AIシステムを開発する際、エージェントを駆使した自動システムと、すべて制御されたワークフローは、相反するものであり、アーキテクチャの設計時には、その違いを十分に理解しておく必要があります。AIエージェントの普及が進んでいる昨今、開発チームは早晩、ワークフローとエージェントのどちらを採用するかの決断にせまられるときがくるはずです。もう、すでに何度か議論に上っているのかもしれません。

そこで、本稿では、その違いを明確化し、それぞれのメリット／デメリットを検証してみたいと思います。

なぜこんな話をするかというと、最近AIエージェントがやたら魅力的に映るからです。AIエージェントを導入すれば、目の前に新しい世界がひらけ、特別な力を手に入れたような気分になります。ツールやパイプラインだけでなく、有能なスタッフを雇ったかのように複数のエージェント同士（マルチエージェント）が切磋琢磨して、たとえるならAI版のスタートアップ企業を立ち上げたかのような醍醐味があります。

しかし、こんな感覚でエージェントを安易に導入すると、あとで後悔することになります。

エージェントシステムの開発が進行するうち、ふつふつと疑問が湧いてくるはずです。これは一体どうやってモニタリングするのかな？とか、エージェントが思考ループに陥ったとき、どうやってデバッグするのかな？とか、これってそもそもメンテンナンス可能なのか？とか、そういった疑問です。

それら数々の自問自答が湧いてきて初めて、もっとも大事な自問自答を最初に省略してしまっていたことに気づくはずです。「このプロセスには本当にAIエージェントが必要なのか？」という、そもそも論です。

AIを活用するうえで、ワークフローとエージェントには決定的な違いがあります。

エージェントは、上に書いたように、まるで有能なスタッフを雇って仕事を一任するようなものですが、スタッフたちは時にチーム内で混乱を引き起こしたり、なんでこんなに⁉と驚くほどの経費を使ったりします。

複数のスタッフが各自てきぱきと仕事を遂行してくれるマルチエージェントの魅力に取り憑かれた人は、今一歩立ち止まって、よく考えてみてください。決してエージェントがだめだというのではなく、堅実なワークフローだけで十分な場合も多々あり、拙速なエージェントの導入が逆効果になるケースも否めません。

なぜエージェントが必要なのか、どういう効果を期待するのか、事前に明確にすることが何よりも大切です。

AIエージェントの誘惑 ― みんなやっているから、うちもやる

今や95%の企業は生成AIを導入し、79％はAIエージェントを使用しているという調査結果があります。これだけ聞くと、うちの会社も乗り遅れてはならない、という気にさせられるかもしれませんが、実際には、この調査でAIエージェントの活用度を「成熟している」と回答した企業はわずか1％にすぎません。

現実には、ちゃんと動きそうなモデルをつぎはぎして本番環境でバラバラにならないことをひたすら祈っている開発チームも少なくないようです。

初めてAIエージェントを導入し、うまく機能したときには魔法の杖を手に入れたような感覚になります。LLMが次のステップを決め、ツールを選択し、一通りのステップをループしてから答えを導き出してくれるのですから。

しかし、このツール選択がやがて複雑化し、エージェントが同じプロセスを行ったり来たりするようになると、それを修正するロジックを開発者が追加することになります。エージェントを管理するエージェントを追加して、さらにそれを管理するエージェントを追加すると、いつの間にか、大勢の不安げなエージェントでシステムが混雑し、しかもエージェントたちは予算を一切考慮しないで、ひたむきに仕事を遂行しようとします。

もちろん、マルチエージェントで大成功した事例は沢山ありますが、それらは偶然のたまものではなく、インフラストラクチャ、モニタリング体制、フォールバックシステムに多大な投資をして、入念な計画によって実現された一大プロジェクトの場合がほとんどです。

既存のワークフローをさほど費用を増やさずに、信頼性と費用対効果の高い自動システムに置き換えたい場合、AIエージェントが逆効果になる場合も少なくありません。

それが時代の最先端だからとか、モデルが次のステップを自動選択したら効率的なはずだからとか、それだけの理由で必ずAIエージェントを取り入れる義務が開発チームにあるわけではありません。

