GitHub の Developer Relations チームに所属するデベロッパーアドボケイトが GitHub のブログに書いた記事で、Rubber Duck Thursdays のライブ配信に付随するものである。その配信で著者は、別々のリポジトリにある Next.js の Web アプリと対応する SwiftUI の iOS アプリからなるアプリケーションを、英語、フランス語、スペイン語にローカライズした。記事は 2025 年 7 月 1 日に公開され、2025 年 8 月 1 日に更新された。記事の位置づけは実践的なものである。GitHub Copilot のエージェント型機能は、開発者と機能のリリースとの間に立ちはだかる定型コード、リファクタリング、「下準備」を引き受けさせる手段として提示され、その一方でレビューとマージは開発者が引き続き担う。
このウォークスルーは、4 つの機能を issue からプルリクエストに至る 1 つのループにつなげている。Copilot による issue の起草、その issue の GitHub Copilot コーディングエージェント への引き渡し、VS Code におけるカスタムの計画用チャットモード、そしてリモートの GitHub MCP サーバー である。
要点
- 著者がエージェント型ワークフローの理由として挙げるのは、漠然とした要望を適切に範囲を定めた issue に落とし込むこと、横断的なリファクタリングで関係するファイルをすべて探し出すこと、同じ単体テストの足場を何度も書くことに、チームが今なお何時間も費やしているという点である。
- 最初のステップは、github.com で Copilot に要望を説明し、概要、受け入れ基準、変更が必要なファイルへの手がかりを含む GitHub issue を起草させることである。
- その issue を割り当てられると、coding agent はブランチを作成し、セッションを開始し（
copilot-setup-steps.ymlがあれば最初に開発環境を構成する）、コードベースを探索して計画を立て、リポジトリのカスタム指示をコンテキストとして用い、ドラフトのプルリクエストを開く。 - 記事は、そのプルリクエストを他のプルリクエストと同じようにレビューすることを求める。説明と変更されたファイルを読み、エージェントのセッションを見てそのアプローチを理解し、Codespace で、あるいは既存の CI を通じてテストする。そしてコードを実行する前にレビューする。
- エージェントが見落としたハードコードされた文字列を著者が見つけたとき、その修正はそれらのローカライズを求めるレビューコメントを付けることだった。エージェントはこれを拾い上げ、別のセッションで対応した。
- 当時 VS Code 1.101 でプレビュー段階にあったカスタムチャットモードは、指示と許可するツールを
.chatmode.mdファイルにまとめ、そのファイルはデフォルトの Ask、Edit、Agent モードと並んで表示される。VS Code チームの例を改変した著者の計画用モードは、コードを編集せずに実装計画を生成し、それを GitHub issue として登録することを提案する。ワークスペースに置いておけば、このモードはリポジトリを通じてチームメイトと共有される。 - リモート GitHub MCP サーバーは、npm パッケージや Docker コンテナを通じて MCP サーバーを動かすというローカルのセットアップをなくす方法として提示されており、個人用アクセストークンの代わりに OAuth 2.0 認証を用いる。
- 記事は、割り当てられたタスクに非同期で取り組む coding agent と、エディタ内で同期的に協働する Copilot のエージェントモードとを区別している。また、Xcode で iOS アプリに国際化を加えた以前のエージェントモードのセッションも簡単に紹介している。
- すべきこととすべきでないこととして、エージェントに「アプリを再設計する」よう求めるのではなく issue の範囲を厳密に絞ること、エージェントが意図を理解していると想定するのではなく受け入れ基準を示すこと、コードを実行したりマージしたりする前に変更を慎重にレビューすること、そして最初から完璧を期待するのではなく反復することを挙げている。
背景
この記事は評価ではなく、ベンダーの実務家によるデモの記録である。その根拠はライブ配信された 1 つのローカライズ作業であり、推奨事項は著者自身のものである。記事は、エージェント型ワークフローは魔法ではなくツールだと述べて締めくくられている。