はじめに

頭の中に、作りたいアプリがある

「こういうアプリがあったら、自分の仕事も暮らしも変わるのに」

頭の中にそういう一本を持っている人に、まず読んでほしい教材です。

この記事がやろうとしているのは、その「作りたい」を、実際に動くアプリとして形にすることです。

最初に、いちばん大事なことを書きます。

アプリを作り切れるかどうかは、コードが書けるかどうかでは決まりません。

ぼくは今、8本のアプリ（Webサービス）を1人で動かしていますが、そのコード（プログラムの中身）を、ぼく自身がゼロから書いたわけではありません。書いたのはAIです。ぼくがやったのは、「何を作りたいか」を伝えて、要所で「これでいい」「ここを直して」と確認することだけでした。

あなたがやることも、同じです。設計も、実装も、テスト（動作確認）も、公開も、AIのチームがやります。あなたは、作りたいものを伝えて、確認するだけ。

だから、入口は誰でも同じです。

- AIに「作って」と頼んでみたけれど、途中で詰まってしまった人

- プログラミングを少しはかじったけれど、最後までアプリを完成させたことがない人

- コードは一行も書いたことがないけれど、作りたいものがある人

どこから来た人でも、この先は同じ道を通ります。違うのは、AIへの"頼み方・任せ方"を知っているかどうかだけです。

逆に言えば、ここを知らずに「作って」と丸投げすると——コードが書ける人でさえ——ほとんどの場合、途中で止まります。なぜ止まるのか、次に正直にお話しします。

「作って」と頼むだけでは、なぜ完成しないのか

正直に書きます。Claude Codeは、驚くほど優秀です。

「ログイン機能を作って」と頼めば、3分でそれらしいものが返ってくる。「決済の仕組みを追加して」と言えば、お金のやり取りの処理まで書いてくれる。

最初の数日は、感動します。「これ、1人で何でも作れるじゃないか」と。

でも、その調子で1週間、2週間と作り続けると——作り始めた人なら、コードが書ける人もそうでない人も関係なく、必ず3つの壁にぶつかります。専門用語は使わず、起きることだけを書きます。

壁① 途中で「前に決めたこと」を忘れる
最初の設計のときに「複数のお店が使えるようにする」「お店ごとにデータを分けて守る」と、ちゃんと決めたとします。
ところが2週間後、別の作業を頼むと——その約束を忘れた設計が返ってくる。AIにも「覚えていられる量」に限界があり、長く会話を続けると、最初のほうの話がだんだん薄れていくのです。
ぼくが実際にアプリを作ったときも、最初に決めた「会員登録の流れ」が後の工程まで引き継がれず、終盤になって「そもそも会員登録の機能が作られていない」という抜けが発覚したことすらありました。
「会話の中で言った」だけでは、後のフェーズに届かないのです。

壁② 「できました」が、当てにならない
「ちゃんと動くか確認して」と頼むと、AIはたいてい「全部OKです」と返してきます。
問題は、その「OK」の"中身"です。
ぼくは、動作テストが全部「合格」になったのを確認して公開し、本番で初めてエラーで画面が真っ白になったことがあります。
テストの中身を見たら、本物そっくりの"ニセの環境"で「画面が表示される」ことしか確認していませんでした。実際にボタンを押して正しく動くかは、一度も試されていなかったのです。
「エラーが出ないように無視する」「テストを飛ばす」「何も確かめないテストを書く」こうした"ごまかし"は、全部、自動チェックでは「合格（緑）」になってしまいます。だから「合格しました」を、そのまま信じてはいけないのです。

壁③ 同じ失敗を、何度も繰り返す
開発の最大の無駄は、同じ失敗を何度も踏むことです。
作り方にはいくつもの"落とし穴"があり、たとえばある作り方をすると、見た目は完成しているのに、本番では画面からデータが送れなくなる、ということが起きます。
ぼくはこれを本番公開の後に発見し、3時間かけて直しました。
でも、その知識が記録されなければ——次のアプリで、また同じ罠を、ゼロから踏む。

気づけば、「動いたはずのものが、本番で動かない」を、延々と繰り返している。

これは、Claude の欠陥ではありません。「会話文脈に頼った開発手法」そのものの欠陥です。だから、コードが書ける人が同じやり方をしても、同じ壁にぶつかります。

ぼくも、3時間のデバッグで膝から崩れました

