導入：AIの華やかなデモの裏に潜む「信頼性」の課題

AIアプリの信頼性を高める秘訣：Vercel V0とEvalが示す「本番で通用する」評価戦略

生成AIの波が世界を席巻し、その能力は日々進化を遂げています。息をのむようなデモが次々と発表され、まるで魔法のようにコードを生成したり、複雑なタスクをこなしたりするAIの姿に、私たちは未来への期待感を募らせています。しかし、その華やかなデモの裏側には、AIアプリケーションを「実用的な製品」として世に送り出す上で避けて通れない、根深い課題が存在します。それは、大規模言語モデル（LLM）が本質的に持つ「信頼性のなさ」です。

本日、私たちはVercelのエンジニア、Ido Pesok氏がAI Engineer World's Fairで行ったプレゼンテーション「Evals Are Not Unit Tests」を深く掘り下げます。Pesok氏は、Vercelが提供する革新的なWeb開発プラットフォーム「V0」を通じて、AIアプリの評価（Eval）をどのように捉え、システムの信頼性と品質を向上させるための実践的な戦略を紹介しました。本記事では、このプレゼンテーションで語られたEvalの概念、具体的な構築方法、そしてそれがビジネスに与える影響と将来性について、専門的かつ分かりやすく解説していきます。

Vercel V0: AI開発を加速するフルスタックプラットフォーム

まず、Ido Pesok氏が所属するVercelについて、そして彼が担当するプロダクトV0がどのようなものかをご紹介しましょう。Vercelは、開発者がWebアプリケーションを迅速にデプロイし、スケールさせるためのクラウドプラットフォームとして知られています。そしてV0は、Vercelが提供するフルスタックのWeb開発プラットフォームであり、Web上でのプロトタイプ作成、構築、新しいアイデアの表現を最も簡単かつ迅速に行えることを目指しています。

開発ワークフローの革新：GitHub Sync機能

最近、V0は「GitHub Sync」という画期的な機能をローンチしました。この機能により、開発者はV0で生成したコードを直接GitHubにプッシュできるようになりました。また、GitHub上の変更をV0のチャットインターフェースにプルしたり、ブランチを切り替えたり、プルリクエスト（PR）をオープンしてチームと共同作業を進めたりすることも可能です。これにより、AI生成コードを従来の開発ワークフローにシームレスに統合し、チーム開発の効率を大幅に向上させることができます。

急成長するV0エコシステム

V0は、そのリリース以来、驚異的なペースで成長を続けており、これまでに送信されたメッセージ数は1億件を突破しています。これは、多くの開発者がV0の可能性を認識し、そのプラットフォーム上で革新的なAIアプリケーションを構築しようとしている証拠です。Twitter上でも、V0を使って構築された様々なクールなプロジェクトが共有されており、そのユースケースは多岐にわたります。

しかし、その活況の裏側で、Ido Pesok氏が本プレゼンテーションで焦点を当てたのは、AIアプリ開発における見落とされがちな「評価」の側面でした。

「デモから本番へ」の落とし穴：LLMの信頼性問題

AIアプリのデモは、多くの場合、驚くほどスムーズで完璧に見えます。しかし、それが実際のユーザーに利用される「本番環境」に移された途端、予期せぬ問題に直面することが少なくありません。Pesok氏はこれを「デモの巧妙さ」と表現し、AIアプリが持つ独特の課題として「幻覚（hallucinations）」を挙げました。

「Fruit Letter Counter」アプリの失敗談

この課題を説明するために、Pesok氏は「Fruit Letter Counter」というシンプルな架空のアプリのストーリーを紹介しました。このアプリの目的は、与えられた果物の名前に入っている特定の文字（例えば「r」）の数を数えるというものです。

開発の開始: ChatGPTを使ってロゴを作成し、V0でUIとバックエンドを構築しました。
最初のテスト: openai(gpt-4.1).generateText({ prompt: 'How many r\'s in strawberry', model: 'gpt-4.1'})というシンプルなプロンプトを使い、「strawberry」に含まれる「r」の数を尋ねると、LLMは「3」と正しく回答しました。しかも、2回テストしても成功です。
自信のリリース: テストが成功したため、開発者は「fruitlettercounter.io」としてアプリをTwitterで自信満々にローンチしました。
問題の発生: しかし、すぐにユーザー（John Smith氏）から「『strawberry』に含まれる『r』の数を尋ねたら『2』と回答された」というツイートが届きました。

