G-gen の堂原です。当記事では、 Google Workspace の Gmail で、メールの送受信を特定のメールアドレスやドメインとの間にだけ許可し、それ以外は制限する方法について解説します。 はじめに 当記事について 仕様 手順1 : アドレスリスト作成 手順1-1 : アドレスリストの管理画面への遷移 手順1-2 : アドレスリストの作成 手順2 : 「配信を制限」の設定 手順2-1 : コンプライアンス画面への遷移 手順2-2 : 「配信を制限」の設定 はじめに 当記事について E メールの利用に際して、組織内のユーザーが外部の不特定多数とメールを送受信することを防ぎたいケースがあります。例えば、学校の生徒が持つメールアドレスからは、同じ学校の教師と生徒だけと送受信できるようにするケースが考えられます。 Google Workspace の Gmail には「 配信を制限 」という機能があります。これを利用することで、管理者が許可した特定のメールアドレスやドメインとのみ送受信できるようにし、それ以外は禁止するように構成できます。当記事では、「配信を制限」機能の設定方法を紹介します。 参考 : メールの送受信を承認済みアドレスまたはドメインのみに制限する - Google Workspace 管理者 ヘルプ 仕様 「配信の制限」設定を行うと、対象の 組織部門 に所属するユーザーは、指定されたアドレスリストに含まれない送信元からのメールを受信できなくなり、またアドレスリストに含まれない宛先へメールを送信できなくなります。 制限に抵触した場合、送信元のメールアドレスには バウンスメール が返送されます。 バウンスメール例 手順1 : アドレスリスト作成 手順1-1 : アドレスリストの管理画面への遷移 まずは、送受信を許可したいドメインやメールアドレスを設定した アドレスリスト を作成するために、「アドレスリストの管理画面」へ遷移します。 管理コンソール（ https://admin.google.com/ ）にログイン 左のサイドバーの「アプリ」をクリック 「Google Workspace」をクリック 「Gmail」をクリック 「Gmail の設定」に遷移するため、設定項目にある「ルーティング」をクリック 「アドレスリストの管理」は最上位の組織部門でしか設定できないため、最上位の組織部門を選択 「アドレスリストの管理」をクリック 手順1-2 : アドレスリストの作成 「アドレスリストの管理」画面にて、アドレスリストを作成します。 「アドレスリストの管理」にて、「アドレスリストを追加」をクリックします。 「アドレス」に送受信を許可したいアドレスとドメインを入力します。注意点として、メールの送信に失敗した際に送信元に送られてくるバウンスメールを受信するためには、 mailer-daemon@googlemail.com を許可する必要があります。 手順2 : 「配信を制限」の設定 手順2-1 : コンプライアンス画面への遷移 「配信を制限」設定は「Gmail の設定」の「コンプライアンス」画面にあるため、まずはそこまで遷移します。 左のサイドバーにて、「アプリ」をクリック 「Google Workspace」をクリック 「Gmail」をクリック 設定項目にある「コンプライアンス」をクリック 手順2-2 : 「配信を制限」の設定 「配信を制限」の設定画面を開きます。 メールの送受信を制限したい組織部門を選択 「配信を制限」欄にある「設定」をクリック 以下が「配信を制限」の設定画面です。 メールの送受信を許可したいアドレスリストを 1. の箇所に追加します。 2. の箇所に入力した文言は、バウンスメール管理者からのメッセージとして記載されます。 再掲 : バウンスメール例 3. にチェックを付けた場合、同じドメインの Google Workspace アカウント（今回だと dev.g-gen.co.jp ）に対して送信するメールは、「配信を制限」設定の影響を受けなくなります。すなわち、組織のドメインをアドレスリストに追加していなくても、組織内であればメールの送受信が可能です。 堂原 竜希 (記事一覧) クラウドソリューション部クラウドエクスプローラ課。2023年4月より、G-genにジョイン。 Google Cloud Partner Top Engineer 2023, 2024, 2025に選出 (2024年はRookie of the year、2025年はFellowにも選出)。休みの日はだいたいゲームをしているか、時々自転車で遠出をしています。 Follow @ryu_dohara

