第5章 運用セキュリティとインシデント対応

学習目標

• 事故調査の質問に答えられる監査ログを設計し、ログ自体も機密データとして保護する。
• コスト・リソース枯渇攻撃とエージェントの暴走を検知し、予算と遮断装置で制限する。
• モデル、モデルファイル、プラグイン、MCPサーバーのサプライチェーンリスクを導入・変更手順で減らす。
• LLMのインシデント対応手順を、段階ごとの担当者、遮断手段、証拠、復旧基準とともに定める。
• 個人情報の漏洩が疑われるときに確認する法的な通知・届出要件の骨格を説明する。

はじめに

金曜の夜、ある会社の顧客サポートエージェントが普段の10倍のメールを送り始めました。オンコール担当者はアラートを受けてログを開きましたが、「ツール呼び出し成功」としか並んでいませんでした。どのセッションで、どの入力を読み、誰に何を送ったかは残っていません。送信ツールだけを止めるスイッチがなく、サービス全体を停止したため、月曜の朝まで問い合わせが積み上がりました。原因は調査で判明しましたが、何人分の顧客情報がどこへ出たかは最後まで確定できませんでした。オンコール担当者に落ち度はありません。事故当日にできることを決めるのは、それ以前に作ったログとスイッチです。運用中の事故は攻撃者なしでも起こります。一時的に有効にした設定1つ、夜間に適用した更新1つが、個人情報やコストの事故に広がります。

運用セキュリティは、事故前に準備した分しか機能しません。この章では、調査に答えられる監査ログとその保護から始め、コスト・リソース枯渇や暴走の制限、モデルとプラグインのサプライチェーン管理、異常信号の設計を扱います。最後に、LLMのインシデント対応手順、遮断スイッチ、個人情報漏洩が疑われるときの通知・届出要件を整理します。

重要な概念

監査ログは何を証明すべきか

事故時の最初の質問は、「いつ、誰のセッションに、どの入力が入り、モデルは何をしたか」です。OWASP Logging Cheat Sheetは、イベントごとに「いつ・どこで・誰が・何を」を記録し、関連イベントをつなぐインタラクション識別子も置くよう勧めています。LLMアプリケーションでは1つのリクエストが検索、複数のモデル呼び出し、ツール呼び出し、承認に分かれるため、追跡識別子が欠けると調査が途切れます。

ログは「モデルがどう考えたか」よりも、「システムが何を許し、何を実行したか」を証明すべきです。下流システムのログに実際の要求者でなく中継サーバーしか残らないと調査が止まる点は、MCPのセキュリティベストプラクティスも指摘しています。

ログ自体を守る

ログも機密データです。OWASP Logging Cheat Sheetは、セッション識別子、アクセストークン、パスワード、暗号鍵やその他の重要なシークレット、データベース接続文字列、決済情報、機微な個人情報を、ログから削除するか、マスキングするか、ハッシュ化するか、暗号化するよう求めています。ログ自体の保護もあわせて求めています。具体的には、偽造・改ざんの検知、可能な限り早い読み取り専用媒体へのコピー、ログへのアクセスの記録と監視、閲覧権限の制限と定期的な見直しです。信頼境界の外から来たデータは、改行文字などを処理してログインジェクションを防ぎます。モデルの出力と外部の文書が、その代表例です。

韓国の基準も、同じ方向を向いています。「個人情報の安全性確保措置基準」（個人情報保護委員会告示）は、個人情報処理システムにアクセスした者（情報主体本人を除く）のアクセス記録を1年以上保存・管理することを求めています。5万人以上の情報主体の情報、または固有識別情報・機微情報を処理するシステムなどでは、2年以上の保存が必要です。また、アクセス記録が偽造・改ざんされたり、盗難・紛失したりしないよう、安全に保管することも求めています。エージェントが個人情報処理システムにアクセスする構成であれば、そのアクセスの記録がこの基準のアクセス記録にどのように対応するかを、個人情報保護責任者と一緒に決めておいてください。

会話の原文全体を残すかどうかは、別途判断する事項です。基本のログはマスキング済みの構造化フィールドとして残し、調査にどうしても必要な原文は、アクセスを厳しく制限した別のストアに短期間だけ保管する方法が、一般的な折衷案です。

ユーザー識別と不正利用の追跡

