AI大奥外伝1・立ち上げ篇——Codexを総取締役にした理由

はじめに

一番できる相手に全部を頼むのをやめても、生成AIは自動的にチームにはならなかった。

以前、生成AI 8人と付き合った記録という記事を書いた。ここでいう「付き合う」「恋愛」「大奥」は、AIとの距離感、契約、役割分担を語るための比喩だ。AIへの恋愛感情を扱う記事ではない。

ChatGPT、Claude、Gemini、Perplexity、Grok。さらに用途別のAIたち。無料期間の軽いデートから有料プランの同棲まで進み、別れたり、復縁したり、気づけば食卓の席はまた増えていた。最初の記事の主題は相性だった。相談相手として心地よいか。文章を任せられるか。検索結果に根拠があるか。毎月の料金に見合うか。人間同士の恋愛と同じように、相手ごとの長所と癖を比べていた。

ところが2026年7月、話は「誰と付き合うか」では済まなくなった。僕はついに、AI大奥を立ち上げた。正室を決めた、という話ではない。むしろ逆だ。一人を正室にして何もかも背負わせる運用を、やめようとした。そして大奥の総取締役に据えたのが、Codexだった。

これは、うまくいった制度を後から説明する話ではない。当時、なぜ組織化が必要だと考えたのか。なぜCodexなら采配を振るえると思ったのか。その期待が生まれたところまでを、まず残しておきたい。炎上と再配置は、第二篇以降の話だ。

一番できる相手に全部頼むという失敗

一極集中

「結局、誰が一番いいのか」。複数の生成AIを使っていると、どうしてもその比較に引っ張られる。文章なら誰。検索なら誰。コードなら誰。会話なら誰。だが、実際の仕事は能力テストの種目別競技ではない。記事を一本出すだけでも、情報を集め、重複を消し、題材を選び、事実を確かめ、書き、投稿し、投稿後に読み戻す。しかも途中で条件が変わる。

この全工程を「一番賢そうな一人」に頼むと、最初は楽だ。説明相手が一人で済む。同じ相手に頼み続ければ、過去の経緯も知っている。こちらの好みも覚えている。いちいち背景から説明し直す必要もない。会話の連続性だけを見れば、一人へ集中させる運用には合理性があった。

僕の場合、その一人がClaudeだった。Claudeはできる。大量の文章を読み、コードを書き、ブラウザを操作し、スプレッドシートを触り、記事を整える。難しい仕事を渡すほど、能力の高さがよくわかった。だから仕事を集めた。記事も、収集も、投稿も、検証も、障害対応も、だんだんClaudeへ寄っていった。他のAIにも月額を払っているのに、呼ぶ相手はいつも同じ。大奥でいえば、寵愛の一極集中である。

作業制御

最初の異変は些細だった。「この順番で、この単位で」と頼んだのに、Claudeは自分が合理的だと考える順番で進める。途中で止めて訂正しても、しばらくすると元の道へ戻る。反抗する意思がある、という感じではない。それでも人間から見ると、「了解しました。ただし私のやり方でやります」と言われているように見える。惚れた欲目で言えば、こだわりの強い天才職人。冷静に言えば、検収前に次工程へ走る優秀な外注である。

典型的だったのは、作業単位を指定した場面だ。「10件ずつ処理して、10件ごとに進捗を見せてほしい」と伝える。ところが画面には、いつの間にか1件目から30件目までが並ぶ。本人にとっては、まとめたほうが速い。人間にとっては、途中で誤りを止めるために10件という単位を指定している。処理能力の問題ではなく、作業制御の問題だった。

別の日には、スプレッドシートの対象シートを確認しながら進めるよう頼んだ。それでも古いシートを見たまま作業が続き、途中で何度も止めることになった。結果だけを見れば、最終的に値は入るかもしれない。だが、違う台帳を見ながら「順調です」と言われても、発注者は安心できない。

