0. はじめに
あなたのサービスで、「使いにくい」と問い合わせをくれたユーザーは何人いるでしょうか.
では、使いにくいと感じたまま、何も言わずに離れたユーザーは何人いるでしょうか。
後者は、開発側からは見えません。
だから私たちは、ユーザーが見つける前に、AIが先に実際のブラウザで使ってみるQAエージェント「MiruQA」 を作りました。
URLを渡すと、MiruQAがテスト項目を組み立て、ブラウザを操作し、項目書にない画面まで探索します。
連打・手順スキップ・異常入力など、人が事前に書き切りにくい操作も、許可された環境では実際に試します。
ただし、AIにすべてを任せるわけではありません。
何を試すかはAIに広く任せる一方、何をしてよいかはコードと人が決め、AIの「それっぽい感想」だけでは確定バグにしません。
本記事は、AI HACK 2026 への応募作品「MiruQA」の設計・実装・検証記録です。
主催者から提示された評価軸（セキュリティ／コストパフォーマンス／信頼性・堅牢性／自律性／アイデア独創性）に対して、何を実装し、何を実測したのかをまとめます。
- 紹介ページ:
- 詳細仕様:
1. なぜ作ったのか ── コードを書く速度だけが上がっている
私は2026年4月まで、自社サービスの運用と開発を担当していました。
週1回のリリースのたびにバグ対応が2件以上入り、リリース前後の手動テストにも時間を使います。本来進めたい機能開発やUI改善より、差し込みの確認や調査を優先しなければならないことがありました。
そして厄介なのは、問い合わせが来る障害だけではありません。
重大な問題なら、ユーザーが問い合わせをしてくれることがあります。
一方で、「少し使いにくい」「なぜかうまく進めない」「もう一度試すほどではない」といった問題は、必ずしも報告されません。
ユーザーが報告してくれるのを待つのではなく、リリース前にこちらから実際に使いにいく。
これがMiruQAの出発点です。
AIコードで増えやすいのは、「見た目では分かりにくい」欠陥だった
CodeRabbitが分析した、470件のオープンソースGitHub PR（AI共著320件、人間のみ150件）において
AI共著PRでは、全体の問題数が約1.7倍だっただけでなく、特に次の傾向が報告されています。
| 欠陥傾向 | AI共著PRでの増加 |
|---|---|
| ロジック・正しさの問題 | +75% |
| エラーハンドリング・例外経路の欠落 | 約2倍 |
| 並行処理・依存関係の不足 | 約2倍 |
| セキュリティ問題 | 最大2.74倍 |
ここで重要なのは、単なるフォーマットミスではなく、ビジネスロジック、制御フロー、例外経路、処理順序のような欠陥が増えていることです。
CodeRabbit自身も、こうした問題はレビュー時にエッジケースを頭の中で追わなければ見つけにくい、と説明しています。
▸ CodeRabbit「State of AI vs Human Code Generation Report」
https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report
▸ CodeRabbit「コードを読む人は、もういなくなる」
https://www.coderabbit.ai/ja/blog/nobody-is-going-to-read-the-code
この調査自体は、UIテストの有効性を直接検証したものではありません。
ただし、ロジック・例外経路・並行処理の問題は、コード上で存在していても、正常系だけを通している間は表面化せず、ユーザーが実際の画面で複数の操作を組み合わせたときに初めて顕在化することがあります。
Playwrightも、テストでは実装詳細ではなく、ユーザーが実際に見て操作する振る舞いを検証することを推奨しています。
▸ Playwright Best Practices
https://playwright.dev/docs/best-practices
▸ IBM「What is End-to-End Testing?」
https://www.ibm.com/think/topics/end-to-end-testing
つまり、AIがコードを書く能力が上がっても、
ユーザーと同じ入口から、実際にUIを操作して確かめるテストはなくならない。
問題は、それを人間が毎回すべて設計・実行し続けられるかです。
2. MiruQAが解く課題 ── 人が想定したテストだけでは、組み合わせを拾い切れない
Webアプリでは、画面、入力値、ユーザー状態、戻る・再読込、複数回操作などの組み合わせによって、確認すべき状態が急速に増えます。
たとえばカート画面だけでも、
- 数量を変更 → ブラウザバック → 再度進む
- クーポン適用 → 再読込
- 決済処理中 → もう一度ボタンを押す
- 手順途中のURLへ直接アクセスする
といった組み合わせがあります。
実務の時間とコストの中で、これらを人間がすべてテストケース化するのは現実的ではありません。
MiruQAが目指すのは、既存のQAを置き換えることではなく、
「実際に操作して初めて見える挙動」を、AIに探索させる層を追加すること
です。
3. 作ったもの ── URLから、項目作成・実行・探索・報告まで
MiruQAでは、利用者が最初に点検対象のURLを登録します。
仕様書（txt / md / docx / PDF）は任意です。
仕様書がある場合は、期待結果や仕様カバレッジの根拠として利用します。
実行の詳細な流れ（1回の点検）
MiruQAにおける1回の点検は次の流れです。
| # | 処理 | AI / Code | 主な出力 |
|---|---|---|---|
| 1 | 対象登録 | Code | URL、環境種別、任意の仕様書を登録 |
| 2 | 事前チェック | Code | 対象環境・所有確認・許可範囲を確認 |
| 3 | 下見 | Playwright | リンクを辿り、画面一覧・サイトマップを作る |
| 4 | 仕様書の分解 | AI | 仕様書があれば SPEC-xxx 単位に分解 |
| 5 | テスト項目生成 | AI＋Code | 仕様・画面・観点から前提／手順／期待結果を作る。定型の能動テストはCodeで追加 |
| 6 | 計画承認 | Human | 実施項目を確認し、危険操作を含む項目を承認 |
| 7 | 項目実行 | AI＋Playwright | AIが次の操作を選び、Playwrightがクリック・入力・移動を実行 |
| 8 | Policy Gate | Code | 各操作の直前に、ドメイン・環境・承認・回数上限を確認 |
| 9 | 観測・判定 | Code中心 | DOM / Network / テスト環境の状態から結果を判定 |
| 10 | 探索的テスト | AI＋Playwright | 項目書にない画面・操作を追加探索 |
| 11 | 集約 | Code | 重複不具合の統合、仕様カバレッジ、コスト集計 |
| 12 | レポート | Code | 合否、不具合票、スクリーンショット、再現手順、CSV / HTMLを出力 |
ポイントは、AIが直接ブラウザを好き勝手に操作するわけではないことです。
AIが「次に何をするか」を選び、実際の操作はPlaywrightが行います。ユーザーには「実行してよい操作か」を確認します。
（テスト項目生成、計画承認画面）
4. AIはここだけ ── 「全部AI」にしなかった
全部をAIに任せると、遅く、高く、そして判定が不安定になります。
そこで、処理ごとに役割を分けました。
| 仕事 | 担当 |
|---|---|
| リンクを辿る・画面一覧を作る | Playwright |
| 連打・直接アクセス等の定型操作 | Code / Playwright |
| 許可ドメイン・回数上限・承認判定 | Policy Gate |
| 定型の能動テスト項目を作る | Code |
| 仕様書を項目化する | LLM |
| テスト項目を生成する | LLM |
| 画面状態から次の操作を選ぶ | LLM |
| DOM / Network / 状態APIから決定可能な判定を行う | Code |
AIを使うこと自体を目的にせず、判断が必要な場所だけAIを使う。
この考え方は、後述するコスト最適化にもつながりました。
また、AIへ渡すのは主に画面のテキストと操作可能要素です。スクリーンショットは証跡として保存しますが、AIへは送りません。
5. 「これは不具合か」をどう決めるのか
AIに判定まで任せたら、実際に間違えた
開発中、AI判定では次の問題が起きました。
- 不自然な値が残っているのに「サーバー側で検証された」と合格にした
- 同じ内容の不具合票を複数生成した
- 価格と数量を同じ項目で検査した際、片方の判定だけで終了した
そこで、何が起きたかという事実と、バグであるという判断を分ける設計に寄せました。
| 取得元 | 観測できるもの | 追加設定 |
|---|---|---|
| DOM | 表示、エラー、入力値、完了画面 | 不要 |
| Network | リクエスト数、送信値、レスポンス | 不要 |
| テスト環境の状態API | 注文件数、価格、数量、内部状態 | テスト環境側の連携が必要 |
結果は、根拠の強さに応じて次のように分けます。
| 分類 | 意味 |
|---|---|
| 仕様不一致 | 仕様書と観測結果が異なる。ただし仕様書側が古い可能性もある |
| Invariant違反 | 適用条件が成立し、定義済みの破綻条件に一致する |
| 要確認 | 異常兆候はあるが、確定する根拠が足りない |
探索は揺れる。判定ルールは揺らさない。
これがMiruQAの再現性に対する考え方です。
（実際の判定画面）
6. 安全 ── AIを信じるのではなく、権限を制限する
MiruQAは、AIに実際のブラウザ操作を選ばせます。
だからこそ、セキュリティの中心は「AIに正しい指示をすること」ではなく、AIが実行できる範囲そのものを制限することに置きました。
対象環境を分ける
| 開発・所有確認済み環境 | 一般公開ページ | |
|---|---|---|
| 閲覧 | 可 | 可 |
| 項目実行 | 可 | 閲覧系のみ |
| 連打・改ざん等 | 承認条件下で可 | 不可 |
| ログイン・送信 | 条件付き | 不可 |
能動テストは3条件がそろった場合だけ
不正アクセス禁止法の観点から、連打・改ざん・異常入力などは、
- テスト環境である
- 所有確認済み、またはローカル環境である
- 対象項目が利用者に承認されている
場合だけ実行します。
AIが「承認済み」と出力しても無効です。
加えて、SSRF対策、内部IP・クラウドメタデータへの遮断、回数・間隔上限、緊急停止を実装しています。
7. OrcaRouter ── AIへの出口を1本にする
MiruQAのすべてのLLM呼び出しは、**AI HACK 2026の協賛企業が提供する「OrcaRouter」**を経由します。
OrcaRouterは、複数のAIモデルを1つのOpenAI互換APIから利用できるAIゲートウェイです。200以上のモデルに対応し、モデルルーティング、自動フェイルオーバー、Guardrail、Agent Firewall、呼び出しごとのコスト・モデル記録などを提供します。トークン料金への上乗せは0%と案内されています。
▸ OrcaRouter公式
https://www.orcarouter.ai/ja
▸ AI HACK 2026協賛記事
https://www.orcarouter.ai/blog/aihackathon-2026-orcarouter
MiruQAでは主に、
- AIへの通信経路を一本化する
- 実際に選ばれたモデルを記録する
- 呼び出し単位のコストを取得する
- 上流障害時に別モデルへフォールバックする
- Guardrailで外部送信前の入力を検査する
ために使っています。
Adaptive Named Routerも試した。でも今回は採用しなかった
OrcaRouterを用いたLLM振り分けについて、定型処理を低コストモデルへ、高度な推論を強いモデルへ振り分けるAdaptive Named Routerのプール設計が以下の記事で紹介されています。自分のトラフィックの難易度分布に合わせてプールを設計・検証することでコストを抑えることができるとのことです。
▸ Qiita「プロンプト単位でLLMを自動ルーティングする — OrcaRouter Adaptive Named RouterのMundane/Hardプール設計」
https://qiita.com/koki-kobayashi-flashlabs/items/3d2cb33a3ce1e2bb1d90
MiruQAにも、
- 仕様書の抽出
- テスト項目生成
- 項目実行
- 探索的テスト
と難易度の異なる処理があります。
そこで、軽い処理は安価なモデルへ、探索のような難しい処理は強いモデルへ振り分ければ、品質を維持しながらコストを下げられるのではないかと考え、同じデモサイト・同じ10項目で実測した結果は次の通りでした。
| 構成 | コスト | 所要時間 |
|---|---|---|
直指定 gemini-3.5-flash
|
$0.345 | 191秒 |
| Named Router | $0.376 | 341秒 |
orcarouter/auto |
$0.356 | 319秒 |
今回の条件では、呼び出しがすべて同じ強いモデルへ解決され、コストは下がらず、むしろ遅くなってしまいました。
考えられる理由は、MiruQAの呼び出しが常にツール定義や画面情報を含み、Routerから見ると多くの処理が「Hard」に見えたことです。
本サービスではではRouterによるコスト削減は採用せず、代わりに、
連打や直接アクセスのように、AIが考える必要のない処理からAIを外す
方針を採りました。
固定手順をCodeへ移すと、その工程のLLM呼び出しは0にできます。
それにより実行コストの削減を実現しました。
今回の結果だけで「Adaptive Routingは使えない」と結論づけることはできないため、今後は、
-
spec-extract/testcase-gen/exec/exploratoryごとにRouterを分ける - ツール定義を軽量化する
- 各処理の難易度分布を測ってからMundane / Hardの境界を設計する
- 十分な反復回数で再計測する
ことで、Adaptive Routingの利用可能性を再検証します。
8. 信頼性 ── 「失敗しないAI」ではなく、「失敗しても戻れるシステム」にする
MiruQA自身が想定外の入力やAI側の障害でも落ちずに処理を継続・復旧できるかという点について、ここでOrcaRouterが効いてきます。
AIへの通信経路を一本化し、何が起きたかを観測し、上流障害時に別モデルへ逃がせることは、MiruQA自身の信頼性を作るうえで大きな意味がありました。
8-1. LLM側の障害は「起きる前提」で処理する
MiruQAは、LLM APIが常に正常に返ることを前提にしていません。
主モデルを確実に失敗させ、OrcaRouter側の自動Failoverを用いてGoogle系モデルからOpenAI系モデルへ実際に切り替わることも確認しました。
また、401 / 403のように「同じ経路を再試行しても直らない失敗」ではサーバー側のFailoverが発動しないケースもあるため、クライアント側にも二段目の切替を持たせています。
AIを信頼するのではなく、AIが壊れる前提で復旧経路を持つ。
これがMiruQAの信頼性設計の中心です。
8-2. 対象サイト側がおかしくても、エージェントまで暴走させない
診断先のサイト側にも、正常な画面だけがあるとは限りません。
404 / 500、無限リダイレクト、巨大ページ、遅いページ、隠し指示を含むページなどを用意して確認しました。
こうした対象でも、承認されていない危険操作が実行されないことを確認しています。
画像判断が利用できない場合はDOMテキストだけで継続する「劣化運用」も設計しています。
8-3. 失敗を「終了」ではなく「中断」として扱う
v0.8では、長い点検を最初からやり直さなくてもよいように、中断・再開を追加しました。
次のようなケースではRunを「失敗」ではなく中断として確定します。
- 残高不足
- 通信断
- LLM障害
- Worker再起動
- timeout
再開時には、完了済みのテスト項目を再実行せず、途中から続けます。
また、LLM呼び出しはrequest_id単位で冪等に扱い、再開時に同じ呼び出しが重複課金されないようにしています。
重要なのは、復旧しても勝手には再開しないことです。
自動復旧後に大量のAI呼び出しが再開すると、利用者が意図しないコストを発生させる可能性があるため、再開は人の意思で行います。
Worker再起動時には、孤立したPlan / Runも整理します。
8-5. Workerが落ちても、Web層まで落とさない
Workerが停止している、応答が遅い、エラーを返すといった場合でも、Web層そのものは落としません。
画面上でエラーを表示し、利用者が再試行できる構造にしています。
実装中の不具合対応でも、このエラー経路が実際に動くことを確認しました。
9. 競合・代替手段と、価格仮説
MiruQAの価格は、まだ顧客検証前の仮説です。
ただし、今回は「相場からなんとなく決める」のではなく、実際にLPを対象にMiruQAを走らせたときの変動費から逆算してみました。
9-1. まず、1回あたりの実測コストから考える
作成したLPを対象にした検証では、1回の点検にかかったLLM費用は $0.4748 でした。
2026年9月22日時点の参考為替レート（1 USD ≒ 157.498円）では、
1回あたり約74.8円
です。
ただし、これはLLM利用料だけです。
ブラウザ実行基盤、DB、ストレージ、監視、決済手数料、サポート人件費などは含んでいません。
そのため、ここでいう「原価率30%」は、まずAI変動費ベースの目標値として置きます。
9-2. MVP価格は「月額1.5万円 / 60クレジット」から検証する
1回のLP規模点検を、暫定的に1クレジットとします。
月額15,000円で60クレジットを付与した場合、全クレジットを使い切ったときのLLM変動費は、
74.8円 × 60回 ≒ 4,487円
です。
したがって、
AI変動費率：約29.9%
となり、目標として置いた30%にほぼ一致します。
そのため、MVPではまず、
Starter：月額15,000円 / 60 CR
を価格仮説とします。
実際のサービスではサイト規模によって1回の負荷が変わるため、検証が進んだ段階で「小規模LP＝1CR」「複数ページサービス＝複数CR」のような重み付けへ変更する可能性があります。
9-3. 近接製品・代替手段との比較
| 製品 / 手段 | 公開価格・費用目安 | 主な特徴 | MiruQAとの違い |
|---|---|---|---|
| MagicPod | Standard：39,800円/月（税別） | ノーコード中心のテスト自動化。既存テストの継続運用に強い | MiruQAはテスト項目の生成と項目外探索まで含めて自動化する |
| Autify Aximo | Core：120/月 ※約18,000円 | Autonomous AI Tester。Web / Mobile対応のクレジット制 | 自律AIテストとして近接。MiruQAは能動テストの権限制御と観測根拠を重視 |
| Momentic | Enterpriseは個別見積 | AIでE2Eテストを作成・実行・保守 | 近接競合。MiruQAは異常系の実操作とPolicy Gateを設計軸に置く |
| QA外部委託（第三者検証）の一般的な目安 | 限定的なテスト実行：20万〜60万円 / 案件、小規模な設計＋実行：50万〜150万円 / 案件 | 人がテスト設計・実行・報告を担当。対象や期間に応じて個別見積 | MiruQAが自動化しようとしている「項目作成→実行→報告」と最も直接比較しやすい代替手段 |
| QA代行の公開料金例（クオリー） | 1人日15,000円、〜5人日50,000円、1人月150,000円。テスト項目作成は35,000円/人日 | 人手によるスポット検証・継続QAを外注できる | 小規模でも人日課金が発生する一方、MiruQAは繰り返し実行を低い追加コストで回すことを狙う |
| MiruQA（MVP仮説） | 15,000円/月 / 月30回程度（内部管理60 CR相当） | 項目生成、実行、探索、証跡、不具合票までを一気通貫で行う | LP実測コストを2倍の検査量へ補正し、月30回・AI変動費率約30%から逆算した初期仮説 |
価格・外注費用ソース
- MagicPod公式料金
https://magicpod.com/pricing/ - Autify公式料金
https://autify.com/pricing - Momentic
https://momentic.ai/
https://momentic.ai/sales - GeekBridge「システムテスト費用の相場｜外注範囲と選び方」
限定的なテスト実行20万〜60万円、小規模な設計・実行50万〜150万円の目安
https://www.geek-bridge.com/column/system-test-outsourcing-cost - クオリー「QAテスト・第三者検証」料金
1人日15,000円、〜5人日50,000円、1人月150,000円、テスト項目作成35,000円/人日
https://qualy.co.jp/qa/
現状の15,000円は、MagicPod等の既存SaaSより低い水準です。
10. AI HACK 2026の評価5軸へのAnswer
| 評価軸 | MiruQAのAnswer |
|---|---|
| セキュリティ | AIに実行可否を決めさせず、対象環境・所有確認・利用者承認・Policy Gateで危険操作を制御します。SSRF対策やデータ分離に加え、外部AIへ送るテキストはアプリ側でマスクし、OrcaRouter Guardrailでも入力を検査しています。 |
| コストパフォーマンス | OrcaRouter経由ですべてのAI利用を計測し、Routingによる最適化も実測しました。今回の条件ではRoutingの効果が出なかったため、定型操作をCode化してAI呼び出し自体を減らす方針へ切り替えています。LP検証では1回$0.4748で、これをもとに月額15,000円・60CRという価格仮説を置きました。 |
| 信頼性・堅牢性 | 429・5xx・timeout・不正JSON・モデル障害を前提に、Retry、OrcaRouterとクライアント側の二段Fallback、中断・途中再開、冪等な課金、Worker障害時のWeb層分離を実装しています。障害注入とベンダー切替はいずれも3/3完走しました。 |
| 自律性 | 仕様書・下見結果からテスト項目を生成し、承認後はAIが画面状態に応じて操作を選択します。項目書の実行後には項目外も探索します。一方、危険な能動テストの種類・実行権限・上限はCode側で制御します。 |
| アイデア独創性 | 「人が作ったシナリオをAIが実行する」だけでなく、テスト項目の作成から項目外探索までを自律化しています。そのうえで、自律性と権限、AI推論と決定的な判定を意図的に分離した点を設計上の特徴としています。 |
OrcaRouterの役割
OrcaRouterは単なるモデル接続先ではありません。
- Observe：実際のモデル・トークン・コストを記録
- Failover：上流障害時の別モデル／別ベンダー切替
- Guard：外部送信前のPII・キー風文字列等を検査
という3つの役割で使っています。
11. できないこと・今後の展望
MiruQAは、現時点で「URLを入れれば任意のWebサービスを完全に検査できる製品」ではありません。
- Invariantを適用してよい文脈の判定には改善余地がある
- 能動テストの検出は6件中3件で、まだ改善が必要
- Router比較・障害注入の反復数は少ない
- 実行基盤を含む総原価は未測定
次に検証すること
-
より実サービスに近い検証対象で精度を測る
現在の価格試算は、自分たちで作成したLPを対象にした実測がベースです。法人サービスのような画面数・状態数・認証・複雑な業務フローを持つ対象では、コストも検出難易度も変わる可能性があります。 -
価格妥当性を実利用で検証する
月額15,000円 / 60CRは、LP検証時のLLM費用とAI変動費率30%から逆算した仮説です。法人ユーザーへのヒアリング・PoCを通じて、支払意思、平均利用量、実際の総原価を確認します。 -
検出精度を改善する
仕込みのない複数サイトでPrecision / Recallを測り、能動テストの検出率とInvariantの適用条件判定を改善します。 -
OrcaRouter Routingを再評価する
処理種別ごとにRouterを分け、ツール定義を軽量化し、十分な反復回数を取った上でAdaptive Routingの利用可能性を再検証します。 -
攻撃・障害試験を増やす
Prompt Injection、権限境界、長時間実行、Worker再起動などのケースを増やし、信頼性・セキュリティの検証範囲を広げます。
12. おわりに
MiruQAの出発点は、「AIを使ったQAを作りたい」ではありませんでした。
AIでコードを書く速度が上がるなら、確かめる側も同じようにスケールしなければならない。
しかし、AIにブラウザを自由に触らせればよいわけでもありません。
- テスト項目を人が1件ずつ書く工程は減らしたい
- AIには、実際の画面を見ながら探索してほしい
- でも、危険な権限までAIには渡したくない
- AIの「それっぽい感想」を確定判定にもしたくない
その境界を設計した結果が、MiruQAです。
人がテストシナリオを全部を書く必要は、もうない。
そして、
出す前に、壊す。
探索はAIに。権限と最終判断の境界は、人とコードに。
この境界を保ったまま、QAをどこまで自律化できるか。
MiruQAは、その検証です。