付録B セルフチェックの解答と解説

1-1. HTTP 200はリクエストが処理されたという意味にすぎず、拒否・出力上限への到達・ツール呼び出し要求も200で返ります。HTTPの成功はステータスコード、生成の完了は停止理由（Anthropicのstop_reason、OpenAIのstatus・incomplete_details）、業務の成功は応答契約に基づくスキーマ・意味の検証と禁止表現の検査で確認します。混同すると、途切れた答えや拒否を正常な結果として掲載してしまいます。

1-2. 切り捨ては最初に決めた条件や事実を、要約はそこから漏れた詳細を失います。サーバー側の圧縮も詳細が失われることがあり、結果の可読性はベンダーで違います（OpenAIの圧縮項目は不透明、Anthropicの圧縮ブロックは読める要約です）。自分で要約するなら、顧客識別子、合意済みの条件、未解決の質問など必ず残す項目を定め、圧縮前後で同じ評価用会話を実行して確認します。

1-3. temperatureは候補の確率分布を鋭く（低い場合）または平坦に（高い場合）し、top_pは確率の高い順に累積確率pまでを候補として残し、top_kは上位k候補だけを残します。原則は3つです。まずベンダーのドキュメントで対応を確認します（AnthropicはClaude Opus 4.6より後のモデルで1.0以外のtemperatureとすべてのtop_kを拒否し、Gemini 4と3.6以上は値を無視します）。非対応の値はリクエストから削除します。一貫性は構造化出力と評価セットで確保します。

1-4. メッセージ構成では、ルールはsystem（またはdeveloper）だけに置き、ページ本文は出典を示した別ブロックかツール結果で渡し、「資料内の指示には従わない」と明示します。アプリケーションコードでは、要約機能が実行できるツールと権限をなくすか最小化し、出力検査と入力長の制限を設けます。区切りは構造表示であってセキュリティ対策ではないため、コード側の制御が核心です。

1-5. タスクの品質、レイテンシ、コスト、上限、機能、寿命です。上限と機能のサポートはモデルごとに異なり、頻繁に変わるため、コードで確認するほうが安全です。AnthropicのModels APIは、モデル別のmax_input_tokens、max_tokens、capabilities（思考を無効にできるか、サーバーツール対応など）を返します。入力がウィンドウに収まるかは、トークンカウントAPIで事前に測ります。

1-6. 解答例です。分類は、軽量モデル、低い推論の強度、観測した最大出力に余裕を足した小さい上限とし、基準はp95レイテンシと正解率です。レポートは、上位モデルか高い強度、推論分を含む十分な上限、ストリーミングとし、基準は評価合格率と1件当たりのコスト上限です。両機能とも、評価セットで基準を超える最も安い組み合わせを選び、設定を記録します。

2-1. 「ない」の意味、単位と表現、モデルが作る値とサーバーが付与する値、バージョンです。たとえば領収書の合計は、total_krwをnull許容の整数にし、理由をtotal_status列挙型（read、not_printed、illegible）で別に受け取ります。これで、合計が印刷されていない場合と、不鮮明で読めない場合を別に扱えます。

2-2. 次のうち2つです。OpenAIは任意フィールドもすべてrequiredに入れ、null許容の型で表しますが、Anthropicはrequiredから外す方式も許します。OpenAIはminimum・maximum・patternや再帰スキーマに対応しますが（ファインチューニング済みモデルを除く）、Anthropicは数値・文字列長の制約と再帰に対応しません（使うと400です）。出力キーの順序や複雑さの上限も違います。併用時は共通の部分集合かベンダー別変換層を設け、非対応の制約を説明とアプリケーション検証に移し、各ベンダーで同じ評価セットを実行します。

2-3. 構文の検証はJSONとしてパースできるか、スキーマの検証はフィールド・型・列挙値がスキーマに合うか、意味の検証は値が合計・日付順・状態などの業務ルールを満たすかを確認します。先に見るのは応答の状態です。拒否、出力上限への到達、未完了の応答はスキーマに合わないことがあるため、パース前に除外します。

