NTTドコモ モバイルイノベーションテック部における AI-DLC 実践（第2回）：2チーム並行開発の実験結果と知見

※ この投稿はお客様に寄稿いただいた記事です。

本稿は、NTTドコモ モバイルイノベーションテック部（以下、MIT 部）が AI-DLC TTT でフィジカル AI 領域の ML パイプラインを構築した取り組みの第 2 回です。

第 1 回では、AI-DLC の Inception フェーズで要件を構造化し、設計レビューで 11 個の不整合を事前に検出した取り組みをご紹介しました。
第 2 回では、Construction フェーズでの 2 チーム並行開発の実験結果と、得られた知見についてご紹介します。

6. Construction フェーズ：パイプラインの実装（Day 2–3）

Inception フェーズで作成した計画に沿って実装を進めました。
両チームとも同一のパイプライン構造を採用しつつ、細部の設計判断に違いが生まれました。

共通アーキテクチャ

両チームが構築したパイプラインの基本構造は以下で共通です。

図：データフロー（act_demos.npz → 座標変換 → 蒸留 → PPO → 評価）

蒸留 MLP の検証 MSE（Mean Squared Error）< 0.01 を両チームとも達成し、Isaac Lab 上での 1024 並列環境による PPO 学習を実行しました。これにより、パイプライン全体（蒸留→PPO→評価）が一通り接続された状態に到達し、以降はパイプラインの構築ではなく成功率の改善に集中できる段階になりました。

チーム間の設計判断の分岐点

テーマ設定の段階で、強化学習を最終段階とするパイプライン構造は共通ですが、ベースとなるモデルが模倣学習の直接的な出力ではなく RPD 論文に基づく蒸留を経由する設計であり、どのように変換を行うかは未検証でした。Inception フェーズに用いた論文などの事前知識でパイプラインの基本構造（蒸留→PPO→評価）までは両チーム共通でしたが、蒸留の入力次元や KL ペナルティの扱いについては複数の有力なアプローチが考えられ、机上では優劣を判断できませんでした。

そこで、それぞれのチームメンバーが AI-DLC の中で判断したアプローチを採用し、実験結果を比較検証する方針としました。全く同じとなる可能性もありましたが、今回は以下のような差異が生まれました。

KL ペナルティの β は、蒸留で得た方策をどの程度信頼するかを制御するハイパーパラメータです。
β が大きいほど蒸留ポリシーからの逸脱にペナルティを強くかけ、小さいほど自由に探索できます。
チームピンクは β=1.0（強い制約）、β=0.5（中程度）、β=0（制約なし）の 3 段階で効果を検証しました。

チームブルーの「部分ロード方式」というのは、蒸留 MLP（12 次元入力）の重みを RSL-RL（Isaac Lab 上で強化学習を行うライブラリ）の ActorCritic（行動出力と価値推定を担うネットワーク構造）における第 1 層の重み行列（256 ニューロン × 28 次元入力）の最初 12 列にコピーし、残り 16 列はランダム初期化のまま学習させます。環境の全観測情報を活用しつつ、蒸留知識を初期値として活かすアプローチです。

7. AI-DLC による軌道修正：チームブルーのスコープ変更

Construction フェーズで、AI-DLC の価値が明確に現れた場面がありました。

チームブルーは当初、ACT モデルの学習からデモ収集までを含む、より上流からのパイプライン構築を目指していました。しかし Day 2 の実装開始直後、ACT 学習環境のセットアップに想定以上の工数がかかることが判明しました。3 日間という制約の中で、ACT の環境構築に時間を費やすとコアの蒸留→PPO→評価パイプラインの検証が間に合わないリスクが生じたのです。

この時点で、AI-DLC のプロセスに従い Inception フェーズに立ち戻りました。タスクリストの優先度を再評価し、以下の判断を行いました。

この軌道修正がスムーズだったのは、要件がタスクリストとして構造化されていたからです。「何を削って何を残すか」の判断基準が各タスクリストの優先度として明示されており、チーム全員が同じ根拠で合意できました。具体的には、TL-1（データ準備）が最高優先度であり事前収集済みデータ（53 エピソード）で着手可能である一方、ACT 学習は優先度が低くこの事前データで代替可能だったため、ACT 学習を除外するという判断に至りました。場当たり的な「間に合わないから削ろう」ではなく、構造化された優先度に基づく意思決定です。

結果として、チームブルーはコアパイプラインに集中し、蒸留あり/なしの比較実験（64% vs 90%）という本 TTT で最も価値のある知見を得ることに成功しています。

8. 実験結果：2 チームの比較

両チーム共通の比較基準として、ACT ベースライン（模倣学習のみ、人手デモ 10 件＋COSMOS,Mimic による増幅）の成功率は 45% です。

チームピンク：KL ペナルティの段階的検証

KL ペナルティの有無と強度を変えた 3 回の実験を実施しました。

チームピンクの成功率が全条件で著しく低かった主因は、後に判明した座標変換の欠落（object_pos のロボットベース相対変換が未実装）でした。蒸留の教師データと RL 環境の座標系が一致していなかったため、蒸留 MLP が誤った方策を学習し、KL ペナルティがその誤りをさらに固定化する結果となりました。TTT 後にこの座標変換を修正し 97% に到達した詳細は後述します。

チームブルー：蒸留あり/なしの比較

RSL-RL をデフォルト設定に委譲し、蒸留初期化の有無を直接比較しました。

2 チームの結果が示す知見

