ブログ記事

購読前に試し読み

提供者が選んだ代表ファイル「CLAUDE.md」の中身です。購読前の参考としてご確認ください。

# Articles Project

全プロダクトを横断するマーケティング記事・コンテンツの管理プロジェクト。

## プロジェクト構成

```
Articles/
├── CLAUDE.md              # このファイル
├── context-profile.md     # 著者プロフィール（全記事共通）
└── topics/                # 全記事（テーマ別）
    ├── INDEX.md           # 全テーマの一覧（必ず最新に保つ）
    ├── stripe-connect/    # 1テーマ = 1フォルダ
    │   ├── zenn.md        # 媒体名がファイル名
    │   ├── note.md
    │   ├── x.md
    │   ├── lovai-platform.md
    │   └── interview.md
    ├── ai-translation/
    │   ├── zenn.md
    │   └── note.md
    └── ...
```

### ファイル命名規則
- フォルダ名: テーマを表すケバブケース（例: `stripe-connect`, `ai-translation`）
- ファイル名: 媒体名（`zenn.md`, `note.md`, `x.md`, `lovai-platform.md`）
- 連載: `zenn-part1.md`, `zenn-part2.md`
- 特殊バリエーション: `note-parody.md` のように媒体名にサフィックス

### INDEX.md の運用ルール
- 記事を新規作成・追加したら、**必ず** `topics/INDEX.md` を更新する
- 新テーマ追加時は、まずINDEXをgrepして既存テーマと重複がないか確認する
- INDEX.mdのテーマ名は自然言語で書く（フォルダ名だけでは後から探しにくいため）

## 記事作成ルール

### 必ず最初にやること
1. `context-profile.md` を読んでトーン・エピソード・肩書きの意味を確認
2. `topics/INDEX.md` を読んで既存テーマと重複がないか確認
3. プラットフォーム別のトーン・文体・長さを守る

### コンテンツ配信パイプライン
```
元ネタ（知見・体験）
  ├── zenn/     技術層向け（5,000〜8,000字）
  ├── note/     一般層向け（3,000〜4,000字）
  ├── lovai/    プロダクト投稿（1,000〜1,500字）
  └── x/        拡散・告知（3投稿スレッド）
```

1つの知見を4プラットフォームに最適化して展開する。
同じ内容でも、読者層に合わせてトーン・深さ・切り口を変える。

### プラットフォーム別ルール

| プラットフォーム | トーン | 文体 | 長さ目安 |
|---|---|---|---|
| Zenn | 技術的・教育的 | です/ます調、SQL付き | 5,000〜8,000字 |
| Note | ビジネス・本質論・思想 | です/ます調、考え方と体験談中心 | 3,000〜4,000字 |
| Lovai | 体験共有 | です/ます調、コンパクト | 1,000〜1,500字（3ブロック） |
| X | ライト・キャッチー | です/ます調ベースの口語 | 3投稿スレッド |

### 文体の最重要ルール（全プラットフォーム共通）
- **柔らかく、女性的な文体で書く。** 男性的な硬い文章にしない
- **断定的な書き方は絶対禁止。**「〜だ。」「〜である。」で言い切らず、「〜だと思う」「〜な気がする」「〜ではないだろうか」のように余白を残す
- 読者に語りかけるように書く。上から教えるのではなく、一緒に考える姿勢
- 感情や感覚を素直に言語化する（「正直、怖かった」「なんだかモヤモヤした」）
- 主張は強く持つが、表現は柔らかく包む。押し付けではなく共感で巻き込む

### Noteプラットフォーム固有ルール
- **ハッシュタグは必ず10個**
- 3,000〜4,000字
- 本題は「何をしたか」ではなく「なぜそう考えたか」「そこから何が見えたか」
- タイトルにバズ要素（衝撃・疑問・逆説）を必ず1つ入れる
- 画像プロンプトは一発生成形式で書く（Canva/Figma前提にしない）
- 画像内の文字はすべて日本語（英語テキスト禁止）

### コンテンツの品質基準（深津原則 + 全プラットフォーム共通）
noteのモデレーション基準に基づき、日本語・英語・全プラットフォーム共通で適用する。
「やること」と「やらないこと」の両面で設計する。

参照: https://note.com/fladdict/n/n5b78bb223b35

#### やること（全プラットフォーム共通）
- **一次情報を核にする** — 自分が体験・実装・検証したことを書く
- **意見と事実を区別する** — 「Stripeの手数料は3.6%」は事実、「この設計が良い」は意見
- **イシューが明確で自己完結** — 1記事で完結させる。「続きはXで」「詳しくはLINEで」はやらない
- **出典を追えるようにする** — 公式ドキュメント、コード、実際の画面を根拠にし、リンクを貼る
- **やり取りが生まれる書き方をする** — 読者が自分の経験と照らし合わせて考えたくなる問いかけや余白を残す
- **インターネットの知見の総和を増やす** — 読んだ人が1つでも新しいことを持ち帰れる記事にする

#### やらないこと（全プラットフォーム共通）
- 他人の記事の言い換え・要約だけの記事（自分の検証・意見がなければ価値ゼロ）
- 一次情報や検証がない「調べてみました」系
- 「〇〇な人はヤバい」「知らなきゃオワコン」「これを知らないと損」系の煽り構文
- 炎上目的・誰かを攻撃する記事
- 出典が追えない断定（「絶対」「確実に」）
- AIに丸投げして生成した記事をそのまま出す
- 過去にバズった他人のコンテンツの再生産・パクリ
- フェイク情報、疑似科学、根拠のない断定

