マニフェスト

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 はハーネスの各部分を、具体的で永続的な成果物としてインストールします。

リポジトリ

• コンテキスト
• ツール
• 制御ループ
• ガードレール
• 状態／再開性

↑ 操縦する

エージェント

すべての要素が、ツールの機能ではなくリポジトリの中のファイルであるがゆえに、ハーネスは構造的に持ち運び可能です。Markdown を読み、シェルコマンドを実行できるどのエージェントも、ツールごとの独自フレームワークを必要とせずに、同じファイルを開くことができます。それこそが、方法論の残りが拠って立つ一行の主張です。すなわち、リポジトリそのものがハーネスになる。これはリポジトリが何を担っているかについての主張であり、モデルが初見のリクエストで自力かつ確実に正しいフローを見つけられるという保証ではありません——だからこそキットは、明示的な dwp-* エントリーポイントとルーターとなる SKILL.md も出荷しています。ファイルの持ち運び可能性と確実なルーティングは別々の性質であり、構造上組み込まれているのは前者だけです。

構造からして効率的

第一の柱が作業を正しくし、第二の柱がそれを移植可能にします。第三の柱はそれを 手頃なまま に保ちます。コンテキストはコーディングエージェントにとって最も希少なリソースであり、それを浪費する方法論は、作業が長くなったまさにその瞬間に破綻するからです。

三つの仕組みがその働きを担います。

• 段階的な開示。 エージェントは本質的な中核だけを読み、各ガイドや仕様の節は、そのフロー自身のトリガーが発火したときに初めて読み込まれます。エージェントが運ぶのは必要な章であって、本全体ではありません。
• 変更対象面（Touched Surface）で選ぶ検証。 すべてのタスクは何を変更するかを記録し、リスククラスによってゲートを選びます。小さく孤立した変更は狭く自らを証明し、共有機構への変更は広く証明します。検証は習慣ではなく、効果によって選ばれます。
• タスク内での学習。 タスクが再利用可能なパターンを生んだとき、決定は証拠が新鮮なそのタスクの内側で行われます。誰も読まない振り返りの中ではありません。

このうちのどれも、構造上は損失なしとは主張しませんし、どれも捏造されたパーセンテージで宣伝されません。各フローが必要とする指示バイト数は計測され、公開されています。振る舞いに関する主張は、意図的に仕込んだ欠陥のリプレイに裏づけられています。さらに、フレッシュエージェント評価——同じ2つの機能を、ハーネスなし、前のメジャーバージョン、現行版でそれぞれ構築——が、凍結プロトコルの下ですでに実行されました。それは初見のエージェントの初日にメカニズムが何をもたらすかを測定したものです：ハーネスを持つツリー上のエージェントは両タスクでハーネスなしの対照より少ないバイトを読み、現行版の機能セッションは、ハーネス報告のとおり、単一ワークロードで前のメジャーバージョンより少ないモデル入出力を消費しました。同じ評価が限界もはっきり示しています。オンボーディングはフローが使われて初めて回収される一回限りのコストであり、5回のフレッシュ実行でフローに自力で入ったエージェントはいませんでした——フローは、あなたか、呼び出し方を知るエージェントが実行するコマンドです。同じツリー上の2つ目の機能は、ハーネスなしの対照も含む測定されたすべての構成で低コストでした：その償却の一部はツリー自体のものであり、ハーネスはそれを意図的なものにするために存在します。

構造化された自律実行がなぜ重要か

現代のAIコーディングエージェントは有能ですが、方向づけがありません。一つを些細でないタスクに向けると、すぐにファイルを編集し始め、何を変更したかを見失い、レビューが難しく再開が不可能な作業を生み出しがちです。

DWP は、それぞれの失敗に直接対処する軽量な構造を課します。

• レビュー可能なタスク — 作業は逐次的な単位へと分解され、それぞれが明示的なスコープと受け入れ基準を持ちます。
• 永続化された状態 — 進捗が書き留められるため、作業は中断を生き延び、セッションとエージェントをまたいで再開できます。
• 標準化されたドキュメント — 人とエージェントは、共通のフォーマットを通じて一つのメンタルモデルを共有します。
• エージェントの移植性 — この方法論は、再実装ではなく薄いアダプターを通じて、どのエージェントとも機能します。

どこまでも Markdown で

DWP はソフトウェアではなく構造を定義します。インストールするランタイムも、依存関係ツリーも、ロックインもありません。計画、タスク、実行ログはすべて、どのエージェントも読め、どの人もレビューでき、どのバージョン管理システムも綺麗に追跡できるプレーンな Markdown です。その結果は、読み、監査し、信頼できる実行です。