はじめにこんにちは。LINEヤフーでモーション生成やアニメーション生成の研究開発に取り組んでいる郁です。このたび、我々のチームから次の 2 本の論文が CVPR 2026 に採択されました。Causa...

2026 年 4 月 14 日、アマゾン ウェブ サービス ジャパン合同会社（以下、AWS ジャパン）は、「フィジカル AI 開発支援プログラム by AWS ジャパン」の採択企業向け勉強会を東京の AWS 目黒オフィスにて開催しました。勉強会では、 NVIDIA 加瀬 敬唯氏より、NVIDIA Robotics Solutions をご紹介いただきました。AWS からは、Physical AI 開発 「データ生成」 フェーズにおける AWS の活用方法と Remote AWS Develop Station のご紹介を行いました。本プログラムについては、過去のブログも参照してください。 「フィジカル AI 開発支援プログラム by AWS ジャパン」の応募受付を開始 「フィジカル AI 開発支援プログラム by AWS ジャパン」キックオフイベントを開催しました 「Physical AI on AWS 勉強会 #1」を開催しました NVIDIA Robotics Solutions のご紹介 Physical AI が今注目される背景と、NVIDIA のシミュレーション技術、そして、世界モデル Cosmos とヒューマノイド向け基盤モデル GR00T について、NVIDIA Robotics Solution Architect の 加瀬 敬唯氏よりご紹介いただきました。 Agentic AI の次のステップとして注目されているのが Physical AI です。Physical AI という言葉は、ヒューマノイドだけでなく、監視カメラ・自動運転・ドローン・工場ロボット等、物理世界を理解し行動する AI 全般を指します。従来の産業ロボットはルールベースで柵の中でしか動けませんが、Physical AI は経験から学習し非構造化環境で動作します。最大の課題はデータ不足で、実ロボットから取得できるデータには物理的限界があるため、シミュレーションによる大規模データ生成が鍵となっています。 Physical AI における最大の課題、データ不足に対して、NVIDIA は実世界におけるロボットの動きを再現しデータを取得できる、さまざまなシミュレーション技術を開発し、提供しています。オープンソースのロボットシミュレーター Isaac Sim を中核に、実環境を iPhone 撮影から 3D Gaussian Splatting で再構築する NeuDex、柔軟物シミュレーションに対応する次世代物理エンジン Newton を提供しています。学習フレームワーク Isaac Lab では強化学習・模倣学習に加え、VR デバイスによるシミュレーション内テレオペレーション（Isaac Teleop）も可能です。 Physical AI のモデル開発においては、シミュレーションによるデータ収集に加え、データの前処理・拡張（Augmentation）・品質評価といった一連のデータパイプラインの整備が不可欠です。NVIDIA からは、この工程を実行するツールやモデルとして、Cosmos Curator（動画キュレーション）、Cosmos Transfer（背景変換）、Cosmos Reason（Physical AI 特化 VLM）を提供しています。 シミュレーションやデータパイプラインに加え、NVIDIA が開発・公開しているモデルやデプロイ向けツールの紹介もありました。Cosmos v2 は、3500 万時間の動画データで学習された世界モデルで、入力映像の続きを予測・生成することでロボットの検証やベンチマークに活用できます。ヒューマノイド向け基盤モデル GR00T N は VLM（System 2）と 120Hz 制御の Diffusion Transformer（System 1）の 2 層構造です。デプロイ向けには GPU 最適化 ROS パッケージ群 Isaac ROS や、異種 GPU リソースを統合管理する OSMO も提供されています。 Physical AI 開発 「データ生成」 フェーズにおける AWS 活用 Physical AI の開発では 「データ生成・収集 → モデル学習 → モデル配信・推論」 の 3 ステップを繰り返します。この各ステップにおける、AWS から提供される NVIDIA GPU の選択肢と、データ生成フェーズにおける AWS の活用方法について、Solutions Architect の杉山より紹介しました。 Physical AI 開発の各フェーズに最適なインスタンスをその理由とともにご紹介しました。データ前処理において、 GPU が不要な場合は、Amazon EC2 C8/M8 等のコンピュート最適化インスタンス、シミュレーションにはレイトレーシングに特化した RT コアと大容量 VRAM を備えリアルタイムレンダリングが可能な Amazon EC2 G6e/G7e (NVIDIA L40S Tensor Core GPU / RTX PRO 6000 Blackwell Server Edition 搭載) インスタンスを推奨しています。学習フェーズでは、VRAM 消費が比較的軽い LoRA ファインチューニングにはAmazon EC2 G6e、大容量 VRAM が必須となるフルファインチューニングには Amazon EC2 P5 (NVIDIA H100 Tensor Core GPU 搭載)インスタンスが適しています。さらに事前学習から取り組む場合は、大規模な分散学習に対応した Amazon EC2 P5en/P6-B200 (NVIDIA H200 / B200 Tensor Core GPU 搭載) インスタンスがおすすめです。 Physical AI モデル開発に利用するデータ生成目的のシミュレーションは、Amazon EC2 上にインストールされた Issac Sim で実行します。そして、生成されたデータは、スケーラブルでコスト効率に優れたオブジェクトストレージである Amazon S3 への保存するのが一般的です。AWS の東京リージョンでは、Issac Sim のリモートデスクトップによるグラフィック操作を快適に行える Amazon EC2 G6e/G7e インスタンスがご利用いただけます。さらに、高性能リモートデスクトッププロトコルである Amazon DCV を利用することで、より快適なシミュレーション環境を実現できます。EC2 間の DCV 接続は無料です。 また、Kubernetes ベースのワークフローオーケストレーターである NVIDIA OSMO もご紹介しました。NVIDIA OSMO は、Physical AI の開発パイプラインである、 「データ生成・収集 → モデル学習 → モデル配信・推論」 を Kubernetes 上で定義・自動実行するオーケストレーターで、各ステージに最適な GPU リソースを自動で割り当てる点が特徴です。NVIDIA OSMO は AWS 上でも利用でき、G 系・P 系インスタンスの選択が自動最適化されるため、インスタンス選定の手間が軽減されます。 スライド資料 Remote AWS Develop Station (RADS)​ Physical AI 開発に便利な Amazon EC2 ベースの開発環境を​簡単に起動/接続/管理できるサンプル 「Remote AWS Develop Station (RADS)​」 を Solutions Architect の原田より、ご紹介しました。 RADS は Amazon EC2 ベースの開発環境を Web ポータル経由で提供するサンプルソリューションです。Isaac Sim や ROS を使ったシミュレーションワークロードを AWS 上で手軽に始められることを特徴としており、ユーザー自身の AWS 環境にデプロイして使うセルフマネージド環境です。接続方式は Amazon DCV（Web / ネイティブクライアント）、code-server（ブラウザ IDE）、SSH（Systems Manager 経由）の 3 種をサポートしています。Web ポータルからインスタンスタイプ・AMI・EBS サイズを選ぶだけで環境が立ち上がり、チームメンバーごとに独立した環境をセルフサービスで作成・停止・削除できます。 ゴールデンイメージには NVIDIA ドライバー・ROS・Isaac Sim に加え、Amazon Bedrock 連携の AI コーディングエージェント（Claude Code 等）もセットアップ済みで、約 5 分で開発を開始できます。 Physical AI 開発におけるユースケースとしては 2 つあります。1 つ目は Issac Sim などを用いたシミュレーションで、DCV 接続まで含めたセットアップ済み環境により、初めての方でもすぐに始められます。2 つ目は AI 駆動開発です。ローカルから分離されたサンドボックス環境として開発環境が起動するため、ローカルに保存された機密データの AI エージェントによる漏洩や改変を心配することなく、長時間エージェントを稼働させたり、大量のエージェントを並列で実行することができます。 利用開始方法もシンプルです。インフラは全て AWS Cloud Development Kit (AWS CDK, コードでクラウドインフラを定義・プロビジョニングするフレームワーク) で定義されており、2 つのコマンドを実行するだけで約 30 分〜 1 時間でデプロイが完了します。現在オープンソース公開に向けて準備中です。 今後のスケジュール 時期 内容 2026 年 5 月中旬 ロボット勉強会: AI 開発者がロボット業界に入っていく上で知っておくべき知識の共有（内容・日程調整中） 2026 年 6 月 1 日 Community Meetup #1 – 登録ページは こちら 2026 年 6 月 25-26 日 Demo Day（中間報告会）at AWS Summit Tokyo 2026（幕張メッセ） 2026 年 7 月中旬 Community Meetup #2 2026 年 7 月下旬 最終成果報告会（AWS 麻布台ヒルズ オフィス 予定） おわりに 本勉強会では、NVIDIA の Robotics Solutions に加え、Physical AI 開発の各フェーズに最適な Amazon EC2 GPU インスタンスの選び方、そしてシミュレーション環境を手軽に構築できるサンプルソリューション RADS をご紹介し、AWS 環境でシミュレーションを実行するための実践的な知識を共有することができました。参加された企業の皆様が、既存の環境と合わせて活用いただくことで、より開発を加速させることができるよう、AWS ジャパンとしても引き続き支援をさせていただきます。 AWS ジャパンは、本プログラムを通じて日本のフィジカル AI の発展に貢献してまいります。採択企業の皆さまの挑戦と、成果発表会をどうぞご期待ください。 関連リンク : –  フィジカル AI 開発支援プログラム by AWS ジャパン（発表ブログ） – 「フィジカル AI 開発支援プログラム by AWS ジャパン」キックオフイベントを開催しました – 「Physical AI on AWS 勉強会 #1」を開催しました

