このたび、鮒谷周史さん（読者数14万人超・日刊配信6,000日継続の超・定番＆まぐまぐ殿堂入りメルマガ、まぐまぐ大賞2025受賞）主催の「AIエージェント実践講座（全7回・32時間）」で講師を務めることになりました。

8月2日から12月6日まで、3週間おきに全7回、オンライン（Zoom）で開催します。

鮒谷さんは、長年にわたり日刊メールマガジン『平成進化論』を発信し、経営、営業、マーケティング、学習、行動変容を一貫して扱ってこられた方です。

今回の講座も、単なる新ツール紹介ではありません。

新しい道具を知って終わる場ではなく、仕事のやり方そのものを更新する場として設計しています。
単発の驚きより、継続して成果につなげること。知識より、行動が変わること。その文脈の中で、AIエージェントを実務に落とし込む32時間です。

ChatGPTに聞く。文章を直してもらう。要約してもらう。

ここまでは、多くの方がすでにやっています。

一方で、仕事そのものは今も自分の手から離れません。調べる。整理する。ファイルを作る。メールを確認する。表にまとめる。アプリを試作する。SNSの運用を考える。こうした作業の多くは、まだ人間が一つずつ手を動かしています。

AIエージェントは、この境界を越える道具です。

ゴールを渡すと、段取りを考え、手を動かし、成果物を返してきます。

私は、チャット型AIとエージェント型AIのあいだには、深い谷があると考えています。

向こう岸の景色は、はっきり見えています。AIに仕事を任せられる未来も見えています。けれど、そこへ渡る途中で、多くの人が立ち止まります。

自治体、上場企業、士業事務所などで研修・セミナーを続ける中で、谷に落ちる場所はかなり共通していると分かりました。
大きく3つあります。

1つ目は、環境構築の谷です。

アプリの導入、アカウント設定、作業フォルダの指定、ローカル環境の扱い。ここで半日つまずくと、多くの方は「また今度」とやめる流れになります。

2つ目は、権限と承認の谷です。

AIにPCの操作を任せるとは、どこまで許可することなのか。

ここを設計できると、AIに任せる範囲と、人間が確認する範囲を分けられます。反対に、ここが曖昧なまま進むと、怖くて任せられない状態か、設計のない任せ方に寄っていきます。

3つ目は、任せ方の谷です。

チャットの延長で、一問一答を続けてしまう。これは多くの人が通る道です。

AIエージェントの本領は、「次に何をすればいいですか」と聞くことより、「このゴールまで進めてください」と渡すところから発揮されてきます。

目的、制約、材料、完成イメージ、確認ポイントを渡す。

すると、AIは段取りを考え、途中で必要な確認を入れながら、成果物に近づいていきます。

短時間のセミナーで覗けるのは、谷の入口までです。

渡り切るには、正しい順番で、十分な時間、手を動かす必要があります。

この講座は、この谷に橋を架ける32時間です。全7回です。

初日の6時間で、谷を渡り切ります。

Codex・Claude Desktop(Cowork)・Cursorの3つをセットアップし、権限・承認・サンドボックスの考え方を押さえ、最初の自動化まで到達します。

その後の6回で、リサーチ、データ分析とダッシュボード、Gmail連携、業務アプリの内製化、SNS運用の仕組み化、複数AIのチーム化へと、「任せられる仕事」を広げていきます。

受講者の役割は、コードを書くことより、目的・制約・確認ポイントを日本語で渡すことです。

必要なコード生成、設定作業、試作の手順は、AIエージェントに任せます。人間は、何を実現したいのか、どこまで任せるのか、どこで確認するのかを設計していきます。

毎回、成果物を1つ持ち帰る設計にしました。

知ったつもりで終わる講座ではなく、手元の仕事に接続する講座です。

開催概要
全7回・計32時間、オンライン（Zoom）で開催します。

第1回：8月2日（日）13:00〜19:00

第2回〜第6回：8月23日、9月13日、10月4日、10月25日、11月15日
いずれも日曜 13:30〜17:30

第7回：12月6日（日）13:00〜19:00

出欠にかかわらず、全回の収録動画と音源が提供されます。

参加費：198,000円（税抜）

