ハクソク

世界を動かす技術を、日本語で。

Show HN: 「Claude Code」を使った書棚のコーディング

108日前原文(balajmarius.com)

概要

  • 大量の蔵書管理が困難になった経緯と課題
  • AIエージェント活用で実現した自作書棚プロジェクト
  • データ収集・整形・UI構築の具体的な手順と工夫
  • 人間の判断・センスが果たす役割の明確化
  • AI時代の実行力と審美眼の価値についての考察

蔵書管理の限界と葛藤

  • 所有書籍数が500冊を超えた時点で、記憶による管理が困難化
  • スプレッドシートなど単純な方法も「面倒さ」で未実施
  • 実行と意図のギャップがプロジェクトを停滞させる主因
  • AIエージェントの登場で「実行の壁」が低下
  • 自分の役割が「実行」から「判断」へ変化する転機

既存ツールの限界

  • ISBNスキャナーアプリはローカル版や古書で失敗
  • Goodreadsなどもマイナー出版社や珍しい書籍に非対応
  • 不完全なデータが逆にストレスとなり、作業の中断を招く
  • 必要なのは「不完全さを許容できる仕組み」の構築

データ収集とAI活用

  • まず**全書籍の写真（470枚）**を撮影しPCに保存
  • 画像ファイルのリネーム・変換など前処理を自動化
  • AIによりOpenAI Vision API経由でタイトル・著者・出版社を抽出
  • 約90%の精度で自動抽出、残りは手作業で修正
  • 追加書籍も同パイプラインで簡単に反映可能

表紙画像の取得と工夫

  • メタデータは整ったが、表紙画像は未取得
  • Open Library APIでカバー画像取得→半数が低品質・不一致
  • SerpAPI経由Google画像検索で不足分を補完
  • 10冊のみ手作業修正、大半は自動化で対応

書棚UIの再現と進化

  • 最初は表紙グリッド、だが無機質で物足りない
  • 本棚らしさは背表紙のランダムさ・色・厚みにあると再認識
  • 背幅はページ数から自動算出、色も自動抽出し可読性も確保
  • 実物本棚の質感をWeb上で再現する工夫

アニメーションと体験の追求

  • 静的な表示に違和感、Framer Motionで背表紙の傾きアニメ追加
  • 最初は「動きが不自然」→AIの指摘でrender cycle外アニメに修正
  • アイデア試行コストの低下で細部までこだわれるように

不要な機能の削除と取捨選択

  • 無限スクロールを実装→体験悪化で削除決断
  • 「動くコード」でも「不要なら消す判断」は人間の役割

モバイル対応とUIの多様化

  • デスクトップでは満足も、モバイルでは横スクロールが不便
  • 縦積みスタックビューをAIに指示し即実装
  • アニメ・色・データ構造も流用、説明不要の完成度

人間の役割とAIの実行

  • コードはClaudeが執筆・実装
  • 自分は「90%で良しとする判断」「手作業修正」「UI選択」「不要機能削除」などセンスと決断を担当
  • 実行コスト低下で、より「審美眼」や「判断力」が価値を持つ時代へ

AI時代の実行とセンス

  • 実行はAIが担う時代、人間は「何を良しとするか」を決める役割
  • 書棚プロジェクトは、AIと人間の最適な分担の象徴
  • 手作業時代の感覚が過去のものに感じられるほどの変化
  • 実行コストは下がるが、センスの価値は変わらないという実感

Hackerたちの意見

