企業が提供するWebサービスや業務システムでは、「通常の利用状況で正常に動作すること」だけを確認していても、十分な品質保証とはいえません。実際の運用環境では、キャンペーン開始直後、テレビやSNSで商品・サービスが紹介された直後、大型セールの開始時刻、チケット販売や予約受付の開始、月末の締め処理などをきっかけに、短時間で通常の数倍から数十倍にまでアクセスや処理件数が増加することがあります。

このようなリスクを事前に確認するために実施されるのが「ストレステスト」です。ストレステストでは、あえて通常時の想定を超える負荷をシステムへ与え、どの程度まで処理できるのか、どの条件で性能が低下するのか、どのコンポーネントが最初にボトルネックになるのか、そして障害発生後に正常な状態へ復旧できるのかを検証します。

1. ストレステストとは

ストレステストを適切に理解するためには、単に「大量のアクセスを発生させるテスト」と捉えるのではなく、その目的と検証範囲を明確にすることが重要です。

システムの性能を確認するテストには、負荷テスト、ストレステスト、スパイクテスト、耐久テストなど複数の種類があります。それぞれ想定する負荷条件や確認するポイントが異なるため、目的に応じて適切なテスト方法を選択する必要があります。

人工知能モデルでは、重み、活性値、勾配、中間計算結果をすべて「数」として保持します。しかし、同じ数値を保存する場合でも、32ビットを使うのか、16ビットを使うのか、8ビットや4ビットまで縮小するのかによって、必要な記憶容量、計算速度、表現可能な数値範囲、丸め誤差、最終的なモデル品質が大きく変わります。そのため数値形式は単なる保存方式ではなく、学習と推論の性能を決める重要な設計要素です。 この点は数値形式を単なる保存型としてではなく、モデルの品質・速度・記憶使用量を同時に左右する設計条件として捉えるうえで重要です。形式名だけを比較するのではなく、どのテンソルとどの演算へ適用されているかまで確認すると、実際の影響を整理しやすくなります。

自律型AIを単純な「質問を入力して回答を返す仕組み」から、複数の手順を実行し、外部ツールを呼び出し、途中で人間の承認を待ち、失敗した処理を再開できるシステムへ発展させると、モデルそのものよりも重要になるのが状態管理です。エージェントは、現在どの作業を行っているのか、何をすでに確認したのか、どのツールを実行したのか、次に何をすべきなのか、利用者からどの権限を与えられているのかを保持できなければ、長い処理を一貫して進められません。

現在のエージェント基盤でも、会話履歴を継続的に保存する仕組み、実行中だけ利用する局所的な文脈、停止した実行を再開するための状態保存などは明確に区別されています。OpenAI Agents SDKでは、局所文脈はプログラムから利用できる実行時情報であり、そのまま言語モデルへ送られる情報とは別に扱われます。またセッションは複数回のエージェント実行をまたいで会話履歴を保持する永続的な記憶層として提供されています。

AIシステムの性能を評価するとき、「一回の推論が何ミリ秒で終わるか」だけを見ていると、本番で必要となる処理能力を正しく判断できないことがあります。利用者が一人しかいない試験環境では100ミリ秒で応答できても、100人が同時に利用した瞬間に処理待ちが発生し、全体として一秒あたり数件しか処理できないのであれば、大規模サービスとして十分な性能を持っているとはいえません。そこで重要になるのが、一定時間内にどれだけの仕事を完了できるかを表すスループット、すなわち単位時間処理量です。

単位時間処理量は、システムによって測定単位が異なります。画像分類なら一秒あたり画像枚数、文章生成サービスなら一秒あたり要求数、大規模言語モデルでは一秒あたり生成トークン数や一秒あたり利用者要求数などが利用されます。また、同じモデルでも一度に一件だけ処理する場合と、複数件をまとめて処理する場合では処理量が大きく変わります。単純にモデルの計算速度だけを見るのではなく、同時実行、バッチ処理、GPU利用率、入力長、出力長、処理待ち列などを含めて評価する必要があります。

AIエージェントを試作するときは、ユーザーの指示をLLMへ送り、モデルが返したツール名を実行し、その結果をもう一度モデルへ渡すだけでも十分に動作する場合があります。数十行のコードで検索、メール作成、データ取得などを組み合わせれば、従来のチャットボットより自律性の高い体験を短期間で実現できます。しかし、この仕組みを実際の顧客業務や社内オペレーションへ投入すると、モデル性能とは別の問題が急速に増えます。ツール呼び出しが途中で失敗したらどこから再開するのか、同じ支払処理を二回実行しないためにどうするのか、長時間タスクの状態をどこへ保存するのか、ユーザーAの権限をユーザーBのエージェントが誤って使わないようどう隔離するのかといった問題です。こうした「エージェントを継続的かつ安全に実行するための仕組み」を受け持つのがエージェントランタイムです。

