州政府、地方自治体、教育機関のオンボーディングのベスト プラクティス

Last reviewed 2022-10-15 UTC

州政府、地方自治体、教育（SLED）機関には、他の企業と比べて独自の IT ニーズがあります。このガイドでは、SLED 機関の Google Cloud 環境と Google Workspace 環境の作成に関するオンボーディングの考慮事項とベスト プラクティスを定義します。このドキュメントは、組織で Google Cloud と Google Workspace または Google Workspace for Education の設定を担当する管理者を対象としています。

ID 管理の概要

Google Cloud 環境を作成する前に、Google Cloud での認証、認可、監査の仕組みを理解しておく必要があります。認証機能、アクセス制御機能、監査機能を提供するために 3 つのクラウド サービスが連携します。

  • Cloud Identity: 認証機能を提供します。組織で Google Workspace または Google Workspace for Education を使用している場合は、すでに Cloud Identity を使用しています。
  • Identity and Access Management: 認可機能を提供します。
  • Cloud Audit Logs: 監査機能を提供します。

Cloud Identity

Cloud Identity は Identity as a Service プロダクトであり、Google Cloud、Google Workspace、Google Workspace for Education のリソースにアクセスするユーザーとグループを一元的に管理できます。Cloud Identity には無料版と有料版（プレミアム）があります。Google Cloud へのオンボーディング プロセス中に、Cloud Identity は TXT レコードを使用してプライマリ ドメイン所有権の確認を行います。Cloud Identity を使用するメリットは次のとおりです。

  • Google Workspace 管理コンソールを使用してグループを作成、管理できます。
  • シングル サインオン（SSO）や 2 要素認証（2FA）などのアカウントのセキュリティ制御機能が提供されます。
  • SAML（Security Assertion Markup Language）と LDAP をサポートしているため、サードパーティ アプリケーションの ID プロバイダとして使用できます。

ID を設定する

推奨される ID 設定手順の概要は次のとおりです。

  1. Cloud Identity、Google Workspace、Google Workspace for Education をまだ使用していない場合は、最初に次のいずれかの登録ページから始めてください。

    管理者アカウントを使用してコンソール内チェックリストに移動します。

  2. Cloud Identity を使用してドメインの所有権を確認します。ドメインの所有権の証明では、Google Cloud リソース階層のルートノードとして機能する組織が自動的に作成されます。

    ドメインがすでに申請されていることを示すエラーが発生した場合は、ドメイン再申請プロセスを実施してください。このプロセスには最長 5 営業日かかることがあります。

  3. ドメインの所有権を確認したら、新しく作成した管理者アカウントで Google Workspace 管理コンソールにログインします。

  4. Google Cloud コンソールで新しい Google Cloud 組織を管理する組織管理者を指定します。

  5. Workforce Identity 連携

    または Cloud Identity を使用してユーザーを追加します。Cloud Identity では、次のいずれかの方法でユーザーを追加できます。

リソースの管理

このセクションでは、SLED 機関でリソースを管理するためのベスト プラクティスについて説明します。

一元的な Google Cloud リソース管理のアプローチを実装する

Google Cloud では、組織、フォルダ、プロジェクトで構成される階層状のコンテナ システムが提供されます。これらの構造内で、他のリソース（Compute Engine 仮想マシン（VM）、データベース、Cloud Storage バケットなど）を整理できます。この階層は、複数のリソースに共通するアクセス制御や構成設定などの要素を管理するのに役立ちます。これらのリソースは、Resource Manager を使用してプログラムによって管理できます。

多くの大規模な機関には、多数のプロジェクトが存在し、Google Cloud リソースを直接操作するユーザーが多数います。既存の IT ガバナンスとアクセス制御戦略を最大限にサポートするには、Google Cloud リソースの組織化を一元的に実施することをおすすめします。

組織ノードを使用してリソースを整理する

リソースは組織ノードをルートとして整理されます。フォルダは、組織ノードの下に最大 4 つのレベルでネストできます。これらのフォルダにはプロジェクトを含めることができます。プロジェクトの下には他のリソースが子として含まれています。各リソースの親は 1 つだけです。親リソースのアクセス制御ポリシーと構成を設定すると、子リソースは親リソースのポリシーと設定を継承します。

