生成AIのセキュリティ審査チェックリスト｜情シスが確認する12項目と、申請・稟議を通す書き方

審査が止まるのは技術の判断ではないことが多い

生成AIのサービスを使いたいという申請が情報システム部門に届いたとき、判断が止まる理由は「そのサービスが危険かどうか分からない」ではありません。多くは、何を確かめれば通せるのかが決まっていないことと、申請書に書かれた情報が足りないことです。

申請票に「業務効率化のため」「機密情報は入力しない」とだけ書かれていると、確認のしようがありません。どの情報を渡すのかが分からないので、提供元の規約を読んでも可否を決められません。結果として提供元への問い合わせと事業部への差し戻しが何往復も続き、事業部からは審査が遅いと見え、情シスからは書いてもらえないと見えます。

止まりを減らす順序は決まっています。確認する項目を先に固定し、その項目を埋めるために事業部に何を書いてもらうかを決め、判断の結果を条件付きで返す形にすることです。可否の二択にすると、条件を詰めれば通せたものまで不可になります。

情シスが確認する5項目

生成AIのサービスで見る点は、一般的なSaaSの審査項目に加えて、入力したデータの扱いに集中します。次の5つに整理すると、提供元への質問もまとめやすくなります。

確認する項目	何で確かめるか	通す条件の例
学習への利用	利用規約とデータ処理に関する条件、申し込むプランの記載	入力・出力を提供元のモデル学習に使わない設定または契約であること
データの保存先と期間	保存されるデータの種類、保存される国・地域、保存期間、削除の方法	保存期間が把握できていること、解約時の削除手順が示されていること
アクセス権限	認証方式、管理者機能、利用者アカウントの発行と停止の手順	既存のIDと連携できること、退職・異動でアカウントを止められること
ログの保全	誰がいつ何をしたかの記録、管理者が取得できる範囲、保持期間	調査が必要になったとき、対象期間の記録を管理者が取り出せること
委託先の扱い	提供元が使う外部のモデル提供者・基盤事業者、再委託の範囲	再委託先まで含めて条件が及ぶこと、変更時に通知があること

学習への利用は、伝聞で決めないことが要点になります。同じサービスでも個人向けプランと法人向けプランで扱いが違い、規約の版が変わることもあります。確認した日付と、根拠にした規約や条件の版を審査記録へ残しておくと、後から見直すときに読み直す範囲が絞れます。

保存先と期間は、学習に使われないことと保存されないことが別だという点を押さえます。学習には使わないが、不正利用の監視のために一定期間は保存する、という条件は珍しくありません。監視のために保存されるものが何で、どれだけの期間残るのかを確認します。

アクセス権限では、発行より停止のほうが問題になります。人が辞めた後や異動した後にアカウントが残ると、社内の情報を渡した先に、権限のない人が入れる状態が続きます。既存のIDと連携できるかどうかで、この手間は大きく変わります。

ログの保全は、事故が起きたときに何を答えられるかで考えます。誰がいつ何を入力したかまで取れるのか、利用の有無だけなのか、管理者が見られるのはどこまでか、保持期間はどれだけかを確認します。取得できても保持期間が短ければ、調査したい時期の記録は残っていません。

委託先の扱いは、生成AIのサービスで確認が抜けやすい項目です。提供元が自社でモデルを持たず、別の事業者のモデルを呼び出している構成が多くあります。その場合、自社のデータは提供元より先へ渡ります。どの事業者へ渡り、そこでの扱いはどうなるのか、変更されたときに通知があるのかまで見ます。個人データを含む場合は、委託先の監督が求められるため、法務と個人情報保護の担当と一緒に判断します。

社内の利用ルール全体をどう組むかは 生成AIの社内利用ルールをどう作るか で扱っています。この記事は、そのルールに沿って個別のサービスを通す部分を対象にします。

確認項目のチェックリスト（12項目）

5項目をそのまま提供元への質問と社内の判断に使える形へ分けると、次の12項目になります。申請が来た順に上から埋め、埋まらないものは空欄のまま残さず、満たせないときの扱いまで書きます。