こんにちは、タイミーでSRE業務を担当している徳富(@yannKazu1)です。 先日、函館で開催されたRubyKaigi 2026に参加してきました。Ruby本体やパーサ、GC、JITといった「言語の中身」を深掘りするカンファレンスなので、普段アプリケーションコードよりインフラ寄りの仕事をしている自分が行って楽しめるのか、という気持ちも少しありました。ですが、結果としてとても楽しめたので、感想を書いておきます。 SREが行っても普通に楽しめた 普段の仕事はRailsアプリケーションを安定して動かしたり、スケールさせたり、観測したりすることが中心です。Ruby本体にコミットするわけでも、パーサを書くわけでもないので、専門外の話も多いだろうと思っていました。 実際、聞いていて全部の細部までは追えないセッションもありました。それでも、 普段ブラックボックスとして扱っているGCやランタイムの中身が、作っている人の口から語られる 他社のRails運用をやっている人たちと直接話せる このあたりだけでも参加する価値を感じました。 Day 1のブースが意外と良かった 参加されたことがある方ならわかると思いますが、Day 2以降はブース巡りが意外と慌ただしくなります。スタンプラリーで人が流れたり、セッションの合間で時間が限られていたり。 その点、 Day 1はスタンプラリーがまだ始まっていないので、ブースが比較的空いていてゆっくり話せる時間帯 でした。立ち寄っても順番待ちがほとんどなく、エンジニアの方とじっくり話せます。 RubyKaigiにはほぼ例外なくRailsを本番運用している会社さんがスポンサーとして出展しているので、SREとしては「他社さんのアーキテクチャや困りごとを直接聞ける場」として、これがかなり面白かったです。 Railsで完結する vs クラウドネイティブに振り切る 複数の会社さんと話して興味深かったのが、「Railsの中で完結させるか、AWSのマネージドサービスに切り出すか」の判断基準が会社によって全然違うことです。 Railsはよくできていて、ActiveJob + Sidekiq、ActiveStorage、ActionCableなどを組み合わせれば、大抵のユースケースはRailsの世界の中で完結します。わざわざクラウドネイティブなマネージドサービスに切り出さなくても、運用負荷を抑えながら回せるケースは多い。 一方で、「ジョブの遅延が事業KPIに直結するので、マネージドサービスに切り出して水平スケールを確実にしている」と話す会社さんもあれば、逆に「今のスタックで十分捌けているし、Rubyエンジニアが運用できる構成に揃えたほうが組織的に強い」と話す会社さんもありました。 技術選定の基準として挙がっていたのは、ざっくりこんな観点です。 スパイク耐性が事業上クリティカルかどうか 運用するチームのスキルセットと採用市場 コールドスタートを許容できるワークロードか RubyKaigiは登壇者も来場者もアプリケーションエンジニアが中心です。そのため、「Sidekiqのままいくか、それとも切り出すか」といったテーマひとつとっても、「アプリケーション側からどう見えているか、何が嬉しいかつらいか」という視点で語られていたのが印象的でした。 普段、SRE系のイベントで「インフラ側の都合」としてこの手の話を聞くことが多い私にとっては、この視点の対比が非常に新鮮に感じられました。 「正解は一つじゃない」と頭ではわかっていても、SRE目線とアプリ目線では同じ意思決定でも見えている景色が違います。両方の視点を持っておくことが大事だなと、改めて感じました。 AI活用の温度感 もう一つ、多くのブースでも話題になったのが AI活用 です。プロダクトへの組み込み、社内開発フローへの導入、営業・カスタマーサポートへの活用と、レイヤーごとに状況が違っていて面白かったです。 特に印象に残ったのが、SmartBankさんのブースで展示されていた「スマートバンクで働くAI Agentたち」のポスターでした。アプリユーザー向けの「 ワンバンフレンズ 」(家計を読み解いて気づきを届けるAIアシスタント)、社内メンバー向けの「 Ask! ワンバン 」(自然言語で社内データを検索・分析する分析AI)、そして開発者向けの「 Guardie 」(エラーや異常を検知してログ・コード・変更履歴を横断して原因特定を支援する番犬AI)という三本立てで、 ユーザー向け / 社内向け / 開発者向けの3レイヤーに対してそれぞれAIエージェントを配置している のがすごく整理されていて印象的でした。 特にGuardieはSRE視点でめちゃくちゃ刺さりました。「2時間覚悟していた調査が10分で終わった」という社内の声が紹介されていて、これは障害対応における MTTR(平均復旧時間)を本質的に短縮しに行っている 事例だなと。エラー検知 → ログ・コード・変更履歴を横断した原因特定までをAIに任せる、というのはこれから我々も作っていこうと思っていた仕組みが普通に動いていて、刺激を受けました。 ブース担当の方とは「どこまでをAIに任せて、どこから人間がやるべきか」「誤検知や暴走への安全装置をどう設計しているか」みたいな話までできて、こういう一次情報が聞けるのもRubyKaigiならではでした。 気になった話は、その後のアフターパーティでさらに深掘りできました。資料には載らない現場のリアルな知見が交換される場として、ブース + アフターパーティの組み合わせは、セッションと同じくらい価値があったと感じます。 参加したセッションを日ごとに振り返る ここからは、自分が参加して特に印象に残ったセッションを日ごとに紹介していきます。 Day 1: Exploring RuboCop with MCP (Koichi ITO さん) 1日目に聴いたのが、RuboCopコアチーム・MCP Ruby SDKチームメンバーのKoichi ITOさんによる、 RuboCopとMCP(Model Context Protocol) を組み合わせる試みについてのセッションです。 これまでRuboCopは「人間」または「他のプログラム（CIなど）」をきっかけに実行されてきました。そこにAI時代になって、 AIエージェントという新しい実行のきっかけ が登場した、というのが導入の話です。生成AIとリンター/フォーマッターをどう組み合わせるか、Rubyで実装されたMCPサーバーをエージェントの隣で走らせるとどうなるか、という内容でした。 技術的には、 MCP SDKの構造(サーバーとクライアントそれぞれのSDKがあること) トランスポート層として stdio と Streamable HTTP の2種類があり、用途で使い分けること HTTPトランスポートではセッション管理が肝になり、Pumaのようなスレッドモデル + シングルプロセス構成だと素直に動くが、複数プロセス・複数ホストに横断するとセッションの保持が難しくなること ただし Stateless Mode ( stateless: true )を使えば、Pumaの複数ワーカーやUnicornのような複数プロセス構成にも対応できること。ただしこれは リクエストごとに新しいtransportインスタンスが生成されるためMCP-Session-Idを共有できない という制約とのトレードオフであり、「セッション保持を諦める代わりに複数ワーカー/プロセスでもスケールできる」という割り切り あたりが特に勉強になりました。特にセッション管理の話は、MCPサーバーをWebアプリケーションとして本番に乗せようとすると、ロードバランサーやスケールアウトとの兼ね合いが出てくるという点で実践的でした。 ステートフル/ステートレスをどう使い分けるか は、これから考えないといけないテーマになりそうです。 セッションの締めくくりで「LLMの 確率的な性質 を決定的なツールに組み込むことで、これまでの決定的なツールとは違う未来が描ける」という話があって、そこも印象的でした。MCPの サンプリング (サーバーがクライアント経由でLLM補完を要求する仕組み)や、 Elicitation (実行中にユーザーへ追加情報を問い合わせる仕組み)といった機能は、ツールの形そのものを変えそうな予感があります。 スライド: https://speakerdeck.com/koic/exploring-rubocop-with-mcp Day 2: Chasing Real-Time Observability for CRuby (Shintaro Otsuka さん) 2日目で一番テンションが上がったのがこのセッション。CRubyの実行状態を リアルタイムに3D可視化する というツール「rrtrace」の話でした。 普通のプロファイラはサンプリングベースで、後から集計して結果を見る形が多いですが、このツールは「いまこの瞬間にCRubyの中で何が起きているか」を、複数スレッドのスタック状態として3次元空間にレンダリングしながら見せる、というアプローチです。デモを見せてもらった時、IRBに入力するたびにスタックが積み上がっていく様子がリアルタイムで見えて、純粋に「すごいものを見ている」という感覚になりました。 技術的なポイントとしては、 計測側のC拡張は軽量に保つ設計 で、イベントの収集と転送に特化している イベントは TracePoint API ( CALL / RETURN / INTERNAL_GC_ENTER / INTERNAL_GC_EXIT )や内部のスレッドイベント( INTERNAL_THREAD_EVENT 、こちらはWindowsでは利用不可)から収集し、timestamp(60bit) + event type(4bit) + method id/thread id(64bit)の合計16バイトの構造体に統一 C拡張(計測側)とビジュアライザプロセスの間は OS管理の共有メモリ上のリングバッファ で受け渡し ビジュアライザ側はCRubyのコアを使っていない別プロセスなので、可視化処理が重くてもCRubyの実行を直接ブロックしない スタックシミュレーションが重いため、 Parallel Scanアルゴリズム で並列化している という設計でした。ただし、スライドのベンチマーク結果を見ると、rrtrace有効時は 関数呼び出しスループットがplain CRubyの17%程度 (73,417,127 → 12,760,131 calls/s、約5.9倍遅くなる)、 Railsサーバーのrpsもplain CRubyの55%程度 (203.19 → 110.84 rps)になるとのことで、 計測のオーバーヘッド自体は「小さくない(not small)」 とスライドでも明記されていました。TracePointフックのコストが支配的で、ここは今後の課題とのことです。 それでも、「 重い処理を別プロセスに全部寄せる 」というアーキテクチャの考え方は面白かったです。計測側はできるだけ軽く保って、分析・可視化は別のリソースでやる。この割り切りが設計をシンプルにしていて、きれいだなと思いました。 「現代のマシンは10コア以上あるのが普通で、CRubyが1コアで動くなら残りのコアを観測やビジュアライズに自由に使える」という、リソースの捉え方の話も新鮮でした。GVLがある世界での観測ツールの設計思想として、納得感が強かったです。 スライド: https://speakerdeck.com/whitegreen/chasing-real-time-observability-for-cruby Day 3: The Less-Told Story of Socket Timeouts (Misaki Shioi さん) 3日目に聴いたのがこれ。ソケットライブラリのタイムアウトの 歴史と内部実装 を、Issue/Commitを参照しながらRuby 4.0までの流れに沿って解説していくセッションでした。タイトルからして気になっていたけど、期待以上の内容でした。 Socket.tcp / TCPSocket.new には、 resolv_timeout (名前解決のタイムアウト) connect_timeout (接続のタイムアウト) そしてRuby 4.0で追加された open_timeout (全体のタイムアウト) の3種類があります。「この3つがなぜ必要で、どういう順番で導入され、どんな歴史的な紆余曲折があったのか」を、Issue/Commitを参照しながら丁寧に追っていく構成でした。 特に印象的だったのが、 まず Socket.tcp に connect_timeout が導入され、続いて Addrinfo.getaddrinfo への timeout および Socket.tcp への resolv_timeout が追加されたこと resolv_timeout と connect_timeout を両方指定しても、全体のタイムアウト時間は制御できない (複数アドレスに対して逐次接続を試行するため、合計時間が想定より長くなりうる) これらの問題を解決するために、Ruby 4.0で 全体時間を管理する open_timeout が追加された という話の流れです。普段、HTTPクライアントの open_timeout / read_timeout / write_timeout を「だいたいこのくらい」で設定しがちですが、その下のレイヤーでは名前解決と接続が並行で走っていて、 タイムアウトの組み合わせによっては想定と全然違う挙動になる ということを、改めて意識させられました。 また、歴史的な経緯として特に面白かったのが、 名前解決の中断可能化(interruptible)をめぐる話 です。 getaddrinfo(3) はブロッキング呼び出しで、 Ctrl+C でも中断できないという問題が長年ありました。これを解決するアプローチとして、まず 2020年1月に「 Addrinfo.getaddrinfo が timeout をサポートする」提案が行われ、そのパッチで Addrinfo.getaddrinfo に timeout 、 Socket.tcp に resolv_timeout が追加されると同時に、内部的に「GNU拡張の getaddrinfo_a(3) が利用可能ならそれを使う」実装が入りました ( getaddrinfo_a(3) はワーカースレッドで非同期に名前解決を行う仕組み)。その後 2020年8月には「Make Socket.getaddrinfo interruptible」がマージされ、 Socket.getaddrinfo の内部もこの getaddrinfo_a(3) を使うように利用範囲が拡張 、さらに 2020年9月には TCPSocket.new にも resolv_timeout / connect_timeout が追加 され、名前解決を中断可能にする方向で進められました。 ところがその後、 Rails ActiveJobの統合テストが失敗するようになった という報告が入り、調査の結果、 fork後の子プロセスで getaddrinfo_a(3) を呼び出すとハングする ことが判明します。 getaddrinfo_a(3) は内部で再利用可能なワーカースレッドを保持しているのですが、forkでコピーされる子プロセスにはワーカースレッドが存在しないにもかかわらず内部状態は「ワーカースレッドが待機中」のままになっており、これによってデッドロックが発生する、という仕組みでした。 2ヶ月以上の調査と回避策の検討を経て、最終的には getaddrinfo_a(3) の導入自体が撤回 され、関連変更もrevertされました。その代わり、後に別アプローチとして 「名前解決ごとに専用のpthreadを立てて getaddrinfo(3) を実行する」方式 (mameさん提案、 ruby/ruby#8695 )が採用され、こちらは rsock_getaddrinfo 内に実装されることで、内部的に rsock_getaddrinfo を呼んでいる Addrinfo.getaddrinfo や Socket.getaddrinfo を含む幅広いメソッド で名前解決のブロッキング問題が解消された、という流れです。 外部API連携で「タイムアウトを設定したはずなのにハングする」「 connect_timeout を短くしたのに、複数アドレスがあるホストで合計時間が想定の何倍もかかる」みたいな経験がある人は少なくないと思いますが、まさにあれの背景にある話でした。タイムアウト設計の見直しや、Ruby 4.0以降は open_timeout を積極的に使っていくこと、テストでタイムアウト周りの挙動を確認しておくことなど、すぐに持ち帰れる学びがいくつもありました。 スライド: https://speakerdeck.com/coe401_/the-less-told-story-of-socket-timeouts リモートワーク時代の副次効果 もう一つ書いておきたいのが 社内メンバーとの関係性 の話です。 弊社エンジニアはリモートワーク中心で、普段の業務だと開発チームの全員と毎日話すわけではありません。SlackやZoomでは話すけれど、雑談ベースで「最近どう?」みたいな会話になりにくい人もいます。 それが、RubyKaigiで3日間一緒に過ごすと一気に距離が縮まります。一緒にセッションを聞いて、休憩中に「今のどう思った?」と話して、夜は飲みに行って、移動中に雑談する。この3日間の密度は、リモートでの数ヶ月分のコミュニケーションに相当するんじゃないかと思います。 おわりに RubyKaigiは「Ruby本体に関わっている人たちのお祭り」という側面が強いカンファレンスですが、Rubyを本番で動かしている側の人間にとっても十分に楽しめる場でした。SREとしても、ランタイムの理解が深まったり、他社の運用知見をもらえたり、社内の関係性が深まったりと、副次効果を含めて満足度の高い3日間でした。 普段Railsを動かしているSREの方や、これからRubyKaigiどうしようかなと迷っている方の参考になれば嬉しいです。