AI導入支援会社を選ぶ際、提案書の見栄えや事例の数ではなく、実装力とサポート体制を判断できる具体的な基準が必要です。本記事では、提案書の構成と記載内容から支援会社の実務能力を見抜く選定基準を示します。技術検証の設計、ガバナンス統制装置の配置思想、監査設計の社内承認可能性、この3点を軸に、導入後の手戻りを防ぐ判断材料を提供します。

AI導入支援の選定基準で確認すべき3つの軸

AI導入支援会社の選定では、提案書に次の3要素が具体的に記載されているかを確認します。これらは実装段階で必ず直面する課題であり、提案時点で設計されていなければ導入後に手戻りが発生します。

第一に、技術検証の設計です。提案書に「PoC実施」とだけ書かれている場合、検証の目的と終了条件が不明確です。検証すべき項目、判定基準、次フェーズへの移行条件が具体的に示されているかを確認します。検証結果を受けて設計を組み替える想定があるかも重要な判断材料です。

第二に、ガバナンス統制装置の配置思想です。AI導入では技術基盤の前提が変わることがあります。例えば、ライセンスの配布範囲が変更されると、統制装置を置く場所も変える必要があります。提案書に「環境分離」「DLP設定」といった装置名だけが並んでいる場合、前提が変わった際に統制が機能しなくなるリスクがあります。統制の思想(入口を止めず出口で締める等)と、前提が変わったときの再配置方針が示されているかを確認します。

第三に、監査設計の社内承認可能性です。技術的に取得できるログと、社内で承認される監査権限は異なります。提案書に「監査ログ取得」とだけ書かれている場合、どの権限が必要で、その権限が社内承認されるかの検討が抜けている可能性があります。権限の承認が得られなかった場合の代替手段と残存リスクの記録方針が示されているかを確認します。

国内のAI導入では、AI事業者ガイドライン(総務省・経済産業省)が参照されることがあります。ガバナンス体制の構築を検討する際、こうした指針が支援会社の提案にどう反映されているかも確認材料になります。

提案書で見る技術検証設計の具体性

技術検証の設計が具体的かどうかは、提案書の記載内容で判断できます。次の4点が明示されているかを確認します。

まず、検証項目と判定基準です。「性能評価」とだけ書かれている提案書は不十分です。何を何と比較し、どの数値を超えれば合格とするかが書かれている必要があります。例えば、応答精度を評価する場合、評価用データセット、正解率の閾値、不正解時の原因分類方法が示されているかを確認します。

次に、検証の終了条件です。検証がいつまで続くかが不明確だと、導入スケジュール全体が遅延します。提案書に「◯日間で◯項目を検証し、判定基準を満たせば次フェーズへ移行」と書かれているかを確認します。終了条件が曖昧な場合、検証が延々と続き、意思決定ができなくなるリスクがあります。

さらに、検証結果を受けた設計変更の想定です。検証で想定外の結果が出た場合、設計をどう組み替えるかが提案書に書かれているかを確認します。例えば、統制装置を環境に置く前提で設計したが、ライセンス配布範囲の変更で環境を経由しない経路が主流になった場合、統制装置の置き場所を人とデータへ再配置する方針が示されているかが判断材料です。

最後に、検証、決定、手順書の順序です。提案書に「決定事項を先に固めてから検証」と書かれている場合、手戻りが発生しやすい構造です。検証結果を材料として先に出し、それを受けて決定し、最後に手順書を作る順序が守られているかを確認します。

ガバナンス統制の配置思想と再設計対応

ガバナンス統制の設計では、装置の名称ではなく配置思想が重要です。提案書に「環境分離」「コネクタDLP」「公開承認フロー」といった装置名が列挙されているだけでは、前提が変わったときに統制が機能しなくなります。

例えば、エンタープライズ企業におけるCopilot StudioとPower Platformの統制設計では、有償ライセンスの配布範囲が統制装置の配置を決定します。ライセンスが一部にしか配布されていない前提では、広く使われるエージェントをCopilot Studioへ昇格させ、環境分離、コネクタDLP、環境別クレジット割当、公開承認フローという統制装置を必ず通過させる設計が成立します。

しかし、有償ライセンスが対象組織のほぼ全員に配布された結果、全社展開の主経路は「Copilot Studioへ昇格」ではなく「Agent Builderのままギャラリーへ掲載」へ転換します。Agent Builderは環境の概念を持たず、コネクタDLPの対象外であるため、Copilot Studio環境側に置いた統制装置の上を、全社展開の主経路が通らなくなります。