このシンプルな例は、LLMが本質的に信頼できない側面を持っていることを示唆しています。同じプロンプトであっても、異なる結果を返す可能性があります。

プロンプトエンジニアリングの限界

この問題に対し、開発者はプロンプトエンジニアリングで対応を試みました。一晩かけて、より詳細な指示を含む新しいプロンプトを作成したのです。「あなたは情熱的な果物好きAIで、果物の名前の文字数を正確に数えるという壮大な使命を帯びています。まず、与えられた果物の名前からスペース、紛らわしい句読点、反抗的な数字、悪意のある記号を大胆に取り除き、スリリングなミッションを開始してください。次に、残ったすべての文字を誇らしげに小文字に変換します。そして、止められない熱意をもって、1文字ずつ数え上げ、楽しく数を記録していきます。最後に、英雄的に数え上げた文字の最終合計を堂々と発表して、壮大な冒険を締めくくりましょう！」この非常に詳細なプロンプトで再度10回テストしたところ、今回はすべて「3」と正しく回答されました。開発者は再び成功を確信し、修正版をリリースしました。

しかし、再びJohn Smith氏から問題のツイートが届きます。今回は「[strawberry, banana, pineapple, mango, kiwi, dragonfruit, apple, raspberry]に含まれる『r』の数を尋ねたら『5』と回答された」というものでした。正解は8です。この例が示すのは、プロンプトを洗練させても、ユーザーが思いつくであろうすべての複雑なクエリに対応することはほぼ不可能であるということです。

「動かないものは誰も使わない」

Pesok氏は、この問題の本質を「誰も動かないものを使うことはない。それは文字通り使えない。」と簡潔にまとめました。AIアプリを開発する上で、この信頼性の課題は非常に重大です。デモではユニコーンAIアプリを掴めると思っても、本番環境では幻覚（hallucinations）が背後から忍び寄ってアプリを台無しにしてしまうのです。

アプリの95%は100%機能するかもしれません。認証、ログイン、ログアウトといった基本的な機能は問題なく動作するでしょう。しかし、最も重要な、そしてユーザー体験に直結する**残りの5%**でLLMが失敗する可能性があるのです。この5%がユーザーの信頼を損ない、アプリの利用を諦めさせる原因となります。

アプリケーションレイヤーでのEval（評価）戦略

では、LLMを活用した信頼性の高いソフトウェアをどのように構築すればよいのでしょうか？Pesok氏は、その鍵が「アプリケーションレイヤーでのEval」にあると力説します。モデル自体の性能評価（モデルレイヤーでのEval）とは異なり、アプリケーションレイヤーでのEvalは、実際のユーザー体験とアプリケーションの振る舞いに焦点を当てます。

メタファー：バスケットボールのコートでの評価

この概念を視覚的に理解するために、Pesok氏はバスケットボールのコートをメタファーとして使用しました。

コート全体: アプリケーションのドメイン（ユーザーが投げかける可能性のあるすべてのクエリ）。
ゴール: バスケット（正解、望ましい出力）。
シュート（タスク）: ユーザーの入力やプロンプト。
ショットの成功: 青い点（正しく機能したEval）。
ショットの失敗: 赤い点（機能しなかったEval）。
距離と難易度: バスケットから遠いほど、クエリは難しくなります。
境界線: コートの境界線は、アプリのスコープ（ドメイン）を示します。

データプロットの例:

「strawberry」の「r」の数という簡単なクエリは、バスケットに近い青い点。
複数の果物の「r」の数を尋ねる複雑なクエリは、バスケットから遠い赤い点。
「carrot」の音節の数など、アプリのドメイン外のクエリは、コートの外（境界線の外）に置かれ、評価の対象外と見なされます。

効果的なEval構築の原則

このバスケットボールのコートのメタファーから、Evalを効果的に構築するためのいくつかの重要な原則が導き出されます。

