じゃあ、おうちで学べる
本能を呼び覚ますこのコードに、君は抗えるか
読解力を分解してちゃんと文章を読む。
はじめに
自分の読解力に絶望する瞬間というものがあります。
たとえば、エラーログを読んでいるとき。無意識のうちに「こういうエラーだろう」という仮説を立てて、その証拠を探すように読んでしまっていました。問題を解決した後で同じログを読み返すと、「なんでこんな読み方をしたんだ？」と首をかしげます。明らかに違うことが書いてあるのに、自分の仮説に都合のよい部分だけを拾い読みしていました。
エラーログという機械が出力するシンプルな文章ですら、こうなのです。もっと複雑なドキュメントなら、どれほど読み間違えていることでしょうか？ライブラリのドキュメント、APIリファレンス、技術記事、PRのコメント、issueの議論、Slackでのやり取り。すべて同じ問題を抱えている可能性があります。
これは挑発でも誇張でもありません。「文章が読める人」は想像以上に希少で、自分も含めて、多くの人は書いてあることを読んでいません。自分の主張や仮説、感情があって、それに合うように拾い読みしているだけなのです。
なぜこんなことが起きるのでしょうか？それは人は文章を読む前から、すでに何らかの主張や仮説、感情を持っているからです。そして無意識のうちに、それを正当化できる「都合のよいワード」だけを探している。文章全体の文脈や意図を理解するのではなく、自分の主張や仮説にマッチする断片だけに反応する。これは読解ではありません。結論ありきの確認作業です。
今の時代、わからないことがあれば、ChatGPTやClaudeに聞けばいい。生成AIは、いつでも、何度でも答えてくれます。これは本当に素晴らしいです。でも——生成AIがあれば読解力は不要になるのでしょうか？
違います。逆だと思っています。生成AIによって読解力は底上げされます。ただし、それは生成AIをどう使うかにかかっています。生成AIを正しく使えば、読解力を飛躍的に高められます。でも、間違った使い方をすれば、読解力は逆に衰えます。
この記事では、「読む」という行為を分解し、それぞれの壁をどう超えるか、そして生成AIをどう活用すべきかを語っていきます。
このブログが良ければ読者になったり、nwiizoのXやGithubをフォローしてくれると嬉しいです。では、早速はじめていきます。
読解力は分解可能なスキル群です
スキルというのは、単一の能力で成り立っているわけではないことが多いです。だいたいは複数の能力の集合体です。
コーディングがうまくなりたい？それなら取り組むべきことは山ほどあります。言語仕様を深く理解する、デザインパターンを学ぶ、Effective 〇〇のようなベストプラクティスを身につける、テストの書き方を学ぶ、デバッグの技術を磨く。さらに、メモリ管理を理解する、並行処理を扱えるようになる、セキュリティや運用を考慮できるようになります。
でも、技術的なスキルだけじゃないです。コミュニケーション能力を高める、他人のコードを読む力をつける、レビューでフィードバックをする、技術的な議論ができるようになる。業界知識を身につける、ドメイン知識を深める、チーム開発の進め方を学ぶ。
コーディングというスキルは、技術、人間関係、知識という軸からなる、いくつものスキルの集合体なんだと思います。
漠然と「コーディングが上手くなりたい」と思っているだけでは、何をすればいいかわかりません。でも分解して「Rustの所有権システムを深く理解する」と具体化すれば、The Rust Programming Languageを読む、borrowチェッカーのエラーと向き合う、といった具体的な練習メニューが見えてきます。「デザインパターンを学ぶ」と具体化すれば、GoFのパターンを実装してみる、OSSのコードでパターンを探す、といった具体的な行動が見えてきます。
読解力も同じです。
書いてあることを正確に読むには、実はいろんなスキルが要ります。語彙力、文法理解力、主語・述語の把握、修飾関係の理解、論理構造の把握、情報の正確な抽出。こういった「書いてあることを正しく読む」基礎的なスキル。
さらに、文脈の理解、推測力、共感力、批判的思考、バイアスへの気づき、メタ認知。こうした「行間を読む」応用的なスキル。
そして、抽象化能力、本質を見抜く力、問いを立てる力、情報の優先順位づけ。「何が本当に重要なのか」を見極める統合的なスキル。
読解力もまた、複数のスキルの集合体です。
上達とは分解して考えること
どんな能力でも、「取り組めるまで分解して考えること」が重要です。漠然と上手になりたいでは、いつまで経っても上達しません（天才を除く）。
分解しないとどうなるでしょうか？「ドキュメントをちゃんと読めるようになりたい」では漠然としすぎて何をすればいいかわかりません。練習のしようがないです。でも「仮説を立てる前に、書かれている情報を網羅的に抽出する」と分解すれば、明日から実践できる具体的な読み方が見えてきます。エラーログを開いたとき、まず全行を読んでからメモ帳に情報を列挙する、という具体的な行動に落とし込めます。
壮大に見えた挑戦も、分解してみれば、シンプルなタスクの積み重ねでしかありません。コーディングも、読解も、他のどんなスキルも同じです。頭の良さが成功の命運を分けるほど高尚な仕事はありません。必要なのは、分解する視点と、一つずつ取り組む地道さです。
この原則は、コーディングでもドキュメントの読解でも、あらゆるスキルに共通しています。そして、生成AI時代においても、この原則は変わりません。むしろ、生成AIがあるからこそ、読解力を分解して鍛えることが、より重要になります。分解できていなければ、生成AIに「何を」「どう」聞けばいいのかもわからないのですから。
読解力には3つの段階があります
読解力には、大きく3つの段階があります。この記事では、その3つの段階を一つずつ分解して説明していきます。
ただし、これは一方通行の階段じゃありません。私たちはこれらの段階を行ったり来たりします。第3段階まで到達した人でも、疲れているときや慣れない分野の文章を読むときは、第1段階に戻ります。
そう、読解力とは一定じゃありません。
「能力」という言葉には「力」という漢字が含まれています。そのせいか、まるで機械のスペックのように「私の読解力は○○レベル」と固定値で捉えてしまいがちです。筋力のように、一定の出力を常に出せるものだと思ってしまいます(筋力も…というツッコミもあります)。しかし実際はそうではありません。能力はその瞬間の状態に大きく左右される可変的なものです。
読解力は文脈によって大きく変わります。自分の専門分野のドキュメントなら第3段階まで読めるのに、まったく知らない分野の文章なら第1段階で苦戦します。朝の集中できる時間なら深く読めるのに、疲れた夜には表面的にしか読めません。
特に感情状態の影響は大きいです。怒りや悲しみを抱えたまま技術記事を読んでも、書かれている内容が頭に入ってきません。これは単に集中力が切れるという話ではありません。感情が認知のリソースを占有してしまうからです。仮に100のキャパシティがあっても、感情に30使われていたら、読解に使えるのは70だけになります。
こうした揺らぎは、誰にでもどんな能力にもあります。この理解は、自己評価にも影響します。ある日うまく読めなかったからといって「自分には読解力がない」と結論づけるのは早計です。単にその瞬間の条件が悪かっただけかもしれません。
だからこそ、筋力を鍛えるように、読解力も鍛える価値があります。鍛えるとは、能力の底上げと安定化を意味します。鍛えておけば、疲れているときでも、新しい分野でも、感情が揺れているときでも、ある程度は正確に読めるようになります。
第1段階：正確に読む
これは読解の土台です。書かれていることを正確に理解する力です。
エラーログで考えてみましょう。第1段階では、どのコンポーネントが、どんな状態で、どんなエラーを出したのかを正確に読み取ります。エラーメッセージの構造を理解し、どこで何が起きたかを正確に把握します。
技術記事なら、著者が説明している手順や概念を、一つ一つ正確に理解することです。「この関数は非同期です」という記述があったとき、それが何を意味するのか（Promiseを返すのか、コールバックを受け取るのか、await可能なのか）を正確に読み取ります。
Rustのコンパイラエラーも良い例です。borrowチェッカーのエラーが出たとき、「所有権の問題だ」とざっくり理解するんじゃなくて、どの変数が、どのスコープで、どのように使われようとして、なぜそれが許可されないのか、を正確に読み取ります。
これはプログラミングにおける「構文を理解する」に相当します。変数、関数、制御構文といった基本がわからなければ、その先のロジックを理解することはできません。読解も同じです。まず書かれていることを正確に読む。この段階なしに、次の段階には進めません。
第1段階の壁：基礎訓練の不足
多くの人はこの第1段階で躓いています。基礎訓練が不足しているんです。
例えば、次の2つの記述の違いが分かるでしょうか？「システムは、2025年1月、レガシーAPIを廃止し、クライアントには新APIへの移行を推奨した」と、「2025年1月、レガシーAPIは廃止され、システムはクライアントから新APIへの移行を推奨された」。答えは「異なる」です。前者ではクライアントが移行を推奨されているのに対し、後者ではシステムがクライアントから推奨されている（主従関係が逆）です。
もっと身近な例で見てみましょう。技術記事に「このメソッドは非同期です」と書かれています。多くの開発者は「わかった」と思って先に進みます。でも実際には、「非同期である」という情報だけでは不十分です。Promiseを返すのか、コールバックを受け取るのか、await可能なのか、エラーハンドリングはどうするのか。これらの情報も読み取らなければ、正確な理解とは言えません。
コーディングに例えるなら、コードはたくさん書くが、変数のスコープを理解せず、型システムの理解もせず、言語仕様の訓練もしない。基礎がないから複雑なシステムを作れない、という状況です。文章の読解も同じ。たくさん読むが、文構造の理解訓練はせず、論理的思考の訓練もしない。基礎がないから正確に読めません。
この壁を超えるには
基本的な訓練が重要です。
主語・述語を意識する。ドキュメントやエラーメッセージで、「誰が」「誰に」「何を」しているのか。これを正確に把握する癖をつけます。
仮説を立てる前に全部読む。私はこれでエラーログの読み間違いが激減しました。全行読んで、情報を列挙してから、それから仮説を立てる。順番を変えるだけで、見える景色が変わります。
文脈を意識する。これはリファレンスなのか、チュートリアルなのか、トラブルシューティングなのか。文章の「置かれた場所」で、読み方も変わるべきなんです。
音読してみる。本質的な訓練ではないが、驚くほど効果的です。声に出すと、飛ばし読みができなくなる。一文字ずつ確実に読むことを強制される。視覚だけでなく聴覚も使うので、「読んだつもり」が減る。特に、複雑なエラーメッセージや理解しにくいドキュメントを読むときは、小声でもいいから音読してみるといいです。読むスピードが落ちる分、思考する時間が生まれる。主語と述語の関係も掴みやすくなります。
生成AIは、この基礎訓練を補助してくれます。わからない専門用語が出てきたとき、集中力を途切れさせずに「『非同期処理』とは何ですか？」と聞ける。複雑な文章の主語・述語の関係がわからなくなったとき、「この文章の構造を分解してください」と聞ける。技術記事を読んで「わかった」と思ったとき、「私はこう理解しました。[あなたの理解]。この理解は正しいですか？」と確認できます。
ただし、まず自分で読むことが前提です。最初の一文を読んですぐ「要約して」と頼むのでは、読解力は鍛えられません。生成AIに分解してもらった後、必ず自分でもう一度読み直します。生成AIの説明も間違えることがあるので、公式ドキュメントでも確認します。生成AIはあくまで訓練の補助です。
第2段階：裏を読む
第1段階で書かれていることを正確に読めるようになったら、次は書かれていない意図を汲み取る力が必要になります。
エラーログで考えてみましょう。第2段階では、エラーの背後にある状況を推測します。タイムアウトエラーがあったとき、単に「タイムアウトした」という事実だけじゃなく、「なぜタイムアウトしたのか」を考える。ネットワークが遅いのか、サーバーが応答していないのか、ファイアウォールで遮断されているのか。
技術記事を読むときも同じ。「この実装方法を推奨します」という記述があったとき、なぜ著者はそれを推奨するのか、どんな状況を想定しているのか、逆にどんな状況では推奨しないのか、を推測します。
PRのコメントで「ここ、もっと良い方法があるかも」と書かれていたとき、それは単なる提案なのか、変更を強く求めているのか、それとも議論を始めたいのか。書かれている言葉だけでなく、その裏にある意図を読み取る力です。
Rustのドキュメントを読むとき、「この関数はunsafeです」という記述の裏には、「注意深く使わないとメモリ安全性が損なわれる」という警告がある。「このトレイトはSendです」という記述の裏には、「スレッド間で安全に送信できる」という保証があります。
これはプログラミングにおける「ロジックを理解する」に相当します。構文を理解した上で、なぜこのデザインパターンを使うのか、なぜこのデータ構造を選ぶのか、といった背景や意図を理解する段階です。
第2段階の壁：認知バイアス
この第2段階では大きな壁にぶつかります。それが認知バイアスです。
エラーログを読むとき、私は無意識に確証バイアスの罠にはまっていました。確証バイアスとは、自分の信念を裏付ける情報を探し求め、それ以外を見ない・軽視する心理学の概念。既存の仮説として「これはメモリの問題だ」と思っていると、フィルターが発動し、メモリに関する情報だけを拾うようになる。結果として、ネットワークに関する情報を見落としてしまいます。
GitHubのissueでも同じことが起きています。「この機能の実装、19時までに終わらせるのは無理だった。他のタスクもあるし、月1回くらいしかこのペースで進められない」というコメントを読んで、「マネジメントに文句を言っている」と受け取る人がいます。でも、よく読んでほしいです。このコメントには「マネジメントが悪い」とは一言も書かれていない。書かれているのは、ただ「間に合わなくて申し訳ない」という弱音だけです。
なぜこのような誤読が起きるのか？「この人は以前も遅れていた」「いつも文句を言っている」という既存の印象があると、フィルターが発動し、「マネジメントを批判している」と読み取ってしまいます。でも実際に書かれていることは、「間に合わなくて申し訳ない」という弱音だけです。
ここで重要なのは、私たちの直観は想像以上に信頼できないということです。
「直観に従えば大丈夫」——もしこれが本当なら、文章の誤読はほとんど起きないはずです。エラーログを読めば直観的に原因がわかる。ドキュメントを読めば直観的に使い方がわかる。コメントを読めば直観的に意図がわかる。
でも現実はどうでしょうか？
私たちは、人生で何千、何万もの文章を読んできました。それでも、誤読は頻繁に起きます。「ちゃんと文章を読める」と自認している人でも、エラーログを読み間違え、ドキュメントを誤解し、コメントを誤読しています。
つまり、直観的な判断は、それなりの確率で裏切ります。
なぜか？直観は過去の経験とパターン認識に基づいているからです。「このエラーは以前見たことがある」「この書き方は○○を意味する」——そう直観的に思った瞬間、私たちは確証バイアスのフィルターをかけてしまいます。直観に従うほど、書かれていることではなく、「自分が予想したこと」を読むようになります。
だからこそ、意識的な読み方が必要なんです。直観を完全に排除することはできません。でも、「直観は間違うかもしれない」と自覚するだけで、読み方は変わります。「直観的にこう思う。でも、本当にそう書いてあるか？」と自問する癖をつける。これだけで、誤読は激減します。
私たちは、自分が信じたいものを信じるようにできています。
ちなみに、SNSでは誤読が頻繁に起こります。でも、発信する側の心持ちとして、SNSでは誤読されるのも投稿する内だと思っていたほうが精神衛生上良いんです。SNSという媒体は本質的に誤読を生みやすいからです。文脈が省略され、文字数に制限があり、読者の背景や感情状態も様々です。「炎上」の多くは、この誤読から生まれる。できるのは、自分自身が読む側に回ったとき、「書かれていないこと」を読み取っていないか、常に自問することだけです。
この壁を超えるには
基本的な訓練が重要です。
「書かれていないこと」を排除する。一文字ずつ丁寧に読み、「これは本当に書いてあるか？」と確認し、「自分が勝手に補完していないか？」と自問する。特に、怒りの感情を覚えたときは要注意だ。
複数の解釈を考える。1つの文章に対して、少なくとも3つの異なる解釈を仮定してみる。先ほどの「19時までに終わらせるのは無理だった」なら、①単純に弱音を吐いている、②マネジメントを批判している、③このプロジェクトから離れたいと思っている、という3つの解釈が考えられる。書かれていることだけからは①が最もストレートだけど、「確定」はできません。
バイアスのメタ認知。文章を読んで強い感情（怒りや共感）を覚えたら、ちゃんと読み直し、「自分のバイアスではないか？」と自問し、複数の解釈可能性を列挙する。
生成AIは、別の視点を提供してくれる。「この文章の別の解釈の可能性を3つ教えてください」と聞けば、あなたが思いつかなかった解釈を示してくれることがある。「このコメントには、『マネジメントを批判している』という意図が書かれていますか？」と聞けば、書かれていることと書かれていないことを区別してくれる。
ただし、生成AI自体もバイアスを持っている。生成AIも訓練データに基づいたバイアスを持っているし、あなたの質問の仕方が回答を誘導してしまうこともある。だから、中立的な質問をする。「この文章のトーンを分析してください」といった、オープンな質問をする。そして、まず自分で複数の解釈を考えてから、生成AIで確認します。この順番が大切です。
第3段階：本質を読む
第1段階で正確に読み、第2段階で裏を読めるようになったら、最後は本当に重要なことは何かを見抜く力が必要になります。
エラーログで考えてみましょう。第3段階では、大量のログの中から本当に重要な情報を抽出する。100行のログがあったとき、その中で本当に問題の原因を示しているのはどの部分なのか。表面的には複数の問題が見えても、本質的には1つの根本原因から派生しているかもしれません。
技術記事を読むとき、第3段階では表面的な実装方法ではなく、その根底にある設計思想や原則を理解する。「このコードはこう書く」という表層だけでなく、「なぜそう書くのか」「そもそも何を解決しようとしているのか」を見抜きます。
Rustのドキュメントを読むとき、個々のAPIの使い方だけでなく、所有権システムという言語の根幹にある哲学を理解する力だ。
これはプログラミングにおける「設計を理解する」に相当します。構文とロジックを理解した上で、なぜこのアーキテクチャを採用したのか、トレードオフは何か、本質的な問題は何か、を理解する段階です。
ただし、新しい言語を学ぶときは構文から学び直す必要があるように、新しい分野の文章を読むときは第1段階から学び直す必要があります。これは退行ではなく、自然なことなんです。
第3段階の壁：わかったつもり
第3段階に到達しても、まだ最後の壁がある。これが一番厄介です。それが「わかったつもり」。
「もう理解すべきことは何もない」って思った瞬間、人は思考停止します。新しい視点を受け入れなくなります。成長が、止まります。
エラーログを開いて「あ、これはあのエラーだ」と思った瞬間、思考が停止します。そして仮説に合う部分だけ読んで、結果として問題を解決できません。実際には50%程度しか理解していないのに、「わかった」と思い込んでいます。
エラーログを見て「ああ、これは接続エラーだ」と思った瞬間、「接続設定を確認すればいい」と結論づけてしまいます。でも実際には、設定以外にも、ファイアウォール、タイムアウト、認証、リトライロジックなど、他にも確認すべきことがあるかもしれない。「わかった」と思った瞬間に、これらの可能性を検討しなくなります。
技術記事を読むときも同じ。「この技術は理解した」と思った瞬間、制約条件や例外的な状況を見落とす。「この設計パターンはわかった」と思った瞬間、適用すべきでない場面に気づかなくなります。
この「わかったつもり」は、第1段階から第3段階まで、すべての段階で起こりうります。だからこそ、これが最大の壁なんです。読解力が高い人ほど、自分が「わかったつもり」になっていないかを常に点検しています。
この壁を超えるには
基本的な訓練が重要です。
「なぜ」「そもそも」と問う。なぜこのエラーが出たのか？そもそも何が問題なのか？本当に重要なのはどこか？問いとは、答えをただ探すためのものではなく、物事の本質に近づこうとする"姿勢"そのものです。
要約訓練。情報を要約する際は、「本当に重要なのは何か？」と自問する癖をつける。これは、99%の情報から1%の本質を抽出する訓練です。でも、「これが本質だ」と決めつけてはいけません。それが「わかったつもり」の罠だからです。
情報の精査。情報に触れたら、「それは個人的意見なのか、客観的事実なのか？」と自問する。事実なのか意見なのか、データに基づいているのか印象なのか。この区別が、本質を見抜く力につながります。
生成AIは、理解を検証してくれます。「私はこの技術の本質を『○○』だと理解しました。この理解は正しいですか？他にもっと重要な本質はありますか？」と聞ける。「なぜこの技術が必要なのですか？」と聞き、返ってきた答えに対して「なぜそれが問題なのですか？」とさらに聞ける。5回「なぜ」を繰り返す「5 Whys」を実践できます。長大なドキュメントを読んだ後、「このドキュメントの本質を、3つの文で要約してください」と聞けます。
ただし、生成AIが示した「本質」も、一つの視点に過ぎません。生成AIは、訓練データに基づいて、「多くの人が本質だと考えていること」を答えます。でも、それが本当の本質かどうかは、わかりません。だから、生成AIの答えを「仮説」として扱う。「本当にそうか？」と疑う。他の情報源でも確認します。実際に使ってみて検証します。
そして、まず自分で「なぜ」を考える。自分の考えを生成AIで確認します。この順番が大切です。すべて生成AIに聞いてしまうと、自分で考える力が衰えます。
なぜ読解力を鍛えるべきなのか
ここまで読んで、「めんどくさそうだな」って思いました？正直、わかる。3つの段階、それぞれの壁、訓練方法、生成AIの使い方。別に分けんでもいいやろって思いました？しかも読解力って一定じゃなくて、落ちるらしいし、新しい分野だとまた1からやり直し。
でも——これだけは言わせてほしい。生成AI時代だからこそ、読解力を鍛える価値は計り知れないです。
「最近の人は長文が読めない」——よく聞く話ですが、これを単なる集中力不足だと片付けてはいけません。
SNS、ショート動画、通知、いいね。私たちの脳は短期的な快楽にチューニングされ続けています。このサイクルを何年も繰り返すうちに、長文を読むことが単に「つまらない」だけでなく、苦痛に変わります。文脈を保持しながら論理を組み立てる——この一連のプロセスが、脳にとって「報酬が遠すぎる」活動になってしまうんです。
さらに深刻なのは、読解力の回路そのものが機能低下することです。文脈を保持する力が衰えると、文章を断片的にしか理解できなくなります。
そして、自分の考えを整理する力も、読解力に依存しています。「なぜこのバグが起きたのか」を説明できない。「なぜこの設計を選んだのか」を答えられない。これは語彙不足ではなく、自分の内側で起きていることを掴めず、整理できていない状態です。感じているのに言語化できない。伝えたいのに届かない。誤解されて、孤立感が強まります。
説明できる力は、安心感や人とのつながりの土台です。「自分だけは分かっている」という拠り所があるなら、人はまだ耐えられます。でも、自分の感じや考えを誰も拾ってくれないどころか、自分自身も拾えないとなると、存在の手応えや安心感が一気に揺らぎます。
読解力は他のすべてのスキルを支える土台である
読解力は、エンジニアとしてのキャリアの「土台」のようなものだ。基礎体力に近いかもしれません。
コーディングで考えてみましょう。変数、関数、制御構文といった基礎がなければ、どんな技術も身につかない。Rustの所有権システムを学ぼうとしても、デザインパターンを理解しようとしても、並行処理を扱おうとしても、基礎がないと何も始まらない。
読解力も同じ。読解力がなければ、どんなドキュメントも正確に理解できず、どんな技術も効率的に学べず、どんなコミュニケーションもうまくいきません。
Rustを学びたいとする。でも、Rustのドキュメントを正確に読めなければ、所有権システムを理解できない。borrowチェッカーのエラーメッセージを正確に読めなければ、問題を解決できません。unsafeの意味を深く理解できなければ、適切に使えません。
生成AIに「Rustの所有権システムを教えて」と聞けば、説明は返ってくる。でも、その説明を理解するのも、読解力だ。生成AIの説明が正しいかどうかを判断するのも、読解力だ。
読解力が貧弱だと、コードを書く、設計する、レビューする、ドキュメントを書く、チームとコミュニケーションする、問題を解決する、新しい技術を学ぶ、生成AIを使いこなす、といった、エンジニアとしてのあらゆる活動で誤作動が生じます。
逆に、読解力という土台があれば、すべてがスムーズに機能するようになります。生成AI時代においても、読解力はすべての土台なんです。
読解力の差は、時間とともに指数関数的に広がる
「読解力があるか、ないか」は、1回だけ見れば小さな差だ。でも、時間とともに指数関数的に広がっていきます。
ドキュメントを正確に読める人と読めない人の差は、1回では小さいです。「たった1回の誤解」。でも、1年間ではどうでしょうか？
ドキュメントを読めない人は、週に3回、APIの使い方を誤解します。年間で150回。そのたびに、実装をやり直す必要があります。週に3時間、年間で150時間を無駄にする。実装ミスのせいでバグが増える。デバッグに時間がかかる。納期が遅れる。レビュアーに迷惑をかけます。チームからの信頼を失う。新しい技術を学ぶスピードが遅くなる。結果として、キャリアが停滞します。
生成AIを使っても、この差は変わりません。むしろ、生成AIがあるからこそ、読解力の差は広がる可能性があります。
読解力がある人は、生成AIを補助ツールとして使って理解を深め、さらに読解力が高まる。読解力がない人は、生成AIに全面的に依存し、自分で考えなくなり、さらに読解力が低下します。
1回の差は小さいです。でも、積み重なると大差になります。読解力が高い人は、読むことで新しい知識を得て、さらに読解力が高まる。読解力が低い人は、読むことで誤解を重ね、さらに読解力が低下する。時間とともに、差は指数関数的に広がっていきます。
そして、自分の読解力が揺らぐことを自覚していれば、「今日は疲れているから、このドキュメントは明日読もう」という判断ができる。「怒りを感じているから、一旦落ち着いてから読み直そう」という戦略が立てられる。「この分野は初めてだから、第1段階から丁寧に読もう」という心構えができる。「疲れているから、生成AIに確認してもらおう」という判断ができます。
読解力を鍛えることは、読解力そのものを高めることだけじゃありません。自分の読解力の限界を知り、それに応じた戦略を立てることでもあります。そして、生成AIをいつ、どう使うべきかを判断する力でもあります。
読解はコミュニケーション
「何回説明しても伝わらない」——こんな経験、誰にでもあるでしょう。上司から同じことを何度も指摘される。部下に説明したのに、まったく違うものができあがる。技術記事を読んだのに、実装したら全然違う結果になりました。
多くの人は、これを「伝え方」の問題だと考える。でも、認知科学の研究が示すのは、違う真実です。問題は「言い方」じゃありません。「心の読み方」なんです。
スキーマという名の「当たり前」
認知科学には「スキーマ」という概念がある。これは、人それぞれが頭の中に持っている「当たり前」の枠組みのこと。知識や経験の構造化されたまとまりです。
重要なのは、私たちは物事を「スキーマを通して」理解しているという点です。
エラーログも、スキーマを通して読んでいる。ドキュメントも、スキーマを通して読んでいる。上司の指示も、スキーマを通して聞いている。生成AIの回答も、スキーマを通して読んでいます。
「何回説明しても伝わらない」のは、説明する側と受け取る側で、スキーマが違うからです。
上司が「この機能を実装してほしい」と言ったとします。上司の頭の中には、長年の経験から作られた「この機能」のスキーマがあります。でも、そのスキーマの大部分は、言葉にされていません。一方、受け取る側も、自分のスキーマを通してその指示を理解します。でも、それは上司のスキーマとは違うかもしれません。
結果として、上司は「言ったはずだ」と思い、あなたは「聞いた通りにやった」と思う。でも、出来上がったものは違います。
Rustのドキュメントを読むときも同じです。ドキュメントを書いた人には、Rustの所有権システムについての豊富なスキーマがあります。だから、「この関数はborrowします」という一文で、多くのことが伝わると思っています。でも、Rustを学び始めたばかりの人には、そのスキーマがありません。
そして、生成AIの回答も、あなたのスキーマに依存しています。
生成AIに「Rustの所有権システムを説明して」と聞いたとします。その説明を理解するのは、あなたのスキーマです。C++のスキーマを持っている人と、Pythonのスキーマしか持っていない人では、同じ説明を読んでも、理解する内容が違います。
だから、生成AIに質問するとき、自分の前提知識（スキーマ）を明示することが有効なんです。「私はPythonしか知りません。Rustの所有権システムを、Pythonとの違いを中心に説明してください」と聞きます。
受け手としてどうすべきか
じゃあ、受け手として、私たちはどうすればいいのか？
まず、自分が持っているスキーマを自覚すること。「自分はこういう前提で理解している」と認識する。エラーログを読むとき、「これはメモリの問題だ」というスキーマで読んでいないか？生成AIの回答を読むとき、「自分の知っている範囲で」理解しようとしていないか？自分のスキーマを自覚するだけで、誤読は減ります。
次に、「わかった」を疑うこと。説明を聞いて「わかった」と思った瞬間、実は自分のスキーマで解釈しているだけかもしれません。だから、理解したことを言い換えて確認します。「つまり、○○ということですか？」と聞く。生成AIを使うなら、「私はこう理解しました。[あなたの理解]。この理解は正しいですか？」と聞きます。
そして、質問する勇気を持つこと。「わからない」と言うのは、勇気がいります。でも、わからないまま進むよりは、はるかにマシです。質問することは、恥ずかしいことじゃありません。自分のスキーマと相手のスキーマのズレに気づいて、それを埋めようとしている証拠です。
最後に、柔軟にスキーマを更新することです。新しい技術を学ぶとき、既存のスキーマで理解しようとしがちです。でも、それが足枷になることがある。Rustを学ぶとき、C++のスキーマで理解しようとすると、所有権システムの本質を掴めません。
コミュニケーションは双方向です。説明する側も、受け手のスキーマを想像する努力が必要だし、「伝わったかどうかを確認する」必要があります。受け手も、自分のスキーマを自覚し、「わかった」を疑い、質問する勇気を持ちます。この両方が揃って初めて、「伝わる」コミュニケーションが成立します。
読解力とは、ただ文字を読む力じゃありません。自分のスキーマを自覚し、それを柔軟に更新しながら、相手の意図を理解しようとする力なんです。そして、生成AIを適切に使って、スキーマのズレを埋める力でもあります。
完璧を目指さない。でも「わかったつもり」にもならない
「読解力を磨くこと」と「わかったつもりにならないこと」の間のバランスを見つけることが、本当の知性なんです。
一方で、積極的に理解しようとする。努力して読解力を高める。3つの段階を一つずつ鍛える。基礎訓練の不足を補う。認知バイアスに気づく。「わかったつもり」を警戒する。生成AIを適切に使う。
他方で、完璧を目指さない。常に完璧に読める人はいない。疲れているときもある。新しい分野もある。バイアスに引っかかるときもある。「わかったつもり」になってしまうときもある。生成AIの使い方を間違えるときもある。それは人間である以上、避けられません。
重要なのは、失敗から学ぶことです。
エラーログを読み間違えたなら、「なぜ読み間違えたのか？」と振り返る。確証バイアスに引っかかっていたのか、情報を網羅的に抽出していなかったのか、「わかったつもり」になっていたのか。生成AIに頼りすぎて、自分で考えなかったのか。次は同じ間違いをしないように、読み方を改善します。
完璧を目指さない。でも、失敗から学び、少しずつ改善する。これが現実的な成長の道です。そして、常に「まだ理解できていないかも」という謙虚さを持つ。問いを持ち続ける姿勢を保ちます。
優れたエンジニアは、何年コードを書いても、「完璧に理解した」とは思わない。新しい技術を学び続け、既存の知識を疑い続け、より良い方法を探し続ける。失敗から学び続ける。生成AIも適切に活用する。だから成長し続けられます。
読解力も同じ。どんなに上達しても、「完璧に読めている」とは思わない。失敗から学び続ける。生成AIも適切に使い続ける。だから成長し続けられます。
おわりに
エラーログを読み間違え、ドキュメントを誤解し、コメントを誤読する。「書いてあることを読んでいない」という絶望——この記事は、そんな問題からスタートしました。
そして、「読む」という行為を分解してみました。読解力は複数のスキルの集合体でした。3つの段階があり、それぞれに壁がありました。第1段階の壁は「基礎訓練の不足」、第2段階の壁は「認知バイアス」、そしてすべての段階に共通する最大の壁が「わかったつもり」。
生成AIは、これらの壁を超える補助ツールになる。でも、使い方次第です。まず自分で読む、鵜呑みにしない、依存しすぎない。この原則を守らなければ、読解力は逆に衰えます。
読解力は他のすべてのスキルを支える土台であり、その差は時間とともに指数関数的に広がる。コミュニケーションはスキーマを通して行われるため、自分の「当たり前」を自覚し、「わかった」を疑い、柔軟にスキーマを更新することが大切です。
完璧である必要はありません。でも、失敗から学び、少しずつ改善する。これが現実的な成長の道です。
まずは一つだけ、明日から実践してみてほしい。
明日エラーログを読むとき、こう自問してみる。「仮説を立てる前に、全行を読んだか？」（第1段階）「自分のバイアスで読んでいないか？」（第2段階）「本当に重要なのはどこか？」（第3段階）「自分のスキーマで解釈していないか？」（スキーマの自覚）
明日生成AIに質問するとき、こう実践してみる。「まず自分で読んでから、わからないところだけ聞く」（第1段階）「複数の解釈の可能性を聞く」（第2段階）「理解を言語化して確認してもらう」（第3段階）「前提知識を明示して質問する」（スキーマの明示）
それだけで、あなたの読解力は確実に一歩前進します。
ところで、ここまで「読む」という行為を分解してきました。でも実は、もう一つの行為があります。
「書く」という行為です。
読解力の3つの段階——正確に読む、裏を読む、本質を読む——を理解した今、書き手としての視点も変わるはずです。
「読めない読み手」を嘆く前に、書き手は自問すべきです。読み手が正確に読める文章を書いているか？誤読されにくい書き方をしているか？本質を掴みやすい構造にしているか？
そして何より、読み手の読解力は一定ではないことを理解しているでしょうか？疲れているとき、慣れない分野を読むとき、感情が高ぶっているとき——読み手は第1段階でさえ苦戦します。
さらに、スキーマの違いを忘れてはいけません。書き手にとって「当たり前」のことが、読み手にとっては「初めて聞く」ことかもしれません。
よく言われる文章作法——「結論を先に書く」「一文を短くする」——これらを抽象化すると、すべて読み手の認知リソースを尊重するという原則に行き着きます。読み手は無限の時間と集中力を持っているわけじゃありません。その限られたリソースを、いかに有効に使ってもらうか。
読解力と同じように、文章力も分解可能なスキル群です。読解力を分解して鍛えられるように、文章力も分解して鍛えられます。
読解力を理解することは、文章力を理解することでもありますので書きました。
生成AIがあれば読解力は不要になるのか？——記事の冒頭で問いかけました。
答えは明確です。生成AIがあるからといって、読解力が不要になるわけじゃありません。むしろ、生成AIを使いこなすために、読解力がますます重要になる。そして同じことが、文章力にも言えます。
「わかったつもり」という最大の壁を、常に警戒してほしい。「もうわかった」と思った瞬間が、最も危険な瞬間なのですから。
それでは。
