本記事は 2024 年 2 月 16 日に公開された” Enhance your AWS cloud infrastructure security with AWS Managed Services (AMS) “を翻訳したものです。 はじめに セキュリティやデータ損失インシデントは、金銭的損失と社会的信用の失墜につながる可能性があります。セキュリティとコンプライアンスは、AWS とお客様の間における責任共有により維持されます。この責任共有では、AWS は「クラウドのセキュリティ」に責任を持ち、お客様は「クラウドにおけるセキュリティ」に責任を持ちます。しかし、クラウドにおけるセキュリティは、特にクラウドインフラおよびオペレーティングシステム(OS)レベルにおいて、より広い範囲に及びます。クラウドにおいて、セキュアでコンプライアンスに準拠した監視環境を大規模に構築するには、高度な自動化、人的リソース、およびスキルが必要です。 このブログでは、「クラウドにおけるセキュリティ」を向上させるために AWS サービスを組み合わせて活用する方法を紹介します。多くの組織にとって、スキル不足やビジネスにおける優先順位により、セキュリティのベストプラクティスを大規模に順守し、導入することは容易ではありません。 AWS Managed Services （AMS）が大規模にお客様の AWS インフラのセキュリティおよびコンプライアンス体制を強化してきたベストプラクティスをご紹介します。AMS は、モニタリング、インシデント管理、セキュリティ、パッチ適用、バックアップ、コスト最適化にわたって AWS クラウドでの運用上の優秀性を達成するための能動的・予防的・検出的な機能を提供します。これにより、お客様はイノベーションに集中できます。 例えば、Coinhako が AMS を運用パートナーとして AWS に移行した際、CTO の Gerry Eng 氏は次のように述べています。「AMS に標準搭載されている数多くのセキュリティ機能は、我々が独自に適切に展開するには数ヶ月、場合によっては数年かかっていたでしょう。」詳細は ケーススタディ をご覧ください。 AWS におけるクラウドセキュリティ管理 予防（Prevention） 「予防は治療に勝る」と言われています。セキュリティ体制を改善し、問題を予防するための領域には、アイデンティティとアクセス管理（ IAM ）、受信 （Ingress）と送信 （Egress）トラフィックの保護、バックアップおよび災害復旧、そして脆弱性への対処があります。 AWS は AWS IAM とサービスコントロールポリシー（ SCPs ）を組み合わせてクラウドリソースへのきめ細かいアクセス制御を提供しています。AWS は IAM サービスのセキュリティベストプラクティス を公開しています。しかし、お客様がその最適な利用状況を長期にわたって監視・統制することは容易ではなく、結果として不正なアクセスや不要なアクセスを招いてしまうことが少なくありません。AMS を活用することで、IAM の変更が AWS のベストプラクティスや AMS の技術基準に適合しているかを継続的に検証することが可能です。また、AMS はカスタム AWS Config ルールを使用して IAM のガバナンスコントロールのベストプラクティスを実装し、異常または逸脱を積極的に検出・修正します。 受信 （Ingress）と送信 （Egress）トラフィックの観点から、エッジネットワークで AWS WAF （Web アプリケーションファイアウォールサービス）を使用して、Web アプリケーションリソースへ届く HTTP/HTTPS リクエストを検査することができます。AWS WAF は Amazon CloudFront 、 Application Load Balancer （ALB）、 Amazon API Gateway などほとんどの AWS 外部向けサービスとネイティブに統合されています。ネットワーク層では、 AWS Network Firewall を使用してファイアウォールルールを定義し、すべての受信 （Ingress）と送信 （Egress）ネットワークトラフィックをきめ細かく制御できます。Network Firewall は AWS Firewall Manager と連携して、複数の VPC およびアカウントにわたってポリシーを一元的に適用します。AMS は AWS ベストプラクティスを使用して、これらのサービスを継続的にセットアップおよび運用するサポートを提供します。 さらに、定期的なパッチ適用は脆弱性に対する最も効果的な予防策の一つです。 Ponemon Institute の調査によると、「侵害被害者の 60% は、パッチが未適用の既知の脆弱性を悪用されて侵害された」と述べています。OS レベルでは、最新の脆弱性から保護するための完全なパッチ管理のために AWS Systems Manager の Patch Manager サービスを活用できます。継続的な脆弱性管理には、 Amazon Inspector サービスで、OS の脆弱性のスキャン・特定ができます。しかし、パッチスケジュールの設定、パッチコンプライアンスのレポート、および大規模なパッチ失敗への対応は、困難ではあるもののビジネス上の差別化に繋がらないタスクとみなされることがあります。AMS は自動化とベストプラクティスを駆使し、大規模環境においても、これら一連の作業をお客様に代わって実行します。AMS は Inspector またはお客様のツールによって報告された高リスクまたはゼロデイ脆弱性に対処するための臨時パッチ適用も実行できます。また、AMS を活用して Security Technical Implementation Guide （ STIG ）ベンチマークに準拠したセキュリティが強化された OS の Amazon Machine Images（AMI）を構築し、安全な EC2 インスタンスをデフォルトで保護することもできます。 最後に、インシデント時のデータ損失に対して、堅牢なバックアップおよび災害復旧戦略が不可欠です。 AWS Backup と AWS Elastic Disaster Recovery を組み合わせて AWS クラウドのデータを保護できます。大規模な環境において、バックアップ計画の設定とバックアップコンプライアンスの継続的な監視は複雑になることがあります。AMS は継続的なバックアップの監視・管理を支援するだけでなく、ランサムウェア保護プランを含むデータ復旧のビジネスユースケースに対応した複数のバックアップ計画を提供します。定期的なバックアップのテスト・復元は、予期せぬ問題発生時のビジネスサービスのダウンタイムを最小化するための重要な実践です。AMS はインシデント時の平均復旧時間（MTTR）を短縮するためのサービス復旧に関する SLA を提供します。AMS はお客様のチームとともに、侵害インスタンスやランサムウェアイベントなどのシナリオをシミュレートするセキュリティおよび運用重視のゲームデー（模擬訓練）を実施します。 検出（Detection） クラウド環境を継続的に監視して異常や潜在的な悪意ある活動を積極的に検出・封じ込め・修正することは非常に重要です。AWS は、ログやイベントの処理、およびモニタリングを通じて、監査、自動分析、アラーム通知を可能にするさまざまな検知統制を実装するためのサービスを提供しています。例えば、 Amazon GuardDuty は機械学習（ML）ベースの脅威検出サービスで、アクセス関連アクティビティと不正な動作を継続的に監視して AWS アカウントのワークロードを保護します。GuardDuty は Amazon Macie と組み合わせることができます。Macie はデータセキュリティサービスで、ML とパターンマッチングを使用して AWS アカウント内の機密データの検出・保護を行います。 AWS Security Hub CSPM はクラウドセキュリティ体制管理（CSPM）サービスで、セキュリティのベストプラクティスチェックを実行し、AWS およびサードパーティサービスからのアラートを集約し、修復手順を提案します。しかし、多数の AWS アカウントにわたってこれらのアラートを処理し、修復を実施することは、運用上すぐに困難な状況になることがあります。 AMS は Amazon GuardDuty を活用して、お客様が契約しているすべての AWS アカウントの脅威を監視し、そこから生成されるすべてのアラートを 24 時間 365 日体制でレビューします。AMS は GuardDuty アラートを分析する自動化技術を駆使し、誤検知を減らして、初期トリアージ（優先度判定）を行い、インシデント通知の一環として実用的な対応策を提供します。重大な問題については、AMS は積極的にお客様と連携して共同セキュリティ調査を実施し、修復に必要な承認を取得します。AMS は Amazon Macie の検出結果を監視し、お客様に代わって必要な修復を実施することもできます。 モニタリングとインシデント対応（Monitoring and Incident Response） Amazon CloudWatch はオブザーバビリティのための AWS ネイティブの基盤サービスで、インフラ、アプリケーション、およびエンドユーザーモニタリングにわたる機能を提供します。Systems Manager の OpsCenter により、オペレーションスタッフは CloudWatch や AWS Config などのサービスによって特定された運用上の問題を表示・調査・修復できます。Systems Manager の Incident Manager 機能は、自動化された対応計画を使用して重要なアプリケーション問題をより迅速に解決するのに役立ちます。OpsCenter と Incident Manager は、Atlassian Jira や ServiceNow などの ITSM およびチケットシステムと統合して、お好みのツールでインシデントの包括的なビューを提供します。Incident Manager は Amazon Q Developer in chat applications とも連携しており、Slack、Microsoft Teams のようなコラボレーションツールを使用して、インシデントの調査や修復対応を行うことができます。(※1) AMS は、世界各地の複数のサイトに配置されたエンジニアによる 24 時間 365 日のセキュリティ監視とインシデント対応を通じて、クラウドでの運用上の優秀性の達成を支援します。アラートとイベントは AWS Config、Amazon GuardDuty、Amazon Macie、Amazon CloudWatch、 AWS CloudTrail などのネイティブサービスから監視されます。セキュリティインシデント対応（ SIR ）については、AMS は事前定義された National Institute of Standards and Technology （NIST）準拠のランブック（対応手順書）に従い、セキュリティアラートに対して、特定・分析・封じ込め・根絶・復旧の対応を行います。AMS は Systems Manager の OpsCenter を使用してすべての運用項目をログに記録し、AWS サポートケースを通じて通知し、お客様のチームと連携して解決します。Security Incident and Event Management （SIEM）や Endpoint Detection and Response （EDR）などサードパーティまたは自社開発のセキュリティツールを使用している場合、AMS はそれらによって報告された OS および AWS インフラ関連の検出結果を修復する支援も行うことができます。また、 AWS Service Management Connector を ServiceNow や Atlassian Jira などの ITSM ツールと統合して、AMS とのシームレスなインシデント・チケット対応を実現することもできます。(※2) コンプライアンス（Compliance） AWS の責任共有モデルの下、お客様はゲスト OS、アプリケーションソフトウェア、および AWS アカウント内の AWS サービスの設定と選択に関して、セキュリティとコンプライアンスの責任を負います。さらに、ビジネスニーズに応じて幅広いローカル・グローバルのコンプライアンスフレームワークに準拠する必要があり、それらのフレームワークを AWS セキュリティコントロールにマッピングすることは困難な場合があります。 AMS を使用することで、AWS における全体的なセキュリティ体制を強化するだけでなく、必要なコンプライアンスレベルへの到達を加速できます。まず、AMS というサービス自体が、 HIPAA 、 SOC 、 ISO27001 、 FedRAMP 、 IRAP 、 NIST 、 PCI-DSS 、 GDPR など、多くのグローバルなコンプライアンスフレームワーク、規制、セキュリティ基準に適合し、準拠しています（詳細は AWS コンプライアンスセンター を参照）。そのため、AMS によって管理されるクラウド環境は、特定のコンプライアンス要件や規制要件が求められるアプリケーションをホストするのに適しています。 次に、AMS では利用開始初日から、AWS Config を活用することで、CIS、NIST、PCI、HIPAA という、極めて厳格かつ多岐にわたる 4 つのグローバル・セキュリティ・フレームワークに対するお客様のセキュリティ体制を完全に可視化できます。AMS は、厳選された AWS Config Rules をデプロイし、お客様のアカウント内のリソース状態を継続的に監視することで、これらのコンプライアンス基準やフレームワークの要件への準拠を維持します。これらのルールは、ビジネスのニーズに応じて、自動修復を行うか、インシデントやレポートとして通知を行うかのいずれかに設定することが可能です。例えば、AMS では、AMS アカウント内で AWS CloudTrail によるログ記録がデフォルトで有効化されており、これが必要なときにいつでも行えるレポート作成、アラート通知、および監査に利用されます。この設定だけでも、セキュリティ基準である NIST SP 800-53 の監査と責任（AU）コントロールファミリーにおける AU-06/07（a-c, 1-4） や、ISO 27001 のコントロール A.12.4.1-3 といった複数の管理策を満たす上で有効です。 さらに、AMS はコンプライアンス要件を強化するために、OS レベルと AWS アカウントレベルの両方において、中央集権型のログ記録および監査コントロールを実装しています。AWS アカウント内で行われたユーザーアクセスや変更に関する監査レポートは、 Amazon Athena コンソール経由で、AMS が事前構築した厳選されたクエリを使用して簡単に抽出することができます。 レポートとガバナンス（Reporting & Governance） AWS クラウド環境全体におけるセキュリティ体制や潜在的なリスクを測定・追跡するためには、強固なレポート機能とガバナンスの実践が不可欠です。Key-Value のペアを使ってメタデータを作成する AWS Resource Tagging は、監査、自動化、およびコスト配分を通じて、運用上の優秀性を達成するために極めて重要な役割を果たします。例えば、AWS のメタデータやタグの値は任意の AWS ストレージサービスにエクスポートすることができます。これにより、 AWS Glue 、 Amazon Athena 、 Amazon Quick Sight といったサービスを活用して、パッチ適用状況やセキュリティコンプライアンスのカバー率に関するレポート、あるいはその他のダッシュボードを構築できます。 AMS は、OS のパッチ適用レベル、バックアップのカバー率、および高緊急度のインシデントに関するレポートを、毎週・毎月セルフサービスで提供します。また、お客様専任の AMS Cloud Service Delivery Manager（CSDM）と Cloud Architect（CA）が信頼できるアドバイザーとして、月次ビジネスレビューを主導します。このレビューでは、管理されているすべての AWS アカウントを横断した中央集中型の追加レポートが提供されます。月次ビジネスレビューには、 AWS Well Architected Framework の各柱にわたる主要なクラウド運用リスクへの洞察と高緊急度のアラートに対処するための将来的な計画が含まれています。 AMS のタグまたはお客様独自のカスタムタグを強制適用するために、AMS 管理下にある AWS リソースでは、AMS が提供する Resource Tagger ツールを活用できます。監査やレポート作成に加えて、AMS 固有のタグを使用することで、アクセス制御、監視、パッチ適用、バックアップ、および自動修復にわたる自動化アクションが可能になります。この AMS Resource Tagger とお客様のカスタムタグを組み合わせることで、クラウドガバナンスのための強固なタグ付け戦略を構築できます。 セキュリティオンデマンド（Security On-Demand） AMS は、 Operations on Demand （OOD）サービスを通じて、必要なときに拡張セキュリティサポートを提供しています。AMS OOD を活用することで、AWS サービスに関する変更を行い、AWS クラウドにおけるセキュリティ体制をさらに向上させることができます。このサービスには、既知の、あるいは未対策のセキュリティ脅威から保護するためのセキュリティ関連サービスカタログが含まれており、AWS Network Firewall の運用や、サポート終了が迫っているレガシー OS のアップグレードなどに対応しています。 おわりに 本記事では、AWS クラウドにおけるセキュリティ体制を強化するために実装できる、予防・検出・対応の管理を含む、多くの不可欠なセキュリティベストプラクティスを検討しました。また、お客様の AWS クラウド環境を管理することで、求められる「クラウドにおけるセキュリティ」を実装する信頼できるパートナーとして、どのように AMS を活用できるかを説明しました。AMS は、AWS のベストプラクティスを用いた複数のガードレールの実装に加え、24 時間 365 日のセキュリティインシデント対応および復旧を行うことで、クラウドのセキュリティ体制を強化します。さらに、AMS は初日からお客様の AWS アカウントにログ記録、監査、監視に関する多くの必要なセキュリティ統制とベストプラクティスの導入を支援し、コンプライアンスへの取り組みを加速させます。 セキュリティ特有の機能にとどまらず、AMS はインフラや OS の能動的な監視、アラートの自動復旧、コスト最適化、そして継続的なガバナンスの組み合わせにより、大規模なお客様の AWS クラウド環境における運用上の優秀性の達成を支援します。詳細については、 AWS Managed Services の製品ページをご覧ください。 ※1 2025 年 11 月 7 日に AWS Systems Manager Incident Manager は新規のお客様への提供を終了しました。AWS は引き続き Incident Manager のセキュリティと可用性への投資を継続し、既存の Incident Manager のお客様は、すでに Incident Manager が有効化されているアカウントにおいて、これまで通りサービスを引き続きご利用いただけます。 ※2 2026 年 3 月 31 日に AWS Service Management Connector は新規のお客様への提供を終了しました。既存のお客様は、2027 年 3 月 31 日までサービスを引き続きご利用いただけます。2027 年 3 月 31 日以降、AWS Service Management Connector の機能にアクセスすることはできなくなります。AWS パートナーソリューションへの移行、または直接的な SDK 統合の構築をお勧めいたします。 翻訳はシニアオペレーションズマネージャーの木村が担当しました。 原文はこちら です。 Nitin Verma Nitin は、クラウドオペレーション、自動化、セキュリティにおいて 10 年以上の専門知識を持つプリンシパルソリューションアーキテクトです。お客様が運用上の優秀性を達成し、AWS 上でのクラウドジャーニーを加速できるよう支援することを専門としています。Nitin の重点分野には、クラウドアーキテクチャ、IaC（Infrastructure as Code）、DevSecOps、AIOps などの新興テクノロジーが含まれます。 LinkedIn でフォローできます。 Amit Gupta Amit は、インフラストラクチャセキュリティオペレーションおよび AWS Managed Services（AMS）を専門とするシニアセキュリティエンジニアです。サイバーセキュリティにおいて 10 年以上の経験を持っています。セキュリティインシデント対応やセキュリティリスク管理のバックグラウンドを有しています。適切な戦略と設計により、お客様のサイバーセキュリティリスクを最小限に抑えることを支援することに注力しています。 TAGS: AWS Managed Services (AMS) , Cloud Operations , Management and Governance , Security

