当ブログ（KCのノート）の記事の大半は、Claude CodeとGitHub Actionsによる自動運用で作られています。平日の相場解説、土曜の週間まとめ、日曜の講座配信、毎朝の告知メール——この仕組みの全体像と、運用して分かった「自動化してよい境界線」、そして実際に踏んだ失敗を記録します。
対象環境
– 開発: Claude Code（ターミナルで動くAnthropicのコーディングエージェント）
– 実行基盤: GitHub Actions（スケジュール実行）＋ Python 自作CLI
– 投稿先: WordPress（REST API経由）／実施時点: 2026年7月
全体像：4本の定期ジョブ
| ジョブ | タイミング | 内容 | 公開方法 |
|---|---|---|---|
| 相場解説 | 平日夕方 | 主要銘柄の値動きを市場・為替・固有に分解し記事化 | 自動公開 |
| 週間まとめ | 土曜朝 | 週間騰落ランキング＋内部リンク | 下書き→人間承認 |
| 講座ドリップ | 日曜朝 | ストックしてある中級講座を1本ずつ配信 | 下書き→人間承認 |
| 告知メール | 毎朝07:40 | その日公開の記事のX告知文をGmailで自分宛に送信 | 人間が手動でXに投稿 |
役割分担はこうです。Claude Codeが「仕組みと記事の型」を作り、GitHub Actionsが毎日回し、人間は承認と投稿だけ。日々の運用に人間の作業はほとんど残っていません。
設計で決めた3つのルール
① 自動公開と人間承認を分ける
数値の集計記事（相場解説）は自動公開まで任せる一方、解説・教育記事は必ず下書き止まりにして人間が承認します。AIの文章は稀に事故るからです（後述）。「どこまで自動で出すか」の線引きを最初に決めておくと、事故時の影響範囲が読めます。
② SNSへの自動投稿はしない
X（Twitter）への投稿は、本文をメールで受け取って人間が手動投稿する設計です。自動投稿は事故が即・公開事故になるうえ、投稿の最終責任を人間に残したいため。「自動化の一歩手前で止める」のも設計です。
③ 秘密情報はコードに書かない
WordPressのアプリケーションパスワードやGmailのアプリパスワードは、ローカルでは環境変数ファイル、CI上ではGitHub Secretsのみ。リポジトリに一切コミットしません。
実際に踏んだ失敗2つ（そして直し方）
失敗1：AIの「前置き」が記事に混入した
生成された解説の冒頭に「本文を返します」というAIの前置きがそのまま載る事故がありました。モデルは時々、依頼への返答として自然な「了解しました」系の文を本文に付けてしまいます。
対策は2段階にしました。(1) 生成後に前置きらしい行を機械的に検出して除去するフィルタを通す、(2) 公開済み記事も一括バックフィルで修正。「AIの出力は必ず後処理を通してから公開する」が教訓です。
失敗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環境の環境変数は空文字で来る前提で書くのが安全です。
Claude Codeに任せて効いたこと
- 仕組みづくりの往復が速い。「週間まとめにX告知文の生成を足して」の一言で、生成ロジック・文字数制限（URL短縮の23字換算）・テストまで揃う
- 運用の異常対応。CIのエラーログを貼ると原因特定から修正・再実行まで一気に進む
- 規律の維持。リンター・型チェック・テストのゲートを最初に作らせておくと、以後の変更もそのゲートを通ってくる
持ち帰り
- 自動化は「どこで止めるか」の設計が本体。公開の最終責任が誰にあるかを仕組みに落とす
- AIの出力は後処理・検証を通してから世に出す。前置き混入のような事故は起きる前提で
- CIの環境変数は空文字で来る。
orフォールバックを癖にする
※本記事は当サイトの運用記録（教育目的）です。記載の仕様は実施時点のもので、変更される可能性があります。
コメント