不正利用を防ぐには、誰が繰り返しているかを把握する必要があります。OpenAIは、リクエストにsafety_identifierパラメータを付けてユーザーを一意に識別する一方、ユーザー名やメールアドレスはハッシュ化し、個人を識別できる情報を送らないよう勧めています。ログインしていないユーザーについては、代わりにセッション識別子を送ることができます。同じ文書では、登録やログインを求めるなど、ユーザーを把握しておくこと（KYC）もリスクの低減につながるとしています。

Anthropicは、同じ種類の拒否を繰り返し引き起こすユーザーに対して、ポリシー違反であることを伝え、レート制限や遮断で対応するよう勧めています。そのためには、ガードレールの判定を、ハッシュまたは内部の仮名で記録したユーザー識別子とあわせて残し、実際の身元との対応表は別に管理します。

無制限な消費の現れ方

OWASP LLM10（Unbounded Consumption）は、ユーザーが過剰で統制されない推論を実行できる場合のリスクです。下位のリスクは7つあります。

エージェントでは攻撃者なしでも起きます。ツールエラーへの再試行、下位タスクの分岐、互いに仕事を渡す循環が費用を幾何級数的に増やします。OWASP Agentic Top 10のASI08（Cascading Failures）の波及が、コストとして現れる場合です。ウォレット枯渇は、サービスが正常に見える間にも被害が積み上がる点で、一般のサービス拒否と異なります。

予算と遮断装置

OWASP LLM10は、入力検証、ロジット・対数確率の露出制限、レート制限、リソース配分管理、時間制限とスロットリング、ログ・監視・異常検知、透かし、段階的な機能縮小、アクセス制御、一元的なモデル一覧など15の緩和策を挙げます。OpenAIも、入力長と出力トークン数の制限が不正利用の削減に役立つとしています。

アプリケーション運用者がまず備えるべき仕組みは次のとおりです。

アラートと遮断を区別してください。費用アラートは知らせるだけで、金曜夜は誰も見ないかもしれません。予算上限はコードが実行を止めます。モデル抽出への対策は、OWASPの推奨に従って、API応答のlogit_bias・logprobsなどの詳細確率情報の露出を制限・曖昧化し、アカウントごとの利用パターンを監視します。OWASP AI Agent Security Cheat Sheetも、セッション別のトークンと費用を追跡し、連鎖的失敗を止めるサーキットブレーカーを置くよう勧めています。

サプライチェーン1：モデルとモデルファイル

OWASP LLM03（Supply Chain）は、古い外部パッケージ、ライセンス、保守終了モデル、バックドアのある事前学習済みモデル、弱い出所保証、悪意あるLoRAアダプター、共同開発の悪用、機器搭載モデルの改ざん、不明確な規約をリスクに挙げます。モデルは内部を見にくいバイナリのブラックボックスなので、静的検査だけでは保証に限界があります。

モデルファイルの形式もリスクです。Hugging Faceの文書は、PyTorchの重みの既定形式であるpickleファイルの読み込み時に任意のコードが実行されうると警告します。信頼できるユーザーや組織のモデルだけを読み込み、署名付きコミットで出所を確認するよう勧めますが、署名は安全性でなく出所を保証するだけとも補足しています。Hubのセキュリティスキャンも完全ではないと明記し、pickleと異なりテンソルを安全に保存するためのsafetensors形式を案内しています。

導入手順は次の順序で作ります。

1. 提供元、データの出所、規約、プライバシーポリシーを検討し、定期的に再確認します。
2. 出所を検証できるモデルだけを使い、署名とファイルハッシュで完全性を確認します。
3. 読み込み時にコードが動きうるファイルは、隔離環境でのみ開きます。
4. ベンチマークではなく、自分の用途のレッドチームと評価で確かめます。公開ベンチマークをすり抜けるようファインチューニングされることがあるためです（OWASP）。
5. パッチ方針を定め、保守されているAPIとモデルに依存します。

サプライチェーン2：ツール・プラグイン・MCPサーバー

エージェントは実行中にツールや他のエージェントを読み込みます。OWASP Agentic Top 10のASI04（Agentic Supply Chain Vulnerabilities）は、静的依存関係に注目するLLM03と異なり、実行中に組み合わせるツール、MCPサーバー、エージェントレジストリ、更新経路の汚染を扱います。初回導入時にレビューしたツールでも、更新後は別のツールかもしれません。

