AIと資料を作る人こそGitを使おう：GitHub Desktopで始める差分レビュー

皆さんこんにちは。SMEアナリティクス部でデータ分析を行っているみみずくです。

昨今、ChatGPTやGemini、ClaudeなどのLLM（大規模言語モデル）と会話しながら、文章や資料を作る機会が増えてきました。AIに出してもらった構成案を元に原稿を書き、AIのレビューを受け、指摘を反映して、またAIにレビューしてもらう。この繰り返しでテキストの精度を高めています（もちろんこの原稿もそのプロセスを通して書いています）。

しかし、何度も修正を重ねていると、少し面倒なことが起こります。修正した箇所を確認してほしいだけなのに、前後関係が伝わるように周囲の文章を長めにコピーしたり、最新版のファイルを丸ごと添付したりする必要が出てくるのです。変更したのは数行だけなのに、LLMには長い文章をもう一度読んでもらうことになります。これは多くのトークンを消費してコストがかさむだけでなく、回答の精度も下がることが知られており、望ましい状態とは言えません。

そこで、今回はエンジニアのソースコード管理に使われているGitをLLMとの共同作業に利用して、プロセスを効率化する方法を紹介します。

Gitと聞くと、黒い画面にコマンドを入力する難しいツールを想像するかもしれません。しかし、今回紹介するGitHub Desktopは、変更の確認や履歴の保存をほとんどGUI上で完結できるデスクトップアプリです。しかも、GitHubのサーバーへアップロードする必要はなく、自分のPCの中だけで、LLMに渡すための「差分」を作ることができます。

1. LLMに長い文章を何度も渡す問題

数十ページのマニュアルや、複数の章に分かれた企画書の場合、修正のたびに必要な範囲を切り出す作業が必要で、その物量はばかになりません。また、前後関係を伝えようと長めにコピーすると、どこを変更したのかが分かりづらくなります。かといってファイル全体を渡せば、変更していない部分まで毎回読み込ませることになります。

LLMが一度に参照できる情報量には「コンテクストウィンドウ」と呼ばれる上限があります。この上限に収まるように情報を渡したとしても、その中に同じ文章が何度も登場すると、本当に確認してほしい箇所に辿り着きにくくなります。人にレビューを依頼するときに申し送り事項を一緒に伝えないと、レビューする人が「変更された箇所がわかりにくい」と感じるのと同じです。

例えば、50ページのマニュアルのうち変更されたのが1ページだけなら、確認してほしいのは「削除もしくは加筆した箇所が間違っていないか」「文脈と矛盾しないか」「以前の指摘が正しく反映されているか」であり、残りの49ページを毎回読み直してもらう必要はありません。

2. 差分だけを渡すという考え方

そこで使えるのが、Gitのdiffです。diffは、以前の状態と現在の状態を比較し、変更された部分だけを表示する仕組みです。

例えば、ミュージックビデオを公開する際のプレスリリースを推敲するケースを考えます。

修正前：

歌手Aの1st EP「B」から、リードトラック「C」のミュージックビデオが公開された。
本ミュージックビデオは映像作家のXが制作を担当した。

修正後：

歌手Aが本日リリースした1st EP「B」から、リードトラック「C」のミュージックビデオが公開された。
本ミュージックビデオはSNSを中心に人気の映像作家Xが制作を担当し、AのR&B的な音楽センスを日本のポップカルチャーに落とし込んだ作品となっている。

この変更をgit diffで表示すると、次のようになります。

diff --git a/press-release.md b/press-release.md
--- a/press-release.md
+++ b/press-release.md
@@ -1,2 +1,2 @@
-歌手Aの1st EP「B」から、リードトラック「C」のミュージックビデオが公開された。
-本ミュージックビデオは映像作家のXが制作を担当した。
+歌手Aが本日リリースした1st EP「B」から、リードトラック「C」のミュージックビデオが公開された。
+本ミュージックビデオはSNSを中心に人気の映像作家Xが制作を担当し、AのR&B的な音楽センスを日本のポップカルチャーに落とし込んだ作品となっている。

先頭が-の行が削除された文章、+の行が新しく追加された文章です。このdiffをLLMへ渡せば、原稿全体を送り直さなくても、何を変更したのかを正確に伝えられます。人間が推敲を行う際、変更履歴の記録やコメント機能を用いて変更箇所をわかりやすくしておくのと同じです。

