はじめに
キュー（Queue）は、Salesforce で複数のユーザーがレコードを共有し、効率的に処理するための重要な機能です。サポートチームでのケース管理や、営業チームでのリード割り当てなど、チームベースの業務フローに欠かせません。
本記事では、キューの基本概念から実践的な設定方法、自動割り当ての活用まで、システムアドミニストレータとして知っておくべきキュー管理の全てを解説します。
学習目標
この記事を読むことで、以下のスキルを習得できます：
- キューの概念と目的を理解する
- キューの作成と管理方法を習得する
- レコード割り当てルールとの連携を理解する
- キューを活用した効率的な業務フローを設計できる
- システムアドミニストレータ試験の関連問題に対応できる
【本記事の前提】
本記事では、ケースとリードで使用できる「Assignment Rules（割り当てルール）」を中心としたキュー運用を解説しています。
なお、タスクはキューを所有者として設定できますが、Assignment Rules は利用できないため、本記事では対象外としています。タスクをキューで管理する場合は、Flow や Apex による自動化が必要です。
キューとは
基本概念
キューは、複数のユーザーやグループが共同でレコードを処理するための「待ち行列」です。
主な特徴：
- 共有の受け皿 - チーム全体でレコードを所有し、誰でも対応可能な状態にする
- 柔軟な割り当て - 自動割り当てルールで振り分け、手動での移動も可能
- オブジェクトごとの設定 - リード、ケース、カスタムオブジェクト等、オブジェクトごとに異なるキューを作成
- メンバー管理 - ユーザー、ロール、パブリックグループを含む柔軟なメンバー構成
キューの仕組み
新規リードが登録
↓
割り当てルールで評価
↓
条件に基づいてキューに割り当て
↓
キューメンバーが確認・取得
↓
個人ユーザーに割り当て変更
↓
処理開始
具体例：サポートケースの処理
- 顧客からケースが作成される → 「一般サポートキュー」に自動割り当て
- サポートチームメンバーがキューを確認 → 対応可能な担当者を見つける
- 担当者が「私に割り当て」をクリック → ケースの所有者が個人ユーザーに変更
- 担当者が対応を開始 → ケース解決まで処理
キューを使うべき場面
使用が推奨される場面
複数人で対応するレコード
サポートケースのように、誰でも対応可能で、緊急度に応じて優先処理し、チーム全体で負荷分散する場合は「サポートチームキュー」で管理します。
地域・製品別の振り分け
営業リードを東日本エリアは東日本営業キュー、西日本エリアは西日本営業キュー、製品A関連は製品Aスペシャリストキューのように、地域・製品別にキューを作成します。
エスカレーション管理
L1サポート → L2サポートのように、初期対応はL1サポートキュー、解決不可ならL2サポートキューへ移動、さらにエスカレーションが必要ならL3キューへと、レベル別キューで段階的に処理します。
一時的な受け皿
担当者未定のレコード、再配分待ちのレコード、処理保留中のレコードを「未割り当てキュー」で一時管理します。
使用を避けるべき場面
- 常に同じ担当者が処理する場合 - 直接ユーザーに割り当てる方が効率的
- 完全に個人管理のレコード - 営業担当者の商談（通常は個人所有）、個人的なタスクや活動
- 1人のユーザーのみが処理できる場合 - キューのメリットがなく、直接割り当てを推奨
キューの作成手順
ステップ1: キューの作成
設定手順：
- 設定画面を開き、クイック検索で「キュー」と入力してキューに移動（または 設定 → ユーザー → キュー）
- 新規 をクリック
- 基本情報を入力：
- ラベル: 東日本営業キュー
- キュー名: East_Sales_Queue
- キューのメールアドレス:（任意）east-sales@company.com
- サポート対象オブジェクトを選択（例：リードにチェック）
- 保存
ステップ2: キューメンバーの追加
キューメンバーに含められるもの：
- 個別ユーザー - 山田太郎、鈴木花子、佐藤次郎など
- ロール - 営業担当者（東日本）など、そのロール配下の全ユーザー
- ロールおよび下位ロール - 営業部長（東日本）など、その下位ロール全てを含む
- パブリックグループ - 東日本営業チームグループなど
メンバー追加手順：
- 作成したキューの詳細ページを開く
- キューメンバー セクションで 編集 をクリック
- 選択可能なメンバー から追加したいメンバーを選択
- 追加 をクリックして「選択済みのメンバー」に移動
- 保存
ステップ3: 割り当てルールの設定（オプション）
レコードを自動的にキューに割り当てるには、割り当てルールを設定します。
リードの場合：
- クイック検索で「リードの割り当てルール」と入力して移動（または 設定 → 機能設定 → マーケティング → リード設定 → 割り当てルール）
- 新規 をクリック
- ルール名を入力（例：地域別リード割り当て）し、有効にチェック
- ルールエントリを追加：
- エントリ順序1: 都道府県 = 東京、神奈川、埼玉、千葉 → 東日本営業キュー
- エントリ順序2: 都道府県 = 大阪、京都、兵庫 → 西日本営業キュー
- 保存 して 有効化
ケースの場合：
クイック検索で「ケースの割り当てルール」と入力して移動し、同様の手順でルールを作成します。
実践例：キューの活用パターン
パターン1: サポート組織のキュー設計
小規模サポートチーム（5-10名）
シンプルな構成として「一般サポートキュー」を1つ作成し、サポートチーム全員をメンバーに設定します。全ての新規ケースをこのキューに自動割り当てし、空いている担当者が取得して解決まで処理します。
中規模サポートチーム（20-50名）
レベル別構成として、L1サポートキュー（初期対応）、L2サポートキュー（エスカレーション）、L3サポートキュー（専門対応）を作成します。優先度が低・中のケースはL1キューへ、優先度が高のケースはL2キューへ自動割り当てし、解決不可の場合は上位キューへ手動移動します。
大規模サポートチーム（100名以上）
製品・地域・レベルを組み合わせた構成にします。例えば「製品A - L1サポートキュー（東日本）」「製品A - L1サポートキュー（西日本）」「製品A - L2サポートキュー（全国）」「VIPカスタマーサポートキュー（優先対応）」のように細分化します。
パターン2: 営業組織のリード管理
地域別キュー
東日本営業キューと西日本営業キューを作成し、都道府県に基づいて自動割り当てします。Webフォームからリードが作成されると地域に基づいて自動割り当てされ、営業担当者が取得して商談化まで育成します。
製品・業種別キュー
エンタープライズ営業キュー（従業員数 > 1000）、SMB営業キュー（従業員数 <= 1000）、製品Aスペシャリストキュー、業種別（製造業）キューなど、専門知識を持つ担当者が対応できるように分類します。
パターン3: 一時的な受け皿キュー
- 未割り当てリードキュー - インポートしたリードを一時保管し、マネージャーが内容確認後、適切な担当者に手動割り当て
- 休暇中担当者キュー - 担当者休暇前にレコードを移動し、チームで代理対応、復帰後に担当者へ戻す
- 再配分待ちキュー - 退職者のレコードを移動し、新担当者決定まで保管
キューの管理
キューからのレコード取得
方法1: リストビューから取得
- 対象オブジェクト（例：ケース）に移動
- リストビュー「サポートチームキュー」を選択
- 取得したいレコードをクリック
- 所有者の変更 をクリック
- 自分のユーザー名を選択して 保存
方法2: 「私に割り当て」ボタン
レコード詳細ページで「私に割り当て」ボタンをクリックすると、自動的に所有者が自分に変更されます（キューメンバーにのみ表示）。
方法3: 一括割り当て
リストビューで複数レコードを選択し、「所有者の変更」を選択して新しい所有者を指定すると、一括で割り当て変更できます。
キューの監視とレポート
キュー内のレコード数を確認：
レポートタイプ「ケース」で条件を「所有者 = サポートチームキュー」、グループ化を「ステータス」に設定すると、新規・進行中・保留などの件数を確認できます。
キュー滞留時間の監視：
レポートに数式項目「TODAY() - DATEVALUE(CreatedDate)」を追加すると、キュー滞留日数を監視できます。
キューからの取得状況：
レポートタイプ「ケース履歴」で条件を「項目 = 所有者、変更元 = キュー」、グループ化を「変更先ユーザー」に設定すると、各担当者の取得件数を確認できます。
キューメンバーの管理
定期的なレビュー：
月次で、メンバーは最新か、退職者は削除されているか、新入社員は追加されているか、ロール変更の反映を確認します。四半期で、キュー構成は最適か、統合・分割の必要性、割り当てルールの見直しを確認します。
キューのベストプラクティス
1. 明確な命名規則
推奨パターン：
- 地域ベース: East_Sales_Queue, West_Support_Queue
- 製品ベース: ProductA_Specialist_Queue, ProductB_Support_Queue
- レベルベース: L1_Support_Queue, L2_Support_Queue
- 部門_用途: Sales_Unassigned_Queue, Support_Escalation_Queue
避けるべき命名： Queue1, Queue2（内容不明）、テストキュー（本番環境で使用）、Temp_Queue（一時的な名前）
2. 適切なメンバー構成
推奨： ロールを活用すると、人事異動時の更新が不要になります。パブリックグループを活用すると、プロジェクトチームや一時的なグループ、複雑な条件のメンバー構成に対応できます。
避けるべき： 個別ユーザーのみ（人事異動のたびに更新必要）、全社員を含む（責任の所在が不明確）
3. キュー数の最適化
推奨： 必要最小限のキュー数に抑えます。小規模は2-5キュー、中規模は5-15キュー、大規模は15-30キューが目安です。各キューの目的を文書化し、重複を避けます。
避けるべき： キューの乱立（50個以上、類似キューの重複、使用されていないキュー）、1つのキューで全て管理（細かい振り分けができない）
4. 割り当てルールの設計
推奨： 明確な条件を設定し、デフォルトの設定を最後のエントリに配置します。
原則： 具体的な条件 → 先、汎用的な条件 → 後、デフォルト（全て） → 最後
避けるべき： 複雑すぎる条件（10個以上の条件式、ネストした複雑なロジック）、漏れの発生（どのキューにも該当しないレコード）
5. キューメールアドレスの活用
- チーム共有メールアドレス（support@company.com → サポートキュー）
- メール-to-ケース（メール受信で自動ケース作成、キューに自動割り当て）
- 通知の集約（キュー宛の通知メールをチーム全体で共有）
6. 権限の管理
- 割り当てルールの管理 - 「割り当てルールの管理」権限が必要（システム管理者または委任管理者）
- キューメンバーの管理 - 「キューの管理」権限が必要（部門マネージャーに委任可能）
- レコードの取得 - キューメンバーであることが必要（オブジェクト権限も確認）
よくある間違いと対処法
間違い1: 個人ユーザーのみをメンバーに追加
問題： 人事異動のたびに更新が必要で、新入社員の追加漏れや退職者の削除漏れが発生します。
対処法： ロールまたはパブリックグループを使用します。そのロールの全ユーザーが自動的にメンバーになり、人事異動時の更新が不要になります。
間違い2: キューからの取得を忘れる
問題： キューにレコードが滞留し、誰も取得しないため対応遅延が発生します。
対処法： ダッシュボードで監視（キュー内レコード数、滞留時間、古いレコードのアラート）、メール通知（新規レコード割り当て時、一定時間経過後）、SLAの設定（キュー滞留時間の目標、超過時のエスカレーション）、ローテーション制（当番制で定期確認）を導入します。
間違い3: 不要なキューの放置
問題： 50個以上のキューがあり、半分は使用されておらず、選択が困難で管理が煩雑になります。
対処法： 四半期ごとに棚卸しを行い、過去3ヶ月でレコードが割り当てられたか、メンバーは適切か、統合できるキューはないかを確認します。不要なキューはレコードを移動後、無効化します（削除は推奨しない）。
間違い4: 割り当てルールの順序ミス
問題： 「全てのレコード → 一般キュー」を最初に配置すると、後続のエントリ（優先度 = 高 → VIPキュー等）が実行されません。
対処法： 具体的な条件を先に配置し、デフォルト（全て）を最後に配置します。
間違い5: オブジェクト権限の不足
問題： キューメンバーになっているがレコードが表示されません。
対処法： オブジェクト権限（参照・編集）、項目レベルセキュリティ、レコードタイプアクセスを確認します。設定 → ユーザー → プロファイル/権限セット → オブジェクト設定で確認できます。
キューの制限事項
機能的な制約
キューを所有者として設定できるオブジェクト：
- サポートされる: リード、ケース、タスク、サービス契約、カスタムオブジェクト
- サポートされない: 取引先、取引先責任者、商談、イベント
※ 本記事では、初級者・実務で頻出するオブジェクトに焦点を絞って説明しています。
連絡要求（ContactRequest）、注文（Order）、ナレッジ記事バージョンなど、
他にもキュー所有が可能なオブジェクトがあります。完全な一覧は公式ドキュメントをご参照ください。
※ 活動（Activity）には「タスク」と「イベント」がありますが、
キューを所有者として設定できるのはタスクのみで、イベントは対象外です。
注意： サポート対象オブジェクトの最新情報は Salesforce ヘルプ: キューの設定 を参照してください。
Assignment Rules の制約
Assignment Rules でサポートされるオブジェクト：
- サポートされる: リード、ケース
- サポートされない: タスク（キュー所有は可能だが、Assignment Rules は不可）、カスタムオブジェクト
タスクのキュー運用について
タスクの OwnerId フィールドにキューを設定できます。ただし、以下の点に注意が必要です：
できること： タスクの所有者としてキューを設定、キューのリストビューでタスクを表示、キューメンバーがタスクを取得、Flow や Apex での自動割り当て
できないこと： Assignment Rules による自動割り当て、Web-to-Task での自動キュー割り当て
代替手段： Record-Triggered Flow で条件に基づいてタスクをキューに割り当て、または Apex トリガーでの自動割り当て
その他の制約
- キュー同士のネスト（親子関係）は不可
- キューが対象外オブジェクトのレコードを所有することは不可
試験対策ポイント
重要な知識ポイント
1. 基本概念： キューは複数ユーザーがレコードを共有する仕組みで、リード、ケース、カスタムオブジェクトなどをサポートし、割り当てルールで自動振り分けが可能です。
2. メンバー構成： ユーザー、ロール、パブリックグループを含められ、「ロールおよび下位ロール」も選択可能で、複数のメンバータイプを組み合わせできます。
3. 割り当てルール： エントリは上から順に評価され、条件に合致したら処理終了（次のエントリは評価されない）、デフォルトエントリを最後に配置することを推奨します。
試験によく出る問題パターン
パターン1: キューの用途
Q: 複数のサポート担当者が交代でケースに対応するシナリオでキューを使用すべきですか？
A: YES。サポートチームキューを作成し、全サポート担当者をメンバーに設定します。
Q: 営業担当者が自分の商談を管理するシナリオでキューを使用すべきですか？
A: NO。商談は個人所有が基本で、直接ユーザーに割り当てます。
パターン2: メンバー構成
Q: キューメンバーに含められるのは？
A: 個別ユーザー、ロール、ロールおよび下位ロール、パブリックグループは含められます。プロファイル（含められない）、他のキュー（ネスト不可）は含められません。
パターン3: 割り当てルールの順序
Q: エントリ1が「条件なし → 一般サポートキュー」、エントリ2が「優先度 = 高 → VIPサポートキュー」の場合の問題点は？
A: エントリ1が先に評価され、全てのケースが一般サポートキューに割り当てられ、エントリ2は実行されません。正しくは、優先度 = 高 → VIPサポートキューを先に、条件なし → 一般サポートキューを後に配置します。
パターン4: サポート対象オブジェクト
Q: キューで管理できるオブジェクトは？
A: リード（Assignment Rules 対応）、ケース（Assignment Rules 対応）、カスタムオブジェクト、サービス契約は管理できます。商談、取引先は管理できません。タスクはキュー所有は可能ですが Assignment Rules は不可です。
実務シナリオ問題
シナリオ1：
サポートチームは東日本と西日本に分かれており、各地域のケースはそれぞれの地域チームで対応します。ただし、緊急ケースは両地域の上級スペシャリストが対応する必要があります。
推奨設計：
キュー構成として、東日本サポートキュー、西日本サポートキュー、緊急対応キュー（東日本上級スペシャリスト + 西日本上級スペシャリスト）を作成します。
割り当てルールは、エントリ1: 優先度 = 緊急 → 緊急対応キュー、エントリ2: 地域 = 東日本 → 東日本サポートキュー、エントリ3: 地域 = 西日本 → 西日本サポートキュー、エントリ4: 条件なし → 東日本サポートキュー（デフォルト）の順に設定します。
シナリオ2：
営業チームは製品別に専門化されていますが、リードは最初は製品が不明です。
推奨設計：
フェーズ1（初期受付）として未分類リードキューを作成し、インサイドセールスチームをメンバーに設定してリードの質問・分類を行います。フェーズ2（専門チーム）として製品Aスペシャリストキュー、製品Bスペシャリストキュー等を作成します。
ワークフローは、新規リード → 未分類リードキュー → インサイドセールスが連絡・分類 → 製品が判明 → 該当製品キューに手動移動 → スペシャリストが商談化、となります。
まとめ
キューは、チームベースの業務フローを効率化する重要な機能です。
重要ポイント
- キューの目的 - 複数ユーザーでレコードを共有、柔軟な割り当てと負荷分散、チーム全体での処理効率化
- 適切な設計 - 明確な命名規則、ロール/グループを活用したメンバー構成、具体的条件を先に配置した割り当てルール
- 効果的な運用 - ダッシュボードで監視、定期的なキューの見直し、メンバーの定期更新
- 制限の理解 - サポート対象オブジェクトは限定的、キューのネストは不可、適切な権限設定が必要
設計のチェックリスト
- キューの目的は明確か
- メンバー構成は適切か（ロール活用）
- 命名規則は統一されているか
- 割り当てルールの順序は正しいか
- デフォルトの割り当て先は設定されているか
- 監視方法は確立されているか
- ドキュメントは作成したか
- ユーザーへのトレーニングは完了したか
次のステップ
キューを理解したら、次は以下のトピックに進みましょう：
- パブリックグループ - より柔軟なユーザーグループの管理
- 割り当てルールの詳細 - 複雑な条件での自動割り当て
- 承認プロセス - キューと連携したワークフロー