Work IQ 開発ツールを Microsoft 365 Copilot プラグイン CI/CD に統合する

Work IQ 開発ツール (WIQD) を使用して、継続的インテグレーションと継続的デリバリー (CI/CD) チェックを Microsoft 365 Copilot プラグイン プロジェクトに追加します。 この記事では、低コストなプル リクエストのチェックと、認証された候補テストおよび承認済みのリリース提出を区別します。

このガイドは、WIQD を既存の CI/CD システムに統合する開発者向けです。 完全な CI/CD 環境を設定する方法ではなく、要件とコマンド シーケンスが文書化されています。 システムのジョブ、トリガー、ランナー、シークレット、承認、およびアーティファクト処理を構成し、サンプルをそのシステムに統合する必要があります。 開始する前に、「 前提条件」にリストされているランナー、環境、および資格情報を準備します。

リリース先はテナントの organization アプリ カタログであり、管理者は送信されたプラグインをユーザーが検出する前に承認します。 直接共有は別の配布方法です。 このワークフローでは、パートナー センターを介した管理者の承認やパブリック ストアの公開は自動化されません。

前提条件

既存のパイプラインまたはワークフローで WIQD コマンドを実行するには、次のことを確認してください。

• ライフサイクル ファイル、コンポーネント テスト、非シークレット環境構成を含むソース管理された WIQD プラグイン プロジェクト。 「 Work IQ Dev Toolsを使用してプラグインを構築する」を参照してください。
• ソース チェックアウト、ランナー、保護されたシークレット、リリース承認コントロールを備えた既存の CI/CD システム。 そのシステムでジョブ、トリガー、およびアーティファクト処理を構成する方法を理解しています。
• Node.js 24.15.0 以降と、ランナー上の正確な承認済み WIQD リリース。 WIQD のインストール手順に従い、インストールされているバージョンを wiqd --version で記録します。
• この記事のコマンド例を使用するための PowerShell 7。
• テナント ベースのコマンド用に構成された WIQD 環境。 WIQD 環境構成に従って、環境ファイルを準備します。 個別のテスト環境と運用環境または Microsoft 365 テナントは、前提条件ではなくオプションです。 dev、 staging、 prod は従来の名前であり、テナントまたはデプロイ スコープに関する保証ではありません。
• 必要な代理同意を得て、選択したプロビジョニング、詳細検証、および公開操作に対して承認された Microsoft 365 ID。 WIQD の同意とリソースの制限に記載されているように、これらの操作に必要なアクセス許可のみを付与します。
• 宣言型エージェント評価の場合、プロビジョニングされたターゲット、レビューされたプロンプト ファイル、承認された品質しきい値、および個別に構成された評価認証と EULA 同意。 詳細なセットアップと要件については、 WIQD エージェント評価ガイド に従ってください。 エージェントの評価は、スキルのみのプラグインやツールのみのプラグインなど、エージェントのないプラグインには必要ありません。適用可能なコンポーネントとターゲット エクスペリエンス テストを保持します。

プラットフォームのセットアップとワークフローの作成については、CI/CD プロバイダーのドキュメントに従ってください。 たとえば、「最初の Azure パイプラインの作成」または「GitHub Actions の実装」を参照してください。

パイプライン シナリオを選択する

信頼されていない変更がデプロイ資格情報にアクセスしたり、リリースを送信したりできないように、個別のジョブを構成します。

プロジェクトのコンポーネント ビルドとテストを保持します。 WIQD は、すべてのプラグインにユニバーサル コンパイル コマンドを提供したり、プラグインが参照するリモート サービスを更新したりするわけではありません。

WIQD パイプライン セットアップ ガイドをプラグイン プロジェクトに適応させる場合は、この記事のwiqd pluginコマンド シーケンスを使用します。 このガイドの wiqd agent ライフサイクル例は、スタンドアロンのプラグイン プロジェクトではなく、エージェント プロジェクトを対象としています。

コストのかかる pull request チェックを追加する

Microsoft 365 資格情報なしでオフライン検証を実行します。 これらのチェックでは、リソースのプロビジョニング、エージェントの呼び出し、レジストリへの送信は行われません。

既存のジョブに静的チェックを追加するには:

