＜【連載】具体と抽象を往復しよう！ 記事一覧＞ ※クリックで開きます 【第1回】分類学とアブストラクト（抽象化）〜AI時代を生き抜くための「思考の武器」〜 【第2回】分類学とアブストラクト（抽象化）〜「思考の武器」をテスト・QAの現場に活かす〜 【第3回】『具体と抽象』から見る、デザインと直感 【第4回】『具体と抽象』から見る、テスト設計 はじめに 前回の記事では、具体と抽象の往復が、デザインや直感にどのように表れるのかを書きました。 デザインでは、ユーザーの頭の中にある「こうしたい」という抽象的な期待を、ボタンやアイコン、色、配置といった具体的なUIへと変換します。直感では、過去の具体的な経験から抽象化されたパターンが、思考を高速化します。 つまり、抽象は単に物事を整理するためだけにあるのではありません。具体的な成果物をつくるためにも、複雑な状況を素早く判断するためにも使われています。 今回は、これまでの話をQAとソフトウェアテストの領域に戻します。 テストは、目の前にあるソフトウェアという具体を観察し、そこからリスクやテスト条件、テスト観点といった抽象をつくり、その抽象を再びテストケースや実行手順という具体へ落とし込む活動です。 つまり、テスト設計は、具体と抽象の往復そのものです。 前回の記事の最後では、直感による思考のショートカットは便利である一方、見えている関係だけを信じてしまう危うさもあると書きました。人はパターンを見抜けるからこそ、早合点もします。 そこでQAエンジニアが行うテスト活動では、直感に頼るだけではなく、関係性そのものを構造として捉え直す必要があります。さらに、さまざまな抽象度で複雑に発散したテスト観点を人間が扱えるように、適切な抽象度で階層化する必要もあります。 今回の記事では、次の順番で話を進めます。 まず、仕様や要件を条件と結果の関係として捉え直す方法を見ます。次に、テストがなぜ必要なのか、テストをどのようにリスクとして捉えるのかを整理します。そのうえで、テスト要求分析、テストアーキテクチャ設計、テスト詳細設計、テスト実装というテスト開発プロセスを、具体と抽象の往復として見ていきます。 テストケースをたくさん作ることが、テスト設計ではありません。 テスト対象を理解し、重要なものを抽象化し、構造化し、必要十分な具体へ戻すこと。これが、今回考えたいテスト設計の本質です。 抽象は関係性を見抜く：逆・裏・対偶という見方 前回の記事では、抽象化されたパターンが直感を生み、思考を高速化するという話を書きました。 しかし、直感は便利である一方、見えている関係だけをそのまま信じてしまう危うさもあります。「この条件なら、きっとこうなるだろう」と思い込んでしまうからです。 そこでテスト対象を理解する上では、関係性そのものを形式として捉え直す視点が重要になります。その一つが、命題を「逆・裏・対偶」で捉える考え方です。 前回の記事で扱ったように、抽象化は単に「似ているものをまとめる」だけではありません。複数の事象に共通する関係性を取り出し、形式として扱うことも抽象化です。 仕様や要件の多くは、「もしこうなら、こうなるはずだ」という形で記述できます。これは論理の世界では、「PならばQである」という命題です。 元の命題：P ならば Q P：条件、操作、入力 Q：結果、状態、出力 逆：Q ならば P 裏：Pでない ならば Qでない 対偶：Qでない ならば Pでない こうして書くと、少し数学のように見えるかもしれません。しかし、実際にはかなり実務的な考え方です。 ログイン機能に当てはめる たとえば、ログイン機能に当てはめると、次のように整理できます。 論理 テスト観点 テスト例（ログイン機能） 元の命題（P → Q） 正常系テスト 有効なIDとパスワードでログインでき、マイページに遷移するか。 裏（Pでない → Qでない） 準正常系・異常系テスト IDまたはパスワードが間違っている場合に、ログインできないか。 逆（Q → P） 状態の正当性・セキュリティ ログイン状態になっているなら、正当な認証経路を通ったはずだと考え、URL直打ちやセッションの不正利用ができないか。 対偶（Qでない → Pでない） 原因の切り分け ログインできない場合、本当にIDやパスワードが無効なのか。それともサーバー障害など別の原因なのかを区別できるか。 ここで大事なのは、元の命題だけを見ていると、テスト観点がかなり限定されてしまうということです。 「有効なIDとパスワードならログインできる」という仕様だけを見ていると、正常系の確認で満足してしまいがちです。しかし、逆や裏や対偶まで視野を広げると、セッションの正当性、URL直打ち、ブラウザバック、エラーメッセージの妥当性、原因の切り分けなど、別の角度から仕様を見られるようになります。 つまり、ここで行っているのは、「ログイン」という機能を、単なる具体的な画面操作ではなく、「条件と結果の関係」という抽象モデルで捉え直すことです。 前回の記事で言えば、見た目の違いを超えて共通する構造を抜き出しているのと同じことです。 抽象モデルの便利さと限界 ただし、ここで注意が必要です。 ログイン失敗の原因は、IDやパスワードの妥当性だけとは限りません。サーバー障害、ネットワーク障害、外部認証基盤の問題など、別の要因もあります。 「サーバー起因か、ユーザー起因かを区別できるか」というテストは、先ほどの命題の枠組みの外側にある観点です。対偶の確認だけで、すべての原因を説明できるわけではありません。 このあたりに、抽象モデルの便利さと限界が両方表れています。 モデルは思考を整理してくれます。しかし、現実を完全には覆い尽くせません。前回の記事で引用したGeorge Boxの言葉、「すべてのモデルは間違っている、しかし有用である」が、ここでもそのまま当てはまります。 共通点と相違点を適切にどう掴むのか。どこまでを同じ構造として扱い、どこからを別物として扱うのか。 この判断が、抽象的に考えるコツなのだと思います。 テストは具体と期待を突き合わせる活動である ここまで、仕様や要件を関係性として抽象化する話をしました。では、そもそもなぜテストが必要なのでしょうか。 テストとは、目の前にある具体的なソフトウェアと、そこから期待される振る舞いを突き合わせる活動です。 たとえば、会議室予約システムであれば、利用者が実際に会議室を予約します。その結果、予約が登録され、予約完了が表示され、必要な情報が関係者へ伝わるかもしれません。これが、実際に起きたこと、つまり具体です。 一方で、テストをする前には、「この条件なら、この結果になるはずだ」という期待があります。 空いている会議室なら予約できる 予約済みの時間帯なら予約できない キャンセルした会議室は再び予約できる 権限のない利用者は他人の予約を変更できない これらは、現実の利用目的や仕様から取り出した、期待される振る舞いです。 具体的なソフトウェア ↓ 期待される振る舞い ↓ 一致しているかを確認する つまり、テストは単に画面を操作することではありません。実際に起きたことと、起きるはずだったことを比較することです。 テストはリスクを具体化する活動でもある テストのリソースは有限です。すべての入力値、組み合わせ、環境、ユーザー行動を確認することはできません。 そこで、「何を確認するか」を決める前に、「何が起きると困るのか」を考えます。 会議室予約システムであれば、同じ時間帯に二人が同じ会議室を予約できてしまうと、重要な会議を開催できなくなるかもしれません。 予約処理の不備 ↓ 重複予約が登録される ↓ 会議室を利用できない ↓ 業務に支障が出る この具体的な失敗の経路から、「予約の整合性」や「重複の防止」といった抽象的なテスト条件を取り出します。そして、その重要度に応じて、どこを厚く確認するのかを決めます。 テスト設計では、具体的な機能や利用場面からリスクを抽象化し、その抽象的なリスクを、具体的なテストへ戻していくのです。 テストを設計するまでのプロセスは、抽象度を変換する活動である テスト要求分析、テストアーキテクチャ設計、テスト詳細設計、テスト実装という流れは、単に活動を区切るためのものではありません。 それぞれ、異なる抽象度の問いを扱っています。 テスト要求分析：具体から抽象へ まず、実際の利用場面やシステムの構造を見ます。 利用者は何をしたいのか。どの失敗が困るのか。システムのどこが複雑なのか。 こうした具体的な事実から、「何を守るべきか」「何をテストすべきか」という抽象的なテスト条件やリスクを取り出します。 テストアーキテクチャ設計：抽象を構造へ 次に、抽象化したテスト条件を、どこで確認するのか整理します。 画面で見るのか、APIで見るのか、部品同士の連携で見るのか、システム全体で見るのか。どこを厚くし、どこを代表的な確認にとどめるのか。 ここでは、現実をそのまま写すのではなく、考えやすく、分担しやすい構造へ変換します。 テスト詳細設計：抽象から具体へ 構造が決まったら、テスト条件を具体的な値や操作へ落とし込みます。 「重複を防ぐ」という抽象的な条件を、同じ時間帯、部分的な重なり、隣接する時間帯など、具体的なパターンへ変換します。 すべてを組み合わせるのではなく、何を代表する値なのかを考えながら、必要十分な条件を選びます。 テスト実装・実行：具体へ着地する 最後に、選んだ条件を、前提データや操作手順、期待結果を含む実行可能な形へ落とし込みます。 ただし、ここで終わりではありません。実際に手順へ落としてみると、テストしにくい構造や、想定していなかった条件が見つかることがあります。 そのときは、手順だけでなく、上位のテスト条件や構造を見直します。 テスト実装は、抽象を具体へ着地させる工程であると同時に、具体を通じて抽象モデルを検証する工程でもあります。 このように考えると、テスト開発プロセスは単純な一方向の流れではありません。具体的な現実から抽象化し、その抽象を構造化し、再び具体的なテストへ落とし込みます。そして、実行によって得られた事実をもとに、また抽象へ戻ってモデルを見直します。 次に、このテスト設計全体を、具体と抽象の往復運動として整理してみます。 テスト設計全体は、抽象と具体の往復運動である ここまでをまとめると、ソフトウェアテストの各工程は、次のように見ることができます。 テスト要求分析：具体的な現実を観察し、テスト条件やリスクという抽象へ持ち上げる テストアーキテクチャ設計：その抽象を、整理棚や担当構造としてさらに構造化する テスト詳細設計：抽象的な条件を具体値へ落とし込みつつ、具体値を代表性という抽象で整理する テスト実装：具体的な手順へ着地させ、その実行可能性から上位の抽象モデルを見直す つまり、これは一直線の分解プロセスではありません。 具体 ↓ 抽象化 ↓ 構造化 ↓ 具体化 ↓ 実行 ↓ モデルの見直し 前回の記事で、分類学は多様な生き物に名前を与えることで、世界を理解しやすくしていると書きました。 ソフトウェアテストも同じです。 現実のシステムや要求は、そのままでは複雑すぎて扱えません。だから、リスク、条件、責務、レベル、パラメーター、担当、手順といった名前を与えて整理し、人間が扱える形に変えていきます。 しかし、分類学がそうであったように、その分類やモデルは現実そのものではありません。 実際のテスト対象に向き合い、テストを実装し、テストを実行する中で、モデルはまた見直されなければなりません。 だから、テスト設計の本質は、単にケースを作ることではないのだと思います。 具体と抽象を往復しながら、納得できるモデルを育てていくこと。 これが、テスト設計の本質です。 おわりに：テストケースの数ではなく、モデルの質を見る 今回は、ソフトウェアテストを具体と抽象の往復として捉え直しました。 テストでは、まず実際の利用場面やシステムの構造を観察します。そこから、利用者にとって重要なことや、起きると困ることを抽象化し、リスクやテスト条件として整理します。 そのうえで、抽象化した条件を、確認する場所や役割に割り当て、具体的な値や操作へと落とし込みます。最後に、実行可能なテストケースとして現実に戻します。 具体的な現実 ↓ リスクやテスト条件への抽象化 ↓ 確認する構造の設計 ↓ 具体的なテストケース ↓ 実行結果をもとにモデルを見直す この流れを意識すると、テストケースの数だけを見て、テストの良し悪しを判断することが難しいと分かります。 重要なのは、ケースが何件あるかではありません。 どのような利用目的に対応しているのか どのようなリスクを軽減するのか どのテスト条件から導かれたのか なぜその値や組み合わせを選んだのか どの場所やテストレベルで確認するのか 実行結果をもとに、上位のモデルを見直せるか こうしたことを説明できることが重要です。 たとえば、「会議室を予約できること」を確認するテストケースがあったとしても、それだけでは十分ではありません。 そのテストケースが、単に予約ボタンの動作を確認しているのか、それとも「利用者が確実に会議室を使える」という目的を確認しているのかによって、意味は変わります。 後者であれば、重複予約、権限、変更、キャンセル、同時操作、外部カレンダーとの連携など、別の具体的な条件も必要になるかもしれません。 つまり、テストケースは単独で存在するものではありません。 上位にある目的、リスク、テスト条件、構造とつながって初めて、意味を持った成果物になります。 一方で、モデルをつくったからといって、現実を完全に捉えられたわけでもありません。 実際にテストを実行すると、想定していなかった利用方法や、テストしにくい構造、抽象化の際にこぼれ落ちた条件が見つかることがあります。 そのときに必要なのは、テストケースを追加することだけではありません。 なぜそのケースが必要になったのかを考え、リスクやテスト条件、確認する構造そのものを見直すことです。 テスト設計の技術力とは、思いついた観点を並べることではありません。 具体的な現実から重要な構造を抜き出し、その構造を必要十分な具体へ戻し、実際の現物と突き合わせる力です。 そして、現実との突き合わせによって、抽象モデルを更新する力です。 テスト設計とは、ケースを増やし続ける作業ではありません。 具体と抽象を往復しながら、現実に耐えられるモデルを育てていくことです。 次回は、抽象度の高い仕事ほど責任の質がどのように変わるのかを考えてみます。 AIが具体的なコードやテストケースを生成するようになった今、QAエンジニアには何が求められるのでしょうか。キャリアが上がるにつれて、どのような抽象的なタスクが待っているでしょうか。 次回は、「抽象的なタスクと責任」をテーマに書いてみたいと思います。 【連載】具体と抽象を往復しよう！ 記事一覧 【第1回】分類学とアブストラクト（抽象化）〜AI時代を生き抜くための「思考の武器」〜 【第2回】分類学とアブストラクト（抽象化）〜「思考の武器」をテスト・QAの現場に活かす〜 【第3回】『具体と抽象』から見る、デザインと直感 【第4回】『具体と抽象』から見る、テスト設計 The post 【第4回】『具体と抽象』から見る、テスト設計 first appeared on Sqripts .

