公式APIが無いサイトを自動化する方法｜裏のAPIを観測

「/publish も /schedule も試したのに、返ってくるのは全部404」——公式APIが用意されていないサービスを自動化しようとして、こんなふうに手が止まった経験はないでしょうか。

結論から言うと、エンドポイントの名前は勘では当たりません。正解は「自分のログイン済みブラウザで対象操作を1回だけ手で実行し、その裏に飛ぶ通信を観測してURL・メソッド・本文（body）を確定する」ことです。推測ではなく観測が唯一の正解になります。

株式会社Fyveは、公式APIが無いサービスでも自分の発信基盤をこの方法で自動化してきました。この記事では、私が実際に踏んだ手順と、途中で全部踏んだ落とし穴を、そのまま追える形でまとめます。

なぜ「勘でエンドポイントを探す」と失敗するのか

大前提として、画面が動いている以上、その裏では必ず内部APIを叩いています。予約ボタンを押せばどこかにリクエストが飛び、サーバーがそれを処理して結果が返ってくる。だから「自動化できる余地」は必ず存在します。

問題は、その内部APIの名前が公開されていないことです。そして名前は、常識的な単語を並べても当たりません。私が自分の発信基盤（Substack）の予約公開を自動化したときは、/drafts/{id}/schedule や /publish など、それらしい名前を8通り推測しましたがすべて404でした。正解は /scheduled_release。この名前は、どれだけ考えても思いつけるものではありません。

ここで発想を切り替えます。名前を「当てにいく」のではなく、実際にボタンを押したときに本当に飛んだリクエストをそのまま観測する。当てものをやめて、事実を記録するアプローチに変えるだけで、成功率が一気に上がります。

既製の自動化ツールでブラウザを操作するだけで足りる場面も多くあります。どのツールで足りるかは、こちらの比較記事も参考にしてください。

Claude Codeブラウザ自動化｜Playwrightとbrowser-use比較

公式APIが無いサイトを自動化する5つの手順

実際の流れは、次の5ステップです。難しいのは4番だけで、あとは準備と後始末です。

手順1：ログイン済みのブラウザを選ぶ

対象サイトにすでにログインしているブラウザのプロファイルを使います。cookie（ログイン状態を保持する仕組み）が有効なので、再ログインもCAPTCHA突破も必要ありません。ここが後半のスクリプト化でそのまま効いてきます。

手順2：使い捨ての下書きで1操作だけ試す（安全の要）

観測のためとはいえ、操作は本当に実行されます。予約すれば本当に予約され、送信すれば本当に送信されます。だから本番データでは絶対に試しません。テスト用のダミー（捨ててよい下書きなど）を1件だけ用意し、そこで対象操作を行います。

このとき逆操作（削除・取り消し）が分かっているものを選ぶのが鉄則です。後片付けができない操作で試すと、痕跡が本番に残ってしまいます。

手順3：観測を「操作の前」に仕込む

通信の記録は、記録を始めた時点から先しか録れません。操作を実行してから「さあ記録しよう」では手遅れです。必ず、ボタンを押す前に観測の準備を済ませておきます。

観測の中身はシンプルで、ページ上で飛ぶ通信を横取りせずに「通しながら控える」だけです。イメージとしては、次のように fetch を包んで、URL・メソッド・bodyを記録します（止めずに通すのがポイント）。

const _f = window.fetch;
window.fetch = function(...a){
  記録する(a[0], (a[1]||{}).method, (a[1]||{}).body); // 控えるだけ
  return _f.apply(this, a);                          // そのまま通す
};

手順4：飛んだ非GETリクエストを特定する

操作を1回完了させたら、記録の中からその操作で新しく飛んだリクエストを探します。目印は「非GET」であること。データを変える操作は POST / PUT / DELETE で飛ぶので、閲覧のためのGETや、分析・エラー監視系の通信は除外します。残った1本が、探していた内部APIです。URL・メソッド・送信本文の3点を控えます。

手順5：スクリプトで再現し200を確認する

