【iOS 27】Evaluationsフレームワークで品質を測る
はじめに
こんにちは。リテールアプリ共創部のYahiroです。
オンデバイスでのAI実行が可能になった一方で、いざアプリに組み込もうとすると難しくなるのが品質の評価です。
iOS 27では、（前回記事のリンク）で紹介した「④確かめる」のパートとして Evaluations というフレームワークが登場しました。今回はこれについて書いていきます。
この記事でわかること
- なぜAIの品質は、これまでのユニットテストでは測れないのか
- Evaluationsが「品質」をどうやって数値にしているのか
- コードでは判定できない良し悪しを、AIに採点させる仕組み（モデルジャッジ）
- その採点役のAIが信用できるかを、どう確かめるのか
AIの評価が、従来のテストと違うところ
そもそもソフトウェアというのは、Aという入力に対してBという出力を返すプログラムがあった場合、基本的にいついかなる時も結果は変わりません。
だからこそユニットテストが成立します。「Aを入れたらBが返ってくるはず」という前提で組むことができます。
ところがAIではそうはいきません。同じAを入力しても、結果がBの時もあればCの時もあります。
Appleもセッションの中で、ユーザーはアプリのインテリジェント機能に対して安全性と信頼性を期待しており、予測不能な挙動をする機能をリリースすればアプリの評判に悪影響が出る、と述べています。
AIの挙動を、どうにかして定量的に測る必要があるわけです。
Evaluationsフレームワークとは
Evaluationsは、WWDC26でAppleが発表した、AIを使った機能の品質を測定・検証するためのフレームワークです。
考え方はシンプルで、たくさんのサンプルを流し込んで**「期待どおりに振る舞った割合」を測る**というものです。
主な対象はFoundation Modelsを使った機能ですが、セッションでは「確率的な動作をするシステムなら何でも評価できる」と説明されていて、分類器や回帰モデルも例に挙がっていました。
そしてEvaluationsには、大きく2つのアプローチが用意されています。
- コードで測れるものを測る
- コードで測れないものをAIに採点させる
セッションでは、書評から本のタグを自動生成するアプリ「Book Tracker」を題材に、この2つが順に紹介されていました。以下、同じ流れで見ていきます。
① コードで測れるものを測る
まずは定量的なアプローチから。やることは5つです。
- 測定対象 — 評価したい機能の呼び出しを書く
- データセット — 「入力」と「理想の出力」のペアを並べる
- 測定内容 — 何を測るかを定義する（例：生成されたタグが3〜8個に収まっているか）
- 集計 — 1件ごとの結果を、全体の傾向（平均など）にまとめる
- 実行 — Swift Testingから走らせ、合格ラインをアサートする
従来のテストが「正しいか」を問うのに対して、評価は 「どれくらいの割合で正しいか」 を問います。セッションのデモでは、この合格ラインを80%に設定していました。
従来のように「Bが返ってきたからOK」ではなく、「8割方期待どおりに振る舞うならOK」と評価するわけです。
また、実行結果はXcodeに専用のレポートとして残ります。メトリクスごとの合格率、サンプル1件ごとの結果、モデルが実際に返したレスポンスまで確認できるので、「80%を割った」だけでなく「どのサンプルがなぜ落ちたか」まで追えるようになっています。実際のUIがセッション中に紹介されていましたが、便利そうでした。これは、別記事で試してみたいと思います。
② コードで測れないものを、AIに採点させる
ここまでの評価は、すべて「コードで判定できること」を測っていました。タグの数、タグに空白が入っていないか、既知のジャンルが含まれているか。どれも定量的に測れてしまいます。
セッションでは、本のタグづけを行うアプリにおいて困った問題が発生します。
たとえば私が、以下のような感想を書いたとしましょう。
この物語は、ファンタジーですがとても奥深くて、面白かったです。
最近睡眠不足気味だったので、夜に読んでいたら面白すぎてさらに夜更かしになった気がします笑
あまり本が得意ではない私でも、すらすら読めてしまったので、今度は友達に勧めてみようと思います！
上記の感想文からAIでタグづけしてみたとしましょう。すると
#ファンタジー
#面白い
#睡眠不足
#夜
#友達
こんなタグが出たとします。ファンタジーまでは正しいですが、#面白い は私の完全な主観ですし、#睡眠不足、#夜 についてはもはや本の内容と関係がありません。
このとき、仮にタグが5個生成されることが基準なら、基準値としてはOKになります。ところが、タグの内容自体は本の内容と関係がないのでNGです。
ただこれについては、コードで #睡眠不足 や #夜 を弾くというのは不可能です。人間が読めば一発でわかりますが、定量的に表現する方法がない。
だったらモデルに読ませればいい、というのがモデルジャッジです。
採点基準を「言葉」で書く
要するに、AIが作ったタグを、別のAIに採点してもらうということです。
人間が1件ずつ読んで「これは違うだろ」と判断していた作業を、代わりにやってもらうイメージですね。しかも人間と違って、何百件あっても同じ基準でブレずに採点してくれます。
まずは、基準を書いてみましょう。
scale: .numeric([
4: "タグが関連性があり、閲覧に役立つ",
3: "概ね関連性があるが、1つ曖昧なタグがある",
2: "複数のタグが誤り、または一般的すぎる",
1: "役に立たない、または無関係"
])
上記のような基準を用意し、これと入力データをジャッジに渡して評価してもらいます。
なお、モデルジャッジは①の定量的な評価と同じ仕組みの上で動くので、ひとつの評価の中に定量と定性を並べて書くことができます。まったく別の仕組みを覚え直す必要はありません。
設計上のポイントが2つ紹介されていました。
スケールは偶数段階にする。 奇数だと、ジャッジは迷ったときに中立の真ん中を選びがちだからです。
人間でもありそうですね。仮に5段階評価だと3にしてしまいがちというのと同じです。
ジャッジには、評価対象と同等以上のモデルを使う。 デモではタグ生成機能自体はオンデバイスモデル、ジャッジ側はPrivate Cloud Computeの高性能モデル、という組み合わせでした。
「スコア」より「根拠」を読む
実際に走らせてみたとします。先ほどのレビュー文が4点満点中3点だったとしましょう。
この時、ジャッジが #友達 を指摘したのに、#睡眠不足 と #夜 をスルーすることがあります。ジャッジの根拠を見てみると、「概ね関連性があるが、1つ曖昧なタグがある」という解釈になっていたのです。
つまり、人間が読むと明らかに違うものの、ジャッジに渡した基準だけでいうと正しい、ということが起こります。ジャッジは基準に忠実に従っただけで、「関連性」という言葉に対しての解釈が人間とジャッジで異なっていたわけです。
セッション内では、「自分の判断の代わりが務まるようになるまでジャッジを調整していく」という順序が大事だと強調されていました。スコアに納得できないとき、まず疑うべきは機能ではなくジャッジのほうだ、ということですね。
ジャッジと人間のズレをどう測るか
ちなみに、このズレには名前がついています。ドリフトです。
モデルジャッジと人間の評価が食い違ったまま放置すると、データセットが大きくなるほどズレは広がっていきます。そうなると、そもそも評価が正しく機能しているのかどうかが分からなくなってしまいます。
では、どれくらいズレているかをどう測るか。ここで使うのが、統計学のコーエンのカッパ係数です。2人の採点者がどれくらい一致しているかを表す指標で、偶然一致してしまう分を差し引いて計算するのが特徴です。
WWDCのセッションでは、この係数が 0.6 を超えることを合格ラインに設定していました。統計学的に、0.6は意味のある一致水準とされているそうです（％ではなく、0〜1の係数の0.6です）。
このへんは、統計学も絡んで難しそうなので理解できたら記事にしたいと思います笑
おわりに
AIの登場で、これまでのソフトウェアに対する評価基準が新しく定義されてきた様に思います。
実装のみならず、企画などにおいても、AIに対する品質管理をどう製品に落とし込んでいくかは、難しくも面白そうだなと思いました。
