Amazon Bedrock で OpenAI GPT-5.6 モデルが 25 を超える AWS リージョンから利用可能になり、クロスリージョン推論 (CRIS) に対応しました。クロスリージョン推論に対応する GPT-5.6 のモデルは Sol、Terra、Luna の 3 つで、それぞれ性能とコストのバランスが異なります。 この対応で日本拠点のお客様にとって特に重要なのは、 東京リージョン (ap-northeast-1) と大阪リージョン (ap-northeast-3) が、グローバル推論プロファイルの呼び出し元 (ソース) リージョンに含まれている ことです。すでに東京リージョンで Amazon Bedrock をお使いのお客様は、 アプリケーションの接続先リージョンを変更することなく、いま使っている環境のまま GPT-5.6 を呼び出せます。 本記事では、GPT-5.6 モデルの概要、地理的 (Geographic) 推論プロファイルとグローバル推論プロファイルの違い、そしてそれが日本拠点のお客様にとって具体的に何を意味するのかを整理します。あわせて、導入を判断する前に必ず把握しておくべきデータの所在とレイテンシの論点を扱い、最後に Amazon Bedrock コンソールで試す手順を紹介します。 コード例、IAM ポリシー、SCP、クォータ管理といった実装の詳細は、関連記事「 東京リージョンから Amazon Bedrock の OpenAI GPT-5.6 を呼び出す実装ガイド 」で解説しています。 Amazon Bedrock の GPT-5.6 Amazon Bedrock の GPT-5.6 ファミリーには、汎用のモデルと、サイバーセキュリティに特化したモデルがあります。本記事で扱うのは、クロスリージョン推論に対応する 3 つの汎用モデル (Sol、Terra、Luna) です。 3 つのモデルに共通する仕様は次のとおりです。 入力はテキストと画像、出力はテキスト コンテキストウィンドウは 100 万トークン 推論 (reasoning) モード、サーバーサイドツール呼び出し、プロンプトキャッシュに対応 OpenAI Responses API、OpenAI Chat Completions API、Amazon Bedrock Converse API から呼び出し可能 ストリーミングは Responses API と Chat Completions API の stream=True 、および ConverseStream に対応 モデル間の主な違いは、位置づけと対応リージョンです。対応リージョンは呼び出し方 (In-Region / Geo / Global) ごとに異なるため、次の表ではその区分で整理しています。最新の提供状況は、後述のドキュメントリンクからご確認ください。 GPT-5.6 Sol GPT-5.6 Terra GPT-5.6 Luna 位置づけ 最も高性能。エージェント用途・コーディング向け バランス型。日常的な本番ワークロード向け 高速・低コスト。大量処理向け In-Region (リージョン内) 対応 us-east-1 、 us-east-2 us-east-1 、 us-east-2 、 us-west-2 us-east-1 、 us-east-2 、 us-west-2 Geo ( us. ) 対応 us-east-1 、 us-east-2 、 us-west-1 、 us-west-2 同左 同左 Global ( global. ) 対応 東京・大阪を含む商用リージョン全体 同左 同左 料金はモデルごとに異なります。最新の単価は Amazon Bedrock の料金 ページをご確認ください。各モデルの提供リージョンの正式な一覧は、 Amazon Bedrock のリージョン別モデルサポート ページをご参照ください。 GPT-5.6 におけるクロスリージョン推論の仕組み クロスリージョン推論自体は Amazon Bedrock でかねてより提供されているもので、新機能ではありません。 推論プロファイル (inference profile) を通じて動作します。推論プロファイルは、モデルと、Amazon Bedrock がリクエストをルーティングできる AWS リージョンの組み合わせを定義した論理的な識別子で、生のモデル ID の代わりに指定します。 お客様はソースリージョンからプロファイルを呼び出し、Amazon Bedrock がそのリクエストを宛先リージョンにルーティングして、そのリージョンの計算リソースで処理します。 クロスリージョン推論は、第一義的にはキャパシティのための仕組みです。 1 つのリージョンで利用可能なキャパシティに縛られるのではなく、より広い計算リソースのプールを利用できるようにすることで、スループットを高め、負荷がかかった状況でも安定した性能を維持しやすくします。 GPT-5.6 のローンチでは、2 種類のクロスリージョン推論プロファイルが導入されました。この 2 つは、 データがどこで処理されうるか が異なり、その違いがコンプライアンス上の主要な判断ポイントになります。 Geo (地理的) 推論プロファイル ： us. のように地理コードが接頭辞として付きます (例: us.openai.gpt-5.6-terra )。推論処理をあらかじめ定義された地理的範囲内のリージョンに限定します。リクエストはソースリージョンから入り、その地理的範囲内の宛先リージョンにのみルーティングされます。データレジデンシー要件のあるワークロードでも、境界の内側で複数リージョンにスケールできます。 グローバル推論プロファイル ： global. が接頭辞として付きます (例: global.openai.gpt-5.6-terra )。そのモデルが展開されている、サポート対象のすべての AWS 商用リージョンに対して、リアルタイムのキャパシティ状況に基づいてリクエストをルーティングできます。最も広いキャパシティプールを利用でき、地理的な処理要件がないワークロードに適した選択肢です。 どちらのプロファイルでも、リクエストはすでに Amazon Bedrock を呼び出しているリージョンからプロファイル ID を指定して送信し、どのバックエンドリージョンが処理するかは Amazon Bedrock が決定します。レスポンスは同じ呼び出しの中で返ります。 アプリケーションのコード側で、どの宛先リージョンが処理したかを追跡する必要はありません。 補足として、次の点を押さえておいてください。 請求とクォータの消費は、どのバックエンドリージョンが処理したかに関係なく、お客様のアカウントに対して記録されます。 そのため、支出とスループットは引き続き 1 つのビューで把握できます。 グローバル CRIS を経由するデータは、そのモデルの対象リージョン群をまたいで処理される可能性があります。 処理を特定の地理的範囲に限定するデータレジデンシー要件がある場合は、該当する地理の Geo プロファイル (例: us.openai.gpt-5.6-terra ) を使うか、単一リージョンへの直接呼び出しを使ってください。 クロスリージョン推論の仕組みそのものについては、Amazon Bedrock の クロスリージョン推論のドキュメント で解説されています。GPT-5.6 の各リージョンがどの呼び出し方 (In-Region / Geo / Global) に対応しているかは、 リージョン別モデルサポート ページのリージョン別の対応表をご確認ください。 ソースリージョンと宛先リージョン まず押さえておきたいのは、 us. プロファイルのソースリージョンは米国とカナダのリージョンに限られており、東京リージョンと大阪リージョンは含まれていない 点です。つまり、東京リージョンから us.openai.gpt-5.6-terra を呼び出すことはできません。 これは仕組み上の制約ではなく、提供状況によるものです。 ご自身の環境で呼び出せるプロファイルは、次のコマンドで確認できます。 aws bedrock list-inference-profiles --region ap-northeast-1 \ --query "inferenceProfileSummaries[?contains(inferenceProfileId, 'gpt-5.6')].[inferenceProfileId,status]" \ --output table 一方で、 東京リージョンと大阪リージョンは、グローバル推論プロファイルのソースリージョンに含まれています。 以下の表は、グローバル推論プロファイル ( global.openai.gpt-5.6-sol / -terra / -luna ) を呼び出せるソースリージョンと、リクエストが処理されうる宛先リージョンの一覧です。ルーティングの内容は Sol、Terra、Luna の 3 モデルで共通です。 ソースリージョン 宛先リージョン 米国 : us-east-1 、 us-east-2 、 us-west-2 、 us-west-1 カナダ : ca-central-1 欧州 : eu-north-1 、 eu-west-3 、 eu-west-1 、 eu-central-1 、 eu-south-2 、 eu-south-1 、 eu-west-2 、 eu-central-2 アジアパシフィック : ap-southeast-4 、 ap-southeast-2 、 ap-northeast-1 (東京) 、 ap-northeast-3 (大阪) 、 ap-northeast-2 、 ap-south-1 、 ap-south-2 、 ap-southeast-1 、 ap-southeast-3 、 ap-southeast-7 、 ap-southeast-5 、 ap-east-2 中東 : me-central-1 、 il-central-1 南米 : sa-east-1 仕組み上はサポート対象の AWS 商用リージョン全体が対象。実際の処理先はモデルがデプロイされているリージョン ( us-east-1 、 us-east-2 、 us-west-2 ) 各プロファイルのルーティング対象リージョンの正式な一覧は、 リージョン別モデルサポート ページの GPT-5.6 の対応表をご確認ください。クロスリージョン推論プロファイル全般の仕様 (オプトインリージョンの扱いや、ソースリージョンによって宛先が変わる場合があることなど) は、 推論プロファイルのサポート対象リージョンとモデル ページに記載されています。 日本拠点のお客様にとって、これが何を意味するか 具体的なメリットは次の 3 点です。 1. 既存の Amazon Bedrock 利用環境をそのまま使える すでに東京リージョンで Amazon Bedrock をお使いであれば、エンドポイントもリージョン設定も、VPC エンドポイントも、CloudTrail の集約先も、いま使っているものがそのまま使えます。アプリケーションコードで変えるのは modelId (または model ) パラメータに渡す文字列だけ です。 - model_id = "anthropic.claude-...." + model_id = "global.openai.gpt-5.6-terra" 米国リージョン側にスタックやエンドポイントを追加で用意する必要はありません。 ただし、 コード以外に必要な準備が 2 つあります。 ひとつは IAM ポリシーで、グローバル推論プロファイルの呼び出しには 3 つのステートメントが必要です。もうひとつは、利用可能リージョンを制限する SCP を使っている場合の除外設定です。いずれも 実装ガイドの記事 で解説しています。 2. 単一リージョンより広いキャパシティプールを使える グローバル推論プロファイルは、リアルタイムのキャパシティ状況に基づいてルーティングします。特定リージョンの需要が高まっている時間帯でも、単一リージョンに固定した呼び出しに比べてスロットリングの影響を受けにくく、負荷時のスループットが安定しやすくなります。新しいモデルの提供開始直後は需要が集中しやすいため、この効果は特に大きくなります。 3. 運用の可観測性は東京リージョンに残る リクエストがどのリージョンで処理されても、CloudTrail のイベント、モデル呼び出しログ、CloudWatch メトリクス、Service Quotas はすべて ソースリージョンである東京 に記録されます。監視・課金・クォータ管理のダッシュボードを日本国外に分散させる必要はありません。 日本拠点のお客様が事前に理解しておくべきこと グローバル CRIS の利点と引き換えに、必ず理解しておくべき論点が 2 つあります。導入判断の前に、社内のセキュリティ・コンプライアンス担当と共有してください。 推論処理は日本国外のリージョンで行われる これが最も重要な点です。東京リージョンからグローバル推論プロファイルを呼び出した場合、 推論処理はモデルがデプロイされているリージョンで実行されます。 プロンプトと生成結果は、処理のために日本国外に送信されます。 執筆時点では、GPT-5.6 がデプロイされているのは米国の 3 リージョン ( us-east-1 、 us-east-2 、 us-west-2 ) です。 グローバル推論プロファイルという名称は「全世界のリージョンにルーティングしうる仕組み」を指しますが、実際にリクエストが到達できるのはモデルが配置されているリージョンに限られます。したがって東京から呼び出した GPT-5.6 のリクエストは、米国内で処理されます。 ただし、 この前提は将来にわたって保証されるものではありません。 グローバル推論プロファイルの宛先はモデルの展開状況に追随するため、対応リージョンが増えれば処理先も変わりえます。加えて、どのリージョンが処理するかはリアルタイムのキャパシティ状況に基づいて Amazon Bedrock が自動的に選択し、 お客様が処理先リージョンを指定することはできません。 そのため、データレジデンシーの観点では「現時点で米国内に収まっている」ことを設計の前提に置くのではなく、 地理的範囲を限定しない仕組みである という理解でご検討ください。処理範囲を確実に限定する必要がある場合は、グローバル推論プロファイルではなくジオ推論プロファイルが適切な選択肢です。 特定のリージョンで処理する必要がある場合、一般には「そのリージョンのモデルを直接呼び出す」という選択肢があります。ただし 東京・大阪リージョンから GPT-5.6 を直接呼び出す方法は提供されていません。 bedrock-runtime エンドポイントは推論プロファイルの指定を求め、生のモデル ID を受け付ける別のエンドポイント ( 実装ガイドの記事 で解説) は東京・大阪では GPT-5.6 を利用できません。そのため、処理リージョンを日本国内に固定する必要があるワークロードでは、別のモデルを検討してください。 あわせて、 不正利用検知の目的で入力プロンプトと出力結果が保存される場合がある 点を、社内のコンプライアンス担当と共有してください。GPT-5.6 を含む一部のモデルでは、自動不正利用検知の分類器がフラグを立てたトラフィックが最大 30 日間保持されます (詳細は後述の「セキュリティとコンプライアンス」を参照)。 ここで、 リージョンをまたぐデータと、ソースリージョンに留まるデータを区別しておくことが重要です。 データ 保存先 出典 モデル呼び出しログ (リクエスト・レスポンスの全文を含む) ソースリージョン (東京) モデル呼び出しのモニタリング CloudTrail イベント、CloudWatch メトリクス ソースリージョン (東京) グローバルクロスリージョン推論 不正利用検知でフラグが立った入力・出力 (最大 30 日間) 宛先リージョン (推論処理が行われたリージョン) 不正使用の検出 モデル呼び出しログについては、配信先として指定できるのが 同一アカウント・同一リージョンの Amazon S3 または CloudWatch Logs のみ である点がドキュメントに明記されています。そのため、プロンプトとレスポンスの全文を保管したい場合でも、その保管先は東京リージョン内に収まります。 一方で、 不正利用検知のために保持されるコンテンツは、処理が行われた宛先リージョン側に保存されます。 不正使用の検出のドキュメントには次のように記載されています。 If cross-region inference is enabled for these models, retained inputs and outputs are stored in destination regions (i.e., the region where your inference request is processed). この点はデータレジデンシーの検討で見落としやすいため、コンプライアンス担当と共有しておくことを推奨します。なお、リージョンをまたいで転送されるリクエストは AWS のネットワーク内を暗号化されて流れ、パブリックインターネットを経由しません。 判断のための整理は次のとおりです。 ワークロードの要件 推奨される選択 データ処理を日本国内に限定する必要がある 執筆時点では GPT-5.6 で要件を満たせません。 日本ジオ ( jp. ) の推論プロファイルが提供されている他のモデル、または東京リージョンで In-Region 呼び出しに対応した他のモデルを検討してください データ処理を特定の地理的範囲に限定したい Geo プロファイルが該当します。ただし GPT-5.6 に提供されるのは us. (米国) のみで、 東京からは呼び出せません 。米国リージョンをソースとして呼び出す構成が必要です 処理リージョンを 1 つに固定したい 東京・大阪をソースとする GPT-5.6 では実現できません。 クロスリージョン推論では処理先を指定できず (仕様上の挙動であり設定で変更できません)、日本リージョンから GPT-5.6 を直接呼び出す方法も提供されていません。別のモデルをご検討ください 地理的な処理要件はない グローバル CRIS が最適です。 最も広いキャパシティプールを利用できます レイテンシに処理先までのネットワーク往復が加わる 処理が日本国外のリージョンで行われるため、東京から呼び出す場合、ネットワークの往復時間がリクエストごとに上乗せされます。処理先が米国リージョンであれば、太平洋を往復する分の時間が加わります。 また、複数の処理先候補の中からリクエストごとに選択されるため、レイテンシは一定ではありません。 対話型 UI のように応答の速さが体験に直結するワークロードでは、次の対策が有効です。 ストリーミングを使う ： stream=True または converse_stream を使うことで、最初のトークンが届いた時点から表示を開始できます。ネットワークの往復は最初の 1 回に集約されるため、体感の待ち時間を大きく削減できます。 プロンプトキャッシュを活用する ：長い共通プレフィックス (システムプロンプトや few-shot 例) の再処理を省けるため、キャッシュ対象部分の処理時間を短縮できます。 実測する ：一般的な目安ではなく、実際のプロンプトサイズと出力長で、本番と同じ経路で計測してください。処理先が変動する性質上、 平均値だけでなく p90 / p99 も併せて確認すること を推奨します。Converse API のレスポンスには metrics.latencyMs が含まれるため、まずは短いプロンプトで往復を確認し、その後に本番相当の負荷で計測するとよいでしょう。 ストリーミングとプロンプトキャッシュの具体的な実装方法は、 実装ガイドの記事 で解説しています。 重要なのは、これがトレードオフであって欠陥ではないという点です。 バッチ処理、非同期のドキュメント処理、エージェント的なワークフロー、社内ツールなど、数百 ms のレイテンシが問題にならないワークロードは多く、そうしたケースではグローバル CRIS のキャパシティ上の利点がそのまま享受できます。一方、ミリ秒単位の応答性が要件であれば、その要件を先に確認してから設計してください。 セキュリティとコンプライアンス クロスリージョン推論は、同一リージョン内での直接呼び出しと同じ Amazon Bedrock のセキュリティモデルを使用します。リクエストは AWS Identity and Access Management (IAM) の認証情報で認証され、IAM ポリシーによってロールが呼び出せる推論プロファイルを制御できます。 Amazon Bedrock はチップレベルで実施される ゼロオペレーターアクセス (ZOA) セキュリティモデルを採用しており、AWS のオペレーターがお客様のプロンプトや生成結果にアクセスすることはできません。すべてのモデル呼び出しはお客様の IAM ポリシー配下で実行され、VPC エンドポイント経由で VPC からプライベートに到達でき、AWS CloudTrail に記録されます。データ境界ポリシーによって、アカウントやネットワークの境界をまたぐデータの流出を防ぐこともできます。 Amazon Bedrock は既定でゼロデータ保持 (ZDR) のモデルを採用しており、モデルへの入力と出力を保存しません。ただし GPT-5.6 を含む一部のモデルでは、自動不正利用検知の分類器がフラグを立てたトラフィックが、オフラインでの不正利用検知のために最大 30 日間保持されます。 クロスリージョン推論を使う場合、 保持されるコンテンツは宛先リージョン (推論処理が行われたリージョン) に保存されます。 保持されたデータは AWS が保存・処理し、お客様が明示的に許可しない限りサードパーティのモデルプロバイダーと共有されることはありません。要件に応じて、完全な ZDR の適用を AWS のアカウントチームに相談できる場合があります。 対象となるモデルと仕組みの詳細は、Amazon Bedrock ユーザーガイドの 不正使用の検出 をご参照ください。 Amazon Bedrock コンソールで GPT-5.6 を試す GPT-5.6 を最も手軽に試せるのは、Amazon Bedrock コンソールのプレイグラウンドです。コードや SDK のセットアップは不要です。プロンプトを送信し、推論パラメータを調整し、モデルを切り替えながら、API 統合の前に各モデルの感触を確かめられます。 モデルセレクターには地理的推論プロファイルとグローバル推論プロファイルの両方が表示されるため、コードを書く前にどちらのクロスリージョン推論オプションも試せます。 東京リージョンから試す手順: Amazon Bedrock コンソールを開き、 リージョンセレクターでアジアパシフィック (東京) ap-northeast-1 を選択します 。 ナビゲーションペインの Test の下から Playground を選択します。 ページ中央の Select model を選択します。 OpenAI GPT-5.6 Sol を検索し、 Global OpenAI GPT-5.6 Sol を選択して Apply を選択します。 プロンプトを入力し、 Run を選択して応答を生成します。 まとめ この記事では、Amazon Bedrock の OpenAI GPT-5.6 におけるクロスリージョン推論の仕組みと、東京・大阪リージョンをソースとして使う場合に押さえるべき論点を整理しました。 GPT-5.6 には 3 つのモデルがあります。要求の厳しいエージェント用途とコーディングには Sol、日常的な本番ワークロードには Terra、大量処理とレイテンシに敏感なアプリケーションには Luna です。 日本拠点のお客様にとって、この対応の実際的な意味は次の 3 点に集約されます。 グローバルキャパシティへのアクセス ：東京リージョンと大阪リージョンはグローバル推論プロファイルのソースリージョンに含まれます。アプリケーションの接続先リージョンを変更することなく、いま使っている環境から GPT-5.6 を呼び出せます。 スループットの改善 ：グローバル推論プロファイルはリアルタイムのキャパシティ状況に基づいてルーティングするため、単一リージョンに固定した呼び出しよりも広い計算リソースのプールを利用できます。需要が集中する時間帯でも性能が安定しやすくなります。 可観測性はソースリージョンに集約される ：呼び出しログ、CloudTrail、CloudWatch メトリクス、Service Quotas はすべて東京リージョンに記録されます。監視基盤を日本国外に分散させる必要はありません。 一方で、 グローバル CRIS を使うと推論処理は日本国外のリージョンで実行されます。 執筆時点で GPT-5.6 がデプロイされているのは米国の 3 リージョンのため、実際の処理は米国内で行われますが、グローバル推論プロファイルは地理的範囲を限定しない仕組みであり、処理先を指定することもできません。データレジデンシー要件があるワークロードには適さず、レイテンシには処理先までのネットワーク往復が加わります。導入前に、この点を社内のセキュリティ・コンプライアンス担当と共有してください。 なお、 GPT-5.6 に日本ジオ ( jp. ) の推論プロファイルは提供されていません。 推論処理を日本国内に限定する必要がある場合は、 jp. プロファイルが提供されている他のモデル、または東京リージョンで In-Region 呼び出しに対応した他のモデルをご検討ください。実際の導入時には、記事中の list-inference-profiles コマンドと AWS 公式ドキュメントで最新の対応状況をご確認ください。 次のステップ Amazon Bedrock コンソールを 東京リージョン で開き、Playground から Global OpenAI GPT-5.6 Sol にテストプロンプトを送ってみてください。 実装に進む場合は、関連記事「 東京リージョンから Amazon Bedrock の OpenAI GPT-5.6 を呼び出す実装ガイド 」で、3 種類の API のコード例、IAM ポリシー、SCP、クォータ管理を解説しています。 本番ワークロードのサイジング前に、 Amazon Bedrock の料金 ページで GPT-5.6 の最新単価を確認してください。 問題が発生した場合やコミュニティに質問したい場合は、 AWS re:Post で検索または投稿するのが有効です。 著者について 本橋 和貴 (Motohashi, Kazuki) は、AWS Japan の機械学習ソリューションアーキテクトです。AI/ML 領域には9年ほど携わっており、最近は主に自動車業界のお客様を対象にAWS の生成 AI/ML サービスのご利用をサポートしています。博士 (理学)。

