コンテンツリサーチライター は何をしますか？
このスキルはあなたのライティングパートナーとして機能し、リサーチ、アウトライン作成、下書き、推敲を通じて、あなた独自の声とスタイルを維持しながらコンテンツ作成を支援します。
このスキルを使用するタイミング
- ブログ記事、記事、ニュースレターの作成
- 教育コンテンツやチュートリアルの作成
- 思想的リーダーシップ記事の執筆
- ケーススタディのリサーチと作成
- 出典付きの技術文書の作成
- 適切な引用と参考文献を用いた作成
- フック（導入部）とイントロダクションの改善
- 執筆中のセクションごとのフィードバックの取得
このスキルの機能
- 協調的なアウトライン作成: アイデアを一貫性のあるアウトラインに構造化するのを支援
- リサーチアシスタンス: 関連情報を検索し、引用を追加
- フックの改善: 読者の注意を引くために冒頭を強化
- セクションフィードバック: 各セクションを執筆中にレビュー
- 声の維持: あなたの書き方のスタイルとトーンを維持
- 引用管理: 参考文献を適切に追加およびフォーマット
- 反復的な推敲: 複数の下書きを通じて改善を支援
使用方法
執筆環境のセットアップ
記事専用のフォルダを作成します:
mkdir ~/writing/my-article-title
cd ~/writing/my-article-title
下書きファイルを作成します:
touch article-draft.md
このディレクトリからClaude Codeを開き、執筆を開始します。
基本的なワークフロー
- アウトラインから始める:
[topic]に関する記事のアウトラインを作成してください。
- リサーチと引用の追加:
[specific topic]についてリサーチし、アウトラインに引用を追加してください。
- フックの改善:
これが私のイントロダクションです。フックをもっと魅力的にするのを手伝ってください。
- セクションフィードバックの取得:
「なぜこれが重要なのか」セクションを書き終えました。レビューしてフィードバックをください。
- 推敲と仕上げ:
下書き全体をフロー、明瞭さ、一貫性についてレビューしてください。
指示
ユーザーが執筆支援をリクエストした場合:
-
執筆プロジェクトを理解する
明確化の質問をする:
- トピックと主な主張は何ですか？
- 対象読者は誰ですか？
- 希望する長さや形式は？
- 目標は何ですか？（教育、説得、娯楽、説明）
- 含める既存のリサーチや出典はありますか？
- 書き方のスタイルは？（フォーマル、カジュアル、テクニカル）
-
協調的なアウトライン作成
コンテンツの構造化を支援する:
# 記事アウトライン: [タイトル] ## フック - [導入の一文/ストーリー/統計] - [読者が関心を持つべき理由] ## イントロダクション - 背景と文脈 - 問題提起 - この記事の内容 ## 主要セクション ### セクション1: [タイトル] - 要点A - 要点B - 例/証拠 - [リサーチが必要: 特定のトピック] ### セクション2: [タイトル] - 要点C - 要点D - データ/引用が必要 ### セクション3: [タイトル] - 要点E - 反論 - 解決策 ## 結論 - 主要なポイントのまとめ - 行動喚起 - 最後の考え ## リサーチTODO - [ ] [topic]に関するデータを見つける - [ ] [concept]の例を入手する - [ ] [claim]の引用元を探すアウトラインを反復する:
- フィードバックに基づいて調整
- 論理的な流れを確保
- リサーチギャップを特定
- 深掘りするセクションにマーク
-
リサーチの実施
ユーザーが特定のトピックについてリサーチをリクエストした場合:
- 関連情報を検索
- 信頼できる情報源を見つける
- 主要な事実、引用、データを抽出
- 要求された形式で引用を追加
出力例:
## リサーチ: AIの生産性への影響 主な発見: 1. **生産性の向上**: コンテンツ作成タスクで40%の時間節約を示す研究 [1] 2. **導入率**: 67%のナレッジワーカーが毎週AIツールを使用 [2] 3. **専門家の引用**: 「AIは人間の創造性を強化するのであって、置き換えるものではない」— Dr. Jane Smith, 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: Teresa Torresのワークフロー
ユーザー: 「継続的ディスカバリーについての記事を書いています。アウトラインを作成してください。」
プロセス:
- アウトライン構造で協力
- リサーチニーズを特定
- ユーザーがイントロダクションの執筆を開始
- フックをレビューして改善
- ユーザーが各セクションを執筆
- 各セクション後にフィードバックを提供
- リサーチを実施し引用を追加
- 下書き全体の最終レビュー
- 仕上げと公開準備
結果: Teresaの声で書かれ、強力な構造とフローを持つ、十分にリサーチされ適切に引用された記事。
例2: リサーチ中心の記事
ユーザー: 「プロダクトマネジメントへのAIの影響について書いています。最新のデータと例を探してください。」
出力:
## リサーチ結果
### 最近のデータ
- Gartner: 2025年までにPMの80%がAIツールを使用する [1]
- 調査: 45%が機能提供の高速化を報告 [2]
- ケーススタディ: AirbnbのAI支援による優先順位付け [3]
### 専門家の引用
- 「AIはPMの判断を増幅し、置き換えるものではない」 - Marty Cagan
- [引用付きの追加の引用]
### 実際の例
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よりも優れている
- 一度に1セクション: 段階的にフィードバックを得る
- リサーチは別に保存: 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
ベストプラクティス
リサーチについて
- 引用する前に情報源を検証する
- 可能な場合は最新のデータを使用する
- 異なる視点のバランスを取る
- 元の情報源にリンクする
フィードバックについて
- 何が欲しいか具体的に言う: 「これは難しすぎますか？」
- 懸念を共有する: 「このセクションがだらだらしているのが心配です」
- 質問する: 「これは論理的に流れていますか？」
- 代替案をリクエストする: 「これを説明する別の方法はありますか？」
声について
- あなたの執筆例を共有する
- トーンの好みを指定する
- 良いマッチングを指摘する: 「それは私らしいですね！」
- ミスマッチをフラグする: 「私のスタイルにはフォーマルすぎます」
関連するユースケース
- 記事からソーシャルメディア投稿を作成する
- 異なる読者向けにコンテンツを適応させる
- メールニュースレターの作成
- 技術文書の下書き
- プレゼンテーションコンテンツの作成
- ケーススタディの作成
- コースアウトラインの作成