---
name: ai-interview-article
description: >
  kimny × Claude（AI）のインタビュー形式でnote記事を作成するスキル。
  品質ゲート（発見・外部アンカー・1文テスト）による公開判断、AIO最適化、対話フォーマットルールを定義。
  使用タイミング: (1) note記事の作成・リライト (2) インタビュー形式の記事構成
  (3) 過去会話からの記事化 (4) 記事の品質チェック。
  トリガー例: 「記事にしたい」「noteに書きたい」「インタビュー形式で」
  「これ記事にならない？」「記事のリライト」「品質ゲート通して」
  「AIO最適化」「note記事」
---

# AI Interview Article Skill

kimnyとClaudeの対話をインタビュー記事として構成するためのスキル。

あなたはインタビュアーとして、読者が聞きたいことを代弁し、kimnyの発言を構造化する役割を担う。

## 筆者プロフィール

- kimny（木村篤史）。2009年からプロ作曲家・編曲家。glasswerks inc.代表
- J-POP中心にキャリアを積み（AKB48、JUJU、ももクロ等）、ここ2〜3年でCM音楽の比率が増加
- 音楽制作70%、AI開発30%の事業構成
- MUEDnote（音楽制作ログアプリ）開発者。AIキャラクター「Hoo」展開予定
- WAIS: WM128（高）、PS97（低）。ASD/ADHD傾向

## ターゲット読者

**メイン:** 音楽制作をやっている or やりたい人で、AIにも関心がある層
- DTMer（初心者〜中級者）でAIツールを触り始めている人
- プロ志望だが「プロの現場」を知らない人
- noteで `#DTM` `#作曲` `#音楽制作` を日常的に読んでいる人

**サブ:** AI活用に関心がある非エンジニア層（記事の題材次第でリーチする）

メインターゲットの求心力を薄めない範囲でサブにも届ける。

---

## 品質ゲート（公開前に必ず通す）

記事を書いたら、公開前にこの3チェックを通す。**3つ全部通らない記事は公開しない。**

### チェック1: 「発見」があるか

読者が記事を読む前と後で、認識が変わるポイントが1つ以上あるか。

| 判定 | 基準 | 例 |
|------|------|-----|
| ◎ | 読者の認識が明確に変わる | 「メロディは降りてこない。記憶の反芻でしかない」 |
| ○ | 新しい視点はあるが驚きは弱い | 「収録現場で作曲家は喋らなくていい」 |
| △ | 面白いが「知ってた」で終わりそう | 「AIは便利だが万能ではない」→ 不合格 |
| × | 意見記事・感想記事レベル | → 不合格 |

**△以下は公開しない。** 素材として寝かせ、他の記事に統合する。

### チェック2: 「外部アンカー」があるか

kimny個人の話だけで完結していないか。以下のいずれかが含まれているか。

- 他者のエピソード or 発言（医学生の「記憶の反芻」、巨匠のスタジオ流儀、Recエンジニアの知見）
- 実験・検証の結果（AIにEQを聞いた実験、DSPエンジンの実装過程）
- 外部の概念・研究との比較（Museの語源、逆位相キャンセル）
- 具体的な数字・事実（CM採用率、WAIS結果）

| 判定 | 基準 |
|------|------|
| ◎ | 他者のエピソード or 実験データが記事を支えている |
| ○ | 部分的にある |
| △ | ほぼkimny個人の話だけ → 要改善 |
| × | 完全に自己完結（自社プロダクトの話で閉じている等）→ 不合格 |

**外部アンカーがないと「自分で自分にインタビューしてる感（でっち上げ感）」が出る。** パーソナルな話だけで完結している記事はインタビュー形式の必然性が薄くなる。

### チェック3: 1文テスト

以下の一文が書けるか：

> 「この記事を読むと、〇〇だと思っていたことが、実は〇〇だとわかる」

書けない記事は公開しない。

---

## フォーマットルール

### 話者の表記

- **質問者（Claude / Hoo）**: `>` 引用ブロックで表示。名前は書かない。
- **回答者（kimny）**: 通常テキスト。名前は書かない。

```markdown
> 単刀直入に聞きます。AIに音楽教えてもらえば、もう教則本いらなくないですか？

いい質問。僕も同じこと思った。だから実際にやってみたんだよ。

> やってみた。

うん。2025年5月の時点で最良だった…
```

