説得力のある文章を作成する上で、弁証法（Dialectic）は極めて高い有効性を発揮する構成手法ならびに思考フレームワークである1。従来の多くの論理的ライティング手法が一方向からの主張と正当化に依拠するのに対し、弁証法は自説に対する対立意見や矛盾をあえて取り込み、それを包含・昇華するプロセスを通じて結論を導き出す3。この動的な論理展開は、読者の抱く懐疑心や心理的抵抗を解消し、思考の深度と客観性を両立させた強固な説得力を生み出す3。

本報告では、弁証法が文章の説得力を高める認知論的・修辞学的メカニズムを解明し、文章構成としての基本構造（TASモデル）、領域別の適用パターン、既存の主要文章フレームワークとの比較、そして実務上の限界と実践的留意点について包括的に分析する。

1. 弁証法が文章の説得力を高める認知論的メカニズム

一方向的な主張を並べるだけの文章は、読者の内に潜む心理的抗拒（リアクタンス）や疑念を誘発しやすい3。読者は文章を読み進める際、無意識のうちに反論や例外事例を検索しており、著者が自身の都合の良い情報だけを提示していると感じた瞬間に説得への警戒感を強める3。弁証法的ライティングが強力な説得力を持ち得る根本的な理由は、この読者の思考プロセスを先回りし、自説の弱点や対立視点を文章内で可視化・検証する構造を備えている点にある1。

文章内で反対意見を提示する行為（反命題の導入）は、一見すると自説の威力を弱めるように思われがちだが、実際には認知的な信頼性を大幅に高める効果をもたらす3。自身の主張の限界や想定される反論を正確に言語化し、正当に評価する姿勢を示すことで、著者は客観的かつ不偏不党な分析者としての立場を確立できる5。

さらに、単なる賛否の並列にとどまらず、双方の対立軸を乗り越える高次の結論を提示するアプローチは、読者の認知的な視野を拡張させる3。読者は受動的に説得されるのではなく、著者が提示する問いと反論の葛藤を経由することで、自らが能動的にその結論へと到達したかのような認知的な納得感を得ることができる3。このように、弁証法は対立を回避するのではなく、論理的発展の原動力として活用することによって、文章に多層的な深みと説得力を付与する3。

2. 弁証法的文章構成（TASモデル）の基本構造と止揚（アウフヘーベン）の本質

弁証法を文章表現に応用する際、標準的フレームワークとして用いられるのが「テーゼ・アンチテーゼ・ジンテーゼ（Thesis-Antithesis-Synthesis: TAS）」モデルである3。ヘーゲル弁証法に由来するこの概念モデルは、文章内において初期主張の提示、対立視点による否定、そして高次元での統合という動的な論理展開を可能にする2。

論理の出発点となるテーゼ（正・初期命題）は、著者の主張や、世間で広く受容されている通説・現行方針を明示する段階である1。ここでは後続する対立構造を明確にするため、主張の根拠や前提条件をあいまいさなく明確に言語化することが求められる1。

続いて配置されるアンチテーゼ（反・反命題）は、テーゼに対する論理的な反論、不備、矛盾点、あるいは直面する課題を明示する段階である1。重要なのは、テーゼそのものを感情的に全面否定するのではなく、テーゼが依拠する前提の限界や特殊な状況下での破綻を突き止めることにある4。質の高いアンチテーゼを構築するために意図的に反論を育てる「レッドチーム思考」や批判的思考を取り入れることが、文章全体の議論の質を高める4。

論理展開の到達点であるジンテーゼ（合・統合命題）は、テーゼとアンチテーゼの対立を解消し、より高次の次元で双方を昇華・統合した結論である3。この統合を可能にする思考プロセスが「止揚（アウフヘーベン）」である2。アウフヘーベンは、テーゼとアンチテーゼの表層的な矛盾を捨て去りつつも、双方が持っていた本質的な価値や正当性を肯定・保存し、新たな思考のパラダイムへと高める役割を果たす2。

実践的な文章作成において極めて注意すべき点は、ジンテーゼを「安易な足して二で割るような折衷案」や「無難な妥協」に陥らせないことである4。単なる両論併記や中庸の模索は文章の主張をあいまいにし、かえって説得力を著しく低下させる4。真のジンテーゼは、対立する二項対立を超克し、「いかなるメカニズムや構造変更を行えば、双方の本質的価値を同時に実現できるか」という問いに対する構造的な解答でなければならない4。

3. 領域別における弁証法的ライティングの適用展開

弁証法は、学術論文、思想的情報発信（ソートリーダーシップ）、ビジネス提言など、多様な領域において異なる目的と様式で適用されている1。

学術論考・アカデミックライティング

法学や倫理学、社会科学分野の論考において、弁証法は特定の問いに対する妥当性を検証する骨組みとして厳格に用いられる2。例えば、法学エッセイでは現行の判例や解釈（テーゼ）を提示した後、学説や具体的事例に基づく問題点（アンチテーゼ）を挙げ、双方の法的保護利益を最大化する新たな解釈論（ジンテーゼ）を提示する形式がとられる2。議論の公平性と客観的な実証性が重視されるため、アンチテーゼには客観的データや文献に基づく強固な証拠が不可欠とされる1。

ソートリーダーシップ・コンテンツマーケティング

ビジネスにおける思想的影響力の確立を目的とした文章では、業界の常識（テーゼ）に疑問を投げかけ、新たな市場潮流や手法（ジンテーゼ）を提案する戦略的ツールとして弁証法が機能する3。例えば、「生成AIによる即座の執筆は生産性を高める（テーゼ）」という一般的認識に対し、「AI生成への安易な依存は独自の思考力を弱小化させ、長期的価値を損なう（アンチテーゼ）」という課題を突きつける3。その上で、「人間が思考の方向性と判断力を確定した後の推敲段階でAIを活用する（ジンテーゼ）」という指針を示すことで、単なるAI肯定論・否定論を超えた深い示唆を提供し、筆者の専門性と権威性を際立達せる3。

ビジネス提案・コンサルティング報告書

クライアントや組織内での意思決定を促す提言文書において、弁証法は抵抗の強い組織的対立を解きほぐす手法として活用される4。既存の経営方針（テーゼ）を全面的に否定すると関係者の反発を招くが、その方針が策定された背景や合理性をまず受容（テーゼの肯定）した上で、市場環境の変化に伴う定量的・構造的リスク（アンチテーゼ）を提示する4。最終的に、既存の強みを継承しつつリスクを克服する新たな戦略ロードマップ（ジンテーゼ）へと誘導することで、利害関係者の合意形成を極めて円滑に推進することが可能となる4。

4. 他の文章フレームワーク（PREP法・ピラミッドストラクチャー）との比較分析

文章構成には弁証法のほかにも、実務で頻繁に用いられる代表的なフレームワークが存在する9。文章の説得力を最大化するためには、それぞれの構造的特性と読者の状況に応じた使い分けが欠かせない3。

下記の比較表は、弁証法（TASモデル）、PREP法、ピラミッドストラクチャーの論理的特徴と最適な適用文脈を整理したものである。

PREP法は結論を最優先で伝える直線的な構造であり、迅速なコミュニケーションに適している反面、対立する視点を考慮しないため、読者がすでに異なる意見を持っている場合には反発を招きやすい3。ピラミッドストラクチャーは論理的根拠を過不足なく網羅・整理することに長けているが、静的な推論構造であるため、既存の思考フレームワークそのものを転換させるような動的な説得には必ずしも向かない3。

これらに対して弁証法は、主張に対する疑念や反対意見が存在することをあらかじめ前提としており、論理の中に「対話」と「発展」のプロセスを組み込んでいる点に定性的な違いがある3。したがって、読者が現状に安住している場合や、相反する論点が複雑に絡み合うテーマにおいて、他のフレームワークを凌駕する強力な説得力を発揮する3。

5. 弁証法的ライティングの限界と実践における留意点

弁証法は高度な説得力を提供する一方で、あらゆる文章作成に適用できる万能の手法ではない3。無批判な適用や誤った運用は、かえって文章の主張を曖昧にし、読者を混乱させるリスクを伴う4。

適用境界と不適切な文脈

純粋な手順説明や操作ガイドといった実用的なマニュアルコンテンツにおいて、弁証法を適用することは推奨されない3。このような文章の主目的は、読者に迷いなく特定のタスクを実行させることであり、対立概念や反論の提示は不必要な不確実性を生み出し、情報伝達の効率性を著しく損なう3。

二項対立への単純化と歪曲のリスク

現実のビジネス課題や社会問題は、複数の要因が複雑に絡み合っており、単純な「テーゼ vs アンチテーゼ」の2軸だけに集約できないケースが多い4。多角的な視点が存在する課題に対して無理に二元論を当てはめると、重要な第三・第四の論点が見落とされ、議論が浅薄化する危険性がある4。論点が多岐にわたる場合は、軸ごとに段階的な弁証法を展開するか、他の構造化ツールを併用する必要がある4。

妥協的統合の回避と意思決定の不可逆性

すべての対立がアウフヘーベンによって高次元に統合できるわけではない4。命題と反命題がトレードオフの関係にあり、本質的に両立不可能な場合、強引な統合を試みると論理の破綻した中途半端な折衷案が生成される4。止揚が極めて困難であると判断される局面においては、無理な統合を避け、論理的根拠に基づいてどちらか一方の立場を選択・決断する明確さが求められる4。

認知的負荷と論理密度の調整

弁証法的アプローチは、対立命題の検証と統合のプロセスを文章内で展開するため、必然的に文章の構成が長くなり、読者に相応の認知的負荷を要求する1。情報収集と推敲にかかる時間的コストも増大するため、迅速性が求められるビジネスのエグゼクティブ向けサマリーなどでは、導入部や結論部にジンテーゼを簡潔に示し、本文で弁証法的展開を行うといった階層制御が必要となる3。

6. 結論：高度な説得力を実現するための弁証法的思考の統合

弁証法は、説得力のある文章を作成するための思考法ならびに文章構成フレームワークとして極めて高い有用性を備えている1。その本質は、単なる自説の強弁を脱し、反対視点や構造的矛盾を論理の発展力へと転化させる動的な思考プロセスにある3。

文章内で弁証法を効果的に機能させるためには、まず議論の前提となるテーゼを明確に定め、それに対する不備や限界を示す質の高いアンチテーゼを意図的に提示することが求められる1。そして、表面的な対立に留まるのではなく、双方の根底にある本質的価値を保存しながら新たなパラダイムへと昇華させる「止揚（アウフヘーベン）」を達成することが、読者に深い納得感を与える要諦となる2。

単なる情報の整理や知識の伝達を超えて、読者の既存の認識を揺さぶり、自発的な合意形成や新たな意思決定へと導く高度なライティングにおいて、弁証法は欠くことのできない知的な駆動力であり続ける3。

引用文献

1. How to Write a Dialectic Essay With Explanations and Examples – Wr1ter, https://wr1ter.com/dialectic-essay
2. Full article: Essays as “clinical” pedagogy: a Hegelian approach to essay writing, https://www.tandfonline.com/doi/full/10.1080/03069400.2024.2422752
3. Persuasive Writing In Three Steps: Thesis, Antithesis, Synthesis – Animalz, https://www.animalz.co/blog/thesis-antithesis-synthesis
4. 弁証法的思考とは？テーゼ・アンチテーゼ・ジンテーゼで議論を昇華する技術 | コンサルノート, https://www.consulnote.com/articles/thinking/dialectical-thinking/
5. How to Write an Dialectic that is exclusive Essay Assignment and Sample – Casa College, https://www.casacollege.ac.cy/how-to-write-an-dialectic-that-is-exclusive-essay/
6. Thesis/Antithesis/Synthesis Structure in Presentations and Papers, https://research.cs.queensu.ca/home/cisc497/resources/ThesisAntithesisSynthesisFramework.pdf
7. How To Compose A Perfect Dialectic Essay? – Assignment Help – Allassignmenthelp.com, https://www.allassignmenthelp.com/blog/dialectic-essay/
8. 【ヘーゲルの弁証法とは？】具体例を使ってわかりやすく解説します | キタテン, https://kita-tenkara.com/2021/10/benshoho.html
9. PREP法、ピラミッドストラクチャーの違いは？ 伝わる話し方の基本 058 – YouTube, https://www.youtube.com/watch?v=P43I-NzkGfo

API、専用UI、内蔵ブラウザ、クラウドブラウザ、拡張機能、Computer Useの違い

AIエージェントを使っていると、同じ「Webサイトを操作する」という作業でも、動き方が大きく異なることがあります。

あるときは画面を開かずに処理が終わり、あるときはChatGPTの中にWebページが表示されます。別の場面ではChromeが操作され、さらにデスクトップアプリまで動かされます。

この違いを理解するには、製品名ではなく、AIが利用している「操作経路」で分類する必要があります。

現在の代表的な操作経路は、次の6種類です。

重要なのは、これらが同じ技術の強弱ではないことです。それぞれ、操作対象、実行場所、人間の関与方法が異なります。

1．API・コネクタ：画面ではなくデータを直接扱う

最も構造化された操作経路が、APIやコネクタです。

たとえばAIがGoogle Driveのファイルを検索するとき、必ずしもGoogle Driveの画面を開いて検索欄へ文字を入力しているわけではありません。

次のように、サービスが提供するAPIへ直接問い合わせます。

AI
 ↓
コネクタ・API
 ↓
Google Driveのデータ

この方式では、AIは画面上のボタンや文字の位置ではなく、「ファイル名」「更新日時」「所有者」「本文」といった構造化データを扱います。

画面のデザイン変更による影響が小さく、処理速度と安定性に優れています。ClaudeもCoworkでは、利用可能なコネクタを最初に使い、コネクタがない場合にブラウザ操作へ進むという優先順位を説明しています。

ただし、APIで許可されている範囲が、そのままAIの能力の上限になります。

APIに「記事を取得する」機能しかなければ、記事の取得はできますが、公開状態の変更はできません。「更新する」「削除する」「公開する」といったAPIが用意されていれば、その操作も可能になります。

2．専用UI：APIを人間が操作するための小さなWebアプリ

ClaudeのInteractive Connectorなどは、API操作に専用画面を加えた仕組みです。

Claude
 ↓
専用UI
 ↓
コネクタ・API
 ↓
Asanaなどのサービス

利用者には、タスク一覧、チェックボックス、担当者選択、保存ボタンなどが表示されます。

見た目はWebアプリですが、AsanaやNotionの通常サイトをそのまま開いているわけではありません。APIで取得できるデータと、APIで許可された操作だけを扱う専用UIです。

つまり、専用UIは「APIの画面付き版」と表現できます。

API
＝AIがデータを操作する入口

専用UI
＝同じデータを人間が確認・操作する画面

Claudeでは、通常のテキスト型コネクタとは別に、会話内へ操作可能なUIを表示するInteractive Connectorが提供されています。管理者は、UIを表示するツール呼び出しだけを停止し、テキスト型のコネクタ機能を残すこともできます。

この方式は、普通のWebサイトを自動操作する機能というより、Claudeの中で動く専用業務アプリに近いものです。

3．内蔵ブラウザ：人間とAIが同じWebページを見る

ChatGPTデスクトップアプリの内蔵ブラウザは、通常のWebサイトをChatGPTアプリ内に表示する機能です。

ユーザーのPC
 └─ ChatGPTデスクトップアプリ
      ├─ 会話
      └─ 内蔵ブラウザ
           └─ 普通のWebサイト

専用UIとは異なり、Webサイト側がChatGPT専用の画面を用意する必要はありません。

WordPress管理画面、企業サイト、検索結果、Webサービス、localhost上の開発中ページなどを開けます。ユーザーとChatGPTが同じページを見ながら、複数タブの移動、ダウンロード、ログイン待ち、画面への注釈などを行えます。citeturn735389search2

内蔵ブラウザには、普段使っているChromeとは別のブラウザ状態があります。

したがって、Chromeでログイン済みのWebサービスへ、そのままログイン済み状態でアクセスできるとは限りません。必要に応じて、内蔵ブラウザ側でログインします。

この方式は、次のような共同作業に向いています。

人間がページを確認
 ↓
AIが入力・修正
 ↓
人間が結果を確認
 ↓
AIが続きを実行

一言で表せば、内蔵ブラウザは「AIと一緒に使うブラウザ」です。

4．クラウドブラウザ：Web作業をAIに委任する

ChatGPT Workのクラウドブラウザも、普通のWebサイトを操作します。

内蔵ブラウザとの違いは、ブラウザが動く場所です。

内蔵ブラウザ
ユーザーのPC内で動く

クラウドブラウザ
OpenAI側のリモート環境で動く

クラウドブラウザは、ユーザーと同じ画面で共同作業するためというより、Web作業をAIへ委任するために設計されています。

ユーザー
 ↓ 作業を依頼
ChatGPT Work
 ↓
クラウドブラウザ
 ↓
複数のWebサイトを調査・操作

クラウドブラウザの作業は、ユーザーが会話画面を離れたあともバックグラウンドで継続できます。追加情報や確認が必要な場面では一時停止し、Webサイトがログインを要求した場合には停止します。

両者の違いは、次のように整理できます。

内蔵ブラウザを「AIと一緒に使うブラウザ」とすれば、クラウドブラウザは「AIに任せるブラウザ」です。

5．ブラウザ拡張機能：普段使っているChromeをAIが操作する

内蔵ブラウザは独立したブラウザですが、ブラウザ拡張機能はユーザーが普段使っているChromeへ接続します。

ChatGPT・Claude
 ↓
Chrome拡張機能
 ↓
普段使っているChrome
 ├─ ログイン状態
 ├─ Cookie
 ├─ 開いているタブ
 └─ Chrome拡張機能

ChatGPTではCodex Chrome Extension、ClaudeではClaude in Chromeがこの分類に入ります。

ChatGPTの公式説明でも、通常のChromeプロファイル、ログイン済みセッション、開いているタブ、既存のChrome拡張機能が必要な場合には、内蔵ブラウザではなくChrome拡張機能を使うよう案内されています。

Claude in Chromeも、Chrome上のWebサイトを読み、クリックし、ページを移動するブラウザ拡張機能です。Claude Desktop、Claude Cowork、Claude CodeからChrome操作を開始できます。

内蔵ブラウザとの違いは明確です。

内蔵ブラウザ
＝AI専用の独立したブラウザ

Chrome拡張機能
＝人間が普段使うChromeへAIが参加する

ログイン済みサイトを扱いやすい一方で、メール、管理画面、決済情報など、Chrome内の情報へ到達できる範囲が広くなります。利用するサイトと操作権限を限定する運用が重要です。AnthropicもClaude in Chromeについて、Webサイトを直接操作することに伴う固有のリスクを説明しています。

6．Computer Use：ブラウザの外まで操作する

Computer Useは、APIやDOMではなく、OS上のユーザーインターフェースを操作します。

AI
 ↓
スクリーン・ウィンドウ
 ↓
マウス・キーボード操作
 ↓
デスクトップアプリ

対象はブラウザに限られません。

Word、Excel、ファイル管理、業務アプリ、設定画面など、画面と入力装置を持つアプリケーションを操作できます。

ChatGPTデスクトップでは、Computer Useにより、アプリ、ツール、ブラウザをまたいで、クリック、文字入力、ファイル移動などを実行できます。citeturn980500search3turn980500search17

Computer Useは、APIやコネクタが存在しないアプリにも対応できるため、最も汎用性があります。一方で、画面表示、ウィンドウ位置、ダイアログ、読み込み時間などの影響を受けやすくなります。

なお、Computer Useと「カーソルを奪うこと」は完全な同義ではありません。

OpenAIはMac向けのバックグラウンドComputer Useについて、AIが独自のカーソルを使い、人間の作業と並行して複数エージェントを動かせる構成を説明しています。一方、Windowsではアクティブなデスクトップを使用し、実行中に前面操作を占有する場合があります。実装方式とOSによって挙動が変わります。

6つの操作経路を一つの図にまとめる

全体構造は、次のようになります。

構造化されたデータを操作
│
├─ 1．API・コネクタ
│      画面を使わずデータを直接操作
│
├─ 2．専用UI
│      APIに人間向けの画面を追加
│
├─ 3．内蔵ブラウザ
│      AIと人間が普通のWebサイトを共有
│
├─ 4．クラウドブラウザ
│      普通のWebサイト上の作業をAIへ委任
│
├─ 5．ブラウザ拡張機能
│      普段使っているChromeをAIが操作
│
└─ 6．Computer Use
       OS上のアプリと画面を操作
