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

第1章

1-1. パラメータ化クエリは、クエリの構造と値を別々の経路で送るため、パーサーが構造を固定します。LLMでは、システムプロンプト、ユーザーの依頼、文書、ツール結果が1つのコンテキストに入り、ロールの表示があっても、何を指示として従うかを決めるのはパーサーの文法ではなくモデルの確率的な判断であるため、構造的な分離が成立しません。

1-2. コンテキストを組み立てる場所（誰が書いたテキストが混ざるか）、ツールを実行する場所（誰の権限で、何を検査して実行するか）、出力を解釈する場所（出力がコードや命令として解釈される可能性があるか）、記憶を書き込む場所（保存した内容を後で誰が読むか）です。

1-3. 残るリスクの内容と、そのリスクの責任者です。移転はリスク自体を小さくせず、受容はリスクを抱えたまま進むという決定です。そのため、記録がなければ、誰も責任を負わないリスクになってしまいます。見直しの条件もあわせて記載しておけば、状況が変わったときに決定を再検討できます。

1-4. たとえば、エージェントのすべてのツール呼び出しが共用サービスアカウントから行われ、依頼したユーザーの識別子がログに残らない設計です。事故が起きても、誰の依頼がその行動を引き起こしたかを証明できず、影響範囲と責任を確定できません。トークンをそのまま転送し、下位システムのログに中継サーバーしか残らない構成にも、同じ欠陥があります。

1-5. 出発点にはASI06（Memory & Context Poisoning）、波及にはASI08（Cascading Failures）を付けます。ASI08は初期の欠陥ではなく、その欠陥がエージェント・ツール・ワークフローに沿って広がる現象を指します。そのため、直接の侵害はそれに合った番号で別に分類します。出発点を修正せず、波及だけを止めると、同じ事故が再び始まります。

1-6. MITRE ATLASです。攻撃の戦術と手法がケーススタディと結び付いており、段階ごとのシナリオを作るのに適しています。NIST AI RMFは、組織がAIリスクをどのように管理するか（責任、文脈、測定、対応）に答えます。SAIFは、どのようなセキュリティ統制を、どのように備えるか（中核要素とリスクごとの統制）に答えます。

1-7. 新しい信頼境界は、モデルの要約がチャネルへの投稿という行動になり、その投稿が他の社員の画面にレンダリングされる場所です。見直しの条件の例としては、「投稿先に外部共有チャネルを追加する」「要約対象に外部文書の出所を追加する」「投稿前の確認段階を取り除く」「投稿ツールに修正・削除機能を追加する」があります。

第2章

2-1. 白い文字、コメント、メタデータのように画面上では見えない内容も、モデルにとっては入力です。そのため、人が見る画面ではなく、モデルが実際に受け取るテキスト（抽出結果）を基準に、レビューとスクリーニングを行う必要があります。

2-2. 直接・間接インジェクションは指示が入ってきた経路による区分であり、ジェイルブレイクはモデルの安全ポリシーを回避するという目的による区分です。たとえば、共有文書に隠された指示が、モデルに安全ポリシーで禁止されたコンテンツを作らせた場合、間接インジェクションであると同時にジェイルブレイクでもあります。ユーザー入力だけを見るジェイルブレイク用のフィルターは、このような事例を見落とします。

2-3. 逸脱の段階は、ユーザーの依頼に基づいて先に計画を確定し、その後で外部コンテンツを読ませる設計（計画の固定）、または計画する側は原文を見ず、読む側から所定の形式のデータだけを渡す設計（原文を参照しないプランナー）によって断ち切ります。予期しない目標の変化が見られたら実行を停止する、意図の検証もこれに当たります。伝達の段階は、外部コンテンツを読むフローでは書き込みツールを呼び出せないように分離する、影響の大きい行動に人の確認を設ける、受信者とドメインを許可リストに限定する、といった方法で断ち切ります。

2-4. 引用符やタグを閉じてデータ領域を抜け出し、指示の文脈へ移る試みが難しくなります。それでも、モデルが文字列の値に含まれる指示に従う可能性は残ります。エンコードは境界を明確にするだけで、モデルの判断を強制するものではないため、権限の分離と確認を組み合わせる必要があります。

2-5. 第1に、実際のサービス経路（アップロードとテキスト抽出）を通した韓国語の攻撃事例、および正常事例・境界事例を使い、検知率と誤遮断率を別々に測ります。第2に、判定が得られない場合やエラーの場合の動作と、検知されたときに遮断・表示・人のレビューのどれを行うかを決めます。Prompt Shieldsの文書も、主に英語で学習・評価されているため、言語ごとに評価するよう案内しています。

