架空企業「みらい業務サービス」の社内依頼・承認管理アプリの例。実在する会社・案件・人物は含まない。
記事「差分・保存単位・分岐・レビューで、変更履歴を安全に管理する」（06-03）の本文で実際に実行して確認した内容をまとめたもの。空欄版は 06-03-change-management_template.md。
1. 最小の流れ（作業開始→分岐→変更→確認→add→commit→確認→やり直し）
| 段階 | 操作 | 確認したこと（2026-09-21 実行、evidence_public/phase5b2c2-2026-09-21/06-03/run_log.md） |
|---|
| 作業開始 | 変更前のコードを最初の保存単位にする | git log --oneline に1件 |
| 分岐 | git switch -c fix-self-approval | 分岐名が表示された |
| 変更確認 | git status --short、git diff | M approval.js の1ファイル、+ if (isSelf) return false; の1行だけ |
| add・commit | git add approval.js、git commit -m "自己承認を禁止する条件を追加（REQ-003）" | エラーなし |
| 保存確認 | git status --short、git log --oneline、git show --stat | status 空、log に理由、1 file changed, 1 insertion(+) |
| やり直し | git revert --no-edit HEAD | Revert の保存単位が増え、ファイルは変更前と同一 |
| 共有先確認 | git remote -v | 出力なし（共有先なし） |
AIに変更させた後、保存の前に人が確認すること：変わったファイルが頼んだ範囲だけか（status）、変わった行が意図した変更だけか（diff）、保存の理由が何を・なぜを言えているか（log）。
2. 保存単位・変更理由の書き方
| 基準 | 内容 |
|---|
| 保存単位 | 1つの目的ごとに1つの保存単位とする |
| 変更理由の書き方 | 「何を」「なぜ（関連する要件ID）」を含める |
| 分岐の使い方 | 目的が分かる名前（例：fix-self-approval）。元の履歴を保ったまま試す変更、並行作業に使う |
| レビューの条件 | 保存の前に本人が status・diff を読む。共有先へ送る前に本人以外が差分を読む |
3. 共有先の扱い
| 項目 | 内容 |
|---|
| 送ってよい条件 | レビューを経た変更のみ |
| 禁止事項 | 秘密情報・実データを含む変更を送信しない |
4. 完了条件の確認
5. 次工程へ渡すもの
AI時代のシステム開発の基礎