1. 提案されたソースを確認し、承認された WIQD リリースをインストールします。
2. プロジェクトの適用可能なコンポーネント テストを実行します。
3. 次の WIQD 手順を実行し、 .\plugins\contoso をプロジェクト パスに置き換え、 dev 目的の環境コンテキストに置き換えます。
4. ジョブを渡すには、ネイティブ終了の成功と JSON の成功エンベロープが必要です。

この GitHub Actions ステップでは、スタンドアロン プラグイン プロジェクトで宣言型エージェントのソース サーフェイスをチェックします。

- name: Validate plugin source
  shell: pwsh
  run: |
    $ErrorActionPreference = 'Stop'
    $PSNativeCommandUseErrorActionPreference = $false
    $text = wiqd plugin validate --path .\plugins\contoso --env dev --mode static --json
    if ($LASTEXITCODE -ne 0) { exit $LASTEXITCODE }
    $result = ($text -join "`n") | ConvertFrom-Json
    if ($result.status -cne 'success') { throw 'Plugin source validation failed.' }

同じ PowerShell 本文を Azure パイプライン pwsh: ステップで実行できます。 ライフサイクルまたは評価の資格情報を、プロバイダーの信頼されていない pull request ジョブに挿入しないでください。

静的検証では、宣言型エージェント マニフェストと参照される API プラグインまたは OpenAPI ファイルを対象とします。 最上位レベルのアプリ マニフェスト、スタンドアロン スキル コンテンツ、またはルート コネクタ宣言は検証されません。 スキルのみのプラグインまたはコネクタのみのプラグインが合格する可能性があるのは、宣言型エージェントのチェックが適用されないためであり、すべてのコンポーネントが有効であるからではありません。

オフライン公開準備状況チェックを追加する場合は、次のコマンドを実行し、同じ終了コードと JSON チェックを適用します。

wiqd plugin publish --path .\plugins\contoso --env dev --dry-run --no-runtime --no-network --json

このチェックではプラグインは送信されません。 ランタイム チェックとネットワーク チェックは無効になり、エージェントが存在しない場合は宣言型エージェント フェーズはスキップされます。 オフライン チェックは、パッケージ優先の詳細な検証やターゲットの Microsoft 365 エクスペリエンスでのテストに代わるものではありません。

信頼されたジョブの認証を構成する

プロビジョニング、詳細検証、および公開には、プル リクエスト ジョブが持たない資格情報が必要です。 文書化された認証モードをテナント管理者と確認し、選択した WIQD リリースでのサポートを確認してから、信頼できる手順にのみ資格情報を挿入します。

更新トークン認証の場合:

1. WIQD パイプライン認証では、プライベートなローカル ブートストラップ手順に従います。
2. 結果のトークンを、承認されたパイプライン シークレット ストアに直接配置します。 コミットしたり、コマンド引数として渡したり、ログや成果物に含めたりしないでください。
3. テナントとトークンを信頼されたコマンド プロセスにマップします。
4. リリースの提出を有効にする前に、選択した WIQD リリース、ID、ランナー、および必要な操作を制御された実行で確認します。

信頼できる GitHub Actions ステップの場合は、次の環境バインディングを使用します。

env:
  CI_ENABLED: 'true'
  M365_TENANT_ID: ${{ vars.M365_TENANT_ID }}
  M365_REFRESH_TOKEN: ${{ secrets.M365_REFRESH_TOKEN }}

Azure パイプラインでは、シークレット変数に明示的な env マッピングが必要です。 次のバインドを使用し、WIQD を呼び出す前に未解決の $(NAME) マクロを拒否します。

env:
  CI_ENABLED: 'true'
  M365_TENANT_ID: $(M365_TENANT_ID)
  M365_REFRESH_TOKEN: $(M365_REFRESH_TOKEN)

これらは環境バインドであり、完全なパイプライン定義ではありません。 認証モードとプロバイダー固有のチェックの両方について、 WIQD パイプラインの例に従ってください。

CI_ENABLED 完全に小文字にする必要があります。 true汎用 CI=true では十分ではありません。 ライフサイクル コマンドを CI で wiqd auth login するのではなく、直接呼び出します。 これらは、アプリ専用 ID ではなく委任された資格情報であり、MFA、条件付きアクセス、同意、またはアクセス許可をバイパスしません。

WIQD はパイプライン シークレット ストアをローテーションしません。 認証に人間のサインインまたは同意が必要な場合は、ポリシーまたは同意の問題を解決し、文書化されたローカル手順を使用してシークレットを置き換えます。 別の ID に自動的に切り替えないでください。

