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

はじめに

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

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

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

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

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

前回までのあらすじ

本編では、生成AIとの相性、契約、使い方を追ってきた。AI大奥外伝は、癖の違うAIへ役を振り、ひとつの仕事を完成までつなぐ試みの記録である。

最初の問いは、誰が一番できるかから、誰に何を任せ、誰が確かめるかへ変わった。その立ち上げを、この篇から記していく。

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

一極集中

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

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

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

作業制御

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

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

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

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

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

禁止札の増殖

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

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

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

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

配役を決めたのは拙者だった

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

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

費用の重なり

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

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

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

同じ資料を何人に読ませるか

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

能力と残量は、分けて見る。枠が余っていることは、能力の証明ではない。能力が高いことも、その仕事へ毎回最高性能を使う理由にはならない。大奥は、複数契約を重複したお小遣いから役割別の予算へ変える試みだった。

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

検収分離

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

途中で拙者が「待て」と声をかけたら、古い段取りに固執せず、その場で足を止めて新しい指図に合わせ直す。人間の職人を相手にするなら当たり前の作法だが、AI相手にはどこか曖昧にしていた。もう一つ大きかったのは、他の娘の「できました」という口上をそのまま鵜呑みにしない姿勢だった。「反映済み」「検証済み」「全件一致」と報告が上がってきても、必ず蔵を開けて実物の文面や帳面を自分の目で確かめ直す。相手を疑うというより、言葉ではなく実物の証拠で仕事を閉じる作法である。

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

Codexを総取締役に据えた

配役表

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

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

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

2026年7月の立ち上げ時に、期待した配役は次のとおりだった。

大奥での役目	AI／道具	期待した仕事
上様（主）	人間（拙者）	目的の裁定、掟、最終承認、表舞台への責任
総取締役	Codex	仕事の切り分け、配役、検収条件、品の統合、実物照合
文章職人	Claude	大量の書状の読解、骨子案、長文の仕立て
仕入れ方	Grok	世間の一次発信と生きた情報の早馬探索
構造目付役	Gemini	論理の飛躍、矛盾、大袈裟な表現の突き崩し
離れの探索役	Perplexity	広い探索と確かな出典の発掘
帳場・関所	決まりきったからくり（台帳・関所）	実行台帳、納品物、完了状態、受入の関所

必要な相手だけを呼ぶ

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

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

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

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

小試験

2026年7月21日、まずは小さな試し運転を行った。三人の娘を同時に走らせてみると、一人ずつ順番に仕事を渡すよりずっと早く品が揃い、あらかじめ設けた関所の条件も無事に通過した。むろん、一度の小さな試しにすぎないが、手応えは悪くなかった。

別の長い書状でも試してみた。文章案と事実確認は上がったが、目付役（構造監査）の書式が関所の定めと合わず、仕事はそこでピタリと止まった。必要な品が欠けたまま「完成」として通すような真似はしなかった。

この停止は、むしろ好材料に見えた。出力形式が合わない構造監査をCodexが自分で補えば、別の目で確かめるという分業が崩れる。今回は不足が不足として残った。誰の成果物が欠け、どこで止まったかも見えた。拙者はそこに、組織としての進歩を感じた。

この二つの試験で、担当を分けて動かせることと、不足した成果を受け取らずに止まれることは確認できた。だが、止まったあとに手段を組み直し、必要な助けを求め、完成まで動き続けられるかは、まだ見ていなかった。それでも拙者には、一人の天才へ依存しない方法が見えた気がした。

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

総取締役の実地試験

順位表ではない

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

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

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

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

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

あわせて読みたい

• 生成AI交際録（集合ハブ）
• AI交際記録1｜ChatGPT
• AI交際記録2｜Claude
• AI交際記録3｜Gemini
• AI交際記録4｜Perplexity
• AI交際記録5｜Copilot
• AI交際記録6｜Manus
• AI交際記録7｜Grok
• AI交際記録8｜Suno
• AI交際記録9｜Grok Bot
• AI交際記録10｜Antigravity
• AI交際記録11｜GenSpark
• AI大奥外伝1・立ち上げ篇（役職と席）
• AI大奥外伝2・炎上篇（任命と再配置）
• AI大奥外伝3・復興前夜篇（監視と采配）
• AI大奥外伝4・見習い篇（見習いと七つの門）
• AI大奥外伝6・第2回大運動会篇——1行の短冊で競う全4種目ダイジェストと14名の適材適所
• AI大奥外伝5・着任篇（選抜と着任）
• 大店モデルとBizAIOps（オーケストレーション）

FAQ