2026年3月時点で個人的な使用感をTierList風にまとめてみた。
この記事が、皆様の『GSD(Get Shit Done)』を加速させる一助となれば幸いです。
| Tier | 共通 | opencode | pi coding agent | gemini-cli |
|---|---|---|---|---|
| S |
rtkplannotator
|
|||
| A | spec-kit |
opencode-dcp |
pi-guardrailspi-rewindpi-powerline-footerpi-extmgr |
gemini-cli-security |
| B | true-mem |
oh-pi-themes |
superpowers |
|
| C | oh-my-opencode-slim |
|||
| D |
rtk : LLMのトークン消費を大幅削減
ある程度日々コーディングエージェントを利用していると、サブスクのレートリミットやAPIの従量課金制のコストが割と大きな関心事になることも多い。最大コンテキストの壁に当たったりもする。
そこで、いかに消費トークンを減らしつつ効率的に運用するかが問題になる。
このツールは、コマンド出力をフィルタリング・圧縮して、LLMのトークン消費を大幅に削減する。
たまにコマンドが対応しておらず再試行するが、今の所ほぼデメリットもないので、かなり使い勝手がいい。
rust製、ClaudeCodeにも対応
追記: pi coding agent用のプラグインもある
plannotator : アノテーションでUX爆上がり
HTMLで出力された実装計画や提案された仕様の任意箇所にコメントし、ワンクリックで返答(OK/NG)を送り返すことが可能。
「ざっくりやりたいことを伝える → エージェントが計画を立ててくる → それをレビューして修正を指示する」という流れ自体は変わらないが、HTML出力された計画書なので読みやすく、アノテーション機能でこのサイクルが一気に効率化する。
特に pi coding agent は plan モード を内蔵していないため、このツールがほぼ必須級の立ち位置になる。「承認するまで手を動かすな」という制御と「どこをどう直せ」という指示を UI 上で完結できるのが大きい。
使い分けとしては、後述する spec-kit が 0→1 開発向けなのに対し、plannotator は既存コードへの小さめの修正をテンポよく回すのに向いている。
TypeScript製、ClaudeCodeにも対応
spec-kit : 仕様から実装まで一気通貫
ある程度の規模の機能を実装しようとすると、ざっくりした指示だけでは設計がすぐに崩れる。途中でリファクタが必要になったり、エージェントが意図とは違う方向に走り出すのは、仕様が曖昧なまま実装を始めているのが原因であることが多い。
このツールキットは、Spec-Driven Development(仕様駆動開発)を実践するための一式で、/speckit.constitution でプロジェクト原則を定め、/speckit.specify で仕様を書き、/speckit.plan→/speckit.tasks→/speckit.implement の順で実装まで進める流れを提供する。各フェーズが明確に分かれているため、エージェントに丸投げしても設計の軸がぶれにくい。
前述した plannotator が既存コードへの小さめの修正向けなのに対し、spec-kit はゼロから構造を設計する 0→1 開発や、大きめの機能追加 で真価を発揮する。
ClaudeCodeにも対応
opencode-dcp : opencode 専用のインテリジェントなコンテキスト圧縮
rtk と同様にトークン消費・コンテキスト枯渇の問題を狙ったツールだが、こちらは opencode 専用でより賢いコンテキスト管理に特化している。opencode 標準の compaction がセッション全体を機械的に圧縮するのに対し、このプラグインはタスク完了単位で圧縮対象をモデルに選ばせ、重複ツール呼び出しの除去や、エラーになったツール入力の自動刈り取りなども行う。
セッション履歴が書き換わらず、プレースホルダーで置き換える形なので安心感がある。opencode をメインで使うなら rtk と組み合わせて入れておきたい一本。
TypeScript製
pi coding agent + opencode 並の実用性
pi はミニマルな設計思想ゆえ、素の状態だと opencode と比べて機能が明らかに不足し痒いところに手が届かない。裏を返せば、エコシステム側でその差を埋められる。個人的には以下を揃えることで実用性がほぼ同等になった。どれも必須級。
-
pi-guardrailshttps://github.com/aliou/pi-guardrails —.envなどの秘匿ファイルへのアクセス保護と、rm -rf等の危険コマンド実行前の確認ゲートを追加する。 -
pi-rewindhttps://github.com/nicobailon/pi-rewind-hook — セッション中に自動チェックポイントを git refs で作成し、ファイル変更を任意の時点に巻き戻せる。 -
pi-powerline-footerhttps://github.com/nicobailon/pi-powerline-footer — Powerlevel10k 風のステータスバーと、モデル切り替えプロファイルをフッターに追加する。 -
pi-extmgrhttps://github.com/ayagmar/pi-extmgr — エクステンションの参照・インストール・有効化・削除を一元管理する UI。npm 検索やオートアップデートにも対応。 -
oh-pi-themeshttps://github.com/ifiokjr/oh-pi — エクステンション・テーマ・スキルをまとめてワンクリック設定できる、oh-my-zsh 的なセットアップキット。
インストール方法はどれも pi install npm:<パッケージ名>
一部インストール方法に違いがあった。各githubレポジトリにコマンド掲載あり。
true-mem : セッションをまたいだ記憶の永続化
「毎回同じ好みを伝えるのが面倒」という問題を解決するために、会話から自動でプリファレンスや決定事項を抽出し、次のセッションでも覚えている状態にしてくれる opencode 専用プラグイン。エビングハウスの忘却曲線を模した記憶モデルや STM/LTM の二層アーキテクチャなど、設計が凝っている。
ただ使ってみて結局手放した。AGENTS.md などの初回読み込みドキュメントにコンテキストをしっかり書いておく方が、何を覚えているかが明示的で確実だと感じたのが大きい。ときどき意図しない学習が蓄積されて、それを掃除する手間が地味にストレス。
TypeScript製
superpowers : マルチエージェントでの開発ワークフロー
ブレスト → 仕様化 → 計画 → サブエージェントによる実装 → レビューという一連の開発フローをスキルとして提供するフレームワーク。gemni-cli へは gemini extensions install 一発で導入できる。サブエージェントが各タスクを並列処理し、数時間自律的に動き続けるという謳い文句は魅力的に映る。
ただ 現状 plan モードで十分だったので、徐々に使わなくなった。サブエージェントを複数動かすとトークン消費が逆に増えがちで、エージェント間の情報伝達にもノイズが入りやすい。シンプルに一つのモデルで一貫させる方が今のところ安定している。とくに gemni-cli は、モデルの最大コンテキストが大きいことが強みで、正直スループット/レスポンスが速い割に高性能な gemini-3-flash で計画→実装まで行えてしまう。今後まだ変わるかもしれないが。
TypeScript製
oh-my-opencode-slim : opencode 向けマルチエージェント構成
Orchestrator・Explorer・Oracle・Librarian・Designer・Fixer という6体の専門エージェントを opencode 上に構築するプラグイン。本家 oh-my-opencode が bloated と評されているのに対し、トークン消費を抑えたスリム版として登場した。役割分担が明確で、設計としては面白い。
superpowers と同様の理由で使わなくなった。複数エージェントがガチャガチャ動くのはトークン効率が悪く、結果のフィードバックも一本筋で流れる方がシンプルにうまくいくことが、個人的には多かった。plannotator で計画を固めてから一つのモデルに任せる運用で十分に感じている。
TypeScript製
gemini-cli-security : Google謹製のセキュリティ監査
セキュリティ脆弱性を自動的に検出・提案するツール。利用したケースでは、ほぼ何も言われなかったので、ちょっとまだわからないのが、今後また利用したい。