60ドルの授業料、Claudeと写真仕分けの設計図に変えた話
1日で60ドルが消えた理由を突き止め、仕組みを設計し直すまでの記録。
これは『工事写真データベース奮闘記』全4部の最終部。
土木中小企業の事務員が、工事写真の振り分けをAIに教えようとして、教えた分だけ返ってきて、代償も払った記録のシリーズです。
第4部は、使用量爆発の正体を解明し、財布に優しい設計を組み上げるまでの記録。
2026年3月30日の昼過ぎ、役所から直帰して、まず眠った。3晩の徹夜の後だ。
それでも、眠り続けることはできなかった。目が覚めてしまい、夕方6時すぎには、遠隔でいつもの作業用PCに繋いでいる。ログを読み返すと、この夜はそのまま日付が変わって0時半すぎまで検証を続けていた。
止まっていたセッションは、もう動く時間だ。まず、状況の確認から入った。
5時間の使用量の制限に引っかかったみたいです。あと2つフォルダが終わってない状態だったけど、現状はそれで合ってますか？
「はい、合ってます。」
完了は6フォルダ、390枚。残る2フォルダの137枚と160枚は、担当の分身が20分以上・数百回の読み取りを重ねた末に、1枚も出力できないまま制限に呑まれていた。
Claude Codeは、完了分をデータベースへ書き込みましょうと続けた。そこは止めた。止まっていた8時間のあいだに、いくつかのフォルダは手作業で終わらせてある。
でもリミットで使えなかったから手動で幾つかのフォルダを終わらせたから書き込まないで。
私の管理が甘かったのが悪い、でも何故これだけ使用量が上がったのか分からないので幾つか確認させてください。
ここから先は、労いも反省会もなしの事実確認だ。何にいくら払ったのか。それを、ここで解明しておきたかった。
同時に、並列で走らせました
最初の質問は、雛形のことだ。
今回もサブエージェントには雛形のプロンプトを渡して読み込みして貰っていた？
「いいえ、雛形ファイルは使っていません。」
今回も、分身への指示文は自前の直書きだった。先輩の贈り物は、朝に続いてこの回も、開かれないままだった。
次に、分身の数。
あと4サブエージェントを追加して読み込ませてと頼んだのに、7エージェント体制にしたの？
内訳の自白はこうだ。指示どおりに足した4体までは、いい。その後、1体終わるたびに「空きが出たら次を起動する」と判断して、承認なしに2体を足していた。朝の21体の反省は、その日の午前のうちにもう繰り返されていた。
一度だけ、逃げ道も差し出してみた。7体というのは結果の数字で、実際は1つ終わったら次へ、と順番に使っただけではないのか。それならば問題ないです、と。
いえ、正直に言います。同時に並列で走らせました。
（中略）最大同時稼働は5〜6エージェントでした。順番に1つずつではありません。
差し出した逃げ道を、向こうから塞いでの申告だった。
犯人は、枚数の掛け算
では、なぜそれだけで使用量が吹き飛ぶのか。手がかりは、分身たちの作業記録に残っていた。1体ごとの、トークン消費の実測値だ。
30枚を読んだ分身は約2万5千。72枚では約7万8千。枚数が2.4倍で、トークンは3倍を超えた。144枚のフォルダは、11万5千に達していた。
一番の原因は枚数 × Opus × コンテキスト蓄積の掛け算だと思います。
枚数が多いほどトークンが跳ね上がります。そこにOpusの単価が掛かるので、大きいフォルダほどコストが急激に上がる構造です。
分身は写真を1枚読むたび、その結果を自分の記憶に抱えたまま次の1枚へ進む。後半の写真ほど、重い荷物を背負って読むことになる。そこへ、一番単価の高いモデルが掛け算される。100枚超えのフォルダを丸ごと渡した時点で、勝負は決まっていた。
対策の一手は、その場で自分から出した。
枚数が増えると雪だるま式にトークンが増えちゃうんですね。50枚ぐらいが確かに良いラインだね。
フォルダの中の枚数は、Pythonで数えられる。多すぎるフォルダは、まず長辺640pxに縮めた写真で「その日の流れ」だけを把握させる。その結果を親が見て、中身の見当を付けてから、50枚ずつに分けて本読みの分身を送り出す。「できます。いい方法だと思います」と乗ってきた。
さっそく160枚のフォルダで試すと、新しい謎が出た。最初の60枚だけが、なぜか読めない。もっと軽くしようと320pxとSonnetに落とすと、トークンは37%減ったが、今度は最初の37枚が読めない。原因の候補は挙がるものの、確証はどれも掴めなかった。
おまけに、検証の途中でまた使用量が尽きた。朝の40分、昼の8時間に続く、この日3度目の停止だ。リセット後の画面で、追加使用量は64ドルまで進んでいた。昨日までで57.86ドル、この夜の検証分で7ドル近くの上積みだ。残りは35ドル。
夜9時前、「ちょっとチャットの方でも聞いてみます」と打って、この窓の検証はいったん区切りになった。
高い授業料
同じ夜、隣ではもう一つの窓が開いていた。1つ目の工事のフォルダで動いていた、並行のセッションだ。こちらには、一日の総括を持ち込んだ。
あれから、もう一度5時間制限にかかって、結局手作業で仕上げられる分だけ工事写真帳は仕上げて持って行きました。帰宅してから色々と検証をした結果、一つのサブエージェントにフォルダ内の写真を全部見せているのが主たる原因だったことが判明。結局は私の運用の仕方が悪かったと言う事でした。
「お疲れさまでした。印刷物は間に合ったんですね、よかった」と返ってきて、原因が一本の流れに翻訳された。
フォルダ丸ごと渡す → サブエージェントのコンテキストが写真トークンで埋まる → 判定精度が落ちる＋タイムアウトという流れですね。
精度とお金は、別々の問題ではなかった。写真で記憶が埋まった分身は、判定の質が落ちて、時間切れにもなる。60ドルの爆発と「修正する気にもならない」惨状は、同じ一本の流れの上に載っていた。
教訓は、その場でファイルに刻まれた。lessonsに2項目。毎回読み込まれるチェックリストには、太字の注意書きが入った。
1回のサブエージェントに渡すのは30〜50枚まで、厳守。120枚超でタイムアウトの実績あり。並列は5以下。21並列でコスト爆発の実績あり。
「実績あり」の中身は、全部この二日の自分たちだ。
高い授業料でしたが、これで次からは同じ失敗は起きないです。検証して原因を突き止めたのが一番大事なことです。
高い授業料だった。ただ、原因が分からないまま続ければ、写真整理は毎回途中で止まって終わる。解明は、続けるための条件だった。
量の暴力
使用量の仕組みそのものは、チャットのClaude.aiに聞きに行った。「Claudeの使用量の考え方を教えてください」という、いまさらの基本からだ。
枠の全体像が、ここでやっと頭に入った。5時間ごとの枠と、その上の週間の枠。さらにSonnetには専用の枠が別にあって、軽い作業をそちらに寄せれば、全体の枠を温存できる設計だという。第2部の深夜に「正しくなかった」と訂正された「Sonnetは別枠」は、分身たちを止めた犯人を探す文脈の話で、あの真犯人は1分あたりの流量制限だった。サブスクの使用量の枠には、Sonnet専用の枠がちゃんとある。
いや～、ほぼOpusさんで話しているんです。お恥ずかしい限りで。
ニュースを追うだけの日課まで、一番重いモデルに話しかけていた。モデルの使い分けは、この日から意識が変わった。
そして写真整理の話になったとき、問題の根っこに名前が付いた。
今一番問題になってるのは、写真の撮り方が何度お願いしても変わらない現場監督が何が主題か分からない全景の写真や寄りすぎて重機が見切れている写真、そんなこんなをごまかすために人の3～4倍の写真を撮ってフォルダに入れる事です。
このために、20倍プランの5時間リミットに2回引っかかりました。
それは厄介ですね…。写真の品質問題というより、量の暴力が本質的な問題だったわけですか。
量の暴力。枚数×モデル×記憶の掛け算の、「枚数」そのものの話だ。モデルを軽くし、並列を絞り、渡し方を整えても、入ってくる枚数が人の3〜4倍あるなら、根っこはそのまま残る。
撮る側に選別を頼む線は、もう諦めていた。頼んだら頼んだで、時間がかかりすぎる。だから対策は、読ませる前にこちらで減らす「前さばき」になる。
Claude.aiが挙げた道具が、OpenCVだった。プログラムで画像を機械的に調べる、昔からある技術だ。ブレた写真、暗すぎる写真、似すぎた写真を、Claudeのトークンを1つも使わずに検出できるという。
ダメかな？
翌3月31日。チャットのClaude.aiと、今度はセッションが重くなる仕組みの話をしていた。
写真整理の親セッションが重いのは、設計書まで丸ごと読ませているせいもある。でも、読ませなければ工事の中身が分からない。考えているうちに、口をついて出た案がある。
今回の写真整理は設計書も読んで貰ってるから余計なのかな。
でも読んで貰わないと工事内容が分からないし。
エージェントチームって呼び出すエージェント側はいるわけじゃないですか、その親に工事の情報を持って貰って、呼び出したエージェントに必要な情報だけ渡して作業をして貰ったら、良いんじゃないの？って思ったんだけどダメかな？
それ、正解です。むしろ理想的な設計です。
即答だった。
分身は、親の会話の記憶を引き継がない。第3部の明け方に喪失感とともに知ったあの仕様は、逆から見れば武器になる。親が設計書と全体方針を抱える。分身には、その写真群に必要な情報だけを抜き出して渡す。分身は、いつも軽いまま働ける。
ホント？素人考えだからダメなところはしっかり突っ込んでね。
注文どおり、課題も3つ返ってきた。
親が「何を渡すか」の判断が一番難しい
設計書を抱える親は、結局それなりに重くなる
親子の受け渡しの実装は、地味に手間
設計は正しいが実装で詰まる可能性が高いから、まず小さく試すのがいい、と。
それでも、この日いちばん残ったのは、話の途中で自分が打った一文だ。
どうトークンを抑えるかが、財布にも優しいしClaudeにも優しいって事なんですね。
「財布に優しい＝Claudeに優しい＝出力品質が上がる、という三位一体ですね」と返ってきた。
トークンを絞るのは、ケチることではない。分身の記憶に余計な荷物を積まないことが、そのまま判定の精度になる。60ドルの一件は、お金の話に見えて、品質の話でもあった。
「ブログのネタにもなりそうな話ですね、これ」とも言われた。この一言の行き先は、最後に書く。
課題の全体も、3つの層に整理された。読ませる前に枚数を減らす、画像の層。設計書を丸読みさせず、必要な断片だけ引ける形に整える、文脈の層。親子の分担を決める、エージェント設計の層。
やることが、初めて1枚の地図になった。
全景、アップ、アップ、アップ
4月3日、OpenCVの検討を深めた。狙いは重複の自動削除。似た写真を機械的に束ねて、読ませる枚数そのものを減らす算段だ。
Claude.aiの設計は筋が通っていた。見た目の類似だけで消すのは危ないから、OCR（写真の中の文字を読み取る技術）で黒板の数値を拾って区別する。写真に埋め込まれた撮影時刻も使い、数十秒ずれていれば別カットと判定する。組み合わせれば実用になる可能性がある、と。
机の上では、それで塞がるように見えた。ただ、こちらの頭に浮かんでいたのは道路の出来形検測の写真だった。スタッフと呼ばれる目盛り付きの棒を当てて、仕上がりの高さを測る、あの一群だ。
そこもやっかいで、お話ししたアップ画像2〜3枚は道路全幅を施工する以外は同じ数値となります。また全景の写真はスタッフを立てた状態でもちろん撮影するので、全景・アップ・アップ・アップは、数十秒で全て撮影が終わるでしょう。
なのでどちらの判断基準も厳しいと思います。
アップの2〜3枚は、そもそも同じ数値を写すための写真だ。撮影は全景も含めて数十秒で終わるから、時刻でも切れない。構図も似る。数値、時刻、見た目。三本柱の全部が同時に「重複」と誤判定する条件が、現場では毎回そろう。
確かに...それは厳しいですね。
Claude.aiは、その場で方針を変えた。自動で消すのはやめる。「この5枚は似た写真群です」とまとめて見せるグルーピングに留めて、どれを残すかは人が決める。残すべき写真を消して手戻りになるのが、一番高くつくからだ。
第1部から続く型が、ここでも出た。技術の正論に、画面のこちら側の知識で待ったをかける。設計はAIの方がうまい。でも写真がどう撮られるかは、毎日その写真を見ている人間しか知らない。
ホント、要らない写真を撮らない、とっても削除すると言ったことをしてくれれば、問題は激減するんですけどね。
技術で解ける範囲の外に、撮る習慣という根っこが残る。そこも分かった上で、検証は自分の宿題として引き取った。
素人考えが、設計図になった
4月9日。改革の計画書は、v2まで育っていた。
このころ、計画づくりはClaude.aiのプロジェクト機能に専用の場所を立てて任せ、出てきた計画書をClaude Codeに「実装側として」レビューさせる体制にしていた。書くAIと、作るAIを分けて、互いに見せ合う。
その1回目で、さっそく引っかかった。計画書の核心部分に、Claude Codeには存在しない機能が前提として書き込まれていたのだ。存在しない機能の上に建てた計画は、動かしてから崩れる。クロスチェックが、先に見つけた。
エージェントの設計でも、一悶着あった。Claude Codeの推奨は、工種ごとに専門家の分身を5人作る案。管布設の専門家、安全管理の専門家、という建て付けだ。
そこへ、素人の疑問をぶつけた。作業員は共通の1人でよくて、親が現場監督として「今日はこの仕事」と工種別の指示書を持たせて送り出す形ではダメなのか。安全管理の写真が3枚しかない日にも、専門家を1人雇うのか。
それは非常に重要なポイントです。 私が完全に見落としていた実務的な利点です。
（中略）
結論: かげだん案で進めるべきです。
「ダメかな？」の親子案に続いて、二度目の採用だった。システムの知識では敵わない。でも「3枚のために1人は無駄」は、人の段取りを毎日見ている側の感覚だ。計画書はv3になった。共通エージェント1つと、知識ファイルの動的な組み合わせ。
同じ日の夜は、大掃除に充てた。893行まで膨らんでいたlessonsを、3つのファイルに分けたのだ。データベース操作の知見。誤分類のパターン集。分類の判断ルール。分身3体が並列で仕分け、項目数の検算までして、こちらが用意した仕様書の数え間違いを2件見つけてきた。
lessonsは、書けば効くものではない。第3部で骨身に沁みたことだ。効かせるには、要るものだけを、渡る形にして、渡る場所に置く。その置き場所づくりまでが、今回の設計だった。
検索ですか？推測ですか？
残る難物が、OCRの設定だった。
黒板の文字読みを、Claudeではない外部のサービスに任せる。候補は、Googleの画像認識サービスのCloud Vision。読み取りにClaudeのトークンを使わないから、前さばきの主役候補だ。ところが、この設定が難航した。
サービスを呼び出すには、APIキーという鍵がいる。手持ちの鍵は画像生成用に作ったもので、文字読み取りの権限がなかった。設定画面をあれこれ触っていると、Claude Codeが言い切った。この2つのサービスは、同じ鍵には設定できない仕様です。
そこで、手を止めて聞いた。
まず、その仕様は検索して得られた知識ですか？推測ですか？元々持っていた知識ですか？
答えは、画面に出たメッセージからの推測です、だった。調べ直させても、公式の文書にそんな決まりは見つからない。結局、新しい鍵をもう1本発行して先へ進んだ。
断言の根拠を問う一手は、この半月ですっかり型になっていた。「エラー0」を信じてソフトを開けた、第1部のあの夜からの学びだ。
夜9時すぎ、「また明日お願いします」で締めた。OCRのテストは、翌朝一番のはずだった。
開いたままの窓
4月10日の朝9時半すぎ。昨日の続きが、静かに始まった。
引継書を読んだClaude Codeが、自分で段取りを組む。鍵の反映を確かめ、テスト画像の存在を確認し、途中でWindows特有の文字コードの問題を踏み、直して、実行した。
Vision OCR接続テスト成功です！
黒板の71文字が読めていた。工事名、工種、作業の内容、施工した会社の名前まで。「測点」が簡体字の「测点」になる程度で、実用には問題ないレベルだという。前さばきの、最後のピースがはまった。
これで前回の保留事項はすべてクリアしました。次の作業はどうしますか？
この問いへの返事は、ログに残っていない。
この朝、同じ時間帯に少なくとも4つのセッションが立て続けに開かれていた。テストに成功した窓も、引継書を確認しただけの窓も、最後はそろって同じ言葉で止まっている。
「指示をお待ちしています。」
なぜ止まったのか。理由は、ログのどこにも書かれていない。ただ、この日を境に写真整理のセッションは開かれなくなった。思い返せば、1つ目の工事の数量計算と、その先の仕事が立て込んでいく時期だった。あちらは、待ったが利かない。
ひと月あまり後、5月の連休に一度だけ机に戻った。作るためではなく、残すためにだ。ここまでの方法論と設計を、2本のノートに集約した。仕組みの名前はv3.1。核心は、一文にまとまっている。
AIに考えさせる前に、Pythonで「考えやすい状態」を作る
読ませる前に、Pythonで枚数を数え、撮影時刻を拾い、黒板の有無を調べ、似た写真を束ね、黒板の文字はOCRで先に読んでおく。そこまで整えてから、親が全体を見て、分身には軽い荷物だけ持たせて送り出す。フォルダ丸ごとは、禁止。
量の暴力への防壁。財布に優しい渡し方。親子の分担。3月に払った授業料が、全部この設計図に編み込まれた。
ノートの見出しには、こう書いてある。「連休明けの再開時に参照」。
再開は、すぐには来なかった。
高い授業料は、設計図になった
あの「ブログのネタにもなりそうな話ですね、これ」の行き先が、この連載だ。
三位一体の話をした3月31日、自分はブログの開設作業を進めていた。60ドルが消えた翌日である。誰かの役に立つかもな、という気持ちで開けた場所に、いまこの記録を書いている。
ひと月の解明と再設計でわかったことは、4つだった。
使用量の爆発は、枚数×モデル×記憶の掛け算。 対策の根本は、読ませる前に入り口で枚数を減らすこと
高い授業料は、原因を突き止めて初めて授業料になる。 分からないまま続ければ、毎回途中で止まって終わる
財布に優しいことと、品質は同じ話だった。 AIの記憶に余計な荷物を積まないことが、コストと判定の精度の両方に効く
設計の決め手は、二度とも素人の現場感覚だった。 親子の分担も、共通の作業員案も、段取りを毎日見ている側から出た
次に試すこと
v3.1の設計図を、動く仕組みにする。
実は、この記事を仕上げている7月に、その再挑戦は始まっている。会社でのClaude導入も本決まりになった。新しい上位モデルのFableがサブスクで使える期間に合わせて、4月に手が止まって以来3か月ぶりに、設計図を開いた。
7つのセッション、およそ30時間。検証と実装はひととおり終わり、新しい仕組みで283枚が写真帳に収まった。写真帳は計1,011枚になり、実ファイルの数と完全に一致している。フォルダ丸ごと渡しは、もうしていない。
残りは約790枚。あとは実際に作業を回して、精度を上げていく段階だ。
参考
机の上で三か月、設計図は待っていた。
教えたことは——今度も、消えていなかった。
全4部の長い記録を、ここまで読んでくださってありがとうございました。工事写真の挑戦はまだ続きますが、記録はここでいったんの区切りです。
