このブログは、東海旅客鉄道株式会社（以下、JR 東海）中央新幹線推進本部 リニア開発部 藤原 海渡氏と、アマゾン ウェブ サービス ジャパン合同会社 カスタマーソリューションマネージャー 西部 信博、プロフェッショナルサービス本部 正村 雄介、森田 和真による共著です。 1. はじめに JR 東海では、中央新幹線の保守・運用として、山梨リニア線において超電導リニアの電気設備保守の省力化・高度化を進めています。本活動の一環として、状態監視保全（Condition Based Maintenance、以下 CBM）の実現を目的に、AWS 上に IoT プラットフォームを段階的に構築してきました。機械学習の運用（MLOps）も IoT と切り離さず、この IoT プラットフォームの中に統合する方針としています。変電所・開閉所・トンネル区間など設置環境が多様な拠点に、エッジコンピュータやセンサデバイスといった種類の異なる IoT 機器が分散して設置される中で、構成情報を継続的に把握し遠隔から運用していくことが、保守業務の品質を左右する重要なテーマになっています。 本記事では、IoT プラットフォームの概要と構築にあたっての工夫点や得られた知見についてご紹介します。 2. 全体像 2-1. 本システムで実現したいこと（論理アーキテクチャ） IoT プラットフォームで実現したいのは、現地に出向かなくても設備の状態をデータで捉え続けることです。具体的には、次の能力を備えることを目指しました。 機器のメーター情報をデジタル化して取り込み 動作音や電流値をもとにした設備状態の数値化 メーター情報や各種計測情報を統合した状態把握 2-2. 構築した AWS アーキテクチャ（物理アーキテクチャ） 電気設備保守における IoT プラットフォームでは、多様な拠点に設置された IoT デバイスから設備のデータを取得し、エッジで処理した結果と必要なデータのみをクラウドに連携する構成としています。 エッジとクラウドにまたがる IoT システムでは、現場での即時処理とクラウドでの一元管理を両立させる構成が鍵になります。本アーキテクチャでは、 AWS IoT Greengrass がエッジ側の処理ランタイムとして現場固有の推論・前処理を担い、 AWS IoT Core がそのエッジとクラウドをつなぐ通信のハブとなります。クラウド側では AWS IoT SiteWise が設備データをモデル化して時系列で管理し、 Amazon SageMaker AI がエッジ推論向けの異常検知モデルの学習を担います。これらのマネージドサービスを組み合わせることで、通信・運用基盤そのものの開発を最小化し、設備保守の本質的な作り込みに集中できる構成になっています。 この IoT プラットフォームの設計思想は、「処理はできる限りエッジに寄せ、設備も機器も同じ階層モデルで構造化し、その構成を一元的に運用し続ける」 という点に集約されます。以降の 3 つの工夫は、いずれもこの思想を具体化したものです。 3. 工夫①：エッジ処理を中心とした状態監視システムの構築 実装に落とすうえで、まず向き合ったのがデータ取得と通信の制約です。電気設備の状態を正しく捉えるには高いサンプリングデータ・カメラ画像・動作音などが必要ですが、これらをそのままクラウドへ転送すると、通信回線の制約・通信コスト・クラウド側の処理負荷のいずれもが課題となります。 通信量の最適化（3-1）とエッジでの機械学習推論（3-2）という 2 つのアプローチで、この課題に取り組みました。 3-1. エッジ処理と通信量の最適化 Greengrass のコンポーネントとして、カメラ画像からのメーター値読み取り、動作音の特徴量抽出、機械学習モデルによる異常推論などを実装し、クラウドには集計値・推論結果と必要最小限の分析用データだけを送る構成としています。 また、標準コンポーネントに加え、現場固有の処理（カメラ機種ごとの画像切り出しやノイズ除去など）をプライベートコンポーネントとして実装することで、デバイスや設置環境ごとに柔軟な処理を実現しました。 3-2. 機械学習モデルの構築とエッジへのデプロイ 状態監視の中核は、設備の異常検知モデルをエッジ上で推論実行することです。モデルを Amazon SageMaker AI で学習・構築し、オープンソースの ONNX （Open Neural Network Exchange）形式へ変換したうえで、 Greengrass コンポーネントとしてエッジにデプロイしています。これによりモデルを軽量化し、計算資源の限られたエッジコンピュータ上でも無理なく推論を実行できる構成を実現しました。 4. 工夫②：多様な拠点・設備・機器のモデル化 中央新幹線では、監視対象となる拠点・設備が多様であり、それを監視するエッジ構成（IoT 機器やネットワーク）もまた多様になります。そこで 、これらの多様な設備や機器群を共通の構造（モデル）に落とし込み、保守員が一貫した方法で管理できるようにすることを目指しました。 4-1. 拠点・設備のモデル化 拠点・設備は、 AWS IoT SiteWise の Asset Model を活用し、「エリア」→「拠点」→「設備」という階層構造でモデル化しています。これにより、保守員は監視ダッシュボード上で拠点や設備種別を横断して状態を俯瞰したり、特定の設備にドリルダウンしたりといった操作を、共通の枠組みで行えるようになりました。 4-2. エッジ構成のモデル化 エッジ構成は、ネットワーク機器・コンピュータ・センサといった種別に分類したうえで、各機器のハードウェア構成（CPU・メモリや、NIC・USB などの外部接続インターフェース）を共通の属性としてモデル化しています。ネットワーク構成についても、NIC や USB を介した機器間の接続関係としてモデル化し、物理配置は階層的な属性（エリア／拠点／ゾーン／フロア／詳細位置）として表現しています。 5. 工夫③：IoT 機器と機械学習モデルの一元管理・自動運用 拠点とデバイスの数が増えるにつれ、運用上の最大の課題となったのが、モデル化した構成を実体に合わせて正確に把握し続けることです。 以下のようなオペレーションを行うには、正確な構成情報が不可欠です。 ソフトウェアの一括更新 機器のリプレース IP アドレス管理 新規拠点の構築 こうした情報を台帳と現場の作業記録に頼って管理すると、機器が増えるほど負担も増し、台帳と実機の乖離も広がっていきます。そこで 、これらの構成情報を一元管理する仕組みを新たに構築しました。 5-1. 構成情報の自動収集と一元管理 IoT 機器の構成を、実値で最新化し続ける仕組みとして IoT 構成管理システムを構築しました。エッジの構成情報を自動で集約し、機器の物理配置情報も紐付けることで、一元管理を実現しました。 IoT 構成管理システムのアーキテクチャ IoT 構成管理システムは Web アプリケーションとして実装しました。バックエンドは AWS AppSync による GraphQL API と Amazon DynamoDB で構成し、フロントエンドは Next.js で実装して AWS Amplify Hosting でホスティングしています。サーバーレスのマネージドサービスと、Next.js をはじめとする既成のフレームワーク・コンポーネントを最大限に活用したことで、少ない実装コストで素早く立ち上げられました。インフラの運用負荷を抑えられる点も、少人数での継続運用に寄与しています。 エッジ構成の自動収集 構成管理で主となる課題は、機器の構成を実体に合わせて常に同期し続けることです。OS バージョン、 Greengrass の外で動くネイティブアプリケーション、ネットワーク情報まで含めてエッジの構成全体を収集対象としたのが特徴です。これらを集める「構成情報収集機能」を Greengrass コンポーネントとして実装し、 AWS IoT Core 経由でクラウドへ送信して構成管理データベースを定期的に最新化することで、エッジの構成を一元的に把握できるようにしました。これにより、保守員は台帳と実機の乖離を心配することなく運用できます。 5-2. 機械学習モデルのビルド自動化と運用効率化 電気設備の異常検知では、設置環境によってデータの特性が異なるため、設備ごとに特化したモデルの方が精度を得やすい一方、運用面では多数のモデルのライフサイクル管理が新たな課題となります。 そこで 、 Amazon SageMaker Pipelines による学習パイプラインと、 AWS Step Functions による Greengrass コンポーネントへのビルドパイプラインを組み合わせ、学習から配信までの各作業を自動化しています。学習 – ONNX 化 – コンポーネント化 – 配信までを一連の流れとしてスムーズに回せるようにしました。 また、学習済みモデル自体を Greengrass コンポーネントとして扱うことで、IoT 機器のソフトウェア構成管理の枠組みにそのまま乗せられるようにし、IoT と機械学習を別管理にしない運用を実現しています。 6. Professional Services との伴走による内製化の推進 本取り組みは、リニア開発部と AWS Professional Services が伴走する形で進めてきました。週次のスプリントで要件整理・設計・プロト開発・QA を協働で行うことで、リニア開発部のメンバーが IoT・機械学習・Web アプリケーションそれぞれの実装ノウハウを段階的に獲得することができ、開発スピードと内製化の両立につながっています。 リニア開発部自身が運用と改善を主導できる体制を作るうえで、伴走型の開発スタイルは非常に有効でした。 7. まとめ JR 東海では、中央新幹線の将来運用を見据えた電気設備保守の高度化に向け、IoT プラットフォームを段階的に構築・拡充してきました。この取り組みは、次の 3 つの柱に支えられています。 エッジ処理を中心とした状態監視システムの構築（通信量最適化＋エッジでの機械学習推論） 多様な拠点・設備・機器のモデル化（設備データ＋機器／ネットワーク／接続関係） IoT 機器と機械学習モデルの一元管理・自動運用（構成管理＋MLOps） 今後は、将来の営業線運用に向けて、生成 AI を活用した開発・運用ナレッジの継承支援機能追加を検討しています。IoT と機械学習を横断する高度な専門知識を組織に定着させ、現場作業や障害対応の場面で必要なナレッジに素早くアクセスできる環境を整えることを目指しています。 おわりに 本ブログでご紹介した JR 東海の取り組みや関連する AWS サービスに関して、ご興味・ご質問をお持ちのお客様は お問い合わせフォーム もしくは担当営業までご連絡ください。 著者について 東海旅客鉄道株式会社 藤原 海渡 (Kaito Fujiwara) 中央新幹線推進本部 リニア開発部 在来線の電気設備保守、リニア電気設備の運用・保守・開発、営業線システムの検討を経て、現在は AWS を活用した IoT プラットフォームと MLOps の推進を担当しています。 アマゾン ウェブ サービス ジャパン合同会社 西部 信博 (Nobuhiro Nishibe) カスタマーソリューションマネージャー カスタマーソリューションマネージャーとして、エンタープライズのお客様を中心に、技術・非技術問わずクラウドジャーニーにおける課題の特定から解決までをご支援しています。好きな AWS サービスは Kiro と AWS IoT シリーズです。 正村 雄介 (Yusuke Shomura) プロフェッショナルサービス本部 IoT コンサルタントとして、製造業や鉄道事業者のお客様を中心に、IoT・生成 AI を活用したシステムの構築をご支援しています。通信分野の研究者を経て AWS に入社しました（工学博士）。好きな AWS サービスは AWS IoT Core と Amazon Bedrock です。趣味は読書とコーヒーです。 森田 和真 (Kazuma Morita) プロフェッショナルサービス本部 アソシエイトデリバリコンサルタントとして、金融や鉄道事業者のお客様をはじめとして、クラウド基盤・生成 AI 基盤に関連したご支援を中心に行っています。好きな AWS サービスは Kiro と Amazon Bedrock AgentCore です。

