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

1-1. エージェントは、必要なステップ数を事前に予測することが困難または不可能な未解決の問題に適しています。その代償は自律性に起因するコストの増加とエラー蓄積の可能性であり、広範なツールの権限もあわせて検討する必要があります。そのためAnthropicは、サンドボックスでの十分なテストと適切なガードレールを推奨しています。ステップがあらかじめ決まっているタスクであれば、ワークフローのほうがよりシンプルな解決策となります。

1-2. ガイドは6つの項目を挙げています。予測可能性を維持しなければならない作業、静的または限定された情報を提供する作業、高コストなエラーを最小限に抑えなければならない作業、完全な透明性が必要な作業、迅速かつ低コストに作ることが最も重要な作業、そして人々が価値を置いて自ら行いたいと望む作業の自動化です。このような作業では、ルール、検索、人間の判断のほうがAIよりも優れている可能性が高くなります。

1-3. ルール・照会が適しています。残席数は予約システムにすでに正確な値として存在するため、質問の意図だけを大まかに把握し、照会した値をそのまま表示すれば十分です。生成モデルが数値を文章に変換しても得られるメリットはなく、数値を誤って出力するリスクとコストが生じるだけです。

1-4. 訪問記録をシステムに残す業務手順と保存構造から作成します。予測モデルは過去の記録があって初めて構築でき、期待される結果があって初めて評価できます。紙の名簿しかない状態では、開発を開始しても結果を検証する方法がありません。

1-5. AI基本法第34条第1項は、リスク管理計画の策定・運用、技術的に可能な範囲での説明方針の策定・施行、利用者保護計画の策定・運用、人間による管理・監督、安全性・信頼性の確保措置を確認できる文書の作成と保管などを求めています。これとは別に第31条第1項の事前告知が適用され、第35条第1項は、事前に人間の基本権に及ぼす影響を評価する高影響人工知能影響評価を行うよう努めることを定めています。

1-6. 第37条の2第1項ただし書に基づき、同意・法律・契約の履行等による決定であれば拒否権は制限される場合があります。しかし、情報主体が決定に対する説明等を求める権利（第2項）とそれに伴う処理者の措置義務（第3項）、決定の基準と手順、個人情報の処理方式を容易に確認できるように公開する義務（第4項）はそのまま残ります。施行令によれば、処理者は正当な理由がない限り、決定の結果・主要な基準・処理手順等を盛り込んだ簡潔で有意義な説明を提供するか、情報主体が提出した意見の反映有無を検討して通知しなければなりません。拒否権の制限が条項全体の免除を意味するわけではありません。

1-7. 答えは課題ごとに異なります。良い答案は、5つの質問（ルールで定められるか、原文を見せれば事足りるか、効果がコストを上回るか、記録と期待される出力があるか、エラーが取り返しのつかない被害につながるか）に順番に答え、最初に該当した質問から6つの結論（着手（自動化）、着手（補助形態）、形態変更（ルール・検索）、データ先行、保留（現状維持）、作成しない）のうち1つを導きます。着手という結論に至った場合は、評価セットの準備を次のアクションとして記述します。

2-1. 必ず含めるべき4つの要素は、何を（指標）、どこで（データ）、どれくらい（基準値）、どのように（測定方法）です。1つでも欠けると、他の人が合否を判定できなくなります。ここにベースライン（何と比較した数値なのか）を併記すれば、基準値がなぜその数値なのかを説明できます。

2-2. 例えば、「本番リクエストの95%で最初のトークンが1.5秒以内に出力され、全体の応答が8秒以内に完了する」のようにパーセンタイルと時間制限で記述します。ユーザーが画面の前で待機する機能では、体感遅延を左右する最初のトークンまでの時間（TTFT）を主要指標とし、全体の時間は補助指標とします。測定方法には、どこで測定するのか（ネットワークを含むユーザー端末基準か、サーバーのAPI応答基準か）も記載しなければ、開発チームと同じ基準で判定できません。

2-3. 適合率は陽性と判定したもののうち実際の陽性の割合であり、再現率は実際の陽性のうち陽性として捉えられた割合です。前者は「捉えたものがどれだけ正しいか」、後者は「捉えるべきものをどれだけ捉えられたか」を測定します。

2-4. 適合率を守る必要があります。捉えた案件が人間の確認なしにそのまま予約の削除につながるため、キャンセルリクエストではないメッセージを誤って捉えてしまうと、正常な予約が削除される事故につながります。見逃したキャンセルリクエストは、スタッフがメッセージを再度確認するか患者が再度連絡して処理できるのであれば、コストは比較的小さくて済みます。

2-5. モデルが安全性上の理由で拒絶した場合（stop_reasonがrefusal）、拒絶メッセージがスキーマの制約より優先され、出力がスキーマと一致しないことがあります。出力がmax_tokensの制限に達して途中で切れた場合も、結果が不完全になりスキーマを守れないことがあります。そのため、バリデーションと失敗時の処理ルールが必要になります。

