章 01
マニフェスト
Deep Work Plan（DWP）は、AIコーディングエージェントによる構造化された自律実行のための、Markdown のみで成り立つ方法論です。曖昧な目標を、レビュー可能な計画、すなわち仕様へと変えます。エージェントはその仕様を、コンテキストを失うことも、行き当たりばったりで一貫性のない結果に陥ることもなく、実行し、一時停止し、再開し、報告できます。
エージェントのためのディープワーク
この名前は、それが生み出す実践そのものを表しています。認知的に負荷の高い作業に対する、集中した持続的な努力であり、意志の力ではなく構造によって支えられます。ディープワークを人にとって価値あるものにする性質、すなわち気を散らさない集中を長期にわたって持続させることは、何時間も何日もにわたる作業をやり遂げるためにAIコーディングエージェントが必要とするものと同じです。Deep Work Plan はその構造を供給し、そうすることでリポジトリを AI-first でエージェントが操縦できるコードベースへと変えます。
計画のないエージェントは、決して時間を確保せず、何も書き留めず、中断のたびにコンテキストを切り替えるナレッジワーカーのように振る舞います。Deep Work Plan はエージェントに、確保されたカレンダーと書面のブリーフに相当するものを与えます。すなわち、区切られたスコープ、明確な順序、そして進捗を記録する永続的な場所です。
方向づけこそが乗数である
AIコーディングエージェントの能力は、モデルそのものよりも、与えられる方向づけの質に左右されます。有能なモデルを曖昧な依頼に向ければ曖昧さが増幅され、同じモデルを正確な仕様に向ければ正確さが増幅されます。モデルが進歩するほど、この差は縮まるどころか広がります。ボトルネックは上流へ、コードを書くことから作業を定義することへと移動します。問われるスキルはもはや実行ではなく、方向づけです。
これは、うまく委譲するとはどういうことかを問い直します。よい委譲とは、エージェントに作業を依頼することではなく、正しく実行できるほど明確に作業を定義することです。すなわち、目標、制約、エージェントがなければ欠いてしまうコンテキスト、そして成功したかどうかを判定する基準です。価値の大半は、実行が始まる前に生み出されます。
Deep Work Plan は、その上流の作業を永続的で再現可能なかたちで行う規律です。その二本の柱は、よい方向づけの二つの半分です。仕様は「正しい」とはどういう姿かを述べ、**ハーネス（harness）**はエージェントにそこへ到達するためのコンテキストとツールを与えます。両者が合わさることで、モデルの素の能力が信頼できるエンジニアリングへと変換されます。何時間も走るタスクを通して持続され、セッションのあいだに入れ替わるエージェントをまたいで保たれます。
設計からして仕様駆動
これは方法論の第一の柱であり、「ハーネス」と同様、平易に定義する価値があります。
仕様駆動開発とは何か。 通常のプロンプト駆動の作業では、信頼できる情報源は会話です。エージェントに何かを依頼し、ファイルが編集され、意図の唯一の記録はスクロールして消え去り二度と読み返されないチャットの履歴です。仕様駆動開発（SDD）はこれを逆転させます。まず 何が 真であるべきか、すなわち目標、スコープ、受け入れ基準、完了を証明するチェックを書き留め、その書かれた仕様が、会話ではなく、信頼できる情報源になります。エージェントはそのうえで、一行のプロンプトから即興するのではなく、仕様 に照らして 実行します。
DWP がそれをどう体現するか。 Deep Work Plan では、計画 こそが 仕様です。目標はレビュー可能な計画になり、計画はアトミックなタスクへと分解され、各タスクは明示的な受け入れ基準と検証ゲートを備え、完了プロトコルがそれらに照らして作業を確認します。計画 → タスク → ゲート → 完了は、具体的で実行可能にされた SDD そのものです。
なぜそれが重要か。 仕様を先に書くことは三つのかたちで報われます。エージェントは依頼の薄れゆく記憶ではなく明示された基準に照らして測られるため、逸脱が減ります。すべてのゲートは合格か不合格のいずれかであるため、作業は検証可能になります。そして仕様は単一のセッションやエージェントよりも長く生き残るため、作業は再開可能になります。別のエージェントが明日それを引き継ぎ、「完了」が何を意味するかを正確に把握できます。
DWP はどう異なるか。 この考え方をめぐっては、GitHub Spec Kit、Amazon Kiro、Tessl を含む、より広い仕様駆動の潮流が形成されてきました。それらのアプローチは、特定のツールやプラットフォームに縛られる傾向があります。DWP は意図的に異なります。ツール非依存でリポジトリネイティブです。仕様はプレーンな Markdown としてリポジトリの中に存在するため、ベンダーの製品ではなくコードとともに移動します。そして仕様はそれ自体がリポジトリの携える ハーネスの一部であるため、第二の柱と直接組み合わさります。
リポジトリがハーネスになる
これは方法論の第二の柱であり、平易な定義に値します。「ハーネス」は意味を負わされた語になり、業界の多くがその意味を述べないまま使っています。
エージェントハーネスとは何か。 大規模言語モデルは、それ自体では単なるテキストの予測器にすぎません。それを信頼できるエンジニアに変えるのは、その周りを取り巻くすべて、すなわち与えられるコンテキスト、呼び出せるツール、次に何をするかを決める制御ループ、誤りを捕らえるガードレール、そして停止と再開を可能にする永続的な状態です。その周囲の足場が ハーネス です。モデルはエンジンであり、ハーネスはそのエンジンを安全に走らせるシャーシ、ステアリング、ブレーキです。
ハーネスエンジニアリングとは何か。 ほとんどのチームは、その足場を暗黙のうちに単一のツールの内側、すなわち特定の IDE、エージェント製品、独自のフレームワークの中に作ります。そのためそこでしか機能せず、ツールを切り替えた瞬間に消え去ります。ハーネスエンジニアリングは、その足場を一級の成果物として意図的に設計する規律です。Deep Work Plan は、それがどこに存在すべきかについて一つの強い立場を取ります。すなわち、ツールの中ではなく、リポジトリそのものの中に。
なぜリポジトリが正しい場所なのか。 ハーネスがリポジトリの中に存在すると、それはコードとともに移動し、リポジトリを開くすべてのエージェントがそれを受け継ぎ、他のあらゆるコードと同じようにバージョン管理され、レビューされ、改善されます。DWP はハーネスの各部分を、具体的で永続的な成果物としてインストールします。
| ハーネスの要素 | 提供するもの | DWP がリポジトリのどこに置くか |
|---|---|---|
| コンテキスト | エージェントが知るべきこと | AGENTS.md、docs/、モジュールごとの README |
| ツール | エージェントができること | .agents/ のスキル、エージェント、dwp-* コマンド |
| 制御ループ | 作業の進め方 | Deep Work Plan: 計画 → アトミックなタスク → ゲート → 完了 |
| ガードレール | 正しさを保つもの | 明示的な受け入れ基準と検証ゲート |
| 状態 | 中断を生き延びる方法 | gitignore された .dwp/ の計画、ドラフト、進捗ログ |
- コンテキスト
- ツール
- 制御ループ
- ガードレール
- 状態／再開性
すべての要素が、ツールの機能ではなくリポジトリの中のファイルであるため、ハーネスは構造的に持ち運び可能です。それこそが、方法論の残りが拠って立つ一行の主張です。すなわち、リポジトリそのものがハーネスになる ことで、どのエージェントもどのリポジトリも操縦できる、ツールごとの独自フレームワークを必要とせずに。
構造化された自律実行がなぜ重要か
現代のAIコーディングエージェントは有能ですが、方向づけがありません。一つを些細でないタスクに向けると、すぐにファイルを編集し始め、何を変更したかを見失い、レビューが難しく再開が不可能な作業を生み出しがちです。
DWP は、それぞれの失敗に直接対処する軽量な構造を課します。
- レビュー可能なタスク — 作業は逐次的な単位へと分解され、それぞれが明示的なスコープと受け入れ基準を持ちます。
- 永続化された状態 — 進捗が書き留められるため、作業は中断を生き延び、セッションとエージェントをまたいで再開できます。
- 標準化されたドキュメント — 人とエージェントは、共通のフォーマットを通じて一つのメンタルモデルを共有します。
- エージェントの移植性 — この方法論は、再実装ではなく薄いアダプターを通じて、どのエージェントとも機能します。
どこまでも Markdown で
DWP はソフトウェアではなく構造を定義します。インストールするランタイムも、依存関係ツリーも、ロックインもありません。計画、タスク、実行ログはすべて、どのエージェントも読め、どの人もレビューでき、どのバージョン管理システムも綺麗に追跡できるプレーンな Markdown です。その結果は、読み、監査し、信頼できる実行です。