区分	確認する内容	満たせないときの扱い
学習への利用	入力と出力を提供元のモデル学習に使わないことが、契約するプランの規約・条件のどの条項に書かれているか	条項を示せない場合は書面での回答を依頼し、回答が届くまで判断を保留する
学習への利用	学習に使わない設定を管理者が組織全体へ適用でき、利用者が個別に戻せない状態にできるか	利用者側で戻せる場合は、戻さないことを利用条件に書き、定期的に設定を確認する
学習への利用	規約やプランの条件が改定されたときに通知があるか。確認した版と日付を記録したか	通知が無い場合は、次に読み直す時期を審査記録へ書いておく
データの保存	入力したデータが保存される国・地域はどこか。地域を選べるプランがあるか	選べない場合は、個人データと取扱注意の情報を入力しない条件を付ける
データの保存	学習に使わない場合でも、不正利用の監視などの目的で保存されるものは何か。その保存期間はどれだけか	期間が示されない場合は不明のまま通さず、提供元へ照会する
データの保存	解約したときの削除の手順と、削除されたことを確認する方法があるか	手順が示されない場合は、契約前に削除の取り扱いを条項として詰める
アクセス権限	既存のIDと連携でき、退職・異動に合わせてアカウントを止められるか	連携できない場合は、停止を手作業で行う担当と手順を決めてから通す
アクセス権限	社内文書を参照させる場合、参照範囲が利用者の権限で絞られるか	絞られない場合は、参照させる範囲を全員が見てよい文書に限る
ログの保全	誰がいつ何を入力したかを管理者が取り出せるか。取れる粒度はどこまでか	利用の有無しか取れない場合は、扱ってよい情報の区分を下げる
ログの保全	記録の保持期間が、社内で調査に必要な期間を満たすか	足りない場合は、定期的に書き出して自社側で保管できるかを見る
委託先の扱い	提供元が呼び出す外部のモデル提供者・基盤事業者はどこか。その所在国はどこか	開示されない場合は、個人データを含む使い方を対象から外す
委託先の扱い	再委託先まで同じ条件が及ぶか。委託先が変更されたときに通知があるか	及ばない場合は、法務と個人情報保護の担当を入れて契約条件を確認する

このうち審査が実際に止まるのは、学習への利用の1つ目、保存の2つ目、委託先の2つです。学習への利用は、条項の場所まで確認できたかどうかで結論が変わります。 「学習には使いません」という説明はあっても、根拠が個人向けプランの説明ページだったり、規約の旧版だったりすることがあります。確認した条項と版を審査記録に残すと、次の更新時に読み直す範囲が絞れます。

保存については、学習に使わないことと保存されないことを分けて聞きます。 監視のために一定期間保存する条件は珍しくないため、保存されるものの中身と期間を個別に確認します。ここが「学習には使わないので保存もされない」とまとめられていると、あとで削除の依頼ができません。

委託先は、提供元の一次回答だけで終わらせないところが要点です。 自社でモデルを持たず別の事業者のモデルを呼び出す構成では、データは提供元より先へ渡ります。渡り先の名前と所在国、そこでの扱い、変更時の通知の有無まで質問に含めます。個人データを含む場合は、委託先の監督が必要になるため、この段階で法務と個人情報保護の担当を入れます。

3列目に書く「扱ってよい情報の区分」は、サービスごとに決めるものではなく、社内の利用ルールで先に決めておくものです。区分の切り方は 生成AIの社内利用ルールをどう作るか で扱っています。ログをどこまで見るかは 生成AIが社内でどれだけ使われているかを測る を参照してください。

審査で止まりやすい論点

確認項目を固定しても、次の5つでは判断が割れます。先に社内の扱いを決めておくと、審査のたびに議論せずに済みます。

回答の根拠が伝聞になっている。 「学習には使われないと聞いています」という申請は通せません。規約やデータ処理に関する条件のどこに書かれているかを示してもらいます。営業担当の口頭説明しかない場合は、書面での回答を依頼します。

