モデルが賢くなるほど、漏れる穴も広くなる
前回の第5回では、規模別に自動化予算をどう組むべきかについてお話ししました。見積もりが整理された後、決裁者の席で最も頻繁に返ってくる質問は決まっています。「それで、これを導入したら、うちの会社のデータは安全なのですか?」。第5回の規模別見積もりガイドが財務イシューだったとすれば、第6回はその見積もりを通すための最後のゲート、セキュリティとガバナンスの話です。
正確に言えば、問題は「LLMが危険だ」ではありません。自動化ワークフローにLLMノードが1つ入る瞬間、これまで社内システムの内側に閉じ込められていたデータが外部APIへと流れ出し、判断1つが人の手を経ずに決裁・送信・アップロードへとつながっていくという事実です。この構造が生み出す新しいリスク4つを押さえ、決裁者が最低限確認すべきチェックポイントを整理します。
なぜ2026年にこの話題が急務になったのか
3つの流れが重なりました。第一に、韓国のAI基本法が本格適用段階に入りました。第二に、OWASPが発表したLLMアプリケーションの脅威ランキングで「機密情報の露出」が6位から2位へと跳ね上がりました。プロンプトインジェクションで対話ログから個人情報を抜き取る攻撃事例がそれだけ増えたということです。第三に、自動化ツールがSaaSベースになるにつれて、担当者がワークフローを1つ追加するたびに、データ流出経路が1つずつ増えていく構造になりました。
正直に言うと、初めて自動化を導入する会社でこの3つをすべてカバーしているケースは稀です。むしろよくあるパターンはこうです。総務担当者がワークフローツールでチャットボットを1つ作り、顧客からの問い合わせデータをそのままOpenAI APIに流した後、数日経ってから法務が「これ、個人情報の処理委託契約なしで外部に出て行ったデータですよね?」と尋ね、プロジェクト全体が止まる。技術的な事故よりも、こうした組織的な事故のほうがずっと頻繁に起こります。
PIIマスキング — データがモデルに触れる前に
第一の防衛線は非常にシンプルです。個人情報(PII, Personally Identifiable Information)をモデルに渡さないことです。マイナンバー、カード番号、電話番号、メールアドレス、氏名 — この5つを自動的にフィルタリングするだけで、事故の半分は予防できます。
実装は大きく2つの層で行われます。プロンプトがモデルへ送信される直前に、正規表現ベースのフィルターで代替文字列([MASKED_PHONE]、[MASKED_NAME])に置換するのが1次、応答が返ってきた後に元の値へ復元するのが2次です。この往復構造があれば、ログ・ベクトルDB・プロンプトキャッシュのどこにも元のPIIが残りません。
正規表現では捕捉できない氏名のような項目には、別途の小型NERモデルや、LLM Gateway系の商用サービス(例: Presidio、OpenGuardrails)を前段に置く方式が標準として定着しつつあります。100%完璧ではありませんが、「すべてのリクエストを人がレビュー」という非現実的な代替案よりは、はるかに持続可能です。
監査ログ — 事故の後で何を再現できるか
ガバナンスで最も後回しにされがちなのが監査ログ(audit log)です。自動化の実行1回について、次の4つが残っていなければなりません: いつ(timestamp)、誰がトリガーしたか(user or system)、どんなプロンプトが出て行き(input、PIIマスキング後)、どんな応答が返ってきて(output)、結果としてどの外部システムが呼び出されたか(tool_calls)。
業務自動化の観点でこのログが重要な理由は2つあります。1つはエラー原因の追跡です。自動送信された見積もりメールに誤った金額が入っていた時、ログがなければ「モデルがおかしかったからそうなった」としか言えません。もう1つは監査対応です。規制当局や顧客企業のセキュリティ監査で「昨年3月にある顧客のデータをどのプロセスが処理したのか」を30分以内に答えられなければなりません。
実務のヒントを1つ。監査ログは、自動化ワークフローツール自身が保存する実行履歴とは別に、アプリレベルのイベントストリーム(例: 別途のログテーブル、または観測性ツール)へ二重に残しておくのが安全です。SaaSベンダーがログを30日しか保管しないケースでは、規制対応期間とずれてしまいます。
出力ガードレール — JSONスキーマ検証とリトライ
モデルの応答が自由テキストのまま次のノードへ流れていくと、ワークフローのどこかで必ず壊れます。ですから出力ガードレールの第一原則はこうまとめられます。「自由テキストを絶対に信頼しないこと、スキーマで検証すること」。
実務で最も多く使われるパターンはJSONスキーマの強制です。リクエスト時に応答フォーマットをJSONに指定し、受け取った応答をスキーマ検証器(例: Pydantic、Zod、Guardrails AI)に通した後、検証に失敗すればエラーメッセージを再びプロンプトに添えてリトライします。このリトライパターンを導入しておけば、実務で8%程度発生するフォーマットエラーが、たいてい1〜2回のリトライで正常に収束します。
ただしリトライには落とし穴が1つあります。すべての失敗をリトライしてはいけません。フォーマットエラーやAPIの一時的なエラーはリトライ対象ですが、ビジネスルール違反(例: 承認限度を超える金額)は、リトライではなく人へのエスカレーションに回すべきです。ここを区別しておかないと、モデルは3回試行した末に「とにかく通る答え」を出す方向へ学習したかのように振る舞います。
決裁者が確認する5つのチェックポイント
技術詳細に踏み込むとキリがありませんが、決裁者・CIOの観点ではこの5つをチームに問うだけで十分です。「このワークフローは — 」①どの個人情報がどこへ出て行き、どうマスキングされていますか? ②すべての実行に対する監査ログが何ヶ月分残っていますか? ③応答フォーマットはどう検証され、失敗した時にどう処理されますか? ④人が必ず介入すべきポイント(ヒューマン・イン・ザ・ループ)はどこですか? ⑤外部LLMベンダーとのデータ処理委託契約は締結されていますか?
この5つの答えが用意されていない自動化は、規模を問わず、まだプロダクションに乗せる準備ができていない状態です。逆にこの5つが明確なら、残りの細かい実装はチームが自ら埋めていけます。
今日のアクションアイテム
- PIIカテゴリ5つから開始: マイナンバー・カード番号・電話・メール・氏名をマスキング対象に指定し、今週中にワークフローの前段へ正規表現フィルターを組み込んでみます。
- 監査ログの最小スキーマ: timestamp・trigger・input(masked)・output・tool_callsの5フィールドでログテーブルを1つ作ります。完璧さよりも存在が先です。
- JSONスキーマ強制の導入: 自由テキストで次のノードへ渡している箇所を1つ見つけ、PydanticやZodで検証層を入れます。
- ヒューマン・イン・ザ・ループ箇所の明示: 自動で完結するフローのうち「金額・契約・送信」に関わるノードには、承認ゲートを1つ挟んで進めるようにします。
- セキュリティ設計レビューの依頼: 第三者レビューが必要でしたら、セキュリティ設計レビューをご依頼いただけます。導入前のリスクマトリクスを一緒に整理いたします。
本シリーズの次回、第7回では「自動化プロジェクト失敗の5大パターンと回避チェックリスト」を扱います。今日押さえたガバナンスが不在のまま導入を強行した場合にどんな場面が繰り広げられるのか、実務で頻繁に観測される5つのパターンを整理する予定です。
よくある質問
PIIマスキングを行うと、モデル応答の品質は落ちませんか?
単純な代替文字列([MASKED_NAME])方式は、対話の自然さを一部損ないます。ただし、応答をユーザーに見せる前に元の値へ復元する後処理ステップを挟めば、エンドユーザー視点では品質差はほとんど感じられません。むしろ「モデルが名前を誤って覚えて別の呼び方をする」事故を予防する副次効果もあります。
監査ログを保存するのに最も安全な場所はどこですか?
自動化ワークフローツール内部の実行履歴 + 別途のログストレージ(観測性ツールまたは自社DB)への二重保存をお勧めします。SaaSベンダーがサービスを終了したり、ログ保管ポリシーを変更しても監査対応が可能なようにする、最低限のセーフガードです。保存場所そのものは、国内リージョンまたは契約上明確な管轄権を持つリージョンであれば十分です。
小規模チームでこれらすべてをカバーするのは負担が大きいです。どこから始めるべきですか?
PIIマスキング → 監査ログ → スキーマ検証の順序をお勧めします。マスキングは1日で組み込め、ログは2日、スキーマ検証は対象ノード数に応じて数日かかります。完璧なガバナンスよりも、「事故が起きた時に原因を追跡でき、再発を防げるか」という最低ラインを先に通過することが実用的です。