第4章 失敗への対応と人による監督

学習目標

• 捏造された回答（ハルシネーション）、拒否、形式エラー、一時的な障害を区別し、類型ごとに予防策と失敗時の対応を設計します。
• リトライ、キュー（待機列）、代替ルート、段階的縮小、機能停止の中から、障害の継続時間と機能の性質に応じた対応を選択します。
• エラーの可逆性（取り消し可能性）、処理量、危険なサブセットを基準に、人による介入ポイント（事前承認、条件付きエスカレーション、事後点検、異議申し立て）を定めます。
• レビュアーが実質的に判断できるよう、判断の根拠、修正・拒否の権限、記録を設計します。
• 利用者への告知、信頼のキャリブレーション（補正）、フィードバックと制御の仕組みを、法的義務とユーザー体験の観点から設計します。

はじめに

あるショッピングモールのAI相談ボットが、ある日「この商品はご購入後60日以内であれば無料で返品できます」と案内しました。実際の規定は14日でした。ボットはエラーを出さず、応答も速く、言葉遣いも丁寧でした。システムのすべての指標は正常でしたが、数百人もの顧客が誤った期限を信じて行動してしまいました。AI機能の失敗は、大抵このように静かに起こります。

従来のソフトウェアの失敗はエラー画面として現れます。しかし、AIの失敗はもっともらしい回答の陰に隠れます。そのため、AI機能の企画には2つの要素が必ず含まれていなければなりません。1つ目は、失敗を類型別に分類してそれぞれを低減し、失敗した際の動作を定めておくことです。2つ目は、人間がどこでどのように介入するかを決定することです。OpenAIは、可能であれば結果を実際に使用する前に人間がレビューすることを推奨しており、リスクが大きい領域ほどこれが重要であると強調しています。しかし、すべての箇所に人を配置することはできないため、どこに人を配置するかを選ぶことこそが企画なのです。

本章では、まず失敗の4つの類型とそれぞれの対応を確認し、障害が長引いた場合の代替ルートと段階的縮小を扱います。続いて、人による介入ポイントを選択する基準とレビュアーに与える権限を整理し、最後に利用者への告知とフィードバックの仕組みを設計します。

重要な概念

失敗は企画の一部である

AI機能の失敗は、大きく4つの類型に分けることができます。

Google PAIRガイドでは、エラーを「システムの限界」「コンテキストエラー」「バックグラウンドエラー」にも分類しています。特にバックグラウンドエラーは、システムが正しく動作していないにもかかわらず、ユーザーもシステムもエラーとして認識できないケースであり、捏造された回答がその代表例です。ユーザーが気づかない失敗はユーザーフィードバックでは検知できないため、設計と運用指標によって検知しなければなりません。一時的な障害については、対応を定める際にさらにその継続時間で分類します。数秒で解消される障害と復旧の見通しが立たない長期的な障害では対応がまったく異なるため、後述の対応表では4つの類型を5行に広げて記載しています。また、悪意のある入力によって指示を迂回するプロンプトインジェクションのようなセキュリティ上の失敗もあります。本講座では深く扱いませんが、外部からの入力を受け付ける機能であれば、セキュリティレビューの結果をこの対応表に併記します。

捏造された回答

捏造された回答（ハルシネーション）とは、モデルが事実と異なっていたり、与えられたコンテキストと一致しなかったりする内容をもっともらしく作り出してしまう現象です。Claudeのドキュメントでは、これを軽減するための基本戦略として次の3つを挙げています。

1. 「わからない」と言えるようにする。 不確実性を認めてもよいと明示的に許可することで、誤った情報を大幅に減らすことができる。
2. 直接引用で根拠を持たせる。 長いドキュメント（Claudeのドキュメントの例では2万トークン以上）を扱う際は、まず関連する文章をそのまま抽出させ、その引用に基づいて回答させる。
3. 引用によって検証する。 主張ごとに根拠となる引用を付与させ、根拠を見つけられなかった主張は撤回させる。

高度な手法としては、推論プロセスの点検、同一の質問を複数回実行して結果を比較する方法、結果を再検証させる反復、提供されたドキュメントの情報のみを使用するように制限する方法などがあります。同ドキュメントでは、これらの手法によって捏造された回答を大幅に減らすことはできるものの完全になくすことはできないと明言しており、重要な情報、特にリスクの大きい意思決定においては必ず検証を行うよう述べています。

