Xのブックマーク整理はAIで自動化。要約からナレッジ化まで

Xのブックマーク整理が続かない原因は、フォルダ分けや外部アプリへの移し替えという手作業そのものにあります。答えは、人が整理するのをやめること。保存した投稿をAIが自動で取得し、日本語で要約しタグを付け、検索できるナレッジとして保存する仕組みに任せれば、人の仕事はブックマークの1タップだけになります。

僕はこの仕組みを2026年5月末から自分のMacで実運用しています。約3か月で1,064件のブックマークが、全件要約とタグ付きで蓄積されました。この記事では、その中身と実運用でしか分からなかった注意点を公開します。

Xのブックマーク整理が続かないのはなぜか

フォルダ分けも外部アプリも「手作業」が残る

検索で出てくるXのブックマーク整理術は、大きく3パターンです。有料プランのフォルダ機能で分類する、不要なブックマークを定期的に削除する、NotionなどのメモアプリやDeweyのような外部ツールに移し替える。どれも1件ずつなら正しい方法です。

問題は、3つとも「人が手を動かし続ける」前提で設計されていることです。ブックマークは移動中や会議の合間に、1日に何件も雑に押すもの。その1件ごとに「どのフォルダに入れるか」「どのアプリに写すか」の判断と操作を要求される整理術は、忙しい週に必ず止まります。僕自身、フォルダ分けは3日で放置しました。

保存しても、探せなければ存在しないのと同じ

もう1つの構造的な問題は検索性です。Xのブックマーク一覧は時系列に並ぶだけなので、1か月前に保存した投稿を探すには延々スクロールするしかありません。

検索できないストックは、無いのと同じです。「あの投稿、確かブックマークしたはず」が見つからない体験を数回すると、人はブックマークを見返すこと自体をやめます。溜まる一方で見返されない、という検索者の悩みはこうして生まれます。

「整理する」のをやめて、AIで自動的にナレッジ化する

人の仕事はブックマークの1タップだけ

発想を変えます。整理を頑張るのではなく、整理という工程を人の手から外します。

僕が運用している仕組みでは、人がやることは「いいなと思った投稿をブックマークする」の1タップだけです。あとはAPI（プログラムからサービスの機能を呼び出す窓口）経由で機械が1時間毎にブックマークを取りに行き、AIが日本語で要約してタグを付け、検索できる形式で保存します。人間の仕事はブックマークの1タップまで。以降の工程に人手が1つでも入ると、その仕組みはどこかで必ず止まります。

実運用3か月の実測

この仕組みの索引ファイルの先頭には、自動集計がこう記録されています。

Total: 1064 / Summarized: 1064

（索引ファイル冒頭の自動集計。2026年8月20日時点）

運用開始から約3か月で1,064件。要約済み率は100%です。直近は月300件以上のペースでブックマークしていますが、僕は整理作業を1分もしていません。雑に保存した英語の技術投稿も、1時間後には日本語の要約とタグが付いた状態で検索対象に入っています。

一番効いているのは、保存の瞬間に「これをどう分類するか」を考えなくていいことなんですよね。判断を後回しにするのではなく、判断そのものをAIに渡す。ブックマークを押す心理的コストがゼロになったので、情報の入口が広がりました。

収集から要約、保存まで。自動化の3ステップ

仕組みの本体は、次の3ステップの繰り返しです。

実運用で分かった3つの注意点

作ってみて初めて分かった制約が3つあります。ここが検索しても出てこない部分です。

注意点1: APIで遡れるのは直近800件まで

X APIで取得できるブックマークは、実運用で確認した範囲で直近800件までです。それより古いブックマークは、APIをどう叩いても返ってきません。

つまり、何年も溜めてきた人ほど「救い出せない過去」を既に抱えています。僕が初回取得を走らせたときも、取れたのは直近分だけでした。溜め込むほど、救えない過去が増えていく。これが、この仕組みを今すぐ始めるべき一番の理由です。

注意点2: 「ブックマークした日時」はAPIで取れない

意外な落とし穴ですが、APIのレスポンスには投稿の作成日時はあっても、自分がそれをブックマークした日時が含まれません。「いつ保存したか」で並べたり月別に整理したりするには、この日時が必要なのに、です。

僕の設計では、仕組みが最初にその投稿を観測した時刻を「ブックマーク日時の代替」として台帳に記録しています。1時間毎に取得しているので、誤差は最大でも約1時間。月別フォルダの整理にはこれで十分でした。

注意点3: 取得コストは差分設計で抑える

APIの利用には回数制限と従量的なコストが付きまといます。1時間毎に毎回全件を取得する設計にすると、読み取り量が無駄に膨らみます。

対策がステップ1の早期停止です。新しい順に見ていき、既知のIDに当たったら即打ち切る。この設計だと、新規ブックマークがない時間帯の実行は先頭の数件を確認するだけで終わります。1時間毎という高頻度ポーリングと低コストは、差分設計にすることで両立できます。

溜めたナレッジを情報収集の自動化につなげる

RAG投入で「あの話どこだっけ」が1つの質問になる

Markdownで溜めるだけでも検索性は劇的に上がりますが、僕はさらにRAG（溜めた文書をAIが検索して答えに使う仕組み）へ自動投入しています。

これで何が変わるかというと、Xのブックマークが、YouTube動画の文字起こしや会議メモなど他のナレッジと一緒に横断検索できる資産になります。「エージェントの評価手法について、最近保存した情報を出して」と1回聞けば、出どころがXでも動画でも関係なく答えが返る状態です。SNSで偶然出会った情報が、保存した瞬間から会社の検索できる資産に変わります。溜めたナレッジを検索して使う側の設計は、次の記事に分けて書いています。

関連記事社内ナレッジをAIで検索可能にする。RAG導入の実運用社内ナレッジをAIで検索可能にする方法を実運用ベースで解説します。会議録画・議事録・講座資料を人手ゼロで取り込む仕組み、機密の線引き、検索対象の分離とリランク検索で精度を上げる運用、導入5ステップを紹介します。→

情報収集の自動化はAIで役割分担して組む

情報収集の自動化をAIで組むとき、僕は入口ごとに仕組みを分けています。この記事の仕組みが担うのは「SNSで偶発的に出会った情報を確実に資産へ落とす」取り込み側だけです。

• テーマを決めて毎朝取りに行く定点リサーチはClaude Codeで情報収集を自動化する仕組み

• 学習動画を文字の資産に変えるのはYouTube文字起こしの自動化

• 集めた知見をSNSへ発信する側の分業はSNS運用のAI自動化

偶発的な出会い（ブックマーク）と計画的な収集（定点リサーチ）は性質が違うので、1つの仕組みに詰め込まず分けたほうが、それぞれが止まりにくくなります。

Xのブックマーク整理でよくある質問

まとめ。整理をやめた日から、ブックマークは資産になる

Xのブックマーク整理は、頑張り方を変えるのではなく、人が整理すること自体をやめるのが答えです。ポイントを3つに絞ります。

• フォルダ分けも外部アプリへの転記も、手作業が残る限り必ず止まる。人の仕事はブックマークの1タップだけに減らす

• 仕組みは「1時間毎の差分取得→AIの日本語要約とタグ分類→Markdown保存と索引生成」の3ステップ。差分設計で取得コストを抑える

• APIで遡れるのは直近800件まで。溜め込むほど救えない過去が増えるので、始めるなら早いほうがいい

保存した情報を資産に変える出口は検索です。僕の場合はRAG投入まで自動化したことで、Xで拾った知見が経営判断や記事執筆の材料としてそのまま引き出せるようになりました。