AIでセキュリティチェックシートはどこまで自動化できるのか？

「ChatGPTを使えば、セキュリティチェックシートも自動化できるのでは？」

そう考えたことのある担当者は、今や珍しくありません。ここ1〜2年でAI活用が急速に広がり、この問いを持つ担当者が増えています。問い自体は正しいといえます。AIはチェックシートの設問作成や依頼メールの文面生成において、驚くほど有能です。100項目のチェックシートを数分でドラフトし、取引先の業種に合わせた文体で依頼文を整えることも難しくありません。

「AIで全部できるのでは」という期待は、間違っていません。

ただし、その期待は「生成」という点において正しいといえます。問題は、実務が点ではなく線で成立していることです。

AIは点（生成）を作るのが得意です。しかし実務は線（運用）で動いています。この二つは能力の違いではなく、レイヤーの違いです。

チェックシート業務の一般的な流れは4つの工程です。

1. チェックシートの作成
2. メールでの回答依頼
3. 回収・進捗管理
4. 内容チェック

工程1と2は生成の領域です。工程3と4は運用の領域です。
この違いが、自動化の現実を決めます。

AIが最も力を発揮する工程です。

経産省やIPAのガイドラインを参照しながら、標準的なチェック項目を生成することはAIの得意領域にあります。「サプライチェーン管理に関するセキュリティチェックシートを作成してほしい」と入力すれば、それなりの精度でドラフトが出てきます。

ただし、そのままでは使えないケースが多いです。自社特有のリスクや、過去のトラブル経緯、業種特有の確認事項といった「文脈」をAIは持っていません。生成したドラフトを人間が調整・承認するというプロセスが現実的です。

AIの領域	標準的な設問の生成、依頼文のドラフト
運用の問題になる部分	自社固有リスクや過去経緯の反映
人が責任を持つ	調査項目の最終決定、リスク許容度の設定

依頼メールの文面生成も、AIが有効な場面です。相手企業の規模や関係性に応じて、丁寧さのトーンを変えた文面を素早く作れます。

ただし「誰に」「いつ」「どの順番で」送るかは、生成の領域ではありません。

100社の委託先リストを正確に管理し、送信ログを保持し、未回答者へのリマインドを適切なタイミングで行う——これは運用の問題です。

AIの領域	相手に合わせた依頼メールの文面生成
運用の問題になる部分	送信対象リストの管理、送信ログの保持
人が責任を持つ	重要取引先への個別対応、送信タイミングの判断

この工程が、生成と運用の境界線がもっとも鮮明になる場所です。

締切2日前、まだ返信が来ていない取引先が15社あります。昨日もリマインドを送りましたが、返ってきていません。重要な委託先が含まれているので、メールではなく電話した方がいいかもしれない——こうした判断と行動の連鎖は、AIが自律的に担うものではありません。

期限が近づくにつれて、一括対応から個別対応へと温度感が変わります。「全社に一斉送信する」段階と「この取引先だけに個別で連絡する」段階は、求められるアクションがまったく違います。

「誰が回答済みで、誰がまだか」というステータス管理は、継続的なモニタリングが必要になります。AIは問いかけには応えられますが、自律的に進捗を監視して次のアクションを起こし続けることは、生成の領域にはありません。未回答が積み重なると取引判断が止まり、確認が曖昧なまま取引が進みます。後から問題が発覚したとき、その時点では説明できる記録が残っていません。

AIの領域	相手に合わせた依頼メールの文面生成
運用の問題になる部分	送信対象リストの管理、送信ログの保持
人が責任を持つ	重要取引先への個別対応、送信タイミングの判断

回収した回答の内容確認でも、AIは補助として機能します。

回答テキストの要約、明らかな記入不備の検出、前回との差分の指摘など、一次スクリーニングとしての活用は現実的です。100件分の回答をAIにまず整理させてから担当者が確認する、という流れは効率化になります。

ただし最終的な判断は、スクリーニングの問題ではなく責任の問題です。

「YES（手動でカバーしています）」「YES（一部例外はありますが）」といった回答の実態を見抜くのは経験的な判断であり、「この委託先のリスクを許容するかどうか」はリスク判断です。YES/NOの精査ではなく、「このリスクを自社が引き受けるか」という意思決定であり、それはAIに委ねられる問題ではありません。

