コーディングエージェントへの指示の出し方3通り：仕様書、プロダクトモデル、まっさらな目でのレビュー

間違ったものを出してくるコーディングエージェントは、たいてい依頼は理解していて、製品を誤解しています。2026年後半の興味深い問いは、もはやどのエージェントを使うかではなく、どう指示を出すかで、それに対して3つの異なる答えが現れています。違いは一点です。何を書き留めるか、そしてそれをどれだけ長く残すかです。

仕様駆動：変更ごとに1つの文書

最も広く採用されている方法は、機能ごとに仕様書を書き、次に計画とタスク一覧を書いて、エージェントにそれに沿って作らせるものです。Spec Kit（4.3）はGitHubによるもので、スターは約143,000、実装を文書と照らし合わせる収束のステップがあり、40以上の名前付きエージェントに対応しています。BMAD-METHOD（3.8）は、複数のペルソナを使って同様の範囲を扱います。強みは、取り決めがgitの中にあり、コードと同じようにプルリクエストを通ることです。代償は読む時間です。Scott Logicが公表した試験では、人によるレビューに機能1つあたりおよそ2〜3.5時間かかりました。そのため、どちらのツールも小さな修正向けの軽い手順を用意しています。

プロダクト駆動：常に存在する1つのモデル

より新しい流派は、仕様書が記述するのは変更であって製品ではなく、そのため製品が毎回一から組み立て直されてしまうと主張します。pdd-kit（3.7）は、gitで管理する単一のプロダクトモデル（エンティティ、ジャーニー、ビジネスルール、バリエーション）を持ち、すべてのエージェントが推測する代わりにそれを読みます。コードをそのモデルと照合する検証のステップもあります。仕様書のフォルダより鋭いアイデアですが、まだ初期段階です。スターは約97でメンテナーは1人、そしてコードから遅れたモデルは、モデルがないとき以上にエージェントを惑わせます。元が取れるのは本当に複雑なドメインを持つ製品で、CRUDアプリではありません。

レビュー優先：まっさらな目に穴を見つけさせる

3つ目の方法は、下書きを書くエージェントは自分の盲点を見落とすものだと受け入れ、会話を一度も見ていないレビュアーを呼び込みます。GoogleのオープンソースプラグインElephant-Goldfish Model（4.2）は、深いコンテキストを持つエージェント（Elephant）に設計を書かせ、それを文書と引用元だけを読むコンテキストのないサブエージェント（Goldfish）に渡します。設計を生んだチャットに頼れないため、Goldfishは明示されていない前提を浮かび上がらせます。手法はよく練られており、すでにスターは約6,500です。注意点は、新しいサブエージェントを起動できるハーネスが必要なことで、それができない環境ではレビューを装わずに止まります。

ワークフローパックの位置づけ

これらと並んで、Superpowers（4.7）のような汎用のワークフローインストーラーがあります。仕様書の形式を指定せずに、エージェントに計画と自己点検の習慣を身につけさせるものです。3つの指示のスタイルのどれとも競合せずに組み合わせられ、最も手間をかけずに始められる場所です。

どれを使うか

1行の修正なら、どれも不要です。git、テスト、ファイル名を挙げた短いプロンプトで十分です。コードの前に設計の判断が必要な機能なら、エージェントがサブエージェントに対応している限り、レビュー優先が最も少ない執筆量で最も多くの本物のバグを見つけます。監査人が後で読む規制対象の変更なら、仕様駆動の記録が残ることこそが目的です。そして、エージェントが同じルールを何度も作り直してしまう複雑な製品なら、誰かが最新の状態に保つ場合に限って、プロダクトモデルは維持の手間に見合う価値があります。