AIエージェントのルーティング設計｜判定表4列と外れを直す5段

「この依頼、どこに投げればいいんでしたっけ」。AIエージェントを何体か動かし始めた組織で、最初に詰まるのがここです。

作れる担当は増えました。ところが、届いた依頼をどれに渡すかは、その場にいる人の勘に戻ってしまいます。勘が当たっているうちは回りますが、担当が入れ替わった日に説明できなくなります。

この記事は、依頼を振り分ける判定表の作り方と、外れたときに気づいて直すところまでを扱います。素材は公式ドキュメント4件と、実際に運用している判定表の設計です。

進行役は3人です。若葉さんが言葉の意味から聞き、高梨課長が自分の手で組む側から聞き、鈴木さん（本誌監修）が答えます。

01AIエージェントのルーティング設計って、そもそも何を決めているんですか？

若葉さん

若葉さんの発言

ルーティング設計という言葉、配線みたいな響きですけど、何を決めるものなんでしょうか。

鈴木さん

鈴木さんの発言

会社の代表電話に近いと思っています。かかってきた用件を聞いて、どの部署の誰へ回すかを決める。その回し方を、あらかじめ紙に書いておくのがルーティング設計です。

ルーティング設計とは、依頼文を読み、担当部署・AI社員・手順のどれへ渡すかを判定表で決める設計です。

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. 振り分けの誤りは検知の仕組みとセットで運用し、判定表を直すところまでが設計の範囲です。

AIエージェントそのものの定義や、任せてよい業務の判定は、この記事では扱いません。対象業務そのものの分け方はAI社員の組織設計｜部署より先に決める3点と確かめ方が扱っています。この記事は、その手前にある「どの担当・手順へ渡すか」の層だけを見ます。

02AIエージェントに渡す依頼は、どの単位で区切ればいいんですか？

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

WEBMARKSは業務ドメイン単位を主軸にしています。7部署・30体を抱えているため、部署名だけでは担当が一意に決まりません。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ルーティング設計の判定表には、AI社員の何を書けばいいんですか？

高梨課長

高梨課長の発言

表を作れと言われたのですが、列を何にすればいいのかが分かりません。

鈴木さん

鈴木さんの発言

列が少ないと担当が2つ以上出てしまい、多いと誰も埋めきれません。埋めきれる範囲で、担当が一意に決まる最小の組み合わせを探す感じです。

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

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

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

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

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

04同じ依頼が複数のAIエージェントに当たるのは、どう防ぐんですか？

行が増えると、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本に固定し、重なる記事は統合するか親子関係を宣言する運用にしています。

05二重着手の事故は、AIエージェントの運用のどこで起きたんですか？

高梨課長

高梨課長の発言

重なっていると、実際どんな壊れ方をするんでしょうか。

鈴木さん

鈴木さんの発言

姉妹メディアのAIO Journalで、番犬プロセスと本体セッションが同じ記事を同時に書きに行きました。記事3本が上書きされています。誰も無理な使い方はしていなくて、着手する範囲を宣言していなかったことだけが原因でした。

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

前後で入れ替わったのは、判定の賢さではありません。走り出す前に名乗るかどうかです。表の書き方をいくら詰めても、走る側が黙って走れば、同じ対象は重なります。

06AIエージェントのルーティング設計と、生成AIが自分で選ぶ発火は何が違うんですか？

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

スキルのdescriptionは、Claudeにそのスキルをいつ自動的に読み込むかを判断させる材料です（出典: Claude Code公式）。通常のセッションでは、全スキルのdescriptionだけが常にコンテキストへ読み込まれ、本文はスキルが呼ばれたあとにだけ読み込まれます（出典: Claude Code公式）。サブエージェントへの委譲も同じ仕組みで、タスクの内容とdescriptionが一致した時点で、Claude Code自身がそのサブエージェントへ委譲します（出典: Claude Code公式）。

積み上げてみると、表の並びとは別の関係が見えます。決まる時刻が層ごとに違うということです。判定表は依頼が届く前に決まっていて、description一致は届いた瞬間に決まります。

だから、判定表がうまく機能していても、その先で呼ばれるスキルのdescriptionが曖昧なら、担当は合っているのに手順の入口で発火しません。逆にdescriptionだけを整えても、担当が違う判定表に依頼を乗せてしまえば、正しいスキルへはたどり着けません。2つの層は独立に壊れるため、片方だけを直しても解決しません。

発火条件そのものの書き方は、Claude Codeのスキルが発火しない｜descriptionを直す4層が1スキル単位で扱っています。委譲の設計自体はサブエージェント設計｜委譲の線引きと3つの失敗にあります。

07振り分け（ルーティング設計）が外れたことに、AI導入の現場ではどう気づくんですか？

判定表は作った時点では正しくても、依頼の傾向が変われば外れます。手がかりは3つです。

高梨課長

高梨課長の発言

手戻りは会議で話題になりますが、沈黙はどうやって拾うんでしょうか。

鈴木さん

鈴木さんの発言

拾いに行かないと出てきません。エラーが出ないので、判定表を見返さない限り発覚しない種類の外れです。

Claude Codeの同名サブエージェント問題も、同じ性質を持っています。名前が重なっていても実行時にエラーは出ず、意図しないほうが選ばれたまま気づかないことがあります（出典: Claude Code公式）。/doctorのようなチェックコマンドが同じディレクトリ内の重複名を検出して警告するのは、この沈黙を機械的に拾うためです（出典: Claude Code公式）。

置き分けると、3つが一列に並ばないことが分かります。目に入りやすさと、記録が残るかは別だからです。検知の仕組みを作らなければ、判定表は書いた時点の正しさしか保証しません。運用が続くほど依頼の言い回しも担当範囲も変わるため、検知は判定表とセットで設計します。

08外れたAIエージェントのルーティング設計は、どう直せばいいんですか？

気づいたあと、判定表へ反映するまでの手順は5段です。

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

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

09AI活用が進むほどルーティング設計でつまずくのは、どこですか？

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

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

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

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

3つに共通するのは、どれも作った直後には表面化しないことです。運用が始まってから、静かに効いてきます。

10AI社員へ配り始める前に、ルーティング設計の何を確かめますか？

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

最後の項目だけ、性質が違います。ほかは机の上で確かめられますが、これは依頼文を実際に通してみないと分かりません。書いた表が読めることと、その表が引けることは別に数えます。

11よくある質問

12まとめ｜今日やる3つのこと

単位を1つに決め、担当と手順が一意に決まる列を組み、外れに気づく道をセットで置く。ここまでが設計の範囲でした。