2-6. (ア) 口座番号が残る割合は個人情報インシデントにつながるため、リリース遮断基準です。(イ) 簡潔さのスコアは利用に支障のない品質項目であるため、改善目標です。(ウ) 返金期限の誤記の割合は、顧客が誤った期限を信じて行動し損害が生じる可能性があるため、リリース遮断基準です。

2-7. 良い答案は、失敗の瞬間（回答不能、入力が範囲外、根拠不足、処理遅延、システム障害など）ごとにユーザーに表示する文言と次のアクション（直接入力、関連メニュー、担当者への接続、再試行のタイミング）を具体的に記述します。「エラーが発生しました」のように次のアクションが記載されていない項目がある場合、まだ設計が完了していないことを意味します。

3-1. 評価目標の定義、データ収集、評価指標の定義、実行と比較、継続的評価の順です。前段階の結果が次段階の入力となるため、順序を変更することはできません。

3-2. 無関係または存在しない入力、過度に長い入力、チャット機能であれば質の低い・有害な・無関係なユーザー入力、そして人間同士でも判定が分かれる曖昧な事例です。

3-3. コードによる採点は、ルールで表現しにくい複雑な判断においてニュアンスを汲み取れず、正解と表現が異なるだけの正しい回答に対して脆弱です。LLMによる採点は結果に多少のばらつきが生じる可能性があるため、事前に信頼性を確認し、人間の採点と照らし合わせて補正する必要があります。人間の採点は品質が高いものの、時間がかかり高コストです。

3-4. 返却期日の日付は、貸出システムの値と完全に一致するかどうかをコードで採点します。正解が決まっているため、最も高速で信頼できます。案内のトーンには正解の文字列が存在しないため、ルーブリックを与えたLLM採点器で採点しますが、人間が採点したサンプルと事前に対照して一致度を確認したうえで使用します。

3-5. 能力評価は、まだうまくこなせないタスクをどれだけ上手に行えるようになったかを確認するものであり、低い合格率からスタートします。回帰評価は、すでにうまくこなせていたタスクを引き続き問題なくこなせているかを確認するものであり、合格率はほぼ100%である必要があります。能力課題を安定してこなせるようになったら、その課題を回帰スイートへと卒業させ、継続的に実行して性能低下を監視します。

3-6. 開発セットに合わせて修正した過学習を疑う必要があります。開発セットでは23%ポイント向上したものの、修正時に参照しなかったホールドアウトセットでは2%ポイントしか向上していないため、実際の改善はわずかです。リリースの判断はホールドアウトセットの結果をもとに行い、開発セットでのみ改善された事例を精査して原因を特定します。

3-7. 人間が複数の候補の中から1つを選択する機能では、k回のうち少なくとも1回成功すればよいため、pass@kが適しています。顧客が毎回同じ品質の回答を受け取る必要がある機能では、k回すべて成功しなければならないため、pass^kが適しています。

3-8. 良い答案は、本章のフォーマットの欄をすべて埋め、成功基準ごとに採点方式（正解と対照できる場合はコード採点、ルーブリックで判定できる場合は人間と対照して補正したLLM採点、専門的な判断が必要な場合は人間の採点）とその理由を記述します。評価セットの欄には、実際の比率に準じた構成、エッジケースのセット、高リスクセット、そして各セットから切り離して確保したホールドアウトセットが個別に記載されている必要があります。

4-1. モデルが「わからない」と答えることを許容すること、長い文書から直接引用を先に抽出して根拠とすること、主張ごとに引用によって検証し、根拠が見つからなかった主張は撤回させることです。

4-2. 過剰拒絶は誤った情報を与えるわけではないため、誤答の割合（エラー率）にはカウントされません。正答率を全問題基準で測定すると、拒絶も不正解としてカウントされるためスコアは低下しますが、拒絶率を個別に観察しなければ、そのスコア低下が拒絶によるものかどうかが分かりません。対処の方向性は2つあります。回答可能であった拒絶事例を評価セットに組み込んで改善し、拒絶そのものを減らすこと、そして拒絶する場合であっても関連メニューの案内や担当者への接続といった次のアクションを提示することです。

4-3. Claudeのドキュメントによれば、構造化出力は文字列の列挙値（enum、const）の大文字・小文字を保証しないため、エラーや特別な中断理由なしに正常終了した応答であっても、大文字・小文字のみが異なる値が含まれる場合があります。そのため、列挙値は大文字・小文字を区別せずに比較するバリデーションを残しておきます。拒絶（stop_reasonがrefusal）やmax_tokensへの到達によってスキーマから外れるケースもあるため、中断理由の確認とスキーマ検証を併せて実施します。

