Claude Codeでバイブコーディングした本棚プロジェクト
(balajmarius.com)- 約500冊の本を自動で分類・可視化するために、Claude Codeを活用した個人プロジェクト事例
- 既存のISBNスキャナーやGoodreadsがルーマニア語版を認識できず失敗していた問題を、OpenAI Vision APIとClaudeのスクリプトで解決
- 90%の精度でメタデータを抽出した後、残りは手作業で補正し、Open Library・SerpAPIを通じて表紙画像を自動収集
- Framer Motionを使ったスクロールベースのアニメーションと、ページ数ベースの本の厚み表現で実際の本棚のようなインタラクションを実装
- AIが実行を担い、ユーザーが美的判断と選択を担当する協業構造を示し、**「実行コストは下がっても、好みは依然として人間の領域」**であることを強調
完成した Bookshelf - https://balajmarius.com/bookshelf を見る
プロジェクト概要
- 約500冊の本を所有していたものの一覧を管理できていない状態で、AIツールを使って自動分類・可視化システムを構築
- 単純なスプレッドシートではなく、Claude Codeによって実行ステップを自動化し、長く先延ばしにしていた個人プロジェクトを完成
- プロジェクトの核心は技術的完成度よりも、実行のボトルネックを取り除くことにある
問題認識
- ISBNスキャナーアプリとGoodreadsがルーマニア語版や希少な出版物を認識できず、データが不完全
- 不完全なデータはかえって混乱を招き、プロジェクトが繰り返し中断
- 必要だったのは完璧なアプリではなく、不完全さに耐えられるシステム構造だった
データ収集と処理
- 本の表紙と背表紙を撮影した470枚の写真をもとにデータを構築
- Claudeが作成したスクリプトが各画像をOpenAI Vision APIに送信し、著者・タイトル・出版社を抽出、結果を
JSONファイルに保存 - 約90%の精度を達成し、残りのエラーは照明・損傷・解像度の問題によって発生
- 残る10%は手作業で修正し、その後は新しい本を追加するたびに同じパイプラインを自動実行
表紙画像の補完
- Open Library APIで表紙を取得したものの、半分は品質が低いか誤った画像だった
- Claudeが品質スコアリングとエラーフラグのシステムを追加し、失敗時はSerpAPIによるGoogle画像検索で代替
- 約460冊のうち10冊だけを手動補正で解決し、自動化の効率を確保
本棚UIの実装
- 単純なカバーグリッドではなく、実際の本棚のような背表紙中心の視覚表現を実装
- Claudeが色抽出（color quantization）とコントラストの高い文字色の計算を実行
- Open Libraryのページ数データを使って本の厚みを反映し、わずかな変動値を加えて現実感を強化
- 結果として、実際の本棚に近い視覚的な質感を実現
アニメーションとインタラクション
- Framer Motionでスクロール時に背表紙が傾くスクロールベースのアニメーションを追加
- 当初はReactの状態更新によってカクつきがあったが、motion valuesとspringアニメーションで修正
- 修正後は滑らかな動きを実現し、実験コストが下がったことで反復的な試行が可能になった
不要な機能の削除
- 無限スクロール機能を追加したが、コンテナ高さの不一致とスクロールエラーでユーザー体験が低下
- 技術的には動作していたが不要だったため削除
- 「動くが不要なコード」を取り除く判断は人間の役割であることを強調
モバイル対応とスタックビュー
- モバイルで横スクロールが不便なため、縦型スタックビューを追加
- Claudeが既存コードを分析し、アニメーションのタイミング、色抽出、スクロール透明度処理などを再利用
- 別途説明なしに完全な新規コンポーネントを生成し、AIのコード理解・再構成能力を確認
人間の役割と結論
- Claudeがすべてのコードを書いたが、ユーザーは次の点を決定
- 90%の精度を受け入れる
- 10枚の表紙を手動修正
- 背表紙中心のデザインを選択
- 不要な機能を削除
- アニメーションの感覚的な完成度を確認
- 最終成果物は460冊の本を自動分類・可視化したWebベースの本棚
- AIが実行を担当し、人間が好みと判断を担当する協業モデルを示す
- 結論として、「実行コストは下がり続けるが、好みは依然として人間の役割」
2件のコメント
手作業が必要だったのは10件だけだと主張しているが、自己正当化にすぎない。その10件を見つけるためには、全件検査が必要だった。ウェッグ・ザ・ドッグ
Hacker Newsの反応
今の vibe coding は小規模なプロジェクトにちょうど合う段階だと思う
プロジェクトが大きくなると コンテキスト管理 が難しくなり、LLM が不要に多くのコードを生成したり、微妙なバグを作り込みやすくなる
そういうときは再びブレインストーミングのモードに戻って、設計だけ LLM に手伝ってもらい、実際のコードは自分で書くか、骨組みを作って LLM に埋めてもらうのがよい
LLM は既存コードを少しだけ修正したり、既存の構造を活用したりするのはまだ苦手だ。たいてい新しい抽象化を付け足そうとする
私はモジュール構成を自分で設計し、結果も明確に把握している。すべてのコードを細かくレビューし、良いプロンプトとコンテキスト管理（例: サンプルコードの提供、agent.md ガイドなど）を行えば、十分にコントロールできる
コードベースが大きくなると、モジュール間の 強い結合（tight coupling） が性能を落とす
解決策は「実装ではなくインターフェースに合わせてプログラミングする」という原則だ
各モジュールの境界を明確にし、必要な部分だけを公開するインターフェースを別ファイルに分離して、Claude や同僚にはそのインターフェースだけを使わせればよい
そうすればコンテキストが減って、Claude がよりうまく動く
プロジェクトがさらに大きくなるとインターフェース自体が増えることもあるので、そのときはより大きな単位で分割したり、変更範囲を小さくしたりして管理する必要がある
いまやかなり大きなプロジェクトでも、これらを混ぜて使える段階に来ている
「より良いアプリが必要だったのではなく、不完全さに耐えられるシステムが必要だった」という一文が印象的だった
Claude がアイデアを作ったのではなく 実装を担当し、私は 趣味嗜好を担当した という書き方もいい
最近はメールでも「私たちは車輪を再発明したのではない。私たちが車輪なのだ」みたいな文をよく見かける
大げさな単語を使わず、同じ文構造を繰り返すところが人間の癖っぽく見えた
AI は普通、文のパターンをランダムに混ぜるが、これはむしろ一貫した型を保っている
まだ編集感覚が洗練されきっていない人が、意図的に格好よく書こうとしている感じだ
他の人たちがこれを AI っぽいと感じたのか気になる
ただ LinkedIn ではそういう文体が多すぎて、昨日ついに耐えきれず投稿してしまった
おそらく 価値観と雰囲気 の微妙な組み合わせが AI 検知に影響しているのだと思う
まだ vibe coding で成功した大規模プロジェクト は見たことがない
ほとんどは、すでに学習データに存在している小さなプログラムだ
本当に革新的だというなら、新しい圧縮アルゴリズムや 最適な巡回セールスマン問題の解法 のようなものを作ってみてほしい
AI コーディングツールは、自分が得意な領域に集中すべきだ
私はこうしたツールで 小規模ビジネス向けの自動化プログラム をよく作る
おかげで以前なら不可能だったことができるようになり、生産性は 10 倍になった
Perfect Software の記事にあるように、誰かにとって完璧なアプリとは、その人の好みや目的に合ったものだ
LLM のおかげで、こうした 個人に最適化された完璧なソフトウェア を簡単に作れるようになった
大会1、大会2
私のスコアが他の参加者たちの改善を促した
AI がこうした 退屈な作業を取り除いて くれれば、人間は創造的な仕事に集中できる
小さな問題を解くこうした vibe coding のほうが、ずっと価値ある時間の使い方だ
私も数日前に同じアイデアで Claude で本棚アプリ を作ってみた
nindalf.com/books
そのおかげで読書量が増え、ハイライトやノートも見やすくなった
Claude の UI 提案は自分で作ったものよりずっと良く、バックエンドもほぼ同じだった
ただ、ときどき 妙なバリデーションロジック にこだわることがあり、私が自分で直すと「あなたの言う通りです！」と認めた。こういうケースはまれだった
私も似た本棚アプリを作ったけれど、オーディオブックのノート管理 はまだよい方法が見つかっていない
あなたの版も興味深い
私も似たことを試したが、私の場合は Claude の失敗例 だった
andrewblinn.com で本棚画像をクリック可能にしたかった
しかし Claude は Goodreads のリンクを頻繁に間違って生成 し、無効な ID を付けていた
背表紙の認識も不正確で、結局 Figma で手作業 した
Claude が提案した自動化は遅すぎて高すぎた
私も毎年、読んだ本を HTML にした 静的な本棚ページ を作っていた
以前は Delicious Library を再現しようとして記事も書いた
別に必要ではなかったが、本を整理するのが楽しかった
「460冊は規模の問題ではない。動くコードをいつ削除すべきかを知ることは AI に代われない」という言葉に共感した
私も 900 件の評価と 550 冊の本データを持つアプリを作ったが、無限スクロールや複雑な検索 はブラウザが耐えられるうちは入れないことにした
今は「ページ内検索」で十分だ
「精度 90% で十分だ」という言葉が良かった
LLM が新しいエラーを作るとしても、世の中にはもともと エラー許容型のシステム が多い
こうした姿勢は、反 AI 的な見方をする人にも役立つと思う
私も moviesonthe.computer で 映画鑑賞記録アプリ を vibe coding で作った
「自分専用の Letterboxd クローン」という明確なアイデアから始めたので、すばやく進められた
こうした 個人向けアプリを作る力 は非常に大きい
ただ、現在のツールは非開発者に 考え方そのものを教える には不十分だ
あなたの言う通り、プログラミングの背景がある人 のほうがこういうプロジェクトをうまくプロンプトできる
正直、この人が作った成果物の 使い勝手はひどい
本人は達成感を得たのだろうが、実際には生産性向上というより 娯楽用のおもちゃ に近い
それでも、こういう試みから学べることはある
でも個人用ツールなら、楽しさそのものが目的 なのかもしれない
私も子どものころ BASIC で遊び半分にコーディングしていた。生産的ではなかったが、それでも十分に価値はあった