日々進歩するAIの自分を凌ぐ優秀さを目の当たりにして 早くすべての仕事を奪ってくれないかなと思っているみなさん、 こんにちは、ソリューションアーキテクトの伊勢です。 AIは文章を書き、画像を作り、コードも書くようになりました。 次は、現実世界を認識して自分で考え、身体を動かす「フィジカルAI」の番です。 ただし、ロボットを夏休みの自由工作で作るには、少々お小遣いが足りません。 そこで今回は、AIに頭脳を、iPhoneに目と耳を、ヒトに足を担当してもらいます。 ヒトはAIの指示どおりにチェックポイントを周り、ゴールを目指します。 コースは世界一の乗降者数を誇る巨大ターミナル、新宿駅です。 果たしてヒトはフィジカルAIに進化するのでしょうか。 はじめに フィジカルAIとは オリエンテーリングとは REST APIのアップストリームとは iPhoneショートカットとは 作ってみた 全体構成 地図 プラグイン：intdash REST Plugin 設定画面 送受信履歴 iPhoneショートカット データ送信 データ取得 やってみた Data Visualizerで振り返る おわりに はじめに フィジカルAIとは フィジカルAIは、現実世界を認識し、推論し、行動するAIシステムを指します。 ロボットや自動運転車のように、センサーから得た情報をもとに判断し、現実世界へ働きかける仕組みです。 www.nvidia.com 今回は役割を次のように分担します。 フィジカルAIの役割 今回の担当 現実世界を認識する iPhoneカメラ 状況を考えて次の行動を決める サーバーサイドAI 現実世界で行動する ヒト ロボットのボディを用意する代わりに、私が歩きます。 言い換えると Human in the Loop のLoop部分がずいぶん大きく新宿を一周します。 オリエンテーリングとは オリエンテーリングは、地図を読みながら指定されたチェックポイントを順番に巡り、ゴールを目指すスポーツです。 日本オリエンテーリング協会 選手は地図に記されたコースと目標物の情報から、現在地や進む方向を判断します。 今回はこの 地図を読む／次の行動を決める／目標物を確かめる をAIへ任せます。 舞台は新宿駅東口から歌舞伎町、新宿御苑、新宿駅南口・西口を経て都庁へ向かう全11ポイントのコースです。 1 自律稼働するフィジカルAIを模して、AIから送られてくる指示だけを頼りに進みます。 REST APIのアップストリームとは AIとヒトの間にintdashを挟みます。 intdashにおけるアップストリームは、デバイス側からプラットフォーム側へデータを送信する方向のストリームです。 今回はiPhoneから写真を送り、別のエッジからAIの指示・目標物画像・写真の判定結果を返します。 REST APIによるアップストリームは、HTTPで手軽にデータを送信でき、低頻度データの送信や簡単な検証に向いています。 tech.aptpod.co.jp iPhoneショートカットとは 複数の操作を組み合わせて自動化できるApple純正アプリです。 カメラで撮影した画像をAPIへ送信したり、APIから受け取った結果の表示を画面上で組み立てられます。 AIがアプリを作ってくれる時代とはいえ、専用アプリで収集データを追加するのはそれなりの開発コストが発生します。 今回は複数データの収集を素早く試すため、ショートカットから利用できるプラグインアプリとして実装しました。既存機能を活用して実装コストを抑えられます。 2 作ってみた 全体構成 今回の構成は次のとおりです。 全体構成図 AIがルートマップを読み、各区間の移動指示と目標物画像を準備 intdashを経由して、次のチェックポイント番号・移動指示・目標物画像をiPhoneへ送る ヒトが指示に従って歩きいて現地で写真を撮る iPhoneから現地写真をintdashへ送る AIが目標物画像と現地写真を照合する 一致すれば次のチェックポイントへ進み、不一致なら再挑戦する サーバー側ではPythonプログラムでAI中継処理を動かしました。 このプログラムがintdashとAIをつなぎ、ルート案内、写真照合、チェックポイント進行、休憩・再開を管理します。 要するにAIが「次はあっちです」と言い、私が歩き、AIが「そこです」と判定します。 地図 ルートマップにはコース、チェックポイント、目標物の写真をまとめています。 オリエンテーリングのルートマップ 地図画像は最初に一度だけAIへ渡します。 AIは全区間の移動指示を生成し、各チェックポイントの目標物を切り抜きます。 生成したルート情報と画像は保存し、レース中は再利用します。 AIは地図をかなり読んでくれましたが、高架道路の上下関係や階段の進行方向などは、画像だけでは判断しにくい部分があります。 そこで確認済みの情報は補足テキストで渡し、地図の読み違いを減らしました。 地図はOpenStreetMapをもとに、オリエンテーリング国際仕様を参考に作りました。 3 地図データ © OpenStreetMap contributors を利用しています。 4 プラグイン：intdash REST Plugin iPhoneの「ショートカット」からintdash REST APIを使えるようにするため、SwiftUIでプラグインアプリを試作しました。 5 巡回地点で写真などを送りたいという要望があり、試しに作ったものです。 アプリにApp Intentsを組み込み、ショートカットから呼び出せるようにしました。 送信する数値・文字列・画像を送信リストへ追加する 複数のデータを同じ時刻でまとめて送信する 最新の計測から指定したデータを取得する 計測を完了する 対応する値は int64 、 float64 、 string 、JPEGです。 そのため、位置情報、歩数、気温、住所、音声認識結果、写真など、ショートカットが扱えるさまざまな情報をintdashへ渡せます。 設定画面 接続先情報、送信エッジUUIDなどを指定します。 プラグインの設定画面 送受信履歴 計測の作成・完了、データID、値、サイズ、通信時刻、成否を確認できます。 ログはJSONとして書き出せるので、「ショートカットは動いたように見えるけれど、実際に何を送ったのか」を後から追えます。 プラグインの送受信履歴画面 iPhoneショートカット ショートカット側では、iPhoneの標準機能とプラグインを組み合わせます。 データ送信 現地写真に加えて、緯度・経度・高度、住所、歩数、移動速度、気温、湿度、体感温度、バッテリー残量、音声メモを送信できるようにしました。 送信したい項目を並べ、最後に「データ送信」を1つ置きます。 ショートカットがデータを集めて、プラグインがintdashと通信します。 iPhoneショートカットのデータ送信 データ取得 AI側からは、次のチェックポイント番号、移動指示、目標物画像、写真判定、判定信頼度、判定理由を受け取ります。 JPEGも実行結果として表示できるため、次の目標物を確認できます。 iPhoneショートカットのデータ取得 やってみた それでは、人力フィジカルAIを起動します。 AIが最初の指示と目標物画像を送信し、ヒトが歩き始めます。 チェックポイントに着いたと思ったら写真を撮影し、AIへ送ります。 AIは目標物と写真を照合し、一致と判断すれば次の指示を返します。 似ているけれど違う場所では先へ進めません。 人間の「たぶんここでしょ」に対して、AIの方が几帳面です。 途中で「暑いのでちょっと休憩したい」と音声メモを送ると、AIは写真判定を止め、休憩と水分補給を案内します。 「休憩が終わった」と送ると、現在の移動指示と目標物画像をもう一度送って再開します。 6 スタートからゴールまでの様子を動画にしました。 youtu.be 動画の台本案もChatGPTをベースにしています。 AIに指示されて歩く動画を、AIと相談しながら編集しました。 7 Data Visualizerで振り返る レース中に送受信したデータを同じ時間軸に並べて確認できます。 intdash Data Visualizerのレース全体画面 画面には、大きく分けて次のデータを表示しています。 担当 表示データ わかること ヒト+iPhone 緯度・経度・高度 どこを移動したか ヒト+iPhone 歩数・移動速度 いつ歩き、いつ止まったか ヒト+iPhone 気温・湿度・体感温度 どのような環境だったか ヒト+iPhone バッテリー残量 ゴールまで持ちそうか ヒト+iPhone 現地写真・音声メモ 何を見て、何を伝えたか AI チェックポイント番号・移動指示 何をさせようとしたか AI 目標物画像 何を探させたか AI 写真判定・信頼度・判定理由 なぜ次へ進めたか AIが送った目標物画像と、ヒトが撮った写真を並べると照合の流れがわかります。 撮影写真照合NG 撮影写真照合OK 信頼度と理由も残しているため、AIが判断した根拠を後から確認でき、 途中で何が起きていたかをデータとして振り返れます。 おわりに 今回は、AIにルートマップを読ませてオリエンテーリングをしてみました。 AIは次の目的地を考え、目標物を示し、現地写真を判定します。 iPhoneは周囲の情報を集め、指示を表示します。 そしてヒトは歩きます。 ヒトはフィジカルAIに進化したのでしょうか。 残念ながら、私の脚力は一切アップデートされませんでした。 ただし、AI、スマートフォン、通信基盤、そしてヒトを組み合わせることで「認識・推論・行動」のループを現実世界で回せました。 今回ヒトが担当した部分をモビリティやロボットへ置き換えると、巡回点検のようなシステムへつながります。 現地から写真やセンサーデータを送り、遠隔のAIが判断し、次の行動を返す。 今回の自由工作は、その小さな模型です。 フィジカルAIを活用するのに、必ずしも最初から立派なロボットを用意しなくてもよいのかもしれません。 まずは手の中のスマートフォンと、自分の身体からはじめられます。 もっとも、次回までには歩くところも奪ってほしいところです。 実際のオリエンテーリングは、人が密集していない開けた場所で安全に行われます。乗降者数世界一の駅近辺でスプリントレースを開催するのは危険ですので、おやめください。今回は周囲の状況を確認し、交通ルールを守って歩行しています。 ↩ 拡張機能 App Intents を組み込んでショートカットから呼び出せるようにしています。 ↩ つまり、猛暑日の新宿一周を事前にもう一回行ったということです。 ↩ 地図と位置説明は、 International Specification for Control Descriptions 2018 日本語版 および International Specification for Orienteering Maps 2017-2 日本語版 を参考にしています。ただし、作りやすさとAIの読み取りやすさを優先してカスタマイズしており、仕様に則っていない部分があります。 ↩ 本ツールは試作であり、現在、公開や提供の予定はありません。 ↩ 熱中症警戒アラートが出ている日に屋外を2時間歩き回るのは危険です。実施する場合は気象情報と体調を確認し、危険を感じる前に中止してください。この記事の試行条件を再現しないでください。 ↩ 動画のテロップは白がヒト、グリーンがAIの発言です。途中からグリーンばかりになるのは、主体がAIに切り替わっていく演出です。 ↩

