📋 Associate Google Workspace Administrator (AGWA) 試験対策 — Section 2: Managing Core Workspace Services  · 公式認定ページ · 試験ガイド PDF
SECTION 2 / MANAGING CORE WORKSPACE SERVICES

Google Workspace
コアサービス管理
完全学習ガイド

初学者でもわかる、AGWA試験 Section 2 の全トピックをステップバイステップで解説。各サービスの設定方法・ベストプラクティス・試験ポイントを網羅。

配点比率 ≈ 23%
トピック数 7つのサービス
重要度 ★★★★★

このセクションのカバー範囲

2.1
Gmail の設定
MX・SPF・DKIM・DMARC・ルーティング・スパム対策
2.2
Drive & Docs
共有設定・信頼ルール・共有ドライブ・DLP・ラベル
2.3
Google Calendar
リソース管理・予約ポリシー・外部共有設定
2.4
Google Meet
安全設定・ノックイン・録画・ビデオ設定
2.5
Google Chat
履歴・外部共有・招待制限・モデレーション
2.6
Gemini AI
データプライバシー・有効化・拡張機能設定
MX レコード — メール配送の入口

MX（Mail Exchanger）レコードは、外部サーバーに「このドメイン宛のメールをどこに届けるか」を伝えるDNSレコードです。Google Workspace で Gmail を使う際の最初のステップです。

外部メールサーバー
→
DNS でMXを照会
→
Googleサーバー発見
→
Gmail受信箱に配信
設定方式優先度メールサーバー（Value）推奨
新しい推奨設定1smtp.google.com✅ 現在の推奨
レガシー互換設定1ASPMX.L.GOOGLE.COM既存環境で使用中の場合は維持可
5ALT1.ASPMX.L.GOOGLE.COM
5ALT2.ASPMX.L.GOOGLE.COM
10ALT3.ASPMX.L.GOOGLE.COM
10ALT4.ASPMX.L.GOOGLE.COM
⚠ 注意
MXレコード変更後、DNS伝播には最大72時間かかります。移行時は旧MXレコードを保持したまま新設定を追加し、動作確認後に旧レコードを削除してください。
🔧 確認ツール
設定後はAdmin Toolbox MX チェッカーで正しく設定されているか確認しましょう。
1

段階的移行を実施する — 切り替え前にTTLを下げ（例：300秒）、旧レコードを保持したままGoogleのMXを追加して動作確認後に旧レコードを削除する

2

Admin Toolboxで定期確認 — MXレコードの設定は変更されることがあるため、定期的にツールで検証する

3

移行後は旧MXを必ず削除 — 古いMXレコードが残るとセキュリティリスクと不要な遅延が生じる

高度なメールルーティング — 分割配信・二重配信

組織の移行フェーズや複数システム運用時に、メールのトラフィックを適切なサーバーに振り分ける設定です。

分割配信（Split Delivery）

Google サーバーで受信後、宛先ユーザーの存在に応じて配信先を振り分け

  • Google ユーザー → Gmail に配信
  • Google に存在しないユーザー → レガシーサーバーへ転送
  • 用途:段階的移行、特定部署のみオンプレミス継続
二重配信（Dual Delivery）

全メールを Gmail と外部サーバーの両方に同時配信

  • 移行前の並行稼働テストに最適
  • サードパーティアーカイブへの全件転送
  • 用途:移行テスト、コンプライアンスアーカイブ

分割配信の設定手順

1
ホストを登録管理コンソール → アプリ → Google Workspace → Gmail → ホスト から転送先の外部サーバー（FQDN または IP）を登録
2
ルーティングルールを作成Gmail → ルーティング → 新しいルールを追加 → 対象を「受信」に設定
3
アクションを設定「メッセージを変更」→「ルートを変更」→ 手順1で作成したホストを選択
4
フィルターを適用Googleに存在しないアカウント（Catch-all）のみを転送対象にするようフィルタリングを設定
📍 設定場所
管理コンソール → アプリ → Google Workspace → Gmail →ルーティング
★最重要★ メール認証：SPF・DKIM・DMARC の完全理解
🎯 試験最頻出トピック
SPF・DKIM・DMARC は試験で最も頻出するトピックです。それぞれの役割の違い、設定手順、DMARC の段階的導入を完全に理解してください。