渡すときは、例えば次のように依頼します。

以下は、前稿からのgit diffです。変更後の文章について、
1. 変更部分が前後の文体から浮いていないか
2. 説明が冗長になっていないか
を確認してください。変更していない箇所は、今回の変更による
影響がある場合のみ指摘してください。

LLMは、-で始まる行を変更前、+で始まる行を変更後として認識し、変更の意図を踏まえてレビューできます。変更箇所を人間が説明しなくても、diffの形式自体が変更内容を構造化してくれるのです。Gitは単に履歴を残すだけでなく、人間が行った修正を、LLMが解釈しやすい形式へ変換する役割も果たします。

3. Gitはエンジニアだけのものではない

Gitが実際に行っているのは、ファイルの状態を記録し、以前の状態との差分を管理することです。

ブログ記事、プレスリリース、社内マニュアル、企画書、LLMへ渡すプロンプトなど、Markdownやテキストのように内容が文字として保存される形式なら、何でも相性がよいのです。対象がプログラムである必要はありません。

文章を書く人にとってのGitは、難しい開発ツールというより、変更履歴を自動で残してくれる高性能な赤入れ機能と考えると分かりやすいかもしれません。

4-1. GitHub Desktopで差分管理を始める

GitHub Desktopは、Gitの操作をほとんどGUI上で行える無料のデスクトップアプリです。インストール方法は公式サイトに譲り、差分を作るまでの流れだけを紹介します。

まず、メニューから File → New repository を選択します。リポジトリとは、Gitで変更履歴を管理するフォルダのことです。作成したフォルダに原稿を保存すると、「Changes」タブにファイルが表示されます。画面左下の「Summary」へ「初稿を作成」などと入力し、「Commit to main」を押します。コミットとは、その時点のファイルの状態をPC内に記録する操作で、GitHubへアップロードするわけではありません。

その後、普段のエディタで原稿を修正すると、GitHub Desktop上で削除した行が赤、追加した行が緑で表示されます。

この差分をLLMへ渡すには、メニューの Repository → Open in Command Prompt からターミナルを開き（環境によってはPowerShellやTerminalの表記）、次の1行だけ実行します。

git diff --no-color | clip     （Windowsの場合）
git diff --no-color | pbcopy   （Macの場合）

差分がクリップボードへコピーされ、そのままLLMの入力欄へ貼り付けられます。

4-2. レビュー後はコミットする

LLMの指摘を反映して内容が固まったら、GitHub Desktopで再びコミットします。これで修正後の状態が新しい基準になり、次に原稿を変更した際には、新たに書き換えた部分だけがgit diffに表示されます。基本は「原稿を編集する → diffをLLMへ渡す → 指摘を反映する → コミットする」の繰り返しです。コミットが、LLMとの共同編集におけるセーブポイントになるイメージです。

4-3. Wordや表形式の資料でも使えるのか

Wordの.docxやExcelの.xlsxは、そのままでは文章の差分を読みやすく表示できません。そのため、完成ファイルとは別に、原稿や構成をテキスト形式で管理すると便利です。

用途	管理方法
Notion	Markdown形式でエクスポートする
Word	装飾前の原稿をテキストでも管理する
表形式の資料	CSVやJSONで管理する

最終的なデザインはWordやExcelで行い、内容の設計とレビューはテキストで行う、という分担です。

5. セキュリティ上の注意

GitHubへプッシュしなくても、作成したdiffを外部のLLMへ貼り付ければ、情報はそのサービスへ送信されます。

社外秘の情報や個人情報を扱う場合は、社内ルールや利用するLLMサービスのデータ取り扱いを確認してください。

Gitをローカルで使うことと、LLMへ入力してよい情報かどうかは、別の問題です。

まとめ

これまでGitの価値は、「以前の状態に戻せる」「複数人で変更を管理できる」といった点を中心に説明されてきました。しかし、LLMとの共同作業では、もうひとつ新しい価値が生まれています。Gitは、AIに変更内容だけを伝えるためのツールになるのです。

プレスリリースを書く人も、Notionでマニュアルを作る人も、AIと何度も文章を推敲するなら、差分を管理する価値があります。AI時代だからこそ、Gitを活用していきましょう。