• 戻る（GitHub）
  • GitHub CLI
  • GitHub Actions
  • GitHub Copilot
    • GitHub Copilot Coding Agent
    • GitHub Copilot CLI

• AI がコードを自動的に生成し、開発者の生産性を向上させるツール。
• LLM（GPT-4）と IDE を繋ぐ、Extension と Bridge 機能から構成される。
• 殆どの重要な機能は、プロンプトのコントロールと出力の検証である。

補足（「LLM（GPT-4）」はもう固定ではない）: 本文執筆時は
GPT-4 一択だったが、現在はモデルを選べる。

【マルチモデル対応（2024年〜）】★
   ・OpenAI       GPT-4o / GPT-5 系 / o シリーズ（推論）
   ・Anthropic    Claude Sonnet / Opus 系 ★
   ・Google       Gemini 系
   → Copilot Chat の【モデル ピッカー】で切り替える
   → 組織管理者がポリシーで
     利用可能なモデルを制限できる

【なぜ重要か】
   ・「Copilot ＝ OpenAI」という前提が崩れた
   ・タスクによって適するモデルが異なる
       補完・小さな修正 → 速いモデル
       設計・大規模な変更 → 推論の強いモデル ★
   ・データの流れ先（どのベンダーか）が変わるため、
     【機密性の要件がある組織は要確認】★

【「重要なのはプロンプト制御と出力検証」という指摘】★
   この一文は【本ページで最も本質的】である。
   2 年経った現在も評価は変わらない。
     ・生成そのものは商品化・汎用化した
     ・差がつくのは
         - どの文脈を渡すか（コンテキスト設計）
         - 出てきたものをどう検証するか（テスト／レビュー）
     → エージェント時代になって
       【この重要性はむしろ増した】
     → 詳細は [GitHub Copilot Coding Agent](MS_GitHubCopilotCodingAgent)

いずれも、GPT のコードやテキストの生成機能を用いている。

• 生成（Chat 的な生成）

  • プロンプト：質疑、コメント、テストケース、コードテンプレート
  • 生成内容：提案、エラー修正、リファクタリング
    （冗長性の削除、構造の改善、命名規則の統一）

• 自動補完で生成（IntelliSense 的な生成）
  コンテキスト、型推論、API ドキュメント、カスタム

コード生成の中でも、特殊なユースケースで、
プロンプトにテスト対象コードを入れ、テストコードを Chat 的に生成

• 単体テストの生成
• 統合テストの生成
• テストカバレッジの向上

補足（テスト生成は「二重の罠」がある）: 最も需要が高い用途だが、
使い方を誤ると品質を下げる。

【罠① 実装からテストを生成すると
      「実装が正しい前提」のテストになる】★★
   ・実装にバグがあれば
     【バグごとテストに写経される】
   ・「テストが通る＝正しい」が成り立たなくなる
   → 仕様（受入条件）からテストを書かせる
   → あるいは【境界値・異常系を明示的に指示する】★

【罠② カバレッジだけが上がる】
   ・getter/setter や自動生成コードにまで
     テストが生成され、数字だけ良くなる
   ・保守対象のテストコードが膨張する
   → 【カバレッジは目的ではない】
   → 詳細は [単体・結合テスト方式](MS_UnitAndIntegrationTestMethods)

【有効な使い方】★
   ・既存テストを 1 本書いて、
     【それを手本に類似ケースを量産させる】
   ・パラメタライズド テストのデータ生成
   ・モックの定型コード生成
   → 「発想」ではなく【作業】を任せるのが正解

新発明の「コーディング・エージェント」
（Master Vibe Coding with AI Coding Agents：Claude Code...）の
機能・作法が輸入されている。

• GitHub Copilot Coding Agent
• GitHub Copilot CLI

• コメントの翻訳

• コードの翻訳

  • ドキュメント生成
  • プログラミング言語間の変換

• GitHub Copilot は IDE 内で全てが完結。
• Web ブラウザと IDE を行き来する必要がなく快適に利用可能。

AI が提示するコードの精度が高く、品質向上に寄与する。

日々の開発をスムーズに進めコーディング速度をアップする。

