7月17日、TechTargetが「AI agents in enterprise software: Questions to ask vendors」と題した記事を公開した。企業がAIエージェントをベンダーから調達する際に問うべき評価フレームワークについて詳しく紹介している。
IDCの予測によれば、2029年までに世界で稼働するAIエージェントの数は10億を超える——2025年比で約40倍という規模だ。MicrosoftのSatya Nadella CEOが「同期型アシスタントから非同期の自律的な共同作業者へ」と表現したように、主要ベンダーはAIをもはや生産性ツールではなく、自律的な業務実行システムとして位置づけている。SalesforceはAIエージェントを「デジタル労働力」と呼び、ServiceNowはエンドツーエンドの業務インパクトを前面に押し出す。
問題は、これに対して既存の調達プロセスが対応しきれていない点だ。従来のRFP（提案依頼書）は、決まったワークフローと明確な動作範囲を前提として設計されている。エージェントが実行する処理はあらかじめ人間が定義したルールに従うものとされており、ガバナンスの仕組みもその前提に基づいて作られている。しかし自律的に判断し、複数の企業システムをまたいで行動するAIエージェントは、その前提を根底から覆す。エージェントは状況に応じて自ら次のアクションを決定し、ERPやCRM、HRといった複数システムを横断して処理を実行する。このため、従来のRFPが想定していなかったガバナンス・説明責任・リスク管理の観点から、全く異なる評価軸が必要になる。
機能比較だけで導入を決めると何が起きるか。エージェントが無断で顧客に約束をする、財務トランザクションを実行する、機密情報を漏洩する、採用判断にバイアスを持ち込むといった事態が起こりうると、元記事はリスクとして指摘している。複数システムにまたがって動作するため、1つのエージェントの設定ミスがドミノ式に連鎖障害を引き起こす可能性もある。
ベンダーに問うべき12の評価軸
記事では調達・更新・プラットフォーム拡張の局面で確認すべき評価軸を12項目に整理している。紙幅の都合上、エンジニアリング・ガバナンス観点で特に重要な6項目を以下に取り上げる（残る項目についてはベンダーロックイン対策、規制変化への適応能力、インテグレーションの柔軟性といったテーマが扱われており、詳細は元記事を参照されたい）。
1. 権限・決定境界の設計が甘いと致命的になる
最初に確認すべきは「エージェントが何を自律判断でき、何は人間の承認が必要か」の境界設計だ。
- ERPでは：人間の承認なしに実行できる財務トランザクションの上限と、それを制御するポリシーは何か
- HRでは：採用・解雇のどの判断がエージェント単独で実行可能か
- CRMでは：割引・クレジット・契約変更などの顧客向けアクションをエージェントが単独で行えるか
ベンダーには**最小権限の原則（Principle of Least Privilege）** の実装、ロールベースアクセス制御（RBAC）によるきめ細かい権限設定、特権昇格に対するガードレールを具体的に示させる必要がある。「設定可能です」という回答では不十分で、実際の制御粒度を確認すること。
2. マルチテナント環境のデータ分離
クラウドSaaSの多くはマルチテナント構成——複数組織が同一インフラを共有する——で動いている。AIエージェントがその上で動く場合、テナント間のデータ漏洩リスクは無視できない。
確認すべき点：
- 同一AIインフラを共有する他テナントのデータ・モデル・ツールにアクセスできない仕組みはどうなっているか
- 認可されたドキュメントリポジトリ・ナレッジベース・名前空間の範囲内でのみ検索できるよう、メタデータとパーミッションベースのフィルタリングが適用されているか
3. 透明性・説明可能性・監査ログ
規制産業——金融・医療・製造など——では特に重要な観点だ。これらの業界ではAIの判断根拠を監督当局に説明できなければ、そもそも導入自体が認められないケースもある。
説明可能性（Explainability） については：
- 意思決定の透明度がどのレベルで提供されるか——高レベルのサマリーか、中間ステップか、どの入力が判断に影響したかを示す完全なデータリネージか
- 説明はリアルタイムで生成されるか、それとも監査時の事後生成のみか
- エンドユーザー、コンプライアンス担当、技術チームなど対象者別にカスタマイズできるか
「解釈可能なAI」という漠然とした表現だけで具体的な実装説明がないベンダーは要注意だ。
監査ログ（Auditability） については：
- ログが完全・改ざん不能・検知可能な形で保持されているか
- 適用される規制要件に沿った保持期間が確保されているか
- ハルシネーション（AIが事実と異なる内容を生成する現象）や挙動ドリフトを防ぐ仕組みはあるか
4. 障害時の「キルスイッチ」と復旧プロセス
どれだけ設計が優れていても、AIシステムは予期しない出力を生む。問うべきは：
- 不正なトランザクションを実行し始めたERPエージェントをどれだけ早く無効化できるか
- 個別エージェントを、他のエージェントやシステム全体に影響を与えずに停止できるか
- 問題のある出力を特定の意思決定ポイントまで遡ってトレースできるか
この「シャットダウン機能」の有無と粒度は、デモ段階では見落とされやすいが、本番運用では極めて重要だ。
5. ベンダーの性能主張を鵜呑みにしない
ベンダーデモは理想的シナリオで実施される。記事は以下の確認を推奨している：
- 性能指標が「タスク完了数」ではなく実際のビジネス成果に紐づいているか
- ベストケース・平均・ワーストケースそれぞれのタスク成功率は何%か
- ハルシネーション、偽陽性、偽陰性の発生頻度と主な障害モードは何か
性能データは本番環境のものを要求し、事前に定義した成功指標を持つパイロットプログラムで検証することを記事は強く推奨している。
6. 価格・ライセンス・消費ベースコスト
AIエージェントの料金モデルは複雑だ。タスク数課金・成果課金・フラットサブスクリプション・連携システム数課金など、ベンダーによって異なる。大規模展開にコミットする前に、コストのスケール方法と予測可能性を具体的に確認しておく必要がある。
調達判断の前に
記事が強調するのは、AIエージェントの評価において技術仕様や機能比較は出発点に過ぎないという点だ。ガバナンス、セキュリティ、説明責任、運用境界、長期コストがそれと同等以上の重みを持つ。
規制産業ではコンプライアンス対応は交渉の余地がない必須要件であり、将来の規制変化への適応能力も評価対象に含めるべきとされている。また、ベンダーロックインを避けるため、標準APIやデータエクスポート形式のサポート、契約終了時のデータ・ワークフロー・設定の移行可能性も確認が必要だ。こうした非機能要件の確認を怠ったまま大規模展開に踏み切ることが、導入後に深刻なガバナンス上の問題を招く主因になりうる。調達の前段階で評価軸を整備しておくことが、長期的なリスク低減につながる。
詳細はAI agents in enterprise software: Questions to ask vendorsを参照していただきたい。
