Copilot Chatで受入テストを考える―境界値と未定義の仕様を分ける

この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。 Microsoft公式資料を2026年11月3日に確認し、架空の予約仕様から受入テストを考える手順を整理しました。Copilotの実行結果は未確認です。

検証ステータス：📘 公式情報確認済み・プロンプト実行未確認

まず3操作で試す

1. 組織で許可されたCopilot Chatを開き、下の「小さい架空仕様からテスト表を作る」にあるプロンプトを貼り付けます。

2. 生成された表で、人数の境界値「0・1・10・11」と、S4の「未定義」が区別されているか確認します。

3. S1の上限を「12人」へ変えて新しい会話で試し、12人と13人の扱いを比較します。

操作後はここを見る： 0人と11人は条件外、1人と10人は条件内、重複予約S4は未定義と整理されることを期待します。実際のCopilot出力は未検証であり、AIが書いた期待結果を実行済み試験の合格記録にはしません。

対応環境・できること・制限事項（公式確認：2026年11月3日）

仕様メモからテスト項目を作るとき、正常な入力だけでは不具合を見つけにくくなります。一方で、書かれていない動作を期待結果として決めてしまうと、テストが新しい仕様を作ることになります。Copilot Chatには、確認できる期待結果と、仕様の確認が必要なケースを分けて出してもらいます。

小さい架空仕様からテスト表を作る

対象は架空の備品予約フォームです。実際の画面へアクセスせず、コードも実行しません。ここで作るのはテスト設計の下書きです。入力値と期待結果を並べ、人が仕様との対応を確認できる形にします。

次の架空仕様だけから、受入テストの候補を作ってください。
列：ID／観点／入力／期待結果／根拠仕様／仕様確認が必要な点。
正常系、境界値、異常系を含めてください。
期待結果が仕様にない場合は「未定義」とし、動作を創作しないでください。
自動テストコードや実行済み結果は出さないでください。

S1：予約人数は整数で、1人以上10人以下。
S2：予約名は必須で、30文字以内。
S3：受付完了後、予約番号を画面表示する。
S4：同じ時間帯で重複予約できるかは未決定。

人数の一人と十人は、許される範囲の端です。ゼロ人と十一人は範囲外です。予約名は三十文字と三十一文字を比べる候補になります。ただし空白だけの入力を必須違反とするか、絵文字を何文字と数えるかは、このメモだけでは決まりません。

境界値は「上限だけ」ではない

境界値は、許される範囲の端と、そのすぐ外を比べる考え方です。人数なら一と十だけでなく、ゼロと十一も確認します。AIが「通常の五人」をたくさん出しても、境界の観点を網羅したことにはなりません。

この表は、エラーメッセージの文言や表示位置までは決めていません。仕様にないためです。「保存ボタンが無効になる」「赤字のメッセージが出る」といった画面動作をAIが付けた場合は、実装の事実ではなく確認候補へ戻します。

条件を一つずつ変えて原因を絞る

人数と名前を同時に不正にすると、どの条件で失敗したか分かりにくくなります。まず、名前を正常な値へ固定して人数だけを変えます。次に人数を正常な値へ固定し、名前の長さだけを変えます。これはケースの数を増やすより、結果を解釈しやすくするための工夫です。

すべての組合せを試す必要があるとは限りません。条件同士の関係がある場合は組合せ確認が必要ですが、独立した入力なら、単独の境界値から始める方法があります。対象のリスクと仕様に合わせて、人が試験範囲を決めます。

「正常に登録できる」という期待も細かく分けます。受付が通ること、予約番号が表示されること、後から予約を参照できることは別です。S3が示しているのは画面表示までであり、メール通知や一覧への反映は書かれていません。

未定義の仕様をテストで確定させない

S4の重複予約は未決定です。AIが「重複ならエラー」と書いたとしても、その期待結果を承認済みテストへ入れません。重複の単位、例外、利用者への案内を確認してから、期待動作を定めます。

未定義の項目を別欄にすると、設計レビューで答えるべき質問が見えます。「同じ時間帯」とは開始時刻の一致なのか、予約期間の重なりなのかも、このメモでは分かりません。曖昧な語を具体的な入力例へ変えると、判断しやすくなります。

