コーディングAIがTODOに寄り道する｜Googleの調査から見直すコメント管理

Googleは2026年11月6日、コーディングエージェントがソース内のTODOを見て、依頼されていない課題を調べ始める現象を報告しました。AIに修正を頼んだ後、無関係なチケットの調査が増えるチームでは、モデルの変更と並んで、コードに残した作業メモを点検する価値があります。

対象は、AIを使ってWebアプリやライブラリを継続的に改修する開発チームです。最初に行うのはTODOの一括削除ではなく、参照先の課題と現在のコードを照合し、不要になった指示と残すべき設計理由を分ける作業です。本記事はGoogleの新しい調査紹介と、それを受けた実務手順の提案です。

Googleの調査が示す寄り道のコスト

Google Developers Blog「Agent Distraction」によると、調査したファイル読み取りセッションの13％で、課題番号付きのTODOやFIXMEに接触しました。接触の6％でその番号に対する後続行動があり、その83％は利用者の依頼に含まれないものでした。13％と6％と83％は分母が異なり、全セッションの83％が寄り道したという意味ではありません。

開発者や作業の種類、モデルの層、読んだファイル数などを調整した同社の分析では、依頼外の課題への寄り道は、セッション当たりのトークン77％増、待ち時間105％増と関連していました。また、課題がクローズ済みでも、現行コードにコメントの意図が残るかは履歴まで確認したと説明しています。

これはGoogleの開発環境の観測結果です。TODOを消せば自社の費用が77％減るという実験結果ではなく、特定のモデルを選べば解消するという保証でもありません。以下の分類、コマンド例、比較方法は本サイトの提案であり、Googleが公開した完成ツールや本サイトによる性能実測ではありません。

作業時間を修正と寄り道に分ける

例えば、決済画面の入力チェックを直す依頼で、AIが共通部品の古いTODOを見つけたとします。共通部品を読むこと自体は必要でも、別の画面の表示改善まで始めれば、元の依頼との関係を説明できなくなります。読んだファイル数だけを制限すると、必要な依存関係の確認まで妨げるため、行動の目的で区別します。

点検用の記録には、依頼した成果、最初にTODOを読んだ場所、その後の検索先、変更したファイル、最終的な採否を残します。「課題を見た」と「その課題を直した」は別の状態です。追加調査が元の不具合の原因特定に必要だったなら、寄り道として数えないようにします。

判断が難しい場合は、担当者に『この調査を省くと、依頼された修正の正しさを確かめられないか』を確認してもらいます。省けるが将来役立つ調査は、今回の実装に混ぜず、別の作業候補として記録します。こうすると、AIの積極性そのものではなく、依頼を完了するまでの余分な工程を観察できます。

まず対象ディレクトリのTODOを棚卸しする

Gitで管理しているプロジェクトなら、Git公式のgit grep資料に沿って、対象ファイルの文字列を行番号付きで抽出できます。次はリポジトリのルートで実行する読み取り専用の例です。拡張子と対象範囲は自分のプロジェクトに合わせてください。

git grep -n -E 'TODO|FIXME' -- '*.ts' '*.tsx' '*.js' '*.py' '*.java'

このコマンドは、通常は作業ツリー内の追跡済みファイルを検索します。文字列を探すだけなので、コメントと文字列リテラルを区別せず、課題番号のないメモも拾います。未追跡ファイルや別リポジトリまで網羅した一覧ではありません。最初はAIが頻繁に読む一つのディレクトリに絞ると、確認する量を管理できます。

棚卸し表には、ファイルと行、参照する課題、課題の状態、残っている制約、確認したコミット、担当者を記録します。行番号は編集で変わるため、後で照合する際はコメント本文も残します。課題番号の形式を統一する作業は有用でも、番号だけで内容を判定する自動削除には進めません。

クローズ済みの課題を三つに分ける

第一は、実装も移行も終わり、現在のコードに作業が残っていないメモです。該当する修正差分と現行のテストを確かめ、作業指示として不要なら削除候補にします。削除する理由をレビューへ残せば、後でコメントが消えた経緯を追えます。古い日付というだけでは、この分類に入れません。

第二は、課題を閉じた後も設計上の制約が残るメモです。例えば外部サービスとの互換性のために分岐を維持しているなら、『後で直す』という曖昧な指示より、何との互換性が必要で、いつ再検討するかを説明する注記へ直す案が考えられます。作業指示を消しても、分岐を残す理由は失わないようにします。

第三は、状態を確定できないメモです。重複課題へ移された、担当部署が変わった、参照先を閲覧できない場合などが該当します。こうした候補は確認待ちへ回し、番号が見えないことを解決済みの証拠にしません。未解決のTODOについても、今回の依頼に含まれるかは別に判断します。

コメントの履歴と実装を照合する

コメントがいつ追加されたかを調べる入口として、Git公式のgit log資料の-Sを使えます。指定文字列の出現数が変わった差分を探す機能です。次の課題番号とファイル名は仮想例で、実際の候補へ置き換えます。

