Launch HN: Morph (YC S23) – AIによるコード編集を4,500トークン/秒で適用

322日前

概要

MorphはAI生成コードの編集を高速かつ信頼性高く既存ファイルへ適用するモデルを開発。従来のフルファイル書き換えや検索置換に比べ、圧倒的なスピードと正確性を実現。独自のFast Applyモデルと推測デコーディング技術を採用。無料で利用できるライブデモやAPIも提供。今後はインライン編集や次回編集予測機能も展開予定。

Morphの高速AIコード編集モデルとは

Morph はAI生成コードの編集内容を 既存ファイルへ直接・高速適用 するモデルを開発
4,500トークン/秒 超の適用速度を実現するFast Applyモデルを提供
従来の フルファイル書き換え や 検索置換 の課題（遅い・高コスト・エラー多発）を解決
編集は「// ...existing code...」のような 既存行参照形式 で出力
Fast Applyモデル＋推測デコーディング でAIパッチを即時・高信頼で適用
Cursorが先駆的に採用した手法だが、 API提供がなかったためMorphが独自開発
大規模無料枠 あり、誰でも利用可能

利用方法・デモ・ドキュメント

ライブデモ （サインアップ不要）: https://morphllm.com/dashboard
クイックスタートガイド: https://docs.morphllm.com/quickstart
YouTubeデモ動画: https://www.youtube.com/watch?v=LdT8epGHJPk

提供モデルと導入事例

morph-v3-fast: 4,500トークン/秒超の超高速モデル
morph-v3-large: 2,500トークン/秒の大規模モデル
Fast Apply技術 はcreate.xyz、databutton、continue.devなどで採用実績
埋め込み・再ランキング用リトリーバルモデル も提供

今後のロードマップ

Inline Edit Model (Cmd-K): 開発者の作業状態を維持しつつ、超高速インライン編集を実現予定
Morph Tab API: 次回のコード編集やアクションを 500ms未満で予測 するモデル（プライベートベータ中・早期アクセス申請可）
申請フォーム: https://morphllm.com/tab

Morphによる業界への提言

推論速度の向上 はUXにおいて精度向上より重要という見解
フルファイル書き換え は旧世代、 Fast Apply編集 が速度・コスト・信頼性で優位
ベンチマークが飽和する中、 タスク特化型・推論最適化モデル の重要性が増加
Frontierモデルは複雑なタスクへ、単純タスクは特化型モデルが担う時代への移行

コーディングエージェントへのフィードバック募集

開発者体験や意見、アイディアの共有を歓迎
コーディングエージェント活用事例や要望の募集

Hackerたちの意見

生の推論速度は、開発者のUXにとって、段階的な精度向上よりも重要だと思う？賛成？反対？ちょっと話題を作ろうとしてるのは分かるけど、正直言ってこれは間違ってると思う。人は、コーディングの質を重視するから、もっと大きな（または推論する）モデルを使いたがるんだよね。5kトークンの大きな編集をする場合でも、編集時間の200-300msの違いなんて大したことじゃない。編集速度は確実に開発者のUXのボトルネックじゃなくて、質が重要なんだ。200msのために質を犠牲にする開発者には、ちょっと共感できないな。1-2人のエージェントを並行して使ってると、ほとんどの場合、他のエージェントのコードをレビューしてる間に編集はもう適用されてるし。でも、これが俺だけかもしれないけど。質について言えば、どうやって測ってるの？ベンチマークはあるの？速いモデルと大きなモデルのエラー率の違いはどれくらい？

└

マーケティングの言葉からは、質に自信がなくて量をアピールしたいみたいに感じるね。でも、俺も同じ立場だから、4500トークン/秒の使い捨ての回答を1時間かけてキュレーションするより、正しい答えを10トークン/秒で得られる方が嬉しいよ。ベンチマークのパフォーマンスは、遅延よりも100倍重要だと思う。もしこれらの「ホットテイク」がMorphの開発哲学にまで及ぶなら、ユーザーじゃなくてよかったと思う。

└

