Askhub
資料請求 お問い合わせ
お問い合わせ

ナレッジ

AIエージェントの導入審査をスムーズに通すには？推進担当の準備と選び方

全部そろうまで、待たなくていい

「AIの審査は厳しい。すべての項目に答えられるまで、稟議は通らない」
AIに業務を任せたい推進担当の方ほど、そう身構えていると思います。

日本企業は特に、承認の階層が深い。
情シス、内部統制、法務。稟議は何人もの机を回ります。
そこで確かめられるのが、AIエージェントの導入審査です。AIに業務の記録の読み書きを、何をどこまで許すのか。おかしいときに、どう気づいて止めるのか。誰が責任を持つのか。

でも、すべての条件がそろうまで待つ必要はない、と私たちは考えています。
読むだけの小さな使い方から始める。確かめられた範囲だけ、任せる範囲を広げる。
そうすれば、審査も段階ごとに短く通せます。

審査が早く通るかは、推進する側の準備で大きく変わります。
この記事は、営業部門や管理部門で稟議を通す推進担当の方に向けて書いています。

まずは、審査で何を聞かれるのかから見ていきます。

新しく聞かれるのは、4点だけ

多くの会社には、クラウドサービスを導入するときのセキュリティチェックシートがあります。
認証、暗号化、バックアップ、データセンターの所在地。第三者認証（政府のクラウド評価制度ISMAP、監査法人の保証報告書SOC 2、ISO/IEC 27001など）。
AIエージェントの審査でも、これはそのまま使えます。

新しく聞かれるのは、AIならではの4点です。

1つ目は、AIが記録を書き換える担当者になること。
見積の登録や入金の消し込みを任せると、AIの出力がそのまま会社の記録になります。
だから聞かれるのは、AIに何を許すか。承認をどこに挟むか（AIエージェントの権限設計、AIエージェントの承認はどの粒度で？承認疲れと自動承認ルール）。

2つ目は、AIが乗っ取られうること。
AIが読むメールやPDFに紛れ込んだ指示で、AIの動きが変わることがあります。プロンプトインジェクションと呼ばれる攻撃です。
いまのところ、完全には防げません。英国の国家サイバーセキュリティセンター（NCSC）も、「止める」とうたう製品には懐疑的になるよう勧めています。
だから聞かれるのは、乗っ取られても被害がどこまでで止まるか。そして、どう止めるか（プロンプトインジェクションとは？防げない前提の対策と確認8項目、AIエージェントの監視と停止）。

3つ目は、「誰がやったか」が二重になること。
AIは、誰かの代わりに動きます。記録に本人の名前しか残らなければ、本人とAIのどちらの操作か分かりません。
「記録で人とAIを見分けられるか」を聞かれます（AIエージェントは誰の権限で動くのか）。

4つ目は、振る舞いが変わり、委託先が増えること。
モデルの更新で、AIの答え方は変わります。AIの事業者や、AIを外部のツールにつなぐ部品も、新しい委託先・供給元として加わります。
「データがどこへ行くか」「更新をどう知るか」を聞かれます（AIで作ったアプリは誰が直す？パッチが追いつかない時代の保守運用、生成AIに渡すデータはどこの国へ？保存先の確かめ方と個人情報保護法28条）。

では、この4点を確かめる物差しは、もうあるのでしょうか。

公的な資料は、全社の方針に効く

国内には、すでに使える公的な資料があります。2026年10月時点で、主なものは3つです。

全社の方針の点検には、総務省・経済産業省のAI事業者ガイドラインのチェックリスト（2026年3月31日）。安全性、プライバシー、透明性、ガバナンスの方針などを確かめるものです。

要求事項の書き方には、デジタル庁の生成AIの調達・利活用に係るガイドライン（2026年6月公開、9月1日施行）。
政府機関向けですが、高リスクの判定に「出力が人の判断を経るか」を含みます。書き込みまで任せるかを考えるとき、民間でも参考になります。

ベンダーへの質問には、AIセーフティ・インスティテュートの評価観点ガイド（2026年7月7日の版）。
AIエージェント向けに「観測と制御」を新たに設けました。権限の限定、リスクの高い操作の検知、人による介入・停止です。「この観点でどう評価したか」と、ベンダーに聞けます。

ただ、どれも個別の導入をそのまま審査する物差しではありません。
評価観点ガイドは、AIを提供する側が自ら評価するための観点です。経済産業省の契約チェックリストも、AIの書き込みや停止を主な題材にしていません。
「誰の代わりにAIが動いたか」の記録や、業務の単位での書き込みの許可。これらは、正面から扱われていませんでした。

