0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@takurot(takurot)

良いOSSを作っても誰にも届かない問題をClaudeスキルで解決する

0
Posted at

はじめに

「1ヶ月かけて作ったOSS、GitHubスターが一桁のまま埋もれている」

エンジニアなら一度はこの状況に直面したことがあるのではないでしょうか。技術力があっても、発信の設計がなければOSSは届きません。

この記事では、SNSでOSSをバズらせるための戦略・企画20本・動画台本を一括生成するClaude用スキル「oss-sns-strategy」の設計思想と使い方を紹介します。

このスキルは、SNSコンサルタントとして知られるど素人ホテル再建計画さん（以下、ど素人さん）のバズメソッドをエンジニア向けに体系化したものです。

ど素人さんのメソッドとは

ど素人さんは、沖縄の赤字ホテル再建のプロセスをSNSで発信し、わずか1週間でフォロワー2万人を獲得したSNSコンサルタントです。NHKや『奇跡体験！アンビリバボー』にも取り上げられ、現在は450名以上が在籍するSNSスクール「バズ塾」を運営しています。

そのメソッドの核心は、以下の5つです。

1. プロセスエコノミー

完成品を宣伝するのではなく、「達成するまでの過程」をコンテンツにする考え方です。起業家のけんすうさんが提唱した概念をSNS戦略として昇華させたものです。

「検索しても答えは出ない。フォローするしかない」という状態を設計することで、視聴者が自然と追いかけ続ける構造を作ります。

2. 弱者設定（正しいベクトルで）

ポイントは「目標に対して正しいベクトルで弱者」であることです。

ど素人さんの例で言えば：

  • ❌ 動画クリエイターがホテルを再建（ベクトルがずれている）
  • ✅ ホテル経営のど素人がホテルを再建（同じベクトル上の弱者）

エンジニアがOSSを広めようとする文脈では：

  • ❌ 「20年のエンジニアが作った最強ツール」（強者アピール）
  • ✅ 「良いものを作ったのに誰にも届かないエンジニア」（同じベクトル上の弱者）

3. 冒頭2秒のフック設計

「2秒ごとに興味をズラす」という変態的に緻密な設計が特徴です。最初の2秒で視聴者の手を止めなければ、どんなに良い内容でも見られません。

4. 視聴者参加型の設計

視聴者の意見が実際にコンテンツや成果物に反映される仕組みを作ることで、「自分ごと」として巻き込みます。

5. PR感のないPR

「使ってください」と言わずに、実験・失敗・改善の過程を見せることで、自然にツールへの興味を生みます。

スキルの概要

スキル名： oss-sns-strategy

できること：

GitHubリポジトリのURLとOSSの概要を渡すだけで、以下の5セクションを一括生成します。

oss-sns-strategy Skill 
---
name: oss-sns-strategy
description: |
  OSSプロジェクトをSNSでバズらせるための戦略・企画・動画台本を一括生成するスキル。
  ユーザーがGitHubリポジトリURLとOSSの概要を提供したとき、または「OSSを宣伝したい」「GitHubスターを増やしたい」「OSSをSNSで話題にしたい」「個人開発を広めたい」「OSSマーケティングを手伝ってほしい」などと言ったときに必ずこのスキルを使うこと。
  プロセスエコノミー・弱者設定・視聴者参加型・PR感のないPR・冒頭2秒フックの5つの手法を組み合わせた戦略を出力する。
  出力は必ず以下の5セクション全て：アカウント初期設計・プロセスエコノミー設計・企画案20個・第1話ショート動画台本・改善サイクル。
---

# OSS SNS戦略スキル

OSSプロジェクトをSNSで注目させるための戦略・企画・台本を一括生成する。
単なる宣伝ではなく、「挑戦の結末を見届けたい」「応援したい」「参加したい」という構造を作ること。

## インプット収集

ユーザーから以下を収集する。提供されていない場合は質問する。

- **GitHubリポジトリURL**（必須）
- **OSSの概要**：何ができるツールか、誰向けか（必須）
- **現在のGitHubスター数**（任意。不明なら「不明」と記載）
- **投稿者のSNS経験**（任意。初心者/経験者）

URLが提供された場合、そのリポジトリの情報（言語、スター数、説明文）をもとに内容を具体化すること。

---

## 出力構成（全5セクション、必ず全部出力）

### セクション1：アカウント初期設計

以下を全て出力する。

**アカウントコンセプト**
- OSSの内容と挑戦の構造を1〜2文で表現する
- 「完成品の宣伝」ではなく「無名OSSが認知されるまでの過程を公開する挑戦アカウント」として設計する