git log -p -S 'TODO(PROJ-123)' -- src/payment.ts

見つけたコミットでは、コメントだけでなく周囲の条件分岐、関連テスト、変更理由を読みます。その後、課題の完了時点と現在の実装を比較します。文字列の個数が変わらない編集を、この検索だけですべて発見できるわけではありません。結果がない場合は表記の違いやファイルの移動、取得した履歴の範囲も確認します。

コメントの削除と機能修正は、できるだけ別の変更にします。コメントだけの整理でテストが変わったり、本体の分岐まで消えたりしていないかを差分で点検してください。仕様の変更が必要と判明したら、棚卸しの延長で直し切るのではなく、要求と確認方法を持つ別の実装作業として扱います。

エージェントへ渡す依頼にも完了範囲を残す

コードの整理と並行して、修正依頼には対象の不具合、触れてよい機能、満たすべきテスト、依頼外の発見の扱いを書きます。『ついでにきれいにする』という広い依頼では、何を余分な作業とみなすかが決まりません。例えば入力チェックの修正なら、共通部品を調査する必要性と、別画面の改善を実装する必要性を分けて説明します。

今回の完了条件：決済画面の入力チェックを直し既存テストを通す。
依存する実装の調査は行う。関係しないTODOは修正せず、
最終報告に場所・概要・今回の作業との関係を記す。

この例は特定エージェントの設定仕様ではなく、依頼文の書き方です。文章を付けるだけで行動が固定されるとは考えず、実際の検索と差分を見ます。また、依頼外と判断した箇所が修正対象の前提を壊しているなら、必要な確認まで禁止せず、その関連を報告させる運用にします。

効果は削除件数ではなく完了した変更で測る

比較の出発点は、似た種類の修正を集めた小さな作業セットです。同じモデル、同じツール構成、同じ完了条件で、コメント整理前後のコードを使い、トークン、待ち時間、依頼外の調査回数、採用できた変更の割合を記録します。整理と同時にモデルを替えると、どちらの影響か切り分けにくくなります。

一つの修正だけで結論を出さず、TODOを読む作業と読まない作業を分けて見ます。再実行による慣れや揺らぎを考慮し、失敗した実行も集計から落としません。費用は、最初の生成に加えてやり直しと人の手直しを含め、受け入れた変更一件当たりで比較する案が現実的です。

速く終わっても、互換性の注記を失って不適切な修正が増えれば採用できません。整理前に守れていたテスト、レビューで見つかった仕様の取り違え、元に戻したコメントも合わせて確認します。改善が見えないときは削除範囲を広げる前に、そもそもAIがそのコメントを読んでいたか、費用の大半が別工程にあるかを調べます。

削除案には再確認できる根拠を付ける

整理用のプルリクエストには、対象のコメント、関連課題、完了を示す変更、現行コードで残す理由がないと判断した根拠を短く書きます。例えば「課題が閉じたため」だけでなく、「移行処理は別コミットで完了し、この分岐を使う呼び出しも現行コードにはないため」と説明できるかを確認します。これは説明用の仮想例であり、検索結果だけで到達できる結論ではありません。

レビューで意見が割れた候補は、無理に削除せず担当者の確認へ戻します。コメントを残す場合も、誰がどの条件で再検討するかが分かる注記にできるかを相談します。同じ課題に結び付くコメントが複数のファイルにあるなら、一覧で対応関係を確認し、一か所だけ直して矛盾を作らないようにします。

新しいTODOが古くなるまでの流れを変える

継続運用では、新しく追加するTODOに参照先と残っている作業を持たせ、課題を閉じるレビューで対応するコメントも確認する方法を提案します。最初から全件をCIの失敗条件にすると既存分の処理で止まりやすいため、まず新規追加分の形式と参照先の有無を確認し、過去分は別の棚卸しとして進めます。

定期点検の出力は、削除パッチの自動投入よりも、根拠付きの候補一覧から始められます。候補ごとに、課題の状態、確認した実装、削除または書き換えを勧める理由を残し、コードの所有者が判断します。課題サービスを照会できなかった候補は未確認とし、状態が変わっていないかレビュー時にも読み直します。

当面の着手点は、直近でAIが余計な調査をした一件を選び、その起点となったメモを調べることです。依頼範囲を明確にし、コメントの意味を確かめ、小さな整理前後の差を測る。この順序なら、チームのコードに必要な説明を残しながら、AIが本来の修正を終えるまでの負担を検討できます。

関連記事

AI開発の待ち時間はどこにある？Scionの事例から見直すGitとCIでは、ソース取得やCIの待ち時間を分解しています。今回のコメント由来の寄り道と、開発基盤側の待ち時間を切り分ける際の参考になります。

参考資料

Google Developers Blog：Agent Distraction（2026年11月6日公開）
Git：git-grep Documentation
Git：git-log Documentation
資料確認日：2026年11月8日。調査数値はGoogleの報告であり、棚卸し・依頼文・比較運用は本サイトの提案です。