AIエージェント開発の実務 — 「自律」を追わず、「裁量」を設計する

「AIエージェントを作りたい」という相談が、この1年ではっきり増えました。話を聞いていくと、私たちの感触では、その半分ほどは「エージェントにしなくてよい」案件です。そしてエージェントが本当に要る案件でも、成否を分けるのは流行りのフレームワークではなく、もっと地味な設計判断でした。

この記事では、2024年から見積エージェントを本番で動かし続けてきた経験をもとに、AIエージェント開発の実務——何をエージェントにし、何をしないか。ツールと裁量をどう設計するか。どう運用に乗せるか——を書きます。

AIエージェントとは — 短い整理

この記事でのAIエージェントは、LLMに道具（ツール）と裁量を与え、目的に向けて「考えて、道具を使い、結果を見てまた考える」を繰り返させる仕組みを指します。推論と行動を交互に繰り返す枠組みはReAct（Yao et al., 2022）として、モデル自身が外部ツールの使い方を身につける方向はToolformer（Schick et al., 2023）として整理され、以後のエージェント研究の土台になっています（サーベイ: Wang et al., 2023）。

定義はこれで十分です。実務で大事なのは次の問い——その処理は、本当にエージェントである必要があるか——のほうです。

エージェントが「要る」処理と「要らない」処理

判断の軸は一つです。手順が事前に書き切れるかどうか。

「全部エージェントに任せる」構成は、一見未来的ですが、本番では三重に不利です。同じ入力でも動きがブレる、失敗の原因が追いにくい、そして毎回LLMが判断するぶん遅くて高い。決定的に解ける部分をワークフローとルールに固定するほど、エージェントは安定します。私たちが本番で動かしているエージェントも、実体は「決定的な骨格＋要所だけ裁量」です。

設計の勘所① — ツールは狭く、堅く

エージェントに渡すツールは、多機能な1本より、役割の狭い数本のほうがうまくいきます。入出力の型を固くし、計算・集計・整形のような決定的な処理はツールの内側で完結させる。LLMに電卓を持たせるのであって、暗算をさせないということです。

ツールが狭いほど、エージェントの選択肢は明確になり、失敗したときに「どの道具で・何を入れて・何が返ったか」を追えます。本番で原因調査ができるかどうかは、この段階でほぼ決まります。

ツールの数が増えてきたら、全部の説明を毎回LLMに渡すのをやめ、要るツールをその都度探して読み込ませます。Anthropicの報告では、ツールの定義を必要な時に読み込む仕組みにすると、MCPのツールを使う評価の正答率がClaude Opus 4で49%から74%に上がりました。使い方の例を添えると、複雑な引数の扱いの正確さも72%から90%に上がっています（Anthropic, 2025）。

呼び出しの形も縛ります。必ずどれか1つのツールを呼ぶ場面では、呼ぶかどうかをLLMに任せる設定（auto）にせず、呼ぶことを必須にするか呼ぶ関数を指定し、引数の型を厳密に検査する設定を使います。LLMの推論サーバーとしてよく使われるvLLMの文書も、autoでは引数が崩れうる一方、必須や関数指定なら解析できる呼び出しが保証されると書いています。ただし保証されるのは形で、中身の正しさではありません（vLLM Docs）。値の妥当性の検査はツールの側に残します。

設計の勘所② — 裁量には境界と、縮退の道を

次に決めるのは、どこまで任せ、どこで止まるかです。読み取り系の操作は自由に、書き込みや対外的な操作は確認を挟む。確信が持てないときは、それらしく進めるのではなく、人に返す。この「困ったら人に返す」縮退経路があるだけで、エージェントは安心して業務に置けるものになります。

止まる条件も最初に決めます。反復して調べるエージェントでは、どれだけ探させるかがそのまま品質と費用を左右します。Anthropicの調べもの用のマルチエージェントは、通常の対話の約15倍のトークンを使い、問いの難しさに応じた呼び出し回数の目安を指示に書いていました（Anthropic, 2025）。私たちは、呼び出し回数の上限・予算・「必要な情報が揃ったか」の判定の3つで止め、どれで止まったかを記録に残します。

