『Doing More with GitHub Copilot as a .NET Developer』の要点は、GitHub Copilotを「C#の補完ツール」として使うだけでなく、Chat、エージェント、CLI、クラウド上のコーディング支援まで含めて、.NET開発の作業単位で使い分けることです。すぐに既存コードの移行が必要になる種類の発表ではありませんが、チームで使う場合は、管理ポリシー、IDE設定、コンテンツ除外、レビュー手順を見直しておく価値があります。
Microsoft .NET Blogの公式記事は、ページ上では「May 26th, 2026」公開として表示されています。内容としては、Visual Studio、Visual Studio Code、Copilot CLI、cloud coding agentを.NET開発の場面ごとにどう使い分けるかを整理した実践ガイドです。(Microsoft for Developers)
GitHub Copilotの今回の要点は「どの機能を使うか」ではなく「どの作業を任せるか」
今回の公式情報で重要なのは、新しいボタンや単一機能の追加というより、GitHub Copilotの使い方の重心が広がっている点です。
従来のGitHub Copilotは、エディタ上でC#コードを補完するイメージが強いものでした。もちろん、LINQ式、DTO、Minimal APIのひな形、単体テストの補助など、インライン補完は今も有効です。ただし、公式記事では、より大きな効果が出るのは、Chatによる理解・設計支援や、エージェントによる範囲の決まった作業実行を組み合わせたときだと説明されています。(Microsoft for Developers)
つまり、.NET開発者が最初に考えるべきことは「Copilotのどの機能を試すか」ではありません。
「いま目の前にある作業のうち、どこをCopilotに任せると安全で効果が高いか」を決めることです。
たとえば、次のように使い分けると実務に落とし込みやすくなります。
| 作業 | 向いているCopilotの使い方 | 具体例 |
|---|---|---|
| 既存コードを理解したい | Chat | ASP.NET Coreのサービスクラスの責務、依存関係、ビジネスロジックを説明させる |
| テスト観点を増やしたい | ChatまたはTest Agent | xUnitの既存スタイルに合わせて境界値・異常系テストを生成する |
| ビルド失敗を切り分けたい | Copilot CLI | dotnet buildやdotnet testの出力をもとに原因候補と次のコマンドを整理する |
| 複数ファイルを安全に変更したい | Agent mode | コード修正、テスト更新、検証までを限定された範囲で進める |
| GitHub上でPR候補まで作りたい | Copilot cloud agent | Issueに紐づく小さな機能追加やテスト拡充をブランチ上で進める |
.NET開発者にとって何が変わるのか
今回の更新で押さえるべき変化は、GitHub Copilotを「入力中のコード補完」だけで評価しないことです。
公式記事では、Visual Studio、VS Code、Copilot CLI、cloud coding agentは、それぞれ異なる.NETタスクに向いていると説明されています。Visual Studioはソリューションの中に深く入り込んで作業する場面、VS Codeはコード・設定・ドキュメントをまたぐ変更、Copilot CLIはターミナル上のビルドやテストの切り分け、cloud coding agentはレビュー可能な範囲に絞った委任作業に向いています。(Microsoft for Developers)
インライン補完は「小さな繰り返し作業」に強い
インライン補完は、今後も日常的なC#開発で役立ちます。たとえば、似たようなプロパティのマッピング、DTOの追加、LINQの組み立て、単純なテストケースの雛形などです。
ただし、設計判断が必要な修正や、複数ファイルにまたがる変更をインライン補完だけで進めると、文脈不足で中途半端なコードが混ざりやすくなります。
インライン補完に向いているのは、次のような作業です。
- 既に方針が決まっている実装の続きを書く
- パターンが明確なコードを増やす
- 名前や型から意図が読み取りやすい短い処理を書く
- 生成後にすぐ目視確認できる小さな単位を補完する
逆に、設計の比較、影響範囲の洗い出し、テスト戦略の検討はChatやPlan Agentに回した方が安全です。
Chatは「理解・比較・計画・下書き」に向いている
Chatが力を発揮するのは、コードを書く前に考えるべき作業です。公式記事でも、Chatは説明、比較、計画、実プロジェクトに基づく対象限定のコード生成に有効だと説明されています。(Microsoft for Developers)
たとえば、レガシーなASP.NET Coreサービスを変更する前に、次のように依頼できます。
このサービスクラスの責務を説明してください。
主要な依存関係を整理し、ビジネスロジックとインフラ寄りの処理を分けてください。
挙動を変えずに最初に行うべき安全なリファクタリング案も提示してください。この聞き方は、いきなり「リファクタリングして」と依頼するより安全です。変更前にコードの責務、依存関係、テストすべき箇所を把握できるからです。
Agentic workflowsは「変更・検証・更新」まで任せる場面に向いている
公式記事では、Agentic workflowsは複数ステップで、範囲が限定され、レビュー可能なタスクに向くと説明されています。単に回答を得るのではなく、Copilotに作業の一部を実行させる使い方です。(Microsoft for Developers)
向いている例は、次のような作業です。
CreateOrderフローの不足している単体テストを追加してください。
バリデーション失敗、重複注文、支払いタイムアウトを対象にしてください。
既存のテストスタイルを維持し、公開API名は変更しないでください。
新しいテストが通るところまでで停止してください。このプロンプトが実務向きなのは、範囲、対象、変更してはいけないもの、完了条件が明確だからです。公式記事でも、スコープが明確で、影響範囲が限定され、完了条件があり、差分レビューしやすいタスクがエージェントに適しているとされています。(Microsoft for Developers)
ChatとAgentic workflowsの使い分け
GitHub Copilotをうまく使えない原因の多くは、Chatで十分な作業をAgentに任せたり、逆にAgentに任せるべき作業を曖昧なChatで済ませたりすることです。
公式記事では、理解・比較・概要作成・説明・下書きにはChat、変更・検証・更新・再実行・レビュー可能な成果物の作成にはAgentic workflowsを使う、という実践的な判断基準が示されています。(Microsoft for Developers)
| 判断基準 | Chatが向いている | Agentic workflowsが向いている |
|---|---|---|
| 目的 | 理解、比較、計画、説明 | 修正、検証、テスト更新、差分作成 |
| 成果物 | 方針、説明、サンプルコード | 変更済みファイル、テスト結果、PR候補 |
| リスク | 低め。人が内容を見てから適用する | 高め。実際にファイル変更が発生する |
| 指示の粒度 | 質問形式でもよい | 完了条件と禁止事項が必要 |
| レビュー方法 | 回答内容を読む | diff、テスト結果、ログを確認する |
実務では、次のように段階を分けると失敗しにくくなります。
- Chatで既存コードの責務と変更案を確認する
- Plan Agentで実装前の作業計画を作る
- Agent modeで限定範囲の修正を実行する
- テスト結果と差分を人間がレビューする
- 必要に応じて追加修正を依頼する
Visual Studioで確認すべきポイント
Visual Studioを使う.NET開発者は、Copilot Chat、Agent mode、Plan Agent、Test Agentの役割を分けて理解しておくと、日常業務に組み込みやすくなります。
Visual StudioのAgent modeは、自然言語で高レベルのタスクを指定すると、Copilotが手順を判断し、コード編集、ターミナルコマンド、ツール呼び出し、結果確認を繰り返す仕組みです。Ask modeと異なり、1回の回答で止まらず、目標に近づくまで反復できます。(Microsoft Learn)
ただし、Agent modeは自由に何でも実行してよい機能ではありません。Visual Studioのドキュメントでは、ターミナルコマンドや組み込みではないツールを実行する前に確認を求めること、ターミナルコマンドはVisual Studioプロセスと同じ権限を持つため慎重に確認すべきことが説明されています。(Microsoft Learn)
Plan Agentはコード変更前の合意形成に使う
Visual StudioのPlan Agentは、実装前に計画を作るための機能です。コードベースを読み取り専用ツールで調べ、必要に応じて確認質問を行い、レビュー可能な実装計画を作成します。Agent modeとは異なり、計画中にファイル編集や実装手順の実行は行いません。(Microsoft Learn)
大きめの機能追加、知らないコードベースの修正、チームレビューが必要な変更では、いきなりAgent modeに実装させるより、Plan Agentで方針を見える化した方が安全です。
使い方の例は次の通りです。
注文作成APIにキャンセル理由の記録を追加したいです。
既存のHTTP契約を壊さず、DB変更、サービス層、テスト、ドキュメント更新の影響範囲を調べて、実装計画を作ってください。
まだコードは変更しないでください。このように「まだコードは変更しない」と明示すると、設計レビューの材料として使いやすくなります。
Test Agentはテスト追加の入口として使う
Visual StudioのGitHub Copilot testing for .NETは、C#プロジェクト向けにテストを生成する機能です。公式ドキュメントでは、MSTest、NUnit、xUnitに対応し、既存ソリューションにNUnitまたはxUnitの単体テストがある場合は同じフレームワークで新しいテストを生成し、単体テストがない場合はMSTestを使用すると説明されています。(Microsoft Learn)
利用条件として、Visual Studio 2026 version 18.3以降、C#プロジェクト、GitHubアカウントでのサインイン、有料のGitHub Copilotサブスクリプションが必要です。Free Copilot subscriptionsはサポートされないと明記されています。(Microsoft Learn)
実務では、次のように使うと効果的です。
@Test generate tests for the pricing service.
既存のxUnitスタイルに合わせてください。
割引率0%、上限金額超過、null入力、地域別税率の境界値を含めてください。
FluentAssertionsを使っている既存テストがあれば同じ書き方にしてください。注意点は、生成されたテストを「正しい仕様」とみなさないことです。Copilotはテストコードを作れますが、業務仕様の正解を保証するわけではありません。特に、税率、料金計算、権限判定、金融・医療・法務に関わる処理では、仕様書や既存テストと突き合わせるレビューが必要です。
VS Code、Copilot CLI、cloud coding agentの使いどころ
Visual Studioだけでなく、作業の性質によってVS Code、Copilot CLI、cloud coding agentを使い分けると、GitHub Copilotの効果が出やすくなります。
VS Codeはコード・設定・ドキュメントをまたぐ変更に向いている
.NET開発でも、変更対象がC#だけとは限りません。APIハンドラー、OpenAPI定義、Bicep、GitHub Actions、README、運用ドキュメントを同時に見直す場面があります。
公式記事では、コードだけでなく、API、デプロイ設定、ドキュメントにまたがる作業ではVS Codeが向いている例として紹介されています。(Microsoft for Developers)
たとえば、次のような依頼です。
このエンドポイントに任意のregionフィルターを追加します。
ASP.NET Coreのハンドラー、OpenAPI定義、関連するクライアントコード、READMEの更新候補を整理してください。
実装前に影響範囲を一覧化し、変更すべきファイルを示してください。このような作業では、ソリューション内のC#だけでなく、周辺ファイルを含めて文脈を与えることが重要です。
Copilot CLIはビルド失敗やテスト失敗の切り分けに向いている
Copilot CLIは、ターミナルからCopilotを使うための機能です。公式ドキュメントでは、質問、コードの作成・デバッグ、GitHub.comとのやり取りに利用でき、プロジェクトへの変更やPull Request作成の依頼もできると説明されています。対応OSはLinux、macOS、WindowsではPowerShellまたはWSL内とされています。(GitHub Docs)
.NET開発で特に使いやすいのは、dotnet buildやdotnet testの失敗を見ながら原因を絞る場面です。
このdotnet testの失敗を平易に説明してください。
どのプロジェクトの変更が原因の可能性が高いかを示し、
次に実行すべきコマンドを2つだけ提案してください。ここで大事なのは、「直して」ではなく、まず「説明して、切り分けて、次のコマンドを絞って」と依頼することです。ビルドやテストの失敗は環境差分、依存パッケージ、テストデータ、並列実行など複数要因が絡むため、いきなり修正させるよりも原因候補を狭める方が安全です。
cloud coding agentはレビュー可能な作業を委任する場面に向いている
GitHub Copilot cloud agentは、GitHub上でリポジトリを調査し、実装計画を作成し、ブランチ上でコード変更を行い、必要に応じてPull Requestにつなげられる機能です。GitHub Docsでは、Copilot cloud agentは有料Copilotプランで利用でき、GitHubに保存されたリポジトリで利用可能ですが、managed user accountsが所有するリポジトリや明示的に無効化されたリポジトリは例外とされています。(GitHub Docs)
また、cloud agentはGitHub Actionsベースの一時的な開発環境でコードを調査し、変更、テスト、lintなどを実行できます。IDEのAgent modeがローカル環境で編集するのに対し、cloud agentはGitHub上で自律的に作業する点が異なります。(GitHub Docs)
任せやすい作業は、次のようなものです。
- 小さなバグ修正
- テストカバレッジの追加
- ドキュメント更新
- 技術的負債の小さな整理
- 既存Issueに基づく限定的な機能追加
反対に、認証基盤の大幅変更、課金ロジックの修正、データ移行を伴う変更などは、最初からcloud agentに丸投げしない方が安全です。Plan AgentやChatで影響範囲を確認し、人間の設計レビューを挟むべきです。
良いプロンプトに必要な4要素
公式記事では、.NET作業で有効なプロンプトには、目標、コードまたはコマンド出力、制約、期待する回答形式の4つを含めるとよいと説明されています。(Microsoft for Developers)
実務では、次の形をテンプレート化しておくと、チームで使い回しやすくなります。
| 要素 | 書く内容 | 悪い例 | 良い例 |
|---|---|---|---|
| 目標 | 何を達成したいか | 改善して | retry policyをテストしやすくしたい |
| 文脈 | 対象コード、エラー、仕様 | この辺 | BackgroundWorker、関連テスト、失敗ログ |
| 制約 | 変えてはいけないもの | いい感じに | 公開API、ログ形式、DI登録方法は維持 |
| 出力形式 | 何を返してほしいか | よろしく | 変更案、更新すべきテスト、リスクを表で出す |
たとえば、次のようなプロンプトは実務向きです。
このBackgroundWorkerのretry policyをテストしやすくリファクタリングしたいです。
公開されている挙動、structured logging、既存のDI登録方法は変えないでください。
まず変更方針を3案に分けて比較し、推奨案と追加すべきxUnitテストを示してください。
まだコードは変更しないでください。このプロンプトでは、目的、制約、出力形式が明確です。さらに「まだコードは変更しない」と書いているため、ChatやPlan Agentで安全に検討できます。
管理者が確認すべき設定とガバナンス
企業や開発チームでGitHub Copilotを展開する場合、開発者向けの使い方だけでなく、管理者側の設定確認が重要です。
GitHub Docsでは、Organization ownerは、ライセンスを付与されたユーザーに対してCopilotの機能やモデルの可用性を制御できます。また、Enterprise ownerが特定のポリシーを設定している場合、組織側ではその設定を上書きできない場合があります。(GitHub Docs)
Enterpriseでは、AI controlsからAgents、Copilot、MCPに関するポリシーを管理できることが説明されています。(GitHub Docs)
確認すべき主なポイントは次の通りです。
| 確認項目 | 管理者が見るべきこと | 放置した場合のリスク |
|---|---|---|
| ライセンス割り当て | 誰にCopilot seatを付与するか | 不要なコスト、必要な開発者が使えない |
| Feature policy | Chat、Agent、CLI、third-party agentsなどの許可範囲 | チームごとに使える機能が揺れる |
| Model policy | 利用できるモデル、追加コストが発生し得るモデル | 想定外の利用や費用管理の難化 |
| Editor preview features | Visual StudioのAgent mode利用可否 | 開発者の画面に機能が出ない、検証なしに使われる |
| Content exclusion | 機密ファイルや対象外コードの扱い | 除外対象が想定より広く参照される |
| MCP/toolsets | AIツールに許可する外部ツール範囲 | 過剰な権限、誤操作、不要なコンテキスト増加 |
| レビュー運用 | PRレビュー、ブランチ保護、テスト必須化 | AI生成コードが十分に検証されず入る |
Visual StudioのAgent modeについては、管理者がGitHub CopilotダッシュボードのEditor preview features flagで制御できるとMicrosoft Learnに記載されています。管理者がこの設定をオフにすると、そのサブスクリプション配下のユーザーはVisual StudioでAgent modeを使えません。(Microsoft Learn)
content exclusionは全機能をカバーすると考えない
管理者が特に注意すべきなのが、content exclusionの扱いです。
GitHub Docsでは、リポジトリ管理者、Organization owner、Enterprise ownerがcontent exclusion設定を管理できると説明されています。一方で、GitHub Copilot CLI、Copilot cloud agent、IDE内のCopilot ChatのAgent modeはcontent exclusionをサポートしないという注意書きもあります。(GitHub Docs)
これは、展開時に非常に重要です。
「content exclusionを設定したから、どのCopilot機能でも機密ファイルは参照されない」と考えるのは危険です。CLI、cloud agent、Agent modeを許可する場合は、content exclusionだけでなく、リポジトリ権限、ブランチ保護、レビュー必須化、secret scanning、MCPのtoolset制限などを組み合わせて管理する必要があります。
また、content exclusionの変更後は、IDE側で設定を読み込み直す必要があります。GitHub Docsでは、JetBrains IDEsとVisual Studioはアプリケーションの再起動、VS CodeはDeveloper: Reload Window、Vim/Neovimはファイルを開くたびに取得されると説明されています。(GitHub Docs)
公開コード一致の扱いも確認する
GitHub Copilotでは、公開コードと一致する提案の扱いもポリシーとして確認すべきです。
個人サブスクライバー向けのGitHub Docsでは、Suggestions matching public codeをAllowまたはBlockに設定できると説明されています。ただし、GitHub Enterprise Cloudの組織からCopilot seatを割り当てられている場合、個人設定ではなく組織またはEnterpriseの設定を継承する場合があります。(GitHub Docs)
また、Blockを選んだ場合、多くのGitHub Copilot製品では、提案コードとその周辺約150文字をGitHub上の公開コードと照合し、一致または近い一致がある場合は提案を表示しないと説明されています。(GitHub Docs)
企業利用では、次の方針を決めておくと運用しやすくなります。
- 公開コード一致をBlockするか、参照情報を見た上で利用判断するか
- ライセンス確認が必要なコードをどうレビューするか
- AI生成コードのPRに、担当者が確認すべきチェック項目を入れるか
- 監査やコンプライアンス上、どの設定を標準とするか
custom instructionsでチーム標準を明文化する
GitHub Copilotをチームに展開するときは、プロンプトだけで毎回ルールを伝えるのではなく、リポジトリ側にcustom instructionsを置くと一貫性を出しやすくなります。
Visual Studioのドキュメントでは、リポジトリルートに.github/copilot-instructions.mdを作成し、Visual Studio側で読み込みを有効化する方法が説明されています。また、.github/instructions/*.instructions.mdを使うと、ファイル種別やタスクに応じた複数の指示ファイルを用意できます。(Microsoft Learn)
.NETチームなら、たとえば次のような内容を入れておくと実用的です。
- C#のnullable warningsを増やさない
- ASP.NET CoreのDI登録は既存のProgram.csのスタイルに合わせる
- テストは既存のxUnit + FluentAssertionsの書き方に合わせる
- 公開APIのシグネチャを変更する場合は、必ず理由と影響範囲を説明する
- 例外を握りつぶさず、既存のstructured logging方針を維持する
- 生成したコードには不要な抽象化を追加しないcustom instructionsは、Copilotの出力を完全に制御するものではありません。しかし、チームの暗黙知を明文化し、レビュー時の基準をそろえる効果があります。
MCPやAgent Skillsを使う場合は権限を絞る
GitHub Copilotの活用が進むと、MCPやAgent Skillsを使って外部ツールや専門的な作業手順を組み込む場面も出てきます。
GitHub Docsでは、MCPはGitHub Copilotの機能を既存ツールやサービスと統合して拡張する仕組みだと説明されています。Copilot CLIはローカルおよびリモートMCP serverをサポートし、GitHub MCP serverは追加設定なしで利用可能です。また、Copilot cloud agentとCopilot code reviewでは、リポジトリレベルで構成されたMCP serverが適用されると説明されています。(GitHub Docs)
ただし、MCPは便利な反面、AIが使えるツールの範囲を広げます。GitHub Docsでも、GitHub MCP serverでは必要なtoolsetsだけを有効にすることで、性能とセキュリティの両面で利点があると説明されています。(GitHub Docs)
管理者は、最初から多くのツールを有効にするのではなく、次の順で展開すると安全です。
- 読み取り中心のツールから開始する
- 書き込みやPR作成を伴うツールは対象リポジトリを限定する
- 機密情報を扱うリポジトリでは別ポリシーにする
- 監査ログ、PRレビュー、ブランチ保護を組み合わせる
- 使われていないtoolsetsを定期的に無効化する
移行・展開で失敗しやすいポイント
今回の公式情報は、既存.NETアプリを移行しなければならない発表ではありません。とはいえ、チームとしてGitHub Copilotの利用範囲を広げるなら、展開方法を決めずに各開発者へ任せるだけでは失敗しやすくなります。
特に注意すべき失敗パターンは次の通りです。
| 失敗パターン | 起きやすい原因 | 対策 |
|---|---|---|
| Agentに大きすぎる変更を依頼する | 完了条件が曖昧 | 1Issue、1機能、1テスト対象など小さく切る |
| 生成コードをそのままマージする | レビュー基準がない | PRテンプレートにAI生成コード確認項目を追加する |
| テストが増えたのに品質が上がらない | 仕様ではなく実装に合わせたテストを生成している | 仕様、境界値、異常系を明示する |
| 開発者ごとに出力がばらつく | チーム標準がCopilotに伝わっていない | custom instructionsを整備する |
| 管理設定が想定と違う | Enterprise policyがOrganization policyを上書きしている | EnterpriseとOrganizationの設定を両方確認する |
| content exclusionを過信する | サポート対象外のCopilot機能を見落とす | CLI、cloud agent、Agent modeの扱いを別途確認する |
| Visual Studioで機能が出ない | バージョンやpreview設定が不足 | Visual Studioのバージョン、Copilot設定、管理ポリシーを確認する |
展開時は、全社一斉にAgent活用を始めるより、対象リポジトリとユースケースを絞ったパイロット運用が現実的です。
開発者が今日から試すなら、この順番が安全
個人または小規模チームで試すなら、最初から大規模なリファクタリングを任せる必要はありません。
おすすめは、次の順番です。
- 既存サービスの説明をChatに依頼する
- 変更前にPlan Agentで実装計画を作る
- Test AgentまたはChatで不足テストを追加する
dotnet testやdotnet buildの失敗をCopilot CLIで切り分ける- 範囲の狭いリファクタリングをAgent modeに依頼する
- 生成された差分を通常のPRと同じ基準でレビューする
最初の題材には、次のようなバックログが向いています。
- 仕様は変えずにテストを増やしたい処理
- 重複したguard clauseを整理したい小さな範囲
- ログ出力の形式を既存方針に合わせたいハンドラー群
- READMEと設定例を実装に合わせて更新したい作業
- 失敗している特定プロジェクトのテスト修正
反対に、最初の題材として避けたいのは、認証、認可、課金、データ移行、暗号化、外部連携の本番影響が大きい変更です。これらはCopilotを使ってよい領域ではありますが、先に設計レビュー、テスト戦略、ロールバック手順を固めるべきです。
管理者が次にやるべきチェックリスト
GitHub Copilotを.NET開発チームでより深く使うなら、管理者は次の項目を確認しておくと展開がスムーズです。
- Copilot seatの付与対象が現在の開発体制と合っているか
- Enterprise policyとOrganization policyの優先関係を確認したか
- Agent、CLI、third-party agents、MCPの許可範囲を決めたか
- Visual StudioのAgent modeを許可するかどうかを決めたか
- content exclusionの対象と限界を開発者に共有したか
- 公開コード一致の扱いを標準化したか
.github/copilot-instructions.mdでチーム標準を明文化したか- AI生成コードのPRレビュー基準を用意したか
- テスト、lint、セキュリティスキャンを必須チェックにしているか
- パイロット運用の対象リポジトリと評価指標を決めたか
評価指標は、単純な「Copilotを何回使ったか」だけでは不十分です。実務では、レビュー差し戻し率、テスト追加数、ビルド失敗の解消時間、Issue消化速度、生成コードに起因する不具合の有無などを合わせて見る方が、導入効果を判断しやすくなります。
まとめ：GitHub Copilotは.NET開発の「作業分解」とセットで使う
今回の公式情報から読み取れる最大のポイントは、GitHub Copilotを単なるコード補完ではなく、.NET開発の作業フローに組み込むことです。
Chatは理解、比較、計画に使う。Plan Agentは実装前の合意形成に使う。Agent modeは範囲の決まった変更と検証に使う。Copilot CLIはターミナル上のビルド・テスト切り分けに使う。cloud coding agentは、レビュー可能な単位に切った作業をGitHub上で進めるために使う。
開発者は、まず自分のバックログから「小さく、完了条件が明確で、差分レビューしやすい作業」を1つ選ぶことが第一歩です。管理者は、機能を有効化する前に、ポリシー、content exclusion、公開コード一致、MCP、レビュー運用を確認してください。
GitHub Copilotを安全に活用できるチームは、AIに丸投げするチームではありません。任せる作業を小さく切り、制約を明示し、テストとレビューで受け止めるチームです。
コメント