Pi(pi-coding-agent)をローカルLLMで動かす設定手順と実用ラインを解説
Pi(pi-coding-agent)は、libGDXの開発者Mario Zechner氏が公開しているオープンソースのターミナル型コーディングエージェントです。MITライセンスで無料、しかもAnthropicやOpenAIだけでなくOllamaやllama.cppといったローカルLLM基盤にも接続できるため、API課金ゼロ・機密コードを外部に出さない構成を組めます。本記事では、PiとローカルLLMを接続する具体的な設定手順、モデル選定の基準、実測性能の目安、そして商用エージェントとの使い分け判断までを整理します。
目次
まとめ:PiとローカルLLMは無料で動くが用途の見極めが成否の分岐点
結論から言うと、PiをローカルLLMで動かす構成は2026年時点で十分に実用段階です。VRAM 6GBの旧世代GPUでもMoE型モデルなら動作し、設定はmodels.jsonへの数行の記述で完了します。API利用料はゼロ、コードが社外に出ることもありません。
ただし万能ではありません。出力速度は商用APIより遅く、長いコンテキストでは顕著に低下します。実装の主戦力ではなく「レビュー・ドキュメント生成・サブ機能を並行で任せる補助役」と割り切るのが現実的な使い方です。本文では設定手順と、採用すべきでない場面の判断基準まで踏み込んで解説します。
Pi(pi-coding-agent)の概要とコアツール4種に絞った設計思想
Piは「完成品のエージェント」ではなく、自分の環境に合わせて組み替える前提のエージェントハーネスです。まず全体像を押さえます。
read・write・edit・bashの4ツール構成が生む軽さと拡張性
Piのコアツールはread・write・edit・bashの4種類だけです。Claude Codeが標準搭載するサブエージェントやプランモードは持たず、システムプロンプトも最小限に抑えられています。この割り切りがトークン効率に直結し、性能に限りのあるローカルLLMでも動かしやすい土台になっています。
足りない機能は拡張で補います。TypeScript製の拡張機能(Extensions)、必要時にだけ読み込まれるスキル、プロンプトテンプレートという3層の仕組みがあり、pi install npm:@foo/pi-toolsのようにnpmやGitHubからパッケージとして導入できます。権限ゲートやMCP連携も、この拡張の形で後付けする設計です。
MITライセンス・npm配布で始める導入と対応プロバイダーの範囲
導入はnpm install -g --ignore-scripts @earendil-works/pi-coding-agentの1コマンド、またはpi.devのインストールスクリプトで完了します。ソースコードはGitHubのearendil-works/piリポジトリで公開されており、ライセンス費用や座席課金はありません。発生するコストは接続先モデルの利用料だけです。
対応プロバイダーはAnthropic・OpenAI・Google・Azure・Bedrock・Mistral・Groq・xAI・OpenRouter・Ollamaなど20以上に及びます。世の中の「OpenAI互換API」には、思考モードの指定方法やmax_tokensの扱いなど細かな非互換が無数にありますが、Piは15種類以上のcompatフラグでこの差異を吸収し、URLやモデル名から特性を自動検出したうえで設定ファイルによる上書きも許します。ローカルLLMサーバーへの接続が安定しやすいのは、この互換レイヤーの作り込みによるものです。
OllamaとPiを接続する設定手順とローカルモデル選定の3条件
最も手軽なローカル構成はOllamaとの組み合わせです。設定ファイル2つで接続が完了します。
models.jsonとsettings.jsonに書く接続設定の具体的な記述内容
Ollamaを起動した状態で、~/.pi/agent/models.jsonにプロバイダー定義を書きます。公式ドキュメントに示されている記述は次の通りです。
baseUrlにhttp://localhost:11434/v1を指定するapiにopenai-completionsを指定するapiKeyはダミー値(例:ollama)で構わないmodels配列にqwen3-coderなど使用モデルのIDを列挙する
続けて~/.pi/agent/settings.jsonにdefaultProviderとdefaultModelを書けば、次回起動時からローカルモデルが既定になります。セッション中は/modelコマンドやCtrl+Lでモデルを切り替えられるため、軽い作業はローカル、難しい局面だけ商用モデルという運用も1セッション内で完結します。
function calling対応と文脈長で絞るローカルモデル選定の判断基準
エージェント用途のローカルモデル選定では、ベンチマークスコアより先に確認すべき条件が3つあります。ツール呼び出し(function calling)への対応、エージェントの履歴膨張に耐える128K以上のコンテキスト長、そしてツール引数を壊さない安定したJSON出力です。この3条件を満たす代表格がQwen3系・gpt-oss系・Gemma 4系で、いずれもQ4量子化でも実用上の問題は少ないとされています。
コーディング特化ならQwen3-Coder系が第一候補です。モデルの系譜や商用利用条件はQwen3の特徴とモデル一覧の解説で整理しています。OpenAIのオープンウェイトモデルを試すなら、必要GPUとベンチマークをgpt-oss-120bと20bの比較記事で確認してから選ぶと失敗が減ります。
llama.cpp(llama-server)で動かす接続の仕組みと実測性能の目安
GPUメモリが少ない環境や、量子化を細かく制御したい場合はllama.cppを直接使います。PiはこのケースをOllamaと同等に扱えます。
llama-server接続先の探索順序と/modelsコマンドでの切り替え
Piはllama-serverの接続先を、プロジェクト直下の.pi/llama-server.json、環境変数LLAMA_SERVER_URL、~/.pi/agent/settings.json、既定値http://127.0.0.1:8080の順で探索します。llama-serverをオプションなしで起動していれば既定ポートのまま認識され、追加設定なしで使い始められます。
複数モデルを立ち上げている場合は、Pi内の/modelsコマンドでロード中のモデル一覧を表示し、その場で切り替えられます。llama-serverはOpenAI互換APIを提供するため、前章のmodels.json方式で明示的にプロバイダー登録する方法も併用できます。
VRAM 6GBの旧世代GPUで動いた構成と入出力速度の実測値
2026年6月公開の検証記録では、GTX 1660 Super(VRAM 6GB)とRAM 32GBという旧世代構成で、MoE型のQwen3.6-35B-A3B(Q4量子化)が実用速度で動作しています。MoEモデルは推論時に一部のエキスパートだけを動かすため、エキスパート重みをCPU側メモリへ逃がす設定と組み合わせれば、VRAMが小さくても35Bクラスを扱えます。
同検証での速度は入力処理が毎秒約75トークン、生成が毎秒約20トークンでした。コンテキストが3万トークンを超えると体感で遅くなると報告されており、「爆速で主実装を任せる」より「自分が実装している間にレビューやドキュメント作成を並行で任せる」使い方が現実的です。Apple Silicon環境でも、M1 ProでQwen系9BモデルのQ4を使い、14ファイル・約750行のマージリクエストをレビューさせた事例が公開されています。
商用エージェントとの使い分け判断とPiを採用すべきでない場面
PiとローカルLLMの組み合わせは「安くて閉じている」一方、明確な弱点があります。導入判断はここで決まります。
知識量・生成速度の限界とローカル検索基盤で補完する実装パターン
ローカルLLMは学習知識が固定されているため、最新ライブラリの仕様変更や新しいバグの解決策を知らないことが多い点が構造的な弱点です。この穴は検索で埋めます。公開事例では、メタ検索エンジンSearXNGとHTML整形ツールCrawl4AIをDockerで自前運用し、Piのスキルとして検索・クロール手順を定義することで、外部の検索APIに一切データを渡さない調査基盤を成立させています。
もう1つの前提がサンドボックス化です。Pi本体はファイルやネットワークへのアクセスを制限する権限システムを持たず、起動ユーザーの権限のままコマンドを実行します。公式リポジトリもコンテナ化やサンドボックスでの隔離を推奨しており、実務ではDockerで専用UIDを切り、ネットワークを内部ブリッジに閉じる構成が定石です。この隔離を省いたまま社内マシンで走らせるのは避けるべき失敗パターンと言えます。
Claude Code・Codex CLIとの比較で見える採用判断の分岐点
主要なターミナル型エージェントとの違いを整理します。
| 観点 | Pi | Claude Code | Codex CLI |
|---|---|---|---|
| 接続モデル | 20以上・ローカル可 | Claude系が前提 | OpenAI系が前提 |
| 費用 | 本体無料+モデル費 | サブスク/API課金 | サブスク/API課金 |
| 標準機能 | 4ツールのみ | サブエージェント等豊富 | 実行環境が充実 |
| 拡張方法 | 拡張・スキルで自作 | 公式機能中心 | 公式機能中心 |
| 権限制御 | 標準では非搭載 | 許可プロンプト標準 | サンドボックス標準 |
判断の軸は「モデルの自由度を取るか、完成度を取るか」です。チームの主戦力エージェントとして大規模実装を任せるなら、標準機能と権限制御が揃ったClaude CodeやCodex CLIの機能解説で紹介している構成が向きます。逆に、機密コードを外部へ出せない案件、定型処理をシェルスクリプトに組み込みたい場面、モデルを跨いだ検証環境が欲しい場合はPiが有力です。プログラムからエージェントループを呼び出す用途なら、Claude Code SDKの解説記事と比較すると設計思想の違いが分かります。
なお、ローカルLLMを前提にした開発環境の設計や、社内データを外に出さない生成AIシステムの構築は、要件定義の段階から専門知見が要る領域です。株式会社一創ではAI開発の受託支援として、LLM選定からエージェント組み込み、セキュリティ設計までを一貫して支援しています。
Pi(pi-coding-agent)とローカルLLMに関するよくある質問
導入前に確認されることが多い5つの疑問に答えます。
Pi(pi-coding-agent)は無料で使えますか?
Pi本体はMITライセンスのオープンソースで、ライセンス費用や座席課金はありません。発生するのは接続先モデルの費用のみで、Ollamaやllama.cppでローカルLLMを使えばモデル費用もゼロになります。商用APIに接続する場合は、そのプロバイダーのAPI料金またはサブスクリプション費用がかかります。
ローカルLLMでコーディングに使うモデルは何を基準に選べばよいですか?
function calling対応・128K以上のコンテキスト長・安定したJSON出力の3条件を優先します。この条件を満たすQwen3-Coder系、gpt-oss系、Gemma 4系が有力候補です。VRAMが8GB未満ならMoE型の量子化モデル(Q4クラス)を選び、エキスパート重みをCPUメモリへオフロードする構成にすると動作範囲が広がります。
PiとClaude Codeはどちらを使うべきですか?
大規模な実装をエージェント主導で進めるなら、サブエージェントや権限制御が標準で揃うClaude Codeが向きます。Piが勝るのは、ローカルLLMを含む多様なモデルを1つのCLIで切り替えたい場合、シェルスクリプトへの組み込みなどスクリプタブルな用途、コストを抑えた検証環境の3つです。併用も現実的な選択肢です。
PiはMCPサーバーに対応していますか?
MCP連携は標準搭載ではなく、拡張機能(Extensions)として追加する方式です。Piはサブエージェントやプランモードも含め、標準外の機能をTypeScript拡張やコミュニティパッケージで足す設計を取っています。必要な連携はPi自身に実装を指示して作らせることもできます。
どの程度のPCスペックがあれば実用できますか?
公開されている検証では、VRAM 6GBのGTX 1660 SuperとRAM 32GBの構成で35BクラスのMoEモデル(Q4量子化)が入力毎秒約75トークン・生成毎秒約20トークンで動作しました。Apple SiliconではM1 Proで9Bクラスの動作事例があります。快適さを求めるならVRAM 12GB以上、または統合メモリ32GB以上が目安です。
関連記事
- Qwen3とは?アリババのオープンLLMの特徴・モデル一覧・日本語性能・商用利用を解説:Piのローカル運用で第一候補になるQwen系モデルの選び方
- gpt-oss-120bの性能とは?20bとの違い・ベンチマーク・必要GPUを徹底比較【OpenAI公式】:OpenAI系オープンウェイトをローカルで動かす際のGPU要件
- Codex CLIが持つ主な特徴と高度な機能の詳細解説:Piとの使い分け判断で比較対象になる主要エージェント
- Claude Code SDKとは?特徴やClaude Codeとの違いを解説:エージェントループをプログラムに組み込む際の比較先
- Claude Code 2.1.7とは何か?最新アップデートの概要と徹底解説【2026年最新情報】:商用エージェント側の最新機能動向