AIとペアプロで個人ブログメディアを立ち上げた話 — blog.b1ue.jp 制作日誌 #1
ビジネス

AIとペアプロで個人ブログメディアを立ち上げた話 — blog.b1ue.jp 制作日誌 #1

31記事・日英バイリンガル・Cloudflare Pages 運用のメディアを、AIと2人で立ち上げた1ヶ月。意思決定だけ自分がやり、手は全部AIに任せた経験のリアル。

KIYODO00
#個人開発#AI#Next.js#Cloudflare#制作日誌

このブログ自体について書く。blog.b1ue.jp は、AI とのペアプロで作った個人メディアだ。Next.js 16 + Tailwind v4 + MDX + Cloudflare Pages のいわゆる「2026年版モダン静的構成」を、丸ごとAIに任せて立ち上げた。自分は意思決定だけして、手は一切動かしていない。

このシリーズ「制作日誌」では、これまで AI と組んで作ってきた個人プロジェクト群について書く。第1回はその総元であるこのブログ自体の制作プロセス。やってみて分かった「2026年の個人開発の作法」をまとめる。

なぜ自前でメディアを作ったのか

note や Substack ではなく、なぜ独自ドメインで自前ホスティングか。理由は3つ。

  1. AdSense・Amazon アソシエイト・各種ASP を全部好きに貼れる — プラットフォーム手数料なし
  2. Cloudflare Pages なら個人レベルなら完全無料で運用できる — Functions + D1 + 帯域、全部フリープラン内に収まる
  3. そして何より、AI に書かせる前提なら note のリッチエディタはむしろ邪魔 — Markdown ベースで AI が直接ファイルを叩く方が圧倒的に速い

サイト構造を全部自前にすることで、**「AIが書いた MDX をそのまま git push すれば本番に反映される」**という最短経路が手に入る。これは note では絶対に作れない体験だ。

スタック選定 — AI に得意な土俵で戦わせる

最近のAIモデルは、Next.js App Router・Tailwind・MDX といった標準的でドキュメントが豊富なスタックが圧倒的に得意。逆に独自フレームワークや古いライブラリは弱い。

採用したスタック:

  • Next.js 16 (App Router, RSC, static export モード)
  • Tailwind v4 (@theme inline でデザイントークン管理)
  • MDX (gray-matter + next-mdx-remote/rsc + remark-gfm)
  • TypeScript 必須
  • Cloudflare Pages + D1(PV計測・コメント・ランキング用)
  • Wrangler CLI でデプロイ

意図的にこの組み合わせを選んだ理由は1つだけ。AIが一発で正解を出せる確率が一番高いから。Astro でも Eleventy でも作れるが、コードを書くのはAIなので「AIにとって書きやすい」を最優先した。

役割分担 — 自分は手を動かさない

これがこのプロジェクト最大の発見。

自分の仕事:

  • 「ガジェット・AI・サイエンスを独自視点で」というコンセプト決定
  • カテゴリ7つの定義
  • 「Gizmodo 風の暗めUIにしたい」というビジュアル方向性
  • 記事のトピック選定と編集方針
  • 「これは公開していい / これはぼかせ」の判断

