Connect with us

AIエージェントを統治するために必要なアーキテクチャのシフト

ソートリーダー

AIエージェントを統治するために必要なアーキテクチャのシフト

mm
A photorealistic widescreen image of a technician viewed from behind, seated at a dark command center with multiple monitors. A large glass wall in front of him displays a complex, glowing architectural blueprint made of blue and green light. The hologram features intricate pathways, interconnected nodes, and two small silhouettes of figures standing together, representing a human and an AI

AIは、単にテキストを生成するチャットボットではなくなりました。企業環境では、AIエージェントは、機密データの取得、ワークフローのトリガー、ツールの呼び出し、システム全体でのアクティビティのログ記録などのアクションを実行しています。自律性は、統治に関する議論全体を変えます。人間のユーザーと従来のアプリケーション向けに最初に設計されたコントロールと手順は、実行時にはマルチステップのアクションを実行できるソフトウェアを統治するために設計されていませんでした。

リスクは理論的なものではありません。可視性、 アクセス制御、監査可能性の小さなギャップは、すぐに複合し、検出が困難で、さらに逆転が困難なランタイムの障害になります。

この新しい時代に追いつくには、AIエージェントの統治はさらに多くのポリシードキュメントを追加することではできない。統治は、デザインによって実現する必要があります。つまり、コントロールはコントロールプレーンに埋め込まれ、実行時に継続的に適用されるアーキテクチャアプローチです。エージェントがデジタル同僚のように行動するのであれば、人間と同じ企業のガイドレールを継承する必要があります。さらに、実行時のより強力な監視が必要です。

なぜ統治が収束の時代に壊れるのか

企業アーキテクチャは収束の時代に入りました。データとワークロードは、複数のクラウド、プライベートデータセンター、エッジ環境にわたっています。

並行システムでプラットフォームを実行している組織があります。なぜなら、同時に複数のプロセスを管理する必要があるからです。これには、別個のアイデンティティシステム、ログパイプライン、カタログ、承認済みプロセスが含まれます。結果は、ツールやクラウド環境が増えるたびに統合オーバーヘッドが増加する「フランケンシュタインプラットフォーム」になります。実際、この断片化は日常の現実に現れています。

最近の調査によると、47%の回答者は、アクセスの複雑な要件とプロセス、44%の回答者はデータの在り処に関する可視性の限界を、データを効果的に使用するための障害として挙げています。

これは、エージェントがシステム間のシームを暴露する場所です。

ビジネス上の質問に答えるために、エージェントはオンプレミスのERPシステム、クラウドのCRM、別のクラウドの運用テレメトリ、コラボレーションスイートのドキュメントからデータを取得する必要があるかもしれません。組織が各場所でポリシーを異なる方法で適用している場合、エージェントは失敗するか、説明できない方法で、または制御できない方法で成功する可能性があります。

これは、企業のリーダーが注意を払うべき瞬間です。エージェントは、環境全体で一貫性と実行時の説明責任を要求する、より高い基準を強制しています。

この理由により、統治は、規制当局やセキュリティ機関によってスポットライトにさらされています。例としては、NIST AIリスク管理フレームワークがあります。これは、ビルド時だけでなく、AIライフサイクル全体でリスク管理を強調しています。つまり、コンプライアンスと信頼は、1回限りのチェックリストではなく、運用上の責任です。

ポリシーからプラットフォームへ

統治はデザインによって実現することを意味します。つまり、統治はワークロードに従うのではなく、各シロに再実装されるのではなく、統治が行われるのです。
実践では、これは3つの構成要素に依存しています:

  • 統一されたコントロールプレーン

アイデンティティ、 アクセス、ポリシー、カタログ、エンタイトルメントをクラウドとデータセンター全体で定義および適用する1つの場所。

目標は、ポリシーを1回書き込んで、データとモデルが実行されるどこにでも適用することです。システムごとにコントロールシステムを再構築するのではなく、エージェントの動作のズレを防ぐことができます。エージェントが1つの環境では安全に動作するが、別の環境では危険に動作するのを防ぐことができます。

実用的テストはシンプルです。ユーザーが列にアクセスできない場合、ユーザーの代理で動作するエージェントもアクセスできないことを確認します。これにより、書き込まれたポリシーがコントロールプレーン全体で適用されているかどうかがわかります。

  • オープン標準に基づくデータファブリック

エージェントは、動作するためにコンテキストが必要です。コンテキストが異なる構造に分散し、異なるチームによって所有されている場合、データファブリックはセマンティクスとアクセスパターンを標準化するのに役立ちます。エージェントは、各データセットごとに新しいルールセットを学習する必要がなくなります。

Apache Icebergのようなオープンテーブル形式は、これをサポートします。複数のエンジンが、コピーせずに同じ統治データを共有できるようになるからです。これは重要です。なぜなら、データの複製は、統治が通常失敗する場所だからです。チームが「エージェントが必要とするものだけ」をコピーし始めると、新しい、統治されていない環境を作成したことになります。

