AIに先回りされずに本を読む ── 1冊につきChatGPT Projectを1つ作る

レビューを読む前の自分を、SHA-256で固定した

本を読むための仕組みを作っていたら、いつのまにかハッシュ値を計算していた。

やりたかったのは単純なことである。世間の評価を知る前に自分が何を考えていたか、後から確認できるようにしたい。 そのために、第三者のレビューを調べる前の状態を技術的に固定した。

なんでそんなことになったのか、順番に書く。

分からない言葉を、当たり前にAIへ聞くようになった

最近、本を読んでいて分からないことがあると、当たり前のようにAIへ質問するようになった。

これは非常に便利だ。一方で、本を読むという行為においては少し問題があるのではないか、と感じるようになった。

まだ本を途中までしか読んでおらず、自分自身の理解も固まっていない段階でAIに質問する。するとAIは、その本に書かれていることだけではなく、世間での評価、後世から見た解釈、批判、関連する思想までを含めて答えることがある。

それ自体は間違いではない。

しかし、その情報を先に知ってしまうことで、本来なら自分で考えながら形成していくはずだった本への認識が、AIの説明によって先回りして形作られてしまう。

場合によっては、「自分で考える」前にAIへ答えを求めることが習慣になり、考えることそのものを止めてしまう可能性もある。

それでは、本を読んだというより、AIや他人の解釈を通して本を確認しただけになってしまう。

かといって、要約させたいわけでもない

一方で、NotebookLMのように本を要約したり、短時間で内容を把握したりするためにAIを使いたいわけでもない。

せっかく時間を使って、その本そのものを直接読んでいるのだから、できるだけ自分の頭で考えながら読みたい。

ただし、本を理解するためには自分の知識だけでは足りないことも多い。

• 筆者がどのような人物なのか
• その本は、どのような時代や社会情勢の中で書かれたのか
• 当時どのような技術、制度、思想、産業構造が存在していたのか
• 本文に登場する概念は、どのような意味を持っているのか

こうした「本の外側にある基礎的な背景情報」を知っていれば、AIを使ったとしても、本文の解釈を先回りして与えてもらうのではなく、自分自身で本を理解するための補助として使える。

つまり、AIの介入そのものをなくしたいわけではない。

AIが何を教えるのか、そして何を教えないのかを、最初に設計したい。

これは「AI読書」ではあるが、AIに読書を代行させる仕組みではない。自分の読書を守るためのAI利用法である。

毎回準備するのは面倒だから、1冊1Projectにする

とはいえ、本を読むたびに、

• 著者について調べる
• 出版当時の社会背景を調べる
• 関連する基礎知識を集める
• AIにどこまで答えてよいか指示する
• 参照してよい情報源を設定する

を毎回やるのは面倒である。

そこで、ChatGPTのProjectでは情報源とインストラクションをあらかじめ指定できることを利用し、一冊の本につき一つの読書Projectを作るという方法を考えた。

全部はこの一文から始まっている。2026年8月8日、AIに投げた最初のメモ。

本ごとにGPTのプロジェクトを作って、その情報源に「著者の暦書md」と「その本のレビューmd」を入れて、プロジェクトのインストラクションに一緒に本についての考察をしたいってことを書いて、思いつき次第、プロジェクト内に新しいチャットを作り、その中で質問や考察して行き、最後にプロジェクト全体をまとめるチャットを作りそこから横断的に読書感想文みたいなまとめを作らせるってのはどう？

誤字はそのままにしておく（暦書＝経歴）。この時点では2ファイルしか考えていない。

最初の対象は『DXの思考法 日本経済復活への最強戦略』（西山圭太 著／冨山和彦 解説）にした。

読み方はこうなる。本を読みながら何か思いついたら、その都度Project内に新しいチャットを作る。

「この部分はどういう意味だろう」 「これは自分の仕事にも当てはまるのではないか」 「著者はなぜこう考えたのだろう」 「ここには少し違和感がある」

1つの長大なチャットに全部押し込むのではなく、問いや考察ごとにチャットを分けておく。そして読み終わった段階で、Project全体を横断してまとめるチャットを作る。

そうすれば、本を読んだ結果だけではなく、本を読みながら自分の考えがどう動いたかまで残る。

Project内は役割ごとにファイルを分ける

最初のメモでは著者とレビューの2ファイルだった。それが対話しながら増えていった。

途中で「本の背景」と「著者の背景」は別レイヤーだと気づいて分離し、自分の読みを蓄積する場所を足して4つになり、最後にProjectのインストラクションそのものをファイル化して5つになった。

ファイル	役割
01_book-context.md	書誌情報や本の背景など
02_author-context.md	著者・解説者について理解に必要な最低限の背景
03_reviews.md	書評・第三者評価を隔離して保存
04_my-reading.md	自分自身の疑問、感想、解釈、変化の記録
project-instructions.md	AIがこのProjectでどう振る舞うかのルール

配置で言うと、こういう対称になっている。

01_book-context ── 本はどこから来たか
02_author-context ─ 誰が、なぜ書いたか
              │
              ▼
            📖 本
              │
              ▼
            自分
              │
              ▼