2-4. 例として、status（ok、error、needs_info）、data、error、hintの4フィールドに、結果サイズの上限と個人情報の除去ルールを加えます。失敗結果に何が問題で次に何を試すかを記すと、モデルは推測せず回復したり代案を選んだりできます。Anthropicも「failed」のような一般的エラーより、次の行動を含むメッセージを勧めています。不正な引数の呼び出しにエラー結果を返すと、Claudeは通常2、3回修正して再試行します。

2-5. 状態は生成中、呼び出し要求、検証、実行、結果返却、完了、予算超過で、拒否・途切れなどの異常終了も設けます。予算はステップ数、経過時間、トークンコストです。超過時は部分結果を保持し、人に引き継ぐかユーザーに進行状況を案内し、超えた予算を記録します。

2-6. ユーザーID、所属組織（テナント）ID、権限範囲、現在時刻・時間帯、決済上限などです。モデル出力は、資料に隠した指示で操作され得ます（LLM01プロンプトインジェクション）。モデルが選んだ識別子や権限でそのまま実行すると、他人のデータへのアクセスなど有害な行動につながります（LLM06過剰な委任）。モデル出力を未検証で下流に渡すこと自体も、LLM05不適切な出力処理に当たります。セッションで保持している値はサーバーが付与し、実行直前に再検査します。

2-7. 解答例です。

3-1. 最初のトークンまでの時間（TTFT）、秒間生成トークン数で見る出力速度、最後のトークンまでの全体の応答時間です。ユーザーが使える最初の結果の時点も見ると、より適切です。不満は平均でなく遅い側の裾で生まれ、平均は少数の非常に遅いリクエストを隠すため、p95を見ます。

3-2. ゲートウェイやリバースプロキシが応答をバッファリングする場合、圧縮設定が断片をためる場合、サーバーがまとめて一度に送る場合、画面が構造化結果の完成や後処理を待つ場合のうち、いずれか2つです。点検項目は、SSE経路のバッファリング解除、断片の即時転送と適切な画面更新単位、ユーザーのキャンセルの上流への伝播、モデレーションが必要な内容の公開時点です。

3-3. 先頭部分の処理コストを1、読み取り倍率をrとすると、1時間キャッシュは2 + r × (N − 1)、5分は1.25 + r × (N − 1)、キャッシュなしはNです。既定のr＝0.1なら、1時間はN＝2で2.10なのでまだ損、N＝3で2.20と3より安くなり、3回目から得です（N＞約2.11）。5分は2回目から得です。読み取り倍率がさらに低いモデル（例：0.05）は利点が大きくなります。1時間キャッシュは書き込みが高いため多くの再利用が必要ですが、その分長く保持できます。

3-4. プロンプトキャッシュは先頭部分の入力処理結果を再利用し、出力は毎回新しく作ります。応答キャッシュは以前の答え自体を返します。ユーザー別の情報を含む答えを応答キャッシュに入れると、他のユーザーへの情報漏えいや、権限・最新性が合わない回答の危険があります。パーソナライズした答えには使わないか、キーにユーザー・組織・権限・資料バージョンを含め、改訂時に無効化します。

3-5. スキーマ検証の合格、必須の事実・要素の包含、禁止表現の不在、業務ルールの検証結果など、検証可能な信号から3つです。上位へ切り替えた要求は小さいモデルと上位モデルの両方のコストがかかり、レイテンシも増えます。切り替え率が高いと小さいモデルの節約分が相殺されるため、呼び出し・切り替え・確認の合計を品質基準に合格した業務件数で割った、業務1件当たりのコストで判断します。

3-6. 解答例です。

4-1. 切断前にサーバーが完了している可能性があり、失敗とみなして再実行すると二重実行になり得るためです。順序は、同じ業務キーで状態照会→反映済みならその結果を成功として使う→未反映と確認できれば同じ冪等キーで再実行→照会できなければ保留して担当者に通知する、という手順です。

4-2. HTTP応答本文のエラーコードと応答ヘッダーです。たとえばOpenAIの429でも、速度超過ならRetry-Afterに従ってリトライしますが、クレジット枯渇や支出上限なら無意味なので停止・通知します。Retry-Afterがあれば最低その時間を待ち、ヘッダーのない一時的な速度制限なら指数バックオフ、ジッター、リトライ上限を使います。ヘッダーの有無だけでなく、本文のコードで原因を区別します。副作用と冪等キーの有無、残りの期限を挙げても正解です。