組織ノードを使用すると、ユーザーがドメイン内で作成するすべてのプロジェクトが特権管理者に表示されます。各プライマリ ドメインには 1 つの組織ノードがあります。デフォルトでは、Google Workspace の特権管理者には、組織のポリシーを設定するための取消不能なアクセス権が付与されています。IT とクラウドが個別に管理されている組織の場合、Google Workspace の特権管理者は、組織を管理する組織管理者を割り当てる必要があります。詳しくは、特権管理者アカウントのベスト プラクティスをご覧ください。

組織ノードを作成する前にプロジェクトを作成した場合は、これらの関連付けられていないプロジェクトを組織ノードに移行できます。

Google Cloud を使い始める際のデフォルト構成では、組織ノードは 1 つだけです。以降のセクションでは、単一の組織ノードと複数の組織ノードのアプローチを比較して説明します。これらのオプションの詳細については、Google Cloud ランディング ゾーンのリソース階層を決定するをご覧ください。

オプション 1: 単一の組織ノード

このオプションでは単一の組織ノードを Workspace ドメインにマッピングします。Workspace ドメインは IAM の信頼できる情報源です。各フォルダには、フォルダの管理者と個別のロールやその他のポリシーを設定できます。次の図は、単一の組織ノードを教育機関の例で示しています。必要に応じて、チームと環境のサブフォルダをさらに追加できます。

単一の組織ノード。

クロス プロジェクト ネットワークや共有イメージなどのグローバル リソースを組織内のすべてのユーザーからアクセスできるフォルダにホストできます。

詳しくは以下をご覧ください。

オプション 2: 個別の組織ノード

組織内の部門を、一元管理されない独立エンティティとして扱う場合は、個別の組織を作成することを検討してください。次の図は、個別の組織ノードを学校の例で示しています。

個別の組織ノード。

この構成を実装するには、school.edu と lab3.school.edu を個別のプライマリ Google Workspace ドメインとして設定します。これにより個別の組織ノードが作成されます。このオプションは、以下のすべての項目に該当する場合にのみ使用してください。

  • 個別の ID ドメインを維持する必要がある。
  • 2 番目の組織のアクセス制御、カスタムロール、請求、割り当て、構成の設定が、中央の school.edu 組織ノードから独立した状態にする必要がある。

IT ガバナンスを一元化している多くの組織では、2 つの独立した Google Cloud 環境を管理することで、さらなるオーバーヘッドが発生します。たとえば、管理者がポリシーの同期を維持している場合を除き、複数の組織ノード間で時間の経過に伴ってセキュリティ ポリシーが分割される可能性があります。

このアプローチによる影響の詳細については、単一の組織ノードを使用するをご覧ください。

フォルダを使用してリソースを整理する

フォルダを使用すると、Google Cloud リソースの整理、ポリシーの適用、管理権限の委任が可能になり、部門やチームの自律性を強化できます。フォルダによって、プロジェクトのグループに対するポリシーの管理とアクセスの制御を同時に行うことができます。フォルダ内にネストされたフォルダ、プロジェクト、およびリソースは、親フォルダのポリシーを継承します。

フォルダの使用が適切ないくつかのシナリオを以下に示します。

  • 組織に個別のビジネス ユニットがあり、それぞれに専用の IT グループがある。
  • Microsoft Active Directory などの LDAP ディレクトリに基づいて確立された構造にマッピングされている。
  • IT インフラストラクチャ、リサーチ コンピューティング、指導と学習など、使用例ごとにプロジェクトを分離する。

詳細については、Google Cloud リソースを管理するをご覧ください。

プロジェクトごとにリソースをまとめる

Google Cloud のリソースを割り当てて使用するには、リソースがプロジェクトに含まれている必要があります。プロジェクトとは、構築する対象をまとめて管理する 1 つの単位です。プロジェクトは、設定や権限に加え、アプリケーションに関する情報を記述したその他のメタデータで構成されます。同じプロジェクト内のリソースは、内部ネットワーク経由の通信によって連携します。各プロジェクトが使用するリソースは、他のプロジェクトからは分離されます。これらのリソースは、外部ネットワーク接続または共有 Virtual Private Cloud（VPC）ネットワークを介してのみリンクできます。

各 Google Cloud プロジェクトには次の属性が含まれます。

  • ユーザーが提供するプロジェクト名
  • プロジェクト ID（ユーザーまたは Google Cloud が指定）
  • Google Cloud から提供されるプロジェクト番号。

