Dev Days | Nagoya, Japan GitHubCopilotAppの概要資料

Dev Days | Nagoya, Japan 14:45–15:15 GitHub Copilot app 概要説明 IssueからPR・マージまで、ひとつのアプリで進める開発体験 初めて使う人向け ／ このあと15:15からハンズオン 協賛：なごあず（JAZUG名古屋支部）

AGENDA この30分でお伝えすること 1 Copilot appとは何か エージェントファーストへ移る開発スタイル 2 開発プロセス全体のサポート Issueドリブンで、着手からマージまでを支える 3 画面を見ながら主要機能 並列セッション、3つのモード、差分、実行、PR、Agent Merge 4 他のCopilotとの使い分け Copilot CLI、VS Code Chat、cloud agent 5 開発の流れ（まとめ） Issue選定 → マージまでの7ステップ 6 ハンズオンの準備 15:15〜17:00に体験する内容 GitHub Copilot app概要 2

WHAT IS IT GitHub Copilot appとは 複数のAIエージェントを指揮するためのエージェントファーストな開発環境 エージェントファースト ローカルで動く GitHubネイティブ 人は目的・制約・判断を担い、エージェン Windows、macOS、Linux向けです。 リポジトリ、ブランチ、Issue、PRをアプリ トが調査・実装・検証を進めます。 Copilot CLIを基盤に、手元のコードと 内で直接扱えます。 開発ツールを扱います。 リポジトリごとに複数のセッションを動かし、IssueからPR・マージまでを人が監督します。 出典：docs.github.com「GitHub Copilot app」 3

AGENT-FIRST 開発の中心が「コードを書く画面」から変わる エディター中心 エージェントファースト 作業単位 作業単位 開いているファイルとコード リポジトリと、達成したいタスク 開始点 エディターでコードを開く → 開始点 Issue・PR・プロンプト 進め方 進め方 人が編集し、AIにその場で相談 複数セッションを並列に指揮・レビュー 人の役割は、コードをすべて手で書くことから、意図と制約を伝え、結果を検証して判断することへ広がります。 Copilot appは、この働き方に沿って設計されたUIです 4

SCREEN TOUR 画面ツアー：Home 1 1 Pull requests / Issues GitHubの作業をアプリ内で 2 Automations / Customize 定型作業の自動化と、設定のカスタマイ ズ 3 Projects 登録したリポジトリと、その配下のセッショ ン 4 入力欄 指示を入力します。 / でコマンド、 # で 2 3 4 5 Issueを参照できます 5 画面は2026年10月時点のアプリ モード・モデル・worktree 入力欄の下で選ぶ 5

CONCEPT Issueドリブンで開発する Issueに「やりたいこと」を書くと、それがそのままエージェントへの指示になります。 1 Issueに書く 背景・期待する動作・受 け入れ条件 ▶ 2 3 4 セッション開始 ▶ エージェントが実装 ▶ 人がレビュー Issueから ワンクリックで 専用ブランチで 作業 差分と動作を確認 5 ▶ PR → マージ Issueが自動で クローズ チームで共有できる 後から検索して振り返れる 書き方が大事 Issueはチーム全員が読める「指示書」に なぜその変更をしたのかは、Issueを見れ Issueにタスク内容をしっかりまとめるほ なります。 ば分かります。 ど、結果が安定します。 参考：JAZUG for Women #12（2026/09/29）発表資料 6

START Issueから、そのままセッションを始める 1 Issue一覧 Assigned to me / Created by me / Mentioning me 2 New session 選んだIssueから作業を始めます。 New 2 1 3 session in repository… や Chat も選べる 3 Issueの本文 アプリを離れずに内容を確認できます 開始点はIssueだけではない Issue、PR、プロンプト、過去のセッションから始め られます。コードを開かなくても着手できます。 ※ 画像中のIssueは筆者の個人プロジェクト 7

