Redbook — Xiaohongshu CLI

redbook CLI を使用して、Xiaohongshu (小红书/RED) でノートを検索し、コンテンツを読み込み、クリエイターを分析し、エンゲージメントを自動化し、トピックをリサーチします。

OpenClaw ユーザー: clawhub install redbook または npm install -g @lucasygu/redbook でインストール。

使用方法

/redbook search "AI編程"              # ノートを検索
/redbook read <url>                   # ノートを読む
/redbook user <userId>                # クリエイターのプロフィール
/redbook analyze <userId>             # 完全なクリエイター分析 (プロフィール + 投稿)

クイックリファレンス

目的	コマンド
ノートを検索	redbook search "keyword" --json
ノートを読む	redbook read <url> --json
コメントを取得	redbook comments <url> --json --all
クリエイタープロフィール	redbook user <userId> --json
クリエイターの投稿	redbook user-posts <userId> --json
フィードを閲覧	redbook feed --json
ハッシュタグを検索	redbook topics "keyword" --json
バイラルノートを分析	redbook analyze-viral <url> --json
コンテンツテンプレートを抽出	redbook viral-template <url1> <url2> --json
コメントを投稿	redbook comment <url> --content "text"
コメントに返信	redbook reply <url> --comment-id <id> --content "text"
一括返信 (プレビュー)	redbook batch-reply <url> --strategy questions --dry-run
ノートをいいね	redbook like <url>
いいねを取り消す	redbook like <url> --undo
お気に入りをリスト表示	redbook favorites --json または redbook favorites <userId> --json
ノートを保存	redbook collect <url>
保存から削除	redbook uncollect <url>
フォロワーをリスト表示	redbook followers <userId> --json
フォロー中をリスト表示	redbook following <userId> --json
自分のノートを削除	redbook delete <url>
ノートのヘルスチェック	redbook health --json または redbook health --all --json
ユーザーボードをリスト表示	redbook boards または redbook boards <userId> --json
アルバムのノートをリスト表示	redbook board <board-url> または redbook board <boardId> --json
マークダウンをカードにレンダリング	redbook render content.md --style xiaohongshu
画像ノートを投稿	redbook post --title "..." --body "..." --images img.jpg
接続を確認	redbook whoami

プログラム的に出力を解析する場合は常に --json を追加してください。 これがない場合、出力は人間向けのテキスト形式になります。

---

XHS プラットフォーム シグナル

XHS は Twitter や Instagram ではありません。これらのプラットフォーム固有のエンゲージメント比率は、コンテンツタイプとオーディエンスの行動を示します。

保存/いいね比率 (collected_count / liked_count)

XHS の「保存」(收藏) はあとで読むメカニズムです。ユーザーは個人的なリファレンスライブラリを構築します。この比率はコンテンツの有用性を示す最も強いシグナルです。

比率	分類	意味
>40%	工具型 (リファレンス)	チュートリアル、チェックリスト、テンプレート — ユーザーが再利用のためにブックマーク
20–40%	认知型 (インサイト)	考えさせるが、あとで読むために保存されない
<20%	娱乐型 (エンターテイメント)	消費されて忘れられる — エンゲージメントは受動的

コメント/いいね比率 (comment_count / liked_count)

ノートがどの程度の会話を生成するかを測定します。

比率	分類	意味
>15%	讨论型 (ディスカッション)	議論、経験の共有、質問
5–15%	正常互动 (通常)	典型的なエンゲージメント パターン
<5%	围观型 (受動的)	ユーザーはいいねするが、さらにエンゲージしない

シェア/いいね比率 (share_count / liked_count)

社交的通貨を測定します。ユーザーが身元を示すか他人を助けるためにシェアするかどうか。

比率	意味
>10%	社交货币 — ユーザーが好みや身元、または友人を助けるためにシェア
<10%	個別に消費されて転送されないコンテンツ

検索ソート セマンティクス

ソート	意味
--sort popular	証明されたシーリング — キーワードが達成できる最良の結果
--sort latest	コンテンツ速度 — 現在どの程度投稿されているか
--sort general	アルゴリズム加重ブレンド (デフォルト)

コンテンツ形式のダイナミクス

形式	傾向
图文 (画像テキスト、type: "normal")	保存率が高い — ユーザーがリファレンス コンテンツを保存
视频 (ビデオ、type: "video")	いいね率が高い — 受動的に消費するのが簡単

---

分析モジュール

各モジュールは構成可能な構成要素です。異なる分析の深さで組み合わせます。

モジュール A: キーワード エンゲージメント マトリックス

回答: どのキーワードが最もエンゲージメントのシーリングを持っていますか? どれが飽和しているか、ニーズを満たしていませんか?

コマンド:

redbook search "keyword1" --sort popular --json
redbook search "keyword2" --sort popular --json
# リスト内の各キーワードについて繰り返す

