ドキュメント : 開発ガイドライン

ドキュメント

項目	内容
共有サービスである事の制限	mobile backendは共有サービスのため、他のお客様の利用により、パフォーマンスなど影響を受ける可能性があります。
システム安定稼働に対するサービス運営方針	富士通クラウドテクノロジーズ（以下、FJCT）では上記のように、一部のお客様のご利用によって他のお客様への影響がでないようサービス運営をしております。その為、システム全体への高負荷が予想されるお客様については、未然にパフォーマンス低下を防ぐため改善勧告を行う事がございます。改善勧告の一例として、スロークエリ（クラスに大量データが入っていたり、クラスに対する検索内容が複雑で、ニフクラ mobile backendに負荷がかかり、レスポンスに時間がかかっているリクエスト）が大量に発生していたお客様に対してご連絡する場合がございます。また、突発的に負荷が高まった際はやむを得ない場合に限り、利用規約に則りサービスの一時停止などの処置も行いますので、サービスご利用の際はパフォーマンスチューニングの実施をお願いいたします。尚、Expertプラン以上のお客様につきましては、テクニカルサポートにてパフォーマンス向上のアドバイスを行わせて頂く事も可能です。
Basicプランにおけるアプリ自動削除	Basicプランを利用している場合、お客様の本サービス最終ログイン時点および本サービス上にお客様が作成したいずれかのアプリケーションへの最終アクセス時点から起算して30日が経過した時点において、全アプリケーションは自動削除されます。なお、「アプリケーションへのアクセス」はAPIリクエスト消費を指し、スクリプトAPIコール数のみの利用は含まれません。
アプリ作成数の制限	プランに関わらず、1アカウントにて利用可能なアプリ数は2,000件です。 ※削除されたアプリは件数に含まれません。
ログの提供について	ログそのものの提供は行っておりません。但し、具体的なご要望があれば、テクニカルサポートにて調査することが可能な場合もございます。（調査可能期間：直近1ヶ月以内）例：あるIPアドレスからの管理画面へのログイン回数　等

　項目　　　　　　

　　　　　内容　　　

共有サービスである事の制限

mobile backendは共有サービスのため、他のお客様の利用により、パフォーマンスなど影響を受ける可能性があります。　

システム安定稼働に対するサービス運営方針

富士通クラウドテクノロジーズ（以下、FJCT）では上記のように、一部のお客様のご利用によって他のお客様への影響がでないようサービス運営をしております。
その為、システム全体への高負荷が予想されるお客様については、未然にパフォーマンス低下を防ぐため改善勧告を行う事がございます。
改善勧告の一例として、スロークエリ（クラスに大量データが入っていたり、クラスに対する検索内容が複雑で、ニフクラ mobile backendに負荷がかかり、レスポンスに時間がかかっているリクエスト）が大量に発生していたお客様に対してご連絡する場合がございます。
また、突発的に負荷が高まった際はやむを得ない場合に限り、利用規約に則りサービスの一時停止などの処置も行いますので、サービスご利用の際はパフォーマンスチューニングの実施をお願いいたします。
尚、Expertプラン以上のお客様につきましては、テクニカルサポートにてパフォーマンス向上のアドバイスを行わせて頂く事も可能です。

Basicプランにおけるアプリ自動削除

Basicプランを利用している場合、お客様の本サービス最終ログイン時点および本サービス上にお客様が作成したいずれかのアプリケーションへの最終アクセス時点から起算して30日が経過した時点において、全アプリケーションは自動削除されます。なお、「アプリケーションへのアクセス」はAPIリクエスト消費を指し、スクリプトAPIコール数のみの利用は含まれません。

アプリ作成数の制限

プランに関わらず、1アカウントにて利用可能なアプリ数は2,000件です。
※削除されたアプリは件数に含まれません。　

ログの提供について

ログそのものの提供は行っておりません。
但し、具体的なご要望があれば、テクニカルサポートにて調査することが可能な場合もございます。（調査可能期間：直近1ヶ月以内）
例：あるIPアドレスからの管理画面へのログイン回数　等

項目	内容
レスポンスタイムの保証	レスポンスタイムの保証はございません。パフォーマンスが出ない場合はリクエスト内容の見直しや、対象クラスの保持オブジェクトの数やサイズの見直し、追加インデックス（有償オプション）の利用などをお客様にてご検討ください。また、Expertプラン以上のお客様につきましては、テクニカルサポートにてパフォーマンス向上のアドバイスを行わせて頂く事も可能です。
レスポンスの保証	レスポンスに関して、Basicプランのお客様には一切の保証をしておりません。 Expertプラン以上のお客様にはSLAを定めております。いずれの場合も100％の保証は行っておりませんので、アプリ側で適切なエラーハンドリングとリトライを実装してください。エラーについてはこちらをご覧ください。
タイムアウト時間	APIのタイムアウト時間は公開しておりません。 ※非公開としているのは、タイムアウト等のエラー発生時はエラー発生原因に基づくエラーコードを返却し、タイムアウト時間を意識せずにお使いいただける仕様であるためでございます。なお、SDKに関しては、レスポンス遅延によるアプリへの影響を防ぐためにタイムアウト値を設けております。（詳細はこちらをご覧ください。）SDKを使用せずに直接APIを利用される場合に、レスポンス遅延によるアプリへの影響にご配慮いただく場合は、お客様にてタイムアウトの処理をアプリに組み込んでください。
同時接続数制限	mobile backendでは同時接続数に制限を設けておりますが、制限数の公開はしておりません。なお、制限数に達した場合、一時的にエラーが発生いたします。同月内に複数回上限に達した場合でも、それ以降のリクエストが来月までエラーとなる仕様ではございません。
流量制限	mobile backendでは流量に関して制限を設けておりますが、制限数の公開はしておりません。なお、制限数に達した場合、一時的にエラーが発生いたします。同月内に複数回上限に達した場合でも、それ以降のリクエストが来月までエラーとなる仕様ではございません。
サポートしているSSL/TLSのバージョン	・SSLv1, v2, v3 / TLSv1.0, v1.1 使用不可・TLSv1.2 使用可
複数件処理について	mobile backendでは複数オブジェクト更新APIは提供しておりません。以上から、トランザクション処理の提供も行っておりません。
APIリクエストの消費について	SDK／API経由でのアクセス時、APIリクエストが消費されます。管理画面経由でのアクセス時にはAPIリクエストは消費されませんが、例外的にREST APIツール経由でのアクセス時はAPIリクエストを消費いたします。また、スクリプトを管理画面で実行しても、スクリプトAPIコール数・スクリプト累計処理時間は消費されません。

　項目　　　　　　

　　　　　内容　　　

レスポンスタイムの保証　　　　