│
画面そのものを操作

上にある方式ほど、データが構造化され、操作が限定されます。

下に進むほど、対象範囲が広がり、人間と同じ画面操作に近づきます。

実務では「最も構造化された経路」を優先する

AIエージェントへ仕事を任せるときは、最も高機能な方式を選べばよいとは限りません。

基本的な優先順位は次のとおりです。

1．API・コネクタで完結する
   → API・コネクタを使う

2．人間の確認や選択が必要
   → 専用UIを使う

3．同じWebページを見ながら進める
   → 内蔵ブラウザを使う

4．公開Web上の作業をまとめて任せる
   → クラウドブラウザを使う

5．普段のChromeのログイン状態が必要
   → Chrome拡張機能を使う

6．デスクトップアプリを操作する
   → Computer Useを使う

APIで処理できる作業にComputer Useを使うと、画面表示という余分な工程が増えます。

反対に、APIが用意されていない古い業務アプリでは、Computer Useが有効な選択肢になります。

重要なのは、「AIが何を操作しているか」ではなく、「どの経路を通って操作しているか」を確認することです。

まとめ

AIエージェントのWeb操作は、一種類ではありません。

ClaudeのInteractive Connectorは、APIで扱えるデータと操作を専用Webアプリとして表示する仕組みです。

ChatGPTデスクトップアプリの内蔵ブラウザは、人間とAIが同じ普通のWebサイトを見るためのブラウザです。

ChatGPT Workのクラウドブラウザは、リモート環境でWeb作業を実行し、ユーザーが離れたあとも処理を継続する委任型のブラウザです。

Chrome拡張機能は、普段使っているChromeのログイン状態やタブを利用します。

Computer Useは、ブラウザを越えてOS上のアプリケーションを操作します。

この分類を理解すると、AIがカーソルを動かす理由、ログイン状態を引き継げる場合と引き継げない場合、バックグラウンドで作業できる場合、画面変更に強い場合と弱い場合を、一つの構造で説明できます。

※本稿は2026年7月19日時点の公開情報を基に整理しています。各機能の提供範囲は、プラン、OS、地域、組織設定によって異なります。ChatGPTの新しいデスクトップアプリはChat、Work、Codexを統合しており、段階的に提供されています。

コネクタ/API、ファイル、ブラウザ、DOM、Computer Use、カーソル占有の違い

ChatGPTデスクトップアプリには、WorkモードとCodexがあります。画面を切り替えると名前は変わります。しかし、プラグイン、内蔵ブラウザ、Chrome拡張機能、Computer Useは両方から使えます。

結論から書きます。違いは、使える道具の一覧ではありません。仕事の中心を、調査や資料作成に置くか、コードベースとローカル作業に置くかです。本稿では、OpenAIの公式資料で確かめられる事実と、実際の挙動から推測できる範囲を分けます。

最初に名称をそろえる

OpenAIの公式クイックスタートは、ChatGPT側の実務向けモードを「Work」と表記しています。本稿では「Workモード」と呼びます。調査、分析、文書、プレゼンテーション、表計算、Sitesなどの作成が主な用途です。

Codexは、コードベースの文脈と開発者向けツールを使うソフトウェア開発の作業場所です。「旧Codex」という過去の機能名ではなく、現在のChatGPTデスクトップアプリに並ぶ作業領域として扱う方が実態に合います。

WorkモードとCodexの違い

Workモードは文書作成、Codexはプログラム開発、とだけ分けると不十分です。Workモードもコードやシェルを使います。Codexもブラウザ、コネクタ、文書作成を扱えます。差が出るのは、何を正本として仕事を進めるかです。

1．コネクタとAPIは両方で使える

Gmail、Google Drive、Slackなどのプラグインは、WorkモードとCodexの両方で使えます。プラグインには、手順をまとめたスキル、外部サービスにつなぐコネクタ、MCPサーバーなどが含まれます。

コネクタが外部サービスのAPIやMCPツールを呼ぶ場合、画面上の検索欄やボタンを一つずつ押す必要はありません。通常はシステムのマウスカーソルも使いません。

ただし、対象サービスにAPIがあるだけでは足りません。対応するプラグインやコネクタを入れ、認証を済ませ、必要なツールがChatGPTへ公開されている必要があります。「APIがあるから自動で使える」は誤りです。

2．ファイルとシェルは仕事の置き場所が違う

Workモードのコードとシェルは、管理された隔離環境で動きます。公開インターネットへの接続は、Web検索、プラグイン、リモートブラウザとは別に管理されます。調査結果から表や文書を作る仕事に向きます。

Codexは、選んだローカルフォルダを作業場所にします。ファイルを読み、書き換え、コマンドを動かし、テスト結果と差分を見ながら進めます。コマンドは無制限に動くわけではありません。サンドボックスが、書き込める場所とネットワークの範囲を決めます。

WordやExcelのファイルも、必ずアプリ画面を開くとは限りません。DOCXやXLSXをファイルとして直接読み書きできれば、カーソルは動きません。WordやExcelの画面固有の機能が必要になった時点で、Computer Useへ切り替わります。

3．内蔵ブラウザはAI用の作業場所

ChatGPTデスクトップアプリの内蔵ブラウザは、普段使うChromeとは別のブラウザプロファイルを持ちます。既存のChromeタブやログイン状態を自動では引き継ぎません。必要なサイトには、内蔵ブラウザ側でログインします。

WorkモードとCodexは、Browserプラグインを通じて内蔵ブラウザを開き、クリック、入力、画面状態の読み取り、スクリーンショット、結果の検証を行えます。ユーザーとChatGPTが同じページを見ながら進められる点が特徴です。

内蔵ブラウザを作った理由は、DOMを読むためだけではありません。普段のChromeから作業を分離し、権限、ダウンロード先、許可するサイト、開発確認をChatGPT側で管理するためです。なお、公式資料では内蔵ブラウザからのファイルアップロード自動化に制限があります。

4．Chrome拡張機能は普段のChromeを使う

Chrome拡張機能は、ログイン済みのChromeプロファイル、開いているタブ、社内ツールなどをChatGPTから使うための接続経路です。WorkモードとCodexのどちらからも起動できます。

デスクトップアプリから指示を出せば、必要に応じてChromeを使えます。同じ指示をChromeのサイドパネルへ入力し直す必要はありません。反対に、Webページを見ながらその場で質問したい場合は、Chrome側のパネルから始められます。会話はChatGPTアプリ側でも続けられます。

内蔵ブラウザとChrome拡張機能は、同じ機能の重複ではありません。前者は分離された作業場所です。後者は普段のログイン状態を使う接続口です。

5．DOMはブラウザそのものではない

DOMは、Webページ内の見出し、入力欄、ボタンなどを木構造で表す仕組みです。しかし、「ブラウザ操作はDOMだけで動く」と考えると実態から外れます。

OpenAIの公式資料は、通常のブラウザ操作について、ページを開く、クリックする、入力する、表示結果を見る、スクリーンショットを撮る、と説明しています。DOM、CSS、コンソール、ネットワーク通信を明示的に調べる機能は、Developer modeでChrome DevTools Protocolへのアクセスを許可した場合です。

したがって、DOMはブラウザが持つ情報源の一つです。DOMが存在するだけで、外部のAIが読めるわけではありません。拡張機能、ブラウザの権限、CDPなどの接続経路が必要です。

6．Computer Useとカーソル占有

Computer Useも、WorkモードとCodexの両方で使えます。コマンドや構造化された連携だけでは確かめられない画面を見て、アプリをクリックし、入力し、メニューをたどります。

Windowsでは、ChatGPTがポインターを動かし、文字を入力し、前面を使うと公式資料に明記されています。同じWindowsセッションを同時に使うのは難しくなります。

macOSでは、ユーザーが別の作業を続けながらComputer Useを背景で動かせると説明されています。ただし、「常に専用カーソルを使う」「ユーザーのカーソルを絶対に奪わない」という記述は確認できませんでした。カーソルの動きは観察材料ですが、内部方式を断定する証拠ではありません。

事実と推測を分ける

実務での選び方

• DriveやGmailの情報を集め、報告書や表を作る：Workモード
• ローカルのコードやWebサイトを直し、テストする：Codex
• 普段のChromeのログイン状態が必要：どちらかにChromeプラグインを追加
• 普段のChromeから分けて調査や確認を進める：どちらかにBrowserプラグインを追加
• Word、Excel、会計ソフトなどの画面を操作する：どちらかにComputer Useを追加

一つの仕事で複数の経路を使う場合もあります。Gmailコネクタでメールを探し、Chromeでリンク先を開き、ファイルをローカルへ保存し、Codexで内容を加工する流れです。WorkかCodexかを先に決めるより、正本がどこにあり、どの操作経路が必要かを見る方が迷いません。

セキュリティ上の注意

内蔵ブラウザはChromeプロファイルから分離されています。一方、Chrome拡張機能は普段のログイン状態へ接続します。便利さとアクセス範囲が同時に増えます。

• 必要なサイトだけ許可する
• 送信、購入、削除、権限変更は実行前に内容を見る
• 金融、医療、法務、企業機密を含む画面は開いたままにしない
• Webページに書かれた指示を、利用者の命令と同じものとして扱わない
• 普段のChromeが不要なら、分離された内蔵ブラウザを選ぶ

まとめ

WorkモードとCodexの差は、ブラウザやComputer Useの有無ではありません。両方が同じプラグイン群を使えます。

Workモードは、調査、分析、資料作成を中心に据えます。Codexは、コードベースとローカルファイルを中心に据えます。カーソルを占有するかどうかは、WorkかCodexかではなく、コネクタ、ファイル操作、ブラウザ、Computer Useのどれが選ばれたかと、OSの違いで決まります。

※本稿は2026年7月19日時点のOpenAI公式資料を基にしています。機能名、対応地域、プラグイン、権限の仕様は変わる場合があります。

OpenAI公式資料

• ChatGPT Quickstart
• Plugins
• Browser
• Chrome extension
• Computer Use
• Sandbox

次に読む

• AIエージェントは、どのようにブラウザやアプリを操作しているのか
• OpenAI Codexの非エンジニア向けユースケースレポート
• Claude Cowork と OpenAI Codex のユースケース調査レポート

API、DOM、オブジェクトモデル、Computer Useの違い

生成AIは、文章を作るだけの道具から、ブラウザや業務アプリを操作して仕事を進めるAIエージェントへ変わりつつあります。実際に使うと、AIが作業しているのにマウスカーソルが動かない場合と、カーソルが動いて自分の操作と競合する場合があります。

この違いは、何を操作しているかではなく、どの経路で操作しているかから生まれます。本稿では、AIエージェントの代表的な操作経路を整理します。

AIエージェントには4つの操作経路がある

1. コネクタやAPIによる操作
2. ブラウザ拡張機能による操作
3. アプリ専用アドインやオブジェクトモデルによる操作
4. Computer Useによる画面操作

上にある経路ほど、対象を構造化されたデータとして扱えます。下に行くほど、人間と同じ画面、マウス、キーボードに近づきます。

1．コネクタやAPIによる操作

Gmail、Google Drive、Slack、Notion、Microsoft 365などのサービスは、外部プログラムがデータを取得・更新するためのAPIを提供しています。AIに対応するコネクタがあれば、画面を開いて検索欄へ入力する代わりに、サービスと直接通信できます。

この方式は高速で、画面レイアウトの変更にも影響されにくく、通常はマウスカーソルを使いません。大量のメール検索、ファイル一覧の取得、データベース更新などに向いています。

2．ブラウザ拡張機能による操作

コネクタがないWebサイトでも、ブラウザ拡張機能を通じて操作できる場合があります。Webページは、人間には画面として見えますが、ブラウザ内部では見出し、文章、入力欄、ボタンなどの部品が階層構造として管理されています。この構造がDOM（Document Object Model）です。

DOMを利用できれば、AIは画面上の座標だけを推測せず、「ログインという名前のボタン」や「メールアドレス入力欄」を構造的に認識できます。そのため、システムのマウスカーソルを動かさずにクリックや入力を実行できることがあります。

ただし、ブラウザ操作を「DOMだけで動く仕組み」と説明するのは正確ではありません。実際のブラウザエージェントは、DOM、タブ情報、JavaScript、アクセシビリティ情報、ブラウザ内部の制御機能、スクリーンショットなどを組み合わせます。カーソルが動かない場合でも、ページ状態の確認に画像認識を使うことがあります。

3．アドインとオブジェクトモデルによる操作

WordやExcelはWebページではないため、通常のHTML DOMを持ちません。その代わり、文書、段落、表、セル、数式、グラフなどを構造化して扱うオブジェクトモデルがあります。

AIが専用アドイン、API、コネクタ、SDKを通じてこの構造へ接続できれば、画面上の文章やセルを一つずつクリックせずに読み書きできます。この場合も、通常はシステムカーソルを占有しません。

重要なのは、アプリにオブジェクトモデルがあるだけでは足りないことです。AI側に、その構造へ接続する経路が必要です。接続手段がなければ、WordやExcelであっても画面操作に切り替わります。

4．Computer Useによる画面操作

専用の連携手段がないデスクトップアプリでは、AIがスクリーンショットを取得し、画面上のボタンや入力欄を見つけ、マウスとキーボードで操作します。これは人間のパソコン操作に最も近い方式です。

1. スクリーンショットを取得する
2. 操作対象の位置を判断する
3. カーソルを移動してクリックする
4. キーボードで入力する
5. 再び画面を確認する

AIとユーザーが同じマウスとキーボードを共有するため、利用者には「カーソルを奪われた」と感じられます。対応範囲は広い一方、画面変更の影響を受けやすく、構造化された操作経路より速度と安定性が下がりやすい方式です。

カーソルの動きは手掛かりになる

ただし、カーソルの挙動だけで内部方式を断定することはできません。カーソルが動かなくてもスクリーンショットを利用する場合があり、ブラウザ内でも特殊な画面では画像認識へ切り替わる場合があります。カーソルの動きは有力な観察材料ですが、完全な証拠ではありません。

実務では構造化された経路を優先する

• 大量のデータを検索・更新する：コネクタやAPI
• WordやExcelを精密に編集する：専用アドイン、API、ファイル直接編集
• APIがないWebサービスを操作する：ブラウザ拡張機能
• 専用連携がないデスクトップアプリを操作する：Computer Use

一つの作業で複数の経路を併用することもあります。たとえば、メールをAPIで検索し、取得したURLをブラウザで開き、最後だけ人間が承認する流れです。

セキュリティ上の注意

ブラウザ、メール、文書を読めるAIエージェントには、プロンプトインジェクションのリスクがあります。Webページや文書に埋め込まれた命令を、AIが利用者の指示と誤認する可能性があるためです。

• 金融、法務、医療、企業機密を扱う画面では利用範囲を限定する
• 送信、購入、削除、公開などの確定操作は人間が確認する
• アクセス権限は作業に必要な範囲へ絞る
• 変更履歴や操作ログを残す

まとめ

AIエージェントは、可能な限りAPI、DOM、オブジェクトモデルなどの構造化されたインターフェースを使い、それだけでは完結しない部分を画面操作で補います。

判断の要点は、「そのアプリにAPIやオブジェクトモデルがあるか」だけではありません。AIがそこへ接続するためのコネクタ、アドイン、SDKを持っているかです。この視点を持つと、カーソルが動く理由、処理速度の違い、操作の安定性を一つの枠組みで説明できます。

※各製品の機能や対応範囲は更新されます。本稿は2026年7月19日時点の一般的な仕組みを整理したものです。

2026年7月9日、OpenAIは待望の「GPT-5.6ファミリー」を一般公開しました。今回のリリースは、単なる既存モデルの延長線上にはありません。AIが「指示を待つツール」から、複雑なタスクを自律的に完遂する「エージェント」へと決定的なパラダイムシフトを果たした瞬間と言えるでしょう。

特に、Microsoft 365 Copilot（Word, Excel, PowerPoint等）への全面的な統合により、AIはビジネスの現場で「複数のステップを要する曖昧な業務」を自ら計画し、実行する能力を手に入れました。一方で、この強力すぎる能力ゆえに、米国政府からの要請で一部の展開が制限されるという異例の事態も発生しています。OpenAIはこれに従いつつも、「制限が常態化すべきではない」と警鐘を鳴らしており、本作が持つ技術的重圧を象徴しています。

本記事では、フラグシップモデル「Sol Ultra」を中心に、この新しい知能の核心をテックジャーナリストの視点から紐解きます。

2. GPT-5.6「Sol Ultra」とは？：3つの階層と究極の推論モード

GPT-5.6ファミリーは、処理能力とコストのバランスに応じて「Sol（ソル）」「Terra（テラ）」「Luna（ルナ）」の3つの階層で構成されています。

最上位の「Sol」は、複雑な推論や科学研究を担う旗艦モデルです。特筆すべきは、このSolにのみ搭載された「Ultra」モードです。これは通常の1エージェントによる推論ではなく、後述する並列処理に膨大な計算リソースを投下する特殊設定であり、AIの限界を押し広げるための「究極の推論エンジン」として位置付けられています。

※価格はRequesty、ベンチマークはOpenAI公開値に基づく。

3. 動作メカニズムの核心：64人の「並列サブエージェント」

Sol Ultraの驚異的な精度の裏側にあるのが、進化した「マルチエージェントv2」システムです。

従来のAIは、どれほど強力でも単一の「思考の線」で回答を生成していました。しかしSol Ultraは、内部で最大64人の独立した「サブエージェント」を同時並列で起動させます。特筆すべきは、これらのエージェントが単に協力するだけでなく、**「敵対的監査（Adversarial Audit）」**を行う点にあります。

各エージェントは異なる数学的アプローチや論理構造を探索し、その過程で他のエージェントの推論に「循環論法はないか」「論理の飛躍はないか」といった厳しい監査をリアルタイムで繰り返します。この「多様な知能による議論と相互チェック」のプロセスこそが、単一モデルでは到達できなかった高度な信頼性を生み出しています。

4. 世紀の難問「サイクル二重被覆予想」の完全自律証明

Sol Ultraが世界を震撼させた最大のニュースは、数学界で50年来の未解決問題であった「サイクル二重被覆予想（Cycle Double Cover Conjecture）」の証明です。

1. 難問の背景: 1979年にポール・シーモアが提唱したこの予想は、グラフ理論における「難攻不落の砦」とされてきました。
2. 驚異のプロセス: OpenAIが用いたプロンプト戦略は極めて独特でした。「完全な証明が存在すると仮定せよ」「諦める前に少なくとも8時間は粘れ」という、AIに心理的（あるいは演算的な）粘り強さを強制するインセンティブ・メカニズムを採用。その結果、Sol Ultraは並列エージェントをフル稼働させ、わずか1時間足らずで完全な証明PDFを生成しました。
3. コミュニティの反応: 現在、数学者たちによる数日〜数週間にわたる検証が進められています。注目すべきは、今回の証明にLean 4のような形式化証明ツールが使われていない点です。専門家は「グラフ理論を扱える成熟した証明システムがまだ存在しないため」と指摘しており、AIが自然言語と数式のみで歴史的知見に貢献した可能性に、Hacker Newsなどの技術コミュニティは熱狂しています。

5. 強みと技術的限界：卓越した性能と「過剰記述」の罠

Sol Ultraは、特定の領域で他を寄せ付けない強さを誇りますが、ジャーナリスティックな視点で見れば、明確な死角も存在します。

強み

• 圧倒的なコード実行力: Terminal-Bench 2.1での91.9%は、複雑なOS操作やエラー復帰において「人間のエンジニア」に限りなく近づいたことを示しています。
• 科学的推論の深化: SecureBioベンチマークで前世代から9ポイント向上。特に「ヒト病原体（Human Pathogen）」に関する能力は68.4%と高く、一方で「ウイルス学（Virology）」は53.5%と、分野による差異が見られます。

弱点・注意点

• 「過剰記述（Overwriting）」の罠: 丁寧すぎる推論が災いし、出力トークンが冗長になり、コストと時間を浪費する傾向があります。
• 特効薬「Programmatic Tool Calling」: この弱点への対策として、モデルがJavaScriptを書き、隔離されたV8ランタイムで実行する機能が導入されました。データフィルタリングをスクリプトで行うことで、トークン浪費を最大63.5%削減可能です。
• 競合との差: SWE-Bench Proでは64.6%に留まり、競合のClaude Mythos 5（80.3%）に対し、15.7ポイントもの大差をつけられている事実は無視できません。

6. 実務での活かし方：賢い運用のための「3つのコツ」

