質問の回答⼀覧 

Q A コード解析（既存コードの仕様理解や不具合調査）を⾏う際に、GitHub Copilot のトー クン消費を抑えるコツや⼿法があれば教えてください。 コツは「コンテキストを絞ること」です。 ● ① 関連するファイル/関数だけを明⽰的に指定し、リポジトリ全体を⼀度に読ませない ● ② まずコードベースで該当箇所を特定→そこだけ深掘り、と段階的に進める ● ③ instructionsファイルにプロジェクト概要‧構成を書いておき、毎回ゼロから探索させない ● ④ 調査は⾼速‧低コストモデル(Auto/軽量モデル)で⾏い、複雑な推論が要る時だけ上位モデルに切替 ● ⑤ 1セッションの会話を⻑くしすぎない（不要な履歴がトークンを消費） ○ 新しいタスクは新セッションで。 Q A ボイスモードとテキストでtoken消費量は？変わりますかね？ 変わりません。 Copilot CLIのボイス⼊⼒は⾳声をローカルで⽂字起こしして、そのテキストをモデルに送る仕組みなの で、LLMの token消費は「最終的に送られた⽂字数」に依存します。 つまり、同じ内容ならボイスでもテキストでもtoken消費はほぼ同じです（差が出るとすれば⽂字起こし 結果の⻑ さ‧⾔い回しの違い分だけ）。 

Q A プレミアムリクエスト数単位の制限からトークン消費単位になったことでどう⼯夫した らいいですか？ 基本は「使うトークン量を意識した運⽤」に尽きます。 ● ① Autoや軽量モデルを既定にし、難しい場⾯だけ上位モデルへ切替 ● ② コンテキストを最⼩化（不要なファイル/⻑い履歴を渡さない、タスクごとに新セッション） ● ③ ⼀発で精度⾼く出すためのプロンプト‧instructions整備で、やり直し(再⽣成)を減らす ● ④ ⼤きな作業は分割し、無駄な全体読み込みを避ける ○ 消費の中⾝が「リクエスト数」から「実際の計算量(トークン)」に近づいたので、“短く‧的確に‧適 切なモデルで”が効率化の軸になります Q A 最近のレートリミット計算⽅式変更による、上限への到達しやすさについてどう変わったか。 考え⽅として、上限は実際の計算量(トークン消費)をより反映する⽅向に変わっており、重いモデルや⻑いコンテキ ストを多⽤すると相対的に到達が早くなり、軽い使い⽅なら余裕が出ます。 対策は前問と同様で、Auto/軽量モデルの活⽤、コンテキスト最⼩化、再⽣成を減らすプロンプト整備が有効です。 具体的な係数‧上限値は変動するため、Docsと管理画⾯の使⽤状況(/usage)で実値を確認しながら運⽤するのが確 実です。 

Q A modelをAutoで選択するようにしたとき、VSCodeから使う時とCLIで使う時モデルの選択され⽅ に違いはありますか？ はい、違いがあります。 6⽉から順次「タスク最適化付きAuto mode」を提供開始しておりますが、インターフェイスごとにスケジュール のずれがでております。 VS CodeとGitHub websiteでは「タスク最適化付きAuto mode」が使われ、タスクの複雑さを評価して最適なモ デルを選びます。 単純なタスクは⾼速‧低コストなモデルに、複雑な問題は推論モデルに振り分けます。 CLIでは「信頼性‧可⽤性最適化Auto」が使われ、リアルタイムのシステム状態を⾒て安定して使えるモデルを選 びます。 