**アカウント名案（10個）**
- 専門用語を避け、非エンジニアにも読めるもの
- 挑戦・実験・記録といったキーワードを含めると良い
- OSSの技術スタック名（例：Rust、Python等）を1〜2個含めてもよい

**プロフィール文案（5個）**
- 1案ごとに140文字以内
- 弱者設定（「誰にも使われていないOSSを作った」等）を自然に入れる
- フォローしたくなる理由（毎日記録・実験公開・一緒に育てる）を含める

**固定ポスト案**
- 30日チャレンジの宣言
- 現在地（スター数・フォロワー数）を数字で示す
- 視聴者に何をしてほしいかを、直接的な「スターください」以外の言葉で誘導する

**30日間の挑戦テーマ**
- Week1〜Week4に分けて、毎週のテーマを設定する
- 数字の変化が見えるように設計する（スター数、閲覧数、PRなど）

**視聴者がフォローしたくなる理由（3点）**

**エンジニア以外にも届く見せ方（3点）**

---

### セクション2：プロセスエコノミー設計

**現在地の弱者設定**
- 事実に基づいた「弱者性」を1〜3点書く
- 嘘や誇張はしない。スター数・認知度・コントリビューター数などの事実を使う

**目標設定**
- 「達成できるかできないかギリギリ」の目標を2〜3個設定する
- 期間と数値で具体化する（例：30日でスター100）

**視聴者参加の仕組み（3〜5個）**
- 投票・募集・コメント欄での意見収集など
- 視聴者の行動が実際にOSSに反映される仕組みにする

**毎日見せるべき数字（5個）**
- GitHub Stars, Forks, Issues, Views（Traffic）, SNSフォロワー数 など
- スクリーンショットで見せやすいものを選ぶ

**視聴者が応援したくなるストーリー（3幕構成）**
- 第1幕：弱者設定・現在地の絶望感（共感）
- 第2幕：試行錯誤・小さな変化（興味）
- 第3幕：目標達成 or 次の挑戦（期待）

**嘘っぽく見えないための注意点（5個）**

---

### セクション3：バズりやすい企画案（20個）

各企画を「AIに渡してすぐショート動画台本を生成できるプロンプト」として出力する。

**出力フォーマット（企画1件ごと）**

【企画XX：タイトル】

▼ 企画メモ（人間用の確認情報）
種類：（プロセス公開 / 実験 / ストリート / バックテスト結果 / 失敗・落胆 のいずれか）
冒頭フック：（冒頭2秒で言う言葉）
想定コメント：（視聴者が書きそうな反応）

▼ 台本生成プロンプト（このままAIに貼り付けて使う）
---
あなたはSNSショート動画（TikTok・Reels・YouTube Shorts）の台本ライターです。
以下の条件で、1分以内のショート動画台本を作成してください。

【OSSの基本情報】
- ツール名：{OSS_NAME}
- 一言説明：{OSS_DESCRIPTION}（例：仮想通貨の売買ルールを過去データで検証できるツール）
- GitHubスター数：{STAR_COUNT}
- 使用言語：{LANGUAGE}

【この動画のテーマ】
{THEME}

【冒頭2秒のフック（必ずこの言葉から始めること）】
「{HOOK}」

【台本に必ず含める要素】
- 映像指示（画面に何を映すか）
- セリフ（実際に話す言葉）
- テロップ（画面に重ねるテキスト）
- 視聴者への質問（コメントで答えてもらう形式）
- 締め（次回予告 or 前向きな終わり方）

【禁止事項】
- 「スターください」「使ってください」などの直接的なPR表現
- 専門用語のまま使う（必ず非エンジニア向けに言い換える）
- 1分を超える台本

【出力フォーマット】
【0:00〜0:02】映像：／セリフ：／テロップ：
【0:02〜0:XX】映像：／セリフ：／テロップ：
…（時間ごとに区切って出力）
【視聴者への質問】
【締め・次回予告】
---

企画の種類は以下をバランスよく混ぜる。
- プロセス公開系（数字の変化を見せる）×4
- 実験系（AとBどちらが効くか試す）×4
- ストリート系（エンジニア・投資家への質問）×4
- バックテスト結果系（ツールの実用結果を見せる）×4
- 失敗・落胆系（うまくいかなかった日を正直に見せる）×4

