AI にプロジェクトの「免疫システム」を持たせたら、開発が壊れなくなった

から | | AI, 技術・コンピュータ・プログラム

はじめに

Claude Code や Cursor で AI と一緒に開発していて、こんな経験はないだろうか。

  • AI が「前に決めた仕様」を忘れて、勝手に別の方向に走り出す
  • 「ちょっと直して」と頼んだら、関係ない部分まで壊れた
  • ドキュメントと実装が乖離して、どっちが正しいのかわからない
  • セッションが切れるたびに、毎回ゼロから説明し直し

AI は優秀なシステムエンジニアであり、プログラマーだ。
でも翌日には「優秀だけど記憶喪失の同僚」になる。
毎回プロジェクトの背景を説明して、やってはいけないことを伝えて、前回の続きを思い出させて……正直、面倒だ。

この問題を仕組みで解決するために作ったのが Living Architect Model（LAM）だ。

以前、LAM の基本コンセプトを紹介する記事を Zenn に書いた。

今回は v4.0.0 で導入した免疫システムを中心に、LAM が「どうやってプロジェクトを守るか」を掘り下げてみる。

LAM をざっくり振り返る

詳しくは前回の Zenn 記事に書いたので、ここでは要点だけ。

LAM は AI を「コードを書く道具」から「プロジェクトの設計者 兼 門番」に変えるプロトコルセットだ。GitHub にテンプレートリポジトリとして公開していて、自分のプロジェクトにコピーするだけで使える。

普通の AI アシスタントは、聞かれたことに答えて、言われた通りにコードを書いて、セッションが切れたら全部忘れる。

LAM を入れると、AI の振る舞いが根本的に変わる。

  • 記憶に頼らず、毎回ファイルを開いて確認してから動く
  • 曖昧な仕様や低品質なコードを通さない
  • 「設計 → 実装 → 監査」の手順を自分から守る
  • コードを変える前に影響範囲を調べる

要するに、AI が作業者ではなく「プロジェクトの番人」になる。

3つのフェーズと承認ゲート

AI に「この機能を作って」と言うと、いきなりコードを書き始める。仕様が曖昧なまま書いたコードは、だいたい後から「そうじゃなかった」になる。

LAM では開発を3つのフェーズに分けて、これを防ぐ。

PLANNING（設計フェーズ）

  • コード生成を禁止
  • 要件定義 → 設計 → タスク分解を、承認ゲートを挟みながら進める
  • 各ステップでユーザーが「承認」と言うまで次に進めない

BUILDING（実装フェーズ）

  • TDD（テスト駆動開発）を厳守
  • テストを先に書いてから実装する Red-Green-Refactor サイクル
  • 仕様書なしの実装は禁止

AUDITING（監査フェーズ）

  • コードレビューと品質チェック
  • 仕様とコードの整合性を検証
  • 問題をリスクレベルで分類（自動修正できるもの / 報告が必要なもの / 人間の判断が必要なもの）

フェーズの切り替えは /planning、/building、/auditing とコマンドを打つか AI に頼むだけ。AI が自動的にモードを切り替えて、フェーズに合った行動をとってくれる。

承認ゲート: 勝手に進ませない仕組み

フェーズを分けるだけでは実は不十分で、AI は「よさそうだからどんどん進めよう」と暴走することがある。PLANNING で仕様を決めている最中に、勝手に設計に入ってしまうこともある。

そこで LAM では、PLANNING フェーズの中にも承認ゲートを設けている。

アイデア → 要求仕様 → [承認] → ADR・設計 → [承認] → タスク分解 → [承認] → BUILDING

ユーザーが「承認」と言わない限り、AI は次のステップに進めない。仕様書を出力したら一度止まって「これでよいですか？」と確認する。設計が終わったらまた止まる。

これにより Claude の手綱を握ることができる。「知らないうちに変な方向に進んでいた」という事故がなくなる。承認の負荷は軽い――内容を読んで「承認」の一言を返すだけだ。でもその一言が、プロジェクトの方向性を人間がコントロールし続けるための安全装置になる。

v4.0.0: 免疫システム

ここからが今回の本題。v4.0.0 で導入したのが免疫システムだ。

人体の免疫と同じ発想で、病原体が入ってきたら自動で検知して排除する――あれをプロジェクトでもやりたかった。

権限等級（PG/SE/PM）

すべてのファイル変更にリスクレベルを自動分類する。

等級対象AI の行動
PG級typo修正、フォーマット調整自動で直す。報告もなし
SE級テスト追加、リファクタリング直した後にユーザーに報告する
PM級仕様変更、アーキテクチャ変更必ず人間の承認がないと進めない

「どこまで AI に任せるか」の線引きが、感覚ではなくルールで決まる。

具体的には、ファイルパスで自動分類される。

