認証準備をSecureframeに任せる範囲｜証跡と方針文書を確かめる線

「取引先から情報セキュリティの認証を取ってほしいと言われたが、担当は兼務の1人しかいない」「証跡集めも方針文書もAIが作ってくれるなら、審査もそのまま通るのでは」——認証の取得を急に任された情報システムや管理部門の担当者から、よく聞く二つの声です。前の声は人手の話で、後の声は期待の話です。ただ、論点はAIに準備を任せられるかどうかではありません。審査で問われるのは、書類がそろっているかより、書いたとおりに会社が動いていると人が説明できるかです。この記事では、米国の認証準備の自動化製品 Secureframe を例に、AIと自動化に任せてよい範囲と、人が確かめる証跡と方針文書の線を整理します。

Secureframe は、認証の取得と維持の準備を自動化する米国の製品

Secureframe は、企業が情報セキュリティの認証や報告書を取得し、その後も維持していくための準備を自動化する製品です。2026年10月時点の公式サイトは、SOC 2、ISO 27001、クレジットカード業界の基準である PCI DSS、米国の NIST の枠組みなど、複数の基準を一つの画面で扱えるとしています。

中心にあるのは、社内のシステムとの連携です。ISO 27001 の製品ページによれば、クラウド、人事、端末の管理などの150を超える連携を通じて、設定や記録を自動で集め、統制が守られているかを続けて点検します。点検に落ちた項目は一覧に並び、直し方の案が示されます。

そのうえに、Comply AI と呼ばれるAI機能が載っています。是正の手順の案、リスク評価の項目の下書き、取引先から届くセキュリティの質問票への回答案、方針文書の編集の支援などです。どれも「下書きを出す」機能で、決めるのは利用者の側という作りになっています。

なお、認証を持っている会社が生成AIを社内で使えるかという問いは、すでに別の記事で扱っています。本稿は向きが逆で、認証の準備そのものをAIに任せるときの話に絞ります。

作っている会社と、国内でまだ知られていない理由

公式の会社ページによれば、Secureframe は2020年に創業し、サンフランシスコ、ニューヨーク、オースティン、デンバー、トロント、ロンドンに社員が分散している会社です。調達の総額は7,900万ドルと記され、出資者には Kleiner Perkins などの名前が並びます。公式トップでは、社内の専門家と元監査人が30人を超えると紹介しています。

国内でまだ知られていない理由は、確かめた範囲で三つあります。一つ目は、画面と資料が英語で、日本語への対応が公式サイトに書かれていないことです。方針文書の編集支援の翻訳先として挙がっているのも、スペイン語・フランス語・ドイツ語・イタリア語・オランダ語で、日本語は含まれていません。

二つ目は、扱う基準の重心が米国にあることです。公式サイトは、米国の国防調達のサイバーセキュリティ基準への対応を大きく打ち出しています。三つ目は、日本の認証の仕組みとの関係です。国内で ISO 27001 の認証を取るときは、認定を受けた認証機関が審査を行いますが、Secureframe が国内の認証機関とどう連携するかは、公式の資料では確かめられませんでした。

したがって国内の会社が検討するなら、日本語の方針文書の扱い、国内の認証機関の審査で出力を使えるか、データの保存場所を、最初に提供元へ確かめる項目として扱います。本稿ではその確認が済んだ前提で、何を任せ、何を人が持つかを整理します。

2026年10月時点のAI機能と、データの扱い

公式ヘルプの「AI機能の概要」には、AIを使う機能が並び、それぞれの役割とデータの扱いが書かれています。主なものを、人が残る所と合わせて表にします。

機能	中身（公式で確かめた範囲）	人が残る所
是正の支援	点検に落ちたクラウドの項目について、直し方を対話で示し、設定を直すコードの案も出す	本番の環境に当てるかの判断と、変更の承認
証跡の点検	上げた証跡の書類に不足や問題がないか、12か月以内の日付かを確かめる	証跡が実態を表しているかの突き合わせ
リスク評価の下書き	リスクの分類、機密性・完全性・可用性の評価、対応、影響と起こりやすさを根拠つきで埋める	評価の確定と、リスクを受け入れる判断
質問票の回答案	社内の知識の蓄積と方針文書を使って回答を下書きし、使った出典を回答ごとに残す	取引先に出す前の確認と、約束になる回答の承認
方針文書の編集支援	選んだ文の要約・言い換え・簡潔化・口調の変更・翻訳	方針の中身の決定と承認
MCP サーバー	社外のAIアシスタントから統制データを読み書きする	書き込みを許す人と操作の範囲