04_my-reading ──── 自分はどう読んだか

03_reviews ─────── 他人はどう読んだか
      ↑
  普段は遮断

03_reviews.md と 04_my-reading.md を対称に置く。他人はどう読んだか、自分はどう読んだか。最後に初めてぶつける。ここが気に入っている。

レビューは封印する

一番気になっていたのがレビューだった。

本についてAIと話すなら、レビューや書評を入れておけば情報量は増える。一方で、最初からAIがレビューを読んでいると、こちらが質問したときに、AI自身が意識していなくても第三者の評価に引っ張られる可能性がある。

自分がある箇所について「ここは重要なのではないか」と考えたとする。AIがすでに世間のレビューを知っていれば、「実際、多くの読者もそこを重要視しています」と言えてしまう。

反対に、自分が気にした点がレビューでほとんど触れられていなければ、AIはその論点を軽く扱うかもしれない。

それでは自分の読書ではなくなる。

そこで 03_reviews.md は、情報源として保存はするが、通常の読書中には封印する。「世間ではどう評価されている？」「自分の感想とレビューを比較して」と私が明示したときだけ参照する。しかもレビューから得た論点を他のファイルへ逆流させない。

読書の初期段階（Stage A）で使ってよいのは、出版社、著者本人、所属組織など、比較的一次情報に近いものだけ。書評、Amazonレビュー、読者レビュー、第三者要約は、根拠にも、論点選択にも、AIが私へ投げる質問の生成にも使わない。

さらに、レビュー調査に入る前にStage A側の4ファイルをSHA-256で固定する。これは思想として書いただけではなく、scripts/validate_reading_project.py に実装した。

# レビューを見る前
python scripts/validate_reading_project.py "<folder>" --phase pre-review \
  --write-baseline "<temporary-baseline.json>"

# 03_reviews.md を書いた後
python scripts/validate_reading_project.py "<folder>" --phase final \
  --compare-baseline "<temporary-baseline.json>"

ここまでやっておいて何だが、この検証には限界がある。そしてその限界はSkillの中に自分で明記した。

ハッシュ一致が証明できるのは「レビュー調査中に4ファイルを書き換えなかった」ことだけで、意味的な影響がゼロだったことは機械的には証明できない。

バリデータはStage Aの出典欄にレビュー系ドメインや評価的な言い回しが混ざっていないかも見るが、これもヒューリスティックにすぎない。結局、探索段階での自制と目視確認が必要になる。

大げさに見えるかもしれない。ただ守りたかったのはデータそのものではなく、「これはレビューを知る前に自分が考えたことだ」と後から確認できることだった。証明にはならなくても、境界線を引いた時刻は残る。

著者情報にも同じ問題がある

著者の背景を知ることは本の理解を助ける。しかし、

「この人は経産省出身だからこういう考えなのだろう」 「この経歴だから、この主張をしたに違いない」

とAIが勝手に因果関係を作ると、これも読書への過剰介入になる。

そこで 02_author-context.md は最低限の背景確認用とし、人物像や経歴から本の主張や意図を推測しない、という役割に限定した。

本命は 04_my-reading.md

このファイルは単なる感想文ではない。残すのは、

• 読む前の自分の考え
• 重要だと思った問い
• 違和感や反論
• AIとの対話から生まれた発見
• 読んだことで考えが変わったこと

本の要約よりも、自分がその本とどう関わったかを残す。

そしてこのファイルには、Skill側に強いルールを入れた。

ユーザーの問い、仮説、期待、反応、経験を、AIが創作してはならない。 私が自分から述べた考えだけを、解釈も拡張もせずに書き写す。それ以外の内省セクションは、空欄のまま残す。

実際、テスト実行で生成された 04_my-reading.md は566バイトしかない。他のファイルが5,000〜13,000バイト書かれている中で、ここだけほぼ空である。

これでいい。ここは私が埋める場所だから。

この構造なら、何年か後に読み返したときに「この本にはこう書いてあった」だけではなく、「2026年の自分はこの部分をこう読んでいた」という記録になる。私にとってはこちらの方が面白い。

AIには、答えではなく背景と問い返しを担当してもらう

整理すると、こうなった。

やってほしいこと

• 用語や背景知識の補足
• 本文についての事実確認
• 自分が言ったことの整理
• 問い返し
• 考えを深めるための壁打ち

やってほしくないこと

• 未読部分を先に要約する
• 本の「正解」を提示する
• 「本当に重要なのは〜です」と評価を決めてしまう
• レビューで有名な論点へ誘導する
• 自分がまだ曖昧に感じていることを、勝手に完成した主張へ変える

特に最後が重要だった。

人間が考えている途中には、「なんとなく引っかかる」「まだ説明できないけど違う気がする」という段階がある。AIは文章を綺麗にまとめるのが得意なので、この曖昧さをすぐに完成された論理へ変えてしまう。

しかし読書では、その曖昧な状態そのものに意味がある。だから、曖昧な考えを勝手に完成させるのではなく、曖昧なまま保持しながら一緒に考えてほしい。

1冊専用にしておくのはもったいない

