「この 2 つは外すのがよいと考えます」。自作の自動実装パイプラインが作った PR の報告には、そう書かれていた。
頼んだのは、社内の LP の repo で Node 20 を 24 に上げる issue だ。変えてよいファイルは workflow と package.json の 2 つだけ。報告の該当箇所はこうだ。
issue で変えてよいのは 2 つだけですが、PR には
.gitignoreへの 1 行と.worktreeincludeも入っています。どちらも範囲外です。テストも変更対象パスの外です。残すかどうかは判断をお願いします。
範囲を守る、行儀のいい報告に見える。筆者が返したのはレビューでも指示でもなく、素朴な疑問だった。
.gitignore と .worktreeinclude って今後必要になるよね？ PR 分けてもいいけど、必要じゃないっけ？
返事は「はい、どちらも今後要ります。前回『外すのがよい』と書いたのは誤りでした」。さっきまでの確信は、一往復で引っ込んだ。
範囲外の差分は、出自がばらばらだった
AI が訂正の根拠に挙げたのは、この PR の最初の commit で起きた混入だった。PR の履歴を並べるとこうなる。
- 最初の commit に、パイプラインの作業用ファイルが 4 つそのまま入った。前準備の結果を書いた JSON、PR 本文と commit メッセージの下書きなどで、JSON には手元の worktree の絶対パスまで書いてあった
- 次の commit で作業用ファイルと
.worktreeincludeを commit から外し、作業用ディレクトリを.gitignoreに足した。外したのは追跡だけで、ファイル自体は手元の作業ツリーに残る - その 20 秒後、同じパイプラインの「直し残しをまとめて commit する」工程が、残っていた
.worktreeincludeを元の内容のまま拾い直した。作業用ディレクトリは ignore したが、.worktreeincludeはしていなかった（worktree を作る直前に走る自作の hook が生成したファイル） - レビュー役の AI は「もう一度外し、
.gitignoreにも足して」と指摘した
報告役は外せ、レビュー役は外して ignore しろ、問い返した後は要るから別 PR で入れろ。同じ 5 行のファイルに、AI の答えが 3 通り出たことになる。
報告の「外すのがよい」は、2 で足した 1 行も対象にしていた。混入を止めた当の 1 行なのに、範囲外として片付けようとしていた。.worktreeinclude のほうは片付けたはずが、実際は 20 秒後に、同じパイプラインの片付け忘れ回収係が拾って戻していた。
外す・分ける・残すを比べる
「今後必要になるよね？」を差分ごとに当てていくと、範囲外の差分は 3 つの方針に分かれた。
| 方針 | この PR のレビュー | 次の実行 | 向いている差分 | 今回あてはまったもの |
|---|---|---|---|---|
| 外す | issue の範囲だけを見ればよい | 外したものが要るものなら、同じ事故がまた起きる。取り込み方によっては、混ざった最初の commit が履歴に残る | 次の実行に何も残さなくていいもの | 作業用ファイル 4 つ |
| 分ける（別 PR を先に merge） | issue の範囲だけを見ればよい | 守りは残る。先に merge しないと、その間の実行で再発する | 今回の変更とは無関係だが、repo に今後も要る設定 | .gitignore の 1 行と .worktreeinclude |
| 残す（理由を PR 本文に書く） | 範囲外が混ざるので、理由をレビューする人に渡す | 変わらない | 今回の変更を確かめるテストなど、一緒に読むべきもの | Node の版を確かめるテストと test script |
分けるときの順番も AI のほうから出てきた。作業用ディレクトリが ignore されていない間にパイプラインを回すと、また混ざる。だから設定の PR を先に merge する。実際、設定の PR を先に merge し、本体の PR はその直後に merge した。
テストは「変更対象パスの外なので、受け入れてよいか判断してほしい」と PR 本文に書かれたまま残った。残す方針は、理由を書いて人に渡すところまでが一組になる。
3 つに優劣はない。決め手は差分の中身で、「外す」が安全なのは、外しても次の実行で何も困らないものだけだ。
どこで AI に問い返すか
パイプラインの範囲チェックは、issue の変更対象パスと diff を突き合わせる。答えられるのは「この PR に属するか」までなのに、報告はそこから「外すのがよい」まで一足で進んでいた。「repo に要るか」は別の問いだ。筆者の「今後必要になるよね？」は、たまたまその 2 つ目を聞いていた。
| エージェントの言い分 | 問い返し | 今回わかったこと |
|---|---|---|
| 範囲外なので外す | 外したら、次の実行で何が起きる？ | 作業用ファイルがまた commit に混ざる |
| 範囲外なので外す | 外したファイルは、まだ手元に残っている？ | 追跡から外しただけで残っていて、20 秒後にまとめて add する工程が拾い直した |
| どちらも要ります | その理由は、今の版でも正しい？ | 理由の片方は、今の Claude Code では当たらない見込み |
3 行目は、記事を書くために公式 docs を確かめて見つけた。AI は .worktreeinclude が要る理由をこう説明していた。ローカル設定ファイル（settings.local.json）は git で ignore されている。だから worktree にコピーさせないと効かない、と。
ところが Claude Codeの設定の docs は別のことを書いている。v2.1.211 以降は、main checkout 側のこのファイルを worktree でも使う。この repo の .worktreeinclude がコピーするのは、このファイル 1 つだけだった。.env のようなほかの ignore 済みファイルを運ぶ用途なら今も意味があるが、今回の理由は当たらない見込みだ。実機では比べていない。
筆者は「分けて進めて」と返して終わり、根拠は聞き返していない。問い返しは 1 回目より、相手が同意した直後のほうが効く。
自分のエージェントに頼むなら、範囲外の差分を報告するとき「外した場合に次の実行で何が起きるか」と「外したファイルが手元に残るか、ignore されているか」を添えさせる。そうすれば、外すか分けるかを人が決める材料が報告の中に揃う。
まとめ
範囲外の差分は、外す・分ける・残すのどれが正しいかを差分の中身で決める。作業のゴミは外し、repo に今後も要る設定は別 PR にして先に merge し、変更を確かめるテストは理由を書いて残す。
AI が「範囲外なので外します」と言ったら、外したあとの次の実行を聞く。AI がこちらの疑問に同意したら、その根拠を聞く。自動化の守りを PR 単位で組むなら、PR 自動化で人が最後に見る場所もあわせてどうぞ。