プロンプト内の `{OSS_NAME}`, `{OSS_DESCRIPTION}`, `{STAR_COUNT}`, `{LANGUAGE}`, `{THEME}`, `{HOOK}` は、ユーザーが提供したOSSの情報で埋めた状態で出力すること（プレースホルダーのままにしない）。

---

### セクション4：第1話ショート動画台本（1分以内）

以下を全て含めた台本を出力する。

**構成要素（必須）**
- 冒頭0〜2秒：強烈なネガティブフック（エンジニア以外も手を止める表現）
- 映像指示（画面に何を映すか）
- セリフ（話す言葉）
- テロップ（画面に表示するテキスト）
- GitHub画面・スター数の見せ方
- 視聴者参加の呼びかけ（コメントに何を書いてもらうか）
- 最後：ハッピーエンドまたは次回予告で終わる
- 「スターください」と直接言わない。PR感のない自然な導線

**フォーマット**

【0:00〜0:02】
映像：
セリフ：
テロップ：

【0:02〜0:XX】
映像：
セリフ：
テロップ：

...

【視聴者参加の呼びかけ】
【次回予告 or 締め】

---

### セクション5：改善サイクル

**見るべきKPI（7個）**
- SNS側とGitHub側に分けて記載

**伸びなかった時の改善方法（5パターン）**
- 「再生数は高いがフォロワーが増えない」「コメントがつかない」など状況別に記載

**コメント欄の活用方法（3点）**

**GitHub側で改善すべき項目（5個）**
- README、トップページ、トピックタグ、CONTRIBUTING.md 等

**次の10本で検証すべき仮説（5個）**
- 「英語投稿 vs 日本語投稿」のような具体的な実験仮説

---

## 品質チェックリスト

出力前に以下を確認する。

- [ ] 専門用語を使う場合は非エンジニア向けに言い換えを添えているか
- [ ] 弱者設定は事実に基づいているか（嘘・誇張がないか）
- [ ] 「スターください」「使ってください」などの直接的なPRが含まれていないか
- [ ] 企画案20個は種類が偏っていないか（各種類4本ずつ）
- [ ] 台本は1分以内に収まるボリュームか（目安：日本語で約400〜500文字）
- [ ] GitHub URLが提供された場合、リポジトリの実情（言語・スター数・説明）を反映しているか
- [ ] 企画案のプロンプト内に {プレースホルダー} が残っていないか（全て実際の値で埋めているか）
- [ ] 各プロンプトの {HOOK} はエンジニア以外も手を止める表現になっているか
- [ ] 各プロンプトの {THEME} はその企画の目的を1〜2文で具体的に説明しているか

---

## 出力スタイル指示

- 日本語で回答
- 抽象論で終わらせず、具体的な言葉・数字・セリフを書く
- エンジニア以外にも伝わる言葉を使う（ただし技術者としての信頼感は保つ）
- 過度な煽りや嘘の演出は避ける
- マークダウン形式で整理して出力する
セクション 内容
1. アカウント初期設計 アカウント名案10個・プロフィール5案・固定ポスト・30日チャレンジテーマ
2. プロセスエコノミー設計 弱者設定・目標・視聴者参加の仕組み・3幕ストーリー
3. 企画案20本 AIに渡してそのまま台本生成できるプロンプト形式
4. 第1話ショート動画台本 1分以内の完成台本（映像指示・セリフ・テロップ付き）
5. 改善サイクル KPI・伸びなかった時の改善パターン・GitHub改善項目

最大の特徴：企画案がそのまま「台本生成プロンプト」になっている

通常の企画案は「こんな動画を作れ」という指示で終わります。このスキルでは企画案20本のそれぞれが、AIに貼り付ければ即座に台本を生成できるプロンプトとして出力されます。

出力イメージ：

【企画01：スター0からの宣戦布告】

▼ 企画メモ（人間用の確認情報）
種類：プロセス公開系
冒頭フック：「このOSS、たぶん誰にも使われません」
想定コメント：「応援してます」「自分のOSSも同じ状況」

▼ 台本生成プロンプト（このままAIに貼り付けて使う）
---
あなたはSNSショート動画の台本ライターです。
以下の条件で、1分以内のショート動画台本を作成してください。

【OSSの基本情報】
- ツール名：crypto-rs-backtester
- 一言説明：仮想通貨の売買ルールを過去データで検証できるツール
- GitHubスター数：8
- 使用言語：Rust

【この動画のテーマ】
30日間でGitHubスター100を目指す挑戦の第1話。
現在地の弱者設定と、挑戦宣言を見せる。

【冒頭2秒のフック（必ずこの言葉から始めること）】
「このOSS、たぶん誰にも使われません」

