oh-my-pi 徹底解説:IDE を組み込んだコーディングエージェントと、編集フォーマットがモデルの成否を分ける理由

位置づけ:IDE を組み込んだコーディングエージェント

oh-my-pi(コマンド名は omp)は、Stencil Labs の can1357 が保守するプロジェクトです。Mario Zechner 氏のオープンソース Pi のフォークにあたります。自己紹介は一文だけです。「IDE を組み込んだコーディングエージェント」。README が示す規模は、60 以上のモデルプロバイダ、31 の組み込みツール、14 種の LSP 操作、28 種の DAP 操作、そして約 8 万行の Rust コアです。これらはプロジェクト自身の数字であり、一つずつ独立に検証したわけではありません。それでも狙いははっきりしています。omp は「モデルにターミナルを付けただけ」の道具ではなく、開発者が IDE で当たり前に使う機能一式をエージェントに与えようとしています。

技術スタックは TypeScript、Rust、Bun ランタイムです。Bun 1.3.14 以上が必要で、macOS、Linux、Windows で動きます。README には運用方針の試行も書かれています。プルリクエストは当面、誰にでも開放されます。以前は vouch(推薦)が必要でしたが、結果次第で復活する可能性があります。

コアアーキテクチャ:Pi の上に重なる三つの層

README からは三つの層が読み取れます。第一は Pi から受け継いだエージェントループとターミナル UI です。第二は omp が「バッテリー」と呼ぶ追加分で、多数の組み込みツール、モデルごとの適合、プロンプト調整を含みます。第三は IDE に相当する言語サービス層、つまり LSP と DAP です。

LSP(Language Server Protocol)は、定義へのジャンプ、参照検索、診断、リネームなどを提供します。README の言葉では「IDE が知っていることは、エージェントも知っている」。14 種の LSP 操作があれば、エージェントはシンボルの関係を grep で推測せず、言語サーバに直接尋ねられます。DAP(Debug Adapter Protocol)はエージェントではまだ珍しい機能です。28 種の操作により、ブレークポイントの設定、ステップ実行、変数の確認ができます。ログを足して再実行するという粗い手順が、本物のデバッグセッションに置き換わります。自動化されたエージェントにとって、この二つのプロトコルはテキストエディタを開発環境に引き上げる鍵です。

性能が重要な部分は Rust コアが担います。README は grep を「西部で最速」と表現し、検索は即座に返ると述べています。実装の詳細や検索ベンチマークは README にないため、ここでは推測しません。

内部の仕組み:ボトルネックは編集フォーマット

omp の中心にある主張は、品質を決めるのはモデルだけでなくハーネス(周辺の枠組み)でもある、というものです。作者は 2026 年 2 月 12 日に「The Harness Problem」という記事を公開し、README からリンクしています。要点は、同じモデルでもハーネスが違えば性能が大きく変わり、中でも編集フォーマットの影響が最も大きい、ということです。 モデルが誤った形の diff を出すと、ツールは拒否します。するとエージェントはリトライのループに入ります。リトライはトークンを浪費し、コンテキストを汚します。omp はモデルごとにツールとプロンプトを調整し、編集が最初の試行で成功するようにしています。README の表には四つの例があります。 - Grok Code Fast 1:通過率が 6.7% から 68.3% へ、約 10 倍。作者は、編集フォーマットがモデルを「食い潰す」ことをやめたためだと説明しています。

• Gemini 3 Flash:str_replace より 5 ポイント高い。作者は、Google 自身の最良の試みを上回ったと述べています。
• Grok 4 Fast:出力トークンが 61% 減少。不正な diff によるリトライループが消えたためです。
• MiniMax:通過率が 2.1 倍。重みもプロンプトも同じです。

注意点があります。これらは作者自身が報告した数字です。テストセット、サンプル数、比較条件は README の表ではなくブログ記事側にあります。確定した結果ではなく、確認する価値のある手がかりとして扱うのが安全です。ただ、現象そのものは納得できます。編集ツールの設計が、同じモデルの使いやすさを大きく左右するのです。 README には他にも設計方針があります。`read` はファイル全体を吐き出さず、要約したスニペットを返します。デフォルト値とセレクタの命中率も調整されています。`prompts` はモデルごとに繰り返し調整されています。

ツール呼び出し付きのコード実行

README が最初に紹介する機能は、ツール呼び出し付きのコード実行です。多くのハーネスは Python サンドボックスを渡して終わりです。omp は永続的な Python カーネルと Bun ワーカーの両方を動かします。どちらのカーネルも、ループバックブリッジを通じて、エージェント自身のツール(read、search、task など)を呼び返せます。

README の例では、エージェントが Python の中で tool.read を使って CSV を読み込み、JavaScript からグラフを描き、同じセルを一度も離れません。利点は明快です。中間データはカーネル内に残り、各ステップでモデルのコンテキストに戻す必要がありません。大きなファイルや多段の分析では、コンテキストを節約でき、人がノートブックで作業する流れにも近くなります。リスクも同じ場所にあります。コード実行とツールのコールバックは攻撃面を広げるため、企業が広く使う前に権限の境界を確認すべきです。

インストールとエコシステム

導入方法は幅広いです。macOS と Linux 向けの curl ワンライナー、Homebrew、Bun のグローバルインストール(README が推奨)、Nix、Windows の PowerShell、mise によるバージョン固定があります。Nix 利用者は packages、overlays、nixosModules、homeManagerModules を含む flake を使えます。Home Manager の設定で omp を導入し、`settings.startup.quiet = true` のように設定を宣言的に管理できます。Alpine では、事前ビルドの musl バイナリが libstdc++ と libgcc を動的リンクするため、先にそれらを入れる必要があります。

シェル補完は omp 自身が bash、zsh、fish 向けに生成します。元になるのは実行中のコマンドとフラグのメタデータなので、実際の CLI とずれません。`--model`、`--smol`、`--slow`、`--plan` のモデル名は同梱のモデルカタログから補完され、`--resume` はディスク上のセッションから補完されます。フラグ名からは、タスクの段階ごとに別のモデルを使えることがうかがえますが、正確なルーティング規則は公式ドキュメントで確認してください。

開発者と企業への影響

個人の開発者にとっての魅力は、箱から出してすぐ使え、しかも深いところまで開かれていることです。60 以上のプロバイダに対応しているため、モデルの切り替えコストは低く、複数ベンダーを使い分けるチームには、モデルごとの調整が特に意味を持ちます。

企業にとっては、Nix と Home Manager の対応やバージョン固定のインストールが、再現可能な環境管理に役立ちます。LSP と DAP の統合により、チームが既に持つ言語サービスの設定をエージェントが再利用できます。

限界と今後

第一に、性能の数字の多くは自己報告で、第三者による再現がありません。第二に、31 のツール、二つのコードカーネル、LSP と DAP は表面積が大きく、学習コストと安全性レビューのコストが無視できません。第三に、Pi のフォークである以上、上流への追従という長期的な保守負担があります。第四に、PR の方針はまだ試行中で、コミュニティの運営方針は変わる可能性があります。

今後の方向としては、モデルごとの調整の拡大、デバッグ機能の深化、権限制御の強化が考えられます。実務的な助言はこうです。まず「The Harness Problem」を読み、次に普段使うモデルで自分のコードベース上に omp を走らせ、各パーセンテージを自分のタスクで確かめてください。