論文要約：Zup における内部コーディングエージェント「CodeGen」の構築：教訓と未解決の課題

1. 問題背景 (Problem)

大規模言語モデル（LLM）を基盤としたコーディングエージェントは、ベンチマークや孤立したデモでは高い性能を示しますが、企業環境での本番運用（プロダクション）においては、開発者が実際に信頼して使用できるレベルに至るまでに大きなギャップが存在します。

既存の文献はモデルの性能評価やプロンプトエンジニアリングに焦点を当てがちですが、実運用における成功を決定づける以下の工学的課題が軽視されています。

• ツール設計の質: LLM がツールを正しく理解・実行するための設計。
• 安全性の強制: 複数のツール間で重複する機能に対する包括的なセキュリティポリシー。
• 状態管理: セッションの耐障害性とコンテキストの維持。
• 人間の信頼調整: 盲目的な信頼ではなく、段階的な監視体制による採用促進。

これらの課題が解決されない場合、エージェントは信頼性の低い編集を行い、開発者の手動修正を強要したり、安全性インシデントにより信頼を失ったり、プロトタイプ段階で止まってしまうという結果を招きます。

2. 手法とアーキテクチャ (Methodology & Architecture)

Zup Innovation 社が開発・運用する内部コーディングエージェント「CodeGen」の構築プロセスとアーキテクチャを分析しました。

2.1 基本コンセプト

CodeGen は、ReAct（Reasoning + Acting）パラダイムに基づき、自然言語プロンプトからタスクを推論し、ツールを呼び出して実行、結果を観察し、タスク完了まで反復する自律型エージェントです。

2.2 システムアーキテクチャ

3 層構造で構成されています。

1. CLI インターフェース (Node.js): ユーザーとの対話とローカルツールの実行を担当。IDE 拡張機能の多様性を避け、ポータビリティと社内ツールとの統合を重視して CLI を採用。
2. Backend API (FastAPI): 認証、リクエストルーティング、クライアント接続管理。WebSocket（双方向通信）と SSE（読み取り専用ストリーム）の 2 種類の通信チャネルをサポート。
3. Maestro (オーケストレーションエンジン): エージェントループを制御する中核。LLM へのシステムプロンプト、履歴、ツール記述（Tool Manifest）の提供、ツール呼び出しの仲介、結果の再入力を行う。

2.3 状態管理と耐障害性

• セッション管理: PostgreSQL で永続化、Redis でキャッシュおよびメッセージング基盤（Redis Streams）を使用。
• 再接続機能: ネットワーク切断や非アクティブ時でも、コンテキストを失わずにタスクを再開可能。
• 監査ログ: 各ツール呼び出しやモデル応答を記録し、デバッグ、分析、コンプライアンス対応、システム改善のフィードバックループに活用。

2.4 ツール設計の戦略

• 編集ツール: 全ファイルの書き換えではなく、「文字列置換（String Replacement）」に特化。LLM の長文生成における欠落や切断エラーを回避。
• 読み取り - 編集ポリシー: 編集前に必ず read ツールを呼び出すようプロンプトで指示し、古い文脈や幻覚（ハルシネーション）による編集を防ぐ。
• シェルツール: 最も有用かつ危険なツール。コマンドレベルのブロック、設定ファイルによる制限、承認モード（人間による確認）の多層防御を適用。

3. 主要な貢献と設計決定 (Key Contributions & Design Decisions)

論文では、13 の具体的な設計決定とそれに基づくトレードオフ分析を提示しています。

3.1 アーキテクチャとフレームワーク

• 手動実装の優先: 初期段階では LangChain などのフレームワークではなく、エージェントループを手動実装（Maestro）しました。これにより、実行フローの制御、停止条件、エラー処理を明確に理解でき、学習が加速しました。後にフレームワークが同様の機能（例：LangGraph）を提供するようになり、移行が容易になったことが検証されました。
• 非同期処理の採用: FastAPI と asyncpg を採用し、多数の WebSocket 接続と非同期 DB 操作を単一サービスで処理可能にしました。
• 推論の委譲: 推論ロジックを LLM に委譲し、オーケストレーターは構造的な枠組み（コンテキスト作成、ツールディスパッチ）に注力しました。

3.2 ツール設計と安全性

• ツール記述の重要性: プロンプト調整よりも、ツールの説明、パラメータスキーマ、エラー契約の品質向上がエージェントの信頼性向上に寄与しました。
• 包括的な安全性: 特定のツールを制限するだけでは不十分です。シェルツールなど、他の手段で同じ破壊的動作が可能であれば、ポリシーはツール全体（ツール記述全体）で一貫して適用される必要があります。

3.3 人間の監視と採用 (Human Oversight)

• 段階的な承認モード: 開発者は最初は「承認モード（すべての編集・実行に人間確認が必要）」から始め、信頼が蓄積されるにつれて自律モードへ移行します。この自発的な移行が企業内での有機的な採用を促しました。
• 計画モード: 複雑なタスクでは、実行前に LLM が提案するアクションプランを人間がレビュー・承認するステップを設けました。
• トレードオフの管理: 安全性、速度、制御性など、単一の指標ではなく、文脈に応じたトレードオフの管理が設計の核心でした。

4. 結果と知見 (Results & Findings)

• 信頼性の向上: プロンプトエンジニアリング単独よりも、ツール設計（特に文字列置換編集や読み取り - 編集ポリシー）の改善が、エージェントの動作の安定性を大幅に向上させました。
• 採用の成功: 承認モードから自律モードへの段階的な移行モデルにより、開発者の信頼を構築し、強制的な導入ではなく自発的な利用を促進しました。
• 実用性の検証: 手動実装からフレームワークへの移行戦略は、アーキテクチャの成熟度を正しく評価する上で有効でした。
• モデルとオーケストレーションの相補性: 強力なモデルだけでは安全性は保証されず、オーケストレーションによる制御とガードレイルが不可欠であることが確認されました。

5. 意義と未解決の課題 (Significance & Open Questions)

この論文は、コーディングエージェントをプロトタイプから実運用へ移行させるための「工学的決定」の重要性を浮き彫りにしました。モデルの選択だけでなく、ツールの設計、安全性の強制、状態管理、人間の信頼調整が実用性を決定づけます。

さらに、以下の 6 つの未解決の課題（Open Questions）を提起し、今後の研究と実践の指針を示しています。

1. ツール記述の設計手法: モデルの誤用を最小化し、正しく呼び出すための体系的な設計原則や評価指標の確立。
2. 推論と制御の境界: モデルに委譲する推論と、オーケストレーターが制御する部分の最適な境界線の設定。
3. クロスツールの安全性: 重複する機能を持つツール間での一貫した安全性ポリシーの形式化と強制。
4. 適応的信頼モデル: 人間の監視から自律運用への移行を、タスクの複雑さや成功率に基づいて動的に調整するメカニズム。
5. 長期メモリ構造: セッション間での学習と信頼性を両立するメモリアーキテクチャの設計。
6. 品質保証パイプライン: エージェント生成コードに対する、人間作成コードとは異なる検証メカニズムの必要性。

結論

CodeGen の事例は、エンタープライズ環境における AI エージェント構築において、モデルそのものよりも、そのモデルをいかに安全かつ効果的に運用する「工学的な周辺システム」の設計が重要であることを示しています。実用的なエージェント開発は、単なる技術の導入ではなく、トレードオフの管理と段階的な信頼構築のプロセスであるという洞察を提供しています。