候補を作成して検証する

リリース提出の前に、選択した WIQD 環境で候補をビルドしてテストします。 テストでは、リリースと同じテナント、環境構成、承認された Microsoft 365 ID を使用できます。個別のテスト環境は省略可能です。 関連するコマンドを同じプロジェクトと環境の状態に保持します。

候補者を準備するには:

1. 承認されたソース リビジョンとプラグイン パッケージ バージョンを選択します。
2. 選択した環境が既にプロビジョニングされている場合は、承認された安全な永続化メカニズムを通じて、確立された環境状態を利用できるようにします。 アプリ ID だけでなく、ライフサイクルに必要なすべての値を保持します。 プロジェクト アーカイブや認証キャッシュをダウンロードして資格情報を復元しないでください。
3. コンポーネントのビルド、テスト、オフライン プラグインの検証を実行します。
4. この候補に対して必要に応じて、選択した環境をプロビジョニングまたは更新します。
5. プロビジョニングで静的検証の対象となる入力が変更された場合は、影響を受けるソースを再検証します。
6. プロジェクトをパッケージ化します。
7. 生成された ZIP ファイルを正確に検証します。
8. ZIP、検証結果、ソース リビジョン、パッケージ バージョン、WIQD バージョン、および環境 ID を候補レコードに保持します。

次の PowerShell の例は、テナント リソースのプロビジョニングまたは更新を必要とする候補を対象としています。 認証が構成された後、信頼されたジョブ内で実行します。 選択した環境が既に ID バインドされていて、プロビジョニング更新が不要な場合は、provision コマンドを省略します。 入力が変更された場合にのみ静的検証を繰り返す。 プロジェクト パスと dev 環境を候補構成に置き換えます。 ヘルパーは、ネイティブ エラー、不正な形式の JSON、または失敗したエンベロープで停止します。

この例では、中間証拠として .artifacts\validation.json に完全な検証 JSON を書き込みます。 アクセスを制限し、テナント情報、識別子、URL、機密コンテンツを保持または共有する前に、ペイロードを確認します。 アップロードする前に証拠を消毒してください。成果物ディレクトリは自動的にアップロードしないでください。

$ErrorActionPreference = 'Stop'
$PSNativeCommandUseErrorActionPreference = $false

function Invoke-WiqdJson([string[]]$Arguments) {
    $text = & wiqd @Arguments
    if ($LASTEXITCODE -ne 0) { exit $LASTEXITCODE }
    $result = ($text -join "`n") | ConvertFrom-Json
    if ($result.status -cne 'success') { throw 'WIQD operation failed.' }
    return $result
}

$project = (Resolve-Path .\plugins\contoso).Path
$environment = 'dev'
$artifactDirectory = Join-Path $PWD '.artifacts'
New-Item -ItemType Directory -Path $artifactDirectory -Force | Out-Null
$package = Join-Path $artifactDirectory 'plugin-dev.zip'
$common = @('--path', $project, '--env', $environment, '--json')

Invoke-WiqdJson (@('plugin', 'validate', '--mode', 'static') + $common) | Out-Null
Invoke-WiqdJson (@('plugin', 'provision') + $common) | Out-Null
Invoke-WiqdJson (@('plugin', 'validate', '--mode', 'static') + $common) | Out-Null
Invoke-WiqdJson (@('plugin', 'package', '--output', $package) + $common) | Out-Null
if (-not (Test-Path -LiteralPath $package -PathType Leaf)) { throw 'Package output is missing.' }
$validation = Invoke-WiqdJson (@('plugin', 'validate', '--mode', 'deep', '--package-file', $package) + $common)
$validation | ConvertTo-Json -Depth 100 | Set-Content -LiteralPath (Join-Path $artifactDirectory 'validation.json')

詳細検証では、ビルドされた ZIP がプラットフォームのアプリ検証ライブラリに送信され、そのパッケージ チェックが報告されます。 ランタイム動作、接続準備、リモート サービスの正常性、パートナー センターの受け入れは確立されません。 これには認証されたサービス アクセスが必要であり、オフラインのプル要求チェックではありません。 認証の欠落、サービスの失敗、または拒否されたパッケージにより、候補がブロックされます。