【台本に必ず含める要素】
- 映像指示（画面に何を映すか）
- セリフ（実際に話す言葉）
- テロップ（画面に重ねるテキスト）
- 視聴者への質問（コメントで答えてもらう形式）
- 締め（次回予告 or 前向きな終わり方）

【禁止事項】
- 「スターください」「使ってください」などの直接的なPR表現
- 専門用語のまま使う（必ず非エンジニア向けに言い換える）
- 1分を超える台本
---

変数（OSSの名前・スター数・フックなど）は、入力したリポジトリ情報で自動的に埋められた状態で出力されます。

実際の動作例

crypto-rs-backtester（Rust製の暗号資産バックテストライブラリ）を対象に実行した際の出力例を抜粋します。

弱者設定の出力例

・Rust製という技術的こだわりがあるが、
  Rust自体のコミュニティは英語圏が中心であり日本語圏での認知がほぼない
・GitHubスターが一桁台という事実を数字で見せる
・コントリビューターがまだいない——自分一人で作り続けている孤独な状態

第1話台本の冒頭部分

【0:00〜0:02】
映像：GitHubリポジトリページのスター数をクローズアップ
セリフ：（無言。効果音だけ）
テロップ：「このOSS、たぶん誰にも使われません」（大きく表示）

【0:02〜0:10】
映像：顔出しまたは手元だけ。普通の部屋。
セリフ：「1ヶ月かけて、仮想通貨の売買ルールを
         過去データで検証できるツールを作りました」
テロップ：「1ヶ月かけて作ったツール」

スキルのインストール方法

.skill ファイルを Claude.ai の Settings → Skills からアップロードするだけです。

インストール後は、以下のように話しかけるだけでスキルがトリガーされます：

このOSSをSNSでバズらせたい。
https://github.com/yourname/your-oss
Rust製のXXXツールで、YYYができます。スターは現在〇個です。

設計上のこだわり

エンジニア以外にも届く言葉に変換する

スキルの内部では、技術用語を非エンジニア向けに言い換えるルールが組み込まれています。

技術的な表現 非エンジニア向けの表現
Rust製バックテストライブラリ 仮想通貨の売買ルールを過去データで試せる道具
GitHubスター数 開発者界隈での「いいね」の数
コントリビューター プロジェクトに参加してコードを直してくれた人

嘘・誇張なしの弱者設定

ど素人さんのメソッドで強調されているのが、「正しいベクトルの弱者設定」と「嘘を使わないこと」です。スキルの品質チェックリストにも「弱者設定は事実に基づいているか」を必ず確認する項目を入れています。

「スターください」と言わない設計

直接的なPR表現を全企画・全台本で禁止しています。代わりに、実験結果・失敗・改善のプロセスを見せることで、視聴者が自発的にリポジトリを確認しに行く動線を設計します。

ど素人さんのメソッドとエンジニアの相性

ど素人さんのメソッドが特に効果的なのは「誰でも気になる問い」が作りやすいジャンルです。

OSSには天然の問いがあります。

  • 「この投資法、本当に過去データで勝てたの？」
  • 「無名のOSSが30日でどこまで伸びるのか？」
  • 「Rustで作った理由って何？Pythonじゃダメなの？」

技術的なこだわりが、非エンジニアにとっての「稀有性」になります。ど素人さんが言う「稀有な人に普通の質問をする」フォーマットは、エンジニアに対して非常に有効に機能します。

まとめ

課題 このスキルのアプローチ
良いOSSが届かない 「過程の公開」をコンテンツに変換する
技術者以外に伝わらない 専門用語を非エンジニア向けに自動変換
毎回企画を考えるのが大変 AIに渡せるプロンプト形式で20本一括生成
宣伝っぽくなってしまう 直接的なPR表現を構造的に排除
弱者設定が嘘くさくなる 事実ベースの設定ルールを品質チェックに組み込む

OSSを作って「公開したのにスターが増えない」と感じているエンジニアの方に、ぜひ試してほしいスキルです。

参考・謝辞

このスキルの設計にあたり、ど素人ホテル再建計画さんのSNSバズメソッドを参考にさせていただきました。

プロセスエコノミー・弱者設定・冒頭フック設計など、本スキルのコアとなる考え方はど素人さんのメソッドに基づいています。

関連リンク

  • スキルを作成したOSS：crypto-rs-backtester（Rust製・暗号資産バックテストライブラリ）
  • スキル作成には Claude.ai の Skills 機能を使用
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?