データの扱いについて、ヘルプは次のように説明しています。AI機能は OpenAI のモデルを API 経由で使い、Secureframe 自身はモデルを学習させたり、調整したり、運用したりしない。データはAI機能を使うときにだけ、作業に必要な最小限を送る。顧客のデータは同社の AWS の環境に、顧客ごとに論理的に分けて保存する、というものです。

気をつけたいのは、Comply AI は既定で有効になっていて、会社の管理者がいつでも無効にできるという点です。質問票のAIを使うには、OpenAI へのデータ共有を別に承認する必要があります。取引先審査の機能については OpenAI と学習への利用を禁じる契約があると書かれていますが、他の機能の契約上の扱いは同じページでは確かめられませんでした。導入の最初に、どの機能を有効のまま使うかを決めます。

認証の準備が重い3つの所：証跡・方針文書・是正

認証の準備が担当者1人で回らなくなる所は、だいたい決まっています。一つ目は証跡です。アカウントの棚卸し、退職者の権限の削除、端末の暗号化、ログの保存、バックアップの確認など、統制が動いている跡を一つずつ集めるだけで、何週間もかかります。

二つ目は方針文書です。情報セキュリティの基本方針から、アクセス管理、事故の対応、取引先の管理、事業の継続まで、ISO 27001 の認証では、管理策に合わせた文書を一通りそろえることが求められます。白紙から書けば、それだけで担当者の手が止まります。

三つ目は是正です。点検で見つかった穴を直すには、クラウドの設定、人事の手続き、社員の研修など、情報システムの部門だけでは閉じない作業が続きます。是正は担当者が書類の上で直すものではなく、現場の誰かが実際に動いて初めて終わるものです。

Secureframe のような製品は、この三つのそれぞれに自動化とAIを当てています。証跡は連携で集め、文書は雛形とAIの編集支援で下書きし、是正はAIが直し方の案を出します。どれも担当者の手を大きく減らしますが、三つとも最後の一歩は人の側に残る、という点を次の節から見ていきます。

AIと自動化に任せられる範囲

任せてよい範囲は、「集める」「下書きする」「見つける」の三つに分けると整理しやすくなります。集めるのは、連携した仕組みから設定や記録を取り出す作業です。人が画面を撮って貼るより正確で、続けて点検できる利点があります。

下書きするのは、方針文書・リスク評価・質問票の回答・是正の手順の案です。公式の ISO 27001 のページは、社内の専門家と元監査人が作った方針文書の雛形を用意していると説明しています。雛形とAIの編集支援を使えば、白紙から書く時間は減りますが、自社の実態に合わせて直す時間は残ります。

見つけるのは、点検に落ちた統制、古くなった証跡、足りない書類を拾い出す作業です。公式は2025年5月に、AIが証跡の書類を点検し、不足や古い日付を審査の前に知らせる機能を発表しています。

反対に、任せてはいけないのは、何を方針として約束するかを決めること、下書きが実態と合っているかを確かめること、リスクを受け入れるかを決めること、審査員の質問に答えることです。この四つは、認証の責任者の名前で決めると最初に書いておくと、道具が増えても線が動きません。

AIが書いた方針文書が審査で困る型

方針文書の下書きをAIや雛形に頼ると、見た目の整った文書が短い時間でそろいます。困るのは、その文書が自社の実態とずれているときです。審査では、文書に書いたことが実際に行われているかを、記録と聞き取りで確かめられます。

• 雛形にあった「パスワードは90日ごとに変更」を残したまま、実際は多要素認証に切り替えて定期変更をやめている
• 「全社員に年2回の研修」と書いたが、研修の記録は年1回分しかない
• 持ち込み端末の利用を禁じると書いたが、営業部門では私物のスマートフォンで社内のチャットを使っている
• 取引先の評価を年1回と書いたが、評価の担当者が決まっていない
• 事故の連絡先に、すでに退職した担当者の名前が残っている

どれも、文書の出来が悪いから起きる失敗ではありません。文書が会社の動きより先に書かれ、誰も突き合わせなかったときに起きる失敗です。AIの文章が上手になるほど、ずれは目立たなくなり、審査の場で初めて見つかります。

