1. はじめに Quality Engineering Gのとみよしです。 私が所属するQAチームではオープンソースのテスト管理ツールであるTestLinkを採用しています。 :::message TestLinkとは テストケースの作成・管理からテスト計画の立案、実行結果の記録まで一元管理できるオープンソースのテスト管理ツールです。 ::: TestLinkへの結果入力は工数がかかるため、Excelマクロで結果を一括入力できるXMLファイルを生成する仕組みを運用していました。 しかしこのExcelマクロには2つの課題がありました。 チーム内にMac・Windowsユーザーが混在しており、OS差分を考慮した 2本のコードを管理 しなければならなかった ローカル環境でのみ動作するため、 更新のたびにファイル共有が必要 だった これらを解決するために、Microsoft 365のCopilotを活用してGoogle Apps ScriptでWebアプリを作ってみました。 コードは一行も自分で書いていません。 その過程を紹介します。 2. 解決策としてGAS Webアプリを選んだ理由 課題の本質は「 環境に依存している 」ことでした。ブラウザで動くWebアプリにすれば、OSの違いもローカル管理の問題も一度に解決できます。 その中でGAS（Google Apps Script）を選んだ理由は主に3つです。 ① OS差分がなくなる ブラウザで動くため、MacでもWindowsでも同じように使えます。 ② Google スプレッドシート（以下、GSSと表記）と連携できる プロジェクトコードや担当者などのマスタデータをGSSで管理し、Webアプリからそのまま参照できます。更新もGSS上で行うだけなので、誰でもマスタ更新が可能になります。 ③ 無料で使える Google アカウントがあれば追加コストなしで開発・運用できます。 3. 完成したWebアプリの紹介 主な機能は3つです。 ① 一括生成 テストケースが連番になっている場合に使います。開始番号と終了番号を入力するだけで、その範囲をまとめたXMLファイルを出力できます。 例）No.1〜100をまとめて一括出力 ② 個別生成 テストケースを個別に指定して出力します。飛び番号のケースや、特定のケースだけ再テストしたい場合に便利です。 例）No.1, 3, 5, 7, 10を個別に出力 ③ マスタ管理 プロジェクトコードや担当者名をGSSで管理しています。画面右上の「マスタを編集」ボタンからGSSに直接遷移して編集できます。 4. 開発の進め方 〜Copilotと約15往復した話〜 「WebアプリはGASで作ろう」と決めたものの、私は簡単なGASのコードしか書けず、Webアプリに関する知識はほとんどありませんでした。そこで活用したのが Microsoft 365のCopilot です。 Copilotへの最初の一手 まず既存のExcelマクロのコードをそのままCopilotに貼り付け、以下のように依頼しました。 「このExcelマクロと同じ機能をGAS（Google Apps Script）で書いてください」 たったこれだけです。Copilotは既存コードの意図を読み取り、GAS向けのコードを出力してくれました。 Excelマクロという既存の資産がそのまま設計書代わりになった わけです。 機能を1つずつ育てていった 最初から全機能を一度に作ろうとせず、以下の順番で1つずつ機能を追加していきました。 一括生成機能の作成 個別生成機能の追加 マスタ機能の追加 細かい仕様の追加 Webアプリ化 1ステップずつCopilotに依頼し、動作を確認してから次に進む流れです。結果的に 10〜20往復 のやり取りになりました。 エラーが出たらそのまま貼り付ける 開発中にエラーが発生することも何度かありましたが、対処法はシンプルです。 エラーメッセージをそのままCopilotに貼り付ける それだけで原因の説明と修正コードを返してくれました。エラー対応は 1〜2往復で解消 できました。 5. やってみて気づいたこと Copilotへの伝え方のコツ 一度に複数のことを依頼するより、 1つの依頼につき1つの機能追加 に絞ったほうがスムーズでした。欲張って「あれもこれも」と依頼すると、意図が伝わりにくくなることがありました。 QAエンジニアでもWebアプリが作れた 着手前は「自分にWebアプリなんて作れるのか」という不安がありました。しかし Copilotに既存のコードを渡してやり取りを繰り返すだけで、気づけば動くWebアプリができあがっていました。 プログラミングの専門知識がなくても、「何をしたいか」を言葉で伝える力があれば十分です。 Before / After Excelマクロ GAS Webアプリ OS対応 Mac/Windows別管理 ブラウザで統一 コード管理 実質2本 1本 マスタ管理 Excelファイル Google スプレッドシート 共有のしやすさ ファイル共有が必要 URLを共有するだけ 「はじめに」で挙げた2つの課題が、どちらもきれいに解消されました。 6. おわりに 「QAエンジニアにはコードが書けない」なんてことはありません。 AIを活用すれば、 既存の資産を渡すだけで新しい環境向けのコードを生成してもらえます。 私自身、コードを一行も書かずにWebアプリを完成させることができました。 同じようにExcelマクロの管理に悩んでいるQAエンジニアの方がいれば、ぜひ一度試してみてください。まず手元にあるマクロのコードをCopilotに貼り付けるところから始めれば大丈夫です。 この記事が、AIを活用した業務改善の第一歩を踏み出すきっかけになれば嬉しいです。