これらは、現在のバイブコーディングにぴったりのプロジェクトサイズだね。あるポイントを超えると、プロジェクトが大きすぎたり、依存関係が多すぎたりして、コンテキストの管理にすごく気を使わなきゃいけなくなる。そうなると、LLMがコードを生成しすぎたり、微妙なバグを生むことを期待しなきゃいけない。そうなったら、個人的にはブレインストーミングモードに戻って、LLMをデザインの手助けに使うのが一番いいと思う。コードは自分で書くか、コードの骨組みだけ自分で作って、LLMに埋めてもらうのがいいよ。コードが多すぎると、LLMは既存のコードを使ったり、賢く数行のコードを置き換えたりするのがまだできないみたい。ほとんどの場合、新しい抽象化をたくさん追加しちゃう。
└
> 既存のコードを使ったり、賢く数行のコードを置き換えたりすることについては、明確に伝えられるよ。
└
プロジェクトのサイズに関しては、バイブコーディングの考えに同意するよ。生成されたコードを見ないことも多いしね。でも、Claude Codeを使って大きなプロジェクトのコードを書くのには問題ないよ。既存のパターンに適応するのも全然OK。ただ、バイブコーディングではないけどね。モジュールの設計は自分でやるし、最終的にどうしたいかはほぼ分かってる。コードはすべて詳細にレビューして、正確に自分が欲しいものになってるか確認するよ。良い指示を書いて、コンテキストをうまく管理する必要があるね（参照用のサンプルコードを与えたり、ガイダンス用のagent.mdファイルを用意したり）。
└
現在、雰囲気でコーディングするのにぴったりなサイズのプロジェクトだね。今のところ…これからどんどん良くなって、最終的にはすべてのソフトウェアがこの方法で書かれるようになるだろうね。
└
今のエンジニアリングコードはバイナリだけじゃなくて、雰囲気コーディングからコパイロットスタイル（デザインやコーディングの支援）を経て、デザインだけの手伝いやAIなしまで、スペクトラムになってる。今の能力は、かなり大きなプロジェクトやリポジトリでコパイロットの範囲をほぼ完全にミックス＆マッチできるほど強いよ。
└
ケン・マイルズの7000rpmの名言を思い出すな。これが起こるのはどれくらいの規模だと思う？この文脈で最も関連性のあるサイズの指標は何だろう。
└
それとも、人間が同じタイプの問題を解決するために設計されたソフトウェアアーキテクチャの方法を適用することもできるよ。コードベースがあるサイズを超えると、他のモジュールの実装に依存するコードを持つことは逆効果になる（密結合）。Claude Codeの用語で言うと、現在のアーキテクチャがモデルにあまりにも多くのコード行を読み込ませていて、パフォーマンスを低下させているってこと。解決策は人間と同じで、「実装ではなくインターフェースにプログラムする」ことだ。--Design Patterns: Elements of Reusable Object-Oriented Software (1994) アプリケーションの異なる部分の境界を慎重に描き、他のモジュールが必要とする部分だけを公開するシンプルなインターフェースを作る必要がある。各インターフェース定義を別のファイルに分けて、Claude（または人間の同僚）には、そのモジュールの内部作業をしているとき以外はインターフェースだけを使うように指示する。そうすれば、大きなコンテキストの部分が解放されて、Claudeは進捗を続けられるようになる。もちろん、プロジェクトは成長し続ける可能性があり、比較的小さなインターフェース宣言が文脈に収まらなくなることもある。その場合は、アプリケーションを見直して、他の部分から分離できる大きな部分があるかどうかを確認する価値がある。Claudeが行う変更の数と範囲を管理することも役立つだろう。すべての仕事がアプリケーションの異なる部分に触れる必要があるわけではないから、プロジェクト管理のスキルがさらに役立つかもしれない。
└
コードがモジュラーであれば、この制限はなくなると思う。AIが毎回全コードベースを読む必要があるなら確かにそうだけど、すべてがうまく設計されていれば、毎回限られたコードセットだけを扱えばいいから、その部分では得意なんだ。
> 90%の精度で十分だと決めた。多くのシステムはフォールトトレラントだし、LLMが新しいバグを生む世界ではそれを思い出すのが大事だよね。この考え方を持ってるOPには拍手を送りたい。もっと多くの反AI派の人たちも、たまにはこのアイデアを考えてみるといいと思う。
└
同意だね。LLMとやり取りしてると、たまに面白い結果が出ることがあるよね。もし90%のやり取りがポジティブな結果を生むなら…それはGoogle検索結果を掘り進むよりも改善だよ。
これは偶然だね。数日前に同じアイデアを思いついて、Claudeを使ってライブラリをバイブコーディングしたんだ。https://nindalf.com/books。元々はもっと読書をするためのきっかけにするつもりだったんだけど、成功したと言えるよ。数年間の低迷を経て、今年の目標を達成したんだ。ハイライトやメモを見るのも好きだし、このUIのおかげで読みやすくなった。Claudeとの体験はほとんど良好だったよ。確かに、UIは自分が考えたものよりずっと良いし、バックエンドも自分が書くものに近い。満足できないときは、欠点を説明できて、ほとんど自分で修正してくれるんだ。こういう小規模で自己完結したプロジェクトは、Claudeのおかげで実現できた。時にはうまくいかないこともあったけどね。開始日と終了日の検証は、z.string().or(z.date()).optional().transform((val) => (val ? new Date(val) : undefined))って決めたんだけど、すごく複雑に見えた。簡略化できるか聞いたら、Claudeは「無理だよ」って言った。z.date().optional.を提案したら、Claudeは「それは不可能だ」って根気よく説明してくれた。でも、試してみたらうまくいった。「あなたは絶対に正しい！」って言ってくれたけど、この行動は例外だったね。
└
あなたの本のライブラリのコードはありますか？僕も一年間に読んだ本を覚えるために似たようなことをしたいんです。
> 私が必要だったのは、より良いアプリではなく、全体のシステムが崩れないように不完全さを受け入れる方法だった。 > Claudeはそのアイデアを発明したわけではない。それを実行したんだ。 > Claudeが実装を担当した。私はセンスを担当した。このスタイルの文章は今でも好きだな :)
└
この書き方は人間じゃない。AIだよ。^^ こういうドラマチックな表現は、ほとんどがAIの影響を受けてる気がする。最近は人のメールでもよく見かける。「私たちは車輪を再発明したわけじゃない。私たちが車輪だ。」
└
その気持ちわかるけど、今回はなぜか引っかからなかったな。でもLinkedInではよく引っかかるから、昨日はコントロールを失って投稿しちゃった。AIで書かれていることを意識させるような価値や雰囲気のダイナミクスが働いている気がする。
└
「それで十分だった。」
└
他の人もコメントしてほしいな、ちょっとアンケートみたいな感じで：俺は「GPT臭」にはいつも眉をひそめる。君が引用したラインも印象に残ったけど、「初期キャリアのブロガー臭」って解釈したよ。似てるけど、AIっぽくはなかった。壮大な言葉を避けてたし、同じフレーズフォーマットを使い回してたから（人間の癖みたいに）、ランダムにフォーマットカテゴリーをサンプリングするAIとは違ったんだ。これは、意図的でパンチのある文体を持とうと真剣に努力してる人から出てくる人間のテキストの姿だけど、まだ編集者の目を持ってなかったり、他の人に校正を頼んでなかったりするから、孤立してると加算的に見えるけど、全体としては素人っぽい行動が残るんだ。みんなは、AIがコピーするように訓練された古典的なトリックを使ってる人間だと感じたのか、それともこのカテゴリーの何かがすぐにAIの使用を暴露するのか？
サイズの境界点は実際に存在するよ。プロジェクトが数千行を超えると、雰囲気でコーディングするのをやめて、意図やコンテキストを管理し始めるんだ。その段階では、LLMは魔法の杖というよりも、速いジュニアみたいになるね。
「意図と実行のギャップは小さかったけど、それでもプロジェクトをずっと“いつかやる”の山に置いておくには十分だった。」その通りだね！これが僕のエージェント、特にClaude Codeとの経験だよ。僕を越えさせるための十分な活性化エネルギーを供給してくれる。次のステップが簡単すぎて、自然に進めるんだ。
雰囲気でコーディングされた成功例は、既にトレーニングデータに複数の形で存在する小さなプログラムばかり見てきた。何か画期的なものを見せてほしいな。AIコーディングがそんなに素晴らしくて、10倍や100倍の生産性をもたらすなら、新しい高効率の圧縮アルゴリズムや最先端の巡回セールスマン問題の解決策を生成してみせてほしい。
└
僕たちがやっているコーディングの多くは繰り返しの作業で、トレーニングデータに存在しているから、AIがその苦労を取り除いて、クリエイティブな作業に集中できるようにしてくれるのはすごくいいことだと思う。
└
その通りだけど、同時に99%のソフトウェアは何らかの形で既に作られているんだよね。これは先週投稿された「完璧なソフトウェア」に関する記事に戻るね。この本棚はそれを書いた人には完璧だけど、他には全く同じものはない。App Storeの一般的なツール（goodreads）は彼のニーズには合わない。でも、彼は自分の目標やデザインの好みにぴったり合った「完璧なソフトウェア」を作ることができたんだ。これは以前にやったことを組み合わせるだけで、LLMを使ってとても簡単に達成できた。これってまだまだすごいよ！ 1: https://outofdesk.netlify.app/blog/perfect-software
└
画期的なことは置いといて、複雑でアクティブに開発されている広く使われているオープンソースプロジェクト（例えば、ffmpeg、curl、openssh、sqlite）のメンテイナーたちが、質の高いAI支援のコミットが増えているって言ってるのを聞きたいな。もしAIが本当に10倍の力を持つなら、これらのプロジェクトは昨年だけで10年分の開発を見ているはずじゃない？誤解しないでほしいけど、AIはプログラミングにおいてStackOverflowやGoogleが昔持っていたのと同じくらい革命的だと思う。既にトレーニングデータに存在するものを調べて、自動的にコードに統合できるのは本当に便利だよ。俺も毎日使ってて、特定のタスクでは何時間も作業を節約できてる。[0] そういうタスクに関しては、確かに10倍の生産性をもたらしてる。でも、そのタスクはソフトウェア開発全体のプロセスのほんの一部に過ぎないから、他の部分はそんなに簡単には自動化できない。だから、AIは一部の人が言うほどの全体的な10倍の力を持っているわけじゃないんだ。[0] https://news.ycombinator.com/item?id=45511128
└
> 画期的な何かを見てみよう。 なんで？ハンマーに壁に釘を打つ以上のことを求める人はいないでしょ。AIのコーディングツールは信じられないほど強力だけど、その力は実際に得意なことに集中すべきじゃない？AIのコーディングツールは、「トレーニングデータに複数の形で既に存在する小さなプログラム」を作るために使われるべき場面がたくさんある。俺は自分の小さなビジネスのためにこういうことをよくやってるよ。以前はできなかったことができるようになった。みんなAIのコーディングツールに、今の姿以上のものを求めてるけど、確かにそれはクールだけど、彼らが得意な仕事を手伝うことで俺の生産性は10倍に増えたんだ。
└
そういうことだよね？人間としての面白い考えをするのは俺の脳の役割で、AIにはそのために作られたチップを使わせればいい。正直、今のままで満足してるし、AGIとかも求めてない。ただ、LLMが俺の思考のスケールに近いことが大事で、「なんでこのロボットと話してるんだろう」って感じないようにしてほしい。
└
こういうコメントはちょっと落ち込むな。今は探求と新しいことを学ぶ時期だと思う。これをやるのにぴったりな方法だよ。問題を解決する小さなプロジェクトだし、既存の代替案を評価するよりも、コードを書く時間を大切にした方がいい。
└
「AIが感心しない」ってコメント、議論に何かプラスになるの見たことないな。最先端の技術は常にあるし、まだまだそれを超えたものもあるからね。
└
LLMエージェントを使って、この2つのコンペでリードできたよ。RustやC++の知識は全くなかったけどね。どちらも実際のアプリケーションがあるんだ。- https://highload.fun/tasks/15/leaderboard - https://highload.fun/tasks/24/leaderboard どちらの場合も、俺のスコアが他のプレイヤーにより良い解決策があることを示して、彼らもスコアを改善するように促したんだ。
└
サンプル外の問題に取り組んだことがあるけど、AIは本当に苦労する。でも、研究プロセスを劇的に加速させるよ。アイデアをテストするのは安上がりだし、サポートツールもすぐに書けるし、LLM自体が素晴らしい研究ツールなんだ。一般的に言うと、LLMはほとんどの一般的な作業に対して10倍以上のパフォーマンスをもたらすと思う。人が手作業でやってることのほとんどはトレーニングデータに含まれてるからね（だからそんなにデータが多いんだ）。その分野で10倍以上の効率が出れば、君が話してる問題を解決するための脳のスペースがもっと空くかもしれない。俺からのアドバイスは、シニシズムを少し抑えて、どう役立つか見てみることだ。正直、AIには未来についてすごく不安を感じるけど、使うのは楽しいよ。
└
マイクロソフトは現在、エンジニアを雇って、全コードベースをRustで書き直すためにvibecodingを使ってるんだ。開発者一人あたり月に約100万行のコードを書く感じだよ。
> 460冊の本はスケールの問題じゃない。動作するコードを削除するタイミングをAIが決めることはできない。これはアプリを自分のために作るときに自分に言い聞かせる大事なことだ。俺には900件以上の評価があるページと、550冊の本を持っている別のアプリがあるけど、ブラウザがそのデータを表示できなくなるまでは無限スクロールや複雑な検索・フィルタリングはやらないことにした。「ページ内検索」は今のところ十分に機能してるよ。
映画の視聴を追跡するアプリをvibeコーディングで作ったよ。https://moviesonthe.computer すぐに「シングルユーザーのレターボックスクローンを作る」みたいな既知のアイデアから始められるのがすごく楽しい。システムプロンプトで自分の好みの技術スタックを説明してね。そこからは、プロジェクトのテイストメーカーになるのが比較的簡単なんだ。自分専用のアプリを作れるのは大きなスーパーパワーだと思う。ただ、今のツールは、すでにソフトウェアエンジニアでないと考え方を教えるのがあまり得意じゃないと思う。Sonnetは抽象化をあまり理解しないし。
実は最近、自分のウェブサイトのために似たようなことをやったんだけど、結局はClaudeの失敗例になっちゃった。ちょっとは助けになったけど、結局自分でやった方が時間がかからなかったな。俺のバージョンでは、実際の本の背表紙の画像が欲しかったんだけど、そういうデータベースがないから、自分の棚（牛乳箱）を写真に撮って、クリックできるエリアを作りたかったんだ。さらに、背表紙から本の適切なウェブページにリンクさせたかったけど、他に選択肢がなければgoodreadsに戻るようにした。Claudeが後者の部分でもあまりうまくいかなかったのは驚きだった。最初の試みではリンクが30%しか機能しなかったのが、75%の正常なリンクを得るために、かなり詳細な指示を含む何度もプロンプトを修正する必要があった。良いURLを生成するのが好きみたいで、本のタイトルを含んだgoodreadsのURLを作ろうとするけど、無効なIDになっちゃうんだ（goodreadsではURLのタイトル部分は無視されるからね）。前者はあまり驚かなかったけど…本に重ねたSVGのアウトラインを生成するためのかなり粗い手動戦略を試みてたけど、最初はうまくいくことが多かったのに、画像の右側では実際の背表紙にすら交差しないことが多かった。サードパーティのセグメンターを使うように言葉で促してみたけど、全然ダメだった。結局、バイナリサーチスタイルの反復的なクロッピング戦略を見つけたけど、これがうまくいったものの、1本の背表紙に6分、ほぼ数ドルかかるから、それをやめて、SVGのアウトラインは自分でfigmaで作ったよ。 * https://andrewblinn.com 下にスクロールして本棚を見つけて、ドラッグしてズームして本をアンロックしてね。