こんにちは、株式会社TIMEWELLの濱本です。
9月30日の前編でも書いたとおり、侵入の入口は、外から見える機器の脆弱性と、IDや認証の弱さが中心です。社内のシステムを守る作業の多くは、新しい製品を買うことではなく、すでに使っているサービスの、IDの管理、管理者の権限、外部アプリとの連携といった設定を見直すことです。
この記事では、多くの会社が使っている4つを取り上げます。Google Workspace、Apple Business、Claude Code、そしてブラウザで動くAIエージェントです。それぞれの公式ドキュメントとOWASPをもとに、何を、どの順番で見直すかを整理します。画面の操作手順を網羅する記事ではありません。設定の考え方と、優先順位を書きます。数字や仕様は、2026年10月20日時点で確認できたものです。
Google Workspace。管理者アカウントから固める
Googleは、中規模・大規模の企業向けに、セキュリティチェックリストを公開しています。1 項目は多いのですが、優先順位をつけるなら、私は次の順だと考えます。
1. 管理者アカウントを分ける。
Googleの管理者アカウントのベストプラクティスは、スーパー管理者を、複数の担当者に分けて用意するよう勧めています。1つのアカウントが失われても、別のスーパー管理者が重要な作業を続けられるようにするためです。そのうえで、スーパー管理者は、管理用のアカウントと、日常業務用の一般アカウントの2つに分けます。たとえば、admin-maria@example.comとmaria@example.comのようにします。スーパー管理者は、必要な作業のときだけサインインし、終わったらサインアウトします。常時サインインしていると、フィッシングの被害を受けるリスクが高くなるとされています。2
日常的な管理作業は、権限を絞った管理者ロールを持つ一般アカウントに任せます。ユーザーの作成とパスワードのリセットは許可しても、ユーザーの削除は許可しない、というように、最小権限で渡します。2
2. 2段階認証を必須にし、フィッシングに強い方式を使う。
チェックリストは、ユーザーに2段階認証を求めること、そして、少なくとも管理者などの重要なアカウントには、フィッシングに強い物理的なセキュリティキーを求めることを挙げています。1 管理者向けのページは、セキュリティキーを「2段階認証のなかで最も安全な方式」と位置づけ、予備のキーを複数登録して、安全な場所に保管するよう勧めています。2 復旧用の電話番号とメールアドレス、事前に作って印刷したバックアップコードも、用意しておきます。
3. サードパーティアプリのアクセスを、承認制にする。
GmailやDriveなどのコアサービスにアクセスできるアプリを把握して、承認したものだけを許可します。OAuthなどの最新の標準を使わない、安全性の低いアプリは止めます。信頼済みのアプリの許可リスト(allowlist)を作ることも、挙げられています。1 従業員が自分の判断で連携したアプリが、会社のメールやファイルへの入口になっていないかを、一度確かめる価値があります。
4. 共有の既定値を、厳しめにする。
Driveでは、組織外への共有をオフにするか、信頼ルールで制御します。公開Webへの共有は禁止し、一般アクセスの既定値は「制限付き」にします。ドメイン外に共有するときは、ユーザーに警告を出します。機密データ(パスポート番号など)を含むファイルの外部共有は、DLPでブロックまたは警告できます。1
5. メールの認証と、自動転送の制御。
Gmailでは、SPFとDKIMで送信元を認証し、DMARCで未認証メールの扱いを定めます。自動転送は無効にし、IMAPとPOPは必要なユーザーだけに許可します。1 メールの認証の詳細は、DKIMリプレイ攻撃とDNS設定の記事で書いています。
6. 退職者のアクセスを、確実に切る。
退職時に、組織のデータへのアクセスを取り消します。侵害の疑いがあるときや退職者に対しては、Google Takeoutでのデータの一括ダウンロードを止めることも、チェックリストに挙がっています。1
7. 見張る仕組みを入れる。
アクティビティレポートとアラートで、アカウントの状態、管理者権限、2段階認証の登録状況を定期的に確認します。管理者向けのメールアラートを設定し、不審なサインインや管理者による変更を検知します。管理者の操作は、監査ログで、誰が、いつ、どのIPアドレスから行ったかを確認できます。12
なお、IPアドレスや端末の状態などの条件でアクセスを制御するコンテキストアウェアアクセスは、チェックリストに挙がっています。1 利用できる契約の種類に条件があるため、自社の契約を確かめてから検討してください。
Apple Business。端末と「会社のApple Account」を管理下に置く
Appleの公式ドキュメントは、組織向けの管理の入口として、Apple Businessのポータルを案内しています。このポータルには、組織向けに無償で提供される、組み込み型のデバイス管理サービスが含まれています。対象は、iPhone、iPad、Mac、Apple TV、Apple Vision Proです。3
1. 端末を、購入時から管理下に入れる。
組織が購入したApple製デバイスは、ユーザーが受け取る前に、デバイス管理サービスへ自動で登録できます。購入元は、Apple、正規の再販業者、携帯通信事業者のいずれかです。この仕組みを使うと、個人の端末を後から管理下に入れる手間なく、会社の標準の設定を、最初から入れられます。登録時には、管理対象のApple Accountによる認証が必要です。3 運用上の注意として、デバイス管理サービスのトークンは1年で失効するので、期限の前に、ポータルで新しいトークンを作る必要があります。3
2. 管理対象のApple Accountで、会社のIDと個人のIDを分ける。
管理対象のApple Accountは、組織が設計・所有・管理するアカウントで、個人が自分で作るApple Accountとは別のものです。組織のデータと個人のデータを分けて、組織のデータを守りやすくする目的があります。作り方は、手動での作成、Google WorkspaceやMicrosoft Entra IDなどのIDプロバイダーとのフェデレーション認証、同期の3通りです。アカウントは、組織が所有するドメイン名を使うように設計し、ドメインは、サブドメインごとに別々に追加します。Appleは、管理対象のApple Accountについて、ISO 27001とISO 27018の認証を維持しています。4
Google Workspaceを使っている会社は、Workspaceのアカウントを、そのまま管理対象のApple Accountの認証元にできます。ID管理を一本化できる点は、大きな利点です。
3. Macのディスクを、暗号化した状態にする。
デバイス管理サービスを使うと、セットアップアシスタントの途中で、FileVaultをオンにすることを必須にできます。個人用の回復キーは、ユーザーに表示するか、デバイス管理サービスにエスクローするかを選べます。macOS 26.4以降では、セットアップ中にFileVaultが既定でオンになります。それでも、回復キーのエスクローと、ユーザーがあとからオフにできないようにする目的で、管理の設定は意味を持ちます。5 紛失・盗難のときに、データを読まれない状態にしておくための、最も基本的な備えです。
4. 高リスクの人には、Lockdown Modeも。
Lockdown Modeは、標的型の攻撃を受ける可能性が高い人向けの、任意の強い保護機能です。全社員に入れるものではありません。経営層や、機密情報を扱う担当者など、狙われやすい人に絞って検討するのが現実的です。なお、デバイス管理サービスがLockdown Modeの状態を確認できる機能は、発売前のiOS 27などの情報で、最終版までに変わる可能性があります。6
AIセキュリティ研修を、本気で
OWASP・NIST・ISO 42001・経産省ガイドライン全準拠の2日間集中講座。経営層と現場で分けて受講できます。
Claude Code。権限と信頼の境界を決める
Claude Codeは、コマンドの実行やファイルの編集ができるAIエージェントです。公式のセキュリティドキュメントは、権限の仕組みと、守りの考え方を説明しています。7
1. 権限モードを、組織で決める。
手動モード(Manual)では、読み取り専用から始まり、ファイルの編集やコマンドの実行の前に、ユーザーの承認を求めます。自動モード(Auto)では、別の分類器のモデルが、行動を確認して、危険と判断したものを止めます。組織は、自動モードをオフにすることもできます。ユーザーが明示的に決めた許可・拒否のルールは、どのモードでも適用されます。7
2. ネットワークに出るコマンドを、制限する。
curlやwgetのような、Webから内容を取ってくるコマンドは、既定では自動承認されません。実行させたくない場合は、拒否のルール(permissions.deny)に入れます。ただし、拒否のルールは、書かれたとおりのコマンド文字列に一致するものです。コマンドの書き方に左右されずに、ネットワークを制限したい場合は、サンドボックスのネットワーク分離を使います。7
3. サンドボックスを使う。
Bashのコマンドを、ファイルシステムとネットワークから隔離して実行できます。承認の確認を減らしながら、安全性を保つための仕組みです。作業ディレクトリの境界は、承認の確認として働くもので、承認したBashコマンドは、ユーザーのアカウントが書ける場所のどこにでも書けます。OSのレベルで制限したい場合は、サンドボックスを有効にします。7
4. 信頼できないものを、直接渡さない。
ドキュメントは、信頼できないコンテンツを、そのままClaudeに渡さないこと、提案されたコマンドは承認の前に確認すること、重要なファイルへの変更は検証することを勧めています。外部のWebサービスとやり取りするスクリプトやツール呼び出しは、仮想マシンの中で実行するのが望ましいとされています。また、リポジトリを初めて開くときの「信頼するか」の確認は、そのフォルダのファイルが実行できることを、承認する意味を持ちます。-pで起動した非対話のセッションでは、この確認も、MCPサーバーの承認の確認も、表示されません。7
5. MCPサーバーは、信頼できる提供元に限る。
MCPサーバーは、AIに外部のツールやデータをつなぐ仕組みです。ドキュメントは、自分で書くか、信頼できる提供元のものを使うよう勧めています。Anthropicは、ディレクトリに載せるコネクタを審査していますが、MCPサーバーのセキュリティ監査や管理は、していません。組織で使えるサーバーを絞るには、管理されたMCP設定(Managed MCP configuration)があります。7
6. 管理設定と監視で、組織の標準を強制する。
チームでの使い方として、管理設定(managed settings)で組織の標準を強制すること、承認済みの権限設定をバージョン管理で共有すること、利用状況をOpenTelemetryで監視すること、セッション中の設定変更を、フックで監査またはブロックすることが挙がっています。7 開発者の自己管理に任せず、組織として標準を決めて、配る形にします。
ブラウザエージェント。「情報を取られる」仕組みを理解する
ブラウザの中でAIが動き、Webページを読み、フォームに入力し、操作を代行する。便利な一方で、特有の危険があります。
仕組み上の問題
OWASPは、プロンプトインジェクションを、LLMの上位のリスクとして整理しています。そのうち「間接プロンプトインジェクション」は、Webサイトやファイルなど、外から取り込んだコンテンツに仕込まれた指示を、モデルが解釈して、振る舞いが変わるものです。影響として、機密情報の開示、LLMが使える機能への不正なアクセス(権限の悪用)、連携先のシステムでの任意のコマンドの実行が挙げられています。影響の大きさは、モデルに与えられた権限に大きく左右されます。完全な防止策は確立されていない、とも書かれています。8
ブラウザエージェントでは、AIが、利用者のログイン済みのセッションで動き、Webの内容を読みます。そのWebページに、攻撃者の指示が隠れていれば、AIがそれに従って、情報を外に出したり、操作をしたりするおそれがあります。人間の目には見えない形(隠した文字など)でも、モデルが読めれば影響します。8
どの程度、実際に起きているのか
Googleは、2026年4月23日に、公開Webを調べた結果を公表しています。Common Crawlを使い、定型句のパターンから検出し、Geminiで意図を分類し、最後に人が確かめる方法です。2025年11月から2026年2月にかけて、悪意のカテゴリの検出は、相対的に32%増えました。ただし、検出の多くは、研究論文や教育記事などの無害な例でした。悪意のあるもののなかで、データ窃取の試みは件数が少なく、洗練度も低いとされ、ファイルの削除を狙う破壊的な指示も見つかっています。Googleの結論は、攻撃者は、実験的に試している段階で、研究成果を大規模に実用化してはいない、というものです。一方で、増加の傾向と、エージェント型AIで攻撃のコストが下がる可能性から、規模と高度化は進むと予測しています。9
つまり、「いま、広く情報が盗まれている」と断定できる状況ではありません。ただ、「起きるはずがない」とも言えません。備えを始める理由は、十分にあります。
提供元が示す対策と、残るリスク
AnthropicのClaude in Chromeのヘルプは、権限モード(手動の承認、自動の承認)、受け取るコンテンツを調べる分類器と、実行前に各操作を調べる分類器の2種類、サイト単位の制御を説明しています。高リスクのサイトへのアクセスは禁止され、金融サイトでは、アクセス前に許可を求められます。社内のテストでは、攻撃の成功率を0.08%未満に抑えたとされています(同社の値で、第三者の検証ではありません)。それでも、ヘルプには、「リスクはゼロではない」と明記されています。10
組織の管理者は、許可するサイトと禁止するサイトのリストを設定でき、組織全体で拡張機能をオン・オフできます。機密データを扱う組織には、厳格な許可リストが勧められています。10
社内のルールにすること
提供元の説明とOWASPの緩和策から、社内のルールとして決めておきたいことを挙げます。
- 機密性の高い業務には使わない。 ヘルプも、金融口座の管理、法的文書の処理、医療情報の処理、機密情報を含む業務アカウントでの利用は、避けるよう強く勧めています。10
- 別のブラウザプロファイルを使う。 銀行、医療、政府などのアカウントにログインしていないプロファイルで、ブラウザエージェントを動かします。10
- 操作の承認は、手動にする。 特に、初めて使うサイトや、データの送信、購入、投稿など、取り返しのつかない操作では、人が確認します。OWASPも、高リスクな操作に、人の承認を入れることを挙げています。8
- 許可するサイトを絞る。 管理者が、許可リストで、使えるサイトを限ります。10
- 権限を、最小にする。 AIに渡す権限は、業務に必要な最小限にします。8 認証情報は、AIに直接渡さず、パスワードマネージャーの連携を使う方法があります。10
- 信頼できない内容を、読ませない。 外部のメールや、出どころの分からないWebページを、AIに要約させる使い方は、間接プロンプトインジェクションの入口になります。
3つの条件がそろうと危険が大きくなる、という考え方があります。AIが私的なデータにアクセスできること、AIが信頼できない内容を読むこと、AIが外部に送信できること。この3つのどれかを外せば、危険は小さくなります。私の整理です。たとえば、読むだけのブラウザエージェントなら、外部への送信を止めます。
優先順位。まず何から手をつけるか
4つを一度にやる必要はありません。私なら、次の順で進めます。
- Google Workspaceの管理者アカウントを分け、セキュリティキーを入れる(今週)
- Workspaceのサードパーティアプリの承認制と、外部共有の既定値を見直す(今月)
- Macにデバイス管理を入れ、FileVaultとApple Accountを管理下に置く(今月から来月)
- Claude Codeの権限モードと、ネットワークの制限、MCPの許可範囲を、組織で決める(今月)
- ブラウザエージェントの利用ルールを書く。機密業務には使わない、別プロファイル、手動の承認(今月)
まとめ
社内システムの備えの中心は、新しい製品ではなく、すでにあるサービスの設定です。Google Workspaceは管理者アカウントから、Apple Businessは端末とIDの管理から、Claude Codeは権限とサンドボックスから、ブラウザエージェントは、使う範囲を絞るところから固めます。
ブラウザエージェントについては、まだ広く悪用されている状況ではありません。ただ、仕組み上の問題は、提供元も、OWASPも、認めています。新しい技術は、使い始める前にルールを決めておくほうが、あとから直すより、ずっと楽です。
社内の設定の点検や、社員向けのルールづくりについて相談したい方は、WARP SECURITYの個別相談からお声がけください。各社の仕様は変わるため、続報や仕様の変更があれば、この記事を更新します。
参考
Footnotes
-
Security checklist for medium and large businesses (100+ users) — Google Workspace Help ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8
-
Security best practices for administrator accounts — Google Workspace Help ↩ ↩2 ↩3 ↩4
-
Deploy devices with Apple School Manager or Apple Business — Apple Support ↩ ↩2 ↩3
-
WWDC26 device management updates(発売前の情報を含む)— Apple Support — 2026年6月8日 ↩
-
LLM01:2025 Prompt Injection — OWASP GenAI Security Project ↩ ↩2 ↩3 ↩4
-
AI threats in the wild: The current state of prompt injections on the web — Google — 2026年4月23日 ↩
-
Use Claude in Chrome safely — Claude Help Center — Anthropic ↩ ↩2 ↩3 ↩4 ↩5 ↩6






