add-ai-webapi

プラグインの確認：node "${PLUGIN_ROOT}/scripts/check-version.js" を実行してください。メッセージが出力された場合は、先にユーザーに表示してください。

AI Web API の追加

Note

AI 要約 API はプレビュー機能です。プレビュー機能は本番環境での使用を目的としておらず、機能が制限される場合があります。これらの機能は、正式リリース前にお客様が早期に利用し、フィードバックを提供できるように提供されています。

この注記を、フェーズ 1 とフェーズ 8 の概要で、ユーザーにそのまま提示してください — 上記の **Note** ブロックを（「正式リリース前にお客様が早期に利用し、フィードバックを提供できるように提供されています」という文言も含めて）正確にコピーしてください。独自の「プレビュー機能に関する注記：...」という文に言い換えないでください。この文言は Microsoft Learn のプレビューに関する免責事項と一致しており、言い換えるとその忠実性が損なわれます。

Power Pages の生成 AI 要約 API を SPA サイトに統合します。このスキルでは、AI レイヤー（レイヤー 3）、すなわち要約サービスコードと Summarization/* サイト設定に重点を置きます。基盤となる Web API の前提条件である Webapi/<table>/enabled、Webapi/<table>/fields、テーブル権限、Web ロールは、すべてのレイヤーで情報源を一元化するため、/integrate-webapi と /create-webroles に委任します。

対象となる2つの API

#	API	URL	Body	Response
1	検索サマリー	POST /_api/search/v1.0/summary	{ userQuery }	{ Summary, Citations }
2	データの要約	POST /_api/summarization/data/v1.0/<entitySet>(<id>)?$select=...&$expand=...	{ InstructionIdentifier } または { RecommendationConfig }	{ Summary, Recommendations }

例：サポート案件ページに表示される、Microsoft 提供の Copilot サマリー。 データの要約は、任意のエンティティセット、列、プロンプトの組み合わせで呼び出せます。ただし、Microsoft が標準の incident テーブル向けにドキュメントで説明し、提供している構成は1つです。 POST /_api/summarization/data/v1.0/incidents(<caseId>)?$select=description,title&$expand=incident_adx_portalcomments($select=description) を、本文 { "InstructionIdentifier": "Summarization/prompt/case_summary" } で呼び出します。これは Microsoft Learn で「案件ページ Copilot プリセット」と呼ばれることがあります。これはデータの要約のレシピの一例として扱ってください。ユーザーが Microsoft のサンプルを明示的に再現したい場合に役立ちますが、自動的に推奨するものではありません。カスタムの案件相当テーブル（cr363_servicerequest、adx_case）や、異なる観点（優先度、担当者、SLA タイマー）で要約する標準の incident テーブルは、メーカーが定義した値を使う通常のデータの要約呼び出しです。

参照先：${PLUGIN_ROOT}/skills/add-ai-webapi/references/ai-api-reference.md — API の標準形式、必須ヘッダー、サイト設定名、エラーコード、ドキュメントに記載されたサポート案件の例が記載されています。ワークフローの開始時に参照してください。ユーザーが最新情報を求めている場合は、 mcp__plugin_power_pages_microsoft-learn__microsoft_docs_fetch を使って Microsoft Learn のソースページを取得します。

管理者によるガバナンス階層：両方の API は、3段階の管理者階層によって制御されます。テナントの PowerShell 設定（enableGenerativeAIFeaturesForSiteUsers）、Copilot Hub による環境／サイトのガバナンス、サイトレベルのメーカー切り替え（検索サマリーの場合：Set up workspace → Copilot → Site search (preview) → Enable Site search with generative AI (preview)）です。 各レベルの設定は、1つ下のレベルの設定より優先されます。そのため、「メーカーの切り替えはオンなのに、API はまだ無効と表示される」という状況も実際に起こり得ます。管理者レベルのガバナンスが優先されます。

2つのエンドポイントでは、無効状態の返し方が異なります。

• 検索サマリー → HTTP 200 と、埋め込みエンベロープ { Code: 400, Message: "Gen AI Search is disabled." } が返されます。生成された fetchSearchSummary はこれを検出して SearchSummaryApiError をスローし、UI に解決方法を示すカードを表示します。
• データの要約 → HTTP 400 と、error.code = 90041001（管理者レベルで無効）または 90041003（サイトごとの Summarization/Data/Enable=false）が返されます。

完全なトラブルシューティングチェックリスト（テナント → 環境 → サイトに加え、ランタイムバージョン、Bing への依存関係、リージョン間のデータ移動）は、references/ai-api-reference.md §1「トラブルシューティング：AI 機能が無効に見える（管理者階層）」に記載されています。いずれかの無効状態が見られた場合は、ユーザーにこのページを案内してください。Phase 7 の前にこのガバナンス階層について明示的にユーザーに伝え、Phase 8 のまとめでも再度説明してください。

組み込みの検索コントロールとカスタムコードの経路：サイトで Microsoft 提供の Power Pages 検索コントロールを使っていて、そのページの検索結果を AI で要約したいだけであれば、このスキルは必要ありません。Copilot ワークスペースの切り替えと Search/Summary/Title コンテンツスニペットを設定するだけです。このスキルは、独自の検索 UI を構築するサイトや、カスタムコードから /_api/search/v1.0/summary を呼び出す必要があるサイト向けです。Phase 1 でユーザーがどちらの経路を使っているか確認してください。

基本原則

• レイヤー 3 のみを担当し、それ以外は委任します。 Web API のサイト設定、テーブルのアクセス許可、Web ロールはすべて /integrate-webapi と /create-webroles の担当です。このスキルでは、要約サービスのコードと Summarization/* サイト設定のみを作成します。それ以外は作成しません。
• エージェントは順番に起動します。 plugins/power-pages/AGENTS.md に従い、対象ごとに ai-webapi-integration エージェントを順番に起動します（並列実行はしません）。最初の呼び出しで共有の要約サービスファイルと CSRF ヘルパーを作成し、その後の呼び出しで拡張します。すべてのコード統合が完了した後、ai-webapi-settings-architect を単独で実行します。
• 生の fetch と CSRF を使用します。 すべての要約リクエストに /_layout/tokenhtml から取得した __RequestVerificationToken と X-Requested-With: XMLHttpRequest を付与します。OData ラッパー経由でリクエストしてはいけません。
• 不要な場合は /integrate-webapi をスキップします。 確認済みの対象がすべて検索サマリー（テーブルごとの Web API 前提条件が不要）である場合、またはレイヤー 1／2 の前提条件がすべてすでにディスク上に存在する場合、スキルはフェーズ 3 からフェーズ 5 に進みます。
• TaskCreate/TaskUpdate を使用します — 開始前に、すべてのフェーズを含む ToDo リストを作成します。
• サイトの整合性を維持します。 AI 機能を追加または調整する前に ${PLUGIN_ROOT}/references/site-modification-integrity.md を読みます。ローカライズでは、ラベル、読み込み中、空の状態、エラー、引用、推奨、修復の各状態に対応します。UI は双方向に操作でき、展開しても安全でなければなりません。

前提条件：

• /create-site で作成した既存の Power Pages SPA サイト
• データ要約の対象ごとに、/setup-datamodel または手動で設定済みの Dataverse データモデル（テーブルと列）
• 設定フェーズではサイトが少なくとも一度デプロイ済みであること（.powerpages-site フォルダーが存在すること）

初期リクエスト： $ARGUMENTS

---

ワークフロー

（ワークフロー以下のフェーズ見出しでは、実行時のレイヤー構造を示し、メンテナーが検索に使用する名称である技術用語「レイヤー 1+2／レイヤー 3」を維持しています。以下のタイトルは、ユーザー向けタスクリストに合わせています。）

1. サイトの準備状況を確認する — プロジェクトの場所を特定し、フレームワーク、データモデル、デプロイ状況、Web ロールの有無を確認します。
2. AI サマリーの適用先を見つける — コードを調べ、検索／データ要約の候補を探します。
3. 追加する内容を確認する — マニフェストを確認し、統合する API／対象を選びます。
4. AI のデータアクセスを設定する — 必要に応じて /create-webroles を実行し、データ／ケースの対象について AI 専用の読み取りモードで /integrate-webapi を実行します。検索のみの場合、または前提条件がすでに存在する場合は、完全にスキップします。
5. AI 要約コードを追加する — 対象ごとに ai-webapi-integration エージェントを順番に実行します。
6. AI プロンプトを登録する — ai-webapi-settings-architect エージェントを実行します。
7. すべてを検証する — ヘッダーコントラクトの grep、$select の grep、npm run build、バリデータースクリプトを実行します。
8. レビューしてデプロイする — スキルの使用状況を記録し、要約して、/deploy-site を提案します。

---

反復モード（初回実行後）

このスキルは一度限りのセットアップスキルです。ユーザーが要約 API の統合を初めて依頼したときに、フェーズ 1～8 を最初から最後まで実行します。AI の機能が実装済み（サービスファイル、フレームワークラッパー、UI 呼び出し箇所、Summarization/* 設定がすべて存在）になった後は、描画済み UI の調整（色、間隔、文言、ボタンの移動、別の空状態メッセージ、フックへの 2 つ目の推奨項目の接続など）を求められても、スキルを最初からやり直してすべてのフェーズを再実行する必要はありません。そうすると、調整のたびに完全な pac pages upload-code-site と連続した git commit が発生します。これは、上記のフェーズ 5.5／6.4 のプロンプトで避けようとしている、まさにその煩雑な進め方です。

すでに統合済みの AI 機能について、ユーザーから追加の UI 変更を依頼された場合：

• ファイルを編集し、ローカルで npm run build を実行して、調整がコンパイルできることを確認します。UI 変更の検証はこれだけです。
• **pac pages upload-code-site を自動的に実行しないでください。**アップロードは、ユーザーが調整を終えたセッションの最後に一度だけ行います。
• **git commit を自動的に実行しないでください。**関連する調整をまとめて 1 つのコミットにできるよう、ユーザーに任せます。
• ユーザーが作業終了を伝えたとき（または最後の変更依頼を完了したとき）に、セッション終盤のプロンプトを 1 回だけ表示して、デプロイとコミットをまとめて行います。

🚦 ゲート（同意 · add-ai-webapi:iter.deploy-commit）： 反復作業の最後にまとめてデプロイとコミットを行うためのプロンプトです。調整のたびにアップロードやコミットを行う煩雑な進め方を避けます。

**トリガー：**ユーザーがセッション中の UI 調整を終えたと伝えたとき。 **質問する理由：**小さな編集のたびに自動でデプロイまたはコミットすると、調整ごとに 1 回の git commit と 1 回の pac pages upload-code-site が発生します。まとめて行うことで、履歴を読みやすくし、重複するデプロイを避けられます。 **キャンセル時の影響：**ありません。ソースファイルはすでに編集済みで、デプロイもコミットも実行されません。

AskUserQuestion を使用します。

質問	ヘッダー	選択肢
UI の調整はすべて問題なさそうです。サイトをデプロイし、変更を今すぐコミットしますか？	デプロイとコミット	はい、デプロイしてコミットする（推奨）、コミットのみ — デプロイは後で行う、デプロイのみ — コミットは後で行う、どちらもしない — 両方とも自分で行う

ユーザーが新しい AI 機能（新しいページ、新しいテーブル、2 つ目の API）を追加する場合に限り、スキル全体のフローを再実行します。依頼が調整なのか、新しい機能なのか判断できない場合は、ユーザーに確認してください。

---

フェーズ 1：サイトの存在を確認する

目標：Power Pages プロジェクトのルートを特定し、前提条件を確認します。

1.0 イテレーションモードを検出する（何よりも先に）

このスキルの以降の処理では初回セットアップを前提とするため、再実行の検出を最初に行います。 プロジェクトの状態に関する次の2つのシグナルを確認します。

1. サービスシグナル：要約サービスが存在すること。src/services/aiSummaryService.*、または /_api/search/v1.0/summary もしくは /_api/summarization/data/v1.0/ を含む src/ 配下のソースファイルが該当します。シグナルが存在する場合は、サービスコードが参照する API サーフェス（検索のみ、データのみ、または両方）も記録します。この分類は以降の判定で重要です。
2. 設定シグナル：.powerpages-site/site-settings/Summarization-*.sitesetting.yml に Layer 3 のサイト設定が1つ以上存在すること。

次の組み合わせに基づいて処理を分岐します。

• 両方のシグナルが存在する → 再実行です。以前の /add-ai-webapi の実行がエンドツーエンドで完了しています。以下のイテレーションモードのプロンプトを表示します。
• サービスシグナルが存在し、既存のサービスコードが検索のみの場合（/_api/search/v1.0/summary を参照するが、/_api/summarization/data/v1.0/ は参照しない）→ 再実行です。検索のみのサイトでは Summarization/* 設定が存在しないのが正しい状態です（Search Summary は呼び出しごとの設定ではなく、ワークスペースのトグルを使用するためです）。したがって、設定シグナルがない状態は実行失敗ではなく、通常の状態です。以下のイテレーションモードのプロンプトを表示します。
• サービスシグナルが存在し、既存のサービスコードに Data Summarization が含まれているが、設定シグナルが存在しない場合 → 処理中の初回実行です（以前の試行が Phase 6 に到達する前に失敗しています）。プロンプトは表示せず、全フローを続行します。
• どちらのシグナルも存在しない → 初回実行です。Phase 1.1 に進みます。

イテレーションモードの分岐に到達したら、次の質問をします。

質問	ヘッダー	選択肢
AI 要約サーフェスがすでにこのサイトに組み込まれているようです。このリクエストは既存のものの調整ですか、それともまったく新しいサーフェス（新しいページ、新しいテーブル、2つ目の API）の追加ですか？	モード	既存のサーフェスを調整する（ビジュアルや文言の編集におすすめ）、新しいサーフェスを追加する（スキル全体を再実行）、わからない — すでに組み込まれているものを表示

• 既存のサーフェスを調整する：このスキルの実行を停止します。上記のイテレーションモードのセクションで説明されているワークフローに切り替えます — 編集と npm run build を行い、自動の upload-code-site は実行せず、自動コミットも行わず、セッション終了時にデプロイとコミットをまとめて確認します。
• 新しいサーフェスを追加する：Phase 1.1 に進みます（全フロー）。後続のフェーズでは既存のインフラストラクチャ（CSRF ヘルパー、要約サービス、設定）を検出し、重複させずに拡張します。
• わからない — すでに組み込まれているものを表示：既存のサービスファイル、接続済みの UI コンポーネント、Summarization/* 設定を一覧表示してから、同じ質問をもう一度します。

1.1 Todo リストを作成する

進捗の追跡を参照し、TaskCreate を使って8つのフェーズのタスクをすべて先に作成します。

1.2 プロジェクトを特定する

現在のディレクトリまたは直下のサブディレクトリで powerpages.config.json を探します。

見つからない場合：最初に /create-site でサイトを作成するようユーザーに伝えます。

1.3 フレームワークを検出する

package.json を読み取り、React／Vue／Angular／Astro を検出します。${PLUGIN_ROOT}/references/framework-conventions.md を参照してください。

1.4 データモデルを確認する

.datamodel-manifest.json を探します。見つかった場合は読み取ります。ここに記載されたテーブルは、Data Summarization API の候補です。標準の incident テーブルも他のテーブルと同様に候補の1つです。特別扱いしないでください。

1.5 デプロイ状況の確認 — 必須の前提条件

.powerpages-site を確認します。Phase 4（/integrate-webapi）と Phase 6（ai-webapi-settings-architect）では、 このフォルダーが存在する必要があります。デプロイを後回しにする方法は、現実的な回避策ではありません。 Phase 5 で AI 呼び出しサービスのコードを書き終えた後に、Layer 1/2/3 の設定がまだディスク上にないサイトを デプロイすると、実行時に動作しないコードが公開されます（2 回目のデプロイが完了するまで、すべての要約呼び出しが 403/500 エラーになります）。最も確実な手順は、AI コードがまだないうちに、今すぐクリーンなスキャフォールドを デプロイすることです。

.powerpages-site が存在しない場合：

質問	ヘッダー	選択肢
.powerpages-site が見つかりませんでした。AI 要約スキルでは、アクセス許可と設定を構成する前に、サイトを少なくとも 1 回デプロイしておく必要があります。クリーンなスキャフォールドを今すぐデプロイしますか（AI コードはまだありません。中間状態を安全に保てます）。それとも、停止して先に /deploy-site を実行しますか？	ブートストラップデプロイ	はい。スキャフォールドを今すぐデプロイする（推奨）、停止 — 先に自分でデプロイしてから /add-ai-webapi を再実行する

はいを選択した場合：power-pages:deploy-site の Skill ツールを呼び出し、完了を待ちます。その後、 続行する前に、.powerpages-site が存在することを再確認します。サブスキルの実行後も 存在しない場合（デプロイが途中で失敗した、ユーザーがキャンセルした、またはアップロードは完了したものの ローカルフォルダーが作成されなかった場合）は、ここで停止し、明確なメッセージを表示します。デバッグできるように deploy-site の結果をそのまま提示し、/deploy-site の後に /add-ai-webapi を再実行するよう伝えます。Phase 2 に黙って進んではいけません。後続のサブスキルでは、この フォルダーが必要です。

停止を選択した場合：次の手順を明確に伝えてスキルを終了します（「/deploy-site を実行してから、 /add-ai-webapi を再度呼び出して続行してください」）。Phase 2 に進んではいけません。後続のサブスキルは実行できません。

1.6 Web ロールの確認

.powerpages-site/web-roles/*.yml を確認します。ロールが存在するかどうかを記録してください。Phase 4 の 委任では、/integrate-webapi がテーブルのアクセス許可を作成する前に、少なくとも 1 つのロールが必要です。

出力：確認済みのプロジェクトルート、フレームワーク、データモデルの利用可否、デプロイ状況、Web ロールの一覧。

Phase 2：AI 統合ポイントを調査する

目標：2 つの API それぞれについて、AI に限定してすべての候補を見つけます。

Explore エージェントへのプロンプト本文、マニフェストの形式、委任判断のルールは、 ${PLUGIN_ROOT}/skills/add-ai-webapi/references/explore-prompt.md にあります。まずこのファイルを読み、 その後、プロンプト本文をそのまま渡して Explore エージェントを呼び出します（Task を使用し、 subagent_type: "Explore"、詳細度 medium を指定）。

Explore エージェントから報告される内容（要約 — 正確なプロンプトについてはリファレンスを参照してください）：

• 予約スロットマーカー（POWERPAGES:AI-SLOT kind=<pick>）— /create-site によって配置された、信頼できる配置ヒントです。孤立したマーカーにはフラグが立てられ、Phase 3 で解決されます。
• Search Summary の候補。詳細ページ上の関連レコード検索対象（「おすすめの KB 記事」「類似するケース」など）も含みます。
• Data Summarization の候補。single-record / list / intent-mismatch に分類され、それぞれに既存の取得処理で使われている OData クエリと、スコープ分類（matches-existing-fetch / scope-extends-beyond-existing-fetch / needs-definition / intent-mismatch）が付属します。
• 既存のインフラストラクチャ — CSRF ヘルパー、powerPagesApi.ts、既存の aiSummaryService.*。
• Data Summarization の各対象と、すべての $expand 対象に対する レイヤー 1/2 のステータス — ready / missing / n/a (search)。
• フィールド一覧の範囲に関する注意事項 — レイヤー 1/2 が ready の行のうち、既存の Webapi/<table>/fields が AI サーフェスに必要な範囲を超えているもの（主キーを含む、@odata.bind で使用されないリレーションシップの Navigation Properties、未使用の列）には fields-broader-than-ai-mode のフラグが立てられ、Phase 3 で提示できます。
• Data Summarization の各対象に対する レイヤー 3 のステータス — Summarization/Data/Enable と、コードが送信する特定の Summarization/prompt/<id>。

エージェントの出力から統合マニフェストを作成します（候補ごとに 1 行、列は #、API、Target file、Target kind、Entity Set、$select / $expand、Source、 Layer 1/2 status、Layer 3 status）。リファレンスファイルには記入例があります。

委任判断（ステータス列から直接算出）：

• /integrate-webapi を実行しますか？ → いずれかの行の Layer 1/2 ステータスが missing の場合は True です。tables= センチネルには、ステータスが missing の行だけを指定します。対応済みのテーブルは再監査しません。
• ai-webapi-settings-architect を実行しますか？ → いずれかの行の Layer 3 ステータスが missing の場合は True です。

出力：統合マニフェスト + 委任判断 + 既存インフラのレポート + fields-broader-than-ai-mode の注意事項一覧（該当する場合）

---

Phase 3：AI 計画を確認する

目標：マニフェストを提示し、統合する API と対象を確認します。

ユーザーに以下を提示します：

1. 見つかった API と対象の一覧。
2. それぞれについて、参照しているファイルとサービスの処理内容。
3. Phase 2 の 2 つの委任判断（「[tables] に対して /integrate-webapi を呼び出します」、 「レイヤー 3 に対して ai-webapi-settings-architect を呼び出します」）。
4. 既存インフラに関する注記（CSRF ヘルパーの再利用、powerPagesApi.ts、既存の aiSummaryService.*）。

承認のタイミング（事前に見通しを伝える）

統合に関する質問をする前に、「一度だけの」実行でユーザーが驚かないよう、判断があと何回必要かを簡潔に伝えてください。主な判断ポイントの一覧から、今回に該当しないものを差し引いて数えます。

• 検索のみの実行：/integrate-webapi への委任（フェーズ 4）と設定アーキテクト（フェーズ 6）を除外します。この質問の後に、あと 4～5 回確認します。
• レイヤー 1／2 がすでに準備済み：フェーズ 4.3 のアーキテクト承認を除外します。
• リスト／スコープ拡張／意図不一致に該当する行がない：対象ごとのフェーズ 3 の追加確認を除外します。
• 初回実行ですべての分岐に該当する場合：この質問の後に、あと 7～10 回確認します（ウェブ上の役割の選択、対象ごとのリストトリガーとスコープ確認、integrate-webapi のアーキテクト計画 2 件、AI 設定のアーキテクト計画、コミットの確認 2 回、最終デプロイ）。

警告ではなく、事前の案内として伝えてください。例：「この後、あと 6 回ほど入力をお願いします（ウェブ上の役割の選択、アーキテクト計画 2 件、コミットの確認 2 回、最終デプロイ）。リスト対象についてトリガーやスコープの判断が必要な場合は、さらに数回増えることがあります。」

統合に関する質問

AskUserQuestion を使用し、フェーズ 2 のマニフェストに基づいて選択肢を動的に作成してください。候補があるカテゴリが 1 つだけの場合に「検索の概要とデータの要約」を固定で表示してはいけません。見つかった内容に応じて質問文を作成してください。

• 両方のカテゴリに候補がある場合：「検索の概要とデータの要約の候補が見つかりました。どちらを統合しますか？」
• 候補があるカテゴリが 1 つだけで、対象が 1 つの場合：「すべて」を省き、単一の対象だけを確認します（「<page> に検索の概要を接続しますか？」）。

対応するカテゴリに候補がある場合にのみ、以下の既定の選択肢を表示します。

選択肢	含める条件
すべて（推奨）	両方のカテゴリに候補がある
検索の概要のみ	検索の候補とデータの要約の候補が両方ある
データの要約のみ	データの要約の候補と検索の候補が両方ある
対象を個別に選択する	複数対象の実行では常に含める
いいえ — キャンセル	常に含める

ユーザーが「対象を個別に選択する」を選んだ場合は、統合マニフェストの各行を一覧にした複数選択の質問を続けてください。フェーズ 2 で詳細ページの候補が関連レコード検出の対象として指定されていた場合は、同じページのデータの要約の選択肢に加えて、専用の選択肢として含めてください。これにより、ユーザーは手作業の OData 照合ではなく、AI に基づく方法を意識して選択できます。例：

• CaseDetail.tsx の検索の概要（生成 AI を使って関連する KB 記事を見つけます）
• ProductDetail.tsx の検索の概要（生成 AI を使って関連商品を見つけます）

選択肢には「検索の概要」だけでなく、ページ名と実現される内容を記載し、AI 機能がどこに表示されるかをユーザーが正確に把握できるようにしてください。

対象ごとの追加質問

ユーザーが対象を確認した後、必要な場合にのみ、対象ごとの追加質問をします。

• リストのトリガー — リストの対象ごとに、「開いたときに読み込む」か「手動ボタン」かを質問します。
• スコープの確認 — Phase 2 でその行に scope-extends-beyond-existing-fetch、 needs-definition、または intent-mismatch のフラグが付いた場合にのみ行います。 次に尋ねるスコープの質問（LIST または SINGLE-RECORD）は選択した対象の種類によって 決まるため、まず intent-mismatch を解決します。

質問文、選択肢のリスト、スコープ分類と質問の対応関係は ${PLUGIN_ROOT}/skills/add-ai-webapi/references/scope-classification.md にあります。 対象ごとの追加質問が必要な場合は、このファイルを読み込んでください。

選択した値は、Phase 5 のエージェント呼び出しプロンプトにある Scope for the summary call ブロック（$filter、$orderby、Scope source、Target's existing list fetch）に 渡されます。対象コンポーネントの既存 UI フェッチは変更せず、そのまま維持します。 サマリー URL は追加であり、既存のフェッチに置き換わるものではありません。

ユーザーが新しい $expand 対象を追加するスコープを選択した場合（例：「明細を含める」）は、 Phase 2 の Layer 1/2 の委譲判断を再評価します。新しい展開は新たな前提条件であり、 子テーブルで Web API が有効になっていることと、親スコープの権限が必要です。

「None — cancel」の処理

ユーザーが None — cancel を選択した場合：

1. 残りのタスクをすべて completed にし、activeForm に (skipped — cancelled by user) の接尾辞を付けて、タスクリストが pending のまま残らず、すっきり表示されるようにします。
2. Phase 8.1（--skillName "AddAiWebapi" と結果 cancelled を指定してスキルの使用を記録） および Phase 8.2（1 行の要約「変更はありません — プランのレビュー時にキャンセルされました」 を提示）に直接進みます。
3. Phase 4、5、6、7、8.3 はすべて省略します。/integrate-webapi、 ai-webapi-integration、ai-webapi-settings-architect、/deploy-site は呼び出さないでください。 コミットもしないでください。

出力：ユーザーが確認した統合マニフェスト、または適切に処理されたキャンセル。

---

Phase 4: Layer 1 + Layer 2 を委譲する

目標：Layer 1/2 のファイルを直接作成するのではなく、/create-webroles と /integrate-webapi（AI 専用の読み取りモード）に委譲して、AI 対象テーブルに必要な Web API の前提条件をすべて満たします。

4.1 スキップ判定

以下のいずれかに該当する場合、このフェーズ全体をスキップします。

• 確認済みの対象がすべて Search Summary である（検索にはテーブルごとの Web API の前提条件がありません）。
• Phase 2 の委譲判断で「Run /integrate-webapi? No」となった — すべての Layer 1/2 の 前提条件は、以前の実行ですでにディスク上にあります。
• .powerpages-site が存在しない（どちらのサブスキルもこれを必要とします）。

スキップする場合は Phase 5 に進み、最終要約でその旨を記載します。

4.2 不足している Web ロールを作成する（必要な場合）

Phase 1.6 で確認したとおり、.powerpages-site/web-roles/ に Web ロールが存在しない場合、または既存のロールがサイトの認証モデルと一致しない場合は、ユーザーに確認します。

質問	ヘッダー	選択肢
/integrate-webapi でテーブル権限を割り当てるには、少なくとも 1 つの Web ロールが必要です。一致するロールが見つかりませんでした。/create-webroles で今すぐ作成しますか？	Web ロール	はい、/create-webroles で作成する（推奨）、スキップ — ロールは別途対応します

はいの場合：呼び出し元抑制センチネルを含むプロンプトを指定して、power-pages:create-webroles の Skill ツールを呼び出します。これにより、サブスキルが独自のデプロイ確認を行わず、オーケストレーターが実行終了時のデプロイ判断を一括して行います。

[CALLED-BY-PARENT-SKILL] caller=add-ai-webapi

この Power Pages SPA サイト用の Web ロールを作成してください。親スキル /add-ai-webapi は、作成されたロールに AI 専用の読み取りモードのテーブル権限を後で割り当てます。デプロイの確認は行わないでください。オーケストレーターが最後にデプロイをまとめて行います。

完了するまで待ちます。その後、4.3 に進む前に .powerpages-site/web-roles/ を再確認します。

スキップの場合：これは既知の不具合がある経路になります。ユーザーが手動で Web ロールとテーブル権限を作成するまで、AI エンドポイントは実行時に 403 を返します。何も伝えずに先へ進まないでください。

🚦 ゲート（同意 · add-ai-webapi:4.2.skip-webrole）： Web ロールなしで続行する前に、明示的な確認が必要です。スキップすると、実行時にレイヤー 1/2 が機能しません。

トリガー： ユーザーが Web ロールの作成案内で「スキップ」を選択しました。 確認する理由： 何も伝えずに進めると、AI API エンドポイントは実行時に 403 を返します。このトレードオフを示すことで、ユーザーは停止するか続行するかを十分な情報に基づいて判断できます。 キャンセル時の状態： 何もありません — コードはまだ書き込まれていません。

2 回目の AskUserQuestion で、トレードオフを確認します。

質問	ヘッダー	選択肢
Web ロールがないとテーブル権限を設定できないため、ご自身で設定するまで AI エンドポイントは実行時に 403 を返します。ここで停止して先に /create-webroles を実行しますか？ それとも、フロントエンドのコードだけを書き、最後の要約で不足点を伝える形で続行しますか？	続行しますか？	ここで停止する（推奨）、続行 — フロントエンドのコードのみを書き、不足点を要約で伝える

ここで停止するの場合：スキルを正常に終了します。まず /create-webroles（必要に応じて /integrate-webapi も）を実行してから、/add-ai-webapi を再度実行するようユーザーに伝えます。

続行の場合：Phase 4 の残りをスキップして、Phase 5 に進みます（/integrate-webapi への委任では権限を割り当てる Web ロールが必要なため、4.3 を実行すると失敗します）。Phase 8 の要約では、レイヤー 1/2 の不足点を明確に示します。ユーザーが作成する必要のある正確なファイル（Webapi/<table>/enabled、Webapi/<table>/fields、各対象のテーブル権限）を列挙し、実行時に機能させるための手順が最終メッセージから明確に分かるようにします。

4.3 AI 専用読み取りモードで /integrate-webapi を呼び出す

Phase 2 のマニフェストからセンチネル引数を作成します。

• primary=<primary table logical name>（レコード／コレクションの要約対象となるテーブル。例：incident、cr4fc_product、cr363_workorder）
• tables=<primary plus every $expand target, comma-separated>
• expand-targets=<every $expand target, comma-separated; empty for pure data-summary targets with no $expand>
• caller=add-ai-webapi

単一のプロンプトを指定して、power-pages:integrate-webapi の Skill ツールを呼び出します。

[AI-READ-ONLY] mode=ai-read-only primary=<primary> tables=<list> expand-targets=<list> caller=add-ai-webapi

次の Power Pages AI 要約対象に対して、Layer 1/2（Web API のサイト設定とテーブル権限）を構成してください：

。これは読み取り専用の統合です。/_api/summarization/data/v1.0/ エンドポイントが Dataverse を変更することはありません。 すべての Web API サイト設定、テーブル権限、共有の powerPagesApi.ts クライアントがディスクに書き込まれたら、処理を終了してください。

AI 専用読み取りモードの契約（SKILL.md の Phase 1.6）に従ってください。

• コミットしないでください。 Phase 4.4 と Phase 6.5 をスキップし、コミットする予定だったファイルの一覧を出力してください。後でこのオーケストレーターがステージングします。親スキルがコミットをまとめて処理します。
• デプロイしないでください。 Phase 6.1 のデプロイ確認、Phase 7.3 のデプロイ確認、Phase 7.4 のデプロイ後のメモをスキップしてください。Phase 7.2 の要約を返して停止してください。オーケストレーション全体の最後に行う単一のデプロイは、親スキルが担当します。

/integrate-webapi は [AI-READ-ONLY] センチネル（Phase 1.6）を検出し、強化されたプロンプトを使用して一連のフローを実行します。読み取り専用のテーブル権限、最小限のフィールドリスト（主キーなし。ルックアップには _<col>_value のみ）、読み取り専用のサービスレイヤーが適用されます。ただし、各アーキテクトに対するプランモードの承認確認は引き続きユーザーに提示されます。このスキルがそれらを抑止することはありません。

/integrate-webapi の完了を待ちます。ファイルシステムを再確認してください。

• src/shared/powerPagesApi.ts が存在する
• 対象テーブルごとに、Webapi/<table>/enabled と Webapi/<table>/fields が存在する
• 対象テーブルごとに、read: true のテーブル権限が少なくとも 1 つ存在する。すべての $expand 対象には Parent スコープの権限が存在する

前提条件がまだ不足している場合は、先に進む前にユーザーに伝えてください。委任したフローで何かが反映されなかった可能性があります（例：ユーザーがアーキテクトのプランを拒否した）。ここで Layer 1/2 のファイルを作成する処理に、黙って切り替えてはいけません。

出力：Layer 1/2 の前提条件がディスク上にそろっており、共有の powerPagesApi.ts と読み取り専用サービスが存在し、Web ロールも存在します。

---

Phase 5：Layer 3 コードを実装する

目標：AI 要約サービスを作成し、各対象の UI に組み込みます。

5.1 ai-webapi-integration エージェントを呼び出す — 最初の対象（逐次実行）

確認済みマニフェストの最初の対象について、Task を介して ${PLUGIN_ROOT}/agents/ai-webapi-integration.md のエージェントを呼び出します。エージェントが必要とするすべてのフィールドと、各値を解決したオーケストレーターのフェーズに関する注記を含む完全なプロンプトテンプレートは、 ${PLUGIN_ROOT}/skills/add-ai-webapi/references/agent-invocation-prompt.md にあります。このファイルを読み、テンプレートをコピーして、現在の対象に対応する具体的な値で、すべての <…> プレースホルダーを置き換え、Task を介して渡してください。エージェントはプレースホルダーを解釈しません。文字どおりのテキスト <search | data> を送ると、混乱させてしまいます。

最初の呼び出しは逐次実行します。これは、後続の対象が再利用する共有の要約サービスファイル（src/services/aiSummaryService.*）と CSRF ヘルパーを最初に作成するためです。エージェントは構造化されたファイル変更一覧を返します（「Return value」セクションを参照）。Phase 5.5 のファイルごとのコミットに備えて記録してください。

5.2 サービスと CSRF ヘルパーの存在を確認する

エージェントを追加で起動する前に、次を確認してください。

• 要約サービスファイルが存在する（デフォルトは src/services/aiSummaryService.ts）。
• コードベース内で getCsrfToken が 1 か所で定義されている（または既存のヘルパーからインポートされている）。

5.3 残りのターゲットに対してエージェントを順次呼び出す

plugins/power-pages/AGENTS.md に従い、エージェントの起動は順次行います。残りのターゲットごとに ai-webapi-integration を一度呼び出し、完了を待ってから次を開始してください。各ターゲットで追加されるのは、独立したエクスポート関数、フレームワークラッパー（まだない場合）、および UI ファイル 1 つへの配線のみです。マージの競合はありませんが、順次実行のルールに従うことで、障害時の対応が簡単になります。

ターゲットが合計 1 つしかない場合は、5.3 をスキップしてください。

5.4 プレースホルダーの POST を置き換える

Phase 2 で Explore エージェントが指摘したプレースホルダーの InstructionIdentifier ボディについては、サブエージェントが置き換えているはずです。対象ファイルで InstructionIdentifier を検索し、解決済みの各呼び出しで実際のエンティティセットと ID が使用されていることを確認してください。

5.5 コミットするか確認する

自動的にコミットしないでください。反復実行時に、ここで予告なく git commit を行うと、実質的に 1 組の変更に対してコミットが大量に発生します。

🚦 ゲート（同意 · add-ai-webapi:5.5.commit）： Phase 5 の summarization-service と UI の配線が完了した後、明示的にコミットするかどうかを確認します。

トリガー： Phase 5 の全ターゲットの配線（サービス、フレームワークラッパー、UI の呼び出し箇所）が完了したとき。 確認する理由： 統合実行のたびに自動コミットすると、小さな変更ごとに 1 コミットが追加され、履歴が煩雑になります。ユーザーがまとめてコミットできるようにするほうが安全です。 キャンセル時に残るもの： なし。ソースファイルは書き込まれますが、git commit は実行されません。

AskUserQuestion を使用してください。

質問	ヘッダー	選択肢
これらの Layer 3 統合変更を今すぐコミットしますか？	コミット	はい、今すぐコミット（推奨）、スキップ — 後でコミットします

はいの場合：Phase 5 中に変更されたファイルのみをステージングしてください。対象は、summarization service、フレームワークラッパー、配線した各 UI ページ、およびエージェントが出力した safe-markdown レンダラーコンポーネントです。オーケストレーターは、各 ai-webapi-integration 呼び出しのファイル変更レポートから、この一覧をすでに取得しています。ファイルごとに明示的な git add <path> を使用し、git add -A は使用しないでください。そうしないと、src/ 内の無関係な作業中ファイルまでコミットに含まれるおそれがあります。コミットメッセージの <targets> は、簡潔で分かりやすい一覧（例：CaseDetail and SearchResults、ターゲットが多い場合は 3 pages）に置き換えてください。

git add <each file modified by the Phase 5 agents>
git commit -m "Add AI summarization integration for <targets>"

スキップの場合：コミットせずに続行してください。ユーザーが最後にまとめてコミットします。

出力： 確認済みのすべてのターゲットについて、summarization service、フレームワークラッパー、および UI の呼び出し箇所を作成します。

---

Phase 6：Layer 3 の設定

目標： ai-webapi-settings-architect エージェントを通じて Summarization/* サイト設定を登録します。

6.1 スキップ条件の確認

以下の両方を満たす場合は、この Phase をスキップしてください。

• 確認済みのターゲットがすべて Search Summary であること（検索には呼び出しごとの Summarization/* サイト設定がありません。ai-api-reference.md を参照してください）。
• Phase 3 で Data Summarization のターゲットが追加されていないこと。

検索のみの場合は、デプロイ後にサイトの Copilot ワークスペースで Site search with generative AI (preview) を有効にするようユーザーに伝え、Phase 7 に進んでください。

6.2 デプロイの前提条件を再確認する

Phase 1.5 では、.powerpages-site が存在することをすでに条件として確認しています。ここで再確認してください。Phase 1 の後に消えている場合（まれですが、ユーザーが手動でフォルダーを削除した可能性があります）は、停止して Phase 1.5 の bootstrap-deploy プロンプトを再実行してください。フォルダーがない状態で、そのまま architect に進んではいけません。

6.3 ai-webapi-settings-architect を呼び出す

Task を介して ${PLUGIN_ROOT}/agents/ai-webapi-settings-architect.md のエージェントを呼び出します。

「この Power Pages SPA サイトを分析し、生成 AI による要約のサイト設定を提案してください。 以下のデータ要約ターゲットは Phase 5 で統合済みです。各ターゲットのエンティティセット、ターゲットごとの InstructionIdentifier 値、およびターゲット種別（single-record または list）を列挙してください。これは、アーキテクトが Summarization/Data/ContentSizeLimit を決めるために必要です。 ターゲットに list が1つでもある場合、計画には必ず Summarization/Data/ContentSizeLimit=200000 を含めてください。サーバーのデフォルト値 100k ではリストの内容が通知なく切り詰められます。これは必須です。 既存の Summarization/* 設定を確認してください。レイヤー 1 （Webapi/<table>/*）とレイヤー 2（テーブル権限）は、Phase 4 で /integrate-webapi を使い、AI 専用の読み取りモードで設定済みです。これらがディスク上に存在することを確認し、計画の前提条件テーブルに充足済みとして記載してください。プランモードで AI 計画を提案し、承認されたら create-site-setting.js で YAML を作成してください。」

エージェントが完了するまで待ちます。レイヤー 1／2 の前提条件が不足していると報告された場合は、Phase 4 の処理が完了していません。ファイルシステムを確認して不足箇所を特定し、ここでレイヤー 1／2 のファイルを作成しようとせず、ユーザーに伝えてください。

6.4 コミットを提案する

🚦 ゲート（同意 · add-ai-webapi:6.4.commit）： アーキテクトが Summarization/* サイト設定を作成した後、コミットするかどうかを明示的に決定します。

トリガー： ai-webapi-settings-architect がすべての Summarization/Data/Enable および Summarization/prompt/<id> YAML を書き込みました。 確認する理由： 自動コミットすると、既存の未コミット YAML がコミットに含まれる可能性があります。明示的な同意を得ることで、コミット対象をアーキテクトの出力のみに限定できます。 キャンセル時： 何もありません。YAML ファイルはディスクに書き込まれますが、git commit は実行されません。

AskUserQuestion を使います。

質問	ヘッダー	選択肢
新しい Summarization/* サイト設定をコミットしますか？	コミット	はい、今すぐコミット（推奨）、スキップ — 後でコミットします

はいの場合：アーキテクトが作成したファイルのみをステージします。ai-webapi-settings-architect が返した filePath の一覧（または各 create-site-setting.js 呼び出しで出力されたファイルごとのパス）を使用し、glob は使わないでください。glob を使うと、無関係な理由で未コミットになっている既存の Summarization-* YAML（例：以前の部分的な実行や、メーカーが編集したプロンプト）まで拾い、誤ってコミットに含める可能性があります。

ファイルごとに明示的な git add <path> を使います。

git add <each Summarization-*.sitesetting.yml the architect just wrote>
git commit -m "Add AI summarization site settings"

スキップの場合：コミットせずに続行します。

出力： Summarization/Data/Enable、Summarization/prompt/<id> の設定が作成されます。

---

Phase 7：検証

目標： 想定されるすべてのファイルが存在し、すべての POST で必須のヘッダーが両方設定され、プロジェクトがビルドできることを確認します。

プレビュー機能に関する注意。 ビルドが成功しても、実行時に API が要約を返すとは限りません。管理者レベルのガバナンス（テナントの PowerShell、Copilot Hub）または Search Summary に関するサイトレベルのメーカー設定が、引き続きブロックする可能性があります。このスキルの冒頭にあるプレビュー機能に関する注意と、 references/ai-api-reference.md §1「トラブルシューティング：AI 機能が無効に見える」の管理者階層チェックリストを参照してください。 デプロイ後のテストが予想外にならないよう、今すぐユーザーに伝えてください。

7.1 ファイル一覧

確認済みのターゲットごとに、以下を確認します。

• サービスファイル：src/services/aiSummaryService.ts（またはプロジェクトの規約に準拠したファイル）に、想定されるエクスポート関数（fetchSearchSummary または fetchDataSummary。ユーザーがサポートケースのシナリオを選択した場合、エージェントが fetchCaseSummary のような薄いラッパーも出力することがあります）が含まれている。
• フレームワークラッパー（Astro 以外）：src/hooks/ の React フック、src/composables/ の Vue コンポーザブル、または src/app/services/ の Angular サービス。
• UI の接続：少なくとも 1 つのページ／コンポーネントがサービスまたはラッパーをインポートして呼び出している。
• 共有 API クライアント：Data Summarization のターゲットが対象範囲に含まれる場合、src/shared/powerPagesApi.ts が存在する。
• Summarization/Data/ContentSizeLimit サイト設定：リスト要約のターゲットが統合されている場合。ソースで fetchListSummary を grep します。一致するものがある場合は、.powerpages-site/site-settings/Summarization-Data-ContentSizeLimit.sitesetting.yml が存在し、value: 200000（またはそれ以上）が設定されていることを確認します。この設定がないと、リスト要約はサーバーのデフォルトである 100k にひそかに制限され、ユーザーには入力が途中で切り詰められた状態で提供されます。設定がない場合は、Phase 7 を完了する前に不足をユーザーに伝え、アーキテクトを再実行するか、YAML を手動で作成します。

7.2 ヘッダー契約の grep

Grep: "_api/search/v1\\.0/summary|_api/summarization/data/v1\\.0/" in src/**/*.{ts,tsx,js,jsx,vue,astro}

