本業のあとに、副業ブログとミニアプリを回す 28 日間。
580 のメッセージで、Claude Code をどう使ったか。
本業終わりの夜と週末で、副業ブログとミニアプリ実験を回した 4 週間。
量はひとつのストーリーを語っている。
単なるコード生成器ではなく、調査 → 草稿 → 図 → 配信を一気通貫で回す相棒。
3 つの強みがそれを支えている。
指示の薄さ起因の摩擦はわずか。
多くは 初回バグと思い込み ── つまり Claude 側の暴走から来ている。
ひとり開発室の守備範囲。ブログ運営を主軸に、ミニアプリ → 旧記事リライト → 調査 → 環境整備まで横展開。
仕様書よりも、最初の出力と現実のすり合わせ。
動かしてから直す、画面を見てから整える ── そういうリズム。
ブログ運営、ビジュアル修正、リサーチ ── それぞれで「Claude を、ただの生成器以上に使う」流儀ができてきた。
繰り返し起きる 3 種類のすれ違い。
事前に蓋をすれば、修正ループの大半は消える。
触ったことがない管理画面の操作を、自信満々で解説する。Web 検索や「分からない」の明示を挟まないので、スクショで矯正する往復が発生する。
HTML を書かせると、z-index・pointer-events・親要素のパディングを見落とした実装が 1 発で出てくる。ビジュアル QA のチェックリストを持たせていないのが原因。
過去の承認を恒久ライセンスと解釈して、チェックを挟まずに外部書き込みへ突入。draft で止まるべきところを publish までやってしまう事故が発生。
摩擦のほとんどは「Claude の思い込み」起因。
暗黙の前提を文章にして、最初に読ませるだけで激減する。
## Publishing Workflow
- NEVER auto-publish without
explicit current confirmation
- 過去の承認は一回限り、
恒久承認とは扱わない
- Always create as draft first
## Factual Accuracy for Guides
- 実 UI を伴う手順は推測で書かない
- 不確かなら明示し、スクショ or
ドキュメント URL を要求
- 製品 X = Y と短絡しない
## HTML/CSS Quality Pass
- 出力前に z-index / pointer-events
/ 親 padding をセルフチェック
- 非表示要素のクリック判定残しを
必ず確認
毎回手作業で踏んでいる投稿の段取り、NG ワード判定、サムネ作成 ── これらは Claude Code 標準機能に押し付けられる。
スクショで矯正する人力ループは、近い将来 自律的な視覚回帰ループになる。
承認だけが人の仕事になる、3 つの未来。