Cursor×GitHubで規定の改訂を効率化してみた

はじめに

「規定の最新化、面倒だけど避けて通れない……生成AIが勝手にやってくれないかな」

社内規定の改訂業務は、地味ですが非常に重要な仕事です。
しかし複数人で協力して改訂作業を行うのは非常に骨が折れます。要件の変更に伴い、影響する規定の条文をExcelで横に並べて、整合性をとりながら修正したり、Wordの校閲機能で修正前後の変更を見比べたり、現実は「ExcelとWordの往復運動」となっていました。

「なんとかして生成AIを活用し、この苦痛から解放されたい」

最初に思いついたのは、Word ファイルを元データとしているため、Microsoft 365 Copilot を利用する方法でした。
しかし、実際に検討してみるといくつかの壁に直面しました。

1. 「書き出す」処理の難しさ:
   AI に修正案を出させることはできても、それを元ファイルの正しい位置に、正しい書式で反映させる（書き戻す）のは意外と困難でした。
2. コンテキスト整理の限界:
   「最新のガイドラインのこの条文やその他の要求事項を踏まえて、こちらの規定を直す」といった、複数文書にまたがる複雑な文脈（コンテキスト）や要求事項を、チャット欄だけで正確に指示し続けるのは骨が折れます。

そこで私たちが求めたのは、単なるチャットボットではなく、「文脈を深く理解し、修正を直接ファイルに書き込んでくれる」ツールでした。
その解として辿り着いたのが、「Cursor (AIエディタ) × GitHub」というエンジニアの開発フローを応用する方法です。

なぜ Cursor なのか？（選定理由）

私たちが Cursor を採用した理由は、単に「使い慣れているから」だけではありません。
「指示の書き込み（プロンプト）」「コンテキスト理解（Indexing）」「差分管理（Git）」の3点が、文書改訂業務に最適だったからです。

1. Indexing（ベクトル化）による深い理解:
   • 多数の文書を Indexing してベクトル化しておくことで、AI は質問のたびに関連性の高い文書を自動で探し出し、その内容を踏まえて回答できます。「最新のガイドラインや要求事項」と「既存の規定」の整合性を取るには、この機能が不可欠でした。難しい言い方をすると、社内文書を検索用のデータベースとして登録しておき、関連部分を引きながら文章を生成する RAG（Retrieval-Augmented Generation）的な使い方が、Cursor ではほぼそのまま実現できるイメージです。
2. 指示の書き込みと即時反映:
   • チャットで指示を出すだけでなく、エディタ上で直接修正内容を確認・編集できます。
3. Git による差分管理と共同作業:
   • 修正結果をそのまま Git で管理できるため、元の文章との差分（Diff）が明確になり、複数人でのレビューや並行作業が容易になります。

セキュリティ対策（Privacy Mode と Private Repository）

もちろん、Cursor と GitHub を利用するにあたってはセキュリティ対策が必須です。
Cursor を経由して生成 AI のエンドポイントに規定の情報等が送信されるため、これがモデルの学習に利用されないよう、Cursor 側で Privacy Mode を有効に設定し、データ利用を制限するよう配慮しています。

また、GitHub を利用する場合でも、社外に情報が公開されないよう、リポジトリを必ず Private（非公開） モードで管理し、アクセス権限も厳格にコントロールする必要があります。

方針と役割分担

• 人の判断: ガイドラインや要求事項の解釈、修正骨子の抽出、最終的な品質責任
• AIの作業: 文章の整形、規定への反映、整合性チェック（Cursor）
• Gitの管理: 変更履歴の一元管理と透明性の担保

生成 AI に基本は任せますが、嘘や幻覚（ハルシネーション）が起きていないか、最終的な成果物は必ず人が確認します。
修正が必要な場合も GitHub 上で PR（Pull Request）を作成し、Cursor 上でスムーズに修正サイクルを回します。

ワークフロー

1. 変更対象の規定を Markdown 化し、リポジトリに配置
2. 改訂の読解と反映対象の抽出（人が実施）
3. 抽出した修正骨子を章ごとに Markdown 化して整理
4. Cursor に章単位でコンテキストを与え、規定本文へ反映を依頼
   • 一度に与える文脈が多すぎる箇所は、章ごと・セクションごとに分割
   • 各文章について「修正要否」と修正文案の一次提案を依頼し、人が採否判断
5. 生成AIが提案した差分をそのまま Markdown に反映し、コミット
6. 複数人で内容の正しさをレビュー
7. PR の最終承認後、Git 上の差分をもとに Word 版の原本へ手動で反映し、正式な施行版として管理

ここで特に重要だったのが、最初の「Markdown 化」の設計です。Word で作られた規定は「章／節／条／項／号」そのものが意味を持つため、Markdown に落とすときもこの構造を壊さないことを最優先にしました。具体的には、次のようなルールを置いています。

• 見出しレベルの対応付け
  • 章・節・条・小見出しをそれぞれ #〜#### に対応付けつつ、元の番号とタイトルはそのままテキストで残しました。
    • 例：# １． はじめに、## １－１． 本規定の位置づけ、### １－３－１． 対象範囲、#### （１） xxの責務
• 図・表の扱い
  • 図は「図 １-１　本規定の位置づけと構成」のようなキャプション行だけをテキストで残し、実際の図は別管理としました。
  • 表は、可能なものだけ Markdown のテーブル構文に手作業で変換し、元の行・列構造を維持するようにしています。