GPT-5.6、特にSol Ultraを「宝の持ち腐れ」にしないための実戦的な運用ガイドを提案します。

1. ルーティングの最適化 安価なタスクはLuna、日常業務はTerraへ。Sol Ultraは「大規模なリファクタリング」や「検証困難な難題」にのみescalate（昇格）させる運用を徹底してください。
2. プロンプト・キャッシュの厳密な管理 本モデルでは「30分間の最小キャッシュ寿命」と「明示的なブレークポイント」が利用可能です。キャッシュ読み取りは90%オフになりますが、**「キャッシュ書き込み料金（通常の1.25倍）」**という新たな課金項目がある点に注意。頻繁に変更される文脈にはキャッシュを使わないのが賢明です。
3. 「max」と「ultra」の明確な使い分け 「max」は深い思考を求める際に、「ultra」は複数のエージェントによる並列調査が必要な際に使用します。Ultraはトークン消費が激しいため、Plus以上のプランで提供されるこの機能を、ここぞという場面に限定して投入するのがプロの技術戦略です。

7. まとめ：モデルを「選ぶ」時代へ

GPT-5.6 Sol Ultraの登場によって、AIは単なる「回答マシン」を卒業しました。それは、数学の未解決問題を1時間で解き明かし、隔離された環境で自らコードを実行して最適化を行う、自律的な「デジタル・パートナー」です。

私たちは今、AIを「使う」段階から、タスクの難易度とコストのバランスを冷徹に見極め、最適なモデルとモードを「選ぶ」段階へと進みました。Sol Ultraという強大な刃を正しく研ぎ、適切な局面で振るうことができるか。その「目利き」の力が、これからの知識労働の成否を分けることになるでしょう。

0. エグゼクティブサマリー

OpenAI Codexは、出発点としては「AIコーディングエージェント」です。ただし、2026年時点のCodexは、開発者だけの道具から、知識労働全般を扱う業務エージェントへ拡張されています。OpenAIは、Codexの週間利用者が500万人超であり、非開発者、具体的にはアナリスト、マーケター、オペレーター、デザイナー、研究者、投資家、銀行員などが利用者全体の約20%を占め、開発者より3倍超の速度で伸びていると説明しています。(OpenAI)

本レポートの結論は明確です。Codexの非エンジニア向け価値は、「コードを書けること」ではなく、散らばった業務素材を集め、整理し、判断可能な形にし、レビュー可能な成果物へ変換し、必要に応じて軽量ツールや自動化へ接続することにあります。

OpenAI Academyは、Codexを日常業務に使う基本形として、カレンダー、メッセージ、メール、ドキュメント、ダッシュボード、スプレッドシート、トラッカー、デッキ、議論履歴など、すでに存在する素材から、ブリーフ、週次報告、意思決定メモ、ローンチキット、財務レビュー、ワークフロー監査などを作る使い方を示しています。(OpenAI)

したがって、Codexを非エンジニアに説明する場合、「プログラミング支援ツール」ではなく、次のように説明する方が実態に近いです。

Codexは、業務の素材を集め、構造化し、レビュー可能な成果物に変換し、必要なら業務アプリや自動化まで作る、作業実行型AIエージェントである。

この見方を採用すると、ユースケースは大きく5分類できます。

1. 情報整理：Gmail、Slack、Calendar、Drive、Docs、PDF、会議録などから、重要事項、未対応事項、判断待ち事項を抽出する。
2. 成果物作成：メール、PPTX、レポート、メモ、提案書、比較表、FAQ、台本、記事構成などを作る。
3. データ処理：CSV、Excel、Google Sheets、ダッシュボード出力、アンケート、顧客データを整形・集計・可視化する。
4. 業務実行：会議後フォロー、CRM更新案、顧客対応、オンボーディング、イベント運営、ワークフロー監査を進める。
5. 軽量ツール化：ダッシュボード、レビュー画面、プランナー、プロジェクトボード、ギャラリー、簡易Webアプリを作る。Codex Sitesは、アイデア、分析、計画をダッシュボード、プランナー、レビュー用ワークスペース、プロジェクトボード、ギャラリー、軽量ツールに変換できると説明されています。(OpenAI)

1. 調査範囲と前提

本レポートでは、OpenAI公式ページ、OpenAI DevelopersのCodex Use Cases、OpenAI Help Center、OpenAI Academy、Axios、Reuters、TechRadarの記事を確認しました。一次情報として最も重視したのは、OpenAI公式の「Codex for every role, tool, and workflow」「Codex for almost everything」「Codex use cases」「Using Codex with your ChatGPT plan」「How to use Codex for everyday work」です。

調査対象は、次の4層に分けています。

第1層は、OpenAIが明示している公式ユースケースです。Gmail受信箱管理、Computer Use、フィードバック統合、CSV整形、表データ分析、PPTX生成、新入社員オンボーディング、学習レポート、日次ブリーフ、週次サマリー、意思決定メモ、月次財務レビューなどが含まれます。(OpenAI デベロッパー)

第2層は、OpenAIが示すロール別プラグインから展開できる職種別ユースケースです。Data Analytics、Creative Production、Sales、Product Design、Public Equity Investing、Investment Bankingなどが含まれます。OpenAIは、これらのロール別プラグインが62の人気アプリと110のスキルを含むと説明しています。(OpenAI)

第3層は、公式ユースケースを非エンジニア業務に展開した実務ユースケースです。営業、マーケティング、経営企画、財務、人事、総務、法務、教育、編集、構成、研究、行政、個人事業などが対象です。

第4層は、プライベート案件への応用です。家計、引っ越し、旅行、学習、読書、note・ブログ、家族手続き、健康ログ、買い物比較、副業案件管理などを含めます。OpenAI公式は主に業務利用を中心に説明していますが、Computer Use、Gmail、Calendar、Drive、Messages、ファイル操作、Sites、Automationsの性質を踏まえると、プライベート案件への応用は自然な拡張です。CodexはMacアプリやブラウザ、ローカルファイルをまたぐ作業を、クリック、閲覧、入力によって処理できると説明されています。(OpenAI デベロッパー)

2. Codexの現在地：開発者向けから知識労働向けへ

Codexはもともとソフトウェア開発を支援する道具として位置づけられていました。Reutersは、2026年2月にOpenAIがCodexのデスクトップアプリを発表し、ユーザーが複数のAIエージェントを長時間にわたり同時管理し、コードを使って情報収集や分析を行えるようにしたと報じています。(Reuters)

その後、OpenAIはCodexを「ほぼすべてのこと」に使える方向へ拡張しました。2026年4月の発表では、CodexがPC上のアプリを操作し、日常的に使うツールやアプリと連携し、画像を生成し、ユーザーの好みを記憶し、過去の行動から学び、継続的・反復的な仕事を担えるようになったと説明されています。(OpenAI)

Axiosは、Codexがオフィスワーカーに広がっている背景として、ドキュメント、メール、デッキ、ダッシュボードなどの作成が容易になった一方、それらの「職場の成果物」が各アプリ内に分断されている問題を指摘しています。Codexは、メール、カレンダー、文書、スプレッドシート、デザインアプリ、SlackやTeamsなどに接続し、重要な文脈を集める方向に進んでいると報じられています。(Axios)

この流れから見ると、Codexの価値は「生成」よりも「接続」にあります。単に文章やコードを作るだけなら、ChatGPT単体でも多くの作業は可能です。Codexの差分は、複数の素材、複数のアプリ、複数のファイル、複数の作業手順を扱い、実際の成果物まで持っていく点にあります。

3. 非エンジニア向けCodexの基本構造

非エンジニア向けにCodexを理解するには、次の4段階で捉えると整理できます。

3.1 入力

Codexに渡す入力は、プロンプトだけではありません。カレンダー、Gmail、Slack、Google Drive、Docs、Sheets、Notion、PDF、CSV、PowerPoint、スクリーンショット、会議録、CRM、ダッシュボード、ローカルファイル、ブラウザ上のページ、既存の業務メモなどが入力になります。OpenAI Academyは、Codexはカレンダー、メッセージ、メール、ドキュメント、ダッシュボード、スプレッドシート、トラッカー、デッキ、議論履歴などの実文脈がある仕事で有効だと説明しています。(OpenAI)

3.2 処理

Codexは、入力を読むだけでなく、分類、抽出、要約、表化、整形、比較、分析、可視化、ファイル生成、PPTX編集、Webページ作成、PC操作、定期実行を行います。Codex Use Casesには、Gmail返信案、Computer Use、フィードバック統合、CSV整形、表データ分析、PPTX生成、新入社員オンボーディング、学習レポートなどが並んでいます。(OpenAI デベロッパー)

3.3 出力

出力は、単なるチャット回答に限定されません。メール下書き、Google Sheet、Google Doc、Markdownレポート、PPTX、CSV、Excel、HTML可視化、ダッシュボード、意思決定メモ、ローンチキット、週次報告、月次財務レビュー、プロセス文書、軽量Webアプリ、共有URLなどになります。OpenAI Academyは、Codexが日常業務の入力を、レビュー可能なブリーフ、要約、デッキ、ワークブック、計画、プロセス文書に変換できると説明しています。(OpenAI)

3.4 レビューと承認

Codexの成果物は、人間のレビューを前提にした方が安全です。Gmailユースケースでも、Codexは返信ドラフトを作り、送信は人間が判断する設計が推奨されています。(OpenAI デベロッパー)

したがって、非エンジニア向けCodex導入では、「完全自動化」よりも「レビュー可能な下書き」「比較表」「判断メモ」「承認前の作業キュー」を中心に置くべきです。

4. 公式に確認できる中核ユースケース

4.1 日次業務ブリーフ

OpenAI Academyは、日次業務ブリーフの用途として、カレンダー、未読メッセージ、未読メール、未対応フォローアップ、メモ、優先事項を入力し、優先順位、会議準備、返信が必要なメッセージ、判断待ち、FYI、アクションフラグを返す使い方を示しています。(OpenAI)

この用途は、非エンジニアにとって最もわかりやすい入口です。毎朝、Gmail、Slack、Calendar、Driveを横断して「今日見るべきもの」を作るだけでも、実務価値が出ます。

4.2 週次サマリー

OpenAI Academyは、週次サマリーとして、カレンダー、編集されたドキュメント、送信済みメッセージ、計画トラッカー、プロジェクトノートなどを入力し、完了事項、決定事項、変更点、ブロッカー、フォローアップ、次の優先事項、ソースリンクを含む更新情報を作る使い方を示しています。(OpenAI)

この用途は、管理職、個人事業主、コンサルタント、編集者、制作進行、営業責任者に向きます。

4.3 PPTX・スライドデッキ作成

Codex Use Casesは、既存プレゼンテーションの更新、新規デッキ作成、画像生成、レイアウトルール適用、スクリーンショット・PDF・参考デッキからの再構成を明示しています。Slidesスキルでは、PptxGenJSやレンダリング・検証スクリプトを使い、オーバーフロー、重なり、フォントチェックを行うと説明されています。(OpenAI デベロッパー)

この用途は、講師、営業、コンサルタント、広報、マーケター、構成作家、著者に特に有効です。

4.4 意思決定メモ

OpenAI Academyは、意思決定が内部エビデンス、外部調査、予算文脈、トレードオフに依存する場合、Codexにそれらを統合させ、推薦、根拠、トレードオフ、費用、リスク、未確認情報、ソースリンクを含む1ページの意思決定メモを作らせる使い方を示しています。(OpenAI)

これは、ユーザーが重視している「目的・制約から評価基準を作り、選択肢を調査・採点する」意思決定型プロンプトと極めて相性が高い領域です。

4.5 CSV・スプレッドシート整形

Codex Use Casesは、混在した日付形式、通貨表記、重複行、別名表記、貼り付けられた集計行などを含むCSVやスプレッドシートを、元ファイルを保持したままクリーンコピーへ変換する用途を示しています。(OpenAI デベロッパー)

これは、非エンジニアにとって最も実用的な用途の一つです。営業リスト、セミナー参加者一覧、アンケート結果、請求データ、顧客管理表などは、ほぼ必ず表記ゆれや欠損を含みます。

4.6 表データへの質問と可視化

Codex Use Casesは、CSV、スプレッドシート、ダッシュボード出力、Google Sheet、ローカルデータファイルに対して質問し、計算、チャート、表、短い要約、HTML可視化を作る用途を示しています。(OpenAI デベロッパー)

非エンジニアにとって重要なのは、「データ分析を依頼する」ではなく、「この表から何が言えるかを質問する」使い方です。

4.7 顧客フィードバック統合

Codex Use Casesは、Slack、GitHub、Linear、Google Driveなど複数データソースに接続し、フィードバックをGoogle Sheet、Google Doc、Slack更新、定期チェックにまとめる用途を示しています。(OpenAI デベロッパー)

この用途は、CS、マーケティング、商品企画、編集、行政の住民意見整理にも展開できます。

4.8 Gmail受信箱管理

Codex Use Casesは、Gmailを検索・トリアージし、返信が必要なメールを見つけ、送信済みメールやGoogle Drive内の文例を使って文体を合わせ、SlackやDriveの文脈を参照しながら返信案を作る使い方を示しています。(OpenAI デベロッパー)

これは、個人事業主、経営者、営業、士業、編集者に向く実用的な入口です。

4.9 Computer Use

Codex Use Casesは、Computer Useによって、CodexがMac上のアプリ、ウィンドウ、ブラウザセッション、ローカルファイルをまたぐ作業を引き受けられると説明しています。アプリUIを見て、クリックし、入力する作業に使えるとされています。(OpenAI デベロッパー)

この機能は、非エンジニアにとって「アプリをまたぐ雑務」の自動化につながります。旅行メモをMessagesから拾ってNotesへまとめる、Slack内の依頼をリマインダーへ登録する、ローカルファイルから資料を探す、といった使い方が考えられます。

4.10 新入社員オンボーディング

Codex Use Casesは、新入社員情報、オンボーディングトラッカー、チーム情報、Google Drive、Notionなどを入力し、トラッカー更新案、チーム別サマリー、Welcomeスペースの下書きを作る用途を示しています。(OpenAI デベロッパー)

この用途は、人事だけでなく、セミナー運営、コミュニティ運営、講座受講者管理にも転用できます。

4.11 学習レポート

Codex Use Casesは、研究論文や講座資料などの濃い素材を読み、サブエージェントに分担させ、背景用語、図表、主張、根拠、限界、未解決論点を含むMarkdownレポートを作る使い方を示しています。(OpenAI デベロッパー)

これは、研究者、講師、編集者、著者、コンサルタント、学生、個人学習者に有効です。

4.12 Sites・軽量Webアプリ

OpenAIは、Codex Sitesにより、アイデア、分析、計画を、ダッシュボード、プランナー、レビュー用ワークスペース、プロジェクトボード、ギャラリー、軽量ツールに変換できると説明しています。(OpenAI)

また、ChatGPT Businessのリリースノートでは、ChatGPT SitesがCodexアクセスのあるBusinessワークスペース向けにプレビュー提供され、ワークスペース内部で使う軽量なJavaScript/TypeScriptのWebアプリを作成・反復・デプロイできると説明されています。(OpenAI Help Center)

5. 非エンジニア向けユースケース全体マップ

以下では、公式に確認できる用途と、そこから自然に展開できる実務用途を、職種・生活領域別に整理します。

第1部：ビジネス・業務ユースケース

5.1 個人業務・管理職・経営者向け

この領域は、Codexの「情報横断」と最も相性がよい領域です。OpenAI Academyの日次ブリーフ、週次サマリー、意思決定メモ、ワークフロー監査の用途が土台になります。(OpenAI)

実務上は、「毎朝チェックして」「今週をまとめて」「未決事項を出して」という依頼だけでも有効です。ただし、良い出力には、何を重要と見なすか、誰の依頼を優先するか、どの範囲の資料を見るかを明示する必要があります。

5.2 メール・Slack・チャット対応

この領域は公式ユースケースが明確です。Gmail受信箱管理では、Codexが重要メールを探し、文体を合わせた返信案を作り、SlackやDriveから文脈を補う使い方が示されています。Slack、Gmail、Driveの横断利用も示されています。(OpenAI デベロッパー)

メール・チャット系の重要点は、送信や投稿の手前で止める設計です。Codexに「下書きまで」「送信前に確認」「削除やラベル変更は対象を限定」と指示すると、安全性と効率が両立します。Gmailユースケースでも、返信ドラフトはレビュー可能であり、削除などの破壊的処理は明示的で狭い指示にする方針が示されています。(OpenAI デベロッパー)

5.3 データ・表計算・レポート

CSVやExcelの整形・分析は、非エンジニア向けCodexの中核です。Codex Use Casesでは、CSVやスプレッドシートの混在日付、通貨表記、重複、欠損、別名表記、集計行を処理し、元ファイルを保持したままクリーンコピーを作る用途が明示されています。(OpenAI デベロッパー)

表データへの質問では、Codexに「列を確認してから分析」「根拠となる列を示す」「HTML可視化を作る」「欠損や結合できない行を別タブに出す」と指示すると品質が上がります。Codex Use Casesでも、列確認、計算、HTML可視化、ローカルプレビューの流れが示されています。(OpenAI デベロッパー)

5.4 財務・経営企画・投資

財務・投資領域では、表計算、文書読解、比較分析、意思決定メモの組み合わせが中心です。OpenAI Academyは、月次財務レビューとして、close workbook、ダッシュボード、サポートフォルダ、前月デッキ、財務メモを入力し、数値、変動要因、スピーカーノート、経営陣向け質問、前提、レビュー対象を含むレビュー資料を作る用途を示しています。(OpenAI)

投資領域について、OpenAIはPublic Equity Investingプラグインで、決算レビュー、企業比較、シグナル追跡、投資仮説の強弱評価を行えると説明しています。(OpenAI)

5.5 営業・カスタマーサクセス

営業・CSは、Codexのロール別プラグインで明示されている領域です。OpenAIはSalesプラグインについて、優先アカウントやシグナルの発見、顧客会議準備、フォローアップ、顧客レコード更新、クロージング計画、リスク案件レビューに使えると説明しています。(OpenAI)

OpenAI Academyも、Book of Business Prioritizationとして、CRM、通話記録、顧客メール、利用ダッシュボード、アカウントプラン、更新・成長シグナルから、優先アカウント、根拠、リスク・アップサイド、次アクション、フォローアップ案を作る用途を示しています。(OpenAI)

5.6 マーケティング・広報・クリエイティブ

OpenAIはCreative Productionプラグインについて、マーケティング・クリエイティブチームが、ブリーフをレビュー可能なアセットへ変換し、キャンペーンボード、ディスプレイ広告バリエーション、商品ライフスタイル画像、EC向け画像セットを作れると説明しています。(OpenAI)

OpenAI Academyは、ローンチキットの用途として、ローンチ計画、商品ノート、トラッカー、クリエイティブブリーフ、ステージングページ、チーム議論を確認し、レビュー用ブリーフ、顧客メール、社内発表、SNS投稿、2週間コンテンツ計画、代理店ブリーフ、ページ修正リスト、チーム状況更新を作る使い方を示しています。(OpenAI)

5.7 商品企画・UX・プロダクトデザイン

OpenAIはProduct Designプラグインについて、初期アイデアをチームがレビューできるプロトタイプに変換し、プロダクト方向性の探索、ユーザーフロー監査、ライブURLからのプロトタイプ作成、静止スクリーンショットのインタラクティブ化を支援すると説明しています。(OpenAI)

この領域では、Codexを「デザイナーの代替」と見るより、「レビュー可能な第1案を作る相手」と見る方が実務的です。

5.8 人事・採用・オンボーディング・社内運営

Codex Use Casesは、新入社員オンボーディングについて、承認済みの新入社員情報、トラッカー、チーム情報、Google Drive、Notionなどを使い、トラッカー更新、チーム別サマリー、Welcomeスペース下書きを準備する使い方を示しています。(OpenAI デベロッパー)

人事・採用領域では、個人情報、評価情報、機微情報の扱いに注意が必要です。Codex Use Casesのオンボーディング例でも、報酬、政府ID、住所、医療・障害、背景調査、移民関連、面接評価、業績メモなどを含めないようにする安全設計が示されています。(OpenAI デベロッパー)

5.9 資料作成・出版・講演・編集

PPTX生成、Docs整理、表・図・画像生成、記事管理は、Codexの非エンジニア用途として強い領域です。Codex Use Casesは、PPTXファイルをコードで直接編集し、画像生成とレイアウト検証を使ってスライド作成を自動化する用途を示しています。(OpenAI デベロッパー)

