technical how本記事は 2026 年 5 月 13 日 に公開された「 Sim-to-Real and Real-to-Sim: The Engine Behind Capable Physical AI 」を翻訳したものです。 はじめに 現実世界で知覚・推論・行動するロボット、いわゆる Physical AI システムの進化が加速しています。その中心にあるのが Sim-to-Real パイプラインです。しかし、実験室の外でも安定して動作するモデルの構築は、この分野で最も難しい課題の一つです。シミュレーションで機能するものと実際のハードウェアで機能するものの間にあるギャップこそ、多くのプロジェクトが行き詰まる原因です。 本記事では、Sim-to-Real (Sim2Real) と Real-to-Sim (Real2Sim) が、物理環境で動作する AI モデル構築において最も重要な技術となった理由を解説します。シミュレーションと現実のギャップがなぜ埋まりにくいのか、現代的なアプローチでどう克服するのか、そしてロボティクスをけん引する Vision Language Action モデル (VLA) がこのパイプラインの品質に全面的に依存している理由についても説明します。 実世界のデータだけではスケールしない理由 ロボットに操作タスクを学習させるには、照明・物体の位置・表面テクスチャ・グリッパーの向きといった条件を横断して汎化するために、通常数万件のデモンストレーションが必要です。それを実機で実施するのは時間もコストもかかり、リスクも伴います。 この制約はあらゆる分野に共通します。倉庫の自動化では通常、数千種類の SKU バリエーションへの対応が必要です。自動運転車は通常、数百万件の走行シナリオを必要とします。手術ロボットは、実際の患者で倫理的にリハーサルできない処置を扱います。必要な規模での物理的なデータ収集は、現実的に不可能です。 シミュレーションはこの課題に直接対処します。物理的に正確な仮想環境では、通常、はるかに低コストで安全な環境から桁違いの速さでトレーニングデータを生成できます。ただし、純粋にシミュレーションで学習したモデルは、常に変化し予測不可能な物理環境での動作という性質上、実世界に展開すると失敗しがちです。この失敗パターンには名前があります。シミュレーションと現実のギャップ、すなわち「リアリティギャップ」です。 シミュレーションと現実のギャップ シミュレーションと現実のギャップとは、シミュレーションで学習したモデルを実機に展開したときの性能差のことです。シミュレーションはあくまで近似であるため、このギャップは避けられません。実際のカメラはノイズ・歪み・露出変動をもたらしますが、合成レンダリングはデフォルトではそれを再現しません。実際の表面には、どの物理エンジンも完全にはモデル化できない摩擦係数があります。実際のアクチュエータにはバックラッシュ・遅延・熱ドリフトがあります。クリーンな合成データで学習したモデルはシミュレーションの完全性を利用することを覚えてしまい、その挙動は現実には転用できません。 ギャップを埋めるには、二つの補完的なアプローチが必要です。 シミュレーション精度の向上 NVIDIA Isaac Sim のような現代の物理シミュレーターは、剛体ダイナミクス・変形可能物体・流体挙動・接触力を、数年前には実現できなかったレベルの精度でモデル化します。パストレーシングと物理ベースマテリアルを用いたフォトリアリスティックなレンダリングにより、実際のカメラ映像との区別がますます難しい視覚入力が生成されます。 Figure 1: Amazon EC2 G6e.4xlarge インスタンス上で動作する NVIDIA Isaac Sim ドメインランダム化　 単に一つのシミュレーションを完全に正確にするのではなく、多数のランダム化されたバリエーションにわたって学習します。照明・テクスチャ・物体の質量・関節摩擦・センサーノイズを変化させることで、幅広い条件の分布に対してロバストなポリシーを学習します。重要なのは、純粋なデータ量ではなく、シミュレーションパラメータの十分な多様性とカバレッジです。これにより、ニューラルネットワークは多様な環境において、対象物のキーとなる要素を識別することを学習します。 Figure 2: OpenAI が実証した、ルービックキューブを解くロボット。(出典: OpenAI, https://openai.com/index/solving-rubiks-cube/) Real-to-Sim: 物理世界をトレーニングインフラに変える Real-to-Sim とは、現実の環境をキャプチャしてシミュレーション対応のデジタル表現に変換するプロセスです。Sim2Real が学習済みポリシーを実機に転用することを目的とするなら、Real2Sim はそのシミュレーションがハードウェアの実際の動作環境を反映することを保証するためのものです。 使用される技術は複数の分野にまたがります。LiDAR スキャンとフォトグラメトリーは、3D メッシュに処理できる点群を生成します。 Neural Radiance Fields (NeRF) と 3D Gaussian Splatting は、通常のカメラ映像からシーンのジオメトリと外観を再構築し、物理シミュレーション環境に直接取り込めるアセットを生成します。これはリアリティギャップ、すなわち仮想アセットと物理アセットのモデル化における性能差の解消に役立ちます。これらのアセットは、多様な照明条件やカメラアングルにわたって現実の見た目や質感を保持する技術を用いて仮想世界に取り込まれます。 Physical AI のトレーニングパイプラインにおいて、Real2Sim は 遠隔操作によるデータ収集 で特に重要な役割を果たします。人間のオペレーターがデモンストレーションインターフェースを通じて物理的なロボットアームを操作すると、システムはその動きをシミュレーション上のデジタルツインに同時にミラーリングします。これにより現実世界で記録された人間品質のデモンストレーションデータセットと、同じタスクの追加的な合成バリエーションを生成できる同期済みシミュレーショントレースという二つのデータを同時に得られます。。 Figure 3: SO-101 を使ったテレオペレーション このアプローチが実用的な加速手段となるのは、 模倣学習 の中心的なボトルネックに対処しているからです。模倣学習とは、報酬ベースの試行錯誤ではなく人間のデモンストレーションを観察することでロボットが学習する枠組みです。高品質な人間のデモンストレーションは模倣学習が依存するトレーニングシグナルであり、Real2Sim インフラを活用することで、物理ハードウェアのコストを比例的に増やすことなくそのシグナルをスケールできます。 合成データの生成とフィルタリング 実世界およびテレオペレーションで収集したデータは分布に沿った教師信号を提供します。つまり、トレーニングサンプルがロボットの展開時に実際に直面する条件 (照明・物体の種類・カメラアングル) を反映しています。シミュレーションはスケールを提供します。現代の Physical AI トレーニングパイプラインはこの二つを組み合わせます。 合成データ生成とは、シミュレーション環境内でラベル付きトレーニングサンプルをプログラム的に大規模生成することです。操作タスクでは、異なる物体姿勢・照明条件・グリッパー構成にわたって把持シナリオの数千バリエーションをレンダリングし、それぞれに深度・セグメンテーションマスク・アクションラベルのグラウンドトゥルースを自動アノテーションします。 データ量だけでは不十分です。フィルタリングパイプラインは、自動品質メトリクスと学習済み識別器を使って、分布外または物理的に不自然なサンプルをトレーニングセットに入る前に除去します。適切に構築されたパイプラインの出力は、実際のデモンストレーションによる物理的な根拠、合成生成の規模、および自動フィルタリングによる品質管理を備えたトレーニングデータセットとなります。 VLM・VLA と、シミュレーション品質がモデル性能を決める理由 Physical AI チームがロボット制御の基盤レイヤーとして注目しているモデルが、Vision Language Model (VLM) と Vision Language Action モデル (VLA) です。 VLM は、大規模な画像とテキストのコーパスで学習したマルチモーダル基盤モデルです。幅広い視覚的理解で、画像内の内容を推論し、空間的な関係を説明し、物体を識別し、視覚的なコンテンツを参照する言語指示に従う能力を獲得します。 Amazon Bedrock 上の Amazon Nova 、Anthropic Claude、Qwen、Mistral などがこのクラスの例です。Amazon Bedrock は、基盤インフラを管理することなくこれらのモデルにアクセスするためのマネージド API レイヤーを提供します。これは、独自のインフラの複雑さを持つ Physical AI パイプラインに視覚的推論を統合する際に重要です。 VLA は、VLMのパラダイムを物理的な動作へと拡張したものです。VLAは、テキストを出力するのではなく、視覚的な観察と言語による指示に応じて、ロボットの動作、関節の位置、速度指令、エンドエフェクタの軌道などを生成します。VLAのトレーニング目標は、視覚的理解と物理的な因果関係の両方に基づいた方針を学習することです。つまり、「自分が見ているものと、自分がするように求められていることを踏まえて、どのような行動をとるべきか？」を学習します。 シミュレーションデータの品質は、VLAが明示的に学習されていないタスクに対してどれだけうまく汎化できるかを直接左右します。学習に使用した視覚ドメイン（合成レンダリング）が展開ドメイン（現実世界）と一致しない場合、学習されたポリシーは破綻し、ぎこちない動作制御、タスクの失敗、ポリシー評価の精度低下といったパフォーマンス上の問題が即座に発生します。ドメインランダム化は、高品質のベースデータセットを取り込み、それを拡張して、新しいオブジェクト、異なる照明条件や色を持つ環境などを含むさらに高品質のデータセットを生成することで、ポリシーの堅牢性を高めます。高忠実度物理演算により、動作出力が物理的に意味のあるものとなることが保証されます。 合成データパイプラインは、実際のデモンストレーションだけではカバーできないタスク分布、まれな障害モード、エッジケース構成、そしてまだ物理的に存在しない環境に対してVLAを学習させることを可能にします。 産業への応用 このパイプラインが最も即効性のある価値をもたらす業界には、ある共通の特徴があります。それは、物理的な環境がリスクが高く、変化に富み、直接学ぶには費用がかかったり危険を伴ったりするという点です。 製造業 では、倉庫自動化システムが SKU のバリエーション・梱包の損傷・フロアレイアウトの変化に対応する汎化能力を必要とします。Real2Sim キャプチャがシミュレーショントレーニングに供給され、Sim2Real 転用により実世界のバリエーションに耐えるポリシーが生成されます。 自動車業界 では、自動運転システムは通常、実世界では安全に再現できない数百万件のエッジケースシナリオにわたるトレーニングを必要とします。 医療分野 では、手術や患者ケアへの応用が厳格な安全規制上の制約を受けます。高精度なシミュレーションにより、患者への接触なしにモデルのトレーニングと検証を進められます。 エネルギー・公益事業 では、点検用の自律ロボットが変電所・パイプライン・風力発電所など、人間が立ち入ることに実際の身体的リスクを伴う環境で稼働します。 小売業界 では、自律型フルフィルメントシステムは、絶えず変化するレイアウトの中で膨大な種類のSKU（在庫管理単位）に対応しなければなりません。数千種類もの製品バリエーションにわたるトレーニングデータを生成するシミュレーションこそが、生産規模での汎用化を実現する唯一の現実的な方法です。 今後の展望 本記事では、Physical AIモデルを現実世界で動作させるためのコアエンジンであるSim2Real/Real2Simパイプラインの目的と内容について解説しました。本シリーズの次回記事では、LeRobot SO-101 AWS Sim2Real2Sim リファレンスプロジェクトのハンズオン技術解説を通じて、これらの概念を具体化します。AWS インフラストラクチャ・NVIDIA Isaac Sim・公開されている LeRobot プラットフォームを使ってエンドツーエンドで実装する、完全にデプロイ可能なアーキテクチャを紹介します。 まずは基盤モデルへのアクセスに Amazon Bedrock を、シミュレーションワークロードに最適化された Amazon EC2 G6e インスタンス をご確認ください。 <!-- '"` --> Dario Macagnano Dario Macagnano is a Physical AI Solutions Architect at AWS. With years of experience designing and deploying solutions spanning real-time simulation, digital twins, and edge inference — from rapid prototypes to large-scale production systems — Dario is passionate about the convergence of AI, robotics, and cloud infrastructure that brings intelligent systems into the physical world. Ignacio Sánchez Ignacio Sanchez is a Worldwide Specialist Solutions Architect for Physical AI in AWS, based in Madrid, Spain. He works with customers and partners globally to design and deploy AI solutions that bridge the digital and physical worlds, spanning spatial computing, robotics, and edge inference workloads on AWS. Ignacio is passionate about emerging technologies and their real-world applications. In his spare time, he enjoys reading, playing video games, and staying active through sports. Quinn Cheong Quinn Cheong is a Worldwide Specialist Solutions Architect for Physical AI at AWS, helping to shape the global Physical AI architectural strategy for the domain. Quinn’s expertise spans cutting-edge software development, and he has pioneered multiple solutions from World Generation and 3D Model Inferencing on Kubernetes, to creating WebXR augmented workers for AR Glasses. Quinn is also a seasoned AWS speaker, having presented at 30+ global events and summits. He is now focused on scaling Physical AI Infrastructure with Kubernetes and Agentic AI. 翻訳は Visual Compute SSA 森が担当しました。原文はこちらをご覧ください。

はじめに こんにちは、カート決済部カート決済サービスAブロックの 道場 です。ZOZOTOWN内のカート機能や決済機能の開発、保守運用を担当しています。 現在、ZOZOTOWNのカート決済画面はリプレイスが進行中です。既存システムとリプレイス後のシステムが並行して開発される中、既存システムへのさまざまな機能改修を、リプレイス側にも取り込む必要があります。その際、条件の組み合わせが膨大になるテストを手動で網羅的に実施することが現実的でなく、特に注文金額の計算結果の正確性を人間が1件ずつ確認するには大きなコストがかかっていました。 本記事では、Claude CodeとPlaywright CLIを組み合わせて、自然言語によるE2Eテストを自動化した仕組みをご紹介します。Confluence（Atlassian社が提供するナレッジ共有ツール）に自然言語でテスト手順を記述することでAIが自律的にブラウザを操作し、計算検証も含めてE2Eテストを完結させています。コードを書かずにテストを作成・実行できるため、テスト自動化の属人化解消にもつながりました。 目次 はじめに 目次 背景・課題 リプレイスに伴う二重開発とテストの課題 なぜ従来のE2E自動化では足りなかったのか AIエージェント駆動のE2Eテストシステム 全体アーキテクチャ Playwright CLIによるブラウザ操作 Agent Skillsによる操作手順の定義 テストケースの設計と期待値の保証 Confluenceベースのテストケース管理 計算が必要なテストの期待値保証 テスト実行の6つのStep テスト支援ツールの構築 atlassian-cli：Confluence操作のCLI zozo-sql-server-cli：SQL Serverクエリ実行CLI AIエージェントが必要なツールを自ら作る 従来のテスト自動化との比較 実践から得られた知見 テストケースの実績 実践を通じた気づき まとめ 背景・課題 リプレイスに伴う二重開発とテストの課題 冒頭の通り、ZOZOTOWNのカート決済画面ではリプレイスが進行中です。既存システムとリプレイス後のシステムが並行して動作する期間中、既存システムに対するさまざまな機能改修をリプレイス側へ取り込む必要があります。 これらの改修をすべて取り込み、条件の組み合わせが爆発的に増加するテストケースを検証する工数が大きな課題となりました。 たとえば、ある案件の機能を取り込む場合、以下のような因子が絡み合います。 ユーザーの属性（性別・年齢 等） 購入商品の種類・金額 割引・クーポンの有無 ポイント利用の有無 キャンペーン期間の内外 これらを組み合わせると、1つの案件だけで 100件以上のテストケース が発生することもありました。さらに、各テストケースでは 注文フローの複数画面 （配送・支払い選択、注文の確認 等）で表示値の確認が必要です。そして、 PC用の画面とスマートフォン（以下、SPと表記します）用の画面がそれぞれ存在 するため、検証量は実質的にさらに倍になります。 カート決済画面では、注文金額の計算ロジックにさまざまな要素が関わっており、前述の通り案件ごとに条件の組み合わせが大きくなりがちでした。さらに、期待値は複雑な計算式で決まるため、人間が1件ずつ手計算したうえで画面の表示と照合するには多くの時間がかかっていました。 なぜ従来のE2E自動化では足りなかったのか ZOZOTOWNでは、手動テストに加えて品質管理部によるコードベースのE2E自動テストも活用しています。しかし、そのような従来のコード記述型の自動テストを使ったアプローチでは以下の課題がありました。 プログラミングスキルへの依存 ：CSSセレクタやロールを使った要素特定のコードを書く必要があるため、開発者でなければ作成・保守が難しい UI変更への追従コスト ：UIの変更に応じて、要素特定の方法やテスト内容のメンテナンスが必要になる テストコードの属人化 ：記述・保守できる人が限られるため、特定の開発者への依存が生じる 実現したかったのは、 テスト手順を自然言語で書くだけで、AIが要素を自動で見つけて操作し、計算検証まで完結する仕組み です。そのためのアプローチとして、Claude CodeのAgent SkillsとPlaywright CLIを組み合わせた自動化システムを構築しました。 AIエージェント駆動のE2Eテストシステム 全体アーキテクチャ 構築したシステムの全体像は以下の通りです。 各コンポーネントの役割は次の通りです。 コンポーネント 役割 Confluenceページ テストデータ・手順・期待値を自然言語で記載したテストケース管理の場 エージェント （ zozotown-qa-tester ） テストの実行フローを定義するClaude Codeエージェント Agent Skills ZOZOTOWNの操作手順やCLIの使い方をMarkdownで定義した再利用可能なリファレンス 計算サービス（TypeScript） 期待値を算出するための計算ロジック実装 Playwright CLI コマンドでブラウザを操作するCLIツール atlassian-cli Confluenceの読み取りと、エビデンスを含めた結果の記載を行う自作CLI zozo-sql-server-cli SQL Serverへのクエリ実行と結果の画像化を行う自作CLI Claude CodeのエージェントがConfluenceからテストケースを読み取ります。Agent Skillsを参照しながらPlaywright CLIでブラウザを操作し、結果をConfluenceに書き戻します。 Playwright CLIによるブラウザ操作 Playwright CLI は、ブラウザ操作をコマンドで実行できるCLIツールです。テストコードを書く代わりに、コマンド1つでブラウザを操作できます。Playwright MCPもありますが、CLIの方がトークン使用量を節約できるため選択しています。 特徴的なのは スナップショット機能 です。ページを開くと、Playwright CLIはページの構造をYAML形式で取得します。このとき各要素には ref 番号が付与されています。AIはこのスナップショットを読んで要素を特定し、 ref 番号を使って操作します。 # ref番号を使って要素をクリック playwright-cli click e42 --session = pc # テキストを入力 playwright-cli fill e15 &quot; test@example.com &quot; --session = pc # スクリーンショットを取得 playwright-cli screenshot --output screenshots/cart-top.png --session = pc CSSセレクタやロールを明示的に指定しなくても、AIがスナップショットを解釈して要素を特定できます。そのため、セレクタベースの実装に比べると、軽微なUI変更には追従しやすくなります。 PCとSPの切り替えは設定ファイルで行います。 // playwright-cli.json（PC用） { &quot; browser &quot;: { &quot; launchOptions &quot;: { &quot; headless &quot;: false } , &quot; isolated &quot;: false , &quot; contextOptions &quot;: { &quot; viewport &quot;: { &quot; width &quot;: 1400 , &quot; height &quot;: 1080 } } } } // playwright-cli-sp.json（SP用） { &quot; browser &quot;: { &quot; launchOptions &quot;: { &quot; headless &quot;: false } , &quot; isolated &quot;: false , &quot; contextOptions &quot;: { &quot; viewport &quot;: { &quot; width &quot;: 430 , &quot; height &quot;: 932 } , &quot; userAgent &quot;: &quot; Mozilla/5.0 (iPhone; ...) Safari/604.1 &quot;, &quot; isMobile &quot;: true , &quot; hasTouch &quot;: true } } } PCテストとSPテストは 別セッションで同時に実行できる ため、テスト時間の短縮にも貢献します。 Agent Skillsによる操作手順の定義 Agent Skillsでは、Claude CodeのSkill機能を活用してZOZOTOWN固有の操作手順を定義しています。コードベースのPlaywrightにおけるPage Object Modelに相当する役割を、Markdownによる自然言語の手順書で担うイメージです。 操作手順は次のように自然言語で記述します。 # ログイン手順リファレンス ## 手順 1. 以下のページを開く - PC: ` /_member/login.html ` - SP: ` /sp/_member/login.html ` 2. ` メールアドレス ` 入力欄にメールアドレスを入力する。 3. ` パスワード ` 入力欄にパスワードを入力する。 4. ` ログイン ` ボタンをクリックする。 テストケースに「テストユーザーAのアカウントでログインする」と書けば、エージェントがこのリファレンスを参照して手順を実行します。操作をリファレンスとして標準化しておくことで、 誰が書いたテストケースでも同じ操作が再現できます 。 今回定義した主要なリファレンスは次の通りです。 login-flow.md ：ログイン手順（PC / SP対応） add-to-cart-flow.md ：商品をカートへ投入する手順 order-flow.md ：注文フロー（カートTOP → 配送・支払い選択 → 注文確認 → 注文完了） sql-execution-flow.md ：SQL Serverへのクエリ実行手順 テストケースの設計と期待値の保証 Confluenceベースのテストケース管理 テストケースはConfluenceページで管理しています。ページの構成は次の通りです。 セクション 内容 要件 テスト対象の機能仕様 因子と水準 テストに関わる条件の洗い出し（ホワイトボックス観点） デシジョンテーブル 条件の組み合わせパターン テストデータ 環境URL、ユーザー情報、商品情報 テストケース 手順、パラメータ、期待値、実行結果、エビデンス テスト実行後は、Claude Codeがこのページに結果（OK / NG）とスクリーンショットを自動で書き込みます。 実際に実施したテストケースの例を紹介します。 注文金額に関わる計算ロジックの検証テスト ：注文の確認画面に表示される金額が、計算サービスの算出結果と一致することを検証します。前述の因子を組み合わせた数十件のパターンを定義しています。 テストの手順は、Confluenceページに次のように自然言語で記述されています。 1. カートを空にする 2. パラメータ（商品）に記載されている商品をカートに入れる 3. 注文へ進み、パラメータ（支払い方法）の支払い方法を選択して注文確認画面を表示する 4. 表示されている計算結果の値が OrderAmountCalculationService.getの値と 一致していることを確認する 5. viewportのスクリーンショットを取得する 6. パラメータ（ポイント利用）に記載のポイントを利用する 7. 表示されている計算結果の値が上記計算サービスの値と一致していることを確認する ... この手順をClaude Codeが読み取り、Agent Skillsを参照しながらブラウザを操作します。 計算が必要なテストの期待値保証 計算結果の検証は、今回の取り組みで最も重要なポイントです。 課題 ：注文金額に関わる複雑な計算結果を、人間が手計算して期待値と照合するには大きな工数が必要です。特に、割引・クーポン・ポイント利用・税率が絡み合う計算は、ミスが発生しやすく時間もかかっていました。 解決策 ：Playwrightテスト用リポジトリにTypeScriptで計算サービスを実装し、あらかじめ期待値を算出しておきます。Claude Codeはテスト計画の作成時に計算サービスを呼び出し、期待値をプランに出力してから、ブラウザの表示値と照合します。 // ZOZOCARD還元ポイントを計算するクラス export class ZozocardRewardPointCalculationService { private static readonly POINT_RETURN_RATE = 0.05 ; public get ( goodsPriceWithoutTax : number , quantity : number , taxRate : number ): number { // ZOZOCARD 還元ポイントの計算処理... } } この計算処理は、システムと同じ仕様をもとにClaude Codeで生成した 独立した実装 になっています。システム側の実装コードをそのまま流用すると、同じバグを共有してしまいます。仕様を別実装することで、 システム側とテスト側の独立性 を保っています。これにより、期待値とシステムの表示値を照合したときに、単なる一貫性チェックではなく、システム側の実装が仕様どおりかを検証できます。実際に、このテストを通じてシステム側の実装が仕様を正しく考慮できていないケースを検知できた事例もありました。 期待値の検証フローは次の通りです。 Claude Codeはテスト計画を作成する段階で計算サービスを実行し、全テストケースの期待値を事前に算出します。テスト実行時には、ブラウザで取得した表示値と事前に算出した期待値を照合します。 テスト実行の6つのStep エージェント定義ファイル（ zozotown-qa-tester.md ）では、テスト実行を次の6つのStepで定義しています。 --- name: zozotown-qa-tester description: ZOZOTOWN の QA テストを実行するエージェント skills: - playwright-cli - zozotown-operations - confluence-page-operations - atlassian-cli - zozo-sql-server-cli --- ## テスト実行フロー ### 1. テストケースの確認 Confluenceページからテストケースを取得し、 対象の開発環境・前提条件・手順・期待結果を読み取る。 ### 2. テストケースプランの作成 テストデータ・期待値（計算サービスの実行結果）・実行手順を整理し、 ` test-plans/ ` ディレクトリにMarkdownファイルとして出力する。 **ユーザーの承認を得てからテスト実行に進む。** ### 3. テスト準備 ブラウザを起動し、ログインや初期データのセットアップを行う。 ### 4. テスト実行 各ステップを ` zozotown-operations ` のリファレンスに従って実行する。 手順が定義されていない操作は、実際にブラウザで確認して新しいリファレンスを作成する。 ### 5. 結果の記録 実行結果（OK / NG）を判定し、スクリーンショットを撮影して Confluenceページに結果とエビデンスを書き込む。 ### 6. 結果の報告 ユーザーに実行結果のサマリを報告する。 特に重要なのは Step 2のテストケースプランの作成とユーザー承認 です。AIは非決定的に動作するため、テストケースの解釈が意図と異なる可能性があります。実行前に計画を提示してユーザーに確認することで、 解釈のズレを事前に検出 できます。 また、Step 4の「リファレンスに手順がない操作は自ら作成する」という仕組みにより、エージェントが新しい操作手順を発見するたびにリファレンスファイルが自動的に追加されていきます。使うほどにリファレンスが充実し、テスト作成が楽になっていく仕組みです。 実際のテスト実行では、テスト計画の確認とPC / SPセッションの並列実行をターミナル上で確認できます。 テスト支援ツールの構築 atlassian-cli：Confluence操作のCLI Confluenceのテストケースページを詳細に処理するため、atlassian-cliを作成しました。Atlassian MCPもありますが、スクリーンショットを添付できないため、REST APIをラップしたCLIです。 テスト実行フローでの使用例を示します。 # Confluence のテストケースページを取得 atlassian-cli confluence get-page 348678105 --body-format atlas_doc_format # テスト結果のスクリーンショットをアップロード atlassian-cli confluence upload-attachment 348678105 \ --file ./screenshots/confirm-pc.png # テスト結果をページに追記 atlassian-cli confluence update-page 348678105 \ --body-file ./test-results/result.json \ --page-version 41 zozo-sql-server-cli：SQL Serverクエリ実行CLI 注文完了後のDBデータを検証するため、zozo-sql-server-cliも作成しました。注文データが正しく保存されているかをSQLで確認し、 結果をHTMLテーブルとして描画してPuppeteerでスクリーンショット化 する機能が特徴です。 # SQL クエリを実行してテーブル形式で表示 zozo-sql-server-cli \ &quot; SELECT total_amount, discount_amount FROM orders WHERE order_id = 12345 &quot; # クエリ結果をスクリーンショット（HTMLテーブルとして描画）として保存 zozo-sql-server-cli \ &quot; SELECT total_amount, discount_amount FROM orders WHERE order_id = 12345 &quot; \ --screenshot ./screenshots/order-db.png このスクリーンショットをそのままConfluenceのエビデンスとして添付することで、DB検証の証跡も自動的に記録できます。 AIエージェントが必要なツールを自ら作る atlassian-cliとzozo-sql-server-cliは、いずれもClaude Codeを活用して作成しました。 テスト自動化を進める中で「Confluenceにスクリーンショットを添付したい」「DBの検証結果を画像として保存したい」といったニーズが生まれました。これらをCLIとしてClaude Codeに実装してもらい、短期間で必要な機能を揃えることができました。 AIエージェントに必要なツールをAI自身が作れる という点は、自動化のエコシステムを大幅に加速させます。 従来のテスト自動化との比較 従来のコードベースのE2E自動テストと、今回構築したClaude Code + Playwright CLIのアプローチを比較します。 観点 コードベースのPlaywright Claude Code + Playwright CLI テストケースの形式 TypeScript / JavaScriptコード Confluenceページ（自然言語） 要素の特定方法 CSSセレクタ / ロール スナップショットのref番号（AIが自動特定） 期待値の検証 ハードコードされたアサーション 計算サービス + AIによる照合 UI変更への耐性 低い（セレクタ・ロールの変更対応が必要） 高い（スナップショットベースで柔軟に対応） 作成に必要なスキル プログラミング ドメイン知識 + 自然言語 最も大きな違いは、 テストコードの記述・保守スキルがなくてもE2Eテストを作成・実行できる 点です。 Confluenceでテスト手順を書く際には「テストユーザーAでログインする」「XXXの商品をカートに入れる」といった日常的な言葉で記述できます。Agent Skillsのリファレンスにログインやカート投入の手順が定義されているため、この自然言語の指示だけでAIが正確に操作を再現します。 また、計算検証の自動化により、人手では高コストだった期待値照合をAIが実行できるようになりました。開発者は別の案件の開発を進めながら、Claude Codeにテストを並行して実行させることができます。 実践から得られた知見 テストケースの実績 実際に実施したテストの実績は次の通りです。 テスト対象 テストケース数 対象画面 プラットフォーム 案件A（計算ロジックの検証） およそ20件 注文フローの各画面 PC / SP 案件B（条件の組み合わせ検証） およそ50件 注文フローの各画面 PC / SP 手動でのフローと、今回構築したAIエージェント活用後のフローを比較すると次のようになります。 人が行うのは、テスト計画のレビューのみです。数十件のテストケース × 複数ページ × PC / SPの全テストをClaude Codeに任せられました。案件Aでは詳細な計算結果を、案件Bでは肥大化する条件の組み合わせを検証でき、人手による手計算や確認にかかる工数を大きく減らせました。 実践を通じた気づき Agent Skillsの粒度設計 ：ログインやカート投入、注文フローというような1つの手順として指示する粒度がちょうどよく、再利用しやすいです。細かすぎるとリファレンスが増えすぎて管理が難しくなり、粗すぎると他のテストケースで使いにくくなります。 テスト計画承認フローの効果 ：「2. テストケースプランの作成」でAIが作成した計画をレビューすることで、テストケースの解釈ミスを事前に検出できた事例がありました。コーディング時もそうですが、私はClaude Codeのプランモードをよく利用します。何をするかを綿密に考えさせたものを自分が確認することで、あとはそれを実行するだけになり、質が高くなると感じています。 自己改善するリファレンス ：未定義の操作に遭遇した際、エージェントが実際にブラウザで操作して手順を確認し、新しいリファレンスファイルを自動作成する仕組みは実用的でした。テストを重ねるほどリファレンスが充実し、環境を育てていくことで後のテスト作成が楽になっていきます。 まとめ 本記事では、Claude CodeとPlaywright CLIを組み合わせた自然言語E2Eテストの構築と実践をご紹介しました。Confluenceに自然言語でテスト手順を記述するだけでAIが自律的にブラウザを操作し、計算検証も含めてE2Eテストを完結させることができました。 膨大な組み合わせテストの自動化・計算検証の正確性担保・テスト自動化の属人化解消という課題を同時に解決し、開発者が別の案件を進めながらテストを並行完了できる体制が実現しました。今後は他の画面への展開や、定期的な実行によるリグレッションの検知などを検討していきたいと考えています。 ZOZOでは、一緒にサービスを作り上げてくださる方を募集中です。ご興味のある方は、ぜひ採用ページをご覧ください。 corp.zozo.com

こんにちは。LIFULL HOME'S の CRM領域で開発を担当しているソンです。 LIFULL HOME'Sでは、賃貸の一部レコメンドメールに掲載するレコメンド物件に対して、LLMを活用した「推薦文」を自動生成しています。これは「なぜこの物件がお勧めなのか」を自然な日本語で伝える短い文章です。物件情報をもとにユーザーごとの関心に寄り添った説明を添え、物件理解の促進とメール経由の詳細閲覧率向上を目指しています。 この記事では、その推薦文の品質を守るために私たちが構築した「AI監視システム」にフォーカスし、どのような基準で文章をチェックしているのか、実際の検出事例を交えて紹介します。 1. 導入：AIが書く文章は「便利」のその先へ 2. 根拠のない「充実」は、ただのノイズ 3. 「日本一」や「最高」が法に触れる理由 4. わずか12文字の攻防：128〜140文字のルール 5. AIが「空気を読む」：スペック羅列を超えた文章へ 6. 2段構えの監視：システムのしくみ 7. 結び：誠実な言葉こそ、選ばれるマーケティング 1. 導入：AIが書く文章は「便利」のその先へ AIによる推薦文の自動生成は、私たちのサービスにおいて欠かせない存在になりました。ただ、AIが生成する文章にはコンプライアンス上のリスクもあります。 実はこの施策の立ち上げ当初から、推薦文の品質監視は重要な課題として認識していました。LLMの特性上、意図しない表現が生成される可能性は避けられません。初期段階では生成ログをもとに人が目視でチェックしていましたが、確認できる量には限界があり、監視の精度にも課題がありました。 そこで私たちは、監視の自動化に取り組みました。2026年4月現在、「推薦文不正文言AI監視システム」が日々稼働しています。このシステムは、日中のコアタイムに定期的に生成された全文章を精査しています。私たちの監視システムは、ルールベースの用語スクリーニングとLLMによる文脈判定を組み合わせた構成へと進化しています（詳細は6章で解説します）。 この監視システムが、どうやって問題のある表現を検出しているのか。そのしくみと、私たちが目指す「言葉の質」について、技術と規制の両面から紹介していきます。 2. 根拠のない「充実」は、ただのノイズ 監視システムのログを分析して最も多く検出されるのが、「根拠なし表現」による「警告」です。「充実した設備」や「買い物便利」といった言葉は、つい多用されがちな表現です。しかし、監視システムにとってこれらは、具体的な裏付けのない不十分な表現に過ぎません。たとえ近くにスーパーがあったとしても、単に「便利」と書くだけでは不十分なのです。 監視システムの指摘例 「買い物便利」：近隣にコンビニ（徒歩800m以内）はあるが、もう少し具体的な説明が望ましい。 「充実した設備」：具体的設備名が明記されていないため根拠不足。 「日当たり良好」：方角や採光面などの理由が併記されていない。 読み手であるユーザーは、形容詞ではなく「事実」を求めています。監視システムに定義された「OK例」は、そのままプロフェッショナルの記述作法となります。 NG : 買い物便利 OK : スーパー（100m）近隣のため買い物便利 NG : 設備充実 OK : 設備充実（床暖房／追い焚き／WIC） 「近さ」や「多さ」を主観で語るのではなく、数値や施設名という「根拠」を添える。結局、具体的な根拠があるかどうかが品質の分かれ目です。 3. 「日本一」や「最高」が法に触れる理由 不動産広告には、明確に「違反」と判定される表現もあります。それは「不動産公正競争規約」によって厳格に定められた、最上級表現や完全性を意味する用語の使用です。 「日本一」「No.1」「最高級」「完全」「絶対」。これらの言葉は、客観的かつ調査にもとづいた具体的なデータがない限り、消費者に誤認を与える不当表示とみなされます。この規約にもとづくルールが監視システムに設定されており、過度な装飾は瞬時に「違反」と判定されます。 また、意外な落とし穴が「新築」という言葉の扱いです。 「違反」判定の事例 「新築複数」：『新築』と表記できるのは建築後1年未満かつ未入居の物件に限られるため、複数物件をまとめて『新築』と謳うことは規約違反のリスクが高くなる。また、新築と呼ぶための根拠説明も欠如している。 「格安」「破格」：射幸心をあおる表現として排除対象。 「早い者勝ち」：不当なあおりとして排除対象。 監視システムを通じて、こうした表現がブランドの信頼を損なうリスクをあらためて実感しました。 4. わずか12文字の攻防：128〜140文字のルール 推薦文の品質を左右するのは、言葉の意味だけではありません。システムには、非常に厳格な「文字数」という物理的制約が課せられています。私たちの監視基準では、推奨範囲は「128〜140文字」と極めてタイトに設定されています。 1文字でも超えれば警告が出ます。141文字になった瞬間、「文字数違反」として検出されます。 監視ログの記録 「推薦文が141文字と140文字を超えています」 「183文字で推奨範囲128〜140文字を超過」 なぜ、ここまで厳格なのでしょうか。それは、ユーザーのデバイス上でストレスなく読める「情報の密度」を、表示幅やスクロール量をもとに社内で検討した結果、この範囲が最適と判断したためです。ユーザーが読みやすい情報量を検討した結果、この範囲に落ち着きました。 5. AIが「空気を読む」：スペック羅列を超えた文章へ 「3LDK、南向き、駅徒歩5分」。こうした事実の羅列は、間違いではありませんが、優れた推薦文としては評価されません。監視システムには「スペック羅列」という警告項目が存在し、情報の羅列に終始した文章を「品質が低い」と判定します。監視システムは単なるキーワード検索ではなく、「自然な日本語で物件の魅力を伝えているか」という文章としての自然さも判定しています。 品質基準の定義 自然な日本語で物件の魅力を伝える文章であること。 スペック羅列のみは不可。 たとえば、条件だけを並べて最後に「ゆとりある毎日を実現します」と付け加えただけの文章は、「説明が薄く、スペック羅列寄り」と判定されます。 求められているのは、そのスペックが実際の生活にどう役立つのか、という視点です。物件データを生活のイメージに変換する力こそが、私たち書き手が意識すべき役割だと考えています。 6. 2段構えの監視：システムのしくみ この品質管理を支えているのが、LLMを活用した「推薦文不正文言AI監視システム」です。本システムは、コアタイムに定期的なチェックを実行します。 AI判定の前段階では、まず「ルールベース」による完全禁止用語のスクリーニングが行われ、それを潜り抜けた文章のニュアンスにリスクがないかをAIが判定します。特筆すべきは、AIに対して高い推論精度を求める設定を施している点です。これにより、AIは単なる文字のマッチングを超え、文脈を踏まえて、表面的には問題なさそうな表現のリスクも判定します。 システムの3つの強み 即時性の担保 : 違反検出時は、即座に担当者へ通知され、即応可能です。 高度な推論 : LLMの深い推論能力により、「一見よさそうだが実は根拠があいまいな表現」も見逃しません。 継続的改善 : 定期的に結果がまとめられ、組織全体のコンプライアンス意識の向上にもつながっています。 このしくみによって、人的チェックでは見落としがちな表現もカバーできます。常に高い水準で広告品質を維持する。これが私たちの目指す広告品質管理の姿です。 7. 結び：誠実な言葉こそ、選ばれるマーケティング AI監視システムが導き出した「安全」な文章。それは、けっして個性を殺した無機質なものではありません。むしろ、誇張を取り除いた、物件本来の価値を伝える言葉です。 結局のところ、監視システムが問題なしと判定する文章とは、「嘘がなく、具体的で、相手の人生に寄り添った誠実な文章」にほかなりません。どれだけテクノロジーが進化しても、 信頼の土台になるのは、事実にもとづいた言葉の積み重ねです。 AIを活用して推薦文を運用する私たちは、常に自らこう問いかけるべきでしょう。「あなたのその言葉に、読み手が信頼できる根拠はありますか？」その問いへの誠実さが、ユーザーから信頼されるサービスへとつながると考えています。 この監視システムはまだ導入したばかりですが、すでに大きな収穫がありました。監視結果を分析する中で、既存の推薦文生成プロンプトや監視用プロンプトそのものにも改善の余地があると見えてきたのです。監視システムは品質を守るだけでなく、私たち自身のしくみを見直すきっかけにもなっていると実感しています。 最後に、LIFULLではともに成長していける仲間を募集しています。よろしければこちらのページもご覧ください。 hrmos.co hrmos.co