20261022_GitHub Copilot CLI × Agentic DevOps — Deployで終わらせないために

2026年10月22日、GitHub Dev Days Tokyo で登壇した資料です。

「AIでコードが速く書ける」という話は、もう十分に聞いたと思います。でも運用側の仕事は、調べて、確認して、手順どおりに実行することが大半です。そして本番の踏み台の先には、IDEもブラウザもなくて、ターミナルしかありません。

GitHub Copilot CLI が効くのは、まさにそこだと思っています。

この資料では、Copilot CLI を「CLI版のCopilot」としてではなく、Issue から Pull Request、GitHub Actions、Deploy を通り、監視と障害対応を経てまた Issue に戻ってくる——その一周のどこに Agent を置くか、という視点で整理しました。

後半には、Azure Pipelines から GitHub Actions への移行を Copilot の Custom Agent に任せてみた実体験を入れています。Agent が強かったところ、人が判断するしかなかったところ、そして正直いちばん時間を取られた「前提を整える」部分まで、そのまま載せました。

扱っている主なトピック
・Copilot CLI と GitHub Copilot app の使い分け
・Context / Custom Instructions / MCP の設計
・/plan /agent /skills /fleet /delegate /remote
・運用でのCLI活用（障害調査、IaCドリフト、Runbookの資産化、定期点検）
・AI Agent を前提にした DevOps のガードレール

Transcript