それは状況によると思う。開発者がフロー状態を保つために測るべき実際の要素があるからね。多くのエラーや遅延がこれを壊す。簡潔に言うと、はい、精度が最優先だよ。質は主に2つの方法で測定される：1) エンドツーエンド：ユーザーのクエリからタスクの解決まで。これは実際のタスク完了の質問に答えるスタイルのベンチマーク。2) 質の適用：構文の正確さ、文字の差異など。大きなモデルと速いモデルのエラー率は約2%だよ。もし非常に複雑なコード編集やマイナーな言語を扱っているなら、大きなモデルがより良い選択だね。タスクに最適なモデルにルーティングする自動オプションもあるよ。

└

推論が約50%速くなることは、単一桁の精度向上よりも、俺のワークフローにとってずっと価値があると感じてる。どうせ変更が正しいか確認しなきゃならないなら、より早く多くの反復を行える方が、段階的な精度向上よりもずっと良い気がする。ただし、明確な転換点はあるよ。精度の向上が高すぎて、作業をあまり注意深くチェックしなくても良くなるなら、推論速度の利点はほぼゼロになるね。

└

スローはスムーズで、スムーズは速い。

└

私の理解では、これは±300msじゃなくて、300ms対10秒みたいな感じだよ。それって大きな違いだよね。個人的には、こういう大きなモデルを待つ時間が制約になってると思う。これって、比較的簡単なタスクに対してリソースの無駄遣いかもしれないし。（LLMの一般的な機能近似と比べて）でも、正直言って、賢く編集を適用するタスクは伝統的なコーディングタスクの範疇に入ると思うんだけど、何がそんなに難しいの？賢いdiffアルゴリズムでできないの？

└

速いモデルを使った後に遅いモデルを使うのは耐えられないって認めざるを得ない。質と速度が線形に関係しているかはわからないけど。

└

コーディングにはOpusを使わないで、Sonnetの方が好きだな。多くのタスクは反復や監視があった方がうまくいくし、Sonnetがそれを可能にしてくれる。

└

レビュー時間がボトルネックになってるみたいだね。今、コーディングエージェントの出力をレビューするのをもっと速くするためのものに取り組んでるんだ。もし時間があれば、あなたのワークフローについてインタビューしたいな。ここに返信するか、プロフィールにある連絡先を見つけてね。-- ジミー・コッペル博士

└

完全に同意するよ。AIモデルから提案された変更セットを受け取ったら、まずは慎重にレビューするのが最初のステップだよね。大抵の場合、特定のトークンや文脈をスキップしちゃうから、コードが重複することが多いんだ。それをユーザーがプロンプトに含めなかった場合もあるし。変更を一括適用するのは、デバッグがさらに難しくなるコードを作るだけだし、そんな大量のコードインジェクションは、思ってるより早くコードを壊しちゃうよ。B、サム

最後にMorphを見たとき、OpenRouterにはまだ載ってなかったよね。今は変わったみたいだけど、古いモデルしか載ってないみたい。もっとアクティブになる予定はあるの？それと、あなたの速い適用モデルとRelaceやCerebras経由のLlamaなど他のモデルとの比較ベンチマークはある？特に出力の精度に興味があるんだ。

└

現在リストされているv2モデルはmorph-v3-largeを指してるよ。v3-largeとv3-fastをリストするために彼らと協力してるところだ。

└

ハッカーニュースの力だね！新しいモデルがそこにリストされてるよ。

これ、Relaceと比べてどうなの？RelaceもYCの会社だよね？機能がすごく似てるみたいだし。

└

いい質問だね。同じ顧客（create.xyz、continue.dev）もリストに載ってるよ。

ちょっと確認したいんだけど、Morphは他のLLMの出力を統合するためのツールであって、LLMそのものではないの？4500トークン/秒を生成するわけじゃなくて、4500トークン/秒を編集できるってこと？

└

正解だけど、MorphもLLMなんだよね。実際には、基本的に大きなLLMが小さなLLMをツールとして使ってる感じ。

