Pi vs OpenCode - どちらのAIコーディングエージェントを使うべきか？
KKTG Analysis
Computing/SoftwareSmall Business/StartupsInternet Technology
Transcript
00:00:00現在、ターミナルを舞台に、2つの本格的なオープンソースAIコーディングエージェントが競い合っています。
00:00:04選択を誤れば、後でワークフロー全体を再構築することになりかねません。
00:00:10一方は、必要な機能がすべて最初から揃っています。もう一方は
00:00:14中身はほぼ空ですが、それこそが肝要だと主張しています。今日は、
00:00:19Open CodeとPiを徹底比較します。
00:00:21この動画を見終わる頃には、どちらをターミナルに導入すべきか明確に分かるはずです。
00:00:27まずは、これらのツールが一体何なのか見ていきましょう。
00:00:30同じ核心的な課題を、根本的に異なる方法で解決しようとしているからです。
00:00:34Open CodeもPiもターミナルベースのAIコーディングエージェントです。これらを
00:00:40ターミナルで実行し、ClaudeやGPTといった大規模言語モデルに接続します。そして
00:00:45コードの読み取り、ファイルの編集、シェルコマンドの実行、コードベースに関する深い対話が可能です。
00:00:50Claude Codeのオープンソース代替版だと考えてください。
00:00:55どちらもTypeScriptで書かれ、MITライセンスで、20以上の
00:01:01LLMプロバイダーをサポートしています。しかし、共通点は概ねそこまでです。Open Codeは
00:01:06Terminal.shopの創設者たちとNeovim愛好家コミュニティによって構築されました。
00:01:11これは、いわゆる「バッテリー内蔵」アプローチを採用しています。
00:01:15初期状態で、特定のタスクに特化した複数のエージェントシステム、
00:01:20承認ダイアログを備えた組み込みの権限システム、LSP（Language Server Protocol）
00:01:24によるコードインテリジェンス、外部ツール接続用の完全なMCP（Model Context Protocol）サポート、
00:01:29セッション永続化のためのSQLiteデータベースが手に入ります。
00:01:34さらに、ターミナルインターフェースに加えて、Tauriベースのデスクトップアプリまであります。
00:01:40Open Codeの哲学は、コーディングエージェントは適切なデフォルト設定と深い統合により、すぐに機能すべきだというものです。
00:01:45一方、Mario Zechner氏が作成したPiは、対極のアプローチをとっています。その哲学は
00:01:51その哲学はREADMEに明確に記されています。PIは
00:01:56徹底的に拡張可能で、ワークフローを強制しません。Piは
00:02:00あえてサブエージェントやMCPサポート、権限システムを搭載せず、
00:02:05プランモードやToDo管理もありません。その代わりに、
00:02:11その代わりに、強力な拡張APIを提供し、「必要なものを自作するか、
00:02:17好みの方法で実現しているコミュニティパッケージをインストールしてくれ」という姿勢です。コアは最小限に保たれ、それ以外はすべてオプトインです。
00:02:22つまり、これら2つのプロジェクトは、開発者ツールの設計思想における真の分岐点を象徴しています。
00:02:27それぞれの技術的な詳細を深掘りし、直接比較してみましょう。
00:02:32まずは、Open Codeのアーキテクチャから始めます。
00:02:36Open Codeは約21のパッケージで構成されるモノレポです。
00:02:42コアエンジンは単一のパッケージですが、Webコンソール、デスクトップアプリ、
00:02:46TypeScript SDK、プラグインシステム、共有UIコンポーネント、ドキュメント用のパッケージは分かれています。
00:02:52内部的には、起動と実行がNodeよりも大幅に速いBunで動作しています。
00:02:57LLM抽象化レイヤーには、汎用性の高いVercel AI SDK version 5を使用しています。
00:03:02これは、数十のプロバイダーに統一されたインターフェースを提供する、広く普及したライブラリです。
00:03:08手厚くメンテナンスされ、広く普及しているライブラリで、統一インターフェースを
00:03:13実用的な利点として、Open CodeはVercel SDKが新しい統合を追加するたびに、
00:03:18ほぼ自動的にそのプロバイダーサポートを継承できる点にあります。Open Codeの目玉機能の一つは、
00:03:24マルチエージェントシステムです。複数の特化型エージェントが搭載されています。
00:03:30Buildエージェントはデフォルトで、何でも読み書き・実行できるフルアクセスの開発エージェントです。
00:03:35Planエージェントは読み取り専用で、変更を加えずにコードを調査・分析するために設計されています。
00:03:40これは特定のプラン用ディレクトリにしか書き込みができません。
00:03:45Explorerエージェントは、コードベースのナビゲーションに特化した高速で軽量なスペシャリストで、
00:03:50検索と読み取り操作に制限されています。さらに、サブエージェントとして機能する、
00:03:55複雑なマルチステップタスク用のGeneralエージェントもあります。
00:04:00ユーザーはTabキーでこれらのエージェントを切り替えることができ、それぞれに独自の権限ルールが設定されています。
00:04:05また、設定ファイルでカスタムエージェントを定義することも可能です。
00:04:09使用するモデルや権限、システムプロンプトを個別に指定できます。
00:04:14データ永続化について、Open CodeはDrizzle ORMを備えたSQLiteを使用しています。
00:04:19セッション、メッセージ、権限、MCP認証情報はすべて、単一のデータベースファイルに保存されます。
00:04:25これは重要なアーキテクチャ上の選択です。SQLiteを採用することで、
00:04:30トランザクションの整合性、セッションを跨いだ効率的なクエリ、そしてバックアップが容易な単一ファイルという利点が得られます。
00:04:35Open Codeは、並列読み取りパフォーマンスを向上させるためにWALモードで動作させています。
00:04:41Open Codeの権限システムは、多層的で詳細に設定可能です。
00:04:46すべてのツールの呼び出しは権限チェックを通過します。
00:04:52ツールごと、あるいはファイルパターンごとにルールを設定できます。例えば、
00:04:57すべてのファイルの読み取りは許可するが、.envファイルの編集には承認を必須とし、
00:05:03本番環境のディレクトリに触れるシェルコマンドは完全に拒否するといった設定が可能です。
00:05:08権限は、グローバル設定からプロジェクト固有の上書き設定まで、複数のレベルでカスケードされます。
00:05:13エージェントが承認を必要とする場合、ターミナル上にインタラクティブなダイアログが表示され、
00:05:18「今回のみ許可」または「常に許可」を選択できます。MCP統合も本格的です。
00:05:24Open Codeはローカルとリモートの両方のMCPサーバーに接続できます。STDIOと
00:05:30HTTPトランスポートをサポートし、リモートサーバー用のOAuth認証を処理し、
00:05:37接続されたMCPサーバーからツールを自動的に登録します。
00:05:42他のツールですでにMCPサーバーを使用している場合、Open Codeですぐに利用可能です。
00:05:47もう一つの注目すべき機能は、組み込みのLSPサポートです。
00:05:53Open CodeはTypeScript、Python、Go、Rustなどの言語サーバーを起動できます。
00:05:58これにより、AIモデルは単なるテキストのパターンマッチングに頼るのではなく、
00:06:04ホバー情報、定義への移動、シンボル参照といった本物のコードインテリジェンスにアクセスできます。
00:06:10これはコード理解の正確性において、地味ながらも大きな利点です。
00:06:15Open Codeには、Claude Codeの形式と互換性のあるスキルシステムもあります。
00:06:20スキルは、特定の動作を定義したフロントマター付きのMarkdownファイルです。
00:06:25さらにNPMパッケージベースのプラグインシステムがあり、
00:06:30設定の読み込みからメッセージ変換、ツールの実行まで、ライフサイクルのほぼ全工程にフックできます。
00:06:35次にPiのアーキテクチャを見てみましょう。
00:06:40Piもモノレポですが、構造が異なります。主要なパッケージは、コーディングエージェント本体、
00:06:45LLM抽象化レイヤーのPi-i、ステートフルなエージェントランタイムのPi-agent-core、
00:06:51そしてターミナルレンダリングエージェントのPi-tuiです。他にもSlackボットのPiMomや、
00:06:57GPUデプロイ用のPiPodsなどがあります。Piにおける最も重要な技術的決断は、
00:07:02Vercel AI SDKを使わず、独自のLLM抽象化レイヤーをゼロから構築したことです。
00:07:08Pi-iは、統一されたマルチプロバイダーLLM APIで、
00:07:12MinimaxやKimiなど、Vercel SDKがカバーしていないプロバイダーを含む30以上をサポートしています。
00:07:20プロバイダーをサポート。Vercel AI SDKがカバーしていない
00:07:24独自のレイヤーを構築することで、Piチームはストリーミングの動作、ツール呼び出しのパース、
00:07:30プロバイダー固有の最適化を完全に制御できます。メンテナンスの負担は増えますが、
00:07:35ツール引数のストリーミング中に不完全なJSONをパースするといった機能を、
00:07:40意図通りに実装できるという利点があります。
00:07:44Piのセッション管理にはJSONL形式が採用されています。これは各行がJSONオブジェクトであるフラットファイルです。
00:07:50各エントリにIDと親IDがあり、単一ファイル内でツリー構造を実現しています。
00:07:56単一ファイル内での構造を実現。巧妙な設計で、会話の分岐や
00:08:00ブランチ間の移動が、標準的なUnixツールで簡単に閲覧できる1つのファイル内で完結します。
00:08:06treeコマンドを使えば会話履歴全体を可視化し、任意のポイントへ戻ることができます。
00:08:12会話履歴全体を可視化し、任意のポイントへ戻ることができます。
00:08:17forkコマンドは、どのメッセージからでも新しいブランチを作成できます。これは間違いなく、
00:08:23コーディングエージェントにおいて最高クラスの会話管理インターフェースの一つです。
00:08:28Piの拡張システムこそが、その哲学が真に活きている部分です。拡張機能は
00:08:33JITIによって直接読み込まれるTypeScriptファイルなので、コンパイル工程が不要です。
00:08:38拡張機能でカスタムツール、コマンド、キーボードショートカットを登録できます。また、
00:08:44セッション開始、エージェント起動、ツール呼び出し、モデル選択といったライフサイクルイベントを購読できます。
00:08:49確認ダイアログ、選択メニュー、テキスト入力プロンプトを通じてユーザーと対話することも可能です。
00:08:55独自のTUIコンポーネントをレンダリングすることさえできます。拡張APIからは、
00:09:01セッションマネージャー、モデルレジストリ、認証ストレージ、イベントバスにアクセスできます。
00:09:06つまり、拡張機能はコアができることなら実質的に何でもできるのです。
00:09:11ここでPiが意図的に機能を省いている理由が腑に落ちます。権限システムがない？
00:09:16危険なコマンドの前に確認ダイアログを出す拡張機能を書けばいい。サブエージェントがない？
00:09:20tmux経由でPiのインスタンスを立ち上げるか、複数のエージェントループを調整する拡張機能を書けばいい。
00:09:27MCPがない？CLIツールとREADMEでスキルを作るか、MCPサポートを追加する拡張機能を書けばいい。
00:09:33CLIツールとREADMEでスキルを作るか、MCP対応の拡張機能を書くことも可能です。
00:09:40プランモードがない？プランをMarkdownファイルに書き出すか、好みの方法で管理する拡張機能を作ればいいのです。
00:09:45Piのターミナルレンダリングも独自構築です。Pi-tuiパッケージは、
00:09:51画面更新を最小限に抑える3つの戦略を用いた差分レンダリングを実装しており、
00:09:56チラつきをなくすアトミック更新のためのCSI 2026プロトコルを使用しています。
00:10:02コンテナ、エディタ、テキストレンダリング、Markdown表示、画像サポート、
00:10:07選択リストを備えた独自のコンポーネントシステムを持っています。エージェントのTUIはこのフレームワークのみで構築されています。
00:10:13ツールに関しては、PiにはREAD、bash、edit、write、grep、find、lsの
00:10:187つの組み込みツールしかありません。あえて最小限に絞っているのです。bashツールは、
00:10:25オプションでDockerサンドボックス化とリアルタイムのストリーミング出力に対応しています。
00:10:30editツールはunified diff形式を使用します。すべてのツールは実行前にAJVで引数を検証し、
00:10:36デフォルトで並列実行をサポートしています。つまり、LLMからの複数のツール呼び出しを、
00:10:42順次ではなく同時に実行できます。では、重要なポイントでこれらを直接比較してみましょう。
00:10:48次に、最も重要な項目について、これら2つを直接比較してみましょう。
00:10:53プロバイダーサポート。両者とも20以上のプロバイダーとOpenAI互換APIをサポートしています。
00:10:59Open CodeはVercel AI SDKを使用しているため、エコシステムの成長に合わせて新しいプロバイダーを自動で取り込めます。
00:11:06Piは独自のPi-iライブラリを構築しており、制御性は高いですが、新しいプロバイダーの追加には手動作業が必要です。
00:11:12実際には、主要なプロバイダーはどちらも網羅されています。エージェントモデルについては、
00:11:18どちらも主要なプロバイダーを網羅しています。エージェントモデルについては、
00:11:22Open Codeは複数の特化型エージェントを搭載し、キー一つで切り替えられます。
00:11:27Piは単一エージェントで、「サブエージェントが欲しければ拡張機能で作るか別インスタンスを立てろ」という立場です。
00:11:33最初から特化モードを使いたいならOpen Codeの勝ちです。
00:11:37自分でエージェント構成を構築したいなら、Piがその道具を提供してくれます。
00:11:42Open CodeはSQLite、PiはJSONLファイルを使用します。
00:11:47SQLiteは整合性とクエリ効率に優れます。JSONLはcatやgrepで読める可視性があり、
00:11:53Piの単一ファイル内ツリー構造はエレガントです。両者ともセッションの分岐をサポートしていますが、
00:11:58Piの単一ファイル内のツリー構造はエレガントです。両者ともセッション
00:12:04Piのツリーナビゲーションは、会話履歴の探索において特によく設計されています。
00:12:08Open Codeには、承認ダイアログやファイルごとのルール、権限の記憶を備えた包括的なシステムがあります。
00:12:13承認ダイアログやファイルごとのルール、永続的な権限管理を備えた組み込みシステム。
00:12:19Piのコアには権限システムがなく、拡張機能で対応することを想定しています。
00:12:25すぐにガードレールが欲しいならOpen Codeが安全です。コンテナ内で動かすか、
00:12:30セキュリティモデルを完全に制御したいなら、Piのアプローチの方が柔軟です。
00:12:35MCPサポートについて。Open CodeはOAuthや自動ツール登録を含むフル機能を備えています。
00:12:41PiはコアでのMCP採用を明確に拒否し、README付きのCLIツールである「スキル」を推奨しています。
00:12:48コアでは採用せず、READMEで文書化されたCLIツールである「スキル」を推奨します。
00:12:54Mario Zeckner氏は、単純なCLIツールとREADMEがあれば同じ目的を
00:13:00達成できるのに、MCPは複雑さを増すだけだとブログで主張しています。
00:13:04MCPサーバーに依存しているなら、Open Codeが明白な選択です。Unixの
00:13:10Unix哲学を好むなら、Piの方がしっくりくるでしょう。コードインテリジェンスに関しては、
00:13:16Open CodeはLSP統合により、型情報や定義にアクセスできます。PiはコアにLSPを含みません。
00:13:22型情報や定義、参照へのアクセスが可能です。PiのコアにLSPは含まれません。
00:13:28これは、型コンテキストが理解を助ける静的型付け言語において、Open Codeの大きな強みになります。
00:13:32型コンテキストがAIの理解を助ける静的型付け言語において有利です。
00:13:37ターミナルインターフェース。どちらも洗練されたカスタムTUIを実装していますが、作りは別物です。
00:13:42Open CodeはSolid.jsとOpenIDフレームワークを使用し、Piは独自の差分レンダリングフレームワークを使用しています。
00:13:48どちらも見栄えが良く、レスポンスも良好です。Open CodeはデスクトップアプリやWebコンソールも提供しますが、
00:13:53レスポンスも良好です。Open CodeはさらにTauriベースのデスクトップ
00:13:58Piはターミナル専用であることを誇りにしています。両者ともプロジェクト単位とグローバル単位の
00:14:03JSONベース設定を使用します。Open Codeはコメントが書けるJSONCを採用しており、
00:14:07プロジェクトおよびグローバルの設定。Open CodeはJSONC（コメント付きJSON）を、
00:14:14これは嬉しい配慮です。Piは標準のJSONです。Open Codeの設定は項目が多い分複雑ですが、
00:14:19使用。どちらもモデルやツール、挙動の広範なカスタマイズが可能です。Open Codeは
00:14:26Piは組み込み機能が少ないためシンプルです。さて、どちらを選ぶべきでしょうか？
00:14:31組み込み機能が少ないためシンプルです。さて、どちらを選ぶべきか
00:14:35自分自身にこう問いかけてみてください。「最初から多機能なツールが欲しいか？それとも自分で構築したいか？」
00:14:39最初から多機能なツールがいいですか？それとも自分で構築したいですか？
00:14:455分でインストールして、権限、マルチエージェント、MCP、LSPが揃った洗練された体験をしたいなら、
00:14:49Open Codeが最適です。最小限のコアを自分好みにカスタマイズし、TypeScriptで拡張機能を書くのが苦でないなら、
00:14:56設計されています。最小限のコアを自分好みにカスタマイズしたいなら、
00:15:01Piがあなたのために作られたツールです。MCPはどの程度重要ですか？
00:15:06すでにMCPサーバーを使っている、あるいは使う予定があるなら、Open Codeがネイティブにサポートしています。
00:15:11予定があるなら、Open Codeはネイティブ対応しています。Piはあえて採用せず、
00:15:16主に静的型付け言語で開発しますか？Open CodeのLSPサポートによる深い理解は、
00:15:22開発しますか？Open CodeのLSP統合は、AIに豊かなコード理解を与えます。
00:15:28TypeScript、Go、Rustなどの言語で威力を発揮します。Pythonなどであれば、この差は小さくなります。
00:15:34Pythonや動的型付け言語を主に使う場合、この利点は小さくなります。
00:15:39デスクトップアプリやWeb画面は必要ですか？Open Codeはそれらを提供しますが、
00:15:44Piはターミナル一筋です。信頼性とサンドボックスについてはどう考えますか？
00:15:51危険な操作の前にエージェントに確認してほしいなら、Open Codeの権限システムが役立ちます。
00:15:55危険な操作の前に承認が必要なら、Open Codeの権限システムが標準で対応します。
00:16:00エージェント全体をDockerで動かし、その中で自由にやらせたいなら、Piの「権限なし」アプローチが合っています。
00:16:04サンドボックス内で自由に動かしたいなら、Piの「権限なし」方針が適しています。
00:16:10すべてをカスタマイズしたいパワーユーザーですか？Piの拡張システムは驚くほど強力です。
00:16:15Piの拡張システムは非常に強力です。事実上あらゆる
00:16:20ツールの実行からセッション管理、TUIまで、エージェントの挙動をほぼすべて変更できます。
00:16:25Open Codeにもプラグインはありますが、挙動の完全な上書きというよりは特定のフックに重点を置いています。
00:16:30率直な結論を言えば、Open Codeの方が現時点ではより成熟し、機能も充実した製品です。
00:16:34正直な結論です。Open Codeは現時点でより成熟し、多機能な製品です。
00:16:40より多くの外部システムと統合でき、導入のハードルも低いです。オープンソースのAIエージェントを求める
00:16:44多くの開発者にとって、Open Codeはより無難で確実な選択肢です。
00:16:49Piは、より興味深い設計と言えます。徹底したミニマリズムと拡張優先の哲学は、他にはない適応性を生んでいます。
00:16:55徹底したミニマリズムと拡張優先の哲学は、独自の適応性を生んでいます。もし
00:17:01Neovimの設定を何週間もいじるタイプの人や、自分の理想通りに動くエージェントが欲しい人にとって、
00:17:05コードを書く前に準備するタイプの人で、自分の思い通りに動くエージェントが欲しいなら、
00:17:09Piは投資に見合う価値があり、そのセッションツリーナビゲーションは間違いなくクラス最高です。
00:17:14どちらもMITライセンスで活発にメンテナンスされており、同じ広範なLLMプロバイダーをサポートしています。
00:17:20午後のひとときを使って両方を試すことができます。コードはGitHubにあり、始めるのにサブスクリプションも不要です。
00:17:27試せます。コードはGitHubにあり、どちらも使い始めるのにサブスクリプションは不要です。
00:17:31インストールして同じコードベースで走らせ、自分の仕事スタイルにどちらがハマるか確かめてみてください。
00:17:37それこそが、唯一本当に意味のある比較なのです。
Community Posts
No posts yet. Be the first to write about this video!
Write about this video