無職が Claude Code を使って 3 週間かけて OSS ライブラリを開発したけど誰も使ってくれなかった話
無職が Claude Code を使って 3 週間かけて OSS ライブラリを開発したけど誰も使ってくれなかった話
注意: この記事はAI（Claude Code）を活用して執筆されました。内容は筆者の実体験に基づいていますが、一部の文章生成にAIを使用しています。（2025年8月現在の情報を元に書かれています）
1. 概要
無職がClaude Codeを使ってChatGPTとの会話履歴をMarkdownに変換するツールを開発しましたが、残念ながら誰にも使われませんでした。。。
リリースして2週間、XでエゴサしたりGitHubのStar数を確認したりしましたが0件でした。これは誰も使っていないのだろうということになり、せめてネタにしないとOSSも報われないので投稿するに至った次第です。
2. はじめに
このOSS開発を通じて、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 前提知識
- モバイルアプリエンジニア（8年ほど）
- TypeScript 2025年6月から学習中
- 初npmパッケージリリース
- 初Homebrewパッケージでのリリース
- 無職（現在案件探し中）
4. なぜ誰も使ってくれなかったのか
4.1 当初の期待と現実
そもそもClaudeとChatGPTの会話履歴をMarkdownに変換しようとした目的はObsidianで管理しやすくするためでした。そして、その情報を元にObsidian上に第二の脳を作ることでした。AIとのやりとりを通じて得た知見を蓄積できると思っていました。
しかし、実際に作成したツールによって出力して、AIとのやりとりを見返したところ、「あのときこんなことしたなー」と思い出にふけることはできますが、正直そこまでよいインサイトになりそうにありませんでした。具体的には、改めてAIに尋ねれば同じような出力が得られる内容でした。これは私が行なっている質問が技術的性質の高いものであったからかもしれません。
AIと相談した結果としてソースコードという最終成果物があり、そこに本質が詰まっています。私の場合だけかもしれませんが、本質的にこのツールは不要だという結論に至りました。
開発を始めて早々に、私個人としては不要なツールであることを認識していましたが、「このツールはきっと誰かの役に立つだろう」と期待して開発を続けた結果、誰にも使われなかったというオチです。
4.2 マーケティングの失敗
（追記: この項目は記事の公開後にさまざまな方面からいただいたコメントから気づきを得たので追記しました🙇♀️）
まず、マーケティングというものを全くしていませんでした。というのも、このOSSは前述したように、自分が作りたいものを作ってそれをみんなに使ってもらうという「プロダクトアウト」の発想で作っていました。
であるならば、「プロダクトアウト」でのマーケティングをしなければいけませんでした。例えば、実際に使ってみて、Obsidian上でグラフビューでの活用方法を動画で紹介したり、X でOSSの立ち上げからリリースまでの過程を実況して、そのストーリーでファンを作るなどのマーケティングを行うべきでした。
私が行なったのは、GitHubにリポジトリを公開して、Xで「OSS作ったよ」と投稿しただけでした。誰も使ってくれないのは当然です。
4.3 過剰な機能実装
もし求められていないことがわかっていたのであれば、以下の機能は作らなかったでしょう。
- 日本語と中国語のREADME（維持が難しく、簡単な修正にも結構トークンを消費する）
- Homebrew対応（npm対応だけでよかった）
- Windows対応（npm対応だけでよかった）
- ファイルの分割モードとまとめるモードの実装
- 出力のquietモードの設定
しかしながら、そもそも自己学習もテーマであったので完全に作らなければよかったということもないのでよしとしましょう（負け惜しみ）。作らなくてよかった機能はたくさんありますが、触りたかった技術があるのでそれはとてもモチベーションになりました。TypeScriptという新しい技術にどっぷり触れられたこと、npm、Homebrew でのリリースなど、良い経験になりました。
5. 日々の開発ワークフロー
5.1 5時間サイクルの生活リズム
Claude Codeには利用制限（Usage Limit）があり、5時間ごとにリセットされるサイクルになっています。この制限に合わせて生活リズムを調整するようになりました。朝起きてすぐにClaudeにおはようと言って5時間サイクルを開始させるのが習慣になりました。
最初は1日に4回のUsage Limitを使い切るサイクルを回そうと思ったのですが、例えば朝9時から開始すると、次のサイクルは14時、19時、24時となります。Usage Limitを使い切るまでには約3時間かかるため、最後の4サイクル目（24時スタート）の場合は深夜3時頃まで作業が続いてしまいます。健康を考えると1日3回が限度だということを学びました。
そのため、途中から1日に3回のUsage Limitを使い切ることを目標に、11時、16時、21時のサイクルを固定にして、間に食事やジム、サウナなどの時間を計画的に入れるようにしました。これでClaude Codeの奴隷の完成です。
5.2 効率的な作業方法
待ち時間の有効活用
Claude Codeをauto-acceptしている状態で待ち時間が暇だからといって席を立つと、もとの作業に戻るスイッチングコストが尋常じゃないので、なるべく席を立たずに次の質問をメモ帳で作成しながら、今依頼している作業から大きく意識を離さないようにしました。
またClaude Codeが自動で走っている時に変更したコードをVSCode上でgit diffを表示しながら、変更をどんどんgit addするようにすれば、リアルタイムコードレビューができます。Claudeの動いている時間を有効活用できながら意識を維持することができるのでとてもお勧めです。
夜間作業の落とし穴
夜になると集中力が下がってきて、Claude Codeが書いたコードをよく確認せずに何でも受け入れがちになってしまいます。特にリファクタリングはお勧めしません。
夜に受け入れてしまった意味不明なコードに翌朝になって苦しめられることが多発しました。集中力が下がっている夜はできるだけ頭を使わないような作業を残しておいて、それを捌いていくのをお勧めします。
5.3 プラン選択とAIツールの使い分け
Claude Code Max Planは5xのプラン($100)で毎日少なくとも3回はUsage Limitまで使っていたので、そんなに使うならと、一時期20xのプラン($200)まであげようと思いましたが、これはあげなくて正解でした。
理由は5xのプラン($100)の時点で一人でどんなに頑張ってOpusを走らせても2時間でUsage Limitがくるので、その4倍のトークンを使える20xのプラン($200)ではとても5時間では使いきれません。むしろ、「この5時間で使い切らないともったいない」という締め切り効果の恩恵を多分に受けていたので、5xのプラン($100)のほうがむしろ効率が良かったように思えます。（ケチったことを正当化しているだけかもしれませんが）
ChatGPT Plusにも課金をしているのですが、Claudeのように5時間のサイクルではなく1週間単位でのUsage Limitなので締め切り効果が味わえず使いきれていません。
Opus4では仕様の検討や採用するライブラリの選定に物足りなさを感じたので、より高度な知性が必要なユースケースではChatGPT o3で相談していくことが必要だと感じましたが、コードのコンテキストを全部読ませやすいClaudeの方が実装方針を決める点では有利なので、o3の使い所が難しいのは否めません。
5.4 複数同時作業の現実性について
5時間でUsage Limitまで使いきれない時はClaude Codeを2つ立ち上げて別々の作業をさせましたが、片方が開発中のために、もう一方でのテストが通らなかったりしました。また、Claude Codeを2つ同時に使うような作業は人間の脳がボトルネックになるため、片方には長時間かかる作業を、もう片方には単純な作業をやらせて、なるべく脳のスイッチングコストを下げるような工夫も試してみました。
正直なところ、Claude Codeを一つのPCで2つ同時に走らせて指示しながら作業をするのはあまり現実的ではないと思いました。人間の脳は2つのことを同時に考えることが得意ではないらしく、体感的な作業効率はどんなに良くても1.5倍ぐらいで、「Usage Limitまで使い切らなけば」というプレッシャーもある状態なので、雑なコードも受け入れがちになり、結果的に作業効率はむしろ下がってしまうこともありました。
Git Worktreeを使えばよりスムーズに並行して作業させられるということですが、やったことないので何とも言えませんが、一つのリポジトリで作業していればコンフリクトの心配もないので、Git Worktreeを使うのは個人的にはあまりお勧めしません。
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、フォーマッター、テスト、バリデーション、コミットメッセージルール、ブランチ名チェックなど必要な処理を実行させることで、ルールを守らせることにしました。
それぞれのルールを定義してClaudeに読ませて実行してもらうこともやっていましたが、コンテキストや時間を消費してしまうことがわかりました。自然言語でルールを細かくコンテキストとして渡して指定するより、勝手に処理されるhuskyのhooksでエラーメッセージを通じてルールを教えた方が、コンテキストや時間をかけずに対応してくれます。
イメージとしてはGitHub Actionsで検証していたようなことは全部ローカルのコミットやpushの段階で全部検証するようにしたほうがスムーズに開発できる印象でした。もちろんClaude Codeのhooksでも良いと思いますが、どちらかというとプロダクトコードに関連する話なので、その辺はhuskyに寄せるようにしました。
また、アーキテクチャレベルのルールについては、ファイルの依存関係をMermaid図で自動生成するツールをhuskyのpre-commitで実行し、その変更をチェックすることで、アーキテクチャ違反を検出して修正させるようにした方が良いです。また、その際のメッセージをClaude Codeが読み取ることを前提に参照すべきファイルなどを出力するように指定しておくと、こちらがわざわざ指示しなくても自動的に修正してくれるようになります。
6.5 コンテキスト管理について
Claude Codeにアーキテクチャやライブラリの導入理由などをADR（Architecture Decision Record）としてGitHubで管理し、各開発時に読み込ませる仕組みを導入しましたが、メンテナンスも含めてうまくいきませんでした。
実装していくのに伴って、こう実装したほうがいいというのはどんどん移り変わっていきますし、その移り変わりをADRに反映するのをつい忘れてしまいます。メンテナンスされていないADRをリポジトリで管理していると、意図していないタイミングで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モードが登場して一瞬でその優位性（？）が陳腐化しました。
他にも作業の終了時に音を鳴らすTipsが登場して、私もそれを取り入れていましたが、Anthropic公式がhooksの機能をリリースして、CLAUDE.mdへのそのような記述も不要になりました。2025年8月現在、Kiroでのスペック(spec)開発が盛り上がりを見せていますが、これもおそらくAnthropic公式が早々にspecモードを出すことでしょう。
継続的学習の重要性
ここで言いたいのは、すぐに陳腐化するから無駄だということではなく、このバイブコーディング時代において「今日一番詳しい」ということよりも、「明日も興味を持って勉強できる」ことが最大の武器だということです。
AIによって開発効率や学習効率がどんどん高まっている時代では、来月になれば新しい学習サポートAIや新しいClaude Codeのモード、新しいエディターなどが次々に登場し、ここで紹介しているような小手先のTipsや便利プロンプトはすぐに陳腐化するでしょう。
そのため、今遅れているからといって焦る必要はなく、明日も新しいことを取り入れる姿勢さえ忘れなければ、きっと大丈夫だと思っています。逆に、今AIツールを使いこなしているからといってあぐらをかいていると、すぐに足元をすくわれるので気をつけたいです。（まさにこのようなTips記事を書いている私が一番怪しいと思っています。）
7.4 AIのトレンドに取り残されて不安に思っている方へ
おそらく会社の制約などあって自由に開発にAIを使えずに自分が取り残されていて不安に思っている人が多くいると思います。
でも大丈夫です。今日の最先端は明日の常識になり、明後日には古い知識になるでしょう。大切なのは今どれだけ詳しいかではなく、明日も興味を持って学び続ける姿勢だと私は思います。
8. 振り返りと結論
8.1 そもそもとして誰も使ってくれなかったことは問題なのか?
資本主義的には問題なのでしょうが、個人的にはこれだけ教訓が得られたので全然問題ないです。むしろ、変な勘違いしなくてよかったかもしれません。
一方で、たくさん使ってもらってメンテナンスに明け暮れることで初めてわかることもあると思うので、その機会損失という意味では大負けかもしれませんね。
ただ自分の学習のためだけのサンドボックス的なリポジトリでの開発で3週間フルに使うようなモチベーションは維持できないので、少し遠回りにはなりましたが、勉強という意味ではOSS開発は良い選択だったと思います。
8.2 得た教訓
- バイブコーディングでの悩みは昔からあるエンジニアリングの悩みと変わらない。
- 使ったことない技術を触るのは楽しい。
- OSS開発は勉強になる。
- OSS開発はモチベが維持しやすい。
- OSS開発しても使ってくれるとは限らない。
- バイブコーディング Tips はすぐに陳腐化するので、常に学び続ける姿勢が大切。
8.3 結果として良かったこと
- Claude CodeのOpusが出すTypeScriptでのコードの提案に対して改善提案を突っ込めるようになるレベルまでに上がったこと。
- OSS開発を経験できたこと。
- npm リリースを経験できたこと。
- Homebrewリリースを経験できたこと。
- この記事に書いてあるような学びを得たこと。
- あなたがこの記事を読んでくれたこと。
Discussion
ナイスチャレンジです！
以下感想を書いてみます。（批判的な内容が気に入らなければ、全然無視してしまってくださいmm
マーケティングが足りなかった？
本文中に触れられていないですが、他人に使ってもらうプロダクトを作ることが目的であれば、一通りのマーケティングは必要だと思いました。
例えば、自分は課題特定や市場分析、作ったあとの広報など、 ChatGPT に聞いて片っ端から取り組むようなことをしています！
などの点が本文に加えて気になりました。これらはマーケティングの作業を軽くでも一通り回せば回避できることなんじゃないかと思っています。
解決策の物足りなさ
もし本当にこの機能を持つツールがあったら自分は使いたいです！
ここでの期待値は、なんの準備をせずとも、コマンドを叩けば、好きな会話を Markdown ファイルに即座に保存できることですかね。
が、説明文を読んでみると、自分でエクスポートをしなければならず、
使って得られる便利さが実際に使うハードルを超えていないと感じます。
（ChatGPT 側のインターフェースや規約などが障害になるのはとってもよく分かるのですが 🙇）
コメントありがとうございます！
まさにいただいたコメントの通りだと思います！！
これは本当におっしゃる通りで耳が痛いです。。。
一方で、OSSなので自分が作りたいものを作りたいという側面もあり、「自分が必要なら他にも必要だと思っている人もきっといるだろう、多少需要が少なかったとしてもやろう！」と始めたものでもあります。
ただ流石にここまで需要がなかったのは自分でも予想外でした😂
しっかり事前にマーケティングしていれば期待値の下がった状態で開発できたはずなので、その面ではマーケティングしておけばよかったと後悔しています。。。
これ実はChromeの拡張機能では既にそのようなツールは存在するのですが、無料版では使用制限があるので課金しないとすべてを変換できず、だったら自分で作ろうと思ったのが最初のきっかけになります。
（もしかすると無料でてきるものもあるかもしれませんが、、、）
今まさにコメント返信をしていて思いついたのは、そもそもCLIではなくてChromeの拡張機能をリリースしたほうがよかったのかもしれませんね笑
そうすれば手間であった事前のエクスポートの手順がなくなるので、もっと使いやすくなって、もっと需要のあるOSSになったかもしれません😂
ChatGPTとのやり取りをエクスポートするツール、自分も使ってます。
・Chrome拡張
・ChatGPTに生成させたtampermonkey スクリプト
結局、既存のChrome拡張は広告がウザかったので、tampermonkeyで動くやつを生成しました。
つまり、必要としてる人は利用実績の多い奴を使うか、自分で自分の満足出来る奴を生成しちゃう。
後発は、検索で見つけてもらえないんじゃないかと……。つらいね。
この生成AI時代ではこの程度のツールなら自分で作れてしまうのでわざわざOSSとしてツールを公開する価値は低いかも知れませんね…つらいです（ ; ; ）
同意頂きありがとうございます。
当方、ソフト開発でメシを食ったことのない素人（ただしPC歴40年）です。
コードを書かない側から見ると、やりたいことの明確化（要件定義）さえ出来れば、生成AIで何とでもなる時代だなぁ、と。
プロのコーダーには世知辛い世界になりましたね。（実現可能性が読める優位性、仕組みへの理解が強み、ですかねぇ）
私は元ITエンジニアで、最近は完全にIT技術からは足を洗ったので界隈には詳しくないのですが、なぜかChromeが通知をあげてきてこの記事を知りました。
技術的なことはあまり分かりませんが、要所がウィットに富んでいて、楽しく読めました！
IT技術とは無関係ですが、高橋さんの向上心というか、勉強意欲に、刺激されます。
AIは人間の細かな技術力を劣化させるかもしれませんが、高橋さんの記事を拝読して、むしろ「どのようにAIを使うか」という戦略的思考を人間に促し、発展させるのではないかな？と思いました。
私は、日常で考えたことや感じたことについて、心理学的観点や歴史的観点などの理論的根拠を求めて、Claudeに相談してます。
昔は課金してたのですが、最近は、無料枠内でのみですけど。
Claudeと対話した履歴は、Googleのスプレッドシートにコピペして、重要な分をハイライトした状態で残してます。たまに読み返してます。
読み返すのは、Claudeに教わった理論がどれだけ私自身に身についているかの確認 or 記憶のリフレッシュのためですね。
Claudeにもう一度同じこと聞けばいいというのは技術分野ではそうかもしれませんが、文系ジャンルでは、やり取りの中で生まれるものがあるので、一度でまったく同じ回答をClaudeから引き出すというのは、試してはいませんが、なかなか難しいのではないかな？と思います。
同じ問いかけをすると、無駄に無料枠使ってしまいますしね。
ディスカッションの場なのに、技術的なこと書けなくてすみません！
コメントありがとうございいます！！
むしろ、私が作ったOSSツールのユースケースを掘っていただきありがとうございます！
これ確かに難しいと思います。
文系理系関わらずAIとのやり取り初めて生まれる価値というものもあると思います。
個人的には、まさにこの「AIとの会話を振り返って重要な部分を探してハイライトした箇所を決める」という行為そのものに本質的な価値があるんだと感じています。
私が作ったツールは、会話をまずMarkdownに変換することでAIが読みやすいフォーマットにして、最終的には、重要な部分をハイライトしたスプレットシートのようなものを自動的に得ることを目的にしたツールでした。
これはこれで素晴らしいのですが、登山するのにヘリコプターで山頂まで辿り着くようなツールを作ってしまったような感覚です。。。
でも、書いていて思ったのは振り返り補助ツールとしてではなくて、自分がどのようなことに疑問を思っているのか? どんな角度から質問をよくしているのか? といった情報が詰まっているので、「今までの会話履歴を元に自分だったらどう分析しますか?」みたいなまさに第二の自分を生み出すような材料にはなりそうですね。
まだまだ、ユースケースは掘れそうですね。。。示唆に富んだコメントありがとうございます🙏
あくまで私個人の話ですけど、AIとの対話履歴管理みたいなツールだったら、使いたいなと思いますね…。
対話履歴の入力はコピペでもいいので、AIの種類別に検索したり、逆にすべてのAIから検索したり、あるいは、ハイライトした箇所だけを表示して、そこから元の会話に飛べたりだとか、
対話期間を指定すると、対話の概要がずらっと並んだり、あるいはハイライト部分だけ並んだりとか、会話のテーマごとに一覧が見れたりとか、ですね。
他の人はどうだか分かりませんが、私は管理が苦手な人で、Googleのスプレッドシートによる管理は正直煩雑だと思ってて（検索機能が不便です）、もっと冴えた管理ツールがあったらぜひ使いたいなと思います。
まあ、こういう管理ツールはあまり作るの面白くない or 元ITエンジニアならデータベース使って自分でなんとかしろよて代物なのかもですが…。
スプレッドシートによる管理は、AIとの対話履歴をコピペ＆ハイライトしてるだけじゃなくて、SNSで投稿した内容のコピペ、考えたこと感じたことやったことなど含めて、日付ごとに入力してる感じです。
日記みたいなものですね。
私も本当に欲しいです。。。
私のツールを使うとMarkdownに分割してくれるのでVSCodeなどのエディターで扱えるので検索性はかなり増すのですが、それ以上でもそれ以下でもないんですよね。。。
もっと自動にカテゴリーとかテーマで分類してくれて、それこそプロンプトの自然言語のように検索できると最高なんですけどね。
いつかChatGPTやClaudeが公式に対応してくれるのを祈ります🙏
私も個人開発している者の端くれですが、自分以外に利用者のいない OSS に価値がないとは思いません。
技術の向上を目指す人に習作は不可欠だと思っていますし、「他人に見せるもの」という前提をおいて作るものと、その前提をおかずに作るものはやはりソースも設計も質が異なるようになると考えています。
また、「お題をもらわなければモノが作れない人」と「自分で課題を設定して、かつ解決できるモノを作れる人」は規模の大小はあれど技術者として隔絶したものがあると思います。
自分の作った作品が使ってもらえない寂しさはたしかにありますが、AI によってコーダーの価値が相対的に下がりつつある現代において、私はこのチャレンジはとても価値のあるものだと感じました。
上から目線になってしまっていますね。失礼しました。
コメントありがとうございます！
これはまさに今回実際にやってみてつくづく感じました。
クローズドな実際の開発現場よりも今回のOSS開発の方がより気をつけることが多かったです。
そして、一般公開するOSSとして耐えられるようにするには、実際に多くの方が使われいる他のOSSを参考にする機会が増えて、そこで始めて得る知見も多分にありました。
技術者としてまた一歩成長できたような気がします。