2-6. 回答の汚染では、機密情報が外に出ることなく、正常な形式の回答の中で推薦がゆがめられたり、条件が抜け落ちたりします。そのため、持ち出しを監視する検知ルールには引っかかりません。根拠文書と引用を付けて原文と照合する検証、必須項目が抜けていないかを見る決定的な検査、重要な決定に対する人のレビューが、この被害を減らします。

2-7. 第1の原因は、承認の依頼が多すぎて、内容を読まなくなることです。リスクに応じて確認の対象を絞ることで対応します。第2の原因は、画面が実際の引数ではなくモデルの要約を表示し、人がその説明を信じてしまうことです。対象・引数・効果を元の値で表示し、承認と実行時の引数を結び付け、値が変われば再度確認することで対応します。承認率と承認までにかかった時間を監視すると、形式的な承認に気付くことができます。

2-8. 解答例です（投稿前に人が確認する手順を4行目として加えてもかまいません）。

確率を下げる層：レビュー本文には「外部公開ページ、作成者未確認」という出所を付け、ツール結果としてのみ渡し、スクリーニングモデルで指示の挿入を表示する。
権限の分離：レビューを読む段階では投稿ツールを呼び出せないようにし、整理した結果は所定の表形式でのみ受け取り、決定的なコードが投稿する。
出力の制限：投稿前に外部リンク・画像・マークアップを除去し、投稿先を指定されたWikiスペースに固定する。

第3章

3-1. たとえば、コンテキストの組み立て（必要以上のフィールドが入るため、フィールド単位で照会するツールで減らす）、外部モデルの呼び出し（原文が外部に送られるため、マスキング・仮名化を行い、契約条件を確認する）、ログとキャッシュ（原文が残るため、マスキングと保存期間を定める）です。ツールの引数（引数の検証と宛先の制限）や、要約・埋め込み・ファインチューニング用データといった派生データ（学習前の精製と削除手順）を挙げてもかまいません。

3-2. 拡張機能と下位システムの活動のロギング・モニタリング、およびレート制限です。どちらも、誤った行動を後から発見したり、その回数を減らしたりするだけです。モデルが有害な行動を取れるようにする機能・権限・自律性を減らすものではないため、予防策ではありません。

3-3. 下位システムに向かうすべてのリクエストについて、モデルの判断ではなく、下位システムがセキュリティポリシーに従って毎回認可を検査するという原則です。たとえば、「管理者だけが返金を承認できる」とシステムプロンプトにだけ記載し、返金APIでは呼び出し元の権限を検査しない設計は、この原則に反します。

3-4. 入力と出力がモデルの学習に使われるかどうかと、それを拒否する方法、不正利用監視ログの保管期間、アプリケーションの状態（会話、ファイル、ベクトルストア）の保管期間と削除方法、保管を減らすオプションの承認条件、保存・処理される地域です。条件は機能や契約ごとに異なるため、確認した日付とともに記録します。

3-5. 基本は、textContentのようにテキストとしてのみ扱う方法で描画します。書式がどうしても必要な場合は、生のHTMLを無効にしたMarkdownレンダラーと、許可リストに基づくサニタイザー（OWASPはDOMPurifyを推奨）を通します。CSPは、この2つを代替するものではなく、追加の防御層です。

3-6. 状態ハンドルを持っているという事実を、認証として扱うことを禁止しています。サーバーはすべてのリクエストを検証し、ハンドルを安全な乱数で作る必要があります。また、検証済みトークンから得たユーザーIDとハンドルをサーバー側で結び付け、別の主体が提示したハンドルは拒否する必要があります。ハンドルに有効期限を設けると、リスクはさらに小さくなります。

3-7. 解答例です。find_free_rooms(시작, 끝, 인원)は会議室の一覧照会だけを行う読み取り専用ツールであり、確認は不要です。read_my_calendar(기간)は、依頼した社員本人の予定だけを、ユーザーのコンテキストに属するトークンで読み取り、確認は不要です。book_room(회의실, 시작, 끝)は予約の作成だけを行い、修正・削除の機能は持ちません。ユーザーのコンテキストで実行され、サーバーが重複と権限を検査し、作成前にユーザーの確認を受けます。汎用的なカレンダーの書き込み権限は含めません。

第4章

4-1. ハンドオフ、ホスト型ツール（Web検索、ファイル検索、ホスト型MCP、コードインタープリターなど）、組み込み実行ツール（コンピューター、シェルなど）のうち、2つを挙げればよいです。代わりに設ける統制には、遮断モードの入力ガードレール、実行環境の隔離とドメインの許可リスト、下位システムでのサーバー側の認可、自作の関数ツールで包んで検査する仕組みなどがあります。

4-2. 有害コンテンツの分類は「このコンテンツは安全ポリシー上、有害か」、インジェクション攻撃の検知は「この入力や文書には、モデルへの指示を変えようとする試みが含まれているか」、認可の検査は「この主体は、このリソースに対して、この行動を取ってよいか」に答えます。互いを代替することはできません。

