5
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【ざっくり理解】Poteto Modeとは? AIコーディングエージェントに「動く証拠」を求める仕事の進め方

5
Last updated at Posted at 2026-11-03

はじめに

Claude CodeやCursorなどのAIコーディングエージェントに不具合修正を頼んだとき、「コードは直したと言っているけれど、本当に問題が解消したのだろうか」と感じることがあります。

そこで気になったのが、Lauren Tanさん(@poteto)が公開しているpstackと、その中心となるPoteto Mode(poteto-mode)です。

pstackは、AIにコードを書かせるための単一のプロンプトではありません。調査・実装・検証などに使う複数のスキルをまとめ、作業に応じて呼び出す仕組みです。

本記事では、公式のGitHubリポジトリを中心に、「何をしてくれるのか」「普通にAIへ頼む場合と何が違うのか」「どうやって使い始めるのか」をざっくり整理します。

記事の範囲:2026年11月3日時点で参照できた公開ドキュメントをもとにした調査メモです。筆者自身による導入・実行検証や、品質改善効果の比較測定は行っていません。プロジェクトは更新が速いため、導入時は最新のREADMEを確認してください。

この記事の全体像(1枚でざっくり理解)

Poteto Modeの概要・進め方・3つの考え方・対応ツールのまとめ

この図は本家READMEに基づく概要の要約です。「3つの考え方」は記事向けの整理であり、公式が定める原則の総数を示しているものではありません。

まず、pstackとPoteto Modeの違い

  • pstack:調査・設計・実装・レビュー・検証などを支援するスキル群(およびそれらを利用するための仕組み)
  • Poteto Mode:依頼された作業を読み取り、適切なプレイブック(作業手順)を選び、必要なスキルを順に使う入口
  • スキル:たとえばhow(仕組みの調査)、why(背景や理由の調査)、architect(実装前の設計整理)といった個別の支援手順

つまり、pstackが道具箱なら、Poteto Modeは「どの道具を、どんな順番で使うか」を決める案内役です。

Poteto Modeの全体像

Poteto Modeの基本的な流れは、次のように理解できます。

  1. 目的を伝える:「ページ切り替えで検索条件が消える不具合を直して」などと依頼する
  2. 手順を選ぶ:バグ修正や機能追加など、依頼に合ったプレイブックを選択する
  3. 必要な調査・設計・実装を進める:作業に応じて補助スキルやエージェントを利用する
  4. 実際の結果を確かめる:テスト、実行、計測などで確認できる範囲を検証する

ポイントは、「直しました」という報告だけでなく、「どのように確かめたか」も重視することです。ただし、環境や権限、テスト手段が不足していれば、検証を完了できない場合もあります。Poteto Modeを使えば必ず不具合が直る、という意味ではありません。

参考:本家pstack README

大事にしている3つの考え方

公式READMEには多数の原則が定義されています。本記事では、初心者がつかみやすいよう、特に次の3点に要約しました(公式が原則をこの3つに限定しているわけではありません)。

3つの考え方

考え方 ざっくりした意味
小さく整った変更 必要以上のコードを増やさず、問題を解決する最小限の変更を目指す
計画的な並列作業 やみくもにエージェントを増やさず、検証できる単位で仕事を分担する
実物で検証する 「通るはず」ではなく、動作・テスト結果・実測値などを確認する

また、複数のエージェントを並列で動かす考え方も取り入れられています。ただし、並列化そのものが目的ではなく、「確かさ」を土台に、速さも目指すという発想です。やみくもに数を増やすのではなく、検証できる単位に仕事を分けることで、品質と速度の両立を狙います。

例:バグ修正を頼んだ場合

コミュニティ版のREADMEでは、「ページを切り替えると検索フィルターがリセットされる問題」を例に、作業の流れが説明されています。

バグ修正の流れ

  1. 再現する:まず、問題が発生する操作や条件を確認する
  2. 原因を調べる:必要に応じてhowやwhyを使い、関連する実装や背景を調査する
  3. 修正する:原因に対応する変更を行う。関数の境界をまたぐ修正では、事前にarchitectで設計を検討する
  4. もう一度確かめる:最初に失敗していたケースを実行し、結果を比較する

うまく検証できれば、修正したコードに加えて、変更前は失敗していたこと、変更後は成功したことを示す情報が得られます。

これは、エンジニアが行う「再現 → 原因調査 → 修正 → 再確認」を、AIの作業手順として明示する取り組みといえそうです。

なお、ここに記したのはREADMEで紹介されている想定ワークフローであり、筆者が実機で再現した結果ではありません。

参考:pstack-claude README

CursorとClaude Codeではどう使う?

本家pstackはClaude Codeにも対応している

当初はCursor向けのスキル集として知られていましたが、現在の本家READMEにはClaude Code向けのインストール方法も記載されています。そのため、「Claude Codeでは非公式の移植版しか使えない」と理解するのは正確ではありません。

本家とコミュニティ版の利用経路

利用先 選択肢 補足
Cursor 本家pstack Cursor向けの導入手順を案内
Claude Code 本家pstack 本家がClaude Code用のアダプターと導入方法を案内
Claude Code、Codex、Piなど コミュニティ版pstack-claude 複数の実行環境を対象に調整・拡張された別プロジェクト

Claude Codeで本家を導入する場合

本家READMEでは、Claude Code内で以下を実行する方法が案内されています。

/plugin marketplace add cursor/plugins
/plugin install pstack@cursor-plugins

Claude Codeでのコマンド名は、名前空間付きの**/pstack:poteto-mode**になります。利用前には/pstack:setup-pstackによるモデル設定も確認します。

コミュニティ版を導入する場合

一方、michael-denyer/pstack-claudeは、本家をベースに別の実行環境へ対応させたコミュニティプロジェクトです。こちらを使う場合は、次のように案内されています。

/plugin marketplace add michael-denyer/pstack-claude
/plugin install pstack@pstack-claude

コミュニティ版READMEでは、Claude Code 2.1.292以降を対応条件として記載しています。これはコミュニティ版の記載であり、本家の導入条件と混同しないようにします。

本家とコミュニティ版は同時インストールを前提としたものではなく、まず使いたい経路を選ぶのが分かりやすそうです。

参考:本家pstack README / コミュニティ版README

導入前に気をつけたいこと

  • 自動で成果が保証されるわけではない:テスト環境がない場合や再現が難しい不具合では、検証にも限界があります。結果だけでなく、実行した確認内容と未確認事項を見ます。
  • 実行権限を確認する:スキルやフックがローカルのファイル、コマンド、GitHub操作などにアクセスすることがあります。導入前にリポジトリの内容と許可する権限を確認します。
  • モデル利用量は増える可能性がある:調査・並列実行・再検証を重ねれば、通常より多くのトークンや実行時間を使うことがあります。実際の増減はタスクや設定次第です。
  • 自動振り分けの設定が異なる:コミュニティ版ではルーティング用フックとsetup-pstackによる設定が説明されています。本家と同じ動作とは限りません。
  • データの送信先を理解する:コミュニティ版READMEは独自サーバーやテレメトリーを持たないと説明していますが、エージェントが読み取ったコードやセッション情報は利用するモデル提供元に送られ得ます。「外部送信がない」という意味ではありません。
  • 実行環境で使える機能を確認する:本家のClaude Codeアダプターでは、Cursor専用機能に依存する手順をスキップする場合があります。

作者の考え方で印象に残ったこと

本家READMEでは、pstackの目的を単純なコード生成量の最大化ではなく、より少ないコードで、より品質の高い変更を行うことに置いています。また、build-the-lever(繰り返せる道具・仕組みを作る)やprove-it-works(実物を使って動作を確かめる)といった原則が列挙されています。

たとえば、毎回手で同じ確認をするのではなく、検証用のスクリプトやスキルにしておけば、次の作業でも繰り返して利用できます。

この考え方は、「AIに一回きりの回答を作らせる」よりも、次の仕事にも使える検証手順を蓄積する方向に近いと感じました。

作者はXでもガイドや運用事例を発信しています。ただし、X上の個別投稿については今回本文を直接確認できていないため、投稿に含まれる数値や最近の方針変更を事実として本文には採用していません。最新の発信はLauren TanさんのXを参照してください。

まとめ

  • pstackは、調査・設計・実装・検証に関わるスキルをまとめた仕組み
  • Poteto Modeは、依頼に応じたプレイブックとスキルを選ぶ入口
  • 大切なのは、生成されたコードの量よりも小さな変更・計画的な並列作業・確認できる証拠
  • バグ修正では、再現 → 調査 → 修正 → 再確認を重視する
  • 本家pstackはCursorだけでなくClaude Codeにも対応しており、コミュニティ版という別の選択肢もある

一言でまとめると、Poteto Modeは「AIに『直したと言わせる』だけでなく、『どう確かめたか』まで求めるための仕事の型」だと理解しました。

次は練習用のリポジトリで、小さな不具合を修正させ、普段のClaude Codeと検証内容がどう変わるのか試してみたいと思います。

参考資料

5
2
3

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
5
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?