本記事は 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 がレビューしました。

こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp 以前は自社の戦略について書きましたが、今回は視点を変えてみます。 これまで大手・ベンチャー・外資など様々な企業で社内システムに触れてきたユーザーとしての経験、そして現在バックオフィス系SaaSに携わっている提供者としての知見。 これらを踏まえて、自分なりに整理してみました。 目次 はじめに：SaaSの普及と、残された「巨大な壁」 第1章：前提となる「企業の基幹システム」4つのアーキテクチャ 1. Fit to Standard（ERP一本足打法） 2. Two-Tier ERP（2層構造：ERP × SaaS） 3. Composable ERP（レゴブロック型） 4. SaaS Unbundling（脱SaaS・完全内製回帰） 第2章：なぜ「SI」や「AI × BPO」だけでは届かないのか SI（システムインテグレーション）の課題 ── 「要件定義」の壁 AI × BPOの課題 ── 「ブラックボックス化」の壁 第3章：現場を変える「専属シェフ」 ── Forward Deployed Engineer (FDE) 第4章：システムをつなぐ「万能翻訳機」 ── 中間システムとOntology 「データ」に「意味」を与える (Ontology) 異なる言語を翻訳する「万能翻訳機」 第5章：AI時代の新しいアーキテクチャ ── 「自律的AI」への道 AIが「働く」ための地図 おわりに：バックオフィス・プロダクトの解像度を高める はじめに：SaaSの普及と、残された「巨大な壁」 ここ10年で、日本のSaaS市場は劇的な進化を遂げました。クラウド上の優れたツールを契約し、IDを発行すれば、その日から最新のUI/UXで業務ができる──。これが「当たり前」となり、多くの企業で生産性が向上しました。しかし、この成功法則が通用しない領域が依然として存在します。それが、巨大な歴史と複雑な業務構造を持つ「エンタープライズ企業」の基幹業務領域です。 「SaaSを導入したけれど、既存の基幹システムとデータがつながらない」 「現場独自の複雑なオペレーションが、標準機能ではカバーしきれない」 「結局、CSVデータを手作業で加工してアップロードする業務が残った」こうした声は、SaaSベンダーとエンタープライズ企業の双方が抱える深い悩み（ペイン）です。なぜ、便利なSaaSが増えても、現場の苦しみはなくならないのか。その解像度を高めるためには、まず現在企業が置かれている「システム・アーキテクチャの現在地」を知る必要があると思っています。 本記事では、企業の基幹システムが辿ってきた自分なりに整理した「4つのアーキテクチャ」と、既存の「SIやBPO」が抱える課題を整理した上で、その全てを突破するために現れた新しいアプローチ──「専属シェフ（FDE）」と「万能翻訳機（中間システム）」について自分なりに市場の状況を踏まえて解説をまとめてみました。 これは単なるツールの話ではなく、これからのバックオフィスプロダクトが向かうべき、ひとつの進化系統樹の話と思ってもらえればと思います。 第1章：前提となる「企業の基幹システム」4つのアーキテクチャ 「専属シェフ」や「万能翻訳機」という新しい概念を理解するために、まずは現在、エンタープライズ企業がどのようなシステム構造の上に成り立っているのか、その類型を見ていきましょう。大きく4つのパターンに分類されます。 1. Fit to Standard（ERP一本足打法） 最も伝統的かつ、かつての「理想形」とされたモデルです。SAPやOracleといった巨大なERPを導入し、会計・人事・販売・在庫など、企業のあらゆるデータを一つの巨大なシステムで管理します。 特徴： 「業務をシステムに合わせる」思想。データが一元管理されるため、経営層には理想的です。 課題： 現場にとっては「使いにくさ」が壁になります。UI/UXよりもデータ整合性が優先されるため、単純な経費精算にも多大な工数がかかります。また、日本固有の商習慣に合わせるための追加開発（アドオン）により、保守コストが高騰しがちです。 2. Two-Tier ERP（2層構造：ERP × SaaS） 現在、多くの日本企業が採用している現実解です。「本社やコア業務（会計など）は重厚なERPで守り、現場業務（労務、SFAなど）は軽快なSaaSで攻める」というハイブリッド構成です。 特徴： 守りと攻めのバランス型。現場はモダンなSaaSを使えるため、生産性が上がります。 課題： 「データの分断」が最大のネックです。社員マスターがERPにもSaaSにも点在し、それらをつなぐために「月末にCSVを吐き出し、手加工して取り込む」というアナログ作業が残ります 3. Composable ERP（レゴブロック型） Two-Tierをさらに推し進め、巨大なERPを置かずに「各業務における最強のSaaS（Best of Breed）」をレゴブロックのように組み合わせてシステム群を構成する考え方です。 特徴： 「会計はfreee」「人事はSmartHR」「営業はSalesforce」のように最適解を選べ、変化に強い構成です。 課題： インテグレーションの難易度が極めて高い点です。API連携がうまくいかないとデータがサイロ化（孤立）し、全体が見えなくなります。強力な情シス（コーポレートエンジニア）組織が不可欠です。 4. SaaS Unbundling（脱SaaS・完全内製回帰） AIの進化により、近年テック企業を中心に注目され始めた「揺り戻し」です。「SaaSは機能過多で高い。AIを使えば自分たちで必要なシステムを安く作れるのではないか？」という発想です。 特徴： 汎用SaaSを使わず、自社DBの上にAI支援で独自アプリを構築します。コスト削減と業務への完全適合がメリットです。 課題： 「作った人しか直せない」という属人化リスクと、セキュリティや品質保証をすべて自社で担う重責が発生します。 欧州フィンテック大手Klarnaが有名な例です kigyolog.com 第2章：なぜ「SI」や「AI × BPO」だけでは届かないのか 上記の4つのアーキテクチャには、それぞれ一長一短があります。「あちらを立てればこちらが立たず」の状況です。 この課題を解決しようとする際、企業が次に検討するのは、 伝統的な「SI（システムインテグレーション）」か、あるいは近年台頭してきた「AI × BPO（AIを活用した業務委託）」 だと思います。しかし、エンタープライズの「ラストワンマイル」においては、これらもまた決定打になり得ない現実があるように思います。 SI（システムインテグレーション）の課題 ── 「要件定義」の壁 SIは「建物を建てる（＝システムを作る）」ことには長けています。しかし、SIモデルの前提は「要件が固まっていること」です。 「今の業務をそのままシステム化してください」と依頼しても、現場の業務は複雑怪奇なマクロや暗黙知で動いており、誰も正解を知りません。結果、要件定義に半年かかり、完成した頃にはビジネス環境が変わっている──。これが「ウォーターフォール型の限界」です。 AI × BPOの課題 ── 「ブラックボックス化」の壁 一方で、「AIを使って業務ごとアウトソースする（AI × BPO）」というアプローチも増えています。これは即効性がありますが、本質的には「人の作業をAIに置き換えただけ」です。 業務プロセス自体がブラックボックス化し、社内にデータ資産やノウハウが蓄積されません。また、AIが誤った判断（ハルシネーション）をした際、背後にあるデータ構造（オントロジー）が整備されていないため、原因究明が困難になります。 「SIのように外から作る」のでもなく、「BPOのように外に出す」のでもない。 既存のSaaS群も、SIも、BPOも解決しきれなかった「断絶」。これを埋めるために必要なのが、 「内側に入り込み、業務を回しながらシステムを進化させる」 という、第3のアプローチがでてきています。 第3章：現場を変える「専属シェフ」 ── Forward Deployed Engineer (FDE) そこで登場するのが、 FDE（Forward Deployed Engineer） という概念です。 彼らは「SIer」とも「BPOスタッフ」とも異なります。あえて言うなら、 「エンジニアリング能力を持った、現場専属の解決請負人」 です。「調整」ではなく「実装」で解決する。 SIerが「仕様書」を作る間に、FDEは「プロトタイプ」を作ります。 BPOが「マニュアル通り」に作業する間に、FDEは「マニュアルを不要にする自動化」を行います。彼らは顧客のオフィスの最前線（Forward）に入り込み（Deployed）、以下のように動きます。 APIがない？ → 「ならDBのダンプから直接データパイプラインを作ります」 現場のエクセルが複雑？ → 「そのロジックをPythonで解析し、システムに移植します」 SIのような「納品して終わり」ではなく、BPOのような「作業代行」でもない。 既存の冷蔵庫（レガシーシステム）にある食材（データ）を、その場で極上の料理（モダンな業務フロー）に調理して提供する「専属シェフ」。このアジャイルなアプローチは、全体最適の大改修ではなく“詰まりやすい部分”から小さく改善を重ねることで、エンタープライズの組織・プロセスの制約下でも変革を進めやすくします。 第4章：システムをつなぐ「万能翻訳機」 ── 中間システムとOntology FDEという高度人材が活躍するためには、彼らが振るう「包丁」となるシステム基盤が必要です。それが「中間システム」であり、その核となる「Ontology（オントロジー）」です。 「データ」に「意味」を与える (Ontology) 従来のデータベースは「行と列」の羅列に過ぎません。SIで開発するシステムや、AI × BPOで使うツールも、往々にして「その業務専用のデータ定義」になりがちです。 しかし、中間システムにおけるOntologyは、データそのものではなく「業務の実体（Concept）」を中心にデータを再定義します。 従来： Table_A.col_1 と Table_B.id を結合（人間が都度判断） Ontology： Customer has many Contracts（データ自体が意味を持つ） 現実世界の業務の関わり合い（コンテキスト）をそのままデータ構造として定義することで、システムは裏側の複雑なDB構造を知らなくても、「顧客の契約状況を教えて」と問うだけで正しいデータを引き出せるようになります。 異なる言語を翻訳する「万能翻訳機」 エンタープライズには、SAPやOracle、野良エクセルなど、異なる言語（プロトコル）で話すシステムが乱立しています。 ここに「 中間概念（データやシステム）」を配置することで、レガシーとモダンをつなぐ「万能翻訳機」 としての役割を果たさせます。 入力（レガシー）： 古いシステムからFDEがパイプラインでデータを吸い上げる。 処理（翻訳）： 吸い上げたデータをOntologyに基づいて「意味のある情報」に変換・統合する。 出力（モダン）： AIエージェントやSaaSが、整理されたデータにアクセスする。 この「中間概念(データやシステム)」が存在することで、企業は巨大な基幹システムをリプレイスすることなく（＝冷蔵庫を買い替えることなく）、最新のAI活用（＝プロの料理）を享受できるようになります。 第5章：AI時代の新しいアーキテクチャ ── 「自律的AI」への道 この 「FDE × 中間概念（Ontology）」 という構造は、これからのバックオフィスプロダクトにおいて、AIを活用するための必須条件となります。 AIが「働く」ための地図 生成AIやAIエージェントが実業務で機能するためには、コンテキスト（文脈）が必要です。単にマニュアルを学習させるだけでは不十分で、「今、この瞬間の会社の状態」を正確に把握していなければなりません。 中間システム上のOntologyは、まさに 「AIにとっての地図」になります。 「A社の請求書が遅れている」という事実だけでなく、「A社は重要顧客であり、過去に同様のケースでは担当者が電話でフォローしていた」という文脈をAIが理解できて初めて、AIは単なるツールを超え 、「自律的なエージェント」として機能します。 つまり、中間システムを構築することは、単なるデータ統合ではありません。 SIのように「箱」を作るのでもなく、BPOのように「人」で埋めるのでもなく、「企業そのものをデジタルツイン（デジタルの双子）化し、AIが自律的に働ける環境（ワークスペース）を整えること」なのです。 おわりに：バックオフィス・プロダクトの解像度を高める 「Fit to Standard」から「SaaS Unbundling」まで、企業のシステムは揺れ動いてきました。しかし、どの時代、どのアーキテクチャにおいても、「データをつなぎ、業務を流す」という本質的な課題は残されたままでした。 「専属シェフ（FDE）」と「万能翻訳機（中間システム）」のアプローチは、既存のSaaS群やSIモデルを否定するものではありません。むしろ、過去の遺産（レガシーデータ）と未来の技術（AI/SaaS）を、技術と泥臭さで接着する新しいアプローチなのではと思っています。 古い文字コードとの戦い、複雑怪奇な勘定科目のマッピング、例外だらけの承認フロー......。 そうした「泥臭い現実」を、高度な抽象化技術（Ontology）と実装力（FDE）で包み込み、ユーザーには「魔法のようなシンプルさ」として提供する。これこそが、この領域のプロダクトマネジメント、エンジニアリングの真の面白さであり、深淵なる魅力ではないでしょうか。 それを支える中間概念（Ontology）思考。 これらはまだ耳慣れない言葉かもしれませんが、数年後には企業のバックオフィス構造を支える、当たり前のインフラになっているかもしれないと感じています。 もし、こうした「複雑さを技術で解きほぐす」アプローチや、社会の基盤となるバックオフィスプロダクトの進化に興味を持っていただけたなら、ぜひこの広大なフィールドを一緒に探求していければと思います。 この記事を読んで、現在の場所を飛び出そうと思った方やラクスのプロダクト部に興味を持ってくださった デザイナー／PdM の方 は、ぜひカジュアル面談からご応募ください。※プロダクトマネージャーのカジュアル面談は、基本的に私（稲垣）が担当します！ ●採用情報 デザイナー career-recruit.rakus.co.jp   └ デザインマネージャー career-recruit.rakus.co.jp ／アシスタントマネージャー career-recruit.rakus.co.jp

