AI ツールの承認プロセス：アプリ、接続、エージェントの操作

AI ツールの承認プロセスで決めること

AI ツールの承認プロセスとは、業務でどの AI ツールを、どのデータで、どのような条件で使ってよいかを組織が決める仕組みです。多くのプロセスは、チャットアシスタント、会議の議事録作成ツール、コーディングアシスタントなど、アプリそのものの承認から始まります。

エージェントが加わると、決めるべきことがさらに 2 つ増えます。現在、多くの AI ツールは組み込みのコネクターや Model Context Protocol（MCP）を通じて社内システムに接続しており、中には、メッセージの送信、レコードの更新、変更のマージなど、そのシステム内で操作を実行できるものもあります。アプリを承認しても、どのシステムにアクセスしてよいか、どの操作に人によるレビューが必要かまでは決まりません。

そのため、役に立つプロセスでは、3 つの対象をそれぞれ適切な粒度で承認します。

申請しやすくする

人は手に入れやすいツールを使います。正規のルートが遅かったりわかりにくかったりすると、各自でツールを探すようになり、そこからシャドーAI が生まれます。誰も読まない厳格なポリシーよりも、短い申請フォーム、公開された承認済みツールの一覧、明確な対応期間の目安のほうが効果的です。

申請のやり取りが何度も往復しないよう、レビュー担当者が必要とする情報は最初に提出してもらいましょう。

• 業務上の目的と、ツールを使うチーム。
• 扱うデータ（既存の分類レベルで記載）。
• 接続が必要な社内システムと、そのシステム内で何かを変更する必要があるかどうか。
• 承認後にツールを担当する人。
• ベンダー、プラン、セキュリティとデータ利用に関する規約へのリンク。

リスクに見合ったレビューを行う

すべての申請に同じレビューが必要なわけではありません。区分を設ければ、リスクの低いツールはすばやく通し、詳しいレビューは機密データを扱うツールや操作を実行するツールに絞れます。

区分は製品単位ではなく、用途単位で決めます。同じアシスタントでも、文章作成の補助として使うならリスクは低く、誰かに代わってメールを送信できるようになればリスクは高くなります。以下の区分は一例です。自社のデータ分類や遵守すべき義務に合わせて調整してください。

AI ツールで重要な点をレビューする

通常のベンダーレビューは引き続き必要です。セキュリティ対策、自社の ID プロバイダーを使ったサインイン、監査ログ、契約条件などです。AI ツールでは、これに加えてデータに関する確認事項があります。ベンダーが自社のデータをモデルの学習に使うかどうか、プロンプトや出力がどのくらいの期間保存されるか、そうした条件が無料プランとビジネス向けプランで異なるかを確認しましょう。

社内システムに接続するツールでは、接続ごとに個別の判断としてレビューします。どのシステムに、誰の認証情報で、どのスコープで、どのデータにアクセスするのかを確認します。広いスコープで認可された接続は、ツールがどの用途で承認されたかにかかわらず、そのスコープで許されるすべてにアクセスできてしまいます。

操作を実行するツールについては、どの操作を単独で実行してよいかを決めます。OWASP は、AI システムに必要以上の機能、権限、自律性を与えることを過剰なエージェンシー（Excessive Agency）と呼び、影響の大きい操作に人の承認を求めることを緩和策の一つに挙げています。

より広い枠組みが必要な場合、現在改訂中の NIST の AI リスクマネジメントフレームワークでは、この取り組みをリスクのガバナンス、マッピング、測定、管理という観点で整理しています。

範囲を具体的に決め、期限を設けて承認する

承認が最も役立つのは、何を承認したのかが正確にわかる場合です。つまり、このツールを、このチームのこの用途に、この種類のデータで、これらのシステムに接続して、これらの操作を許可して使う、という形です。その範囲外のものは新しい申請として扱います。

