本記事は 2026 年 4 月 30 日に公開された Ankit Sharma、Brian Beach による “ Amazon Q Developer end-of-support announcement ” を翻訳したものです。 私たちが Amazon Q Developer を立ち上げたときの目標は、AI による支援を開発者の作業の流れに直接組み込むことでした。お客様は VS Code、JetBrains、Eclipse、Visual Studio にわたって Q Developer を導入し、コード生成やデバッグ、チャットベースのガイダンスに活用してきました。Q Developer は、AI が日々の開発サイクルに欠かせない存在であることを証明しました。 この 1 年で私たちが学んだのは、もっともインパクトのある AI 開発者体験はコード生成や補完にとどまらないということです。開発者には、プロジェクト全体 —— アーキテクチャ、要件、テスト、そしてコードの背後にある意図 —— を理解する AI が必要です。そのためには、専用に設計された環境が必要になります。それこそが、私たちが Kiro を構築した理由です。 Kiro とは 、仕様駆動開発（spec-driven development）のためにゼロから構築されたエージェント型の開発環境（IDE、CLI）です。個別のプロンプトに反応するのではなく、構造化された仕様をもとに計画・実装・検証をコードベース全体にわたって進めます。主な機能は次のとおりです。 Specs —— 構築したいものを構造化された自然言語の要件として定義し、Kiro がそれをもとに実装を最初から最後まで進めます。 Hooks —— ファイル保存やコミットなどのイベント発生時に自動で実行されるトリガーです。手動での操作なしに、標準の適用、テストの実行、ドキュメントの更新を行います。 Steering files —— プロジェクト単位の設定ファイルで、アーキテクチャや規約、制約についての永続的なコンテキストを Kiro に提供します。 Custom subagents —— セキュリティレビュー、API 契約の検証、インフラのプロビジョニングなど、ドメイン固有のタスクのために自分で定義できる専用の AI エージェントです。 Powers —— Kiro のエージェント的な振る舞いを自分の開発プロセスに合わせて拡張できる、組み合わせ可能な機能モジュールです。 Kiro には、現在の Q Developer で開発者が活用している機能もすべて含まれています。エージェント型コーディング、インラインチャット、ターミナル統合、そして MCP サポートです。 何が変わるのか Amazon Q Developer の IDE プラグインと有償サブスクリプションは、2027 年 4 月 30 日にサポートを終了します。お客様には Kiro への移行期間として 12 か月が用意されています。 2026 年 5 月 15 日以降、新規サインアップを受け付けなくなります。 IDE プラグインから Builder ID を用いた Q Developer 無料利用枠アカウントの新規作成、および AWS コンソールからの Q Developer サブスクリプションの新規作成はブロックされます。 モデルが変更されます。  2026 年 5 月 29 日より、Q Developer Pro では Opus 4.6 が利用できなくなります。Opus 4.5 やその他の既存モデルは引き続き利用できます。Opus 4.7 を含む最新のコーディングモデルは Kiro でのみ利用できます。 既存のお客様はアクセスを維持できます。 Q Developer Pro サブスクリプションまたは Kiro サブスクリプションを通じて Q Developer をご利用の場合、2027 年 4 月 30 日までは引き続き Q Developer の IDE プラグインにアクセスできます。2026 年 5 月 15 日の変更は、Q Developer アカウントおよびサブスクリプションの新規サインアップにのみ影響します。 IDE プラグインの掲載は継続します。 Q Developer のプラグインは、4 つの IDE マーケットプレイスすべてで引き続き公開され、ユーザーを Kiro へ案内する非推奨の通知が表示されます。移行期間中は、既存ユーザー向けに重要なバグ修正の配信が継続されます。 何が変わらないのか AWS マネジメントコンソールおよび AWS ファーストパーティの体験（AWS マーケティングサイト、AWS ドキュメントサイト、AWS Console Mobile App、チャットアプリ向け Amazon Q Developer —— Slack および Microsoft Teams）における Amazon Q Developer は、今回のサポート終了の影響を受けず、引き続き AWS のお客様にご利用いただけます。これらのプロダクトで Q Developer をお使いのお客様は、現在のサブスクリプションの特典と機能を引き続きご利用いただけます。 お客様にお願いしたいこと 今日から Kiro を試してみてください。 kiro.dev から Kiro をダウンロードし、次のプロジェクトで仕様駆動開発を体験してみてください。 ご利用の IDE に合わせた 移行ガイド をご確認ください。 移行についてご質問がある場合は、担当の AWS アカウントチームまでお問い合わせください。 私たちは AI を活用した開発の未来にわくわくしており、すべてのお客様にとってこの移行ができる限りスムーズなものとなるよう取り組んでいきます。 翻訳は App Dev Consultant の宇賀神が担当しました。