エージェントが、新しいアクセスギャップを導入せずにデータセット全体で動作できる場合、統治は意図したとおりに機能しています。

  • リアルタイムの観察可能性と系譜

エージェントは、実行時に何をしているかがわかる場合にのみ、統治できます。

ここでの観察可能性は、「nice-to-have」ではなく、実行時コントロールとインシデントレスポンスの基盤です。

具体的には、エージェントのアクションに対するエンドツーエンドの証明が必要です。エージェントは、どのデータにアクセスしたか、どのツールを呼び出したかを証明できなければなりません。そこから、系譜は出力と入力を接続し、チームが意思決定を監査し、必要に応じて障害をトラブルシューティングできるようにします。つまり、全体的なコンプライアンスを証明します。

エージェントを「デジタル同僚」として扱う

最も役立つ精神モデルは、エージェントをデジタル同僚として扱うことです。

これを分解するための比較は次のとおりです。従業員は、入場を許可される建物や部屋に対してアクセスバッジを持っていますが、エージェントも制限付きでアクセスを許可されます。統治は、エージェントが何を明らかにすることが許可されているかについて、状況に応じて認識するようにします。

サポートエージェントを考えてみましょう。問題を解決するために、以前のサポートケースにアクセスする必要があるかもしれませんが、別の顧客のプライベート詳細を漏らすことはできません。言い換えると、エージェントは制限付きの知識を使用して推論できますが、開示の境界を強制する必要があります。これは、従来の「プロンプトの書き方」の問題ではなく、アイデンティティと実行時の適用の問題です。

2026年に何が変わるのか:エージェントが実験から本番へ

2026年は、実験が終了し、エージェントが本番の座に就く年です。

このシフトは、企業が2つの速度で運営することを強制します。1つはイノベーションスピードで、新しいモデル、ツール、エージェントのワークフローをテストして競争上の優位性を得るためにチームが取り組む速度です。もう1つは、セキュアスピードで、システムがコンプライアンスと運用要件を満たす必要があり、厳格なアクセス制御と盲点が含まれる場合があります。

統治のためのアーキテクチャがなければ、これら2つの速度は衝突します。

エージェントを統治する前に展開すると、パッチワークのコントロールと運用上の障害が発生します。逆に、セキュリティがすべてをブロックし、イノベーションがガバナンスを損なう影のITに移行します。

目標は、速度を選択することではありません。両方をサポートするアーキテクチャを構築することです。

エージェントの実行時統治のための実用的なチェックリスト

  • エージェントを構築またはスケーリングしている場合、統治が真正にアーキテクチャであるかどうかを明らかにするために、次の質問を自分に問いかけることが重要です。エージェントが答えを出すために、またはアクションを実行するためにアクセスしたデータを、エンドツーエンドで説明できますか?
  • アクセス決定は、ハイブリッド環境全体で一貫していますか? それともプラットフォームによって異なりますか?
  • エージェントのアクション、ツールの呼び出し、ポリシーのチェック、人間のエスカレーションに関するテレメトリがありますか?
  • エージェントが予期せずに動作した場合、実行時にエージェントをスロットル、停止、または隔離できますか?
  • 規制上の義務とリスクアプティチュードに基づいて、展開後のモニタリング計画がありますか?

これらに答えることができない場合、エージェントの展開を、発生する運用上的インシデントとして扱ってください。

統治のシフトはアーキテクチャ的でなければならない

エージェントは、企業運用の標準的な追加要素になるでしょう。

質問は、エージェントが信頼できる企業運用の一部になるかどうかです。

エージェントが人間やミッションクリティカルなソフトウェアと同じレベルの自信で統治されない場合、結果は現実的になります。データ漏洩、コンプライアンスの失敗、運用停止、AIプログラムへの信頼の喪失が見られるようになります。

リーダーは、エージェントの統治を文書化の演習として扱うのをやめる必要があります。プラットフォームの機能が拡大するにつれて、エージェントの統治は他の役割の監視を担うべきものです。これは、コントロールをコントロールプレーンに埋め込み、行動を観察可能にし、意思決定を監査可能にすることを意味します。そして、拡大します。

これが、エージェントが企業を壊すことなく迅速に動作する方法です。

Sergio GagoはClouderaのCTOであり、AI/ML、量子コンピューティング、データ駆動型アーキテクチャにおける20年以上の経験を持っています。以前はMoody’s AnalyticsのAI/ML & Quantumのマネージングディレクターであり、Rakuten、Qapacity、ZinioでのCTO役職も経験しています。Sergioは、信頼できるデータインフラストラクチャの強力な擁護者であり、AIが2030年までに企業のオペレーティングシステムに進化することを信じています。