学習者テストペルソナ
AdCP のドキュメント、ウェブサイト、Addie がさまざまなユーザータイプにどれだけよく役立つかをテストするための 7 つのペルソナ。ペルソナ 1-3 はビルド側（エンジニアリング実装）。ペルソナ 4-6 はバイ側（異なるスケールでの戦略と採用）。ペルソナ 7 は非コーダー向けの認定ビルドプロジェクト体験をテストします。それぞれが現実的なセッションと一連の質問を表します。
キャラクターバイブルとの関係: キャラクターバイブル（specs/character-bible.md を参照）は、ウォークスルーパネルで使われる図解キャラクター（Alex、Sam、Jordan、Maya など）を定義します。ここでのテストペルソナは別の概念です — それらはコンテンツ品質を評価するために実際のユーザージャーニーをシミュレートします。テストペルソナがウォークスルーキャラクターのロールにマップする場合、その接続を記します。
ペルソナ 1: Marcus Chen — レガシー AdCP ビルダー
ロール
エージェンシーのテックチームのシニアエンジニア。約 9 か月前に AdCP 2.5 に対してバイヤーエージェント統合を構築。それは本番で稼働し、少数のブランドのためにメディアバイを配置している。背景
Marcus の統合は、MCP 上で製品ディスカバリー、クリエイティブ同期、メディアバイ作成を処理する。彼はそれを 2.5 スキーマに対して書き、ローンチ以来触れていない。Slack で v3 RC アナウンスを見て、移行する必要があることを知っているが、まだ変更履歴を読んでいない。プロトコルに慣れており、MCP が何か、タスクがどう機能するかを誰かに説明してもらう必要はない。彼が既に知っていること
- コアタスクフロー:
get_products->sync_creatives->create_media_buy->get_media_buy_delivery - パブリッシャーディスカバリーのための
adagents.jsonの仕組み - v2 チャネル enum（
display、video、audio、native、social、ctv、podcast、dooh、retail） - パッケージの文字列配列としてのクリエイティブ ID
- クリエイティブアセットタイプとしての
promoted_offerings - 価格オプションの
fixed_rateとprice_guidance.floor - フラットな文字列配列としての
geo_postal_codesとgeo_metros - パッケージ上の単一オブジェクトとしての
optimization_goal - ケイパビリティディスカバリーのための
adcp-extension.jsonの仕組み
彼が知らないこと
nativeがチャネルとして削除されたこと（彼はchannels: ["native"]を持つパッケージを持っている）videoがolv、linear_tv、cinemaに分割されたことcreative_idsが重み付けを持つcreative_assignmentsになったこと- 新しいアカウントモデル（
sync_accounts、list_accounts、課金モデル） promoted_offeringsがファーストクラスカタログ（sync_catalogs）に置き換えられたことbrand_manifestがbrandref（{ domain, brand_id }）に置き換えられたことadcp-extension.jsonがget_adcp_capabilitiesに置き換えられたこと- geo ターゲティングが今やシステム仕様を要求すること
optimization_goalがoptimization_goals（配列、判別されたユニオン）になったこと- Brand Protocol、Governance、Sponsored Intelligence、または Registry API の存在
誤解と盲点
nativeが依然として有効なチャネルだと想定。検証が失敗すると混乱する。- ケイパビリティディスカバリーが依然として
adcp-extension.jsonを使うと想定。もう存在しないエージェントカード拡張ドキュメントを探す。 account_idが単に彼が渡す文字列だと考える。AccountReferenceオブジェクトや account-id 名前空間対バイヤー宣言アカウントモデルについて知らない。promoted_offeringがメディアバイ上の文字列フィールドのままだと期待する。- 価格フィールドの名前が変わっていないと想定する。
- おそらく「what’s new」ではなく「migration」または「upgrade」を検索する。
主要ゴール
既存の統合に影響するすべての破壊的変更を理解し、更新すべきもののチェックリストを取得し、移行の労力（週ではなく時間）を見積もる。彼が尋ねる主要な質問
- 「AdCP 2.5 と 3.0 の間で何が壊れたか?」
- 「v2 から v3 への移行ガイドはあるか?」
- 「native チャネルの代わりは何か?」
- 「creative_ids を新しいフォーマットにどう更新するか?」
- 「adcp-extension.json はどうなったか?」
- 「accounts プロトコルを実装する必要があるか、スキップできるか?」
- 「移行中に v2 統合を v3 と並行して実行できるか?」
彼が訪れそうなページ
/docs/reference/whats-new-in-v3— 最初の立ち寄り先、変更のサマリーを探す/docs/reference/migration/channels— 彼のnativeとvideoパッケージが壊れている/docs/reference/migration/pricing—fixed_rateとprice_guidance.floorの修正/docs/reference/migration/creatives—creative_idsからcreative_assignmentsへ/docs/reference/migration/catalogs—promoted_offeringsの置き換え/docs/reference/migration/geo-targeting— geo フィールドのシステム仕様/docs/reference/migration/optimization-goals— 単一ゴールから配列へ/docs/reference/migration/brand-identity—brand_manifestからbrandref へ/docs/accounts/overview— 新しいアカウントモデルの理解/docs/protocol/get_adcp_capabilities—adcp-extension.jsonの置き換え
成功基準
- 彼は統合が必要とするすべてのコード変更のラインアイテムリストを作成できる
- どの変更がリネーム（簡単）対 構造的（より難しい）かを理解している
- どの新しいプロトコルドメイン（accounts、governance、brand protocol）が彼のユースケースに必須対オプションかを知っている
- 推測せずにコードを書き始めるのに十分なスキーマ詳細を持っている
- ランディングから「何をすべきか分かった」までの合計時間: 45 分未満
ペルソナ 2: Ravi Mehta — AI アドネットワークビルダー
ロール
AI アドネットワークスタートアップ（Kontext や Koah を思い浮かべる）のエンジニアリングリード。彼の会社は複数の AI プラットフォーム — AI アシスタント、AI 検索エンジン、生成 AI 体験 — にわたって広告在庫を集約し、統一されたインターフェースを通じてエージェンシーとブランドに販売する。背景
Ravi の会社は、会話型と検索の体験で広告をサーブする十数の AI プラットフォームとのパートナーシップを持つ。会社のバリュープロップは集約: エージェンシーは各 AI プラットフォームと個別に統合したくなく、AI プラットフォームは自身の販売チームを構築したくない。彼のアドネットワークは中間に座る — エージェンシーから広告主データ（カタログ、予算、ブランドガイドライン）を受け入れ、それを適切な AI プラットフォームに配布する。 彼は各 AI プラットフォームと各エージェンシーとのカスタム統合を構築してきた。スケールしない。彼は AdCP の実装を検討しているパートナープラットフォームから AdCP について聞いた。彼は AdCP が彼のビジネスの両側の標準インターフェースになりうるか評価している: 需要側で AdCP 経由でデータをプッシュするバイヤーエージェント、供給側でそのデータを AI プラットフォームにプッシュするネットワーク。 彼はアドテックを深く知り（これ以前に中規模 SSP で ad ops を運営）、以前に MCP サーバーを構築した（彼の会社は既に MCP ベースのプロトタイプを持つ）。彼は技術的に流暢で、プロトコル仕様を直接読む。彼が既に知っていること
- アドネットワークがどう供給と需要を集約するか
- ファーストパーティプラットフォーム（ウォールドガーデン）とネットワーク（マルチプラットフォーム）の違い
- MCP の基本 — 彼は MCP サーバーを構築し、ツール露出を理解し、クライアントがどう接続するか知っている
- 従来のプログラマティック: OpenRTB、prebid、SSP/DSP メカニクス
- 彼の会社の痛み: プラットフォームごととエージェンシーごとのカスタム統合がスケールしない
- AI プラットフォームがブランドデータからクリエイティブを生成すること — 彼のネットワークはそのデータをパイプする必要がある
- 複数の広告主とプラットフォーム全体のアカウント管理
- OAuth、API キー管理、マルチテナントアーキテクチャ
彼が知らないこと
- AdCP が彼のユースケースのための特定の
sponsored_intelligenceチャネルを持つこと sync_catalogsが、彼が各プラットフォームのためにカスタムで構築してきたカタログパイプをどう標準化するか- アカウントモデルがネットワーク（バイヤー宣言アカウント、agent-trusted モデル）対ファーストパーティプラットフォーム（account-id 名前空間、ウォールドガーデン）にとってどう機能するか
adagents.jsonの仕組み — バイヤーエージェントが彼のネットワークを発見するために必要で、彼が接続する AI プラットフォームからそれを理解する必要がある- ガバナンスポリシーがネットワークをどう流れるか — ブランドはコンテンツ標準を彼のネットワークにプッシュし、彼のネットワークはそれを各 AI プラットフォームにプッシュするか?
optimization_goalsとsync_event_sourcesがネットワーク境界全体でどう機能するか — 彼のネットワークは複数のプラットフォームから配信データを集約する- AdCP がネットワークトポロジーを処理するか: バイヤーエージェント → アドネットワーク → AI プラットフォーム、それとも直接バイヤー対セラーを想定するか
- AI プラットフォームがセッションをホストするが、ブランドが彼のネットワークを通じて紹介されたとき、Sponsored Intelligence がどう機能するか
誤解と盲点
- AdCP がバイヤー対セラーのみだと想定。 彼のビジネスは中間のネットワーク。プロトコルが中間者を考慮しないこと — 彼がバイヤーかセラーのふりをしなければならないこと — を心配している。
- アカウントが単純だと考える。 彼のネットワークはブランドに代わってアカウントを管理するエージェンシーに代わってアカウントを管理する。彼はこの複雑さに慣れているが、AdCP のアカウントモデルがマルチレベル委任をどう処理するか知らない。
- カタログパイプを自分で構築する必要があると想定。 彼は各 AI プラットフォームとカスタムカタログ同期統合を構築してきた。
sync_catalogsが彼のビジネスの両側で機能しうる標準であることに気づいていない。 - 彼のネットワークの製品を基盤プラットフォームの製品と混同。 彼は「AI アシスタント全体のスポンサー付きレスポンス」を単一製品として販売するが、各基盤 AI プラットフォームは独自の製品 ID、価格、フォーマットを持つ。AdCP で集約製品をどうモデル化するか理解する必要がある。
- ガバナンスがパススルーだと考える。 彼は単にバイヤーからプラットフォームにブランドセーフティルールを転送すると想定。プラットフォームに転送する前にネットワークがルーティングレイヤーで強制できる構造化オブジェクトとしてのガバナンスポリシーについて知らない。
主要ゴール
AdCP がネットワークトポロジー（バイヤー → ネットワーク → プラットフォーム）で機能するか判定。そうなら、彼のビジネスをどうモデル化するか理解する: 彼のネットワークはバイヤーにどう見えるか（セラーエージェントとして）、AI プラットフォームとどう相互作用するか（バイヤーまたはオペレーターとして）、カタログ、アカウント、ガバナンスがネットワークレイヤーをどう流れるか。彼が尋ねる主要な質問
- 「AdCP は中間のネットワークをサポートするか、それとも厳密にバイヤー対セラーか?」
- 「複数の AI プラットフォーム全体で集約するとき、アドネットワークの製品をどうモデル化するか?」
- 「ネットワークにとってアカウントはどう機能するか? エージェンシーは私とアカウントを持ち、私は各 AI プラットフォームとアカウントを持つ。」
- 「両側で
sync_catalogsを使えるか — エージェンシーからカタログを受け入れ、AI プラットフォームに転送する?」 - 「ガバナンスポリシーとコンテンツ標準がネットワークをどう流れるか?」
- 「複数のプラットフォーム全体で集約しているとき、配信レポートはどう機能するか?」
- 「私の
adagents.jsonはどう見えるか? 私は自分のものでない複数のパブリッシャープロパティを代表する。」 - 「私が中間者のとき SI はどう機能するか — ブランドは私のネットワークを通じて紹介されたが、セッションは AI プラットフォームで実行される?」
- 「アカウントモデルは何か — 私は agent-trusted なので
require_operator_auth: false?」 - 「AdCP を使う他のネットワークはあるか、それとも私が最初か?」
彼が訪れそうなページ
/docs/sponsored-intelligence/overview— コアページ、ネットワーク固有のガイダンスを探す/docs/building/implementation/seller-integration— バイヤーエージェントにセラーとしてどう見えるか/docs/accounts/overview— ネットワークアカウントモデル（agent-trusted、バイヤー宣言アカウント）/docs/building/integration/accounts-and-agents— マルチレベルアカウント委任/docs/creative/catalogs— パススルーのためのカタログ同期メカニクス/docs/governance/overview— ガバナンスが中間者をどう流れるか/docs/media-buy/product-discovery/media-products— 集約製品のモデル化/docs/media-buy/advanced-topics/accounts-and-security— ネットワークのためのadagents.json/docs/protocol/get_adcp_capabilities— ネットワークが宣言するケイパビリティ/docs/sponsored-intelligence/overview— ネットワーク中間者を通じた SI/docs/building/integration/mcp-guide— MCP サーバーパターン（彼は詳しいが AdCP 固有のガイダンスが欲しい）/docs/reference/media-channel-taxonomy—sponsored_intelligenceチャネル定義
成功基準
- 彼はネットワークがバイヤーにどう見えるか（バイヤー宣言アカウントを持つセラーエージェント）、AI プラットフォームとどう相互作用するか（各プラットフォームで account-id 名前空間を持つオペレーター）を理解している
- 彼は集約製品 — 異なる価格の複数の基盤 AI プラットフォームにまたがる製品 — をモデル化できる
- カタログがどう流れるか知っている: バイヤー → ネットワーク → AI プラットフォーム、両レグで
sync_catalogsを使う - ガバナンスフローを理解している — ブランドからのコンテンツ標準はネットワークレイヤーで強制されプラットフォームに転送されうる
- アカウントチェーンを説明できる: ブランド → エージェンシー → ネットワーク → AI プラットフォーム、AdCP が各関係をどうモデル化するか
- 彼のビジネスの両側で AdCP 統合をアーキテクトするのに十分なものを持っている
- ランディングから「アーキテクチャドキュメントを書ける」までの合計時間: 90 分未満
ペルソナ 3: Tomoko Hayashi — AI プラットフォーム広告インフラリード
ロール
主要な AI アシスタントプラットフォームの広告チームのシニアプロダクトマネージャー。ChatGPT スケールを思い浮かべる: 数億のユーザー、強い商業意図シグナル、リーダーシップが広告支援ティアの構築を決定した。彼女は需要側アーキテクチャ — 広告主データと予算がどうプラットフォームに流れるか — に責任を持つ。背景
Tomoko のチームは既にサービングインフラを構築した — プラットフォームはスポンサー付きレスポンスをレンダーし、コンテキスト推奨を注入し、ブランド体験セッションを処理できる。LLM は正しい入力を持つとき、関連性のあるオンブランドコンテンツを生成するのが得意。今の難問は配管: 数百の広告主がどう製品カタログ、コンバージョンイベント、ブランドガイドライン、コンテンツ標準をスケールでプラットフォームに入れるか? そしてエージェンシーとその AI エージェントがどうプラットフォームの広告製品を発見しプログラマティックにバイを実行するか? 彼女は 2 つのアプローチを評価した: (1) プロプライエタリ API を構築し各バイヤーに 1 つずつ統合させる、または (2) オープン標準を採用し、任意の準拠バイヤーエージェントがプラグインできるようにする。彼女はオプション 2 のために AdCP を見ている。彼女はまた従来の SSP（prebid、GAM）に売り込まれ、懐疑的 — 入札リクエストモデルは会話コンテキストを持たないリモートの意思決定者に薄いシグナルを送り出す。彼女のプラットフォームはコンテキストを持つ。彼女はデータが彼女のところに来ることを望む。彼女が既に知っていること
- 彼女のプラットフォームの LLM ケイパビリティ — 正しいブランドデータとコンテキストが与えられたときに何を生成できるか
- 広告サービングが彼女のプラットフォーム内部でどう機能するか（スポンサー付きレスポンスランキング、コンテキストマッチング、セッション管理）
- スケール問題: プロプライエタリ API を通じて広告主を 1 つずつオンボードすることがスケールしない
- 従来のプログラマティック（入札リクエスト外、広告返却）が、リモート入札者が会話コンテキストを持たないため相性が悪いこと
- 基本的なアドテック: CPM、CPC、エンゲージメントあたりコスト、フィルレート、フリークエンシーキャッピング
- 彼女のプラットフォームが良い広告を生成するために広告主製品データを必要とすること — 初期テストのため手動でスクレイピングしてきた
- OAuth、API 設計、webhook パターン — 彼女はプロトコル仕様を評価するのに十分技術的
彼女が知らないこと
- AdCP が彼女のプラットフォームのユースケース向けに設計された特定の
sponsored_intelligenceチャネルを持つこと sync_catalogsが広告主製品データをスケールで入れる標準パイプとしてどう機能するかsync_event_sourcesが広告主にコンバージョンシグナルをプッシュさせ、プラットフォームが実際の結果で最適化できるようにする方法- ガバナンスポリシーがブランドにコンテンツ標準をプッシュさせる方法 — プラットフォームが生成時に強制する適合性ルール
brand.jsonが生成クリエイティブ品質を改善するブランドアイデンティティ（ボイス、ビジュアルガイドライン、ポジショニング）を提供する方法- メディアバイ上の
optimization_goalsがプラットフォームに各キャンペーンの成功がどう見えるか伝えること - MCP が何か、REST API の構築とどう異なるか（彼女は REST を構築すると想定してきた）
- バイヤーエージェントが彼女のプラットフォームを発見するための
adagents.jsonの仕組み - アカウントがどう機能するか — 広告主ごとに OAuth を要求すべきか、バイヤーエージェントにブランドを宣言させるか
- Sponsored Intelligence が単なる「派手なスポンサー付きレスポンス」ではなく、マルチターンのブランド体験のための別のプロトコルであること
誤解と盲点
- 選択がプロプライエタリ API 対 SSP だと考える。 AdCP がまさに彼女のユースケース向けに設計されたオープン標準 — 入札リクエストを送り出すのではなくデータを受け取る — という第 3 の選択肢であることをまだ見ていない。
- REST API を構築する必要があると想定。 MCP が AI エージェントが既にネイティブに話すトランスポートとして存在することを知らない。彼女のプラットフォームのバイヤーエージェントは LLM — 既に MCP ツールを呼ぶ方法を知っている。
- カタログ問題を過小評価。 彼女のチームは初期広告主から製品フィードを手動でオンボードしてきた。これがスケールしないことは知っているが、
sync_catalogsがそれを標準として解決することに気づいていない。 - ブランドセーフティをブロックリストと考える。 ブランドに適合性ルールをプラットフォームにプッシュさせるガバナンスポリシー — LLM がクリエイティブ生成中に強制するルール、事後フィルタリングとしてでなく — について知らない。
- スポンサー付きレスポンスを SI と混同。 ブランド体験ハンドオフが単によりリッチなスポンサー付きレスポンスだと考える。SI がブランド自身のエージェントが会話を引き継ぐ別のセッションライフサイクルであることを理解していない。
- コンバージョン追跡が自身のピクセル / SDK を要求すると想定。
sync_event_sourcesが広告主に既存のコンバージョンデータをプッシュさせ、プラットフォームが自身の測定スタックを構築せずに最適化できるようにすることを知らない。 - 他の側からの「なぜプログラマティックをやらないのか?」という質問について考えていない。 彼女はなぜ AdCP が SSP との統合より彼女のプラットフォームにとって良いかリーダーシップに明確に述べる必要がある — 答えは、プログラマティックが薄いシグナルを送り出すのに対し AdCP がリッチなデータを持ち込み、彼女の LLM がそのデータを使って任意のリモート入札者よりも良い広告決定を下せること。
主要ゴール
AdCP を彼女のプラットフォームの需要側配管の標準インターフェースとして採用するか決定する。そうなら、何を構築する必要があるか（MCP サーバー、アカウントモデル、カタログ取り込み、製品スキーマ）と、それが代替（プロプライエタリ REST API または SSP 統合）とどう比較されるか理解する。彼女のエンジニアリングチームが実行できる技術設計ドキュメントを書く。彼女が尋ねる主要な質問
- 「AdCP はどう広告主製品データを私のプラットフォームに入れるか? カタログ同期の標準はあるか?」
- 「広告主はコンバージョンイベントをプッシュして、プロキシメトリックの代わりに実際の結果で最適化できるか?」
- 「ブランドセーフティとコンテンツ標準はどう機能するか? ブランドは私の LLM がクリエイティブ生成中に強制する適合性ルールをプッシュできるか?」
- 「なぜ自分の API を構築する代わりにオープン標準を採用するのか? 何が得られるか?」
- 「MCP とは何か、なぜ REST API の代わりに MCP サーバーを構築するのか?」
- 「バイヤーエージェントはどう私のプラットフォームとその広告製品を発見するか?」
- 「アカウントモデルは何か? 広告主ごとに OAuth が必要か、もっと単純なパスがあるか?」
- 「スポンサー付きレスポンスと Sponsored Intelligence の違いは何か?」
- 「なぜこれが従来の SSP との統合より良いか? リーダーシップにどう説明するか?」
- 「他に誰がこれをやっているか? リファレンス実装はあるか?」
彼女が訪れそうなページ
/docs/intro— 出発点、AI 固有のフレーミングを探す/docs/sponsored-intelligence/overview— 彼女のユースケースのコアページ — 逆転したデータフロー論、カタログ同期、ガバナンス、製品モデル化を見つけることを期待/docs/creative/catalogs— カタログ同期の深掘り — これが彼女の最大の運用上の痛点/docs/building/implementation/seller-integration— セラーエージェントとして構築する必要があるもの/docs/governance/overview— コンテンツ標準がプラットフォームがクエリ / 受信する「オラクル」としてどう機能するか/docs/media-buy/media-buys/optimization-reporting— 最適化ゴールとコンバージョンイベントがどう機能するか/docs/accounts/overview— アカウントモデルの理解（ウォールドガーデン対 agent-trusted）/docs/building/integration/mcp-guide— なぜ REST の代わりに MCP か、MCP サーバーはどう見えるか/docs/sponsored-intelligence/overview— SI セッションライフサイクル対スポンサー付きレスポンスの理解/docs/media-buy/product-discovery/media-products— 在庫を製品としてどうモデル化するか/docs/protocol/get_adcp_capabilities— 宣言するケイパビリティ/docs/building/understanding/adcp-vs-openrtb— リーダーシップとの「なぜ SSP でないのか?」会話のための弾薬
成功基準
- 彼女はなぜ AdCP が SSP 統合より彼女のプラットフォームにとって良いかリーダーシップに明確に述べられる — 逆転したデータフロー論: 「私たちは会話コンテキストを持つ。AdCP はブランドデータ、コンバージョンシグナル、適合性ルールを持ち込み、私たちの LLM がローカルで素晴らしい広告決定を下せる。SSP は私たちのコンテキストを持たないリモートシステムに薄い入札リクエストを送らせるだろう。」
- 彼女はデータパイプを理解している: 製品データのための
sync_catalogs、コンバージョンシグナルのためのsync_event_sources、コンテンツ標準のためのガバナンスポリシー、ブランドアイデンティティのためのbrand.json、成功定義のためのoptimization_goals - 実装するアカウントモデルとその理由を記述できる（ファーストパーティプラットフォームなので OAuth を持つウォールドガーデン）
- スポンサー付きレスポンス（製品レベル、カタログ駆動）と SI（セッションレベル、ブランドエージェントハンドオフ）の実装の違いを知っている
- チームが構築する MCP サーバーを仕様化できる: どのタスクを実装するか、どのケイパビリティを宣言するか、カタログ取り込みが既存インフラにどうマップするか
- 明確な比較を持つ: AdCP（オープン標準、データが流れ込む、任意のバイヤーエージェントがプラグイン）対 プロプライエタリ API（バイヤーごとにカスタム、同じデータフローだがエコシステムなし）対 SSP（間違った方向 — シグナルを送り出す）
- ランディングから「技術設計ドキュメントを書ける」までの合計時間: 90 分未満
ペルソナ 4: Daniela Reyes — エージェンシートレーディングデスク幹部
ロール
中規模独立エージェンシーのプログラマティック VP。彼女のチームは 30 以上のブランドにわたって年間 2 億ドル以上のデジタル支出を管理。CEO に報告し、エージェンシーの AI トランスフォーメーション委員会に属する。背景
Daniela はトレーディングデスクを通じて昇進した — この独立ショップに加わる前にホールディングカンパニーでプログラマティック運用を運営。彼女は DSP、SSP、OpenRTB、prebid を隅々まで知っている。彼女のチームは 15 人のトレーダーと、カスタム入札アルゴリズムとレポートダッシュボードを保守する 3 人のエンジニア。 彼女はクライアントから、そして業界カンファレンスで「AI メディア」について聞いてきた。彼女の最大のクライアント 2 社（CPG ブランドと金融サービス会社）が、チームに「ChatGPT と Perplexity で広告を買う方法を見つける」よう頼んだ。彼女はそれらのプラットフォームと直接取引をセットアップしようとしたが、それぞれが異なる API、異なるクリエイティブ仕様、異なるレポートフォーマットを要求する。彼女はチームが従来のプログラマティック全体で買うのと同じ方法で AI サーフェス全体で買う標準的な方法を探している。 彼女はエンジニアではない — コードを書かない。しかし技術を評価し、buy/build 決定を下し、実装すべきことをエンジニアリングチームにブリーフする。概念レベルでドキュメントを読み、形状のためにスキーマをざっと見て、ワークフロー、経済性、競争優位に焦点を当てる。彼女が既に知っていること
- プログラマティック広告を深く: DSP、SSP、アドエクスチェンジ、OpenRTB 入札 / レスポンスフロー
- キャンペーン管理: フライト、予算、ペーシング、最適化、フリークエンシーキャッピング
- クリエイティブトラフィッキング: タグ管理、VAST/VPAID、DCO
- 測定: ビューアビリティ、ブランドセーフティベンダー（IAS、DV）、アトリビューション、MMM
- エージェンシー経済性: マージン、マネージドサービス対セルフサーブ、プラットフォームフィー
- AI プラットフォームが新しいメディアチャネルで、クライアントがそれを求めていること
- 現在のアプローチ（プラットフォームごとの直接取引）がスケールしないこと
彼女が知らないこと
- AI メディア購入の標準として AdCP が存在すること
- 「逆転したデータフロー」が何を意味し、なぜ彼女のエージェンシーにとって重要か
- チームが単一のバイヤーエージェントを使って複数の AI プラットフォーム全体で買えること
- カタログがクリエイティブタグをどう置き換えるか — アセットをトラフィックする代わりに、製品データをプッシュする
- AI プラットフォームが彼女のブランドのデータからクリエイティブを生成すること
- アカウントがプラットフォーム全体でどう機能するか — どこでも別々のログインが必要か?
- AI メディアでガバナンスがどう見えるか — IAS と DV は関連するか、それとも違うか?
- 最適化ゴールが彼女が慣れている DSP 最適化アルゴリズムをどう置き換えるか
- MCP が何か、なぜ重要か（彼女は API とダッシュボードの観点で考える）
- Sponsored Intelligence がより深いブランドエンゲージメントフォーマットとして存在すること
- 価格設定がどう機能するか — RTB のようにオークションベースか、固定か、それとも他の何か?
誤解と盲点
- すべてをプログラマティックにマップ。 彼女は DSP と SSP のレンズを通じて AdCP を理解しようとする。「じゃあバイヤーエージェントは DSP みたいなもの?」「adagents.json は ads.txt みたいなもの?」これらのアナロジーの一部は助け、一部は誤解を招く。
- UI を期待。 彼女は DSP ダッシュボードに慣れている。バイヤーエージェントがキャンペーン管理 UI なしにすべてをプログラマティックに行うという考えは馴染みがない。ダッシュボードがどこにあるか知りたがる。
- クリエイティブが自分の仕事だと考える。 従来のプログラマティックでは、エージェンシーがクリエイティブを構築しトラフィックする。AI メディアでは、プラットフォームがブランドデータからクリエイティブを生成する。これは大きなメンタルシフト。
- ブランドセーフティが同じベンダーを意味すると想定。 彼女は IAS/DV 統合を探す。ガバナンスがサードパーティ検証としてボルト留めされるのではなくプロトコルに組み込まれている（生成時に強制されるコンテンツ標準）という考えは新しい。
- カタログワークフローを過小評価。 彼女は製品フィードをリテールメディアのものと考える。すべての AI メディア購入がカタログとブランドデータをプラットフォームにプッシュすることから始まることに気づいていない。
- AI メディアを「単なる別のチャネル」と考える。 既存のプログラマティックスタックに新しいラインアイテムとして追加したがる。パラダイムシフト — 入札リクエストを送り出すのではなくデータが流れ込む — は、単にチャネルを追加するのではなくワークフローの再考を要求する。
主要ゴール
AdCP が彼女のエージェンシーが AI メディア購入のために採用する正しい標準か理解する。CEO のためのビジネスケースとエンジニアリングチームのための技術ブリーフを構築する。競争優位を見極める: 他のエージェンシーより先にこれを採用したら、勝つか?彼女が尋ねる主要な質問
- 「AI プラットフォームで広告を買うことは DSP で買うこととどう違うか?」
- 「ChatGPT、Perplexity、他の AI プラットフォーム全体で買う標準的な方法はあるか?」
- 「キャンペーンワークフローはどう見えるか? 私のチームはどこに収まるか?」
- 「まだクリエイティブを構築する必要があるか、それともプラットフォームが処理するか?」
- 「ブランドセーフティはどう機能するか? IAS/DV を使えるか?」
- 「価格モデルは何か? オークションベースか?」
- 「これをどうレポートするか? 既存のダッシュボードに入れられるか?」
- 「エンジニアリングチームに何を構築させる必要があるか?」
- 「複数のプラットフォーム全体でアカウントと課金はどう機能するか?」
- 「他に誰かがこれをやっているか? 競争ランドスケープは何か?」
彼女が訪れそうなページ
/— ホームページ、「これは何で、なぜ気にすべきか」を探す/docs/intro— オリエンテーション、明確なバリュープロップを望む/docs/building/understanding/adcp-vs-openrtb— 彼女の「これはどう違うか」の質問に直接答える/docs/sponsored-intelligence/overview— 彼女のユースケースのコアガイド（彼女はバイヤー）/docs/sponsored-intelligence/workflow— コードを書かなくても、ワークフローがどう見えるか見たい/docs/building/implementation/seller-integration— 他の側を理解するためにこれを読むかもしれない/docs/governance/overview— この世界でブランドセーフティがどう機能するか/docs/creative/catalogs— カタログワークフローの理解/docs/accounts/overview— マルチプラットフォーム課金がどう機能するか/docs/reference/media-channel-taxonomy— チャネルリストでsponsored_intelligenceを探す
成功基準
- 彼女は CEO に、なぜ AI メディアが新しい DSP を追加することと違うか、なぜ標準の採用が重要か説明できる
- エンジニアリングチームに何を構築するかブリーフできる: 「AdCP を話すバイヤーエージェントが必要。ワークフローはこう: カタログをプッシュ、製品を発見、メディアバイを作成、配信レポートを引き出す。」
- クリエイティブパラダイムシフトを理解している: エージェンシーがブランドデータとカタログを提供し、プラットフォームがクリエイティブを生成
- ガバナンスモデルを知っている: コンテンツ標準はプロトコルレベル、生成時強制で、サードパーティのボルト留めではない
- 3 人のエンジニアリングチームのためのエンジニアリング投資とタイムラインを見積もれる
- 競争優位を見る: 動作するバイヤーエージェントを持つ最初のエージェンシーは、直接取引をするエージェンシーより速く AI メディアのクライアント需要に応えられる
- ランディングから「これを CEO にプレゼンできる」までの合計時間: 60 分未満
ペルソナ 5: James Okafor — ブランドメディアトランスフォーメーションリーダー
ロール
Fortune 500 の消費者エレクトロニクスブランドのグローバルメディア責任者。CMO に報告。3 つのエージェンシーパートナーと成長するインハウスチームにわたって年間 5 億ドルのメディア予算を管理。ブランドの「未来のメディア」イニシアチブの議長を務める。背景
James は 15 年間ブランド側メディアに携わり、メディアプランナーから機能全体を運営するまで移動。彼はすべての主要なシフトをナビゲートした: プログラマティック、ソーシャル、リテールメディア、CTV。彼はエージェンシー関係をよく知る — エージェンシーに戦略と KPI をブリーフし、彼らがキャンペーンを実行しレポートする。彼のインハウスチームはリテールメディア（Amazon、Walmart）を直接処理し、より多くのプログラマティックをインハウスに持ち込むことを実験している。 彼の CMO は AI メディアを次の優先事項としてフラグした。消費者はますます AI アシスタントを使って製品を調査・購入している。彼のブランドの製品が AI 生成レスポンスに現れている — 時に正確に、時にそうでなく。彼は「AI が正しく言及することを願う」から「AI 体験で正確なブランドメッセージングで積極的に消費者に到達する」に移りたい。 彼は技術的でない。メディア戦略、ブランドエクイティ、消費者ジャーニー、ROAS の観点で考える。ビジネス成果、エージェンシー関係、組織の準備状況のレンズを通じて技術を評価する。彼が既に知っていること
- スケールでのメディア戦略と計画: リーチ、フリークエンシー、GRP、クロスチャネル配分
- エージェンシー管理: ブリーフィング、交渉、パフォーマンス評価、フィー構造
- リテールメディア: Amazon Ads、Walmart Connect、Instacart Ads の学習曲線を経験
- ビジネスリスクとしてのブランドセーフティ: ブランドセーフティインシデントを経験し、コストを知る
- 彼のカテゴリーで消費者が購入を調査するために AI アシスタントを使っていること
- 競合が AI 広告を実験し始めていること
- インハウス対エージェンシーのダイナミクス: 一部のケイパビリティは所有した方が良く、他は外注した方が良い
彼が知らないこと
- AdCP が何か、AI 広告の標準が存在すること
- AI 広告が実際にどう機能するか — デモは見たが、メカニクスを理解していない
- クリエイティブが AI プラットフォームによって彼のブランドのデータ（カタログ、ブランドガイドライン）から生成されること
- 彼のブランドのコンテンツ標準を AI プラットフォームにプッシュして、ブランドがどう現れるか制御できること
- 「カタログ品質が広告品質を駆動する」こと — 彼の製品データがクリエイティブ入力
- AI メディアでガバナンスがどう異なって機能するか（生成時強制対事後検証）
- Sponsored Intelligence が彼のブランドに消費者とマルチターンの会話をさせること
- AI プラットフォームで価格設定がどう機能するか — プログラマティックオークションと同じではない
- AI メディアキャンペーンを実行するためにエージェンシーが彼から何を必要とするか（カタログ、brand.json、コンテンツ標準）
- AI メディアの組織モデルが、従来のプログラマティック（クリエイティブ + ターゲティング）よりリテールメディア（データ + コンテンツ）に近く見えること
誤解と盲点
- AI 広告が AI アプリのバナー広告だと考える。 ChatGPT のレスポンスの隣のディスプレイ広告を想像する。AI がブランドデータから広告を生成すること — 「広告」が AI 体験にネイティブに見え感じるスポンサー付きレスポンスであること — に気づいていない。
- エージェンシーが既にこれをやる方法を知っていると想定。 そうでない。AI メディアは十分新しく、エージェンシーもそれを見極めている。彼は彼らの提案を評価し正しい方向に押すのに十分理解する必要がある。
- ブランドセーフティが同じことを意味すると考える。 従来のメディアでは、ブランドセーフティ = 悪いコンテンツ隣接を避けること。AI メディアでは、ブランドセーフティ = AI がブランドについてどう話すか制御すること。異なる問題、異なる解決策。
- データ要件を過小評価。 彼のチームはリテールメディアのための製品フィードとクリエイティブアセットのための DAM を管理する。AI メディアがさらにリッチなブランドデータ — 製品カタログ、ブランドボイスガイドライン、コンテンツ標準 — を要求し、このデータの品質が直接広告品質を決定することに気づいていない。
- エージェンシー問題だと想定。 彼はエージェンシーをブリーフして見極めさせたがる。しかし AI メディアはエージェンシーが生成できないブランド側入力（カタログ、ブランドアイデンティティ、コンテンツ標準）を要求する。彼はデータパイプラインを所有する必要がある。
- Sponsored Intelligence が派手なリターゲティングだと考える。 SI が新しいエンゲージメントモデルであることを理解する必要がある — 消費者が AI アシスタント内で彼のブランドと会話する。
主要ゴール
AI 広告が何か、彼のブランドが投資すべきか、どんな組織変更が必要か理解する。CMO のためのビジネスケースを構築する。エージェンシーに何を変えるかブリーフする。インハウスチームが何を所有し何を委任すべきか識別する。彼が尋ねる主要な質問
- 「AI 広告とは何か、今日私たちがやっていることとどう違うか?」
- 「消費者は AI アシスタントで広告をどう体験するか?」
- 「AI がブランドについてどう話すか制御できるか?」
- 「私のチームはどんなデータを提供する必要があるか?」
- 「AI がクリエイティブを生成するとき、ブランドセーフティはどう機能するか?」
- 「エージェンシーに何をするよう頼むべきか?」
- 「これをどう測定するか? ROAS を得られるか?」
- 「プログラマティックと比べて価格設定はどう見えるか?」
- 「大きな投資なしにこれをテストする方法はあるか?」
- 「競合は何をしているか?」
彼が訪れそうなページ
/— ホームページ、全体像を探す/docs/intro— 「私が CMO だと思って説明して」/docs/sponsored-intelligence/overview— コアガイドだが、技術的すぎると離脱するかもしれない/docs/building/understanding/adcp-vs-openrtb— 彼が知っているものとの比較が欲しい/docs/creative/catalogs— チームが提供する必要があるデータの理解/docs/governance/overview— ブランドセーフティとコンテンツ標準（彼にとって高優先）/docs/governance/content-standards/overview— ブランドコントロールの深掘り/docs/sponsored-intelligence/overview— 会話型エンゲージメントモデルの理解/docs/creative/brand-json— 作成する必要があるブランドアイデンティティデータ/docs/learning/basics/intro— 構造化されたコンテンツを学ぶため認定を試すかもしれない
成功基準
- 彼は CMO に AI 広告が何か、なぜプログラマティックと違うか説明できる — 単なる「AI アプリの広告」ではなく「AI が私たちのブランドデータから広告を生成する」
- 組織的含意を理解している: チームがリテールメディア製品フィードを所有するのと同じ方法でブランドデータ品質（カタログ、ブランドアイデンティティ、コンテンツ標準）を所有する必要がある
- エージェンシーをブリーフできる: 「AdCP を話すバイヤーエージェントを構築または採用してほしい。私たちが提供するもの: 製品カタログ、brand.json、コンテンツ標準。私たちが期待するもの: 配信レポートを持つ主要 AI プラットフォーム全体の AI メディアキャンペーン。」
- ガバナンスストーリーを知っている: 「私たちはコンテンツ標準を AI プラットフォームにプッシュする。彼らは生成時にそれを強制する。AI が私たちのブランドについて正しいことを言うことを願うのはもう終わり。」
- Sponsored Intelligence を単なる広告ではなく新しい消費者エンゲージメントチャネルとして見る
- 競争リスクを明確に述べられる: 「今 AI メディアデータ品質に投資しなければ、競合はブランドデータがよりリッチなので AI 体験でより高性能な広告を持つだろう」
- 段階的計画を持つ: (1) ブランドデータの準備状況を監査、(2) 1 つの AI プラットフォームで 1 つのエージェンシーとパイロット、(3) AdCP 標準を通じてスケール
- ランディングから「これを CMO にプレゼンできる」までの合計時間: 45 分未満
ペルソナ 6: Priya Sharma — SMB e コマース創業者
ロール
DTC スキンケアブランドの創業者兼唯一のオペレーター。Shopify で稼働。年間 200 万ドルの収益。時折フリーランスの助けを借りてマーケティングを自分で処理。40 SKU の製品カタログを持つ。背景
Priya は Instagram と Google Shopping でブランドを構築した。彼女は自身の Meta Ads、Google Ads を管理し、最近 Amazon を始めた。各プラットフォームは独自の広告マネージャー、独自のクリエイティブ要件、独自のピクセル / コンバージョンセットアップを持つ。3 プラットフォームでは管理可能だが、顧客から ChatGPT と Perplexity の推奨を通じて製品を見つけたと聞いている — そして彼女はそこにプレゼンスがない。広告なし、ブランドプロフィールなし、製品がどう記述されるかのコントロールなし。 彼女は ChatGPT での広告を調べ、直接販売関係を要求することを見つけた。Perplexity は異なるプログラムを持つ。すべての AI プラットフォームが異なる。彼女はエージェンシーを持たず、エンジニアを持たず、さらに 5 つのプラットフォームを個別にセットアップし管理する時間もない。 彼女は技術的に有能 — Shopify アプリを構成し、Meta ピクセルをセットアップし、Zapier を使える — が、コードは書かない。「私のストアをこのプラットフォームに接続する」「予算を設定して実行させる」の観点で考える。彼女が既に知っていること
- Meta、Google、Amazon で広告を実行する方法 — キャンペーンセットアップ、予算、ターゲティング、クリエイティブ
- Shopify がストアを広告プラットフォームに接続するアプリ統合を持つこと
- 製品フィード管理 — Google Merchant Center フィードを保守
- 基本的な測定: ROAS、CPA、アトリビューションウィンドウ
- 彼女の製品が AI アシスタントレスポンスに、時に間違った価格や廃止された商品で現れていること
- AI プラットフォームがブランドをどう表現するか現在制御・改善できないこと
彼女が知らないこと
- AdCP が存在すること、「エージェント型広告」が何を意味するか
- 複数の AI プラットフォームに一度に接続する標準的な方法があること
- 既存の Shopify 製品フィードが基本的に AI プラットフォームにプッシュできるカタログであること
- AI プラットフォームがアップロードするクリエイティブからではなく製品データから広告を生成すること
- brand.json がすべての AI プラットフォームにわたってブランドアイデンティティを確立できること
- コンテンツ標準が AI プラットフォームが承認していない製品についてのクレームを作ることを防げること
- AdCP を直接実装するのではなく、パートナー（アドネットワーク、Shopify アプリ）を通じて機能する可能性が高いこと
- MCP や A2A が何か — 彼女はプロトコルではなくアプリと統合の観点で考える
誤解と盲点
- AI プラットフォームでの広告がダッシュボードを意味すると考える。 Meta Ads Manager のようなもの — クリエイティブをアップロード、ターゲティングを設定、予算を設定、ローンチ — を期待する。AI プラットフォームが彼女のデータから広告を生成するという考えは馴染みがない。
- プラットフォームごとにやる必要があると想定。 Meta、Google、Amazon に別々のアカウントを持つのと同様に、ChatGPT、Perplexity、Claude、Gemini などに別々のアカウントが必要だと想定。
- 製品フィードが既に必要なものの大半であることに気づいていない。 Google Merchant Center フィードはタイトル、説明、価格、画像、在庫状況を持つ。それが製品カタログ。標準パイプを通じて AI プラットフォームにプッシュするだけでよい。
- これを支払えないと考える。 「AI 広告」をエンタープライズ予算と関連づける。AI アドネットワークが複数プラットフォーム全体で月 500 ドルで始められることを知らない。
- ブランドコントロール問題を過小評価。 彼女の製品は既に AI 会話で議論されている — 時に不正確に。これを機会に接続していない: 正確な製品データ AND ブランドガイドラインをプッシュすれば、AI は推測する代わりに正しい情報を持つ。
主要ゴール
エージェンシーやエンジニアを雇わずに AI プラットフォームで広告できるか見極める。何を提供する必要があるか（製品データ、ブランド情報）、誰が助けるか（Shopify アプリ、アドネットワーク、パートナー）を理解する。小さく始めて機能するか見る。彼女が尋ねる主要な質問
- 「ChatGPT と Perplexity で広告できるか? どうやって?」
- 「エージェンシーが必要か、自分でできるか?」
- 「単に Shopify ストアを接続できるか?」
- 「始めるのにいくらかかるか?」
- 「新しいクリエイティブを作る必要があるか、AI がやるか?」
- 「AI が製品を正しく — 価格、説明、在庫状況 — 得ることをどう確認するか?」
- 「AI がブランドについて何を言うか制御できるか?」
- 「機能しているかどう分かるか? ROAS を見られるか?」
- 「これのための Shopify アプリはあるか?」
- 「これと単に Google Ads をやることの違いは何か?」
彼女が訪れそうなページ
/— ホームページ、平易な言葉の説明を探す/docs/intro— 技術的すぎると離脱するかもしれない/docs/sponsored-intelligence/overview— バイヤーセクションが彼女を捉えたら読む/docs/creative/catalogs— Shopify フィードが機能するか知りたい/docs/brand-protocol/brand-json— ブランド表現を制御したい/docs/governance/overview— AI が製品について間違ったクレームを作るのを防ぎたい/docs/learning/overview— ランドスケープを理解するため基礎を試すかもしれない
成功基準
- 彼女は既存の製品フィードが必要な主要な材料であることを理解している
- プロトコル配管を処理するパートナー（アドネットワーク、Shopify アプリ）を通じて機能することを知っている
- 価値を見る: 1 つの統合（パートナーを通じて）ですべての AI プラットフォームに到達 対 各々を個別にセットアップ
- ブランドコントロールストーリーを理解している: AI プラットフォームがブランドを正しく表現するよう正確なデータとガイドラインをプッシュする
- プロトコル用語に怖気づかない — コンテンツが彼女のいる場所で彼女に会う
- 明確な次のステップを持つ: Shopify で機能する AdCP 接続パートナーを見つける
- ランディングから「次に何をすべきか分かった」までの合計時間: 20 分未満
ペルソナ 7: Lisa Tran — ビルドプロジェクトをする非コーダー
ロール
中堅リテールブランドのデジタル VP。ブランドのデジタルメディア戦略とベンダー関係を管理。AI コーディングアシスタントに慣れている（内部ツーリングプロトタイプに毎日 Cursor を使う）が、TypeScript や JavaScript を手で書いたことは決してない。背景
Lisa は C トラック認定モジュール（C1-C3）を完了し、C4 ビルドプロジェクトを始めている。彼女は Cursor を使って小さな内部ツール — Slack ボット、スプレッドシート自動化、シンプルなダッシュボード — を、望むものを記述し出力を反復することで構築した。彼女はスタックトレースを読んだことがなく、npm が何か知らず、「コードを実行する」を「Cursor で再生を押すと機能する」と考える。
彼女は C1-C3 に合格した、材料が概念的だから — 購入ワークフロー、製品ディスカバリー、キャンペーン戦略。C4 は彼女に動作するバイヤーエージェントの構築を求める。彼女はエージェントが何をすべきか（製品を発見、メディアバイを作成、クリエイティブを同期）を理解するが、「記述できる」と「動作する」のギャップが彼女が苦労する場所。
彼女が既に知っていること
- C1-C3 からの AdCP 購入概念: 製品ディスカバリー、メディアバイ、クリエイティブ同期、ターゲティング、最適化ゴール
- AI コーディングアシスタントに望むものを平易な言葉で記述する方法
- AI と反復するワークフロー: 記述 → 生成 → テスト → 再び記述
- 彼女のブランドのメディア購入ニーズ — シナリオの実際のコンテキストを持つ
@cptestagentがテストするサンドボックスセラーであること
彼女が知らないこと
- 「実行中の MCP サーバー」が何を意味するか、実行中であることをどう検証するか
- エラーメッセージの読み方 —
TypeError: Cannot read properties of undefinedを見て何をすべきか分からない - コードが実行される前に
npm installやpip installが必要かもしれないこと - 「JSON レスポンスを貼り戻す」方法 — JSON が他のターミナル出力とどう違うか知らないかもしれない
- AI コーディングアシスタントがプロンプトで指定された adcp クライアントライブラリを必要とすること
- 検証フェーズのためにローカルエージェントを Addie に接続する方法
彼女が詰まる場所
- 最初のビルド試行が失敗。 AI コーディングアシスタントが実行されないコードを生成する。ターミナルにエラーが見えるが、どの部分がエラー対通常の出力か分からない。
- 反復方法が分からない。 彼女はシンプルなツールのため Cursor で反復する方法を知るが、依存関係を持つマルチファイル TypeScript プロジェクトは単一ファイル Slack ボットとは異なる。
- 仕様の問題をコードの問題と混同。 エージェントがエラーケースを処理しない場合、それは彼女の仕様が不完全だったからか、AI コーディングアシスタントがミスをしたからか? 彼女には分からない。
- 検証フェーズが混乱を招く。 「この MCP ツール呼び出しをローカルエージェントに対して実行」 — 彼女はそれが機械的に何を意味するか分からない。
彼女が Sage から必要とするもの
- フェーズ 1（仕様）: ここでうまくやる。AdCP 用語で購入ワークフローを記述できる。Sage は彼女の仕様がコーディングアシスタントに十分完全であることを確認すべき。
- フェーズ 2（ビルド）: ビルドが失敗したとき、Sage にデバッグループを教えてもらう必要がある — 彼女のためにデバッグするのではなく。「そのエラーメッセージをコピーし、Cursor に貼り戻し、『実行しようとしたときこのエラーが出た』と言う。」再び失敗したら、「Cursor に何を構築しようとしているか、エラーを修正すべきと伝える。」2-3 サイクルが正常で、失敗のサインではないことを学ぶ必要がある。
- フェーズ 3（検証）: 明確で機械的な指示が必要。「エージェントに対して get_products を実行」ではなく、ツールを正確にどう呼び出すか、どの出力をコピーバックするかのガイダンス。
- フェーズ 4（説明）: ここでうまくやる — 概念を理解している。
- フェーズ 5（拡張）: フェーズ 2 と同じパターン — 変更を仕様化し、コーディングアシスタントと反復し、結果を持ち帰る。
成功基準
- 彼女は誰にもコードを書いてもらわずにビルドプロジェクトを完了する
- デバッグループを学ぶ: エラー → アシスタントに貼り付け → 反復
- どの機械的ステップでも 5 分以上ブロックされない
- 体験がエンジニアリングでの失敗ではなく、コーチングのように感じる
- コードを書かない同僚に認定を推薦する