AIエージェントのルーティング設計｜依頼を振り分ける判定表

AIエージェントの数が増えるほど、依頼をどの担当へ渡すかが人の勘に頼りがちになります。本記事は、AIエージェントのルーティング設計を、判定表の作り方・発火条件の重複を避ける書き方・振り分けが外れたときの検知と修正の順で扱います。根拠は公式ドキュメント4件と、実際に運用している判定表の設計です（2026-07-28時点）。

01結論：AIエージェントのルーティング設計は、判定表と重複回避と検知修正の3点で作る

Anthropicは、性質の異なるカテゴリに分けたほうがよい複雑な業務で、入力を分類し専用の処理へ振り分けるRoutingという型を挙げています（出典: Anthropic公式）。同じ文書は例として、顧客対応の問い合わせを一般質問・返金・技術サポートに振り分ける例を挙げています（出典: Anthropic公式）。易しい質問は低コストなモデルへ、難しい質問はより高性能なモデルへ振り分ける例も挙げています（出典: Anthropic公式）。

WEBMARKSも同じ発想で、依頼を7部署・30体のAI社員へ振り分ける判定表を運用しています。CLAUDE.mdは業務判定の手順を「やりたいこと→部署→AI社員→SKILL」の4段で定義しています。実体はMEMORY.mdの依頼別ルーティング表と03-AI_departments/_INDEX.mdです。結論は3点です。

1. 判定表は、依頼をどの単位で切り分けるかを先に決めてから作ります。
2. 発火条件の重複は、判定順序・除外条件・1判定＝1オーナーの原則の3つで防ぎます。
3. 振り分けの誤りは検知の仕組みとセットで運用し、判定表を直すところまでが設計の範囲です。

AIエージェントそのものの定義や、任せてよい業務の判定は本記事では扱いません。判定表に発火条件を書く技術は『Claude Codeのスキルdescription｜呼ばれる条件と除外の書き方』が1スキル単位を扱っています。本記事はその手前にある「どの担当・手順へ渡すか」の層を扱います。対象業務そのものの分け方は『AI社員の組織設計｜AIエージェントに人の組織図は写せない』が扱っています。

02ルーティング設計の対象を決める｜依頼をどの単位で区切るか

判定表を作る前に、依頼をどの単位で区切るかを1つに決めます。単位が粗すぎると性質の違う依頼が同じ担当に集まり、細かすぎると表が際限なく膨張します。

単位の候補は主に3つです。

WEBMARKSは業務ドメイン単位を主軸にしています。7部署・30体のAI社員を抱えているため、部署名だけでは担当が一意に決まりません。03-AI_departments/_INDEX.mdの表は「やりたいこと→部署→AI社員→SKILL」の4段構成です。部署が決まっても、担当者や実行手段が1つに決まらない依頼があるためです。

区切る単位より先に決めることもあります。CLAUDE.mdは、パッケージ済みのスキルを使う案件か、スキルを使わない手作業の案件かを、部署判定より前の入口で分けています。前者はstart_skill_case.pyを使う運用、後者はworkspace_output.pyのplan→initを直接使う運用です。

skill_gate.pyは、この入口分岐とは別のゲートです。入口分岐の後、パッケージ済みSKILLを実際に実行する段階で通します。この分岐は部署ではなく「実行の仕方」を単位にした例で、判定表の単位は業務ドメインだけに限りません。

03ルーティング判定表の作り方｜依頼文から担当・手順を引く4列

判定表の骨格は、依頼文から一意の担当・手順を引ける列構成です。列が少なすぎると担当が2つ以上出てしまい、多すぎると誰も埋めきれません。

実務でよく機能する構成は次の4列です。

WEBMARKSの実例では、担当と手順が1つの経路として書かれています。業務を判定した後、該当する03-AI_departments/<部署>/<AI社員>/_RULE.mdを読みます。そのうえでskill_gate.pyを通し、中立正本のSKILL.mdを実行する経路です。担当と手順が分離していないため、担当だけ決まって手順が空欄になる事態を避けられます。

