5
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Day 12

Claude Code Advent Calendar 2025

@m96-chan(Yusuke Harada)

LLMエージェントが「使うほど賢くなる」6層アーキテクチャを提案した話

Last updated at Posted at 2025-12-11

LLMエージェントが「使うほど賢くなる」6層アーキテクチャを提案した話

はじめに

Claude CodeやGitHub Copilot、素晴らしいですよね。

でも、数日間の開発を任せるとこうなりませんか？

  • 「さっき説明したアーキテクチャ、もう忘れてる...」
  • 「このバグ、昨日直したはずなのにまた出てきた」
  • 「昨日と今日で言ってること違くない？」

これ、LLMの限界じゃなくてアーキテクチャの問題だと思って、解決策を論文にまとめました。

📄 論文（プレプリント）: https://doi.org/10.5281/zenodo.17734815

本記事では、提案した「VibeLayer Development（VLD）」の概要を日本語で解説します。

TL;DR

  • LLMエージェントは短時間タスクは得意だが、数日間の開発では破綻する
  • 原因は「記憶喪失」「計画の不整合」「同じミスの繰り返し」
  • 6層アーキテクチャでこれらを解決する
  • 特に**第5層（自己モデリング）**で本番データから自己改善し続けるのがミソ

問題：なぜLLMエージェントは長期開発で破綻するのか

4つの根本的なギャップ

ギャップ 症状
1. 永続メモリの欠如 セッションが切れると全部忘れる
2. 計画の不安定性 昨日と今日で違う設計を提案する
3. 再現性の欠如 「なぜその実装にしたか」を再構成できない
4. 自己改善の欠如 同じミスを何度も繰り返す

既存ツールの組み合わせでは解決しない

「GitHubに保存すればいいじゃん」「Discordにログ残せばいいじゃん」と思うかもしれません。

でも、単純な組み合わせでは足りないんです：

組み合わせ 何が足りない
GitHub + LLM イベントの時系列がない。推論過程を再構成できない
Discord + LLM 構造化されたメモリがない
GitHub + Discord 推論能力がない
3つ全部（非構造化） イベントと状態変更が因果的にリンクされていない

構造化された統合が必要なんです。

解決策：VibeLayer Development（VLD）

6層アーキテクチャ

┌─────────────────────────────────────────────────────────────┐
│  Layer 5: 自己モデリング（ファインチューニング、プロンプト進化）│  ← ★ここが味噌
├─────────────────────────────────────────────────────────────┤
│  Layer 4: バリデータ（AIレビュー + 人間レビュー + テスト）    │
├─────────────────────────────────────────────────────────────┤
│  Layer 3: エグゼキュータ（コード生成、パッチ適用）            │
├─────────────────────────────────────────────────────────────┤
│  Layer 2: プランナー（タスク分解、アーキテクチャ）            │
├─────────────────────────────────────────────────────────────┤
│  Layer 1: イベント層（Discord Webhooks、監査ログ）           │
├─────────────────────────────────────────────────────────────┤
│  Layer 0: 外部メモリ（GitHub Issues、PRs、Projects）         │
└─────────────────────────────────────────────────────────────┘
        ↑                                           │
        │         フィードバックループ（L5 → L2）      │
        └───────────────────────────────────────────┘

各層の役割

Layer 0: 外部メモリ（GitHub）

エージェントの「長期記憶」

  • Issues：要件、決定、タスクステータス
  • Pull Requests：完全なプロヴェナンスを持つコード変更
  • Projects：カンバンスタイルの実行キュー

設計原則：エージェント再起動後も生き残る必要があるすべての状態はここに保存。エージェントはステートレス。GitHubが真実の源。

Layer 1: イベント層（Discord）

「いつ、何が起きたか」の完全な記録

  • GitHubウェブフックが専用Discordチャンネルにポスト
  • エージェントアクションは実行前にログ
  • Discordのメッセージ順序が全順序保証を提供

重要：状態変更の前にイベントをログすることで、孤立した状態遷移を防ぐ。

Layer 2: プランナー

タスク分解とアーキテクチャ決定

  • 構造化プロンプトを持つLLMベース
  • 計画は特定のIssue/イベントIDを参照
  • メモリが変更された場合の競合検出が可能

Layer 3: エグゼキュータ

コード生成と実装

  • Issueを直接変更できない
  • すべての状態変更はイベント（L1）を伴うメモリ（L0）を通過

Layer 4: バリデータ

