Inspecting What Agents Build - エージェントが作ったものを、誰が検品するのか、Build → Inspect → Fix を4つの分野で実演 -

Inspecting What Agents Build エージェントが作ったものを、誰が検品するのか、 Build → Inspect → Fix を 4 つの分野で実演 Shotaro Suzuki Executive Evangelist FPT Japan Holdings

鈴⽊ 章太郎 X (Twitter) : @shosuz • FPT Japan Executive Evangelist • 独⽴⾏政法⼈国⽴印刷局 デジタル統括アドバイザー • Microsoft MVP for Developer Technologies (.NET/Developer Tools) • 元 Microsoft Technical Evangelist • AI 駆動開発勉強会 主催 https://aid.connpass.com/

• https://aid.connpass.com/

RevenueCat主催のグローバルイベントで8月1日から9月末まで開催 2か月間、アプリ開発 ストア公開 マネタイズ をオンラインで競う 高額賞金 VC支援 NYC表彰式 他豪華特典。参加資格不問 完全無料 昨年は世界で50,000人以上が参加。アプリ総売上は10億円突破 優勝した「Payout」は、2週間で開発し約500万円の売上を達成 300万ダウンロードを達成するアプリなどソロプレナーが続々誕生

Codex ではじめるエージェンティックコーディング --AI エージェントによる⾃律的システム開発ガイド 9/10 発売 https://amzn.asia/d/0g8bJDp0

• https://amzn.asia/d/0g8bJDp0

仕様駆動開発 (SDD) で「何を作るか」を先に構造化し、 そのドメインに合った "テスト"（機械で検証できる合否シグナル）で フィードバックループを回す CLAIM 「動いた」では終わらない 成功条件を、仕様どおりへ

「テスト」の形は分野（ドメイン）で変わる 同じ型が別の分野でも成⽴する - 今回はインフラ・コード・3D・モバイルの 4 つを実演 分野 インフラ コード 3D テスト（検証）の形 Terraform plan / validate（構⽂・計画） ＋ デプロイ直後のスモークテスト 型・ユニット / 統合テスト バックエンド（.NET API）= xUnit レンダリング画像を vision で検証 モバイル フロント（SwiftUI）= スクショ + vision ゲーム ビルド / 経路探索 / アセット取込 = 機能テスト ⾃動判定の度合い 今回 実演 ⾼い（構⽂＋疎通） 今回 実演 ⾼い（Spec Kit の世界） 今回 実演 中（⾒えるミスに強い） 今回 実演 ⾼い（本命） 機能は可（feel は⼈間） 💡 追うべきはツールでなく型 - フロントを替えても同じ型が有効（バックエンドは .NET）

（参考）ゲームの⼤⼿事例も vision で検品を⾃⾛ スクウェア・エニックス @ Gemini Enterprise Agent Platform（Google Cloud Next Tokyo '26） vision = AI が画像を「⾒て」検証 ・画⾯を⾒て状況を理解し、コントローラを操作 ・マップを開き、⽬的地へキャラを動かして検証を ⾃⾛ ・思考過程とタスクリストを表⽰しながら実⾏ → ゲームでも機能⾯は機械で検品できる 残るのは feel（⼈間） https://www.itmedia.co.jp/aiplus/article/2607/31/2000000322/ 💡 vision = AI が画像を⾒て検証 - この checker はもう⼤⼿が本番に投⼊済み

• https://www.itmedia.co.jp/aiplus/article/2607/31/2000000322/

Agentic Commerce アプリ - GearMate 初⼼者向けの楽器を探し、⽇本語 / 英語で相談して選び、カートで購⼊するまで 商品を探す （セマンティック検索) ⽇本語 / 英語で相談する （エージェント推薦) 💡 この画⾯が仕様であり、検品の突合先になる カートで購⼊

シード資産の全体像 商品データ・画像の下準備 商品カタログ 100 件 GPT Image 2.5 / Blender 画像⽣成 • • • 商品画像 100 枚 digimart 調・ロゴなし Azure Blob 公開ホスト アプリで表⽰ Azure SQL / SwiftUI 商品カタログを 100 件登録（ギター 30 / ベース 30 / アンプ 20 / マルチエフェクター 20）- description / tags / 価格 / 在庫 ギター・ベースの商品画像は ChatGPT App の GPT Image 2.5 で⽣成（digimart 調・架空ブランド・ロゴなし）、アンプとエフェ クターは Blender で作ってシードへ Azure Blob の公開コンテナにアップロード、catalog に imageBaseUrl 設定

