for Startups Tech blog

このブログのデザインを刷新しました。(2023/12/26)

【AI駆動開発】GitHub Copilotだけでやり切るAgentic(Vibe)Coding

目次

はじめに

こんにちは。フォースタートアップス株式会社エンジニアの野尻(@jsotakebmx)です。ヒューマンキャピタル支援システム(社内プロダクト)の開発を担当しています。

現在、AIツールが全く利用されていない開発組織はほぼ無いと言っていいほど、AIはエンジニアにとって身近な存在になりました。しかし、導入されているAIツールは以下の様に組織によって様々ですよね。

  • AI先進企業DevinClaude Codeのような最新のAIエージェントや、複数のAIチャットツールを自由に使いこなしている。GitHub Copilot Enterpriseが導入されている。
  • AI導入企業ChatGPTGeminiなど、特定のAIチャットとGitHub Copilot Business(もしくはEnterprise)が導入されている。
  • AI導入中企業::申請ベースで最低限のAIチャットツールとGitHub Copilot Businessが利用できる。
  • AI未導入企業:全くAIツールが導入されていない。

バズるテックブログやSNSの投稿を見ているとほとんどの組織がAI先進企業であるように錯覚しますが、実際のところは多くの組織がAI導入企業に当てはまり、あくまで体感ですがGitHub Copilotが標準的なツールとして導入されているのではないでしょうか。

最新のDevinやClaude Codeのような新興AIエージェントの(進化の早いAI界隈ではDevinなど新興ではないのかもしれないですがw)活用事例を目にするたびに、こう感じているエンジニアも少なくないはずです。

「すごいな… でも、うちの会社では高度なAIエージェントは使えないし、自分には関係ないか…」

いや、諦めるのはまだ早いかもしれません!

未だGitHub Copilotのイメージは「高機能なコード補完ツール」で止まっている人もいるのではないでしょうか。しかし実際にはGitHub Copilotのポテンシャルはもっと先にあります。

この記事では、多くの開発現場で再利用可能なGitHub Copilotを最大限に活用し、自律的なAIエージェントのように振る舞わせる「AI駆動開発」の実践方法についてご紹介します。

AI駆動開発の3つのレベル

まず前提としてAIによるコーディングスタイルは、大きく3つのレベルに分類できます。

  1. コーディングサポート
    • コードの補完や簡単なスニペット生成など、最も基本的なスタイル。
  2. Vibe Coding
    • 「いい感じにやっといて」といった抽象的な指示に対してAIがコーディングを進める。人間は細かいフィードバックを与えながらゴールを目指すスタイル。
  3. Agentic Coding
    • ゴールを伝えることで、AIが自律的にタスクを分解・計画し一つずつ実装を進めていくスタイル。

Vibe CodingAgentic Codingの違いや詳細な説明については、arXiv論文の「Vibe Coding vs. Agentic Coding: Fundamentals and Practical Implications of Agentic AI」を一度読んでみることをお勧めします

arxiv.org

多くのテックブログやSNSではClaude CodeやGemini CliなどがAgentic Codingの代表例として紹介されています。そのため、「GitHub Copilotでは物足りない」と相対的に感じてしまっている方も多いのではないでしょうか。

しかし、私は「GitHub Copilotでも工夫次第でAgentic Codingに近い開発体験が可能」だと考えています。

GitHub Copilotを"最強のAgent"にする4つの工夫

GitHub Copilotを単なる補完ツールから開発エージェントへと昇格させるためには、いくつかの重要な機能を使いこなす必要があります。

3つのモードを意識的に使い分ける

Copilotには大きく3つのモードがあります。これらを状況に応じて使い分けることが全ての基本です。

モード 機能 主な用途
💬 Ask AIチャット 既存コードのロジック解明、仕様に関する壁打ち、アイデア出し
📝 Edit 選択範囲内のコード編集 機能追加、修正、リファクタリング、テストコード生成
🤖 Agent 自律的な開発エージェント 新機能開発複数ファイルにまたがる大規模なリファクタリング

特にAgentモードは、Copilotが自律的に思考し、複数のファイルにまたがる変更を行う際にはメインで利用することになります。

instructionsを分割・活用する

プロジェクトのコーディング規約やアーキテクチャといった"お作法"をCopilotに教えるためのファイルが.github/copilot-instructions.mdです。

重要なのは、ドメインごとにファイルを分割して適用範囲を限定することです。これにより、コンテキストに応じたより正確な指示が可能になります。

