Oh My Pi

Oh My Piを選ぶ理由

Oh My Pi は、ターミナルでのエージェント開発を好みつつ、IDE で使えるようなコード解析機能も手放したくない開発者向けです。

重要なのは、ツールの数よりもこの位置づけです。多くの CLI コーディングエージェントは、ファイルの読み取り、シェルコマンドの実行、パッチの適用に対応します。OMP はさらに、言語サーバー、デバッガー、ブラウザー自動化、エージェント制御、永続的な実行カーネル、モデルルーティング、リポジトリ操作を一つの利用環境にまとめています。

その結果、シェルにチャット画面を付けたものというより、開発用ワークステーションの機能をエージェントに直接開放する試みに近くなっています。

成り立ちも製品の考え方を示しています。OMP の出発点である Pi は、小さく拡張可能なエージェントコアが魅力です。Oh My Pi は、開かれた拡張方式を保ちつつ、多くの機能を標準で備える方向へ進んでいます。最小構成の基盤にプラグイン、フック、スクリプト、MCP サーバーを組み合わせる作業に時間をかけてきた上級者には、魅力的な選択です。

その代わり、複雑さは増します。調整項目、認証する提供元、把握すべき実行経路が多くなります。必要なワークフローでは価値がありますが、数ファイルを修正してテストするだけなら、余分な負担になる場合があります。

基本的な作業の流れ

OMP を効果的に使うセッションは、空の会話ではなくリポジトリから始まるのが一般的です。

エージェントは、プロジェクトの情報、既存ルール、言語サーバーの状態、Git 履歴、検索、実行時ツールを使い、編集前にコードベースを理解できます。実装中も、テキスト検索やコンパイラー出力だけでなく、意味情報に基づくナビゲーション、ファイル編集、シェル実行、診断、デバッガーによる調査を組み合わせられます。

これは、リポジトリ全体に及ぶ変更で特に役立ちます。

複数パッケージにまたがる API 名の変更を考えてみましょう。テキストだけを扱うエージェントは文字列検索と置換を行えますが、再エクスポート、別名、生成ファイル、オーバーロード、たまたま同名の参照があると不安定になります。OMP の LSP を使うワークフローでは、エディターのナビゲーションや名前変更と同じ意味情報を利用できます。

デバッグも同様です。言語環境が DAP に対応していれば、ログを追加するために何度もソースを変更せず、デバッグセッションを利用できます。作業の流れを edit, print, rerun から reproduce, pause, inspect, reason, patch, verify、つまり再現・停止・状態確認・推論・修正・検証へ変えられます。

大きなタスクでは、親エージェントがすべての調査を一つのコンテキストで抱える必要はありません。サブエージェントに調査や実装を分担させ、分離によって編集の衝突を減らせます。価値は並列化だけでなく、コンテキストの分離にあります。依存関係の調査、テスト失敗の分析、文書整備、実装のすべてが、親エージェントの作業コンテキストを消費する必要はありません。

モデルルーターが重要な理由

OMP は、モデル選択を単一のグローバル設定として扱わない点で、CLI エージェントの中でも特徴的です。

役割ごとのルーティングにより、作業に応じてモデルを変えられます。範囲の狭いサブタスクには比較的安価なモデル、設計や難しいデバッグには高い推論能力を持つモデルを使えます。別のアドバイザーが、まったく同じコンテキストを共有せずに親エージェントの作業をレビューすることもできます。

この構成は費用管理に役立ちますが、設定が処理内容に合っていることが前提です。

検索、分類、実装、サブエージェントのすべてに高価な最先端モデルを使う構成は簡単ですが、オーケストレーションによる費用上の利点を失いかねません。反対に、重要な実装を能力不足のモデルに任せると、リトライや無駄なツール操作が増える場合があります。

実用的な設定では、モデルの役割を意図的に分けます。

• default：通常の対話型の実装作業。
• smol：低コストの並列調査や範囲を絞ったワーカータスク。
• slow：難しい推論や調査。
• advisor：追加のモデル呼び出しに見合う価値がある独立レビュー。
• ローカルモデル：コード品質が十分な場合の、予測しやすい処理、機密性の高い作業、低コストのタスク。

主な利点は、多数の提供元に接続できること自体ではなく、モデルの能力をタスクの難しさに合わせるワークフローを作れることです。

OMP と Claude Code の違い