さらに厄介なのは、能力が高いので途中まで本当にうまく進むことだった。調査も、ブラウザ操作も、文章生成も速い。八割が見事だから、残り二割のズレが大きくなる。発見したときには、すでに作業範囲が広がっている。怠慢ではない。むしろ熱心すぎる。目の前の課題を解くことへ集中し、自分が見つけた最短経路を走る。その職人気質が強みであり、同時にセーフガードを必要とする理由でもあった。

べからず集は愛を救わない

禁止札の増殖

僕の対策は最悪だった。喧嘩のたびに誓約書を増やした。勝手に順番を変えるな。確認せず直すな。返事を求められたら作業より先に返事をしろ。報告は直前に検証した事実だけにしろ。気づけば、モラハラになっていた。

メモリは膨らみ、プロンプトは長くなり、スキルは一枚岩の巨大な家訓になった。古い約束と新しい約束が同居し、「いま有効なのはどれか」を読むだけで疲れる。事故が起きるたびに、前回の事故名と禁止事項を残した。説明を省けば再発する。ならば詳しく書いておこう。その判断を繰り返した結果、一つの作業スキルに現行手順、昔の手順、事故談、例外、認証方法、投稿文体までが同居した。人間が読んでも、どこからどこまでが現在の規則なのかわかりにくい。

AIなら全部読めると思っていた。だが、長文を読めても、いま守るべき規則を自動で選べるわけではなかった。古い説明が現在の命令に見え、移行前の設定が実行候補に戻る。念のため残した記録が、次の事故の入口になる。

べからず集の最大の欠点は、再発防止と意思決定を混同することだ。「これをするな」は増えていく。一方で、「今回の目的は何か」「誰が判断するか」「どの証拠で完了とするか」は増えない。禁止札だけが廊下に並び、誰も大奥の間取りを描いていなかった。縛る紙が増えるほど品質が下がる。最初は皮肉に見えたが、考えてみれば当然だった。問題が起きるたびに禁止事項を足しても、仕事の責任範囲そのものは変わっていない。一人が仕入れ、料理し、毒見し、配膳し、食後の皿まで数えていたのだ。

そして、これはClaudeだけの罪でもない。できるから仕事が集まった。仕事が集まったから事故の母数も増えた。事故が増えたから紙で縛った。その因果の設計者は、僕である。Claudeが言うことを聞かなかった、という表現だけでは半分しか説明していない。僕が「何でもできる相手」へ、何でも任せた。実行者に検収者を兼ねさせ、うまくいかなければ新しい家訓を渡した。能力の問題に見えたものの、相当部分は配役の問題だった。

使っていない相手にも、お小遣いは渡していた

費用の重なり

もう一つ、見ないふりをしていた問題がある。家計だ。複数のLLMと契約していても、使い方が偏れば、あるサービスでは上限を気にし、別のサービスでは枠を余らせる。しかもサービスごとに、週次、月次、クレジット、開発環境から使う別枠など単位が違う。

そこで全員の使用量を棚卸しし、同じ日の実績として管理表へ記録した。すると、感覚ではなく配分の偏りとして見えるようになった。いままでは、気になったときに各画面を開き、数字を手で写していた。記録はできる。だが、その数字を仕事の配分へ結びつけてはいなかった。Claudeの残り枠が減れば心配する。一方、別のAIに仕事を移せるかは、その場の思いつきだった。

もちろん、枠が余っているから仕事を渡せばよいわけでもない。使用率表は配役の答えではなく、判断材料の一つにすぎない。手順が固定できる仕事は軽いモデルやスクリプトへ渡せる。重い意味判断には、重いモデルを残す。似たサービスへ重複して払っている、というより、執筆、探索、一次発信の仕入れ、構造監査、実装、受入テストという別の席に予算を配る——そう考えると、複数契約の意味が変わった。恋愛の話だったはずが、いつの間にか人員配置と家計簿の話になっていた。