レスポンスタイムの保証はございません。
パフォーマンスが出ない場合はリクエスト内容の見直しや、対象クラスの保持オブジェクトの数やサイズの見直し、追加インデックス（有償オプション）の利用などをお客様にてご検討ください。
また、Expertプラン以上のお客様につきましては、テクニカルサポートにてパフォーマンス向上のアドバイスを行わせて頂く事も可能です。　

レスポンスの保証　　　　

レスポンスに関して、Basicプランのお客様には一切の保証をしておりません。
Expertプラン以上のお客様にはSLAを定めております。
いずれの場合も100％の保証は行っておりませんので、アプリ側で適切なエラーハンドリングとリトライを実装してください。
エラーについてはこちらをご覧ください。　

タイムアウト時間

APIのタイムアウト時間は公開しておりません。
※非公開としているのは、タイムアウト等のエラー発生時はエラー発生原因に基づくエラーコードを返却し、タイムアウト時間を意識せずにお使いいただける仕様であるためでございます。なお、SDKに関しては、レスポンス遅延によるアプリへの影響を防ぐためにタイムアウト値を設けております。（詳細はこちらをご覧ください。）SDKを使用せずに直接APIを利用される場合に、レスポンス遅延によるアプリへの影響にご配慮いただく場合は、お客様にてタイムアウトの処理をアプリに組み込んでください。

同時接続数制限

mobile backendでは同時接続数に制限を設けておりますが、制限数の公開はしておりません。
なお、制限数に達した場合、一時的にエラーが発生いたします。
同月内に複数回上限に達した場合でも、それ以降のリクエストが来月までエラーとなる仕様ではございません。

流量制限

mobile backendでは流量に関して制限を設けておりますが、制限数の公開はしておりません。
なお、制限数に達した場合、一時的にエラーが発生いたします。
同月内に複数回上限に達した場合でも、それ以降のリクエストが来月までエラーとなる仕様ではございません。

サポートしているSSL/TLSのバージョン

・SSLv1, v2, v3 / TLSv1.0, v1.1 使用不可
・TLSv1.2 使用可

複数件処理について

mobile backendでは複数オブジェクト更新APIは提供しておりません。
以上から、トランザクション処理の提供も行っておりません。

APIリクエストの消費について

SDK／API経由でのアクセス時、APIリクエストが消費されます。管理画面経由でのアクセス時にはAPIリクエストは消費されませんが、例外的にREST APIツール経由でのアクセス時はAPIリクエストを消費いたします。また、スクリプトを管理画面で実行しても、スクリプトAPIコール数・スクリプト累計処理時間は消費されません。

項目	内容
オブジェクトサイズの制限	システム制限：16MB 登録可能なサイズ上限の目安：10MB程度巨大なオブジェクトに対して更新処理を行うと高負荷が発生する恐れがあるので実施を控えるよう推奨いたします。
オブジェクト数の制限	システム制限：なしただし、多数のオブジェクトを登録すると更新や検索における性能劣化が予想されます。そのため、1クラスあたり、数十万件程度のオブジェクト数に抑えることを推奨いたします。 ※なお、データ構造・検索条件によっては、推奨値であっても性能劣化となることがございます。性能向上のために、下記のような対策もご検討ください。　　1)定期的なデータのバックアップのうえ、不要データを削除していただく　　2)日時でクラスを分けるなど、複数クラスへのデータ分散を実施していただく　　　データのバックアップについては、エクスポート機能をご覧ください。
フィールドサイズの制限	フィールドのサイズ・文字数には制限はございません。 ※各フィールドサイズの合計が、オブジェクトサイズの制限(16MB)を超えないようご注意ください。
インデックスが無いフィールドでのソート制限	システム制限：ワーキングメモリ32MB以下内部データベース上でのソート処理で使用するメモリが32MBを超えた場合、ソートができませんので、インデックス機能のご利用をご検討ください。
登録および更新後、参照に反映されるまでの時間	内部データベースはレプリケーション構成を採っているため、登録／更新後すべてのデータベースに反映される時間にはタイムラグが存在します。また、更新中のオブジェクトを参照した場合は、更新前の値を返却します。
更新失敗時の挙動について	基本的にエラーが返却された際は、データの更新は行われておりません。（データは更新前の状態でございます。）但し、SDKのタイムアウト発生時や、バックエンドの過負荷、インフラ側のトラブル等が重なった場合などは上記の限りではなく、必ずしもデータのロールバックを保証するものではございません。予めご了承ください。
クラス名について	"class"、"user"、"role"、"installation"、"push"、"push_open_state"、"file"、もしくは"__mbaas_"で始まる名前のクラスを作成することはできません。また、一度作成したクラスのクラス名変更は行えません。ご希望の場合には、インポート・エクスポート機能等をご利用ください。
クラス作成数の制限	プランに関わらず、1アプリにて利用可能なクラス数は1,000件です。 ※削除されたクラスは件数に含まれません。
objectIDについて	objectIDはクラス内で一意性を保っておりますので、クラス間・アプリケーション間では同一のobjectIDが存在する可能性がございます。なお、自動生成されるobjectIDの桁数は、最大16桁・最小1桁です。 ※生成処理上、稀に桁数の少ないIDが生成されることがございます。また、フォーマットは「0~9,a~z,A~Z」を含む文字列です。
暗号化設定について	管理画面にてフィールドの暗号化設定をした場合は、弊社データベース上に対象データが登録される際、Blowfishアルゴリズムでの暗号化を実施します。但し、データを取得する際は復号処理を行っていますので、API/管理画面では復号された状態でデータが返却/表示されます。 ※参考：データストア基本的な使い方:暗号化の設定
データ型について	データ型が文字列の場合、記号を含む1バイト英数字、多バイト文字が利用できます。但し、バリデーションや制限がかかっているフィールドもあるため、必ずしもこの限りではないケースもあります。入力できる仕様に関しては、必ず各ドキュメントにてご確認ください。
ロールに所属できるユーザー数の最大件数	最大件数：20万程度となります。
所属ユーザーが削除された場合のロールの挙動	ロールの所属ユーザーが削除されても、ロール内部の当該ユーザーへの参照ポインタは削除されません。ロールの件数は、参照先ユーザー削除済みの件数も含めてカウントされます。 $relatedToで検索した際に、参照先ユーザーが存在しないポインタが対象に含まれた場合は無視されますので、ロールに所属しているユーザー情報を取得する際、そのロールにユーザーが100件登録されているにも関わらずlimit=10で検索した際に8件しか返却されないことなどが発生します。そのため、参照先ユーザーを削除する際には、ロールからも解除いただくようお願いいたします。

　項目　　　　　　

　　　　　内容　　　

オブジェクトサイズの制限　　　　

システム制限：16MB
登録可能なサイズ上限の目安：10MB程度
巨大なオブジェクトに対して更新処理を行うと高負荷が発生する恐れがあるので実施を控えるよう推奨いたします。　

オブジェクト数の制限　　　　

