Skip to content

MS_GitHubCopilotCodingAgent

Jump to bottom
nishi_74322014 edited this page Aug 21, 2026 · 1 revision

GitHub Copilot Coding Agent

概要

コーディング・エージェント・ツール

  • Claude Code をはじめとする各プロダクトの台頭に強い危機感を持って
    急ピッチで開発された（かつ現在も進化している）
  • 名前の通り、従来のクラス・メソッド生成、スニペット生成、オートコンプリートから、
    開発プロジェクトを代行できるコーディング・エージェントとなった。
  • このブレークスルーは「従来のエージェントアーキテクチャの成熟」と
    「推論モデル（Reasoning Models）の登場」が完璧に噛み合ったからと言われている。

詳細

使い方については参考を参照。

実装可能な機能

Claude Code（オリジナル・コンテンツ（イキナリLLMコーディング・エージェント）
（DNET_LLMCodingAgent.md）を参照）と同じ。

エージェント

  • my-reviewer.agent.md などとして（拡張子：.agent.md）以下のように定義する。
    • ヘッダ部は「YAML フロントマター（メタデータ）」、
      ボディ部は「Markdown 形式の指示」
    • ヘッダ部には、name、tools、model などを任意で設定できる
      （name、description は必須項目）。
---
name: my-reviewer
description: バグやセキュリティ問題に特化したコードレビュアー
---

# Code Reviewer

あなたは、バグやセキュリティ問題の検出に特化したコードレビュアーです。

コードレビュー時には、必ず以下を確認してください：

- SQLインジェクションの脆弱性
- エラーハンドリングの不足
- ハードコードされたシークレット情報

補足（サブエージェントを分ける効用と副作用）: 「専門性の高い
エージェントを定義する」ことの実務上の意味を補っておく。

【分ける効用】★
 ① 【コンテキストの隔離】
     レビュー用エージェントは
     レビューに必要な情報だけを読む
     → 本体の会話履歴が
       大量のファイル内容で埋まらない ★
 ② 【役割の固定】
     「あなたはレビュアーです」という
     強い役割付けが毎回効く
     → 指示のブレが減る
 ③ 【ツールの制限】
     tools でファイル書き込みを禁じれば
     「レビューのつもりが勝手に直された」を防げる ★

【副作用】
 ① サブエージェントは【毎回ゼロから始まる】
     → 呼ぶたびに前提を再調査するコストがかかる
     → 本体で既に分かっていることは
       プロンプトで渡してやる方が速い
 ② 数を増やしすぎると
     「どれが呼ばれたか分からない」状態になる
     → description を明確に書き分ける ★

スキル

  • SKILL.md を以下のように定義する。
    • ヘッダ部は「YAML フロントマター（メタデータ）」、
      ボディ部は「Markdown 形式の指示」
    • ヘッダ部には、license、compatibility、metadata、allowed-tools などを
      任意で設定できる（name、description は必須項目）。
---
name: echo-skill
description: 入力されたテキストをそのままユーザーに返します。
---

# Echo Skill
このスキルは、入力されたテキストを受け取り、それをそのまま返します。

  • SKILL.md ファイルの置き場は以下の 2 箇所

    • リポジトリ：.github/skills/スキル名（ココでは echo など）
    • 個人設定：~/.copilot/skills/スキル名（ココでは echo など）

  • 複雑なスキルには
    サンプルコードやスクリプトを用意できる。

.github/skills/
└── my-skill/
    ├── SKILL.md           # 必須：スキル定義と指示
    ├── examples/          # 任意：参照用サンプルコード
    │     └── sample.py
    └── scripts/           # 任意：スキルで使用するスクリプト
           └── validate.sh

補足（エージェントとスキルの使い分け）: 両者は似た形式
（YAML フロントマター + Markdown）だが、役割が違う。

エージェント（.agent.md） スキル（SKILL.md）
何を定義するか 人格・役割・使えるツール 手順・知識
実行の単位 独立したコンテキストで動く ★ 呼び出し元の文脈に読み込まれる ★
付属ファイル なし examples / scripts を持てる ★
主な用途 レビュー、調査、設計 定型手順、規約、ツールの使い方
分量 30,000 文字制限あり ファイル分割で実質無制限 ★ 
【原文の指摘が的確な点】★
   「定義が長すぎる場合、詳細はスキルで管理する」
     → エージェント定義は【役割の宣言】に留め、
       具体的な手順は【スキルに外出しする】
     → これが公式に想定された使い分けである

