devrel-content

DevRel コンテンツ

このスキルは、開発者に実際に読まれる技術コンテンツ（ブログ記事、チュートリアル、ドキュメント、ソートリーダーシップ記事）の作成を支援します。信頼を築き、導入を促進するコンテンツを作成できます。

---

始める前に

まず、対象読者のコンテキストを読み込んでください。 .agents/developer-audience-context.md を読み、以下を把握します。

• 誰に向けて書くのか（役割、経験年数、技術スタック）
• 読者の課題（どのような問題に関心があるか）
• 読者が実際に使う表現（物事をどのように説明するか）
• 文体とトーン（どの程度フォーマルか、技術的か）

コンテキストファイルが存在しない場合は、まず developer-audience-context スキルを実行してください。

---

DevRel コンテンツのフレームワーク

フェーズ 1：調査と検証

何かを書く前に、そのトピックについて書く価値があるかを検証します。

調査の種類	実施すること
検索意図	トピックを Google で検索します。すでに上位表示されているのは何ですか？何が不足していますか？
コミュニティの兆候	Reddit、HN、Stack Overflow を検索します。開発者はこのトピックについて質問していますか？
競合の不足点	競合は何を書いていますか？何を取り上げていませんか？
内部データ	このトピックに関するサポートチケット、Discord の質問、GitHub の Issue
キーワード調査	Ahrefs/SEMrush を使って、技術用語の検索ボリュームを調べます

注意すべき兆候 — 次の場合は書かないでください。

• このトピックに関心があるのが自分だけである
• 同じ内容の記事がすでに 10 件ある
• トピックが広すぎる（「JavaScript 入門」など）
• トピックが狭すぎる（検索ボリュームがなく、コミュニティの関心もない）

フェーズ 2：コンテンツの種類を選ぶ

目標に合った形式を選びます。

コンテンツの種類	最適な用途	構成
チュートリアル	特定のスキルを教える	ステップごとの説明、コード中心
ガイド	トピックを包括的に扱う	セクション、参考資料
比較	意思決定を支援する	表形式、長所と短所
告知	機能や製品を公開する	ニュースの要点、何を・なぜ・どのように
ソートリーダーシップ	権威を築く	意見、予測、見解
事例紹介	社会的証明	課題 → 解決策 → 結果
トラブルシューティング	特定のエラーを解決する	エラー → 原因 → 修正方法

フェーズ 3：アウトラインを作成する

次のアウトラインテンプレートを使います。

# [Title that promises specific value]

## Hook (2-3 sentences)
- State the problem or opportunity
- Establish credibility ("We migrated 10,000 repos...")
- Promise what the reader will learn

## Context (optional)
- Brief background if needed
- Link to prerequisites

## The Meat
### Section 1: [First major concept]
- Explanation
- Code example
- Common pitfall

### Section 2: [Second major concept]
- Explanation
- Code example
- Real-world application

### Section 3: [Third major concept]
- Explanation
- Code example
- Advanced tip

## Putting It Together
- Complete example
- Working code

## What's Next
- Links to deeper content
- Call to action (try the product, join Discord, etc.)

---

コード例を書く

コードがコンテンツの要です。正確に書きましょう。

コピー＆ペーストのテスト

すべてのコード例は、次の要件を満たす必要があります。

要件	重要な理由
変更なしで実行できる	開発者はコピーして貼り付けます。動かなければ、信頼を失います。
インポートを含める	どのライブラリをインポートすべきか、読者が知っているとは限りません。
出力を示す	正常に動作したとき、何が表示されるべきかを示します。
エラーを処理する	実際のコードにはエラー処理があります。それを示します。
実際の値を使う	必要な場合を除き、foo、bar、example.com は使わないでください。

コード例の構成

First, install the dependencies:

\`\`\`bash
npm install your-library axios
\`\`\`

Now create a file called `fetch-data.js`:

\`\`\`javascript
// fetch-data.js
import { Client } from 'your-library';
import axios from 'axios';

const client = new Client({
  apiKey: process.env.YOUR_API_KEY // Use environment variables
});

async function fetchUserData(userId) {
  try {
    const user = await client.users.get(userId);
    console.log(`Fetched user: ${user.name}`);
    return user;
  } catch (error) {
    console.error(`Failed to fetch user: ${error.message}`);
    throw error;
  }
}

// Example usage
fetchUserData('user_123')
  .then(user => console.log(user))
  .catch(err => process.exit(1));
\`\`\`

Run it:

\`\`\`bash
YOUR_API_KEY=sk_test_xxx node fetch-data.js
\`\`\`

Expected output:

\`\`\`
Fetched user: Jane Developer
{ id: 'user_123', name: 'Jane Developer', email: '[email protected]' }
\`\`\`

言語ごとの規約

言語	コードブロック	パッケージのインストール	環境変数
JavaScript/Node	javascript または js	npm install	process.env.VAR
TypeScript	typescript または ts	npm install	process.env.VAR
Python	python または py	pip install	os.environ['VAR']
Go	go	go get	os.Getenv("VAR")
Rust	rust	cargo add	std::env::var("VAR")
Shell	bash または shell	N/A	$VAR

---

技術的な正確性のチェックリスト

公開前に確認します。

確認項目	検証方法
コードが動く	すべてのスニペットをコピーして貼り付け、実行します
バージョンが一致している	現行のライブラリバージョンを使っていますか？
リンクが機能する	すべてのリンクをクリックします
コマンドが機能する	すべての CLI コマンドを実行します
スクリーンショットが最新である	UI のスクリーンショットは現行の製品と一致していますか？
非推奨 API がない	使用している API が非推奨になっていないか確認します
セキュリティレビュー	ハードコードされたシークレットや SQL インジェクションなどがないことを確認します
ピアレビュー	エンジニアに正確性を確認してもらいます

---

開発者向けコンテンツの SEO

開発者は、一般消費者とは異なる方法で Google を使います。

開発者の検索パターン

パターン	検索例
エラーメッセージ	"TypeError: Cannot read property 'map' of undefined"
方法	"how to deploy next.js to vercel"
比較	"prisma vs typeorm 2024"
ベストプラクティス	"typescript project structure best practices"
代替手段	"alternatives to firebase"
組み合わせ	"react with typescript tutorial"

テクニカル SEO チェックリスト

要素	ベストプラクティス
タイトル	主要キーワード、フレームワーク名、関連する場合は年を含めます
メタディスクリプション	150 文字に収め、キーワードを含め、具体的な成果を約束します
H1	タイトルと一致させるか、できるだけ近づけます
H2	関連キーワードを含め、内容をひと目で把握できるようにします
コードブロック	適切なシンタックスハイライトを使用します（強調スニペットの表示に役立ちます）
内部リンク	関連ドキュメント、チュートリアル、API リファレンスにリンクします
外部リンク	紹介するツールの公式ドキュメントにリンクします
URL スラッグ	小文字とハイフンを使い、キーワードを含めます

最適化されたタイトルの例

悪い例	良い例
"Using Our API"	"How to Authenticate with the YourProduct API (Node.js)"
"Database Guide"	"PostgreSQL Connection Pooling: Complete Guide with pgBouncer"
"Getting Started"	"Getting Started with YourProduct: Your First API Call in 5 Minutes"

---

コンテンツ品質のシグナル

優れた開発者向けコンテンツと平凡なコンテンツの違いは次のとおりです。

こうしましょう

• 説明するより見せる — 文章よりコードを使います
• 「なぜ」に答える — 方法だけでなく、いつ、なぜ使うのかも説明します
• トレードオフを認める — 完璧なものはありません。開発者は誠実さを重視します
• 情報源にリンクする — 公式ドキュメント、RFC、関連記事にリンクします
• 日付を含める — 「2024年3月更新」やバージョン番号を記載します
• 段階的に情報を示す — シンプルな内容から始め、徐々に複雑さを加えます
• 実例を含める — 「Hello, world」だけでなく、本番環境のシナリオを取り上げます

これは避けましょう

• 長文の壁 — コード、見出し、箇条書きで区切ります
• マーケティング用語 — 「業界最高」「シームレス」「革新的」など
• 知識があると決めつける — 略語を定義し、前提知識の説明にリンクします
• 古いコンテンツ — 非推奨の API を使った 2019 年のチュートリアルほど悪いものはありません
• 要点を後回しにする — まず答えを示し、その後に説明します
• コードがない — 開発者が求めているのは文章ではなくコードです

---

コンテンツのテンプレート

ブログ記事のテンプレート

# [Specific, keyword-rich title]

[2-3 sentence hook: problem + promise]

## The Problem

[1 paragraph explaining the pain point]

## The Solution

[Brief explanation of your approach]

### Step 1: [Action]

[Explanation]

\`\`\`language
// Code
\`\`\`

### Step 2: [Action]

[Explanation]

\`\`\`language
// Code
\`\`\`

### Step 3: [Action]

[Explanation]

\`\`\`language
// Code
\`\`\`

## Complete Example

\`\`\`language
// Full working code
\`\`\`

## Troubleshooting

### [Common Error 1]
[Solution]

### [Common Error 2]
[Solution]

## What's Next

- [Link to deeper dive]
- [Link to related tutorial]
- [CTA: Try it yourself]

比較記事のテンプレート

# [Tool A] vs [Tool B]: [Specific Use Case] ([Year])

[1 paragraph: Who this comparison is for and what you'll learn]

## Quick Comparison

| Feature | Tool A | Tool B |
|---------|--------|--------|
| [Feature 1] | | |
| [Feature 2] | | |
| [Feature 3] | | |

## When to Choose [Tool A]

- [Scenario 1]
- [Scenario 2]
- [Scenario 3]

## When to Choose [Tool B]

- [Scenario 1]
- [Scenario 2]
- [Scenario 3]

## Deep Dive: [Specific Aspect]

### Tool A Approach
[Explanation + code]

### Tool B Approach
[Explanation + code]

## Our Recommendation

[Specific guidance based on use case]

---

コンテンツの成果を測定する

追跡する指標

指標	わかること
ページビュー	リーチ（ただし、背景情報がなければ見栄えだけの指標です）
ページ滞在時間	エンゲージメント（読まれているか）
スクロール深度	最後まで読まれたか
直帰率	必要な情報が見つかったか
検索順位	SEO のパフォーマンス
被リンク	権威性と参照価値
ソーシャルシェア	反響（特に HN、Twitter、Reddit）
コンバージョンイベント	登録、インストール、ドキュメントのクリック

コンテンツからコンバージョンまでの経路

ユーザーの行動を追跡します：

1. 検索／ソーシャル → ブログ記事
2. ブログ記事 → ドキュメント／クイックスタート
3. ドキュメント → 登録／インストール
4. 登録 → 利用開始（最初の成功）

---

ツール

ツール	用途
Octolens	コンテンツがどこで共有されているか（HN、Reddit、Twitter）を監視します。競合コンテンツのパフォーマンスを追跡します。開発者の会話からコンテンツのアイデアを見つけます。
Grammarly / Hemingway	読みやすさと文法のチェック
Carbon / Ray.so	美しいコードのスクリーンショット
Excalidraw	技術図の作成
Loom	手軽な動画チュートリアル
Ahrefs / SEMrush	キーワード調査と SEO の追跡
Google Search Console	検索パフォーマンスの追跡

---

関連スキル

• developer-audience-context — 読者を理解するための基礎
• technical-tutorials — ステップバイステップのコンテンツを深掘りする
• developer-newsletter — メールでコンテンツを配信する
• developer-seo — 技術的な SEO の最適化
• hacker-news-strategy — HN で効果的にコンテンツを共有する