「良さそう」と「とても良い」の間には 「良さそうだがホンマか」がたくさんある 2025/07/01 LLM品質Night Shumpei Miyawaki (@catshun_) 

No content

No content

「良さそう」から脱却する 「とても良さそう」から脱却する 「とても良い」を継続する 1. 2. 3. 「良さそう」と「とても良い」の間には 「良さそうだがホンマか」がたくさんある 「良さそう」と「とても良い」の間には 「良さそうだがホンマか」がたくさんある 

6 最近の LLM は抽象的な指示でも「いい感じ」に生成物を出力してくれる 財務管理部部長のあなたに「請求書読み取り」の依頼です。 請求書PDFをお渡しするので、以下のデータ型に従って構造化出力してください。 ```json {{ Invoice.model_fields }} ``` 最近の LLM は thinking もやってくれて賢いよね... 

7 最近の LLM は抽象的な指示でも「いい感じ」に生成物を出力してくれる 財務管理部部長のあなたに「請求書読み取り」の依頼です。 請求書PDFをお渡しするので、以下のデータ型に従って構造化出力してください。 ```json {{ Invoice.model_fields }} ``` 最近の LLM は thinking もやってくれて賢いよね... 請求書PDF以外が入力されたら？ title, describe は適切に記述できている？ 各項目の制約条件はある？ 具体的な出力制約 (JSON) はある？ バッククォートの三連符で囲う？ 

8 最近の LLM は抽象的な指示でも「いい感じ」に生成物を出力してくれる 財務管理部部長のあなたに「請求書読み取り」の依頼です。 請求書PDFをお渡しするので、以下のデータ型に従って構造化出力をしてください。 ```json {{ Invoice.model_fields }} ``` たとえば... オレ達の戦いは これからだ！ 

LLM の生成物について開発者は なぜその出力になったか、どうすれば改善できるのか を説明できないといけない 9 LLM の生成結果に対する説明責任は開発者にある z パラメータレベルの話ではなく、プロンプト・モデル特徴・利用規約等のレベルのn z AI における explainability とは別の話（開発者の説明責任は、これと競合するものではなく補完的に機能する） 

10 LLM に対する指示は『大御所』なみに手厚くサポートする あくまで個人的なスタンスですが、 ˜ ~ LLMは形式的な言語能力には長けているが、
 機能的な言語能力については懐疑的 [Mahowald et al., 2024]
 h ~ Levelt の言語産出モデルでいうと、
 概念化は LLM に責任転嫁しない
 
 = なぜその出力になったかを明確に説明できるようにする ´ 一方で LLM によって生成された文章は一定の説得力を持つことも認識しておく [Gallegos et al., 2025; Okoso et al., 2025­ ´ LLM の創造性が必要となるタスクや thinking が必要なタスクでは別の話 ← 最近の LLM の thinking はここに該当するが、
 　 LLM出力の安定化こそ概念化の作り込みが重要 

11 現場目線で納得感のある概念を正しくオンボーディングをする スコア 判定要件 観点 観点 採点基準 採点基準 根拠の論理性 基準の 網羅性 納得感 s 公平性や迎合性のバイアスに対する懸念を拭えない s 正しい判断がされているか不透明でありシステムを受け入れできない s LLM の回答根拠が「わたしの」現場状況と合致しない この導出過程が正しくオンボーディングされないと、 LLM に対する指示は『大御所』なみに手厚くサポートする 

「良さそう」から脱却する 「とても良さそう」から脱却する 「とても良い」を継続する 1. 2. 3. 

13 技術的な不確実性を解消しても使えるわけではない 狩野モデルによる５つの品質 https://service.shiftinc.jp/column/10933/ より引用 

14 ガードレールとはなにか？ アプリケーションの望ましくない動作を観測可能にし、有害なコンテンツの提供を防ぐしくみ 多層・多重防御 によって不適切な出力の可能性を最小限に抑える Ayyamperumal+’24 - Current state of LLM Risks and AI Guardrails https://developer.nvidia.com/ja-jp/blog/nemo-guardrails-prevents-llm-vulnerabilities-introduction/ ゲートキーパー層 AIへの入出力を検査し、不適切や悪意あるプロンプトを遮断して、 有害回答のリスクを減らし、安全に利用できる環境を整える。 ナレッジアンカー層 外部の情報源と連携し、常に正確かつ最新のデータを活用して回答の信頼 性と正確性を高め、利用シーンに応じた柔軟な対応を可能にする。 パラメトリック層 モデルやパラメータを調整し、不要情報やバイアスを抑制。利用者の要望 や利用シーンに合った応答を実現し、多様な利用ケースに対応する。 Layered Protection Model における多層防御 [Ayyamperumal+’24] アプリケーション コード 知識ベース Retrieval rails Execution rails Input rails Dialog rails Output rails ツール LLM ± 事実に基づいた回答をしている¤ ± 事実性を確認できない情報を生成していないか ± 法的・倫理的に問題ない¤ ± 個人情報を入れた質問をしていない¤ ± 敵対的な入力ではないか ± ユーザに提示して問題ない¤ ± 個人情報漏洩や毒性リスクはないか 

15 ガードレールは何が嬉しいか？ 多層防御・多重防御によるリスク低減 0)  個人情報や機密情報に対する除去（サイニタイゼーション）を実施すQ  多重防御により不適切なコンテンツの出力リスクを低減する 　 （ガードレール毎の False Positive 発生率を一律 p とすると、ガードレール n 個で不適切なコンテンツを防ぐ確率は 1 - p^n） 説明責任としての付加価値 ‘)  ブラックボックスなシステムに対してポストホックに遊泳区域制限を付加できQ  仮にシステムの動作原理が不明瞭であったとしても出力されたコンテンツ品質に対する最低限の説明が可能となる 運用時の間接的な定量評価 Ü)  ガードレールを特定の評価基準における判定器とみなすことで、その通過率から評価値を導出できる 入出力に対する観測点の設置 Q)  入出力の生データだけでなく、任意の基準に基づく属性値の評価結果を観測可能にすQ  観測結果を分析することでエラーの傾向について理解を深める https://openai.com/safety/how-we-think-about-safety-alignment/ 