主催：鮒谷周史さん（平成進化論）
講師：本郷喜千

お申込みはこちらから。

AIエージェント実践講座（全7回・32時間）

https://form.os7.biz/f/143a2ee6/

道具の進化は、待てば手に入ります。

ただし、「聞く側」から「任せる側」への移動は、自分で一歩目を踏み出す領域です。

AIエージェントは、魔法の道具ではありません。

けれど、任せ方を身につけた人から、仕事の組み立て方が変わっていきます。

詳しい内容は、開催日に向けて平成進化論で展開されます。メルマガに登録されると1日1通メルマガが届きますので、そこで徐々に全貌が明らかにされます。

https://www.mag2.com/m/0000114948

橋は架けます。

谷の向こうでお会いしましょう。

「てにをは」の概念的定義と語意の多層的変容

「てにをは」は、現代の日本語空間において主として助詞、あるいは助詞と助動詞を包含する機能語の総称として広く用いられている¹。単語と単語の文法的関係性を規定し、文全体の命題構造や文脈的・情緒的ニュアンスを決定づける極めて重要な言語的言説装置である⁴。

日常の言語実践においては、論理的整合性や文脈の一貫性が欠如している状態を指して「てにをはが合わない」と形容する³。この比喩表現が示すように、「てにをは」の概念は単なる個別の文法カテゴリとしての機能語にとどまらず、文章表現における整合性、論理的説得力、ひいては発話・記述における統語的能力そのものを表象するメタ概念としての役割を担っている³。

歴史的な変遷を辿ると、「てにをは」が対象とする言語要素の射程は時代ごとに伸縮を繰り返してきた¹。古代から中世の日本語学において、この語は単に現在の助詞に相当する概念のみならず、用言の活用語尾、各種の接尾語、さらには助動詞に至るまで、主体的・自立的な意味（実質語）に対して補助的かつ文法的な機能を付与するあらゆる語尾要素を包括的に指し示す言葉として運用されていた³。このような歴史的背景を理解することは、現代日本語における助詞の洗練された文法的機能を解明するための不可欠な前提となる¹。

漢文訓読におけるヲコト点の幾何学的構造と語源的派生

「てにをは」の語源は、平安時代以降の漢文訓読技術において、漢字の周囲に点や短い線などを書き加えることで日本語の読み下し（送り仮名や助詞など）を示した「ヲコト点（乎古止点）」の記号体系に直接由来している¹。漢字という異言語の記述順序を日本語の統語規則に従って読み解く必要性に迫られた当時の知識層（僧侶や学者など）は、視覚的な補助符号として機能するヲコト点を発明・発達させた³。

ヲコト点は、伝承する学派や学術的系統（博士家）ごとに独自の配置パターンを有していた¹。その中で、明経道や紀伝道の儒学者、さらには医学者の間で広く流通し、後に最も世に広まることとなった「俗家点（別称として俗点・博士家点）」は、すべて「第五群点」に分類される符号体系に属している⁸。この俗家点における代表的な点図において、漢字の字面の四隅に配された点が、語源形成において決定的な役割を果たした¹。

漢字を仮想的な四角形（田の字状の座標系）と見立てた際、左下の星点を起点として時計回りに四隅を結ぶ走査線を描くと、その位置に対応する助詞が順番に「て」「に」「を」「は」となった¹。この幾何学的な位置表記と読みの連動性こそが、「てにをは」という語彙を誕生させた起源である¹。

中田祝夫博士の研究によれば、これらのヲコト点体系は静的なものではなく、歴史的に図式自体が「回転」することによって、新たな符号バリエーションを発生・変遷させていくダイナミックな発達プロセスを辿ったことが指摘されている¹⁰。一つの基本座標系が空間的に回転・移動することにより、異なる助詞の対応関係を示す新たな読み方図式（西墓点や仁都波迦点など）が派生したという学説は、当時の知識層における言語認知的工夫の柔軟性を雄弁に物語っている¹⁰。

近世歌学・国学における学術的文法研究への止揚

中世から近世にかけて、「てにをは」は伝統的な歌学（和歌の創作・注釈）の文脈で極めて重要視され、情調表現の真髄として秘伝化される傾向にあった¹¹。しかし、江戸時代中期に国学が本格的な勃興を見せると、実証的な古典文献学のアプローチによって、「てにをは」は神秘主義のベールを剥がされ、客観的な言語法則として記述されるに至った¹²。

