一つの不具合を任せたはずだった

一覧画面を再読込すると、同じ日時の行の並び順が変わる。 担当者がコーディングAIへ修正を頼み、別の仕事に戻ったところ、データベースの構造変更を含む大きな差分が返ってきた。 これは設計を考える想定例だ。 テストの成功通知はあるが、なぜその変更が必要で、元の不具合がどう解消したかを調べ直すなら、仕事を任せたつもりでも確認の負担が残る。

本稿は2026年4月13日までのOpenAI、Anthropic、GitHub、Google、AWSの公表資料から、この一件を調査、計画、実行、介入、受入まで追う。 各製品を同じタスクで実測した順位ではない。 コードを生成する能力に加え、人が離れている間に何が進み、戻ったとき何を判断できるかを比較する。

私の判断は、修正能力と、その作業を担当者が引き取れる形にする設計を一緒に評価することだ。 途中で方向を直せること、実行できる範囲が分かること、変更が依頼に答えた根拠が残ることがつながれば、任せる範囲を広げやすい。 長く動いたこと自体を、仕事が片付いた証拠にはしない。

人が付き添う修正と、離れて進む作業

OpenAIの2月2日のCodex app発表は、プロジェクトごとの作業、差分のレビュー、別の作業コピーを作るworktreeを示す。 利用者が複数の作業を見渡し、必要なところへ戻るための画面だ。 発表にはskillsによる手順の拡張もあるが、アプリのすべての作業がクラウドで実行されるという説明ではない。

同社の2月12日のCodex-Spark発表は、短い修正を対話しながら繰り返す用途を研究プレビューで提示した。 標準の作業スタイルでは、依頼しない限り自動でテストを行わないとも説明する。 速く書き換わることと、確認を終えた修正が返ることを分けて読む必要がある。

GoogleのJulesの2025年5月の発表は、コードをクラウドのVMへ取得し、裏で作業して計画や差分を返す形を示す。 同年8月の一般公開では、以前の環境設定を再利用する機能も説明された。 作業場所の準備を製品が持つ点が、担当者の端末で対話しながら直す場合との比較になる。

一覧の一箇所だけを直し、その場で画面を確かめるなら、担当者が付いて短く往復する方法も候補だ。 原因調査、依存関係の導入、関連テストまで時間がかかるなら、離れている間に進める仕組みが役立ち得る。 ただし、後から環境を再現できず検証し直すなら、その待ち時間や手戻りも比較へ含めたい。

計画には、変更の大きさを判断できる材料を入れる

GitHubの4月1日の更新は、Copilot cloud agentがPRを作らずブランチで作業する機能と、依頼に応じてコードを書く前に計画を提示する流れを説明する。 利用者は方針に承認やフィードバックを返し、差分を見てからPRを作れる。 調査だけを依頼する使い方も示され、調査の完了とコードの公開を分ける入口になる。

想定例では、同じ日時のデータを用意して並びを再現し、表示側の処理か、取得時の並べ方かを調べる。 既存のIDを使って同時刻の順を固定できるなら、構造変更を含む案には、その必要性を説明してもらいたい。 データベースの問い合わせを直す必要がある場合まで排除せず、問題の原因と変更範囲を対応させる。

「並び順を修正してテストする」だけの計画では、過剰な変更かを判断しにくい。 どの条件を再現し、どこを変え、何が通れば直ったとするかが分かれば、担当者は実装前に方向を直せる。 Julesも実行前や途中の方針修正を説明しているが、計画が見えることだけから、あらゆる設定で人の明示承認が必須とは推定しない。 実際に使う構成で、開始や停止の条件を確認する必要がある。

ブランチの分離と、操作できる範囲を分ける

Gitブランチは変更履歴を分ける。 worktreeは別の作業コピーを作り、VMはコマンドを動かす場所を分ける。 これらを一語の「隔離」で扱うと、履歴が分かれたことから、ネットワークや認証情報も使えないと誤解しやすい。 本番の認証情報を渡せば、外部サービスへ届く経路は別に調べる必要がある。

