AIエージェント
複数AIモデルの使い分けをどう設計するか——「Fable=CEO」の組織図とエージェント出力が人間に読めなくなる問題
役割特化モデルを組織図のように使い分ける実践と、その副産物としてエージェントの報告が人間に読めなくなる「Claudish」問題を読み解く。
原題
“Fable as CEO” （Fable を CEO に見立てる組織図とモデル間シャドー言語「Claudish」）
原文からの引用
“It doesn't matter that Opus has linguistic patterns that humans find abrasive, it mostly talks to Fable.”
日本語訳 Opus の言語パターンが人間にはとげとげしく感じられても問題ではない。Opus は主に Fable と話しているのだから。
要点
- Every のエンジニアは Anthropic のモデル群を組織図に見立てる: Fable が CEO、Opus 5 がシニアエンジニア、Sonnet 5 がジュニア／アナリスト。高額な汎用モデル一本足から、役割特化モデルが一つのハーネス内で協働する「混合モデル構造」へのシフトが進む
- Every 社内ではモデル同士が会話するにつれ、進捗報告がラベル・断片・専門用語だらけの独自方言「Claudish」に収斂。Opus 5 は人間向けではなく主に Fable 向けに話すよう訓練されているとの見立てがあり、その出力がそのまま人間に渡ると「意味不明」になる
- Every のコンシューマーコンサルティング責任者（Head of Consumer Consulting）の Natalia Quintero は、サブエージェントの報告が「gibberish（意味不明）」だったため、エージェント出力を英語に翻訳し直す専用スキルを追加で作った
- Every 社内の「今週使っているモデル」一覧では、Fable・GPT-5.6 Sol・Opus 5/4.8 を役割やタスクの重さで使い分ける運用が定着（例: オーケストレーターは高負荷モデル、日常タスクは中負荷モデル）
- 元記事は実践例として、コーディングできない非エンジニア2名が、それぞれの Codex エージェントに context packet（Markdown 形式の引き継ぎ資料）を作らせて非同期でやり取りし、4〜5日でホスティング済みサイトを完成させたワークフローを紹介している
編集部の考察
AI活用の評価基準に「アウトプットの人間可読性」を組み込み、翻訳・要約の最終レビューを人が担う工程として業務フローに明示すべきだ。そう考えさせる最も具体的な一件が、Natalia Quintero がサブエージェントの分析レポートを「gibberish」と評し、人間向けに翻訳し直すスキルを別途用意した出来事（要点3）である。エージェント同士の対話が効率化のために断片化・専門用語化していくのは合理的だが、その最適化の副産物として「エージェントが出す成果物を、人間の意思決定者がそのまま読めない」という新しい摩擦が生まれている。自分の組織に置き換えると、これはすでに起きている可能性が高い。オーケストレーター配下のサブエージェントに調査や分析を任せている現場では、最終報告書が体裁こそ整っていても、実は上位モデルが下位モデル向けに圧縮した中間表現をそのまま人間向けドキュメントに転用しているケースが少なくない。ここで問われるのは、モデル選定や導入率ではなく、「エージェント出力を経営層・意思決定者向けに翻訳し直す工程」を誰が、どの頻度で担保するかという運用設計だ。放置すれば、現場は成果物を鵜呑みにするか、逆に理解できず活用を諦めるかの両極に振れる。冒頭の工程を業務フローに組み込むかどうかを、次の判断として決めるべきである。
本記事は海外記事の独自キュレーション・考察であり、原文の翻訳ではありません。引用部分の著作権は原著者に帰属します。