コーディング・エージェントではオート・パイロットも可能
（だが、当然デメリットも存在する）

• AI がコードのサジェスチョンを提供。
• 適切なコード断片を自動的に示す。

• コードを書いているファイルの中でチャット機能を呼び出し、
  コードの生成や修正などを行う。
• プログラムのベースを新規作成したり、部分的な処理を追加したりする。

• コードの生成や修正に関する指示をチャット形式で行う。
• AI との対話を通じて、コードを効率的に作成できる。

• プロンプト・フィルタリング（ユーザーから Copilot への指示）

  • 意図しているユースケースかどうか判断する

• 提案フィルタリング（Copilot からユーザーへの答え）

  • オフトピック・フィルタ
    意図しない回答/ユースケースになっていないかどうか

  • パブリックコードとのマッチングフィルタ

    • Copilot には、「Public コードとの一致を防ぐ」という機能
    • パブリックコードと一致し、この機能が ON（Block）になっている場合、
      フィルタに引っかかる
    • パブリックコードと一致していて、ユーザーがそれを許可する場合、
      Copilot はリファレンスを提示

  • 品質、脆弱性フィルタ

    • SQL インジェクションやハードコードされたシークレットなどを確認し
      安全なコードを提案
    • このフィルタに引っかかった場合、その旨を知らせる回答をだすという挙動になっている。

• 毒性フィルタ

  • ヘイトスピーチや差別、自傷などの内容
  • 中にもさらに 2 つのフィルタがある。
    • LLM として判別するもの
    • あらかじめリストアップされたキーワードとのマッチング

移行メモ（空項目・誤字）: 移行元では
「意図しているユースケースかどうか判断する」の直後に
中身のない箇条書き（-- のみの行）があったため削除した。
また「意図しない回答/ユースケースとになっていないか」の
重複した助詞を整理した。

補足（パブリック コード一致フィルタと、ライセンス上の位置付け）:
「差別化ポイント」として後述されているが、実務上の意味を明確にしておく。

【Duplicate Detection Filter】★
   ・生成された提案が
     【公開リポジトリのコードと約 150 文字以上一致】する場合、
     提案を【ブロック】する（既定は組織設定に従う）
   ・Copilot Business / Enterprise では
     管理者が組織全体に強制できる ★

【なぜ必要か】
   ・学習元に GPL 等の【コピーレフト】コードが含まれうる
   ・一致したコードをそのまま取り込むと
     ライセンス違反の疑いが生じる
   → フィルタは【リスクを下げるが、消しはしない】★

【IP 補償（Copilot Copyright Commitment）】★
   ・Microsoft は Copilot Business / Enterprise の
     有償利用者に対し、
     著作権侵害の申し立てについて【防御・賠償を行う】と表明
   ・ただし条件がある
       - 【フィルタを有効にしていること】★
       - ガードレールを迂回していないこと
   → 企業導入時は【フィルタ ON が実質必須】である

GitHub のアカウントに権利を付与（個別契約や会社契約に紐付け）

Visual Studio Code に GitHub Copilot 系の Extension を
インストール

• GitHub Copilot の Extension から、GitHub にログイン（OAuth 系）
• GitHub Copilot の Extension から、GitHub の WebAPI にアクセスできるようになる。

Settings.json に以下の様な設定を追加

"http.proxyStrictSSL": false,
"http.proxy": "http://<ユーザ名>:<パスワード>@<プロキシサーバのアドレス>:<プロキシサーバのポート>",

「http.proxy」のユーザ名、パスワードはプロキシサーバの設定によっては不要。

補足（proxyStrictSSL: false は最後の手段）: この設定は
TLS 証明書の検証を無効化するため、安易に使うべきではない。

【なぜ必要になるのか】★
   ・企業プロキシが【SSL インスペクション】を行い、
     通信を独自の CA 証明書で再署名している
   ・その CA を VS Code / Node.js が信頼していない
     → 証明書エラーになる

