「取引先から ISMS 取得を条件にされたが、認証だけ取ればいいのか、それとも実運用が回る体制まで作るべきなのか判断できない」「情報セキュリティ規程は書いたが、現場では誰も守っていない状態が続いている」「3 年後の更新審査までに規程がすでに陳腐化しそうで不安」。ISMS (ISO 27001) 取得の相談を受けるとき、この 3 つは必ずと言っていいほど出てくる論点です。本記事は、AI 駆動開発のクリエイティブスタジオとして自社でも情報セキュリティ規程を運用している観点から、ISMS 取得を「認証を取る」のではなく「現場で回る規程を作る」ためのガイドとして整理しました。
結論: ISMS 取得は「認証を取る」より「現場で回る規程を作る」を主眼にする
先に結論を書きます。ISMS (ISO 27001) 取得を「認証を取ること」自体を目的にすると、書類だけ整えて認証が下りたあとに現場で誰も守らない、という状態に陥りがちです。取得を検討する段階で「認証取得後、3 年後の更新審査までに規程が現場で回っているか」を最初から意識して、規程・運用・教育をセットで設計するのが現実的な進め方です。
理由は 3 つあります。1 つ目は、ISMS の規程は 3 年ごとの更新審査で「規程どおりに運用されているか」を確認されるため、書類だけ整えても更新のタイミングで必ず矛盾が出るという構造上の理由です。2 つ目は、取引先から取得を条件にされている場合でも、実際に取引先が求めているのは「認証マーク」ではなく「安心して情報を渡せる相手か」の確認なので、認証取得後に規程が陳腐化して情報漏えいを起こせば、取引そのものが打ち切りになるという事業上の理由です。3 つ目は、AI コーディングツールや生成 AI サービスを業務で使う環境では、モデル契約・データ保持ポリシーの変更が頻繁に起きるため、規程を作った時点で最新化を止めると数ヶ月で陳腐化するという実務上の理由です。
注意
ISMS 取得を「認証を取ること」だけに絞ると、認証取得後 6 ヶ月〜1 年で規程が現場と乖離し、3 年後の更新審査で大幅な作り直しが必要になります。取得検討時から「認証取得後の運用と 3 年更新までの規程育成」をセットで設計するのが、費用対効果の高い進め方です。
本記事では、まず ISMS と ISO 27001 の関係を整理し、そのうえで取得までの 4 ステップ、費用と期間の実案件レンジ、AI ツール利用時の規程整備、認証後の運用設計、と順に掘り下げます。P マーク (プライバシーマーク) 取得との違いや併用は P マーク 取得の進め方 にまとめる予定です。
ISMS とは何か - ISO 27001 との関係
ISMS (Information Security Management System) は情報セキュリティマネジメントシステムのことで、ISO/IEC 27001 は ISMS を構築・運用するための国際規格の名前です。実務では「ISMS 取得」と「ISO 27001 取得」はほぼ同じ意味で使われます。日本国内で認証を受ける場合は、国内認証機関 (JIPDEC、BSI、DNV など) が JIS Q 27001 (ISO 27001 の日本語版) をベースに審査を行います。
ISMS の対象は「情報資産」全般で、顧客データ・従業員データ・ソースコード・業務システム・SaaS・クラウド環境・オフィス機器などが含まれます。P マーク (プライバシーマーク) が個人情報保護に特化しているのに対し、ISMS は情報セキュリティ全体をカバーする点が違いです。
取引先要件で ISMS 取得が求められる典型例は次のとおりです。
- 官公庁・自治体との取引で情報セキュリティ体制の証明が必要
- 金融機関・保険会社と業務委託契約を結ぶ際に ISMS 保有が条件
- SaaS 事業で大手企業に販売する際にセキュリティチェックシートで ISMS 保有を求められる
- IPO 準備段階で監査法人から情報セキュリティ体制の証明を求められる
取得までの 4 ステップと期間の目安
ISMS 取得までの標準的な進め方は次の 4 ステップです。
ステップ 1: 現状ヒアリング・情報資産棚卸し (3〜4 週間)
最初に行うのは、社内の情報資産と業務フローの棚卸しです。ここが後工程の設計を左右する最重要フェーズで、資産の量と現状把握の粗さがそのまま全体期間に響きます。
具体的な作業は次のとおりです。
- 情報資産の洗い出し (顧客データ・従業員データ・ソースコード・SaaS 契約・クラウド環境)
- 業務フローと情報の流れの可視化
- 既存規程・手順書の棚卸し
- ISMS 適用範囲 (全社 or 事業部単位) の決定
- 経営層のコミットメント確認 (Information Security Management Committee の設置)
適用範囲を全社にするか事業部単位にするかは、取得目的で決めます。取引先要件が特定事業のみに関するなら事業部単位に絞る方が期間と費用を圧縮できます。IPO 準備なら全社を推奨します。
ステップ 2: リスクアセスメントと規程整備 (6〜10 週間)
情報資産のリスク評価を行い、必要な管理策を選定して、規程・手順書のドラフトを作成します。ここでの規程作成が「書類だけの規程」で終わるか「現場で回る規程」になるかの分かれ目です。
必要な規程・手順書の例:
- 情報セキュリティ基本方針
- 情報資産管理規程
- アクセス制御規程
- クラウドサービス利用規程
- AI ツール利用ガイドライン (Claude Code / Codex / Cursor 等の業務利用)
- インシデント対応手順
- 内部監査規程
- 従業員教育規程
AI コーディングツールを業務利用する企業では、「AI ツール利用ガイドライン」を明示的に整備することを強く推奨します。次節で詳しく扱います。
ステップ 3: 内部監査と是正 (3〜4 週間)
整備した規程が現場で回るかを内部監査で確認します。ここで「規程は作ったが実際には守られていない」箇所を洗い出し、認証審査前に是正します。内部監査を軽視して認証審査に臨むと、外部審査で不備が指摘されて是正に追加期間がかかることがよくあります。
内部監査で確認する主要項目:
- 情報資産一覧が更新されているか
- アクセス権が退職者削除まで含めて運用されているか
- インシデント発生時の連絡フローが実際に動くか
- 従業員教育の受講記録が残っているか
- クラウドサービスと AI ツールの利用状況が把握されているか
ステップ 4: 認証審査対応 (4〜8 週間)
第三者認証機関の審査は Stage 1 (書類審査) と Stage 2 (現地審査) の 2 段階で行われます。Stage 1 で規程・記録の整備状況を確認し、Stage 2 で現場での運用状況を確認します。
審査で指摘事項が出た場合、是正計画を提出して 30〜60 日以内に是正を完了させる必要があります。是正が完了すると認証書が発行されます。
FIXIT書類は入り口です。判断の軸は、規程どおりに運用されているかを 3 年後の更新審査で証明できるかです。
Tsukasa書類だけで取ると、更新のたびに規程を作り直すことになります。それが結局、専門コンサル会社の高い顧問料につながっています。
FIXITじゃあ最初から、更新までを見据えて作るってこと？
Tsukasaはい。取得と運用を切り分けず、一貫した設計にすることで、3 年後の更新審査で大きな作り直しを避けられます。
費用と期間の実案件レンジ
実案件で見えている費用と期間のレンジは次のとおりです。
| 会社規模 | 期間 | 取得伴走費用 (税抜) | 認証機関の審査費用 |
|---|---|---|---|
| 中小企業 (〜50 名) | 4〜5 ヶ月 | 100〜150 万円 | 50〜80 万円 |
| 中堅企業 (50〜200 名) | 5〜7 ヶ月 | 150〜250 万円 | 80〜120 万円 |
| 中堅企業 (200〜500 名) | 7〜8 ヶ月 | 200〜300 万円 | 100〜150 万円 |
上記は自社完結型のスタジオ (FIXIT のような形態) での実案件レンジです。専門コンサル会社に依頼した場合は、伴走費用が 300〜700 万円と 2〜3 倍のレンジになることが一般的です。理由は、専門コンサル会社では ISMS 専門家の月額単価が高く、案件担当者と ISMS 認証審査員が別々についてマージンが積み上がるためです。
取得後の運用サポート (顧問型) の月額は次のレンジです。
- 中小企業: 月額 10〜15 万円
- 中堅企業: 月額 15〜30 万円
顧問契約には、定期監査 (半年ごと)・規程見直し (年 1 回)・インシデント対応・3 年ごとの更新審査対応が含まれるのが標準です。専門コンサル会社の顧問月額は 30〜80 万円のレンジなので、自社完結型では 3 分の 1 から半分程度で提供できます。
AI コーディングツール利用と ISMS の相互作用
Claude Code、OpenAI Codex、Cursor、GitHub Copilot などの AI コーディングツールを業務で利用している場合、ISMS 規程に AI ツール特有の論点を明示的に組み込む必要があります。ここは 2026 年に入って急速に重要度が上がっている領域で、多くの ISMS コンサル会社がまだ対応しきれていません。
モデルベンダーとのデータ保持契約
Anthropic の ZDR (Zero Data Retention) や OpenAI Enterprise Retention Controls といったモデルベンダーとの契約は、ISMS の「委託先管理」規程に含めます。特に 2026 年 6 月 9 日に発効した Anthropic Mythos 5 系ポリシーで、ZDR 契約でも Mythos 5 系モデル経由のリクエストは 30 日間保持される扱いになった点は重要です。「ZDR を結んだから安心」という前提を規程に書き込むと、監査時に実態と乖離してしまいます。
詳しい経緯と実務判断は Claude Code vs Codex 実務比較 2026 にまとめています。金融・保険・医療のように保持ゼロを求められる案件では、Mythos 5 系を回避する運用や、オンプレミス・エアギャップ運用の選択肢を規程に組み込みます。
社内 AI 利用ガイドライン
AI ツール利用ガイドラインとして規程に含めるべき論点は次のとおりです。
- どのモデル (Claude / GPT / Gemini) をどの業務で使ってよいか
- 顧客データ・機密情報を AI に渡してよいか、どこまで渡してよいか
- AI が生成したコード・ドキュメントのレビュー・承認フロー
- AI 利用ログの記録と保持期間
- 生成 AI サービスの新規追加時の承認フロー
AI 生成コードのレビュー体制
情報セキュリティの観点で AI 生成コードには特有のリスクがあります。既存コードの規約から逸脱した実装・暗号化ライブラリの誤用・認証情報のハードコーディング・セキュリティホールを含む依存パッケージの推薦、といった論点です。これらを AI 駆動 TDD (AI 駆動 TDD) のような形でレビュー体制に組み込みます。
認証取得後の運用と 3 年更新への備え
認証取得はゴールではなく、そこからが本番です。取得後 3 年間に必要な運用は次のとおりです。
定期監査 (半年ごと)
情報資産一覧の更新、アクセス権のレビュー、インシデント対応の実施状況、AI ツール利用状況、を半年ごとに監査します。監査結果は経営層に報告し、改善策を実行します。
規程の見直し (年 1 回)
年 1 回、規程全体を見直します。特に AI ツールやクラウドサービスの追加・変更、法令改正、ベンダー契約の変更、といった外部要因の変化を反映します。
インシデント対応
情報セキュリティインシデント (情報漏えい・システム侵入・マルウェア感染など) が発生した場合の対応フローを、規程に基づいて実行します。実際にインシデントが発生していなくても、年に 1〜2 回は対応訓練を実施します。
3 年ごとの更新審査
3 年目の認証有効期限前に、更新審査を受けます。ここで規程が現場で回っていることが証明できれば、追加費用と期間を最小限で更新できます。逆に、規程と実態が乖離していると、再取得に近い工数と費用がかかります。
失敗を避けるチェックリスト
ISMS 取得と運用で、事前に確認しておくべき論点を整理します。
- 取得目的を「認証取得」ではなく「3 年後の更新審査まで規程が回る状態」に置いているか
- 適用範囲 (全社 or 事業部単位) を取得目的から逆算して決めているか
- 情報資産棚卸しに 3〜4 週間の期間を確保できているか
- 経営層のコミットメントが最初の段階で得られているか
- AI コーディングツール・生成 AI サービスの利用ガイドラインを規程に組み込んでいるか
- モデルベンダーとの契約 (ZDR、Enterprise Retention) の実態を規程に反映しているか
- 認証取得後の運用サポート (顧問契約) を予算化しているか
- 3 年ごとの更新審査の予算と期間を長期計画に含めているか
これらを満たしたうえで、ISMS 取得は「取得の伴走」と「取得後の運用サポート」を同じチームで一貫して回せる会社に依頼するのが、費用対効果の高い進め方です。
ISMS 取得のご相談
「取引先要件で ISMS 取得を進める必要が出てきた」「認証だけ取るのではなく、実運用が回る規程を作りたい」「AI コーディングツール利用を規程に組み込みたいが、対応できるコンサル会社が見つからない」といった状況こそ、AI 駆動開発のクリエイティブスタジオが伴走できる領域です。まずは ISMS 取得サポートのサービス内容 をご覧いただき、お問い合わせ からお気軽にご相談ください。