ハクソク

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

Devtoolsはオープンソースであるべきです

2026年8月3日原文(blog.exe.dev)

概要

  • 5年前 は多くのソフトウェアエンジニアが自分用のプログラムを持っていなかった現状
  • エージェント技術 の進化で、ソフトウェアのパーソナライズが非常に簡単になったこと
  • パーソナライズ例 としてShelleyとmeat.devの連携事例を紹介
  • 従来のカスタマイズ とエージェント駆動のパーソナライズの根本的違い
  • ソースコード公開 の重要性と、閉じたプロダクトの限界を指摘

ソフトウェアエンジニアと自作プログラムの現状

  • 5年前、多くのエンジニアは自分専用のプログラムを持たない状況
  • 日々 他人が作ったツール で他人のためのプログラムを書くワークフロー
  • 設定ファイルやプラグイン、拡張機能によるカスタマイズが一般的
  • 自分専用のソフトを作るのは珍しく、ブログやホームオートメーション、自宅サーバー管理など一部に限られる
  • 自作ソフト のROI（投資対効果）は低く、保守も困難なため多くの場合標準環境を選択

ソフトウェアパーソナライズの進化とエージェントの力

  • 現在 はソフトウェアのパーソナライズが驚くほど簡単になった
  • エージェントへの2種類のプロンプトでカスタマイズが可能
    • ソースコードのダウンロードとローカルビルド、変更理由の記録
    • 定期的なアップストリーム同期とローカル変更のリベース、動作確認
  • エージェントが アップストリームとの同期 やカスタマイズの自動管理を実現
  • パーソナライズの 着手・継続 が劇的に容易化

Shelleyとmeat.devによるパーソナライズ事例

  • 個人プロジェクト meat.dev の紹介
    • LLMを活用し、コードレビュー時に不要な部分（importやnilチェック等）を自動で省略
  • ユーザー体験向上のため、 Shelley のUIにmeat.devを組み込み
    • Shelleyのコミット作成時にmeatをバックグラウンド実行
    • ShelleyのDiffビューにmeatのトグル追加、進行中は状態表示
  • これら全てが シンプルなプロンプト一つ で実現可能
  • 従来のVS Codeやvimdiff等への組み込みは極めて困難

エージェント駆動パーソナライズと従来型カスタマイズの違い

  • 従来は 大規模な設定ファイル や拡張システムが必要
  • ソースコードの学習・変更には多大なコスト
  • エージェント活用で 単一ユーザー向けの機能追加が容易 になり、コードレビューも「動けばOK」レベルで十分
  • パーソナライズ可能なソフトウェアは プラグインや設定ファイル不要 の時代へ
  • 例：フォントサイズ変更もエージェントに指示するだけで実現

パーソナルソフトウェアの新時代と再発明の必要性

  • 小規模チームにも パーソナライズの恩恵 が拡大
    • 既存の高機能タスク管理ツールやCMS、CRMの必要性が低下
    • 必要な機能だけを 組み合わせて構築 できる時代
  • パーソナライズ可能なプロダクトには ソースコード公開 が不可欠
  • ShelleyやTiptapのような ライブラリ組み合わせ型 の開発が主流へ

オープンソースとクローズドソースの分岐点

  • ShelleyやPiのような オープンソースエージェント はパーソナライズが容易
  • Codexも同様に拡張可能だが、 Claude Code はクローズドソースのためパーソナライズ不可
  • クローズドなカスタマイズフックに依存せず、 ソースコードが拡張の本質 であることを強調
  • パーソナライズを重視するなら オープンなエージェント選択 が必要

Hackerたちの意見

それには賛成できないな。もしツールがエージェントを通じてカスタマイズされて、何か問題が起きたら、それを直すのはユーザーの責任だと思う。例えば、銀行アプリ（またはSCAツール）をニックネームを使うようにカスタマイズしたとする。もしそれが壊れたら、誰が直すの？

└

そもそも壊れなくても、あなたとあなたのLLMが、あなたがよく知らないコードベースに微妙なバグや脆弱性を持ち込むことがあるし、それをキャッチするユーザーは1人だけなんだよね。

└

AIに何が壊れたか教えると、直してくれるんだよね。サポートに連絡するより、こっちの方がいい体験になることが多い。でも、もしそれがうまくいかなかったらどうなる？これは開発者以外にはあまり一般化しないかも、少なくともすぐにはね。自分たちでアップグレードをしなくても、マージコンフリクトが何かは分かるし、AIに何が悪かったかを伝えるのが得意だと思う。興味がある人には、そんなに難しいスキルじゃないと思うよ。それに、AIが自動で対処できないマージコンフリクトは、上流で何か大きな変更があったことを意味するかもしれない。もっと深刻な問題に直面している人を助ける仕事も出てくるだろうね。もしそれにお金がかかるなら、学びの経験になるのかな。