プロジェクトを作成するときには次の点を考慮してください。

  • プロジェクトの所有権を決定し、ワークロードやチームごとに個別のプロジェクトを作成します。
  • 個別のプロジェクトを使用して、アプリケーションを本番環境と非本番環境に分割します。このようにすることで、非本番環境で行われた変更は本番環境に影響せず、デプロイ スクリプトを使用して変更をプロモートまたは伝播させることができます。
  • コンピューティング リソースとデータリソースをラボ間で分離するか、またはラボ内の作業を分離します。この分離によって、完全な自律性とプロジェクト間のデータ分離が可能になります。これは、ラボが競合関係にあるステークホルダーと一緒に複数のプロジェクトに取り組んでいる場合に便利です。

プロジェクトを作成するときには、プロジェクトを請求先アカウントに関連付ける必要があります。新しいプロジェクトを既存の請求先アカウントに関連付けるには、対象の請求先アカウントに請求先アカウント管理者または請求先アカウント ユーザーのロールが必要です。

Active Assist を使用して大規模なリソースを管理する

一般的に、組織の拡大に伴い複雑さが増大します。プロジェクトは使用されなくなり、VM はアイドル状態になります。権限が付与されますが、不要になっても削除されません。複雑さを軽減するために、最新のアセット インベントリを維持し、Active Assist の推奨事項と分析情報を使用してこのインベントリを確認することをおすすめします。Active Assist は、アイドル状態の VM の検出、余分な IAM 権限の削除、未使用のプロジェクトの削除または再利用に関する推奨事項を提供します。

これらの推奨事項を使用すると、組織に大きなメリットをもたらす可能性があります。このようなメリットには、不要な支出の削減、セキュリティ リスクの低減、組織のパフォーマンスと管理性の向上などがあります。

すべての Google Cloud プロジェクトと関連リソースのインベントリと履歴にアクセスするには、Cloud Asset Inventory を使用します。アセット履歴は BigQuery または Cloud Storage にエクスポートできます。

アクセス制御の管理

このセクションでは、Google Cloud サービスと Google Workspace サービスへのアクセスを管理するためのベスト プラクティスについて説明します。

ポリシー管理にグループを使用する

IAM では、ポリシーで個人ではなくグループを使用することをおすすめします。チームメンバーが参加または離脱するときに、グループ メンバーシップを調整できます。また、適切なポリシー変更が自動的に行われます。このプラクティスを実装するには、職務に基づく Google グループを各プロジェクトまたはフォルダに作成します。次に、職務に必要な複数のロールを各グループに割り当てます。

グループを管理するには、特権管理者または代理管理者が Google Workspace 管理コンソールを使用できます。

最小権限を使用して信頼境界を作成する

プロジェクトの構造を決定するときには、IT の信頼境界を考慮します。この境界は、既存の IT ガバナンスやセキュリティ モデルに沿ったものになります。たとえば、組織内にエンジニアリング、ビジネス、法律などの部門があり、部門間の信頼境界を維持する必要がある場合を考えてみましょう。

最小権限のセキュリティ ベスト プラクティスを適用すると、ユーザー アカウントとサービス アカウントに対し、プロジェクト間で異なるロールを付与できます。ユーザーが 1 つのプロジェクトに対しては管理者レベルのアクセス権を持ち、他のプロジェクトに対しては閲覧者アクセス権のみが必要な場合は、許可ポリシーを使用してこれらのロールを明示的に定義できます。詳しくは、最小権限に関する IAM のガイダンスをご覧ください。

サービス アカウント、ロール、ポリシーを使用してリソースへのアクセスを管理する

大規模な組織では、セキュリティやネットワーク管理などのオペレーション チームが他の部門から分離されていることがよくあります。この分離を実現するには、使用するリソースの管理を他チームに委ね、最小権限の原則に沿った形でリソースを使用する必要があります。IAM とサービス アカウントを使用してこの分離を構成します。

IAM では、誰がどのリソースにどのレベルでアクセスできるかを定義することで、アクセス制御を管理します。許可ポリシーを作成して、ユーザーにロールを付与します。特定の Google Cloud リソースに対するきめ細かなアクセス権を設定するには、事前定義ロールを使用するか、カスタムロールを定義します。

