Agentic Coding 実践ワークショップ

某所での研修資料です。初学者向け・3～4時間を想定しています。
出張も可能ですので、ご依頼お待ちしております。

Transcript

1. Agentic Coding 実践ワークショップ (公開版) 2026/01/21
2. 講師紹介 渡邉 洋平(＠watany) • 所属：NTTテクノクロス株式会社 ◦ 「AWS 500 APN Certification Distinction」 ◦ AWS Ambassadors(2024〜) • 対外：JAWS-UG東京(AWSコミュニティ) 運営 • 「なんでAWSの⼈を連れてきたんですか？」 https://jawsug.connpass.com/event/316451/ 2
3. 講師紹介 Coding Agent 関連の活動 - 2025’s Most Viewed Speaker Deck Presentations：4位 - CodeZine(翔泳社)寄稿 - Developers Boost 2025(U35向けデ ブサミ) ：ベストスピーカー3位 - ※今回の内容も含んだ書籍：執筆中 3
4. カリキュラム 1. Vibe Coding 体験 - GitHub Codespaces, GitHub Copilot(Agent) 2. Agentic Coding 体験 - Agents.md, Agent Skillsなど 3. 仕様駆動開発 - Spec Kit Appendix. Planと仕様駆動開発の関係 4
5. １． Vibe Coding 体験 5
6. Vibe Codingとは Andrej Karpathy（OpenAI共同創業者）がXで提唱した概念 (2025/2) https://x.com/karpathy/status/1886192184808149383 要約 > 「vibe coding（雰囲気コーディング）」 と呼んでいる新しいタイプのコーディン グをしている。 > 雰囲気に完全に身を任せ、指数関数 的な進化を受け入れ、もはやコードの 存在すら意識しないやり方だ。 6
7. つまりこういうこと 7
8. Vibe Coding =「コーディングレスのプログラミング」 - 狭義Vibe Coding (Andrej Karpathy提唱) - キーボードレス・音声での指示、全てを承認 - 広義Vibe Coding - Agentに委ねてプロセス(How)に介入しない - 生成されたコードは読まない - 要求を指示し続ければバグはいつか直る 8 Vibe Codingとは
9. キーボードは捨てないけど、概ねこんな気持ちで 9
10. この「魔法」の正体は？ ⇒ Coding Agent 10
11. 2024年の世界観：LLM Chat 〇〇〇の機能を実装して 設計書を見せてください ＜添付ファイル＞ ありがとうございます。 <コード> テストの結果動きません。エラーは～ 失礼しました<修正済コード> ありがとう、動くコードです 11
12. Coding Agent - 承認あり 〇〇〇の機能を実装して 設計書を読んでもいいですか？ いいよ これがコードです。書き出していいですか？ いいよ <コマンド>このコマンドでテストしていい？ いいよ テストが通ったよ。完成！ 12
13. Coding Agent - 承認なし 〇〇〇の機能を実装して 設計書を読みます これがコードです。書き出します <コマンド>このコマンドでテストします テストが通ったよ。完成！ いいよ いいよ いいよ 13
14. Coding Agentはコーディングだけの話ではない (和訳) > 私は以前から、Claude Codeは開発者ツールに偽装 した「汎用エージェント」だと主張してきました。コードの実 行やターミナルコマンドの実行で達成できるあらゆるコン ピュータータスクを支援してくれます…それは、それらを 使いこなす知識さえあれば、ほとんどあらゆることをカ バーします！ First impressions of Claude Cowork, Anthropic’s general agent https://simonwillison.net/2026/Jan/12/claude-cowork/ Simon Willison Djangoの共同開発者 14
15. 説明よりも、まずは体感しましょう 15
16. 今回の⽬標：⼦供向け「ハノイの塔ゲーム」を作る 16
17. ハンズオンで主に利⽤するもの - 動作環境： GitHub Codespaces - AIエージェント：GitHub Copilot (Agent) 17
18. ハンズオンで主に利⽤するもの - 動作環境： GitHub Codespaces - AIエージェント：GitHub Copilot (Agent) 18
19. GitHub Codespaces - ブラウザからアクセスできるク ラウドベースの開発環境 - VS Code(Local)、 CLIでも - GitHubとのインテグレーション - リポジトリページから直接起 動が可能 - GitHubへの認証やリポジト リ連携の追加設定が簡易 GitHub Codespaces とは https://docs.github.com/ja/codespaces/about-codespaces/what-are- codespaces 19
20. GitHub Codespaces - 起動 1. リポジトリ作成 GitHubの右上にある自分のアイコンを クリックし、「Repositories」を選択 20
21. GitHub Codespaces - 起動 1. リポジトリ作成 - 遷移先で緑色の「New」ボタンをク リック。 - 右図を参考に入力し「Create Repository」ボタンを押す。 - Branch名 ：2026-0121-AgenticCoding - Choose visibility：Public - .gitignore：Node - Licence：MIT 21
22. GitHub Codespaces - 起動 2. ブランチ作成 - 作成したブランチの「Main」をクリック - 検索窓に「001」など一意なブランチ名をクリッ ク - Create Branch <ブランチ名>～をクリック 22
23. GitHub Codespaces - 起動 3. 起動 右の「Code」ボタン →「Codespace」タブ →未作成：「＋」ボタン →作成済：「...」ボタン 23
24. GitHub Codespaces - 起動 起動！ (概ね、このような画面になります) 24
25. ハンズオンで主に利⽤するもの - 動作環境： GitHub Codespaces - AIエージェント：GitHub Copilot (Agent) 25
26. ハンズオンで主に利⽤するもの - 動作環境： GitHub Codespaces - AIエージェント：GitHub Copilot (Agent) 26
27. GitHub Copilot (Agent) VS Code上で動作する“エージェント型”のCopilot機能群 - 自然言語の指示を受けて、複数ステップ（複数ファイル変更・ テスト実行・修正反復など）を自律的に進める - 注意：類似サービス - GitHub Copilot (Agent) ：「同期型・ローカル実行」 - 類似：Cline, Cursor, Kiro - GitHub Copilot Coding Agent：「非同期型・リモート実行」 - 類似：Devin, Jules, Claude Code on Web 27
28. GitHub Copilot (Agent) - 起動 0. 前提 - 以降、画面右の以下の画面からの操作が 多くなります。 - 狭いと感じる方はウインドウを 左に広げても良いです。 28
29. GitHub Copilot (Agent) - 起動 1. 事前設定 モード：「Agent」 モデル：「Claude Haiku 4.5」 ※モデルを選択できない場合はVS Code Extentionか ら「GitHub Copilot」をインストール 29
30. ここまでのおさらい - 環境が整いました。 - 動作環境： GitHub Codespaces - AIエージェント：GitHub Copilot (Agent) - いよいよバイブコーディングの始まりです。 30
31. Vibe Codingのはじまり - プロンプトを入力しましょう ハノイの塔を小学生に伝えるための Webアプリを作ってください - Vibe Codingなのであまり深く確認 せず「Allow」「保持」ボタンをクリック して進めましょう。 31
32. Agentが動く様⼦ 32
33. Agentが動く様⼦ - 開発が完了した旨メッセージがあれ ばアプリを起動しましょう - 右のようにAgentから手順の案 内がなければ、チャットで訪ね ましょう。 - 下の「ブラウザーで開く」を 押すとブラウザで確認できます。 33
34. Vibe流テクニック: 1. Auto Approve Allowボタン横の「∨」から画像を参考に「⾃動全承認モード」 34
35. Vibe流テクニック: 2. 最⼤リクエスト数の設定 セッション中の停⽌を防ぐため、設定から最⼤リクエスト数を設定 35
36. アプリケーションの作例 36
37. アプリケーションの不備を直してもらう例 37
38. 機能完成時 - これでいいと感じたらCommit しましょう。 - 右図のようにIDEのUIでも、 Agentにお願いしても良い - ※以降Commitタイミングは 記載しません。機能開発後に随時コ ミットを行ってください。 38
39. Vibe Coding練習 - 「ハノイの塔アプリ」に機能を追加しましょう。 - 追加機能 - 1. ハノイの塔ゲームをクリアできないお友達がいます。Autoモー ドを作ってください。 - 2. 円盤の接地時に大きなエフェクトを付けたい。アメリカンコミック のようなデフォルメされた大きなもの。 - 3. ストーリーモードを作りたい。小学生向けで面白い、ワクワクす るような冒険の物語。 - 4. タイムアタック機能を作りたいです。DBに保存してお友達とラン キングで遊べるようにしてください。 39
40. 例：Autoモード 40
41. 例：エフェクト 41
42. 例：ストーリーモード 42
43. 例：ストーリーモード 43
44. 例：タイムアタック 44
45. まとめ - Vibe Codingについて理解できる - Vibe Codingに使った環境・エージェントについて理解できる - GitHub Codespaces, GitHub Copilot (Agent) - Vibe Codingの進め方について理解できる - 指示、承認 - コミット - 追加指示、修正依頼 45
46. 2. Agentic Coding 体験 46
47. AWS re:Invent 2025 Keynote抜粋 (和訳)「Vibe Codingは良いものです。ただし、何が構築さ れているかに細心の注意を払う場合に限り。IDEでレバー を引けば何か良いものができるだろう、なんてことはでき ません。」 「それはソフトウェアエンジニアリングではなく、ギャンブル です。」 Werner Vogels Hands Out Newspapers at His Final Re:Invent Keynote. The Man Who Built the Cloud Isn't Done Teaching. https://www.implicator.ai/werner-vogels-hands-out-newspapers-at-his-likely-final-re-invent-the-man-who-built-the-cloud-isnt-done-teaching/ Dr. Werner Vogels, VP & CTO at Amazon.com 47
48. 運の介在するゲームにおいて、実⼒の強弱は存在する https://www.irasutoya.com/2017/07/blog-post_91.html https://www.irasutoya.com/2017/05/blog-post_84.html https://www.irasutoya.com/2016/06/blog-post_992.html 48
49. 「運の介在するゲーム」 リスクの⾼い⾏動を避け、期待値 の⾼い⾏動をとり、勝率を⾼める ”運ゲー”のグラデーション 「レバーを引くギャンブル」 プレイヤーの⾏動が、結果の確率 分布を変えない https://www.irasutoya.com/2015/06/blog-post_689.html 49
50. コーディングエージェントを「レバーを引くだけ」にしない - エージェント固有のベストプラクティス - リスクの高い行動を避け、期待値の高い行動をとる - エンジニアリングにおける、既存のベストプラクティス - SDLC, TDD, DevOps, … ⇒ 「エージェントによる新しいコーディング」 ≒ ゲームの勝ち越し方 ＋ SWEのベストプラクティス Vibe Codingを越えるには 50
51. Vibe Coding ⇒ Agentic Coding 51
52. Agent ＝”tools in a loop” Context Engineering https://blog.langchain.com/context-engineering-for-agents/ 52
53. Vibe Codingというループ ①要求(プロンプト) ②要求に対し最もそれら しい仮説のもと、ツール を呼び出す ③ツールの実行結果を LLM受 け取り、要求と結果のギャップ を理解。ギャップに対し最もそ れらしい～(略) ④LLMが要求を満たしたと判 断するまで②③(Coding)の ループを続ける 53
54. Vibe Codingの課題 - 要求と出力結果のギャップ - コードが「動く」と「動かない」の間に「動くけど気になる」が沢山ある - 成果物に「Explainability(説明可能性)」が十分にあるか - 人間というボトルネック - Agentの速度感において、ボトルネックは人間のレビュー工程 - 品質の合意が不十分だと人間のチェック回数・時間が増加 - Step By StepでAgentを承認すると確実で安全だが、遅い。 54
55. 一般的なソフトウェアエンジニアリング ＝ 悲観的なAgent運用 ソフトウェアエンジニアリング 55 https://x.com/kumagi/status/2012447802836779306
56. ”Agentが活⽤されればVibe Coding”という派閥もある 本研修におけるAgentic Codingの定義 56 広義Vibe Coding Agentを利⽤した開発 楽観的な運⽤ 悲観的な運⽤ Vibe Coding Agentic Coding
57. Agentic Codingとは 「反Vibe Coding」としての、Agentと共同するスタイルの開発 > Agentに委ねてプロセス(How)に介⼊しない - ⇔ チームのプロセスでAgentに開発させる > ⽣成されたコードは読まない - ⇔ エージェントの⽣成物もメンバと同様にレビュー > 要求を指⽰し続ければバグはいつか直る - ⇔ エージェントと共にバグの根拠を探索する 57
58. 決定的なことはなるべく静的なものに置き換える Human AI Agent AI Workflow System Static Dynamic 58
59. Agentic Coding 要は「エージェントと普通の開発をする」 - 様々なベストプラクティスがあるが、この辺りを抑えると良い 1. ガードレール 2. 品質ゲート 3. カスタム指⽰ 4. プラグイン‧拡張 5. Planモード 59
60. Agentic Codingの基本 1. ガードレール 2. 品質ゲート 3. カスタム指示 4. プラグイン・拡張 5. Planモード 60
61. Agentic Coding - 1. ガードレール - おさらい：Agentのボトルネックは人間のレビュー工程 - エージェントに安心して委ねられるほどループが高速で回る - 安心してエージェントに委ねるには - ファイルが消えたらどうしよう：バージョン管理システム - ファイルが壊されたら／権限昇格されたら：環境分離 61
62. ハンズオン - 1. ガードレール ハンズオン：実施済 - 実は既にVibe Codingで実践している - バージョン管理システム：Git (GitHub) - 環境分離：WebIDE (GitHub Codespaces) ※バージョン管理システムはLLMの学習量や、Agentの 並列実行なども考慮し「Git」が好ましい。 62
63. Agentic Codingの基本 1. ガードレール 2. 品質ゲート 3. カスタム指示 4. プラグイン・拡張 5. Planモード 63
64. Agentic Coding - 2. 品質ゲート 開発で「レビュー以前」の品質ゲートはあればあるほど良い(SHOULD)と されていた。 - 広義の静的解析：Type, Lint, Format - 実行時の確認：Test(unit/integration/e2e), Runtime Checks - ゲート：Pre-commit Hooks、CI/CD 64
65. Agentic Coding - 2. 品質ゲート AIエージェントに委任する場合、品質ゲートは必須(MUST) 65
66. 品質ゲートはSHOULDからMUSTへ - 実際の開発では「SHOULD」をやらない理由は沢山ある - 「”CI/CD”をやりたいけど、セットアップする時間がない」 - 「自動テストを採用すべきだけど、テストケースを書く時間が」 - 短期間で実装するCoding Agentに設定させれば「MUST」にできる - 適切に設定するほど、フィードバックループが自動で回る 66
67. ハンズオン - 2. 品質ゲート 前提： ※ Vibe Codingでの手順の復習です - 「002」など一意なブランチ名で、新規ブランチを作成 - 新規のGitHub Codespacesを起動する 67
68. ハンズオン - 2. 品質ゲート 1．以下のプロンプトをコピーして Copilot Agentに依頼してください。 — React + Vite + TypeScriptのbootstrapリポジトリを作成してください。 要件: - Node.js v24 (.nvmrc) - React 19 + Vite 6 - TypeScript 厳密モード - Biome (linter/formatter) - Vitest(Test) - npm scriptsは dev, build, typecheck, lint, lint:fix, test, test:coverage を用意。 68
69. ハンズオン - 2. 品質ゲート 2. 以下のコマンドを実行して設定が完了したことを確認します。 $ npm install $ npm run test ※動かない場合は「実行したコマンド」と「出力されたエラーメッセージ」をコ ピーし、Agentへ追加入力して解決を依頼します。 69
70. 備考：Todo ツール 備考：画像(左)の「～1/8」辺りをクリックすると、Todoツールで タスクリストでの管理状況が確認できます。 70
71. Agentic Codingの基本 1. ガードレール 2. 品質ゲート 3. カスタム指⽰ 4. プラグイン‧拡張 5. Planモード 71
72. Agentic Coding - 3. カスタム指⽰ - プロンプトは⼤まかに2つに分けられる - ユーザプロンプト - システムプロンプト 72
73. Coding Agentが意識するシステムプロンプト - Coding Agentが意識するシステムプロンプトは主に以下の2つ - 組み込みのプロンプト - エージェント側の内部実装として記載 - カスタム指⽰ファイル - 次項で説明 73
74. カスタム指⽰ファイル - 「プロジェクト固有の知識」や「ルール」を記載する - = エージェント⽤のREADMEファイル - ⻑期記憶としても表現される - ⼀般的Tips - 不要な内容は書かず、記述は最⼩に留める - 否定形を避ける - 役割付与、品質指定をしない - e.g. あなたは◦◦です〜、最⾼品質の〜 74
75. GitHub Copilot (Agent)対応の指⽰ファイル タスクの作業での GitHub Copilot の使用に関するベスト プラクティス https://docs.github.com/ja/enterprise-cloud@latest/copilot/tutorials/coding-agent/get-the-best-results 75
76. GitHub Copilot (Agent)対応の指⽰ファイル タスクの作業での GitHub Copilot の使用に関するベスト プラクティス https://docs.github.com/ja/enterprise-cloud@latest/copilot/tutorials/coding-agent/get-the-best-results ツール固有の形式 3rd Party 対応 共通規格 76
77. AGENTS.md - ”カスタム指⽰”の共通規格 - Claude Codeは⾮採⽤ - 規約 - Markdown形式 - 配置場所 - プロジェクトルート - 各フォルダ - 競合時は最も近いものを読込 Agents.md https://agents.md/ 77
78. AGENTS.md - 記載イメージ - Setup〜：各種コマンド - Code style：コーディング規約 - 常に使うものを書く - 特定のジョブ‧ワークフローで のみ使うものは、後述の 「プラグイン‧拡張」で Agents.md https://agents.md/ 78
79. ハンズオン - 3. カスタム指⽰ 1. AGENTS.mdファイルの準備 $ touch AGENTS.md 2. AGENTS.mdファイルの記載 左のタブからファイル (AGENTS.md)をクリックし、サン プルのルールを書きこむ — ## 共通ルール - 語尾に必ず⾳符を付ける 79
80. ハンズオン - 3. カスタム指⽰ 3. AGENTS.mdファイルが機能していることを確認 80
81. ハンズオン - 3. カスタム指⽰ 4. 開発に機能するルールを書き込む(1/2) — ## TDDサイクル 各機能は以下のサイクルで実装します。 1. Red: テストを書く（失敗する） 2. Green: 最⼩限の実装でテストを通す 3. Refactor: コードを改善する ## イテレーション単位 - 機能を最⼩単位に分割し、各イテレーションで1つの機能を完成させます。 - 各イテレーションでbuild, test, lintなどを⼀通りパスしたことを確認し、コミット。 81
82. ハンズオン - 3. カスタム指⽰ 4. 開発に機能するルールを書き込む(2/2) — ## Tidy First? (Kent Beck) 機能変更の前に、まずコードを整理（tidy）するかを検討します。 原則: - 構造的変更と機能的変更を分離する: tidyingは別コミットで⾏う - ⼩さく整理してから変更する: ⼤きなリファクタリングより、⼩さな整理を積み重ねる - 読みやすさを優先: 次の開発者（未来の⾃分を含む）のために整理する 82
83. ハンズオン - 3. カスタム指⽰ ※4.のルールは時間がかかるので ハンズオン5で同時に確認します。 - 期待する動き - ハンズオン2の資材に従って React + Viteで動く - TDD, あるいはテストファース トで動く - 利⽤するモデルの性能上、単 に「テストを忘れない」程度 の動きをする(右図) 83
84. Appendix. カスタム指⽰に何を書くか - 「これさえ書けば良い」という内容はなく、プロジェクトに最 適なプロンプトを考える必要があります。 - 今回は以下を意図して記載しました - 開発ガイドラインのうち、品質ゲートでは検知できない観点 ‧作業プロセス - TDD、イテレーション単位 - コーディングスタイルのうち、品質ゲートで検知できない観 点 - Tidy First - プロジェクト‧企業固有のルールやポリシー(未記⼊) 84
85. Appendix. カスタム指⽰に何を書くか - 「Generate Agent Instructions」 をクリックすれば、指⽰ファイル を⾃動⽣成できます。 - リポジトリの状況を記載すること は⼤切ですが、更新に追従できて いなかったり、過剰な記載は逆効 果に働きます。 - ※後述の「Context Engineering」と関連 85
86. Agentic Codingの基本 1. ガードレール 2. 品質ゲート 3. カスタム指⽰ 4. プラグイン‧拡張 5. Planモード 86
87. Agentic Coding - 4. プラグイン‧拡張 「◦◦の観点でレビューをして」など定期的に利⽤するプロンプト をプラグイン‧拡張として扱うことができる - カスタムスラッシュコマンド - 定型プロンプトの呼び出し、ショートカット - カスタムエージェント(Sub Agent) - サブプロセスへタスクを委譲、独⽴したエージェント - Agent Skills - 必要な時に呼び出す専⾨知識のパッケージ - 本⽂/参考⽂献/ツール/アセット 87
88. Agentic Coding - 4. プラグイン‧拡張 これらの疑問は「Context Engineering」を理解することで解消され ます。 - なぜスラッシュコマンドの内容を「カスタム指⽰ファイル」に 書かないのか？ - なぜカスタムエージェントに分離する必要があるのか？ - なぜSkillsは「必要な時だけ」読み込まれるのか？ 88
89. Context Engineering 89
90. LLMが参照できる範囲 - Context：プロンプト + 外部情報 - Context Window：LLMの 理解できるトークンの総量 - つまり、LLMとの「会話」 において、総トークン数が Context Window以内であ る必要がある Context Engineering https://blog.langchain.com/context-engineering-for-agents/ 90
91. Contextを巡る問題 - Lost in the Middle "Lost in the Middle: How Language Models Use Long Contexts." https://aclanthology.org/2024.tacl-1.9.pdf Promptの最初と最後の情報に影響される ≒ 中間の情報が⽋損する 91
92. Contextを巡る問題 - Multi-Turn Conversation LLMs Get Lost in Multi-Turn Conversation https://arxiv.org/abs/2505.06120?ref=cline.ghost.io 会話のターンが嵩むと、Contextが⽋損する 92
93. Context Engineering 「LLMという関数」の⼊⼒ / 出⼒管理 = Context Engineering 12-Factor Agents -3. Own your context window https://github.com/humanlayer/12-factor-agents/blob/main/content/factor-03-own-your-context-window.md 93
94. Context Engineering コンテキストを書く / 選ぶ / 縮める / 分ける ための技術 Context Engineering https://blog.langchain.com/context-engineering-for-agents/ 94
95. Context Engineeringの理解でわかること > なぜスラッシュコマンドの内容を「カスタム指⽰ファイル」に書かないのか？ - コマンドを利⽤しない時に「コンテキストを分離」したい > なぜカスタムエージェントに分離する必要があるのか？ - メインの処理と「コンテキストを分離」したい > なぜSkillsは「必要な時だけ」読み込まれるのか？ - 不必要な場合には「コンテキストを分離」したい 95
96. ハンズオン - 4. プラグイン‧拡張 プラグイン‧拡張は「コンテキストを分離する」ための機能 - 必要な時だけ使う、不要な時は切り離す 本ハンズオンでは「Agent Skills」を取り扱います - カスタムスラッシュコマンド → 後述の「Spec-Kit」にて - カスタムエージェント(Sub Agent) → 後述の「Planモード」にて - Agent Skills → 本ハンズオン 96
97. Agent Skills ”専⾨知識”の共通規格 - Agentが判断して利⽤する 「振舞い⽅ + 知識 + ⼿段(ツール)」 - ≒ オンボーディングガイド - 3段階の読取り⽅で、Context Windowを汚さず知識を得られる - パッケージとしてマーケットプレ イスで扱うこともできる 2025/10 Anthropicが Claude用に発表 https://claude.com/blog/skills 2025/12 Agent Skillsとし て規格化 https://agentskills.io/home 97
98. Agent Skills 注)2026/1現在では、あまり枯れた技術 ではありません - 配置場所がAgent毎にバラつく のは、シンボリックリンクで 対応しましょう - 使い⽅通りに整備しても、 Skillsが⾃動で発動しない場合 もあります https://x.com/flaviocopes/status/2011861756260266234 98
99. Agent Skills - Progressive Disclosure（段階的開⽰） 1: メタデータ Agentが常に読み 込む領域 Equipping agents for the real world with Agent Skills https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills 2: 本⽂ メタデータで選んだ Skillsの利⽤時に、 全⽂を読み込む 3: リファレンス Skills本⽂から 参照される別⽂書 を必要に応じて動 的に読み込む 99
100. Skillsを⽤いるAgentの設定値‧マシン構成 Equipping agents for the real world with Agent Skills https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills 100
101. ハンズオン - 4. プラグイン‧拡張 1. Skillsのセットアップ $ mkdir -p .github/skills/ping 2. Skills設定の有効化 - GitHub Copilotの⻭⾞アイコンをク リックし「チャット設定」を選択 - 検索窓で「use」と⼊⼒し、 「Chat: Use Agent Skills」にチェック する 101
102. ハンズオン - 4. プラグイン‧拡張 3. Skillsの作成 - コマンドで「SKILL.md」ファイルを作成 $ touch .github/skills/ping/SKILL.md - ファイルにSkillの内容を書き込む --- name: ping-skill description: pingと⾔われたときに使います。 --- # Echo Skill このスキルは、「ping」のみをテキスト⼊⼒された場 合、「pong」をそのまま返します。 102
103. ハンズオン - 4. プラグイン‧拡張 4. Skillsの確認 - 「ping」と話しかけて「pong」が 返ってくる - 思考中の過程を確認し 「ping-skill」を認識した上での回 答であること 103
104. Agentic Codingの基本 1. ガードレール 2. 品質ゲート 3. カスタム指⽰ 4. プラグイン‧拡張 5. Planモード 104
105. Agentic Coding - 5. Planモード Plan ＝ 実装したがりのAgentに 「まず考えさせる」機能 - コードベース全体を理解 - ファイルを1⾏も触らせない - 要件理解と戦略作成に専念 Plan & Act https://docs.cline.bot/features/plan-and-act 105
106. Planモードのプロンプト - プロンプトの共通点 - 計画中の実装の禁⽌、ユーザー側での承認がゴール - プロンプトの具体例 - GitHub Copilot https://github.com/microsoft/vscode-copilot-chat/blob/main/assets/agents/Plan.agent.md - Cline https://github.com/cline/cline/blob/main/src/core/prompts/system-prompt/components/act_vs_pla n_mode.ts - OpenCode https://github.com/anomalyco/opencode/blob/09ff3b9bb925903b36aa35fec25394133a42cf6d/packages/opencode/src/s ession/prompt/plan.txt 106
107. GitHub Copilot (Agent) の場合 > 一方で、Plan モードはカスタムエージェント の一種として実装されています。 > したがって、Plan.agent.md の内容を 参考にして、Plan モードの動作をカスタマイ ズすることも非常に有効です。 GitHub Copilot Chat の Plan "モード" をコードレベルで理解する https://zenn.dev/openjny/articles/43e010c65faa9a 107
108. ハンズオン - 5. Planモード GitHub Copilot(Agent)のPlan モードはカスタムエージェントです。 - カスタムスラッシュコマンド → 後述の「Spec-Kit」にて - カスタムエージェント(Sub Agent) → 本ハンズオン - Agent Skills → 解説済(4. プラグイン‧拡張) 108
109. ハンズオン - 5. Planモード 1. 事前設定 モード：「Plan」 モデル：「Claude Haiku 4.5」 ※モデルを選択できない場合はVS Code Extention から「GitHub Copilot」をインストール 109
110. ハンズオン - 5. Planモード 2. Vibe Codingと同様のプロンプトで Planモードのまま、プロンプトを⼊⼒しましょう — ハノイの塔を⼩学⽣に伝えるためのWebアプリを作っ てください — 110
111. ハンズオン - 5. Planモード 具体的な実装計画がはじまる 111
112. ハンズオン - 5. Planモード Agentからの質問に答えながら計画を進める 112
113. ハンズオン - 5. Planモード 注意) 実装権限が欲しいと要求があれば「Plan」→「Agent」 113
114. ハンズオン - 5. Planモード タスクリストに従い、実装が完了する様⼦ 114
115. ハンズオン - 5. Planモード ⼀度で完成形にならなくても、「Plan」で修正依頼しながら⼀緒に直しましょう 115
116. まとめ - Vibe Codingの課題について理解できる - Agentとの開発(Agentic Coding)に必要な知識を理解できる - ガードレール - 品質ゲート - カスタム指⽰(AGENTS.md) - プラグイン‧拡張(Agent Skills) - Planモード 116
117. 3. 仕様駆動開発 117
118. Specification(仕様書)について > A specification is a kind of (version controlled, human-readable) super prompt. — 仕様書とは、一種の（バージョン 管理され、人間が読める）スー パープロンプトです。 Kiro and the future of AI spec-driven software development https://kiro.dev/blog/kiro-and-the-future-of-software-development/ 118
119. Specification(仕様書)について > That’s why we’re rethinking specifications — not as static documents, but as living, executable artifacts that evolve with the project. — 仕様書を静的な⽂書ではなく、 プロジェクトと共に進化する⽣ きた実⾏可能な成果物として捉 え直しています。 Spec-driven development with AI: Get started with a new open source toolkit https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/ 119
120. 仕様駆動開発 (Spec-Driven Development, SDD) 「実装前に仕様(書)を作る」というVibe Coding以後のレトロニム - 2025/7、AWSがIDE「Kiro」の発表と共に提唱 - レトロニム：新しい事物の誕⽣後、既存の事物を区別する ため「後から」つくられた⾔葉 - 例) 裸眼、固定電話、オンプレミス - 実装前に仕様を書くのは「当たり前」だったため、 従来は名前がなかった。 Kiro https://kiro.dev/ 120
121. 具体例：Vibe vs Spec Vibe Specs: Vibe Coding That Actually Works https://lukebechtel.com/blog/vibe-speccing 121
122. 事例：KDDIアジャイル開発センター 122 KDDI系が仕様駆動開発を採用、 AIで業務は「設計8割・開発2割」に https://xtech.nikkei.com/atcl/nxt/column/18/00001/11413/
123. 「仕様駆動開発」の実装例 仕様駆動開発の理想と現実、そして向き合い方 https://speakerdeck.com/gotalab555/shi-yang-qu-dong-kai-fa-noli-xiang-toxian-shi-s ositexiang-kihe-ifang?slide=17 123
124. 「仕様駆動開発」の実装例 仕様駆動開発の理想と現実、そして向き合い方 https://speakerdeck.com/gotalab555/shi-yang-qu-dong-kai-fa-noli-xiang-toxian-shi-s ositexiang-kihe-ifang?slide=17 124
125. Spec-Kit Spec-Kit https://github.com/github/spec-kit GitHubからOSSとして公開された、 仕様駆動開発を「外付け」で⽀援するKit - 各Agentのカスタムスラッシュ コマンドとして動作するPrompt & Scriptを配置する。 - 基本コマンド - /speckit.specify ：要件定義 - /speckit.plan ：機能設計 - /speckit.tasks ：実施計画 125
126. Spec-Kit - install # uv インストール $ pipx install uv # Spec-Kit (Specify CLI）をインストール $ uv tool install specify-cli --from git+https://github.com/github/spec-kit.git # 既存プロジェクトをSpec Kit化（--ai : Copilot⽤テンプレ） $ specify init . --ai copilot (コマンド⼊⼒を求められたら、 y, sh (POSIX Shell (bash/zsh)) ) 126
127. 導⼊すると「speckit.〇〇」コマンドが表⽰されます 127
128. ハンズオン 以下のコマンドを参考に使ってみてください。 - /speckit.specify “ハノイの塔を⼩学⽣に伝えるためのWebア プリを作ってください。既存のファイルは無視して⼀から 「./3_spec/」配下にプロジェクトを配置してほしい。” - /speckit.plan “技術構成はReact+Vite, Tailwindcss, Vitest, Biomeを使って。” - /speckit.tasks (追加プロンプト無し) - /speckit.implement (追加プロンプト無し) 128
129. SDDはウォーターフォールの復権か？ What Is An Agent? https://www.aihero.dev/what-is-an-agent Q. Single Source of Truth（SSOT）が コードからドキュメントへ先祖返りし ているように感じる。SDDはウォー ターフォールの復権なのか？ A. No。 開発⼯程の話ではない。 タスク単位で、要件‧仕様の定義→設 計→タスクリストという「AIワークフ ロー」へエージェントの⾏動をワーク フローへ収束させることが⽬的。 129
130. まとめ - 仕様駆動開発の基本的な背景がわかる - 仕様駆動開発の実装(Spec Kit)がわかる - 実際に使ってみる - 以降の研修で、試してみてください！ 130
131. 「エンジニアは不要になりますか？」 131
132. IT産業における「機械化⾰命」 現職のSE・PGの人はAIの発達で職がなくなると思っていますか？ https://jp.quora.com/%E7%8F%BE%E8%81%B7%E3%81%AESE-PG%E3%81%AE%E4%BA%BA%E3%81%AFAI%E3%81%AE%E7%99%BA%E9%81%94%E3%81%A7%E8%81%B7%E3%81% 8C%E3%81%AA%E3%81%8F%E3%81%AA%E3%82%8B%E3%81%A8%E6%80%9D%E3%81%A3%E3%81%A6%E3%81%84%E3%81%BE%E3%81%99/answers/1477743830562528 132
133. AIの成果物を「削る」という新たな専⾨性 Waterfall, Agile, And AI: The Evolution Of Development https://programmerhumor.io/agile-memes/waterfall-agile-and-ai-the-evolution-of-development-fgst 133
134. 来年のことを⾔えば⿁が笑う(2025/4) - AI 2027：元OpenAIの Daniel Kokotajloらが公開 した、AIの社会的影響に関 する予測シナリオ - 2027/4に超⼈レベルのコー ダー(superhuman coder) 相当の低コスト‧複数コ ピーで⾼速開発をするAIシ ステムが現れるとされた 134 AI 2027 https://ai-2027.com/
135. 来年のことを⾔えば⿁が笑う(2025/12) 本職の研究者でも完全な予測は難しい - Automatic Coder(コーディング完全⾃動化)： 2027年→2031年 135 https://x.com/eli_lifland/status/2007182080162279798
136. 「終末論」に惑わされずに、今のAIに向き合う - 「シンギュラリティ到達後はエンジニアが不要になるか？」と 定期的に話題になるが、肯定も否定もしようがない - Coding Agentを触ると圧倒的な⾺⼒を理解できる - 「エンジニアが必要だ」とエンジニアが⾔うのは単なるポジ ショントークなのかもしれない - 当⾯はAIを疑いながら信じていく(⼆重思考) - 今の延⻑線からの、地続きの未来を着実に予測する - 今回の研修に留まらず、積極的に利⽤し予測の精度を⾼めよう - GitHub、Codespacesは個⼈でも無料枠がある - Coding Agentも安価なものは⾒つけられる 136
137. おわり 137
138. Appendix. Spec is “Plan” ? 138
139. Spec is “Plan” ? 実装前に仕様(書)を作るSDDとは、前述の「プランモード」と 何が違うのか？ - どちらも「反Vibe Coding」の変奏である。 - エージェントの即時実装を抑制し、順番付きのタスクリス トを指針とすることで、発散せずに⽬的を達成できる。 - Plan ：実装前に「検討」 - Spec ：実装前に「仕様」 139
140. PlanとSpecが統合された例 - Cline v3.25.0〜：Plan (+ /deep-planning) - ユーザへ不明点を質問 - ask_followup_question tool - 仕様書相当をファイル保存 - ⼩さな依頼でも仕様書を執筆 し、実⾏速度が遅いデメリット もある - 計画後、セッションを切り替えて Actモードへ移⾏する 140 v3.2.0〜：Plan - 「要件整理と⽅針策定」 に集中する読み取り専⽤ フェーズ - 計画が固まったら、Act モードへ移⾏する。開発 者がゲートとなる
141. PlanとSpecが統合された例 - Claude Code v1.0.33?：Plan - 「要件整理と⽅針策定」 に集中する 読み取り専⽤フェーズ - 計画が固まったら、Act モードへ移⾏する。 開発者がゲートとなる v2.0.51〜：Plan + Spec - ユーザに不明点を質問 - interactive question tool - 仕様書相当をファイル保存 - ⼩さな依頼でも仕様書を 執筆し、実⾏速度が遅い デメリットもある - 専⽤のSubAgentで計画 - Context分離 141
142. “仕様駆動開発”へどう向き合うか 2026/1 現在で、SpecとPlanの境界は曖昧になりつつある。 - Spec ≒ 以下の総称 - 計画(Plan) / ドキュメント化 / Taskリスト駆動 / (Context分離) - まず落ち着いてすべきことを明確にする (計画‧Plan) - 仕様書‧設計書化し、コンテキストから切り離す (ドキュメント化) - 順番付きリストを北極星として順にタスクをこなす (Taskリスト駆動) 142
143. “仕様駆動開発”のアレンジ例 講師が最近やっているClaude Code on the Webでの進め⽅ - セッション1：要件定義‧設計‧順序付きタスクリスト作成 - コミット：設計書、タスクリスト - セッション2：実施プランの確認‧実装‧試験パス確認 - コミット：コード‧テスト‧ドキュメント(更新) - セッション3： - 実装状況の検証(ドキュメント- コード) - レビュー(セキュリティ‧性能...) 143
144. - ”仕様駆動開発”という翻訳の 字⾯が強すぎて真っ当に⾒える - ⽋点も含めた理解が必要 - 従来のPlanモードより作業 ⼯程が多く開発速度が低下 - ドキュメントが膨れ易く、 メンテナンス性に課題 “仕様駆動開発”は万能ではない 144
145. “仕様駆動開発”のドキュメントの扱い “仕様駆動開発”のSpecファイル管理について 1. 保存‧継続管理 - Kiroなどのプロダクトでは推奨 - プロダクトに依存するドキュメント体系をとることに注意 - or 独⾃ドキュメントとSpecファイルの⼆重管理 - コードを含め、⼀貫性が保てるか？ 2. 削除‧移動 - タスクリスト⽣成のインプットと割り切って、使い捨てる - Gitの削除ログに残っていればいい 145
146. Spec実装のパターン 1. Spec-first(仕様優先): まずspecを書き、 開発に使う（ただしタスク完了後、 specを継続利⽤する前提ではない） 2. Spec-anchored(仕様アンカー): タスク 完了後もspecを保持し、将来の変更‧ 保守でもspecを更新し続ける 3. Spec-as-source(仕様がソース): ⻑期的 にspecがオリジンで、⼈はコードを直 接編集しない ⼤量のファイルとの向き合い⽅ 146 Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html
147. ⼤量のファイルとの向き合い⽅ 前述の寄稿の結び >(翻訳) 特に、⼤量のファイルを作成するような複雑なアプロー チの場合、ドイツ語の複合語「Verschlimmbesserung」を思わず にはいられません。「私たちは何かを良くしようとして、悪化さ せているのではないか？」 147 Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html
148. 開発ドキュメントが増えるのは「良いこと？」 - 仕様駆動開発、特にSpec Kitで作成したドキュメントは ⽂章量が過剰な傾向にある - For Agent：コンテキストの浪費 - For Human：レビュー負荷 - “⻑い⼿紙となってしまいました。短くする時間がなかった ためです。” - パスカル - 不⾜を埋めることは必須だが、⽂章量が多いほど良い わけではない - ⽂章が制約となり、⾃由度‧創造性とのトレードオフ になる 148
149. Spec と Plan についての講師⾒解 - 2026/1 時点 - Plan: 計画とTodoリストによる開発ワークフロー作成 - 結果的にVibe相当の委ね⽅をするにせよ、実⾏を推奨 - Spec: Planより詳細なドキュメントによる、Todoリスト(AIワー クフロー)への収束 - Plan-fileとSpec-fileは記載粒度、作業の具体性が異なる - ”仕様駆動開発”: 仕様Spec-fileが 「Source of Truth」 - 単なるAgentの⾏動制限だけでなくリポジトリのファイル体系 や開発プロセスを変える戦略 - Spec-Fileと既存のドキュメントとの棲み分けは判断が分かれ る。 - 既存の開発体系を変えるのは、状況を⾒てからでもよい - Git管理されていれば、Spec-Fileを使い捨てても復旧は可能 149
150. (本当に)おわり 150