Googleビジネスプロフィールの写真登録、直接送る経路は16回全部失敗し、公開URLを渡す経路は試験の1枚が通った
——再試行を続ける前に残す失敗記録の3項目と、登録できたかを読み戻して確かめる手順

この記事の読者は、店舗や事務所のGoogleビジネスプロフィール（Googleマップと検索に出る自分の店の情報）を自分で整えている担当者と、その整備を制作会社や代行会社に委託している側の方です。写真を登録しようとして「失敗しました」で止まり、同じ操作をもう一度、もう一度と繰り返している。あるいは委託先から「Google側の不具合で登録できません」と言われて、それが本当かどうか判断できずにいる——そういう方に向けて書いています。

結論を3つ、先に書きます。ひとつ、同じ経路の再試行を続ける前に、何回・どの経路・何が返ったかを書き留めてください。私たちの運用記録に残っているのは「同じ日に16回、16回とも同じ種類の内部エラー」という集計で、1回ごとの行ではありません。経路を替える判断は、この回数からではなく、次に書く「崩した送信には別の応答が返る」という違いと、公式にもう1つの経路が書かれていたことから行いました。回数は、あとから運用記録に残した集計です。ふたつ、送り方をわざと崩して応答が変わるかを見ると、形式の不備が検知されているかどうかは分かります。崩した送信には別の応答が返り、形式の整った送信には内部エラーが返る。この組み合わせだけでは送り方の問題を除外できませんが、私たちはこれを見て、同じ経路で送り方を直し続けるより、もう1つの経路を試す判断をしました。みっつ、登録の応答を受け取ったあとに、登録済みの一覧を読み戻して枚数を確かめてください。応答が通ったことと、一覧に載ったこと、一般の画面に表示されたことは、それぞれ別の確認です。

ここから書くのは、HaruIroAI自身のプロフィールで起きたことです。お客様のプロフィールで起きたことではなく、お客様への影響もありません。登録に使ったのは、管理画面ではなく、Googleが公開している連携の仕組み（Business Profile API。以下、API）です。管理画面から写真を載せる操作は、この記事では検証していません。そして、Google側で何が起きていたかの原因は、書きません。分からないからです。公式リファレンスとヘルプは、2026年9月9日に開いて確認しました。

公式リファレンスには、写真を登録する経路が2つ書かれている

APIで写真を登録する方法を説明した公式ページ「メディアをアップロードする」には、見出しが2つあります。「URL からアップロードする」と「バイトからアップロードする」です。前者は、インターネット上に置いた画像のURLを1回の呼び出しで渡す経路。後者は、まず送信を開始し、画像の中身そのものを送り、返ってきた参照を付けて登録する、3段階の経路です。この記事では、前者を「公開URLを渡す経路」、後者を「画像を直接送る経路」と呼びます。

それぞれの経路で使う欄の名前と説明が載っているのは、写真そのものを扱う別の公式リファレンス（英語）です。公開URLを渡す欄が sourceUrl で、説明は「メディア項目を取得できる、一般公開されたURL」。直接送る経路で使う欄が dataRef で、「送信開始の手続きで得た、画像データへの参照」です。写真の条件も同じリファレンスに書かれていて、短辺が250ピクセル以上、ファイルが10,240バイト以上（ロゴとカバー写真は最小サイズの制限を受けません）。

もうひとつ、さきほどの「メディアをアップロードする」のページに、制限が1行あります。「バイトからのメディアのアップロードは、ビジネス情報でのみサポートされています。ローカル投稿にメディアを含める場合は、URL からアップロードしてください」。つまり、投稿に写真を付ける場合は、もともと公開URLを渡す経路しかありません。プロフィールの写真には2つの経路があり、投稿の写真には1つ。この違いは、あとで委託先への確認項目に効いてきます。

APIそのものについて、ひとつ添えておきます。ビジネスプロフィールのヘルプは、APIを「テクノロジーに精通した大規模な企業のデベロッパーや第三者のデベロッパー向けのソリューションです」と位置づけ、「ビジネス プロフィールのデータを管理するアプリケーションを作成する際は、Business Profile API へのお申し込みをおすすめします」と書いています。個人の店舗が自分で使う前提の道具ではありません。この記事でAPIの話を書くのは、委託先や連携ツールがこの経路で写真を扱っている場合に、担当者が確認できる言葉を持つためです。

