AIを使う仕事のセキュリティ対策：最初のチャットからリリースまで

// 01 · レベル1／6 · AIを安全に使う

AIとやりとりする

起こりうること

ここでのリスクのほとんどは、AIに何を渡すかです。顧客の名前、メール、契約書、誰かの履歴書、社内の戦略資料。一度チャットに入れたら、他社のシステムに置かれることになります。ツールや設定によっては、保存されたり、学習に使われたり、何か月も前にオンにしたまま忘れていたコネクタから読まれたりする可能性があります。

チェック項目

1. このツールは、この種類のデータに使ってよいと承認されていますか？仕事のデータは、たまたま開いているツールではなく、会社が承認したツールに入れます。
2. 人や取引先を特定できる情報が含まれていませんか？含まれていれば、入力する前に削除するか置き換えます（名前は役職に、正確な数字はおおよその数字に）。
3. プライバシー設定を確認しましたか？チャットが学習に使われるか、どのくらいの期間保存されるか、メモリに何が保存されるか。
4. どのコネクタがオンになっていて、それぞれ何を読めますか？メールやドライブにつながるコネクタがあるなら、AIもそこを読めるということです。

対策

// 02 · レベル2／6 · AIを安全に使う

AIでものを作る

起こりうること

AIを使えば、すぐに何かを公開できてしまいます。小さなミスが紛れ込むのは、そういうときです。URLを知っていれば誰でも開ける「非公開」リンク。契約上使えないはずのクライアント名が入った提案書。自分のメモやフォルダのパス、誰かの名前が中に残ったまま共有したファイル。あるいは、他社の資料やデザインに似すぎているもの。

チェック項目

1. 誰が開けますか？思い込みではなく、共有設定そのものを確認します。
2. 契約違反になったり、法的なリスクが生じたりするものは含まれていませんか？たとえば、使ってはいけないクライアント名など。
3. 受け取る人の立場で、全体を読みます。スピーカーノート、非表示のスライド、コメント、ファイル名も含めて。
4. 消し忘れを検索します。「lorem」「TODO」「test」「example.com」、自分の名前、クライアント名、ファイルのパス。

対策

// 03 · レベル3／6 · AIを安全に使う

AIに自分のPCで作業させる

起こりうること

AIエージェントがファイルを読み、コマンドを実行できるようになると、チャットには決して貼り付けないファイルも読めるようになります。APIキーの入った.envファイル、SSHキー、クラウドの認証情報などです。何かを削除するコマンドを実行することもあれば、説明にない動作までするパッケージをインストールすることもあります。特に軽く見られがちなのがパッケージです。AIが1つ提案し、承認したとたん、中身を確認する前にインストールスクリプトがPC上で実行されます。AIは存在しないパッケージ名を提案することもあり、攻撃者はその名前を登録しておき、次にその提案を受け入れた人に自分のパッケージを入れさせます。

チェック項目

1. AIはシークレットを読めますか？読めないようにするべきです。プロンプトでお願いするより、ツールの設定にルールを書くほうが確実です。
2. 必ず確認を求めるべきコマンドはどれですか？ファイルの削除、コードのプッシュ、デプロイ、お金がかかる操作すべてです。
3. パッケージをインストールする前に：本物か（入手元のドキュメントと1文字ずつスペルを照らし合わせる）、メンテナンスされているか、誰が公開しているか、インストール時にスクリプトを実行するか。
4. ロックファイルはコミットされていますか？毎回同じバージョンがインストールされるようにするためです。
5. AI向けのスキルやプラグインもパッケージです。インストールする前に、SKILL.mdを読み、セキュリティ監査の結果を確認します。2月にSnykが公開されているエージェントスキル3,984件をスキャンしたところ、76件で悪意のあるペイロードが確認されました。Vercelのskills.shでは現在、各スキルのページにSnyk、Socket、Genによる監査結果が表示されています。

対策

{
  "permissions": {
    "deny": [
      "Bash(env)",
      "Bash(env:*)",
      "Bash(printenv)",
      "Bash(printenv:*)",
      "Read(**/.env)",
      "Read(**/.env.*)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)"
    ]
  }
}

default_permissions = "protect-secrets"

[permissions.protect-secrets]
extends = ":workspace"

[permissions.protect-secrets.filesystem.":workspace_roots"]
"**/.env" = "deny"
"**/.env.*" = "deny"
"**/*.env" = "deny"

[permissions.protect-secrets.filesystem]
"~/.ssh" = "deny"
"~/.aws" = "deny"

// 04 · レベル4／6 · 作ったものを守る

AIで作るアプリ

起こりうること

