事前質問の回答⼀覧 

Q A Q A agentsとskillsの使い分けやhooksの効果的な使い⽅ Agents = 「どういう役割で動くか」を決める Skills = 「特定作業をどううまくやるか」を覚えさせる Hooks = 「実⾏の節⽬で何を⾃動実⾏するか」を決める instructionsや、prompts、skills、hooksなどAIの動きをカスタマイズするディレクトリが いくつかありますが、この使い分けについてベスプラがあればお聞かせ願いたいです。 「常時効かせるもの」「必要な時だけ呼ぶもの」「⾃動で実⾏するもの」に分けるのがGood ● ⼀番実務的な使い分け ○ instructions: ほぼ毎回必要な短いルール ○ prompts / prompt files: ⼈が明⽰的に呼ぶ定型タスク ○ skills: 特定の場⾯でだけ必要な、⻑めの⼿順や補助スクリプト ○ hooks: 実⾏の節⽬で⾃動で⾛らせる検証やポリシー 

Skillsの有効的な活⽤⽅法や確度の⾼いレビュー、Planモードの使い⽅をしりたいです Skillsの有効的な活⽤⽅法 ● Skillsは、Copilotに特定の作業を毎回同じ品質でやらせるための再利⽤可能な作業⼿順です。 ● GitHub公式では、Skillsを「instructions‧scripts‧resources をまとめたフォルダ」で、Copilotが関連性 があるときに読み込んで specialized tasks の性能を上げる仕組み ● Skillsが特に効くのは、以下のような繰り返し発⽣する作業です。 ○ Issueから実装⽅針を決める ○ PRレビュー観点を固定する ○ テスト追加の観点を揃える ○ React/Next.js/Azure/Terraform など、技術ごとのお作法を毎回守らせる ○ ⾃社の開発ルールや命名規約を反映させる 確度の⾼いレビュー ● Copilot CLIでは /review を使って、CLI上でコード変更をレビューできます。GitHub公式でも、/review は コミット前に素早くフィードバックを得る⽤途として案内されていて、必要に応じて対象のパスやファイ ルパターンでスコープを絞れます ● /review + プロンプトで指⽰の具体化することが重要 ● /planで設計確認をして、/reviewで確認することに加え、Skillでreview-skillに各プロジェクトで必要な要 件を記載しておくとよりGood Q A 

Q A Skillsの有効的な活⽤⽅法や確度の⾼いレビュー、Planモードの使い⽅を知りたいです Planモードの使い⽅ ● Plan mode はコードを書く前に構造化された実装計画を作るモードです。Shift + Tab で切り替えでき、 通常モードでも /plan コマンドで同じ流れを使えます。 Copilotは要求を分析し、必要なら確認質問をして、チェックボックス付きの計画を作り、plan.md に保存 してから、承認後に実装へ進みます。 ● Plan modeを使うべきなのは、こんな場⾯です。 ○ 新機能追加 ○ 複数ファイルにまたがる変更 ○ リファクタ ○ 既存仕様を壊したくない変更 

Q A エージェントモードの効果的な利⽤⽅法を教えてほしい 通常のChatや補完は「その場の1問1答」や「局所的な修正」に強いですが、 エージェントモードは“タスク完了”まで持っていくのが強み ● 新機能追加 ● 複数ファイルにまたがる修正 ● 既存コードを読みながらのリファクタ ● テスト追加 ● lint / compile error の修正込みの変更 以下を明確に ● 何を作るのか ● どこまでやるのか ● 何はやらないのか ● どう検証するのか 

Q A エージェントモードの⼤規模開発への活⽤事例を教えてほしい ⼤規模開発では、いきなり書かせるより、設計→確認→実装の順の⽅が安定。よくある失敗はタスクが広すぎること。 ● 例えば、「認証基盤を全部刷新して」よりも、以下のように限定して⾏う ○ middleware 対応 ○ APIガード追加 ○ フロント画⾯の制御 ○ テスト整備 ● Skills や agentss.md で“流儀”を覚えさせるのも重要。GitHub Blog では agents.md を整備すると、リポジトリご との開発ルールや期待値を agent に伝えやすくなるとしています。 ● たとえば⼤規模開発なら、次のような内容を持たせるのが有効です。 ○ 変更前に読むべきファイル ○ 禁⽌事項 ○ テストの最低基準 ○ PR本⽂の形式 ○ レビュー観点 ○ ディレクトリごとの責務 ● “完全⾃動”ではなく、⼈のレビューを前提にする ○ agent mode で実装 ○ /review で確認 ○ ⼈間が最終レビュー ○ 必要なら再修正 

