作ったシステムの動作確認は、「画面が動いた」ではなく「業務で使える」ことを確かめる作業です。そのために、機能ごとに正常系・異常系・境界・業務シナリオの4つの観点で確かめ、改修したときは触ったコードではなくデータが流れていく先まで確認します。この記事では、テストの専門家でなくても自分で動作確認を終えられる手順を、具体例と一緒に説明します。
「動いた」と「使える」の違い
生成AIを使ってコードを書く機会が増え、画面ができあがるまでの時間はかなり短くなりました。一方で、画面が表示されてボタンが押せることと、現場の業務で毎日使えることの間には距離があります。
業務で使える状態とは、想定される入力すべてで正しい結果が返り、誤った入力をしたときにも納得できる動きをする状態です。たとえば予約フォームが1件目の登録で正しく動いても、定員を超えたとき、日付を空欄にしたとき、同じ人が二重に申し込んだときの動きを確かめていなければ、使えるとは言えません。動作確認は、この差を埋める作業です。
確認すべき4つの観点
1つの機能に対して、次の4つの観点で確かめます。
| 観点 | 確かめること | 予約フォームでの例 |
|---|---|---|
| 正常系 | 期待どおりの入力で期待どおりの結果が出るか | 空きのある日時で予約し、確認メールが届く |
| 異常系 | 空欄、不正な値、想定外のデータを入れたときの動き | 電話番号に文字を入れる、過去の日付を選ぶ |
| 境界 | 0件、1件、上限ちょうど、大量データなど量の極端な場合 | 定員ちょうどの予約、定員を1人超える予約 |
| 業務シナリオ | 1日の業務の流れを通しで使ったとき | 予約→変更→キャンセル→再予約を続けて行う |
正常系だけで終わらせると、本番で利用者が最初に踏むのは異常系と境界です。とくに上限ちょうどと1つ超えの組み合わせは、条件式の < と <= の取り違えが出やすいところです。
動作確認の手順
| ステップ | やること | できあがるもの |
|---|---|---|
| 1. 洗い出し | 想定する入力と操作のパターンを列挙する | 確認項目の一覧 |
| 2. データの用意 | 正常系と異常系のテストデータを作る | テストデータ一式 |
| 3. 実行 | 1項目ずつ実行し、結果を記録する | 実行記録 |
| 4. 判定 | 業務として問題ないかを判定する | 合否の一覧と修正リスト |
洗い出しとテストデータの用意は、生成AIに叩き台を作らせると速く進みます。「この機能で確認すべき異常系の入力を10個挙げて」「境界値のテストデータを作って」と頼み、出てきたものを現場の感覚で取捨選択します。ただし、判定は自分で行います。業務として正しいかどうかを決めるのは、業務を理解している人です。
改修したときは「データの流れの先」を見る
新しく作った機能より、既存のシステムを改修したときのほうが事故は起きやすくなります。改修した画面だけを確認して、別の画面や帳票で問題が出るためです。影響の範囲はコードの場所ではなく、データの流れで決まります。
テーブル×処理のマトリクスを作る
縦にテーブル、横にAPIやバッチ、CSV出力などの処理を並べ、それぞれの処理がそのテーブルに何をするか（作成C、参照R、更新U、削除D）を書き込みます。
| テーブル | 予約登録API | 予約詳細API | 料金計算 | 日次売上バッチ | 会計CSV出力 |
|---|---|---|---|---|---|
| reservations | C | R | R | R | R |
| members | R | R | R | ー | ー |
| payments | ー | R | C | R | R |
あるテーブルを変更したら、その行にあるすべての処理が確認の対象です。Rが多い行ほど影響は広くなります。Cが複数の処理にあるテーブルは書き手が複数いるので、データの整合性が崩れやすい点にも注意します。
値がコピーされる先をたどる
業務の流れの中で、ある値が別のテーブルにコピーされることがあります。たとえば予約時の料金が、決済のテーブルにコピーされ、そこから日次の売上集計と会計システム向けのCSVに出ていく、という流れです。
reservations.price
└→ payments.charged_amount （決済時にコピー）
├→ daily_sales （日次バッチで集計）
└→ accounting.csv （会計システムへ出力）
料金の計算方法を変えたら、コピー先のテーブルと、そこから先の集計や帳票まで確認が要ります。コピー先でさらに別のテーブルに流れているなら、同じ確認を繰り返します。
業務フローから確認項目を出す5つの問い
改修したテーブルについて、業務フロー図を見ながら次の5つに答えると、確認すべき項目の大半が出てきます。
- 誰がこのテーブルにデータを入れるか
- 誰がこのテーブルを見るか
- このテーブルの値は、次にどのテーブルへコピーされるか
- このテーブルの値は、どの帳票、CSV、外部システムに出ていくか
- 過去のデータと新しいデータで、動きが変わってはいけないものは何か
例題：会員割引を追加する
会員向けの施設予約システムに「会員ランクに応じた割引」を追加するとします。変更するのは料金計算の処理と、会員テーブルへの discount_rate 列の追加です。
先ほどのマトリクスとコピーの流れから、確認項目を作ると次のようになります。
| # | 確認項目 | 影響度 | 確認方法 |
|---|---|---|---|
| 1 | 割引後の料金が予約画面と決済で一致する | 致命 | ランク別の会員で予約し、決済額を照合 |
| 2 | 割引率が未設定（NULL）の既存会員でも料金計算が落ちない | 致命 | 既存データのまま予約する |
| 3 | 日次売上の合計が、決済額の合計と一致する | 高 | テスト日の決済を合計して比べる |
| 4 | 会計CSVの金額が割引後の値になっている | 高 | CSVを出力して行ごとに照合 |
| 5 | 改修前の予約の料金が変わっていない | 致命 | 過去の予約詳細を開いて比べる |
| 6 | 予約一覧の金額表示が崩れない | 中 | 一覧画面で確認 |
2番と5番は、改修した画面だけを見ていると見落としやすい項目です。新しく追加した列は既存のデータでは空になっていることが多く、過去のデータを計算し直してしまう実装もありえます。影響度が「致命」のものは、確認の手順と結果をスクリーンショットやログで残しておきます。
AIが出した集計を検算する
動作確認の対象はシステムの動きだけではありません。生成AIに集計やレポートを作らせた場合、その数字も確かめる必要があります。検算では次の3つを行います。
- 別の方法でもう一度出す。件数で出した割合を金額でも出す、単純平均を「総額÷総数量」の加重平均でも出す。同じ計算をなぞると同じ誤りが再現するだけなので、必ず違う角度から出します
- 内訳の合計が総計と合うか確かめる。地域別や商品別の内訳を足して、総計と一致しなければ、漏れか二重計上があります
- 桁、単位、母数を確かめる。割合の母数は件数か金額か、単位は円か千円か、返品のようなマイナスの行が混ざっていないかを見ます
AIの集計で起きやすい誤りは、母数の取り違え（件数の割合を金額の割合として書く）、単純平均と加重平均の混同、返品などの区分の扱い間違いです。
デモと運用初期で気をつけること
- エラーを画面で見えるようにする。例外を黙って握りつぶしたり、失敗したのに「完了しました」と表示したりすると、データだけが静かに壊れていきます。少なくとも試験運用の間は、エラーの内容と、どの操作で起きたかを画面で確認できるようにし、あわせてログにも残します
- テスト用の値を自動で入れる。入力項目の多いフォームを毎回手で埋めていると、確認の回数が減ります。テスト環境ではテスト値を自動で入れ、固定値だけでなくランダムな値も使うと、想定していなかった入力を自然に踏めます。ランダムな値で落ちるなら、入力チェックが足りていません
- 正常に動いている様子を録画しておく。顧客の前でのデモは、通信や環境の違いで失敗することがあります。最新の状態で主要な操作を録画しておけば、ライブが失敗しても説明を続けられます
よくある失敗
- 自分が触った画面だけ確かめる。同じテーブルを読んでいる別の画面、バッチ、帳票で問題が出ます。マトリクスで参照している処理を全部洗い出します
- 手元で動いたので本番も大丈夫と考える。本番には空の値、古い形式のデータ、大量のデータがあります。本番に近いデータで確かめます
- ステータスの値を1つ追加しただけと考える。ステータスを条件にしているSQLが、新しい値を取りこぼしていないかを全件確認します
- 確認結果を記録しない。何をどう確かめたかが残っていないと、同じ不具合が再発したときに原因を追えません
- リリースしたら終わりにする。月次の集計や、月をまたいだ過去データの参照は、リリース直後には動きません。致命・高の項目はリリース後しばらく見直します
この記事のまとめ
- 動作確認は「動いた」ではなく「業務で使える」ことを確かめる作業
- 機能ごとに正常系・異常系・境界・業務シナリオの4観点で確かめる
- 改修したときは、テーブル×処理のマトリクスと値のコピー先から影響範囲を洗い出す
- 新しい列が空の既存データと、過去データが変わっていないことは必ず確かめる
- AIの集計は、別の方法での再計算、内訳と総計の照合、桁・単位・母数の確認で検算する
動作確認はロードマップのステップ6「進めて作る」で扱う技術です。確認の起点になるテーブルと状態の設計はステータス設計とテーブル分割、AIをどの処理に使うかは業務AI化のアルゴリズムの選び方で扱っています。手順とチェックリストの全体はFDEガイドの「動作確認入門」にあり、スライド・演習問題・テストは lecture.iplot.jp で取り組めます。