対象が機能ではなくサービス単位になっている。 同じサービスでも、標準の機能と拡張機能で扱いが違うことがあります。外部と接続する機能や、社内のファイルを読み込ませる機能は、扱うデータの範囲が変わります。審査の対象は使う機能の単位で切ります。

無料プランでの試用がそのまま定着する。 無料や低額のプランは、有料の法人プランと条件が違うことがあります。試用の段階でも、扱ってよい情報の範囲を条件として付けておきます。

入力したデータの二次利用を止める設定が既定になっていない。 設定で止められるとしても、既定値が有効なら、利用者が個別に設定するまで有効のままです。管理者側で組織全体に適用できるかを確認します。

社内の情報をどこまで読ませるかが決まっていない。 社内の文書を参照させる使い方では、参照範囲が利用者の権限で絞られるかどうかが分かれ目になります。全員が同じ範囲を見る構成だと、人事や経理の文書が権限のない人の回答に混ざります。社内データを使う構成の選び方は RAGとファインチューニングの違い で扱っています。

事業部側に書いてもらう項目

審査が進むかどうかは、申請票の設計でほぼ決まります。情シスが確認する5項目を埋めるために必要な情報を、事業部が答えられる言葉で聞きます。

• どの業務で使うか … 対象の業務と、月あたりのおおよその件数
• 何を入力するか … 実際に渡す資料の名前と、その情報の区分（社内限、取扱注意など）
• 誰が使うか … 部署と人数、権限を分ける必要があるか
• 出力を何に使うか … 社内の検討資料までか、社外に出す文書に使うか
• 代わりの手段 … 既に社内で使えるサービスで代替できるか、できないならどこが足りないか
• 契約の形 … プラン名、契約期間、費用、支払方法

このうち審査の速さを決めるのは2つ目です。「機密情報は入力しません」ではなく、渡す資料の名前まで書いてもらいます。名前が挙がれば、情報の区分は情シス側で当てられます。区分が決まれば、確認すべき条件も決まります。

5つ目の代わりの手段を入れておくと、通せなかった場合の会話が変わります。既存の環境で足りるのであればそこへ寄せられますし、足りない点がはっきりすれば、別のサービスを探す材料になります。

条件付きで通す形を用意する

審査の結果を可否の二択にすると、判断できないものが不可に寄ります。実際には、範囲を制限すれば通せるものが多くあります。返し方を3つに分けておくと、事業部側でも次の動きを決められます。

• 通す … 申請された範囲でそのまま利用してよい
• 条件付きで通す … 扱う情報の区分、使う部署、使う機能、期間のいずれかを制限したうえで利用してよい
• 通さない … 満たせなかった条件と、代わりに使える経路を添えて返す

条件付きで通す場合は、条件を口頭で伝えず、審査記録と申請の回答に文章で残します。「取扱注意の情報は入力しない」「外部と接続する機能は使わない」「3か月後に利用状況を確認する」のように、後から確認できる書き方にします。

稟議に添える資料の構成

稟議を通す相手は情シスではありません。費用の決裁者が読んで判断できる形にします。技術的な説明を厚くするより、次の6点が揃っているかを見ます。

1. 何のために使うか … 対象の業務と、今どれだけ手間がかかっているか
2. 費用 … 初年度の総額、内訳（利用料、初期費用、教育の工数）、契約期間と解約の条件
3. 効果の見込みと測り方 … 何をいつ測って判断するか。導入前の状態を記録しておくこと
4. リスクと対応 … 情報の取り扱い、誤った出力の扱い、想定される事故と対応の手順
5. 審査の結果 … 情シスの確認が済んだ項目と、付いた条件
6. やめる条件 … 何が起きたら停止・解約するか、そのときの代替

3の効果の見込みは、導入後に説明を求められる箇所です。使い始めてから測り方を考えると、比較する相手がなくなります。指標の置き方と削減額への換算は AI導入の効果測定と効果検証 を参照してください。

6のやめる条件を先に書いておくと、稟議は通りやすくなります。決裁する側から見ると、後戻りできる提案のほうが承認の負担が軽いためです。検証から本番利用へ進む判断そのものの立て方は 生成AIのPoCが進まない で扱っています。

