休眠していたWordPressベースの仕事術ブログをHugo + Cloudflare Pagesへ移行しました。
記事151本の変換や必要な技術仕様の策定と機能実装はClaude Codeにほぼ丸投げし、約2日で完了。
ここでは「なぜ今、移行しようと思ったのか」と「具体的にどうやったのか」を書きます。
WordPressブログの更新が止まった理由
経緯を振り返ると、更新が止まった原因は一つではありませんでした。
仕事術ブログの構造的な限界
2017年に仕事術ブログとして始めた「NAEの仕事効率化ノート」は、当初は純粋に「自分が学んだことをまとめたい」という動機で動いていました。書くことは楽しかったし、読んでもらえることも嬉しかった。
転機はブログを契機とした本の出版です。当初は初の単著で全力投球していましたが、出版に向けて自分の考えを体系化していく過程で、「ぼくがやっていたのは、世の中に溢れるビジネス書と同じことを、自分の言葉で再解釈しているだけだ」と気づいたのです。ビジネスノウハウ本の輪廻、車輪の再発明、そういう気分だったのをよく覚えています。
そういった背景もあり、執筆スピードが減速。ちょうど本業で立場が変わるというイベントもあり、
- これまで積み重ねた経験は整理整頓・明文化しきった
- むしろこれからの立場では見える景色が違う。自分が学ぶ立場になるフェーズだ
という境地に至ったことで、執筆はほぼストップしました。
そして数年後、追い打ちをかけたのが、生成AIの台頭です。生成AIは一般論としての仕事術を余すことなく学んでいます。自身が知りたい角度の質問をすれば、わりと何でも答えてくれます。
つまり、一般論レベルの仕事術はコモディティ化しきっており、情報発信そのものの意味が極限まで薄まっているのです。幅広な情報発信より、身近な人への生身のフィードバックや伴走支援など、実行と成果到達に至らせる部分にこそ価値が残ります。
要するに、「知っている」は誰でもすぐに到達できるので、仕事術を扱う者の主戦場が「実行できる」「継続できる」に到達させる部分に収斂される構造になりました。となると、仕事術の情報発信は、ビジネスコンサル業の集客・マーケティングのみが目的となった、と言い換えても良いでしょう。
一方、本業以外で伴走支援までを行う時間的余裕はぼくにはありません。過去の記事ストックなどの資産を活かすにしても、副業より本業に活用するほうがレバレッジが効きやすい。そのため、書く動機が著しく下がっていったのです。
参考 ブログ10周年。やってよかった理由は、全部スキルの話でした
管理だけが残り、負債化していった
書く動機を失った後も、WordPressは存在し続けました。「管理義務だけが残った状態」です。
テーマのアップデート、更新停止となったプラグインの入れ替え、WordPressコアのバージョンアップ、その他セキュリティ対応・・・—これらは書くことへの報酬とはまったく無関係なテクニカルな作業です。2022年から2025年にかけて、ぼくがWordPressにログインする理由はほぼこれだけでした。
くわえて、レンタルサーバのサービスアップデートに伴うサーバ移転対応、SSL証明書更新の失敗通知への対応など、ITインフラと呼ばれる部分のメンテナンスも頻度は少なけれど手間はかかっていました。
要するに、管理コストだけが積み上がっていく。そのあいだに記事は一本も増えない。WordPressやサーバは情報発信の基盤ではなく、メンテナンスの手間を発生させる負債になっていました。
なぜ今、移行しようと思ったのか
アーカイブサイトとして残すだけなら、わざわざ静的サイトジェネレーターに移行する必要はありません。Staticなコンテンツだけどこかにホストすればよい話です。
でも、あえて静的サイトジェネレーターを選んだ理由は、仕事術ブログを再開するためでした。
「AI × 仕事」は書けるし、書きたい
「一般論の仕事術はコモディティ化した」という認識は今も変わっていません。ただ、AIを使った新しい働き方・価値の出し方については話が別です。
AIとどう組み合わせるか、どこに人間の判断を残すか、チームのレバレッジをどう効かせるか。これらはぼく自身が日々本業で実験している固有の体験です。AIに聞いても出てきません。
また、AIは課題設定の仕方や問いの立て方、AIが動く環境の設計が勝負。組織論や部下育成などこれまで積み重ねてきた仕事術と非常に相性が良いです。
テストマーケとして、本業でAI活用系の講師を担当したり、naenote.netにいくつか投稿してみた結果、情報発信自体に価値がある領域である以上に「これは自分の学びになる」と手応えを感じたのです。
書く動機が戻ってきました。
そのため、AIネイティブな軽い基盤が必要だった
一方で、本業の立場的に仕事は多忙。執筆に取れる時間は限られています。管理コストが重いプラットフォームを使い続ける理由はありません。
そもそも、AI×仕事術の記事はテキスト中心です。複雑なレイアウトも、豊富な装飾も要りません。WordPressはその用途には過剰です。データベース、PHPの実行環境、プラグインのエコシステム。これらすべてが、テキストを書くという目的に対して重すぎるのです。
よって、ぼくが必要としたのは、AIによる執筆支援を前提とした、軽い執筆基盤でした。
AIネイティブなMarkdownで書いて、gitにpushすれば公開される。それだけで十分なのです。
Hugo + Cloudflareを選んだ理由
乗り換え先はいくつか候補がありましたが、Hugo + Cloudflare Pagesの組み合わせに決めました。
Cloudflareで完結できるお得感
Cloudflare Pagesを選んだ理由は、GitHubへのpushだけでビルド・デプロイが自動化されることです。ローカルでビルドしてFTPでアップロード、という手順が一切不要になります。
さらに、Pages・R2・Workersと、個人ブログの運用に必要なものがほぼ無料枠でまかなえます。レンタルサーバー代が毎月かかっていた旧環境と比べると、運用コストはほぼゼロになりました。
もともとCloudFlareのCDNを利用しており操作に慣れていた点も背中を押しました。
ビルド速度とCloudFlareとの相性でHugo一択
静的サイトジェネレーターを選ぶ上でビルド速度を最重要項目としました。書いて→ビルドして→確認→直す。この周回が遅いと致命的なストレスになるためです。Hugoはこの点でトップクラスで、記事151本でもビルドは数秒で完了します。
またCloudFlare PagesとWorkerはHugoがネイティブで組み込まれている点も決め手の一つとなりました。GitHubリポジトリのmainブランチを本番・それ以外を非本番とするなどの使い分けが初手から設定済だったり、ビルドもデプロイもDNSもCDNもすべてCloudFlare内で完結します。
Hugo自体も開発が活発、かつテーマも豊富でアップデートが活発で、長く使えそうな点も加点要素でした。ただ、静的サイトジェネレーターなので、もし将来Depreciationされても最悪バージョン固定したバイナリをコンテナに置いてビルドすれば良い、と割り切ることも可能。コミュニティや開発の活発度は、ビルド速度やCloudFlareとの相性よりも優先度は低かったです。
Claude Codeを使って2日で151本を移行
移行作業はClaude Codeとの二人三脚。
基本はClaude Codeに任せましたが、せっかく新しい技術要素を触るのでいろいろ解説をさせて自分の理解を進めつつ、Claude Codeに任せると時間がかかりそうな部分は自分で手を動かす、という分担としました。
2日べったり作業していたわけではなく、実作業時間は自分の理解を深める時間を含めて8時間くらいです。
Day1（2026-05-04）
準備の日です。
Claude Codeと移行要件・環境要件・運用要件を壁打ちしたのち、移行ドキュメント4ファイル・1,102行を作成。技術構成図・移行方針・手順書・テスト方針・リポジトリ構成案など、全体設計を固めました。
装飾用のブロックやショートコードの取扱、問い合わせフォームやコメントの移行要否など、機能要件もここで詰めきりました。
といっても、Claude Codeが実ドキュメントを作り、ぼくは家族と遊びながらワガママ言ってただけです。
Day2（2026-05-05）
実行の日です。
WordPressから記事をエクスポートしてMarkdownへ変換、173ファイル・25,531行の追加という初の大規模データ移行コミットからスタート。
GitHubに乗った記事151本に対して、Claude Codeが設計実装したPythonベースの変換スクリプト5ファイル（fix_content.py・fix_front_matter.py・collect_images.py・apply_r2_urls.pyなど）を生成。Claude Codeが準備した356行のテストコードに基づきClaude Codeが実行・評価・修正させていきます。
その様子の眺めながら、ぼくはひたすらCloudFlareの管理コンソールの設定作業や、R2バケットへの画像ファイルのアップロード、Markdownへ自動変換できなかったエッジケースの微調整と更新をしていきました。（CloudFlareは他ブログも使っいる本番環境なのでさすがにClaude Codeに任せられなかった）。
実際にサイトをビルドしてみるとWordPressとは違うところがたくさんあるもので、たとえばWordPressとHugoでカテゴリとタグの設計思想が違うのでカテゴリを再設計したり、階層型のパンくずリストを出すパーツを実装したり、リッチスニペット向けのJSON-LDをイチから実装したり、いろいろギャップを埋める開発が発生しました。これらに対して対応方針や要件を決め、Claude Codeに設計・実装してもらい、詰まったときは判断を入れていきます。
その他にも細かい技術的な突っかかりポイントはたくさんあったんですが、自身の技術力でクサいところがわかったもの以外はClaude Codeに「エラーログから原因分析して直して。判断が必要な部分があったら聞いて」と定型文を送り続ける形で、Claude Codeをぶん回していました。
たぶんCloud Codeがなかったら1週間以上はかかっていたと思います。
移行して変わったこと
移行してすぐですが、現時点での評価を書きます。
AIをUIとした執筆は本当に楽
AIネイティブな記事執筆フローを作ってあるので、執筆がとても気軽です。Claude Codeと壁打ちさえしていれば半自動的に執筆な進み記事ができあがり、「go」と言えば公開される仕組みを活用しています。
具体的には、運営用のGitHubリポジトリに「AI編集部」を仕込んでありまして、それを読み込んだClaude Codeに話しかける感じです。それだけで、記事ネタの壁打ち、競合調査、SEO/AIOレビュー、マーケターレビュー、記事のポジショニング定義、不足している一次情報をぼく自身から引き出すインタビューの実行、それらを受けたぼくの思考回路や書きっぷりでの記事執筆、レビューとFB反映、内部リンク構築、フロントマターの設定まで、すべて完結します。この記事もその仕組みで書いています。
WordPressの管理画面を開かずに済む、という事実だけで精神的な負荷がまったく違います。AIが新しいUIになっている感じです。
ただし画像が絡むと話は別
ただ、画像ありきの記事にはHugoは向きません。少なくとも今のワークフローでは。
今回の技術構成は、画像ファイルはCloudflare R2に置くことにしています。理由は画像までGitHubリポジトリに置くとリポジトリが肥大化してしまうためです。
その構成だと、記事に画像を挿入する手順は「R2に手動アップロード→パーマリンクを取得→MarkdownのイメージタグにURLを挿入」となります。この作業をClaude Codeにやらせるのは少し骨が折れます。下手するとトークンを大量消費するリスクもあります。
ガジェットレビューのように写真が多い記事を作るなら、WordPressの方が楽です。画像まわりの問題が解決しない限り、このサイト（naenote.net）はWordPressのまま維持することになるでしょう。
こういう人に移行を勧める・勧めない
移行後の実感をもとに、判断基準を示します。
移行を勧める人
- テキスト中心の記事（技術ブログ・日記・オピニオン）を書いている
- プラグイン更新やセキュリティ対応が面倒になってきた
- Markdownに抵抗がなく、gitの基本操作がわかる（またはAIに任せられる）
- VPSやレンタルサーバーの費用を削減したい
移行を勧めない人
- ガジェットレビューなど、画像が多い記事を中心に書いている
- WordPress管理画面での執筆フローが完成していて快適
- 動的機能（会員機能・決済・複雑なフォーム）が必要
- Markdownを新たに覚えるコストを払いたくない
まとめ
WordPressからHugoへの移行は、「書く動機が戻ってきたタイミング」と「AIネイティブな軽い基盤が必要なテーマ」が重なった結果です。WordPressが悪いわけではなく、自分の要件が変わったのです。
移行作業はClaude Codeがなければもっと長期に及んでいたと思います。本業でもClaude Codeを本格利用していたこともあり、2日で終えることができました。記事151本のMarkdown変換からカテゴリ再設計まで含めて、ぼくが自分の手で書いたコードはゼロです。AIを使うと移行もこんなに楽なんですね。
とはいえ、「AIがあれば誰でも簡単」という話ではありません。静的サイトジェネレーターという概念、Hugoのテンプレート構文、Cloudflareの設定、GitHubの操作、それらの技術的な依存関係と影響。これらを理解した上で、またはAIに解説させながら理解を進めたうえで、AIの嘘を見抜き、適切な指示を出す必要があります。
ハードルは低くないですが、ハードルを超えることを楽しめる、テキスト中心のブログで管理コストを下げたい、という方は、Hugo + Cloudflareの組み合わせは選択肢に入れてみてはいかがでしょうか。
ここまで読んでいただきありがとうございました。
コメント