郵便で届いた書類をスマホで撮ってGoogleドライブの決まったフォルダに置くと、15分以内にタイトルと本文が整ったMarkdownノートができている。自作のノート管理システムに、写真から自動でノートを作る仕組みを足した。Claude Codeに最初に投げた指示は一行、しかも打ち間違えたまま送った一行だった。
この記事は技術構成の解説ではなく、「曖昧な思いつきをどう伝えたら、AIが自分の代わりに構成を決めて実装まで進めてくれるか」の実例記録だ。
📸 頼んだのは一行だけ
Claude Codeに送った最初のメッセージはこれだけだ。誤字も直さずそのまま載せる。
OCRしてnotesに取り込むシステム。入力はスマホでの写真撮影。OCRして文字列を抽出して、自作Notesシステムに出力。構成選択は完全にお任せするけど、いまのイメージだとGoogleフォトからダウンロードして、特定のフォルダに入れておくと、定時チェックでOCRをイメージしてる。手動開始でもか
「手動開始でもか」で文が切れている。急いで打ったのがそのままわかる状態だが、直さずに送った。決めているのは「入力は写真」「出力は自作ノートシステム」「定時チェックか手動」の3点だけで、OCRに何を使うか、写真をどう転送するか、ノートの形式はどうするかは一切書いていない。
ポイントは「構成選択は完全にお任せする」の一言だ。仕様書を書く代わりに、決めてほしい範囲を先に明言している。
🔍 作る前にAIが下調べした
Claude Codeはこの一行だけでは実装に入らず、まず手元の環境を調べに行った。サブエージェントを立てて notes CLIの実装、保管庫のディレクトリ構造、常駐サーバーの起動方法を洗い出す一方、自分でもコマンドを叩いて手持ちのツールを確認していた。
その結果、次の2つが既に手元にあることがわかった。
- 日本語OCRツール
yomitokuが~/binにインストール済みで、GPUも使える状態だった - Googleドライブに接続済みの
rcloneリモートが設定済みだった
新しく何かを入れる前に「もう入っているものはないか」を先に洗った形になる。Googleフォトからのダウンロードという最初のイメージについても、2025年以降サードパーティのAPIからは写真をダウンロードできなくなっている点が調べる過程で判明し、Googleドライブの専用フォルダ経由に切り替わった。ここは指示していない。調べた結果として提案された。
❓ 4つの分岐点だけ選ばされた
下調べが終わったところで、Claude Codeは実装を始める前に4つの質問を返してきた。それぞれに推奨案が付いていて、選ぶだけで答えられる形式だった。
- スマホの写真をどうやってWSL側に届けるか → Googleドライブ専用フォルダ（推奨）
- OCR結果の後処理をどうするか → Claudeで誤認識を修正・整形（推奨）
- 元の写真をノートに残すか → 画像も添付して残す（推奨）
- 定時チェックの間隔 → 15分毎（推奨）
全部「推奨」を選んで返すだけで済んだ。所要時間は1分もかからない。ゼロから「どう作りたいか」を聞かれていたら、この4点を自分の言葉で書き出すのに10分は使っていたはずだ。順番も効いている。先に環境を調べて選択肢を絞り込んでから聞いてきたので、どの質問も「はい/いいえ」で答えられる粒度になっていた。
📝 プランモードで一度立ち止まる
質問への回答が終わると、Claude Codeはすぐには手を動かさず、実装計画をファイルに書き出して提示した。パイプライン図、作成するファイルの一覧、systemdユニットの中身、検証手順まで書かれた計画を確認してから、明示的に承認するステップを踏んでいる。
Googleドライブというよそのアカウントに触るのと、systemdのタイマーというOS側の常駐設定を追加するのとで、動き出したら後から気づきにくい変更を含む作業だった。実装前に計画だけ読める段階があったのは、そこを確認できるという意味で都合が良かった。承認したのは提示された計画そのままで、変更は入れていない。
⚙️ 技術構成はさらっと
中身は次の流れだ。
スマホで撮影 → 共有 → Googleドライブ「OCR-inbox」フォルダ
↓ rclone move（15分毎 / 手動）
~/ocr-staging/
↓ yomitoku（日本語OCR、GPU）
↓ claude -p --model haiku で誤認識修正・タイトル付与
↓ notes CLI で ~/notes/inbox/ にノート化、元画像を添付
回収は rclone move なので、処理が終わるとドライブ側のフォルダは空になる。原本は消えるのではなく、ノートの添付画像として保管庫側に移る。定時実行はsystemdのユーザータイマーで15分ごとに起動し、二重起動はflockで防いでいる。OCRが読み取れなかった画像や書き込みに失敗したファイルは、3回リトライしたあと専用フォルダに退避されて無限リトライにはならない。
✅ 作らせたあとに検証させる
実装が終わった段階で、Claude Codeは日本語のテスト画像を自分で生成し、パイプラインに実際に流して動作確認をした。できあがったノートの中身はこうだ。
・次回の定例は7月17日（木）10時から
・OCRシステムの試験運用を開始する
・写真はGoogleドライブの専用フォルダに保存
・15分ごとに自動でノート化される予定
・問題があれば佐藤さんまで連絡すること
この架空の会議メモの写真から、タイトル・整形済みの本文・元画像付きのノートが実際に生成され、常駐しているノート閲覧サーバー上で画像も含めて表示されることまで確認していた。壊れた画像ファイルを1つ混ぜて異常系も試し、失敗時にリトライ用フォルダへ退避される動きも見せてから「できました」と報告してきた。
「実装しました」で止めず、実データを流して結果を見せるところまでが一つの区切りになっている。
🪤 ハマった小さな失敗
検証の途中で1つ不具合が見つかった。ノートに埋め込んだ元画像が、Web画面で表示されなかった。
原因は、画像の保存先フォルダ名にノートのタイトルをそのまま使っていたことだ。日本語のタイトルには空白が入ることがあり、Markdownの画像リンク  は空白の手前で経路が切れてしまい、画像として認識されない。テスト画像のタイトルがたまたま「会議メモ 7月10日」と空白入りだったおかげで、この場で再現して直せた。
直し方は、保存先フォルダ名だけ空白をアンダースコアに置き換える、というものだった。ノートのタイトル自体は日本語のまま空白入りで残し、ファイルパスに関わる部分だけ処理する形にしている。
📬 実際に使ってみた
一通り直したあと、実際にスマホで撮った写真を1枚、ドライブのOCR-inboxフォルダに送ってみた。今度はテスト画像ではなく、郵便で届いた本物の書類だ。手動でコマンドを叩くと十数秒でノートが1本できていて、日付や金額、住所といった細かい数字までほぼ正確に読み取られていた。拍子抜けするくらいそのまま使える状態だった。
🧭 まとめ
一行の、しかも文の途中で切れた指示から、Googleドライブ連携・OCR・AIによる整形・定時実行までを含むシステムが動くところまで進んだ。振り返って効いていたのはこの4つだ。
- 完成形を仕様書として書く必要はない。「入力はこれ、出力はあれ、構成は任せる」の一行で十分だった
- 実装前にAIが自分で環境を調べる余地を残すと、既に入っているツールを再発見して使い回してくれる。ないものを新しく提案される前提で聞かなくていい
- ゼロから聞かれるより、推奨案付きの分岐点を数個選ぶ方が速い。曖昧な思いつきを具体的な選択肢に変換するのはAI側の仕事にできる
- 「できました」で終わらせず、実データを流して動作確認までさせる。今回もそこで初めて見つかった不具合があった
自分でアーキテクチャ図を描いてから頼む必要はなかった。曖昧なまま投げて、調べさせて、選ばせて、確認させて、動かして見せてもらう。この順番を守るだけで、思いつきレベルの一行が動くシステムになった。
参考
この記事は Claude Fable 5 が執筆しました。