比較
Deep Work Plan と代替ツール
状況に合ったレイヤーを選んでください。各代替ツールはそのツール自身の言葉で記述され、すべての事実は公式ドキュメントにたどれ、ページは最終確認日を明記します。これはランキングではなく地図です。
このページの読み方
三つの値が各ケイパビリティを記述します。これらはケイパビリティがツールのどこにあるかを示すものであり、ツールの優劣を示すものではありません。
- 組み込み
- オプションまたは拡張経由
- 対象外
最終確認:
代替ツールをそれぞれ自身の言葉で
仕様駆動開発ツール
-
仕様駆動開発ツール
GitHub Spec Kit
憲章、仕様、計画、タスクリストを通じて機能を実行可能な仕様に変え、五十を超えるコーディングエージェントと統合するスラッシュコマンドで駆動します。実装前に各成果物が互いに整合しているかを確認できます。
すでに使っているエージェントの内側で、繰り返し可能な specify・plan・tasks・implement のワークフローを求めるチーム。
-
仕様駆動開発ツール
OpenSpec
各変更を、デルタ仕様（追加・変更・削除）とシナリオ付き RFC 2119 要件を備えた提案として捉え、生きた仕様へとアーカイブします。変更が受け入れられる前に、提案の完全性とシナリオの網羅性を検証するバリデーターも備えます。
既存のシステムを扱い、仕様を一度に一つの変更ずつ育てたいチーム。
-
仕様駆動開発ツール
Amazon Kiro
エージェント的な IDE と CLI。仕様は EARS 形式の要件から設計へ、そしてタスクへと進み、ステアリングファイルとエディタのイベントで走るフックを備えます。既存のコードベースから仕様を生成し、設計に入る前に要件の抜け漏れを見つけることもできます。
AWS 基盤のツールとともに、エディタに組み込まれた仕様駆動開発を求める開発者。
エージェントワークフローフレームワーク
-
エージェントワークフローフレームワーク
BMAD Method
専門化されたエージェントロール（分析、プロダクト、アーキテクチャ、開発、品質）からなるアジャイルフレームワークで、ブリーフ、要件、アーキテクチャドキュメント、ストーリーファイルを生成します。完了の定義には、各ストーリーが完了と見なされる前にチームメイトまたは AI ピアレビュアーによるレビューを受けることが含まれます。
ロールベースの作法を好み、エージェント作業に完全なアジャイルライフサイクルを求めるチーム。
-
エージェントワークフローフレームワーク
Superpowers
ブレインストーミング、小さなテストファーストのステップでの計画、サブエージェントによる実行、完了前のレビューのためのスキルライブラリとワークフロー。ここに挙げたどの選択肢よりも多くのコーディングエージェントホストと統合されており、すべてのタスクで二段階のサブエージェントレビュー（仕様準拠、続いてコード品質)を実施します。
コーディングエージェントの内側で、規律あるテスト駆動の実行を求める開発者。
-
エージェントワークフローフレームワーク
GSD Core
.planning ディレクトリ、要件 ID、フェーズ計画、新しいコンテキストでの実行、各計画のサマリーから抽出したユーザーが観察可能な成果物に対する検証パスを備えた計画システム。調査・計画・実行を使い捨てのサブエージェントで行い、内容のフィンガープリントで古くなった検証を検出することで、コンテキストの劣化に正面から対処するよう設計されています。
儀式を少なくコンテキストエンジニアリングと検証を求める、個人開発者と小さなチーム。
-
エージェントワークフローフレームワーク
Gentle-AI
すでに使っているコーディングエージェントを、セッションやモデルをまたいでルーティングも行う永続メモリ、厳選されたスキル、MCP サーバー、ペルソナ、そしてオプションの Spec-Driven Development や Receipt-Driven Development で構成します。設定はデフォルトでエージェントのグローバル設定に書き込まれ、ワークスペース単位のインストールはオプトインです。
セッションをまたいで作業を記憶し、必要に応じて証跡を生成できる、構成済みのエージェントエコシステムを求める開発者向け。
AI-native SDLC
Deep Work Plan がもたらすもの
-
ツール非依存でリポジトリネイティブ
ハーネスも計画もあなたのリポジトリ内のファイルであり、AGENTS.md と Agent Skills 標準に従うどのエージェントにも読めます。エージェントを乗り換えても計画は失われません。
-
各タスクが触れたものから選ばれる検証
すべてのタスクが変更対象面を宣言し、変更された挙動とそのコンシューマーのテストを実行し、影響を境界づけられないときはスイート全体に広げます。選択されたテストがゼロで合格することはありません。
-
セキュリティパスを伴う単一の Final Review
計画は、累積変更セットのセキュリティレビュー（diff の必須ローカルレビューを含む）と最終状態の検証で締めくくられます。重大な発見は完了を阻止します。
-
セッションとエージェントを生き延びる状態
README のチェックボックス、タスクログ、範囲が限られた作業インデックス、機械可読の状態ファイルがすべての境界で書き込まれるため、別のセッションや別のエージェントがディスクから続行します。中断された計画の作成すら復元できます。
-
リポジトリ自身のための適合性チェッカー
読み取り専用のスクリプトが、ハーネスとすべての計画を仕様に照らして検証し、両方の計画ライフサイクルを理解し、CI に優しいコードで終了します。
-
計測され公開される指示読み込み
コミットされたスクリプトがフローごとに二つの測定値——セッション開始時に読み込まれる入口バンドルと、実際のトリガーが発火した後のエンドツーエンドのパス——を、それぞれの除外事項とともに公開するため、入口の数値だけが実行全体のコストとして読まれることはありません。増加を含む結果は常にバイトとして公開され、トークンやコストのパーセンテージとして公開されることはありません。
正直な限界
Deep Work Plan には生きた仕様やデルタ仕様の仕組みがなく、その領域では OpenSpec などのツールが優れています。方法論の独立したベンチマークはまだ存在しません。一方、ファーストパーティによるフレッシュエージェント評価が凍結プロトコルの下で実行済みです——規模は小さく、単一ワークロード、構成ごとに2つの機能、1台のマシン——その結果は両方向で公開されています：ハーネスを持つツリー上のエージェントは両タスクでバイト読取量が少なく、現行版のセッションは前のメジャーバージョンより少ない、ハーネス報告のモデル入出力を消費した一方、ワークロードごとのトークンの純方向は混在し、ウォールクロックの優位は主張されていません。指示読み込みの台帳は読み込まれたバイト数を測るものであり、トークン、コスト、成果ではありません。また、その入口バンドルの数値は、実行が読み込む量の上限ではありません。DWP はあえてリポジトリの範囲に限定されています。プロジェクトをまたぐメモリシステムでも、役割ベースのエージェントフレームワークでも、IDE でもないため、これらの軸では競合しません——その能力が必要な作業には、それをカバーするツールと組み合わせてください。
正確さを保つためにご協力ください
正確さを保つためにご協力ください
このページは表示された日付に確認し、要望に応じて修正されます。あなたのツールの記述が古い、あるいは不完全な場合は Issue を開いてください。修正します。