Raindrop.ioでリサーチフローを設計する:情報収集から記事執筆までの一連の流れ

タスク・プロジェクト管理

※本記事にはアフィリエイトリンクが含まれます。

「ブックマーク管理ツールを入れました」だけで終わっていたら、たぶん3ヶ月で使わなくなっていた。

Raindrop.ioを使い始めて最初に感じたのは「とりあえず保存できるようになったけど、で、どうやって使うの?」だった。ブックマークが貯まるだけで、記事執筆のフローとつながっていなかった。

実際に記事制作の流れに組み込んで、月10〜15本ペースで半年使ってみたら、リサーチ時間が以前より25〜30%短縮された。何を変えたかをそのまま書く。

この記事でわかること:

  • リサーチのどこがボトルネックだったか
  • Raindrop.ioでフローを設計する具体的な手順
  • Raindrop.io → Obsidian → Claudeという一連のパイプライン
  • このフローで変わったこと・期待外れだったこと

Raindrop.ioの基本機能や登録手順はRaindrop.ioの使い方入門に書いたので、機能説明はそちらを参照してほしい。この記事では「どう使うか」の話に集中する。

freelance research workflow raindrop
Photo by Bluestonex on Unsplash

リサーチのボトルネックはどこにあったか

「あの記事どこだっけ」問題が週2〜3回起きていた

Raindrop.ioを使う前のリサーチフローはこうだった。

Perplexityで調べる → 参考になりそうな記事をChromeでブックマーク → 執筆するときに「あの記事どこに保存したっけ」と探し直す → 見つからなければ再度検索して探す。

これが毎回どこかで詰まっていた。Chromeのブックマークが300件を超えた頃から「あの記事どこだっけ」が週に2〜3回起きるようになり、1回の検索・再確認で5〜15分が消えた。

月10本の記事を書くと、このロスが月2〜3時間になる計算だ。

ブラウザのブックマークはリサーチに向いていない

ブラウザのブックマークには検索機能はあるが、タイトルしか検索できない。「あの料金プランが書いてあった公式記事」みたいな探し方ができない。

タグも使えるが、Chromeのブックマークのタグ機能は弱く、横断検索がしにくい。フォルダに入れると階層が深くなって探しづらくなる。

「ブックマークは保存するだけで再利用しない」という状況になっていた。リサーチ素材が死蔵されていた。

Raindrop.ioでフローを設計する:入り口から出口まで

コレクションの設計:記事テーマ別か、ジャンル別か

最初に試したのは「記事テーマ別のコレクション」だった。「n8nの料金記事」「Makeのエラー処理記事」みたいに、制作する記事ごとにコレクションを作る方式。

2週間でやめた。コレクションが記事本数分増えていくので、使い終わったコレクションが残り続けてゴミになった。どのコレクションが現在進行中でどれが終わったのかわからなくなった。

今の設計はもっとシンプルだ。

コレクション 用途
リサーチ中 現在書いている記事のリサーチ素材
ストック 近い将来使いそうな素材・参考資料
後で読む まだ内容を確認していないもの(翌日に処理する前提)
アーカイブ 使い終わり・古くなったもの

状態ベースの設計にしたことで、「どこに入れるか」の判断が速くなった。

タグルール:少ない種類で横断検索できる設計にする

タグはコレクションを横断する軸として使う。ツール名と大カテゴリの2種類だけ使う。

  • ツール名タグ:#n8n #make #obsidian #raindrop #claude #perplexity など
  • カテゴリタグ:#automation #writing #knowledge-management #pricing など

タグの種類は全部で15〜20種類に絞る。それ以上増やすと管理が崩壊する(経験談)。

新しいツールを書く記事が増えたら、そのツール名タグを1つ追加するだけでいい。カテゴリタグは増やさない。

「後で読む」の扱いがフローの鍵だった

「後で読む」コレクションを作ったはいいが、最初の2ヶ月で80件以上が未読のまま溜まった。完全に墓場になった。