確認先：Google Business Profile APIs「メディアをアップロードする」／同「REST Resource: accounts.locations.media」（英語。sourceUrl・dataRef の説明と写真の条件はこのページ）／Google ビジネス プロフィール ヘルプ「ビジネス プロフィールの写真と動画を管理する」／同「Business Profile API の使用方法」。いずれも2026年9月9日に取得して確認

自社で起きたこと——直接送る経路は16回すべて内部エラー、公開URLを渡す経路は試験1回で200

ここからはHaruIroAI自身の話です。

9月5日の記事に、「写真13枚を選んだまま、載せていない」と書きました。その記事を公開した9月5日、人の承認を得たうえで、自社のプロフィールへの書き込みをAPIから行いました。写真以外の5つ——説明文の書き直し（全角換算339字）、サービス14件への説明の追加、公開を終えた投稿の削除、制作事例の投稿、サイトへのリンクの整備——と、別枠の写真13枚です。写真以外の5つは、その日のうちに完了しました。

写真だけが止まりました。最初に使ったのは、画像を直接送る経路です。手元にある13枚をそのまま送れるので、こちらが自然でした。ところが、送信を開始して参照を受け取り、画像の中身を送り、参照を付けて登録する、という手順の途中で、Google側の内部エラー（HTTP 500・INTERNAL）が返ります。日を改めたわけではなく、同じ日のうちに16回試して、16回とも同じ内部エラーでした。16回が同じ1枚への送り直しだったのか、複数の写真に及んだのかは、記録に残っていません。

そこで経路を替えました。公式ページにあるもう1つの経路、公開URLを渡す方法です。画像をどこかに公開して、そのURLを渡す。まず1枚だけ、自社サイトに置いた画像のURLで試験登録をしたところ、200（成功）が返り、すぐに削除しました。登録できることだけを確かめて、公開中のプロフィールに試験の画像を残さないためです。そのうえで、13枚は自社サイトの決めた場所に置き、そのURLで登録する方針にしました。ただし、13枚それぞれについて登録の応答を受け取ったかどうかは、この記事の時点で運用記録から確認できていません。記録に残っているのは、試験の1枚が200で通ったことと、この経路で登録するという方針までです。確認できた日に、このブログに書き足します。

気をつけて読んでほしいところが2つあります。ひとつ、直接送る経路が「使えない経路」だとは言えません。私たちが試したのは1日で、1つのプロフィールで、16回です。翌週に通るのかもしれませんし、他のアカウントでは最初から通っているのかもしれません。それは確かめていません。ふたつ、公開URLを渡す経路が「解決策」だとも言えません。自社で試験の1枚が通った経路、というだけです。この記事が勧めるのは「経路を替えろ」ではなく、「同じ経路の17回目を試す前に、もう1つの経路が公式に用意されているなら、そちらを1回試す価値がある」というところまでです。

切り分けの根拠——送り方をわざと崩したら、別の応答が返った

16回失敗したとき、疑うべきは自分たちの送り方です。画像の形式、サイズ、送信の順番。どれかが間違っていれば、こちらで直せます。そこで、送り方をわざと崩して送ってみました。体裁をわざと崩した形で送ると、返ってきたのは400（リクエストの不備）でした。内部エラーではありません。

この2つの応答を並べると、言えることが1つ増えます。形式の不備は検知されて400が返る。その同じ相手が、形式の整った送信に対しては500を返している。だとすれば、500は、形式の不備として弾かれたものではない。ここまでが、私たちが記録から言えることです。ただし、これは送り方の問題を除外できたという意味ではありません。形式が通った送信の中身に原因が無いことを、この2つの応答は証明しません。私たちが下したのは「この経路で送り方を直し続けるより、公式にあるもう1つの経路を1回試す」という判断で、それ以上ではありません。原因がGoogle側の何なのかは分かりませんし、書きません。障害報告が指した機能が本番に存在しなかった記録で書いたとおり、見えていないものを推測で埋めると、対応そのものが空振りします。

