CA.ai #3 〜事例から学ぶ実践AIエージェント開発〜 | CyberAgent Developers
概要
サイバーエージェント主催の生成AI勉強会CA.ai第3回。「実践AIエージェント開発」をテーマに、Google ADKによるマルチエージェント構築、ワークフローと狭義エージェントの使い分け、コーディングエージェントによる新規プロダクトの短期立ち上げと運用という3本のLTが行われた。オープニングでは同社の「2028年までに開発プロセスを全自動化」というAIドリブン組織のビジョンも共有された。
主なポイント
- 同社は開発チームのAI成熟度を5段階で定義し、2028年までに全プロダクトを「要件定義から本番リリースまで自動化」するレベル4到達を目標にしている。SDD(スペック駆動開発)だけではレベル4に届かず、ドメイン知識・UX・社会的価値の見積もりが必要という認識。
- Google ADK(Agent Development Kit)はPython/TypeScript対応のエージェント開発フレームワーク。Google Cloud/Workspace連携、LiteLLM経由でのマルチプロバイダー対応、豊富な組み込みツール(Google検索、LangChain/CrewAIツール、MCP)が採用理由。Web UIでチャット・トレース・評価が可能で、ノーコードのVisual Agent Builderも追加された。
- 品質向上の設計思想は「専門家のチームを作る」こと。1つのLLMに大量のツールとプロンプトを渡すとツール選択が破綻するため、業務単位でサブエージェントに分割し、LLMエージェント/ワークフローエージェントがオーケストレーションする。
- 実践テクニック: リフレクション(生成→レビュー→再生成のループ)、プランナーによるチェックリスト生成、曖昧な指示にはフォローアップ質問を返す仕組み、複数モデルの並列生成と統合、Pydanticによる出力スキーマ固定、リトライオプション、会話履歴の要約とセッションステートによるコンテキスト管理。
- モデルの使い分けが重要。計画立案や最終出力は高性能モデル(Gemini 2.5 Pro級)、ツール実行だけのタスクは軽量モデル(Flash級)でコストとレイテンシを最適化する。
- 動的ルーティングは100%意図通りには動かないため、決定論的な処理はSequential/カスタムエージェントで固定し、柔軟性が要る箇所だけLLMに任せるハイブリッド設計を採る。
- 「AIエージェント=チャットアプリ」ではない。用途に応じてフォーム形式UIを選び、実行中のサブエージェントや進捗率を可視化して安心感を与え、Human-in-the-Loopで最終確認と編集を人間に残す。
- 2本目のLTでは、理想的なツールが揃っていてもエージェントは「前提条件を無視した実行」「中間成果物のID取り違え」「同じステップの重複実行」といった失敗をすると実例で共有。狭義のエージェントは最終手段にすべきという結論。
- 選定の指針: 一発で済むなら単発LLM → 手順が固定なら決定的なワークフロー → 終了条件が機械的に判定できない(Web検索など)、道筋が事前に決まらないタスクのみ自律ループのエージェント。
- 3本目は約6〜8人月見積もりの新規プロダクトを1か月強で立ち上げた事例。期間の1/3をMVP決定とシステム設計という「下準備」に充て、モノレポ徹底・Zod等でのスキーマ統一・エージェントにも人間にも読みやすいディレクトリ構成を最初に作り込んだことが7〜8割を決めたと述べている。
- 設計判断の「根拠」をコンテキストとして書き残すのが品質に効く(例: この画面は作業に集中してほしいので落ち着いた配色にする、という理由まで書く)。ドキュメントはエージェントに自動更新させ、CIで更新を担保する。
- 運用フェーズでは二重実装が発生して修正箇所が指数関数的に増え、開発速度が落ちる。DRY原則の徹底指示、重複検出パッケージの導入、GitHub Actionsでの定期レビュー→優先度付きIssue自動起票、問い合わせフォームからの不具合Issue自動生成と重複クローズ、リリースノートとバージョニングの自動生成などで対処している。
実践に使えること
- エージェントを作る前に、まず単発LLM→ワークフロー→エージェントの順で「一段下」で解けないか検証する。特に業務フローのように手順が決まっているものは、ワークフローの中に検索など不確定な部分だけエージェンティックなコンポーネントとして埋め込む。
- 1つのエージェントに全ツールを渡すのをやめ、「同じ情報・同じ目的を共有する1業務」を単位にサブエージェントへ分割する。プロンプト改善とデバッグの単位が揃い、再利用もできる。
- 出力はPydantic等でJSONスキーマに固定し、リトライ設定を入れる。レートリミットやリソース不足によるエラーはフレームワーク側の自動リトライで吸収する。
- 計画立案・最終出力は高性能モデル、検索実行など単純タスクは軽量モデルに割り当ててコストとレイテンシを調整する。複数ベンダーのモデルに同じタスクを並列で流し、別モデルで統合すると視点の幅が広がる。
- エージェントのUIはチャットに固定せず、入力が定型ならフォーム+選択式にする。レイテンシが長い分、実行中のサブエージェント名やタスク完了率を表示し、重要な反映内容はユーザーが選択・編集できるようにする。
- 新規プロジェクトをAI前提で立ち上げるなら、着手前にモノレポ化・スキーマ共有・機能単位のディレクトリ構成を整え、設計の「なぜ」をMarkdownで残す。ドキュメントの自動更新をエージェントに指示し、CIで検証する。
- 運用に入ったら二重実装の検知を仕組み化する。定期的な自動レビューでIssueを優先度付きで起票し、その修正用プロンプトまで自動生成しておくと着手が速い。
- 観測性はLangfuse等のOpenTelemetry対応ツールをフレームワークのWeb UIと併用し、レイテンシとエラーの原因を特定できる状態にしてから本番投入する。