長さの仕様も同じです。三十文字を、画面上の見かけ、文字コード上の単位、保存先の制約のどれで数えるかによって境界が変わる可能性があります。ここでは「あ」の反復で基本境界を確認し、複雑な文字の扱いは別の確認事項として残します。

一行変えて、追加すべきケースを調べる

S1の上限だけを十人から十二人へ変え、新しい会話でテスト表を作ります。期待する変化は、十二人を許容し、十三人を範囲外とする境界ケースが出ることです。十人が不正のまま残っていたら、旧条件を引きずっています。

ここではテスト項目を丸ごと作り直すだけでなく、変更の影響を説明させます。「どのIDを変更・追加・削除するか」を出すと、既存ケースとの対応を確認できます。ただしAIが付けたIDは、実際のテスト管理台帳へ自動反映されるわけではありません。

上限の変更によって、予約名の長さや予約番号表示の条件まで変わる理由はありません。無関係な期待結果が書き換わっていないかを見ることも、改訂時の確認に含めます。差分を小さく捉えると、レビューする範囲を明確にできます。

仕様との対応から、漏れと重複を見る

テスト表ができたら、仕様番号ごとに対応するケースをまとめます。S1には人数の境界が複数あり、S3には受付完了後の表示確認が必要です。行数が多くても、S3に対応する項目がなければ、その仕様は確認されません。AIへ番号別の対応一覧を作らせると、見直す範囲を絞れます。

重複も、入力値が同じだけでは判断しません。同じ十人の入力でも、予約番号表示を確認するケースと、人数の上限を確認するケースは目的が違います。まとめて一回の操作で確認できる場合もありますが、期待結果の欄には両方の観点を残す必要があります。

不正入力については、拒否されたことと、既存データが変わっていないことを区別します。後者を試験へ加えるべきかは、保存処理の仕様と影響を確認して決めます。AIが安全策として提案した項目は、承認済み仕様に基づく期待結果とは分けて管理します。

ケースの優先度も自動の点数だけで決めません。誤った人数で予約される影響と、メッセージの表記違いでは重みが異なります。業務上の影響、発生しやすさ、変更箇所との関係を人が確認し、限られた時間でどこを先に試すかを決めます。

実行中に仕様の不足が見つかった場合は、その場で期待結果を書き換えて合格にしません。質問と回答を記録し、仕様とテスト表の両方を同じ合意内容へ更新します。試験を続ける前に、変更が他のケースへ影響しないかも確認します。

テスト設計と実行の記録を分ける

表が作れた段階では、テストは未実行です。実行日、対象版、操作環境、実結果、証跡を記録して初めて、合否を判定できます。AIが「合格」と書いた出力を、そのまま実行記録として扱わないようにします。

実際の入力を試すときは、検証用の環境とダミーの予約名を使います。業務の本番画面へ大量に登録したり、予約を占有したりする試験を、この文章から直ちに行うものではありません。対象環境の利用ルールと後片付けの方法を先に確認します。

仕様書の入力にも注意します。未公開の画面、内部ルール、取引情報を含む場合は、組織が許可した範囲で扱います。架空仕様で表の形を試し、実際の情報を渡す段階で入力先と共有先を確認する順序が実務的です。

評価するのは項目数ではありません。各仕様へ少なくとも一つの確認が対応するか、境界の内側と外側があるか、未定義が合格条件へ紛れ込んでいないかを見ます。候補を増やした後に、人が重複と優先順位を整理します。

受入テストは、実装が仕様を満たすかを確認するためのものです。Copilotが候補を広げる役割を持つ一方、期待結果は合意した仕様に結び付けます。未定義を未定義のまま残せれば、試験表は実行の準備と仕様確認の両方に使えます。

公式情報・一次情報

• Copilot Chatの公式概要

• プロンプトの目的・背景・参照情報・期待する出力

• プロンプトを具体化する公式ガイド

• Copilot Chatのプライバシーと保護

製品の範囲と入力方法は公式資料を参照しています。架空データ、プロンプト、期待例、点検表は本記事の検証案であり、Microsoftが保証する出力例ではありません。