- Electronは HTML・CSS・JS ベースで Windows、Mac、Linux を同時にサポートするデスクトップアプリを作れるフレームワークで、Slack・Discord・VS Code など多くのアプリがこれを使用している
- しかし各アプリが Chromium エンジンを個別に同梱するため容量が大きく、遅延・無応答の問題が発生し、OS 機能との統合も限定的である
- コーディングエージェントが仕様とテストに基づいて プラットフォーム別のネイティブコード生成を行えるようになり、Electron の利点は薄れるようにも見える
- しかし実際にはエージェントが開発を 90%までしか自動化できず、最後の10%の例外処理と保守は依然として難しく、人手に依存している
- したがって Anthropic の Claude アプリのように、エージェント技術が進歩しても Electron を使う現実的な理由はなお存在する
Electronの利点と限界
- Electron は Web 技術で クロスプラットフォームのデスクトップアプリを構築できるようにする
- 1つのコードベースで Windows、Mac、Linux をすべてサポート
- 既存の Web アプリコードを再利用できるため 開発効率が高い
- 欠点として アプリ容量の増加と 性能低下がある
- 各アプリが独自の Chromium エンジンを含むため数百 MB 規模になる
- 応答速度の低下、OS 機能との統合不足などの問題が生じる
- 一部の問題は OS ごとの最適化で改善できるが、Electron の構造的利点はそれを積極的には促さない
コーディングエージェントの登場と期待
- 最近の コーディングエージェントは、仕様（spec）とテストに基づいて 言語・プラットフォーム間の実装を自動化する能力を示している
- 理論上は、1つの仕様とテストセットで 各プラットフォームのネイティブアプリを生成できる
- これにより 小規模で集中したチームが 高性能なネイティブアプリを幅広い市場に提供できる可能性が示されている
ClaudeとAnthropicの事例
- Anthropic は Rust ベースの C コンパイラをコーディングエージェントで実装したが、最終段階で限界に突き当たった
- 新機能の追加やバグ修正のたびに既存機能が壊れる問題が繰り返された
- 成果物は印象的だが、実運用には不適切な水準と評価された
- Claude デスクトップアプリも Electron ベースで作られており、遅く、バグが多く、容量の大きいアプリとして言及されている
「最後の10%」の難しさ
- コーディングエージェントは開発の 最初の90%を素早く処理するが、
現実環境での例外処理・保守は依然として複雑で、人手の介入が必要である
- 実際のユーザー環境では 予期しないシナリオが蓄積し、開発は終わらない
- プラットフォームごとに別アプリを作る場合、バグ・サポート範囲が3倍に拡大して保守負担が大きくなる
- Electron は共通ラッパー（wrapper）を通じてこの問題をある程度緩和する
Electronを使い続ける理由
- 仕様ベースの開発が可能でも、最後の10%の開発コストと保守負担は依然として存在する
- エージェント技術の進歩にもかかわらず、Electron の単一コードベースという利点は現実的に有効である
- 現時点では Electron は依然として合理的な選択と評価される
- コーディングエージェントは驚くべき進歩を見せているが、完全な代替手段としてはまだ不十分である
1件のコメント
Hacker News の反応
Claude Code チームの Boris です
以前 Electron を開発していたエンジニアがいたので、ネイティブではない方式で作ることを好んでいました
こうすると Web とデスクトップ間で コード共有 ができ、同じ UI/UX を維持できます
もちろん、すべてはトレードオフの問題なので、将来は変わるかもしれません
スタックを変えなくても性能最適化で解決できそうです。モバイルアプリも同じです
言葉より 行動を見ることが重要だ という教訓になります
それなら Claude に「これをダサくならないようにして」と頼めばいいのでは、と冗談を言っています
AI エージェントが仕様とテストだけで保守まで可能なのか という問いです
とくに Opus 4.6 のようなモデルの限界を考えると、どんな結果になるのか気になります
コードがタダではない理由は明白です
私たちのチームも 6 か月間 Claude をかなり使ってきましたが、バグ率は相変わらずです
AI は万能の解決策ではありません
AI に思考を 外注 すると、システムに対するメンタルマップを失います
それなのに、もう「なぜすべてを AI で書き直さないのか」と言い出すのはおかしいです
Imgur リンク 参照
AI コーディングエージェントは完全にそのレベルではありませんが、速いだけのミス には警戒すべきです
OpenAI のブラウザもリリースから 4 か月経ったのに、まだ macOS 専用です
すでに クロスプラットフォームエンジン の上で動いているのに、拡大が遅いのは疑問です
「Free as in puppy」という表現は気が利いていました
元のタイトルは「If code is free,」で始まっていたそうです
この記事とスレッド全体が、典型的な HN 式の論争パターン に見えます
「AI はダメ」「JavaScript はダメ」「Electron はダメ」という繰り返しの構図です
Electron は事実上 『第4の OS プラットフォーム』 なのに、それを理解できていない開発者が多いです
今のアプリは 継ぎはぎした Web サイトのように見え、スタイルの不一致やバグが多いです
ネイティブ Mac アプリを作るほうがずっと気分がいいです
Electron の利点はありますが、OS ごとの最適化はほとんど行われていません
ひどいネイティブ UI も多く、結局は 人がどうコードを書くか の問題です
Claude が CLI ツールを提供している状況なら、Electron の選択は合理的です
Electron の利点も認めており、選択理由も説明しました
ただ、Mac Studio 64GB RAM でも遅い というのは興味深い事実です
npm 依存関係まで標準で含めるのは 技術的な矜持の欠如 のように見えます
「最高の人材を雇う」というスローガンとも釣り合いません
JavaScript は好きですが、RAM 使用量は異常です
Anthropic は「コードはタダだ」と言ったことはありません
彼らは 生産性向上 を強調しており、実際にコードの大半を LLM で書いています
批判するなら、藁人形論法ではなく 実際の問題点 を指摘すべきです
なぜもっと良い成果物が出てこないのか」という疑問は残ります
Lenny’s Newsletter のインタビュー 参照
この記事はそういう人たちを狙ったもののようです
Felix です。Claude Code Desktop と Claude Cowork の Electron アプリを担当しています
私たちのアプリには Rust、Swift、Go のコードもかなり含まれています
Electron を使う理由と、独自エンジンを配布する理由は
公式ドキュメント に詳しく書いてあります
Electron は単なる ツール にすぎず、必要なら別のものを使うこともできます
CEO が「コーディングはほぼ解決された問題」と言ったのに、なぜこういう結果なのかと聞きたいです
Claude のログイン問題を経験しました
ブラウザが無限ロード状態に陥り、ログインをクリックするとサインアップに飛ばされます
こうした基本機能が不安定なのは、「コーディングの未来」と呼ぶには物足りません
コードは決してタダではありません
結局、どんな形であれ コストを支払う ことになります
AI がコードを全部書くとしても、それを 理解する人 は必要です
マニュアルを読む力がハッカーの強みであり、
自分たちが作った製品の仕組みを理解していない会社は危険です
Claude が Electron を使うのは技術ではなく 文化の問題 だと思います
スタートアップなら Electron は合理的ですが、
大企業なら ネイティブアプリの品質と UX に投資すべきです
自動化されたコーディングが可能でも、なおそうしていないのは
今日の開発文化が「最高のソフトウェアを作ろうとする意志」を失っているからです