セキュリティチェックシートの回答術｜情シス審査で止まらない準備

2026年10月12日

受注はほぼ決まっていた。現場の担当者は乗り気で、見積もりも通り、あとは契約書を交わすだけ——そう思っていた頃に、Excelの添付ファイルが届く。情報システム部門からのセキュリティチェックシート、全40問。データの保管場所、通信の暗号化、委託先の管理状況、障害やインシデント時の連絡体制。開発に聞けば「それはインフラ担当に」、インフラに聞けば「契約の話は法務では」と社内をたらい回しになり、気づけば2週間が溶けている。その間、せっかく温まった現場の熱は静かに下がっていく。

結論から言う。情シス審査で止まる案件の多くは、自社のセキュリティが弱いから止まっているのではない。原因はむしろ答えを手元に持っていないという準備の側にある。過去の回答を資産として一箇所に集め、答えられない項目の伝え方まで先に決めておけば、2週間かかっていた工程は数日に縮む。そしてこの関門は、準備したベンダーにとっては他社が落ちる場所として働く。審査は敵ではない。

本記事では、審査で止まる構造、よく聞かれる項目の全体像、回答を資産化する仕組み、AIで下書きを作るプロンプト、そして答えられない項目の伝え方までを順に示す。読み終えたら、次にチェックシートが届いた日の段取りが変わるはずだ。

なぜ情シス審査で止まるのか

止まる原因は技術力の不足ではなく、むしろ審査が来る前提で商談を設計していないことにある。チェックシートは不意打ちのように見えて、法人向けにITサービスを売るならほぼ確実に通る工程である。にもかかわらず、多くの現場は届いてから慌てて動き出す。

理由は3つある。

第一に、現場の担当者が自社のセキュリティ要件を知らないまま話を進めることだ。商談の相手は営業部門や事業部門の担当者で、彼らの関心は業務課題の解決にある。情報システム部門にどんな審査基準があり、どの段階で何を提出させられるのかを把握している担当者は少ない。だから「社内の承認は私のほうで進めます」という言葉を信じて提案を詰めていくと、最終段階で初対面の審査者が登場する。営業側が一度も会話していない人物が、資料だけを見て可否を判断する構図になる。

第二に、ベンダー側も毎回ゼロから答えていることだ。前回のチェックシートは、担当した営業の個人フォルダか、送信済みメールの添付ファイルの中に眠っている。別の営業が次の案件で同じ質問を受けても、その存在を知らない。結果として、過去に一度答えた内容をもう一度開発に問い合わせることになる。開発側からすれば、同じ質問が形式だけ変えて何度も飛んでくる状態であり、対応の優先度は下がる。この往復が日数を食う最大の要因である。

第三に、答えられない項目を曖昧にすると差し戻されることだ。「適切に管理しております」「社内規程に基づき運用しています」といった記述は、書いた側は無難に処理したつもりでも、審査する側には何も伝わらない。審査者は社内に対して導入の可否を説明する責任を負っている。中身のない回答は、そのまま再質問として返ってくる。1往復ごとに数日が消え、しかも回答の信頼度は下がる。

具体例で考える。同じチェックシートを受け取った2社があるとする。一方は過去の回答集を持っており、40問のうち35問を営業が即日埋め、残り5問だけを開発に投げて3日で提出した。もう一方は全問を開発に転送し、他の開発タスクの合間に処理されて2週間後に返ってきた上、曖昧な記述が5項目差し戻された。技術的な中身は大差なくとも、審査者の目に映る印象は「この会社は管理ができている」と「この会社は社内が整っていない」に分かれる。審査は技術の試験ではなく、組織の成熟度の試験として機能している側面がある。

なお、自社の営業チームが生成AIを安全に使うためのルール作りは営業組織のセキュリティ・ガイドラインで扱っている。あちらが自社の内側を守る話だとすれば、本記事は顧客から審査される側として外向きに答える話だ。立場が逆であり、必要な準備も別物である。

よく聞かれる項目の全体像

チェックシートの様式は顧客ごとに違う。設問数も、Excelかスプレッドシートか、Webフォームかもばらつく。だが聞かれている論点はおおむね共通しており、分類すれば7つに収まる。先に全体像を押さえておけば、初見の様式でも「これはどの論点の質問か」を即座に判定できる。