【Progressive Disclosure（段階的開示）】★
   スキルの設計思想。
     ① まず description だけが読まれる（軽い）
     ② 関連しそうなら SKILL.md 本体が読まれる
     ③ 必要なら examples / scripts を辿る
   → 【コンテキストを浪費せずに
     大量の知識を持たせられる】仕組み
   → だから description の書き方が最重要 ★
     「いつ使うか」が明確に書かれていないと発火しない
     （原文の「発火しない場合は description の調整が必要」）

【移植性について】★
   原文が「オープン標準に基づいている」と書くとおり、
   スキルの形式は
     Claude Code / GitHub Copilot / その他
   でほぼ共通になりつつある。
     → 【.claude/skills/ ↔ .github/skills/】を
       シンボリック リンクで共有する運用も見られる
     → ただし
       - 使えるツール名が違う
       - allowed-tools の解釈が違う（原文の指摘どおり）
       - 発火のしやすさが違う
       ため【完全な互換ではない】

レガシー対応

  • なお、GitHub Copilot同様、
    Visual Studio Code から、
    Visual Studio 20XX（Visual Studio）、
    その他、著名な IDE でもサポートされている。
  • 特に、Visual Studio 20XX（Visual Studio）の
    .NET Framework 開発は PJ ファイルの古さなどもあり、
    winapp CLI でなくても開発可能か気になっていたが、動きはしたが、
    • PJ ファイルの編集は、IDE にロックされている中で、
      スクリプトで無理やりやろうとしてバグっていたケースがあった。
    • また、VS の一部の？ファイルは既定で BOM 付き UTF-8 である必要があり、
      エージェントが追加した BOM 無し UTF-8 ファイルで文字化けが発生して
      エラーになったりした。

移行メモ（誤字）: 移行元の「文字化が発生して」を
「文字化けが発生して」に修正した。

補足（レガシー .NET 開発でエージェントが躓く理由）: 作者が遭遇した
2 つの問題は、いずれも典型的なので一般化しておく。

【① プロジェクト ファイルの編集競合】★
   旧形式の .csproj / .vbproj は
     ・ファイルを 1 つずつ <Compile Include> で列挙する
     ・GUID / ProjectTypeGuids など
       意味の分かりにくい要素が多い
     → エージェントがテキスト編集すると
       【整合性を壊しやすい】
     → さらに VS が【開いている間ロックし、
       VS 側の内容で上書きする】ため、
       「直したはずが戻る」現象が起きる

   【対策】
     ・エージェントに触らせる前に
       【VS を閉じる】★
     ・可能なら【SDK スタイルへ変換】してから作業する
       （ファイル列挙が不要になり、編集点が激減する）
     ・AGENTS.md に
       「.csproj は手動で編集する」と明記する ★

【② BOM 付き UTF-8 の要求】★
   Visual Studio が生成する日本語入りファイルは
   【BOM 付き UTF-8】が既定
     → BOM が無いと
       C# コンパイラが【Shift_JIS と誤認】して
       日本語コメント・文字列リテラルが化ける
       （特に .NET Framework 世代の csc）
     → エージェント／一般的なツールは
       【BOM 無しで書く】のが普通

   【対策】
     ・.gitattributes / .editorconfig で
       方針を明示する
         [*.cs]
         charset = utf-8-bom        # ★
     ・ビルド前に BOM を付与するスクリプトを用意する
     ・.csproj に
       <CodePage>65001</CodePage> を指定して
       BOM 無しでも UTF-8 と解釈させる（回避策）
     ・AGENTS.md に
       「新規 .cs は BOM 付き UTF-8 で保存する」と書く ★

【レガシー開発でエージェントを使う際の一般則】★
 ・【AGENTS.md に環境固有の制約を書く】
     文字コード、改行コード、
     触ってはいけないファイル、ビルド手順
 ・【ビルドを回せるようにしておく】
     msbuild をエージェントから叩けると
     自己修正のループが回る
 ・【差分を小さく保つ】
     旧形式プロジェクトは
     大きな変更のレビューが難しい
  • 検証
    • みたいな：https://github.com/codecypher/NorthwindForms
    • Northwind を用いて生成した仕様
      （生成AIを活用した設計書のブレークダウン（DNET_DesignDocBreakdownWithAI.md））を用いて、
      GitHub Copilot Coding Agent で実装を行った。
    • ココでの方式は、プロ用（フェーズ毎の検収）＋ ドキュメント・フォワード
      （いずれもオリジナル・コンテンツ（イキナリLLMコーディング・エージェント）
      （DNET_LLMCodingAgent.md）の該当節）と言える。

