Agentic Coding 実践ワークショップ¶
チェック¶
- [ ] 本文を確認した
- [ ] 概要を確認した
- [ ] タグを確認した
- [ ]
inbox/直下へ移行した
概要¶
Agentic Coding を実践するための研修資料。 AI コーディングを単なるコード生成ではなく、ガードレール、品質ゲート、コンテキスト設計、Skills、Plan mode、仕様駆動開発を組み合わせた開発プロセスとして扱う。 ワークショップ形式で、Context Engineering、Agent Skills、Plan mode、Spec-driven development の考え方と手順が説明されている。
本文¶
資料は、AI コーディングエージェントを安全に実務投入するための実践ワークショップ。 対象は初学者向けで、3〜4時間程度の研修を想定している。 単に「AI にコードを書かせる」ではなく、エージェントが扱う情報、実行権限、品質確認、仕様、作業分解をどう設計するかに重点がある。
Agentic Coding の基本¶
Agentic Coding では、AI は補完ツールではなく、調査、計画、実装、検証、修正を一連の作業として進めるエージェントになる。 そのため、指示の出し方だけでなく、どの情報を渡すか、どの制約を置くか、どの品質ゲートを通すかが重要になる。
資料では、ガードレール、品質ゲート、カスタム指示、プラグインや拡張、Plan mode などが重要な要素として扱われる。 AI に自由に作業させるのではなく、作業範囲と確認基準を整えることで、出力を実務に近づける。
Context Engineering¶
Context Engineering は、LLM を関数のように捉え、入力と出力を管理する考え方。 LLM の出力は、モデルそのものだけでなく、プロンプト、会話履歴、外部ファイル、ツール結果、システム指示などの context に強く依存する。
資料では、context window は有限であり、長い会話や大量の資料を入れればよいわけではないと説明される。 特に Lost in the Middle のように、長い context の中央にある情報が使われにくくなる問題がある。 また、複数ターンの会話では、前の指示や途中の仮説が残り続け、現在の作業に不要な context が混ざる。
Context Engineering の技法は、大きく分けると次のように読める。
- 必要な context を書く。
- 必要な context を選ぶ。
- 不要な context を短くする。
- context を分割する。
カスタム指示に何でも詰め込まない、slash command や Skills を必要時だけ使う、subagent に文脈を分ける、といった設計はこの考え方に基づく。
なぜ slash commands や Skills を分けるのか¶
資料では、slash command、custom instructions、custom agents、Skills が context 分離のための仕組みとして整理される。
常に読み込む custom instruction に大量の手順を書くと、すべてのタスクで context を消費する。 一方、slash command や Skill は、必要になったときだけ読み込める。 特定のタスクにだけ必要な手順、ドメイン知識、参照資料を分けておくことで、通常タスクの context を軽くできる。
subagent も同じ。 一つの会話にすべての調査、設計、検証を詰め込むのではなく、役割ごとに context を分離する。 これにより、各エージェントの入力が整理され、余計な情報に引っ張られにくくなる。
Agent Skills¶
Agent Skills は、特定の作業に必要な専門知識、手順、参照ファイル、ツールの使い方をまとめる仕組み。 資料では、Skills を「behavior + knowledge + means/tools」の組み合わせとして扱う。
Skill の特徴は、エージェントが必要に応じて使うこと。 すべての Skill 本文が常に context に入るのではなく、メタデータを見て使うべき Skill を選び、必要になったときに本文や参照ファイルを読み込む。 これが progressive disclosure。
最小例として、次のようなディレクトリと SKILL.md を作る。
SKILL.md は frontmatter と本文を持つ。
---
name: ping-skill
description: pingと言われたときに使います。
---
# Echo Skill
このスキルは、「ping」のみをテキスト入力された場合、「pong」をそのまま返します。
実務では、単純な応答ではなく、レビュー手順、リリース手順、テスト観点、障害対応、社内ライブラリの使い方などを Skill 化する。
Plan mode¶
Plan mode は、いきなり実装せず、読み取りと計画に限定するモード。 AI エージェントは、コードベースを読み、要件を確認し、実装方針を作る。 書き込みや実行をする前に、人間が計画を確認できる。
資料では、GitHub Copilot、Cline、OpenCode などの Plan mode 的な機能に触れながら、実装権限を持つ Agent mode と、読み取り中心の Plan mode を分ける意義が説明される。
Plan mode の価値は、AI の早すぎる実装を止めること。 コードベースを理解せずにファイルを作ったり、要件を勘違いしたまま大きな変更を始めたりするリスクを下げる。 特に既存コードがあるプロジェクトでは、まず構造を読み、既存パターンを把握し、変更範囲を決めることが重要。
ワークショップでは、たとえばハノイの塔の Web アプリを Plan mode で依頼し、エージェントからの質問に答え、計画を固めてから実装へ進む流れが示される。
Spec-driven development¶
Spec-driven development は、仕様を version control された human-readable な super prompt として扱う開発方法。 AI に実装させる前に、仕様、計画、タスクを段階的に作り、合意可能な成果物として残す。
資料では、Kiro や GitHub spec-kit が例として挙げられる。 spec-kit の導入コマンドは次のような流れ。
pipx install uv
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
specify init . --ai copilot
生成された環境では、仕様作成、計画、タスク分解、実装を slash command のように進められる。
例として、React、Vite、Tailwind、Vitest、Biome のような技術スタックで Web アプリを作る流れが扱われる。
SDD はウォーターフォールの復活ではない。 すべてを最初に完全に決めるのではなく、AI エージェントが扱いやすい形で、要求、計画、タスクを明示する。 実装の前に仕様ファイルを作ることで、AI が何を作るべきか、何を満たすべきかを参照できる。
Spec と Plan の違い¶
資料の補足では、Spec と Plan の境界にも触れる。 Plan は実装前にどう進めるかを考えるもの。 Spec は何を作るか、どう振る舞うべきかを記述するもの。 実際には境界が曖昧になる。
パターンとしては、spec-first、spec-anchored、spec-as-source がある。 仕様を最初に作る、仕様を作業の拠点にする、仕様をソースオブトゥルースとして扱う、といった使い方。
ただし、仕様ファイルを増やしすぎると context を圧迫し、人間のレビュー負担も増える。 テキストが多いほどよいわけではない。 Git 履歴に残るなら、一時的な設計メモやタスク分解ファイルとして使い、必要がなくなったら整理する選択もある。
AI時代の態度¶
資料の終盤では、AI を「機械化革命」として捉える話が出る。 将来予測は不確実であり、過度な悲観や楽観に振り回されないことが大事。
Coding agent は強力だが、疑うことと信じることの両方が必要になる。 出力を信用しすぎると危険だが、すべてを拒否すれば道具として使えない。 AI を使いながら、どこで間違えるか、どこで強いかを観察し、自分の予測精度を上げていく。
要点¶
- Agentic Coding は、AI に実装させるだけでなく、context、権限、品質ゲート、仕様を設計する開発方法。
- Context Engineering では、必要な情報を選び、短くし、分割する。
- Skills は必要なときだけ専門知識や手順を読み込む progressive disclosure の仕組み。
- Plan mode は、実装前にコードベース理解と計画を行い、早すぎる変更を防ぐ。
- Spec-driven development は、仕様、計画、タスクを AI が扱いやすい成果物として残す。
- 仕様や文書を増やしすぎると context とレビュー負担が増えるため、目的に合わせて使う。