はじめに こんにちは。医療プラットフォーム本部ビジネス基盤グループでエンジニアをしている熊本です。 ブログへの登場は久々となりますが、2019年に新卒で入社して以来、長らくプロダクト開発のエンジニアをしてきました。そんな私は現在、医療プラットフォーム全体のMA（マーケティングオートメーション）、SFA（営業支援）、CRM（顧客管理）といったITツールおよび業務フローの設計・改善を通じて、事業パフォーマンスの向上を担う開発組織のマネージャーを務めています。 メドレーでは、患者・生活者と、病院・有床診療所、医科診療所、歯科診療所、調剤薬局といった各医療機関向けに事業・プロダクトを展開していますが、今回は、これらの事業を支えるITツールの Salesforce を kintone へ移行したプロジェクトについてお話しします。 背景 SFAが抱えていた課題 弊社では長年、医療プラットフォームにおける複数の事業部門で共通のSalesforceを利用してきましたが、運用を続ける中で以下のような課題が顕在化していました。 最新・正しい情報の把握が困難 ：正規化されていないデータや重複管理による情報の分散 データ分析の壁 ：分析を見据えた設計になっておらず、プロダクト側の利用状況との突合など、柔軟なデータの加工に工数がかかっていた 非効率な業務フロー ：複数ツールの併用や重複する項目の存在などを背景に、手動での転記やダブルチェックが発生している状態 システム管理の属人化 ：目的が不明な項目が乱立し、メンテナンス・レポート作成ができる人が限られている状態 また、130個近くのライセンスを保有していたため、これらの課題を踏まえるとコスト過多な状況にも陥っていました。 全ての顧客体験をプロダクト側が理解し、設計責任を持つ 私たちは、 営業・カスタマーサクセスといった顧客活動から、契約・請求に至るまでを「一連のプロダクト体験」として捉え 、その設計・実装にエンジニアが深く関わることを大切にしています。 この考えに基づき、単なるツールのリプレイス（お引っ越し）ではなく、より良い顧客体験につながる合理的で整理された事業オペレーションを実現するため、 業務・データ・ツールを一体でエンジニアが設計し直す 。これが本プロジェクトの重要なポイントでした。 取り組み 体制構築とアーキテクチャ設計 前述の通り、Salesforceはこれまで複数の事業部門で活用してきました。1人で各事業の業務フローや必要データを把握し再設計するのは困難ですし、何より私たちが大切にしている考え方も踏まえ、プロダクトエンジニアが各事業に深く潜り込んで再設計すべきだと考えました。そこで、各事業領域からプロダクトエンジニアを1名ずつアサインする体制としました。私はPMとして全体設計や車輪の再発明が起きないよう各部門の連携をコントロールする役割を担い、各環境のデータ設計・構築はその事業領域担当のエンジニアが主導する形をとりました。 kintoneは責務分離やメンテナビリティを考慮し、事業領域ごとに環境を分けるアーキテクチャを採用しました。また、kintoneへの移行に伴い、コストや親和性を加味してMAツールの移行も行いましたが、本記事では詳細を割愛させていただきます。 医療プラットフォーム本部の組織体制 ツールの移行イメージ 業務理解と要件定義 まずは、日々の事業活動の中で発生するデータや、業務上必要となるデータ、およびそのフローの現状とあるべき姿を描くため、事業部とコミュニケーションを重ねました。長年利用してきたこともありデータ項目が膨大となっていたため、「このデータをどう活用するのか」を重点的に会話し、そもそも不要ではないか、より活用しやすくするにはどうすべきか、などの整理に時間をかけました。 データ設計 特に工夫したのは、DB観点での「正規化」とユーザー観点での「入力のしやすさ」のバランスをとったデータ設計です。kintoneはDBとUIが一体型であるため、このバランス調整にとても苦労しました。一般的なRDBMSではデータの履歴を残すために専用のテーブルを設けイミュータブルモデリングなどを採用する場面でも、kintoneだとテーブル≒アプリとなるため、テーブルを分けることは単純にユーザーの画面遷移や入力箇所を増やすことに直結してしまいます。こういった場合は完全な正規化をするのではなく、普段の商談管理で使用するアプリとその商談ステータスの履歴を管理するアプリを分け、それぞれのアプリに同類のフィールド（RDBMSのカラムをkintoneではフィールドと呼びます）を設置することを許容しつつも、JavaScriptを用いた自動転記の仕組みを作ることで、ユーザーは商談管理アプリだけに入力していれば良いようにするといった工夫をしました。 泥臭く戦ったポイント：データ移行と同期システム ここからは、エンジニアとして特に苦労した2つのポイントをご紹介します。 1. 冪等性と再現性を追求したデータ移行 100名以上が利用するシステムにおいて、特にデータ移行には慎重を期しました。具体的な方法としては、Salesforceのスキーマをkintoneのスキーマに変換し、データをマッピングした結果をCSVに出力するという一連の処理を、CLIコマンド等の整備によりスクリプト化しました。 データ移行では、一度kintoneに投入した後、UAT期間中に事業部からのフィードバックを受けて設計を見直し、再投入が必要になるケースがありました。また、リハーサル目的で、本番移行前にも何度でも再実行できる仕組みが必要でした。そのため、前述のように一連の処理をスクリプト化し、「再現性」を確保しました。さらに、「冪等性」も重要なポイントでした。今回のケースでは、それぞれのアプリにユニークキーを設けて常にUPSERT処理を行うことで、元データが同じであれば、何度実行しても同じ状態を再現できるようにしました。 kintoneへのインポート処理自体はレコード数に比例して一定の時間がかかってしまうものの、事前に手順化しリハーサルを重ねたことで、本番稼働前日の夜間作業で無事に移行を完了させることができました。ただし、（一定の想定範囲ではあったものの）移行作業直前にSalesforce側でデータの更新や削除が行われたことで、kintone側で関連データ同士の紐付けがうまく設定できないケースも発生しました。これはエラーログを見て個別に対処するしかなく、大変苦労した部分でもありました。 2. Salesforceとkintoneの双方向同期システム Salesforceは長年活用してきたことから、いわゆるSFAとしての機能だけではなく、請求や契約管理としての役割も担っていました。今回のプロジェクトでは事業部側が利用するSFAとしての機能はkintoneへ移行しつつも、請求や契約管理といったバックオフィス領域に関しては将来的な販売管理システムへの移行も見据えてスコープ外としていました。よって、これまでは一つのシステムの中で顧客・商談から契約・請求まで一元管理していたものを分離したため、システム間でデータを連携させる必要がありました。 詳細は省きますが、Salesforceに残った契約・請求関連データの一部は、営業やカスタマーサクセスなどの事業部側と契約・請求処理を担うバックオフィス部門の双方向による書き込みが業務上必要であったため、単にkintoneから必要なデータを一方向で送るだけでは要件を満たせませんでした。そのため、SFA領域とバックオフィス領域のハブとなる「商談」などのデータに関しては、Salesforceとkintone間で一部のスキーマ定義を揃え、両システムを一定間隔で同期させる仕組みとしました。 具体的な仕組みとしては、両システムのスナップショットを一定間隔で取得し、前回との差分を検知して互いのシステムへ反映し合う形をとりました。 ここで壁となったのが、「準リアルタイム性」の要求と「データの競合」です。両方のシステムで日常的にトランザクションが発生するため、「同じレコードの同じ項目が、それぞれのシステムで同時に別の値へ書き換えられる」可能性がありました。この競合状態を安全に解決するためのロジックを構築する必要があり、非常に苦労しました。 この対応にあたっては、当初想定していた対象項目が、本当に準リアルタイムで同期が必要なのかを関係者と徹底的に精査しました。その結果、同期間隔の調整や同期対象の大幅な絞り込みができ、現在は安定して稼働する仕組みを実現できています。 ※ データ移行や同期処理のディープな話は盛りだくさんな内容となってしまうため、また別の機会にブログ化できればと思います！ 成果 80%以上のランニングコスト削減 契約・請求などを担う組織の必要分を除き、90個ほどのアカウントを削除することができました。kintoneの費用を加味しても、全体のランニングコストとして80%以上削減することができました。 BigQuery集約によるデータ分析・可視化の実現 Salesforceのレポート機能の制約から解放され、より柔軟なデータ活用ができるようになりました。 KPIダッシュボードの構築 ：Looker Studioなどのアセットと連携したデータの分析・可視化が可能に 自律的な分析文化 ：勉強会の開催やマニュアル整備のおかげもあり、事業部メンバーが生成AIも活用しながら、より自律的かつスピーディなデータ分析が可能に 横断的分析 ：kintoneの顧客・商談データ、契約データ、プロダクトデータなどをBigQueryに集約し、多角的な分析を実現 また、横断組織にあるデータ戦略グループが、最近「自然言語でBigQuery等のデータを分析できる社内システム」をリリースしました。今回のプロジェクトによるデータ整備とこのシステムが組み合わさり、よりスピーディにデータ分析を行える環境づくりが加速しています。 関連記事： データ分析AIエージェントの実践 - Slack × Devin × Context Engineering 今後の展望 本プロジェクトによって多くの成果を得られましたが、私たちはまだ「業務やデータの一部をツールの移行と共に再設計し、基盤を整えた」に過ぎません。 今後はこの基盤を活かし、KPIなどの定量的なデータや現場ヒアリングを通じて事業の課題・ボトルネックを特定し、継続的に改善を回すサイクルを作っていきたいと考えています。 また、日々顧客と向き合う事業部のメンバー自身が、データ活用や拡張性を見据えて自律的にツールを改修できる状態こそが、組織のアジリティを最も高く保ちながらスケールできる理想の形だと考えています。その実現に向けて、エンジニアリングの専門性を持つ私たちビジネス基盤グループが、誰もが改修・改善しやすい仕組みづくりを牽引していきたいと考えています。 まとめ エンジニアが事業の深い部分に入り込み、業務・データ・ツールを一体で再設計するプロジェクトについてご紹介させていただきました。 メドレーでは、「医療ヘルスケアの未来をつくる」というミッションのもと、エンジニアがビジネスの根幹に関わり、プロダクトと事業を共に成長させる文化があります。自ら課題を発見し、設計から運用までをエンジニアとしてのリーダーシップを発揮しながら一気通貫で推進できる方を絶賛募集しています。 メドレーで働く｜株式会社メドレー メドレーでの働き方や人事制度、求人情報など、採用に関する情報をご紹介します。 www.medley.jp 少しでも興味を持っていただけましたら、ぜひメドレーの採用ページをご覧ください！