だから、分けて使うのが分かりやすいと考えています。
全社の方針や契約の確認には、公的な資料を使う。個別の導入では、先の4点を足して確かめる。
この4点への答えを推進担当が先に用意しておけば、審査の場での「持ち帰って確認します」が減ります。

とはいえ、4点すべてを最初から深く聞かれるわけではありません。

聞かれる範囲は、使い方で絞れる

審査を短くする一番の近道は、最初に「どの段階の使い方か」をはっきりさせることです。
AIが読むだけなのか。候補を出して、人が確定するのか。AI自身が、記録に書き込むのか。
それによって、確かめることの量は大きく変わります。

使い方の段階

業務の例

審査で主に確かめること

読むだけ

営業の商談メモの要約、社内規程や過去の提案書の検索

入力が学習に使われないか。データの行き先。見てはいけない文書が検索に出ないか

候補を出し、人が確定する

管理部門の入金消込の候補の提示、営業の見積書の下書き

上に加えて、AIが読む社外の文書（取引先のメールやPDF）の把握。記録で人とAIを見分けられるか

AIが書き込む

決めた条件の範囲での自動の消し込み、SFA（営業支援システム）の商談情報の更新

上に加えて、書き込める操作の範囲、承認の挟み方、止め方、取り消し方

なぜ、段階が上がるほど確かめることが増えるのか。
そろうと危ない組み合わせがあるからです。

開発者のSimon Willison氏は2025年6月、これを「致命的な三要素」として整理しました。
社内の私的なデータに触れる。信頼できない外部の内容を読む。外へ送れる。
この3つが同じ仕事の中でそろうと、紛れ込んだ指示で情報を持ち出されえます。
読むだけの使い方なら、3つはそろいにくい。書き込みや送信を任せるほど、そろわないようにする工夫が要ります。

だから、最初の申請で、書き込みまでの審査をすべて受ける必要はありません。
小さな試行にまで全部の項目を課すと、時間がかかります。社員が会社の把握しないAI（シャドーAI）に流れるきっかけにもなります。
「まず読むだけで試し、記録を見てから候補の提示に進む」。そう段階を区切って申請すれば、情シスも判断しやすくなります。

段階を上げるときは、追加で確かめる項目だけを審査し直します。
最初の審査の記録が、そのまま次の段階の土台になります。

段階が決まれば、次は稟議の前の準備です。

往復を減らすのは、稟議の前の3つ

審査に時間がかかる原因は、たいてい2つのどちらかです。
何に使うのかが決まっていない。ベンダーの説明を裏づける材料がない。
次の3つを先にそろえておけば、やり取りの往復は減ります。

1. 用途の一枚紙

「全社で自由に使えます」という説明は、審査する側には「用途が決まっていない」と聞こえます。
だから、業務ごとに1枚にまとめます。
対象の業務と、使い方の段階。AIが読むデータ（社内の文書、取引先から届くメール、顧客の情報など）。AIが書き込む先（SFA、会計システムなど。読むだけなら「なし」）。業務の責任者と、AIの設定を変えられる人。

営業部門なら、こう書けます。「商談メモの要約。読むのは担当顧客の商談記録だけ。書き込みはなし。責任者は営業企画の課長」。
管理部門なら、「入金消込の候補の提示。読むのは入金明細と請求データ。確定するのは経理担当者」といった形です。

2. 実演の段取り

ベンダーの「対応済み」という回答も、それだけなら自己申告にすぎません。
推進担当が先に実演の場を設け、その結果を審査に持ち込む。それだけで、話は早く進みます。

図1 回答の裏づけ · 自己申告を3つの方法で確かめる
実演は「いま効いているか」を、記録は「これまで効いていたか」を、契約は「この先も守られるか」を示します。重要な項目は2つ以上で裏づけます。

実演では、うまくいく場面より「失敗するべき場面」を試します。
許していない操作を頼んで、断られるか。権限のない文書を検索させて、出てこないか。停止したあとに、定期実行が動かないか。
こうした場面を推進担当が業務に合わせて決め、試験環境で動かしてもらいます。記録は、1件の操作を記録だけで辿った例など、サンプルで構いません。

