Agent-Skills.md

Agent Skills: AI Interview Article Skill

>

UncategorizedID: kimny1143/claude-code-template/ai-interview-article

Install this agent skill to your local

pnpm dlx add-skill https://github.com/kimny1143/claude-code-template/tree/HEAD/.claude/skills/ai-interview-article

Skill Files

Browse the full folder contents for ai-interview-article.

Download Skill

Loading file tree…

.claude/skills/ai-interview-article/SKILL.md

Skill Metadata

Name
ai-interview-article
Description
>

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）: 通常テキスト。名前は書かない。
> 単刀直入に聞きます。AIに音楽教えてもらえば、もう教則本いらなくないですか？

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

> やってみた。

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

絶対にやらないこと:

  • **Claude:** **kimny:** のように毎回名前を書く
  • 名前を太字ラベルとして行頭に置く

記事ヘッダー

# タイトル

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

注釈・前提情報

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

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

セクション見出し

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

AIO最適化セクション

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

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

> **この記事のポイント:** プロ作曲家は「メロディが降りてくる」経験を持たない。15年のキャリアで一度もない。創作の正体は「記憶の再構成」であり、インプットの質と量がアウトプットを決める。
  • AIOが引用しやすい「問い→回答」構造
  • 読者にとっても記事の価値が5秒でわかる
  • 対話のリズムを邪魔しない位置に置く

末尾FAQ（導線の前）：

## よくある質問

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

**Q: AIに作曲を教えてもらうのは有効？**
A: 部分的に有効だが、AIの回答は中央値に収束する傾向がある。（2〜3文で回答）
  • AIOのFAQ引用パターンに最適化
  • 2〜3問。記事テーマに応じて設計

末尾

---

*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）を入れ忘れる → テンプレとして毎回入れる