この記事で扱うこと
「AIエージェント」が単なるチャットボットを超えて、ERPやCRMといった既存システムと連携し、実際の業務プロセスを実行するようになるとき、設計者は何を考えなければならないか。
本記事では、エンタープライズシステムにおけるAIエージェントのアーキテクチャを Agent層・Context層・Control層 の3層に分解し、各層の責務と実装上の判断基準を解説する。特に、API連携・権限管理・監査・運用設計にフォーカスし、現場のエンジニアがすぐに設計に反映できる観点を提供する。
なぜ「プロンプトだけ」では不十分か
多くの組織は、AIエージェントを「より賢いチャットボット」の延長線上で捉えている。より良いモデル、より良いプロンプト、より良いUI──しかし、これではエンタープライズの要求を満たせない。
エンタープライズシステムでAIエージェントが求められるのは、「答えること」ではなく「実行すること」 だ。月末の決算処理において、エージェントは複数のシステムからデータを収集し、仕訳の異常を検知し、承認者への推奨事項を生成する。この一連の流れを、監査可能かつ制御可能な形で実現しなければならない。
そのためには、プロンプトエンジニアリングだけでは到達できない。システムアーキテクチャとしての設計が必要になる。
3層アーキテクチャの全体像
以下の図が示すように、エージェントシステムは既存のデジタルコア（ERP/CRM/HRIS/データ基盤）の上に、3つの層として構築される。
Agent層：エージェントの役割を分離する
最大の設計ミスは、1つの汎用エージェントにすべてを任せることだ。制御不能、テスト困難、そしてビジネスからの信頼を得られない。
実践的な設計では、以下のようにエージェントタイプを分離する。
| タイプ | 責務 | 具体例 |
|---|---|---|
| Orchestrator Agent | ワークフローの進行管理、他エージェントへのディスパッチ | 決算処理の各ステップを制御し、専門エージェントを呼び出す |
| Specialist Agent | 特定ドメインの深い判断 | 購買ポリシーの解釈、契約分析、インシデント原因特定 |
| Task Agent | 単一・反復作業の実行 | 請求書からのデータ抽出、フォームのバリデーション |
| Human Interface Agent | 人間との対話窓口 | チャット、ポータル、メール経由での問い合わせ受付 |
この分離により、各エージェントのスコープが明確になり、テスト・ガバナンス・所有権の管理が劇的に容易になる。
実装上のチェックポイント
- Orchestratorは「何を」「どの順序で」実行するかだけを知っていればよい。ドメイン知識は持たせない。
- Specialist Agentは、そのドメインに閉じたAPI・データソースのみにアクセスさせる。
- Task Agentは冪等性を担保し、再実行可能な設計にする。
Context層：エージェントに「会社の文脈」を理解させる
エージェントが正しく判断するには、単なるドキュメント検索（RAG）以上の文脈が必要だ。
エンティティ間の関係をモデル化する
「この顧客はどの契約に紐づいているか」「この請求書はどの発注書に対応するか」──こうした関係性を理解するために、ナレッジグラフやエンタープライズリレーショナルモデルの導入が有効になる。
# 擬似コード：エンティティ関係の問い合わせ
context = agent_context.query(
entity="Invoice-12345",
relations=["purchase_order", "customer_contract", "approver"],
depth=2
)
権限を考慮した検索（Permission-Aware Retrieval）
最も見落とされがちだが致命的なのが、権限を考慮しない検索だ。HRエージェントが全社員の給与データを取得できてしまう、購買エージェントが戦略的契約を誰でも参照できてしまう──これは重大なデータ漏洩経路になる。
設計原則：
- 検索レイヤーは、呼び出し元のユーザーコンテキスト（ロール、部署、権限）を常に受け取る
- エージェント自身にも「スコープ」を設定し、そのスコープ外のデータにはアクセスできないようにする
- ベクトルDBのメタデータフィルタリングや、グラフDBのエッジ権限制御を活用する
Control層：企業が制御を手放さないために
エージェントが「答える」から「実行する」に移行するほど、この層の重要性は増す。コンプライアンスの付属品ではなく、アーキテクチャの中核と位置づけるべきだ。
エージェントのアイデンティティと最小権限
すべてのエージェントには明確なIDが必要だ。システムは「どのエージェントが」「誰の代わりに」「どの権限で」「どのシステムに」「どのプロセスコンテキストで」アクションを実行したかを常に把握できなければならない。
原則：エージェントには、そのタスクスコープに必要な最小限の権限のみを与える。人間の代わりに動く場合でも、その人間の権限を継承するのではなく、エージェント専用のサービスアカウントを用いる。
明示的な承認ワークフロー
すべてのアクションを自動実行してよいわけではない。以下の条件では、人間の承認を必須とする設計にする。
- 取引金額が閾値を超える
- 機密データ（個人情報、戦略情報）を扱う
- モデルの信頼度が低い
- リスクカテゴリが高い
- 業務影響が大きい（例：発注の確定、取引のキャンセル）
エージェントは推奨事項と根拠を準備し、人間が最終判断を下す。この「人間参加型」の設計は、緊急時のフォールバックではなく、通常運用の一部として組み込む。
完全な監査証跡
最低限、以下の情報が追跡可能でなければならない。
- どのエージェントがアクションを実行したか
- どのデータを入力として使用したか
- どのツール・APIを呼び出したか
- どのポリシーが適用されたか
- どの出力が生成されたか
- 人間の承認が必要だった場合、誰が承認したか
# 監査ログの最小スキーマ例
audit_entry:
agent_id: "procurement-specialist-v2"
user_context: "user:田中太郎, dept:購買部"
action: "create_purchase_order"
input_data: { "po_id": "PO-2024-12345", "amount": 500000 }
tool_call: "SAP_API.create_po"
policy_applied: "approval_threshold: 300000"
output: { "status": "pending_approval" }
approved_by: "user:佐藤部長"
timestamp: "2024-01-15T10:30:00Z"
健全なアーキテクチャの5つの設計原則
-
スコープから始め、モデル能力から始めない
最も強力なモデルを選んでから課題を探すのではなく、ビジネスアウトカムを定義し、エージェントのスコープを決め、必要な能力を選定する。 -
すべてのアクションは説明可能かつ追跡可能であること
成功したかどうかだけでなく、どのように成功したかを説明できなければならない。 -
人間によるオーバーライドはコア機能である
緊急時のフォールバックではなく、通常運用の一部として設計する。 -
グレースフルデグラデーションを設計する
モデルが失敗したとき、ツールが使えないとき、検索が不十分なとき──システムは自律実行から推奨提示へ、マルチステップ実行からドラフト出力へ、セルフサービスから人間へのハンドオフへ、段階的に縮退する。 -
モジュール性を優先する
1つの巨大エージェントより、複数の小さなエージェントの方がテスト・置換・ガバナンスが容易。オーケストレーションのオーバーヘッドは、大規模エンタープライズでは許容できる。
あなたのチームに持ち帰るべき問い
- CIOへ：あなたのエンタープライズアーキテクチャは、エージェントを「本物の運用アイデンティティ」として扱っているか？それとも単なるアプリケーション機能の一部か？
- COOへ：どのプロセスが人間とエージェントの協調運用に本当に耐えられるか？どのプロセスはまだ自律性を許容できないか？
- CHROへ：実行がデジタル労働に移行するとき、人間の役割はどう強化されるべきか？
- 変革リーダーへ：スケール可能な基盤を構築しているか？それとも、運用モデルにならないデモを収集しているだけか？
参考
元記事（日本語）：
https://ariefwara.github.io/ai-for-business/ja/agentic-enterprise-architecture