分類	何を聞かれるか	事前に用意しておく答え
データの保管場所	データがどの国・どの事業者の環境に置かれるか、顧客データが他社と論理的に分離されているか	利用しているクラウド基盤とリージョン、データ分離の方式を1〜2行で説明した定型文
アクセス管理・認証	誰がどの権限で顧客データに触れるか、認証方式と権限付与の運用はどうなっているか	提供機能としての認証方式と、自社社員が顧客データへ触れる際の承認フロー
通信の暗号化	通信経路と保管データの暗号化の有無、利用しているプロトコルの世代	通信と保管それぞれの暗号化の実装状況を、製品仕様として記述した説明
バックアップと可用性	バックアップの頻度と保管期間、障害時の復旧目標、過去の停止実績	バックアップ方針と、公開可能な範囲での稼働実績・障害時の対応手順
委託先・再委託	サービス提供に関わる外部事業者は誰か、再委託の有無と管理方法	利用している外部サービスの一覧と、委託先管理の社内ルールの概要
インシデント対応と連絡体制	事故が起きたとき誰が誰に、どの経路で、どれだけ早く連絡するか	一次連絡窓口と連絡手段、社内の報告体制を図か箇条書きにしたもの
退会時のデータ削除	契約終了後にデータをどう扱うか、削除の方法と証跡、返却可否	契約終了時のデータ返却・削除の手順と、完了を伝える方法

重要な前提がある。この表の右列はあくまで自社の実態をそのまま書くための枠であって、模範解答ではない。規格や第三者認証の取得状況、満たすべき水準、顧客側が必須と考える条件は、自社の状況と顧客の調達ルールの双方によって変わる。何が求められるかを一般論で決め打ちせず、自社の実装と社内規程を事実として確認し、不明な点は顧客の審査担当に要求水準を聞くのが正しい手順だ。認証や規格の名前を安易に持ち出して「業界標準を満たしています」と書くのは、後で根拠を問われたときに最も立場を悪くする書き方である。

また、審査はチェックシートだけで終わらない。多くの案件では、ほぼ同時期に契約書や利用規約、SLAのレビューも走る。両者は求められる精度が違うため別の準備が必要で、契約書側の読み方は契約書チェックにAIを使う手順にまとめている。チェックシートで述べた内容と契約書の条文が食い違っていないかは、提出前に必ず突き合わせておきたい。

回答を資産化する仕組み

ここが本題だ。やるべきことは、回答を案件ごとの作業から組織の在庫へ移すことに尽きる。考え方自体はRFP対応をAIで効率化する手順と同じで、一度書いた答えを次の案件でそのまま使える形に整えておく発想である。違いは、RFPが案件ごとに個別性が高いのに対し、セキュリティチェックシートは聞かれる論点がほぼ固定されている点だ。つまり資産化の効果はこちらのほうが大きい。

①過去の回答を1つのシートに集約する

まず、過去に提出したチェックシートをすべて集める。担当者の個人フォルダ、送信済みメール、共有ドライブの奥。探せば数件は出てくるはずだ。それを1枚のシートに統合し、前章の7分類で並べ替える。列は「質問の趣旨」「標準回答文」「補足が必要な場合の追記」「最終更新日」「回答の根拠」の5つで足りる。

肝は、顧客ごとの質問文をそのまま貯めるのではなく、あくまで質問の趣旨で束ねることだ。「データはどこに保管されますか」と「データセンターの所在国を記載してください」は文面が違うだけで、聞かれていることは同じである。趣旨で束ねれば、設問数が増えても在庫は増えない。実務的には、7分類それぞれに10〜20問ぶんの趣旨を並べた状態が最初のゴールになる。ここまで作れば、次に届く初見のシートの大半はコピーと微修正で埋まる。

②製品の変更時に更新する担当を決める

資産化の失敗はほぼすべて、ここで起きる。シートを作った直後は精度が高いが、製品のインフラ構成が変わり、利用する外部サービスが入れ替わり、認証方式が追加されるにつれて、記述は静かに古くなる。古い回答を提出するのは、答えられないことより悪い。審査を通した後に実態との差が判明すれば、信頼の問題になる。

