WordPress でもなく、Wix でもなく、note でもない。
S3 にファイルを cp するだけで、毎週月曜の朝に AI が記事を書いて公開してくれる。
そんな個人ブログの仕組みを作って運用しています。月のインフラ費は数百円〜数千円。広告は一切なし。今回はその設計思想と、運用してみて感じたことを書き残しておきます。
技術的な構成の詳細は別記事にまとめたので、ここではまず「なぜこれを作ったか」「何を捨てて何を取ったか」の話をします。
きっかけは「広告のないブログを安く持ちたい」だけだった
個人事業で情報発信したい人にとって、ブログ運営の選択肢は意外と限られます。
- WordPress — 自由度は高いが、サーバ代・プラグイン管理・脆弱性パッチが永遠についてくる
- Wix / Squarespace — 管理画面は楽だが、月額数千円かかるし、無料プランは広告が入る
- note / はてな — 書くだけなら最高だが、ドメインも体験も借り物
- 静的サイトジェネレータ(Hugo / Astro) — 高速で安いが、毎回ローカルでビルドして push する手間
教育・士業・医療みたいに「広告表示が信頼性に直結する」業種だと、無料プランの広告は致命的です。かといって自前で WordPress を運用するほどの時間はない。
そこで、「S3 にファイルを置くだけ、あとは AI が記事化して勝手に公開」 という運用にしたらどうだろう、と考えたのが出発点です。
設計の核は「捨てる」判断だった
このシステムを作るとき、いちばん時間を使ったのは何を実装するかではなく、何を実装しないかでした。
捨てたもの
- 管理画面 — いらない。
aws s3 cpで十分 - データベース — いらない。manifest.json を S3 に置けば事足りる
- ランタイムサーバ — いらない。CloudFront から静的 HTML を返すだけ
- ログイン機能 — いらない。書き手は自分一人
- コメント機能 — いらない。連絡したい人はメールで来る
- SNS 連携・OGP 自動生成・AMP・PWA — いらない。後から欲しくなったら足す ←一部足しました
- prev / next リンク — いらない(これは今も少し迷っている) ←結局実装しました
残したもの
- 広告ゼロのレイアウト
- GA4 と Microsoft Clarity の計測タグ(ヒートマップで読まれ方を見たい)
- カテゴリ分け(5 つに固定: tech / study / thought / life / creative)
- AI による記事生成(メモを置いたら整えてくれる)
- 月曜朝の自動公開(更新頻度の安定が SEO 的にも気持ち的にも効く)
たぶん多くの人は「足し算」で設計を考えるけど、僕は「引き算」から入りました。残ったものだけで何ができるかを考える方が、運用が続きます。
ワークフロー: 月曜の朝に勝手に記事が出る
実際の運用はこんな感じです。
1. ネタを思いついたら S3 に投げる
aws s3 cp ~/Obsidian/notes/claude-code-jissen.md \
s3://da-leca-blog/source/
Obsidian のメモでも、ChatGPT との会話ログでも、docx でも pdf でも、なんでも受け付けます。source/ というプレフィックスに置けば終わり。
複数ファイルをまとめて 1 記事にしたいときはフォルダごと放り込みます。
aws s3 sync ./my-article-folder/ \
s3://da-leca-blog/source/my-article-folder/
2. 翌朝 9:20、AI が下書きを作る
毎日 9:20 JST に Lambda が動き、source/ を見て、公開予定がスカスカなら次の月曜分の下書きを準備します。
ここで Bedrock の Claude が呼ばれて:
- 本文の整形(Sonnet が「ブログ編集者」として再構成)
- URL slug の生成(Haiku が英語 kebab-case を提案)
- カテゴリの判定(Haiku が 5 カテゴリから選ぶ)
を全部やります。
3. 月曜 6:00、自動で公開される
publish_lambda が起動して staging を本番にコピー、sitemap.xml を再生成、CloudFront を invalidate。完了したら成功通知メールが届きます。
僕がやることは「ネタを cp する」だけ。あとは寝てる間に終わっています。
「順序を制御したい」という人間の弱さに対応した
完全自動化にしたら、自分の意図が反映されなくて寂しくなりました。具体的には、「シリーズものは順番に公開してほしい」「この記事は他より先に出したい」というのが時々ある。
そこで、ファイル名の先頭に数字を付けると優先される仕組みを足しました。
source/
├── 1_intro.md ← 最初に出る
├── 2_setup.md ← 次に出る
├── 10_advanced.md ← その次
└── random-thought.md ← 数字なしはランダム順
これだけで「順番付きキュー」と「気分次第のランダムプール」が両立します。シリーズが終わったらまた数字なしの放牧運用に戻る。
完全自動と完全手動の間にある 「半自動」 のバランス、これが個人運用には合っている気がします。
コスト: 月 150 円〜2200 円で収まる見込み
設計上の試算はこんな感じです。
| 項目 | 月額目安 |
|---|---|
| Bedrock(記事 4 本分の生成) | $0.06 |
| Lambda | 無料枠内 |
| S3 ストレージ | $0.025 |
| CloudFront | $1〜10(トラフィック次第) |
| SES(通知メール) | 無料枠内 |
| 合計 | $1〜15 / 月 |
WordPress を中規模で回すと最低でも月 1,500〜3,000 円(レンタルサーバ + ドメイン + バックアップ)はかかるので、トラフィックが少ないうちは圧倒的に安い。
しかも、トラフィックが伸びても CloudFront の従量課金で線形に増えるだけです。プラン変更とかサーバ増強とかの離散的なジャンプがない。これが地味に精神衛生に良いです。
ベンダーロックインへの不安は、思ったほどない
「AWS にロックインされない?」とよく聞かれます。たしかに S3 と CloudFront と Bedrock に依存しています。でも、コンテンツ自体はすべて Markdown か HTML として S3 内に置いてあるので、引っ越しは aws s3 sync で別のホスティングにコピーするだけです。
- Cloudflare Pages に移す → ファイルコピー + DNS 切り替えで終わり
- Netlify に移す → 同上
- AI 部分を OpenAI に変える → Lambda のコードを 1 箇所差し替え
「インフラが AWS なだけで、資産は手元にある」という状態を保てているのが大事。データベースに記事を入れてしまうと、これができなくなります。
運用してみてわかったこと
良かったこと
- 書くハードルが下がった — 「ちゃんと記事にする」を AI に任せられるので、メモを投げるだけで済む
- 更新が止まらない — キューに数本入れておけば、しばらく放っておいても勝手に出続ける
- 広告がない清潔感 — 自分のサイトに広告がないと、人に紹介しやすい
イマイチだったこと
- prev / next リンクがないのが地味に不便 — これは追加予定 ←結局実装しました
- AI の出力にクセが残る — system prompt のチューニングで対処中
次の記事で、技術構成を全部書きます
ここまでが「思想と運用」の話でした。
次の記事では、これを実際にどう組んだか:
- なぜ S3 + CloudFront + Lambda の構成にしたか
- なぜ Bedrock を選んだか(API 直叩きではなく)
- なぜ DynamoDB ではなく manifest.json + S3 ListObjects で済ませたか
- セキュリティ境界をどう「CloudFront の Behavior 列挙」で確保したか
- 失敗からの復旧をどう idempotent にしたか
このあたりを書きます。技術選定で迷っている人に届くと嬉しい。
このブログ自体がこの仕組みで動いています。 記事のソースもこの仕組みに
cpで投入されました。