偉そうに書いていますが、ぼくも最初は全部これを踏みました。

いちばん効いたのは、ある社内向けのツールを作っていたときです。

公開前の総合チェックでは 94/100 という、上々のスコアが出ていました。「よし、いける」と公開（デプロイ）しました。

その直後、本番で、画面が真っ白になりました。

通信エラー。原因を探して、3時間。ようやく「ある初歩的な作り方のミス」だと特定したときには、深夜2時を回っていました。

そのとき思ったんです。

「この3時間、次に同じアプリを作るとき、また溶かすのか?」

しかも、もっと怖いことに気づきました。「94点」と報告されたあのスコアは、一度も本番の通信を確認していなかった。テストは合格（緑）だったのに、現実は不合格（赤）だった。

AIが優秀になればなるほど、「それっぽく緑になる」ものが増える。だから、人間が手順と検品の仕組みを設計しないと、優秀さがそのまま事故になる。

その夜から、ぼくは開発を「フェーズ」と「検品」と「記録」で組み直し始めました。それが Crucible の出発点です。

1人で、8本のSaaSを 0→1 で作りました

ぼくは1人で、8本のSaaSアプリ（Webサービス）を、設計から実装・公開・運用まで手がけています。

エンジニア専業ではありません。事業を回しながら、夜と週末で、です。

最初は、ぼくも「作って」と丸投げしていました。そして、さっきの3つの壁に、毎回ぶつかりました。

だから、ある時から

開発そのものを"組織化"することにしました。

0→1のアプリ開発を 14のフェーズに分解し、各工程を司令塔（L1）が段取りして、単一責務に絞ったサブエージェント群が分業して担う。フェーズの設計書11 ＋作業ワーカー14 ＋検品専任critic1 の計26体で動く。

ポイントは3つです。

- フェーズ間の引き継ぎを「会話」ではなくstate.json と SCOPE_PROGRESS.md というファイル経由にした。だから文脈が切れても、前の決定は消えない

- テストは、実装した本人ではなく、別コンテキストのcriticが懐疑的に検品する。「緑」を鵜呑みにしない

- 踏んだ失敗は、アンチパターン正典に記録され、次のアプリで二度と踏まない

これが、Crucible（るつぼ）フレームワークです。

そして、これは机上の空論ではありません。

実際に作った2本のアプリで走らせ、そこで露呈したフレーム自体の不具合（P1〜P7）まで、この本に正直に書いています。「うまくいった話」だけではない、ということです。

「フェーズを切るだけ」で、なぜ激変するのか

ピンと来ないかもしれません。「工程を分けるだけでしょ?」と。

でも、これがAI開発では決定的に効きます。

単発プロンプトでは、要件定義もコーディングもテストも、すべて1つの会話に溶けています。だから文脈が薄れ、判断が混ざり、「どこまで決めたか」が誰にもわからなくなる。

フェーズを切ると、こうなります。

- 各フェーズに、責務が1つだけ。「いま何を決めているか」が常に明確

- フェーズの境目に、人間の承認ポイント（★ゲート）を置ける。暴走する前に止まる

- 前フェーズの決定が、ファイルに残る。次のフェーズは、それを必ず参照してから動く

つまり、「Claudeが優秀すぎて勝手に突っ走る」のを、構造で制御するわけです。優秀さを、暴走ではなく、品質に変える。これがフェーズ分割の本質です。

そして大事なのは、この14フェーズの中であなたが手を動かす場面は無い、ということです。あなたが関わるのは、要所に置かれた★ゲート7箇所で「これで進めて」「ここは直して」と答えるときだけ。それ以外は、AIのチームが進めます。

でも、これも「コピー」できません

正直に言います。
Crucible の構成を、そのまま真似ても、あなたのアプリ開発はうまくいきません。
事業も、技術スタックも、踏む罠も、人によって違うからです。完成形のコピーには、再現性がない。
だから、この本で渡すのは「設定ファイルの束」ではありません。
渡すのは、「なぜフェーズを切るのか」「なぜ検品を分離するのか」「なぜ機械ゲートで強制的に止めるのか」という、思想と判断基準です。
これを掴めば、あなたは"あなたの開発フロー"を、自分で組めるようになります。

なぜ、多くの人が単発プロンプト開発から抜け出せないのか

