AI時代の技術書の読み方

私はどちらかといえば技術屋なので、昔からハウツー本や技術書をよく読んできました。

技術書は分厚いものが多いので、最初から最後まで読んで、その中から自社でも使えそうなところを拾い、実際に試してみる。

ずっと、そんなやり方をしていました。

ただ、技術書には大きな問題があります。

もちろん内容は役に立つのですが、小説のようにどんどん読み進められるものではありません。

「あとで読もう」と思って買った本が、そのまま机や本棚に積まれていく。

いわゆる「積ん読」です。

でも、AI時代になると、技術書の使い方そのものが変わります。

AIに読ませて、AIに実践させる

最近、Claude CodeやAIエージェントに関する本を3冊購入しました。

合計すると、1,000ページを超えます。

これを全部読んで、重要なところに付箋を貼って、自社に使えるところを考える。

以前なら、それだけでかなりの時間がかかります。

今回は違います。

書籍をPDF化し、Claudeに文字として読み取らせました。

そして、

「この本に書かれている内容と、うちの現在の仕組みを比較して」

と指示しました。

単なる要約ではありません。

本に書かれている考え方や技術と、自社ですでに動いている仕組みを照らし合わせ、

• すでにできていること
• 一部できていること
• まだできていないこと
• 今の自社には必要ないこと
• 取り入れると効果が大きそうなこと

を洗い出してもらいます。

実際にやったこと

ここからは、うちで実際にやったことを具体的に書きます。

1,000ページが「するべきこと17件」になった

3冊を章ごとに読ませ、うちの仕組みと突き合わせた結果、出てきたのは「するべきこと」17件でした。

それを、重要度でA・B・Cの3段階に分けています。

おもしろいのは、3冊で同じことを言っている箇所です。著者も出版社も違う本が、そろって「ここは押さえておけ」と書いている。そこは優先度が高いと判断しました。

たとえば「無人で動くAIには、やり取りの回数の上限を付けろ」は2冊が、「効いているかを測れ」も2冊が書いていました。

いちばん重要な5件は、2日で片づいた

重要度Aの5件は、洗い出した翌日から2日で本番に入れています。

1つ目の「回数の上限」は、以前にAIが3日間止まらずに動き続けた苦い経験があったので、特に効きました。

実装したのも、確認したのもAIです。開発担当のAIが作り、情シス担当のAIが要件を決めて、実際に動かして確かめる。私がやったのは、使っていない外部サービスとの接続を3つ消してよいか、の判断くらいでした。

進み具合は、社内の専用ページで17件すべて見えるようにしています。

本のとおりにはしなかったこと

全部を本のとおりにしたわけではありません。

たとえば「AIが読んではいけないファイル」の決まりは、本では「組織全体で、個人の設定でも外せない形にする」ところまで勧めています。

でも、いきなりそこまで固めると、何かが止まったときに戻すのが大変です。

そこで、まずは自社の設定で1〜2週間動かして様子を見て、問題が出ないのを確かめてから格上げする、という順番にしました。

本にも「まず様子を見ろ」と書いてあったので、これは本の言うことを守ったとも言えます。

比較の目的は、本の通りにすることではなく、自社に合う形で取り込むことです。

本を読んで終わりではなく、その場で改善する

実際に比較してみると、面白いことが分かりました。

たとえば、AIエージェントが仕事をしたあとに結果を記録する仕組みは、すでに自社にありました。AIが「終わりました」と言っても信じず、実際に何が変わったかで完了を判定する仕組みです。

一方で、

さらに、

ということが分かりました。

重要なのは、ここからです。

以前なら、

「なるほど。これは取り入れたほうがよさそうだ」

とメモして、あとで時間があるときに実践していました。

今は、そのままAIに、

「では、うちの仕組みに合わせて改善して」

と頼めます。

1つ目の「失敗から直す」ほうは、ループエンジニアリングとして別の記事に書きました。失敗を見つけ、原因を調べ、手順書の直し案を作るところまでAIに回させる仕組みです。

2つ目の「費用と成果」は、新しい管理画面をむやみに作るのではなく、すでにある「仕組み地図」（社内の自動化を一覧にした画面）に、AIや自動化ごとのコストと成果を並べるタブを足しました。