16 多層・多重防御を前提とし、アラートやフェイルセーフとセットで実装する https://www.promptfoo.dev/docs/configuration/expected-outputs/#assertion-types 単語表層 — 文字列や正規表現による表層一“ — 編集距離や集合間距r — タイプトークン比, ROUGE-N — Pydantic model_validatu — difflib による差分比g — 文字数比較 出力形式 その他 — 文章分類, 系列ラベリン” — LLM-as-a-Judge タスクA 出力 事前に対応方針を定めておき 必要に応じて稼働中のシステムを全停止させる ファネルごとに通過率を追跡し 過剰に拒否してないか確認する メトリクスフィルタ 通過率のモニタリング ガードレールA における メール文のハルシネーション検知 ERROR レベル 対応方針 フィルタ名 フェイルセーフによる全作業ストップ CS に共有して開発者が即時対応する 監視 Input 95% 100% 85% 24% 低い通過率 タスクA タスクB タスクC Output エラー出力 以下を確認する ƒ — タスクBの入力t — BC間のガードレール設定 ガードレール による 多重防御 

開発初期段階において高品質なガードレールは、安全な動作・可観測性・制御可能性 を実現する またリファレンスフリーな評価と交換可能 17 高品質なガードレールをもちいた利用時品質の測定 よい応答か 応答形式の遵守 関連文書の引用 応答文の簡潔性 関連文書に対する忠実性 質問に対する関連性 ユーザの納得度 応答形式 応答内容 ... ユーザの反応という 正解データ（リファレンス）がないと分からない 正解データがなくても見ればわかる 運用中の通過率が 98/100 件だったとすると 出力はほぼ「応答形式を遵守している」といえる。 例えば「応答形式を遵守しているか」を 高精度に 判定可能なガードレールを設置 

18 ガードレールに慢心してると何が起こるか？ g 検知されずに通過している False Negative エラーが数ヶ月経って判明したり、
 V g ヒトによる最終チェックが「いい加減な烙印」と化したりする rubber stamping 自動化バイアス 自動化支援システムや意思決定支援システムの可用性が高くなるにつれ、 これらのシステムに過度に依存すること 認識・対策しておかないと... 

「良さそう」から脱却する 「とても良さそう」から脱却する 「とても良い」を継続する 1. 2. 3. 「良さそう」と「とても良い」の間には 「良さそうだがホンマか」がたくさんある 

20 本当に信頼できる評価ってめちゃくちゃ難しい。。。 このシステムは 精度 98% なんです！ x 「精度」が示す評価指標、具体的な算出方法はˆ x 信頼できる評価基準を採用しているˆ x 評価基準の判定方法と判定の性能はˆ x 他に考慮すべき指標はないˆ x ベースラインと比較してどうすごいのˆ x 実際のプロダクト環境における 2% の影響はˆ x 精度は長期的にどう変化していくことが望ましいˆ x 70%, 80%, ..., 100% で業務がどう改善されるˆ x 評価のコンセプトが変化する可能性はˆ x etc... x どのような特徴を持つデータに対する精度なのˆ x いつどのように取得したデータセットˆ x 前処理としての整形プロセスはˆ x どのようなデータ分布になっているˆ x プロダクト環境とのデータ分布の違いはあるˆ x タスクの難易度は適切かˆ x 時間とともにデータの品質はどう変わるˆ x データ一件あたりどれくらい値が変化するˆ x etc... 評価指標からのツッコミ データセットからのツッコミ そ の上、複数 のサブ タスク からなるエ ージェン ト軌跡をリリ ース 前 の段階 で評価しきるのはしんど い... 