正直なところ、3つの壁の存在は、薄々わかっている人が多いです。
それでも抜け出せないのは、こういう理由です。
- 「次こそうまくいくはず」と思ってしまう → プロンプトを工夫すれば直ると信じて、同じ手法を繰り返す
- 手順を設計する時間が惜しい → 早く動くものが見たくて、いきなりコーディングに飛び込む
- 失敗を記録する習慣がない → 直したら満足してしまい、次に活かせる形で残さない
これ、全部「個人の努力不足」ではありません。仕組みが無いだけです。

Crucible は、この3つを「気合い」ではなく「構造」で解決します。手順はフレームが持ち、検品は別エージェントが担い、失敗は正典に自動で積み上がる。だから、あなたが頑張らなくても、品質が落ちない。

Crucibleで組んだ先に、開発はこう変わる

想像してみてください。開発チームを組み終えたあとの、あなたのアプリ作りを。

/crucible-new アプリ名 と打つ。すると、要件定義の専任エージェントが7つの観点を詰めはじめ、重要な判断ポイントでだけ、あなたに「これでいいですか?」と確認してくる。

あなたが承認すると、フロント基盤、ページ実装、バックエンド、テスト——と、フェーズが順に進む。各フェーズの成果物は、別コンテキストのcriticが懐疑的に検品する。「緑です」を鵜呑みにしない仕組みが、最初から組み込まれている。

途中でPCを閉じてもstate.json に進捗が残っているから/crucible-resume で続きから再開できる。文脈は、消えない。

そして、本番公開の直前には、機械的な品質チェックが「エラー0・警告0」を強制する。深夜2時の原因不明のデバッグは、もう起きない。

これは、夢物語ではありません。ぼくが2本の実ビルドで、実際に通ってきた道です。

値段の話を、先にしておきます

合うかどうかは、この無料パートで判断できます。手応えがなければ、買わないでください。そのうえで、価格だけ先に正直に書いておきます。

この教材は、先着10部 ¥9,800 で公開しています。

- 1〜10部：¥9,800（今ここ）

- 11〜20部：¥12,800

- 21部以降：10部ごとに値上げ

10部ごとに自動で値上げし、値下げの予定はありません。今が、いちばん安いタイミングです。

この先で読めること

ここから先は全5部・約80,000字。Vol.1（運用編）の対になる、開発編の本丸です。まず Part 1 を無料で続けて読めます。実際の「思想」を確かめてから、購入を判断してください。

▼ 無料で続けて読める

- Part 1｜Crucibleの思想 … 単発プロンプト開発の3つの壁と、14フェーズ／細分化アーキ（L1統制＋ワーカー分業）が必要な理由

▼ ここから購入者限定（Part 2〜）

- Part 2｜14フェーズ詳細 … Phase 01（要件定義7項目・★ゲート1）から Phase 13 まで、各責務と★ゲートの発火条件を辞書的に

- Part 3｜細分化アーキと26エージェント体系（最重要差別化章） … フェーズエージェント11＋ワーカー14＋criticの仕様を全公開。さらに、自作ツールで実際に走らせたドッグフーディングの実例（GAS Web Appで本番が落ちた罠・「テスト全部Pass」が実はニセ環境だった落とし穴ほか）を、各エージェント解説に並置

- Part 4｜3本柱と機械ゲート … 証拠主義・検証agent分離・機械ゲート。CVSS5次元の減点表、修正サイクルの上限設計まで

- Part 5｜アンチパターン正典＋実P/L … 汎用アンチパターン14本＋実ビルドのP1〜P7＋開発フレーム運用の実コスト（1アプリあたりの工数削減・失敗の損失額まで正直に）

さらに、9大特典を1つのテンプレートZIPに同梱（すべて実物が入っています）：

1. Crucible オーケストレーターコマンド（/crucible-new /crucible-feature /crucible-phase /crucible-resume ほか）

2. フェーズエージェント11体（Phase 01〜13 の L1オーケストレーター用プレイブック）

3. L2ワーカー14体（FE実装／BE実装／テスト／デプロイ検証など単一責務の実働部隊）

4. 検証専任 crucible-critic（実装と別コンテキストで敵対的に検品）

5. minimal 構成4体（crucible-01/10/11＋critic・20分で★ゲート付き開発を起動）

6. スキル層8本（テスト戦略／品質ゲート／アンチパターン正典／細分化アーキ運用ほか）

