テストが先か、推論が先か: Webアプリを強くするのは『正しさを閉じ込める設計』だった

まず、怖い問いから始めよう

ブラウザで機械学習モデルを動かせたら、それだけで未来っぽい。画像を選ぶと即座に判定が返り、サーバーに投げずにローカルで推論できる。体験としては鮮やかだし、技術的にも気持ちがいい。

でも、ここで不安になるべき問いがある。そのモデルは、本当に動いていると言えるのか。 たまたま手元の画像で当たっただけではないのか。入力の形が少し変わったら壊れないのか。UIは反応しているのに、中身は静かに間違っていないか。

ここで見えてくるのは、テストと推論は別々の話ではないという事実だ。ひとつは Web アプリの正しさを確かめる技術、もうひとつは機械学習モデルをブラウザで走らせる技術。一見すると片方は品質保証、もう片方は実行環境の工夫に見える。しかし実際には、「正しさをどこに閉じ込めるか」 という同じ問題を別の角度から扱っている。

本当に難しいのは、動かすことではない。壊れ方を制御することだ。

---

Webアプリ開発の本当の敵は、コードではなく境界である

多くの人は、アプリが壊れる原因を「バグ」と呼ぶ。だが実際には、バグの多くは境界から生まれる。HTTP リクエストが来る境界。画像がアップロードされる境界。Tensor の形が変わる境界。ブラウザと推論エンジンが接続される境界。

テストが役に立つのは、コードの中身を全部理解できるからではない。境界で何が入ってきて、何が出ていくべきかを固定できるからだ。たとえば API のテストでは、入力に対して期待するステータスコードや JSON の形を確認する。これは単なる確認作業ではない。システムの振る舞いを「契約」として定義する行為だ。

一方で、ブラウザ内推論はその契約をさらに厳しくする。サーバーに逃げられないからだ。サーバーが受け持っていた前処理や推論を、React アプリの中で完結させると、UI、画像読み込み、モデルのロード、推論結果の表示が一つの連続した体験になる。便利だが、そのぶん失敗も見えやすい。モデルが重ければ画面が固まる。画像の前処理がずれれば精度が落ちる。推論の成功が、必ずしもユーザー体験の成功を意味しない。

ここで重要なのは、正しさは計算結果だけでは測れないということだ。正しい API 応答が返ることと、正しく見える UI が表示されることと、正しく速く推論が終わることは、同じではない。にもかかわらず現場では、これらをひとまとめにして「動いた」と言ってしまう。

速く動くシステムは、必ずしも強いシステムではない。強いシステムとは、壊れ方が予測できるシステムである。

この視点で見ると、テストとブラウザ推論は対立しない。むしろ補完し合う。テストは境界を固定し、ブラウザ推論は境界を増やす。その増えた境界を、どう設計し、どう検証するかが本当の設計課題になる。

---

ブラウザで推論することは、機械学習を UI の問題に変えることでもある

機械学習の話はしばしば精度で語られる。正解率が何パーセントか、F1 がいくつか、推論時間が何ミリ秒か。しかしブラウザで動かす瞬間、その議論は一段階変質する。モデルはもはや研究成果ではなく、インタラクションの一部になる。

たとえば、ユーザーが画像をドラッグして認識させる場面を想像してほしい。サーバー推論なら、多少の待ち時間は「通信中」で済まされる。だがブラウザ推論では、ロード時間も、初回のバッファリングも、処理中のスピナーも、すべて体験の一部だ。モデルの精度が高くても、初回ロードが重すぎればユーザーは離脱する。逆に、多少精度が低くても、即応性が高ければ「使える」と感じることもある。

つまり、ブラウザ推論はモデルを製品の文脈に引き戻す。ML は魔法ではなく、UI の制約条件を含んだシステム部品になる。ここで考えるべきなのは、モデルの正しさをどう測るかではなく、いつ、どこで、誰にとって正しいかだ。

これをテストの言葉に翻訳すると、期待値を一つに固定しないということになる。API テストではレスポンスの構造を確認する。UI テストでは画面の状態を確認する。推論テストでは予測ラベルだけではなく、入力の前処理、出力のスコア分布、ロード失敗時のフォールバックも確認する必要がある。ブラウザ推論は、この多層の期待値を同時に意識させる。

このとき役に立つのが、「モデルを検査する」から「体験を検査する」へ発想を変えることだ。たとえば画像認識アプリなら、次のような問いを並べる。

• 画像を選んだ瞬間に UI は反応するか
• モデルは毎回再ロードされずに再利用されるか
• 推論中にユーザーは何を見ているか
• 推論結果が外れたとき、ユーザーはどう修正できるか
• ネットワークが不安定でも最低限の動作は保てるか

これらは、純粋な ML 研究の問いではない。だがプロダクトとしては、こちらのほうが重要なことが多い。

---

いちばん価値があるのは「速く作ること」ではなく「壊れない境界を作ること」

