勢いでバイブコーディングしたツールは、数か月放っておくと中身を覚えていません。どこまで動くのか、何が壊れているのかもわからない。そんな状態のまま「続きを作って」と頼むと、AIもあなたと同じく手探りで書き始めます。Simon Willisonさんが、約10か月前に作った純Python製のWebAssemblyエンジンを再開した記録から、再開時の最初の一手を型にします。
放置プロジェクトを再開するときにまず現状を評価させ、ゴールまでの距離を見積もらせるプロンプトの型（コピペ用テンプレート付き）と、AIの評価レポートを鵜呑みにしないための確かめ方です。
pwasmは、WebAssemblyを純粋なPythonだけで動かすエンジンです。Simon Willisonさんが2026年1月、本人いわく「最初のAI熱」の時期に、全部バイブコーディングで作りました。
その後は手つかずのまま。10月になって、Claude Opus 5.5にこのプロジェクトを任せます。そのときの依頼は「直して」でも「機能を足して」でもありませんでした。順番が決まっていて、要点はこうです。
結果はバージョン0.2a0として公開されました。作業は42コミットで、追加の指示はほとんど要らなかったそうです。WebAssemblyの仕様のほぼ全体を扱えるようになり、PyPIのパッケージにはMicroPython、QuickJS、Micro QuickJSのWASMビルドが同梱されています。
一方でSimonさんは、このプロジェクトをまったく信用していないとも書いています。だからバージョンにalpha（a0）が付いています。ここも大事なポイントなので、後で扱います。
ここが核心。依頼の最初の一語が「評価して」だった。書き始める前に、いまの地図を作らせている。
作った本人が覚えていないコードを、いきなり「続きを」と渡すと何が起きるか。評価を先に挟む理由は3つあります。
数か月たてば、依存ライブラリの版も、手元の環境も、使えるモデルも変わっています。当時は動いたテストが今は落ちることもあります。最初に評価させると、「今この環境で何が動くか」から話を始められます。記憶や古いREADMEを出発点にしなくて済みます。
Simonさんの依頼は「評価」と「目標（MicroPythonを載せる・速くする）に何が要るか」がセットでした。現状と目標の差分を先に書き出させると、作業が足りないものリストになります。AIは思いついた順に直すのではなく、リストを順に潰していけます。追加指示がほとんど要らなかったのは、このリストが道しるべになったからだと考えられます。
評価レポートが出た時点で、一度止まれます。「思ったより壊れているからやめる」「高速化は後回し」といった判断を、コードが書き換わる前にできます。いきなり実装させると、判断する材料が手に入るのは差分が積み上がった後です。
逆に「直して」から始めると、AIは目についたエラーから手をつけます。直した箇所が全体の中でどれくらい大事なのかは、誰も把握していません。放置プロジェクトでこれをやると、小さな修正が積み上がって、何が前進したのかわからない差分が残りがちです。
Simonさんの依頼を、個人開発の再開でそのまま使えるテンプレートに直しました。ポイントは最初のターンではコードを書き換えさせないことです。
# 再開プロンプト（1ターン目）
このリポジトリは数か月放置していた自作ツールです。
まだコードは変更しないでください。
1. 現状を評価する
- 依存関係を入れ、テストとビルドを実際に実行して結果を記録する
- 動く機能／壊れている機能／未実装の機能を分けて一覧にする
- 根拠（実行したコマンドと出力）を各項目に添える
2. ゴールとの差分を書く
- ゴール: 〈例: 〇〇の形式も読めるようにする〉
- ゴールに足りないものを、依存関係の順に並べる
3. 計画を出して止まる
- 各項目の作業量の目安と、途中で止めてよい区切りを示す
- ここで止まり、私の確認を待つ2ターン目で「計画のうち1〜3を進めて。区切りごとにテストを回してコミット」と頼みます。コミットを区切りごとに分けさせると、後から差分を読み返しやすくなります。Simonさんの42コミットも、1つの大きな変更ではなく小さな積み重ねとして残っています。
Simonさんは、大きく前進した0.2a0を「まったく信用していない」と書き、alpha版として出しています。これは謙遜ではなく、正しい扱い方だと思います。評価と計画が上手でも、出てきたコードの正しさは別の話です。
特にバイブコーディングでは、テストもAIが書いています。テストが通ったことは、AIが自分で決めた基準を満たしたという意味でしかありません。WebAssemblyのように公式の仕様やテスト集がある分野なら、それに照らして確かめられます。自作ツールの場合は、確かめる基準を自分で用意する必要があります。
レポートに「テスト○件成功」とあれば、そのコマンドを自分で1回打つ。全部を確かめる必要はありません。1つ再現できれば、レポートが実行結果にもとづいているかどうかはわかります。
実際に使いたいファイルやデータを1つ渡して動かします。AIが作ったテストデータだけで通っている状態から、一歩外に出すためです。
alpha、experimental、「自分用・保証なし」など。数か月後にまた放置から戻ってきたとき、どこまで信じてよいかが残っていれば、次の評価の出発点になります。
分けて考える。評価させるのは作業の順番を決めるため。信用してよいかは、自分で用意した基準で別に確かめる。
放置した自作ツールは、作った本人にとっても他人のコードです。そこにいきなり「直して」と頼むと、AIは目についたところから手をつけます。最初のターンで現状を評価させ、ゴールとの差分を並べさせ、計画を出したところで止める。それだけで、その後の作業は「リストを順に潰す」形になります。
そして、出来上がったものを信じてよいかは別に確かめます。Simonさんがalphaの印を付けたように、どこまで信じてよいかを書いておくことも再開の作法の一部です。
まとめ。再開プロンプトは評価→差分→計画→停止。評価は実行結果つきで出させ、信用はAIが書いていない基準で確かめる。
出典: Simon Willison's Weblog「pwasm 0.2a0」（2026年10月1日）。pwasmの経緯・コミット数・同梱物・alpha扱いは同記事の記述にもとづきます。速度や仕様準拠率の具体的な数値は元記事に記載がないため、本記事でも扱っていません。テンプレートは筆者が個人開発向けに再構成したもので、元記事のプロンプトそのものではありません。