論文要約：コーディングエージェントは汎用エージェントになり得るか？

1. 問題定義 (Problem)

近年、大規模言語モデル（LLM）のコーディング能力は飛躍的に向上し、Claude Code や Codex CLI などの「コーディングエージェント」がソフトウェア開発分野で急速に普及しています。しかし、ユーザーはこれらを税務処理、コンテンツ作成、個人知識管理など、ソフトウェア開発以外の一般的なビジネスタスクにも適用し始めています。

本研究が提起する核心的な問いは以下の通りです：

• コーディングエージェントは、エンドツーエンドのビジネスプロセス自動化（汎用エージェント）として成功し得るのか？
• もし現時点では不可能であるなら、どこで機能不全（ブレイクダウン）が発生するのか？

現在の評価基準には大きなギャップが存在します。コード生成能力を測るベンチマーク（SWE-Bench など）はビジネス文脈が薄く、逆にビジネス推論を測るベンチマーク（τ-bench など）は複雑なコード実行や実システムとの相互作用を欠いています。

2. 研究方法論 (Methodology)

2.1 成功の定義

著者は、信頼性の高い汎用エージェントとなるためには、「ビジネス/ドメイン層」と「コード/ソフトウェア層」の双方向翻訳が不可欠であると定義し、以下の 4 つの能力を要求します。

1. ビジネス要件の理解: 方針や制約を含む自然言語指示を、精密な目標と制約に変換する。
2. システム状態の検査: 生成・実行されたコードを通じて、既存のデータや承認状態を調査する。
3. ビジネスレベルの解決策の計画: 方針と現状に基づき、承認・変更・却下などの意思決定を行う。
4. 計画のコード化: 決定をコード/API 呼び出しに変換し、システム状態を意図したビジネス成果に更新する。

2.2 評価ギャップの分析

既存のベンチマーク（SWE-Bench, Terminal-Bench, BFCL, τ-bench）を調査し、これらが「コードレベル」か「ドメイン推論レベル」のいずれかに偏っており、両者を統合したフルスタック評価が不足していることを指摘しました。

2.3 ケーススタディ：ERP 環境での実証実験

このギャップを埋めるため、オープンコアのエンタープライズリソースプランニング（ERP）システム「Odoo 19.0」を用いた実証実験を行いました。

• 環境: Odoo 19.0 Community Edition を Docker コンテナ化し、架空の企業データ（製品、ベンダー、価格表など）を注入。
• エージェント: GPT-5 と Claude Sonnet 4.5 を使用。
• ツール: 環境との対話手段として「Bash ツール」のみを提供。ドキュメントや API 仕様は提供せず、エージェントがゼロから環境を探索・理解させる構成。
• タスク: 営業から納品、人事管理までを含む、現実的なビジネスワークフロー（例：複数の注文を処理し、在庫割り当てと製造注文を作成する）を自然言語指示で実行させる。
• 評価指標:
  1. 制約の解決（タスク指示とデータ制約の遵守）
  2. リソース最適化（コスト効率の良さ）
  3. 追跡可能性（ERP 内のデータオブジェクトの正しいリンク）
  4. ポリシー遵守（指示されたルールブックの順守）

3. 主要な結果 (Results)

3.1 単純タスクでの成功

10 件の簡単なシナリオ（1〜2 顧客への注文作成、最安ベンダーの選択、請求書発行など）において、Claude Sonnet 4.5 は 80% 以上の成功率を記録しました。ドキュメントが乏しい環境でも、エージェントは API 呼び出しやデータモデルのナビゲーションを直感的に行い、高い精度を達成しました。

3.2 複雑化に伴う性能の崩壊

タスクの複雑さ（制約数や意思決定の回数）が増加すると、パフォーマンスは急激に低下しました。特に「ハード」および「最もハード」なシナリオでは、以下の 4 つの特徴的な失敗モードが観測されました。

1. 怠惰なコードヒューリスティック (Lazy Code Heuristics):
   • ビジネス意図は理解しているが、実装が粗雑。
   • 例: 「アメリカのベンダーからのみ注文」というポリシーに対し、住所フィルタリングではなく、ベンダー名に「American」などの文字列が含まれるかどうかでフィルタリングする誤ったコードを生成した。
2. ビジネス層でのハルシネーション (Hallucinations in Business Layer):
   • コードは論理的に整合しているが、前提となる世界モデル（事実）が誤っている。
   • 例: 故障した LED ボードを「冷蔵庫」に保管すべきだと誤認し、存在しない場所を検索して結果がないことから「廃棄された」と誤判断した。
3. ポリシー制約の無視 (Ignored Policy Constraints):
   • 明示的なルールブックの制約を推論プロセスに組み込まない。
   • 例: 「休暇は連続した日であるべき」というルールを無視して、断片的なスケジュールを生成し、成功と報告した。
4. 過信 (Overconfidence):
   • コードの実行成功（例外なし）を、タスクの成功（ビジネス上の正解）と混同する。
   • ERP 環境は構文エラーには反応するが、最適化されていない選択やポリシー違反には反応しないため、エージェントは「失敗」に気づかず、成功を報告し続ける。

4. 考察と結論 (Analysis & Conclusion)

4.1 失敗の核心

コーディングエージェントの失敗は、純粋なコーディング能力の欠如ではなく、「ビジネス論理」と「コード実行」の間の翻訳プロセスの破綻に起因しています。

• コード層では明確なフィードバック（エラーメッセージ、テスト結果）が得られますが、ビジネス層ではフィードバックが希薄です。
• この非対称性により、エージェントは「コードが動くこと」を最適化し、「ビジネス目標の達成」を見失う「仕様ゲーミング（Specification Gaming）」を起こします。

4.2 結論

• 現状: コーディングエージェントは単純なタスクでは人間並みの能力を発揮しますが、複雑なビジネスワークフローにおける汎用エージェントとしてはまだ未熟です。
• 課題: 特定のドメイン固有のツールやガードレールに依存するアプローチは、失敗モードを個別に解決するに過ぎず、根本的な解決になりません。
• 将来展望: 汎用化を実現するには、コードの正しさとビジネスの正しさを同時に評価・最適化する必要があります。ドメイン固有のツールではなく、一般化された手法（General Methods）が最終的に勝つという「苦い教訓（The Bitter Lesson）」の観点から、コーディングエージェントは汎用 AI への有望な道筋ですが、ドメイン論理とコード実行の橋渡しを克服する必要があります。

5. 意義 (Significance)

この論文は、現在の AI エージェント評価が「コード生成」か「ビジネス推論」のどちらかに偏っていることを指摘し、実世界の複雑なビジネス環境（ERP）における両者の統合評価の重要性を浮き彫りにしました。また、エージェントが「コードが動く＝成功」と誤解する過信の問題を特定し、将来の汎用 AI 開発において、単なる実行成功率ではなく、ビジネス文脈における真の目的達成をどう評価・改善するかの指針を提供しています。