AIが力を出しやすい環境をどう作るか。Lauren Tanさんの考え方から学んだこと

XでCursorやAI開発についての投稿を読んでいて、Lauren Tanさんの考え方が気になった。

最初は、Cursorの便利な使い方を紹介している話だと思っていた。けれど、読み進めると本質はツールの機能ではなかった。

AIに何を作らせるかだけではなく、AIが力を出しやすい環境をどう作るかを考えている。

この記事では、まずLauren Tanさんが公開しているpstackとpoteto-modeの考え方を紹介する。そのうえで、そこから自分の仕事にどう応用できそうかを考えてみる。

Lauren Tanさんは何を言っていたのか

Lauren Tanさんは、Cursor向けのプラグイン群と開発の進め方をまとめたpstack公式リポジトリを公開している。

pstackの中心にあるのは、AIにできるだけ多くのコードを書かせることではない。

まず深く考える。目的を絞る。必要なものだけを作る。そして、結果を確認する。

つまり、速さだけではなく、少ない仕事で、より質の高い結果を出すための仕組みとして設計されている。

この考え方は、AIを使っているときに起きやすい問題への答えにもなっている。

• アイデアが次々に増えて、最初の目的から離れていく
• いろいろな役割を一つのAIに同時に頼んでしまう
• 作ったものを確認する前に、さらに機能を足してしまう
• 何が終われば完了なのかが曖昧なまま進んでしまう

AIが賢くても、仕事の境界が曖昧なら、出力も広がりやすい。

poteto-modeはAIの口調ではなく、仕事の進め方

pstackのpoteto-modeの公式説明を読むと、単なる話し方の変更ではないことがわかる。

役割を分け、目的に合う作業へ振り分け、実装と確認をつなげる。必要なら、追加する前に削る。やらないことも決める。

ここで大事なのは、AIに「もっと頑張って」と頼むことではない。

AIが担当する仕事、担当しない仕事、確認する人、完了の条件を先に用意することだ。

これはAIを一人の万能な作業者として扱うのではなく、複数の役割があるチームのように扱う発想に近い。

Xでのやり取りから見えたLauren Tanさんの考え方

Xで紹介されていたやり取りには、Lauren Tanさんの考え方がよく表れている。

たとえば「poteto-modeが有効なら、architectを明示的に呼ばなくてもよいのでは？」と聞かれたときには、説明のために明示しているだけで、必要なら省略してもよいと答えている。逆に、確実にその役割を使いたいときは明示してよい。

これは、決められたコマンドを暗記させる考え方ではない。状況に応じて、どの役割を呼ぶかを人が選べるようにしている。

また、「高価なモデルを使うのか、選べるのか」と聞かれたときには、/setup-pstackから選べると案内している。モデルを固定して押しつけるのではなく、目的や予算に応じて環境を調整できるようにしている。

Cursorで直接使うのか、Grokのボット経由なのかという質問には、両方使っていると答えている。さらに、計画や実装案から得た重要な判断をどこに残すかという問いには、エージェントの判断をよくする文脈でなければ、リポジトリではなくGoogleドキュメントのような別の場所に置くという考えも示している。

ここが、私が「すごい」と感じたところだ。

特定のツールや一つの正解に閉じず、役割、モデル、保存場所、呼び出し方を、仕事に合わせて組み替えている。AIを魔法の箱として扱うのではなく、仕事の流れの中に置いて設計している。

Cursor Marketplaceのpstackの紹介でも、スキルや役割を使い分ける考え方が示されている。また、Xで紹介されていた自動化ボットの例として、dr eggbot v2のように、決めた仕事を担当させる入口も用意されている。

ただし、ここで注意したいことがある。

これは「Cursorを使えば自動的にうまくいく」という話ではない。CursorやXは考え方を試すための具体例であって、本質はどのAIツールを使うかより、仕事の環境をどう設計するかにある。

SASIE：浮かんだアイデアをすべて同時に進めず、いま扱う一つの仕事へ絞り込むイメージ。

なぜAIは環境によって動きが変わるのか

同じAIでも、依頼の仕方によって結果が大きく変わる。

「いい感じに作って」と頼めば、AIは考えられるものを広げてくれる。一方で、「ここまでを、このファイルで、こう確認できたら完了」と伝えれば、判断の範囲が狭くなる。

この差を作るのは、プロンプトの巧さだけではない。

