「AIに丸投げしたら、それっぽいけど使えないコードが返ってきた」——Claude Codeを使い込むほど、この壁にぶつかります。原因はモデルの能力ではなく、あいまいな指示を一気に実装させようとする進め方にあります。
料理本を作るとき、いきなり原稿を書き始める人はいません。「目次→章立て→各章の下書き→本文」と段階を踏むはずです。Deep Trilogyは、まさにこの段取りをClaude Codeのプラグインとして実装したものです。あいまいなアイデアを分解し、計画を立て、実装する——この3工程を3つのプラグインに分け、人間が要所で判断しながら一気通貫で進めます。
この記事では、開発者Pierce Lamb氏が公開した3プラグイン（/deep-project・/deep-plan・/deep-implement）を、公式リポジトリと本人のブログ記事という一次ソースだけを根拠に、役割分担・導入手順・連携の実例まで日本語で整理します。
30秒で理解する Deep Trilogy
・Pierce Lamb氏が公開したClaude Code向けプラグイン3本の総称。すべてMITライセンス・Python 3.11+・beta版（2026年6月時点）
・/deep-project（分解）→ /deep-plan（計画）→ /deep-implement（実装）の3段パイプライン。「vague idea → spec → plan → code」を段階ごとに自動化する
・各プラグインは状態をファイルに書き出すため、中断しても同じコマンドで再開できる
・人間を全自動から外さず、インタビューやコードレビューの分岐で「判断」だけを求める設計
・プロジェクトの成熟度に応じてどの工程からでも入れる
この記事の内部リンクの起点として、Claude Code本体の導入と運用はClaude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引きにまとまっています。プラグインやフックの前提知識はそちらで押さえてください。
Deep Trilogy とは——3プラグインの役割分担
Deep Trilogyは、ソフトウェアを「アイデア」から「本番コード」まで運ぶための3段パイプラインです。リポジトリのREADMEは、3本の関係を次の1行で表現しています。
/deep-project(decompose) →/deep-plan(plan) →/deep-implement(build)
最初の/deep-projectが、broadで漠然としたアイデアを独立したコンポーネントに切り分けます。次の/deep-planが、各コンポーネントのspecを受け取り、リサーチと外部レビューを経てTDD前提の計画に落とします。最後の/deep-implementが、計画から生まれたセクションを1つずつ実装していきます。
3本それぞれが「入口・中間・出口」を担い、工程の境界で生成物（specファイルやセクションファイル）を受け渡します。この受け渡しがファイルベースである点が、後述する「中断と再開」を支えています。
『SaaSを作りたい』"] --> B["/deep-project
分解（decompose）"] B --> C["spec.md×N
01-auth / 02-billing ..."] C --> D["/deep-plan
計画（plan）"] D --> E["TDD計画＋
sections/ ファイル群"] E --> F["/deep-implement
実装（build）"] F --> G["テスト済みコード＋
atomicなgit履歴"] G --> H["本番コードベース"]
下の比較表は、3プラグインの入力・出力・役割を1枚に整理したものです。
| プラグイン | 入力 | 主な工程 | 出力 | バージョン |
|---|---|---|---|---|
/deep-project |
あいまいな要件（requirements.md） | インタビュー → 分割分析 → 依存マッピング → spec生成 | 分割ごとのspec.md（01-auth/ 等）＋project-manifest.md | 0.2.1 (beta) |
/deep-plan |
個別のspec.md | リサーチ → インタビュー → 外部LLMレビュー → TDD計画 → セクション分割 | claude-plan.md（主成果物）＋sections/ ＋テストスタブ | 0.3.2 (beta) |
/deep-implement |
sections/ のセクションファイル群 | テスト先行実装 → コードレビュー → インタビュー → コミット | テスト済み実装コード＋セクションごとのatomicコミット | 0.2.1 (beta) |
3本の人気度には差があり、入口の/deep-projectが141★、/deep-planが99★、/deep-implementが54★（GitHub API実測、2026年6月時点）。入口ほど注目が集まっているのは、多くの開発者が「最初の分解」でつまずいている証拠とも読めます。
なぜ Trilogy なのか——モノリス的な丸投げが失敗する構造
なぜ1つのプラグインで完結させず、わざわざ3本に分けたのか。Lamb氏はブログで、Claude Codeの特性をこう整理しています。即興のコーディングは得意だが、徹底した計画を与えるほど結果が良くなる。ところが従来のやり方は、リサーチ・関係者インタビュー・外部検証・テスト駆動といった重要な工程を飛ばしてしまう、と。
Lamb氏自身、同じ計画・実装ワークフローを何カ月も手作業で繰り返すうちに、分解・計画・実装の3フェーズはそれぞれ専用の自動化に値すると気づいたといいます。1本のプラグインに全部を詰め込むと、各工程が浅くなり、Claude Codeの有限なコンテキストウィンドウも食いつぶしてしまうわけです。
Lamb氏の設計哲学は「構造化された人間参加型（human-in-the-loop）開発」です。本人の言葉を借りれば、エージェント型コーディングはいずれ人間の介入を必要としなくなる方向に進むが、2026年1月時点ではまだそこに達していない。だからこそ、要所で人間の判断を残すほうが全自動より良い結果を出す——という前提に立っています。
そのため3プラグインとも、インタビューで隠れた要件を引き出し、コードレビューのトリアージで優先順位を開発者に委ね、コンテキスト管理のチェックポイントでドリフト（脱線）を防ぎます。Claudeに任せるのは「賢い判断と各ピースの調整」だけ、というのが一貫した思想です。
/deep-project — あいまいなアイデアをspecに分解する
入口の/deep-projectは、READMEの言葉で言えば「vague, high-level project requirementsを、well-scopedな planning unitsに変換する」プラグインです。「アプリ作って」レベルの粒度を、/deep-planにかけられる単位まで噛み砕くのが仕事です。
内部は5つのフェーズが順に走ります。
あいまいな要件"] --> B["1. インタビュー
適応的Q&Aで全体像を把握"] B --> C["2. 分割分析
複数ユニットに分ける価値があるか判定"] C --> D["3. 依存マッピング
関係と実行順序を特定"] D --> E["4. ユーザー確認
提案した構造を承認"] E --> F["5. spec生成
分割ごとにspec.mdを書く"] F --> G["splits/01-auth/spec.md
splits/02-billing/spec.md ..."]
READMEによれば、所要時間は「約15分のインタビュー」で、その代わり「何時間もの調整と手戻り」を節約できると謳われています。実行後のplanning/ディレクトリは次のような構造になります。
planning/
├── requirements.md
├── deep_project_interview.md
├── project-manifest.md
└── splits/
├── 01-auth-system/spec.md
├── 02-billing/spec.md
└── 03-dashboard/spec.md
ポイントは、各spec.mdが独立して/deep-planにかけられるよう番号付きで整理される点です。project-manifest.mdが全体像と依存関係を保持し、どの順序で計画すべきかを示します。
実行コマンドはシンプルです。
/deep-project @planning/requirements.md
中断検知と自動再開にも対応しており、同じコマンドを再実行すれば途中から続きます。外部APIキーは不要で、テストはuv run pytest tests/で走らせられます。100% Pythonで書かれている点も、Lamb氏の「決定的ロジックはテスト済みスクリプトに置く」という方針の表れです。
/deep-plan — spec を TDD セクションファイルに変える
/deep-projectが吐き出した個別のspecを受け取るのが/deep-planです。READMEの定義では「vagueなfeature requestを、AIによるリサーチ・関係者インタビュー・マルチLLMレビューを通じて、本番投入可能な実装計画に変える」プラグインです。
工程は次の5フェーズです。
Research → Interview → External LLM Review → TDD Plan → Section Splitting
リサーチフェーズでは既存コードベースとWeb上のベストプラクティスを分析し、インタビューで隠れた要件を引き出します。注目すべきは外部LLMレビューで、Gemini・OpenAI（ChatGPT）のいずれか、あるいはキーが無ければ内部のOpusサブエージェントが、計画を独立した視点でレビューします。開発者はその指摘を取捨選択して取り込めます。
TDDフェーズでは、実装の前にテストスタブを定義します。「期待する振る舞いを先に決める」というテスト駆動の原則を、計画の段階で組み込むわけです。最後にセクション分割で、作業を自己完結した並列実行可能なユニットに割ります。出力構造は次のとおりです。
planning/
├── your-spec.md
├── deep_plan_config.json # セッション状態
├── claude-research.md
├── claude-interview.md
├── claude-spec.md # 統合済み
├── claude-plan.md # ★主成果物
├── claude-plan-tdd.md # テストスタブ
├── reviews/ # 外部フィードバック
└── sections/ # 実装ユニット
実行は/deep-plan @path/to/your-spec.md。specファイルの親ディレクトリからplanningディレクトリを推測し、同じコマンドの再実行で中断した作業を再開できます。
/deep-implement — section を実装コードに変える
パイプラインの出口が/deep-implementです。READMEは「/deep-planが生成したセクションファイルを受け取り、TDD手法・統合コードレビュー・構造化されたgitワークフローで1つずつ実装する」と説明します。
各セクションは次のループで処理されます。
Read Section → TDD Implementation → Code Review → Interview → Commit → Next
セクションごとに、まずテストを書き、次に実装コードを書きます。専用のコードレビュー用サブエージェントがステージ済みの変更をレビューし、修正の前に「実際の判断ポイント」だけ開発者にインタビューします。各セクションのドキュメントには「What Was Built（何を作ったか）」が追記され、1セクション＝1つのatomicコミットとして明快なgit履歴が残ります。
3回リトライの上限
/deep-implementはTDDを強制し、「テスト先行→実装」を最大3サイクルまでリトライしてから次に進みます。無限ループでコンテキストを溶かさないための歯止めです。
実行は/deep-implement @planning/sections/.。sectionsディレクトリにはSECTION_MANIFESTブロックを含むindex.mdと、section-NN-<name>.md形式のファイルが必要です。進捗はdeep_implement_config.jsonに記録され、ここでも中断・再開が効きます。
3プラグイン連携の実例——SaaS構築のウォークスルー
Lamb氏がブログで挙げる典型例は「ユーザー管理・課金・ダッシュボードを備えたSaaSプラットフォームを作りたい」というbroadな依頼です。これをDeep Trilogyに通すと、次のように流れます。
まず/deep-projectが、この漠然とした依頼を01-auth（認証）・02-billing（課金）・03-dashboard（ダッシュボード）といった独立コンポーネントに分解し、それぞれのspecと依存関係を書き出します。
次に各specを/deep-planにかけます。たとえば認証コンポーネントなら、既存コードの認証パターンをリサーチし、GoogleやGitHubのプロバイダ統合について5〜10個の質問を投げ、ドラフト計画を外部LLMに独立分析させ、その提案を理由付きで採否し、実装前にテストスタブを作り、最後に並列で着手できるユニットに分割します。
SKILL.md＋frontmatter
（名詞＝知識ユニット）"] C["コマンド
スキルを連鎖（動詞）"] SUB["サブエージェント
隔離された子スレッド"] H["フック
SessionStart / SubagentStop 等"] end ECO --> DT["Deep Trilogy
分解→計画→実装を束ねる
3プラグイン"] DT --> DP1["/deep-project
入口：分解"] DT --> DP2["/deep-plan
中間：計画"] DT --> DP3["/deep-implement
出口：実装"]
最後に各セクションを/deep-implementが実装します。認証・課金それぞれのコードがTDDで書かれ、レビューを通り、コンポーネント単位でコミットされ、最終的に本番コードベースへ統合されていきます。
ここで効いているのがどの工程からでも入れる柔軟性です。すでにスコープが固まった単一機能なら/deep-projectを飛ばして/deep-planから、セクションファイルが手元にあるなら/deep-implementから始められます。3本は強く連携しつつ、それぞれ単体でも機能するよう作られています。
インストール手順——marketplace add → install → enable
3本とも導入手順は共通で、Claude Codeのプラグイン仕様に沿っています。/deep-projectを例にすると次の3コマンドです。
/plugin marketplace add piercelamb/deep-project
/plugin install deep-project
/plugin enable deep-project
/deep-plan・/deep-implementも、リポジトリ名を差し替えれば同じ3ステップで入ります。手動インストールの場合は、リポジトリをcloneして.claude/settings.jsonにパスを追加します。
{
"plugins": {
"paths": ["/path/to/deep-project"]
}
}
動作要件はPython 3.11+、uvパッケージマネージャ、そしてClaude Code本体です。/deep-planの外部レビューを使う場合のみ、GeminiまたはOpenAIのAPIキーを任意で設定します。プラグインやフックの仕組みそのものが初めてなら、冒頭で挙げたClaude Code本体の実装手引きで土台を作ってから導入するとスムーズです。
既存の Claude Code 運用との接続
Deep Trilogyは、いま広がりつつあるSkills／Pluginエコシステムの一部として読むと位置づけが鮮明になります。スキルが「何を知っているか（知識ユニット）」を担うのに対し、Deep Trilogyのプラグインは「どういう順序で進めるか（ワークフロー）」を束ねている、という違いです。
たとえばClaude Skillsを徹底解説｜スキルはフォルダで押さえた「SKILL.mdはただのフォルダ」という前提は、Deep Trilogyを理解する土台になります。Lamb氏自身、SKILL.mdはオーケストレーター（指揮役）であってロジックエンジンではない——決定的ロジックはテスト済みスクリプトに置き、Claudeには判断と調整だけを任せる——という設計原則を強調しています。
デザイン領域でこの考え方を体現したのがdesigner-skillsとは｜デザイン237スキルをClaude Codeに教えるOSSプラグイン集です。「専門知識をスキル化して配る」designer-skillsと、「専門的な進め方をプラグイン化して配る」Deep Trilogyは、同じエコシステムの別の断面と言えます。
制限と注意点——beta版・個人作という前提
採用前に押さえておくべき制約を、誇張なく整理します。
第一に、3本ともbeta版（/deep-project 0.2.1、/deep-plan 0.3.2、/deep-implement 0.2.1、いずれも2026年6月時点）です。仕様やコマンドが今後変わる可能性があり、本番の重要プロジェクトにいきなり全面適用するより、小さなサイドプロジェクトで挙動を確かめるのが安全です。
第二に、Anthropic公式ではなくPierce Lamb氏個人の制作物です。MITライセンスなので利用・改変・フォークは自由ですが、サポートやメンテナンスは個人の裁量に依存します。
第三に、Python 3.11+とuvが前提です。これらが入っていない環境ではセットアップの段階でつまずきます。Lamb氏もブログで「ユーザー環境の検証はセットアップセッションの最初に行うべき」と、有限なコンテキストの奥で失敗しないための早期バリデーションの重要性を説いています。
全自動ではない
Deep Trilogyは意図的にインタビューやコードレビューで停止し、人間の入力を求めます。「投げて放置」を期待すると肩透かしを食らいます。逆に言えば、要所で判断を挟みたい開発者にこそ向く設計です。
これからの Skills／Plugin エコシステム文脈
Deep Trilogyが示すのは、Claude Codeの使い方が「1つの巨大プロンプト」から「役割を分けた小さなプラグインの連携」へ移りつつある流れです。Lamb氏のブログにある技術的な学びは、この潮流を象徴しています。
たとえばClaudeのTask APIに頼ると40以上のツール呼び出しが連鎖してハルシネーションに弱くなるため、セッションスクリプトがタスクファイルを直接ディスクに書く方式に切り替えた、という話。あるいはサブエージェントは構造化出力モードを持たないため、SubagentStopフックで.jsonlの対話ファイルから出力を抽出してファイルに書く、という工夫。いずれも「決定的な処理はコードへ、判断はLLMへ」という境界線を引き直す試みです。
この設計思想は、ツール・スキル・サブエージェントで肥大化したエージェントを分解する考え方とも通じます。エージェント設計の解剖学に踏み込みたい読者はツール・スキル・サブエージェント——肥大化したエージェントを解剖するAnthropicワークショップ実録もあわせて読むと、Deep Trilogyの構造判断の背景が見えてきます。プラグインを「配る」標準化の動きについてはSkillは標準仕様になる｜Googleが公式Agent Skillsリポジトリを公開も参考になります。
まとめ
Deep Trilogyは、Claude Codeの弱点だった「あいまいなアイデアの一気実装」を、分解・計画・実装の3プラグインに分けて埋める実践的な解です。要点を振り返ります。
・/deep-projectがbroadなアイデアを独立specに分解し、/deep-planがTDD計画とセクションに落とし、/deep-implementがテスト先行で実装する3段パイプライン
・工程の受け渡しはファイルベースで、どこで中断しても同じコマンドで再開できる
・外部LLMレビューやインタビューで人間の判断を要所に残す「human-in-the-loop」設計
・3本ともMIT・Python 3.11+・beta版で、Anthropic公式ではなくPierce Lamb氏個人の制作物
・「決定的ロジックはスクリプト、判断はClaude」という境界線が、Skills／Pluginエコシステム全体の設計指針になっている
まずは小さなサイドプロジェクトで/deep-projectから試し、分解の質を体感するのがおすすめです。気に入ったら/deep-plan・/deep-implementまで通して、「vague idea → 本番コード」の一気通貫を確かめてみてください。
参照ソース
・piercelamb/deep-project — 入口プラグイン公式リポジトリ（MIT License、141★／2026年6月実測）
・piercelamb/deep-plan — 計画プラグイン公式リポジトリ（MIT License、99★）
・piercelamb/deep-implement — 実装プラグイン公式リポジトリ（MIT License、54★）
・The Deep Trilogy: Claude Code Plugins for Writing Good Software Fast — Pierce Lamb氏による3プラグイン連携の解説
・What I Learned While Building a Trilogy of Claude Code Plugins — プラグイン開発の技術的学び
