8月15日、InfoWorldが「Agentic AI in the enterprise: How to balance autonomy with constraints」と題した記事を公開した。エージェントAIが誤作動したとき、その「爆発半径（blast radius）」——つまり被害の及ぶ範囲——をどこまで設計段階で抑え込めるか。この問いが、エンタープライズへのAIエージェント導入において今最も重要な論点になりつつある。記事はその問いに対し、権限・監査・障害という三つの設計層を軸に、実務的な回答を提示している。

「爆発半径」をどう設計するか：自律性と制約のトレードオフ

エージェントAIの設計で最も重要な問いは、どこまで自律的に動かし、どこで人間の承認を挟むかという判断だ。記事はこの点を実務的な観点から深く掘り下げている。

エージェントに与える権限は「読み取り→書き込み→外部サービスへの操作」の順で影響範囲が拡大する。たとえばCRMのデータを読むだけなら影響は限定的だが、メールを送信したり、本番データベースを更新したりする場合は話が変わる。記事はこうした操作を「爆発半径（blast radius）」という言葉で表現し、エージェントが誤作動したときの被害範囲を事前に設計段階で見積もることを強調している。

自律性を高めれば高めるほどスループットは上がるが、人間が介在する余地は減る。記事が示す現実解は「完全自動化」ではなく、「自動化できる部分は自動化し、重要な判断は人間が行う」構造だ。この前提に立ったうえで、以降の三つの設計層が意味を持つ。

チャットボットの次の段階：エージェントAIとは何か

エンタープライズ現場でのAI活用は、チャットベースのアシスタントから「実際にアクションを実行するシステム」へと移行しつつある。コードを書き、チケットを起票し、CRMレコードを更新し、コンプライアンスチェックを走らせ、プルリクエストを生成する——そういった一連の作業を自律的にこなすシステムが求められるようになった。

記事ではエージェントシステムを次のように定義している。「ユーザーのゴールをステップの連鎖に変換し、ツールを通じてそれを実行し、実行履歴を追跡し、監査可能な結果を生成するソフトウェア」だ。LangChainやAutoGenといったLLMエージェントフレームワークが普及し、こうしたシステムを比較的容易に構築できる環境が整ってきたことも、エンタープライズ導入の議論を加速させている。

LLM（大規模言語モデル）が担うのは計画立案と自然言語処理であり、権限・状態管理・検証・制御といった仕組みは周囲のシステムが提供する。言い換えれば、LLMは「頭脳」だが、それを安全に動かすアーキテクチャは人間が設計しなければならない。

第一層：権限設計——最小権限とチェックポイント

記事が提示する実装上の指針のうち、権限設計に関わるものは以下の通りだ。

• 最小権限の原則（Principle of Least Privilege）：エージェントには、タスクを完了するために必要な最小限の権限だけを与える。全テーブルへの書き込み権限を与えるのではなく、特定のフィールドへのアクセスだけに絞る。セキュリティの文脈では古典的な原則だが、エージェントAIにおいては「モデルが意図せず広範な操作を実行してしまう」リスクを構造的に抑える手段として改めて重要性が増している。
• チェックポイントの設計：影響の大きい操作の前には人間の承認ステップを挟む。完全自動化を目指すより、重要な判断は人間が行う構造が現実的だ。

また、ツール（tool）の設計品質も権限設計の一部として位置づけられる。エージェントはLLMがツールを呼び出すことで動作するが、ツールの設計が曖昧だと、モデルが意図しない操作を実行するリスクが生まれる。具体的には、ツールの名前・説明・パラメータを明確に定義し、副作用（side effect）を持つツールと読み取り専用のツールを明示的に分離することが推奨される。「このツールは外部にメールを送信する」「このツールはデータを変更する」といった情報をモデルが正しく判断できるよう、インターフェース設計そのものが安全装置になるという考え方だ。

第二層：監査設計——何をいつ記録するか

エージェントが「何をしたか」を事後に追跡できる設計は、エンタープライズ運用において不可欠だ。記事は監査ログの設計について、LLMの出力だけを記録するのでは不十分だと指摘する。

ツール呼び出しのパラメータ・実行結果・実行タイムスタンプを含めた形で保存することで初めて、障害発生時の原因調査やコンプライアンス要件への対応が可能になる。エージェントが複数ステップにまたがって動作する場合、どのステップでどのような判断がなされたかを再現できる粒度のログが求められる。

第三層：障害設計——失敗を前提にしたアーキテクチャ

記事はエージェントAIを本番環境に投入する際の現実的な落とし穴も整理している。

• 状態管理の複雑さ：複数ステップにまたがる実行では、途中で失敗したときの再試行や状態の巻き戻しが難しい。トランザクション的な設計が必要になる場面がある。
• モデルの非決定性：同じ入力でもLLMの出力が変わり得るため、テストが困難だ。ゴールデンパス（期待される実行経路）だけでなく、異常系のシナリオを事前に洗い出すことが重要になる。
• コストとレイテンシ：マルチステップの実行では、LLMへの呼び出し回数が増えるにつれてコストとレイテンシが積み上がる。どこまでをエージェントに任せ、どこを従来のルールベースの処理で賄うかのトレードオフを設計段階で意識する必要がある。

三層をつなぐ設計思想

権限・監査・障害——この三層は独立した対策ではなく、互いに補完し合う設計思想として機能する。最小権限で爆発半径を抑え、監査ログで事後検証を可能にし、障害設計で失敗を前提としたリカバリを担保する。いずれが欠けても、エンタープライズ品質のエージェントシステムとは言えない。

エンタープライズでのエージェントAI導入は「LLMを使うかどうか」の議論を超え、権限設計・監査設計・障害設計をどう組み合わせるかというシステムエンジニアリングの問題になりつつある。記事が指摘する通り、LLMは計画と言語を担うが、それを安全に動かす仕組みはあくまで人間が設計しなければならない。

詳細はAgentic AI in the enterprise: How to balance autonomy with constraintsを参照していただきたい。