この文法研究の飛躍的進展を牽引したのが本居宣長である¹²。宣長は、『古事記』をはじめとする古代文献の精密な記述分析を通じて、日本語の文法構造、とりわけ「係結（かかりむすび）」の法則性に客観的な規則が働いていることを帰納的に突き止めた¹²。そして明和8年に成立した『てにをは紐鏡』において、これらの係結関係を網羅的に1枚の図表へと視覚化した¹²。

宣長は文中の係り要素を「は、も、徒（ただ：助詞を伴わない形）」、「ぞ、の、や、何（なに）」、「こそ」という3つの明瞭な系列に分類し、それに対応する結びの活用形（終止形・連体形・已然形に相当する形態）の関係性を43段にわたり整理・図式化した¹²。さらに、この図式的成果を基盤として、具体的な古典の用例をもって各助詞の実際の用法を実証的に裏付けた『詞玉緒』を刊行した¹²。

このような本居宣長による「てにをは」の体系化は、後世の文法書や解説書に広範な影響を与えた¹¹。例えば、寛政10年に珠阿弥（元木網）が刊行した初心者向けの和歌解説書『詞のもとすえ』の改題再版本などは、宣長の『てにをは紐鏡』や『詞の玉緒』、さらには実用的な語彙・文法解説を含む『玉あられ』や、富士谷成章の先駆的な文法書『あゆひ抄』などの記述を多分に引用・折衷しながら構成されている¹¹。歌学から国学へのこの学術的転回は、「てにをは」を単なる修辞技法から、日本語独自の論理構造を記述するための学術的文法体系へと止揚させた重要なマイルストーンであった¹¹。

現代日本語における助詞の機能分類と統語・意味論的対比

現代の日本語学および日本語教育において、「てにをは」を構成する助詞は、文法構造における役割と機能の差異に基づいて「格助詞」「副助詞」「接続助詞」「終助詞」の4つに大別される⁴。これらは、単に形式的に分類されるだけでなく、書き手の意図や事態の捉え方を反映するための多様な意味論的・語用論的対比構造を内包している¹⁷。

これらの対比から明らかなように、現代日本語における「てにをは」の選択は、文の論理的な意味（命題レベル）を伝達するだけでなく、話し手の心理的態度や格式（伝達レベル）をも同時に規定する、極めて動的な表現制御システムとして機能している⁵。

文章表現・推敲の実務における「てにをは」の制御と修辞技術

実務的な文書作成や文芸創作の現場において、「てにをは」を十全に使いこなすことは、文章の可読性および表現力を決定づける一大要素である⁵。推敲段階における助詞の精密な調整と、構造的な統語管理の技術は、プロフェッショナルな表現行為において不可欠な役割を果たす²²。

助詞の連続使用と認知的負荷の回避

実務文書や創作物において最も頻繁に観察される文章の不全は、同一助詞の過度な連続によるものである²⁷。特に属格の「の」が「AのBのCのD」のように3回以上連続すると、名詞同士の修飾・被修飾関係（依存構造）が多層化・曖昧化し、読み手の読解を著しく阻害する²⁷。この問題は、文章を書く際に「話し言葉」の即興的な流れに身を任せて執筆することが直接的な誘因となる³⁰。

これを解消する推敲の技術として、第一に「名詞表現の動詞表現化」が挙げられる³⁰。「〜の〜の予約」を「〜がよく行く店の予約」のように、関係節（動詞修飾句）へと組み替えることで、名詞の連続と「の」の使用率を効率的に引き下げることができる³⁰。第二に、一文の長さを適切にコントロールし、冗長な一文を複数の短い文へと分割する「文の仕立て直し」が効果的である²⁸。一文における同一助詞の使用回数を原則2回までに留め、3回以上の重複を避けるという数値的管理は、文章を論理的かつスッキリと整えるための実用的な指針となる²⁸。