1 つの spec から、1 タスクへ task.md がこの後のデモ 4 本すべての⼊⼝になる Spec とは︖: 作るものを、⼈と AI が同じ意味で読める形に書いたもの 💡 spec は 1 つ、⼊⼝は 1 タスク - インフラ・コード・3D・モバイルは全部ここから枝分かれ

GitHub Copilot × Spec Kit - まず「何を作るか」を構造化する specify → plan → tasks で作業をタスク単位に割る（実際には 7 + 3 コマンド） 必須 5 コマンド - 上流から実装まで⼀直線 1. constitution 原則・制約 （唯⼀の基準） 2. specify 3. plan 4. tasks 仕様(What) 設計(How) 作業単位に分解 5. implement 実装 任意 3 コマンド - 必要に応じて組み込む(品質と精度を上げる) clarify analyze checklist spec を精緻化 整合をチェック 品質観点を追加 tasks が実装の単位になる → だから消費を task 単位で下げられ、過程も task 単位で残せる = この後の効率化と可視化の⼟台

参考︓Spec Kit のコマンド⼀式 - 必須 7 + 任意 3 すべて /speckit-プレフィックス（例: /speckit-specify）。taskstoissues は 2025-11、converge は 2026-06 に追加 ① ② ③ ④ ⑤ ⑥ ⑦ constitution specify plan tasks tasksto issues implement converge 原則・制約 仕様（What） 設計（How） 実装単位に分解 Issue 化 実装 残タスクを追加 🧩 任意 3 コマンド - 必要に応じて差し込む（品質と精度を上げる） ・clarify - spec の曖昧な箇所を対話で詰める（plan の前に推奨。旧 /quizme） ・analyze - spec / plan / tasks の整合と網羅をチェック（tasks の後、implement の前） ・checklist - 要件の完全性・明確さ・⼀貫性を検証する品質チェックリストを⽣成 💡 converge は既存コードを spec / plan / tasks と突き合わせ、未実装分を tasks.md に追加する（brownfield で有効）

Task → Build → Inspect（テスト）→ Fix の 1 周の実演 作る側と検証する側を分ける、maker-checker の考え⽅ Task SDD, task.md → Build エージェントが ⽣成・描画 → Inspect テストで検証 画像を vision で突合 → Fix ズレを直して 再実⾏ テストが不合格なら戻り、合格するまで反復 - これが maker-checker の checker 💡 成功条件は「動いた」ではなく「仕様どおり」。checker を分けるのが設計の勘所

LOOP 実演するループ Build → Inspect → Fix を 1 周

「テスト」の形は分野（ドメイン）で変わる 同じ型が別の分野でも成⽴する - 今回はインフラ・コード・3D・モバイルの 4 つを実演 分野 インフラ コード 3D テスト（検証）の形 Terraform plan / validate（構⽂・計画） ＋ デプロイ直後のスモークテスト 型・ユニット / 統合テスト バックエンド（.NET API）= xUnit レンダリング画像を vision で検証 モバイル フロント（SwiftUI）= スクショ + vision ゲーム ビルド / 経路探索 / アセット取込 = 機能テスト ⾃動判定の度合い 今回 実演 ⾼い（構⽂＋疎通） 今回 実演 ⾼い（Spec Kit の世界） 今回 実演 中（⾒えるミスに強い） 今回 実演 ⾼い（本命） 機能は可（feel は⼈間） 💡 追うべきはツールでなく型 - フロントを替えても同じ型が有効（バックエンドは .NET）

DOMAINS テストの形は分野で変わる インフラ / コード / 3D / モバイル

デモは 1 本のシナリオ - Agentic Commerce 同じ spec を 4 つのテストで検証 - IaC / .NET バックエンド / Blender 3D / SwiftUI フロント デモ 1 - インフラ（IaC） Gearmate spec 予算・楽器種別 ⽐較・購⼊ = 合否の基準 Terraform で Azure を⽤意 デモ 2 - コード（.NET） → バックエンド API を実装 デモ 3 - 3D（Blender） 箱物を⽣成 → シードへ（MCP） デモ 4 - モバイル SwiftUI でフロントを実装 checker : plan / validate + スモークテスト checker : xUnit（型・統合テスト） checker : レンダを vision で検証 checker : スクショ + vision / snapshot 4 つの checker が、同じ 1 つの spec と突合する = 同じ型が別の分野で成⽴ 💡 写実の精度（本物に⾒えるか）は合否に⼊れない - generic・精度は⼈間側に残す