MCPのセキュリティベストプラクティスは、ローカルサーバーのリスクを具体的に記しています。ユーザーのコンピューター上でクライアントと同じ権限で動くため、悪意ある起動コマンドやサーバーが任意のコード実行や漏洩につながります。ワンクリックでローカルサーバーを設定するクライアントは、実行コマンドを省略せず全文表示し、危険な作業であることを示し、ユーザーの明示的な承認を得る必要があります。サーバーコマンドは最小権限のサンドボックスで動かし、ファイルとネットワークへのアクセスを制限することが推奨されます。

運用原則は4つです。ツールとサーバーの版を固定し、更新時に名前・説明・パラメータ・要求スコープの変化を比較し、権限が広がるなら新規導入同様に承認し、侵害の疑いがあれば接続とトークンを一度に止める失効手順を用意します。

構成一覧とAI BOM、モデルのライフサイクル

事故の際に「問題となった構成要素を、どこで、どのバージョンで使っているか」にすぐ答えるには、一覧が必要です。OWASP LLM03は、署名済みの最新のSBOM（ソフトウェア構成一覧）を維持し、モデルとデータまで含めたAI BOM（ML SBOM）を検討するよう勧め、その出発点としてOWASP CycloneDXを挙げています。CycloneDXのML-BOMは、AI・機械学習システムのデータセット、モデル、構成を表現し、その出所を記録するための形式です。LLMアプリケーションでは、これに加えてプロンプト、ツール定義、コネクターとその権限範囲、分類器、検索インデックスの出所まで一覧にしておくと役立ちます。

モデルにもライフサイクルがあります。Anthropicの文書によると、各モデルIDは固定されたバージョンを指しており、そのIDの重みは変更されません（以前の世代にあったエイリアスは、最新のスナップショットに追随するため例外です）。ただし、リクエストルーターや安全分類器といった配信インフラが変わることで、観測される動作が少し変わる可能性があります。モデルはサポート終了の予告（deprecated）を経て廃止（retired）され、廃止されたモデルへのリクエストは失敗します。Anthropicは、公開モデルの廃止を少なくとも60日前に通知し、廃止の十分前に代替モデルでアプリケーションを試験するよう勧めています。セキュリティの観点では、モデルの切り替えは第1章で扱った見直しの条件に当たります。新しいモデルで回帰評価セット（第4章）を再実行してから切り替えます。

検知信号の設計

不審な文言を探す検知より、実際の権限悪用や被害の兆候を見る検知が長く役立ちます。

担当のないアラートはたまるだけなので、担当者と最初の措置を各アラートに定めます。目標状態やツール使用パターンの基準線があれば、予想外の目標変更や呼び出し順を逸脱として検知できます（OWASP Agentic Top 10）。

インシデント対応手順

LLMの事故も一般のセキュリティ事故と同じ骨格に従いますが、ツール権限、記憶とインデックス、プロンプト・モデルの版という固有要素が加わります。NISTは2025年4月、SP 800-61 Rev. 3を公開し、対応の推奨事項をCSF 2.0とリスク管理活動に合わせて整理しました。NIST AI RMFのManageも対応・復旧・コミュニケーション計画を含み、事故やエラーを関係主体に伝えるよう求めています。

遮断は範囲確定より先です。漏洩が続いているかもしれないのにログ分析を先にすると、被害が拡大します。逆に、原因を確認せず急いで再開すると同じ経路が開きます。OpenAIはキーの露出や不正使用の可能性があれば即座に無効化して交換するよう勧め、OWASP Secrets Management Cheat Sheetは、アプリの再起動では盗まれた認証情報は失効しないと警告します。同文書は、無効化と再発行を迅速に行えるよう、平時からシークレットを中央管理ツールに置き、自動ローテーションを設定することも推奨しています。

遮断スイッチと安全な縮小運用

「サービス全面停止」しか手段がないシステムは、小さな事故でも大きな代償を払います。スイッチは単位別に準備します。

1. ツール単位：特定のツール（送信、決済、外部取得）だけを止めます。
2. 接続単位：特定のMCPサーバーやコネクターを切断し、トークンを失効させます。
3. 機能単位：メモリ書き込み、外部リンクのレンダリング、ファイルアップロードを止めます。
4. モード切り替え：読み取り専用モードや、事前に用意した定型案内のみを返すモードにします。
5. タスク単位：待機タスクを取り消し、実行中のタスクを止めます。

