画面操作の自動投稿をやめて Pinterest API へ移ると決めた理由

relmea は2026年8月8日から、ピンの投稿をブラウザの自動操作で行っていました。

8月15日、動画ピンで問題が起きました。下書きを開き直した直後は動画が読み込まれておらず、再生時間が 0:00 のままです。その状態で「公開」を押すと、何も起きないまま下書きが残ります。エラーも出ません。

この事象は、動画ピン6本のうち3本で起きました。

対処として、動画の長さが0より大きいことを確かめてから押す判定を足しました。ただ、これは画面の挙動に合わせて後から足した対処です。画面が変われば、また同じ種類の止まり方をします。画面の変化に弱いという性質は残ったままでした。

これが、公式の API へ移る動機の一つになりました。

Pinterest API の審査は2段階（Trial → Standard）

Pinterest API には、試用の Trial アクセスと、本番向けの Standard アクセスがあります。relmea の経過は次のとおりです。

  • 2026年9月19日: API 用のスクリプトを用意（OAuth・ボード一覧・数字の取得・投稿）
  • 2026年9月29日: Trial が承認。同じ日に Standard へ申請
  • 2026年10月7日: Standard が却下（メールで通知）
  • 2026年10月24日: 再申請
  • 2026年10月27日: Standard が承認。同じ日に投稿を API へ切り替え
Pinterest API の審査は、Trial の承認から Standard の承認まで28日かかった
  1. 9月19日 準備OAuth・ボード一覧・数字の取得・投稿のスクリプトを用意。公式仕様だけを根拠にし、未検証の箇所は明記した
  2. 9月29日 Trial 承認数字の取得はすぐ動いた。本番でのピン作成は 403（code 29）で不可。同じ日に Standard を申請
  3. 10月7日 却下メールで届いた。デモに Pinterest との連携と OAuth の全体が映っていない、という指摘
  4. 10月24日 再申請デモ動画を作り直して提出した
  5. 10月27日 Standard 承認同じ日に、ピンの投稿を API へ切り替えた

審査の前に書いたスクリプトの方針

スクリプトは審査の前に書きました。レスポンスの形は公式仕様（OpenAPI）だけを根拠にしています。確かめていない箇所は「未検証」と明記し、初回の実際の応答を保存して、その形で固める方針にしました。想定で書いた形をそのまま信じないためです。

Trial でできたことと、できなかったこと

Trial が承認された9月29日に、数字の取得はすぐ動きました。実際の応答を見て直した点が2つあります。

  • 分析 API の指標の指定は、カンマ区切りで渡さないと先頭の1指標しか返らない
  • ピン一覧の 5xx は一時的なものなので、3回まで再試行する

どちらも、仕様を読んだだけでは書けなかった修正です。初回の応答を保存しておいたので、どこが想定と違ったかをすぐ特定できました。

一方で、Trial は本番環境でピンを作れません。作ろうとすると 403（code 29）が返ります。ピンを作れるのはサンドボックス環境だけで、サンドボックスのトークンは30日で失効します。

つまり Trial の間は、「数字は本番で取れるが、投稿は試験環境でしか試せない」状態です。自動投稿が目的なら、Standard の承認が必要になります。

Standard の審査で却下された理由と、デモ動画の作り直し

9月29日の Standard 申請で出したものは3つです。

  • デモ動画（80秒。OAuth は本番、ピン作成はサンドボックス、数字は本番）
  • プライバシーポリシーに「Pinterest API の利用」の項を足して公開したもの
  • 使用目的の説明

却下の理由は2つの型だった

10月7日に、メールで却下が届きました。理由は次の2つの型です。

  • デモで Pinterest との連携が表示されなかった
  • デモで OAuth のすべての流れが表示されなかった

初回のデモはスライドを挟んでおり、ピン作成はサンドボックスで見せていました。説明のための画面と、実際に動いている画面が混ざっていた構成です。審査する側からは、実際に連携している場面が見えにくかったのだと読み取りました。

デモ動画 v2 で変えたこと

10月24日の再申請では、デモ動画を作り直しました（119秒）。

  • スライドを使わない
  • 実際のターミナルと実際のブラウザだけで撮る
  • 認可画面、許可、コールバック、トークン交換の順に、OAuth の流れを全部映す
  • 本番でボード一覧と数字を取る
  • サンドボックスでピンを作る（応答は 201）
  • 英語字幕をつける

説明文にも1文を足しました。「デモのピン作成は Trial の制約でサンドボックスを使っている」という内容です。ピン作成だけ環境が違う理由を、動画を見る前に分かるようにするためです。

当初は、作ったピンが Pinterest 上に表示されるところまで撮る予定でした。ところが10月24日に試すと、サンドボックスで作ったピンは画面に表示されませんでした。そのため、表示ではなく端末の応答（201）で見せています。

この再申請が、10月27日に承認されました。

Pinterest API の Standard 審査で通ったデモは、スライドをやめて実際の画面だけで OAuth の全体を映した