PARALLEL セッションを並列に走らせる：worktreeで分離 セッションA：Issue #12 worktree + ブランチA 1 3 リポジトリ main セッションB：Issue #37 worktree + ブランチB 2 セッションC：別リポジトリ worktree + ブランチC 作業フォルダーをセッションごとに分けるため、作業中のフ ァイルを直接上書きし合いません。一時停止と再開もで きます。 1専用ブランチ（from main）／2変更状況・使用量 ／3 git worktree list にセッション分のworktree が並ぶ ただし、同じファイルや仕様を変更すれば、統合時のマージ競合・重複実装・設計の不整合は起こり得ます。Issueの境界を分け、PRを小さくレビューしてテストしま す。 worktreeは作業場所を分離する仕組み。変更内容の衝突まで防ぐものではありません 8

PARALLEL 複数のプロジェクトとセッションを一覧で管理 プロジェクト単位で整理 リポジトリを登録すると、その下にセッションが並びます。 並行して進められる あるセッションが実装している間に、別のセッションで別のIssueを進められます。 後から戻れる 終わったセッションも履歴として残り、再開や参照ができます。 ※ 1人が複数のエージェントを「指揮」するイメージ 9

MODES 3つのモードで「任せ具合」を選ぶ Interactive Step-by-step 一緒に進めるモードです。1ステップずつ確認しながら進めます。迷う作業や探索に向いています。 Plan Plan first 先に計画を出させ、人が承認してから実行します。大きめの機能や、影響範囲が読めない変更 に向いています。 入力欄左下のメニューで切り替える Autopilot End-to-end 中断せず最後まで自律的に実行します。要件が明確な作業に向いています。 おすすめの組み合わせは、Planで方針を固めてからAutopilotで実装することです。実行できるコマンドと変更範囲を確認してから 任せます。 出典：docs.github.com ／ 画面で確認 10

MODELS モデルも選べる：Autoか手動か 迷ったら Autoにしておく 難しい課題だけ手動 で強いモデルへ Effortで「考える深さ」 を調整 Auto：最適化の方針（Efficiency / Balance / Intelligence）を選ぶ 手動：モデル、Effort、Context windowを指定 表示されるモデル名は時期・環境によって変わります。当日の画面を優先してください。 画面で確認 11

PLAN 計画と進捗が見える：Planタブ 1 エージェントがタスクに分解して順に進めます 2 完了したタスクには緑のチェックが付き、今どこまで進んだかが一目で 分かります 3 うまくいかなかった項目も見えるので、人が判断して次の指示を出しま す 画像は実行中のセッションのPlanタブ（Plan / Terminal / Changesはタブで切り替え） ※ 計画の承認操作はハンズオンで体験します 12

REVIEW 差分をアプリ内でレビューする Changesタブ 追加（緑）と削除（赤）が行単位で見えます。ファイルごとの増 減件数も一覧で確認できます。 人の役割はここ エージェントが書いたコードを読んで判断します。気になる点があれ ば、会話で修正を依頼します。 VS Codeも開ける じっくり編集したいときは、ボタンからVS Codeを開けます。 ※ 画像は筆者の個人プロジェクトの差分 13

RUN & VERIFY 実行して、アプリの中で動作確認 1 3 1 2 実行／停止 起動コマンドは package.json から取得 4 2 Create PR そのままPRへ 3 統合ブラウザ 開発サーバーを表示 4 Pick & Polish 画面の要素を選んで修正 を依頼 コードを書く、動かす、見る、直すという流れが、ウィンドウを切り替えずに回ります。 画面で確認 ／ Pick & Polishの説明は参考資料より 14

PULL REQUEST PRの作成：説明文まで自動生成 1 変更内容と検証結果を、エージェントが説明文にまとめます 2 Fixes #47 でIssueと紐づき、マージ時にIssueも閉じます 3 Check statusでCIの結果を確認できます PRの画面そのものも、アプリのタブ（ PR #48 ）として開きます。ブラウザに戻る必 要はありません。 ※ 画像は筆者の個人プロジェクトのPR 15

REVIEW COMMENTS レビュー指摘への対応も、セッションの中で ① Copilotがレビュー 指摘を重要度つきでまとめます（Mediumなど）。 ② 「Fix unresolved comments」で修正 未解決の指摘をエージェントに修正させます。 ③ 解決済み（Resolved）になる ※ ブラウザを開かずにレビュー対応が完結 16

