GitHub Copilot の Agent mode の勘所

モンスターハンターワイルズの力の護符と守りの護符をいつの間にか取っていたものの、ずっとアイテムBOXの中に入れていて取り出さないとダメ、ということに HR 70 になってから気がついた柴田です。

今日は最近紹介記事をよく見かける AI Agent による自動コーディングについて実際に試してできたコードや感想についてご紹介します。

GitHub Copilot の Agent mode

勤務先のアンドパッドではエンジニア全員が GitHub の Copilot のビジネスプランを使用することができます。私も GitHub の Copilot を VScode から利用しており、同じようなコードの繰り返しなど、「ここでこういう処理を書いてほしいなあ」と想像したものと大体同じコードを補完してくれるので便利に使っています。

一方で Copilot Edits や最近 Preview で追加された Edits の Agent mode などについてはよくわかっておらず、Cline など流行っているし、エンジニアに AI によるコーディングのみを1週間実行してもらう、というような面白い話も見かけたので自分も同じように試してみた、というのが今回のエントリです。

最初に GitHub Copilot の用語の整頓からです。

GitHub Copilot: GitHub が提供する AI 機能全体を指す総称
GitHub Copilot の VScode 拡張: AI によるコードの補完機能、Copilot と呼ぶとこの機能を指すことが多い
GitHub Copilot Edits: AI によるコード生成、コード修正の機能、指定した範囲やファイルを読み込み、指示することでコードを生成する
GitHub Copilot Edits Agent mode: Edits の機能に加えて、コンソールでのコマンド実行やその結果を自己解釈して半自動でコードを継続的に生成する

上記の通り、Cline に相当するものは Edits の Agent mode です。なお、私は Cline は試したことがなく、他社のテックブログなどのエントリで読んで理解した、というレベルというのをご容赦ください。

Agent mode の準備

Agent mode は VScode insider 限定の機能です。自分は日頃から insider バージョンを使っているので、必要なものは GitHub Copilot 拡張のみと特に準備は不要でした。実際に使うときは macOS の場合はアイコンやメニューから Edits のサイドパネルを表示します。なお、私は「Cmd + Shift + I」のショートカットで起動することが多いです。起動直後は Edits になっている場合があるので Agent に変更します。

Agent mode に変更後に使用するモデルを選択します。2025年3月11日時点では、「Claude 3.7 Sonnet」、「Claude 3.5 Sonnet」、「GPT-4o」の3つを選ぶことができます。ただし Claude 3.7 と 3.5 は Preview という扱いです。

Cline の紹介エントリを見ると、Agent に何かをやらせるサイクル、イテレーションごとに金銭的なコストが発生するようですが、Copilot の Agent mode ではどれを何回使っても元々の Copilot の使用費用以上のコストは発生しません。しかし、それぞれのモデルに Rate limit は入っているようで Claude 3.7 を使っていると、割と早い段階で Rate limit に引っかかるようです。その場合は大人しく 3.5 に切り替えて使用を再開することにしています。この辺は Preview バージョンということもあり、今後変わる可能性は十分にあります。

さて、実際にコードをいくつか書かせて出来上がったものや所感を紹介します。なお、試していた時の Copilot Edits の Agent mode ではコンテキストをプロジェクトごとに事前に共通で与えるということができないので、プロジェクトとそのファイル、あとは指示で Web ページを読んで実行せよ、というような都度の指示になるということを念頭においていただけるとありがたいです。

利用事例1: HTML と CSS 中心のリポジトリ

試した例の1つ目は GitHub pages でデプロイしている Rails Girls JP の公式サイトです。

github.com

このサイトは素朴な HTML と CSS で作られていますが、Bootstrap 3 や jQuery などが残っているため、これらの書き換えを行ってみました。

「Bootstrap 3 を 5 にアップデートしてください」と指示
- https://github.com/railsgirls-jp/railsgirls.jp/pull/864/commits/ec5d5705ae421a1d7916d1296a9f4002a62bbf1d
「参照されてない不要なファイルが残っているので消してください」と指示
- https://github.com/railsgirls-jp/railsgirls.jp/pull/864/commits/95e366d2c04cb547cba102c3c04f41656939e5aa
「jQuery を消しても動くようにしてください」と指示
- https://github.com/railsgirls-jp/railsgirls.jp/pull/865/commits/0b32300b6785470a2e4fa5bc4e95196104750ea1