Claude Code と Oh My Pi は、リポジトリの調査、コード変更、コマンド実行、不具合調査、複数段階の開発作業など、多くの用途が重なります。

大きな違いは、製品の考え方にあります。

Claude Code は Anthropic を中心に密接に統合された体験を提供します。OMP はモデルに依存しない設計を採用し、より幅広いルーティング層を備えます。周辺の開発ワークフローを作り直さずに、Anthropic、OpenAI、Gemini、xAI、ゲートウェイ、コーディング向けサブスクリプション、ローカル推論を切り替えられます。

OMP は、LSP、DAP、カスタム実行環境、サブエージェント制御、ユーザーが拡張できる内部構造も重視しています。

Anthropic に統一しているチームには、Claude Code のほうが簡単な場合があります。提供元への非依存、ローカルモデル、独自のエージェント基盤、異なるモデルへの振り分けが重要な要件なら、OMP の魅力が増します。

OMP と Codex CLI の違い

Codex CLI と OMP は、どちらもターミナル中心の開発に自然に組み込めます。

OpenAI のコーディングモデルとエコシステムを中心に使うなら、Codex CLI がわかりやすい選択です。OMP は、OpenAI と多くの他の提供元を併用できる汎用的な実行基盤に近い性格を持ちます。

モデルを頻繁に変えるユーザーには、この違いが重要です。OMP では、推論バックエンドを変えてもツール、セッションの仕組み、ルール、オーケストレーション方針を維持できます。

OMP は、拡張機能、RPC、ACP、SDK を通じて内部機能をプログラムから利用できるようにしています。独自のエージェント UI を作ったり、大きな自動化システムにコーディングエージェントを組み込んだりする開発者には重要です。

OMP と Aider の違い

Aider はターミナル型コーディング支援として長い実績があり、Git 中心の編集や、モデルとコードを直接結ぶ比較的シンプルな流れを求める場合に魅力があります。

OMP は、より幅広い機能をエージェントに提供します。

意味情報に基づくコード解析、デバッガー連携、ブラウザー操作、状態を保持したコード評価、サブエージェント制御、プログラムから扱える実行環境により、パッチ生成を超える作業に対応します。その分、運用の負担が増え、設定体系の変化も速くなります。

選ぶ際は、どちらもコードを編集できるかより、求めるエージェントの運用方式に注目するとよいでしょう。

Aider は、Git のワークフローに強い、用途を絞ったコーディングアシスタントを求める人向けです。OMP は、ターミナルのエージェントをプログラム可能な開発環境にしたい人に向いています。

おすすめの構成

設定の自由度が高いエージェントでは、すべての機能を有効にしたくなりがちです。しかし、それが最も安定する構成とは限りません。

主な実行経路を小さく保ち、繰り返し起こる問題を解決するために必要な機能を追加するほうがよいでしょう。

まず信頼できる既定モデルと、より安価なワーカーモデルを用意します。複雑なタスクで必要になってから、時間をかけて推論する専用モデルを追加します。別のコンテキストを使う費用に見合う独立レビューが必要なら、アドバイザーを導入します。

言語サーバーは、リポジトリで主に使う言語に合わせて設定します。初期化に失敗し続ける LSP は、意味情報を提供せず遅延だけを増やします。

MCP サーバーや拡張機能も同様です。OMP は複数の既存エージェント環境から設定を検出でき、移行時には便利です。しかし、長年蓄積したツールやルールを自動で取り込むと、不要な情報が増える場合があります。見つかった内容を確認し、すべての連携を有効なままにするべきだとは考えないでください。

プライバシーを考慮する場合、最先端モデルの品質を必要としないタスクをローカルバックエンドに割り当てられます。ただし、機密リポジトリでは全体の評価が必要です。主モデルがローカルでも、Web 検索、外部 MCP サーバー、拡張機能、コラボレーション、その他の設定済みサービスが通信する可能性があります。

ローカルモデルと BYOK の方針

一社のクラウドを前提に動くツールと比べ、OMP ではローカルモデル対応をより活用しやすくなっています。

ローカルの Ollama、LM Studio、llama.cpp、vLLM を、同じワークフローの別バックエンドとして使えます。繰り返すコード検索、非公開の実験、オフライン開発、最高品質よりトークン費用を重視する処理に役立ちます。

ただし、ローカルであれば必ず優れているわけではありません。

