Fable 5後の協働思考：難易度は定数であるべきだ

TL;DR：よくあるモデル割り当て器は、「どのタスクをどのモデルへ」というルールを直書きする。しかしモデルの能力は、システム全体の中で最も変わりやすいものだ。今日は大きなモデルが必要な作業も、来年には小さなモデルで十分になるかもしれない。私のやり方はこうだ。タスクの難易度をまずエラーコスト・推論の深さ・判断空間で分類し、この層はできるだけ触らない。本当に変わるのは「このカテゴリのタスクを今どのモデルに渡すのが最も合理的か」だ。だからモデル名はルールに書かない。日付つきのバインディング表に置く。

数日前、Claudeに手持ちの作業を異なるモデルへ割り当ててもらった。すぐに表ができあがった。難しいものはOpus、中程度のものはSonnet、量が多くて規則的なものはHaikuへ。この分け方は一見理にかなっている。モデルを等級の異なる道具として扱い、タスクの難易度に応じてリソースを配分する。難題には強いモデル、定型作業には軽いモデルを使えば、コストと品質の両方を満たせる。

しかし私はすかさず尋ねた。モデルが進化し続けるなら、私たちの作業フローはどう変わるのか。

今年Opusでないと安定しないタスクが、来年はSonnetで処理できるかもしれない。今日Sonnetに向いている作業も、しばらくすればHaikuの基本問題になるかもしれない。では、もとの割り当て表はどうするのか。

ここで問題が浮かび上がる。マルチモデル調停は固定表一枚では済まない。表の中で変わるのは、タスクそのものだけではなく、モデルの能力もだからだ。

変わりうる能力を、めったに更新されないルールに書き込んでしまうと、システムは徐々に狂い始める。すぐには壊れない。だがゆっくり陳腐化していく。強すぎるモデルをまだ使っているタスクもあれば、すでに下位モデルに任せられるタスクもあり、前世代モデルの能力の境界に留まったままの判断もある。

だから、マルチモデル調停の難しさは、最初の割り当て表をどう描くかにはないのかもしれない。その点についてはすでに多くの人が丁寧に語っている。

肝心なのは、この設計を組んだ後、それがすでに期限切れかどうかを誰が見るのか、という問いだ。

なぜモデル割り当て器は稼働した瞬間から腐化するのか

あの表の前提は、モデルの能力が変わらないということだからだ。しかしモデルの能力は、システム全体の中で唯一確実に「変わる」部分でもある。

「難しいものはOpus、簡単なものはHaiku」とルールに書くのは、最も動きやすいものを、最も動かすべきでない場所に釘付けにすることだ。半年後に新しいモデルが出て、以前はOpusでないとこなせなかったタスクが一段安いモデルでもできるようになる。それでもルールは旧世界に止まったままだ。結果は二つに一つ。高いモデルに簡単になった作業をやり続けさせるか、もっと安い選択肢があることに気づかないか。割り当て器は壊れていない。ただ静かに期限切れになっているだけだ。

耐久性のある割り当て器は、何を固定すべきか

まず説明しておく。割り当てという行為そのものは新しい発明ではない。計画・ルーティング・割り当て・検証・統合というフレームワークは、Anthropicの公式エージェント設計ガイドにすでに詳しく書かれている。「単純な問いは安いモデルへ、複雑なものは強いモデルへ」というルーティングも含めて。私が補いたいのは、ガイドがあまり掘り下げていない次の層だ。この割り当てをモデルの世代交代に耐えさせるにはどうするか。

私のやり方は、難易度を固定し、「どのモデルを使うか」の列は柔軟に差し替え可能な状態に保つことだ。

タスクの難易度は、タスク自体の性質であって、モデルの性質ではない。

例えば、記事の句読点を直すのは、間違えてもやり直せる。しかし契約書のリスクを判断するのは、間違えると意思決定に影響する。モデルが賢くなれば多くの作業はこなしやすくなるが、「間違えたときのコスト」が自動的に下がるわけではない。何層の論理を経るか、間違えたらどれほど高くつくか、標準的な答えがあるかどうか、これらがタスク本来の難易度だ。モデルがどれほど進歩しても、高リスクの意思決定が低リスクになることはない。変わるのは一つだけ、その難易度を今どこに渡すのが最も合理的か、だ。