ただし、こうした文法的洗練の規範をあえて逆手に取ることで、特殊な効果をあげる修辞技術も存在する²⁸。例えば推理小説（ミステリー）において、読者を意図的にミスリードに陥れたい場合、あえて「の」を多重に連続させて事態の階層構造を曖昧にし、叙述トリックを仕掛けるという高等技術も知られている²⁸。

構造的な不全を排する推敲のタイムマネジメントと実務指針

「てにをは」をはじめとする細部の不全や、主語・述語のねじれ（主述の照応関係の崩れ）を完全に排除するためには、推敲プロセスの制度化が極めて有効である²⁵。

こうした組織的な推敲手法の実践は、単なるケアレスミスの排除にとどまらず、文章全体の論理的密度を高め、書き手が意図した通りのニュアンスを読者に正確にデリバリーするための強固な担保となる⁵。

結言

「てにをは」は、日本語の黎明期において外来の高度な思想体系（漢文）を消化・受容する訓読符号「ヲコト点」として誕生して以来、常に日本語の論理的表現力を背後から支え続けてきた基盤システムである¹。中世の歌学的洗練を経て、近世の国学による実証的研究によって科学的な文法記述の対象へと昇華し、現代の高度な日本語記述言語学へと結実したその軌跡は、日本語という言語そのものの主体的な進化プロセスをそのまま体現している¹。

日常的な文章表現から学術・文芸的創作に至るまで、「てにをは」を統制する技術は、文章の品質を根底から決定づける²²。執筆者が日本語の各種助詞における意味論的・語用論的機能の深層（「は」と「が」における主題と主格の差異など）を理論的に把握し、さらに推敲過程において体系的かつ機械的なチェック体制（「の」の連続制限や主述の近接化など）を構築することは、言語の信頼性と情緒的感染力を極限まで高めるための王道に他ならない¹⁸。

引用文献

