Azure Lifecycle with Copilot CLI

by Toru Makabe

Embed

Start on current slide

Slide 1

Slide 1 text

Azure Lifecycle with GitHub Copilot CLI 日本マイクロソフト株式会社シニアクラウドソリューションアーキテクト真壁徹 Global Azure 2026 @Tokyo

Slide 2

Slide 2 text

Azure使いの日常  サービスを選ぶ  サービスの使い方を決める  コストを見積もる  利害関係者への説明資料を作る  アプリケーションを作る  サービスリソース（インフラ）とアプリケーションをデプロイする  デプロイした環境を確認、理解する  トラブルシューティングする  メンテナンスする

Slide 3

Slide 3 text

Azure使いの日常  サービスを選ぶ  サービスの使い方を決める  コストを見積もる  利害関係者への説明資料を作る  アプリケーションを作る  サービスリソース（インフラ）とアプリケーションをデプロイする  デプロイした環境を確認、理解する  トラブルシューティングする  メンテナンスする with

Slide 4

Slide 4 text

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ワークフローに溶け込むエージェント

Slide 5

Slide 5 text

わたしがGitHub Copilot CLIを推す理由  成果物が期待に沿いやすい  UI周りの仕事が少なく、目的達成にフォーカスできる  チャットのような応答時間を求められず、調査や試行に時間をかけられる  エディタがらみの事故が起きにくい  エディタと連動した「保持」「取り消し」操作とエージェントのgit操作が衝突、なんてことが起きにくい  進化が速い  毎日のように新機能や改善がリリースされる  GitHub Copilotのコアになりうる  GitHub Copilot SDKを使って、GitHub Copilot CLI呼び出すアプリケーションを作れる  他Microsoft/GitHub製品のベースになっていくかも（VS Code Agents Appは一例）  理解、習熟の価値がある

Slide 6

Slide 6 text

GitHub Copilot CLI 使いこなしのポイント

Slide 7

Slide 7 text

ターミナル/CLIは怖くない

Slide 8

Slide 8 text

VS Code連携: diff表示  ファイル編集の承認要求時に、diff がVS Codeのエディタに表示される  ターミナル向けエディタではコードやdiffが入ってこない、という人に優しい

Slide 9

Slide 9 text

VS Code連携: コンテキスト注入  VS Codeのエディタで選択した行をCLIのコンテキストとして注入できる

Slide 10

Slide 10 text

ターミナルソフト -> VS Code接続  ターミナルソフトからVS Codeに接続  VS Code統合ターミナルは良くできているが…  依存するXterm.jsの制約や不具合がちらほら  当然ながらターミナルソフトのCLI体験は良い  Windows Terminal、Ghostty、etc  好みのターミナルでGitHub Copilot CLIを使い、 VS Codeのエディタと連携したいときは `/ide` で接続  前述のVS Code連携機能が使える

Slide 11

Slide 11 text

信頼せよ、されど検証せよ

Slide 12

Slide 12 text

コーディングエージェントと人、情報、ツールの関係出典: Birgitta Böckeler, “Harness engineering for coding agent users” MartinFowler.com

Slide 13

Slide 13 text

フィードフォワードとフィードバック  信頼して導く “ガイド” からのフィードフォワード  エージェントが最初の試みで良い結果を生み出せるよう、情報やツールを与える  エージェントの創造性を活かすしくみが活躍  推論的/非決定論的  リファレンス、テンプレート、ナレッジベース、原則集、ルールブック、etc  検証する “センサー” からのフィードバック  エージェントのアクションを事前/事後に検証し、自己修正を助ける  実行タイミングとロジックを強制できるしくみが活躍  計算的/決定論的  静的解析、フォーマット、単体テスト、ツールブロッカー/エンフォーサー、ロギング、etc  作った仕組みはCIでも使えるので無駄にならない注: まだ一般的な表現ではないが、このプレゼンテーションではガイド、センサーと呼ぶ

Slide 14

Slide 14 text

GitHub Copilot CLI におけるガイドとセンサーガイド  カスタム指示ファイル  copilot-instructions.md  AGENTS.md  カスタムエージェント  スキル  MCP  モード  Plan/Autopilot  実行オプション  ツール、ファイル、URLの allow/deny センサー  フック  イベントに応じたスクリプト実行  カスタムスクリプト  静的解析ツールやテストなどをコール  レビューエージェント  /review スラッシュコマンド  rubber-duck 補足: これらは個人（~/.copilot）とリポジトリ、2つのレベルで設定可能。マージを基本とするが、ユニーク名が求められるものはリポジトリが優先される（スキル、カスタムエージェントなど）