だからシステムを二層に分けた。一層は難易度分類、安定しており、ほぼ変わらない。作業を「ロール」で表現する。例えば深い推論・標準生成・高スループット、といった具合に、モデル名は直書きしない。もう一層はバインディング表で、ロールを現在のモデルに対応づける。この表は変わる。変わることを明示するために、日付を付ける。

エンジニアの習慣はそのバインディング表を固定化したがる。かつては「内部設定」と呼ばれていた。しかしこの設計では、できるだけ目立つ場所に置くべきだ。

なぜなら、それはシステム全体の中で「変えてよい」と許可された唯一の場所だからだ。モデルが更新されたとき、触るのはこの表だけ。新しい日付を記し、分類ルールは一行も変えなくてよい。

「今年の山は、来年の道になる。」モデルの進化が速すぎる今、私たちにできるのは変化を止めることではない。変わるものを、小さな、日付のついた一枚のルックアップ表に集中させることだ。

もう一点、伝えておきたい。モデルの層を切り替えることだけが唯一のボタンではない。同じモデルの中でも、effortのようなパラメータで「どれだけ深く考えさせるか」を調整できる。高く設定すると答えはより安定するが、遅くなり、コストも上がる。低く設定すると速度とコストは改善するが、リスクの低いタスクに適している。Anthropicの公式モデル選定ガイドも、effortの調整はモデルを切り替えるより費用対効果が高いことが多いと指摘している。だから表に書くべき欄は実は二つある。どのモデルを使うか、そしてどれだけ力を入れさせるか。どちらも変わりうる層に属する。

難易度はどの尺で測るべきか

「モデルが十分に賢いか」ではなく、エラーコストという尺で測る。

難易度の評価軸は三つにした。推論の深さ、判断空間、そしてエラーコストで、エラーコストの重みが最も高い。これは意図的な選択だ。推論の深さと判断空間は、モデルが賢くなるにつれて相対的に縮小する。今日は頭を使う推論も、来年のモデルは一息で飲み込むかもしれない。しかし「これを間違えたらどれだけ高くつくか」はビジネスの性質であって、モデルがどれほど賢いかとは無関係だ。三つの軸の中で最も動かない一本だ。最も安定した軸に重みを置くことで、分類法はモデル更新のたびに陳腐化しない。

モデルが進化したとき、再バインドのタイミングをどう知るか

これが設計全体の中で私が最も心を砕いた部分だ。防ぎたい問題がエラーを出さないからだ。

以前、痛い目を見たことがある。あるスケジューラが毎日自動で動いていたが、ある日アップストリームが切れた。スケジューラは無音のまま止まり、パイプライン全体が静かに消えた。かなり時間が経ってから気づいた。同じリスクがここにもある。モデルが進化し、バインディングを更新すべき時が来ても、何もアラートを出してくれない。表はエラーを出さない。ただ最も合理的な選択でなくなるだけで、この種の退行はいかなるアラームも発火させない。

だから表にハートビートを与えた。実際に自分が処理するタスクから代表的な問題を約10問選び、各問に理想のロールと「何ができていれば合格か」の基準を事前に付けておく。新しいモデルがリリースされたら、このセットを丸ごと実行し、どの層を安定してこなせるかを確認する。その結果に応じて対応するロールをより安価なモデルへ移し、日付を更新して理由を一行記録する。これは私がずっと使ってきたレジリエンスの原則の実装だ。自分が依存しているあらゆる自動化は「まだ生きているか」と答えられなければならない。

マルチモデルの分業について書いたのはこれが初めてではない（マルチモデル認知協働、Fable 5の作業システムでも書いた）が、今回の焦点は誰が何をするかではなく、この分業をモデルの世代交代に耐えさせることにある。付け加えると、このルールを稼働させた日に、私は自分の設計を一度検証した。手元のタスクがツールを書くことだったり、何本もの資料を整理することだったり、サイトの機能を修正することだったりする中で、どのモデルに任せるべきか一瞬迷うことがよくある。以前は「これは難易度どれくらい」「割り当てを手伝って」と自分から聞かないと判断が起動しなかった。動作モードはもともと受動的だったが、後で能動的に切り替え、skillを新しいバージョンに更新した。もう私から聞く必要はない。今はセッションのウィンドウでタスクを渡すと、冒頭にまず一行が表示される。難易度、役割、現行モデル、そして一言の理由だ。この転換は三行の変更で済んだ。分類ロジックは一文字も触らなかった。動作モードと分類ロジックが、最初からきれいに切り分けられていたからだ。

