Cloudflareは2026年4月にEmDashを出荷しました。TypeScriptで書かれたオープンソースCMSで、AIコーディングエージェントが約2か月で構築しました。これは本当に見事な成果で、業界がどこへ向かっているのかを示す確かなシグナルです。
しかし同時に、AIコーディングの会話が避けてきた疑問も浮かび上がります：AIが最初のバージョンを出荷した後、何が起きるのか？
「読みは良いが、うまく作れない」計画の問題
AI支援のコードベースで私が繰り返し見ている失敗パターンがあります。最初のビルドは速い。計画に書かれた文章は権威あるように読める。コードはコンパイルでき、テストも通る。3週間後、2人目のエンジニアが拡張しようとすると、うまく噛み合わない。エージェントのナラティブが説得力はあっても、前提となる制約については正しくなかったからです。
これはモデルの問題ではありません。最前線のモデルは、もっともっともっとそれらしいコードを書くのが上手くなっていくでしょう。問題はワークフローの問題です。エフェメラルなエージェントのセッションを、耐久性がありレビュー可能なアーキテクチャ上の意思決定へと変換する層が欠けています。
欠けている層がどのようなものか
私たちは、このギャップを埋めることを念頭に、rp1を作ってきました。3つのアイデアで、それぞれ特定の失敗パターンに直接対処します。
1. 憲法（コンスティチューション）に基づくプロンプト
「プロンプトエンジニアリング」の多くは加算的です。つまり、モデルの上に指示を積み重ねて、うまくいくことを祈る。憲法に基づくプロンプトは減算的です。ワークフローが、専門家が制約として従うはずのパターンを、制約としてエンコードします。/buildはプロンプトではなく、パイプラインです：
- 要件からブループリントを生成する
- 既存のコードベースに関する仮説を立てる
- 何かを書く前に、実際のコードに対して仮説を検証する
- 検証済みの計画に基づいて実装する
- 検証（verification）を実行する
仮説の検証ステップが、「計画は読みは良いが、ListViewに関する前提が違っている」といった種類のバグを見つけてくれます。
2. 知識を踏まえたエージェント
ほとんどのAIコーディングセッションは何もない状態から始まります。毎回、アーキテクチャを説明し直すことになります。rp1の/knowledge-buildは一度だけ実行され、コードベースを永続的な知識ベースへとマッピングし、以後のすべてのコマンドがそれを引き継ぎます。
実務的な効果はこうです。あなたのパターンを無視した汎用的なアドバイスが出てこなくなります。/buildのたびに、想像上のシステムではなく、実際のシステムを完全に把握した状態から始まります。
3. 耐久性のあるアーティファクト
すべてのrp1ワークフローは、検査可能な設計ドキュメントを生成します。要件、設計、仮説、検証、レポートなどが、チャットのスクロール履歴に閉じ込められるのではなく、プロジェクトに紐づいて添付されます。
これはオンボーディングのための基本要素です。2人目のエンジニアが
AIで作られたコードベースに参加するとき、理解のために毎回再度プロンプトを工夫していく代わりに、何が決まり、なぜそうなったのかを読めるようになります。
試してみる
rp1はオープンソースで、Claude Code、OpenCode、Codex、GitHub Copilot CLIにまたがって動作します。 同じワークフローで、異なるハーネスです。
EmDashのようなコードベースで、これが具体的にどう機能するかについての全文はブログにあります：rp1 on EmDash — AIで作られたコードベースをナビゲート可能にするワークフロー層.
もしエージェントが書いたコードベースをメンテナンスしているなら、Premと私としては、本当に「何が壊れているのか」を聞きたいです。それが、ここまで私たちが作ってきたものすべてを形づくってきたフィードバックです。
rp1はPrem Pillai（@cloud_on_prem）とMahesh Shivamallappa（@maheshs786）によって作られています。