システム制限：なし
ただし、多数のオブジェクトを登録すると更新や検索における性能劣化が予想されます。
そのため、1クラスあたり、数十万件程度のオブジェクト数に抑えることを推奨いたします。

※なお、データ構造・検索条件によっては、推奨値であっても性能劣化となることがございます。
性能向上のために、下記のような対策もご検討ください。
　　1)定期的なデータのバックアップのうえ、不要データを削除していただく
　　2)日時でクラスを分けるなど、複数クラスへのデータ分散を実施していただく
　　　データのバックアップについては、エクスポート機能をご覧ください。

フィールドサイズの制限

フィールドのサイズ・文字数には制限はございません。
※各フィールドサイズの合計が、オブジェクトサイズの制限(16MB)を超えないようご注意ください。

インデックスが無いフィールドでのソート制限　　　　

システム制限：ワーキングメモリ32MB以下
内部データベース上でのソート処理で使用するメモリが32MBを超えた場合、ソートができませんので、インデックス機能のご利用をご検討ください。

登録および更新後、参照に反映されるまでの時間

内部データベースはレプリケーション構成を採っているため、登録／更新後すべてのデータベースに反映される時間にはタイムラグが存在します。
また、更新中のオブジェクトを参照した場合は、更新前の値を返却します。

更新失敗時の挙動について

基本的にエラーが返却された際は、データの更新は行われておりません。（データは更新前の状態でございます。）
但し、SDKのタイムアウト発生時や、バックエンドの過負荷、インフラ側のトラブル等が重なった場合などは上記の限りではなく、必ずしもデータのロールバックを保証するものではございません。予めご了承ください。

クラス名について

"class"、"user"、"role"、"installation"、"push"、"push_open_state"、"file"、もしくは"__mbaas_"で始まる名前のクラスを作成することはできません。
また、一度作成したクラスのクラス名変更は行えません。ご希望の場合には、インポート・エクスポート機能等をご利用ください。

クラス作成数の制限

プランに関わらず、1アプリにて利用可能なクラス数は1,000件です。
※削除されたクラスは件数に含まれません。

objectIDについて

objectIDはクラス内で一意性を保っておりますので、クラス間・アプリケーション間では同一のobjectIDが存在する可能性がございます。

なお、自動生成されるobjectIDの桁数は、最大16桁・最小1桁です。
※生成処理上、稀に桁数の少ないIDが生成されることがございます。
また、フォーマットは「0~9,a~z,A~Z」を含む文字列です。

暗号化設定について

管理画面にてフィールドの暗号化設定をした場合は、弊社データベース上に対象データが登録される際、Blowfishアルゴリズムでの暗号化を実施します。
但し、データを取得する際は復号処理を行っていますので、API/管理画面では復号された状態でデータが返却/表示されます。
※参考：データストア基本的な使い方:暗号化の設定

データ型について

データ型が文字列の場合、記号を含む1バイト英数字、多バイト文字が利用できます。
但し、バリデーションや制限がかかっているフィールドもあるため、必ずしもこの限りではないケースもあります。
入力できる仕様に関しては、必ず各ドキュメントにてご確認ください。

ロールに所属できるユーザー数の最大件数

最大件数：20万程度となります。

所属ユーザーが削除された場合のロールの挙動

ロールの所属ユーザーが削除されても、ロール内部の当該ユーザーへの参照ポインタは削除されません。
ロールの件数は、参照先ユーザー削除済みの件数も含めてカウントされます。
$relatedToで検索した際に、参照先ユーザーが存在しないポインタが対象に含まれた場合は無視されますので、ロールに所属しているユーザー情報を取得する際、そのロールにユーザーが100件登録されているにも関わらずlimit=10で検索した際に8件しか返却されないことなどが発生します。
そのため、参照先ユーザーを削除する際には、ロールからも解除いただくようお願いいたします。

項目	内容
in, nin inArray, ninArray	条件の配列に多くの要素を指定した場合、レスポンス時間が遅くなり、システム全体への負荷に繋がる可能性があります。以上から、条件の配列の要素数は5,000件以下にすることを推奨します。 ※インデックス付与済みのフィールドを想定した推奨値です。 ※リクエスト頻度やアプリが持つデータ件数にも依存するためあくまで目安であり、必ずしも安全性を保証する値ではありません。
or	同一フィールドでの複合条件検索には適さないため、使用しないでください。 (例)プッシュ通知登録の絞り込み条件にて、指定したobjectIdのいずれかに該当する配信端末にプッシュ通知を送信する条件を指定する。 NGケース："searchCondition" : { "$or": [ { "objectId" : "AAA" },{ "objectId" : "BBB" },… ] } 上記事例については、$inオペレータを用いることで指定可能です。 "searchCondition" : { "objectId" : { "$in" : [ "AAA", "BBB",… ] } }
include	1つだけ指定する利用方法を想定しています。カンマ区切りで複数指定することも可能ですが、前に指定されたものから順に検査され最初に置き換えができたものだけが子要素に置き換えられます。2つ以上指定した場合に1つ目が正常に子要素に置き換えられると、2つ目はポインタのまま返却されます。
order	orderを指定しない場合の並び順は「natural order」であり、DB上のデータ並び順に従います。更新等の書き換え処理によって順番が変わることがあるため順序の保証はありません。内部データベースの制限事項にもある通り、ソート処理には制限事項があるためインデックスのあるフィールドをorderに指定することを推奨します。
limit	0-1000を指定できます。 limitに大きな値が設定されていると取得件数(それに伴うデータ量)が多くなるため、レスポンス時間も遅くなります。レスポンス遅延はmobile backendシステム全体への負荷ともなりうるため、limitの値については適切な値を設定し、必要件数分以上のデータを取得しないようお願いいたします。
limit&skip	skipの分だけ読み飛ばして、limit分を返却するため、skipが大きくなるに従ってパフォーマンスが劣化します。

　項目　　　　　　

　　　　　内容　　　

in, nin
inArray, ninArray　　　

条件の配列に多くの要素を指定した場合、レスポンス時間が遅くなり、システム全体への負荷に繋がる可能性があります。
以上から、条件の配列の要素数は5,000件以下にすることを推奨します。
※インデックス付与済みのフィールドを想定した推奨値です。
※リクエスト頻度やアプリが持つデータ件数にも依存するためあくまで目安であり、必ずしも安全性を保証する値ではありません。　

同一フィールドでの複合条件検索には適さないため、使用しないでください。
(例)プッシュ通知登録の絞り込み条件にて、指定したobjectIdのいずれかに該当する配信端末にプッシュ通知を送信する条件を指定する。
NGケース："searchCondition" : { "$or": [ { "objectId" : "AAA" },{ "objectId" : "BBB" },… ] }
上記事例については、$inオペレータを用いることで指定可能です。
"searchCondition" : { "objectId" : { "$in" : [ "AAA", "BBB",… ] } }　

include　　　

