7月13日、Bala Priya Cが「Building AI Agents? Here Are Some Anti-Patterns to Avoid.」と題した記事を公開した。この記事では、AIエージェント構築時に陥りがちなアーキテクチャ・運用上のアンチパターンとその対策について詳しく紹介されている。

エージェントはなぜ「普通のAI」と違う壊れ方をするのか

チャットボットが誤った回答を返しても、会話はそこで終わる。しかしエージェントは違う。タスクの途中で判断を誤っても、処理を止めずに走り続ける。誤ったパラメータでツールを呼び出し、後続のステップがその出力に依存し、最終的にユーザーが異変に気づく頃には、すでに複数の誤ったアクションが積み重なっている。

さらに、エージェントはステップをまたいで状態を蓄積する。ステップ2での誤ったツール呼び出しが、ステップ5で参照できるコンテキストを汚染する。これが「エージェントの失敗は程度の問題ではなく、種類が違う」とBala Priya Cが指摘する理由だ。

記事では、こうした失敗のほとんどがモデルの問題ではなく、アーキテクチャ・メモリ設計・ツール設計の問題だと一貫して主張している。

最もよくある失敗：マルチエージェントへの早まった移行

記事が最初に挙げるアンチパターンは、「マルチエージェントアーキテクチャへの早すぎる移行」だ。

チームはマルチエージェントシステムや階層型オーケストレーターの設計論を読み込み、シングルエージェントで解決できるかどうかを検証する前に、そちらへ設計を向けてしまう。マルチエージェントはコーディネーションのオーバーヘッドを生み、トークンコストとデバッグの難易度を事前に見積もりにくい形で増大させる。

移行前に問うべき3つの問いとして、記事は以下を挙げている：

• よく設計されたツールを持つシングルエージェントで、すでに問題を解けるか？
• シングルエージェントアプローチがどこで実際に破綻するか、計測したか？
• そのビジネス価値が、トークンコストと複雑性の増大に見合うか？

「最初のデプロイにはシングルエージェントで十分なことが多い。最もシンプルな手段から始め、計測し、データが必要性を示したときだけ層を追加せよ」というのが記事の結論だ。

見落とされがちな落とし穴：メモリ設計とコンテキスト管理

エンジニアが特に見落としやすいのが、メモリアーキテクチャとコンテキストドリフトの問題だ。

多くのチームはエージェントをチャットボットと同じ設計思想で作る。つまり「会話を渡して、レスポンスを得る」。しかしマルチステップタスクを処理するエージェントは、2ステップ前に何をしたか、ツール呼び出しが成功したかどうか、どんな中間結果を持ち越しているかを知る必要がある。

記事が推奨するのは3層構造のメモリ設計だ：

• 短期セッションメモリ：現在のタスク状態と直近のツール出力
• 長期メモリ（ベクトルストア）：セッションをまたいだコンテキストと学習済みパターン
• 構造化ログ：監査とデバッグのため

「デプロイ済みエージェントにメモリアーキテクチャを後付けするのは本当に苦痛で、たいてい部分的な作り直しになる」と記事は述べており、初日から組み込むことを強く推奨している。

また、長時間稼働するエージェントではコンテキスト腐食（context rot）の問題が発生する。コンテキストウィンドウ内のトークン数が増えるにつれ、モデルが初期情報を正確に参照できなくなる現象だ。コンテキストの「鮮度」が劣化していくイメージに近い。対策として記事が挙げるのは以下の3点：

• トークン上限に近づいた際に古いツール出力を自動削除（会話の流れは保持）
• ツールのレスポンス全体をコンテキストに流し込まず、必要な部分だけを取得
• ツール出力サイズの上限を設け、1つの大きな結果が他を圧迫しないようにする

本文では語られにくい2つのアンチパターン

表にのみ登場し、見落とされやすい2つのアンチパターンについても補足しておきたい。

ツールの肥大化は、エージェントに多数のツールを持たせすぎることで起きる問題だ。ツールの数が増えるほど、モデルが適切なツールを選択する判断は難しくなり、誤った呼び出しや冗長な呼び出しが増える。記事は「ツールは最小限・目的特化・重複なし」を原則とし、似た役割のツールを統合するか、そもそも不要なツールを削ることを推奨している。エージェントが「何でもできる」状態は、往々にして「何も確実にできない」状態と表裏一体だ。

ハードコードされたモノリシックなロジックは、プロンプトや処理ロジックをコードに直接埋め込んでしまう設計上の問題を指す。このアプローチでは、プロンプトを修正するたびにデプロイが必要になり、ツール間の依存が密結合になるためデバッグも困難になる。記事は、プロンプトを設定ファイルとして外部化し、ツールを独立したユニットとして構成することを推奨している。ロジックの変更がコードの変更を必要としない構造にしておくことが、長期的な保守性を大きく左右する。

運用フェーズで露見するアンチパターン

アーキテクチャ以外に、本番稼働後に初めて顕在化する運用上の問題も記事は整理している。

オブザーバビリティの欠如：AIエージェントは非決定論的で推論プロセスが不透明だ。問題が起きたとき、スタックトレースを見ても原因はわからない。プロンプトチェーン、ツール呼び出しとそのパラメータ、推論パス、コンテキストの流れ——これらすべてへの可視性が必要になる。記事は「初行のコードからオブザーバビリティを組み込め」と断言している。

書き込みアクセスの無制限付与：LLMは自信満々に誤った答えを返すことがある。本番システムへの直接書き込みや実ユーザーへの通知を行えるエージェントには、出力と実アクションの間にガードレールが必要だ。読み取りと書き込みは異なるリスクカテゴリとして扱い、高リスク・不可逆なアクションには人間の確認を必須にすることを推奨している。

評価なしのデプロイ：制御されたテスト環境で動作するエージェントが、本番では新たな失敗モードを露出させる。ハッピーパスのテストは「すでに想定していたケース」を確認しているに過ぎない。多様な入力・敵対的入力・エッジケースに対してテストを行い、ビジネス成果に紐づいた成功指標を定義することが必要だ。

アンチパターン一覧

記事末尾には対応表がまとめられている：

詳細はBuilding AI Agents? Here Are Some Anti-Patterns to Avoid.を参照していただきたい。