Claude Code は強力なコーディング支援機能を備えているが、Spec-Driven Development（SDD）を体系的に実行するための標準ワークフローは提供していない。
そのため多くのユーザが、独自のスラッシュコマンドや手作りの手順書を作成してワークフローを補完し、SDD を実現している。
この課題に対して、SDD を実践するための OSS として注目されているのが Agent OS である。
Agent OS は、仕様策定から実装までの一連のサイクルを Claude Code 上で完結できるようにする、軽量で扱いやすい拡張環境である。
まずは紹介動画（日本語字幕あり）が分かりやすい。
https://www.youtube.com/watch?v=kApsR0l9Jfw
動画・ドキュメントを見るとわかるとおり、特に興味深いのは サブエージェント を自然に活用できる点である。既存プロジェクトにも容易に導入でき（いわゆる Brownfield にも対応）、SDD のワークフローをそのままプロジェクトに埋め込むことができる。
1. Agent OS の導入
インストールすると、.claude 配下に Agent OS 用のエージェント定義が追加される。
シンプルな構成であり、既存の Claude Code の操作感を維持したまま拡張できる。
2. ワークフロー全体像
Agent OS のワークフローは非常に明確で、プロダクト計画フェーズ（最初に 1 回） と 機能開発フェーズ（機能ごとに繰り返す） の二層構造である。
2.1 Plan Product（初期 1 回実行）
公式ドキュメントでは、/agent-os:plan-product をプロジェクト開始時または導入初日に 1 回実行することが推奨されている。
ここでは以下を整理し、エージェントが共通理解として参照できるようにする：
- プロダクトの技術スタック
- ミッションとゴール
- ロードマップ
- 高レベルのアーキテクチャ方針
これにより、以降の仕様策定・タスク分解・実装で迷走しにくくなる。
2.2 機能ごとに反復する 5 ステップ
以降の 5 フェーズは、機能（イニシアティブ）単位で繰り返す。
仕様の成形（shape-spec）
粗いアイデアを仕様の形に整えるフェーズ。要求が曖昧な場合に特に有効。
すでに要求が明確な場合はスキップしてよい。
仕様書作成（write-spec）
要求から詳細仕様（spec.md）を自動生成する。
タスク分解（create-tasks）
仕様を実装タスクに分割し、優先度・カテゴリごとに整理した tasks.md を生成する。
実装（implement-tasks）
直接メインエージェントに実装させる簡易モード。
実装オーケストレーション（orchestrate-tasks）
タスクグループごとにサブエージェントを割り当て、標準（スタンダード）を適用しながら実装を進める高度モード。
この「機能単位での反復サイクル」が Agent OS の中核であり、SDD の実践を強制的に構造化してくれる。
3. 実際の挙動：shape-spec の例
まず /agent-os:shape-spec を実行すると、Agent OS は spec-shaper エージェントを呼び出す。
この段階ではまだ要件が渡されていないため、対話的に要件を確認してくる。
やり取りをすると、次のような結果が得られた：
● spec-shaper(Finalize lineout xP requirements) resuming ae70abc
⎿ Done (3 tool uses · 47.2k tokens · 1m 6s)
● Spec shaping is complete!
✅ Spec folder created: /xxx/xxx/xxx/xxx
✅ Requirements gathered
✅ Visual assets: No files provided
---
調査結果サマリー
| 項目 | 内容 |
|------------|-----------------------------------------------------------|
| 対象条件 | xxx |
| 処理 | xxx |
| 既存コード | xxx |
| 必要な変更 | xxx |
発見事項: このロジックは既にコードベースに存在しています。主な作業はコメントの修正と、既存ロジックが正しく動作していることの確認になります。
---
NEXT STEP 👉 Run /agent-os:write-spec to generate the detailed specification document.
ここで特筆すべき点は次の二つである。
- 作業完了後に次のステップが明確に提示されること
- 仕様フォルダの生成、既存コード調査、変更点の整理などが標準化されていること
SDD を「迷いなく進める」ためのガイドとして理想的な設計になっている。
4. write-spec：仕様書の自動生成
案内に従って /agent-os:write-spec を実行すると、要求に応じた詳細仕様書（spec.md）が生成される。
ここでも重要なのは以下の点である：
- 対象ファイル・修正箇所・検証項目などが整理される
- 変更の影響範囲が明示される
- 次に実行すべきコマンド（create-tasks）が提示される
SDD の「仕様が上位、コードが従う」という考え方を体現したプロセスである。
5. create-tasks：タスク分解
続いて /agent-os:create-tasks を実行する。
タスクは複数のグループに分けられ、さらに個別タスクとして細分化される。
特に注目したいのは tasks.md に自動生成される Acceptance Criteria（受け入れ基準） である。
これは SDD の文脈でも極めて重要であり、後続の実装・テストを「評価可能な形」に固定する役割を持つ。
6. orchestrate-tasks：サブエージェントによる実装オーケストレーション
実装には /agent-os:implement-tasks と /agent-os:orchestrate-tasks の二方式があるが、後者はより高度である。
オーケストレーションモードでは：
- タスクグループごとに担当サブエージェントを割り当てる
- 使用するスタンダード（技術規約）を指定する
- グループ単位で実装が実行される
ここは Agent OS の特徴が最もよく現れる部分であり、SDD をマルチエージェントで実行可能にする設計となっている。
実装のログを見ると、スタンダードを読み込み、タスクに応じて自律的にコード変更・検証・テスト実行を行っていることがわかる。
> /agent-os:orchestrate-tasks
⎿ Read agent-os/standards/global/coding-style.md (11 lines)
⎿ Read agent-os/standards/global/conventions.md (12 lines)
⎿ Read agent-os/standards/global/tech-stack.md (32 lines)
⎿ Read agent-os/standards/frontend/css.md (8 lines)
⎿ Read agent-os/standards/frontend/responsive.md (12 lines)
● Read(agent-os/specs/2025-12-20-xxx/tasks.md)
⎿ Read 101 lines
● Write(agent-os/specs/2025-12-20-xxx/orchestration.yml)
⎿ Wrote 4 lines to agent-os/specs/2025-12-20-xxx/orchestration.yml
task_groups:
- name: Comment Corrections and Logic Verification
- name: Verification Testing
● orchestration.yml を作成しました。次に、各タスクグループに割り当てるサブエージェントを指定してください。
各タスクグループに割り当てるサブエージェント名を指定してください:
1. Comment Corrections and Logic Verification - コメント修正とロジック検証
2. Verification Testing - 検証テスト
タスクグループ番号とサブエージェント名で回答してください。例:
- 1: backend-specialist
- 2: test-engineer
> 1: backend-specialist, 2: test-engineer
● Write(agent-os/specs/2025-12-20-xxx/orchestration.yml)
⎿ Added 2 lines
1 task_groups:
2 - name: Comment Corrections and Logic Verification
3 + claude_code_subagent: backend-specialist
4 - name: Verification Testing
5 + claude_code_subagent: test-engineer
● サブエージェントを割り当てました。次に、各タスクグループの実装をガイドするスタンダードを指定してください。
各タスクグループに適用するスタンダードを指定してください:
1. Comment Corrections and Logic Verification
2. Verification Testing
各タスクグループ番号に対して、以下のいずれかを指定できます:
- all - すべてのスタンダードを含める
- global/* - standards/global内のすべてのファイルを含める
- frontend/css.md - 特定のファイルを含める
- none - スタンダードなし
例:
- 1: global/*
- 2: none
> 1: global/*, 2: none
● Write(agent-os/specs/2025-12-20-xxx/orchestration.yml)
⎿ Added 2 lines
1 task_groups:
2 - name: Comment Corrections and Logic Verification
3 claude_code_subagent: backend-specialist
4 + standards:
5 + - global/*
6 - name: Verification Testing
7 claude_code_subagent: test-engineer
● orchestration.yml を更新しました。これからタスクグループの実装をサブエージェントに委任します。
---
Task Group 1: Comment Corrections and Logic Verification
backend-specialist に委任中...
● implementer(Implement Task Group 1)
⎿ Done (11 tool uses · 83.1k tokens · 8m 45s)
● ✅ Task Group 1 完了
コメント修正とロジック検証が完了しました：
- xxx
- xxx
- ロジックコードは変更なし（正しく動作することを確認済み）
---
Task Group 2: Verification Testing
test-engineer に委任中...
● implementer(Implement Task Group 2)
⎿ Done (17 tool uses · 52.6k tokens · 2m 45s)
● ✅ Task Group 2 完了
検証テストが完了しました：
- 4件のユニットテストを作成・実行 → 全てパス
- コードレビュー完了 → ロジックは正しく動作
- xxxの参照は残っていないことを確認
---
オーケストレーション完了
すべてのタスクグループが正常に完了しました。
| Task Group | サブエージェント | ステータス |
|-----------------------------------------------|--------------------|------------|
| 1. Comment Corrections and Logic Verification | backend-specialist | ✅ 完了 |
| 2. Verification Testing | test-engineer | ✅ 完了 |
実施内容サマリー
コメント修正:
テスト作成:
検証結果:
---
実装完了です！ 必要に応じて変更をコミットしてください。
7. 全体評価：Agent OS の価値
Agent OS の優位点は次の三点に集約される。
7.1 導入が容易
プロジェクトに追加するだけで使い始められ、Brownfield にも問題なく適用できる。
7.2 ワークフローが極めて明確
次に何をすべきかがコマンドとして明示され、SDD を実践する手順を迷わず踏める。
7.3 Claude Code との親和性の高さ
仕様策定、タスク分解、実装、テストがすべて Claude Code 内で完結する。
これは従来の「外部ツールで仕様を作ってから LLM に渡す」という煩雑さを解消する。
結果として、SDD とエージェントによる実装を一貫して行える“軽量 Agent OS” として非常に実用的である。
まとめ
Agent OS は、Claude Code を「仕様駆動のマルチエージェント開発環境」へと進化させる OSS である。
導入が容易で、ワークフローが明確で、SDD の実践を迷いなく進められる。
特に、仕様書生成 → タスク分解 → サブエージェントによる実装という一連の流れが自然に連動する点は、既存の AI コーディング体験を大きく補完してくれる。
Claude Code を日常的に使っているユーザであれば、一度触ってみる価値があるだろう。