AIプログラミングをPiで始める：1.0の導入・料金・最初のタスク

Piなら、モデルを動かすエージェントの仕組みを自分で整えられます

Piは、モデルとファイルやコマンドをつなぐ最小限のエージェントハーネスです。作業台をイメージすると分かりやすいでしょう。何をするかは選んだモデルが判断し、その実行に必要な道具をPiが提供します。

標準で有効な4つの組み込みツールが、基本的な作業の流れを支えます。

モデルがツールの実行を要求すると、Piが実行し、結果を会話に戻します。タスクが終わるまで、この流れを繰り返せます。ここで挙げたのは標準で有効な4つのツールであり、1.0で利用できる組み込みツールすべての一覧ではありません。Piのツールリファレンス、エージェントの実行ループ。

すでにClaude CodeやCodexを使っているなら、どのワークフローを自分で管理したいかを基準にPiを評価してください。私が勧めるのは、リポジトリ専用のレビューコマンドや、繰り返し使える移行スキルなど、具体的に実現したいカスタマイズがある場合です。ほかの候補も比較したい方は、モデルを選べるコーディングエージェントをご覧ください。

Pi 1.0で変わったターミナル操作とツール連携

1.0.0では全画面表示が標準になり、codemodeとサインインも改善されました。TUIは、ターミナル内に描画されるユーザーインターフェースです。導入時に押さえておきたい変更は次のとおりです。

MCPは、エージェントを外部ツールにつなぐ仕組みです。OAuthは、ツールにパスワードを渡さずにアクセスを許可するサインインの仕組みを指します。codemodeでは、モデルがJavaScriptでツール呼び出しを組み立て、選んだ結果を会話に戻せます。プロンプトの削減はこの仕組みに対するもので、どのタスクでも料金が40%下がるという意味ではありません。Pi 1.0.0のリリースノート、codemodeのリファレンス。

同じリリースで、codemodeのスクリプトからの画像生成、/loginでのRadiusへの対応、quietStartup: "header"も追加されました。最初のコーディングタスクでは、これらは後回しにして構いません。リリースノート。

AIプログラミングをPiで始める：28分で導入から最初のタスクまで

使い慣れたリポジトリ、動作するテストコマンド、対応モデルへのアクセスを用意してください。以下の時間配分は目安です。ダウンロード、サインイン、テストにかかる時間は環境によって変わります。セッションを終える前に変更内容を確認できる、小さなタスクを選びましょう。

0〜5分：インストールしてプロジェクトを開く

プロジェクトが案内するnpmでのインストールには、Node.js 22.19以降が必要です。次のコマンドではPiを1.0.0に固定し、この記事で扱うリリースと手順をそろえています。

node --version
npm install -g --ignore-scripts @earendil-works/pi-coding-agent@1.0.0
pi --version
cd /path/to/project
pi --tui-mode regular

/path/to/projectを作業フォルダーのパスに置き換えてください。pi --versionで1.0.0と表示されることを確認します。単にpiを実行すると、新しい標準設定の全画面表示で起動します。macOS/Linuxでは、公式の別の導入方法としてcurl -fsSL https://pi.dev/install.sh | shも用意されています。こちらは現行リリースをインストールします。プロジェクトのインストール手順、クイックスタート。

5〜10分：手持ちのアカウントを接続する

Pi内で/loginを実行し、プロバイダーを選んで、提示された認証方法で接続します。続けて/modelを実行し、利用可能なモデルを選びます。プロバイダーはモデルへのアクセス経路、モデルは実際に応答を生成するシステムです。

Piの認証ドキュメントには、AnthropicのサブスクリプションとOpenAIのSign in with ChatGPTによる接続が記載されています。OpenAIは、アカウントの利用条件を満たす場合に、対象リクエストでプランの利用枠を使うことを認めています。APIキーを選ぶ場合は、これとは別の料金体系になります。PiのOAuthプロバイダー、OpenAIのサインインドキュメント。

Piの公式サイトには、Anthropic、OpenAI、Google、OpenRouter、Ollamaなどが挙げられています。プロバイダーに対応していても、すべてのアカウントですべてのモデルが表示されるわけではありません。モデルが見つからない場合は、まず認証を確認してください。/modelには、利用可能な認証情報があるモデルが表示されます。選択画面でCtrl+Sを押すと、標準で使うモデルを保存できます。モデル選択のドキュメント。

Ollamaを使う場合は、~/.pi/agent/models.jsonにプロジェクトの互換エンドポイントの設定例を反映します。この例は、http://localhost:11434/v1、APIタイプopenai-completions、ダミーキーollama、手元の環境で提供しているモデルIDを使います。/modelを開くと、このファイルが再読み込みされます。有料のモデルアカウントを使わずにPiを試したい場合は、このローカル経由の方法が選べます。

10〜13分：リポジトリの作業ルールをPiに伝える

