OSS

概要 Linux Foundationは2025年12月9日、**Agentic AI Foundation（AAIF）**の設立を発表した。AIシステムが会話型アシスタントから自律的なエージェントへと急速に進化するなか、透明性と相互運用性を担保する中立プラットフォームの必要性に応える形での設立となる。初期プロジェクトとして、AnthropicのModel Context Protocol（MCP）、BlockのオープンソースAIエージェントフレームワーク「goose」、OpenAIが提案するAIコーディングエージェント向け仕様「AGENTS.md」の3プロジェクトが寄贈された。プラチナム会員にはAmazon Web Services、Anthropic、Block、Bloomberg、Cloudflare、Google、Microsoft、OpenAIが名を連ね、主要AIプレイヤーが共同でガバナンスを担う体制が整った。 MCPが解決してきた課題 MCPはAnthropicが開発したオープン標準で、AIモデルが外部ツールやデータソースと安全に接続するためのプロトコルを定義している。登場以前、AIエージェント開発者は「n×m統合問題」に悩まされていた。5つのAIクライアントが10の内部システムと連携するだけで、認証やエラー処理の異なる50通りの個別実装が必要になる計算だ。MCPはこの問題をスキーマ駆動のインターフェース（JSON Schema）、OAuth対応のセキュアなリモート接続、予測可能なツール呼び出し、長時間タスクのサポートといった仕様を統一することで解消した。現在は10,000以上のMCPサーバーが公開されており、Claude、Cursor、Microsoft Copilot、Geminiをはじめとする主要AIプロダクトで採用が進んでいる。 急速な普及とLinux Foundation移管の意義 2025年のGitHub Octoverse報告によれば、LLM SDKをインポートするリポジトリは113万件に達し、AIリポジトリの新規作成は69万3,000件を記録した。MCPは公開から8か月足らずで3万7,000スターを獲得し、月間インストール数は9,700万件に及ぶ。Linux FoundationへのMCP移管は、開発者にとって長期的な安定性、企業規模を問わない平等な参加、互換性の保証、エンタープライズ向けのオープンスタンダードガバナンスといった実質的な恩恵をもたらす。この位置づけはKubernetesやSPDXといったクリティカルインフラと並ぶものとして評価されている。 今後の展望 AAIFはLinux Foundationの中立的な管理のもと、各プロジェクトの独立性と透明性を確保しながら標準策定を進める。MCP Dev Summitなどのコミュニティイベントも開催予定で、エコシステム全体での協調開発が加速する見通しだ。開発者は1つのMCPサーバーを複数のAIクライアントで再利用でき、テスト・デバッグが容易な標準化されたツール連携の恩恵を享受できる。独占的なプロプライエタリ解決策ではなく、契約ベースのオープン標準としてAIエージェント統合の基盤が確立されつつある。

概要 JavaScriptテストフレームワークVitest 4.1が2026年5月1日にリリースされた。今回のリリースは「テスト整理」「ネイティブ実行」「AIエージェント最適化」の3つを主要テーマとして掲げており、Vite 8への完全対応も同時に提供される。VoidZeroがメンテナンスするVitestは、Jestと互換性のあるAPIを維持しながら、大規模プロジェクトでのパフォーマンスや開発者体験の向上を継続的に進めている。5万件のテストを持つプロダクションモノレポを対象にしたSitePointのベンチマークでは、コールドスタート・ウォッチモードの再実行・ピークメモリ使用量のいずれにおいてもJestを上回る結果が示されている。 テストタグとライフサイクルフックの強化 2025年10月から要望が挙がっていた機能として、Pythonのpytestマーカーに着想を得たテストタグ機能が搭載された。各テストにラベルを付与し、論理演算子やワイルドカードを用いて実行対象を柔軟に絞り込める。たとえば vitest --tags-filter='frontend && !flaky' と指定することで、フロントエンド向けテストのうち不安定なものを除外して実行できる。大規模コードベースでのテスト管理に大きく貢献する機能だ。 ライフサイクルフック面では、テストをコンテキストでラップするための aroundEach と aroundAll が新たに追加された。また test.extend ビルダーパターンの型推論が改善され、カスタムフィクスチャを利用する際の型安全性が向上している。CIとの連携を強化する github-actions レポーターも導入され、テスト統計やフレイキーテストのハイライトを含むJobサマリーをGitHub Actions上で自動生成できるようになった。 ネイティブNode.js実行モード（実験的） 実験的機能として、Viteのモジュールランナーサンドボックスをバイパスする viteModuleRunner: false オプションが追加された。これを有効にすると、Node.jsのネイティブインポートが使用されるため、起動速度の向上と本番環境により近い挙動が期待できる。Node.js 22.18以降または23.6以降を使用している場合、ネイティブのTypeScriptストリッピングが追加設定なしで利用可能となる。Bunとも動作するが、現時点ではモジュールモックとカバレッジ機能はサポートされておらず、今後の対応が見込まれる。 AIエージェント向けのagentレポーター AIコーディングエージェントによる開発ワークフローへの統合を意識した専用レポーター agent が追加された。AIエージェントがテスト実行結果を解析する際に消費するトークン数を削減することを目的に設計されており、LLMベースのコーディング支援ツール内でVitestを活用するユースケースを直接サポートする。 リリース後に確認された不具合 リリース直後に2件の問題が報告されている。1つ目は、カバレッジの無視ヒントに関するリグレッションで、@preserve アノテーションが必要となる挙動が確認された。2つ目は、更新されたViteのピア依存関係の記法によってYarn Classic（v1.x）での導入が壊れる問題だ。いずれも既知の問題として追跡されており、修正が進められている。