SPF（Sender Policy Framework）

「このドメインからメールを送信できるサーバーはここです」とDNSに宣言する仕組み。なりすましメールの送信元IP偽装を防ぎます。

# Gmail のみを使う場合（最もシンプル）
v=spf1 include:_spf.google.com ~all

# Gmail + Salesforce など複数サービスを使う場合
v=spf1 include:_spf.google.com include:_spf.salesforce.com ~all

# 終端ポリシーの意味
-all → FAIL（厳格に拒否）
~all → SOFTFAIL（スパム扱い）← 移行期に推奨
?all → NEUTRAL（何もしない）
⚠ SPF の制限
SPFレコードには最大10回のDNS参照という制限があります。Mailchimp、Salesforce など複数のサードパーティサービスを追加しすぎると上限を超えてしまいます。

DKIM（DomainKeys Identified Mail）

送信メールにデジタル署名を付与し、「本当にそのドメインから送られており、改ざんされていない」ことを保証します。

# DNS に追加する TXT レコード（例）
# ホスト名: google._domainkey.example.com
v=DKIM1; k=rsa; p=MIGfMA0GCSQ... (公開鍵)

DKIM 設定手順：

1
鍵を生成 — 管理コンソール → Gmail → メールの認証 → DKIM キーを生成（2048ビット推奨）
2
DNS に追加 — 生成されたTXTレコードをDNSレジストラでgoogle._domainkey.ドメイン名 に登録
3
署名を開始 — 管理コンソールに戻り「DKIM を開始」をクリック
4
動作確認 — Admin Toolbox でDKIMが正しく機能しているか確認

DMARC（Domain-based Message Authentication, Reporting, and Conformance）

SPFとDKIMの検証失敗時の処理ポリシーを受信サーバーに伝え、レポートを受け取る仕組みです。

# フェーズ1: 監視（最初に設定）
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

# フェーズ2: 隔離モード（段階的に適用割合を増やす）
v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@example.com
v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@example.com

# フェーズ3: 完全拒否（最終目標）
v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-reports@example.com
ポリシー(p=)意味認証失敗時の動作推奨フェーズ
none監視のみ何もしない（レポートのみ）Phase 1（1〜2週間）
quarantine隔離スパムフォルダに移動Phase 2（段階的拡大）
reject拒否メールを完全に拒否Phase 3（最終目標）
❌ アンチパターン
DMARC を最初からp=rejectに設定するのは危険です。SPFに含まれていない正規の送信サービスからのメールまでブロックされてしまいます。必ずp=none で監視 → 段階的に強化 してください。
1

三点セットで設定する — SPF・DKIM・DMARC は必ず3つセットで設定。1つや2つだけでは完全な認証にならない

2

DMARC は段階的に導入 — p=none → p=quarantine（pct=10→100）→ p=reject の順に進める

3

DMARC レポートを分析ツールで可視化 — Postmark、dmarcian 等のツールを使いレポートを解析する

4

サードパーティサービスを SPF に含める — Salesforce、Mailchimp 等のIPも忘れずSPFに追加する

5

DKIM キーは 2048 ビットを使用 — 1024ビットより安全。年1回のローテーションも推奨

📎 公式ソース
スパム・フィッシング・マルウェア対策設定

Gmail は多層的なセキュリティフィルタリングを提供しています。管理者はこれらの設定を組み合わせて防御を強化します。

📍 設定場所
管理コンソール → アプリ → Google Workspace → Gmail →スパム、フィッシング、マルウェア
設定名機能推奨設定
スパムフィルタ強化迷惑メールの検出強度「強化されたスパム対策」を有効化
メールの許可リスト常に受信箱に届けるメールアドレス/ドメイン信頼できるビジネスパートナーのみ登録。過度な登録はNG
IP 許可リスト特定IPからのメールをスパムフィルタ免除受信ゲートウェイのIPのみ登録
ブロックリスト特定のアドレス・ドメインをブロックスパム送信者、不審なドメイン
フィッシング対策偽サイトへのリンク検出、なりすまし検出まず「警告表示」から始め、誤検知確認後に「隔離」へ
⚠ 許可リストとIP許可リストの違い（試験頻出）
  • Email Allowlist（メール許可リスト）：特定のIPから送られたメールをスパムフィルタをスキップして受信箱へ届ける
  • IP Allowlist（IP許可リスト）：受信ゲートウェイとして機能するIPを登録。このIPを経由したメールは「既にスパムチェック済み」と認識され、スパム分類が緩和される（完全スキップではない）
