AIエージェント設計の5つの型は、どう噛み合うのか ── 競合しない「補完スタック」という見方

はじめに ── 前回の続きから

前回、AIエージェントを「一台の車」にたとえました。

https://zenn.dev/ukiajp/articles/ai-agent-trunk-roots-car

エンジン（モデル）ばかりが語られるけれど、車として人や荷物を運ぶには、車体・タイヤ・計器盤・安全装備……その全部が要る、という話です。

そして最後に、車のパーツひとつひとつに、海外できちんと名前のついた「設計の型」があると述べました。

今回はその型について、もう一段くわしく描きます。

先に結論を言っておきます。

これらの型は競い合うものではありません。

車の別々のパーツを埋め合う「補完スタック」です。

だから問いは「どれを選ぶか」ではなく、「いま自分たちにどの層が欠けているか」になります。

正直に言うと、この記事は私自身の学びの整理でもあります。

海外で出てきた型を、自分の現場の判断軸に落とし込んでいく——その過程をそのまま書きます。

5つを役割で並べる

まずそれぞれが、車のどこを担うかで並べます。

■本筋（パイプライン）

• 仕様駆動開発（SDD）… 何を作るか（目的地・行き先）
• ハーネス工学… どう安全に走らせるか（車体・骨格）
• 評価駆動開発（EDD）… 正しい、適切と言えるか（計器盤・車検）

■それらを貫く作法

• 12-Factor Agents… どう作るか。上の3つすべてに効く横断ルール（車づくりの作法）

■全体を包む外周

• OWASP / NIST… 安全か・統治されているか（安全装備・交通ルール）

ここで、ひとつ気づくことがあるかもしれません。この5つに、エンジン（AIモデル）が入っていないのです。

ではエンジンはどこにいるのか。この5つに囲まれた、ちょうど真ん中です。
(後ほど図で示します)

仕様（SDD）で行き先を与えられ、器（ハーネス）に載せられ、作法（12-Factor）で律せられ、検証（EDD）で測られ、外周（OWASP/NIST）で守られて、はじめてエンジンは「車」として仕事をします。

エンジン単体は、剥き出しのエンジンにすぎません。

そしてそのエンジンは、いずれ差し替わる枝葉です。

今日話すのは、その周りの——車を車たらしめている、幹と根の部分です。

これらは競合しない ── 別レイヤーを埋め合う「補完スタック」

新しい型が次々に出てくると、「結局どれが正解なの？」「SDD派？ EDD派？」という流派対立のように見えてしまいます。

でも、よく見ると埋めている層が違います。

何を作るか（SDD）、どう走らせるか（ハーネス）、どう作るか（12-Factor）、正しいか（EDD）、安全か（OWASP/NIST）。

これらは対立ではなく、ソフトウェア開発の別々の層に対応しています。

図にすると、こうです。

SDDが入口を固め、ハーネスの器で動かし、EDDで検証する。

12-Factorはそのすべてに規律を与える串。そしてOWASP/NISTが全体をぐるりと包む。

5つで1つのスタックです。

そして、行き先を決め、最後に「これでいい」と承認するのは人間です。

エンジンも5つの型も、人間が閉じるループの中で動きます。

価値は「導入順序」にある

この地図のいちばんの実用価値は、入れる順番だと思っています。

• SDD（入口）… まず「何を作るか」を仕様として固める。ここが曖昧なまま走らせると、AIは平気で別の方向へドリフトします
• ハーネス（器）… その仕様を、暴走させず最後までやり切らせる器に載せる
• 12-Factor（規律）… 器づくりと実装に、差し替えに耐える設計の作法を効かせる
• EDD（検証）… 「正しく動いている」を雰囲気ではなく数値で言えるようにする
• OWASP / NIST（外周）… 全体をセキュリティとガバナンスで包む

おもしろいのは、この順番がどんなエンジン（AIモデル）を積もうと変わらないことです。

エンジンは差し替わっても、土台から外周へという組み立て順は崩れません。

順番が逆になると痛い目に遭います。たとえば、何を作るかが決まっていない（SDDが無い）のに高性能な器（ハーネス）を用意しても、立派な車で目的地のないドライブをするだけです。

前回の「目的地が車を決める」は、ここに効いてきます。

誤解されやすい、重なる領域

「層が違う」と言いましたが、一部は重なって見えます。ここを整理しておくと、混乱しません。

• SDDの「検証基準」 ⇔ EDDの「eval」… 実は同じものを別の粒度で呼んでいます。仕様側では「合否条件」、運用側では「計測指標」
• ハーネスの「人間を介す承認」 ⇔ 12-Factorの「人間連絡もツール呼び出し」… 同じ思想（人間を制御ループに組み込む）を、別の文脈で言っているだけ
• OWASP（技術的脆弱性） ⇔ NIST（組織統治）… 層が違うので競合せず、積み重なる。OWASPは現場の防御、NISTは組織のガバナンス

重なって見えるものは、たいてい「対立」ではなく「同じ思想の別の顔」です。

だから、問いは「どれを選ぶか」ではない

ここまで来ると、最初の問いが変わります。

「SDDとEDD、どっちを採用すべき？」ではなく、「自分たちのチームは、いまどの層が欠けているか」。

• 仕様が人の頭の中にしかない → SDDが欠けている

• AIが途中で迷子になる・勝手に完成宣言する → ハーネスが欠けている

• モデル（エンジン）を替えるたびに作り直している → 12-Factorが欠けている

• 「なんとなく動いてる」で本番に出している → EDDが欠けている

• 権限と責任の設計が後回し → OWASP/NISTが欠けている

私のような立場（業務自動化の設計アドバイザー）の仕事は、まさにここです。

全部を一度に入れさせるのではなく、いちばん欠けている層を見つけて、そこから足す。

前回の「現場は今の道で最高の車を、上流は道を舗装する」も、結局は「どの層から手をつけるか」という話でした。

抽象論で終わらせない ── 海外ではもう数字が出ている

ここまで「地図」の話をしてきました。「で、それは本当に効くの？」と思われたかもしれません。

各型は、すでに海外の本番現場で数字を出しています。さわりだけ並べます。

• SDD：仕様を起点にする「GitHub Spec Kit」はOSSで9万超のスター。非自明なタスクで初回成功率が3〜10倍という早期報告もあります（GitHub / AWS）
• ハーネス：前回の再掲ですが、同じモデルでも足場の設計だけで、ベンチマークが20ポイント以上動きます
• 12-Factor：100人超の創業者・AIエンジニアへの聞き取りから生まれた、現場発の原則（2011年Herokuの「12-Factor App」へのオマージュ）
• EDD：Notionはeval（評価）を導入後、不具合修正のペースが1日3件から30件に。Stripe・Vercel・Zapierなども本番で回しています
• OWASP / NIST：「Agentic Top 10」は2025年末に公開され、日本でもAI事業者ガイドラインが自律型エージェントを対象に取り込み始めました（v1.2）

数字の出典も、それぞれの「どう作るか」も、ここでは深追いしません。それは各回の主役だからです。

次回から、1枚ずつ分解する

地図はこれで描けました。今回はあくまで「型」「地図」までです。

「どう作るか」という具体的なコードや設定は、ここから先で1枚ずつ、手を動かしながら見ていきます。各回、こんな形で書く予定です。

• どんな失敗の文脈から、その型が生まれたのか
• 型の中身（仕様・具体的な設定やコード）
• 海外の現場事例
• そして、私が現場でどう翻訳して使うか

まずは入口の 仕様駆動開発（SDD） から。

「動くものを作る前に、何を作るかをどう固定するか」という、いちばん地味で、いちばん効く層の話をします。