プラグインを改善および更新する

モニタリング エビデンスと評価を使用してプラグインを改善し、変更する必要があるものを見つけます。 修正または改善を適用し、テストしたパッケージを正確にリリースし、更新されたプラグインが目的のユーザーに対して引き続き機能することを確認します。

ビルダーはパッケージを保守してテストします。 Microsoft 365 管理者は、必要に応じて組織のロールアウト アクションを完了します。 サービス所有者は、プラグインが使用するコネクタ、リモート MCP サーバー、ID、外部サービスを管理します。

開始する前に

保有者:

• 現在のプラグイン ID とパッケージ バージョン。
• 現在のバージョンがユーザーに到達した方法: 直接共有、管理者によるアップロード、または Microsoft Marketplace。
• 証拠、ユーザー フィードバック、サポート ケース、または計画された改善の監視。
• 代表的なタスクと受け入れ基準。
• 影響を受けるユーザーと Microsoft 365 エクスペリエンス。
• プラグイン ソースへのアクセスと影響を受ける機能。
• 必要な接続と外部サービスの所有者。

何を変更する必要があるかまだわからない場合は、 プラグインのモニターから始めてください。

ベースラインを確立する

1. 対処したい問題または改善を述べます。
2. 影響を受けるパッケージのバージョン、ユーザー、エクスペリエンス、機能、依存関係を特定します。
3. 代表的なタスクと測定可能な受け入れ基準を定義します。
4. 現在のパッケージに対してタスクを実行し、結果を記録します。
5. organizationがプラグインを管理している場合は、その現在のステータス、ユーザーの可用性、およびインストール状態を Agents>Tools>Plugins に記録します。
6. 現在の動作と更新された動作を比較するために必要な証拠を保持します。

エージェントを含むプラグインの場合は、「 エージェント評価の概要 」を使用して、応答の品質、指示、知識、またはツールの使用が変更の一部である場合の評価を設計します。 評価は、プレリリースの証拠を提供し、使用シグナル、ユーザー フィードバック、エージェントと依存関係の変更によって発生した問題など、デプロイ後の品質の問題を調査するのに役立ちます。

エージェント評価は、すべてのプラグインに必要なわけではありません。 機能テスト、パッケージ検証、または完全なユーザー エクスペリエンスのテストに代わるものではありません。

展開された宣言型エージェントの場合は、ガイド付きwiqd agent evalワークフローを使用します。 直接コマンドラインまたはパイプライン制御については、「 エージェント評価 CLI の概要」を参照してください。

変更を適用してテストする

1. プラグインのソースまたは影響を受ける機能を更新します。
2. 変更が必要になった場合は、個別に運用されているサービスまたは構成を更新します。
3. 変更された各機能と影響を受ける依存関係をテストします。
4. ベースライン タスクと評価を再度実行します。
5. 結果を受け入れ基準と比較します。
6. リリース パッケージを作成する前に回帰を調査します。

変更がコネクタ、リモート MCP サーバー、ID、アクセス許可、または外部サービスに影響を与える場合は、その依存関係の所有者が関与します。 パッケージの変更によって、個別に運用されるサービスが更新されるとは想定しないでください。

パッケージの作成と検証

1. 新しいパッケージ バージョンを割り当て、公開方法の ID 要件をチェックします。
2. プラグイン パッケージを作成します。
3. リリースする予定の正確なパッケージを検証してテストします。
4. 必要なサインイン、同意、接続、外部サービスをテストします。
5. サポートするすべての Microsoft 365 エクスペリエンスでパッケージをテストします。
6. 既知の制限事項、必要な構成、使用可能なロールバックまたは交換オプションを記録します。

検証したパッケージとは異なるパッケージを公開しないでください。

更新プログラムの公開とロールアウト

更新されたパッケージと対象ユーザーに対して サポートされている公開または共有方法 を選択します。 既存のプラグインを更新する方法については、その手順を確認してください。新しいバージョンを共有またはアップロードするとレジストリ エントリが置き換えられたり、可用性設定が引き継がれたりすると想定しないでください。

リリースの前に、メソッドでパッケージ ID を再利用するか、別のエントリを作成するか、以前のユーザーの可用性とインストール設定が引き継がれるかどうか、必要に応じてバージョンを置き換えたり復元したりする方法を確認します。 2 つ目のエントリが表示された場合は、意図したユーザーが古いバージョンを制限する前に、新しいバージョンに移動したことを確認します。 まだ使用中のエントリは削除しないでください。

その後で以下の手順に従います。

1. 選択した方法で、テストされた正確なパッケージを公開、アップロード、または共有し、それが提出、公開、共有、拒否、ブロックされたかどうかを記録します。
2. 管理者またはロールアウト所有者に、正確なパッケージ バージョン、対象ユーザー、必要な構成、既知の制限事項、サポート連絡先を伝えます。
3. 更新されたプラグインを利用できるようにするには、該当する手順のみを完了します。 承認、割り当て、およびインストールの要件は、メソッドと organization の設定によって異なります。
4. 必要に応じて、個別に制御されるエージェント、接続、ID、リモート MCP サーバー、または外部サービスを更新します。
5. どのパッケージ バージョンが各オーディエンスに届いたかを確認します。

アルファ版の Work IQ Dev Tools プラグインの場合、 wiqd plugin share は選択した対象ユーザーのプラグイン レジストリに発行します。パブリック ストアへの申請はパートナー センターで個別に行われます。 別のリリースを準備する際は、 Work IQ Dev Tools プラグイン ガイド に従って、プロビジョニング、パッケージ化、検証、共有のシーケンスを確認してください。

ロールアウトする前に、メソッドが以前のバージョンの復元をサポートしているかどうかを確認します。 パッケージを置き換えても、外部サービス、接続、ID、データ、またはアクセス許可の変更は自動的に復元されません。

更新プログラムの検証

1. サポートされている各エクスペリエンスで、目的のユーザーを使用して代表的なタスクをテストします。
2. ユーザーが期待どおりのパッケージ バージョンを受け取ったことを確認します。
3. サインイン、同意、接続、ツール呼び出し、外部サービスが機能することを確認します。
4. プラグインがorganizationで管理される場合、そのステータス、ユーザーの可用性、およびインストール状態が Agents>Tools>Plugins の意図した対象ユーザーと一致チェック。 代替バージョンがまだ使用中かどうかを確認します。
5. 変更を承認するために使用した評価を繰り返します。
6. ロールアウト後に使用シグナル、フィードバック、エラー、サポート ケースを確認します。
7. 更新プログラムが受け入れ基準を満たしていない場合は、サポートされているロールバックまたは交換の手順に従い、必要に応じて影響を受ける依存関係を復元します。

対象ユーザーが正しいパッケージ バージョンを持ち、そのアクセス設定が意図したロールアウトと一致し、代表的なタスクが受け入れ基準を満たし、すべての未解決の問題に所有者と次のアクションがある場合、更新が完了します。

更新を記録する

記録:

• 以前のパッケージ バージョンと更新されたパッケージ バージョン。
• 変更、理由、影響を受ける機能、依存関係。
• ベースライン、評価、検証、およびユーザー テストの結果。
• 発行方法、対象ユーザー、ロールアウト状態、該当するレジストリ状態。
• 構成またはサービスの変更。
• 既知の制限事項、ロールバック オプション、サポート所有者。

関連コンテンツ

• プラグインを監視する
• プラグインをパッケージ化する
• プラグインの検証とテスト
• プラグインを公開または共有する
• プラグインを利用可能にする
• プラグイン、スキル、MCP サーバーを管理する
• プラグインの廃止