【正しい対処】★
 ① 【企業 CA を OS の証明書ストアに入れる】
     → VS Code は "http.experimental.systemCertificates"
       （現在は既定で有効）で OS ストアを読む
 ② NODE_EXTRA_CA_CERTS 環境変数に
     CA の PEM ファイルを指定する ★
 ③ プロキシ側で
     github.com / api.github.com /
     copilot-proxy.githubusercontent.com 等を
     【インスペクション除外】にしてもらう

【proxyStrictSSL: false の危険】
   ・すべての通信で【中間者攻撃を検知できなくなる】
   ・Copilot 以外の拡張機能の通信にも影響する ★
   → 恒久設定にせず、原因を解消する

【認証情報を settings.json に書かない】★
   ・URL にユーザ名／パスワードを埋めると
     【平文で保存され、設定同期で流出しうる】
   → 認証プロキシなら
     OS の資格情報マネージャや
     プロキシ認証を透過する仕組みを使う

• VS Code ではワークスペースと呼ばれる、フォルダ単位で開く。
• GitHub Copilot ではワークスペース内のソースコードを参照して候補を提案する。
• 参考になる関連ソース・ファイルは、ワークスペース内に格納しておくとよい。

• Copilot は IDE で用意されている補完機能のように自動で候補を提案。
• 候補はグレーアウトされた状態で表示され、Tab を入力することで、反映できる。

「Ctrl + I」で対話形式でのプロンプトからコードを生成させる。

「Ctrl + Enter」で 10 の提案を表示する別のパネルが開く。

補足（現在の Copilot Chat で押さえるべき操作）: 上記に加え、
文脈の与え方が生産性を大きく左右する。

【コンテキスト参照（VS Code / Visual Studio）】★
   #file:Foo.cs        … 特定ファイルを文脈に含める
   #selection          … 選択範囲
   #codebase / @workspace
                       … 【ワークスペース全体を検索させる】★
   #terminalLastCommand… 直前のコマンドと出力
   #problems           … 現在のエラー一覧

【スラッシュ コマンド】
   /explain            … 選択コードの説明
   /fix                … 修正案
   /tests              … テスト生成 ★
   /doc                … ドキュメント コメント生成
   /new                … 新規プロジェクトの雛形

【カスタム指示（最も効果が大きい）】★
   .github/copilot-instructions.md
     → プロジェクトの規約・命名・使用ライブラリを書く
     → 【毎回の指示が不要になる】
     → 詳細は [GitHub Copilot CLI](MS_GitHubCopilotCLI) の
       Instruction ファイルの節も参照

