過去記事をAIで分析するため、WordPressの記事データをGitHubに保存しています。
前の記事では、AI（Codex）に一度声をかければ、記事の取得から保存まで完了する仕組みを作った話を書きました。
ただ、それでも毎回「同期して」と頼む手間は残ります。できれば、こちらから声をかけなくても、データが更新されていてほしいところです。
そこで、ブログで使っているConoHa WINGに同期プログラムを置き、毎朝動かす仕組みを作りました。最初の自動実行も終わり、GitHubへの保存まで確認できています。
今回は、毎回AIを呼ばなくても動く仕組みの全体像と、構築の途中でつまずいた点をまとめました。最後に、自分のAIへ同じような仕組みを作ってもらうための依頼文も載せています。
同期するたびにAIを使うものだと思っていた
最初は、定期的な同期にも、AIコーディングツールのCodexを使い続けるものだと思っていました。繰り返す作業なので、使うなら軽いモデルにしてほしい、と相談していたくらいです。
ところが、記事を取得し、変換・検査して保存する手順がプログラムになっていれば、同期するたびにCodexに指示を与える必要はないと分かりました。
動かす場所に選んだのは、すでに使っているConoHa WINGです。サーバーにプログラムを置き、cronという定期実行の仕組みに、毎朝起動するよう設定しました。炊飯器のタイマーのように、決めた時刻になったら処理を始めてもらうイメージです。
Macは最初の接続準備や配置、確認に使いましたが、日々の同期はConoHa上で動きます。そのためにMacを起動し続ける必要もありません。
これ、すごくない？ Macを閉じていても、朝の作業を始めるころには、前日にWordPressで更新した記事がGitHubに取り込まれている。もちろん同期が正常に終わっていれば、という条件はありますが、毎回自分で頼まなくていいのはかなり楽です。
しかも、ConoHa WINGの契約内で使える機能なので、スケジュール設定のために追加料金を払う必要もありません。今までまったく使っていなかったのは、もったいなかったかも。
AIを使えば、自分1人なら全く使えなかった機能まで使えるようになるので、まじですごいっす。
どこで何が動くのか
各サービスの役割を整理しました。
- WordPress：公開記事のデータを取り出す場所
- ConoHa：取得・変換・検査のプログラムを動かす場所
- GitHub：分析用の記事データと変更履歴を保存する場所
ConoHa上のプログラムがWordPressから記事を取り出し、Markdownや記事一覧、リンク情報を作ります。それらを検査し、変更があればGitHubへ保存する流れです。
更新するのは分析用のコピーです。WordPressの公開記事は書き換えません。
接続用の鍵も別々です。MacからConoHaへ入るためのSSH鍵はMacで保管し、ConoHaからGitHubへ接続するための鍵はConoHaのWeb公開領域の外で管理しています。
つまずき1：海外アクセス制限
最初に確認が必要だったのは、記事を取り出すためのREST APIへ接続できるかどうかでした。
ConoHa WINGには、海外からのアクセスを制限する機能があり、REST APIも設定対象に含まれます。普通の記事ページが読めても、データ取得用の入口には別の制限がかかることがあるわけです。
同期の準備中には、記事データをうまく取得できないことがありました。原因を確かめるために、この制限を一時的に切り替える案も出ました。ただ、同期するたびに私がON・OFFを操作する運用にはしたくありませんでした。
そこで、制限を維持したまま取得できる方法をAIに調べてもらいました。実際にConoHa上から試すと、私の環境では制限をONにしたまま公開記事を取得できました。
以前の接続失敗の原因は特定できていません。ただ、ConoHa上からなら制限をONにしたまま取得できることを確かめられたので、この構成を採用しました。
つまずき2：途中で止まるとデータが食い違う
取得できるようになっても、保存の仕方に修正が必要でした。
最初はGitHubへ送るデータ量の制限で止まり、送信方法を変更しました。その後、保存に成功したものの、取得した元データと、そこから作るMarkdownや一覧が、別々の段階で反映されていることが分かりました。
もし途中で止まれば、元データだけが新しくなり、一覧は古いままになるかもしれません。本の中身を更新したのに、目次だけが前の版のまま残るような状態です。
そこで定期実行をいったん止め、必要なデータをすべて用意して検査してから、まとめて反映する方式へ直しました。
例えば、同期用データを準備している間に別の作業でGitHubが更新されていたら、想定していた版と違ってしまいます。こうした競合に備え、保存前にGitHubの状態を確かめる手順も整えました。
「保存できた」という結果だけでなく、保存したもの同士がそろっているかまで確かめる必要がありました。
つまずき3：失敗したら保存せず止まる
修正版を試す途中でも、取得先からエラーが返り、同期が止まったことがありました。このときはGitHubを更新せずに終了し、回復を確認してから再試行すると保存できました。
ここで避けたいのは、「取得できなかった」を「記事がなくなった」と扱ってしまうことです。空のデータを正しい結果として保存すれば、保存済みの分析用コピーを空の内容で上書きしてしまうおそれがあります。
今回は、取得に失敗したら保存せず止まる動きを確認できました。自動化では、失敗しても無理に最後まで進めないことも大切です。
設定しただけでは完成にしない
最後に残ったのが、手動の指示なしで本当に動くかどうかでした。
翌朝の結果を確認すると、予定した自動実行による変更がGitHubへ保存されていました。その後、サーバー側の処理終了と、GitHubに保存した版がサーバー側の保存済み記録と一致していることも確認しました。
これで、毎回私が「同期して」と頼まなくても、取得から保存まで進むことを確認できました。
もちろん、まだ最初の自動実行を確認した段階です。長く使ったときの安定性や失敗時の通知には、確認・整備する余地があります。鍵の管理や、問題が起きたときの調査・保守も引き続き必要です。
どのAIを使うかの前に、毎回AIが要るか
最初は「どのAIモデルを使うか」と考えていました。今回の同期では、毎回同じ手順を繰り返す部分を、プログラムに任せられると分かりました。
もともとの目的は、過去記事をAIで分析し、リライトや整理に役立てることです。そのためのデータを用意する作業と、そろったデータから記事の直し方を考える作業は、分けられました。
分析やリライトは、引き続きAIと進めます。その準備のたびに「同期して」と頼む手間を減らせたことが、今回の前進です。
自分のAIに頼むなら
同じような仕組みを作りたいなら、まず次のものを用意します。
- 自分が管理するWordPressのURL
- 定期実行や必要なプログラムが使えるConoHa WINGの契約・環境
- 記事のコピーを保存する非公開のGitHubリポジトリ
- ファイルやサーバーを扱えるAIの作業環境。接続や操作ができる範囲は、使うツールによって異なります
新しい契約や権限を追加する前に、まずは今の環境で何ができるかをAIに確認してもらいます。会話だけのAIなら、手順を聞いて自分で操作する部分も出てきます。
依頼文には、今回つまずいた点も条件として入れました。アクセス制限には「取得場所の確認」、目次と本文の食い違いには「まとめて保存して照合」、取得エラーには「空データとして保存しない」が対応します。
URLと保存先を置き換えて使ってください。秘密鍵やパスワードは書き込まないでください。
AIへの依頼文
私が管理するWordPressの公開記事を、ConoHa WING上で定期取得し、GitHubへ分析用のコピーとして保存する仕組みを作りたいです。
対象のWordPress：［公開サイトのURL］
GitHubの保存先：［リポジトリ名またはURL］
実行頻度：毎日。時刻とタイムゾーンは相談して決めたいです。
次の順序で進めてください。
1. 現在の契約・接続環境で、必要なプログラムと定期実行が使えるかを確認する。続いてConoHaから公開REST APIで記事を取得できるか、少量で試す。
2. 取得できたら、プログラムや設定をWeb公開領域の外に置く計画と、必要最小限の接続権限を提案する。認証や権限の作成・変更は、内容とリスクを説明して、その都度私の確認を取る。秘密鍵やパスワードなどの入力・転送が必要なら、私自身が安全に操作できるよう案内する。
3. GitHubやWordPressを変更しない取得・変換・検査を行い、取得漏れや想定外の変更がないか確認する。
4. 保存する範囲を私と確認してから、元データとMarkdown・一覧をそろえ、途中で失敗しても一部だけが新しくならない形で、まとめてGitHubへ反映する。まずは手動実行で確かめる。保存直後にGitHubを読み直し、GitHubに保存した版と、サーバー側が保存済みとして記録した版が一致するかを確認する。
5. 手動確認が済んだら、時刻とタイムゾーンを確認して定期実行を設定する。設定だけで完成とせず、最初の定刻実行が終わり、保存と状態記録まで完了したことを確かめる。変更なしの場合も、正常終了を確認する。
次の条件を守ってください。
- WordPressの公開記事を変更・削除しない。
- 秘密鍵、パスワード、トークンをチャット、GitHub、実行ログ、公開用ファイルに残さない。非公開リポジトリにも保存しない。
- セキュリティ機能を常時OFFにして動かす方法を前提にしない。
- 取得失敗を「記事がなくなった」「空のデータ」として保存しない。検査失敗、想定外の変更、他の作業との競合があれば停止し、理由を報告する。
- 保存後の一致と処理終了、次回を妨げる実行中状態が残っていないことを確認する。
- 同期用の定期実行だけを止める方法と、動いている処理の確認方法も教える。停止時は保存データや他の定期処理を消さず、実行中の処理を無理に終了させない。再開前に途中状態を確認する。
実作業できないところや、私の操作が必要なところは明示してください。自分の環境に合わせて進める
環境によって接続方法や必要な手順は変わります。この依頼文を、自分の環境でAIと作っていく入口として使ってみてください。
参考資料
- ConoHa WING公式：サーバー管理機能：cronによる定期実行の案内。
- ConoHa WING公式：WordPressのセキュリティ設定：REST APIを含む海外アクセス制限の案内。
＊関連記事
補足資料：ConoHa WING公式仕様資料：契約料金と共通機能のジョブスケジューラーについて。
コメント