Ubuntu 26.04 LTSとZed 1.0——4月の二大メジャーリリース 2026年4月、Linux・OSSコミュニティにとって特に注目度の高いリリースが相次いだ。まずUbuntu 26.04 LTS（コードネーム：Resolute Raccoon）が正式リリースされ、通常の5年間の長期サポート（LTS）が提供される。LTSリリースは企業や安定運用を重視するユーザーに広く採用されており、次の大きな移行サイクルの基盤となるバージョンとして注目されている。 もう一つの大きなトピックが、RustベースのオープンソースIDEである「Zed」のバージョン1.0正式リリースだ。Zedは高速なパフォーマンスとモダンな設計で注目を集めてきたエディタであり、今回の1.0リリースではAI・エージェント機能が強化された。具体的にはDeepSeekのAIモデルへの対応が追加され、セッションをまたいで保持されるブックマーク機能、Git統合の改善なども盛り込まれた。一方でpreferred_line_length設定が廃止され、ソフトラップのバウンド制御方式に移行するなど、設定周りの整理も行われている。 4月の主要OSSアップデート一覧 4月はZedとUbuntu以外にも多くの注目リリースが揃った。動画編集ソフトのKdenlive 26.04では、マルチディスプレイ環境向けのモニターミラーリング、トランジションのアニメーションプレビュー、自動トランジション長調整、複数クリップ同時速度変更といった機能が追加された。 Firefox 150はLinux向けにGTK絵文字ピッカーのサポートを導入し、スプリットタブ機能も改善された。仮想化プラットフォームVirtualBox 7.2.8はLinuxカーネル7.0をホスト環境でサポートし、Linuxホスト上でのCPU使用率をより正確に報告するゲスト時間アカウンティング機能が加わった。動画編集ツールShotcut 26.4はSpeech to TextモジュールにVulkan GPUアクセラレーションを導入し、処理速度を大幅に向上させた。 アーカイブマネージャのPeaZip 11.0は大規模コレクションのプリパース処理を最大94%高速化し、ダークモードのHiDPI表示を改善した。システムクリーナーのBleachBit 6.0は選択的Cookieマネージャ、ChromiumベースブラウザのFlatpakサポート、LibreOfficeの最近のドキュメント履歴削除などを追加。デスクトップパブリッシングのScribus 1.7.3ではライブスペルチェックのスレッド分離と、高度なフィルタリングを備えた検索・置換機能の再実装が行われた。 まとめと今後の展望 2026年4月は、長期的な安定基盤となるUbuntu 26.04 LTSと、AIネイティブな開発体験を目指すZed 1.0という二つの象徴的なリリースを軸に、幅広いOSSプロジェクトのアップデートが集中した月となった。Zedが1.0に到達したことで今後さらなるエコシステムの拡大が期待され、Ubuntu 26.04 LTSはエンタープライズ・個人ユーザー双方の標準環境として普及していくとみられる。