Q A 既存の⼤規模‧レガシーコードに対してCopilotを使う際、 意図しない実装や設計ブレを防ぐために⾏っている⼯夫や判断基準があれば知りたいです。 ● ⼤規模‧レガシーコードでは、Copilotに最初から実装させるのではなく、まず構造理解と制約整理をさせ ます。 ○ その上で「何を変えてよくて、何を変えてはいけないか」を明⽰し、最後は必ずテストとコードレ ビューで閉じる、という運⽤にしています。 ● GitHub公式でも、レガシーや深い業務知識を要する変更、⼤きな設計変更は慎重に扱うべきとされていま す。 Q A 修正コードの提案の質を上げる⼯夫 ● 修正コードの提案品質を上げるなら、いちばん効くのは 「曖昧に直させないこと」 です。 ○ GitHub の公式ベストプラクティスでも、複雑なタスクは分解する、要件を具体的に書く、⼊出⼒や 実装例を与えることが推奨 ○ https://docs.github.com/en/copilot/get-started/best-practices 

Q A エンタープライズですでに開発基盤がある環境で、基盤のコンテキストをどのように渡すべきか ● GitHub公式でも、常に効くルールは custom instructions、詳細で特定タスク向けは skills、実⾏タイミン グの⾃動検証は hooks、外部システムや動的情報は MCPといった具合に “常時必要” は instructions、 “たまに必要で⻑い” は skills、hooksは説明ではなく機械的に判定出来るもの がGood ○ lint ○ unit test ○ typecheck ○ secrets check ○ policy check ○ IaC validation ● ⼀番よくない渡し⽅は巨⼤なmarkdownに全部記載すること。 ● 基盤知識は原則と運⽤情報に分けて短く記載。また、禁⽌事項は明確に。docsだけではなく、hooksへ検 証コマンドを記載し、タスク毎の専⾨性はskillへ逃がす 

Q A 企業向けのデータが外部に漏れない契約プランがあるか ● はい。企業向けには GitHub Copilot Business / Enterprise があり、これらのプランでは顧客データはモデ ル学習に使われず、GitHub Data Protection Agreement の対象になります。 ● ただし、完全性はプランだけでなく、content exclusion や機能制御などの契約⾯: Copilot Business か Enterprise を使う ○ 法務⾯: DPA の適⽤範囲を確認する ○ 設定⾯: content exclusion を設定する ○ 運⽤⾯: cloud agent や外部連携を使ってよい repo を分ける運⽤設定も含めて担保する必要があり ます。 

Q A プレリクが上限に達した時の追加予算の妥当性について指針があれば知りたい (使ってない⼈も⼤勢いる中で⾜りない⼈は 1/5程度) ⅕ では全体に追加予算は適切ではない。 ● 企業オーナーは特定のユーザーをアップグレードし、プレミアムリクエストの基本許容範囲を増やすこと ができます。 ● ⽉に800件以上のプレミアムリクエストを⾏うCopilot Businessユーザーは、Copilot Enterpriseライセンス でコスト削減が可能です。 ● https://docs.github.com/en/copilot/how-tos/manage-and-track-spending/manage-request-allowances 

Q A GitHub Copilot CLIの使⽤事例について。従来のChatで指⽰するのと何が優れていると考えるか？ ● GitHub Copilot CLIの強みは、単に⾃然⾔語で相談できることではなく、ターミナル上でそのまま計画‧実 装‧レビューまで進められることだと思っています。 ● 通常のChatは相談や発想整理には向いていますが、CLIは作業ディレクトリの⽂脈を持ったまま、ファイル 編集やコマンド実⾏、差分レビューまでつなげられるので、開発フローに直接効きます。 ● 特に /plan で⽅針を作って、そのまま実装‧テスト‧/review まで進められる点は、従来のChatより実務 に乗せやすいです。 Q A Cloud AgentをWebで実⾏するのとCLIで実⾏するのは何が違うのか ● Cloud Agent は GitHub 上で⾮同期に動く、CLI は⼿元のターミナルで対話しながら動く、この違いです。 ○ GitHub 公式でも、Cloud Agent は「GitHub 上で repository を調査し、計画し、ブランチ上でコー ド変更し、必要なら PR を作る」⾃律エージェント、CLI は「ターミナルから直接使う terminal-native な AI coding assistant」と説明されています。 

