Kindle本のOCRアプリをClaude Codeで一日かけて作って5人に配るまでやった全記録

公開: 2026年5月24日更新: 2026年9月3日約12分で読めます

一日で、社内向けの小さなアプリが一つできる。これが何を意味するか。「欲しい道具を外注せずに自分で作れる」状況が、中小企業の手元まで下りてきた、ということだ。

なぜ作ろうと思ったか

Kindleで買った本を全文検索したい、引用したい、Markdownで手元に残したい。これが意外と難しい。

スクリーンショットを撮りためた239ページ分のPDFをOCRしようとしたら、Adobeの月額代もばかにならないし、Tesseractは無料だけど精度が荒れる。「ええい、Claude Codeに作らせるか」と思って始めたら、半日で完成、夜にはMac/Windows両対応の配布版まで出来上がっていた。AI駆動開発のリアルな実例として残しておく。

最初の30分で動くプロトタイプ

最初に頼んだのは「PythonでKindleのページを連続スクショして1つのPDFにまとめて、OCRで検索可能にする」。Claude Codeはサクッと骨格を組んだ。

pyautoguiで右矢印キーを連打
mssで画面キャプチャ
img2pdfで結合
ocrmypdfでOCR

各ライブラリは枯れていて選定は迷いなし。GUIはPySide6で30分後にはダブルクリック起動できる .app になっていた。

ここまでは順調。問題はその先だった。

罠その一: macOSの権限

macOSの権限の壁。Pythonバイナリにアクセシビリティ権限が無いと、キー送信が無音で失敗する。

「ページが進まない」と最初に詰まった。アプリを起動して実行ボタンを押すと、画面のスクショは取れるのに、Kindleのページが一切めくられない。

原因はmacOSのアクセシビリティ権限。pyautoguiでキーを送るには、Pythonバイナリ自体がアクセシビリティの許可リストに入っている必要がある。さらにmacOS Sequoia以降は、未署名のアプリには「権限を許可しますか?」のポップアップすら出してくれなくなった。

Claude Codeと一緒に試行錯誤すること数時間。たどり着いた解決策はこうだ。

アプリを .app バンドル化して独自のBundle IDを持たせる
自己署名証明書を専用Keychainに作り、毎回同じ署名でビルド
ユーザーは設定アプリの「アクセシビリティ」一覧に Kindle OCR を1回ドラッグ&ドロップ
一度トグルをONにすれば永続化

「専用Keychainを作って既知パスワードで管理する」という発想は自分では絶対に出てこなかった。ad-hoc署名だと再ビルドのたびに署名が変わってTCCが「別アプリ」と判定するため。これを30分で実装してくれた時に、「ああ、これはもう一人で作る時代じゃないな」と思った。

罠その二: 旧版Kindleと新版Kindleが両方インストールされてた

自分のMacには、なぜかKindle.app(旧版、サポート終了)とAmazon Kindle.app(新版、Mac App Store版)の両方が入っていた。アプリは「Kindleを起動」を実行する時に、旧版を勝手に起動してしまっていた。

ややこしいのは両方ともプロセス名が「Kindle」なこと。プロセス名では区別がつかない。AppleScriptで file of process を取ってバンドルパスで判別するロジックに書き換えた。

「Kindle新版/旧版をバンドルパスで判別」みたいなニッチな修正、5年前ならStack Overflowを何時間も漁る案件だが、Claude Codeに状況を説明したら数分で書き直してくれた。

罠その三: OCR精度

Tesseract（80%）からApple Vision（97%）への切り替えで、誤認識が激減した。

ここが一番効いた。

最初はTesseract(無料・OSS)を使っていた。日本語精度は経験的に80〜90%。「機構」が「機茶」、「米国」が「米世」、「読みやすさ」が「読みやすかな」と。100ページ読むと10〜20箇所くらい違和感のある誤認識が出る。

途中で「Adobeで以前OCRした時はもっと精度よかった気がする」と気付いて、Claude Codeに「macOS標準でもっと精度高いOCRないの?」と聞いたら、「Apple Visionが使えますよ」と返してきた。

