OpenClawのQAシナリオを回す openclaw-qa-testing

使うとこうなる

OpenClawのソースを取得した作業フォルダで依頼すると、エージェントがQAシナリオを実行します。失敗があれば原因を直し、通るまで再実行するところまで進めます。

実サービスでQAのシナリオ一式を回して、失敗があれば原因を直してから再実行して

エージェントはまず、シナリオの一覧とテスト実行部分のコードを読みます。続いて実際のモデルを使う検証レーンでシナリオ一式を走らせ、結果を.artifacts/qa-e2e/の下に保存します。出力先は、成功・失敗の集計がqa-suite-summary.json、人が読む報告がqa-suite-report.mdです。

失敗したシナリオがあると、原因が製品側にあるのか、テストを動かす仕組み（ハーネス）にあるのかを調べて直します。直したあとは、失敗した1件だけでなく同じレーン全体を流し直す決まりです。作業が終わると、次の4点が報告されます。

• 実行の様子を見る画面のURL（該当する場合）
• 成功・失敗の件数
• 検証資料の保存先
• 何を直したかの短いメモ

画面のURLはhttp://127.0.0.1:<port>の形で、手元のブラウザから開けます。依頼したレーンのシナリオがすべて通った状態が、このスキルでの「完了」です。

openclaw-qa-testing でできること

このスキルは、OpenClawの品質確認用の仕組みであるqa-labとqa-channelを扱います。qa-channelは、テスト用に用意された疑似的な会話チャネルです。シナリオの実行と観察、失敗の調査、シナリオの追加、仕組みの説明までをまとめて頼めます。

模擬環境と実サービスを選んで実行する

QAの実行には2つのレーンがあります。開発中の確認には模擬応答のレーン、本番に近い検証には実モデルのレーンという使い分けです。

レーン	中身	向いている場面
mock-openai	模擬応答で動かす	開発中の動作確認
live-frontier	実際のモデルを使う	本番に近い検証

通常の実行では、エージェントはモデルを明示的に指定しません。モデルの選び方はQA Lab側の既定値に任せる形です。指定を加えるのは、シナリオが特定のモデルやプロバイダーを必要とするときだけです。

失敗の原因を調べて直す

よくある失敗の型と対処が、あらかじめスキルにまとめられています。エージェントはこのまとめを手がかりに原因を切り分けます。

• 実サービスでの待ち時間が短すぎてタイムアウトする
• 作業用ワークスペースの中でリポジトリのファイルが見つからない
• サブエージェントの動作確認が不安定で、結果が揺れる
• 未コミットの変更があると実行前にビルドが走り、ポートが開くまで時間がかかる

複数モデルの話し方を比べる

qa character-evalを使うと、複数の実モデルで口調や人格、雰囲気を比べられます。レポートに入るのは、審査役のモデルによる順位、実行の統計、所要時間、会話の全文です。所要時間は参考情報で、採点には使いません。

人格の設定はシナリオの中でSOUL.mdに書きます。モデルには評価中だと伝えず、雑談や小さなファイル作業など自然な依頼を送るのが基本です。比較の候補には、Codex CLIをモデルとして加えることもできます。

処理追跡データを手元で検証する

OpenTelemetry（処理の流れを記録する標準的な仕組み）の出力も、ローカルで確かめられます。実行するのは次のコマンドです。

pnpm qa:otel:smoke

このコマンドは、手元に追跡データの受け口を立ち上げて専用シナリオを流します。そのうえで出力された記録を読み解き、名前とプライバシー上の取り決めを確認します。OpikやLangfuseなど、外部の収集サービスの認証情報は必要ありません。

シナリオを追加する

新しいシナリオはqa/scenarios/の下にYAMLで書きます。Markdownでのシナリオ記述は禁止です。追加時は実行コードにも確認処理を足し、模擬だけで終わらない端から端までの検証を優先します。

インストール方法