【原文の「Ctrl + Enter で 10 の提案」について】
   ・これは初期の Copilot（提案パネル）の仕様
   ・現在の UI では
     【インライン提案の切替（Alt + ] / Alt + [）】と
     Chat が主体になっており、
     10 件パネルは目立たなくなった ★

タイタニックデータセットのデータ分類問題を GPT を使って解いた
（開発基盤部会 Wiki の Kaggle - Competitions - Getting Started）。

（当然と言えば当然だが、）同様のことが、他の GPT 系 Chat サービスでも可能。

移行メモ（誤字）: 移行元の「GPT を使って描いた」を
文意（データ分類問題を解いた）に沿って「解いた」に改めた。

• 基本的に、コードの提案は実用レベルに達している。
• ただし、あくまでサンプルコードとしての扱い（脆弱性、ライセンスなど）。
• コレは、ググったサンプルコードの扱いと同じなので、今更感。
• また、ある要件に対して、どのような仕様をくむべきか？と言う点は、
  GPT では回答できないケースもある（タイタニックデータセット例で回答できた）。

移行メモ（誤字）: 移行元の「どのようか仕様を」を
「どのような仕様を」に修正した。

IDE 組み込みの場合、

• IntelliSense 的な利用が最も意味が在りそう。

• IDE と GPT（Web）間の行き来が不要と言う点は、コーダー的にはメリットが大きそう
  （アーキテクトにはメリットは少なそう）

• また、様々なコマンドが用意されているが、これらを使いこなすのは難しいため、
  慣れるまではデメリットと考える。

他の GPT 系 Chat サービスとの差別化ポイント

• Chat 的に使う場合は、他の GPT 系 Chat サービスとの差別化ポイントは、
  自動的なプロンプティングとなる。
• ただし、プロンプティングがブラックボックス化されていることは
  逆にデメリットになりかねない。

他の GPT 系 Chat サービスとの差別化ポイント

• GitHub Copilot にはフィルタリングが実装されており、
  他の GPT 系 Chat サービスとの差別化ポイントとなっている。
• ただし、フィルタリングから得られるベネフィットについては評価が難しいと考える
  （機能も不透明）。
• 銀行系システムなどで Web 参照なども禁止されるようなシステム開発では
  安心感を与える可能性がある。

補足（「雑感」の評価を現在から振り返る）: 各項目の見立てを
その後の経過と突き合わせると、当たった点と外れた点がはっきりする。

【当たった点】★
 ・「サンプルコードとしての扱い」
     → 【今も正しい】。生成物のレビュー責任は利用者にある
 ・「どのような仕様を組むべきかは回答できない」
     → 要件定義・トレードオフの判断は
       依然として人間の仕事
 ・「プロンプティングのブラックボックス化はデメリット」
     → だからこそ
       【AGENTS.md / copilot-instructions.md】という
       「明示的に指示を書く」方式が主流になった ★
       （＝ブラックボックスを開ける方向へ進んだ）

【変わった点】★
 ・「アーキテクトにはメリットが少なそう」
     → 【逆転しつつある】
       - 大規模なリファクタリング計画の立案
       - 既存コードベースの調査・要約
       - 設計案の複数生成と比較
       → コーディング・エージェントの登場により
         【設計・調査フェーズでの活用】が広がった
 ・「コマンドを使いこなすのは難しい」
     → 自然言語で足りるようになり、
       コマンドの重要性は下がった
 ・「IntelliSense 的な利用が最も意味がありそう」
     → 補完は今も価値があるが、
       主戦場は【Chat とエージェント】へ移った

【「銀行系システムでの安心感」について】★
   この指摘は的確で、実際に企業導入の焦点になった。
   現在の Copilot Business / Enterprise では
     ・【プロンプトと提案を学習に使わない】と明記
     ・保持期間の明示
     ・監査ログ（Enterprise）
     ・IP 補償（前述）
     ・【Copilot Enterprise は
       自社リポジトリを文脈にできる】★
   → 「不透明さ」への回答が制度面で整備された
   → ただし導入前に
     自組織の規程と突き合わせる必要がある点は変わらない

• [GithubCopilot]今より活用するためのtips / 裏側
  https://zenn.dev/airiswim/articles/624cc7ba04575d

• GitHub Copilot のセキュリティ・ライセンスに関する懸念の調査メモ
  https://zenn.dev/miyajan/scraps/3567cee380280c

• GitHub Universe Copilotのウラ側！コードが提案されるまでに何が起きている？ - Alternative Architecture DOJO
  https://aadojo.alterbooth.com/entry/2023/11/11/23540000

• Github Copilot のコード脆弱性管理の舞台裏 | HackerNoon
  https://hackernoon.com/ja/GitHub-%E3%81%AE%E3%82%B3%E3%83%BC%E3%83%89%E8%84%86%E5%BC%B1%E6%80%A7%E7%AE%A1%E7%90%86%E3%81%AE%E8%88%9E%E5%8F%B0%E8%A3%8F

• GitHub Copilot’s Security Filters Don’t Work
  https://codeium.com/blog/github-copilot-security-scanning-does-not-work

補足（最後のリンクの読み方）: 「Security Filters Don't Work」は
競合製品（Codeium）のブログであり、立場を踏まえて読む必要がある。
ただし主張の核（フィルタは万能ではなく、生成コードの脆弱性検査は
別途 SAST 等で行うべき）は妥当である。

【生成コードに対する現実的な守り】★
   ・【CodeQL / GitHub Advanced Security】… SAST
   ・【Dependabot】… 依存の脆弱性
   ・【Secret scanning + push protection】★
     → ハードコードされた資格情報の混入を防ぐ
   ・通常のコード レビュー
   → 「Copilot が安全なコードを出す」ことに依存せず、
     【パイプラインで検出する】設計にする

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