品質保証

  • AIレビュアー：バグ、アンチパターン、セキュリティ脆弱性の自動検出
  • テストランナー：自動テスト実行
  • 人間レビュアー：マージの最終承認

Layer 5: 自己モデリング ★最重要

「使うほど賢くなる」を実現する層

  • プロンプト進化：成功/失敗タスクを分析してプロンプトを改良
  • パターン学習：繰り返し発生する問題を特定し予防ルールを生成
  • ファインチューニング：蓄積データに基づく定期的なLoRA/SFT更新

安全性：すべての自己モデリング更新は、デプロイ前に人間の承認を必要とする。

創発的特性：なぜ6層すべてが必要か

個々のコンポーネントでは達成できない創発的特性が、完全な統合によって初めて実現します。

4つの創発的特性

特性 必要な層 説明
決定論的再構成 L0 + L1 初期状態とイベントログから任意の過去状態を再現可能
時間的一貫性 L1 + L2 異なる時点で生成された計画が相互に一貫
閉ループ自己改善 L1 + L4 + L5 実行履歴→検証結果→自己改善のサイクル
監査完全性 全層 すべての状態遷移がトレース可能

部分集合ではダメな理由

構成 再構成 一貫性 自己改善 監査
L0のみ ✗ ✗ ✗ ✗
L0 + L1 部分的 ✗ ✗ 部分的
L0 + L1 + L2 + L3 ✓ ✓ ✗ 部分的
L0 + L1 + L2 + L3 + L4 ✓ ✓ ✗ ✓
完全なVLD（L0-L5） ✓ ✓ ✓ ✓

形式モデル：決定論的再構成の保証

少しだけ数式を使って説明します。

イベントの定義

e = (τ, type, source, payload, ref)
  • τ：タイムスタンプ
  • type：イベントタイプ（ISSUE-CREATE, PR-MERGEなど）
  • source：発生源（GITHUB, PLANNER, HUMANなど）
  • payload：イベント固有のデータ
  • ref：影響を受けるメモリオブジェクトへの参照

状態遷移

S_{t+1} = f(S_t, e_{t+1})

現在の状態 + 次のイベント → 次の状態

決定論的再構成定理

任意の時刻 t の状態は、初期状態とイベントシーケンスから一意に再構成できる：

S_t = f(...f(f(S_0, e_1), e_2)..., e_t)

つまり：イベントログさえあれば、「あの時点でエージェントは何を考えていたか」を完全に再現できる。

既存研究との違い

同時期の研究：OpenHands SDK V1

OpenHands SDK V1もイベントソーシングを採用していますが、VLDとは異なります：

側面 OpenHands SDK V1 VLD
イベントストア 内部（メモリ/ファイル） 外部（Discord）
状態ストア 内部 外部（GitHub）
耐久性 プロセス寿命 無期限
自己モデリング なし L5層
監査 内部ログ 第三者監査可能

VLDの「外部化戦略」により：

  • プロセス再起動だけでなくインフラ障害からも生き残る
  • 第三者による独立した監査が可能

メモリシステム：Mem0との違い

側面 Mem0 VLD
メモリタイプ グラフベース ドキュメントベース（Issues）
時間的順序 保証なし 保証あり
再構成 近似（検索） 正確（リプレイ）

評価指標

長期間エージェントの安定性を評価するための4つの指標を提案しています：

指標 意味 目標
TDR（タスク重複率） 既存タスクと重複する生成タスクの割合 < 20%
SRA（状態再構成精度） ログからの状態再構成のF1スコア > 90%
RRR（リグレッション再発率） 以前修正したバグが再発する割合 < 5%
TC（タスク一貫性） 計画と実装のセマンティック類似度 > 85%

制限と今後

制限

  • 外部サービス依存：GitHub、Discord、LLM APIが必要
  • 実証実験はこれから：本論文は提案段階（プレプリント）

今後の研究

  • 実証実験の実施
  • マルチリポジトリ対応
  • セルフホスト版の開発

まとめ

  • LLMエージェントの長期開発問題はアーキテクチャで解決できる
  • 6層すべての統合が創発的特性を生む
  • 特に**第5層（自己モデリング）**が「使うほど賢くなる」を実現
  • 外部化戦略により耐久性と監査可能性を確保

リンク

おわりに

「Vibe Coding」の次は「VibeLayer」の時代...かもしれません。

フィードバック、質問、ツッコミ、大歓迎です！

タグ: LLM, AIエージェント, ソフトウェア開発, アーキテクチャ, ClaudeCode, GitHub, 自己改善AI

5
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
5
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?