【ITニュース解説】Building AI Agents in Production: What MCP Rejections, .env Leaks, and 70-Line Loops Taught Me

AIエージェントを本番環境で運用する際には、AIモデルの性能だけでなく、そのAIを支えるシステム全体の設計（エンジニアリング）が極めて重要だ。筆者は自身の経験から、AIエージェントの未熟なアーキテクチャが原因で、モデルコンテキストプロトコル（MCP）のリジェクション、環境変数漏洩、そして70行にも及ぶ無限ループといった問題に直面し、課金サービス停止などの事態を経験したと語る。この記事は、AIの指示（プロンプト）の工夫ではなく、デモ版と本番で安定稼働するシステムを分けるための「裏側の仕組み」に焦点を当てている。

AIエージェントを本番環境で構築する際の最初の誤解は、AI（大規模言語モデル、LLM）への一回の指示と、外部ツールの一回の呼び出しで全てが解決すると考えることだ。しかし、実際のシステムでは、エージェントは過去の情報を記憶し（状態持ち）、複数のステップで推論を進め、問題発生時の明確な対処方法を定義する必要がある。モデルコンテキストプロトコル（MCP）はAIと外部システム間の連携を円滑にする目的で設計されたが、MCPからのリジェクション（拒否）は、エージェントの信頼性に関する設計上の深い欠陥を露呈させる。MCPサーバーからのリジェクションは、単なるツール呼び出しの失敗ではなく、エージェントが「この状況はサポートできない」状態に陥ったことを示す。これは、AIがツールを間違った順序で呼び出したり、AIが一度に処理できる情報量（コンテキストウィンドウ）がサーバーの容量を超えたり、セッション途中で認証情報が期限切れになったり、APIの利用制限（レートリミット）に達したりしたときに発生する。重要なのは、MCPリジェクションを単なるエラーではなく「特別なイベント」として捉え、回復可能な状態に移行させるための「リジェクションハンドラー」を設けることだ。このハンドラーは、コンテキスト圧縮、指数バックオフでの再試行、認証情報の更新といった対応を行う。

次に、AIシステムにおける環境変数（システム設定情報）の管理は、従来のアプリケーションとは大きく異なる。AIエージェントは動的に指示を生成し、外部APIを呼び出し、機密情報を含む出力を生成する可能性があるため、設定ミス一つでAPIキーやデータベースの認証情報、顧客の個人情報などがエージェントの出力を通じて漏洩する恐れがある。筆者は、設定ミスにより本番データベースの接続文字列がエージェントに渡され、AIが「完全な診断情報を提供せよ」という指示に従って接続文字列を応答に含めてしまった経験を語る。これはAIモデル自体の問題ではなく、実行時の設定情報とAIの処理対象情報の分離が不十分だったためである。この問題を解決するためには、エージェントプロセスには現在のタスクに必要な環境変数のみを渡す「最小限の環境の原則」を適用し、認証情報を起動時に読み込むのではなく、セキュアなエンドポイントを通じて「動的に取得する」仕組みを導入する。さらに、エージェントの全ての出力が、ユーザーや他のシステムに送られる前に、認証情報パターンを検出・匿名化する「出力サニタイズ層」を通過させるべきである。

本番AIエージェントにおける最も厄介なバグの一つが「無限推論ループ」だ。エージェントが進行することなくツール呼び出しを繰り返し、システムリソースを際限なく消費し続ける状態を指す。これはシステムが即座にクラッシュするよりもはるかに危険である。筆者は、ツール利用のルールが緩すぎたエージェントで、AIが「ユーザーデータ取得→結果空→ID検証→失敗→セッション更新→無効→再度ユーザーデータ取得」といったサイクルに陥る事例を観察した。この問題の解決には、複数の層で明確な終了条件を設定する必要がある。まず、エージェントの実行ごとにツール呼び出しの回数に厳密な上限を設ける「最大イテレーション制限」だ。次に、エージェントが次のツール呼び出しを行う前に、行動がシステムの状態を意味ある形で変更したかを検証する「進行状況の検出」を行い、進展がない場合は処理を強制終了させる。さらに、最近のツール呼び出しのシグネチャ（例えば、呼び出されたツールとパラメータの組み合わせのハッシュ値）を記録し、同じ呼び出しが繰り返された場合にループと判断して別の推論経路を取るよう要求する「ツール状態の重複排除」も有効である。

本番環境で実際に成果を出したアーキテクチャパターンも存在する。ツール呼び出しの失敗を一時的なものとせず、連続した失敗後に「回路を開く」ことで過負荷を防ぐ「サーキットブレーカーパターン」。エージェントのロジックを明確な「ステートマシン」として表現し、各状態に決まった遷移、タイムアウト、エラー処理を持たせることでデバッグを容易にする方法。そして、全てのエージェントの実行が、ツール呼び出しのシーケンス、応答時間、リジェクション理由、状態遷移などの構造化された監視データを出力する「可観測性（オブザーバビリティ）」を第一級の関心事とすること。これらがなければ、本番環境で問題が発生した際に盲目的にデバッグすることになる。

開発と運用の心得として、AIエージェントのコアな処理がうまく機能することも証明できていないのに、高度なアーキテクチャを過剰に設計してしまうのは誤りだ。まずはシンプルなアーキテクチャで正常な処理経路（ハッピーパス）を動かし、テストで実際に観察された失敗モードに基づいて、一つずつ回復力のあるパターンを追加していくのが賢明である。

最後に、AIエージェントは単なる技術システムではなく、「社会技術システム」であるという最も重要な教訓がある。エージェントは、期待、不満、そして独自の回避策を持つ人間と相互作用する。技術的には動作しても、ユーザーを混乱させたり不満を与えたりするエージェントは、いかなる技術的負債よりも早く本番環境で失敗するだろう。筆者が送り出した最高のAIエージェントは、その「限界を明確にする」という共通の特徴を持っている。MCP呼び出しが失敗したとき、エージェントは沈黙して再試行するのではなく、何が問題だったかをユーザーに伝え、次のステップを提案する。認証情報の問題に遭遇した場合も、アクセスレベルを下げて進行するのではなく、再認証を求める。このような透明性は信頼を築き、隠れた失敗は信頼を損なう。本番AIエージェントのエンジニアリングは、大規模言語モデルとの連携を完璧にすることよりも、そのAIの周りに堅牢で、監視可能で、人間を意識したシステムを構築することなのだ。MCPリジェクション、環境変数漏洩、そして無限ループは、特別なケースではなく、システムエンジニアが学ぶべき重要なカリキュラムそのものである。これらをマスターすれば、AIエージェントは本番環境で生き残ることができるだろう。