「コートを理解する」ことの重要性: これは最も重要なステップです。あなたのアプリがどのような「コート」でプレイされているのかを正確に理解する必要があります。具体的には、ユーザーがどのような種類の質問やタスクをアプリに与える可能性が高いのか、そしてそれに対してどのような応答を期待しているのかを把握することです。
- 「Out of bounds」の罠を避ける: ユーザーが関心のない、またはアプリのドメイン外のデータのためにEvalに時間を費やすべきではありません。あなたのチームには、ユーザーが実際に求めている課題を解決するという、もっと多くの問題があります。
- ポイントの集中を避ける: 特定のクエリタイプにEvalが偏らないように注意が必要です。コート全体を網羅するように、多様なユースケースをカバーするEvalを作成することが重要です。これにより、アプリの弱点（赤い点が多い領域）と強点（青い点が多い領域）を正確に特定できます。
データの収集: Evalの基盤となるのはデータです。できるだけ多くのデータを収集し、Evalに組み込むことが推奨されます。
- Thumbs Up/Down: アプリ内でユーザーがフィードバックを提供できるようにする（良い/悪いボタンなど）。ノイズが含まれることもありますが、アプリが苦戦している箇所を示す貴重なシグナルとなります。
- ログからのランダムサンプルを読む: オブザーバビリティ（可観測性）ツールを活用し、ユーザーがアプリをどのように使用しているかをログから定期的に確認します。週に一度、100個のランダムサンプルを読み解くだけでも、ユーザーの行動やLLMの課題について深い洞察が得られます。
- コミュニティフォーラム: ユーザーが直接問題を報告したり、議論したりする場は、LLMの失敗パターンを発見する宝庫です。
- X/Twitter: ソーシャルメディアでの言及も、ノイズはあるものの、問題の早期発見につながることがあります。
ショートカットはない: Evalの構築にショートカットはありません。地道な作業を通じて、ユーザーのニーズとアプリの振る舞いを理解し、継続的にEvalを改善していく必要があります。これは、最高のパフォーマンスを発揮するために日々の練習を欠かさないアスリートのようなものです。

Evalの構造化：データとタスクの分離

Evalをスケーラブルに保つために、コードの構造も重要です。

定数と変数の分離:
- data には、Evalの実行を通じて変更されない定数的な要素（例えば、ユーザーが尋ねる特定の質問「How many r's in strawberry」と期待される回答「3」）を配置します。これは、バスケットボールのコート上の固定された点に相当します。
- task には、実験したい変数的な要素（例えば、異なるシステムプロンプト、前処理ロジック、RAG（Retrieval-Augmented Generation）戦略、使用するLLMモデルのバージョンなど）を配置します。これは、プレイヤーがシュートを打つ位置や方法を変更するようなものです。
- 利点: この分離により、システムプロンプトやRAG戦略を変更しても、大量のdataを再構築する必要がなくなります。これにより、Evalの繰り返しがはるかに効率的になります。
AI SDKのミドルウェア: VercelのAI SDKは、「ミドルウェア」という良い抽象化を提供します。これは、RAGやシステムプロンプトなどの前処理ロジックを配置するのに最適な場所です。このミドルウェアを実際のAPIルートとEval間で共有することで、本番環境で実行されるロジックと、Evalでテストされるロジックが常に同期していることを保証できます。これは、練習（Eval）と本番（API）で同じ技術を磨くことに相当し、Evalの有効性を最大化します。

「スコアリング」：評価結果をどう解釈し、改善に繋げるか

Evalを実行した後、その結果をどのように解釈し、改善に繋げていくかが次の重要なステップです。

