book-review

ユーザーの Reader のハイライトをもとに、長文の書評を作成します。対象の本だけでなく、ライブラリ全体から関連するハイライトを取り入れ、独自の論考を展開します。

目指すのは、本そのものよりも興味深い書評です。要約＋批評＋独自のアイデアで構成し、その独自のアイデアは、本をユーザーが読んできたあらゆるものと結びつけることで生み出します。

Readwise へのアクセス

Readwise MCP ツールが利用できるか確認してください（例：mcp__readwise__reader_list_documents）。利用できる場合は、全体を通してそれらを使用します。利用できない場合は、代わりに readwise CLI コマンドを使用してください（例：readwise list、readwise read <id>、readwise highlights <id>、readwise search <query>）。以下の手順では MCP ツール名を参照していますが、必要に応じて CLI コマンドに置き換えてください。

セットアップ

1. ペルソナファイルを確認します。 現在の作業ディレクトリに reader_persona.md があれば読み込みます。ユーザーの関心、読書の目的、文体を把握してください。これらは書評の切り口、優先する関連性、ユーザーが重視しそうな点を決めるための指針になります。ペルソナファイルがない場合は、そのまま進めてください。ハイライトから本を読む目的が明らかでない場合は、ユーザーに尋ねてください。

2. 引数を解析します。 引数は本のタイトルまたは検索語です。

/book-review Merchant Kings
/book-review 7 Powers

---

フェーズ 1：本のハイライトを取得する

1.1 本を見つける

Reader で対象の本を検索します。

mcp__readwise__reader_search_documents(query="[book title]", category_in=["epub", "pdf"])

検索結果がない場合は、すべてのカテゴリに対象を広げてください。一致する結果が複数ある場合は、それらを一覧表示してユーザーに選んでもらいます。

1.2 ハイライトを取得する

mcp__readwise__reader_get_document_highlights(document_id="[book_id]")

ハイライトをすべて読み、件数を数えてください。10件未満の場合は、内容の充実した書評を書くには材料が不足している可能性があることをユーザーに伝えます。作業を続けるか、待つかを尋ねてください。

1.3 ドキュメントの詳細を取得する

mcp__readwise__reader_get_document_details(document_id="[book_id]")

タイトル、著者、要約、表紙画像を取得します。これらは最終的な出力に必要です。

---

フェーズ 2：主張を抽出する

各ハイライトを、個別の主張に分解します。この手順により、「この段落にハイライトを付けた」という状態から、構造化され、検索可能な調査資料へと変換できます。

各ハイライトについて：

1. ハイライトされたテキストと、ユーザーのメモや注釈を読みます。
2. 現在形の平叙文で、単一の主張を書きます（できれば10語未満）。
3. ユーザーがメモを残している場合は、メモで重点が置かれている内容に沿って主張を調整します。

主張の品質基準：

良い主張は、具体的で検索可能な事実または断定です。

• 「煙突掃除人は石炭の煤による陰嚢がんで死亡した」
• 「オスマン帝国のハレムでは、奴隷の少女たちがエリート官僚として訓練された」
• 「モンスーンの風が世界的な海上交易を可能にした」

悪い主張は、曖昧または一般的です。

• 「石炭採掘は健康に影響を及ぼした」
• 「著者はオスマン帝国の継承について論じている」
• 「奴隷制について興味深い点がある」

すべてのハイライトの処理後、主張の一覧全体を見直します。次のような主張は却下し、書き直してください。

• 一般的で面白みに欠けるもの（「著者は X について論じている」）
• 重複しているもの（同じ内容を別の表現で述べている2つの主張。統合します）
• 曖昧なもの（ハイライトを読まないと意味が分からないもの）

主張は、テーマ別にまとめた作業用リストとして保存します。これがアウトラインになります。

---

フェーズ 3：ライブラリから関連資料を検索する

これが、書評を単なる要約にとどめないための手順です。フェーズ2で抽出した主要なテーマ群ごとに、ユーザーの Reader ライブラリ全体から関連する内容を検索します。

