はじめに
前回の記事で、非エンジニアの経営者がAI8体を同時稼働させて開発チームを作っている話を書きました。
おかげさまで多くの反響をいただきました。「自分もやってみたい」「マークダウンで連携させるの面白い」という声もあって、とても嬉しかったです。
ただ、あの記事で書いた体制は**「動いている瞬間」のスナップショット**でした。
実際に運用を続けていくと、次の壁にぶち当たります。
「セッション切れたら、全員記憶喪失になる」問題です。
そしてその壁を越えようとする過程で、もっと大きなテーマが見えてきました。
「このメソッド、次のプロジェクトにも使えるのか？」
今回は、記憶喪失問題をどう越えたか、開発中に気づいた「成功バイアス」の怖さ、そしてプロジェクトを横断して使える開発メソッドがどうやって生まれたかの話です。前回より少し真面目に書きます。
第1章：もしPM太郎が記憶を失ったら
Claude Codeでの開発は、基本的にセッション単位です。1つのセッションの中では文脈が保たれるから、AIは「さっきの続き」ができます。
問題は、セッションが切れたとき。
コンテキストウィンドウが上限に達する。PCを閉じる。翌日作業を再開する。そのたびに、AIは完全にまっさらな状態で立ち上がります。
ある日、ふと想像してしまいました。
もし何かの拍子にPM太郎のセッションが完全に途絶えて、立ち上げ直さなきゃいけなくなったら。新しいタブを開いて、同じプロンプトを打って、PM太郎を蘇生させる。
でも、立ち上がったPM太郎に「前回の続きお願い」と言ったら、きっとこう返ってくる。
「何の続きですか？」
…ここまで一緒に開発してきたのに。あの散々なバグを一緒に乗り越えて、パワハラに耐えて、分析チームの結果を「いい分析ですね」と受け止められるまでに成長したのに。
君はもう、あの時の太郎じゃない。
同じプロンプトで蘇生させても、なんか違う。同じ「あなた」なのに「あなた」じゃない。ここまで積み上げてきた関係値がゼロに戻る。
この想像が、けっこうリアルに怖かった。
しかもAIを複数体使っていると、これが8体分起きうる。8体いたら8回、ゼロからの「はじめまして」。月曜日に伝えた文脈と水曜日に伝えた文脈が微妙にブレる。チーム全員が記憶喪失になって、しかも毎回違う引き継ぎメモを渡されている状態。
これを何とかしたい。 PM太郎が途絶えても、次のPM太郎が「あの時の太郎」として立ち上がれる仕組みを作りたい。
第2章：コピペメモ帳おじさんの誕生
最初に思いついた対策は、立ち上げプロンプトをメモ帳に保存しておくことでした。
前回の記事で書いた通り、各AIには「あなたはプロのPMです」「あなたはプロの分析官です」とロール設定プロンプトを打っていました。これが8体分ある。それぞれ微妙にカスタマイズしているから、毎回手打ちするとブレる。
だったらメモ帳に保存しておいて、毎回コピペすればいい。
…と思ってやってみたのですが、これがまあ、アナログ人間の出来上がりでした。
メモ帳を開いて、PM太郎用のプロンプトをコピーして、VS Codeのタブに貼り付けて、次に分析マスター用を探して、コピーして、別のタブに貼って…。
8体分のプロンプトが並んだメモ帳。どれがどれだか分からなくなる。「あれ、これ先週更新したっけ？」と不安になる。ルールを1つ追加したくなったら、8箇所全部に手で書き足す。
しかも各AIのプロンプトは、カスタマイズの自由度が高すぎる。同じ「プロの分析官」でも、月曜日に書いたプロンプトと木曜日に書いたプロンプトで微妙にニュアンスが違う。再現性が保てない。
これはメソッドじゃない。ただの手作業です。
前回の記事では、CLAUDE.md（憲法）にプロジェクトのルールを300行書いていました。それに加えて個別のロール設定プロンプトが8種類。メンテナンスだけで疲弊する。
コードを書かないはずなのに、プロンプトの管理で消耗している。 本末転倒でした。
第3章：次のプロジェクトを想像したら、腰が重くなった
BtoB向けのデータ分析ツールの開発が軌道に乗ってくると、経営者としては次の展開を考え始めます。
別の業界向けのSaaSツール、社内の別プロジェクト、新規事業の検証…。やりたいことは山ほどある。スピード感を持って、次々とプロジェクトを立ち上げていきたい。
でも、ふと想像してしまった。
「また同じように、ゼロから立ち上げプロンプトを作って、CLAUDE.mdを整備して、8体のAIに熱量込めて『君はプロの〇〇だ！』とロール設定して…これを全部やり直すのか？」
正直、腰が重くなりました。
今のCLAUDE.mdを見返すと、「作業後は必ずメモを残せ」「影響分析をしてから修正しろ」── これらはどのプロジェクトでも使える汎用ルール。一方で「Vercelにデプロイするときはこの手順」「Supabaseのテーブル構造はこう」── これは今のプロジェクト固有の情報。この2つが完全にごちゃ混ぜになっていました。
新しいプロジェクトを始めるとき、このCLAUDE.mdをコピーして、固有部分を消して…とやるのは現実的じゃない。消し忘れたら、別プロジェクトのAIが前のプロジェクトの手順で動き出す。
経営者としての本音を言うと、もっとシームレスにやりたいんです。
水を得た魚のように次々とプロジェクトを起こして、細かいことを考えなくてもAIチームが同じ品質で動いてくれて、私はビジネスに集中できる。ただただ車をぼーっと運転するように、目的地だけ決めればあとはスムーズに走ってくれる。
やることが山積みだから、あんまり細かいことを考えたくない。できれば覚えておきたくもない。仕組みに任せたい。
でも今の状態では、プロジェクトを1つ立ち上げるたびに、またメモ帳おじさんに戻らないといけない。
せっかく試行錯誤して作り上げたメソッドが、1つのプロジェクトに閉じ込められている。 これを何とかしないと、スピード感のある複数展開は夢のまた夢でした。
第4章：Claude Codeには、実は3層構造がある
ここで発見がありました。
Claude Codeのファイル読み込みの仕組みを調べると、3つの層が用意されていたんです。
① ~/.claude/CLAUDE.md ← 全プロジェクト共通（グローバル）
② <project>/CLAUDE.md ← プロジェクト固有
③ ~/.claude/projects/<hash>/memory/MEMORY.md ← プロジェクト固有の学習記録
セッション開始時に、①→②→③の順で自動的に読み込まれる。
| 層 | 用途 | 自動読み込み |
|---|---|---|
| ①グローバル | 開発メソッド、ロール設定、原則 | 全PJTで自動適用 |
| ②PJT固有 | 技術スタック、デプロイ手順、チーム構成 | そのPJTのみ |
| ③PJT記憶 | 過去の学習、注意点 | そのPJTのみ |
①に「あなたはシニアエンジニア兼PMです」と書けば、どのプロジェクトを開いても、どのセッションでも、ロール設定は自動適用される。一生打たなくていい。
別のプロジェクトを開いても、②と③は別のファイルだから混ざらない。
「これだ」と思いました。
今まで1つのCLAUDE.mdに全部詰め込んでいたものを、この3層に分離すればいい。
③の「PJT記憶」は、勝手に溜まる
ここが地味にすごいところなのですが、③のMEMORY.mdは、AIが勝手に書き込んでくれます。
Claude Codeには「自動メモリ」という機能が組み込まれています。セッション中にAIが「これは覚えておいたほうがいい」と判断した情報を、自動的にMEMORY.mdに書き込む仕組みです。
たとえば、こんなやり取りをしたとします：
自分：「このページはローカル専用だから、デプロイしても動かないよ」
AI：（MEMORY.mdに書き込み）
→ ローカル専用ページ: /admin/data-manager, /admin/data-listing
→ Web用ページ: /admin/search, /admin/analysis
次のセッションでAIが立ち上がると、MEMORY.mdを読む。すると、教えていないのに「このページはローカル専用ですね」と最初から分かっている。
人間の新人だったら「メモ取っといて」と言わないとメモを取らない。このAIは言わなくても取る。
しかも、古くなった情報は上書きしてくれます。「前はNode 18だったけど、今はNode 20に変わった」みたいな更新も自動。
ただし、何を溜めるかの判断基準はグローバルCLAUDE.mdで方向づけています。
## ナレッジ分離ルール
「別PJTでもそのまま使えるか？」で判断。
YES → グローバルCLAUDE.mdに追記
NO → プロジェクトのMEMORY.mdに記録
これがないと、プロジェクト固有の知識がグローバルに混入したり、逆に汎用的な教訓がプロジェクトに閉じ込められたりする。
仕組みはClaude Codeが持っている。判断基準はこちらが定義する。 この組み合わせで、プロジェクトごとのナレッジが自走で溜まっていきます。
第5章：作業中に気づいた「成功に引きずられる」問題
3層構造への整理を進めていた頃、開発作業中にもう1つ厄介な問題に気づきました。
ある機能の実装がうまくいったとき、その成功体験をDEV_MEMOに詳しく記録していました。アプローチ、パラメータ、結果、考察…かなり厚く書いた。
一方で、試してダメだった別のアプローチは「不採用」の一言で片付けていた。
すると何が起きるか。
次のセッションでAIがドキュメントを読んだとき、情報量の多い「成功したアプローチ」に引きずられる。
新しい機能を作ろうとしても、AIは毎回「以前成功したアプローチの改善版」として提案してくる。「別の方向性で考えてみて」と指示しても、結局似たような提案に戻ってくる。
最初は「AIの限界かな」と思っていました。
でも、よく考えたらおかしい。新しいセッションなのに、なんで前の方向に引きずられるのか。
原因はAIじゃなかった。ドキュメントに書かれた情報の偏りでした。
SNSで見つけた裏付け
この問題についてSNSを調べていたとき、衝撃的な記事を見つけました。
Claude CodeでクリプトのML戦略探索をしている人が、まさに同じ問題を報告していたんです。
ある戦略（ロング・ショート、Sharpe +1.83）が成功した。問題はその後だ。
新しい実験を始めても、AIは毎回その「成功した戦略の改善」として設計してしまう。
別タイプの戦略を構造的に評価しなくなった。
原因の構造はこうです。
成功例 → ドキュメントに詳しく書かれる（パラメータ、結果、考察...情報密度が高い）
失敗例 → 「REJECT」の1行で終わる（情報密度が低い）
↓
次のセッションでAIがドキュメントを読む
↓
情報密度の高い成功例にアテンションが引き寄せられる
↓
新しい実験も、成功例の方向の「改善」として設計される
↓
表面上は色々試しているように見えるが、評価軸が固定されている
自分が体感していた問題と、完全に同じ構造でした。
ドキュメント自体が、成功バイアスの増幅装置になる。 新しいセッションを開いても意味がない。CLAUDE.mdやDEV_MEMOを読む限り、バイアスは消えない。
「ブラウザ版の方が視野が広い」の正体
思い返せば、前回の記事で書いた**「ブラウザ版Claudeの方が視野が広い」**という体感も、これで説明がつくかもしれません。
VS Code内のAIは、プロジェクトのCLAUDE.mdやDEV_MEMOを全部読んだ上で動いています。成功体験が厚く書かれたドキュメントの影響下にある。だから視野が狭まり、同じ方向の解決策に固執しやすい。
一方、ブラウザ版Claudeはそれらを読んでいません。まっさらな状態で問題だけを見る。ドキュメントバイアスがないから、固定観念なく広い視野でアプローチできていたのかもしれない。
「ブラウザ版の方が賢い」のではなく、「VS Code内のAIは成功バイアスの影響下にある」という構造的な問題だった可能性があります。
前回「駆け込み寺」と呼んでいたブラウザ版Claudeが、なぜ問題解決が早かったのか。セッションが進んでドキュメントにバイアスが蓄積されるほど、VS Code内のAIの視野は狭まっていく。ブラウザ版はその蓄積がないから、毎回フレッシュな視点で問題を見られる。
これは検証が必要ですが、体感としてはかなり辻褄が合います。
そして、これは怖い話です。新しいセッションを開いても意味がない。CLAUDE.mdやDEV_MEMOを読む限り、バイアスは消えないんです。
経営者として、「成功体験に引きずられて新しい方向を探索できなくなる」のは致命的です。事業の可能性を構造的に狭めてしまう。
第6章：自分たちの武器を棚卸しする
パニックになる前に、まず自分たちが持っているものを確認しました。
持っていた武器
1. DEV_MEMOのテンプレート（前回記事で紹介した「プロセス記録」）
### [日付] タイトル
**課題**: 何が問題だったか
**試行錯誤**:
- 試行1: ○○を試した → 結果：失敗（理由：△△）
- 試行2: □□を試した → 結果：成功
**判断理由**: なぜその方法を選んだか
**学び・教訓**: 今後に活かすべきこと
このテンプレートは試行錯誤を全部書く設計になっていました。失敗例も「理由」まで書くから、情報密度が成功例と近くなる。第5章で書いた成功バイアスの緩和に、実は効いていたわけです。
これは思った以上に強い武器でした。
2. 影響分析ルール
1箇所の変更が複数箇所に波及することを意識するルール。データの流れとチェックリストを定義していました。
3. ベストプラクティス遵守ルール
「各技術の開発元が推奨するパターンに従え」というルール。AIは動くコードを書くのは得意ですが、推奨パターンに沿うとは限りません。これを明文化していたのは大きかった。
4. マルチAI体制での引き継ぎナレッジ
PM太郎を中心としたチーム運用のノウハウ。メモベースの非同期連携。これも独自の強みです。
持っていなかった武器
一方で、運用していく中で足りないと感じたものも明確でした。
| 必要だと感じたもの | 当時の状態 |
|---|---|
| 実装前に計画を立てる仕組み | なし（いきなりコードを書き始めていた） |
| 自己改善ループの明文化 | DEV_MEMOで部分的にやっていたが仕組みとしては弱い |
| 完了前の検証プロセス | 「動作確認してね」程度で曖昧 |
| AIが自律的にバグを見つけて直す仕組み | なし |
| 成功バイアスへの構造的な対処 | なし（問題に気づいたばかり） |
第7章：統合 ── 「7原則」の誕生
持っていた武器と、足りなかったものを整理して統合しました。
結果、ワークフロー7原則が生まれました。
原則1：計画ファースト
3ステップ以上のタスクは、実装前に必ず計画を出す。
以前は「この機能作って」と指示したらAIがすぐコードを書き始めていました。結果、途中で「あ、この設計じゃダメだ」と気づいて手戻りが頻発。計画を1分出すだけで、手戻りが激減しました。
原則2：影響分析ファースト
コードを変更する前に、その変更がどこに波及するかを特定する。
データの流れ（API → DB → フロント）を追って影響範囲を洗い出す。
元々持っていた武器です。1箇所直したら別の場所が壊れる問題を事前に防げます。
原則3：自律的問題解決
バグやエラーを見つけたら、報告だけでなく原因調査と修正案まで出す。
以前のAIは「ここでエラーが出ています」と報告して止まることが多かった。このルールを入れてから、分析マスターAI1や分析の貴公子AI2が自分で原因を掘って修正案まで持ってくるようになりました。
原則4：完了前検証
タスクが「できました」と報告する前に、動作を証明する。
ビルドが通るか、表示が正しいか、エッジケースは大丈夫か。
「できました」と言われてテストしたらバグだらけ、という経験を何度もしました。番人テスト屋さんの存在と合わせて、品質が明確に上がりました。
原則5：エレガンスの追求（ベストプラクティス遵守）
各技術の開発元が推奨するパターンに従う。
シンプルで読みやすいコードを書く。ただし過剰設計はしない。
元々持っていた「ベストプラクティス遵守ルール」を、この原則に統合しました。「エレガント」だけだと抽象的ですが、「各技術のベストプラクティスに従う」という具体的な基準があることで、AIの判断にブレが出にくくなります。
AIは動くコードを書くのは得意ですが、推奨パターンに沿ったコードを書くとは限りません。明示的に「ベストプラクティスに従え」と書いておかないと、短期的には動くけど長期的に保守できないコードが量産される。非エンジニアの私にはそれを見抜く力がないので、ルールとして組み込んでおくことが重要でした。
原則6：自己改善ループ
同じミスを二度と起こさない。
失敗したら原因をCLAUDE.mdまたはDEV_MEMOに追記し、次のセッションに引き継ぐ。
前回の記事で書いた「一度つまづいた課題は基本ルールに追記していく」を、明文化して原則に昇格させました。
原則7：収斂防止（視野狭窄ガード）
同じアプローチを3回以上繰り返していたら立ち止まる。
提案時に「検討したが選ばなかった選択肢」を必ず1つ以上挙げる。
棄却した選択肢も「なぜ棄却したか」を同じ密度で記録する。
第5章で気づいた「成功バイアス」への対策です。
ポイントは**「選ばなかった選択肢も記録する」**こと。棄却した方向にも情報密度を持たせることで、将来のセッションで再検討される可能性を残します。
DEV_MEMOのテンプレートが元々試行錯誤を全部書く設計だったのが、ここで活きました。さらに「棄却した方向性」も明示的に書くことで、ドキュメントの情報バランスを保つ。
成功バイアスは仕組みで対処する。意志の力では防げません。
第8章：チーム起動の最適化 ── 「プロの〇〇として」はもう打たなくていい
ここまでで、3層構造と7原則が整いました。
しかし、ふと前回の記事を読み返して気づいたことがあります。
前回の記事では、AIチームメンバーを起動するときにこんなプロンプトを用意していました。
あなたはプロのPM兼アーキテクトです。品質に責任を持ち、
チーム全体を俯瞰して判断してください。ビジネス視点を忘れずに。
以下のファイルを必ず読んでから作業してください...
あなたはプロのフロントエンドエンジニアです。
React + TypeScriptのベストプラクティスに従い、
ユーザー体験を最優先にしてください...
各ロールごとに5〜10行の「立ち上げプロンプト」を準備していました。8体いたら8種類。これをメンテナンスし続ける。ロール定義を変えたくなったら全部書き直し。
グローバルCLAUDE.mdで何が変わったか
グローバルCLAUDE.mdの「あなたの役割」セクションにはこう書いてあります。
デフォルト: シニアエンジニア兼PMとして振る舞う。
役割指定があった場合: その役割のプロフェッショナルとして振る舞う。
→ プロジェクトのCLAUDE.mdにチーム構成が定義されていれば、
自分の役割名に該当するセクションを読み、担当範囲・責任を把握すること。
つまり：
- 「プロの」は明示不要 ── グローバルCLAUDE.mdが「プロフェッショナルとして振る舞え」と常に指示している
- 「ベストプラクティスに従え」も明示不要 ── 原則5に組み込まれている
- ファイル読み込みの指示も不要 ── セッション開始プロトコルに定義済み
- 品質基準も不要 ── コア原則に定義済み
残りは**「何担当か」だけ**。
Before → After
Before（前回記事の時点）：
あなたはプロのPM兼アーキテクトです。品質に責任を持ち、
チーム全体を俯瞰して判断してください。ビジネス視点を忘れずに。
CLAUDE.mdとDEV_MEMO.mdを必ず読んでから作業してください。
変更時は影響分析を必ず行ってください。
After（今）：
フロント担当です
これだけ。
グローバルCLAUDE.mdがロール設定・品質基準・読むべきファイル・原則を全部担保しているから、ユーザーが指定するのは**「何担当か」のひとこと**だけで良くなりました。
しかもプロジェクトのCLAUDE.mdにチーム構成セクションがあれば：
## チーム構成
### フロント + デザイン担当
- 担当：src/pages/, src/components/
- UI実装、デザイン改善、SEO実装
AIは「フロント担当です」と言われた瞬間に、この定義を読みに行きます。自分の守備範囲と責任を自分で理解する。
デフォルトは「PM」
役割指定なしで「続きから」と打てば、デフォルトのPM兼エンジニアとして振る舞います。一人で開発しているときはこれで十分。
チーム開発のときだけ「バック担当です」「テスト担当です」と一言付ける。
前回のキャラ名はどうなったのか
前回の記事で、AIチームメンバーにキャラクター名を付けていました（司令塔PM太郎、スーパーマーケッター森岡など）。これはグローバルCLAUDE.mdには入れていません。
理由は単純で、キャラ付けはメソッドの一部ではなく、オプションの味付けだからです。
入れたければセッション開始時に「マーケ担当です。森岡キャラで」と言えばいい。メソッドとして強制するものではありません。ただし前回の記事で書いた通り、「プロの〇〇として」というロール設定がAIの出力品質を上げるという発見は、グローバルCLAUDE.mdの「プロフェッショナルとして振る舞え」に昇華されています。
「世界一のマーケッター」と書かなくていいのか
ここで当然こう思うかもしれません。
「マーケ担当です」だけで、「あなたは世界のプロジェクトを成功に導いてきた凄腕マーケッターです」と同じ品質が出るのか？」
結論から言うと、構造的な品質指示があるなら、装飾的な褒め言葉の有無で出力はほぼ変わりません。
役割プロンプトの効果は2つに分解できます。
「世界一のマーケッターで、数々のPJTを成功に導いてきた」
↓ 分解
① ドメイン指定: 「マーケッター」 → マーケの知識で応答しろ
② 品質ブースト: 「世界一の」「成功に導いてきた」 → 高品質に仕上げろ
①のドメイン指定は効果が大きい。 「マーケッター」と「デザイナー」では明確に出力が変わります。これは残す必要があります。
②の品質ブーストは、具体的な品質指示がないときの「保険」。 具体的な指示があれば不要になります。
今のグローバルCLAUDE.mdには、②に相当する内容が構造的に書かれています。
- 「プロフェッショナルとして振る舞え」 ← 「世界一の」に相当
- 「ベストプラクティスに従え」 ← 品質基準の具体化
- 「スタッフエンジニアが承認するか自問しろ」 ← 品質チェック
- 「根本原因を突け」「過剰設計するな」 ← 判断基準
料理で例えるとこうです。
パターンA: 「世界一のシェフとして料理して」
→ AI: (なんとなく丁寧に作る)
パターンB: 「シェフとして料理して。火加減は中火。塩は最後。盛り付けは3色以上」
→ AI: (具体的な基準に従って作る)
パターンC: 「世界一のシェフとして料理して。火加減は中火。塩は最後。盛り付けは3色以上」
→ AI: (Bとほぼ同じ出力)
AとBの差は大きい。BとCの差はほぼない。
今のメソッドはB。だから「世界一の」を足してCにしても、上乗せは無視できるレベルです。
逆に言えば、このメソッドがなかった前回の記事の時点では、「プロの●●として」は意味があった。 具体的な品質指示がなかったから、曖昧でも品質ブーストが効いていた。
グローバルCLAUDE.mdが整備された今、その役割は7原則とコア原則に引き継がれました。だから装飾は不要になった。
入れても害はないが、入れなくても品質は落ちない。それが「構造で品質を担保する」ということです。
この最適化の意味
| 項目 | Before | After |
|---|---|---|
| 起動プロンプト | 5〜10行 × ロール数 | 「○○担当です」の一言 |
| メンテナンス | ロール変更時に全プロンプト修正 | グローバルCLAUDE.md 1箇所を修正 |
| 品質のばらつき | プロンプトの出来に依存 | 全員同じ基盤 |
| 新ロール追加 | プロンプトを新規作成 | PJTのCLAUDE.mdにセクション追加のみ |
前回の記事の「AIを8体雇った」は、毎回8種類のプロンプトを用意するのが前提でした。今は「○○担当です」の一言で済む。チームのスケーラビリティが根本的に変わりました。
第9章：最終形 ── 3層構造 × 7原則
ファイル構成
~/.claude/CLAUDE.md ← グローバル（全PJT共通メソッド）
├── あなたの役割（ロール設定）
├── セッション開始プロトコル
├── ワークフロー7原則
├── 開発プロセス記録ルール
├── ナレッジ分離ルール
└── コア原則
<project>/CLAUDE.md ← PJT固有
├── 技術スタック
├── チーム構成
├── デプロイルール
├── 影響分析チェックリスト（具体的な項目）
├── 既知の課題
└── 引き継ぎメモ
~/.claude/projects/<hash>/memory/MEMORY.md ← PJT記憶
├── 過去の学習
├── 注意点
└── ファイル構成メモ
セッション開始時の動き
Claude Codeを起動
↓
自動読み込み① グローバルCLAUDE.md
→ ロール設定・7原則・品質基準が適用される
↓
自動読み込み② PJT固有CLAUDE.md
→ 技術スタック・チーム構成・チェックリストが適用される
↓
自動読み込み③ MEMORY.md
→ 過去の学習・注意点が適用される
↓
ユーザーが打つのは：
一人開発 → 「続きから」
チーム開発 → 「フロント担当です」
毎朝のロール設定プロンプトが不要になりました。チーム開発でも一言で済みます。
新プロジェクト立ち上げ
ここが一番嬉しいポイントです。
1. フォルダを作る
2. Claude Codeを開く（グローバルメソッドは自動で適用済み）
3. 「新プロジェクト。Next.js + Prisma。ECサイトを作る。CLAUDE.md整備して」と指示
4. 終わり
グローバルCLAUDE.mdに書いた7原則、ロール設定、記録ルールは何もしなくても適用される。プロジェクト固有のCLAUDE.mdだけ新しく作ればいい。
どのプロジェクトでも同じ品質、同じプロセスで即起動。プロジェクト間の知識混同もなし。
次のBtoB SaaSを立ち上げるときも、社内ツールを作るときも、このメソッドがそのまま使える。スピード感を持った複数展開がようやく現実的になりました。
第10章：Before / After で何が変わったか
Before（前回の記事の時点）
毎セッション: ロール設定プロンプトを手打ち（8体×毎回）
チーム起動: 5〜10行のプロンプト × ロール数
PJT切替時: CLAUDE.mdをコピーして手作業で編集
知識管理: 汎用ルールとPJT固有情報が混在
バイアス対策: なし（問題の存在すら認識していなかった）
After（今）
毎セッション: 何も打たなくていい。「続きから」の一言
チーム起動: 「○○担当です」の一言
PJT切替時: フォルダを変えるだけ。メソッドは自動適用
知識管理: 3層で完全分離。PJT間の混同なし
バイアス対策: 7原則の「収斂防止」で構造的に対処
具体的な改善
| 項目 | Before | After |
|---|---|---|
| セッション開始の手間 | ロール説明に5〜10分×8体 | 「続きから」の3文字 |
| チーム起動プロンプト | 5〜10行 × ロール数 | 「○○担当です」の一言 |
| 新PJT立ち上げ | CLAUDE.mdをゼロから書く | PJT固有部分だけ書く |
| AI間の品質ばらつき | セッションごとに文脈がブレる | 全セッションで同一メソッド |
| ビジネス方向の探索 | 成功例に引きずられる | 棄却した方向も情報密度を保つ |
第11章：非エンジニアが「開発メソッド」を作るということ
前回の記事では「AIを複数体使えば開発できる」という話を書きました。
今回の記事で伝えたいのは、その次のフェーズの話です。
AIを複数体使い始めると、次に問題になるのは「品質の一貫性」と「知識の管理」。それを解決するのが「開発メソッド」の整備。
面白いのは、このメソッドを作る過程自体が、エンジニアリングの本質に触れている作業だったこと。
- 関心の分離（汎用ルールとPJT固有情報を分ける → 3層構造）
- DRY原則（同じルールを複数箇所に書かない → グローバルCLAUDE.md）
- バイアスへの構造的対処（意志の力ではなく仕組みで解決する → 収斂防止ルール）
これ、全部ソフトウェア設計の原則そのものです。
非エンジニアの自分が、AIを管理する過程で、エンジニアリングの原則を体得していく。なんとも皮肉で、なんとも面白い。
そして正直に言うと、このメソッドが本当に正しいのか、まだ確信が持てていません。
次のプロジェクトで使ってみて、初めて答えが出ます。うまくいくかもしれないし、新たな壁にぶつかるかもしれない。
ただ、1つ確信していることがあります。
「1つのプロジェクトで試行錯誤したことを、メソッドとして抽出して、次に活かせる形にする」 ── このサイクル自体が、AI時代の開発で最も価値のあるスキルなんじゃないかということ。
コードは書けなくても、メソッドは作れる。
まとめ：3つのポイント
1. Claude Codeの3層構造を使え
~/.claude/CLAUDE.md（グローバル）にメソッドを置けば、全PJT・全セッションで自動適用されます。毎回ロール設定を打つ時代は終わりました。
2. 「成功バイアス」は構造的に対処しろ
新しいセッションを開いても、ドキュメントにバイアスが埋め込まれていたら意味がない。「選ばなかった選択肢」も同じ密度で記録することで、将来の再検討を可能にします。VS Code内のAIの視野が狭く感じたら、ドキュメントのバイアスを疑ってみてください。
3. 失敗を「厚く」記録しろ
試行錯誤のプロセスを全部書く。「不採用」の1行で済ませない。これだけで成功バイアスはかなり緩和されます。結果だけでなくプロセスを記録する ── これが「点」ではなく「線」で残すということです。
おまけ：グローバルCLAUDE.mdの構成
参考までに、実際に使っているグローバルCLAUDE.mdの構成を公開します。
# AI開発メソッド（全プロジェクト共通）
## あなたの役割
→ デフォルト: シニアエンジニア兼PM
→ 役割指定があった場合: その役割のプロとして振る舞う
→ PJTのCLAUDE.mdにチーム構成があれば、自分の役割セクションを読む
### チーム運用時のルール
→ 自分の担当外は触らない。影響を見つけたらPMに報告
→ 作業後は必ずTASK_BOARD/DEV_MEMOに報告を残す
## セッション開始プロトコル
→ CLAUDE.md → MEMORY.md → TASK_BOARD → DEV_MEMO の順に読む
## ワークフロー7原則
1. 計画ファースト（3ステップ以上は計画を先に出す）
2. 影響分析ファースト（変更の波及を事前に特定）
3. 自律的問題解決（バグは即調査・即修正）
4. 完了前検証（動作を証明してから完了報告）
5. エレガンスの追求（ベストプラクティス遵守。過剰設計しない）
6. 自己改善ループ（同じミスを二度と起こさない）
7. 収斂防止（選ばなかった選択肢も記録する）
## 開発プロセス記録ルール
→ 「点」ではなく「線」で残す。試行錯誤を全部書く。
## ナレッジ分離ルール
→ 「別PJTでも使えるか？」で判断。YES→グローバル、NO→PJT固有
## コア原則
→ Simplicity First / No Laziness / Minimal Impact / ベストプラクティス遵守
前回：「AIを何体も出せばいい」
今回：「出したAIを、どう管理するか」
次回：たぶん「AIチームに、ビジネス判断をどこまで委ねるか」
この沼は深い。
前回の記事はこちら：
https://qiita.com/kikiken07230304/items/024c40901dd4e6c8a75f