ターミナルで動くコーディングエージェントを試したことがある人なら、「LSPの補完は出るのにエージェントはそれを知らない」という場面に一度はぶつかったことがあるのではないでしょうか。エディタが持っている情報と、エージェントが持っている情報が別々のまま動いている、あの微妙なすれ違い感です。oh-my-pi（omp）は、そこをど真ん中から攻めているツールです。60以上のLLMプロバイダー、31本の組み込みツール、約8万行のRustコアを積みながら、MITライセンスで公開されています。この記事では、機能の紹介だけでなく、設計のどこが上手くて、どこに目を向けると評価しやすいかを一緒に見ていきます。
どんなツールか
omp（oh-my-pi）は、ターミナルで動作するコーディングエージェントです。Mario Zechner氏のPiというプロジェクトをフォーク元に持ちつつ、can1357氏が大幅に拡張した形で公開されています。TypeScriptとRustのハイブリッド構成で、ランタイムにはBunを使っており、macOS・Linux・Windowsのいずれでも同じバイナリが動きます。
想定しているユーザーは、毎日エディタとターミナルを行き来しながら開発しているエンジニアです。「エージェントに頼んでいる間も手元の環境と整合性が取れているか」を気にする人、つまり補完やリファクタリングの正確さをある程度の基準として持っている人に向いています。使い始めはcurl -fsSL https://omp.sh/install | sh一行で済み、HomebrewやBun、Nix経由のインストールにも対応しています。Nix向けにはHome Managerモジュールまで用意されていて、設定をNixで宣言的に管理することもできます。
設計でここが上手い
LSPとDAPをエージェントの「眼」にする
ほとんどのコーディングエージェントは、ファイルを読んでテキストを書くだけです。ompはそこに14種類のLSP操作と28種類のDAP操作を接続しています。「rename」を依頼するとworkspace/willRenameFilesを通るので、バレルファイルや再エクスポートが連動して更新されます。テキスト上の書き換えではなく、IDEが実際に実行するリネーム処理を呼んでいる、という意味の違いが大きいです。デバッグも同様で、lldb・dlv・debugpyを通じてプロセスにアタッチし、フレームを読み、変数を評価します。print文を埋め込む代わりに、本物のデバッガを動かすということです。エージェントが「ソースを読む」段階と「動いている状態を観察する」段階の両方を同じツール面で扱えるため、人間がデバッガとエディタを行き来するのと近い流れで仕事を進められます。
ripgrepとbashをプロセス内に組み込む
ほかのエージェントはrg、grep、findをサブプロセスとして呼び出します。ompはripgrepのソースコードをプロセス内にリンクしており、fork-execのコストがゼロです。さらにbrushというbashクローンを組み込みで持ち、ls・sed・sort・xargs・jqを含む58のコマンドをビルトインとして実行します。Windowsでbashが存在しない環境でも同じ動作になるのは、このアーキテクチャの直接の結果です。外部バイナリへの依存をコアの設計から排除していることが、マルチプラットフォーム対応の実質を支えています。
Time-traveling stream rulesによるコンテキスト節約
ルールの扱い方にも工夫があります。通常のエージェントはルールをシステムプロンプトに最初から詰め込みますが、ompは「ルールに引っかかる兆候が出るまで黙っている」設計です。正規表現マッチでストリームを途中で止め、そのターンだけルールを注入してリトライします。毎回のターンでルールテキストを渡す必要がないため、コンテキストの消費が抑えられます。注入されたルールはセッションの圧縮後も残るので、一度コース修正すれば次のターンも効果が続きます。
サブエージェントを型付きで扱う
taskコマンドでファンアウトすると、各ワーカーが独立したworktreeで動き、最終的な出力はスキーマ検証済みのオブジェクトとして親に戻ります。自然言語の出力を親がパースするのではなく、型付きの結果として受け取れるのは、大きなジョブを並列化するときに実際の差がでます。Alt+Aで開くAgent Hubでは、動作中のサブエージェントのトランスクリプトを読んだり、操舵メッセージを送ったりできます。親セッションを止めることなく個別のワーカーを終了できる点も、長時間のバックグラウンド処理で重宝します。
Hashlineによるトークン効率の改善
「Hashline」と呼ばれる編集形式は、変更したい箇所をコンテンツハッシュのアンカーで指定します。モデルが書き換えたい行を丸ごと出力する代わりに、アンカーだけ指定できるため、出力トークンが減ります。README内のベンチマーク数値によると、Grok 4 Fastで同等の作業をしたとき出力トークンが61%少なくなっているとのことです。ファイルが変わってアンカーがずれた場合はパッチを拒否する仕組みになっていて、壊れた編集が静かに通り抜けるのを防いでいます。
こういう人に向くかも
LSP対応のエディタを日常的に使っていて、「エージェントに頼むとリファクタリングが雑になる」と感じている人に向いているツールです。リネーム一つとっても、エディタ経由の操作とテキスト置換では品質が違うことを知っているエンジニアなら、ompが何をやっているかはすぐに伝わるはずです。
逆に、まずシンプルなチャット形式でコードを生成したいだけ、という用途には少し大きすぎるかもしれません。60以上のプロバイダーへの対応、LSP設定、DAP設定と、触れる箇所が多いツールです。設定ファイルをゼロから書く場面では、ドキュメントのlsp-config.mdなどを読む時間が必要になります。チームで既にCursorやClineのルールファイルを持っているなら、そのまま読み込めるという点は導入の敷居を下げてくれます。CopilotのapplyToやClineの.clinerules、AGENTS.mdなど8種類のフォーマットをネイティブに読めるので、「移行コスト」という概念がかなり小さくなります。
設計の良し悪しをどこで見るか
評価軸として特に目を向けたいのは、機能の単一性とトークン効率の2点です。
ompは明らかに「単一機能」ではありません。LSP、DAP、サブエージェント、メモリ、コラボレーション、コードレビューと、機能が横に広がっています。このような多機能ツールを評価するときに見るべきなのは、「機能が足し算されているか、それとも統一されたモデルの上に乗っているか」という点です。ompの場合、read・grep・writeというツール面を一定に保ちながら、pr://やconflict://のような内部スキームを透過的に解決するアーキテクチャを取っています。GitHub PRを読むときと、ローカルファイルを読むときで、エージェントが使う道具が変わらない設計です。これは機能を足しながらも「エージェントが覚えることを増やさない」という方向性を持っていることを示しています。
トークン効率の面では、Hashline・stream rules・サブエージェントの型付き結果の3つが評価軸になります。特にstream rulesは「コンテキストに入れる量を減らす」設計であり、長いセッションでコストが膨らみやすいコーディング作業では実際の効果が見えやすいです。自分で使ってみるなら、同じタスクをhashline有効・無効で走らせてトークン数を比べてみると違いが数字で確認できます。
ドキュメントの深度については、READMEが機能ごとのキャプチャ動画へのリンクを持っており、各機能が何をするものか視覚的に把握できます。lsp-config.mdのような個別ドキュメントも存在しますが、全機能にわたる設定リファレンスがどこまで整備されているかは、実際に触りながら確認が必要です。
メンテナンスの継続性という点では、PRを一時的に開放したという記述をREADMEに正直に書いていること、CHANGELOGが存在することは好材料です。フォーク元との関係性も明記されていて、経緯が追いやすいのは信頼感につながります。
自分が書くなら、どこを変えるか
ドキュメントの構造が気になります。READMEは18個の機能をシーケンシャルに並べていますが、「何から始めればよいか」の導線が読み取りにくいです。たとえばLSPを使いたいだけの人と、サブエージェントのファンアウトを試したい人では、読むべき設定が全く異なります。機能マップのような入口があると、目的別に進めやすくなるのではないかと思います。
もう一点は、エラー時の挙動の説明です。Hashlineがアンカーのずれを検出してパッチを拒否する、stream rulesがストリームを中断してリトライする、といった動作は設計として面白いですが、実際に失敗したときに何が表示されてどう対処すればよいかが、ドキュメントからは読み取りにくいです。失敗パターンと復帰方法をまとめたセクションがあると、導入後の体験がかなり改善されるのではないでしょうか。設定の柔軟性が高い分、「うまくいかない状態」のバリエーションも多くなりがちなので、そこのフォローが厚いと安心感が違います。
導入を検討するときのチェック観点
- 使いたいLLMプロバイダーが60以上のプロバイダー一覧に含まれているか確認する
- LSPを使う場合、自分のプロジェクトで使用している言語サーバーがomp側でどう設定するか確認する（lsp-config.mdを参照）
- DAPを使う場合、対象のデバッガ（lldb・dlv・debugpyなど）がローカルにインストールされているか確認する
- 既存のルールファイル（Cursor MDC・Cline .clinerules・AGENTS.mdなど）がある場合、そのままの形で読み込めるか動作確認する
- チームで使う場合、
/collabによるセッション共有の権限設計（read-only vs read-write）をどう運用するか事前に決めておく - Alpine Linuxなどmuslベース環境では
libstdc++とlibgccの追加インストールが必要になることを確認する - メモリバックエンド（local・Hindsight・Mnemopi）の選択と、プロジェクトスコープの管理方針を決めておく
積み上げ方の話
IDEが持っている情報をエージェントに渡す、という発想自体は以前からありましたが、LSP・DAP・プロセス内ripgrep・型付きサブエージェントを一本のツールに積むところまでやりきっているプロジェクトは多くありません。機能の多さは「大きすぎる」という評価にもなり得ますが、ひとつの一貫したツール面の上に乗せている点は、単なる足し算とは少し違う印象を受けます。どの機能から試すかは目的によって変わりますが、LSP対応とHashlineだけでも日常の開発フローに変化が出るかどうか確かめてみる価値はあるのではないでしょうか。