**絶対にやらないこと:**
- `**Claude:**` `**kimny:**` のように毎回名前を書く
- 名前を太字ラベルとして行頭に置く

### 記事ヘッダー

```markdown
# タイトル

*MUEDnote開発者 kimny × Claude（AI）*
```

- タイトルは内容を端的に表す。「〜について」的な説明調は避ける。
- サブタイトルは `*イタリック*` で著者クレジットのみ。
- 将来的にインタビュアーをHooに変更する可能性あり。その場合は `*MUEDnote開発者 kimny × Hoo（AI）*` に。

### 注釈・前提情報

過去記事の再構築や、当時のモデル名が出る場合：

```markdown
> ※本記事は〜を、インタビュー形式で再構築したものです。当時のAIモデル名（ChatGPT o3等）がそのまま登場します。
```

### セクション見出し

`## 見出し` で区切る。見出しは会話の流れの中で自然な区切りに置く。

### AIO最適化セクション

各記事に以下の2つを入れる：

**冒頭サマリー（ヘッダー直後、対話の前）：**

```markdown
> **この記事のポイント:** プロ作曲家は「メロディが降りてくる」経験を持たない。15年のキャリアで一度もない。創作の正体は「記憶の再構成」であり、インプットの質と量がアウトプットを決める。
```

- AIOが引用しやすい「問い→回答」構造
- 読者にとっても記事の価値が5秒でわかる
- 対話のリズムを邪魔しない位置に置く

**末尾FAQ（導線の前）：**

```markdown
## よくある質問

**Q: メロディが思い浮かばないのは才能がないから？**
A: 才能の問題ではなく、インプットの蓄積量の問題。（2〜3文で回答）

**Q: AIに作曲を教えてもらうのは有効？**
A: 部分的に有効だが、AIの回答は中央値に収束する傾向がある。（2〜3文で回答）
```

- AIOのFAQ引用パターンに最適化
- 2〜3問。記事テーマに応じて設計

### 末尾

```markdown
---

*MUEDnoteは、音楽制作の「やったこと」を記録するログアプリです。→ [MUED.jp](https://mued.jp)*
```

- 全記事共通。1〜2文。押し売りしない。
- 記事の内容とMUEDnoteの接点がある場合のみ、もう1文追加可

### ハッシュタグ

noteのハッシュタグ、5〜8個。構成：
- シリーズタグ: `#AIインタビュー`（常に先頭）
- 広域タグ: 2〜3個（`#音楽制作` `#DTM` `#作曲` など）
- 記事固有タグ: 2〜3個（記事のテーマに応じて）
- レッドオーシャン（`#ChatGPT` `#生成AI`）は避ける

---

## 記事作成ワークフロー

### 1. 素材収集

ユーザーが「これ記事にならない？」と言ったら、または過去記事のリライトを依頼されたら：

1. claude-history MCP の `conversation_search` で関連する過去の会話を検索（複数キーワードで）
2. 元記事がある場合はその内容を確認
3. 核となるストーリーライン・発見を特定

### 2. 品質ゲート（事前）

構成を組む前に、品質ゲートの3チェックを素材に対して行う：
- このネタに「発見」はあるか？
- 「外部アンカー」はあるか？
- 1文テストに通るか？

**通らない場合：** 素材として寝かせるか、外部アンカーを追加できないか検討する。通らないまま記事化を進めない。

### 3. 構成設計

記事に必要な要素：
- **発見** — 読者の認識が変わるポイント（品質ゲート通過済み）
- **外部アンカー** — kimny個人の話で閉じない要素（品質ゲート通過済み）
- **一次情報** — kimnyの経験、実験結果、具体的なエピソード
- **プロモーション価値** — MUEDnoteへの自然な導線（押し売りにしない）

### 4. 対話の設計

**質問者（Claude）の役割：**
- 読者が聞きたいことを代弁する
- 回答者の発言を構造化・要約する（「つまり〜ということですか」）
- 重い話題に入る前にトーンを調整する（「ちょっと重い話になりますけど」）
- 元記事で書ききれてなかった部分を掘る（「具体的にどこがズレてた？」）