Anthropicの3月25日のauto mode解説は、読み込む内容への警告と、実行する操作を分類する仕組みを説明する。 ただし、許可規則に当たる操作やプロジェクト内の編集などは、分類器を通さず許可される。 モデルによる判定には残る誤りもあり、全操作が同じ検査を受ける固定の壁ではない。

Codex appの発表も、設定可能なサンドボックスと権限を説明する。 想定する並び順の修正なら、リポジトリと試験環境へアクセスする権限と、本番のデータを変える権限を分けて考えたい。 依頼文に「構造を変えない」と書くこと、人が計画を読むこと、接続自体を制限することは、異なる働きをする。 必要な境界を具体的なファイル、接続先、操作で確認する。

検証役には、実際の画面と合格条件を渡す

Anthropicの3月24日の長時間開発の報告は、計画、生成、評価の役割を分け、実装前に区切りごとの完成条件を合意する構成を示す。 評価役はPlaywrightで実際のアプリを操作し、長方形の塗りつぶしが始点と終点にしか反映されない、といった不具合を報告した。 関数が存在することと、画面で機能が使えることの差が分かる具体例だ。

この報告では、比較した実行の時間、費用、計画が広げた機能範囲も異なる。 三つの役割に分ければ、どの修正も安く速く正確になる、という測定ではない。 評価役を別にしても、同じ誤った仕様を基準にすれば、誤りを見逃す可能性は残る。

一覧の修正なら、同時刻の行、ページの再読込、別ページへの移動、既存の並べ替え操作について期待する動作を決める。 コードの形だけでなく、固定したデータで画面を動かして結果を確かめたい。 一つのテストで足りるか、別の担当者や評価役が必要かは、変更の広さと見落としの影響で決める。

調査、実装、検証を専門のエージェントへ分ける場合も、返す内容を短い結論だけにしない。 対象の版、再現条件、実行した確認、未確認の点を渡す。 別の作業コピーで通った試験を、統合後の差分の成功として扱わず、合流した変更に影響する確認を行う。 役割を増やす価値は、この引き継ぎの負担も含めて判断したい。

受け取る担当者には、異なる五つの問いがある

原因と計画

元の不具合をどの条件で再現し、なぜその変更が必要か。依頼外の変更があるなら、その理由を確認する。

環境と権限

どの版、依存関係、資源、接続先で作業したか。作業コピーの分離と、外部操作の制限を別に確認する。

差分と出所

返された変更が何を変えたか、誰に関連付けられた記録か。出所が確かめられても、内容の判断は残る。

動作と試験

元の不具合が解消したか、関連機能が通るか。実行した確認と、できなかった確認を区別する。

受入と残件

どこまで反映でき、何を誰が続けるか。実装、レビュー、公開を同じ完了通知へまとめない。

これは担当者が成果を引き取るための、本稿の整理である。 製品が五つの項目をすべて自動で保証するという意味ではない。 小さな変更でも、対象の不具合と確認した結果は短く示せる。 情報を増やす目的は、全ログを読ませることではなく、判断に必要な箇所を見つけられるようにすることだ。

GitHubの署名検証の記録に関する発表は、署名を確かめた状態をコミットに結び付けて保持する仕組みを説明する。 Verifiedの表示は、その並び順が正しいことを判定するものではない。 出所を確認した後も、差分と動作を見る必要がある。

4月10日のCopilot更新は、CodeQL、依存関係の脆弱性確認、secret scanning、コードレビューなどを並列に動かし、検証時間を20%短縮したと説明する。 同社の検証ツールについての値であり、修正から人のレビューまでの総時間が20%減った測定ではない。 こうした検査と、一覧の期待動作を確かめる試験は、異なる問題を見つける。

途中で戻れることと、実行を戻すこと