4-3. 対象のシステムとバージョン、本番から分離された試験環境、合成データと架空のシークレットの使用、許可・禁止する行為（模擬ツールの使用、第三者のシステムを対象にすることの禁止）、停止条件、連絡と報告の体制（誰に、どの形式で、いつ伝えるか）です。

4-4. 出力や外部へのリクエストにその値が現れたら、漏洩したと自動的に判定するためです。実際のデータや実際のシークレットと重ならないことと、モデルが偶然には生成できないほど固有の値であることが必要です。

4-5. 攻撃通過率は9 ÷ 240 = 3.75%、正常リクエストの誤遮断率は15 ÷ 500 = 3%です。この2つの数値だけでは、シナリオ単位でいくつが一度でも破られたか、どの層が攻撃を捕捉したか、正常な業務が最後まで処理されたか（業務完了率）、通過した攻撃の経路と被害の大きさはわかりません。このうち1つを挙げればよいです。

4-6. 上限は、およそ3 ÷ 60 = 5%です。実際の成功率が約5%より低い可能性が高いとは言えます。しかし、成功率が0であるとも、別の経路、別の変種、別のモデルのバージョンでも安全であるとも言えません。

4-7. 各統制を単独で使ったときの効果と、組み合わせたときの効果を分けて見るには、基準線、基準線 + 入力スクリーニング、基準線 + 書き込みツールの確認、両方を適用した構成、という4つの構成が必要です。評価セットのバージョン、モデル・プロンプト・ツールのバージョン、反復回数（および判定方法）を固定します。シナリオ単位の攻撃通過率と、正常業務の完了率（または誤遮断率）をあわせて見ます。統制を1つ取り除いた構成と比較すると、重複する統制を見つけられます。

第5章

5-1. セッション識別子、アクセストークン、パスワード、暗号鍵とシークレット、データベース接続文字列、決済情報、機微な個人情報のうち、4つです。代わりに、ハッシュ化したユーザー識別子、追跡識別子、ツール名と結果の状態、トークン数、ガードレールの判定といった情報を残します。

5-2. アラートは人に知らせるだけで実行は続きますが、予算の上限ではコードが実行を停止させます。1つのタスクに設けられる上限としては、モデルの呼び出し数、ツールの呼び出しと再試行の回数、子エージェント数、反復の深さ、費用、実行時間があります。

5-3. 継続的な入力超過は、コンテキストウィンドウを超える入力を繰り返し送ることであり、入力サイズの上限で防ぎます。リソース集約型クエリは、計算負荷の高いリクエストでリソースを使い果たすことであり、時間制限とスロットリング、リソースの配分管理、レート制限で防ぎます。

5-4. Anthropicの文書によると、モデルIDの重みは固定されていますが（以前の世代のエイリアスは最新のスナップショットに追随します）、リクエストルーター、安全分類器、サンプリングロジックといった配信インフラが変わると、観測される動作が少し変わる場合があります。運用チームは回帰評価セットを定期的に再実行し、サポート終了の予告と廃止の日程を追跡して、廃止前に代替モデルをあらかじめ試験します。

5-5. 実行されるコマンドを引数まで省略せずに表示し、ユーザーのシステムでコードを実行する危険な作業であると明示し、ユーザーの明示的な承認を得る必要があります（取り消しも可能である必要があります）。サーバーのコマンドは、既定の権限を最小限にしたサンドボックス内で、ファイルとネットワークへのアクセスを制限して実行することが推奨されます。

5-6. 1,000人以上の情報主体に関する個人情報の漏洩等が生じた場合、機微情報または固有識別情報の漏洩等が生じた場合、個人情報処理システムまたは個人情報の処理に使う情報機器への外部からの不正アクセスによって漏洩等が生じた場合です。知った時点から72時間以内に、個人情報保護委員会または韓国インターネット振興院に届け出ます。やむを得ない事情がある場合や、回収・削除によって権利利益の侵害の可能性が著しく低下した場合の例外もあるため、実際の判断は個人情報保護責任者と法務担当者が行います。

5-7. 解答例です。（1）メモリへの書き込み停止：AIプラットフォームのオンコール担当者が停止し、新しい記憶の保存は止めますが、既存の記憶の読み取りは維持します。汚染が確認された場合には読み取りも停止する、2段階の仕組みを設けます。（2）外部送信ツールの遮断：サービスのオンコール担当者が停止し、メール・メッセージの送信が止まり、下書きの作成だけが残ります。（3）コネクター・MCPの接続解除とトークンの失効：セキュリティ運用担当が実行し、該当する外部システムの照会と変更が止まります。（4）読み取り専用の案内モード：サービス責任者が有効にし、相談対応を事前に用意した案内を中心とする形に縮小します。