メインコンテンツへスキップ
AI初心者2/20/2026, 10:24:25 AM

my-blogを立ち上げた理由: 書く前後で止まらない運用を作るため

目次(10件)

Reference only: do not publish this file. Canonical publish source is 2026-02-20__why-i-started-my-blog__note.md (slug: why-i-started-my-blog).

my-blogを立ち上げた理由: 書く前後で止まらない運用を作るため

結論から書くと、私がmy-blogを立ち上げた一番の理由は、本文より前後の作業で止まるのがしんどかったからです。
書くこと自体はできるのに、下書き管理、公開前確認、更新差分の確認で毎回つまずいていました。
この「止まり方」を減らすために、運用の流れそのものを作り直しました。

立ち上げ前に感じていたこと

当時の感覚は、次の3つでした。

  1. 書き始める前に疲れる
    どこに原稿を置くか、どれが最新版かを毎回判断して、着手前に消耗していました。

  2. 公開判断が怖い
    draft で確認したつもりでも、同一slugの更新反映に確信が持てず、公開ボタンを押すのが重かったです。

  3. 失敗が資産にならない
    詰まった理由を記録しても、次回の冒頭で再利用できる形にできず、同じミスを繰り返していました。

noteでは解消しきれなかったこと(穏やか比較)

noteは「書くこと」と「読まれること」に強い場所だと思っています。
ただ、私が欲しかったのは「運用を固定して再現する土台」でした。

  • 原稿を1か所に集約する
  • draft -> 表示確認 -> public を固定する
  • 失敗ログを次回の執筆に戻す

この3点を運用ルールとして回したかったので、用途差としてmy-blogを選びました。

noteや他ブログで困った具体例(3ケース)

ケース1

  • 状況: 記事の下書きをChatGPTで作ってから、noteへ転記して公開準備していた時。
  • 困りごと: 書く場所がnote単体で完結せず、転記工程が毎回発生した。
  • 当時の影響: 1本あたり約15-30分の追加作業が増え、週2本運用で詰まりやすかった。
  • my-blogでの解消: 下書き作成先を blog-brain/inbox/processing に固定し、転記ではなく同じ原稿をそのまま投稿運用へ接続した。
  • 再発防止ルール: 原稿は1ファイル1正本で管理し、別媒体への手動転記を作業フローから外す。

ケース2

  • 状況: ChatGPTの別チャットに切り替えて、同じテーマの記事を継続執筆していた時。
  • 困りごと: 文体・論点・前提がチャットごとにずれて、内容差分が増えた。
  • 当時の影響: 1本あたり2-3回の再編集が必要になり、整合調整で約20-40分かかることがあった。
  • my-blogでの解消: 記事の前提を見出し骨子と正本ファイルに固定し、同一slug更新で差分確認を一本化した。
  • 再発防止ルール: 新規チャット開始前に既存骨子を貼り、対象読者・課題・結論の3点を毎回固定する。

ケース3

  • 状況: 記事を書き続けた後に、関連記事をまとめ記事(ハブ)として再構成したい時。
  • 困りごと: 既存記事の要点抽出と導線整理が手作業になり、まとめ化の負荷が高かった。
  • 当時の影響: まとめ記事1本に60-120分かかり、個別記事の公開優先で後回しになった。
  • my-blogでの解消: 記事構成と失敗ログの記録フォーマットを統一し、まとめ記事へ流用できる素材を先に残す運用へ変えた。
  • 再発防止ルール: 各記事に「困った具体例」「失敗例と回避」を固定し、週次でハブ化候補を1回抽出する。

困りごとは他にもありましたが、個別対処を続けるより、ブログサイトそのものを運用基盤として持つ方が再発防止に効くと判断しました。

my-blogで固定した運用

実際には、次の流れを固定しました。

  1. 原稿は blog-brain/inbox/processing に集約する
  2. frontmatter(title, slug, category, summary)を必須にする
  3. node scripts/md-to-supabase.js --file <path> --status draft で下書き登録する
  4. /admin/posts/posts/<slug> の2点で表示確認する
  5. 問題なければ同一slugで public へ切り替える

手順を固定してからは、迷いの種類がかなり減りました。

実際に変わったこと

2/20の入口記事作成では、AIあり実測で約55分、AIなし想定で約95分でした。
短縮できたのは本文そのものより、骨子作成と言い換え整理、確認手順の固定です。
感覚としては「速く書けた」より「怖さが減って継続しやすくなった」が大きい変化でした。

それでも人間がやること

運用を整えても、最後は人が決める部分が残ります。

  • 読者に何を持ち帰ってほしいかを決める
  • 比較を書くときに相手を下げない
  • 失敗を隠さず、次回に使える形で残す

この3つはテンプレ化しつつ、毎回手動で確認しています。

まとめ

my-blogを立ち上げた気持ちは、派手な挑戦というより、毎回止まる摩擦を減らしたいという実務的な動機でした。
noteとmy-blogは対立ではなく用途差です。
私にとってmy-blogは、書く前後の不安を小さくして、継続を現実にするための土台です。