AppSheet DLP 機密情報制御：Gemini判定で補完する設計基準

AppSheet の Automation 機能を通じて Gemini の AI Task（テキスト分類・情報抽出）が利用可能になり、フリーテキスト入力を含む業務フォームの機密情報制御が Google Workspace の範囲内で完結できるようになっています。この記事では、AppSheet × Gemini × GWS DLP (Data Loss Prevention) の三層制御アーキテクチャについて、「どの場面で Gemini 判定を組み合わせるか」という設計判断の軸を整理します。

この記事を読んだほうが良い人

• AppSheet でノーコードの業務フォームや申請アプリを運用しており、機密データの送信制御方法に課題を感じている情シス担当者
• GWS の DLP をすでに設定しているが、フリーテキスト欄への機密入力をうまく検出できていない方
• Gemini の AI 判定を AppSheet の業務フローに取り込みたいが、どのシーンに使うべきか判断基準がない方
• ノーコードアプリの情報漏洩対策を体系化したい 100 名規模企業の情シス担当者

AppSheet の機密データ送信制御で DLP が不十分になる場面

Google Workspace の DLP は、Drive ファイルや Gmail 経由の送信時にパターンマッチング（正規表現・キーワードリスト）で機密情報を検出します。マイナンバーやクレジットカード番号のように「形式が決まっているデータ」には強力ですが、文脈に依存した機密判断は得意ではありません。

データの種類によって DLP の有効性がどう変わるかを整理すると、以下のようになります。

データの種類	DLP 検出力	理由
マイナンバー（12桁数字）	高	正規表現パターンが確立されている
クレジットカード番号	高	業界標準のフォーマットが一定
契約金額・条件（テキスト）	低	金額の書き方が人によって異なり、文脈が必要
顧客対応メモ	低	機密性は文章の意味で変わり、パターン化できない
NDA・取引先名の言及	低	組織内文脈がないと機密かどうか判断できない

AppSheet のフォームには、経費明細の摘要欄・事故報告の詳細・顧客対応メモのようにフリーテキストが入るケースがあります。「契約金額：1,500万円」「A社との NDA 締結済み」「受注単価は非公開でお願いします」のような入力は、DLP の正規表現パターンだけでは機密かどうかを判断できません。

この文脈判断を補うのが Gemini の AI Task です。Gemini はテキストの意味を読んで機密度を分類できるため、DLP の「パターン検出」と組み合わせることで検出の穴を埋めます。

三層制御アーキテクチャの全体像

「AppSheet 数式 → Gemini AI Task → GWS DLP」の三層で役割を分担します。それぞれの層が担う役割と特性を理解することが、設計判断の起点です。

第一層：AppSheet 数式によるルールベース制御

送信ボタンの表示制御や Valid_If 式を使った入力バリデーションで、ルールが明確な項目を機械的にチェックします。「プロジェクトコードが "SECRET-" で始まる案件は承認フローに乗せる」「添付ファイルのサイズが 10MB を超える場合は送信不可にする」のような決定的なルールはここで処理します。Automation を通さず即時反応するため、ユーザー体験のロスが最小です。

第二層：Gemini AI Task による機密度スコアリング

AppSheet の Automation で、フリーテキスト欄の内容を Gemini の「分類（Categorize）」AI Task に渡します。「機密」「社外秘」「一般」のカテゴリをあらかじめ定義しておくと、Gemini がテキストの文脈を読んで分類します。分類結果はレコードの専用カラムに書き戻し、第一層の数式から参照できる構成にします。

Gemini AI Task の設定では、分類カテゴリの説明文が精度を左右します。カテゴリの説明が曖昧だと誤分類が増えるため、「機密：社外秘の金額・取引先名・契約条件・法的合意を含む内容」「一般：公開可能な一般業務連絡」のように、自社の情報セキュリティポリシーに基づいた具体的な説明を付けておくことが重要です。導入後は実際のテストケースで精度を検証し、カテゴリ定義を調整するサイクルを持つと実運用に耐えられます。

第三層：GWS DLP による送信時の機械的検出

Drive や Gmail 経由でデータが外部に出る際に、GWS の DLP ポリシーがマイナンバー・クレジットカード番号・カスタムキーワードリストなどのパターンを検出してブロックします。第一層・第二層をすり抜けた場合のセーフティネットです。カスタムコンテンツ検出器を使えば、自社固有の識別子（案件番号の形式・取引先コードなど）も検出対象に追加できます。

どの層に何を任せるか：設計判断フロー

データの性質で判断する