却下されたデモ（80秒）

  • スライドを挟んだ
  • ピン作成はサンドボックスで見せた
  • 「連携が表示されない」「OAuth の全体が表示されない」と指摘された

承認されたデモ（119秒）

  • スライドなし。実際のターミナルとブラウザだけ
  • 認可画面から許可、コールバック、トークン交換まで映す
  • 本番でボード一覧と数字、サンドボックスでピン作成（201）
  • 英語字幕つき。サンドボックスを使う理由を説明文に1文

審査待ちの見張りが、却下を知らせなかった

審査を待つ間、開発者ページの「保留中」の表示が変わったら通知する見張りを毎日回していました。

ところが、10月7日の却下はこの見張りから通知されませんでした。見張りが見ていたのは「保留中の行が消えたか」だけで、却下はメールで届いていたためです。

行が消える理由は、承認でも却下でもあり得ます。「変わったか」だけを見ていると、結果が何だったのかは分かりません。今回は、結果が別の経路（メール）で来たので、行の変化を待っていても気づけませんでした。

審査のように結果が複数ある状態を見張るときは、「変わったか」ではなく「何になったか」まで読む必要があります。結果が届く経路が画面以外（メール）にもあるなら、そちらも見張りの対象に入れます。

承認後に作った Pinterest API の投稿の仕組み

Standard が承認された10月27日に、投稿を API へ切り替えました。初回は画像ピン1本と動画ピン1本です。どちらも、ログインしていないブラウザで実際に見えることを確かめました。

作成のあとに必ず確かめる2つ

API で投稿するスクリプトは、ピンを作成したあとに次の2つを確かめます。

  • API で読み戻して、ボード・リンク・タイトルが入力どおりか
  • ログアウトした状態で、ピンのページが見えるか

作成の API が成功を返しても、それだけで「投稿できた」とは言いません。公開された面で見えて、はじめて投稿できたと扱います。

結果は終了コードで分ける

スクリプトの終了コードで、次にすることを決めています。

  • 0: ログアウト状態で見えた。投稿できたと報告してよい
  • 4: ピンは作成済みだが、確認に通らなかった。投稿し直さない（二重投稿になる）。要確認として、残りの投稿は止める
  • 5: 送信中に通信が落ち、作成されたか分からない。投稿し直さず、ピンの一覧で確かめる
  • 1・3: 作成されていない。理由を残し、画面操作の予備の経路で投稿する

投稿し直してよいのは、作成されていないと分かっているときだけです。ここを分けておかないと、通信が落ちた場面で同じピンが二重に出ます。画面操作の経路は予備として残し、作成前のエラー（トークン切れ・通信）のときだけ使います。この分岐には17件のテストを付けています。

Pinterest API でピンを作ったあと、終了コードで「投稿し直してよいか」を分ける
  1. 0 見えたログアウト状態でピンが見えた。投稿できたと報告してよい
  2. 4 確認に通らない作成済み。投稿し直さない（二重投稿になる）。要確認として残りは止める
  3. 5 作成されたか不明送信中に通信が落ちた。投稿し直さず、ピンの一覧で確かめる
  4. 1・3 作成されていない理由を残し、画面操作の予備の経路で投稿する

動画ピンも1回の実行で通す

動画ピンは、動画の登録、アップロード、処理待ち（最大10分）、ピン作成、読み戻し、ログアウト状態での確認までを、1回の実行で通します。画面操作のときに起きた「動画が読み込まれる前に公開を押してしまう」問題は、処理待ちを API の状態で確かめる形に置き換わりました。

取得した数字は、あとから変わる

承認後は、過去30日分の数字を API で取れます。ただし、数字はあとから積み増されます。実測では、ある日の値が当日は558、2日後に取り直すと573でした。

そのため、過去の記録行は取り直していません。当日に取った値を、その日の記録として残しています。取り直すと、ほかの列（フォロワー数など）だけが今日の値になり、行の中で日付が揃わなくなるためです。

EC・ブログの運営者が読み替えるときのポイント

relmea が投稿しているのは、記事から作ったピンです。EC 事業者が商品のピンで同じことをするなら、次のように読み替えられます。

  • 審査のデモ動画には、実際に使う流れをそのまま映す。スライドで補わない
  • Trial の制約で本番の操作を映せない部分は、その理由を説明文に書いておく
  • プライバシーポリシーに、Pinterest API の利用についての項を足して公開しておく
  • 審査の結果は、開発者ページの表示だけでなくメールまで含めて見張る
  • 投稿のあとに、読み戻しとログアウト状態での表示確認を入れる。商品ページへのリンクが入力どおりかも、ここで確かめられる
  • 通信が落ちたときに投稿し直さない決まりを、最初から作っておく

Pinterest API の審査は、却下されても理由の型が示されるので、直して再申請できます。relmea の場合は、Trial の承認（9月29日）から Standard の承認（10月27日）まで28日でした。審査の期間はアプリや時期によって変わるはずなので、この日数は1つの実例として読んでください。