概要 RustベースのAIターミナル「Warp」が、クライアントコードをGitHub（warpdotdev/warp）でオープンソース公開した。ライセンスはデュアル構成で、UIフレームワーク部分（warpui_coreおよびwarpuiクレート）にはMITライセンス、残りのコードベースにはAGPL-3.0が適用される。現在70万人以上のアクティブ開発者を持つWarpにとって、これは単なるコード公開にとどまらず、競合他社に対抗するための戦略的な事業転換として位置づけられている。OpenAIが創設スポンサーとして参加しており、同社のThibault Sottiaux氏は「オープンソースは開発者が学び、ものを作り、分野を前進させる方法の中心にあり続けてきた」とコメントしている。 AIエージェント主導の新しい貢献モデル Warpが今回打ち出した最大の特徴は、従来のオープンソースとは異なる「エージェントファースト」な開発貢献モデルだ。同社のクラウドエージェントオーケストレーション基盤「Oz」を活用し、コードの実装・テスト・PRの作成といった実務作業をAIエージェントが担う一方、人間のコントリビューターはアイデア出し・仕様策定・レビューへの集中を期待されている。CEO Zach Lloyd氏は「現時点での開発のボトルネックはコードを書くことではなく、人間主導のタスクにある」と説明する。GitHubのIssueが公式の機能要望・ロードマップ管理の場となり、技術的な議論もオープンに行われる予定だ。 同時発表された機能強化 オープンソース化と同時に、3つの機能強化も発表された。まず、Kimi・MiniMax・Qwenといったオープンソースモデルのサポートが拡充され、タスクに応じた自動モデルルーティングが可能になった。次に、アーキテクチャの柔軟性が向上し、シンプルなターミナルとして使うか、一部のエージェント機能を有効にするか、あるいはフル機能の開発環境として活用するかをユーザーが選択できるようになった。さらに、新しい設定ファイルによってプログラマブルなカスタマイズとマシン間の設定ポータビリティが実現した。対応プラットフォームはLinux・Windows・macOSの3つ。 戦略的背景と競争環境 Zach Lloyd CEOはオープンソース化の動機として、資金力のある閉鎖的な競合製品の台頭を挙げている。価格競争や利用料の補助ではなく、活発なコミュニティとエージェントオーケストレーションの組み合わせにより、内部チーム単独では不可能なスピードで機能リリースを加速できるとの見方を示している。開発者ツール市場において、透明性と外部コントリビューションによる競争優位の確立を目指すこの賭けは、AIエージェント活用を前提とした次世代のオープンソース開発モデルの試金石としても注目を集めている。

概要 Microsoftは2026年4月14日にリリースしたVisual Studio 2026 April Update（バージョン18.5）において、IntelliSenseとGitHub Copilotのコード補完が同時表示される問題への対応を実施した。これはGitHub CopilotがVisual Studio 2022に統合されて以来、開発者コミュニティから継続的に報告されてきた問題であり、「エディタが一度に表示する補完候補は1つのみ」という原則に沿う形でIntelliSenseが優先されるよう動作が変更された。Microsoftのリリースノートでは「IntelliSenseとCopilotの補完が同時に表示されると注意が散漫になるというフィードバックを受け取った」と明記されている。 問題の背景 GitHub CopilotのVisual Studio統合以降、開発者はキー操作における意図しない競合に悩まされてきた。具体的には「Enterキーでプロパティ名を確定しようとした瞬間にCopilotがIntelliSenseを上書きして不正確な補完候補を提示する」「TabキーをどちらのシステムPが処理するのか判別できない」といった問題がGitHub Communityのディスカッション（Discussion #15649など）で数年にわたって議論されてきた。複数の補完システムが同時に介入することで、開発者のフロー状態が頻繁に中断されていた。 技術的な変更内容 今回の変更では、IntelliSenseが有効な状態の間はCopilotのインライン補完が一時的に抑制される仕組みが導入された。IntelliSenseのリストで補完を確定または却下した後、CopilotによるAI補完が自動的に再開される。この優先順位付けはデフォルトで有効となっており、ユーザーが追加の設定変更を行わなくても恩恵を受けられる。4月21日にリリースされたバージョン18.5.1でも引き続き同動作が維持されている。 今後の展望 同時期のアップデートでは、バックグラウンドでタスクを実行しPull Requestの作成まで自動で行うCloud Agent統合、デバッグ作業を支援するDebugger Agent、過去の会話を管理するChat Historyパネルなど、より高度なAIエージェント機能も追加された。Visual StudioへのAI統合は単なるコード補完にとどまらず、開発ワークフロー全体を自動化する方向へ継続的に拡張されており、今回のIntelliSense優先対応はその基盤となるエディタ体験の整備という位置付けでもある。

