17
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

セキュリティ職が生成AIに相談するときの「マスクのしかた」ざっくりメモ

Last updated at Posted at 2025-12-22

こちらは シーエー・アドバンス Advent Calendar2025 22日目の記事です。

はじめに

ごきげんよう。
シーエー・アドバンス(CAAD)技術統括本部セキュリティチームの @asami-H-Ishi です。
2016年10月に入社してから、脆弱性診断員としての業務を経験した後、診断の調整業務や支援業務に携わってきました。
直近では支援チームのリーダーを担当し、2025年11月からは調整チーム専任として動いています。

毎年Qiitaのアドベントカレンダーでは、その年に自分の業務でやってみたこと・工夫したことをまとめています。
今年は「生成AIを業務で使うとき、セキュリティ職として気をつけていること」をざっくり共有します。

セキュリティを意識すると生成AI使うの億劫じゃない?

生成AI、便利ですよね。
ただ、プライベートでも気をつけなければいけませんが、業務に関する情報をそのまま渡して活用することはできません。
脆弱性診断やその調整/支援業務をやっていても、そのまま貼ってはいけない情報がとても多いです。

でも、使わないより使った方が早い仕事ってたくさんあります。

  1. Slackやメール等で送る依頼文の下書き作成
  2. 追加ヒアリング項目の洗い出し
  3. やり取りの要約
  4. 議事録の整形   などなど……。

生成AIを活用してちょっとの時間を短縮することで、これまで着手できずにいた緊急度が次点以降だったタスクに取り組む時間を捻出できます。
そのために、生成AIへ渡せる形に情報を加工する必要がありますが、慣れないとそこがネックになってしまいがちです。

というわけで、この記事は、毎日忙しいけどどうにか時間を作って自分やチームメンバーを楽にしたい人のヒントになれればいいな、と思ってまとめたマスキングざっくりメモです。

結論:ざっくりマスキングのお作法

わたしがやっているのはこの2つです。

1. 固有名詞を消す

顧客名、サービス名、担当者名、案件名などは、そのまま渡しません。

顧客名 → 顧客A
サービス名 → サービスB
依頼者/担当 → 担当C

固有名詞を消しても、相談したい内容の大半は残ります。

2. URLや構成は「構造」だけ残す

https://example.com/admin/login みたいな情報は、ドメインを捨ててパスの種類だけ残します。

https://{domain}/{role}/{function} とか /api/{location}-{id_number} などです。

「どの種類の画面の話か」だけわかれば、文章作成や観点洗い出しの相談はだいたい成立します。

絶対に貼るのを避ける情報

わたしが上の1、2で消したり残したりする対象としているのはこういう情報です。

  • 認証情報・トークン・キー類(ID/PW、セッション、APIキー、Cookie、秘密鍵など)
  • 特定に直結する情報(顧客名、ドメイン、IP、社内システム名、画面キャプチャ)
  • 未公開の詳細な脆弱性情報や生ログ(そのまま再現できる粒度の手順・ログ)

「これ貼っていいのかな?」と迷うものは、だいたい貼らない方が安全です。
全部 { } で括って置き換えてしまうか、まるっと載せないか、です。

その上で、こういう構成で生成AIに依頼する

最低限この形式で送ります。

目的:
前提:
制約:
欲しい出力:

「目的」は「プロジェクト担当者に追加でヒアリングしたい」など。
「前提」は抽象化して書きます。
「制約」はやらないこと、入れない情報について指定します。
「欲しい出力」は何かテンプレがあるならそれを渡し、長さ(300字前後など)や、必要に応じて「取引先に送るビジネスメール形式で」などのトーンを指定します。

他にも、自分の用途に合わせたテンプレを生成AI自身に出力させて利用するといいです。
わたしも用途に応じてテンプレを作成させて、それをローカルにメモして活用しています。

注意:AIは“それっぽく断定する”ので、ここは必ずチェックする

忙しいときほどAIの出力をそのまま使いたくなりますが、わたしは最低限ここだけ見ます。

  • 断定してないか
    • 「原因はこれです」「確実に脆弱性です」みたいな言い切りが出たら要注意
    • その回答を 事実ではなく仮説(候補) として扱う
    • チケットや顧客向け文面に転記する場合も、断定表現は消して「可能性」「要確認」に戻す
  • 前提を勝手に足してないか
    • 環境や設定、権限などを勝手に補完して書いてくることがある
    • AIの断定は、だいたい「前提の補完」か「一般論の混同」
      • 前提:環境、設定、権限、再現条件、対象範囲は何か
      • 根拠:それを裏付ける観測(レスポンス差分、ログ、画面挙動、ツールの検出内容)は何か
      • 不足:確認しないと判断できない点は何か
  • 上記の「断定」と「前提補完」がみられた場合のプロンプト例
    • 「断定をやめて、前提・根拠・未確認点・追加で確認すべきことに分解して箇条書きにして」
    • 「原因候補を3つ挙げて、それぞれ検証方法を最短手順で出して」
    • 「この主張が誤りになる反例を挙げて」

絶対に人がやること:送信前に必ず人が整える

ここまでで、自分でいちから作文するより、確実に整理され必要情報がまとまった文章を出力させています。
やり取りの往復回数も節約できているからこそ、その内容はきちんと理解し、自分の言葉に置き換えてから送信した方がいいです。
生成AIによる文章には癖があるので、活用している人ほど「これ生成AIっぽい文章だな」と勘付きます。
「活用している」と捉えられるか「手抜きしてる」と捉えられるかはこの一手間にかかってくると思います。

まとめ

わたしが生成AIに相談するときに気をつけているのは、

  • 固有名詞と機微情報を消す
  • 構造だけ残す
    の2つで、必須事項は
  • 送信前に必ず人が書き直す
    の1つだけです。

これだけでも、脆弱性診断のための調整業務の文章作成や確認観点の整理、メモの並べ替えには十分使えます。

もちろん、所属組織のルールや契約条件が最優先です。

この記事が、セキュリティを意識して生成AI利用を億劫に思っている方のヒントになれば嬉しいです。

17
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
17
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?