Slide 15

Slide 15 text

Azure ライフサイクルにおける活用法

Slide 16

Slide 16 text

用意したガイドとセンサー #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

Slide 17

Slide 17 text

用意したガイドとセンサー #2  ガイド  カスタムエージェント  architecture-snapshot: アーキテクチャ概要説明書作成  manage-adr: ADRの作成、維持  review-repo: リポジトリの整頓。主にガイド/センサーの陳腐化、肥大化を防ぐ  センサー  フック  post-edit-lint: コード編集後のリント/フォーマット公開リポジトリ: torumakabe/az-lifecycle-with-ghcp-cli

Slide 18

Slide 18 text

サービスを選ぶ

Slide 19

Slide 19 text

サービス選定プロンプト例 /research 次の要望を満たす Azure サービスの組み合わせを調査し、推奨を提示して - Python の Web API アプリケーション - Python のバージョンは 3.13 - フレームワークは FastAPI - Python のパッケージ管理は uv - ピーク時のリクエスト数は100/秒程度 - RDBMSを使う（トランザクションあり） - コンテナ技術（Docker等）の導入予定はなく、コードを直接デプロイしたい - チームに PostgreSQL の経験があり、既存の運用知識を活かしたい - パスワードレス認証（Entra ID）でデータベースに接続したい - リージョンは東日本 - コンピューティングサービスとデータベースサービスそれぞれについて、候補を比較したい - SKU やプランは未決定でよい結果は docs/research/azure-service-selection.md に保存して

Slide 20

Slide 20 text

結果  Azure MCP Server / MS Learn MCP Server 等を活用した Deep Research が実行される  要望をもとに、推奨するAzureサービスをまとめたレポートが生成される

Slide 21

Slide 21 text

Tips: ADR（Architectural Decision Record）を記録する App Service と PostgreSQL Flexible Server を採用する。サービス選定の判断を ADR として記録して。コンテキストは @azure-service-selection.md を参考にして • 決定事項記録は人間/エージェントどちらにも有用 • ライフサイクル全体で判断の拠り所になる • 決定事項やその理由がセッションと一緒に消えてしまわないようにする • ADRに記録することの例 • コンテキスト、背景 • 決定事項 • 不採用案とその理由 • 期待できる効果/考慮点

Slide 22

Slide 22 text

Tips: ADRの作成・維持  何をADRとして残すか  まず、アーキテクチャとは、何か  トール・マカベッチによる定義: 作るものの土台となる構造。および、それに関する意思決定の集合  コードを読めば分かることは残さない  仕様書ではない  ドキュメントが多くなるとエージェントも人間も読み切れなくなる  迷ったら「6か月テスト」  6ヶ月後に誰かが「なぜこうした？変えていい？」と聞きそうなことは、記録する  ADR作成・維持の省力化  カスタムエージェントで楽をする

Slide 23

Slide 23 text

サービスの使い方を決める

Slide 24

Slide 24 text

推奨構成の調査プロンプト例 /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 に保存して

Slide 25

Slide 25 text

結果  Azure MCP Server / MS Learn MCP Server 等を活用した Deep Research が実行される  選定したサービスの、より踏み込んだ推奨構成レポートが得られる  このレポートをもとに構成や使い方を決定し、追加のADRを作る

Slide 26

Slide 26 text

追加ADRの例

Slide 27

Slide 27 text

Tips: このタイミングでIaCコードを作る @docs/research/recommended-architecture.md と @docs/adr/ をもとに bicepコードを生成して。 azd 構成（azure.yaml、hooks）も含めて • LLMは自然言語の読み書きができるとはいえ、パターンやルールのあるコードの扱いのほうが得意 • 早い段階でコードを生成し、エージェントとのコミュニケーションのベースにする

Slide 28

Slide 28 text

