この講義では、いま急速に進化している「AIエージェント」、特にソフトウェア開発を支援する「コーディングエージェント」について学びます。題材として GitHub Copilot を取り上げ、その機能とカスタマイズ方法を見ていきます。

まず「AIエージェント」とは何かを整理しておきましょう。よく聞く「AI」や「LLM」との違いを押さえることが大事です。

• モデル（LLM）= 頭脳。テキストを受け取って回答を生成する AI の本体。ChatGPT や Claude の裏側で動いているもの
• AIエージェント = 頭脳＋手足。モデルに加えて、外部ツール（ファイル操作・Web検索・API呼び出しなど）を組み合わせて自律的にタスクをこなす仕組み
• コーディングエージェント = AIエージェントの中でも、ソフトウェア開発に特化したもの。コードの読み書き・ビルド・テスト・デバッグまでこなす

前のセクションで Copilot の名前は知りましたね。ここからは「具体的に何ができるのか」を見ていきます。Copilot には3つのモードがあり、状況に応じて使い分けます。

• コードについて質問・調査するモード
• ファイルの編集は行わず、会話形式で回答を得る

💬 「この getUser 関数は何をしている？引数の userId はどこから渡される？」

→ Copilot がコードを読み解いて、関数の役割・呼び出し元・データの流れを説明してくれる

• 対象ファイルを自分で指定して、複数ファイルを一括編集するモード
• 変更箇所がインラインdiffで表示され、1つずつ承認/棄却できる

💬 「src/utils 配下の3ファイルで、console.log を全て logger.info に置き換えて」

→ 指定したファイルだけを対象に変更案がdiffで表示される。1箇所ずつ Accept / Discard を選べる

• 最も自律性が高いモード。タスクを渡すと、必要なファイルの特定・編集・ターミナル実行まで自動で行う
• エラーを検出すると自己修復を試みる（セルフヒーリング）

💬 「ユーザー登録APIにメールアドレスのバリデーションを追加して。不正な形式の場合は400エラーを返すようにして」

→ Copilot が関連ファイルを自分で探し、バリデーションロジックの追加・エラーハンドリングの実装・テストの作成まで自律的に進める

この講義では最も強力な Agent モードを中心に、その仕組みと使い方を説明していきます。

Agent モードは「計画 → 実行 → 検証 → 自己修復」のサイクルで動きます。単にコードを生成するだけでなく、エンジニアの作業フロー全体を支援するのが特徴です。それぞれのフェーズを見ていきましょう。

Agent モードに指示を出すと、いきなりコードを書き始めるわけではありません。まずコードベースを読み込み、実装計画を立てます。

• 読み取り専用のツール（コード検索・Web取得など）で調査し、方針を整理する
• 計画を確認・修正してから実装に進めるため、意図しない変更を防げる
• 特に大規模な変更やアーキテクチャに関わるタスクで効果が大きい

💬 「パスワードリセット機能を追加したい。まず計画だけ立てて」

→ Copilot が既存の認証まわりのコードを読み、「1. パスワードリセット用のエンドポイント追加 2. トークン生成ロジック 3. メール送信処理 4. リセット画面のUI」のような実装計画を提示する。この時点ではコードは一切変更されない

計画ができたら、Agent は様々な「スキル」（組み込みツール）を使って実装を進めます。単なるコード補完ではなく、ビルド・テスト・デバッグまでこなせるのがポイントです。

「Agent が自律的に動く」と聞くと不安に思うかもしれません。安心してください。すべての操作の前にユーザーの承認が求められます。

• ファイル編集やターミナルコマンドの実行前に、必ず承認を求められる
• 変更内容はインラインdiffで表示され、Accept（承認）/ Discard（棄却）を選べる
• チェックポイント機能があり、「やっぱり元に戻したい」と思ったらいつでもロールバック可能

Agent: 「src/auth/validator.ts を以下のように変更します」→ diffが表示される

あなた: 内容を確認して Accept → 次のステップへ進む

Agent: 「npm test を実行します」→ 承認を求められる

あなた: Accept → テストが走る → 失敗したら Agent が自動で修正案を提示

承認の手間を減らしたい場合、承認レベルを設定できます：

• Session: 現在のセッション中だけ特定操作を自動承認
• Workspace: そのプロジェクトで常に自動承認
• Application: すべてのプロジェクトで自動承認（非推奨）

ここまでは「素の Copilot」の能力を見てきました。ここからは、チームや業務に合わせて Copilot の振る舞いをカスタマイズする方法を紹介します。

カスタマイズの中で最も簡単なのが、裏側で動く LLM（大規模言語モデル）の切り替えです。

• GPT-4o、Claude Sonnet、Gemini など複数のモデルから選択可能
• モデルによって得意分野が異なる（例：コード生成が得意、長い文脈の理解が得意、など）
• チャット画面のモデル選択ドロップダウンから簡単に切り替えられる

『Claude Sonnet に切り替えて同じ質問をしたら、GPT-4o とは違うアプローチの実装案が返ってきた』
→ 行き詰まったらモデルを変えてみるのも1つの手

便利に使うためにも、コストの仕組みを知っておきましょう。なお、課金の仕組みは2026年6月に新しくなりました（後述）。

AIクレジット制の仕組み