もう一つの型は、誰も説明できない文書です。審査員から「なぜこの頻度にしたのか」「この管理策を対象外にした理由は」と聞かれたとき、AIが書いたのでと答えるわけにはいきません。文書の一行ごとに、なぜそう決めたかを説明できる人がいる状態にしてから審査に臨みます。

方針文書の持ち主と承認を決める

ずれと説明不能を防ぐには、方針文書ごとに持ち主を決めます。持ち主は、その文書に書かれたことを実際に回している部門の責任者です。アクセス管理なら情報システム、採用と退職の手続きなら人事、取引先の管理なら購買や法務、といった具合です。

下書きはAIと雛形で作ってかまいませんが、持ち主が読んで、実態と違う所を直してから承認します。承認したら、日付と承認者を記録に残します。承認者が中身を読んでいない文書を、承認済みとして扱わないことを決まりにします。

方針文書の編集支援で言い回しを整えるのは、承認の前に行います。承認の後に文を整えると、意味が少しずつ変わることがあります。言い回しを変えたら、持ち主にもう一度見てもらう、という手順にしておくと安全です。

見直しの周期も決めます。組織変更、新しいクラウドの導入、事故の発生など、会社の動きが変わったときに文書が古くなります。年に一度の見直しに加えて、仕組みや体制が変わったときにも持ち主が文書を開くようにします。なお、公式ヘルプによれば、方針文書の機能は MCP の接続にはまだ出ていません。外のAIアシスタントから方針文書を書き換える経路は、2026年10月時点ではない、ということです。

自動で集めた証跡の確かめ方

連携で集めた証跡は、人が集めた証跡より正確なことが多いのですが、それでも確かめる所があります。いちばん大事なのは、連携の範囲に入っていない仕組みは、点検にも出てこないという点です。連携していないクラウドや、部門が独自に契約した道具の設定は、画面上では空白のまま、合格のように見えることがあります。

• 連携した仕組みの一覧が、認証の適用範囲に入る仕組みの一覧と一致しているか
• 部門が独自に契約した道具や、試しに使っている環境が抜けていないか
• 連携に使っているアカウントの権限が、読み取りに必要な範囲に収まっているか
• 手で上げた証跡の日付が、審査の対象の期間に入っているか
• 点検の結果が合格になっている項目について、合格の条件が自社の方針と合っているか
• 点検の対象から外した項目に、外した理由と承認者が残っているか

手で上げる書類の証跡には、AIの点検が使えます。公式ヘルプによれば、この機能は書類の不足や問題、会社が決めた確認の項目、日付が12か月以内かを点検します。ただし点検が見ているのは書類の形と中身の整合で、書類に書かれたことが本当に行われたかまでは見ていません。研修の受講記録が整っていても、受講した社員が内容を覚えているかは別の話です。

証跡の抜き取り確認も決めておきます。審査の前に、責任者がいくつかの証跡を選び、元の仕組みの画面と見比べます。全部ではなく抜き取りでかまいません。連携が途中で切れていた、権限の変更で一部の記録が取れていなかった、といったことは、こうした確認で初めて見つかります。

是正の下書きを本番の環境に当てる前に

点検に落ちたクラウドの項目について、Comply AI は直し方を対話で示し、設定を直すコードの案も出します。公式の説明では、コマンドの形や設定の記述の形など、いくつかの書き方で案を出せるとされています。

ここで線を引くのは、案を出すまでがAI、本番の環境に当てるのは人、という所です。設定の変更は、他の仕組みに思わぬ影響を出すことがあります。たとえば、外からの接続を閉じる変更が、取引先とのデータのやり取りまで止めてしまう、といったことです。是正の案は、ふだんの変更管理の手順に乗せてから当てることを決まりにします。

変更管理に乗せるとは、変更の内容と影響を書き、承認者が承認し、試しの環境で確かめてから本番に当て、当てた記録を残すことです。認証の審査では、この変更管理の記録そのものが証跡になります。AIの案をそのまま本番に当てると、是正は済んでも変更管理の証跡が欠けることになり、別の穴を作ります。

是正の担当も決めます。クラウドの設定は情報システム、退職者の権限の削除は人事と情報システム、研修の未受講は各部門の上長、と担当が分かれます。点検の一覧を担当者1人で抱えず、項目ごとに直す人と期限を割り振ります。

リスク評価の下書きと、リスクを受け入れる判断

