コーポレートエンジニアの @sion_cojp です。
この記事では、ISMS関連の文書を Google Docs から GitHub に移行した理由と運用方法 について紹介します。
ISMSで管理する文書とは？
ISMS（Information Security Management System）は、情報セキュリティを組織として継続的に管理・運用するための仕組みです。
ISO/IEC 27001（JIS Q 27001）は、そのISMSをどのように構築・運用・改善していくべきかを定めた規格になります。
例えば、規格では「付属書A 9.4.5 プログラムソースコードへのアクセス制御」が要求事項として定められており、これに対応する形で社内文書には「ソースコードのアクセスおよび管理方法」を記載します。
ISMS というと「文書が多い」「運用が大変」というイメージを持たれがちですが、本質は 文書を作ることではなく、運用を属人化させず、継続的に改善できる状態を作ることにあります。
私たちの組織では、その実現手段としてISMS 関連文書をGitHubに移行するという判断をしました。
なぜGitHubに移行したのか？
1. 議論の履歴が残らない問題
Google Docsでは「提案モード」でコメントしながら議論を進めていました。
しかし、提案を承認するとコメントが非表示になり、「いつ、どんな議論を経て修正されたのか」が追えなくなっていました。
さらにコメントの表示上限もあり、過去の議論を遡れない問題があります。
GitHubではPull Requestで修正を提案できるため、議論内容と変更履歴を同時に可視化できます。
2. 誰が起案・レビューしたのか分からない
Google Docsの提案を承認すると、「誰が提案したか」「誰がレビューしたか」が履歴に残りません。
コーポレートガバナンスの観点からもこれは望ましくありません。
GitHubではPull Requestにより、起案者・レビュアー・承認者が明確に記録されます。
3. 改善提案が残しづらい
Google DocsにはIssue機能がないため、「こう改善したら良いかも」という軽い提案を残す場所がありません。
結果として「それ前に議論したんだよね」ということがよく起きていました。
GitHubではIssueを使って、改善提案や議論の履歴を蓄積できます。
4. 文書のバージョン管理が難しい
ISMS文書では「どんな改訂を行ったか」を明確に記録する必要があります。
しかしGoogle Docsでは、修正のたびにバージョン名を更新し、修正ハイライトを追記する必要がありました。
これは特に大規模修正時に手間がかかります。
GitHubならPull Requestとリリースタグで管理できるため、コピーを作る必要もなく、コミットログから修正内容を追跡可能です。
5. 会社の主要ドキュメントツールがNotion
カミナシの主要なドキュメント管理ツールはNotionです。
Google DocsはNotion検索の対象外のため、情報が分断されてしまいます。
そこで、GitHubで管理したMarkdownをNotionに自動同期する仕組みを作りました。
これにより、統一されたドキュメント検索が可能になります。
GitHub移行と運用の流れ
既存文書をMarkdown化してpush
Google DocsをMarkdownとしてエクスポートしましたが、一部が独自形式になっていたため、手作業で標準Markdownに整形。
整えた上で、GitHubにすべてpushしました。
GitHub ActionsでNotionへ自動同期
「GitHubのアカウントを持っていない社員も閲覧できるようにしたい」
「Notion上で全社的に検索できるようにしたい」
という要望を満たすため、MarkdownをNotionへ自動転記するOSSを開発しました。
GitHub Actionsでは .github/workflows/deploy_ms_manual.yml に次のような設定を行っています。
（mainブランチにマージされたら、MSマニュアルをNotionへ同期する例）
name: Update Notion page from Markdown on: push: branches: [ main ] paths: - 'docs/MSマニュアル.md' workflow_dispatch: permissions: contents: read jobs: DeleteAllBlocksMSManual: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v4 - name: Install go-markdown-to-notion run: | curl -L https://github.com/sioncojp/go-markdown-to-notion/releases/download/v1.0.2/go-markdown-to-notion_Linux_x86_64.tar.gz -o go-markdown-to-notion.tar.gz tar -xzf go-markdown-to-notion.tar.gz chmod +x go-markdown-to-notion mkdir -p $HOME/.local/bin mv go-markdown-to-notion $HOME/.local/bin/ echo "$HOME/.local/bin" >> $GITHUB_PATH - name: Delete All block in Notion page id: delete_blocks env: NOTION_API_TOKEN: ${{ secrets.NOTION_API_TOKEN }} # Notionのインテグレーショントークン NOTION_PAGE_ID: "xxxxxxxxxxx" # 上書き対象ブロックID run: go-markdown-to-notion delete-all-blocks --notion-page-or-block-id ${NOTION_PAGE_ID} UploadMSManual: needs: [DeleteAllBlocksMSManual] runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v4 - name: Install go-markdown-to-notion run: | curl -L https://github.com/sioncojp/go-markdown-to-notion/releases/download/v1.0.2/go-markdown-to-notion_Linux_x86_64.tar.gz -o go-markdown-to-notion.tar.gz tar -xzf go-markdown-to-notion.tar.gz chmod +x go-markdown-to-notion mkdir -p $HOME/.local/bin mv go-markdown-to-notion $HOME/.local/bin/ echo "$HOME/.local/bin" >> $GITHUB_PATH - name: Insert Markdown to Notion page env: NOTION_API_TOKEN: ${{ secrets.NOTION_API_TOKEN }} # Notionのインテグレーショントークン NOTION_PAGE_ID: "xxxxxxxxxxx" # 上書き対象ブロックID MD_FILE: docs/MSマニュアル.md # 監視対象のMarkdownファイル run: go-markdown-to-notion upload --notion-page-or-block-id ${NOTION_PAGE_ID} --source-md-filepath ${MD_FILE} --is-add-table-of-contents
Notionのメリットは「リッチな見た目に表示できること」なので、
h1, h2…タグは色をつけたり、--is-add-table-of-contents` オプションをつけると先頭に目次をつけれるなど、リッチ化できる実装もしてます。
Issueによる議論とタスク管理
やるべきことや議論したいことはすべてIssueで管理。
非同期に議論を進められるうえ、ISMS更新タスクをIssueテンプレート化することで、「何を」「いつまでに」行うかが明確になりました。
移行したことのその他のメリット
法令改訂時の差分が明確に見える
法令管理台帳という、会社を運営するために関係する法令をまとめた台帳があります。
e-Gov（https://laws.e-gov.go.jp/）から法令を取得し、GitHubで管理。Pull Requestで更新内容を差分表示できるようにしました。
変更箇所だけを確認できるので、どの条文が変わったか一目で把握できるようになりました。
また、PR上で「この改訂に伴う社内対応は？」という議論も残せるため、レビューや承認がスムーズになりました。
Copilotやlinterによるサポート
GitHub Copilotによる補完が地味に便利です。
Markdownのフォーマットチェックや自動整形も可能で、ドキュメントの品質を保ちやすくなりました。
今後の課題
「文書」は全て移行できましたが、大半の「台帳」はGitHubに移してません。
例えば、情報資産管理台帳のように頻繁に更新されるものは、現状ではスプレッドシートでの管理が適しています。
スプレッドシート間で参照関係（いわゆるFOREIGN KEY）を持てないため、1カラム変更で全シート修正が必要になる点はスプレッドシートの課題です。
この領域も今後改善していきたいと考えています。
まとめ
GitHubを使った文書管理は、
- 変更履歴の透明性
- 議論の可視化
- バージョン管理の効率化
- Notionとの同期・連携
といった点で非常に効果的でした。
みなさんもぜひ、GitHubを活用したコーポレートドキュメント管理に挑戦してみてください！
