はじめに この記事は、BASEテックブログ夏のブログリレー10日目の記事です。 こんにちは、Data Strategyチームの竹内です。 BASEでは日々数多くの多種多様な商品が新しく登録されています。それらの商品が「何のカテゴリの商品なのか」を機械学習モデルで自動的に推論する仕組みを、以前からバッチ処理基盤として運用してきました。 今回、そのモデルを 商品テキストと商品画像の両方を入力に取るマルチモーダルなモデル に置き換えたので、その経緯やモデルの中身について紹介します。 はじめに TL;DR なぜ商品カテゴリを推論するのか これまでの取り組みと、画像を使いたくなった理由 使用したモデル 1. 画像を3つのトークンに変える 2. 画像特徴を「BERTのトークン」に翻訳する 3. 1本のTransformerに流し込む 4. 分類と埋め込みの取り出し 結果 埋め込みベクトルの活用 おわりに ※ 記事内のコードはサンプルとして簡略化しています。 TL;DR 商品タイトル・説明文などのテキストと、商品画像の両方を入力とする商品カテゴリ分類モデルを作成しました モデルは MMBT（Supervised Multimodal Bitransformers）をベースに、画像側を Swin Transformer、テキスト側を日本語BERT（ tohoku-nlp/bert-base-japanese-v3 ）に置き換えたものです 学習データは約100万件の商品で、ラベル（498クラスの階層カテゴリ）はLLMによるアノテーションで付与しました なぜ商品カテゴリを推論するのか BASEには毎日さまざまな商品が登録されますが、「その商品がどのカテゴリに属するか」を横断的に把握することは困難です。ショップ側で設定されたショップカテゴリは任意項目であり、また「ショップのカテゴリ」と「そのショップが実際に売っている個々の商品のカテゴリ」は必ずしも一致しません。 そこで、商品ごとにカテゴリを機械学習で推論して付与しています。用途は大きく3つあります。 分析基盤としての提供 … カテゴリごとの流通額・登録数・不正決済の発生状況といった、商品全体像に対する解像度を上げるための分析軸 不正検知モデルの特徴量 … 不正決済の検知や不正な商品登録の検知など、各種モデルの特徴量として利用 プロダクトでの活用 … 推薦や検索など、アプリ側の機能での利用 これまでの取り組みと、画像を使いたくなった理由 商品カテゴリの推論そのものは新しい取り組みではなく、2022年にBERTを使ったモデルとその推論基盤について記事を書いています。 devblog.thebase.in このときのモデルは商品タイトルと説明文を結合したテキストのみを入力とするもので、記事でも画像の利用は今後の課題としていました。 商品によっては、説明が簡素で短いものや、購入者とのやり取りや注意事項のみを記載しているものなど、テキストだけでは何の商品か判断できない商品が一定数あります。一方で、そうした商品でも画像を見れば人間には一目で分かることが多くあります。 逆に、商品の外装やイメージだけのものなど、画像だけでは判断がつかない商品も存在します。テキストと画像は互いに補い合う関係にあり、両方をバランス良く扱えるようにしたい、というのがマルチモーダルモデルを使用する主な動機となります。 あわせて、分類先のカテゴリも見直しています。従来のモデルは100クラス程度の分類モデルであったのに対し、今回は階層構造を持つカテゴリマスタのフルパス（例: グルメ・飲料/スイーツ・お菓子/ケーキ ）を1つのクラスとみなした 498クラスのシングルラベル分類にしています。 使用したモデル マルチモーダルなモデルには様々な選択肢がありますが、今回は MMBT (MultiModal BiTransformer) を採用しました。 github.com アイデアはとてもシンプルで、画像を数個の「単語」のようなトークンに変換して、テキストトークンと一緒に同じ1本のTransformerに流し込むというものです。画像とテキストをそれぞれ別のエンコーダに通して最後にベクトルを結合するのではなく、最初から同じself-attentionの中で混ぜてしまうアプローチになります。 https://arxiv.org/abs/1909.02950 より引用 その際、attention内で個々のトークンがどのモーダルに対応するのかを、Token Type Embedding（セグメント埋め込み）によって区別しています。こちらは従来、テキスト文が質問と回答のどちらに該当するかなどのマーカーとして使用していたものですが、MMBTではそのトークンが属するモーダルによって値を変えたEmbeddingを位置埋め込みなどと同様に、それぞれのトークンに加算しています。 また、本実装では、論文のオリジナル実装から次の2点を置き換えています。 画像エンコーダ: ResNet → Swin Transformer ( swin_base_patch4_window7_224.ms_in22k ) テキストエンコーダ: 英語BERT → 日本語BERT ( tohoku-nlp/bert-base-japanese-v3 ) 実装は責務ごとに4つのクラスを積み上げる形になっています。以下、内側から順に見ていきます。 1. 画像を3つのトークンに変える ImageEncoder は、224×224 の画像を Swin Transformer に通して 7×7 の特徴マップにし、それを3つの領域に平均プーリングして3本の特徴ベクトル（各1024次元）に要約します。この3本が「画像トークンの素」になります。 class ImageEncoder (nn.Module): def __init__ (self, num_image_embeddings: int = 3 ): super ().__init__() model = timm.create_model( "swin_base_patch4_window7_224.ms_in22k" , pretrained= True , num_classes= 0 , ) # avg poolingと最後のlinear層を除外 modules = list (model.children())[:- 2 ] self.model = nn.Sequential(*modules) self.pool = nn.AdaptiveAvgPool2d((num_image_embeddings, 1 )) def forward (self, x): out = self.model(x) out = out.permute( 0 , 3 , 1 , 2 ).contiguous() out = self.pool(out) out = torch.flatten(out, start_dim= 2 ) return out.transpose( 1 , 2 ).contiguous() 画像を何トークンに要約するかはハイパーパラメータで、ここでは3としています。トークン数を増やすほど画像の情報は細かく残せますが、そのぶんテキストに使えるトークン列が短くなります。 2. 画像特徴を「BERTのトークン」に翻訳する BERTのテキストトークンの埋め込みは、実際には 単語埋め込み + 位置埋め込み + セグメント埋め込み の足し算でできています。画像トークンもまったく同じ作り方にすることで、BERTは画像をテキストトークンと同様に扱うことができます。 ImageBertEmbeddings では、 Swin の出力（1024次元）を nn.Linear(1024, 768) でBERTの隠れ次元に射影し 位置埋め込みはテキスト側と同じものを共有し 画像かテキストかを区別するセグメント埋め込み （ nn.Embedding(2, 768) ）を新たに定義して加算する という処理を行います。BERTの実装によってはそのまま使える token_type_embeddings が無いケースがあるため、こちらで定義しています。 さらに先頭に [CLS] 、末尾に [SEP] の単語埋め込みを足すので、画像トークンの個数が3の場合、常に 固定長5トークン の並びになります。 [CLS] 画像1 画像2 画像3 [SEP] テキスト1 テキスト2 ... テキストN [PAD] ... |___________________________| |_________________________________________| 画像トークン（固定5個） テキストトークン（可変長） テキスト側は日本語BERTのtokenizerでトークン化し、最大長は 512 - 画像トークン数 に切り詰めます。 3. 1本のTransformerに流し込む MultimodalBertEncoder は、画像トークン列とテキストトークン列を横に連結して1本のシーケンスにし、BERTのエンコーダに通します。 このとき attention mask は、 画像部分は常に1 （必ず全部見る）、テキスト部分は実トークンだけ1・パディングは0、という形で作っています。 attention_mask = torch.cat( [torch.ones(bsz, self.num_image_embeds + 2 ).long(), attention_mask], dim= 1 , ) extended_attention_mask = attention_mask.unsqueeze( 1 ).unsqueeze( 2 ) extended_attention_mask = extended_attention_mask.to(dtype= next (self.parameters()).dtype) # 1の部分は0に、0の部分は-10000.0に変換する extended_attention_mask = ( 1.0 - extended_attention_mask) * - 10000.0 あとは通常のBERTと同じで、全トークンが互いに attention を張り合い、最後に pooler が全体を768次元のベクトルに要約します。 4. 分類と埋め込みの取り出し 最後の MultimodalBertClf は、pooler の出力（768次元）を nn.Linear(768, クラス数) に通してカテゴリのスコアを出すだけの薄いクラスです。 class MultimodalBertClf (nn.Module): def __init__ (self, n_classes, model, vocab, hidden_size: int = 768 ): super ().__init__() self.enc = MultimodalBertEncoder(model=model, vocab=vocab) self.clf = nn.Linear(hidden_size, n_classes) def forward (self, txt, mask, segment, img): return self.clf(self.enc(txt, mask, segment, img)) def embeddings (self, txt, mask, segment, img): # 分類前の特徴量を返す return self.enc(txt, mask, segment, img) この768次元ベクトルは「商品テキストと商品画像の両方を要約したベクトル」なので、カテゴリ分類以外の下流タスクにも転用できます。推論時にはカテゴリと一緒にこの埋め込みも保存しています。 結果 学習はGeForce RTX 5090を積んだオンプレサーバーで数日程度行い、検証データ全体でのaccuracyは90%でした。推論バッチの作成後、新規登録された商品を対象に定性的な検証も実施したところ、498クラスのうち比較的少数のクラスに関しても、ある程度正確に推論できていました。 また、従来のテキストのみによる分類では判別が難しかった商品についても、適切に分類できていることが確認できました。 埋め込みベクトルの活用 先述の通り、このモデルからはカテゴリだけでなく、分類器手前の768次元の埋め込みベクトルも取り出せます。これは「テキストと画像の両方を踏まえた商品の表現」なので、カテゴリという498個の枠に丸める前の、より細かい情報を持っています。 手元で近傍探索を試すと、同じカテゴリの中でも見た目や商品の雰囲気が近いものが上位に並ぶことが確認できました。この埋め込みは、商品の推薦や検索、あるいは他の機械学習モデルの特徴量としての活用を想定しています。 おわりに 今回は、テキストと画像の双方を扱うマルチモーダルモデルによる商品カテゴリ分類の取り組みを紹介しました。 今回利用したMMBTは、それぞれのモーダルのエンコーダをある程度自由に選択できる点、クラス分類に特化しており実装がシンプルな点が魅力です。また、少し工夫を加えれば複数の画像への対応や画像以外のモーダルの利用もできそうであり、今後も活用の幅を広げられたらと思っています。 最後に、BASEでは様々な職種で一緒にプロダクトを作り上げていくメンバーを募集しています。 興味のある方は、ぜひお気軽に採用情報をご確認ください！ binc.jp 明日はoliverさんによる「顧客中心主義を開発の意思決定に組み込むために実践したこと」に関する記事です！

