AI ツールの使い分けに迷ったら — 3 層ルーティングという考え方
最近 Claude / ChatGPT / Gemini を実務で並列に使い始めて、しばらくしてから気づいたことがあります。全部のタスクを同じ AI ツールでやろうとすると、過剰でも不足でも結果がブレる、ということです。
具体的な失敗として、本来 Claude 単体で 5 分で終わる単純な GAS 改修に、「念のため」と複数 AI の比較レビューを走らせてしまい、最終判断まで 1 時間以上かかった経験があります。逆に、ツール選定や運用方針のように 自分の判断 + 上司の承認 が絡む戦略系のタスクを Claude 単体に投げて、もっともらしい一案を採用したら後から穴に気づいたこともありました。
そこから自分のルールとして、タスクの性質に応じて AI ツールを 3 層に分ける という運用を試しています。
3 層ルーティング（コピペできる判断軸）
## AI ツール選択ルール（タスク性質ベース）
- 単純な開発タスク → AI 単体
- プロトコルが複雑 / 他から借りる判断 → AI × API（WebFetch / Agent サーベイ）
- 多重解釈 + トレードオフを含む判断 → 複数 AI の議論（cross-vendor）
それぞれの層が、何を解いているのかを簡単にまとめておきます。
層 1: 単体 AI（Claude / ChatGPT / Gemini どれでも）
- 対象: 1 ファイル内の改修、既存パターンの転用、単純なデータ操作、定型 GAS 開発
- 判断シグナル: 「答えがほぼ決まっている」「正解にたどり着く道筋が見えている」「複数解釈の余地がない」
- 避ける: 過剰品質。ツールを増やすほど起動コストが膨らむため、軽い判断は単体で完結させる
層 2: AI × API（WebFetch / 公式ドキュメント取得 / Agent サーベイ）
- 対象: ライブラリ選定、仕様調査、ベストプラクティス比較、学術動向確認
- 判断シグナル: 「外部仕様や既存実装を参照する必要がある」「知識のカットオフがあるため、AI 単体の知識の鮮度や網羅性が怪しい」
- 使い方: Claude Code なら WebFetch / general-purpose Agent でサーベイさせる。ChatGPT なら ブラウジング、Gemini なら Deep Research
- 避ける: 内部完結タスク（既存コードのリファクタ、定型的な GAS 改修、社内ルールに沿った定型作業など）への適用。外部参照を必要としないものに API 経由を持ち出すと、起動コストだけが膨らみます
層 3: 複数 AI の議論（cross-vendor）
- 対象: 採用判断、設計分岐、公開戦略、撤退判断、プロトコル変更採否
- 判断シグナル: 「複数の解釈が成立する」「どの選択肢にもトレードオフがある」「AI 単体だと一案に偏る危険がある」
- 使い方: 同じ議題を Claude と Gemini の両方に投げ、相互に批判させる。人間が router として最終判定
- 避ける: 起動コストが高いので、層 1 や層 2 で十分なタスクには使わない（やりすぎ防止）
-
やりすぎを避ける具体策:
- 迷ったら層 1 から始める。層 1 で決まれば終わり、決まらなかった項目だけを層 2 / 層 3 へ昇格させる
- TTL を最初に決める（例: 複数 AI の往復は最大 3 回まで）。それを超えたら人間判断へエスカレートさせる
- 1 セッション 1 主論点に絞る。複数論点を同じ議題に詰め込むと、TTL を即圧迫する
補足として、この「やりすぎ防止」の発想は、Andrej Karpathy が AI 協業について語っている「簡素第一・最小差分」の原則と同じ方向を向いていると感じています。要求されていない領域に投機的提案を出させない、スコープ外の改善を勝手に追加させない、という規律です。AI ツールに何かを任せるとき、ツールを増やす方向ではなく 必要な層に必要なだけ留める という抑制的な発想は、層 1 / 層 2 / 層 3 のどの層でも効きます。
もう一つ、対になる規律として Fail-Fast（早期撤退） も置いています。TTL を超えて議論が収束しないとき、無理に答えを絞り出すより、「この機能はいったん諦めて切り離す」という選択肢のほうが ROI が高い場面が実際あります。完璧を目指して全停止するより、不完全でも動く部分を残す（Graceful Degradation / 縮退運転）ほうが、運用視点では合理的なことが多いです。AI に「諦めるべき箇所」を判断させるのではなく、人間に撤退判断を返してもらうことが、層 3 を健全に運用する鍵だと思います。
ちなみに、層 3 を実際に走らせてみると意外な観察があって、これがけっこう面白いです。AI 同士が互いに遠慮しあって形式的な同意ばかり繰り返してきたり、片方が完全同意モードに入ったら「それは手を抜いている」と判断してこちらから反論を強要しに行ったり、机上で想像していたよりずっと泥臭い運用になります。AI のキャラクターやチューニングの違いがこういう形で出てくるのは、観察としても日々の小さな楽しみだと感じています。
なお、層 2 / 層 3 を「いっそ全部 API で繋いで自動化したくなる」気持ちは分かりますが、手作業のコピペコストと API 保守の技術的負債コストは別物です。前者は線形に増えるだけ、後者はバージョン追従と認証管理で非線形に膨らむ可能性があります。可観測性を残すために、あえて手作業を残すという判断もインフラ視点では普通にありえます。
ここまでのまとめと、その先
ここまでが「どの AI ツールに何を任せるか」のルーティングの話でした。一段だけ深く、その背後にある考え方にも触れておきます。
この 3 層ルーティングは「何を判断軸にするか (What)」と「どう振り分けるか (How)」の話までで、なぜこの分割が効くのか (Why) や 複数 AI に議論させるときのプロトコル設計 (Trade-off) までは踏み込んでいません。
Why と Trade-off の領域は、本記事ではあえて分けて扱っています。
- Why の入口: 層 1 / 層 2 / 層 3 の境界線がそもそもなぜ存在するのか、という背景論。「全肯定 AI が単一障害点になる」「机上評価と実走評価の差」あたりの考え方は、別記事で運用エンジニアの規律 (5 つの作法 + 5 つの禁じ手) として整理しています
- Trade-off の入口: 複数 AI を運用するときの 統制プロトコル — ドメイン文脈型ガバナンス、議論セッションの採番ルール、TTL 設計といった一段深いアーキテクチャ論 — については、後日公開予定の長編記事で扱う予定です
判断軸を持った後、もう少し深く考えたくなったら以下から読んでみてください。続編も気になる方はお待ちいただければと思います。