oh-my-pi とは？ターミナル、IDE、デバッガをつなぐ AI コーディングアシスタント

Sat, 23 May 2026 19:02:20 +0800

oh-my-pi は、ターミナルとエディタ向けの AI Coding Agent です。Mario Zechner の Pi プロジェクトをもとにしたフォークで、can1357 によって拡張されています。目的は単なるコマンドラインのチャット画面を作ることではなく、ファイル読み取り、コード検索、構造化編集、LSP、デバッガ、ブラウザ、サブエージェント、複数モデルプロバイダをひとつのコーディングワークフローに接続することです。

README を見ると、これはシンプルなアシスタントというより、AI コーディングのためのツール基盤に近いものです。ターミナルで対話的に使えるだけでなく、ACP 経由でエディタに接続したり、SDK 経由で Node プロジェクトに組み込んだりできます。Claude Code、Codex CLI、Cline、Cursor などをすでに使っている人にとって、oh-my-pi の面白さは、外部ツールに分散しがちな機能をひとつの内蔵ツール面にまとめている点にあります。

何を解決しようとしているのか

多くの AI コーディングツールの弱点は、モデルそのものではなく、その周辺のツールインターフェースにあります。モデルがコードを変更したくても、粗い全文読み取り、壊れやすい文字列置換、一回限りの shell しか使えない場合、失敗率はツールチェーンによって大きくなります。

oh-my-pi は、こうした摩擦を減らそうとしています。

ファイル読み取りでは、全文をそのままコンテキストに入れるのではなく、構造化された要約を優先します。
search、glob、find、シンタックスハイライト、token 計数などを可能な範囲でネイティブ実装し、外部コマンドへの依存を減らします。
コード書き込みでは LSP を利用し、リネーム、参照検索、ファイル移動を IDE の動作に近づけます。
デバッグでは lldb、dlv、debugpy などの DAP ツールを使い、ログと推測だけに頼らない流れにします。
複雑なタスクはサブエージェントに分割し、構造化された結果として返せます。
編集操作では内容アンカーとプレビューを使い、誤った patch が直接ディスクに反映される可能性を下げます。

つまり重視しているのは「モデルが答えられるか」ではなく、「モデルが実際のコード変更を安定して完了できるか」です。

インストール方法

プロジェクトはいくつかのインストール方法を提供しています。macOS と Linux ではインストールスクリプトを使えます。

`1`	`curl -fsSL https://omp.sh/install \| sh`

Bun を使う場合、README では npm パッケージのグローバルインストールが推奨されています。

`1`	`bun install -g @oh-my-pi/pi-coding-agent`

Windows PowerShell では次のコマンドを使えます。

`1`	`irm https://omp.sh/install.ps1 \| iex`

README では mise によるバージョン固定にも触れています。

`1`	`mise use -g github:can1357/oh-my-pi`

インストール前に Bun のバージョン要件を確認しておきましょう。README では macOS、Linux、Windows が対象とされ、bun >= 1.3.14 が必要とされています。

注目したい機能

1. ツール呼び出しが shell だけではない

oh-my-pi には、ファイル読み取り、検索、書き込み、編集、AST 編集、ブラウザ、タスク分割、デバッグ、LSP などのツールが内蔵されています。README では 32 個の内蔵ツール、13 個の LSP 操作、27 個の DAP 操作に触れています。

そのため、Agent はすべてをコマンドライン出力として扱う必要がありません。参照検索は LSP を使えますし、PR や issue は統一されたファイル風インターフェースで読めます。Web ページや PDF も、リンク構造を保った Markdown に変換してからモデルに渡せます。

2. LSP 統合は実際のコードベースで効く

大きなプロジェクトでは、リネームやファイル移動の際に re-export、エイリアス import、barrel file、ディレクトリをまたぐ参照を漏らしがちです。oh-my-pi の README は、書き込み経路が LSP と連携できることを強調しています。たとえばファイルリネームは workspace/willRenameFiles を通るため、編集が IDE の意味的操作に近づきます。

これは TypeScript、Rust、Go、Python などの日常的なリファクタリングで役立ちます。特に、手で直せるものの参照漏れが起きやすい場面に向いています。

3. デバッガが第一級のツールになる

多くの AI コーディングフローでは、クラッシュに遭遇するとログを追加し、再実行し、出力を読むという流れにとどまります。oh-my-pi は DAP デバッガをツール面に接続します。README では C プログラムに lldb、Go サービスに dlv、Python プロセスに debugpy を使う例が紹介されています。

