TL;DR: ルーティングとは、あるタスクをどのコーディングエージェントが処理するかを決めることです。先週のリーダーボードではなく、タスクの性質でルーティングしましょう。何を変更するのか、どれだけ元に戻せるのか、別のエージェントが触っているファイルと重複するか、どれだけの時間を無人で動かすのか、どのサブスクリプションでカバーするのか。これらを、あなたのコードベース上での挙動が合うエージェントにマッチさせます。エージェントが1つか2つなら頭の中でも回ります。3つを超えると、ルーティングの判断を置いておく共有の場所が必要になります。本ガイドではルールとチェックリストを紹介します。
1つのターミナルにはClaude Code、別のターミナルにはCodex、さらに3つ目にはGemini CLIが入っているとします。そこにタスクが舞い込みます。フレーキーなテストの修正、エンドポイントの追加、他の3つのファイルがインポートしているモジュールのリファクタリング。どのエージェントに任せますか? 多くの人は習慣で、あるいはすでにフォーカスされているウィンドウで答えてしまいます。マイグレーションをどのエージェントに渡したか思い出せなくなったり、2つのエージェントが同じファイルを編集し始めたりするまでは、それで問題なく回ります。
「最高の」エージェントを選ぶことは、新しいモデルが出た日に陳腐化する一度きりの判断です。目の前のこのタスクをどのエージェントに任せるかは、週に何十回も下す判断であり、ランキングよりもタスクの性質にずっと強く依存します。エージェントが1つを超えた時点で、あなたの時間が溶けていくのはルーティングです。
Sharklyは、まさにその判断を中心に作られています。Sharklyはオールインワンのエージェント指令・管理プラットフォームです。自分のComputerを接続し、ランタイムに結びつけた役割としてAgentを一度定義し、そこにTaskを割り当てます。既に動かしているコーディングエージェントの隣に並ぶのではなく、その上に位置します。本記事では、タスクをうまくルーティングする方法を、まずは手で適用するルールとして、次にルーティングの判断を共有できる場所に置く必要が出てくる段階まで順に解説します。
ルーティングは好みではなく判断である
まずは定義を整理しましょう。ルーティングとは、タスクを実行すべきエージェントにマッチさせることです。お気に入りのエージェントを選ぶこととは違い、モデルを選ぶこととも違います。どのコーディングタスクにどのモデルかは、そのさらに下のレイヤーにある、より狭い別の問いです。ここで決めるのは、どのエージェント(Claude Code、Codex、Gemini CLI、OpenCode、その他)がその作業を受け取るかです。
タスクには、能力が問題になる前にそのルートを決定づける性質が備わっています:
- 何を変更するか。 1ファイルの修正、横断的なリファクタリング、新規機能、テスト、ドキュメント。それぞれ影響範囲(ブラスト半径)が異なります。
- どれだけ元に戻せるか。 タイポ修正もデータベースマイグレーションも差分を生みます。エージェントが失敗したときに午後を台無しにするのは片方だけです。
- ファイルの重複。 今まさに別のエージェントが編集しているファイルに触れるかどうか。
- 自律稼働の時間軸。 短い対話的な編集か、計画・実行・自己検証を行う長時間の無人実行か。
- コスト上限。 どのサブスクリプションやAPI予算で吸収すべきか。
タスクをこの5つの性質で読めば、ルートは多くの場合おのずと決まります。間違いは、「どのエージェントが最高か」に直行してしまうことです。その問いに固定の答えはなく、研究所がモデルをリリースするたびに変わります。
能力でルーティングする前に、タスクの形でルーティングする
コーディングエージェントには確かな違いがあります。長い多段階タスクの計画が得意なものもあれば、外科手術のような編集に鋭く、素早いループを回すのが速いものもあります。しかし正直に言えば、違いはあなたのコードベース上で現れるものであり、それを知る唯一の方法は、実際にそこで働く様子を観察することです。ベンチマークは、ある固定された時点である固定された問題セットを測っているにすぎず、それはあなたのリポジトリでも来月でもありません。ランキングを信じる前に、自分のコードベースでエージェントを比較するようにしましょう。
だからこそ、まず形でルーティングします。判断の軸となるペアはこれです: タスクが小さく、スコープが明確で、自分が監視している場合は、高速で対話的なエージェントを使う。タスクが十分に大きく、各ステップに付き添うよりも一度説明して結果をレビューしたい場合は、より自律的なエージェントに任せる。
| タスクの形 | ルート先 | 理由 |
|---|---|---|
| 小さく、スコープが明確で、自分が監視している | 最も速い対話型エージェント | オーバーヘッドが低く、ループが速い |
| 大きく、多段階で、一度説明すれば済む | 最も信頼できる自律型エージェント | 無人で計画し自己検証する |
| 別のエージェントが開いているファイルに触れる | どのエージェントでも、隔離されたworktreeで | マージ衝突を避ける |
| 高リスクまたは不可逆 | 出力を厳密にレビューするエージェント、狭い権限で | 速度ではなく影響範囲が支配する |
| 安価で反復的 | 予算が好むもの | コスト上限で決まる |
ここには勝者が一切登場しません。存在しないからです。あるのはタスクとエージェントの観察された挙動とのフィットであり、そのフィットこそがルーティングの根拠です。
能力よりも先にルーティングを決める制約
能力を必ず上書きする制約が2つあり、どちらもスキルではなく調整の問題です。
1つ目はファイルの重複です。5つのエージェントが1つのリポジトリを編集するのは効率的に聞こえますが、2つが同じファイルに触れて、自分でわざわざ作ったマージコンフリクトを解消する羽目になるまでは、の話です。解決策は隔離です。各タスクに専用のチェックアウトを与えれば、エージェントは衝突できません。コーディングエージェントのworktree、タスクごとに1チェックアウトで仕組みを、1つのリポジトリで複数のエージェントを動かすでそれがない場合に何が壊れるかを解説しています。2つのタスクが同じファイルに触れる場合、ルートは「優れた方のエージェント」ではなく、「どちらでもよい、別のworktreeで」です。
2つ目はリスクです。データを移行する、認証を変更する、ホットパスを書き換えるといったタスクは、どのエージェントが技術的に最も強いかに関係なく、レビューが最も厳しく、エージェントの権限が最も狭い場所へルーティングすべきです。エージェントは調査し、実行し、テストし、報告します。人は方向性を定め、権限を付与し、結果を受け入れます。リスクのあるタスクを最速のエージェントに任せるのは、間違った変数を最適化しているのです。
頭の中だけのルーティングがスケールしなくなる地点
エージェントが1つなら、ルーティングの問題はありません。2つなら、頭の中に表を保持でき、それで問題ありません。厄介になるのは、エージェントが3つほどになり、複数のタスクが進行中のあたりからです。ルーティングの判断は、あなたの短期記憶以外に置く場所がなくなります。
どのエージェントにマイグレーションを任せたか思い出せません。終わった実行結果は、あなたが読む前にターミナルの先頭からスクロールで消えていきます。一度決めたはずの同じルートを、記録がないために何度も決め直します。互いの存在を知らされていないため、2つのエージェントが同じファイルを編集します。これらはどれもエージェントの失敗ではありません。ターミナルが増えていく中で、ルーティング表を頭の中に保持し続けることのコストです。ターミナルが多すぎることは実際のコストであり、それが真っ先に現れるのがルーティングです。
ここでタスクボードが価値を持ちます。ルーティングの判断をあなたの頭の中から、共有された記録へと移せるからです。Sharklyはこれを3つの名詞で実現します。Taskは作業の共有単位です。Agentはランタイムに結びつけた役割で、一度定義すればルーティングの判断はすべてのターミナルで作り直されるのではなく再利用可能になります。TaskをAgentに割り当てすると、実行・ブロッカー・結果はスクロールで消える代わりにそのTaskへ戻ってきます。ウィンドウを切り替えずに、どのエージェントが何を担当しているかがわかり、diffとテスト出力は一箇所であなたのレビューを待ちます。エージェントの作業を割り当て、追跡し、レビューすることで、記憶ゲームを置き換えられます。
エージェントを1つうまく動かすだけなら、こうしたものは一切不要です。Claude CodeとCodexを1つのコードベースで一緒に動かすことを手作業で行うこともでき、2つのエージェントならそれで妥当です。方程式が変わるのは、ルーティングの判断が頭に収まる量を超えたときです。複数のエージェント、複数のタスク、複数のリポジトリ、同じボードを見る必要のあるチーム。
今日から使えるルーティングチェックリスト
エージェントにタスクを渡す前に、次の項目を順に確認します:
- タスクの形を名付ける。 1ファイルの修正、リファクタリング、新規開発、テスト、ドキュメントのどれか? これで影響範囲が決まります。
- 可逆性を確認する。 元に戻すのが難しい? 最速のエージェントではなく、最も厳しいレビューと最も狭い権限へルーティングします。
- ファイルの重複を確認する。 別のエージェントがすでにこのファイルにいる? それなら、まずこのタスクを専用のworktreeに隔離します。
- 自律稼働の時間軸を合わせる。 短く監視ありか、長く無人か? あなたのリポジトリ上での挙動が合うエージェントへルーティングします。
- コスト上限を設定する。 どのサブスクリプションや予算でこの実行を吸収するかを決めます。
- ルートをどこか共有できる場所に記録する。 エージェントが2つを超えたら、あなたとチームが見られる場所に書きます。閉じてしまうターミナルではなく、Taskに。
- 結果を1箇所に戻す。 diff、テスト出力、レビューはタスク記録へ戻すべきで、ウィンドウ間に散らばらせてはいけません。
ランキングではなくタスクでルーティングしましょう。あるタスクにとって最高のエージェントとは、目の前の作業と形が合うエージェントであり、ルーティングの判断は、あなたが見られる場所に置かれている限りにおいて安く保たれます。
すでに複数のコーディングエージェントを動かしているなら、Sharklyはそれらのタスクをルーティングし結果を読むための1つの場所を提供します。Sharklyをダウンロードして、あなたが使っているエージェントを接続できます。
FAQ
ルーティングは最高のコーディングエージェントを選ぶことと同じですか? いいえ。最高のエージェントを選ぶのは、すぐに陳腐化する一度きりの判断です。ルーティングは、タスクの形、リスク、ファイルの重複、自律稼働の時間軸に基づいて、各タスクをどのエージェントが処理するかを決めることです。エージェントを1回選ぶごとに、ルーティングは何十回も行います。
モデルを選ぶこととはどう違うのですか? モデルの選択は、エージェントの内部という1つ下のレイヤーで行われます。ルーティングはどのエージェントがタスクを受け取るかを決め、モデルの問いはそのエージェントのセッション内で何が動くかを決めます。より狭い判断についてはどのコーディングタスクにどのモデルかをご覧ください。
実際にツールが必要になるのはどんなときですか? ルーティングの判断が頭で追える量を超えたとき、多くの場合はエージェントが3つほどで複数のタスクが進行中のとき、またはチームが同じ判断を見る必要があるときです。エージェントが1つか2つなら、頭の中の表と別々のターミナルで十分です。
SharklyはClaude CodeやCodexを置き換えますか? いいえ。SharklyはClaude Code、Codex、その他の実行ツールの代替ではありません。チームがすでに使っているコーディングエージェントの周囲に、共有されたタスク、Computer、コンテキスト、レビューのレイヤーを追加します。