概要 WSO2はKubernetes向けオープンソース内部開発者プラットフォーム「OpenChoreo 1.0」をリリースした。同プロジェクトは2026年1月6日にCloud Native Computing Foundation（CNCF）サンドボックスへの採択も達成しており、2025年1月の初回コミットからわずか1年足らずでCNCFへの採択に至ったことは、同プロジェクトの急速な成長を示している。すでに240の組織から785名のコントリビューターが参加し、GitHubスターも694に達している。 OpenChoreoはWSO2の商用SaaSプロダクト「Choreo」のオープンソース版として開発されており、チームが大規模なツール統合作業なしにすぐ使える「本番環境対応の基盤」を提供することを目指している。KubriXやCrossplaneといった競合プロダクトが台頭する内部開発者プラットフォーム（IDP）市場において、KubernetesをコントロールプレーンのサブストレートとしてIDPを構築する方向性を明確に打ち出している。 アーキテクチャと主要機能 OpenChoreoは複数のプレーンを明確に分離した設計が特徴で、「ツールを積み重ねるのではなく、関心事を分離する」というコンセプトに基づいている。具体的には以下のプレーンで構成される。 エクスペリエンスプレーン: 開発者とSREが操作するインタラクション層 コントロールプレーン: 高レベルの抽象化をKubernetesマニフェストに変換 データプレーン: ワークロードが実際に実行される層 オブザーバビリティプレーン: メトリクス・ログ・トレースの管理 CIプレーン（オプション）: Cloud Native BuildpacksとArgo Workflowsを使ったビルド管理 開発者ポータルの基盤にはBackstageを採用し、GitOpsの実現にはFluxCDを使用している。プラットフォームエンジニアはコンポーネントタイプとトレイトを通じて抽象化を定義でき、低レベルのKubernetesコントローラーを自ら実装する必要がない点も評価されている。 AIエージェント統合とSREエージェント 1.0の注目機能として、AIエージェントをプラットフォームの「ファーストクラスの参加者」として扱う設計が挙げられる。Model Context Protocol（MCP）サーバーを通じてエージェントにプラットフォームへのアクセスを提供し、コンポーネントの作成・設定管理・プラットフォーム状態の分析といった操作をAIエージェントから実行できるようになっている。 また、SREエージェント機能も内蔵されており、LLMを活用してログ・メトリクス・トレースを自動分析し、インシデントの根本原因を特定する機能を提供する。開発者の日常作業からインシデント対応まで、AI支援のワークフローを広く統合した設計は、現代的なプラットフォームエンジニアリングの潮流に沿ったアプローチといえる。

概要 Astral社が開発するRustベースのPythonパッケージマネージャー「uv」は2026年4月27日、バージョン0.11.8をリリースした。本リリースでは、Astralミラーを介したself-updateサポートや、任意のミラーからPythonをダウンロード可能にする新フラグの追加など、使い勝手を向上させる複数の機能強化が含まれている。また、環境変数による設定オプションの拡充や、細かなバグ修正も行われた。 新機能と機能強化 最大の目玉の一つは、python pinコマンドへの--python-downloads-json-urlフラグの追加だ。これにより、デフォルト以外の任意のミラーから特定のPythonバージョンをダウンロードできるようになり、ネットワーク制限のある環境や社内ミラーを利用する場面での柔軟性が高まった。また、uv self updateがAstralミラーからuvそのものを取得する仕組みに対応し、更新の信頼性と速度が改善されている。 その他の機能強化としては、pip uninstall -y構文のサポート追加、uv self version --shortでバージョン番号のみを表示するオプションの追加、空のSSL_CERT_DIRディレクトリに対する不要な警告の抑制、exclude-newer-spanが存在する場合にexclude-newerの省略を許容するロックファイル処理の改善などがある。相対的なexclude-newer/exclude-newer-package値に対してはセンチネルタイムスタンプが使用されるようになった。 環境変数と設定の拡充 設定面では、新しい環境変数が3つ追加された。UV_PYTHON_NO_REGISTRYはWindowsレジストリを通じたPythonの自動検出を無効化し、UV_NO_PROJECTはプロジェクトファイルの探索を無効化する。さらにUV_PYTHON_SEARCH_PATHを使うことで、Pythonインタープリタの探索パスをカスタマイズできるようになった。これらの環境変数は、CI環境での動作の予測可能性を高めたい場合や、特定のPythonバイナリを確実に指定したいケースで役立つ。 バグ修正 バグ修正では、uv-buildのソースディストリビューションにrust-toolchain.tomlが含まれていなかった問題が修正された。uvからgitコマンドを呼び出す際にリポジトリの環境変数を引き継いでしまう問題も解消された。また、詳細ログに事前署名済みアップロードURLが平文で表示される問題が修正され、セキュリティが向上している。その他、PEP 517ビルド要件における推移的なURL依存関係の処理の修正、dependency-groupsのみを持つpyproject.tomlでのuv lockの動作改善、パッチバージョン指定時のPython自動アップグレードの無効化なども含まれる。なお、uv-buildのパッケージメタデータにPython 3.14のclassifierが追加され、PyTorchドキュメントもバージョン2.11向けに更新された。

