--- title: AI が書いたコードのセキュリティを AI に検品させる - Claude Code Codex で Build → Inspect → Fix tags: #github copilot #claude #codex #github #claude code #azure #openai #anthropic #security #idor #bola #spec kit #sdd #spec driven development #agentic commerce #shipaton 2026 #maker #checker #github copilot cloud agent #claude security #codex security #security review author: [Shotaro Suzuki](https://image.docswell.com/user/shosuz) site: [Docswell](https://www.docswell.com/) thumbnail: https://bcdn.docswell.com/page/27VV1P6Y7Q.jpg?width=480 description: https://creator-square.connpass.com/event/406047/ 【受付12:55開始】秋のAI駆動開発勉強会（Claude Code / Codexの最前線） published: October 11, 26 canonical: https://image.docswell.com/s/shosuz/KDMQPR-2026-10-11-141012 --- # Page. 1 ![Page Image](https://bcdn.docswell.com/page/27VV1P6Y7Q.jpg) AI が書いたコードのセキュリティを AI に検品させる - Claude Code / Codex で Build → Inspect → Fix - Shotaro Suzuki Microsoft MVP for Developer Technologies (.NET / Developer Tools) Developer Advocate © 2026, Developer Advocate, LLC. # Page. 2 ![Page Image](https://bcdn.docswell.com/page/5JGL2PNW7L.jpg) 鈴⽊ 章太郎 X (Twitter) : @shosuz FPT ジャパン エグゼクティブエバンジェリスト 独⽴⾏政法⼈ 国⽴印刷局 デジタル統括アドバイザー兼最⾼情報セキュリティアドバイザー Microsoft MVP for Developer Technologies (.NET/Developer Tools) 合同会社デベロッパーアドボケイト 代表社員チーフアドボケイト Developer Advocate 略歴︓ Microsoft エバンジェリスト時代(2003年)から、Dell、Accenture、Elastic、VMware を 経て現職まで、20年に渡り⼀貫して開発者向けに最新技術を啓発。NVIDIA GPU クラウド 技術訴求、 AI 駆動開発コンサルティングを実施。 AI 駆動開発勉強会主催。 AI 駆動 開発コンソーシアム副座⻑。 政府の仕事は、内閣官房 IT 総合戦略室 政府 CIO 補佐官（併任︓法務省 CIO 補佐官、第4次安倍改造内閣、 2019年4⽉〜）、 デジタル庁 PM（併任︓⾦融庁 デジタル統括アドバイザー、菅内閣、2021年9⽉〜）を経て2024年10⽉より現職を兼務。 AI 駆動開発トレーニング、AI 駆動開発コンサルティング、技術顧問、技術マーケティング ⽀援、クラウドトレーニング、を提供する合同会社デベロッパーアドボケイトを2022年設⽴。 https://shotaro-evangelist.carrd.co / https://www.docswell.com /user/shosuz MCT (Microsoft 認定トレーナー) としてエディフィストラーニング社においてGH-300 コース 担当の他、多くの AI 開発系トレーニング講師を担当。 Google Cloud Partner All Certification Holder 2025 。 Developer Advocate © 2026, Developer Advocate, LLC. # Page. 3 ![Page Image](https://bcdn.docswell.com/page/47QYP2QQEP.jpg) Developer Advocate © 2026, Developer Advocate, LLC. # Page. 4 ![Page Image](https://bcdn.docswell.com/page/KE4WYLNYJ1.jpg) Codex ではじめるエージェンティックコーディング --AI エージェントによる⾃律的システム開発ガイド 9/10 発売 https://amzn.asia/d/0g8bJDp0 # Page. 5 ![Page Image](https://bcdn.docswell.com/page/L71Y6L5NJG.jpg) Web システムからの漏えい公表が急増 突かれているのは AI のゼロデイではなく API の個別の不備 (マクニカ 2026-10-07) 119 84 狙われている不備 事案対応とログ分析で判明 ・必要以上の情報を返す API 62 ・匿名で使えてしまう会員機能 ・アプリから抜かれた API キー ・管理画⾯の弱いパスワード 2024 年 2025 年 2026 年 (10/6 時点) 要点 AI で速く作ったコードを「動いた」で⽌めると、不備がそのまま攻撃の⼊⼝になる 出典: マクニカ「相次ぐ WEB システムからの情報漏洩事案について」(2026-10-07) Developer Advocate © 2026, Developer Advocate, LLC. # Page. 6 ![Page Image](https://bcdn.docswell.com/page/G7WGWVWME2.jpg) 突かれているのは API の基本的な不備 他⼈の ID を送ると他⼈の情報が返る - IDOR (BOLA) と呼ばれる不備 レスポンス (B さんの注⽂) GET /orders/1002 { ⼀般会員 A API ⾃分の注⽂は 1001 認証: ある 認可: ない 200 OK "orderId": 1002, "name": "B さん", "address": "東京都…", "phone": "090-…", "card": "****1234" } IDOR (アイドア): Insecure Direct Object Reference URL や API の ID を書き換えるだけで他⼈のデータに届いてしまう不備。認可の確認が抜けると起きる BOLA (ボラ): Broken Object Level Authorization API での IDOR の呼び名。OWASP API Security Top 10 (2023) の 1 位 要点 ログインの確認 (認証) はあるが その注⽂が本⼈のものかの確認 (認可) が抜けている 出典: OWASP Top 10:2025 A01 Broken Access Control Developer Advocate © 2026, Developer Advocate, LLC. # Page. 7 ![Page Image](https://bcdn.docswell.com/page/4JZL545ME3.jpg) AI のコードは「動いた」で⽌まりやすい ⾃分の ID で確かめると 200 が返るので不備に気付かない 「動いた」の確認 「仕様どおり」の確認 作った⼈が⾃分で試す 仕様の受け⼊れ条件で試す ・⾃分の注⽂ 1001 → 200 OK ・画⾯に注⽂が表⽰される → ここで完了にしてしまう ・他⼈の注⽂ 1002 → 403 のはず → 実際は 200 が返る ・返す項⽬は仕様どおりか → 住所と電話も返している 45% AI ⽣成コードのうち セキュリティ テストに 不合格だった割合 (Veracode) 100% テストした全アプリに アクセス制御の不備が あった (OWASP) 出典: Veracode 2025 GenAI Code Security Report・OWASP Top 10:2025 A01 Developer Advocate © 2026, Developer Advocate, LLC. # Page. 8 ![Page Image](https://bcdn.docswell.com/page/YE6W9395EV.jpg) Developer Advocate © 2026, Developer Advocate, LLC. # Page. 9 ![Page Image](https://bcdn.docswell.com/page/GE5MNLNGE4.jpg) SDD とは - 何を作るかを先に書いてから AI に作らせる 仕様 = 作るものを⼈と AI が同じ意味で読める形に書いたもの 要件 ⼈が決める プロンプトだけ SDD spec.md 何を作るか plan.md どう作るか tasks.md 作業の単位 実装 + テスト AI が作る 指⽰ → コード → 動いたら完了 合否の基準がない 仕様 → コード → 仕様どおりかをテストで判定 合否の基準が仕様にある 要点 合否の基準を先に書くので AI が作ったものを検品できる Developer Advocate © 2026, Developer Advocate, LLC. # Page. 10 ![Page Image](https://bcdn.docswell.com/page/97295L5DJR.jpg) Spec Kit - SDD を補助するツールキット GitHub が公開している無料のオープンソースツール Spec Kit とは よくある誤解 ・GitHub 公式の無料 OSS （github.com/github/spec-kit） ・SDD のワークフローを補助するテンプレート集 ・× 新しい AI モデルではない （Copilot / Claude のまま） ・× 既存ツールから乗り換えるものではない ・コマンド︓必須 7 + 任意 3 = 10（詳細は後述） ・Copilot / Claude Code / Gemini CLI 等で動作 ・× 全部⾃動化するものではない（⼈間レビュー必須） ・× 専⽤ IDE が必要なわけでもない ・リポジトリ初期化コマンド 1 ⾏で導⼊可能 ・○ 既存ツールの上に「思想層」を導⼊する仕組み Spec Kit → SDD という思想を既存ツールに乗せるためのキット 10 Developer Advocate © 2026, Developer Advocate, LLC. # Page. 11 ![Page Image](https://bcdn.docswell.com/page/DJY4KQKM7M.jpg) Spec Kit のコマンド⼀式 - 必須 7 + 任意 3 すべて /speckit- プレフィックス (例: /speckit-specify) - taskstoissues は 2025/11、converge は 2026/06追加 ① ② ③ ④ ⑤ ⑥ ⑦ constitution specify plan tasks tasksto issues impleme nt converge 原則・制約 仕様（What） 設計（How） 実装単位に分解 Issue 化 実装 残タスクを追加 任意 3 コマンド - 必要に応じて⾜す（品質と精度を上げる） ・clarify - spec の曖昧な箇所を対話で詰める（plan の前に推奨。旧 /quizme） ・analyze - spec / plan / tasks の整合と網羅をチェック（tasks の後、implement の前） ・checklist - 要件の完全性・明確さ・⼀貫性を検証する品質チェックリストを⽣成 converge は既存コードを spec / plan / tasks と突き合わせ、未実装分を tasks.md に追加する（brownfield 向け） 11 Developer Advocate © 2026, Developer Advocate, LLC. # Page. 12 ![Page Image](https://bcdn.docswell.com/page/V7NYRKR3E8.jpg) Agentic Commerce アプリ - GearMate 初⼼者向けに楽器の検索から相談と購⼊までを⾏う 商品を探す （セマンティック検索) ⽇本語 / 英語で相談する （エージェント推薦) この画⾯が仕様であり、検品の突合先 カートで購⼊ Developer Advocate © 2026, Developer Advocate, LLC. # Page. 13 ![Page Image](https://bcdn.docswell.com/page/YJ9PMVMP73.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 Developer Advocate © 2026, Developer Advocate, LLC. # Page. 14 ![Page Image](https://bcdn.docswell.com/page/GJ8DLPLXJD.jpg) 相談チャットの中⾝ - AI が組み⽴てる Claude が理解と説明／実データは検索で取る（でっち上げない） 相談 ⽇本語の質問 Claude 理解 → 条件 OpenAI 埋め込み Azure SQL vector 検索 • 最近は Jev、OpenAI の Decisions API、MicrosoftDecision-1 のように、選択肢から判断だけを返すモデル が続けて出ている • 今の GearMate は相談の画⾯で、Claude が理解と 説明を両⽅⾏い、判断専⽤のモデルは使っていない • もしトップをチャットにしたら(v2)、相談の意図の振り分け や、エージェントがカートを操作してよいかの判定に使える Claude 推薦理由 候補 商品 + 理由 モデル: Claude Sonnet 5（理解・推薦理由）/ OpenAI text-embedding-3-small（埋め込み） • 今の GearMate では、エージェントに⽂章で指⽰を送れるのは相談の画⾯だけ。プロンプト インジェクションを受ける場所は、ここに限られる • カートと購⼊はユーザーが⾃分で操作するので、守る場所は API の認可であり、先ほどの「他⼈の注⽂番号で 403 を返す」がそれに当たる • v2 ではトップをチャットにするので、最初の画⾯からエージェントに指⽰を送れるようになり、エージェントがカートを操作するときの認可も確かめる必要が出てくる Developer Advocate © 2026, Developer Advocate, LLC. # Page. 15 ![Page Image](https://bcdn.docswell.com/page/LJLML1LNER.jpg) Developer Advocate © 2026, Developer Advocate, LLC. # Page. 16 ![Page Image](https://bcdn.docswell.com/page/47MYMWMQ7W.jpg) constitution.md と spec.md に認可を書く 書いていない認可はエージェントも守らない constitution.md (原則) spec.md (US3 注⽂履歴を⾒る) ## セキュリティ原則 - すべての API は認証を必須とする - 返す前に所有者を確認する - 他⼈のリソースには 403 を返す - spec にない項⽬は返さない - 会員は⾃分の注⽂だけを⾒られる 受け⼊れ条件 - 他⼈の注⽂ ID → 403 - 未ログイン → 401 - 返す項⽬: 注⽂ ID・商品・⾦額・⽇付 要点 誰が何を⾒てよいかを仕様に書き 受け⼊れ条件はテストで判定できる形にする Developer Advocate © 2026, Developer Advocate, LLC. # Page. 17 ![Page Image](https://bcdn.docswell.com/page/P7R9VYVKE9.jpg) 合否はテストで決める - 403 を返すかを確かめる 受け⼊れ条件をそのままテストにして AI に先に書かせる OrdersApiTests.cs (xUnit) [Fact] public async Task OtherUsersOrder_Returns403() { var client = CreateClientAs("user-A"); var url = "/orders/1002"; // B の注⽂ var res = await client.GetAsync(url); Assert.Equal(HttpStatusCode.Forbidden, res.StatusCode); } 1 受け⼊れ条件をテストにする spec.md の「他⼈の注⽂ → 403」 2 実装前に実⾏すると失敗する テストが仕様を表している証拠 3 実装後にテストが通れば合格 AI の⾃⼰申告では合格にしない 要点 「動いた」ではなく「仕様どおり」を合格の条件にする Developer Advocate © 2026, Developer Advocate, LLC. # Page. 18 ![Page Image](https://bcdn.docswell.com/page/PJXQZGZ57X.jpg) Task → Build → Inspect（テスト）→ Fix の 1 周の実演 作る側とテストする側を分ける = maker-checker Task SDD, task.md → Build エージェントが ⽣成・描画 → Inspect テストで合否 画像は vision で⾒る → Fix ズレを直して 再実⾏ 不合格なら戻る - 合格するまで繰り返すのが checker 💡 成功条件は「動いた」ではなく「仕様どおり」。checker を分けるのが設計の勘所 Developer Advocate © 2026, Developer Advocate, LLC. # Page. 19 ![Page Image](https://bcdn.docswell.com/page/3JK9848RJD.jpg) Claude Code の /security-review 差分を AI が検品︓2025-08-06 から全ユーザーが使える - GitHub Action なら PR ごとに実⾏する ・⼿元のブランチの差分をレビューする ・SQL インジェクション・XSS・ 認証と認可の不備を検査する ・GitHub Action は PR ごとに実⾏して 該当⾏にコメントする ・Action の検査対象には IDOR と 権限昇格が⼊っている > /security-review ・Action は信頼できる PR にだけ使う 要点 ⼿元では /security-review で検品し PR では Action で毎回検品する 出典: Anthropic「Automate security reviews with Claude Code」・anthropics/claude-code-security-review Developer Advocate © 2026, Developer Advocate, LLC. # Page. 20 ![Page Image](https://bcdn.docswell.com/page/LE3W2L2GE5.jpg) Claude Security - 脅威モデルから検証まで AI が⾏う 2026-04-30 から Enterprise 向けパブリック ベータ - Claude Code のプラグインもある ・複数のエージェントが 構成の把握 → 脅威 モデル → 脆弱性の探索 → 独⽴した検証 を順に⾏う ・データの流れをファイルをまたいで追う ・検出ごとにパッチを提案し 別のエージェント がテスト付きでレビューする ・⾃動では適⽤しない (git apply は⼈が実⾏) > /plugin install claude-security @claude-plugins-official 要点 ⾒つけるだけでなく 本当に突けるかを別のエージェントが確かめる 出典: Claude Security (Claude Code Docs)・Claude Security public beta Developer Advocate © 2026, Developer Advocate, LLC. # Page. 21 ![Page Image](https://bcdn.docswell.com/page/8EDKZNZN7G.jpg) Codex Security - 隔離環境で再現してから直す 脅威モデルを作ってスキャンし 再現できたものだけを Fix with Codex で直す 脅威モデル ⼊⼝と信頼境界 スキャン 差分やリポジトリ 再現 隔離コンテナ内 Fix with Codex パッチを作る draft PR ⼈がレビュー 使い⽅は 3 通り ・ChatGPT デスクトップのプラグイン ・CLI と SDK (@openai/codex-security) ・Cloud で GitHub と連携 (research preview) ・CI で --fail-on-severity high を指定し high 以上なら merge を⽌める 要点 継続スキャンは 2026-10-15 まで無料 - その後はトークン課⾦ 出典: Codex Security (OpenAI Docs)・FAQ・CI Developer Advocate © 2026, Developer Advocate, LLC. # Page. 22 ![Page Image](https://bcdn.docswell.com/page/V7PKD5DNJ8.jpg) checker を別モデルにする - 作ったモデルに検品させない maker は Copilot で checker は Claude - 結果は PR コメントとして GitHub に残る .github/workflows/adversarial-review.yml on: pull_request: types: [opened, synchronize] jobs: review: runs-on: ubuntu-latest permissions: { contents: read, pull-requests: write, id-token: write } steps: - uses: actions/checkout@v6 - uses: anthropics/claude-code-action@v1 # 公式 action（MIT ライセンス） with: anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }} prompt: | REPO: ${{ github.repository }} PR NUMBER: ${{ github.event.pull_request.number }} この差分に課題がある前提で反証しろ。良い点は不要。 深刻度と根拠を付けろ。根拠は実⾏できる形で⽰せ。 gh pr comment で PR に書き戻せ。 claude_args: --allowedTools "Bash(gh pr comment:*),Bash(gh pr diff:*)" 前提 公式の anthropics/claude-code-action@v1 を使う - claude の導⼊は不要 反証の指⽰は、良い点は求めず、深刻度と根拠を出させる。採否は⼈が決める Developer Advocate © 2026, Developer Advocate, LLC. # Page. 23 ![Page Image](https://bcdn.docswell.com/page/2JVV1P1YJQ.jpg) GitHub Copilot cloud agent - 既定で検品が⼊る PR を仕上げる前に CodeQL と依存とシークレットを⾃動で検査する 追う 既定で⼊るもの レビューを⾜す View session cloud agent ⾃⾝に適⽤ Copilot code review ・PR の下書きができる ・Firewall でアクセス制御 ・Copilot をレビュアーに ・session で動きを確認 ・CodeQL で脆弱性を検査 ・instructions で指⽰ ・途中からコメントで指⽰ ・シークレットも検査 ・skills で観点を⾜す ・依存の脆弱性も検査 ・MCP で⼀次情報を参照 ・MCP: GitHub・Playwright ・Skill の使⽤はログで ・別リポジトリは要設定 要点 Copilot code review に加えて 別のモデル (Claude) にも反証させる Developer Advocate © 2026, Developer Advocate, LLC. # Page. 24 ![Page Image](https://bcdn.docswell.com/page/5EGL2P2WJL.jpg) 4 つの検品を⽐べる どれも修正を採るかどうかは⼈が決める Copilot cloud agent /security-review Claude Security Codex Security ⼿元で差分ごと Action で PR ごと 定期スキャン 対象を絞ったスキャン 定期スキャン CI で差分ごと cloud agent の PR ごと 確かめ⽅ AI がレビュー 別のエージェントが 独⽴して検証 隔離コンテナで 再現する CodeQL・依存・ シークレット・レビュー 直し⽅ 指摘を受けて パッチを提案 Claude Code で直す (⾃動適⽤しない) Fix with Codex → draft PR agent が⾃分で 直してから PR 提供 全ユーザー プラグイン・CLI Cloud (preview) 有料の Copilot プラン いつ Enterprise (ベータ) 出典: Claude Code・Codex Security・GitHub Changelog 2025-10-28 Developer Advocate © 2026, Developer Advocate, LLC. # Page. 25 ![Page Image](https://bcdn.docswell.com/page/4JQYP2PQ7P.jpg) Build → Inspect → Fix を繰り返す 作るモデルと検品するモデルを分けて最後は⼈が承認する Build Inspect Fix maker checker ⼈が判断 ・Spec Kit で仕様から ・テストとセキュリティ ・修正案を AI が出す tasks まで作る レビューで検品する ・テストを再実⾏して ・Claude Code・Codex が ・作ったのとは別の 確かめる 実装する モデルに反証させる ・⼈が承認してマージする ・テストも⼀緒に書かせる ・CodeQL・シークレット・ 依存も検査する 要点 ツールは変わっても型は同じ。仕様 → 実装 → 検品を繰り返す Developer Advocate © 2026, Developer Advocate, LLC. # Page. 26 ![Page Image](https://bcdn.docswell.com/page/K74WYLYYE1.jpg) Thank you for your attention! Developer Advocate © 2026, Developer Advocate, LLC. # Page. 27 ![Page Image](https://bcdn.docswell.com/page/LJ1Y6L6NEG.jpg) A Appendix 本編で省いた詳細と⽤語⼀覧 Developer Advocate © 2026, Developer Advocate, LLC. # Page. 28 ![Page Image](https://bcdn.docswell.com/page/GJWGWV4M72.jpg) ⽤語⼀覧 (1) - セキュリティ スライドに出てくる⽤語の意味 認証 利⽤者が誰かを確かめる (ログイン) 認可 その利⽤者がそのデータや操作を許されているかを確かめる IDOR (アイドア): URL や API の ID を書き換えるだけで他⼈のデータに届いてしまう不備 認可の確認が抜けると起きる BOLA (ボラ): API での IDOR の呼び名。OWASP API Security Top 10 (2023) の 1 位 Insecure Direct Object Reference Broken Object Level Authorization 200 / 401 / 403 OWASP Top 10 HTTP の応答コード 200 は成功・401 は未ログイン・403 はログイン済みだが権限がない Web アプリの代表的なリスクを OWASP がまとめた⼀覧 2025 年版の 1 位はアクセス制御の不備 脅威モデル どこから攻撃されうるか (⼊⼝・信頼境界・認証の前提) を整理したもの プロンプト インジェクション ⼊⼒に紛れ込ませた指⽰で AI の動作を乗っ取る攻撃 シークレット スキャン API キーやパスワードがコードに⼊っていないかを検査する CodeQL GitHub のコード解析エンジン。コードを解析して脆弱性を⾒つける Developer Advocate © 2026, Developer Advocate, LLC. # Page. 29 ![Page Image](https://bcdn.docswell.com/page/4EZL542M73.jpg) ⽤語⼀覧 (2) - 開発 スライドに出てくる⽤語の意味 SDD (仕様駆動開発) 仕様を先に書き それを基準に AI に実装させて検品する進め⽅ Spec Kit GitHub が公開している SDD ⽤の OSS コマンドで constitution → specify → plan → tasks → implement と進める constitution.md プロジェクト全体の原則 (技術スタック・セキュリティ⽅針など) を書くファイル 受け⼊れ条件 仕様を満たしたと判定する条件。テストにそのまま書ける形で書く xUnit .NET のテスト フレームワーク 依存の脆弱性検査 新しく⼊れたライブラリに既知の脆弱性がないかを検査する CI push するたびにビルドとテストを⾃動で実⾏する仕組み draft PR レビュー前の下書き状態のプルリクエスト maker / checker 作る役と検品する役。別のモデルに分ける Developer Advocate © 2026, Developer Advocate, LLC. # Page. 30 ![Page Image](https://bcdn.docswell.com/page/Y76W93V57V.jpg) ▶ デモ動画 - バックエンド⽣成 → xUnit が不合格から合格へ → セマンティック検 索（意味の近さで探す検索）が返る Developer Advocate © 2026, Developer Advocate, LLC. # Page. 31 ![Page Image](https://bcdn.docswell.com/page/G75MNLDG74.jpg) 「テスト」の形は分野（ドメイン）で変わる 今回はインフラ・コード・3D・モバイルの 4 つを実演 分野 インフラ コード 3D テストの形 Terraform plan / validate（構⽂・計画） ＋ デプロイ直後のスモークテスト 型・ユニット / 統合テスト バックエンド（.NET API）= xUnit レンダ画像を vision で⾒る モバイル フロント（SwiftUI）= スクショ + vision ゲーム ビルド / 経路探索 / アセット取込 = 機能テスト ⾃動化の度合い ⾼い（構⽂＋疎通） ⾼い（Spec Kit の世界） 中（⾒えるミスに強い） ⾼い（本命） 機能は可（feel は⼈間） 💡 追うべきはツールでなく型 - フロントを替えても同じ型が有効（バックエンドは .NET） Developer Advocate © 2026, Developer Advocate, LLC. # Page. 32 ![Page Image](https://bcdn.docswell.com/page/9J295L8DER.jpg) 作るところから検品まで途切れずにつながる Spec Kit → GitHub Copilot → .NET → Blender MCP → Skill Spec Kit 仕様を構造化 → • • • • GitHub Copilot 仕様との差分を → レビュー .NET/Azure （Container Apps・SQL） バックエンド API Blender MCP Skill 3D 商品画像を 検品を⾃動化 → → ⽣成 デモ 1 = コード（.NET） デモ 2 = インフラ（IaC） デモ 3 = 3D（Blender） デモ 4 = モバイル（SwiftUI） Developer Advocate © 2026, Developer Advocate, LLC.