解決策は「後で読む」コレクションに上限を設けることだった。20件を超えたら古いものを削除する、というルールにした。

これがポイントで、「後で読む」は「いつかたぶん読む」ではなく「翌日以内に読む」という意味で使う前提にした。今日保存した記事は明日のリサーチ作業で読む。読まないなら削除するか「ストック」に移す。

保存したときの自分が「これは役に立つ」と思ったとしても、2週間後の自分には無関係なことが多い。「後で読む」は消費期限付きで使うと管理しやすくなった。

Raindrop.io → Obsidian → Claudeの一連の流れ

research pipeline obsidian claude
Photo by Kelly Sikkema on Unsplash

Raindrop.ioで素材を貯める段階でやること

リサーチ中に記事や公式ドキュメントを見つけたら、拡張機能でワンクリックしてRaindropに保存する。この時点でタグだけ付けて「リサーチ中」コレクションに入れる。

タグを付けるのは10秒程度の作業で、後で検索したときに使うためだけのもの。コメントや要約は書かない。書き始めると保存の手間が増えて「まあいいか」になる。

1記事で10〜15件のブックマークが溜まったら、次のObsidian段階に移る。

Obsidianに移す判断基準:「一次情報として残す価値があるか」

Raindropに貯めたすべてのブックマークをObsidianに移すわけではない。

Obsidianに移すのは「一次情報として手元に残しておく価値があるもの」だけ。具体的には:

  • 公式ドキュメントの該当箇所(料金・仕様・制限など変わりやすい情報)
  • 自分が実際に使ったときの生メモ(「この設定で詰まった」「この機能は使えなかった」)
  • 複数の記事で再利用できそうな統計・調査データ

URLだけ保存すればいいもの(読んで参考にしたが再利用不要な記事)はRaindropに残す。

Obsidianへの移し方は単純で、URLを開いて本文の必要な部分をコピー → Obsidianの新しいノートに貼る → タグだけ付けて終わり。整理はしない。詳細はObsidianをAIに食わせる前の置き場にしたに書いた。

Claudeに渡す前の整理:構造化しすぎない

いよいよ執筆段階でClaudeに素材を渡すとき、最初は「整理してからのほうがいいだろう」と思ってサマリーを作っていた。

でも、Obsidianのノートをそのままコピーして貼り付けるほうが出力の質が高かった。

理由は単純で、サマリーを作る時点で「自分のフィルター」が入るから。情報を整理・要約すると、取捨選択が発生して元の情報が削られる。AIに渡す前に情報を絞ると、AIは残った情報しか使えない。

生のMarkdownをそのまま渡すと、Claudeが文脈を読んで必要な情報を選んでくれる。僕が整理する時間も省けるし、出力の質も上がる。

Perplexity Proに渡す場合は、URLリストを渡すとPerplexityが参照して最新情報と突き合わせてくれるので、少し違う使い方になる。

フロー設計で失敗したこと・やり直したこと

参考のために、うまくいかなかったパターンも書いておく。

失敗1:「後で読む」を溜め込みすぎた

最初は「後で読む」に上限を設けていなかった。その結果、2ヶ月後に83件が未読のまま溜まった。Raindropを開くたびに「ああ、未読が増えている」というプレッシャーがかかり始めて、Raindropを開かなくなった。

解決策は先述の通り、上限を20件に設定して消費期限を設けること。これをやってからRaindropを開くのが苦にならなくなった。

失敗2:記事ごとにコレクションを作った

「n8n料金記事用」「Make比較記事用」とコレクションを記事単位で作った。記事を書く度にコレクションが増え、使い終わったコレクションが残り続けた。

3ヶ月後にコレクションが22個になっていて、「このコレクションは何用だったっけ」という状態になった。全部削除して状態ベースの4コレクション設計に作り直した。

失敗3:タグを付けすぎた

「もっと細かく分類したほうが後で検索しやすい」と思って、タグを30種類以上作った。「#n8n-pricing」「#n8n-error」「#n8n-integration」みたいにツール×トピックでタグを細分化した。

