Pi.devの設定を爆速で！シンプルかつ強力なベストプラクティスを解説

Pi.devの設定、迷っていませんか？シンプルで扱いやすく、かつ玄人好みの構成方法をまとめました。効率的な開発環境を今すぐ整えましょう。

一方で、デフォルトのインストールでスキルや拡張機能を使ってあれこれ盛り込むのがダメってわけじゃない。でも、自分はPiの「ミニマルさ」こそが好きなんです。エージェント的なコーディング環境を一番シンプルな形で理解して使いこなし、問題点を見つけ、プロンプトのスキルも向上させたい。しかもそれをローカルLLMで全部やりたいんだよね。基礎を理解しないまま進めてたら、結局自分が何をやってるか深く考えずに先送りしてるだけにならないかな？もちろん、エージェントコーディングをどうやるかは個人の自由。みんなが幸せで生産的になれる方法を選ぶのが一番だよ。

Piってのは、自分が何をやってるかをあえて考えさせるためのものだろ。ページにあるマリオの引用にもある通り、これを使うのはその趣旨を台無しにしてるし、使う価値がないよ。「Less is more（少ない方が豊か）」をもっと試すべき。最近のモデルは十分賢いんだから、昔みたいに何十個もMCPやスキルでコンテキストを埋め尽くす必要はないよ。しっかりしたヘルプとエラーメッセージが組み込まれたCLIツールなら、モデルも驚くほど簡単に理解してくれるしね。もしPiがミニマルすぎて自分でいじるのが面倒なら、OpenCodeが最初からかなり優秀だよ。Piを設定してない環境での作業にはそれを使ってる。OpenCodeに加えてるのは、頻繁に使うプロンプトを省略できるコマンドと、変更を実装するために固定モデルを使うサブエージェントくらいかな。

これ、Piの本来の目的を完全に台無しにしてるね。

Piの開発陣は、コアとなるエージェントを削ぎ落として、サブエージェントのような機能に、名もなき誰かが書いたプラグインを読み込ませるようにしてしまった時点で、サプライチェーン的なミスを犯したんじゃないかな。

今はOh My Pi (https://github.com/can1357/oh-my-pi) を使ってるけど、全部入りってアプローチはありがたいよ。素のPiを少し使ってみた感じでは、プラグインの多くがいまいちで、自分で更新・修正して維持したいとは思わなかったんだよね。まあ、他の人は違う意見かもしれないけど。Piをミニマルに保ちつつ、「公式」の高品質なオプションプラグインを用意して使いやすくする、っていう方向性ならいいと思う。

自分もしばらくoh-my-piを使ってるけど、すごく満足してる。自分でPi環境を一から作り上げる気がないなら、あえてこれを選ばずにoh-my-piを使わない理由がわからないな。

これ、Piのアンチテーゼみたいだな。本来はミニマルな状態で自分好みにカスタマイズしていくものなのに。素のVim/neovimと、最初からいろいろ詰め込んだVimの「ディストリビューション」の間で起きる摩擦と似たようなものかな。

みんな今どんなAGENTS.mdやスキルを頼りにしてるの？自分はほとんど使ってないけど、Claude Code、Codex、Shelleyを使ってフルスタックなGoアプリを構築できてるよ。どれもカオスなブラックボックスから単純なbashのラッパーまで幅広くカバーしてるしね。やっぱり、モデル自身が何をすべきかをどんどん学習して改善してるんだと思う。むしろ、自分のコードベースの「Developer Experience (DX)」を改善することに力を入れてるよ。標準的なGoのツールセット、慣用的なGoの書き方、しっかり設計されたテストハーネス、リントを強制するGitHub Actionsとかね。結局、どんなマークダウンの指示書よりもその方がうまくいく気がする。

60個以上も！いやあ、面白いけどやりすぎな気がする。自分ならそのスキル全部を完璧に把握しておきたいな。でも、他の人がどんな拡張機能を使ってるか覗き見できるこういうプロジェクトは好きだよ。昔の.vimrcファイルみたいでさ。盲目的にコピペするんじゃなくて、見て学んで必要なものだけを取り入れるのが正解だね。

「自分だけのPiを構築する」という設定作業が大変で圧倒される人がいるのはわかる。それがPiの醍醐味の一つでもあるんだけど、Vimと同じで、しばらくこれで遊んだら、また素のPiに戻って「自分に何が必要か」を見極めてから、段階的に追加していくことを勧めるよ。インクリメンタルに管理する力はすごいよ。新しい依存関係をどんどん増やすんじゃなくて、自分の行きたい方向に進み続けることができるからね。