エージェントアーキテクチャ：ツール・権限・監査の設計

はじめに

結論として、エージェントアーキテクチャの中心はLLMではなくツールゲートウェイです。現場アプリ、基幹、RAG、通知—接続先ごとに権限と監査を分離しないと、一つのプロンプト注入で広範囲が書き換わるリスクがあります。

三層構成

1. オーケストレーション：計画、ステップ実行、人間承認の挟み込み
2. ツール層：APIラッパー、レート制限、入力バリデーション
3. データ層：トランザクションDB、ベクトル索引、オブジェクトストレージ

LLMは1層に閉じ込め、2層で副作用のある操作を必ず検証します。

ツール設計の原則

• 一ツール一責務（「なんでも更新」ツールは作らない）
• 読み取りと書き込みを別ツールに分ける
• 破壊的操作は二段階確認（プレビュー→確定）

権限とロール

エージェント自体にサービスアカウントを持たせ、人間ユーザーのロールを代理する方式が一般的です。代理範囲は最小にし、昇格は時間限定トークンにします。

監査

プロンプト、ツール入出力、承認者IDを相関IDで結び、改ざん耐性のあるストレージに保存します。現場トラブ調査では「誰が何を指示したか」が必須です。

社内ですり合わせのヒント

ツール数が増えたら、オーケストレーション層で「同時実行上限」と「人間承認待ちキュー」を可視化し、現場リーダーが詰まりを把握できるようにします。

導入を検討する組織では、情シスだけでなく現場リーダーを最初のレビューに入れると、後工程の手戻りが減ります。本記事の論点をそのまま議事録の見出しに使い、未決事項と決定事項を分けて残してください。

次のアクション

社内勉強会では、本記事の見出しをそのままアジェンダにし、各項目を15分以内で議論してください。結論が出なくても「誰がいつまでに調査するか」だけ決めれば、次のベンダー面談やパイロット設計が具体化します。資料ダウンロードや相談フォームは、議事録の末尾リンクとして共有すると、後から参加したメンバーも追いやすくなります。

おわりに

アーキテクチャは早期に固定し、モデルは差し替え可能に設計してください。詳細設計の相談も承ります。