各スイッチについて、誰が操作でき、止めると何が止まり、実行中のタスクはどうなるかをランブックに書き、定期的に実際に操作します。画面の「停止」ボタンがサーバーのタスクを本当に止めるかも試験対象です。四半期ごとの机上演習で、実システムに触れずランブックの手順を口頭で確認すれば、「1ツールだけを止めるスイッチがない」「提供元への連絡経路が不明」などの穴が見つかります。

個人情報漏洩の通知と記録

LLMの事故が個人情報の漏洩につながると、法的な通知・届出の要件が生じます。この節の内容は判断の骨格であり、法律上の助言ではありません。実際の事故では、個人情報保護責任者と法務担当者が判断します。

韓国の個人情報保護法第34条は、個人情報処理者が漏洩等（紛失・盗難・漏洩・偽造・改ざん・毀損）を知ったとき、遅滞なく情報主体本人に通知するよう定めています。通知するのは、漏洩した項目、時点と経緯、被害を減らすために本人が取れる方法、処理者の対応措置と救済手順、担当部署と連絡先、損害賠償請求や紛争調停などの法的権利とその行使方法などです。2026年9月11日に施行された改正により、漏洩等の可能性があることを知った場合の通知も新たに加わりました。施行令は、この通知を書面等の方法で72時間以内に行うという期限を定めています（緊急措置が必要な場合は、その理由が解消した後、直ちに行います）。具体的な内容がまだ確認できていない場合は、確認できた内容から先に通知し、その後に追加で通知することを求めています。施行令第40条は、1,000人以上の情報主体の情報、機微情報または固有識別情報、外部からの不正アクセスによる漏洩のいずれかに該当すれば、知った時点から72時間以内に個人情報保護委員会または韓国インターネット振興院に届け出るよう定めています。やむを得ない事情がある場合の期限の例外と、回収・削除によって権利利益の侵害の可能性が著しく低下した場合には届け出なくてもよいという但し書きもあります。健康に関する情報は、同法第23条の機微情報に当たります。

実務上の意味は2つあります。72時間以内に「どの項目が、何人分、どの経路で漏洩したか」に答えるには、範囲の確定に使うログをあらかじめ用意しておく必要があります。また、漏洩が確定する前にも通知の判断が必要になる可能性があるため、事故の初期から個人情報保護責任者を対応体制に加えておきます。NIST AI 600-1も、ログ、変更管理の記録、バージョンの履歴が事故情報の共有に役立つと説明しています。

さらに深く

証拠保全と個人情報のバランス

調査には原文が必要であり、個人情報保護の観点からは原文を減らすよう求められるため、ストアを分けます。基本の監査ログは、マスキング済みの構造化フィールドとして長期間保管します。原文は別の証拠ストアに短期間だけ保管し、アクセスの承認を受けた場合にのみ閲覧できるようにします。事故が宣言されたら、該当する期間の原文を証拠ストアに凍結し、収集・閲覧・引き渡しの記録を残します。分析には原本ではなくコピーを使い、そのコピーにも完全性を確認するための値を付けます。

システムごとに時計が異なると、出来事の順序を再構成できません。そのため、時刻を1つの基準に合わせ、追跡識別子でイベントをつなぎます。調査中に原文をメッセンジャーやチケットに貼り付けて二次的な露出を起こさないよう、調査用チャネルのルールも定めておきます。

メモリ・インデックス・キャッシュ汚染からの復旧

エージェントの事故では、原因を取り除いても汚染が残ることがあります。汚染された文書はインデックスに、隠れた指示から生じた「好み」は長期メモリに、汚染された回答は応答キャッシュに残ります。復旧は、次の順序で考えます。まず、汚染源からの書き込みを停止します。次に、汚染が生じた期間と経路をもとに、影響を受けたメモリ項目、インデックスの断片、キャッシュ項目を探します。出所の情報が保存されていれば、この段階が容易になります。見つけた項目は、まず検索対象から外して隔離し、その後で削除します。インデックスは、信頼できる原本から必要な範囲を再構築します。汚染期間中に発行された、または露出した認証情報は交換します。最後に、同じ汚染を再現するシナリオで回帰評価を実行してから、書き込みを再開します。

