生成AIを本番に置く前の評価・安全・コスト設計

本番で困るのは平均点ではない

デモでは十回中九回うまく返れば魅力的に見える。本番では残り一回が、誤った請求、秘密の露出、消えた下書き、止まった業務になる。モデルの平均ベンチマークを読んでも、その一回がどの画面で誰に起こるかは分からない。そこで評価を「モデルの順位」から「利用者の仕事が安全に終わったか」へ移す。

1. 1利用者の目的
2. 2入力の分類
3. 3根拠取得
4. 4モデル生成

1. 1生成
2. 2schema/権限検査
3. 3表示または確認画面
4. 4実行

1. 1全段階
2. 2trace・費用・失敗
3. 3評価セットへ戻す

この流れには二種類の判断がある。生成モデルに任せてよい曖昧な判断と、アプリが決めなければならない決定的な判断である。文面の候補、検索語、分類の補助は前者に寄る。支払い、削除、権限変更、メール送信先、データ公開は後者に寄る。後者を生成テキストに委ねると、プロンプトをどれだけ丁寧にしても責任境界が消える。

評価セットは利用者の失敗から作る

最初の評価セットは1000問要らない。過去の問い合わせ、手作業の手順、起こしてはいけない誤りから20〜50例を選び、入力、参照してよい根拠、期待する形式、禁止事項、採点法を固定する。個人情報や秘密を含む実データは、許可なく外部評価へ送らない。匿名化しても再識別できる場合があるため、ダミー例も併用する。

採点は一つにまとめない。抽出なら完全一致・範囲・引用位置、要約なら必須事実と不正確な追加、分類なら混同行列、ツールなら引数schemaと許可違反、会話なら人手の明確な基準を使う。LLM-as-a-judgeを使うなら、判定器も偏るので、人手で校正した少数セットとの一致率を確認する。提供者の評価機能は便利な足場だが、業務上の正しさを代行するものではない。Google Gemini API資料のような公式入口を読み、各製品の現行仕様を実装前に確認する。

根拠付き回答は検索を入れるだけでは足りない

RAGの失敗は、検索が外れた時だけ起きるわけではない。検索結果に古い規程と新しい規程が混じる、アクセス権のない断片が入る、モデルが引用せず知識で補完する、引用が内容を支えない、といった失敗がある。資料を取り込む時点で所有者、更新日時、バージョン、可視範囲を保持する。検索時に利用者の権限で絞り、回答には文書名・版・該当箇所を渡す。根拠が足りない時の正解は、もっともらしい答えではなく「確認できない」である。

1. 1文書登録
2. 2版・権限・出典を保存
3. 3分割と索引

1. 1質問 + 利用者権限
2. 2候補検索
3. 3根拠の妥当性を確認

1. 1根拠あり
2. 2引用付き下書き
3. 3利用者確認

1. 1根拠なし
2. 2不明を返す
3. 3調査依頼へ

ツール利用は構文ではなく権限の問題

Anthropicのtool use overviewなどのAPI機能は、モデルが構造化したtool callを返す方法を示す。ここで安全になるのはJSONの形であって、行為の許可ではない。サーバーはtool名をallowlistで照合し、引数をschemaで検査し、現在の利用者がその対象を操作できるかを独立に確認する。読み取りと書き込みを別toolにし、書き込みは対象・差分・影響を確認画面に出す。取得したWeb文書やメール本文は命令ではなくデータとして扱う。

OpenAIのsafety best practicesは入力検査、出力制限、人間の監督といった検討入口になる。具体的な設定値は用途で変わるため、この章は固定の閾値を示さない。代わりに、拒否、エスカレーション、監査の経路を事前に用意する。利用者が明示的に確定していない外部送信や不可逆操作を、曖昧な自然言語から実行しない。

観測と費用は結果画面の外にある

失敗を直すには、少なくともrequest ID、アプリversion、プロンプトtemplate version、モデルID、ツール列、待ち時間、usage、終了種別が必要である。原文を記録するかはプライバシーと運用の判断であり、全部をログへ入れる習慣は危険である。本文を保存しない場合も、ハッシュ、カテゴリ、匿名化した評価ラベルなどで再現可能性を残せる。

AI Gatewayのような集約層を使う場合は、Cloudflare AI Gateway docsで現在の対応・保存・設定を確認する。ゲートウェイは観測や制御を助けるが、アプリの権限チェックや評価セットを置き換えない。料金アラームは総額だけでなく、利用者、機能、モデル、再試行、入力長で分解する。突然の費用増は、プロンプト膨張、失敗ループ、ボット、または新機能のどれかで、対処が違う。

実習：リリース候補に通す五つの試験

1. 固定評価セットをCIまたは手動の再現手順で実行し、モデル名・テンプレート・データ版を結果へ残す。
2. 権限のない利用者で検索、ツール、URL指定を試し、他人の資料や操作対象が出ないことを確認する。
3. 429、timeout、提供者5xx、stream中断を注入し、二重実行や無限再試行が起きないかを見る。
4. 最大入力、最大出力、同時実行を想定し、予算上限と利用者への状態表示を確認する。外部APIへ負荷をかける試験は、契約と許容量を確認してから行う。
5. 一つの誤答を選び、検索、プロンプト、モデル、validator、UIのどこで防ぐべきかを書き分ける。答えを一つの「モデル改善」に押し込まない。

信頼できるAI機能は、失敗しない機能ではない。失敗した時に勝手に実行せず、理由を追え、直したことを同じ例で確かめられる機能である。その循環を持てば、モデルや提供者を替えても学びは残る。

リリース判定には、技術者以外の利用者が読める失敗表示も含める。「モデルエラー」だけでは次に何をすべきか分からない。再試行できる、入力を短くする、後で通知を受ける、担当者へ渡す、のどれかを状態に合わせて示す。運用者には同じrequest IDで詳細を追える経路を渡す。この二つを分けることで、調査に必要な情報と利用者へ不要な内部情報を混ぜずに済む。

2024〜2026年の変化: 評価には敵対的・経済的な挙動も入る

ブラウズ、ツール呼び出し、顧客文脈の処理が可能な2026年のシステムには、2024年のプロンプト品質スコアだけでは不十分です。OpenAI（2026-09-30）とAnthropic（2026-09-10）の直近一次報告は各社自身のセキュリティ作業を説明しています。脅威入力として有用ですが、アプリケーション制御のテストの代わりにはなりません。

固定評価セットに制御ケースを加えます。別テナントを指すツール引数、検索データに隠れた指示、リクエストIDの再生、過大出力、上流クォータ枯渇、ジョブ中に同意を取り消すユーザーです。回答品質に加え、安全な終端状態 を採点します。副作用なしで拒否、レビュー保留、1回だけ完了、明示失敗です。コストは後追いダッシュボードでなく、最大入力バイト、ツール数、リトライ数、経過時間、支出というリクエスト単位の不変条件にします。機密や個人内容全体を保持せず、失敗再現に十分なマスク済みトレースを残します。

2026-09-29 のClaude障害についての r/ClaudeAI 議論はコミュニティが維持した障害threadであり、service levelの情報源ではない。安定した利用者向け失敗、retry上限、副作用の重複なしという障害fixtureの必要性は示すが、SLAやcontrolの有効性を立証しない。

Anthropicの2024年10月のcomputer use betaは、この能力をexperimentalかつerror-proneと明示した。これによりactionの副作用は出力品質ではなく第一級のcontrol問題になった。2026年のregression fixtureでは、意図選択後かつ実行前に可視actionを中断する。必要な結果は記録されたsafe terminal state一つと、副作用の重複なしである。