自動で反応しないときは、トリガーフレーズで呼び出す。「どのモデルを使うべきか」「このタスクの割り当てを手伝って」といった言い方や、スラッシュコマンド /model-orchestrator を直接打つこともある。判断を得ることと、実際にモデルをまたいで実行させることは別の話だ。分派の結果を本当に走らせたいときは、「この分派を実際に走らせて」「サブエージェントで実行して」ともう一言添える必要があり、そこで初めて計画・実行・検証・統合の流れが動き出し、サブエージェントのmodelパラメータを通じてOpus、Sonnet、Haiku、Fableへとルーティングされる。メインの会話スレッドがどのモデルを使うかは、私がアプリ内で自分で選んだものであり、Claudeがそれを切り替えることはできない。モデルをまたぐ実行はサブエージェント経由のみで、メインスレッド自体を入れ替えるわけではない。この仕組みは今、私が普段コードを書いているウィンドウ（Code）ではすでに完全に機能しており、常駐させているもう二つのウィンドウ（Cowork、Chat）でもcapabilitiesをアップロードした後は使える。

将来の層収斂を前提に設計する

もう一つ、早めに準備しておくべきことがある。この三層はいつか二層に崩れる。

モデルの能力の床は上がり続け、安価なモデルが下から中間層を少しずつ食い尽くす。今日は深い推論・標準生成・高スループットの三層があっても、来年には標準生成の層ごと安価なモデルに吸収されるかもしれない。再来年には最も難しい一握りを除いて、全部同じモデルに投げるのが最も合理的になっているかもしれない。だから最初からバインディング表で複数のロールが同じモデルを指せるようにしておいた。ある層が消えても、システムは崩れない。

もっと先を見ると、判断の軸そのものが入れ替わる。今日の問いは「このタスクをこなすのに十分に賢いモデルはどれか」だ。最終的には「このエラーコストのしきい値を守れる最も安い層はどこか」になる。最初からエラーコストを主軸にする理由はここにもある。その日まで持ちこたえられる唯一の尺だからだ。これはAIというテーマで私が考え続けていることでもある。能力が急速に変化するとき、それでも耐えうる秩序をどう設計するか。

この問いはモデル割り当てだけでなく、人間自身のワークフローにも起きる。

実はこの話は、モデル割り当てよりずっと大きい。先日ある読書会の後、友人とこの半年のAI Agent体験を話した。マルチタスクが常態になった。複数のウィンドウ、複数のタスク、複数の文脈が同時に広がり、人間が同時に追うべきものも新しい上限に達した。それで私たちは二人とも、思考を整理するために手書きのノートに戻るようになった。面白いのは、ツール自体にもコントロールパネルが登場したことだ。どのウィンドウが動いていて、どれが遊んでいて、どれを読み返すべきか、一つのダッシュボードで確認できる。AIが安くて速くなると、本当のボトルネックは別のところに移る。人間がこれだけ多くの文脈を管理できるかどうかだ。あのバインディング表と同じ論理で、ツールを底で加速させながら、判断と方向感は自分でしっかり握る。手書きノートが守っているのはまさにそれだ。

最初から逃げ道を設計しておく

私はこの割り当てルールが永遠に存在すると最初から想定していない。いつかモデルのベンダーがバックエンドで割り当てを内部化し、一つのエンドポイントの中でルーティングを完結させるなら、この手動調停は引退すべきだ。いつか層が一つに収束し、全部同じモデルへ投げる方が何よりも合理的になるなら、それも引退の時だ。

この背後には計算できる帳簿がある。Anthropic自身のデータがある。一つのエージェントは単発の会話の約4倍のトークンを消費し、マルチエージェントシステムでは約15倍になる。タスクの価値がそのコストを支えられるときだけ割に合う。並列化できる部分が少ないコーディングタスクの多くには、マルチエージェントは適していないとも明言している。割り当てと調停は多ければ多いほど良いわけではない。シンプルに解決できるなら、無理に複雑にしない。