この領域で重要なのは、Codexに「最終文章」だけを頼むよりも、「素材管理」「構成」「表」「スライド」「画像指示」「投稿計画」まで任せることです。

5.10 調査・学習・ナレッジ化

Codex Use Casesは、研究論文や講座資料などの濃い素材を分担読解し、実行要約、用語集、図解、エビデンス表、注意点、未解決論点を含むMarkdownレポートへ変換する用途を示しています。(OpenAI デベロッパー)

この領域では、Codexに「資料を信じ切る」のではなく、「資料が主張していること」「こちらの解釈」「根拠が弱いところ」「追加確認が必要な点」を分けさせるのが重要です。Codex Use Casesの学習レポート例でも、論文を無批判に真実として扱わず、論文の主張と解釈を分け、前提と追読資料を示す指示が含まれています。(OpenAI デベロッパー)

5.11 社内サイト・簡易アプリ・業務ツール化

Codex Sitesは、非エンジニアにとって非常に重要です。OpenAIは、Codexがアイデア、分析、計画を、ダッシュボード、プランナー、レビュー用ワークスペース、プロジェクトボード、ギャラリー、軽量ツールにできると説明しています。(OpenAI)

ここは、従来ならノーコード、スプレッドシート、Notion、Airtable、社内ポータルで行っていた領域です。Codexの特徴は、「作りたい画面」を自然言語で説明し、必要ならデータや資料から直接画面化できることです。

5.12 法務・コンプライアンス・リスク管理

OpenAIは、今後のロール別プラグインとしてLegalを挙げています。現時点で非エンジニア向けに現実的なのは、法的判断の代行ではなく、文書・証跡・論点の整理、レビュー前チェック、承認用資料の作成です。(OpenAI)

法務・コンプライアンス領域では、最終判断を専門家に残す設計が重要です。Codexには「判断材料の整理」「論点表」「確認リスト」「下書き」を作らせるのが実務的です。

5.13 研究・専門職・高度分析

Codexは、研究・専門分析にも広がっています。OpenAIは、NVIDIAの研究者が研究アイデア探索から機械学習インフラ向けスクリプト作成まで、実験ワークフローの高速化にCodexを使っていると説明しています。(OpenAI)

Axiosの記事でも、Stanford Graduate School of Businessの教授が、データ収集、統計分析、図表作成、論文更新などにコーディングエージェントを使った事例が紹介されています。一方で、手作業監査によりエラーも見つかり、専門家による監督が必要だったと報じられています。(Axios)

第2部：プライベート案件ユースケース

プライベート案件では、Codexは「個人秘書」「生活設計アシスタント」「家計分析係」「学習伴走者」「趣味制作スタッフ」「副業オペレーター」「個人用アプリ職人」として機能します。

OpenAIが公式に示すプライベート専用ユースケースは業務向けより少ないものの、Computer UseはMessagesアプリから旅行アイデアを探してNotesにまとめ、返信案を作る例を示しています。(OpenAI デベロッパー)

6.1 生活管理・個人秘書系

この領域では、Codexに「実行前に確認」「メールは下書き」「予定変更は候補提示まで」と指示するのが適切です。

6.2 家計・お金・支出管理

家計領域では、Codexは「診断」よりも「整理・可視化・比較」に向きます。判断は、人間側の目的、制約、評価基準に基づいて行います。

6.3 買い物・比較検討

買い物は、ユーザーの意思決定型プロンプトと非常に相性がよい領域です。Codexには、検索、表化、採点、根拠整理、購入前チェックリスト化を任せるとよいです。

6.4 旅行・外出・イベント

Computer Useの公式例にも、Messages内の旅行アイデアを探し、Notesへまとめ、返信案を作る使い方が示されています。(OpenAI デベロッパー)

6.5 学習・資格・読書

学習領域は、Codexの「濃い資料を読み、図表・用語集・根拠表に変換する」使い方とつながります。(OpenAI デベロッパー)

6.6 創作・発信・趣味プロジェクト

この領域は、構成作家、著者、講師、note執筆者に特に強いです。Codexは、単発の原稿作成より、素材台帳、連載管理、スライド化、画像指示、投稿計画のような「運用系」に効きます。

6.7 副業・個人ビジネス

副業・個人ビジネスは、会社の権限管理が少ない分、小さな業務アプリ化が進めやすい領域です。案件ボード、請求管理、顧客カルテ、投稿計画、売上ダッシュボードが典型です。

6.8 住まい・引っ越し・不動産

住まい領域は、評価基準が多く、感情が入りやすい領域です。Codexには、条件の分解、評価基準の作成、比較表、手続き表、費用試算を任せるのが適しています。

6.9 健康・運動・生活習慣

健康領域では、診断や治療判断を任せるのではなく、記録整理、時系列化、医師に伝えるメモ作成に限定するのが安全です。

6.10 家族・介護・教育

家族案件は、紙、メール、LINE、写真、PDFに情報が散らばります。Codexの「散らかった素材を構造化する力」が効きます。

第3部：職種別ユースケース整理

7.1 経営者・個人事業主

7.2 営業・CS

7.3 マーケティング・広報

7.4 経営企画・財務・管理部門

7.5 編集者・著者・講師・構成作家

7.6 行政・公共領域

行政領域では、Codexを「決定者」にするより、「根拠整理係」「不足資料検出係」「比較表作成係」として使うのが適しています。

第4部：導入優先度

8.1 最初に試すべきユースケース

最初に試すべきなのは、失敗しても影響が小さく、成果物を人間が簡単にレビューできるものです。

OpenAI Academyも、Codexを「散らばった入力から具体的な出力へ移す」使い方を示し、ソース素材、制約、レビュー期待、出力形式を与えることを推奨しています。(OpenAI)

8.2 プライベート案件で最初に試すべきもの

第5部：Codex依頼テンプレート

9.1 汎用テンプレート

【案件名】について、関連情報を整理してください。
目的は【目的】です。
外せない制約条件は【制約】です。
参照する入力は【Gmail／Slack／Google Drive／CSV／PDF／PPTX／URL／メモ】です。
出力は、1. 現状、2. 重要論点、3. 未対応事項、4. 判断が必要な点、5. 次のアクション、6. 確認が必要な情報、の順にまとめてください。
実行・送信・削除・投稿・予約・購入は、私の確認後にしてください。
根拠となったファイル、メール、表、リンクを示してください。

9.2 Gmail整理テンプレート

Gmailを確認し、返信が必要なメールを抽出してください。
返信が必要なもの、確認だけでよいもの、保留でよいものに分けてください。
返信が必要なものは、私の文体に近いドラフトを作ってください。
文脈が不足する場合は、Slack、Google Drive、過去の送信メールを参照してください。
送信はせず、ドラフトと判断理由だけ出してください。

9.3 Slackアクション抽出テンプレート

Slackの【チャンネル名】と私宛てメンションを確認し、私が対応すべき事項を抽出してください。
直接依頼、暗黙の依頼、期限があるもの、判断が必要なもの、単なるFYIに分類してください。
出力は、依頼内容、依頼者、期限、根拠メッセージ、推奨アクションの表にしてください。

9.4 CSV整形テンプレート

添付CSVを整形してください。
問題点は、日付形式の混在、通貨表記、重複、欠損、表記ゆれ、集計行の混在です。
元ファイルは保持し、クリーンコピーを作成してください。
変更した行、削除した行、判断が難しい行をログにしてください。
欠損値は推測で埋めず、Needs Reviewに分けてください。

9.5 意思決定メモテンプレート

【決めること】について、目的【目的】と外せない制約条件【制約】から評価基準を作成してください。
その基準に沿って、候補を調査・比較し、100点満点で採点してください。
出力は、評価基準、候補一覧、比較表、採点表、推奨案、リスク、追加確認事項に分けてください。
内部資料と外部調査は分けて示してください。

9.6 PPTX作成テンプレート

【テーマ】について、講演用PPTXを作成してください。
入力は、原稿、章立て、既存資料、参考画像です。
出力は、表紙、問題提起、全体構造、各論、演習、まとめ、CTAの順にしてください。
文字は編集可能なテキストとして残してください。
スピーカーノートを入れてください。
作成後、文字あふれ、重なり、フォント崩れ、図表の読みやすさを確認してください。

9.7 プライベート案件テンプレート

【プライベート案件名】について整理してください。
目的は【目的】です。
外せない条件は【制約】です。
入力は、メール、PDF、メモ、写真、CSV、URLです。
出力は、現状整理、比較表、優先順位、次にやること、確認が必要な点に分けてください。
予約、購入、送信、申請は、私の確認後にしてください。

第6部：注意点と限界

10.1 Codexは「判断者」ではなく「作業実行者」として使う

Codexは強力ですが、最終判断を委ねる設計は危険です。特に、財務、投資、法務、医療、採用、個人情報、外部送信、購入、予約、契約、削除を含む操作では、人間の承認を残すべきです。

Axiosの記事でも、研究用途でAIエージェントが多くの作業をこなした一方、データ収集やコーディングに誤りがあり、専門家による監督が必要だった事例が紹介されています。(Axios)

10.2 接続アプリと権限管理が成果を左右する

Codexは、Gmail、Slack、Google Drive、Google Calendar、Notion、Sheets、Slides、Figma、Canva、Salesforce、HubSpotなど、接続されるツールによって実用範囲が変わります。OpenAIは、BusinessやEnterprise/Eduのワークスペースでは、プラグインへのアクセスがワークスペースのアプリ制御やRBACに従うと説明しています。(OpenAI Help Center)

10.3 プランと利用上限に注意する

OpenAI Help Centerは、Codexの利用上限がプランに依存し、Codex、ChatGPT for Excel、Workspace Agentsの利用がagentic usage limitにカウントされると説明しています。小さなスクリプトや簡単な関数は少ない利用量で済む一方、大きなコードベース、長時間タスク、長い文脈を保持するセッションはより多く消費するとされています。(OpenAI Help Center)

10.4 データ制御と機密情報

OpenAI Help Centerは、Codexの一部機能が、記憶、長期継続、ツール連携により便利になる一方、それらの機能が保存・処理するデータ管理を確認する必要があると説明しています。また、Computer UseのスクリーンショットもChatGPTのトレーニングデータ制御の対象になると説明しています。(OpenAI Help Center)

プライベート案件では、医療情報、家計、家族、相続、税金、契約書、住所、学校書類などが入りやすいため、最初は機微性の低いメモ、公開情報、自作ファイルから試す方が安全です。

10.5 マルチエージェント疲れ

Axiosは、複数のAIワークストリームを同時に監督することで、精神的な負荷を感じるユーザーがいると報じています。(Axios)

これは重要な指摘です。Codexが複数タスクを並行実行できるほど、人間側には「タスク監督」「成果物レビュー」「承認判断」「例外処理」が増えます。したがって、最初から多くの自動化を走らせるより、レビューしやすい小さなタスクから始めるべきです。

第7部：Codex導入の判断基準

Codexを使うべき仕事には共通点があります。

11.1 向いている仕事

11.2 慎重に扱う仕事

第8部：本レポートの最重要結論

OpenAI Codexの非エンジニア向けユースケースは、単に「プログラミングができない人でもアプリを作れる」という話ではありません。それは一部にすぎません。

より本質的には、Codexは次の5つの機能を組み合わせたものです。

1. 情報を集める。
2. 構造化する。
3. 成果物にする。
4. 必要ならアプリ化する。
5. 型が固まれば自動化する。

この構造で見ると、非エンジニア向けの本丸は、コード生成ではなく、業務の途中工程の外部化です。

人間がやるべきことは、前提を置くこと、目的を定めること、評価基準を作ること、最終判断を下すことです。Codexが担うべきことは、資料を探すこと、表を整えること、候補を並べること、根拠を示すこと、下書きを作ること、レビュー可能な形にすることです。

これは、意思決定論の観点から見ると、非常に重要です。Codexは「答えを出す機械」ではなく、意思決定の前処理を高速化する機械です。

したがって、最も実務的な使い方は、次の一文に集約できます。

Codexに結論を丸投げするのではなく、目的・制約・評価基準を与え、情報収集・整理・比較・下書き・可視化・ツール化を任せ、人間がレビューして決める。

この設計にすれば、Codexは非エンジニアにとって、単なるAIコーディングツールではなく、業務、生活、学習、発信、副業、意思決定を支える「実行型アシスタント」になります。

本調査の結論を先に述べると、Claude Cowork は「非開発者を含む知識労働のデスクトップ実行基盤」として強く、OpenAI Codex は「ソフトウェア開発を中核にしつつ知識労働にも拡張し始めたエージェント基盤」として強い、という住み分けが最も実態に近いです。Claude Cowork はローカルファイル、デスクトップアプリ、スケジュール実行、プラグイン、プロジェクト記憶、モバイルからの遠隔指示に強く、レポート作成、リサーチ統合、ファイル整理、経費処理、法務ドキュメント処理のような“成果物中心”の業務に向いています。他方で OpenAI Codex は、CLI・IDE・デスクトップアプリ・クラウド・GitHub レビュー・SDK・MCP・クラウド環境を持ち、コード生成、PR レビュー、テスト、移行、長時間の自律実行に強く、さらに 2026 年時点ではレポート、スプレッドシート、調査、共有エージェントといった“開発起点で知識労働へ浸透する”方向が明確です。

ただし、両者の採用判断を「モデル性能」だけで決めるのは粗すぎます。導入成否を分けるのは、むしろ 実行場所、権限境界、監査性、既存ツール統合、評価設計 です。Claude Cowork はデバイス上ネイティブ実行と VM 実行を分ける設計を採用しますが、現在のヘルプセンター文書では Cowork 活動が監査ログ・Compliance API・データエクスポートで捕捉されない点、VM 内活動が EDR から見えない点が明記されています。OpenAI Codex はサンドボックス・承認ポリシー・クラウドコンテナ・Compliance API・企業向け保持ポリシーとの整合が比較的整理されていますが、品質問題の多くが「モデルの失敗」ではなく、作業ディレクトリ、権限、設定、AGENTS.md 構造、テスト不足といった環境設計の失敗として現れることを OpenAI 自身が繰り返し示しています。

したがって、組織導入の推奨は二段構えです。事業部門・オペレーション・法務・財務・総務・リサーチには Claude Cowork を、開発・データ・SRE・セキュリティには OpenAI Codex を主軸にし、共通する評価指標として「リードタイム短縮」「再作業率」「レビュー検出率」「ヒューマン承認率」「リスクイベント率」を置くのが現実的です。単一製品に全集約するより、役割別に最適化した二層構成の方が、2026 年時点の製品成熟度には合っています。これは両社の公式ユースケース、企業導入事例、管理・安全性文書を突き合わせると最も整合的な読みです。

概要と調査方法

本報告の調査対象は、Anthropic の Claude Cowork と OpenAI の Codex です。ここでいう Codex は、クラシックな 2021 年のコードモデルではなく、2026 年時点の Codex app / CLI / IDE extension / Cloud / SDK / Codex-powered workspace agents を含む現行プロダクト群を指します。Claude Cowork については、2026 年のヘルプセンター更新と製品ページを中心に読み、必要に応じて Claude Code・Managed Agents・業界別ソリューション文書を周辺情報として扱いました。OpenAI Codex については、開発者ドキュメント、製品ページ、企業事例、学術・安全文書を中心に整理しました。

調査の優先順位は、ユーザー指定どおり 公式ドキュメント・製品ページ → 主要論文・システムカード → 企業導入事例・ホワイトペーパー → 技術ブログ → GitHub 実装 → 報道 の順で置きました。日本語の一次情報が存在する箇所は Anthropic ヘルプセンター日本語版、OpenAI 日本語ページを優先し、存在しない部分のみ英語一次情報で補いました。

なお、前提上の注意があります。Claude Cowork の公開事例は、Codex よりも定量 KPI が少なく、成功事例の多くが質的説明に偏っています。 また、Claude Cowork 自体の一般公開 API は確認できず、プログラマブルな近縁物としては Claude Managed Agents が public beta として提供されています。したがって、本報告の「Cowork の programmatic 実装」部分は、Cowork の直接 API ではなく、Cowork と同系統の Anthropic エージェント基盤を使う代替実装として整理しています。

機能別ユースケース一覧

下表は、ユーザーが指定した観点に沿って、主要機能ごとに両製品の適合性、導入ステップ、必要リソース、リスクを比較したものです。ここでの「リスク」は、誤作動・情報漏えい・監査困難・過剰自律を含む総合評価です。各行の最終列で、どの判断が一次情報か、どこからが推論かを明示しています。

機能面を総括すると、Claude Cowork は「ローカル資料・ローカル作業・非技術部門の成果物作成」への最短距離であり、Codex は「リポジトリとワークフローを伴う継続改善」への最短距離です。ユーザーが挙げたコード生成、文書化、教育、研究、データ解析、テスト自動化、セキュリティのすべてを両者ともカバーはしますが、重心の置き方が違うため、比較軸は「できるか」ではなく「どの組織設計で安定するか」に置くのが適切です。

業界別ユースケース

下表では、業界別に「公式に近い証拠が厚いもの」と「機能から合理的に導けるが定量事例がまだ薄いもの」を分けてあります。証拠強度は High / Medium / Low で示し、Low は“能力からの妥当な推論”が中心です。

業界別に見ると、Claude Cowork は財務・法務・オペレーション・小規模事業・教育・研究者支援に早く刺さりやすく、Codex は開発・プロダクト・データ・ゲーム・レビュー自動化で深く刺さる構図です。医療・教育・カスタマー対応のような分野では、両者とも「単体のモデル能力」より、根拠提示、権限分離、専門家レビュー、データ境界の設計が導入条件になります。

技術的制約と実装パターン

Claude Cowork の最大の特徴は、デバイス上でネイティブに走るエージェントループと、コード/シェル実行用の隔離 Linux VM を分けていることです。会話処理、接続フォルダの読み書き、ウェブフェッチ、ローカル MCP サーバーはデバイス上で動き、コード実行は macOS では Apple Virtualization.framework、Windows では Hyper-V 上の Linux VM に分離されます。この設計は、ローカル成果物処理には向きますが、同時に Cowork 活動が監査ログや Compliance API に出ない、EDR が VM 内を見られない、VM が上がらないとシェル/コード実行が unavailable になるという制約も直接伴います。

OpenAI Codex はより多層です。CLI・IDE extension・app・cloud・SDK・app-server があり、CLI は Responses API を使って推論を回し、ChatGPT ログイン時は chatgpt.com 側、API キー時は api.openai.com/v1/responses 側を使います。ローカルでは OS レベルのサンドボックス、クラウドでは OpenAI 管理コンテナ、レビューでは Git リポジトリ前提、クラウドタスクでは setup フェーズのみネットワーク可能、agent フェーズは既定でオフラインという明確な境界があります。“実装可能性”は広いが、構成オプションも多いため、運用が雑だと品質低下がすぐ表面化します。

次の Mermaid 図は、両製品の実行経路を公式文書から再構成した概念図です。図そのものは説明用に簡略化していますが、権限境界と統合ポイントの理解には有効です。

flowchart LR
    U[ユーザー] --> D[Claude Desktop Cowork]
    D --> N[ネイティブ実行環境]
    N --> F[接続フォルダ]
    N --> W[ウェブ検索・ウェブフェッチ]
    N --> M[MCP・ローカルプラグイン]
    D --> V[隔離 Linux VM]
    V --> C[コード実行・シェル]
    C --> O[成果物出力]
    F --> O
    W --> O
    M --> O

flowchart LR
    U[ユーザー] --> A[Codex App / CLI / IDE]
    A --> L[ローカルサンドボックス]
    A --> CL[Codex Cloud]
    A --> S[App Server / SDK]
    L --> G[Git リポジトリ / Worktree]
    L --> MCP[MCP サーバー]
    CL --> E[Cloud Container]
    E --> P[Setup Script]
    E --> R[Tests / Lint / Review]
    G --> R
    MCP --> R
    R --> PR[Diff / PR / Inline Review]

技術制約の比較表

実装パターン

参照画面

実装の現場では、テキスト説明以上に UI の理解が重要です。以下の公式画面は、PDF 添付資料や社内説明資料にそのまま「参照図版」として有用です。ここでは画像そのものではなく、どの画面を見れば何が分かるか を整理します。

事例分析