ISO 27001 の認証では、リスクを洗い出し、評価し、どう対応するかを決めることが求められます。公式ヘルプによれば、Comply AI はリスクの記述から、分類、機密性・完全性・可用性の評価、対応の方針、影響と起こりやすさの点数を、根拠つきで埋める機能を持っています。

この下書きは、空欄を埋める手間を大きく減らします。ただし点数は、会社の事業や取引先の事情を知らないAIが、記述の文面から推した値です。同じリスクでも、主要な取引先のデータを扱う部門と、社内の連絡にしか使わない部門では重さが違います。点数は出発点として使い、責任者が自社の物差しで直します。

いちばん人の側に残すべきなのは、リスクを受け入れる判断です。対策の費用が見合わないので受け入れる、という判断は、経営の判断です。リスクを受け入れる判断は、AIの下書きの欄を埋めるのではなく、責任者の名前と日付で残すようにします。

委託先や取引先のリスク評価にも、提出された報告書を読んで質問に答える自動の下読みがあります。公式ヘルプは、この機能が上位の契約に含まれる場合があると書いています。委託先の審査をAIに任せるときの線引きは別の記事で扱っているので、ここでは触れるだけにします。

AIアシスタントから MCP で統制データを扱わせる権限

Secureframe は、AIアシスタントから統制のデータを扱える、完全にホスト型の MCP サーバーの提供開始を公式のニュースルームで発表しています（発表の日付は公式のページでは確かめられませんでした）。Claude Desktop、Claude Code、Cursor などのAIアシスタントから、点検に落ちた統制、危険度の高い取引先、利用者や端末の状態などを問い合わせられます。

公式ブログによれば、この接続は100を超える操作を持ち、作成・更新・削除まで、API と同じ書き込みができます。ニュースルームでは、点検の状態を更新したり、改善の計画の項目を作ったりする例が挙がっています。読むだけの道具ではない、という点を押さえておきます。

権限の考え方は、ヘルプにはっきり書かれています。要求はすべて接続した利用者として動き、その利用者がもともと持っている権限を守る。公式ブログの言い方では、利用者が Secureframe で見られない物・変えられない物は、代わりに動くアシスタントも見られず変えられない、というものです。接続の方法は OAuth でのログインが勧められ、API の鍵での接続もできます。

つまり、アシスタントに許される範囲は、つないだ人の権限そのものです。管理者の権限を持つ人がつなげば、アシスタントも管理者と同じ範囲で書き換えられます。接続そのものの条件として、ヘルプは管理者であるか、API の鍵を作れる役割を持つことなどを挙げています。どの役割の人に接続を許すかを、道具を入れる前に決めておきます。

MCP で許す操作を、読む・書く・消すに分けて決める

MCP の接続を許すかどうかは、一律で決めるより、操作の種類で分けたほうが現実的です。読む操作は便利で害が少なく、書く操作は記録が変わり、消す操作は戻せないことがあるからです。

操作の区分	例	誰に許すか（目安）
読む	点検に落ちた統制の一覧、取引先の危険度、端末の状態を問い合わせる	統制の担当者と各部門の責任者
書く（状態の更新）	点検の状態を更新する、改善の計画の項目を作る、証跡を求める	認証の責任者と、指名した担当者だけ
消す・保管する	記録の削除や保管	原則として許さない。必要なときは画面で人が行う
接続の作成	OAuth や API の鍵でアシスタントをつなぐ	接続を許す人を名前で決め、一覧で持つ

書く操作を許すときに気をつけたいのは、審査の対象になる記録を、会話の流れの中で書き換えてしまうことです。点検の状態を「済み」に変えるのは、実際に直したことを人が確かめた後であるべきです。アシスタントが案を出し、人が画面で確かめてから状態を変える、という順番を守ります。

接続に使う鍵と記録も決めます。ヘルプは、API の秘密の値をパスワードと同じように扱うよう注意しています。アクセスの証明は1時間で切れ、自動で更新されるとも書かれています。接続している人の一覧と、アシスタント経由で変わった記録を、月に一度は人が見ることを決まりにします。接続の取り消しの操作はヘルプでは確かめられなかったため、導入の前に提供元に確かめます。

審査で人が説明すること

審査の場で道具が代わりに答えてくれることはありません。審査員が確かめるのは、方針を誰が決め、どう周知し、どう守られているかを示す記録と、担当者の説明です。準備をAIと自動化に任せたほど、説明の準備は意識して人が行う必要があります。

