※ この投稿はお客様に寄稿いただいた記事です。 本稿は、NTTドコモ モバイルイノベーションテック部（以下、MIT 部）が AI-DLC TTT でフィジカル AI 領域の ML パイプラインを構築した取り組みの第 2 回です。 第 1 回：フィジカル AI 領域での ML 開発への適用 第 2 回：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 の中で判断したアプローチを採用し、実験結果を比較検証する方針としました。全く同じとなる可能性もありましたが、今回は以下のような差異が生まれました。 設計判断 チームピンク チームブルー パイプライン起点 事前収集済みデモデータ（53 エピソード） ACT 学習→デモ収集から（後述の軌道修正あり） 蒸留 MLP 入力次元 28 次元（環境の全観測空間） 12 次元 → Actor 28 次元入力層の最初 12 列に部分ロード PPO への統合方式 蒸留 MLP 全体を Actor としてロード Actor 入力層の最初 12 列に蒸留重みをコピー、残り 16 列はランダム初期化 KL ペナルティ あり（adaptive β方式、3 パターン検証） なし（RSL-RL デフォルト設定に委譲） 検証の焦点 KL ペナルティの効果検証 蒸留初期化の効果そのものの検証 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 蒸留用データの準備（ACT 学習→デモ収集を含む） 「ACT 学習→デモ収集」を除外。事前収集済みデモデータ（53 エピソード）を起点に変更 TL-2 MLP の蒸留 維持 TL-3 PPO Fine-tune 維持 TL-4 評価と比較 維持 この軌道修正がスムーズだったのは、要件がタスクリストとして構造化されていたからです。「何を削って何を残すか」の判断基準が各タスクリストの優先度として明示されており、チーム全員が同じ根拠で合意できました。具体的には、TL-1（データ準備）が最高優先度であり事前収集済みデータ（53 エピソード）で着手可能である一方、ACT 学習は優先度が低くこの事前データで代替可能だったため、ACT 学習を除外するという判断に至りました。場当たり的な「間に合わないから削ろう」ではなく、構造化された優先度に基づく意思決定です。 結果として、チームブルーはコアパイプラインに集中し、蒸留あり/なしの比較実験（64% vs 90%）という本 TTT で最も価値のある知見を得ることに成功しています。 8. 実験結果：2 チームの比較 両チーム共通の比較基準として、ACT ベースライン（模倣学習のみ、人手デモ 10 件＋COSMOS,Mimic による増幅）の成功率は 45% です。 チームピンク：KL ペナルティの段階的検証 KL ペナルティの有無と強度を変えた 3 回の実験を実施しました。 条件 成功率 累積報酬 備考 蒸留初期化 + PPO + Full KL (β=1.0) 0% -6.72 std 減少を阻害、探索不能 蒸留初期化 + PPO + Mean-only KL (β=0.5) 0% 2.05 探索の早期停止 蒸留初期化 + PPO（KL なし） 11% 1.82 局所最適に陥る チームピンクの成功率が全条件で著しく低かった主因は、後に判明した座標変換の欠落（object_pos のロボットベース相対変換が未実装）でした。蒸留の教師データと RL 環境の座標系が一致していなかったため、蒸留 MLP が誤った方策を学習し、KL ペナルティがその誤りをさらに固定化する結果となりました。TTT 後にこの座標変換を修正し 97% に到達した詳細は後述します。 チームブルー：蒸留あり/なしの比較 RSL-RL をデフォルト設定に委譲し、蒸留初期化の有無を直接比較しました。 条件 成功率 累積報酬 備考 蒸留初期化 + PPO（部分ロード） 64% 56.69 蒸留 12 次元→Actor28 次元に統合 ランダム初期化 + PPO（蒸留なし） 90% 84.44 蒸留なしが最高性能 2 チームの結果が示す知見 蒸留初期化は reaching（接近）を加速するが、lifting（持ち上げ）への移行を阻害する局所最適を生む KL ペナルティは、蒸留ポリシーが偏った方策を学習している場合、探索を制限し逆効果になる 蒸留初期化自体が性能を制限する可能性がある（蒸留なし 90% vs 蒸留あり 64%） 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 分）を実行した結果です。 条件 成功率 ACT ベースライン（模倣学習のみ） 45% RL-Only（蒸留なし、ランダム初期化） 90% 再蒸留 + PPO 97% 再蒸留 + PPO は RL-Only（90%）を統計的に有意に上回りました（Fisher’s exact test, p=0.049）。 TTT 中に得た「蒸留初期化は逆効果」という結論は、座標変換バグに起因する誤りでした。前処理が正しければ、蒸留初期化は PPO の収束を加速し、最終成功率も向上させます。 構造化された記録が継続を可能にする TTT 後 1 日で 97% に到達できたのは、3 日間の実験記録、失敗分析、設計文書が構造化ドキュメントとして残っていたからです。コンテキストが消えず蓄積されること、失敗が次のサイクルの出発点になることが、AI-DLC を ML 実験に適用する最大の利点でした。 10. 成果と今後の展望 3 日間の定量的成果 カテゴリ 成果物 コード distill.py (~400 行), train_finetune.py (~500 行), evaluate.py (~450 行) — 合計 1,350+ 行 実験 蒸留チェックポイント, PPO 学習結果 (3 Runs + 蒸留あり/なし比較), 100 エピソード評価 ドキュメント タスクリスト, ユニット分割計画, 設計レビューレポート, 実験分析レポート — 計 30+ 文書 今後の展望 技術面では、蒸留データ品質の改善、実機（SO-101）への Sim-to-Real Transfer を計画しています。 プロセス面では、他チームへの AI-DLC プロセス展開、ML 実験における設計レビューテンプレートの標準化を進めます。 著者について 株式会社NTTドコモ 片岡 敬志郎 株式会社NTTドコモ R&D イノベーション本部 モバイルイノベーションテック部 ユースケース協創担当 フィジカル AI、ロボティクス領域における研究開発と社会実装を推進。AI-DLC TTT のテーマ選定を担当し、R&D 組織への AI-DLC 展開を推進中。