記述例: (.github/instructions/backend.instructions.md)

---
# この指示はバックエンド関連のファイルにのみ適用する
applyTo: "src/backend/**/*.ts, src/trpc/**/*.ts" 
---
# バックエンドアーキテクチャ・実装ガイド

## 概要
当プロジェクトのバックエンドは三層アーキテクチャを採用しています。
Presentation層、Application層、Infrastructure層の責務を厳密に守ってください。

## 実装ルール
- 新しいエンドポイントを追加する際は、必ずXXXのルールに従うこと。
- ...
etc...

promptで定型作業を効率化する

テストコードのテンプレート生成や、Pull Requestに記載するE2Eテスト項目のリストアップなど、繰り返し行う指示はカスタムプロンプトとして登録しましょう。

/.github/prompts/* ディレクトリに .prompt.md 形式でファイルを作成し、チャットでスラッシュコマンドで入力することで登録したプロンプトを簡単に呼び出せます。

例えば、テストコードの生成において、ただ「テストを書いて」と依頼するだけでは品質にばらつきが出がちになってしまうので、以下のようなプロンプトファイルを作成しています。

ファイルパス例:/.github/prompts/unit-test.prompt.md

# Testing Rules

## 基本要件

- **テストフレームワーク**: Vitest + React Testing Library
- **言語**: TypeScript
- **テストケース命名**: 日本語
- **import文**: vitestのメソッド(test, expect等)は不要

## テストパターン

以下のテストケースを含めてください:

- **正常ケース**: 期待される動作の検証
- **異常ケース**: エラーハンドリングの検証
- **エッジケース**: 境界値・極端な入力の検証
- **UI動作**: 表示・非表示、ユーザーインタラクション
- **非同期処理**: ローディング、APIレスポンス

## ベストプラクティス

- Testing Libraryのメソッド優先(`getByRole`等)
- 外部依存はモック化
- `fireEvent`でのイベントテスト
- `beforeEach`/`afterEach`で共通処理をまとめる

## テストファイル配置
- src/components/Button/index.tsx
- src/tests/components/Button/index.test.tsx

後はチャット内で「このコンポーネントのテストコードを作成してください」のような通常のプロンプトの先頭に /unit-test とスラッシュコマンドを入力するだけで、チームで一貫した品質のテストコードを生成することが可能になります。

ナレッジの自己蓄積と育成

AIは一度の対話で教えたことを永続的に覚えてはくれません。そのため、私のチームでは対話を通じて得られた学びをGitHub Copilot自身に記録させるために、copilot-instructions.mdに以下のようなルールを記述しています。

## ナレッジの記録
- セッションを通じて学んだことは、「.agent-doc/knowledge」配下のマークダウンファイルに記録してください。
- 記録は重要なステップであるため、私たちの確認を待たずにあなたの判断で記録してください。
- 「何をしたか」よりも「なぜそう判断したか(思考のプロセス)」を最も重要視して書いてください。
- 私たちからの指示と、あなた自身の行動の差分から、今後の開発で気をつけるべき点を記録してください。

このプロセスを各セッションごとに繰り返すことでプロジェクト固有の知識を蓄積することが実用的なエージェントへ成長させるための鍵となります。

ただ都度ナレッジ化させるわけですので、内容が重複したり情報が古くなったりがよくあります。定期的に整備しましょう。 場合によってはpromptファイルへ昇格させるのもかなり有効な手段だと思います。

旧システム移行プロジェクトでの実践例

私が所属しているチームでは、Rails + Vue.js on AWS(ECS)で構築された社内システムをNext.js on Salesforceへ移行しています。

この移行における最大の壁は主に以下の2点です。

  1. データ構造の根本的な変化
    • RDB (MySQL) からSalesforceオブジェクトへの変更に伴い、データ構造や型、リレーションの考え方が大きく異なります。また、SQLとSOQLの差分も吸収しなくてはなりません。
  2. 複雑な既存ロジックの把握
    • 移行元のRailsアプリケーションの各APIの実装にはテキストベースの設計書はほとんど存在しておらず、またbefore_actionafter_saveといったコールバックが複雑に実装されていることで、APIリクエストの裏側で何が起きているのかコードを追うだけでは実装の詳細を把握するのが非常に困難でした。

このような複雑な移行タスクは、まさにClaude Codeのような高度なAIエージェントが得意とする領域かもしれませんが、彼らはまだ私たちのチームには参画していません。とはいえGitHub Copilotという古株の強力な味方がいるので工夫して現代の働き方をトレースしてあげましょう。

人間が司令塔となる擬似Agentic Coding

Agentic Codingの核心は、目的(ゴール)を達成するために、AIが自律的にタスクを分解し順序立てて実行していく点にあります。

この「タスクを分解する」というAIエージェントにおいて最も重要なプロセスを人間が肩代わりします。そして、分解された個別のタスクの実行をCopilotに任せることで、擬似的なAgentic Codingを実現します。

今回の目的は、「Railsで実装された〇〇 APIをNext.jsへ完全に移行する」ことです。 以下でそのために実行した具体的なステップを紹介します。

Step 1: Askモードで既存APIを設計書化する

Askモードを使い、対象のRails APIに関連するコードを全てコンテキストとして与え、「登録APIの一連の処理を仕様書としてまとめてください。データフローや条件などについても詳しく説明してください。Markdownファイルに書き出してください」の様に指示します。これにより、複雑なコールバックを含めたロジックをドキュメント化させます。もちろん、生成された内容が正しいかは人間が厳密に精査しましょう。(当該APIで再度同じ作業をしなくて良いように生成したAPI設計書もGitで管理できるとベストですね)

Step 2: Agentモードで設計と実装のタスクを実行させる

仕様が明確になったところでやっとこさAgentモードの出番です。Copilotの出力品質は、当然私たちが与えるコンテキストの質に大きく左右されます。

この品質をもう一歩進めるのにADR (Architecture Decision Records)も有効です。所属チームでは重要な技術的決定事項を記録したADRGitHub Discussionsで管理しており、GitHub MCPリポジトリ内のこれらの議論を参照させています。(このADR活用法については、以前執筆したこちらのテックブログで詳しく紹介していますので、ぜひご覧ください。)

tech.forstartups.com

単純な型情報の比較だけでは不十分です。ドメインとの関連性、Salesforceへの移管となった技術的背景、MySQLSalesforceオブジェクトのN:N関連の表現方法など、豊富なコンテキストを事前に与えることが重要になります。

そのために「Salesforceのデータモデルに関するADRを参照し、その決定背景を考慮した上でスキーマの差分を分析してください」といった形で指示することでCopilotはコードや型定義だけでなく、「なぜそうなったのか」という設計思想まで理解した上で、精度の高い分析レポートを作成してくれます。この分析結果は、後の工程で何度も参照するため、ナレッジとして蓄積しておきましょう。

  • Next.js用のAPI設計書を作成させる

Step1で生成したRailsAPI仕様と、先ほど分析したスキーマ差分をインプットとして、「これらの情報に基づき、Next.js用のAPI設計書をマークダウンで作成してください」の様に指示します。生成された設計書に対しては、人間がレビューとフィードバックを繰り返し、完成度を高めていきます。

  • Agentモードで設計と実装のタスクを実行させる

後は、最終的にFIXした設計書をもとに「この設計書と関連するADRの規約に従って、APIの実装とテストコードを作成してください」と指示するだけです。ここでも必ず生成されたコードに対して人間がフィードバックを行い品質は担保しましょう。

成果と考察

この一連のプロセスを経て実装した「+300, -160」行ほどの変更量のAPIを特に不具合なくリリースすることができました。

「いや、そのプロセスを一々やるのが手間だからClaude Code使ってるんやが...」という声が聞こえてきそうです。しかしよくよく考えるとたとえClaude Codeを使ったとしても、生成されたタスクリストや設計書、そして最終的なコードをレビューなしで承認する(auto approve)ことはほとんど無いのではないでしょうか。

結局のところ、各タスクの節目で人間がレビューし、次のステップに進む許可を出すという本質的なプロセスは、どのツールを使っても変わらないのです。

GitHub Copilotを使って紹介したプロセスを踏むことで、その「節目」を人間が意図的に作り出し、ADRのようなアーキテクチャ情報を与えてAIを正しく導くことができます。 それにより高度(トレンド)なAIエージェントを使って高品質な成果を得ることができると考えています。

ちなみに先月はここ半年で一番Copilotを駆使したつもりでしたが、プレミアムリクエスト70~80%くらいの消費で収まっていました。 みなさん超えた人いますか?いたらどんな使い方したら超えたのか何卒教えていただけますと幸いです🙏