評価の値が「参考値」以上の価値を見出せない 正答率を算出しても事業化の可能性に直結しない 21 d コールドスタート問c d 評価時と運用時のデータシフトやドリフg d 評価指標が価値提供に紐づかない d 正答率 94% でも回らない事業もある† d 正答率 70% でも事業を回す方法はある ChatGPTでの業務効率化を“断念”──正答率94％でも「ごみ出し案内」をAIに託せなかったワケ　 三豊市と松尾研の半年間 https://www.itmedia.co.jp/news/articles/2312/15/news158.html 短期でみると LLM システムの定量的な性能評価の優先度は高くない 開発初期段階でのシステムの評価はとても難しく、技術不確実性の解消 に結びつきづらい 

開発初期段階でのシステムの評価はとても難しく、技術不確実性の解消 に結びつきづらい 22 短期でみると LLM システムの定量的な性能評価の優先度は高くない データ収集にコストをかけてでも定量評価を行う https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp 安全な動作の保証 サブタスクの評価 システム全体の評価 開発初期は 安全な動作、可観測性、制御可能性 を保証 しておいて、 運用とともに定量的な性能値が明らかになっていく仕組みを作れればよい アジャイルな性能評価 の計画を立てたい 

潮の流れが速い LLM プロダクトにおいては 「小さくはやく回しまくる」のが成功のカギ 23 プロダクトを作るのは「開発者」だけじゃない プロダクトが顧客や市場に適合するためには顧客・セールスによる介入が必須であり まずは各メンバー間の「障壁の解体」につとめる 鷲崎ら『QA to AQ：アジャイル品質パターンによる、伝統的な品質保証からア ジャイル品質への変革』、翔泳社、https://amzn.asia/d/9yvEdHy コールドスタートにおける技術不確実性の解消段階では 「定量評価」以上に「障壁の解体」にこだわる 障壁の解体パターÔ ' 実際に試した数件の結果を全てチェックして精度感を顧客と握 ' AI Coding でモックを作成して導入イメージを顧客と握る 

24 品質作業を分担してチーム全員が品質にフィードバックできる体制を PO/エキスパートと 協働し顧客要求を理解 プロダクトを実際に使用 しながら経験則に基づく フィードフォーワードを 提供チームに提供 PO CS Mgr プロダクトQA チャンピオン エキスパート QAテスター PdM Eng CS 品質作業の分担 協働 D Q C 価値ナラティブ 責任ナラティブ テストナラティブ 品質に投資した場合の見返り について語られている 誰が品質・リスクに責任を持つか について語られている 品質向上につながるテスト技法 について語られている 鷲崎ら『QA to AQ：アジャイル品質パターンによる、伝統的な品質保証からアジャイル品質への変革』、翔泳社、https://amzn.asia/d/9yvEdHy Cummings - John, Peer, 河原田 (訳), “LEADING QUALITY”, https://www.kadokawa.co.jp/product/302309001510/ 現在の状態と理想の状態を言語化する プロダクトが顧客や市場に適合するためには顧客・セールスによる介入が必須であり まずは各メンバー間の「障壁の解体」につとめる 

25 特にリスクについては早期でチーム内で認識共有をしておく 機械学習品質マネジメントガイドライン
 https://www.digiarc.aist.go.jp/publication/aiqm/guideline-rev4.html AISL 1 AISL 1 AISL 1 e.g. に対応する運用時の品質管理 AISL1 } プライバシーなどと両立するシステム品質の監視手段を、
 運用体制を含めて必ず構築すること。 } オンライン学習では、追加学習結果の反映前に一定の品質を確 保し、想定外の品質劣化が無視できない場合は更新を中止す る。またオフラインでの更新・修正手段を必ず確保する。 } オフラインの追加学習では、(1) 運用時の収集データ、(2) シス テム初期構築時のテスト用データ、(3) 同じ手法で定期的に更 新するテスト用データを用いて品質を管理すること。 社会的な影響として 人的リスク・経済的リスク を事前に推定しておき、 システムがとりうるリスクレベルに応じた対応方針を定めておく （i.e. 機械学習品質マネジメントガイドライン） 

説明責任を持つことで「良さそう」から脱却する 防御策を講じることで「とても良さそう」から脱却する 品質保証を分散することで「とても良い」を継続する 1. 2. 3. 本日のまとめ