Google Cloud では、デフォルトで Google Workspace の特権管理者に組織管理者のロールが割り当てられます。このロールは他のユーザーに権限を付与するために使用され、特権管理者ユーザー アカウントからは削除できません。特権管理者が付与する最も重要なロールはプロジェクト作成者のロールです。指定されたユーザーは独自のプロジェクトの作成を開始できます。

サービス アカウントの詳細については、サービス アカウントについてをご覧ください。

特権アカウントは控えめに作成する

最小権限の原則に従って、管理者の通常のアカウントとは別のアカウントに特権管理者ロールを割り当てます。たとえば、日々の活動のためには alex@school.edu を使用しますが、Google Workspace 管理コンソールや Google Cloud コンソールに変更を加える際には alex.admin@school.edu を使用する場合があります。

ワークロードの ID を作成する

Google Cloud ではサービス アカウントを使用して Google API 呼び出しを行い、ユーザーの認証情報が直接関与しないようにします。これらのアカウントは、ID とリソースの両方として次のように扱われます。

  • サービス アカウントが ID として機能するときは、ストレージ バケットなどのリソースにアクセスできるように役割を付与します。
  • サービス アカウントがリソースとして機能するときは、BigQuery データセットへのアクセス権を付与するのと同じ方法で、そのアカウントにアクセスする権限をユーザーに付与する必要があります。ユーザーには、所有者、編集者、閲覧者、またはサービス アカウント ユーザーのロールを付与できます。サービス アカウント ユーザーのロールが付与されているユーザーは、サービス アカウントでアクセスできるすべてのリソースにアクセスできます。

請求を管理する

Cloud 請求先アカウントには、セルフサービス（またはオンライン）アカウントと請求書発行（またはオフライン）アカウントの 2 種類があります。

セルフサービス アカウントの機能は次のとおりです。

  • お客様の国または地域でサポートされている場合、クレジット カード、デビットカード、ACH 口座振替などのお支払い方法でお支払いが行われます。
  • 費用は、Cloud 請求先アカウントに関連付けられているお支払い方法に自動的に請求されます。
  • セルフサービス アカウントは、Google のサポートなしで登録できます。
  • セルフサービス アカウントに関して生成されるドキュメントには、明細書、お支払い領収書、請求書などがあります。これらのドキュメントには、コンソールからアクセスできます。

請求書発行アカウントの機能は次のとおりです。

  • お支払いは小切手または電信送金で行われます。
  • 請求書は郵送またはメールで送られます。
  • 請求書とお支払い領収書にはコンソールからアクセスできます。
  • 請求書発行アカウントのご利用には一定の要件があります。詳しくは、請求書発行の対象をご覧ください。

以降のセクションでは、両方のタイプの Cloud 請求先アカウントに関するベスト プラクティスについて説明します。

分析のために Cloud Billing データを BigQuery にエクスポートする

使用量と費用を分析するには、BigQuery データセットに課金データをエクスポートします。

課金データを BigQuery にエクスポートすると、設定した上限を超えているプロジェクトを特定できます。課金対象のサービスの一覧をクエリすることもできます。たとえば次のクエリでは、当月に $0.10 以上を費やしたすべてのプロジェクトが一覧表示されます。

SELECT
  project.name,
  cost
FROM
  YOUR_BIGQUERY_TABLE
WHERE
  cost > 0.1 AND usage_month IN "YYYY-MM"
ORDER BY
   cost DESC

次のように置き換えます。

  • YOUR_BIGQUERY_TABLE はテーブル名に置き換えます。
  • YYYY-MM は現在の月と日付に置き換えます。例: 2022-10。

請求と予算の管理に単一の請求先アカウントを使用する

Google Cloud コンソールを使用して、Cloud 請求先アカウントを管理します。コンソールでは、お支払い方法や管理者の連絡先などのアカウント設定を更新できます。また、予算の設定、アラートのトリガー、お支払い履歴の表示、課金データのエクスポートなどを行うようにコンソールを構成することもできます。

ほとんどの組織では、すべてのプロジェクトに単一の請求先アカウントで対応できます。組織全体の割引は、請求先アカウントに関連付けられているすべてのプロジェクトに適用されます。Google に対して 1 回の支払いで毎月の請求書を決済できます。機関固有、部門固有、ラボ固有のプロジェクトに対しては、社内の IT チャージバック プロセスを使用して請求できます。