よくある要望: ExcelパラメータシートからIaCコードを作りたい  技術的には〇〇  Opus 4.6 など最近のモデルはExcelをうまく扱える  Excelパラメータシートの内容によっては、できなくはない  それに意味があるかは議論したほうがよい  Azure MCP Serverなどがあれば、Azure上の現物からIaCコードを生成できる  ほんとうにExcel必要？  エージェントでワークフローを効率化しても、そこが制約になりうる  構成ドリフト、変更履歴の不透明さ、レビュー・承認プロセスの欠如、陳腐化、etc  ほんとうにExcel必要？  「Excelくらいしか使えないでしょ」とコラボレーション相手を低く見ていないか  相手の学ぶ機会を奪っていないか  ほんとうにExcel必要？

Slide 29

Slide 29 text

Tips: 複数のモデルでレビューする /review @infra/ をレビューして。セキュリティ、コスト、運用性の観点で改善点があれば指摘して。Bicep のビルドも実行して。 2つのサブエージェント（Opus 4.6 と GPT 5.4）で実行して • 異なるモデルの2つのサブエージェントが並列実行される • いちいち /model コマンドで切り替えなくてよい • 結果は統合のうえ報告される • 両者が指摘した点は信頼度が高い • 片方だけ指摘した点はセカンドオピニオン • 複雑な作業を行っていると自動でrubber-duckエージェントが発動し、別モデルでレビューする（現在は Experimentalフラグで有効化）

Slide 30

Slide 30 text

Tips: 構成図を書く（Mermaid） @infra/ このBicepファイルからAzure構成図を Mermaid形式で docs/design-infrastructure-diagram.md に作って。本番環境だけでなく、全ての環境を。後続のドキュメントやスライドから参照しやすいよう、可読性を優先し、必要なら分割して • 生成が早い • 細かなレイアウト調整は難しい

Slide 31

Slide 31 text

Tips: 構成図を書く（draw.io） @infra/ このBicepファイルからAzure構成図を draw.io 形式で docs/design-infrastructure- diagram.drawio に作って。本番環境だけでなく、全ての環境を。後続のドキュメントやスライドから参照しやすいよう、1ページに無理に詰め込まず必要なら分割して • Azureのアイコンを使って生成する • スキルでdraw.ioのMCPやCLIを使う • レイアウトや結線をGUIで編集できる • ただし、編集してしまうと気軽に再生成できなくなる • ライフサイクル全体で再生成の機会は多い • 生成に時間がかかる

Slide 32

Slide 32 text

コストを見積もる

Slide 33

Slide 33 text

コスト見積プロンプト例と結果 @infra/ このBicepファイルに定義されたAzureリソースの月額コストを見積もって。価格ツールを使って最新の価格で計算して見積もり結果を Excel ファイルにまとめて docs/cost-estimate.xlsx に保存して。リソース名、SKU、月額コスト、年額コストの列を含めて • Azure MCP Server の Pricing Tool （`azure_development_get_pri ces`）が呼ばれる • Bicep で定義された各リソースのコストが表示される • Excelファイルに出力される

Slide 34

Slide 34 text

利害関係者への説明資料を作る

Slide 35

Slide 35 text

説明資料作成プロンプト例 @docs/adr/ @infra/ @docs/design-infrastructure-diagram.drawio @docs/cost-estimate.xlsx の内容を踏まえて、Azure環境の概要スライドを docs/overview.pptx として作って。構成図は無理に画像挿入せず、別資料参照として扱ってよい。以下のページを必ず含めること: 1. 構成要素一覧（Bicepリソースベース） 2. 設計判断のポイント（ADRベース） 3. コスト概算（xlsxベース） 4. 参考資料（構成図や詳細資料への参照）

Slide 36

Slide 36 text

結果  モデルとスキルの組み合わせによっては、「ありかも」なPowerPointスライドを生成できる  現時点で「ありかも」と思えた組み合わせ  Opus 4.6  Anthropicが公開しているpptxスキル  期待に沿う出力になるようスキルで調整  テンプレートの使いこなしなど  生成に時間がかかる  凝り始めると時間が溶ける  人間の加筆修正を前提に、たたき台と割り切る

Slide 37

Slide 37 text

アプリケーションを作る

Slide 38

Slide 38 text

アーキテクチャ屋のひとりごとアーキテクチャの妥当性を検証したいけどアプリケーションはまだない

Slide 39

Slide 39 text

検証用アプリケーション作成プロンプト例 @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）で実行して

Slide 40

Slide 40 text

結果  ADRやIaCを踏まえ、要望に沿うアプリケーションコードを生成する  複数モデルでのレビューは強力  何度も回したくなる（ほどほどに）