4-4. キュー（待ち行列）が適しています。30分間続いている障害に対して数回の再試行は適切ではなく、送信はリアルタイム性を必要とせず翌日の午前中まで猶予があります。リクエストを保管しておき、復旧後に処理して、担当者に完了予定時刻を通知します。段階的縮小は、ユーザーが今すぐ結果を確認しなければならない機能において、よりシンプルな経路を提供する場合に適した対応です。

4-5. 事前承認は、結果を取り消すことができず処理量がレビューの処理能力内に収まる場合に適しています。条件付きエスカレーションは、処理量が膨大でリスクが特定のサブセットに集中している場合に適しています。事後サンプリング点検は、エラーを容易に修正でき被害が軽微である場合に適しています。異議申し立て処理は、結果が個人に影響を与え、当事者がエラーに気づくことができる場合に適しています。

4-6. 第1に、AIが実際には非常に正確であるため、全件の事前承認が過剰になっている状況が考えられます。この場合は、リスク条件や確信度の低さに該当した案件のみを送る条件付きエスカレーションへと縮小します。第2に、レビュー担当者に判断根拠や修正権限がないため、確認を諦めてしまっている形式的な承認である可能性が考えられます。この場合は、レビュー画面に根拠、修正・拒否機能、および理由の記録機能を組み込みます。既知のエラーを意図的に混入させ、レビュー担当者がそれを検知できるかどうかを確認することで、両者を見分けることができます。

4-7. 第1項は、高影響または生成AIを利用した製品・サービスを提供しようとする場合、その製品・サービスが当該人工知能に基づいて運用されているという事実を利用者に事前に告知することを求めています。第2項は、生成AIまたはそれを利用した製品・サービスを提供する場合、成果物が生成AIによって生成されたという事実を表示することを求めています。両者は別個の義務であるため、一方を履行したからといって他方が免除されることはありません。

4-8. 良い答案は、少なくとも捏造された回答（ハルシネーション）、過剰拒絶、形式エラー、一時的障害、長期障害を行に配置し、各行に予防（根拠の引用、拒絶事例の評価、構造化出力、トラフィックの段階的増加、代替経路の準備）、検知指標、失敗時の動作、ユーザーに表示される文言と次のアクションを記載します。免責事項のみが書かれている欄がある場合、その欄は対応策とは言えません。

5-1. 問題を顕在化できること、代表性があること、そして変更に起因していると特定できること（変更への帰属性があること）です。

5-2. シャドウテストはユーザーに新しい結果を表示しないため、通報、離脱、コンバージョンといったユーザーの反応を測定することができません。ユーザーの反応を確認する必要があり、ロールバックが容易な変更であればカナリアリリースを、2つの案のビジネス指標に対する効果を比較したい場合はA/Bテストを採用します。

5-3. 小さなサンプルから生じた差は偶然である可能性があり、基準を超えているかどうかを判定できません。最小サンプル数が設定されていないと、偶然のノイズによってロールバックしてしまったり、根拠がないまま次のフェーズへと拡大してしまったりします。最小サンプル数は判定のための前提条件です。

5-4. システム（エラー、遅延、コスト）、品質（根拠の引用割合、スキーマ検証の失敗、拒絶率、サンプル採点）、ユーザー行動（再生成、オペレーターへの転送、離脱、通報）、ビジネス（コンバージョン、コスト削減）の4つの層です。捏造された回答（ハルシネーション）はシステム側から見れば正常な応答として出力されるため、エラー応答率には一切検知されません。

5-5. Active（完全サポート、推奨）、Legacy（アップデート停止、将来的にサポート終了の可能性あり）、Deprecated（動作するが非推奨、代替モデルと引退日を指定）、Retired（利用不可）です。引退したモデルに送信されたリクエストは失敗します。

5-6. 拡散の遮断（無効化、人間への切り替え、ロールバック）、影響を受けた対象の特定と通知・訂正、原因の修正と復旧（回帰評価で確認したうえで段階的に再開）、記録、非難のない振り返り、再発防止策の実行と確認の順です。

5-7. 第1のタイプは50件 × 4万ウォン × 顧客に提示された10% = 月20万ウォン、第2のタイプは1,200件 × 2,000ウォン = 月240万ウォンです。月間の被害額としては第2のタイプが優先されます。ただし、第1のタイプが法令・安全上の問題や重大な信頼の失墜につながる可能性がある場合は、遮断措置が十分であるかを別途確認します。

5-8. 良い答案は、リリースの範囲、リリース方式とその選定理由、フェーズごとの割合・期間・最小サンプル数、対照群、数値化された停止基準、ロールバックの方法（すでに処理された結果を含む）、運用指標とアラート、変更管理、インシデント連絡体制をすべて網羅します。停止基準に最小サンプル数が記載されていない場合や、対照群がリリース前後の比較になっている場合は、見直してください。