AIエージェントを使用することは、キッチンで電子レンジの代わりに、シェフをアシスタントに雇うようなものです。シェフは電子レンジよりも柔軟に対応して、美味しい料理を仕上げてくれますが、お金もかかるし、時に頼んでもいない味付けや盛り付けを勝手にやりだしたりもします。

では、どのような場合にAIエージェントを導入するのが得策で、どのような場合に既存のワークフローをキープすべきなのでしょうか。

現実問題として、一体、何と何を比べているのか？

AIエージェントとワークフローのどちらかを選択する前に、両者の定義を整理しておきましょう。これらの定義は、人によって微妙に異なる場合があるので、本稿での解釈を明確にしておきたいと思います。

ワークフロー ― たとえるなら、何でも言うことをきく忠実な愛犬

ワークフローではすべてがオーケストレーション下にあります。開発者がロジックを記述し、場合によってはベクトルストアからコンテキストを取得したり、ツールチェーンを呼び出したりして、LLMに結果を引き出させます。各ステップは明示的であり、不具合が生じた場合はどこに問題があるのかをすぐに見つけ出せます。

RAGパイプラインやプロンプトチェーンは通常これに当たります。すべてを制御でき、テストでき、コストが予測できるという利点があります。

何でも必ず言うことをきく従順で賢い犬のようであり、こちらの計画どおりに動いてくれ、独自にデータベーススキーマを書き換えるような知恵も柔軟性もない代わりに、勝手な行動をとる心配もありません。

シンプルなカスタマーサポートタスクを例に取り上げてみます。このサンプルワークフローは、常にclassify（分類）→ route（割り当て）→ respond（レスポンス生成）→ log（ログ生成）という同じステップをたどります。予測がつきやすく、デバッグが簡単で、処理に一貫性があります。

def customer_support_workflow(customer_message, customer_id):   
　# """明示的に制御された事前定義済みワークフロー"""       

　# ステップ1: メッセージタイプを分類    
　classification_prompt = f"Classify this message: {customer_message}\nOptions: billing, technical, general"    
　message_type = llm_call(classification_prompt)        

　# ステップ2: 分類にもとづいてプロンプトを割り当て（明示的パス）    
　if message_type == "billing":        
　　# お客様の請求情報を取得        
　　billing_data = get_customer_billing(customer_id)        
　　response_prompt = f"Answer this billing question: {customer_message}\nBilling data: {billing_data}"            

　elif message_type == "technical":        
　　# プロンプト情報を取得        
　　product_data = get_product_info(customer_id)        
　　response_prompt = f"Answer this technical question: {customer_message}\nProduct info: {product_data}"            

　else:  # 一般的なレスポンス        
　　response_prompt = f"Provide a helpful general response to: {customer_message}"        

　# ステップ3: レスポンスの生成    
　response = llm_call(response_prompt)        

　# ステップ4: ログの生成    
　log_interaction(customer_id, message_type, response)        
　
　return response

これは決定論的アプローチであり、以下の利点があります。

● 予測可能な処理の実行 ― 入力Aは必ずプロセスB、結果Cにつながる

● 明示的エラーハンドリング ― エラーが生じたら、この処理で対応

● 透明性のあるデバッグ ― コードを追跡して問題を特定可能

● リソースの最適化 ― 必要なコストが明確

エージェント ― たとえるなら賢い子ども、気が利くが、いつも言うことをきくとは限らない

エージェントはプロセスの循環にもとづいています。目標を与えられたLLMがそれを達成する方法を論理的に見つけようとします。そこでは、ツールを選択し、アクションをとり、結果を分析して、次のステップを決定する、といった具合に意思決定プロセスのループが繰り返されます。

AIエージェントのアーキテクチャには以下の機能が備わっています。

• ● 動的で柔軟なツール選択 ― データベースにクエリを送るか、APIを呼び出すかを、エージェントが自分で判断します。

• ● 適応型の論理思考 ― 同じ会話内でミスから学習することができます。

• ● 自己修正能力 ― やってみて機能しなければ、自ら考え、次のアプローチを試します。

