1 ポイント 投稿者 GN⁺ 2025-07-09 | 1件のコメント | WhatsAppで共有
  • AIコーディングツールで生成された変更を既存ファイルに貼り付ける工程がボトルネックになる中、MorphはFast Applyモデルでファイル全体の再書き換えや脆弱な検索・置換を置き換えようとしている
  • エージェントは未変更の行を//...existing code...のように残したゆるい編集出力を作成し、Morphが元のファイルを基準に実際の変更を適用する
  • 提供モデルはmorph-v3-fast4,500+ tok/secmorph-v3-large2,500+ tok/secで、create.xyz、databutton、continue.devなどで使われている
  • 検索向けには埋め込み・リランキングモデルを提供し、次の製品としてCmd-Kスタイルのインライン編集モデルとsub-500ms遅延のMorph Tab APIを準備中
  • Cursorが先に切り開いた方式だがAPIとして公開されておらず、Morphは開発者が直接組み込めるAPIと大きな無料ティアを前面に出している

AIコード編集適用のボトルネック

  • AIが作成したコード変更を既存コードへ安定して挿入する工程が、Morphの中核となる問題意識である
    • ファイル全体の再書き換えは遅く、コストも大きくなりうる
    • 検索・置換方式は小さな違いでも壊れやすく、エラーにつながる可能性がある
  • Morphはエージェントが変更内容をゆるく出力するよう設計している
    • 変更していない既存行は// ...existing code...のように参照する
    • 元のファイルとゆるいパッチを入力として受け取り、Fast Applyモデルと推測デコーディングで実際の編集を適用する
  • 目標は、AIパッチをより高速で安定し、本番環境で使いやすい形にすること
  • 関連資料は以下で確認できる

モデルラインアップと次の製品

  • Morphは2種類のFast Applyモデルを提供している
    • morph-v3-fast: 4,500+ tok/sec
    • morph-v3-large: 2,500+ tok/sec
  • これらのモデルはcreate.xyz、databutton、continue.devなどでFast Applyを動かすために使われている
  • コード検索のために、埋め込みとリランキング用の検索モデルもあわせて提供している
  • 次の機能は編集フローをさらに短くする方向に焦点を当てている
    • Inline Edit Model, Cmd-K: 開発フローを中断しない非常に高速なインライン編集
    • Morph Tab API: 次のコード編集やアクションを予測するモデルで、sub-500ms遅延を目標としており、現在は非公開ベータ
  • Morphは、開発者体験において生の推論速度が重要であり、ファイル全体の再書き換えよりFast Apply編集のほうが速度・コスト・信頼性の面で優れていると見ている
  • 狭いタスクのベンチマークが99%以上で飽和すると、複雑性は単一のfrontierモデルよりも特化した推論最適化モデルへ移るという見方をしている