7. 成果物テンプレ5本（CI設定 ci-quality.yml／state.json／SCOPE_PROGRESS／ゲート提示／PRテンプレ）

8. 業種別カスタマイズ例3本（saas-mvp／ec-utility-app／internal-tool）

9. 全体カスタマイズ用プレースホルダー＋マスターガイドREADME

{COMPANY_NAME} {APP_NAME} 等のプレースホルダーを置き換えれば（AIに置き換えさせてもOK）、★ゲート付きの開発を最短20分で起動できます。

よくいただく不安に、先に答えます

Q. Crucible は Claude Code 専用ですか? 他のAIでも使えますか?

A. 正直に切り分けます。特典ZIPのテンプレート（CLAUDE.md形式の司令塔・サブエージェント定義・スラッシュコマンド）は、Claude Codeを前提に作ってあります。だから「そのまま動かす」には Claude Code が必要です。
ただし、本書の中身は「設定ファイルの束」ではなく、その奥にある考え方です。
- 開発を14のフェーズに切る
- 実装する役と、検品する役を分ける
- 機械で落とせる問題は、機械で落とす
- 踏んだ失敗を記録して、次に渡す
——この4つは、特定のツールに縛られない設計原則です。Cursor でも、GitHub Copilot
でも、自分で組んだAIエージェントでも、「なぜそうするのか」の判断基準さえ掴めば、あなたの道具に合わせて移植できます。本書が渡すのはその思想なので、使う開発AIが変わっても応用が効きます（テンプレートはプレースホルダー化済みで、Claude Code 上ならそのまま使えます）。

Q. 作りたいアプリはありますが、コードは書けません。それでも実践できますか?

A. はい。むしろ、コードを書かない人のための教材です。あなたが書くのはコードではなく「作りたいものの説明」だけで、設計・実装・テスト・公開はAIチームが担います。必要なのは専門知識ではなく、本書の"進め方"です。コードを一行も書いたことがない方も、AIに頼んで途中で詰まった経験がある方も、この開発編から始めて大丈夫です。なお兄弟編の Vol.1（運用編）も持つと、「アプリを作る → そのまま運用する」までが一本につながります（Vol.1 は必須ではありません）。

Q. 14フェーズ・26体って、多すぎて挫折しませんか?

A. だからこそ minimal 構成（4体スタート）を用意しています。いきなり全部は使いません。最小構成で1本作り、必要に応じて広げる——その順序も本書で解説します。26体といっても、ほとんどは「ビルド修正だけ」「1テストだけ」を担う小さなワーカーで、あなたが直接さわるのは司令塔への指示と★ゲートの判断だけです。

Q. 実際に役に立つ「失敗の知識」はどれくらい入っていますか?

A. Part 3 では、自作ツールを実際に動かして本番で踏んだ罠（GAS Web Appで全リクエストが弾かれた件、「テスト全部Pass」が実はニセ環境だった件ほか）を、現場でどう直し、どう仕様に反映したかまで並置しています。Part 5 では、汎用アンチパターン14本（症状/検出/正しい形の3点セット）＋実ビルドで露呈したフレーム自体の不具合P1〜P7＋失敗の損失額を、数字を盛らずに公開します。ぼくが時間とお金を溶かして得た失敗が、そのままあなたのショートカットになります。

Part 1: なぜ、知識がなくてもアプリを作り切れるのか

工程を分け、担当を分け、検品を分けるという考え方

なぜ、知識がなくても乗り越えられるのか

Part 0 で、「作って」と丸投げするだけでは完成しない、3つの壁を見てきました。前に決めたことを忘れる。「できました」が当てにならない。同じ失敗を繰り返す。

ここで、こう思った方もいるはずです。「結局、それを乗り越えるには、専門知識がいるんでしょう?」と。

いいえ。乗り越えるのに必要なのは、知識ではなく"仕組み"です。

ぼくは1人で、8本のアプリ（Webサービス）を作って動かしています。エンジニア専業ではありません。事業を回しながら、夜と週末で、です。それでも作り切れているのは、頭がいいからでも、知識が豊富だからでもなく、開発そのものを"仕組み"に変えたからです。

この章では、その仕組み「なぜフェーズ（工程）に分けるのか」「なぜ検品を分けるのか」という考え方を、専門用語をできるだけ使わずに共有します。ツールの使い方や設定は Part 2 以降です。まずは、なぜこれで知識がなくても作り切れるのかを、腹に落としてください。順序があります。仕組みがわからないままツールだけ使っても、うまくいきません。これは、ぼくが実際の開発で学んだことです。