一致したファイルごとに、周辺の fetch に以下が含まれていることを確認します。

• __RequestVerificationToken（/_layout/tokenhtml から取得する CSRF トークン）— 必須ルール
• X-Requested-With: XMLHttpRequest — 推奨（バリデーターはこれがない場合に警告しますが、処理はブロックしません。shell.ajaxSafePost およびその他すべての Power Pages POST と同じ形式です）

データ要約の呼び出しでは、さらに以下の両方を確認します（必須ルール）。

• URL に $select= が含まれている（ワイルドカードは使用しない）
• OData-MaxVersion: 4.0 と OData-Version: 4.0 のヘッダーが設定されている

不足している 必須ルール のヘッダーがあれば、先に修正します。CSRF がない場合は 500 エラーが発生し、$select または OData ヘッダーがない場合は 403／400 エラーが発生します。X-Requested-With がない場合はバリデーターの警告のみが発生します。一貫性のために追加してください。ただし、処理が失敗することはありません。

7.3 ビルドチェック

cd "<PROJECT_ROOT>"
npm run build

型またはインポートのエラーを修正します。よくある問題は、接続したページで要約サービスがインポートされていないこと、DataSummaryResponse と UI 側の利用コードの型が一致しないこと、（Phase 5 で既存のヘルパーの再利用に失敗した場合の）getCsrfToken 宣言の重複です。