機能の性質によって、捏造された回答への対処法は異なります。根拠となるドキュメントが存在する事実の案内では回答を引用に紐づけ、根拠がなければ確認できないと答えさせます。事実の主張を伴わないアイデア出しなどの作業では、幅広く生成させた上で人間が選ぶようにします。根拠ドキュメントを用いても検証できない物理的な判断のように、根拠がなくエラーが取り返しのつかない被害につながるようなタスクは、機能自体を開発しないか、専門家への引き継ぎに変更します。

拒否と過剰な拒否

モデルが回答しないことは、時に正しい動作となります。根拠がない要求や危険な要求に対して「確認できません」と答えることは、捏造された回答を返すよりも望ましい正常な動作です。問題となる失敗は2つあります。回答できる質問まで拒否してしまう「過剰な拒否」、そして正常な拒否であっても次のアクションを案内せずに会話を打ち切ってしまう「案内のない拒否」です。過剰な拒否は、誤った回答の割合（エラー率）にはカウントされず、正答率においても拒否を個別に集計しなければその原因が表面化しません。そのため、回答可能な質問に対する拒否率を別途測定します。過剰な拒否はユーザーのフローを妨げ、処理コストをオペレーターや電話窓口に押し付けることになります。

過剰な拒否には2つのアプローチで対処します。まずはそれを減らすことです。回答できたはずなのに拒否してしまった事例を収集して評価セットに加え、プロンプトや根拠の範囲を修正して再評価します。そして、拒否する場合であってもユーザーが次のアクションを取れるようにします。PAIRガイドでは、失敗した後にユーザーができることに焦点を当て、失敗時にはユーザーがタスクを引き継げるようにすることを推奨しています。「回答できません」の代わりに、「このご質問は規定のドキュメントで見つけることができませんでした。関連メニュー：○○、担当者へのおつなぎ：○○」のように記述します。根拠が見当たらず回答できなかった場合と、安全性ポリシーに従って回答しなかった場合とでは、案内を分けます。前者は別のルートを開き、後者は理由を簡潔に伝えた上で同じ要求を再び促さないようにします。

形式エラー

形式エラーは、約束された出力形式を守らない失敗です。人間が読む画面であれば画面が空白になったり崩れたりし、他のシステムに送られる結果であれば連携に失敗します。連携の失敗は、誰も気づかないうちに蓄積されやすいため、より危険です。

Claudeのドキュメントでは、構造化出力を使用すればJSONスキーマに準拠した応答が保証されると説明する一方で、安全上の理由から拒否された応答（stop_reasonがrefusal）や、max_tokensに達して途切れた応答はスキーマに合致しない可能性があると述べています。そのため、対応は3重の構えとなります。

1. 構造化出力や厳格なツール入力（strict tool use、ツール名と入力値がスキーマに従うようにする設定）によって形式を固定する。文字列の列挙型（enum）の値の大文字・小文字は保証されないため、大文字・小文字を区別せずに比較する。
2. 受け取った結果をスキーマで検証し、失敗した場合は後続システムに渡さない。
3. 検証失敗案件は再処理キューやデフォルト画面へ送り、その割合を運用指標として監視する。

一時的な障害とリトライ

モデルのAPIでも障害は発生します。Claudeのドキュメントでは、エラーコードとして429（rate_limit_error、レート制限）、500（api_error、内部エラー）、529（overloaded_error、一時的な過負荷）などを説明しています。内部エラーに対しては指数バックオフによるリトライを推奨しており、Anthropic公式SDKは接続エラー、レート制限、5xxなどの一時的な失敗に対して、デフォルトで最大2回まで指数バックオフにより自動的にリトライし、retry-afterヘッダーが存在する場合はそれに従うと明記しています。指数バックオフとは、リトライを行うたびに待機する間隔を1秒、2秒、4秒のように増やしていく方式のことです。

リトライは短時間の障害に適した対応です。数秒で解消される過負荷であれば、間隔を空けて数回リトライすることで大半は解決しますし、規定の回数を超えた場合はユーザーに通知して別の手段を提示します。回数を制限しなければ、ユーザーは際限なく待たされることになり、障害発生中のサーバーにリクエストが集中して事態が悪化します。同ドキュメントでは、使用量が急激に増加すると加速制限（acceleration limits、急増する使用量に対する制限）によって429エラーが発生することがあるため、トラフィックを段階的に増やすことも推奨しています。

代替ルートと段階적縮小

障害が長期化したり復旧の見通しが立たなかったりする場合、リトライだけでは不十分です。機能の性質に応じて対応は異なります。