• ● 複合的な状態管理 ― 起きたことをトラッキングし、たとえば3ステップ前の結果も考慮します。

前述のワークフローの例と同様に、カスタマーサポートタスクを例に取ると、エージェントはまずナレッジベースを検索し、請求情報を取得してから、顧客のニーズを独自に解釈して、さらに詳細を絞り込むための質問を繰り出します。プロセスの実行手順はすべて、エージェントが何を探り当て、どのような推論を展開したかによって変わってきます。

def customer_support_agent(customer_message, customer_id):    
　# """エージェントによる動的なツール選択と論理思考"""        
　
　# エージェントが利用可能なツール    
　tools = {        
　　"get_billing_info": lambda: get_customer_billing(customer_id),        
　　"get_product_info": lambda: get_product_info(customer_id),        　
　　"search_knowledge_base": lambda query: search_kb(query),        
　　"escalate_to_human": lambda: create_escalation(customer_id),    
　}        
　
　# エージェントがツール情報でプロンプト生成    
　agent_prompt = f"""    
　You are a customer support agent. Help with this message: "{customer_message}"        
　Available tools: {list(tools.keys())}        
　
　Think step by step:    
　1. What type of question is this?    
　2. What information do I need?    
　3. Which tools should I use and in what order?    
　4. How should I respond?        

　Use tools dynamically based on what you discover.    
　"""        

　# エージェントが次のステップを決定（動的な論理思考）    
　agent_response = llm_agent_call(agent_prompt, tools)        

　return agent_response

これは自律したプロセスであり、それこそがAIエージェントの強みなのですが、同時にリスクでもあります。

AIエージェントは、途中で新しい戦略を思いつく可能性があり、混乱すると、同じツールを何度も何度も繰り返し呼び出して検証し続ける可能性があります。

このような状態に陥った場合に警告メッセージを受け取ることができればよいのですが、このようなループプロセスでは、警告メッセージの代わりにリソースの消費が嵩んで巨額の請求書を受け取るのが関の山です。

わかりやすく言うと、ワークフローはカーナビのように機能します。目的地を設定し、すべて指示どおりに運転していれば、ほぼ必ず目的地に到着します。それに比べ、エージェントは、ほかの誰かに地図とスマホとクレジットカードを手渡して、目的地に向かわせるようなものです。その人が歩いて行くか、タクシーを使うか、どこを通るかはその人次第なので、自分がカーナビで行くより、ずっと早く着いたりすることもあれば、時間よりも途中のプロセスを優先して、観光スポットに立ち寄ったり、高くて美味しいものを食べてから満足げに目的地に到着するかもしれません。

両方とも機能しているのですが、大事なのは、「本当に自律システムが必要なのか、それとも手順に沿った確実なフローが必要なのか？」という問いです。

AIエージェントの栄光の裏に隠れたコスト

机上では、AIエージェントは輝いて見えます。目標を与えれば、エージェントが方法を見つけ出して達成してくれるのですから。制御フローをハードコードする必要はなく、タスクさえ定義すれば、あとはエージェントたちに任せておけばよいだけです、理論上は。

実際には、あまり大っぴらには語られない、隠れたコストが嵩みます。お金の話だけでなく、プロセスの複雑化による開発チームの疲弊も考慮しなければなりません。

膨れ上がるトークンコスト

AIのエージェントシステムは単純なチャットインタラクションと比較して、消費されるトークン数が4倍になると言われます。マルチエージェントなら15倍です。論理的な思考と再評価でループして結論に到達するのだから、15倍は決して大げさな数字ではありません。

しかも、これは順調に行った場合の数字で、エージェントのツール呼び出しがループした日には「なんじゃこれは⁉」と思わず叫ばずにはいられない請求書が届くかもしれません。

密林をさまようようなデバッグ

また、不具合が発生した場合、ワークフローは、文字通り、フローがはっきりしているので、デバッグは、地図どおりに経路をたどって行き詰ったポイントを見つけるようなものですが、それに対して、エージェントシステムのデバッグは密林をさまようのに似ています。地図をたどるのではなく、エージェントの思考回路をたどるので、エラーが予測不能な方向に分散している可能性があります。この場合、バグはエージェントの創造的な解釈の問題なので、ブレークポイントを設定して実行パスをトレースするといった伝統的な手法は通用しません。