リポジトリのルートに短いAGENTS.mdを追加するか、すでに管理しているものに追記します。Piは~/.pi/agent/、親ディレクトリ、現在のディレクトリから指示を読み込みます。セッション中に変更した場合は、/reloadを実行してください。設定のドキュメント。

指示には、実際のリポジトリに即した内容を書きます。たとえば、次のようなものです。

Use the existing test runner and neighboring test conventions.
Keep this task within the function and tests I name.
Do not add dependencies or change the public API.
Run the focused tests and report the exact command and result.
Leave commits and publishing to me.

対象を絞ったテストコマンドが分かっているなら、その実際のコマンドも加えてください。AGENTS.mdはモデルの行動を導く指示であり、権限の境界を強制する仕組みではありません。

13〜23分：小さくても役立つ変更をひとつ行う

空の入力に対する動作が定義されているのに、回帰テストがまだない既存のヘルパーを選びます。Piのファイル選択機能@で、そのヘルパーと近くにあるテストを添付し、次のタスクを依頼してください。

回帰テストは、期待する動作が後の変更で壊れるのを防ぐためのものです。このタスクなら、アプリケーション全体の設計をPiに見直させずに、具体的な差分を得られます。クイックスタートでは、@によるファイル選択と、タスク後の変更ファイルの確認が説明されています。最初のタスクの手順。

23〜28分：変更とテスト結果を確かめる

変更されたテストを読み、ファイルの変更内容を示すgit diffを確認します。アサーションが期待する動作を検証していることを確かめたうえで、対象を絞ったテストコマンドを自分でも実行してください。テストの成功は変更を評価する材料になりますが、そのアサーションに意味があるか、変更範囲が適切かを判断するのは自分です。

初回の到達点はシンプルです。選んだプロバイダーが使えたこと、Piが意図した変更を行ったこと、そして自分で差分を説明できることです。カスタマイズは次のセッションに回しましょう。

Piのライセンス料は無料。支払いを決めるのはモデルの利用量です

PiのMITライセンスでは、ソフトウェアの利用席ごとの料金はかかりません。サブスクリプション経由なら、そのプランが提供する利用枠を消費します。APIキーを使えば、プロバイダーの従量課金が発生します。ローカルモデルの場合は、ハードウェアと運用に費用が移ります。

APIの計算例を見てみましょう。OpenAIのGPT-6.1 Solは、標準の短いコンテキストでの利用料金が入力100万トークンあたり$2、出力100万トークンあたり$10です。トークンは、課金のために数えるコンテンツの単位です。OpenAIの公式料金。

小さなタスクで、複数のリクエストの利用量が次の合計になったと仮定します。

これは計算方法を示す例で、実測したタスクの利用量ではありません。標準処理を使い、各リクエストの入力が272,000トークン以下で、キャッシュへの書き込みや別途課金されるツールがないことを前提としています。キャッシュされた入力、キャッシュへの書き込み、より長いリクエスト、ほかの処理区分では料金が異なります。まったく同じ利用パターンで100件のタスクを実行すると、モデルの基本料金は$30になります。GPT-6.1 Solの料金詳細。

予算を考える際の判断軸は、実現したいカスタマイズに、それを保守するだけの価値があるかどうかです。Piならハーネスのライセンス料は不要ですが、モデルの利用料、人によるレビュー、ワークフローを支える開発・保守の時間は必要です。

ワークフローの拡張は、必要な仕組みから始めましょう

作業の規約は指示に、繰り返す手順はスキルに、実行可能な機能は拡張機能にまとめます。

スキルのSKILL.mdは、名前と説明から始まります。特定のスキルを明示的に読み込むには、/skill:nameを使います。拡張機能はPiのプロセス内で実行されるため、読み込む前にコードを確認してください。スキル、拡張機能。

pi install ./local-packageで、手元に用意したパッケージをインストールできます。公開されているパッケージには、実際の名前とバージョンを指定してpi install npm:@scope/package@versionを使います。--localを追加すると、プロジェクト単位のパッケージ宣言が.pi/settings.jsonに記録されます。セッション中にリソースを変更したら、/reloadを実行してください。パッケージのドキュメント。

外部のMCPサービスを使う場合は、そのサーバーを設定し、OAuthが必要なら/mcp login <server>を使います。まずは基本の環境が動くことを確認し、その後で追加しましょう。MCPのドキュメント。

実務で役立つ6つの使い方：効果を見込める順に

最も有効な出発点は、自分がよく理解しているリポジトリで繰り返し発生する作業です。以下はワークフローの提案であり、効果はコードベースとレビューの進め方によって変わります。