公開事例を見ると、OpenAI Codex は 定量 KPI を伴う導入事例が比較的多く、Anthropic Claude Cowork は 部門別テンプレート・業界ソリューション・ウェビナー・導入ガイドが先行しています。これは製品の成熟度差というより、公開の仕方の差です。Anthropic は金融・法務・医療・中小企業向けに“役割別配布物”を強め、OpenAI は“顧客事例で採用効果を見せる”傾向が強いと言えます。

成功事例

失敗事例というより導入トラップ

Cowork と Codex について、公開された大規模インシデント級の「失敗事例」は多くありません。代わりに、両社はどこで失敗しやすいかをかなり正直に出しています。ここを拾う方が、導入レポートとしては有益です。

KPI の置き方

導入評価で見るべき KPI は、単純な「時短」だけでは不十分です。少なくとも以下の指標を置くと、モデルの派手なデモと実務価値を分けやすくなります。これは公開事例の測り方とも整合します。

• 生産性: 1 タスク当たり所要時間、1 人当たり PR 数、初稿作成時間、redlining 所要時間
• 品質: human review での差戻し率、欠陥検出率、テスト追加率、根拠リンク付与率
• 運用: 承認要求率、拒否率、再試行率、長時間タスク完遂率
• ガバナンス: 監視対象セッション比率、高リスク操作発生率、権限逸脱率
• 採用: MAU、継続利用率、テンプレート/プラグイン利用率

法的・倫理的考察

法務・倫理面では、「モデル能力」より「誰がデータ管理者/処理者か」「どの保持ポリシーがどの surface に効くか」 を精密に区別する必要があります。Anthropic は商用製品では customer data について processor として振る舞い、商用製品データをモデル訓練に使わないと明示しています。一方で、Cowork 個別の挙動としては、プロジェクトデータがローカル保存であり、Cowork タスク削除は履歴即時削除・バックエンド削除は 30 日以内というドキュメントが存在します。つまり、Anthropic 商用全般の privacy stance と、Cowork デスクトップ固有のデータフローは分けて読む必要があるということです。

OpenAI 側では、企業データは既定で学習不使用、保持期間の制御、API の zero data retention、EKM、DPA、SOC 2 / ISO 群が整備されています。Codex は ChatGPT サインインと API キーでデータハンドリング規則が切り替わり、Enterprise では retention / residency / Compliance API が効く一方、API キー認証時は API 組織の設定に従います。したがって、同じ Codex でもサインイン方式で統制面が変わる点は、IT 部門が最初に押さえるべき論点です。

倫理面で最大の論点は、両者ともに自律エージェント化によって「読み取り」と「書き込み」の境界が曖昧になることです。Anthropic は Cowork の安全文書で、読み取りツールと書き込みツールを分け、prompt injection は「信頼境界外の情報を読み取れ、かつ危険操作も可能」なときに成立しやすいと説明しています。OpenAI も Codex の cyber safety 文書で、高いサイバー能力に応じた safeguards を導入している一方、false positives が過剰監視を招く residual risk を認めています。したがって、完全自律より、限定自律＋人間承認＋狭い writable roots が現実解です。

説明可能性については、両者とも“完璧な説明可能性”を約束しているわけではありませんが、プロセス可視化はかなり重視しています。Cowork は進捗表示と steering を提供し、Codex は review pane、inline comments、thread history、turn items、tool activity を基盤にしています。ただし、可視化できることと、法的説明責任を満たせることは同義ではありません。医療・法務・金融では、最終判断責任は人間に残すという設計を崩さない方がよいです。公式事例でもこの前提は一貫しています。

導入時の最低ガバナンス要件を短く整理すると、次の 5 点が外せません。

• 権限は read-heavy / write-light で始める
• 業務テンプレート、レビュー基準、禁止事項を repo/project/skill に埋め込む
• 高リスク業務は 承認必須 にする
• 監査ログ、OTel、Compliance API のいずれかで 観測可能性 を持つ
• 導入部門ごとに 退出条件 を設ける。たとえば不正確率、差戻し率、エスカレーション率が一定基準を超えたら自律範囲を縮小する

代替技術比較と将来展望・推奨アクション

代替技術比較

Claude Cowork と Codex を比較するとき、競合は単なる LLM ではありません。GitHub Copilot、Cursor、Gemini Code Assist、さらに UiPath のような agentic automation / RPA 系 まで含めて見ないと、位置づけを読み誤ります。下表は用途・強み・弱み・導入単位の違いを整理したものです。

この比較から見える本質は、Claude Cowork は “knowledge worker desktop agent” 側、OpenAI Codex は “engineering-native agent platform” 側に立っていることです。GitHub Copilot と Cursor は Codex に近く、UiPath は Cowork の一部ユースケースと重なりますが、RPA 的統制をより強く持ちます。よって、業務部門に Cowork、開発部門に Codex、基幹自動化は RPA/agentic automation という三層配置が、多くの企業ではもっとも自然です。

将来展望

今後の大きな流れは、コーディングエージェントと知識労働エージェントの収束です。Anthropic は Cowork を Claude Code のアーキテクチャ拡張として位置づけ、金法務・医療・中小企業向けプラグインや connectors を増やしています。OpenAI は逆に Codex をソフトウェア開発から reports / spreadsheets / research / workspace agents へ広げ、知識労働側に侵入しています。つまり、両社は逆方向から同じ地平に向かっています。

研究課題としては、少なくとも四つあります。第一に prompt injection 耐性。Anthropic は browser use での防御研究を進めていますが、モデル層の防御は 100% ではないと自社で述べています。第二に 長期運用時のコード・ドキュメント腐敗。OpenAI の Harness engineering は、agent-first 開発で documentation structure と cleanup job の重要性を示しました。第三に 監査可能性の標準化。MCP、skills、app-server、Managed Agents のような接続・実行基盤は増えていますが、監査章の標準はまだ揃っていません。第四に 部門別評価指標の確立。医療・金融・教育のような高コンテクスト業務で、単なる時短ではない評価が必要です。

推奨アクション

最後に、導入前提がまだ固定されていない組織向けの推奨アクションを、優先順位順にまとめます。

• 役割で分ける
  1 つの製品で全社最適を狙うより、事業部門の成果物業務は Claude Cowork、開発・データ・レビューは Codex で切る方が失敗率が低いです。
• 最初のパイロットは “長い業務” を選ぶ
  10 分の作業を 8 分にするタスクではなく、契約 redlining、月次レポート、PR review、incident follow-up のような 1〜6 時間級のタスクを選ぶ方が差が出ます。
• テンプレートとガイドを成果物として先に作る
  Codex では AGENTS.md と docs 構造、Cowork では project instructions と plugin customization が先です。モデル選定より、ここが再現性を決めます。
• 権限は段階的に開放する
  Cowork は実行前確認から始める。Codex は read-only / workspace-write / on-request を初期値にする。
• KPI は productivity と governance を同時に置く
  所要時間短縮に加えて、差戻し率、承認率、監視対象率、再試行率、検出バグ数を追わないと、導入判断が楽観バイアスに流れます。

本件で情報が相対的に薄いのは、Claude Cowork の公開定量 KPI と、Codex の製造・教育・法務における純粋な単独事例です。そのため本報告では、そこを能力ベースの妥当推論として明示し、証拠強度を分けて扱いました。逆に、Cowork のデスクトップ実行特性と Codex の repo/cloud/approval 特性 は一次情報が厚く、導入判断に使える確度が高いと言えます。

0. 要旨

AIエージェント周辺の用語は「同じ階層の部品名」ではなく、脳・職務記述書・技能・道具・通信規格・外部サービス・認証情報が混在しており、大変わかりにくい状況です。

整理すると、AIエージェントは次のような階層構造で捉えると明瞭になります。

ユーザーの自然言語
↓
メインLLM
↓
目的・意図の解釈
↓
Agent / Plugin / Skill / Tool の選択
↓
内部処理 or 外部呼び出し
↓
MCP / API / Browser Use / Computer Use
↓
外部サービス・データ・別モデル
↓
結果の評価・統合
↓
ユーザーへの返答

人間・組織に例えるなら、次の構造です。

AI組織

社長
└─ メインLLM

社長の思考機能
└─ Reasoning

記憶
└─ Memory

部署
└─ Plugin

部長・専門管理職
└─ Agent / Subagent

熟練技能
└─ Skill

業務手順書
└─ Workflow

道具
└─ Tool

道具カタログ・発注仕様書
└─ Tool Definition

取引先接続規格
└─ MCP

取引先の担当窓口
└─ MCP Server / API

会員証・鍵・ログイン情報
└─ Connector

外部組織・外注先
└─ App / SaaS / DB / Image Model / Search Engine

1. 内部用途と外部用途の基本分離

まず、AIエージェントの構成要素は「内部用途」と「外部用途」に分けるべきです。

AI内部
├─ LLM
├─ Reasoning
├─ Prompt / Instruction
├─ Memory
├─ Skill
├─ Workflow
├─ Agent
├─ Subagent
└─ Plugin

境界層
├─ Tool Definition
├─ Tool
├─ Connector
├─ Browser Use
├─ Computer Use
└─ MCP Client

外部層
├─ MCP Server
├─ API
├─ SaaS / App
├─ Database
├─ File System
├─ Search Engine
└─ Other AI Model

この分離をすると、混乱の大部分が消えます。

Plugin、Skill、Agent は主に内部の仕事のまとめ方です。
MCP、Connector、API、Browser Use、Computer Use は外界との接続方法です。
App、SaaS、DB、画像生成モデルなどは外部の目的地・外注先です。

2. LLM と Reasoning の関係

LLM と Reasoning は並列ではありません。

正確には、

Reasoning ⊂ LLM

です。

LLM は大脳全体に近く、その中に言語理解、知識想起、推論、計画、評価、生成が含まれます。Reasoning はその中の「前頭前野的な機能」です。

LLM
├─ 言語理解
├─ 知識想起
├─ 推論
├─ 計画
├─ 評価
└─ 生成

したがって、

LLM = 大脳
Reasoning = 大脳内の前頭前野的機能

と見るのが自然です。

Reasoning を独立部品として扱うより、「LLM の中で目標達成・計画・検証に関わる機能」と捉えた方が構造的に整合します。

3. Tool Definition と Tool の違い

ここが非常に重要です。

Tool Definition はツールそのものではありません。

Tool Definition は、

{
  "name": "search_documents",
  "description": "契約書・社内規程・稟議書を検索する",
  "inputSchema": {
    "query": "string"
  }
}

のような、AIに向けた「能力の仕様書」です。

人間に例えると、

この部署は契約書検索ができます
この道具は売上データを取得できます
この外注先は画像生成ができます

というカタログです。

一方、Tool は実際に呼び出される能力です。

Tool Definition
↓
LLMが選択
↓
Tool実行
↓
内部処理 or 外部呼び出し

Tool の実体はさまざまです。

Tool
├─ 内部コード
├─ Python / TypeScript スクリプト
├─ Web検索
├─ Browser Use
├─ Computer Use
├─ MCP Server 呼び出し
├─ API 呼び出し
├─ DB検索
├─ 画像生成モデル
└─ 別LLM / Subagent

つまり Tool Definition は「仕様書・発注書・広告文」であり、Tool は「実際の能力」です。

LLM はユーザーの自然言語を解釈し、その意図に近い Tool Definition を選びます。したがって似たような Tool Definition が複数あると、誤って別のツールへルーティングする可能性があります。これは現在のAIエージェント設計における中核的な問題です。

4. Skill の定義

Skill は、単発の道具というより、再利用可能な業務手順・技能パッケージです。

OpenAI Codex の公式ドキュメントでは、Skill は「instructions, resources, optional scripts」を含み、Codex がワークフローを安定して実行するためのタスク特化能力として説明されています。また、Skill は SKILL.md を中心に、任意で scripts、references、assets を含める構造になっています。(OpenAI Developers)

Claude Code の公式ドキュメントでも、Skill は SKILL.md に指示を書き、Claude が関連すると判断したとき、または /skill-name で直接指定されたときに使われるものとして説明されています。さらに、Claude Code の bundled skills は固定ロジックではなく、プロンプトベースでClaudeに詳細指示を与え、Claudeがツールを使って作業を編成するものと説明されています。(Claude API Docs)

したがって、Skill の実体は次の混合物です。

Skill
├─ Prompt / Instruction
├─ Workflow
├─ Examples
├─ References
├─ Templates / Assets
└─ Optional Scripts

人間に例えると、

Skill = 小脳的な熟練技能 + 業務マニュアル

です。

たとえば、

契約書レビューSkill
DCFモデル作成Skill
議事録作成Skill
ピッチデック作成Skill
コードレビューSkill

は、それぞれ「毎回ゼロから考えるより、一定の型で進めるべき仕事」です。

5. Workflow の定義

Workflow は、Skill よりも「手順」に焦点があります。

Workflow
├─ Step 1
├─ Step 2
├─ Step 3
└─ Step 4

たとえば、あなたが提示した pitch-agent には次のような流れがありました。

1. Scope the ask
2. Write the situation overview
3. Pull data
4. Spread the peer set
5. Stand up the sponsor case
6. Build the rest of the model
7. Generate the football field
8. Populate the deck
9. Run deck QC

これは明らかに Workflow です。

Workflow は基本的には「業務手順書」です。
Agent は、その Workflow を読み、必要に応じて Skill や Tool を呼びます。

Agent
↓
Workflowを読む
↓
Skillを呼ぶ
↓
Toolを使う
↓
結果を評価する

6. Agent の定義

Agent は単なるプロンプトではありません。

Agent の本質は、

目的を理解する
↓
計画する
↓
実行する
↓
結果を評価する
↓
必要なら修正する

という フィードバック制御です。

したがって、Agent は次の要素を持ちます。

Agent
├─ Role
├─ Goal
├─ Workflow
├─ Tool Access
├─ Skill Access
├─ Guardrails
├─ Evaluation Criteria
└─ Execution Loop

人間に例えると、Agent は「部長」または「プロジェクトマネージャー」です。

社長 = メインLLM
部長 = Agent
社員 = Skill
道具 = Tool
取引先 = MCP Server / API

ここで重要なのは、Agent = Sub LLM とは限らないという点です。

Agent は次のどちらでも成立します。

パターンA:
メインLLM
↓
Agent用Prompt
↓
同じLLMが役割を演じる

パターンB:
メインLLM
↓
Subagent
↓
別のLLM呼び出し・別コンテキスト・別ツール権限

あなたが提示した pitch-agent 定義を見る限り、そこには model: の明示や、独立した実行プロセスを示す記述はありません。したがって、それ単体からは「サブLLMが入っている」とは断定できません。

より正確には、

pitch-agent = Agent定義ファイル

です。

中身は、

Pitch Agent
├─ Metadata
├─ Role Prompt
├─ Output Contract
├─ Workflow
├─ Guardrails
├─ Tool Permissions
└─ Skill Dependencies

です。

7. Subagent と Multi-Agent

Subagent は、Agent の中でも独立した実行文脈を持つものです。

Claude Code の公式ドキュメントでは、custom subagents は Markdown ファイルと YAML frontmatter で定義され、name、description、tools、model、skills、mcpServers、memory、background、effort などのフィールドを持てます。特に model は sonnet、opus、haiku、inherit などを指定可能で、デフォルトは inherit です。つまり、Subagent は別モデルを使うことも、親と同じモデルを継承することもあります。(Claude API Docs)

OpenAI Codex の公式ドキュメントでは、Codex は specialized agents を parallel に spawn し、その結果を1つのレスポンスに統合できると説明されています。また、Codex は明示的に依頼されたときにのみ subagent を spawn すると書かれています。(OpenAI Developers)

この点について、前の議論の一部は修正が必要です。
「ユーザーが意図的にマルチエージェントを作れない」という一般化は、現在のCodex公式情報とは合いません。正しくは、

製品・画面・権限・設定によって、
ユーザーがSubagent / Multi-Agentをどこまで制御できるかが異なる

です。

Multi-Agent の定義はこうです。

Multi-Agent
= 複数の独立したAgent実行文脈が存在する状態

単に Tool が複数あるだけでは Multi-Agent ではありません。

単一Agent
├─ Tool A
├─ Tool B
└─ Tool C

これは「社長が複数の道具を使っている」状態です。

一方、

Multi-Agent
├─ Research Agent
├─ Finance Agent
├─ Legal Agent
└─ Writer Agent

これは「複数の部長がそれぞれ考えて作業している」状態です。

8. Plugin の定義

Plugin は最も混乱しやすい言葉です。

現在の文脈では、Plugin は単なる外部API呼び出しではなく、配布可能な業務パッケージと見るのが適切です。

Claude Code の公式ドキュメントでは、Plugin system は skills、agents、hooks、MCP servers によって機能拡張する仕組みとして説明されています。(Claude API Docs)

OpenAI Codex の公式ドキュメントでも、Skills は reusable workflows の authoring format、Plugins は reusable skills and apps の installable distribution unit と説明されています。(OpenAI Developers)

つまり Plugin は、

Plugin
├─ Skill
├─ Agent
├─ Hook
├─ MCP Server設定
├─ Tool定義
├─ Prompt
├─ Resources
└─ Optional Scripts

をまとめて配布する単位です。

人間に例えるなら、

Plugin = 部署パッケージ

です。

たとえば、

Legal Plugin
Finance Plugin
Marketing Plugin
Data Plugin
Pitch Plugin

は、それぞれ

法務部
経理部
マーケティング部
データ分析部
投資銀行ピッチ部

に相当します。

部署には、部長、社員、マニュアル、外注先、使用許可された道具、社内ルールが含まれます。Plugin も同じです。

9. MCP、MCP Server、API、Connector の関係

ここも重要です。

MCP はプログラムではありません。
MCP は通信規格です。

Anthropic の公式ドキュメントでは、MCP は AIアプリケーションを外部システムへ接続するためのオープン標準として説明されています。(Claude API Docs)

OpenAI Codex の公式ドキュメントでも、MCP は外部ツールやコンテキストプロバイダーに接続する標準的な方法であり、MCP servers は tools、resources、prompts を公開できると説明されています。(OpenAI Developers)

したがって、

MCP = 規格
MCP Server = 規格を実装したプログラム
API = 外部サービスの窓口
Connector = クライアント側の認証・接続設定

です。

関係はこうです。

LLM / Agent
↓
Tool Definition
↓
MCP Client
↓
Connector
↓
MCP Server
↓
API
↓
External App / DB / Service

Connector は「電話帳」では説明が浅いです。より正確には、

Connector
├─ 接続先
├─ 認証情報
├─ OAuth Token
├─ 権限
├─ 利用者アカウント
├─ 有効/無効設定
└─ 利用可能なスコープ

です。

人間に例えるなら、

Connector = 会員証 + 鍵 + 契約情報 + Cookie + パスワード管理

です。

MCP Server 側は「能力」を公開します。
Connector 側は「このユーザーがその能力を使える状態」を保持します。

10. Prompt・Program・Data・Config の分解

あなたが最も知りたかった「それはプロンプトなのか、プログラムなのか、知識ファイルなのか」は、次のように整理できます。

Agent / Plugin / Skill の中身

├─ Prompt
│  ├─ Role
│  ├─ Instructions
│  ├─ Workflow
│  ├─ Guardrails
│  └─ Output Format
│
├─ Data
│  ├─ Knowledge
│  ├─ References
│  ├─ PDFs
│  ├─ Templates
│  ├─ Examples
│  └─ Assets
│
├─ Config
│  ├─ name
│  ├─ description
│  ├─ tool permissions
│  ├─ model selection
│  ├─ MCP server settings
│  ├─ connector settings
│  └─ invocation rules
│
├─ Program
│  ├─ scripts
│  ├─ hooks
│  ├─ validators
│  ├─ API wrappers
│  └─ MCP server implementations
│
└─ Model Runtime
   ├─ main LLM
   ├─ inherited model
   └─ separate subagent model

あなたが提示した pitch-agent は、ほぼ次の構成です。

pitch-agent

├─ YAML Frontmatter
│  ├─ name
│  ├─ description
│  └─ tools
│
├─ System Prompt
│  └─ "You are the Pitch Agent..."
│
├─ Output Contract
│  ├─ Excel valuation workbook
│  └─ Pitch deck
│
├─ Workflow
│  ├─ Scope the ask
│  ├─ Pull data
│  ├─ Build model
│  └─ Populate deck
│
├─ Guardrails
│  ├─ No external communications
│  ├─ Cite every number
│  └─ Stop and surface for review
│
└─ Skill Dependencies
   ├─ sector-overview
   ├─ comps-analysis
   ├─ lbo-model
   ├─ dcf-model
   ├─ pitch-deck
   └─ ib-check-deck