AI の仕事(=Claude Code が全部やった):

  • ファイル/フォルダ構成の決定
  • TypeScript 型の定義
  • React コンポーネント全部
  • Tailwind クラスの組み合わせ
  • MDX レンダラ実装
  • 動的 OGP 生成(Next 16 ImageResponse
  • sitemap.xml / robots.txt / RSS feed
  • D1 スキーマと Pages Functions の API
  • A8.net / Amazon アソシエイトの広告コンポーネント
  • 全記事31本の本文執筆(指示に沿って)
  • Cloudflare Pages へのデプロイ(wrangler pages deploy

自分は、ターミナルすら触っていない。 全部「これやって」と日本語で言って、AI が自走した。

詰まったポイント — 2026年特有の罠

楽だった反面、現代特有の落とし穴も踏んだ。記しておく。

1. Next.js 16 + Tailwind v4 のフォント周り

Tailwind v4 の @theme inline は、フォント値をビルド時にユーティリティに焼き込む。つまり --font-headline のような CSS カスタムプロパティを実行時に上書きしても、font-headline クラスには反映されない。

ja/en でフォントを出し分けたかったので、結局 globals.css に [data-locale="en"] .font-headline { font-family: ... } 直書きで上書きする戦略になった。AI も最初は @theme の中で何とかしようとして詰まっていた。

2. Cloudflare Pages の Managed robots.txt

普通に robots.txt を書いて配信したら、Cloudflare が「AI Crawl Control の Managed robots.txt」機能で勝手に上書きして、GPTBot / ClaudeBot / PerplexityBot を Disallow に設定してきた。

これは AI 学習ブロックの善意の機能なんだけど、ブログを書いている自分側としては「ChatGPT が引用してくれる経路」を塞がれるとアウト。CF dashboard で Managed robots.txt を OFF にして自前 robots.txt を復活させた。

3. Next 16 static export の RSC prefetch

NEXT_OUTPUT=export で静的書き出しすると、__next.$d$locale....txt という RSC prefetch ファイルへの 404 リクエストが Lighthouse の console エラーに出る。動作には影響しないが、ベストプラクティススコアが落ちる。これは現状放置。

1ヶ月でやった作業量

数字で振り返ると、規模感が見える。

指標数字
記事本数31本(日本語 22 + 英語のみ 9)
カテゴリ7(ガジェット / AI / サイエンス / モビリティ / カルチャー / ビジネス / ライフ)
コンポーネント数約20
Pages Functions API6本(track / stats / ranking / comments / admin/dashboard ほか)
D1 テーブル5本(page_views / view_counts / comments / ad_creatives / ad_ctr_daily)
Lighthouse スコア (mobile)SEO 100 / A11y 100 / Agentic Browsing 100 / Best Practices 96
自分が書いたコード行数ほぼゼロ(こちらから書いたのは設定ファイル数行のみ)

これを 1ヶ月でやった。本業の片手間で。1日あたりの拘束は1〜2時間ぐらい。AIに「こうして」と言って、出力を眺めて、おかしければ「ここ違う」とフィードバックする、の繰り返し。

収益化の現実

メディアを作るからには稼ぐ前提で組んだ。現状の貼り付け済み広告:

  • Amazon アソシエイトb1ueblog-22、自作 <AmazonCard asin=...> コンポーネント)
  • A8.net(A8AdRotator で記事カテゴリと広告を自動マッチング)
  • AdSense(タグだけ仕込み済み、申請待ち)
  • バリューコマース / アクセストレード / afb(提携準備中)

審査前のいま時点で、PV はまだ自分テスト + 数人の知人レベル(73 PV / unique 10)。収益化はこれから。ただ「広告貼り付けの基盤を最初から組み込んでおく」は、後から付け足すより圧倒的にラク。

やってみて分かった「AI と作る」の本質

1ヶ月やって思ったこと。

1. AI は「決められない」、人間は「書けない」

意思決定は人間でしかできない。「このプロジェクトはやる価値あるか」「このカテゴリは要るか」「この色は寒色か暖色か」は AI には決まらない。一方で、決まった後に Tailwind の組み合わせ100通りから最適解を選ぶのは、AI が圧倒的に速い。役割は綺麗に分かれる。

2. 「全部AIで作りました」は AI への過小評価

実際には、自分が方向を決めて、AI が手を動かし、出てきたものを自分が評価して、修正指示を返す、という継続的な編集会議だった。「AIが全部やってくれる」じゃなくて、「AI と編集者の関係」に近い。

3. 詰まった時に一番効くのは、AI に状況を整理させること

謎のバグやデプロイ失敗にハマった時、自分で頭で考えるより「いま起きていることを整理して」とAIに投げる方が早い。AI は「事実の列挙」が極端に得意。整理してもらった後、人間が判断する。

次回予告

次回は 「MCP サーバーを自作した — k-chrome 編」。ブラウザ自動化MCPを自分で書いた理由と、既存プロファイルを利用した実装パターンを書く。Claude_in_Chrome(公式)で詰まる「金融サイトはブロック」「Google ログインが効かない」をどう回避したか。

まとめ

  • AI と作るときは「意思決定 = 人間 / 実装 = AI」の分担に振り切ると速い
  • スタックは「AI が一発で書ける土俵」を選ぶ(Next.js + Tailwind + MDX が現状最強クラス)
  • Cloudflare Pages + D1 で個人メディアは ほぼ無料で完全運用できる
  • AI には「書く」より「整理させる」方が高効率な場面が多い

このブログ自体が、その実証実験の場でもある。これからの記事で、もっと突っ込んだ話を書く。

コメント (0)

まだコメントはありません。最初の一言を残しませんか?