AI エージェントは分散システムへ：TikTok のサルマン・ムナフ氏

AI エージェントは「分散システム」である：TikTok 元エンジニアが語る、失敗しないための設計原則

生成 AI の進化により、AI エージェントは単なるテキスト生成から外部システムと相互作用し、状態変更を行う「実行者」へと進化しました。しかし、この変化は本質的にエージェントを「確率的な分散システム」へと変容させており、従来のチャットボットの設計思想のままでは重大なインシデントを防げません。

TikTok の元エンジニアであるサルマン・ムナフ氏は、AI エージェントの導入において重要なのはモデルの知能そのものではなく、エラー発生時のバウンディングと回復を設計するアーキテクチャだと指摘します。本記事では、分散システムとしての視点から AI エージェントを安全に運用するための 5 つの核心原則を解説します。

確率的コーディネーターとしてのリスク管理

AI エージェントが従来のソフトウェアと決定的に異なる点は、その動作原理にあります。従来のマイクロサービスやワークフローは、明確な決定木（デシジョンツリー）に基づいて「確定的」に動作しました。一方、AI エージェントは外部ツールを呼び出し、状態を変更する「確率的コーディネーター」として機能します。

エージェントの取る行動の種類や量は大きく変動し、従来のシステムとは異なり、確定的な制御がなければ深刻な結果を招く可能性があります。

このため、エージェントが外部世界に与える副作用（サイドエフェクト）を制限する「確定的な制御」が不可欠です。例えば、Replicate の AI エージェントが生産環境のデータベースを削除したり、エア・カナダのチャットボットが誤った返金処理を行ったりした事故は、すべてこの「確率的な性質」に対する適切なガバナンスが欠如していたことが原因でした。

トランザクション管理と恒等性の確保

AI エージェントは計画（Planning）→ 実行（Action）→ 観測（Observation）というループを回りますが、各ステップは外部システムとの境界を越える行為です。この際、ネットワーク遅延やタイムアウトが発生した際に「処理が完了したのか不明」という状態に陥るリスクがあります。

タイムアウトは必ずしも失敗を意味しません。「未知（Unknown）」の状態であり、エージェントが誤って再試行して重複実行を引き起こす危険性があります。

これを防ぐには、以下の設計が必須となります。

1. 恒等性の保証: リクエスト ID や幂等性キー（Idempotency Keys）を実装し、同じリクエストが来た際に外部システムで重複した副作用が発生しないようにします。
2. トランザクションと補償操作: エージェントの処理が途中で失敗した場合に備え、ロールバックや「補償操作（Compensation）」を事前に定義する必要があります。例えば、誤ったメールを送信してしまった場合、自動的に謝罪メールを送るなどの補償アクションをシステム側に組み込んでおくのです。
3. 状態の永続化: エージェントがどのステップで失敗したかを特定し、適切な回復を行うために、すべてのコンテキストやアクション履歴をデータベースなどに保存する必要があります。

スコープ付き権限付与と最小権限の原則

多くのチームは、AI エージェントにタスクを完遂させるため、広範な権限（フルアクセス）を与えてしまいがちです。しかし、無害なモデルでも、危険な操作を実行できる権限を与えられれば危険になります。

人間が関与する承認プロセスも、単なる「一括許可」ではなく、「アクション・タイムスタンプ・アクター・有効期限」に紐付くべきです。

例えば、ユーザーが「30 ドルの返金を承認」したとしても、それが自動的に「300 ドルの返金」の承認になるような曖昧な権限管理は避けるべきです。具体的な対策として以下のアプローチが必要です。

• 読み書きの分離: データベースへのアクセス権限を「読み取り専用」と「書き込み専用」に細分化する。
• ホワイトリスト化: エージェントが呼び出せるツールや API を事前に許可リスト（ホワイトリスト）で制限し、それ以外の操作はブロックする。
• スコープ限定認証: 特定のタスク完了後にのみ有効な、期限付きの権限付与を実装する。

包括的な観測可能性と回復経路

従来のシステム開発ではログ（Log）が主要なトラブルシューティング手段でしたが、AI エージェントにおいては不十分です。なぜなら、エージェントは確率的に動作するため、単なるログだけでは「なぜその行動を取ったのか」「どのコンテキストに基づいたのか」を再構築できないからです。

必要なのは、プロンプト、呼び出されたツール、取得したコンテキスト、権限の履歴までを含めたトレーシング（追跡可能性）です。これにより、チームはエージェントがどこで失敗し、なぜその判断に至ったかを正確に再現できます。

また、エラー発生時の自動回復経路も重要です。外部依存が不健康な状態になった際、AI エージェントが無限ループや「リトライストーム（過剰な再試行）」を起こしてシステム全体をダウンさせるのを防ぐため、サーキットブレーカーの導入とレート制限の設定が必須です。

まとめ：堅牢なアーキテクチャこそが真の知能である

AI エージェントは、外部システムと相互作用する分散システムとして扱う必要があります。モデルの推論能力の高さよりも、エラー発生時のバウンディング（範囲限定）と回復メカニズムを設計するアーキテクチャの方が、実運用においては遥かに重要なのです。

生成 AI の導入フェーズにある開発者や企業は、単なるプロンプトエンジニアリングから脱却し、分散システムの堅牢性設計へと意識を転換する必要があります。セキュリティインシデントやデータ不整合を防ぐためには、確率的なエージェントに対して「確定的な制御」を課すことが、未来の AI 社会を支える基盤となるでしょう。