1.はじめに こんにちは、OpenInnovationラボ（通称イノラボ）の奥野正寛です。 現在イノラボではフィジカルAIの研究開発に取り組んでおり 前回記事 では、小型アームのSO-ARM101を使い、VLAモデルであるπ0.5の精度や汎化性を検証しました。 今回は業務利用を見据え、業務向けレベルにパワーと精度がある協働ロボットとしてxArm7を2台で双腕のロボット基盤モデル検証システムを構築し、実証したことについて書きたいと思います。 今回の検証ではπ0.5で以下2つの内容を検証しております。 本記事では、取り組んだ内容と併せてVLAをxArmのような協働ロボットに適応するにあたり苦労したことや、実際に実機で動かしてみて分かったことなどをお伝えします。 検証①：基本的なピック＆プレイス 検証②：ラボオートメーションを想定した「電子レンジで資材を温める」というロングタスク 2.独自のRFM実証システムを構築 今回ロボットとしてUFACTORYの xArm7を2台組み合わせた双腕構成 にしました。 操作インターフェースには各アームに対応するGelloを使い、直感的かつ精度高くxArmを制御してデータ収集できる構成を目指しました。 システムはLeRobot0.6.1をベースに開発し、データ取得や学習済みVLAモデルを実行できるシステムを構築しました。 カメラは各アームの手首にRealSense1台ずつと、空間全体を見るUSBカメラ1台の計3台です。 データ取得では、何百回とエピソード動作を繰り返すためデータ記録の効率性を考慮し、 フットスイッチで記録終了や次のエピソードの記録開始を行えるようにしました。 Gelloから手を離してPCを操作する必要がなく、両手でロボットを操作しながら、効率よくデータを収集できました。 タスクによってはエピソードの初期状態に戻すことも、ロボットを制御して行うこともできます。 また実証システム開発において考慮した点として安全性があります。xArmのように大きくてパワーがあるロボットの場合、制御によっては周囲への危害だけでなくロボット自体の破損の懸念があります。 今回は対策の一例として、VLAによる制御時にはロボットに制御値を送る前に各関節への指令値の変化量に上限を設けるフィルターと、移動平均によるスムージングをかける構成としてます。 また、扱う物体や作業に合わせて、グリッパーの先端治具を3Dプリンターで作成しています。 特に今回は電子レンジの庫内へのアクセスの際に手首カメラが衝突してしまうことが判明したため、掴みやすさだけでなくグリッパー先端を長くする調整が必要でした。 世の中のフィジカルAIの事例を参考にFin-Ray形状の治具を作成しましたが、曲がりやすさなどは作って試さないと分からないため微調整しながら最終形状を設計してます。 他にもGelloの固定台座なども3Dプリンターで作成しており、ロボットをやるうえで3Dプリンターは必須であると改めて感じました。 3. 検証①：π0.5による基本的なピック＆プレイス 基本動作ができるまでの試行錯誤 まずはシンプルなピック＆プレイスのタスクで、システム全体が想定通りに動作することを目指しました。 SO-ARM101での経験があったため、同じようにデータを集めてπ0.5をファインチューニングすればある程度は動かせると考えていましたが、最初は期待する精度が出ず試行錯誤を繰り返しました。 トライ1 最初は左右それぞれ50回ずつそれぞれ別アイテムをピック＆プレイスするデータを取得しπ0.5を学習したモデルを試しました。 プロンプトの切り替えでそれぞれのアイテムを取れることを期待しましたが、片方のプロンプトはそれらしい動作はするが、もう片方のプロンプトはほとんど動かなくなるなど全く成功しない結果となりました。 原因を検討した結果、以下点を想定し、システムを見直したうえでトライ２へ移行。 空間カメラ配置の見直し ・最初は作業机の真上から真下を見下ろす形で空間カメラを設置しましたが、これだと映像に含まれる位置情報が２次元となり、高さに関する情報が不足すると考えました。 ・Physical Intelligenceなどの主要なVLAベンダーのデモ動画を参考にすると、双腕の間の上方部から見下ろす位置に空間カメラを設置していることが多く、上下の情報も取れる位置であることから同様の位置に変更しました。 片腕固定による条件を絞った ・今回双腕のそれぞれが動くと固定カメラは空間カメラ1台となり、残りの２カメラが動くとなるとカメラ位置の条件が相当多いことになると考えられます。そこで片腕を固定してカメラとして使い、まずは単腕アームシステムの状態として検証することにしました。 ・前回SO-ARMで実施した検証では2台のカメラを固定カメラとして、100~200回程度のエピソードデータである程度ピック＆プレイスに成功するモデルが学習できていたことを参考としてます。 トライ2 上記のカメラ位置変更、単腕アーム化した状態で1つのアイテムに対するピック＆プレイスを検証。 しかしそれでも精度が出ないことから他のシステムバグやデータ不整合などを中心に見直しました。 結果としてグリッパーのデータが正しく保存できていない、実際の動作時間と記録データの時間がずれがあった、Lerobot自体のバグなど様々な要因が発見されました。 厄介だったのは、こうした問題があっても「なんとなく動いてしまう」こと データが足りないのか、学習がうまくいっていないのか、制御側の問題なのか問題切り分けが必要となります。 環境整備・データ取り・モデルFT・実機検証・要因分析を繰り返す ことにより期待する精度のシステムの構築ができます。この繰り返しをいかに効率的に実施するかが重要だと感じました。 またこれまでの経験から、VLA実行時に様々な初期状態に対応するためには収集データにおいて、対象物の置き方の網羅性が重要であると考えました。 そこで初期条件としての置き方の網羅性を確認するために、各エピソードデータから重畳画像で確認できるツールを作りました。 以下の画像のように学習データにおいてどこに置いてないが一目で分かることで、学習後モデルで精度のでない位置条件の原因が切り分けやすいです。 データ条件が少ない場合はあまり問題なかったですが、条件が増えてくると分からなくなってくるためこういった確認方法は有効だと感じます。 最終トライ 最終的にこれまでの不具合要因を修正し、単腕で200回程度のデータを使うことで、期待するピック＆プレイスができるπ0.5のモデルを作ることができました。 このプレ検証ではπ0.5の対象物に対する汎化性を確認することができました。 「ニンジンを掴んで皿に置く」動作のデータのみで学習したπ0.5モデルに対して、実行時に入力プロンプトを変えると、 掴む対象として学習していないピーマンやナスでもピック＆プレイスに成功 する挙動が見られました。 ニンジンがある場合、プロンプトで他のアイテムを指定してもニンジンを取りにいく挙動です。 またタスク終了条件となるニンジンが皿に乗った状態においても、他のアイテムには反応しない状態となります。 ニンジンがない状態で、プロンプトでピーマンやナスを指定するとそれぞれのアイテムを取りにいくことが出来ました。 学習時に掴む対象として扱っていない野菜にも対応できたことから、対象物に対して汎化した結果が見られました。 サイズや形状が異なる赤パプリカに対しては、指示に反応して取りにいくが掴むことはできませんでした。 ニンジンに対する把持動作だけ学習しているため、パプリカの大きさに合わせたアクションが生成できなかった可能性が考えられます。 4. 検証②:ラボ作業をサブタスクに分けて検証 本検証では業務向け活用のユースケースとしてラボオートメーションを想定し、「電子レンジで資材を温める」という長いタスクを設定しました。 1つのモデルで一気に全タスクを動作させる方法もありますが、π0.5において複雑かつ長いタスクを一気に実行することは精度が出ないと考えました。 π0.5の論文でも内部的に上位で全体タスクからタスクへ分割し、アクション生成する２段階のフローとなっています。したがって今回はπ0.5の考え方に沿って、全体タスクを8つのサブタスクに分け、7つの別モデルに分ける形で検証しました。 結果としてサブタスクごとの専用モデルでは、7つのうち「5.温め実行」を除く6つで成功することを確認できました。 「電子レンジで資材を温める」をサブタスクへ分解 1.コップにジェルを入れる 2.レンジを開ける 3.コップを庫内に入れる 4.レンジを閉める 5.温め実行 (2.レンジを開ける) 6.コップを取り出して資材を落とす 7.温めた資材をカゴに入れる 単腕でのタスク実行 単腕の比較的単純な動作であれば、200回程度のデータである程度の精度が得られました。 また「4.レンジを閉める」のようにある程度決まった位置でアームを動かせば成功するタスクでは100回程度のデータでもほとんど成功するモデルとなりました。 ただし、対象物の位置が変わると失敗するケースも多くあり、1モデルにつき200回程度ではデータに含めたすべての位置に対して安定して動くまでの精度にならない結果です。 双腕でのタスク実行 今回のサブタスクの中で「1.コップにジェルを入れる」だけ双腕で同時に2つのアームを動かすタスクでした。片方のアームでコップを持ち、もう片方でジェルを掴んでコップに入れて、コップをレンジの横に置く、というタスクを1つのモデルに学習する形で検証しました。 コップとジェルの位置条件を満遍なく変更した約300回分のデータで学習した結果、 うまくいく特定の初期位置の条件でのみ成功しました。 学習データに含まれるほとんどの位置条件でジェルやコップを掴むことができず、位置に対する汎化性が得られない結果です。 固定カメラが1台となる双腕の協調動作においては、単腕に比べて必要とされるデータ量が相当に多くなると考えられます。 「押せたか分からない」ボタン操作の難しさ 今回のサブタスクの中で唯一成功しなかったのは、電子レンジの3つのボタンを順番に押す「5.温め実行」タスクです。 200回分のデータで学習し、ボタンを押した結果が分かるようにカメラで液晶表示の変化も映しましたが、モデル実行するとグリッパーの先端でボタンを押しにいくような動作はするものの、ボタンは押すことは出来ませんでした。要因として大きく2つあると考えています。 要因1：ボタンを押せた判断情報がない 人間はボタンを押した際の操作音や押したクリック感で判断できます。一方今回の学習データには音や力覚の情報が含まれておらず、カメラに映した液晶表示の変化だけでは、ボタン押下の成否判断として不十分だった可能性があります。 要因2：先端の微小な動作を学習不足 今回グリッパーの治具で先端を延長しているため、ロボットの各関節の角度変化が先端部では大きな位置ずれにつながりやすくなります。今回の構成ではVLAは各関節角度を出力しており、ボタンを押すほどの正確な先端の位置制御を再現するほどには学習できていないと考えられます。 実用化を考えると、こうした課題をVLAの学習だけで解決しようとするよりも、IoTボタンなどの外部機器や別システムとの連携によって、確実に操作できる仕組みを取り入れることも有効だと感じています。 5.プロンプトの切り替えから、モデルの切り替えへ方針転換 もともとこの検証を始めた際はサブタスク別に入力プロンプトは分けるが1つのモデルに全てのサブタスクのデータで学習させ、プロンプトで実行するサブタスクを切り替えることを想定していました。 しかし実際やってみると2つ3つのサブタスクでも1つのモデルにまとめて学習すると、プロンプトを切り替えてもほとんどのタスクが成功しないモデルとなってしまう結果でした。具体的にはプロンプトの切り替えても関係ないサブタスクの動作をしてしまったり、各サブタスクに近い動作はするものの全く成功するような動きにならないなどです。 プロンプト設計により切り替えられる可能性も考えられましたが、ここでは方針転換しサブタスクごとにモデル自体を別に作る形としました。 結果として前述の通りで多くのサブタスクで成功するモデルを作ることができました！ しかしモデル自体を切り替える場合、モデルの切り替え時にVRAM読み込み等で長い時間がかかることが、業務利用を想定すると課題として残ります。 この課題の回避策を検討し、大きいVRAMへ2つのモデルを同時に読み込ませ実行するモデルを順次切り替え、実行終了したモデルは破棄・・ということを繰り返すことで即座にモデル切り替える形を構築しました。 π0.5は実行時に1つのモデルで10GB程度VRAMを消費します。今回の実行環境ではVRAMが32GBあるRTX5090では、2つのデルの同時展開を問題なく実現できてます。 以下が最初の4つのサブタスクのモデルを順次切り替えて実行している様子です。 6.まとめ 今回の実証では、LeRobotと双腕のxArm7で独自のロボット基盤モデル検証システムを構築し、π0.5による対象物への汎化や、ラボを題材としたロングタスクへの適応を検証しました。 長いタスクでもサブタスクに分解し、それぞれ専用モデルとして学習することでサブタスクを実現できること、またそれらの専用モデルを順次切り替える構成により連続実行できることを確認できました。 一方で現場導入を想定すると位置などの条件に対する汎化性や精度を高めることが必要で、そのためにはやはり大量のデータ収集、そのための効率的なデータ取得やデータ管理・運用が重要となります。 今回の検証では扱うデータや学習済みモデルの容量も膨大になりました。データの管理や学習環境などのインフラ整備、そのためのクラウド費用が課題となるため データ収集から管理・学習・実機評価までを、費用も含めて効率よく回せる環境づくりが重要 だと感じています。 また今回は精緻な操作のためにGelloを使いましたが、1本のアームを細かく動かすには両手が必要で、双腕のデータ収集は2人必要で動きを合わせて行う必要がありました。今後はUMIなどの操作インターフェースも検討し、データ品質と収集効率を両立できる方法を探っていきたいと考えています。 7.最後に 試行錯誤をしている間にも、技術は大きく変化しています。 GeneralistのGEN-1.5 のように 少数の手本でタスクに対応するワンショット・フューショット学習の成果が登場しています。 また、Astraのような最新LLMで追加学習を行わずにロボットを制御し、シミュレーションでは一定の成功率が出る報告がされるなど、この数ヶ月はフィジカルAIにおける大きな技術進化と、進化スピードがより早く広くなってきていると感じます。 新しい技術の可能性も含め、自分たちの環境で実際に動かして確かめ、その過程で出来ることや出来ないことを見極めることが重要だと考えており、イノラボでは引き続きフィジカルAIの社会実装を目指した研究開発を進めていきます。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @okuno_takahiro 、 @miyazawa.hibiki レビュー： @azeta.takuya （ Shodo で執筆されました ）