4月1日のGitHub Mobile更新は、セッションログ、PR作成・レビュー、実行中の停止を扱う。 一方、4月13日のCLIの遠隔操作は公開プレビューとして、手元で動くセッションへ別端末から指示や権限の判断を返す機能を示す。 両者の提供条件は同じではなく、遠隔操作が実行場所をクラウドへ移すわけでもない。

想定例で、途中の調査が構造変更へ向かったら、担当者は必要性を聞き、範囲を直せる。 ただし、停止したことから、すでに行ったファイル変更や外部操作まで戻ったとは判断しない。 どこまで実行し、何が残っているかを確かめて続きを決める。

セッションへ戻れること、会話を再開できること、別の実行環境で作業を復元できることも異なる。 続ける前に、作業した版、計画の変更、未完の試験を確認したい。 端末を離れて監督できる価値は、通知の多さより、必要な時点で判断材料へ届くことにある。

運用調査へ広げると、同じ差分の意味も変わる

AWSの3月31日のDevOps Agent一般提供は、監視情報、runbook、コード、CI/CDと、実際のデプロイ情報をつないで問題を調査する使い方を説明する。 これは、コードを直す前に、運用上の出来事から原因候補を調べる製品面が広がった例だ。 本稿が、事故対応の全自動化や復旧時間の短縮を実測したわけではない。

一覧の不具合がデプロイ直後に現れた場合、変更したコードだけでなく、依存関係、設定、取得したデータの条件も調べる価値がある。 ただし、時刻が近いことだけで、そのデプロイが原因とは言えない。 修正案へ至った観測と、まだ確かめていない推測を分けて渡す必要がある。

担当者が欲しいのは「原因はデータベースです」という短い断定だけではない。 どのログと版を見て、何を再現し、どの変更なら検証できるかが分かれば、次の行動を選べる。 運用情報へのアクセスを増やす場合も、調査に必要な読取りと、共有環境を変更する権限を区別して設計したい。

同じリポジトリで、修正を引き取るまで比べる

Anthropicの2月5日の実験報告は、同じClaudeモデル、同じ実行器、同じTerminal-Bench 2.0のタスクで、六つの資源設定を比較した。 厳しい制限と無制限の間で、成功率は6ポイント異なった。 資源不足による失敗の減少に加え、多くの資源を使う解法が可能になる影響も説明している。 この値を、すべてのモデルや社内修正へ当てはめることはできない。

自社で試すなら、同じ不具合、リポジトリの版、依存関係、時間・費用の上限、実行できる操作をそろえる。 返るまでの時間だけでなく、原因の調査、計画への介入、差分のレビュー、検証し直す時間も記録する。 一度成功した例だけで選ばず、訂正を伝えた場合や、依存関係を導入できない場合も含めたい。

モデルの違いを知りたい比較では、実行環境や手順をできるだけそろえる。 製品として選びたい比較では、環境準備や介入の機能の違いも記録して、総時間と受入可能な成果で見る。 二つを混ぜて、一つの点数からモデルだけの優劣を説明しない。

想定する一覧の修正では、元の条件で不具合が再現しなくなったこと、関連する確認が通ったこと、残る不確実性を把握したことを受入の条件にする。 テスト名、対象の版、結果、未実行の理由があれば、担当者は確認済みの範囲を判断できる。 これは試行の提案であり、各製品をこの条件で試験した結果ではない。

任せた仕事を、担当者が続きから引き取れるようにする

公表資料には、コード生成に加えて、計画、作業環境、差分、途中の指示、動作確認を製品へ組み込む動きが見える。 私はこれらを、人が監督しながら作業を任せるための設計として読む。 すべての製品が同じ保証を持つという意味でも、モデルの修正能力が重要でなくなったという意味でもない。

一件の不具合を任せ、途中で必要な方向を直し、返った変更を根拠とともに引き取る。 その流れが成立する範囲から、任せる仕事を広げたい。 確認する人が調査を最初からやり直さず、何を受け入れ、何を続けるかを選べることまでが、コーディングエージェントの価値になる。