PoCは作れる。問題はその先にある
LLMの進化でAIエージェントの「動くもの」はかなり短期間で作れるようになった。これは事実だ。ただ、本番に持ち込んだ瞬間に別の問題が噴き出す。品質をどう評価するか、システムの内部で何が起きているかをどう観測するか、そしてモデル呼び出しコストをどう制御するか。
Findy Toolsが公開した9社のAIエージェント特集（2025年5月）は、その「PoC後の壁」を正面から語っている記事として読む価値が高い。各社のアーキテクチャ図と運用の肉声が揃っており、抽象論ではなく具体的な失敗と対処が書かれている。
9社の課題を横断して読むと、同じ問題が形を変えて現れる
まず事実の整理から入ろう。
GMOペパボは「カフェのサイトを作りたい」という要望を起点にウェブサイトを最短10分で自動生成するエージェントを運用している。最大の課題として挙げたのは、ウェブサイトの「良し悪しを一意に判定できないこと」だ。LLMの呼び出しが成功してJSONが返ってきても、それが本当にユーザーへ渡せる品質かどうかは自動テストで判定できない。解として採ったのはデザイナーによるヒューリスティック評価で、「評価軸の明文化→LLM-as-a-Judge→自動改善ループ」という三段階のロードマップを描いている。観測基盤もあえてMySQLとMetabaseのシンプル構成からスタートし、「最初から本格的なデータウェアハウスを構えない」判断を明示している点が興味深い。
グリーホールディングスのSlack Bot「イルカちゃん🐬」は、運用後に「有益な回答が半数程度しかできていない」という現実に直面した。その後、GeminiとBigQueryを使ったLLM-as-a-Judgeによる日次の定量評価基盤を構築。ログ分析で検索クエリの粒度に問題があることを特定し、「SaaS製品名などの固有名詞を優先的に抽出する」よう指示を強化して精度改善につなげた。
KDDIアジャイル開発センターの「AIこーぽたん」は、利用拡大に伴うモデル呼び出しコストの急増という問題にぶつかった。対応策として、統括役のOrchestrator（Claude Sonnet 4.5）の下に2体のSpecialist（Nova 2 Lite）を置くオーケストレーション型マルチエージェント構成に切り替え、約55%のコスト削減を実現したと報告している。評価面でも10〜15問のテストセットを使ったAI自動採点基盤を整備し、モデル差し替えやプロンプト変更の判断スピードを改善した。
LayerXの「Ai Workforce」はエンタープライズ向けで顧客データの機密性が高い。そのためOpenTelemetryをベースにDatadog LLM Observabilityと連携し、入出力そのものは送信せず「実行構造・処理時間・エラー種別・モデル名・token数」のメタデータを中心に観測する設計を選んでいる。KINTOテクノロジーズとログラスはともにLangfuseをセルフホストで使い、ノード単位のトレースを運用基盤に組み込んでいる。
ここからは見方だが──三つの問題は実は同根だ
9社の課題を並べると、「評価できない」「観測できない」「コストが読めない」という三つの問題が繰り返し登場することに気づく。一見バラバラに見えるが、これらは根本的に同じ問題の別の顔だ。
AIエージェントは実行パスが非決定的だ。同じ入力でも「途中で選ばれるツール、参照する情報、判断の順番が実行ごとに変化する」（LayerXの記述）。だから従来のHTTPステータスやアプリケーションログでは中身が見えない。見えないから評価できない。評価できないから、どのモデル呼び出しが本当に必要だったか判断できず、コストが制御できない。
GMOペパボが「まず評価軸の明文化」を先行させ、自動化はその次と設計したのはこの構造を正しく理解した判断だと思う。自動化の前に「何が良いアウトプットか」を人間が言語化できていないと、LLM-as-a-Judgeに採点させても採点基準自体が曖昧なまま精度が上がらない。
もう一つ注目したいのは、各社が「どこまでエージェントに任せ、どこからワークフローで固定するか」という設計判断を慎重に下している点だ。GMOペパボは「定型化できる処理はワークフローで固定し、エージェントに任せる範囲を絞る」と明記しているし、ログラスも「決定論的なワークフローとして定義し、各ワークフローを構成する処理ステップをLLMが解決する」組み合わせを採用している。「全部エージェントに任せる」方向に振りきった結果、「同じプロンプトでも結果が大きく変わったり、SQL発行に失敗する」課題が顕在化したという経緯がログラスの事例で正直に書かれている。
実務に落とすと、何を優先すべきか
AIエージェントの導入を検討している開発チームやプロダクト担当者に向けて、この記事から引き出せる実務的な示唆を三点整理する。
第一に、評価軸の言語化は自動化より先にやる。 GMOペパボが示した「デザイナーが目で見てコメント化→評価軸の明文化→自動評価」という順序は、他のドメインでも参考になる。LLM-as-a-Judgeは便利なツールだが、採点基準が曖昧なまま使っても出力の信頼性は上がらない。
第二に、観測基盤は最初から作り込まなくていい。 GMOペパボはMySQLとMetabaseというシンプル構成を意図的に選んだ。「評価/改善プロセスの解像度が上がった段階で適切なデータ基盤への移行を進める想定」という記述は示唆的だ。最初から大きなデータ基盤を構えると、その維持コスト自体が足かせになる。
第三に、人間との協働設計を最初から織り込む。 グリーHDが「人間の担当者が対応を開始した際にAIが自動で沈黙する機能」を実装し、段階的に展開した経緯は、既存業務へのAI導入の現実的なアプローチとして参考になる。「AIが全部やる」ではなく「どの判断を人間に残すか」を設計する視点が本番運用では欠かせない。
今後の論点──「評価コスト」と「作業委任の条件」
次に問題になるのは二点あると見ている。
一つは評価コスト自体の肥大化だ。LLM-as-a-Judgeを日次で回せば、評価のためのモデル呼び出しコストが積み上がる。本番の品質を保証するために評価基盤を整備したはずが、その評価基盤のコストが新たな問題になるというのは、AIエージェント運用が成熟してくる次の段階で必ず表面化する。
もう一つはエージェントへの「作業委任」ができる条件だ。グリーHDが「PCのキッティングやライセンスの払い出しといった実際の作業を任せることができない」と正直に書いている。単なる回答生成と、実際のシステム操作を伴う作業委任の間には、現状まだ大きなギャップがある。社内ナレッジを「AI用に蒸留された軽量なデータベース」として整備するという方向性は面白いが、それが本当に機能するかどうかの検証はこれからだ。
PoC後の壁を越えた先に何があるか。9社のリアルは、その輪郭をかなり具体的に示している。