上記のうち、Bootstrap 3 から 5 への書き換えは必要な要素については適宜置き換えを行ってくれたものの、「ヘッダをもう少し広くしてほしい」「グリッドの間隔をもう少し広げてほしい」のような視覚的な修正については、何度指示をしても Agent が期待通りの変更をしてくれることはなく、自分で mergin や padding を調整するという作業が必要でした。この辺は Copilot の Vision 機能などによって解決されるかもしれません。

また、不要なファイルを消してください、というような CSS の参照を見つける処理は機械にとっては即座にできるものの、人が確認する場合は目視であったりツールを組み合わせる必要がある、というような作業をやらせるのはとても便利でした。

Copilot の Agent mode では、テストの実行やファイルの削除のような実際にコマンドを実行する時には上記のように確認処理が必要です。

利用事例2: Bundler のプラグイン作成

2つ目は0からコードを作るということを試してみました。前回のエントリで紹介した SBOM を Gemfile の lockfile から生成する Bundler のプラグインがお題です。空のディレクトリに対して以下のような順序で指示をしていきます。

「Bundler の lockfile から SBOM を生成する Ruby スクリプトを書いてください」
「作成したスクリプトが SBOM の仕様に準拠しているかを確認するテストを RSpec を使って書いてください、カバレッジは 98% 以上にしてください」
「作成したスクリプトとテストを Bundler の plugin として使えるようにしてください」

この時点で lockfile をパースしてそれっぽい SBOM を json で作成してテストを実行するというライブラリが出来上がりました。感心したのはカバレッジの指定をしたところ以下のように simplecov を導入して実行結果のパーセンテージを解釈して 98% に足りなければテストを追加して再実行して、足りなければ、というのを達成するまで繰り返したところです。

https://github.com/hsbt/bundler-sbom/commit/cd17d5b1dc347d41285889124f64ada5ae6dcfaf

このライブラリは全てを Agent にやらせる、という意気込みでやったもののどうしても解決できない箇所があり1つだけありました。具体的には、以下のようにサブコマンドを持つ Bundler の plugin を想定していましたが、Agent に何度やらせても動かないコードしか生成しません。

$ bundle sbom dump --option

Agent mode では解決できない問題に陥ると、存在しないメソッドをそれっぽく組み立てて作り、テストの実行時にエラーを検知して、再び適当なコードを書いて、というループに陥ります。

そこで Bundler: How to write a Bundler plugin を読み込んで作るように指示をしましたが、それでも動かないコードしか書きません。正解を書いてしまうと、今回のケースでは以下のようなコードを期待していましたが、Bundler の公式サイトにも thor を使ったサブコマンドを持つ Bundler plugin の書き方はガイドとして存在していないため、Agent は生成することができないのかもしれません。

# lib/bundler/sbom/cli.rb
module Bundler
  module Sbom
    class CLI < Thor
      desc "dump", "Generate SBOM and save to file"
      def dump
        ...
      end
      ...
    end
  end
end

# plugins.rb
require "bundler/sbom/cli"

module Bundler
   module Sbom
     class Plugin < ::Bundler::Plugin::API
       command "sbom"
 
       def exec(command_name, args)
         ::Bundler::Sbom::CLI.start(args)
       end
     end
   end
 end

この辺は最初の例のように Bootstrap のバージョンをアップデートせよ、というような知見が潤沢な領域には強いが世界で誰もやってないようなこと、は当然のように弱いということと思います。

気を取り直して、この後も引き続き以下のように指示をしてコードを生成していきます。

「SPDX だけではなく CycloneDX も生成できるようにしてください」
「ライセンス情報のサマリを表示する機能を追加して」
「JSON だけではなく XML も生成できるようにして」
「README を書いて」

どんどん指示が雑になっていきますが、Agent は文句も言わずにどんどんコードを書いてくれます。Agent によるコーディングの一番すごいところはカバレッジを向上させる時もですが、人間なら「飽きた」「つまらない」というような内容でも黙々と作業をするところにある気がします。

一方で、Copilot の Agent mode はコンテキストを事前に与えることができないので、機能を追加するたびに「テストはカバレッジ 98% をキープしてますか?」であるとか「行末のスペースは消してください」というように、マイクロマネジメントをしなくてはいけません。

