注意: 本記事はドキュメント・公開情報をもとにした評価記事です。コード例はシミュレーションです。
3行要約
- 次の文字ではなく「次の編集場所」を予測するNext Edit Prediction（NEP）特化型ツール
- 従来のオートコンプリートでは不可能だった「別行へのジャンプと修正」をワンタップで完結させる
- 大規模リファクタリングを行うシニアエンジニアには最適だが、定型文を打つだけの初学者には不要
📦 この記事に関連する商品
Logicool MX Master 3SMercuryで移動は減りますが、精密なコード選択には高性能なマウスが不可欠です
※アフィリエイトリンクを含みます
結論から: このツールは「買い」か
結論から言うと、VS CodeやCursorの標準補完に「もどかしさ」を感じているプロ級のエンジニアなら、今すぐ導入すべきです。 評価は星4つ（★★★★☆）。 GitHub Copilotが「次に打つべき文字」を教えてくれるツールだとしたら、Mercury Edit 2は「次に直すべき場所」へ連れて行ってくれるツールです。 特に、関数のシグネチャを変えた後に、その呼び出し元を一つずつ修正して回るような「作業」を、AIが先回りして位置指定まで含めて提案してくれる体験は、一度味わうと戻れません。 ただし、月額料金が発生する点と、常にエディタの挙動を監視されることによるリソース消費を許容できることが前提になります。
このツールが解決する問題
これまでのAIコーディング支援は、カーソルがある場所の「続き」を書くことに特化していました。 しかし、実際のエンジニアの業務時間の8割は、新規作成ではなく「既存コードの修正」です。 変数名を一つ変えたら、それに関連する3箇所のロジックを直し、最後にテストコードを修正する。 この「ファイル内を上下にスクロールして、該当箇所を探して、カーソルを合わせて、修正する」という物理的な移動コストが、開発のコンテキストスイッチを発生させていました。
Mercury Edit 2は、この「移動」そのものをAIに肩代わりさせます。 独自のNext Edit Prediction（NEP）エンジンにより、直前の編集内容から「次にユーザーが編集したくなるであろう行と内容」をセットで予測。 ユーザーはTabキーを押すだけで、次の編集ポイントへワープし、同時に修正案を適用できます。 これは「入力支援」ではなく「思考のショートカット」であり、マウスや矢印キーに触れる回数を劇的に減らす解決策です。
実際の使い方
インストール
基本的にはVS Codeの拡張機能として提供されています。ドキュメントによれば、以下の手順でセットアップが完了します。
- VS Codeの拡張機能マーケットプレイスで「Mercury Edit」を検索
- インストール後、右下に現れるアイコンからログイン
- 独自の推論エンジンを使用するため、初期化に数十秒待機
前提条件として、Node.js 18以降が推奨されています。また、推論をクラウドで行うため、インターネット接続は必須です。
基本的な使用例
Mercury Edit 2が本領を発揮するのは、データ構造の変更時です。例えば、以下のようなPythonコードがあるとします。
# settings.json でのMercury設定例（シミュレーション）
{
"mercury.edit.prediction.enabled": true,
"mercury.edit.context_window": 4096,
"mercury.edit.model_size": "large"
}
実際の編集フローはこうなります。
# 1. まずここで関数の引数を変更する
def fetch_user_data(user_id: int, include_metadata: bool = False): # ここに 'include_metadata' を追加
...
# 2. すると、Mercuryが「次にここを直すでしょ？」と数行下の呼び出し箇所をサジェストする
# カーソルを移動させていないのに、呼び出し側のコードがグレーアウトして表示される
user = fetch_user_data(123)
# 3. Tabを押すと、カーソルが自動でジャンプし、コードが以下に書き換わる
user = fetch_user_data(123, include_metadata=True)
この「ジャンプ＋追記」がシームレスに行われるのが特徴です。
応用: 実務で使うなら
実務、特に大規模なReactコンポーネントのProps変更や、APIのレスポンス形式変更に伴う型定義の修正で威力を発揮します。 例えば、TypeScriptでInterfaceを変更した際、それを利用している複数の関数内でのプロパティ参照を、Mercuryは次々と予測して提示してくれます。
「1箇所直す→エラーが出る→該当箇所へ移動→直す」というリアクティブな修正から、「1箇所直す→Mercuryが次を提案→Tab→Tab→Tab」というプロアクティブな修正に変わります。 私のようにRTX 4090を積んだマシンでローカルLLMを動かしている人間から見ても、Mercuryの予測モデルの軽量さとレスポンスの速さは驚異的です。 推論サーバーとの通信を含めても、編集の提案まで0.5秒を切る速度で反応します。
強みと弱み
強み:
- 物理的な移動が減る: カーソルキーやマウスで「修正場所を探す」時間がほぼゼロになります。
- コンテキストの理解度が深い: 直近の5〜10件の編集履歴を常にベクター化して保持しているため、修正の意図を正確に汲み取ります。
- 既存ツールとの共存: Copilotがコードを書いている最中に、Mercuryが「次の行」を予測するといった併用が可能です。
弱み:
- 予測が外れるとストレス: 複雑なロジックを組んでいる最中に、見当違いな場所にジャンプさせようとされるとリズムが崩れます。
- 英語ドキュメントのみ: 設定項目やトラブルシューティングはすべて英語です。
- プライバシーポリシー: 編集履歴（エディットグラフ）を推論のために送信する必要があるため、機密性の極めて高いプロジェクトでは導入に慎重な判断が求められます。
代替ツールとの比較
| 項目 | Mercury Edit 2 | Cursor (Composer) | GitHub Copilot |
|---|---|---|---|
| 主要機能 | 次の編集箇所の予測移動 | 対話型コード生成・編集 | 行単位の補完・チャット |
| 予測の質 | 編集フローに特化 | 全体構造に強い | 汎用的だが移動は弱い |
| 速度 | 非常に高速(0.5s以内) | 普通(生成待ちがある) | 高速 |
| 最適な層 | 修正・改善が多いプロ | 新規開発メインの層 | 全エンジニア |
CursorのComposer機能も複数箇所の修正を得意としますが、あちらは「指示を出して待つ」スタイルです。対してMercuryは「いつものように書いていると、道筋が見える」という、よりエディタの延長線上にある体験を提供します。
私の評価
私はこのツールを、現在のメイン環境であるVS Codeに常駐させています。 星4つの理由は、これが「エンジニアの認知負荷を物理的に下げる唯一無二のツール」だからです。 一方で、星5つに届かないのは、大規模なファイル（3000行超）において、予測精度が若干不安定になる場面が見受けられたからです。
万人におすすめできるわけではありません。 しかし、1日に数千行のコードを読み書きし、常に複数のファイルを行ったり来たりしている中級以上のエンジニアにとって、この「移動の自動化」は年間で数十時間の節約に直結します。 「コードを書くスピード」を上げたいのではなく、「開発のテンポを維持したい」と願うエンジニアには、最高の武器になるはずです。
よくある質問
Q1: GitHub Copilotと一緒に使っても競合しませんか？
基本的には競合しません。Copilotはインラインのコード補完（ゴーストテキスト）を担当し、Mercuryは編集箇所のジャンプと修正提案を担当します。表示が重なった場合は、Mercuryの設定で提案の優先度を調整可能です。
Q2: 会社で導入する場合のセキュリティリスクは？
コードのコンテキストと編集履歴がサーバーに送られます。エンタープライズ向けのプライベートデプロイ版や、データの学習利用をオフにする設定があるか、導入前に公式の最新ドキュメントを確認することをおすすめします。
Q3: 日本語のコメントや変数名でも予測は機能しますか？
はい、試した限りでは日本語が含まれていても問題なく機能します。予測モデル自体はコードの構造と編集パターンを重視しているため、言語依存性は比較的低いです。ただし、複雑な日本語の文脈を汲み取った修正案は、英語に比べると精度が落ちる印象です。