説明の準備で押さえたいのは、適用範囲、方針の決め方、リスクの受け入れ、是正の経緯の四つです。適用範囲は、どの部門・拠点・仕組みを対象にしたかと、その理由です。方針の決め方は、文書ごとの持ち主と承認の記録で示します。

リスクの受け入れは、受け入れたリスクと判断した人です。是正の経緯は、点検で見つかった穴をいつ誰がどう直したかで、変更管理の記録と合わせて示します。AIの下書きを使ったこと自体は隠す必要はありませんが、最後に決めた人が説明できることが前提です。

審査員から、自動の点検の仕組みそのものについて聞かれることもあります。どの仕組みと連携しているか、連携が切れたらどう気づくか、点検の結果を誰が見ているか、です。道具の画面を見せる前に、道具の外で決めた手順を説明できるようにしておくと、審査の場で慌てずに済みます。

止め方と、費用の増え方

導入の前に、止め方を決めておきます。止める場面は三つあります。AI機能だけを止める場面、MCP の接続を止める場面、製品そのものをやめる場面です。AI機能は、公式ヘルプによれば会社の管理者がいつでも無効にできます。

製品をやめるときに困るのは、集めた証跡と方針文書と点検の履歴です。認証は一度取って終わりではなく、更新の審査が続くので、やめた後も、過去の証跡と承認の記録を書き出して持てるかを契約の前に確かめます。書き出しの形と範囲は、公式の資料では確かめられませんでした。

費用は、扱う基準の数、連携する仕組みの数、取引先審査などの上位の機能を使うかで増えていく形が、この種の製品では多く見られます。料金の体系は公式サイトでは確かめられませんでした。二つ目の基準を足すとき、取引先が増えたときに費用がどう増えるかを、見積もりの段階で聞いておくと判断がしやすくなります。

よくある質問

AIで方針文書をそろえれば、審査に通りますか

文書がそろうことと、審査に通ることは別です。審査では、文書に書いたことが実際に行われているかを記録と聞き取りで確かめられます。下書きはAIと雛形で作ってかまいませんが、持ち主が実態と突き合わせて承認し、説明できる状態にしてください。

国内の ISO 27001 の認証の審査に使えますか

2026年10月時点の公式サイトでは、日本の認証機関との連携や、日本語の方針文書への対応は確かめられませんでした。証跡の収集や点検は基準を問わず役立ちますが、国内の審査で出力をどう使えるかは、提供元と認証機関の両方に先に確かめてください。

社内のデータが AI の学習に使われることはありますか

公式ヘルプは、Secureframe 自身はモデルを学習させず、OpenAI のモデルを API 経由で使うと説明しています。取引先審査の機能では学習への利用を禁じる契約があると書かれていますが、他の機能の契約の扱いは同じページで確かめられなかったため、契約の前に書面で確かめてください。

SOC 2 の報告書を受け取る側でも使えますか

本稿は認証を取る側の準備に絞りました。取引先から届いた報告書の読み方は別の記事で扱っています。

まとめ

Secureframe は、連携で証跡を集めて統制を続けて点検し、Comply AI が是正の案・リスク評価の下書き・質問票の回答案・方針文書の編集を支える製品です。2026年には、AIアシスタントから統制データを読み書きできるホスト型の MCP サーバーも公開されました。日本語への対応と国内の認証機関との関係は、公式の資料では確かめられませんでした。入れるなら、集める・下書きする・見つけるは道具に任せ、方針の決定と承認、実態との突き合わせ、リスクの受け入れ、審査での説明は人が持つ。方針文書には持ち主を付け、是正の案は変更管理に乗せてから当てる。MCP の接続は、読む・書く・消すに分けて許す人を決めてから開いてください。

• 製品の機能と提供の状態は、Secureframe の公式サイト（トップ・会社ページ・ISO 27001 のページ）、公式ヘルプ（AI機能の概要・MCP サーバー）、公式のニュースルームと公式ブログ（MCP サーバー・2025年5月16日の証跡の点検）を2026年10月26日に確かめた範囲に基づきます
• 日本での提供と日本語の対応、国内の認証機関との関係、料金の体系、記録の書き出し、MCP の接続の取り消しの操作は公式の資料で確かめられなかったため、契約の前に提供元に直接確かめてください

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。