次の図は、この単一の請求先アカウントの仕組みを示しています。

単一の請求先アカウント

請求に関する考慮事項は、Google Cloud のプロジェクトとフォルダの整理方法にも影響する場合があります。内部コストセンターに応じて、次の図のように整理できます。

複数のフォルダを使用する。

この図では、コストセンター、部門、IT プロジェクトに関連付けられているすべてのプロジェクトとアセットが、フォルダによって識別されています。費用はプロジェクトごとに表示され、BigQuery への課金データのエクスポートにはプロジェクト ID が含まれます。

コストセンターで個別の請求書に対して支払いを行う必要がある場合や、組織で個別の通貨で支払う必要があるワークロードがある場合は、複数の請求先アカウントを検討してください。このアプローチでは、請求先アカウントごとに契約に署名するか、Google Cloud 販売パートナーとの契約が必要になる場合があります。

請求先アカウントのロールを割り当てる

請求先アカウントのロールは、請求先アカウントの管理に役立ちます。以下の請求に関するロールを組織レベルで特定のユーザーに割り当てることができます。

ロール 説明
請求先アカウント管理者 組織内のすべての請求先アカウントを管理します。
請求先アカウント作成者 組織内の請求先アカウントを作成します。
請求先アカウント ユーザー プロジェクトと請求先アカウントをリンクします。
プロジェクト支払い管理者 プロジェクトの請求先アカウントの割り当てと、プロジェクトの請求の無効化を行うためのアクセス権を付与します。
請求先アカウントの費用管理者 予算を管理し、請求先アカウントの費用情報を表示、エクスポートします（料金情報の表示とエクスポートはできません）。
請求先アカウント閲覧者 請求先アカウントの費用情報とトランザクションを閲覧します。

ユーザーが組織内のすべての請求先アカウントを閲覧できるようにするには、組織レベルで請求先アカウント管理者のロールを付与します。請求先アカウントを作成できるユーザーと作成方法を制限するには、請求先アカウント作成者のロールを使用し、この権限を持つユーザーを制限します。詳細については、請求先アカウントの登録、変更、閉鎖と請求アクセス制御の概要をご覧ください。

プロジェクトの請求先アカウントを変更するには、プロジェクトの請求先アカウントを変更する方法をご覧ください。

予算とアラートを作成して請求をモニタリングする

請求先アカウントと個々のプロジェクトをモニタリングするには、予算を作成し、課金管理者と課金ユーザーにメール通知アラートを送信します。

予算によってアラートが生成されますが、プロジェクトに対する請求はオフになりません。つまり、予算を超えても、引き続きプロジェクトが実行されます。プロジェクトが予算を超えて実行されている場合は、手動で請求を無効にする必要があります。また、予算はリアルタイムでは更新されないため、1～2 日は費用超過の問題が検出されないことがあります。

課金管理者または課金ユーザーではないユーザーに予算アラートを送信するには、Cloud Monitoring 通知チャンネルを構成します。

ラベルを使用してリソースを整理する

ラベルは、Google Cloud リソースの整理で役立つ Key-Value ペアです。ラベルは課金システムに転送され、BigQuery への課金データのエクスポートに含まれます。ラベルを使用すると、ラベル別に請求料金をクエリできます。

部門、カレッジ、ワークロード、ラボごとにリソースにラベルを追加すると、新しいプロジェクトごとに個別の請求先アカウントを作成しなくても、請求料金を適切なエンティティに関連付けることができます。ラベルの詳細については、ラベルの作成と管理をご覧ください。

割り当てと上限をモニタリングする

Google Cloud 内の多くのリソースが割り当てによって制限されます。たとえば、新しく関連付けられた請求先アカウントにリンクされている新しいプロジェクトには、Compute Engine 上の 8 つの仮想 CPU の割り当てがあります。Google Cloud コンソール で割り当ての使用状況をモニタリングできます。また、割り当ての増加をリクエストして、より多くのリソースや GPU などの新しいリソースにアクセスすることもできます。

ネットワークを管理する

このセクションでは、Google Cloud ネットワークを管理するためのベスト プラクティスについて説明します。

ネットワーキング アプローチを選択する

