Gemini Omni登場、マルチモーダル動画生成の新時代
Google DeepMindは2026年5月17日、新たなマルチモーダル生成AIモデル「Gemini Omni」を発表した。テキスト、画像、音声、動画といったあらゆる形式の入力を組み合わせ、高品質な動画を生成・編集できる点が最大の特徴だ。
ファーストモデルとなる「Gemini Omni Flash」は、発表と同時にGeminiアプリ、Google Flow、YouTube Shortsで提供が開始された。自然言語による会話形式での動画編集や、現実世界の物理法則を反映したリアルな映像生成が可能になっている。
この記事では、Gemini Omniが従来の動画生成AIと何が異なるのか、具体的な機能とその仕組み、そしてコンテンツ制作の現場にもたらす変化について解説する。
上の概念図にあるように、Gemini Omniの最大の進化はインプットの柔軟性にある。テキストプロンプトだけでなく、画像や音声、既存の動画そのものを「参照素材」として組み合わせ、そこからまったく新しい映像を生み出せるのだ。DeepMindの記事によれば、将来的には画像や音声の出力にも対応する予定だという。
自然言語で動画を編集する新体験
Gemini Omniが提供する最も画期的な機能のひとつが、会話形式による動画編集だ。従来の動画編集は、タイムライン上でクリップを切り貼りし、エフェクトを重ねる作業の連続だった。Omniでは、編集内容を自然言語で指示するだけで、AIが映像を理解して変更を加える。
DeepMindの発表によれば、Omniは過去の指示内容を記憶し、編集のたびに映像全体の一貫性を維持する。登場人物の見た目や物理法則、シーンの流れが破綻しない。これは単なる「映像の切り貼り」ではなく、AIが映像の文脈を理解しているからこそ実現するものだ。
映像の一部を変更、または一変させる「トランスフォーム」
Omniは、映像内の特定のオブジェクトだけを変更する、あるいはシーン全体をガラリと変えることができる。DeepMindのデモでは、「彫刻をバブル材質に変える」というプロンプトで、彫刻だけが泡状に変化する映像が紹介されている。
この機能は、例えば商品紹介動画の背景だけを差し替えたい、プロモーション映像の季節感を変更したいといった実務ニーズに直結する。撮影済みの映像を素材として、新たなクリエイティブの出発点にできるのだ。
アクションを再構築し、予想外の映像を生成
撮影済みの動画に対して「このシーンで起こっていることを変えてほしい」と指示するだけで、Omniは映像内のアクションそのものを再構築する。新しいキャラクターの追加も、光が音楽に同期して灯るような複雑な演出も可能だ。
発表資料には「手が鏡に触れた瞬間、鏡が美しい液体のように波打つ」というプロンプト例が掲載されている。こうした物理法則に基づく映像表現は、従来の動画生成AIでは難しかった領域だ。
複数ターンにわたる動画の洗練
Omniの編集は、1回の指示で終わらない。環境の変更、アングルの切り替え、スタイルの変更、特定のディテール調整といった指示を段階的に重ねることで、映像を徐々に洗練させていける。DeepMindは「バイオリニストの演奏動画」を例に、環境変更→バイオリンを透明化→肩越しのアングル変更という一連の編集を示している。
この「対話的な編集の積み重ね」は、ディレクターが編集者に指示を出す感覚に近い。クリエイティブの方向性を言葉で伝え、結果を見ながら微調整するワークフローが、AIによって実現しつつある。
世界知識が映像にリアルな文脈を与える
Gemini Omniのもうひとつの核は、Google DeepMindが「世界知識（world knowledge）」と呼ぶ能力だ。Omniは単に見た目がリアルなシーンを構築するだけでなく、「次に何が起こるべきか」を推論する。物理法則、歴史的事実、科学的知識、文化的文脈を踏まえた映像生成が、単なるフォトリアルを超えた説得力のあるストーリーテリングを可能にする。
より正確な物理演算の再現
Omniは重力、運動エネルギー、流体力学といった物理法則の直感的な理解が従来よりも改善されているという。DeepMindが示した「ビー玉が高速でカラクリ装置の上を転がる連続ショット」のプロンプト例では、ビー玉の動きが物理的に破綻しない映像が生成された。
動画制作の現場では、物理演算が破綻した映像は視聴者に違和感を与え、説得力を損なう。特に製品の動作デモや、教育用の科学解説動画では、物理的正確さが信頼性に直結する。Omniのこの改善は、商用・教育コンテンツの品質を引き上げる要素だ。
知識と創造性の融合
Omniはパターンマッチングを超えたレベルで、言語と映像、意味を結びつける。DeepMindの例として挙げられた「AからZまでの珍しいアイテムを各文字ごとに表示する動画」では、カピバラ（C）、ディスコグローブ（D）、ラバランプ（L）といった具合に、各文字に対応するアイテムをAIが自律的に選定し、映像化している。
これは「指示された映像を生成する」というより、「概念を理解した上で映像化する」という質的に異なる能力だ。クリエイターがアイデアを言葉で伝えれば、AIがそれを映像的な表現に落とし込んでくれる。企画段階でのモックアップ作成や、プレゼンテーション用のビジュアル資料作成が大幅に効率化する可能性がある。
複雑な概念を視覚化する説明動画の生成
Omniは短いプロンプトから、複雑な概念をわかりやすく解説する説明動画を生成できる。DeepMindの例では、タンパク質の折り畳み（プロテインフォールディング）を、すべて粘土で作られたクレイメーション（粘土アニメ）風の映像で解説したデモが紹介された。
「複雑なトピックを短時間で視覚化できる」という点は、教育コンテンツや企業の研修資料、製品のオンボーディング動画など、幅広い用途に応用できる。特にスタートアップや中小企業にとって、高品質な説明動画を低コストで制作できる可能性は大きい。
あらゆる組み合わせから動画を生成する力
Gemini Omniのインプットの柔軟性を示す機能として、DeepMindは「複数形式の参照入力」を強調している。画像、テキスト、動画、音声のいずれかを「参照素材」として与えることで、それらをブレンドしたひとつの映像を生成できる。
現時点で音声入力は「声」による参照のみサポートされているが、DeepMindは他の形式の音声入力にも順次対応していく方針だ。画像からキャラクターの外見を、動画から動きのパターンを、音声からリズムやトーンを取り込むといった複合的な制作が可能になる。
画像・音声・動画を「参照」して統一された映像を出力
DeepMindの発表では、3つの異なる素材（画像、動画、音声）を組み合わせて「SF映画風の映像」を生成する例が示された。画像でシーンのスタイルを、動画でカメラワークやエフェクトを、音声で映像のリズムをコントロールできる。
別の例では、人物のイラストとウォークサイクルの動画を組み合わせて、歩きながらリアルな実写映像に変化していく映像を生成している。これらは、クリエイターが持つ複数の素材アセットをAIが「調和」させてひとつの作品に仕上げるという、新しい制作フローを示唆する。
スタイル、動き、エフェクトを自在に適用
参照素材を使うことで、映像のスタイル、動き、エフェクトを細かくコントロールできる。プロンプトだけで指示する場合と比べて、参照素材があることで「こういう感じ」というニュアンスをAIに正確に伝えやすくなる。
「スケートボードにアニメーションのモーションエフェクトを追加する」という例では、撮影済みの映像とAIによるエフェクト生成がシームレスに融合した。実写とCGの境界線が曖昧になっている現在、Omniは実写素材を出発点に、AIによる拡張を重ねるというハイブリッドな制作スタイルを加速させるだろう。
自分のアバターで動画を制作、そして責任ある開発
Google DeepMindは、AIの責任ある開発と利用のためのポリシーを明確にしている。その一環として提供されるのが「Avatars」機能だ。これは自分の声と姿をデジタル化したアバターを作成し、そのアバターを使って動画を生成できるというもの。
デジタルアバター機能
アバター機能を使うと、生成された動画はユーザー自身の声と姿を反映したものになる。これはパーソナライズされたコンテンツ制作を可能にする一方、なりすましや悪用のリスクもはらむ。DeepMindは、音声や発話を伴う動画編集機能については、テストを重ねた上で責任ある形での提供方法を模索している段階だとしている。
SynthIDによる電子透かしとコンテンツの透明性
Omniで生成されたすべての動画には、人間の目では認識できないSynthIDのデジタル透かしが埋め込まれる。これにより、GeminiアプリやChrome、Google検索を通じて、その動画がAIによって生成されたものであることを簡単に検証できる。
AIによるコンテンツ生成が一般化するにつれ、その真正性を担保する仕組みの重要性は高まっている。動画メディアの信頼性に関わるこの取り組みは、プラットフォームとしてのGoogleの姿勢を示すものだ。Web制作者やマーケターにとっては、配信する映像コンテンツの透明性を確保する手段として注目に値する。
Gemini Omniの利用を開始するには
現在提供されているのは「Gemini Omni Flash」モデルで、Google AI Plus、Pro、Ultraの各プラン加入者がGeminiアプリとGoogle Flowで利用できる。また今週より、YouTube ShortsとYouTube Create Appでは無償で提供が開始される予定だ。
今後数週間以内には、API経由で開発者やエンタープライズ顧客にも提供が拡大される。これにより、既存の制作ワークフローやサービスにOmniの動画生成機能を組み込んだアプリケーションの登場が期待される。
この記事のポイント
- Gemini Omniはテキスト・画像・音声・動画の組み合わせ入力に対応した動画生成AIで、最初のモデル「Flash」が提供開始された
- 自然言語による会話形式で動画を編集でき、複数ターンの指示で映像を段階的に洗練できる
- 物理法則や世界知識に基づいたリアルで一貫性のある映像生成が可能になった
- 生成動画にはSynthIDの電子透かしが埋め込まれ、コンテンツの透明性が確保される
- API提供により、今後のサービス連携や制作フローへの組み込みが加速する見込みだ
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
OpenAI、Windows版Codexに独自サンドボックス実装 昇格不要プロトタイプから完全制御へ
2026年5月13日、OpenAIはWindows版Codexにおけるサンドボックス実装の技術的詳細を公式ブログで公開した。これまでWindowsユーザーは、コーディングエージェントの操作を逐一承認するか、全アクセスを許可するリスクの高い選択肢しかなかった。今回の独自サンドボックスによって、安全性と生産性を両立する仕組みが実現した。
Codexは開発者のローカルマシン上で動作し、CLIやIDE拡張機能、デスクトップアプリを通じて利用できる。デフォルトではワークスペース内でのファイル書き込みやネットワークアクセスに制限がかかるが、これをOSレベルで強制するサンドボックスが不可欠だった。macOSやLinuxにはSeatbeltやseccompといった確立された分離機能がある一方、Windowsには同様の機能が標準で提供されていなかった。
Codex for Windowsが抱えていた課題
Windows版Codexの初期リリースでは、サンドボックス機能が実装されていなかった。ユーザーは次の2つの不十分な選択肢を強いられていた。
- ほぼすべてのコマンドを手動で承認するモード: ファイル読み取りのような安全な操作も含めて逐一の許可が必要で、煩雑さから本来の自律的作業の利点が損なわれる。
- フルアクセスモード: 承認なしにすべてのコマンドを無制限に実行させる。操作はスムーズだが、意図しないファイル変更やデータ流出のリスクがある。
Codexは本来、ユーザーの代理としてテスト実行やファイル編集、ブランチ作成などを自律的に処理することで生産性を高めるツールだ。したがって、安全性を確保しつつ、許可の承認を最小限に抑える仕組みが求められた。その鍵となるのが、OSが持つ隔離機能を活用したサンドボックスである。
サンドボックスが果たす役割
サンドボックスとは、プロセスに制約を課す隔離実行環境である。Codexがコマンドを実行する際、OSがそのプロセスツリー全体に制限を伝播させることで、許可なくワークスペース外のファイルへ書き込んだり、インターネットへアクセスしたりできないようにする。macOSやLinuxでは標準機能でこれが実現できるが、Windowsでは一から設計する必要があった。
Windowsが提供する3つの分離機能を検証
OpenAIのエンジニアリングチームは、Windowsに用意されている隔離プリミティブとしてAppContainer、Windows Sandbox、Mandatory Integrity Control（MIC）を検討したが、いずれもCodexの用途には合致しなかった。
AppContainer: 強力だがワークフローに柔軟性欠く
AppContainerはWindowsネイティブのサンドボックスで、必要なアクセス権限を事前に定義するケイパビリティベースのモデルである。OS境界による本格的な制限を提供するが、Codexはシェル、Git、Python、パッケージマネージャなど多様なツールを動的に制御する必要がある。事前に厳密に権限を絞るAppContainerでは、エージェントのワークフローに対応できなかった。
Windows Sandbox: 強い隔離だが実環境と分断
Windows Sandboxは、使い捨ての軽量仮想マシンである。セッション終了時に内部の変更はすべて破棄される。セキュリティ面では強力だが、Codexはユーザーの実際のチェックアウト環境やツール群を直接操作する必要があり、外部の仮想デスクトップでは実用的ではなかった。さらにWindows SandboxはHomeエディションでは利用できず、製品上の問題も抱えていた。
MIC: 静的制御だがホストファイルシステムへの影響が大きい
Mandatory Integrity Control（MIC）は、低／中／高の整合性レベルを使ってプロセスやオブジェクトの信頼度を制御する。原則として、低整合性プロセスは高整合性オブジェクトに書き込めない。Codexを低整合性で実行し、書き込み可能ディレクトリを低整合性に再ラベルすることで、書き込み範囲を制限できる可能性があった。
しかし、ワークスペース全体を低整合性にすると、「Codexが書き込める」以上の意味が生じる。低整合性プロセス全般がその領域にアクセスできるようになり、開発マシンの信頼モデルを大きく損なうリスクがあった。またACLと同様に実ファイルシステムに変更を加えるため、サンドボックスの制約を動的に変更することも難しかった。
OpenAIの独自アプローチ: SIDと制限トークンによる非昇格サンドボックス
既存機能では要件を満たせないと判断したOpenAIチームは、WindowsのSID（セキュリティ識別子）と書き込み制限トークンを組み合わせた独自のサンドボックスを設計した。最初のプロトタイプは管理者権限なし（非昇格）で動作することを目標とし、ファイル書き込みとネットワークアクセスを制限する仕組みを目指した。
SIDと書き込み制限トークンの仕組み
SIDはWindowsがユーザーやグループ、ログインセッションを識別するために用いるIDである。たとえば、S-1-5-5-X-Yが現在のセッションに割り当てられる。SIDはACL（アクセス制御リスト）と組み合わせて、ファイルやディレクトリへの読み書き実行権限を制御する。OpenAIのチームは、Codex専用の合成SID sandbox-writeを作成し、このSIDを使って書き込み可能範囲を厳密に定めた。
書き込み制限トークン（write-restricted token）は、プロセストークンに追加の書き込みチェックを課す。通常のユーザー権限に加え、トークン内の制限SIDリストに含まれるSIDのいずれかが書き込み先ACLで許可されていなければ書き込みができない。これにより、Codexプロセスの書き込み権限を、ワークスペースと明示的に許可したディレクトリだけに絞り込んだ。
非昇格プロトタイプの流れ
セットアップ時に、sandbox-write SIDを作成し、カレントディレクトリや設定ファイル config.toml に指定した書き込み可能ルートに書き込み・実行・削除のACLを付与する。一方で .git、.codex、.agents といったディレクトリには明示的に書き込みを拒否した。そのうえでCodexは、制限SIDリストに Everyone、ログインセッションSID、sandbox-write を含む書き込み制限トークンで子プロセスを起動した。
これにより、明示的に許可した場所以外への書き込みはOSレベルでブロックされ、読み取りはユーザー権限で広く許可されるバランスのとれた環境が実現した。しかしネットワーク制御には別の課題が残った。
環境変数によるネットワーク抑制と限界
非昇格環境ではWindows Firewallを管理者権限なしで利用できなかったため、環境変数を用いた間接的なネットワーク抑制が採られた。具体的には HTTPS_PROXY=http://127.0.0.1:9 などのプロキシ変数に無効なアドレスを指定し、GitやSSHなどのツールが外部に接続できないようにした。またPATHにダミーの denybin ディレクトリを追加するなど、一般的なツールの通信を妨げた。
しかしこの方法はあくまで「助言的」な制約であり、プロキシ設定を無視するプログラムや独自のソケット通信を行うバイナリに対しては効果がなかった。悪意あるコードに対しても脆弱だった。
ネットワーク制御を突破した昇格版サンドボックスの実装
実用的なネットワーク制御を実現するため、OpenAIチームはWindows Firewallの導入を決断した。ファイアウォールルールをプロセスツリー単位で適用するには、サンドボックス専用のユーザー権限が必要となり、結果として管理者権限でのセットアップを許容する「昇格版サンドボックス」へと設計が進化した。
専用ユーザーとファイアウォール
昇格版では、CodexSandboxOffline と CodexSandboxOnline という2つのローカルユーザーを作成する。Offline のユーザーにはすべての外部ネットワーク通信を遮断するファイアウォールルールが適用される。Codexがネットワークを必要としないコマンドを実行する際にはOfflineユーザーで起動し、ネットワーク許可が必要な場合はOnlineユーザーを選択する。これにより、ファイル書き込み制限と同様にOSレベルでの確実なネットワーク遮断が可能になった。
コマンドランナーと4層アーキテクチャ
ユーザー権限を切り替えて子プロセスを起動するには、Windowsのセキュリティ境界を越える必要があった。OpenAIは専用のバイナリ codex-command-runner.exe を導入し、次のような多層構造を採用した。
- codex.exe: 通常のユーザー権限で動作し、コードエージェントのハーネスとして機能する。
- codex-windows-sandbox-setup.exe: 管理者権限でセットアップ処理を担当。サンドボックスユーザーの作成、ファイアウォールルールの追加、必要なACLの付与を実行する。
- codex-command-runner.exe: サンドボックスユーザーとして起動され、自身のトークンから書き込み制限トークンを作成し、最終的な子プロセスを起動する。
- 子プロセス: 制限付きトークンで実行されるGitやPythonなどの実コマンド。
具体的な起動フローは次の通りである。codex.exe が CreateProcessWithLogonW を用いて codex-command-runner.exe をサンドボックスユーザーとして起動。ランナーは自身のプロセストークンからログオンSIDを抽出し、書き込み制限トークンを構築したうえで CreateProcessAsUserW により制限付きの子プロセスを立ち上げる。
このデモで示したように、昇格版ではOSのファイアウォール機能を組み込むことで、非昇格版のネットワーク上の弱点を克服した。また、システム全体へのACL変更は最小限にとどめ、非同期処理を用いてセットアップのブロック時間を短縮している。
この記事のポイント
- Windows版Codexは当初、サンドボックスが存在せず、手動承認かフルアクセスの選択肢しかなかった。
- OpenAIはAppContainer、Windows Sandbox、MICを検討したが、いずれも動的な開発ワークフローに適さず、独自サンドボックスを開発した。
- 最初の非昇格プロトタイプは、SIDと書き込み制限トークンでファイル書き込み範囲を制限したが、ネットワーク抑制は弱かった。
- 最終的な昇格版サンドボックスでは、専用のWindowsユーザーとファイアウォールルールを導入し、ネットワーク遮断をOSレベルで実現。
- codex-command-runner.exeによる多層アーキテクチャで、安全性を保ったままコードエージェントの自律実行を可能にした。
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
OpenAI CodexがDellと提携、オンプレミス環境でエージェントAIを実行可能に
OpenAIとDell Technologiesが、エンタープライズ向けAIコーディングツール「Codex」の導入範囲を大幅に拡大する提携を発表した。週間アクティブ開発者数が400万人を突破したCodexは、クラウド利用が難しい重要データを抱える企業のために、Dellのオンプレミスインフラ上で直接稼働する道を手に入れた。
この提携で、CodexはDell AI Data PlatformおよびDell AI Factoryと接続される。ソースコードや社内ドキュメントといった機密性の高い企業データを外部に出さずに、AIエージェントを構築・運用できるようになる点が最大の意義だ。
AIの業務活用を進めたいがデータ主権やセキュリティの壁に阻まれていた企業にとって、この提携は「自社データセンター内で完結する高度なAIエージェント」という現実的な選択肢を提供する。
Codexの現在地 コーディングツールからビジネスエージェント基盤へ
CodexはOpenAIが提供する開発者向けAIツールだ。IDE（統合開発環境）やCLI（コマンドラインインターフェース）上で動作し、コード補完、バグの自動修正、テスト生成などを行う。2026年5月時点で週間アクティブ開発者数は400万人を超え、OpenAIのエンタープライズ製品群の中で最も急成長しているサービスの一つになっている。
Codexの活用範囲は開発現場を超えて広がっている。ツール間のコンテキスト収集、レポート作成、プロダクトフィードバックの整理とルーティング、リードのスコアリングとフォローアップ文面の作成、さらには複数のビジネスシステムを横断した業務調整まで、エージェントとしての機能を実務に組み込む企業が増えている。
Codexが「開発者のためのツール」から「ビジネスプロセスを動かすエージェント基盤」へと進化している点が、今回のDell提携の文脈で重要になる。エージェントが実用的な価値を発揮するには、その企業固有のデータやシステムと深く接続している必要があるからだ。
Dell AI Data Platformとの統合で実現すること
今回の提携の中核は、CodexがDell AI Data Platformと直接接続される点だ。Dell AI Data Platformは、多くの企業がオンプレミス環境でデータの保存・整理・ガバナンス（管理統制）に利用している基盤である。
エージェントが「使える」内部コンテキストへのアクセス
AIエージェントがビジネスで役立つかどうかは、どれだけ深い「コンテキスト（文脈情報）」を取得できるかにかかっている。単に公開情報を検索するだけのエージェントでは、企業内部のコードベースや非公開の運用ドキュメント、過去のインシデント対応履歴といった重要情報にアクセスできない。
CodexがDell AI Data Platform経由でアクセスできるようになる情報には、以下のようなものが含まれるとOpenAIの記事では説明されている。
- 企業の非公開コードベース
- 内部ドキュメントやナレッジベース
- ビジネスシステムの実データ
- 運用知識やチームのワークフロー情報
この仕組みにより、データを社外に送信することなく、AIエージェントが企業内部の文脈を理解して動作する。金融機関や医療機関、製造業など、データ主権が厳格に問われる業界にとっては特に重要な意味を持つ。
ガバナンスを維持したままのAI導入
ガバナンスとは、データの管理体制や利用ルールを整備し、遵守することだ。企業は法規制や社内ポリシーにより、特定のデータを社外のクラウドサービスに保存できないケースが多い。Dellのオンプレミス基盤上でCodexを動作させることで、既存のデータガバナンスの枠組みを壊さずにAIを導入できる。
Dell AI Factoryとの連携がもたらす応用可能性
OpenAIの発表によると、両社はDell AI Factoryとの接続も検討している。Dell AI Factoryは企業がAIワークロードを実行するための基盤で、データ準備やシステム管理、テスト実行、AIアプリケーションのデプロイ（展開）までをカバーする。
この接続が実現すると、Codexに加えてChatGPT Enterpriseやその他のAPIベースのソリューションも、Dellのハイブリッドまたはオンプレミスインフラ上で統合的に動作する可能性がある。
この構想が示すのは、OpenAIがエンタープライズ市場において単なる「API提供者」から「インフラと一体化したAIプラットフォーム」への転換を図っていることだ。Dellの発表文では「Dell AI Factory with OpenAI Codex」という表現が使われており、両社のブランドを冠した統合ソリューションとして展開される可能性が高い。
エンタープライズAI市場における提携の戦略的意味
今回の提携は、企業向けAI市場での競争軸を読み解く上でも示唆に富む。
「データの所在地」がAI導入の決定打になる
2026年現在、多くの企業がAI導入を進めているが、最大の障壁は技術力ではなく「データをどこに置くか」というポリシー問題だ。GDPR（EU一般データ保護規則）や各国のデータローカライゼーション規制により、クラウド上のAIサービスをそのまま使えない企業は少なくない。
Dellとの提携によりCodexは、企業のデータセンター内で動作する選択肢を手に入れた。これは競合のAIコーディングツールにはない差別化要素であり、特に規制産業からの需要を取り込む上で強力な武器になる。
「エージェントの実用化」に必要なのはコンテキスト
AIエージェントが「良いコードを提案する」だけの段階から「ビジネスプロセスを自律的に実行する」段階へ進むためには、企業固有のコンテキストにアクセスできることが不可欠だ。OpenAIの記事でも、エージェントが役立つために必要な内部情報として、コードベースやドキュメント、業務システム、チームのワークフローが挙げられている。
CodexがDell AI Data Platform経由でこれらの情報に安全にアクセスできるようになることで、エージェントが「汎用的なアドバイザー」から「その企業の業務を深く理解した実行者」へと進化する基盤が整う。
OpenAIのエンタープライズ戦略における位置づけ
OpenAIは2025年以降、ChatGPT EnterpriseやCodex CLIといった企業向け製品を相次いで投入してきた。今回のDell提携は、それらの製品群を「インフラレベルで企業の既存環境に溶け込ませる」動きとして位置づけられる。
Microsoft Azureを通じたクラウド提供に加え、オンプレミスという選択肢を加えたことで、OpenAIのエンタープライズ展開は「パブリッククラウド」「ハイブリッド」「オンプレミス」の三層をカバーする体制に近づいている。
企業が今から準備すべきこと
Dellのインフラを既に利用している企業にとって、Codexのオンプレミス展開は比較的スムーズに導入できる見込みだ。OpenAIの発表では、具体的な提供開始時期や料金体系の詳細は明かされていないが、両社の協業が進むにつれて順次情報が公開されるだろう。
企業の開発部門やIT統括部門は、以下の点を事前に整理しておくと、展開開始時のスピードが上がる。
- Codexエージェントにアクセスさせたい内部データの棚卸し（コードベース、ドキュメント、APIなど）
- 既存のDellインフラ（AI Data Platform / AI Factory）の利用状況確認
- データガバナンスポリシーの見直しとAI利用ルールの整備
- セキュリティチームとの事前協議（エージェントがアクセスするデータ範囲の定義）
AIエージェントの導入で先行する企業は、すでにコードレビューやテスト自動化といった開発領域から始め、段階的にビジネスプロセスへ適用範囲を広げている。Codexのオンプレミス対応は、その拡大をより安全に進めるためのインフラ選択肢として機能するだろう。
この記事のポイント
- OpenAI CodexがDell AI Data Platformとの統合により、オンプレミス環境での稼働が可能に
- 企業のコードベースや内部ドキュメントに安全にアクセスし、AIエージェントの実用性が大幅に向上
- Dell AI Factoryとの連携により、ChatGPT Enterpriseなど他のOpenAIサービスもオンプレミス展開を検討
- 金融や医療など厳格なデータガバナンスが求められる業界でのAI導入障壁が下がる
- 企業は今のうちに内部データの棚卸しとガバナンスポリシーの整備を進めておくことが有効
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
GPT-5.5が企業向けエージェントにもたらす変革、Databricks導入事例
大規模言語モデルの進化が、企業の実務ワークフローに直接的な成果をもたらし始めている。データ分析基盤を提供するDatabricksが、OpenAIの最新モデルGPT-5.5を社内向けAIエージェントに組み込んだ結果、複雑な文書処理タスクを評価するベンチマーク「OfficeQA Pro」でエラーが46%も減少した。GPT-5.5はこのベンチマークで初めて正解率50%を超えたモデルとなった。
この結果は「モデルの性能向上が、実際のビジネス指標にどう結びつくか」を示す重要な事例だ。単なる会話能力の評価ではなく、スキャンされたPDFや古い社内フォーマットの文書を解析し、複数ステップのタスクを自律的に遂行する能力が問われている。本記事ではGPT-5.5がどのような技術的進歩を遂げ、企業のAI活用にどんな可能性を開くのかを解説する。
企業向けAIエージェントの現在地、なぜ文書処理が壁になるのか
企業がAIエージェントを導入する際、最初にぶつかる壁が「社内文書の解析」だ。契約書や見積書、古いシステムから出力されたレポートなど、形式がバラバラな文書をAIに理解させるのは想像以上に難しい。特にスキャンされたPDF（画像として取り込まれた文書）や、数十年前のレガシーフォーマットで保存されたファイルは、最新のAIでも正確なテキスト抽出に失敗することが多い。
この問題の深刻さは、小さな認識ミスが後続の処理全体を狂わせる点にある。たとえば請求書の金額を一桁間違えて抽出すれば、その後の経理処理やレポート作成がすべて誤った情報で進んでしまう。人間なら「明らかにおかしい」と気づくようなエラーでも、AIエージェントは抽出した数値をそのまま信じて処理を続ける。これが企業現場でのAI導入を妨げる最大の障壁となっていた。
OfficeQA Proベンチマークの評価観点とは
Databricksが開発したOfficeQA Proは、こうした実務課題を忠実に再現する評価指標だ。このベンチマークでは、モデルに対して以下の3つの能力が求められる。
- 文書解析（Parsing）：スキャンPDFやレガシーファイルから正確に情報を抽出する能力
- 情報検索（Retrieval）：長大な文書群の中から必要な情報を見つけ出す能力
- 根拠に基づく推論（Grounded Reasoning）：抽出した情報をもとに、論理的な判断や回答を生成する能力
単なる知識クイズではない。バラバラなフォーマットの文書を理解し、複数のステップを経て最終的なアウトプットを出す「エージェントとしての実務能力」が試される設計になっている。
上図のように、GPT-5.5への切り替えによって文書解析のエラーが大幅に減り、後続のワークフロー全体の信頼性が向上した。この改善の背景には、モデルの視覚認識能力と言語理解の統合が進んだことがあると見られている。
GPT-5.5が達成した二つの飛躍的改善
Databricksが報告したGPT-5.5の改善点は、大きく二つの領域に分かれる。一つは文書解析精度の劇的な向上、もう一つは複数ステップのタスクを効率的に管理するオーケストレーション能力の進化だ。
スキャン文書解析の「ステップ関数的」な進歩
Databricksの記事で同社のSinghvi氏が指摘するように、GPT-5.4まではスキャンされた古い文書から数字を正確に読み取れないケースが頻発していた。これに対しGPT-5.5は、古い文書やスキャンPDFの解析において「ステップ関数的な性能向上」を見せたという。「ステップ関数的」とは、なだらかな改善ではなく、階段を一段上がるように非連続的な飛躍があったことを意味する。
この進歩が特に重要なのは、企業が保有する文書の多くが過去の資産だからだ。10年前の契約書、5年前の監査レポート、紙をスキャンしてPDF化した資料。こうした「過去の遺産」を正確に解析できるかどうかが、AIエージェントの実用性を左右する。GPT-5.5はこの壁を一つ越えたと言える。
ムダな遠回りをしないタスク実行能力
もう一つの重要な改善が、複数ステップのタスクを実行する際の軌道（Trajectory）の最適化だ。GPT-5.4では、目的に対して不必要な検索を繰り返す「遠回り」が発生し、非効率な処理経路をたどることがあった。これはエージェントが過剰に「慎重」になりすぎる、あるいは文脈を適切に把握できずに余計な確認作業を挟んでしまう問題だ。
GPT-5.5では、必要な情報を必要なタイミングで的確に取得し、最短のステップでタスクを完了する能力が高まった。追加の監視や人間による修正なしに、複雑なワークフローを完遂できる信頼性が向上している。
この改善は、企業がAIエージェントに求める「人間の監視なしで動く自律性」に直結する。タスクが長引けばそれだけコストも増え、途中で人間が介入する必要性も高まる。GPT-5.5はこの課題に対して明確な前進を示した。
企業ワークフローへの実装、AgentBricksとAI Unity Gateway
DatabricksはGPT-5.5を単独のチャットボットとして使っているわけではない。同社の「AI Unity Gateway」を通じて、AgentBricksやAgent Supervisor APIといったエージェント構築基盤と統合し、実際のビジネスワークフローに組み込んでいる。
AgentBricksとは、Databricksが提供するエージェント構築フレームワークだ。専門特化した複数のエージェントを組み合わせ、複雑な業務プロセスを自動化できる。ここでGPT-5.5は「監督者（Supervisor）」として機能する。各専門エージェントが文書解析やデータ検索、レポート生成といった個別タスクを担当し、GPT-5.5が全体の流れを管理して適切なタイミングで適切なエージェントに指示を出す。このアーキテクチャによって、単一モデルでは扱いきれない複雑な業務フローが実現できる。
この「監督者モデル」のアプローチは、今後の企業向けAI活用の主流になると考えられる。一つの巨大モデルがすべてを処理するのではなく、専門エージェントを束ねる統括役としてLLMを配置する設計だ。GPT-5.5のオーケストレーション能力の向上は、この設計思想と見事にマッチしている。
ナレッジワークにおけるGPT-5.5のインパクト
DatabricksのSinghvi氏は「GPT-5.5は知識作業においてステップ関数的な変化をもたらした」と評している。単に質問に答えるだけでなく、複数の文書を横断して情報を統合し、文脈を理解した上で判断を下す「知識労働の代替」としての性能が大きく向上したという評価だ。
この評価が特に重要なのは、AIが「単なる道具」から「業務のパートナー」へと役割を変えつつあることを示唆しているからだ。従来のAIアシスタントは、人間が明確に指示したタスクを実行するのが限界だった。GPT-5.5を中核に据えたエージェントは、曖昧な指示や複雑な文脈でも自律的に判断し、複数ステップの業務を完遂できる水準に近づきつつある。
日本企業への示唆、データ資産の再活用という視点
この事例から日本企業が学ぶべきポイントは明確だ。多くの企業が「過去の文書資産」を抱えている。紙で保管された契約書、古い基幹システムから出力された帳票、スキャンされたPDFの山。これらをAIで解析し、活用可能なデータに変換する技術が現実のものになりつつある。
ただし注意点もある。GPT-5.5の性能向上が顕著だったのは「スキャン文書の解析」と「複数ステップのオーケストレーション」であり、これはモデル自体の進化に加えて、Databricksのエージェント基盤との統合設計が効いている。単に高性能なLLMを導入するだけでは同様の成果は得られない。データ基盤とエージェント設計の両面からアプローチする必要がある。
この記事のポイント
- GPT-5.5は企業の実務ベンチマークOfficeQA Proでエラーを46%削減し、初めて正解率50%を突破した
- 特にスキャンPDFやレガシー文書の解析精度が飛躍的に向上し、古い文書資産の活用が現実的に
- 複数ステップのタスクを効率的に管理するオーケストレーション能力も改善し、自律的な業務遂行が可能に
- DatabricksではGPT-5.5を監督エージェントとして配置し、専門エージェント群を統括する設計を採用
- 日本企業にとっては、過去の文書資産をAIで再活用できる可能性が開けた事例として注目すべき
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
GitHubがアクセシビリティエージェントを試験運用。3,535件のPRをレビューし解決率68%
GitHubは2026年5月、実験的な汎用アクセシビリティエージェントの試験運用を開始した。このエージェントはプルリクエスト内のフロントエンドコードを自動的にレビューし、アクセシビリティ上の問題を指摘する。さらに多くのケースで修正案まで提示する。
運用開始後に3,535件のプルリクエストをチェックし、68%という高い解決率を達成。構造の明確化やインタラクティブ要素の名前付け、テキスト代替など、日常的に発生するバリアを自動で取り除く仕組みだ。
GitHubのブログで公開された知見には、アクセシビリティチームが取り組んだ設計方針や、LLMエージェントならではの制限への対処法が詰まっている。本記事ではその要点を技術者向けに掘り下げる。
エージェントの目的と初期成果
📋 エージェントが検出した問題の上位5種
- 支援技術への構造と関係性の明示不足
- インタラクティブ要素の名前の不明瞭さ
- 重要なアナウンスがユーザーに届かない
- 非テキストコンテンツの代替テキスト欠如
- フォーカス順序が視覚レイアウトと一致しない
※エージェントは自動修正を適用するか、開発者に具体的な提案を提示する
GitHubの発表によれば、このエージェントはアクセシビリティを「完全に解決する」ことを狙っていない。現場のエンジニアがアクセシビリティ上のバリアを見つけて取り除く作業を「増強する」存在として設計された。そのため、あらゆるケースに対応する「銀の弾丸」ではないと明言されている。
この姿勢が実験の立ち上げを加速させ、社内の賛同を得るうえで有効だった。スコープを限定し、明確な責任範囲を共有することで、過度な期待を防ぎつつ素早く実装できたという。
エージェント設計を支える考え方
GitHubのチームは「障害の社会モデル」に基づき、環境の作り方によってアクセス障壁が生まれると捉えている。ユーザーインターフェースの構築方法そのものが障壁を生み出すため、エージェントは仲間の作業を補い、そうした障壁の除去を支援する役割を担う。
つまり「人間の判断を置き換えるAI」ではなく、「アクセシビリティ専門家の補助輪」として機能させる考え方だ。この方針が、後述するサブエージェント構造や複雑性評価の仕組みに一貫して織り込まれている。
過去のアクセシビリティ改善がエージェントを支えた
GitHubにはLLMが普及する以前から、アクセシビリティの問題を体系的に記録し修正する仕組みが存在していた。テンプレート化された報告フォーム、再現手順、WCAG達成基準との紐付け、修正プルリクエストへのクロスリンクといった豊富なメタデータを備えた単一のリポジトリに、すべての問題が集約されている。
この構造化されたデータの蓄積こそが、エージェントにとって理想的な「学習素材」になった。GitHubのブログ記事は「過去の手作業による監査と修正こそが最大の資産」と強調している。問題とその修正コードを参照することで、エージェントは組織固有のコーディング規約やUIパターンに沿った適切な提案を引き出せるようになった。
さらに、LLMの非決定的な「あいまい一致」がここでは強みに転じた。定型のスキルファイルだけで「アクセシビリティのベストプラクティスに従え」と指示しても、膨大な非アクセシブルコードで訓練されたモデルはむしろアンチパターンを生成しがちだ。過去の修正履歴から具体的な文脈を参照できることで、質の高い出力が安定した。
効率的なトークン消費のためのサブエージェント戦略
アクセシビリティはコード、デザイン、ライティングなど多領域にまたがる全体的な関心事だ。そのため、一般的なエージェントを作ろうとすると、1回の処理で大量のトークンを消費し、応答速度の低下や運用コスト増、信頼性の低下を招く。
⏺ 親エージェント（Orchestrator）
- リクエストの振り分けとコードスキャン
- 複雑性スコアの算出
- エスカレーション判断と再監査ループ
コード監査とWCAG調査を実施し、構造化された監査レポートを出力する。コード変更は一切行わない。
親エージェントから渡された構造化レポートを基に、コード修正またはガイダンス文書を生成する。
親エージェントが出力を検証し、必要なら人間の専門家へエスカレーションする
2つのサブエージェントはサンドボックス化され、直接通信はしない。構造化テンプレートを介して情報を受け渡す。
GitHubは当初、1つのモノリシックなエージェントで始めたが、すぐに限界を感じたという。そこで採用したのが、2つの専用サブエージェントによるアーキテクチャだ。
1つ目は「パッシブなレビューア」。コードの監査とWCAG達成基準との照合を行い、構造化されたレポートを出力する。2つ目は「アクティブな実装者」。親エージェントがレポートを精査した後、修正が必要な箇所だけにコード変更を加える。両者は直接情報をやり取りせず、テンプレート化されたスキーマファイルで内容を渡す。
この構成には明確な意図がある。レビューサブエージェントは「意見を持たず」すべての問題を列挙し、親エージェントが重要度を評価する。複数の重大なWCAG違反がある場合や、高リスクと判定されたパターンでは自動修正を試みず、アクセシビリティチームへのエスカレーションを促す。コードの複雑性が閾値を超えれば、修正ではなくガイダンス提供のみの「ガイダンス専用モード」に切り替わる。
さらに、メソッド的な手順で指示を実行させることが精度向上の鍵だった。親エージェントに「フェーズ1 調査」「フェーズ2 コード監査」「フェーズ3 構造化出力」という順序を徹底させ、各フェーズ内のステップも固定順で実行する。この線形な流れは、人間が手動で監査と修正を行うときの思考手順をそのままなぞったものだ。
エージェントの限界を理解し対策する
どれほど精心に設計しても、LLMベースのエージェントには避けられない落とし穴がある。GitHubは実験を通じて、以下の領域に特に注意を払った。
コードの複雑性を数値化して介入を制御する。シェルスクリプトでコードの相対的な複雑度をスコア化し、閾値を超えた場合は自動修正を禁止する。エージェントは「アクセシビリティチームに相談してください」と開発者に伝えるだけにとどめる。
高リスクパターンをブラックリスト化する。ドラッグアンドドロップ、トースト通知、リッチテキストエディタ、ツリービュー、データグリッドなど、現在のLLMでは支援技術と完全に調和する実装が困難なUIパターンが対象だ。これらのパターンを含むコードに対しては、エージェントは修正を生成せず、必ず人間の介入を求める。
「行動バイアス」を抑える。LLMはとにかく何かを生成したがる性質があるため、コードを書かないよう指示されたルールをかいくぐろうとする行動が見られた。これに対抗するため、指示違反を防ぐ「アンチゲーミング」ルールを導入した。
自動化で検出できない36%の壁を認識する。WCAG 2.1のレベルAとAAの達成基準は55項目あるが、そのうち決定論的な自動チェックで検出できるのは35項目にとどまる。残り約36%は手動評価が不可避だ。エージェントの成功率だけを見て安心してはならず、設計段階から手動でアクセシビリティを検討する重要性をGitHubは強調している。
WCAG A/AA達成基準55項目の内訳
自動検出可能
手動評価が必要
LLMエージェントはこの36%の領域に挑戦しているが、まだ完全ではない。設計とプロトタイピングの段階で人間がバリアを特定するプロセスが不可欠。
加えて、エージェントの出力を定期的に手動レビューし、プルリクエストレビュアーのフィードバックを収集する仕組みも整えている。これにより、指示やリソースを改善すべき領域を継続的に特定している。
この記事のポイント
- GitHubのアクセシビリティエージェントは、3,535件のPRをレビューし68%の解決率を記録した
- エージェントは「人間の代替」ではなく「増強」を目的とし、スコープを限定して運用
- 過去の手動監査で蓄積した構造化データが、エージェントの精度を飛躍的に高めた
- サブエージェント構造と線形な指示実行でトークン消費を抑え、精度を向上
- 自動検出できないWCAG基準の約36%を手動で補い、高リスクパターンは生成を禁止する対策が鍵
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
VS Code 1.121が公開、AIエージェントのターミナル連携とモデル管理が進化
マイクロソフトは2026年5月20日、コードエディタ「Visual Studio Code」のバージョン1.121を公開した。今回のリリースでは、Copilot Chatが備えるエージェント機能とターミナルとの連携部分に多くの改良が加えられている。
具体的には、ツール呼び出しの表示が見やすくなり、特定のLLMモデルをピン留めして素早く選択できる仕組みが追加された。加えて、長いテストやビルドの出力を自動で圧縮する範囲が大幅に拡大され、エージェントが生成するコマンドの実行効率と可読性が一段と向上している。
開発者のワークフローに与える影響は小さくない。ターミナルに流れるログ情報が整理され、エージェントが勝手にバックグラウンド処理に移行するタイミングが賢くなったおかげで、より思考の流れを途切らせずに済むのだ。本記事ではこれらの改善点を実務的な視点で掘り下げていく。
エージェントホストの操作性向上
まず目を引くのが、エージェントホスト内でのツール表示まわりの改善だ。Copilot Chatのエージェントモードでは、AIが「ファイルを読む」「ターミナルでコマンドを打つ」などのツールを自律的に呼び出す。今回のアップデートで、それらのツール名がより直感的な表示になった。
これまでは内部的で分かりにくかった呼称が、人間にとって理解しやすい「ファイル読み取り」「コマンド実行」といったラベルに置き換わっている。入力と出力のUIも再設計され、どのツールに何を渡し、何が返ってきたかが一目で追えるようになった。エージェントの行動をレビューしたり、デバッグしたりする局面で役立つ変更だ。
自動承認ピッカーとワークスペースの事前選択
もうひとつ、エージェントホスト接続時の「自動承認ピッカー」が追加された。外部のエージェントホストへ接続する際に、あらかじめ信頼できるものを選んでおける仕組みで、毎回承認操作を求められる煩わしさが減る。
また、VS Codeを既に特定のワークスペースで起動している場合、エージェントウィンドウを開くとそのワークスペースのフォルダが自動で事前選択される。手動でプロジェクトフォルダを指定し直す手間が不要になるため、作業開始時のリズムが良くなる。小さな改良だが、1日に何度も繰り返す操作だけに、開発効率への積み重ね効果は意外と大きい。
上の図は、ツール表示とワークスペース選択の流れをビフォーアフターで示したものだ。変更前は開発者がエージェントの内部的な動きを読み解く必要があったが、変更後は視覚的に整理され、作業開始時の手数も減っている。
モデル管理の進化と「お気に入り」機能
続いて、言語モデルピッカーに「ピン留め」機能が追加された。これは、よく使うモデルをお気に入り登録して、ドロップダウンリストの上部に固定する機能だ。
現在、VS CodeのCopilot Chatでは複数のAIモデルを切り替えて使える。コーディング向きのモデル、自然言語のやり取りに向いたモデル、軽量で反応が速いモデルなど、タスクに応じて選び分ける開発者も多い。ピン留め機能により、毎回リストをスクロールして探すストレスから解放される。
環境変数「VSCODE_AGENT」の追加とその効果
Copilot Chatがターミナルでコマンドを実行する際、専用の環境変数「VSCODE_AGENT」がセットされるようになった。この変数は、AIが起動したターミナルセッションであることを明示的に示すためのものだ。
実務では、シェルのプロンプト表示を変えたり、エージェント向けのログフォーマットを自動判別したりする用途に使える。たとえば、AI用のターミナルでは冗長なカラー表示をオフにして、パースしやすいテキスト出力に切り替える、といった使い方が考えられる。自分でシェル初期化ファイルをカスタマイズしている開発者にとっては、自動化の可能性が広がる嬉しい追加だ。
チャットと統合ブラウザの連携強化
統合ブラウザ（Simple Browser）で表示中のWebページを、ワンクリックでCopilot Chatに共有できる「Add to Chat」オプションが右クリックメニューに追加された。
VS Codeの統合ブラウザは、エディタ内でドキュメントやAPIリファレンスを閲覧するのに使われる。今回の機能で、例えばReactの公式ドキュメントを開きながら「このセクションの内容を要約して」とAIに投げる操作が、ドラッグやコピーペーストなしで完結する。Web上の情報をコーディングの文脈にスムーズに取り込めるのは、エディタを離れずに作業を続けたい開発者にとって大きな利点だ。
また、チャットエージェントが内部的に生成したバックグラウンドターミナルは、コマンド完了後に自動で破棄されるようになった。これにより、使われないプロセスが蓄積してシステムリソースを圧迫するのを防げる。エージェントがテストの実行や依存関係のインストールなどを一括操作した後、きれいに後片付けされるイメージだ。
これらの改善は、AIアシスタントを「裏方」として使う際の体験を底上げする。情報収集からコード生成、実行、後始末まで、一連の流れに無駄がなくなっていく方向性だ。
ターミナルツールの出力処理が大幅に改善
今回のリリースで最も実務的なインパクトが大きいかもしれないのが、ターミナルツールの出力圧縮まわりの拡張だ。
エージェントがテストランナーやビルドツールを実行すると、膨大なログが出力され、チャット画面が埋め尽くされることがある。この問題に対応するため、出力圧縮（冗長な行を折りたたみ、重要な結果だけを強調表示する仕組み）の対象が一気に広がった。
圧縮対象が大幅に拡大されたコマンド群
新たに対象となったのは、以下のツール群だ。
- テストランナー:
pytest、jest、cargo test - ビルドツール:
tsc（TypeScriptコンパイラ）、cargo build、make - リンター類
- Docker関連コマンド
- パッケージマネージャ（npm、yarn、pipなど）
これらのツールが出力する長大なログから、本当に必要なエラー行やサマリーだけを抽出し、チャット画面上ではコンパクトに表示してくれる。テストが数千件走っても、失敗したケースだけに集中できるわけだ。
アイドルサイレンスタイマーで同期実行を自動バックグラウンド化
ターミナルツールには、同期コマンドが一定時間まったく出力を返さない場合に、自動的にバックグラウンド実行に切り替える「アイドルサイレンスタイマー」が導入された。設定した時間内に何の進捗も表示されなければ、AIエージェントはそのコマンドをバックグラウンドに回し、別のタスクに取り掛かれる。
従来は、長時間かかる処理が走っている間、エージェントの思考がブロックされがちだった。この機能は、CI/CDパイプラインや重いデータベースマイグレーションの待ち時間中に、エージェントが他の作業を並行して進められるようにするものだ。
（数千行のログが流れる）
エージェントは完了まで他の操作ができない
出力が折りたたまれ、エラー行のみ表示
一定時間出力なし → 自動でバックグラウンド化
アイドルサイレンスタイマーは設定可能なため、プロジェクトの特性に合わせて閾値を調整できる。テストが沈黙するのはバグではなく重い処理の前触れ、というチームなら長めに取ればいい。
マルチラインコマンドの修正とConPTYの最新化
エージェントホストのターミナルツールでは、複数行にまたがるシェルコマンドの実行時に問題が発生することがあったが、今回のアップデートで修正された。bashやPowerShellでループや条件分岐を含むスクリプトを生成させるケースで、従来は行の継続が正しく解釈されないバグに遭遇することがあった。この修正によって、AIが生成した複数行スクリプトの信頼性が高まっている。
さらに、Windows環境向けに、擬似ターミナルAPIの基盤となるConPTY（conpty.dll）の新しいバージョンがVS Code本体に直接バンドルされるようになった。これまではシステム側のバージョンに依存しており、古いWindowsではターミナルの描画に問題が出ることがあった。バンドル化により、VS Code側で一貫したターミナル挙動を保証できるようになった。
SSH接続におけるキーボード対話認証のサポート
最後に、エージェントホストがSSH接続する際に、キーボードインタラクティブ認証（パスワード入力やワンタイムパスコードの要求を含む対話形式の認証）がサポートされた。多要素認証が求められるサーバーや、接続時に追加の質問が表示される環境でも、エージェントホスト経由の自動接続が可能になったわけだ。
セキュリティ要件が厳しい本番環境や、企業ポリシーで対話認証を強制されているサーバーに対して、Copilot Chatのエージェントを遠隔操作するハードルが下がる。VS Code Remote Developmentの既存ユーザーにとっては、よりシームレスにAI支援を組み込めるようになる変更だ。
この機能は、特にDevSecOpsの文脈で歓迎されそうだ。開発環境と本番環境を明確に分離しつつ、AIアシスタントの支援を安全に受けられる選択肢が増えたことを意味する。
この記事のポイント
- VS Code 1.121ではAIエージェントのツール表示が見直され、入力と出力の可読性が向上した
- モデルピッカーにお気に入りのピン留め機能が追加され、切り替え操作が高速化した
- ターミナル出力の圧縮対象が拡大され、テストやビルドのログがコンパクトに表示される
- アイドルサイレンスタイマーにより、長時間コマンドの自動バックグラウンド化が可能になった
- SSHのキーボード対話認証サポートで、よりセキュアな環境へのエージェント接続が容易になった
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
OpenAIがTanStack npm攻撃に対応、Macユーザーは6月12日までにアプリ更新を
広く利用されるオープンソースライブラリ「TanStack」のnpmパッケージが悪意ある第三者によって改ざんされた「Mini Shai-Hulud」と呼ばれるサプライチェーン攻撃。この影響はOpenAIにも及び、同社は2026年5月13日に公式な対応報告を公開した。
OpenAIの調査によると、ユーザーデータや本番システム、知的財産への不正アクセスは確認されていない。しかし、同社のコード署名証明書が一時的に影響下にあったことから、予防的な措置としてMacユーザーを対象に全アプリケーションの更新を2026年6月12日までに完了するよう呼びかけている。
今回の記事では、攻撃の具体的な影響範囲、OpenAIが講じたセキュリティ対策、なぜMacだけが更新対象なのか、そして実務者が理解すべきサプライチェーンリスクの本質を解説する。
TanStackを狙ったサプライチェーン攻撃とは
2026年5月11日（UTC）、フロントエンド開発で広く使われるJavaScriptライブラリ群「TanStack」のnpmパッケージが、攻撃グループによって改ざんされた。この攻撃は「Mini Shai-Hulud」と名付けられ、ソフトウェアサプライチェーンの弱点を突く大規模なキャンペーンの一環だ。
サプライチェーン攻撃とは、正規のソフトウェアやライブラリを踏み台にし、その利用者にマルウェアを拡散する手法を指す。開発者が信頼して導入するパッケージマネージャー（npm、PyPI、RubyGemsなど）を通じて感染が広がるため、一企業だけでなく、エコシステム全体に被害が連鎖する点が最大の脅威だ。
今回の攻撃では、改ざんされたパッケージをインストールした開発者の端末から認証情報が引き出される挙動が確認されている。OpenAIの事例でも、このメカニズムにより2台の社内端末が侵害を受けた。
攻撃の構造とマルウェアの挙動
Socket.devの分析によれば、Mini Shai-Huludは主に認証情報（トークン、APIキー、セッション情報など）の窃取を目的としている。感染後の典型的な挙動は、開発者端末に保存されたGit認証情報や環境変数への不正アクセス、そして一部の内部コードリポジトリへの侵入だ。
OpenAIが委託した第三者デジタルフォレンジック企業の調査では、影響を受けた2名の社員がアクセス可能だった一部の内部ソースコードリポジトリで、認証情報の引き出しが成功した形跡が確認された。ただし、コードそのものや他の情報が流出した証拠はない。
OpenAIの初動対応と封じ込め
OpenAIは悪意ある活動を検知した直後、以下の封じ込め措置を即座に実行した。
- 影響を受けた端末とIDの隔離
- 全ユーザーセッションの強制無効化
- 影響リポジトリに関連する全認証情報のローテーション（再発行）
- コードデプロイワークフローの一時的制限
- ユーザーおよび認証情報の挙動調査の徹底
これらの対応により、攻撃者による追跡アクセスや窃取された認証情報の悪用は確認されていない。また、顧客データやOpenAIの知的財産への影響は一切なかったと報告されている。
Macユーザーに更新が必要な理由
一見すると「社内端末2台の侵害だけなら、なぜエンドユーザーが対応するのか」と疑問に思うかもしれない。この背景には、コードサイニング証明書（コード署名証明書）の重要性がある。
コードサイニング証明書とは、ソフトウェアの開発元を電子的に証明する仕組みだ。macOSやWindows、iOSといったプラットフォームは、この証明書を確認することで「正規の開発者がリリースしたアプリかどうか」を判定している。
OpenAIの内部リポジトリには、iOS、macOS、Windows、Android向けのコードサイニング証明書が保管されていた。この証明書自体が直接流出したわけではないが、アクセス可能な状態にあったことから、OpenAIは予防的措置としてすべての証明書を新しいものに置き換える判断を下した。
証明書失効のタイムラインと影響
2026年6月12日をもって、旧証明書は完全に失効する。これ以降、旧証明書で署名されたmacOSアプリは、Appleのセキュリティ保護機能（Gatekeeper）によって新規ダウンロードや初回起動がブロックされる。
WindowsやiOS、Androidのアプリについても新しい証明書で再署名されるため、将来的なアップデートは必要になる。ただ、これらのプラットフォームでは即時のユーザー操作は不要とされている。
Macだけが個別アクションを求められる理由は、Appleのセキュリティモデルが証明書の有効性を厳格に検証する設計になっているためだ。更新を怠ると、以下のアプリが正常に動作しなくなる可能性がある。
- ChatGPT Desktop（バージョン 1.2026.125 以前）
- Codex App（バージョン 26.506.31421 以前）
- Codex CLI（バージョン 0.130.0 以前）
- Atlas（バージョン 1.2026.119.1 以前）
なぜ即時の証明書失効ではないのか
OpenAIはすでにプラットフォーム事業者と連携し、旧証明書を用いた新規の公証（ノータリゼーション）を全面的にブロックしている。公証とは、Appleがアプリをスキャンして悪意あるコードが含まれていないことを確認するプロセスだ。
仮に攻撃者が旧証明書を使って偽のOpenAIアプリを作成したとしても、公証を受けられないため、デフォルトのmacOSセキュリティ設定では実行が阻止される。この防御策が機能している間に、ユーザーがスムーズに公式アプリへ移行できるよう約1か月の猶予期間が設けられた。
この猶予期間中に、アプリ内アップデートまたは公式サイトからの再インストールを通じて、最新バージョンへの切り替えを済ませておくことが推奨される。
攻撃が浮き彫りにした開発エコシステムの脆弱性
今回の事案は、特定企業を標的とした攻撃というよりも、オープンソースエコシステム全体の構造的な弱点を突いたものと言える。攻撃者は個別の企業ではなく、広く使われる共有ライブラリを侵害することで、一度に多数の組織へ侵入できる。
現代のソフトウェア開発は、npm、PyPI、Maven Centralといったパッケージレジストリに大きく依存している。1つのパッケージが侵害されれば、依存関係の連鎖によって数百、数千のプロジェクトが影響を受ける。実際、TanStackのパッケージを依存関係に持つプロジェクトは膨大だ。
OpenAIが進めるサプライチェーン防御
OpenAIは2025年末に発生したAxios開発者ツールの侵害を受け、すでにサプライチェーン攻撃への防御を段階的に強化していた。具体的には以下の対策が進められていた。
- CI/CDパイプラインで扱う機密度の高い認証情報の追加保護
minimumReleaseAgeなどの設定を用いたパッケージマネージャーの制御導入- 新規パッケージの信頼性を検証する追加セキュリティソフトウェアの展開
minimumReleaseAge とは、パッケージがレジストリに公開されてから一定時間（例：3日間）経過しないとインストールを許可しない設定だ。これにより、公開直後の悪意あるパッケージを誤って取り込むリスクを低減できる。
しかし、これらの対策が全社的に展開される途中の段階で、今回のインシデントは発生した。侵害を受けた2台の端末には、新たな制御設定がまだ適用されていなかったのである。
実務者が今すぐ取るべき対策
OpenAIの事例から学べる教訓は、単一の企業だけに留まらない。自社の開発環境においても、以下の対策を早急に検討すべきだ。
- パッケージマネージャーのロックファイル（package-lock.jsonなど）を定期的に監査する。 意図しないバージョン変更や新規依存関係が混入していないか、CI環境で自動チェックする仕組みを作る。
- サプライチェーンセキュリティツールの導入。 Socket.dev、Snyk、GitHub Dependabotなどを使い、脆弱性や悪意あるパッケージを早期に検出する。
- コードサイニング証明書の厳格な管理。 CI/CD環境とは完全に切り離し、必要最小限の担当者のみがアクセスできる保管場所を確保する。
- 依存パッケージの更新を自動化しすぎない。 パッチバージョンであっても、公開直後の即時適用は避け、一定の猶予を設ける。
このような防御策は、自社の開発文化や速度とバランスを取りながら段階的に導入していくのが現実的だ。しかし、攻撃の連鎖速度は日に日に速まっている。放置するリスクの方がはるかに大きいことは、今回の事例が明確に示している。
ユーザーが取るべき具体的なアクション
OpenAIのアプリをMacで利用している個人および企業は、以下の手順を確実に実施してほしい。
- 公式の更新経路のみを使用する。 アプリ内のアップデート通知、またはOpenAI公式ウェブサイト（openai.com）からダウンロードする。メール、メッセージ、広告、ファイル共有リンク経由の「ChatGPT」「Codex」インストーラーには絶対に手を出さない。
- 6月12日までに更新を完了する。 期限を過ぎると、旧証明書で署名されたアプリはmacOSによってブロックされる。業務で利用している企業は、社内のIT管理者が一括アップデートを計画すべきだ。
- パスワード変更は不要。 OpenAIは公式に、顧客のパスワードやAPIキーが影響を受けていないと明言している。無用なパスワード変更はフィッシングのリスクを高めるだけだ。
企業のIT管理者向け追加ガイダンス
組織内でOpenAIアプリを管理している場合、6月12日の証明書失効までにMDM（モバイルデバイス管理）やソフトウェア配布ツールを通じて、全Mac端末のアプリを最新バージョンに更新する計画を立てる必要がある。
更新対象となるアプリと、失効する旧バージョンの一覧は以下の通りだ。
- ChatGPT Desktop（旧バージョン 1.2026.125）
- Codex App（旧バージョン 26.506.31421）
- Codex CLI（旧バージョン 0.130.0）
- Atlas（旧バージョン 1.2026.119.1）
これらのバージョンが社内で稼働している場合、速やかに更新手続きを進めることが求められる。
この記事のポイント
- OpenAIはTanStack npmパッケージへのサプライチェーン攻撃により社内端末2台が侵害されたが、ユーザーデータや本番システムへの影響はなかった。
- 予防措置としてコードサイニング証明書を全面的にローテーション。Macユーザーは6月12日までにアプリを更新する必要がある。
- 旧証明書を用いた新規の公証はすでにブロック済みのため、偽アプリがmacOSで実行されるリスクは低い。
- 攻撃の本質はオープンソースエコシステムの脆弱性を突いたものであり、全開発組織がパッケージ管理の防御策強化を求められている。
- パッケージの即時自動更新を避け、minimumReleaseAgeの設定や監査プロセスの導入が有効な対策となる。
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
GitHub Copilotに新プランMax登場、Pro/Pro+にFlex割り当てで利用可能額が大幅増
2026年6月1日から、GitHub Copilotの個人向けプランが大きく変わる。利用量に応じた課金への移行に伴い、ProとPro+プランに「Flexアロットメント」と呼ばれる変動型の追加利用枠が導入され、月額100ドルの新プラン「Max」も登場する。
GitHubの公式ブログで発表された今回の変更は、長時間のエージェント駆動作業や複数ステップの複雑なタスクに対応するためのものだ。価格は据え置きで利用可能な総額が大幅に増える仕組みであり、とくにPro+ユーザーには大きな恩恵となる。
この記事では、Flexアロットメントの仕組み、各プランの具体的な料金とクレジット、移行時に注意すべき点を詳しく解説する。
GitHub Copilotの個人向けプラン刷新概要
なぜ今、プランが変わるのか
GitHubは2026年1月に、Copilotの課金方式を「月額固定の定額制」から「利用量ベースの課金（Usage-based billing）」へ切り替える方針を発表した。この移行に伴い、多くのユーザーから「含まれる利用量が十分か」という懸念が寄せられていた。とくに、マルチステップのエージェント作業や、より高性能なモデルの利用が増えるにつれて、当初発表された利用枠では不足するケースが想定されたのである。
公式ブログの記事によれば、GitHubはこのフィードバックを受け、Pro/Pro+プランの利用総量を増やすとともに、新しいMaxプランを追加した。これにより、個人開発者から高負荷のAI活用まで幅広いニーズをカバーする形となる。
新ラインナップの全体像
2026年6月1日以降、個人向けCopilotは「Free」「Pro」「Pro+」「Max」の4プラン体制に再編される。Freeプランは引き続き月に限定的なコード補完とチャット、エージェント機能を提供する。Pro、Pro+、Maxは有料となり、利用量ベースの課金が適用されるが、月額料金に応じた「基本クレジット」と、変動する「Flexアロットメント」の合計が利用可能な総クレジットとなる。
Flexアロットメントの仕組み
基本クレジットとFlex割り当ての関係
有料プランでは、毎月の利用可能額は2つの部分で構成される。一つは「基本クレジット（Base credits）」で、これは月額料金と1対1で対応し、常に固定だ。たとえばProプラン（月額10ドル）なら基本クレジットは10ドル分になる。もう一つが「Flexアロットメント（Flex allotment）」で、これは基本クレジットの上乗せ分として付与される可変の追加枠である。
実際の利用時には、まず基本クレジットが消費される。基本クレジットを使い切ると、自動的にFlexアロットメントが適用される。ユーザーは特別な設定やバケット管理をする必要はなく、ダッシュボードで残りの利用可能額を確認するだけで済む。IDE、github.com、CLIのすべてで共通のレートで消費される仕組みだ。
Flexが無制限ではない理由
FlexアロットメントはAIの経済性の変化に応じて変動するよう設計されている。具体的には、モデルの価格変動や新モデルの登場、推論効率の向上といった要因によって、GitHub側が柔軟に割り当て量を調整する。つまり、利用可能な追加枠は時期によって変わりうる。しかし基本クレジットは常に月額料金と等価のため、最低限保証されるラインはブレない。
このように、Proプランは従来の固定クレジットに上乗せがあるため、実質的なお得感が増す。とりわけPro+プランでは基本の39ドルに加えて31ドル分のFlexが付与され、合計70ドル分の利用が可能になる。頻繁に長大なエージェントタスクを回すパワーユーザー向けにはMaxが用意された形だ。
各プランの料金と利用可能クレジット
Proプラン：月額10ドルで15ドル分
Proプランは月額10ドル。基本クレジットは10ドル分、Flexアロットメントが5ドル分付与され、合計15ドル分の利用枠となる。小規模な個人開発や、日々のコード補完を主に使う層には十分な容量と言える。
Pro+プラン：月額39ドルで70ドル分
Pro+プランは月額39ドル。基本39ドルに加え、Flexで31ドルが追加され、総額70ドル分を利用できる。マルチステップのリファクタリングやドキュメント生成、中規模のエージェントタスクを日常的にこなす開発者にとって、コストパフォーマンスが非常に高い設計だ。
Maxプラン：月額100ドルで200ドル分
新設のMaxプランは月額100ドル。基本クレジット100ドル分に、同じく100ドル分のFlexが加わり、総利用可能額は200ドルになる。大量のコード生成や継続的なエージェント実行を必要とするフルタイムのAI活用シナリオを想定したプランだ。大規模オープンソースプロジェクトのメンテナや、AIを骨太に組み込んだ開発フローを回すチームリーダーに適している。
クレジットの消費ルールと実際の使い方
コード補完と次編集候補は引き続き無制限
有料プランでは、コード補完（Code completions）と次編集候補（Next edit suggestions）は無制限で、クレジットを消費しない。つまり、エディタ上でリアルタイムに表示される補完候補はこれまでどおり使い放題である。クレジットが消費されるのは、チャット形式の問い合わせやエージェントによる複数ステップの実行、より高度なモデルを利用した処理だ。
超過時の追加購入とダッシュボード
もし基本クレジットとFlexアロットメントの両方を使い切ってしまった場合でも、追加のクレジットを購入して作業を続けられる。ダッシュボードには、現在の残りクレジットと消費状況が表示されるため、いつでも確認できる。これにより、月末に突然利用できなくなる心配はなく、プロジェクトの進捗に合わせて柔軟にリソースを追加できる。
Flexアロットメントが変動する背景
AIの経済性の進化に合わせた設計
Flexアロットメントが月によって変わるかもしれない最大の理由は、AIモデルの推論コストが急速に変化しているためだ。新モデルの登場やハードウェア効率の改善、サードパーティのAPI価格改定などが起きれば、GitHubは利用者に提供できる付加価値の量を動的に調整する。固定の枠では、こうした外的要因に対応しきれないリスクがある。
GitHubの発表では、基本クレジットだけは常に月額料金と等価であることを約束している。Flex部分が変動しても、最低限のコストパフォーマンスは損なわれない仕組みだ。このハイブリッドな設計は、ユーザーに安定した基盤を提供しつつ、AI技術の進歩をプランに取り込むGitHub側の狙いが感じられる。
ユーザーが今すぐすべきこと
月額契約者は自動移行、追加操作不要
現在ProまたはPro+の月額プランを利用しているユーザーは、2026年6月1日になると自動的に新しい利用量ベース課金のプランへ移行し、Flexアロットメントが適用される。手動でプランを変更する必要はない。もし年間契約を結んでいる場合は、更新タイミングなどの詳細を公式ドキュメントで確認するとよい。
移行後すぐにダッシュボードでクレジットの残高をチェックし、自分の普段の開発スタイルでどれだけ消費するかを把握しておくことを推奨する。特にエージェント機能を積極的に使っているユーザーは、Pro+やMaxへのアップグレードを検討するタイミングかもしれない。
この記事のポイント
- 2026年6月1日より、GitHub Copilot個人向けプランにFlexアロットメントと新Maxプランが導入される
- Pro（10ドル）とPro+（39ドル）の月額料金は据え置きのまま、利用可能クレジットが増加（Proは15ドル分、Pro+は70ドル分）
- Maxプランは月額100ドルで200ドル分のクレジットを提供し、高負荷なAI活用を想定
- コード補完と次編集候補は有料プランでも無制限で、クレジット消費はチャットやエージェント利用時のみ
- FlexアロットメントはAIの経済性変化に応じて変動するが、基本クレジットは常に固定
- 既存の月額契約者は自動移行のため、追加の操作は不要
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
ChatGPTに広告が登場。OpenAIがテスト運用を発表、日本への展開も明らかに
OpenAIは2026年2月、ChatGPTの無料プランとGoプランにおいて広告のテストを開始した。回答の内容に広告が影響することはなく、会話データは広告主に対して非公開に保たれる。すでに米国でのテストを経て、カナダや豪州への拡大が始まっている。
5月7日のアップデートでは、日本、英国、メキシコ、ブラジル、韓国の5カ国にもパイロットを拡大する計画が発表された。このテストはAIモデルの開発コストを一部カバーし、無料での利用を継続可能にする目的がある。実際に広告がどう表示されるのか、具体的な仕組みを見ていく。
ChatGPTで始まった広告テストの実態
今回のテストは、ChatGPTのログイン済み成人ユーザーのうち、無料プランとGoプランを対象とする。月額20ドルのPlusや200ドルのPro、契約型のBusinessやEnterprise、Educationの各プランには広告が表示されない。OpenAIの公式ブログでの発表によれば、目的は「より多くの人が強力なChatGPTの機能にアクセスできるようにする」ことだ。
無料層を支えるインフラと広告の役割
ChatGPTは数億人のユーザーが学習や日常の判断に使うサービスである。無料プランとGoプランを高速かつ安定して提供し続けるには、大規模な計算基盤と継続的な投資が欠かせない。広告収入はその運用費を補填し、無料層や低価格帯の品質を落とさずにAIの能力を向上させるための資金源と位置づけられている。
実際にどの程度のリクエスト数がさばかれているかというと、SimilarWebの推計では2026年3月時点でChatGPTの月間訪問数は約50億回に達している。これだけのアクセスをリアルタイムで処理するためのGPUクラスタの電気代だけでも、月あたり数十億円規模と試算するエンジニアもいる。
広告の表示要件
テスト段階では、会話の話題とユーザーの過去のチャット履歴、過去の広告とのインタラクションに基づいて表示する広告が選ばれる。たとえば料理のレシピを検索しているときには、食材キットや食料品の宅配サービスといった関連性の高い広告が出る仕組みだ。
自然検索結果はスクロールが必要
食材キットの広告が1件だけ表示
このデモでは、従来の検索エンジン型の広告表示と、ChatGPTの会話型広告表示の違いを示している。検索エンジンでは広告が検索結果の上位を占めることが多いが、ChatGPTでは回答と明確に分離され、会話の流れを妨げない形で1件の関連広告が表示される。
広告が回答内容に与えない影響とプライバシー設計
OpenAIは今回のテストに際して、「広告はChatGPTの回答に一切影響を与えない」という基本方針を明示している。回答はユーザーにとって最も役立つ内容に最適化され、広告は常に「スポンサー」ラベル付きで回答とは視覚的に分離される。
会話データは広告主に渡らない
プライバシー面では、広告主がユーザーのチャット内容やチャット履歴、メモリ機能に保存された情報、個人の詳細にアクセスすることはできない。広告主に提供されるのは、自社の広告が何回表示され何回クリックされたかといった集計データのみである。
これは、Cookieやデバイスフィンガープリントで個人を追跡する従来の行動ターゲティング広告とは根本的に異なるアプローチだ。OpenAIは「狭いターゲティングを防ぐためのガードレール」を設け、詐欺広告や有害・誤解を招く広告のリスクを減らす保護策も組み込んでいる。
18歳未満とセンシティブな話題では表示しない
テスト期間中、18歳未満と判明しているまたは予測されるアカウントには広告が表示されない。また、健康やメンタルヘルス、政治といったセンシティブまたは規制対象の話題の近くにも広告は表示されない設計である。これは、広告がユーザーの信頼を損なわないようにするための重要な仕組みだ。
ユーザーに提供される広告管理の選択肢
ChatGPTでは、広告に対してユーザーが細かく制御できる仕組みが用意されている。広告を見たくない場合は、PlusまたはProプランにアップグレードする方法と、無料プランのまま1日の無料メッセージ数を減らす代わりに広告を非表示にする方法の2つが提供される。
広告コントロールパネルの機能
設定画面からは次の操作が可能である。広告を閉じる、フィードバックを送信する、なぜその広告が表示されたのか理由を確認する、ワンタップで広告データを削除する、広告のパーソナライズ設定を管理する。
● インタレスト（推定される興味関心の確認）
● 広告データの削除（ワンタップで全消去）
● パーソナライズ設定（オン / オフ切替）
● 過去のチャットとメモリの使用（許可 / 不許可）
このパネルはChatGPTの設定内に組み込まれており、数タップで広告の表示有無やパーソナライズのオンオフを切り替えられる。一般的なSNS広告の設定画面よりも項目が整理されており、非エンジニアでも迷わず操作できる設計だ。
地域拡大のロードマップと日本市場への示唆
OpenAIは段階的にテスト地域を拡大している。2026年2月の米国を皮切りに、3月にはカナダ、豪州、ニュージーランドでのパイロットが開始された。そして5月の発表で、英国、メキシコ、ブラジル、日本、韓国の5カ国に拡大する計画が明らかになった。
地域ごとに異なる広告体験を学習する狙い
OpenAIの発表によれば、このパイロットの目的は「地域ごとに何が効果的かを理解し、拡大にあわせて体験を継続的に改善すること」にある。つまり単なる広告枠の販売ではなく、文化や商習慣の違いが広告の受け入れられ方にどう影響するかを検証する意図がある。
日本市場においては、LINEやYahoo! JAPANなどが提供するAIアシスタントとの競合が意識される局面でもある。ChatGPT上での広告が日本のユーザーにどのように受け止められるかは、国内でのサービス定着を左右する要素のひとつになるだろう。
広告主にとっての意味
OpenAIは企業向けに広告プログラムへの参加登録ページを公開している。現在は限定的だが、将来的には広告フォーマットの拡張や、目的別の広告購入モデルの追加が検討されている。とくにChatGPTの会話型インターフェースでは、ユーザーが「探している」タイミングで広告が表示されるため、検索広告とは異なる高いコンバージョン率が期待できると見られている。
対話型AIにおける広告の可能性と課題
OpenAIは今回のテストを「学習」の機会と位置づけている。広告が「役に立つ」と感じられ、ChatGPTの体験に自然に溶け込むかどうかを注意深く観察するとしている。初期の結果では、消費者の信頼指標に悪影響は見られず、広告の非表示率は低く、関連性は改善を続けているという。
会話型インターフェースならではの広告価値
ChatGPTのユーザーは、何かを積極的に調べたりアイデアを比較したり、意思決定に向けて動いている最中であることが多い。そうしたタイミングで表示される広告は、ユーザーが求める商品やサービスとの出会いを支援する可能性を持つ。OpenAIは「会話型インターフェースでは、広告がより関連性が高く有用になり、人々を新しい商品やサービスに自然な形でつなげられる」と述べている。
広告の独立性与信頼性の維持
ただし、AIアシスタントに広告を組み込むことへの懸念も根強い。ユーザーが「AIは中立的であるべき」と考える傾向があるためだ。OpenAIは「ChatGPTの回答は独立しており偏りがなく、会話は非公開に保たれ、人々は自分の体験を意味のある形で制御し続ける」という基本原則を、広告プログラムが拡大しても変えないと明言している。
この原則が実際に守られるかどうかは、今後の第三者監査やユーザーからのフィードバックの蓄積によって検証されていくことになるだろう。少なくともテスト段階では、広告が回答内容に干渉しないという設計は一貫している。
この記事のポイント
- ChatGPTの無料層で広告テストが始まり、日本を含む6カ国に拡大予定である
- 広告は回答内容に影響せず、会話データは広告主に非公開。プライバシー設計が明確だ
- ユーザーは広告の非表示やパーソナライズ設定の管理が可能である
- 対話型AIならではの広告価値が期待される一方、信頼性維持が最大の課題となる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
エージェントPRが急増中。レビューで見るべき5つの視点
テストが通り、コードもクリーンに見える。多くの開発者がそのプルリクエストを深く疑わずにマージしている。しかし、そのPRを書いたのは人間ではない。エージェントが生成したコードだ。そして、簡単に承認してしまうことこそが最大の問題である。
2026年1月に発表された研究「More Code, Less Reuse」によれば、エージェントが生成したコードは人間が書いたコードよりも変更あたりの冗長性と技術的負債が大きい。表面上はクリーンだが、負債は静かに蓄積される。さらに、同じ研究はレビュアーがエージェントのコードに対してむしろ積極的に承認したくなる傾向があることも指摘している。
これは開発速度を落とせという主張ではない。意図的かつ戦略的にレビューに臨むべきだという提言だ。エージェントのPRをどうレビューすれば、隠れた問題を見落とさずに済むのか。本稿では、GitHubのシニアデベロッパーアドボケイトであるAndrea氏が公開した実践ガイドをもとに、具体的なチェックポイントと効率的なワークフローを解説する。
エージェントPRの急増とレビュー負荷のギャップ
すでにプルリクエストの量は膨大だ。GitHub Copilotのコードレビュー機能はこれまでに6,000万回以上のレビューを処理し、1年足らずで10倍の規模に成長した。GitHub上のコードレビューの5件に1件以上がエージェントと関わっている。これは自動レビューの通過数に過ぎない。肝心のプルリクエストそのものは、レビュアーが処理できる速度をはるかに超えて増殖している。
従来の「レビュー依頼→コードオーナーが確認→マージ」というループは、1人の開発者が午前中に十数回のエージェントセッションを起動できる今、崩壊しつつある。スループットは指数関数的に伸びたが、人間のレビュー能力は変わっていない。そのギャップは広がる一方だ。
レビュアーが持つべき「コードを書いたのは誰か」の認識
diffの1行を見る前に、レビュアーは自分が何を確認しているのかをモデル化しておく必要がある。コーディングエージェントとは、生産的で字義通りに動き、既存のコードパターンを忠実に模倣する貢献者のような存在だ。しかし、そのエージェントには、自社のインシデント履歴も、チームが蓄積してきたエッジケースの知見も、リポジトリの外にある運用上の制約も一切ない。
エージェントは一見完成されたコードを生成する。だが、この「完成しているように見える」という状態が危険なのだ。コードが動き、テストも通る。それにもかかわらず、運用環境では破綻する。レビュアーこそが、そうした抜け落ちた文脈を埋める存在である。それは負担ではなく、レビューの本質的な仕事であり、自動化できない判断の部分だ。
エージェントPRで見るべき5つのレッドフラッグ
このデモは、エージェントのプルリクエストをレビューする際にまず確認すべき5つのポイントをまとめたものだ。各項目の詳細は以下で解説する。
1. CIの改ざん
エージェントはCIに失敗すると、テストを通すための明白な抜け道を選ぶことがある。テストの削除、リントステップのスキップ、テストコマンドに || true を追加するなどの行為だ。CIを弱体化させる変更は即座にブロックすべきである。
具体的には、カバレッジ閾値の変更、テストの削除やリネーム、スキップの追加、ワークフローがフォークやPRで実行されなくなっていないか、CIステップが新たな条件でゲートされていないか、を必ずチェックする。
2. 既存コードの再発明
これはレビュアーにとって最も費用対効果の高いチェックだ。エージェントはリポジトリ内のパターンを探し、それを複製する。同名の機能を持つ既存ユーティリティを確認せず、よく似た名前の新規関数を追加する。バリデーションロジックを複数箇所に再実装し、共有モジュールに既にあるミドルウェアをゼロから書き直す。こうした「ほとんど同じだが名前が違う」ヘルパーが生まれやすい。
エージェントのローカルコンテキストにはリポジトリ全体の見取り図が欠けている。レビュアーは新しく追加されたユーティリティやヘルパーをすべて検索し、重複があれば統合をマージ前に要求する。重複ロジックを放置すると、それが今後のエージェントにとっての「先行事例」になり、さらに複製が加速する。
3. うわべだけの正しさ
存在しないAPIを呼び出すような明らかな誤りはCIで検出される。深刻なのは、コンパイルが通り、すべてのテストを通過し、それでも間違っているコードだ。ページネーションのオフバイワンエラー、テストで決して通らないブランチでの権限チェック漏れ、エージェントが考慮しなかったエッジケースで短絡するバリデーション、大規模環境でのみ顕在化する競合状態などが該当する。
diffの中で最も重要なパスを選び、入力を出力まで追跡する。境界条件（ゼロ、最大値、空）や外部値のバリデーション漏れ、全ブランチの権限チェック、予期しない条件分岐を確認する。加えて、変更前の動作で失敗する新たなテストを要求すれば、理解不足や修正の不完全さを炙り出せる。
4. エージェントの沈黙と見せかけの反応
詳細なレビューを残しても、PRが沈黙してしまうケースがある。あるいはエージェントが要点を外した返信を繰り返し、堂々巡りになる。特に大きく構造化されていないPRでは、エージェントの放棄やミスアライメントが目立つ。レビュー時間を無駄にしないためにも、大規模なエージェントPRに深く入る前に、PRの履歴を確認する。
それまでのラウンドで応答性があったか、明確な実装計画があるか、エージェントがいきなりコードを書き始めただけではないかを見極める。計画がない場合は、以下のような定型文で分割や概要の提示を求める。これは個人攻撃ではなく、時間を節約するための率直な要求だ。
このPRは大きすぎて、明確な実装計画なしにレビューできません。
小さな単位に分割するか、各パートの目的と構造の意図をまとめてもらえますか。
その後、改めてレビューします。5. ワークフローへの信頼できない入力
CIエージェントへのプロンプトインジェクションは過小評価されている脅威だ。典型的なパターンとして、PR本文やIssue、コミットメッセージから内容を読み取り、それをプロンプトに展開し、モデル出力をシェルコマンドに流し込み、GITHUB_TOKEN権限で実行する流れがある。
LLMを呼び出すワークフローをレビューする際は、以下をブロッカーとみなす。信頼できないユーザー入力（PR本文、Issue本文、コミットメッセージ）が無害化されずにプロンプトに挿入されていないか。GITHUB_TOKENが書き込みスコープを持っているのに読み取りしか必要としていないか。モデル出力がバリデーションなしでシェルコマンドとして実行されていないか。シークレットがエージェントステップに渡されたりログに出力されたりしていないか。
マージ前に求めるべき対策は、ワークフローYAMLでの最小権限の原則（permissions: read-all をデフォルトに）、プロンプトに触れる前に信頼できないコンテンツのサニタイズとクォート、本番環境に触れる部分での「分析」と「実行」の分離と人間の承認ゲート、モデル出力の直接実行の禁止だ。
10分で完了する効率的なレビューワークフロー
上のフローは、GitHubのAndrea氏が提唱する時間枠付きのレビュー手順を図示したものだ。ポイントは、CIチェックを最優先し、重複検索を別工程で行い、最後に「証拠」としてのテストを要求することにある。
diffが5つ以上の無関係なファイルにまたがる、PRの目的を一文で説明できない、実装計画がない、CIが落ちていて変更点がテストファイルだけ、といった場合には、PRの縮小や計画の明確化を依頼する判断も必要になる。
Copilotに先にレビューさせるメリット
自動レビューは、機械的なチェックを人間に代わって処理するという、その得意分野で使うのが賢明だ。Copilotコードレビューは、スタイルの不一致、明らかなロジックエラー、エラーハンドリング不足、型の不一致などを自動検出する。これにより、低レベルの走査から解放され、レビュアーは判断を要する作業に集中できる。
自動レビューはあくまで前提条件であり、代替ではない。Copilotを最初に走らせ、明らかな問題があれば著者に修正させてから、人間のレビューに進む。チーム固有のカスタム指示を与えれば、CI閾値の変更をフラグ付けしたり、重複レビュー用に新しいユーティリティを表面化させたり、外部入力のバリデーションを確認したりといった調整も可能だ。
実際、Andrea氏はCopilot SDKを使って自分のレビューチェックリストをコード化し、管理エンドポイントの認証、テストの実効性、安全な環境変数処理といった観点を自動チェックするワークフローを構築したという。重大な問題が見つかればマージをブロックする仕組みだ。こうした自動化によって、レビュアーは真に価値のある判断業務に時間を振り向けられる。
この記事のポイント
- エージェント生成PRは表面上クリーンだが、冗長性と技術的負債を内包しやすい
- CIを弱める変更は即座にブロックし、テスト削除やカバレッジ操作を厳重に確認する
- 新規ユーティリティの重複検索を習慣化し、既存コードの再発明を防ぐ
- 最重要パスをトレースし、境界条件と権限チェックを目視で検証する
- CIエージェントへのプロンプトインジェクション対策として、ワークフローの最小権限化と入力サニタイズを徹底する
- Copilotコードレビューを先に実行し、機械的チェックを済ませたうえで人間の判断に集中する
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験