直感的には、モデルが増えるほど答えが良くなるということだ。もう1つのタブ、もう1つの視点を開いて、真実に向かって三角測量する。これは約3つのモデルまでは機能し、その後は逆転する。それを超えると、追加するモデルごとに調整に費やすコストが得られる洞察を上回り、最初に低下するのは速度ではない。どの答えが正しかったかについての判断力だ。
重要な要点：1つのモデルは明確な思考を強制する。2つか3つあれば、本物の第二意見が得られる。それを超えると、モデルをオーケストレーションしているのではなく、10分前に何に同意したかを覚えていない委員会を議長としているのだ。
6つのモデルがほぼ常時開いていて、非常に生産的に感じたが、著しく劣った仕事をリリースした月の後に、この曲線を引いた。
6つのモデルを開くと、1つのリダイレクトマップで1日を失った
最悪の場合、アーキテクチャの問題でOpus 5を開き、実装の途中でCodexを開き、エディタでComposerをライブで開き、第二読として読むためにGrokを開き、Qwen と KimiをX上の誰かが言っていたので、さらに2つのタブに置いた。コックピットのように感じた。これは誰も指示書を読んでいないグループチャットだった。
コストはリダイレクトマップに現れた。大規模なプログラマティックサイトで、数百個の古いURLを統合していた。95パーセント正しいでは災害になるような仕事だ。なぜなら5パーセントが静かに301で収益を壁に送っているからだ。トレーリングスラッシュチェーンについて3つのモデルに質問して、3つの防御可能な答えを得た。1つを選んで論理を詰めるのではなく、それらをマージした。そのブレンドは3つのうちどれよりも悪かった。なぜなら、それぞれ内部一貫性があり、マージはそうではなかったからだ。解きほぐすのに丸一日かかった。完全に自分のせいだ。
1つのモデルは明確に考えることを強制する
単一モデルの過小評価されている特性は、仕様をあなたに返すことだ。正確に1つのことだけを質問できるとき、本当のブリーフを書く必要がある。入力、出力が満たすべきもの、スコープ外のもの、「完了」の意味。その執筆行為がエンジニアリングのほとんどだ。プロンプトを書くときのほうが、どんなコードレビューよりも設計上の誤りを見つけている。
6つのモデルを開くと、その規律は静かに消える。ブリーフを書くのをやめて、投票を始める。そして曖昧な質問を6つのモデルに投げると、6つの自信に満ちた答えが返ってくる。自信は証拠ではない。これらのシステムが聞こえ方というだけだ。Claude Codeワークフローの私の価値のほぼすべてはモデルの上流にある。
2つか3つのモデルが実際のスイートスポットだ
3つが機能する理由は、モデルが同じ仕事を並列で行うのではなく、異なる仕事をしているからだ。労働分業は加算的だ。重複は加算的ではない。1つのモデルが計画を保持し、1つがコードを書き、1つが冷たい視点でそれを読み返す。誰も投票していない。
2つのモデルが同じ仕事をしている瞬間、冗長性は買っていない。あなただけが解決できるタイブレーク機構を買ったのだ。そしてあなたはこの会話で最も疲弊した参加者だ。
スペシャリストモデルが実際にタブを獲得するとき
スペシャリストは構造的に異なるとき、単なる異なるブランディングではなく、価値がある。私の試験は単純だ。他のものと学べるような形で異なるか。すべてに同意するモデルは非常に高価なイエスマンだ。
Codexは実装、特に複数のファイルにわたる長い機械的な変更で、会話ではなくdiffが欲しいときはタブを獲得する。Composer 2.5はエディタ内で獲得する。そこでの価値は深さではなく、レイテンシだ。Grokは製品とポジショニングの質問で獲得する。なぜなら、そのアイデアはつまらないと楽しく教えてくれるからだ。QwenとKimiは同じ近所からのもう1票ではなく、異なるトレーニング分布が欲しいときに獲得する。KimiはUI監査スクリプトに接続している。他のモデルが丁寧であることを学んだものに気づくからだ。
その最後の区別こそが全てだ。五つ目のモデルを追加する人の大半は、別の意見を求めているのではなく、別の確認を求めている。その瞬間は同じに見えるが、実は正反対だ。
隠れたコストは切り替えではなく、調整である。
コンテキスト切り替えが誰もが挙げるコストであり、それは現実だ。制約をどのタブに伝えたのか思い出せないから、同じファイルを四度目に読み直すことになる。だがそれが高くつくものではない。
高くつくのは、お前がマージコンフリクトになることだ。二つのモデルなら一つの不一致を裁定すればいい。三つなら三つ。六つなら十五の相互対立した不一致があり、全てが同じ疲弊した人間からの決定を求めている。スタックの何もそれを調整していない。お前が統合レイヤーであり、一日の終わりに、六つの微妙に異なるフレーミングを既に読んだ問題に対して走っている。
そしてモデルはお前を助けられない。なぜなら、それらの誰もが他のモデルが何を言ったか知らないからだ。全体の文脈を保持しているのはお前だけであり、それはまさにお前が委譲しようとしていた立場だ。
AI オーケストレーションは通常、人間の問題だ。
より良いオーケストレーションが必要だと言う人は、大抵より明確なブリーフが必要ということだ。三つのモデルが本当に異なる答えを三つくれるなら、それは稀に能力ギャップではない。ほぼ常に質問の曖昧さであり、ルーティングロジックがいくら解決することもできない。分散させるだけだ。
今使っている診断法は、正解が満たさなければならないことを二文で書き留めることができなければ、別のモデルを開くのは進捗バー付きの先延ばしだということだ。まず二文を書け。時々その二文が答えそのものであり、全てのタブを閉じる。
今日実際に走らせているワークフロー
思考用に Opus 5。アーキテクチャ、トレードオフ、そのものを作るべきかという厄介な質問。ここが私がプロンプト努力を費やす場所だ。ここでの悪い決定は後からのより良いコードでは回復不能だからだ。
実装用のコーデックス。形状が決まったら、仕様書を渡して作業させる。私が確認するのはdiffであり、推論ではない。
コード補助用のComposer 2.5。エディタ内で高速、小規模スコープ。優れたオートコンプリートであり、同僚ではない。同僚のように扱うと、頼んでもいない400行が返ってくる。
別の視点が必要な時はGrok。意図的にクリティカルパスの外に置く。自分で納得させられてしまったと疑う時に、そこに行く。
確認ではなく別の意見が欲しい時はQwenかKimi。滅多にない。意図的に。
重要なのはリストではなく、これらがほぼ同時に開いていることがないという点だ。コックピットではなくシーケンス：思考、実装、レビュー。各段階で1つのモデルにペンを持たせる。チャートが3でピークになるのは、良い日には3つの段階が本当にアクティブだからだ。Claude CodeとCursorの2つを比較した。
タブを増やすより、プロンプトを良くする方が効く。
よく仕様を詰めた問題を1つの良いモデルに与える方が、曖昧な問題を6つのモデルに与えるより優れている。差は大きい。複数のモデルは、タブを開くのが瞬間だから気分が良くなるだけだ。仕様を書くのは仕事だから。AI FOMOは、次のモデルが避けてきた思考を してくれるという信念だ。そうはならない。間違った問題についてもっと雄弁になるだけだ。
規律は地味だが複利で効く。これらのツールで最高の成果を出している人たちは、最も多くのモデルを使っている人たちではない。意図的に2つか3つを使い、明確な役割分担と書き上げた仕様がある人たちだ。そして彼らは、モデル・オブ・ザ・ウィークの議論に飽きている。
今日やることは1つだけ。
AIのタブをすべて閉じる。ただ1つを残す。実際に取り組んでいるタスクを書き出す。入力は何か、正しい出力が満たさなければならない条件は何か、この2文を書く。この2文をそのまま残したモデルに与える。答えが良ければ、あなたのボトルネックはモデルの能力ではなかった。悪ければ、この2文のどちらが間違っていたか分かる。それは6つのモデルが教えてくれることではない。
よくある質問
一度に何個のAIモデルを使うべきか？
2つか3つ。それぞれ異なる役割を担当させる。1つは問題を思考し、1つは実装し、オプションで1つはレビューか異なる視点を提供する。3つを超えると、矛盾する回答を調整するコストが追加の視点の価値より速く増加する。なぜなら、すべてのモデルが何を言ったか知っている唯一の参加者はあなただからだ。
同じタスクに複数のAIモデルを使うのは悪いか？
同じタスクで2つのモデルを実行するのは通常は無駄だ。冗長性を得られるのではなく、あなたにしか解決できないタイブレーカーを得るだけだ。複数のモデルは計画と実装のような異なる役割を持つときに役立ち、互いに重複するときには害になる。
AIモデルを切り替える実際のコストは何か？
明らかなコストはコンテキストの再確立と同じファイルの再読だ。より大きなコストは調整だ。6つのモデルがあると15個のペアワイズの不一致を判定する必要があり、スタックの中にそれをしてくれるものは何もない。あなたが統合レイヤーになる。
Codex、Grok、Qwen、Kimiのようなスペシャリストモデルは本当に役立つか？
単に異なるブランドではなく、構造的に異なるとき、そして定義された役割を持つときに役立つ。テストは、そのモデルが他のモデルと学べるような方法で不一致を示すかどうかだ。ほとんどが一致する場合、確認のために支払っているのであって、洞察のためではない。
関連：これが主張する単一モデルの規律のための私のClaude Codeワークフロー。または、これが誰か他の人の問題であってほしい場合、Claude Code開発者を雇うこと。