1つだけ指定する利用方法を想定しています。
カンマ区切りで複数指定することも可能ですが、前に指定されたものから順に検査され最初に置き換えができたものだけが子要素に置き換えられます。2つ以上指定した場合に1つ目が正常に子要素に置き換えられると、2つ目はポインタのまま返却されます。　

order　　　

orderを指定しない場合の並び順は「natural order」であり、DB上のデータ並び順に従います。
更新等の書き換え処理によって順番が変わることがあるため順序の保証はありません。
内部データベースの制限事項にもある通り、ソート処理には制限事項があるためインデックスのあるフィールドをorderに指定することを推奨します。　

limit　　　

0-1000を指定できます。
limitに大きな値が設定されていると取得件数(それに伴うデータ量)が多くなるため、レスポンス時間も遅くなります。
レスポンス遅延はmobile backendシステム全体への負荷ともなりうるため、limitの値については適切な値を設定し、必要件数分以上のデータを取得しないようお願いいたします。

limit&skip　　　

skipの分だけ読み飛ばして、limit分を返却するため、skipが大きくなるに従ってパフォーマンスが劣化します。　

項目	内容
データ保持形式	リレーションは「ポインタの配列」としてオブジェクト内に保持されるため、巨大なリレーションを作成すると、それを保持するオブジェクトも巨大化します。データ検索時のパフォーマンス低下を防ぐため、数千件といった大量リレーションの作成は推奨しておりません。 (例)Childrenクラスのあるレコードのrelationフィールドに、ParentクラスのobjectId:AAA,BBBの2レコードをAddRelationした場合のrelationフィールド内のデータは、以下の通りです。 [{"type":"Pointer","className":"Parent","objectId":"AAA"},{"type":"Pointer","className":"Parent","objectId":"BBB"}]
リレーションの最大件数	最大件数：20万程度となります。
参照先オブジェクトが削除された場合のリレーション型の挙動	リレーション型の参照先オブジェクトが削除されても、リレーション型内部の当該オブジェクトへの参照ポインタは削除されません。リレーションの件数は、参照先オブジェクト削除済みの件数も含めてカウントされます。参照先オブジェクトを削除する際には、リレーションからも解除いただくようお願いいたします。 ※データ保持形式の項目で(例)として記載したデータの場合、ParentクラスのobjectId:AAAのレコードが削除されても、RemoveRelationを実施しないとrelationフィールド内のデータは以下のままとなります。 [{"type":"Pointer","className":"Parent","objectId":"AAA"},{"type":"Pointer","className":"Parent","objectId":"BBB"}] 以上から$relatedToで検索した際に、参照先オブジェクトが存在しないポインタが対象に含まれた場合は無視されますので、そのリレーションにポインタが100件登録されているにも関わらずlimit=10で検索した際に8件しか返却されないことなどが発生します。
「ポインタの配列」内を検索する際の挙動	「ポインタの配列」内を検索する場合（$relatedToを用いた検索の場合）、以下の様に通常の検索時の挙動と異なる点がありますのでご注意ください。 (1)検索する際は、「ポインタの配列」内の【skipの値】件目～【limitの値】件目のポインタを取得し、それらのポインタの参照先オブジェクトを返却します。更に($relatedTo以外の)別の検索条件を指定していた場合は、その取得してきた参照先オブジェクトの中から検索条件に合致したオブジェクトを返却します。 ※skip、limitを指定していない場合は、デフォルト値であるskip=0、limit=100が適用されます。 (2)「count」は「ポインタの配列」内の全ポインタ件数ではなく、実際に取得した参照先オブジェクトの件数を表します。 (3)「order」は「ポインタの配列」内の全ポインタを並び替えてから検索処理を行うのではなく、検索によって取得した参照先オブジェクトのみを並び替えします。 (4)「ポインタの配列」内の全ポインタの参照先オブジェクトに対して検索を実施したい場合は、skip、limitを用いて複数回検索リクエストを実施していただきますよう、お願いいたします。（例）2000件のリレーションデータに対して検索を行う場合は、以下の通り2回の検索を行ってください。 ①skip=0,limit=1000での検索/②skip=1000,limit=1000での検索 (5)リレーションデータ件数については、管理画面にて確認が可能です。リレーションデータ件数をAPIにて取得されたい場合は、返却される参照先オブジェクトの件数(countの値)がlimitで指定した値未満(limitを指定しない場合は100件未満)となるまで複数回($relatedTo以外の)検索条件指定なしの検索(全件検索)を実施してください。countの値の合計がリレーションデータ件数となります。 ※「参照先オブジェクトが削除された場合のリレーション型の挙動」に記載の仕様であることから、参照先オブジェクトが存在しないポインタは必ずRemoveRelationで削除されていることが前提となります。 (6)(1)より、管理画面にて「リレーションを見る」をクリックし遷移した先の画面で「絞り込み」からレコードの検索を実施される場合、管理画面側でlimitの値が指定されてしまうため、本来検索条件に合致する参照先オブジェクトが存在するはずであっても、検索結果として表示されないケースがあります。上記は、巨大なリレーションの操作による負荷を考慮した仕様です。予めご了承ください。

　項目　　　　　　

　　　　　内容　　　

データ保持形式　　　　　

リレーションは「ポインタの配列」としてオブジェクト内に保持されるため、巨大なリレーションを作成すると、それを保持するオブジェクトも巨大化します。データ検索時のパフォーマンス低下を防ぐため、数千件といった大量リレーションの作成は推奨しておりません。
(例)Childrenクラスのあるレコードのrelationフィールドに、ParentクラスのobjectId:AAA,BBBの2レコードをAddRelationした場合のrelationフィールド内のデータは、以下の通りです。
[{"type":"Pointer","className":"Parent","objectId":"AAA"},{"type":"Pointer","className":"Parent","objectId":"BBB"}]

リレーションの最大件数

最大件数：20万程度となります。

参照先オブジェクトが削除された場合のリレーション型の挙動　　　　　

リレーション型の参照先オブジェクトが削除されても、リレーション型内部の当該オブジェクトへの参照ポインタは削除されません。
リレーションの件数は、参照先オブジェクト削除済みの件数も含めてカウントされます。参照先オブジェクトを削除する際には、リレーションからも解除いただくようお願いいたします。
※データ保持形式の項目で(例)として記載したデータの場合、ParentクラスのobjectId:AAAのレコードが削除されても、RemoveRelationを実施しないとrelationフィールド内のデータは以下のままとなります。
[{"type":"Pointer","className":"Parent","objectId":"AAA"},{"type":"Pointer","className":"Parent","objectId":"BBB"}]

以上から$relatedToで検索した際に、参照先オブジェクトが存在しないポインタが対象に含まれた場合は無視されますので、そのリレーションにポインタが100件登録されているにも関わらずlimit=10で検索した際に8件しか返却されないことなどが発生します。

「ポインタの配列」内を検索する際の挙動

