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