エンドユーザー向けのオープンソースソフトウェアの利点の一つは、そのソフトウェアの動作を調べたり、変更したりする自由があることだよね。でも、実際にはほとんどの人、特にプログラマーでも、その自由は他の人に頼ることができるってことが多いんだ。ほとんどの人は、よく使うツールのコードを読んで修正するために必要な時間を正当化できない。LLM（大規模言語モデル）は、その状況を変えて、元々の夢を実現可能にしてくれたと思う。毎日何度も「GitHubからx/yをクローンして、Zがどう動くか教えて」ってClaudeチャットに頼んでる。ソフトウェアをコンパイルしてハッキングを始めるのは、以前は面倒だったからあまりやらなかったけど、今はそれをゼロ時間投資のチャレンジとして捉えてる。CodexやClaude CodeにXをチェックアウトしてビルドさせて、10分後にどうなったか見に行く感じ。まだ使ってるソフトウェアを習慣的に修正はしてないけど、1年ほど前にはなかった道筋が見えてきた。

└

以前から、使っているツールに小さなバグ修正を何度も送ってきたよ。特別なことじゃないけど、ツールをいじるのは楽しいし。今のLLM主導のものは期待を裏切ることが多いし、送ったものを無視されることも多い（以前と同じような修正でも）。でも、いくつかのツールはペースを上げて、実際に反応が早くなったりもする（ここは人それぞれかも）。ただ、途中で止まってしまうのが一番イライラする。例えばLM Studio。クローズドソースでバグもあるし（当たり前だけど）、バグを報告するためのGitHubのイシュー追跡もあるけど、報告したことに対してほとんど何も起こらない。イシュー追跡がない方がマシだったかも（そうすれば、LM Studioに触れない理由ができるから）。でも、報告が修正に繋がることを期待して使い続けてる。

└

エンドユーザー向けのオープンソースソフトウェアの利点の一つは、そのソフトウェアの動作を調べたり変更したりする自由があることだ。代表的な例は、RMSがソフトウェアのアップデートが一般的になる前にプリンタードライバのバグを修正する必要があったことだ。それは、ユーザーが自分の変更を維持するための動機が大きかったことを意味する。今では、ソフトウェアがBIOSからOS、リモートAPIまでの永続的なスタックになっているので、ユーザーが自分のプライベートフォークを無期限に維持することを期待するのはかなり無理があると思う。ソフトウェアリポジトリやアプリストアを通じて展開されないローカル専用のメンテナンスされていないプロジェクトでない限り、オープンソースソフトウェアの元々のビジョンは例外であって、ルールではないと思う。

└

はは、そうだね！何回か、ソフトウェアXが期待通りに動かない理由についてClaudeとやり取りしたことがあるんだけど、Claudeがどんどんおかしな説明を出してきて、最後には「コードを読んでみて」と言うと、ちゃんとそれを思い出して実行して、バグや変なUXデザインを見つけてくれるんだ。ほんとに助かるよ。

└

実際の厳しい現実は、大多数の人にとっては、ただの海賊行為をするための簡単な方法でしかないってことだよね。しかも、昨日必要だった機能を実装してくれない可哀想なメンテナーに文句を言う権利があると思ってる。

└

うん、これが速く変わってると思う。『Xをクローンして、どう動くか教えて』には100%同意だね。さらに『XをクローンしてYをどうやってやるか見て、それを参考にZの機能を作る』ってのも加えたいな。ライセンスが許せばだけど。ソフトウェアの改造については、去年の12月にCodexをフォークして、自分の軽量な「プランモード」や他のいくつかの機能を作ったんだ。楽しかったし満足感もあったけど、更新を続けるのがちょっと面倒になっちゃった。当時のモデルはあまり良くなかったし、Rustを先に学んでおくべきだったかも。でも、もう少しでうまくいきそうだった。もっと動きの少ないコードベースだったらうまくいったと思うし、それが8ヶ月前の話だよ。初めて開発ツールを作ってる立場としては、これをどう考えればいいのか悩んでる。私たちはクラウドエージェントとサンドボックスプラットフォームを作ってるんだけど、https://boxes.dev - 著者の製品exe.devと同じ問題領域だよ。クライアントや全体のスタックをオープンソースにすることも考えてるけど、追加してるものが多すぎて、カスタマイズする人は更新が大変だと思う。ホスティング側にも、ユーザーが自己ホスティングしない限り変更できないことがたくさんあるし。でも、ソフトウェアが流動的なもので、みんなが個人的なモッドを書いたり、他の人のを基にして作ったりする世界のビジョンは好きだな。基本的にはフォークがあるOSSだけど、すべてのユーザー（少なくともそのエージェント）がコードに関わってる感じ。

└

ほとんどの人は、よく使うツールのコードを読み込んで修正するために必要な時間を正当化できない。実際、時間をかけることができるときでも、最新バージョンや大きなセキュリティ修正に合わせてパッチを修正するための維持負担を正当化できないんだよね…。

└

自由というのは、他の人に頼ることができることにもっと関係してる。逆に言えば、集団の能力が重要で持続的な変化をもたらすけど、個々の能力もそこに到達するための必要な基盤なんだ。考えてみれば、言論の自由と似てるね。

└

ほとんどの人は、よく使うツールのコードを読み込んで修正するために必要な時間を正当化できない。最近のオープンソースソフトウェアは、依存関係が重い言語で書かれていることが多いから、「適切な」検査をするには、依存関係とコアコードの両方を考慮する必要があるんだよね。サプライチェーン攻撃が増えてるのはみんな知ってるし。

Hacker Newsで議論の続きを見る