本記事は Physical AI デモ開発の技術解説シリーズ Part 2 です。 Part 1: 企画からステージ制作、アプリケーション開発まで では、企画からクラウド側アプリケーションまでの開発と、その過程での生成 AI 活用を紹介しました。Part 1 のまとめに「プロセスの型が品質を守る」という言葉があります。本記事はその続きです。実機のロボット開発では、この型に安全と物理世界の検証が加わります。 AWS Summit Japan 2026 の展示エリア「AWS EXPO」で私たちは、FANUC の協働ロボット CRX-20iA/L （以下、CRX）2 台と配送車両を使い、AI エージェントが配送経路上の障害物を見つけ、つかんで運び、配送を復旧するデモを展示しました（ 展示紹介記事 ）。2 日間の Summit 期間中、障害物のピックは失敗ゼロでした。ロボット向けの追加学習は行っていません。 本記事でわかることは次の 3 つです。 クラウド上で動く AI エージェントと、従来のロボット制御の役割分担 — 何を任せ、何を任せなかったか 開発者の手元で動くコーディングエージェント（Kiro や Claude Code のような AI コーディング支援ツール）を、実機が動く開発で安全に使うためのルール ROS 2 ベースの標準スタックとシミュレーター上での検証で、実機の試行錯誤を最小にする方法 — 豊富な公開情報がある OSS を活用することで、コーディングエージェントによる適切な提案が可能になります 図 1: AWS Summit Japan 2026 の展示フィールド。2 台の協働ロボットと配送車両、周回路を配置 ロボットシステムの構成 — 2 台の CRX と 1 つの AI エージェント このデモの設計は一言で表せます。判断はクラウド、実行はエッジ。状況を見て次の行動を決めるのは、 Amazon Bedrock AgentCore （AI エージェントの実行基盤）の上で動く AI エージェント（Claude Sonnet 4.6 / Claude Haiku 4.5）で、その判断が物理世界の動作に変わります。指令は AWS IoT Core を経由してエッジの ROS 2（センサーや制御機能を連携させるロボット向けのソフトウェア基盤）へ届き、その上で動作計画と衝突判定を担うライブラリである MoveIt 2 が軌道を計画して実機が動きます。本記事で扱うのは、このクラウドからエッジまでの一本の経路の作り込みです。クラウド側の作りは Part 1 をご覧ください。 エッジ側の構成はシンプルです。この ROS 2 スタックを載せた Ubuntu 24.04 の制御 PC が、CRX のコントローラーと 1 対 1 で接続します。1 対 1 に固定したのは、同じコントローラーへの二重接続を構成上防ぎ、トラブル時の切り分けを単純にするためです。アーム先端のカメラは、障害物の観察と位置・向きの計測の両方に使います。 このロボット側の仕組みは、ロボットチーム 4 名、およそ 2 か月の集中開発で作りました。以降の章では、この体制で本番 2 日間を走り切るために、どのようにエッジとクラウドの役割分担を決め、何を検証したかを工程順に紹介します。 図 2: 開発フィールドの全体像。2 台のロボットを背中合わせに配置し、中央の ChArUco ボード（チェスボードとマーカーを組み合わせた校正ボード）を共通の原点にした 設計 — 何をどこに任せるか 判断と動作の分離 クラウドの AI エージェントは、「アームを動かしてカメラの視点を変え、状況をさらに調べる」「アームで障害物を持ち上げて取り除く」「人に支援を求める」という選択肢から、次の行動を一つずつ選びます。観察も除去も実体はアームの動作であり、AI エージェントの選択がそのまま実機の動きになります。 ただし、任せるのは判断だけです。画像と言語による指示を入力として、動作指令までを一つのモデルで生成する VLA（Vision-Language-Action）モデルは採用せず、クラウドとエッジで役割を分けました。クラウド側では、Claude Haiku 4.5 がアーム先端のカメラ画像から障害物が何かを認識し、その結果を踏まえて Claude Sonnet 4.6 が次の手順を決めます。決めるのは「どの動作を、地図上のどこに対して行うか」までです。指令は、あらかじめ実装した動作（通路の探索、障害物の把持と搬送など）の指定と、フィールド共通の地図座標の組で届きます。受け取ったエッジ側は、その地図座標を自分のロボット座標系に読み替えます。そこへ至る軌道は、MoveIt 2 がその都度計画して実行します。 アームの姿勢や移動経路を AI エージェントに生成させることはありません。AI エージェントが指す障害物の位置も地図上の大まかな指定にとどめ、把持に使う正確な位置と向きは、エッジ側で、障害物に付けたマーカーをアーム先端のカメラで捉え、その見え方から OpenCV で計算した値で確定させます。クラウドが状況を見て意図を決め、エッジが意図を安全な動作に翻訳します。 この分け方で足りるかどうかは、扱う対象の性質で決まります。VLA が向くとされるのは、布を畳むように対象の形が変わり続け、見た目に応じて動きを作り続ける必要がある操作です。一方、今回のデモで扱う把持対象の障害物は形の変わらない剛体としました。把持の直前に位置と向きを計測してしまえば、あとの動きは事前に定義した把持動作と動作計画で組み立てられるため、AI エージェントの出力をロボットの動作指令に直結させる必要はありません。汎用モデルの判断と既存のロボット制御を組み合わせることで、追加学習なしに、柔軟な判断と実績ある制御の確実な動きを両立しました。 図 3: Claude Haiku 4.5 が画像から障害物を認識し、Claude Sonnet 4.6 が次の手順を判断する。クラウドの指令は AWS IoT Core を介してエッジ側の 2 台のロボットへ届く インターフェース仕様の先行合意 — 座標系・単位・通信 クラウドとロボットのインターフェース仕様で、機能一覧より先に固定したのは座標系と単位です。原点の位置、各軸の向き、右手系か左手系か、位置の単位（mm の整数）、角度の表現（度ではなくラジアン）。とくに座標軸の向きの取り決めが食い違うと、同じ数値が鏡写しの別の位置を指します。こうした座標系や単位の誤りは、数値としては正常なまま、ロボットが誤った場所へ動く形で現れるため、JSON の形式検証では見つかりません。 2 台のロボットの座標系は、フィールド中央に固定した校正ボード（図 2）を共通の原点として突き合わせています。障害物の位置計測に使うマーカーとは別物です。マーカーで測った位置を自分のロボットの座標へ正しく変換できるかは、この校正の精度で決まります。本番前に校正をやり直した際の実測は、校正点への当てはまり（RMSE）で 1〜4 mm でした。校正のずれは実行時のエラーとしては現れず、静かに精度だけを損ないます。 そこで、合意した値が現物と一致しているかを起動時に検証します。たとえば位置計測に使うマーカーは、印刷倍率が少しずれていても検出自体は成功してしまい、座標だけが誤った値になります。マーカー寸法の実測値と設定値を照合して、一致しなければ先へは進まず、担当者が設定を直して測り直すか、中止するかを選びます。人の注意力に頼らず、機械が先に気づく形にしておくのが要点です。 座標系と単位に加えて、通信も用途で分けました。 用途 手段 指令 AWS IoT Core の MQTT 5 Request/Response 配送車両の状態 AWS IoT Device Shadow （デバイスの最新状態をクラウドに写しとして保持する機能） 画像・深度 Amazon Simple Storage Service (Amazon S3) （大きなデータは指令の経路に載せない） 指令の配信方式では同じメッセージが重複して届き得るため、識別子を記録して重複実行を防いでいます。認証には AWS IoT Core の証明書ベースの仕組みを使い、長期のアクセスキーをデバイスに埋め込まずに一時的な認証情報を取得する構成にしています。 自前実装の最小化 ロボット制御スタックは、 FANUC 公式の ROS 2 ドライバー を土台に、エンドエフェクター（開閉式グリッパー）、仮想壁、クラウド連携などデモ固有の機能だけをパッケージとして追加しました。ドライバーは、Stream Motion という通信機能を使って動作データをやり取りします。これは FANUC のロボットコントローラー向けに提供される固有のインターフェースで、外部 PC から短い周期で動作指令を送り続けることで、コントローラーの外からリアルタイムに近い制御を可能にするものです。MoveIt 2 が計画した軌道は、この周期通信に載って実機で実行されます。ドライバー本体のコードは 1 行も変えず、設定の変更だけで 2 台を運用しました。動作計画・衝突判定は MoveIt 2、座標変換は ROS 2 の標準機能です。 図 4: MoveIt 2 による動作計画の様子（ROS 2 標準の可視化ツール RViz の画面）。白が現在姿勢、オレンジが目標姿勢で、黄色の線が自動生成された軌道。仮想壁（フィールド境界）などの制約を考慮した経路を自動で計画する 標準スタックを選んだ効果は、もう一つあります。ROS 2 も MoveIt 2 も OpenCV も公式ドライバーも、公開情報が豊富な OSS です。コーディングエージェントが学習し、参照できる情報が最も多い土俵であり、次章で紹介するコーディングエージェント活用の効果は、この選択に支えられています。 実装 — コーディングエージェントに任せる範囲の線引き ロボット側の開発でも、設計文書、実装、テスト、運用手順の多くをコーディングエージェントとともに作りました。実装リポジトリだけを数えても、約 7 週間で 400 を超えるコミットを重ねています。新規実装（feat）と修正（fix）が同数規模で回った週もあります。会場での現地調整も含めた追い込みの 3 日間には、100 件を超えるコミットが入りました。この開発スピードを維持しながら、実機の安全をどう確保するか。それが本章の主題です。Part 1 で紹介したクラウドアプリケーションの開発と違うのは、誤った変更が物理的な事故につながり得ることと、検証の最終段に「実機で動かす」という共有リソースの制約があることです。そこで、コーディングエージェントを速く走らせる工夫より先に、守るべき前提を毎回読み込ませる形で渡すことに時間を使いました。 開発ルールの文書化 多くのコーディングエージェントには、リポジトリに置いた文書を作業の最初に読み込む仕組みがあります。この文書に、コーディング規約だけでなく次を明文化しました。 一次情報の参照ルール: ロボット固有の挙動に関わる変更は、公式ドキュメントと公式ドライバーの実装を確認してから行う 禁則: 過去の事故につながった変更は、経緯とともに禁止事項として残す 完了条件: コード上のテストが通っただけでは不十分とする。実機をつながず、シミュレーター上のロボットモデルに軌道を実行させ、関節が動くことを RViz（ROS 2 標準の可視化ツール・図 4）の画面で確認する。スクリーンショットやログを検証エビデンスとしてリポジトリの所定の場所に残すところまでを条件とする この確認を回すために、シミュレーション用の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを検証環境として用意しました。環境の構築には、開発者ごとのリモート開発環境を AWS 上に用意するサンプルソリューション Remote AWS Development Station (RADS) を使っています。ROS 2 や MoveIt 2、コーディングエージェントまでセットアップ済みの GPU 環境をチームの各メンバーがすぐに使えるため、検証環境の整備に時間を取られません。この手順を開発ルールの文書に書いておくことで、コーディングエージェントは自分が書いた変更をこの環境で自律的に検証します。問題がなければリポジトリに push します。エッジ PC への接続とデプロイも AWS Systems Manager のセッション経由で同じ環境から行い、実機での実行だけは人の承認を得たうえで行います。実機に触れられる時間が限られていても、コードを書く速度と検証の速度を釣り合わせられます。 この文書はコーディングエージェントへの指示であると同時に、4 名のチームの合意の置き場でもあります。人もコーディングエージェントも同じ文書を参照するため、誰の作業でも判断が揃います。あわせて、影響の大きい設計判断は ADR（Architecture Decision Record、設計判断の記録）として残しました。クラウドと ROS 2 の間の通信で「一度目は動くのに二度目から応答しなくなる」問題にはまった際も、原因と結論を ADR に残したことで、以後の変更で同じ議論を繰り返さずに済んでいます。 影響範囲の大きい変更では、いきなりコードを書き始めず、まず仕様と設計上の懸念をコーディングエージェントに徹底的に洗い出させ、設計を固めてから実装に進むのも有効でした。2 台のロボットの座標系を統一する変更では、この段階で、誤った座標でも後述の安全制約を通過してしまう設計バグを実機に触れる前の机上で検出できています。 安全制約の先行実装 アームの進入を禁じる仮想壁、手先の向きを保つ姿勢拘束、関節角のリミットといった安全制約は、コーディングエージェントに考えさせる対象ではなく、人が最初に設計して実装しました。その上で、コーディングエージェントの作業範囲を 3 つに分けています。 変更できる: ROS 2 ノードの実装、説明ドキュメント 人の承認が要る: 座標系、校正値、プランナー設定、テストの変更、仮想壁や姿勢拘束など先行実装した安全制約の変更・無効化、開発ルール文書の禁則と完了条件の変更、実機での実行 コーディングエージェントの外で強制される: ロボットに標準搭載の接触停止機能、非常停止ボタンなどの物理 E-stop コーディングエージェントが必ず安全な変更をするとは限りません。先に制約を実装し、変更できる範囲と実行できる範囲を分けたため、その内側では思い切って任せられます。試行錯誤の速度と実機の安全は、この権限の分離で両立しました。 シミュレーションでの検証の必須化 実機を占有できる時間は限られます。個々の機能はコード上のテストで、動作計画はシミュレーター上での実行と RViz での目視で確認し、実機の時間は、グリッパーの把持力の加減や画像認識の精度といった、実物でしか確かめられない項目に充てました。 あわせて、軌道計算まわりの変更には、シミュレーター上での確認を検証ゲートとして毎回適用するのをチームのルールにしました。実機に触れる前に、シミュレーター上での実行が門番になる形です。 ただし、シミュレーター上の合格をそのまま信用はできません。シミュレーター上のロボットモデルは受け取った指令にそのまま応答するだけで、実機の条件の一部を省略しているからです。実際、ロボットに取り付けた周辺機器のケーブルやコネクターは、挙動のモデル化が難しく衝突判定に含めていませんでした。計画上は問題のない経路でも、実機ではこのコネクターがロボット自身の機体に当たりかけ、人が気づいて止める場面がありました。対処として、コネクターを覆う少し大きめの円柱を衝突判定のモデルに加え、計画の段階で自己干渉として避けるようにしています。シミュレーターが省略している条件は仕様に明記し、シミュレーター上で確認できる範囲と実機で確認すべき範囲を線引きしました。 安全要件の多層防護 開発中、動作計画が失敗し続けた際に、コーディングエージェントが原因を「手先を下向きに保つ」姿勢拘束だと誤判断し、一度無効化したことがあります。計画は通るようになりましたが、実機では障害物を持ったまま大回りして手先の向きが崩れる経路が選ばれてしまいました。原因は 2 つあり、別の変更で到達判定の許容誤差が厳しくなりすぎていたことと、姿勢を拘束した状態では既定の経路探索が解を見つけにくいことでした。許容誤差を直したうえで、探索アルゴリズムの変更や、失敗時に経由点を挿入する工夫によって、拘束を外さずに解決しています。「安全制約の先行実装」で述べた権限区分が、まだ固まっていなかった頃の出来事です。 トラブル対応では、コーディングエージェントも人も、早く解決するために制約を緩めがちです。だからこそ、安全要件は個々のプロンプトや作業指示に委ねず、層で守る形にしました。 動作計画上の制約: 仮想壁、姿勢拘束、関節角のリミット（「安全制約の先行実装」で人が先に実装したもの） ロボット側の保護機能: 接触停止機能、非常停止ボタンなどの物理 E-stop リポジトリの規約: 失敗の切り分け手段として拘束を外すことの禁止と、代わりに試す手順（規約自体の変更には人の承認が要ります） 検証: 実機に送る前の plan-only（実機へ送らず経路だけを計画）確認 この一件を機に、「禁止」と「代替手順」をセットで開発ルールに追記しました。禁止だけを書くと、行き詰まったコーディングエージェントや開発者は制約を回避しやすくなります。代替手順とセットで残すことで、次に同じ症状に出会っても、同じ近道を選ばずに済みます。なお、ここで挙げた拘束や仮想壁は動作計画上の制約であり、安全規格に基づく安全機能ではありません。接触停止や物理 E-stop の代わりにはならず、生産環境への適用では別途リスクアセスメントが必要です。 図 5: 姿勢拘束を維持しながら障害物を把持して退避させる動作 まとめ 今回の実装で重要だったのは、AI エージェントとコーディングエージェントに任せる範囲を広げることではなく、線を引くことと、検証することでした。AI エージェントには判断だけを任せ、動作は既存のロボット制御に。コーディングエージェントにはルールを文書で渡し、先に実装した安全制約の内側だけを任せる。そしてシミュレーター上での検証と起動時検証が、実機と本番を守ります。 同じ構成での検証は、実機がなくても今日から始められます。 ROS 2 と、その上で動く MoveIt 2 をセットアップする（いずれも公開されています。RADS を使うと、ROS 2 / MoveIt 2 / コーディングエージェント入りの環境を AWS 上にすぐ用意できます。実機をつなぐ段階で、ロボットのメーカー公式ドライバーやカメラのドライバーを加えます） コーディングエージェントに開発ルールの文書を渡し、シミュレーター上のロボットモデルで動作計画が解けるところまで作る AWS IoT Core でエッジとクラウドをつなぎ、Amazon Bedrock AgentCore 上の AI エージェントから動作の指令を受け取れるようにする（クラウド側の作りは Part 1 で紹介しています） 想定外への対応など、事前のルールでは書き切れない判断を含む業務（検査で不合格になった製品を、状態に応じて手直し・再検査・廃棄に振り分ける作業など）を一つ選び、判断を AI エージェントに、動作を既存制御に割り当てる クラウドに判断を置く構成は、この先に広がります。ロボットへの指令のインターフェースを揃えれば、判断の仕組みはそのままに、AI エージェントが扱うロボットの種類や台数を増やしていけます。生産管理や倉庫管理といった業務システムと連携した例外対応の仕組みも組めます。そしてコーディングエージェントが使う検証環境も、シミュレーターも、実機へのデプロイも、AWS の上で揃えられます。今回の開発で使った検証環境の仕組みは、 RADS として aws-samples で公開しています。 本記事が、お手元の産業用ロボットと AI エージェントを組み合わせる検討の出発点になれば幸いです。進め方や構成に迷う点があれば、ぜひ AWS にご相談ください。 関連リンク AWS Summit Japan 2026 Physical AI デモの裏側 Part 1: 企画からステージ制作、アプリケーション開発まで Physical AI – AI エージェントが現実世界で「見て、考えて、動かす」自律オペレーションの実現 Remote AWS Development Station (RADS) 著者について 河田 武之（Takeyuki Kawata） 河田 武之（Takeyuki Kawata）は、製造業のお客様をご支援しているソリューションアーキテクトです。電機メーカーやロボットベンチャーでロボット開発に携わったのち AWS に入社し、現在も Physical AI の領域で、VLA モデルの学習からシミュレーション、実機検証まで自ら手を動かしています。 大前 遼（Ryo Omae） 大前 遼（Ryo Omae）は、アマゾン ウェブ サービス ジャパン合同会社のソリューションアーキテクトです。製造業のお客様を中心に、クラウド活用の技術支援を行っています。好きな領域は機械学習やロボティクスで、最近は Physical AI に注力するあまり、部屋にロボットが溢れています。 西亀 真之（Saneyuki Nishigame） 西亀 真之（Saneyuki Nishigame）は、アマゾン ウェブ サービス ジャパン合同会社のソリューションアーキテクトです。好きな領域は IoT とロボットで、Physical AI に注力しています。 原田 裕平（Yuhei Harada） 原田 裕平（Yuhei Harada）は、製薬業界のお客様を中心にご支援しているソリューションアーキテクトです。技術領域では Physical AI や AI for Science を軸に、最近は自律開発や自律実験など、AI の自律性をどこまで高められるかの実践に取り組んでいます。

