---
title: Dev Days | Nagoya, Japan GitHubCopilotAppの概要資料
tags:  #githubcopilot  
author: [Hiroki Nomura](https://www.docswell.com/user/shirokuma)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/4JMYMP52JW.jpg?width=480
description: Dev Days | Nagoya, Japan GitHubCopilotAppの概要資料 by Hiroki Nomura
published: October 10, 26
canonical: https://www.docswell.com/s/shirokuma/KPR361-github-copilot-app-overview
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/4JMYMP52JW.jpg)

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


# Page. 2

![Page Image](https://bcdn.docswell.com/page/PJR9V13579.jpg)

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


# Page. 3

![Page Image](https://bcdn.docswell.com/page/PEXQZY4XJX.jpg)

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


# Page. 4

![Page Image](https://bcdn.docswell.com/page/3EK983Z9ED.jpg)

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


# Page. 5

![Page Image](https://bcdn.docswell.com/page/L73W2GD975.jpg)

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


# Page. 6

![Page Image](https://bcdn.docswell.com/page/87DKZ1P8JG.jpg)

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


# Page. 7

![Page Image](https://bcdn.docswell.com/page/VJPKDQNWE8.jpg)

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


# Page. 8

![Page Image](https://bcdn.docswell.com/page/2EVV15K9EQ.jpg)

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


# Page. 9

![Page Image](https://bcdn.docswell.com/page/57GL26Q4EL.jpg)

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


# Page. 10

![Page Image](https://bcdn.docswell.com/page/4EQYP4KRJP.jpg)

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


# Page. 11

![Page Image](https://bcdn.docswell.com/page/KJ4WYQPQ71.jpg)

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


# Page. 12

![Page Image](https://bcdn.docswell.com/page/LE1Y6P9L7G.jpg)

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


# Page. 13

![Page Image](https://bcdn.docswell.com/page/GEWGW2QQJ2.jpg)

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


# Page. 14

![Page Image](https://bcdn.docswell.com/page/47ZL5DW3J3.jpg)

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


# Page. 15

![Page Image](https://bcdn.docswell.com/page/YJ6W91GZJV.jpg)

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


# Page. 16

![Page Image](https://bcdn.docswell.com/page/GJ5MN4V9J4.jpg)

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


# Page. 17

![Page Image](https://bcdn.docswell.com/page/LE3W2GD2E5.jpg)

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


# Page. 18

![Page Image](https://bcdn.docswell.com/page/8EDKZ1P67G.jpg)

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


# Page. 19

![Page Image](https://bcdn.docswell.com/page/V7PKDQ1ZJ8.jpg)

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


# Page. 20

![Page Image](https://bcdn.docswell.com/page/2JVV15YMJQ.jpg)

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


# Page. 21

![Page Image](https://bcdn.docswell.com/page/5EGL269XJL.jpg)

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


# Page. 22

![Page Image](https://bcdn.docswell.com/page/4JQYP4W57P.jpg)

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


