INSIGHT

人数だけでは分からない——AIで作ったシステムの忙しい時間を試す

ACTION|次の確認へ AI / リスクと対策

忙しい時間に、何件の仕事が完了し、失敗すると何が残るか。

部門内の試用では、担当者一人が問題なく登録できた。次は全営業所へ広げたい。しかし、月曜の朝、締切の直前、在庫を確保する瞬間に操作が集中しても、必要な仕事を時間内に終えられるかは、一人の成功から判断できません。

利用を広げる前に、人数ではなく、仕事が集中する時間と操作を再現します。

「100人」より「月曜9時の15分」を伝える

負荷試験の条件は、利用者数だけでは足りません。現場から、仕事が混む短い時間を一つ選びます。

たとえば「月曜9時から15分間に、各営業所が前週分の注文を検索し、50人が在庫を確認し、20人が添付付きの登録を確定する」。これは試験条件の書き方を示す仮の例で、推奨人数ではありません。ここまで書くと、同時に起きる検索、保存、ファイル処理、外部連携、AIへの呼び出しを分けられます。

業務側は、締切、待てる時間、時間切れになった依頼の扱いを決めます。技術側は、同時利用者、処理件数、データ量、呼び出し回数、依存先の制限を試験条件へ変えます。「全社で500人」より、いつ何が重なるかの方が実際の負荷に近い情報です。

AWS Well-ArchitectedのLoad test your workload は、本番に近い環境と想定利用量で負荷を生成し、応答時間や処理量などを事前に定めた目標と比較することを勧めています。試験データは合成または機微情報を除いたものにするとも説明しています。AIで作ったシステム専用の性能調査ではなく、自社に必要な人数や秒数を示す資料でもありません。

速さだけでなく、終わった仕事の数を測る

画面が表示されるまでの平均時間だけを見ると、遅い一部の依頼や、途中で失敗した仕事が隠れます。測る項目を、利用者の体験と業務結果に分けます。

利用者の体験では、応答時間、時間切れ、再操作の回数、待機中の表示を見ます。業務結果では、受付件数、完了件数、失敗・保留件数、締切時点の未処理、後から手直しした件数を見ます。平均だけでなく、遅かった依頼がどのくらいあり、どの操作に集中したかを残します。

外部サービスの呼び出し上限や待ち時間も、システム全体の条件です。自社の画面だけ速くても、外部連携の結果を待つ仕事が終わらなければ、業務目標は満たしません。部品ごとの数値ではなく、一件の業務が締切までに終わるかを最後に確認します。

「画面が落ちなかった」ではなく、締切までに正しい状態で完了した件数を合格の根拠にします。

同じ対象を同時に変える条件は、別枠で試す

混雑時には、二人が同じ在庫、予約、申請を同時に更新することがあります。速さの試験に混ぜるだけでは、どちらの変更が残ったかを見落とします。

一人目が開いた後に二人目が更新する。同じ残数へ同時に確定する。時間切れになった利用者がもう一度押す。こうした条件で、古い内容が上書きされないか、二重登録にならないか、再確認が必要だと利用者へ伝わるかを見ます。

具体的な制御方法は、対象システムと業務で選びます。ここでは、同時更新の詳しい設計を一律に定めません。負荷を上げても、結果の整合、利用者への表示、記録、再処理が保たれることを受入条件に加えます。

失敗時に現場へ何が残るかを見る

試験では、外部連携が遅い、AIへの呼び出しが時間切れになる、処理待ちが増える条件も入れます。目的は障害を演出することではなく、忙しい時間に未完了を見つけられるかを確かめることです。

負荷をかける前に、技術担当と試験先、許可された量、費用の上限、停止する担当を決めます。外部サービスの本番窓口へ大量の試験依頼を送らず、提供元が認める環境や模擬した応答を使います。模擬した箇所は報告に残し、その結果だけで実際の外部サービスの処理能力まで確認済みにしません。

利用者が同じ操作を繰り返すと、処理量と重複がさらに増えます。画面には、受付済み、処理中、完了、保留を区別して示します。時間切れの依頼を誰が探し、手作業へ引き継ぐか、利用者へ何を案内するかも試します。

性能が目標へ届かなければ、全社展開を失敗と決める必要はありません。利用時間を分ける、予約処理にする、添付の大きい仕事を分ける、利用部門を限定する、改善後に再試験する、といった選択があります。技術担当は測定結果を示し、現場は待てる時間と代替方法を選びます。

試験した環境・量・時間を添え、未確認の条件も共有する

自分のアプリがいつ、どの操作で混むかを技術担当へ伝え、許可された試験の結果を一緒に確認します。報告には最大人数だけでなく、次を残します。自分で負荷をかけられない場合も、再現してほしい仕事と待てる時間は具体化できます。

  • 再現した時間帯、操作、件数、データ量、外部連携
  • 業務が待てる時間と締切
  • 応答、完了、失敗、未処理、手直しの測定結果
  • 同時更新と再操作の結果
  • 利用できる範囲、未試験条件、改善後の再試験日

利用者、業務責任者、技術担当が同じ一枚を見て、「この時間帯と業務なら広げる」「添付処理は限定する」「締切前は手作業を残す」と合意します。利用者数、ファイルの大きさ、外部連携、処理内容が変われば、過去の合格をそのまま使わず条件を見直します。

負荷試験は設備の点数表ではなく、現場へ約束できる利用範囲を決める材料です。

忙しい15分の操作を試し、一件の完了と未処理まで測る

忙しい時間に使えるかは、登録した利用者の総数では決まりません。短い時間にどの操作が重なり、一件の仕事がいつまでに終わる必要があるかで決まります。

まず、自分が知る忙しい時間を一つ選び、重なる操作と締切を書いてみてください。技術担当と試験先・量・費用・停止条件を決め、完了と未処理まで見ます。試せなかった条件も添えて、利用拡大を判断する人へ結果を渡します。

参考資料