コンプライアンスフッター・メール隔離・コンテンツコンプライアンス

コンプライアンスフッターは送信メールに自動的に法的免責事項などのテキストを追加する機能です。組織部門（OU）ごとにカスタマイズ可能です。

📍 設定場所
管理コンソール → Gmail → コンプライアンス → コンプライアンスフッター / メールの隔離 / コンテンツコンプライアンス

コンテンツコンプライアンスルール — できること

条件アクション実例
件名・本文・添付ファイルに特定キーワード/正規表現を含むメールを拒否「社外秘」を含む送信メールを組織外にブロック
特定の添付ファイルタイプ（.exe等）隔離（管理者レビュー）実行ファイルを管理者承認なしに受信不可にする
送信先が特定ドメインBCC コピーを追加競合企業ドメインへの送信をコンプライアンス担当にCC
特定パターンのメッセージヘッダー変更・転送カスタムヘッダーの追加
1

隔離機能を活用 — 単純なブロックではなく隔離にすることで、誤検知時に管理者が判断して解放できる

2

OU ごとにフッターをカスタマイズ — 営業部門には促進情報、法務部門には守秘義務条項を自動付与する

セキュリティサンドボックス — 未知のマルウェアを仮想環境で検出

標準のウイルス対策を回避するゼロデイマルウェアを、添付ファイルを仮想環境で実際に実行することで動的に検出します。

⚠ エディション要件
セキュリティサンドボックスはBusiness Standard 以上のエディションで利用可能です。試験でエディションが記載されている問題に注意してください。
1
有効化 — 管理コンソール → Gmail → スパム、フィッシング、マルウェア → セキュリティサンドボックス を ON
2
スキャン対象の設定 — 全ての添付ファイル対象 OR 特定ルール（不審送信元・特定拡張子）に限定
3
注意点 — スキャン完了まで数分かかる場合がある。業務スピードとのバランスを考慮して設定
📎 公式ソース
共有設定の階層と外部共有制御

Drive の共有設定は階層構造になっており、上位の設定が下位を継承（上書きも可）します。

管理コンソール（最上位ポリシー）
↓ 継承または上書き
OU 単位の設定
↓ 継承または上書き
共有ドライブの設定
↓ 管理者が許可した範囲内
ユーザー個人の設定
📍 設定場所
管理コンソール → アプリ → Google Workspace →Drive と Docs → 共有設定
設定項目選択肢セキュリティ推奨
外部共有許可 / 禁止 / ドメイン限定部門OU ごとに制御。財務・法務は禁止推奨
新規ファイルのデフォルト共有制限付き / リンクを知っている組織内全員「制限付き（組織内のみ）」がセキュアなデフォルト
リンク付きで共有「リンクを知っている全員」許可/禁止機密情報部門は「禁止」
ドメイン外への一般公開許可 / 禁止原則禁止（特定部門のみ許可）
🎯 試験ポイント
OU ごとに異なる外部共有ポリシーを適用したい場合は、ルート組織でデフォルトを設定し、特定OUで「上書き（Override）」を使って個別設定します。
Drive 信頼ルール（Trust Rules）— 精密な外部共有制御

通常の共有設定より細粒度のアクセス制御が必要な場合に使用するエンタープライズ機能です。

⚠ エディション要件
信頼ルールは Enterprise エディション が必要です。
通常の共有設定
  • 「組織外への共有を許可/禁止」
  • おおまかな制御のみ
Trust Rules（精密制御）
  • 「営業OU は partner.com のみ共有可」
  • 「人事OU は外部共有一切禁止」
  • OU・グループ・特定ドメイン単位で設定
