当ブログ(KCのノート)の投稿・更新・予約公開・告知メールは、ほぼすべて自動処理です。この記事は、その構成・運用ルール・実際に踏んだ失敗を1本にまとめた運用記録です。
うまくいった話より、壊れた話と直し方のほうを厚く書いています。自動化で本当に困るのはそちらだからです。
※本記事は当サイトの運用記録(教育・解説目的)です。特定銘柄の売買推奨や将来予測を含みません。記載の仕様は実施時点(2026年7〜9月)のもので、外部サービスの仕様は変更されることがあります。
① 対象環境
- 開発: Claude Code(ターミナルで動くAnthropicのコーディングエージェント)
- 実行基盤: GitHub Actions(スケジュール実行) + Python の自作CLI
- 投稿先: WordPress(テーマ Cocoon)、REST API 経由
- 認証: WordPress のアプリケーションパスワード / Gmail のアプリパスワード
Claude Code そのものの導入手順や料金は変更の早い領域なので、この記事では扱いません。公式ドキュメント(code.claude.com/docs)の最新版を確認してください。ここに書くのは、当サイトが実際に組んで動かしている仕組みの側だけです。
② 全体像 — 定期ジョブと、その公開方法
| ジョブ | タイミング | 内容 | 公開方法 |
|---|---|---|---|
| 相場解説 | 平日夕方 | 主要銘柄の値動きを市場・為替・固有に分解して記事化 | 自動公開 |
| 週間まとめ | 土曜朝 | 週間騰落ランキング+内部リンク | 下書き→人間承認 |
| 講座配信 | 日曜朝 | ストックしてある講座を1本ずつ配信 | 下書き→人間承認 |
| 告知メール | 毎朝07:40 | その日公開の記事のX告知文をGmailで自分宛に送信 | 人間が手動でXに投稿 |
| イベント検知 | 毎時 | 価格急変・ニュースを検知してアラートメール | 検知のみ。記事化は人間判断 |
役割分担はこうです。Claude Code が仕組みと記事の型を作り、GitHub Actions が毎日回し、人間は承認と投稿だけを担当します。
③ 設計で決めた3つのルール
ルール1: 自動公開と人間承認を分ける
数値の集計記事(相場解説)は自動公開まで任せる一方、解説・教育記事は必ず下書き止まりにして人間が承認します。生成された文章は稀に事故るからです(⑤で実例を挙げます)。
「どこまで自動で出すか」の線引きを最初に決めておくと、事故が起きたときの影響範囲が読めます。これが一番大事な設計判断でした。
ルール2: SNSへの自動投稿はしない
X への投稿は、本文をメールで受け取って人間が手動で投稿する設計です。自動投稿は事故が即座に公開事故になりますし、投稿の最終責任を人間に残したいからでもあります。自動化の一歩手前で止めるのも設計のうちです。
ルール3: 秘密情報はコードに書かない
WordPress のアプリケーションパスワードや Gmail のアプリパスワードは、ローカルでは環境変数ファイル、CI 上では GitHub Secrets のみに置き、リポジトリには一切コミットしません。
④ WordPress REST API — 実務で使うのは5つ、罠は4つ
投稿系の自動化で実際に使うエンドポイントは、これだけで足ります。
| やりたいこと | エンドポイント | メモ |
|---|---|---|
| 投稿の作成・更新 | /wp-json/wp/v2/posts |
slug で冪等に。excerpt も設定可 |
| 予約公開 | 同上 | status: "future" + date |
| 画像アップロード | /wp-json/wp/v2/media |
返ったIDを featured_media に渡せばアイキャッチ |
| カテゴリ・タグ | /wp-json/wp/v2/categories /tags |
slug で検索 → なければ作成、が安定 |
| メニュー編集 | /wp-json/wp/v2/menu-items |
フッターへの固定ページ追加もAPIでできる |
認証は WordPress 標準のアプリケーションパスワードで十分です。管理画面の「ユーザー → プロフィール」で発行でき、本パスワードと違って用途ごとに発行・失効できます。
そして罠が4つありました。
罠1: 同じslugでPOSTすると重複記事ができる。 作成APIは同じslugでも素通りし、my-post-2 が生えます。自動運用では必ず「slugで既存検索 → あれば更新、なければ作成」の冪等パターンにします。定期ジョブは失敗リトライで二重実行される前提で書くべきです。
罠2: 予約投稿の日時はタイムゾーンに注意。 date はサイト設定のローカル時刻、UTCで指定したいなら date_gmt。混ぜると「朝7時の予定が夕方に公開」が起きます。どちらか一方に統一します。
罠3: テーマ独自の設定はRESTの外。 サイト設定の多く(Cocoonの「ヘッド用コード」など)はREST APIでは操作できません。テーマ設定はDBの別領域にあるためで、そこだけ管理画面での手作業に残しています。「どこまでAPIで届くか」を最初に確認しておくと設計を誤りません。
罠4: 更新したのに反映されない。 更新APIは成功しているのにページが古いまま、という現象の原因はサーバー側のページキャッシュでした。REST経由の一部操作ではキャッシュが飛ばないことがあります。検証時はキャッシュを疑い、クエリを付けて素の応答を確かめると切り分けが速いです。
⑤ 失敗1: AIの「前置き」が記事に混入した
生成された解説の冒頭に「本文を返します」という前置きがそのまま載る事故がありました。モデルは時々、依頼への返答として自然な「了解しました」系の文を本文に付けてしまいます。
対策は2段階にしました。(1) 生成後に前置きらしい行を機械的に検出して除去するフィルタを通す。(2) 公開済み記事も一括バックフィルで修正。
教訓は単純で、生成された出力は必ず後処理を通してから公開する。起きる前提で設計しておくことです。
⑥ 失敗2: GitHub Actions の未設定Secretは「空文字」で渡る
メール送信が SMTPRecipientsRefused: {'': ...} で失敗しました。原因は、GitHub Actions では未設定のSecretが「存在しない」ではなく「空文字」として渡ることでした。
# NG: EMAIL_TO が空文字だと '' がそのまま宛先になる
to = os.environ.get("EMAIL_TO", default_addr)
# OK: 空文字もフォールバックさせる
to = os.environ.get("EMAIL_TO") or default_addr
get(key, default) は「キーはあるが空」を拾えません。CI環境の環境変数は空文字で来る前提で書くのが安全です。
⑦ 失敗3: 金曜日が104日ぶん消えていた
これが一番大きな事故でした。株価を市場・為替・業種・固有に分解する回帰分析パイプラインで、検算が「4.7ポイント合わない」と吐いたのが始まりです。
発見できたのは、検算を最初に義務付けていたから
このバグは、目視でチャートを見ていても絶対に気づけませんでした。起点は、パイプラインに最初から仕込んでいた恒等式チェックです。
値動きの分解は、足し合わせると元の値動きに一致しなければならない
分析を任せる際に、「もっともらしい結果」と「正しい結果」を区別する装置として、成立すべき等式・件数・分布のチェックを必ず出力させる——この規律が効きました。
調査は「仮説」ではなく「集計」から
「誤差では」と流さずに、次の順で作業させました。
- 結合後のデータの件数を数える → 営業日が104日消えていた
- 消えた日を曜日別に集計する → 全部金曜日。ここで原因がタイムゾーンだとほぼ確定
- 為替データの日付ラベルの由来を調べる → バーの開始時刻がUTCでラベルされ、東京の暦と1日ずれていた
ポイントは、仮説をいきなり求めず、集計を先にやらせたことです。「金曜が全滅」という異常な偏りは、曜日別に数えれば一目瞭然ですが、数えなければ永遠に見えません。数えるのが速くて嫌がらないというのが、監査作業でのAIの一番の利点でした。
修正より大変なのは「全部やり直し」
原因が分かれば修正は数行です(為替の日付を東京時間の暦に正規化)。大変なのはその後で、このデータの上に積んだ分析をすべて再実行しました。結果、感応度の推定値が約2倍変わり、モデル比較の順位が逆転し、統計的に有意だったはずの発見が1つ消えました。
再実行は退屈で大量ですが、パイプライン化してあれば「全部再実行して、変わった結論を一覧にして」で済みます。人手なら「大丈夫だったことにしたい」誘惑と戦う工程です。
データ分析としての教訓はデータで相場を読むときの4つの落とし穴に別途まとめてあります。
⑧ AIと組むときに効いた作法
- 「冪等に」「リトライ前提で」と最初に指定する。 事故るのは正常系ではなく再実行時です
- 変更系の操作は、まず GET で対象を確認するコードを書かせてから POST/PUT に進む
- 一括修正(バックフィル)は、対象一覧を先に出力させて人間が確認してから実行する
- 検算を最初に契約する。 成立すべき等式と期待される件数を先に決め、毎回出力させる
- 異常が出たら、仮説より先に集計。 件数・曜日・欠損の分布は数行で出ます
- 過去の結論も監査対象にする。 今回覆った3つの結論は、いずれも当時のデータでは筋が通って見えました
- リンター・型チェック・テストのゲートを最初に作らせておく。 以後の変更もそのゲートを通ってきます
⑨ 記録から言えること
- 自動化は「どこで止めるか」の設計が本体。 公開の最終責任が誰にあるかを仕組みに落とす
- 生成された出力は後処理と検証を通してから世に出す。 前置き混入のような事故は起きる前提で
- CIの環境変数は空文字で来る。
orフォールバックを癖にする - 自動運用の要は冪等性(slug検索→更新)とタイムゾーンの統一
- AIは間違ったデータの上でも高速に「もっともらしい結論」を出す。 だから賢い分析より先に、地味な検算の自動化から
- 覆った経緯ごと公開する。 修正を隠さないことが、この種のコンテンツの信頼の担保になる
「4.7ポイントのずれ」を放置しなかったことが、このプロジェクトで一番価値のある判断でした。
出典・手法: WordPress REST API の仕様は公式ハンドブックおよび実装時の実挙動によります。Claude Code の導入手順・料金は公式ドキュメント(code.claude.com/docs)を参照してください。本記事の失敗事例はすべて当サイトの運用中に実際に発生したものです。
※本記事は当サイトの運用記録(教育目的)であり、特定銘柄の売買推奨・将来予測ではありません。
関連記事: データで相場を読むときの4つの落とし穴 ｜ トヨタとホンダの株価はなぜ動くのか
コメント