各結果の items[] から抽出するフィールド:

• items[].note_card.interact_info.liked_count — いいね (中国語数字の場合もあります: "1.5万" = 15,000)
• items[].note_card.interact_info.collected_count — 保存
• items[].note_card.interact_info.comment_count — コメント
• items[].note_card.user.nickname — 作成者

解釈方法:

• Top1 シーリング = items[0] いいね — このキーワードの最も良いパフォーマンスのノート。これは証明されたデマンドシグナルです。
• Top10 平均 = items[0..9] 全体のいいねの平均 — 平均的なトップノートがどの程度パフォーマンスするか。
• Top1 が高く Top10 avg が低い場合 = 1 つのアウトライアーが支配している。競争するのは難しい。
• Top10 avg が高い場合 = 一貫したデマンド。参入しやすい。

出力: キーワード × エンゲージメント テーブル (Top1 シーリングでランク付け)

キーワード	Top1 いいね	Top10 平均	Top1 保存	保存/いいね
keyword1	12,000	3,200	5,400	45%
keyword2	8,500	4,100	1,200	14%

---

モジュール B: クロストピック ヒートマップ

回答: どのトピック × シーン交差点にニーズがありますか? コンテンツギャップはどこにありますか?

コマンド:

# ベーストピックをシーン/アングルキーワードと組み合わせる
redbook search "base topic + scene1" --sort popular --json
redbook search "base topic + scene2" --sort popular --json
redbook search "base topic + scene3" --sort popular --json

抽出するフィールド: モジュール A と同じ — 各組み合わせの Top1 liked_count。

解釈方法:

• Top1 が高い = この交差点のニーズが証明されている
• ゼロまたは非常に低い結果 = コンテンツ ギャップ (機会またはニーズなし — 組み合わせが合理的かどうか確認)
• シーン全体で比較して、どのアングルがベース トピックで最も響くかを見つける

出力: ベース × シーン ヒートマップ

             scene1    scene2    scene3    scene4
base topic   ████ 8K   ██ 2K     ████ 12K  ░░ 200

---

モジュール C: エンゲージメント シグナル分析

回答: 各キーワードはどのようなコンテンツですか? リファレンス、インサイト、またはエンターテイメント?

コマンド: モジュール A からの検索結果を使用、または単一ノートの場合:

redbook analyze-viral "<noteUrl>" --json

抽出するフィールド:

• 検索結果から: interact_info フィールドから比率を計算
• analyze-viral から: 事前計算されたフィールド engagement.collectToLikeRatio、engagement.commentToLikeRatio、engagement.shareToLikeRatio を使用

解釈方法: XHS プラットフォーム シグナル の比率ベンチマークを適用。

出力: キーワードまたはノートごとの分類

キーワード	保存/いいね	コメント/いいね	タイプ
keyword1	45%	8%	工具型 + 正常互动
keyword2	12%	22%	娱乐型 + 讨论型

---

モジュール D: クリエイター発見とプロファイリング

回答: このニッチのキークリエイターは誰ですか? 彼らの戦略は何ですか?

コマンド:

# 1. キーワード全体の検索結果から一意の user_ids を収集
#    items[].note_card.user.user_id から抽出

# 2. 各クリエイターについて:
redbook user "<userId>" --json
redbook user-posts "<userId>" --json

抽出するフィールド:

• user から: interactions[] where type === "fans" → フォロワー数
• user-posts から: notes[].interact_info.liked_count すべての投稿について → 平均、中央値、最大値を計算
• user-posts から: notes[].display_title → コンテンツパターン、投稿頻度

解釈方法:

• 平均 対 中央値: 大きなギャップはバイラル アウトライアーが平均を膨らませることを意味。中央値が「真の」ベースラインです。
• 最大値 / 中央値 比率: >5× = 大きなヒットがある。それらのノートを特に勉強する。
• 投稿頻度: ノート数をカウントして投稿速度を推定。頻繁なクリエイター (>3/週) vs 品質重視 (<1/週)。

出力: クリエイター比較テーブル

クリエイター	フォロワー	平均いいね	中央値	最大値	投稿数	スタイル
@creator1	12万	3,200	1,800	45,000	89	チュートリアル
@creator2	5.4万	8,100	6,500	22,000	34	ストーリー

---

モジュール E: コンテンツ形式の分類

回答: このトピックの場合、画像テキスト ノートとビデオ ノートではどちらが良いパフォーマンスをしていますか?

コマンド:

redbook search "keyword" --type image --sort popular --json
redbook search "keyword" --type video --sort popular --json

抽出するフィールド:

• 2 つの結果セット間で Top1 と Top10 avg liked_count と collected_count を比較
• type フィールドに注目: "normal" = 画像テキスト、"video" = ビデオ

出力: 形式 × エンゲージメント テーブル