コマンドで入れる場合は次を実行します。実行時に、Claude CodeやCodexなど入れる先のエージェントを選べます。

npx skills add https://github.com/openclaw/openclaw --skill openclaw-qa-testing

エージェントに入れてもらう場合は、次の文面をそのまま送ってください。

次の Agent Skill をインストールしてください。
https://github.com/openclaw/openclaw/tree/main/.agents/skills/openclaw-qa-testing

まず SKILL.md と付属ファイルの中身を確認し、不審な処理（外部への送信、認証情報の読み取りなど）がないことを確かめてから、Claude Code なら ~/.claude/skills/openclaw-qa-testing/、Codex なら ~/.agents/skills/openclaw-qa-testing/ に配置してください。

置き場所は、使うエージェントと適用範囲で決まります。

エージェント	全プロジェクトで使う	特定のプロジェクトだけで使う
Claude Code	~/.claude/skills/	プロジェクトの.claude/skills/
Codex	~/.agents/skills/	プロジェクトの.agents/skills/

使い方の例

依頼はOpenClawのソースを取得したフォルダで送ります。代表的な頼み方は次の3つです。

模擬環境でQA一式を実行し、失敗原因を調べて

模擬応答のレーンでシナリオ一式が走ります。失敗があれば原因を直してレーン全体を再実行し、成功・失敗の件数、レポートの保存先、修正内容のメモが返ってきます。

このキャラクター設定を複数モデルで比較して

qa character-evalで、複数のモデルに同じ人格設定と依頼を与えます。返ってくるのは、審査役による順位、所要時間、会話全文を含むレポートとその保存先です。

ローカルで追跡データの出力を確認して

pnpm qa:otel:smokeが実行され、外部サービスにはつながりません。返ってくるのは、追跡データの名前とプライバシー上の取り決めが守られているかどうかの結果です。

注意点

このスキルはOpenClawのソースを取得した開発環境でだけ動きます。 配布用のビルドには、QA機能があえて含まれていません。ビルド済みの環境で試す場合は、QA機能を含める専用の設定でビルドするか、開発モードで起動します。

実サービスでの検証には、対象に応じた認証情報が必要です。手順はOpenClawプロジェクトの1Passwordの保管庫を前提に書かれています。1Password CLIはtmuxの中でだけ使う決まりです。必要な値が見つからないとき、エージェントは推測せず、管理者に確認を求めます。

WhatsAppの検証では、専用のテスト用番号を2つ使います。個人の番号や個人のアカウントは使いません。認証情報はリポジトリ、ログ、PR、スクリーンショットに残さず、電話番号も伏せる運用です。

複数モデルの比較では、候補側も審査側も同時実行数の既定が16です。手元の環境やプロバイダーの利用制限が厳しいときは、エージェントに数を下げるよう頼めます。

ライセンスはMITです。同梱ファイルはSKILL.mdとagents/openai.yamlの2つなので、入れる前に中身を読んでおいてください。

関連スキル

同じOpenClawのリポジトリには、このスキルの前後で使えるスキルがあります。

• auto-qa は、OpenClaw全体の品質検証を続けて回すスキルです。不具合の再現から修正、レビュー、反映確認までを、再開できる報告書に残します。
• 1password は、1Password CLIの導入と認証を確認します。実サービス検証で認証情報を扱う前の準備に使えます。
• add-model-provider は、OpenClawにモデル提供サービスを追加し、実際の応答まで確認します。比較したいモデルを先に追加するときに役立ちます。

まとめ

openclaw-qa-testingは、OpenClawのQAシナリオの実行から失敗の修正、再実行、結果の報告までを一続きで任せるスキルです。模擬環境と実サービスのレーンを選べ、複数モデルの話し方の比較や追跡データの検証にも使えます。前提はソースを取得した開発環境です。実サービスの認証情報は記録に残さない運用が求められます。OpenClawの品質確認をまとめて進めたい開発者は、cccskills のページから詳細を確認してください。