スコアリングはドメインに依存: スコアリングの方法は、アプリのドメインによって大きく異なります。例えば、「Fruit Letter Counter」のように明確な正解がある場合は、出力が期待値を含むかどうかをチェックするだけで十分かもしれません。しかし、文章生成のような創造的なタスクでは、スコアリングははるかに複雑になります。
決定的スコアリングとパス/フェイルへの傾倒: 原則として、スコアリングはできるだけ「決定的（deterministic）」で「パス/フェイル（pass/fail）」の形式に近づけるべきです。これは、デバッグを容易にするためです。多くのEvalが生成する大量のログを扱う場合、明確なパス/フェイルの結果は、何がうまくいかなかったのかを迅速に特定するのに役立ちます。複雑すぎるスコアリングロジックは、チーム全体で共有し、理解し、活用することを困難にします。
自問する：「何が失敗したのかを見るために、何を探せばよいのか？」: この問いに対する答えが、スコアリングロジックを構築する際の出発点となります。例えば、V0では生成されたコードが機能しない場合を探します。文章生成アプリであれば、特定の言語学的特徴やトーンの逸脱を探すかもしれません。この問いに答えを見つけたら、それを検出するコードを記述します。場合によっては、コードで自動的にスコアリングするのが非常に難しいこともあります。そのような場合は、人間によるレビュー（Human-in-the-Loop）が必要となることもあります。これはリソースを要しますが、正確なフィードバックを得るためにはやむを得ない選択です。
スコアリングを容易にするテクニック: Evalのスコアリングを簡素化するためのヒントとして、LLMのプロンプトにわずかな変更を加えることが有効です。例えば、Eval用のプロンプトにのみ「最終回答を<answer>タグで出力せよ」という指示を追加します。これにより、LLMの出力から答えの部分だけを簡単に抽出し、文字列マッチングなどの単純なロジックでスコアリングできるようになります。本番環境のプロンプトにこのタグを含める必要はありません。

CI/CDパイプラインへのEvalの統合

Evalを継続的な改善サイクルに組み込むために、CI/CDパイプラインへの統合は不可欠です。

Braintrust Evalレポートの活用: Braintrustのようなツールは、このプロセスを大いに支援します。Braintrustは、あなたのtaskを全てのdataに対して実行し、その結果を詳細なレポートとして提供します。このレポートには、改善点（Evalの青い点が増えた領域）と回帰点（赤い点が増えた領域）が明確に示されます。
プルリクエスト（PR）時の自動評価: PRが作成されるたびにEvalを自動的に実行し、そのレポートをPRに紐付けることで、プロンプトやロジックの変更がアプリの信頼性にどのような影響を与えるかを、開発チームがリアルタイムで把握できます。例えば、ある同僚がプロンプトの一部を変更するPRを出した場合、このレポートを見れば、「この変更は特定のユースケースでパフォーマンスを向上させたが、別のユースケースで回帰を引き起こした」といった具体的な情報を得ることができます。

これは、システムが全体としてどのように機能しているかを理解し、RAG戦略やシステムプロンプトの変更が実際にアプリを改善したことを、客観的なデータに基づいてチームに説明するための強力なツールとなります。

結論：測定がもたらすAIアプリ開発の変革

Ido Pesok氏は、プレゼンテーションの最後に「Improvement without measurement is limited and imprecise. (測定なき改善は限定的で不正確である)」という強力なメッセージを伝えました。そして、「Evals give you the clarity you need to systematically improve your app. (Evalは、アプリを体系的に改善するために必要な明確さを与えてくれる)」と締めくくりました。

AIアプリ開発の新たな時代において、Evalは単なる技術的なプラクティス以上の意味を持ちます。それは、LLMのデモが示す「魔法」の背後にある「現実」と向き合い、堅牢で信頼性の高い製品を構築するための羅針盤となるものです。

Evalを開発プロセスに導入することで、あなたのアプリは次のようなメリットを享受できるでしょう。

信頼性と品質の向上: ユーザーが直面する幻覚やエラーを減らし、期待通りの体験を提供できるようになります。
高いコンバージョン率と維持率: 信頼性の高いアプリは、ユーザーの満足度を高め、結果としてコンバージョン率の向上と長期的なユーザー維持に繋がります。
サポートと運用にかかる時間の短縮: 問題が事前に特定され、解決されることで、本番環境でのサポートチケットや緊急対応の必要性が減少し、開発チームはより戦略的なタスクに集中できるようになります。

AIアプリ開発の未来は、いかに「野生」で通用する堅牢なシステムを構築できるかにかかっています。Evalは、そのための明確な道筋を示してくれる強力なツールなのです。今日の華やかなデモの向こう側にある、本番で通用する信頼性の高いAIアプリを構築するために、今こそアプリケーションレイヤーでのEval戦略を真剣に検討する時が来ています。