📍 設定場所
管理コンソール → Drive と Docs → 信頼ルール → ルールを作成
共有ドライブ（Shared Drives）の管理

マイドライブとの最大の違いは「ファイルの帰属」です。共有ドライブは組織所有のため、メンバーが退職してもファイルは失われません。

比較項目マイドライブ共有ドライブ
ファイルの帰属個人ユーザー組織（チーム）
退職時の影響⚠ ファイルが失われる危険✅ ファイルはそのまま残る
アクセス管理ユーザー個人管理者またはマネージャー
用途個人ファイルチームの共有資料・プロジェクト

共有ドライブの権限レベル（試験頻出）

役割できること推奨対象
マネージャーメンバー管理・設定変更・全ファイル操作チームリーダー、IT管理担当者
コンテンツ管理者追加・編集・削除・移動（メンバー管理不可）プロジェクトのメインメンバー（デフォルト推奨）
投稿者追加・編集のみ（削除・移動不可）外部協力者、一般メンバー
コメント投稿者閲覧・コメントのみレビュー担当者
閲覧者閲覧のみ参照のみの他部署ユーザー
🎯 試験ポイント
外部ユーザーを共有ドライブに招待する際は「投稿者」以下の権限に留め、ファイルの削除・移動を防ぐことがベストプラクティスです。
1

マイドライブより共有ドライブを推奨 — チームの業務ファイルは共有ドライブで管理し、退職時の引き継ぎ問題を根本解決する

2

外部ユーザーは「投稿者」以下に設定 — 削除・移動権限を与えない。ファイル単体での共有も活用する

3

定期的に共有ドライブの監査を実施 — 管理コンソール → 共有ドライブを管理 から不要なメンバーやアクセス権を確認・削除

DLP（データ損失防止）と Drive ラベルの統合

DLP ポリシーはドライブのドキュメントをリアルタイムでスキャンし、機密情報の検出とアクションを自動化します。

DLP ルールの構成要素選択肢例
スキャン対象組織全体 / 特定OU / グループ財務部門OU のドキュメント
検出条件事前定義検出器 / 正規表現（Regex）クレジットカード番号、マイナンバー
アクション共有ブロック / 警告表示 / 監査ログ記録「このファイルには機密情報が含まれます」と警告

Drive ラベル — DLP との連携

ラベルはファイルに分類情報（機密レベルなど）を付与し、DLP・Vault・検索と連携します。

ラベル例値の例使用場面
機密レベル公開 / 社内限 / 機密 / 極秘情報管理ポリシーの自動適用
プロジェクトProject-A / Project-Bプロジェクト別の分類と検索
ステータスドラフト / 承認待ち / 承認済み承認ワークフロー管理
📍 設定場所
管理コンソール → Drive と Docs → ラベル → ラベルを作成
📎 公式ソース
リソースカレンダーの作成と管理

会議室、設備、車などの物理的なリソースをカレンダーで予約・管理できます。構造化されたリソース設定がベストプラクティスです。

📍 設定場所
管理コンソール → ディレクトリ → 建物とリソース → 建物/リソースを追加
設定要素内容重要ポイント
建物（Buildings）会議室が存在する拠点情報正確な住所を入力するとルームインサイトで地理分析が可能
機能（Features）リソースの特徴タグ大型モニター、車椅子対応、TV会議システム搭載 など
リソース（Resources）実際の会議室名・備品名建物と機能に関連付け。キャパシティも正確に入力
1

命名規則を統一する — [拠点名]-[階数]-[部屋名]（例：TK-3F-RoomA）のように、一目で場所がわかる名称にする

2

キャパシティを正確に入力 — 収容人数を入力すると「Find a time」機能が参加人数に最適な部屋を自動提案できる

3

ルームインサイトを活用 — 管理コンソール → 建物とリソース → インサイト で利用率が低い部屋や満室が多い拠点を特定

予約承認フローの種類

