プラットフォーム
本格的なAIソフトウェアデリバリーのための自動QA
AIが書いたすべての変更は、公開前と公開後に、ユーザーが体験するのと同じように、本物のブラウザでテストされます。
Ciao QAは、プラットフォームの自動テスト層です: 決定論的なブラウザリプレイ、自己修復するテスト、公開前のスモークゲート、公開後の本番チェック。アプリケーションの変化とともに朽ちていくテストスイートとは異なり、CiaoのテストはUIが進化したときに自己修復します — こうしてカバレッジは、AIの速度の開発に遅れずついていきます。
公開日 2026-07-03 · 最終更新 2026-07-03
AIは人間がテストできるより速く書く
AI支援開発はボトルネックを移動させます。かつてスプリント丸々かかっていたコードが午後に届きます — そしてそのすべての変更が、チェックアウト、ログイン、ディレクターが毎週月曜に読むレポートを壊す可能性があります。手動でアプリをクリックして回ることはそのペースに拡張できず、従来のテストスイートはUIが変わった瞬間に朽ちていきます。
Ciao QAはそのペースのために作られています。決定論的なブラウザリプレイ、自己修復するテスト、公開前のスモークゲート、公開後の本番チェックを、コードを書いたのと同じループの一部として、すべての変更に対して自動的に実行します。
QAの仕組み
QAはデリバリーループの一部として実行されます — 導入すべき別のツールでも、維持すべきパイプラインでもありません。
1. フローがリプレイとして記録される
サインイン、レコードの作成、チェックアウトといった主要なユーザージャーニーは、決定論的なブラウザリプレイとして記録されます: 毎回同じステップ、同じ入力、同じ期待される結果。
2. テストは本物のブラウザで実行される
リプレイは、モックされたコンポーネントではなく、ユーザーが体験するのと同じように、実際のアプリケーションに対して実行されます — 本物のレンダリング、本物のネットワーク、本物の認証。
3. テストは朽ちるのではなく修復する
UIが正当に変更されたとき — ボタンが移動する、ラベルが書き換えられる — 自己修復するテストは、古びたセレクタで失敗して削除されるのではなく、新しい現実に合わせて自身を更新します。
4. スモークゲートが門を守る
公開前に、スモークゲートが重要なリプレイを実行します。失敗したゲートは公開を止めるので、壊れたバージョンがそこを通って出荷されることはありません。
5. 本番チェックがループを閉じる
公開後、設定とデータが本物である本番環境で、リリースが正しく動作することを確認するためにチェックがライブアプリケーションに対して実行されます。
6. 失敗が文脈とともに作業に戻ってくる
失敗したチェックは、どのステップが失敗し何が期待されていたかという文脈とともにループに戻り、修正が構築され再検証される場所に届きます。
なぜ重要なのか
決定論的であることが重要なのは、不安定なテストがチームに赤を無視することを訓練してしまうからです。リプレイが失敗したとき、実際に何かが変わったということです — それはシグナルに基づいて行動する価値があり、ゲートを信頼する価値があるということを意味します。
自己修復が重要なのは、代替案が静かに死んでいくスイートだからです。自分自身を維持するカバレッジは、AI速度の変化に追いつくため、100番目の変更も最初の変更と同じくらい徹底的にテストされます。そして公開の両側にあるゲートは、「プレビューでは動いた」と「本番で動く」の両方が想定ではなく検証されることを意味します。
これが築く習慣こそが要点です。すべての公開がゲートされ、すべてのリリースが本番でチェックされるとき、出荷は勇気ある行為であることをやめます。チームはより多くの変更を、より小さな単位で行います。間違っていたコストが、壊れた月曜日ではなく、止まった公開になるからです — そして監査証跡は各リリースが通過したすべてのゲートを示します。
誰が使うのか
QAはCiaoのAIソフトウェア組織における6つの役割の1つであり、異なる人々が異なる形で頼りにしています。
- 本物のアプリをリリースする非エンジニア — テストスイートを書けるとは期待されない人々も、実際にそれを手に入れます — アプリが実際に持つフローから記録されます。
- エンジニアリングリーダー — 約束ではなくゲート: スモークゲートに失敗した公開は、誰がリクエストしたかに関わらず出て行きません。
- 代理店 — すべてのクライアントアプリケーションが、プロジェクトごとのQA予算やクライアントごとの手作業のスイートなしで、保護されたジャーニーを得ます。
- 運用とサポートチーム — 本番チェックがライブアプリの回帰を捕捉するので、問題はサポートチケットではなく検出結果として表面化します。
セキュリティとガバナンスに関する注記
- ✓ スモークゲートはすべての公開前に、本番チェックは公開後に実行されます。
- ✓ リプレイは決定論的です — 毎回同じステップ、同じデータ、同じ期待される結果。
- ✓ 自己修復は、UIが進化してもカバレッジを生かし続けます。
- ✓ QAの結果はConductorのプロジェクト稼働状況に反映され、フリート全体で見られます。
- ✓ テスト結果は、マージやデプロイと並んで追記専用の監査証跡に加わります。
手作業のスイート対Ciao QA
手作業のスイートとの対比は、表面的ではなく構造的です。
| 手作業で維持するテストスイート | Ciao QA | |
|---|---|---|
| 作成 | エンジニアがスクリプトを書き、更新する | アプリの構築中にフローがリプレイとして記録される |
| UIの変更 | セレクタが壊れ、テストがスキップされる | テストが新しいUIに合わせて自己修復する |
| リリース前 | 誰かが設定していればCIが実行 | スモークゲートが失敗した公開を止める |
| リリース後 | 設定されていれば監視 | 本番チェックがライブアプリを検証する |
| 不安定な失敗 | 再実行して期待する | 決定論的なリプレイ — 赤は何かが変わったことを意味する |
よくある質問
ここでの決定論的とはどういう意味ですか?
リプレイは毎回同じステップを、同じ入力と同じ期待値で実行します。したがって失敗は、テストが揺らいだのではなく、アプリケーションが変わったことを意味します — これが公開をゲートする根拠になります。
自分でテストを書く必要がありますか?
いいえ。主要なジャーニーはアプリケーションの構築とともに記録され、ビジネスにとって最も重要なフローを追加できます。エンジニアは実行されるものを検査し拡張できます — ブラックボックスではなく、プロジェクトの一部です。
スモークゲートが失敗するとどうなりますか?
公開が止まります。失敗はステップ、期待値、代わりに何が起こったかという文脈とともに戻ってくるので、修正を行い再検証できます。ゲートが緑になれば、公開が進みます。
本番チェックとは何ですか、なぜ公開後に実行するのですか?
プレビューと本番は異なります: 設定、データ、連携、トラフィックは片方でのみ本物です。本番チェックは各リリース後にライブアプリケーションに対して実行され、それが重要な場所で正しく動作することを確認し、検出結果はDoctorとSysOpsに流れて診断と対応が行われます。
これはQAエンジニアを置き換えますか?
いいえ — 彼らが時間を使う対象を変えます。ブラウザテストを生かし続ける機械的な作業は自動化され、人間はどのジャーニーが重要かを決め、ゲートが捕捉するものをレビューし、時間とともに基準を引き上げます。