LLMアプリ開発の精度評価｜開発前に決める5つの項目

生成AIを組み込んだサービス機能は、デモでは良く見えても、実際の利用でどれくらい期待どおりに動くのかを説明しにくいことがあります。この記事では、LLMアプリ開発で精度をどう評価するかを、開発に入る前に決めておきたい5つの項目として整理します。数字を先に約束するのではなく、「何を良しとし、どう測り、どこで判断するか」を決める考え方が分かります。

生成AI機能の「精度」が、従来のテストと違う理由

LLM（大規模言語モデル。文章を理解し生成するAIの基盤）を使った機能の精度は、従来のシステムのテストと同じ感覚では測れません。まず、違いを整理します。

従来のシステムでは、同じ入力を与えれば同じ出力が返ります。期待する結果を先に書いておき、一致すれば合格と判定できます。

LLMを使った機能は、事情が異なります。

• 同じ入力でも、言い回しや長さが毎回少しずつ変わる
• 「正しい回答」が1つとは限らない（要約や文章の下書きなど）
• 事実として誤っていても、もっともらしい文章になることがある
• 良し悪しの判断に、業務の文脈や会社の基準が入る

さらに、条件が時間とともに変わります。使うモデルの更新、指示文（プロンプト）の変更、参照するデータの入れ替え、利用者の入力の傾向の変化。どれも出力に影響します。モデルやAPIの版が上がる場面は今後も続きます。API新版の話題は「Claude API 3年ぶり新版、温度指定は送るとエラー」で取り上げています。

そのため、生成AI機能の精度は「一度測って終わりの数字」ではなく、「測り方を決めて、条件が変わるたびに繰り返し測るもの」と捉えるほうが実態に合います。

たとえば「正答率90%」と聞いても、何を正解とし、どんな入力を何件試した結果なのかが分からなければ、判断材料になりません。重要なのは数字そのものより、その数字がどんな評価から出たのかです。この評価の設計は、作り始めてから考えると後戻りが増えます。だからこそ、開発前に決めておく価値があります。

開発前に決めたい評価の5つの項目

ここからは、開発に入る前に、事業側と開発側で話し合って決めておきたい5つの項目を順に見ていきます。

1. 「良い出力」の定義（成功基準）

最初に決めるのは、その機能が出す結果を「良い」と呼ぶ条件です。ここが曖昧なままだと、あとの評価がすべて曖昧になります。

問い合わせへの返信文を下書きする機能を例にします。

• 事実関係が、社内の資料と矛盾していない
• 回答に必要な項目が抜けていない
• 会社として使う口調・表現の基準に沿っている
• 担当者が大きく書き直さなくても送れる長さと構成になっている

ポイントは、技術的な指標ではなく、業務や事業の目的から逆算して書くことです。「担当者の手直しがどの程度で済めば、この機能に価値があるのか」といった問いが出発点になります。作りたいものを言葉にする手順は「AI開発の仕様の伝え方｜作りたいものを言葉にする手順」でも整理しています。

2. 失敗の種類と、それぞれの重さ

次に、起こりうる失敗を洗い出し、重さを分けます。すべての失敗を同じ1点として数えると、重大な失敗が軽いミスに埋もれてしまうためです。

失敗の種類	具体例	重さの考え方
事実と異なる回答	存在しない規定を案内する	利用者への影響が大きく、重く扱う
根拠のない断定	不確かな内容を言い切る	内容や場面により重さが変わる
不適切な表現	失礼な言い回し、偏った表現	ブランドや信頼への影響で判断
回答の拒否・空振り	答えられる質問に答えない	利用体験への影響として扱う
情報の取り扱いの誤り	他の利用者の情報を出してしまう	最も重く扱い、設計で防ぐ
応答の遅さ	待ち時間が長く離脱する	利用シーンごとに許容値を決める

重い失敗は、評価で見つけるだけでは足りません。確実に防ぎたいものは、AIの出力をそのまま利用者に出さず、人の確認を挟む、出力できる範囲を限定する、といった設計で対処します。「どの失敗を評価で減らし、どの失敗を設計で防ぐか」の線引きも、この段階で決めておくと後の判断が楽になります。

3. 評価用データ（評価セット）を用意する

評価用データとは、機能に与える入力と、その期待する答えや採点メモをまとめたものです。精度評価の土台になります。

偏りなく集めたいのは、次のような種類です。

• 典型的な入力（実際に最も多く来ると想定されるもの）
• 難しい入力（情報が少ない、言い回しが曖昧、複数の用件が混ざっている）
• 境界の入力（機能の対象内か対象外か、判断が分かれるもの）
• あってはならない結果を引き出そうとする入力（範囲外の質問、不適切な依頼など）

