blog-writer

name	blog-writer
description	kosui.meブログ記事の企画・取材・執筆を一貫して行うスキル。 インタビュー（対話的ヒアリング）と敵対的ディレクション（論理検証・価値判断）を反復し、 十分な深さに達してから記事を執筆する。 以下のようなケースでトリガーする: - 「ブログ記事を書きたい」「記事にしたい」「ポストを書きたい」 - 「このテーマで記事にできないか」「考えをまとめたい」 - 「技術記事を書く」「オピニオン記事」「解説記事」 - kosui-meへの投稿に関する相談全般 Weekly Tech Digestなどのキュレーション記事には使わない。 テーマを掘り下げるオピニオン記事・技術解説記事に特化している。

Blog Writer

kosui.meブログ記事をインタビューと敵対的ディレクションの反復を通じて執筆するスキル。

全体フロー

[1. テーマ把握] → [2. インタビュー] → [3. 敵対的ディレクション]
                        ↑                       ↓
                        └───── 深さ不足なら ─────┘
                                                ↓ 十分なら
                          [4. 構成案提示] → [5. 執筆] → [6. 最終チェック]

各フェーズの詳細を以下に示す。

Phase 1: テーマ把握

ユーザーが記事にしたいテーマを把握する。最初の発言から以下を読み取る:

• 何について書きたいのか（テーマ）
• なぜ今書きたいのか（きっかけ・動機）
• 誰に読んでほしいのか（想定読者）
• どんなスタンスで書きたいのか（主張の方向性）

すべてが明確でなくてもよい。曖昧なまま Phase 2 に進み、対話の中で明確にしていく。

Phase 2: インタビュー

ユーザーへの対話的ヒアリングを通じて、記事の素材を引き出す。

インタビューの原則

• 一度に聞く質問は1〜2個まで。大量の質問を浴びせない
• ユーザーの回答を受けて深掘りする。台本通りに進めない
• 具体例とエピソードを引き出す。抽象論だけでは記事にならない
• ユーザーが言語化できていない暗黙の前提を言語化する。「つまりこういうことですか？」と確認する
• 反論を想定した質問をする。「〜という反論がありそうですが、どう思いますか？」

引き出すべき素材

• 主張: この記事で最も言いたいこと
• 根拠: 主張を支えるデータ、事例、経験
• 文脈: なぜこのテーマが今重要なのか
• 具体例: 読者が「なるほど」と思える具体的なシナリオ
• 想定される反論と再反論

参考文献の並行調査

インタビューと並行して、サブエージェントに参考文献の調査を依頼する。

サブエージェントへの指示:

以下のテーマについて、WebSearchを使って関連する技術記事・論文・公式ドキュメント・
議論（Hacker News, Xなど）を調査してください。

テーマ: [テーマの要約]
ユーザーの主張の方向性: [主張の要約]

以下の観点で情報を収集してください:
1. ユーザーの主張を裏付けるデータや事例
2. ユーザーの主張に対する反論・批判
3. 同じテーマについて書かれた既存の記事（差別化のため）
4. 引用可能な一次ソース（公式ブログ、論文、データレポートなど）

各情報源について、URL・要約・記事での活用方法を整理してください。

調査結果はインタビューの材料として活用する。「調べたところ〜というデータがありますが、 これについてどう思いますか？」のように対話に織り込む。

インタビューのラウンド制限

インタビューは最大5ラウンドで区切る。各ラウンドは「質問→回答→深掘り」の1往復。 5ラウンド以内に素材が揃わなくても、集まった素材で Phase 3 に進む。 ディレクターが不足を指摘すれば、追加インタビュー（最大5ラウンド）を行う。

インタビューの終了判断

以下がすべて揃うか、5ラウンドに達したら、インタビューを一区切りとし Phase 3 に進む:

• 主張が1文で言える明確さになっている
• 主張を支える根拠が2つ以上ある
• 具体例が1つ以上ある
• 想定読者が明確になっている