※ この投稿はお客様に寄稿いただいた記事です。 本稿では、株式会社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 展開を推進中。

2026年9月16日、Elastic Cloud Serverless の Cross-Project Search（CPS：クロスプロジェクト検索） が正式提供（GA）になりました。 CPS を使うと、複数の Serverless プロジェクトをリンクできます。データを1か所に集約することなく、複数のプロジェクトを横断して検索できる機能です。 目次 Cross-Project Search の利点 設定はシンプル 仕組み：Origin Project と Linked Project GA で特に注目したいポイント Security では Central SOC の構成が可能に Origin Project は専用に作るのがおすすめ 日本で利用する場合 まとめ 参考資料 Cross-Project Search の利点 Elastic Cloud Serverless では、用途、組織、リージョンなどに応じて環境を複数の「プロジェクト」に分けます。たとえば、次のような構成です。 東京と海外リージョンでデータを分ける 顧客や部門ごとに Security プロジェクトを分離する 本番環境とステージング環境を分ける 環境を分ければ分離は保てます。しかし複数のプロジェクトをまとめて調査したいという場面では、それぞれのプロジェクトを個別に確認する必要がありました。CPS は、この課題を解決します。 設定はシンプル CPS は、Elastic Cloud の画面からプロジェクトをリンクして利用します。従来の Cross-Cluster Search（CCS）のように、接続先ごとの証明書やリモートクラスターを個別に設定する必要はありません。 Cloudのホーム画面 → OriginにしたいProjectの  Manage を選択します。 左サイドバーの Serverlessから Cross-project search をクリックし、Get started with cross-project search画面からLink projectsをクリックします。 リンクできる一覧が表示されますので選択したいプロジェクトのボックスにチェックを入れます。リンク後は、Discover、ES|QL、Dashboard、Alerting などから Linked Project のデータを検索できます。 仕組み：Origin Project と Linked Project CPS では、1つの Origin Project （起点となるプロジェクト ） から、複数の Linked Project を検索します。 リンクできるのは、同じ Elastic Cloud Organization 内の Serverless プロジェクトです。プロジェクト自体は、異なるリージョンやクラウドプロバイダーに配置されていても構いません。 この仕組みによって、データの配置や環境の分離を維持したまま、必要なときだけ横断して検索できます。 GA で特に注目したいポイント 今回の GA では、1つの Origin Project から標準で最大 100 の Linked Project を扱えるようになりました。 また、既存の Serverless プロジェクトを Origin Project として利用できます。機械学習と Agent Builder も Cross-Project Search に対応しました。 特に Agent Builder では、AI Agent が1つのプロジェクトだけを見るのではなく、複数の Serverless プロジェクトから必要なコンテキストを取得する構成が可能になります。たとえば、地域や部門ごとにログを別プロジェクトへ保存しながら、中央の AI Agent から横断的に調査する、といった使い方が考えられます。 Security では Central SOC の構成が可能に Security では、中央の Origin Project に Detection Rule を置き、複数の Linked Project にあるデータを対象として検知する構成が可能です。リージョンや組織ごとに Security プロジェクトを分離しながら、中央の SOC から横断的に監視・調査できます。 一方で、現時点ではすべての Security 機能が完全に横断化されるわけではありません。Linked Project 側の Detection Rule が独自に生成したアラートは、Origin Project の Alerts 画面には表示されません。Attack Discovery も、Origin Project で生成されたアラートを対象とします。 そのため Central SOC や MSSP のような構成では、どこでデータを保持するかだけでなく、どのプロジェクトで Detection Rule を実行し、アラートを生成するかまで含めた設計が重要になります。 Origin Project は専用に作るのがおすすめ GA では、既存の Serverless プロジェクトを Origin Project として利用できるようになりました。ただし Elastic の公式ドキュメントでは、多くの構成で 新しい空の Overview Project を作り、そこを Origin Project として利用する Hub-and-Spoke 型の構成 が推奨されています。 理由は、稼働中のプロジェクトを Origin にすると、そのプロジェクトですでに利用している Dashboard や Alerting Rule などが、Linked Project のデータまで対象にする可能性があるためです。特に Detection Rule では、意図していなかったデータまで評価されることで、誤検知が増える可能性があります。 複数プロジェクトを横断するための専用プロジェクトを用意する、と考えるとイメージしやすいでしょう。 日本で利用する場合 2026年9月時点で、Elastic Cloud Serverless では AWS の東京リージョン（ap-northeast-1）と GCP の東京リージョン（asia-northeast1）を利用できます。Microsoft Azure の Serverless については、現時点の提供リージョン一覧に日本リージョンは含まれていません。 また、Observability と Security のプロジェクトで Cross-Project Search を利用する場合は、 Complete tier が必要です。 まとめ Cross-Project Search のポイントは、「環境は分けたまま、必要なときだけ横断して検索できる」ことです。 リージョン、組織、顧客などの理由で Serverless プロジェクトを分離しながら、中央の SOC や Observability 環境、AI Agent から複数プロジェクトのデータを横断して利用できます。 Central SOC、複数リージョンの Observability 環境、分散したデータを参照する AI Agent を設計する際に、押さえておきたい Elastic Cloud Serverless の機能です。 参考資料 本記事では、Cross-Project Search の概要と、設計時に特に押さえておきたいポイントに絞って紹介しました。対応機能の詳細、設定手順、プロジェクトルーティング、アクセス制御、API、料金体系などについては、以下の Elastic 公式情報をご確認ください。 Elastic 公式ブログ「Elastic announces GA of cross-project search on Serverless」 GA で追加された機能や主なユースケース、料金の概要を確認できます。 https://www.elastic.co/blog/cross-project-search-elastic-serverless-ga Elastic 公式ドキュメント：Cross-Project Search の設定 Origin Project / Linked Project の構成、Security での制約、推奨アーキテクチャ、権限設定など、実際に利用する際の詳細を確認できます。 https://www.elastic.co/docs/deploy-manage/cross-project-search-config Elastic Cloud Serverless の提供リージョン AWS、Google Cloud、Microsoft Azure で利用可能な Serverless リージョンの最新情報を確認できます。 https://www.elastic.co/docs/deploy-manage/deploy/elastic-cloud/regions The post Elastic Cloud Serverless の Cross-Project Search がGAに first appeared on Elastic Portal .