#### エッセイ・思想系で特にやること（Note / Medium / X）
- **失敗談と学びを必ず含める** — 成功だけでなく「最初はこう間違えた」を入れる
- **感情と体温を入れる** — 「正直、怖かった」「ここは反省だが」など
- 体験 → 気づき → 考え方の変化、の構造で書く
- 公式ドキュメントの再構成ではなく、自分の視点と判断を主役にする

#### エッセイ・思想系で特にやらないこと（Note / Medium / X）
- 一般論だけで終わる記事（具体的な体験がないなら書かない）
- 感情ゼロの評論家スタイル（自分が当事者として語る）
- 他人の成功事例の紹介だけ（自分のケースを語る）

#### 技術チュートリアル系で特にやること（Zenn / Qiita / Dev.to / Hashnode）
- **実装が一次情報** — 自分のプロダクトで動いているコードをベースにする
- **公式ドキュメントの正確な引用** — APIの仕様、料金、制約は公式を根拠にし、リンクを貼る
- **ハマりポイントで一次性を出す** — 公式ドキュメントに書いていない実体験（エラー、設計ミス、パフォーマンス問題）を各セクションに入れる
- **コードの意図を説明する** — 「何をしているか」だけでなく「なぜこの設計にしたか」を書く

#### 技術チュートリアル系で特にやらないこと（Zenn / Qiita / Dev.to / Hashnode）
- 公式ドキュメントの翻訳・転記だけで終わる記事
- 自分で動かしていないコードを載せる
- ハマりポイントや設計判断の理由がない手順書（それは公式ドキュメントの劣化コピー）
- 検証せずに「〇〇がおすすめ」と書く

### 「AIっぽさ」を消すライティング原則

| AIの癖 | 対策 |
|---|---|
| 抽象的な一般論 | 数字・固有名詞・場面描写で映像化できるレベルまで具体化 |
| 単調な文体 | 短文と長文を意図的に混ぜる。体言止め、問いかけも使う |
| 感情表現ゼロ | 「正直」「驚いた」「悔しかった」など体温のある一言を要所に |
| 文脈の弱さ | 各セクション冒頭に「なぜこの話をするか」の1-2文 |
| 論理的すぎる | 「正直に書くと〜」「ここは反省なのですが〜」など余白を残す |
| 不自然な比喩 | 比喩は本当に効く場面だけ。無理に入れない |

#### プラットフォーム別の強弱
- **X（最大）:** 口語トーン、感情むき出し、短文連打。脱線・ユーモアも積極的に
- **Note（強）:** 具体性・感情・文脈を強めに。ストーリーテリング重視。口語は控えめ
- **Lovai（中）:** 体験共有なので具体性と感情は必須。コンパクトにまとめる
- **Zenn（控えめ）:** 具体性と文脈を重視。情報密度と正確性が最優先

### 共通禁止事項
- 「〜は非常に重要です」「〜が不可欠です」→ 具体的に何がどう変わるか書く
- 「まるで〇〇のように」→ 本当に効く場面以外では使わない
- 同じ文構造の3連続 → 2つ続いたら文体を変える
- 「いかがでしたでしょうか」系の定型結び → 絶対禁止
- 他社サービス名は出さない（悪い例として名指ししない）
- エピソードの使い回し禁止。同じ教訓を別の具体例・別の切り口で語る

### 関連記事リンク（全記事必須）
記事末尾に必ず関連記事セクションを設ける。SEOの内部リンク戦略として、記事が増えるほど重要になる。

**3つの関連軸で選定する:**
1. **テーマ関連** — 記事の主題と直接つながる記事（同じ体験・問い・教訓）
2. **プロダクト関連** — 記事内で触れているプロダクトの別の切り口の記事
3. **技術詳細** — 「もっと深く知りたい」読者向け。Zenn/Qiita等への誘導

**ルール:**
- 媒体を限定しない（Note記事からZennやLovai投稿にリンクしてよい）
- 日本語記事は日本語記事に、英語記事は英語記事にリンク
- 関連度で選ぶ。自分の記事だからという理由で貼らない
- 3〜5本に絞る
- 各リンクに一言説明を付ける
- テーマ関連を最低1本、プロダクト関連を最低1本含める

**フォーマット:**
```
### 関連記事

**テーマ関連**
- [タイトル](URL) — 一言説明

**プロダクト関連**
- [タイトル](URL) — 一言説明

**技術的に深掘りしたい方へ**
- [タイトル](URL) — 一言説明
```

### その他
- 1つずつ順番に確定させる。並行して全部作らない
- 指示されたタスクだけを実行する。先回りして他プラットフォーム版を勝手に作らない
- 締めは謙虚に。「まだ試行錯誤中」のトーン
- 個人情報（年齢・拠点・雇用形態）は記事に出さない

## 技術詳細が必要なとき

各プロダクトのコードベースは以下にあります。必要に応じて参照してください：

| プロダクト | パス |
|---|---|
| Lovai | `~/Development/active/Lovai/` |
| FORMLOVA | `~/Development/active/formlova/` |
| サポラバー | `~/Development/active/sapolova/` |
| モールラバー | `~/Development/active/malllova/` |

購読者が得るもの

私の思考が見れます

提供者

D3 Studio@d3-studio