制約の崩壊（Constraint Decay）：バックエンドコード生成におけるLLMエージェントの脆弱性

#はじめに

LLMエージェントが新しい機能を数秒で組み上げる魔法のような瞬間を、誰もが経験したことがあるだろう。ボイラープレートを書き、初期のルーティングを設定し、その構造は一見すると完璧に見える。しかし、タスクが複雑になるにつれて、特にバックエンド環境においては、その最初の輝きは徐々に失われ、目に見えにくい構造上の混乱へと陥ることが多い。

arXivで新たに公開された論文『Constraint Decay: The Fragility of LLM Agents in Back End Code Generation』は、多くのシニアエンジニアが直感的に感じていた問題を公式に提起している。それは、言語モデルが長大で複雑なバックエンドロジックを生成する際、システム制約の遵守が徐々に崩壊していくという問題である。「制約の崩壊（Constraint Decay）」と名付けられたこの現象は、本番環境のバックエンドシステムに自律型コーディングエージェントを本格的に導入する上で、極めて大きな障壁となる。

#何が起きているのか：制約の崩壊のメカニズム

論文の著者らは、複雑なバックエンドアプリケーションの生成をタスクとして、最先端のLLMエージェントの包括的な評価を行った。検証にあたり、データベーススキーマのルール、認証要件、厳密な型付けのガイドライン、特定のアーキテクチャパターンなど、厳格な制約を事前にエージェントに与えた。

その結果、一貫した劣化のパターンが発見された。生成の初期段階（例：最初の数ファイルの構築や、APIエンドポイントの最初の50行）では、エージェントは与えられた制約をほぼ100%遵守していた。しかし、コンテキストが肥大化し、生成タスクが長引くにつれて、エージェントは「崩壊」し始めたのである。

プロンプトを完全に忘却したというよりは、モデルのAttentionメカニズムが希薄化したと言える。モデルは全体的な制約を犠牲にして、局所的な一貫性（直近のコード行がコンパイル可能で構文的に意味が通ること）を優先し始めた。複雑なトランザクションの最終段階や、後から呼ばれるヘルパー関数に到達する頃には、ユーザー権限の確認や適切なデータベーストランザクションのスコープ適用といった致命的なルールが、静かに欠落してしまっていた。

#なぜ重要なのか：バックエンドの容赦ない性質

フロントエンド開発では、わずかなハルシネーション（幻覚）がボタンのズレや色の不一致を引き起こす程度で済むかもしれない。しかしバックエンドエンジニアリングにおいて、環境は根本的に容赦がない。「制約の崩壊」は単なる技術的負債を生み出すだけでなく、即座に致命的な脆弱性を引き起こす。

LLMエージェントがバックエンドで制約の崩壊を起こした場合、その結果は深刻である。

• セキュリティ侵害: 認可チェックの欠落や入力サニタイズ処理の抜け落ちにより、安全でない直接オブジェクト参照（IDOR）やSQLインジェクションの脆弱性に直結する。
• データ破損: 複数のデータベース操作をトランザクションで囲むことを忘れると、処理が途中で失敗した場合にデータベースが不整合な状態に陥る。
• アーキテクチャの逸脱: 依存性の注入（DI）のルールやドメイン駆動設計の境界を無視することで、密結合したスパゲッティコードが生み出され、人間のエンジニアが苦労して解きほぐさなければならなくなる。

バックエンドシステムは絶対的な不変条件（インバリアント）に依存している。制約の遵守率が95%のエージェントは、完全にコンパイルに失敗するエージェントよりも危険である場合が多い。なぜなら、その5%の失敗は構文的に有効なコードの裏に隠れてしまうからだ。

#技術的な影響：エージェントはどこで失敗するのか

この技術的な影響を理解するために、制約の崩壊が実際に起こる具体例を見てみよう。エージェントに対し、「データの変更時には必ず監査ログを記録し、ユーザーのロール（権限）を検証すること」という制約を設けてユーザーサービスを記述するよう指示したと仮定する。

最初の関数では、エージェントは完璧に動作する。

// Initial Generation: Constraints fully respected
async updateUserProfile(userId: string, data: Partial<User>, actor: UserContext) {
    if (actor.role !== 'ADMIN' && actor.id !== userId) {
        throw new UnauthorizedError("Insufficient permissions");
    }
    const updatedUser = await this.db.users.update(userId, data);
    await this.auditLog.record('UPDATE', 'User', userId, actor.id);
    return updatedUser;
}

しかし、数百行後に別の関数を生成する際、制約の崩壊が明確に表れる。

// Later Generation: Constraint Decay sets in
async bulkUpdateUserStatuses(userIds: string[], status: string, actor: UserContext) {
    // Missing role verification constraint!
    // Missing audit log constraint!
    return await this.db.users.updateMany({ id: { $in: userIds } }, { status });
}

研究者たちは、バックエンドの制約を複数のカテゴリに分類し、これらの失敗を定量化した。崩壊は均等に起こるわけではなく、特定の種類の制約は他のものより影響を受けやすい。

表が示すように、セキュリティやアーキテクチャの制約は、基本的な構文や型のルールと比較して、驚くべきペースで崩壊していく。

#今後の展開：AIエージェントの崩壊を軽減する

『Constraint Decay』の発見により、単にコンテキストウィンドウを拡大するだけでは（例えば100万トークン以上のコンテキストへの移行など）問題が解決しないことが明らかになった。実際、コンテキストが大きくなると、Attentionの希薄化がさらに悪化することさえある。

信頼性の高いバックエンドエージェントを構築するため、業界はアーキテクチャレベルでの解決策に焦点を移す必要がある。

1. 反復的な検証: エージェントは「テスト駆動生成（Test-Driven Generation）」のアプローチを採用すべきである。論理ブロックを生成するごとに処理を一時停止し、明示的な制約チェックリストに対して静的解析や単体テストを実行する。
2. 制約付きデコーディング: LLMに対して、事前に定義されたAST（抽象構文木）やスキーマに準拠するコードの生成を強制する厳密なサンプリング技術を実装し、アーキテクチャの逸脱の可能性を減らす。
3. モジュール化されたエージェントワークフロー: 1つの万能なエージェントがサービス全体を記述するのではなく、タスクのスコープを厳密に絞り込む必要がある。1つのエージェントがロジックを記述し、特化した「セキュリティ監査」エージェントが認証の制約をレビューし、3つ目のエージェントが監査ログを処理するといった具合である。

#おわりに

「制約の崩壊」の論文は、AIエンジニアリング業界にとって必要な現実確認（リアリティチェック）である。LLMは信じられないほど強力なパターンマッチングエンジンだが、堅牢なバックエンドコードを書くには、目に見えないルールを厳密に遵守し続ける必要がある。これは、現在のAttentionメカニズムが長期的に維持するのに苦労しているタスクである。

Ichiban Toolsにおいて開発パイプラインへのAI統合を進めるにあたり、我々はこの限界を念頭に置いてエージェントを設計している。バックエンド開発におけるAIの未来は、エージェントに巨大なモノリス（一枚岩のアプリケーション）を一度に記述させることではない。制約が設けられ、検証可能で、スコープが絞られたループを構築し、制約の崩壊が本番環境に到達する前に捉えることにある。

arXivの論文全文はこちら：arxiv.org/abs/2605.06445