よくあるつまずき
AIに実装を任せている途中で、横から自分も少しコードを直す場面があります。軽い修正のつもりで条件分岐を足したり、変数名を変えたり、失敗しているケースだけ手元で直したりする。自分の頭の中では理由がつながっているので、そのまま続きをAIに渡したくなります。
ここで起きやすいのは、AIがその変更を十分に読み直さないまま進むことです。人間の編集を信じすぎる場合もあれば、逆に消してしまう場合もあります。どちらの結果になっても、最後に残るのは「なぜこの変更が入ったのか」が曖昧なコードです。
日常で生かせる点
SWE-Touch は、AI coding agent が作業している共有ワークスペースに、タスクと競合する小さなユーザー編集を入れて反応を見た研究です。SWE-bench Verified では、平均7行ほどのCounter-Editを入れ、ユーザーメッセージも添えたうえで、AIがその変更を検出し、必要なら直し、テストで確かめられるかを見ています。
ここから日常に借りられる見方は、「人間が触ったことをAIが自然に理解する」と置かないことです。研究が示したのはベンチマーク上の競合編集への弱さであって、三行メモの効果を直接測ったものではありません。一方で、触った場所、変更理由、確かめる動作を分けて渡すだけで、AIが読み直すべき地点はかなり明確になります。
手軽にできる第一アクション
AI作業中に自分がコードを触ったら、続きを頼む前に三行だけ残します。1行目は「触った場所」。ファイル名、関数名、条件分岐など、AIが探せる粒度で書きます。2行目は「変更理由」。何を守りたくてその編集をしたのかを短く書きます。3行目は「確かめる動作」。見るテスト、再現手順、画面操作のどれか一つで十分です。
例えば、「app/services/importer.rb の空行処理を触った」「CSVの末尾が空行のケースで落ちないようにしたかった」「既存のimport specと空行入りCSVで確認してほしい」のように渡します。正解を押しつけるのではなく、AIが自分の編集を検査できる入り口を置く感覚です。
続けるときの見方
AIが自分の変更を残したときは、安心する前に確認先を見ます。残した理由がテストや仕様と結びついているか、単にユーザーの言葉を信じているだけかを分けたいところです。AIが変更を消したときも、すぐに戻すのではなく、どの条件とぶつかったのかを聞き直します。
AIとの共同作業では、速さよりも受け渡しの丁寧さが後から効きます。人間が触ったコードにも、AIが触ったコードにも、意図と確認先を残す。小さな三行メモですが、未来の自分と次に読む人を助ける記録になります。
暮らしに置き換える
小さく試すなら
今週のAI実装タスクを一つ選び、AI作業中に自分が触った箇所が出たら、触った場所、変更理由、確かめる動作を三行で残してから続きを頼む。最後に、AIがその三行を読んで対象箇所を見直したか、関連するテストや確認をしたかだけを振り返る。
役に立つ場面
AIと自分の編集がすれ違ったとき、どちらが正しいかの感情論に寄せず、変更理由と確認先で会話を戻しやすくなります。AIに任せた作業の速度を保ちながら、意図のないコードが残る不安を小さくできます。
読むときの余白
深めるなら
- AI作業中に自分が直したファイル名と関数名を一行で残す。
- その変更で守りたかった条件を一行で書く。
- AIに続きを頼むとき、該当テストや確認手順を一つ添える。
そのまま信じないところ
- arXiv:2608.02499v1 のプレプリントであり、確認時点で査読済み表示やv2、訂正、撤回表示はない。
- 本文照合はarXivのabstractとPDF/TeX sourceで行った。arXiv HTML版は提供されていなかった。
- 研究は制御されたCounter-Editとcoding agent benchmarkを扱う。自然な共同開発で人間の編集がいつも同じ影響を持つとは限らない。
- 三行メモは記事側の読み替えであり、論文がその実践の有効性を直接検証したわけではない。
- 本番障害、セキュリティ、医療、金融など影響の大きい領域では、小さなメモだけで判断せず、人間のレビューと既存手順を優先する。