このブログ、昨日Claude CodeとGCPで2時間で構築したブログシステムなんです

昨日、お昼ころに思い立って、情報発信用の自社ブログを、WordPressも既製のブログサービスも使わずに立ち上げました。Claude CodeとGCPで、所要時間はだいたい2時間です。そして私は、開発者ではありません。

いま読んでいただいているこのサイトが、その成果物です。単なる記事投稿ツールではなく、読みやすさやSEOまで考えた作りになっているので、中身を全部お見せします。

Blogを読む人向けの機能

タグとおすすめ記事で、回遊しやすく

記事を保存すると、AIが本文を読んで関連タグを自動でつけます。タグはクリックでき、同じタグの記事一覧ページに飛べます。記事の下（デスクトップでは右側に固定表示）には「おすすめ記事」も並ぶので、気になった話題をたどって読み進められます。

表示は軽く、検索にも強く

画像はnext/imageで自動的に最適化して配信しています。記事ページにはパンくずリストと構造化データ（BreadcrumbList・BlogPosting）を仕込んであり、検索エンジンにページの構造が伝わりやすい状態です。sitemap.xml、OGP、Twitter Card、canonical URLにも対応しています。

お問い合わせは、スプレッドシート＋Slackで即キャッチ

フォームから送信された内容はGoogle Apps Script経由でスプレッドシートに自動記録され、同時にSlackへ通知が飛びます。見逃しません。

Blogを書く人向けの機能

書き心地は、普通のブログエディタと同じ

太字・下線・斜体・取り消し線・文字色、見出しH1〜H4、箇条書き、引用、リンク、画像挿入、YouTube／Vimeoの埋め込みまで一通り揃えています。ツールバーはスクロールに追従します。

HTMLを直接書きたい人にも対応

「HTMLで編集」モードがあり、ビジュアルエディタと相互に切り替えられます。ClaudeやGPTで作ったHTMLをそのまま貼って公開でき、HTMLファイルを丸ごとドラッグ＆ドロップで流し込むことも可能です。画像をドラッグ＆ドロップすると、同名ファイルのsrcを自動で置き換えます。

書いている途中で消える心配なし

入力が止まって数秒後に、バックグラウンドで自動保存されます。ブラウザを閉じてしまっても大丈夫です。公開前には「プレビュー」で実際の見た目を確認できます。

抜粋とSEO設定は、AIにお任せ

記事の抜粋やメタディスクリプションを書き忘れても、保存時にAIが本文から生成します。自分で書いたものがあれば、そちらを優先します。「ここは後で直す」といった執筆中のメモが要約に混ざらないよう、プロンプト側で制御しています。

運用まわり

• 投稿者ごとに個別のログインアカウントを発行しています（発行はCLIから）

• 全員が全記事を編集・削除できる仕様です。少人数運用なので、権限分離はあえて入れていません

• robots.txtはALLOW_INDEXING環境変数で公開／非公開を切り替えられます。構築中に検索エンジンへ拾われる事故を、フラグひとつで防ぐためです

• DBパスワード、セッションシークレット、Claude APIキーなどはGoogle Secret Managerで管理しています

• 組織のドメイン制限共有ポリシーが効いているため、GCSバケットとCloud Runの公開設定には、プロジェクト単位で組織ポリシーの例外を適用しました

ここまでの機能表を従来の見積もりで眺めると、数人日から数週間のスコープです。それが昼から夕方までに収まりました。

どうでしょう？ブログで欲しい機能はほとんど入っています。

なぜ2時間で作れたのか

速さの理由は、コードが自動で書かれることそのものではありません。「こうしたい」が明確になっていれば、日本語で指示を出すだけで、数分後には本番に反映されていることです。

たとえば、この2つ。

「HTMLを直接編集できるモードが欲しい。ClaudeでHTMLを書いて、そのまま貼りたいから」

「画像はドラッグ＆ドロップで置けるようにして。同名ファイルのsrcは自動で置き換えてほしい」

これをそのまま日本語で伝えるだけで、機能ができあがります。従来なら、ここから要件定義書を書き、画面設計に落とし、見積もりを取り、実装を依頼し、レビューして差し戻す——という工程が挟まっていました。早くても数日、間に会社が挟まれば数週間のリードタイムです。

