AI機能を測る：品質、費用、信頼

製品に関わる人、チームリーダー、AIを製品に組み込むプログラマーのための記事です。技術用語には短い説明を付けます。

3つの層への分け方と指標は、実務家の手引き（ブログ、ツールの文書）から取りました。これは二次的な情報源です。この記事の閾値と数字はすべて例で、標準ではありません。お店「ホン」の例は、作り直したものです。

---

先に要点#

• 利用回数は成功ではありません。仕事の結果を測ります。
• 3つの層を同時に測ります：品質、費用、信頼。1つの層だけでは盲点が生まれます。
• 正しい費用は、成功した結果あたりの費用で、レビューの手間を含みます。
• 受け入れ率が高いのは、過信かもしれません。evalsの合格率と並べます。
• 1ページの表を使い、指標が悪化したとき何をするかを先に決めます。

---

むずかしい言葉をやさしく#

---

1. なぜ1つの数字で測らないのか#

数えやすいものから始めるのは簡単です：呼び出しの回数、利用者の数。けれどAI機能は、とてもよく使われても悪いことがあります：間違って答える、費用がかさむ、利用者に黙って無視される。

実務家の手引き（要約で読みました）は、2点で一致します：呼び出しを数えるのは浅く、大事なのは完了した仕事であること。そして、指標は層に分けること。1つに集中すると盲点が生まれるからです。よくある例：95%正しいモデルも、利用者が信頼しなければ役に立たない。

だから3つの層に分けます：

この記事はAI機能のための評価を書く（品質の層）と、生産性をコードの行数で測らない（活動の指標が誤解を招く理由）につながります。

---

2. 品質の層#

品質は、1つの「正確さ」の数字ではありません。エラー分析から取ります：evalsの記事のように、失敗を分類にまとめて数えます。

提案する指標：

• 失敗の分類ごとの合格率。 たとえば「意図の読み違え」「情報のでっち上げ」「口調が硬い」。分類ごとに1つの数字。
• 重大な失敗の件数。 でっち上げた価格は、口調の失敗とは全く違います。実際の結果を伴う失敗は、別に数えます。
• 全体の合格率。ただし、それだけを唯一の数字にしない。

「すべて合格」の数字を出し、それから各分類に掘り下げます。evalsの手引きも、段階評価でなく合格か不合格を勧めています。

追い方： モデル、プロンプト、データを変えるたびにevalsを動かし直します。モデルを変えて動かし直さなければ、品質がどう動いたか分かりません。

---

3. 費用の層#

3.1. 呼び出しあたり、成功した結果あたりの費用#

呼び出しあたりの費用は、得やすい数字です。けれど機能が、モデルを安く呼びながら、人の修正が多く要るかもしれず、使える結果1つに多くの呼び出しが要るかもしれません。だから比べる価値のある費用は：

成功した結果あたりの費用 =（モデルの費用 + 基盤 + レビューや修正をする人の手間）÷ 成功した結果の数

例（作り直した数字）：お店「ホン」の顧客対応アシスタント、1か月。

モデルの費用だけを見れば、2,000万を10,000回で割って、1回2,000ドン。職員の手間と1,000件の失敗を見落とします。だから「成功した結果あたりの費用」のほうが、多くを明らかにします。

3.2. 遅延#

遅延は、平均だけでなくp95（とp99）で測ります。平均は最も遅い場合を隠しますが、利用者が離れるのはそこです。チャットの機能では、最初の言葉までの時間が、速いという感覚を大きく左右します。

---

4. 信頼の層#

最もよく省かれる層です。利用者の行動を見ます：

絶対的な水準だけでなく、傾向を見ます。 修正率の急な跳ね上がりは、個人に合わせた結果でなく、品質の低下の印だと述べる手引きもあります。

背景： Stack Overflowの2025年調査（回答者4万9千人超）では、46%がAIの正確さを信頼せず、強く信頼するのは3%だけでした。あなたの製品の利用者も、似た気持ちかもしれません。信頼は得るものであり、測るものです。

---

5. 落とし穴：高い受け入れ率は過信かもしれない#

この記事で、私が最も重要だと思う点です。利用者が出力の90%を受け入れているのに、evalsでは実際に正しいのは75%だけなら、15ポイントの差は、利用者が過信していることで、良い機能ではありません。

読み方： 受け入れ率を、evalsの合格率と並べます。

これらの率が、普通どのくらいかを言えるデータは、私にはありません。これは指標の読み方で、測定結果ではありません。

---

6. 1ページの表#

9つの指標、3つの層を、毎週記録します。

組み合わせます： 速度や費用の指標には、必ず品質の指標を添えます。費用が下がり、合格率が落ちるのは、進歩ではありません。

---

7. 指標が悪化したときのことを先に決める#

行動の規則のない表は、飾りです。例で、閾値は作り直したものです：

具体的な閾値は、機能のリスクによります。お金について答える機能は、タイトルを提案する機能より厳しい閾値が要ります。

---

8. よくある落とし穴#

• 利用だけを測る。 よく使われても、良いとは限らない。
• いいね、よくないねだけ。 押す人は少なく、両極に偏る。行動（修正、上書き）と組み合わせる。
• 費用にレビューの手間を忘れる。 モデルの費用は安くても、総費用は安くないかも。
• 平均が裾を隠す。 p95と最悪のケースを見る。
• evalsを動かし直さずにモデルを変える。
• 指標を目標にする（グッドハートの法則）：受け入れ率に報いれば、人は品質を上げずに、数字をよく見せる。

---

9. バランスの取れた見方#

• 二次的な情報源です。 3つの層への分け方は、実務家の手引き（ブログ、追跡ツールの文書）から来ており、独立した研究ではありません。
• 閾値の標準はありません。 ここの数字はすべて例です。機能の種類ごとに、「普通の」受け入れ率や修正率がどのくらいかは分かりません。
• 測ることは手間がかかります。 小さな実験なら、絞った1ページの表（品質、費用、信頼の指標1つ）で足ります。
• 指標は、利用者の声を聞くことの代わりになりません。 毎週、実際のやり取りをいくつか読んでください。
• お店「ホン」の例は作り直したもので、式を示すために私が作った数字です。

---

10. 結論#

良いAI機能は、最も多く呼ばれる機能ではなく、正しい結果を、妥当な費用で出し、適度に信頼されている機能です。3つの層を同時に測り、成功した結果あたりの費用を計算し、受け入れ率を合格率の隣に置いて読みましょう。

今日の小さな一歩：動かしているAI機能を1つ選び、成功した結果あたりの費用を計算し（修正の手間を足すのを忘れずに）、いつも使う数字と比べてください。

---

参考資料#

• Antoine Buteau：AI product metrics, economics and support burden（二次的、実務家の手引き）
• PostHog：Product metrics to track for LLM apps（二次的）
• Hamel HusainとShreya Shankar：LLM Evals, Everything You Need to Know
• Stack Overflow Developer Survey 2025、AIの章
• ブログ内の関連記事：AI機能のための評価を書く、生産性をコードの行数で測らない、バイブコーディングで1日でプロトタイプ