Each language version is independently generated for its own context, not a direct translation.
🍳 研究の舞台：AI 料理人の実験
想像してください。
**「AI 料理人（エージェント）」が、「レシピ（要件）」だけを見て、あるいは「既存のキッチン（既存システム）」**を見ながら、新しい料理（マイクロサービス）を作ろうとしています。
この研究では、3 人の有名な AI 料理人（Claude Code, Codex, Code Qwen）に、4 つの異なる料理場（プロジェクト）で、144 回もの料理を振る舞ってもらいました。
実験は大きく 2 つのシチュエーションで行われました。
シチュエーション A：「既存のキッチンへの追加」 (Incremental Generation)
- 状況: すでに料理が並んでいるキッチンに、新しい料理を追加します。
- AI の役割: 既存の料理（コード）や、他の料理との連携ルール（API 契約）を**「見ながら」**新しい料理を作ります。
- 実験: AI に「既存の味付けやルールを踏襲して」という**「詳細なメモ（P2）」を与えた場合と、「名前とレシピだけ」**（P1）を与えた場合を比べました。
シチュエーション B：「何もない土地からの新築」 (Clean State Generation)
- 状況: 何もない広場で、ゼロから新しい料理店を作ります。
- AI の役割: 既存のコードは一切見られません。あるのは**「レシピ（要件）」だけ**です。
- 実験: AI に「この料理を作ってください」と頼むだけで、ゼロから店を作り上げさせました。
🔍 発見された驚きの結果
1. 「詳細なメモ」は逆効果だった？（シチュエーション A の結果）
意外な事実： 既存のキッチンで料理を作る際、「詳細なメモ（P2）」を渡したほうが、AI の料理は失敗しやすかったのです。
- なぜ？ AI がメモに書かれた「大きな話（OAuth2 やスケジュール機能など）」に夢中になりすぎて、**「細かい重要な調味料（データベースの特殊な変換設定など）」**を見落としてしまったからです。
- 正解： 逆に、**「名前とレシピだけ（P1）」**を渡して、AI 自身に厨房を探索させたほうが、AI は「あ、ここにはこんなルールがあったんだ！」と自分で発見し、**より高い成功率（50〜76%）**を叩き出しました。
- 教訓： すでに完成されたシステムに手を加えるときは、AI に「余計な説明」を与えず、**「自分で探させて」**あげたほうが良いかもしれません。
2. 「ゼロから」の方が上手にできた？（シチュエーション B の結果）
- 結果： 何もない土地から作る場合、AI の成功率は**80〜98%**と非常に高くなりました。
- 理由： 既存のコードに縛られないため、AI は自分の得意なスタイルで自由に作れます。また、この実験では「味（機能）」が合っていれば OK とするテスト（統合テスト）を使ったため、細かい「器の形（パッケージ名やクラス名）」が違っても合格になりました。
- 教訓： 新規開発なら AI は非常に頼もしいですが、**「既存システムとの連携」**にはまだ人間がチェックする必要があるようです。
3. 料理の「質」と「コスト」
- コードの質： AI が作った料理は、人間が作ったものよりも**「シンプルで複雑さが低い」**傾向がありました。ただし、これは「防御策（エラー処理など）が抜けている」可能性もあるため、注意が必要です。
- 時間とコスト：
- Claude Code: 早く（約 8 分）、料理はシンプルですが、**「高級食材」**で最も高価でした。
- Codex: 料理に時間がかかる（平均 16 分、最長 100 分以上！）ことがあり、**「遅延リスク」**があります。
- Code Qwen: 最も**「安上がり」**で、コストパフォーマンスが良いですが、ゼロから作る際は「メモ（P2）」がないと料理を放棄してしまうことがありました。
💡 結論：AI は「完璧な職人」にはまだなれない
この研究が伝えたかったメッセージは以下の通りです。
- AI は「料理人」として使えるが、完全な「一人前」ではない。
機能は作れるし、コードも綺麗に書けるが、**「既存システムとの微妙な連携」や「細部への配慮」**では、まだ人間の監督（チェック）が不可欠です。
- 状況によって「正解の指示の出し方」が違う。
- 既存システムに追加するときは：**「余計なメモは渡さず、AI に探させる」**のが正解。
- ゼロから作るときは：**「明確なメモ（要約）」**を渡したほうが、AI が迷わずに済む。
- コストと速度のバランス。
安くて速い AI がある一方で、時間がかかる AI もいます。プロジェクトの性質に合わせて、どの AI を使うか（あるいは人間がどこまで介入するか）を慎重に選ぶ必要があります。
🎯 まとめ
AI エージェントは、**「建築の設計図（要件）」から「壁や柱（コード）」を建てることはできます。しかし、「近隣の家との境界線（API 契約）」や「配管の細部」まで完璧に理解して、既存の街並みになじむように建てるには、まだ「人間の建築家（開発者）」**の目が必要だ、というのがこの研究の結論です。
AI は強力な「助手」ですが、まだ「責任者」にはなれない、というのが今の現実です。
Each language version is independently generated for its own context, not a direct translation.
論文「Can AI Agents Generate Microservices? How Far are We?」の技術的サマリー
本論文は、大規模言語モデル（LLM）を基盤としたAI エージェントが、依存関係や API 契約を明示的に持つマイクロサービスを生成できるかどうか、およびその機能性、コード品質、効率性を評価した実証研究です。
以下に、問題定義、手法、主要な貢献、結果、および意義について詳細をまとめます。
1. 問題定義 (Problem)
ソフトウェアアーキテクチャの分野では、アーキテクチャ記述から実行可能システムを自動生成することが長年の目標でしたが、従来の ADL（アーキテクチャ記述言語）や DSL（ドメイン固有言語）は学習コストが高く、普及していませんでした。
近年、LLM を用いたコード生成は進歩しましたが、単一の関数やスニペット生成に留まることが多く、マイクロサービスのような複雑なアーキテクチャ単位での生成は未研究でした。マイクロサービスは、各サービスが個別のロジックを満たしつつ、厳格な API 契約や相互運用パターンを通じて統合される必要があるため、AI エージェントにとって極めて挑戦的なタスクです。
本研究は、AI エージェントが既存システムへの追加（インクリメンタル生成）と、要件のみからの新規構築（クリーンステート生成）の両方において、機能的に正しいマイクロサービスを生成できるか、またその品質と効率性はどの程度かを実証的に検証することを目的としています。
2. 研究方法 (Methodology)
実験設計
- 対象エージェント: 3 種類の AI エージェント（Claude Code, Codex, Code Qwen）を選定。
- 対象プロジェクト: 4 つのマイクロサービスシステム（オープンソース 2 件、学生プロジェクト 2 件）。
- 生成シナリオ:
- インクリメンタル生成 (Incremental Generation): 既存システムの一部として、既存のコードベース、ドキュメント、API 契約を参照しながら、特定のマイクロサービスのみを再生成するシナリオ。
- クリーンステート生成 (Clean State Generation): 既存の実装情報を一切排除し、要件定義のみからゼロからマイクロサービスを生成するシナリオ。
- プロンプト戦略:
- P1 (最小限): サービス名と要件パスのみを提示。
- P2 (詳細): P1 に加え、事前生成された実装サマリー（機能範囲、API 責任、データ管理など）を提示。
- 評価指標:
- 機能正しさ: インクリメンタルでは単体テスト（Unit Tests）、クリーンステートでは他サービスからの API 呼び出しを含む結合テスト（Integration Tests）のパス率。
- コード品質: ソース行数（SLOC）、循環的複雑度（Cyclomatic Complexity）、認知的複雑度（Cognitive Complexity）。
- 効率性: 生成時間、トークン消費量、コスト。
- データセット: 合計 144 件のマイクロサービス実装（4 プロジェクト × 3 サービス × 3 エージェント × 2 シナリオ × 2 プロンプト）を生成・評価。
3. 主要な貢献 (Key Contributions)
- 初の実証研究: 異なる文脈（既存システム vs 新規構築）において、AI エージェントによるマイクロサービス生成の機能正しさとコード品質を評価した初の研究。
- エージェント効率性の比較分析: 生成時間、コスト、トークン消費量に基づくエージェント間の詳細な比較分析の提供。
- 実用的な知見: 文脈の提供方法（プロンプト戦略）が生成結果に与える影響（例：詳細なサマリーが逆効果になる場合がある）の解明。
4. 主要な結果 (Results)
機能正しさ (Functional Correctness)
- インクリメンタル生成: 最小限のプロンプト（P1）の方が、詳細なサマリーを含むプロンプト（P2）よりも高いテストパス率（50%〜76%）を示しました。詳細なサマリーを与えると、エージェントが文脈探索を怠り、重要な実装詳細（例：MongoDB のコンバーター設定など）を見落とす「アンカリング効果」が発生しました。
- クリーンステート生成: 非常に高い結合テストパス率（81%〜98%）を達成しました。これは、結合テストが内部構造の厳密な一致よりも API 契約の遵守を重視するためです。特に Code Qwen は、P2（サマリーあり）によって大幅に性能が向上しました。
- 結論: AI エージェントは機能的に正しいマイクロサービスを生成できますが、文脈（既存システムか新規か）とプロンプト設計が結果に大きく影響します。
コード品質 (Code Quality)
- 生成されたコードは、人間が記述したベースラインと比較して、循環的複雑度や認知的複雑度が 15%〜40% 低い傾向がありました。
- コードはより簡潔（concise）でしたが、機能的な正しさを損なうことなく、複雑さを削減していました。
効率性 (Efficiency)
- 時間: Claude Code と Code Qwen は平均 7-8 分で生成完了しましたが、Codex は平均 16.6 分と遅く、最大で 104 分（1.74 時間）かかるケースもありました。
- コスト: 1 サービスあたりのコストは、Code Qwen が最も安価（約$2.98）、Claude Code が最も高価（約$13.28）でした。
- トークン: Claude Code は非常に少ない出力トークン（平均 2.1K）で高い正しさを達成しましたが、Codex は冗長なコード（平均 37.5K）を生成しました。トークンの多さ（冗長性）は機能正しさと相関しないことが示されました。
一般的な知見
- データ汚染の影響: 有名なオープンソースプロジェクト（PiggyMetrics, Train-Ticket）ではエージェントの性能が高く、学生プロジェクト（プライベートコード）では性能が低下しました。これは LLM の学習データに含まれる可能性を示唆しています。
- 人間の監視の必要性: 完全な自律生成は現時点では達成されておらず、API 契約の整合性やアーキテクチャの妥当性を確認するための人間の監視が不可欠です。
5. 意義と結論 (Significance & Conclusion)
本研究は、AI エージェントがマイクロサービス開発において実用的な支援となり得ることを示しましたが、その能力はシナリオと文脈に強く依存することを明らかにしました。
実務への示唆:
- 既存システムへの追加では、詳細なサマリーよりも最小限のプロンプトでエージェントに探索させる方が効果的である可能性があります。
- 新規開発では、明確な要件とサマリーが有効です。
- 生成時間のばらつき（特に Codex）やコストを考慮し、タイムアウト対策やフォールバック戦略が必要です。
- コードの冗長性は品質の指標ではなく、簡潔なコードでも高い正しさを達成できる可能性があります。
研究への示唆:
- 既存のベンチマーク（SWE-bench など）はリポジトリレベルのタスクに焦点を当てており、マイクロサービスのようなアーキテクチャ的依存関係を評価するには不十分です。アーキテクチャ固有のベンチマークの確立が必要です。
- データ汚染の検出手法や、人間とエージェントの最適な協働モデル（介入タイミングなど）の確立が今後の課題です。
総じて、AI エージェントはマイクロサービス生成の有望なツールですが、完全な自律化には至っておらず、開発者は生成結果の検証とアーキテクチャ的整合性の確保において重要な役割を果たし続ける必要があります。