AGENT MERGE Agent Merge：マージまでの面倒を任せる スイッチを入れると、PRのライフサイクルを自動で追いかけます。 1 Address reviews：レビュー指摘に対応 2 Fix CI failures：失敗したCIを修正 3 Resolve conflicts：コンフリクトを解消 4 Merge pull request：条件が揃ったらマージ どこまで任せるかは項目ごとに選べます。CIが通っても、変更内容と動作を確認して最終判断するのは人です。 出典：docs.github.com ／ 画面で確認 17

EXTEND 自分のチーム向けに育てられる カスタム指示 MCP（外部ツール連携） コーディング規約やドキュメント標準を指示 Playwright MCPなどを追加すると、エー として定義します。全体用とリポジトリ単 ジェントが実際のブラウザーを操作して動作 位で設定できます。 を検証できます。 スキル Automation 品質チェックなど、決まった手順をスキルと 繰り返し発生する作業を自動化します。 して持たせ、作業の検証に使います。 ハンズオンでは要約の実行を試します。 ハンズオンのレッスン3〜5, 7, 8で体験します ／ キャンバス例：awesome-copilotのaccessibility-kanban キャンバス：Issueのカンバンのような共有の作業画面 です。エージェントと人の双方が編集でき、 /createcanvas で作成を依頼できます。 18

HOW TO CHOOSE 他のCopilotとの使い分け Copilot app Copilot CLI VS Code Chat cloud agent 主な場所 デスクトップアプリ ターミナル エディター（VS Code） GitHubのクラウド 強み リポジトリ単位で複数のエージェントを指揮。 Issue／PR連携、ローカル実行、並列セッシ ョン ターミナルで軽快に。スクリプト や自動化に組み込みやすい コードを開いて編集しな がら、その場で相談 手元の環境を使わ ず、非同期で任せる 向く場面 複数のIssueを並行して進めたい／レビューか らマージまで通したい CLI中心の作業、リモート環 境 1ファイルずつ丁寧に作 る、細かい編集 手を離して任せたい 定型的な作業 共通点：中で動くエージェントの実行基盤は共通です。どれかが正解というわけではなく、場面で選びます。 この表は公式の比較ではなく、共通基盤・GUIの有無・並列セッションなどの事実から整理した目安です。 出典：GitHub Blog（共通ランタイム）ほか 19

WORKFLOW 開発の流れ：Issueからマージまで 1 Issue選定 Issues一覧から選 ぶ 2 ▶ セッション開始 New session 3 ▶ モード選択 Plan → Autopilot 4 ▶ 5 差分レビュー Changesタブ ▶ 実行して確認 統合ブラウザ 6 ▶ PR作成 Create PR 7 ▶ Agent Merge 指摘対応・CI・マ ージ 人がやること エージェントに任せること 何をやるか決める（Issue）／ 作業の境界を分ける／ 計画を承 調査・実装・テスト／PR説明文／ レビュー対応／CI修正／ コンフ 認する／ 差分と動作を確認する／ 最終判断 リクト解消 ハンズオンの演習2〜6がこの流れに対応 20

HANDS-ON 15:15からのハンズオンで体験すること # レッスン 体験すること 0 前提条件 Node.jsの準備と、演習用リポジトリ（Tailspin Toys）のコピー作成 1 アプリのインストール 導入、サインイン、リポジトリ接続、ワークスペースの確認 2 最初のエージェントセッション 星評価の実装 → 最初のPR → マージ 3 カスタム指示 Issueに基づくTSDoc標準の追加 4 Autopilotで構築 Plan / Autopilotでフィルター機能を実装、スキルで検証 5 Playwright MCP MCPサーバーを追加し、ブラウザーで検証 6 Agent Merge PRの修正とマージを任せる 7・8 キャンバス／振り返り 共有キャンバスで計画、Automationで自動化 事前にアプリのインストールが必要です。ローカルのファイル変更やコマンド実行を任せるため、対象リポジトリと指示内容を確認してください。AIクレジットの残量も 事前に確認し、画面が教材と違うときは講師へ。 教材：content/ja/app（Dev Days） 21

まとめ Copilot appは、複数のAIエージェントを指揮するための開発環境です リポジトリ／Issue・PR起点でタスクを始め、ローカルで実装・検証します worktreeで並列化できますが、統合時の競合や不整合は人が管理します 人は意図・制約・レビュー・最終判断を担います では、実際に触ってみましょう。