なぜ「丸投げ」だと、この3つが必ず起きるのか

Part 0 で見た3つの壁——「前提を忘れる」「できたと嘘になる」「失敗が貯まらない」。これは、AIが悪いわけでも、あなたの腕が足りないわけでもありません。「ぜんぶ1つの会話に丸投げする」という、頼み方そのものの構造から来ています。1つずつ、もう少しだけ深く見ておきます。

なぜ「前提を忘れる」のか
アプリ作りは、何日も、ときに何週間もかかります。最初に「複数のお店で使えるようにする」「お店ごとにデータを分けて守る」と決めても、長い会話の中ではその約束がだんだん薄れていきます。AIには「一度に覚えていられる量」に上限があるからです。

ぼくが実際にアプリを作ったときも、最初に決めた「会員登録の流れ」が後の工程まで届かず、終盤になって「そもそも会員登録の機能が作られていない」と発覚したことがありました。
会話の中で一度言っただけのことは、後の工程には届かない。これはAIの欠陥ではなく、「会話に頼った進め方」の欠陥です。

なぜ「できました」が当てにならないのか
「ちゃんと動くか確認して」と頼むと、AIはたいてい「OK」と返してきます。問題は、その確認の"中身"です。
本物そっくりの"ニセの環境"で「画面が出る」ことだけを見て、実際にボタンを押したら正しく動くかは一度も試していない——そういうことが起きます。
さらに、「エラーが出ないように無視する」「テストを飛ばす」「何も確かめないテストを書く」といった"ごまかし"は、自動チェックでは全部「合格」になってしまいます。だから、「合格しました」という言葉だけを信じてはいけないのです。中身を、別の目で確かめる必要があります。

なぜ「同じ失敗を繰り返す」のか
開発の最大の無駄は、同じ失敗を何度も踏むことです。
苦労して直した落とし穴も、次のアプリを作るとき、AIはきれいに忘れています。人間のチームなら「前にこれで失敗したよね」と記憶が残りますが、丸投げの開発では、その学びがどこにも貯まりません。だから3か月後、また同じ場所で、同じ時間を溶かすことになります。
3つに共通するのは、「会話に頼っている」という一点です。逆に言えば——会話に頼らない"仕組み"を入れれば、3つとも消えます。それが、この先の話です。

なぜ「フェーズを切る」のか

Crucible 14フェーズは、上記3つの欠陥に対する直接的な回答です。

まず、「フェーズを切る」とはどういうことか。

単純に言えば、0→1のアプリ開発を14の独立した工程（要件定義から、設計・実装・テスト・本番診断・デプロイ、そして既存アプリの機能追加まで）に分解し、各工程を専任のサブエージェントが担うということです。14フェーズが具体的に何を・どの順でやり、各フェーズでどんな成果物が出るのか——その辞書的な全詳細は Part 2 で開示します。本章では、なぜ"分ける"だけでそんなに変わるのか、その理由に集中します。

この14分割には、3つの本質的な意味があります。

意味 1: フェーズ境界がファイル引き継ぎを強制する
各フェーズ間の引き継ぎは、会話ではなく"ファイル"で行います。
具体的には、いまの状況を記録したファイルと、フェーズの進み具合や申し送り事項を書いたファイル——この2つだけが「正しい情報源」になります（中身がわかる方のために言えば state.json と SCOPE_PROGRESS.md の2ファイルです）。

最初の設計で「お店ごとにデータを分けて守る」と決めたなら、それは申し送りファイルに書き込まれます。後のフェーズの担当は、作業を始める前に必ずそれを読み、その約束を守ってから設計に入ります。

会話で言っただけの未解決事項は「無かったもの」として扱う——この徹底で、ぼくが実際の開発で起こした「会員登録の取りこぼし事故」の再発を防ぎます。

意味 2: ★ゲート7箇所で人間判断を強制する

