エージェンティックAIフライホイール
本記事では、エージェンティックAIシステムのライフサイクルを、プレプロダクション段階と継続ループ（フライホイール）に分けて提案する。プレプロダクションでは問題定義、概念実証、パフォーマンス指標、初期評価セットを構築する。フライホイールは「出荷、観察、診断、改善」のサイクルを回す。診断段階での鍵は「評価ファースト」：エラーモードを特定したら即座に評価を書き、修正は別にスケジュールする。これにより、評価セットの成長はエラー発見速度に連動し、エンジニアリング速度から切り離される。5つの評価タイプ（引用検証、ツール使用正しさ、検索再現率@k、スキーマ/フォーマット検証、LLM-as-judge）も詳述。
記事インテリジェンス
要点
- エージェンティックAIのライフサイクル：プレプロダクション（問題定義、PoC、指標、初期評価セット）→フライホイール（出荷、観察、診断、改善）。
- 評価ファーストの原則：エラーモード発見時に評価を書き、修正は後回し。評価セットはエラー発見速度で成長し、エンジニアリング速度に依存しない。
- 5つの評価タイプ：引用根拠チェック（プログラムまたはLLM支援）、ツール使用正しさ（決定論的）、検索再現率@k、スキーマ/フォーマット検証、LLM-as-judge（ルーブリック付き）。
重要な理由
このニュースが重要なのは、エージェンティックAIのライフサイクル：プレプロダクション（問題定義、PoC、指標、初期評価セット）→フライホイール（出荷、観察、診断、改善）ためです。
技術的影響
モデル選定、推論コスト、プロダクト能力、評価基準に影響する可能性があります。
本記事では、エージェンティックAIシステムのライフサイクル、特に「エージェンティックAIフライホイール」の概念について深く掘り下げます。著者Aurimas Griciūnasは、SwirlAIニュースレターで、ほとんどのエージェントシステムが小さな初期評価セットで出荷され、その評価セットが捉えきれない本番障害が蓄積し、結果的にユーザーからのクレーム経由でデバッグされるという問題を指摘します。解決策は、フィードバックをシステムが利用できる入力に変換するライフサイクルです。つまり、トラフィックを評価に、ドリフトをシグナルに、予期しないエラーモードを回帰テストに変換します。
システムライフサイクルは2つの部分に分かれます。プレプロダクション段階では、問題定義、概念実証（PoC）、パフォーマンス指標、初期評価セットを含むプロトタイプを構築します。この段階は一度だけ実行され、明らかな障害なしにシステムをユーザーの前に出すことが目的です。
2番目の部分は継続ループ（フライホイール）です。最初のバージョンが出荷された後に機能し、「出荷、観察、診断、改善、再出荷」のサイクルを繰り返します。各ループで本番トラフィックを処理し、新しい障害モードを発見し、それらに新しい評価を追加し、これまでに書かれた評価のほとんどを満たす新しいバージョンをリリースします。
診断段階の「評価ファースト」原則が重要です。エラーモードを特定した瞬間に評価を書き、修正は別のスケジューリング判断とします。これはテスト駆動開発と同じ規律です。評価を先に書くことで、修正が実際にその障害を直したか検証でき、評価が後回しになることを防ぎます。また、修正が後日になるエラーモードを「保留評価」としてCIに残すことで、後の無関係な変更が偶然にその評価をパスさせた場合に検出できます。
記事では、5つの具体的な評価タイプを例示しています。
- 引用根拠チェック：出力の引用が実際に取得されたコンテキストに含まれているか、その主張を裏付けているかを検証。プログラム的（文字列照合）またはLLM支援（判定モデル）の2つの実装。
- ツール使用正しさ：決定論的。既知の入力に対する期待されるツール呼び出しと引数を比較。コードのみでモデル不要。
- 検索再現率@k：情報検索指標。既知の関連ドキュメントがトップkに含まれるかを測定。多くの場合「保留」バッジが付き、検索修正（チャンク再構築、埋め込み変更、リランカ追加）は数週間の作業となる。
- スキーマ/フォーマット検証：決定論的な構造チェック。出力をJSONスキーマ、正規表現、型定義と比較。
- LLM-as-judge（ルーブリック付き）：主観的、モデルで評価。
これらの評価タイプは、チームの好みではなくエラーモードが選択すべきであり、リストは網羅的ではないと注意されています。
全体として、エージェンティックAIフライホイールは、システムを継続的に改善するための体系的なアプローチを提供します。評価ファーストの規律と継続的な観察により、チームは迅速に問題を発見・修正し、同時に評価セットを蓄積して将来の改善に役立てることができます。