段階的縮小（graceful degradation）は、AI機能が停止しても中核業務がよりシンプルなルートで継続できるようにする設計です。AI推薦検索が停止した場合はキーワード検索に、AI相談が停止した場合はよくある質問（FAQ）やオペレーターへの接続に切り替えます。NIST AI RMFでは、意図された用途から外れた性能や結果を示すAIシステムを代替、解除、または停止するメカニズムを設け、その責任を定めるよう求めています（MANAGE 2.4）。この仕組みは、リリース前に構築してテストしておく必要があります。

失敗類型別の対応表

失敗への対応は1枚の表に整理します。各セルが空欄のままであれば、その失敗が発生した際に何が起きるか誰も把握できない状態を意味します。

人による介入ポイント

人間が介入する方式は、4つに分けることができます。

選択の基準は3つあります。エラーを取り消す（元に戻す）ことができるか、処理量がレビュー能力の範囲内に収まっているか、リスクが特定の部分集合（販売制限商品、高額取引、安全関連など）に集中しているか、です。Anthropicは、エージェントがチェックポイントや行き詰まったポイントにおいて、人間からのフィードバックを得るために一時停止できると説明しています。企画者が行うべきことは、そのポイントをあらかじめ定めておくことです。

人間にエスカレーションされた案件を待つユーザーの体験も設計します。レビューにかかる目標時間を定め、その間ユーザーに進捗状況を表示し、目標時間を超過した案件をどのように処理するか（担当者の追加割り当て、安全なデフォルト処理など）を決めておきます。レビュー待ちのキューが溢れた際の処理ルールがなければ、人による介入がそのままサービスの遅延につながってしまいます。

複数の方式を組み合わせるのが一般的です。例えば1日に数万件の分類を行う場合、リスク条件に該当する案件は条件付きエスカレーションとし、残りは自動反映と事後サンプリング点検を行い、結果に不満がある出品者（販売者）に対しては異議申し立てのルートを用意します。

レビュアーの権限と根拠

人間がレビューのプロセスに入っているからといって、監督が機能しているとは限りません。レビュー画面にAIの推薦と「確認」ボタンしかない場合、レビュアーはその推薦を変更することも、なぜそのような推薦が出されたのかを確認することもできません。形式上は人間の判断であっても、実質的には自動化にすぎません。

レビューが実質的に機能するためには、3つの要素が必要です。

1. 判断の根拠。 AIがその結果を出力した主な根拠（引用したドキュメント、反映した項目）をレビュアーが確認できること。
2. 権限。 レビュアーが結果を修正または拒否でき、その判断が実際に反映されること。
3. 記録。 修正・拒否の理由が記録として残り、将来の点検や改善のための資料となること。

NIST AI RMFでは、人による監督プロセスを組織のポリシーに従って定義、評価し、記録するよう求めています（MAP 3.5）。AI基本法（韓国）（「人工知能発展および信頼基盤造成等に関する基本法」）でも、高影響AI、すなわち採用・融資審査など法律が定めた領域において生命・安全・基本権に重大な影響を与えうるAI（第1章参照）や、それを利用した製品・サービスを提供するAI事業者（開発事業者および利用事業者）が講ずべき措置として、人による管理・監督、説明手段、および措置内容を確認できる文書の作成・保管を定めています（第34条第1項）。高影響AIに該当しない一般的な相談ボットであっても、実質的なレビューの設計は品質と信頼性を維持するための基本となります。

信頼のキャリブレーションと確信度の表示

ユーザーがAIの結果を無条件に信じても、無条件に疑っても問題となります。Google PAIRガイドでは、ユーザーが信頼を適切にキャリブレーション（補正）し、ある状況では信頼し、必要なときには再確認できるようにすることが目標であると説明しています。

確信度のレベルを提示することは役立つ場合もありますが、その方法が重要です。同ガイドでは、数値による確信度の提示はユーザーが確率を十分に理解していることを前提としているため危険であると警告しており、代わりに複数の候補を提示したり、確信度のレベルをいくつかの段階に分けて段階ごとにユーザーが取るべき行動を明確にしたりすることを推奨しています。確信度の表示がユーザーの意思決定に影響を与えないのであれば、あえて表示しないことも一つの選択肢です。

利用者への告知

