バックエンドでどこまでVibe Codingできる？最小限の設定で精度を上げる方法 with GitHub Copilot
この記事では、どのベンダーのインフラを使っていても共通して使えるバックエンドのVibe Codingをより快適にする方法を3回のイベントに渡り検証した結果をまとめます。
Azureを例にしていますが、それ以外でも参考になると思います。時間がない方は一番最後のまとめからどうぞ。
初戦
AI Codingを極める会 - VS Code Meetup × GitHub dockyard - connpassというイベントで、そのイベントのアンケートフォームをライブVibe Codingで作り上げる、という企画を行いました。
このイベントではバックエンドチーム（私はこちら）とフロントエンドチームに分かれ1時間で以下のWebアプリを完成させることに挑みました。
- 画面は「アンケートフォーム」「結果集計画面」の二つ
- インフラはAzure
- フロントはAzure Static Web Appsでホスト
- APIはHTTPトリガーのAzure Functions（.NET）
- データベースはCosmos DB
デプロイ用ワークフローとリソースは事前作成済みの状態で開始しました。
アーカイブはこちらです↓
結果
フロントエンドチームは1時間でアンケートフォームを完成させ、デプロイまで成功しました。
一方バックエンドチームは、Cosmos DBへのデータ登録でエラーになり、デプロイまで至りませんでした。
エラーの原因は、Cosmos DB の Partition Key を GitHub Copilot が考慮していなかったことです。実際の Cosmos DB の状態を見ずに Partition Key を GitHub Copilot が推測してコードを書いていた ために、存在しない Partition Key を設定してデータを更新しようとしているという内容のエラーが出ていました。
バックエンドのVibe Codingの難しさ
個人的に、バックエンドのVibe Codingはフロントエンドより難しいと感じています。
フロントエンドはコード内でほとんど解決するため、必要なコンテキストを与えやすいです（AIには目がないのでUIの細かい実装は苦手、など諸々課題はあると思いますが）。
一方バックエンドはインフラ側のリソースの考慮が必要になるため、コードだけではコンテキストが足りません。
この状態だと、GitHub Copilotが勝手に推測したインフラリソース構成でコードを考えてしまいます。
初戦の敗因はまさにその部分、「GitHub Copilotがデータベースの構成を知らない」ことでした。
であれば、インフラ側のリソース情報をコンテキストとして与えられればうまくいくのでは、という仮説が立ちます。
インフラ側の情報の与え方
インフラの構成をコンテキストとして与える方法として、以下の 2 つを思いつきました。
- IaC（Infrastructure as Code）を利用する
- インフラの状態をコードで管理する方法です。これによりインフラの情報までコード内に含めることができます
- インフラの構成を取得可能な MCP、もしくはコマンドを Agent に利用させる
「1. IaC（Infrastructure as Code）を利用する」 の場合、IaC の定義が同じリポジトリ内にあることが望ましいです。しかし、開発者とインフラ管理者の権限を分ける都合上、別で管理されているケースも多いと思われます。
これを前提としてしまうと汎用性が低くなるため、今回はインフラがIaC化されていない場合でも実践可能な「2. インフラの構成を取得可能なMCP、もしくはコマンドを Agent に利用させる」 の戦略で行くことにしました。
第2ラウンド
というイベントを開催し、以下の改善策を適用した状態で同じ課題に挑戦しました。
前回の課題
- インフラ側の具体的な構成・設定をGitHub Copilotに渡せていない
改善策
-
Azure MCP Serverの導入
- Azure上（インフラ）のリソース構成を取ってくる役割
- 実は初戦から入れていたが、ちゃんと動いてくれていなかった
- 入手はこちらから：Azure/azure-mcp: The Azure MCP Server, bringing the power of Azure to your agents.
-
Microsoft Docs MCP Serverの導入
- Microsoft公式ドキュメントから情報を検索してくる役割
- 初戦でもちゃんと動いていた
- 入手はこちらから：MicrosoftDocs/mcp
-
GitHub Copilot for Azure 拡張の導入
- 入手はこちらから：GitHub Copilot for Azure 拡張
- 機能詳細はこちらから：GitHub Copilot for Azure とは - GitHub Copilot for Azure | Microsoft Learn
- Custom instructions の改良
- Custom instructionsとは、Copilotへの指示の時に特定のプロンプトを必ず与えるよう設定ができる機能です。いつも書いている指示がある場合はこちらで設定すると楽になります
- 詳細はこちらから：Customize AI responses in VS Code
- 今回はVS Codeの設定
github.copilot.chat.codeGeneration.instructionsに以下のような内容を直書きしていました ※設定ファイル（settings.json）への直書きは現在非推奨なので実際は別ファイルを作成して参照するよう設定しましょう"github.copilot.chat.codeGeneration.instructions": [ { "text": "必ず Azure MCP Server、Azure CLI を使って Azure 側の構成を把握してから実装を考えてください" }, （省略） ]
結果
Azure の情報をシームレスにとってこられれば大丈夫だろうと思っていましたが、またしても 1 時間以内に達成できませんでした。
エラーが解決できずタイムオーバーになりましたが、主なエラーの原因はAzure Cosmos DB SDKの不具合というか、現状の微妙な仕様の問題でした（詳細は書きませんが参照しているJSON系のパッケージ関連の問題）。バージョンが上がってこの問題が解消されればうまくいっていたかな、と思える範囲内ではあります。
ただ、これでうまくいっても再現性は低いな、というごたつき感は否めないですし、1時間で目標達成に至っていないので再度原因分析を行いました。
その時に分析した原因としては以下が挙げられます。
- Azure の認証問題: Agent Mode でどこから Azure の認証情報を取っているかわからず、希望のアカウントで認証できなかった
- Custom instructions の無視: 「Azure 側の構成を把握してから実装」と Custom instructions で設定したのに無視して Agent Mode が実装を始めてしまっていた
- 手順の揺らぎ: 「まずは手順を示して、許可が出たら実装して」のように指示しても、勝手に実装されてしまっていた
- Copilotの不具合: その日はGeminiもClaude Sonnetもエラーになるという謎の外れ日で、GPT-4.1しか使えない状態だった
- Toolの整理不足: Agent Mode で設定されている Tool が 128 を超えており、何かの拍子に選択解除した Tool が再選択される、などの問題も発生していたため、リクエストを投げるたびに Tool 整理のロスタイムが発生していた
結果として、「Azure 側の情報を取得して来られればスムーズにいくのでは？」という仮説は検証できずに終わってしまっていました。
第3ラウンド
というイベントを開催し、以下の改善策を適用した状態で同じ課題に挑戦しました。
改善策
-
Azure の認証問題
Agent Modeから見られているAzureの認証情報について調べました。
GitHub Copilot for Azure 拡張については
@azure get auth state
と Chat で聞くことでどのアカウントでログインしていてどのサブスクリプションを参照しているか確認できました（ここで任意のサブスクリプションを見ていることが確認できたのに、イベント当日は正常に動かなかったのですが…）。
-
Agent Mode の Tool 整理 & 揺らぎを抑える
カスタムチャットモードを設定することで、使用する MCP Server の Tool を絞り、Custom instructions で指示していた内容をさらに詳細化しました。
追加で、以下の内容も指示に入れています。
- Markdown のチェックリスト形式でタスクを書き出すようにする
-
ローカル実行時は接続文字列で接続するように
- こう書かないとローカルでは設定が複雑な認証方法で書かれてしまうため（Azure特有かも？）
-
パッケージのインストールは必ずコマンドで実行する
- パッケージファイルに誤ったバージョン名などで直書きしようとしてエラーになるケースが多いため
カスタムチャットモードについて詳細はChat modes in VS Codeをご覧ください。
今回は@taiga_kk322さんが公開しているこちらのチャットモードをベースにさせていただきました。
Tool に関してはイベント後適当に変えてしまって不要な Tool が選択されているところもありますが、概ね下記のようなチャットモードをイベントで作成して使用しました。
イベント中に作成したので粗はありますが、ご参考までに。
@taiga_kk322さんのものをAzure用に変えているのと、このチャットモード内でコードまで書いてもらえるように修正しています。
元のものの方が役割を限定することで揺らぎを抑えられるのですが、最小限のカスタムで今回のゴールを達成する方法を検証したかったため、設計と実装でチャットモードを分けませんでした。
ただ、実際の開発では役割ごとにチャットモードを作成して、「コードを変更しない、設計のためのチャットモード」「コードを変更する、実装のためのチャットモード」のように使い分けた方が安定はしそうです。
結果
40分ほどで「アンケートフォームのバックエンド作成」が完了しました！
といってもほとんどの時間をAzureの認証情報問題に費やしていました。Azure CLIでもうまくいかず（Copilotのターミナルで実行されるazコマンドのログイン情報がどこから取得されているか謎。手動でaz loginしても次のAgentによるコマンド実行時に新しいターミナルで実行されてしまってダメだった）、結局Cosmos DBの設定をスクショしてCopilot Chatに投げました。
ただ、第 2 ラウンドまでと大きく異なるのはカスタムチャットモードの指示を守ってくれていたことです。
そのため、第2ラウンドでは聞いてくれなかったCosmos DBの構成についても、指示し忘れていることに気付けるような動きをしてくれていました。
勝手にインフラ側の構成（今回は主に Cosmos DB の Partition Key）を捏造してコードを書き始める、という挙動がなくなったのは大きな一歩です。
知らぬ間に捏造されたインフラ側の情報をもとにコードを書かれて動かない状態になるのを避けることができます。
Azure の認証情報問題を解決できていれば Partition Key を含めた Azure 側の構成を自動で取得してそれをもとに設計し、許可を得てから実装へと移ってくれるはずです。
まとめ
バックエンドのVibe Codingを極める会を通して、最小限ここを意識して設定するとバックエンドでのバイブコーディングがしやすくなるよ、という点をまとめました。あくまで最小限です！ここをベースにさらなる調整を重ねていくとよさそうです。
-
インフラ側の情報を自動で取ってくるか、人間に聞くように設定する
- GitHub Copilotでいうカスタムチャットモードなどでそのように指示を与える
-
コマンドもしくはMCP Serverを利用してシームレスにインフラ側の情報を取得可能にする
- Azure の場合は Azure MCP Server、GitHub Copilot for Azure 拡張、Azure CLI がその役割
- もしIaCを導入していれば話は別。同じリポジトリにTerraformなどのコードがある場合はそこを参照させれば十分
- 公式提供の Tool でインフラ側の情報を取得できるものがない場合・ネットワーク制限などで取得できない場合は、Agent 側から設計段階で人間にヒアリングするようカスタムチャットモードなどで指示を設定する
- この指示をいれることで、インフラ構成というコードに影響を与えうるコンテキストの伝え忘れを防止する
-
特定技術（今回でいう Azure）に特化させたコードを生成したい場合は Custom instructions ではなくカスタムチャットモードを利用する
- Agentが使用するToolとプロンプトを紐づけて管理でき、複数チャットモードの切り替えも容易なため
-
適切なモデルで Agent を実行する
- GPT-4.1 では MCP Server をうまく呼び出してくれず、Claude Sonnet 4 を使うとうまく呼び出してくれる、ということが多かった
- 今後もモデルの更新に合わせていい感じにカスタムチャットモードの指示を守って MCP Server を呼び出してくれるモデルを選択しよう
Azure系のツールの認証情報がそれぞれどこから取得されているのかは、後日別記事でまとめます。
それでは、良きVibe Coding Lifeを！
Discussion