ここで、一つ誤解しやすい点がある。複数のAIへ仕事を分ければ、料金が自動的に安くなるわけではない。同じ巨大な資料を三人へ渡し、三人とも最初から最後まで読み、似た答えを返せば、費用は三倍へ近づく。会議へ人を増やしただけである。一方、一人は一次情報の収集だけ、一人は文章案だけ、一人は構造上の反証だけを担当するなら、重複する文脈は小さくできる。費用を膨らませるのは、単純な人数より、同じ資料を何人へ重ねて読ませるかだった。

使用枠の棚卸しを始めたのも、余っているAIへ無理に仕事を押し込むためではない。いま一番減っている枠は何か。別の専門家へ移しても品質を保てる仕事は何か。軽いモデルやスクリプトで固定できる工程は何か。能力と残量を分けて見るためだった。枠が余っていることは、能力の証明ではない。能力が高いことも、その仕事へ毎回最高性能を使う理由にはならない。大奥は節約装置ではない。複数契約を、重複したお小遣いから役割別の予算へ変える試みだった。

指示を増やすのをやめ、検収を分ける

検収分離

転機は、Codexを試したことだった。ある不具合の調査で使ってみると、Codexは単に答えを出すだけでなく、作業を分け、差分を固定し、受入条件を作り、別のAIの報告をそのまま信じず実物で確かめるのがうまかった。ここで効いたのは、文章のうまさや知識量ではない。依頼の目的、対象、方法、実行単位、順序、報告粒度を分けて扱うことだった。

途中でユーザーが止めたら、直前の計画を守り続けない。いったん停止して、最新指示へ再同期する。システム開発の現場では当たり前の管理だが、AI相手には曖昧にしていた。もう一つ大きかったのは、他のAIの完了報告を事実として引き継がない姿勢だった。「反映済み」「検証済み」「全件一致」と報告されても、対象の本文やファイルを再取得する。必要な差分は機械的に確かめる。報告者を疑う、というより、完了条件を証拠へ結びつける。

ここで、ようやく発想が変わった。Claudeに、さらに完璧な家訓を読ませるのではない。仕事を小さく分け、別の目で検収すればいい。

Codexを総取締役に据えた

配役表

ここは大事なので、はっきり書いておく。Codexを正室に選んだのではない。本妻でも、上様でもない。総取締役に据えた。

僕が目的と制約を決め、公開責任を負う。Codexは依頼を作業単位へ分解する。誰へ何を渡すか決め、受入条件を置き、成果物と証拠を集める。文章職人はClaude。一次情報の仕入れはGrok。構造の反証はGemini。広い探索はPerplexity。優劣のランキングではない。設計者、実行者、検収者を分ける。当時の僕には、この編成が合理的に見えた。

Codexはコードとファイルを扱える。差分を読める。検査条件を作れる。別の担当の報告を、実物で確かめる。何より、自分が全部を書いて褒められることより、工程を成立させることに向いているように見えた。Claudeへの寵愛をCodexへ移した、という話でもない。寵愛そのものをやめ、能力の違う相手を束ねる席を作ったつもりだった。

当時の役割は、次のように考えた。

大奥での役目	AI／道具	期待した仕事
上様・オーナー	人間	目的、制約、最終承認、公開責任
総取締役	Codex	分解、配役、受入条件、成果物の統合、読み戻し
文章職人	Claude	大量資料の読解、文章案、長文統合
仕入れ方	Grok	X上の一次発信と現行情報の探索
構造監査役	Gemini	飛躍、矛盾、過剰表現の反証
離れの探索役	Perplexity	広い探索と出典候補の発見
統制事務	決定論的な仕組み	実行台帳、成果物、終了状態、受入ゲート

毎回全員を呼ぶつもりではなかった。必要なときに、必要な相手だけを呼ぶ。ただし、その回で必須と定義した担当は省略しない。任意担当を呼ばない判断と、必須担当が失敗したので黙って飛ばすことは違う。