形式	Top1 いいね	Top10 平均	保存/いいね
图文	8,000	2,400	42%
视频	15,000	5,100	18%

---

モジュール F: 機会スコアリング

回答: どのキーワードをターゲットにすべきですか? 最良の労力対報酬比率はどこにありますか?

入力: モジュール A のキーワード マトリックス。

スコアリング ロジック:

• デマンド = Top1 いいね シーリング (証明されたオーディエンス規模)
• 競争 = 高エンゲージメント結果の密度 (Top10 の >1K いいね数が何個あるか)
• スコア = デマンド × (1 / 競争密度)

ティア閾値 (Top1 いいねに基づく):

ティア	Top1 いいね	意味
S	>100,000 (10万+)	大規模なデマンド — 競争は激しいが上振れの可能性が大きい
A	20,000–100,000	強いデマンド — 競争的だが勝つことができる
B	5,000–20,000	適度なデマンド — 成長するアカウントに良い
C	<5,000	ニッチ — 低競争、低シーリング

出力: ティア別キーワード リスト

ティア	キーワード	Top1	競争	機会
A	keyword1	45K	中 (6/10 >1K)	高
B	keyword3	12K	低 (2/10 >1K)	非常に高
S	keyword2	120K	高 (10/10 >1K)	中

---

モジュール G: オーディエンス推論

回答: このニッチのオーディエンスは誰ですか? 彼らは何を望んでいますか?

入力: モジュール C のエンゲージメント比率 + analyze-viral のコメント テーマ + コンテンツ パターン。

analyze-viral JSON から抽出するフィールド:

• comments.themes[] — コメント セクションからの定期的なフレーズとキーワード
• comments.questionRate — 質問であるコメントの % (学習意図)
• engagement.collectToLikeRatio — 保存行動は意図をシグナル
• hook.hookPatterns[] — このオーディエンスを引きつけるタイトル パターン

推論ルール:

• 高保存率 + 高質問率 → 学習志向のオーディエンス (学生、専門家)
• 高コメント率 + 感情テーマ → コミュニティ志向のオーディエンス (経験の共有)
• 高シェア率 → 願望志向のオーディエンス (ライフスタイル、身元シグナリング)
• コメント言語パターン → 年齢/教育シグナル (フォーマル = より年上、スラング = より若い)

出力: オーディエンス ペルソナ サマリー — デモグラフィクス、意図、コンテンツ設定。

---

モジュール H: コンテンツ ブレインストーム

回答: データに基づいて、どのような具体的なコンテンツを作成すべきですか?

入力: 機会スコア (モジュール F) + オーディエンス ペルソナ (モジュール G) + ヒートマップ ギャップ (モジュール B)。

各コンテンツ アイデアについて指定:

• ターゲット キーワード — 機会スコアリングから
• フック アングル — このニッチで機能する hookPatterns に基づく
• コンテンツ タイプ — 工具型/认知型/娱乐型 オーディエンスが望むことに基づく
• 形式 — 图文 または 视频 モジュール E に基づく
• エンゲージメント ターゲット — このキーワードの Top10 avg に基づいて現実的
• 競争参考資料 — このアングルが機能することを証明する特定のノート URL

出力: データ裏付けのあるランク付けコンテンツ アイデア

#	キーワード	フック アングル	タイプ	ターゲット いいね	参考資料
1	keyword3	"N个方法..." (リスト)	工具型 图文	5K+	[トップ ノート URL]
2	keyword1	"为什么..." (質問)	认知型 视频	10K+	[トップ ノート URL]

---

モジュール I: コメント オペレーション

回答: どのコメントが返信に値しますか? コメント品質分布は何ですか?

コマンド:

# 1. すべてのコメントをフェッチ
redbook comments "<noteUrl>" --all --json

# 2. 返信候補をプレビュー (ドライラン)
redbook batch-reply "<noteUrl>" --strategy questions --dry-run --json

# 3. テンプレートで返信を実行 (5分遅延、±30% ジッターあり)
redbook batch-reply "<noteUrl>" --strategy questions \
  --template "感谢提问！关于{content}，..." \
  --max 10

--dry-run JSON から抽出するフィールド:

• candidates[].commentId — ターゲット コメント
• candidates[].isQuestion — ブール値、検出された質問
• candidates[].likes — エンゲージメント シグナル
• candidates[].hasSubReplies — 既に回答済みかどうか
• skipped — フィルタリングされたコメント数
• totalComments — フェッチされた総数

戦略:

• questions — ？ または ? で終わるコメントへの返信 (学習志向のオーディエンス)
• top-engaged — 最も高いいいねのコメントへの返信 (最大可視性)
• all-unanswered — 既存の返信がないコメントへの返信 (ギャップを埋める)

解釈方法:

• 高質問率 (>15%) = オーディエンスは学習志向 → 返信して権威を構築
• 高いいいねのコメント (>100 いいね) = 可視的なコメントに返信して最大リーチを獲得
• 多くの未回答コメント = エンゲージメント ギャップ、返信率を上げる機会

安全性: ハード キャップ 1 バッチ 30 返信、最小 3 分遅延、±30% ジッター (デフォルト 5 分)、デフォルトで --dry-run (テンプレートなし = プレビューのみ)、キャプチャで即座に停止。詳細は レート制限と安全性 を参照。

出力: 候補コメント、戦略一致の理由、ステータスのある返信計画テーブル。

---

モジュール J: バイラル レプリケーション

回答: 成功したノートから抽出できる構造テンプレートは何ですか?新しいコンテンツ作成をガイドするために。

コマンド:

# 1. キーワードのトップノートを見つける
redbook search "keyword" --sort popular --json

# 2. 2-3 個のトップ パフォーマーから構造テンプレートを抽出
redbook viral-template "<url1>" "<url2>" "<url3>" --json

viral-template JSON から抽出するフィールド:

• dominantHookPatterns[] — ノートの大多数に現れるフック タイプ
• titleStructure.commonPatterns[] — 特定のタイトル フォーミュラ
• titleStructure.avgLength — ターゲット タイトル長
• bodyStructure.lengthRange — ターゲット単語数 [最小、最大]
• bodyStructure.paragraphRange — ターゲット段落数
• engagementProfile.type — リファレンス/インサイト/エンターテイメント
• audienceSignals.commonThemes[] — オーディエンスが議論する話題

解釈方法:

• ノート全体でフック パターンが一貫している = このニッチの証明されたフォーミュラ
• 狭いボディ長範囲 = オーディエンスは明確なコンテンツ長をもつ環境設定
• 高い保存/いいね = オーディエンスがコンテンツを保存 → リファレンス素材を作成
• 共通のコメント テーマ = 新しいコンテンツで対処するべきトピック

他のモジュールとの構成:

• モジュール A の結果を使用してテンプレート抽出用のトップ URL を特定
• モジュール H (コンテンツ ブレインストーム) へ構造制約としてフィード
• モジュール C の分類を使用してエンゲージメント プロフィールを検証

出力: コンテンツ テンプレート仕様 — コンテンツ作成の構造スケルトン。LLM (構成ワークフロー経由) がこのテンプレートを使用して実際のタイトル、本文、ハッシュタグ、およびカバー画像プロンプトを生成します。

---

モジュール K: エンゲージメント自動化

回答: 私のオーディエンスとの継続的なエンゲージメントをどのように管理すべきですか?

このモジュールはモジュール I と J を人間の監視で構成するワークフローです。

ワークフロー:

1. 監視 — redbook comments "<myNoteUrl>" --all --json 最近のコメントをフェッチ
2. フィルター — redbook batch-reply --strategy questions --dry-run 返信候補を特定
3. レビュー — 人間がドライラン出力をレビュー (または LLM がペルソナ ガイドラインでレビュー)
4. 実行 — redbook batch-reply --strategy questions --template "..." --max 10
5. レポート — 送信された返信、発生したエラー、レート制限ステータスのサマリー

安全ルール:

• 常に --dry-run 最初に、実行前に人間の承認
• 1 セッション最大 30 返信 (ハード キャップ)
• 返信間の最小 3 分遅延、デフォルト 5 分、±30% ランダム ジッターあり
• 同じコメントに 2 回返信しない (hasSubReplies をチェック)
• キャプチャで即座に停止 — リトライしない
• レート制限と安全性 を XHS リスク制御閾値について参照

スパム対策ガイドライン:

• バッチ間で返信テンプレートを変動させる
• 1 ノートあたり 1 日 1-2 バッチ実行に制限
• 量より質を優先 (ターゲット戦略)
• 均一なタイミング パターンはボット検出をトリガー — ジッターが自動的に適用される

---

モジュール L: カード レンダリング

回答: マークダウン コンテンツを Xiaohongshu 対応の画像カードに変換するにはどうしたらいいですか?

コマンド:

# マークダウンをスタイル済み PNG カードにレンダリング
redbook render content.md --style xiaohongshu

# カスタム スタイルと出力ディレクトリ
redbook render content.md --style dark --output-dir ./cards

# JSON 出力 (プログラム的な使用用)
redbook render content.md --json

入力: YAML フロントマターのマークダウン ファイル:

---
emoji: "🚀"
title: "5个AI效率技巧"
subtitle: "Claude Code 实战"
---

## 技巧一：...
コンテンツはここに...

---

## 技巧二：...
さらにコンテンツ...

出力: 同じディレクトリに cover.png + card_1.png、card_2.png など。

カード仕様:

• サイズ: 1080×1440 (3:4 比率、標準 XHS 画像)
• DPR: 2 (Retina 品質、実際の出力 2160×2880)
• スタイル: purple、xiaohongshu、mint、sunset、ocean、elegant、dark