この辺は Customize chat responses in VS Code でプロジェクトごとにコンテキストを与えられるようになったので、プロジェクトごとの決まり事などは指示を与えなくてもこなしてくれる気がします。

また気になった動きとしては、RSpec には and.return というメソッドはないのですが and_return だと思って、何回も間違えるということに遭遇しました。その度に動かないので直しますというのを見て苦笑いしていましたが、RSpec のドキュメントを同様にコンテキストとして与えれば直るのを期待します。

github.com

最終的に完成したものはこちらです。機能としては大体動いているな、というものができたので Agent を使ったコーディングの体験としてはちょうど良いサイズだったと思います。

まとめ

コードを書く人全員が AI Agent によるコーディングができるようになるべきか、は「仕事の内容と立場によるのでなんとも言えない」という感想になりましたが、使ってみた、という文章を読むだけではなく体験としてやってみないとわからない部分が多数あり、パラダイムシフトがありそうという箇所は多数あるなと思います。

これまでプログラムを書くときは人が読んでコードを書くために、認知負荷を下げる目的でフレームワークを利用したり、デザインパターンのようなものを見出して導入したりと、長きにわたって工夫してきました。ところが Agent にコードを書かせると Ruby のクラスメソッドだらけのベタっとしたコードを大量に生成してきます。とても人が後から読んでメンテできるようなものではありません。

最初は「このコードをメンテし続けるのはキツイな」とも思いましたが、Agent に命令してひたすらコードを書かせていくと「別に人間が理解しなくても、仕様をちゃんと検証できるならそれで良いのではないか?」とも思ってきました。人間が理解しなくて良いならコードは Agent が高速に理解して、コードを生成できるように人間がお膳立てするということに時間をかけた方が合理的です。

Agent によるコーディングを上手に使うコツは「ルンバが掃除をしやすいように部屋を片付ける」という例えを見てその通りとも思いましたが、今回 Copilot の Agent mode を試して対象とするプロジェクトで気に掛けた方が良い点は以下のようなことです。

GPT-4o はコード生成では使い物にならないので Claude 3.7/3.5 Sonnet のどちらかしか選択肢にならない
機能を作る時には動かないコードを検知する対策として Copilot にコードを生成させてはテストなどを実行させて結果を見るというサイクルが必須、カバレッジ100%でも良いくらい
試行を繰り返させて、自己修正させることが効率化につながるのでテストはとにかく速く、ローカルのみで実行できる方が良い
Lint などをやらせても別に追加コストはかからないのでどんどんやらせる、どちらかというと実行のボタン押下の関心を奪う方がロスなのでエディタの機能でやらせた方が良い
Agent mode の処理が完了すると、途中に与えていた指示が全て消えてしまうのが不便。動かしてみたらダメだったので git reset してもう一度、というときに思い出して打ち込む必要がある
処理が終わるたびに git commit を忘れない、ちょっと方向性をミスるとどんどん壊していくのですぐに戻せるようにしておく
プロジェクト内を読み込んで必要なコンテキストを生成するので、モノレポであるとか、複数のディレクトリを色々追加しているプロジェクトだと「ちょっと違うんだよな」というコードを生成しがちなので、プロジェクトにちょうど良いディレクトリ構造とファイル配置の勘所をつける必要がある
指示の与え方によってはコード生成、テスト失敗、コード生成...というような無限ループに陥って Rate limit エラーになるので、適当に解ける問題のサイズを順序よく与えることが重要

以上、Agent によるコード生成を1週間程度試してみた、というエントリでした。実際にサービスとして動いている Rails アプリケーションに対して「〜という機能を作って」という使い方をして、実現をする場合の勘所はまだまだ試行錯誤しないと身につかない感触があります。

過去に RPA や補完機能としての Copilot が登場した時はそれほど気持ちは動きませんでしたが、私はパッとコードを書いて解決するという瞬発力が低いので、Agent mode を使うようになってからはまず最初に指示してそれっぽいコードを作らせる、ダメなときは調整するという動き方になり、コードによって解決できる領域がとても広がったように感じます。

Cline の情報はだいぶ充実してきたように感じますが、Copilot Edits の Agent mode はまだ insider 向けかつ preview バージョンなのでまだまだこれから、と思います。今回ご紹介したような事例に対する解決策は実はある、などあったら教えていただけると助かります。