1. 蒸留初期化は reaching（接近）を加速するが、lifting（持ち上げ）への移行を阻害する局所最適を生む
2. KL ペナルティは、蒸留ポリシーが偏った方策を学習している場合、探索を制限し逆効果になる
3. 蒸留初期化自体が性能を制限する可能性がある（蒸留なし 90% vs 蒸留あり 64%）
4. RPD 論文の前提（オンライン VLA 推論）を私達の実装（重み固定 MLP）に上手く適応できていない

今回の結果は単一タスク、単一条件での実験であり、RPD の手法自体の評価を確定するものではありません。しかし、2 チームが異なる実験設計（KL の段階的緩和 vs 蒸留あり/なしの直接比較）で同じ傾向を観測したことは、今後の検証を進める根拠にはなると考えています。

9. AI-DLC を ML に適用して得られた知見

方針転換と失敗の蓄積を支えるプロセス

各フェーズ（Inception、Construction、Operation、評価）で成果物が定義されているため、方針転換の判断が容易でした。チームブルーの軌道修正はその好例です。

設計レビューにより、実装前に 11 個の不整合を検出できました。ML 実装では「動くが正しくない」コードが生まれやすく、設計段階での整合性検証が手戻りの防止に直結します。

3 回の実験サイクルと失敗分析はすべて構造化ドキュメントとして残り、次の実験の判断根拠として蓄積されました。

実験サイクルの高速化

Kiro が論文の解釈や数式の意味を解説することで、強化学習、蒸留、Isaac Lab、RSL-RL といった専門領域の理解がチーム全員で揃いました。

この共有された理解が、実験サイクルの速度に直結しています。初回の失敗分析から修正、2 回目のパイプライン実行までが数時間で完了しました。速さの要因は 2 つあります。

• Inception で実験の仮説と検証基準がドキュメント化されており、「何を変えて次を試すか」の起点が明確だったこと
• パイプライン全体の構造と各ユニットの役割を全員が把握しており、原因の切り分けと修正方針の合意に時間がかからなかったこと

一般的な ML 実験では仮説の修正から再実験まで数日かかることが多いですが、今回は 1 日で 3 サイクル回すことができました。

ドメイン専門家の役割をどう位置づけるか

Kiro の支援により、ドメイン専門家がいないチームでも動作する ML パイプラインの構築まで到達できました。

一方で、「なぜこの手法がこのタスクで機能しないか」を正確に評価する局面や、RPD 論文の前提条件と実装の差異を見抜く局面では、深い理論的理解が必要でした。Kiro が出力したコードの妥当性を判断できない場面が繰り返し発生し、ML 実装の経験が浅い私たちにはかなり負荷が高かったのが実情です。

この経験から、AI-DLC は「専門家がいないと着手できない」状態を「専門家なしでもパイプラインを構築でき、専門家は品質の最終確認に集中する」状態に変えるフレームワークだと捉えています。AI が論文解釈、コード生成、設計レビューを担うことでチームの知識水準が引き上げられ、専門家がレビューすべき範囲が絞り込まれます。

Inception で生成された設計レビューレポートや実験分析レポートを専門家に共有すれば、常駐せずスポット参加でも的確なフィードバックが可能です。今回の座標変換の問題も、TTT 後に構造化された記録を読み返すことで数時間で原因を特定できました。

今後は、Inception で定義した受け入れ基準（座標値の範囲、入力次元の整合性、損失の収束条件など）を自動テストとして実装し、パイプラインの各段階で機械的に検証する仕組みを導入する予定です。ドメイン知識を実行可能なテストコードに変換すれば、専門家が不在でも品質の劣化を早期に検出できます。

（参考）TTT 後：AI-DLC の継続で 97% へ

TTT は 3 日間で終了しましたが、AI-DLC のプロセスは継続可能です。TTT 後に得られた結果を補足します。

座標変換の欠落が真因だった

TTT 後、構造化された実験記録を読み返し Inception に立ち戻りました。最優先だった TL-1（座標系変換）の実装を再検証したところ、object_pos の座標変換が欠落していることが判明しました。

ACT のデモデータは LeIsaac のワールド座標系で記録されている一方、RL 環境はロボットベース相対座標系を使用しています。この不一致が蒸留 MLP の学習を破綻させていました。

# 欠落していた変換（修正版で追加）
object_pos -= [0.35, -0.64, 0.01]  # LeIsaacのロボットベース位置

構造化された実験記録があったため、原因の切り分けは数時間で完了しました。

再蒸留の実装と結果

座標変換の修正に加え、TTT 中の観察（reaching は学習するが lifting が伸びない）に基づき、損失関数を Phase-weighted MSE に変更しました。lifting フェーズの重みを 5 倍にしています。

再蒸留を初期重みにロードし、KL なし PPO で 5000 イテレーション（1024 環境並列、約 52 分）を実行した結果です。

再蒸留 + PPO は RL-Only（90%）を統計的に有意に上回りました（Fisher’s exact test, p=0.049）。

TTT 中に得た「蒸留初期化は逆効果」という結論は、座標変換バグに起因する誤りでした。前処理が正しければ、蒸留初期化は PPO の収束を加速し、最終成功率も向上させます。

構造化された記録が継続を可能にする

TTT 後 1 日で 97% に到達できたのは、3 日間の実験記録、失敗分析、設計文書が構造化ドキュメントとして残っていたからです。コンテキストが消えず蓄積されること、失敗が次のサイクルの出発点になることが、AI-DLC を ML 実験に適用する最大の利点でした。

10. 成果と今後の展望

3 日間の定量的成果

今後の展望

技術面では、蒸留データ品質の改善、実機（SO-101）への Sim-to-Real Transfer を計画しています。

プロセス面では、他チームへの AI-DLC プロセス展開、ML 実験における設計レビューテンプレートの標準化を進めます。

著者について