この場面は、いま情シスが気にしていることとも重なります。
JPCERT/CCは2026年10月、国内組織で相次ぐ不正アクセスに注意喚起を出しました。
続く調査で挙げたのは、操作の対象と内容に応じて許可を判定すること。認証用の秘密情報を、アプリに埋め込まないこと。
「許していない操作が断られるか」「AIから鍵の値が読めないか」。これを実演で見せられれば、その関心にそのまま答えられます。

3. 契約と規約の該当箇所

「入力は学習に使いません」「データは国内で処理します」。
こうした説明は、利用規約やデータの取り扱いを定めた契約のどこに書いてあるかまで確かめます。設定画面の説明だけでは、規約の改定で変わることがあるからです。
個人データを渡す場合は、契約の相手が日本の会社か、外国の事業者かも整理しておきます。

インシデントの連絡も、契約で確かめておきたいところです。
個人データが漏えいしたとき、自社が個人情報保護委員会に出す速報は、概ね3〜5日以内が目安です（個人情報保護委員会）。
ベンダーからの連絡は「何日以内」なのか。それがこの3〜5日に間に合うかで、契約の書き方を確かめます。

第三者認証や保証報告書も、契約の確認の代わりにはなりません。
保証報告書は、利用する側にも一定の統制を求めていることが多いからです。それを自社で行っていなければ、報告書には頼れません。

準備がそろったら、次はベンダーや作りを選ぶ物差しです。

導入がスムーズに進みやすいAIの選び方

ベンダーや作りを選ぶ段階で、次の基準を満たすものを選んでおくと、情シスへの説明が短く済み、導入が進みやすくなります。最初からすべてを満たす必要はありません。使い方の段階に合うものから見ていけば十分です。

  1. AIが書き込める操作が、業務の単位で決まっている：「入金を消し込む」「商談ステージを更新する」のような操作だけを許し、データを自由に書き換えられない作りです。乗っ取られても被害は決めた操作の範囲にとどまる、と説明できます。OWASP（国際的なセキュリティ団体）も、AIに与える権限の広げすぎを主なリスクの1つに挙げています
  2. 許すかどうかの判定が、AIの外で行われる：「AIへの指示文で禁止しています」ではなく、システム側の関門で断る作りです。指示文は、乗っ取られると破られるからです
  3. 承認を業務の単位で挟め、承認する人が根拠を見られる：金額や取引先などの条件で承認を挟み、承認画面で元のデータを確かめられると、承認が形だけになりません
  4. 記録で人とAIを見分けられ、1件ずつ辿れる：誰の代わりにどのAIが、何を根拠に、誰の承認で変えたかが、書き換えられない形で残ります
  5. 鍵をAIに見せない：外部サービスのAPIキーなどをAIが動く場所に置かず、AIには決めた操作だけを呼ばせる作りです
  6. 社内検索が、使う人の権限で絞られる：その人が見られない文書は、最初から検索の対象になりません
  7. 入力を学習に使わないことと、データの行き先が文書で示されている：保存と処理の地域、再委託先を、規約や別紙で確かめられます
  8. 止め方が用意されている：おかしいときに管理者がAIの動きを止められ、止めたあとに定期実行が動き続けないことを実演で確かめられます
  9. モデルの更新や提供終了が事前に知らされる：業務で使うモデルが変わる前に、自社の業務の例で確かめる時間がとれます

1つの製品でこれらすべてを満たすことは、まずありません。欠けている部分は、別の仕組みや自社の運用で補えば足ります。統制を置く場所の選び方はAIエージェントの権限設計で整理しています。

全部そろわなくても、条件つきで通せる

全項目がそろわなければ導入できない、というわけではありません。
満たせない項目があれば、代わりの手当てと使い方の制限を書いて、条件つきで通す。それが現実的だと考えています。

進め方は、ここまでの順のままです。
段階を決める。チェックシートにAIの4点を足して送り、回答を推進担当が先に読む。実演を受け、記録のサンプルをもらう。契約・規約と照らし合わせる。
交渉が難しい汎用的なサービスなら、入力する情報を絞る運用で補います。
最後に、満たせない項目と手当てを稟議に書きます。「書き込みはまだ許さない」「個人データは入れない」。こうした使い方の制限で補えば、証拠のそろった申請になります。

分担の一例です。
契約と体制は、法務と内部統制。書き込みと承認は、業務部門と内部統制。IDや記録、データの行き先は、情シスとセキュリティ。
推進担当は、その間をつなぐ窓口になります。

導入した後も、見直すのは該当する項目だけです。
読むだけから書き込みへ進む。個人データを渡し始める。自動承認を足す。モデルが変わる。そうしたときに、その分だけを見直します。