差し戻される書き方と、そのまま通る書き方

同じ6点を書いていても、書き方で差し戻しの有無が変わります。差し戻されるのは、決裁者が金額と責任の範囲を自分で確かめられない書き方です。数量、時期、条件のどれかが抜けていると、質問を返すしかなくなります。

稟議の項目	差し戻される書き方	決裁者が判断できる書き方
目的	業務効率化のため	月◯件の資料作成で、1件あたり◯分かかっている下書きの工程を対象にする
費用	月額◯◯円	単価×利用人数×12か月の年額に、初期費用と教育の工数を足した初年度総額。契約期間と解約の条件も併記する
効果の見込み	大きな工数削減が見込める	導入前の所要時間を◯月に測って記録済み。3か月後に同じ測り方で比べ、その結果で継続を判断する
リスクと対応	セキュリティ面は確認済み	入力してよいのは社内限までで、取扱注意の情報は入力しない。出力は担当者が確認してから社外文書へ使う
審査の結果	情シス確認済み	12項目の確認が完了。外部と接続する機能は使わない条件付きで可（審査記録◯番、確認日◯月◯日）
やめる条件	（書かれていない）	3か月後の利用が◯人を下回る、または規約改定で学習への利用の条件が変わった場合は、いったん停止して再審査する

右の列に共通するのは、あとから同じ方法で確認できる形になっていることです。「効率化する」は達成したかどうかを誰も判定できませんが、「◯月に測った所要時間と3か月後を比べる」は判定できます。審査の結果も、確認済みとだけ書くのではなく、条件と審査記録の番号を添えると、決裁者は情シスへ確認を戻さずに済みます。

費用は、月額だけを書くと年額と解約条件を聞き返されます。初年度の総額、内訳、契約期間、解約の条件を最初から並べておくと、1回で判断に進みます。導入後に効果を説明できる形にしておく点も同じで、測り方を先に書いておくほど、後から出典を探す手間が減ります。

部署単位の試用から全社契約へ切り替えるとき

一部の部署で使ってみて良かったので全社へ広げる、という流れでは、審査を通し直します。利用者の数が増えるだけに見えて、条件が変わるためです。

変わるところ	試用のとき	全社契約で追加になる確認
扱う情報	使う人が限られ、渡す資料も限られる	部署ごとに扱う情報が違う。取扱注意の情報を持つ部署が入る前提で条件を引き直す
アカウント管理	手作業で発行しても回る	既存のIDとの連携、入社・異動・退職に合わせた発行と停止の手順
権限の分離	全員が同じ範囲を見ても支障が出にくい	参照範囲を部署や役職で分けられるか。社内文書を読ませる場合は特に確認する
ログ	使った記録が追えれば足りる	保持期間、監査で求められる粒度、調査の依頼を誰が受けるか
契約	月単位で解約できることが多い	年間契約、最低利用数、値上げの条件、解約時のデータ返却と削除
費用の負担	部署の予算で収まる	全社の予算科目、部署への配賦、利用状況に応じた見直しの周期

このうち見落としやすいのは権限の分離です。試用の段階では同じ部署の人が同じ資料を見ているため問題になりませんが、全社へ広げると、権限で絞られていない参照範囲がそのまま漏れる経路になります。社内文書を参照させる構成では、切り替え前に確認します。

契約面では、年間契約に切り替わると解約のしやすさが下がります。使われなくなった場合にどうするかを決めたうえで契約期間を選びます。既製サービスを使い続けるか自社で持つ範囲を作るかの判断は AIエージェントは自作か既製ツールか で扱っています。

審査を運用として続ける

一度通したサービスも、条件は変わります。規約の改定、プランの変更、機能の追加、モデル提供者の入れ替えのいずれでも、審査したときの前提は動きます。契約更新の前に、確認した5項目のうち変わったものがないかを見る時間を取ります。

続けるための負担を下げるには、審査の記録を蓄積する形にします。サービス名、確認した日付、根拠にした規約の版、判断と条件、次に見直す時期を1件1行で残します。同じ提供元の別サービスや、似た構成のサービスを審査するときに、前回の記録がそのまま使えます。

