AI時代に技術書を読む理由 ― 脳内インデックスとしての読書

はじめに

AIに聞けばたいていのことが返ってきます。コードの書き方も、設計の定石も、用語の定義も、フレームワークの使い分けも、相応の精度で答えが出ます。この前提に立ったとき、技術書を腰を据えて読むことには、どんな意味が残るのでしょうか。

「教養として」「深い理解のために」といった答えは、間違ってはいませんが少し弱い気がします。なぜなら、AI登場以前から成り立っていた論理の延長でしかないからです。AI後の世界で読書を擁護するなら、AIを使いこなすという行為それ自体に組み込まれた機能として読書を位置づける必要があると思っています。

本稿の主張はシンプルです。技術書を読むという行為は、脳内にインデックスを構築する作業です。データベースのインデックスと同じく、それは単なる記憶でも教養でもなく、検索と意思決定の効率を大きく変える構造です。AIに聞くという行為の質は、聞き手の脳内インデックスの質に強く依存します。だから読むのです。

なお「脳内にインデックスを構築する」という比喩自体も学習論やメタ認知の文脈で古くから語られてきたものですが、新しいのは、AIという外部の巨大なデータ層が手に入ったことで、学習論の話を超えてAIに対する動作原理として実装レベルで効くようになったことだと考えています。

読書とはポインタを貼ることだと思う

読書によって脳内に残るものは、データベースのインデックスと似た性質を持っています。一冊の技術書を読み終えた後、内容を一字一句覚えていることはありません。残るのは「この問題はあの本の中盤で触れられていた」「これはあのパターンに分類される話だったはずだ」というポインタの集合です。

たとえばAIにエラーリトライ機構を相談していて、「指数バックオフでリトライすれば大丈夫」と返ってきたとします。なにか違和感がある。中身までは思い出せませんが、「リトライは冪等性が前提だと、確か信頼性設計の本で読んだはずだ」というポインタが立っている。そこから「このAPIは本当に冪等か? 副作用のある操作をリトライしたら何が起きるか?」と問い直せる。ポインタの中身を覚えていなくても、その存在が次の問いを生みます。

つまり、技術書を読む目的は内容を覚えることではなく、後から呼び出すためのポインタを脳内に貼ることにあります。

なぜインデックスが効くのか

インデックスを持つことは、AI時代に2つの次元で効いてきます。

第一に、プロンプトを書く負担が下がります。 例えばキャッシュの実装方法をAIに教えてほしいときに

Redisをキャッシュ層として使う場合、Write-ThroughとWrite-Behindのトレードオフを踏まえて、強整合性とレイテンシのどちらをどこまで犠牲にすべきか

とプロンプトを書くとします。まずこのプロンプトを書くにはRedisの固有用語と概念を持っている必要があります。もちろん、AIと壁打ちをして「Write-Through」や「Write-Behind」のような用語にたどり着くこともできるでしょう。しかし、毎回ゼロからこれらの用語を壁打ちして言語化していると、それだけでMP(RPGでいうマジックポイント)が削られていきます。対照的に、脳内インデックスを貼ることは、一回の対話あたりのMPコストを下げる行為でもあります。読書は新しい知識を入れるだけでなく、AIを使いこなす際のランニングコストを下げる投資、とも言えそうです。

第二に、ハルシネーションを照合できるようになります。存在しないライブラリのメソッドを断言してきたり、廃止済みのAPIシグネチャを現役のように示してきたりした場合に、これを検知しやすいのは、答えを照合する独立した参照点を脳内に持っている人です。インデックスのない領域では、ハルシネーションは検知されないまま自分の意思決定に組み込まれていきます。

それこそ「自分が知らない領域こそAIに聞けばいい」と思いがちですが、実際にはその領域でこそ、AIの誤りに最も気づきにくい。これは自動化された出力を過信しがちな傾向（automation bias）として古くから観察されてきた現象とも整合します ^[1]。

土台のない領域こそAIに頼りたくなるが、そこでこそAIに騙されやすい――このねじれがあるからこそ、インデックスを貼っておくことに価値があります。

では、なぜ書籍なのか

脳内インデックスを作る経路は、実戦経験・公式ドキュメント・AIとの壁打ちなど複数あります。それでも本稿が技術書を推すのは、技術書が体系性・順序立て・網羅性を設計済みの形で渡してくれる入力だからです。

著者が長年かけて整理した「領域全体の地図」が一冊に収まっていて、自分がまだ経験していない失敗パターンや、思いつかなかった選択肢まで含めて、構造ごと取り込める。これは他の経路では取りこぼされがちな書籍の強みです。実戦経験は自分が遭遇したサンプルに偏りがちで、未経験の領域には届きません。AIとの壁打ちは断片を補完してくれますが、断片同士を繋いで全体像にする作業は自分側に残ります。書籍はその「全体像」を最初から渡してくれる。インデックスを作る経路として、書籍は時間効率と網羅性の両立に優れている、というのが本稿の見立てです。

AI Slopの時代に読解力が問われる理由

ここまでが「AIに問うためのインデックスをどう持つか」の話だとすれば、ここからは「そのインデックスに何を入れるか」、つまり入力の質の話に移ります。

AIが生成した薄い文章――いわゆるAI Slop ^[2]――が世の中に溢れることは避けられないと思います。もちろんAIの出力すべてがSlopなわけではない一方で、Slopの絶対量が増えるなかで読み手側に選別の手間がかかってしまいます。ここで問われるのが、

入力をフィルタする読解力です。飛ばし読み・要点抽出・現場への落とし込みといった読書術は、AI Slop時代に