G-gen の杉村です。2026年8月に発表された、Google Cloud や Google Workspace のイチオシアップデートをまとめてご紹介します。記載は全て、記事公開当時のものですのでご留意ください。 はじめに Google Cloud のアップデート BigQuery で cross-cloud connections が Preview 公開 SCC で Malicious Skill runtime threat detectors が利用可能に BigQuery テーブルを AlloyDB へ同期する機能が Preview 公開 Gemini 3.7 Flash がリリース Gemini Enterprise app で Skills（スキル）が一般公開（GA） Agent Search の回答生成モデルに Gemini 3.5 Flash が登場 Antigravity in Gemini Enterprise がリリース Agent Identity auth manager が一般公開（GA） BigQuery の会話型分析（データエージェント）のモニタリング（Preview） Cloud SQL for PostgreSQL で「推奨事項の事前アセスメント」が Preview 公開 Cloud Run の新体系「Cloud Run instances」が Preview 公開 音声認識モデル Gemini 3.5 Transcribe が Preview 公開 新サービス Cloud FTP が一般公開（GA） 画像生成/編集モデル Gemini Omni 1.1 Flash が Preview 公開 VPC Flow Logs でドロップされたパケットのレコードが出力されるように Gemini Enterprise で Sensitive Data Protection のコンテンツポリシーが使用可能に BigQuery Graph が一般公開（GA） BigQuery の生成AI関数のトークンのクォータ（上限）が任意に設定できるように Google Workspace のアップデート Google Meet の自動メモ作成で投影物のスクリーンショット保存されるように Google Workspace Studio で Gemini Notebook にソースデータを追加可能に Excel ファイルを Google スプレッドシートにインポートする際の互換性が向上 Connected Sheets で「リストパラメータ」と「列名エイリアス」機能 Google Workspace のスプレッドシートで Sheets Canvas がリリース Take notes for me が Web 会議だけでなく対面会議でも使えるように Drive Inventory Reportingで外部共有関連の情報をエクスポートできるように Google Workspace Studio でエンタープライズ向けセキュリティ機能が強化 Google Chat に Workspace Intelligence のハブとなる Ask Gemini 画面が登場 Gemini アプリでインタラクティブな 3D モデルを生成できるように Microsoft OneDrive からのデータインポート（Advanced モード）が一般公開 Microsoft Teams からのチャット情報のデータインポート機能が一般公開 Google カレンダーで Teams や Zoom などからの招待がわかりやすく Google ドライブで AI によるデータ自動ラベリング機能がオープンベータ開始 予定主催者が受け取る出席可否メール通知をイベント単位で無効化できるように はじめに 当記事では、毎月の Google Cloud（旧称 GCP）や Google Workspace（旧称 GSuite）のアップデートのうち、特に重要なものをまとめます。 また当記事は、Google Cloud に関するある程度の知識を前提に記載されています。前提知識を得るには、ぜひ以下の記事もご参照ください。 blog.g-gen.co.jp リンク先の公式ガイドは、英語版で表示しないと最新情報が反映されていない場合がありますためご注意ください。 Google Cloud のアップデート BigQuery で cross-cloud connections が Preview 公開 Create cross-cloud connections (2026-08-03) BigQuery で cross-cloud connections が Preview 公開。 例として Amazon S3 上の Parquet ファイルを BigQuery から外部テーブルとしてクエリ可能。東京 / 大阪リージョンにも対応している。AWS、Azure、Salesforce Data 360 に対応 。 以下の記事も参照。 blog.g-gen.co.jp SCC で Malicious Skill runtime threat detectors が利用可能に Security Command Center release notes - August 04, 2026 (2026-08-04) Security Command Center で Malicious Skill runtime threat detectors が利用可能に。AI エージェントが悪意あるスキルをロードしたり実行したりすると検知。Agent Runtime、Cloud Run、GKE で実行されるエージェントに対応。脅威インテリジェンス「Google Threat Intelligence」を使用。 BigQuery テーブルを AlloyDB へ同期する機能が Preview 公開 Choose how to access BigQuery data from AlloyDB (2026-08-08) BigQuery テーブルを AlloyDB へ同期する機能が Preview 公開。 業務アプリ側から BigQuery データを利用可能になる。以下の手法から選択可能。 データを移動しない Lakehouse federation（処理は BigQuery 側にプッシュダウン） データ同期（ワンタイム） データ同期（定期スケジュール） Gemini 3.7 Flash がリリース Introducing Gemini 3.7 Flash (2026-08-13) Gemini 3.7 Flash がリリース。 「ソフトウェアエンジニアリング、知識労働、Web開発で大幅な改善」とされている。Agent Platform、Google AI Studio、Gemini Spark 等で利用可能。 また、Gemini 3.7 Flash および 3.6 Flash のトークンあたり料金が2026年12月31日までの限定で、半額で提供される。Agent Platform（Google Cloud）と Gemini Developer API（Google AI Studio）の両方でこの半額キャンペーンが適用される。 Gemini Enterprise app で Skills（スキル）が一般公開（GA） Create and manage skills (2026-08-13) Gemini Enterprise app で Skills（スキル）が一般公開（GA）。 タスクに特化したプロンプトや Bash/Python スクリプトを事前に定義しておける。呼び出し方は以下のいずれか。 アシスタントが自動で判断して読み込む プロンプト内でメンション形式で呼び出す プロンプト内の自然言語による指示で呼び出す Agent Search の回答生成モデルに Gemini 3.5 Flash が登場 Answer generation model versions and lifecycle (2026-08-13) Agent Search（旧称 Vertex AI Search）の回答生成モデルに Gemini 3.5 Flash が登場。 これまでの最新は gemini-3-flash-preview または gemini-3.1-pro-preview だった。RAG やそれにもとづく回答の精度向上に期待。 Antigravity in Gemini Enterprise がリリース Gemini Enterprise release notes - August 18, 2026 (2026-08-18) Antigravity in Gemini Enterprise がリリースされた。Gemini Enterprise 付属の Antigravity のことを指す。 少し前から既に使用可能だったが、正式にリリースノートに記載された。Gemini Enterprise の1ライセンスあたり、Standard なら$10、Plus なら $15 がプールされる。例として、Standard が 100 ライセンスあれば、$1,000 がプールされる。総ライセンス数分がプールされ、それをシェアして使用する形になる。 各種機能の有効化やロギングのオン・オフなども設定可能なほか、使用状況のモニタリングなど、各種統制機能が付帯しており、企業が Antigravity を使用するにあたり有用。詳細は以下の記事でも紹介。 blog.g-gen.co.jp Agent Identity auth manager が一般公開（GA） Agent Identity auth manager overview (2026-08-22) Agent Identity auth manager が一般公開（GA）。 AI エージェントによる外部ツール呼び出しの認証を一元管理でき、API キーやトークン保管、OAuth フローの実行、ヘッダーへの認証情報注入などをある程度マネージド化でき、セキュアになる他、コード簡素化にもなる。 BigQuery の会話型分析（データエージェント）のモニタリング（Preview） Create data agents (2026-08-24) BigQuery の会話型分析（データエージェント）のパフォーマンス、利用率、レイテンシ、コスト等を Cloud Monitoring 等で可視化可能になった（Preview）。 BigQuery の会話型分析の費用は、以下のとおり。2026-09-30まで無償トライアル期間であり、2026-10-01からの課金開始が予定されている。 参考 : Data Cloud Agent pricing and free trial Cloud SQL for PostgreSQL で「推奨事項の事前アセスメント」が Preview 公開 Assess recommendations for Cloud SQL in Database Center (2026-08-25) Cloud SQL for PostgreSQL で「推奨事項の事前アセスメント」が Preview 公開。 Database Center の推奨事項（マシンタイプ / エディション変更等）について、自動で事前にインスタンスをクローンしてベンチマークテストを行ってくれる。複製インスタンスの費用は発生する。 Cloud Run の新体系「Cloud Run instances」が Preview 公開 Assess recommendations for Cloud SQL in Database Center (2026-08-25) Cloud Run の新体系「Cloud Run instances」が Preview 公開。 既存の Cloud Run service と異なり、「単一リビジョン」「単一インスタンス」「長期稼働」「高コスト効率」。固有URLが与えられ起動停止等の管理が可能。ステートフルなワークロード等に使える。 以下の記事で詳細に解説。 blog.g-gen.co.jp 音声認識モデル Gemini 3.5 Transcribe が Preview 公開 Gemini 3.5 Transcribe (2026-08-26) 新しい音声認識モデル Gemini 3.5 Transcribe が Preview 公開。英語、日本語、韓国語、ポルトガル語、仏語など80以上の言語を正確に文字起こし。雑音や専門用語にも対応、フィラーは自動削除。リアルタイム用 API と、バッチ用の API がある。 Gemini Enterprise Agent Platform と Google AI Studio で提供開始。 新サービス Cloud FTP が一般公開（GA） Cloud FTP overview (2026-08-26) 新サービス Cloud FTP が一般公開（GA）。公開鍵認証で SFTP プロトコルの暗号化接続を確立し Cloud Storage との間でファイルをやりとりできる。 接続元 IP アドレス制限も可能。通常の SFTP なので Cyber​​duck、WinSCP などのクライアントが使用可能。 以下の記事も参照。 blog.g-gen.co.jp 画像生成/編集モデル Gemini Omni 1.1 Flash が Preview 公開 Gemini Omni 1.1 Flash Preview (2026-08-27) 画像生成/編集モデル Gemini Omni 1.1 Flash が Preview 公開。 マルチモーダルモデルであり入力として「テキスト、画像、動画」を、出力として「テキスト、動画 (音声付)」に対応。 Agent Platform と Google AI Studio で利用可能。 VPC Flow Logs でドロップされたパケットのレコードが出力されるように About VPC Flow Logs records (2026-08-27) VPC Flow Logs が、ファイアウォールルール等でドロップされたパケットのレコードを出力するようになった。 セキュリティ監査やネットワーク疎通エラーのトラブルシューティングに有用。既存 VPC で Flow Logs 料金（Network telemetry 料金）に注意が必要か。 Gemini Enterprise で Sensitive Data Protection のコンテンツポリシーが使用可能に Protect sensitive data in sources (2026-08-31) Gemini Enterprise と Gemini Notebook Enterprise で、Sensitive Data Protection のコンテンツポリシーが使用可能になった。 コンテンツポリシーをデータストアやアシスタントに割り当てることができ、機密情報の取得やアップロードを水際で防げる。テキスト、PDF、画像など様々な形式に対応。 コンテンツポリシーとは、ビルトインまたはカスタムの infoType 検出器をリアルタイム適用できる仕組み。 BigQuery Graph が一般公開（GA） Introduction to BigQuery Graph (2026-08-31) BigQuery Graph が一般公開（GA）。 BigQuery 上で大規模なグラフデータの格納や GQL（Graph Query Language）を用いたクエリ実行が可能。 GA に伴い CALL ステートメントや探索パスの特性を検査する関数（IS_ACYCLIC、IS_SIMPLE、IS_TRAIL）が追加され、より高度分析が可能になった。 BigQuery の生成AI関数のトークンのクォータ（上限）が任意に設定できるように Control costs with token quotas (2026-08-31) BigQuery の生成AI関数（AI.GENERATE_TEXTなど）の1日のトークンのクォータ（上限）が任意に設定できるようになった。 予期しない大量実行やループ処理によるトークンの過剰消費を抑制し、コスト管理を計画的・安全に制御できる。なお以前リリースされたが一時的に停止していた。 Google Workspace のアップデート Google Meet の自動メモ作成で投影物のスクリーンショット保存されるように Visual screenshots in Google Meet meeting notes will soon be generally available, pre-configure admin settings in advance (2026-07-27) Visual screenshots now included in Google Meet meeting notes (2026-08-03) Google Meet の自動メモ作成（Take notes for me）で投影されたスライドなどのスクリーンショットがメモ内に保存されるようになる。 2026-08-03から15日間かけてロールアウト。 Google Workspace Studio で Gemini Notebook にソースデータを追加可能に Automatically add sources to your Gemini Notebooks in Workspace Studio (2026-08-07) Google Workspace Studioで、Gemini Notebook（旧称 NotebookLM）にソースデータを追加するアクションが使えるようになった。 使用例として、Google ドライブへのファイル追加を検知して Notebook に自動追加などが可能。 Excel ファイルを Google スプレッドシートにインポートする際の互換性が向上 Improved file importing in Google Sheets with tables and linked pivot tables (2026-08-11) Excel ファイルを Google スプレッドシートにインポートする際の互換性が向上。アップデートは2点で、以下のインポート後の手直しが不要になった。 Excel の「テーブル」がスプシの「テーブル」として認識される Excel のテーブル範囲を参照するピボットテーブルがスプシでもピボットとして認識される Connected Sheets で「リストパラメータ」と「列名エイリアス」機能 Improved file importing in Google Sheets with tables and linked pivot tables (2026-08-11) Connected Sheets（BigQueryデータをスプレッドシートに読み込める機能）で「リストパラメータ」と「列名エイリアス」機能がリリース。 リストパラメータ: セルの内容に応じて SQL の WHERE 句を動的に生成 列名エイリアス: スプシ上で列のエイリアス名を任意に設定できる Google Workspace のスプレッドシートで Sheets Canvas がリリース Use Sheets canvas to visualize data in custom, interactive mini-apps (2026-08-13) Google Workspace のスプレッドシートで Sheets Canvas がリリース。 スプシにインタラクティブなアプリ（可視化ダッシュボードやカンバンボードなど）を組み込める。Gemini に自然言語で指示して作成。 Take notes for me が Web 会議だけでなく対面会議でも使えるように Take Notes for me for in-person meetings is now available (2026-08-13) Google Meet の自動議事メモ（Take notes for me）が Web 会議だけでなく対面会議でも使えるようになった。 会議音声をスマホ等で Meet に聞かせると、議事メモを作成して Google ドキュメントにまとめてくれる。要約やアクションアイテムも整理される。Business Standard 以上に順次展開。 Drive Inventory Reportingで外部共有関連の情報をエクスポートできるように Enhanced external sharing insights now available in Drive Inventory Reporting (2026-08-17) Drive Inventory Reporting（Google ドライブの使用状況レポートを BigQuery にエクスポートする機能）で外部共有に関する情報をエクスポートできるようになった。 外部組織やインターネットへの共有有無がわかりやすい。明示的にオンにする必要あり。 Google Workspace Studio でエンタープライズ向けセキュリティ機能が強化 New enterprise security controls for Workspace Studio enable expanded collaboration use cases (2026-08-17) Google Workspace Studio でエンタープライズ向けセキュリティ機能が強化。 Agent Identity: フローによる自動化処理は最小権限を持つ一意の ID で自動化処理を実行 監査ログ強化: Studio での設定および実行操作は、Studio の監査イベントに記録される。ドライブ内ファイルへの編集や Gmail でのメール送信など、操作に関する監査イベントには、一意のフロー識別子や所有者情報などのフローコンテキストが含まれる 管理者からの制御強化: OAuthスコープ取り消し、一時停止など Human-in-the-Loop の強制: 管理者設定で、人間の承認なしに外部へのデータ送信を禁止することが可能に Google Chat に Workspace Intelligence のハブとなる Ask Gemini 画面が登場 Introducing Ask Gemini in Chat: your new partner in productivity (2026-08-19) Google Chat に Ask Gemini 画面が登場する。Gemini が Google Workspace 全体からコンテキストを収集（Workspace Intelligence）して、タスクを行うためのハブとなる。ドライブ、Gmail、カレンダーなどを横断して Gemini が情報収集したうえで、質問への回答やコンテンツ生成、予定の作成など、さまざまなタスクの中心となる。 2026-08-26から順次展開開始、まずは英語版のみ。 Gemini アプリでインタラクティブな 3D モデルを生成できるように Generate interactive simulations and models in the Gemini app (2026-08-24) Gemini アプリでインタラクティブな 3D モデルを生成できるようになった。 DNA 構造などをインタラクティブに回転させたりズームインするなど。Google Workspace 等で既に展開済（Available now）。 Microsoft OneDrive からのデータインポート（Advanced モード）が一般公開 Introducing data import for Microsoft OneDrive: An easier, faster, and higher-fidelity migration to Google Workspace (2026-08-25) Google Workspace で Microsoft OneDrive からのデータインポート（Advanced モード）が一般公開。 複数のまとまりを同時並行でインポートできるため高速。並列度は、MS 側のクォータにあわせて調整可能。追加費用なし。移行時間の見積ツールも付帯している。 Microsoft Teams からのチャット情報のデータインポート機能が一般公開 Introducing data import for Microsoft Teams: An easier, faster, and higher-fidelity migration to Google Workspace (2026-08-25) Google Workspace で Microsoft Teams からのチャット情報のデータインポート機能が一般公開。 Teams のチャネル、チャネルメッセージ、グループチャット、DM を並列処理で高速に Google Chat に移行できる。追加費用なし。移行時間の見積ツールも付帯している。 Google カレンダーで Teams や Zoom などからの招待がわかりやすく Improving Google Calendar’s interoperability with third-party video conferencing solutions (2026-08-27) Google カレンダーで Microsoft Teams や Zoom など他媒体からの招待を受信したときの体験が改善。 予定の「場所」欄に会議 URL が記載されたり、招待の会議 ID、PIN コードなどが構造的に識別され「参加」ボタンがわかりやすく表示される等。 Google ドライブで AI によるデータ自動ラベリング機能がオープンベータ開始 Gemini-based data classification in Google Drive is now available in open beta (2026-08-28) Google ドライブで、Gemini によるデータ自動ラベリング機能がオープンベータ開始。 管理者が自然言語でプロンプトを定義するだけで、Gemini がファイルを評価して分類ラベルを自動的に付与する。機械学習用のデータ準備不要。大規模な DLP ポリシーの適用や保持ルールの徹底が簡素化できる。 予定主催者が受け取る出席可否メール通知をイベント単位で無効化できるように Suppress email responses to calendar invitations and updates (2026-08-28) Google カレンダーで、予定の主催者が受け取る出席可否のメール通知をイベント単位で無効化できるようになった。 「ゲストが回答したときにメールを受け取る」のチェックを外す。これで全社イベントなどで出欠通知が大量になりすぎるのを防げる。順次ロールアウト。 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it