ページネーション モード:

• auto (デフォルト) — 文字数ヒューリスティックを使用した見出し/段落境界での スマート分割
• separator — マークダウンの --- での手動分割

解釈方法:

• ユーザーの既存 Chrome をレンダリングに使用 (puppeteer-core 経由) — ブラウザー ダウンロード不要
• 完全にオフライン — XHS API またはクッキー不要
• 出力画像は redbook post --images cover.png card_1.png ... にすぐ使用可能

依存関係: puppeteer-core と marked が必要 (オプション、npm install -g puppeteer-core marked でインストール)。

他のモジュールとの構成:

• モジュール H (コンテンツ ブレインストーム) と配置 — コンテンツ アイデアを生成、マークダウンを書く、カードにレンダリング
• モジュール J (バイラル レプリケーション) と配置 — テンプレートを抽出、テンプレートに一致するコンテンツを書く、レンダリング
• 出力は redbook post --images に公開のためにフィード

---

モジュール M: ノート ヘルスチェック (限流检测)

回答: 私のノートのいずれかが XHS によって密かにレート制限されていませんか?

XHS は各ノートに隠された level フィールドをクリエイター バックエンド API に割り当てます。このレベルは推奨分布を制御しますが、UI では決して表示されません。ノートが「通常」に見える間に、密かにゼロの推奨を受け取っている場合があります。

コマンド:

# すべてのノート (最初のページ) をチェック
redbook health

# すべてのページをチェック
redbook health --all

# プログラム的な使用用の JSON 出力
redbook health --all --json

レベルの定義:

レベル	ステータス	意味
4	🟢 通常	完全な推奨分布
2-3	🟡 ベースライン	基本的に通常、軽微な制約
1	⚪ 新規	レビュー中 (新しい投稿)
-1	🔴 ソフト制限	軽度のスロットル、推奨の減少
-5 から -101	🔴 中程度	中程度のスロットル、最小限の昇進
-102	⛔ 重大	不可逆 — 削除して再投稿する必要がある

追加チェック:

• 機密単語検出 — 自動化/AI キーワード (自动化、AI生成、批量 など) を含むタイトルをフラグ
• タグ数警告 — >5 ハッシュタグ のノートをフラグ (リスク要因)

解釈方法:

• レベル -1 以下 = ノートがスロットルされている。編集または削除 + 再投稿を検討。
• レベル -102 = 不可逆。ノートを削除して新しいコンテンツを作成。
• 機密単語ヒット = リスキーなタイトル キーワードはスロットルをトリガーする可能性があります。言い換える。
• 過度なタグ = 潜在的なスパム シグナル。3-5 のターゲット タグを使用。

出力: カラー コード分布サマリー、制限されたノート リスト、リスク要因警告のあるターミナル ダッシュボード。

発見クレジット: @xxx111god — xhs-note-health-checker

---

構成ワークフロー

異なる分析の深さのためにモジュールを組み合わせます。

クイック トピック スキャン (~5 分)

モジュール: A → C → F

3-5 個のキーワードを検索、エンゲージメント タイプを分類、機会をランク付け。ニッチがより深い研究に値するかどうかをすばやく検証するのに適しています。

コンテンツ計画

モジュール: A → B → E → F → H

キーワード マトリックスを構築、トピック × シーン交差点をマップ、コンテンツ形式パフォーマンスを確認、機会をスコア、特定のコンテンツ アイデアをブレインストーム。

クリエイター競争分析

モジュール: A → D

ニッチを支配している人を見つけて、彼らのコンテンツ戦略、投稿頻度、エンゲージメント パターンを研究。

完全なニッチ分析

モジュール: A → B → C → D → E → F → G → H

包括的なプレイブック — キーワード ランドスケープ、クロストピック ヒートマップ、エンゲージメント シグナル、クリエイター プロフィール、コンテンツ形式分析、機会スコアリング、オーディエンス ペルソナ、データ裏付けのあるコンテンツ アイデア。

単一ノート ディープ ダイブ

コマンド: redbook analyze-viral "<url>" --json

モジュール構成不要 — analyze-viral は 1 回の呼び出しでフック分析、エンゲージメント比率、コメント テーマ、著者ベースライン比較、0-100 バイラル スコアを返します。

バイラル パターン リサーチ → コンテンツ テンプレート

# 1. トップノートを見つける
redbook search "keyword" --sort popular --json

# 2. トップ 3 ノートからテンプレートを抽出 (手動合成を置き換える)
redbook viral-template "<url1>" "<url2>" "<url3>" --json

viral-template は以前 analyze-viral 結果全体での手動合成が必要だったものを自動化します。支配的なフック、ボディ構造範囲、エンゲージメント プロフィール、オーディエンス シグナルをキャプチャする ContentTemplate JSON を出力します。

