pstackとは、Cursorをはじめとする自律型コーディングエージェントに現場エンジニアの設計・検証プロセスを遵守させるワークフロー規律プラグインです。AIにバグ修正を依頼したとき、ファイルを何行も変更してテストを通したと報告してきたのに、動かしてみるとバグが直っていなかった経験はないでしょうか。あるいは小さな機能追加を頼んだだけなのに、不要なクラスや設計パターンが勝手に量産されて保守コストが増えた場面に出くわした人も多いはずです。こうしたエージェント特有の空振りを防ぐ仕組みがpstackです。
開発エージェントが現場で自滅する原因は何ですか？
自律型AIエージェントが開発現場で期待外れの結果を招く最大の理由は、実装作業そのものより前段階の調査と後段階の検証を省略する点にあります。
一般的なコーディングエージェントは、指示を受け取ると即座にファイルの編集を開始します。トークン生成の仕組み上、次に来るコードを予測して出力することが最優先されるためです。人間であれば最初に行う「周辺コードの依存関係を調べる」「動作を再現するテストケースを書く」「変更差分の影響範囲を見積もる」といったステップを踏みません。この傾向はモデルが進化しても根本的には残り続けます。
AIによるコード生成の正解率を測る指標については、pass@kとは？AIコード生成の実力を測る指標と3つの落とし穴でも取り上げられている通り、単にテストを通過することと保守に耐えうるコードを書くことの間には大きな隔たりがあります。
エージェントが陥りやすい典型的な失敗パターンを次の表に整理しました。
| 失敗パターン | エージェントの | 開発者が |
|---|---|---|
| 即時編集の罠 | 指示を受けた直後に既存設計を読まず書き直す | 既存の命名規則やアーキテクチャが破壊される |
| 架空の成功報告 | テスト結果を偽装、または的外れなテストを追加して通過とする | 本番環境で障害が発生するまで不具合に気づけない |
| 過剰な抽象化 | 単純な修正に対して不要なヘルパー関数や階層を勝手に新設する | コード行数が増加し保守コストが跳ね上がる |
| 広範な破壊 | 1箇所の修正のために無関係な周辺ファイルまで書き換える | PRの差分レビューが破綻しマージできなくなる |
AIエージェントの失敗は能力不足ではなく、作業手順の欠落から生じます。
編集部のおすすめ
AIで
エディタのAIを使いこなしたい人向けの講座と、コードなしで作れるツールです。
初月10ドルオフ（新規ユーザー）
Claude CodeやCursorへの指示を声で入力できる。日本語にも対応し、Mac・Windowsのどの入力欄でも使える（無料は1,000語まで）
AI音声・文字起こし ／ 最低料金 ¥0〜
XServer VPSAIと作ったWebアプリやDifyのアプリを自分のサーバーで公開するなら。Dockerのアプリイメージで始められる
VPS（Dify・n8n の自前運用） ／ プランと料金は公式で確認
pstackがエージェントに課す4つのエンジニアリング規律とは？
pstackはエージェントの作業フローを厳密に制限し、勝手なコード改変を封じるための4つの原則を定義しています。
開発者のLauren Tan（poteto）氏がCursorの社内開発で実践してきた習慣をプラグイン化したもので、コード行数を増やすのではなく、最小限のコードで高品質な実装を残す方針を徹底します。エージェントは指示を受けると、即座に編集画面を開くのではなく、決められた4段階の思考プロセスを踏むよう制約を受けます。
[ステップ1: 既存コードの理解]
↓
[ステップ2: 設計の選定と合意]
↓
[ステップ3: 現実環境での検証]
↓
[ステップ4: 変更差分のレビュー]
エージェントが勝手な判断で実装を完了と宣言することは許されません。4つの原則それぞれがどのような行動を指示しているのか、具体的に見ていきます。
原則1：既存コードの理解（Understand the existing code）
エージェントは変更対象のファイルだけでなく、呼び出し元や依存しているモジュールを事前に探索しなければなりません。
プロジェクト内で使われている命名規則、エラーハンドリングの流儀、非同期処理の共通パターンを把握するまで、コード編集ツールの呼び出しを禁止します。エージェントが既存の文脈を無視して新しいライブラリを勝手に追加したり、独自のユーティリティ関数を作り始めたりする暴走を未然に防ぐ効果があります。
原則2：設計の選定（Choose a design）
実装に入る前に、複数の実現方針を比較検討し、最も侵入度の低い設計を選びます。
コードの修正には必ず複数のやり方が存在します。既存の引数を拡張するのか、新しい関数を切り出すのか、あるいは設定値の変更だけで済むのかをエージェント自身に整理させます。方針が定まらないまま書き始めて後から辻褄を合わせる行為を禁じるため、手戻りが激減します。
原則3：現実の検証（Verify the result）
「直しました」という言葉の前に、実際にテストやビルドを実行して動作を証明することを義務づけます。
エージェントは推論結果だけで成功を報告できません。テストランナーを実行した標準出力のログ、またはビルドコマンドの終了コードを確認し、エラーがない事実を提示して初めて次のステップへ進めます。再現手順が存在しないバグ修正の場合、修正前に失敗し、修正後に成功する検証スクリプトの作成をエージェントに求めます。
AIに作業メモや検証プロセスを保持させる手法は、scratchpadとは？AIの下書き欄の使い方と3つの意味を整理 (2026年版)の仕組みと深く共通しています。
原則4：差分のレビュー（Review the diff）
タスク完了を宣言する直前に、git diffに相当する変更差分をエージェント自身に総点検させます。
要求に関係のないインデント変更が含まれていないか、デバッグ用に出力したログ文が残っていないか、削除すべき古い関数が放置されていないかを監視します。人間のレビュアーがPRを見たときに一目で意図が伝わる状態にまで差分を磨き上げることが、エージェント側の完了条件です。
CursorとClaude Codeにおけるpstackのアーキテクチャ
pstackは独自のバイナリや重厚なサーバーを常駐させる仕組みではありません。エディタが読み込むプロンプト定義とスキルファイル（SKILL.md）の集合体として設計されています。
軽量なテキストファイルで構成されているため、Cursor専用のプラグインとして動作するだけでなく、AnthropicのCLI環境であるClaude Codeにも生成コピーをそのまま配置して利用できます。
.cursor/ (またはプロジェクトルート)
├── plugins/
│ └── pstack/
│ ├── SKILL.md # コアとなる規律定義
│ ├── playbooks/ # タスク別の作業手順書
│ │ ├── bugfix.md # バグ調査・修正手順
│ │ ├── feature.md # 新機能開発手順
│ │ └── refactor.md # リファクタリング手順
│ └── bots/
│ └── dr-eggbot.md # ボット生成・スキル作成支援
エディタ内のエージェントが起動した際、これらの定義がシステムプロンプトのコンテキストへ自動的に展開されます。エージェントは自身が利用可能なツール（ファイル読み込み、コマンド実行、ファイル編集）を呼び出す順番を、ファイル内のルールに従って厳密に自己管理します。
高度なモデルを用いたAIエージェントを動かす際、モデルの推論能力そのものよりも、エージェントが辿るべきプロセスの外枠を固定する方が実用性に直結します。
毎週月曜の朝に、今週のCursorのニュースとアップデートを先頭に、AI全体の主なニュースと新しく載ったツールをまとめて届けます。登録特典は「AIツール選定チェックリスト 2026」。
確認メールのボタンを押すと登録が完了します。配信はいつでも解除できます。
pstackの導入手順と初期セットアップ
pstackの導入は数分で完了します。設定ファイルをリポジトリ内、またはエディタのプラグインディレクトリに配置するだけで即座に反映されます。
# プロジェクトのリポジトリにクローン、またはプラグインとして追加
git clone https://github.com/cursor/plugins.git /tmp/cursor-plugins
cp -r /tmp/cursor-plugins/plugins/pstack .cursor/plugins/pstack
Claude Codeを利用している環境であれば、プラグインに含まれるREADMEとGUI設定の指示に従って生成スクリプトを叩くだけで、対応するスキル定義が自動構築されます。
導入後にプロジェクトルートへ配置された設定ファイルを確認し、自チームのテストコマンドやリントコマンドをプレイブックに追記しておくと、エージェントの検証精度が一段と高まります。
タスク別プレイブックによるエージェントの誘導手順
pstackには、日常的な開発業務に応じた「タスク別プレイブック」が標準で同梱されています。開発者がチャット欄で作業内容を指示した際、エージェントは対応するプレイブックを自動的に引き当てます。
代表的な3つのユースケースにおけるエージェントの動作規則を確認しておきます。
1. 不具合の調査と修正（Bugfix Playbook）
不具合修正において、pstackは「再現コードの作成」を最優先の関門に据えます。
- 報告された不具合の事象を読み取り、再現条件を特定する。
- 修正対象コードを触る前に、失敗する再現テストを作成して実行する。
- テストが期待通り赤（失敗）になることを確認する。
- 最小限の変更でテストを緑（成功）にする実装を行う。
- 既存のテストスイート全体を走らせ、リグレッションがないことを証明する。
この手順を遵守させることで、「直したつもりで直っていなかった」事故を完全に排除します。
2. 機能追加（Feature Playbook）
新機能の追加時、エージェントはコード行数を無駄に増やす傾向があります。Feature Playbookはその悪癖を抑制します。
- 既存のドメインモデルとAPI設計を走査し、類似機能の実装パターンをリスト化する。
- インフラ層やインターフェースを無駄に増やさない、最も単純なデータフローを設計する。
- 実装を行い、単体テストと統合テストを追加する。
- コマンドラインやAPI呼び出しを通じて、機能が正しく応答する事実をログで確認する。
3. リファクタリング（Refactor Playbook）
振る舞いを変えずに内部構造を改善する作業では、差分管理が最重要視されます。
- リファクタリング対象のテストカバレッジを確認し、不足があればテストを追加する。
- 1回につき1つの小さな変更（関数の移動、型の整理など）に留めてテストを実行する。
- 動作が変わっていないことをテストログで証明しながらステップを刻む。
- 最終的なPR差分から不要な空白変更やコメントの乱れを排除する。
AIコーディングツールを実務に組み込む現場では、こうした手順の明文化が作業品質を分ける決め手となります。
付属ボット「Dr Eggbot」の機能と活用法
pstackには、日常の開発を支援するだけでなく、開発組織に最適化したカスタムボットを作成するためのツール「Dr Eggbot」が同梱されています。
Dr Eggbotは、pstackが持つ高い検証規律を他の専門ボットへ継承させるためのメタボットです。コーディング用ボットだけでなく、ドキュメント作成やインフラ定義など、非コーディング用途のボットにも同様の厳密さを持たせることができます。
チャット画面でDr Eggbotを呼び出し、次のように指示を出します。
@Dr Eggbot
リポジトリ内のPlaywrightテストを自動実行し、
失敗時に画面キャプチャを比較してレポートを作成するエンジニアボットを作成してください。
検証スキルとして /create-verification-skill を設定してください。
指示を受けたDr Eggbotは、検証手順と失敗判定基準が埋め込まれた専用のプロンプトファイルを自動生成します。新しく作られたボットもpstackの基本原則を受け継ぐため、いい加減な推測でレポートを出力することがありません。
日常業務のタスク整理や進行管理をAIに任せるアプローチについては、AIタスク管理ツール7選｜3〜20人チームはClickUp Brainが軸 (2026年版)でも触れられている通り、ツールの選定以上に運用の枠組みを固めることが成果につながります。
pstackのコマンドと操作方法
pstackの操作は極めてシンプルです。専用のGUIメニューを複雑にクリックする必要はなく、チャット入力欄でのスラッシュコマンドやキーワード指定で進行をコントロールできます。
| 操作コマンド | 動作内容 | 活用する |
|---|---|---|
/poteto-mode | プレイブックの自動マッチングとスキル連動を有効化する | 複雑な機能実装や原因不明のバグ調査を開始するとき |
原則名の指定（例: verify） | エージェントに特定の原則を再実行させ、証拠の提示を求める | テストログの提示が不十分で、再検証を指示したいとき |
/create-verification-skill | プロジェクト固有のテスト・ビルド検証ルールを新規作成する | 独自フレームワークのCIチェックを手順に組み込むとき |
原則名の指定（例: review-diff） | 変更差分を再精査させ、不要な行の削除を命じる | コード変更量が想定より多く、最小差分に圧縮させたいとき |
開発者がエージェントを操舵する際、長文のダメ出しプロンプトを打つ必要はありません。原則名を一言入力するだけで、エージェントは自身の作業フェーズを該当ステップへ巻き戻し、必要な検証ログを取得し直します。
従来のプロンプト指示とpstackは何が違うのか？
多くの開発者は、エージェントの精度を上げるために「勝手にファイルを書き換えないでください」「テストを必ず実行してください」といった注意書きを個別プロンプトや.cursorrulesに書き込んできました。しかし、これらは簡単に無視されます。
なぜ指示文だけでは不十分で、pstackのような規律システムが必要になるのか。両者の構造的な違いを比較します。
| 比較項目 | 個別の | pstackに |
|---|---|---|
| 制約の強さ | 単なる推奨事項として扱われ、文脈長で薄まる | スキルとツールの呼び出し手順として強制される |
| 失敗時の挙動 | テストが通らなくても「完了」と主張して停止 | 検証ログが提示されるまでタスクを完了できない |
| 差分の品質 | コードを書き換えた後のレビューは人間任せ | 差分チェックフェーズを通るためPRが肥大化しない |
| 設計の共有 | エージェントが思いつきの構造でコードを量産 | 既存コードの探索が完了するまで実装に入れない |
指示文をいくら重ねても、エージェントの思考ステップそのものを縛ることはできません。pstackは「次に呼ぶべきツール」の手順を物理的に制限することで、プロンプトの形骸化を根底から解決します。
開発チーム全体の生産性を底上げする観点からは、AI生産性・ノートツールやAI自動化の導入と並び、コーディングエージェントの振る舞いを標準化することが必須の取り組みとなります。
pstackを導入する際の注意点と制限事項
pstackはエージェントの暴走を抑える強力なツールですが、導入にあたって理解しておくべきトレードオフも存在します。
1. API呼び出し回数とトークン消費量の増加
pstackを適用すると、エージェントはコードを書く前に複数のファイルを読み込み、テストコマンドを叩き、差分を再帰的にチェックします。結果として、1つのタスクを完了するまでに消費するトークン数とAPIリクエスト回数が従来の2倍から3倍に跳ね上がります。
簡単なタイポ修正や文言の変更など、検証ステップを踏むまでもない軽微な作業にまで適用すると、開発テンポが悪化します。
2. テスト環境が整っていないプロジェクトでの形骸化
pstackの原則3（現実の検証）は、プロジェクト内に実行可能なテストスイートやビルドコマンドが存在することを前提としています。
自動テストが一切存在せず、コンパイルも通らないようなレガシー環境に導入した場合、エージェントは「検証の証拠」を取得できず、エラーログの前でスタックしてしまいます。導入に先立ち、最低限の構文チェックや単体テストがローカルで走る環境を整備しておく必要があります。
pstackと他のコーディング支援ツールの役割分担
現代のAI開発環境には、Cursorをはじめとするエディタ、裏側で動く基盤LLM、そしてワークフローを制御するプラグインなど、複数のレイヤーが存在します。混乱しやすい各要素の役割分担を整理します。
[基盤LLM: 推論能力の提供]
(Claude 5系 / GPT-6系 など)
↓
[開発エディタ: ファイル操作・ツール実行]
(Cursor / Claude Code)
↓
[規律プラグイン: 振る舞い・手順の制御]
(pstack)
エディタやモデルを最新のものへ入れ替えても、指示の出し方が雑であれば精度の高いコードは得られません。逆にpstackを組み込んでいれば、基盤モデルの推論能力を最大限に引き出し、現場の規律に沿ったコードのみをコミットさせることが可能になります。
開発チームの規模に応じた開発支援の選定については、AIプロジェクト管理のツール群と連携させながら、コミット前の品質ゲートをどのように敷くか検討するのが現実的です。
AI PICKS編集部の判定
pstackは、CursorやClaude Codeを日常的に使い倒している現場エンジニアにとって、一度導入したら手放せない重宝ツールです。
多くの開発者が直面している「AIが勝手に余計なコードを書いてPRが崩壊する問題」に対し、プロンプトの工夫ではなくワークフローの強制という設計で正面から回答を出しています。コード行数を増やすことを競うのではなく、「最小限のコードで安全に倒す」という思想は、実務の現場感覚と完全に一致しています。
一方で、ローカルでテストが走らない雑多なスクリプトや、スピード最優先のプロトタイプ開発では、検証手順の多さが仇となり正直イマイチに感じる場面もあります。トークン消費量も確実に増えるため、すべての作業で常時起動しておく道具ではありません。
すでに一定以上の自動テストが整っており、エージェントの生成コードに対するレビュー負担を減らしたい開発チームには一択の選択肢です。無料のMITライセンスで手軽に試せる点も含め、エージェントの手綱を握るための規律として圧倒的に筋が通っています。
よくある質問（FAQ）
Q. pstackは無料で使えますか？
MITライセンスのオープンソースとして公開されているため、プラグイン自体の利用料金は無料です。ただし、CursorやClaude Codeを通じて外部LLMのAPIを呼び出す際のトークン費用は通常通り発生します。
Q. 日本語のプロンプトでも正しく機能しますか？
問題なく動作します。pstackの内部規律ファイルは英語で書かれていますが、CursorやClaude Codeのエージェントは指示文の言語を問わず手順を理解します。日本語でタスクを依頼しても、探索・設計・検証・差分確認の4原則に従って処理が進みます。
Q. VS Codeの通常版やJetBrains環境でも動きますか？
pstackの標準仕様はCursorのエージェント環境およびClaude CodeのSKILL仕様に依存しています。そのため、エージェント型の自律実行環境を持たない通常のVS CodeやJetBrainsエディタ単体では動作しません。
Q. 導入するとコード生成の待ち時間は長くなりますか？
長くなります。ファイルを即座に書き始める従来の手法と異なり、周辺コードの読解や事前テストの実行、事後レビューを挟むため、1タスクあたりの応答時間は確実に伸びます。ただし手戻り修正の回数が減るため、作業全体の所要時間は短縮されます。
Q. 小さなタイポ修正でも4つの原則はすべて実行されますか？
原則としてエージェントは規律に従おうとします。タイポ修正や文言変更など明らかな軽微修正で時間をかけたくない場合は、/poteto-modeを付与せずに直接編集を指示するか、プロンプトで即時修正を指定して運用を切り替えるのが現実的です。
あわせて見たいツール・カテゴリ
AIを活用したソフトウェア開発や作業効率化を進める際は、開発規律の整備に加えて周辺ツールや関連技術のキャッチアップが役立ちます。
エージェントの振る舞いだけでなく、チーム全体の開発フローを自動化する観点からは、AIタスク管理ツール7選｜3〜20人チームはClickUp Brainが軸 (2026年版)を合わせて読むと、業務全体の設計がより明確になります。
参考にした一次情報
記事の事実関係は、次の公式ページで確認しています。仕様や料金は変わることがあるため、最新の内容は各ページで確かめてください。
- GitHub cursor/plugins リポジトリ（公式）：公式プラグイン一覧にpstackがあり、作者はLauren Tanと記載されています（2026年10月確認）
- pstack ガイド「変更の実装と整理」（公式）：バグ修正・機能追加・リファクタリング・性能改善のプレイブックへ振り分けます（2026年10月確認）
- pstack create-verification-skill（公式）：/create-verification-skillで、アプリを操作して検証するプロジェクト用スキルを生成します（2026年10月確認）
- pstack ガイド「セットアップ」（公式）：Claude Codeでもマーケットプレイスを追加すればpstackをインストールできます（2026年10月確認）