新しいインフラ設定が必要

エージェントシステムを構築するには、コンピューティングだけでなく、新しいツールセットのレイヤーが必要になります。エージェントシステムを実用化しようとすると、たとえば以下のツールを取りそろえることになります。

● 可視性・監視力を高めるためのLangFuse、Arize、Phoenixなどのツール

● コストやビヘイビアモニタリング用のAgentOps

● カスタムのトークン制御やループ回避のためのフォールバックシステムなど

これらは、オプションではなく、必須と考えるべきです。少なくとも、本番環境でエージェントシステムを実用化する場合、このようなサポート体制抜きではリスクが大きすぎます。

これらはエージェントの栄光の裏に隠された現実を指摘しただけで、決してエージェントシステムの導入を否定しているわけではありません。ただ、費用面、技術的・人的リソース面で、よりコストがかかるというだけで、エージェントシステムを実用化しようとすれば、誰でも遅かれ早かれ気づくことです。

問題は、AIエージェントの便利さを伝えるデモでは、このような側面が見えにくい点です。このような現実的側面をきちんと考慮したうえで、エージェントシステムの導入を検討するのであれば、何の問題もありません。

エージェントは、どのような場合に有効なのか

では、エージェントの導入が有効だと考えられるケースには、どのようなものがあるでしょうか。

AIを活用するうえで、エージェントはトレンドではあるけれど、実際にはワークフローで十分なケースが多いと前述しましたが、ワークフローでは到底太刀打ちできない優れた仕事をエージェントがしてくれるのも事実です。

エージェントは、うまく使えば、融通がきくし、賢いし、ワークフローよりはるかに生産性が高いことは、エージェントの便利さを伝えるデモが示すとおりであり、それを否定する理由はありません。

重要なのは、「最新のトレンドだし、便利そうだからエージェントを導入する」のと、「実際に自律型システムが有効だから導入する」の違いであり、自分が前者ではなく後者であることを計画段階でしっかり確認できているのであれば、ぜひエージェントに取り組むべきです。

実際にエージェントの自律型システムが有効だと思われるユースケースを、具体的に考えてみましょう。

柔軟な対応が必要なカスタマーサポートシステム

カスタマーサポートシステムを構築する際、多くの問い合わせは単純に対応できるものです。たとえば、注文や払い戻しのステータス確認とか、パスワードのリセットなどはワークフローで十分対応可能なはずです。

しかし、お客様との会話が想定できない方向に進み、臨機応変な対応が必要になると、ワークフローでは手に負えません。

これこそまさに、エージェントの出番です。ワークフローが単純なフォームを記入していくような顧客対応であるのに対し、エージェントは状況に応じて異なる対応をします。顧客ニーズに合わせてトラブルシューティングを実行したり、新しいプロダクトやサービスを推奨したり、契約条件を調整したりすることができます。

エージェントベースのカスタマーサポートシステムを導入した企業は、112％から457％、効率性が向上したというレポートがあります。エージェントシステムがうまく機能している場合、顧客の信頼度が高まり、新規の顧客獲得率も上がる実績も報告されています。

件数は少ないが個々にクリティカルな意思決定

エージェントシステムにはお金がかかります。しかし、その結果がビジネスに及ぼす影響のほうがもっとお金がかかる場合があります。

つまり、定型的な大量の決定をワークフローで量産する場合、その中に例外的にちょっとずれた決定事項があっても、ビジネスへの影響が少ないことがワークフローを採用する条件となります。その決定事項がビジネスに多大な影響を及ぼすのなら、定型的に量産すべきではなく、エージェントにもっときめの細かい判断をさせたほうが得策です。

このようなユースケースでは、エージェントへの投資が有意義であり、エージェントシステムが決して高くないという経営判断が成り立ちます。

走り出してみないと行き先が定まらないタスク

前もってフローチャートを描けないケースもあります。正しいステップを見つけるためのタスクは、正しいステップが何であるかが事前に判っていないので、フローを定義しようがありません。たとえば、