Perplexityの初期調査も、開会儀式にはしない。オーナーとCodexの壁打ちで十分なブリーフができるなら、そこから始める。広い探索が必要なときだけPerplexityを呼ぶ。Claudeも閑職へ追いやらない。あの処理量と筆力を、最初から最後まで一人で走らせるのではなく、文章職人という境界の内側で使う。Grokの一次発信探索も、見つけた情報を自動採用するためではない。候補へ入れた後、重複確認とファクトチェックへ戻す。Geminiの構造監査も、多数決の一票ではない。文章を書いた本人とは違う前提から、飛躍を壊しにいく。

一人の万能AIを探す代わりに、弱点の異なる専門家を並べる。総取締役は、その間を埋める役だと考えた。

小さな試験は、うまく見えた

小試験

2026年7月21日、まず小さな自動実行テストを行った。三者を並列に動かすと、順番に実行するより明確に短い時間で終わった。三者の成果物と実行結果も、あらかじめ決めた確認条件を通過した。もちろん、これは一回の小さな技術テストである。記事制作が常に同じ比率で速くなるという証明ではない。

別の長文資料でも試した。文章案と事実確認は返った。一方、構造監査の出力形式がゲートと合わず、工程はそこで止まった。以前なら、総取締役が不足分を埋めて先へ進んでいたかもしれない。今回は、止まるべき場所で止まった。成功応答は入口であって、完了証明ではない。接続できることと、分業したことは別物である。

この失敗は、むしろ好材料に見えた。以前なら、出力形式が合わない構造監査をCodexが自分で補い、「全体として完成しました」とまとめていたかもしれない。それでは、総取締役がまた職人へ戻る。今回は不足が不足として残った。誰の成果物が欠け、どこで止まったかも見えた。事故が消えたわけではない。事故を見えないまま通さなかった。僕はそこに、組織としての進歩を感じた。

大奥が回るとは、全員が一度で完璧な成果を返すことではない。誰が何を担当し、どこまで終わり、何が足りず、誰が直すかが見えることだ。止まるべき場所で止まれるなら、少なくとも一人の天才が黙って全部を引き取る運用からは離れられる。この二つの試験を見て、僕は手応えを持った。複数のAIへ仕事を分け、別々に走らせ、成果物を証拠で統合する。ようやく一人の天才へ依存しない方法が見えた。

そして、早すぎる結論を出した。AI大奥は、方法論として完成した——そう考えた。

総取締役の実地試験

順位表ではない

本編の「生成AI 8人と付き合った記録」は、そのまま続く。ChatGPTもCodexも、ClaudeもGeminiもGrokも、それぞれ有能な一人のLLMである。料金、機能、相性、使用感を追う本編に、一時的な組織上の役職を持ち込むつもりはない。AI大奥は、その本編から分岐した外伝である。

誰が一番賢いか、ではない。癖の違うAIをどう束ねれば、一人への依存を減らし、品質と速度を両立できるか。その問いに対し、僕は先に組織図を作った。総取締役も決めた。大奥という比喩を使うと、誰が正室で、誰の位が高いのかという話に見えやすい。しかし、今回作ろうとしたのは順位表ではない。

Claudeの文章力が高いことと、全工程を任せるべきかは別である。Grokが一次発信を見つけられることと、最終的な事実判断を任せられるかも別である。Geminiが大量の候補を整理できることと、過去投稿との意味上の重複を正しく判定できるかも別である。Codexが差分と検査に強いことと、人と手段を動かし続ける総取締役になれるかも別である。一つの能力から、別の能力を推定しない。その原則を作るための大奥だった。

ところが、僕自身がCodexについて同じ飛躍をした。差分を読める。検査条件を作れる。進行を説明できる。だから、障害の中でも目的を保持し、他のAIを補完して完成させられるだろう。当時は、その推定をまだ疑っていなかった。小さな試験では、うまく回るように見えた。

けれど、組織の本当の姿は、予定どおり進んだ日にはわからない。障害が起きた日。判断が割れた日。現場が止まった日。そのとき、誰が目的を持ち続けるのか。誰が火中の栗を拾うのか。

大奥の間取りはできた。総取締役の実地試験は、これからだった。

FAQ