公開URLを渡す経路には、この経路ならではの落とし穴もありました。自社サイトは、決まった名乗りをしない自動アクセスに対して403（拒否）を返す設定にしています。手元の確認用の道具でそのまま画像のURLを開くと、403が返りました。人がブラウザで開けることと、Googleの取得元が開けることは、別です。私たちの場合は、Googleからの取得は通り、200が返りましたが、サイト側の設定によっては、URLは公開しているつもりでも取得元が拒否されることがあり得ます。「一般公開されたURL」という公式の条件は、人に見えるかではなく、取りに来る側に見えるかで読む必要があります。

再試行を続ける前に残す3項目——何回・どの経路・何が返ったか

先に断っておくと、私たちの運用記録に残っているのは「同じ日に16回、16回とも500」という集計です。何回目に何が返ったかを1行ずつ残していたわけではありません。この集計は判断のあとに残したもので、判断の材料にはなっていません。1行ずつ残していれば、同じ応答が5回並んだ時点で切り分けに移れたはずです。ここから先は、その反省をもとにした提案です。記録が無ければ、「さっきも失敗した気がする」で20回でも30回でも続けてしまいます。

持ち帰りの1つ目は、この記録のテンプレです。API経由でも管理画面でも、書く欄は同じです。下の行は記入例で、自社の記録の転記ではありません（自社の記録は回数の集計までで、16回が同じ1枚か複数枚かは残っていません）。委託先に登録を頼んでいる方は、このテンプレをそのまま渡して「失敗したらこの形で報告してほしい」と伝えると、「Google側の不具合です」という一言で終わらなくなります。

【写真登録の失敗記録——1回の試行につき1行。以下は記入例で、自社の記録の転記ではない】

日付・時刻 | 何回目 | 経路（管理画面／連携ツール／直接送る／公開URL） | 写真（番号か名前） | 返ってきたもの（画面の文言・番号・応答の種類） | 送り方を変えた点
2026-09-05 | 1  | 直接送る  | 01 | 500 INTERNAL（3段階の途中）      | —
2026-09-05 | 2  | 直接送る  | 01 | 500 INTERNAL                    | 送り直しのみ
…
2026-09-05 | 16 | 直接送る  | 01 | 500 INTERNAL                    | —
2026-09-05 | —  | 直接送る  | 01 | 400（体裁をわざと崩した試験）     | わざと崩した
2026-09-05 | 1  | 公開URL   | 試験 | 200 → 確認後すぐ削除            | 経路を替えた

止まる目安:
・同じ経路・同じ応答が5行並んだら、6行目を書く前に「切り分け」へ
・わざと崩した送信に別の応答が返るなら、形式の不備は検知されていると分かる。送り方の問題を除外できたわけではないが、別の経路を試す判断の材料になる
・公式に別の経路があるなら、そちらを1回だけ試験で試す（試験の画像は残さない）

管理画面から登録している方は、「経路」の欄が「管理画面」の1種類になります。それでも、何回目か、どの写真か、画面に何と出たかを残す価値は変わりません。公式ヘルプには「写真と動画がビジネス プロフィールに表示されるまで、最長で 24～48 時間ほどかかることがあります」と書かれています。登録の操作が失敗したのか、登録は済んでいて表示を待っているだけなのかは、記録が無いと区別できません。

委託先に渡すときの確認項目——「登録できない」を一言で終わらせない

持ち帰りの2つ目は、写真の登録を制作会社や代行会社に任せている方が、委託先へそのまま渡せる確認項目です。私たちは受け持つ側でもあるので、聞かれて困る項目は入れていません。

【写真の登録を委託先へ頼むとき・失敗の報告を受けたときの確認項目】

登録の前に
□ 写真は公式の条件を満たしているか（JPGまたはPNG・10KB〜5MB・推奨720×720・最小250×250）
□ どの経路で登録するか（管理画面／連携ツール／API。APIなら「直接送る」か「公開URLを渡す」か）
□ 公開URLを渡す経路なら、画像をどこに置くか。その場所は取得元からも開けるか
□ 登録が終わったら、何をもって「完了」と報告してもらうか（応答だけ／一覧の枚数／一般画面の表示）