ただ、審査がどれだけ丁寧でも、審査では決まらないことが残ります。

何を決めるかは、業務部門が持つ

審査で確かめられるのは、「決めたとおりに守らせる仕組みがあるか」です。
「何を決めるか」は審査の外にあり、業務部門が持ちます。

1つは、業務の型と条件の中身。
何円までの差なら自動で消し込むか。どの商談ステージまでAIが更新してよいか。
条件が間違っていれば、システムは間違った条件を正確に守ります。

もう1つは、承認する人の判断。
承認画面が根拠を見せても、見るのは人です。

そして、どこまで任せるか。
どのリスクを取るかは、結果に責任を負う業務の側が決めます（セキュリティもガバナンスもAIが解決する？人に残る3つの仕事、AIエージェントの責任は誰が負う？システムと運用の責任分界）。

この3つを「業務部門が持つ」と稟議に書いておく。
そうすれば、情シスにとっても確かめる範囲がはっきりし、審査を進めやすくなります。

情シスに説明するときの要点

  • 既存のSaaSチェックシートはそのまま使い、AIならではの4点（記録を書き換える、乗っ取られうる、「誰が」が二重になる、委託先が増える）だけを足して確かめます
  • 今回の申請は「読むだけ／候補を出す／書き込む」のうちの1つの段階です。段階を上げるときは、追加の項目だけ審査をお願いします
  • ベンダーの回答は、自社で決めたシナリオでの実演、記録のサンプル、規約の該当箇所で裏づけています
  • AIが書き込める操作は業務の単位に限られ、許すかどうかの判定はAIの外で行われます。乗っ取られても、被害は決めた操作の範囲にとどまります
  • 満たせない項目は、使い方の制限と運用の手当てを付けた条件つきの申請にしています。何をどこまで任せるかは業務部門が決め、責任を持ちます

小さく通せば、任せる範囲は広げられる

審査は、すべての条件がそろうまで待つものではありません。
チェックシートにAIの4点を足し、使い方の段階で範囲を絞る。稟議の前に、一枚紙と実演と規約の該当箇所をそろえる。
それで、情シスへの説明は短く済みます。

最初の稟議は、読むだけの小さな使い方で十分です。
通った審査の記録が、次の段階の土台になります。
一段ずつ通していけば、AIに任せる範囲は広げられる。私たちは、そう確信しています。

関連記事

参考資料

Askhubについて

Askhubは、日本の中堅・大企業がAIに業務を任せるための基盤です。業務の型（オントロジー）でAIに許す操作を定め、承認と判断ログで任せる範囲を広げながら、国産の基幹システムまで書き込めるようにします。導入はコンサルタントが伴走します。

Askhubは、統制を置く場所でいえば業務の型を持つ基盤にあたります。審査でよく聞かれる点について、作りと確かめ方を挙げます。

  • 書き込みの判定は、サーバー側の1か所で行います。業務の型を決めたデータには、画面からでも、AIや外部のAIからでも、同じ書き込みの関門を通らないと書き込めません。定義にない操作をAIに頼んで拒否されるところを、実演で確かめられます。
  • 鍵の扱いでは、外部サービスの鍵をAIが動く環境に置きません。AIに渡すのは代わりの文字列だけで、本物に差し替えるのは、許可した送信先へ通信する瞬間に別の場所で行います。実行中のAIに鍵の値を読ませても本物が出てこないことを、実演で確かめられます。
  • 記録は、書き換えを防ぎ全ての版を残す監査ログに10年間残り、元のデータを消しても残ります。AIやトリガーが動いたときは、誰の依頼で動いたかも残ります。監査ログはご要望に応じて提供するので、写しを自社の手元に置いたうえで、1件の変更を記録だけで辿れるかを確かめられます。
  • 契約と文書として、データの扱い、再委託、漏えい時の通知、契約終了時の削除を利用規約と別紙で定めています。利用者データを扱う外部サービス事業者は、役割・扱うデータ・処理する国や地域を一覧で開示しています。

当社はISO/IEC 27001の認証を取得しています。管理者は、必要なときにエージェントの動きを柔軟に止められます。社内の他のAIを含めたIDの管理、シャドーAIへの対応、業務の型の定義はお客様の側に残ります。どこまで任せられるかは、本文の進め方どおり、実演・記録・契約で確かめてください。

※Askhubのサービスに関する記載は、2026年11月時点の情報です。

関連する機能：承認、製品の全体像

ナレッジの記事をもっと見る