本ブログでは、 AWS Summit Japan 2026 （2026年6月25日〜26日、幕張メッセ）の Physical AI ブースで展示するデモを題材に、AWS のクラウドサービスと産業用ロボットを組み合わせた自律オペレーションの実現方法をご紹介します。 はじめに Physical AI とは、ハードウェアを通じて物理世界を知覚し、ソフトウェア側で理解・推論・学習を行い、再びハードウェアを通じて物理世界に働きかける技術です。テキストの内容を返すデジタル AI とは異なり、ロボットやヒューマノイド、AGV といったハードウェアを通じて、物理的なアクションを自律的に実行します。AI とロボティクスの双方が同時に進化しブレークスルーを迎えた今、製造・物流・インフラ管理など、あらゆる産業の現場オペレーションが変革されようとしています。 従来の産業用ロボットは事前にすべての動作をプログラミングする必要があり、予期せぬ状況や形状が変化する対象物には対応できないという壁がありました。Physical AI は状況を自ら判断し、不確実性の高い環境にも適応できます。ここに、AI エージェントが自律的に「調査し、判断し、実行する」能力が加わることで、真に自律的なオペレーションが可能になります。 Physical AI とは — Agentic AI が現実世界に出るとき 本デモにおける Physical AI の中核 — Agentic AI 本デモにおける Physical AI の中核は、AI エージェント（Agentic AI）です。ソフトウェアの世界で発展してきたエージェントの能力 — ツール呼び出し、メモリへの学習蓄積、計画立案と実行 — を、カメラやセンサーによる「知覚」とロボットアームや自律走行車両による「行動」へと拡張し、知覚 → 判断 → 行動のループを自律的に回します。 なぜ今 Physical AI なのか Physical AI が注目される背景には、いくつかの技術的ブレークスルーがあります。 LLM の推論能力の飛躍的向上 — 複雑な状況判断や計画立案が可能に Agentic AI フレームワークの成熟 — ツール呼び出し、メモリ管理、マルチエージェント協調が実用レベルに クラウド-エッジ連携の高度化 — 低遅延通信と安全な制御の両立 協働ロボットの普及 — 人と同じ空間で安全に動作するロボットが入手可能に これらが揃った今、AI エージェントが現実世界で自律的にオペレーションを遂行する時代が到来しています。 デモコンセプト — 「知らない状態」から自律的に解決する 概要 現実世界とつながった AI エージェントが、想定外の障害に対して自ら調査し、自ら考え、ロボットを動かして解決する。 私たちが構築したデモは、空想の街に Amazon のラストワンマイル配送を模した配送網を作り、来場者が自由に障害を仕掛けることで、AI エージェントの自律的な問題解決能力を体験してもらうものです。 重要なのは、これが 事前にプログラムされたシナリオではない という点です。来場者が自由に障害物を配置するため、毎回異なる状況が発生します。AI エージェントは障害の存在も位置もあらかじめ知らない「ゼロ」の状態から、調査・判断・実行を自律的に回していきます。 来場者体験の設計 来場者の目の前には2つの画面が並びます。 画面 内容 AI エージェントの思考 AI エージェントがいま何を考え、次に何をしようとしているかをリアルタイム表示 AI が認識している世界 AI エージェントが現時点で認識している世界。調査が進むにつれて実際の状態に近づく この2つを見比べることで、AI がまだ何を知らず、いま何を考え、どう行動しようとしているかが一目でわかります。リアルタイムダッシュボードではエージェントの調査計画・復旧方針が逐次可視化されます。 デモフロー — 5ステップの自律オペレーション デモは1サイクル約3〜4分で、以下の5ステップで進行します。 Step 1: 通常配送（デモの起点） 空想の街で、配達車両（TurtleBot）が物流・倉庫エリアから配送先へルートを巡回しています。配送網は正常に動いており、来場者にはまずこの「通常状態」を見てもらいます。 Step 2: 来場者が障害を発生させる 来場者が配送ルート上に障害物を配置すると、配達車両が障害物を検知して停止し、配送が止まります。障害の場所は来場者が自由に決めるため、毎回パターンが異なります。 Step 3: AI エージェントが調査を開始する 配送停止を検知した AI エージェントが、障害の特定に動き出します。FANUC CRX-20iA/L 協働ロボットのアーム先端カメラ（FRAMOS D435e）でトラブルが起きた通りを探索し、段階的にデータを収集します。 以下のループで段階的に進みます。 周辺調査 — トラブルが起きた通りをカメラで撮影する 認識の更新 — 得られたデータをもとに AI が自分の地図を更新する 次の調査計画 — 追加で調べるべき箇所があるかを判断する 一発で全容がわかるわけではなく、このループを繰り返しながら障害を見極めます。 Step 4: 復旧の実行 障害物を特定した AI エージェントが、FANUC ロボットに除去を指示します。ロボットが障害物を把持し、ステージ上の回収エリアへ移動させることで道路を開通させます。把持できない障害物を発見した場合は、オペレーターに支援を要請します。 Step 5: 配送再開 復旧が完了すると、AI エージェントは配達車両に配送再開の指示を出します。来場者が止めた配送網が、目の前で復旧されます。 システムアーキテクチャ 設計原則 本システムは以下の原則に基づいて設計されています。 知性が必要な処理はクラウドで実行 — 物体認識、コンテキスト判断、アーム制御指示、車両の再開指示は LLM の推論力を活かしクラウドから発行 物理的な動作実行はエッジで処理 — クラウドからの指示を受けたモーションプランニング（MoveIt 2）やセンサー処理はエッジ PC 上で実行 通信断に耐える設計 — クラウドとの通信が切れた場合、アームは安全停止し、復旧後にクラウドから再開指示を受ける 全体構成 ▲ 知性が必要な処理はクラウド（Amazon Bedrock AgentCore / Amazon Bedrock / Amazon Polly）で実行し、物理的な動作実行はエッジ（ROS 2 / MoveIt 2）で処理。AWS IoT Core がクラウドとエッジをセキュアに接続します。 通信方式 通信経路 プロトコル 理由 FANUC ロボット AI エージェント AWS IoT Core（MQTT 5）Request/Response 低遅延・双方向制御。TLS 相互認証による安全性 配達車両 クラウド AWS IoT Core（Device Shadow） Named Shadow で走行状態・停止/再開・バッテリー・温度などを管理 ダッシュボード UI クラウド AWS IoT Core（MQTT 5）+ HTTPS エージェントの思考過程をリアルタイムに配信 使用する AWS サービス Amazon Bedrock AgentCore Runtime — AI エージェントの実行基盤 Amazon Bedrock AgentCore は、AI エージェントをインフラ管理不要でデプロイ・運用できるマネージドサービスです。本デモでは、AgentCore Runtime 上で動作する AI エージェントが、推論モデルに Amazon Bedrock の Claude Sonnet 4.6 を使用し、ツール呼び出し（ロボット制御 API）、メモリ（調査結果の蓄積）、データ（地図情報）を統合的に管理して、調査計画の立案から復旧指示までを自律的に遂行します。 Amazon Bedrock（Claude 4.5 Haiku）— 視覚認識と推論 Amazon Bedrock 上の Claude 4.5 Haiku が、D435e カメラから取得した画像をもとに周囲の状況を認識します。障害物の有無や周囲の状況を考慮した最適な行動の推論を担当します。 AWS IoT Core — エッジとクラウドの架け橋 AWS IoT Core が、会場内のロボットとクラウド上の AI エージェントをセキュアに接続します。MQTT 5 の Request/Response パターンによるアーム制御と、Device Shadow による配達車両の状態管理を実現します。通信断が発生しても最後の既知状態から安全に復帰できます。 Amazon Polly — AI の声 Amazon Polly により、AI エージェントの判断内容を音声で来場者に伝えます。「状況を確認します」「障害物を探します」「障害物を発見しました」「障害物を取り除きます」といったナレーションがデモの臨場感を高めます。 ハードウェア構成 FANUC CRX-20iA/L 協働ロボット × 2台 FANUC CRX-20iA/L は、可搬質量 20kg、リーチ 1,418mm の協働ロボットです。人と同じ空間で安全に動作します。 項目 仕様 リーチ 1,418 mm 制御装置 R-30iB Mini Plus 安全機能 接触検知による即時停止 ロボットハンド OnRobot 2FG7（ストローク 最大 68mm） カメラ FRAMOS D435e（RGB + Depth） 2台の CRX はそれぞれ担当エリアを持ち、AI エージェントの指示のもとで協調動作します。調査時はアーム先端の FRAMOS D435e カメラで隣接エリアを撮影し、復旧時はロボットハンド（OnRobot 2FG7）で障害物を把持して回収エリアへ移動します。 TurtleBot3 Burger — 配達車両 配送網を走行する自律走行ロボットです。 項目 仕様 経路追従 赤外線ラインセンサー（TCRT5000 × 3ch）によるライントレース 区間認識 停止ライン検知（3センサー同時白）による区間識別 障害物検知 赤外線距離センサー（IRSS-10）による前方障害物検知 通信 AWS IoT Core Named Shadow（mTLS）+ MQTT ログ送信 障害物を検知して停止すると、その情報がクラウド側のエージェントに伝達され、調査フローが起動します。復旧完了後、エージェントからの再開指示で走行を再開します。 項目 仕様 経路追従 赤外線ラインセンサー（TCRT5000 × 3ch）によるライントレース 区間認識 停止ライン検知（3センサー同時白）による区間識別 障害物検知 赤外線距離センサー（IRSS-10）による前方障害物検知 通信 AWS IoT Core Named Shadow（mTLS）+ MQTT ログ送信 障害物を検知して停止すると、その情報がクラウド側のエージェントに伝達され、調査フローが起動します。復旧完了後、エージェントからの再開指示で走行を再開します。 ジオラマステージ 3,640mm × 3,640mm の木工ステージ上に、3D プリンタで製作したミニチュアの街を配置します。周回トラックには「オレンジ通り」「ブルー通り」「グリーン通り」「パープル通り」の4つの通りがあり、配達車両の走行ルートとしています。 道路は黒地マット仕上げの上に白線（幅 30mm）を敷設し、配達車両がライントレースで追従します。配送・積荷のポイントには配達車両のための停止線を配置しています。 AI エージェントの意思決定 — 調査し、学習し、適応する 1ターン = 1アクション AI エージェントは毎ターン、以下のアクションから1つを選択して実行します。 アクション 内容 調査 FANUC ロボットの FRAMOS D435e カメラで対象エリアを調査 障害物除去 FANUC ロボットで障害物を把持し、回収エリアへ移動 エージェントは MAP の構造（道路レイアウト）とスタート/ゴール位置は既知ですが、障害物の位置は一切知りません。 調査の選択 調査を行うかどうかは、AI エージェントが自律的に判断します。配達車両が障害物を検知した後、AI エージェントは FANUC ロボットのカメラで状況を確認し、把持可能な障害物かどうかを見極めてから行動を計画します。これは事前にプログラムされた手順ではなく、状況に応じた AI エージェントによる自律的な判断です。 障害物除去戦略の判断 障害物を発見した AI エージェントは、カメラ画像から障害物の形状・サイズを認識し、ロボットハンドで把持可能かを判断します。把持可能と判断すれば、ロボットに除去を指示し道路を開通させます。把持が困難と判断した場合は、オペレーターに支援を要請します。 まとめ 本ブログでは、AWS Summit Japan 2026 の Physical AI ブースで展示するデモを通じて、AI エージェントが現実世界で自律的にオペレーションを遂行する仕組みをご紹介しました。 このデモのポイントは以下の通りです。 想定外への対応力 — 事前に定義されたシナリオではなく、予測不能な状況に AI が自律的に対応する 調査から解決まで一気通貫 — 障害の検知・調査・判断・復旧までを AI エージェントが自律的に完走する リアルタイム可視化 — ダッシュボードにより、エージェントの思考と行動が常に可視化される クラウド AI × ロボットの協調 — クラウド上の AI エージェントが判断し、現場のロボットが実行する新しいオペレーションモデル Physical AI は、AI が「考える」だけでなく「行動する」時代の到来を示しています。AWS のクラウドサービスとロボティクスの組み合わせにより、この未来は今まさに実現可能になっています。 体験機会のご案内 Physical AI デモの実物は、 AWS Summit Japan 2026 （2026年6月25日〜26日、幕張メッセ）の Physical AI ブースでご覧いただけます。AI エージェントが現実世界で自律的に問題を解決する様子を、ぜひ目の前で体験してください。 AWS を活用した Physical AI ソリューションにご興味のある方は、ぜひ お問い合わせ ください。 このブログは AWS Japan のソリューションアーキテクト 西田 光彦 、水野 貴博 が執筆しました。 西田 光彦は、エンタープライズのお客様をご支援しているソリューションアーキテクトです。自動車・製造業を専門領域とし、Generative AI/Physical AI など最新テクノロジーを活用してお客様の組織と業務変革のお手伝いしています。 Kiro と 信頼できる同僚達 に支えられながら仕事しています。 水野貴博は、製造業のお客様をご支援しているソリューションアーキテクトです。サプライチェーン領域を得意としており、好きな AWS サービスは Amazon Connect Decisions (旧AWS Supply Chain) です。趣味は、ドラマや映画のエキストラに参加することです。

