Azure Lifecycle with Copilot CLI

※リンクを効かせたい場合はダウンロードしてください

Transcript

1. Azure Lifecycle with GitHub Copilot CLI 日本マイクロソフト株式会社 シニアクラウドソリューションアーキテクト 真壁 徹 Global Azure 2026 @Tokyo
2. Azure使いの日常  サービスを選ぶ  サービスの使い方を決める  コストを見積もる  利害関係者への説明資料を作る  アプリケーションを作る  サービスリソース（インフラ）とアプリ ケーションをデプロイする  デプロイした環境を確認、理解する  トラブルシューティングする  メンテナンスする
3. Azure使いの日常  サービスを選ぶ  サービスの使い方を決める  コストを見積もる  利害関係者への説明資料を作る  アプリケーションを作る  サービスリソース（インフラ）とアプリ ケーションをデプロイする  デプロイした環境を確認、理解する  トラブルシューティングする  メンテナンスする with
4. GitHub Copilot 四変化 Editor/IDE Plugin: GitHub Copilot Agent mode Visual Studio Codeなどのエディタ/IDEにプラグイン CLI: GitHub Copilot CLI エージェントが目的達成に集中。複雑なコーディングや分析に向く Desktop: VS Code Agents App on GitHub Copilot セッションを軸にした、新しい開発体験 Cloud: GitHub Copilot Cloud agent GitHub Actionsで動く、GitHubワークフローに溶け込むエージェント
5. わたしがGitHub Copilot CLIを推す理由  成果物が期待に沿いやすい  UI周りの仕事が少なく、目的達成にフォーカスできる  チャットのような応答時間を求められず、調査や試行に時間をかけられる  エディタがらみの事故が起きにくい  エディタと連動した「保持」「取り消し」操作とエージェントのgit操作が衝突、なんてことが起きにくい  進化が速い  毎日のように新機能や改善がリリースされる  GitHub Copilotのコアになりうる  GitHub Copilot SDKを使って、GitHub Copilot CLI呼び出すアプリケーションを作れる  他Microsoft/GitHub製品のベースになっていくかも（VS Code Agents Appは一例）  理解、習熟の価値がある
6. GitHub Copilot CLI 使いこなしのポイント
7. ターミナル/CLIは 怖くない
8. VS Code連携: diff表示  ファイル編集の承認要求時に、diff がVS Codeのエディタに表示される  ターミナル向けエディタではコードやdiffが入ってこ ない、という人に優しい
9. VS Code連携: コンテキスト注入  VS Codeのエディタで選択した行をCLIのコンテキストとして注入できる
10. ターミナルソフト -> VS Code接続  ターミナルソフトからVS Codeに接続  VS Code統合ターミナルは良くできているが…  依存するXterm.jsの制約や不具合が ちらほら  当然ながらターミナルソフトのCLI体験は良い  Windows Terminal、Ghostty、etc  好みのターミナルでGitHub Copilot CLIを使い、 VS Codeのエディタと連携したいときは `/ide` で 接続  前述のVS Code連携機能が使える
11. 信頼せよ、 されど検証せよ
12. コーディングエージェントと人、情報、ツールの関係 出典: Birgitta Böckeler, “Harness engineering for coding agent users” MartinFowler.com
13. フィードフォワードとフィードバック  信頼して導く “ガイド” からの フィードフォワード  エージェントが最初の試みで良い結果を生み出せるよう、情報やツールを与える  エージェントの創造性を活かすしくみが活躍  推論的/非決定論的  リファレンス、テンプレート、ナレッジベース、原則集、ルールブック、etc  検証する “センサー” からの フィードバック  エージェントのアクションを事前/事後に検証し、自己修正を助ける  実行タイミングとロジックを強制できるしくみが活躍  計算的/決定論的  静的解析、フォーマット、単体テスト、ツールブロッカー/エンフォーサー、ロギング、etc  作った仕組みはCIでも使えるので無駄にならない 注: まだ一般的な表現ではないが、このプレゼンテーションではガイド、センサーと呼ぶ
14. GitHub Copilot CLI におけるガイドとセンサー ガイド  カスタム指示ファイル  copilot-instructions.md  AGENTS.md  カスタムエージェント  スキル  MCP  モード  Plan/Autopilot  実行オプション  ツール、ファイル、URLの allow/deny センサー  フック  イベントに応じたスクリプト実行  カスタムスクリプト  静的解析ツールやテストなどをコール  レビューエージェント  /review スラッシュコマンド  rubber-duck 補足: これらは個人（~/.copilot）とリポジトリ、2つのレベルで設定 可能。マージを基本とするが、ユニーク名が求められるものはリポジトリが 優先される（スキル、カスタムエージェントなど）
15. Azure ライフサイクルにおける 活用法
16. 用意したガイドとセンサー #1  ガイド  プラグイン  Azure Skills: Azure MCP Serverと関連スキル  MS Learn MCP Server: MS Learn MCP Serverと関連スキル  スキル  azure-pptx: Anthropic公開スキル + Azureテンプレート知識 + プロジェクト固有知識  azure-drawio: jgraph/drawio-mcp + プロジェクト固有知識  azd-infra-rules: azd と bicep に関するプロジェクト固有知識  azd-hooks: azd で使うフックスクリプトに関するプロジェクト固有知識  bicep-api-version-updater: Bicepのメンテナンス作業手順 公開リポジトリ: torumakabe/az-lifecycle-with-ghcp-cli
17. 用意したガイドとセンサー #2  ガイド  カスタムエージェント  architecture-snapshot: アーキテクチャ概要説明書作成  manage-adr: ADRの作成、維持  review-repo: リポジトリの整頓。主にガイド/センサーの陳腐化、肥大化を防ぐ  センサー  フック  post-edit-lint: コード編集後のリント/フォーマット 公開リポジトリ: torumakabe/az-lifecycle-with-ghcp-cli
18. サービスを選ぶ
19. サービス選定 プロンプト例 /research 次の要望を満たす Azure サービスの組み合わせを調査し、推奨を提示して - Python の Web API アプリケーション - Python のバージョンは 3.13 - フレームワークは FastAPI - Python のパッケージ管理は uv - ピーク時のリクエスト数は100/秒程度 - RDBMSを使う（トランザクションあり） - コンテナ技術（Docker等）の導入予定はなく、コードを直接デプロイしたい - チームに PostgreSQL の経験があり、既存の運用知識を活かしたい - パスワードレス認証（Entra ID）でデータベースに接続したい - リージョンは東日本 - コンピューティングサービスとデータベースサービスそれぞれについて、候補を比較したい - SKU やプランは未決定でよい 結果は docs/research/azure-service-selection.md に保存して
20. 結果  Azure MCP Server / MS Learn MCP Server 等を活用した Deep Research が実行される  要望をもとに、推奨するAzureサービ スをまとめたレポートが生成される
21. Tips: ADR（Architectural Decision Record）を記録する App Service と PostgreSQL Flexible Server を採用する。 サービス選定の判断を ADR として記録して。コンテキストは @azure-service-selection.md を参考にして • 決定事項記録は人間/エージェントどちらにも有用 • ライフサイクル全体で判断の拠り所になる • 決定事項やその理由がセッションと一緒に消えてし まわないようにする • ADRに記録することの例 • コンテキスト、背景 • 決定事項 • 不採用案とその理由 • 期待できる効果/考慮点
22. Tips: ADRの作成・維持  何をADRとして残すか  まず、アーキテクチャとは、何か  トール・マカベッチによる定義: 作るものの土台となる構造。および、それに関する意思決定の集合  コードを読めば分かることは残さない  仕様書ではない  ドキュメントが多くなるとエージェントも人間も読み切れなくなる  迷ったら「6か月テスト」  6ヶ月後に誰かが「なぜこうした？変えていい？」と聞きそうなことは、記録する  ADR作成・維持の省力化  カスタムエージェントで楽をする
23. サービスの使い方を 決める
24. 推奨構成の調査 プロンプト例 /research @docs/adr/ と次の要望を満たす推奨構成を調査して - App Service と PostgreSQL の間は常に VNet + Private Endpoint 経由のプライベート接続とする（PoC・ 本番共通） - データベースは本番環境ではインターネットに公開しない - ただし PoC 段階では開発者が手元のツール（psql 等）から直接接続できるよう、DB パブリックアクセスも有 効にする - PoC と本番の構成が大きく変わらないようにしたい（もちろんサイズや SKU は違ってもよい） - PoC で性能の基礎値を測りたいため、PoC と本番は同じプランレベルとする。PoC のサイズは最小とする - Azureサービスのログとメトリクス、アプリケーションのトレースを収集 - アプリケーションのトレースは自動計装 - ログとメトリクス、トレースは取り込みコストが低くなるように。保存期間は既定 - Azure Developer CLI（azd）でデプロイする前提 結果は docs/research/recommended-architecture.md に保存して
25. 結果  Azure MCP Server / MS Learn MCP Server 等を活用した Deep Research が実行される  選定したサービスの、より踏み込んだ 推奨構成レポートが得られる  このレポートをもとに構成や使い方を 決定し、追加のADRを作る
26. 追加ADRの例
27. Tips: このタイミングでIaCコードを作る @docs/research/recommended-architecture.md と @docs/adr/ をもとに bicepコードを生成して。 azd 構成（azure.yaml、hooks）も含めて • LLMは自然言語の読み書きができるとはいえ、パ ターンやルールのあるコードの扱いのほうが得意 • 早い段階でコードを生成し、エージェントとのコミュニケーショ ンのベースにする
28. よくある要望: ExcelパラメータシートからIaCコードを作りたい  技術的には〇〇  Opus 4.6 など最近のモデルはExcelをうまく扱える  Excelパラメータシートの内容によっては、できなくはない  それに意味があるかは議論したほうがよい  Azure MCP Serverなどがあれば、Azure上の現物からIaCコードを生成できる  ほんとうにExcel必要？  エージェントでワークフローを効率化しても、そこが制約になりうる  構成ドリフト、変更履歴の不透明さ、レビュー・承認プロセスの欠如、陳腐化、etc  ほんとうにExcel必要？  「Excelくらいしか使えないでしょ」とコラボレーション相手を低く見ていないか  相手の学ぶ機会を奪っていないか  ほんとうにExcel必要？
29. Tips: 複数のモデルでレビューする /review @infra/ をレビューして。 セキュリティ、コスト、運用性の観点で改善点があれば指摘して。Bicep のビルドも実行して。 2つのサブエージェント（Opus 4.6 と GPT 5.4）で実行して • 異なるモデルの2つのサブエージェントが並列実行さ れる • いちいち /model コマンドで切り替えなくてよい • 結果は統合のうえ報告される • 両者が指摘した点は信頼度が高い • 片方だけ指摘した点はセカンドオピニオン • 複雑な作業を行っていると自動でrubber-duckエー ジェントが発動し、別モデルでレビューする（現在は Experimentalフラグで有効化）
30. Tips: 構成図を書く（Mermaid） @infra/ このBicepファイルからAzure構成図を Mermaid形式で docs/design-infrastructure-diagram.md に作って。本番環境だけでなく、全ての環境を。 後続のドキュメントやスライドから参照しやすいよう、可読性を優先し、必要なら分割して • 生成が早い • 細かなレイアウト 調整は難しい
31. Tips: 構成図を書く（draw.io） @infra/ このBicepファイルからAzure構成図を draw.io 形式で docs/design-infrastructure- diagram.drawio に作って。本番環境だけでなく、全ての環境を。 後続のドキュメントやスライドから参照しやすいよう、1ページに無理に詰め込まず必要なら分割して • Azureのアイコンを使って生成する • スキルでdraw.ioのMCPやCLIを使う • レイアウトや結線をGUIで編集できる • ただし、編集してしまうと気軽に再生成でき なくなる • ライフサイクル全体で再生成の機会は多い • 生成に時間がかかる
32. コストを見積もる
33. コスト見積 プロンプト例と結果 @infra/ このBicepファイルに定義されたAzureリソースの月額コストを見積もって。価格ツールを使って最新の価 格で計算して 見積もり結果を Excel ファイルにまとめて docs/cost-estimate.xlsx に保存して。リソース名、SKU、月額コスト、 年額コストの列を含めて • Azure MCP Server の Pricing Tool （`azure_development_get_pri ces`）が呼ばれる • Bicep で定義された各リソースのコ ストが表示される • Excelファイルに出力される
34. 利害関係者への説明資料を作る
35. 説明資料作成 プロンプト例 @docs/adr/ @infra/ @docs/design-infrastructure-diagram.drawio @docs/cost-estimate.xlsx の内 容を踏まえて、Azure環境の概要スライドを docs/overview.pptx として作って。 構成図は無理に画像挿入せず、別資料参照として扱ってよい。 以下のページを必ず含めること: 1. 構成要素一覧（Bicepリソースベース） 2. 設計判断のポイント（ADRベース） 3. コスト概算（xlsxベース） 4. 参考資料（構成図や詳細資料への参照）
36. 結果  モデルとスキルの組み合わせによって は、「ありかも」なPowerPointスライ ドを生成できる  現時点で「ありかも」と思えた組み合わせ  Opus 4.6  Anthropicが公開しているpptxスキル  期待に沿う出力になるようスキルで調整  テンプレートの使いこなしなど  生成に時間がかかる  凝り始めると時間が溶ける  人間の加筆修正を前提に、たたき台と割り切る
37. アプリケーションを作る
38. アーキテクチャ屋の ひとりごと アーキテクチャの妥当性を検証したいけど アプリケーションは まだない
39. 検証用アプリケーション作成 プロンプト例 @infra/ の構成に対して、以下を検証するシンプルなWebアプリをPython 3.13 + FastAPIで作って: 1. ヘルスチェックエンドポイント（/health） 2. DB接続確認エンドポイント（/check-db） — 認証方式は infra/ の定義に従う 3. レスポンスタイム計測（各エンドポイントで処理時間をms単位で返す） src/verification-app/ に配置して /review @src/verification-app/ をレビューして。特に @docs/adr/ の設計判断が正しく反映されているかと、 @infra/ @azure.yaml @hooks/ との統合ができているか。 2つのサブエージェント（Opus 4.6 と GPT 5.4）で実行して
40. 結果  ADRやIaCを踏まえ、要望に沿うア プリケーションコードを生成する  複数モデルでのレビューは強力  何度も回したくなる（ほどほどに）
41. ADRとガイドだけで チーム開発できるか？  原則「ソースコードが唯一の真実」  とはいえ勢いで作ったplanファイルを使い捨てて、「ソースコード読んで」は乱暴  IaCやプラットフォームロジックでは実用的  モデルやガイドが持つ一般的な知識 + α で多くをカバーできる  判断ポイントをADRで記録し、人とエージェントに伝える  アプリケーションロジックは、他の手段を組み合わせるのが現実的  組織固有のドメイン知識などは機能仕様として記録し伝える必要があるが、ADRはそれに向かない  まだ定番と呼べる手段はないが、活発に議論・開発されている  例: GitHub Spec Kit  仕様のドキュメント化から実装までのワークフローを実現するエージェントの集合体  生成されるドキュメントの量に、エージェントも人も圧倒されがち  機能追加はよいが、既存仕様の変更に課題あり（拡張機能での解決が提案されている）
42. サービスリソース（インフラ）と アプリケーションをデプロイする
43. Azureへのデプロイ プロンプト例と結果 azdでインフラとアプリをデプロイして。PoC向けで 作成されたリソースの一覧と状態を確認して デプロイしたアプリの /health と /check-db エンドポイントを叩いて、結果を見せて
44. デプロイした環境を 確認、理解する
45. アーキテクチャ屋の ひとりごと Azure CLIコマンド、KQLを覚えれば大抵の構成・ 状況把握ができるって分かってるけど 忘れる
46. 環境確認・調査 プロンプト例と結果 #1 デプロイしたリソースグループ内で、インターネットからアクセスできる可能性があるリソースを調べて。 Resource Graph を使って公開設定を確認し、リソースごとにどのように露出しているか分類して
47. 環境確認・調査 プロンプト例と結果 #2 App Service から PostgreSQL への接続がどのように構成されているか分析して。 App Service のアプリケーション設定から接続先情報を確認し、ネットワーク経路（VNet統合やプライベートエン ドポイントの有無、パブリックアクセスの設定）を調べて、接続経路の全体像を説明して
48. トラブルシューティングする
49. トラブルシューティング プロンプト例 デプロイした App Service の /check-db エンドポイントへのアクセスでエラーが出ているらしい。状況を確認して 原因が分かれば修正して、動作確認もして
50. トラブルシューティング自動化の前に  理解していないことの自動化 -> 高リスク  破壊の連鎖、コスト爆発、情報漏洩、etc  まず手を動かし Agentic Operation/Troubleshooting の世界を理解する  Azure SRE Agentのような常駐・自律型エージェントの本格化に備える  GitHub Copilot CLIは手を動かしながら考え、理解するのに適したツール  運用/トラブルシューティングにおいて、どのようなガイドやセンサーが必要か？  エージェント視点での可観測性とは？  与えるべき権限は何か？
51. メンテナンスする
52. Bicep APIバージョンメンテナンス プロンプト例 @infra/ 配下の Bicep で使われている API バージョンを更新して • Bicep APIバージョンを更新するスキルを用意 • Bicepファイル解析 • プレビューAPIチェック • 最新GAバージョンと比較 • 破壊的変更の確認 • APIバージョン更新（仮適用） • リンター検証（警告時は戻し） • このような「たまにやるけど、頑張って自動化 するか悩む」作業にスキルは便利
53. まとめ
54. まとめ  Azure使いはGitHub Copilot CLIでハッピーになれます  日々しみじみと  AIで技術力が落ちる？使い方次第です  理解する手段が増える（文法やコマンドに自信がなくても、好奇心と自然言語で飛び込む）  理解する時間が増える（退屈なことはAIに任せて、手を動かす時間を作る）  手を動かして理解できる（机上検討はそこそこに、動かして確かめる）  GitHub Copilot CLIを使いこなす道具を整えましょう  ガイド  センサー