【ITニュース解説】Test the denied path before connecting an AI agent to SAP

AIエージェントと基幹システムであるSAPの連携は、企業の業務効率を飛躍的に向上させる可能性を秘めている。しかし、このような強力なシステム連携を実現する際には、「接続ができた」という成功体験だけでなく、その「接続が安全であるか」という点を徹底的に検証することが極めて重要となる。単にデータが取得できた、操作が実行できたというだけでは不十分で、意図しない情報漏洩や不正な操作を防ぐための厳格なチェックが必要なのだ。

システムの連携テストを行う際、多くの人はまず、データが正しく取得されるか、操作が意図通りに実行されるかといった「成功するケース」の確認に焦点を当てがちだ。しかし、真に安全なシステムを構築するためには、むしろ「拒否されるべきケース」が確実に拒否されるかどうかの検証が不可欠となる。例えば、あるユーザーが本来アクセス権限を持たない情報にアクセスしようとした場合、システムがそれを正しくブロックしなければ、重大なセキュリティインシデントにつながる可能性がある。

この「拒否されるケース」を体系的にテストすることは、AIエージェントとSAP間の接続が、特定のユーザー、組織、環境に対して適切にアクセス制御を行えるかを証明するために必須となるプロセスだ。具体的なテストシナリオとしては、以下のような項目が考えられる。

まず、ユーザーの組織スコープ外のデータ要求への対応だ。例えば、ある部署のユーザーが自分の権限範囲外にある他部署の情報をAIエージェント経由で要求した場合、システムはその要求を正しく拒否するか、あるいは許可された範囲内に制限しなければならない。この際、システムがどのような判断を下し、どのような記録を残したかを検証する。

次に、設定された許可リストにないターゲットシステムへの要求だ。AIエージェントが、本来接続を許可されていない別のSAPシステムやデータベースへのアクセスを試みた場合、システムはその接続を試みる前に要求を拒否する必要がある。これにより、不審な接続が下流システムに到達するのを防ぎ、拒否イベントがログに記録されるかを確認する。

さらに、期限切れのセッションの再利用も重要なテスト項目となる。ユーザーの認証情報が無効になった後もAIエージェントが古いセッション情報を使って操作を継続しようとした場合、システムはそれを拒否し、認証セッションが正しく検証されたことを確認する必要がある。

また、ユーザーインターフェース上からは見えない隠された操作を直接呼び出すケースも考慮が必要だ。たとえAIエージェントが、通常の手段では選択できない操作を直接実行しようとしたとしても、サーバー側でその操作に対する認可が改めてチェックされ、適切な権限がなければ拒否されなければならない。インターフェース上から見えないからといって、無条件に許可されることはあってはならない。

加えて、非常に広範な日付範囲や大量の結果セットを要求するケースもテストすべきだ。AIエージェントが、システムの処理能力を超えたり、不審に思われるほど大量のデータを要求したりした場合、システムはそれを拒否するか、あるいは事前に定められた制限を適用する必要がある。これは、システムへの過負荷攻撃や、無制限なデータ取得を防ぐ上で非常に重要だ。

そして、取得されたビジネスコンテンツ内に指示が含まれていた場合の対応も確認する。例えば、SAPから取得したデータの中に、何らかのスクリプトや実行可能な命令が含まれていたとしても、AIエージェントはそれをデータとしてのみ扱い、実行可能な指示として扱ってはいけない。これにより、意図しないコード実行やセキュリティ上の脆弱性を防ぐことができる。

これらのテストで重要なのは、「便利なインターフェース」と「強制された境界」の違いを明確に理解することだ。ユーザーからある操作が見えないようにすることは、単に間違いを減らす効果があるだけであり、その操作が直接呼び出された場合に認証や認可を自動的に与えるものではない。すべての呼び出しに対して、サーバー側で認可の判断が下されるべきなのだ。

データ変更（書き込み）を伴う操作については、さらに慎重なテストが求められる。読み取り専用の検証段階では、無理に書き込み操作を組み込む必要はない。しかし、実際に書き込みが必要なユースケースでは、「コンテキストの取得」「変更案の準備」「実行」という段階を明確に分け、それぞれをテストすることが望ましい。承認プロセスを含む場合、承認された変更内容が、その後で勝手に変更された場合に承認が無効になるか、あるいは承認なしでの操作が拒否されるか、期限切れの承認が機能しないかなどを検証する必要がある。また、ネットワークのタイムアウトなどにより、AIエージェントがSAPからの応答を受け取れなかった場合でも、SAP側ではすでに処理が完了している可能性があるため、再試行の前には必ず、重複防止メカニズムを利用して、元の操作がすでに実行されていないかを確認する必要がある。HTTPエラーが返されたからといって、何も起こらなかったと安易に判断してはならない。

AIエージェント側の認可システム（MCP認可）を設計したとしても、それはSAPシステム自体のセキュリティを完全に置き換えるものではない。SAPには独自のロール、認可オブジェクト、アプリケーションレベルのチェックが存在するため、これらも連携テストの一環として必ず検証しなければならない。可能であれば、AIエージェントは「実際のユーザー」としてSAPにアクセスし、そのユーザーの権限で操作が実行されるかを確認する。もし技術的なサービスアカウントを使用する必要がある場合は、そのアカウントに与える権限も、AIエージェント側のポリシーも厳しく制限することが重要だ。許可されたテストではSAP内部で実際にどのような権限で操作が実行されたかを確認し、拒否されたテストでは、拒否の判断がAIエージェント側のアプリケーション層でなされたのか、それともSAPシステム内部でなされたのかを明確に区別する必要がある。両方の層で拒否されることは、多層防御の観点から良い証拠となり得るが、それぞれの層が異なる制御メカニズムを反映しているため、その違いを理解しておくべきだ。

テスト結果の証拠を保管する際には、テストケース、期待される結果、実際の結果、そして関連するログの参照情報など、判断の再構築に必要な最小限の情報を記録するように心がける。ユーザーの完全なプロンプトや認証情報、取得されたビジネス文書のコピーなど、機密性の高い情報を不必要に記録することは避けるべきだ。記録された証拠自体が、新たな機密データの貯蔵庫となり、情報漏洩のリスクを抱える可能性があるため、マスキングやデータ保持のポリシーもテストの一部として検証することが重要となる。

最終的に、システム連携の安全性を証明するためにチームが直面する最も重要な問いは、「成功した応答を明確に示すのと同じくらい、正しい拒否を明確に示すことができるか」という点に集約される。安全なシステムとは、正しい操作を許可するだけでなく、不正な操作を確実に阻止できるシステムなのだ。このような多層的かつ網羅的なテストを通じて、AIエージェントとSAP間の連携は真に信頼できるものとなる。