集め方は、現場の担当者が実際に受けている問い合わせや、日々の業務で扱う入力を材料にするのが確実です。最初の件数は数十件でも構いません。大切なのは件数よりも、種類に偏りがないことと、1件ごとに「何を見て良し悪しを判断するか」が書かれていることです。

運用上の注意が2点あります。

1. 実際の顧客情報や社外秘の資料をそのまま使う場合は、扱いのルールを先に決める。生成AI開発での機密の扱いは「生成AI開発の情報漏洩を防ぐ確認点｜機密と事業アイデア」で整理しています
2. 指示文の調整に使うデータと、最終確認に使うデータを分けておく。同じデータで調整と確認を繰り返すと、そのデータにだけ合った状態になり、実際の利用で期待を下回ることがあるため

4. 誰が、どうやって採点するか

評価用データがあっても、採点の方法が決まっていなければ結果は出ません。採点の方法には複数の選択肢があり、次の章で詳しく比べます。ここで決めておきたいのは、次の3点です。

• 採点する人（事業の担当者、現場の担当者、開発側のどれか）
• 採点の基準表（項目ごとに、何点ならどういう状態かを書いたもの）
• 採点が割れたときの決め方

採点者が1人だけだと、その人の癖が結果に入ります。最初は複数人が同じ事例を採点し、点が割れたところを話し合うと、基準そのものの曖昧さが見つかります。

5. 合格ラインと、結果を見たあとの判断

最後に、結果をどう読んで何を決めるのかを、測る前に決めておきます。測ってから基準を考えると、出た数字に合わせて基準を動かしたくなるためです。

• 合格ラインは、項目ごとに分けて決める（重大な失敗の項目は厳しく、文体の項目は緩く、など）
• 合格ラインを下回ったときの選択肢を並べておく（指示文の見直し、参照データの追加、人の確認工程の追加、機能の範囲を絞る、見送る）
• 事業の判断基準とつなげる

事業の判断基準とのつなぎ方は、「MVP検証の指標を先に決める方法｜判断基準の作り方」と考え方が共通します。やめる判断の基準を先に置く点は「新規事業の撤退判断｜プロトタイプで「やめる」と決める基準」も参考になります。AIの出力が基準に届かない場合に、事業計画を見直すのか、機能を絞るのか。その分岐を前もって話し合っておくと、結果が出たあとに議論が止まりにくくなります。

評価の方法を使い分ける

採点の方法は1つに決める必要はなく、目的に応じて組み合わせます。主な方法の特徴を整理します。

方法	向いていること	注意点
ルールによる自動チェック	形式、必須項目の有無、禁止表現、文字数の確認	内容の良し悪しや意味の正しさは測れない
人による採点	事実の正確さ、業務への適合、表現の自然さ	手間がかかる。採点者の間でずれが出る
別のLLMによる採点	大量の出力を短時間で一次確認する	採点側にも癖が出ることがある。人の採点と突き合わせて確認が必要
実際の利用者による評価	業務での使いやすさ、期待とのずれの発見	少人数だと偏る。質問の設計が要る
公開ベンチマークの参照	モデルを選ぶ際の目安	自分たちの業務や入力に当てはまるとは限らない

自動チェックと人の採点を組み合わせる

実務では、まず自動チェックで形式の崩れや禁止表現を機械的に弾き、通ったものを人が採点する流れが取りやすい方法です。人の手間を、判断が必要な部分に集中させられます。

別のLLMに採点させる方法は、評価の回数を増やしたいときに役立ちます。ただし、採点するLLMの判断が人の感覚とずれていないかを、先に確かめる必要があります。人が採点した一部の事例とLLMの採点を並べ、一致しているかを見てから使うのが安全です。

プロトタイプで利用者に触ってもらう

評価用データの採点だけでは、実際の使い心地までは分かりません。業務の担当者に実際に使ってもらうと、「点数は高いのに使いづらい」「想定していなかった聞き方をされる」といった発見があります。その際の質問の作り方は「プロトタイプのユーザーテスト｜新規事業での確かめ方と質問」で扱っています。ここで見つかった入力は、評価用データに足していきます。

公開ベンチマークは、モデル選びの目安として使う

公開されているベンチマーク（共通の課題でAIの性能を比べる仕組み）は、候補のモデルを絞る段階で参考になります。ただし、自分たちの業務の入力や基準とは条件が違います。たとえばコーディングAIを同じ条件で採点する仕組みも公開されています（「Scope公開、コーディングAIの出来を同条件で採点」）。ここから学べるのは、同じ条件で測るから比べられるという考え方です。自社の機能でも、自分たちの評価用データという同じ物差しで測って初めて、モデルや指示文の比較ができます。モデル選びの視点は「AIシステム開発でのAIの選び方｜2026年10月比較」にもまとめています。

