正解が主観のものをどう測るか AirbnbのAI評価の作り方

3行まとめ

• LLMの出力は毎回変わり、何が正解かは人の主観で決まります
• AIの答えをAIに採点させると、採点者そのものが新しい失敗の原因になります
• Airbnbは評価を後回しにせず、開発の最初に作ることを勧めています

何が起きたか

Airbnbのエンジニアリングチームが、生成AI機能をどう評価しているかをまとめた記事を公開しました。2026年7月28日付です。Rohit Girme氏ら5名の共著。

同社はレビューのハイライト、AIカスタマーサポート、ゲストとホストのやりとりを助ける機能などをすでに出しています。製品チームごとに評価の基準も手順も違いますが、土台の考え方は共通しています。インフラ担当のチームが道具と作法を用意し、各領域で得た学びを全社に配る形です。

記事はその共通部分を社外に公開したものです。冒頭で、評価のやり方に唯一の正解はないと断っています。

なぜ難しい・何がすごいか

生成AIは、これまでのソフトウェアテストの前提を壊します。普通のプログラムは、同じ入力に同じ出力を返しました。だからテストは「期待した値と一致するか」で書けました。

LLMは違います。出力は毎回ゆれ、しかも何をもって正しいとするかが読む人の判断に委ねられます。ここが厄介です。

判断が絡むぶん、採点を自動化しようとすると、結局AIにAIを採点させることになります。すると採点役のAIが持つ失敗の癖まで抱え込みます。さらに1回のやりとりの中で、検索・推論・ツール呼び出し・生成が数珠つなぎに動き、そのどれかひとつだけが静かに壊れます。

たとえ話

味見の基準を決めないまま、料理を大量に作る店を想像してください。作る速度は上がります。

でも「今日のスープは薄い」と誰かが言ったとき、それが好みの差なのか、本当に塩を入れ忘れたのかを判定できません。基準表を先に用意し、迷ったら料理長が最終判断を下す。Airbnbの言う評価の設計は、この段取りに近いものです。

用語ミニ辞典

• eval-driven development（EDD）: 失敗を事前に全部予想するのではなく、見つけた失敗をその都度テストとして書き足していく進め方。テスト駆動開発の生成AI版という位置づけです。
• LLM-as-a-judge: 強めのLLMに、別のLLMの出力をルーブリック（採点基準）に照らして採点させる手法。記事では仮想ジャッジと呼ばれています。
• ゴールデンデータセット: 人がラベルを付けた基準用のデータ。良い例だけを集めず、悪い例を必ず混ぜます。
• 較正（キャリブレーション）: 採点役のAIが人の判断とどれだけ一致するかを測り、ずれを詰める作業。
• トラジェクトリ: エージェントが答えにたどり着くまでに通った手順の道筋。

技術者向けの深掘り

評価は3層で重ねます。1層目はコードで書ける機械的チェックです。JSONが壊れていないか、長さが範囲に収まっているか。

安く速く、明らかな失敗をここで落とします。2層目が仮想ジャッジ、3層目が人手の評価です。

仮想ジャッジは較正しないと使えません。較正していないジャッジは、ジャッジがいない状態より悪い。偽の安心を与えるからです。

手順は、50〜100件のゴールデンセットを作り、ジャッジを走らせ、人との一致率を測る。目標は80%台後半から90%台です。ずれた事例を分析してプロンプトと少数事例を直し、届くまで回します。

一致度の指標にはCohenのkappaやKrippendorffのalphaが挙がっています。

評価器は3〜5個に絞り、1個が1つの観点だけを見ます。20〜30個の雑な評価器を並べるより強い、というのが同社の結論です。

エージェントでは最終出力だけ見ても足りません。正しい答えが、壊れた推論経路を覆い隠すからです。トレースとスパンを深さ優先探索で組み直し、どのサブエージェントがいつ呼ばれ、どのツールに何を渡したかまで見ます。

これは自分に関係ある？

AIツールを使うだけの立場なら、「このAIは正確です」という宣伝文句の読み方が変わります。何をもって正確としたのか、誰がそれを決めたのか。そこが書かれていない数字は、何も保証していません。

AIを組み込む側のエンジニアには、着手の順番の話になります。プロトタイプを100件動かして出力を全部読み、失敗を分類してから評価を書く。Airbnbが唯一のルールとして挙げているのが「迷ったらデータを見ろ」です。

チームを預かる人には、見積もりの話です。評価にはプロジェクト全体のかなりの割合を割く前提で計画する、と記事は書いています。専門家同士でラベルが割れたら、自動化の前に止めて合意を作ります。