はじめに

お疲れ様です。前回の更新からだいぶ経ってしまい、継続的にテックブログを上げられなかったことを反省しております。
ちょっと大きめのリリースが立て込んでおりました。
その間にもいろいろ作ったり試したりしていたので、それらを少しずつ記事にしていこうかなと思います。
ということで、今回はバイブコーディングとAwesome-Copilotを使ってみたところ、普段の開発よりも素早く開発できたので、記事に残しておこうと思います。

目次

はじめに
目次
バイブコーディングとは
バイブコーディングで重要なこと
Awesome-Copilotとは
実際にやってみた
完成した製品の感想
参考

バイブコーディングとは

まず、今更感もありますが、Vibe Codingについて簡単に書いておきます。

バイブコーディング（Vibe Coding）は、「雰囲気（Vibe）でコーディングする」ということで、自然言語で設計書をがちがちに作り込んでからコーディングするのではなく、
何を作りたいか・どう動かしたいかという意図をAIエージェントに伝えて作成してもらうのが特徴の開発手法ですね。

バイブコーディングで重要なこと

バイブコーディングにおいて特に重要なのがプロンプトです。

AIに「何を作りたいか」を伝えるのがプロンプトですが、曖昧な指示を出すと意図と全く違うコードが生成されてしまいます。
逆に、的確なプロンプトが書ければAIは驚くほど正確に動いてくれます。

プロンプトは賢い方々が毎日のように研究・改良されており、追い付くのが大変ですが、
プロンプトの手法をすべて挙げていくとキリがないので、ざっくりと大事そうな部分だけ挙げておきます。

目的を明確にする — 「〜を作りたい」ではなく「〜という機能を持つ〜を実装したい」のように具体的に伝える
制約・条件を添える — 使用言語、フレームワーク、既存コードとの整合性など前提情報を渡す
期待する出力を示す — 関数単位なのか、ファイル全体なのか、どこに組み込むのかを明示する

Awesome-Copilotとは

Awesome-Copilot は、GitHub がホストするコミュニティ主体のリポジトリで、GitHub Copilot をより効果的に活用するための エージェント・インストラクション・スキル・ワークフロー などをまとめたコレクションです。

コミュニティが実際に使って効果的だったものを集めているため、1から自分でプロンプトを考えなくてもすぐに質の高い設定を使い始めることができます。

主な構成要素はざっくり以下の通りです。

Agents — MCPサーバーと統合する専門エージェント。特定ドメインの作業を丸ごと任せられる
Instructions — ファイルパターンに応じて自動適用されるコーディング標準。リポジトリ全体にAIの振る舞いを統一できる
Skills — インストラクションと関連アセットをひとまとめにした自己完結型の機能パック
Plugins — 特定ワークフロー向けにエージェントとスキルをバンドルしたセット。copilot plugin install で即導入できる
Hooks — Copilotエージェントのセッション中に自動トリガーされるアクション
Agentic Workflows — マークダウンで記述するAI駆動のGitHub Actions自動化
Cookbook — Copilot APIを使ったコピペすぐ使えるレシピ集

要するに、「先人の知恵をそのまま借りて、バイブコーディングの精度を底上げする」ためのリソース集です。

実際にやってみた

導入については、いろんな記事や公式が提供しているのでそちらをご確認ください。

まずは何を作るのかのフェーズです。
何を作ればいいかわからなかったので、上司に相談しました。

私「バイブコーディングで何やればいいですか？」
上司「ルート最適化問題とかそういう統計学の問題を解くツール作れば？」

というノリでルート最適化問題を解くことにしました。

※ルート最適化問題とは、複数の地点を巡る際に「距離・時間・コストが最小になる順序・経路」を求める問題です。有名なものだと「巡回セールスマン問題（TSP）」がこれに当たります。地点数が増えると全パターンを総当たりで試すのが現実的でなくなるため、アルゴリズムや統計的手法で近似解を求めるのが一般的とのことです。

とはいっても、ちゃんとサービスっぽくしたいので、車で5人を迎えに行く最短ルートを計算するツールとします。

次に要件定義ですが、何を決めればAIエージェントに漏れなく誤解なく伝わるのかわからなかったので、Awesome-Copilotに聞いてみます。

Awesome-CopilotはMCPサーバーとして利用できるので、まず「要件定義に必要な項目を教えてもらう」ところからMCPを使います。

以下のコマンドを実施して、ルート最適化問題の車で5人を迎えに行く最短を計算するツールを作成するための要件定義をprompts/phase1.mdに作成したい。
/mcp_awesome-copil_search_instructions keywords:"requirements definition project planning"

と入力しました。

▼ search_instructions のレスポンス（実際は全カタログが返ってくる）:

Agents（一部抜粋）:
  - prd.agent.md             : Generate a comprehensive Product Requirements Document (PRD) in Markdown,
                               detailing user stories, acceptance criteria, technical considerations, and metrics.
  - plan.agent.md            : Strategic planning and architecture assistant focused on thoughtful analysis
                               before implementation.
  - planner.agent.md         : Generate an implementation plan for new features or refactoring existing code.
  - arch.agent.md            : Expert in modern architecture design patterns, NFR requirements...
  - atlassian-requirements-to-jira.agent.md : Transform requirements documents into structured Jira epics...
  ...（全20+ エージェントが返ってくる）

Instructions（一部抜粋）:
  - spec-driven-workflow-v1.instructions.md : Specification-Driven Workflow v1 provides a structured approach
                               to software development, ensuring requirements are clearly defined...
  - go.instructions.md       : ...
  ...（全11 インストラクションが返ってくる）

Skills（一部抜粋）:
  - breakdown-epic-pm        : Prompt for creating an Epic PRD for a new epic.
  - breakdown-feature-prd    : Prompt for creating PRDs for new features.
  - breakdown-plan           : Epic > Feature > Story hierarchy project plans.
  ...（全30+ スキルが返ってくる）

キーワードで絞り込まれるわけではなく、Awesome-Copilotにある全コンテンツの一覧が返ってきます。
一覧の説明文を読んだ上で、要件定義に使えそうな prd.agent.md（"Generate a comprehensive Product Requirements Document..."）をGitHub Copilotがおすすめしてきたので、ロードしてみます。

以下を実行し、要件定義の詳細を詰めたいと思います。
/mcp_awesome-copil_load_instruction filename:prd.agent.md mode:agents
prompts/phase1.mdを作成するにあたり、必要な項目を教えてください

▼ load_instruction (prd.agent.md) のレスポンス（抜粋）:

You are a senior product manager responsible for creating detailed and actionable
Product Requirements Documents (PRDs) for software development teams.

PRD Outline:
  1. Product overview  — プロジェクトの目的・スコープ
  2. Goals             — Business goals / User goals / Non-goals
  3. User personas     — ユーザー種別・ロール別アクセス権限
  4. Functional requirements — 機能要件（優先度付き）
  5. Technical considerations — 連携・データ保存・スケーラビリティ・課題
  6. Milestones & sequencing  — フェーズ分け・チーム構成・スケジュール感
  7. User stories      — 受け入れ基準付き（ID: GH-001 形式で管理）

ここで重要なのが、MCPで取得した内容はAIのコンテキストに自動的に注入されるという点です。
つまり「要件定義はこう進めるべき」というフレームワークをAIが事前に持った状態で、自分のやりたいことを伝えられるのがポイントです。

MCPから取得（要件定義のフレームワーク）
        ↓
  ユーザーが作りたいものを入力（自分のやりたいこと）
        ↓
  AIが「抜け漏れのない要件定義書」を生成

① MCPがAIに注入したコンテキスト（prd.agent.md より）:

prd.agent.md はシニアプロダクトマネージャーとしてPRD（プロダクト要件定義書）を作成するエージェントで、以下のフレームワークをAIに読み込ませるようです。
そして、以下の項目について質問されたので、入力しました。

セクション	内容
Product overview	プロジェクトの目的・スコープの概要
Goals	ビジネス目標 / ユーザー目標 / Non-goals（スコープ外）
User personas	誰が使うか・ロール別のアクセス権限
Functional requirements	機能要件を優先度付きで列挙
Technical considerations	連携ポイント・データ保存・スケーラビリティ・課題
Milestones & sequencing	フェーズ分けとスケジュール感
User stories	受け入れ基準付きのユーザーストーリー（ID管理）

② 自分が入力した内容:

項目	内容
目的	5人を迎えに行く最短ルートを計算する
必須機能	① 送迎対象者追加時に距離行列を自動生成・保存　② 最短ルート最適化の実行
技術スタック	Go 1.24.0 / Echo v4 / Google Maps Routes API
フロントエンド	Pure HTML + CSS + Vanilla JS（フレームワーク不使用）
スコープ外	リアルタイム渋滞考慮・地図可視化・詳細なCRUD操作

③ 上記の回答によって生成された prompts/phase1.md

上記を実施したのち、要件定義で不足している情報はないかの確認を行いました。

基本設計に移るにあたって、不明確な部分や誤っている部分があるかの観点でレビューしてください。

上記のレビュー→対応を何回か繰り返した結果、一部抜粋ですが、以下が出来上がりました。

データモデル定義 — User（複数住所対応）/ DistanceMatrix / Route / Constraint などのGoの構造体定義
APIエンドポイント設計 — POST /api/v1/users（友人追加 + 距離行列自動生成）/ POST /api/v1/routes/optimize（最適化実行）など
ディレクトリ構成 — cmd/ internal/handler internal/service internal/repository internal/optimizer の役割分担
アルゴリズム方針 — Greedy Nearest Neighbor → 2-opt Local Search の2段階最適化
スコープ外の明示 — 時間制約・詳細CRUD・リアルタイム渋滞考慮は将来拡張扱い