これにより、Agent のバグ対応は変わります。プロセスを一時停止し、スタックフレームを見て、ローカル変数を読み、そのうえで次の手を決められるようになります。

4. Hashline 編集で patch 失敗を減らす

プロジェクトが強調する Hashline は、内容アンカーに基づく編集方式です。モデルが大きな diff を何度も出すのではなく、変更したい内容のアンカーを指せるようにします。これにより、空白、古いコンテキスト、文字列マッチ失敗による編集エラーを減らせます。

Agent ツールにとって、この仕組みは重要です。モデルが強くても、書き込みインターフェースが何度も失敗するなら、体験は結局リトライだらけになります。

5. サブエージェントとワークスペース分離

README では task サブエージェント機能が紹介されています。ひとつのタスクを複数の隔離された worker に分割し、結果を構造化オブジェクトとして返せます。プロジェクトには、並列タスク、分岐探索、編集の衝突回避に使うワークスペース分離の実装も含まれています。

これはコードレビュー、移行、まとめての修正、テスト調査に向いています。価値は単に「並列で速い」ことだけではなく、探索経路ごとのコンテキストと変更をきれいに分けられる点にもあります。

6. 既存のルールと設定を引き継げる

oh-my-pi は初回実行時に、他のツールが残したルールや設定を読み取れます。対象には .claude、.cursor、.windsurf、.gemini、.codex、.cline、.github/copilot、.vscode などが含まれます。

これは実用的です。多くのチームはすでに複数の AI ツール向けにルールを書いています。新しいツールごとに移行し直すのは負担が大きいため、oh-my-pi は既存のコンテキストをできるだけ再利用しようとします。

4 つの入口

プロジェクトには主に 4 種類の使い方があります。

対話型 TUI：ターミナルで omp を直接実行します。
ワンショットコマンド：omp -p で単発の prompt を送ります。
Node SDK：@oh-my-pi/pi-coding-agent を使って Node や TypeScript プロジェクトに組み込みます。
RPC / ACP：stdio または Agent Client Protocol 経由で、他のプログラムやエディタに接続します。

つまり、個人のターミナル利用だけでなく、IDE、プラグイン、自動化基盤、社内ツールへの統合も想定されています。

誰に向いているか

oh-my-pi は次のような人に向いています。

ターミナルでコード変更、デバッグ、レビューをよく行う人。
AI Coding Agent を使っているが、ファイル読み取り、patch、検索、デバッグの安定性に不満がある人。
Agent をエディタ、RPC、Node サービスに接続したい開発者。
ひとつのツールで複数モデルや複数プロバイダを切り替えたい人。
LSP、DAP、AST 編集、サブエージェントなどの基盤機能に興味があるツール開発者。

ただし、すぐ使えるチャット型のコードアシスタントだけが欲しい場合は、学習コストが高く感じられるかもしれません。ツールチェーンを理解し、Agent を設定可能な開発環境として扱いたい人に向いています。

使うときの注意点

第一に、oh-my-pi はまだ速いペースで進化しているオープンソースプロジェクトです。コミットは頻繁で、issue や PR も多いため、インストール方法や使い方は変わる可能性があります。

第二に、体験はローカル環境に大きく左右されます。LSP、デバッガ、Bun、モデルプロバイダの認証、ターミナル環境、Windows と Unix の違いが影響します。

第三に、内蔵ツールが多いからといって、すべての場面で全部を有効にすべきではありません。実際にはタスクに必要なツールを選び、ルール、権限、ワークスペース境界を明確にするほうが安全です。

第四に、AI Agent はコードを書けますが、誤って変更することもあります。プレビューや内容アンカー編集があっても、重要なプロジェクトではバージョン管理、テスト、人間によるレビューが必要です。

まとめ

oh-my-pi の面白さは、またひとつ AI ターミナルシェルが増えたことではありません。AI コーディングで足を引っ張りがちなツール層、つまりファイル読み取り、検索、編集、LSP、デバッグ、ブラウザ、サブエージェント、SDK をひとつの Agent ワークフローに整理している点です。

AI コーディング基盤に関心がある人や、複数の Coding Agent の方向性を比較したい開発者に向いています。現在の AI コーディングツールの競争は、モデルの回答品質だけではありません。モデルを実際のコードベース、実際のデバッグフロー、実際のチームルールに安定して接続できるかが問われています。oh-my-pi は、その方向にかなり踏み込んだオープンソース実装です。

参考資料：

GitHub プロジェクト：https://github.com/can1357/oh-my-pi
公式サイト：https://omp.sh/
SDK ドキュメント：https://omp.sh/docs/sdk

Terminal Tools on KnightLiブログ