ISMSの運用を、GitHub×Claudeで“ラクで楽しい”ものにする【前編】

ISMS運用、正直しんどくないですか

ISMS（情報セキュリティマネジメントシステム）を運用していると、文書の更新履歴が追えなくなったり、誰がいつどの規程を直したのか分からなくなったりすることがあります。ExcelやWordで管理していると、バージョン違いのファイルが増え、監査前になって「どれが最新か分からない」という事態になりがちです。担当者が変わるたびに引き継ぎ資料を作る負担も大きく、正直なところ「またこの作業か」と気が重くなる方も多いのではないでしょうか。

業務効率化の本質的な考え方を学びたい方はこちら → AI時代でも変わらない、業務自動化・効率化の本質的な考え方

この記事でできるようになること

本記事の前編では、GitHubを文書のバージョン管理基盤として使い、Claudeを文書レビューのパートナーとして組み込む、基本的な環境構築を行います。ISMS文書をGitHubで管理すれば、変更履歴が自動で残り、誰が何をいつ変えたかが一目で分かるようになります。後編では承認フローの自動化まで踏み込みますが、今回はまず土台作りに絞ります。

ステップ1：ISMS文書をGitHubリポジトリ化する

まずはプライベートリポジトリを1つ作成します。既存の規程集・手順書・記録類をMarkdownまたはテキストファイルに変換し、フォルダごとに整理してコミットします。Wordのまま管理していた場合は、この変換作業が最初の関門です。ここは正直少し面倒ですが、一度Markdown化してしまえば、以降の更新はテキスト編集だけで済むようになります。

ステップ2：文書構成とディレクトリ設計

次にディレクトリ構成を決めます。例えば以下のような分け方が扱いやすいです。

• policies/（基本方針・規程）
• procedures/（手順書）
• records/（実施記録）
• risk-assessment/（リスクアセスメント関連）

最初から完璧な構成を目指す必要はありません。運用しながら調整していくくらいの気持ちで始めるのが個人的には楽でした。

ステップ3：Claudeで文書レビュー・整合性チェックをする

リポジトリ内の文書をClaudeに読み込ませ、規程間の矛盾や表記の揺れをチェックしてもらいます。たとえば「アクセス権限の見直し頻度」が規程Aでは年1回、手順書Bでは半年ごとと書かれていた場合、こうした不整合を人手で見つけるのは意外と骨が折れます。Claudeに複数文書を渡して「用語や運用ルールの矛盾点を指摘して」と依頼すると、こうしたズレを素早く見つけてくれます。

Claudeの活用方法についてはこちらで詳しく解説しています → Claudeの使用履歴機能を業務効率化・副業管理に活かす実践ステップ

ステップ4：修正案をブランチで管理する

Claudeの指摘を受けて修正する際は、GitHub上でブランチを切ってから編集するようにしましょう。直接メインブランチを書き換えてしまうと、後から「どの指摘に対応した修正か」が分かりにくくなります。ブランチ名に「fix-access-policy-frequency」のように内容が分かる名前を付けておくと、後編で紹介する承認フローとの連携もスムーズになります。

つまずきやすいポイントと対処

最初に戸惑いやすいのは、GitHubの操作そのものに慣れていない場合です。コマンド操作が不安な方は、GitHub Desktopのようなアプリを使うと、ブランチ作成やコミットが視覚的に行えて負担が減ります。もう一つの落とし穴は、Claudeに文書を渡す際に機密情報を含んだまま貼り付けてしまうことです。個人情報や取引先名などが含まれる記録類は、渡す前に伏字にするか、テスト用のダミーデータに置き換える運用ルールを最初に決めておくと安心です。

まとめ

前編では、ISMS文書をGitHubで管理し、Claudeで整合性チェックを行う基本の流れを紹介しました。文書管理を「探す・見比べる」作業から解放するだけで、ISMS運用に対する心理的なハードルはかなり下がります。後編では、プルリクエストを使った承認フローの自動化や、Claude Projectsを使った運用ルールの質問対応まで掘り下げていきます。まずは今回の環境構築だけでも試してみてはいかがでしょうか。