Q A ● IDEプラグインは「書きながら使う」ためのもの、CLIは「流れを進める」ためのものです。GitHub Copilot は VS Code や JetBrains 系 IDE でインライン補完‧Chat‧修正提案が使え、CLI では Plan / Review / terminal ベースの作業⽀援がしやすい ● IDEプラグイン向き ○ コードを読みながら理解したい ○ その場で補完してほしい ○ ファイルをまたいで修正したい ○ エディタ上で差分を⾒ながら直したい ● CLI向き ○ 実装計画を⽴てたい ○ terminal中⼼で作業したい ○ Git 操作、レビュー、テスト、PR準備まで流れで進めたい vscode、IntlliJ等のIDEのプラグインとCLIの使い分け 

Q A Q A Q A エンジニアではないですが、バイブコーディングでプロトタイプや業務アプリの開発にトライしようとして Github Copilotを導⼊し、チャットベースの開発でちょっとしたプラグインが作れるようになってきました。 次にチームとして知⾒を共有していきたいのですが、Code Spacesなどが役⽴ちそうで気になっています。 是非GitHub Copilot CLIをローカルで構築して、ご自身の環境を構築して今後の開発ライフに活かしてください！ これだけは使える、おすすめが知りたい ● GitHub Copilot CLIはなかなか良いです。 ● エンジニアだけでなく、ビジネス職の⽅にも使っていただけるもの。後、/fleetが並列処理を⾃動で実⾏し てくれるので⾯⽩い ACP（IDE連携の標準）でできることは今後増えますか？予定などあれば知りたいです！ ● 増える可能性は⾼いです。 ○ ただし、現時点で公開情報からは、細かい機能追加の確定ロードマップが明⽰されているわけではあ りません。⼀⽅で、公式サイトには “Full support for remote agents is a work in progress” とあり、 クラウドホストや別インフラ上のリモートエージェント対応は、まさに拡張中とされています。 

Q A GitHub Copilotの特異点 ● GitHub Copilot は、Issue から PR 作成、PR 上での修正依頼、コードレビューまでを GitHub の流れの中で扱いやすいです ● GitHub Copilot には、custom instructions、prompt files、skills、hooks、custom agents、MCP など、 チームや組織で振る舞いを揃えるための仕組みがまとまっていて、組織で使うという点では⾮常に良い ● PRレビュー運⽤との相性がかなり良い。 Copilot は コードレビュー機能が GitHub のPR運⽤に直接つながっている ● GitHub Copilot も MCP による外部システム連携を公式にサポートしています。 

Q A 他のAIツールと⽐較していい点悪い点を聞きたいです ● 「どのAIが⼀番優れているか」ではなく、どの運⽤に⼀番合うかで⾒るのが実務的です。 ● GitHub Copilot を軸に、よく⽐較対象になりやすい Cursor / Claude Code / Codex と⽐較 ○ GitHub Copilot は、GitHub上の開発フローと⾃然につながるのが最⼤の強みです。 ○ 公式ドキュメント上でも、Copilot docs の中に skills、hooks、custom agents、MCP、policy conflicts、allowlist、enterprise administration がまとまっていて、単なる補完機能ではなく、組 織運⽤前提で設計されていることが分かります。ガバナンス‧標準化はしやすい。 ● GitHub Copilot は機能が豊富なぶん、instructions / agents / skills / hooks / MCP とレイヤーが多く、ちゃ んと設計しないと効果が薄くなります。 ○ これは裏返すと強みですが、導⼊初期のハードルでもあります。 ○ GitHub Docs でも customization 領域がかなり広く、運⽤設計前提の製品であることが読み取れま す。 ● 「とりあえず⼊れたらすぐ強い」という体験は、CursorやClaude Codeの⽅が出やすいケースがありま す。 ○ これは各社の公式情報でも、Cursor は agent best practices と IDE 体験、Claude Code は terminal 中⼼の実⾏体験を前⾯に出している 

Q A GitHub Copilot活⽤アンチパターン ● GitHub Copilot活⽤のアンチパターンは、だいたい次の4つです。 ○ 丸投げする ○ ⽂脈を渡さない ○ 検証しない ○ チーム標準にしない ● この4つを避けるだけで、活⽤品質はかなり上がります。これは GitHub の best practices、CLI best practices、agent best practices の共通メッセージでもあります。 