※ この投稿はお客様に寄稿いただいた記事です。 本稿では、株式会社NTTドコモ（以下、ドコモ）モバイルイノベーションテック部（以下、MIT 部）が AI-DLC（AI-Driven Development Lifecycle） の TTT（Train The Trainer）に参加し、フィジカル AI 領域における機械学習パイプラインを 3 日間で構築した取り組みについて、全 2 回に分けてご紹介します。 第 1 回：フィジカル AI 領域での ML 開発への適用（本記事） 第 2 回：2 チーム並行開発の実験結果と知見 1. はじめに ドコモの MIT 部ユースケース協創担当では、次世代技術の社会実装に向けた研究開発を推進しています。 私は、注目領域の一つであるフィジカル AI（現実世界で物理的に動作する AI）において、ロボットアームの動作学習を効率化するパイプラインの構築に取り組んでいます。 今回、AWS が提唱する AI-DLC の手法を活用し、模倣学習（IL: Imitation Learning）で獲得した動作知識を強化学習（RL: Reinforcement Learning）で自律的に改善していくパイプラインを 1 つのプロダクトとして捉え、その設計から実装までを AI-DLC のプロセスに沿って、チーム開発で 3 日間という短期間で構築・検証しました。 本記事（第 1 回）では、AI-DLC を ML 領域に適用するに至った私たちの理解と判断、そして Inception フェーズでの要件構造化と設計レビューの実践についてご紹介します。 2. 背景と課題 フィジカル AI における学習の課題 ロボットに動作を学習させるアプローチには、大きく分けて 2 つの方法があります。 模倣学習（Imitation Learning, IL） ：人間のデモンストレーションデータから動作を学習する。学習は安定するが、デモにない状況への汎化が難しい 強化学習（Reinforcement Learning, RL） ：試行錯誤を通じて報酬を最大化するように学習する。未知の状況にも対応できるが、ゼロからの学習はサンプル効率が低い 私たちが対象としたのは、SO-101 ロボットアーム（オープンソースの廉価な 6 軸卓上アーム）による「キューブを持ち上げる」タスクです。 本来模倣学習には 50 件程度のデモデータが推奨されますが、私たちは人手を最小限にしたいと考えており 10 件のデータを収集することから出発しました。模倣学習モデル（ACT: Action Chunking with Transformers）はこの 10 件で成功率 10% でしたが、NVIDIA の提供する COSMOS（物理法則を理解した映像生成によりデータを合成する World Foundation Model）や Mimic（少数のデモから大量の合成軌道を自動生成するデータ増幅フレームワーク）によるデータ増幅を適用したところ、成功率は 45% まで向上しました。しかし、デモデータ 10 件という母数では増幅の効果にも限界があり、改善は頭打ちになりました。 これ以上の改善にはデモデータの追加収集か、別のアプローチが必要です。私たちの目的は少ないデータでタスク成功率を上げることなので、データ収集を増やす方向ではなく、強化学習を組み合わせる方向を選びました。 採用手法：RPD（Refined Policy Distillation） この課題に対して、私たちは RPD（Refined Policy Distillation） 論文のアプローチを採用しました。 RPD は、大規模な模倣学習モデルの知識を軽量なポリシーに蒸留し、さらに強化学習で改善するフレームワークです。 RPD の基本的な流れは以下の通りです。 蒸留 ：大規模モデル（VLA 等）の動作知識を、軽量な MLP（Multi-Layer Perceptron）に教師あり学習で圧縮する PPO（Proximal Policy Optimization） Fine-tune ：蒸留済み MLP を初期ポリシーとして、KL ペナルティ付きの強化学習で改善する。KL（Kullback-Leibler）ペナルティは、元のモデルをオンラインで推論し、その出力を参照分布として「蒸留ポリシーから離れすぎない」よう制約をかける RPD 論文では、教師として大規模 VLA（Vision-Language-Action）モデルをリアルタイムで推論しながら KL ペナルティの参照分布に使います。一方、私たちの実装では VLA の代わりに ACT から蒸留した重み固定 MLP を参照分布として使用しました。この前提の違いが実験結果にどう影響したかは第 2 回で詳述します。 図：RPD 論文のアプローチ（上）と私たちの ACT への適用（下） ML 開発特有の課題 機械学習パイプラインの構築は、一般的なソフトウェア開発とは異なる課題を持っています。 不確実性が高い ：論文との細かな前提の差異などから、論文通りに実装しても動作する保証がない 専門知識が広範 ：強化学習の理論、シミュレータの仕様、座標系変換など複数のドメイン知識が必要 実験サイクルが長い ：仮説→実装→学習→評価のサイクルに時間がかかる これらの課題は、チームでの開発において「何を作るか」「なぜこの設計にするか」の共有コストを増大させます。 個人で AI と対話しながらコーディングを進める「Vibe Coding」のアプローチでは、こうした構造的な課題を 1 つ 1 つ対話の中で解消しても、その判断やコンテキストが流れてしまい蓄積されません。これでは個人でも知見の蓄積が難しいだけでなく、組織的な研究開発となるとさらに顕著な課題になるのではないかと考えました。 3. AI-DLC 理解と適用判断 AI-DLC とは何か AI-DLC は、AI を開発プロセス全体に組み込むためのフレームワークです。私たちは TTT を通じて、以下のように理解しました。 AI-DLC の核心は、AI が作業計画を体系的に作成し、人間が意思決定に集中する協働モデルです。具体的には以下のフェーズで構成されます。 Inception フェーズ ：ユーザーストーリーの定義、要件の構造化、設計レビュー。AI が専門知識を補完しながら、人間が「何を作るか」を決定する。Inception の最後で分けた Unit ごとに小規模なモブチームを形成する。 Construction フェーズ ：Unit ごとのモブチームが詳細設計、実装、テストを並行で進める。AI がコード生成を担い、人間がレビューと意思決定を行う。 Operation フェーズ ：デプロイ、運用への移行。 図：AI-DLC の3フェーズ 従来の「Vibe Coding」との違いは、チーム全体で共有可能な構造化ドキュメント（ユーザーストーリー、設計文書、レビューレポート）が生成される点です。これにより、AI と個人の間の暗黙知がチームの共有知に変わります。 なぜ ML 領域に適用したか AI-DLC の既存事例は Web サービスや業務アプリ開発が中心ですが、私たちは ML 開発への適用をチャレンジしてみました。理由は 3 つあります。 論文→実装のギャップを埋める ：研究開発では論文の手法を実装に落とし込む過程で、前提条件の違いや暗黙の仮定が問題になる。Inception フェーズで AI と対話しながら要件を構造化することで、これらの曖昧さを事前に可視化できるのではないかと考えました。 チーム学習の加速 ：私たちはフィジカル AI に取り組み始めたばかりのチームです。強化学習やシミュレータの専門知識は属人性が高いため、AI-DLC の構造化ドキュメントを通じて、チーム全員が同じ理解水準で議論できる環境を作れると考えました。 実験サイクルの管理 ：ML 実験は「仮説→実装→学習→評価→修正」のサイクルを高速に回す必要がある。AI-DLC のチェックポイント（Inception→Construction→Operation→評価）が、方針転換の判断基準を明確にすると考えました。 私たちは、要件の構造化と設計レビューというプロセスが、不確実性が高く前提条件の検証が必要な ML 開発に適応できるのではないかと考えました。本記事はあくまで ML 領域への適用事例として、私たちの TTT での経験と見解を中心にご紹介するものです。 4. AI-DLC TTT の概要 以上の背景を踏まえ、TTT で実際に取り組んだ内容をご紹介します。 テーマ設定 具体的な目標は以下の通りです。 人手によるデモデータ収集を最小限に抑えつつ、模倣学習によって習得したロボットアームの動作を、強化学習を用いて自律的にブラッシュアップしていくパイプラインを１つのプロダクトとして捉え構築する 参加者を 2 チーム（チームピンク、チームブルー）に分けました。 強化学習を最終段階とするパイプライン構造は共通ですが、ベースとなるモデルが模倣学習の直接的な出力ではなく RPD 論文に基づく蒸留を経由する設計であり、どのように変換を行うかは未検証でした。 そのため、チームごとでアプローチを決め並行して比較検証する方針としました。 両チームの設計判断の詳細は第 2 回でご紹介します。 事前準備 AI-DLC で効果的に開発を進めるために、以下を事前に準備しました。 学習データ ：ACT の実行から得た成功軌道データ 53 エピソード（蒸留の教師データとして使用。人手で収集した 10 件とは別に、ACT がシミュレーション上で成功した軌道を自動収集したもの） 参考論文 ： RPD 、 ACT 、 Knowledge Distillation 、 PPO の 4 本 設計概要ドキュメント ：環境差分、手法の設計思想、データ概要 Amazon EC2 インスタンス ：g6e.8xlarge（NVIDIA L40S 48GB）に Isaac Lab（NVIDIA が提供する GPU 並列ロボット学習シミュレーションフレームワーク）環境を構築済み 5. Inception フェーズ：要件構造化（Day 1） ML パイプラインをプロダクトとして AI-DLC のプロセスに載せた Inception フェーズの具体例を以下に示します。 Inception フェーズでは、フィジカル AI に関する論文や専門情報を Kiro に読み込ませ、要件の構造化とスコープ決定を行いました。 図：チームピンクの Inception の様子、右下に映っているのが SO-101 タスクリストの定義 Kiro との対話を通じて、4 つのタスクリストを定義しました。 表：タスクリスト一覧 # タスクリスト 優先度 TL-1 蒸留用データの準備（座標系変換+データ整形） 最高 TL-2 MLP の蒸留（教師あり学習） 高 TL-3 PPO Fine-tune（強化学習による改善） 高 TL-4 評価と比較（100 エピソード評価） 中 各タスクリストには具体的な受け入れ基準を設定しました。たとえば TL-1 では「座標変換後の joint_pos_rel の範囲が [-2.2, 1.5] 程度であること」「NaN/Inf が含まれていないこと」など、ML 特有の検証項目を含めています。 ユニット分割とデータフロー設計 パイプライン全体を 3 つの実装ユニットに分割し、データフローを設計しました。 なお、TL-4（評価）は Unit 3 の出力を受けて実行する工程として Unit 3 に含めています。 以下はチームピンクのデータフローとコンテキストマップです。 act_demos.npz (Amazon S3)：座標変換 + データ整形【Unit 1】 ↓ obs_flat (12次元) + act_flat (6次元)：教師あり学習（蒸留）【Unit 2】 ↓ distilled_mlp.pt：PPO Fine-tune (KLペナルティ付き)＋評価【Unit 3】 ↓ model_<iter>.pt：100エピソード実行【Unit 3】 ↓ evaluation_report.md 図：コンテキストマップ 図：データフロー（act_demos.npz → 座標変換 → 蒸留 → PPO → 評価） 設計レビューの効果 Inception フェーズではモブスタイル（Mob Inception）を採用し、チーム全員が Kiro を囲んで対話しながら設計を進めました。 この過程で Kiro が設計レビューを実施し、実装前に 11 個の不整合を検出しました。 モブスタイルと AI による支援の組み合わせにより、チーム内でのイメージのすり合わせと合意形成にかかる時間を短縮でき、実際にコードに反映できた点は、AI-DLC ならではの効果だと思いました。 発見された不整合の例： チェックポイント形式の不一致（RSL-RL が期待する actor/critic 分離形式との差異） 入力次元の食い違い（12D と 28D の混在） アクションスケールの不整合（環境間で /0.5 の変換が必要） これらを実装前に検出できたことで、Construction フェーズでの手戻りを削減できました。ML 実装では「コードが動くが出力が正しくない」という不具合が起きやすいため、設計段階での整合性チェックは価値が高いと実感しました。 第 1 回のまとめと次回予告 本記事では、AI-DLC をフィジカル AI（ML）領域に適用するに至った私たちの理解と判断、そして Inception フェーズでの要件構造化と設計レビューの実践についてご紹介しました。 Inception フェーズだけで、設計レビューにより 11 個の不整合を検出し、30 以上の構造化ドキュメントを生成しました。 第 2 回 では、Construction フェーズでの 2 チーム並行開発の実験結果をご紹介します。チームブルーが当初スコープの断念から AI-DLC のフレームに従って軌道修正し成果を出したエピソードや、蒸留初期化についての知見についてお伝えします。 著者について 株式会社NTTドコモ 片岡 敬志郎 株式会社NTTドコモ R&D イノベーション本部 モバイルイノベーションテック部 ユースケース協創担当 フィジカル AI、ロボティクス領域における研究開発と社会実装を推進。AI-DLC TTT のテーマ選定を担当し、R&D 組織への AI-DLC 展開を推進中。

こんにちは。Yahoo!検索のフロントエンドエンジニアの山本です。普段は Yahoo!検索の開発と運用を行っています。そのかたわら、Coding Agent を使った開発自動化と AI 活用、チームへ...