はじめに
この記事は「ハックツハッカソン ギガノトカップ 2025」で作成した「TYPE 2 DIVE」に関する記事です。
ハッカソン中にこねくりまわした知見を出力しているだけなので、改善点などあるかと思います。よければコメントください🙇♂️
GitHub Copilot、使ってますか？
2025年6月現在、学割適用で無料で使い倒せる便利な AI Agent ツールであり、お世話になっている人も多いかと思います（残念ながら制限はつきましたが...）
世間では Cloude Code やら Cursor やら Devin やらが流行っていますね。ちょうど先日も Google I/O で Jules が発表されたり、Xcode にも Agent モードがきたりと、AI 方面の進化が続いています。
しかし、 すべて有料 です。
インターン先に恵まれるか、日々の食事をもやし定食にしない限りは使うことができません。
ということで、GitHub Copilot for Agent を極限まで使用するためのスキームを用意してみます。
注意：
今回の方法は、使用するモデルによって効き目が異なります。
Claude 4 Sonnet に対してチューニングを行ったので、性能の低いモデルでは十分に動作してくれない場合があります（例：GPT 4.1 では指示の無視などが見られた）。
tl:DR
以下のようなプロンプトを使用しています。
# 基本
- 日本語で応答すること
- 必要に応じて、ユーザに質問を行い、要求を明確にすること
- 作業後、作業内容とユーザが次に取れる行動を説明すること
- 作業項目が多い場合は、段階に区切り、git commit を行いながら進めること
- semantic commit を使用する
- コマンドの出力が確認できない場合、 get last command / check background terminal を使用して確認すること
## develop
各作業を以下のように定義する。
- 「調査」と指示された場合、都度 docs/reports に記載すること
- 「計画」と指示した場合、docs/tasks.md に計画を記載する
- 前回の内容が残っている場合は、読まずに消して構わない
- コードベース / docs を読み込み、要件に関連性のあるファイルパスをすべて記載すること
- 不明な点については、fetch mcp を使用して検索すること
- 必要最小限の要件のみを記載すること
- このフェーズで、コードを書いては絶対にいけない
- ユーザが「実装」と指示した場合、docs/tasks.md に記載された内容に基づいて実装を行う
- 記載されている以上の実装を絶対に行わない
- ここでデバッグしない
- 「デバッグ」と指示された場合、直前のタスクのデバッグ「手順」のみを示す
## documents
- docs/reports/*.md : 調査レポート
- docs/schema.md : データ構造
- docs/requirements.md : 要件定義
copilot-instructions.md とは？
さて、GitHub Copilot を使うにあたり、copilot-instructions.md について知っておく必要があります。
作業するリポジトリの .github フォルダに copilot-instructions.md というファイルを設置すると、支持するたびにこのファイルの内容をプロンプトとして読み込んでくれます。
たとえば、これが空の状態だと英語で返答されたりするんですが...
「日本語で応答して」と記述することで、常に日本語の応答を出力させることができます。
いいですね！
copilot-instructions.md つきの copilot の応答を見てみると、"Used 1 referense" と書いてあります。これを展開すると...
出力の前に copilot-instructions.md を参照していることがわかります。
このように、GitHub Copilot に対する定型的な指示書を作成できるのが copilot-instructions.md です。
これを使用して、開発におけるプロセスを 極限まで高める ことを今回の目標としたいと思います。
注意：
AI モデルには、それぞれ指示されたことすべてを正確に実行できるプロンプトの長さがあります。人間と同様、一度にたくさんの事柄を処理するのは現実的ではありません。
copilot-instructions.md にあまりにも多い指示を含めてしまうと、指示されたことを正確に実行できない 可能性があります。注意してください。
感覚値ですが、
・Claude 4 Sonnet: 600 文字
・GPT-4.1: 300 文字
程度がよいと思ってます。
開発のステップを形式化する
さて、本題に入ります。
GitHub Copilot で開発をするにあたり、開発サイクルの流れを考えることが重要です。各段階で何を行うかを整理し、それをテンプレートとして copilot-instructions.md に記載していくことで、応答をよりシンプルにすることができるはずです。
開発の各ステップ
私は以下のように定義しました。
前提としてハッカソンのような高速の開発であること、アイデアや要件定義がそれなりにできていることを添えておきます。
シンプルですね！
僕は実装の前にあらかた下調べを行い、その場で最適な実装方法を計画したのち、それを実装するようにしています。この時点で実装の成功条件（どうあれば「実装が成功した」といえるか）もあらかた決めるので、これがのちのデバッグ要件になります。
各ステップを定義する
さて、これらに対してテンプレートを定義していきます。
前提として、各ステップの合間に人間がレビューする ことを想定しています。これにより、
- AI によって加速した開発に、人間が置いて行かれないようにする
- AI が指針を失い、想定と違う実装を行うことを防止する
の2つのメリットがあります。
「テンプレート」というのは、「A と指示したときに B を行う」のようなイメージです。「ping」といったら「pong」と返す、みたいな。
私が作成したプロンプトが以下になります。
ハッカソン内のトライアンドエラーで書いたものなので、結構ムダがあるかも。好きに改造してください。
- 「調査」と指示された場合、都度 docs/reports に記載すること
- 不明な点については、fetch mcp を使用して検索すること
- ファイル名は `YYYYMMDDmmss-title.md` とする
- 「計画」と指示した場合、tasks.md に計画を記載する
- 前回の内容が残っている場合は、読まずに消して構わない
- コードベース / docs を読み込み、要件に関連性のあるファイルパスをすべて記載すること
- 必要最小限の要件のみを記載すること
- このフェーズで、コードを書いては絶対にいけない
- ユーザが「実装」と指示した場合、plan.md に記載された内容に基づいて実装を行う
- 記載されている以上の実装を絶対に行わない
- ここでデバッグしない
- 「デバッグ」と指示された場合、直前のタスクのデバッグ「手順」のみを示す
順に解説します。
調査
Web 上を検索し、判断に必要な情報を集めます。
このステップを Copilot に行ってもらうために、 fetch MCP を使用します。導入は以下の記事を参考にしてください（意外とカンタンでした）。
ここでは、以下のように定義しています。
- 「調査」と指示された場合、都度 docs/reports に記載すること
- 不明な点については、fetch mcp を使用して検索すること
- ファイル名は `YYYYMMDDmmss-title.md` とする
特筆すべきは、調査結果を docs/reports 内にファイルとしてまとめてもらってる点です。
通常はレスポンスとして会話履歴に吐き出されますが、けっこう見づらいです。加えて、あとから見直そうとすると履歴を辿る必要があったりと大変でした。
ファイルに出力しておくことで、Copilot が忘れた後でもファイルを渡すことで再教育できます。
計画
以下のように定義しました。
- 「計画」と指示した場合、tasks.md に計画を記載する
- 前回の内容が残っている場合は、読まずに消して構わない
- コードベース / docs を読み込み、要件に関連性のあるファイルパスをすべて記載すること
- 必要最小限の要件のみを記載すること
- このフェーズで、コードを書いては絶対にいけない
前回と違い、計画は tasks.md という一枚のファイルで管理しています。これはハッカソン中に実装計画を見直すことはないだろうと思ったからですが、Design Docs のように履歴のような運用をする場合は別途 docs/plans などに吐き出してよいかもしれません。
上の画像は GPT 4.1 で実行しているのでめっちゃ簡素ですが、Claude Sonnet 4 で実行すると結構ガッチリ書いてくれます。うれしいですが、余分に要件を書き足すことがあるので、人間側でレビューが必要です。
以下は実際にハッカソンで立てた計画書の引用。
実装
以下のように定義しました。
- ユーザが「実装」と指示した場合、plan.md に記載された内容に基づいて実装を行う
- 記載されている以上の実装を絶対に行わない
- ここでデバッグしない
tasks.md に基づいた範囲 のみ の実装を確実に行わせたいので、それ以外の実装を行わせないようにしています。また、デバッグもあとでやるようにしています。
デバッグ
以下のように定義しました。
- 「デバッグ」と指示された場合、直前のタスクのデバッグ「手順」のみを示す
よくあるのが、ユーザーの環境を勘案してないコマンドの提案です（例：npx で呼びたいツールを直接呼んでいる、aliases を使いたい）。それらを別途 copilot-instructions.md に記載するのは手間なので、ユーザーが適宜読み替える方式でデバッグするようにしています。
その他：出力を安定させる
上記とは別に、とりあえず入れておくと出力が安定したプロンプトを付記しておきます。僕の好みで入れてる部分もあるので、適宜書き換えてください。
- 日本語で応答すること
- 必要に応じて、ユーザに質問を行い、要求を明確にすること
- 作業後、作業内容とユーザが次に取れる行動を説明すること
- 作業項目が多い場合は、段階に区切り、git commit を行いながら進めること
- semantic commit を使用する
- コマンドの出力が確認できない場合、 get last command / check background terminal を使用して確認すること
- 絵文字を多めに使用する
日本語で応答すること
日本語で応答してくれます。
会話が続くと日本語で応答していたことを忘れて英語で話し始めることがありますが、その予防です。
必要に応じて、ユーザに質問を行い、要求を明確にすること
あいまいな部分を聞き返してくれるようになります。
作業後、作業内容とユーザが次に取れる行動を説明すること
いわゆる "NEXT ACTION" の提示です。
作業項目が多い場合は、段階に区切り、git commit を行いながら進めること
semantic commit を使用する
ロールバックできるよう、作業の合間にコミットを挟むようにしています。
semantic commit とは、feat: fix: chore: のような作業のカテゴリを簡単に示す接頭辞をコミット文につける手法です。参照性が高くなってオススメ。
コマンドの出力が確認できない場合、 get last command / check background terminal を使用して確認すること
たまに、Copilot がコマンド出力を見失うことがありました。ログが出ているにもかかわらず、「ログが出ていませんね...」的な話をし始めたらソレです。
おそらくログが出力される前にチェックしようとしていると考えたので、確認できなかった場合はもう一度チェックしたり、別のターミナルを確認したりするようにさせました。
絵文字を多めに使用する
そのままです。出力がちょっとだけカワイイ。
おわりに
おすすめのプロンプトがあったら Twitter のメンション付きでおしえてください！ぼくが喜びます。
おまけ
後で知ったんですが、Cloude Code などでも同様の方法が取られているらしいです。そうなんだ。