いまはその場で言って、その場で直り、そのまま本番に出せます。「使ってみて違和感があった箇所を、使いながら直す」ができる。これが実際に効きました。仕様を決め切ってから作るのではなく、触りながら決めていけるので、そもそも要件定義という工程が要らなくなります。

エンジニアを介さずに完結します

ここが大きいところです。上の作業に、エンジニアは1人も入っていません。自分たちの「こうしたい」という要求仕様を、自分たちの言葉のまま、その場で実現して即本番適用できるということです。

これまで、業務を分かっている人と、それを実装できる人は別人でした。だから間に翻訳工程が必要で、そこで時間と精度が失われていました。業務を分かっている人が、そのまま作れる。翻訳工程が消えるので、速いのは当然です。

逆に言えば、「こうしたい」が言えない人のところに、2時間は訪れません。今日ずっと使っていた能力は、技術力ではなく「何が欲しいのかを、判断込みで具体的に言い切る力」でした。実際、いちばん時間をかけたのも技術ではなく「全員が全記事を編集・削除できてよいか」という運用の判断です。少人数だから権限分離は入れない、と決めました。決めれば実装は一瞬ですが、決めなければ永遠に終わりません。

既製CMSを選ぶ理由が、ひとつ消えました

「自作は危ないから既製品を使うべき」という前提も、揺らいでいます。

Patchstackの「State of WordPress Security in 2025」によれば、2024年にWordPressエコシステムで報告された新規脆弱性は7,966件で前年比34%増。うち96%はプラグイン由来、4%がテーマ由来で、コア本体で見つかったのは7件だけでした。WordPress本体ではなく、その上に載せる無数のサードパーティ製部品が攻撃面になっているということです。さらにWordfenceの年次レポートでは、2024年に開示された脆弱性のおよそ35%が2025年時点でも未修正だと指摘されています。

今回のブログには、他人が書いたプラグインが1つも入っていません。攻撃面が小さく、どこに何があるかを自分が全部把握できています。もちろん自作すれば自動的に安全になるわけではなく、責任の所在が自分に移るだけです。ただ、「更新を追い続けないと危ない資産」を抱え込まない選択肢が、現実的なコストで取れるようになりました。

もうひとつ大きいのが、制約から解放されることです。HTML直接編集モードも、画像のsrc自動置換も、私たちの運用都合から生まれた機能です。既製サービスなら「プラグインを探す」か「諦める」かの二択でした。いまは「自分たちの運用に合わせて作る」が最短ルートです。探して比較検討する時間より、作る時間のほうが短いのですから。

実際に詰まったのは、コードではなく組織ポリシーでした

唯一まともに時間を取られたのが、GCSバケットとCloud Runの公開設定です。組織側のドメイン制限共有ポリシーが効いていて、そのままでは外部公開ができませんでした。

これはAIの限界ではなく、ガバナンス設計の話です。そして示唆的だと思っています。開発速度がここまで上がると、ボトルネックは実装能力から、権限・ポリシー・意思決定へ移動します。「作れないから進まない」ではなく「通らないから進まない」に変わるのです。企業のAI活用をご支援していて実感するのも、まさにこの点です。

でもこういう難しい話もClaudeCodeと対話すると丁寧に教えてくれます。
わからなかれば、画面キャプチャを貼り付ければ、丁寧にどうすればいいかを指示してくれます。

それでも既製サービスが向くケース

公平を期して書いておきます。次の場合は、いまでもWordPressやSaaSが合理的です。

• 更新する人が非エンジニアで、かつ人数が多い場合。慣れたUIとエコシステムの価値は大きいままです

• 会員課金やEC決済など、要件が複雑で事故ったときの損害が大きい領域

• 障害時に手を入れられる人が社内にいない場合。自作は運用責任とセットです

つまり「WordPressがもう古い」のではなく、小〜中規模の情報発信サイトを作るために既製CMSを選ぶ理由が消えた、という話です。

まとめ

このブログ自体が「AIと一緒に作る」を体現したプロジェクトで、皆さんの身近に感じられる事例ではないですかね。今日わかったことは3つです。

• 人間がやると数人日（数十万円）規模の機能セットが2時間で立ち上がります。実装コストは、もうボトルネックではありません。

• 代わりに、要件を具体的に言い切る力と、運用上の判断を下す力が、そのまま成果物の質になります

• 詰まる場所は技術ではなく、組織のポリシーや権限へ移っていきます