プラットフォームが 2 つの仕様を公開しているとき、どちらに従えばいいですか？

ここの数字はすべて各プラットフォーム自身のマーチャント向け文書から、各出典に添えた日付に読み取ったものです。DoorDash は 16:9、Uber Eats は 5:4 から 6:4 の帯、Grubhub は 2 つの答えを公開していて、このページの残りはそこから始まります。規定を英語とスペイン語で公開しているのは DoorDash だけで、Uber Eats、Grubhub、Toast は英語のみです。4 社とも日本語版はありません。

写真の助言のほとんどは、各プラットフォームが 1 つの数字を公開していると前提しています。文書をよく読むと、そうではないことがわかります。私がアップロードする 5 つのプラットフォームのうち 3 つは、同じ会社が公開した別の数字と食い違う数字を、ときには同じページの中で公開しています。

これが大事なのは細かいことにこだわるためではなく、実務上の理由です。矛盾の誤ったほうに従えば写真は却下され、却下通知はもう一方を引用して返してきます。

配達の写真文書の中で最大の矛盾で、Grubhub のどちらのページももう一方の存在を認めていません。1 つの規定を詳しさの違う 2 段階で書いたものではなく、すべての項目で食い違っています。

ヘルプセンターを満たす画像は、開発者ポータルの最小値より面積で 48 分の 1 しかなく、しかも形も違います。正方形は 4:3 ではありません。

どちらに拘束されるかは、メニューが Grubhub にどう届くか、手動アップロードかパートナーのフィードか、で決まるようです。Grubhub はそうとはどこにも書いていないので、各ページが誰に向けて書かれているかからの私の推測であって、Grubhub に対して主張できる規定ではないと受け取ってください。

どのページをどの言語で読むかによって、3 つすべてです。英語ページでは、写真がサイズで却下される理由を説明する部分が最大 2 MB と述べ、同じページの下にある要件のまとめが商品写真を 16 MB 未満 と記載しています。同じページのスペイン語版（2026-10-01 確認）はサイズの節で 10 MB、まとめで 16 MB です。

上から順に読むマーチャントは 1 つの答えを得ます。仕様表に飛ぶマーチャントは 8 倍大きい別の答えを得ます。スペイン語で読むマーチャントは 3 つ目を得ます。

何をすべきかに曖昧さはなく、3 つの中で最も簡単です。2 MB 未満に収めれば 3 つの読み方すべてを一度に満たします。これが大事なのは主に、残りに対する警告としてです。プラットフォームが 1 ページの中で、しかも言語の間で自己矛盾できるなら、6 か月前にどこかで読んだ数字は確認し直す価値があります。

はい、2 点で反しています。2 つの記事を Toast 自身の言葉（英語）で。

1 つ目は、メニュー項目の画像には 750 × 450 ピクセルの長方形を推奨すると述べています。2 つ目は、Online Ordering Pro のメニューテンプレートが 1:1、4:3、16:9 の縦横比に対応し、高さか幅の最小値として 1000 ピクセルを推奨すると述べています。1 つ目の推奨にきっちり従ったレストランは、2 つ目に二重に外れるファイルを作ることになります。

1920 × 1080 で書き出せば、2 つの記事を余裕をもって満たせます。Toast が挙げる 16:9 で、短辺はすでに 1000 px を超えています。

文言について正直な注記を 1 つ。この矛盾がどれだけ効くかを左右するからです。Toast の 2 つの数字はどちらも要件ではなく推奨として書かれているので、DoorDash の 16:9 のように却下の根拠になる規定ではありません。形のほうがより固いです。"support"（対応する）が、Toast が受け入れる 3 つの比率に使っている動詞だからです。

別々の理由が 3 つあり、明らかなのはそのうち 1 つだけです。

料理を画面の中央 75% の範囲に、縦横どちらの方向でも収めてください。

この数字は目安ではなく、公開された要件から計算した結果です。4:3 の写真を考えます。16:9 の切り抜きは幅を全部残し、上下を取り除きます。1:1 の切り抜きは高さを全部残し、左右を取り除き、これは避けられません。DoorDash はすべての商品写真を中央の正方形サムネイルとして表示し、Grubhub のヘルプセンターは正方形をそのまま求めるからです。5:4 の切り抜きはその中間です。3 つすべてを生き残る領域は、幅の中央 75% と高さの中央 75% です。その長方形の外にあるものは、少なくとも 1 つのプラットフォームで切られます。

75% という数字は 4:3 の写真に固有のものです。 別の形で撮れば安全領域は動きます。不利に働く切り抜きが変わるからです。

ここから 2 つのことが導かれます。3 つのプラットフォームすべてで販売しているなら 4:3 で撮る。 どの切り抜きも大きく欠けない唯一の形だからです。そして撮影前にカメラの設定を確認してください。ほとんどのスマホで静止画の初期設定は 4:3 ですが、動画モード、パノラマ、多くのプロモードは 16:9 で撮ります。16:9 は DoorDash が求める形でありながら、ここでは最悪の形です。

どのプラットフォームも受け付ける最大のサイズで撮って縮小し、プラットフォームごとに別々に書き出してください。1 つのファイルを 3 回名前を変えて使うのではなく。

通常の助言はプラットフォームごとにファイルを 1 つ書き出すことです。これらの矛盾は、それだけでは足りないことを意味します。一部のプラットフォームには、書き出すべき合意された単一の目標がないからです。

すべてに耐えるのは、料理の周りに余裕を持たせて撮ることです。上の矛盾はどれもサイズと形についてで、どちらも書き出し時ではなく撮影時に決まります。端ぎりぎりに撮った料理は、同じ原本から 4:3 と 1:1 と 16:9 に切り直せません。余白のある料理ならできます。

私が自分のアップロードで使っている実務的な規則はこうです。広めに撮り、各矛盾のより厳しい数字に書き出し、原本を保管する。厳しいとは、Grubhub は 1600 × 1200、DoorDash は 2 MB 未満、Toast は 1920 × 1080 です。そのどれも、対立するゆるいほうの数字も満たします。