次にフェーズ2として、フェーズ1の要件定義をもとに基本設計・データ定義を行います。
ここでも同じ仕組みでMCPを使います。今度は go.instructions.md を直接ロードし、GoのコーディングルールをAIに注入した上で指示を出しました。

以下のコマンドを実施して、prompts/phase1.mdをもとに基本設計・データ定義をprompts/phase2.mdに作成したい。
/mcp_awesome-copil_load_instruction filename:go.instructions.md mode:instructions

と入力しました。

▼ load_instruction (go.instructions.md) のレスポンス（抜粋）:

# Go Coding Standards

Based on:
- Effective Go (https://go.dev/doc/effective_go)
- Go Code Review Comments (https://go.dev/wiki/CodeReviewComments)
- Google Go Style Guide (https://google.github.io/styleguide/go/)

## Naming Conventions
  - Package names: lowercase single words
  - Exported names: PascalCase
  - Interfaces: "-er" suffix (e.g., Reader, Writer, Optimizer)

## Error Handling
  - Wrap with fmt.Errorf("context: %w", err)
  - Error messages: lowercase, no punctuation

## Code Structure
  - Early returns to keep nesting shallow (happy path left-aligned)
  - cmd/         → entrypoints
  - internal/    → packages not exposed externally

## Interfaces
  - Keep small (1-3 methods)
  - Define on the consumer side, not the implementor side

## Testing
  - Table-Driven tests as standard pattern
  - Use t.Run() for subtests
  ...

フェーズ1と同様に、MCPで取得した内容はAIのコンテキストに自動的に注入されるため、
「Goはこう書くべき」という知識をAIが事前に持った状態で、自分の設計指示を伝えられます。

MCPから取得（実装ルール・骨格パターン）
        ↓
  ユーザーが「この構成で実装して」と指示
        ↓
  AIが「ベストプラクティス準拠のコード」を生成

① MCPがAIに注入したコンテキスト（フェーズ2で特に効いた箇所）:

カテゴリ	AIに注入されたルール
DI（依存性注入）	コンストラクタ `NewXxx()` に依存を全て渡す。サービス層はインターフェース型フィールドを持つ
HTTP ハンドラー	ハンドラーはステートレス。バインド → バリデーション → サービス呼び出しの順で実装
アルゴリズム実装	小さい関数に分割。`Optimizer` インターフェースで Greedy → 2-opt を差し替え可能に設計
品質チェック	`gofmt` / `go vet` / `go test ./...` / `go build` を全てパスすることが前提

② 自分が入力した内容:

項目	内容
実装対象	フェーズ1で定義した要件どおりの全ファイル構成
アルゴリズム	Greedy Nearest Neighbor → 2-opt Local Search の2段階最適化
テスト方針	Table-Drivenテストでオプティマイザーとサービス層を検証

③ 上記の回答によって生成された prompts/phase2.md

上記を実施したのち、フェーズ1と同様にレビューを依頼しました。

実装に移るにあたって、不明確な部分や誤っている部分があるかの観点でレビューしてください。

上記のレビュー→対応を何回か繰り返し、では、実装してくださいと入力。
以下は順守されていました。

全ハンドラーが「バインド → 早期リターンバリデーション → サービス呼び出し → JSONレスポンス」の一貫した構造で生成
NewOptimizerService(userRepo, staffRepo, ...) のようにDIパターンが全レイヤーで徹底
レイヤー間のエラーラップ・命名・構造が初回から統一されており、修正不要で動いた

完成した製品の感想

実際に出来上がった製品の感想ですが、主要機能は問題なく動きましたし、バグや不便さもゼロでした。そこまで動かし込んでいないというのもあるかもしれませんが。
私が指定したアルゴリズムも使ってくれているようで、条件を変えてもいい感じにルートを最適化してくれていました。

失敗したなと思う点としては、画面モックを先に作って、それに合わせた要件にすべきだったということです。
「これを入力したいのにできない」「迎えに行くだけなのに工程が多いな」など、気になる点が多々ありました。

もう一つは、途中で迎えに行く順番に優先順位をつけたいと思い、その部分を追加でフェーズ3として組んだのですが、これが失敗でした。
既存のAPIに組み込まれるのではなく新しい機能として追加されてしまい、画面には反映されず、結局どこからも呼ばれないコードになってしまいました。
そもそもコンテキストエンジニアリングを理解して管理できていれば何とかなったのかもな、と振り返って思っていますが、勉強不足でした。

次やるときはスケールアップしやすい構成を考え、マルチエージェントで追加機能にも問題なく対応できる形にしたいなと思います。

参考