リスクを下げられる場合は条件を付けます。たとえば、ビジネス向けプランに限る、シングルサインオンを必須にする、顧客データは扱わない、試験導入の期間中は特定の操作をレビューする、といった条件です。承認ごとに担当者と見直し日を決めておけば、不要になったツールや変化したツールが改めて判断の対象になります。

決定を設定に反映する

スプレッドシートの中だけにある決定では、誰も止められません。設定で適用できるものは適用しましょう。承認されたグループに対してシングルサインオン経由でツールを有効にし、承認済みの接続とスコープだけを設定し、承認済みリストを利用者が探す場所に公開します。

MCP 経由で社内システムに接続するエージェントについては、ゲートウェイを使えば、決定をすべてのリクエストに適用されるルールに変換できます。誰が接続を使えるか、どのツールとデータを利用できるか、どの変更操作にレビューが必要かといったルールです。ゲートウェイを経由しないリクエストには、エンドポイント管理や認証情報の慎重な取り扱いなど、別の対策が引き続き必要です。

すでに使われているツールに対応する

承認プロセスは、ツールがすでに使われ始めてから整備されることがよくあります。ペナルティなしでツールを申告できる猶予期間を設ければ、実態に即したインベントリをつくれます。検出も役立ちます。サインインログ、経費精算の記録、ブラウザー拡張機能の一覧、そしてエージェントについては管理対象デバイス上の MCP 設定などです。

次に、見つかったものを仕分けます。条件付きで承認する、承認済みの代替ツールを案内する、利用をやめてもらう、のいずれかです。ツールを却下した理由と代わりに使うべきものを説明すれば、プロセスへの信頼を保てます。

ツールの承認は、すべての操作の承認ではない

ツールの利用を承認することと、ツールが行う操作をレビューすることは、別の管理策です。前者は導入前に一度だけ行います。後者は、返金の実行や顧客リストのメール送信など、エージェントが特定の操作を提案したときに行います。

MCP の仕様では、人がいつでもツール呼び出しを拒否できるようにすること、そしてクライアントが操作の前に確認を求めることを推奨しています。影響の大きい操作については、さらに一歩進めて、実行前に別の担当者がリクエストの正確な内容をレビューするようにもできます。どの操作にこのレビューを必須にするかは、誤りが起きた場合の損害の大きさに基づいて決めましょう。

承認を継続的に見直す

AI ツールは変化が速いものです。ベンダーは機能を追加し、データ利用規約を変更し、新しいコネクターを導入するため、6 か月前の承認が今では別の製品を対象にしている可能性もあります。承認は定期的に見直し、さらにデータの新しい使い方、新しい接続、新しい操作、プランの変更など、重要な変化があったときにも見直しましょう。

記録を残しておきましょう。誰がツールを申請し、誰が承認したか、どのような条件だったか、最後にレビューしたのはいつか。こうした記録があれば監査が楽になり、どの決定から見直すべきかもわかります。

Durinが適している場所

Durin は、MCP を使うエージェントについて、接続と操作に関する判断を担います。メンバーは「接続」画面で、カタログからプロバイダーを選ぶか、利用目的を添えてカスタムサーバーを提案して接続を申請し、管理者が「承認」画面でその申請を承認または却下します。承認しただけで何かが有効になることはありません。その後も、プロバイダーの設定、ツールのレビュー、読み取り専用のテストが続きます。

接続が有効になると、Durin は各リクエストを、その時点のアクセス権とチームのルールに照らして確認します。これらのチェックを通過したレビュー済みのリクエストは、デフォルトで実行に進めます。管理者は、提案された変更操作を別の管理者がレビューするよう求めることもでき、その場合、申請者は許可の有効期限が切れる前に、同じリクエストをもう一度送信します。シャドーMCP の検出機能は、登録済みデバイスに設定されている MCP サーバーを報告するため、承認プロセスを経ずに使われているツールを見つけるのに役立ちます。

Durin は AI ベンダーやアプリ、そのデータ利用規約を評価するものではなく、管理できるのは Durin のゲートウェイを経由するリクエストだけです。そうした判断は、引き続き組織全体の承認プロセスが担います。