3.1 テーマ別の検索

各テーマ群について（3～6テーマを目安にします）：

mcp__readwise__reader_search_documents(query="[theme keywords]", limit=20)

上位の検索結果からハイライトを取得します。

mcp__readwise__reader_get_document_highlights(document_id="[related_doc_id]")

次のような内容を探します。

• 裏付けとなる証拠： 別の資料から得られた、本の主張を強化する根拠
• 矛盾点： 本の論旨を複雑にする反対の見解
• 並行する事例： 異なる分野の例（ユーザーが生物学で読んだ X と同じことが、本では経済学について述べられている）
• ユーザー自身の過去の考え： 関連するドキュメントのメモや注釈に表れている、ユーザー自身の考え

3.2 著者を検索する

mcp__readwise__reader_search_documents(query="[book author name]")

ユーザーが同じ著者の別の作品を読んでいるか確認します。過去の文脈を取り入れると、書評をより深められます。

3.3 関連する主張を抽出する

関連文書の各ハイライトについて、フェーズ 2 と同じ方法で主張を抽出します。適切に引用できるよう、出典文書のタグを付けてください。

結果： 以下がそろっているはずです。

• テーマごとにまとめた本の主張（フェーズ 2）
• 同じテーマに対応付けた、より広いライブラリからの関連する主張（フェーズ 3）
• ユーザーの読書内容が、本の主張をどこで裏付け、複雑にし、あるいは発展させているかについての把握

---

フェーズ 4：ウェブ調査で補足する

ユーザーのライブラリで扱われていない情報の不足を補います。焦点を絞ってください。中心となるのはライブラリ調査であり、ウェブ調査は補足です。

• 学術資料、著者インタビュー、その他のレビューを検索する
• 同じトピックを扱う Substack の執筆者やブロガーを探す

---

フェーズ 5：レビューを書く

優れた書評には、次の 3 つの要素があります（ACX Book Review Contest の知見によるものです）。

1. 要約 — 本の内容と興味深い理由を示します。これがないと、読者は戸惑います。
2. 批評 — 質や意見の一致について、実際に判断を示します。これがないと、書評とは言えません。
3. 独自のアイデア — 本を、ユーザーの読書内容から見えてくるより広いパターンと結び付けます。これがないと、特に印象に残りません。

独自のアイデアはフェーズ 3、つまりユーザーのライブラリから得た関連ハイライトをもとにします。 これがこのスキルの要点です。

構成

