CodexのComputer Useで、Kindleの読書メモづくりを試してみた。
Computer Useは、AIが画面を見ながらマウスを動かし、デスクトップアプリを操作する機能だ。見た目はとにかく派手で、実際にカーソルが動き、アプリが開き、ボタンが押されていく様子は、いかにも「AIエージェントが働いている」という雰囲気がある。
ただ、いざ実務で何に使うかを考えると、これが意外と難しい。
ファイル操作、メール処理、スプレッドシート、ObsidianやNotionへの書き込み——この手の作業は、API・MCP・CLI・スクリプトで処理したほうが圧倒的に安定する。わざわざ画面を操作させる理由がない。
では、Computer Useはどこで効くのか。
今回いじってみて、ひとつの答えが見えた。API化されていないデスクトップアプリの中に閉じ込められた、自分の知的作業の痕跡を取り出す用途だ。
その典型例が、Kindleである。
Kindleのハイライトは「自分の読書ログ」だ
Kindleで本を読んでいると、気になった箇所にハイライトを引く。
これは単なる本文の抜き書きではない。
その瞬間の自分が「ここは重要だ」「仕事に使えそうだ」「ブログや資料のネタになるかもしれない」と反応した場所だ。
つまりハイライトは、自分の関心のログなのだ。
本の一般的な要約なら、書籍名をAIに渡すだけで作れる。だがそれでは「自分がどこに反応したのか」はどこにも残らない。読書メモとして本当に役に立つのは、平均的な要約ではなく、自分が引いたハイライトを起点にしたメモのほうだ。
そこで今回は、KindleデスクトップアプリをCodexのComputer Useで操作し、『両利きの経営』のハイライトから読書メモを生成させてみた。
出力フォーマットは次のように指定した。
- 一般的な書籍情報・評価のまとめ
- ユーザーのインサイト
- インサイトのまとめ
- 次に読むべき本・関連書
保存先はObsidianの 06_Reading フォルダ。新規Markdownファイルとして書き出させた。
デモ：KindleアプリをComputer Useで動かす
動画では、CodexがKindleアプリを操作して対象書籍を開き、注釈メニューからハイライトを拾っていく様子が見られる。
ちなみに、現在のCodexでComputer Useを使うには、事前にComputer Useプラグインを入れておく必要があった。最初はこの仕様変更に気づかず少し戸惑ったが、プラグインさえ入れれば狙い通りに動いた。
ここで見せたいのは「AIがマウスを動かしてすごい」という話ではない。APIやCLIでは扱いにくい情報が、デスクトップアプリの画面上にしか存在しない——そういう状況で、Computer Useはその情報をAIの処理ラインに接続する手段になる、ということだ。
実際に使ったプロンプト
Codexには、おおよそ次のように依頼した。
kindleのデスクトップアプリを操作して、”両利きの経営”を開き、ユーザーがハイライトした箇所から読書メモを作って。 様式として
- 一般的な書籍情報・評価のまとめ
- ユーザーのインサイト
- インサイトのまとめ
- 次に読むべき本・関連する本 保存は06_Readingフォルダの中に新規mdを作って。 書籍を開いた後、GUIの右上にマウスオーバーするとハンバーガーメニューがあり、その中の”注釈”メニューからハイライトを取得できる。 ローカルDBやSQLからの取得は無効なので、GUI操作だけで達成すること。
このプロンプトで効いたのは、最後の2点だった。
1. GUI上の導線を具体的に書く
Kindleアプリは、書籍を開いただけでは注釈一覧にたどり着けなかった。注釈メニューは書籍を開いただけでは表示されないからだ。GUI右上にマウスオーバーするとハンバーガーメニューが出て、その中に「注釈」がある。
ここまで書かないと、Codexは注釈メニューを見つけられず、途中で迷子になることがあった。
2. 「GUI操作だけで達成しろ」と明示する
これを書かないと、CodexはローカルのアプリDBやSQLからハイライトを探そうとする。しかしKindleはDRMやコピーガードで保護されているため、そこからは取得できない。
厄介なのは、ただ失敗するだけならまだマシで、失敗したあとに存在しないDB構造や取得結果を推測してしまうことがある点だ。つまり、ハルシネーションの温床になる。
Computer Useを使う場合でも、「画面を操作して」とだけ書くのでは足りない。どの画面を開き、どのメニューをたどり、何を見て、何をしてはいけないか。ここまで指定したほうが安定する。
普通のプロンプトというより、作業標準書に近い感覚だ。
読書メモは「AIに渡すコンテキスト」になる
今回作った読書メモは、Obsidianに保存した。
読書メモは本来、自分が後で読み返すためのものだ。だがAIを日常的に使うようになると、それだけにとどまらない。
自分がどんな本を読み、どこに線を引き、そこから何を考えたのか。それがMarkdownで蓄積されていれば、そのままAIに渡すコンテキストになる。
NotebookLMに入れれば、複数の読書メモを横断して比較できる。Obsidianに置いておけば、他のメモやプロジェクトノートとつながる。
読書がその場限りのインプットで終わらず、後から仕事・ブログ・提案資料・研究会のネタとして再利用しやすくなる。今回いちばん面白かったのは、まさにこの点だった。
権利面では、線引きが要る
当然ながら、Kindleの書籍は著作物だ。自分が買った本であっても、本文を自由に抜き出してよいわけではない。
ここは分けて考える必要がある。
「自分がどこに線を引いたか」は、自分の読書行為の記録だ。一方で「線の下にある本文」は、著者と出版社の著作物である。
だから今回の目的は、本文の収集ではなく、あくまで読書メモの作成に限定した。運用上は、次のような線引きが必要だと考えている。
- 自分が購入した本を対象にする
- 自分が付けたハイライトを起点にする
- 本文の引用は必要最小限にとどめる
- 主要部分は自分の言葉で要約する
- 出力は個人用のObsidianやNotebookLMに限定する
- 公開記事では本文ではなく、ワークフローを紹介する
技術的にできることと、やってよいことは別だ。ここは慎重に扱いたい。
まとめ
Computer Useは派手だが、APIやCLIで済む作業に使うと完全に遠回りになる。
一方で、Kindleのようにデスクトップアプリの画面上にしか出てこない情報を扱う場面では、はっきりと意味がある。
今回試した範囲では、Kindleのハイライトを読書メモに変換してObsidianに保存する流れは、十分に実用的だと感じた。
ただし、安定して動かすにはコツがいる。特に重要なのは次の5点だ。
- Computer Useプラグインを事前に入れておく
- GUI上のメニュー導線を具体的に指示する
- ローカルDBやSQLを使わせず、GUI操作に限定する
- 取得できない情報を推測させない
- 出力形式と保存先を明確にする
Computer Useに必要なのは、ふわっとしたお願いではなく、作業標準書に近いプロンプトだ。
そして、今回の本質はKindle操作そのものではない。
Kindleのハイライトは、読書中の自分の判断ログだ。それをAIで読書メモ化し、ObsidianやNotebookLMに蓄積すれば、読書そのものが「AIに渡せるコンテキスト」へと変わる。
Computer Useの価値は、マウスを動かすことにはない。画面の中に閉じ込められていた自分の知的活動を、AIが扱えるコンテキストへ変換すること——そこにある。
Kindle読書メモの自動化は、その分かりやすい実例だと思う。
コメント