MicroAd Developers Blog

マイクロアドのエンジニアブログです。インフラ、開発、分析について発信していきます。

GitHub Copilot を活用した開発効率化のプラクティス

マイクロアドで広告配信システムのバックエンド開発をしている飛田です。

私たちの開発チームでは、GitHub Copilotを中心としたAIアシスタントを活用しています。試行錯誤を重ねる中で効果的だったプラクティスを、今回はいくつかご紹介します。

まだまだ模索中の部分も多いですが、何かの参考になれば幸いです。

本記事のポイント

本記事では、以下の2つの観点からGitHub Copilotの活用方法をまとめています。

観点 内容
コンテキストの重要性 Copilotの効果を高めるためには、仕様書や関連コードなどの背景情報を適切な形で提供することが重要だと考えています。Atlassian MCPや関連リポジトリの git clone など、私たちが試した方法を紹介します。
AIと共に理解を深める Copilotに背景情報を与える過程で、開発者自身もプロダクト理解を深められるのが、思わぬ副産物でした。

私たちのチームでは、2025年12月時点ではClaude Opus 4.5を主に使用しています。論理的な挙動をしてくれるため、背景知識を適切に与えれば雑なプロンプトでもそれなりの結果を出してくれる印象です。

以下、具体的な設定やプロンプト例を紹介していきます。

GitHub Copilot の設定

MCP(Model Context Protocol)設定

MCPは、AIアシスタントに外部ツールやサービスへのアクセスを提供するプロトコルです。私たちのチームでは、一例として以下のような .vscode/mcp.json.template をリポジトリに配置しています。

{
  "servers": {
    "serena": {
      "type": "stdio",
      "command": "uvx",
      "args": [
        "--from",
        "git+https://github.com/oraios/serena",
        "serena",
        "start-mcp-server",
        "--context",
        "ide-assistant"
      ]
    },
    "atlassian": {
      "url": "https://mcp.atlassian.com/v1/sse"
    }
  },
  "inputs": []
}