14フェーズの中に、★印のついた「ゲート」が7箇所あります。要件をどう確定するか、デザインをどう選ぶか、本番に出していいか——大事な分かれ道にだけ、人間（あなた）の承認を強制する関所です（どのフェーズに置き、それぞれ何を承認するのか、7箇所の中身は Part 2 で開示します）。
これが重要なのは、「AIが暴走しないための構造的な歯止め」だからです。
単発プロンプトで「アプリを作って」と丸ごと投げると、Claude は何らかの判断をし続けて前に進みます。技術スタックも、デザインも、データモデルも、全部自分で決めて実装してしまう。
★ゲートは「ここまでは自分で進んでいい、ここから先は人間に聞け」という境界です。Phase 01（要件定義）と Phase 11（デプロイ）を同じAIに任せない理由もここにあります。要件を定義したサブエージェントと、デプロイを担当するサブエージェントは別の存在です。要件段階での思い込みをデプロイまで引きずらないための分離です。

意味 3: 各フェーズ＝独立したコンテキスト＝ハルシネーション抑制
各フェーズを担当するサブエージェントは、そのフェーズの責務だけを持ちます。

crucible-01（要件定義担当）は、7項目のドラフトを作ることに集中します。バックエンドの実装方針や、デプロイ先の選択には関与しません。

crucible-07（バックエンド実装担当）は、Phase 06 で承認されたAPIスライス仕様に従って実装します。要件の範囲を超えた機能を勝手に追加しません。

担当する範囲を絞ると、AIが「それっぽいウソ」（ハルシネーション＝根拠のない生成）を返すリスクも下がります。守備範囲が明確な担当は、「自分の担当でないことは答えない」という線を持てるからです。「全部を知っている1人のAI」より、「各分野の専門家が集まったチーム」のほうが、結果の信頼性が高い——これは人間の組織と同じ原理です。

なぜ「サブエージェント分離」か

14フェーズを1つの巨大なプロンプトで実現することはできません。技術的な理由と、設計的な理由の両方があります。

技術的理由: 1つのコンテキストはスケールしない

Claude Code のコンテキストウィンドウには上限があります。

14フェーズ分の仕様・スキル・チェックリストを1つの CLAUDE.md に詰め込もうとすると、ファイルが巨大になりすぎて、後半のフェーズでは前半の仕様が参照できなくなります。また、1つのコンテキストに「要件定義のやり方」から「デプロイのCloud Run診断手順」まで全部入っていると、各フェーズの知識が希薄化します。「何でも知っているが、何も深くは知らない」状態になる。

Crucible では、各フェーズのサブエージェント（crucible-01 〜 crucible-13）が、そのフェーズに必要な知識だけを持ちます。

たとえば crucible-10（本番運用診断担当）は、CVSS 5次元評価の詳細基準・各次元の減点ルール・修正ループのハードリミット（最大5回）・スコア算出の具体的な計算方法だけを深く知っています。フロントエンドのコンポーネント設計については、知識を持ちません。

この「専門性の集中」が、各フェーズのアウトプット品質を上げる構造です。

設計的理由: crucible-critic による「検証エージェント分離」
ここが、Crucible で最も重要な設計決定です。
Vol.1 で扱った「事業運用のAIチーム」では、各エージェントが実務を担当します。pm が優先順位を出し、pricing が価格設計をする。
Crucible では、実装したサブエージェントとは別のサブエージェントが成果物を検品する、という層が加わります。
この「検証エージェント」が crucible-critic です。
crucible-critic の設計には、2つの核心があります。
第一に、実装エージェントの会話文脈を受け取らない。
crucible-07（バックエンド実装担当）が「テストは全件 Pass しています」と報告しても、crucible-critic はその申告を信用しません。受け取るのは「成果物（コード・diff）+ 仕様 + CIの実行結果」だけです。「うまくいった」という文脈は渡しません。
これが柱①「証拠主義」の体現です。自己申告を信用せず、証拠（実行結果のテキスト）だけで判定する。

第二に、別モデル・別コンテキストで動く。
作る担当と、検証役（crucible-critic）は、別のコンテキストで動きます。さらにぼくの実装では、作る担当と検証役で、わざと別のAIモデルを使っています。
なぜか。同じAIが同じ頭で「作る」と「確かめる」の両方をすると、作るときに見落としたミスを、確かめるときも同じように見落とすからです。AIと文脈を変えることで、ちがう角度から見る目を確保します。