最後に、控えたcookieを付けて同じリクエストをプログラムから再現し、200（成功）が返るかを確かめます。ここまで通れば、以後はブラウザを開かずにその操作を自動化できます。あわせて逆操作（POSTならDELETEなど）も押さえておくと、テストと後始末が安全になります。

読者特典・無料ダウンロードClaude Codeを「素のまま」使うな無料でダウンロード →

私がこの方法で自動化したこと

具体例として、私は自分の発信基盤である Substack の予約公開を自動化しました。記事を書いたら指定時刻に自動で公開したい。ところが Substack にはそのための公開APIがありませんでした。

そこで、捨ててよいダミーの下書きを1本作り、ブラウザで予約操作を1回だけ実行。裏で飛んだ通信を観測したところ、POST /api/v1/drafts/{id}/scheduled_release に {"trigger_at":"（時刻）", ...} を送っていると分かりました。逆操作は同じパスへの DELETE、本文が空だとエラーが返ることも、再現の過程で判明しました。

ここまで確定すれば、あとは自作のスクリプトに落とすだけです。今では原稿を用意すれば、ブラウザを一切開かずに予約投稿まで通ります。割り出したAPIを常時起動のPCで定期実行に載せる流れは、こちらの記事にまとめています。

Claude CodeMac miniをAI自動化サーバーにする｜claude -p×launchdで定期実行を集約

つまずきやすい4つの落とし穴

私はこの過程で、次の落とし穴を全部踏みました。先に知っておくと数時間は節約できます。

AIに操作させると観測が壊れる：予約・送信・公開・決済のような「外向きの確定操作」は、AIに押させてはいけません。安全のためAI側でリクエストが遮られ、偽の応答が返ると、画面が誤作動して観測ごと壊れます。ボタンを押すのは必ず人です。
相対URLで取りこぼす：同じサイト内への通信は /api/v1/... のように省略形（相対URL）で書かれます。ドメイン名で絞り込むと、この省略形が漏れます。判定の前に必ずフルのURLへ直してから拾います。
記録は「操作の前」から：手順3の繰り返しですが、これが一番やりがちです。押してから記録を始めても、肝心のリクエストはもう飛んだ後です。
本文の必須項目で400が返る：再現段階で「本文が空だと400」のようなエラーが出ることがあります。これは失敗ではなく、必須の前提条件を教えてくれている合図です。エラー本文を読んで条件を埋めれば通ります。

この一連の設計を一言でまとめると、「AIは観測に徹し、確定操作は人が押す」という役割分担になります。

この方法が向くケース・向かないケース

すべての自動化をこの手法でやる必要はありません。向き不向きを先に見極めると、遠回りを避けられます。

向いているのは、次のようなケースです。

公式APIが無い、または欲しい操作だけAPIが用意されていない
予約・送信・エクスポート・一括更新など、画面上でボタン1つで完結する定型操作
自分が毎回手作業で繰り返している、自分のアカウント内の操作

逆に、向かないケースもあります。

公式APIがすでにある（素直にそちらを使うほうが速く、壊れにくい）
画面の見た目を操作するだけで足りる（既製のブラウザ自動化ツールで十分）
ログイン状態や画面の作りが頻繁に変わり、内部APIも一緒に変わりやすい

特に3つ目は重要です。内部APIは公開APIと違って予告なく変わり得ます。動かなくなったら、もう一度観測してURLやbodyの変化を確かめる——この「壊れたら録り直す」を許容できる範囲で使うのが、現実的な付き合い方です。

使う前に必ず守る前提（規約と安全）

最後に、この手法を使う前提を確認します。技術的にできることと、やってよいことは別だからです。

対象サービスの利用規約を確認する：自動化やアクセス方法に制限がないかを必ず確かめます。規約に反する使い方はしません。
操作するのは自分のアカウント・自分のデータだけ：他人の予約やデータには触れません。観測するのも、あくまで自分のログイン済みブラウザに流れる自分の通信です。
本番データで試さない・逆操作を先に押さえる：使い捨てのダミーで検証し、テストで作ったものは逆操作で必ず消します。
認証情報はコードに直書きしない：cookieやトークンは環境変数など外部の設定ファイルから読み込み、チャットやログに生の値を残しません。