AIエージェント導入、業務システムでLangChain等は本当に必要か

業務システムに「AIエージェント」を組み込む相談が増えています。ただ、その多くは実際にはエージェントと呼べる代物ではありません。

エージェントという言葉は、ツールを呼び出すだけの関数にも、記憶を持つチャットボットにも、ループ処理するスクリプトにも使われています。この言葉の希釈は単なる用語の問題ではありません。実際に設計判断を誤らせる原因になっています。単純なパイプラインで済む処理に、LangGraph（複数エージェントの処理フローをグラフ構造で組み立てるフレームワーク）やCrewAI（役割分担した複数エージェントを協調させるフレームワーク）を持ち込み、数週間かけてオーケストレーション層を作り込んでから「複雑すぎて保守できない」と気づくケースは珍しくありません。

本稿は、社内システムにAI機能を追加する設計を任されたエンジニアやPMに向けて、エージェント型アーキテクチャを採用すべきかどうかを判断する軸を整理します。フレームワーク選定の前段階、つまり「そもそもエージェントが必要か」という問いに答える内容です。

エージェントか、ただの関数呼び出しか

最初に確認すべきは、対象の処理が本当にエージェントを必要としているかどうかです。ここでのエージェントの定義は、目的（objective）を持ち、指示（instruction）だけでは動かないシステムを指します。

具体的には次の3点を満たすかどうかで判定できます。

• 次に何をすべきかを自分で決める（人間が毎ステップ指示しない）
• ツール呼び出しが失敗したとき、別の手段を試すなど回復動作ができる
• ゴールをサブタスクに分解し、それぞれを委任できる

毎回人間が次の一手を教える必要があるなら、それはエージェントではなくチャットインターフェースです。請求書のOCR結果を確認するだけの画面に「エージェント」という看板を付けても、実態はルールベースの検証フローのままです。

判断軸1: タスクの分岐パターンが事前に列挙できるか

業務システムの多くは、処理の分岐パターンが有限です。たとえば経費精算の承認ルート、在庫引当のロジック、問い合わせの一次切り分けなどは、条件分岐として書き出せます。

この場合、LLM（大規模言語モデル）に毎回「次に何をすべきか」を推論させる必要はありません。ステートマシン（状態遷移を明示的に定義する設計パターン）やルールエンジンで十分なことが多く、推論コストも監査のしやすさも段違いです。

逆に、想定外の入力パターンが継続的に発生し、都度人間が判断していた業務であれば、意思決定を委任する余地があります。カスタマーサポートのトリアージ（問い合わせ内容を見て担当部署や優先度を振り分ける作業）や、フォーマットが定まらない書類からの情報抽出などが典型例です。

判断軸2: 失敗時の回復コストとリスク許容度

エージェントが真価を発揮するのは、ツール呼び出しが失敗したときに別の経路を試せる点です。裏を返せば、失敗時の挙動を設計し切れないなら、エージェント化はリスクになります。

会計システムへの自動仕訳や、外部APIへの発注のように、誤った実行が金銭的損失や取り消し困難な状態を生む処理は、エージェントに完全な自律性を与えるべきではありません。人間の承認ステップ（human-in-the-loop）を挟む設計が現実的です。

一方、社内ドキュメントの下書き作成や、ログからの障害原因の一次切り分けのように、誤りが訂正可能でコストが低い処理であれば、自律的な試行錯誤を許容しやすくなります。

判断軸3: 可観測性を作り込む体力があるか

実運用でうまくいっているチームは、最新モデルへの乗り換えよりも、ツール設計・失敗時のハンドリング・可観測性（observability、システムの内部状態を外部から追跡できる度合い）に時間を使っています。

エージェントがなぜその判断をしたのかを後から追跡できなければ、障害対応もできず、監査対応もできません。既存の業務システムでログ基盤やトレーシング（LangSmith、Langfuseなどのトレース収集ツール、あるいは自社のAPMを流用する形）を整備する体力がないなら、エージェント化は時期尚早です。

監査ログの保存義務がある業務（金融・医療・人事など）では、この軸が特に重くなります。判断根拠を人間が読める形で残せるかどうかを、導入前に必ず確認してください。

判断軸4: フレームワーク依存が既存コードベースに与える負債

LangChain、LangGraph、CrewAI、AutoGen、Semantic Kernelなど、毎月のように新しいフレームワークが登場し、その都度「旧フレームワークはもう終わり」という論調が出てきます。

しかし、フレームワークそのものより重要なのは設計パターンです。特に次の3つは、どのフレームワークを使っても効いてきます。

• Plan-then-execute: 計画を立てる推論ステップと、それを実行するステップを分離する
• 検索と推論の分離: コンテキストを取得する処理と、それを使って判断する処理を混在させない
• 明示的なハンドオフ: エージェント間で作業を渡すときは、構造化されたデータで受け渡し、ログに残す（プロンプト文字列に埋め込んで済ませない）

既存の業務システムに特定フレームワークを深く組み込むと、そのフレームワークのメンテナンス状況に保守運用が引きずられます。数年単位で運用する基幹システムでは、フレームワーク非依存の形でこの3パターンを自前実装する選択肢も検討に値します。

選択肢の比較

ケース別の推奨

分岐パターンを事前に洗い出せる業務なら、ステートマシンかルールエンジンを選びます。エージェント化は監査対応のコストを増やすだけで得るものが少ないはずです。

入力は多様だが、1回のLLM呼び出しで判断が完結するなら、単発プロンプトで十分です。数週間のオーケストレーション実装は過剰投資になりがちです。

サブタスクへの分解、失敗時の代替経路、複数ツールの動的な使い分けが本当に必要な業務であれば、フレームワークを使ったマルチエージェント構成を検討する価値があります。ただし可観測性の整備とセットで進めてください。

あえて見送るべき条件

次のいずれかに当てはまる場合は、エージェント化を一旦見送るのが妥当です。

• ログ基盤・トレーシングを整備する工数を確保できていない
• 誤実行時のロールバック手段が設計されていない
• 監査ログの粒度要件が厳しい業界で、判断根拠の可読な記録が保証できない
• 「最新モデルに乗り換えれば解決する」という前提で設計が始まっている

特に最後の項目は見落とされがちです。モデルを差し替えても、ツール設計や失敗処理を変えなければ挙動は変わりません。

まとめ

エージェント導入を検討する際は、まず対象業務の分岐パターンが列挙可能かを確認してください。可能ならルールベースで十分です。

次に、失敗時の許容コストと承認フローの要否を洗い出し、可観測性を整備する工数があるかを見積もってください。

そのうえでフレームワークを選ぶなら、Plan-then-execute・検索と推論の分離・明示的なハンドオフという3パターンを、選んだフレームワークがどう実現しているかをドキュメントで確認するところから始めてみてください。