AI基本法（韓国）第31条では、次の3点を求めています。高影響または生成AIを利用した製品・サービスを提供しようとする場合、その製品・サービスが当該AIに基づいて運用されているという事実を利用者に事前に告知しなければならず（第1項）、生成AIまたはそれを利用した製品・サービスを提供する場合は、生成物が生成AIによって生成されたという事実を表示しなければならず（第2項）、実際と区別がつきにくい仮想の音声・画像・動画を提供する場合は、利用者が明確に認識できる方式で告知または表示しなければなりません（第3項）。具体的な方法および例外規定は大統領令に委任されています（第4項）。

企画者にとって重要な点は、事前の告知と生成物の表示が原則として別個の義務であるということです。事前の告知を行ったからといって、生成物の表示義務が免除されるわけではありません。具体的な方法や例外は施行令第23条で定められています。事前の告知は利用規約への記載、画面表示、提供場所への掲示などによって行うことができ、生成物の表示は人間が認識できる方法、または機械可読な方法で行うことができます。機械可読方式の場合、生成AIによって作成された事実を1回以上テキストや音声で案内する必要があります。サービス名や画面上の文言によってAIの活用が明白である場合や、社内業務用途でのみ使用する場合などには、規定の全部または一部を適用しないことができます。法的な義務とは別に、PAIRガイドでは、初回利用時に製品ができることとできないことを率直に伝え、技術そのものよりもユーザーが得られるメリットを説明することを推奨しています。ユーザーが機能の適用範囲を誤解することによって生じる不満（リアルタイムの情報を参照していると思い込むなど）は、出力結果を修正することではなく、ユーザーの期待値を適切に調整することで解決します。

フィードバックと制御

ユーザーからのフィードバックには2つの種類があります。PAIRガイドの定義では、暗黙的フィードバックとは製品ログに残るユーザーの行動データ（修正、再生成、離脱など）であり、明示的フィードバックとはユーザーが意図的に残す意見（高評価・低評価、報告など）です。結果の一部だけが頻繁に間違えるようであれば、ユーザーがその場で結果を直接修正できるようにし、修正内容を記録することがユーザーの負担軽減と改善用データの確保という両方の課題を解決します。ただし、ユーザーによる修正が常に正しいとは限らないため、修正ログはレビューを経た上で評価セットや改善資料として活用します。

コントロール（制御）の仕組みも不可欠です。PAIRガイドでは、ユーザーが出力を自身のニーズに合わせて修正したりオフにしたりできるようにし、AIを初めて導入する際には試用できるようにしたり無効化できるようにしたりして、使用しないという決定を尊重することを推奨しています。OpenAIは、ユーザーが不適切な動作を簡単に報告できる手段を設け、その報告を人間がモニタリングして適切に対応することを求めています。NIST AI RMFでも、エンドユーザーや影響を受けるコミュニティが問題を報告し、結果に対して異議を申し立てることができるフィードバックプロセスを設けるよう推奨しています（MEASURE 3.3）。

さらに深く

形式的承認の罠

人間がすべての結果を承認する構造は安全に見えますが、処理量が大きくAIがほとんど正しい場合、レビュー担当者は次第に確認することなく承認するようになります。1日に数百件を数秒ずつ見て99%以上をそのまま承認しているなら、そのレビューは監督ではなく単なる署名です。

この罠は数字に現れます。レビュー担当者の修正率（そのまま承認しなかった割合）、1件あたりのレビュー時間、レビュー担当者が修正した案件が実際に間違っていた案件だったかどうかを定期的に確認します。人間がAIの推薦を吟味せずに受け入れる傾向を自動化バイアスと呼びます。修正率がほぼ0でレビュー時間が短いなら、2つのうちのいずれかです。AIが極めて正確で事前承認が過剰であるか、レビュー担当者に判断するための根拠と権限がなく確認を諦めてしまったかです。前者の場合は条件付き移管によって減らし、後者の場合はレビュー画面を改善します。一部の結果にあえて既知のエラーを混入させ、レビュー担当者が検知できるか確認する方法もあります。

他のモデルへの自動切り替えの罠

障害対応として「他社のモデルへの自動切り替え」がよく提案されます。可用性だけを見ればもっともらしく思えますが、企画者が確認すべき点が3つあります。第1に、そのモデルで評価セットを実行し、品質基準を満たしているか確認したか。同じプロンプトであってもモデルが変われば結果は異なります。第2に、その提供元へ顧客データを送信してもよい契約および処理条件があるか。第3に、レイテンシとコストが契約条件の範囲内であるか。

3つのうち1つでも確認されていなければ、自動切り替えは障害を品質事故や契約違反へとすり替えるだけにすぎません。そのような場合には、段階的縮小やキューの利用がより安全な解決策です。予備モデルを用意するのであれば、平時から並行して評価を行い、契約を結んでおくことが前提です。