SCENARIO デモは 1 本のシナリオ - Agentic Commerce Blender が商品画像を⽣成し、SwiftUI アプリで表⽰

進め⽅は 4 つのデモで同じ Task → Build → Inspect → Fix の順番は変わらず、道具だけが分野ごとに変わる 💡 分野ごとに変わるのは Build と Inspect で使う道具

作るところから検品まで、途切れずにつながる Spec Kit → GitHub Copilot → .NET → Blender MCP → Skill Spec Kit 仕様を構造化 → • • GitHub Copilot 仕様との差分を → レビュー .NET/Azure （Container Apps・SQL） バックエンド API Blender MCP Skill 3D 商品画像を 検品を⾃動化 → → ⽣成 デモ 1 = インフラ（IaC） デモ 2 = コード（.NET） デモ 3 = 3D（Blender） デモ 4 = モバ イル（SwiftUI） Build → Inspect → Fix を各デモで実演する 💡 ツールは⼊れ替わっても、Build → Inspect → Fix の型は変わらない

全体像 ̶ Azure 上の⽬標構成（この後 IaC で実現） Azure（⽬標構成） iOS アプリ SwiftUI Azure VNet Container Apps .NET 10 / EF Azure SQL Native Vector

DEMO 作るところから検品まで、途切れずにつながる Spec Kit → Copilot → .NET → Blender MCP → Skill

インフラも仕様が決める（⾮機能要件） ⾮機能要件として Azure SQL（vector）と Container Apps を constitution に定義、それに沿って IaC で⽤意 - 鍵は⼿元に置かない Vector とは︖: ⾔葉を数値の並びにして、意味の近さで探せるようにしたもの IaC = コードでインフラを⽤意すること インフラも場当たりでなく、constitution（⾮機能要件）に沿って⽤意する

Terraform ⽣成 GitHub Copilot plan / validate 構⽂・計画の検証 apply Azure に反映 Azure SQL(vector) + Container Apps テスト（checker）: デプロイ直後の最⼩確認 - 検索結果が 1 件返り、API の URL が応答すれば合格 IaC AI IaC - ⾮機能要件に沿って DB と API を⽤意する • Terraform で Azure SQL（vector）と Container Apps を⽤意し、API を配置する • 鍵は Key Vault に置き、Managed Identity で参照する（⼿元に持たない）

デモ 1 - インフラ（IaC / Terraform） constitution（⾮機能要件）に沿って Azure SQL（vector）と Container Apps を⽤意する Task task.md （1 タスク） → Build Terraform ⽣成 → apply → ★ Inspect plan / validate + スモークテスト → Fix 直して再実⾏ ↺ 反復 ✗ 不合格なら Fix → Build へ戻り、合格まで反復 💡 checker = 構⽂・計画の検証 + デプロイ直後の最⼩確認（検索が 1 件返り、 API が応答すれば合格）

▶ 録画 - IaC 適⽤ → デプロイ直後の最⼩確認が合格

ソリューション全体像 ̶ ローカルで作り、Azure へデプロイ ローカル（開発） VS Code ̶ ローカル実⾏ iOS アプリ SwiftUI .NET 10 API / EF / Seed Azure（デプロイ後） Azure VNet iOS アプリ SwiftUI Container Apps .NET 10 / EF Azure SQL Native Vector

デモ 2 - コード（.NET xUnit） Agentic Commerce のバックエンド API を .NET で作る（ローカル） Task task.md （1 タスク） → Build .NET で実装 → ★ Inspect xUnit で検証 → ↺ 反復 ✗ 不合格なら Fix → Build へ戻り、合格まで反復 💡 checker = 型・ユニット / 統合テスト（Spec Kit の世界） Fix 直して再実⾏

Products ProductTags Id (PK) Brand Name Category Price / Stock ProductId (FK,PK) Value (PK) ShopperProfiles InstallId (PK) Budget Preferred*Json (好み) Carts InstallId (PK,FK) UpdatedAt ProductEmbeddings ProductId (FK,PK) Model / Dimensions Vector vector(1536) ContentHash Consultations InstallId (FK,PK) ProductId (FK,PK) Quantity UnitPriceSnapshot Id (PK) CatalogHash ProductCount Status RecommendationSnapshots Id (PK) InstallId (FK) Query / SemanticQuery Degraded CartItems CatalogSeedRuns Id (PK) InstallId (FK) ProfileVersion Orders Id (PK) OrderNumber (UQ) InstallId (FK) Total DATA MODEL データモデル 11 テーブル / 意味ベクトルは ProductEmbeddings.Vector（1536 次元）に持つ CheckoutOperations InstallId (FK,PK) IdempotencyKey (PK) OrderId (FK)