低品質な入力から脳内インデックスへ何を取り込むかを選別する技術として機能的な意味づけが変わってきます。

良い技術書は構造的に設計された入力で、章立て・用語集・参照構造・段階的な概念の積み上げといった工夫が読み手のために設計されています。これを繰り返し読むと、技術の会得とは別に、副次的に脳内へ読み方のテンプレートが蓄積され、結果的にAI Slopのような構造化されていない文章を読むときに自分の中で構造を補うための基礎となります。

読み方のテンプレートを持っている人は「結局どんな主張をしているのか」「根拠は何か」「どこが借り物か」と仮の構造を組み立てに行けますが、持っていない人の読み方はフラットになりがちです。設計された入力で読解の作法を会得しておかないと、設計されていない入力から有意なインデックスを抽出するのは難しいというのが本稿の見立てです。

QAタイム

公式ドキュメントや技術記事で十分では?

実用ではドキュメントや記事が有効です。ただ、ドキュメントや記事は断片を与えることが多く、書籍は体系を与えます。AIや検索で断片を拾う時代だからこそ、体系を持っている人ほど断片を正しく配置できます。

書籍が要らなくなるのではなく、書籍と断片の役割分担が変わる、と捉えた方が近いのかもしれません。

実戦と公式ドキュメントだけで育ったエンジニアもいるのでは?

確かに、書籍をほとんど読まずに優れた仕事をしているエンジニアは存在します。本稿の主張は「書籍を読まない人はインデックスを持っていない」ではなく、何らかの構造化された経路を経て階層的に組織化されたインデックスを構築する必要がある、というものです。

ただ、書籍には特有の役割があるとも考えています。実戦経験は強力ですが、自分が遭遇したサンプルに偏りがちで、ある領域を体系的にカバーすることは難しいです。書籍は、その領域を体系的・網羅的に取り込める入力です。設計原則の本を一冊読み通せば、自分がまだ経験していない失敗パターンまで含めて、その領域の地図が脳内に貼られる、というイメージです。これは実戦だけでは到達しにくい性質だと思います。

つまり書籍は「唯一の経路」ではなく、体系性と網羅性を補える経路の一つだと思っています。実戦の人が書籍を加えると伸び、書籍の人が実戦を加えると伸びる。両者は競合ではなく補完関係にある、というのが正直な見方です。

AIに聞いて学べばインデックスも作れるのでは?

確かに、分からない用語をAIにその場で説明させる、を繰り返すだけでも、ある程度のインデックスは作れるはずです。むしろ初期コストを下げる経路として有効です。

ただ、AI経由の学習が成立しやすい場合とそうでない場合があると感じています。成立しやすいのは、答えが明確で評価しやすい場合――特定の用語の意味、シンタックスの確認、既知のパターンの参照など。これらはAIが返した答えを自分で評価でき、ハルシネーションも判別しやすい領域です。

逆に成立しにくいのは、概念同士の繋がりや前後関係を踏まえた体系を取り込みたい場合です。AIへの質問は基本的に断片を返してくれる仕組みで、「この章はあの章の前提です」「この概念はあの議論を経由して理解する必要があります」という順序立ての設計は人間側が組み立てる必要があります。良い技術書は、その順序立てを著者が渡してくれます。

つまり、AI経由の学習と書籍経由の学習は、得られるものの粒度が違う、という見方です。両者は対立するというより、片方が断片の単位、もう片方が体系の単位として、補完しながら回るものだと考えています。

構造化された文章を読みすぎると逆にSlopアレルギーになるのでは?

これは正直、刺さる問いです。実際、構造化された入力に慣れすぎると、雑多な文章を「薄い」「読めない」と感じて飛ばすクセはついてきます。本稿が推奨する読み方の副作用として、確かに存在するリスクだと思います。

ただ、ここには切り分けが必要だと考えています。「Slopを速く判別して捨てる能力」自体は時間効率として正しいものです。読むに値しないものを早めに切るのは、認知資源の節約として合理的でもあります。問題なのは、「構造が雑だから内容も無価値」と短絡してしまうこと――つまり形式の弱さで内容を判断するクセです。良い洞察が雑なフォーマットで書かれていることはありますし、それを取りこぼすのは損失です。

つまり、警戒すべきはSlopアレルギーそのものではなく、形式で内容を判断するクセのほうだと思います。これは意識的にメタ認知で抑える必要があります。「自分はいま、形式が嫌で切ろうとしているのか、それとも内容が薄いから切ろうとしているのか」を自問する習慣が、テンプレートを持つ側にも必要かもしれません。

おわりに

AIは強力なデータ層です。ですが、そのデータ層から何を引き出すか、引き出した答えをどう照合するか、次に何を問うかを決めるのは、聞き手の脳内に貼られたインデックスです。

AIに聞ける時代だからこそ、聞ける問いの質を決めるインデックスが問われます。AI Slopが溢れる時代だからこそ、入力からインデックスを構築する読解の技術が問われます。

そして、インデックスも読解技術も、構造化された経路を経て少しずつ構築されていきます。技術書はその経路の一つで、しかも入りやすい一つだと思っています。

だから、技術書を読みましょう。AIを使いこなす力の半分以上は、AIの外側にあります。

• Goddard, K., Roudsari, A., & Wyatt, J. C. (2012). Automation bias: a systematic review of frequency, effect mediators, and mitigators.

  Journal of the American Medical Informatics Association, 19(1), 121-127.https://doi.org/10.1136/amiajnl-2011-000089↩︎

• Merriam-Webster, "2025 Word of the Year: Slop."

  https://www.merriam-webster.com/wordplay/word-of-the-year↩︎