7.4 検証結果の提示

ターゲットファイル	API	サービス関数	ラッパー	UI 呼び出し箇所	ヘッダー ✓	$select ✓
src/pages/SearchResults.tsx	検索要約	fetchSearchSummary	useSearchSummary	あり	あり	対象外
src/pages/CaseDetail.tsx	データ要約	fetchDataSummary（任意で fetchCaseSummary としてラップ）	useCaseSummary	あり	あり	あり
src/pages/ProductDetail.tsx	データ要約	fetchDataSummary	useProductSummary	あり	あり	あり

（Phase 2 のマニフェスト例と同じ行順およびファイルパスの例を使用しているため、両方の表を読むメンテナーは、各行を上から下へたどれます。2 行目は Microsoft が提供するサポートケースのレシピに対応しています。これは、incidents 用に設定し、case_summary プロンプト識別子を使用する Data Summarization の呼び出しです。）

ビルドの状態： 成功／失敗（詳細を記載）。

7.5 最終サイト整合性ゲート

すべての AI 統合に関するソース変更とビルド検証が完了した後、以下を実行します。

node "${PLUGIN_ROOT}/scripts/validate-site-integrity.js" --projectRoot "<PROJECT_ROOT>"

完了を報告したりデプロイを提案したりする前に、ブロックするエラーをすべて修正します。両方の方向から、展開されたコンテンツを含めて確認事項を調査し、報告します。以降にソースを変更した場合は、このゲートを再実行します。