「ポインタの配列」内を検索する場合（$relatedToを用いた検索の場合）、以下の様に通常の検索時の挙動と異なる点がありますのでご注意ください。

(1)検索する際は、「ポインタの配列」内の【skipの値】件目～【limitの値】件目のポインタを取得し、それらのポインタの参照先オブジェクトを返却します。
更に($relatedTo以外の)別の検索条件を指定していた場合は、その取得してきた参照先オブジェクトの中から検索条件に合致したオブジェクトを返却します。
※skip、limitを指定していない場合は、デフォルト値であるskip=0、limit=100が適用されます。

(2)「count」は「ポインタの配列」内の全ポインタ件数ではなく、実際に取得した参照先オブジェクトの件数を表します。

(3)「order」は「ポインタの配列」内の全ポインタを並び替えてから検索処理を行うのではなく、検索によって取得した参照先オブジェクトのみを並び替えします。

(4)「ポインタの配列」内の全ポインタの参照先オブジェクトに対して検索を実施したい場合は、skip、limitを用いて複数回検索リクエストを実施していただきますよう、お願いいたします。
（例）2000件のリレーションデータに対して検索を行う場合は、以下の通り2回の検索を行ってください。
①skip=0,limit=1000での検索/②skip=1000,limit=1000での検索

(5)リレーションデータ件数については、管理画面にて確認が可能です。リレーションデータ件数をAPIにて取得されたい場合は、返却される参照先オブジェクトの件数(countの値)がlimitで指定した値未満(limitを指定しない場合は100件未満)となるまで複数回($relatedTo以外の)検索条件指定なしの検索(全件検索)を実施してください。countの値の合計がリレーションデータ件数となります。
※「参照先オブジェクトが削除された場合のリレーション型の挙動」に記載の仕様であることから、参照先オブジェクトが存在しないポインタは必ずRemoveRelationで削除されていることが前提となります。

(6)(1)より、管理画面にて「リレーションを見る」をクリックし遷移した先の画面で「絞り込み」からレコードの検索を実施される場合、管理画面側でlimitの値が指定されてしまうため、本来検索条件に合致する参照先オブジェクトが存在するはずであっても、検索結果として表示されないケースがあります。

上記は、巨大なリレーションの操作による負荷を考慮した仕様です。予めご了承ください。

項目	内容
共通仕様（会員管理を除く）	許可されている人／ロールを列挙する（deny/allow) 明示的に全体(public=*)への許可を設定することもできます。誰も登録されていない場合は全許可とみなされます。拒否する人／ロールを設定することはできません。
会員管理特有の仕様	共通仕様に準じるが、「誰も登録されていない場合は本人のみ許可」となります。

　項目　　　　　　

　　　　　内容　　　

共通仕様（会員管理を除く）　　　　　

許可されている人／ロールを列挙する（deny/allow)
明示的に全体(public=*)への許可を設定することもできます。
誰も登録されていない場合は全許可とみなされます。
拒否する人／ロールを設定することはできません。

会員管理特有の仕様　　　　

共通仕様に準じるが、「誰も登録されていない場合は本人のみ許可」となります。　