1. てにをはとは？ 意味や使い方 – コトバンク, https://kotobank.jp/word/%E3%81%A6%E3%81%AB%E3%82%92%E3%81%AF-1187578
2. 「てにをは」とは｜使い方と「おかしい」と言われない勉強方法を解説 | ライターズHub, https://writers-hub.com/2548/
3. 「てにをは」とは？意味や正しい使い方、使用時の注意点について徹底解説 – Oggi.jp, https://oggi.jp/7697368
4. 助詞について, https://ocw.nagoya-u.jp/files/144/zyoshi.pdf
5. 今さら聞けない！「てにをは」って何だろう？ | 自費出版の幻冬舎ルネッサンス, https://www.gentosha-book.com/method/trivia/whats-tenioha/
6. てにをはの意味とは? 助詞? 使い方を例文でわかりやすく解説 – マイナビニュース, https://news.mynavi.jp/article/20220602-2350909/
7. https://www.gentosha-book.com/method/trivia/whats-tenioha/#:~:text=%E3%82%82%E3%81%A8%E3%82%82%E3%81%A8%E3%80%8C%E3%81%A6%E3%81%AB%E3%82%92%E3%81%AF,%E4%BD%BF%E3%82%8F%E3%82%8C%E3%82%8B%E3%81%93%E3%81%A8%E3%82%82%E3%81%82%E3%82%8A%E3%81%BE%E3%81%99%E3%80%82
8. ヲコト点 – Wikipedia, https://ja.wikipedia.org/wiki/%E3%83%B2%E3%82%B3%E3%83%88%E7%82%B9
9. 「てにをは」とは？その意味と具体的な使い方について紹介, https://c-edge.jp/column/tenioha/
10. ヲコト点の座標表現 – 国立歴史民俗博物館学術情報リポジトリ, https://rekihaku.repo.nii.ac.jp/record/2199/files/kenkyuhokoku_192_08.pdf
11. 所蔵資料展示 – 三重大学附属図書館, https://www.lib.mie-u.ac.jp/tenji202212.pdf
12. てにをは紐鏡(テニヲハヒモカガミ)とは？ 意味や使い方 – コトバンク, https://kotobank.jp/word/%E3%81%A6%E3%81%AB%E3%82%92%E3%81%AF%E7%B4%90%E9%8F%A1-101258
13. 本居宣長について, https://www.norinagakinenkan.com/pages/40/
14. キーワードで宣長さんを知る「三十六の窓」, https://www.norinagakinenkan.com/pages/59/
15. 助詞の分類 – 北海道教育大学学術リポジトリ, https://hokkyodai.repo.nii.ac.jp/record/596/files/10-1-A-04.pdf
16. 助詞4種類の見分け方をマスターせよ【格助詞】【副助詞】【終助詞】【接続助詞】【中学国語文法】, https://gakonai.com/joshi1/
17. ライターなら知っておきたい「てにをは(助詞)」の使い方 – 株式会社乙栄商会, https://otoei.co.jp/%E3%83%A9%E3%82%A4%E3%82%BF%E3%83%BC%E3%81%AA%E3%82%89%E7%9F%A5%E3%81%A3%E3%81%A6%E3%81%8A%E3%81%8D%E3%81%9F%E3%81%84%E3%80%8C%E3%81%A6%E3%81%AB%E3%82%92%E3%81%AF%E5%8A%A9%E8%A9%9E%E3%80%8D%E3%81%AE/
18. 「うなぎ文」に新提案？ 「は」と「が」の基本を解説！ – TCJ日本語教師養成講座, https://xn--euts3n8lg6bk91h.jp.net/tcj-column/%E3%80%8C%E3%81%86%E3%81%AA%E3%81%8E%E6%96%87%E3%80%8D%E3%81%AB%E6%96%B0%E6%8F%90%E6%A1%88%EF%BC%9F-%E3%80%8C%E3%81%AF%E3%80%8D%E3%81%A8%E3%80%8C%E3%81%8C%E3%80%8D%E3%81%AE%E5%9F%BA%E6%9C%AC%E3%82%92/
19. 『は』と『が』の一歩進んだ教え方, https://www.9640.jp/MATERIALS/20190216slide.pdf
20. 「は」と「が」の違いを人に説明できるか？【文章術017】｜いのうえ あきら – note, https://note.com/akira_e_noway/n/nee06fdda7e66
21. 「は」と「が」の違いに悩む前に知っておきたいこと【３つ】 – Chaso Blog, https://chasoblogjapan.com/hatoga/
22. 文章における「てにをは」の正しい使い方とは – かくたまブログ, https://cakutama.com/blog/marketing/how-use-teniwoha.html
23. 助詞（てにをは）の正しい使い方とは？種類と意味、使い分けを解説 – 神楽坂編集室, https://kagurazaka-editors.jp/particle/
24. 意識して「てにをは」を使い分けていますか？ – 鳥影社, https://www.choeisha.com/column/column30.html
25. 長編にも使える！ 小説の推敲・校正のポイントとコツ｜文章力向上テクニックをプロ小説家が紹介します | 小説家デビューを叶える書き方を指導 – 榎本メソッド小説講座, https://enomotomethod.jp/column/novel-proofreading-elaboration/
26. 文章をチェック・校正・推敲・添削するコツがつかめる参考サイト – 株式会社ディーエスブランド, https://ds-b.jp/dsmagazine/pages/410/
27. 文章でやりがちな「なんとなくの『が』」と「『の』の連続使用」に注意 – 日本実業出版社, https://www.njg.co.jp/column/column-29900/
28. 974.筆洗篇：助詞「の」を極力連続させない解決法【No.87補講】 – 三百枚書けるようになるお得な「小説の書き方」コラム（カイ壬） – カクヨム, https://kakuyomu.jp/works/1177354054889417588/episodes/1177354054892812909
29. 第39回＞一文を整える⑮〜助詞「は」「が」「の」の連続/「〇〇のおかげ」/「〇〇のせい」/間違いやすい読み方の漢字などの注意点【文章の書き方入門講座】 – note, https://note.com/ronbun_yoritomo/n/n4a4b96f6d47d
30. 文章が読みやすくなる適切な助詞の使い方〜同じ助詞を連続で使わないための3つの方法 – 文賢マガジン, https://magazine.bun-ken.net/3137
31. 小説を書いたら絶対に推敲しよう。推敲のやり方、コツ、かける時間などを解説！(初心者向け小説の書き方の基本とルール) | 本出版ガイド, http://masterpublish.com/elaboration/
32. 【「てにをは」推敲は後回し！】まずは「大局」をみて、文章をダイエットさせよう｜Koubo – note, https://note.com/kouboguide/n/n511b78b27081

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自動操作は後段に回すことです。これが、公式ソース、学術研究、事例を重ねたときに最も整合的な導入戦略です。