クラウド サービスを VPC で分離します。たとえば、VPC を使用してネットワークを設定します。このネットワークには、すべてのプロジェクトにまたがる共通のプライベート RFC 1918 IP 空間が含まれています。次に、任意のプロジェクトのインスタンスをこのネットワークまたはそのサブネットワークに追加します。新しいプロジェクトごとにデフォルトの VPC ネットワークが作成されます。このデフォルト ネットワークはテストや開発に適していますが、本番環境ではカスタム VPC ネットワークに置き換える必要があります。

また、Cloud VPN 接続を 1 つのネットワークに接続して、すべてのプロジェクトまたは一部のプロジェクトで使用することもできます。VPN 接続を使用して Google Cloud 固有の RFC 1918 IP 空間に接続するか、オンプレミス ネットワークの RFC 1918 IP アドレス空間を拡張します。

次の表に、Google Cloud で最も一般的な 2 つのネットワーキング オプションを示します。

ネットワーキング オプション 説明
ダイレクト ピアリング 登録済みの自律システム番号（ASN）とパブリック ルーティング可能な IP 接頭辞がある場合は、ダイレクト ピアリングを使用して Google に接続します。このオプションは、公共のインターネットと同じ相互接続モデルを使用します。ただし、公共のインターネットとは異なり、サービス プロバイダはありません。詳細については、Google のエッジ ネットワークをご覧ください。
キャリア ピアリング パブリック ASN がない場合や、サービス プロバイダを使用して Google に接続する場合は、キャリア ピアリングを使用します。キャリア ピアリングは、Google エッジ ネットワークとエンタープライズ クラスの接続を希望するお客様向けに設計されています。

多くの場合、下り（外向き）トラフィックに関連する費用を予測することは困難です。Internet2 Higher Educationの会員を支援するため、Google では、正規価格で計算されるインターネット下り（外向き）料金を、毎月の利用費用合計の最大 15% を上限として免除しています。この特典は、特定のインターネット下り（外向き）SKU に適用されます。

ネットワーキング オプションの詳細については、ネットワーク接続プロダクトの選択をご覧ください。

サポートが必要な場合

このセクションでは、Google のヘルプを利用する際のベスト プラクティスについて説明します。

ニーズに合ったサポートプランを選択する

組織のニーズを満たすサポートプランを選択し、サポートケースを作成できる適切な権限を持つユーザーを文書に記録します。

ベーシック サポートは、Google Cloud ユーザーであれば誰でも無料で利用できます。ベーシック サポートには課金サポートが含まれますが、テクニカル サポートは含まれません。テクニカル サポートを利用するには、テクニカル サポートプランを購入する必要があります。

Google Cloud テクニカル サポートプランは組織レベルでのみ購入できます。テクニカル サポートの料金は、組織内のすべてのプロジェクトに対してプロジェクト レベルで請求されます。

サポートプランの詳細な機能と費用の比較については、Cloud カスタマーケアをご覧ください。

SLED 機関の場合、少なくともスタンダード サポートプランを購入することをおすすめします。ただし、組織でビジネス クリティカルなワークロードを実行している場合は、エンハンスト サポートプランの購入を検討してください。エンハンスト サポートプランでは、年中無休 24 時間対応のカスタマーケアへのアクセス、Customer Support API を使用したケースの作成、ケースのエスカレーションが可能です。

組織では、テクニカル アカウント マネージャーが、ガイド付きオンボーディング、ケース管理、ケースのエスカレーション、毎月の運用の健全性の確認を支援できます。テクニカル アカウント マネージャーが必要だがプレミアム サポート ￥￥プランを希望しない場合は、Technical Account Advisor Service をおすすめします。

Google Cloud コンソールを使用してスタンダード サポートとエンハンスト サポートを購入できます。プレミアム サポートを購入する場合は、営業担当者にお問い合わせください。

サポートケースを作成してエスカレーションする

ケースを作成するには、Google Cloud コンソールまたは Cloud Support API を使用します（エンハンスト サポートまたはプレミアム サポートが必要です）。ケースを作成する際には、適切なサポートケースの優先度に留意してください。

ケースに適切な優先度をすでに設定しており、サポート プロセスで問題が発生した場合は、ケースをエスカレーションできます。ケースをエスカレーションする理由の一覧については、ケースをエスカレーションするをご覧ください。

プレミアム サポート サービスをご利用の場合は、各地域の営業時間内にテクニカル アカウント マネージャーにお問い合わせいただき、エスカレーションをリクエストすることもできます。

次のステップ