pstackで何を学ぶ？

「pstackを試してみて。私を雇うようなものだけど、無料です」。React Compilerの開発にも関わったLauren Tanさんは、Xでこう紹介しました（AMPL訳）。

経験ある開発者はAIに何を任せ、何を見て「できた」と判断するのか。その仕事の進め方を公開された手順から読めるのがpstackの面白さです。

AIにアプリを作ってもらったけれど、本当に動くのか自信がない。そんな非エンジニアのVibe Coderこそ、完成したコードだけでなく、そこへ至る調べ方や確かめ方を知っておくと役立ちます。この講座では自分のAIに仕事を任せるための判断を練習します。

この投稿はX上で11.9万回の表示（2026年10月19日確認）。利用者数や性能の実証を示す数字ではありません。「無料」はpstackの紹介であり、AIサービスの利用料金は別です。

Step 1：依頼から確認までの全体像

LaurenさんがREADMEで重視するのは、書くコードの量より品質です。まず一つのAIに、結果を確かめられる仕事を任せる。それができてから並列に仕事を進める、という考え方です。

たとえば、AIに作ってもらったアプリでログインできないとします。「直して」と頼み、変更したコードを受け取るだけでは、使えるようになったか分かりません。pstackのバグ修正の手順は、元の失敗を再現し、原因を調べ、直したあとに動作を確かめるところまで求めます。

毎回「ちゃんと確認して」と言い足す代わりに、調査から確認までを仕事の手順に含めておく。この違いを、自分の依頼にも取り入れていきます。

今は細部を覚えなくて構いません。各回で一つずつ、この構造に戻ります。インストールはまだ必要ありません。

手順が公開されていても、AIが必ず守る保証はありません。作者の仕事の進め方を学ぶことと、作者と同じ成果が出ることは別です。自分の環境で何を確かめるかまで、この講座で練習します。

Step 2：道具を増やしてきた人ほど確かめたいこと

私も以前、ECC（Everything Claude Code）やさまざまなSkillを導入していました。新しい道具を足してきた人にこそ、「今の環境では何が、いつ働くのか」を確かめながら読んでほしい講座です。

「AI環境の健康診断」「配線をほどく」は、指示・道具・検証のつながりを点検するというAMPLの比喩です。導入済みのものを全部消す話ではありません。

Anthropicはモデルの進歩に合わせて、AIを動かす周辺の仕組み（Harness）を見直す考え方を示しています。同社の開発事例では構成を一括で簡略化すると元の性能を再現できず、一つずつ外して影響を確かめる方法へ変えています。pstackを教材に選ぶのはAMPLの判断です。

コードの細部をAIに任せる、非エンジニアのVibe Coderも、目的・変更してよい範囲・完了条件は自分で判断する必要があります。pstackが公開する手順と検証方法を手がかりに、AIへの依頼と結果の確認を練習します。

ECCやXの投稿をどう捉えるか

kaitoさんもAI開発環境の構成変更を紹介していますが、個人の選択です。今回確認できた投稿本文は一部で、ECCを外す理由までは確認できていません。

ECC自身も同じ環境への重複導入を避け、必要なルールを選ぶよう案内しています。特定の道具を一律に外すのではなく、自分の作業で何が必要かを確かめます。

なお、Claude CodeのSkillは通常、名前と説明を先に読み、本文は使用時に読み込みます。導入済みのSkillすべての本文が、常に読まれるわけではありません。

講座トップの目次で、全8回の学ぶ順番を確認できます。図に出てくる用語は各回で例とともに説明します。

Step 3：自分の困りごとを一つ選ぶ

最初から全部の用語を覚える必要はありません。講座では「ログインできない」という架空のアプリを共通の例にして、依頼、調査、動作確認へと進みます。

たとえば「原因を聞いただけなのに、AIが勝手に直した」は依頼の範囲の問題です。「直ったと言われたのに使えない」は、何をもって完了とするかの問題です。同じ不具合でも、困っている場面を分けると、学ぶ内容と自分の経験がつながります。

メモに「最近AIに任せて困ったこと」を一つ書き、次の文を埋めてみてください。AIやアプリを動かす必要はありません。

頼んだこと：
AIがしたこと：
自分がまだ確かめられていないこと：

今回持ち帰るもの

自分の困りごとを一つ選べたら、この回は一区切りです。図の用語をまだ説明できなくても構いません。次の回から具体例と原典を照らし合わせます。

次は「原因を調べて」と「直して」を分ける頼み方を練習します。