1. G i t Hub De v Da ys To kyo GitHub Copilot CLI × Agentic DevOps 作って終わりにしない — Issueに始まり、運用からIssueに戻るまで copilot $ copilot > 本番で出ている 5xx を調べて、Issue にして GitHub Dev Days Tokyo | Session
2. AGENDA 今日伝えたいこと 01 02 03 AIは「道具」から 「プロセスの参加者」へ CLIは「作る側」と 「動かし続ける側」をつなぐ 一周させて、 初めてDevOpsになる 補完してくれる道具ではなく、 ターミナルは開発者だけの Deployで終わらせない。 計画し、実行し、報告する 場所ではない。運用の現場こそ 運用で分かったことを 一員になりつつある。 ターミナルしかない。 次のIssueに戻す。 今日の裏テーマ：Devの話に偏らせない。Opsにこそ効く、という話をします。
3. RIDING TH E WAVES GitHub Copilotの進化 Wave 3 Wave 2 Wave 1 コード補完 2021-2023 Agentic SDLC 2026+ 2024-2025 人とAgentがチームを組み、 開発者が中心で全体を指揮する。 計画・実装・レビューまで、 AIがプロセスに参加する。 開発者が運転席。 AIは横で補完するだけ。 いま私たちは Wave 2 → Wave 3 の移行期にいる ハイブリッドチーム 運用まで含めて任せ始める。
4. EVERYWH ERE YOU CODE One GitHub Copilot, everywhere you code GitHub.com / Mobile VS Code / 各種IDE Terminal（Copilot CLI） Issue・PRから直接依頼 Visual Studio, JetBrains, Xcode 今日の主役 GitHub Copilot app Slack / Teams Boards / Jira / Linear デスクトップの司令塔 チャットからタスクを委譲 既存のバックログとつながる どこで頼んでも同じCopilot。同じ Custom Instructions を読み、同じ Issue を見る。 だから、ターミナルで始めた作業をGitHub上で引き継げるし、その逆もできる。
5. WH AT' S DIF F ERENT Copilot CLIとは — IDEのCopilotと何が違うか copilot $ copilot -p "/review 直近のIaC差分" • リポジトリを解析中... • AGENTS.md を読み込み • azure-mcp: 実環境の構成を取得 どこでも動く SSH先、コンテナの中、GUIのない本番環境。 自動化できる ✓ レポートを report.md に出力 > この差分、Issue に起票して ヘッドレス実行 copilot -p で非対話実行。cron や Actions から呼べる。 main.bicep と実環境に差分 3件 - SKU が手動変更されています エディタを前提にしない 並列と遠隔 /fleet と /remote 並列で走らせ、外から確認・操作できる。 統制できる 権限とログを設計できる Permissions / Sandbox / Hooks / OpenTelemetry。 CLIはIDEのCopilotの代わりではない。「自動化」と「統制」の層を足せる、唯一の入口。
6. CLI vs APP Copilot CLI と GitHub Copilot app の使い分け GitHub Copilot CLI GitHub Copilot app ターミナルの中で動くAgent 作業全体を束ねるデスクトップの司令塔 POSITION POSITION 手元の環境そのものを操作対象にする GitHub上の作業フローを一箇所に集約する STRENGTH STRENGTH 細かい制御と、パイプラインへの組み込み 複数セッションの並行管理と可視化 PARALLEL PARALLEL /fleet — 1セッション内のサブエージェント セッションごとに独立したworktreeとブランチ OPS FIT OPS FIT 踏み台の先・本番環境でも同じものが動く Cloud automationsで定期実行をクラウドに置く Copilot app は Copilot CLI の上に構築されている。対立ではなく、同じエンジンの別の使い方。 配管に組み込むならCLI。人が複数の作業を指揮するならapp。まずCLI側で権限とログの型を作るのが先。
7. TH E KEY SLIDE Agentic DevOps — Deployは終点ではない DEV — つくる Issue Copilot CLI Context / Agent Code Change Pull Request 作業の起点 ターミナルの入口 規約・文脈・MCP 差分を生む 人が確認する場 Developer — 一周の中心にいるのは人 OPS — 動かし続ける 原因をIssueへ Incident / Alert Monitor / Logs Deploy GitHub Actions 次の起点に戻す 異常に気づく 動いている状態を見る 承認を経て本番へ テスト・スキャン Deployで線を止めない。運用で分かったことがIssueに戻って、はじめて一周する。 Agentが入る場所は上段だけではない。障害の一次切り分けも、Issue化も、同じCLIからできる。
8. DEV SIDE / CONTEXT Context is Everything AIの出力品質は、 渡したContextで 決まる。 AGENTS.md @file /context Custom Instructions チームの規約・設計方針を毎回の前提にする ファイルメンション 対象ファイル・ログ・画面キャプチャを明示的に渡す Contextの可視化 いま何が入っているか、消費量を確認する プロンプトを磨くより、 「何を読ませるか」を設計するほうが、 結果への影響がはるかに大きい。 /compact /mcp Contextの圧縮 要約して圧縮。Infinite Sessionsで自動管理も 外部の文脈を接続 GitHub・Azure・Microsoft Learn などを参照
9. DEV SIDE / /p l an いきなり書かせない — Plan before Code copilot 1 要件と影響範囲を洗い出す 依存関係・波及する箇所をAgentに整理させる > /plan ## 実装方針 1. AuthHandler を分離 2. 既存の DI 登録を更新 2 方針を人がレビューする /model で別モデルの案と比較してから決める ## 影響範囲 6 files / 2 tests ## テスト方針 単体 + 統合を追加 > 2 は影響が広い。別PRに分けよう 3 合意できたら実装へ Autopilotで一気に進める。判断は先に済んでいる ✓ 計画を更新しました 手戻りの原因は「実装の失敗」より「方針の不一致」
10. DEV SIDE / EXTEND Agents / Skills / MCP で役割を分ける /agent /skills /mcp 専用Agent Skills MCP 役割ごとに振る舞いを定義した 手順とツール権限をセットで定義し、 外部システムをツールとして接続。 Agentを使い分ける 必要なときだけ呼び出す GitHub / Azure / MS Learn など レビュー観点そのものを、Agentとして資産化する レビューAgent テストAgent セキュリティAgent 運用点検Agent 規約準拠と設計の妥当性 不足テストの洗い出し Secret混入・依存の脆弱性 アラートの一次切り分け
11. F AN - OUT / F AN- IN 分散と統合の実行モデル — /fleet をどう走らせるか ① ② ③ ④ ⑤ 目的を1つ渡す 作業項目に分解 独立分を並列実行 完了を待ち次の波 検証して統合 分割は指示しない 依存関係を判定 各自のContext 依存分を順に 親が1つにまとめる プロンプトの書き方で、ほぼ決まる copilot 成果物をファイル単位で書く 「よしなに」ではなく、出力先を明示する > /fleet 認証モジュールをリファクタし、 tests/auth を更新し、docs/auth を直して $ copilot -p "/fleet ..." --no-ask-user 依存関係は自分で宣言する 先に終わらせたいものを文中で指定する 直列の仕事には使わない 分けられない作業は、調整コストで遅くなる Copilot CLI /fleet Claude Code Agent Teams ハブ&スポーク型。親が分解し統合。サブ同士は会話しない。 チーム型（実験的）。独立セッションが共有リストで会話する。 価値があるのは「並列化」ではなく「分割の設計」。並列で増えるのは差分の量であって、レビューの免除ではない。
12. DEV SIDE / TO P R Code Change から Pull Request へ /diff /review /rubber-duck 変更を確認 レビューを走らせる 別モデルで再確認 クラウドへ委譲 何が変わったかを 規約・設計観点で 同じモデルの自己レビューに ブランチ作成から 人の目で把握する Agentに点検させる 頼らない Draft PR 作成までを委譲 /remote /delegate ターミナルで始めた作業を、GitHub.com やモバイルから確認・操作・マージする 深夜の対応でも、ノートPCを開かずにスマートフォンから承認だけ返せる。これはOps側で効きました。 どのルートを通っても、合流点は Pull Request。IaCの変更もアプリのコードも、扱いは同じ。
13. OPS SIDE 「作る」だけじゃない — 運用でこそ、CLIが効く 障害調査 ログを横断して仮説を立てる 構成ドリフト IaCと実環境の差分を説明させる @ でログを渡し、MCPで構成を引く。深夜、踏み台の先でも Bicep / Terraform と現状の差を出すだけでなく、 ターミナルだけで一次切り分けまで進む。 「なぜ差分が出たか」まで言語化させる。 手順の資産化 RunbookをSkillにする 定期点検 ヘッドレス実行で夜間に回す 人の頭の中にある手順を、呼び出せる形に変える。 cron や Actions から copilot -p を呼び、 実行の記録も残るので、引き継ぎが楽になる。 点検結果をIssueとして起票させる。 最初は読み取り専用の権限から始める。「調べさせる」だけでも、十分に価値が出ます。
14. WH AT ACTUALLY H AP P ENED やってみてわかったこと Azure Pipelines → GitHub Actions 移行を、Custom Agent に任せてみた Agentが強かったところ 人の判断が必要だったところ YAML構文の機械的な変換 OIDC（フェデレーション認証）の設計 量が多く、単調で、人がやると事故る作業 セキュリティ方針そのものの決定 ステップの対応付けと整理 Secrets と Variables の分類 命名と並び順を揃えてくれる どれが秘匿情報かは、組織の文脈 重複処理の集約 Runner の選定 ACRログインが各所に散っていたのを1箇所に self-hosted か、GitHub-hosted か 実は、ここでいちばん時間を取られた — 準備の4点 Copilot Agents 用 Secret の置き場所 ／ PATが2種類必要 ／ Enterprise側のAI制御設定 ／ .github-private の構成 移行そのものより「前提を整える」ほうが重かった。そしてそこは、Agentの仕事ではない。
15. GUARDRAILS AI Agentの成果物は、そのまま本番に入れない Pull Request Code Review GitHub Actions Automated Test 変更を必ず可視化する 人が意図と設計を確認 ビルドとテストを自動化 回帰を機械的に検出 Security Scan Approval Deploy Gate Secret・脆弱性の検査 責任者による承認 環境ごとの通過条件 Ops側にもゲートを置く 本番環境へのAgentの権限は読み取りから。書き込みや再起動は、人の承認を挟む。実行ログは必ず残す。 速度を上げるほど、ゲートの設計が効いてくる。縛るためではなく、安心して任せるために。
16. CLOSING AIを、開発と運用の一周に参加させる BEFORE AFTER AIにコードを 書かせる AIを開発と運用の 一周に参加させる CLIは、ターミナルとGitHubをつなぐ入口。IDEが開けない場所でも動く 効くのはContextとInstructionの設計。プロンプトの言い回しではない Deployで終わらせない。運用の気づきをIssueに戻して、一周させる このあとのハンズオンで、実際に手を動かしてみましょう。