これはプログラム本体というより、宣言的なAgent定義ファイルです。

11. 複数Skillの逐次実行・同時実行

1つのプロンプトで複数Skillを指定した場合、挙動はランタイム次第です。

ただし構造的には、次の4パターンがあります。

パターン1: 逐次実行
/skill1
↓
/skill2
↓
統合

パターン2: 片方のみ実行
/skill1 または /skill2

パターン3: 両方を読み込んで一つの推論で処理
skill1 + skill2 の指示を統合

パターン4: 並列実行
skill1 ─┐
        ├─ 統合
skill2 ─┘

Skill の列挙だけでは並列実行は保証されません。

並列実行には、

Worker
Subagent
Task Scheduler
Parallel Runtime

のような仕組みが必要です。

Codex については、公式ドキュメント上、subagents を parallel に spawn して結果を集約できるとされています。(OpenAI Developers)

一方、あなたが提示した pitch-agent の定義だけを見る限り、Workflow は番号付きの逐次手順です。したがって、このファイル単体から読み取れるのは、主に逐次オーケストレーションです。

12. Tool選択ミスが起きる理由

Tool、Skill、Agent は、LLM が意味解釈によって選びます。

ユーザー指示
↓
LLMが意味を解釈
↓
Tool / Skill / Agent のdescriptionと照合
↓
最も近いものを選択

したがって、似たような定義があると誤選択が起きます。

悪い例です。

search_document
search_documents
search_file
search_files

境界が曖昧です。

良い例は、担当範囲を明確に分けることです。

search_contracts
契約書、NDA、覚書を検索する。社内規程や議事録には使わない。

search_policies
社内規程、就業規則、稟議ルールを検索する。契約書には使わない。

Tool Definition は単なる仕様書であると同時に、AI向けのルーティング広告文です。

人間の組織で言えば、

法務部: 契約・規制・リスク
経理部: 請求・仕訳・決算
営業部: 顧客・商談・売上予測

と部署名と担当範囲を明示するのと同じです。

13. 最終モデル

最終的に、AIエージェントの全体像は次のように表現できます。

AI Agent System

├─ Core Intelligence
│  ├─ LLM
│  └─ Reasoning
│
├─ Context Layer
│  ├─ Prompt
│  ├─ Instructions
│  ├─ Memory
│  └─ Project Guidance
│
├─ Capability Layer
│  ├─ Skill
│  ├─ Workflow
│  ├─ Agent
│  ├─ Subagent
│  └─ Plugin
│
├─ Interface Layer
│  ├─ Tool Definition
│  ├─ Tool
│  ├─ Browser Use
│  ├─ Computer Use
│  └─ MCP Client
│
├─ Connection Layer
│  ├─ Connector
│  ├─ OAuth
│  ├─ Permissions
│  └─ Auth Tokens
│
├─ Protocol Layer
│  ├─ MCP
│  └─ API
│
└─ External Layer
   ├─ MCP Server
   ├─ SaaS
   ├─ Database
   ├─ File System
   ├─ Search Engine
   ├─ Image Model
   └─ Other LLM

組織比喩に置き換えると、こうです。

会社としてのAI

├─ 社長
│  └─ LLM
│
├─ 社長の思考能力
│  └─ Reasoning
│
├─ 記憶・資料室
│  └─ Memory / Knowledge
│
├─ 部署
│  └─ Plugin
│
├─ 部長
│  └─ Agent / Subagent
│
├─ 熟練社員
│  └─ Skill
│
├─ 業務マニュアル
│  └─ Workflow
│
├─ 道具
│  └─ Tool
│
├─ 道具カタログ
│  └─ Tool Definition
│
├─ 会員証・鍵
│  └─ Connector
│
├─ 取引ルール
│  └─ MCP
│
├─ 取引先窓口
│  └─ MCP Server / API
│
└─ 外注先・外部組織
   └─ App / SaaS / DB / Model

14. 結論

この議論で到達した中心命題は次です。

AIエージェントとは、LLM単体ではなく、LLMを中心に、Prompt、Memory、Skill、Workflow、Agent、Tool、Connector、MCP、API、外部サービスを階層的に接続した業務遂行システムである。

さらに短く言えば、

LLM = 考える中枢
Skill = 定型能力
Workflow = 手順
Agent = 目的達成の管理職
Plugin = 部署パッケージ
Tool = 実行可能な道具
Tool Definition = 道具の仕様書
Connector = 利用者固有の鍵・認証情報
MCP = 共通通信規格
MCP Server = 能力提供プログラム
API = 外部サービスの窓口
App = 外部組織
Multi-Agent = 複数の管理職が独立文脈で動く組織

この整理の価値は、単に用語を覚えることではありません。

実務上は、

どこまでがPromptか
どこからがProgramか
どこにDataがあるか
どこで認証しているか
どこでLLMが判断しているか
どこで外部システムが動いているか
どこからMulti-Agentになるか

を切り分けられるようになります。

AIエージェントの設計とは、結局のところ「賢い脳を作ること」だけではなく、脳・技能・部署・道具・外注先・契約情報・通信規格をどう組織化するかという問題です。これは技術設計であると同時に、かなり組織設計に近い領域です。

1. 計算資源調達における戦略的パラダイムの対立と市場構造の変容

人工知能（AI）業界におけるフロントランナーであるOpenAIとAnthropicの計算資源（コンピューティング・キャパシティ）調達戦略は、単なるインフラ規模の競争を超え、テクノロジーの進化とビジネスモデルの根幹を揺るがす思想的対立へと発展している。

OpenAIは、スケーリング則（Scaling Laws）がもたらす知能の向上を絶対的な基盤とし、物理的なインフラと最新の半導体をどれだけ独占的に確保できるかが他社に対する決定的な参入障壁（モート）になると確信してきた¹。しかし、その膨大な要求は、単一のクラウドプロバイダーが単独で支えられる物理的・財務的限界を突破しつつある²。このため、OpenAIは長年維持してきたマイクロソフト（Microsoft）との独占的パートナーシップを再編し、IPのライセンス契約を非独占的へと変更した³。マイクロソフトは依然として27%の株式を保持しつつ、主にソフトウェア側の統合を担うが²、OpenAIはマイクロソフトのAzureサービスに2500億ドル、オラクル（Oracle）に3000億ドルの計算資源契約を割り当てるなど、複数の提携先を複雑に組み合わせる「協調的競争（コープティション）」へと戦略の舵を切った²。

こうしたインフラへの超巨額投資に伴い、OpenAIの財務的リスクは極めて深刻なものとなっている。同社は2026年単年で140億ドルの最終損失を計上すると予測されているが³、2028年までに累積損失が740億ドルに達した後に、2030年までに「NVIDIA並み」の収益力をもって黒字化するロードマップを投資家に提示している³。この膨大な支出軌道を維持するため、最高経営責任者（CEO）のサム・アルトマンがかつて唱えていた「1.4兆ドル」のインフラ調達構想は事実上リセットされ、2026年1月には2030年までのコンピューティング投資ターゲットをより現実的な「6000億ドル」に引き下げ、投資家向けの再説明を行っている³。

対照的に、Anthropicはハードウェアの自社所有を巧みに回避し、提携するクラウドベンダーとの関係を通じてシリコンの多様化とモデルの効率化に賭けている¹。同社は2026年5月に650億ドルのシリーズH資金調達（ポストマネー評価額9650億ドル）を完了させ、一時的に時価総額でOpenAIの8520億ドルを凌駕した⁴。Anthropicの年換算（ランレート）売上高は、2025年末の約90億ドルから⁴、2026年4月に300億ドル⁷、同年5月には470億ドルへと驚異的なスピードで急増しており⁵、2028年までに売上高700億ドルと170億ドルのフリーキャッシュフロー黒字化を達成するという、OpenAIに比べてはるかに健全な財務モデルを確立している⁴。

さらに、米国のエンタープライズAI市場における支出シェアにおいて、Anthropicは40%へと急伸したのに対し、OpenAIは50%から27%へと大きくシェアを落としており⁹、これがOpenAIにとって企業向けコードツールやセキュアなインフラ提供に注力する「警鐘（ウェイクアップ・コール）」となった⁹。

以下の表1は、両社の財務基盤と長期インフラ支出計画、および市場での位置づけを定量的にまとめたものである。

評価項目	OpenAI（マイクロソフト/Oracle/ソフトバンク連合）	Anthropic（AWS/Google/SpaceX連合）
最新の資金調達額	（2026年3月）6	（2026年5月、シリーズH）4
ポストマネー評価額	[cite: 6]	4
売上高ランレート	約 （2026年Q1時点）6	約 （2026年5月時点）5
2028年の財務予測	の累積赤字予測4	売上 、フリーキャッシュフロー 4
2030年までのインフラ投資枠	最大 （2026年1月改定）3	AWSへ 超7、国内に 7
米エンタープライズ支出シェア	27%（旧50%から下落）9	40%（急増）9

2. OpenAIの「スターゲイト」計画と垂直統合型ハードウェアスタック

OpenAIのインフラ調達を象徴する「スターゲイト（Stargate）」計画は、オラクルおよびソフトバンクを巻き込んだ共同事業であり、当初の計画から大幅にスケールアップして全米各地で合計5000億ドル、10ギガワット（GW）におよぶインフラの確保を目指している²。現在確定または開発中のサイト（テキサス州アビリーンの主力拠点、およびCoreWeaveとの協働プロジェクトを含む）の合計で、今後3年間で約7 GWの容量、4000億ドル以上の投資枠が具体化している¹⁴。

このインフラを支える最大の技術的バックボーンが、オラクルの提供するクラウドAIスーパーコンピューター「OCI Zettascale10」である¹⁷。アビリーン・キャンパスに配備されたこの超巨大システムは、最大80万個のNVIDIA製GPUを相互接続し、ピーク性能16 ZettaFLOPSという天文学的な演算出力を提供する¹⁷。この接続システムには、オラクル独自のRoCEv2（RDMA over Converged Ethernet）技術である「Acceleron」ネットワークアーキテクチャが採用されている¹⁷。

Acceleronは、各GPUのネットワークインターフェースカード（NIC）を小型スイッチ（ミニスイッチ）として機能させ、物理的・論理的に独立した複数のスイッチングプレーン（平面）に同時並列接続する独自の設計を有している¹⁷。これにより、従来の3階層接続構造からネットワーク階層を削減し、GPU間のデータ遅延を著しく低減するとともに、ある通信経路が不安定になっても自動的に別プレーンにルーティングを切り替えて処理を中断させない「耐障害性（レジリエンス）」を備えている¹⁷。さらに、リニアプラガブル光モジュール（LPO）やリニア受信光コンポーネント（LRO）の導入により、400G/800Gの超広帯域を維持したまま、ネットワークのエネルギー消費と冷却コストを劇的に圧縮し、配分された電力エネルギーの大部分を演算（コンピューティング）そのものに直接集中させることに成功している¹⁷。

また、マイクロソフトとの非独占的な協力を受け、Azure上にも世界初の「NVIDIA GB300 NVL72」をベースとするスーパーコンピューティングクラスターが実装された²⁰。これは単一VMとして動作し、4,600個以上のBlackwell Ultra GPUを接続している²⁰。各ラックは72個のGPUと36個のGrace CPUから構成され、第5世代NVLinkスイッチを介して130 TB/sという想像を絶するラック内通信帯域を提供するとともに、Quantum-X800 InfiniBand（各GPU 800 Gb/s）によってラック間を相互接続している²⁰。

半導体の調達多様化を目指し、OpenAIはリチャード・ホー率いる内製カスタムチップ開発チームのエンジニアを40名規模に増員し、2026年後半の量産をターゲットとして推論処理に特化した自社チップの開発を急いでいる¹⁵。さらに、メモリ確保の観点から、スターゲイトプロジェクトは世界の半導体供給市場に多大な影響を与えており、サムスン電子（Samsung）およびSKハイニックス（SK Hynix）との間で月間最大90万枚のウェハ供給合意を交わした³。これは世界のDRAM生産量の最大40%を消費する規模に相当し、超並列演算に不可欠なメモリ帯域を事実上寡占するOpenAIの圧倒的な調達力を示している³。

以下の表2に、OpenAIが「スターゲイト」の傘下において全米で展開する主要な超巨大データセンターキャンパスの構成を整理する。

キャンパス名 / 開発主導	所在地 / 地域	計画電力容量	主なハードウェア / 開発の進捗
Abilene (アビリーン) （Oracle主導）	テキサス州アビリーン2	15	NVIDIA GB200を45万基配備（15年リース）2、 OCI Zettascale10（GPU 80万基規模）17
Shackelford County （Oracle / Vantage主導）	テキサス州シャックルフォード14	15	新規の超巨大ハイパースケール拠点、用地開発中15
Doña Ana County （Oracle主導）	ニューメキシコ州ドニャアナ14	複数 GW14	新規拠点、電力供給合意および許認可取得中14
The Barn (ザ・バーン) （OpenAI主導）	ミシガン州15	複数 GW15	約250エーカーの敷地に55万平方フィートの建屋3棟を建設15、 2026年初頭より着工15
Milam County （ソフトバンク / SB Energy主導）	テキサス州ミラム15	15	ソフトバンクの電源子会社が建設、2026年より順次部分稼働15、 OpenAI・SBが各 を出資15
Lordstown （ソフトバンク主導）	オハイオ州ロードズタウン15	複数 GW15	ソフトバンク独自の先進データセンター設計を導入、18ヶ月で立ち上げ14

3. Anthropicのマルチクラウド戦略、SpaceX Colossusレンタル、および供給エコシステム

Anthropicは、単一のクラウドプロバイダーや半導体ベンダーにインフラを依存することから生じる「単一障害点」を回避するため、AWSとGoogle Cloudの2つのエコシステムを極めて戦略的に併用している⁷。

同社はAWSに対し、10年間で1000億ドル以上を支払うという天文学的なクラウド利用契約を結んでいる⁷。このコミットメントには、AWSが誇るGravitonプロセッサや、Trainium2、Trainium3、次世代のTrainium4といったカスタムAI半導体の優先調達権が含まれており、すでに100万個以上のTrainium2チップを用いて構築された世界最大の独自クラスター「プロジェクト・レイニア（Project Rainier）」を共同で運用している⁷。Amazonはこれに応じる形で、すでに実行した80億ドルの出資に加え、新たに50億ドルの直接投資を実行し、さらに最大20億ドルの追加投資オプション枠を設定した⁶。これにより、2026年中に約1 GWに及ぶTrainium2/3の新規キャパシティが稼働を開始する計画となっている⁷。

同時に、AnthropicはGoogleおよびブロードコム（Broadcom）とも提携し、2027年以降に順次デリバリーされる複数ギガワット規模の次世代TPU調達合意を締結しており、その実質的な初期調達規模は約3.5 GWに上る⁸。この提携の核となるBroadcomは、2026年時点でTSMCの先進製造プロセス（3nm、2nm、およびそれ以下）におけるウェハ製造能力の約10%を確保している⁸。このBroadcomに割り当てられたTSMCの製造枠は、2030年に月間4万〜5万ウェハスタートに達する見込みであり、理論上、年間約12〜13 GW相当のAIアクセラレータ供給を担保することが可能である⁸。Broadcomが供給する9,216基規模のアクセラレータ統合を可能にする超高速光インターコネクトシステムは、Anthropicに独自のハードウェアパフォーマンスをもたらしている⁸。

さらに、Anthropicのインフラ戦略における最もアグレッシブな短期の「迂回調達」として特筆すべきなのが、2026年5月に完了したSpaceXとの合意である⁵。これは、旧xAI主導でメンフィスに構築され、2026年2月に株式交換に伴いSpaceXへ吸収された超巨大スーパーコンピューター「Colossus 1」の全計算能力を、月額12億5000万ドル（年間15億ドル相当）で3年間独占的にレンタルするという衝撃的な契約である²³。Colossus 1は、本来イーロン・マスクがGrokモデルの学習用に122日間で10万基、さらに92日間で計20万基（実質22万基規模）のH100/H200 GPUを敷き詰めた怪物システムである²³。

しかし、急速かつ強引な建設プロセスの結果、異なる複数のハードウェア世代やネットワーク配線が混在する「混合アーキテクチャ」の設計効率が悪く、フルスケールでの大規模LLM学習時におけるモデル演算効率（MFU）が11%という「使い物にならないほど低い」状態にあった²³。Anthropicはこの設計上の制約を逆手に取り、大量の高速メモリ帯域を必要とする「Claude」の推論（Inference）やエージェント実行処理専用にこの22万基のHopper GPU群（約300 MW容量）をそのまま割り当てることで、同社の実効的なデプロイキャパシティを瞬時に拡張した²³。

また、同社のシリーズHラウンド（総額650億ドル）には⁴、Micron、Samsung、SK Hynixという世界のメモリ・半導体産業の巨人たちが直接株主として参画しており⁵、高帯域幅メモリ（HBM）の極端な供給逼迫が懸念されるなか、物理レイヤーにおける強固なサプライチェーンの確保を実現している⁵。

4. 2030年に向けた計算資源（電力容量・ハードウェア）の年次ベース予測

計算資源の調達スピードは、各地域のグリッド（送電網）の稼働可能枠、サプライチェーンにおける変圧器などの重電コンポーネントの物理的リードタイム、そして両社の設備投資計画に制約される²⁸。特にOpenAIは、コスト構造の急激な肥大化や各国の規制懸念を踏まえ、イギリス（UK）での「スターゲイト」データセンタープロジェクトの計画を一時的に休止したほか、ノルウェー（Norway）のデータセンター取引から退きマイクロソフト側にその開発枠を引き渡すなど、国際的なインフラ拡張のペースを一部リセットしている³。

以下の表3は、これら市場環境、公式の調達コミットメント、および遅延リスクを踏まえて算出した、2025年から2030年までの両社の稼働可能な電力容量（GW）と、それを構成する推定実効アクセラレータ（GPU/TPU/ASIC）数の年次予測推移である。

年次	OpenAI 予測電力容量	OpenAI 推定実効アクセラレータ数	Anthropic 予測電力容量	Anthropic 推定実効アクセラレータ数
2025	(実績)9	約 80万基17	(実績)9	約 60万基相当
2026	14	約 220万基2	[cite: 7, 23]	約 150万基相当7
2027	9	約 450万基2	[cite: 9, 31]	約 350万基相当8
2028	15	約 720万基	7	約 500万基相当
2029		約 1,000万基		約 700万基相当
2030	[cite: 9, 31]	約 1,350万基	5	約 900万基相当

注：実効アクセラレータ数は、各世代のNVIDIA GPU、AWS Trainium、Google TPU等の混在環境を想定し、1基あたり平均 〜 の消費電力を前提として算出した実効換算値である。

この年次ベースの成長予測を形成する主要な調達イベントとタイムラインは、以下のように数理的かつ物理的に裏付けられている。

2025年〜2026年：アビリーン稼働とSpaceXによる短期埋め合わせ

OpenAIはアビリーン（テキサス）の主力データセンターの稼働（オラクルのGB200調達）によって、1.9 GWから5.5 GWへと拡大する⁹。一方、Anthropicは自社による大規模データセンターの建設期間をスキップするため、AWS上での1 GW規模のTrainium2/3供給を確保しつつ⁷、SpaceX「Colossus 1」の300 MWに及ぶ全GPUリソースをフルレンタルしたことで²³、2026年末には合計2.7 GWの実効容量に到達する²³。

2027年〜2028年：Google TPUデリバリーとスターゲイト第2波

2027年より、GoogleおよびBroadcomとの間で交わされた3.5 GWに及ぶ最新鋭TPUクラスターがデリバリーを開始するため、Anthropicは一気に7.5 GWへとキャパシティを膨張させ、OpenAIとのインフラ供給差を劇的に縮小させる⁸。対するOpenAIは、シャックルフォードや「ザ・バーン」などのスターゲイト主要拠点が順次完成し¹⁴、1枚あたり50 Petaflops（FP4）、かつ22 TB/sという超高速HBM4を搭載するNVIDIA「Vera Rubin」プラットフォームの配備が本格化することで、10 GWから16 GWへと順調に推移する²。

2029年〜2030年：全米30 GW送電網の完成

OpenAIは、当初に宣言した10 GWの全米物理インフラネットワークを大きく上回る、30 GW目標への物理的統合を果たす⁹。Anthropicも、AWSによる最大5 GWの電力枠確保に加え⁷、Google TPUの追加、および次世代のTrainium4などの高性能シリコン群の納入が完了することで、累計16 GWに及ぶ巨大なマルチクラウドインフラ群を稼働させる⁵。