承認タイプ仕組み用途
自動承認予約者 → 即時確定一般会議室
手動承認予約者 → リソースオーナーが承認/拒否役員室、高価な機材
特定ユーザーのみ自動承認不要ユーザー:即時 / その他:承認フローハイブリッド運用
カレンダー共有設定と外部共有
📍 設定場所
管理コンソール → アプリ → Google Workspace →Calendar → 共有設定
外部共有設定レベル説明推奨
外部との共有なし組織外の誰にも予定情報を共有しない機密性が高い組織向け
空き時間のみ共有予定の詳細は非公開、空き/予定ありのみ✅ デフォルト推奨
すべての予定詳細を共有組織外のユーザーにも予定詳細が見える特定部門のみ
一般公開公開URLでカレンダーを公開⚠ 原則非推奨（会議タイトルが公開されるリスク）
🎯 試験ポイント
外部共有のデフォルト推奨は「空き時間のみ表示（詳細は非公開）」です。「一般公開」設定では「A社買収に関する会議」などの機密情報が外部に漏れる可能性があります。
📎 公式ソース
安全設定（Safety Settings）— 外部参加者の制御
📍 設定場所
管理コンソール → アプリ → Google Workspace →Google Meet → Meet の安全設定
設定名説明推奨設定
ノックイン（ノックをする）組織外ユーザーが参加前にホストの承認が必要✅ 必ず有効化
ホストの管理ホストが参加者をミュート・退出させられる✅ 有効（特に教育機関・ウェビナーで重要）
会議終了時に全員退出ホスト退出後に残存参加者を自動退出✅ 有効
安全チェックユーザーが安全でない状況を報告できる✅ 有効
🎯 試験ポイント（超頻出）
外部参加者が無断で会議に入ってくる問題への対策はノックイン機能の有効化です。これが最頻出の問題パターンです。
録画・文字起こし・AI機能の管理
機能説明注意点
録画の許可会議の録画を許可するか録画は主催者のGoogle Driveに自動保存される
自動文字起こし（Transcript）会議音声を自動テキスト化Business Standard 以上が必要
AI ノートテイキングGemini が自動的にメモを作成Gemini対応エディションが必要
1

外部参加者にノックインを必須化 — 不審な参加者の防止に最も効果的な設定

2

録画の保存先を組織の共有ドライブに指定 — 個人ドライブへの散逸を防ぎ、アクセス管理を統一する

3

録画後はアクセス権を見直す — 「リンクを知っている全員」設定のまま放置しないようユーザーに周知

📎 公式ソース
チャット履歴とコンプライアンス — 最重要設定
❌ 重大なリスク（試験頻出）
チャット履歴が オフ になっている場合：
• メッセージが保存されない
• Google Vault での検索・保持ができない（eDiscovery 不可）
• DLP（データ損失防止）が機能しない

法的調査・コンプライアンス要件がある組織では、チャット履歴を必ずオンに設定してください。
📍 設定場所
管理コンソール → アプリ → Google Workspace →Google Chat → 設定 → チャット履歴
設定名説明コンプライアンス要件がある場合
チャット履歴メッセージを保存するか✅ 必ずオンに固定
外部ユーザーとのスペース組織外ユーザーとのChatスペースへの参加許可リスト（信頼ドメイン）でのみ許可
アプリ（ボット）Chat への外部アプリの追加承認済みアプリのみ許可
コンテンツのモデレーション不適切なメッセージの報告・管理✅ 有効化推奨
🎯 試験ポイント
「法的調査のため過去のチャットを提出する必要があったが、履歴がオフだったためデータがなかった」というシナリオは試験の典型問題です。予防策としてチャット履歴をオンに設定し、Vault で保持ルールを設定することが正解です。
1

履歴は必ずオン — コンプライアンス要件がある業界では、Chat 履歴をオンに固定し、ユーザーが変更できないようにする

2

外部ドメインは許可リストで管理 — 組織外とのChatは許可リストに登録されたドメインのみに制限する

3

Chat アプリは承認制に — 未承認のアプリを介したデータ流出（シャドーIT）を防ぐため、管理者承認済みアプリのみ許可

📎 公式ソース
データのプライバシーとセキュリティ — 試験必須知識
🎯 試験最頻出ポイント
Gemini for Google Workspace のデータ取り扱いについて、以下の3点を必ず覚えてください。
1