2週間後に「これを付けるとき#n8n-pricingじゃなくて#n8n-priceだったか?」という混乱が毎回起きるようになった。タグを探すために別のアプリを見るという本末転倒が発生して、タグ管理を一度リセットした。

今は「ツール名は英小文字」「カテゴリは5〜7種類に絞る」というルールだけ決めている。少なすぎても検索ができないが、多すぎても管理コストが増える。

このフローに変えて変わったこと・変わらなかったこと

変わったこと:

  • リサーチから執筆開始までの時間が45分前後から25〜30分に短縮(月換算で3〜4時間の節約)
  • 「あの記事どこだっけ」という探し物がほぼゼロになった
  • 2〜3ヶ月前に調べた情報が再利用できるようになった(特に価格・仕様変更の追跡に使える)
  • Raindrop.io + Obsidianの組み合わせで、リサーチ素材の「鮮度管理」ができるようになった

変わらなかったこと・期待外れだったこと:

  • リサーチ自体の速度は変わらない(そこはPerplexityの問題)
  • タグの一貫性を保つのは今も難しい。2ヶ月経ってもタグの運用が崩れることがある
  • Raindrop.ioのAIアシスタント(有料版機能)は試したが、正直そこまで使っていない。ClaudeへのコピペのほうがAI活用としては効果的だった

期待値の調整として言っておくと、Raindrop.ioはあくまで「素材を貯める・探す」ためのツールだ。記事の質を上げるのはリサーチの中身の問題で、Raindropは道具として機能するだけ。

フローを安定して維持するために意識していること

フローは設計しただけでは崩れる。3ヶ月後に「気づいたら使わなくなっていた」を防ぐために、今も続けていることがある。

週1回のRaindrop整理を固定する

「後で読む」コレクションを週1回だけ見直す。未読のものを読んで「リサーチ中」か「ストック」に移すか削除する。この作業を週5分・月曜の朝に固定したことで、コレクションが腐らなくなった。

「いつかやる」では機能しない。「月曜朝にやる」まで具体化して初めて継続できた。

タグ運用のリセットを年1回許容する

半年使い続けると、タグの一貫性がどこかで崩れる。「#n8n」と「#N8N」が混在したり、「#pricing」と「#price」が両立したりする。

これを毎回直そうとするとコストが高すぎる。年1回、タグを一括で見直して統一するタイミングを設けることにした。完璧なタグ運用を目指すより「年1回のリセットで十分」と割り切ったほうが精神的に楽だ。

素材の「賞味期限」を意識して捨てる

ツールの料金・機能仕様は変わる。3ヶ月以上前に保存したRaindropのブックマークは「情報が古くなっている可能性がある」と思いながら使う習慣をつけた。

Raindropのアーカイブ機能は「使い終わったもの」だけでなく「情報が古くなったと判断したもの」にも使う。アーカイブに入れても削除はしない。古い情報でも当時の状況確認には使えることがあるから。

raindrop obsidian workflow freelance
Photo by Bernd Dittrich on Unsplash

まとめ:ブックマーク管理はフローの設計次第で別物になる

ツールを入れるだけでは変わらない。フローに組み込んで初めて効果が出る。

Raindrop.ioを使うなら:
1. コレクションはシンプルに状態ベースで設計する
2. タグは15〜20種類に絞る
3. 「後で読む」は翌日中に処理するルールで使う
4. 素材はRaindrop.io(URL管理)とObsidian(一次情報ストック)で役割を分ける

この設計にしてから、ブックマーク管理が「貯めるだけのもの」から「リサーチの一部」になった。

Raindrop.ioの基本機能・登録方法はRaindrop.ioの使い方入門を先に読んでほしい。


合わせて読みたい
Raindrop.ioの使い方入門:フリーランスのリサーチを効率化するブックマーク管理ツール
ObsidianをAIに食わせる前の置き場にした:リサーチ素材を一次情報のまま貯める方法

コメント

タイトルとURLをコピーしました