Apple Vision Framework。macOSに内蔵されている、Appleが訓練した日本語認識モデル。完全無料、ローカル動作、ネット不要。pyobjc-framework-Vision経由でPythonから呼べる。

切り替えた結果、精度は95〜98%。「機構」も「読みやすさ」もちゃんと出る。しかも速度が4〜5倍速い。340ページの本が25分→6分に短縮された。

TesseractからApple Visionに切り替えるのに費やしたコードは150行くらい。これも、自分で調べていたら一週間かかったと思う。

Windowsはどうするんだ問題

GitHub Actionsで Mac/Windows 両OSを並列クラウドビルド。git push するだけで両方の最新版が出来上がる。

Macで動くようになったら、欲が出る。「Windowsの友人にも使ってほしい」。

ここで現実が降りかかってきた。PyInstaller(Pythonアプリをexe/appにバンドルするツール)はクロスコンパイルできない。Mac上でWindowsのexeは作れない。逆もしかり。

選択肢を整理した。

Parallels Desktopで14日無料体験 + Windows 11評価版で実機ビルド
GitHub Actionsのクラウドビルドで自動化
諦める

「諦める」以外で迷ったが、GitHub Actionsを選んだ。理由は「一度設定すれば、コード更新するたびに両OS版が自動で出来上がる」から。

.github/workflows/build.yml を書いて、git push したら数分後にはMac版とWindows版が両方ビルドされた。タグを切ると自動でGitHub Releasesにも公開される。

ただし、GitHub Actionsで作っただけでは「実際に動くか」は分からない。結局Parallelsの無料体験版でWindows 11 ARM版をインストールして、Mac→WindowsへZIPをドラッグ&ドロップ、動作確認した。

最初は「Python DLLが見つかりません」エラー。ZIPを「開く」ではなく「すべて展開」しないとPyInstallerバンドルは動かない、というWindowsの初心者あるある。これも修正してUSER_GUIDE.mdに追記。

配布の現実

これで完成、5人に配るぞとなって、また現実。

GitHub Releasesは自分のリポジトリがPrivateだとログイン必要。受け取り手にGitHubアカウントを要求するのはハードル高い。結局Google Driveの共有フォルダにZIPを置く方式に落ち着いた。

メールで送るメッセージも考えた。最初は「動作確認のため返信お願いします」と書きそうになって、これだと相手にプレッシャーをかける。「お忙しいと思いますので、ご返信は不要です。お時間のあるときに試してみてください」に書き直した。ここはAIには判断できない、人間味のところ。

Apple Vision以外で発見した小ネタ

副産物として面白かったのを並べる。

macOSのスクリーンショット系コマンドにはTCC権限が必要だが、ctypesで直接 AXIsProcessTrusted() を呼ぶと、PyObjCに頼らずに権限状態を取れる
PyMuPDFの組み込みCJKフォント japan-s を使えば、検索可能PDFのテキストレイヤーを日本語で埋め込める
pygetwindowはWindowsで w.activate() が「フォーカス窃取防止」で失敗するケースがあり、minimize→restoreで代替できる
mss(画面キャプチャ)は時計の秒が動くだけでハッシュが変わるので、重複検出は画面中央領域だけで計算する

どれも単発の知識だが、6時間の開発でこれくらいの「Tipsの引き出し」が増える。

外注したらいくらかかったか問題

ここまで読んで「結局、自分でやらずに誰かに頼んだらいくらなんだ?」と気になる人もいると思う。せっかくなので相場を調べてみた。

まずフリーランスに頼む場合。エンジニアの月額単価は、2025年12月時点で平均78.3万円あたりが中心だ。今回のアプリは、画面の自動操作とOCR、それにmacOSの署名まわりとクロスプラットフォーム対応という、地味なわりに手間のかかる要素が詰まっている。腕のいい人でも、要件のすり合わせから動作確認、簡単なマニュアル作成まで含めれば1〜2週間、署名やCIに不慣れならもっとかかる。一括の個人案件として見積もるなら、ざっと30〜80万円あたりが現実的なラインだろう。 En-japan