1件のコメント

 
GN⁺ 2025-07-09
Hacker Newsのコメント
  • 開発者体験では、生の推論速度より正確さのほうが重要だという主張にはあまり同意できない。ユーザーがはるかに遅い tok/sec を受け入れてでもより大きなモデルを好むのは、結局コード品質が第一の基準だからだ。大きなコード修正(例: 5,000 トークン)では 200〜300ms 程度の遅延はあまり意味のある数値ではない。編集速度そのものは、ボトルネックというより品質のほうが大きな要素だ。コード変更で 200ms 短縮することが品質より優先されるというのは、まったく共感できない。1〜2 個のエージェントを並列で使えば、コードをレビューしている間にすでに大半の修正は終わっている。品質の測定基準が気になるし、高速モデルと大規模モデルの間でエラー率の差がどの程度あるのか知りたい

    • 推論速度が約 50% 速くなるなら、正確さが一桁%改善することよりも、自分のワークフローにとってはるかに大きな価値があると感じる。どうせ変更点は自分で確認しなければならないので、反復サイクルが速いほうがよく感じられる。ただし、正確さが十分高くて、検証を減らしたり頻度を下げたりできるレベルなら、このときは推論速度の利点はほとんど意味がなくなる

    • 完全に同意する。AI モデルがコード変更を提案したあと、最初にやるべきことは必ずその成果物を丁寧にレビューすることだ。ほとんどの場合、プロンプトに欠けたコンテキストや特定のトークンのせいで、コードが重複したり的外れに生成されたりする。変更を一括適用するとデバッグはさらに難しくなり、この種の大量コード挿入が積み重なるほど、コードは思ったより早く壊れる可能性が高い

    • 私の理解では、単に ±300ms 程度の話ではなく、300ms と 10 秒のような非常に大きな差がある。こうした大規模モデルの応答待ちは、少なくとも自分にとっては明らかな制約だ。しかも、このような単純作業にはリソースが不必要に消費されている感じもある。実際、コード変更を賢く適用する作業は、既存のプログラミング環境でも十分扱える領域だと思う。こういうものが本当に LLM を必要とするほど難しい作業なのか気になる

    • あなたにとってはレビュー時間がボトルネックのように感じられるんだと思う。私は今、誰かがコードエージェントの成果物をずっと速くレビューできるよう支援する機能を作っている。もし時間があれば、あなたのワークフローについてもう少し詳しくインタビューしたい。コメントか、私のプロフィールにある連絡先から連絡してもらえるとうれしい

    • 重要なのは、開発者が没入状態(flow)を維持することだと思う。エラーも遅延も、どちらも没入を断ち切る要因になる。結論として、コーディングでは品質(正確性)が最も重要な要素だ。品質評価には大きく 2 つの基準を使っている。第一に、ユーザーのクエリからタスク完了までの全体ラインで評価するエンドツーエンド性能(aider スタイルの bench)。第二に、適用精度(文法/構文の問題、文字単位の diff など)。大規模モデルと高速モデルのエラー率差はおよそ 2% 前後だ。複雑な、あるいは難しい言語なら大規模モデルのほうが適しており、タスクに適したモデルへ自動でルーティングするオプションもある

  • microsoft copilot を使ってみたが、特にコード適用の段階であまりにも遅く不便だと感じた。リソースが豊富なところで、モデルをまともに訓練できていないのが不思議だ。要望: どの diff フォーマットを LLM に生成させるのが最適か、システムプロンプトを公式ドキュメントに入れてほしい。LLM のアップグレードのたびに diff フォーマットが変わることが多く、どのフォーマットが最善なのか毎回推測しなければならず不便だ。加えて、プライバシーポリシーがはっきり理解できないのだが、私の解釈どおりだと有料ユーザーでもデータが保存/学習されるという意味なのか気になる。(電話なしで)サービスに料金だけ支払って、データを学習に使われないようにする方法が知りたい。Morph Privacy Policy を参照した

    • ZDR(Zero Data Retention) オプションも可能だ。info@morphllm.com にメールを送ってもらえれば設定する。Morph を OpenRouter 経由で使う場合は常に Zero Data Retention だ

    • 「自分のデータでモデルを訓練するな」という要求は少し滑稽な主張だ。こうしたモデルが作られた原理そのものが、他人のコードで訓練した結果なのだから。こういうツールを使いながら、自分のデータは訓練に使うなと言うのは、実際のところ利己的な考えで、集団利益のジレンマに近い。こうしてモデルはより良くなっていくのだから

  • 公式デモで提供された HTML 例を https://morphllm.com/dashboard/playground/apply でそのまま適用してみたところ、何の変更も要求していないのに CSS が追加され、contact セクションまでできた。そうした内容は更新指示に含まれていなかった

    • よく見つけた。HTML 例でハードコードされたスニペットがコメント解除されていない状態だった。今は修正済みだ
  • コスト面で見ると、Morph は Gemini Flash よりかなり高いという印象だ。Gemini Flash でもかなり良いコード生成ができるし、高速に編集を反映する AI も良いが、価格帯は気軽ではない。たとえば Morph v3 fast は入力 $1.20/M トークン、出力 $2.70/M トークンだが、Gemini 2.5 Flash は入力 $0.30/M トークン、出力 $2.50/M トークンだ(参照: OpenRouter)

    • それはデータ 0 保持オプション基準の料金だ。Morph 公式ウェブサイトの価格は入力 $0.80 / 1M トークン、出力 $1.20 / 1M トークンだ。大量利用/予約インスタンスには割引制度もある
  • 念のため確認したいのだが、Morph は他の LLM の結果を「適用」するツールであって、独自の LLM ではないのだろうか。毎秒 4,500 トークンを生成するのではなく、適用基準という理解で合っているのか気になる

    • そのとおり。ただし Morph 自体も LLM だ。実際には、大規模 LLM が小規模 LLM をツールコールのように活用する構造になっている
  • とても印象的だ。社内 AI コーディングシステム向けにこうしたソリューションを探している立場なのだが、オープンソースの Osmosis Apply 1.7B のようなプロジェクトと比べると何が違うのか気になる。Morph モデルがオープンソース/オープンウェイトではない前提だ

    • 両方を実際に試してみるのがよいと思う! 私たちのモデルは速度と正確性の両面でかなり優位だ
  • 以前は Morph を OpenRouter で見かけなかったが、今は載っているようだ。ただ、登録されているモデルは旧バージョンのように見える。今後もっと積極的にサポートする予定はあるのか。それと、fast apply モデルが Relace や Llama/Cerebras と比べて、性能(特に正確性)でどうかというベンチマーク結果も気になる

    • Hacker News の力はすごい! 今ではそちらにも新しいモデルが登録された

    • 現在 v2 モデルは morph-v3-large を指している。まもなく v3-large と v3-fast も追加される予定だ

  • Relace との比較が気になる。どちらも YC 出身の会社で、機能もかなり似ているように見える Relace

    • いい質問だ。顧客企業の一覧も(create.xyz, continue.dev)同じように表示されている
  • ChatGPT と VSCode の間をつなぐブリッジになるブラウザ拡張があって、その間に Morph(または Claude)を挟めば、agentic coding を Web UI からすぐ活用できて本当に良さそうだ。API ではなく Web インターフェースを使うアイデアだ

    • MCP を使えばこの目的を達成できる。まもなくリリース予定だ
  • AI が賢く rebase+merge を自動化してくれる機能があれば、開発速度は飛躍的に上がると思う。複数ユーザーのコード変更を AI が意図まで理解して自動でマージしてくれたら、本当に生産性向上になる

    • Claude Code を使えば、すでにその機能を使える。単に「別のブランチをマージして競合を解決して」と頼めばいい

    • マージコンフリクトの状況にどれくらいの頻度で遭遇するのか気になる