バグ報告はたいてい何日も追跡システムに寝たままで、そのバグが潜むファイルを誰かが開くのはずっと後のことになる。そして実際にコードを書き換える時間は、修復という作業全体のうちで一番短い章であることが多い。日程を食いつぶすのは、その周辺にあるものだ。ブランチを切り、なぜこの変更が必要なのかを説明するコミットメッセージを書き、Push し、Pull Request を開き、差分をレビューする人が意図を逆算しなくて済むところまで説明し、返事を待ち、指摘に沿ってもう一巡直す。どれも難しくはない。しかし積み重なると、一日の仕事を考え事のできない細切れに変えてしまう。

GitHub Copilot のコーディングエージェントが狙っているのは、まさにこの細切れになった中間部分だ。公式の位置づけは字面どおりに受け取ったほうがいい。期待を置く場所が変わるからだ。これはエディタの中で次の質問を待っている入力欄ではなく、タスクを引き受けてバックグラウンドで最後まで自分で運ぶ役割であり、その間こちらは別のことに手を回せる。

Issue を渡して、Pull Request を受け取る

仕組みは地味だ。ある Issue を Copilot に割り当てるか、どの画面でもよいのでエージェントパネルからタスクを起こす。すると Issue のタイトル、本文、すでに付いているコメントを持って着手し、自分専用の一時的な開発環境の中でリポジトリを見て回り、計画を立て、手を入れ、最後に Pull Request を開く。終わるとレビュー担当としてこちらを登録し、通知を出す。受け渡しが、実際に目に入る場所に落ちてくるわけだ。

その環境は継続的インテグレーションの仕組みで動いている。つまりこちらの目に入る前に、そのプロジェクトのテストと静的チェックを走らせられるし、リポジトリに書いてある準備手順どおりに作業環境を先に整えることもできる。データベースと裏方のサービスが動いていないとテストが通らない、という案件でも、その準備を当て推量にしないで済む。

要件が動いたときに引っかかりやすい点がひとつある。割り当てた後に Issue へ足したコメントは、エージェントには届かない。追加の依頼は、エージェントが開いた Pull Request の側に書く。そこに一言残せば新しいセッションを起こして対応するし、同じ Pull Request 上の過去のセッションの文脈は保持されるので、二回目の依頼のほうが速く、誤読も少なく着地しやすい。継続的インテグレーションのワークフローが落ちたときも同じ経路が使える。失敗を渡せば調べに行き、修復を Push してくる。

世に出る前に、自分で読んでおく

機械が書いた変更をレビューするのが疲れるのは、明らかに壊れているからではない。動きそうに見えるのに、チームの誰もそうは書かない、という形で来るからだ。公式の構成では、Pull Request を開く前にコーディングエージェント自身がコードレビューの機能で自分のパッチを読み、返ってきた指摘で反復改善する。こちらがレビュー担当に加わる時点で、すでに一巡は済んでいる。

同じ流れの中で、コードスキャン、シークレットスキャン、依存パッケージの脆弱性チェックも走る。既知の問題を抱えた依存や、うっかりコミットしてしまった認証情報らしき文字列は、レビューする人が見つける前ではなく、Pull Request が見えるようになる前に印を付けられる。

チームのやり方を設定ファイルに落とす

短いプロンプトは、その場の判断に大きな余地を残す。そしてその場の判断は、チームの実際のやり方と一致するとは限らない。そこを固定するのがカスタムエージェントだ。リポジトリに設定ファイルをひとつ置けば、ある種類のタスクをどの順番で進めるかを指定できる。たとえば性能改善のエージェントなら、まず計測し、次にコードを変え、変えたあとにもう一度測って効果を数字で示し、それからようやく Pull Request を開く、といった段取りになる。この設定は組織や企業の単位で共有できるので、別々のチームが私有の手順を何本も抱えるのではなく、ひとつの流れに寄っていく。

デスクトップでは、セッションが横に並ぶ

同時に走るタスクが増えると、難しさは「どう分けておくか」に移る。デスクトップアプリは Issue、Pull Request、ひとことの指示、過去のセッションのいずれからでも作業を起こせて、複数のエージェントセッションを並行して走らせられる。セッションごとに独立した作業ツリーとブランチを持つので、ファイルも会話もタスクの状態も混ざらずに済む。Windows、macOS、Linux 向けのビルドがあり、変更は統合ターミナルとブラウザで確認でき、開かれる Pull Request はチーム既存のレビュー、チェック、マージのルールをそのまま通る。

コーディングエージェントはバックグラウンドでタスクを引き受け、ブランチ作成からコミット、Pull Request の作成までを、横から指示されずに一人で歩く。

受け渡し前の自己点検はまずコードレビューで反復改善し、そのうえでコード、シークレット、依存のスキャンを回す。

並列セッションはデスクトップの各セッションに作業ツリーとブランチを分け与え、同じファイルを同時に触らないようにする。

費用はどうなっているか

個人向けのプランは 2026 年 6 月から従量制に変わり、無料の Free から Pro、Pro+、Max まで並ぶ。Free には補完の回数に上限があり、チャットとエージェントの利用にも上限があるが、コマンドラインツールとエージェントモードは付いてくるので、まず試すのに費用はかからない。有料プランでは基本の枠が購読料と一対一で対応し、その上にコストに応じて動く柔軟な枠が乗る。補完と次の編集の提案は有料プランでは無制限で、枠も消費しない。細かい段階と数字は公式の料金ページが唯一の拠りどころだ。

コードを書くことは仕事の半分にすぎない。残りの半分は、変更をレビューとチェックとマージの向こう側へ通すことだ。この仕組みはその後半も引き受けるので、人は本当に判断が要る場所にだけ顔を出せばよくなる。