CRM（顧客管理システム）、SFA（営業支援システム）、MA（マーケティングオートメーション）ツールの役割、機能、活用方法、選定ポイントを紹介しています。各ツールの目的や管理対象、主な機能を比較し、企業の活用事例や選定時のポイントを解説しています。

本記事は 2025 年 12 月 2 日 に公開された「 Physical AI: Building the Next Foundation in Autonomous Intelligence 」を翻訳したものです。 はじめに 世界は自律型経済 (Autonomous Economy) に向かって動いています。AI、エッジコンピューティング、ロボティクス、空間インテリジェンス、シミュレーション技術が連携し、人の介入を最小限に抑えてシステムが自律的に動作する経済モデルです。フィジカル AI はこれらの技術の融合であり、コンピュータが物理世界を感知し、理解し、予測し、行動できるようにすることで、自律型経済への移行に大きな機会をもたらします ( https://www.linkedin.com/pulse/path-fully-autonomous-economies-andre-drpde/ )。フィジカル AI は自律運用へのパラダイムシフトを支え、純粋にデジタル環境で動作する従来の AI システムから、物理世界を知覚し、理解し、行動できるインテリジェントシステムへと進化させます。輸送 (自動運転車)、製造 (無人製造施設)、エネルギー (現場の人員を最小化し危険エリアの自動検査を実現)、ヘルスケア (低侵襲ロボット手術) など、あらゆる分野を変革しています。以前の ブログ で、AWS はフィジカル AI で実現できる自律性のレベルを説明する 4 段階のフィジカル AI ケイパビリティ・スペクトラムを提案しました。今回は、これらの自律性レベルを達成する方法のガイダンスを提供します。ヘルスケア向けの Diligent Robotics を取り上げた ブログ で実例を確認できます。 本記事では、自動化への道筋を描くための包括的なフィジカル AI フレームワークを説明します。フィジカル AI を抽象的な概念から、開発して技術開発ロードマップに統合できる実用的で具体的な機能に分解します。今日のユースケースに対応し、明日の課題を解決する準備を整えます。物理世界 (アトム) とデジタル世界 (ビット) をつなぐ継続的な学習ループを説明し、物理運用での自律性の開発を加速します。最後に、仮想世界でのフィジカル AI モデルトレーニングと物理世界でのリアルタイム自律運用の違いを明確にし、クラウドからエッジへのハイブリッドデプロイメントで両者がどのように接続されるかを説明します。本記事は、フィジカル AI フレームワークの各機能を深く掘り下げる複数回のブログシリーズの最初の導入記事です。 フィジカル AI の理解 AWS では、フィジカル AI を物理世界と相互作用するために知覚、理解、推論、学習を統合したハードウェアとソフトウェアのシステムと定義しています。 フィジカル AI は人工知能のサブセットであり、時空間的な関係と世界の物理的性質の理解に焦点を当て、センサーとアクチュエータを通じて周囲の環境と相互作用します。画像、動画、テキスト、音声、深度/LiDAR、実世界のセンサーデータなどのマルチモーダル入力を処理し、洞察を導き出し、複雑で動的な環境で独立して動作できる自律システムでのリアルタイム意思決定を可能にします。たとえば、AI モデルは推論を使ってコーヒーを注ぐ方法を説明できますが、フィジカル AI モデルはまずコーヒーがどこにあり、カップに注ぐ必要があることを推論し、さらに物理世界への追加機能を拡張して、実世界の条件下でコーヒーを識別し、つかみ、持ち上げ、カップに注ぎます。 AWS のフィジカル AI フレームワーク フィジカル AI の可能性を完全に実現するには、自律システムのライフサイクル全体に対応する体系的なアプローチが必要です。図 1 に示す AWS フィジカル AI 概念フレームワークは、デジタルインテリジェンスと物理的アクションの間に継続的な学習サイクルを作り出す 6 つの相互接続された機能を通じて、この包括的な構造を提供します。これは、エンドツーエンドのフィジカル AI 技術スタックでカバーされる 6 つの機能領域にズームインしたもので、この ブログ でも取り上げられています。まず各機能を説明し、次にこれらの機能が仮想世界でのトレーニングループと物理世界での自律ループを構築・接続し、ハイブリッドクラウド-エッジデプロイメントを通じてどのように使用されるかを説明します。このように、フィジカル AI は将来の状態について推論し、複雑なアクションシーケンスを計画し、物理的能力を継続的に改善するシステムへの進化を表しています。 図 1: トレーニングループ、自律ループ、6 つの主要機能を示すフィジカル AI 継続的学習ループの図 1. 物理世界の接続とデジタル化 : フィジカル AI システムの基盤は、実世界の情報を取得してデジタル化する能力にあります。IoT デバイス、センサー、カメラ、その他の物理デバイスが物理環境からマルチモーダル状態データを収集します。LiDAR などの空間センサーは深度と体積データをマッピングし、地理空間データと衛星データは広大な物理エリアをマッピングし、温度、湿度、化学組成などのパラメータを監視するセンサーが使用されます。これらのさまざまなデータは、1D データストリーム、2D 画像、3D ポイントクラウド、センサーデータ、エンタープライズ運用技術 (OT) システムと資産管理システムからのメタデータを通じて、物理世界の包括的なデジタル表現を作成します。この豊富な感覚入力が、後続のすべての AI 処理の基盤となります。AWS では、 Amazon IoT SiteWise 、 Amazon IoT Core 、 Amazon Kinesis Video Streams など、 Industrial Data Fabric および Smart Machine ソリューションガイダンスの一部として使用できるサービスや、3D データ収集用の Matterport、Treedis、Prevu3D などのパートナーソリューションを提供しています。 2. データの保存と構造化 : フィジカル AI システムは二重経路アーキテクチャを採用しています。低レイテンシーのセンサーデータストリームは、ネットワークをバイパスしてエッジ ML モデルに直接送られ、リアルタイムオペレーティングシステム (RTOS) を使用して即座の反応制御を実現します。一方、より高レベルの推論タスクは、クラウド接続されたナレッジグラフとエンタープライズシステム統合 (ERP、CRM、LIMS、PLM) を活用して、複雑な計画と意思決定を可能にします。非構造化された多様なデータタイプを効率的に処理して相関付けできます。フィジカル AI システムで効果的にデータを管理するには、リアルタイム解析を維持しながら、複数のソースからの膨大な量の情報を処理する必要があります。高度なストレージアーキテクチャとデータ処理パイプラインにより、組織はこの複雑さを管理しながら、即座の意思決定と長期的な学習の両方に重要な情報を利用可能に保てます。AWS では、ストレージ用の Amazon S3 、 Amazon DynamoDB 、 Amazon Aurora などのサービスや、複雑な空間、IT、OT データを管理するための Spatial Data Management on AWS ソリューションを提供しています。 3. データのセグメント化と理解 : この段階では、変換、クリーニング、センサーストリームの時間的リサンプリングなどのデータ操作を処理し、動画、LiDAR、時系列データを構造化された 3D モデルと環境表現に変換してシミュレーションワークフローに情報を提供します。前処理と関係マッピングを通じて、生のマルチモーダル物理世界データを AI 対応の洞察に変換します。ナレッジグラフを通じて異なるマルチモーダルデータセット間のオントロジー関係を構築することが重要です。RAG 経由のメンテナンスマニュアルなどのデータを接続し、事前作成された 3D アセットをカタログ化し、空間、運用、時間データディメンション全体でセマンティック接続を確立できます。AWS サービスがこの変換を支えます。 AWS Glue は、マルチモーダルセンサーデータを処理して同期するための組み込みデータ変換パイプラインを備えたサーバーレス ETL 機能を提供し、 Amazon Neptune は、空間関係とアセットメタデータを構造化する高度なナレッジグラフとオントロジーを可能にし、自律システムが物理環境を理解して相互作用するために必要な基礎的なインテリジェンス層を作成します。産業検査レポート自動化のフレームワーク例については、この ブログ をご覧ください。 4. シミュレーション、トレーニング、モデル最適化 : シミュレーション環境は、実世界のリスクなしに自律システムをトレーニングするための安全で制御された空間を提供し、複数のユースケースにわたるフィジカル AI システムの開発をサポートします。これらの環境により、ニアエッジデプロイメントを対象としたモデル開発のための包括的なトレーニングが可能になり、AI システムは、現実でテストするのが非現実的または不可能な稀なケースや危険な状況を含む、無数のシナリオから学習できます。シミュレーション機能にはデジタルツインが含まれ、シミュレーションベースのトレーニングと仮想テスト、モデル開発用の合成データ生成、ML とハイブリッド AI + メカニスティックモデルの両方のトレーニングと調整、エッジデプロイメント用に最適化されたモデルの開発が含まれます。シミュレーション環境により、フィジカル AI モデルの反復的な最適化が可能になり、チームはエッジデプロイメント前に多様なシナリオ全体でパフォーマンスを検証しながら、知覚、意思決定、制御アルゴリズムを改良できます。シミュレーション機能は、基本的なデジタル表現から世界物理モデル (NVIDIA Omniverse、Unity、Unreal Engine、その他新興の WFM) まで、高忠実度エンジニアリングシミュレーション (数値流体力学、有限要素解析、熱力学プロセスモデリング) まで多岐にわたります。AWS で NVIDIA Cosmos world foundation model を実行する 例 をご覧ください。フィジカル AI モデルはデジタルツインで表現できる可能性があります。デジタルツインは複雑なトピックであり、 L1-L4 デジタルツインレベリングガイド と デジタルツインフレームワーク リファレンスアーキテクチャ を開発しました。AWS では、 AWS Batch 、 AWS ParallelCluster 、 AWS Parallel Computing Service 、 Amazon SageMaker 、 Amazon EKS/ECS など、モデルの構築、オーケストレーション、トレーニングのためのさまざまなサービスを提供しています。 5. 自律システムのデプロイと管理 : トレーニングと検証が完了したら、AI モデルとポリシーを堅牢な管理機能を備えた自律システムにデプロイする必要があります。この機能は、無線アップデート、エージェントポリシー管理、継続的なシステムアップデートを処理し、デプロイされたシステムが最新で、コンプライアンスに準拠し、効果的であることを保証します。デプロイフェーズでは、エッジコンピューティング機能、ローカライズされたインフラストラクチャ、ネットワーク接続、セキュリティ要件を慎重に検討する必要があります。システムは、中央管理システムから切断されている場合でも確実に動作し、アップデートを受信してステータス情報を報告する能力を維持する必要があります。 AWS IoT Greengrass は、自律システムへの AI モデルとアプリケーションの安全なデプロイと管理を可能にするコアエッジランタイムとして機能し、無線アップデート、ローカル処理機能、中央管理システムから切断されている場合でも確実に動作する能力をサポートします。 AWS IoT Device Management は、リモートデバイス監視、ポリシー管理、自動無線ファームウェアアップデートを含むフリート全体の運用を提供してこれを補完し、 AWS Systems Manager は、OS パッチ適用やアプリケーションデプロイメントなどのタスクのために、従来の IT インフラストラクチャと並んでエッジデバイスの一元管理を可能にします。さらに、 AWS IoT Core は、自律システムとクラウド間の安全な双方向通信を促進し、リアルタイムステータスレポートとポリシーアップデートを可能にし、 AWS Secrets Manager や IoT Device Defender などのサービスは、デプロイされた自律フリート全体で堅牢なセキュリティとコンプライアンス管理を保証します。 6. エッジ推論と運用 : 最後の機能は、インテリジェンスをエッジにもたらします。エッジベースのコンピューティングにより、低レイテンシーのデータ転送が可能になり、ネットワーク依存なしにアクチュエータとセンサーアレイを駆動するオンデバイスコンピューティングのリアルタイム分析が可能になります。フィジカル AI システムは、自動運転車の衝突回避や産業機器の緊急停止など、ミリ秒単位が重要でネットワーク接続に依存できない重要なアプリケーションに即座の応答を必要とします。エッジデバイスに高度な推論機能をデプロイすることは、モデルパフォーマンスの最適化、超低レイテンシー推論、信頼性の低い接続下での動作において大きな課題を提示し、リソース制約のあるエッジハードウェアで高度なフィジカル AI モデルを実現するための AWS の重要な投資領域となっています。AWS では、 AWS IoT Greengrass などのサービスを提供しており、クラウドから切断されている場合でも超低レイテンシーでローカル AI 推論を可能にし、 AWS Local Zones と AWS Outposts はクラウド機能をリモートロケーションに拡張し、ネットワーク依存を減らすために AI 処理がローカルで行われることを保証します。 フライホイール効果: 運用を通じた継続的な推論改善 フィジカル AI フレームワークが特に強力なのは、データ駆動型の改善ポテンシャルです。自律システムが実世界で動作すると、フィジカル AI モデルの改良に役立つ運用データが生成されます。強化されたモデルはより高性能な自律システムを可能にし、それがさらに追加のトレーニングデータを生成し、運用コストを削減しながら能力向上を推進できるフィードバックループを作り出します。この学習サイクルは、フィジカル AI システムが時間とともにより効果的になる可能性があることを意味しますが、改善の度合いは環境の性質と収集されるデータの品質に依存します。物理世界との各相互作用は、新しいトレーニングデータ、エッジケース、最適化の機会を提供します。フレームワークをうまく実装した組織は、戦略的なモデル管理と人間の監視を組み合わせることで、運用経験を蓄積するにつれて、システムがパフォーマンス、信頼性、効率の向上を示すことが期待できます。 デュアルループアーキテクチャ: クラウドとエッジの統合 フレームワークは、包括的なフィジカル AI 機能を提供するために連携して機能する 2 つの重要なループを通じて動作します。トレーニングループは主にクラウド環境で動作し、データ処理、AI モデルトレーニング、シミュレーション活動を処理します。計算能力、ストレージ容量、グローバルに分散されたネットワークインフラストラクチャを活用して、AI 機能を開発して改良します。自律ループは、リアルタイム運用と物理世界との相互作用に焦点を当て、通常、自律システムがデプロイされているエッジで動作します。速度、反復、信頼性を優先し、クラウドリソースへのネットワーク接続に依存せずに、システムが変化する条件に応答できることを保証します。2 つのループの統合により、組織はクラウドインフラストラクチャの計算上の利点とエッジデプロイメントの応答性要件の両方から恩恵を受けられます。データはクラウド環境とエッジ環境の間をシームレスに流れ、運用の信頼性を維持しながら学習と改善が継続的に行われることを保証します。 自律運用の安全なデプロイ セキュリティは AWS のフィジカル AI フレームワークの基盤を形成し、自律システムはデジタルから物理へのループのすべての段階で揺るぎない信頼と回復力を持って動作する必要があります。組織が物理システム、デジタルインテリジェンス、人間の監視の間の関係を調整する AI エージェントをデプロイする際、AWS はエッジからクラウドまで安全な自律運用を可能にするセキュリティフレームワークを提供します。フィジカル AI フレームワークは本質的に、初期センサーデータキャプチャと空間データ管理から、AI モデルトレーニングと物理ベースのシミュレーション、自律システムデプロイメントとリアルタイムエッジ推論運用まで、ワークフロー全体を通じてエンタープライズ統合とセキュリティコンプライアンスを優先する必要があります。安全/機密性の高い環境で動作したり人と相互作用したりすることが計画される自律システムには、プロプライエタリ/非公開のデータと環境、個人を特定できる情報 (PII) などのセキュリティ考慮事項が必要です。AWS のセキュリティ体制は、マルチモーダルデータフローの保護、フィジカル AI モデルの AI トレーニングパイプラインの保護、デジタルツインの安全な運用の保証、物理システムとデジタルブレイン間の安全な接続ループ (オプションの転送中暗号化と保管時暗号化を含む) によってフィジカル AI に適用されます。セキュリティファーストのアプローチにより、顧客は最高水準のデータ保護、アクセス制御、運用整合性を維持しながら、物理世界を知覚し、理解し、行動できる自律システムを自信を持って開発でき、最終的に企業が最も重要な資産と運用を保護しながらフィジカル AI の変革的な可能性を実現できます。 自律型経済の構築 フィジカル AI フレームワークは、組織に自律運用への道のりのロードマップを提供し、新興の自律型経済に貢献して恩恵を受けるのを支援します。初期データ収集から継続的な運用と改善まで、自律システムの完全なライフサイクルに対応するアプローチを実装することで、組織はそれぞれの領域で持続可能な競争優位性を開発できます。 フィジカル AI での成功には、個々の技術をデプロイするだけでなく、感知、処理、学習、アクションを、複雑な環境で独立して動作できる一貫したシステムに統合する体系的なアプローチが必要です。本記事で概説したフレームワークは、安全な自律運用、スケーラビリティ、信頼性、継続的な改善を保証しながら、統合を実現するために必要な構造を提供します。 まとめ AWS のフィジカル AI フレームワークは、組織がデジタル世界と物理世界を橋渡しする自律システムを安全に構築してデプロイする方法の根本的な変化を表しています。物理世界の接続とデジタル化からエッジ推論と運用まで、6 つの相互接続された機能を統合することで、このフレームワークは、実世界の運用データがますます高性能な AI モデルを推進する継続的な改善フライホイールを作り出します。クラウドベースのトレーニングとエッジベースの自律性を組み合わせたデュアルループアーキテクチャにより、組織は人の介入を最小限に抑えながら、複雑な物理環境を理解し、推論し、行動できるシステムを開発できます。製造、輸送、エネルギー、ヘルスケアなどの業界をすでに変革しており、インテリジェントシステムが継続的に学習して改善しながら独立して動作する新興の自律型経済を推進しています。補完的なポッドキャストをご覧ください: Physical AI: Teaching Machines to Act, Not Just Think 。 フィジカル AI が運用をどのように変革できるかを探る準備はできていますか? フィジカル AI フレームワークの各機能を深く掘り下げ、詳細な技術ガイダンス、リファレンスアーキテクチャ、実際の顧客事例を共有する今後の 6 部構成のブログシリーズにご参加ください。自律システムの旅を始めたばかりでも、既存のデプロイメントをスケールしようとしている場合でも、フィジカル AI スペシャリストに連絡して、特定のユースケースについて話し合い、AWS が自律型経済への参加をどのように支援できるかをご確認ください。 著者について David Randle AWS でフィジカル AI の GTM をリードしています。デジタル世界と物理世界を橋渡しする自律システムを実現する AWS の戦略的イニシアチブを担当しています。3D 技術とリアルタイムシステムで 19 年以上の経験を持ち、Dassault Systèmes SolidWorks に買収される前の Bunkspeed でリアルタイムレンダリングの普及に貢献しました。自律運用の基盤となるデジタルツインワークフローと仮想シミュレーションシステムのバックグラウンドに、ビジネスと工業デザインの知見を組み合わせ、変革的な技術をヒューマナイズして明確にしています。これらの経験により、AI を活用したシステムが物理環境をどのように知覚し、理解し、行動する必要があるかについて深い理解を持っています。 Adam Rasheed AWS の Emerging Technology (Advanced Computing) 部門の責任者として、エンジニアリング向けの Agentic AI と自律システムを実現するフィジカル AI の限界を押し広げるチームをリードしています。産業領域とデジタル領域の両方にまたがる中期段階の技術開発で 28 年以上の経験があり、航空、エネルギー、石油・ガス、再生可能エネルギー業界でデジタルツインを 10 年以上開発してきました。Caltech で実験的超高速空気熱力学 (軌道再突入加熱) を研究し博士号を取得しました。MIT Technology Review Magazine から「世界のトップ 35 イノベーター」の 1 人に選ばれ、AIAA Lawrence Sperry Award も受賞しました。産業分析、運用最適化、人工リフト、パルスデトネーション、極超音速、衝撃波誘起混合、宇宙医学、イノベーションフレームワークに関する 32 件以上の特許と 125 件以上の技術出版物があります。 Dan Cotting AWS で Worldwide フィジカル AI Specialist Solutions Architect チームをリードし、この領域の技術リーダーとして、フィールドでの AWS のフィジカル AI アーキテクチャ戦略の開発を支援しています。顧客とパートナーと直接協力して、空間インテリジェンス、シミュレーションとトレーニング、エッジインテリジェンスのユースケースにまたがるフィジカル AI ワークロードを AWS でスケールして成長させています。過去 9 年間、BMW、NVIDIA、ExxonMobil、Koch Industries、Siemens などの顧客やパートナーと協力しながら、自動車、製造、エネルギー、ヘルスケア、航空宇宙業界全体で空間コンピューティングとフィジカル AI を専門としてきました。AI、IoT、空間コンピューティング、シミュレーション、エッジ技術の融合を通じて自律運用を実現することに焦点を当てています。AWS に入社する前は、Magic Leap、Shockoe、Team One で多くの業界のエンタープライズ顧客に空間アプリケーションを提供していました。Virginia Commonwealth University で修士号、Boston University で学士号を取得しています。妻と息子とシアトルに住んでいます。 Ross Pivovar 物理シミュレーションと機械学習の両方のための数値的および統計的手法開発で 15 年以上の経験があります。AWS の Senior Solutions Architect として、自己学習デジタルツイン、マルチエージェントシミュレーション、物理 ML サロゲートモデリングの開発に焦点を当てています。 この記事は Kiro が翻訳を担当し、Professional Services の Akinori Hiratani と Solution Architect の Shinya Nishizaka がレビューしました。