本講座は、生成AIを業務に取り入れたいビジネスパーソンを対象にした通信教育講座です。ChatGPT、Gemini、Claude、Copilotなど、特定のAIツールに依存しない汎用的なテクニックを、具体的なビジネスシーンを通じて学ぶ構成となっています。

講座の特徴

本講座では、プロンプトによってAIから質の高いアウトプットを引き出す方法に加え、自身の業務フローにAIを組み込み、出力を検証・加工するための考え方を扱います。

当社は監修を通じて、生成AIを単なる文章作成ツールとしてではなく、判断材料を整理し、業務の流れに組み込むための実践知として扱う観点を提供しました。

講座情報

• 講座名: 生成AIビジネス実践テクニック50選
• 提供: 株式会社日本能率協会マネジメントセンター（JMAM）
• 開講時期: 2026年4月
• 監修: 本郷喜千（インディ・パ株式会社 代表取締役）

講座の詳細は、JMAM通信教育 Webカタログおよび当社の開講告知ページをご確認ください。

• JMAM通信教育 Webカタログ: https://www.jmam.co.jp/tsukyocatalog/course/gat.htm
• 当社の開講告知: https://indepa.net/correspondence-education-course-50-practical-generative-ai-b/

生成AI研修、AI活用講座、意思決定をテーマにした登壇・監修のご相談は、お問い合わせページからご連絡ください。

インディ・パ株式会社 代表 本郷喜千の新刊『NotebookLM意思決定の強化書』の発売を記念し、オンラインセミナー「NotebookLM活用講座」を開催します。

本講座では、NotebookLMを単なる要約ツールとしてではなく、ビジネス上の意思決定を支援するための実践ツールとして活用する方法を解説します。

書籍『NotebookLM意思決定の強化書』では、意思決定を「根拠・前提・結論」の3層で捉え、資料やデータをもとに、どの前提で、どのように結論を導くのかを整理する方法を紹介しています。

今回のセミナーでは、この考え方をもとに、NotebookLMを使いながら、実務で使える意思決定プロセスを体験していただきます。

具体的には、以下のような成果物を作成しながら進めます。

• 定義辞書
• 前提リスト
• 選択肢表
• 採点表
• 決定書

AIに判断を丸投げするのではなく、人間が前提を言語化し、根拠を確認しながら結論を組み立てる。そのためのNotebookLM活用法を、実務に近い形で学べる内容です。

本講座は、板橋区立企業活性化センターの講座として開催されますが、在住・在勤を問わず、どなたでも参加できます。オンライン開催のため、全国からご参加いただけます。

開催概要

講座名：NotebookLM活用講座
形式：オンライン開催（Zoom）
日時：
第1回　2026年6月23日（火）19:00〜21:00
第2回　2026年6月30日（火）19:00〜21:00

参加費：9,800円
準備するもの：Googleアカウント、NotebookLM、Zoom、PC
※NotebookLMは無料版でもご参加いただけます。

このような方におすすめです

• NotebookLMを業務で活用したい方
• AIの回答を、根拠を確認しながら使いたい方
• 会議や企画検討で、結論がまとまらず困ることがある方
• 事業継続・撤退、提案方針、施策選定などの判断を整理したい方
• AIを使った意思決定支援に関心のある方

お申し込み

詳細・お申し込みは、下記ページをご確認ください。

https://www.itabashi-kigyou.jp/%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC/notbooklm%E6%B4%BB%E7%94%A8%E8%AC%9B%E5%BA%A7

皆さまのご参加をお待ちしております。

より厳密に言えば、図解とは「対象の意味構造を、視覚的な構造へ写像する行為」です。
ここで重要なのは、図解は対象そのものではなく、対象についての一つの解釈である、という点です。何を要素と見なし、どの関係を強調し、何を省略するかによって、図解の意味は変わります。

1. 要素

図解の基本要素は、大きく分けると「内容要素」と「表現要素」に分かれます。

