注目ポイント
- AIの失敗はモデルではなくアーキテクチャに起因します。AIの成果を左右するのは、その基盤となる構造です。
- 信頼とガバナンスは後付けではなく、設計当初から組み込む必要があります。
- ベンダーロックインを回避するため、モジュール化とオープンスタンダードに基づいた設計を行います。
※本記事は2026年3月23日に米国で公開された8 Design Principles for the Agentic Enterpriseの抄訳です。本記事の正式言語は英語であり、その内容および解釈については英語が優先されます。
AI導入が失敗した際、モデルの性能やユースケースの選択ミス、あるいは現場の抵抗を理由にしたくなるかもしれません。
しかし、本質的な問題はより深いところにあります。不適切な既存のアーキテクチャの上に単にAIエージェントを被せるだけでは機能することはありません。それはモデルが古いからではなく、従来のアーキテクチャがAIエージェントのワークロードを想定して設計されていないからです。
エージェンティック エンタープライズの導入を成功させるには、4つのアーキテクチャ層が不可欠です。それらは、人とエージェントが協働する System of Engagement（エンゲージメントのためのシステム）、AIエージェントそのものである System of Agency（AIエージェントのためのシステム）、企業のビジネスアプリケーションである System of Work（業務のためのシステム）、そして統合された企業データである System of Data（データのためのシステム）です。
エージェンティック エンタープライズの成否は、これらの層がいかに連携するかにかかっています。Salesforce の製品およびアーキテクチャチームのリーダーたちは、長年の戦略、イノベーション、そして生成AIおよび自律型AIの経験に基づいて、その知見を8つの設計の柱に凝縮しました。これは優れた実装のあり方と注意すべきリスクを示すフレームワークです。
1. モジュール化を考慮した設計
レゴブロックのセットを想像してみてください。同じブロックの組み合わせで、飛行機でも家でも消防車でも作ることができます。 エージェンティックAIのアーキテクチャにも、同様のモジュール化された柔軟性が必要です。AIエージェントに新しい機能を追加するたびに、アーキテクチャ全体をゼロから再構築する余裕はありません。それでは時間もコストもかかり過ぎます。また、それはAIを利用する本来の目的にも反しています。すべてのAIエージェントが独自の仕様でバラバラであれば、ガバナンスを効かせることができなくなるからです。
- 理想的な状態： モジュール化された「既製品」のメニューを活用します。顧客オンボーディング用エージェントの開発から半年後に、顧客オフボーディング用エージェントが必要になった場合でも、既存のデータコネクタやインテグレーションを再利用するだけで済みます。
- 問題がある状態： 既存のAIエージェントにわずかな変更を加えるだけでシステムのリブートが必要になったり、新しいAPIの呼び出しやAIエージェントを追加するたびに既存アーキテクチャの調整に1ヶ月も要したりする場合、その設計は機能していません。
2. メタデータ駆動型の理解によるデータの調和
人であれば、CRM 上の「Acme Corp」と、ERP 上の「Acme Corporation」、データウェアハウス上の「ACME-NA」が同一であることを理解できます。
AI エージェントには、単に統合されたデータだけでなく、それが何を意味するかを理解するためのメタデータが必要です。
- 理想的な状態： 共通の命名規則に基づき、一貫してファイルにラベルが付与されている状態です。AIエージェントはデータ、メタデータ、ビジネス用語集、オントロジーにアクセスできます。これらのツールを備えることで、AIエージェントは情報のつながりをより正確に把握し、時間の経過とともに学習を深めることができます。
- 問題がある状態： AIエージェントが割り当てられたタスク（例：大幅な値引きによる売上拡大）を達成したものの、会社が 1 件の販売ごとに赤字を出すような事態です。データが適切に相互接続されていないと、AIエージェントはその決定が財務的にも健全であるべきだというコンテキスト（文脈）を理解できません。
AIエージェントにはガードレールが必要です。そのため、ガバナンスと信頼の原則を、エージェンティック エンタープライズのアーキテクチャのDNAそのものに組み込む必要があります
3. 統合されたオブザーバビリティ（可観測性）の実現
AIエージェントが誤った動作をした際、その理由を全員が把握できる必要があります。AIエージェントがどのように（そしてどこで）アクションを実行しているかを明確に可視化することで、システムを意図通りに微調整し、不具合が発生した際も容易に修正できるようになります。
統合されたオブザーバビリティとは、アクション（何をしたか）、推論（なぜその道筋を選んだか）、コンテキスト（どのデータと言語定義を使用したか）、ガバナンス（ポリシーや権限をどう遵守したか）、そしてビジネス成果（何が変化し、どの程度の効果があったか）をリアルタイムに把握することを意味します。また、このオブザーバビリティはIT部門とビジネス部門の両方にまたがる必要があり、一方の影響が他方にどう及ぶかを明確にする必要があります。
- 理想的な状態： どのアクションが最も頻繁に使用されているか、どこでミスが起きているか、そしてそれらのアクションがいかにビジネス成果を導いているかを把握できている状態です。この包括的なオブザーバビリティにより、AIエージェントの労働力を最適化することが可能になります。
- 問題がある状態： オブザーバビリティが確保されていないと、ミス（必ず発生するものです）が起きた際にその原因を追跡できません。
4. 信頼を基盤とした構築
AIエージェントは、財務システムへの書き込み、エグゼクティブの代理でのメール送信、契約の承認などを実行できます。そのためには、ガードレールが不可欠です。ガバナンスと信頼の原則をエージェンティック エンタープライズのアーキテクチャのDNAそのものに組み込む必要があります。
- 理想的な状態： ガバナンスがアーキテクチャ全体に浸透している状態です。これには、AIエージェントに対する明確で検証可能なアイデンティティの付与、無期限のアクセス権ではなく特定期間で期限が切れるタスクベースの権限設定、そして確立されたポリシーやリスクプロトコルに照らしてチェックとバランスを機能させるワークフローのステップなどが含まれます。
- 問題がある状態： 信頼できないシステムを人が利用することはありません。
5. 戦略的な人の介入と監視のための設計
空港の保安検査場を思い浮かべてください。全乗客の身体検査をしたり、すべての機内持ち込み手荷物をかき回して調べたりするのは過剰であり、混雑を招きます。一方で、全員をノーチェックで通すのは危険です。正解は、すべての手荷物をX線検査にかけ、不審なものだけを抽出して詳細な検査を行うことです。AIエージェントにも、同様の戦略的な人による監視が必要です。 意思決定の各ポイントにおいて、人が関与する（Human-in-the-loop）適切なレベルを設計してください。
- 理想的な状態：AIエージェントはデフォルトで日常的な低リスクのタスクを処理し、ユーザーが担当外の事項を要求したり、人との対話を求めたりした場合には人に通知します。AIエージェントから人への引き継ぎはコンテキストを保持したままスムーズに行われ、人が最初からケースをやり直す必要はありません。
- 問題がある状態： すべてのAIエージェントの決定に人の介入が必要な状態、あるいは逆にAIエージェントが常に全く監視されることなく意思決定を行っている状態です。
6. イベント駆動型プロセッシングの有効化
ビジネスのスピードには、リアルタイムの意思決定が求められます。AIエージェントは常に稼働し、テキストやメール、通話、APIなど、あらゆるチャネルを通じて対応が必要なトリガーを監視する必要があります。
- 理想的な状態： アーキテクチャがリアルタイムのトリガーやマルチモーダルな入力に反応する状態です。AIエージェントは、返金について問い合わせる顧客からの電話と、システム停止を知らせるシステムからの通知の両方に対応できます。
- 問題がある状態： チャネルを越えたリアルタイムの接続性が確保されていないと電話は放置され、メッセージは未読のままになります。異なる情報セットで動くAIエージェントは不正確な結論を導き、顧客の不満を招きます。
7. AIワークロードの増大に対応するインフラの拡張性
AIワークロードの課題は、計算ニーズが集中するだけでなく、予測不可能である点にあります。負荷は数秒で劇的に急増し、データの取得量やトークンの使用量も大きく変動します。エージェンティック エンタープライズのアーキテクチャには、レジリエンス（回復力）が求められます。
- 理想的な状態： AI対応のインフラには、ワークロードのニーズに応じて拡張する計算リソースが含まれます。負荷を分散させることで、単一の障害点による致命的なシステムダウンのリスクを軽減します。また、予測不可能なデータアクセスパターンに対応できるストレージと、APIトラフィックの増加を許容できる帯域幅が必要です。
- 問題がある状態： 必要な計算能力が不足していると、AIエージェントの推論やワークフローが急増した際に脆弱なシステムがダウンし、サービス停止のリスクが生じます。
8. オープンなエコシステムと標準化の優先
エージェンティック エンタープライズのための堅牢なアーキテクチャには、相互運用性が不可欠です。単一のベンダーが自律型AIのすべてを提供することは不可能ですし、将来何が登場するか予測できない中で、現在の必須ツールに縛られるわけにはいきません。 だからこそ、「あらゆるデータ、あらゆるLLM、あらゆるアプリ」に対応できる環境を設計し、特定のプロトコルに固定されないよう、オープンなエコシステムと普遍的な標準規格を頼りにする必要があるのです。
- 理想的な状態： オープンアーキテクチャにより、モデルの標準インターフェースが確立されており、より優れたモデルが登場した際に簡単に交換できます。各種モジュールの統合には、オープンプロトコル（Model Context Protocol、API、標準データ形式）が使用されます。ポータブルなワークフロー定義により、オーケストレーションが特定のプラットフォーム構成に依存しません。さらに、データアクセスパターンがソースを問わず機能するため、AIエージェントが特定のデータベースに限定されることもありません。
- 問題がある状態： AI導入を拡大しようとしたり、自社のニーズに合わせた新しい LLM を試そうとしたりしても、既存ベンダーの計画が自社のビジョンと合わず、身動きが取れなくなる状態です。別のシステムに切り替えるには、40以上のAIエージェントを再構築しなければならないような状況です。
今後の展望について
これらの原則は、いわば制御面です。これらを活用することで、信頼を損なうことなくAIエージェントを拡張できます。また、規制当局や顧客、そして取締役会に対して説明可能な形でインテリジェンスをアクション（行動）へと変えることができます。
これらの原則がなければ、エージェンティック エンタープライズは実現しません。あるのは、断片的な実験と希望的観測だけです。
しかし、これらの原則さえあれば、多くの企業が足踏みしている、段階的かつ範囲を限定し集中的に溝を埋めるという現実的な形で前進することができるようになるのです。
完全なレポート『The Invisible Advantage: Why Your Architecture, Not the Model, Will Define Your Agentic Enterprise』の詳細は、こちら（英語）から参照できます。
詳細情報：
- 世界初のエージェンティック エンタープライズを構築するプロセスの詳細は、こちら（英語）。
- Agentic Work Unitsによる価値測定の詳細は、こちら。
- エージェンティック エンタープライズでの働き方の詳細は、こちら（英語）。
本記事、または公式に言及されている未提供のサービスや機能は現在利用できないものであり、予定通りに、または全く提供されない可能性があります。お客様は、現在利用可能な機能に基づいて購入をご判断くださいますようお願いいたします。