第1章の質問である「汚染されたときにどう消すか」に答えられないストアは、この段階で丸ごと破棄しなければならない場合もあります。メモリやインデックスに出所と作成時刻を残す設計にすると、復旧のコストを大幅に減らせます。

実務の場面

一心歯科ネットワーク：デバッグログが漏洩経路だった

歯科医院のネットワーク「一心歯科ネットワーク」の予約・相談チャットボットを定期点検していた担当者は、3か月前に品質調査のために有効にしたデバッグログが、そのまま有効になっていることを発見しました。会話の原文全体が、外部のログ分析サービスに送信されていたのです。会話には患者の氏名、連絡先、痛みのある部位、治療履歴が含まれていました。そのログサービスのプロジェクトには、外注の開発会社の社員を含め、20人近くのアカウントがアクセスできました。

担当者は、まず遮断を行いました。デバッグログを無効にし、外部への送信を停止し、プロジェクトへのアクセス権限を必要最小限の人数に絞りました。続いて、送信されていた期間、送信された会話の数、重複を除いた患者数を調べ、ログサービスのアクセス記録から、その期間に誰がログを閲覧したかを確認しました。外部からの不正アクセスの形跡はありませんでしたが、業務上の必要がない人たちが、機微な診療情報にアクセスできる状態でした。

個人情報保護責任者と法務チームが、その日のうちに対応に加わりました。治療履歴は機微情報に当たる可能性があり、施行令上、機微情報の漏洩は人数に関係なく届出の対象となる可能性がありました。法務チームは通知と届出が必要かどうかを検討し、72時間以内に結論を出しました。その判断には、担当者が整理した期間、項目、人数、閲覧記録がそのまま使われました。

原因を取り除くため、基本のログにはマスキング済みの構造化フィールド（追跡識別子、ツール名、判定、トークン数）だけを残すことにしました。原文が必要な場合は、承認を得たうえで、アクセスを制限した内部ストアに最大2週間だけ保管するようにしました。デバッグ設定には有効期限を設け、外部へ送信されるデータは四半期ごとに見直します。振り返りには、「ログも機密データであり、一時的な設定には必ず有効期限を設ける」と記録しました。

なみメディア：攻撃者なしで起きたウォレット枯渇

コンテンツ企業「なみメディア」は、記事の草稿を作る際に資料調査エージェントを使っています。エージェントは外部資料を検索するコネクターで資料を集め、子エージェントに要約を分担させます。ある火曜日の未明、月間予算の40%がわずか6時間で使われたというアラートが出ました。アラートはメールでしか届かず、朝の出社まで誰も見ることができませんでした。

オンコール担当者がログを確認しましたが、攻撃の形跡はありませんでした。前の晩に検索コネクターが更新されて応答形式が変わり、エージェントは応答を解釈できないと「検索失敗」と判断して再試行していました。再試行のたびに子エージェントを新たに起動して要約をやり直させ、子エージェントも同じコネクターを呼び出して失敗し、再試行していました。1つのタスクが、数百回のモデル呼び出しに膨らんでいたのです。

遮断は2段階で行いました。コネクターの接続を停止し、進行中の調査タスクをすべて取り消しました。取り消しボタンが実際に子エージェントまで停止させるかを確認するのに時間がかかりました。一部の子タスクは、親タスクが取り消された後も動き続けていたのです。チームは、これを別の欠陥として記録しました。

再発防止策は、アラートで知らせる仕組みを、実行を遮断する仕組みに変えることに重点を置きました。1つのタスクに対し、モデル呼び出し数、子エージェント数、再試行回数、費用の上限を設けました。再試行の間隔は徐々に長くし、同じツールエラーが5回連続したらその呼び出しを遮断するサーキットブレーカーを導入しました。親タスクを取り消すと、子タスクも一緒に停止するよう修正しました。コネクターはバージョンを固定し、応答形式の比較と回帰試験を通過した更新だけを適用します。組織の1日あたりの予算に達したら、調査機能を読み取り専用の要約モードに縮小します。振り返りには、「悪意がなくても無制限な消費は起きる」「誰も見ていない時間に働くのは、アラートではなく上限である」と記載しました。

間違えやすいポイント