G-gen の西田です。ノーコードで Google Workspace のタスクを自動化できる Google Workspace Studio に導入された、リストデータを繰り返し処理できる ループ処理機能 について解説します。 はじめに Google Workspace Studio とは ループ処理機能の概要 検証シナリオ 設定手順 動作確認 はじめに Google Workspace Studio とは Google Workspace Studio とは、プログラミングを行うことなく、Google Workspace の各アプリケーションや Gemini を組み合わせた自動化フローを作成できる AI エージェントツール です。 ユーザーは「ステップ」と呼ばれる個々のタスクを順に配置することで、複雑な業務プロセスを自動化できます。例えば、「メールを受信したら Gemini で内容を要約し、Google Chat に投稿する」といったフローを直感的に構築可能です。 Google Workspace Studio の詳細やコンセプトについては、以下の記事を参照してください。 blog.g-gen.co.jp ループ処理機能の概要 Google Workspace Studio のフローにおいて、2026年6月に リストをループ処理する機能 が導入されました。これにより、リスト形式のデータに対して同じ処理を繰り返し実行できるようになりました。これまでは1つのデータに対して1つの処理を行うフローが中心でしたが、今回のアップデートにより、リストデータを一括で処理する高度な自動化が容易になります。導入された機能は主に以下の2つです。 機能 概要 Ask Gemini のリスト出力 「Ask Gemini」ステップの「Response format」設定に リスト形式 が追加されました。Gemini に相談した結果を構造化されたリストとして後続のステップに渡すことができます。 Repeat for each Gemini に相談した結果のリストの各項目や Google スプレッドシートの各行に対して、指定した一連の処理（サブステップ）を 繰り返し実行 するステップです。 参考 : Introducing the ability to loop over a list of items in Workspace Studio - Google Workspace Updates 検証シナリオ ループ機能の具体的な活用例として、社内パソコンの管理台帳（Google スプレッドシート）を参照し、OS のサポートが切れている端末の利用者へ案内メールの下書きを作成するフローを構築します。 検証用の管理台帳には、端末管理ソフト等で取得できるデータの一部である、「端末 ID」「マシンベンダー」「OS」「最終起動日」「ログイン ID」「メールアドレス」の項目を持つリストを使用します。 フローでは以下の処理を自動化します。 Gemini で案内メールのテンプレートを作成 管理台帳からデータを取得 各行の OS 情報をチェックし、サポート切れの場合はメールの下書きを作成 管理台帳の「ステータス」列を Done に更新 設定手順 Google Workspace Studio で以下のステップを持つフローを作成します。 ステップ1: トリガー設定 フローが実行されるトリガーを設定します。今回は特定の日時に開始するように設定します。 ステップ2: メール文面作成 サポート切れのパソコンの利用者に向けた案内メールの文面を作成します。検証では「Gemini に相談」を利用して文章を作成します。 なお本来、ここで指定するメールの文面は定型文で問題ありませんが、当記事では Gemini による生成機能の説明を目的として「Gemini に相談」を使用しました。 ステップ3: リストデータ取得 「シートのコンテンツを取得」アクションを選択し、対象のスプレッドシートのシートからリストデータを取得します。すべての行を取得するため「値を取得する行を検索」では、「すべて」を指定します。 ステップ4: ループ処理開始 ループ処理を設定します。日本語の画面では、「それぞれについて繰り返す」というツールを選択します。 「リストを選択します」の変数ボタンから、ステップ3で取得したシートのコンテンツを選択し、「詳細リスト - 一致する値」を指定します。 ステップ5: 処理対象か確認 ループ内のサブステップとして、「OS がサポート切れであるか」を判定するロジックを記述するため、AI アクションの「決定」を追加します。 処理行の「OS」の値を取得するため、プロンプト入力欄の変数ボタンから、ステップ4のループ処理を選択し、その中から「一致する値 "OS" の各アイテム」を指定します。 ここでは、「処理行の OS がサポート切れである」という条件から真偽値を判定させます。 ステップ6: 条件分岐 条件分岐のステップでは、ステップ5の結果が "真" である場合、後続のステップに進ませるようにします。 ステップ7: 下書き作成 条件に一致した行の "メールアドレス" 宛のメールの下書きを作成します。宛先のメールアドレスは、ステップ4のループ処理の中から「一致する値 "メールアドレス" の各アイテム」を指定します。メッセージ（本文）は、ステップ2で作成した文面を指定します。 ステップ8: 台帳更新 下書きを作成した行については、作成済みの記録を入力する処理を設定するため「行を更新」というステップを選択します。更新対象のスプレッドシート、シート、対象の行および入力する値をそれぞれ指定します。 動作確認 フローをテスト実行すると、管理台帳の各行が順番に処理されます。 管理台帳を確認すると、Windows 11 の行以外については、サポート切れ OS と判定され、G 列に下書きが作成された記録が入力されています。 また、作成された下書きメールは以下の通りです。今回の管理台帳では対象となる行が45行ありましたので、同様の下書きメールも45件作成されました。 なお、ループ処理できる行の数は画面の注意書きに記載の通り、100件までです。 101件目以降のデータを処理する場合は、スプレッドシートのシートからのリストデータ取得時に条件を加えるなどして調整します。上記の手順では、ステップ3の「シートのコンテンツを取得」のステップに、「下書き作成」が空白であるといった抽出条件を加えます。 西田 匡志 (記事一覧) クラウドソリューション部 美容商社→物流→情シスを経て、2025年6月G-genにジョイン。Google Cloud を通じて多くの人に貢献できるよう日々精進！