どの層をどの程度使うかは、扱うデータの性質とリアルタイム性の要件によって変わります。

データの性質	推奨アーキテクチャ
構造化データのみ（数値・コード・チェックボックス）	第一層（数式）+ 第三層（DLP）で足りる
フリーテキストを含む、文脈依存の機密情報	三層すべてを使う
大量データを一括処理するバッチフロー	Gemini 呼び出しはコスト要因になるため DLP 中心。Gemini の適用は必要最小限に絞る
リアルタイム性が求められる（数秒以内のレスポンス要求）	第一層の数式のみで即時返答し、Gemini 判定はバックグラウンドで非同期実行する設計にする

運用コストで判断する

Gemini AI Task の呼び出しは、AppSheet の Automation が動くたびに Gemini API が呼ばれます。全フォーム入力に対して一律に Gemini 判定を挟む設計は、コストと応答時間の面で現実的でないケースがあります。「フリーテキスト欄を含む、かつ外部共有の可能性がある申請フォーム」に絞って適用するのが実務に合っています。

同じ AppSheet で Gemini を使う承認フロー設計との違いを整理すると、承認フローは「誰が承認するか」を振り分ける用途であるのに対し、この機密制御アーキテクチャは「送信をそもそも許可するかどうか」を制御する用途です。承認フローが始まる前段階の制御として位置づけると、役割の混乱を防げます。

AppSheet セキュリティ設定：Gemini 分類結果を使った数式サンプル

Gemini の分類結果（[Gemini分類] カラム）を使って送信ボタンを動的制御する例を示します。列名はアプリの実際のカラム名に合わせて変更してください。

送信ボタンの表示制御（Show_If プロパティ）

分類が「機密」のときにボタンを非表示にし、ユーザーが誤送信できない状態にします。

[Gemini分類] <> "機密"

警告メッセージの表示（仮想カラムの App formula）

フォーム内に警告テキストを表示する仮想カラムです。Show_If 条件と組み合わせて「機密」分類のときだけ表示させます。

IF(
  [Gemini分類] = "機密",
  "このフォームには機密情報が含まれている可能性があります。送信前に情報セキュリティ担当者に確認してください。",
  ""
)

キーワードを使った第一層のバリデーション（Valid_If プロパティ）

Gemini 判定を待つ前に、確定しているキーワードが含まれる場合に入力を弾く即時ガードです。NDA 関連の記入が摘要欄に入ったタイミングでユーザーに警告します。

NOT(CONTAINS([摘要], "NDA"))

このように、キーワードが確定している機密語は第一層の数式で処理し、文脈が必要なケースは第二層の Gemini 判定に任せると、処理を効率よく分担できます。

機密レコードの承認フロー振り分け（Automation トリガー条件）

「機密」に分類されたレコードを自動で承認フローへ振り分ける場合は、Automation のトリガー条件に以下を設定します。

[Gemini分類] = "機密"

このトリガーに「承認メール送付」「Slack 通知」などの後続ステップを紐付けることで、機密データを含む申請が自動的に別ルートへ流れる設計になります。

GWS DLP との接続点

AppSheet のデータが Drive に書き込まれるタイミングや、Gmail 経由でエクスポートされるタイミングで GWS DLP が機能します。AppSheet 側の Gemini 判定は「フォーム入力フェーズの機密検出」を担い、DLP は「データ出力フェーズの最終防衛線」を担う役割分担です。

三層を組み合わせることで、「AppSheet フォームで入力 → Gemini が機密度を分類 → 機密なら承認フローへ振り分け → Drive に保存された時点で DLP がパターン検出」という多層防御の流れができます。どこか一層を単独で使うよりも、検出漏れを構造的に減らせます。

DLP をカスタムコンテンツ検出器で強化すれば、自社固有の機密識別パターンも検出対象にできます。たとえば「PJ-XXXX」形式の案件番号を機密フラグとして定義し、その番号が Drive ファイルや Gmail に含まれていた場合にアラートを出す設定が取れます。

カスタムコンテンツ検出器の正規表現設定については、DRASENAS の GWS DLP カスタムコンテンツ検出器の解説記事で詳しく扱っています。自社独自パターンの定義とこの三層設計を組み合わせると、機密検出の網羅性がさらに上がります。

よくある設計ミスと回避策

実際の導入でつまずきやすい3つのパターンを整理します。

ミス1：Gemini 判定結果を不可逆処理に直結させる

