コーディング支援ツールで、どうせ終わらなかったはずのプロジェクトを蘇らせる
(blog.matthewbrunelle.com)- 長く放置していた個人プロジェクトは、新しく学ぶことより実装を終わらせることに焦点があり、コーディング支援ツールを試すのにちょうどよかった
- YouTube Music を OpenSubsonic API として公開する shim を再実装し、異なる Subsonic クライアントが同じ方法で接続できるようにした
- 最小限の構成と実装規約を先に固定し、その後は短い反復サイクルで進めながら、OpenAPI 仕様ベースの stub 生成と実クライアント接続テストを並行して回した
- 仕様にだけ合わせた初期実装は実接続ですぐ破綻し、リクエストログの確認と単体テストの追加を繰り返して、検索・再生ができる水準まで引き上げた
- 学習用の stretch プロジェクトではなく、ただ存在していてほしいプロジェクトであれば、コーディング支援ツールは後回しにしていた作業を実際に使えるサービスへ変えるのに大いに役立つ
プロジェクトの背景とアプローチ
- 以前に手を付けたものの完了できなかった個人プロジェクトは、AI コーディング支援ツールを試すのに適していた
- 蘇らせた対象は、YouTube Music と OpenSubsonic API をつなぐ shim だった
- OpenSubsonic は、音楽ストリーミングのクライアントとサーバーを分離するための API 契約として使われた
- サーバーには Navidrome、デスクトップクライアントには Feishin、Android には Symfonium を使用した
- shim は YouTube Music を OpenSubsonic API に合わせて公開し、どのクライアントからでも接続できるようにする
- メタデータ取得には
ytmusicapi、ストリーミングにはyt-dlpをプログラムから呼び出した - 基本的なストリーミング接続は比較的簡単だったが、仕様に沿ってすべてのエンドポイントを実装するには長いしっぽの作業が残っていた
- メタデータ取得には
- このプロジェクトは、新規性や独創性のある問題よりも明確な仕様の実装が中心だったため、コーディング支援ツールと相性が良かった
- Claude Code と Opus 4.6 を使い、最初から再実装する実験として進めた
初期セットアップ
- 出発点は、構造をあらかじめ制限した最小プロジェクトだった
uvプロジェクトを作成し、fastapi,pydantic,ytmusicapi,yt-dlpを依存関係に追加したmain.pyは FastAPI のサンプルメインファイルに差し替え、OpenSubsonic の OpenAPI 仕様をフォルダに入れた- README にはサーバーの役割、使用ライブラリ、ドキュメント URL、
openapi.jsonの場所を簡潔に記した - 空の TODO ファイルを追加し、
/initでCLAUDE.mdを生成した
CLAUDE.mdには実装規約を別途記述し、繰り返しの指示を減らした- メソッド引数と戻り値に型アノテーションと docstring を要求した
- データモデリングは Pydantic V2 の規約に合わせた
- docstring には Google スタイルの args、returns セクションを要求した
- テストは上位レベル関数と
assert、fixture を使う最新の pytest スタイルに統一した
- この出発点は git repository としてまとめておいた
MVP 実装の流れ
- 作業方法は計画モードと短い反復サイクルで回した
- 次の作業をプロンプトとして投げ、初期計画で抜けている点や問題を確認した
- 噛み合わない場合は関連リソースのリンクを追加で渡し、複数の選択肢があるときは検索ツールでより慣用的な方法を探させた
- 作業後には
"Accept and clear context"を使ってコンテキストを空にし、反復した
- 最初の実装は、OpenAPI 仕様から新しい JSON エンドポイントだけを stub として作ることに集中した
- 古い XML エンドポイントと新しい JSON エンドポイントが併存していたが、新しい方だけを扱うよう範囲を絞った
- 実装後には、すべてのメソッドが正しいか再確認する検証段階を入れた
- 仕様があっても初回の試行ではミスが出て、二度目の確認で大半を捕まえられた
- 大きな変更の後には
/initを再実行し、CLAUDE.mdを新しい状態に合わせて更新した - 次の段階は、検索とストリーミングが動く最小機能を定義して実装する作業だった
- Subsonic クライアントを接続し、曲を検索して再生できる最小機能を目標にした
- 検索には
ytmusicapi、ストリーミングにはyt-dlpを使った
実接続で見えた問題と補正
- 見た目にはもっともらしい実装がすぐできたが、実際に Feishin に接続するとすぐ崩れた
- クライアントで直接テストし、サーバーのリクエストログを Claude Code に渡しながら修正を繰り返した
- 仕様だけでは見えない細かな差異もあり、たとえばエンドポイントの
.view接尾辞は取り除く必要があった
- エラーが出るたびに単体テストを新しく作り、回帰を防いだ
- 数回の反復だけで、Feishin で実際に音声が再生され始めた
- 核心的な問題は、stub エンドポイントが何も返していなかったことにあった
- ほとんどのエンドポイントは、中身が空でも構造が正しいレスポンスを返すように変える必要があった
- ただしこの水準の MVP は、以前の POC と大きくは変わらず、実際の使い勝手はその後の長いしっぽの作業にかかっていた
長いしっぽの作業と機能全体の拡張
- OpenSubsonic ドキュメント によれば、API は約 80 個のエンドポイントが 15 カテゴリに分散していた
- MVP に必要な範囲は比較的小さかった
getLicense,getUser,getGenres,getMusicDirectoriesは空だが有効なコレクションを返すgetSongはクエリパラメータの ID をそのまま返し、既定値を埋める pass-through として処理したsearch3は単純なytmusicapi呼び出しで実装したstreamはasyncio.to_threadで包んだyt-dlp呼び出しで"bestaudio"形式の URL を抽出したgetCoverArtはyt-dlpでカバー画像 URL を取り出した
- 実際にSubsonic クライアントの全機能を支えるには追加作業が必要だった
ytmusicapi呼び出しには単純なメモリキャッシュを入れ、利用制限を避けた- 音楽メタデータの保存には
sqliteを使い、browsing カテゴリの全エンドポイントを実装した getTopSongsも top songs 一覧を問い合わせて処理した
- ストリーミング中には曲をディスクに保存し、再ダウンロードを回避した
- クライアントがダウンロード完了前に stream エンドポイント接続を切る場合、未完成ファイルを掃除する追加処理が必要だった
- こうした作業は本来手作業でもできたが結局終えられなかった部分であり、配布予定がなかったため認証のような難しい部分は依然として飛ばした
- 最終的には、短い夜の時間の中で Subsonic クライアントが接続できる動くサービスを作り、プロジェクト名は
Sub-standardとした
どこに使うべきか
- コーディング支援ツールを無条件に押し進めるのではなく、依存による能力低下への懸念もあわせて持っていた
- 個人プロジェクトは大きく二つに分かれていた
- 学びと成長のためのstretch プロジェクト
- ただ存在していてほしいと感じるプロジェクト
- 今回のプロジェクトは後者に属し、コーディング支援ツールはこれまで終えられなかった願いを形にするのに向いていた
- 本来なら手を付けられなかったはずのプロジェクトを実際に持てるようになり、読めていない本の山を一つ減らす感覚に近かった
- 重要な基準は、後者のプロジェクトをやるかどうかよりも、前者の学習用プロジェクトも引き続き並行して続けているかどうかにあった
1件のコメント
Hacker Newsの意見
いちばんよく放置していたプロジェクトはビデオゲームだった
中断したプロジェクトのフォルダが何十個もあるけれど、今ではそれを実験としてもう一度受け止めている
先週そのうちの1つをClaudeで再開してみたら本当に相性が良くて、方向性もすぐに正してくれた
もともと捨てたプロジェクトだと伝えておいたら、まずはV0のゲームプレイループを完成させて、そこから面白さを見つけて広げようと後押ししてくれたので、諦めずに済んだ
ゲームデザインのアイデアを渡すと動くコードを出してくれるし、proceduralアルゴリズムの論文を渡すと実装まで持ってきてくれるし、アイテムのブレインストーミングもするし、グラフィックアセットも作るし、さらにはlore構築まで手伝ってくれた
Claude Code + Godotの組み合わせは本当に楽しくて、久しぶりにコンピュータを使うこと自体がこんなに楽しかった
非難したいわけではないけれど、かなり興味深く、少し居心地が悪くも感じた
実験フォルダが何十個もあったが、そのかなりの部分が今では実際のプロジェクトになりつつある
今では実際に動くものもあるし、依然としてエージェントには複雑すぎるものもある
それでも個人用アプリを作るのはどんどん簡単になっている
近いうちに「Alexa、冷蔵庫の食べ物を撮影して栄養情報を集めて、運動アプリと同期して、健康アプリの目標に合う材料と比較して、予算・地域・食事制限に合うもっと良い材料をメールで教えてくれるiPhoneアプリを作って」と言えば、15分でアプリができるレベルまで行きそうだ
たとえば壊れたtresファイルが何度か出てきたし、LLMにIDを生成させるのもかなり不安定に感じた
その上に一種のライブナラティブを載せる形だ
ローカルモデルはまだ遅くて弱いが、それでもどんな結果が出るかを見るのはかなり興味深かった
本当に素晴らしい
今では個人用ソフトウェアがものすごく増えた
昨日はMediaWikiに完全統合されたネイティブのテキストエディタを作り、リンク自動補完と文法入力補助まで付けた
こういうソフトウェアは他人にはほとんど価値がないので、自分以外に作る理由がなく、自分も以前は時間がかかりすぎて作れなかった
でもエージェントにコーディングを任せると、ボトルネックは実装ではなく自分の注意力になり、頭の中の空きスロットにこうした個人用作業を投げ込むやり方がうまくハマる
本当に良い時代だと感じる
AIのおかげで、COVID以降の燃え尽きと中途半端なプロジェクトの山を乗り越えられた
今日はターミナル関連のRDPツールも直したし、10年前にOpenRAへ上げたissueにも再び取り組んでいる
エンジンは10倍速くなり、pathfindingも今ではだいたい正しく動く
個人ツールが120個くらいあり、ボトルネックが実装からコンテキストスイッチングへ移ったというのはまさにその通りだ
だから今では各プロジェクトルートにmarkdownファイルを置いて、止めるたびに状態と次のステップを書いている
そうすれば戻ってきたときに20分かけて「自分はいまどこまでやっていたんだ？」を復元するコストを払わずに済む
どうせ他人は使わないのだから、edge case対応やドキュメント化の圧力もなく、自分の問題だけを正確に解決してすぐ次へ進めばいい
今感じているこの生産性の爆発を見ると、これほど多くの小さなニーズを積み上げるにもかなり時間が必要だったはずだ
どれほどニッチか考えると笑ってしまうほどだ
もともとコードは書けたが時間がなく、AIはオープンソースプロジェクトを世に出せるようにしてくれた完全なゲームチェンジャーだった
以前は作る気にまではならなかったLinux向けローカルGUIアプリを、今では嬉々として作っている
Samba 4 Active Directory Domain Controllerをリモート管理するLinux GUIアプリだ
Linux Mint / CinnamonとGtkStatusIconを使うGTK環境向けのKerberosチケット管理GTK3システムトレイアプリだ
どちらも自分が実際に必要として探していた種類のアプリだからだ
コーディングアシスタントのおかげで、モジュール設計まで含めた深い構造変更を以前よりはるかに少ない時間で試せるようになった
もちろん代償がないわけではなく、一部のモデルは保守性の基準に達しないコードをしばしば出してくる
書く時間を節約できたからといって、繰り返し修正や整理、system promptやinstructionファイルの補強にかかる時間が消えるわけではない
ツールを使いすぎるとdeskillingするのではと心配するという話にはあまり同意しない
自分はミレニアルだが、手工具と昔ながらの木工の継ぎ手で家具を作っている
誰かに教わったわけでもなく、オンライン資料を見ながら身につけただけだが、それでも結局は欲しいものを学べた
後でその技術を失うのではと怖くないのも、必要になればまた身につければいいからだ
本も、動画も、道具も、木材もなくならない
AIを使うからといって、手でコードをあまり打たなくなったせいで脳にブラックホールができるわけではない
アルツハイマーのように情報を永遠に失うわけでもなく、少し温め直す時間がかかるだけですぐ戻ってくる
コーディングから管理職に移って数年後に戻った人たちも、少し錆びついただけでまた取り戻している
特に個人プロジェクトなら、わざわざOpusトークンを燃やす必要もない
安いサブスクでMiniMaxのようなものを使い、コンテナでyolo modeで回し、コンテキストとプロンプト、Web検索、beadsのようなチケットシステムだけ渡せばいい
急ぎでもないのだから brainstorm → plan → implementation → testing の順を守り、mockやunit testだけでなく実際のテスト手段まで入れておけば、時間とお金を節約しながら最終的に完成まで持っていける
12年前、自分の1日/1週/1か月がどれだけ残っているかをバーの長さで見せ、天気も最高・最低気温や雲量などをバーで表すシンプルなアプリを作ろうとしていた
テキストとASCIIではある程度できたが、毎日使いたくなるほどのインターフェースを作るのに失敗し、グラフィカルUIは結局作れなかった
そこでClaude Codeに欲しいグラフィカルインターフェースを説明して回してみたら、まさに自分が欲しかったアプリが出てきて、自分の知らなかった日付パーサのバグまで見つけてくれた
今ではそのアプリを画面の隅に常に表示している
次は、子どもたちの学校が休みの日の朝にアラームを自動でオフにしてくれるiPhoneアプリを作るつもりだ
iPhoneアプリはまったく知らず、学ぶ時間もなかったので、以前は考えもできなかった
個人用アプリではClaude Codeは本当に素晴らしく、コード品質がそこまで重要ではないので、そのままの成果物で十分使える
何年も使っていたMac用clipboard managerがOSアップデート後におかしくなり、App Storeの代替アプリにも自分の欲しい機能がなかった
そこでSimon WillisonのSwiftUI vibe coding記事を見て、Claude Codeで自分で作った
何度か反復は必要だったが、今ではMacのメニューバーで自分が欲しかった機能とそれ以上を全部やってくれている
特にCCに追加機能のアイデアを聞いてみたら、自分では思いつかなかった選択肢を長々と提案してくれて、選んだものをそのまま実装させたのがかなり印象的だった
2日前には、LibreOfficeの新しいmarkdown編集コンポーネントに似ているが、もっと小さく軽い専用markdownエディタが欲しくなった
そこでGPT 5.5で概要を組み、CCで実装したところ、2回のvibe codingセッションだけで、ファイルのオープン・作成、ワープロ風編集、canonical markdown保存を行う軽量なネイティブMacアプリがほぼ完成した
markdown tableだけまだなく、それは今日さらにやらせてみるつもりだ
https://simonwillison.net/2026/Mar/27/vibe-coding-swiftui/
https://news.ycombinator.com/item?id=47298885
何かを作るのは好きだが、ときにはただ出来上がった結果を早く手に入れたいことがある
特定目的の個人ツールを、週末を丸ごと1つ潰さずに手に入れたいとき、LLMの助けは本当にありがたく、コード品質はそれほど重要ではない
iPhoneでは標準のShortcutsアプリで解決できる
すべてのアラームをオフにするshortcutを作り、カレンダーのようなシグナルを読んで特定の日付や時間にアラームをオン/オフするようにできるし、定期スケジュールで回せばいい
サイドプロジェクトは、たいていやりたい気持ちがなければやる価値は低いと思う
プロセスと経験が優先なら余暇であり、結果が優先なら仕事と呼ぶ
結果のためだけにサイドプロジェクトをたくさんやるなら、結局は自由時間に仕事をしているのと同じで、それが本当に自由なのか疑問だ
現代社会はすでに私たちに過剰な結果を要求しているのだから、サイドプロジェクトくらいは心のために残しておきたい
ただし、より大きな善のために信じる目的があるなら例外かもしれず、そうした目的はプロセス自体を豊かにもできる
別の趣味をもっと楽しくしてくれるソフトウェアが必要なときがあるが、だからといって趣味Xの時間を削ってそのソフトウェアを自分で作りたいわけではないこともある
しかもそういう作業は、自分が楽しくやりたいタイプのコーディングではない場合も多い
こういう点こそ自分にとってLLM支援コーディングのsweet spotで、実際にほかの趣味をもっと楽しむためのhelperアプリをいくつも作った
依然として趣味の時間ではあるが、その趣味がコーディングである必要はない
でも解決したいitchや叶えたい野心がありながら、時間や動機が足りなかった場合、それをなぜ自由時間の労働と見なさなければならないのかわからない
以前は週末や休暇を丸ごと食っていたプロジェクトが、今では15分で骨組みを立てられるのだから、むしろ仕事の反対側に近い
30年以上プログラミングしてきたが、コマンドラインアプリだけでもずっと満足していて、最近になってようやくQtを学んでちゃんとしたデスクトップアプリUIを付け始めた
学習曲線は非常に急だったが、今ではある程度乗り越えた
ところがLinkedInにアプリのスクリーンショットと無料オープンソースだと投稿したら、肝心の自分を採用するわけでもないLinkedIn的な人たちから何百件ものコメントが付いた
「私たちのワークフローに統合したい」とか「これを試した人が初めてではない」みたいな反応だったが、まったく動機づけにならず、むしろ人のために働かされるか無意味な批判を受ける感じがした
そのショックで1か月ほど手を止めたが、結局、自分が好きだったのはQtを学び、昔のプログラムたちが生き返って動くのを見るプロセスそのものだったのだと整理できた
だから今ではこれを自分のproject carのように扱っている
ひたすら分解しては直し、データモデルを完全に作り直して別の設計の長所短所を見て、グラフィックビューも自作し、言語翻訳まで付けてみる
機能的にはすでに完成しているが、内部構造が完全に異なるバージョンが5つくらいあり、まさにそこが楽しい
仕事中ずっと便利に使っていて、LinkedInではもう二度と触れないことにした
個人repoの中にノートアプリの試作品が3つもあり、どれもアイデアと自由時間の隙間で止まっていた
でもClaude Codeのおかげで、本当に欲しかった1つを2か月で完成させた
作る過程そのものが、これまで見つけた中で最高の趣味で、ゲームやスクロールよりずっといい
何年も温めてきたアイデアがついにリリースされると、そのアプリには自分の一部がもっと深く入ることになるし、こういうものを作るソロビルダーはこれからずっと増えると思う
古いプロジェクトを作り直すことを貶したいわけではないが、市場は極端に特化したプロジェクトであふれる可能性が高い
昔はアプリの箱に仕様書が貼ってあったが、今では用途と範囲を説明する新しいモデリング言語のようなものが必要になるのかもしれない
自分の経験もほとんど同じだった
比較集計用のサイドプロジェクトが1年以上20%完成の状態で止まっていて、月に1回開いてやることリストを見ては疲れてタブを閉じていた
でもClaudeと週末を何度か一緒に過ごしたら、半分できた壁を越えられた
驚いたのは純粋な速さではなく、何かやろうとするたびに、まず自分の古いコードを1時間かけて頭に再読込しなければならない再突入コストが消えたことだ
大げさなhypeにはうんざりするが、こうしたツールを嘲笑う人たちの多くは、実際にはこういう退屈な作業にどれだけ使えるかを自分で試していないのだと思う
いつも自分が処理できるよりアイデアの方が多く、その中にはかなり良いものもあった
AIツールのおかげで、今ではそのうちもっと多くを一応動く形に実装できるようになった
皮肉なことに、そうした実装の価値は急速に下がっている
数週間前には、ブラウザで動きサーバー不要の小さな検索ライブラリを作ったのだが、Elasticsearch風でterm/matching queryとaggregationの大半をサポートし、ANN vector searchまでWebGPUで付けた
ほとんど「feature Xを入れよう」と言えばすぐ実現する感じで、実際のWebサイトでもすでに使ってみた
スケールはしないが、ブログやドキュメントサイトにはとても良く、ドキュメントサイトは https://querylight.tryformation.com/ にある
自分が思い描いた通りに正確に動くし、Elasticsearchのロングテール機能も大きな労力なしにさらに追加できそうだ
一方でGitHubでの反応はかなり鈍かった
今ではみんなAIで自分のものを作るのに忙しく、他人の努力をあまり歓迎しなくなっているようで、実際それは理解できる
検索ライブラリが必要なら自分で生成してもいいし、AIに適当なものを選ばせてもいいからだ
そもそもこれを作るのにも、ものすごい労働が必要だったわけではない
こうしたプロジェクトの経済的価値は急速に下がっている
それでも自分は作るのが好きだから続けるし、こういうツールを扱う学習曲線を身につけることも重要だと思っている
これからもやるべきことは多いだろうが、人々はより少ない支払いでそこそこ良い結果を期待するようになるだろうし、その期待に応えるにはツールへの習熟が必要だ
結局、可能な範囲が広がれば野心の基準も一緒に上がるだけで、AIが代わりに働いてくれるのだから人間はもう努力しなくていいと考えるなら見当違いだ
自分もここ数か月はとても長時間働いている
数年間、毎週いくつもの製品アイデアを思いついていたが、全部Apple Notesに積まれているだけだった
でもこの1か月でそのうち3つを実際に使えるbetaにまで作り、今では3つとも毎日使っている