1. 報告されたバグに回帰テストを追加する。 サブスクリプション型のWebアプリを保守する創業者なら、バグの再現手順、実装、テストを添付し、失敗するテストと範囲を絞った修正をPiに依頼して、関連するチェックを再実行する使い方が考えられます。確認できた不具合を、継続して検証できるテストに残せる点に価値があります。
2. プルリクエストを開く前に変更をレビューする。 開発者なら、ローカルの差分とリポジトリ用のレビュースキルをPiに渡し、問題になりそうな箇所をファイルへの参照と説明付きで挙げるよう依頼できます。具体的な問題をレビュー前に見つけられれば、やり取りをひと往復減らせる可能性があります。
3. アプリケーションの一部を範囲を決めて移行する。 保守担当者なら、移行手順をスキルにまとめ、ひとつのモジュールに適用してチェックを実行できます。同様のモジュールで手順を再利用しつつ、差分は毎回レビューすることで、作業時間の削減が期待できます。
4. 初めて触るリポジトリの仕組みを理解する。 新しく参加したエンジニアなら、ひとつのリクエストが入口からストレージに届くまでをPiにたどらせ、ファイルへの参照と関連するチェックコマンドをメモとして残せます。そのメモがあれば、環境や仕組みについて同じ質問を繰り返す回数を減らせるかもしれません。
5. 小さな保守スクリプトを作る。 古くなったフィクスチャを管理する担当者なら、Piにスクリプトの草案を作らせ、サンプル入力で動作を確認し、使い方を文書化できます。レビュー済みのスクリプトで、繰り返しの手作業を置き換えられる可能性があります。
6. 社内の開発ワークフローを作る。 技術リーダーなら、独自のコマンドとスキルをパッケージにまとめられます。また、単発のコマンドにはprintモード、別プロセスの制御にはRPC、アプリケーションへのセッションの組み込みにはSDKライブラリを使ってPiを連携させる方法もあります。繰り返し発生する仕事にエージェントを合わせられる点が利点で、連携の実装とサポートは技術リーダーが担います。連携用インターフェース。

開発して提供するなら、リポジトリ専用のレビュー機能が有力です

最も事業化を考えやすいのは、マージ前のレビューを行うパッケージです。同じ作業が繰り返され、購入する側もレビューの遅延による負担をすでに理解しているためです。小規模な開発チームなら、自分たちの規約をチェックし、レビュアーに判断材料を渡せる、保守付きのパッケージに料金を払う可能性があります。

需要調査では、「ai code review」の米国Google推定月間検索数は1,300件でした。料金の比較基準として、CodeRabbit Essentialsは年間払いで開発者1人あたり月額$24、月間払いなら$30です。これらはコードレビューへの関心と、すでに有料サービスの市場があることを示しています。ただし、Piのパッケージに需要があると証明するものではありません。検索数はDataForSEOのキーワード概要で2026年10月3日に確認した値です。CodeRabbitの料金。

販売できる最小限の構成としては、レビュースキル、ローカルの差分を集めるコマンド、リポジトリ専用のチェック、ファイルへの参照を含むレポートが考えられます。最初はローカルで動く形で提供しましょう。課題は差別化です。汎用的なプロンプトは簡単にコピーできますし、Piのパッケージには保守、アクセス制御、サポートが必要です。売るべき価値は、リポジトリをチェックする仕組みの質と、その継続的な保守です。

次の候補は、チーム向けのスターターパッケージです。開発チームのリーダーなら、プロバイダー設定、AGENTS.md、共有スキル、少数の承認済み拡張機能をそろえるための導入と保守を購入する可能性があります。同じ日のDataForSEOによる需要調査では、「open source ai coding assistant」の米国推定月間検索数は1,600件でした。初期版は、ひとつのパッケージと、ひとつのチームのリポジトリを対象にした導入手順で構成できます。ただし、検索されていることと、インストールにお金を払ってもらえることは別です。継続的な価値を提供するには、チームのワークフローを保守し続けることが必要です。

標準設定の設計や保守を担いたくないチームには、Piは向きません

権限確認、隔離、標準化されたワークフローを、サポートのある製品として用意してほしいなら、運営側が管理するツールを選びましょう。Piのツールは、Piを起動したプロセスの権限で動きます。プロジェクトの信頼設定は、読み込むプロジェクトリソースを制御しますが、ツール呼び出しをサンドボックスで隔離するものではありません。作業フォルダーを指定しても、コマンドがほかのアクセス可能なパスに到達することは防げません。Piのセキュリティモデル。

拡張機能で確認のフローやパスの保護を追加でき、コンテナーでOSレベルの境界を設けることもできます。ただし、いずれもチームに実装と保守の作業が発生します。codemodeのJavaScriptサンドボックスも、呼び出したツールの権限を制限するものではありません。拡張機能でできること、codemode。

Piは、組み込みのサブエージェントやプランモードもコアに含めていません。私の評価では、小さな土台を自分の用途に合わせて作り込みたい開発者には、良い割り切りです。一方、その設計判断をほかの人に任せたいチームには向きません。プロジェクトの設計方針。

月曜日には、自分が保守するリポジトリで、範囲を絞ったバグ対応かテストのタスクをひとつPiに任せてみてください。差分とテスト結果を残し、繰り返す手順のうち、どれをスキルにする価値があるか考えましょう。チーム専用のワークフローを構築したい場合は、AIエージェント開発から始められます。