はじめに こんにちは！ タイミーでPlatform Engineerをしている @MoneyForest です。 2026年6月9日〜10日にニューヨークで開催された Datadog の年次カンファレンス DASH 2026 に参加してきました。弊社からは、MLOpsエンジニアの斎藤が「 How Timee Delivers Day 1 Production Ready LLM Features 」というタイトルで登壇していました。 本記事では、Keynote の全体像、タイミーの登壇セッション、そして Fireside Chat から得たメッセージについてお届けします。 DASH 2026 の全体像 公式のKeynoteの記事 にあるように、まさに「Datadog enables teams to build better with AI」といった内容でした。AI がコードを書くスピードは劇的に速くなったが、それを安全に運用するためのループも同じスピードで回らなければ意味がない。この課題に対し、Datadog は Bits AI というAIエージェント群を中核に据えた新製品群を提示しました。 Keynote Keynote で発表された新プロダクトは、AIエージェントによってループを閉じ、開発を高速化するためのものでした。ループは大きくOps・Dev・AI Agent の3つの軸で整理できます。 全発表の詳細は Datadog 公式の記事 に網羅されているので、ここではループごとの要点に絞って紹介します。 Ops ループ （Detect → Investigate → Remediate） 従来人間が手作業で回していた検知・調査・修復のループを Bits AI で自動化する軸です。 Bits Detection （Preview）はサービストポロジーやデプロイ履歴から何が重要かを推測し、本番が赤くなりそうなときだけ発火するモニターを自動で作成・維持します。大量のフレーキーなモニターリストを置き換えるものです。 Bits Memories （Preview）は Slack でのインシデント対応やポストモーテムから運用上の教訓を学習し、将来の調査に適用します。 Bits Remediation （Preview）は根本原因に対して kubectl コマンド実行やコード修正 PR 作成まで自律的に行います。 Bits Infrastructure Operations （Preview）は OOMKilled や証明書期限切れといった日常的なインフラ問題を自動で検知・修復します。 Dev ループ （Code → Deliver → Evaluate） AI コーディングエージェントが加速する開発スピードに対して、リリースの信頼性を追いつかせる軸です。 Bits Code （GA）は Datadog が問題を検出したあらゆる場所（Error Tracking、APM、Code Security 等）から、本番テレメトリを根拠にした修正 PR を生成します。 Bits Release （Preview）は PR の意図を理解し、「新機能が動くか」「リグレッションがないか」の両面でバリデーションプランを自動生成するリリース検証エージェントです。 Bits Testing Agent （Preview）は URL や自然言語のゴール（例：「黒いサングラスを購入して」）からアプリを自律探索し、セルフヒーリングなテストスイートを生成します。 Agent Console （GA）は Copilot / Cursor / Claude Code 等のコーディングエージェントの利用状況を組織横断で可視化し、非効率なパターンの検出やコストアラートを提供します。 AI Agent ループ （Observe → Evaluate → Experiment → Ship） AI エージェント自体を本番で運用・改善するためのループです。 Agent Observability Patterns （Preview）は、本番の LLM トレースを行動パターンに自動分類します。デモでは15,000件のトレースから想定外の「coordination」パターンが $20,000 のコストを生んでいることを発見し、根本原因分析から修正・検証まで一気通貫で行っていました。 Bits Evals （Preview）はトレース・データセット・プロンプトバージョンを横断して仮説検証やプロンプト改善を自動化します。 Data Observability （GA）はデータパイプライン全体のリネージと異常検知を担います。 Infinite Cardinality Metrics （GA）は課金モデルをカーディナリティベースからメトリクス名＋データボリュームベースに変更し、高カーディナリティ環境でのコスト予測可能性を大幅に向上させます。 その他 AI Guard （Limited Availability）はカスタムエージェントとコーディングエージェント双方の入出力をインターセプトし、プロンプトインジェクションやツール悪用をリアルタイムでブロックします。 Runtime Prioritization Engine （Preview）は16,000件の CVE から本番で悪用可能な9件に自動で絞り込み、 Security Analyst （GA）がセキュリティ調査を自動化します。 Journey Monitoring （Preview）：Synthetics・RUM・Product Analytics を統合し、ユーザージャーニー単位で可用性・パフォーマンス・コンバージョン率を一つのビューで可視化。「CPU が高い」ではなく「その CPU 高騰でコンバージョンが落ちているか」を見る、ビジネスインパクトへの引き上げが狙い Federated Logs （Preview）：Log Explorer から離れずに Databricks 等の外部ストレージを横断クエリ Bits Database Optimization ：LLM 生成のクエリ最適化案をシミュレート DB で検証してから PR 化。デモでは500クエリから検証済み30件に絞り、ノイズを9割削減 タイミーの登壇：How Timee Delivers Day 1 Production Ready LLM Features dash.datadoghq.com speakerdeck.com 弊社 MLOps エンジニアの斎藤が、タイミーにおける LLM 機能のプロダクション対応と LLM Gateway の構築について発表しました。内容について要約して紹介します。 背景 タイミーでは LLM がワーカー・クライアント双方の体験を向上させる重要な要素になっています。求人票の自動生成をはじめ、多くのストリームアラインドチームが独立して LLM 機能を活用しており、MLOpsエンジニアがその基盤を支えています。 チェックリストの誕生 最初のプロダクション導入では、LLM の不安定さ（タイムアウト、レイテンシスパイク、レートリミット）を想定した設計を行い、Vertex AI をプラットフォームとして採用しました。この経験から、LLM 機能に求められるプロダクション水準を定義した Production Readiness Checklist を策定しました。一般的なプロダクションの品質基準に加え、LLM 固有のシグナル（フォールバック、モデルレイテンシ、コスト制御など）をカバーするものです。 障害による転機 求人票生成機能の導入後、同一プロバイダー起因で2つの LLM 機能が同時にダウンする障害が発生しました。チェックリスト・モニタリング・ゲートウェイはそれぞれ存在していたものの、採用するかは各チームに依存していたことが根本原因でした。 また、高いスピードで価値を届けるという当然の行動をしていた中で、3人の ML プラットフォームチームが全チームに基準を強制するのは物理的に不可能だったのです。 解決策：LLM Gateway この障害を転機に、全 LLM 呼び出しの共通エントリーポイントとして LLM Gateway を導入しました。Cloud Run 上に構築され、複数の LLM プロバイダーを抽象化しています。 ゲートウェイが提供する価値は3つです。 自由な探索：プロダクトチームがセットアップのオーバーヘッドなしにプロンプトやユースケースを試せる 可観測性：全呼び出しにチーム・機能・環境のメタデータが付与され、トレース・レイテンシ・エラー・フォールバックが一箇所で見える ガバナンス：コスト・使用量・レートリミット・安全性が自動的に強制される これにより、チェックリスト（期待値を定義）× モニタリング（コンプライアンスのエビデンス）× ゲートウェイ（パスの強制）が統一化され、すべてのチームが恩恵を得られる状態になりました。 このセッションは「成功事例ではなく、何が壊れ、何を学び、何ができるかの話」という齋藤の言葉通り、実践的な知見が詰まった内容でした。 Fireside Chat OpenAI や Vercel の幹部を招いた Fireside Chat （対談）が非常に印象的でした。それぞれの視点からエージェント時代のソフトウェア開発について語られましたが、共通するメッセージが浮かび上がってきました。 The New Shape of Engineering（Fireside Chat with Datadog CTO Alexis Lê-Quôc and OpenAI Head of Product and Platform Thibault Sottiaux ） dash.datadoghq.com OpenAI で Codex と API Enterprise を率いる Thibaut との対談では、エージェントが組織にもたらす変化が語られました。 特に印象的だったのは、可観測性の役割が根本的に変わるという点です。エージェントの生産性が人間のレビュー能力を超えるにつれ、「すべてのコードをレビューするのか？」という問いに直面します。システム開発は、コードを一行ずつレビューするのではなく、「症状と振る舞い」で監視する、つまり医者が患者を診断するようなアプローチになるというビジョンが語られました。 また、OpenAI 社内ではフォンブースを使っている人の大半が会議ではなく AI と話していたというエピソードや、Thibaut 自身の Codex の使い方がコーディングから情報の統合と組織の把握へシフトしたという話も、エージェント時代の働き方を象徴していました。 エージェントを正しく使うヒントとして、「生産性の幻想を避ける」（並行して動かしていても、本当に意味のある問題に取り組んでいるか？）と「良い状態を説明する」（同僚に期待値を説明するように、エージェントにも伝えること）が挙げられていたのも実践的でした。 Fireside Chat with Datadog CPO Yanbing Li and Vercel CPO Tom Occhino dash.datadoghq.com Vercel CPO の Tom Occhino との対談では、「意図と実装の距離がほぼゼロに縮まった」という時代認識から出発し、プロダクト開発の変革が議論されました。 特に印象的だったのは、仕事を「2つの波長」として捉える考え方です。 Long Wavelength（基盤作業）：コアプラットフォームの品質・信頼性・セキュリティを高める作業。AI を使ってプロセスを加速しても、既存の検証・可観測性・レビューはすべて残る Short Wavelength（グリーンフィールド）：誰も依存していない新規領域。AI をエンドツーエンドで使ってどんどんシップする 両方の組み合わせが大事であること、そして Long Wavelength 自体を短くしていくこと、つまりリリースエンジニアリングのエージェント化が次の挑戦として語られていました。 共通メッセージ 両セッションは全く別物ですが、かなり共通する点が多かったのが印象的でした。 「作ること」は安く速くなり、人間の価値は"何を・どう良くするか"の定義に移る OpenAI（Thibaut / The New Shape of Engineering）：Thibaut は「良い状態を説明せよ」と語りました。実装が安くなったぶん、エージェントに何を期待するのかを伝えないと、エージェントは勝手に仮定を置いてしまう。難しいプロジェクトの期待値を同僚に説明するのと同じように、成功基準と検証方法を明示することが結果を大きく左右する。 Vercel（Tom / Fireside Chat）：Tom は「意図と実装の距離がほぼゼロに縮まった」という時代背景からセッションを始めました。だからこそ PM のコア業務である成功の定義、明確な問題設定、顧客理解はなくなるどころか重要性を増す。仕様が明確であるほどコーディングエージェントの出力は良くなるため。 本番・検証・信頼は"無料ではない" OpenAI：Thibaut は、OpenAIのメインエージェントの全アクションを"元の意図"に照らして検証する Guardian（デュアルエージェント安全システム）を紹介しました。そしてAIエージェントへの信頼は一足飛びには得られない。テストとログへ惜しみなく投資し、実績を積み重ねることで漸進的に築かれていくものだと語りました。 Vercel：Tom は「ソフトウェアの構築はほぼ無料でも、本番は絶対に無料ではない」と強調しました。基盤となる作業（Long Wavelength）では、AI でプロセスを加速しても、可観測性・既存システムへの統合・人間によるレビューはすべて残る、と。 可観測性が検証の中心になる OpenAI：Thibaut は、AIエージェントの生産性が人間のレビュー能力を超えていく中で「すべてのコードをレビューするのか？」と問いを投げかけ、システムは医者が患者を診断するように「症状と振る舞い」で監視する時代になると語りました。過去に発火したアラートを分析してノイズを減らす、アラートのトリアージ自体もエージェントが担い始めています。 Vercel：Tom がユースケースで示したのは、本番から得たインサイトでフィードバックループを閉じる「AIエージェント型インフラ」でした。コアのバイタルを常時監視し、リグレッションが起きれば原因を二分探索し、修正もしくはリバートの PR を自動で出す。コードを一行ずつ追うのではなく、本番の振る舞いから全体の健全性を捉える方向に進んでいます。 まとめ DASH 2026 を通じて感じたのは、「検証、品質、安全性の評価を、個人の規律ではなく経路（path）に作り込む」という考え方が、発表全体を貫いていたことです。 例えばBits Release はリリース検証を、AI Guard はセキュリティ評価を、呼び出し経路に強制的に組み込みます。 この時代におけるプラットフォームエンジニアリングの仕事は基準そのものを作ることではなく、基準が自動で適用される経路（基盤）を作ることだと思いました。