Slide 41

Slide 41 text

ADRとガイドだけでチーム開発できるか？  原則「ソースコードが唯一の真実」  とはいえ勢いで作ったplanファイルを使い捨てて、「ソースコード読んで」は乱暴  IaCやプラットフォームロジックでは実用的  モデルやガイドが持つ一般的な知識 + α で多くをカバーできる  判断ポイントをADRで記録し、人とエージェントに伝える  アプリケーションロジックは、他の手段を組み合わせるのが現実的  組織固有のドメイン知識などは機能仕様として記録し伝える必要があるが、ADRはそれに向かない  まだ定番と呼べる手段はないが、活発に議論・開発されている  例: GitHub Spec Kit  仕様のドキュメント化から実装までのワークフローを実現するエージェントの集合体  生成されるドキュメントの量に、エージェントも人も圧倒されがち  機能追加はよいが、既存仕様の変更に課題あり（拡張機能での解決が提案されている）

Slide 42

Slide 42 text

サービスリソース（インフラ）とアプリケーションをデプロイする

Slide 43

Slide 43 text

Azureへのデプロイプロンプト例と結果 azdでインフラとアプリをデプロイして。PoC向けで作成されたリソースの一覧と状態を確認してデプロイしたアプリの /health と /check-db エンドポイントを叩いて、結果を見せて

Slide 44

Slide 44 text

デプロイした環境を確認、理解する

Slide 45

Slide 45 text

アーキテクチャ屋のひとりごと Azure CLIコマンド、KQLを覚えれば大抵の構成・状況把握ができるって分かってるけど忘れる

Slide 46

Slide 46 text

環境確認・調査プロンプト例と結果 #1 デプロイしたリソースグループ内で、インターネットからアクセスできる可能性があるリソースを調べて。 Resource Graph を使って公開設定を確認し、リソースごとにどのように露出しているか分類して

Slide 47

Slide 47 text

環境確認・調査プロンプト例と結果 #2 App Service から PostgreSQL への接続がどのように構成されているか分析して。 App Service のアプリケーション設定から接続先情報を確認し、ネットワーク経路（VNet統合やプライベートエンドポイントの有無、パブリックアクセスの設定）を調べて、接続経路の全体像を説明して

Slide 48

Slide 48 text

トラブルシューティングする

Slide 49

Slide 49 text

トラブルシューティングプロンプト例デプロイした App Service の /check-db エンドポイントへのアクセスでエラーが出ているらしい。状況を確認して原因が分かれば修正して、動作確認もして

Slide 50

Slide 50 text

トラブルシューティング自動化の前に  理解していないことの自動化 -> 高リスク  破壊の連鎖、コスト爆発、情報漏洩、etc  まず手を動かし Agentic Operation/Troubleshooting の世界を理解する  Azure SRE Agentのような常駐・自律型エージェントの本格化に備える  GitHub Copilot CLIは手を動かしながら考え、理解するのに適したツール  運用/トラブルシューティングにおいて、どのようなガイドやセンサーが必要か？  エージェント視点での可観測性とは？  与えるべき権限は何か？

Slide 51

Slide 51 text

メンテナンスする

Slide 52

Slide 52 text

Bicep APIバージョンメンテナンスプロンプト例 @infra/ 配下の Bicep で使われている API バージョンを更新して • Bicep APIバージョンを更新するスキルを用意 • Bicepファイル解析 • プレビューAPIチェック • 最新GAバージョンと比較 • 破壊的変更の確認 • APIバージョン更新（仮適用） • リンター検証（警告時は戻し） • このような「たまにやるけど、頑張って自動化するか悩む」作業にスキルは便利

Slide 53

Slide 53 text

まとめ

Slide 54

Slide 54 text

まとめ  Azure使いはGitHub Copilot CLIでハッピーになれます  日々しみじみと  AIで技術力が落ちる？使い方次第です  理解する手段が増える（文法やコマンドに自信がなくても、好奇心と自然言語で飛び込む）  理解する時間が増える（退屈なことはAIに任せて、手を動かす時間を作る）  手を動かして理解できる（机上検討はそこそこに、動かして確かめる）  GitHub Copilot CLIを使いこなす道具を整えましょう  ガイド  センサー

Slide 55

Slide 55 text

No content