docs/specs/*.md    → PM級（仕様書）
docs/adr/*.md      → PM級（アーキテクチャ決定記録）
.claude/rules/*.md → PM級（ルール）
src/**             → SE級（ソースコード）

docs/specs/ を触ろうとしたら、AI が勝手に変えることはできない。必ず「これを変更してよいですか？」と聞いてくる。

Hooks による自動監視

Claude Code の Hooks 機能を使って、AI がファイルを操作するたびに自動チェックを走らせている。

PreToolUse（変更前チェック）
AI がファイルを書き換えようとする瞬間に発火する。対象ファイルのパスを見て権限等級を判定し、PM級なら警告メッセージを返す。

# 例: docs/specs/ への書き込みを検知
if [[ "$file_path" == docs/specs/* ]]; then
    echo "PM級: 仕様書への変更です。承認が必要です。"
fi

PostToolUse（変更後チェック）
テストの失敗→成功パターンを自動記録したり、src/ の変更後にドキュメント更新が必要かフラグを立てたりする。

Stop hook（ループ制御）
/full-review コマンドの自動収束ループを制御する。「監査 → 修正 → 再監査」を繰り返して、問題が0件になったら自動停止。無限ループ防止のため反復回数にも上限がある。

TDD 内省パイプライン

テストの失敗→成功パターンを自動で記録していて、同じ失敗が3回繰り返されると「こういうルールを追加しませんか？」と提案してくる。プロジェクトが経験から学んでいく感じだ。

1回目: パターンを記録
2回目: 観測回数をインクリメント
3回目: ルール候補を自動生成 → ユーザーに承認を求める

承認されたルールは .claude/rules/auto-generated/ に配置され、以降の開発で自動的に適用される。90日以上使われなかったルールは棚卸し対象として通知される。ルールは増え続けるのではなく、新陳代謝する。

Green State: 「完了」の定義

LAM には「Green State」という概念がある。以下の5条件をすべて満たして初めて「完了」と言える。

#条件内容
G1テスト全パスpytest / npm test 等
G2lint エラーゼロruff / eslint 等
G3対応可能 Issue ゼロPG/SE級は修正済み
G4仕様差分ゼロdocs/specs/ と実装の整合性
G5セキュリティチェック通過依存脆弱性 + シークレットスキャン

/full-review コマンドを実行すると、複数のサブエージェントが並列で監査を行い、自動修正→再監査のループを回して Green State に収束させる。人間は他の作業をしていてOK。

セーブ/ロード: セッション切れ問題の解決

Claude Code のセッションは揮発する。長時間の作業でコンテキストが逼迫したり、セッションが切れたりすると、それまでの文脈が失われる。

LAM にはこの問題を解決する4つのコマンドがある。

コマンド用途消費
/quick-save軽量セーブ（SESSION_STATE.md のみ）3-4%
/quick-load軽量ロード~1%
/full-saveフルセーブ（STATE + commit + push）~10%
/full-load詳細確認 + 復帰報告2-3%

この仕組みの詳細は別の Zenn 記事に書いた。

実際の使い方: 5分で始められる

1. テンプレートからリポジトリを作成

GitHub で「Use this template」をクリック。それだけ。

2. Claude Code を起動して /planning

claude

LAM の設定はテンプレートに全部入っているので、初期化コマンドは要らない。

起動したら /planning と打って、作りたいものを伝える。AI が壁打ち相手になって、要件を具体化し、設計書を書き、タスクに分解してくれる。承認ゲートを一つずつ通過していくので、勝手に変な方向に進むことはない。

3. 要件が固まったら LAM を適応

「LAM の全ファイルを確認して、このプロジェクトに必要な部分を適応させて」と伝えれば、AI が CLAUDE.md や README をプロジェクト固有の内容に書き換えてくれる。.claude/ や docs/internal/ といった汎用基盤はそのまま動くので触らなくてよい。

コマンドを覚える必要はない

コマンド一覧を暗記する必要はない。AI に「今何をすべき？」と聞けば、適切なコマンドを教えてくれる。

18リリースの旅

LAM は v1.0.0 から始まった。最初は単なるドキュメント集だった。

バージョン主な追加
v1.xプロトコル文書の整備
v2.0Gemini から Claude Code へ移行
v3.0フェーズ制御、サブエージェント、承認ゲート
v3.3ルールシステム（.claude/rules/）
v3.6スライドサイト、タスクオーケストレーション
v3.9/ship、/full-review、TDD品質チェック
v4.0免疫システム（権限等級、Hooks、TDD内省）

LAM は LAM 自身を使ってバージョンアップしてきた。
18リリースを重ねて、プロジェクトは一度も破綻していない。仕様とコードの乖離（ドリフト）もゼロ。
これは LAM の設計思想の証明だと思っている。

まとめ

AI がコードを書ける時代になった。問題はその先にある。書いたコードでプロジェクトが壊れないか？ ということだ。

LAM は、AI を「頼まれたことをやる人」から「プロジェクトを守る人」に変える。フェーズで暴走を防ぎ、承認ゲートで手綱を握り、免疫システムで健全性を自動維持する。

興味があれば、まずはスライドを見てほしい。5分で概念がわかる。

関連記事

MIT License | 質問やフィードバックは GitHub Issues へ

ブックマーク パーマリンク.

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です