my-blogを書き出した理由: AI初心者でも回せる運用にした話

フック

結論として、私は記事本文より前後のバックグラウンド作業を減らすためにmy-blogを選びました。
下書き管理、公開反映、確認導線、再利用ルールを一つにまとめるのが目的です。
この記事では、「書く前後で止まる」AI初心者向けに体験と再現手順を残します。

なぜmy-blogを作ったか（背景）

最初に困っていたのは、本文より周辺作業でした。
どこに下書きを置くか、どれが最新版か、公開前に何を確認するか。
この管理が毎回バラバラで、書くたびに初期化されていました。
そこでmy-blogでは、blog-brain/inbox/processing 集約、md-to-supabase 反映、/admin/posts と /posts/<slug> 確認の流れを固定しました。
「作業順を固定して迷いを減らす」ことが立ち上げ理由です。

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

noteは、書くことと読むことに強いサービスです。
一方で私の課題は、運用自動化と検証ログの蓄積でした。
同一slug更新確認、draft/public 管理、確認観点のテンプレ化が必要でした。
これは良し悪しではなく目的の違いです。
私には「周辺作業を仕組み化できる土台」が必要で、my-blogを選びました。

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

ケース1

• 状況: 週2本ペースで記事を書き、公開前確認までを同日に終わらせたい時。
• 困りごと: 下書きの最新版がすぐ分からず、同じ内容を2回整形してしまった。
• 当時の影響: 1本あたり約20分の手戻りが発生し、公開が翌日にずれた。
• my-blogでの解消: blog-brain/inbox/processing に原稿を1か所集約し、ファイル名規則で版管理を固定した。
• 再発防止ルール: 下書きは必ず同フォルダで作成し、本文修正前に対象ファイル名を先に確定する。

ケース2

• 状況: 同じ記事を更新しながら draft で確認し、問題なければ public に切り替えたい時。
• 困りごと: 更新差分が意図どおり反映されたかを確認しづらく、公開判断に迷った。
• 当時の影響: 確認作業を2回やり直し、約15分の判断遅延が出た。
• my-blogでの解消: md-to-supabase を同一slug運用に固定し、/admin/posts と /posts/<slug> の2点確認を手順化した。
• 再発防止ルール: draft -> 表示確認 -> public の順序を崩さない。確認URLも毎回ログに残す。

ケース3

• 状況: 公開後に「何が失敗だったか」を次の記事に活かしたい時。
• 困りごと: 失敗の記録が散らばり、次回に再利用できる形で残せなかった。
• 当時の影響: 同じ詰まりを週内に2回繰り返し、合計30分以上のロスが出た。
• my-blogでの解消: 日記に 失敗例と回避 を固定項目として残し、次記事の骨子に再利用した。
• 再発防止ルール: 各記事で「失敗1件 + 回避策1件」を必ず記録し、次回の冒頭で参照する。

対象読者

• AI初心者で、記事前後の作業に時間を取られている人
• 書くネタはあるのに、公開手順が曖昧で止まる人
• 実践ログを資産化して仕事につなげたい人

今日の課題（体験）

1本の記事を「公開可能な状態」まで運ぶ摩擦を減らすことです。
下書き作成から確認までを再現手順として固定し、次回も同じ順番で回せる状態を目指しました。

Agentに渡した入力

1. 「この日記ログから入口記事の骨子を 体験 -> 再現手順 で作って。詰まりポイント3つを入れて。」
2. 「本文を実践ログ調で整えて。note比較は用途差として書いて。」

再現手順（コピペ可）

1. blog-brain/inbox/processing/2026-02-20__why-i-started-my-blog__note.md を作成する。
2. 見出しを固定順で配置する（フック、背景、対象読者、手順、失敗、結果、次の1歩）。
3. Agentに「体験 -> 再現手順」構成で本文生成を依頼し、一次稿を作る。
4. 手動で「初心者が詰まる点3つ」と「失敗例と回避」を追記する。
5. 時間比較を入れる（AIあり実測 / 非AI想定）。
6. 表現を整えたら node scripts/md-to-supabase.js --file <path> --status draft で下書き登録する。
7. /admin/posts と /posts/<slug> で表示確認し、次回改善点を日記へ戻す。

初心者が詰まる点3つ

1. 何から書き始めるか決まらない。
   詰まる理由: 構成より本文を先に書こうとして迷子になる。
   回避策: 見出し骨子を先に固定し、各見出しを3行ずつ埋める。

2. AI出力が長くて実務に落ちない。
   詰まる理由: 指示が抽象的で、用途と読者が曖昧。
   回避策: 「対象読者」「課題」「出力形式」を先に指定する。

3. 公開前確認で漏れが出る。
   詰まる理由: 確認観点が毎回変わる。
   回避策: /admin/posts と /posts/<slug> の2点確認を固定する。

失敗例と回避

失敗例: 本文を先に完成させてから構成を整え、修正コストが増えました。
原因: 先に「読者の持ち帰り」を定義していなかったことです。
回避: 骨子固定 -> 読者課題 -> 本文の順へ変更しました。
再発防止として、毎回「見出し固定 -> 詰まり3つ -> 失敗と回避」でチェックします。

結果

今回の入口記事作成は、AIあり実測で約55分でした。
同等作業をAIなしで行う場合は約95分想定です。
差分は40分で、骨子作成と言い換え整理が短縮されました。
次回に使える手順が残り、単発作業ではなく資産化に変わりました。

次の1歩

1. この本文にfrontmatterを付けて draft 登録する。
2. 表示確認後に、初心者が詰まる点の表現をさらに短く調整する。
3. 次回記事でも同じ骨子を使い、再現性を検証する。

まとめ

私がmy-blogを始めた理由は、周辺作業の摩擦を減らすためです。
noteとmy-blogは対立ではなく用途差で使い分けるのが自然でした。
まず実践し、必要ならテンプレ、必要時に相談につなげる。
AI初心者でも継続しやすいです。