【nao1215/prompt】コードを読むのが辛いから、放置されたOSSをforkせずに作り直した話

前書き：OSSが放置されることは当然のようにある

「OSSは、人気があれば活発にメンテナンスされる」

そのように考えている方がいらっしゃるのではないでしょうか。現実は、そこまで甘くありません。私が利用していた c-bata/go-prompt（5.4 stars）は、ライブラリとして採用した時点でメンテナンスが滞っており、結局3年間殆ど更新はありませんでした。

　

c-bata/go-prompt（下図は、同じ作者のc-bata/kube-promptで用いられるgo-prompt）は、利用方法が分かりやすく、シェルのようなプロンプトを実現するには便利なライブラリでした。ただし、まだ枯れたソフトウェアではなかったため、バグが存在しました。先程述べたようにメンテナンスが滞っていたため、バグ対策を利用者側でワークアラウンド対応するか、諦めていました。

　　　

私もOSSを開発する立場なので、メンテナンスが滞る原因にいくつか心当たりがあります。

• 多忙
• ライフステージの変化による心境の変化（注：OSS開発ではメンタルも大事です）
• 興味の対象が別に移っている
• モチベがない。燃え尽きた

開発者の心境を実際に聞いたわけではないので、本当の原因は不明です。今回の一件に対して、私個人としては「よくあることだ」と捉えていました。「今後、どうやってバグを潰そうかな、ガハハ」ぐらいの軽さです。ガハハ。

 

ちなみに、c-bata/go-prompt は愛されていたので、私がライブラリとして採用した頃に有志が「go-prompt/go-promptとして、組織で管理しよう（意訳）」と提案しており、私はその行く末を見守っていました。最終的には、組織化の提案も失敗しており、c-bata/go-promptのメンテナンス問題は再び宙に浮いていました。

　　　

誰かのforkを使うか、forkするか

さて、2022年にc-bata/go-promptをnao1215/sqlyに採用した私は、2025年8月頃にc-bata/go-prompt起因のバグとどのように向き合うべきかを考えていました。

 

まず、誰かのforkを使う案が思いつきました。この案は、本質的には何も改善していません。fork先のメンテナが燃え尽きてしまえば、同じ問題が再発します。私がバグ修正のPull Requestを書いても、マージされなければ意味がありません。また、何となく心理的に、forkしたOSSを使うことに抵抗があります。

 

次に、自分でforkして、nao1215/go-promptとしてメンテナンスを続ける案が思いつきました。本案は、オーナーシップを持てる点でメリットがあります。その一方で、「他人が書いたコードを読み込むコストを受け入れなければならない」という圧倒的なデメリットがあります。

 

私は数百万規模のコードを読んだ経験がありますし、一日に20件近くのコードレビューをした経験もあります。そんな私でも、コードリーディングは脳に負荷がかかります。別の言い方をすると、私はコードリーディングがそこまで得意ではありません。プライベートの時間に、メンテナンスのためにコードを読みたくありません。この文章を書いていて気づきましたが、私が他人のOSSに対して殆ど貢献しない理由は、「コード読むのが下手だから」なのかもしれません。コミュ症なのもありますが……

　

LLM時代は、作り直すコストが安い

forkを嫌った私は、精神的続編みたいなノリで、nao1215/promptとして作り直しました。最初のバージョンは1日で完成しましたが、動作確認したらバグの嵐でバグフィックスに追加で1日かかりました。精神的続編なので、APIの互換性はありません。既に、nao1215/sqlyに組み込んで期待通りに動いていることを確認済みです（下図）。Windows環境では、動作が怪しいだろうと踏んでいます。

   　

提供する機能

• 複数行入力サポート
• 入力補完機能（c-bata/go-promptと大幅に仕様が違います）
• 履歴機能
• キーバインド設定
• カラースキーマ設定
• クロスプラットフォーム対応（Linux、macOS、Windows）

　

nao1215/promptの開発における特徴として、Claude Code、cursor、GitHub Copilot の設定ファイルをnao1215/prompt内に始めから置いています。私は、Vibe Codingで開発する流れは止められないと考えており、私自身もClaude Codeを利用しました。

 

完全な余談ですが、私にとってVibe Codingは外注管理です。適切な要件定義を伝え、開発中に適宜サポートし、検収で致命的なバグや仕様不備を洗い出します。20代の頃の経験が、こんな形で活きるとは思っていませんでした。私はMCPやカスタムスラッシュコマンドで頑張らず、プロンプトの作文だけで乗り切ってます。Vibe Codingが楽しいかと言われれば、全く楽しくありません。

 

楽しくない代わりに、LLMのおかげで思いつきを形にするまでの日数が1〜3日程度に短縮されたので、妄想が捗るようになりました。例えば、「独自DSLから、サーバー／クライアントのソースコードおよびswaggerを生成できるWebフレームワークがあると便利では？生成対象を複数のプログラミング言語にすれば、独自性があるのでは？」みたいな妄想をするようになりました。LLMを使えば、自分程度が思いつくことはある程度形にできるので、妄想日記を書くのが楽しいです。

 

最後に：本記事に全く関係ないけど、CTFも作った

「あいつは、Vibe Codingに魂を売った」

そんな声が聞こえてきそうですが、その通りです。一応、最近はVibe Codingだけでなく、不正対策やセキュリティの勉強もしていました（過去形。今はマネジメントの勉強をしています。機械学習も勉強したい……）。

 

私は、現職の株式会社カンムでVisaプリペイドカードの不正対策を担当しており、その流れで「ハッキングラボの作り方」「HackerOne」でCTF（Capture The Flag）を黙々とチャレンジしていました。CTFの次は、バグバウンティを頑張ったのですが、某サイトの脆弱性を探せず力尽きました。

そんな力尽きた私に、CTFの作問依頼が来ました。カンムはGo Conference向けにでCTFを出す伝統があり、今回は3名で作問と実装を行いました。CTFの王道問題が作れたのではないかと考えています。是非、楽しんでいただきたいです。

問題へのリンク：https://github.com/kanmu/gocon2025-ctf