Q A 各IDEのプラグイン事に、instruction、prompt、MCPの設定の置き場所が違ってややこしい。 どう、解決するのか？ 「リポジトリの.github配下に集約」が基本戦略です。 ● ① instructionsは .github/copilot-instructions.md がVS Code/JetBrains/Visual Studio等で共通参照される 標準。リポジトリにコミットすればIDE横断で効きます。 ● ② ファイル別ルールは .github/instructions/*.instructions.md（frontmatterのapplyToで対象指定）。 ● ③ promptファイルは .github/prompts/*.prompt.md。これらはリポジトリ管理で共有可能。 ● ④ MCPだけはIDE固有設定（VS Codeは .vscode/mcp.json、CLIは ~/.copilot 配下 等）。 結論：共有したいものは.githubに集約し、IDE固有のものだけ各IDEで設定、という2層に分けると整理できます。 Q A VSCodeアップデートがある度にSkillを読まないことがある。 Skillの書き⽅で⼀番最新のベストプラクティスを教えてください。 また、Copilot Agentに⼤規模 なプロジェクト構成を理解させるベストプラクティスはありますか。 ● ① 1ファイルに詰め込みすぎず⽬的別に分割し、frontmatterのapplyToで対象を絞る ● ② 命令は具体的‧簡潔に、箇条書きで。曖昧表現を避ける ● ③「何を‧なぜ‧どう」を明⽰ ● ④ 最新形式は .github/instructions/ + applyTo 読まれない時はパス/frontmatterの記述ミス、ワークスペース直下に置かれているかを確認。 ⼤規模プロジェクト理解：copilot-instructionsにアーキ概要‧ディレクトリ構成‧主要モジュールの責務を記載 ∕README‧docsを充実させ参照させる∕コードベース検索を活⽤∕⼤きなタスクは分割して与える、が効果的 

カスタムエージェント/スキルファイルの管理‧適⽤⽅法が⾊々あって困っています。 VS Codeだとマルチルートワークスペースによる複数リポジトリへの横断が便利だが、Copilot CLIだと.copilotに格納しないといけない等。よい管理⽅法があれば教えてください 【結論】複数リポジトリ横断‧組織標準として配りたいカスタムエージェント/スキルは、Enterprise plugin standards に従い、enterprise の `.github-private` リポジトリで「プラグイン」として配布‧管理するのが推奨 です（現在パブリックプレビュー）。 ■ 推奨：Enterprise plugin standards（組織横断の標準化） ● enterprise の `.github-private` リポジトリ内 `copilot/managed-settings.json`（旧 `.github/copilot/settings.json` も可）で、利⽤可能なマーケットプレイスと⾃動インストールする プラグインを⼀元定義 ○ 主な設定項⽬：extraKnownMarketplaces（追加マーケットプレイス） ∕strictKnownMarketplaces（許可するマーケットプレイスを限定）∕enabledPlugins（全 社員へ⾃動インストール: 例 "PLUGIN-NAME@MARKETPLACE-NAME": true） ● 適⽤範囲：enterprise の Copilot プラン利⽤者全員。Copilot CLI / Copilot cloud agent / VS Code(1.122以降) に横断適⽤。ユーザーが認証したタイミングでポリシーが反映 ○ 利点：クライアント間で同⼀プラグインを保証、設定を1ファイルで集中管理、Gitなので変 更履歴‧PRレビュー可、新メンバーは認証だけで標準プラグインを⾃動取得 ● カスタムエージェント(`agents/*.agent.md`)‧スキル(`skills//SKILL.md`) ‧hooks‧MCP/LSP 設定を `plugin.json` を持つ「プラグイン」にまとめ、マーケットプレイス(リ ポジトリ)経由で配布します Q A 

カスタムエージェント/スキルファイルの管理‧適⽤⽅法が⾊々あって困っています。VS Codeだ とマルチルートワークスペースによる複数リポジトリへの横断が便利だが、Copilot CLIだ と.copilotに格納しないといけない等。よい管理⽅法があれば教えてください ■ 補⾜：管理の層構造（どこに置くか） ● (a) リポジトリ固有：各リポジトリの `.github/copilot/settings.json`（そのリポジトリでのみ有 効。cloud agent もこれを参照）。 ● (b) 個⼈共通（CLI）：`~/.copilot/settings.json` の enabledPlugins、またはローカルの `~/.copilot` 配下。⾃分の全プロジェクトで共通利⽤。 ● (c) 組織標準：上記 Enterprise plugin standards（`.github-private`）。← 横断‧標準化はこれが 正攻法。 ■ VS Code と Copilot CLI の置き場所の違い ● VS Code：マルチルートワークスペースで複数リポジトリを横断でき、Agent plugins(1.122以降)で Enterprise plugin standards も反映 ● Copilot CLI：プラグイン/設定は `~/.copilot`(ユーザー単位) または各リポジトリの `.github/copilot/settings.json`(リポジトリ単位) に配置 ○ `copilot plugin install` / `/plugin install` でも導⼊可 ● どちらのクライアントでも、組織横断で揃えたいものは「ローカルに個別配置」ではなく `.github-private` のプラグイン標準に寄せると、置き場所の差を意識せず統⼀できます Q A 

カスタムエージェント/スキルファイルの管理‧適⽤⽅法が⾊々あって困っています。VS Codeだ とマルチルートワークスペースによる複数リポジトリへの横断が便利だが、Copilot CLIだ と.copilotに格納しないといけない等。よい管理⽅法があれば教えてください ■ 使い分けのまとめ ● 1リポジトリだけ → そのリポジトリの `.github` ● ⾃分の全作業で使う → `~/.copilot`(CLI) ● チーム/全社で標準化‧横断 → Enterprise plugin standards（`.github-private` の `copilot/managed-settings.json`） ● 参考: https://docs.github.com/en/copilot/concepts/agents/about-enterprise-plugin-standards Q A 

GitHub Copilotは複数のIDEで利⽤可能なのが売り。私の環境でも業務に応じて複数のIDE上で利 ⽤されている。この時、Visual StudioやPHP Storm など ⾮VSCodeとVSCodeの機能や情報の 差異が推進の運⽤コストを上げている。例えばAICを確認する⽅法がVSCode ではエージェントデ バッグログがあるが、VisualStudioではエージェントデバッグログが無い。この場合代替⼿段を 探すか、場合によっては独⾃実装する必要がある。このような状況はしばしば多く起こりうる。 GitHub 公式ドキュメントに差異は表⾯的には記載されているものの、実活⽤をする場合には情 報が⾜りず実際に触って調査しなければ分からないことが殆ど。 この時、各IDEで調査するコストが⾼く困っている。何か良い解決⽅法のアイデアがあれば 運⽤コストを下げる現実解として、 ● ① 主要IDE(例:VS Code)を“リファレンス環境”と決めてそこで検証し、他IDEは差分のみ確認する ● ② GitHub Copilot CLIはIDE横断でご利⽤いただける、且つ、最も機能リッチなインターフェイスになる ので活⽤ご検討ください。 Q A 

Rubber-duckはCLIだけとのことですが、他の機能でもCLI限定のものが多く、今後の新機能は、 Copilot CLIにしか提供されないのでしょうか？Copilot Chatには新機能は今後あまり提供されな いのでしょうか。 CLIは新しい/実験的な機能の先⾏提供先になりやすいですが、Chat(VS Code等)が軽視されるわけではありませ ん。 各サーフェスの強みに合わせて展開され、有⽤な機能は順次他サーフェスにも広がる⽅針です。 Chatは対話‧IDE統合に、CLIは⾃動化‧エージェント的ワークフローに強みがあります。 ⽤途で使い分けるのが基本で、どちらも継続的に強化されます。 Q A CLIでしか提供されない機能と、chatでしか使えないもの(vscodeのaskQuestion等)があり、 困っています。 今後、⻑期的にはchatからCLI or App Canvasに切り替えた⽅がいいのでしょうか ⼀本化する必要はなく、併⽤が現実的です。 ● 対話的にコードを書く/IDEの⽂脈が重要 → Chat ● ⾃動化‧スクリプト的‧エージェントで⼀気通貫 → CLI GitHubの開発リソースがCLIに集中しているのは事実ですが、現時点ではCLIの開発が先⾏している状況となります Q A 

github copilot code reviewのレベルで、lowとmediumの使い分け基準などありますか？ レビューの「深さ/積極性」の調整です。 ● Low=重要度の⾼い明確な問題(バグ‧セキュリティ等)に絞り、ノイズが少ない ● Medium=設計‧可読性なども含め広く指摘 使い分け： ● PR量が多い/誤検知を避けたい→Low ● 重要モジュールでじっくり品質を上げたい→Medium まずLowで運⽤を始め、物⾜りなければMediumに上げる、というのが実⽤的です。 Q A Code Reviewと CLIの /reviewのレビュー内容の違いや推奨の使い分けを教えてもらえますか。 GitHub上の動作と、ローカルでの動作という動作環境の違いやそれによる使い分けはわかるの で、その他について教えてもらえるとうれしいです 動作環境以外の主な違いは「役割とタイミング」です。GitHub上のCode Review(PR)はPR全体の差分を対象に、 チームのレビューフローに組み込まれ、コメントとして記録される“⾮同期‧共同作業向け”。CLIの /review は ローカルの作業中/未コミット変更を即座に対話的にチェックする“コミット前のセルフ品質ゲート向け”。 推奨の使い分け： ● コミット前の⼿元チェック=CLI /review ● 提出後のチーム可視レビュー=GitHub Code Review 両者は補完関係で、併⽤すると⼿戻りが減ります。 私はマルチモデルでレビューできる/reviewを好んで使っています。 Q A 

インフラエンジニアが、GItHub Copilot を使っていたりしますでしょうか？コード開発よりか は、Agent Skillを使いないながらスイッチのコンフィグとか⽣成AIを通して検査が出来ないかと ちょうど動き始めたところです。。 はい、インフラ/ネットワーク領域でも活⽤が広がっています。コード開発以外でも、以下が可能です。 ● ① 設定ファイル(YAML/JSON/各種config)のレビュー‧差分チェック‧命名/ポリシー検査 ● ② スイッチconfigの社内標準/ベストプラクティス照合やtypo検出（ルールをinstructions/Skillに記述して 実施） ● ③ IaC(Terraform/Ansible)の⽣成‧レビュー ● ④ ログ解析 エージェント＋カスタムinstructionで「社内標準に沿うかの⾃動チェック」は有効。⼩さなルールセットから始 めるのがおすすめです。 Q A データ(mf4ファイルもしくはCSV)とモデル(slxファイルもしくはCソース)、これらをAIに読みま 込ませて、データ分析およびロジック不備特定をしたいのですが、それは可能でしょうか？ CSVやCソースはテキストなので読み込み‧解析できます。 データ分析はCopilotに分析スクリプト(Python等)を書かせて実⾏する形が有効です。 ⼀⽅mf4やslx(Simulink)はバイナリ/専⽤形式のため⼀度copilotで読み込ませて処理ができない場合は、 Skills等を活⽤して読み込ませてみてください。 Q A 

GitHub Actions などローカルPCで完結しないものの実装の検査が、結局⼿作業になってしまい ます。何か⼯夫できる点は？？ GitHubの強みはGitHub Platform上の操作もcopilotが⾏ってくれる部分にあると思います。Actionsの実⾏や結果 のチェック含めCopilot CLi等から直接操作できる認識です。 その上で、以下のような⽅法もお試しいただけると思います。 ● ① nektos/act でワークフローをローカル実⾏‧検証 ● ② actionlint等のlinterをCopilotに使わせて静的チェック（構⽂‧権限‧シークレット‧条件分岐） ● ③ Copilotにワークフローのドライラン的レビューを依頼 ● ④ テスト⽤ブランチやworkflow_dispatch(⼿動trigger)で素早く回す ● ⑤ CLIエージェントで「変更→push→gh run watchで結果確認→修正」を半⾃動化。 act＋linter＋エージェントの組み合わせで⼿作業を⼤幅に減らせます。 Q A 

社内での継続利⽤にあたりclaude codeなど他のコーディングエージェント⽐較のメリットを良 く聞かれます。どのような点で特⻑があるかコメントいただけますと幸いです。 GitHub Copilotの特⻑は「開発ライフサイクル全体の統合」です。 ● ① GitHubエコシステム(PR/Issue/Actions/Code Review/セキュリティ)との⼀体化 ● ② IDE各種＋CLI＋Web＋モバイルのマルチサーフェスで⼀貫した体験 ● ③ 複数モデルから選択でき、⽤途に応じて最適化(Auto含む) ● ④ エンタープライズのガバナンス/監査/データ保護/コンテンツ除外が成熟 ● ⑤ 既存のGitHub運⽤にそのまま乗る導⼊容易性 単なるコード⽣成でなく“チーム開発のワークフロー全体を加速”する点が差別化ポイントです。 Q A claude codeやcursorとの差別化についてご意⾒を伺いたいです。 Cursorやclaude codeはエディタ/CLI体験に強みがありますが、Copilotの差別化は「点(コード⽣成)ではなく線 (開発プロセス全体)」で効く点です。 ● ① GitHubワークフロー(Issue→PR→Code Review→Actions→セキュリティ)に統合 ● ② IDE各種/CLI/Web/モバイルのマルチサーフェスで⼀貫 ● ③ 複数モデル選択＋Auto最適化 ● ④ エンタープライズのガバナンス‧監査‧データ保護が成熟 ● ⑤ 既存のGitHub運⽤にゼロ摩擦で組み込める チーム開発全体を⼀気通貫で加速できるのが強みです。 Q A 

利⽤するモデルを選択する設定がありますが、どれを選べば良いのか、とりあえず全部選択して おくので良いのか、バージョン番号の⼤きいのを選択しておけば良いのか、、、よく分かってい ません。モデル選択の指針などあれば教えてください。 「全部選択して必要時に切り替える」でOKです。選択は使えるモデルを増やすだけで害はありません。 基本はAuto：タスクに応じてコスト/速度/品質のバランスで最適モデルを⾃動選択します。 指針としては、⽇常的‧単純な作業は⾼速‧低コストモデル、複雑な設計や難しいバグは⾼性能な推論(上位)モデ ル。 バージョン番号が⼤きい=新しい傾向ですが「常に最適」ではなく、コストや速度も考慮を。 迷ったらAuto、⾏き詰まったら上位モデルに切替、が実⽤的です。 Q A