AIは、動くアプリを作るのはとても得意ですが、守りの固いアプリを作るのはそれほど得意ではありません。よくある穴は、誰でも見られるフロントエンドのコードに置かれたキー、ログインしているユーザーなら誰でも（あるいはアプリの公開キーを持っていれば誰でも）全行を読めるデータベース、そして入力された内容をそのまま信用するフォームです。

チェック項目

1. シークレットはサーバーか環境変数に置き、フロントエンドのコードやgitの履歴には絶対に置かない。
2. すべてのテーブルにアクセスルールがある。この行を誰が読めて、誰が変更できるか。Supabaseでは行レベルセキュリティ（RLS）がこれにあたり、すべてのテーブルで有効にしておくべきです。
3. ブラウザから送られてきたID、ロール、価格は信用しない。ユーザーが誰なのかは、サーバー側でセッションから判断する。
4. ユーザーから入ってくるものはすべてサーバー側で検証し、ユーザーが入力したものをそのままHTML、URL、SQLに入れない。

対策

alter table notes enable row level security;

create policy "Read own notes" on notes
  for select using ((select auth.uid()) = user_id);

create policy "Change own notes" on notes
  for update using ((select auth.uid()) = user_id)
  with check ((select auth.uid()) = user_id);

// 05 · レベル5／6 · 作ったものを守る

プロダクトに組み込むAI

起こりうること

プロダクトにモデルを組み込むと、モデルが読むものすべてが、モデルに指示を出そうとする可能性があります。これがプロンプトインジェクションです。ユーザーから直接来ることもあれば、メールやWebページ、アップロードされたファイルなど、モデルが読むコンテンツの中に隠れていることもあります。たとえば、届いたメールを読むサポートアシスタントに、直近10件の請求書を外部のアドレスに転送するよう求める一文が隠されたメールが届くかもしれません。プロンプトインジェクションは、多くのチームが基準にしているOWASP Top 10 for LLM Applicationsで1位です。2026年版は8月に公開され、上位3つはプロンプトインジェクション、機密情報の漏えい、Excessive Agency（過剰なエージェンシー：必要以上に行動できる力を与えられたモデル）です。Excessive Agencyは3位に上がりました。モデルに与えられるツールが増えるなかで、リスクがどこに向かっているかをはっきり示しています。

チェック項目

1. モデルが読むものはすべて、見知らぬ人から来たものとして扱う。実際にそうかもしれないからです。ツールの結果、取得したページ、アップロードされたファイル、他のユーザーが書いた行も、すべて含みます。
2. 判断と実行を分ける。信頼できないコンテンツを読むことと、それに基づいて権限が必要な操作をすることを、1つのステップでさせない。読んで、結果をコードで検証してから、実行する。
3. モデルの出力を、そのままコード、データベースのクエリ、コマンドとして実行しない。信頼できるHTMLとして表示しない。
4. 各ツールには、その仕事に必要な最小限のアクセスだけを与え、デフォルトは読み取り専用にする。チケットを要約するツールに、チケットを閉じる権限はいりません。
5. 取り消しにくい操作（削除、権限の変更、メッセージの送信、決済、一括エクスポート）には、人の承認を必要とする。
6. シークレットや他人のデータを、プロンプトに入れない。

対策

// 06 · レベル6／6 · 作ったものを守る

見落としを拾うパイプライン

起こりうること

ここまでの内容はすべて、誰かが覚えていることが前提です。パイプラインは、誰かが忘れた日のためにあります。パイプラインがなければ、キーがコミットされたり、脆弱性のあるパッケージがマージされたり、誰もきちんとレビューしていない変更がそのまま本番環境に入ったりします。

チェック項目

1. すべての変更をレビューする。AIのレビューはあくまでダブルチェック役で、それだけに頼らない。
2. CIで、依存関係のチェック（npm auditやcomposer audit）、シークレットスキャン、テストを実行する。
3. より深いセキュリティレビューは、必要な場面で行う。リリース前と、影響の大きい変更のときです。
4. デプロイの前に、決められた担当者が承認する。

対策

すべてのレベル

最新の状態を保つ

チェック項目

1. 使っているバージョン（Node、PHP、フレームワーク）を把握していますか？それはまだサポートされていますか？
2. 新しいセキュリティ情報を、どこで知りますか？公式のセキュリティリリースのページとGitHubのセキュリティアドバイザリ、そしてリポジトリの依存関係アラートです。
3. パッチはどのくらいの速さで当てていますか？インターネットに公開しているものの重大な脆弱性なら、「次のスプリント」ではなく、数日以内です。
4. 新しいものをインストールする前に、特にAIが提案したものなら、レベル3のパッケージチェックを行う。

対策

技術ブログ、X、同僚やパートナーから、最初に問題を知ることもよくあります。リポジトリの依存関係は、Dependabotがカバーします。