これめっちゃいいね。MicrosoftのCopilot使ってみたけど、すごく使いづらい。特に編集するときがね。モデルをトレーニングするリソースがあると思うんだけど…お願い、ドキュメントにシステムプロンプトを載せて、LLMが自分たちのモデルに最適なdiffフォーマットを生成できるようにしてほしい。LLMはアップグレードのたびにdiffの表示方法が変わるから、どのフォーマットがベストかを推測したくないんだ。編集: プライバシーポリシーを明確にしてほしい。もし私の解釈が合っていれば、有料ユーザーのデータは保持されてトレーニングに使われるの？電話をかけずにサービスを利用して、私のデータがトレーニングに使われない方法はあるの？ 4.1 サービスデータの使用サブスクリプションの種類によって異なる: 無料プラン: 提出したコードデータをモデルのトレーニング、サービスの改善、新機能の開発に使用することがあります。エンジニアプラン: 提出したコードデータをモデルのトレーニング、サービスの改善、新機能の開発に使用することがありますが、サービス契約の機密保持条項に従います。エンタープライズプラン: 提出したコードデータは、即時のリクエスト処理以外の目的には使用しません。あなたのコードデータは、モデルのトレーニングやサービス改善には決して使われません。

└

完了！そうだ、ZDRオプションもあるから、info@morphllm.comにメールして有効にしてね。MorphはOpenRouter経由で常にデータ保持ゼロだよ。

└

「私のデータで訓練しないで」っていうの、ほんとバカみたい。これらのモデルがどうやって作られたか知ってる？コードで訓練されたんだよ。他の人のコードで訓練されたツールを使いたいのに、自分のデータでは使いたくないなんて、自己中心的だし、共通の悲劇だよね。これがモデルを良くする方法なんだから。

完全に壊れてるみたい。https://morphllm.com/dashboard/playground/apply の提供されたHTMLの例をそのまま使ったんだけど、何も編集せずに「適用」を押したら、モデルがCSSをたくさん追加しちゃった。更新指示には全然書いてなかったのに。それに、連絡先のセクションも追加されてて、これもデモの更新指示には載ってなかったんだよね。

└

いい指摘だね。HTMLの例は、コメントアウトを忘れてたハードコーディングのスニペットを使ってた。修正したよ。

本当に印象的だね。私たちの内部AIコーディングシステムのために、こういうソリューションを探してるんだけど、https://huggingface.co/osmosis-ai/Osmosis-Apply-1.7B と比べてどうなの？あなたのモデルはオープンソースじゃないってことだよね？

└

両方試してみるべきだよ！大きな違いは、私たちのモデルはかなり速くて正確だってこと。

1- スピードが知性だってのには同意するけど、精度を下げてスピードを上げて、より良い結果が得られるって言ってるのは納得できないな。2- 混乱してる。私が使ったClaude CodeとNeovimのプラグインは、どちらも編集や差分を扱ってるんだけど、実際に全ファイルを書き換えてるって言ってるの？ 3- 「簡単なタスク」って、モデルを訓練するためのものじゃないの？もしそうなら、たくさんの簡単なタスクを解決してるの？それともカスタム訓練を提供してるの？ > もう遅い全ファイルの書き換えや脆弱な検索・置換ハックはなし。要するに、LLMはすでに超高速なんだ。前にコメントしたけど、平均的なスピードで数ヶ月でChromeの全コードベースを書けると思う。ボトルネックはスピードじゃなくて、精度なんだよね；これはあくまで私の意見だけど。+: https://omarabid.com/claude-magic

└

もちろん、正確さが最優先だよね。どんなエラーもフロー状態を壊しちゃうし、めちゃくちゃ邪魔になるから。Claude Codeは検索と置換をするけど、検索と置換の失敗率はかなり高い（11%以上）んだ。でもClaudeはそれを自己修正できるんだよね。Fast Applyは検索と置換よりも正確だし、10kトークン以下のファイルのフルファイル書き換えはかなりうまくいくことが多いよ。98%以上の成功率だけど、めっちゃ高くて遅いのが難点。Fast Applyはスピードと正確さのバランスが取れてるから、ずっといい選択肢だね。

Gemini Flashより高いけど、実際にかなり良いコードを書けるんだよね（単に差分を適用するだけじゃなくて）。Fast AI編集アプリケーションは確かに素晴らしいけど、結構高いよ。Morph v3 Fast: 入力: $1.20 / Mトークン、出力: $2.70 / Mトークン。Gemini 2.5 Flash: $0.30 / Mトークン、出力: $2.50 / Mトークン（出典: OpenRouter）

Appleの新しいモデルも同じことしてるんじゃない？ https://huggingface.co/apple/DiffuCoder-7B-cpGRPO

ハクソク