● 論文を読んで、比較、要約してくれる技術アシスタント

● 複数の競合プロダクトを調べて総合的なインサイトを引き出すプロダクト分析ボット

● 極端なケースを洗い出して仮定を提案するリサーチエージェント

などが、これに当たります。このような、事前に手順が決定しておらず、結論を得るまでプロセスが繰り返されるようなケースは、エージェントが得意とする分野です。

想定すべき条件が多すぎる／想定しきれないワークフロー

タスクによっては、ワークフローの枝分かれが多すぎて、いちいちハードコードするのが不合理なケースもあります。つまり、IFが多すぎてコード化していたら日が暮れるような場合です。エージェントなら、事前に条件を定義しなくても、LLMがその都度、動的に判断してフローを枝分かれさせてくれるので効率的です。たとえば、診断ツールなどがこれに当たります。

このように、エージェントの活用が有意義なケースは山ほどあります。「エージェントの甘い誘惑に騙されるな」的な、懐疑的なことばかり前半書き連ねましたが、決してエージェントの導入に反対しているわけではありません。むしろ、エージェントが誤解されて、まるでお節介おばさんのような不当な扱いを受けないよう、適切な活用法でエージェントの真価が正しく理解されることを望んでいます。

エージェント vs ワークフローの判断基準

アーキテクチャ設計の誤った意思決定は通常、知識不足からではなく、結論の急ぎ過ぎから発生します。開発会議で誰かが「これは、ワークフローで対応するにはちょっとダイナミック過ぎるのでは？エージェントにちょうどいいかもしれませんね」と発言し、「たしかに、エージェントなら柔軟に対応できて効率的ですね」と誰かが知ったようなことを言えば、ほかの皆は「まぁ、きっとそうなんだろう」と思って特に反論はせず、部長あたりが「うちも、いよいよエージェント制の導入だな」と、エージェントを理解しているのかしていないのかわからないようなコメントで会議を締めくくります。

そして、上に挙げたようなエージェントのカオスに、開発チームは突入していくのです…

こうなる前に、少し立ち止まって考えてみましょう。重要なのは、時代の最先端を行くことではなく、実際に役立つシステムを作ることです。

エージェント vs ワークフローの意思決定には、以下のような点数制の評価基準が参考になるはずです。5つのカテゴリーで状況を採点し、システムに本当に必要なことを判断します。

エージェント導入前評価

1. タスクの複雑さ（2点）

対象となるユースケースには明確な手順が定義されているか。必要なステップを順に記述していくと、プロセスの80%はカバーできるのか。

● はい → ワークフローに+2点

● いいえ → エージェントに+2点

書き出したステップの中に、システム自体で次の展開を推定しなければならない部分がある場合、そのプロジェクトはエージェント導入候補です。

2. ビジネス価値重視か、量産型か（2点）

対応件数が多くても一つひとつの重要度はさほど高くない状況なのか、件数は少ないけど一つひとつの結果がビジネスに大きく影響するのか。

● 大量でも予測可能 → ワークフローに+2点

● 少量でもビジネスへの影響大 → エージェントに+2点

基本的に、少々の間違いは許容できて、むしろコンピューティング費用のほうがビジネスへの影響が大きい場合はワークフロー、結果の適切さのほうがビジネスへの影響が大きくて費用の節約は二の次の場合はエージェントが適しています。

3. 一貫性に対する要求度（1点）

結果の多様性に対する許容度はどの程度か。柔軟性や新しさをいったん脇に置いて、業務の真のニーズを見極めたうえで、システムの出力に対し、どのくらいの多様性を受け入れられるのかを判定します。

● 一貫性が最重要（例：監査、レポート、医療システムのワークフローなど）→ ワークフローに+1点

● ある程度の多様性を許容（例：創造性が求められるタスク、顧客サポート、リサーチなど）→ エージェントに+1点

4. 技術的な成熟度（2点）

現行のシステムやインフラストラクチャの状況を客観的に判断して、開発環境の準備度を判定します。

● 従来型のロギング、モニタリング体制が完備しているが、エージェントシステム用のインフラは未成熟 → ワークフローに+2点