開発の段階ごとに、評価をどう進めるか

評価は一度で終わるものではなく、開発の段階ごとに役割が変わります。

開発前：基準を決める

前章の5項目のうち、成功基準、失敗の重さ、評価用データの最初の版、採点者、合格ラインの考え方を決めます。この時点では完璧でなくて構いません。「何を測るつもりか」を関係者で共有することが目的です。

プロトタイプの段階：実物の出力で基準を直す

動くプロトタイプができたら、実際の出力を並べて見ます。言葉の上では合意していた成功基準が、実物を見ると「これではない」となることはよくあります。その差を早い段階で直せるのが、実物を見ながら進める利点です。認識のズレを減らす考え方は「システム開発の認識のズレを防ぐ、実物を見ながらのすり合わせ」、動くもので確かめる手順は「新規事業のアイデア検証方法｜動くシステムで確かめる手順」を参照してください。

この段階で、評価用データに足りない入力のパターンも見えてきます。見つかった失敗例は、評価用データに追加します。

公開前：合格ラインに照らして判断する

決めておいた合格ラインに対して、結果を確認します。基準に届かない項目があれば、事前に並べた選択肢から対応を選びます。人の確認を挟む運用にする場合は、誰がどの範囲を見るのかも、ここで決めます。AIが関わる開発で人の確認が必要な理由は「AI開発でも品質には人の確認が必要な理由」で述べています。

なお、機能そのもののコードのテストと、AIの出力の評価は別の作業です。前者はテストの自動生成などを使えます（「AIのテスト自動生成｜任せる範囲と人が見る確認項目」）が、後者は事業の基準に照らした人の判断が中心になります。

公開後：測り続ける

公開後は、実際の利用で出た失敗例や、利用者の指摘を集めて、評価用データに加えていきます。モデルの切り替えや指示文の変更をするときは、変更の前後で同じ評価を回し、悪くなった項目がないかを見ます。小さく始めて確かめながら広げる進め方は「新規事業の開発は小さく作って確かめる投資判断の進め方」の考え方と同じです。

評価を決めるときに起きやすいつまずき

最後に、評価の設計でつまずきやすい点を挙げます。

• 良い例だけで判断してしまう：デモ用に選んだ例では、うまくいって当然です。難しい入力や範囲外の入力を含めて測らないと、公開後に差が出ます
• 平均だけで見てしまう：全体の点数が高くても、重大な失敗が少数残っていることがあります。失敗の種類ごとに見ます
• 評価用データに合わせすぎる：同じデータで調整と確認を繰り返すと、そのデータでだけ良い状態になります。調整用と確認用を分けます
• 開発側だけで基準を決める：現場の担当者や決裁者が見ている「良い」と、ずれる原因になります。新規事業では、目的は同じでも、判断の材料や進める速度の違いで話が噛み合わないことがあります（「新規事業で経営陣と現場がすれ違う原因は進め方のズレ」）。基準づくりは、立場の違う人が一緒に実物を見ながら進めると合意しやすくなります
• 精度の数字だけを条件にする：評価の方法を添えない数字は、後で食い違いのもとになります。数字より先に、評価の方法と基準で合意しておきます
• 一度測って終わりにする：モデルや入力の傾向が変わるため、測り直す前提で、評価用データと手順を残しておきます

まとめ

生成AIを使うサービス機能の精度は、作ったあとに1つの数字で示すものではなく、開発前に決めた基準で、繰り返し測るものです。

• 精度は「良い出力の定義」から始める。事業の目的から逆算して書く
• 失敗の種類を分け、評価で減らすものと、設計で防ぐものを線引きする
• 評価用データは、典型・難しい・境界・あってはならないケースを偏りなく集める
• 採点は、自動チェック・人・別のLLM・利用者の評価を組み合わせ、採点基準を決めておく
• 合格ラインと、下回ったときの選択肢を、測る前に決める
• 開発前・プロトタイプ・公開前・公開後の各段階で評価を回し、失敗例を評価用データに足していく

JustFitは、構想をもとに約1ヶ月で動くプロトタイプを先に開発し、実物を見てから契約を判断できる進め方をとっています。AI機能を含む新規事業でも、実物の出力を見ながら評価の基準をすり合わせるという考え方は共通だと、私たちは考えています。何を作るかを決めることと品質の最終判断は人の役割です。評価の基準づくりに悩んでいる段階でも、仕様が固まっていない段階でも相談できます。詳しくは「JustFitのサービス紹介」をご覧ください。