なお、既存の自動変換ツールもいくつか試しましたが、条番号やインデント、箇条書きの構造が崩れてしまうケースが多かったため、初回の Markdown 化だけはあえて人手で行い、その後の改訂サイクルを Cursor と AI に任せる、という役割分担にしました。最終的な施行版そのものは従来どおり Word で管理しつつ、改訂プロセスと差分の見える化を Markdown＋Git に任せる、という二層構造で運用しています。

生成AIの使いどころ

• 文章単位の修正要否判定と初稿生成
• 修正骨子の規定本文への反映（文体・用語の統一も含む）
• 反映後のローカル整合性チェック（用語揺れ、参照の整合）
• 全体俯瞰の観点提示（「定義→本文→付録」のリンク切れ指摘 など）

注意点として、コンテキストが過大になると意図しない改変や拾い漏れが発生しやすいです。今回もコンテキストを章ごとに絞り、各章で完結に近い指示（「この章に修正骨子を反映して整合を取る」）を与えることで安定性を高めました。

生成AIの出力は高品質ですが、最終判断は人が行う前提で「AI→人→AI→人」と交互に品質を高めるサイクルを回しました。

実務で効いたコツ

• Cursor Rules（ルールファイル）の Git 管理
  • AI への指示（プロンプト）や振る舞いを、Cursor Rules 用のルールファイルに記述し、リポジトリで共有しました。
  • これにより、メンバーごとのプロンプトのバラつきを無くし、誰が操作しても一定の品質で出力されるようにしました。プロンプト自体も Git で改善履歴を追えます。
  • 規定改訂プロジェクト向けのルールファイルでは、「どのディレクトリが編集対象か／どのファイルは原本として参照のみか」といった前提条件を globs で明示しました。
  • あわせて、「条番号や見出し構造を勝手に変えない」「既存の用語・定義は必ず修正方針メモを確認してから触る」「本文に存在しない要件や定義を新たに作らない」といった禁止事項もルールとして書いておき、AI の暴走を防ぎました。
  • こうしたルールを Cursor Rules に集約しておくことで、新しいメンバーが参加したときも、「AI にどう振る舞ってほしいか」を毎回ゼロから説明せずに済みました。
  • 参考までに、実際に使っている Cursor Rules の抜粋は次のようなイメージです。

---
description: 規定改訂プロジェクト向けの Cursor ルール
globs:
  - "rules/**/*.md"
  - "comments/**/*.md"
  - "output/**/*.md"
---

## テキスト編集の方針

- 規定文は「章／節／条／項／号」の構造と条番号をできる限り維持し、勝手に再採番しない。
- 既存の用語や定義を変更する場合は、必ず修正方針メモ（comments/*.md）の意図を優先する。
- 本文に存在しない要件や定義を新たに作らない。

• GitHub Pull Requests 拡張機能の活用

  • エディタ（Cursor）に「GitHub Pull Requests」拡張機能を導入し、PR の差分確認やコメントをエディタ内で完結させました。
  • ブラウザを行き来せず、使い慣れたエディタの画面で左右に並べて差分（Diff）を確認できるため、レビュー効率が格段に上がりました。

• 章単位で完結するコンテキスト分割とコンテキスト使用率の監視

  • 長文を一度に読み込ませると、コンテキストが**圧縮（間引き）**されてしまい、細かい指示が無視されたり、幻覚（ハルシネーション）の原因になります。
  • コンテキストの上限は使用する LLM モデルや Cursor の設定によって異なります。
  • Cursor には長文を扱える機能（Max Mode など）もありますが、費用が高額になることから今回は使用せず、章ごとにコンテキストを分割し、Cursor 上のコンテキスト使用率（%）が 100% を超えないよう監視しながら作業を進めました。

これまで（Excel/Word＋SharePoint）と今回（Cursor×GitHub＋AI）の比較

観点	これまで：Excel/Word＋SharePoint	今回：Cursor×GitHub＋AI
改訂作業で扱う文書形式	Excel/Word（Word校閲・コメント、Excel修正案管理）	Markdown（テキスト/見出し構造）
版管理	上書き/複製ファイル	Git履歴/ブランチ/タグ
差分確認	Wordの変更履歴／Excelのセル見比べ	PR差分/コミット差分
修正反映	手作業で一括置換/整形	章単位でAI反映＋人の確定（最終版は Word に反映）
レビュー	Wordコメント/変更履歴＋メール/口頭	PRコメント/サジェスト/必須レビュー
整合性チェック	担当者の目視に依存	AIローカル整合

拡張性と横展開

今回確立したワークフローは、規定に限らず、マニュアルや FAQ、手順書など、更新頻度の高い他の社内文書にも応用可能です。
今後は対象を広げ、組織全体のドキュメントメンテナンスコストを下げていきたいと考えています。

まとめ

Excel と Word の人海戦術から、Cursor×GitHub のワークフローへ移行することで、規定改訂の「工数削減」と「精度向上」を同時に達成しました。人が得意な抽象化・判断は人が担い、AI には反映・整形・整合の反復作業を委ねる。シンプルですが強力な分業が、全体の品質とスピードを支えます。

なお、本記事の執筆自体も Cursor を活用し、人間が構成を考えながら AI とペアライティングを行いました。