返信管理

モジュール: I

単一モジュール ワークフロー、ノートのコメント エンゲージメント管理。batch-reply --dry-run を使用して監査、テンプレートで実行。

コンテンツ レプリケーション

モジュール: A → J → H → L

キーワード リサーチ → バイラル テンプレート抽出 → データ裏付けのあるコンテンツ ブレインストーム → 画像カードにレンダリング。テンプレートはモジュール H のコンテンツ アイデアをガイドする構造制約を提供します。モジュール L は最終マークダウンを XHS 対応 PNG にレンダリングします。

コンテンツ作成エンドツーエンド

モジュール: A → J → H → L → post

完全なパイプライン: キーワード リサーチ → バイラル テンプレート抽出 → コンテンツ ブレインストーム → マークダウン 書き込み → スタイル済み画像カードにレンダリング → redbook post --images cover.png card_1.png ... 経由で公開

アカウント ヘルス モニタリング

モジュール: M

定期的に redbook health --all を実行してスロットルされたノートを早期にキャッチ。レベルが 1 未満に低下した場合、ノートのコンテンツをポリシー違反について調査。モジュール I と組み合わせて、スロットルされたノートがまだ返信する価値のある未回答コメントを持つかどうかを確認。

完全オペレーション

モジュール: A → C → I → J → K → M

包括的なオートメーション プレイブック — キーワード分析、エンゲージメント分類、コメント オペレーション、バイラル レプリケーション テンプレート、エンゲージメント オートメーション ワークフロー。

---

レート制限と安全性

XHS はデバイス フィンガープリンティング、アクティビティ比率監視、タイミング パターン分析を通じた自動化された行動を検出する積極的なアンチスパム (风控) を実行します。CLI はプラットフォーム研究に基づいた安全なデフォルトを適用します。

安全な閾値

アクション	安全な間隔	CLI デフォルト	ハード キャップ
ノートを投稿	3-4 時間 (1 日最大 2-3 ノート)	N/A (手動)	—
コメント	≥3 分	N/A (手動)	—
返信	≥3 分	N/A (手動)	—
一括返信遅延	≥3 分	5 分 ±30% ジッター	—
一括返信数	—	10	30

検出回避対策

• タイミング ジッター: すべてのバッチ遅延に対して ±30% のランダムバリエーション。均一な間隔はボット シグネチャです。
• ハード キャップ: 1 バッチ最大 30 返信 (50 から減少)。オーバーライドなし。
• レート制限警告: post、comment、reply コマンド各アクション後に安全な間隔リマインダーを表示。
• キャプチャ サーキット ブレーカー: バッチ オペレーションはキャプチャ (NeedVerify) で即座に停止。

リスク制御をトリガーするもの

• 均一なタイミング — 正確に 3 秒間隔で返信するとボット検出をフラグ
• 高頻度 — 任意のアクション タイプで >50 インタラクション/分
• アクティビティ比率異常 — 投稿ビューよりも多くのコメントは非認証行動をシグナル
• デバイス フィンガープリント ミスマッチ — XHS は 21 のハードウェア パラメーターをフィンガープリント

エージェントのベスト プラクティス

1. 常に --dry-run 最初に、候補をレビュー、実行
2. デフォルト 5 分遅延を使用 — --delay を 180000 (3 分) 以下にオーバーライドしない
3. バッチ実行をノートあたり 1 日 1-2 に制限
4. バッチ間で返信テンプレートを変動させる
5. post コマンドを 3-4 時間間隔でスペース (1 日最大 2-3 ノート)

---

API 対 ブラウザー制限

次のオペレーションは API 経由で確実に機能します:

• 読取: 検索、ノート、コメント、ユーザー プロフィール、フィード、お気に入り
• 書き込み: トップレベル コメント、コメント返信、ノートを保存/削除
• 分析: バイラル スコアリング、テンプレート抽出、バッチ返信計画

次のオペレーションは API 経由では信頼できません (頻繁にキャプチャをトリガー):

• ノート公開 (成功率を上げるには --private を使用)
• 非常に高頻度の一括オペレーション

次のオペレーションはブラウザー自動化が必要 (このプリオリティでは非サポート):

• キャプチャ解決、リアルタイム通知
• いいね/フォロー (重いアンチオートメーション実装)
• DM/プライベート メッセージ
• カバー画像生成 (Gemini/DALL-E などの外部ツールを使用)

---

コマンド詳細

redbook search <keyword>

キーワード別にノートを検索。ノート タイトル、URL、いいね、著者情報を返します。

redbook search "Claude Code教程" --json
redbook search "AI編程" --sort popular --json        # ソート: general、popular、latest
redbook search "Cursor" --type image --json           # タイプ: all、video、image
redbook search "MCP Server" --page 2 --json           # ページネーション

オプション:

• --sort <type>: general (デフォルト)、popular、latest
• --type <type>: all (デフォルト)、video、image
• --page <n>: ページ番号 (デフォルト: 1)

redbook read <url>

ノートの完全なコンテンツを読む — タイトル、本文、画像、いいね、コメント数。

redbook read "https://www.xiaohongshu.com/explore/abc123" --json

フル URL または短いノート ID を受け入れます。API がキャプチャを返す場合は HTML スクレイピングにフォールバック。

redbook comments <url>

ノートのコメントを取得。すべてのページをフェッチするには --all を使用。

redbook comments "https://www.xiaohongshu.com/explore/abc123" --json
redbook comments "https://www.xiaohongshu.com/explore/abc123" --all --json

redbook user <userId>

クリエイターのプロフィールを取得 — ニックネーム、自己紹介、フォロワー数、ノート数、受け取ったいいね数。

redbook user "5a1234567890abcdef012345" --json

userId はクリエイターのプロフィール URL からの 16 進文字列です。

redbook user-posts <userId>

クリエイターによって投稿されたすべてのノートをリスト。タイトル、URL、いいね、タイムスタンプを返します。

redbook user-posts "5a1234567890abcdef012345" --json

redbook feed

推奨フィードを閲覧。

redbook feed --json

redbook topics <keyword>

トピック ハッシュタグを検索。投稿にアタッチするトレンドingトピックを見つけるのに便利。

redbook topics "Claude Code" --json

redbook favorites [userId]

ユーザーが収集 (ブックマーク) したノートをリスト。userId が提供されない場合、現在ログインしているユーザーにデフォルト設定。

redbook favorites --json                        # あなた自身のお気に入り
redbook favorites "5a1234567890abcdef" --json   # 別のユーザーのお気に入り
redbook favorites --all --json                  # すべてのページをフェッチ

オプション:

• --all: すべてのお気に入りページをフェッチ (デフォルト: 最初のページのみ)

注: 他のユーザーのお気に入りは、コレクションを非公開に設定していない場合にのみ表示されます。

redbook collect <url>

ノートを保存 (ブックマーク) してお気に入りに追加。

redbook collect "https://www.xiaohongshu.com/explore/abc123"

redbook uncollect <url>

コレクションからノートを削除。

redbook uncollect "https://www.xiaohongshu.com/explore/abc123"

redbook analyze-viral <url>

バイラル ノートが機能する理由を分析。決定論的なバイラル スコア (0–100) を返します。

redbook analyze-viral "https://www.xiaohongshu.com/explore/abc123" --json
redbook analyze-viral "https://www.xiaohongshu.com/explore/abc123" --comment-pages 5

オプション:

• --comment-pages <n>: フェッチするコメント ページ (デフォルト: 3、最大: 10)

JSON 出力構造: { note, score, hook, content, visual, engagement, comments, relative, fetchedAt } を返します。

• score.overall (0–100) — フック (20) + エンゲージメント (20) + 相対 (20) + コンテンツ (20) + コメント (20) の複合
• hook.hookPatterns[] — 検出されたタイトル パターン (Identity Hook、Emotion Word、Number Hook、Question など)
• engagement — いいね、コメント、保存、シェア + 比率 (collectToLikeRatio、commentToLikeRatio、shareToLikeRatio)
• relative.viralMultiplier — このノートのいいね / 著者の中央値いいね
• relative.isOutlier — viralMultiplier > 3 の場合 true
• comments.themes[] — コメントからのトップ定期的なキーフレーズ

redbook viral-template <url> [url2] [url3]

1-3 個のバイラル ノートから再利用可能なコンテンツ テンプレートを抽出。各ノートを分析 (analyze-viral と同じパイプライン) し、共通の構造パターンを合成。

redbook viral-template "<url1>" "<url2>" "<url3>" --json
redbook viral-template "<url1>" --comment-pages 5 --json

オプション:

• --comment-pages <n>: ノートあたりフェッチするコメント ページ (デフォルト: 3、最大: 10)

JSON 出力構造: { dominantHookPatterns, titleStructure, bodyStructure, engagementProfile, audienceSignals, sourceNotes, generatedAt } を返します。

• dominantHookPatterns[] — 入力ノートの大多数に現れるフック タイプ
• titleStructure.avgLength — ノート全体の平均タイトル長
• bodyStructure.lengthRange — [最小、最大] ボディ長
• engagementProfile.type — "reference" / "insight" / "entertainment"
• audienceSignals.commonThemes[] — ノート間でマージされたコメント テーマ

redbook comment <url>

ノートにトップレベル コメントを投稿。

redbook comment "<noteUrl>" --content "素晴らしい投稿！" --json

オプション:

• --content <text> (必須): コメント テキスト

redbook reply <url>

ノートの特定のコメントに返信。

redbook reply "<noteUrl>" --comment-id "<commentId>" --content "ご質問ありがとうございます！" --json