免責文言は対応ではない

「AIの回答には誤りが含まれる可能性があります」という文言はよく見られますが、それ自体は失敗への対応ではありません。ユーザーはその文言を読んでも回答を信じて行動しますし、文言はでっち上げの回答を1つも減らしません。法律が要求する告知（AIベースであるという事実、生成結果である旨の表示）と失敗への対応（根拠の引用、人間の介入、代替経路）は、異なる次元の話です。

告知はユーザーの期待値を調整することであり、失敗への対応は失敗による被害を軽減することです。企画書において「免責文言の追加」が失敗対応の欄に入っているなら、その欄はまだ空欄のままなのです。

実務の場面

ひかりレンズの度数案内ボット

メガネのオンラインショップ「ひかりレンズ」は、顧客の問い合わせに回答するAIボットを運営しています。試験運用の記録を見ると、失敗が3種類発生していました。レンズ交換規定にない「無償交換3回」を案内したでっち上げの回答、「度数の入力はどうすればいいですか」といった簡単な質問を拒否した過剰拒否、そして注文照会の結果がアプリ画面に空白で表示されるフォーマットエラーでした。

企画者は類型別に対応を分けました。でっち上げの回答に対しては交換規定ドキュメントの文章を引用して回答させ、引用が見つからない場合は「規定では確認できません」という案内とオペレーターへの接続を表示させるようにしました。過剰拒否については拒否された質問120件を評価セットに組み込んでプロンプトを修正した後、修正時には見なかった保留質問で拒否率を再測定し、拒否する際には度数入力画面へのショートカットを同時に表示するようにしました。フォーマットエラーについては注文照会の結果をスキーマで固定し、検証に失敗した場合はデフォルトの注文画面に遷移させるようにしました。

もう1つ課題がありました。顧客が処方箋の写真をアップロードすると、AIが度数を読み取って注文に入力する機能が提案されました。度数を読み間違えると度数の合わないレンズが製作されてしまい、一度製作されたレンズは取り消す（元に戻す）ことができません。処理量は1日60件でした。企画者は、AIが読み取った度数を顧客が処方箋と並べて確認できるようにし、眼鏡士が製作前にすべての案件を承認する事前承認方式を選択しました。不採用とした案は「確信度が高い案件は自動製作」でした。1日60件であれば眼鏡士がすべて目を通すことができ、たとえ確信度が高くても間違ったレンズは元に戻せないためです。

たまあつめ工房の商品検品

ハンドメイドマーケット「たまあつめ工房」は、1日に8,000件の新規商品登録をAIで検品し、禁止品目（模造品、危険物）をフィルタリングしようとしています。検品人員は1日に250件を確認できます。

最初の提案は「AIが疑わしいと判断した案件をすべて人間がレビューする」というものでした。テストしてみたところ、AIが疑わしいと判断した案件は1日900件でした。企画者はリスクを分類しました。危険物の疑いは稀であるものの被害が大きいため、すべて人間に送ります。模造品の疑いについては確信度が高い案件は登録を自動で保留し、確信度が低い案件のみを人間に送ります。疑いのない商品は自動通過させた後、毎日サンプル50件を点検します。このようにしたことで、人間へと送られる案件は危険物の疑い30件、確信度の低い模造品の疑い140件、事後点検のサンプル50件を合わせて1日220件へと減少し、レビュー能力の250件の範囲内に収まりました。登録が自動保留された出品者には、理由を確認して再審査を申請できる異議申し立ての経路を用意しました。

レビュー画面も改善しました。初期の画面には「禁止の疑い」という表示と承認ボタンしかありませんでした。レビュー担当者はなぜ疑われたのかがわからず、大部分をそのまま承認してしまい、初週の修正率は2%でした。企画者はAIが根拠とした商品名・画像領域・説明文を合わせて表示し、レビュー担当者が判定を変更する際には理由を選択させるようにしました。レビュー担当者が根拠を確認して誤った判定を実際に修正し始めたことで、2週目の修正率は11%へと上昇し、その理由の記録は次の評価セットの素材となりました。

間違えやすいポイント