以前、自動最適化システムを運用していた。育てるうちに、シグナルが薄すぎて価値がメンテナンスコストを支えられなくなり、最終的に終了させた。そのとき学んだことがある。ツールをうまく退場させる方法は設計の一部であり、後から考えることではない。この表はいつか捨てられる。このロールの分け方もいつか変わる。本当に残るのは一つの習慣だ。変わるものを日付つきの小さな箱に閉じ込め、そこにハートビートを与えること。ツールは次の世代のモデルに淘汰されるが、この習慣は淘汰されない。

家を建てるとき、逃げ道も一緒に作っておく。逃げるためではなく、自分にはまだ選択肢があると知るために。

一つだけ持ち帰るなら、これだ。モデル名を判断ルールに書かないこと。判断ルールはそのまま残し、モデル名は再バインドでき、更新でき、淘汰もできる表に置く。

付録：あなた自身のバージョンに改造してください

この設計は私のワークフローに縛られていない。そのまま使えるものを二つ渡す。構造が見えるスケルトンと、自分のバージョンを生成するためのプロンプトだ。

まずスケルトン。埋めるだけで雛形ができる：

# タスク調停ルール（スケルトン）

## 難易度分類（安定層、ほぼ変更しない）
三つの軸で評価。エラーコストの重みが最も高い：
- エラーコスト：間違えたらどれだけ高くつくか。全体の結論やブランドに影響するなら高、局所的な影響にとどまるなら低。
- 推論の深さ：多段の推論や創造性が必要なら高、既定のルールを適用するだけなら低。
- 判断空間：主観的なトレードオフが必要なら高、標準的な答えがあるなら低。
多くの軸が高ければ深い推論層へ、多くの軸が低ければ高スループット層へ、中間は標準生成層へ。

## バインディング表（揮発層、変更あり、日付つき）
校正日：______（モデルを切り替えるときはこの表と日付だけを変更する）
- 深い推論層 → 現在最も強力なモデル
- 標準生成層 → 中間のモデル
- 高スループット層 → 最も安価で最速のモデル

## 再校正ハートビート
新しいモデルのリリース時または四半期に一度、実際の作業から選んだ約10問の代表タスク（各問に理想の層と成功基準を付けたもの）を実行し、どの層を安定してこなせるかを確認する。対応する層をより安価なモデルへ移し、上記の日付を更新する。

## 退場条件
以下のいずれかが発生したら終了する：ベンダーがエンドポイント内で自動ルーティング、層が一つに収束、判断のコストが節約額を上回る。

自分で埋めるのが面倒なら、以下を使い慣れたAIに貼り付けて、インタビューしてもらい、あなたのワークフローに合ったバージョンを生成させてほしい：

あなたは私のモデル調停設計アシスタントです。タスクの難易度を定数・モデルの能力を変数として扱い、二層に分離した、モデルの世代交代に耐える割り当てルールを一緒に作ってください。

1. 難易度分類（安定層）：三つの軸で私のタスクを評価します。エラーコストの重みが最も高く、次に推論の深さ、次に判断空間です。まず私がよく行う3〜5種類の作業を聞いて、それぞれを高・中・低で評価してください。
2. バインディング表（揮発層）：層をロールで説明します（例：深い推論・標準生成・高スループット）。最初はモデル名を直書きしないでください。私が現在持っているモデルとそれぞれのコスト・強みを聞いてから、ロールを現在のモデルに対応させ、今日の日付つきの表を作成してください。
3. 再校正ハートビート：実際の作業から選んだ約10問の評価タスクをリストアップし、理想のロールと成功基準を付けてください。新しいモデルがリリースされたときに再実行・再バインドする根拠として使います。
4. 退場条件：この調停を終了すべき三つのシグナルを書いてください。

出力は、スキルまたはシステムプロンプトとして保存できる一つのファイルにしてください。難易度分類を安定層に、バインディング表を日付つきの独立したセクションに、再校正ステップと退場条件を付記してください。

出典

本記事で言及した仕組みとデータは、Anthropicの公式ドキュメントに基づいている：

• Anthropic、Building Effective Agents：orchestrator-workers・routingなどのワークフローパターン、および「まず最もシンプルな解法から始め、過度に複雑にしない」という原則。
• Anthropic、How we built our multi-agent research system：マルチエージェントのトークンコスト（約4倍・15倍）、Opusがリードしてサブエージェントにsonnetを使う階層の実証、マルチエージェントの適用範囲と退場の境界。
• Anthropic、Choosing the right model：能力・速度・コストの三軸によるモデル選定原則、および同一モデル内での思考量を調整するeffortパラメータ。