AutoDev LG の仕組み

誰が何をしているのか。1 回の自動開発（run）はどう進むのか。2 枚の図で紹介します。

01登場人物と役割分担

AutoDev LG は 4 層の登場人物で回っています。いちばん下のローカル LLM たちがアプリを作ります。その仕組み（フレームワーク）を育てているのは Claude Code で、方針を決めるのは人間です。

👤 人間 オーナー

  • 作りたいアプリを伝える（例: 「インベーダーゲームを作って」）
  • できあがったアプリ（最終アウトプット）だけで評価し、機能が足りなければ簡単に指示する。アプリの仕様書なんて、正直見てすらいない
  • AutoDev LG の目標・方針や仕様の変更を判断する（Claude Code から相談を受けて決める。例: 「INVADERS で 3 回連続 PASS」「特定アプリ専用の処理は入れない」）
作りたいアプリ・評価・指示 ↓↓↑↑ 報告・相談・メール通知

🛠 Claude Code フレームワークの開発担当（以前は ChatGPT も）

  • ① 人間の依頼をもとに、AutoDev LG に渡す仕様書を作成
  • ② AutoDev LG を起動・監視し、終わったらログを分析して失敗の原因を探す
  • ③ AutoDev LG 自体を修正する：テストを先に書く → 版を上げる → リリースゲート（1,200 件超のテスト）→ AutoDev LG のデプロイ → アプリ生成の成功に再現性が出るまで ② に戻る
  • ④ Claude Code のセッションが途切れたときのために、引き継ぎメモを作成
仕様書・起動・修正 ↓↓↑↑ run の結果・ログ

⚙️ AutoDev LG LangGraph で組んだ自動開発ワークフロー

仕様書を受け取り、下のエージェントたちに順番に仕事を振ります。行き詰まったエージェントは、別のモデルに自動で交代させます。run の最後には、できあがったアプリと一緒に利用手順書も自動で作ります。

リーダー要件の整理・設計・テスト計画
Qwen3.8 Flash-Next 詰まったら → Qwen3.8 27B → Gemma 4 → gpt-oss-120b
レビュアー設計やテストが仕様どおりか意味をチェック
Gemma 4 26B
テスト作成合否を判定するテストコードを書く
Qwen3.8 27B
ワーカーOpenHands を使って実際にコードを書く・直す
Qwen3.8 Flash-Next 詰まったら → Gemma 4
プロンプト ↓↓↑↑ 回答（JSON・コード）

🖥 ローカル LLM llama.cpp（llama-server）で自宅 PC 上で動作

モデルは 1 つずつ、5 枚の GPU にまたがって載せます。役割が替わるたびに入れ替えます。クラウドの AI は使いません。

RTX 5070 Ti 16GBRTX 5060 Ti 16GBRTX 5060 Ti 16GBRTX 5060 Ti 16GBRTX 5060 Ti 16GB= VRAM 80GB

021 回の run の流れ

仕様書から始まり、テストがすべて通れば PASS です。途中で失敗したら、原因を診断して種類ごとに直し、もう一度検証します。

作業チェック（ゲート）テスト実行
📄 仕様書SPEC (例: taskboard / INVADERS)Claude Code が作成 → 実物を見る
要件の整理Requirementsリーダー
設計Architectリーダー
設計の抜け漏れチェックContract Gate
設計を凍結（Freeze）
テスト作成Test Generateテスト作成 + レビュアー
テストの意味チェックSemantic Audit
コーディングCoding (OpenHands)ワーカー
実装と設計の突き合わせImplementation Contract Gate
テスト実行Quality: Public + Acceptance tests
全部通った
🎉 PASS
失敗あり
原因を診断Diagnose (Public / Acceptance)
テスト側の不具合fixture / test bug
テストを安全に修理・再生成test repair / regenerate
設計の穴contract gap
設計の見直しcontract reconcile / review
実装のバグimplementation bug
コードを修正code repair (coding)
再検証 → 前進していれば続行re-validate → validated progress?

同じ失敗を繰り返したら 別のモデルに交代。それでも進まなければ run 終了（NOT PASS）

run の最後に
📦 成果物：アプリ一式 ＋ 📘 利用手順書project files + USAGE_GUIDE.md

利用手順書は LLM を使わず、仕様書・設計・実際に生成されたコードから確かめられることだけをプログラムで書き出します（起動方法は実際のコードから取るので、「書いてあるとおりにしたら動かない」が起きにくい）。

※ 実際のワークフローには、テスト計画の監査、ハーネス復旧、スコープ確認など 20 を超える工程があります。上の図は主な流れだけを抜き出したものです。

03run が終わったあと

NOT PASS なら、Claude Code がログを分析します。そして「特定のアプリ専用ではない、一般的な直し方」でフレームワークを修正し、版を上げて次の run を回します。この繰り返しで、版番号は 140 を超えました。

その日々の結果は、開発ログで毎朝更新しています。