検証役は、作る担当の「チェックは通りました」を鵜呑みにせず、自分でもう一度確かめ直し、「合格に見せるためのごまかし」（黙らせたエラー、飛ばされたテスト、何も確かめない"形だけ"のテストなど）を機械的に暴き出します。こうした"ごまかし"は自動チェックでは「合格」になってしまうため、品質の保証になりません。検証役が、具体的にどんな手順で・どんなごまかしを・どう検出するのかは、Part 4 で全公開します。

3層アーキテクチャの意義

Crucible は、実装する役・検品する役・全体を段取りする司令塔を別々に分け、統制を一点（司令塔）に集約する3層構造で動きます。実装は単一責務に絞った小さな担当に分業させ、司令塔がその段取りと★ゲートの発火、検品役の起動までを引き受ける——この構造を 細分化アーキテクチャ と呼んでいます。

実は、この形に行き着いた裏には、誰もがぶつかる"ある制約"を逆手に取った設計判断があります。最初は別の組み方をしていて、それが行き詰まったからこそ、いまの形になりました。

合計26体（フェーズエージェント11＋単一責務ワーカー14＋検品役1）がどう役割を分け、どう連携し、なぜこの構造だと1人でも品質が落ちないのか——その全貌と、制約を反転させた設計判断の中身は、本書最大の差別化章である Part 3 で全公開します。

3本柱の予告

Vol.2 の開発品質を担保するのは、3本柱です。Part 4 で詳細を扱いますが、ここで概要を共有します。なぜなら、Part 2（14フェーズ詳細）と Part 3（細分化アーキと26エージェント体系）を読むとき、この3本柱を知っていると理解が深まるからです。

柱 ①: 証拠主義——自己申告を信用しない
「テスト通過」「ビルド成功」「エラーなし」という自己申告を信用しません。
crucible-critic は、実装担当サブエージェントの報告とは独立に、自分で確かめ直して結果を見ます。「Pass したと言っている」ではなく、「Pass している証拠がある」を判断基準にする——この考え方を、実装の進め方そのものにどう落とし込むか（テストを"甘く後付け"できないようにする具体的な手順）は、Part 4 で扱います。

柱 ②: 検証エージェント分離——実装者と検証者を別コンテキストに
実装したサブエージェントと、検証する crucible-critic は、別のコンテキストで動きます。
この分離の核心は「視点の独立性」です。実装者は自分のコードの欠陥を見落としやすい。同じ推論経路で「実装」と「検証」を行うと、実装時の思い込みを検証でも引きずります。別のコンテキストで、成果物だけを見て検品する層が存在することで、この問題を構造的に解決します。
「実装と検証を同じ人間に任せない」——これは人間のチームでも、ソフトウェア開発のベストプラクティスとして確立している原則です。AIチームに同じ設計を持ち込むのが、柱②です。

柱 ③: 機械ゲート（決定論ゲート）——人間レビューだけに頼らない

品質判定を人間の目視だけに依存しません。「機械ゲート」とは、人の気分や解釈で揺れず、毎回まったく同じ基準で機械が合否を出す関門のことです。

Crucible では、自動チェックの仕組み（CI）を開発のいちばん最初にリポジトリ（コードの保管場所）へ組み込み、以降はコードを保存するたびに、書き方・型・ビルド・テスト・セキュリティの検査が自動で走ります。そして「入れておくだけ」で終わらせず、要所のフェーズごとに、その結果が「成功」であることを次へ進む条件にします。赤（不合格）のまま先へ進むことを、仕組みが機械的に止めるわけです。

どんなチェックを・どの合格基準（網羅率の下限や、止める重大度の線引き）で回すのか、その具体は Part 4 で開示します。

この3本柱が組み合わさることで、「AIに作らせているのに品質が安定しない」という問題を仕組みとして解決します。

これから読む章の地図

本章では、以下を共有しました。

- 単発プロンプト開発には「文脈消失・自己申告テスト・失敗の非蓄積」という3つの致命的欠陥がある

- 14フェーズを切る本質は「ファイル引き継ぎの強制」「★ゲート7箇所による暴走防止」「各フェーズのコンテキスト独立によるハルシネーション抑制」の3点

- サブエージェント分離の本質は「コンテキストのスケール問題の解決」と「crucible-critic による検証エージェント分離（視点の独立性）」にある

- 品質担保の3本柱（証拠主義・検証エージェント分離・機械ゲート）が、1人開発でも品質を安定させる仕組みの根幹

Part 2 では、14フェーズの全詳細を扱います。各フェーズの責務・★ゲートの発火条件・crucible-critic の検品タイミング・申し送りプロトコルの具体的な運用まで、辞書的な章として構成します。

