LLM（大規模言語モデル）を使った自律型エージェントをフロントエンドやバックエンドに組み込み始めたエンジニアに向けた話です。
従来のアーキテクチャレビューがなぜ通用しにくくなるのか、どこを確認すればよいのかを整理しました。
AWS の Well-Architected Framework（AWS が提唱する設計評価の指針。可用性やセキュリティなど複数の観点でシステムを審査する手法）は、長年ソフトウェア設計レビューの共通言語として使われてきました。
この枠組みが前提としていたのは「リクエストが届く前に、実行経路を図に描ける」という単純な事実です。
ところがエージェント型 AI では、この前提そのものが崩れます。
何が起きるか エージェントで壊れるのはコンポーネントではなく「呼び出し図」
通信プロトコルや個々のコンポーネントが壊れるわけではありません。
MCP（Model Context Protocol。LLM と外部ツールを接続するための標準プロトコル）も A2A（Agent-to-Agent。エージェント同士が連携するための通信方式）も、依然としてリクエスト・レスポンス型です。
レート制限や監視も、既存の手法でそのまま対応できます。
問題が起きるのは、その一段上の層です。
エージェント型サービスへの1回のリクエストが、可変個数のモデル呼び出し・メモリ検索・ツール呼び出し・エージェント間メッセージに展開されます。
設計によっては、その回数に上限がありません。
たとえば、ユーザーの1つの質問に対してエージェントが「まず検索ツールを呼ぶか」「もう一度推論するか」「別のエージェントに委譲するか」を、実行の都度その場で判断します。
同じ入力でも、モデルの温度設定や取得したコンテキストの違いによって、翌日には別の経路をたどることがあります。
永続メモリ（セッションをまたいで情報を保持する仕組み）を持たせた場合は、一見孤立したリクエストでも、過去のセッションで蓄積された情報に結果が左右されます。
つまり、呼び出し図（コールグラフ）はデプロイ前に完全には確定していません。
実行時に一部が組み立てられる、という点が根本的な変化です。
なぜ起きるか 「事前に描ける経路」という前提が壊れる過程
原因を段階的に分解すると、3つの層に分かれます。
1つ目は、推論のループ構造です。
従来の機械学習推論は「リクエスト→特徴量→推論→結果」という一方向の流れで、モデルは意思決定者ではなく1つの部品でした。
エージェントでは、モデル自身が「次に何をするか」「結果で十分か」「もう1周推論するか」を判断します。
このループの回数が可変、あるいは無制限になる設計が珍しくありません。
2つ目は、確率的な振る舞いです。
同じプロンプトを与えても、サンプリングの設定や取得コンテキストの違いにより、出力が実行ごとに変わります。
フロントエンドの UI テストのように「同じ入力なら同じ出力」を前提にしたスナップショットテストが、そのままでは機能しにくくなります。
3つ目は、自律的なツール呼び出しです。
各ステップで人間の指示を待たず、モデルがツールを選択して実行します。
Web フロントエンドの文脈で言えば、サーバーサイドで API を叩く関数呼び出しの「呼び出し先・呼び出し回数・呼び出し順序」のすべてが、実行時まで確定しないイメージです。
AWS は2026年6月10日に公開した Well-Architected Agentic AI Lens（既存の6つの柱をエージェント特有の観点で再解釈する追加ガイド）の中で、この状況を「推論する」「自律的に行動する」「確率的に振る舞う」「協調する」という特性で説明しています。
既存の6本柱を置き換えるのではなく、エージェント特有の5つの性質を軸に再解釈する構成になっている点がポイントです。
自分のプロジェクトが該当するか確認する方法
次の観点で、手元のプロジェクトを点検してみてください。
- LLM の呼び出しが while ループやエージェント実行ループ（LangGraph・AutoGen・OpenAI Agents SDK など）の中にあるか
- 1リクエストあたりのモデル呼び出し回数に、コード上で明示的な上限（
max_iterationsやmax_turns相当の設定）があるか - ツール呼び出しの選択をモデルが行っているか、それとも開発者が書いた分岐ロジックが行っているか
- セッション間で永続化されるメモリストア（ベクトルDBやキャッシュ）を参照する設計になっているか
- 同じ入力でリクエストを2回送った際に、レスポンスの構造（呼ばれるツールの種類や回数）が変わるか
該当箇所の探し方としては、まずリポジトリ内で LLM クライアントの呼び出し箇所を検索し、その呼び出しが単発の関数呼び出しか、ループの内部かを確認します。
Python 系のエージェントフレームワークであれば、実行ループを定義するクラス（AgentExecutor や Graph など）の有無を grep で確認するのが手早い方法です。
grep -rn "max_iterations\|max_turns\|AgentExecutor\|while True" src/上限設定が見当たらない、あるいは無限ループに近い実装になっている場合、その部分が今回のリスクの対象です。
対策の手順
呼び出し図が事前に確定できないという前提に立ち、レビューのやり方を変える必要があります。
1. 実行回数に上限を設ける。ループ回数・ツール呼び出し回数・トークン消費量のいずれかに明示的な上限値を設定し、超過時のフォールバック動作（人間へのエスカレーションやデフォルト応答）を定義します。
2. 経路を観測可能にする。事前に図が描けない代わりに、実行後にトレースを残します。OpenTelemetry などの分散トレーシングにエージェントのステップ単位でスパンを記録し、どのツールが何回呼ばれたかを事後的に再構成できるようにします。
3. 確率的な出力を前提にしたテスト設計に切り替える。厳密な出力一致ではなく、出力が満たすべき性質（許可されたツールのみ呼んでいるか、応答時間が閾値内か）を検証するプロパティベースのテストを組みます。
4. メモリの影響範囲を切り分ける。永続メモリを使う機能とステートレスな機能を明確に分離し、メモリ由来の挙動変化をログ上で追跡できるようにします。
5. 既存の WAF レビューに「エージェント固有の観点」を追加する。AWS の Agentic AI Lens や、Google・Microsoft が出している同種のガイダンスを、既存の6本柱・4本柱のチェックリストに追記する形で運用します。既存の枠組みを捨てるのではなく、上乗せする発想です。
WebAssembly やエッジランタイムでエージェントの一部処理をサンドボックス実行する構成を検討している場合も、上限設定とトレース収集の考え方はそのまま流用できます。
Cloudflare Workers や Deno Deploy のようなエッジ環境では、実行時間そのものに制約があるため、ループの上限設計がより早い段階で必須になります。
導入前に確認すること
エージェント型の機能を設計に組み込む前に、次の3点を確認してください。
- LLM 呼び出しのループに明示的な上限があるか、
grepで実装を確認する - 実行経路をトレースできる観測基盤（OpenTelemetry 等）が導入済みか
- 既存のアーキテクチャレビューのチェックリストに、確率的な振る舞いと自律的なツール呼び出しの観点が追加されているか
これらが未整備であれば、まずは上限値の設定とトレース導入から着手するのが現実的な出発点になります。
呼び出し図を事前に描けないという前提を受け入れたうえで、実行後に検証できる仕組みを整えることが、エージェント時代のレビューの出発点です。