AIに任せる量が増えたら、先に必要になったのはGitの5語だった

きっかけ

AIが変更を作る速さと、人間がそれを確認する速さは釣り合っていない。数分で複数のファイルにまたがる変更が出てくるのに、それを読んで採用するかどうかを決めるのは人間の側に残る。

1回の依頼で出てくる変更が1箇所なら、目で見て判断できる。10箇所になると、「どれが今回の変更か」を区別する手段が要る。引っかかったのは、その手段を持たないまま量を増やしていたことだった。変更は手元のフォルダに積み上がっていくけど、どこまでが確定でどこからが作業中か、手元と共有先がどれだけ離れているかは、フォルダを眺めても分からない。

立てた仮説はこうだ。AIに作業を任せる人にとって、Gitは「コードを書く技術」ではなく「AIがした変更を安全に扱う技術」として意味がある。だとすれば、コマンドを網羅的に覚える必要はなく、変更の位置を言い表す最小限の語彙だけで、判断できる場面がかなり増えるはずだ。

比べていないものもある。Gitを使わずに同じ運用をした場合との比較はしていない。ここに書くのは、実際に起きた3件と、そのとき何を知っていれば判断できたかだけになる。

先に5つの用語を並べておく。AIが作った変更は、この順に置き場所が変わっていく。

5つ目の diff（何を変えたか見る）は、この4段階のどこでも使う。特に merge の直前で、これから本流に入るものを一覧するときに要る。

やったこと

手順は3つ。

1. 作業が消えかけた事例を集める。 記録に残っている範囲で、手元の成果が失われうる状態になった場面を洗い出す。原因がAIの誤作動だったものは除き、人間の管理側に原因があったものだけを数える。
2. 各事例を、何を知っていれば判断できたかで分類する。 「難しいコマンドを知らなかった」ではなく「変更がどこにあるかを把握していなかった」に落とせるかを見る。
3. 残った語彙を書き出し、足りなかった場面も記録する。 5語で説明できなかった事例を隠さない。

件数は3件で、統計にはならない。時間の節約量も測っていない。

事例1：作業フォルダが、別の作業に切り替えられていた

自分の作業の直後に、同じフォルダが別の作業状態へ切り替えられ、しかも統合の途中で止まっていた。ファイルの中身は、自分が書いたものではなくなっていた。

実害はゼロだった。その時点で、自分の変更は共有先へ送信済みだったからだ。手元のフォルダが何に切り替わっていても、送った先の記録は独立して残る。送っていなければ、切り替わった時点で失われていた可能性がある。ここで効いたのは push（共有先へ送る）の理解で、「送ったかどうか」が被害の有無をそのまま決めた。

もう1つ分かったのは、別の作業が途中で止めている状態を勝手に元へ戻してはいけない、ということだった。止まっている状態そのものが、相手の作業中の姿になる。

事例2：手元と共有先が、別々に育っていた

手元の本流に24件、共有先の本流に42件、それぞれ相手にない変更が溜まっていた。どちらも壊れてはいない。ただ、別物になっていた。

この状態はフォルダを開いても見えない。ファイルは普通にそこにあり、中身も読める。差が見えるのは、手元と共有先を突き合わせたときだけだ。

必要だったのは diff（何が違うかを見る）と merge（どちらをどう採用するか決める）の理解だった。数が多いと「全部まとめて上書き」で済ませたくなるが、それをやると片側の24件か42件が消える。実際には、作業用の枝を1本作って、そこで突き合わせてから本流へ入れた。

事例3：10個のうち1個だけ、保存されていなかった

ある調査の成果物が10ファイルあり、最終報告書にはその10個が成果物として列挙されていた。実際には、9個は保存済みで、1個だけが保存されていなかった。

報告書は「ある」と書いている。フォルダを見ても、ファイルはそこにある。それでも保存されていない。この2つの状態の区別が、commit（セーブ）を知らないとつかない。見つかったのは、作業の開始時に手元の状態を一覧したからで、一覧に「保存されていないもの」として1件だけ出てきた。

3件の共通点

事例	失われかけた原因	効いた語
作業フォルダの切り替え	手元の状態は他者に動かされうる	push（送っていたので無傷）
手元と共有先の乖離	2つの場所が別々に育つことに気づけない	diff / merge
1件だけ未保存	「ファイルがある」と「保存済み」は別	commit

どれも、AIが間違えた話ではない。AIは依頼どおりに変更を作っていた。失われかけたのは、その変更が「いまどこにあるか」を人間が把握していなかったからだった。

わかったこと

5つの語は、操作方法ではなく置き場所の名前だった。

用語	日常語での意味	これを知らないと困る場面
commit	セーブ	「ファイルがある」と「保存済み」の区別がつかない
push	共有先へ送る	手元が壊れたとき、何が残るか分からない
branch	作業用の枝	失敗しても壊れない場所で試す、ができない
merge	本流へ採用する	採用の判断と、作業の完了を混同する
diff	何を変えたか見る	AIが出した変更を、読まずに採用してしまう

AIに任せる量が増えると、この区別が要る回数が増える。変更が1件なら記憶で追えるが、1回の依頼で複数ファイルが変わり、それが1日に何度も起きると、記憶では追えなくなる。

コードを書く話でもない。この連載の記事も、設定ファイルも、運用ルールの文書も、同じ扱いで管理している。扱う対象が文章でも、AIが変更を作る以上、変更管理の必要は同じように出てくる。AIがコードを書くから人間はプログラミングを覚えなくていい、という話は半分しか合っていなかった。書く作業は任せられるが、出てきた変更をどう扱うかの判断が増えた。

5語で足りなかった場面

足りなかった場面も2つあった。

1つは、枝が増えすぎたときの判断だ。この連載の記事を管理している場所（リポジトリ）には、いま26本の枝がある。どれが現役で、どれが役目を終えたのかは、5語の知識では決まらない。「この枝の変更は本流に入っているか」を1本ずつ確かめる作業が別に要る。

もう1つは、元に戻す操作の危険さだ。「戻す」にあたる操作にはいくつか種類があり、保存していない変更ごと消してしまうものが含まれる。5語には「戻す」が入っていないが、困ったときに最初に手を出したくなる操作がそこにある。ここは5語の外側で、事前に線を引いておく必要があった。

それでも、始める前に全部を覚える必要はなかった。実際に困った場面が、次に何を覚えるかを指していた。

学習にかかった時間は測っていない。見たのは1人・約1か月・記事制作とその運用の範囲で、複数人で同じ枝を触る場合に何が変わるかは入っていない。