本記事は 2026 年 11 月 4 日 に公開された「 Amazon S3 Tables now offer managed migration of Apache Hive tables to Apache Iceberg 」を翻訳したものです。 本日から、データレイクのモダナイゼーションをシンプルかつ低コストで進められるよう、 Amazon S3 Tables で Apache Hive テーブルから Apache Iceberg へのマネージド移行が利用できるようになりました。対象となるのは、 AWS Glue Data Catalog に登録された Amazon S3 上の Parquet テーブルです。パイプラインの構築やコンピューティングのプロビジョニングをせずに、本番ワークロードを動かしたままデータレイクをアップグレードできます。 Apache Iceberg は、大規模な分析データセットのオープンスタンダードになりました。スキーマ進化、hidden partitioning、タイムトラベルクエリなどの機能でペタバイト規模のテーブルを管理でき、データはオープンな形式のまま、Iceberg 互換の任意のエンジンからクエリできます。Amazon S3 Tables は、Iceberg テーブルが大きくなってもパフォーマンスとコスト効率を保てるように設計されたフルマネージドのストレージです。自動メンテナンス、最適化、レプリケーション、 S3 Intelligent-Tiering などの機能を標準で備えています。 新機能の概要 これまで Apache Hive テーブルを Apache Iceberg に移行するには、必要なインフラの構築と管理に数週間のエンジニアリング作業がかかることもありました。データ型の変換やロールバックの仕組みづくりも運用を複雑にしていました。今回、移行を API で操作できるマネージドな処理として利用できるようになりました。 S3 Tables は、データ検証、互換性チェック、型変換、ファイルの再圧縮、コンパクションを含む移行ワークフロー全体を処理します。データをコピーする前に、S3 Tables は対象となるソースオブジェクトをすべて洗い出し、互換性レポートを生成します。同期は必要な回数だけ実行でき、ソーステーブルへの書き込みを止める必要があるのは切り替え時の数分間だけです。準備が整ったら移行を完了でき、テーブルがオフラインになる時間を最小限に抑えられます。 S3 Tables のマネージド移行は、自前で移行する方法と比べてコストを抑えられます。料金はコピーしたデータ分のみで、Hive から Iceberg への変換自体には料金がかからず、S3 Intelligent-Tiering 上のソースオブジェクトは現在のアクセス階層に留まるためです。 移行を試してみる AWS Glue の Hive テーブルを移行するには、 S3 コンソール で移行先のテーブルバケットを選び、 Create table from migration を選択します。 移行先の Iceberg テーブルの名前空間とテーブル名を指定します。移行先テーブルは、クエリパフォーマンスとストレージ効率に合わせて調整された推奨のデフォルト設定で作成されます。 移行を開始すると、S3 Tables はソーステーブルを検証して互換性レポートを生成し、データのコピーを始めます。移行中、移行先テーブルは読み取り専用です。移行を完了すると、移行先テーブルは読み書き可能になります。 AWS コンソールから Amazon Athena や Amazon SageMaker Unified Studio との直接統合を使ってすぐにデータを扱えるほか、Apache Iceberg REST API 互換の任意のツールからテーブルを直接クエリすることもできます。詳しくは S3 Tables の移行に関するドキュメント をご覧ください。 AWS Command Line Interface (AWS CLI) 、 AWS SDK 、 Agent Toolkit for AWS も利用できます。たとえば、移行ジョブを設定して start-table-migration コマンドを呼び出します。 cat > /tmp/start-migration.json <<'EOF' { "roleARN": "arn:aws:iam::123456789012:role/S3TablesMigrationRole", "destinationTable": { "tableBucketARN": "arn:aws:s3tables:us-east-1:123456789012:bucket/my-destination-bucket", "namespace": "mynamespace", "name": "my_destination_table", "encryptionConfiguration": { "sseAlgorithm": "aws:kms", "kmsKeyArn": "arn:aws:kms:us-east-1:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab" }, "storageClassConfiguration": { "storageClass": "INTELLIGENT_TIERING" }, "tags": { "team": "s3tables", "purpose": "migration" }, "properties": { "writeFormat": "parquet", "icebergFormatVersion": 2, "compressionCodec": "zstd", "dictionaryEncoding": true }, "schema": { "type": "struct", "schemaId": 0, "identifierFieldIds": [1], "fields": [ { "id": 1, "name": "id", "type": "long", "required": true, "doc": "primary key" }, { "id": 2, "name": "payload", "type": "string", "required": false } ] },     "icebergSortOrder": {       "orderId": 1,       "fields": [ { "sourceId": 1, "transform": "identity", "direction": "asc", "nullOrder": "nulls-first" } ]     }   },   "sourceType": "glueTable", "source": {     "glueTable": {       "catalogId": "123456789012",       "databaseName": "my_glue_database",       "tableName": "my_source_table"     }   },   "dataMigration": {     "maintenanceSettings": {       "icebergCompaction": { "targetFileSizeMB": 512, "strategy": "binpack" },       "icebergSnapshotManagement": { "minSnapshotsToKeep": 3, "maxSnapshotAgeHours": 168 }     },     "migrationPolicies": {       "unmatchedSourceFieldsPolicy": "fail",       "incompatibleValuesPolicy": "fail"     }   },   "reviewMigrationPlan": false,   "migrationOutput": {     "bucket": "arn:aws:s3:::my-report-bucket",     "prefixes": {       "tableCompatibilityReport": "reports/table-compatibility/",       "objectCompatibilityReport": "reports/object-compatibility/",       "objectMigrationReport": "reports/object-migration/"     }   } } EOF aws s3tables start-table-migration \   --cli-input-json file:///tmp/start-migration.json ソース側の変更を移行先テーブルに反映するには、移行を完了する前に sync-table-migration を必要な回数だけ呼び出します。同期のたびにコピーされるのは変更分だけです。 Kiro などのコーディングエージェントを使っている場合は、Agent Toolkit for AWS の migrating-hive-tables-to-s3-tables スキルが、エージェント向けの安全ガードレール付きで移行を段階的にガイドします。このスキルでは次のことができます。 既存の IAM ポリシーを分析し、移行先で同等になるポリシーを提案する 開始前に移行計画を検証する Start → Sync → Complete の API 呼び出しを実行する ジョブの進行状況を監視し、検証と切り替えをガイドする 詳しくは、 スキルの GitHub README ページ をご覧ください。 提供開始 Amazon S3 Tables のマネージド移行は、本日から米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、アジアパシフィック (ムンバイ、シンガポール、シドニー、東京)、欧州 (フランクフルト、アイルランド、ストックホルム) リージョンで利用できます。提供開始時点では、同一の AWS アカウントかつ同一の AWS リージョン内にある、AWS Glue に登録された Parquet 形式の Hive テーブルに対応しています。新機能について API の呼び出し、ドキュメントの検索、リージョンごとの提供状況の確認、トラブルシューティングをしたい場合は、お好みの AI ツールで AWS MCP Server と プラグイン をお試しください。 ぜひ Amazon S3 コンソール でお試しいただき、 AWS re:Post for Amazon S3 または普段ご利用の AWS サポート窓口からフィードバックをお寄せください。 — Channy 著者について Channy Yun (윤석찬) Channy は AWS News Blog のリードブロガーであり、AWS クラウドの Principal Developer Advocate です。オープンウェブの愛好家で根っからのブロガーでもあり、コミュニティ主導の学びと技術の共有を大切にしています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。