● 監視体制、フォールバックシステム、トークン追跡が完備され、AIプロセスへのチームの理解度も高い → エージェントに+2点

5. 組織的な成熟度（2点）

プロンプトエンジニアリング、ツールオーケストレーション、LLMビヘイビアなど、AIに対する開発チームの習熟度はどれくらいか。

● プロンプトの設計やLLMビヘイビアを学習している段階 → ワークフローに+2点

● 分散システム、LLMループ、ダイナミック推論に習熟 → エージェントに+2点

これは、チームメンバーの能力や知性ではなく、現在の経験値を評価するものです。優秀だから新しいことに挑戦しよう、という意気込みを測るものではありません。

この5つのカテゴリーを採点し、点数を合計したら、以下の判定を導くことができます。

● ワークフローの点数が6点以上 → 引き続き、ワークフローを採用

● エージェントの点数が6点以上 → エージェントの導入を検討する価値あり

発想の転換 ― ハイブリッド

これまで、さんざんエージェント vs ワークフローを論じてきて、今さら何ですが、必ずどちらか一方を選ばなければならないわけではありません。開発環境やチームの状況が許せば、ワークフローの安定感とエージェントの柔軟性の両方を取ることも可能です。

この場合、以下のようなハイブリッドシステムを構成することができます。

• 即応型レイヤー（ワークフロー）― 予測可能な大量処理に対応
• 熟慮型レイヤー（エージェント）― 臨機応変な判断を要する複雑なステップに対応

ハイブリッドシステムの構築手順

ハイブリッドシステムは以下の手順で設計することができます。

1. 中核となるワークフローを定義する。

予測可能なタスクを順番に挙げていきます（データ取得、ベクトル検索、ツール呼び出し、レスポンス生成など）。

2. 意思決定を必要とするポイントを特定する。

どの段階でエージェントによる柔軟な判断が必要になるのかを見極めます。

3. 意思決定ポイントに軽量エージェントを導入する。

ワークフローのリクエストに応じてワークフローに答えを返す、スコープが限定された意思決定エンジンの役割をエージェントに課します。

4. 必要なメモリーとループの制限を定義する。

エージェントが意思決定を行うのに十分なコンテキストを与え、エージェントの推論が既定の枠からはみ出さないように制限します。

5. モニタリングとフォールバックを設置する。

エージェントが余計なことをし出したらデフォルトのワークフローにフォールバックできるメカニズムを設定します。

6. 人的介入ポイントを適宜挿入する。

特にクリティカルなフローでは、エージェントの判断を人間がチェックできるステップを必要に応じて差し込みます。

ハイブリッドが有効なユースケース

ハイブリッドシステムのサンプル

以下に、エージェントとワークフローのハイブリッドによるカスタマーサポートシステムのサンプルを紹介します。このサンプルでは、LangChainとLangGraphを使用しています。ユースケースの大まかな流れは下記のとおりです。

1. 基本ワークフロー ― サポートチケットを取得してエージェント呼び出し

2. エージェントの介入 ― 問い合わせが払い戻しに関する質問か、苦情か、バグレポートなのかを判断

3. ワークフロー ― エージェントのタグに応じて適正な枝分かれフローを実行

4. エージェント ― 問い合わせが苦情の場合、状況を把握して次のステップを提案

5. ワークフロー ― レスポンスを送信し、結果をログに記録

このワークフローでは、大半のチケットはエージェントの介入を必要としないので、ハイブリッドを用いることで、エージェント単独システムと比べてコストを節約できるうえ、複雑さを回避できる利点があります。曖昧な状況に直面したときだけ、エージェントが介入して、エージェントの真価を発揮するしくみです。

from langchain.chat_models import init_chat_modelfrom langchain_community.vectorstores.faiss import FAISS
from langchain_openai import OpenAIEmbeddings
from langchain.chains import create_retrieval_chain
from langchain.chains.combine_documents import create_stuff_documents_chain
from langchain_core.prompts import ChatPromptTemplate
from langgraph.prebuilt import create_react_agent
from langchain_community.tools.tavily_search import TavilySearchResults 

