GitHub Copilotを個人の道具からチームの脳へ
〜カスタムコマンド導入で開発工数を34%削減した話〜

AIエンジニア、クラウドエンジニア
内海志織

2025年12月23日掲載

ソフトバンクアドベントカレンダー 2025 23日目の記事を担当する内海です。

普段は、RAGの回答精度向上を支援するデータ構造化ツールなどを提供する「TASUKI Annotation」サービスの技術開発を担当しております。

今回は、Github Copilotを用いて開発工数を34%削減し、月28時間の業務から解放された運用の仕組みを具体的なコード設定とともにを紹介します。

対象読者

AIツール導入を検討中のプロジェクトリーダー
Copilot活用をさらに最適化したい開発チームメンバー
「AIツールの生成するコードがまだ商用品質に達していない」と感じているエンジニア

1. 課題：Github Copilot任せだと「品質」が揃わない

私の所属するチームでは、あるプロジェクトが始動し、開発が本業ではないメンバー2名で開発を進めることになりました。開発効率化のためにGithub Copilotも導入していました。

しかし導入当初、私たちは大きな壁にぶつかっていました。Copilotは便利ですが、プロンプトの入力方法が属人化しており、生成されるコードの品質にばらつきが生じました。

課題：

Copilot単体では、メンバー間で生成コードの品質にばらつきが発生
結果として商用レベルのシステム構築に必要なレビューコストが増大

そこで私たちは、Copilotに「プロジェクトの共通認識」を持たせるための設定を行いました。

2. 解決策：「カスタムコマンド」でチームの脳を実装する

具体的には、リポジトリ内に特定のファイルを配置することで、Copilotの挙動を制御しました。

.github フォルダ配下に、以下のような構成でインストラクション（指示書）とプロンプトを配置します。

.github/
├ copilot-instructions.md     # プロジェクト全体の共通ルール
└ prompts/                    # 各作業に特化した「手順書」（カスタムコマンド）
   ├ docstring.prompt.md      # ドキュメント生成用
   ├ unittest.prompt.md       # テストコード生成用
   └ logger.prompt.md         # ログ実装用

① 共通ルールの定義 (copilot-instructions.md)

ここには、プロジェクト概要、アーキテクチャ、命名規則など「常に意識してほしいこと」（例：プロジェクト概要、アーキテクチャ、技術スタック、命名規則など）を記述します。これを置くだけで、Copilotは常にこのルールを「コンテキスト」として読み込んだ状態で回答してくれるようになります。以下に .github/copilot-instructions.mdの例を示します。

# 開発者ガイドライン

このリポジトリでは、AI駆動で商用レベルのエージェントパッケージを開発・運用するための各種ガイドラインを定義しています。
以下の目次から各セクションの詳細ページにジャンプしてください。

---

## パッケージの目的

本パッケージは、商用レベルの品質を維持しつつ実験・検証を効率的に進められる環境を提供することを目的としています。具体的には、以下を実現します。

- OSSライクな高品質コード（Lint・型チェック・セキュリティチェック・テスト）を前提にビルドできるようにする。
- 検証アプリケーション（Flask API）を使い、結果の再現性や機能改修を容易に行えるようにする
---

## 目次

1. [プロジェクト概要](./instructions/project_overview.instruction.md)
2. [コーディングガイドライン](./instructions/coding.instruction.md)
3. [タスク進捗管理](./instructions/task_progress.instruction.md)

これを置くだけで、Copilotは常にこのルールを「コンテキスト」として読み込みます。

② カスタムコマンドの実装 (*.prompt.md)

これが今回の肝です。特定の作業を行う際だけのルールを .prompt.md ファイルとして切り出します。ファイル名がそのままコマンドになります（例：docstring.prompt.md → /docstring）。

例えば、「GoogleスタイルのDocstringを日本語で書いてほしい」というルールを毎回チャットで打つのは手間です。そこで以下のようなファイルを作成します。

この関数のドキュメントを生成してください。

# Docstring Style Guide
- Googleスタイルを採用
- Args, Returns, Raises を必ず記載
- 日本語で記述すること

これにより、チャット欄で /docstring と入力するだけで、指定したフォーマットのドキュメントが一瞬で生成されます。

3. 運用の工夫: 「隠れたルール」を逃さないサイクル

仕組みを作っても、ルールは日々変わります。私たちはナレッジの鮮度を保つために、「追加要望したくなったら好きにカスタムプロンプトに反映していい」という運用を徹底しました。

カスタムプロンプトは作業ごとにファイルが分かれているため、他のルールへの影響を気にせず気軽に追加できるのがメリットです。

このサイクルを回すことで、GitHub Copilotに「チームの最新の脳」がどんどん注入されていきました。

4. 効果検証：開発工数を34%削減

この仕組みを導入し、2ヶ月間の開発工数を計測した結果、平均で 34%の削減に成功しました。

特に「ログ整備」や「ドキュメント生成」などの面倒な作業がほぼゼロになり、浮いた時間を本質的な「仕様設計」や「アーキテクチャ検討」に充てることができました。

作業項目	従来想定(h)	Copilot活用(h)	削減率
全体工数	82.2	54.3	-34%
関数内の説明文生成	3.3	0.2	-94%
ログ整備	0.7	0.0	-95%
ユニットテスト整備	5.0	1.3	-73%