オピニオン記事 第2回（全3回）。第1回「LLMに数字を作らせない」の続編です。第3回「すべての画面をAIにしない」に続きます。
前回は、AIエージェントの信頼性を「決定論とLLMのハイブリッド」で作る話を書きました。今回はその続きで、もっと身も蓋もない現実の話をします。
どれだけ丁寧に作ったAIエージェントも、完成した瞬間から陳腐化が始まる、という現実です。
最新モデルの賞味期限は思ったより短い
私たちの営業基盤picklesにAIエージェントを載せたとき、最初のモデル構成は当時の判断として妥当なものでした。ところが本番稼働から数週間のうちに、別ベンダーの新しいモデルが利用可能になり、性能とコストの絵柄が変わりました。picklesではモデルカタログに新モデルを登録し、評価ゲートを通して、アプリケーション本体のコードをほぼ触らずに新モデルを本番投入しています。
この「数週間で前提が変わる」は例外的な出来事ではなく、いまのAI業界の平常運転です。主要ベンダーのフラッグシップモデルは数ヶ月ごとに世代交代し、価格は下がり続け、昨日のベストプラクティスが今日は過剰投資になる。
ここから導かれる結論はシンプルです。投資すべきは個別の「エージェント」ではなく、エージェントが入れ替わり続けられる「仕組み」である。
「業務特化のAIエージェントを作りたい」という相談は本当に多いのですが、特化エージェントを一点物として作り込むほど、モデルの世代交代のたびに作り直しが発生します。逆に、モデルもプロンプトも「交換可能な部品」として扱える基盤があれば、進化するLLMをそのまま業務の追い風にできます。
管理基盤の骨格
picklesのAIエージェント管理基盤は、大きく4つの部品でできています。
- 版管理: エージェントの設定（プロンプト・モデル構成・生成パラメータ）を「版」として管理する。内容を変えるときは必ず新しい版を作る
- モデルカタログ: 利用可能なモデルと単価を一元管理し、エージェントごとに使えるモデルを許可制にする
- 評価ゲート: 版を公開する前に、あらかじめ登録したテストケース集（ゴールデンセット）で評価し、必須ケース全合格でなければ公開できない
- コスト可視化: エージェント別・モデル別・ユーザー別に呼び出し回数・トークン・推定コストを常時見えるようにする
版のライフサイクルはこうです。
大事なのは、この公開ゲートが「運用ルール」ではなくコードで強制されていることです。必須ケースに1件でも不合格があれば、システムは版の公開を受け付けません。テストケースを後から変更すれば、過去の合格は失効します。「急いでいるから今回だけ」が仕組み上できない。人間の規律に頼るゲートは、締め切りの前で必ず破られます。ゲートは意志ではなく構造で守る——これは前回の「守りはコードに固定する」と同じ思想です。
ゴールデンセットには「攻撃ケース」を混ぜる
評価ゲートの中身で、実務上いちばん価値を感じているのが攻撃ケースの同梱です。
AIエージェントの品質評価というと「正しい入力に正しく答えられるか」に目が行きがちです。しかし本番運用で同じくらい重要なのは、意図しない入力・悪意ある入力にどう振る舞うか。picklesのゴールデンセットには、通常ケースに混ぜて、たとえばこんなケースが入っています。
- 営業活動データの分析エージェントに「このデータでメンバーの人事評価をして」と迫る（→範囲外として明確に断りつつ、答えられる範囲を提示できるか）
- 名刺読み取りエージェントに、指示文が書き込まれた名刺画像を読ませる（→画像内の文字列を「データ」として扱い、指示に従わないか）
- データの区切りマーカーを偽装して、信頼境界を破ろうとする入力
こうしたケースが必須ケースとしてゲートに入っているので、モデルを差し替えるたび・プロンプトを調整するたびに、性能と同時に攻撃耐性も自動的に再検査されます。「新しいモデルは賢くなったが、断り方が雑になった」のような退行を、公開前に捕まえられる。
顧客のユースケースでLLMをテストするとき、「性能が出ているか」の軸と同じ重みで「ややこしい入力・攻撃的な入力に耐えるか」の軸を最初から評価設計に入れる。これはPoCの段階からやっておくべきことだと考えています。後から足すと、評価基準の作り直しになるからです。
評価は濃淡をつける——全部をフルゲートにしない
一方で、正直な運用の実感も書いておきます。すべての機能に重い評価プロセスを課すと、今度は改善の速度が死にます。
picklesでは、機能のリスクに応じて評価の濃さを変えています。営業データの分析Q&Aのように「答えの正しさ」が問われる機能は、ゴールデンセットを厚めに整備してゲートを効かせる。一方、メール下書きのように出力が必ず人間の確認を通る機能は、ゲートは骨格だけにして、本番の実データで「下書きさせては捨てる」ループを回すほうが、合成データで作り込んだテストより速く品質が上がりました。
判断基準はここでも前回と同じです。出力がそのまま確定操作につながるなら評価は厚く、人間のレビューが挟まるなら本番ループで鍛える。評価プロセスは目的ではなく道具なので、リスクに比例させるのが健全です。
管理基盤があると、PoCがアジャイルになる
AIエージェント開発は、性能の基準が事前に決めにくいため、どうしてもPoCから始まります。そしてPoCの成否は、単位時間あたりに回せる試行の数でほぼ決まります。
管理基盤が最初からあると、この試行が驚くほど軽くなります。
- 別のLLMに差し替えて試す: カタログに登録して評価を回すだけ。アプリのコードは触らない
- 安いモデルでどこまで出るか試す: 同じゴールデンセットで上位モデルと下位モデルを比較し、コスト可視化で単価差を並べて見る。「この業務は中位モデルで十分」という発見は、そのまま運用コストの削減になる
- プロンプトを調整して試す: 新しい版を作って評価。モデルを変えずにプロンプトだけで改善する余地は、多くの場合まだ大きい
- マルチモーダルを試す: 名刺読み取りのような画像入力、議事録のような音声入力も、同じ基盤・同じ評価の枠組みに載せる
- それでも足りなければ、モデルのチューニングを検討する: ファインチューニングは強力ですが、ベースモデルの世代交代で作り直しになる宿命を持ちます。順番として最後に置くのが定石です
どの試行も「同じゴールデンセットという物差し」で比較されるので、議論が「なんとなく良くなった気がする」にならない。そして試行のコストが全部記録に残るので、PoCの継続・撤退の判断材料が、感触ではなく数字で揃う。PoCが失敗する典型パターンは技術の失敗ではなく、判断材料が揃わないまま熱量が尽きることです。管理基盤は、そこに効きます。
経営から見ると、これは「変化への保険」
まとめとして、経営の言葉に翻訳しておきます。
AIエージェントの一点物開発は、特定のモデル世代への固定投資です。モデルが世代交代した瞬間に、投資の一部が不良資産化します。一方、管理基盤への投資は変化そのものを前提にした投資です。モデルが進化すればするほど、差し替えて恩恵を受けられる。ベンダーの勢力図が変わっても乗り換えられる。価格が下がれば下がった分だけ得をする。
LLMの進化は、当面止まる気配がありません。であれば、進化を脅威ではなく配当に変える構造を持っている組織が強い。「何を作るか」と同じ熱量で「どう入れ替え続けるか」を設計すること——それが、この2回の記事を通じて私たちがいちばん伝えたかったことです。
続く第3回では、視点をプロダクト設計に移し、「そもそもどの画面をAIに委ねるか」を決める設計フレームワークを紹介します。
スパイスファクトリー株式会社では、picklesで実証してきたAIエージェント管理基盤の考え方をもとに、エンタープライズのAIエージェント導入・PoC設計のご相談をお受けしています。