長期間運用されているデジタル製品では、最初から意図的に不統一な画面を作っているわけではなくても、機能追加、組織変更、納期優先の改修、ブランド刷新、担当者交代、技術移行などが積み重なることで、少しずつデザイン上の不整合が生まれます。同じ役割のボタンなのに高さが違う、似た意味の色が複数登録されている、設定画面だけ古いナビゲーションを使っている、あるフォームではエラー表示が丁寧なのに別のフォームでは技術的な文言しか表示されない、といった小さな差異が代表例です。一つひとつは致命的な問題に見えなくても、製品全体へ広がるとユーザーの学習負担が増え、チーム側では修正箇所や判断基準が増えるため、開発速度と品質の両方を下げる原因になります。

デザイン負債監査では、こうした問題を感覚的に「古い」「統一されていない」と指摘するだけではなく、どこに、どの種類の問題が、どれだけ存在し、何を原因として発生しているのかを体系的に確認します。画面の見た目だけではなく、コンポーネント、デザイントークン、文言、ナビゲーション、情報構造、アクセシビリティ、デザインファイル、実装コード、ドキュメント、レビュー方法まで対象にすることで、表面的な症状だけではなく、負債を生み続けている構造そのものを見つけることができます。

Webサイトやアプリを利用する人は、年齢、身体能力、視力、聴力、認知特性、利用している端末、入力方法、通信環境、利用場所などがそれぞれ異なります。同じ画面を見ていても、マウスで操作する人、キーボードだけで操作する人、画面読み上げソフトを利用する人、拡大表示を利用する人では、必要となる設計上の配慮が変わります。

ユニバーサルデザインシステムは、こうした違いを例外として後から処理するのではなく、最初から多様な利用条件を想定してUI、コンテンツ、コンポーネント、実装ルールを構築する考え方です。一部の画面だけを使いやすくするのではなく、製品全体で一貫した利用しやすさを再現できる状態を目指します。

特に複数のデザイナーや開発者が参加するサービスでは、個人の知識や善意だけに依存すると品質にばらつきが生まれます。そこで重要になるのが、利用しやすさを設計資産として体系化し、繰り返し利用できるデザインシステムへ組み込むことです。

1. 誰もが利用できる体験を設計の出発点にする

ユニバーサルデザインシステムを構築するとき、最初に考えるべきなのは特定の画面やボタンではありません。利用者が置かれるさまざまな条件を想定し、その条件が変化しても主要な操作を完了できる設計にすることが重要です。

ウェブサイトやアプリケーションが一般的なマウス操作で利用できても、すべての利用者が同じように目的を達成できるとは限りません。キーボードだけではメニューを開けない、読み上げソフトでは入力欄の目的が分からない、文字を拡大すると申込みボタンが画面外へ隠れる、色の違いだけでエラーを示しているといった問題があれば、一部の利用者は情報を理解できず、手続を完了できません。画面の一部が読みにくいという軽微な問題に見えても、ログイン、購入、予約、申請などの主要経路を完全に遮断する場合があります。

アクセシビリティ監査とは、ウェブサイト、アプリケーション、文書などが、多様な身体・感覚・認知・操作条件を持つ利用者にとって、知覚可能、操作可能、理解可能であり、支援技術を含む環境で堅牢に動作するかを評価する活動です。WCAG 2.2は、これら四つの原則の下に達成基準を整理したウェブアクセシビリティの国際的な技術標準です。WCAG 2.2は2023年10月5日にW3C勧告として公開され、フォーカスが隠れないこと、ドラッグ操作の代替、操作対象の大きさ、認証支援などに関する達成基準が追加されました。

ウェブアプリケーションを開いた直後は軽快に動作するのに、一覧と詳細を何度も往復する、モーダルを繰り返し開閉する、検索条件を変更する、画像を切り替えると、少しずつ画面が重くなることがあります。スクロールが引っ掛かり、文字入力が遅れ、ファンが回り始め、最終的にはタブが応答しなくなる場合もあります。このような問題は、一回の操作確認や短時間の性能計測では見つけにくく、長時間利用される業務システム、管理画面、チャット、地図、動画編集、画像処理などで深刻になりやすい特徴があります。

JavaScriptは、作成されたオブジェクトが不要になれば、ガベージコレクションによって自動的にメモリを回収します。しかし、自動管理だから開発者がメモリを意識しなくてよいわけではありません。不要になった画面やデータへ、イベントリスナー、タイマー、グローバル変数、購読処理、閉じたウィンドウなどから参照が残っていれば、ブラウザーはそのオブジェクトが今後も使われる可能性があると判断し、回収できません。MDNも、JavaScriptの自動的なメモリ管理は、開発者がメモリ管理を考慮しなくてもよいという誤解を生みやすいと説明しています。