# 1. ワークフロー: RAGパイプラインをセットアップ
embeddings = OpenAIEmbeddings()
vectordb = FAISS.load_local(    
　"docs_index",    
　embeddings,    
　allow_dangerous_deserialization=True
)
retriever = vectordb.as_retriever() 

system_prompt = (    
　"Use the given context to answer the question. "    
　"If you don't know the answer, say you don't know. "    
　"Use three sentences maximum and keep the answer concise.\n\n"    
　"Context: {context}"
)
prompt = ChatPromptTemplate.from_messages([    
　("system", system_prompt),    
　("human", "{input}"),
]) 

llm = init_chat_model("openai:gpt-4.1", temperature=0)qa_chain = create_retrieval_chain(    
　retriever,    
　create_stuff_documents_chain(llm, prompt)
) 

# 2. エージェント: Tavilyでエージェントをセットアップ
search = TavilySearchResults(max_results=2)
agent_llm = init_chat_model("anthropic:claude-3-7-sonnet-latest", temperature=0)agent = create_react_agent(    
　model=agent_llm,    
　tools=[search]
) 

# ヒューリスティックレスポンス
def is_answer_uncertain(answer: str) -> bool:    
　keywords = [        
　　"i don't know", "i'm not sure", "unclear",        
　　"unable to answer", "insufficient information",        
　　"no information", "cannot determine"    
　]    
　return any(k in answer.lower() for k in keywords) 

def hybrid_pipeline(query: str) -> str:    
　# RAGの試行    
　rag_out = qa_chain.invoke({"input": query})    
　rag_answer = rag_out.get("answer", "")        

　if is_answer_uncertain(rag_answer):        
　　# エージェント検索にフォールバック        
　　agent_out = agent.invoke({            
　　　"messages": [{"role": "user", "content": query}]        
　　})        
　　return agent_out["messages"][-1].content        

　return rag_answer 

if __name__ == "__main__":    
　result = hybrid_pipeline("What are the latest developments in AI?")    print(result)

このハイブリッドシステムでは、基本的にワークフローがプロセスを遂行し、結果が曖昧な場合だけエージェントがタスクを引き継ぎます。このため、エージェントにかかる費用は、最低限必要な分だけに抑えることができます。

本番環境は未知の世界

アーキテクチャの構成図やホワイトボード上でのディスカッションは、一度AIシステムが暴走し出したら何の意味も持ちません。ソフトウェアのユーザーは、開発者が予想だにしなかった画期的な使い方でソフトウェアをバグらせる名人です。AIシステムではなおのこと、想定外のユーザーの行動と想定外のAIの行動が共鳴し合って、さらに手の付けられない異常行動に走らせる可能性があります。

開発段階ではそれが予想できず、デモも完璧に機能するので、プロトタイプは関係者一同から高評価を博しますが、本番環境で突然AIモデルが勝手な行動を取り出すことは珍しくありません。当然、トークン使用量が急騰して、コスト効率が著しく下がることにもなります。

これこそが、概念実証（PoC）と実際のシステムの違いであり、ワークフローとエージェントシステムの違いが机上の想定を超えて、運用に悪影響をきたす事例です。ワークフローとエージェントのいずれを採用しても、あるいはハイブリッドシステムの場合でも、本番環境に実装した後は、それはAIの機能性を証明する場ではなく、信頼性、安全性、コスト効率を常に実証し続けなければならない場となります。

だからこそ、AIシステムには以下の要素が欠かせません。

モニタリング（自分のマシンで機能しても本番環境で機能するとは限らない）

エージェントシステムのモニタリングは、オプションではなくマストアイテムです。

エージェントシステムは通常のシステムとは異なり、LLMがなぜループしているのか、なぜ1万トークンも消費したのかを、APMツールで解明することはできません。

エージェントの言語を理解するツールで、トークン使用パターン、ツール呼び出し頻度、レスポンス レイテンシ、インタラクションごとのコストなどを追跡できなければなりません。具体的には、LangFuse、AgentOps、Arize Phoenixなどのツールが必要になります。

コスト管理（気づいたときには遅すぎる）

