みなさん、こんにちは。株式会社 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 業界のお客様を中心にアーキテクチャ設計や構築をサポートしています。データアナリティクスサービスや機械学習の領域を得意としています。将来の夢は宇宙でポエムを詠むことです。  

みなさんこんにちは！ワンキャリアのプロダクト開発部 ワンキャリア転職チームの越川（X：@kosshii_）です。 前回は、プロダクト開発チームのエンジニア4名に「学びになった技術書トップ3」を聞いてみました。新卒エンジニアの「本を読んで勉強したいけど、何から読めばいいかわからない」という悩みに寄り添った記事になっておりますので、是非、本記事と一緒にご一読いただきたいです！ ▼ Part1はこちら

こんにちは、株式会社タイミーでMLOpsエンジニアをしているKYです。普段はMLプラットフォームの構築・運用を担当しています。 実務の中でコンテナイメージのサプライチェーンセキュリティ強化を進めており、その一環として Docker 社が提供する「Docker Hardened Images（DHI）」の実装を辿る機会がありました。 その際、実際の定義ファイルを見て、少し驚きました。コンテナのビルド定義といえば「Dockerfile」が当たり前だと思っていたのですが、DHI の定義はなんと YAML で書かれていたのです。 「なぜ Dockerfile ではないのか？」と定義の読み方を追いかけていくうちに、BuildKit のアーキテクチャに行き着きました。この記事では、DHI の仕組みを通じて、私たちが普段の Dockerfile 運用で押さえるべきポイントを再確認したいと思います。 ビルド定義の主役は「Frontend」 BuildKit は、「定義を解釈する部分（Frontend）」と「実際にビルドを実行する部分（Backend）」に分離しています。Frontend は、入力（Dockerfile や YAML）を BuildKit の中間表現（LLB）に変換する役割を持ちます。 ここで鍵になるのが、ファイル先頭のコメント行 # syntax=... です。BuildKit はまずこの1行を読み、どの Frontend で後続を解釈するかを決めます。つまり、Docker 公式が推奨しているのに見落とされがちな以下の1行は、単なるコメントではなく「このファイルは公式の Dockerfile Frontend で解釈してほしい」という宣言です。 # syntax=docker/dockerfile:1 一方で DHI の定義ファイルを開くと、YAML の1行目に次の指定があります。 # syntax=dhi.io/build:2-debian13 YAML も # をコメントとして扱うため、BuildKit から見れば「 # syntax= から始まるビルド定義」という意味で入口は同じ。その後の中身を YAML として解釈するのは、差し替えられた DHI Frontend の仕事 というわけです。 DHI は何をしているのか：YAML をコンパイルする DHI の定義ファイル（YAML）は、 RUN apt-get... のようにといった手順を重ねるのではなく、「最終的に何を入れるか」という状態を宣言します。 【DHI の YAML 定義例（実際の定義ファイルからの抜粋）】 # syntax=dhi.io/build:2-debian13 name : Debian 13 Base image : dhi.io/debian-base variant : runtime platforms : - linux/amd64 - linux/arm64 dates : release : "2025-08-09" end-of-life : "2028-08-09" contents : packages : - '!libelogind0' - '!mawk' - '!original-awk' - base-files - bash - ca-certificates - coreutils # ... 以下、ベースに含めるパッケージの列挙が続く accounts : run-as : nonroot users : - name : nonroot uid : 65532 gid : 65532 cmd : - /bin/bash いくつかのフィールドに注目してみます。 contents.packages : !mawk のように ! プレフィックスを付けると「明示的に含めない」パッケージを宣言できます。削除手順を書くのではなく、最初から「入れない」と表明する点が Dockerfile との大きな違いです。 accounts.run-as: nonroot : 実行ユーザーを非 root に固定する宣言で、Dockerfile の USER 命令に相当します。Dockerfile のように RUN useradd ... といったユーザ作成手順を書く必要はなく、「誰で動かすか」という状態だけが残る点が特徴です。 dates.end-of-life : イメージのライフサイクル終了日まで定義に含まれており、運用上の管理情報もビルド定義の一部として扱われています。 このように、DHI の YAML は「どう作るか」ではなく「何が入っていて、誰が動かすか」を宣言しています。そしてここで重要なのは、 BuildKit が YAML を直接ビルドしているわけではない という点です。 DHI の Frontend がこの YAML を読み込んで中間表現（LLB）へコンパイルし、あとは通常通り BuildKit がビルドを実行します。つまり、DHI の YAML は「別言語」ではなく、 Frontend を差し替えて得た “別の入力形式” なのです。 たとえば不要パッケージの除外ひとつとっても、Dockerfile では apt-get remove → autoremove → キャッシュ削除と手順を重ねる必要があります。一方、DHI なら - '!mawk' の1行で意図が完結します。手順（How）ではなく意図（What）だけが残るため、セキュリティ監査や再現性の面で有利です。DHI が宣言的定義を採用しているのは、こうした相性の良さがあるからです。 忘れられがちな Dockerfile の公式推奨設定 今後、DHI のような宣言的フロントエンドがすぐに主流になるかは未知数であり、当面は既存の Dockerfile 運用が続くでしょう。 しかし、DHI が示す「Frontend は明示し、選ぶものである」という観点は重要です。まずは Docker 公式が推奨する以下の2行を、忘れずに Dockerfile の先頭へ記述しましょう。 # syntax=docker/dockerfile:1 # check=error=true # syntax=... 使用する Frontend を固定し、手元の環境と CI の違いによるビルド結果の揺れを防ぎます。 # check=error=true BuildKit の静的解析（lint）を強め、警告レベルの記述を CI で弾けるようにします。 これらを習慣づけるだけで、「Frontend を明示し、品質を保つ」文化に確実に近づきます。 まとめ DHI から学べる本質は、 BuildKit は Frontend を自由に差し替えられる という点にあります。この視点を持つと、DHI は単なるセキュアなベースイメージではなく、ビルド定義の抽象度を一段上げる試みとして見えてきます。 「手順を書く」から「状態を宣言する」への移行は、Infrastructure as Code で何度か見てきた流れと重なって見えます。DHI を触ってみて、その発想がコンテナビルドの入力形式にも持ち込まれていることを実感しました。 将来的にビルドのパラダイムがどう変わるにせよ、まずは見逃されがちな # syntax=... と # check=... をきちんと置くこと。タイミーでも Cloud Run / Vertex AI Pipelines の DHI 移行を進める中で、Frontend 指定の差がビルド結果の揺れに直結する場面に何度か遭遇し、この2行の重要性を改めて感じました。DHI がもたらした視点を持ちつつ、足元の運用を公式のベストプラクティスで堅牢にする。これが、現実的で安全なコンテナ運用の第一歩です。 参考文献 Docker Hardened Images - カタログリポジトリ Debian 13 Base 定義ファイル（13.yaml） — 記事中の YAML 定義例の抽出元 Custom Dockerfile syntax - Docker Docs Build hardened images - Docker Docs We're Hiring! サプライチェーンセキュリティや ML 基盤の足回りに興味を持っていただけたなら、ぜひ一緒に働きませんか。タイミーでは、ML プラットフォームの構築・運用やサプライチェーンセキュリティの強化に取り組むエンジニアを募集しています！ 少しでも興味を持っていただけましたら、ぜひ以下のリンクから詳細をご覧ください。 MLOpsエンジニア シニアMLOpsエンジニア 募集ポジション一覧