--- title: "AI機能を測る：品質、費用、信頼" url: https://www.thinnd.site/ja/purodakuto-shiko/ai-kinou-wo-hakaru-hinshitsu-hiyou-shinrai/ language: ja author: "Nhu Duy Thin (Thinnd)" published: 2026-10-29 updated: 2026-10-29 section: "プロダクト思考" tags: ["AIプロダクト", "指標", "evals", "費用", "信頼", "測定"] summary: "AI機能は、3つの層を同時に測るべきです。品質：失敗の分類ごとの合格率で、エラー分析とevalsから取る。費用：レビューの手間を含めた、成功した結果あたりの費用と、平均でなくp95での遅延。信頼：利用者の受け入れ、修正、上書きの率、誤りを報告した回数、人に引き継いだケース。1つの層だけを測ると盲点が生まれます。この記事の閾値は例にすぎず、共通の標準はありません。" license: "Cite with the author name and the canonical URL above." --- # AI機能を測る：品質、費用、信頼 > 製品に関わる人、チームリーダー、AIを製品に組み込むプログラマーのための記事です。技術用語には短い説明を付けます。 > > 3つの層への分け方と指標は、**実務家の手引き**（ブログ、ツールの文書）から取りました。これは二次的な情報源です。**この記事の閾値と数字はすべて例**で、標準ではありません。お店「ホン」の例は、作り直したものです。 --- ## 先に要点 - 利用回数は成功では**ありません**。**仕事の結果**を測ります。 - **3つの層を同時に**測ります：**品質**、**費用**、**信頼**。1つの層だけでは盲点が生まれます。 - **正しい費用**は、**成功した結果**あたりの費用で、レビューの手間を含みます。 - **受け入れ率が高い**のは、過信かもしれません。evalsの合格率と並べます。 - **1ページの表**を使い、指標が悪化したとき何をするかを**先に決めます**。 --- ## むずかしい言葉をやさしく | 用語 | やさしい意味 | |---|---| | **Evals** | AI機能の品質を測るテスト（専用の記事を参照）。 | | **受け入れ率** | 利用者がそのまま受け取って使うAIの出力の割合。 | | **修正率** | 利用者が使う前に直す出力の割合。 | | **上書き率** | 利用者が捨てて、自分でやる出力の割合。 | | **p95の遅延** | 依頼の95%がそれより速く終わる時間。最も遅い場合を示し、利用者が実際に覚えているのはそこ。 | | **トークン** | モデルが処理し、課金の単位にもなる文章の単位。 | | **成功した結果あたりの費用** | 総費用を、AIが本当に役立った回数で割ったもの。 | --- ## 1. なぜ1つの数字で測らないのか 数えやすいものから始めるのは簡単です：呼び出しの回数、利用者の数。けれどAI機能は、とてもよく使われても**悪い**ことがあります：間違って答える、費用がかさむ、利用者に黙って無視される。 実務家の手引き（要約で読みました）は、2点で一致します：**呼び出しを数えるのは浅く**、大事なのは**完了した仕事**であること。そして、指標は**層に分ける**こと。1つに集中すると盲点が生まれるからです。よくある例：**95%正しいモデルも、利用者が信頼しなければ役に立たない**。 だから3つの層に分けます： | 層 | 問い | データの出どころ | |---|---|---| | **品質** | 出力は正しく、役に立つか。 | エラー分析、evals | | **費用** | 成功した結果1つにいくらかかり、速いか。 | 請求書、ログ、計時 | | **信頼** | 利用者は信頼して使うか。 | 利用者の行動、フィードバック | この記事は[AI機能のための評価を書く](https://www.thinnd.site/ja/gijutsu/ai-kinou-no-evals-30-no-jissai-no-jirei/)（品質の層）と、[生産性をコードの行数で測らない](https://www.thinnd.site/ja/purodakuto-shiko/gyosu-de-seisansei-wo-hakaranai/)（活動の指標が誤解を招く理由）につながります。 --- ## 2. 品質の層 品質は、1つの「正確さ」の数字ではありません。**エラー分析**から取ります：evalsの記事のように、失敗を分類にまとめて数えます。 **提案する指標：** - **失敗の分類ごとの合格率。** たとえば「意図の読み違え」「情報のでっち上げ」「口調が硬い」。分類ごとに1つの数字。 - **重大な失敗の件数。** でっち上げた価格は、口調の失敗とは全く違います。実際の結果を伴う失敗は、別に数えます。 - **全体の合格率**。ただし、それだけを**唯一の数字にしない**。 **「すべて合格」の数字**を出し、それから各分類に掘り下げます。evalsの手引きも、段階評価でなく合格か不合格を勧めています。 **追い方：** **モデル、プロンプト、データを変えるたびに**evalsを動かし直します。モデルを変えて動かし直さなければ、品質がどう動いたか分かりません。 --- ## 3. 費用の層 ### 3.1. 呼び出しあたり、成功した結果あたりの費用 呼び出しあたりの費用は、得やすい数字です。けれど機能が、モデルを安く呼びながら、**人の修正が多く要る**かもしれず、使える結果1つに多くの呼び出しが要るかもしれません。だから比べる価値のある費用は： **成功した結果あたりの費用** =（モデルの費用 + 基盤 + レビューや修正をする人の手間）÷ 成功した結果の数 **例（作り直した数字）：お店「ホン」の顧客対応アシスタント、1か月。** | 項目 | 例の値 | |---|---| | 顧客の質問 | 10,000 | | モデルと基盤の費用 | 2,000万ドン | | そのまま使えた答え | 6,500 | | 職員の修正が要った答え（1件3分、1時間6万ドン） | 2,500件、つまり7,500分、125時間、750万ドン | | 完全に職員へ引き継いだケース | 1,000 | | **総費用** | 20 + 7.5 = **2,750万ドン** | | **成功した結果**（そのまま、または素早い修正で使えた） | 6,500 + 2,500 = **9,000** | | **成功した結果あたりの費用** | 約**3,060ドン** | モデルの費用だけを見れば、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つの層を、毎週記録します。 | 層 | 指標 | 注意するとき | |---|---|---| | 品質 | 失敗の分類ごとの合格率 | ある分類が下がる、または新しい重大な失敗 | | 品質 | 重大な失敗の件数 | 実際の結果を伴うどんな失敗も | | 費用 | 成功した結果あたりの費用 | 利用が増えると上がる | | 費用 | p95の遅延 | 長くなる、または最初の言葉が遅い | | 費用 | レビューや修正の手間（時間） | 結果より速く増える | | 信頼 | 受け入れ率と合格率の比較 | 受け入れが合格をはるかに上回る | | 信頼 | 修正率と上書き率 | 急な跳ね上がり | | 信頼 | 利用者が誤りを報告した回数 | 増える | | 信頼 | 人への引き継ぎ | 少なすぎ（見逃し）、または多すぎ | **組み合わせます：** 速度や費用の指標には、必ず品質の指標を添えます。費用が下がり、合格率が落ちるのは、進歩ではありません。 --- ## 7. 指標が悪化したときのことを先に決める 行動の規則のない表は、飾りです。*例で、閾値は作り直したものです：* | もし | そのとき | |---|---| | 重大な失敗（でっち上げた価格など） | **その部分をいったん切り**、直してから戻す | | ある分類の合格率が、決めた水準を下回る | それ以上の展開を止め、プロンプトを見直す | | 受け入れが合格をはるかに上回る | 確認の段階を足し、出典を示す | | 結果あたりの費用が予算を超える | モデル、呼び方、範囲を見直す | | p95の遅延が長い | 出力を短くするか、呼び方を変える | 具体的な閾値は、**機能のリスク**によります。お金について答える機能は、タイトルを提案する機能より厳しい閾値が要ります。 --- ## 8. よくある落とし穴 - **利用だけを測る。** よく使われても、良いとは限らない。 - **いいね、よくないねだけ。** 押す人は少なく、両極に偏る。行動（修正、上書き）と組み合わせる。 - **費用にレビューの手間を忘れる。** モデルの費用は安くても、総費用は安くないかも。 - **平均が裾を隠す。** p95と最悪のケースを見る。 - **evalsを動かし直さずにモデルを変える。** - **指標を目標にする**（グッドハートの法則）：受け入れ率に報いれば、人は品質を上げずに、数字をよく見せる。 --- ## 9. バランスの取れた見方 - **二次的な情報源です。** 3つの層への分け方は、実務家の手引き（ブログ、追跡ツールの文書）から来ており、独立した研究ではありません。 - **閾値の標準はありません。** ここの数字はすべて例です。機能の種類ごとに、「普通の」受け入れ率や修正率がどのくらいかは分かりません。 - **測ることは手間がかかります。** 小さな実験なら、絞った1ページの表（品質、費用、信頼の指標1つ）で足ります。 - **指標は、利用者の声を聞くことの代わりになりません。** 毎週、実際のやり取りをいくつか読んでください。 - **お店「ホン」の例は作り直したもの**で、式を示すために私が作った数字です。 --- ## 10. 結論 良いAI機能は、最も多く呼ばれる機能ではなく、**正しい結果を、妥当な費用で出し、適度に信頼されている**機能です。3つの層を同時に測り、成功した結果あたりの費用を計算し、受け入れ率を合格率の**隣に置いて**読みましょう。 今日の小さな一歩：動かしているAI機能を1つ選び、**成功した結果あたりの費用**を計算し（修正の手間を足すのを忘れずに）、いつも使う数字と比べてください。 --- ## 参考資料 - [Antoine Buteau：AI product metrics, economics and support burden](https://www.antoinebuteau.com/ai-product-metrics-economics-and-support-burden/)（二次的、実務家の手引き） - [PostHog：Product metrics to track for LLM apps](https://posthog.com/product-engineers/llm-product-metrics)（二次的） - [Hamel HusainとShreya Shankar：LLM Evals, Everything You Need to Know](https://hamel.dev/blog/posts/evals-faq/) - [Stack Overflow Developer Survey 2025、AIの章](https://survey.stackoverflow.co/2025/ai) - ブログ内の関連記事：[AI機能のための評価を書く](https://www.thinnd.site/ja/gijutsu/ai-kinou-no-evals-30-no-jissai-no-jirei/)、[生産性をコードの行数で測らない](https://www.thinnd.site/ja/purodakuto-shiko/gyosu-de-seisansei-wo-hakaranai/)、[バイブコーディングで1日でプロトタイプ](https://www.thinnd.site/ja/purodakuto-shiko/vibe-coding-ichinichi-purototaipu/)