Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
ChatGPT製:GitHub Copilotの紹介(デモ)
Search
Yuta Matsumura
September 28, 2026
Technology
30
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
ChatGPT製:GitHub Copilotの紹介(デモ)
ChatGPTのGPT-6 Astraを使って、自分のスライドマスターに準拠したデモ用のプレゼンテーションです。
Yuta Matsumura
September 28, 2026
More Decks by Yuta Matsumura
See All by Yuta Matsumura
MCPをつなげて作る組織横断のAIエージェント基盤(の開発工程)
tsubakimoto_s
0
250
Microsoft MVP プログラムを紹介するから目指す人増えてくれ
tsubakimoto_s
0
210
MCPをつなげて作る組織横断のAIエージェント基盤
tsubakimoto_s
0
880
github/awesome-copilotのPHPのエージェントスキルを読む
tsubakimoto_s
0
98
エージェントスキルを作って自分のインプットに役立てよう v2
tsubakimoto_s
0
71
エージェントスキルを作って自分のインプットに役立てよう
tsubakimoto_s
0
890
やさしいとこから始めるGitHubリポジトリのセキュリティ
tsubakimoto_s
4
2.6k
GitHub Copilot CLI で Azure Portal to Bicep
tsubakimoto_s
0
500
使って学ぼう MCP (と GitHub Codespaces)
tsubakimoto_s
1
400
Other Decks in Technology
See All in Technology
AI臭い文章とは何なのか
nasuvitz
18
21k
なぜ「決定性」が 決定的に重要なのか? Durable Execution 基盤の数理的理解 #serverlessjp / ServerlessDays Tokyo 2026
ytaka23
4
1.3k
いちAWSエンジニアのAI活用を振り返る #devio2026 / devio osaka 2026 kawahara
masahirokawahara
1
220
ADKで始める業務改善 - AIエージェント開発時の考えと設計
harappa80
2
300
エージェントはローカル、検証はMicroVM — Lambda MicroVMsでつくるServerless CI
fujioka6789
3
840
AIエージェントの権限管理 3: Agentic RAG の Fine grained access control 編
ren8k
1
290
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
16
120k
手を動かして実感する、Kiro が変える開発体験
inariku
0
400
Apache Iceberg が拓く AI 時代のオープンレイクハウス
tomtanaka
0
130
「どのログを見ればいい?」 から始めた サーバーレス障害解析
y_waka1
1
160
Goodbye ShellScript, Hello File-based App
shunsock
0
1.2k
AI Native Platform Engineering 〜PlatformとAgileで“作る速さ”を“価値”へ〜
uya116
0
310
Featured
See All Featured
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
Joys of Absence: A Defence of Solitary Play
codingconduct
1
530
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
128
56k
How to Talk to Developers About Accessibility
jct
2
560
The AI Search Optimization Roadmap by Aleyda Solis
aleyda
1
6.2k
Prompt Engineering for Job Search
mfonobong
0
460
Building a Modern Day E-commerce SEO Strategy
aleyda
45
9.2k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
141
35k
Code Review Best Practice
trishagee
74
20k
世界の人気アプリ100個を分析して見えたペイウォール設計の心得
akihiro_kokubo
PRO
74
42k
Un-Boring Meetings
codingconduct
0
430
Side Projects
sachag
456
43k
Transcript
GitHub Copilotの紹介 若手エンジニアのための AIペアプログラミング入門 © 2026 Yuta Matsumura. 1
提案はAI、判断はエンジニア GitHub Copilotは、コードの提案や対話を通じて開発を支援するAI。 あなた Copilot あなた 意図を伝える 案をつくる 検証して採用 目的・対象コード・制約を渡す
コードや説明の候補を返す 差分を読み、テストで確かめる 「正解をもらう」より、考えるための下書きに使う。 基本概念の紹介。回答の正確性・安全性は、利用者が確認する。 © 2026 Yuta Matsumura. 2
補完・Chat・Agentを使い分ける まずは補完とChatで慣れ、複数ファイルの変更は範囲を決めて任せる。 使い方 向いている作業 人が確認すること コード補完 入力中のコードを補う 意図・型・境界条件 Chat コードの説明/修正案/テスト案
回答の前提・根拠 Agent 複数の変更や作業を進める 差分・実行内容・権限 「質問する」から始めて、「変更を任せる」へ。 機能名・利用可否はIDE、契約、組織設定で異なる。最新の画面で確認する。 © 2026 Yuta Matsumura. 3
質問には目的・文脈・条件を添える 依頼を具体化すると、回答を評価する基準も明確になる。 曖昧な依頼 そのまま使える依頼例 「テストを書いて」 目的:clamp関数の単体テストを作成 文脈:選択したPython関数が対象 条件:pytestを使用、実装は変更しない 期待:範囲内・範囲外・不正な上下限 出力:テストコードと各ケースの意図
対象も期待動作も不明。 提案の良し悪しを判断しにくい。 依頼例は説明用。対象コードを選択・添付し、必要な情報だけを渡す。 © 2026 Yuta Matsumura. 4
小さな関数で生成と検証を体験する 実習例:数値を下限〜上限に収めるclamp関数。先に期待動作を決める。 実装の一例(Python) 自分で確かめる def clamp(value, lower, upper): if lower
> upper: raise ValueError( "invalid bounds" ) return max(lower, min(value, upper)) clamp(5, 0, 10) → 5 clamp(-1, 0, 10) → 0 clamp(12, 0, 10) → 10 下限 > 上限 → ValueError 追加で考える 上下限ちょうど/上下限が同じ 非数値やNaNはどう扱う? 説明用サンプル。Copilotの実際の出力ではない。対応する入力の型・範囲は別途定義する。 © 2026 Yuta Matsumura. 5
生成コードは4つの観点で確認する 動いたことと、採用してよいことは同じではない。 確認する観点 採用前に自分へ問いかける 正しさ 仕様・境界値・異常系をテストしたか? 安全性 秘密情報、権限、入力値を適切に扱うか? 保守性 不要な依存や変更がなく、チーム規約に合うか?
理解 なぜ動くか、変更理由を自分の言葉で説明できるか? 説明できないコードは、そのまま取り込まない。 推奨チェックリスト。通常のレビュー・CI・セキュリティ確認を置き換えない。 © 2026 Yuta Matsumura. 6
まずは承認済み環境で使い始める VS Codeを例に、組織のルールを確認してから小さなタスクで試す。 01 利用ルールを確認 会社の利用可否・契約を確認。 秘密鍵や顧客データは渡さない。 02 IDEでサインイン GitHub公式のCopilot機能を設定。
利用するアカウントを確認する。 03 小さな変更で試す 関数の説明 → テスト案 → 差分確認。 テスト実行後に採用を判断する。 Agentを使うときは、実行コマンドと変更範囲も確認する。 導入手順の概要。UI・利用上限・契約条件は変わるため、利用時に公式情報を確認する。 © 2026 Yuta Matsumura. 7
次のタスクで、小さく試そう 目標は、生成量ではなく「理解して採用できること」。 1 理解する 既存の関数を選び、処理と注意点を説明させる。 2 試す テスト案を依頼し、実行して結果を確認する。 3 振り返る
採用・修正・却下した理由を、チームに共有する。 AIに任せる範囲を広げる前に、検証する習慣をつくる。 © 2026 Yuta Matsumura. 8