判定表の実装形式はコードでなくてもかまいません。表形式のMarkdown、スプレッドシート、判定ロジックを持つスクリプトのいずれでも、4列の情報が揃っていれば機能します。次は列構成を最小限のパターンとして示した例です。

発火条件: 記事系KWの新規制作依頼
担当: Marketing / jp-writer
手順: seo-articleスキル → 品質ラインを通す
エスカレーション先: 対象カテゴリが無い場合はディレクター判断

エスカレーション先の列は、一致しない依頼が出て初めて価値を持ちます。この列を埋めていない判定表は、想定外の依頼が来た瞬間に運用が止まります。

04ルーティング設計で発火条件の重複を避ける書き方｜3つの判定順序

判定表の行が増えると、1つの依頼文が複数の行に一致する場面が出てきます。重複を避ける書き方は3つです。

1. 優先順位を明示する：OpenAI Agents SDKのHandoffsは、委譲先ごとに1つのHandoffを登録し、モデルにどれを使うか選ばせる設計です（出典: OpenAI公式）。Claude Codeも、管理設定・CLIフラグ・プロジェクト・ユーザーという置き場所間の同名衝突には優先順位表を明文化しています（出典: Claude Code公式）。ただし同じ.claude/agents/ディレクトリ内で同名ファイルが複数あるときは、読み込み順で1つが選ばれ、優先順位は明文化されません（出典: Claude Code公式）。優先順位を書かないと、動作は設計ではなく実装の都合で決まります。
2. 除外条件を明記する：ある行が担当する範囲だけでなく、担当しない場面と代わりの担当先を同じ行に書きます。「この部署が担当しない場面」と「その場合の遷移先」をセットで書くと、判定表を読む人にも重複の有無が見えます。
3. 1判定＝1オーナーの原則を守る：同じ発火条件を2つの行が持つ場合、統合するか、範囲の広いほうを親・狭いほうを子として親子関係を宣言します。この媒体自体のキーワード設計も同じ原則を使っています。kw_registry.csvは1つのcoreに対してownerを1本に固定し、重複する記事は統合するか親子関係を宣言する運用です。

重複が実際に事故になった例もあります。姉妹メディアのAIO Journalでは、番犬プロセスと本体セッションが同じ記事を同時に執筆し、記事3本を上書きする事故が起きました。原因は、着手範囲を宣言せずに複数の実行主体が同じ対象へ振り分けられたことです。

対策として、着手前にWRITER_CLAIMというファイルで範囲を宣言するルールを導入しました。対象の状態をplanned→writingへ進め、CLAIMのない範囲には着手しません。範囲の宣言そのものが、重複を防ぐ4点目の実装です。

05ルーティング設計とスキルのdescription発火は何が違うか｜責任の階層が別

「振り分け」という言葉は、複数の層で別々に使われています。混同すると、直すべき層を間違えます。

スキルのdescriptionは、Claudeにそのスキルをいつ自動的に読み込むかを判断させる材料です（出典: Claude Code公式）。通常のセッションでは、全スキルのdescriptionだけが常にコンテキストへ読み込まれます。本文はスキルが呼ばれたあとにだけ読み込まれます（出典: Claude Code公式）。

サブエージェントへの委譲も同様の仕組みです。タスクの内容とdescriptionが一致した時点で、Claude Code自身がそのサブエージェントへ委譲します（出典: Claude Code公式）。

判定表は依頼が届く前に人が設計する層、description一致は依頼が届いたあとにClaude Code自身が行う判定という違いがあります。判定表がうまく機能していても、その先で呼ばれるスキルのdescriptionが曖昧だと、担当は合っているのに手順の入口で発火しないという事態が起きます。逆にdescriptionだけを整えても、そもそも担当が違う判定表に依頼を乗せてしまえば、正しいスキルへはたどり着けません。2つの層は独立に壊れるため、どちらか一方だけを直しても解決しません。