次に開発会社に頼む場合。小規模アプリ開発の相場は100〜300万円程度とされる。ここに要件定義やテスト、ドキュメント、プロジェクト管理の工数が積み上がる。今回のように「Mac/Windows両対応」「コード署名」「自動ビルドのCI」まで盛り込めば、150〜400万円くらいに膨らんでもおかしくない。しかも受託開発では、保守費が新規開発費の15〜25%／年が相場だ。作って終わりではなく、毎年の維持費もぶら下がってくる。 Ysinc Siainc

で、自分が実際に払ったのは。Claude Codeの月額サブスク代と、半日ぶんの自分の時間。それだけだった。

念のため書いておくと、フリーランスや開発会社が高すぎる、という話ではない。要件のかっちり固まった中規模以上のシステムや、止まると業務が止まる基幹系は、今でもプロに任せたほうがいい。そこは変わっていない。

動いたのは「小さな道具」のところだ。自分や社内の数人だけが使う、ニッチな業務ツール。これまでは「わざわざ外注するほどではないけど、自分では作れない」という理由で、ほしいと思いつつ放置されてきた領域でもある。その採算ラインが、ごっそり下にずれた。「外注なら数十万〜数百万、でも求めている完成度はそこまでじゃない」というツールが、半日の自分の時間で形になる。作るコストより、何を作るか決めるコストのほうが重くなった、と言い換えてもいい。

ちなみに、アプリ開発に限らず「AI導入そのものにいくらかかるのか」の相場観は別記事にまとめてある。中小企業のAI導入費用の実額と、外注するか自社でやるかの判断軸は、ここで書いた「自分でやるか誰かに頼むか」問題とそのまま地続きの話だ。

結論

AIに任せる範囲と人間が決める範囲。開発しながら自然に住み分けが決まっていく。

半日で5人に配布できるレベルのアプリが、しかもクロスプラットフォームで、自動ビルドCI付きで完成した。

Claude Codeが特に効いたのは、

「macOSのTCC回避」のような自分の知識の外側の話
「Mac/Windows両対応」のようなOS差分の処理
「GitHub Actionsで自動ビルド」のような周辺ツールチェーン

一方で自分の判断が必要だったのは、

どのOCRエンジンを選ぶか(Apple Vision採用は自分の決断)
どこまで配布の手間を引き受けるか(Google Drive方式に決めた)
受け取り手への文面(プレッシャーかけない言い回し)

技術と判断のバランスというか、AIに任せる範囲と自分が決める範囲の住み分けが、開発しながら自然に決まっていく感じがあった。

完成したアプリは https://github.com/f2t-code/kindle-ocr-app に置いてある。Mac/Windows両対応、Apple VisionでOCR、ワンクリックで本がMarkdownになる。Kindle本の知識を自分のNotionや検索可能なPDFに変換したい人はどうぞ。

個人で読むための私的複製の範囲でお使いください。

f2tでは、Claude Codeを使ったAI駆動開発の支援・教育を行っています。「自社の業務ツールをサクッと作りたい」「社内向けアプリをエンジニア不在で作りたい」といった相談はこちらまで。

趣味の工作に見えるかもしれないけど、経営目線だと話が変わる。今まで「専用ツールを買うほどじゃないけど、手作業は面倒」で放置していた業務が、社内でサッと作れる対象になった。市販ソフトに月額を払い続けるより、自分たちの仕事にぴったり合う小さな道具を持つ方が安く済むことも多い。何が作れて何が作れないか、その線引きは触ってみないと見えにくい。「こんなの作れます?」の相談から始めてもらって構わない。まずは現在地を知るだけで十分。無料の診断（6問・約1分）で、どの業務からAIに任せられるかの目安がその場で出る。

自動化の現在地を診断する（無料・6問・約1分）