Q A Q A Q A Copilot Chatを含め、「⼈が考えるべき部分」と「Copilotに任せる部分」をどのように切り分 けているか、実務の例を交えて教えていただきたいです ● 「正解を決めるのは⼈、候補を速く出すのはCopilot」 と考えると整理しやすいです。 ○ GitHub公式でも、複雑で広いスコープ、深いドメイン知識、設計整合性が重要な変更は⼈が中⼼で 扱うべきとされています。 ● 逆に、説明、要約、テスト⽣成、レビュー補助、ドキュメント更新などはCopilotがかなり得意です。 今後のCopilotは、開発者の役割をどう変えていくと考えていますか ● 今後のCopilotは、開発者を“コードを書く⼈”から、“AIを前提に設計‧委任‧検証する⼈”へ変えていくと 思います。 ● 実装そのものの価値がゼロになるわけではないですが、より重要になるのは、何を任せ、何を⼈が握り、 どう品質を担保するかです 「Copilotを使いこなせるエンジニア」と「そうでないエンジニア」の差は、今後どこに出ると思 いますか？ ● 差が出るのは、プロンプトの⼩⼿先というより、タスクの切り⽅、必要な⽂脈の渡し⽅、出⼒の検証、そ して“ここは任せない”という判断です。 ● Copilotを使いこなせる⼈ほど、AIを雑に使うのではなく、むしろ厳密に使っています 

Q A オプトアウトやプライバシー管理の徹底について、またプロンプトはパターン化して使っている のか。 ● まず⼤前提として、Copilot Business / Enterprise の顧客データは、GitHub による AI モデル学習には使わ れません。 ○ GitHub の公式ドキュメントでは、個⼈向けプランは設定で学習利⽤をオプトアウトできますが、 Business / Enterprise は Data Protection Agreement により、顧客許可なしで学習利⽤されないと 明記されています。 ○ さらに OpenAI モデルについては、GitHub は OpenAI と zero data retention agreement を維持し ていると案内しています。 ● パターン化した⽅がいいです。 ○ GitHub 公式でも、良い結果を得るには 複雑なタスクを分解する、要件を具体的にする、⼊⼒例‧ 出⼒例を与えるといった prompt best practices が勧められています。 これはつまり、毎回ゼロから聞くより、型を持って使う⽅が安定するということです。 ○ https://docs.github.com/en/copilot/get-started/best-practices 

Q A ⽣成AIのお陰で⾮エンジニアもVibe codingできる時代となりました。 要件やアーキテクチャさえ定義できれば、コードを丸々⽣成してプロダクトを作れますが、ビズ側にいた⼈間が GitHub Copilotを使ってPoCのソリューションを作ったり、セキュリティレビューを通して本番リリースするの に、どの技術をどのくらいベースとしてしっておくべき、のよう⽬安のようなものはありますでしょうか。 技術領域が広く、何も⼿付かずのままとにかく⽣成AIで業務を前に進める、という怖さがあります。 ● 個⼈的な意⾒ですが、1stリリースから完璧なものを作るのではなく、3rdUpdateぐらいで完成させる意識 がいいのかなと思います。 ● まずは動くものを、次は現場のセキュリティレビューを通るように、最後に皆様に使っていただいて、 Updateしていくというふうに実装していき、必要知識を都度キャッチアップすれば良いかなと思います。 ● ⽇々の勉強は⾮常に⼤事 Q A 独学なので、プロが使っているノウハウを吸収したい。 プロのノウハウは、うまいコード⽣成ではなく、うまい制約のかけ⽅‧切り分け⽅‧レビューの仕⽅です。 

Q A 私は個⼈的にGitHub Copilotを活⽤しており、MCPツールを使って特殊な処理(例:ネットワーク機器の設定)を実 ⾏してもらい、状況把握‧設定変更を実施してもらう使い⽅をしています。 業務になると、どこまでAIにやらせていいのか、という線引きも難しくなってくると思いますが、 そういった制約がある中でGitHub Copilot+MCPツールをどのように活⽤されているかを聞いてみたいです。 ● 個⼈的には、業務で GitHub Copilot + MCP を使う場合、まずは「読ませる‧探させる‧整理させる」とこ ろから始めるのが現実的だと思っています。 ● いきなり本番変更まで任せるのではなく、現状把握、影響範囲の整理、変更案の⽣成、⼿順の下書きまで は AI に寄せて、実⾏は⼈の承認を挟む形です。 ● 公開情報ベースで Microsoft系だと、Work IQはM365データの横断取得に強く、MCAPS-IQはMSX/CRM系 の業務⽂脈に直結しやすいです。加えて、Learn MCPは技術参照、Azure MCPは Azure運⽤に相性がよいで す。 ● なので、MCPは「何でも⾃動化する道具」というより、「必要な業務コンテキストを安全にAIへ渡す道 具」として使うのが⼀番価値が出ると思っています。