コーディング基盤は、モデルに確実なツール利用、スキーマへの準拠、コンテキストの保持、正確な編集を求めます。小型のローカルモデルではリトライが増えたり、計画の質が下がったりする場合があります。実行失敗が続けば、トークンが安くてもタスク全体は高くつくことがあります。

モデルは単なるベンチマーク値ではなく、タスク単位で評価するのが適切です。小型のローカルモデルがコード検索、ファイル要約、限定的なサブタスクを確実にこなせるなら、リポジトリ全体のセッションを主導できなくても、ワーカーとして有用です。

移行時の注意点

ワークステーションに複数のコーディングエージェント設定が散在している開発者にとって、OMP は試しやすいツールです。

設定検出の仕組みが、複数の環境からルール、コンテキスト、スキル、関連設定を読み取ります。すぐに独自形式へ変換する必要がないため、既存エージェントと並行して試す負担を減らせます。

ただし、移行では無条件に取り込むのではなく、内容を点検すべきです。

Cursor 向けのルールはエディターのコンテキストを前提とし、Claude 向けの指示は固有の挙動に依存しているかもしれません。MCP サーバーが OMP の内蔵ツールと重複したり、古いプロジェクト指示が新しい AGENTS.md と衝突したりする場合もあります。

整理しながら移行するには、次の手順が役立ちます。

1. 代表的なリポジトリで OMP を起動します。
2. 検出されたルール、スキル、MCP サーバー、コンテキストファイルを確認します。
3. 重複や古い指示を取り除きます。
4. 意図しないプロバイダーの既定値を使わず、モデルの役割を明示的に決めます。
5. 通常の開発タスクをいくつか実行してから、複雑なオーケストレーションを有効にします。
6. シンプルな構成で実際の必要性が見えた段階で、サブエージェント、アドバイザー、メモリ、ブラウザー自動化、独自拡張を追加します。

この方法なら、既存のエージェント環境との互換性という強みを活かしつつ、古い設定が見えない技術的負債になるのを防げます。

OMP が向いている用途

リポジトリ全体のリファクタリング

変更がパッケージ、シンボル、依存関係をまたぐ場合、LSP を使うナビゲーションや名前変更は、文字列だけの編集より確実に行える場合があります。

難しい不具合のデバッグ

DAP 連携により、ログやテスト出力だけに頼らず、エージェントが実行時の状態を直接調べられます。

複数モデルを使う開発

複数の AI 提供元を使うチームや個人は、一つのコーディング基盤を維持しながら、作業ごとに別のバックエンドへ振り分けられます。

並列での調査

サブエージェントで調査、デバッグ、実装、レビューのコンテキストを分け、親エージェントが結果を取りまとめられます。

エージェントプラットフォームの開発

SDK、RPC モード、ACP、拡張機能、スキル、独自ツールを備え、手動で使うだけでなく、エージェントを土台に開発したい人にも向いています。

利用上の注意点

OMP の最大の長所と短所は同じです。扱う機能の範囲が広いことです。

ほぼすべての有用な開発機能を一つのターミナルエージェントに集めようとしています。個別ツールを組み合わせる手間は減りますが、設定や構成要素が増え、提供元、プラグイン、言語サーバー、ツール、権限の相互作用も多くなります。

リリースの速さも、このトレードオフに関わります。新機能をすぐに使える一方、本番利用のチームは、更新が運用に影響しないと決めつけず、バージョンを固定して変更履歴を確認すべきです。

提供元に縛られない運用にも管理が必要です。一つのセッションに、主モデル、安価なワーカー、アドバイザー、検索サービス、画像・音声サービス、外部 MCP ツールが関わる可能性があります。柔軟である一方、費用とプライバシーはステータスバーのモデルだけでなく、設定されたワークフロー全体で決まります。

選び方の目安

単純なコーディングチャットボット以上のものが必要な理由を理解している開発者に、Oh My Pi は特に向いています。

ターミナル操作、意味情報を使うコード解析、デバッガー、提供元への非依存、ローカル推論、サブエージェント、プログラム制御を同じワークフローで活かせるなら、有力な選択です。

作業の中心が edit these files and run the tests、つまりファイル修正とテスト実行であれば、よりシンプルな CLI エージェントが合うかもしれません。ターミナル自動化より、GUI での差分レビュー、インライン補完、画面上のワークスペース連携を重視するなら、AI ネイティブエディターが向いています。

OMP はその中間に位置します。IDE とエージェントフレームワークの両方の性格を強めている CLI エージェントです。