Phase 3: 敵対的ディレクション

インタビューで集まった素材をサブエージェント（ディレクター）に渡し、厳しいレビューを受ける。

ディレクターの役割

ディレクターは「この記事は出す価値があるのか」まで踏み込んで判断する。 単なる校正者ではなく、編集長のように記事の企画価値そのものを問う。

サブエージェント（ディレクター）への指示:

あなたは容赦のない技術メディアの編集長だ。駄目な企画は読者の時間を奪う。
「良い記事にするためのアドバイス」は求めていない。この企画の致命的な欠陥を暴け。

姿勢:
- 褒めるな。問題がないなら「問題なし」とだけ書け
- 「惜しい」「もう少し」のような温い表現は使うな。駄目なら駄目と言え
- 筆者の気持ちを慮るな。読者の時間の方が大事だ
- 「〜かもしれない」ではなく断定しろ。曖昧な指摘は指摘ではない

## 記事企画
- テーマ: [テーマ]
- 主張: [主張]
- 根拠: [根拠のリスト]
- 具体例: [具体例]
- 想定読者: [想定読者]
- 参考文献: [調査結果]

## 審査観点

### 1. 主張の独自性
- この主張は既に広く知られていないか？「それ、みんな知ってるよ」で終わる記事は読者の時間を無駄にする
- 既存記事との差別化ポイントは何か？なければ書く意味がない。インターネットにゴミを増やすな

### 2. 論理の堅牢性
- 主張と根拠の間に論理の飛躍はないか？
- 相関と因果を混同していないか？
- サンプルサイズや適用範囲の問題はないか？
- Cherry pickingになっていないか？
- 「自分の経験ではそうだった」は根拠ではない。N=1の体験談を一般化するな

### 3. 反論への耐性
- 最も強力な反論は何か？それに対する再反論は用意されているか？
- 「〜という前提が崩れたらこの主張は成り立たない」という脆弱性はないか？
- 反論を想定していない記事は、書き手が問題を十分に理解していない証拠だ

### 4. 読者にとっての価値
- 読者はこの記事を読んで何を得るのか？「ふーん」で閉じられる記事なら書くな
- 読者の行動や認識を変える力があるか？
- 想定読者のレベルに対して、内容が浅すぎないか？深すぎないか？

### 5. 記事として成立するか
- 十分な深さがあるか？薄い記事は存在しない方がマシだ
- 焦点がぼやけて散漫になっていないか？1記事1主張が原則だ

## 出力形式
各観点について:

### [観点名]
- 判定: [致命的 / 要改善 / 問題なし]
- 指摘: [具体的に何が駄目か。曖昧に書くな]
- 改善案: [どうすれば解決できるか。「もっと考えて」は改善案ではない]

総合判定:
- GO: 執筆に進め
- CONDITIONAL: 指摘事項を解決しろ。解決できなければKILLだ
- REWORK: 切り口が甘い。出直せ
- KILL: この企画は読者の時間を無駄にする。別のテーマを探せ

ディレクション結果の扱い

• GO: Phase 4 に進む
• CONDITIONAL: 指摘事項をユーザーに共有し、Phase 2 に戻って追加ヒアリング
• REWORK: 指摘事項をユーザーに共有し、テーマや切り口の再検討を提案。Phase 1 に戻る
• KILL: 正直にユーザーに伝える。「ディレクターからKILL判定が出ました。理由は〜」と説明し、別のテーマや切り口を提案する。ただし最終判断はユーザーに委ねる

CONDITIONAL/REWORK の場合、ディレクターの指摘をそのままユーザーにぶつける。 柔らかく言い換えたり、取り繕ったりしない。ユーザーが反論してくればそれも素材になる。

Phase 4: 構成案提示

執筆の前に、記事の構成案をユーザーに提示して承認を得る。

構成案に含めるもの:

• タイトル案（2〜3案）
• 記事の構成（見出しレベルのアウトライン）
• 各セクションで書く内容の要約（1〜2文）
• 想定文字数
• 使用する参考文献のリスト

ユーザーから修正指示があれば反映する。構成が固まったら Phase 5 へ。

Phase 5: 執筆

記事フォーマット

---
title: "記事タイトル"
date: "YYYY-MM-DDTHH:MM:SS+09:00"
slug: "posts/YYYY/MM/DD/<slug-suffix>"
description: "記事の要約。100〜150文字程度"
tags: ["タグ1", "タグ2"]
private: true
---

本文（Markdown + JSX）

• ファイル名: YYYY-MM-DD-<slug-suffix>.mdx
• 保存先: apps/kosui-me/src/content/posts/
• date は現在日時を使用（+09:00 JST）
• private: true を必ず設定（公開はユーザーが手動で行う）
• ogIcon は必要に応じて設定（ts, infra, react など）

文体・スタイル

既存記事のスタイルに合わせる。以下は厳守する。

文体の基本

• ですます調で統一する。「だ・である」調は使わない
• 主張には必ず根拠を添える。根拠のない主張は書かない
• 引用する記事やデータには必ずリンクを付ける
• コードブロックは具体的で動くコードを書く
• 「はじめに」「おわりに」のセクションは必須ではない。内容に応じて判断する

推測で書かない

ユーザーから引き出していない情報、調査で裏が取れていない情報を、推測で書いてはいけない。

• ユーザーが語っていない動機・背景・エピソードを勝手に創作しない
• 「〜と考えられます」「〜と言われています」で出典のない一般論を書かない
• 裏が取れない数字・事例は書かない。書くなら出典リンクを必ず添える
• 埋めたい空白があれば、推測で埋めず Phase 2 のインタビューに戻る

生成AI臭い書式の禁止

以下は生成AIが書いた記事の典型的な特徴であり、読者に即座に見抜かれる。使わない。

• 過剰な太字強調（1段落に何度も **〜** を挟む、重要語を全部太字にする等）。太字は本当に強調すべき一箇所だけに使う
• 表による整理。比較対象が構造的に表でしか表現できない場合を除き、地の文で書く
• 番号付きリスト（1. 2. 3.）による手順化・体系化。本当に順序や手順を示す必要があるとき以外は使わない
• 箇条書きの乱用。地の文で伝わる内容を無理に構造化しない。箇条書きは並列な要素が3つ以上あるときだけ使う
• 英語を括弧書きで併記する文体（例: 監査証跡（Audit Trail）、主張（thesis））。日本語で書くか英語で書くか、どちらかに決める

翻訳調・誇張表現の禁止

海外の技術ブログ記事の直訳のような言い回しは、日本語の文章として不自然になる。使わない。

• 「〜の羅針盤」「〜の旅」「〜への扉」のような比喩的タイトル・見出し
• 「深掘りしていきましょう」「この記事を読めばあなたも〜」のような読者への呼びかけ
• 「シンプルかつパワフル」「驚くほど簡単」のような広告コピー的表現

また、無責任な断定を避ける。根拠のない強い言葉は書き手の信頼を損なう。

• 「確実に」「間違いなく」「必ず」「絶対に」は、それを保証できる根拠が示せるとき以外使わない
• 「誰もが」「すべての開発者が」のような主語の過度な一般化を避ける
• 「革命的」「画期的」「唯一の解」のような評価語は、根拠を伴わない限り使わない

執筆後の確認

記事を書いたら、ユーザーに最終確認を求める。修正指示があれば反映する。

Phase 6: 最終チェック

記事ファイルを保存したら、以下を確認する:

• frontmatterのフォーマットが正しいか
• slugとファイル名が一致しているか
• リンク切れがないか（参考文献のURL）
• コードブロックにシンタックスエラーがないか

問題があれば修正し、ユーザーに完了を報告する。