1. 「安いモデルに変えれば、コスト攻撃は解決する」。単価が下がっても、リクエストが無制限なら費用は増え続けます。原因は、上限のない消費です。
2. 「費用アラートを設定したので、ウォレット枯渇は防げる」。アラートは人に知らせるだけです。誰も見ていない時間には、コードが実行を止める上限が必要です。
3. 「人気のあるモデルなので、検証済みである」。ダウンロード数やベンチマークの点数は、完全性の証拠にはなりません。出所、署名、ハッシュ、自分の用途での評価によって確認します。
4. 「モデルIDを固定したので、動作は絶対に変わらない」。重みが固定されていても、配信インフラの変更で動作が少し変わる場合があります。また、モデルはいずれ廃止されます。回帰評価を定期的に実行します。
5. 「ログは多く残すほどよい」。ログも機密データです。何を残し、何をマスキングし、どれくらいの期間保管し、誰が閲覧するかを決める必要があります。
6. 「原因をすべて解明してから遮断しよう」。被害が進行中であれば、遮断が先です。原因の確認は、再開する前に終わらせます。
7. 「キーを変えるには、サービスを再起動すればよい」。再起動では、盗まれた認証情報は失効しません。失効と再発行を別途行う必要があります。

ひと目でわかるまとめ

試験の前日に、次の文を1つずつ声に出して確認してください。

• 監査ログには、いつ・どこで・誰が・何をしたかに加え、入力の出所、ツール呼び出し、承認、判定、バージョンを記録し、追跡識別子でつなぐ。
• ログからトークン・パスワード・キー・接続文字列・機微な個人情報を除去するかマスキングし、偽造・改ざんと閲覧を制御する。
• 不正利用の追跡は、ハッシュ化したユーザー識別子とガードレールの判定記録を使って行う。
• 無制限な消費は、攻撃者がいなくても起こりうる。再試行・分岐・委任の循環が費用を増大させる。
• アラートは知らせ、上限は停止させる。タスク単位の予算とサーキットブレーカーを設ける。
• モデルファイルは出所・署名・ハッシュを確認し、実行コードを含みうる形式は隔離して扱う。
• ツール・MCPサーバーはバージョンを固定し、更新時には説明・パラメータ・権限範囲の変化を検討する。
• インシデント対応の骨格は6段階であり、被害が進行中なら、範囲をすべて解明する前にまず遮断する。再開するのは、原因を修正し、回帰試験に合格した後である。
• 遮断スイッチは、ツール・接続・機能・モード・タスクの単位で準備し、実際に操作してみる。
• 個人情報の漏洩が疑われたら、72時間を基準とする通知・届出の判断に備え、初期の段階で個人情報保護責任者を呼ぶ。

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

• OWASP LLM10:2025 Unbounded Consumption：下位リスクと緩和戦略。
• OWASP LLM03:2025 Supply Chain：サプライチェーンリスクとAI BOM。
• OWASP Logging Cheat Sheet：記録するもの、除くもの、ログ保護。
• OpenAI — Safety best practices：safety_identifier、キーの無効化、報告経路。
• Hugging Face — Pickle Scanning：pickleのコード実行リスク。
• Anthropic — Model deprecations：モデルのライフサイクルと廃止通知。
• NIST SP 800-61 Rev. 3：CSF 2.0に合わせたインシデント対応の推奨事項。
• 個人情報保護法：第34条の漏洩等の通知・届出（施行令第39条・第40条と併せて）。

セルフチェック

5-1. OWASP Logging Cheat Sheetに基づき、ログから除くか隠すデータを4つ書き、代わりに調査用に残せる情報を1つ挙げてください。

5-2. 費用アラートと予算上限の違いを説明し、1つのエージェントタスクに設定できる上限を2つ書いてください。

5-3. OWASP LLM10の「継続的な入力超過」と「リソース集約型クエリ」を区別して説明し、それぞれの統制を1つずつ挙げてください。

5-4. モデルIDを固定しても同じプロンプトへの動作が変わりうる理由をAnthropicの説明に基づいて書き、運用チームがすることを1つ挙げてください。

5-5. ワンクリックでローカルMCPサーバーを追加するクライアントが、MCPのセキュリティベストプラクティスに従って必ず行うことを2つと、推奨される実行環境を書いてください。

5-6. 韓国の個人情報保護法施行令第40条の届出対象3つと、期限を書いてください。

5-7. 設計課題：長期メモリ付き相談エージェントの対応ランブックに入れる遮断スイッチを4つ設計してください。各スイッチが何を無効にし、誰が操作でき、何が止まるかを書いてください。

実習課題