インシデントが起きたとき、問われるのは「誰がいつどう判断したか」のログです。「AIがスクリーニングしました」は説明責任として成立しません。「○月○日に担当者が確認し、マネージャーが承認した」という記録が実務では必要になります。判断のログがなければ、確認したという事実そのものが証明できません。

AIの領域	回答内容の要約、不備の一次スクリーニング
運用の問題になる部分	矛盾・違和感の発見、過去回答との比較
人が責任を持つ	リスクの最終判定、改善要求の意思決定

4つの工程を見渡すと、AIが担える領域は「作る」「整える」に集中していることがわかります。「回す」「管理する」は別のレイヤーの問題です。

AIは「まだ返信が来ていない相手」を追いかけ続けることが生成の役割ではありません。期限を設定して近づいたらリマインドし、回答が来たら確認し、また次のサイクルへ——この継続的なプロセス管理には、常に状態を保持している基盤が必要になります。
B2Bで求められるのは、点（ドキュメント）ではなく線（プロセス）の管理です。AIは点の生成に強いですが、線の管理は運用インフラの問題です。

セキュリティチェックは毎年繰り返すことに意味があります。昨年はYESだったのに今年はNOになった項目があれば、その理由を確認しなければなりません。この「過去回答との比較」「変化点の追跡」は、データが蓄積されていることを前提にしています。セッションベースのAIには、このコンテキストを持つ仕組みがありません。

インシデントが発生したとき、最初に問われるのは「誰がどう判断したか」です。AIの出力は参考情報であり、意思決定のログとしては機能しません。責任が固定される場所が必要であり、それは運用基盤の役割です。

「SaaS is dead」という言葉が出てきています。AIがあれば専用UIや機能は不要になるのでは——という問いかけです。

この見方には一面の正しさがあります。設問生成や文面作成のための「入力画面」としてのSaaSの価値は、確かに相対的に下がっていきます。AIが担えるからです。

どこまで正しいか。「生成インターフェースとしてのSaaS」は、確かに問い直されます。

どこが抜けているか。「運用・責任を固定する場所」としてのSaaSは、むしろAIが普及するほど必要になります。

これからのSaaSに求められるのは、「信頼できるデータ基盤（System of Record）」としての役割です。SaaSは入力画面ではなく、責任を固定する場所です。後から説明できる形で、判断の記録を残す装置です。

誰が、いつ、何を確認したか。どの委託先が回答済みで、どこがまだか。過去3年間の回答履歴はどうなっているか。どの項目に改善要求を出し、その後どうなったか——こうした記録が一元的に蓄積され、必要なときに取り出せる状態。それがSaaSの本質的な役割になっていきます。

AIは生成と対話が得意です。SaaSは記録と統制が得意です。この役割分担がAI時代のインフラの正しい形です。

現時点での役割分担を整理すると、以下になります。

• チェックシートのドラフト生成
• 依頼メールの文面作成
• 回答内容の一次要約・不備スクリーニング
• 設問の追加・改訂案の提示

• 送付先リストの管理と一括送信
• 回収状況のリアルタイム可視化
• 未回答者への自動リマインド
• 回答履歴の蓄積と過去比較
• 担当者・承認者の記録
• 指摘事項の履歴管理

• 調査項目の最終確定
• リスク許容度の判断
• 回答内容の最終評価
• 改善要求の意思決定
• 監査対応時の説明

この3層が機能することで、AIが効率化した部分をSaaSが管理し、人間が責任を取るという構造が成立します。

AIはチェックシート業務を大きく変えます。特に「作る」工程の効率化は、今後さらに進むでしょう。

ここに逆説があります。生成が簡単になるほど、管理がボトルネックになります。AIを使えば使うほど、運用の重要性は上がります。AIで作れるようになったからこそ、チェックシートの数は確実に増えます。今まで面倒で後回しにしていた確認が、一気に量として顕在化します。

作成は一瞬になっても、回収は待つしかありません。文面の生成は自動化されても、誰がいつ何を判断したかの記録は残さなければなりません。AIが普及するほど、その出力を管理する基盤の価値が上がっていきます。

AIはツールです。SaaSはインフラです。

AIを使うだけでは業務は完結しません。回せる仕組みがなければ、増えたチェックシートの分だけ運用が積み上がって止まります。マモリスは、送付・回収・進捗管理・履歴の蓄積・承認記録を担う基盤として設計されています。AIが作った分を、実務として回すための仕組みです。

AIを使いこなすためにこそ、その出力を管理する基盤が必要になる構造になっています。