ブログを会社化する設計

ブログを会社化する設計

82記事を見直したら、これまで作ったブログ設計が全部つながった

俺は、blog-sekkeiとは別に、ずみログというブログも運営している。40代の投資、家事、暮らしについて、自分で試したことを書いているブログである。blog-sekkeiで作ってきた記事DB、before、planned diff、GO...
ブログを会社化する設計

自動化しない仕事を先に決めた

AIで記事制作を仕組みにすると、できるだけ止めずに進めたくなる。本文を書き、レビューし、WordPressへ保存し、公開後の記録までつなげる。俺も、その区間はAIへまとめて任せてきた。ただし、前の記事「一度に全部直さない。1か所ずつGOを出...
ブログを会社化する設計

一度に全部直さない。1か所ずつGOを出す

AIへ頼む変更先に、同じ形のカードが4枚並んでいれば、一度に直せそうに見える。俺も、トップページの4枚へリンクを付けるとき、最初はまとめて変更しようとした。だが、未確認だったのはリンク先ではなかった。WordPressを通ったあとのHTML...
ブログを会社化する設計

変更する前にbeforeを残すようにした

AIに変更を頼んだあとで、どこが変わったのか説明できなくなることがある。でも、ほかの文章や設定まで触れていないかは、変更後だけを見ても分からない。俺も最初は、直った画面だけを見て終わりにしていた。表示が直っていれば、それでよいと思っていた。...
ブログを会社化する設計

終わったファイルは消さずにarchiveへ移す

記事を作る仕組みを続けていると、下書きは少しずつ残る。公開した原稿。置き換えた旧稿。明示的に不採用にした原稿。どれも消したくはない。でも、全部がdraftsに残ると、今から直す原稿まで探しにくくなる。俺が分けたかったのは、新しいファイルと古...
ブログを会社化する設計

正本を1つ決めたら、探す時間が減った

記事制作の仕組みを作ると、ファイルは少しずつ増える。記事ごとのカルテ。公開前の本文。シリーズの一覧。公開済み記事を確認するDB。どれも必要だから作った。ただ、同じことが二つの場所に書かれ始めると、次にどこを見ればよいか分からなくなる。俺が決...
ブログを会社化する設計

増えた仕組みを、全部は残さない

AIエージェントの運用で記事を1本回せるようになると、次は別のものが増え始める。止まる場所を書くルール。記事ごとのカルテ。下書き、レビュー、公開後の記録。ひとり編集長だけで始めたときより、できることは増えた。でも、増えたものを全部そのまま使...
ブログを会社化する設計

AIに別ブログを混ぜさせない。clientsフォルダで作業範囲を分けた

AIで複数ブログを運用し始めると、次にぶつかるのが「混ざる」という問題だった。俺は今、ブログを2つ運営している。ずみログと、このblog-sekkei。前回、AIエージェントの判断と実行を分けた話を書いた。今回はその続きで、作業範囲そのもの...
ブログを会社化する設計

実装エージェントを作った。AIに全部やらせず、担当を分ける

AIエージェントを使い始めると、次に迷うのは「どこまで実行させるか」だった。書かせるだけなら怖くない。でも、投稿・DB登録・CSS変更まで任せると、話が変わる。Claude Codeでブログ運営を仕組み化してきて、企画と判断を担うhensh...
ブログを会社化する設計

目次と内部リンクで、ブログを記事の集まりからサイトに変える

前回、投稿を仕組みにした。WordPressへの下書き保存までは自動、公開は俺が押す。それで一つ片づいた。でも記事が増えていくと、次に必要になったのは、内部リンクの設計だった。「見つけやすさ」が壊れ始めていた。記事が増えてきたら、次に壊れる...