内容要素とは、図解される対象を構成する意味上の単位です。人物、組織、概念、工程、原因、結果、課題、手段、条件、時間、場所、数値などがこれにあたります。たとえばビジネスモデルを図解する場合、「顧客」「提供価値」「収益源」「コスト」「流通経路」などが内容要素になります。

表現要素とは、それらの意味を視覚的に表すための部品です。箱、丸、線、矢印、ラベル、色、余白、位置、大きさ、アイコン、囲み、軸、番号、階層線などです。これらは単なる装飾ではなく、意味を運ぶ記号です。たとえば、矢印は方向性、囲みはまとまり、上下配置は階層、左右配置は順序、色分けは分類や強調を示します。

図解における要素は、ただ並べればよいものではありません。要素は「何を単位として切り出すか」によって決まります。切り出し方が粗すぎれば曖昧になり、細かすぎれば読めなくなります。したがって図解の要素設計では、対象の本質に対して適切な粒度を選ぶことが重要です。

2. 関係

図解の本質は、要素そのものよりも、要素間の関係にあります。図解は「Aがある」「Bがある」と示すだけでは不十分で、AとBがどのようにつながっているのかを明示することで意味を持ちます。

関係にはいくつかの種類があります。

第一に、包含関係です。全体と部分、上位概念と下位概念、カテゴリと項目の関係です。これは階層図、ツリー図、ピラミッド図などで表されます。

第二に、因果関係です。ある要素が別の要素を引き起こす、促進する、阻害する、条件づけるといった関係です。これは矢印、因果ループ、フローチャートなどで表されます。

第三に、順序関係です。時間の流れ、工程、手順、段階、フェーズなどです。これはタイムライン、プロセス図、ステップ図などで表されます。

第四に、対立・比較関係です。AとBの違い、メリットとデメリット、現状と理想、原因と対策、自社と競合などです。これはマトリクス、対比表、二軸図などで表されます。

第五に、相互依存関係です。複数の要素が互いに影響し合う関係です。これはネットワーク図、システム図、循環図などで表されます。

このように、図解は関係の種類を視覚形式に変換するものです。逆に言えば、関係の種類が曖昧なまま図を描くと、図はそれらしく見えても、理解を助けるどころか誤解を生みます。

特に注意すべきなのは、矢印です。矢印は便利ですが、読者は矢印を見ると、しばしば「時間順」「因果」「依存」「移動」「影響」などを勝手に読み込みます。したがって、矢印が何を意味するのかを明示しない図解は、意味が不安定になります。

3. 構造

図解の構造とは、要素と関係をどのような全体形式に組み上げるかを指します。構造は、図解の読み方そのものを決定します。

代表的な構造には、ツリー構造、フロー構造、マトリクス構造、ネットワーク構造、循環構造、階層構造、二軸構造、中心放射構造などがあります。

ツリー構造は、全体を分解して把握するのに適しています。概念整理、分類、組織構造、目次構成などに向いています。

フロー構造は、時間や手順を表すのに適しています。業務プロセス、意思決定、ユーザー行動、作業手順などを説明する場合に有効です。

マトリクス構造は、複数の観点を交差させて比較するのに適しています。重要度と緊急度、コストと効果、難易度と優先度など、二つ以上の評価軸で対象を整理する場合に使われます。

ネットワーク構造は、多対多の関係を表すのに適しています。人間関係、利害関係、情報流通、システム連携などを示すときに有効です。ただし、複雑になりやすいため、視認性の管理が難しい形式でもあります。

循環構造は、反復やフィードバックを表すのに適しています。PDCA、エコシステム、習慣形成、資源循環、学習サイクルなどを説明する場合に使われます。

二軸構造は、対象の位置づけを直感的に示すのに適しています。ポジショニング、類型化、戦略整理などでよく使われます。ただし、軸の設定が恣意的だと、図全体が強引な整理になります。

構造の選択は、図解の思想そのものです。同じ情報でも、ツリーで描けば「分類」として読まれ、フローで描けば「順序」として読まれ、マトリクスで描けば「比較」として読まれます。したがって図解では、「どの構造を使うか」が「何を伝えるか」とほぼ同義になります。

4. 機能

図解の機能は、主に五つあります。

第一に、理解の機能です。複雑な対象を視覚的に整理し、全体像を把握しやすくします。文章は時間的に順番に読む表現ですが、図解は複数の要素を同時に提示できます。そのため、構造や関係を一目で捉えることができます。

