修正を任せるとき、人は何を確認するのか

コーディングAIに不具合の修正を任せると、コードの提案に加えて、依存関係の導入、テスト、コミットまで進む場合がある。 そのとき「人が監督できる」とは、単に完了通知を受け取れることだろうか。 本稿では、計画を直す機会、実行できる操作の範囲、返された変更の検証を分けて考える。

例として、一覧画面の並び順を直すタスクを想定する。 担当者は表示処理の修正を期待していたのに、エージェントがデータベースの構造変更を計画したなら、実装前に方向を直す価値がある。 ただし、この確認方法がすべての小さな変更に必要だとは限らない。作業範囲と、間違った場合の影響に応じて決める。

計画を読めることと、実行を止めることを区別する

Julesの計画レビューの説明では、コードを書く前に計画を提示し、利用者がフィードバックできる。 一方で、ページには時間経過による自動承認の説明もある。 レビュー画面があることだけから、人の明示承認がなければ絶対に実行されないとは判断できない。

先ほどの修正でデータベース変更を許可しないなら、その条件を指示に書くだけでなく、実行環境から本番データベースへ接続できるかも調べる。 人が計画を読む機会と、ソフトウェアが操作を拒否する制約は別の働きをする。 製品の設定や仕様は変わるため、実際に使う構成で停止条件を試す必要がある。

ブランチ、VM、署名が保証するものは異なる

Gitブランチは変更履歴を分ける仕組みであり、コマンドが読めるファイルや接続できるネットワークを隔離するものではない。 Julesの環境説明が挙げる短命のVMは、リポジトリ取得や依存関係の導入、テストを行う実行環境である。 ブランチの分離とVMの分離を、同じ「隔離」の一語で済ませるべきではない。

VMやコンテナを使っても、渡した認証情報で外部サービスを変更できる可能性は残る。 確認したいのは、実行場所に加えて、どのファイル、認証情報、接続先を利用できるかである。 テスト用の環境で修正を作る権限と、本番へ反映する権限を必要に応じて分ける。

コミットのVerified表示も別の確認である。 GitHubの署名検証の説明では、署名を暗号学的に検証できたことを示す。 この表示は、並び順の修正が正しいことや、テストが十分であることを証明しない。 変更の出所を確かめた後にも、差分と動作を確認する必要がある。

テスト結果には、実行条件も添える

実行環境は性能評価にも影響する。 Anthropicの2026年2月5日の実験報告では、同じClaudeモデル、同じハーネス、同じTerminal-Bench 2.0のタスクで資源設定を変え、厳しい制限と無制限の構成の間に成功率6ポイントの差が出た。 これは同社の実験条件での結果であり、すべてのモデルや業務に同じ差が出るという意味ではない。

自社の修正タスクでも、テスト失敗がコードの誤りなのか、依存関係を導入できなかったのか、メモリ不足なのかを分けて記録したい。 テスト名、実行した版、結果、未実行の理由が残れば、レビュー担当者は確認済みの範囲を判断できる。 「テスト済み」という一文だけでは、その範囲が分からない。

並び順の例なら、対象の不具合を再現する確認と、既存の関連チェックを通し、実際の差分が依頼の範囲に収まるかを見る。 計画、操作権限、署名、テストは、それぞれ違う問いに答える。 この違いを保ったまま必要な確認を組み合わせることが、コーディングAIの作業を引き受ける側にとって有用だと考える。