具体的には、開発から本番への段階検証、コネクタDLPによる出口統制、環境別クレジット割当と上限到達時の自動停止、公開承認フロー、この4つが主経路に対して効かなくなります。全社公開のゲートはギャラリー掲載に置き換わりますが、その審査主体と基準は未定義であり、ガバナンス上の空白として残ります。

この場合、統制の思想(入口は止めず出口で締めるガードレール型)は変えず、装置の置き場所を「環境」から「人(セキュリティグループ)とデータ(権限・ラベル)」へ再配置する方針で組み替えます。統制設計はライセンスの配布範囲という前提に依存しており、前提が変われば統制の思想ではなく装置の置き場所を組み替える必要があります。

提案書では、この再配置の方針が具体的に示されているかを確認します。「前提が変わった場合は再設計します」とだけ書かれている提案書は不十分です。どの前提が変わると、どの装置をどこへ移すかが具体的に示されているかが判断基準です。

監査設計における権限承認の現実性

監査設計では、技術的に取得できるログと、社内で承認される監査権限が一致しないことがあります。提案書に「監査ログを取得し分析します」とだけ書かれている場合、権限承認の壁を想定していない可能性があります。

例えば、監査ログの取得をPurview前提で設計した場合、監査ロールの付与が社内承認されないことがあります。メール等まで閲覧範囲が及ぶことが理由です。この場合、監査目的の大半をエージェント管理基盤へ載せ替える代替手段が必要ですが、「誰が誰に共有したか」の操作記録だけは代替手段がなく、残存リスクとして記録する必要があります。

監査設計は「技術的に取得できるか」ではなく「その権限が社内で承認されるか」で決まります。提案書では、次の3点が示されているかを確認します。第一に、取得を想定するログと、そのために必要な権限の一覧です。第二に、その権限が社内承認されない場合の代替手段です。第三に、代替手段でも対応できない残存リスクの記録方針です。

権限承認の壁を想定していない提案書は、導入後に監査設計を全面的に作り直すことになります。提案時点で権限承認の現実性まで検討されているかが、実装力の判断材料です。

削除基準の設計と低頻度稼働への対応

AI導入後の運用では、不要なエージェントの削除基準を設ける必要があります。しかし、一律の未使用期間基準は成立しないことがあります。

例えば、90日間未使用のエージェントを一律で削除する基準を設けた場合、半年に1回など低頻度で稼働するエージェントが誤って削除されるリスクがあります。この場合、未使用期間による一律削除基準は撤回し、別の判定方法が必要になります。

提案書では、削除基準の設計に次の2点が含まれているかを確認します。第一に、未使用期間以外の判定要素です。例えば、エージェントの作成者、最終更新日、共有先の人数、業務プロセスへの組み込み有無などです。第二に、削除前の確認プロセスです。一律削除ではなく、作成者への確認や業務部門への照会を経てから削除する手順が示されているかを確認します。

削除基準の設計が甘いと、必要なエージェントを誤削除し、業務が止まるリスクがあります。提案書に削除基準の検討が含まれているかも、サポート体制の判断材料です。

提案書のチェックリストと選定手順

AI導入支援会社の選定では、提案書を次のチェックリストで評価します。

  • 技術検証の設計: 検証項目、判定基準、終了条件、設計変更の想定が具体的に示されているか
  • ガバナンス統制の配置思想: 統制装置の名称だけでなく、前提が変わったときの再配置方針が示されているか
  • 監査設計の権限承認: 必要な権限、承認されない場合の代替手段、残存リスクの記録方針が示されているか
  • 削除基準の設計: 未使用期間以外の判定要素と削除前の確認プロセスが示されているか
  • 検証、決定、手順書の順序: 検証結果を材料として先に出し、決定を急がせない構造になっているか

これらの項目が提案書に具体的に記載されている支援会社は、導入後の手戻りを防ぐ設計能力を持っています。逆に、抽象的な記述や装置名の列挙にとどまる提案書は、実装段階で設計の作り直しが発生するリスクが高いと判断できます。

選定手順は次の通りです。まず、提案書を上記チェックリストで評価し、具体性の高い支援会社を2〜3社に絞ります。次に、絞り込んだ支援会社に対し、自社の技術環境とライセンス配布状況を伝え、統制装置の再配置案を追加で提出させます。最後に、再配置案の具体性と、検証、決定、手順書の順序を守る姿勢を比較し、最終決定します。

この手順により、提案書の見栄えではなく、実装力とサポート体制で支援会社を選定できます。