審査の結果は、事業部から見える場所に置きます。どのサービスが通っていて、どの条件が付いているかが分かれば、申請の前に自分で確認できます。通っているサービスの一覧が見えないと、既に使えるものがあるのに新しい申請が出てきます。

まとめ：生成AIのセキュリティ審査を通すための要点

• 確認する項目を、学習への利用、保存先と期間、アクセス権限、ログの保全、委託先の扱いの5つに固定する
• 学習への利用は伝聞で判断せず、規約やデータ処理に関する条件のどこに書かれているかを根拠として残す
• 5項目は提供元への質問と社内の判断に使える12項目へ分け、満たせないときの扱いまで空欄にせず書く
• 申請票では「機密情報は入力しない」ではなく、実際に渡す資料の名前と情報の区分を書いてもらう
• 結果は可否の二択にせず、扱う情報・部署・機能・期間を制限した条件付きの形を用意する
• 稟議には、費用、効果の測り方、審査の結果、やめる条件を、あとから同じ方法で確認できる書き方で並べる
• 部署単位の試用から全社契約へ切り替えるときは、権限の分離、ログの保持期間、契約条件を確認し直す

Augueでは、生成AIの社内利用ルールづくりから、個別サービスの審査基準の整備、承認を人が持つ形での運用設計までを支援しています。審査で判断が止まっている案件や、試用から全社展開へ切り替える段取りでお困りの場合は、ご興味がある方は是非ご相談ください。

関連する記事

社内の利用ルール全体の組み立ては 生成AIの社内利用ルールをどう作るか、検証から本番利用へ進める判断は 生成AIのPoCが進まない、導入後の効果の測り方は AI導入の効果測定と効果検証、全社へ広げる順序は 生成AIが一部の部署で止まる を参照してください。

よくある質問

セキュリティ審査にはどれくらいの期間がかかりますか？

一律の日数は出せません。かかった日数の内訳を記録すると見当が付きます。申請票の不足を埋めるやり取り、提供元へ問い合わせて回答を待つ時間、法務や情報管理の担当が見る時間の3つに分けて記録し、次の審査に使います。多くの場合いちばん長いのは提供元からの回答待ちなので、必要な質問はまとめて一度に送ります。

ISO/IEC 27001やSOC 2の報告書があれば、個別の確認を省略できますか？

省略はできません。第三者の認証や監査報告は、提供元が管理の仕組みを持っていることを示すもので、自社が契約するプランで入力データがどう扱われるかまでは決めません。学習への利用、保存先、保存期間は契約とプランで変わるため、認証の有無とは別に確認します。認証は、提供元の運用体制を毎回ゼロから聞き取る手間を減らす材料として使います。

データが海外のサーバーに保存される場合はどう扱いますか？

保存される国と、そこに置かれるデータの中身の両方で判断します。個人データを扱う場合は、外国にある第三者への提供として本人の同意や体制の確認が必要になることがあるため、法務と個人情報保護の担当を早い段階で入れます。個人データを含めない使い方に限る、保存先の地域を指定できるプランを選ぶ、といった条件付きで通す形も選択肢になります。

すでに使っている業務システムに生成AI機能が追加された場合も審査しますか？

審査します。契約済みのサービスでも、AI機能が別の提供元のモデルを呼び出していれば、データの渡り先が増えています。既存の契約書だけでは分からないため、機能の追加を知った時点で、渡す範囲と学習への利用、管理者側で機能を止められるかを確認します。既定で有効になる機能は、判断が終わるまで管理者側で止めておくと落ち着いて確認できます。

審査を通せなかったとき、事業部にはどう返しますか？

不可とだけ返すと、個人の契約で使われる形に流れます。通せなかった理由をどの条件が満たせなかったかで具体的に示し、同じ目的を果たせる別の経路を一緒に出します。扱う情報を落とせば通るのか、別のプランなら通るのか、社内に用意済みの環境で代替できるのかを示すと、事業部側で選び直せます。