項目	内容
配信の品質保証	配信処理はベストエフォートであり端末への到達を完全に保証するものではありません。
配信の責任範囲	mobile backendではAPNs(Apple Push Notification services)とFCM(Firebase Cloud Messaging)を使用してプッシュ通知を実現しております。mobile backendからAPNs/FCMへ通知の配信依頼が完了した時点で「配信済み」となります。APNs/FCMへの配信依頼完了以降、端末への通知到達まではAPNs/FCMの責任範囲となりFJCTは一切の責任を負いません。
内部システム	大量のプッシュ通知配信処理を短時間に処理するため、システムは非同期（ジョブキュー）かつ並列で構成されています。非同期かつ並列なシステム構成のためステータス（配信中、等）の変更に時間がかかることがあります。
配信速度	ベストエフォートであり配信速度の保証はありません。お客様の用途に適するか、事前検証をお願いいたします。
配信速度目安	iOS/Android両OSともに、数十万端末であれば数分程度で配信処理は完了いたします。なお、こちらはあくまで目安であり、その速度を保証するものではございません。 ※mobile backendからAPNs/FCMへプッシュ通知配信依頼が完了することを、配信処理の完了と定義しています。実際に端末にプッシュ通知が届くことではございません。 ※配信遅延が見られる場合は、"配信遅延"をご参考ください。
配信遅延	配信遅延が発生した場合、下記要因が考えられます。・mobile backend 障害による影響（障害発生有無については、Informationブログをご参考ください）・他ユーザー様の負荷影響（共通PF上、他ユーザー様の影響を受ける場合がございます）・絞り込み配信による遅延（絞り込み条件やinstallationクラス内のデータ数によっては検索に時間を要する場合がございます）・APNs/FCM側での遅延発生（mobile backend側でプッシュ通知配信依頼完了後に、APNs/FCM側で遅延が発生する場合がございます）
配信可能端末数	1つのプッシュ通知登録リクエストにて登録可能な配信端末数については、"内部データベースについて＞フィールドサイズの制限" 同様特に制限はございません。 ※プッシュ通知を登録した際、登録したプッシュ通知情報は内部データベースに1オブジェクトとして登録されます。配信端末を含めた各項目の合計サイズが、オブジェクトサイズの制限(16MB)を超えないようご注意ください。
配信優先順序	配信時刻を過ぎたプッシュから順次キューへの登録が行われますが、キューへの登録は有償プランのお客様から順に実行されます。
即時配信	即時配信は、「プッシュ通知の登録時刻を配信時刻として設定した予約配信」です。順次キューへの登録が行われます。登録と同時に配信されるわけではありませんのでご注意ください。
配信のキャンセル	プッシュ通知配信システムの保全および性能確保のため、一定の条件下においてプッシュ通知の配信がキャンセルされることがあります。キャンセルされたプッシュ通知は、キャンセルされた時点で配信処理が停止し、その時点で未配信の端末への配信処理は行われません。配信キャンセルとなる条件は事前の告知なく変更されることがあります。
APNs特有の注意事項 (badDeviceTokenエラーについて)	APNsにはDebugビルド用のSandbox環境と、AdHocビルドおよびAppStoreビルド用のProduction環境の２つの配信システムが存在し、mobile backendでは管理画面にて設定頂いたAPNs証明書の種類によって使用するAPNsのシステムを決定しています。Sandbox証明書の場合はSandbox環境へ、Sandbox&Production証明書の場合はProduction環境へ接続します。 APNsではdebugビルドのアプリで取得されたデバイストークンはSandbox環境でのみ、AdHocビルドおよびAppStoreビルドのアプリで取得されたデバイストークンはProduction環境でのみ有効であり、異なる組み合わせの場合は不正なデバイストークンとしてbadDeviceTokenエラーが発生いたします。（例：Debugビルドで取得したデバイストークンを使ってAPNsのProduction環境に配信依頼をする） ■badDeviceTokenエラーの回避方法（例）・mobile backend上のアプリを２つ（development/production）作成し、ビルドタイプに応じて使い分けることでinstallationクラスにSandbox/Productionのデバイストークンが混在することを予防することができます。
APNs p8認証キー特有の注意事項	p8認証キーを使用してのプッシュ通知では、鍵情報などからトークンを生成し認証を行うトークン方式と呼ばれる方式にて送信リクエストをAPNsへ送信しています。この際、同一のp8認証キーに対し複数のトークンを多重に生成し送信に用いることによりエラーが発生することがApple社より示されています。同一のp8認証キーを同一mobile backendアカウント内のアプリで使用した場合についてはアプリ間にて同一トークンを用いプッシュ通知送信を行いますが・複数のmobile backendアカウント間で同一のp8認証キーを設定する・mobile backend以外のサービスにて同一のp8認証キーを設定するの場合については多重トークンとなり送信エラーとなる懸念があるため、お控えください。異なるp8認証キーが用意できない場合につきましてはアプリごとに細やかな権限設定の可能なp12証明書を利用してください。参考: Establishing a Token-Based Connection to APNs - Apple Developer Documentation
FCM特有の注意事項 (カノニカルIDの扱いについて)	・「アプリケーションのアップデート」や「アプリケーションの再インストール」などに起因して、同じデバイスに対してFCMサーバが複数のRegistration ID（デバイストークン）を割り振る場合があります。このとき、FCMサーバーが正規のIDと認識しているデバイストークンがカノニカルIDと呼ばれています。・同じデバイスに対して複数のデバイストークンが払い出された場合、FCMの仕様上、払い出されたデバイストークンの全てで正常にプッシュ通知が届きます。このため、同じデバイスを示す複数のデバイストークン宛にプッシュ通知を配信すると、重複受信が発生します。なお、カノニカルID以外のデバイストークン宛にプッシュ通知を配信した場合、FCMはフィードバックとしてカノニカルIDへの更新依頼を返却します。・mobile backendではこの依頼に従い、対象のデバイストークンを持つinstallationのdeviceTokenフィールドをカノニカルIDへ更新します。ただし、installationクラスのdeviceTokenフィールドはユニーク制約が課されているため、カノニカルIDが既に別のinstallationとして登録されている場合は更新に失敗します。この場合、対象のデバイストークンを持つinstallationを削除することで対応します。
FCM配信方法について	FCMでのプッシュ通知配信では、トピックにメッセージを送信する方法を使用しています。
アプリがアンインストールされた端末情報(installation)の自動削除	mobile backendはAPNs/FCMより、アプリ利用者がアプリを端末からアンインストールした等の理由により配信先が喪失したという内容の情報を受け取った場合、mobile backendでは対象の端末情報(installation)を自動で削除致します。・APNsの場合は配信依頼時にAPNsから「unregistered:(APNs)期限切れ(アプリ削除済み)デバイストークンへの送信」エラーが返却された場合に、mobile backendにて該当デバイストークンを削除します。・FCMの場合は配信依頼時のレスポンスとして返却されたregistrationTokenNotRegisteredエラーに従い対処します。
配信済みのプッシュ通知オブジェクトについて	プッシュ通知の配信に伴い、配信済みのプッシュ通知オブジェクトが累積いたします。こちらはプッシュ通知の登録ごとに作成されますので、個通のプッシュ通知を多用されるなど、プッシュ通知登録数が多い場合につきましては、オブジェクトの容量肥大が考えられます。容量が肥大しますと、プッシュ通知の配信パフォーマンス低下やストレージ容量の逼迫に繋がりますので、プッシュ通知オブジェクトが約100万件を超過した場合、超過分の配信済みのプッシュ通知オブジェクト（開封率データ含む）は自動でバックアップされます。詳細はこちらをご覧ください。

　項目　　　　　　

　　　　　内容　　　

配信の品質保証　　　　　

配信処理はベストエフォートであり端末への到達を完全に保証するものではありません。　

配信の責任範囲　　　　　

mobile backendではAPNs(Apple Push Notification services)とFCM(Firebase Cloud Messaging)を使用してプッシュ通知を実現しております。mobile backendからAPNs/FCMへ通知の配信依頼が完了した時点で「配信済み」となります。APNs/FCMへの配信依頼完了以降、端末への通知到達まではAPNs/FCMの責任範囲となりFJCTは一切の責任を負いません。

内部システム

大量のプッシュ通知配信処理を短時間に処理するため、システムは非同期（ジョブキュー）かつ並列で構成されています。
非同期かつ並列なシステム構成のためステータス（配信中、等）の変更に時間がかかることがあります。

配信速度

ベストエフォートであり配信速度の保証はありません。お客様の用途に適するか、事前検証をお願いいたします。

配信速度目安

iOS/Android両OSともに、数十万端末であれば数分程度で配信処理は完了いたします。なお、こちらはあくまで目安であり、その速度を保証するものではございません。

※mobile backendからAPNs/FCMへプッシュ通知配信依頼が完了することを、配信処理の完了と定義しています。実際に端末にプッシュ通知が届くことではございません。
※配信遅延が見られる場合は、"配信遅延"をご参考ください。

配信遅延

配信遅延が発生した場合、下記要因が考えられます。
・mobile backend 障害による影響（障害発生有無については、Informationブログをご参考ください）
・他ユーザー様の負荷影響（共通PF上、他ユーザー様の影響を受ける場合がございます）
・絞り込み配信による遅延（絞り込み条件やinstallationクラス内のデータ数によっては検索に時間を要する場合がございます）
・APNs/FCM側での遅延発生（mobile backend側でプッシュ通知配信依頼完了後に、APNs/FCM側で遅延が発生する場合がございます）

配信可能端末数

1つのプッシュ通知登録リクエストにて登録可能な配信端末数については、"内部データベースについて＞フィールドサイズの制限" 同様特に制限はございません。
※プッシュ通知を登録した際、登録したプッシュ通知情報は内部データベースに1オブジェクトとして登録されます。配信端末を含めた各項目の合計サイズが、オブジェクトサイズの制限(16MB)を超えないようご注意ください。

配信優先順序

配信時刻を過ぎたプッシュから順次キューへの登録が行われますが、キューへの登録は有償プランのお客様から順に実行されます。

即時配信

即時配信は、「プッシュ通知の登録時刻を配信時刻として設定した予約配信」です。順次キューへの登録が行われます。登録と同時に配信されるわけではありませんのでご注意ください。

配信のキャンセル

プッシュ通知配信システムの保全および性能確保のため、一定の条件下においてプッシュ通知の配信がキャンセルされることがあります。
キャンセルされたプッシュ通知は、キャンセルされた時点で配信処理が停止し、その時点で未配信の端末への配信処理は行われません。
配信キャンセルとなる条件は事前の告知なく変更されることがあります。

