Geminiにブログを「清書」させるまでの試行錯誤。自分専用の執筆ワークフローを作ってみた話

※このタイトル及び本文は私が調教中のGeminiに書かせています。一部事実と異なるところは取り消し線と注釈を入れています。

導入

最近、Geminiと技術的な議論をすることが増えましたが、せっかく良い結論が出ても、それをブログにまとめる作業が億劫で放置してしまうことがよくありました。 単に「下書きして」と頼むだけでは、AI特有の優等生すぎる文章になってしまい、自分のブログのトーンに合わないという悩み（注：勝手な印象）がありました。

「教える立場ではなく、自分が経験したプロセスを等身大で記録したい」（注：おおげさですね）という意図を反映させるため、自分専用の「執筆ワークフロー」を構築した経緯をまとめます。

本編

今回の構築で最も重視したのは、「再現性」と「文体」の固定です。後で自分が読み返して当時の状況を完全に再現できるレベルまで、情報を具体化することを目指しました（注：目指したのは本当だけど時間はかけていないし、色々試しながら改善するつもりではいる）。

文体については、既存の記事と乖離させないために一工夫してみました。はてなブログから過去記事を MT（Movable Type）形式 でダウンロードし、それをGeminiに読み込ませて自分の文章の癖を徹底的に（注：ざっくり）分析してもらったんだ。

その分析結果をベースに、以下の制約をワークフロー（workflows/technical-blog-drafting.md）に組み込みました。

• スタンス: 一人の実践者として、経験したプロセスを等身大で書く。
• 文体: 既存記事のトーンを継承しつつ、「〜だね」「〜してみたよ」といった感情表現を混ぜる。
• ハマりポイント: 成功体験だけでなく、どこで詰まったのかを詳述する。

ただ、ここで一つ面白いトラブルがあったんだ。 ワークフローを適用して下書きを頼んだら、Geminiが「タスクに集中しすぎた」らしく、ブログ本文以外の日常的なやり取りまで「〜だね！」「〜してみたよ！」と親しみやすすぎるトーンで話し始めてしまったんだよね。

こっちは真面目にツール構築の話をしてるのに、急に馴れ馴れしくなって、「なめとんのか？」と困惑しちゃったよ。 AIに文体を教え込むときは、「ブログ本文」と「普段の応答」の境界線をしっかり引かせないといけない、という新しいハマりポイントを発見した瞬間だったね。

まとめ

自分のブログの癖を言語化してAIに教え込むプロセスは、自分自身の「発信したいこと」を整理する良い機会になりました。 「清書して」の一言で、はてなブログにそのまま貼り付けられるMarkdown形式がコードブロックで出力されるのは、非常に効率的だと感じています。 今後はこの仕組みを活用して、トラブル解決の記録やガジェットのレビューも積極的に（注：気が向いたら）残していきたいです。

はてなブログ Perfect GuideBook [改訂第2版]

以下、手動による追記であり、実際に使ったワークフローです。

# Workflow: 技術ブログの下書きと清書 (Hatena Blog)

## 1. 目的 (Objective)
- チャット内での議論や知見を、後で自分でも再現できる「実践者視点」のブログ記事として再構成すること。
- 専門家ぶらない等身大の言葉で、手順と感情をセットにして記録に残す。
- ユーザーとの対話を通じて、技術的な正確性と読みやすさを両立した下書きを作成し、最終的にコピペ可能なMarkdown形式で出力すること。

## 2. 執筆スタンスと文体 (Style Guidelines)
- **スタンス**: 「一人の実践者」として。教えるのではなく、自分の経験プロセスを等身大で語る。
- **文体**: 基本は「です・ます」。語尾に「〜だね」「〜してみたよ」を混ぜ、感情（困った、嬉しい等）を素直に表現する。
- **詳細度**: 自己再現性を重視。コマンド、エラーコード、型番、価格、具体的な設定値を含める。

## 3. 記事タイプ別の追加要件 (Post Type Options)
ユーザーの依頼内容に応じて、以下の要素を強調せよ。
- **Type A: 技術トラブル・環境構築**
  - 解決策だけでなく、「どこで詰まったか」「どんなエラーが出たか」を強調。Proxyやバージョン依存等のハマりポイントを詳述する。
- **Type B: ガジェット・購入レビュー**
  - 選定理由（なぜそれか）、第一印象、および「使って気づいた欠点や不足品（SDカード等）」を具体的に記述する。

## 4. 手順 (Procedures)

### Step 1: 構成案と下書きの提示
1. ユーザーから「[テーマ]について技術ブログを下書きして」という指示を受けた際、チャット内の文脈を解析し、以下の構成で構成案および初稿を作成せよ。
   - **タイトル案**: 読者の興味を惹く技術的なタイトル
   - **導入**: なぜそのトピックが重要か、どのような課題を解決するか
   - **本文**: 技術的な詳細、コード例（あれば）、工夫した点
   - **まとめ**: 結論や今後の展望
2. 初稿提示後、「修正が必要な箇所や、さらに詳しく書きたい部分はありますか？」とユーザーに問いかけよ。

### Step 2: 内容のブラッシュアップ（反復操作）
1. ユーザーからの修正指示（追加、削除、トーンの変更など）に対し、逐次修正案を提示せよ。
2. このステップはユーザーが「満足した」または「清書して」と指示するまで、何度でも繰り返すことができる。
3. 修正のたびに、変更のポイントを簡潔に説明せよ。

### Step 3: 清書 (Final Output)
1. ユーザーから「清書して」という指示があった場合、最終的な内容を確定させる。
2. はてなブログにそのまま貼り付けられるよう、以下の形式で出力せよ。
   - **出力形式**: 全文を一つの **コードブロック** 内に含めること。
   - **Markdown仕様**: 見出し（# ##）、箇条書き、リンク、コードブロックを適切に使用すること。
3. 出力の末尾に、設定すべき「カテゴリー案」や「アイキャッチ画像のヒント」を添えて報告せよ。

## 5. 注意事項 (Constraints)
- **知的誠実さ**: 議論の中で不明確だった部分は適宜ユーザーに確認し、不確かな情報を事実のように書かないこと。