組織データをモデル学習に使用しない — プロンプトや参照したドキュメントの内容は、組織外の不特定多数が利用するAIモデルのトレーニングには使用されない（無料版Geminiとは異なる）

2

既存の権限を完全に尊重する — Gemini はユーザーが元々アクセス権を持っていないデータにはアクセスできない。DriveやGmailの既存ACLがそのまま適用される

3

エンタープライズグレードのコンプライアンス— ISO認証・SOC監査・FedRAMP等のコンプライアンス基準がGeminiにも適用される

Gemini の有効化と OU 単位での制御
📍 設定場所
管理コンソール → アプリ → Google Workspace →Gemini for Workspace → [OU を選択] → 機能のON/OFF
部門推奨設定理由
一般業務部門✅ 有効生産性向上、業務効率化
法務・コンプライアンス✅ 有効（ガイドライン策定必須）契約書レビュー等での活用
機密研究部門⚠ 無効 or 制限機密情報の保護を優先

Workspace 拡張機能（Extensions）

GeminiアプリがGmail・Drive・Calendar等のWorkspaceデータにアクセスできる機能です。管理者は各サービスへのアクセスをON/OFFで制御できます。

1

Gemini 利用ポリシーを策定する — 特に機密情報の取り扱い方法をユーザーに周知。「生成された回答は必ずファクトチェックする」という文化を醸成

2

段階的ロールアウトを実施 — パイロットグループ（30〜50名）→ 全社展開の順で進め、問題点を早期に発見する

3

利用状況レポートを定期確認 — 管理コンソール → レポート → Gemini で利用状況を分析し、未使用ユーザーにトレーニングを提供

📎 公式ソース
AppSheet と Apps Script の使い分け
AppSheet（ノーコード）

プログラミング不要でモバイル/Webアプリを構築

  • 在庫管理アプリ
  • 現場報告フォームアプリ
  • 経費申請の承認ワークフロー
  • スプレッドシートベースの簡易CRM

→ エンジニア不要で業務アプリを迅速に作りたい場合

Apps Script（ローコード/スクリプト）

Google Workspace の機能を拡張・自動化するJavaScriptプラットフォーム

  • Gmail の自動返信・自動分類
  • Forms 送信後の自動メール通知
  • 定期レポートの自動生成
  • Admin SDK を使ったユーザー管理の自動化

→ Workspace サービスを API レベルで拡張・自動化したい場合

AppSheet と Apps Script の管理設定
📍 設定場所（AppSheet）
管理コンソール → アプリ → Google Workspace →AppSheet → [OU 選択] → ON/OFF
📍 設定場所（Apps Script）
管理コンソール → アプリ → Google Workspace →Apps Script → [OU 選択] → ON/OFF
1

Apps Script のスコープを最小限に — 「ドメイン全体の委任」を必要とするスクリプトは慎重に審査し、不必要に広いスコープを許可しない

2

AppSheet のデータソースアクセスを制限 — 機密データを含むスプレッドシートに接続する場合はアクセス権を厳密に設定する

3

Apps Script のトリガーを定期審査 — 不要なトリガーが動作し続けていないか、定期的に監査ログで確認する

4

AppSheet アプリの共有範囲を組織内に限定 — 外部ユーザーへの共有は原則禁止し、必要な場合は承認フローを経る

📎 公式ソース

📧 Gmail（2.1）

💾 Drive（2.2）

📅 Calendar（2.3）

🎥 Meet（2.4）

💬 Chat（2.5）

🤖 Gemini（2.6）

🏆 試験合格への最短ルート

①SPF・DKIM・DMARC の三点セット（役割と設定手順を完全理解）  ②DMARC の段階的導入（none→quarantine→reject）  ③Chat 履歴オン＝Vault で保持可能という連携の理解  ④Meet のノックイン機能が外部参加者対策の答え  ⑤Geminiは組織データをモデル学習に使わない

📚 参考:AGWA 認定ページ · 試験ガイド PDF · Workspace Admin Help · Workspace Knowledge Center · Admin Toolbox