エージェントシステムのトークン消費量は、上昇するときにはあっという間に上昇します。はじまりは静かで、いつもよりツール呼び出しが2、3回多い程度だったりしますが、それを放っておくと、気づいたときには半月分の予算が1回のエージェント対話で消費されてしまう場合があります。

だからこそ、コスト管理は後付けではなく、インフラストラクチャに組み込む必要があります。たとえば、以下の戦略が有用です。

• ● モデルの動的なルーティング ― シンプルなタスクには軽量モデルを使用して、本当に必要なときだけ本格的なモデルに切り替える。
• ● キャッシング ― 何度も繰り返される同じ質問には、その都度エージェントで対応しない。
• ● 消費量アラート ― 使用状況に異常性が認められるときに自動アラートを発動させる。

セキュリティ（自動だからこそ、しっかり監視を）

AIシステムのセキュリティは付け焼き刃では絶対に対応できません。システムが自分の意思で勝手にAPIを呼び出したり、機密データにアクセスしたり、外部のアクションをトリガーしたりするような場合、後からセキュリティリスクのある部分に防御を施しても、当然カバーしきれるものではありません。「シフトレフト」の設計コンセプトは、AIセキュリティのためにあるようなものです。開発の初期段階から（プロンプトの設計、ツールの構成、パイプラインの設定などに）セキュリティを組み込む必要があります。

開発段階において、以下のようなセキュリティ戦略が重要になります。

• ● エージェントがアクセスするすべてのツールにロールベースアクセス（RBAC）制御を適用する。
• ● 外部API呼び出しには必要最小限の権限を適用する。
• ● エージェントの推論とビヘイビアの全ステップを監査トレイルでカバーする。
• ● プロンプト インジェクション、エージェントのなりすまし、AI脱獄（ジェイルブレーキング）など、最新のサイバー脅威をモデル化する。

通常のアプリケーションでは、コードがビヘイビアを決めるのでセキュリティも対応を定義しやすいですが、エージェントシステムではビヘイビアが動的であり、プロンプト、ツール、ユーザー入力によって状況がどうにでも変わり得るので、想定外にも対応可能なセキュリティが必要になります。

テスト方法（信用はしても確認は必須）

AIシステムをテストするのは、頭脳明晰で真面目な新入社員の能力を確かめるようなものです。大概の仕事は自分でできるし、理路整然としているし、いつも正しいことを言うけれど、時々びっくりするようなことを仕出かします。

だからAIシステムはさまざまな側面から多層的にテストしなければなりません。

特に、エージェントシステムでは、推論プロセスにおける小さな一つのバグが最終的にとんでもない結論につながることがあります。ロジックはプロンプトの中にあり、静的なフローチャートでじっくり検証できるものではないので、以下のような特別なテスト戦略が必要になります。

• ● サンドボックス環境 ― 例外的なケースに対してもストレステストを実施できるよう本番環境に近い疑似データを揃えます。
• ● 段階的な開発テスト ― 実践データを段階的に投入して、結果を確認しながら本番環境に近づけます。
• ● 自動回帰テスト ― モデルのバージョンごとに、期待される出力を自動的に比較できるようにします。
• ● ヒューマン イン ザ ループ（人間が要所要所で検証する）テスト ― 特に、微妙なニュアンスやトーンなど、人間が必ずチェックしなければならない出力があります。

エージェントシステムにおいて、これらはオプションではなく、必須項目として開発ライフサイクルに組み込む必要があります。

結論 ― なるべくシンプルに始めて確かめながら拡張する

ここまで「ワークフローvsエージェント」の議論を進めてまいりましたが、この辺で締めくくりたいと思います。前述のとおり、多くのユースケースはワークフローで対応できる場合が多く、それが堅実であり、実際に有効です。よって、最初はワークフローでの開発を軌道に乗せ、そこに必要に応じてエージェントを組み込んでいくのが得策と思われます。その場合も、エージェントを導入する目的、特にビジネス目標を明確にし、最初は最低限の必要に応じた軽量エージェントを組み込み、検証後に段階的に拡張していくのがベストです。エージェントの導入を決断する際に、その有効性、合理性の評価に本稿が役に立てば幸いです。