対策は単純で、更新の責任者を名前で決めることだ。推奨は、開発またはコーポレートIT側に1人、営業側に1人を置く二人体制である。開発側は仕様が変わったときにシートへ反映する役、営業側は案件で出た新しい質問を在庫に追加する役を持つ。加えて、インフラ構成や外部サービスの変更を扱う社内の手順に「チェックシート回答の更新」を1行加えておくと、更新漏れが構造的に減る。四半期に一度、全項目の最終更新日を眺める時間を取るだけでも十分機能する。

③営業が9割答えられる状態を作る

最終的に目指す姿は、営業またはプリセールスが自力で9割を埋め、技術確認が本当に必要な項目だけを開発へ回す運用である。この比率が実現すると、開発側に飛ぶ質問が10分の1になるため、回答の優先度が上がり、返ってくるのも速くなる。開発を守ることが、結果として自分の案件を速く通す。

そのために在庫のシートには、回答文だけでなく営業が判断できる基準を書き添える。たとえば、この質問はそのまま標準回答でよい、この質問は顧客の業種によって追記が必要、この質問は必ず開発の確認を取る、という3段階の仕分けだ。仕分けの印が付いていれば、営業は迷わずに手を動かせる。構造としては商談の想定問答集とまったく同じで、作り方の型は商談の想定問答集をAIで作るプロンプトが流用できる。顧客から聞かれる質問に即答できる状態を在庫で作るという意味で、両者は同じ運用の別の面である。

AIで回答の下書きを作るプロンプト

在庫が揃えば、AIの使いどころは明確になる。届いたチェックシートの質問文と、自社の既存回答集を一緒に渡し、引き当てと下書きをさせる工程だ。人間がやるべきなのは、引き当て結果の検証と、未確認項目の確認取りだけになる。

あなたはB2B SaaSベンダーのセキュリティ審査対応の担当者だ。
顧客から届いたセキュリティチェックシートに回答するため、
下記の既存回答集を参照して下書きを作成してほしい。

# 顧客から届いたチェックシートの質問
〔ここに質問文を番号付きで貼り付ける。項目名・設問文・回答欄の形式がわかる状態で〕

# 自社の既存回答・製品仕様
〔ここに社内の回答集、製品仕様の該当部分、インフラ構成の説明を貼り付ける〕

# 絶対に守る制約
- 既存回答集と製品仕様に記載がない事項は、推測で埋めてはならない
- 根拠が見当たらない質問は、回答文を作らず「未確認」として分類する
- 規格名・認証名・数値（期間、頻度、SLA値など）は、
  入力に明記されているものだけを使う。補完や一般論での推定は禁止する

# 出力してほしいもの
1. 引き当て表
   質問ごとに、既存回答集のどの項目が該当するかを示す。
   完全に一致／趣旨は同じだが追記が必要／該当なし の3区分で判定し、
   判定の理由を1行添える。

2. 回答文の下書き
   「完全に一致」「趣旨は同じ」と判定した質問について、
   そのまま提出できる回答文を作る。
   1問あたり2〜4行。曖昧な一般論は使わず、事実と実装を具体的に書く。

3. 社内確認が必要な項目のリスト
   「該当なし」と判定した質問を一覧にし、
   それぞれ誰に何を確認すべきか（開発／インフラ／法務／経営）を示す。
   確認したい内容は、そのまま社内チャットに貼れる質問文の形で書く。

4. 回答に含めるべきでない表現の指摘
   作成した下書きの中から、次に該当する箇所を指摘する。
   - 根拠を示せない断定（業界標準に準拠、十分な水準など）
   - 中身のない定型句（適切に管理、万全を期すなど）
   - 将来の対応を確約してしまっている表現

出力のうち、実務で最も価値があるのは3番目のリストである。何を誰に聞けばよいかが質問文の形で揃っているため、そのまま社内に投げられる。従来は営業が自分で論点を整理してから聞く必要があり、そこで半日を失っていた。

運用上の注意を2つ述べる。1つは、4番目の指摘を必ず読むことだ。AIは空欄を嫌い、もっともらしい一般論で穴を埋めようとする。制約で禁じても完全には止まらないため、人間の目で定型句と断定表現を削る工程は外せない。もう1つは、入力する情報の機密区分の扱いである。自社のインフラ構成や認証方式は、社外に出す前提の情報とは限らない。どの環境なら入力してよいかは営業の判断で決めず、自社の情報管理ルールに照らして先に線を引いておく必要がある。

