WordPress│GitHub Actionsで集めたデータを参照&表示する方法

外部から取ってきたデータを、毎日決まった時刻に WordPress の記事へ反映したい。

よくある要件です。

株価でも天気でも為替でも、やることは同じです。

「どこか（GitHub Actions）で定期実行してデータを作り、それを WordPress に表示する」。

問題はその2つをどうつなぐかでした。

実際に組んでみたら、教科書どおりにいかない箇所が次々に出てきたので、動く最小構成と一緒に共有します。

著者

motoki

WEB制作をしているデジタルノマド
WordPressのカスタマイズが好きで、色々と自作しています。

WordPressのカスタマイズに困ったらご相談ください！

MOTOKI合同会社

カスタマイズの依頼・相談

ブラウザーから直接取得せず、サーバー間で送る理由

最初に考えるのは、たぶんこれです。

記事のページで JavaScript を書いて、データ元の API を直接 fetch() すればいいのでは？

ブラウザーから別のオリジンのAPIを読むには、API側のCORS対応が必要です。対応するAPIなら直接取得できますが、必要な許可ヘッダーを返さないAPIではブラウザーがレスポンスの読み取りを制限します。秘密のAPIキーを使う場合は、そのキーを公開JavaScriptへ埋め込まない構成も必要です。

私が使いたかった API も、コマンドラインからは普通に取れるのにブラウザからは一切通りませんでした。

# これは通る
curl "https://example.com/api/data"

# ブラウザの JavaScript からは CORS でブロックされる

このAPIではブラウザーからの直接取得を採用せず、サーバー間で取得・受け渡しする構成にしました。WordPressのサーバー側で取得する方法もありますが、本稿は定期実行をGitHub Actionsへ分ける例です。

次に考えるのが「GitHub Pages に JSON を置いて、WordPress から取りに行く」。

これは動きますが、リポジトリを非公開にすると GitHub Pages は有料プランが必要です。

コードを人に見せたくない場合はここで詰まります。

そこで逆向きにしました。

GitHub Actions（定期実行）
  └ データを取得・加工
      └ WordPress の受信エンドポイントに POST
          └ プラグインがオプションに保存
              └ ショートコードが表示

この形にすると、こうなります。

• リポジトリは非公開のまま運用できる
• データ表示の処理はWordPressに保存した値を読む構成にできる。ページ内のほかの外部通信までなくなるわけではない
• 定期取得用のサーバーを別途用意せず、GitHub Actionsを利用できる。無料枠に収まるかは実行時間・runner・保存容量・アカウント全体の利用量による

3つ目が地味に効きます。

月間の消費時間は、各実行の所要時間と実行回数で変わります。失敗後の再実行も含め、Actionsの利用量を確認してください。scheduleは指定した時刻から遅れたり、混雑時にジョブが欠落したりすることがあるため、データの取得日時も表示して鮮度を判断します。

以下サンプルコードと知見です。

掲載例は2026年10月13日に改修したPHP 8.1以降向けの構成です。JSONは64KiB・100項目までとし、日時・文字列・項目を検証します。受信トークン、再送ID、古い日時の拒否と、保存状態の条件付き更新を実装しています。改修前の入力検証不足を前提にした説明は、現在のコードには適用しません。

保存先はdata_bridge_state_v2です。旧データの自動移行はありません。旧版を使っている場合はバックアップを保存し、検証環境で新形式のデータを送り、表示と戻し方を確認してから切り替えてください。トークンは設定画面で明示的に発行する方式で、画面を開くだけでは発行しません。

送信先は指定したHTTPSホストと受信ルートに限定し、リダイレクトしません。失敗応答の本文や秘密値をログへ出さない送信例です。実WordPressで確認した範囲と未確認の範囲は、下の検証記録に分けています。

外部からの認証方式はWordPress公式のREST API認証、実行条件はGitHub公式のscheduleで確認できます。

LocalのWordPress・DBで確認した受信処理の範囲

2026年10月13日、新規Local環境のWordPress 7.1.3・PHP 8.1.23・MySQLで、架空データと検証用の値を使って掲載例の受信・保存処理を16ケース確認しました。WordPressのAPI、オプションのキャッシュ、DBへの保存、内部RESTの状態参照を実行した確認です。外部からのHTTP送信やGitHub Actionsの実行は行っていません。

HTTP扱いの拒否、照合値・リクエストID・JSONの不正、正常保存、同じIDの再送、同じIDで内容が違う場合、古い日時、新しい日時を確認しました。新しい状態へ更新した後に古い状態を条件にしたSQLを実行しても上書きされないこと、保存後にキャッシュから新しい値が読めることも確認しています。画面へ出す文字列のHTMLエスケープと、状態参照に照合値・項目本文が含まれないことを確認しました。

この確認でHTTPSの状態はCLIプロセス内の変数で与えており、TLS証明書や公開ネットワークの検証ではありません。並行プロセスの負荷試験、永続オブジェクトキャッシュ、GitHub Actionsからの送信、本番への導入、購入者の別アカウントは未確認です。現在のログイン済みChromeでは公開ページの全17コード枠が保存原稿と一致し、PC幅1280px・スマホ幅375pxで表示を確認しました。この記録は2026年10月13日のものです。今回の本文整理に伴う再実行結果ではありません。