AIエージェントにアイデンティティがない場合、それが問題となる

過去2年間、私たちはAIエージェントの能力向上に注力してきました。エージェントはユーザーに代わって、データベースへのクエリ実行、ドキュメントの要約、ワークフローのルーティング、トランザクションの開始を行うことができます。中には、実に素晴らしい能力を備えたものもあります。

しかし、より困難な課題は、ほとんどの組織がまだ解決していない「アカウンタビリティの確保」です。

エージェントは自律的に行動できます。しかし、アカウンタビリティはまったく別の問題です。人間の従業員が行動を起こす場合、そこにはアイデンティティの連鎖が伴います。一方、エージェントが行動を起こす場合、多くの場合アイデンティティは伴いません。エージェントがデモ段階から本番環境へと移行するにつれ、このギャップがガバナンス上の問題となります。

これが、エージェントのアイデンティティ問題です。エージェントは、定義された権限、定義されたスコープ、実行したことの永続的な記録など、検証可能な独自のアイデンティティを持つべきです。これらがなければ、何が起きたのか、誰が承認したのか、そして許可された境界内に収まっていたのかに答えることはできません。何か問題が起きた瞬間、それは重大な責任問題になります。  

しかし、ほとんどのエージェントはアイデンティティを持っていません。そして、このギャップはすでに、世界で最も高度なAIプログラムのいくつかにおいて、導入を遅らせる要因となっています。

すべてのコンプライアンスチームが答えるべき質問

規制の厳しい業界において、AIは監査の複雑さを軽減するものではありません。むしろ、複雑さを増幅させます。エージェントがデータベースにクエリを実行したり、レコメンデーションを生成したり、アクションを開始したりした場合、そして6か月後に何か問題が起きたら、チームは次の質問に答える必要があります。 

• 誰がそのエージェントを作成したのか。 

• どのような権限を、どの程度の期間持っていたのか。 

• どのデータにアクセスしたのか。 

• また、エージェントが派生的なインサイト（例えば、予測、要約、誰も明示的に承認していない出力など）を生成した場合、その所有者は誰になるのか。

ローン審査エージェントを想像してみてください。このエージェントは、信用データにクエリを実行し、リスクにフラグを立て、承認のレコメンデーションを生成します。1年後、借り手がその結果に異議を唱えました。コンプライアンスチームは、エージェントがどのデータにアクセスしたのか、誰の権限でアクセスしたのか、そしてその出力が承認されたスコープ内に収まっていたのかを、正確に再構築する必要があります。その記録が存在しない場合、単にリスクにさらされるだけではありません。まったくのゼロから対応を始めることになります。

これらは当然の疑問のように思えます。問題は、ほとんどのアイデンティティインフラストラクチャが、こうした質問に答えるように設計されていないことです。

見た目以上に困難な理由

従来のアイデンティティシステムは、固定された役割と定義されたアクセスのために構築されていました。エージェントは、そのモデルには適合しません。

エージェントは単一のタスクのために起動し、4つのデータソースからデータを取得して、正午までには消えてしまう可能性があります。各データソースには、個別に適切なアクセス制御が設定されていたかもしれません。しかし、組み合わされた出力（派生的なインサイト）は、誰も承認していない領域に踏み込む可能性があります。エージェントは設計どおりに動いただけです。問題は、誰もその境界を定義していなかったことです。

そして、エージェントが消滅した後でも、記録は残っていなければなりません。 

毎晩深夜に実行される給与計算スクリプトのような、従来のスケジュールされたバッチ処理について考えてみてください。名前、所有者、ひと揃いの監査証跡があります。では、3時間実行されてレコメンデーションを返した動的なエージェントはどうでしょうか。意図的なアーキテクチャがなければ、ガバナンスの痕跡はほとんど残りません。

エージェントのアイデンティティ問題の解決は、ガバナンスをアーキテクチャに組み込むことから始まる

ガバナンスは後付けできません。最初からアーキテクチャに組み込まれている必要があります。

実際には次のようになります。

