【導入】 すべての始まりは、一枚の「AI利用ランキング」だった
こんにちは、FLINTERS新卒エンジニアの野崎です。
突然ですが、皆さんはAIコーディングツール、活用していますか？
僕は8月頃から使えるようになった「Claude Code」にドハマりし、まさに"ゴリゴリ使い倒す"日々を送っていました。アイデアを壁打ちすれば設計のヒントをくれ、エラーコードを投げれば一瞬で解決策を示してくれる。まるで魔法使いのようなその力に、僕は完全に心酔していました。
しかし、そんな僕にある転機が訪れます。毎月発表される社内のAI利用状況レポートで、なんと僕が Claude Code利用者ランキング2位 にランクインしていたのです。
「え、俺がこんなに使っていいのか…？」「（従量課金だし）これ、まずいのでは…？」
一抹の危機感を覚えたのと同時に、僕は日々の開発業務に潜む、ある種の「ムダ」にも気づき始めていました。そこで、ここはいい機会になると思い、Claude Codeを卒業することにしました。
Jiraチケットを確認して、ブランチ名を考えて、コマンドを打って…
実装が終わったら、MR（マージリクエスト以下MR）のテンプレートをコピーしてきて、チケットの内容を要約して…
一つ一つは小さな作業ですが、積み重なると結構な時間と認知コストがかかります。「AIをもっと賢く使って、この面倒な作業から解放されたい」― それが、今回の挑戦の出発点でした。
【発見】 転機は突然に。モブプロで知った"Copilotの奥深さ"
さて、「Copilotをとことん使い倒す月間」と決めたものの、当初の僕のCopilotに対するイメージは、正直なところあまり高くありませんでした。
もちろん、強力なコード補完は手放せませんでしたが、チャット機能については「Claudeと同じように会話しながら実装できるもの」という認識で、むしろ「生成されるコードの質はClaudeの方が少し良いかな」くらいに思っていたのです。
カスタムプロンプトのような、開発フロー自体を効率化するための『機能』の存在を、僕はまだ知りませんでした。
ただ、そんな僕でも、日々の面倒を少しでも楽にしたいという思いはありました。特にMRのdescription作成は定型作業の極みだったので、以前からこんな「カスタムプロンプト」だけは用意して、限定的に使っていました。
---
mode: agent
---
以下のテンプレートを使用し、MRのdescriptionの作成を行ってください。
前提の情報として、[チケットのプレフィックス]-XXXXのチケットに記載されている内容を参考にしてください。
## やったこと
[1-2行で変更の概要を記載]
## 背景
[なぜこの変更が必要なのかを簡潔に記載]
## 実装内容
（...テンプレートの詳細は省略...）
/create_mr_description と打ち込むだけで説明文が作られるのは便利でしたが、僕のCopilot活用は、この「個別の面倒事をスポット的に解決する」レベルで止まっていたのです。
本当の転機は、ある日のチームでのモブプログラミング中に訪れました。
他のメンバーがCopilotを使っている画面を見て、僕は衝撃を受けます。僕が知らない使い方をしていたのです。それは、「カスタム指示」 という機能でした。
僕が使っていた / で呼び出すコマンド（スラッシュコマンド）とは違い、その人のCopilotは、まるでチームの暗黙のルールをすべて理解しているかのように、常に一貫したコーディングスタイルに沿ったコードを生成していました。
さらに、「Jiraのような社内ツールと連携させる方法(MCPとの接続方法)」も知りました。
「Copilotって、そんなことまでできるのか…！」
その日の僕の頭は、新しい発見でいっぱいでした。そして、一つのアイデアが閃きます。
「僕が点として使っていた『カスタムプロンプト』と、今日知った『常に全体を監視するカスタム指示』を線で繋げれば、あの面倒な開発フローを、まるごと自動化できるんじゃないか？」
（もちろん、こうした仕組みはClaudeのHooksなどを使っても実現できるのかもしれませんが）
このひらめきが、僕とCopilotの関係を大きく変えることになったのです。
【実装】 Copilotに"手順書"を渡す。「ワークフロー自動化」への挑戦
第1章で閃いた、「点（カスタムプロンプト）と線（カスタム指示）を繋ぐ」というアイデア。これを実現すべく、僕は早速、開発フロー全体の自動化設計に取り掛かりました。
目指すのは、もちろん「Jiraチケットの番号をCopilotに投げるだけで、MR作成の直前まで一連の作業が進行する」という、あの夢のような仕組みです。
その設計の核となったのが、全体の流れを定義した「ワークフロー指示書（＝カスタム指示）」 と、各工程を担当する個別の「タスクプロンプト（＝カスタムプロンプト）」 を組み合わせるアプローチでした。
※【使い方補足】
プロジェクト単位で設定するときは、
- カスタムプロンプト: プロジェクトの.github/prompts/フォルダに.mdファイルを置くと、/ファイル名で呼び出せます。
- カスタム指示: .github/instructions/[任意のファイル名].instructions.mdにプロンプトを記述すると、そのプロジェクトで常に指示が有効になります。
チャットウィンドウ右上の歯車マークから設定できます
【ステップ1】 開発準備プロンプト
まず着手したのは、すべての起点となる「準備」の自動化です。
---
mode: agent
---
# 指示
Jiraチケットの情報を元に、開発の準備を行ってください。
# 手順
1. **チケット情報の確認:** 与えられたチケット番号（例: `TICKET-1234`）の内容を要約してください。
2. **ブランチ名の提案:** チケット内容に基づき、`[プレフィックス]-XXXX_（内容の要約）`という命名規則でブランチ名を提案してください。
3. **TODOリストの作成:** 開発に必要なタスクを抽出し、`.github/TODOS.md` というファイルにMarkdown形式で出力してください。
【ステップ2】 実装プロンプト
次に、ステップ1で作られたTODOリストを一つずつこなしていく「実装」のプロンプトです。
---
mode: 'agent'
---
# 指示
`.github/TODOS.md` ファイルを読み込み、未完了のタスクを **1つだけ** 実行してください。
# 制約
- 必ず、チェックが付いていない最初のタスクを1つだけ実行してください。
- 完了後は、実行内容を報告し、`.github/TODOS.md` の該当項目にチェックを入れてください。
- 判断に迷うことがあれば、作業を進めずにユーザーに確認してください。
【ステップ3】 MR作成プロンプト
そして、すべての実装が完了した後の最終工程が、このMR作成プロンプトです。これは僕が最初に作ったプロンプトでもあり、ワークフローの締めくくりとして活躍してくれます。
---
mode: agent
---
以下のテンプレートを使用し、MRのdescriptionの作成を行ってください。
前提の情報として、[チケットのプレフィックス]-XXXXのチケットに記載されている内容を参考にしてください。
## やったこと
[1-2行で変更の概要を記載]
## 背景
[なぜこの変更が必要なのかを簡潔に記載]
## 実装内容
（...テンプレートの詳細は省略...）
全体を管理する"ワークフロー指示書"
そして、これらのプロンプト群を連携させるのが、カスタム指示として設定した「ワークフロー指示書」です。
# 指示
Jiraのチケット番号が渡されたら、以下の手順で開発を進行してください。
中断した場合は、次のステップから処理を再開してください。
1. **現状の確認:**
- チケット番号に対応するブランチは存在しますか？
- `.github/TODOS.md` ファイルは存在し、未完了のタスクはありますか？
2. **次のアクションの決定:**
- **もしブランチがなければ:** `/setup` プロンプトを呼び出してください。
- **もしブランチはあり、TODOが残っていれば:** `/implement` プロンプトを呼び出してください。
- **もしTODOがすべて完了していれば:** `/create_merge_request` プロンプトを呼び出してください。
この指示書のおかげで、僕はただチケット番号をCopilotに投げ、生成されたコードの確認をするだけでよくなりました。
補足：この方法がうまくハマるケース
と、ここまで紹介してきましたが、少し補足させてください。
正直なところ、この自動化フローがいつでも完璧に機能するわけではない、というのが私の実感です。今回うまくいっている背景には、担当したチケットの実装が、ある程度パターン化された比較的単純なものだったという側面が大きいと考えています。
逆に、複雑なビジネスロジックの設計や、前例のない機能開発など、高度な設計判断や創造性が求められるタスクについては、まだまだAIに任せきりにするのは難しいでしょう。
あくまで「得意なことはAIに任せて、人間は人間にしかできないことに集中する」という使い分けが、現時点での最適解なのだと思います。
【効果】 Copilotを"育てる"という発想。私が手に入れた本当の価値
この仕組みを1ヶ月運用してみて、生産性が上がったのはもちろんですが、僕が感じたメリットはそれだけではありませんでした。
一番大きな変化は、自分の"脳のメモリ"が解放されたことです。
これまで、ブランチ名のような些細なことから、MRの説明文の構成、単純な実装作業まで、意識せずとも脳の片隅で常にリソースを消費していました。
その定型作業をCopilotに完全に移譲できたことで、僕の頭の中には大きな「余白」が生まれました。そして、その余白を、
「この設計で本当にユーザーは使いやすいだろうか？」
「パフォーマンスにボトルネックは生まれないか？」
「もっと良いアーキテクチャはないだろうか？」
といった、より本質的で創造的な課題に向き合うために使えるようになったのです。
この経験を通じて、僕のAIに対する考え方は大きく変わりました。Copilotは、単にコードを「書かせる」ツールではありません。自分の仕事のやり方や、チームのルールを辛抱強く教え込み、自分だけのアシスタントとして 「育てる」ツール なのだと。
【今後の展望】 これからのAIとの付き合い方
今回は、僕がGitHub Copilotと真剣に向き合い、開発フローの自動化に挑戦した1ヶ月間の記録をご紹介しました。
もちろん、これでClaude Codeを使わなくなったわけではありません。
あれだけ日夜作業をともにしたClaude Codeのことを忘れられないのですよね...。
最近では、Copilotに実装させたコードをClaudeにレビューさせてみる、といった「AI同士の相互レビュー」のような使い方も試しています。それぞれのツールの得意なことを理解し、適材適所で付き合っていくのがベストなのでしょう。
この記事で紹介したプロンプトは、僕のプロジェクトに特化した部分も多いですが、「定型作業をプロンプトに落とし込む」という考え方自体は、どんな開発現場でも応用が効くはずです。
もしこの記事が、皆さんの日々の「ちょっとした面倒」を解消するヒントになれば、そして、皆さんのCopilotを"最強の相棒"に育てるきっかけになれば、これほど嬉しいことはありません。
「自分はこう使ってるよ！」といった情報があれば、ぜひ教えてください！
Discussion