去年の6月、「生成AIとの協働でWordPress管理システムを3〜4日で作った」という記事を書きました。
前の記事→「生成AIが実現した開発革命：WordPress管理システムを1日で構築した話」
あの記事では、生成AIが開発にかかる時間を劇的に短縮できることを伝えました。でも、「作った」のはスタートに過ぎません。本当に価値があるのは、作ったあとも使い続けられるかです。
この記事は、あのシステムを1年間実際に運用して何が起きたか、そして今日（2026年5月）、オープンソースとして公開するに至った経緯の記録です。
1年間で何が変わったか
数字で見る現在地
前の記事を書いた時点では「18件の投稿を統一フォーマットに変換した」という話でした。今はこうなっています。
指標2025年6月（v1.0）2026年5月（v2.1）管理サイト数1サイト4サイト管理コンテンツ数18件1,000件超スクリプト数数本40本以上X.com自動投稿なし実装済み
4サイトというのは、ITクオリティ株式会社が運営する以下のWordPressサイトすべてです。
-
www.itq.co.jp（公式サイト）：投稿243件・固定ページ25件
-
lab.itq.co.jp（ITQ Laboratory）：投稿36件・固定ページ5件
-
app.itq.co.jp（ITQ Applications）：投稿5件・固定ページ35件
-
tech.itq.co.jp（ITQ Techpedia）：固定ページ883件
最後のTechpediaの883件というのは、応用情報技術者試験のシラバスを解説した固定ページで、これをすべてシステムで管理しています。
「使う」と「育てる」は同時に起きた
最初に作ったシステムは、1サイトの投稿を整形することに特化していました。でも実際に使い始めると、すぐに「あれもしたい」「これも自動化できるのでは」という場面が出てきます。
そのたびに生成AIと対話して機能を追加しました。気づいたら、最初とはまったく違うシステムになっていました。
主な進化の軌跡：
-
2025年後半：v1.0 → 投稿前検証・エラーハンドリング強化
-
2026年2月：v2.0.0 → マルチサイト対応
-
2026年4月：v2.1 → X.com自動投稿・ITQ Techpedia連携
-
2026年5月：公開リポジトリの新設（本日）
最大の転換点：マルチサイト化（v2.0.0）
前の記事では「他サイトへの展開も可能」と書きました。実際にやってみると、思ったよりずっと大きな設計変更が必要でした。
問題は「設定の散在」だった
最初のシステムは、URLや認証情報がスクリプトの中に直接書いてありました。1サイトなら問題ありません。でも複数サイトを管理しようとすると、どこに何が書いてあるか追えなくなってきます。
設計を見直し、すべてのサイト情報を設定ファイルで一元管理する構造に変えました。
config/
├── sites/
│ ├── index.json # サイト一覧
│ ├── www.itq.co.jp.json # 各サイトの設定
│ └── lab.itq.co.jp.json
└── site-config.js # 設定を読み込むクラスこの設計にしたことで、新しいサイトを追加するときは設定ファイルを1つ作るだけで済むようになりました。
「設定の追加のみで無限拡張」を実現する難しさ
「設定ファイルを追加するだけで動く」という仕様は、作るのが意外と難しいです。各スクリプトがサイトを決め打ちしていると、拡張のたびにコードを直さなければならなくなります。
このリファクタリングには生成AIが大きく役立ちました。「このスクリプトをサイト設定から動的に読み込む形に変えてほしい」と伝えるだけで、適切な修正案を出してくれる。人間だけでやっていたら、全スクリプトを1本ずつ直す作業になっていたでしょう。
実際に使った場面：プレスリリースからGNSS比較記事まで
このシステムで管理してきた内容のうち、記憶に残っているものをいくつか挙げてみます。
ITQ GeoLogger 連続リリース（2026年3〜4月）
iOSとAndroidのGNSSロガーアプリを相次いでリリースした期間、ほぼ毎週プレスリリースを出す必要があっりました。
-
Android版 v1.5 リリース
-
iOS版 v1.6 リリース
-
Android版 v1.6 リリース
-
iOS/Android v2.0.0（ITQ GeoLoggerへの改称）リリース
このペースで手動投稿していたら、かなりの作業量になっていたと思います。システムで管理していたことで、下書きのMarkdownを用意すれば投稿・検証・公開まで一気通貫で対応できました。
「iPhoneとAndroidのGNSS測位精度を4つの環境で比較してみた」（2026年4月）
ITQ Laboratoryに実測レポートを公開したとき、www.itq.co.jpへの「お知らせ」投稿もシステム経由で行いました。記事のMarkdownを書いてコマンドを叩くだけで、ローカルの検証・WordPressへの投稿・ログへの記録まで自動で完了します。
こうした小さな手間が積み重なると、システムなしの運用には戻れません。
X.com自動投稿（2026年4月）
ITQ TechpediaはWordPressの固定ページが883件ある。これをX.comで少しずつ紹介するために、「未紹介のページを1件取り出して投稿文を生成し、X.comに投稿する」スクリプトを追加しました。
Google Gemini API（有料）で投稿文を生成し、X API経由（有料）で投稿する。日次実行することで、コンテンツが勝手に発信され続ける仕組です。
今日：オープンソース化という決断
今日（2026年5月1日）、このシステムの汎用部分を公開リポジトリとして公開しました。
akihikoichihara/wp-content-manager
何を公開して、何を公開しなかったか
公開したもの：汎用スクリプト群・APIクライアント・設定ファイル構造・テンプレート
公開しなかったもの：ITQ固有のスクリプト・コンテンツデータ・認証情報・社内運用ノウハウ
要するに、「WordPress × Git × Claude Code という構成と、それを動かすコード」は公開した。「ITQがどんなコンテンツをどう管理しているか」は公開しません。
なぜ今か
「作った」「使った」「育てた」という3段階を経て、はじめて「公開できる」という判断をしました。作りたてのシステムを公開しても、使い物にならないことが多いです。でも、実運用で何度も修正されたコードは、それだけで品質の証明になるのではと思った次第。
1年間使い続けて気づいたこと
生成AIは「完成させる」のではなく「育てる」ためのパートナー
最初の記事で「3〜4日で完成した」と書きました。確かにそれは事実です。でも、「使えるシステム」は作るのではなく育てるものです。
生成AIとの協働は、最初のスプリントだけでなく、その後の継続的な改良でも同じように機能します。「この機能を追加したい」「この部分をリファクタリングしたい」と伝えれば、その都度適切なコードを出してくれます。
「作り直す」より「育て続ける」方がコストが低い
最初の設計が完璧でなくても問題ありません。使いながら問題点が見つかり、その都度直していけばいいのです。生成AIがいれば、リファクタリングのコストが劇的に下がるからです。
Gitによるバージョン管理は「安心感の源」
1,000件超のコンテンツデータをすべてGit管理しています。何か誤操作をしても、いつでも戻せる安心感は運用の質を上げます。もちろん、別に全バックアップもしています。
おわりに
「生成AIで短期間に作ったシステム」は、1年間使い続けることで本当の価値を発揮してきます。
前の記事のテーマが「AIは速い」だったとすると、この記事のテーマは「AIは継続できる」ですね。
このシステムを土台に、次のフェーズではWordPressからCloudflare Pages（静的サイト）への移行も計画しています。それはまた別の記事で書く予定です。
ITクオリティ株式会社では、こうした生成AI活用のシステム開発・運用支援を行っています。
公開リポジトリ：akihikoichihara/wp-content-manager
ウェブサイト：www.itq.co.jp
お問い合わせ：お問い合わせフォーム