費用と成果を並べたら、「採算が出せるもの」は0件だった

ここは正直に書きます。

社内で動いている仕組み33個について、AIの利用量・直接の費用・成果の指標を横に並べてみました。

結果、「この自動化はいくらの利益を生んでいる」と金額で言えるものは、0件でした。

理由は2つです。

• 人が同じ作業をしたら1時間いくらか、という社内の基準が決まっていない。
• 使った分だけ料金がかかるAI（画像生成など）の使用量を、記録していなかった。

さらに、いちばんAIを使っていた処理を見ると、1か月で2,600回以上動いているのに、成果として数えられるものが見えていなかったことも分かりました。

「使っているが、成果が見えない」。

本を読まなければ、この状態に気づくのはもっと先だったと思います。次は、1時間あたりの基準と、成果の数え方を決めるところからです。

つまり、

という一連の作業の多くをAIが担当できるようになりました。

1,000ページを「自社に必要な部分」に圧縮する

ここが一番大きいと思います。

技術書1,000ページすべてが、自社に必要なわけではありません。

初心者向けの説明もあれば、すでに導入している内容もあります。

逆に、自社が気づいていなかった重要な考え方が、数ページだけ書かれていることもあります。

今回で言えば「記憶の目次は、ある長さを超えると後ろが読まれない」という話は、3冊目では触れられておらず、2冊目にだけ書かれていました。うちはその上限の手前まで来ていたので、知らなければ気づかないまま、ある日AIが大事なことを忘れていたはずです。

人間が読む場合、その数ページを見つけるために、何百ページも読む必要があります。

AIなら、

「自社に足りない部分だけ探して」

と頼めます。

そして見つけたら、

「重要な順に並べて」

さらに、

「上から実践して」

と進められる。

3冊の分厚い本を買って、読破することなく、自社に必要な部分だけを取り込める。

これはかなり大きな変化です。

技術書以外でも同じことができる

今回は、ちょうど取り組んでいるAIエージェント組織の構築で試しました。

でも、この方法はAIやプログラミングだけの話ではありません。

たとえば、

• Web集客
• SEO
• 広告運用
• マーケティング
• EC運営
• 組織づくり
• 業務改善
• 経営

など、いろいろなテーマで使えるはずです。

マーケティングの本を数冊読ませ、

「この本の内容と、うちのマーケティングを比較して」

と頼む。

すると、自社でまだやっていない施策や、弱い部分が見えてきます。

そこから効果が高そうなものを選び、AIに実践してもらう。

これからは、本から知識を得るだけではなく、

そんな使い方ができるようになります。

大事なのは「要約」ではない

AIに本を読ませるというと、

「長い本を要約してもらえる」

という使い方を最初に思いつきます。

もちろん、それも便利です。

でも、本当に価値があるのはそこではありません。

重要なのは、

そして、

ここまでやって、初めて本の知識が成果につながります。

そのためには「自社を知っているAI」が必要

ただし、この方法を使うには条件があります。

AIが自社のことを知らなければ、

「一般的にはこうしたほうがいいですよ」

という回答しかできません。

今どんなシステムが動いているのか。

どんな仕事をしているのか。

何を自動化しているのか。

どんな問題を抱えているのか。

何を大事にしている会社なのか。

こうした情報をAIが理解しているからこそ、

という比較ができます。

実際、今回の比較でAIは、本の推奨を読むたびに社内の設定ファイルや手順書、動いているプログラムを開いて「これはもうある」「これは形が違う」と照らし合わせていました。社内の仕組みを普段から文書と台帳に残していなければ、この比較はできなかったはずです。

このサイトで何度も書いている、

という話につながります。

AI時代、本は「読むもの」から「実装するもの」へ

これまでは、

でした。

これからは、

になります。

人間の役割は、全部を覚えることではありません。

ここに変わっていくのだと思います。

積ん読されていた分厚い技術書が、会社を改善するための「材料」になる。

すごい時代になりました。

失敗から自分で強くなる：ループエンジニアリングを会社で実践してみた コンテンツ一覧へ