---
title: Inspecting What Agents Build - エージェントが作ったものを、誰が検品するのか、Build → Inspect → Fix を4つの分野で実演 -
tags:  #github copilot #github copilot spec kit #.net #agentic commerce #xunit #iac #maker-checker #sdd #spec driven development #swiftui #azure container apps #azure sql database (native vector) #terraform #blender #mcp #spec kit #keyvault #managed identity #vector search #semantic search #vision+snapshot #claude sonnet 5 #openai text-embedding-3-small #microsoft foundry  
author: [Shotaro Suzuki](https://image.docswell.com/user/shosuz)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/L73WY9LD75.jpg?width=480
description: .NETラボ 勉強会 2026年9月 https://dotnetlab.connpass.com/event/399503/  エージェントは作れるようになりました。ですが多くは「動いた」で止まり、仕様どおりかは人が目で拾うことが多いのが実情です。本セッションでは、成功条件を差し替えます。SDD で何を作るかを先に構造化し、分野に合った "テスト"(機械で判定できる合否シグナル)で Build → Inspect → Fix を繰り返す maker-checker を、Agentic Commerce アプリを題材に、Infra IaC・コード(.NET/xUnit)・3D・Mobile の 4分野で実演します。追うべきはツールではなく型であり、4分野に共通するバックエンドは .NET です。
published: September 26, 26
canonical: https://image.docswell.com/s/shosuz/5L36X8-2026-09-26-180056
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/L73WY9LD75.jpg)

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


# Page. 2

![Page Image](https://bcdn.docswell.com/page/87DK5GN2JG.jpg)

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


# Page. 3

![Page Image](https://bcdn.docswell.com/page/VJPKG35LE8.jpg)

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


# Page. 4

![Page Image](https://bcdn.docswell.com/page/2EVV64P6EQ.jpg)

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


# Page. 5

![Page Image](https://bcdn.docswell.com/page/57GLN1P2EL.jpg)

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


# Page. 6

![Page Image](https://bcdn.docswell.com/page/4EQYQD29JP.jpg)

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


# Page. 7

![Page Image](https://bcdn.docswell.com/page/KJ4WNZPR71.jpg)

（参考）ゲームの⼤⼿事例も 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 はもう⼤⼿が本番に投⼊済み


# Page. 8

![Page Image](https://bcdn.docswell.com/page/LE1Y5R9V7G.jpg)

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


# Page. 9

![Page Image](https://bcdn.docswell.com/page/GEWG51Q3J2.jpg)

シード資産の全体像
商品データ・画像の下準備
商品カタログ
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 設定


# Page. 10

![Page Image](https://bcdn.docswell.com/page/47ZLNPWGJ3.jpg)

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


# Page. 11

![Page Image](https://bcdn.docswell.com/page/YJ6W8MGQJV.jpg)

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 単位で残せる
= この後の効率化と可視化の⼟台


# Page. 12

![Page Image](https://bcdn.docswell.com/page/GJ5M9ZV2J4.jpg)

参考︓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 で有効）


# Page. 13

![Page Image](https://bcdn.docswell.com/page/9E292R317R.jpg)

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


# Page. 14

![Page Image](https://bcdn.docswell.com/page/D7Y4YD14EM.jpg)

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


# Page. 15

![Page Image](https://bcdn.docswell.com/page/VENYP626J8.jpg)

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


# Page. 16

![Page Image](https://bcdn.docswell.com/page/Y79P3L1RE3.jpg)

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


# Page. 17

![Page Image](https://bcdn.docswell.com/page/G78DMX4G7D.jpg)

デモは 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・精度は⼈間側に残す


# Page. 18

![Page Image](https://bcdn.docswell.com/page/L7LM386XJR.jpg)

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


# Page. 19

![Page Image](https://bcdn.docswell.com/page/4EMYD653EW.jpg)

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


# Page. 20

![Page Image](https://bcdn.docswell.com/page/PER94P3RJ9.jpg)

作るところから検品まで、途切れずにつながる
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 の型は変わらない


# Page. 21

![Page Image](https://bcdn.docswell.com/page/P7XQ234YEX.jpg)

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


# Page. 22

![Page Image](https://bcdn.docswell.com/page/37K9MYZ47D.jpg)

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


# Page. 23

![Page Image](https://bcdn.docswell.com/page/LJ3WY9DDJ5.jpg)

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


# Page. 24

![Page Image](https://bcdn.docswell.com/page/8JDK5GP2EG.jpg)

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 で参照する（⼿元に持たない）


# Page. 25

![Page Image](https://bcdn.docswell.com/page/VEPKG3NL78.jpg)

デモ 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 が応答すれば合格）


# Page. 26

![Page Image](https://bcdn.docswell.com/page/27VV64K67Q.jpg)

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


# Page. 27

![Page Image](https://bcdn.docswell.com/page/5JGLN1Q27L.jpg)



# Page. 28

![Page Image](https://bcdn.docswell.com/page/47QYQDK9EP.jpg)

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


# Page. 29

![Page Image](https://bcdn.docswell.com/page/KE4WNZKRJ1.jpg)

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


# Page. 30

![Page Image](https://bcdn.docswell.com/page/L71Y5RXVJG.jpg)

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)


# Page. 31

![Page Image](https://bcdn.docswell.com/page/G7WG51N3E2.jpg)

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


# Page. 32

![Page Image](https://bcdn.docswell.com/page/4JZLNP3GE3.jpg)

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


# Page. 33

![Page Image](https://bcdn.docswell.com/page/YE6W8MXQEV.jpg)

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


# Page. 34

![Page Image](https://bcdn.docswell.com/page/GE5M9ZX2E4.jpg)

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


# Page. 35

![Page Image](https://bcdn.docswell.com/page/97292RX1JR.jpg)

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


# Page. 36

![Page Image](https://bcdn.docswell.com/page/DJY4YD847M.jpg)

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


# Page. 37

![Page Image](https://bcdn.docswell.com/page/V7NYP6Q6E8.jpg)

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


# Page. 38

![Page Image](https://bcdn.docswell.com/page/YJ9P3LDR73.jpg)

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


# Page. 39

![Page Image](https://bcdn.docswell.com/page/GJ8DMX3GJD.jpg)

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


# Page. 40

![Page Image](https://bcdn.docswell.com/page/LJLM38VXER.jpg)

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


# Page. 41

![Page Image](https://bcdn.docswell.com/page/47MYD6G37W.jpg)

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


# Page. 42

![Page Image](https://bcdn.docswell.com/page/P7R94PZRE9.jpg)

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


# Page. 43

![Page Image](https://bcdn.docswell.com/page/PJXQ239Y7X.jpg)

Thank you for your attention!