Gemini の分類精度は高いですが、誤分類のリスクはゼロではありません。「機密」と判定された瞬間にレコードを削除したり、ユーザーのアカウントを制限したりする処理に直結させると、誤判定によるオペレーションインパクトが大きくなります。「機密」判定は通知と承認フローへの振り分けに留め、削除・強制変更は人間の確認後にする設計が安全です。

ミス2：すべてのフォームに三層制御を一律適用する

Gemini AI Task は呼び出しのたびに処理が走るため、件数が多いフォームに一律適用するとコストが積み上がります。まず「フリーテキスト欄があり、かつ社外共有の可能性がある」フォームを抽出して絞り込み、そこから三層制御を適用するのが現実的です。社内のみで完結するフォームには第一層と第三層だけで十分なケースも多くあります。

ミス3：Gemini の分類カテゴリを曖昧に定義したまま使う

AI Task のプロンプト設計でカテゴリの説明が不十分だと、「機密」「一般」の境界が不明確になり分類精度が落ちます。カテゴリを定義する際には、自社の情報セキュリティポリシーに沿った具体的な説明文を書き、導入後は想定ケース（真陽性・偽陽性・偽陰性）でテストして調整するサイクルを設けることを推奨します。

ノーコードアプリの情報漏洩対策として導入前に確認すべきこと

三層制御を設計する前に、以下の観点を確認します。

• ライセンス要件: Gemini AI Task の利用には AppSheet Enterprise Plus ライセンスが必要です（AppSheet 公式ヘルプより）。GWS DLP のカスタムコンテンツ検出器は Enterprise Standard 以上（Frontline Standard/Plus・Education 各種・Enterprise Essentials Plus も含む）のエディションで利用できます（Google Workspace 公式ヘルプより）。現在のライセンスでどの機能が使えるかを事前に確認してください
• Gemini 判定の精度と不可逆処理の禁止: Gemini はコンテキストを読んで分類しますが、誤分類のリスクはゼロではありません。「機密」と判定されたデータを自動削除するような不可逆的な処理に直結させないのが原則です。上記「よくある設計ミス」の項も合わせて参照してください
• Automation のレイテンシ: Gemini AI Task の呼び出しには数秒から数十秒かかる場合があります。ユーザーが送信後に分類結果を待つ UX 設計を事前に検討する必要があります。リアルタイム性が重要なフォームでは、Gemini 判定をバックグラウンドで実行し、ユーザーへの通知は後から届ける設計を検討してください
• 送信データのスコープ確認: AppSheet から Gemini API へテキストが渡るため、どのカラムのデータが Gemini に送信されるかを整理し、組織のデータ取り扱いポリシーと照合してください。個人情報が含まれるカラムを Gemini に渡す場合は、プライバシーポリシーとの整合性確認が必要です
• テスト環境での事前検証: 本番環境で直接三層制御を設定するのではなく、テスト用のコピーアプリで挙動を確認してから本番に展開します。特に Automation のトリガー条件は、想定外のタイミングで発火するリスクがあるため、件数の少ないテストデータで動作確認を行ってください

Gemini の誤分類リスクについては、「機密」判定 → 即時ブロックではなく、「機密」判定 → 承認者へ通知 → 承認後に送信許可、という二段階を挟む設計のほうが運用上の安全性が高い場合があります。自動化の範囲をどこまで広げるかは、業務上のリスク許容度と合わせて決めることになります。

まとめ

AppSheet の機密情報制御を「ルールベース数式 → Gemini AI 判定 → GWS DLP」の三層で設計することで、ノーコードアプリのセキュリティを GWS の範囲内で完結させられます。

三層すべてを使うかどうかはデータの性質で判断します。構造化データが中心のフォームなら第一層と第三層で十分です。フリーテキスト欄を持つ申請系フォームから始め、Gemini 分類の精度と運用負荷を確認しながら適用範囲を広げるアプローチが現実的です。

設計のポイントを3点に絞ると、以下になります。

• Gemini 判定は文脈依存の機密入力が含まれるフォームに絞って適用する
• 誤分類に備えた二段階承認を挟み、不可逆処理には直結させない
• DLP は最終防衛線として常に有効にしておき、三層で検出漏れを構造的に減らす

DLP 単独では補えない文脈判断を Gemini で担わせ、外部ツールを持ち込まずに済むこの設計は、GWS 環境に統合されたセキュリティを求める情シス担当者の選択肢になります。まず既存フォームのうち「フリーテキストかつ外部共有リスクがある申請」を1本選んでパイロット適用することが、次の一手です。

コーポレートITのご相談はお気軽に

この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。 「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。