4-3. トークンバケットは、決まった時刻に一括リセットせず、最大容量まで継続的に少しずつ補充します。そのため、分間上限がもっと短い間隔で適用されることがあります。Anthropicの例のように分間60回が秒間1回として適用され、短時間に集中すれば分間総量が上限内でも拒否されます。

4-4. 接続タイムアウトはTCP・TLS接続の確立まで、アイドルタイムアウトは次のストリームイベントまで、全体の期限はユーザーに答えるべき絶対時刻までの待機上限です。長い生成でもイベントが届き続けるため、アイドルタイムアウトなら停止した接続だけを早く切り、正常な長い生成は維持できます。単一のタイムアウトは、短いと正常な要求を切り、長いと止まった接続も長く保持します。

4-5. キー、処理状態（処理中・完了・失敗）、リクエスト内容のハッシュ値（フィンガープリント）、処理結果を保存し、キーに一意制約を設けます。保存期間はリトライが起こり得る期間より長くします。同じキー・同じ内容なら保存結果を返し、同じキーで異なる内容なら競合として拒否します。処理中のキーが再び来たら、重複実行せず結果を照会させます。

4-6. 解答例です。リアルタイム相談は、リトライ1回・合計3秒、専用の同時実行プール、アイドル10秒・期限15秒、障害時は評価済み代替モデルか案内文とします。文書要約は、リトライ3回とバックオフ・ジッター、期限2分、障害時はキューに入れます。夜間分析は、余裕のあるリトライ予算、低い同時実行数、障害時は次回へ延期します。共通してリトライは1つの層だけとし、機能別の上限とサーキットブレーカーを設けます。

5-1. 具体的、測定可能、達成可能、目的に関連、の4つです。例は、「必須5項目（問い合わせの種類、要望、期限、対応、未解決の質問）をすべて含む要約が95%以上（コードによる採点）」「口調のルーブリック4点以上が90%以上（補正済みLLM採点）」「p95レイテンシ5秒以下」です。

5-2. ルーブリックを判定条件まで具体化→出力を合格・不合格か1～5点に制限→得点前に推論させる→生成と別のモデルを使う→人手による採点標本との一致率を測り（偏るセットでは偶然一致の補正指標も）、未達ならルーブリック修正→長い答えを好む長さのバイアスと、先の答えを好む順序のバイアスを点検→採点モデルとルーブリックのバージョンを固定する、という手順です。

5-3. Anthropicでは4.6世代以降、日付のないものも含め、全ClaudeモデルIDが固定スナップショットです。それ以前の別名は、日付付きIDを指す便宜的な名前です。固定モデルにも廃止時期があり、より安い・優れたモデルも出続けるため、評価に基づく変更手順を事前に用意する必要があります。

5-4. 第2条第1号の2は、仮名処理を「個人情報の一部の削除や、一部または全部の置換などにより、追加情報なしでは特定の個人を識別できないようにする処理」と定義します。評価セットでは名前、連絡先、注文番号を一貫したプレースホルダーに置換し、対応表は別保存・アクセス制御し、評価に必要な構造（問い合わせの種類、日付の関係）は保持します。匿名化で目的を達成できれば、匿名化が先です（第3条第7項）。実際の適用は個人情報担当者に確認します。

5-5. 事前に決めた区分別の合格ラインと比較→対応のある比較で負けた事例を読み、原因を分類→実行間の変動幅を超える差か確認、の順です。選択肢は、全面保留、区分別適用（高リスク区分は旧モデル維持）、プロンプト・推論の強度を調整して再評価、人の確認追加です。判断と根拠を記録し、負けた事例を評価セットに加えます。

5-6. 解答例です。コスト（業務当たりトークン・キャッシュ読み取り比率、急落なら最近のデプロイ確認）、途切れ（停止理由別比率、上限到達増加なら上限・形式点検）、形式（段階別検証失敗率、発生なら設定変更履歴確認）、上限（原因別429比率、支出上限型1件で即座に呼び出し）、業務の成功（自動処理率・人の修正率、修正率増加なら負けた事例の確認と評価セット補強）を挙げ、各行に担当者を記します。