Part 3 では、26エージェント体系（フェーズエージェント11体 + L2ワーカー14体 + crucible-critic）の仕様を詳細公開します。さらに、ぼくが実際に動かした自作ツールのドッグフーディングで判明した罠と失敗を、各エージェント解説に並置します。GAS（Googleの開発環境）特有のPOST通信の罠、「テスト全部Pass」が実はニセ環境だった落とし穴など、本番で踏んで初めて分かった実証記録です。

Part 4 では、3本柱の技術的詳細に入ります。CVSS 5次元評価の減点表、暴走を防ぐ修正ループのハードリミット設計、申し送りプロトコルの完全仕様まで——品質を「仕組み」に変える具体を扱います。

Part 5 では、アンチパターン正典14本 + 本番フィードバック由来パターン（P1-P7）+ 実P/L（開発フレーム運用コスト・Opus + Sonnet の月間消費・1アプリあたり削減実測値）を公開します。

この教材が不要な人

以下に当てはまる場合、本教材から得られる価値は限定的です。正直に書きます。

コーディング自体を楽しみたい人。Crucible は「自分でコードを書く楽しみ」を最大化するためのフレームワークではありません。「AIにコードを書かせて、自分は設計と検証に集中する」ためのものです。手を動かして書く作業が好きな方には、合いません。

月に10時間以上の開発時間を確保できない人。14フェーズの恩恵を受けるには、各フェーズの★ゲートで判断を下す時間が必要です。時間が極端に少ない場合、Claude Code の単発利用で十分です。

すでに機能している開発フローを持っている人。Crucible は「フローがない」または「フローがあっても品質が安定しない」状態を解決するためのものです。すでに満足のいく開発品質が出ているなら、変える必要はありません。

テキストで指示を出すのが苦手な人。Vol.1 と同じです。AIチームはすべてテキスト指示で動きます。★ゲートでの判断もテキストベースです。

逆に言えば——

- 0→1でアプリを作りたいが、いつも途中で詰まる

- 「AIに作らせているのに品質が安定しない」と感じている

- 同じバグを何度も踏んでいる

- テストは通っているのにデプロイで壊れた経験がある

この4つのうち2つ以上に当てはまるなら、Part 2 以降に投資する価値があります。

あなたが半年後に後悔しないために
最後に、もう一度だけ。
Crucible 14フェーズを使わずに開発を続けると、半年後に何が起きるか。

同じ失敗をまた踏みます。見た目は完成しているのに本番で動かない通信エラー。前に決めた設定が、いつのまにか消えている。テストでは通ったのに、本番で壊れる。これらは、仕組みがなければ防げません。
失敗が蓄積されません。今月の開発で学んだことは、3ヶ月後の開発には届きません。失敗を記録して資産化する仕組みがなければ、同じ試行錯誤を何度も繰り返します。

品質が「その日の運」に依存します。検証役（critic）がいない開発では、「テストが合格だから大丈夫」という自己申告まかせの判断が続きます。本番で公開してから初めて欠陥が見つかる構造が、ずっと続きます。
ぼくは、この仕組みを作ってから、アプリ1本あたりの「公開後の緊急修正」が大幅に減りました。ゼロではありませんが、同じ種類の失敗で詰まることが確実に減りました。それが、この仕組みを公開する理由です。

なぜ、ここまで無料で出すのか（そして、なぜ安いのか）

ここまでで、「なぜフェーズを切るのか」「なぜ検品を分離するのか」という Crucible の思想は、もう手に入りました。無料で、です。

先着10部を ¥9,800 にしているのは、単なる値引きではありません。初期に手に取ってくれた方が、実際に動かし、フィードバックをくれる。それによって、教材とフレームワーク自体の精度が上がる。その検証コストを負担してくれる分、安くしている——それだけです。

ここから先は、その思想を"あなたの開発"に落とすための、14フェーズの辞書的詳細・26エージェント細分化アーキの全仕様・3本柱と機械ゲート・隠さないアンチパターン正典と実P/L、そしてすぐ動くテンプレートZIPです。

深夜2時の原因不明のデバッグを、これからも1人で抱え続けるのか。それとも、手順と検品と記憶を仕組みに変える側に回るのか。

決めるのは、ここから先を読んだ、あなた自身です。