コンテンツリサーチライター
このスキルはあなたのライティングパートナーとして機能し、あなた独自の声やスタイルを保ちながら、リサーチ、アウトライン作成、ドラフト執筆、コンテンツの推敲を支援します。
このスキルを使う場面
- ブログ記事、論文、ニュースレターの執筆
- 教材やチュートリアルの作成
- ソートリーダーシップ記事の起草
- ケーススタディのリサーチと執筆
- 出典付きの技術文書作成
- 適切な引用や参考文献を用いた執筆
- 導入部やフックの改善
- 執筆中のセクションごとのフィードバック取得
このスキルができること
- 協調的なアウトライン作成: アイデアをまとまりのあるアウトラインに構造化するのを支援
- リサーチ支援: 関連情報を見つけ出し、引用を追加
- フックの改善: 読者の注意を引く出だしを強化
- セクションフィードバック: あなたが書いた各セクションをレビュー
- 声の保持: あなたの執筆スタイルやトーンを維持
- 引用管理: 参考文献を適切に追加し、フォーマット
- 反復的な推敲: 複数のドラフトを通じて改善を支援
使い方
執筆環境のセットアップ
記事用の専用フォルダを作成します：
mkdir ~/writing/my-article-title
cd ~/writing/my-article-title
ドラフトファイルを作成します：
touch article-draft.md
このディレクトリからClaude Codeを開いて、執筆を始めます。
基本的なワークフロー
- アウトラインから始める：
[トピック]についての記事のアウトライン作成を手伝ってください
- リサーチと引用の追加：
[特定のトピック]をリサーチして、アウトラインに引用を追加してください
- フックの改善：
以下が私の導入部です。フックをもっと魅力的にするのを手伝ってください。
- セクションフィードバックの取得：
「なぜこれが重要なのか」のセクションが書き終わりました。レビューしてフィードバックをください。
- 推敲と仕上げ：
ドラフト全体の流れ、明瞭さ、一貫性をレビューしてください。
指示
ユーザーが執筆支援を求めた場合：
-
執筆プロジェクトを理解する
明確化のための質問をする：
- トピックと主な主張は？
- ターゲット読者は？
- 希望する長さやフォーマットは？
- 目的は？（教育、説得、娯楽、説明）
- 含めるべき既存のリサーチや情報源は？
- 執筆スタイルは？（フォーマル、カジュアル、技術的）
-
協調的なアウトライン作成
コンテンツの構造化を支援する：
# 記事アウトライン: [タイトル] ## フック - [冒頭の一文/ストーリー/統計] - [読者が気にかけるべき理由] ## 導入部 - 背景と文脈 - 問題の提示 - この記事で扱う内容 ## 本文セクション ### セクション1: [タイトル] - 重要なポイントA - 重要なポイントB - 例/証拠 - [リサーチ必要: 特定のトピック] ### セクション2: [タイトル] - 重要なポイントC - 重要なポイントD - 要データ/引用 ### セクション3: [タイトル] - 重要なポイントE - 反論 - 解決策 ## 結論 - 主要ポイントの要約 - 行動喚起 - 最後の考察 ## リサーチTo-Do - [ ] [トピック]に関するデータを見つける - [ ] [概念]の例を入手する - [ ] [主張]の引用元を明らかにするアウトラインの反復：
- フィードバックに基づいて調整
- 論理的な流れを確保
- リサーチのギャップを特定
- 深掘りするセクションにマーク
-
リサーチを実施する
ユーザーがトピックのリサーチを要求した場合：
- 関連情報を検索
- 信頼できる情報源を見つける
- 主要な事実、引用、データを抽出
- 要求されたフォーマットで引用を追加
出力例：
## リサーチ: AIが生産性に与える影響 主な発見: 1. **生産性向上**: コンテンツ作成タスクで40%の時間節約を示す研究 [1] 2. **採用率**: ナレッジワーカーの67%が週に一度はAIツールを使用 [2] 3. **専門家の引用**: 「AIは人間の創造性を置き換えるのではなく、強化する」 - ジェーン・スミス博士、MIT [3] 引用: [1] McKinsey Global Institute. (2024). "The Economic Potential of Generative AI" [2] Stack Overflow Developer Survey (2024) [3] Smith, J. (2024). MIT Technology Review インタビュー セクション2の下にアウトラインに追加されました。 -
フックの改善
ユーザーが導入部を共有したら、分析して強化する：
現状のフック分析:
- 良い点: [肯定的な要素]
- 改善できる点: [改善領域]
- 感情的なインパクト: [現在 vs. 可能性]
提案する代替案:
オプション1: [大胆な主張]
[例] なぜ効果的か: [説明]
オプション2: [個人的なストーリー]
[例] なぜ効果的か: [説明]
オプション3: [驚くべきデータ]
[例] なぜ効果的か: [説明]
フックへの質問:
- 好奇心を生み出しているか？
- 価値を約束しているか？
- 十分に具体的か？
- 読者に合っているか？
-
セクションごとのフィードバックを提供する
ユーザーが各セクションを書き上げるごとに、以下をレビューする：
# フィードバック: [セクション名] ## 良い点 ✓ - [強み1] - [強み2] - [強み3] ## 改善のための提案 ### 明瞭さ - [具体的な問題] → [修正案] - [複雑な文] → [よりシンプルな代替] ### 流れ - [遷移の問題] → [より良いつなぎ] - [段落の順序] → [提案する並べ替え] ### 証拠 - [裏付けが必要な主張] → [引用や例を追加] - [一般的な記述] → [より具体的にする] ### スタイル - [トーンの不整合] → [あなたの声により合うように] - [単語の選択] → [より強い代替案] ## 具体的な行の編集 原文: > [ドラフトからの正確な引用] 提案: > [改善版] なぜか: [説明] ## 検討すべき質問 - [考えさせる質問1] - [考えさせる質問2] 次のセクションに進む準備ができました！ -
書き手の声を保つ
重要な原則：
- スタイルを学ぶ: 既存の執筆サンプルを読む
- 提案し、置き換えない: 指示ではなく選択肢を提供する
- トーンを合わせる: フォーマル、カジュアル、技術的、フレンドリー
- 選択を尊重する: 彼らが自分のバージョンを好むなら、それを支援する
- 強化し、上書きしない: 違うものにするのではなく、より良くする
定期的に尋ねる：
- 「これはあなたらしく聞こえますか？」
- 「このトーンは適切ですか？」
- 「もっと/もっと少なく [フォーマル/カジュアル/技術的] にすべきですか？」
-
引用管理
ユーザーの好みに基づいて参考文献を扱う：
文中引用:
研究では40%の生産性向上が示されている（McKinsey, 2024）。番号付き参照:
研究では40%の生産性向上が示されている [1]。 [1] McKinsey Global Institute. (2024)...脚注スタイル:
研究では40%の生産性向上が示されている^1 ^1: McKinsey Global Institute. (2024)...引用リストを随時更新する：
## 参考文献 1. 著者. (年). "タイトル". 出版物. 2. 著者. (年). "タイトル". 出版物. ... -
最終レビューと仕上げ
ドラフトが完成したら、包括的なフィードバックを提供する：
# ドラフト全体のレビュー ## 総合評価 **強み**: - [主な強み1] - [主な強み2] - [主な強み3] **インパクト**: [全体的な有効性の評価] ## 構造と流れ - [構成に関するコメント] - [遷移の質] - [ペース配分の評価] ## コンテンツの質 - [議論の強さ] - [証拠の十分性] - [例の有効性] ## 技術的な質 - 文法と表記: [評価] - 一貫性: [評価] - 引用: [完全性チェック] ## 読みやすさ - 明瞭さのスコア: [評価] - 文の多様性: [評価] - 段落の長さ: [評価] ## 最終的な仕上げの提案 1. **導入部**: [具体的な改善点] 2. **本文**: [具体的な改善点] 3. **結論**: [具体的な改善点] 4. **タイトル**: [必要に応じた選択肢] ## 公開前チェックリスト - [ ] すべての主張に出典がある - [ ] 引用がフォーマットされている - [ ] 例が明確である - [ ] 遷移がスムーズである - [ ] 行動喚起が含まれている - [ ] 誤字脱字の校正が済んでいる 公開準備完了！ 🚀
例
例1: テレサ・トーレスのワークフロー
ユーザー: 「継続的発見についての記事を書いています。アウトライン作成を手伝ってください。」
プロセス:
- アウトライン構造について協力
- リサーチが必要な箇所を特定
- ユーザーが導入部を書き始める
- フックをレビューして改善
- ユーザーが各セクションを執筆
- 各セクション後にフィードバックを提供
- リサーチを実施し引用を追加
- 完成したドラフトの最終レビュー
- 公開に向けて仕上げと準備
結果: テレサの声で、しっかりした構造と流れを持ち、十分にリサーチされ適切に引用された記事。
例2: リサーチが重要な記事
ユーザー: 「AIがプロダクトマネジメントに与える影響について書いています。最新のデータや事例を見つけるのを手伝ってください。」
出力:
## 収集したリサーチ
### 最近のデータ
- Gartner: 2025年までにPMの80%がAIツールを使用 [1]
- 調査: 45%が機能リリースの迅速化を報告 [2]
- 事例: AirbnbのAI支援による優先順位付け [3]
### 専門家の引用
- 「AIはPMの判断を増幅するものであり、置き換えるものではない」 - マーティ・ケーガン
- [引用付きの追加引用]
### 実際の例
1. **A社**: ユーザーリサーチの統合にAIを使用
- 結果: 60%の時間節約
- 出典: [引用]
2. **B社**: AIを活用したロードマップ分析
- 結果: ステークホルダーとの調整が改善
- 出典: [引用]
すべて適切な引用とともにアウトラインに追加されました。
例3: フックの改善
ユーザーの元のフック:
"AIによってプロダクトマネジメントは変化しています。この記事では、AIがプロダクトマネージャーに影響を与えるいくつかの方法について説明します。"
改善された選択肢:
選択肢1 (データ駆動):
"先月、私はAIに500件の顧客インタビューを分析させました。3週間ではなく30分で終わりました。プロダクトマネジメントはもう以前と同じではありません。"
選択肢2 (質問):
"朝のコーヒーを飲む前に、すべての顧客と話し、すべてのレビューを読み、すべてのサポートチケットを分析できるとしたらどうでしょうか？"
選択肢3 (ストーリー):
"サラは間違った機能を作るのに2週間費やしました。ユーザーを理解していなかったからではなく、何百ものインタビューを処理してパターンを見つけるのが速くなかったからです。"
例4: セクションフィードバック
ユーザー: 「『よくある失敗』のセクションが書き終わりました。どう思いますか？」
応答:
# フィードバック: よくある失敗セクション
## 良い点 ✓
- 強い例（Slack通知のストーリー）
- 明確な構造（3つの失敗、すっきりしたレイアウト）
- 各失敗に対する実践的なアドバイス
## 提案
### より具体的にする
2つ目のポイントの「悪い優先順位付け」はもっと強くできます：
現在:
> "多くのチームは、アウトカムではなく機能に焦点を当てることで優先順位を誤ります。"
提案:
> "ある四半期に14の機能をリリースしながら、主要な指標が一つも動かなかったチームを見てきました。彼らは進捗よりも活動を優先したのです。"
### データを追加
3つ目の失敗は証拠があるとより良くなります：
> "[引用を追加]: 定期的なユーザーコンタクトがないチームは、未使用の機能を構築する可能性が3倍高いという研究があります [要出典]"
### 流れの改善
順序の再考を: 失敗3 → 失敗2 → 失敗1
これは小さなインパクトから大きなインパクトへと構築されます。
次のセクションの準備ができました！
執筆ワークフロー
ブログ記事ワークフロー
- 一緒にアウトライン
- 重要なポイントをリサーチ
- 導入部を書く → フィードバックを得る
- 本文セクションを書く → それぞれにフィードバック
- 結論を書く → 最終レビュー
- 仕上げと編集
ニュースレターワークフロー
- フックのアイデアを議論
- 短いアウトライン（より短い形式）
- 一度のセッションでドラフト
- 明瞭さとリンクをレビュー
- 素早く仕上げ
技術チュートリアルワークフロー
- 手順のアウトライン
- コード例を書く
- 説明を追加
- 指示をテスト
- トラブルシューティングセクションを追加
- 正確さの最終レビュー
ソートリーダーシップワークフロー
- ユニークな角度をブレスト
- 既存の視点をリサーチ
- 自分のテーゼを発展させる
- 強い視点で書く
- 裏付けとなる証拠を追加
- 説得力のある結論を作成
プロのヒント
- VS Codeで作業する: 長文執筆にはWeb版Claudeより優れている
- 一度に一つのセクション: 段階的にフィードバックを得る
- リサーチを別に保存: research.mdファイルを保持する
- ドラフトのバージョン管理: article-v1.md、article-v2.mdなど
- 音読する: フィードバックを利用してぎこちない文を見つける
- 締め切りを設定する: 「今日ドラフトを終わらせたい」
- 休憩を取る: 書く、フィードバックを得る、一時停止する、修正する
ファイル構成
執筆プロジェクトの推奨構造：
~/writing/article-name/
├── outline.md # アウトライン
├── research.md # すべてのリサーチと引用
├── draft-v1.md # 初稿
├── draft-v2.md # 改訂稿
├── final.md # 公開準備完了
├── feedback.md # 収集したフィードバック
└── sources/ # 参考資料
├── study1.pdf
└── article2.md
ベストプラクティス
リサーチのために
- 引用前に情報源を検証する
- 可能な限り最新のデータを使用する
- 異なる視点のバランスを取る
- 元の情報源にリンクする
フィードバックのために
- 何が欲しいか具体的に: 「これは技術的すぎますか？」
- 懸念を共有する: 「このセクションがだらだらしているのが心配です」
- 質問をする: 「これは論理的に流れていますか？」
- 代替案を求める: 「これを説明する別の方法はありますか？」
声のために
- 自分の執筆例を共有する
- トーンの好みを指定する
- うまく合っているものを指摘する: 「それは私みたいに聞こえます！」
- 不一致を知らせる: 「自分のスタイルにはフォーマルすぎます」
関連するユースケース
- 記事からソーシャルメディア投稿を作成する
- 異なる読者向けにコンテンツを適応させる
- メールニュースレターを書く
- 技術文書の起草
- プレゼンテーションコンテンツの作成
- ケーススタディの執筆
- コースアウトラインの作成