もう一つ、エージェントが読む文書やメールは、社外の人が書けるものとして扱います。紛れ込んだ命令でエージェントが社内データを外へ送ってしまう事故を防ぐには、命令を見分けるフィルタより構造が効きます。プロンプトインジェクション対策の設計パターンをまとめた研究は、LLMには許可された行動の一覧から選ばせるだけにする型（行動選択型）などを挙げています（Beurer-Kellner et al., 2025）。狭いツールを選ばせ、書き込みや対外的な操作には承認を挟む、というここまでの設計は、この型と同じ考え方です。

私たちの見積エージェントでは、金額の確定という一番外してはいけない操作に、Slack上で人がリアクションして承認するという段差を設けました。エージェントは見積案の組み立てまでを受け持ち、最後の確定は人が握る。値付けの判断基準は議論の末にルールとして明文化し、決定的に解ける側へ倒しています。この設計の詳細は営業自動化AIの本番設計に書きました。

運用 — 人間の承認から始めて、「卒業」する

エージェントの本番運用は、human-in-the-loop（人の承認をループに挟む）から始めるのが定石です。ただし、挟みっぱなしでは自動化の意味が薄れていきます。道筋を最初から設計しておきます。

この移行を支えるのが評価です。エージェントも、RAGと同じく測れないと上がりません。どの依頼にどう応え、人はどこで修正したか——承認の記録はそのまま評価データになります。介入が減っていく実績が数字で見えて初めて、監査を外す判断ができます。評価の考え方は評価セットの設計と地続きです。

エージェントの評価は、最後の答えが合っていたかだけでは足りません。どのツールを・どの順で・何回呼び、なぜそこで止まったかという道筋（軌跡）も、期待と照らして記録します。答えが合っていても、不要な書き込みのツールを呼んでいたり、上限まで探し回っていたりすれば、本番では事故や費用の元になるからです。先に挙げたAnthropicの記事でも、エージェントの評価は約20問の小さな評価セットから始め、LLMによる採点と人の確認を組み合わせたとされています。

つまずきの典型 — デモで沸いた案件が、本番で問われること

エージェントのデモは華やかです。自然文で頼むと、いくつもの道具を乗り継いで結果が返る。ところが本番で評価されるのは、華やかさではなく「頼んだことが、毎回、同じ品質で返ってくること」です。PoCで歓声が上がったのに本番に進めない案件の多くは、この切り替え——見せ場を作る開発から、ブレをなくす開発へ——ができていません。この構図はPoC止まりの記事で書いた分かれ目と同じです。

開発前チェックリスト

• その処理の手順は、本当に事前に書き切れないか。ワークフロー＋ルールで足りないか。
• LLMの出番を「曖昧さの吸収」に絞れているか。決定的な処理をツールの内側に固定したか。
• 必ず呼ぶ場面で、呼び出しの形と引数の型を縛っているか。ツールが増えたとき、要るものだけを読み込ませているか。
• 書き込み・対外操作に承認の段差を設けたか。困ったら人に返す縮退経路はあるか。
• 呼び出し回数の上限・予算・情報が揃ったかの判定で止まるか。どれで止まったかを記録しているか。
• 承認の記録と呼び出しの軌跡を、評価データとして貯める設計になっているか。
• 監査を「卒業」するまでの道筋を、最初から描いているか。

「任せて大丈夫」を、設計で作りませんか

エージェント開発の成否は、自律性の高さではなく、任せる範囲の設計の確かさで決まります。いま検討中の業務のどこに裁量が要り、どこをルールに倒せるか。話していただければ、構成の当たりをお伝えします。本番で動いている実例は営業自動化AIの本番設計にあります。

参考文献

• Yao et al. (2022) ReAct: Synergizing Reasoning and Acting in Language Models — arXiv:2210.03629
• Schick et al. (2023) Toolformer: Language Models Can Teach Themselves to Use Tools — arXiv:2302.04761
• Wang et al. (2023) A Survey on Large Language Model based Autonomous Agents — arXiv:2308.11432
• Anthropic (2025) Introducing advanced tool use on the Claude Developer Platform — anthropic.com
• Anthropic (2025) How we built our multi-agent research system — anthropic.com
• vLLM Docs, Tool Calling — docs.vllm.ai
• Beurer-Kellner et al. (2025) Design Patterns for Securing LLM Agents against Prompt Injections — arXiv:2506.08837

この記事は、AIツールを活用して作成し、Cognisant 工藤大地がファクトチェック・編集・監修を行っています。事例はすべて公開済みの実案件既出情報です。