出展の概要 会場の印象 アプトポッドブースの展示 点検・警備ソリューション メーター読み取り 四足歩行ロボット以外の連携：ドローン・ウェアラブルカメラ・サーマルカメラ 通信 リアルタイムデジタルツインソリューション 映像3Dモデル化デモ フィジカルAI 来場者の反応 まとめ こんにちは、クロスインダストリー事業部ソリューション開発グループの影山です。同事業部で製品・ソリューションの開発を担当しています。 この度、株式会社アプトポッドは、2026年7月15日（水）から17日（金）までの3日間、東京ビッグサイト東展示棟で開催された「メンテナンス・レジリエンス 2026」に出展しました。おかげさまで3日間を通して多くの方にブースへお立ち寄りいただきました。ありがとうございました。 https://mente.jma.or.jp/ 今年は、点検・警備、リアルタイムデジタルツイン、フィジカルAIといったトピックにフォーカスして展示を行いました。本記事では、それぞれについてご紹介していきたいと思います。 出展の概要 アプトポッドは産業用IoTミドルウェア「 intdash 」を提供しています。これまで自動車開発や建設機械の領域で導入いただいてきましたが、設備の点検・保全という領域でもintdashの特長を生かせると考え、さまざまなユースケースのデモや事例を展示しました。intdashはマルチモーダルなデータをリアルタイムに扱うことに長けています。カメラ映像、LiDARの点群、ロボットのROSトピック、ガスセンサーの値、既存設備のデータといった、種類も周期もばらばらな大量のデータを、時刻を揃えたままリアルタイムに集めて遠隔から扱いたい、というニーズにマッチします。 www.aptpod.co.jp 今回のデモ全体の構成図 今回の出展では、複数の四足歩行ロボットを動かして点検をデモしたり、同時にドローンの映像をintdashへ転送したりといった実演を通じて、メーカーも種類も異なる機体・センサーを、intdashという1つのデータ基盤の上で運用する様子を、実機と画面でそのままご覧いただきました。 会場の印象 会場を歩いていて印象的だったのは、点検ロボットやドローンを展示しているだけでなく、実際に動かしているブースが非常に多かったことです。人手不足を背景に、インフラ・プラントの点検をいかに自動化・省人化するかというテーマが、実証段階から運用段階へ移りつつあることを感じました。 アプトポッドブースの展示 アプトポッドブースの様子 点検・警備ソリューション 点検や警備の分野では、人手不足が課題になっているというお話をうかがうことが特に多くなっています。よくうかがう課題は、人が現場に行かないと状況が分からないこと、計器の値を人が目視で読む必要があること、定置センサーがない箇所は人が足を運ぶしかないことです。 ブースの前面では、「カメラやセンサーを搭載したロボットが自律的に現場を歩いて移動する」「ロボットが撮影した画像をAIが解析して数値にする」「ロボットからのデータとAIの解析結果を、すべて1つのintdashの画面でリアルタイムに見る」という組み合わせで実演しました。 ブース内には昇降ステップやダミーの計器を配置して簡易的なプラントを模擬し、そのなかを Unitree Go2 や Unitree A2 が走行しました。 デモエリアを歩き回るロボットたち Unitree Go2 では、 パナソニック アドバンストテクノロジー株式会社 様の自律移動ソフトウェア「@mobi」を使い、事前に作成した地図とウェイポイントに沿ってブース内を巡回します。頭部カメラに加えて、背中に3D LiDAR（Livox Mid-360）と360度カメラ（Insta360 X5）、そしてCO2センサーを搭載しました。 adtsd.jpn.panasonic.com Go2の背中。3Dプリンタ製のケースに360度カメラとアンテナ、CO2センサーを載せています Unitree A2 は最近発売された新機種で、防塵防水に対応しており、重いペイロードも搭載できます。今回は自律走行は行わず、intdashを経由した遠隔操縦のデモを行いました。遠隔操縦だけでなく、 株式会社ザクティ 様のPTZカメラの向きを遠隔から操作できるようにし、さらに 理研計器株式会社 様のマルチガスセンサー GX-3R Pro を搭載して、ガスのセンサー値をリアルタイムにintdashへ送りました。PTZカメラを遠隔からパン・チルト・ズームさせて、離れた場所の計器を読みに行く、という使い方ができます。 A2の背中。PTZカメラとマルチガスセンサーを搭載しています product.rikenkeiki.co.jp xacti-co.com ブースの入り口で展示していた Unitree Go2-W は、脚の先が車輪になっているモデルで、こちらには TechShare 社株式会社 様の自律移動パッケージ「Patrobot」を載せています。搭載しているのはCO・アルコールガスセンサーと放射温度計。ガス漏れと発熱という、プラント点検で真っ先に見たい2つを歩きながら測るイメージです。 展示では昇降ステップを並べて段差を作り、ロボットが階段状の障害物を昇り降りする様子もご覧いただきました。 ブース内を自律走行して、メーターの自動読み取りを行うUnitree Go2 techshare.co.jp メーター読み取り アナログ計器は、人が値を目視で読み取って記録する作業が必要です。それを自動化する例として、ロボットのカメラ映像からメーター領域を切り出し、「hakaru.ai」 の認識APIに問い合わせて数値に変換するデモを行いました。 読み取った値は、そのまま intdash の時系列データとして扱えます。intdashへ送ることで、カメラの映像などと並べてメーターの読み取り値を確認できます。また、リアルタイムに見るだけでなく、あとからAPIを利用して回収することもできます。 切り出されたメーター画像と読み取り値。CO2濃度や人物検出数と同じ画面に並びます www.hakaru.ai 四足歩行ロボット以外の連携：ドローン・ウェアラブルカメラ・サーマルカメラ 四足歩行ロボット以外にも、ドローン、ウェアラブルカメラ、サーマルカメラとの連携を展示しました。 ドローンのデモでは、ドローン搭載カメラのライブ映像をintdashへ送り、高所や空中からの確認が可能なことを紹介しました。俯瞰位置に設置したサーマル監視カメラ（EDGEPLANT T1 経由）では、RGB映像とサーマル映像を同時に配信し、温度異常を色で確認できることを紹介しました。 株式会社ザクティ 様のウェアラブルカメラは Raspberry Pi 経由で接続し、ブレ補正された作業者目線の映像を送れることを実演しました。 これらの映像については、サーバー側でYOLOによる人物・物体検出を行い、映像を後処理して検知することも可能であることをデモしました。 ロボット・固定カメラ・人・ドローンという性格の違うデータソースを、intdashで統合して確認できることが、このソリューションの大きな特長の一つです。 ドローンの映像も、ロボットやカメラと同じ画面で確認できます xacti-live.com 通信 各ロボットには回線ボンディングに対応した Peplink MAX BR2 Micro を利用し、混雑した会場内でも2回線を束ねることで安定したモバイル通信を実現しました。 www.caso.co.jp リアルタイムデジタルツインソリューション このエリアでは、施工現場の状況を仮想空間に再現するリアルタイムデジタルツイン基盤をご覧いただきました。画面には現場の3D点群が広がり、その上に車両の走行軌跡が重なります。同じ画面の中に掘削量・盛土量といった土量の数値、地表の断面形状のグラフ、そして車載カメラの映像が並び、すべてが同じ時間軸で再生されます。「現場のいつ・どこで・何が起きていたか」を、後から3D空間ごと巻き戻して確認できる、というイメージです。 3D点群の上に車両の走行軌跡、土量、断面形状、車載カメラ映像が同じ時間軸で並びます 実際に動いている様子は、こちらの動画でご覧いただけます。 www.youtube.com 映像3Dモデル化デモ ブースを iPhoneアプリ intdash Motionで撮影した映像データを、 株式会社Liberaware 様が提供する「 LAPIS 」に連携して点群化し、3Dモデルとして表示しました。 専用の3Dスキャナーだけでなく映像を起点として空間を3D化できるため、設備や現場の状況把握、遠隔からの確認など、さまざまな活用が期待できます。映像を見るだけの監視から、空間として記録・参照する活用へ広がる点が興味深い展示でした。 www.youtube.com フィジカルAI フィジカルAIのエリアでは、これから応用が進んでいくであろうこの分野でも、intdashを活用できそうな事例をご紹介しました。 ロボットやAIを現場で賢く動かすには、大量の現実世界のデータが必要です。一方で、危険な状況やめったに起きない事象は、実環境ではなかなか集められません。そこで、実環境から集めたデータと、シミュレーション環境（Gazeboなど）で生成したデータを、intdash で同じように収集・蓄積する構成をご紹介しました。 あわせて、学習データの収集からアノテーション、モデル開発、実機へのOTAによるモデルデプロイ、そして運用時の遠隔監視・遠隔診断・遠隔制御介入までを一連のパイプラインとして構成する取り組みも、 FastLabel 株式会社様との連携例としてご紹介しました。動画像と関節角度・圧力といったマルチモーダルなデータを、時刻を揃えたまま時系列データベースに蓄積できることが、この構成の前提になっています。 収集したデータを使える形に整えるデータ加工レイヤも重要です。データ収集レイヤであるintdashから必要な時系列データを取得し、解析処理を行ったうえで、運用に必要な形に出力する仕組みが求められます。その一例として、Power BIとintdashを連携させるデモを展示しました。 データ収集レイヤ・加工レイヤ・活用レイヤの3層構成 来場者の反応 ブースでは、プラントや工場の設備保全、倉庫や施設の点検業務のDX推進など、さまざまな立場の方にお立ち寄りいただきました。 四足歩行ロボットによる巡回点検の展示について、反応を多く頂きました。ロボットの導入を考えてはいるものの、まず何から始めればよいのか悩んでいる、という声も多くうかがいました。 「カメラやセンサーはすでに導入しているが、形式も周期もばらばらで突き合わせられない」といった、データのサイロ化に関する課題を挙げられる方もいらっしゃいました。マルチモーダルな時系列データを時刻を揃えて収集するという intdash のアプローチについて、その必要性を実感を持って受け止めていただけたケースも多かったように思います。 まとめ メンテナンス・レジリエンス 2026 にご来場いただき、アプトポッドブースにお立ち寄りいただいた皆さま、誠にありがとうございました。 アプトポッドは、intdash を通じて、現場点検のロボット化・遠隔化、複数のカメラやセンサーを統合したリアルタイム可視化、現場のデジタルツイン化、ロボット・AI開発のためのデータ基盤といった、さまざまな領域で現場のデータ活用を支援してまいります。お困りごとがありましたら、ぜひ お問い合わせフォーム からご連絡ください。