5. モデルロードマップと計算資源がもたらす開発速度（ベロシティ）への直接的影響

両社の計算資源の調達状況とそのアプローチの違いは、それぞれの主力LLMファミリーの開発ロードマップ、リリースのタイミング、および社内開発の効率性（ベロシティ）に非対称な影響を及ぼしている。

OpenAIの「統合プレビュー」と過酷なリリースサイクル

OpenAIは、2025年8月に「ベースモデル」「マルチモーダル（omniシリーズ）」「推理（o-series）」の異なる進化系統を初めて1つに融合した「GPT-5」をリリースした³²。それ以降、インフラのスピーディな拡張を背景に、GPT-5.1、GPT-5.2、さらにGPT-5.3 Instant、GPT-5.4、5.4 Thinking、5.4 Pro、そして2026年4月には完全な再事前学習モデルである「GPT-5.5 Spud」、さらにその2週間後にはGPT-5.5 Instantへと、目まぐるしいアップグレードを矢継ぎ早に繰り出している³²。

特にGPT-5.4は、Anthropicが強固な基盤を築いていたエンタープライズ向けのコード生成や自律エージェントのシェアを奪い返すため、極めて短いスパンで戦略的に市場投入された³³。この過酷な開発・リリース頻度は、既存の開発者に壊滅的な「マイグレーション摩擦」を強いるという副作用も招いている³³。Azure OpenAIにおいて、これまでGA（一般提供）として信頼されていたGPT-4.1が2026年10月に半強制的に引退（リタイア）させられる一方³⁵、新型のGPT-5.x chatモデルはAzure Foundry上でプレビュー状態が長期にわたって続いており³⁵、本番稼働用にGA品質を要求するエンタープライズの開発部門において深刻なジレンマを引き起こしている³⁵。

GPT-5自体は、Speculative Decoding（投機的デコード）技術の採用によりGPT-4o比で2倍の超高速な推論速度を叩き出す³⁶。100万トークンにおよぶコンテキストウィンドウ、ネイティブなエージェントツール（自律的なウェブ検索、ファイル実行、多段階タスク管理）を備え、API価格は100万入力トークンあたり5ドル、出力20ドルに設定されている³⁶。

AnthropicのFable / Mythosと地政学的「モデル消失」リスク

Anthropicは、モデルファミリーの性能Tier（階層）を整然と管理してきた。2026年2月に100万コンテキストを実現した「Claude Opus 4.6」をリリースしたのち³³、同年6月9日には、第5世代モデルの頂点として「Claude Fable 5」および「Claude Mythos 5」（Project Glasswingパートナー向け、安全分類器のない限定版）を同時リリースした³⁷。これらは、4月に「サイバーセキュリティや生物・化学兵器製造の脆弱性を極めて高精度で自動発見・悪用できるため、一般公開するには危険すぎる」として一時公開が差し止められていたMythos Previewの改良版である³⁸。Fable 5 / Mythos 5は100万コンテキスト、128kの出力トークンを有し、API価格は100万入力トークンあたり10ドル、出力50ドル（Opus 4.8のちょうど2倍）に設定された³⁷。プロンプトキャッシュ技術により入力コストを最大90%削減（100万トークンあたり1.0ドル）することが可能であり、大規模コンテキストでのエージェント運用を強力に支援している³⁸。

しかし、一般公開からわずか3日後の2026年6月12日、米国政府は突如として国家安全保障上の「輸出管理指令」を発令した³⁹。これにより、国内外のあらゆる外国籍人員に対してClaude Fable 5およびMythos 5の提供・アクセスが直ちに一時停止された³⁹。Anthropicは指令から数時間以内に両モデルへのアクセスを全面的に遮断し、API利用者は旧世代のOpus 4.8などへの自動フォールバックを強いられた³⁹。この事件は、「APIとして提供されている最先端モデルは、稼働中のアプリケーションの根幹パーツでありながら、政治や安全保障上の規制トリガーによって、契約上の保証を無視して一瞬で消失し得る依存性（デプロイメントリスク）を持っている」という極めて教訓的な現実を市場に突きつけることとなった³⁹。

インフラによる「再帰的自己改善」がもたらす開発ベロシティ

調達された計算インフラは、Anthropic自体のシステム開発力を指数関数的に押し上げている。2025年2月に「Claude Code」がリサーチプレビューとしてリリースされて以降、2026年5月時点で、Anthropicの自社メインリポジトリにマージされるすべてのコードの「80%以上」がClaude自身によって執筆・提案されている⁴¹。このエージェント型AIコード生成の進歩により、2026年Q2時点で、Anthropicのエンジニア1人あたりが1日にマージする平均コード行数は、2024年の水準と比較して実に「8倍」に急増した⁴¹。

AIトレーニングジョブが崩壊しかけた極めて深刻かつ開示されていないエラーバグに対しても、自律エージェントモデル（Claude Fable 5等）が数十万件に上るAPIエラーを1000分の1に削減する自発的なデバッグ修正（800件以上の即時パッチデプロイ）を自律的にやり遂げるなど、最高難度のオープンエンドタスクにおける自律的な解決率は2026年5月に76%（半年前から50ポイントの急上昇）に到達している⁴¹。この「計算資源が新たな賢いモデルを生み、そのモデルがインフラを効率化し開発効率を加速させる」という再帰的なフライホイールは完全に実用化されている⁴¹。

6. 電力インフラ供給・電力網（グリッド）の制約と「BYOP」への構造転換

両社が掲げる数十ギガワットにおよぶ計算資源のロードマップを達成するうえで、最も深刻かつ回避不能な制約要因となっているのが、シリコン（半導体）そのものよりも「送電網（グリッド）」と「重電インフラサプライチェーン」の物理的限界である。

ゴールドマン・サックスによる電力需要の倍増予測

ゴールドマン・サックス（Goldman Sachs Research）のコモディティ調査によると、米国のデータセンターによる電力消費は、2025年の から2027年には へと2倍以上に跳ね上がる²⁹。2027年には、データセンター全体の電力量が米国のピーク夏期総電力需要の8.5%を占める計算になる²⁹。

しかし、驚くべきことに、現在計画または発表されている新規の超巨大データセンタープロジェクトのうち、予定通りのスケジュールで期日に送電を開始できるのはわずか50〜60%にとどまると見られている²⁹。この極端な遅延を生み出している最大の原因は、データセンターの建物やITラック自体は12〜18ヶ月で完成するのに対し、現地の変電所や電力網に高電圧の送電線を物理的に引き込むための送電網相互接続申請から完了までの待ち時間が「5〜7年」にまで長期化しているためである³⁰。

この影響は、地域グリッドのキャパシティ状況によって明確な乖離を見せている²⁹。米国東部のミッドアトランティック、中部のミッドコンティネント、および北西部（ノースウェスト）では、急増するデータセンター需要に対して電力会社の発電・送電網計画が完全に不足しており、電力網の崩壊を回避するために新規プロジェクトの接続申請を実質的に「拒絶」せざるを得ない信頼性危機に直面している²⁹。これに対し、豊富な電力パイプラインと迅速なインフラ計画を伝統的に擁しているテキサス州やジョージア州では、この影響は比較的軽微なものにとどまると分析されている²⁹。

防衛生産法の発動と産業用重電機器の深刻な不足

この国家競争力に関わるグリッド不足の深刻化を受け、大統領は防衛生産法（Defense Production Act: DPA）第303条を発動した³⁰。これにより、高電圧変圧器（トランスフォーマー）や開閉装置（スイッチギア）、超高圧ブレーカーなどの大型インフラ部品が「国家防衛に不可欠な戦略物資」に指定され、国内製造能力を緊急拡大するための連邦財政援助が承認された³⁰。現在、スイッチギアの注文リードタイムは60週間を超えており、大型ガスタービンや送電用ケーブルのバックログ（未納在庫）は複数年先まで満杯となっている²⁸。データセンター開発業者は、もはや電力会社が用意した送電網を待っていては他社とのAI競争に敗北することを悟り、自家発電設備を自前で調達してメーターの「裏側」で給電を行う「Behind The Meter (BTM：メーター裏側) 型発電」や、自前の電源を持ち込む「Bring Your Own Power (BYOP：電力自給)」へと一斉にシフトし始めている³⁰。2025年だけで、全米で50 GW規模のBTMガス発電プロジェクトが発表されていることは³⁰、このエネルギー自給運動のすさまじい過熱ぶりを証明している。

ITラックの高密度化と超巨大な水消費問題

さらに、データセンター内部のラック密度（ラックデンシティ）は劇的な変貌を遂げている。クラウド時代の一般的なラック電力が20〜40 kWであったのに対し、現在の最先端AIクラスターは1ラックあたり500〜600 kWの電力を消費する³⁰。さらに、NVIDIAの次世代「Vera Rubin Ultra」を搭載したラックは、単一ラックだけで「1 MW（メガワット）」という驚異的な超高密度に達する³⁰。この超高電圧化に伴い、従来の電力損失を最小限に抑えるため、データセンター内部の給電は「AC/DC（交流・直流）」変換ステップを廃し、800V DC（直流）直接配電アーキテクチャへの標準化を完了しつつある³⁰。

加えて、これらの高密度発熱を冷却するための「液体冷却」技術の導入が急務となっているが、100 MWの規模を持つ中型データセンターであっても、1日に最大200万リットル（約53万ガロン）という膨大な水を消費する⁴³。これが地域コミュニティにおける電気料金の高騰や水道資源の枯渇への懸念を呼び起こしており、全米でデータセンター建設に対する住民投票での反対や、自治体による建設の一時停止措置（モラトリアム）が拡大する一因となっている⁴²。

7. 結論

OpenAIとAnthropicの計算資源調達戦略に関する定量的比較は、AI開発競争がコードや理論（アルゴリズム）の競い合いから、資本力、送電網、大型ガスタービン、DRAMの確保、およびメモリ物理帯域幅の囲い込みを巡る、重厚長大かつ地政学的な物量戦へと完全に移行したことを明確に示している²。

OpenAIは、マイクロソフトとの独占契約変更という妥協を払いつつも、オラクルおよびソフトバンクと共同で「スターゲイト」を構築し、NVIDIA Blackwell GB300などの超高密度な物理クラスターを自社専用に確保する垂直統合モデルに賭けている²。これに対しAnthropicは、AWSとの10年におよぶTrainium利用契約、Google TPUおよびBroadcomが供給する製造キャパシティ、そしてSpaceX「Colossus 1」の全計算能力の一括独占レンタルといった、きわめて機動的かつシリコンが多様化されたマルチプラットフォーム環境を構築している⁷。

2030年に向けた予測では、OpenAIが30 GW、Anthropicが16 GWに及ぶ稼働容量をそれぞれ実現する見込みであるが、この物理的なデプロイプロセスは、DPAが発動されるほどの重電インフラ不足や³⁰、全米ピーク夏季電力の8.5%をデータセンターが飲み込むという送電網の危機²⁹、さらにはFable 5に対する輸出指令に見られるような規制・政治リスクという、予測不能なボトルネックに常に晒され続けることになる³⁹。したがって、これからのAI市場における最大の覇権は、最も多くの半導体を購入した企業ではなく、これら重層的な物理・政治的リスクをあらかじめ想定し、動的なルーティングや自己発電による電源自給を最も強靭（レジリエント）に構築できたプレイヤーに帰することになる。

引用文献

1. OpenAI vs Anthropic on Compute Strategy: Two Opposite Bets and What Happened, https://www.mindstudio.ai/blog/openai-vs-anthropic-compute-strategy
2. Microsoft and OpenAI Stargate Project: The Role of Oracle and NVIDIA Explained, https://www.mayhemcode.com/2026/02/microsoft-and-openai-stargate-project.html
3. OpenAI has effectively abandoned first-party Stargate data centers in favor of more flexible deals — company now prefers to lease compute and says Stargate is an umbrella term : r/business – Reddit, https://www.reddit.com/r/business/comments/1szkr5r/openai_has_effectively_abandoned_firstparty/
4. Insights: Anthropic Upcoming IPO & Private Stock Price – Forge Global, https://forgeglobal.com/insights/anthropic-upcoming-ipo-news/
5. Anthropic raises $65B in Series H funding at $965B post-money valuation, https://www.anthropic.com/news/series-h
6. Racing to a Trillion: OpenAI and Anthropic’s Funding History – Pinggy, https://pinggy.io/blog/openai_anthropic_funding_history/
7. Anthropic and Amazon expand collaboration for up to 5 gigawatts of new compute, https://www.anthropic.com/news/anthropic-amazon-compute
8. Anthropic’s Gigawatt-Scale TPU Deal with Broadcom Creates a Structural Advantage, https://futurumgroup.com/insights/anthropics-gigawatt-scale-tpu-deal-with-broadcom-creates-a-structural-advantage/
9. OpenAI investor memo touts computing advantage over Anthropic – Quartz, https://qz.com/openai-investor-memo-compute-advantage-anthropic-041026
10. Anthropic’s Google and Amazon Deals Explained – Augustus Wealth, https://augustuswealth.com/blog/why-google-amazon-investing-billions-anthropic/
11. Anthropic, Amazon links tighten: Anthropic to spend $100 billion over 10 years on AWS capacity | Constellation Research, https://www.constellationr.com/insights/news/anthropic-amazon-links-tighten-anthropic-spend-100-billion-over-10-years-aws-capacity
12. Anthropic locks in 5GW of AWS compute as Amazon deepens $100B AI infrastructure bet, https://www.edgeir.com/anthropic-locks-in-5gw-of-aws-compute-as-amazon-deepens-100b-ai-infrastructure-bet-20260501
13. Anthropic expands partnership with Google and Broadcom for multiple gigawatts of next-generation compute, https://www.anthropic.com/news/google-broadcom-partnership-compute
14. OpenAI, Oracle, and SoftBank expand Stargate with five new AI data center sites, https://openai.com/index/five-new-stargate-sites/
15. OpenAI’s Stargate Project: A Guide to the AI Infrastructure | IntuitionLabs, https://intuitionlabs.ai/articles/openai-stargate-datacenter-details
16. The Trillion-Dollar AI Bottleneck Nobody Is Talking About – PR Newswire, https://www.prnewswire.com/news-releases/the-trillion-dollar-ai-bottleneck-nobody-is-talking-about-302800938.html
17. Oracle launches the world’s largest AI supercomputer, serving as the computing power core of OpenAI’s “Stargate” – 36氪, https://eu.36kr.com/en/p/3518250228046722
18. Oracle Unveils Next-Generation Oracle Cloud Infrastructure Zettascale10 Cluster for AI, https://www.oracle.com/news/announcement/ai-world-oracle-unveils-next-generation-oci-zettascale10-cluster-for-ai-2025-10-14/
19. Oracle’s big bet for AI: Zettascale10 – Network World, https://www.networkworld.com/article/4073420/oracles-big-bet-for-ai-zettascale10.html
20. Microsoft Azure Unveils World’s First NVIDIA GB300 NVL72 Supercomputing Cluster for OpenAI – TechPowerUp, https://www.techpowerup.com/forums/threads/microsoft-azure-unveils-worlds-first-nvidia-gb300-nvl72-supercomputing-cluster-for-openai.341752/
21. Anthropic just locked in multi-gigawatt TPU capacity for future Claude models. Is frontier AI now mostly a compute race? : r/AI_Agents – Reddit, https://www.reddit.com/r/AI_Agents/comments/1ser8b7/anthropic_just_locked_in_multigigawatt_tpu/
22. Anthropic just locked in multi-gigawatt TPU capacity for future Claude models. Is frontier AI now mostly a compute race? : r/ClaudeAI – Reddit, https://www.reddit.com/r/ClaudeAI/comments/1ser7pk/anthropic_just_locked_in_multigigawatt_tpu/
23. Anthropic rents Colossus 1 for $1.25 billion/month on an xAI park capped at 11% capacity, https://www.actuia.com/en/news/anthropic-rents-colossus-1-for-125-billionmonth-on-an-xai-park-capped-at-11-capacity/
24. Colossus (data center) – Wikipedia, https://en.wikipedia.org/wiki/Colossus_(data_center)
25. Anthropic-SpaceX deal seems much larger than previously reported : r/singularity – Reddit, https://www.reddit.com/r/singularity/comments/1tj0efw/anthropicspacex_deal_seems_much_larger_than/
26. Colossus: The World’s Largest AI Supercomputer – xAI, https://x.ai/colossus
27. ELI5: why is google paying so much more for spacex compute than anthropic? – Reddit, https://www.reddit.com/r/singularity/comments/1tzv0pd/eli5_why_is_google_paying_so_much_more_for_spacex/
28. The Growing Compute Shortage – Apollo Global Management, https://www.apollo.com/wealth/insights-news/insights/2026/06/growing-compute-shortage
29. US Data Center Power Demand Projected to Double by 2027 – Goldman Sachs, https://www.goldmansachs.com/insights/articles/us-data-center-power-demand-projected-to-double-by-2027
30. Roadmap: The AI data center stack – Bessemer Venture Partners, https://www.bvp.com/atlas/roadmap-the-ai-data-center-stack
31. OpenAI cites computing advantage over Anthropic to investors: report – Seeking Alpha, https://seekingalpha.com/news/4573954-openai-cites-computing-advantage-over-anthropic-to-investors
32. OpenAI GPT Model Release Timeline – Model Lineage, ChatGPT and Codex Milestones, and Platform Availability | hidekazu-konishi.com, https://hidekazu-konishi.com/entry/openai_gpt_model_release_timeline.html
33. Five Models in Three Months — The GPT-5.x Timeline and What It Demands From Enterprise IT – SoftwareSeni, https://www.softwareseni.com/five-models-in-three-months-the-gpt-5-x-timeline-and-what-it-demands-from-enterprise-it/
34. OpenAI 2026 AI Roadmap: GPT-5, 5.2 & Open Models – i10X, https://i10x.ai/news/openai-2026-ai-roadmap-gpt-5-models
35. Availability of GPT-5.x series GA non-reasoning models in Azure Foundry – Microsoft Learn, https://learn.microsoft.com/en-my/answers/questions/5915512/availability-of-gpt-5-x-series-ga-non-reasoning-mo
36. GPT-5 Release Date & Features: Everything Confirmed in 2026 – NeuraPulse, https://neuraplus-ai.github.io/blog/gpt-5-release-date-and-features.html
37. Introducing Claude Fable 5 and Claude Mythos 5 – Claude API Docs – Claude Console, https://platform.claude.com/docs/en/about-claude/models/introducing-claude-fable-5-and-claude-mythos-5
38. Claude Mythos pricing 2026: Fable, Mythos & what each model runs – CloudZero, https://www.cloudzero.com/blog/claude-mythos-pricing/
39. Fable 5 & Mythos 5 Suspension: What It Means for Your AI Architecture – Gravitee, https://www.gravitee.io/blog/fable-5-mythos-5-suspension-what-it-means-for-your-ai-architecture
40. Claude Fable – Anthropic, https://www.anthropic.com/claude/fable
41. When AI builds itself – Anthropic, https://www.anthropic.com/institute/recursive-self-improvement
42. AI Data Center Growth Hinges on Solving Both Power Constraints and Community Concerns, Bloom Energy Report Finds, https://investor.bloomenergy.com/press-releases/press-release-details/2026/AI-Data-Center-Growth-Hinges-on-Solving-Both-Power-Constraints-and-Community-Concerns-Bloom-Energy-Report-Finds/default.aspx
43. Here are the states and cities pushing back against data centers, https://www.washingtonexaminer.com/policy/energy-and-environment/4607237/state-cities-pushing-back-against-data-centers/

エグゼクティブサマリ

今回の調査で最も重要だった発見は、Codexは依然として「コーディングエージェント」だが、実際のプロダクト進化はすでに「コードを書く人だけの道具」から外へ広がっているという点です。OpenAIの公式ドキュメントと2026年のChangelogでは、Codexは研究、執筆、計画、分析、ソース収集、各種アーティファクト生成まで含む「より広い仕事のためのワークスペース」へ拡張されていると説明され、公式ユースケース群もGmail、Slack、Google Drive、Calendar、Google Sheets、Sites、Computer Useを前提とした知識労働・運用・資料作成・データ処理に大きく寄っています。つまり、非エンジニアにとっての本質は「コード生成そのもの」ではなく、自然言語で業務フローを記述し、裏側のコードやファイル処理を隠蔽したまま成果物を得ることです。