06AIエージェントのルーティング設計で振り分けが外れたことをどう検知するか｜3つのシグナル

判定表は作った時点では正しくても、依頼の傾向が変われば外れます。振り分けの誤りは、次の3つのシグナルで検知します。

3つ目の「沈黙」は最も気づきにくいシグナルです。エラーが出ないため、判定表を見返さない限り発覚しません。Claude Codeの同名サブエージェント問題も同じ性質を持ちます。名前が重複していても実行時にエラーは出ず、意図しないほうが選ばれたまま気づかないことがあります（出典: Claude Code公式）。

/doctorのようなチェックコマンドは、同じディレクトリ内の重複名を検出して警告します（出典: Claude Code公式）。この仕組みは、沈黙を機械的に拾うために備わっています。

検知の仕組みを作らないと、判定表は「書いた時点の正しさ」しか保証しません。運用が続くほど依頼の言い回しも組織の担当範囲も変わるため、検知は判定表とセットで設計します。

07振り分けの誤りをルーティング設計へ反映する修正サイクル

検知したあと、判定表へ反映するまでの手順は5段です。

1. 検知経路を先に決める：人が気づく運用か、ログや棚卸しで機械的に拾う運用かを決めます。
2. 誤りの原因を切り分ける：単位が粗すぎたか、優先順位が抜けていたか、除外条件が無かったかを見ます。原因の切り分け方は『AI運用の障害切り分け｜更新時刻を犯人にしない4段の手順』の考え方が使えます。
3. 判定表を行単位で直す：表全体を作り直さず、原因になった行だけを更新します。
4. 変更した行を記録する：誰が・いつ・何を変えたかを台帳や履歴に残します。
5. 同じ依頼文でもう一度確認する：直した行が実際に効くかを、誤りの原因になった依頼文で再確認します。

5段目を省く運用は珍しくありません。表を直した安心感で確認を後回しにすると、直したはずの行がまた同じ理由で外れることがあります。判定表の修正は、確認まで終えて初めて完了です。

08ルーティング設計でつまずきやすい点

つまずきは主に3つのパターンに集約されます。

単位を細かくしすぎて表が膨張する。言い回しの違いごとに行を増やすと、似た行が並び、どれが優先されるか誰にも説明できなくなります。単位は業務ドメイン・操作・検索意図のいずれかに寄せ、細部は除外条件で吸収します。

優先順位を暗黙のルールに任せる。「先に書いた行が勝つ」のような順序を明文化しないまま運用すると、担当者が変わった時点で解釈が割れます。Claude Codeも、同じディレクトリ内で同名のサブエージェントが重複すると、優先順位を明文化せずファイルの読み込み順で1つを選びます（出典: Claude Code公式）。異なる置き場所の間では優先順位表が明文化されているため、優先順位が消えるのは同一ディレクトリ内で名前が重複した場合に限られます。

検知の仕組みを作らず判定表を放置する。判定表は一度作って終わりではありません。手戻り・二重着手・沈黙のいずれかを定期的に見る仕組みがなければ、外れたことにすら気づけません。

09ルーティング設計のチェックリスト

• 依頼の切り分け単位（業務ドメイン・操作・検索意図のいずれか）を1つに決めたか
• 判定表の列を、担当が一意に決まる粒度で設計したか
• 同じ依頼が複数行に一致しないよう、優先順位または除外条件を明記したか
• 1判定＝1オーナーの原則で、重複する行を統合または親子関係にしたか
• エスカレーション先（一致しない・重複したときの遷移先）を判定表に持たせたか
• 手戻り・二重着手・沈黙のいずれかを検知する仕組みを用意したか
• 修正は表全体でなく行単位で反映し、変更履歴を残しているか
• 実際に依頼文を入力し、想定どおりの担当・手順に振り分けられるかを確認したか

10FAQ