• Copilot の利用量は「AIクレジット」で測られる（1 AIクレジット = 約 $0.01）
• やり取りで消費した「トークン量 × モデルの単価」がクレジットに換算される。たくさん入出力するほど、また高性能なモデルほど多くのクレジットを消費する
• プランごとに月のクレジット枠が決まっている（Business プランでは 1シートあたり 1,900 クレジット/月、Enterprise プランでは 3,900 クレジット/月）。枠は組織全体でプールされる
• 枠を超えた分は追加課金（従量課金）になる

モデルによってコストが大きく変わる

ここが前のセクションで触れた「モデル選択」と直結します。モデルごとにトークン単価が大きく異なります。

• 軽量・標準モデルは単価が安い（一部は追加クレジットを消費しない「included」モデル）
• 高性能モデル（Claude Opus など）は単価が桁違いに高く、標準モデルの10倍以上になることもある
• 通常のコード補完や軽いチャットの消費は小さいが、高性能モデルで長い文脈を何度もやり取りすると一気に消費する

リポジトリに特定のファイルを配置するだけで、Copilot の振る舞いを制御できます。チームで統一した使い方をするために重要な仕組みです。

• リポジトリ全体に適用される共通指示ファイル
• Markdown で自然言語の指示を書くだけでOK

記述例：

# プロジェクト概要
ECサイトのバックエンドAPI（TypeScript + Express）

# 開発ルール
- テストは Jest で書く。テストファイルは __tests__ ディレクトリに配置
- エラーハンドリングは AppError クラスを使用する
- DBアクセスは Repository パターンで実装する

# ビルド・テスト
- ビルド: npm run build
- テスト: npm test
- リント: npm run lint

• YAML フロントマターで対象ファイルを glob パターンで指定
• 「フロントエンドは React のルール」「バックエンドは Go のルール」と分けられる

記述例：

---
applyTo: "src/components/**/*.tsx"
---
- コンポーネントは関数コンポーネントで書く
- スタイリングは Tailwind CSS を使用する
- Props の型定義は interface で明示する

• Agent モードに特化した指示ファイル
• 複数の AGENTS.md を階層的に配置して、ディレクトリごとに異なるルールを適用できる

記述例：

# Agent への指示
- 新しいファイルを作る前に、既存の類似実装を必ず検索すること
- テストを書いたら必ず実行して、パスすることを確認すること
- コミットメッセージは Conventional Commits 形式で書くこと

MCP（Model Context Protocol）は、AIモデルに外部ツールを接続するためのオープンな標準規格です。「AIのUSBポート」とイメージしてください。

• DB接続、API呼び出し、Playwright でブラウザ操作など、Copilot 単体ではできないことを追加できる
• .vscode/mcp.json に設定を書いてリポジトリにコミットすれば、チーム全員が同じツールを使える

💬 「このページのスクリーンショットを撮って、デザインカンプと見比べて」

→ MCP で Playwright（ブラウザ操作ツール）を接続していれば、Copilot がブラウザを操作してスクリーンショットを撮影し、差分を報告してくれる

• .agent.md ファイルで、用途別の専用エージェントを定義できる
• 使えるツールを制限したり、特定の振る舞いを指定できる

💬 Planning エージェント：読み取り専用ツールだけで計画を立てる。コードは一切変更しない

💬 レビューエージェント：変更されたファイルだけを対象に、セキュリティやパフォーマンスの問題を指摘する

Copilot は強力なツールですが、使い方を誤るとリスクもあります。業務で使う前に知っておいてほしいことをまとめます。

• プロンプトに API キー、パスワード、個人情報などの機密情報を含めない
• Copilot に送った内容はクラウド上の LLM に送信される（※組織のプラン設定による）
• .env ファイルや credentials を「これを参考にして」と渡さないよう注意

❌ 『このAPIキー sk-xxxx を使って外部APIを呼ぶ処理を書いて』

✅ 『環境変数 API_KEY を使って外部APIを呼ぶ処理を書いて』

• Copilot は「存在しない関数」「間違った引数」「古い API 仕様」をもっともらしく提案することがある
• 特に、あまりメジャーでないライブラリや最新の API では頻度が上がる
• 提案されたコードが動くかどうか、必ず自分で確認・テストする

💬 『○○ライブラリで△△する方法を教えて』
→ Copilot が自信満々に回答するが、提案された関数名が実際には存在しない……ということがある。公式ドキュメントとの照合を習慣にしよう

• Copilot が生成したコードが、学習元のオープンソースコードと類似する可能性がある
• Copilot の設定で「パブリックコードに一致する提案をブロックする」オプションがある
• 業務コードに取り込む際は、ライセンス違反がないか意識しておく

1. Copilot には Ask / Edit / Agent の3モードがあり、タスクの複雑さで使い分ける
2. Agent モードは「計画 → 実行 → 検証 → 自己修復」のサイクルで自律的に動く
3. すべての操作に承認フローがあり、チェックポイントで安全にロールバックできる
4. 指示ファイル（copilot-instructions.md, AGENTS.md）でチーム全体の振る舞いを統一できる
5. MCP で外部ツールを接続し、Copilot の能力を拡張できる
6. 機密情報・ハルシネーション・ライセンスに注意し、提案を鵜呑みにしない

次のセクション「Copilot 実践」では、実際に Agent モードを使ってタスクに取り組みます。