失敗の報告を受けたら
□ 何回・どの経路・何が返ったか（上の失敗記録テンプレの形で）
□ 送り方をわざと崩して応答が変わるかを試したか
□ 公式に別の経路があるなら、そちらを試したか。試したなら結果は
□ 「Google側の不具合」と言う根拠は何か（応答の種類か、公式の告知か、推測か）
□ 次に何を試すか、いつまで待つか、それでも通らなければどうするか

最後の項目を入れたのは、私たち自身が「Google側」と判断したときに、根拠を言葉にする必要があったからです。根拠は、わざと崩した送信に400が返り、形式の整った送信に500が返った、という2つの応答の組み合わせです。この組み合わせは、送り方の問題を除外する証明ではなく、経路を替える判断の材料です。それ以上のこと——Google側で何が起きていたか——は、根拠がありません。委託先が「Google側の不具合です」と言うとき、その根拠が応答の記録なのか、推測なのかは、聞けば分かります。

登録できたかを読み戻して確かめる——応答の200で終わらない

持ち帰りの3つ目は、登録のあとの確かめ方です。確認には段階が3つあります。私たちの記録で言えるのは、試験の1枚について1段階目の応答を受け取ったところまでです。

1. 応答が通った。APIなら200、管理画面なら「アップロードしました」に当たる表示。ここは「受け付けた」であって、載ったとは限りません
2. 一覧に載っている。登録済みの写真の一覧を取り直して、枚数を数えます。APIなら一覧を取得する呼び出し、管理画面なら「写真」の欄です。13枚を登録したなら、13枚増えているかを数えます
3. 一般の画面に表示されている。自分のアカウントでログインしていない状態で、Googleマップと検索の自分のプロフィールを開いて数えます。公式ヘルプのとおり、ここまでには最長24〜48時間ほどかかることがあります

隠さずに書いておくと、私たちの記録に残っているのは、試験の1枚についての1の段階までです。13枚それぞれの登録の応答、2の一覧の枚数、3の一般向けの画面での表示は、いずれもこの記事の時点で確認していません。9月8日に説明文とサービスの反映を確かめたときは、ブラウザで開いた地図の画面に表示の制限が出て、一般向けの画面での確認は残件になっています。写真も同じで、確認できた日に、このブログに書き足します。

【登録のあとの読み戻し——3段階を分けて記録する】

登録した枚数: ____枚（日付: ____年__月__日）

1. 応答           □ 全部通った（__/__枚）  □ 一部失敗（失敗分は失敗記録へ）
2. 一覧の枚数     登録前: ____枚 → 登録後: ____枚（差が登録した枚数と一致するか）
3. 一般画面の表示 確認日: ____年__月__日（登録から__時間後） 表示: ____枚
                  ※ 最長24〜48時間ほどかかることがある、と公式ヘルプにある。翌日に0枚でも失敗と決めない

2と3の枚数が合わなければ、どの写真が無いかを番号で控えてから、失敗記録へ戻る

HaruIroAIはこう考える——17回目より、記録と、もう1つの経路

3つ書きます。

ひとつ。再試行は、記録があって初めて「回数」になります。記録が無い再試行は、何度やっても1回目と同じです。16回という回数は、判断のあとに集計として残したもので、判断の材料にはなっていません。1行ずつ残していれば、5回で切り分けに移れたはずです。

ふたつ。原因は推測しません。言えるのは「わざと崩したら400、形式を整えて送ったら500」という2つの応答の事実と、そこから「形式の不備として弾かれたのではない」と読んで、別の経路を1回試すと決めた判断までです。送り方の問題を除外できたとは言えません。Google側で何があったかは、公式の告知を見つけていませんし、探して無かったから無いとも言えません。分からないことは、分からないと書いて、分かることで次に進みます。

みっつ。「通った」は3段階で数えます。応答、一覧、一般の画面。私たちがいま言えるのは、試験の1枚についての1段階目までで、13枚それぞれの応答と2・3段階目は未確認です。そこを「載せました」と一言でまとめないことが、お客様のプロフィールを受け持つときの約束の形だと考えています。

この記事で書いていないこと

