こんにちは、ブログ運営担当の池部です。 8月のブログアクセス数ランキングをご紹介します！！ （2026年8月1日~8月31日計測） 8月アクセス数TOP10 第1位 カバレッジの種類～C0・C1・C2・MCC～ tech.nri-net.com 第2位 【初心者向け】Swaggerとは？シンプルに解説 tech.nri-net.com 第3位 「何もない」を表す概念について ～0やnullとは～ tech.nri-net.com 第4位 Google タグ ゲートウェイ（GTG）ってなに？ - サーバーサイド タグ（sGTM）を利用して導入してみた tech.nri-net.com 第5位 M…

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に切り替わっていく演出です。 ↩