G-gen の三浦です。当記事では、Gemini CLI から Google SecOps MCP server を使用して、ケース確認からログ調査までを自然言語で要約した検証結果を紹介します。 前提知識 Google SecOps とは Gemini CLI とは 概要 Google SecOps MCP server とは 使用可能なツール 注意点 検証手順 事前準備 IAM 権限の付与と MCP サーバーの有効化 Customer ID の確認 Gemini CLI の設定 ケース運用 未対応のケース一覧の取得 高優先度ケースの抽出と要約 関連アラートの確認と影響範囲の確認 検索・調査 特定ユーザーの Google Workspace 操作ログ調査 AWS 特権ユーザーの操作ログ調査 前提知識 Google SecOps とは Google Security Operations （以下 Google SecOps、旧称 Chronicle）は、Google Cloud が提供する 統合セキュリティ運用プラットフォーム です。 SIEM、SOAR、脅威インテリジェンス、Gemini を利用した AI による運用支援を提供します。これらにより、脅威の検知・調査・対応を一元的に行えます。結果として、セキュリティ運用の効率化と高度化を実現できます。 参考: Google SecOps の概要 詳細は、以下の記事をご参照ください。 blog.g-gen.co.jp Gemini CLI とは Gemini CLI とは、ターミナルから直接 Gemini の機能を利用できるオープンソースのコマンドラインインターフェイスです。詳細は以下の記事をご参照ください。 blog.g-gen.co.jp 概要 Google SecOps MCP server とは Google SecOps MCP server は、Google Cloud が提供する Google Cloud MCP Servers の 1 つです。Gemini CLI などの MCP クライアントから、自然言語で Google SecOps を操作することができます。 参考 : Use the Google SecOps MCP server なお Google Cloud MCP Servers では、Google SecOps の他にも、Compute Engine や Google Kubernetes Engine（GKE）、Google Maps などのための MCP サーバーが提供されています。 参考 : Supported products Google Cloud MCP Servers の詳細は、以下の記事や公式ドキュメントを参照してください。 blog.g-gen.co.jp 使用可能なツール Google SecOps MCP server で使用可能な主なツールとユースケースは以下のとおりです。以下は一部抜粋であり、他にも多数のツールがあります。詳細は公式ドキュメントをご確認ください。 カテゴリ ツール ユースケース ケース運用 list_cases , get_case , update_case 未対応ケースの棚卸し、ケース詳細の確認、担当者の更新 検索・調査 translate_udm_query , udm_search , search_entity 検索条件（UDM クエリ）の作成・変換を行い、ログ/イベントを検索して、関連するユーザー/端末/IP などのエンティティを特定 ルール運用 create_rule , list_rules , list_rule_errors 検知ルールの作成と棚卸し、適用・運用上のエラーの把握 取り込み/整備 create_feed , create_parser , list_parsers ログ取り込み設定（フィード）の作成、ログ整形のためのパーサー作成、パーサーの一覧取得 参考 : Google SecOps MCP Reference 注意点 Google SecOps MCP server は、2026年2月現在、 Preview 版 です。当記事で解説する内容は一般提供（GA）の際に変更される可能性があることを予めご了承ください。 Preview 版のサービスや機能を使うに当たっての注意点は、以下の記事も参考にしてください。 blog.g-gen.co.jp 検証手順 検証の流れは以下のとおりです。 項番 項目 内容 1 事前準備 MCP サーバーの有効化、IAM 権限の付与、Customer ID の確認、Gemini CLI の設定 2 ケース運用 未対応ケースの一覧取得、高優先度ケースの確認、関連アラートと 関与したユーザー／IP の確認 3 検索・調査 ケース／アラートで得たユーザーや IP などの手がかりを起点に、Google SecOps に取り込まれたログ（例：Google Workspace / AWS）を検索し、重要な操作を時系列で整理 事前準備 IAM 権限の付与と MCP サーバーの有効化 Google SecOps MCP を実行するプリンシパル（Google アカウント/サービスアカウント）に、SecOps インスタンスが紐付くプロジェクトで以下の IAM ロールを付与します。 MCP ツールのユーザー（ベータ版）（ roles/mcp.toolUser ） Chronicle API 管理者（ roles/chronicle.admin ） Chronicle SOAR 管理者（ベータ版）（ roles/chronicle.soarAdmin ） ※ roles/chronicle.admin と roles/chronicle.soarAdmin は管理者権限相当です。SecOps 運用に必要なメンバーのみに付与することを推奨します。 参考 : Google SecOps MCP Reference SecOps インスタンスが紐付くプロジェクトで、Google SecOps MCP を有効化します。 # SecOps が紐付くプロジェクト ID export PROJECT_ID = " YOUR_PROJECT_ID " 　 gcloud beta services mcp enable chronicle.googleapis.com --project =" $PROJECT_ID " ※ gcloud beta services mcp コマンドが「Invalid choice: 'mcp'」等のエラーで使用できない場合は、gcloud CLI が古い可能性があります。最新バージョンに更新してから再試行してください。 参考 : gcloud CLI のコンポーネントの管理 MCP サーバーを利用できるアカウントでログインし、アプリケーションのデフォルト認証情報（ADC）を設定します。 gcloud auth application-default login Customer ID の確認 本記事で利用する MCP ツールには、Google SecOps の Customer ID が必要なものがあります。Customer ID は Google SecOps コンソールの設定画面から確認できます。 確認手順の詳細は、以下の記事の 「Google SecOps 転送用のパラメータと認証情報の取得」 をご参照ください。 blog.g-gen.co.jp Gemini CLI の設定 Google（Google Cloud）のリモート MCP サーバーは、Gemini CLI では拡張機能として ~/.gemini/extensions/ 配下に設定します。本記事では拡張機能名を secops （任意）とします。 参考 : Configure MCP in an AI application 設定用のディレクトリと設定ファイル（ ~/.gemini/extensions/secops/gemini-extension.json ）を作成します。 mkdir -p ~/.gemini/extensions/secops 　 touch ~/.gemini/extensions/secops/gemini-extension.json 作成した設定ファイルに以下を記述します。 PROJECT_ID と httpUrl のリージョン（例： asia-northeast1 ）は環境に合わせて置き換えてください。 { " name ": " secops ", " version ": " 1.0.0 ", " mcpServers ": { " secops ": { " httpUrl ": " https://chronicle.asia-northeast1.rep.googleapis.com/mcp ", " authProviderType ": " google_credentials ", " oauth ": { " scopes ": [ " https://www.googleapis.com/auth/chronicle " ] } , " headers ": { " x-goog-user-project ": " PROJECT_ID " } } } } Gemini CLI を起動し、 /mcp コマンドで MCP サーバーへの接続を確認します。ツール一覧が表示されれば、接続は成功です。 > /mcp Configured MCP servers: 　 🟢 secops ( from secops ) - Ready ( 57 tools ) Tools: - list_cases - get_case - list_case_alerts - list_case_comments - update_case ...（省略） ケース運用 未対応のケース一覧の取得 以下のようなプロンプトで未対応（OPENED）のケースを直近 10 件取得し、優先度と作成日時の傾向を確認します。 Project ID PROJECT_ID 、Customer ID CUSTOMER_ID 、Region REGION を使用して 未対応のケースを作成日時の新しい順に 10 件表示してください。 # 出力例 　 ✦ 最新の未対応ケース 10 件を取得しました。 　 　 ┌─────────┬──────────────────────────────────────────┬──────────┬────────┬────────┬────────────────────┐ │ Case ID │ Display Name │ Priority │ Stage │ Status │ Created Time ( UTC ) │ ├─────────┼──────────────────────────────────────────┼──────────┼────────┼────────┼────────────────────┤ │ 399 │ Replacement of Existing Compute Snapshot │ LOW │ Triage │ OPENED │ 2026-01-30 09:33 │ │ 398 │ Replacement of Existing Compute Snapshot │ LOW │ Triage │ OPENED │ 2026-01-30 01:33 │ │ 397 │ Replacement of Existing Compute Snapshot │ LOW │ Triage │ OPENED │ 2026-01-29 19:33 │ │ 396 │ Replacement of Existing Compute Snapshot │ LOW │ Triage │ OPENED │ 2026-01-29 13:33 │ │ 395 │ Replacement of Existing Compute Snapshot │ LOW │ Triage │ OPENED │ 2026-01-29 07:34 │ │ 394 │ Replacement of Existing Compute Snapshot │ LOW │ Triage │ OPENED │ 2026-01-28 23:34 │ │ 393 │ Replacement of Existing Compute Snapshot │ LOW │ Triage │ OPENED │ 2026-01-28 15:34 │ │ 392 │ Replacement of Existing Compute Snapshot │ LOW │ Triage │ OPENED │ 2026-01-28 11:33 │ │ 391 │ Replacement of Existing Compute Snapshot │ LOW │ Triage │ OPENED │ 2026-01-28 05:34 │ │ 390 │ Replacement of Existing Compute Snapshot │ LOW │ Triage │ OPENED │ 2026-01-27 23:34 │ └─────────┴──────────────────────────────────────────┴──────────┴────────┴────────┴────────────────────┘ 　 　 すべてのケースが Replacement of Existing Compute Snapshot（既存のスナップショットの置換）という名称で、優先度は LOW です。 高優先度ケースの抽出と要約 以下のようなプロンプトで優先度が高いケースを抽出し、内容を要約して「先に見るべきケース」を絞り込みます。 Project ID PROJECT_ID 、Customer ID CUSTOMER_ID 、Region REGION を使用して、優先度が高いケースを検索し、最新の3件の内容を要約してください。 # 出力例 　 ✦ 優先度が高いケースの最新 3 件を取得し、要約しました。 　 高優先度ケースの要約（最新 3 件） 　 検出されたケースはすべて、Workspace 管理者による 2 要素認証（2FA）の強制設定解除に関するもので、内容は以下の通りです。 　 1 . Two Factor Authentication Enforcement Removal by a Workspace Admin User ( Case ID: 137 ) * 優先度: PRIORITY_HIGH * 作成日時: 2025 / 11 / 27 19:06:23 ( UTC ) * 概要: 管理者ユーザーによって 2 要素認証の強制設定が解除されました。セキュリティポリシー違反の可能性があるため、意図した変更か確認が必要です。 　 2 . Two Factor Authentication Enforcement Removal by a Workspace Admin User ( Case ID: 135 ) * 優先度: PRIORITY_HIGH * 作成日時: 2025 / 11 / 27 10:18:07 ( UTC ) * 概要: 管理者による 2FA 強制解除が検知されました。アラートが 2 件紐付いており、繰り返しのアクションや関連操作があった可能性があります。 　 3 . Two Factor Authentication Enforcement Removal by a Workspace Admin User ( Case ID: 131 ) * 優先度: PRIORITY_HIGH * 作成日時: 2025 / 11 / 26 13:33:44 ( UTC ) * 概要: 同様の 2FA 解除検知です。短期間に複数発生しているため、アカウント侵害や誤設定の影響範囲を確認してください。 　 管理者権限に関わる重要な変更であるため、早急な確認を推奨します。 関連アラートの確認と影響範囲の確認 以下のようなプロンプトで、前項で確認した Case ID 137 に紐づくアラートを取得し、 「誰が／どこから／何に対して」 の観点で影響対象を整理します。 Project ID PROJECT_ID 、Customer ID CUSTOMER_ID 、Region REGION を使用して、Case ID 137 に関連するアラートを取得し、影響対象と影響範囲を整理してください。 # 出力例 　 ✦ Case ID 137 に関連するアラート情報、および影響対象と影響範囲を整理しました。 　 1 . ケース概要 * Case ID: 137 * ケース名: Two Factor Authentication Enforcement Removal by a Workspace Admin User * 優先度: HIGH * ステータス: OPENED 　 2 . 関連アラート * アラート名: TWO FACTOR AUTHENTICATION ENFORCEMENT REMOVAL BY A WORKSPACE ADMIN USER * 発生日時: 2025-11-26 10:03:52 UTC ( 1764151432245 ) * 内容: Workspace管理者権限を持つユーザーによって、二要素認証（2FA）の強制設定が解除されました。 　 3 . 影響対象と関与エンティティ アラートに関連するエンティティ情報から、以下の事実が確認されました。 　 * 実行ユーザー ( Principal ) : * EXAMPLE@DEV.G-GEN.CO.JP * 接続元IPアドレス: * 0000:0000:0000:0000:0000:0000:0000:0000 ( IPv6 ) * 変更対象リソース ( Target ) : * ORGANIZATIONS/ 1234567890 /SECURITYSETTINGS * 組織レベルのセキュリティ設定オブジェクトです。 　 4 . 影響範囲の整理 このアラートは、特定のユーザーに対する操作ではなく、組織レベルのセキュリティ設定に対する変更を示唆しています。 　 * 直接的な影響: 組織ID 1234567890 （DEV.G-GEN.CO.JP 組織全体、または該当する組織部門）において、二要素認証の強制ポリシーが無効化された可能性があります。 * セキュリティリスク: 2FA強制が解除されると、組織内のユーザーアカウントがパスワード漏洩などの攻撃に対して脆弱になります。全ユーザー、または特定の組織部門（OU）配下の全ユーザーが影響を受ける可能性があります。 　 推奨される次のステップ: * 実行ユーザー ( EXAMPLE@DEV.G-GEN.CO.JP ) に連絡を取り、この設定変更が意図的かつ承認されたものか確認してください。 * 意図しない変更であれば、直ちに設定を元に戻し、該当ユーザーのアカウントが侵害されていないか調査する必要があります。 検索・調査 特定ユーザーの Google Workspace 操作ログ調査 以下のようなプロンプトで前項で確認した Case ID 137 に関連する特定ユーザーの Google Workspace 操作ログの抽出と整理を実施します。 Project ID PROJECT_ID 、Customer ID CUSTOMER_ID 、Region REGION を使用して、Case ID 137 で特定した関与ユーザー EXAMPLE@DEV.G-GEN.CO.JP（接続元 IP：0000:0000:0000:0000:0000:0000:0000:0000） が 2025-11-27（UTC） に行った操作をログから抽出し、重要な操作を時系列で整理してください。 ※ メールアドレスでヒットしない場合は、ケースで得たユーザーID（@ 前）や接続元 IP で再検索します。 # 出力例 　 ✦ 指定された条件（Case ID 137 、ユーザー EXAMPLE@DEV.G-GEN.CO.JP、日付 2025-11-27 UTC）に基づき、Chronicle SIEM のログを調査しました。 　 該当ユーザーによる操作ログが複数確認されました。特に「 2 段階認証プロセス導入ガイド」の作成や「パスキーの登録」など、認証セキュリティに関連する重要な操作が時系列で確認されています。 　 以下に、 2025 年 11 月 27 日（UTC）の重要な操作を時系列でまとめます。 　 ユーザー操作タイムライン ( 2025-11-27 UTC ) 　 1 . OAuth アプリケーションの認可とスクリプト実行 ( 01:31 - 01:45 UTC ) * 01:31:08 - 01:45:34: XXXX というアプリケーションに対し、OAuth トークンを認可・取得しました。 * スコープ: Calendar, Drive, Presentations, Script Deployments 等の権限が含まれています。 * 操作: USER_RESOURCE_ACCESS ( authorize, activity ) * 詳細: Google Apps Script や Calendar API ( calendar.events.list, calendar.events.insert ) の呼び出しが記録されています。 　 2 . ドライブ コンテンツの作成と共有 ( 05:36 - 05:44 UTC ) * 05:36:14 - 05:38:05: Google ドライブ上で「XXXX プロジェクト」および「 2 段階認証プロセス導入ガイド」というファイルを編集・更新しました。 * 05:38:06: 新規ファイル 「 2 段階認証プロセス導入ガイド」（プレゼンテーション）を作成しました。 * 05:41:03: 上記ファイルの権限（ACL）を変更し、共有設定を行いました（USER_CHANGE_PERMISSIONS）。 * 05:41:11: Gmail にて、件名 【GAS自動送信】スライドURLのお知らせ: 2 段階認証プロセス導入ガイド」 のメールを送信しました。 * 接続元IP: 0000:0000:0000:0000:0000:0000:0000:0000 ※提示されたIPと同じサブネット 　 3 . セキュリティ設定の変更 ( 07:10 UTC ) * 07:10:03: ユーザー自身の認証設定として、パスキー ( Passkey ) を登録しました。 * 操作: STATUS_UPDATE ( product_event_type: passkey_enrolled ) * 接続元IP: 0000:0000:0000:0000:0000:0000:0000:0000 　 4 . デバイス管理 ( 07:46 UTC ) * 07:46:49: デバイスの同期/更新イベント ( DEVICE_REGISTER_UNREGISTER_EVENT ) が記録されています。 　 考察 Case ID 137 のアラート名は「Two Factor Authentication Enforcement Removal（ 2 要素認証の強制解除）」ですが、ログからは解除操作そのものではなく、逆に「 2 段階認証プロセス導入ガイド」の作成・配布や、ユーザー自身の「パスキー登録」といった、セキュリティ強化に向けた準備やテストを行っていた動きが顕著に見られます。アラートはこれらの試行錯誤や設定変更の過程でトリガーされた可能性があります。 AWS 特権ユーザーの操作ログ調査 以下のようなプロンプトで、AWS 環境における特権ユーザーの重要な操作（権限変更やリソース削除など）を抽出します。 　 Project ID PROJECT_ID 、Customer ID CUSTOMER_ID 、Region REGION を使用して、 ユーザー XXX@g-gen.co.jp が 2026年1月26日から1月30日の間に AWS で行った操作の中でセキュリティに影響を与える操作を抽出して要約してください。 　 　 # 出力例 　 ✦ ユーザー XXX@g-gen.co.jp の 2026 年 1 月 26 日から 1 月 30 日の間の AWS 操作ログを分析しました。 主に既存の監視設定の削除と、Google SecOps と連携するための新規 IAM 設定が行われています。 　 以下にセキュリティに影響を与える主な操作を時系列で要約します。 　 1 . 監視・ログ収集リソースの削除 ( 1 月 28 日 07:52 - 07:57 ) 以前設定されていたと思われる監視用のリソースが一括して削除されました。これにより、一時的に対象環境のログ収集が停止した可能性があります。 * CloudTrail: トレイル XXXX の削除 * VPC: VPC フローログの削除 * S3: バケット XXXX の削除 * SNS/SQS: 通知用トピックおよびキューの削除 * CloudWatch Logs: ロググループの削除 　 2 . IAM 権限の操作 ( 1 月 28 日 04:44 - 09:56 ) 特定のユーザーやポリシーに対する権限変更が行われました。 * ポリシー更新: XXXX ポリシーのバージョン更新（S3バケットやSQSへのアクセス許可設定）。 * ユーザー権限変更: ユーザー XXXX に対して AdministratorAccess ( 管理者権限 ) の付与 ( AttachUserPolicy ) と、その直後の剥奪 ( DetachUserPolicy ) が行われました。 　 3 . Google SecOps 連携設定の構築 ( 1 月 29 日 01:59 - 06:01 ) Google SecOps ( Chronicle ) から AWS 環境を監視・操作するための信頼関係が構築されました。 * IAM ロール作成: XXXX の作成。 * OIDC プロバイダ作成: accounts.google.com を信頼する OpenID Connect プロバイダの作成。 * 信頼ポリシー設定: 作成したロールに対し、Google アカウントからの AssumeRole を許可する設定 ( UpdateAssumeRolePolicy ) 。 　 結論 このユーザーは、古いサンドボックス環境の監視設定をクリーンアップし、新たに Google SecOps を用いた監視体制を構築するためのセットアップ作業を行っていたと推測されます。 三浦 健斗 (記事一覧) クラウドソリューション部 2023年10月よりG-genにジョイン。元オンプレ中心のネットワークエンジニア。 ネットワーク・セキュリティ・唐揚げ・辛いものが好き。 Google Cloud Partner All Certification Holders 2025 / Google Cloud Partner Top Engineer 2026

はじめに エンジニアの方もエンジニアではない方も、こんにちは。これまでは金融業界で SRE としてGoogle CloudのプロジェクトにJoinしていましたが、最近プロジェクトが変わり、Amazon Web Services (AWS) に挑戦しています。 先日はGoogle Cloud Partner Top Engineer 2026 に選出していただきました！ みなさんは普段、どのようなインプットをしていますか？ 私は「自分から情報を収集しなくても、自動で技術情報が目に入る仕組み」としてRSSを使っています。RSSを利用するには主にRSSリーダーを利用することが多いかと思いま