APNs特有の注意事項
(badDeviceTokenエラーについて)

APNsにはDebugビルド用のSandbox環境と、AdHocビルドおよびAppStoreビルド用のProduction環境の２つの配信システムが存在し、mobile backendでは管理画面にて設定頂いたAPNs証明書の種類によって使用するAPNsのシステムを決定しています。Sandbox証明書の場合はSandbox環境へ、Sandbox&Production証明書の場合はProduction環境へ接続します。
APNsではdebugビルドのアプリで取得されたデバイストークンはSandbox環境でのみ、AdHocビルドおよびAppStoreビルドのアプリで取得されたデバイストークンはProduction環境でのみ有効であり、異なる組み合わせの場合は不正なデバイストークンとしてbadDeviceTokenエラーが発生いたします。（例：Debugビルドで取得したデバイストークンを使ってAPNsのProduction環境に配信依頼をする）

■badDeviceTokenエラーの回避方法（例）
・mobile backend上のアプリを２つ（development/production）作成し、ビルドタイプに応じて使い分けることでinstallationクラスにSandbox/Productionのデバイストークンが混在することを予防することができます。

APNs p8認証キー特有の注意事項

p8認証キーを使用してのプッシュ通知では、鍵情報などからトークンを生成し認証を行うトークン方式と呼ばれる方式にて送信リクエストをAPNsへ送信しています。
この際、同一のp8認証キーに対し複数のトークンを多重に生成し送信に用いることによりエラーが発生することがApple社より示されています。
同一のp8認証キーを同一mobile backendアカウント内のアプリで使用した場合についてはアプリ間にて同一トークンを用いプッシュ通知送信を行いますが

・複数のmobile backendアカウント間で同一のp8認証キーを設定する
・mobile backend以外のサービスにて同一のp8認証キーを設定する

の場合については多重トークンとなり送信エラーとなる懸念があるため、お控えください。
異なるp8認証キーが用意できない場合につきましてはアプリごとに細やかな権限設定の可能なp12証明書を利用してください。
参考: Establishing a Token-Based Connection to APNs - Apple Developer Documentation

FCM特有の注意事項
(カノニカルIDの扱いについて)

・「アプリケーションのアップデート」や「アプリケーションの再インストール」などに起因して、同じデバイスに対してFCMサーバが複数のRegistration ID（デバイストークン）を割り振る場合があります。このとき、FCMサーバーが正規のIDと認識しているデバイストークンがカノニカルIDと呼ばれています。

・同じデバイスに対して複数のデバイストークンが払い出された場合、FCMの仕様上、払い出されたデバイストークンの全てで正常にプッシュ通知が届きます。このため、同じデバイスを示す複数のデバイストークン宛にプッシュ通知を配信すると、重複受信が発生します。
なお、カノニカルID以外のデバイストークン宛にプッシュ通知を配信した場合、FCMはフィードバックとしてカノニカルIDへの更新依頼を返却します。

・mobile backendではこの依頼に従い、対象のデバイストークンを持つinstallationのdeviceTokenフィールドをカノニカルIDへ更新します。ただし、installationクラスのdeviceTokenフィールドはユニーク制約が課されているため、カノニカルIDが既に別のinstallationとして登録されている場合は更新に失敗します。この場合、対象のデバイストークンを持つinstallationを削除することで対応します。

FCM配信方法について

FCMでのプッシュ通知配信では、トピックにメッセージを送信する方法を使用しています。

アプリがアンインストールされた端末情報(installation)の自動削除

mobile backendはAPNs/FCMより、アプリ利用者がアプリを端末からアンインストールした等の理由により配信先が喪失したという内容の情報を受け取った場合、mobile backendでは対象の端末情報(installation)を自動で削除致します。
・APNsの場合は配信依頼時にAPNsから「unregistered:(APNs)期限切れ(アプリ削除済み)デバイストークンへの送信」エラーが返却された場合に、mobile backendにて該当デバイストークンを削除します。
・FCMの場合は配信依頼時のレスポンスとして返却されたregistrationTokenNotRegisteredエラーに従い対処します。

配信済みのプッシュ通知オブジェクトについて

プッシュ通知の配信に伴い、配信済みのプッシュ通知オブジェクトが累積いたします。
こちらはプッシュ通知の登録ごとに作成されますので、個通のプッシュ通知を多用されるなど、プッシュ通知登録数が多い場合につきましては、オブジェクトの容量肥大が考えられます。
容量が肥大しますと、プッシュ通知の配信パフォーマンス低下やストレージ容量の逼迫に繋がりますので、プッシュ通知オブジェクトが約100万件を超過した場合、超過分の配信済みのプッシュ通知オブジェクト（開封率データ含む）は自動でバックアップされます。詳細はこちらをご覧ください。

項目	内容
CDNとしてのご利用について	mobile backendのファイルストア機能はCDNではないため、これを用いた大規模なコンテンツ配信などには適しません。また、Unity Asset Bundleを用いたファイルの配信には適しません。十分な帯域は準備しておりますが、過度な帯域の専有が確認された場合は利用規約に則り対応いたします。
ファイル名について	ファイルストアにアップロードするファイルの名前には、以下の記号は利用できません。 :?#[]!$&'()*+,;="<>%~\| ※なお、プッシュ通知などに利用する設定ファイルの名前についても同様です。

　項目　　　　　　

　　　　　内容　　　

CDNとしてのご利用について

mobile backendのファイルストア機能はCDNではないため、これを用いた大規模なコンテンツ配信などには適しません。
また、Unity Asset Bundleを用いたファイルの配信には適しません。
十分な帯域は準備しておりますが、過度な帯域の専有が確認された場合は利用規約に則り対応いたします。　

ファイル名について

ファイルストアにアップロードするファイルの名前には、以下の記号は利用できません。
:?#[]!$&'()*+,;="<>%~|
※なお、プッシュ通知などに利用する設定ファイルの名前についても同様です。

項目	内容
ライセンス	Apache License, Version 2.0 です。 SDKに同梱されているライセンスが上記と異なる場合は、SDKに同梱されているライセンスを優先します。
タイムアウト時間	SDKのタイムアウト時間は10秒です。
テクニカルサポート対応SDKバージョンについて	テクニカルサポート窓口対応は、1年半以内にリリースされたSDKに対してのみ行わせていただきます。リリースから1年半以上が経過しているSDKについては、テクニカルサポート対応の対象外とさせていただきます。 ※なお、mobile backend にて大規模な改変が行われた際は、リリースから1年半以内のSDKであっても対応出来ない場合がございます。その際はinformationブログにてお知らせいたします。予めご了承ください。
Bugfix対応について	ライセンスに基づきベストエフォートでの対応とさせて頂きます。不具合を報告する場合はgithubのissueに登録してください。
改変について	ライセンスに従ってください。なお、改変されたSDKに関してはテクニカルサポート窓口を含めた全てのサポート窓口での対応の対象外とさせて頂きます。
SDK動作保証環境について	各SDKのREADMEの「動作環境・Supported environment/Specifications」にて、最新版のSDKの動作保証環境を記載しています。動作環境にはOS系 (iOS, Android OS)、ツール/アプリケーション系（Unity, Xcode, Android Studio, Node.js, Cordova）などが含まれます。なお、既に公式サポートが終了したバージョンについては、動作保証環境から除外させていただきます。以上から、動作保証環境については定期的な更新を行っておりますので、ご利用の際はREADMEを必ずご確認ください。