出力：すべての統合ファイルの検証済み、プロジェクトのビルド成功。

---

Phase 8：レビューとデプロイ

目標：スキルの使用状況を記録し、概要を提示して、デプロイを提案します。

8.1 スキルの使用状況を記録する

参考資料：${PLUGIN_ROOT}/references/skill-tracking-reference.md

--skillName "AddAiWebapi" を使用します。

8.2 概要の提示

ステップ	ステータス	詳細
Web ロール	/create-webroles で作成 / 既存のものを再利用 / スキップ	ロール名
レイヤー 1/2（Web API 設定 + 権限）	/integrate-webapi で作成 / 既存のものを再利用 / スキップ（検索のみ）	書き込んだファイルの一覧
要約サービス	作成 / 拡張	エクスポートされた関数、ファイルパス
フレームワークラッパー	作成 / 拡張	hook/composable/service のパス
UI 呼び出し箇所	接続済み	ファイルの一覧
レイヤー 3（Summarization/* 設定）	作成 / 既存 / スキップ	Summarization/Data/Enable。プロンプトごとに 1 つ

8.3 デプロイの確認

質問	ヘッダー	選択肢
すべて準備できました。要約 API を利用可能にするため、サイトをデプロイしますか？	デプロイ	はい、今すぐデプロイ（推奨）、いいえ、後でデプロイします

はい：/deploy-site を実行します。 いいえ：了承します。新しい設定と権限を含めてサイトをデプロイするまで API 呼び出しは機能しないことを伝えます。

8.4 デプロイ後の注意事項

実行の最後に、以下の内容をユーザーに伝えます。

• Search Summary の切り替え — Search Summary を統合する場合は、Set up workspace → Copilot → Site search (preview) → "Enable Site search with generative AI (preview)" をオンにするようユーザーに伝えます。オンにしないと、エンドポイントは無効状態のエンベロープを返し、UI には要約ではなく修正方法を示すカードが表示されます。
• テスト手順 — Data Summarization の場合は、レコード詳細ページまたは一覧ページを開いて要約を実行し、200 とテキストの表示を確認してから、推奨チップをクリックし、後続のリクエストで RecommendationConfig が送信されることを確認します。Search Summary の場合は、検索を実行し、キーワードの検索結果の上に要約が表示され、引用アンカーが /page-not-found/ ではなく SPA ルートを指していることを確認します。Microsoft 提供のサポートケース用レシピでは、コメントのない新規作成ケースに対して 90041005（要約する内容がありません）が返るのは正常です。選択または展開したすべての列に実質的な内容があるレコードでテストしてください。
• 無効状態のカードまたは 90041001 が表示された場合 — references/ai-api-reference.md §1「トラブルシューティング：AI 機能が無効と表示される（管理者階層）」の管理者階層チェックリストに沿って確認します。再試行しても解決しません。管理者または作成者がガバナンス設定を変更するか、サイトの切り替えをオンにする必要があります。
• 要約呼び出しで 403 が発生する場合は、常にレイヤー 1/2 の問題です（Webapi/<table>/fields の列名の大文字・小文字、またはテーブル権限に read: true がないことが原因です）。YAML を手作業で編集せず、AI のみの読み取りモードで /integrate-webapi を再実行します。
• エラーコードの全リファレンス（90041001 … 90041006）は references/ai-api-reference.md §2「エラーコード」にあります。ユーザーから 400 の報告があった場合は、こちらを開いてください。
• 列権限プロファイルによって、コンテンツが気付かれないまま非表示になることがあります。 要約に明らかな欠落がある場合は、プロンプトやフィールド一覧を疑う前に、Web ロールの Dataverse 列権限プロファイルを確認してください。

出力：概要を提示し、デプロイの完了または延期を伝え、デプロイ後の案内を行います。

---

重要な注意事項

すべてのフェーズを通して

• TaskCreate/TaskUpdate を使用して、各フェーズの進捗を追跡します。
• 重要な判断ポイント（以下に記載）でユーザーに確認を求めます。
• エージェントの起動は順次行います — plugins/power-pages/AGENTS.md の「Agent spawning」ルールに従います。ai-webapi-integration を複数のターゲットに対して並列で起動してはいけません（すべてのターゲットが同じ aiSummaryService.* ファイルを拡張するため、並列実行すると競合します）。
• 節目ごとにコミットします — 実装後（フェーズ 5）と設定作成後（フェーズ 6）にコミットします。
• 要約の取得に OData ラッパーを使用してはいけません — 生の fetch のみを使用します。
• レイヤー 1/2 のファイルを直接書き換えてはいけません — 必ず /integrate-webapi / /create-webroles に委任します。このスキルはレイヤー 3 です。

重要な判断ポイント（ユーザーの応答待ち）

以下のリストは、控えめに見積もった上限です。スキップチェック（検索のみの実行、Layer 1/2 の準備完了、リスト対象やインテント不一致対象がない場合）によって分岐全体が省かれるため、多くの実行ではプロンプトがこれより少なくなります。複数の対象を扱う初回実行で現実的に想定される最大数は約10件です。再実行で既存の設定を調整するだけなら、プロンプトは1件（Phase 1.0 のモードに関する質問）のみです。

1. Phase 1.0（再実行の検出）：既存のサーフェスを調整する、新しいサーフェスを追加する、またはすでに接続済みの内容を確認するかを選びます。以前の /add-ai-webapi の実行によって、サービスファイルまたは Summarization/* の設定がディスク上に残っている場合にのみ表示されます。
2. Phase 1.5：デプロイのブートストラップを実行するか、終了するかを選びます（.powerpages-site が見つからない場合）。
3. Phase 3（メイン処理）の後：統合する API／対象を確認します。
4. Phase 3 の対象ごとの追加確認（件数は変動）：リスト対象ごとのリストトリガーの選択と、scope-extends-beyond-existing-fetch、needs-definition、または intent-mismatch の各行に対するスコープ確認です。質問文と選択肢のリストは references/scope-classification.md に記載されています。
5. Phase 4.2：必要に応じて、/create-webroles を使って不足している Web ロールを作成します。呼び出し元による抑制を示すセンチネル付きでサブスキルを呼び出すため、サブスキル独自のデプロイに関するプロンプトは表示されません。
6. Phase 4.2（スキップする場合のみ）：既知のランタイム障害リスクがあることを承知のうえで続行するか確認します。
7. Phase 4.3 の /integrate-webapi への委任処理内：table-permissions-architect の計画と webapi-settings-architect の計画をそれぞれ承認します（各アーキテクトは独自の計画モード用プロンプトを管理します。サブスキルは AI 専用の読み取りモードで実行されるため、コミットとデプロイに関するプロンプトは表示されません）。
8. Phase 5.5：統合の変更を今すぐコミットするか、後でコミットするかを選びます。
9. Phase 6.3 の ai-webapi-settings-architect 呼び出し内：その計画を承認します。
10. Phase 6.4：新しい設定を今すぐコミットするか、後でコミットするかを選びます。
11. Phase 8.3：今すぐデプロイするか、後でデプロイするかを選びます。

リスト要約のユースケース向けプレイブック

対象が単一レコードではなく、レコードの LIST の場合、単一レコード用 Copilot カードのデフォルト設定は適切ではありません。コレクションエンドポイント、表形式のインサイト用プロンプト、ContentSizeLimit=200000、normalizeSummaryString と安全なマークダウンレンダラーなどが該当します。

10項目から成るプレイブック全体（コレクションエンドポイント、スコープのミラーリング、プロンプトのサイズ、ナビゲーションプロパティの大文字・小文字の使い分け、必須の ContentSizeLimit）は、${PLUGIN_ROOT}/skills/add-ai-webapi/references/ai-api-reference.md の §2「リスト要約のプレイブック」に記載されています。リスト要約の対象が Phase 5 に進む前に、このセクションを読んでください。Phase 5 のエージェントと Phase 6 の設定アーキテクトは、どちらも同じプレイブックを参照します。

進捗の追跡

フェーズ 1 を開始する前に、TaskCreate を使ってすべてのフェーズを含むタスクリストを作成します。

タスクの件名	activeForm	説明
サイトの準備状況を確認する	サイトの前提条件を確認しています	プロジェクトルートを特定し、フレームワークを検出し、データモデル、デプロイ状況、Web ロールの一覧を確認します
AI 要約の適用箇所を探す	AI 要約の候補をコードからスキャンしています	Explore エージェントを使って、検索／データ／ケースの候補、既存のインフラ、委譲の判断を確認します
追加する内容を確認する	AI 要約の計画を確認しています	マニフェストを提示し、統合する API と対象を確認します
AI のデータアクセスを設定する	Web API のアクセスと権限を設定しています	必要に応じて /create-webroles を実行し、その後、AI のみの読み取りモードで /integrate-webapi を実行します（検索のみの場合はスキップします）
AI 要約コードを追加する	ページに AI 要約コードを追加しています	ai-webapi-integration を順次呼び出します。最初の対象で共有サービスと CSRF ヘルパーを作成し、残りの対象でそれを拡張します
AI プロンプトを登録する	AI プロンプトの設定を登録しています	ai-webapi-settings-architect を実行して、Summarization/* 設定を作成します
すべてを検証する	ファイル一覧、ヘッダー、ビルドを検証しています	サービスファイル、ラッパー、UI の配線、ヘッダーの契約を確認し、プロジェクトのビルドを実行します
レビューしてデプロイする	要約をレビューしてデプロイしています	スキルの使用状況を記録し、要約を提示して、/deploy-site を提案し、デプロイ後のガイダンスを提供します

各タスクの開始時に TaskUpdate を使って in_progress にし、完了時に completed にします。

---

フェーズ 1：サイトの存在を確認することから始めます