プロビジョニングは、選択した環境ファイルとパッケージ化によって消費される TEAMS_APP_ID が書き込まれるため、通常はパッケージ化の前に行われます。 環境が既に ID バインドされていて、プロビジョニング更新が不要な場合は、プロビジョニング コマンドを省略し、その既存の状態に対してパッケージ化します。 再プロビジョニングではその ID が使用されますが、最新のチェックアウトでは自動的に保持されません。 実行間で安定した ID を確実に保持します。環境ファイル、ユーザー シークレット ファイル、認証キャッシュ、またはワークスペース全体を成果物として公開しないでください。

タイムアウト後にプロビジョニングまたは公開を自動的に再試行しないでください。 再実行を承認する前に、既存の操作とリソースを検査します。

展開された候補のテストと評価

必要な接続、アクセス許可、スキル、リモート サービスを含む、すべてのターゲット エクスペリエンスで候補者をテストします。 パッケージの検証では、すべての機能が実行時に動作することが確立されるわけではありません。

宣言型エージェントを含むプラグインの場合は、品質ゲートを追加します。

1. 展開された宣言型エージェント コンポーネントのタイトル ID を識別します。 スタンドアロン プラグインのカタログ タイトル ID に置き換えないでください。
2. レビューしたプロンプト ファイルと代表的なタスクの受け入れしきい値を準備します。 候補をベースラインと比較するときは、スイートを変更せずに保持します。
3. 評価 CLI の Microsoft 365 エージェント接続認証を構成し、目的のランナーで必要なテナント承認を取得します。 選択したジャッジの資格情報を個別に構成し、CI 外部で評価 CLI に必要な EULA の同意を完了します。
4. 配置されたコンポーネントに対して wiqd agent eval を実行し、結果を候補と保持します。
5. 評価が失敗した場合、しきい値が満たされていない場合、またはランナーが認証できない場合は、リリースをブロックします。

この例では、デプロイされたエージェントを evals\contoso ワークスペースから評価します。 確認したプロンプト ファイルを、チェックアウト ルートを基準にして evals\contoso\evals\prompts.json に配置します。 出力パスは、そのワークスペースを基準にして解決されます。 <deployed-agent-title-id>を候補コンポーネントのタイトル ID に置き換えます。 0.85しきい値はその一例です。シナリオに必要な品質バーを選択します。

$ErrorActionPreference = 'Stop'
$PSNativeCommandUseErrorActionPreference = $false
$agentId = '<deployed-agent-title-id>'
$text = wiqd agent eval --path .\evals\contoso --agent-id $agentId --env dev --threshold 0.85 --output .evals\results.json --json
if ($LASTEXITCODE -ne 0) { exit $LASTEXITCODE }
$result = ($text -join "`n") | ConvertFrom-Json
if ($result.status -cne 'success') { throw 'Agent evaluation failed.' }

WIQD Eval コマンドでは、プロンプト専用のワークスペースと明示的なエージェント ID のリファレンスが記載されています。 評価ワークフローは、しきい値の処理を文書化します。しきい値ミスとアップストリーム エラーはどちらも、JSON で異なるエラー コードを使用して、0 以外の終了を返します。

ライフサイクル更新トークンでは、評価は認証されません。 評価 CLI は独自の Microsoft 365 認証を使用し、判定は別の GitHub Copilot または Azure 資格情報を使用します。 WIQD ソースは、任意のホストされたランナーに対して完全な無人評価資格情報ブートストラップを提供しません。 自動ゲートにする前に、ランナーでそのセットアップを修飾してください。無人で実行できない場合は、スキップした実行を成功として扱うのではなく、承認された評価とその証拠を要求します。

wiqd agent eval プラグイン全体の評価機能や、スタンドアロンのスキル、ルート コネクタ、カスタム エンジン エージェントを評価しません。 これらの機能については、 プラグインの検証とテストで必要なコンポーネントとターゲット エクスペリエンスのテストを保持します。

テスターが直接アクセスする必要がある場合は、対象ユーザーを明示的に承認し、 WIQD プラグインの共有に従います。 共有するには、選択した環境ファイルと、それに対応する共有展開の AGENT_SCOPE=shared が必要です。環境 dev の名前付けでは、その範囲は確立されません。 共有要件をバイパスするために、個人用展開にラベルを変更したり、ID をコピーしたりしないでください。

承認済みの更新を organization アプリ カタログに送信します