6つあります。ひとつ、Google側で内部エラーが起きた原因は書いていません。分からないからです。ふたつ、公開URLを渡す経路が一般的な解決策だとは書いていません。自社の1つのプロフィールで、1日に起きたことです。みっつ、管理画面から写真を登録する操作の挙動は検証していません。自社の登録はAPIで行いました。よっつ、13枚それぞれの登録の応答と、一般向けの画面での表示は確認していません。運用記録にあるのは、試験の1枚が200で通ったことと、この経路で登録する方針までです。確認できた日に書き足します。いつつ、写真を載せたことで閲覧数や問い合わせがどう動いたかは書いていません。9月5日の記事に書いたとおり、判定は4週たまってからで、母数が30に満たないあいだは率を出しません。むっつ、送り方の問題を除外できたとは書いていません。崩した送信への400は、形式の不備が検知されていることを示すだけです。

よくある質問

管理画面で写真の登録に失敗します。この記事の経路の話は使えますか。
管理画面には「公開URLを渡す」に当たる操作が無いので、経路を替える話はそのままは使えません。使えるのは、失敗記録の3項目（何回・どの経路・何が返ったか）と、公式の条件（JPGまたはPNG・10KB〜5MB・最小250×250）を先に確かめること、そして表示まで最長24〜48時間ほどかかることがあるという公式の記述です。同じ操作を5回繰り返して同じ結果なら、記録を持って委託先かGoogleのヘルプへ相談する段階です。

16回は多すぎませんか。何回で止めるべきでしたか。
多かったと思います。振り返ると、同じ応答が5回並んだ時点で切り分けに移れました。この記事のテンプレに「5行並んだら」と書いたのはそのためです。5という数字に公式の根拠はなく、自社の反省から置いた目安です。

公開URLを渡す経路なら、画像はどこに置けばいいですか。
私たちは自社サイトの決めた場所に置くことにしました。公式の条件は「メディア項目を取得できる、一般公開されたURL」で、置き場所の指定はありません。ただし、人がブラウザで開けることと、Googleの取得元が開けることは別です。自社サイトは決まった名乗りをしない自動アクセスに403を返す設定で、手元の道具では開けませんでしたが、Googleからの取得は通りました。サイトの設定によっては逆も起こり得ます。

投稿に付ける写真も同じですか。
違います。公式ページに「ローカル投稿にメディアを含める場合は、URL からアップロードしてください」とあり、投稿の写真は公開URLを渡す経路だけです。プロフィールの写真は2経路、投稿の写真は1経路。委託先がツールで投稿しているなら、投稿の写真はもともと公開URL経由です。

直接送る経路は、もう使えないのですか。
分かりません。私たちが試したのは2026年9月5日の1日、1つのプロフィールで16回です。翌週に通るかもしれませんし、別のアカウントでは通っているかもしれません。公式リファレンスには今も2つの経路が書かれています。この記事は「使えない」とは言っておらず、「同じ経路の17回目より、もう1つの経路を1回」と言っています。

まとめ——同じ経路の17回目より、記録と、もう1つの経路

HaruIroAIは2026年9月5日、自社のGoogleビジネスプロフィールへ写真13枚をAPIで登録しようとして、画像を直接送る経路が16回中16回、Google側の内部エラーで失敗しました。送り方をわざと崩すと別の応答（400）が返ったので、形式の不備は検知されていると見て、公式リファレンスにあるもう1つの経路「公開URLを渡す」を試し、試験の1枚が200で通ったことを確かめて、13枚はその経路で登録する方針にしました。13枚それぞれの登録の応答は、この記事の時点で運用記録から確認できていません。原因は分からず、書いていません。送り方の問題を除外できたとも言えず、自社で試験の1枚が通った経路であって、一般的な解決策ではありません。再試行を続ける前に残すのは、何回・どの経路・何が返ったかの3項目。登録のあとは、応答・一覧・一般画面の3段階で数えます。自社が言えるのは、試験の1枚の1段階目までです。

Googleビジネスプロフィールに正しい情報と写真を載せ、毎月の投稿と数字の確認まで受け持つ形は、はるいろWeb担当のページに、プランごとに含まれるものと含まれないものを書いてあります。