第二に、圧縮の機能です。長い文章で説明しなければならない関係を、図解は短時間で示すことができます。ただし、これは情報量を減らすというより、情報の構造を圧縮するという意味です。よい図解は、省略しているにもかかわらず、意味の骨格を失いません。

第三に、比較の機能です。複数の対象を同じ枠組みに配置することで、差異や共通点が見えやすくなります。表やマトリクスはその典型です。比較可能性をつくることは、図解の重要な機能です。

第四に、発見の機能です。図解は説明のためだけでなく、思考のためにも使われます。要素を配置し、関係を結んでいく過程で、欠落、重複、矛盾、因果の飛躍、分類の不整合が見えてきます。つまり図解は、完成した理解を表すものではなく、理解をつくる道具でもあります。

第五に、共有の機能です。複数人が同じ図を見ながら議論することで、認識のズレを可視化できます。文章だけでは見逃される前提の違いも、図にすると顕在化しやすい。会議、企画、教育、設計、戦略立案などで図解が有効なのはこのためです。

ただし、図解には危険もあります。図解はわかりやすさを生む一方で、過剰な単純化も生みます。複雑な問題をきれいな図にすると、あたかも問題が解決したかのように見えることがあります。これは図解の効能であると同時に、罠でもあります。

5. 原理

図解の原理は、「意味を空間に変換すること」にあります。抽象的な関係を、位置、距離、方向、大きさ、形、色、線によって知覚可能にする。これが図解の根本原理です。

第一の原理は、抽象化です。図解は対象のすべてを描くものではありません。重要な要素を選び、不要な細部を捨てます。したがって、図解には必ず編集が入ります。よい図解は、単に情報を減らすのではなく、目的に照らして本質的な情報だけを残します。

第二の原理は、関係の明示です。図解では、要素の存在よりも、要素間の関係が重要です。何が何に含まれるのか、何が何を生むのか、何が何と対立するのか、何がどの順序で進むのか。これらを視覚的に明示することで、図解は説明力を持ちます。

第三の原理は、空間意味の一貫性です。上にあるものは上位、右にあるものは後続、近いものは関連が強い、大きいものは重要、同じ色のものは同じ種類、といった読み取りが自然に発生します。したがって、図解では配置や色を気分で変えてはいけません。視覚的な差異は、意味上の差異と対応している必要があります。

第四の原理は、粒度の統一です。同じ階層に置かれた要素は、同程度の抽象度でなければなりません。たとえば「売上向上」「広告」「営業担当者のモチベーション」を同列に並べると、目的、手段、状態が混在します。このような粒度の乱れは、図解の論理を壊します。

第五の原理は、認知負荷の制御です。図解は見ればすぐわかるように見える必要がありますが、実際には読者の視線誘導、情報量、余白、ラベル、凡例、色数、線の交差などを慎重に設計する必要があります。図解が複雑すぎると、文章よりも理解しづらくなります。

第六の原理は、目的適合性です。図解には、説明する図解、比較する図解、分類する図解、発見する図解、説得する図解、記録する図解があります。目的が違えば、適切な形式も違います。すべてを一つの図に詰め込もうとすると、たいてい失敗します。

第七の原理は、検証可能性です。図解は見た目が整っているだけでは不十分です。要素の分類は妥当か、関係は正しいか、因果と相関を混同していないか、抜けや重複はないか、読者が別の意味に読まないかを検証する必要があります。美しい図と正しい図は同じではありません。

図解の本質

図解の本質は、「見える化」ではなく「構造化」です。

見える化という言葉は便利ですが、やや曖昧です。単に情報を見える形にしただけでは、図解とは言えません。図解とは、情報の背後にある構造を取り出し、その構造が読者に伝わるように視覚形式へ変換することです。

したがって、図解とは次のように定義できます。

図解とは、ある対象について、要素を抽出し、関係を定義し、構造を与え、視覚表現によって理解・比較・説明・発見を可能にする知的操作である。

ここでの「図」は表現であり、「解」は解釈です。
つまり図解とは、図を描く技術である以前に、対象をどう理解するかという思考の技術です。