▶ デモ動画 - バックエンド⽣成 → xUnit が不合格から合格へ → セマンティック検 索（意味の近さで探す検索）が返る

デモ 3 - 3D（Blender MCP） アンプ / エフェクター（箱物）を Blender で⽣成 → シードへ（MCP 経由） Task task.md （1 タスク） → Build Blender で⽣成 （MCP） → ★ Inspect vision で検証 → Fix 直して再実⾏ ↺ 反復 ✗ 不合格なら Fix → Build へ戻り、合格まで反復 💡 checker = レンダを vision で検証（フレーム内 / マテリアル / ⽩⾶び）

▶ デモ動画 - 3D（Blender build → 検品 → fix）

デモ 3 補⾜ - 不合格の実例 ① フレーム外 被写体がフレームから外れたレンダを checker が落とす ✗ 不合格 ✓ 修正後 （被写体が切れている） 💡 checker が⾒るのは、被写体がフレーム内にあるかどうかだけ

デモ 3 補⾜ - 不合格の実例 ② マテリアル未割当 マテリアルが割り当たっていない⾯を checker が落とす ✗ 不合格 ✓ 修正後 💡 未割当は⾒た⽬の好みではなく、機械が確実に落とせる⽋陥

デモ 3 補⾜ - 不合格の実例 ③ ⽩⾶び ハイライトが⾶んだレンダを checker が落とす ✗ 不合格 ✓ 修正後 💡 ⽩⾶びは閾値で判定できる - 写実の良し悪しとは別の軸

SwiftUI ⽣成 GitHub Copilot ビルド 不⼀致 → fix して戻る SwiftUI SwiftUI - ⽣成して検品 スナップショット / vision で仕様と突合 → fix スクショ vision + snapshot で仕様と突合 ⼀致 → OK

デモ 4 - モバイル（SwiftUI） 実データを表⽰・相談・カート・購⼊するネイティブ アプリ（API は .NET on Azure Container Apps） Task task.md （1 タスク） Build → SwiftUI 実装 ★ Inspect → snapshot + vision Fix → 直して 再実⾏ ↺ 反復 ✗ 不合格なら Fix → Build へ戻り、合格まで反復 💡 checker = スクショ + vision、スナップショットで回帰（バックエンドは .NET）

相談チャットの中⾝ - AI が組み⽴てる Claude が理解と説明／実データは検索で取る（でっち上げない） 相談 ⽇本語の質問 Claude 理解 → 条件 OpenAI 埋め込み Azure SQL vector 検索 Claude 推薦理由 候補 商品 + 理由 モデル: Claude Sonnet 5（理解・推薦理由）/ OpenAI text-embedding-3-small（埋め込み）

▶ デモ動画 - SwiftUI が API を呼んで画⾯に出る

デモ 4 補⾜ ̶ スクリーンショットを仕様と突合 仕様と⾷い違った画⾯を vision が落とし、修正後に合格する ✗ 不合格 vision:「商品名が⻑すぎて右端で⾒切れている」 仕様: 収まらない名前は末尾を … で省略する ✓ 合格 修正後: 末尾を … で省略して収める

まとめ︓「テスト」の形は分野（ドメイン）で変わる 同じ型が別の分野でも成⽴する - 今回はインフラ・コード・3D・モバイルの 4 つを実演 分野 インフラ コード 3D テスト（検証）の形 Terraform plan / validate（構⽂・計画） ＋ デプロイ直後のスモークテスト 型・ユニット / 統合テスト バックエンド（.NET API）= xUnit レンダリング画像を vision で検証 モバイル フロント（SwiftUI）= スクショ + vision ゲーム ビルド / 経路探索 / アセット取込 = 機能テスト ⾃動判定の度合い 今回 実演 ⾼い（構⽂＋疎通） 今回 実演 ⾼い（Spec Kit の世界） 今回 実演 中（⾒えるミスに強い） 今回 実演 ⾼い（本命） 機能は可（feel は⼈間） 💡 追うべきはツールでなく型 - フロントを替えても同じ型が有効（バックエンドは .NET）

Thank you for your attention!