TL;DR
Claude Code は放っておくと設計を飛ばしてひたすら実装する。LAM（Living Architect Model）は、3フェーズの承認ゲート・3視点での意思決定・TDD 強制・Subagent の自動割り当てによって、Claude Code を「コーディングマシン」から「設計者」に変えるフレームワーク。個人〜小規模開発向け。使うほどプロジェクト固有の知識が蓄積されてフレームワークごと育つので “Living” と名付けた。
GitHub: https://github.com/sougetuOte/LivingArchitectModel
はじめに
Claude Code を使っていて、こんな経験はないだろうか。
- ちょっとした機能追加のつもりだったのに、気づいたらテストもないコードが大量にできていた。
- 仕様書を書いたはずなのに、実装が終わる頃には中身が全然違うものになっていた。
- 前に決めたことを AI が覚えていなくて、同じ議論を何度もやり直した。
私も全部やった。今はLAMがあるのでやらかすことはほぼほぼなくなった。
Claude Code は優秀だ。言われたことを高速に、高品質に実装してくれる。ただ、放っておくと「言われたことをひたすら実装するマシン」になる。設計を飛ばす。テストを後回しにする。ドキュメントを忘れる。人間がやりがちなことを、AI もまた同じようにやるのだ。
この問題をどうにかしたくて作ったのが Living Architect Model（LAM） だ。
概念の説明スライドも置いてあるので、ざっくり知りたい方はそちらからどうぞ。
LAM に至るまでの話
claude-friends-templates — 最初の試みと失敗
LAM の前に、claude-friends-templates というリポジトリを作っていた。
きっかけは Vibe コーディングでの「長期記憶」の問題だった。Claude Code はセッションが切れると文脈を忘れる。長期的なプロジェクトだと、毎回同じ説明をするのが面倒になる。Cline で公開されていた長期記憶のマニュアルを参考にして、Claude Code 向けに似たようなものを作り始めた。
ここまではよかった。
Claude Code の新機能が出るたびに追従して、hooks を追加し、commands を追加し、あれもこれもと付け足していった。結果、複雑になりすぎて破綻した。 何でもできるようにしようとした結果、設定ファイルが肥大化し、何がどこにあるのかわからなくなった。
「全部入り」は個人開発には重すぎた。これが最初の、そして一番大きな教訓だった。
反省から生まれた LAM
claude-friends-templates の失敗から学んだことは割とシンプルだった。
スコープを絞ること。個人や小規模開発に必要なものだけにする。バイナリは入れない。テキストファイルだけで完結させて依存を最小限にする。プロジェクトの成長に合わせてルールを変えられる構造にする。そして何より、AI の暴走を止める仕組みが要る。フェーズ管理と承認ゲートで「うっかり実装」を防ぐ。
こうして LAM が生まれた。
LAM の仕組み
CLAUDE.md — プロジェクトの「憲法」
LAM の中心にあるのは CLAUDE.md だ。Claude Code がプロジェクトを読み込んだとき、最初に参照するファイル。プロジェクトにとっての 「憲法」 みたいなものだと思ってもらえればいい。
ここで大事なのは、Claude に対して「お前はコードを書く人じゃない」と宣言しているところだ。Claude の役割は「プロジェクト全体の整合性を守る設計者（Architect）であり門番（Gatekeeper）」と定義している。
真実の優先順位も決めてある。
ユーザーの意志が最優先、次にプロセス文書、それから仕様書、最後に既存コード。コードと仕様が矛盾したら、仕様が正しい。
あと、「覚えているはず」に頼らず、必ずファイルを検索・確認してから回答すること。これだけで Claude の振る舞いはかなり変わる。
「コーディングアシスタント」から 「設計者」 への役割の転換だ。
3フェーズ + 承認ゲート
LAM は開発プロセスを PLANNING、BUILDING、AUDITING の3つのフェーズに分けている。
- PLANNING では要件定義・設計・タスク分解をやる。コード生成はやってはいけない。
- BUILDING では TDD で実装する。仕様なしの実装はやってはいけない。
- AUDITING ではレビューと監査をやる。コードの直接修正はやってはいけない。
で、ここが肝なのだが、各サブフェーズが終わるたびに承認ゲートが入る。ユーザーが「承認」と言わないと次に進めない。
要件定義が終わったら承認。設計が終わったら承認。タスク分解が終わったら承認。実装が終わったら承認。そして監査。
これにより「まだ要件が固まってないのに実装が始まっていた」という事故を防ぐ。PLANNING フェーズで「実装して」と頼むと、Claude は警告を出して選択肢を提示する。意図的に進めることもできるが、少なくとも「意識せずに飛ばす」ことはなくなる。
全自動にならないのは制約でもあるが、同時に安全装置でもある。「全部任せて寝て起きたら完成」にはならない。が、寝て起きたら仕様と違うものができていたという事故も起きない。個人開発ではこのバランスがちょうどいいと思っている。
3 Agents Model — 一人ブレストの仕組み
個人開発で困るのは、設計のレビュー相手がいないことだ。自分一人で考えていると、どうしても盲点が出る。
LAM には重要な意思決定のとき、Claude が3つの視点で議論する仕組みがある。推進者（Affirmative）がメリットを主張し、批判者（Critical）がリスクを指摘し、調停者（Mediator）が両者を統合して結論を出す。
たとえば認証方式を選ぶとき。推進者が「JWT はステートレスでスケーラブル」と言う。批判者が「トークン漏洩リスクや XSS の懸念がある」と指摘する。調停者が落とし所をまとめる。一人で考えるより穴が減るし、少なくとも「考慮すべきだったのに見落としていた」というケースがかなり減った。
lam-orchestrate — タスクの分解と並列実行
Claude Code には「Subagent が他の Subagent を呼べない」という制約がある。Anthropic 公式の Agent Teams 機能もあるが、まだ負荷が高い。
そこで作ったのが lam-orchestrate だ。
Skill ファイル（SKILL.md）が Coordinator 役として振る舞い、与えられたタスクを分析して Wave に分解し、適切な Subagent に割り当てて並列実行する。ただ Subagent を呼ぶだけではなく、Coordinator がタスクの性質を見て「これは要件分析が先、設計はその結果を待ってから」といった依存関係を判断してくれるのがポイントだ。
Main Claude が中継することで擬似的な3層構造を実現していて、8種の専門 Subagent（要件分析、設計、タスク分解、TDD 実装、品質監査、ドキュメント作成、テスト実行、コードレビュー）が必要に応じて呼び出される。
実行前に必ず計画を提示して承認を得るので、何が起こるかわからないまま走り出すということはない。途中で要件が変わっても「計画変更プロトコル」で対応できる。
小規模開発ならこれで十分だ。将来 Agent Teams がもっと安定して使いやすくなったら、そちらに移行することも考えている。
LAM で楽になったこと
実際に使っていて一番助かっているのは「うっかり実装」がなくなったことだ。3フェーズと承認ゲートのおかげで、仕様を飛ばして実装に入るということがまず起きない。これだけでも作った甲斐がある。
3 Agents の一人ブレストもかなり重宝している。個人開発だとどうしても自分の思い込みで突っ走りがちで、後から「ここ考えてなかった」となることが多かった。今は重要な判断のところで自動的に複数の視点が出てくるので、その手の事故が減った。
ちなみに、最近はこれに加えてGoogleのAntigravityにレビューを依頼することがある。違うAIに頼むとまた別の視点が入りClaudeだけでは出てこないものが浮かび上がる。
TDD が強制されるのも地味に効いている。テストを書かないと実装に進めないので、品質の底上げになる。面倒ではあるが、後で「テスト書いてなかったからどこが壊れたかわからない」という地獄を見ることを考えると、はるかにマシだ。
あと、ドキュメントが腐りにくくなった。仕様とコードをセットで更新するルールがあるので、「ドキュメントと実装が全然違う」という状態になりにくい。完全ではないが、何もルールがない状態よりずっといい。
サイクルを重ねるほど仕様書や ADR（アーキテクチャ決定記録）やルールが溜まっていって、次の開発が速くなるのも実感している。CLAUDE.md や rules/ が使いながら洗練されていく。だから “Living” Architect Model という名前にした。最初はテンプレートだったものが、3サイクルも回せばそのプロジェクト専用の開発ガイドに育っている。
LAM の限界
とはいえ万能ではない。正直に書いておく。
まず、良い仕様を自動で書いてくれるわけではない。ゲートは仕様を「作ること」を強制するが、仕様の「質」はユーザー次第だ。ゴミみたいな仕様を承認すれば、ゴミみたいな実装が出てくる。ここは変わらない。
完璧なコードが出てくるわけでもない。TDD で品質の底上げはするが、設計判断の最終責任は人間にある。承認ゲートがあるということは、承認する人間の判断力がボトルネックになるということでもある。
大規模チーム向けでもない。個人から小規模チーム向けに作っている。CI/CD 統合とか権限管理とかは範囲外だ。
初期の学習コストもある。docs/internal/ に8つのプロセス文書があって、全部読む必要はないが、構造を理解するまでに少し時間がかかる。
要するに LAM は「AI を賢くする魔法」ではない。「AI と人間の協業プロセスを構造化するフレームワーク」だ。プロセスがあることで品質が上がるが、プロセスに乗せるものの質は人間が担保する。ここを勘違いすると期待外れになると思う。
今後のこと
LAM はまだ進化の途中だ。自分で使いながら改善を続けている。
新しい Claude Code の機能が出たり、他の人の開発プロセスで取り込めそうなアイディアを見つけたら、積極的に入れていくつもりだ。Agent Teams が安定してきたらそちらへの移行も検討する。
興味がある方は GitHub のリポジトリを覗いてみてほしい。テンプレートとして使えるようになっているので、自分のプロジェクトに導入して試すこともできる。
概念の説明スライドもあるので、まずはそちらからどうぞ。
この記事の内容は LAM v3.7.0 時点のものです。