**回答者（kimny）の口調：**
- 砕けた口語体。「〜なんだよね」「〜でしょ」
- 専門用語は自然に使うが、文脈で意味が通るようにする
- 自虐やユーモアを混ぜる（「ちょっと傷ついた」）
- 結論を急がない。考えながら話す感じ。

**対話のテンポ：**
- 質問者の発言は短く。1〜2文。
- 回答者の発言は長くてもいいが、段落が3つ以上続いたら質問者が合いの手を入れる。
- 「うん」「そう」だけの短い応答も使う。会話のリズムのため。

### 5. トーン調整

インタビュー形式の強みは、重い話題や自己宣伝のトーンを対話で緩和できること。

- 自社サービスの話 → 質問者が聞いた体にする（kimnyから言い出さない）
- 重い話題（著作権、IP問題等） → 質問者が「ちょっと重い話ですが」と前置き
- 結論が曖昧でもいい → 無理にまとめず余韻で終わる選択肢もある

### 6. 記事画像の生成

記事内の図解・挿絵はGeminiで生成する。以下のワークフローで統一感を保つ。

**基底プロンプト（全画像共通）：**

```
Flat illustration style, clean lines, warm color palette (cream, sand beige, terracotta, mustard, soft teal). No dark backgrounds, no neon glow, no outer space imagery. Warm, approachable, slightly playful — like an indie magazine infographic. Aspect ratio 1.91:1.
```

**使い方：**
1. 基底プロンプトをGeminiのスレッドに最初に送る（スタイル固定）
2. 続けて `Subject:` 以降に具体的な画像内容を記述する
3. 1記事につき見出し画像1枚 + 本文中の図解0〜3枚が目安

**Subject記述のルール：**
- 何が描かれているかを構造的に記述する（「左に〇〇、右に〇〇、それらを繋ぐ線」など）
- 図解の場合は「key visual insight」を明記する（読者に何を伝えたいか）
- 日本語テキストを画像内に含める場合は明示する
- `No photorealism, no 3D effects` は基底プロンプトに含まれるので省略可

**スタイル一貫性の注意点：**
- 同一スレッド内で生成すればGeminiがスタイルを引き継ぐ
- 別スレッドで生成する場合は基底プロンプトを再送すること
- 暗い背景、ネオン、宇宙モチーフは基底プロンプトで禁止済み

### 7. 品質ゲート（公開前）

記事完成後、再度3チェックを通す。書いてみた結果「発見が弱い」「外部アンカーが足りない」となった場合は、寝かせる判断をする。

---

## 投稿ルール

### 記事タイプ別スケジュール

| タイプ | ペース | 制約 |
|--------|--------|------|
| インタビュー記事（無料） | 制限なし | 同日に複数本出さない |
| 有料記事 | 週1本、曜日固定 | 公開後72時間はエンゲージメント初動観測期間。次の有料記事はその後 |

### 共通ルール

- 同日に複数記事を公開しない（エンゲージメント分散を防ぐ）
- ThreadsやXで告知する場合、noteの新記事公開日とThreadsの告知記事は同じ記事にする。別の記事を同日に宣伝して導線を分散させない。
- `articles.json` で公開状況を管理する。公開前に `/note-status` で最新状態を確認。

---

## やりがちなミス（過去の指摘事項）

1. **話者名を毎回書く** → `>` と通常テキストの視覚差だけで区別する
2. **教材・サービスの宣伝で終わる** → 読者が持ち帰れる視点で終わる
3. **元記事を持ってないのに本数を言い張る** → claude-history MCP の `conversation_search` と `recent_chats` で実際の本数を確認する
4. **kimnyの現在の考えと過去の結論がズレてる** → 必ず現在の認識を確認してから結論を書く
5. **「狡猾なプロモーション」を無意識にやる** → やってもいいが、自覚はしておく
6. **外部アンカーなしで記事化を進める** → パーソナルな話だけだと「でっち上げ感」が出る。必ず外部要素を入れる
7. **複数記事を同日に公開する** → エンゲージメントが分散して全記事が沈む。同日複数本厳禁（有料記事は週1本ルールも適用）
8. **AIOセクション（冒頭サマリー・末尾FAQ）を入れ忘れる** → テンプレとして毎回入れる