572 Views
September 29, 26
スライド概要
ゆるよな Gh-CUG #06
https://gh-cug.connpass.com/event/406034/
GitHub Copilot を、IDE の中だけで使っていませんか? このセッションでは、VS Code の Agent Window で Spec Kit を使い、仕様・計画・タスクまで進めます。 そして taskstoissues で Issue にしたところから、GitHub.com の Copilot で Issue を計画し、Copilot cloud agent に実装を任せます。この開発環境の組み方として、管理者設定、cloud agent の実行を VS Code から追う方法、手元と Codespaces と cloud agent で環境をそろえるポイント、そして実際のアプリで Issue から PR までの流れを、順に紹介していきます。
※ 公開後、Spec Kit 最新版(v1.1.3)に合わせて微修正したのでスライドを差し替えました!
FPT ジャパン FPT データ& AI インテグレーション エグゼクティブエバンジェリスト 独立行政法人 国立印刷局デジタル統括アドバイザー兼最高情報セキュリティアドバイザー Micorsoft MVP for Developer Technologies(.NET/Developer Tools) Microsoft エバンジェリスト時代から、Dell、Accenture、Elastic、VMware を経て現職まで一貫して開発者向けに最新技術を啓発。 GPU クラウド技術訴求、AI 駆動開発推進。 政府の仕事は、内閣官房 政府 CIO 補佐官、 デジタル庁 PM を経て、現職を兼務。 AI 駆動開発勉強会主催/AI 駆動開発コンソーシアム副座長 Google Cloud Partner All Certifications Holder 2025
Spec Kit で作成した Issue を GitHub Copilot cloud agent へ - VS Code から離れない開発環境の組み⽅ Shotaro Suzuki Microsoft MVP for Developer Technologies (.NET / Developer Tools) Developer Advocate © 2026, Developer Advocate, LLC.
鈴⽊ 章太郎 X (Twitter) : @shosuz FPT ジャパン エグゼクティブエバンジェリスト 独⽴⾏政法⼈ 国⽴印刷局 デジタル統括アドバイザー兼最⾼情報セキュリティアドバイザー Microsoft MVP for Developer Technologies (.NET/Developer Tools) 合同会社デベロッパーアドボケイト 代表社員チーフアドボケイト Developer Advocate 略歴︓ Microsoft エバンジェリスト時代(2003年)から、Dell、Accenture、Elastic、VMware を 経て現職まで、20年に渡り⼀貫して開発者向けに最新技術を啓発。NVIDIA GPU クラウド 技術訴求、 AI 駆動開発コンサルティングを実施。 AI 駆動開発勉強会主催。 AI 駆動 開発コンソーシアム副座⻑。 政府の仕事は、内閣官房 IT 総合戦略室 政府 CIO 補佐官(併任︓法務省 CIO 補佐官、第4次安倍改造内閣、 2019年4⽉〜)、 デジタル庁 PM(併任︓⾦融庁 デジタル統括アドバイザー、菅内閣、2021年9⽉〜)を経て2024年10⽉より現職を兼務。 AI 駆動開発トレーニング、AI 駆動開発コンサルティング、技術顧問、技術マーケティング ⽀援、クラウドトレーニング、を提供する合同会社デベロッパーアドボケイトを2022年設⽴。 https://shotaro-evangelist.carrd.co / https://www.docswell.com /user/shosuz MCT (Microsoft 認定トレーナー) としてエディフィストラーニング社においてGH-300 コース 担当の他、多くの AI 開発系トレーニング講師を担当。 Google Cloud Partner All Certification Holder 2025 。 Developer Advocate © 2026, Developer Advocate, LLC.
Codex ではじめるエージェンティックコーディング --AI エージェントによる⾃律的システム開発ガイド 9/10 発売 https://amzn.asia/d/0g8bJDp0
アジェンダ Spec Kit で作成した Issue を GitHub Copilot cloud agent に渡すまで 1 役割を分ける Agent Window で考え、cloud agent が作る 2 構成の全体像 Spec Kit で Issue を作成し、GitHub.com へ渡す 3 組み⽅の⼿順 管理者設定から、発注・検証・ゲートまで 4 環境をそろえる どこで何が動くか、DB も devcontainer で Developer Advocate © 2026, Developer Advocate, LLC.
Spec Kit - SDD を補助するツールキット GitHub が公開している無料のオープンソースツール Spec Kit とは よくある誤解 ・GitHub 公式の無料 OSS (github.com/github/spec-kit) ・SDD のワークフローを補助するテンプレート集 ・× 新しい AI モデルではない (Copilot / Claude のまま) ・× 既存ツールから乗り換えるものではない ・コマンド︓基本 6 + 品質ゲート 3(詳細は後述) ・Copilot / Claude Code / Gemini CLI 等で動作 ・× 全部⾃動化するものではない(⼈間レビュー必須) ・× 専⽤ IDE が必要なわけでもない ・リポジトリ初期化コマンド 1 ⾏で導⼊可能 ・○ 既存ツールの上に「思想層」を導⼊する仕組み Spec Kit は SDD の考え⽅を既存ツールの上で使うためのキット 5 Developer Advocate © 2026, Developer Advocate, LLC.
Spec Kit のコマンド⼀式 - 基本 6 + 品質ゲート 3 Issue 化は v1.1 で github 拡張に移った - GitHub に依存する機能をコアから外したため ① ② ③ ④ ⑤ ⑥ 拡張 constitution specify plan tasks implement converge github 原則・制約 仕様(What) 設計(How) 実装単位に分解 実装 残タスクを 追加 Issue 化 /speckit-githubtaskstoissues 品質ゲート 3 - 必要に応じて⼯程の間に⾜す ・clarify - spec の曖昧な箇所を対話で詰める(plan の前。旧 /quizme) ・checklist - 要件の完全性・明確さ・⼀貫性を確かめるチェックリストを作る(plan の後) ・analyze - spec / plan / tasks の整合と網羅を確かめる(tasks の後、implement の前) converge はコードを spec / plan / tasks と照合し、未実装分を tasks.md に追加する(implement で仕上げる) 6 Developer Advocate © 2026, Developer Advocate, LLC.
RevenueCat主催のグローバルイベントで8月1日から9月末まで開催 2か月間、アプリ開発 ストア公開 マネタイズ をオンラインで競う 高額賞金 VC支援 NYC表彰式 他豪華特典。参加資格不問 完全無料 昨年は世界で50,000人以上が参加。アプリ総売上は10億円突破 優勝した「Payout」は、2週間で開発し約500万円の売上を達成 300万ダウンロードを達成するアプリなどソロプレナーが続々誕生
Agentic Commerce アプリ - GearMate 初⼼者向けの楽器を探す → ⽇本語 / 英語で相談して選ぶ → カートで購⼊する 商品を探す (セマンティック検索) ⽇本語 / 英語で相談する (エージェント推薦) カートで購⼊ この画⾯が仕様であり検品の突合先になる Developer Advocate © 2026, Developer Advocate, LLC.
全体像 - Azure 上の⽬標構成(この後 IaC で実現) Azure(構成) iOS アプリ SwiftUI Azure VNet Container Apps .NET 10 / EF Azure SQL Native Vector Developer Advocate © 2026, Developer Advocate, LLC.
作るところから検品まで、途切れずにつながる Spec Kit → GitHub Copilot → .NET → Blender MCP → Skill Spec Kit 仕様を構造化 → • • • • GitHub Copilot 仕様との差分を → レビュー .NET/Azure (Container Apps・SQL) バックエンド API Blender MCP Skill 3D 商品画像を 検品を⾃動化 → → ⽣成 デモ 1 = コード(.NET) デモ 2 = インフラ(IaC) デモ 3 = 3D(Blender) デモ 4 = モバイル(SwiftUI) Developer Advocate © 2026, Developer Advocate, LLC.
通常の環境構築例 - GitHub Copilot / Spec Kit 統⼀構成 GitHub 標準スタック(Spec Kit + Copilot + Actions + PR)で統⼀した例 ① Spec /speckitspecify Copilot Chat → spec.md ② Plan・ Tasks ▶ /speckit- plan /speckittasks tasks.md → Issue(githu b 拡張) ③ 実装 ④ 検証 ⑤ ゲート・承認 ⑥ 来歴・改善 ▶ Issue から実装 ▶ CI + レビュー ▶ CI 通過 + 承 ▶ PR / Issue に + テスト → PR Copilot cloud agent + 要件トレース Actions / Copilot code review 認でマージ branch protection /⼈ 痕跡 + ADR hooks で改善 含意 GitHub 標準スタックで統⼀ - Spec Kit で spec→tasks、PR/CI をゲートに、痕跡は PR/Issue/ADR GitHub Copilot(cloud agent / code review / Actions)+ Spec Kit の標準機能の組み合わせ 参考: Issue はエディタ内で確認・操作(GitHub Copilot App の Canvas / Repository Issues Kanban)- github.com に⾏かず完結 出典: chomado(Qiita, 2026-08) https://qiita.com/chomado/items/e49a97a6c9d707306c83 Developer Advocate © 2026, Developer Advocate, LLC.
▶ デモ動画 - バックエンド⽣成 → xUnit が不合格から合格へ → セマンティック検 索(意味の近さで探す検索)が返る Developer Advocate © 2026, Developer Advocate, LLC.
▶ 録画 - IaC 適⽤ → デプロイ直後の最⼩確認が合格 Developer Advocate © 2026, Developer Advocate, LLC.
Developer Advocate © 2026, Developer Advocate, LLC.
▶ デモ動画 - 3D(Blender build → 検品 → fix) Developer Advocate © 2026, Developer Advocate, LLC.
相談チャットの中⾝ - AI が組み⽴てる Claude が理解と説明 / 実データは検索で取る(でっち上げない) 相談 ⽇本語の質問 Claude 理解 → 条件 OpenAI 埋め込み Azure SQL vector 検索 Claude 推薦理由 候補 商品 + 理由 モデル: Claude Sonnet 5(理解・推薦理由)/ OpenAI text-embedding-3-small(埋め込み) Developer Advocate © 2026, Developer Advocate, LLC.
▶ デモ動画 - SwiftUI が API を呼んで画⾯に出る Developer Advocate © 2026, Developer Advocate, LLC.
役割を分ける - 考えるロールと作るロール ⼈は Agent Window で考えて判断する。実装は Copilot cloud agent に任せる 考える 分解して発注 作る ・要求分析と仕様策定 ・spec → plan → tasks ・Issue を受けて実装 ・設計検討とタスク分解 ・github 拡張で Issue 化 ・テストまで実⾏する ・レビューと採否の判断 ・Issue が実装単位 ・PR を作る ・ここでは実装しない ・tasks まで戻って追える ・⻑時間・⾮同期で動く Agent Window Spec Kit と Issue Copilot cloud agent 要点 実装の単位は Issue 1 件 - 何を頼み、何が返ったかが GitHub に残る Developer Advocate © 2026, Developer Advocate, LLC.
Spec Kit で Issue 作成 - そこから GitHub.com にする構成 Issue を作成するまでは通常の環境構築例と同じ。その先は GitHub.com 上の計画と cloud agent に渡 す Issue 作成まで 境⽬ Issue 作成されて以降 VS Code の Agent Window Issue GitHub.com ・constitution で規約 ・1 タスクが Issue 1 件 ・Projects で計画する ・specify → clarify ・何を・なぜ・完了条件 ・Epic と Feature に整理 ・plan → checklist → tasks ・specs/ はコミット済み ・cloud agent に割り当て ・analyze で整合を確認 ・ここから GitHub.com へ ・レビュー(Codespaces でも ・github 拡張で起票 可能) ・⼈が承認してマージ つなぎ⽬ implement は使わない。github 拡張で起票して GitHub.com へ渡す Developer Advocate © 2026, Developer Advocate, LLC.
(参考) - GitHub Copilot は IDE だけじゃない! yuriemori(Microsoft Japan)さんの Zenn 2026-09-03 / Issue から先はこの記事の流れにも近い 計画する 任せる 確かめる GitHub.com の Copilot Copilot cloud agent レビューと Codespaces ・PRD.md を作り PR に ・Issue に割り当てる ・Copilot code review ・/create-issue で起票 ・View session で追う ・skills と MCP で観点 ・Epic > Feature の階層 ・既定で CodeQL 等の検査 ・Codespaces で動かす ・Projects に登録 ・Playwright MCP も既定 ・Spaces で知識を共有 共通点 依頼からデプロイまでを GitHub 上で⼀貫して追う(IssueOps) 記事︓https://zenn.dev/microsoft/articles/ghcp-cloud-agent-workflow Developer Advocate © 2026, Developer Advocate, LLC.
記事の構成を参考にした新しい構成例 - ⼿順 0〜2 ⼿順は 0〜9。0〜2 で Issue を作るところまで進める ⼿順 0 ポリシー ⼿順 1 Spec Kit ⼿順 2 Issue 化 ・cloud agent は有料プランで ・ specify init <project> ・constitution で規約を決める 使える --integration copilot ・specify → clarify → plan ・Business / Enterprise は ・既定で Skills として⼊る ・checklist → tasks → 管理者がポリシーを有効にする ・specify extension add analyze ・無効なら⼿順 3 で⽌まる github ・github 拡張で起票して⽌める 管理者の設定を確認 specify init で導⼊ Agent Window で進める 分岐点 implement は使わない。github 拡張で起票して実装は Copilot へ渡す Spec Kit の基本 6 = constitution / specify / plan / tasks / implement / converge。 品質ゲート 3 = clarify / checklist / analyze。Issue 化は /speckit-github-taskstoissues Developer Advocate © 2026, Developer Advocate, LLC.
GitHub の管理者設定 - ⼿順 0 の中⾝ cloud agent はライセンスだけでは動かない。Enterprise と Organization で許可する Enterprise Organization リポジトリ AI Controls > Agent Copilot > cloud agent Settings > Copilot ・Cloud agent を有効に ・Repository access で ・レビューで MCP を使う ・code review を有効に 対象リポジトリを許可 既定で有効 ・3rd party agents も同じ ・許可が無いと使えない ・レビュー⽤の環境は (Claude・Codex ⽤) 専⽤の yml で変える 中⾝ ⼿順 0 の管理者設定は Enterprise と Organization の 2 か所 Developer Advocate © 2026, Developer Advocate, LLC.
⼿順 2 の続き - GitHub.com で Issue を計画 github 拡張で作った Issue を GitHub.com の Copilot と Projects で整理する 整理する そろえる 管理する GitHub.com の Copilot .github/ISSUE_TEMPLATE GitHub Projects ・spec.md を⽂脈に渡す ・何を・なぜ・完了条件 ・ボードに登録して管理 ・Issue の作成と更新 ・完了条件は Gherkin で ・sub-issue も⼀度に作る ・Epic と Feature の親⼦ ・エラー・境界も 1 つ以上 ・Spaces で知識を共有 ・Ask モードで下書き修正 ・Test Scope に層を書く ・1 件に 1 ストーリー 要点 Issue の元になる要求⽂書は、Spec Kit で作成した spec.md をそのまま使う Developer Advocate © 2026, Developer Advocate, LLC.
⼿順 3〜5 - 発注・実⾏環境・独⽴した検証 Issue を渡す先とその結果を誰が疑うかを決める 3 発注する 4 環境を固定 5 独⽴に検証 ・assignee に Copilot を指定 ・.github/workflows/ ・PR ごとに Claude で反証 ブランチ・コミット・push まで copilot-setup-steps.yml させる ⾃動で進む ・依存関係の導⼊を書く ・結果を PR コメントへ書き戻す ・追加は PR で @copilot に ・timeout-minutes を書く ・maker と checker を分ける Issue を割り当てる 依頼 毎回同じ⾜場にする checker は別モデル ・証跡は GitHub に残る 両⽴ 証跡は⼀元化し、検証だけ独⽴させる。同じベンダーだけでは反証役がいない 反証役は maker から独⽴させる。環境を固定しないと、失敗の原因を実装に絞れない Developer Advocate © 2026, Developer Advocate, LLC.
⼿順 3 の中⾝ - cloud agent に渡したあと 実⾏中を追う・既定で⼊るものを知る・レビューを⾜す 追う 既定で⼊るもの レビューを⾜す View session cloud agent ⾃⾝に適⽤ Copilot code review ・PR の下書きができる ・Firewall でアクセス制御 ・Copilot をレビュアーに ・session で動きを確認 ・CodeQL で脆弱性を検査 ・instructions で指⽰ ・途中からコメントで指⽰ ・シークレットも検査 ・skills で観点を⾜す ・依存の脆弱性も検査 ・MCP で⼀次情報を参照 ・MCP: GitHub・Playwright ・Skill の使⽤はログで ・別リポジトリは要設定 要点 Copilot code review に加えて、⼿順 5 で別のモデル(Claude)にも反証させる Developer Advocate © 2026, Developer Advocate, LLC.
⼿順 5 の中⾝ - checker を別モデルにする
maker は Copilot で checker は Claude。結果は PR コメントとして GitHub に残る
.github/workflows/adversarial-review.yml
on:
pull_request:
types: [opened, synchronize]
jobs:
review:
runs-on: ubuntu-latest
permissions: { contents: read, pull-requests: write, id-token: write }
steps:
- uses: actions/checkout@v6
- uses: anthropics/claude-code-action@v1
# 公式 action(MIT ライセンス)
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
prompt: |
REPO: ${{ github.repository }}
PR NUMBER: ${{ github.event.pull_request.number }}
この差分に課題がある前提で反証しろ。良い点は不要。
深刻度と根拠を付けろ。根拠は実⾏できる形で⽰せ。
gh pr comment で PR に書き戻せ。
claude_args: --allowedTools "Bash(gh pr comment:*),Bash(gh pr diff:*)"
前提 公式の anthropics/claude-code-action@v1 を使う - claude の導⼊は不要
反証の指⽰は、良い点は求めず、深刻度と根拠を出させる。採否は⼈が決める
Developer Advocate © 2026, Developer Advocate, LLC.
⼿順 6〜7 - 決定を残し、ゲートを掛ける GitHub に証跡を残す - 「何をしたか」だけでなく「なぜそうしたか」も残す 6 決定を残す 6 設計判断 7 ゲート ・.github/ISSUE_TEMPLATE/ ・docs/adr/NNNN-題.md ・テスト / lint / 型検査 ・implementation.yml ・Issue から番号で参照する ・adversarial-review も ・何を作るか / なぜこの形か ・constitution に規約として 必須に ・完了条件は機械で判定できる形 書く ・承認 1 名以上 ・採らなかった案も書く ・「なぜ」が GitHub に残る ・main への直接 push ・却下した案も必ず残す を禁⽌ Issue テンプレート ADR に書く branch protection 原則 CI が通り、⼈が承認しなければマージできない状態にする AI との対話で決めたことはチャットに流れて消える。決定は Issue と ADR に着地させる 採否そのものが、次に同じ判断をするときの材料になる Developer Advocate © 2026, Developer Advocate, LLC.
⼿順 8〜9 - spec を残して改訂する・並列の上限 spec は捨てずに改訂し plan と tasks は作り直す。並列の数はレビューできる量で決める 8 spec を残す 9 上限を決める 最初の⼀歩 ・specs/ をコミットする ・⼀度に割り当てるのは 3 本 ・⼿順 0 のポリシー確認 ・spec は改訂して使い続ける ・Issue が 50 個でも 3 本ずつ ・⼿順 1 のリポジトリ初期化 ・設計書があるなら正を決める ・1 ⽇に⾒られる PR 数が上限 ・動いてから 5 以降を⾜す ・A spec が正 / B 設計書が正 ・並列を上げるほど⾃分が詰まる ・先に⾜すと原因が分からない どの環境でも同じ 律速はレビュー 順序を守る 残す specs/ はどこでもコミットする。設計書が別に要るなら A か B を先に決める Developer Advocate © 2026, Developer Advocate, LLC.
どこで何が動くか - ローカルとクラウドの分担 推論はどちらから呼んでもリモート。変わるのはファイルの置き場と実⾏のきっかけ ローカル(Win / Mac) GitHub(クラウド) Agent Window 考える / 採否を決める Issue を渡す PR の確認 VS Code の PR 拡張で⾒る Copilot cloud agent Actions runner Issue / PR / ADR 実装してテストして PR ビルドと検証 証跡が残る GitHub が動かす 毎回作って捨てる VM ここが記録の置き場 PR が返る Codespaces(任意) 使う場合は git の作業コピーがローカルから Codespaces に移る。中⾝も拡張もリモート側で動く 要点 ローカルに残るのは、考えることと PR の確認だけ 推論はローカルから呼んでも GitHub から呼んでもリモート。ローカルの性能は使っていない Developer Advocate © 2026, Developer Advocate, LLC.
GitHub Copilot App - GitHub を⾒に⾏かない Issue から PR のマージまでアプリの中で進む - GitHub.com は計画のときだけ ⾒に⾏かない マージまで Web に残るもの ・Issue と PR が My work に ・差分にコメントを書き、戻って ・ボードで計画を整理する所は ⼀覧で並ぶ Review を出す GitHub.com に残る ・セクションは All / Active / ・レビューの指摘は、Fix を押すと ・Epic と Feature の親⼦も Review requests / Done から エージェントが直す GitHub.com で整理する 選ぶ ・CI が不合格なら、Fix failing ・App のポリシーは、Copilot CLI ・Issue を開いて New session checks を押す とは別に管理者が許可する を押すと、セッションが始まる ・Agent merge が、詰まっている ・セッションを動かす場所は、ローカル ・セッションは Issue の⽂脈を読み 所を直してマージまで進める とクラウドから選べる My work に集まる 直して閉じるまで 計画と管理者の設定 込んだ状態で始まる 要点 ⽇々の往復は App の中で閉じる - GitHub.com に⾏くのは計画のボードだけ 出典: GitHub Docs「Managing issues and pull requests with the GitHub Copilot app https://docs.github.com/en/copilot/how-tos/github-copilot-app/managing-issues-and-pull-requests Developer Advocate © 2026, Developer Advocate, LLC.
モデルの選択に HydraFusion 追加 - VS Code と Copilot App 開発者は進め⽅を選び、どのモデルを使うかは GitHub が決める - 2026/09/30 提供開始 Single 質問 モデル 1 つ 回答 1 つのモデルがそのまま実装する Cascade 質問 軽いモデルが 下書き 品質を 判定 強いモデルへ 回答 A が 1 回直す 回答 軽いモデルが下書きし、通らなければ強いモデルへ上げる Critique • • 別系統 質問 のBが 批評 別系統のモデルが批評し、最初のモデルが 1 回直す モデル A が 下書き 使い⽅ VS Code 1.140 以降で chat.copilot.hydraFusion.enabled を on にし、モデルの⼀覧(Auto の下)から選ぶ。App は Settings > Experimental。企業は管理者が許可する 注意 研究プレビューで SLA は無い。サブエージェントは起動せず、破棄された下書きがファイルに加えた変更は元に戻らない 要点 Auto はモデルを選ぶ。HydraFusion は型を選び、1 ターンで複数のモデルを動かす 出典: GitHub Changelog「HydraFusion in VS Code and the GitHub Copilot app」2026/09/30 / GitHub Docs(early access)「HydraFusion」 https://docs.github.com/early-access/copilot/hydrafusion Developer Advocate © 2026, Developer Advocate, LLC.
どこでモデルを切り替えるか - ローカルとクラウド 開発者が⼯程ごとに分ける。1 ⼯程の中は HydraFusion が決める。クラウドは Issue 1 件ごと ローカル VS Code / Copilot App / CLI spec plan tasks implement のループ ・⼯程ごと = Workflow の step、または .github/agents/ の指⽰役と実⾏役(director / executor) ・1 ⼯程の中 = HydraFusion を選ぶ(型は前の⾴)。実⾏役から上位モデルは呼べない クラウド GitHub (Issue から先) Issue cloud agent が 実装 PR 別モデルで反証 ⼈が承認 ・Issue 1 件ごとにモデルを選ぶ = Auto と各社のモデルから選ぶ。HydraFusion は⼀覧に無い ・役割を分けるなら Issue を分けて発注し、PR で別のモデルに反証させる(adversarial-review) • • ⾃社で設計するのは⼯程の分け⽅。1 ⼯程の中の切り替えは GitHub に任せる形になる HydraFusion はサブエージェントを起動しないので、指⽰役と実⾏役の代わりにはならない 出典: GitHub Docs(early access)「HydraFusion」/ GitHub Docs「Changing the AI model(cloud agent)」2026/10/02 確認 https://docs.github.com/early-access/copilot/hydrafusion ※ cloud agent のモデル⼀覧に HydraFusion は無い(Auto と各社のモデル) Developer Advocate © 2026, Developer Advocate, LLC.
(参考) 3 つの VM の違い - 使い捨てか残るか Actions runner・cloud agent・Codespaces に何を任せるかを決めて使い分ける Actions runner cloud agent Codespaces 使い捨て GitHub が動かす ⾃分で開く開発 VM ・PR などのきっかけで起動 ・Issue の割り当てで動く ・開いている間だけ課⾦ ・終わったら捨てる ・リポジトリを触って PR ・⽌めてもディスクは残る ・Python は最初から⼊っている ・runner の設定は不要 ・作業コピーの置き場になる ・残るのは artifact とログ ・環境固定だけ yml で指定 ・⻑期の保管には使わない 違い • runner と cloud agent は毎回使い捨てで、残るのはブランチ・PR・ログ • Codespaces は⾃分で開いて閉じるまで残る Developer Advocate © 2026, Developer Advocate, LLC.
DB も devcontainer で⽤意する ローカル or Codespaces / cloud agent とで同じ環境にする 起きること そろえる cloud agent 側 接続先がずれる .devcontainer copilot-setup-steps.yml ・ローカルは localhost ・DB も compose で起動 ・同じ依存を⼊れる ・Codespaces はサービス名 ・接続先は環境変数で渡す ・DB が要るなら準備も書く ・テストは DB 無しで通る ・秘密は secrets に置く ・⼿順 4 と同じファイル ・起動して初めて気づく ・作成後に test を 1 回 注意 DB に接続しないテストは、接続先の設定が間違っていても通ってしまう Developer Advocate © 2026, Developer Advocate, LLC.
終わりに - Issue を境に役割を分ける VS Code + Spec Kit から離れずに GitHub.com 側の計画と cloud agent につなぐ Issue で分ける 別モデルで検証 なぜを残す ・Issue まではローカル ・Copilot code review ・Issue に何を・なぜ ・spec.md をそのまま使う ・Claude にも反証させる ・完了条件は Gherkin で ・implement は使わない ・採否は⼈が決める ・設計判断は ADR に ・実装は cloud agent へ ・承認してからマージ ・なぜが GitHub に残る Spec Kit と GitHub.com Copilot と Claude Issue と ADR 要点 Issue の元は Spec Kit の spec.md - 並列の数はレビューできる量で決める Developer Advocate © 2026, Developer Advocate, LLC.
Thank you for your attention! Developer Advocate © 2026, Developer Advocate, LLC.