1. 「『わからないと答えよ』という指示を入れれば、でっち上げの回答はなくなる。」 大幅に減るだけで消えることはありません。重要な情報には検証の仕組みが必要です。
2. 「複数回生成して回答が一致していれば事実である。」 モデルは同じ誤解を繰り返すことがあります。一貫性は根拠ではありません。
3. 「拒否は安全であるため失敗ではない。」 過剰拒否はユーザーを妨げ、コストを別の窓口へ転嫁してしまう失敗です。
4. 「構造化出力を使えばフォーマット検証は不要である。」 拒否や長さの制限によってスキーマが崩れることがあります。
5. 「障害が発生したら別のモデルへ自動で切り替えればよい。」 評価を行っていなかったりデータ条件が整っていないモデルへの切り替えは、品質事故や契約上の事故につながります。
6. 「すべての結果を人間が承認すれば最も安全である。」 処理量がレビュー能力を超えると形式的な承認に陥り、取り消しが容易なエラーに対しては過剰なコストとなります。
7. 「レビュー担当者がいれば監督は機能する。」 根拠や修正・拒否の権限、記録がなければ、監督は署名にとどまります。
8. 「免責文言を記載すれば失敗への対応になる。」 告知は期待値を調整する行為であり、失敗による被害を軽減することは設計の役割です。

ひと目でわかるまとめ

• 失敗の4つの類型：でっち上げの回答（ユーザーが気づかない）、拒否・過剰拒否（行き詰まり）、フォーマットエラー（破損）、一時的な障害（待機）。
• でっち上げの回答：「わからない」の許容、直接引用、引用の検証。減らすことはできても、なくすことはできない。
• フォーマットエラー：構造化出力＋検証＋失敗案件の再処理。拒否や長さの制限は例外。
• 障害：短時間であれば回数制限付きバックオフ再試行、リアルタイム性が不要であればキュー、長時間であれば段階的縮小、予備モデルは事前の評価・契約が前提。
• 人間の介入：可逆性・処理量・リスクのサブセットに応じて、事前承認／条件付き移管／事後点検／異議申し立てを選択する。
• レビューを機能させるには根拠・権限・記録が必要。修正率とレビュー時間で形式的承認を監視する。
• 確信度の表示は段階と行動案内で行い、数値による確信度には注意する。
• AI基本法 第31条：事前告知と成果物の表示は別個の義務。通報窓口は人間が確認して回答する。

公式ドキュメントで確認する

• Claude Docs — Reduce hallucinations：基本・高度な手法と「完全にはなくせない」という注意点。
• Claude Docs — Structured outputs：スキーマ保証と、拒否・max_tokensの例外。
• Claude Docs — Claude API errors：エラーコード、指数バックオフ、SDKの自動再試行。
• OpenAI — Safety best practices：人間によるレビュー、レッドチーム、通報窓口と人間によるモニタリング。
• Google PAIR Guidebook — Errors + Graceful Failure：エラー類型、失敗後の次の行動、コントロール権の返還。
• Google PAIR Guidebook — Explainability + Trust：信頼のキャリブレーションと確信度の表示方法。
• Google PAIR Guidebook — Feedback + Control：暗黙的・明示的フィードバック、修正とオフ機能。
• NIST AI RMF — Core：MAP 3.5（人間の監督）、MEASURE 3.3（通報と異議申し立て）、MANAGE 2.4（代替・解除・停止）。
• 国家法令情報センター — AI基本法施行令 第23条：事前告知と成果物表示の方法、適用の例外。

セルフチェック

4-1. Claudeのドキュメントがでっち上げの回答を減らす基本戦略として挙げている3つを記述してください。

4-2. 過剰拒否が誤答の割合（エラー率）には表れない理由と、過剰拒否に対処する2つの方向性を記述してください。

4-3. 構造化出力を用いる機能において、レスポンスがエラーなく正常終了した場合でも検証ステップを残しておくべき理由を記述してください。

4-4. 公文書の自動送信機能において、モデルAPIが30分間にわたり応答していません。送信は明日の午前中までに行えばよい状況です。再試行、キュー、段階的縮小のうちどれが適切であるかと、その理由を記述してください。

4-5. 人間の介入方式を4つ挙げ、それぞれが適している条件を1行で記述してください。

4-6. レビュー担当者が1日に500件を平均3秒ずつ確認し、99.8%をそのまま承認しています。この数値が意味し得る2つの状況と、それぞれの対応策を記述してください。

4-7. AI基本法 第31条第1項と第2項がそれぞれ要求している内容を記述し、両者の関係を説明してください。

4-8. （設計）現在担当しているAI機能における失敗類型別の対応表（予防、検知、失敗時の動作、ユーザーに見えるもの）を5行で記述してください。

実習課題