oh-my-pi：ターミナルCoding Agentの最強フォークを全部解説する
oh-my-pi：ターミナルCoding Agentの最強フォークを全部解説する
出典: note.com / 2026-05-20
はじめに——ハーネスが全てを変える
「どのAIモデルが一番優秀か？」——この問いは、もう半分だけ正しい。モデルの性能差は確かに存在するが、実際のコーディング現場で成果を左右するのは、モデルとコードベースの間にある「ハーネス」、つまりエージェントの仕組みそのものだ。
oh-my-pi（omp）は、Piという軽量なターミナルCoding Agentをフォークし、そこに32個のツール、LSP統合、サブAgent並列実行、セッション間メモリといった機能をつけ加えたプロジェクト。開発者のCan Bölükが1,300コミット以上を重ね、GitHubで5,100スターを超えた。注目すべきは、彼のベンチマークでHashlineと呼ばれる新しい編集フォーマットがGrok Code Fast 1の成功率を6.7%から68.3%に引き上げたという事実だ。モデルの重みは変えていない。ハーネスだけを変えた。
Piとoh-my-pi、何が違うのか
オリジナルのPiはMario Zechnerが作った、ミニマリズムに徹したコーディングエージェントだ。システムプロンプトがわずか2,000トークン。「Bashがあれば十分」という哲学で、余計な装飾を排している。
oh-my-piはその土台の上で、現場で足りなかったものを全部積み込んだ。Rustで書かれた27,000行のネイティブコアが、grep、シェル、AST操作、シンタックスハイライトをプロセス内で完結させる。他のエージェントが外部バイナリにfork-execで処理を委ねるのに対し、ompはその全部をインプロセスで動かす。速度と安定性の差は歴然だ。
核心技術——Hashline edits
oh-my-pi最大の発明はHashline editsだ。他のエージェントが採用する編集フォーマットには致命的な弱点がある。
Claude Codeのstr_replaceは、モデルが変更したい行を一字一句正確に再現する必要がある。空白のズレ一つで「String to replace not found」が返る。Codexのapply_patchはOpenAI向けに最適化されたフォーマットで、他のモデルに使わせるとパッチ失敗率が50%を超える。
Hashlineの発想は違う。モデルがファイルを読むとき、各行に2〜3文字のコンテンツハッシュが付与される。モデルは「行2:f1を置換せよ」とハッシュを指定するだけで、内容を再現する必要がない。ファイルが読み込み後に変更されていればハッシュが一致せず、破壊的な編集が起きる前に拒否される。
この仕組みにより、Grok 4 Fastの出力トークンが61%減少。MiniMaxの成功率は2.1倍に跳ね上がった。モデルの能力が変わったわけではない。モデルが変更を「伝える手段」が改善しただけだ。
全ツール解説
ompには32個のツールが組み込まれている。以下に主要なものを分類して示す。
ファイル操作と検索
readはファイル、ディレクトリ、アーカイブ、SQLite、PDF、Jupyter Notebook、URL、そして内部スキーム（pr://、issue://など）を統一的に読み込む。writeはファイルやSQLite行の作成・上書き。editはHashlineパッチによる編集。ast_editはtree-sitterベースの構造的リライトで、適用前にプレビューが表示される。ast_grepは50以上の言語に対応した構造コード検索。searchは正規表現によるファイル横断検索。findはglobベースのパス検索。
ランタイム
bashはワークスペースシェル。PTYやバックグラウンドジョブにも対応する。evalは永続的なPythonとJavaScriptのセルを提供し、2つのカーネルがお互いのツールを呼び出せる。CSVをPythonで読み、JavaScriptでグラフを描くといった処理がセル内で完結する。recipeはbun、just、make、cargoといったタスクランナーを自動検出して実行。sshは設定済みホストへのリモートコマンド実行。
コードインテリジェンス
lspは診断、ナビゲーション、シンボル検索、リネーム、コードアクションを提供する。IDEが知っている情報をエージェントも知っている。リネームの要求はworkspace/willRenameFilesを経由するため、re-exportやバレルファイル、エイリアスされたインポートまで自動更新される。debugはDAPセッションを制御し、ブレークポイント、ステッピング、スレッド、スタック、変数を操作できる。
協調とサブAgent
taskはサブAgentを並列に展開する。各ワーカーは独立したworktreeで動作し、最終結果はスキーマで検証されたオブジェクトとして親に返る。ircは同一プロセス内のAgent間通信。todo_writeはフェーズ追跡付きのタスクリスト管理。askは対話的な選択肢を提示する。
外部接続
browserはPuppeteerベースのヘッドレスブラウザ制御。ステルスモードがデフォルトで、通常のユーザーエージェントとしてページにアクセスする。web_searchは14の検索プロバイダーをチェーンし、見つかったURLをreadに直接渡す。arXivのPDFもGitHubページも構造化Markdownとして返ってくる。generate_imageはGemini画像モデルによる画像生成・編集。
メモリと状態
Hindsightと呼ばれるセッション間メモリがある。retainで事実を保存し、recallで検索し、reflectで統合的な回答を生成する。プロジェクト単位でスコープされるため、あるリポジトリで学んだ知識が別のリポジトリに漏れない。checkpointは会話状態のマーク。rewindは探索的コンテキストを刈り込んで要約する。
内部URLスキーム
ompは10種類の内部URLスキームを持つ。pr://1428はPRを、issue://42はIssueを、skill://nameはスキル定義を、conflict://Nはマージコンフリクトを返す。read pr://1428はread src/foo.tsと同じ形状の結果を返すため、モデルは1つのインターフェースだけ覚えれば済む。conflict://に@theirsや@oursを書き込めばコンフリクトが解決される。
40以上のプロバイダー対応
ompはロールベースのモデルルーティングを採用している。defaultは通常のターン。smolは安価なサブAgent用。slowは深い推論用。planはプランモード用。commitはチェンジログ用。各ロールに異なるモデルを割り当てられる。
対応プロバイダーはAnthropic、OpenAI、Google Gemini、xAI、Mistral、Groq、Together、OpenRouter、Ollamaをはじめ40以上。Ollamaやllama.cppといったローカルモデルにも完全対応している。APIキーを複数設定してローテーションさせたり、フォールバックチェーンで429エラー時に自動的に次のプロバイダーに切り替えたりできる。
models.ymlにカスタムプロバイダーを定義すれば、OpenAI互換の任意のエンドポイントを追加できる。
4つのエントリポイント
ompは4つのモードで動く。ompで起動するTUIが基本。omp -pでワンショットプロンプトを実行して即座に終了する。Node SDKでセッションを自分のプロセスに埋め込める。omp —mode rpcでNDJSONによるstdio制御、omp acpでエディタープロトコル経由の操作が可能になる。
Zedエディタでompを動かすと、ターミナルと同じエージェントがエディタのバッファを読み、エディタのセーブ経由で書き込み、エディタのターミナルでシェルを起動する。破壊的なツールは許可プロンプトで一時停止する。
設定とカスタマイズ
設定は~/.omp/agent/config.ymlに書く。初回起動時にプロバイダーの認証を聞かれるので、使いたいサービスのAPIキーを入力する。OpenRouterのキーがあれば40以上のモデルに即座にアクセスできる。
不要な機能を無効にしてトークン消費を抑えることが重要だ。Redditユーザーの実績によると、メモリ機能を無効にし、使わないサブAgent（explore、oracle、librarian等）をdisabledAgentsに追加し、Claude由来のスキルライブラリの読み込みを止めると、初期コンテキストを大幅に削減できる。
コンテキスト管理には/handoffコマンドが有効だ。コンテキスト使用量が25〜30%に達したら/handoffを実行すると、現在のセッションを圧縮して新しいセッションに自動的に引き継ぐ。
スラッシュコマンド一覧
/modelでセッション中のモデルを切り替える。/fastで優先処理モードのオンオフ。/handoffでコンテキスト圧縮と新セッションへの移行。/reviewでコードレビューを起動（サブAgentが並列でブランチやコミットを審査し、P0〜P3の優先度付きで結果を返す）。/loginでプロバイダーのOAuth認証。/reload-pluginsでプラグインの再読み込み。/debugでデバッグ・プロファイリングツールを表示。/sshでリモートホストの追加・削除。/skill:で任意のスキルを呼び出す。
既存設定の引き継ぎ
ompは.cursor、.claude、.windsurf、.gemini、.codex、.cline、.github/copilot、.vscodeに存在するルール、スキル、MCPサーバー設定をそのまま読み込む。移行スクリプトは不要。チームが前四半期に書いた設定が、その夜からそのまま動く。
拡張性
拡張機能はTypeScriptモジュールとして書ける。同じツールAPI、同じスラッシュコマンド登録、同じホットキーテーブルが使える。組み込み機能と外部拡張の間に境界はない。
MCPサーバーもネイティブ対応で、stdioとHTTPトランスポートの両方をサポートする。自動再接続、セキュリティフィルタリング、ゼロコンフィグのツール注入が可能だ。
実際のユーザーの声
Reddit（r/OnlyAICoding）でoh-my-piを日常的に使っているユーザーは「extremely hackable with sensible defaults（非常にハッカブルで、デフォルト設定が適切）」と評している。使わないコンポーネントを無効にし、認証とMCPを設定すれば即座に使い始められるという。
もう一人のユーザーは「最初のコーディングエージェントで、自分の脳の働き方に合わせて形を変えられた」と述べている。
懸念点も明確だ。初期コンテキストが22,000トークンと、オリジナルPiの2,000トークンに比べて大きい。この差は長時間セッションで蓄積されるトークンコストに直結する。ただし、不要なツールやサブAgentを無効にすれば大幅に削減できる。/handoffによるコンテキスト管理を併用すれば、経済的に運用可能だ。
あるユーザーはClaude Opusをプランニングと意思決定に、GPT 5.4をタスク実行に使い分ける構成を公開している。ompのロールベースルーティングを使えば、この構成を自然に実現できる。
Claude CodeやCodexとの違い
Claude CodeとCodexは箱出しで使いやすいが、カスタマイズの余地が限られている。ompは4つのプリミティブ（read、edit、bash、task）を与え、残りは利用者が組み立てるスタイルだ。
この設計思想の差は、特にローカルモデルとの組み合わせで顕著になる。MLXやGGUFモデルはompのハーネス最適化の恩恵を直接受け、Hashlineエディットによって他のエージェントでは発揮できない性能を引き出せる。
今後の展望
Can Bölükはブログ記事「The Harness Problem」で、ハーネス問題が「1社が非公開で、1モデルのために解くか、コミュニティが公開で、全モデルのために解くか」と問いかける。ompは後者を選んだ。AnthropicがOpenCodeを遮断し、Googleが彼のアカウントを無効化した中で、彼はハーネスの最適化が各ベンダーにとっての「無料R&D」だと主張する。
モデルは堀。ハーネスは橋だ。橋を燃やしても、渡る人は減るだけだ。
まとめ——ompに向いている人
ターミナルでコードを書き、ローカルモデルや複数プロバイダーを使い分け、エージェントの挙動を細かく制御したい技術者。CursorやClaude Codeでは物足りなくなった人。自分でツールチェーンを組み立てたい人。ompはそういう「攻めの開発者」のためにある。
逆に、箱出しで何も設定せずに使いたい人にはClaude Codeの方が向いている。ompは設定とカスタマイズに時間をかけることで真価を発揮する。
インストールは一行。bun install -g @oh-my-pi/pi-coding-agent。あとはompと打つだけだ。
この記事は note.com から KTBLOG に移行されました。元記事: https://note.com/famous_prawn2009/n/nfe4d54f47225