開発環境・変更管理の準備学習記事全11節Operate
差分・保存単位・分岐・レビューで、変更履歴を安全に管理する
この記事で身につくこと変更履歴を残す目的と、差分・保存単位・作業の分岐・レビュー・共有先の役割を、実際の成果物の変更前後で説明でき、「作業開始→変更→確認→分岐→add→commit→確認」の最小の流れを自分の手で再現できる。
記事内目次（21項目）
この記事の会社・人物・コードはすべて架空の設定です。実在する会社や案件とは関係ありません。本文のGit操作と実行結果は、
examples/06-03-change-management/直下に作る使い捨ての置き場で実際に実行したものです（第7節）。共有先（GitHubなど）への送信は行っていません。変更後のコードは「自己承認を禁止する条件を1行追加した」教材上の変更例で、実際のAI出力ではありません。
この記事は何の話か。承認可否を判定する小さなコードに1行の修正を加える例で、「作業を始める→分岐を作る→変更する→何が変わったか確認する→保存の対象にする→理由を添えて保存する→保存できたか確認する→必要なら履歴を残したままやり直す」という最小の流れを実際に行い、変更履歴を残す目的と、AIに変更させた後に人が何を確認するかを扱う話です。
なぜ必要か。何をいつ、なぜ変更したかを記録していないと、後から「なぜこうなっているのか」が分からなくなったり、複数人での作業が衝突したりします。AIにコードを変更させる場面が増えるほど、「AIが何を変えたか」を人が差分で確かめてから保存する習慣が、事故を防ぐ最後の砦になります。
この記事を読むとできるようになること。
- 変更履歴を残す目的と、差分・保存単位・分岐・レビュー・共有先の役割を説明できる
- 作業開始から保存の確認までの最小の流れを、演習コードで再現し、各段階の出力を読める
- AIに変更させた後、保存の前に人が何を確認するかを言える
- 保存単位や分岐の使い方を、レビューのしやすさと衝突の危険から判断できる
読む順路。この記事は3つの深さで読めます。全部を順に読む必要はありません。
- 基本だけ理解する：第1節→第3節（なぜ履歴を残すか、AIに変更させた後に人が確認すること）→第4節（判断すること）→第5.1節（最小の流れの8段階）→第6節の実行結果の読み方→第9節。コマンドを打たなくても、各段階で何を確認するかが分かります。
- 作って確かめる：上に加えて第5.2節（演習コード）→第5.3節（演習の設計：実行前に見るもの・失敗したとき・戻せるか・誰が）→第6節の実行結果→第7節（確かめたこと・確かめていないこと）。
- 設計判断を深める：上に加えて第5.4節（保存単位・変更理由・分岐・レビュー・共有先のルール）→第8節（保存単位と分岐の比較、適用限界）。
1. 今回の業務課題と完成するもの
この記事でやることは、承認可否を判定する最小のコードに小さな修正（自己承認を禁止する条件の追加。05-03の権限表に対応する REQ-003）を加える例で、作業開始から保存の確認までの最小の流れを実際に行い、その変更を履歴を残したままやり直す操作まで記録することです。
06-01で作業場所と実行環境を整えましたが、その中でファイルをどう変更し、変更をどう記録するかはまだ扱っていません。この記事では、それを扱います。
この記事を読み終えると、次のものが手元にできます。
- 変更履歴・変更管理ルール（保存単位の基準、変更理由の書き方、分岐の使い方、レビューの条件、共有先の扱い）
- 最小の流れを再現する演習コードと、その実行記録
2. 前提知識と読む順路
この記事で使う言葉を先に説明します。
Git
一言でいうと、ファイルの変更履歴を記録し、管理するための道具です。この記事では、Gitの機能全体ではなく、変更を確認して理由付きで保存するための最小の操作だけを使います。
差分
一言でいうと、変更前と変更後で、何がどう変わったかを示す情報です。たとえば、1行追加された、という情報が差分です。
コミット（保存単位）
一言でいうと、ある時点での変更を、理由とともにひとまとめにして記録することです。保存する前に「保存の対象にする（add）」という段階があり、対象にしたものだけが保存されます。
これがないと、いつ・何を・なぜ変更したかが分からなくなり、問題が起きたときに原因を特定しにくくなります。
ブランチ（作業の分岐）
一言でいうと、元の履歴を残したまま、別の作業を並行して進めるための分かれ道です。目的が分かる名前（この記事では fix-self-approval）を付けます。
レビュー
一言でいうと、変更した本人以外が、その変更を確認することです。AIが変更した場合、変更を指示した人が差分を読むことが最初のレビューです。
共有先
一言でいうと、変更履歴を他の人と共有するための置き場所です（例：GitHubのようなサービス）。この記事の演習では共有先を設定せず、送信は行いません。
読む順路：作業場所と実行環境は06-01が該当します。この記事のルールは、07-03（指示・検証・修正の手順）、09-04（レビュー）、13-02（変更影響調査）で使います。秘密情報を履歴に含めない方法は06-04で扱います。
3. 理解する：なぜ変更履歴を残すか
3.1 差分・保存単位・分岐・レビューの役割
| 要素 | 役割 | 題材での場面 |
|---|---|---|
| 差分 | 何が変わったかを確認できるようにする | 「自己承認を禁止する1行だけが増えた」ことを + の行で確かめる |
| 保存単位（コミット） | いつ・なぜ変更したかを記録する | 「自己承認を禁止する条件を追加（REQ-003）」という理由が履歴に残る |
| 分岐（ブランチ） | 元の履歴を保ちながら、別の変更を試せるようにする | main を残したまま fix-self-approval で変更する |
| レビュー | 変更した本人以外の目で確認し、見落としを減らす | 差分を読み、意図した1行以外が変わっていないことを見る |
3.2 よくある誤解
「変更履歴は完成後にまとめて記録すればよい」。まとめて記録すると、どの変更がどの理由だったかが分からなくなります。変更のたびに記録します。
「保存単位は大きいほど手間が少なくてよい」。大きすぎる保存単位は、差分が読みにくくなり、レビューや原因調査の妨げになります（第8節）。
「共有先に送らなければ記録しなくてよい」。共有先へ送らなくても、自分のパソコンの中で履歴を残すことには意味があります（原因調査、やり直しのため）。
「やり直しは、ファイルを手で書き戻すこと」。手作業での書き戻しは履歴に残らず、いつ・なぜ戻したかが分からなくなります。履歴を残す方法（第6節の手順6、revert）を使います。
3.3 AIに変更させた後、人は何を確認するのか
AIにコードの変更を頼むと、AIは複数のファイル・複数の行を一度に変えることがあります。保存の前に人が確認するのは、次の3つです。
| 確認すること | 見る出力 | 見つけたときの扱い |
|---|---|---|
| 変わったファイルが、頼んだ範囲だけか | git status --short（変わったファイルの一覧） | 頼んでいないファイルが変わっていたら、理由を聞くか、その変更を保存の対象から外す |
| 変わった行が、意図した変更だけか | git diff（+・- の行） | 意図しない行（削除、無関係な書き換え、秘密情報の混入）があれば保存しない |
| 保存の理由が、何を・なぜ変えたかを言えているか | commit の説明文と git log --oneline | 「修正」「更新」だけの説明は書き直す。要件IDを添える |
AIの「変更しました」という報告は、差分の代わりになりません。差分を読んで初めて、変更が確認されたことになります（07-03の検証、09-04のレビューと同じ考え方です）。
4. 判断すること
変更を履歴に残すときに人が判断することは、次の5つです。
| 判断すること | なぜ判断が必要か | 仮置きしてよいか | 間違えた場合の影響 |
|---|---|---|---|
| いつ保存するか（保存単位の区切り） | 1つの目的が終わった時点で保存する。複数の目的を1つにまとめると差分が読めなくなる | 可（区切りが大きすぎたと分かれば、次から小さくする） | 原因調査のとき、どの変更が問題を起こしたか特定できない |
| 保存の前に何を確認するか（止める条件） | 変わったファイル・行が意図した範囲を超えていないか、秘密情報が混ざっていないか（06-04）。超えていれば保存しない | 不可。確認せずに保存すると、履歴に残ってしまう | 意図しない変更や秘密情報が履歴に残り、共有先へ送られる |
| 分岐を作るか | 元の履歴を保ったまま試したい変更、複数人が並行する作業は分岐で行う。1人の小さな変更なら分岐なしでもよい | 可（小規模なら「目的ごとに分岐」を仮置き） | 試した変更が元の履歴に直接入り、戻すのが難しくなる |
| 何を証拠として残すか | status・diff・log の出力と、保存の理由。「AIが直したと言った」は証拠にならない | 不可 | 後から「何が変わったか」を示せない |
| 誰が確認し、誰が共有先へ送ると判断するか | 変更した本人（またはAIに指示した人）が差分を確認し、レビューを経た変更だけを共有先へ送る。送る判断は担当者（架空の想定では開発担当と運用管理者） | 可（架空の体制で仮置き） | レビューされていない変更が共有先に入り、他の人の作業に影響する |
勝手に決めてはいけないこと：この記事の演習で、実際に共有先（GitHubなど）へ送信しません。秘密情報を含むファイルを、変更履歴に含めません（06-04で詳しく扱います）。AIが変更したコードを、差分を読まずに保存しません。
AIに任せる範囲：コードの変更の下書き、保存の理由の文案、差分の要約はAIに任せられます。任せてはいけないのは、差分を読んで「意図した変更だけか」を確かめること、保存するかどうかの判断、共有先へ送る判断です。
5. 作って確かめる：最小の流れを演習する
5.1 最小の流れ（8段階）
| 段階 | 操作 | 何のためか | 確認すること |
|---|---|---|---|
| 0 作業開始 | 置き場を用意し、変更前のコードを最初の保存単位にする | 「変更前」を履歴に残し、比較の基準にする | git log --oneline に1件ある |
| 1 分岐 | git switch -c fix-self-approval | 元の履歴（main）を残したまま変更する | git branch --show-current が分岐名 |
| 2 変更 | コードを書き換える（この演習では変更後のファイルをコピー。実務ではAIや人が編集） | — | — |
| 3 変更確認 | git status --short、git diff | 変わったファイルと行が、意図した範囲だけか | M approval.js の1ファイル、+ が1行 |
| 4 add・commit | git add approval.js、git commit -m "…（REQ-003）" | 保存の対象にし、理由を添えて保存する | エラーが出ない |
| 5 保存確認 | git status --short、git log --oneline、git show --stat | 保存し忘れが無いか、理由が残ったか、何が保存されたか | status が空、log に理由、1 file changed / 1 insertion |
| 6 やり直し | git revert --no-edit HEAD | 履歴を残したまま直前の保存を打ち消す | log に Revert が増え、ファイルが変更前と同一 |
| 7 共有先確認 | git remote -v | 送信先が無いことを確かめる | 出力なし |
5.2 演習コード
演習コードは examples/06-03-change-management/ を正本とします。drill.sh は、このフォルダ直下の work/ に使い捨ての置き場を作り、手順0〜7を順に実行します。演習用の名前・メールアドレス・日時を固定するので、個人のGit設定は読まず、保存単位の識別子（ハッシュ）は誰が実行しても同じになります。
drill.sh：
#!/bin/sh
# 教材演習用：変更履歴を残す最小の流れ（作業開始→変更→確認→分岐→add→commit→確認→やり直し）を、
# このフォルダ直下の work/ に作る使い捨ての Git 置き場で実際に行う。
# 共有先（GitHub など）への送信は行わない。演習用の名前・メールアドレス・日時を固定し、個人の設定は読まない
# （日時を固定するので、保存単位の識別子（ハッシュ）は誰が実行しても同じになる）。
set -e
cd "$(dirname "$0")"
rm -rf work && mkdir work && cd work
export GIT_AUTHOR_DATE="2026-09-21T00:00:00+09:00" GIT_COMMITTER_DATE="2026-09-21T00:00:00+09:00"
GIT="git -c user.name=drill -c user.email=drill@example.invalid -c commit.gpgsign=false -c core.pager=cat"
echo "手順0：作業開始。空の置き場を作り、変更前のコードを最初の保存単位として記録する"
$GIT init -q -b main
cp ../approval_before.js approval.js
$GIT add approval.js
$GIT commit -q -m "承認可否の判定（変更前）"
$GIT log --oneline
echo "手順1：分岐（ブランチ）を作る。目的が分かる名前にする"
$GIT switch -c fix-self-approval
$GIT branch --show-current
echo "手順2：コードを変更する（自己承認を禁止する条件を1行追加。教材上の変更例で、実際のAI出力ではない）"
cp ../approval_after.js approval.js
echo "手順3：変更を確認する。まず何が変わったファイルか（status）、次に何行がどう変わったか（diff）"
$GIT status --short
$GIT diff
echo "手順4：保存の対象にする（add）と、理由を添えて保存する（commit）"
$GIT add approval.js
$GIT commit -q -m "自己承認を禁止する条件を追加（REQ-003）"
echo "手順5：保存できたことを確認する。作業中の変更が残っていないこと（status が空）と、履歴に理由が残っていること"
$GIT status --short
echo "（status の出力なし＝保存していない変更は無い）"
$GIT log --oneline
$GIT show --stat --oneline HEAD | sed -n '2,$p'
echo "手順6：やり直し。履歴を残したまま直前の保存単位を打ち消す（revert）"
$GIT revert --no-edit HEAD >/dev/null
$GIT log --oneline
echo "打ち消し後の approval.js（変更前と同じ内容に戻っている）:"
diff ../approval_before.js approval.js && echo "（diff の出力なし＝変更前と同一）"
echo "手順7：共有先の確認。この置き場には共有先が設定されていない（remote なし）ので、送信は起きない"
$GIT remote -v
echo "（remote の出力なし＝共有先なし）"変更前のコード approval_before.js（08-01で扱う判定をこの記事用に最小にしたもの）：
// 教材演習用：承認可否の判定（08-01 で扱う判定をこの記事用に最小にしたもの。架空）。
function canApprove(state, isSelf) {
if (state !== "提出済み") return false;
return true;
}
module.exports = { canApprove };変更後のコード approval_after.js（自己承認を禁止する条件を1行追加。教材上の変更例で、実際のAI出力ではありません）：
// 教材演習用：承認可否の判定（08-01 で扱う判定をこの記事用に最小にしたもの。架空）。
function canApprove(state, isSelf) {
if (state !== "提出済み") return false;
if (isSelf) return false;
return true;
}
module.exports = { canApprove };5.3 演習の設計
| 項目 | 内容 |
|---|---|
| 何のための操作か | 作業開始から保存の確認、やり直しまでの最小の流れを、使い捨ての置き場で一度通しで行い、各段階の出力の読み方を身につける |
| 実行前に見るもの | 今いる場所が examples/06-03-change-management/ か。git --version が動くか（06-01）。work/ があれば消して作り直される |
| コマンド | sh drill.sh |
| 期待結果 | 手順3で M approval.js と + if (isSelf) return false; の1行。手順5で status が空、log に2件、1 file changed, 1 insertion(+)。手順6で log に3件、diff の出力なし。手順7で remote の出力なし。終了コード0 |
| 結果の読み方 | + の行が意図した1行だけか。手順5の status が空か（空でなければ保存し忘れ）。手順6の「diff の出力なし」＝変更前と同一 |
| 失敗したとき | git: command not found → 06-01 に戻って git を入れる。途中で止まる（終了コード0以外）→ 表示された手順番号の直前の操作を見直す。work/ を消して再実行する |
| 元に戻せるか | 作るのは work/ の中だけ。work/ を消せば元どおり。このリポジトリ本体の履歴には触れない |
| 業務運用では誰が実施／判断するか | 変更と確認：開発担当（AIに指示した人）。共有先へ送る判断：レビューを経て担当者（架空の想定では運用管理者）。この演習ではすべて Claude Code |
5.4 保存単位・変更理由・分岐・レビュー・共有先のルール
| 項目 | 内容 |
|---|---|
| 保存単位 | 1つの目的（例：自己承認禁止の追加）ごとに1つの保存単位とする |
| 変更理由の書き方 | 「何を」「なぜ（関連する要件ID）」を含める（例：「自己承認を禁止する条件を追加（REQ-003）」） |
| 分岐の使い方 | 目的が分かる名前を付ける（例：fix-self-approval）。元の履歴（main）を保ったまま試す変更、複数人が並行する作業に使う |
| レビューの条件 | 保存の前に、変更した本人（AIに指示した人）が status・diff を読む。共有先へ送る前に、本人以外が差分を読む（09-04） |
| 共有先へ送ってよい条件 | レビューを経た変更のみ |
| 禁止事項 | 秘密情報・実データを含む変更を保存・送信しない（06-04）。差分を読まずに保存しない |
| この記事の演習 | 共有先を設定せず、送信は行わない |
6. 実行結果（演習の実測）
examples/06-03-change-management/ で実行した stdout です（整形・省略なし。stderr には分岐を作ったときの Switched to a new branch 'fix-self-approval' の1行だけが出ました）。
$ sh drill.sh
手順0：作業開始。空の置き場を作り、変更前のコードを最初の保存単位として記録する
fec5152 承認可否の判定（変更前）
手順1：分岐（ブランチ）を作る。目的が分かる名前にする
fix-self-approval
手順2：コードを変更する（自己承認を禁止する条件を1行追加。教材上の変更例で、実際のAI出力ではない）
手順3：変更を確認する。まず何が変わったファイルか（status）、次に何行がどう変わったか（diff）
M approval.js
diff --git a/approval.js b/approval.js
index a3c3e1e..fee9d83 100644
--- a/approval.js
+++ b/approval.js
@@ -1,6 +1,7 @@
// 教材演習用：承認可否の判定（08-01 で扱う判定をこの記事用に最小にしたもの。架空）。
function canApprove(state, isSelf) {
if (state !== "提出済み") return false;
+ if (isSelf) return false;
return true;
}
module.exports = { canApprove };
手順4：保存の対象にする（add）と、理由を添えて保存する（commit）
手順5：保存できたことを確認する。作業中の変更が残っていないこと（status が空）と、履歴に理由が残っていること
（status の出力なし＝保存していない変更は無い）
946a72a 自己承認を禁止する条件を追加（REQ-003）
fec5152 承認可否の判定（変更前）
approval.js | 1 +
1 file changed, 1 insertion(+)
手順6：やり直し。履歴を残したまま直前の保存単位を打ち消す（revert）
39ebe6a Revert "自己承認を禁止する条件を追加（REQ-003）"
946a72a 自己承認を禁止する条件を追加（REQ-003）
fec5152 承認可否の判定（変更前）
打ち消し後の approval.js（変更前と同じ内容に戻っている）:
（diff の出力なし＝変更前と同一）
手順7：共有先の確認。この置き場には共有先が設定されていない（remote なし）ので、送信は起きない
（remote の出力なし＝共有先なし）
終了コード: 0読み方：手順3の diff で + が付いた行は if (isSelf) return false; の1行だけで、コメントや他の行は変わっていません（意図した変更だけ）。手順5で status の出力が無いので保存し忘れは無く、log に理由付きの保存単位 946a72a が増え、1 file changed, 1 insertion(+) で1ファイル1行の追加だと分かります。手順6の revert は、946a72a を消すのではなく、打ち消す保存単位 39ebe6a を積み、ファイルは変更前と同一に戻っています。手順7で共有先が無いので、どの操作も外部には送られていません。
7. 確認結果
実行環境：macOS 26.6.2、git 2.54.0 (Apple Git-157)、sh、2026-09-21に実行。実行場所は examples/06-03-change-management/。操作したのは work/ の中の使い捨ての置き場だけで、共有先への送信は行っていません。stdout・stderr・終了コードは evidence_public/phase5b2c2-2026-09-21/06-03/run_log.md に整形なしで記録し、同じコマンドを2回実行して stdout が同一であることを確認しています。
完了条件との照合：
| 完了条件 | 期待 | 実測 | 判定 |
|---|---|---|---|
| 作業開始→分岐→変更→確認→add→commit→確認の流れが実際に通る | 終了コード0 | 0 | 一致 |
| 変更前後の差分が意図した1行だけ | + が1行 | + if (isSelf) return false; の1行 | 一致 |
| 保存の理由が履歴に残る | log に要件ID付きの理由 | 946a72a 自己承認を禁止する条件を追加（REQ-003） | 一致 |
| 保存し忘れが無い | 手順5の status が空 | 出力なし | 一致 |
| やり直しが履歴を残したまま行える | Revert の保存単位が増え、ファイルは変更前と同一 | 39ebe6a Revert …、diff の出力なし | 一致 |
| 共有先へ送っていない | remote なし | 出力なし | 一致 |
| 保存単位と変更理由の書き方、分岐・レビュー・共有先のルールがある | 第5.4節 | 記載あり | 一致 |
この記事で確かめたこと：使い捨ての置き場で、最小の流れ（8段階）が実際に通ること。差分・status・log の出力がそれぞれ何を示すか。
この記事で確かめていないこと：
| 範囲 | 理由 | どこで確かめるか |
|---|---|---|
| 共有先（GitHubなど）への送信と、共有先でのレビュー | 演習では共有先を設定していない | 実際のチームで、レビューを経た変更を送るとき |
| 複数人が同じファイルを変えたときの衝突の解消 | 1人・1ファイルの演習 | 実際の並行作業で |
| AIが実際に変更したコードの差分確認 | 変更後のコードは教材上の変更例（コピー） | 07-03の演習で、AIの初稿を差分で確かめる |
| 実装者以外の人によるレビュー | 実施者は Claude Code | 09-04 |
残る制限：この記事の本文と演習コードはClaude Codeが作成したもので、業務担当者による内容確認は行っていません。
8. 設計を判断する
8.1 保存単位・分岐の使い方を比較する
| 選択肢 | レビューのしやすさ | 衝突の危険 |
|---|---|---|
| 保存単位を大きくする（例：1日の作業をまとめる） | 差分が大きく、レビューしにくい | 複数人が同時に触ると衝突しやすい |
| 保存単位を小さくする（1つの目的ごと、採用） | 差分が小さく、レビューしやすい | 頻繁に保存することで衝突の範囲を小さくできる |
小規模な開発体制（架空の想定）では、複雑な分岐の運用よりも、保存単位を小さく保つことを優先します。分岐は、大きな変更を試す場合や、複数人が並行して作業する場合に使う方針とし、目的名を付けます（第6節の手順1で作った fix-self-approval がその例です）。
8.2 やり直しの方法を選ぶ
| 方法 | 内容 | 適する場合 |
|---|---|---|
| 打ち消す（revert、この記事で採用） | 打ち消す保存単位を積み、元の保存単位も履歴に残る | 一度保存した変更を戻すとき。共有先へ送った後でも安全 |
| 保存の前に捨てる（restore） | 保存していない変更をファイル単位で捨てる | 差分を読んで意図しない変更だと分かった、保存前の段階 |
| 履歴を書き換える | 保存単位そのものを消す・作り直す | この記事では扱わない。共有先へ送った後に行うと他の人の履歴と食い違うため、小規模体制では避ける |
8.3 適用限界
このルールは、架空企業「みらい業務サービス」の小規模な開発体制を前提にした一例です。複数人・複数チームでの開発では、より詳細な分岐運用やレビュー体制が必要になることがあります。演習は使い捨ての置き場で行っており、実際のリポジトリでは work/ を作らず、作業フォルダそのものが置き場になります。
9. 持ち帰る成果物
| 成果物 | 空欄版 | 記入例 |
|---|---|---|
| 変更履歴・変更管理ルールひな形（保存単位の基準、変更理由の書き方、分岐の使い方、レビューの条件、共有先の扱い） | templates/06-03-change-management_template.md | templates/06-03-change-management_example.md |
| 最小の流れの演習コード | examples/06-03-change-management/（drill.sh、approval_before.js、approval_after.js） | 同上 |
| 実行記録（stdout・stderr・終了コード、整形なし） | — | evidence_public/phase5b2c2-2026-09-21/06-03/run_log.md |
自分の業務に使うときの手順は次のとおりです。
- 前工程（作業フォルダ）を用意し、変更前の状態を最初の保存単位にする
- 目的ごとに分岐を作り、変更する（AIに変更させる場合も同じ）
- 保存の前に status と diff を読み、意図した変更だけであることを確かめる
- 保存単位を1つの目的ごとに分け、要件IDを添えた理由で保存し、status が空・log に理由が残ることを確かめる
- 共有先へ送る条件（レビュー済み）と禁止事項（秘密情報・実データ）を決める
10. 次工程への受渡し
次へ渡すもの：変更履歴・変更管理ルール（保存単位、変更理由の書き方、分岐の使い方、レビューの条件、共有先の扱い）、演習の実行記録。
次工程での使われ方：06-04では、この履歴に秘密情報を含めない確認を加えます。07-03（指示・検証・修正の手順）では、AIが変更したコードをこの記事の流れ（status・diff を読んでから保存）で扱います。09-04（第三者の視点でレビューする）、13-02（変更の影響を調べる）では、このルールと履歴を前提に進めます。
前工程へ戻る条件：このルールが06-01の作業フォルダの構成と食い違う場合、または git が動かない場合は、06-01に戻って確認します。
11. 根拠と更新情報
- この記事の会社・人物・コードはすべて架空の設定です。
- 変更例の要件（自己承認の禁止、REQ-003）は05-03の権限表、変更前のコードは08-01の判定に基づきます。
- 制作の来歴：本文はClaude Codeが作成しました。第5.2節・第6節の演習コードは
examples/06-03-change-management/を正本とし、2026-09-21にmacOS 26.6.2・git 2.54.0の環境で実際に実行し、stdout・stderr・終了コードをevidence_public/phase5b2c2-2026-09-21/06-03/run_log.mdに記録しています。共有先への送信は行っていません。人（ユーザー）による実読・内容確認は未実施です。 - 2026-09-21（Phase 5B-2C2）：初版は
git diff・git commit・git revertの3つの断片的な操作例だけで、作業開始・分岐・add・保存後の確認が無く、非エンジニアには再現しにくかった。また第8.1節が存在しない「第5.5節 fix-self-approval」を参照していた。本更新で、作業開始→分岐→変更→確認→add→commit→確認→やり直し→共有先確認の8段階を1本の演習コードdrill.shにし、分岐fix-self-approvalを実際に作り、実測に置き換えた。「何のために履歴を残すか」「AIに変更させた後に人が何を確認するか」（第3.3節）を中心に据え、Git講座にはしていない。 - 未確認事項：共有先への送信と共有先でのレビュー、複数人での衝突の解消、実装者以外の人によるレビューは、この記事の時点では行っていません。