• 目的が一つに絞られているか
• 今回やらないことが決まっているか
• 誰が最終判断するかが明確か
• どこまでできれば完了なのかが見えるか
• 実際に触って確認する手順があるか

この5つが揃うと、AIは迷う場所が減る。

ここからは私の解釈だ。Lauren Tanさんが、私たちの運用について直接この形を指定しているわけではない。ただ、pstackの考え方を自分の仕事に当てはめると、AIの能力を引き出す前に、AIが動きやすい環境を用意する必要があると感じた。

この考えから、私はこう考えた

自分の作業では、アストラさんに設計や実装をお願いすることが多い。

アストラさんが頑張ってくれるほど、こちらから次々にアイデアを追加したくなる。しかし、追加のたびに目的や優先順位が変わると、実装する側は何を完成させればよいのかわかりにくくなる。

そこで、役割を固定してみることにした。

SASIE：目的を一枚の依頼にまとめ、レビューを経て実装へ渡すイメージ。

この分担にすると、アストラさんへ「全部いい感じにやって」と渡さずに済む。

ルナさんから提案が出た場合も、そのまま機能を増やすのではなく、提案を整理してからアストラさんへ戻す。最後に採用するかどうかを決めるのは自分だ。

いま作ろうとしているタスク管理にも応用できる

この考え方は、attrip内の簡単なタスク管理にもそのまま応用できそうだ。

ここでいう「書く」は、すでに使っている既存のツールだ。新しいメモアプリや外部カレンダーを増やす話ではない。

「書く」に浮かんだことを残し、あとでattrip内のスケジュールへ送る。開いたら、まず今日のタスク一覧が見える。優先度の高いものを上に並べ、名前・優先度・期限は同じ場所で編集する。

長いタスクは親を残したまま、子タスクに分ける。子がすべて終わったら、親を完了できると知らせる。親を完了したら今日の一覧からは隠し、完了履歴から見返せるようにする。

外部カレンダーとは混ぜない。

この仕様で重要なのは、機能の多さではない。思いついた瞬間に一、二秒で保存できること、次に何をするか迷わないこと、長い仕事を小さくできること、そして完了したものをあとから確認できることだ。

アストラさんへ渡す依頼も、同じように小さく区切る。

目的：
今回やること：
今回やらないこと：
担当：
完了条件：
確認方法：

たとえば、今回のタスク管理なら次のようになる。

目的：書くに残したアイデアを、今日やる行動へ変える
今回やること：今日の一覧、優先度順、同じ場所での編集、親子タスク、完了履歴
今回やらないこと：外部カレンダー連携、複雑な通知、細かいタグ
担当：Astraが設計と実装、Lunaが使い心地を確認
完了条件：一つのタスクを追加し、編集し、子へ分割し、完了履歴まで確認できる
確認方法：PCとスマートフォンで実際に操作する

私が学んだこと

Lauren Tanさんの考え方から、自分は「AIにうまく頼む方法」だけではなく、「AIが迷わず働ける環境を作る方法」を学んだ。

ポイントは4つある。

1. 仕事を一つに絞る
2. やらないことを決める
3. 役割と最終判断を分ける
4. 実際に触って確認する

とくに、自分にとって大きかったのは「機能を足さない前提でも、使い心地は深く考えられる」ということだ。

今日の一覧を優先度順にする。同じ場所で編集できるようにする。親子関係を見えるようにする。完了したものを隠し、履歴から見返せるようにする。

これは機能を増やしているように見えるけれど、目的は一つしかない。

いま何をすればいいのかを、すぐに見えるようにすること。

これからの進め方

これからは、次の順番で進めていく。

質問 → 構成 → 実行 → 結果 → 修正

最初に目的と完了条件を決める。アストラさんに一つの仕事として渡す。ルナさんには使い心地を見てもらう。提案が出たら、自分が採用するものを決めて、必要な分だけアストラさんへ返す。

この流れなら、アイデアが増えても、いま進めている仕事と混ざりにくい。

Cursorの話から始まったけれど、学んだことはCursorだけの話ではなかった。Xで見かけたLauren Tanさんの考え方を入口に、自分の仕事にも「AIが動きやすい環境」を作っていきたいと思う。

AIに何をさせるかを考える前に、誰が何を担当し、どこまでできたら終わりなのかを決める。

それだけでも、AIとの仕事はずっと進めやすくなるはずだ。