KENTEM TechBlog

建設業のDXを実現するKENTEMの技術ブログです。

読書メモを諦めずに済んだ話

この記事は、 テックブログ強化月間 リレーブログ企画2026 参加の記事です。

AI活用の話でよく目にするのは、AIを使った開発であったり、AIフレンドリーなチーム構築であったり、あるいはAIの上手な使い方みたいなテクニックだ。

しかし、今回はそんな「AIに作業させる」先進的な話ではなく、「AIで作業を楽にしてもらった」という、いち利用者の視点で書いてみたい。

私の読書メモ問題

私は常々、読書メモというものが億劫だった。

かといって、一度読んだら理解できるわけもなく、なんなら二度読み直してもさっぱり頭に入ってこない才能の持ち主である。そのため、本の内容を理解するためには、文字なり声なり図形なり、何らかの形でセルフマルチモーダルコンテキスト(造語)に変換して、自分自身に注入する必要がある。

要するに「読んだだけ」では何も身につかないタイプである。

PCも、ノートも、iPadも、ダメだった

PCで取ろうとした

最初はPCでメモすることにチャレンジしていた。共有も楽だし、検索もできるし、合理的に思えた。

しかし、現実は厳しかった。

  • キーボード入力が絶望的に遅い。
  • キーを打つために本を「置く」工程が地味に集中を切る。
  • PC画面を見ていると目が疲れる。

手書きノートに移行

それならばと、ノートに移行した。

ノートは良かった。自由にまとめられるし、構造図もパッと描ける。自分のイメージを固めやすく、理解を深掘りするには最適だった。

…理解までは。

問題は、その後である。字が汚かった。 自分で書いたメモを後から読み返しても、何が書いてあるかわからない。「なんだこれは」レベルである。さらに、どこかに共有しようと思えば、結局それをPCに打ち直す必要がある。なんだこれは苦行か?

途中、iPadによる手書きメモにも手を出した。が、フォルダ整理を一切しなかったのですぐにメモが散らかり、断念した。「自分には向いていない」と思い知らされた。

私の欠点は2つ

つまり、私の欠点は以下の2つである。

  1. 読んだだけでは分からない
  2. ノートまとめが壊滅的に下手

私は、一度読んでわかる天才でもなければ、ノートを綺麗にまとめられる秀才でもない。むしろ、三度読んでも考察は深まらず、まとめたつもりの文章は「まとめた気に"なっただけ"」にしかならない限界凡人である。

私は血迷って自分の欠点も分析した。 以下の特徴があった。

  • キーボードは使いたくない。
  • 場所を自由にしたい (PCを持ち出したくない)。
  • 手書きも避けたい。

わがまま過ぎて悲しくなった。 自分の欠点を分析することは、安易にしないことをおススメする。

Typeless をご存じだろうか

さて、突然だが、皆さんはTypelessをご存じだろうか。 AquaVoiceでもいい。まぁそういった類のAI音声入力アプリならなんでもよい。

www.typeless.com

aquavoice.com

これらのアプリケーションは、私にとって希望であった。

最初の用途は読書メモではなかった。Claude Code への指示出しに使っていただけである。しかし、自分の考えを1〜3分ほど喋り続ける作業をしていたある日、ふと思った。

「あれ? これ、散歩中にもメモできるのでは?」

これが発端である。

そこから「ながらメモ」を色々試した。結論として、最もハマったのが 読書メモ だった。

スマホを立てて、マイクボタンを押すだけ

私が実際にやっているフローはこうである。

  1. 本を読む前に、Github Issue を1つ作る (これが「この本のメモ」になる)。
  2. スマホを目の前に立てておく。
  3. 本を読む。
  4. 章ごと、あるいは気付いたタイミングでマイクボタンを押し、喋る。
  5. 文字起こしされたものをそのままIssueに貼る。

それだけである。 (Issueやコメントを付けるのが面倒という主張は無視する。その改善策はClaude Codeの方が5億倍詳しい。)

ツール構成は以下:

  • Typeless (スマホ対応のAI音声入力)。AquaVoice もiOS対応している。
  • Github Issue。1冊1Issueで、章は Issueのコメント で分けている。

「1冊1Issue + 章はコメント」という単位が、思いのほか便利だった。Claude Code を介して章ごとの整理や編集を任せられるし、何より 本単位でメモが自然に整理される

キーボードは使わない。手書きもしない。場所も自由。 私の欠点が全て救われた。

前言撤回。自分の欠点を分析してみるのも悪くないかもしれない。

ちょっと発展

私は読書メモIssueから、勉強会の発表資料も作っている。やり方は単純で、Claude Codeに丸投げ する。Issueを渡し、どんなスライドを作りたいかを2〜3分喋って指示する。それだけだ。

ただし、AIに全部やらせるわけではない。線引きはこんな感じである。

  • AIに任せる: 自分のメモを整理するところまで。
  • 自分でやる: 構造図 (自分の理解が露骨に出るから)、スライドの主張部分。

ここで、私は1つの発見をした。

AIに自分の考えを説明し、生成された出力が 自分の理解と一致したとき に初めて、自分の中で「正確に言語化できて腑に落ちた」と感じる。逆に、出力にちょっとでも違和感があれば、そこは自分の理解がまだ甘い部分である。そこを深掘ると、理解がもう一段進む。

「自分で書く」より「AIに書かせて答え合わせする」方が、少なくとも理解面では私にとってメリットだった。(資料の質やデザインの話は…まぁ、別の話である。)

量ではなく、質が変わった

正直に言うと、このやり方で 読書のペースは変わっていない

しかし、「読む → 言語化する」のサイクルが回るようになったことで、本の主張が自分の中に取り込まれやすくなった。読書の 量ではなく、質に効いている 感覚がある。

副次効果として、Issueは 自動あらすじ機能 にもなっている。期間が空いて続きを読むとき、メモをサッと洗うと「ああ、こういう話だった」と思い出せる。…まぁ、私は見返すほど高尚な人間ではないので想像である。

それから、これは思いがけない効果だったが、他人と本の話ができるようになった。一度言語化してあるので、「自分はこの本を読んでどう感じたか」をすぐ説明できる。同じ本を読んだ人と議論できるのも、地味だが嬉しい変化である。

エピソードトーク?

外でも読書メモが取れる環境を手に入れた私は、意気揚々と公園に出かけた。本を読みながらボツボツと喋る。…太陽光が本に反射してまぶしい。挫折した。

ならばカフェへ、と移動した。本を開き、マイクボタンを押す。…店内で喋っているのは私だけだった。

そんなわけで、せっかく場所自由な環境を手に入れたのに、結局、家

ただ、それでも続いている。場所はどこだろうと便利だったらそれでいいのだ。泣いてなんかない。

私たちも利用者だ

AIによって開発は確かに変わった。が、開発以外でもAIはもっといろいろ便利になっている。

私はこのワークフロー以外にも、たとえば Github Project で個人タスク管理を始めたのも、AIに後押しされた個人カスタマイズの結果である。これもまた、別の機会に書きたい。

開発者という側面にこだわらず、1人の利用者としてAIを使ってみる と、もっと楽しめるかもしれない。

このブログで伝えたいのは、それだけである。

おわりに

KENTEMでは、様々な拠点でエンジニアを大募集しています! 建設×ITにご興味頂いた方は、是非下記のリンクからご応募ください。 recruit.kentem.jp career.kentem.jp