Skip to Content
Docs07. ケーススタディケーススタディ: 経費精算アシスタントの段階的 Agent 化
中級ai-agentworkflowtool-use更新: 2026-07-05この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

ケーススタディ: 経費精算アシスタントの段階的 Agent 化

注記: 本記事は、本ライブラリの設計判断を 1 つの物語で通すために構成した**架空の事例(構成事例)**です。登場する組織・数値は実在のものではありませんが、各段階の判断と失敗は実際のプロジェクトで広く観察されるものに基づいています。

この記事の目的

「経費精算の問い合わせ対応」という 1 つの題材を、単発の LLM 呼び出し → Workflow 型処理手順を開発者がコードで固定し、LLM を各ステップの部品(分類・要約・生成など)として使う構成。Agent との対比概念。 → ツール実行型 Agent へと段階的に育てる過程を追い、各段階で「なぜその構成を選ぶか」「いつ次へ進むか」の判断を実例の形で身につけます。本ライブラリ各記事の設計判断を、時系列で接続して見る記事です。

対象読者

  • 最初の Agent プロジェクトをこれから始めるエンジニア(全体の流れの予習として)
  • 概念・設計の各記事は読んだが、判断が実際にどうつながるかを掴みたい人

前提知識

本文

概要: 題材と最終形

題材は社内の経費精算アシスタントです。要件は段階的に増えていきます — (1) 経費規定の Q&A、(2) 申請状況の照会、(3) 差し戻された申請の修正支援。最終形は「照会は自律、書き込みは承認付き」のツール実行型 Agent ですが、最初からそれを作らなかったことがこの事例の要点です。

詳細: v0 — 単発の LLM 呼び出し(規定 Q&A)

最初の要件は「経費規定についての質問に答える」だけでした。構成は、規定文書を検索して回答する典型的な RAG外部の知識ソースを検索し、結果を LLM の入力に加えて回答の根拠にする手法。検索の判断を Agent に任せる構成は Agentic RAG と呼ばれる。 です(RAG と Agent の関係・使い分け)。Agent は不要と判断しました — 「1 回検索して答える」で足りる質問が大半で、自律的な反復検索の価値がまだ確認できていなかったためです。

  • この段階の学び: 手元 15 問の評価セットを最初に作ったことが後まで効きました。以後のすべての構成変更で「規定 Q&A が壊れていないか」を数分で確認できるようになりました(Agent 評価の基礎)

詳細: v1 — Workflow 型(照会の追加)

「私の 3 月の申請、どうなってますか」に答える要件が加わりました。ここで「Agent 化するか」が最初の分岐でした。検討の結果、Workflow 型を選びました(Workflow 型 vs Agent 型の使い分け)。

  • 理由: 問い合わせの型が「規定の質問」と「申請状況の照会」の 2 つに分類でき、それぞれの処理手順は固定できたためです。LLM は「分類」と「回答文の生成」の部品として使い、照会 API の呼び出しはコードで固定しました
  • 効果: 挙動が予測可能で、レイテンシもコストも安定しました。この構成で 3 か月運用し、実際の問い合わせログが溜まりました

詳細: v2 — ツール実行型 Agent への移行(判断の根拠つき)

ログを分析すると、Workflow の分類に収まらない複合的な問い合わせが約 2 割ありました(「差し戻された理由と、直すべき項目と、締切を教えて」など、照会と規定検索を行き来する必要があるもの)。手順を固定できない実タスクの証拠が揃ったことが、Agent 化の判断根拠です。

移行時の設計は本ライブラリの各記事の判断をそのまま適用しました。

設計項目判断参照
ツールsearch_policy(規定検索)と search_expenses(申請照会)の 2 つ、読み取り専用から開始ツール定義の設計
停止条件最大 10 ステップ・タイムアウト・タスクあたりトークン予算をコード側にAgent ループ
プロンプト役割・判断基準(「情報不足なら推測せず質問」)・停止指示を明文化Agent 向けプロンプト設計
記録全ステップの構造化トレース(のちの評価・運用と共通形式)可観測性とトレーシング

最小の Agent ループLLM が「観測 → 思考 → 行動」のサイクルを繰り返し、完了・失敗・上限のいずれかの停止条件まで自律的に処理を続ける制御構造。の実装イメージは examples/python/tool-use/ にあります(本事例の v2 照会部分に相当する最小構成です)。

詳細: v3 — 書き込みの追加は「承認付き」で

最後の要件「差し戻された申請の修正支援」で、初めて書き込み(申請の更新)が入りました。ここでの判断は 2 つです。

  1. 修正案の作成までを Agent、提出は承認後 — 修正の提出は取り消しにくい操作のため、事前承認型にしました(Human-in-the-Loop 設計)。承認対象は「差分の要約」を見せる形にし、承認疲れを避けるため読み取り操作には承認を付けていません
  2. 書き込みツールは修正提出の 1 つだけ、対象は本人の申請のみ — ツール実装側で申請者本人のスコープを強制し、モデルへの指示に依存しない認可にしました(ツール権限設計とサンドボックス)

詳細: 投入前の評価と運用開始

  • 評価セットをログ由来の 50 ケースに拡張し、規定 Q&A(judge 採点)・照会(最終状態の検証)・複合タスク(マイルストーン部分点)で構成しました(LLM-as-a-Judge、軌跡(trajectory)評価)
  • 「書き込みツールが承認なしに実行されない」ことを軌跡のアサーションにしました
  • CI は PR ごとに smoke 10 ケース、夜間にフルスイートとしました(回帰テストと CI 組み込み)
  • 運用側は、タスク単位コストの記録・ステップ数分布の監視・機能フラグでの縮退(Agent を止めて v1 の Workflow に戻す)を用意しました(インシデント対応)

設計判断: この事例の教訓

  1. 段階を飛ばさない — v0 → v1 → v2 の各段階で「今の構成の限界の証拠」を得てから次へ進みました。最初から v3 を作っていたら、2 割のためのループ構造に 10 割のコストを払い、書き込み権限のリスクを最初から抱えていたはずです
  2. 評価セットが移行を可能にした — 構成を 3 回変えても品質の劣化をその日に検知できたのは、v0 の 15 問から評価を積んでいたからです
  3. 自律性と権限は別々に広げる — 自律性(ループ)を導入した v2 では権限を読み取りに固定し、権限(書き込み)を広げた v3 では承認で自律性を制限しました。両方を同時に広げないことがリスクを線形に保ちます

実務での注意点

アンチパターン

  • この事例の順序を「常に正しい唯一の道」と読む → 題材が変われば分岐の答えも変わる(最初から Agent が正しいタスクもある) → 各分岐の「判断根拠」の方を持ち帰り、自分のタスクで判断し直す
  • 段階的移行を「遅い」と省略する → 限界の証拠なしの Agent 化は、コスト・不安定さ・権限リスクを先払いする賭けになる → 各段階の運用ログを次の段階の判断材料にする
  • 架空事例の数値(2 割・50 ケース等)を基準値として引用する → これらは物語のための例示であり、実測に基づく推奨値ではない → 自分のログ・評価から自分の数値を得る

チェックリスト

  • 現在の構成(単発・Workflow・Agent)の「限界の証拠」を運用データで示せる
  • 次の段階に進む判断根拠が文書化されている
  • 評価セットが構成変更をまたいで維持・拡張されている
  • 自律性と権限を同時に広げていない
  • 前の構成へ戻す手段(縮退)が残っている

関連トピック

参考資料

TODO・未確認事項

なし

よくあるアンチパターン集(横断)ケーススタディ: メールアシスタントの情報漏えいインシデント