注意: この記事はAI（Claude Code）を活用して執筆されました。内容は筆者の実体験に基づいていますが、一部の文章生成にAIを使用しています。（2025年8月現在の情報を元に書かれています）
1. 概要
無職がClaude Codeを使ってChatGPTとの会話履歴をMarkdownに変換するツールを開発したが、誰も使ってくれなかった話です。
リリースして2週間、XでエゴサしたりGitHubのStar数を確認したりしましたが0件でした。これは誰も使っていないのだろうということになり、せめてネタにしないとOSSも報われないので投稿するに至った次第です。
2. はじめに
このOSS開発を通じて、TypeScriptを勉強した過程でClaude Codeをかなり使い倒したので、そこから得た知見について書いていきます。
正直に言うと、この記事はちょっとタイトル詐欺です。「誰も使ってくれなかった話」と言いながら、実際の内容の大半はClaude Codeを使い倒して得た実践的なTips集になっています。でも、誰も使ってくれなかったのは本当の話なので、そこはご容赦ください。失敗談を期待してクリックした方には申し訳ないですが、せっかくなのでClaude Codeの知見も持って帰ってください。
なお、客観的な事実に基づくことを書いているわけではなく、完全に私個人の感想を述べているだけなので、その点についてはご了承いただければ幸いです。ポエムだと思って読んでいただければと思います。
3. 開発環境と作ったもの
3.1 作ったもの
ChatGPTとClaudeの会話履歴をMarkdown形式でエクスポートするCLIツールです。会話履歴を個別ファイルに分割したり、1つのファイルにまとめたりできます。
自分のAIとの会話履歴を全部Markdownに出力してObsidianに第二の脳を作ろうと意気込んでいました。突発的に作ったスクリプトを汎用化してリリースするに至りました。また、現在無職でTypeScriptの勉強に良い機会だと思ったのも理由の一つです。
3.2 開発期間とAI利用状況
- 3週間、土日平日問わずClaude CodeがUsage Limitになるまでフル稼働。
- もしAPIを直接使っていたら$3000（45万円）ほどかかっていた計算。
利用したAIサブスクリプション：
- Claude Code Max Plan $100/月
- ChatGPT plus $20/月
- GitHub Copilot $10/月
ClaudeのモデルはSonnet4では物足りなく感じることが多かったので、ほぼ全ての作業はOpus4を使うことにしました。
3.3 前提知識
- モバイルエンジニア
- TypeScript 2025年6月から学習中
- 初npmパッケージリリース
- 初homebrewパッケージでのリリース
- 無職（現在案件探し中）
4. なぜ誰も使ってくれなかったのか
4.1 当初の期待と現実
そもそもClaudeとChatGPTをMarkdownに変換しようとした目的はObsidianで第二の脳を作ったり、今までClaudeやChatGPTと対話した履歴から色々な知見が溜まっているためそれをまとめたいと思いました。しかし、実際に出力したやりとりを見てみても、あのときこんなことしたなーと思い出にふけることはできますが、そこまでよいインサイトになりそうにありませんでした。具体的にはまたAIと相談すれば得られる出力でした。
AIと相談した結果としてソースコードという最終成果物があり、そこに思い出や本質が詰まっています。AIとのやりとり自体に本質はなく、時が経てば古い情報になり、AIの性能も進化しているので、疑問が生じたタイミングで改めてAIと相談すれば良いと思います。そのため、本質的にこのツールは不要だという結論に私個人としては至りました。
結局のところ、存在しないユースケースを補助するツールを作成して、結果、誰にも使われなかったということです。
4.2 過剰な機能実装
もし求められていないことがわかっていたのであれば、以下の機能は作らなかったでしょう。
- 日本語と中国語のreadme（維持が難しく、簡単な修正にも結構トークンを消費する）
- homebrew対応（npm対応だけでよかった）
- windows対応（npm対応だけでよかった）
- ファイルの分割モードとまとめるモードの実装
- 出力のquietモードの設定
しかしながら、そもそも自己学習もテーマであったので完全に作らなければよかったということもないのでよしとしましょう（負け惜しみ）。作らなくてよかった機能はたくさんありますが、触りたかった技術があるのでそれはとてもモチベーションになりました。TypeScriptという新しい技術にどっぷり触れられたこと、npm、homebrew でのリリースなど、良い経験になりました。
5. 日々の開発ワークフロー
5.1 5時間サイクルの生活リズム
5時間サイクルに生活リズムを合わせるようになりました。朝起きてすぐにClaudeにおはようと言って5時間サイクルを開始させるのが習慣になりました。
1日に4回のUsageLimitを使い切るサイクルを回そうと思ったのですが、最後の4サイクル目は24時スタートになってしまいます。開発終了が深夜3時になってしまうため、健康を考えて1日3回が限度だということを学びました。
5.2 効率的な作業方法
待ち時間の有効活用
auto-acceptしている時に席を立つとスイッチングコストが尋常じゃないので、席を立たずに次の質問をメモ帳で作成しながら進めました。なるべくPCの前から離れないようにし、今依頼している作業から意識を離さないようにしました。
リアルタイムコードレビュー
Claude Codeが自動で走っている時に変更したコードをVSCode上でgit diffを表示しながら、変更をどんどんgit addするようにすれば、リアルタイムコードレビューができます。Claudeの動いている時間を有効活用できながら意識を維持することができるのでとてもお勧めです。
夜間作業の落とし穴
夜になると集中力が下がってきて、Claude Codeが書いたコードをよく確認せずに何でも受け入れがちになってしまいます。特にリファクタリングはお勧めしません。
結果として、夜に受け入れてしまった謎なコードを翌朝になって困らされるのはよくあります。集中力が下がっている夜はできるだけ頭を使わない、コードに関係ない作業を残しておいてそれをしていくのをお勧めします。
5.3 プラン選択とAIツールの使い分け
Claude maxプランは5xのプランで毎日少なくとも3回はUsageリミットまで使っていました。一時期20xのプラン(200ドル)まであげようと思いましたが、あげなくて正解な部分があります。
理由は一人でどんなに頑張ってOpusを走らせても2時間でUsageLimitがくるので、とても5時間では使いきれません。むしろ、この5時間で使い切らないともったいないという締め切り効果によって、リズムの良い開発が生まれるので都合が良いです。
逆にChatGPTのplusプランのo3を余していますが、Claudeのように5時間のサイクルではなく1週間単位でのUsageLimitなので締め切り効果が味わえず使いきれていません。改善していきたいところです。
個人的にはもっとo3をベースに仕様や実装方針を決める方向で進めたいです。Opus4では仕様の検討や採用するライブラリの選定に物足りなさを感じたので、より高度な知性が必要なユースケースではChatGPT o3で相談していくことが必要だと感じました。しかし、コードのコンテキストを全部読ませやすいClaudeの方が実装方針を決める点では有利なので、o3の使い所が難しいのは否めません。
5.4 複数同時作業の現実性について
5時間使いきれない時はClaude Codeを2つ立ち上げて別々の作業をさせましたが、片方が開発中にテストの実行ができなかったりしました。そもそも2つ同時に使うような作業は人間の脳がボトルネックになるため、片方には長時間かかる作業を、もう片方には単純な作業をやらせるということも試みました。
正直Claude Codeを一つのPCで2つ同時に走らせて指示しながら作業をするのはあまり現実的ではないと思いました。一回の指示でもっと精度よく長時間走ってくれるようになってから考えれば良いと思いました。
Git Worktreeを使えば並行して作業させられるということですが、これも脳がボトルネックになると思います。やったことないので何とも言えませんが、人間の脳は2つのことを同時に考えることが得意ではないらしいので。
6. 技術的な知見とTips
6.1 テスト戦略について
テストコードが足かせになる理由
テストコードが足かせになるのでテストは最小限にしておいた方がいいです。テストコードの作成コストが安いのでつい作りがちですが、リファクタリングした際にテストコードを通すようにAIが無意味なコードを保守したり破壊的修正を回避してしまうのでやめた方がいいです。
推奨するテスト戦略
テストピラミッドとは逆の考えで、詳細なユニットテストを作らせるとそれに引っ張られてしまうため、本質的な統合テストから設置していったほうがいいです。
カバレッジを設定するとかなり意味のないテストをつけがちなので採用しない方がいいと感じました。カバレッジを維持するために意味のないテストを書いて、リファクタリング時もそれを維持するためです。
6.2 アーキテクチャ戦略について
継ぎ足し開発の限界
Claude Codeで最初に大まかな機能を作って、あとから継ぎ足しで機能を追加していくとたちまち昔書いたコードが動かなくなりました。そこで、テストコードを書かせることで防げるかと思ったのですが、細かいテストコードを書いていると先述したようにそれが逆に負債になってしまってかなりドツボにハマっていきました。
クリーンアーキテクチャの有効性
Claude Codeはクリーンアーキテクチャやレイヤードアーキテクチャが比較的得意なように感じました。そこでアーキテクチャを導入することにしました。クリーンアーキテクチャについては以前経験があったので導入してみたところ、Claude Codeの理解度が高く、比較的簡単にリアーキテクチャしてくれました。その後の機能追加でも既存のコードをあまり破壊せずに追加してくれるようになりました。
もちろん全自動にリアーキテクチャをやってくれたわけではなく、私の方でもかなり指示をしてクリーンアーキテクチャは実現されたのですが、そこそこアーキテクチャ違反をせずにやってくれる印象です。
静的解析ツールの活用
さらに静的解析ツールなどを使って依存図を自動生成して、それを読み込ませてから作業をさせるのはとても効果的でした。特にアーキテクチャ違反を修正させたりする作業にはとても効果的でした。
また、クリーンアーキテクチャではなく、より簡易的な依存性の逆転をさせないようレイヤードアーキテクチャでも同じようにClaude Codeの理解力は高いように感じました。
6.3 リファクタリングのコツ
雑に何のコンテキストも与えずにリファクタリングさせるとあまり期待通りのリファクタリングをしてくれないことが多いです。
そこでお勧めなのが、planモードを完遂し切ったあとにすぐにその修正についてリファクタリングさせることです。Claude Codeはちょっとしたタスクでもplanモードでやったほうが精度がでるので、planモードを活用してタスクを実行し、その直後にリファクタリングを行うのが効果的です。
今実装した内容について振り返らせると、割と良いリファクタリングをしてくれる可能性が高いことが多かったです。これは同一コンテキスト上で行うことが意味あるかもしれないので、もしリファクタリングしたい場合は実装してすぐにこまめに行うことをお勧めします。
6.4 ルール管理戦略について
自然言語ルールの限界と対策
やってほしいこと、やってほしくないことをCLAUDE.mdに書いたとしてもそれを守ってくれないことは多々あります。ただ、作業の直前でCLAUDE.mdをコンテキストに与えるとそのルールを守ってくれる確率は高いです。直前に読み込ませたコンテキストは強く覚えてくれているのだと思います。しかしながら、指示の前に繰り返し毎回必要なコンテキストやCLAUDE.mdを与えたりするのは辛いです。
そのため、修正されてしまいそうな箇所を先読みして、コメントとして残しておくとよいです。例えばtsconfig.jsonで厳格なTypeScript設定をしている場合、linterのワーニングやエラーの解決時にコード側の修正を諦めてtsconfig.jsonを修正してしまうことがあります。これを防ぐため、あらかじめtsconfig.json側に「linterを通すために設定を修正してはいけない」旨のコメントを残しておくと、そのような修正を行わなくなります。
自動化によるルール強制
huskyなどのGit hooksを使ってpre-commitやpre-push、commit-msg、post-checkoutを定義し、linter、フォーマッター、test、バリデーション、コミットメッセージルール、ブランチ名チェックなど必要な処理を実行させることで、ルールを守らせることにしました。
それぞれのルールを定義してClaudeに読ませて実行してもらうこともやっていましたが、コンテキストや時間を消費してしまうことがわかりました。自然言語でルールを細かく指定するより、huskyのhooksでエラーメッセージを通じてルールを教えた方が、コンテキストや時間をかけずに対応してくれます。
イメージとしてはGitHub Actionsで検証していたようなことは全部ローカルのコミットやpushの段階で全部検証するようにしたほうがスムーズに開発できる印象でした。もちろんClaude Codeのhooksでも良いと思いますが、あんまりClaude Codeまわりの設定は個人で色々あると思うので、GitHub管理したくないのでその辺はhuskyに寄せるようにしました。
また、アーキテクチャレベルのルールについては、ファイルの依存関係をMermaid図で自動生成するツールをhuskyのpre-commitで実行し、その変更をチェックすることで、アーキテクチャ違反を検出して修正させるようにした方が良いです。また、その際のメッセージをClaude Codeが読み取ることを前提に参照すべきファイルなどを出力するように指定しておくと、こちらがわざわざ指示しなくても自動的に修正してくれるようになります。
6.5 コンテキスト管理について
Claude Codeにアーキテクチャやライブラリの導入理由などをARD（Architecture Decision Record）としてGitHub管理し、各開発時に読み込ませる仕組みを導入しましたが、メンテナンスも含めてうまくいきませんでした。
実装していくのに伴って、こう実装したほうがいいというのはどんどん移り変わっていきますし、その移り変わりをARDに反映するのをつい忘れてしまいます。メンテナンスされていないARDをリポジトリ管理していると、意図していないタイミングでClaude Codeが検索で見つけて読んでしまい、意図しない作業をしてしまうことが結構ありました。メンテナンスされないドキュメントは人間だけではなくClaude Codeも混乱に陥れるということですね。
結果的に、自然言語でのルールはCLAUDE.mdの1つのファイルに収まるレベルのドキュメントしか残さないことにしました。あとは前述したのですが、コード側にルールに近いようなコメントを残すようにしました。
7. バイブコーディング時代への考察
7.1 学習ツールとしてのClaude Code
AIを使うと深く考えずに済む面もありますが、学習効率が良いのは確かです。TypeScriptほぼ未経験の状態で3週間でOSSを作れるぐらいの学習効率を提供してくれます。
イメージとしてはこれはヒカルの碁でいうところの佐為がいる状態と同じです。佐為がいるなら碁は教えてもらったほうがいいです。佐為にずっと打たせた方が無双できるのになんで、ヒカルは佐為に打たせないんだよ！って昔は思っていたのですが、佐為がいるんだったら、私も碁をやってみようかなと思う気持ちが十分わかるのでヒカルの気持ちが今なら頷けます。（ヒカルの碁はほんとにお勧めです）
7.2 エンジニアリングの普遍的な課題
Claude Codeで生じた課題はバイブコーディング特有のものなのか？そうではないと思います。
更新が追いついていないドキュメントに混乱させられたり、カバレッジ維持のために本質的には無意味なテストコードを書いてしまったり、自分が書いたテストコードを維持できなかったりすることがあります。また、テストを通すために無意味な機能を残し続けたり、夜に急いで書いてマージしたコードに翌朝困らされたりすることもあります。これらはバイブコーディング以前から発生していた問題です。
開発スピードは確かに上がるかもしれませんが、エンジニアリングの本質的な悩みや課題は別にバイブコーディング以前も以降も変わらないのだと感じます。であるならば、まだ、しばらく過去の遺産を材料に飯を食っていけそうです（本当でしょうか？）。
7.3 技術の陳腐化と継続的学習
planモードの登場で学んだこと
ここまで色々Claude CodeのTips的な話を多くしてきましたが、正直この知識はすぐに陳腐化すると思います。
実際に経験したのですが、Claude Codeのplanモード登場前にGitHub issueにステップを起票させて、それを逐次確認・更新しながらタスクを漏れなく実施させるプロンプトを時間をかけて作りました。「バイブコーディングの真のやり方を発明した、これで勝つる」と思っていたのですが、すぐにplanモードが登場して一瞬でその優位性（？）が陳腐化しました。
他にも作業の終了時に音を鳴らすCLAUDE.mdの記述方法なども盛り上がりを見せ、私もそれを取り入れていましたが、Anthropic公式がhooksの機能をリリースして、CLAUDE.mdへのそのような記述も不要になりました。2025年8月現在、Kiroでのスペック(spec)開発が盛り上がりを見せていますが、これもおそらくAnthropic公式が早々にspecモードを出すことでしょう。
継続的学習の重要性
ここで言いたいのは、すぐに陳腐化するから無駄だということではなく、このバイブコーディング時代において「今日一番詳しい」ということよりも、「明日も興味を持って勉強できる」ことが最大の武器だということです。
しかし、AIによって開発効率や学習効率がどんどん高まっている時代では、来月になれば新しい学習サポートAIや新しいClaude Codeのモード、新しいエディターなどが次々に登場し、ここで紹介しているような小手先のTipsや便利プロンプトはすぐに陳腐化するでしょう。
そのため、今遅れているからといって焦る必要はなく、明日も新しいことを取り入れる姿勢さえ忘れなければ、きっと大丈夫だと思っています。逆に、今AIツールを使いこなしているからといってあぐらをかいていると、すぐに足元をすくわれるので気をつけたいです。（まさにこのようなTips記事を書いている私が一番怪しいと思っています。）
7.4 会社制約下のエンジニアへのメッセージ
おそらく最近のバイブコーディング時代に会社の制約などあって自由に開発にAIを使えずに自分が取り残されていて不安に思っている人が多くいると思います。
でも大丈夫です。今日の最先端は明日の常識になり、明後日には古い知識になります。大切なのは今どれだけ詳しいかではなく、これからも学び続ける姿勢を持ち続けることです。
8. 振り返りと結論
8.1 そもそもとして誰も使ってくれなかったことは問題なのか?
資本主義的には問題なのでしょうが、個人的にはこれだけ教訓が得られたので全然問題ないです。むしろ、変な勘違いしなくてよかったかもしれません。
一方で、たくさん使ってもらってメンテナンスに明け暮れることで初めてわかることもあると思うので、その機会損失という意味では大負けかもしれませんね。
ただ自分の学習のためだけのサンドボックス的なリポジトリでの開発で3週間フルに使うようなモチベーションは維持できないので、少し遠回りにはなりましたが、OSS開発は良い学習の選択肢だったのかもしれません。
8.2 得た教訓
- バイブコーディングでの悩みは昔からあるエンジニアリングの悩みと変わらない。
- 使ったことない技術を触るのは楽しい。
- OSS開発は勉強になる。
- OSS開発はモチベが維持しやすい。
- OSS開発しても使ってくれるとは限らない。
8.3 結果として良かったこと
- Claude CodeのOpusが出すTypeScriptの提案に対して改善提案を突っ込めるようになるレベルまでに上がったこと。
- OSS開発を経験できたこと。
- npm リリースを経験できたこと。
- homebrewリリースを経験できたこと。
- この記事に書いてあるような学びを得たこと。
Views: 0