• ランタイム時ではなく、作成時にアイデンティティを確立：エージェントの権限、データアクセス、操作範囲は、呼び出したユーザーから推測するのではなく、実行前に定義する必要があります。有効期限付きの明示的な権限には、何に、どのくらいの期間、誰の代理としてアクセスできるかが含まれます。たとえば、財務担当VPによって呼び出されたエージェントは、VPのアクセス権を継承したコピーではなく、独自にスコープが設定されたアクセス権を取得します。
• 入力だけでなく、出力にもガバナンスを適用：ソースデータのアクセス制御だけでは不十分です。エージェントがシステム間でデータを組み合わせる場合、その出力結果は、個々のソース単独では越えることのない境界を越える可能性があります。ポリシーは、インサイトを生成したデータだけでなく、そこから導き出されたインサイトにも適用される必要があります。人事データと財務データへの個別のアクセスが許可されているエージェントであっても、それらを組み合わせることは許可されていない場合があります。
• エージェントの存続期間を超えるライフサイクルトラッキング：短命のエージェントであっても、誰が作成し、何にアクセスし、何を生成し、誰が承認したかについての永続的な記録が必要です。監査可能性は、エージェントが実行中であるかどうかに依存してはなりません。1時間実行されてレコメンデーションを返した医療用エージェントにも、永続的な記録が必要です。
• 支えではなく早期警戒としての、人間による監視：人間がエージェントのすべてのやり取りを監視することが目標ではありません。それでは本末転倒です。適切なモデルとは、定期的かつ体系的なレビューと、ドリフトが深刻化する前にそれを検知する監査機能です。財務監査のようなものです。すべてのトランザクションを対象にするのではなく、パターンが見える程度に十分な範囲で行います。

これらの原則が設計段階からSnowflakeに組み込まれており、Snowflake独自のAIエージェント開発や、お客様が構築できるエージェントの指針となっているのはこのためです。 

Snowflake独自のGo-To-Market AIアシスタントを構築した際、私たちは、関連するすべての営業知識、カスタマーストーリー、アカウントのインサイトをチームがすぐに利用できるようにしたいと考えました。これを機能させるには、2つのことを正しく行う必要がありました。提供される情報が信頼できるものであることを保証することと、エージェントが適切な情報を、適切な人に、適切なタイミングでのみ公開するように制御を設けることです。

その結果、私たちはこれらを機能としてではなく、設計上の制約として設定することから始めました。

• ロールベースのデータアクセス
• 検証済みの回答と推測された回答を区別する認定済みクエリ
• 作成時に定義されたスコープ
• 複数のソースにわたってデータアクセスを適用する論理データモデル

その結果、現在このエージェントは6,000人以上の従業員を支援し、週に35,000件以上の質問に回答しています。これは、事後の包括的な監査可能性を備え、自律的に動作するとチームが信頼しているエージェントです。

大規模な環境において、私たちは同じようにお客様をサポートしています。TS Imagine、Fanatics、United Rentalsなどの企業のお客様は皆、ビジネスを加速させるためにSnowflake上でエージェントを構築しています。 

たとえば、年間750億ドル以上のトランザクションを処理するグローバル決済プラットフォームであるTipaltiは、Snowflake AIデータクラウドを使用して、チーム全体でLLMを活用したデータ探索を民主化しています。このプラットフォームにより、主要なビジネス部門は財務に関するインサイトを迅速に得て、重要な意思決定に迅速に対応できるようになります。これにより、時間とコストを節約しながら、業務に最も近い担当者が自信を持って行動するために必要な情報を提供できます。

エージェントのアイデンティティ問題の解決は、エンタープライズAI導入の切り札である

エージェントのアイデンティティ解決は、単にリスクを軽減するだけではありません。導入を停滞させている障壁を取り除けます。

現在、未知の技術への恐怖が、企業にすべてのエージェントを監視する人間を割り当てさせたり、真のエージェントの代わりにアプリを構築させたり、あるいはこのカテゴリをまったく活用させなかったりする原因となっています。それはコストがかかります。そして、それでは本末転倒です。

エージェントが誰であるか、何をすることが許可されているか、そして実際に何をしたかに答えられるようになれば、その躊躇は解消されます。エージェントは、人間と同じように信頼を獲得します。意図によってではありません。証拠によってです。

もはや機能が制約となることはありません。信頼できるかどうかが制約となるのです。