みなさん、こんにちは。株式会社 APTO で Physical AI のデータ基盤を構築している田中です。 近年、ロボット向け VLA モデルの台頭により、AI 開発の成否は「学習データの品質」に強く依存するようになっています。 しかし、大容量かつ厳密な同期が求められるロボットの操作データを品質を落とさずに日々収集することは非常に困難であり、Physical AI 開発における最大のボトルネックとなっています。 このブログでは、同じ課題に直面するチームの参考となるよう、APTO 社がこの「データ収集」のハードルをどのように仕組み化して解決したのかを紹介します。 想定読者 Physical AI / ロボティクス分野でデータ基盤を設計している方 AWS 上で大量データのイベント駆動処理を構築しようとしている方 スタートアップで少人数チームの MLOps を運用している方 APTO が AWS 上に構築している双腕遠隔操作ロボット向けの Physical AI データ基盤について、下の図 1 でグリーンの  ① 収集 の部分 — エッジ側で完全性をどう確定させ、Amazon S3 へどう引き渡しているか — を 3 章シリーズの第 1 章として解説します。データ基盤の全体像は「収集 → キュレーション → 拡張 → 学習 → 評価」という MLOps ループで構成されており、第 2 章ではクラウド側の自動キュレーションパイプラインに相当する ② キュレーション 、第 3 章では ③ 拡張 および ④ 学習 への接続を扱う予定です。なお、本稿で扱う ① 収集ではエッジ側のチェックを「データの同期が取れているか」に絞っており、品質スコアリング・重複判定・PII検査・統計集計などのキュレーション工程はすべてクラウド側で実施する設計です。 図 1: MLOps ループ全体像 — 収集が本稿のスコープ   1. APTO と Physical AI APTO は 2020 年 1 月設立、東京都千代田区にある約 40 名のスタートアップです ( APTO 会社概要 2026時点)。「イノベーティブなアノテーションで AI 開発に変革を」を掲げ、AI データプラットフォーム harBest を軸に、画像・動画・3D (LiDAR)・自然言語・音声まで幅広い学習データ事業を展開するスタートアップです。近年は LLM 開発支援、RLHF、エージェント、RAG といった領域に加え、Physical AI のユースケースを増やしています。 その一環として、双腕の遠隔操作ロボット (bimanual teleoperation robot) からデータを集め、Vision-Language-Action (VLA) モデルのファインチューニングに供する自社基盤を AWS 上で開発しています。本基盤の中心は「収集 → 自動キュレーション → 学習」のループを効率よく回し続けるための仕組みであり、このブログではそのうち最も上流にあたる「収集」を扱います。 2. 背景と課題 Physical AI とデータ基盤の関係 Vision-Language-Action (VLA) モデルは、視覚と言語指示を統合してロボットの動作を生成する基盤モデルとして、研究と産業応用の両面で進展しています。Google DeepMind の RT-2 、Physical Intelligence の π0 など、大規模 VLA モデルが相次いで発表されており、ファインチューニング向けの高品質データセットへの需要は今後も拡大が見込まれます。 ファインチューニングの成否は、モデルアーキテクチャの良し悪し以上に「投入するデータが安定した品質で揃っているか」に依存します。LLM の RLHF データセットに対する経験則と同じく、Physical AI でもデータおよびそれを提供するデータ基盤の完成度がモデル品質の上限を決める構造になりつつあります。 データを利用する上で直面する 3 つの構造的課題 Physical AI のデータパイプラインを運用しようとすると、次の課題に必ず突き当たります。 収集現場の不安定性 : 双腕ロボットの遠隔操作中に PC が落ちる、USB が外れる、オペレータが途中で介入する、といった事象は日常的に発生します。1 件でも破損エピソードが混入すれば、その後の再現実験や学習指標の信頼性が損なわれます。 後段クラウドで品質判定するコスト : 1 エピソードが数百 MB〜数 GB に達するため、「ひとまず Amazon S3 にアップロードしてから品質判定する」設計では、転送・ストレージ・再ハッシュのコストが線形に積み上がります。 手動キュレーションの限界 : 収集 → キュレーション → 学習 のループを回すには、目視確認・品質ラベル付け・Snapshot 構成といった工程を機械化しなければ、収集にキュレーションが追いつきません。 本基盤が目指す状態 これらを踏まえ、APTO の Physical AI データ基盤は次の状態を実装目標としています。 不完全なエピソードは エッジ側で除外 し、Amazon S3 には「完成したエピソードだけ」が届く Amazon S3 への到着をイベント駆動で受け取り、人間の判断は Release 承認のみ に限定する レビュアーは、クラウド側のキュレーションパイプラインが算出する品質ゲート結果・データセット統計・lineage を見て承認 / 差し戻しを判断する (詳細は次回ブログで扱う) データの ID をハッシュから導出し、ingest を 冪等 にする (同じデータを何度取り込んでも結果が変わらない)   3. Physical AI のデータ収集が難しい理由 図 2: 収集からキュレーションまでのデータフロー全体像 模倣学習 (imitation learning) は、お手本となるデモンストレーションデータを再現するようにポリシーモデルを学習させる手法です。Physical AI の文脈では、教師データの候補として 人間のテレオペレーションで収集されたデータとシミュレーション環境で生成された合成データが挙げられます。現時点では動作や映像の自然さや接触の忠実度といった面でテレオペデータの方が品質が高いと考えられ、多くの場合は人間が遠隔操作したロボットの動作を再現するようにモデルを学習させます。VLA モデルのファインチューニングでは、この教師データとして用いる「人間のデモンストレーション」が一定品質で揃っていることが前提となります。 ところがロボットの生ログには、次の三つのノイズが必ず混入します。 アクションと状態の混在 : 双腕遠隔操作では、人間が操作するリーダーアームと追従するフォロワーアームを別ストリームとして残さないと、 action と state が同一テンソルに混ざってしまいます。これは学習側のラベル設計を破壊します。 同期ズレ : カメラフレームとモータサンプルのタイムスタンプ差分が一定値を超えると、視覚と動作の対応関係が崩れます。本実装では WARNING / CRITICAL（2ms / 5ms）の二段階閾値で逐次判定しています。 エピソードの欠損 : 書き込み中に PC が落ちた、人間が途中で介入した、といった理由で不完全なエピソードが混じります。1 件の混入で再現実験の信頼性が失われます。 図 3: 双腕遠隔操作の Leader / Follower 構成   これらを後段のクラウドで除去する設計は費用対効果が悪く、Amazon S3 にアップロードしてから「不完全だった」と判明する経路では、転送と再ハッシュのコストが線形に積み上がります。本基盤ではエッジ側で完全性を確定させ、不完全なエピソードは S3 に渡さないことを設計の出発点としました。 4. 設計を貫く 3 原則 本基盤を貫く設計原則は次の 3 つです。データ品質を担保するためのルールとして先に定義し、そのうえでルールに則って AWSのサービスや機能を選定しています。 Immutability : Episode / Snapshot / Batch は一度作ったら書き換えません。修正は新ハッシュで別エンティティを作り、 derived_from で系譜を残します。 Content-Addressed Storage : エピソードの ID はファイル群の決定論的ハッシュから導出します。同じデータを何度取り込んでも同じ ID になり、ingest が冪等になります。 Event-Driven : 完了したエピソードの到着を S3 イベントで検知し、自動処理を駆動します。人間の判断は Release 承認のみに限定します。   5. 収集エンジンの 3 プロセス構成 図 4: sync-engine の 3 プロセス分離   エッジ PC 側の収集エンジン (sync-engine) は、責務の異なる 3 つのプロセスを共有メモリ ( SharedRingBuffer ) で接続する構成を採っています。 Collector プロセス : センサーとカメラからの読み取り、H.264 と FFV1 (深度) の動画エンコードを担当します。 Sync プロセス : メタデータだけでタイムスタンプを照合し、同期品質を逐次判定します。 Storage プロセス : motor_state.bin / sync_log.bin / events.jsonl などのバイナリファイルをディスクに書き出します。 この 3 プロセス構成は、後述する異常停止時の安全装置 (QualityMonitor) と直接結びつきます。Sync プロセス内で品質劣化を検知した時点で multiprocessing.Event を立て、Collector / Sync / Storage の 3 つを同時にグレースフル停止し、エピソードに .failed センチネルを置く流れです。 6. raw フォーマットの設計 現状のフォーマット選定と今後の方向性 エッジで保存する原本 (raw) のフォーマットは、学習で使う LeRobot v3.0 への変換前データを格納するレイヤです。Physical AI / ロボティクスで一般に検討される候補と評価ポイントを並べると次のようになります。 候補 評価ポイント apto-raw-v5 (現行試行) 変換前の物理層を可逆に残せる。当面の運用には十分だが標準ではない MCAP (Foxglove + ROS 2) スキーマと可視化が強い。ロスレス深度動画 (FFV1) や CAN-FD 生ログを 1 階層に同居させる運用を確立できれば有力候補 HDF5 自己 記述型で扱いやすい一方、動画コーデックの選択肢が限定的、巨大単一ファイルが S3 のオブジェクト単位アップロード／部分取得と相性が悪いという課題 Apache Arrow IPC 列指向で学習側との親和性は高い。Stream Format で追記は可能だが、エピソード途中で異常終了した際の整合性保証が現時点のネック これらを踏まえ、現時点では自前の apto-raw-v5 を試行的に採用しています。標準フォーマット側で「ロスレス深度動画 + CAN-FD 生ログを 1 階層に同居させる」運用ノウハウが揃いきっていないため、まずは可逆性と運用容易性を優先した暫定解という位置づけです。 ただし、このレイヤのフォーマット選定は引き続き検討中で、Physical AI 周辺のフォーマット標準は流動的なため、将来的に MCAP などの標準フォーマットへ移行する可能性は残しています。いずれを採るにせよ、(1) 全タイムスタンプを int64 ナノ秒で統一する、(2) CAN-FD 生ログをそのまま保持する、(3) 深度動画をロスレスで保持する、という三点はフォーマット選定に依らず満たす方針です。これらは将来「キュレーションをやり直す」「別の特徴量を後付けで計算する」という要件に直接効いてきます。 クロック同期源 i64 ns で精度を確保しても、各センサーのクロック源が揃っていなければ同期判定そのものが意味を失います。本基盤では次の方針を取っています。 カメラ : PTP (IEEE 1588) 対応の GigE Vision カメラを採用し、PC ホストを PTP マスタとして全カメラを同期。フレームには PC 受信時刻ではなくカメラ側ハードウェアクロックのタイムスタンプを正として保存します。 モータ (CAN-FD) : CAN フレーム自体はタイムスタンプを持たないため、CAN コントローラの SOF 受信タイミングを PC ホストの CLOCK_MONOTONIC_RAW で打刻しています。CANコントローラのHWタイムスタンプを使う方法も考えられます。 WARNING / CRITICAL 閾値の根拠 : カメラフレーム間隔 33 ms (30 fps) に対し、サブフレーム精度を保つために WARNING 2 ms、CRITICAL 5 ms を設定。CRITICAL を超えるとフレーム内での視覚と動作の対応関係がずれ、模倣学習で扱えなくなります。 PTP 同期がない環境では NTP のミリ秒精度に劣化し、CRITICAL を超えるリスクが増えます。本基盤を別環境に適用する場合は、まずクロック同期源の選定が出発点になります。 7. 完全性をエッジで確定させる仕組み 収録中の電源断・プロセスクラッシュで、エピソードが「途中まで書かれた状態」になることは避けられません。問題はそれを後段が完成済みと誤認することです。誤認すると不完全なデータが学習データセットに混入します。エッジ側では「途中で壊れた状態のエピソードを下流に流さない」ことを最優先にしています。 エッジでは抽象度の異なる3つの層で完全性を担保します。 防ぐ失敗 仕組み 失敗時のマーカー レイヤ 1: ファイル単位 単一ファイルが書きかけのまま本来名で残る アトミック書き込み: .part 拡張子で書き出し → fsync → atomic rename 中間ファイルは .part のまま残る（本来名は存在しない） レイヤ 2: エピソード単位 個々のファイルは完全だが、エピソード全体としては途中で中断している .done センチネルによる完了判定。全ファイルが揃った後に .done センチネルを置く .done が存在しない レイヤ 3: 意味的品質 ファイルとしては完全だが、同期ズレで学習に使えない 同期品質劣化時の安全停止 (QualityMonitor): QualityMonitor が閾値超過を検知 .failed を置く 後段（クラウド ingest や Storage プロセス側のスキャナ）は、この3つのマーカーだけを見て「完了 / 未完了 / 失敗」を判定します。中身のパースや SHA-256 検証は後段の責務として明確に切り分けています。 ファイルの存在だけを完了条件にしている理由は、 復旧時の判断を静的検査だけで完結させたい ためです。「特定ファイルが存在するか否か」だけで判定できれば、復旧ロジック自体を実質的に ゼロにできます。後述する Amazon S3 Event Notifications のフィルタ設計も、この原則の延長線上にあります。 全体シーケンス まず初めに全体の流れを図示します。 各データファイルを .part で書き出し → fsync → atomic rename manifest.json を atomic write + 親ディレクトリ fsync 正常完了なら .done、異常停止なら .failed を touch RawUploadAgent が各ファイルを並列 PUT 後、manifest.json を最後に PUT して S3 Event を発火 ファイル単位のアトミック書き込み 個々のファイルは次の手順で書き出します。 .part 拡張子で書き出す（例: cam_front.mp4.part ） 書き終わったら fsync() でデータを物理デバイスに永続化する os.replace() で .part を本来名（例: cam_front.mp4 ）にアトミックに rename する 親ディレクトリに対して fsync() を呼び、ディレクトリエントリの変更も永続化する この手順を守ることで、電源断が起きても「古い完全なデータが残っている」「新しい完全なデータが置かれてい る」「 .part のまま残っている」のいずれかにしかならず、 本来名で半端なファイルが見える状態は発生しません 。 manifest.json も同じ手順で書き出します。 また、エッジストレージ は NVMe SSD + ext4 (data=ordered) を採用しています。ext4 の data=ordered モードでは、データブロックがジャーナル commit より先にディスクへ書き出されることが保証されます。このため、fsync() + os.replace() の組合せでクラッシュ後も「古い完全なデータ」または「新しい完全なデータ」のどち らかが必ず観測されます。これは アトミック書き込みが成立する前提条件です。NFS / FUSE 等にファイルシステムを変更する場合、アトミック書き込みが破綻する可能性があるため、必ず再評価が必要です。 エピソード単位の完了判定 すべてのファイルが揃った時点で、エピソードディレクトリ直下に .done を touch します。途中で中断した場合は .done を置かないか、QualityMonitor が .failed を置きます。 完了検知は、 .done と manifest.json の両方が揃っているかだけで判断します。中身のパースや整合性チェックはクラウド側 ingest の責務として後段に切り分けています。 意味的品質を守る安全装置 (QualityMonitor) ファイルが完全に書けても、収録中の同期品質が劣化していれば学習には使えません。Sync プロセスはカメラフレームと最近傍モータサンプルのタイムスタンプ差分（同期ズレ）を逐次監視しています。この差分の時系列は原本中の sync_log.bin に保存され、後段の品質ゲートでも参照できます。 QualityMonitor が .failed を置く判定条件は次の二つです。 CRITICAL レベルのドリフトが一定フレーム数連続する 観測ウィンドウ内で CRITICAL の割合が一定割合を超える いずれかを満たした時点で、3 プロセス全体（Sync / Storage / Camera）をグレースフル停止し、エピソードに .failed センチネルを置きます。これにより、品質が劣化したフレームが含まれるエピソードはクラウ ドに渡る前にエッジで除外されます。 8. Amazon S3 へのアップロード manifest.json を最後に PUT する設計 RawUploadAgent は完了したエピソードのディレクトリを 1 ファイルずつ Amazon S3 raw バケットにアップロードします。ここで重要なのは、 manifest.json を 最後に PUT することです。 理由はクラウド側の S3 Event Notifications との接続にあります。1 エピソードから 8 オブジェクト前後が生成されますが、すべてに対してイベントを発火させると下流の Amazon SQS キューが 8 倍に膨らみます。さらに、まだアップロード途中の状態で Worker が S3 を読みに行くと、ファイル不一致による偽の IntegrityError が DLQ に積まれてしまいます。 そこで、(1) S3 Event Notifications 側でフィルタを filter_suffix = "/manifest.json" に絞り、(2) manifest.json は他の全ファイルの PUT が完了してから最後に置く、という二段の制約で「完了したエピソード 1 つに対して SQS メッセージ 1 つ」を成立させています。 この設計が成立するのは、S3 Event Notifications がオブジェクトキーの prefix / suffix フィルタをネイティブにサポートしているからです。Terraform での設定はほぼ次の 1 ブロックに収まります。 resource "aws_s3_bucket_notification" "raw" { bucket = aws_s3_bucket.raw.id queue { queue_arn = aws_sqs_queue.s3_events.arn events = [ "s3:ObjectCreated:Put" ] filter_suffix = "/manifest.json" } depends_on = [aws_sqs_queue_policy.s3_events] } filter_suffix を /manifest.json に固定するだけで、エッジ側が manifest.json を最後に PUT した瞬間にのみ SQS メッセージが 1 件キューに入る関係が S3 側で完結します。 実装は concurrent.futures.ThreadPoolExecutor で並列 PUT し、 as_completed() で全 future の完了を待ってから manifest.json を PUT します。1 つでも失敗していれば例外を伝播させ、 .failed を残してエピソード全体を破棄します。 from concurrent.futures import ThreadPoolExecutor, as_completed def upload_episode (episode_dir: Path , bucket: str , key_prefix: str ) -> None : data_files = [f for f in episode_dir.iterdir() if f.name not in { "manifest.json" , ".done" }] with ThreadPoolExecutor(max_workers= 8 ) as pool: futures = [pool.submit(_put_with_checksum, f, bucket, f"{key_prefix}/{f.name}" ) for f in data_files] for fut in as_completed(futures): fut.result() # raise on failure → episode を破棄 # 全データファイル PUT 完了後に manifest.json を最後に PUT # → S3 Event Notifications の filter_suffix="/manifest.json"が発火 _put_with_checksum(episode_dir / "manifest.json" , bucket, f"{key_prefix}/manifest.json" ) _put_with_checksum は boto3 の put_object(ChecksumAlgorithm="SHA256") を呼び、S3 の Additional Checksum 機能でサーバ側でも SHA-256 を再計算させてオブジェクトメタデータに保存します。Worker 側の再計算検証と組み合わせ、データ整合性は二重に担保しています。 .tar でまとめない理由 今回はエピソードを .tar でまとめずに、ディレクトリ構造をそのまま Amazon S3 のキー階層に写し取る方針を採っています。tar 一括 PUT 案と個別 PUT 案を精査した結果、コスト差は小さく(現状 8 ファイル/エピソード規模で損益分岐は約 43 ファイル)、判断は技術観点で決まりました。個別 PUT を選んだ主な理由は次の通りです。 後段 Stage の非対称なアクセスパターン : CosmosStage(映像品質判定)は動画のみ、学習(DataLoader)は Parquet のみを必要とします。個別 PUT なら必要なファイルだけ GET できますが、tar 化すると毎回全体を GET して展開する必要があり、特に GPU ノードで I/O 待ちが発生するのは設計として不適切です。 CopyObject による stream-copy 最適化が崩れる : ColdConvertStage では動画を raw から cold へ CopyObject で転記し、ECS Worker の CPU・帯域コストをゼロに抑えています。これは個別ファイルが独立した S3 オブジェクトとして存在することが前提です。 tar の「全か無か」性質との不整合 : 部分破損で全体が読めなくなる、Range Request で部分読みできない、Glacier 復元で毎回全体を取り出すことになる、IAM / KMS 粒度がファイル単位で切れない、といった問題が積み重なります。 なお tar 形式そのものを否定しているわけではなく、学習配布用の WebDataset 形式や Glacier Deep Archive への長期アーカイブなど、raw アップロード経路とは別レイヤーで tar 化する価値がある用途は存在します。 9. まとめと次回予告 このブログでは、Physical AI のデータ基盤において「完成したエピソードだけを AWS に渡す」状態をエッジ側でどう作るかを解説しました。要点は次の三点です。 自前フォーマット apto-raw-v5 を採用 : i64 ns タイムスタンプ・CAN 生ログ・ロスレス深度を 1 階層で保持しています。MCAP / HDF5 / Apache Arrow IPC のいずれでもこの組合せを単独では満たせなかったためです。 完了判定をファイル存在のみに統一 : .done と manifest.json の両方が揃ったときだけ完了とみなす原則を採り、状態機械の複雑化を避けました。これがクラウド側のイベント駆動設計に直結します。 manifest.json を最後に PUT : Amazon S3 Event Notifications を「エピソード完了 = 1 通知」という対応関係に整理しました。 Physical AI のデータパイプラインを長く回し続けるには、「機械的にやれる工程は全部自動に寄せ、人間の判断を Release 承認だけに集中させる」ことが鍵となります。エッジ側で完全性を確定させる本稿の設計は、その自動化を成立させる土台です。 第 2 章では、この manifest.json 到着イベントを起点に動く AWS 側のキュレーションパイプラインを扱います。Amazon S3 → Amazon SQS → Amazon ECS Fargate Worker のイベント駆動 ingest、Episode / Snapshot / Batch の 3 層モデル、9 サブステップの構造化キュレーションと 2 階層品質ゲートが中心です。続く第 3 章では、データ拡張と VLA ファインチューニングへの接続、シミュレーション環境との統合、マルチロボット対応の方向性を予告編としてお届けします。 同じような課題に取り組まれているスタートアップの参考になれば幸いです。 We are hiring!! APTOは、AIやPhysical AI領域のデータに特化したサービスを提供しています。 技術の実装を進めたい方、研究開発に興味がある方などは、下記採用ページからエントリーください！ https://apto.co.jp/careers/ 著者プロフィール 田中 達也 (Tatsuya Tanaka) APTOにてPhysical AIやロボティクス領域のデータパイプライン開発、およびUI構築をメインに担当しているAIエンジニアです。データの同期やマルチモーダルデータ管理など、AI活用に向けたデータ基盤の設計・開発に従事しています。趣味は競技プログラミングと陸上観戦。学生時代は陸上一筋でしたが、現在はもっぱら見る専門です。 遠藤 俊策 (Shunsaku Endo) ポジション: Co-founder / AI Engineer バンタンゲームアカデミーで、学内の審査会で数々の賞を受賞。その後、AI開発にも興味を持ち2020年1月にAPTOを共同創業。現在は、APTOのCDOとして開発とビジネス双方を管理。 GitHubアカウント: synsax( https://github.com/synsax ) 黒澤 蓮 (Ren Kurosawa) は AWS Japan のソリューションアーキテクトで、Startup 業界のお客様を中心にアーキテクチャ設計や構築をサポートしています。データアナリティクスサービスや機械学習の領域を得意としています。将来の夢は宇宙でポエムを詠むことです。