Northwind WinForms

  • GHC、Visual Studio 2026（Visual Studio）、
    .NET Framework 4.8.2（.NET Framework）、
    Windows Forms
  • なお、AGENTS.md と SPEC.md から、...\.copilot\plans\plan*.md を生成させ、
    ソレを手修正した PLAN.md を作成して、実行している。

Northwind WebForms

  • GHC、Visual Studio 2026（Visual Studio）、
    .NET Framework 4.8.2（.NET Framework）、
    ASP.NET Web Forms
  • なお、AGENTS.md と SPEC.md から、...\.copilot\plans\plan*.md を生成させ、
    ソレを手修正した PLAN.md を作成して、実行している。

補足（「計画を生成させ、手修正してから実行する」の意義）: この進め方は
エージェント活用の要諦なので、明示しておく。

【なぜ一発で実装させないのか】★
   ・エージェントは【途中で方針を変えない】
     → 最初の方針が間違っていると
       大量の間違ったコードが生成される
     → レビューの負荷が爆発する

   ・【計画（PLAN.md）を先に出させる】と
     → 実装前に方針を確認・修正できる ★
     → 修正コストが【文書の数行】で済む
     → 実装中はその計画に沿って進むので
       脱線しにくい

【ファイルの役割分担（本事例の構成）】★
   AGENTS.md  … 【恒久的な規約】
                 文字コード、命名、禁止事項、ビルド手順
   SPEC.md    … 【何を作るか】（要件・設計）
   PLAN.md    … 【どの順で作るか】（作業分解）★
                 → 人がレビュー・修正する対象

   → 「設計書 → 計画 → 実装」という
     通常の開発工程を、そのままエージェントに写している
   → 原文の【ドキュメント・フォワード】という
     呼び方はこの構造を指している ★

Claude Codeでもイケるらしい。

WinUI agent pluginが出ているらしい。

# Add the WinUI plugin to GitHub Copilot CLI
/plugin install winui@awesome-copilot
# Run the winui-setup skill to install all prerequisites
/winui:winui-setup

あとはカスタムエージェント `winui-dev` を選んで、\
「WinUI 3 で〇〇というアプリを作ってください」と入力。
  • Claude Code
claude plugin marketplace add microsoft/win-dev-skills
claude plugin install winui@win-dev-skills

インストール後、Claude Code のプロンプト先頭に `@winui-dev` を付与し\
`@winui-dev` エージェントを使用する。

補足（プラグイン＝スキル＋エージェントの配布形式）: 上記の
/plugin install や claude plugin install が何をしているかを補う。

【プラグインの中身】★
   プラグイン ＝
     【スキル】＋【カスタム エージェント】＋
     【スラッシュ コマンド】＋【MCP サーバ定義】
     をまとめて配布する仕組み

   → 手で .github/skills/ に置いていたものを
     【マーケットプレース経由で配れる】ようにしたもの
   → 更新も plugin update で追随できる

【WinUI agent plugin が提供するもの】
   ・winui-setup    … 前提（Windows App SDK、
                      ワークロード）の導入を代行するスキル
   ・winui-dev      … WinUI 3 に特化したエージェント
   ・XAML / WinUI の【最新 API 知識】★
     → LLM の学習データは WinUI 3 について薄く、
       古い UWP の書き方を出しがち
     → プラグインが正しい書き方を注入する
       （これが「ぐっと楽になった」の中身）

【原文の「WinUI 3 の評判はカナリ悪い」について】
   この評価には根拠がある。
     ・WPF からの移行パスが用意されていない
     ・機能欠落が長く残った
       （印刷、一部のコントロール、アクセシビリティ）
     ・パッケージ化（MSIX）まわりが煩雑
     ・Microsoft 自身が
       WinForms/WPF/UWP/WinUI と
       【方針を変え続けた】ことへの不信 ★

   → 「エージェントが楽にしてくれる」ことと
     「基盤として選ぶべきか」は別問題であり、
     作者の慎重な姿勢は妥当である

参考

開発基盤部会 Wiki

Master Vibe Coding with AI Coding Agents：Claude Code...（DNET_MasterVibeCoding.md）

オリジナル・コンテンツ（イキナリLLMコーディング・エージェント）（DNET_LLMCodingAgent.md）

Tags: 移行, .NET開発, 構成管理ツール, CI, BI/AI

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally