6月22日、Prismaが「Evolving Agentic Engineering at Prisma」と題した記事を公開した。AIエージェントを使った開発プロセスを実運用で試した結果、「重厚なプロセス」から「シンプルな設計と計画重視」へと方針を転換した経緯について詳しく紹介されている。
「プロセスを手厚くすること」が裏目に出た
Prismaはこれまで、AIエージェントを使ったエンジニアリングについて一連の記事（Agentic Engineering: How Prisma Builds with AI、Agentic Engineering at Prisma、Drive and the Maker）を公開してきた。今回はその続編にあたり、「実際にやってみて何が機能して、何が機能しなかったか」を正直に記したものだ。
最初のアプローチは重厚だった。構造化されたDriveプロセス、詳細なスキル定義、明確なステージ、複数エージェントによる実行モデル——これらを組み合わせた大規模なフレームワークを構築した。
この方法は実際に成果を出している。Prisma Nextでは、このアプローチによって数万件の変更を高品質に実施した。「エージェントは大規模な変更をこなせる」ことが証明された。
しかし、問題も見えてきた。詳細なスキル定義にはモデルやハーネス（エージェントの実行環境）に関する前提が大量に埋め込まれていた。当初はその前提が有用だったが、モデルが改善されるにつれ、前提が古くなる。弱いモデルを補助するために書いた冗長な指示が、強いモデルの邪魔になる。ハーネスの制限を回避するために書いたワークフローが、ハーネスが改善された途端に「ただの負債」になる。
結果として、チームがプロセス自体のメンテナンスに追われるようになる。
プロセスの設計、スキルの文言、モデルの挙動に関する前提、ハーネスの挙動に関する前提、評価基準、継続的メンテナンス——これらすべてを自分たちで抱えることになる。
と記事は指摘する。
「スキルはプロセスの説明書ではなく、インターフェースであれ」
転換後の方向性は対照的にシンプルだ。スキル（エージェントへの指示）の定義を絞り込み、インプットとアウトプットの契約だけを定義し、モデルの内部推論は指定しないという方針に移行した。
具体的には、スキルセットはほぼ次の5つに集約される：
- このスペックからプランを生成せよ
- このプランを元に次のマイルストーンを実行せよ
- このdiffをレビューせよ
- このレビューを元に修正を適用せよ
- このプロジェクトのサマリーを生成せよ
「スキルはブログ記事のように読めてはいけない。インターフェースのように読めなければならない」という表現が、この方針を端的に示している。
モデルに対して内部推論を指定しないことで、モデルが改善されても指示が「邪魔」にならない。スキルが出力の品質基準だけを定義し、推論はモデルとハーネスに任せる。
「計画」が唯一の真のボトルネックになる
スキルをシンプルにすると、計画の質がすべてを左右する。
記事はこう整理する。エージェントがコードを速く生成できるなら、コード生成はもはや希少リソースではない。希少なのは判断力であり、その判断は計画に集約される。
良い計画には次が含まれる：
- 何を変更するか、なぜ変更するか
- 何を変更しないか
- 関係するシステムはどれか
- 受け入れ基準とテストケース
- リスクとエッジケース
- エージェントが仮定してはいけないこと
これが整っていれば、実行エージェントは「曖昧なプロンプトからアーキテクチャ全体を推測する」必要がなくなる。定義されたプランを既知のコードベースに対して実行し、自分の成果物を検証するだけでよい。
この考え方が、より高性能なモデルを計画に使い、安価なモデルを実行に使うという構成につながっている。曖昧さはスペックと計画に集中しており、そこでのミスは下流に伝播する。計画が明確なら、実行は「狭い仕事」になる。
コスト感覚：1タスクで数百ドルが出た現実
記事は「トークン最大化に興味はない」としながらも、マルチエージェントワークフローで1タスクあたり数百ドルのコストが発生したケースがあったと開示している。「習慣的にやっていたわけではないが、何度か起きた」と述べ、それがコスト意識を高めるきっかけになったという。
こうした経験から、モデルやハーネス自体の最適化ではなく、プロセスの設計側で対応するという姿勢を明確にしている。モデルとハーネスの改善は他の優秀なエンジニアに任せ、自分たちはスキルと内部ツールとワークフローの「接着剤」を作ることに集中する、という分担だ。
オープンウェイトモデルとGremlin
こうした方向性の延長線上にあるのが、Prismaが開発したGremlinだ。開いたタスクをPRに変換するツールで、開発者がタスクを定義して渡し、後でレビュー可能なPRが返ってくるという形を目指している。エンジニアをループから外すのではなく、「価値の高い部分——問題の定義、計画、判断、レビュー、オーナーシップ——に集中させる」という思想だ。
チームへの示唆：標準化すべきは「原則」であってワークフローではない
記事が提示するリーダー向けの整理は明快だ。すべてのプロンプトを標準化するのも、各自に任せきりにするのも間違い。標準化すべきは原則であり、ワークフローの細部ではない。
標準化すべき原則（抜粋）：
- 大きな作業はスペックまたは同等のアーティファクトを生成する
- プランは実行を導くのに十分な明示性を持つ
- 受け入れ基準はテスト可能なものにする
- 実行にはレビューループを含める
- 人間のレビューが判断を担う
- 不確実性は隠さず表面化させる
コード品質基準は交渉不可、とも明記されている。
「エージェントプロセスは過渡的なものだ」——記事はこう結ぶ。今日の不完全なツールから明日のより良いツールへ橋渡しするためにあるのであって、永遠に最適化し続けるものではない、という立場だ。
詳細はEvolving Agentic Engineering at Prismaを参照していただきたい。