日々、企業は根本的な課題に直面しています。SAPシステムには、サプライヤーとの関係、在庫レベル、財務取引、生産計画など、企業運営を推進するビジネスクリティカルなデータが含まれています。しかし、ワークフロー自動化のためにこのデータにアクセスするには、従来、複雑なカスタム統合、専門的なSAP知識、そして多大な開発時間が必要でした。SAPデータと非SAPデータの両方に依存するビジネスプロセスは、従来、これらのソースを統合するために膨大な開発者の労力を必要としていました。サプライチェーンマネージャーを含む事業部門チームはリアルタイムの混乱分析を必要とし、財務チームは請求書の自動例外処理を望み、調達スペシャリストは即座のサプライヤーリスク評価を必要としています。それでも、これらのビジネスニーズを自動化に変えることは複雑なままでした — しかしそれは過去の話です。 Amazon Quick SuiteのAWS Action Connectors for SAP 2025年10月、AWSは Amazon Quick Suite を発表しました。これは、従業員がインサイトの発見、詳細な調査の実施、タスクの自動化、データの可視化、アプリケーション全体でのアクション実行の方法を変革するのを支援する新しいエージェント型チームメイトです。Quick Suiteは、SAP、ServiceNow、PagerDuty、Asanaなどの人気のあるサードパーティアプリケーションと統合し、データを取り込み、ユーザーがQuick Suiteインターフェース内でタスクを作成し、チケットを開き、アクションを実行できるようにします。 このブログでは、Quick Suite内で利用可能なSAP用の組み込みコネクタと、お客様が Amazon Quick Automate を使用してこれらのコネクタを活用し、ビジネスオペレーションを合理化する強力な自動化を構築する方法について説明します。Quick Automateは、企業が大規模で回復力のある自動化を構築、展開、維持できるようにするQuick Suiteの機能です。AWS Action Connectors for SAPは、お客様がライブSAPデータに対してリアルタイムの読み取り操作を実行できるようにし、Quick AutomateがSAP S/4HANAなどのSAP ERPシステムとシームレスに対話できるようにします。さらに、これらのコネクタは、SAP API、認証、データ交換の技術的な複雑さを自動的に処理します。Quick Automateは、構造化されたワークフロー定義とプロセス定義ドキュメントを通じて、複雑なSAP統合をビジネスユーザーがアクセスできるようにすることで、エンタープライズ自動化を変革しています。カスタム開発を数か月待つ代わりに、お客様は数時間でAI駆動のSAP自動化を構築できるようになりました。 このリリースには、一般的なエンタープライズ自動化シナリオに対応するSAP S/4HANA用の5つのコネクタが含まれています。各コネクタは、特定のAPIエンドポイントをアクションとして提供し、正確なデータ取得(読み取り専用)とワークフロー自動化を可能にします: Business Partner: ベンダー分析とお客様の人口統計評価のための包括的なビジネスパートナー、サプライヤー、お客様データにアクセスします。 Product Master: 包括的な在庫管理のための重要な資材データ、プラント情報、供給計画の詳細を取得します。 Bill of Materials: 製品の依存関係と製造要件を理解するために、資材構造とコンポーネントの関係を照会します。 Physical Inventory Documents: 正確な照合プロセスと包括的な監査証跡の維持のために、在庫ドキュメントの転記と在庫移動にアクセスします。 Material Stock: 正確な可用性追跡と在庫最適化のために、場所別のリアルタイム在庫レベルと在庫ポジションを取得します。 詳細なAPI仕様については、各サービスエンドポイントに対応するSAP APIドキュメントを参照できます。自動化を構成する際は、リストされたアクション名を使用して、自動化シナリオが必要とする特定のデータセットにアクセスしてください。 GenpactがAmazon Quick Automateを使用してお客様に代わってサプライチェーンリスク評価を自動化した方法 Genpactは、深い業界知識、プロセスインテリジェンス、ラストマイルの専門知識で認められたエージェント型および先進技術ソリューション企業です。深い業界専門知識とビジネスプロセスの洞察力を持つ同社は、AWSと提携し、Quick Automate上にAI駆動のサプライチェーンレジリエンスソリューションを構築し、エンタープライズリスク管理を変革しました。このソリューションのインテリジェントで自動化されたサプライチェーン監視機能を備えることで、組織は複数のSAPモジュール全体で数分で混乱の影響を評価できます—これは、手動分析に通常必要な2〜3日から劇的な改善です。外部リスク監視システムがサプライチェーンの混乱を検出すると、自動化されたワークフローは、Business Partner Master、Product Master、Bill of Materials、Inventory Managementシステム全体でデータ収集を即座に調整し、ビジネスへの影響の優先順位を計算し、代替調達や関係者への通知などの適切な対応アクションをトリガーします。この画期的なソリューションは、リアルタイムのクロスシステム調整により24時間体制のサプライチェーン保護を提供し、GenpactをAI駆動のビジネスプロセス変革のリーダーとして位置付けています。 Quick AutomateとSAPコネクタを使用すると、自動化された応答プロセスの概要を示す構造化されたワークフローを直感的なユーザーインターフェースを通じて作成できます: 図1: Genpactによって実装されたサプライチェーン混乱対応プロセス この種の自動化されたデータ駆動型アプローチは、企業が回復力を維持し、問題が発生したときにより迅速に対応するのに役立ち、棚に商品を並べ、お客様を満足させ続けます。 SAPアクションは、フィルタリング基準や選択パラメータなどの追加パラメータを指定することでカスタマイズできます。構造化されたプロセスドキュメントを通じて定義されたこの複雑なワークフローは、数分で自動的に実行され、プロアクティブなサプライチェーンリスク管理を可能にします。 AWS Connectors for SAPの使用開始 Quick AutomateでAWS Action Connectors for SAPの使用を開始するには: Amazon Quick Suiteにアクセス: AWS Connectors for SAPは現在、Amazon Quick Suite Integrationsを介してすべてのお客様が利用できます。 接続のセットアップ: Quick Suiteコンソールを通じてSAPシステムへの安全な接続をセットアップし、コネクタで実行する必要なアクションを構成します。 アクションの検出: 接続のセットアップが成功すると、この統合の一部として有効化されたアクションのセットが表示されます。 自動化グループの作成: 次に、Quick Automate Projectsに移動し、Manage groupsをクリックして自動化グループをセットアップし、作成した統合を「Actions」としてオンボードします。 自動化の定義: 次に、自動化プロジェクトを作成し、ビジネスプロセスの概要を示すワークフロー仕様に作成した自動化グループを追加し、適切なSAPコネクタを活用します。 テストと改善: 展開前に生成された自動化をレビュー、テスト、変更します。 展開と監視: 自動化を実行し、Studio経由でパフォーマンスを監視します。 AWS Action Connectors for SAPは、エンタープライズセキュリティ要件を念頭に置いて構築されています: 安全な認証: 現在利用可能な基本認証のサポートと、まもなく利用可能になるOAuthのサポート。 データプライバシー: SAP内で管理されるデータガバナンスと承認(ユーザーとロール)。 これらのコネクタのセットアップに関する詳細なガイダンスについては、 AWSドキュメント を参照してください。今日からAmazon Quick Suiteの使用を開始するには、 スタートガイドページ にアクセスしてください。 SAP on AWSディスカッションに参加 AWSアカウントチームとサポートチャネルに加えて、最近 re:Post を立ち上げました—AWSコミュニティのための再構築されたQ&A体験です。AWS for SAP Solution Architectureチームは、お客様とパートナーを支援するために回答できるディスカッションや質問について、AWS for SAPトピックを定期的に監視しています。質問がサポート関連でない場合は、re:Postでのディスカッションに参加し、コミュニティナレッジベースに追加することを検討してください。SAPワークロードをAWSに移行する方法の詳細については、 SAP on AWS ページをご覧ください。 謝辞 Amazon Quick Suiteを活用したSAPサプライチェーン向けエージェントAIソリューションを構築するためのAWSとGenpactの戦略的コラボレーションは、お客様がインテリジェントな自動化を通じてサプライチェーンオペレーションを最適化するのに役立ちます。この変革的なパートナーシップを築く上で基本となった専門知識、ビジョン、協力的な精神を持つGenpactリーダーシップ、AWS GenAIスペシャリスト、および拡張AWSサービスチームに感謝の意を表します。 Shriram Bidkar – Associate Vice President, AWS Solutions James Avellone – Director, Sourcing and Procurement Advisory Perryn Stewart – Vice President, Supply Chain Management Reagan Rosario – WWSO Specialist SA- GenAI, AWS Naresh Rajaram – Partner Solution Architect, AWS 著者について Rengarajan Sridharanは、AWS EC2 Commercial Applicationsのシニアテクニカルプログラムマネージャーで、SAPおよびVMwareワークロードに焦点を当てたプログラムを推進しています。エンタープライズリソースプランニング(ERP)ソリューションで20年以上の経験を持つRengaは、お客様がビジネス価値とデジタルトランスフォーメーションの成果を最大化するためにエンタープライズシステムをモダナイゼーションするのを支援することを専門としています。 Apoorva Chandraは、AWSのEC2 SAP Engineeringチームのシニアプロダクトマネージャー – テクニカルで、AWS上でワークロードを実行するSAPエンタープライズのお客様向けのモダナイゼーションとエコシステムイニシアチブをリードしています。彼女の焦点は、お客様がSAPランドスケープを強化するために生成AIと分析サービスの可能性を最大限に引き出すのを支援することです。 Shriram Bidkarは、Genpactのアシスタントバイスプレジデントで、戦略的能力と運用効率を向上させるサプライチェーン変革のためのAWS駆動のエージェントAIソリューションを専門としています。25年以上の経験を持つ彼は、Genpactのお客様に測定可能なビジネス成果をもたらすクラウド移行、モダナイゼーション、AI自動化イニシアチブを推進しています。 James Avelloneは、Genpactの調達およびプロキュアメントアドバイザリープラクティスのディレクターで、クライアントと協力して戦略的能力と運用効率を向上させるサプライチェーン変革を開発および実行しています。業界で15年以上の経験を持つJamesは、ターゲットオペレーティングモデルの設計、データ分析、テクノロジー実装の経験を持つ調達およびソーシングスペシャリストです。 本ブログはAmazon Q Developer CLIによる機械翻訳を行い、パートナーSA松本がレビューしました。原文は こちら です。