開発の現場では、しばしば速度が正義になる。早く実装し、早く動かし、早く見せる。しかし速度だけを追うと、たいてい最後に困るのは境界だ。入力が増えたとき、モデルが差し替わったとき、UI が改修されたとき、突然システム全体が不安定になる。

ここで効くのが、境界を契約として扱う設計である。テストはその契約を守る仕組みであり、ブラウザ推論はその契約をユーザーの手元まで運ぶ仕組みだ。つまり両者を合わせると、「内部実装の自由度」と「外部から見える一貫性」を両立しやすくなる。

具体例を挙げよう。画像認識アプリを React で作るとする。もし推論ロジックがサーバー専用なら、UI は API の返答形式に依存する。API の変更は UI の変更を連鎖的に生みやすい。だがブラウザ内推論にすると、フロントエンドはモデルの出力形式を自分で受け持つことになる。これは面倒にも見えるが、依存が見える化されるという利点がある。どの部分が壊れたかを切り分けやすいし、テストも細かく書ける。

この構造を理解するための比喩として、電気配線を思い浮かべるといい。雑に延長コードをつなぐと、どこで断線しても全体が止まる。だが配電盤のように回路を分けておけば、異常が起きても影響範囲を限定できる。テストとは、回路ごとのブレーカーを用意することだ。ブラウザ推論とは、その回路をユーザーの目の前に持ってきて、見える化することだ。

強い開発とは、何でも自動化することではない。何を信じてよくて、何を毎回確かめるべきかを分離することだ。

この分離ができると、機械学習の導入は急に現実的になる。大げさな MLOps を最初から組まなくても、まずは入力、前処理、推論結果、表示の境界を決める。そしてその境界をテストで守る。そうすると、モデルを変えても UI の信頼性が落ちにくい。

---

実践のための考え方: 三層の正しさを設計する

ここまでの話を、すぐ使える形に落とし込もう。ポイントは、正しさを一枚岩として扱わず、三層に分けることだ。

1. 構造の正しさ

入力と出力の形が期待通りか。HTTP のステータス、JSON のキー、画像テンソルの形、モデル出力のラベル数など、まずは構造を確かめる。これは最も低コストで、最も重要なテストだ。

2. 振る舞いの正しさ

与えた入力に対して、システムが妥当な反応をするか。ボタンを押したらローディングが出る。画像を変えたら予測が変わる。異常入力ならエラーを返す。振る舞いは、ユーザー体験に直結する。

3. 体験の正しさ

速さ、待ち時間、再試行、失敗時の回復など、ユーザーが実際に感じる正しさ。ブラウザ推論ではここが極めて重要になる。モデルのスコアが高くても、体験が悪ければ価値は落ちる。

この三層を分けると、テストの目的が鮮明になる。構造は自動で守る。振る舞いは境界で確認する。体験は実際の画面遷移で確かめる。ここで大事なのは、全部を同じ粒度で検証しようとしないことだ。重いことを毎回やろうとすると、テストはすぐに嫌われる。

また、ブラウザ推論を採用するなら、モデルの良し悪しを精度だけでなく、次のような指標でも見るべきだ。

• 初回ロード時間
• 推論開始までの遅延
• 画像サイズの違いによる安定性
• 失敗時のリカバリのしやすさ
• 画面上での説明可能性

これらは ML の指標というより、プロダクトの信頼性指標だ。だが、最終的にユーザーが買うのは精度そのものではなく、信頼できる体験である。

---

Key Takeaways

• 正しさは結果ではなく境界に宿る。 入力、出力、前処理、表示の境界を明確にするだけで、システムはずっと扱いやすくなる。
• ブラウザ推論は ML を UI の問題に変える。 精度だけでなく、待ち時間や失敗時の挙動まで設計対象に入れる必要がある。
• テストは「壊れないこと」を保証するのではなく、「どう壊れるか」を予測可能にする。 その視点があると、テストの優先順位がはっきりする。
• モデルの正しさと体験の正しさは別物。 画像認識が当たることと、ユーザーが使いやすいことは一致しない。
• 三層で考えると実装が楽になる。 構造、振る舞い、体験を分けて設計すると、テストと推論の両立がしやすい。

---

結論: 未来的なアプリを作る鍵は、未来的な技術ではない

ブラウザで機械学習を動かすと、私たちはつい「すごいものを作った」と感じる。だが本当に価値があるのは、そこにある技術の派手さではない。どこまでを確実にし、どこからを不確実として扱うかを設計できることだ。

テストはその線引きを固定する。ブラウザ推論は、その線引きをユーザーの目の前で成立させる。両者が合流すると、開発は単なる実装作業ではなく、信頼の設計になる。

そしてそのとき、もっとも重要な問いは「動くか」ではなくなる。代わりに問うべきなのは、このシステムは、どこが壊れても意味が残るかである。

その問いに答えられる設計だけが、本当に長く使われる。