はじめに このAdvent Calendarも、いよいよ最終日となりました。 これまで、この20年間に私が書いてきたWeb記事を振り返ってきましたが、最後にそこで感じたことを「変化」「責任」「挑戦」「感謝」の4つのキーワードでまとめたいと思います。やや自分語りの部分もありますが、最終回としてお付き合いいただければ幸いです。 変化 この20年で、本当にさまざまな変化がありました。 扱うテーマの変化＝技術の変化 テストや品質を軸としながら、新しいテーマが次々と加わってきました。 序盤（2006～2012年） テスト自動化（1日目、5日目、8日目、9日目）、メトリクス（2日目）、

この記事は NTT docomo Business Advent Calendar 2025 9日目の記事です。 Unitree Go2はROSの通信ミドルウェアとしてEclipse Cyclone DDSを利用していますが、DDSはNATを越えられないという課題があります。 この課題に対し、DDSをZenohにブリッジしてNAT越えを実現する事例がコミュニティでいくつか紹介されています（1 1 , 2 2 , 3 3 ）。 本記事ではこのアプローチをUnitree Go2に適用し、zenoh-plugin-ros2ddsを用いて Unitree Go2が扱うDDSメッセージをインターネット越しに送受信する方法を紹介します。 はじめに 環境 前提知識 Unitree Go2 ROS Zenoh 実装 ビルド 実行 まとめと今後の取り組み 参考 はじめに こんにちは。イノベーションセンターの柴原です。普段はエッジコンピューティング基盤技術の検証や生成AIアプリケーションの開発に取り組んでいます。 フィジカルAIという言葉を聞いたことがあるでしょうか。生成AIの次に来るテーマとして注目されており、物理世界を理解して自律的に行動するAIを指します。 フィジカルAIの発展により、ロボットがこなせるタスクの幅は飛躍的に広がっています。 一方で、ロボットにはバッテリー容量や搭載できる計算リソース量に制約があります。 これらの制約を克服するためには、クラウドをはじめとするロボット外部の計算リソースを活用することが不可欠になると考えています。 そこで本記事では、クラウドからロボットを制御するための第一歩として、キーボード入力でロボットを操作する簡単なデモを作成したので紹介します。 環境 次のような環境で実装しました。 機種: Unitree Go2 R&D Plus Docking Station (Jetson Orin NX)：Ubuntu 22, ROS 2 Humble クラウド (Azure VM): Ubuntu 22, ROS 2 Humble 前提知識 Unitree Go2 Unitree Robotics社の小型四足歩行ロボットです。今回扱うGo2 R&D Plusは公式SDKを利用して二次開発ができるモデルです。 ROS ROS (Robot Operating System)はロボットのソフトウェア開発においてデファクトスタンダードのプラットフォームです。 通信方法やセンサ値のデータ構造、パッケージ管理機能を提供しており、Unitree Go2もROSを利用した二次開発が可能です。 Zenoh Unitree Go2はROSに対応していますが、その通信ミドルウェアはCyclone DDSに固定されています。 Cyclone DDSは隣のROSノードを自動発見するためにマルチキャストを使用するなどLAN向けに設計されており、NAT越えが困難です。 一方ROSの世界ではWANに対応した通信ミドルウェアとしてZenohが注目されています。現在ROSの最新バージョンであるJazzyでは公式にサポートされているようです。 Zenohの提供元であるEclipseはZenoh・Cyclone DDS間のブリッジも提供しており、これを利用してインターネット越しの通信を実現している事例がいくつかあります。 本記事ではZenohとブリッジを利用してインターネット越しにGo2のセンサ値を読み取り、キーボードからGo2を操作するところまでを実装します。 実装 TechShare社の 【Unitree Go2】キーボードからGo2を操作する２次開発方法 を基に、これをインターネット越しで実行します。 ビルド . └── workspace/ ├── docker/ │ ├── Dockerfile.azure │ ├── Dockerfile.jetson │ └── docker-compose.yml ├── src/ │ ├── ros/ │ │ ├── unitree_ros2/ │ │ └── cmd_vel_control/ │ ├── zenoh/ │ └── zenoh-plugin-ros2dds/ ├── zenoh-config-azure.json └── zenoh-config-jetson.json Docking StationのOS・ROS環境は、 unitree_ros2 の .devcontainer/docker-compose.yaml で定義されている devcontainer-humble サービスを使います。 クラウド側マシンでも同じサービスを、ベースイメージをARMのものからx64のものに変更して使います。 docker/ はこれらを移動しただけです。 src/ 配下に利用するパッケージを配置しています。 unitree_ros2 : Go2を二次開発するためのROSパッケージ cmd_vel_control : 【Unitree Go2】キーボードからGo2を操作する２次開発方法 で作成されたROSパッケージの一部 zenoh (Commit: 44f8b2489) : Zenoh本体を提供するRustパッケージ zenoh-plugin-ros2dds (Commit: 592422b) : Zenoh <-> CycloneDDSのブリッジを提供するRustパッケージ zenoh-plugin-ros2ddsはzenohに依存しており、バージョンによってビルドできないことがあるのでcommitを指定しています。これらをクラウドとJetsonそれぞれに配置し、コンテナ内で src/ をビルドします。 Clone git clone https://github.com/shibahara2/ros2_ws.git cd ros2_ws git submodule udpate --init --recursive コンテナに入ります。 cd docker docker compose up unitree_ros2-<azure or jetson> -d docker exec -it unitree_ros2-<azure or jetson> zsh Rustをインストールします。 curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh source /root/.cargo/env rustup update zenohをビルドします。 cd src/zenoh cargo build --release zenoh-plugin-ros2ddsをビルドします。 cd src/zenoh-plugin-ros2dds cargo build --release ROSパッケージをビルドします。 cd src/ros colcon build 実行 クラウド上でzenohdを起動します。 # Cloud terminal 1 src/zenoh/target/release/zenohd -c zenoh-config-azure.json ポート7447でクライアントを待ちます。モード (router/peer/client)やプラグインのPATHを以下のjsonで設定しています。 $ cat zenoh-config-azure.json { mode: "router", plugins: { ros2dds: { __path__: "src/zenoh-plugin-ros2dds/target/release/libzenoh_plugin_ros2dds.so", } }, listen: { endpoints: ["tcp/0.0.0.0:7447"] }, } Jetson上でzenohdを起動します。 # Jetson terminal 1 src/zenoh/target/release/zenohd -c zenoh-config-jetson.json クラウドのzenohdに接続します。設定は以下の通りです。 $ cat zenoh-config-jetson.json { mode: "client", plugins: { ros2dds: { __path__: "src/zenoh-plugin-ros2dds/target/release/libzenoh_plugin_ros2dds.so", } }, connect: { endpoints: ["tcp/<クラウドのグローバルIP>:7447"] } } zenohd同士を接続すると勝手にトピックが同期され、クラウド上でJetson上のトピックが見られるようになります。 Go2のセンサ値を確認してみます。 # Cloud terminal 2 source src/ros/install/setup.sh export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp ros2 topic echo /sportmodestate 結果（最初の一部） --- stamp : sec : 1765203140 nanosec : 497936758 error_code : 1001 imu_state : quaternion : - -0.9969053864479065 - 0.005156185943633318 - 0.05559273064136505 - 0.05533893033862114 続いてクラウドからロボットを操作します。 クラウド上でノードを起動します。 # Cloud terminal 2 ros2 run teleop_twist_keyboard teleop_twist_keyboard ノード teleop_twist_keyboard はキーボード入力を受け付け、トピック /cmd_vel へpublishします。 Jetson上でノードを起動します。 # Jetson terminal 2 ros2 run unitree_ros2_example cmd_vel_control ノード cmd_vel_to_sport_request はトピック /cmd_vel をsubscribeし、トピック /api/sport/request へpublishします。これが低レイヤーの命令に変換されていき、最終的にモーターが駆動します。 実行の様子です。 このブラウザーは埋め込み動画に対応していません。 ターミナル画面が4分割されており、左上はクラウド上でzenohd、左下はJetson上でzenohd、右上はクラウド上でROSノード teleop_twist_keyboard 、右下はJetson上でROSノード cmd_vel_to_sport_request を実行しています。 (本来かなり運動性能が高いのですが、6畳の部屋では一歩が限界でした。) まとめと今後の取り組み 本記事ではUnitree Go2をクラウドから制御する簡単なデモを作成しました。 クラウド側の処理がシンプルだったため、Zenohにこだわる理由が伝わらなかったかもしれません。 確かにリアルタイム性を求めないアプリであれば、他に適したプロトコルがあります。 状態監視・ログ収集・UIといった処理は、MQTTやREST、WebSocketを使ってクラウド側に簡単に実装できます。 しかし私はロボットの制御ループそのものをどこまでオフロードできるかに興味があります。遅延やジッタがロボットの挙動に直結するため、ROSが提供する（予定の）Zenohを使うのが良さそうだと判断しました。 今後の取り組みとして、以下を調査したいです。 他プロトコルとの比較 SLAMや経路計画など、ロボットの制御ループのうち遅延の制約がそこまで厳しくない処理をクラウドで実行可能か フィジカルAIがロボットの制御ループに組み込まれることで、遅延の制約がどう変化するか またNTTドコモビジネスは docomo MEC というモバイル回線の基地局の側に置かれたエッジサーバーや、 5Gワイド という優先制御サービスなど、低遅延・低ジッタの基盤を提供しています。 これらのサービスを利用することで遅延・ジッタの制約が緩和され、オフロードできる範囲が広がるかもしれません。 本日はここまでです。明日の記事もお楽しみに！ 参考 zenoh-bridge-ros2ddsでZenohとROS 2間通信 ↩ ROS 2のZenoh対応とZenohのROS 2対応 ↩ Zenoh bridge を用いた ROS 2 の通信性能評価 ↩