　項目　　　　　　

　　　　　内容　　　

ライセンス　　　　

Apache License, Version 2.0 です。
SDKに同梱されているライセンスが上記と異なる場合は、SDKに同梱されているライセンスを優先します。　

タイムアウト時間

SDKのタイムアウト時間は10秒です。

テクニカルサポート対応SDKバージョンについて

テクニカルサポート窓口対応は、1年半以内にリリースされたSDKに対してのみ行わせていただきます。
リリースから1年半以上が経過しているSDKについては、テクニカルサポート対応の対象外とさせていただきます。
※なお、mobile backend にて大規模な改変が行われた際は、リリースから1年半以内のSDKであっても対応出来ない場合がございます。その際はinformationブログにてお知らせいたします。予めご了承ください。

Bugfix対応について　　　　

ライセンスに基づきベストエフォートでの対応とさせて頂きます。
不具合を報告する場合はgithubのissueに登録してください。　

改変について　　　　

ライセンスに従ってください。
なお、改変されたSDKに関してはテクニカルサポート窓口を含めた全てのサポート窓口での対応の対象外とさせて頂きます。　

SDK動作保証環境について　　　　

各SDKのREADMEの「動作環境・Supported environment/Specifications」にて、最新版のSDKの動作保証環境を記載しています。動作環境にはOS系 (iOS, Android OS)、ツール/アプリケーション系（Unity, Xcode, Android Studio, Node.js, Cordova）などが含まれます。
なお、既に公式サポートが終了したバージョンについては、動作保証環境から除外させていただきます。以上から、動作保証環境については定期的な更新を行っておりますので、ご利用の際はREADMEを必ずご確認ください。　

項目	内容
mobile backend 対応言語	mobile backend は、公式ドキュメントを提供しているObjective-C,Java,JavaScript,Unity(C#),Swift でのご利用をサポートしております。なお、一部サンプルアプリは、Kotlin,PHPにて提供されていますが、こちらの言語については提供しているサンプルアプリについてのみご質問を受け付けております。また、スクリプト用ドキュメントではRuby言語でのサンプルコードを記載しておりますが、こちらについてもサンプルコードについてのみご質問を受け付けております。予めご了承ください。
サンプルコードの提供について	テクニカルサポートでは、ご要件のみ伺った時点でのサンプルコードの提供は行っておりません。原則、お客様のソースコードにおける問題のみサポートいたします。お困りの際は実装されたコードの提供をお願いいたします。

　項目　　　　　　

　　　　　内容　　　

mobile backend 対応言語

mobile backend は、公式ドキュメントを提供しているObjective-C,Java,JavaScript,Unity(C#),Swift でのご利用をサポートしております。
なお、一部サンプルアプリは、Kotlin,PHPにて提供されていますが、こちらの言語については提供しているサンプルアプリについてのみご質問を受け付けております。
また、スクリプト用ドキュメントではRuby言語でのサンプルコードを記載しておりますが、こちらについてもサンプルコードについてのみご質問を受け付けております。予めご了承ください。

サンプルコードの提供について

テクニカルサポートでは、ご要件のみ伺った時点でのサンプルコードの提供は行っておりません。
原則、お客様のソースコードにおける問題のみサポートいたします。お困りの際は実装されたコードの提供をお願いいたします。

項目	内容
mobile backendサーバーのIPアドレスについて	mobile backendは、ドメイン指定での利用を基本としております。そのため、サーバーのIPアドレスについては公開しておりません。 ※2021年3月時点では固定のIPアドレスを割り当てておりますが、こちらについても今後変更される可能性がございます。その際の告知についてはサービスとして確約しておりません。 ※スクリプト機能についてのみ、ドキュメントにて情報を公開しております。ご参考ください。
海外利用について	mobile backendでは、他国からの通常のAPIリクエストに関して、特に制限は設けておりません。但し、プッシュ通知を実装いただく場合、FCM、APNsそれぞれの各国独自の制限等につきましては、お客様自身でご確認いただきますようお願いいたします。各国の利用可否まで含め弊社側で判断、および詳細調査は行っておりませんので、ご了承ください。なお、過去のお問い合わせ事例として、会員認証で設定可能な、ユーザーに送信するメール文面についてハングル文字が文字化けしたとのお問い合わせがございました。メール送信処理にて指定している文字コードが「iso-2022-jp」のため、「iso-2022-jp」で処理可能な文字でのメール本文作成をお願いいたします。 ※プッシュ通知の本文ではなく、メール送信で利用する本文です。各国で利用している言語表記や文字コードでの検証は行っておりませんので、お客様にて検証ののちご利用ください。

　項目　　　　　　

　　　　　内容　　　

mobile backendサーバーのIPアドレスについて

mobile backendは、ドメイン指定での利用を基本としております。そのため、サーバーのIPアドレスについては公開しておりません。
※2021年3月時点では固定のIPアドレスを割り当てておりますが、こちらについても今後変更される可能性がございます。その際の告知についてはサービスとして確約しておりません。
※スクリプト機能についてのみ、ドキュメントにて情報を公開しております。ご参考ください。

海外利用について

mobile backendでは、他国からの通常のAPIリクエストに関して、特に制限は設けておりません。
但し、プッシュ通知を実装いただく場合、FCM、APNsそれぞれの各国独自の制限等につきましては、お客様自身でご確認いただきますようお願いいたします。各国の利用可否まで含め弊社側で判断、および詳細調査は行っておりませんので、ご了承ください。
なお、過去のお問い合わせ事例として、会員認証で設定可能な、ユーザーに送信するメール文面についてハングル文字が文字化けしたとのお問い合わせがございました。メール送信処理にて指定している文字コードが「iso-2022-jp」のため、「iso-2022-jp」で処理可能な文字でのメール本文作成をお願いいたします。
※プッシュ通知の本文ではなく、メール送信で利用する本文です。各国で利用している言語表記や文字コードでの検証は行っておりませんので、お客様にて検証ののちご利用ください。

お探しの内容が見つからなかった場合はユーザーコミュニティもご活用ください。（回答保証はいたしかねます）
なお、 Expertプラン以上のお客様はテクニカルサポートにてご質問を承らせて頂きます。

サーバー構築不要！スマートフォンアプリ向けの新クラウド