概要 C++向けの高速シリアライズライブラリ「Glaze」がバージョン7.2をリリースし、C++26のP2996リフレクション仕様への対応を正式に取り込んだ。P2996は2025年6月にC++26への採択が決定した標準コンパイル時リフレクション機能で、Glazeはこれを従来の__PRETTY_FUNCTION__解析や構造化バインディングに依存したハックの置き換えとして活用する。JSON、YAML、CBOR、MessagePack、TOMLなど幅広いフォーマットのシリアライズに対応するGlazeにとって、今回のアップデートはコンパイル時メタデータ取得の根本的な刷新となる。 P2996リフレクションで何が変わるか 最も大きな変化は、これまでシリアライズ不可能だった非集約型の自動処理が可能になった点だ。カスタムコンストラクタ・仮想関数・継承を持つクラスは、従来は手動でglz::metaによるメタデータ記述が必要だったが、P2996対応環境ではそれが不要になる。また、従来は構造化バインディングの制約から128メンバーが上限だったが、この制限も撤廃された。 さらに列挙型の自動文字列化にも対応した。これまではglz::metaの手書きが必要だったが、P2996環境ではreflect_enums = trueオプションを有効化することでColor::Greenが"Green"としてシリアライズされる（後方互換性維持のためデフォルトは従来通り整数値）。アクセス修飾子も無視できるため、privateメンバーを含む型も追加設定なしでリフレクション可能となった。内部実装ではstd::meta::nonstatic_data_members_ofとaccess_context::unchecked()を組み合わせて標準APIのみでメンバー情報を取得する。 特性 従来方式 P2996対応 最大メンバー数 128 無制限 非集約型対応 手動記述が必要 自動 列挙型文字列化 glz::meta必須 自動 メンバー名取得 __PRETTY_FUNCTION__解析 標準API 対応コンパイラと有効化方法 現時点でP2996リフレクションを利用するには、GCC 16以降（-std=c++26 -freflection）またはBloomberg clang-p2996（-fexpansion-statements -stdlib=libc++）が必要となる。GCC 16はまもなく正式リリースが予定されている。CMakeではglaze_ENABLE_REFLECTION26オプションをONにするか、コンパイラに-DGLZ_REFLECTION26=1を渡すことで有効化できる。コンパイラが__cpp_lib_reflectionまたは__cpp_impl_reflectionマクロを定義している場合は自動で有効になる。 APIに破壊的変更はなく、既存のglz::metaによるカスタマイズも完全に維持される。ただし一点注意すべき変更として、型名の形式が変わった。従来は"mylib::MyEnum"のように修飾名が出力されていたが、P2996環境では"MyEnum"と非修飾名になる。自動生成されたキー名に依存するコードでは出力形式が変化する可能性があるため、移行時には確認が必要だ。 今後の展望 P2996対応はオプトイン形式であり、標準コンパイラによるビルドには影響しない。GCC 16の正式リリースとともに利用者が増えることが予想され、C++26リフレクションのエコシステム全体における実用的な先行事例となる。Glazeは今回の更新でYAMLの処理改善やストリームリクエストのバッファサイズ設定も取り込んでおり、シリアライズライブラリとしての対応範囲を引き続き拡充している。