そのうえで、非エンジニア向けに最も現実的な導入先は三つあります。第一に、ドキュメント中心の仕事です。会議ブリーフ、PRD、スライド、学習用レポート、フィードバック統合のように、「入力は散在した文書群、出力はレビュー可能な文書」という業務は、Codexの公式想定と最も一致しています。第二に、スプレッドシート中心の仕事です。CSV整形、質疑応答、可視化、予実比較、キャッシュフローモデルのような仕事は、公式ユースケースでも明示され、学術研究でも自然言語による表計算操作は非技術者の障壁を下げる方向で進展しています。第三に、ノーコード寄りの社内アプリ試作です。OpenAI公式のSites、さらにCiscoのApp Builder事例は、「自然言語から動くアプリを立ち上げる」という非エンジニア寄りの導入像をかなり具体的に示しています。

一方で、楽観だけで整理すると判断を誤ります。Codexの価値は「完全自動化」ではなく「レビュー可能な半自動化」として見るのが妥当です。OpenAI自身が、Computer Useには権限承認が必要で、Cloudのインターネットアクセスはデフォルトで遮断、許可時もプロンプトインジェクションや秘密情報流出のリスクがあると明示しています。さらに、会議要約系の研究では幻覚や脱落が依然として課題であり、表計算研究でも実世界の複雑なシートは現行LLMにとって難所です。METRの2025年RCTでは、経験豊富なOSS開発者はAI利用時に平均で19%遅くなったという逆風の結果も報告されています。非エンジニアではなおさら、業務の切り出し方、入力の限定、検証フロー、承認境界が成果を左右します。

結論を先に言えば、非エンジニアに対するCodexの最適戦略は、広く一気に入れることではなく、狭い業務を深く置き換えることです。最初の一歩としては、「毎週ほぼ同じ構成で作る資料」「同じ種類のCSV整形」「会議準備の情報収集」「サポートチケットやSlackスレッドの分類」「既存業務の小さな社内ツール化」が成功しやすい領域です。逆に、「曖昧な要求をまたいで社内外の複数システムを自律操作する」「高リスクな顧客返信を人手なしで送信する」「評価基準が曖昧な創作を一発で本番投入する」といった用途は、現時点では設計・監督コストが高く、導入順位を下げるのが合理的です。

調査範囲とCodexの位置づけ

本レポートは、OpenAI公式のCodexユースケース集、Codex本体ドキュメント、ブログ、ヘルプセンター、日本語の公式ページを最優先に参照し、そのうえで学術論文と業界記事を重ねて評価しました。公式ユースケース一覧は、Automation、Data、Integrations、Knowledge Work、Finance、Operations、Product、Research、Salesといったフィルタを持ち、少なくとも表向きの設計意図として、Codexが開発作業だけではなく知識労働・業務運用・分析・資料作成の中間レイヤーに広がっていることを示しています。OpenAIの2026年4月16日Changelogも、project folder不要のChatsを「research, writing, planning, analysis, source gathering」に有効と明言しており、公式ポジショニング自体が非技術職に近づいています。

この整理は重要です。Codexは「ノーコードプラットフォーム」ではありません。OpenAIのトップページや日本語ページでも、Codexはまずソフトウェア開発エージェントとして説明されています。一方で、Skills、Plugins、MCP、Sites、Computer Use、Artifact Viewer、Automationsが揃った結果、非エンジニアがコードを直接書かなくても、コードを媒介に成果物や業務フローを得られるようになってきました。したがって、Codexの非エンジニア活用は「プログラミングを教えなくて済む」のではなく、プログラム可能性を自然言語・テンプレート・承認フローの背後に隠すアーキテクチャだと捉えるべきです。

日本語資料については、OpenAIは日本語の製品ページとヘルプセンター記事を提供していますが、ヘルプセンターのCodex記事は機械翻訳であることが明示されています。つまり、日本語導入は可能だが、一次情報の厚みは依然として英語が中心です。この点は、非エンジニア導入でありがちな「日本語で全部完結できる」という期待を少し下げておくべき根拠になります。

以下の図は、本レポートで整理した「非エンジニア向けCodex活用の全体像」です。公式ユースケースを中心に、学術研究で妥当性や限界が補強されたものを配置しています。

ユースケース分類と分析

教育 — OpenAI公式の「Learn a new concept」は、研究論文や講義資料をSubagentsで分担読解し、用語集・概念図・証拠表つきMarkdownレポートに落とす使い方を想定しています。これは「プログラミング学習」ではなく、難解資料の学習設計を外部化する用途です。利点は、読解の並列化、引用付きの学習ノート化、図解生成、未理解点の明示です。導入難易度は中程度で、素材の所在整理と「何を学べれば成功か」の定義が必要です。前提条件は、教材ファイル、参照可能なソース、曖昧な主張と自分の解釈を分ける評価ルールです。成功例としては、公式ユースケースそのものに加え、RAG型チュータは教師が与えたソースに基づくことで幻覚を抑えやすいとする研究があり、AIチュータが対面型アクティブラーニングより短時間で高い学習成果を示した報告もあります。他方で、教育研究では過信、浅い理解、主体性の低下、幻覚が一貫した懸念として挙がっており、「答えを出す装置」ではなく「学習の足場」として使う設計が必須です。

ビジネス業務自動化 — 公式には、受信箱管理、会議ブリーフ、オンボーディング、イベント運営、Slackアクション抽出、プロアクティブな仕事整理といった業務が細かくテンプレート化されています。共通点は、散在した文脈を集めて、レビュー可能な草案・チェックリスト・順位付きアクションへ変換することです。利点は、文脈切替の削減、抜け漏れ防止、ルーチン仕事の定時化です。導入難易度は低〜中で、Gmail、Slack、Calendar、Driveなどのプラグイン接続ができれば始めやすい反面、通知ノイズを減らすには継続チューニングが必要です。前提は、接続先の権限設定、どこまで下書きで止めるかという承認境界、Automationsの運用ルールです。成功例はOpenAI公式のワークフロー群自体に加え、OpenAI DevDay 2025でCodexが社内の問題解決・優先順位づけ・並行作業に広く使われたことです。失敗パターンは、広すぎる文脈を渡して重要度判定が崩れるケース、未承認の自動送信、権限を広く与えすぎるケースです。特にAutomationsは unattended 実行であるため、デフォルト権限とallowlist設計を曖昧にすると運用事故の温床になります。

クリエイティブ支援 — 公式には、「Get from idea to proof of concept」「Turn user stories into UI mocks」「Figmaとの双方向連携」が核です。つまりCodexの創造性支援は、純粋な文章生成よりも、曖昧な着想を視覚化し、試作し、比較可能な案に落とすところで強いです。ゲームデザイン支援も、公式ユースケースとSites/Showcase文脈から見ると、まずブラウザゲームや体験モックを作って試す方向が現実的です。利点は、形のないアイデアを短時間で視覚案・操作案・試作品に変えられることです。導入難易度は中程度で、要求の言語化と「評価観点」の提示が必要です。前提は、参考資料、ブランド/世界観ガイド、レビュー担当者です。成功例としては、OpenAI DevDay 2025でステージデモや体験プロトタイプにCodexが広く使われたこと、Figma MCPで“動くUIをFigmaに戻す”往復が可能になったことが挙げられます。一方、創造研究では、LLMは単純課題では発想刺激になっても、複雑課題では creative fixation を起こしうると報告されています。したがって、最初の案を採用するより、複数案比較を前提にした運用が向いています。

データ分析補助 — 非エンジニアにとって最も即効性が高いカテゴリです。公式には「Clean and prepare messy data」「Query tabular data」「Analyze datasets and ship reports」「Review budget vs. actuals」「Forecast cash flow」が揃っており、CSV整形、表データ質問応答、可視化、xlsx生成、予実差異分析までカバーしています。利点は、Excel/Sheetsの数式やスクリプトを書かずに、自然言語から分析作業へ入れることです。導入難易度は低〜中で、単発QAや整形なら始めやすく、財務モデルや複数ソース結合は中級以上です。前提は、元データの所在、列の意味、出力形式、そして「変更前データを保持する」原則です。成功例は公式のスプレッドシート系ユースケースに加え、近年の研究でSheetMindが「スクリプトや数式知識なし」での会話型表計算操作を狙い、単一ステップ80%、複数ステップ約70%の成功率を報告したこと、TableTalkが認知負荷を下げ、好ましさを高めたことです。失敗例・制約としては、SpreadsheetBenchが現実のExcelフォーラム由来タスクを難問として示し、SpreadsheetLLMがシートの2次元構造とトークン長制約を問題視している通り、実務の複雑表計算は依然として難しいという点です。要するに、Codexは「万能Excel代替」ではなく、「質問・整形・可視化・レビュー用ワークブック作成」にまず投資すべきです。

アクセシビリティ支援 — これはCodex単体のネイティブカテゴリというより、CodexとOpenAIの音声・Realtime・Computer Useを組み合わせた周辺活用です。公式にはComputer UseがmacOS/Windows上のGUI操作を担当し、Speech-to-Text、Text-to-Speech、Voice Agents、Realtimeが代替入力や音声UIの基盤を提供します。利点は、キーボード中心の操作が難しい場面でも、音声で依頼し、Codexがアプリやブラウザを操作して成果物を返せることです。さらにAppshotsは、Mac上の前面ウィンドウをショートカットでCodexに渡せるため、長い状況説明の代替入力としても機能します。導入難易度は中〜高で、音声UIの設計、権限設定、誤操作対策が要ります。前提は、Screen Recording / Accessibility権限、利用アプリの可視状態、音声認識品質の確認です。成功例は、公式の音声エージェント構成やComputer Useのワークフロー説明そのものです。制約としては、Computer Useがアプリ状態を変えうること、音声系は日本語を含む多言語対応がある一方で、非英語環境ではAI支援の効果差が生じうるとする研究があること、そしてCodex公式にはアクセシビリティ専用UXの詳細設計までは出ていないことです。したがって、このカテゴリは補助技術としての価値は高いが、完成品ではなく設計対象だと見るのが正確です。

ノーコード/ローコード支援 — 非エンジニアへの波及が最も大きいのはここです。OpenAI公式の「Build and deploy internal apps」とSitesは、Codexに自然言語で社内アプリを作らせ、保存・デプロイ・認証つきで配布する流れを提供しています。Ciscoはさらに一歩進めて、Cloud Control内にApp Builderを組み込み、「plain languageで、インフラ構築なし、最初からデプロイ済みのアプリ」を打ち出しました。利点は、既存業務の手順やフォームや一覧画面を「雑用としての開発」なしに試せることです。導入難易度は中〜高で、要件定義、データモデル、権限設計、レビュー体制が必要です。前提は、扱うデータの所在、認証要件、公開範囲、変更管理です。成功例として、Ciscoはパートナー/顧客向けに自然言語からアプリを組み立てる事例を提示しています。失敗リスクは、要件が曖昧なまま試作を量産して運用負債を増やすこと、LLMと非専門家のあいだに abstraction gap があり「モデルが欲しがる言い方」にこちらが合わせてしまうことです。研究でも、非専門家はコード生成LLMに対し意図の伝え方で躓きやすいとされ、TableTalkや関連研究は足場づくりを重視しています。つまり、ノーコード化の本体はモデル性能ではなく、テンプレート・制約・確認工程の設計です。

ドキュメント作成・要約 — ここはCodexの公式想定が非常に明確です。PRD草案、会議ブリーフ、学習レポート、スライド、フィードバック要約はすべて公式ユースケース化されています。利点は、ソース群からレビュー可能なアーティファクトへ直接変換できる点で、2026年4月のArtifact Viewer追加により、PDF・スプレッドシート・文書・プレゼンをサイドバーで確認できるようになったことも非エンジニアには重要です。導入難易度は低〜中で、特に会議ブリーフ・PRD・スライドは始めやすい領域です。前提は、参照ソースの限定、出力の型、改稿責任者です。成功例としては、各公式ユースケースに加え、OpenAIがSuperhumanの例として「PMが軽微なコード変更に寄与できる」ことを示した点も、ドキュメントから実装への距離が縮んでいる象徴です。失敗例・制約としては、会議要約研究が幻覚・脱落・irrelevancyを引き続き報告していること、要約研究全体でもfaithfulnessが未解決であることです。文書化領域は強い一方で、一次情報との対応表を残すソース付けが品質管理の中心になります。

カスタマーサポート支援 — OpenAIは「Support」専用カテゴリこそ大きく打ち出していませんが、実務上はかなり近いユースケースを揃えています。「Turn feedback into actions」は support-ticket CSVs を明示し、Google Sheet/Doc/Slack updateへの集約を想定しています。「Manage your inbox」は返信案の草稿化、「Prioritize Slack action items」は support・community・operations での優先順位づけを明示しています。利点は、問い合わせの分類、重複要望の集約、返信草案、エスカレーション候補抽出です。導入難易度は低〜中で、すでにGmailやSlackを使っているチームは始めやすいです。前提は、個人情報のマスキング規則、公に見せる要約と内部メモの分離、Human-in-the-loopです。成功例としては、公式スタータープロンプトが「名前や私的引用を visible summary に入れない」ことまで明示しており、サポート運用の実務にかなり近いです。失敗パターンは、顧客感情や文脈を雑に圧縮すること、未承認の送信、自動分類に過度依存することです。よってこのカテゴリでは、送信前承認を外さないことが事実上の必須条件です。

その他 — 公式ユースケースを見ると、非エンジニア活用は実際には「未分類の小さな業務バンドル」に強いです。Messagesからタスクを完了する、イベント運営の公開文面と内部チェックリストを分離する、オンボーディング一式を下準備する、日々の重要事項だけ拾う“teammate”スレッドを作る、といった仕事がそれに当たります。これらは単独カテゴリよりも、“散った文脈を短時間で行動可能な形へ変える”というCodexの汎用能力を示しています。公開成功例は個別には少ないものの、Ciscoの事例やOpenAI社内活用を見る限り、価値は大きなシステム構築より「日々の摩擦を減らす小粒な反復作業」に出やすいと見るのが妥当です。

比較表と導入優先順位

以下の比較表でいう「導入コスト」は、Codexと既存SaaSを前提にした追加導入コストの概算です。低は既存のChatGPTプランと既存業務データで試せるもの、中はプラグイン接続・レビュー手順整備が必要なもの、高はBusiness/Enterprise、Sites、権限設計、監査、あるいは専用ワークフロー整備が必要なものとして整理しました。Codex自体はFree/Go/Plus/Pro/Business/Edu/Enterpriseに含まれますが、Sitesは現時点でBusiness/Enterprise中心、API key運用はクラウド機能が限定されます。

導入優先順位としては、第一群が文書化と表計算、第二群が業務トリアージ、第三群が社内アプリ試作、第四群が代替入力や複雑なCross-app自動化です。理由は単純で、入力と出力の検証可能性が高いほどCodexの価値が出やすく、エラーの社会的コストが低いからです。逆に、顧客送信・権限変更・GUI自動操作が前面に出るほど、メリットはある一方で監督コストが急増します。

非技術者向けの技術要約と実践ガイド

非技術者向けにCodexを一文で言い換えるなら、「自然言語で依頼すると、ファイル・表・文書・アプリ・ウェブ操作まで含めて、レビュー可能な成果物を作る仕事エージェント」です。機能面では、ローカルまたはクラウドで作業し、コードや文書を読み書きし、コマンドを実行し、プラグイン経由でGmail/Drive/Slackを扱い、必要に応じてComputer UseでGUIを操作し、Sitesでホスト済みサイトや社内アプリを配布できます。さらにSubagentsで作業を並列化し、Automationsで同じスレッドを定期的に再実行できます。こうして見ると、非エンジニア活用の本質は「プログラムを書くこと」より「成果物と承認フローを設計すること」にあります。

制約ははっきりしています。第一に、Codexは一般的な万能秘書ではなく、あくまで“作業可能なエージェント”です。だからこそ権限境界が重要で、Permissionsには read-only / workspace / danger-full-access が用意され、Cloud側のインターネットアクセスもデフォルトでは遮断されています。第二に、Computer UseやBrowser Useは便利ですが、外部アプリの状態を変えうるので「狭いタスク」「明確な対象アプリ」「都度承認」が前提です。第三に、In-app browserは認証フローや既存Cookieを扱えず、公式もサインインが必要なページは通常ブラウザを使うよう勧めています。第四に、言語面ではOpenAIは日本語の製品ページとヘルプ記事を提供し、音声系APIも日本語を含みますが、Codex専用の言語対応表は今回確認できず、非英語運用の質はプロンプト設計と検証に左右されます。

歴史的な性能の見方も補足しておくべきです。2021年の原初Codex論文ではHumanEval pass@1が28.8%でしたが、これは現在のGPT-5系Codexとは世代もエージェント構成も異なるため、そのまま比較してはいけません。むしろ現在の実務上の重要点は「一発正解率」より長いタスクをどれだけ整合的に追い続けられるかです。OpenAIは25時間・約1300万トークン・約3万行の長時間Codex実験を公開し、METRはフロンティアAIエージェントのタスク時間軸が過去6年で約7か月ごとに倍化していると報告しています。ここから言えるのは、Codexの非エンジニア活用も「短い質問応答」より「数十分〜数時間かけてアーティファクトを作らせる」方へ重心が移っているということです。

実践ガイドは、次の順で進めるのが最も堅実です。まず、業務を「毎週繰り返す」「入力ソースが限られる」「出力フォーマットが固定されている」ものに絞ります。次に、使う面を選びます。文書・表計算・資料ならCodex appやChats、社内アプリならSites、Slack駆動ならSlack integration、GUI必須ならComputer Useです。そのうえで、ソース境界、非目標、出力形式、承認境界をプロンプトに明示します。たとえば「Gmailだけを参照」「未送信の下書きまで」「Google Sheetで出力」「個人名は要約に入れない」のように、守らせたい境界を先に書きます。続いて、小さなサンプルで試し、差分レビューを行い、最後にAutomationsやSkillsで定型化します。この順番は、OpenAIのスタータープロンプト群、Best Practices、Permissions、Automationsの設計思想と整合しています。

導入タイムラインは、実務では4週間程度の小さなパイロットが適切です。大事なのは、PoCを「できたかどうか」で終えず、人手レビュー込みで、どこまでなら任せられるかを切り分けることです。特に会議要約、顧客返信、財務ワークブック、GUI操作は、最終承認の責任者を最後まで残す方が総合的な品質が安定します。

代表プロンプトテンプレートと主要出典

以下のテンプレートは、OpenAI公式のスタータープロンプト群を日本語業務向けに再構成したものです。ポイントは、入力ソース、出力形式、境界条件、承認条件、除外事項を必ず含めることです。これは公式スタータープロンプトでも繰り返し見られる設計であり、非エンジニア運用ではここを曖昧にすると品質が急落します。

最後に、主要出典を性質別に整理します。
OpenAI公式の中核資料としては、Codex use cases一覧、各ユースケース個票、Codex app、Plugins、Sites、Computer Use、Automations、Permissions、Internet Access、Pricing、Changelog、Introducing Codex、Building frontend UIs with Codex and Figma、How Codex ran OpenAI DevDay 2025、日本語製品ページ、日本語ヘルプ記事が最重要です。

学術一次資料としては、Codex原論文、NL2Formula、SpreadsheetBench、SpreadsheetLLM、SheetCopilot、SheetAgent、SheetMind、TableTalk、abstraction gap研究、要約のfaithfulness研究、教育系のRAGチュータ・AIチュータ研究、教育リスク研究が実務判断に役立ちます。特に、表計算と要約は「可能性」と「難所」がどちらも強く可視化されている領域です。

業界事例としては、OpenAI × Ciscoのケーススタディ、CiscoのApp Builder発表、OpenAIが挙げるSuperhumanのPM活用、Ciscoブログの初期パートナー記事が、非エンジニアや周辺職種への波及可能性を最も具体的に示しています。特にCiscoの「plain languageでアプリを作る」「born deployed」という表現は、Codexが“非エンジニア向けにどう包まれると価値が立ち上がるか”を示す好例です。

総括すると、Codexの非エンジニア向けユースケースは「コードを書かせること」よりも、仕事を構造化し、レビュー可能な中間成果物を作り、必要なときだけ人が最終判断する運用に置いたときに最大化されます。現時点での最適解は、文書系・表計算系・小規模社内アプリ系から入り、顧客送信や広範なGUI自動操作は後段に回すことです。これが、公式ソース、学術研究、事例を重ねたときに最も整合的な導入戦略です。