ここまで設計すると、『DXの思考法』だけに使うのが惜しくなった。

本が変わっても、レビューを隔離する／著者情報と本文解釈を混同しない／自分の読書ログを中心に置く／AIが先回りしすぎない／最後に横断してまとめる、という基本構造は使い回せる。

そこで、この読書Projectを新しく始めるための仕組みそのものを、Reading Project StarterというPersonal Skillにした。中身は12ファイル。

reading-project-starter/
├─ SKILL.md
├─ agents/openai.yaml
├─ assets/templates/     5ファイル（出力する5つの雛形）
├─ references/           3ファイル（探索方針・レビュー隔離方針・出力仕様）
└─ scripts/              2ファイル（雛形展開・検証）

入力として要求するのは、書名と、関係者を最低1名だけ。それ以外は聞かない。

SKILL.md にはこう書いた。「任意の設定質問をするな。通常の曖昧さはWeb調査で解決しろ。作品や版が複数あり得て、選択を誤るとまるごと別のProjectを作ってしまう場合にだけ、識別のための質問を1つする」。

v1.0にするまでに2つ直した

Skillを作ったのはCodexのSkill Creator。最初にできた版（開発版）は、テストは通ったが2つ問題があった。

1つ目。冨山和彦を共著者にしていた。

正確に言うと、生成された 02_author-context.md の中身は正しかった。

入力では西山圭太・冨山和彦の2名が「著者」として示されていたが、出版社の正式なクレジットは「西山圭太 著」「冨山和彦 解説」である。この開始セットでは、その役割の違いを保持する。

私の入力が雑だったのを、質問ではなく文藝春秋の公式ページで解決して、差異だけ記録している。ここは狙いどおりだった。

問題はスクリプト側で、scaffold_project.py が人物を全員 --author として受け取り、2名以上なら自動的に「共著者同士の関係」という見出しを作る設計になっていた。今回はたまたま出力が正しかっただけで、構造としては役割を保持できていない。

そこで名前と書誌上の役割を分離した。

--contributor "著=西山圭太" --contributor "解説=冨山和彦"

著／共著／編著／編集／監修／解説／訳／原著者を保持し、役割が混在しているのに「共著者同士の関係」という見出しを使ったらバリデーションエラーにした。

2つ目。Stage Aの検索そのものを縛った。

ハッシュ検証は「03_reviews.md を作った後に他の4ファイルを書き換えていない」ことしか保証しない。Stage Aの調査中にレビューの検索スニペットを見てしまい、それが無意識に論点選択へ影響する可能性は残る。

このSkillの核心は「レビューを後から隔離する」ことではなく、自分の読みが形成される前に他者の解釈を混ぜないことなので、これはv2ではなくv1.0に入れることにした。

Stage Aで使ってよいのは、出版社公式、著者本人、所属組織、大学・研究機関、政府・公的機関、国会図書館等の書誌、本人インタビュー、テーマに関する一次資料まで。書評・Amazonレビュー・読書メーター・書評ブログ・第三者要約ページは禁止。

検索結果に偶然出てきた場合も、タイトルの評価語もスニペットも星評価も使わない。開かない。Sourcesにも記録しない。

情報が足りなければ、レビューで埋めずに「確認できなかった」と書く。

実際、v1.0の再テストでStage Aに使われたのは、出版社、IPA、参議院、東京大学、IGPI、本人インタビューだけだった。

Projectを立ち上げる。Skillで読書のための背景情報を準備する。その環境の中で、本そのものは自分で読む。

Reading Project Starterは、**読書そのものをするAIではなく、「自分で本を読むための環境を作るAI」**という位置づけになった。

締めたら、成果物は短くなった

ただ、Stage Aを締めたことには代償があった。同じ『DXの思考法』で、修正前と修正後の出力を比べるとこうなる。

ファイル	修正前	v1.0
01_book-context.md	8,789	5,726
02_author-context.md	12,609	7,783
03_reviews.md	13,859	8,400

（バイト数）

3〜4割減っている。

原因を断定はできない。両方とも一度ずつしか走らせていないし、Web調査の結果は毎回同じにならない。ただ、使える情報源を絞って「確認できなければ確認できなかったと書け」と命じた以上、記述量が減るのは筋が通る。

そして私はこの短くなった方を選んだ。読む前に受け取る情報は、多い方がいいわけではない。

……のだが、このSkillをどこから起動するかで、この後かなり遠回りをすることになる。その話は次回。

これは速く読むための仕組みではない

似たような方法をすでに実践している人は、おそらくたくさんいると思う。

それでも、自分が本を読みながら感じた違和感から「こういう仕組みがあればいいのではないか」と考え、自分で形にしてみることには意味があると思っている。

AIを使わない読書へ戻りたいわけではない。AIには強力な知識検索能力があり、分からないことをその場で掘れる。自分の考えを投げれば、一人では気付かなかった角度から問い返してくれる。読書はかなり面白くなる。

だからAIを排除するのではなく、AIが強すぎるからこそ、どこまで任せるかを設計する。

これは、本を速く読むための仕組みではない。AIがある時代に、あえて自分で本を読み、自分で考えるための仕組みである。