このドキュメントでは、Google Cloud で API を活用したモバイルゲーム バックエンドを実行するためのベスト プラクティスについて説明します。このドキュメントでは、ゲーム デベロッパーがモバイルゲームのオンライン アーキテクチャを設計する際の開始点として使用できる参考情報を提供しています。このドキュメントのベスト プラクティスは、すべての種類のモバイルゲームに適用できます。ただし、このドキュメントではゲームの進行状況とアカウント情報をデータベースに格納し、ゲーム デベロッパーが作成したカスタム インターフェース API を介してそのデータにアクセスするゲームに焦点を当てています。
このドキュメントでは、Niantic のポケモン GO、Nintendo のスーパーマリオ ラン、King のキャンディー クラッシュなどのモバイル ビデオゲームを開発するチームを対象としています。このドキュメントで説明するベスト プラクティスは、運が左右するゲーム（カードゲームとカジノゲーム）やファンタジー スポーツアプリ（架空のサッカーゲームなど）を対象としていません。通常、これらのゲームは一般的なウェブアプリやソーシャル アプリのようにスケーリングされます。
ヒットドリブンな性質を持つゲームは、ピーク期間に需要が急増することがあります。アプリはアプリストアで特集される、またはストリーミング コミュニティで支持される可能性があるため、成功による障害発生のシナリオを検討し、ゲームの人気が拡大した場合のスケーリングの明確な方法を確立しておくことが重要です。開発中に情報に基づいた意思決定を行うことで、リスクを最小限に抑えることができます。
予想されるユーザー負荷を見積もる
モバイルゲームのオンライン バックエンドを設計する際は、ユーザー負荷を可能な限り正確に見積もることが重要です。想定した負荷でリソースの大部分を使用するようにアーキテクチャを設計すると、大規模なゲーマー コミュニティからの関心を集めた結果、その需要を満たすためにスケーリングできず失敗する可能性があります。スケーリングに失敗すると、収益機会が失われ、スタジオの評判が損なわれる可能性があります。予想される負荷で適切に動作するアーキテクチャを設計するのは難しい場合がありますが、予期しない成功を収めた場合のスケーリングが容易になります。
ユーザー負荷の予測は常に多くのデータに基づいて行われますが、含めるべき重要なカテゴリは 2 つあります。
- プレーヤー数とプレイ セッションの頻度: これは一般的に、市場で類似のゲームをプレイしているプレーヤーの数と、マーケティング支出でユーザーを獲得するための予算に基づいて推測されます。
- 各プレーヤーによる API 負荷: これは包括的な負荷テストで測定できます。
最初の見積もりを行う
最初の見積もりを行う際は、次のような利用できるすべての要素を考慮します。
- 市場における過去のゲームや類似のゲームの成功
- 含まれる知的所有権（IP）の需要
- 市場にリリースされるタイミング
- アプリ ポートフォリオの残りの事前登録数または相互プロモーション数
- マーケティング予算
ユーザー数の見積もり後、ベストシナリオの 4 倍の見積もりを作成するのが一般的な手法です。ただし、ゲームの人気が急速に高まった、またはゲームが予期せぬ成功を収めた場合の成功による障害発生のシナリオを検討することをおすすめします。ユーザーの見積もりを 10 倍に増やす一部のスタジオもありますが、Google Cloud での過去のゲームリリースでは、見積もりを 20 倍、極端なケースでは 40 倍に増加しました。このような見積もりの数値が低くなりそうな場合でも、これらの数値を計算して、アーキテクチャがこれらのレベルにスケーリングできることを検証することが重要です。
負荷テストを実施する
予想されるユーザー数を知るだけでは、モバイルゲームのスケーリングのニーズを理解するには不十分です。実際の状況に可能な限り近い条件で負荷テストを実施することが重要です。負荷テストは、ほぼ最終版のゲームを使用して、クローズド ベータ版テスターで実施する必要があります。負荷テストで、ステート ストレージ データベースと API レイヤのパフォーマンスをプロファイリングして、十分なヘッドルームが使用可能であることを確認できます。多くの場合、実際のユーザーは、デベロッパーが予測できない使用パターンを作成します。そのため、大規模な負荷テストのモデルとして使用するために、プレーヤー使用状況のライブ プロファイリングを行うことが重要です。前のセクションで計算した初期見積もりで、ベータ版テストのユーザー パターンを再現するために、負荷テスト フレームワークを使用することをおすすめします。
大規模な負荷テストを行う場合は、ストレステストを予定している時間枠内で Google Cloud セールスチームに連絡して適切な Cloud カスタマーケア チケットを送信します。カスタマーケア チケットを送信すると、セールスチームは、ユーザーが必要に応じて割り当ての増加を事前にリクエストできるようにします。また、このサポートでは、Google Cloud プロダクトが想定どおりに動作しない場合に、カスタマーケア エンジニアが質問に回答できるようにします。
リファレンス アーキテクチャに対して検証する
次の図は、このドキュメントのベスト プラクティスに関するリファレンス アーキテクチャを示しています。
上の図では、ゲーム クライアントはロードバランサを介してモバイルゲームのバックエンドに接続しています。バックエンドはプレーヤー レコード データベースに直接接続しています。その前に、オプションの高速キャッシュ レイヤがあり、プレーヤーの進行状況、エンタイトルメント、その他のデータを保存および取得します。バックエンドは、オペレーション指標とログを Google Cloud Observability に出力します。この指標とログは、バックエンドのパフォーマンスのモニタリングに欠かせないものであり、データ ウェアハウスからもアクセスできます。分析の専門家は、BigQuery を使用してデータ ウェアハウスに直接アクセスでき、AutoML を使用して費用とチャーンの予測に使用するモデルを生成できます。これらの予測をゲームのバックエンドで利用できるようになります。次のコンポーネントについては、このドキュメントの後の部分で詳しく説明します。
- クライアント側の API に使用されるコンピューティング
- ステート ストレージに使用されるデータベース
- Google Cloud Observability のオブザーバビリティとモニタリング
- 分析
一部のモバイルゲームでは、専用のゲームサーバーまたは TURN / STUN サーバーを使用してリアルタイム マルチプレーヤー型ゲームを提供しています。このドキュメントのベスト プラクティスには明示的にそのようなサーバーは含まれていませんが、このベスト プラクティスはゲームサーバーと互換性があります。
コンピューティング オプション
Google Cloud には、App Engine などのフルマネージドのスケーラブルなオプションから、Google Kubernetes Engine（GKE）などの完全にカスタマイズ可能な環境まで、モバイルゲーム バックエンド用のコンピューティング オプションがいくつか用意されています。ニーズをよく理解し、それに応じて決定することが重要です。以下の各セクションのすべてのオプションは、Cloud Load Balancing と完全に統合されているため、HTTP(S) トラフィックでシームレスなスケーリングを利用できます。オプションには、エンタープライズ クラスの DDoS 保護などの Google Cloud Armor 機能も含まれます。
実績のあるスケーラブルなサーバーレス環境の App Engine を使用する
App Engine は Google Cloud のフルマネージド サーバーレス プラットフォームであり、基盤となるインフラストラクチャを管理する必要がなく、コードの記述に注力できます。ゲームのニーズに応じてスケーリングするように App Engine を構成できます。また、単一のコマンドでソースから直接ビルドおよびデプロイすることで、デベロッパーのイテレーション数を削減できます。App Engine は、小規模なチームやインフラストラクチャ運用のスケーリング経験の少ないチームに最適です。このことは Nintendo、Madfinger Games、Pocket Gems、Backflip Studios からのリリースを含め、複数のモバイルゲーム リリースを通じて幅広く実証されています。
App Engine がゲームに適しているかどうかを評価する際は、インスタンスがプレーヤーのクエリレートに基づいて開始 / 停止される可能性があることを理解することが重要です。そのため、サービス設計では、ユーザー リクエスト間でメモリに状態を保持するように計画することは回避する必要があります。リクエスト間で状態を保持する必要がある場合は、その状態をステート ストレージ データベース（次のセクションで説明）に保存して取得するか、Memorystore（Memcached または Redis）のような別のキャッシュを使用する必要があります。
App Engine アプリでは、他のランタイム環境で効率的に実行するために、追加の時間やリソースが必要になる場合があります。マルチクラウド環境またはハイブリッド クラウド環境でデプロイできる単一のランタイム ターゲットが必要な場合は、代わりに Cloud Run または Google Kubernetes Engine をおすすめします。
新しいサーバーレス アプリに Cloud Run を使用する
Cloud Run を使用すると、Kubernetes クラスタを管理することなく、ゲーム バックエンド用のコンテナで新しいアプリを開発できます。Cloud Run は、プレーヤーベースのリクエストニーズに合わせて API コンテナを自動的にスケーリングします。App Engine の多くのメリットがあり、インフラストラクチャが抽象化され、選択した構成に従ってスケーリングが自動的に処理される、フルマネージドのランタイム環境などが含まれます。オープン標準 Knative 上に構築されているため、Cloud Run を使用するときにポータブル サービスを簡単に作成できます。Cloud Run アプリは Kubernetes 上のコンテナで実行されます。そのため、今後さらに制御が必要になった場合、セルフマネージド Kubernetes への移行を明確に進めることができます。
GKE を使用してワークロードを完全に制御する
Google Kubernetes Engine は、制御を強化する必要があるデベロッパーや、経験豊富な運用チームと協力して作業するデベロッパー向けの一つの選択肢です。チームでアプリスタックに Kubernetes をすでに使用している場合は、GKE により、同じ Kubernetes インターフェースとコマンドライン インターフェース（CLI）を使用して、既存のサービスとともにゲームのバックエンドを実行できます。チームが複数のクラウドやオンプレミスでアプリを実行する場合は、GKE により、クラウド用に構築されたアプリ（クラウドネイティブ アプリ）に単一ターゲット プラットフォームが提供されます。Pokémon GO など、複数のゲームが、GKE 上で大規模なリリースに成功しています。
ステート ストレージ データベース
モバイルゲームのデータベースを選択する場合は、増加するプレーヤー数と拡大するゲームの複雑さのスケーリングと管理の方法を考慮に入れる必要があります。Spanner と Firestore は機能が豊富で、マネージド エクスペリエンスを提供し、大規模なモバイルゲームで成功した実績があります。Google Cloud では、マネージド MySQL データベースである Cloud SQL も提供されています。ただし、手動でのデータベースのシャーディングやクラスタリングでは、ステート ストレージ レイヤに著しい困難さと複雑さが生じる可能性があるため、Cloud SQL のスケーリングは困難な場合があり、不要なダウンタイムやお客様への影響につながります。
ユーザー同士で取引を行うグローバル ゲームに Spanner を使用する
Spanner は、無制限のスケーリング、強整合性、最大 99.999% の可用性を備えたフルマネージド リレーショナル データベースです。リレーショナル データベースの操作に慣れているデベロッパー向けに、SQL セマンティクスと使い慣れたインターフェースを備えています。Spanner はグローバルにデプロイできますが、リージョンでアクセスできるため、分散レプリカのパフォーマンスを維持しながら単一データベース インスタンスが簡素化されます。
Spanner は無限のスケーリングを提供するため、プレーヤー プロフィールやインベントリ ストレージに適しています。また、トランザクションの保証で、ゲームのプレーヤーに信頼性の高いプレーヤー間取引やオークションハウス機能を提供できます。Spanner では、デベロッパーのオンボーディングやデータベース管理を行うために、移行、開発、オブザーバビリティ、イントロスペクションのツールがいくつか用意されています。Spanner は、数百万の秒間クエリ数（QPS）まで徐々にスケールします。1 日目に 1,000 QPS を超えることが想定される大規模なリリースの場合、ウォームアップとベンチマークのベスト プラクティスに従うことをおすすめします。
Spanner は、10 億ユーザー規模のユースケースまでスケールでき、必要なパフォーマンスに合わせて柔軟にスケールを管理できます。Spanner はモバイルゲームの分野で数多く採用されています。ゲームで Spanner を使用する方法については、ゲーム データベースとして Spanner を使用する場合のベスト プラクティスをご覧ください。
Firestore 使用による開発速度向上と運用上のオーバーヘッド削減
Firestore はフルマネージドのスケーラブルな NoSQL ドキュメント データベースです。効率的なデベロッパー エクスペリエンスを提供し、新しい情報を保存する際にスキーマの更新は必要ありません。また、強整合性、トランザクションの保証、最大 99.999% の可用性も備えています。Firestore には、Firebase クライアント ライブラリを使用するモバイルゲームから直接アクセスすることもできます。
一般的なアプローチでは、プレーヤーごとに 1 つの Firestore ドキュメントを使用し、プレーヤーの進行状況をすべてゲーム設計に適した階層内にあるそのドキュメントに保存します。Firestore を使用するゲームを設計する場合は、Firebase の制限事項と Firestore のベスト プラクティスを検討してください。これらのベスト プラクティスに基づくと、同じドキュメントを頻繁に更新する必要があるワークロードが適さないことがあります。ポケモン GO などの非常に高スケーリングなゲームは、Firestore（旧称 Datastore）を使用したリリースに成功しています。これらのゲームでは、見積もられていたプレーヤー トラフィックの 50 倍を超える圧倒的な需要を満たすようにスケーリングできました。
Firestore では、スケーリングを自動的に処理できます。ただし、使用量が急増した場合（主要なマーケティング支出後など）にスムーズにスケーリングするには、Google Cloud アカウント マネージャーと事前に容量計画について話し合う必要があります。
パフォーマンスを最適化するためにキャッシュ保存を再評価する
パフォーマンスを最適化するために、データベースの前にインメモリ キャッシュを配置することが一般的なモバイルゲーム戦略となります。インメモリ キャッシュは、頻繁に読み取られるデータを保持するか、優先度の低い更新をバッチ処理します。この戦略では、アーキテクチャ設計の複雑さが増す可能性があります。また、読み取り / 書き込み負荷を処理できる Spanner や Firestore などのスケーラブルなマネージド データベースではこの戦略はあまり必要ありません。データベース アクセス パターンの負荷テストを行い、引き続きキャッシュが必要な場合は、Memorystore for Redis や Memcached などのマネージド オプションを検討して管理オーバーヘッドを削減してください。
コンプライアンス要件を満たすデータの局所性を選択する
世界中にプレーヤーがいる場合、多くのゲームは GDPR など地域のデータ保護法を遵守する必要があります。GDPR の要件に対応するため、Google Cloud と GDPR のホワイトペーパーを参照して、正しい Spanner または Firestore リージョン構成を選択してください。
オブザーバビリティ
オブザーバビリティは、早期に実装することをおすすめします。アプリとバックエンド インフラストラクチャのオブザーバビリティは、問題を速やかに見つけて修正する、開発サイクルを短縮する、および問題が発生した場合に顧客への影響を軽減するために重要です。Google Cloud Observability との連携に適した形式を開発の開始時に採用すると、時間と費用を節約できます。
オープンソース標準を使用してアプリの指標を Cloud Monitoring に取り込む
すべての Google Cloud リソースが、すでに計測手法を Cloud Monitoring に統合している場合は、Google Cloud コンソールに表示されます。したがって、モバイルゲーム バックエンドも計測可能にして、Cloud Monitoring と統合することをおすすめします。Cloud Monitoring と統合することで、インフラストラクチャとアプリ用の統合インターフェース（単一画面とも呼ばれます）のモニタリング ダッシュボードを使用できます。統合インターフェースを使用すると、インターフェースとアプリの主要な指標を並べて表示し、問題をすばやく見つけて切り離すことができます。
カスタム指標と分散トレースをアプリに実装する場合は、無料のオープンソース プロジェクトである OpenTelemetry（旧称 OpenCensus）を使用することをおすすめします。OpenTelemetry は、多くの言語にわたり指標とトレースを収集するためのベンダーニュートラルなサポートを提供するものであり、Cloud Monitoring や Cloud Trace を含む多くのオブザーバビリティ プロダクトにそれらをエクスポートできます。詳細については、OpenCensus によるカスタム指標をご覧ください。
構造化ロギングを使用する
ロギング形式を選択する場合は、構造化ロギングを使用し、関心があるログの特徴を JSON フィールドに並べ替えることをおすすめします。この実装により、Cloud Logging でログを速やかに並べ替え、検索、フィルタリングできます。多くのプログラミング言語には、Cloud Logging にエクスポートできる一般的な構造化ロギングのライブラリやモジュールがあります。Google Cloud には、多数の汎用的な Logging クライアント ライブラリも用意されています。
BigQuery ログシンクを作成する
ログを後で分析する必要がある場合、または運用しているリージョンでのデータ保持法によりログを保持する必要がある場合は、事前にログの BigQuery シンクを設定します。BigQuery には、シンクの作成後に生成された新しいログのみが書き込まれます。大量のログを BigQuery に書き込む場合は、パーティション分割テーブルを使用するオプションを選択することをおすすめします。
分析
今後のために、分析の形式を決めることをおすすめします。ゲームによってアナリティクス バックエンドに書き込まれるイベントと指標を決める場合は、分析情報のデータを引き出すための最も簡単な形式を考慮します。抽出、変換、読み込み（ETL）を使用すると、アプリが分析クエリに適した形式に書き込むデータをコピーできますが、これには時間と費用がかかる場合があります。分析出力形式の設計に投資すると、費用を大幅に削減し、リアルタイムの分析情報を取得できる可能性があります。スクエア エニックス、King、Line Games のプレゼンテーションや事例紹介を確認することをおすすめします。こうしたプレゼンテーションから、Google Cloud の分析プロダクトを使用したモバイルゲーム改善についての実世界の分析情報が得られます。
既存の形式にバッチ処理を使用する
制御できない出力形式の指標データ（たとえば、サードパーティ統合またはサービスからのデータ）を分析する場合は、指標データを Cloud Storage に保存することから始めることをおすすめします。データ形式がサポートされている場合は、BigQuery 連携クエリを使用して BigQuery インターフェースから直接クエリできます。データ形式がサポートされていない場合は、ETL を使用して、Dataflow またはその他のツールを使用することにより Cloud Storage からデータをコピーし、生成された書式設定済みのデータを他のソースのデータとともに BigQuery に保存できます。リアルタイムでデータが緊急に必要な場合を除き、コストを節約するためにストリーミングではなく定期的なバッチジョブを設定することをおすすめします。このアプローチの詳細については、分析イベントとログの大規模取り込みの最適化をご覧ください。
実績のあるモデルでチャーンと支出を予測する
Remote Config、アプリ内メッセージング、Firestore クライアント ライブラリなど、その他多数の Firebase 機能のいずれかをすでにモバイルゲーム用にご利用になっていることが考えられます。Firebase には、組み込みのチャーンおよび費用の予測 ML モデルも用意されています。Remote Config のカスタマイズを統合して分析データに ML を適用し、ユーザーの予測される行動に基づいて動的ユーザー セグメントを作成できます。このデータを使用して他の Firebase 機能をトリガーする、または BigQuery にエクスポートして柔軟性を高めることが可能です。
AutoML Tables カスタムモデル トレーニング用のデータの正規化
効果的な ML モデルを生成するには、通常、関連する特徴を選択し、ハイパーパラメータを調整するために、ML についての広範な専門知識が必要です。ただし、データ準備のガイドラインに沿うことで、最新の自動化ツールの機能が向上し、ユーザーの操作を必要とせず、これらのタスクの処理により、有用なモデルが生成されます。モデルの生成後、Google Cloud でホストして、オンライン予測やバッチ予測を行うことができます。たとえば、プレーヤーがゲーム内で購入を行うか、プレイを終了するかを予測できるようになります。
分析イベントとプレーヤー データは、従来の分析クエリとビジネス インテリジェンス指標に役立ちますが、ML モデルのトレーニングには別の形式が必要です。モバイルゲームでの ML の一般的なユースケースは、プレーヤーが最初にゲームに課金するタイミングを予測するカスタムモデルを作成することです。AutoML Tables を使用すると、トレーニング プロセスが大幅に簡素化されます。一般的な概要については、AutoML Tables のドキュメントのトレーニング データの準備とトレーニング データを作成するためのベスト プラクティスをご覧ください。
複数のゲームスタジオやパブリッシャーは、日単位のロールアップ形式をトレーニングの基礎として使用することで、優れた結果を得ています。日単位のロールアップは、重要な分析イベントごとに 1 つのフィールドを持つ正規化された行形式になります。これには、プレーヤーがその日までにイベントをトリガーした累積回数が含まれます。この行には、プレーヤーがこれまでにトリガーしたすべての重要と思われるイベントの日単位のスナップショットと has made
a purchase フラグの true または false が表示されます
AutoML Tables のクイックスタート ドキュメントに記載されているプロセスを使用して、この方法でフォーマットされたデータをトレーニングすることで、高品質なモデルを構築できます。モデルに日次ロールアップ行を指定して、プレーヤーが購入する可能性がどの程度あるかを予測できます。データをフォーマットする同様の方法をさまざまなフラグと一緒に使用して、離脱や他のプレーヤーの振る舞いなど、さまざまな予測を行うようにモデルをトレーニングすることもできます。標準化されたデータ形式の構築に先行投資を行うと、モデルをすばやく試して、想像できるプレーヤーのアクションの予想に役立てることができます。このモデリングは、ゲームの収益化や、望ましいプレーヤー成果をもたらす機能の優先順位付けに役立つ可能性があります。
Spanner ゲーム データベースを分析する
Spanner を使用すると、管理者や分析の専門家がゲームのデータベース トラフィックに影響を与えることなくデータにアクセスできるようになります。BigQuery-Spanner 連携では、データのコピーや移動を行わずに、Spanner に存在するデータを BigQuery からリアルタイムでクエリできます。Spanner は、Dataflow テンプレートを使用したデータのエクスポートもサポートしており、Looker や Google Cloud コンソールで分析することや、任意の他の分析プラットフォームに保存することが可能です。
配信、通知、その他のトピック
モバイルゲームの開発は、多岐にわたります。すべての側面を 1 つのガイドで網羅することはできませんが、以降のセクションではその他の重要な考慮事項について説明します。
Cloud CDN を使用してゲームアセットを配信する
Cloud CDN は、ゲームアセットをモバイル クライアントに配信でき、Cloud Monitoring と Cloud Logging とのインテグレーション機能が組み込まれています。既存のベンダー関係がある場合、ほとんどの主要な CDN は配信元サーバーとして Cloud Storage を使用できます。
reCAPTCHA を使用した不正行為の防止
reCAPTCHA は技術的にはバックエンド インフラストラクチャの一部ではありませんが、クライアントへの有益な統合となる場合があります。適応課題を使用してアプリでの不正行為を低減します。モバイルゲームでは、自動化されたユーザー（bot）の登録数を削減するために頻繁に使用されます。詳細については、reCAPTCHA のドキュメントをご覧ください。
Firebase Cloud Messaging によるクライアントへのプッシュ通知
モバイルゲームでプッシュ通知を送信する、またはユーザーが相互にメッセージを送信できるようにする必要がある場合は、Firebase Cloud Messaging（FCM）の使用を検討してください。FCM は、メッセージを料金なしで確実に送信するためのクロス プラットフォーム メッセージング サービスです。また、このサービスを使用してデータ メッセージを送信することもできます。これにより、アプリコード内の処理を完全に確認できます。独自のメッセージング バックエンド アプリを作成することも、サーバーレスの Cloud Functions を使用してメッセージを作成し、Firebase Admin SDK または FCM サーバー プロトコルを使用して送信することもできます。
ゲーム構成の配信を簡素化する
モバイルゲームでゲームバランスを構成する一般的なアプローチは、ほとんどのゲームプレイ パラメータをデータで定義することです。その後、ドロップ率や武器攻撃力の統計情報などのパラメータを修正する必要がある場合に、クライアントに更新を安全に配信できます。Firebase Remote Config は、ユーザーがアプリの更新をダウンロードしなくてもアプリの動作と外観を変更できるように設計されています。これにより、アプリでデフォルト値を定義できます。この値を使用して、Firebase コンソールか Remote Config バックエンド API によるプログラムで、ユーザーベースのすべてまたは特定のセグメントをオーバーライドできます。
ゲームバランス向けに ML を評価する
ゲームバランスに ML を使用する研究により、GDC および他のイベントで発表された成功例がいくつか生まれました。これらのケーススタディの多くは、データ サイエンティストや ML エンジニアが構築したカスタム ソリューションを使用したものであり、経験豊富なチームでなければ簡単に再現できません。ゲームバランス向け、または AI の対戦相手として ML を評価する場合は、AutoML Tables などのツールを使用すると、ML についての高度な専門知識がなくてもカスタムモデルをテストできます。アイテムの選択や次の動きなど、プレーヤーの動作を予測するには、このドキュメントで前述した AutoML Tables モデル トレーニング用のデータの正規化と同様のアプローチを使用します。
次のステップ
- ゲームのための Google Cloud
- クラウド上のゲーム インフラストラクチャの概要
- リファレンス アーキテクチャ、図、ベスト プラクティスについては、Cloud アーキテクチャ センターをご確認ください。