オプション:

• --comment-id <id> (必須): 返信するコメント ID (comments --json 出力から)
• --content <text> (必須): 返信テキスト

redbook batch-reply <url>

フィルタリング戦略を使用して複数のコメントに返信。常に --dry-run で最初にプレビュー。

# どのコメントが戦略に一致するかをプレビュー
redbook batch-reply "<noteUrl>" --strategy questions --dry-run --json

# テンプレートで返信を実行 (デフォルト 5 分遅延、ジッターあり)
redbook batch-reply "<noteUrl>" --strategy questions \
  --template "感谢提问！{content}" --max 10

オプション:

• --strategy <name>: questions (デフォルト)、top-engaged、all-unanswered
• --template <text>: {author}、{content} プレースホルダーのある返信テンプレート
• --max <n>: 最大返信 (デフォルト: 10、ハード キャップ: 30)
• --delay <ms>: 返信間の遅延 (ms 単位) (デフォルト: 300000 / 5 分、最小: 180000 / 3 分)。±30% ランダム ジッターが自動的に適用される。
• --dry-run: 投稿せずに候補をプレビュー (テンプレートなし時がデフォルト)

安全性: キャプチャで即座に停止。テンプレートなし = ドライランのみ。遅延はランダム ジッターを含めて、XHS ボット検出をトリガーする均一なタイミング パターンを回避。

redbook render <file>

YAML フロントマターを含むマークダウン ファイルをスタイル済み PNG 画像カードにレンダリング。ユーザーの既存 Chrome インストールを使用 — ブラウザー ダウンロード不要。

redbook render content.md --style xiaohongshu
redbook render content.md --style dark --output-dir ./cards
redbook render content.md --pagination separator --json

オプション:

• --style <name>: purple、xiaohongshu (デフォルト)、mint、sunset、ocean、elegant、dark
• --pagination <mode>: auto (デフォルト)、separator (--- で分割)
• --output-dir <dir>: 出力ディレクトリ (デフォルト: 入力ファイルと同じ)
• --width <n>: カード幅 px (デフォルト: 1080)
• --height <n>: カード高さ px (デフォルト: 1440)
• --dpr <n>: デバイス ピクセル比 (デフォルト: 2)

必須: puppeteer-core と marked (npm install -g puppeteer-core marked)。XHS クッキーは NOT 必須 — 完全にオフライン レンダリング。

Chrome パスオーバーライド: Chrome が標準位置にない場合は CHROME_PATH 環境変数を設定。

redbook whoami

接続ステータスを確認。クッキーが有効で、ログインしているユーザーを表示することを検証。

redbook whoami

redbook post (制限)

画像ノートを公開。クリエイター API で頻繁にキャプチャ (type=124) をトリガー。 画像アップロードは機能しますが、公開ステップは信頼できません。投稿については、代わりにブラウザー自動化を検討。

redbook post --title "标题" --body "正文" --images cover.png --json
redbook post --title "テスト" --body "..." --images img.png --private --json

オプション:

• --title <title>: ノート タイトル (必須)
• --body <body>: ノート本文テキスト (必須)
• --images <paths...>: 画像ファイル パス (必須、最低 1 つ)
• --topic <keyword>: トピック ハッシュタグを検索してアタッチ
• --private: プライベート ノートとして公開

グローバル オプション

すべてのコマンドは以下を受け入れます:

• --cookie-source <browser>: chrome (デフォルト)、safari、firefox
• --chrome-profile <name>: Chrome プロフィール ディレクトリ名 (例: "Profile 1")。省略された場合は自動発見。
• --json: JSON として出力

---

技術リファレンス

xsec_token — ノート読取と共有に必須

XHS API はノート コンテンツをフェッチするには有効な xsec_token が必要です。これなしでは read、comments、analyze-viral は {} を返します。

同じトークンがシェア可能な URL にも必須。 任意の https://www.xiaohongshu.com/explore/<id> URL は ?xsec_token=...&xsec_source=... なしで XHS の反スクレイピング レイヤーによって https://www.xiaohongshu.com/404/sec_*?source=xhs_sec_server&originalUrl=... に 302 リダイレクト。これは URL をクリックする誰にでも影響します — Safari、iOS リンク プレビュー、エージェント アクション ボタンなど。

webUrl — これを使用 (v0.7.0 以降):

すべてのノート返却コマンド (feed、search、user-posts、favorites、board、read、post) は現在、トークンが焼き込まれた webUrl フィールドと正しい xsec_source を含みます。コンシューマーは webUrl を直接使用する必要があります — URL を手動で構築しないでください。

redbook feed --json | jq '.items[0].webUrl'
# => "https://www.xiaohongshu.com/explore/<id>?xsec_token=<t>&xsec_source=pc_feed"

xsec_source はコマンドごとに設定: pc_feed、pc_search、`