保護されたリリース ジョブを使用して、organization アプリ カタログに更新を送信します。 候補テストでは、運用環境の変更や管理者の承認は許可されません。

更新プログラムをリリースするには:

1. 候補ソース リビジョン、パッケージ バージョン、検証結果、評価証拠 (該当する場合)、および意図された運用対象ユーザーを承認します。
2. リリース ターゲットの確立された環境状態をジョブで使用できるようにします。 実行するたびに新しいアプリ登録を作成するのではなく、更新のために既存のプラグイン ID を保持します。
3. テストした候補とは異なる環境構成またはプラグイン リソース ID をリリースで使用している場合は、影響を受けるプロビジョニング、パッケージ化、検証、およびテストをそのターゲットに対して繰り返します。
4. 認証された Microsoft 365 ID のみが変更された場合は、そのテナント、委任された同意、アクセス許可、および必要な操作へのアクセスを確認します。 認証 ID の変更だけでは、パッケージの再ビルドは必要ありません。
5. リリース ターゲットのパッケージと配置が、適用可能なテストに合格していることを確認します。 有効な構成、パッケージ、および展開の状態が変更されていない場合は、ターゲット検証を繰り返さずに候補の証拠を再利用します。
6. WIQD を介してリリース ターゲットのプロビジョニングされたプロジェクトを送信し、結果を記録します。
7. 承認のために提出を管理者に渡してから、更新されたアプリ カタログ エントリ、パッケージのバージョン、可用性、およびユーザー エクスペリエンスを確認します。

リリースターゲットを検証し、送信を承認した後、このコマンドは、選択したプロジェクトのプラグインを organization app カタログに公開します。 prod は環境名の例です。候補テストに使用するのと同じ環境であるように、構成済みのリリース環境を使用します。

$ErrorActionPreference = 'Stop'
$PSNativeCommandUseErrorActionPreference = $false
$text = wiqd plugin publish --path .\plugins\contoso --env prod --json
if ($LASTEXITCODE -ne 0) { exit $LASTEXITCODE }
$result = ($text -join "`n") | ConvertFrom-Json
if ($result.status -cne 'success') { throw 'Plugin submission failed.' }

発行結果をリリース レコードと共に保持します。

wiqd plugin publish 以前にビルドされた --package-file による ZIP ではなく、プロジェクトと環境を受け入れます。 キャプチャされた ZIP を詳細検証しても、公開によってそれらの正確なバイト数が送信されることは証明されません。 承認済みのソースと環境の状態を固定したままにし、固定された WIQD リリースの公開動作を修飾して、結果の送信バージョンを確認します。 これを不変の ZIP プロモーション ワークフローとは言わないでください。

WIQD プラグイン ガイドでは、次の結果が区別されます。

WIQD では、プラグイン レジストリ、スロット プロモーション、ロールバック コマンドは文書化されません。 リリース前に、サポートされている置換または回復の手順を確立し、パッケージ更新によって個別に運用されているサービスまたはアクセス許可が復元されると想定しないでください。 ロールアウトの検証と回復計画のために プラグインの改善と更新 に従います。

証拠を保持し、候補者をクリーンアップする

テナントの資格情報や評価データを未承認の閲覧者に公開することなく、承認済みの更新プログラムをトレースするために必要な証拠を保持します。

1. 承認されたソース リビジョン、WIQD リリース、パッケージ ID とバージョン、サニタイズされた検証と評価結果、および発行状態を保持します。
2. プロンプトと応答には組織データが含まれている可能性があるため、評価結果へのアクセスを制限します。
3. 候補となるデプロイを削除する前に、運用環境の更新プログラムを確認します。
4. 一時的な候補に別のリソース ID があり、不要になった場合は、その削除を明示的に承認します。 文書に記載されている WIQD プラグインの削除コマンド は、その候補の環境と ID に対してのみ使用してください。

破壊的クリーンアップを無条件のパイプライン ステージにしたり、候補クリーンアップの一部としてリリースされたプラグインの ID を削除したりしないでください。 テストとリリースで同じ ID が使用されている場合は、一時的な候補として削除しないでください。

関連コンテンツ

• WIQD パイプラインの設定と認証
• Microsoft 365 Copilot プラグインをパッケージ化する
• Work IQ Dev Tools プラグインの共有
• Microsoft 365 Copilot プラグインを発行または共有する
• プラグインを organization に発行する
• プラグインを利用可能にし、アクセスを管理します