Michael Johnsonエージェントにタスクを任せ、リポジトリへの変更を待ち、レビュー用のプルリクエストの下書きを受け取ることができます。しかし、コードとともに疑問も生じます。成果はタスクに沿っているのか、テストでは重要な問題を見落としていないのか、という疑問です。
2026年2月4日、GitHubはClaudeとCodexをコーディングエージェントとして公開プレビューにしたと発表しました。同社によると、エージェントにissueやプルリクエストからタスクを割り当て、そのエージェントが用意したPRの下書きをレビューできます。これは、こうした使い方が開発インターフェースに登場したことを示していますが、時間の節約やコード品質の向上を証明するものではありません。
したがって、問われているのはエージェントがコードを書けるかどうかだけではありません。委任したタスクの周辺で、人間はどのような作業を担わなければならないのか。制約を設定し、作業の進捗を見守り、成果を評価する必要があります。
監督は最終確認だけではない
2026年9月21日にarXivで公開されたプレプリントでは、研究者たちがコーディングエージェントの監督を、一連の工程として捉えることを提案しています。The Work Behind Delegationは、経験豊富な開発者19人の観察とワークフロー図に基づいています。著者らは監督を7つの段階に分け、この枠組みをReddit上の開発者による公開の議論に適用しています。
著者らが挙げるアプローチには、計画により多くの注意を払うこと、監督タスクの一部をほかのエージェントに任せること、繰り返し使う指示を再利用可能な資料にすることなどがあります。これは分析の枠組みであり、時間コストを測定したものではありません。この研究は、開発者が監督にどれだけ時間を費やすのか、またそのプロセスが手作業より速いのかを明らかにしていません。arXivのページでは査読中とされているため、結論は暫定的なものとして扱う必要があります。
実務上は、3つの行動を区別すると役立ちます。タスクの設定では、目的と制約を定めます。監視によって、エージェントが意図から逸れていないかを把握します。検証では、要件、コード、テストを踏まえ、成果を受け入れられるか評価します。ある段階での成功が、次の段階での成功を保証するわけではありません。パッチがもっともらしく見えても、課題を取り違えていたり、大幅な修正が必要だったりすることがあります。
コミュニティの経験は統計ではない
r/LocalLLaMAでの議論では、ある参加者が、ローカルモデルやエージェントを使った経験は期待外れだったと述べています。その人によると、成果を修正し、指示を守るようエージェントに念押しする必要がありました。同じスレッドのほかの参加者は、タスクの範囲を絞る、段階的に進める、コードを慎重に確認するといった、自分にとって有効だった進め方を紹介しています。これらは個々のユーザーの観察であり、モデルを比較するテストでも、チームの生産性を測定したものでもありません。
こうした異なる反応は、タスク、モデル、環境、作業方法によって経験が変わりうることを示しています。しかし、一つの議論だけでは、どの実践が平均的により効果的なのか、問題がどれほど頻繁に起きるのかは判断できません。このスレッドはローカルモデルを扱っているため、そこでの観察をあらゆるエージェント型ツールにそのまま当てはめるべきではありません。
人が関与しているからといって、委任が無意味とは限りません。開発者はタスクを分割し、変更を確認し、要件を明確にしながら、最終的な結果に責任を持つことができます。しかし、タスク設定、修正、レビューにかかる時間を考慮しなければ、作業全体が減ったかどうかはわかりません。
PRの下書きは、まだ受け入れられたPRではない
GitHubが説明したシナリオでは、エージェントにissueを割り当て、プルリクエストの下書きを受け取ることができます。下書きの作成から受け入れまでには、別途確認すべき点があります。変更は要件を満たしているか、エッジケースを考慮しているか、テストは十分か、プロジェクトのアーキテクチャに合っているか、といった点です。
これらの基準を一つの指標にまとめることはできません。作成された変更の数は、実用に耐える変更の数と同じではありません。また、テストに通ったからといって、パッチの重要な特性がすべて確認されたとは限りません。見た目のよい成果であっても、準備と検証にどれだけの作業が必要だったかは、それだけではわかりません。
全体的な効果を評価するには、タスクの設定、結果を待つ時間、レビュー、修正、その後のコード保守というサイクル全体を考慮する必要があります。ここで取り上げた情報源は、そうした全体的な比較を示していません。
何が言えるのか
プレプリントは監督について議論するための枠組みを提示し、GitHubはエージェントにタスクを割り当て、用意されたPRを確認するシナリオを発表しました。Redditでの議論では、ローカルモデルの利用について、個々のユーザーが困難と有用な方法の両方を語っています。これらの情報から、委任したコードの検証をどう組織するかという問いは立てられますが、純粋な生産性について答えを出すことはできません。
開発者全般がすでにコードを書く仕事から監督へと移った、エージェントは必ず追加作業を生む、あるいは業界全体の生産性を高める――といった結論は、これらの情報からは導けません。そのような判断には、異なるタスクやチームを対象に、時間と品質を比較できる測定が必要です。
チームにとって実務的な問いは、もっと具体的です。エージェントにどの変更を単独で準備させられるのか、マージ前に何を確認すべきか、成果が最初の課題を解決していることに誰が責任を持つのか。委任によってこのエンジニアリング作業がなくなるわけではありません。作業が始まる場所と、焦点を当てる対象が変わるのです。