答えられない項目の伝え方

答えられない項目、できていない項目の書き方で通過率は変わる。結論は明確だ。審査対応で最悪手なのは曖昧にごまかすことである。

理由は、審査者の立場を考えればわかる。彼らが探しているのは完璧なベンダーではない。リスクの所在を把握し、それを社内で説明できる材料である。未対応の項目があっても、範囲と影響と代替手段が明示されていれば、審査者は条件付きで前に進める判断ができる。逆に「適切に対応しております」とだけ書かれた回答は、審査者に何の材料も与えない。説明できない項目を抱えたまま承認を出すことは、審査者にとって自分の責任問題になるため、彼らは必ず聞き返す。つまり曖昧な記述は、通過を早めるどころか往復を増やす。

書き方は3つの要素で組む。第一に、できていないという事実を明記する。第二に、そのリスクを運用や契約でどう補っているかという代替策を添える。第三に、対応の予定があるならその方針を書く。たとえば特定の認証連携に未対応なら、現時点では未対応であること、権限の棚卸しを運用手順でどう担保しているか、対応方針が社内で検討されているかを順に書く。この3点が揃っていれば、未対応という事実そのものが減点の決定打になることは多くない。

同時に、過剰な約束は避けなければならない。審査を通したい気持ちから、開発に確認せず「対応可能です」と書き、契約締結後に実装がないと判明する。これは失注より重い事故である。顧客側は回答書を根拠に社内承認を取っており、約束の不履行は信頼の問題として扱われる。チェックシートの記述が契約書や覚書に引用される形で残ることもあり、そうなれば営業個人の判断ミスが会社の債務になる。対応予定を書くときは、確約の表現と検討中の表現を書き分け、期限を書くなら開発の合意を取ってからにする。

誠実な回答が通過率を上げるという経験則は、審査者の評価軸を考えれば筋が通っている。書けないことを書けないと明示し、代わりに何をしているかを示せるベンダーは、管理ができている会社として読まれる。できないことを曖昧にする会社は、できていないことを把握していない会社として読まれる。審査の場で問われているのは、実装の完成度そのものよりも、自社の状態を正確に説明できるかどうかの能力である。

よくある質問

認証を取っていないと通らないのか

一律には決まらない。第三者認証の取得が加点要素や前提条件になる顧客もあり、一方で製品の実装と運用の説明で判断する顧客もある。何が必須かは顧客の調達ルールと取り扱うデータの性質によって変わるため、自社で勝手に結論を出さず、審査担当に要求水準を直接聞くのが早い。実務上は、認証がないことを隠すのが最も損をする。未取得であることを明記し、認証項目に相当する管理を自社の運用でどう実現しているかを具体的に書けば、議論の土台には乗る。認証の有無だけで即落ちと決め込んで提出を諦めるのは、確認もせずに自社を失格にしているのと同じだ。

チェックシートは誰が書くべきか

一次起案は営業またはプリセールス、技術的な事実確認は開発やインフラ、契約や法的な表現は法務、という分担が現実的である。全問を開発に丸投げすると日数がかかり、営業が全問を一人で書くと事実の誤りが混ざる。前章で述べた3段階の仕分けを在庫シートに持っておけば、この分担は自動的に決まる。誰が最終的に提出内容の責任を持つかも、案件が走る前に決めておきたい。提出直前に責任の所在で揉めるパターンが、締切を最後に押し込む典型例である。

AIに自社の仕様を貼って大丈夫か

機密区分の判断を、自社のルールで先に決めておく必要がある。自社のインフラ構成、認証方式、委託先の一覧は、顧客に提出する前提の情報であっても、学習に使われる可能性のある環境へ入力してよいとは限らない。判断すべきは3点だ。どのツールのどのプランなら入力してよいか、入力してはいけない情報は何か、顧客から受け取ったチェックシート自体を貼ってよいか。3つ目は見落としやすい。顧客の様式には、相手の社内体制や審査基準が含まれており、秘密保持の対象になる場合がある。営業部門だけで線を引かず、情報管理の担当と合意を取ったうえで運用に入るべきだ。