[Opening: What the book is and why it matters — a specific fact or scene, not a vague hook.
Leave a %% TODO %% for the user to add how they found the book and why they read it
if context wasn't already in the document note.]

## [Thematic section 1 — informative header, not clever]

[Summarize the book's argument on this theme. Use block quotes from the book's highlights.
Then EXPAND: bring in related material from the user's other reading. This is where the
review becomes more than a summary — it's synthesis.]

> "Block quote from the book" — Author, *Book Title*

[The user also highlighted something in [Related Document] that complicates/supports this:
weave it in naturally. Cite the source with a URL link to the original source, NOT the Reader link.]

## [Thematic section 2]

[Same pattern: book's argument → user's related reading → synthesis.
Each section should advance an argument, not just list facts.]

## [Thematic section 3+]

[Keep going. Organize by theme, not by chapter. Every section should have at least
one connection to something outside the book itself.]

## What the Book Gets Wrong (or Misses)

[Honest critique. Use the user's other reading as evidence where it contradicts
or complicates the book. This is where the related-document research pays off most.]

## Further Reading

- Description with [embedded link](url) for sources worth exploring that were NOT
  linked above but are related to the core themes of this review.

文体のルール

ユーザーになりきるのではなく、ユーザーのために下書きを作成します。

• 感情をでっち上げない — 「心を打たれた」「知って驚いた」などとは書きません。事実を述べます。感想はユーザーが加えます。
• 個人的な詳細をでっち上げない — 「子どもの頃を思い出した」などとは書きません。ユーザーがハイライトのメモに書いている場合は、それに触れます。そうでなければ、%% TODO %% を残します。
• 明示的に空欄を残す — 個人的な導入部分には、%% TODO: [ユーザーが追加する内容] %% を使います。これは、ユーザー自身の経験を補う必要がある箇所を示します。
• 分からないことは正直に扱う — 曖昧にするより「分かりません」とするほうが適切です。確信がなければ、その旨を伝えるか TODO を残します。
• 一人称を使う — ユーザーについての報告書ではなく、ユーザーが編集するための下書きを作成します。
• ペルソナファイルがある場合は、ユーザーがどのつながりを優先し、どのような枠組みを自然に感じるかを判断する参考にします。ただし、確信が持てない個人的な詳細については、引き続き TODO を残します。

長さ

長めにします。内容の充実した本なら 2,000～10,000 語を目安にします。ACX コンテストのデータによると、真に洞察のある長めの書評は、短い書評よりも優れた結果を出しています。すべての段落に意味がある限り、簡潔さより深さを重視します。ユーザーのハイライトが少ない場合（10～20 件）は、1,000～2,000 語を目安にします。

リンクと出典

• 対象の本に初めて言及する箇所に Bookshop.org のリンクを付けます。
• 実在する URL のみを使います — (url) や (link) のようなプレースホルダーリンクは残しません。
• ユーザーの Reader ライブラリにある関連文書を引用する場合は、Reader の URL ではなく、文書の詳細に記載された元の出典 URL にリンクします。
• Substack やオープンアクセスの PDF など、ペイウォールなしで全文を読めるウェブ資料を優先します。読むために購入が必要な本を出典にしないでください。

---

フェーズ 6：品質チェック

独立した工程です。省略しないでください。フェーズ 5 とまとめないでください。

下書き全体を読み直し、次のすべての項目を修正します。

禁止語彙

以下は使用しないでください。具体的な代替表現を使ってください。

禁止語	代わりに使う表現
Additionally	「また」または文の構成を変える
Crucial / Pivotal / Key（形容詞）	重要な理由を具体的に述べる
Delve / Delve into	「検討する」「見る」またはそのまま書き始める
Enhance / Fostering	何が改善されたのかを具体的に述べる
Landscape（抽象的な意味）	実際の分野を明記する
Tapestry（比喩）	実際のパターンを明記する
Underscore / Highlight（動詞）	要点を直接述べる
Showcase	「示す」「実証する」
Vibrant / Rich（比喩）	具体的に述べる
Testament / Enduring	事実だけを述べる
Groundbreaking / Renowned	注目に値する点を具体的に述べる
Garner	「得る」「獲得する」「引き付ける」
Intricate / Intricacies	「複雑な」または実際の複雑さを説明する
Interplay	「関係」「緊張関係」またはその内容を説明する
Serves as / Stands as	「である」を使う
Nestled / In the heart of	場所をそのまま示す

禁止する構文

パターン	修正方法
「Xだけではなく、Yでもある」／「Aではなく、Bである」	Yを直接述べる
三つ並べる表現（「革新、ひらめき、洞察」など）	内容に必要な数だけ挙げる
「～を強調しながら」など、分析を「～ing」で表す構文	重要性を直接述べる
誤った範囲を示す「XからYまで」	実際の項目を列挙する
類義語を次々と使う（主人公／英雄／中心人物など）	用語を一つ選び、繰り返し使う
「困難はあるものの、未来は明るい」	実際の状況を述べる
「これからが楽しみです」	具体的な事実で締めくくる
「Xではなかった。Zだった。」（劇的な種明かし）	肯定的な一文にまとめる
「私が思わず立ち止まった詳細」	事実から書き始める
「真に革命的」	具体的な表現を使う
深遠に見せるための大げさな一文	削除する
「知っていたことを忘れていた」	削除する。知識を再発見したかのように表現しない

チェックリスト

• 6a. 禁止語や禁止パターンがないか、原稿を grep で検索してください。一致した箇所はすべて修正してください。
• 6b. リンクを確認 — すべてのリンクに実在する URL が設定されていること。プレースホルダーは使わないでください。
• 6c. ダッシュの使用頻度を確認 — 1 セクションあたり最大 2～3 個にしてください。超過分はコンマ、コロン、ピリオドに置き換えてください。
• 6d. 単語の繰り返しを確認 — 段落内で 3 回以上使われている単語があれば、表現を変えるか減らしてください。
• 6e. 冒頭の段落を読み直す — 人が書いたように聞こえますか。それとも、本の内容を AI が要約しているように聞こえますか。後者なら書き直してください。
• 6f. 各セクションが、本そのものを超える内容と結び付いていることを確認する — 関連資料とのつながりがなく、要約だけになっているセクションがあれば、関連ライブラリとのつながりを加えるか、そのセクションを削除してください。

---

要約との違い

フェーズ 3（ライブラリ検索）の目的は、レビューに本の著者が書いていない考えを含めることです。ユーザーの読書履歴は独自の視点になります。

• ローマの物流に関する本とサプライチェーン管理に関する本を読んでいる場合 → どちらか一冊だけでは得られないつながりをレビューで示します
• 別の資料で矛盾する主張にハイライトを付けている場合 → ユーザーがすでに説得力を感じた証拠を使って、本の主張に異議を唱えます
• 一見無関係な記事のハイライトにメモを残していて、実は関連性がある場合 → ユーザーが意識していなかったかもしれないつながりをレビューで示します

こうして「独自の考え」が生まれます。これが、優れたレビューと印象に残るレビューを分ける三つ目の要素です。独自の考えを生み出すのは、ユーザーのライブラリです。

---

フェーズ 7：Reader に公開する

Reader に新しいドキュメントとしてレビューを作成します。

mcp__readwise__reader_create_document(
  url="https://reader-review.internal/[slug]-[ISO-timestamp]",
  title="[book title] — Review Draft",
  author="Ghostreader",
  category="article",
  summary="Review draft based on [N] highlights from [Book Title] and [M] related documents",
  html="[converted HTML of the review]",
  notes="DRAFT for editing. Based on highlights from: [list source document titles]"
)

ドキュメントの URL をユーザーに返します。

---

What Makes This Different from a Summary

フェーズ 3（ライブラリ検索）の目的は、レビューに本の著者が書いていない考えを含めることです。ユーザーの読書履歴は独自の視点になります。

• ローマの物流に関する本とサプライチェーン管理に関する本を読んでいる場合 → どちらか一冊だけでは得られないつながりをレビューで示します
• 別の資料で矛盾する主張にハイライトを付けている場合 → ユーザーがすでに説得力を感じた証拠を使って、本の主張に異議を唱えます
• 一見無関係な記事のハイライトにメモを残していて、実は関連性がある場合 → ユーザーが意識していなかったかもしれないつながりをレビューで示します

こうして「独自の考え」が生まれます。これが、優れたレビューと印象に残るレビューを分ける三つ目の要素です。独自の考えを生み出すのは、ユーザーのライブラリです。

---

エラー処理

• Reader で本が見つからない場合：試した検索語を報告し、正しいタイトルまたはドキュメント ID を尋ねます。
• ハイライトが 10 件未満の場合：十分な数ではない可能性があることを警告します。続行するかどうかを尋ねます。
• 関連ドキュメントが見つからない場合：本のみを対象にレビューを進めますが、要約中心になることを警告します。ウェブ調査をより重視します。
• Reader の作成に失敗した場合：下書きのテキストはすでに生成されています。ユーザーが手動で保存できるよう、Markdown として出力します。
• 予期しない失敗が発生した場合：何に失敗したか、すでに完了したこと、部分的な出力がある場所を伝えます。