Bluesky に1日1本、Claude Code を試行錯誤する過程で得た学びを予約投稿するツールを作った。

動機はシンプル。 学びを書き残しておけば、同じところで詰まった人の役に立つかもしれない。続けるうちに、ブログを知ってもらえるかもしれない。自分の頭の整理にもなる。それ以上の意図はない。

ネタ7本は別セッションで仕上げてあった。コードを書くだけ、のはずだった。

結論：実装に入る前に、ネタ7本を全部書き直した。

きっかけは、社内で「短文SNS運用担当」というエージェントを新しく雇ったことだった。

ネタは、何が問題だったか

7本は「フック → 共感 → 結論 → 具体例 → 注意点」の同じ型で書かれていた。 冒頭に🌙の絵文字、ハッシュタグは全部 #ClaudeCode #生成AI で揃ってた。

私は最初、その型を全投稿に毎回当てはめる前提で進めようとした。 「短文SNSはこの構造が正解」と読んだ記憶があったから。

ところが採用した短文SNS担当（Claude Codeに専門役を演じさせるエージェント）の意見はこうだった。

毎回同じ型を当てはめるのは正解ではないです。

理由は4つ。

• 単調になる（飽きられる）
• ネタによっては型が邪魔（観察・問いなどは構造化すると冗長）
• AI臭が出る（テンプレ感は見抜かれる）
• 共感パートが連発すると胡散臭くなる

投稿タイプを先に判定する

担当の言うとおり、投稿にはタイプがある。タイプによって最適な構造が違う。

タイプ	構造
Tips・ノウハウ	フック → 結論 → 理由or具体
体験報告・失敗談	結果 → 経緯 → 学び
意見・主張	結論断定 → 反論先回り → 根拠
質問・問いかけ	1行で問い、本文なし
観察・ぼやき	1行のみ
告知	何が・誰に・どこで

7本見直したら、3本が体験報告型、3本がTips型、1本が意見型だった。 全部Tips型の構造で書かれてたから、体験談として読むと違和感、意見として読むと弱い。

書き直した。

推敲で出てきた文体ルール

7本を1本ずつ直していく過程で、新しい文体ルールが3つ確定した。

1. 冒頭絵文字はいらない

タイムラインの一等地（最初の1〜2文字）に🌙を置くのはもったいない。 時刻はBluesky側で勝手に表示される。情報量ゼロの絵文字でフックを潰すのは損。

2. ぼかし表現を重ねない

「やや遅め」はNG。「やや」も「〜め」もぼかし機能。重ねると冗長。 「遅め」か「やや遅い」のどちらか1個。

3. 生成AIへの指示は使役形で書く

「答えを並べて」じゃなく「答えを並べさせる」。 「自信のない部分は『推測です』と書いて」じゃなく「書かせる」。

私が主、AIが従。文体で関係性を示す。

投稿は不可逆。コードは何度でも書ける

実装に入る前に文面を全部確定させたのは、もう1つ理由がある。

Bluesky投稿は公開した瞬間、タイムラインに残る。削除しても「私が消した」記録は残る。 コードはバグがあれば直してデプロイし直せばいい。差分すら誰にも見えない。

不可逆なほうから順に確定する、が原則だった。

実装は1時間で終わった。 書き直しに数時間かかったが、ツール稼働後に「あの投稿恥ずかしい」とならない安心料と思えば安いほうだと思う。

学び

• 短文SNSは投稿タイプを先に判定する。型は固定しない
• 同じ型を全投稿に当てはめると、AI臭・単調・テンプレ感の三重苦になる
• ぼかし表現は重ねない（やや＋〜め はNG）
• 生成AIへの指示は使役形で書く（私が主、AIが従の関係を文体で示す）
• 冒頭絵文字は基本不要。一等地を装飾で潰さない
• 不可逆なものから先に確定する（投稿文＞コード）
• 「正解の型」は文脈で変わる。1つの型を盲信しない

実際には1日1本、夜21時に投稿していく。 7本消化したら自動で停止するようにした。ネタが切れるくらいなら投稿しないほうが、長く続く。