概要 Dropboxのエンジニアチームは、GitHubと連携してGitのデルタ圧縮の最適化に取り組み、バックエンドモノレポのサイズを87GBから20GBへ約77%削減することに成功した。これによりリポジトリのクローン時間は1時間以上から15分未満へと75%短縮され、CI/CDパイプラインのパフォーマンスと開発者のオンボーディング体験が大幅に改善された。 同社のバックエンドモノレポはバックエンドサービスや共有ライブラリの統合拠点として機能していたが、規模の拡大に伴いクローン操作に1時間以上かかるようになり、CI/CDパイプラインの繰り返しフェッチによってビルドオーバーヘッドも増大していた。さらに、リポジトリホスティングの上限に近づくリスクも浮上していた。 根本原因と技術的な詳細 問題の根本原因は、大容量バイナリの誤コミットや通常の開発活動量ではなく、GitのデルタCOMPRESSIONが大規模リポジトリで非効率なpackfileを生成していた点にあった。DropboxのシニアソフトウェアエンジニアであるIshan Mishraは「実際の開発活動量から想定される成長ペースとは一致しなかった」と説明しており、問題は「何が保存されているか」ではなく「データがどのように保存されているか」にあったという。Shailesh Mishraも「ツールの前提がスケールしたリポジトリ構造と衝突した」と表現している。 対策として採用されたのは以下のアプローチだ。 再パッキング戦略の最適化: packfileの生成方式を見直し、デルタ圧縮の効率を改善 デルタウィンドウと深度の調整: Gitの圧縮パラメーターをリポジトリ規模に合わせてチューニング GitHubとのサーバーサイドパッキング調整: ホスティング側でのパック処理をDropboxの要件に合わせて最適化 ミラー環境での段階的な検証: 本番ロールアウト前にミラーリポジトリでの安全な検証を実施 改善結果と開発者への影響 この取り組みにより達成された改善は以下の通りだ。 指標 改善前 改善後 改善率 リポジトリサイズ 87GB 20GB 77%削減 クローン時間 60分以上 15分未満 75%短縮 CI/CDパイプライン 低速 データ転送量削減により高速化 — 開発者オンボーディング 時間がかかる 待ち時間を短縮 — この事例はバージョン管理システムをプロダクションインフラとして扱う重要性を示している。ストレージ効率がエンジニアリング速度に直結することを改めて示した例であり、ツールの最適化・組織横断的な協力・慎重な検証の組み合わせが大規模モノレポ運用における解決策となり得ることを証明した。

概要 GitHubは2026年4月24日、GitHub Appインストールトークンの新しいフォーマットへの移行を発表した。4月27日より段階的に適用が開始されており、「ステートレストークンフォーマット」の導入によってトークン発行のパフォーマンスと信頼性の向上が図られる。トークンのプレフィックス ghs_ は変更されないが、フォーマット全体は ghs_APPID_JWT 形式に移行し、トークン長が含まれるデータ量に応じて変動する約520文字に延長される。既存のトークンは有効期限まで引き続き使用可能だ。 影響範囲と展開スケジュール 今回の変更はGitHub Enterprise CloudおよびData Residency環境が対象で、GitHub Enterprise Serverへの影響はない。適用対象はサーバー間トークン（server-to-server tokens）とGitHub Actionsの GITHUB_TOKEN で、ユーザー間トークン（user-to-server tokens）については後日対応が予定されている。 展開は2段階で進められる。まず4月27日から5月中旬にかけてGitHub Actionsの GITHUB_TOKEN およびDependabotなどの主要な統合に対して新フォーマットが適用される。続いて5月中旬から6月下旬にかけて全GitHub Appインストールトークンへ拡大され、この期間にはブラウンアウト（一時的な旧形式の無効化）期間も実施される予定だ。 開発者が必要な対応 GitHubはトークンを「不透明な文字列（opaque string）」として扱うことを推奨しており、トークンの内部構造や長さに依存した実装は避けるべきとしている。具体的な対応として、ghs_[A-Za-z0-9]{36} のようなトークン長を固定した検証用正規表現を削除し、データベースのカラムサイズを最低520文字に対応させることが求められる。トークンの形式を検証するコードやトークン長を前提とした処理が存在する場合は、移行期間中に修正を完了させる必要がある。