- 公開日
AIに任せる作業の確認は、分野名や文章の長さだけで決めず、誤った場合に誰へ何が起きるか、どんな情報を扱うか、後から戻せるかに合わせて変えます。厳しくする際は、追加で照合する対象と解除の条件を一緒に決めておきます。問題が解消した後まで同じ確認を増やし続けず、戻す根拠を確かめるところまでがリスクベース設計です。
作業名より、失敗した先を見る
リスクベース設計とは、想定される不利益や発生の条件に応じて、確認や制限の配分を変える考え方です。NISTのAI RMF Coreは、利用される状況や影響を把握し、影響、起こりやすさ、利用できる資源などから対応を優先することを示しています。以下の見方は日常業務への整理例であり、公式の採点方式ではありません。
最初に見るのは、誤りの影響です。個人が検討するメモの誤字と、顧客へ伝える料金条件の誤りでは、修正の範囲が違います。同じ社内文書でも、部署内の下書きなのか、全社員が行動の根拠にする確定案内なのかで、確認すべき箇所が変わります。社内向けという属性だけでは軽く扱えません。
次に情報の機密性を見ます。外へ出せない情報、個人に関わる情報、取引先から利用条件を指定された情報が含まれていないかを確かめます。出力の影響が小さくても、入力時点で許されない相手へ情報を送れば別の問題が起こります。文章が短いことや、学習に使われないという設定だけでは、入力の許可までは決まりません。
もう一つは取り消しやすさです。手元の下書きは直せますが、送信済みの文章を相手が読んだ事実は、訂正メールを送っても戻りません。元の文書を復元できても、変更内容をもとに別の人が動けば、影響が残ります。データを戻せることと、起きた不利益を戻せることを分けて考えます。
これらに加え、判断に必要な情報が揃っているかを見ます。影響が分からないから低リスクなのではありません。公開先、対象者、契約条件などが不明で、それによって判断が変わるなら、該当部分を確かめるまで扱いを決め切らないようにします。
確認を増やすときは、増やす中身を指定する
確認の厳しさを変えるとは、単に「慎重に」と書き足すことではありません。どの資料と照合するか、誰が意味の変更を判断するか、どの操作を保留するかを選びます。誤字の修正なら変更箇所の確認で済む場面がありますが、金額や条件が変わるなら、元の条件と差分の照合が必要です。
常に残す前提もあります。入力してよい情報を使うこと、依頼されていない操作をしないこと、資料にない事実を加えないことです。確認が軽い作業でも、こうした前提まで消すわけではありません。その上に、必要に応じて専門的なレビューや操作前の承認を足します。
人がレビューする場合も、同じ回答をもう一度眺めるだけでは、何を点検したかが曖昧になります。元の文、変更案、変更理由、分からない点を並べて渡すと、確認すべき意味の差を追いやすくなります。確認者には、その条件を判断できる知識と権限が必要です。
同じ文章校正でも、変えてよい箇所が違う
架空の総務担当者が、二種類の文章を校正するとします。どちらも、入力が認められた環境で文案を作り、担当者が確認するまで送信しません。AIの役割は表現の修正案を出すことに固定します。ここで示す文案と出力は説明用で、実在の契約の解釈や検証済みの結果ではありません。
一つ目は、部署内の説明会の案内です。原文は「説明会は10月20日、会議室Aにて開催します。参加の返信は10月15日までにお願いします」です。開催年や時間は今回の提示資料にないものとします。読みやすさを整えても、日付と場所は変えず、年や時刻を勝手に補いません。
依頼は「表現を整え、日付と場所は原文どおりに残してください。原文にない開催年や時刻は追加せず、必要な確認事項として分けてください。変更箇所も示してください」とできます。期待するのは、語調の調整と、確認が必要な情報の表示です。配布前には担当者が確定した開催案内と照合します。
二つ目は、契約文案の一部です。原文に「受領後10営業日以内に通知する」とあるのに、修正案が「受領後10日以内に知らせる」となったとします。少なくとも「営業日」が「日」に変わっており、単なる言い回しの変更とは扱えません。どの期間が正しいかは、この一文だけでは決められません。
この場合、AIには「義務、期限、条件を変えない範囲で修正案を出し、意味が変わり得る箇所は確定せず差分と確認点を示す」と頼みます。出力例は「10営業日から10日への変更は、期間の意味に関わるため採用を保留。原文の表記を維持し、契約担当へ確認」です。短くなった文章を、そのまま正式文書へ反映しません。
確認担当者には該当文だけでなく、用語の定義や関連する条項も渡します。ここで追加するのは「契約だから確認を何回増やす」という手続きではなく、変更した語が当事者の条件へどう影響するかという照合です。AIが「意味は同じです」と答えても、その自己評価を人の判断の代わりにはしません。
反対に、契約文書でも、確定済みの内容を変えない見出しの表示調整なら、組織の規程に従って確認範囲を限定できる場合があります。案内文でも、避難先や申込期限など、誤ると行動に影響する箇所なら厳しく確認します。分野名ではなく、今回どこを変えるかを見ます。
途中で条件が変わったら、その位置で切り替える
開始時に一度分類すれば終わりではありません。校正だけだった依頼が「そのまま取引先へ送って」に変われば、受信者、送る内容、承認の有無を改めて扱います。新たに添付された資料に機密情報が含まれるなら、同じ会話の続きでも入力や共有の条件を確認し直します。一件ずつ確認していた処理を一括処理へ広げる場合も、同じ誤りが多くの相手へ及ぶため、対象範囲と止め方を確かめ、限られた範囲で試してから広げます。
外部操作へ接続する場合、モデルの判断だけで権限を増やさない設計も必要です。OWASPのExcessive Agency対策は、必要な機能と権限に限定し、重大な操作に人の承認を置き、下流側で認可を強制する考え方を示しています。下書き用途では送信機能を与えない、送信時に確定内容と宛先を検査するといった分担ができます。
これは、確認の回数を増やすこととは別の制御です。文章を何度読み直しても、送信の段階で宛先を検査する仕組みがなければ、誤った宛先への送信は止まりません。どこを人が判断し、どこを仕組みで止めるかを、依頼の変化に合わせて見直します。
厳しくした確認を、何を根拠に戻すか
一時的に確認を増やしたときは、「何が解消すれば戻せるか」を記録します。先ほどの校正なら、対象版の原文が揃い、期間に関わる変更を除き、今回の依頼が承認済み文章の表記修正に限られると責任者が確認できれば、その範囲では通常の校正確認へ戻す候補になります。
一方、「最近間違えなかった」「急いでいる」「モデルが自信ありと答えた」は、入力許可や意味の差が解消した証拠ではありません。厳格な確認を必要にした条件そのものが残っていれば、成績がよかったという理由だけでは解除しません。適用される法令、契約、組織の承認要件も、便宜だけで省けません。
実務の記録には、対象作業、厳しくした理由、追加した照合、解除に必要な根拠、判断者を残します。解除時は対象版と作業範囲も記し、別の文書や送信先へ自動的に広げないようにします。重要な不明点が解消できなければ、確認済みの部分だけを続け、依存する修正や操作は保留します。
確認の負担を減らすときも、変更後の案と原文を照らし、日時、金額、条件など残すべき情報が保たれたかを確かめます。判断の根拠が変われば再び水準を上げます。一律に厳しい確認を続けると確認待ちが増え、重要な案件へ時間を割きにくくなります。逆に、件数を減らすためだけに確認を省けば、残すべき条件まで失われます。軽くするか厳しくするかを一度で固定するより、条件が変わる場所と戻す根拠を決めておく方が、日々の作業へ組み込みやすくなります。
危害の可能性がある依頼で、拒否・部分処理・人間確認のどれを選ぶかはLLMのガードレールとは？ 効かない原因と対策、拒否・縮小・人間確認の使い分けで、安全性・正確性・速度の優先の付け方はAI業務の安全性・正確性・速度の使い分け――確認を省ける作業と省けない作業で扱っています。用途ごとの判断を一覧に残す方法はAIの用途別リスク分類は、業務への影響から統制を選ぶ、送信を任せる場合の役割分担はAIの送信をどう制御する？ 指示・システムの強制・人間承認の役割で整理しています。
基本から確認する：この記事の前提になる考え方は、「AIを使う前の安全確認チェックリスト（AIKYで確かめる12項目）」にまとめています。