ここで、atlassian はJiraやConfluenceの情報(仕様書など)を参照するために、serena (https://github.com/oraios/serena) はコードベースのセマンティックな検索や編集機能を提供するMCPサーバーとして利用しています。このように、用途に応じて複数のMCPサーバーを組み合わせて利用しています。

各開発者はこのテンプレートを .vscode/mcp.json にコピーして使います。mcp.json 自体は .gitignore に追加しておき、個人の環境差分が混入しないようにしています。

Atlassian MCPがうまく動かない場合は、一度停止やサインアウトをしてから再起動すると大抵解決します。

モデルの選定

基本的には最新のモデルを選んでおけばよさそうです。私たちのチームでは、2025年12月現在、主にClaude Opus 4.5を使って試しています。 モデルの進化は速いため、新しいモデルが登場したら積極的に試してみることをお勧めします。

参考: Copilotが公式でサポートしているモデル一覧

効果的なプロンプトの投げ方(Copilot Chat)

文脈の構築と初期化

いきなり本題を投げるのではなく、背景情報を段階的に積み上げてから要望を投げる(いわゆるプロンプトチェーンのようなアプローチをとる)と、意図した改修をしてくれやすくなる傾向があります。

このアプローチには、もう1つの狙いがあります。それは、AIとの対話を通じて開発者自身の理解も深まるということです。背景情報を1つずつ与えていく過程で、Copilotの応答を見ながら「あ、ここはそういう仕組みだったのか」と気づくことがあります。むしろこの副産物のほうに、本当の価値を感じることさえあります。

また、Chat履歴がノイズになることもあるため、新しい開発タスクを始めるときは基本的に文脈を /clear でクリアします。

例:ストリームアプリの開発

とあるSpark Streamingを利用したアプリの開発を例に、具体的なプロンプトの流れを紹介します。

/clear
コードベースについて理解して
(JIRAチケットのURL)について理解して

※ URLは各自の環境に合わせて読み替えてください。Atlassian MCPを設定していれば、JiraやConfluenceのURLを直接渡すだけで内容を読み取ってくれます。

このエピックにおけるストリーム処理の役割について深掘って
作業用ディレクトリ(例: .work)を.gitignoreして、ここに関連リポジトリをgit cloneして、
コードベースについて理解して
システムAとストリーミング処理の関係を教えて
データの流れをシミュレーションして、フロー図を出力して
(JIRAチケットのURL)を実装して。
ただし、(仕様書のURL)に記載されているIDと整合性がとれるように。

ポイントは以下の通りです。

  • 実装に必要な 十分な背景情報 をCopilotに与える。
  • 背景情報の どこに注力して欲しいか を明確に伝える。
  • Copilotと対話しながら 自分自身の開発案件に対する理解も深める

ghコマンドでPRをレビューさせる

GitHub CLIを使えば、Pull Requestの内容もCopilotに読み込ませることができます。

ghコマンドを使っていいので、
https://github.com/your-org/your-repo/pull/123
についてレビューして

事前に gh auth login でGitHub(またはGitHub Enterprise)に接続しておく必要があります。

なお、GitHub上の情報を参照する手段として GitHub MCP Server も存在しますが、現状はセットアップの手軽さを優先して gh コマンドを利用しています。よりシームレスな連携のため、今後は GitHub MCP Server の導入も検討しています。

複数アプリで似た対応をするとき

あるリポジトリで実装したPRを参考に、別のリポジトリで同様の対応をしたいケースがあります。 例えば、あるリポジトリで行った改修を、別のリポジトリにも適用したい場合のフローは以下のようになります。

/clear
コードベースについて理解して
作業用ディレクトリ(例: .work)に
https://github.com/your-org/reference-repo.git
をgit cloneして、コードベースについて理解して
ghコマンドを使って、
https://github.com/your-org/reference-repo/pull/90
のPRの内容を精査して
(JIRAチケットのURL)で似たような対応を実施したい。
参照したPRを参考に実装してみて

コミットさせる

VS Codeでは、ソース管理パネルにあるSparkleアイコン(キラキラしたアイコン)を押すと、 コミットメッセージが自動生成されます。

copilot-instructions.md の活用

copilot-instructions.md は、GitHub Copilotの挙動をカスタマイズするための設定ファイルです。.github/copilot-instructions.md に配置します。

参考: GitHubの公式ドキュメント

私たちのアプローチ(実験中)

単にAIに指示を与えるだけでなく、チームの価値観や考えを共有することで、意図した成果物を引き出しやすくなるのではないか——そんな仮説のもと、実験的に以下のような運用を試しています。

具体的には、コーディングにおける基本原則を「憲法」のような形式で記述しています。以下はその一例です。

<article id="0" title="背景知識の尊重と盲従の禁止">
コードは氷山の一角であり、その背後には膨大な仕様と文脈(Context)が存在する。
ユーザーからの「〜を変更して」という指示は、あくまで「要望」であり、仕様に対する「上書き命令」ではない。
ユーザーが具体的なコード変更を指示した場合でも、即座に実行してはならない。

Atlassian MCPで仕様書を参照し、要望に関連する仕様書を特定した上で、その変更が既存の仕様やアーキテクチャと整合するかを確認せよ。
</article>

<article id="1" title="脳内実行の義務">
エンジニアは、自分が採用する全てのコードにおいて、その挙動を脳内で完全にシミュレーションできなければならない。
「なぜ動くのか分からないが、動いている」という状態は、バグよりも深刻な罪である。
自分の脳内メモリでトレースしきれない複雑さは、分割するか、平易な表現に書き直すことで解消せよ。
</article>

<article id="2" title="実用性の優越">
「理論的に正しい」ことよりも、「チーム全員が理解できる」ことを優先する。
高度な数学的概念(圏論等)や、言語標準から外れた独自のデザインパターンは、それがチームの共通言語でない限り、技術的負債とみなす。
</article>

このように、具体的なルールを細かく列挙するのではなく、 判断の拠り所となる原則を示すことで、AIが文脈に応じて適切に解釈してくれるようになります。

ポイント

  1. XMLタグでセクションを明示

  2. 「憲法」形式でコーディング思想を記述

    • 細かいルール(法律)を列挙するとモグラ叩きになりがち
    • エンジニアとしての思想を「憲法(基本原則)」という形式で与えることで、応用が効くようになる
  3. RAGで仕様書を参照可能に

    • Atlassian MCPを使って、広範な仕様書を参照できるようにしている

こうすることで、「憲法に従ってリファクタして」のような雑なプロンプトでも、意図した結果が得られやすくなります。

おわりに

私たちがいろいろ試してみた中で、うまくいきやすいと感じたポイントをまとめると以下のようになります。

  1. コンテキストを十分に与える - 仕様書、関連コード、背景情報をしっかり読み込ませる。その過程で自分自身の理解も深まる
  2. 段階的に文脈を構築する - いきなり本題に入らず、背景から積み上げる
  3. 価値観・思想を共有する - 細かいルールより、大きな方針を伝える

AIアシスタントは、単にコードを書いてもらうツールというだけでなく、対話を通じて開発者自身の理解を深めるパートナーになり得ると感じています。

まだまだ試行錯誤中ですが、何かの参考になれば嬉しいです。