何を作ったか
このサイト（st26life.com）への記事投稿と、Threadsへの投稿を半自動化する小さなパイプラインの構築を、Claude Code（AnthropicのCLIエージェント）と進めています。
「半自動」としているのは意図的です。AIに任せるのは下書きの生成と送信作業まで。公開の判断は必ず私がWordPressの管理画面で行う設計にしています。
構成
Node.js 20以上で動くスクリプト3本だけの構成です。外部ライブラリは使わず、ネイティブのfetchだけで動きます。
- wp-publish.mjs — content/drafts/ のMarkdownをWordPressへ「下書き」として投稿
- threads-post.mjs — content/threads/ のテキストをThreadsへ投稿
- token-refresh.mjs — Threadsの長期アクセストークン（60日で失効）の残日数確認と更新
記事はfrontmatter（タイトル・カテゴリ・タグ・抜粋）付きのMarkdownで管理します。投稿に成功したファイルにはWordPressの投稿IDが自動で書き戻され、次回実行時はスキップされるため、二重投稿が起きない仕組みです。
WordPress側の連携
WordPressへの投稿はREST APIとアプリケーションパスワード（Basic認証）を使っています。サーバーはXserverです。
ここで安全のために決めたのが「statusは常にdraft固定」というルールです。スクリプトにはpublish機能そのものを実装していないため、仮にAI側の挙動がおかしくなっても、勝手に記事が公開されることはありません。
Threads側の連携
Threads APIは「コンテナ作成」と「publish」の2段階で投稿する仕様です。長期トークンは60日で失効するため、残日数をチェックするスクリプトを用意し、15日を切ったら更新を促す運用にしています。
また、新規アカウントでのスパム判定を避けるため、投稿は1日1〜2件までと運用ルールを決めました。
安全側に倒した設計
AIに送信系の操作を任せる以上、「事故が起きない構造」を先に作ることを優先しました。
- WordPressへは下書きのみ。公開は管理画面から手動
- 送信前に必ずdry-run（送信内容の表示のみ）で確認できる
- 本番送信は1件ごとにy/nの確認プロンプトを挟む
- 認証情報は.envに置き、Gitには含めない
- 記事は私が渡した作業ログにある事実だけで書く（捏造禁止をルール化）
セットアップでやったこと
今日はWordPress側のセットアップまで進めました。
- .env.exampleをコピーして.envを作成
- WordPress管理画面でアプリケーションパスワードを発行（スペース区切り24文字。スペースはスクリプト側で除去されます）
- .envにサイトURL・ユーザー名・アプリケーションパスワードを設定
Threads側はMeta for Developersでのアプリ作成とトークン取得がまだなので、次回の作業です。
今後の構想
まだメモ段階ですが、Gitでのバージョン管理や、ホスティングサービスを使った自動更新環境への発展も考えています。まずはこのパイプラインを安定して回すところからです。
まとめ
「AIにどこまで任せて、どこから人間が握るか」の線引きを先に決めてから作ると、安心して任せられると感じました。この記事自体も、このパイプラインの動作テストを兼ねています。