こんにちは。AWS プロフェッショナルサービスの Spatial Computing (空間コンピューティング) 領域の担当チームです。普段主に企業様向けのゲーム、シミュレーション、トレーニング等の用途で利用する 3D 空間の AWS 上への導入・企画支援を行っています。 AWS Summit Japan 2026 の AWS Village にて展示ブースを出展予定です。本ブログではそちらの展示内容をご紹介します。 AWS Summit Japan 2026 登録はこちら ブース A160：SDMA で繋ぐ現実世界とAIシミュレーション Physical AIを支える3Dアセット管理基盤を体験 SDMA (Spatial Data Management on AWS) から取得した 3D パーツで障害物コースを自動生成し、仮想ロボットが AI で走り方を学ぶ様子をリアルタイムで体験できます。大量のロボットが同時に試行錯誤する学習の様子や、学習済み AI の自律走行の体験など、シミュレーションからロボット制御へつなぐ AI 開発の流れを体感いただけます。 こんな方におすすめ 来場者像 ブースで得られること ロボットエンジニア   ロボットモデルの学習向けシミュレーション環境の効率的な構築方法 デジタルツイン推進担当   デジタルツイン環境の構築と AI シミュレーションへの活用例 展示内容 以下の 2 つの AI ロボットデバイスを題材にしたデモをご紹介します。 自律走行車両 自律飛行ドローン 各デバイスは仮想空間上に構築されたシミュレーション環境で強化学習が行われています。本デモでは、その仕組みを説明しながら、Spatial Data Management on AWS (SDMA) を活用したシミュレーション環境の効率的な構築・管理方法についてご紹介します。 補足 : Spatial Data Management on AWS (SDMA) とは Spatial Data Management on AWS (SDMA) は、2025 年 12 月にリリースされた、3D アセットなどの空間データ (Spatial Data) 管理基盤を構成するための AWS ソリューションです。OBJ、GLB、USD、PLY といった空間を表現する多様なフォーマットのデータを AWS のベストプラクティス構成で一元管理でき、AWS サービスとシームレスに連携したパイプライン実行が可能です。 下の図が SDMA のアーキテクチャ図です。公式サイトで提供されている CloudFormation ベースのテンプレートから AWS サービス群をデプロイできます。他の AWS サービスとの違いとして、専用のデスクトップアプリケーションが用意されており、PC から簡単な操作でAWS 上に構成されたデータ管理基盤にアクセス可能です。 デモ 1. 自律走行車両 概要 障害物が散在する不整地環境を、AI が自律的にゴールまで走行するデモです。Aalborg 大学が開発したオープンソースの強化学習フレームワーク  RLRoverLab をベースに構築しています。 強化学習の仕組み 車両は強化学習により、障害物を避けながらゴールに到達するポリシー（状況に応じた自律的な行動の決定ルール）を獲得しています。NVIDIA の Isaac Sim を活用し、報酬を設定した上でパラメータを変化させながら、数百の車両が同時並列で強化学習を行います。 学習に関係する要素 説明 観測空間   車両周囲の地形の凹凸（LiDAR スキャン）、ゴールまでの方向と距離 行動空間   車両の側面についている 6 つの車輪の操舵角および角速度 報酬設計   ゴールに近づくほど高評価、到達でボーナス（加点）、障害物に衝突するとペナルティ（減点） シミュレーション環境の構成 車両が走行するシミュレーション環境は、 地面 と  障害物 の 2 つの要素で構成されています。地面は起伏のある 3D 地形、障害物は 3D モデルで作成された岩で、地面に無数に配置されています。 SDMA によるシミュレーション環境の自動生成 本デモでは、地面と障害物の組み合わせを変化させ、別のパターンのシミュレーション環境を構築します。地面と障害物に対応する画像から 3D データを生成するパイプラインを構築し、SDMA 経由で実行させる例をご紹介します。 SDMA のデスクトップアプリを使用し、地面と障害物に対応する画像をそれぞれ SDMA にアップロードします。 すると、事前定義した AWS Step Functions のワークフローが自動実行されます。 地面の画像から 3D Gaussian Splatting（写真や動画から高精細な 3D 空間を構築する技術 / 点群データで構成され、3次元ガウシアン分布で広がりのあるデータを持つ）形式で 3D 地形点群データを生成する（Image to 3DGS API を利用 – 例：Marble） 障害物の画像から 3D メッシュモデルを生成する（Image to 3D API を利用 – 例：Meshy AI） 生成した 3D 地形点群データから物理判定用のコリジョンメッシュ（車両が重力下の地面を走行し凹凸を認識するために必要）を生成する  3D 地形点群データとコリジョンメッシュを重ね、その表面に障害物の 3D メッシュモデルをランダムに配置し、シーンデータとして合成（USD 形式）した上で、 SDMA に登録する その後、EC2 インスタンス上から SDMA を経由して生成されたシーンデータがダウンロードされ利用されます。 新しいシミュレーション環境の利用 生成した新しいシミュレーション環境上で、学習済みモデルが自律走行する様子を確認できます。地形と障害物が異なる環境でどのように走行するかを見ることで、汎化性能（学習時と異なる環境でも適切に動作する能力）を評価できます。必要に応じて、そのシミュレーション環境で追加学習を行うことも可能です。 デモ 2. 自律飛行ドローン 概要 複数のゲート（通過ポイント）で構成されたコースを、AI ドローンが飛行しながらゲートを順番に通過するレースデモです。オープンソースの  isaac_drone_racer  をベースに構築しています。来場者はコントローラーでドローンを操縦し、AI とレースで対決できます。 強化学習の仕組み ドローンは強化学習により、ゲートを順番に通過しながらコースを完走するポリシー（状況に応じた行動の決定ルール）を獲得しています。最大 4096 機が並列にシミュレーションされ、大量の試行錯誤を短時間で行うことで高速に学習が進みます。 学習に関係する要素 説明 観測空間   機体の速度・角速度・姿勢、次ゲートへの相対位置・方向 行動空間   4 つのプロペラを駆動する各ローターの角速度（＝推力） 報酬設計   ゲート通過で加点、ゲートへの接近・後退で進捗評価、衝突・コース逸脱で減点 シミュレーション環境の構成 ドローンが飛行するシミュレーション環境は、 ゲート と 障害物 の 2 つの要素で構成されます。ゲートはコースの経路を定義する通過ポイントで、障害物はゲート間の飛行経路上に配置されることで回避行動を要求します。 SDMA による障害物の配置 障害物の 3D モデルは SDMA で管理されています。SDMA のデスクトップアプリから障害物に対応した 3D モデル（GLB 形式）をアップロードすると、AWS Lambda によるフォーマット変換（GLB → USD：NVIDIA Isaac Sim で利用される3Dフォーマット）が自動実行されます。 変換された 3D モデルは、ブラウザ上の Web UI から SDMA 経由でダウンロードできるようになり、シミュレーション環境上での障害物の種類や配置を自由にカスタマイズできるようになります。 新しいシミュレーション環境の利用 カスタマイズした新しいシミュレーション環境上で、学習済みのモデルでドローンがどのように飛行するかを確認できます。ゲート配置や障害物の有無の影響を見ながら、AI の汎化性能を評価することができます。必要に応じて、そのコースで追加学習を行うことも可能です。 システムアーキテクチャ 利用している AWS サービス・ソリューション Amazon EC2 — GPU計算基盤 Spatial Data Management on AWS — 3Dアセットの管理・検索・配信基盤ソリューション Amazon API Gateway + AWS Lambda — バックエンド API Amazon S3 — 3D アセットデータストア Amazon DynamoDB — メタデータストア Amazon EventBridge — 3D アセット操作イベント通知 AWS Step Functions — ワークフローオーケストレーション Amazon Cognito — 認証・認可 その他技術要素 Amazon DCV — EC2 上でのシミュレーションツールのリモートデスクトップ配信 NVIDIA Isaac Sim + NVIDIA Isaac Lab — 物理シミュレーション・強化学習の実行環境 活用ユースケース 本デモで紹介した 3D のシミュレーション環境の構築パイプラインは、以下のようなユースケースでの活用が考えられます。 分野 ユースケース 物流・倉庫   AGV/AMR におけるパスプランニング、レイアウト変更時の再学習 建設・インフラ   ドローン点検の飛行経路最適化、現場 3D スキャンデータの活用 製造   工場フロアでの自律搬送ロボット導入シミュレーション エンターテインメント・スポーツ   カメラドローン自律飛行、スタジアム運営シミュレーション ブース情報 ブース ID   A160 エリア   AWS Village（AWS Expo エリア内） 日程   2026 年 6 月 25 日 (木)・26 日 (金) 会場   幕張メッセ まとめ AWS Summit Japan 2026 の AWS Village（ ブース A160 ）にて、2026年6月25日（水）・26日（木）の両日展示します。 デモを通して AI シミュレーションの概要をご覧いただきながら、AWS を活用したシミュレーション環境構築をお気軽にお立ち寄りください。 AWS Summit Japan 2026 公式サイト

みなさんこんにちは。ソリューションアーキテクトの山田です。2026 年 6 月 25 日(木)、26 日(金)の 2 日間に渡って開催される AWS Summit Japan 2026 では今年も製造業に関する展示を数多く行なわれています。製造業に関連する全体的な展示やセッションに関しては こちらのブログ に全体がまとめられておりますので参照ください。 本ブログではその中でも製品設計開発に関するデモ展示について紹介します。 コンセプト : 生成 AI 時代の製品設計開発 CAE 解析や CAD 操作、過去ナレッジの活用など、製品設計開発の現場にはエンジニアの専門性に強く依存する業務が数多く存在します。本展示では、フィジカル AI 時代の到来を見据え、エンジニアの設計開発を加速する 2 つの切り口で実機デモをご覧いただきます。 1. Engineering Development Hub（ EDH ）による PC / Workstation / HPC 環境の俊敏な立ち上げ 2. 設計開発の現場ですぐに実践できる生成 AI ユースケース 「フィジカル AI 時代の研究開発をどう加速するか」を、現場のエンジニア目線で体感いただける展示です。 1. Engineering Development Hub（ EDH ) EDH は 専用 Web ポータルによって設計開発に従事する方が使用する PC / Workstation / HPC 環境をクラウド上にセルフサービスで立ち上げることができるシステムです。3D モデリング、大規模シミュレーション、 CAE 解析、 GPU を用いたモデル作成に至るまで、フィジカル AI 時代の研究開発においてはこれまで以上に多彩なツールチェーンと、それを効率よく実行する多種多様なコンピューティング環境が必要となります。EDH はクラウドの柔軟性を活かした多様な要件に対応できる仮想ワークステーション環境とスケーラブルな HPC 基盤を 1 つのシステムとして提供。専用の Web ポータルによりエンジニアは直感的に必要なデスクトップ環境を取り出し、大規模に CPU/GPU を使用した分散学習やシミュレーションを実行することができます。 EDH は以前 Scale-Out Computing on AWS（SOCA）として知られていたソリューションの後継で、2026 年 4 月にリブランドされ、新たにリリースされました。SOCAの派生としては RES (Research and Engineering Studio on AWS) もリリースされておりますが、RESはVDIに特化したソリューションです。VDIに加えてHPCの機能も統合して利用したい場合は今回ご紹介するEDHの利用をご検討ください。 Engineering and Development Hub (EDH) アーキテクチャ図 EDH の主な特徴 仮想デスクトップによるインタラクティブ処理 Amazon DCV を用いた高性能なリモートデスクトップ環境で、CAD ソフトウェアの 3D 描画もスムーズに操作できます。Windows と Linux の両方に対応し、GPU インスタンスを選択することで、>オフィスにいなくてもワークステーション級の作業環境にアクセスできます。 HPC を使った大規模バッチ処理 Slurm、OpenPBS、IBM LSF といった主要なジョブスケジューラに対応し、ジョブ投入に応じて計算ノードが自動的にスケールアウトします。EFA（Elastic Fabric Adapter）による低遅延ネットワークで、大規模並列処理のスケーリングも問題ありません。処理が完了すればノードは自動的に終了し、課金が停止します。  専用 Web インタフェースによる直感的な利用 EDH には専用の Web ポータルが付属しており、以下のような操作をブラウザから直感的に行えます。コマンドラインに不慣れなエンジニアでも、すぐに使い始められるのが特徴です。 仮想デスクトップの起動・停止 HPC ジョブの投入・状態監視 ファイルの管理とアップロード 利用状況の可視化とコスト確認 Amazon EC2 の高い汎用性 EDH の計算リソースは Amazon EC2 上に展開されるため、実行するアプリケーションや処理の規模に合わせて最適なスペックのインスタンスを選択できます。 CPU：x86（Intel / AMD）、Arm（Graviton） GPU：NVIDIA L4、A10G、A100、H100 etc. メモリ：数 GB から数 TB まで OS：Amazon Linux、RHEL、Ubuntu、Windows Server etc. EDH の仮想デスクトップ管理画面と HPC ジョブ投入画面 EDH のユースケース EDH は以下のような設計開発ワークロードで活用することができます。もちろんこれら以外にも仮想デスクトップや HPC 環境を必要とするワークロード全般に適用可能であり、汎用性の高いソリューションです。 CAD：3D モデリング、設計・製図 CAE：構造解析、流体解析、熱解析 材料シミュレーション：分子動力学、第一原理計算 EDA：半導体設計、論理合成、検証 フィジカル AI：ロボティクス開発、強化学習 EDH のリソース他 Engineering Development Hub（EDH）はオープンソースで公開されているため、すぐに試すことができます。 ソースコード: github.com/awslabs/engineering-development-hub ドキュメント: awslabs.github.io/engineering-development-hub-documentation AWS Summit Japan 2026 会場内の AWS for Industries Zone ブース (ブース ID：A021) で、EDH の実環境をご覧いただけます。ぜひ実際のデモをご覧ください。 2. 設計開発の現場ですぐに実践できる生成 AI ユースケース 自然言語による CAD/CAE 操作のアシストや、時間のかかるシミュレーションを AI で高速化するサロゲートモデルなど、明日からでも取り入れられる「使える AI」の活用例をご紹介します。 その場でご覧いただける動作デモに加え、後日体験できるワークショップもご用意しているので、AI が設計業務をどう変えるのかをじっくり実感いただけます。 生成 AI × CAD + CAE + NVIDIA Isaac による フィジカル AI シミュレーション 本デモでは、AWS の AI コーディングアシスタント Kiro に 自然言語で指示するだけ で、1 台の産業用 6 軸ロボットアームを題材に、 設計 → CAD 編集 → 強度解析（CAE） → ロボットの動作学習 までを一気通貫で実行する様子をご覧いただけます。 フィジカル AI 時代に求められる「設計してから、実際に動かして学習させるまで」の流れを、コードを 1 行も書かずに体感できる展示です。 設計開発の現場に多く存在する、専用ソフトの習熟や、複雑な製図・シミュレーションといった時間を要する業務を効率化する効果が期待できます。 注記：Kiro CLI の基盤モデルは検証を進めた期間中にアップデートが重なったため、工程ごとに Claude Opus 4.6 / 4.7 / 4.8 を使用しています（どの工程でどのバージョンを使ったかは、後述の詳細記事シリーズにそれぞれ明記しています）。 本デモ動画の撮影時点では Claude Opus 4.8 を使用しました。モデルのバージョンによって、生成されるコードの品質や挙動は変わる場合があります。 デモの流れ — 1 台のロボットアームを 4 ステップで設計 同じ 1 つの形状データを引き継ぎながら、すべての工程を Kiro への日本語の指示だけで進めます。 AWS Summit Japan 2026 展示動画（YouTube : 3分58秒） 1. 3D 形状をつくる 寸法を言葉で伝えるだけで、ロボットアームの 3D モデルを生成します。CAD ソフトを使わず Python だけで STL ファイル（※3D 形状のデータを見るのに向いた形式）を作り、関節角度から先端位置を求める順運動学（※各関節を何度曲げると腕の先端がどこに来るかを求めるロボット設計の基本計算）の検算まで Kiro が自動で実施。このモデリングを実時間 4 分 28 秒で完了しました。 技術詳細解説ブログ Kiro で AI 支援の設計開発 -自然言語指示だけで 3D モデリングや流体シミュレーション実行- プロンプト例： 産業用6軸多関節ロボットアームの3Dモデルを生成する generate_robot_arm.py という Pythonスクリプトを構築してください。 numpy-stl、numpy、matplotlib のみを使用してください。 ■ ロボットアーム構成（ベースから先端へ）： 1. ベース（J1軸: 旋回） — 固定台座: 円筒 直径300mm 高さ50mm、旋回部: 円筒 直径250mm 高さ100mm 2. ショルダー（J2軸: 前後傾動） — 関節ハウジング: 直径200mm 高さ150mm 3. 上腕（リンク1） — 長さ500mm、断面: 150mm x 120mm 4. エルボー（J3軸: 上下傾動） — 関節ハウジング: 直径160mm 高さ120mm 5. 前腕（リンク2） — 長さ450mm、断面: 120mm x 100mm 6. 手首（J4/J5/J6軸） — 3段の円筒 7. エンドエフェクタ（ツールフランジ） — 直径63mm（ISO 9409-1準拠）、ボルト穴6個 ■ 姿勢パラメータ： - J1〜J6の関節角度を変数化し、順運動学（FK）で各リンクの位置・姿勢を計算 Kiro が 3D モデリング用のコードを作成し実行している様子 完成したロボットアーム 3D モデル STL ファイル 2. 形を編集する CAD で編集できる STEP ファイル（※3D 形状の CAD ソフトで編集するのに向いた形式）に作り直し、オープンソースの 3D CAD ソフト FreeCAD で、角の丸め（フィレット）や穴あけといった加工を追加します。GUI 操作だけでなく、Kiro が FreeCAD Python API を用いてヘッドレス（GUI なし、コマンドラインとスクリプトだけ）でも編集を実行できることを示します。 技術詳細解説ブログ CADソフトの操作を自然言語指示でAIに任せる — Kiro で STEP 生成から FreeCAD 編集まで Kiro が作成したロボットアーム図面をベースに、FreeCAD で人間が編集操作を行っている様子 Kiro が自然言語指示によりヘッドレスでロボットアーム図面編集操作を行った結果（編集前後比較） 3. 強度を確かめる 完成した形に荷重をかけ、応力やたわみを計算する構造解析（CAE）を実行します。今回は材料をアルミ合金 6061-T6、ベース底面を固定し、先端のフランジに 100 N（約 10 kg 相当）の下向き荷重をかける条件で解析しました。部品の結合からメッシュ分割、材料・拘束・荷重の設定、ソルバー実行、結果の可視化までを Kiro が担当し、最大応力（フォン・ミーゼス応力）約 0.13 MPa・最大変位は 5.76 μm という結果を得ています。途中でエラーが出れば自ら原因を切り分け、手法を見直しながら解析を完走させます。 技術詳細解説ブログ AI が設計して、AI が強度検証する — Kiro × FreeCAD FEM でロボットアームCAE構造解析 Kiro が FreeCAD で CAE 実行した結果を人間が GUI で確認している様子 4. 動かして学ばせる 設計したアームに吸盤を付け、NVIDIA Isaac Sim / Isaac Lab 上で「キューブを持ち上げて運ぶ」動作を強化学習（※ロボットに動きを試行錯誤させ、うまくいくほど報酬を与えて自分で上達させる AI の学習方法）させます。4096 体のロボットを 1 枚の GPU で同時に動かし、学習開始直後はほぼ 0% だった成功率を、学習後にはピックアップ（持ち上げ）成功率 91.5%、目標位置への運搬・保持も 77.9% まで引き上げました。 技術詳細解説ブログ AI で設計した自作ロボット、NVIDIA Isaac で 4096 並列強化学習させた結果 4096 体のロボットを NVIDIA Isaac Sim / Isaac Lab 上でキューブピックアップ強化学習している様子 AIを活用した設計開発のポイント つくりたいものを、言葉にするだけ 専用ソフトの習熟や環境構築も AI が肩代わり。設計の参入障壁が下がる。 時間がかかる作業が、速く・再現性高く 日々の製図も解析も手間を大幅削減。初期検討を素早く回せる。 未知の領域にも、踏み込める 強化学習のような未経験分野も AI が調べて試す。学びながら新スキルが身につく。 仕上げと判断は、人 本番品質には専門家の判断と検証が要る。AI は作業役、決めるのは人。 著者について 山田 航司 (Koji Yamada) AWS のソリューションアーキテクトとして、製造業のお客様を中心にクラウド活用の支援を行っています。製造業における業務課題解決や新規ビジネスにおけるクラウド活用の可能性をお客様と一緒に探求しています。

はじめに 建設業界における BIM（Building Information Modeling）の導入は着実に進んでいます。BIM は建物の 3D 形状に加えて、各部材の寸法・材料・性能といった属性情報を一元的に持つ、いわば「建物のデータベース」とも言える存在です。しかし、その豊富なデータは、後述するいくつかの理由から、十分に活用されていない、という声もよく耳にします。 こうしたなか、BIM データ活用に向けた一つのアプローチとして注目されているのが生成 AI です。近年の生成 AI の発展により、「自然言語で BIM データを読み書きする」「AI エージェントが建物データを解釈して次のアクションに繋げる」といった使い方が現実的になりつつあります。本ブログでは、AWS Summit Japan 2025 の建設・不動産ブースで展示した IFC Viewer with GraphRAG を題材に、IFC ファイルをグラフに変換してグラフデータベースに格納し、生成 AI エージェントが情報を問い合わせる仕組みを、実装レベルで解説します。 なお本ブログは、1〜2 章で「なぜこの構成にしたのか」というアプローチと設計の考え方を、3 章で「どう実装したか」という詳細を扱い、4 章で発展的な拡張に触れる構成です。3 章以降は RDF グラフのモデリングや AI アプリの実装に踏み込む内容のため、グラフデータベースや生成 AI の開発経験があると読み進めやすくなりますが、各節の冒頭に要約を置いているため、詳細を読まなくても全体の流れは追えるようになっています。 1. BIM データを AI から扱うアプローチ BIM が普及するにつれ、3D 形状と属性情報を一元的に持つ「建物のデジタルデータ」が、案件ごとに蓄積されるようになりました。生成 AI を活用することで、こうしたデータに自然言語で問い合わせたり、AI エージェントに解釈させて次の作業へ繋げたりといった応用に繋げることができます。 その入口としてまず候補になるのが、各種 BIM プラットフォームが提供する REST API を、AI エージェントの Tool、あるいは MCP（Model Context Protocol）サーバー経由で渡す方法です。BIM データに API 経由でアクセスできるサービスは増えており、データを別の形式に変換したり外部に書き出したりせず、プラットフォームに置いたまま AI から参照できます。導入の手間が小さく、認証認可の仕組みや、ビューワーまで BIM プラットフォームで完結する利点があります。半面、取得できるデータやロジックは、ベンダーが提供する API の範囲に縛られます。API が想定していない切り口での集計や、他システムのデータとの突き合わせといった使い方には対応しにくいという制約があります。 （補足: MCP はアプリケーションが AI にツールやデータソースを提供するための共通プロトコルで、対応していれば異なる AI クライアントから同じツールを使えます） オープンフォーマットな BIM (IFC) を起点にする 特定ベンダーの API 範囲に縛られたくない場合、業界標準のオープンフォーマットである IFC（Industry Foundation Classes） を起点にする方法があります。IFC は、建設分野のオープンな BIM 標準を策定する、国際的な非営利団体である buildingSMART が定めた国際標準フォーマットで、特定ベンダーの製品に依存せず建物データを表現・交換できます。主要な BIM ツールは IFC のエクスポートに対応しているため、特定の製品で作成した BIM モデルであっても IFC 形式に変換できます。 ただし、IFC は AI がそのまま解釈できる形式にはなっていません。IFC は STEP 物理ファイル形式というテキスト形式で、中身は次のように、エンティティを #1234= のような ID 番号で繋いだフラットな構造になっています。 #129= IFCBUILDING('0w984V0GL6yR4z75XVLWOr',#41,'',$,$,#32,$,'',.ELEMENT.,$,$,#125); #138= IFCBUILDINGSTOREY('0w984V0GL6yR4z75YWgVfX',#41,'Nivel 1',$,'Nivel:Nivel 1',#136,$,'Nivel 1',.ELEMENT.,0.); #186= IFCWALLSTANDARDCASE('2idC0G3ezCdhA9WVjWemc$',#41,'Muro básico:Partición con capa de yeso:163541',...,#155,#182,'163541'); #6723= IFCWINDOW('2idC0G3ezCdhA9WVjWe$OB',#41,'Ventana simple:100 x 100 cm:164193',...,#25036,#6717,'164193',2.3,1.); 壁 ( #186 ) が所属する階 ( #138 ) は #136 経由でたどり、窓 ( #6723 ) が埋まっている壁は IFCRELVOIDSELEMENT / IFCRELFILLSELEMENT を介して参照する、といった具合です。エンティティの量（上記は数万行のうちの一部です）も相応にあり、AI にこの生テキストを渡してそのまま解釈させるのは現実的ではありません。 この IFC を扱いやすくするアプローチが、大きく 2 つあります。1 つは IFC を解釈できるライブラリを使ってその場で読む方法（A）、もう 1 つは IFC を別のデータモデルに変換し、データベースに格納してから問い合わせる方法（B）です。 (A) IFC を扱えるライブラリを AI のツールとして渡す 1 つ目は、IFC を扱えるオープンソースソフトウェア（OSS）を Tool として渡し、エージェントに探索させる方法です。代表的な OSS が IfcOpenShell で、先ほどのような生の STEP テキストを直接たどる必要はありません。 by_type("IfcWall") で壁を一覧したり、 #136 のような番号ではなく wall.Name のように属性名でアクセスしたり、ある要素を参照している関連要素を逆向きにたどったりと、IFC の構造を扱いやすい形で読み取ることができます。先ほど挙げたフラットさや参照の複雑さの多くは、こうしたライブラリが吸収します。 一方で、このアプローチには考慮すべき点もあります。問い合わせのたびに IFC ファイルを読み込んで探索する形になるため、エージェントにライブラリの API を組み合わせて目的の情報までたどらせると、問い合わせの内容によっては探索の手数が読みにくく、応答時間も安定しません。また、複数の建物をまたいだ横断検索や、大量要素の集計のように「あらかじめ整理されたデータ」を前提とする用途とは相性がよくありません。1 ファイルを対象とした素朴な参照には手軽で有効である一方、規模や横断性が増すほど追加の工夫を要する、という位置づけです。 (B) IFC を構造化してデータベースに格納し、AI が問い合わせる 2 つ目は、IFC を一度解釈し、用途に合わせたスキーマでデータベースに格納してから、エージェントには「データベースを問い合わせる Tool」を渡す方法です。問い合わせのたびにファイルを探索する代わりに、あらかじめ整理した状態を用意しておく、という発想です。 データの構造を案件・用途に合わせて設計できるので、カスタマイズの自由度が最も高くなります。複数ファイルをまたいだ横断検索や集計を書きやすい形に整えたり、他システムのデータと突き合わせやすいスキーマにしたりと、(A) では難しかった用途にも対応できます。半面、変換パイプラインとデータベースの両方を用意・運用する必要があり、導入コストは最も高くなります。 本ブログで扱うアプローチ ベンダー API（最初に触れた方法）、ライブラリでの直接探索（A）、データベースへの構造化（B）と、後ろにいくほど構築の手間は増えますが、その分、任意の構造でデータを格納でき、検索・集計・横断分析の自由度が高くなります。本ブログでは、この (B) のアプローチを採用した実装例を取り上げます。次の章では、データベースとして何を選び、どう組み立てたかを見ていきます。 2. IFC をグラフに変換して、グラフデータベースに格納する 採用したアプローチを一言でまとめると、「IFC をグラフ (RDF グラフ) に変換してグラフデータベース (Amazon Neptune Serverless) に格納し、AI エージェントがクエリ言語 (SPARQL) で問い合わせる」というものです。 (B) のデータモデルとして RDF グラフを選んだ理由は、BIM データの性質にあります。BIM データは「壁が窓を含む」「階が要素を持つ」といった、モノ同士の関係の集まりで、構造的にはグラフそのものです。また、検索する際も、関係をいくつもたどっていく問い合わせが中心になります。こうした「関係をたどる」処理は、テーブルを JOIN し続けるリレーショナルデータベースよりも、関係をそのままエッジとして持つグラフデータベースのほうが素直に記述できます。 RDF（Resource Description Framework）についても簡単に補足します。RDF は、あらゆる事実を「主語 – 述語 – 目的語」の 3 つ組（トリプル）で表す W3C 標準のデータモデルです。たとえば「Wall_001 は Window_002 を含む」という事実は、 Wall_001 - hasSubElement - Window_002 というトリプルで表せます。これを大量に集めると、ノード（モノ）とエッジ（関係）からなるグラフになります。 グラフの表現方法は他にもありますが、今回 RDF を選んだのは、既存の資産をそのまま活かせるためです。建設業界で広く使われている IFC を Linked Building Data（LBD）系のオントロジーで RDF 化する考え方や OSS が整備されており、さらに Amazon Neptune がマネージドサービスとして RDF / SPARQL をサポートしています。これにより、変換パイプラインとデータベース運用のいずれも、ゼロから構築する必要がありません。 アーキテクチャ 全体のアーキテクチャは以下の通りです。 処理の流れは大きく 2 系統に分かれます。 (1) 取り込み系: IFC → RDF グラフ → Neptune へのロード ユーザーが IFC ファイルを Amazon S3 にアップロード S3 イベントを Amazon EventBridge で受け、AWS Batch で変換用コンテナを起動 コンテナ内で IFC → Turtle 変換ツールを実行し、IFC を Turtle 形式（RDF を表現するテキスト形式の 1 つ）のファイルに変換して S3 へ書き戻す Turtle ファイルの S3 PUT イベントが AWS Lambda を起動し、Amazon Neptune の bulk loader API でグラフをロード 同じ Lambda が、後段の問い合わせで使うメタデータを Turtle から抽出して Amazon DynamoDB に保存 (2) 問い合わせ系: ユーザーの質問 → SPARQL → 自然言語回答 ユーザーがフロントエンドから自然言語の建物に関する質問を投げる Amazon API Gateway を経由して、エージェント実装の Lambda を起動 Lambda は対象 IFC のメタデータを DynamoDB から読み出し、Amazon Bedrock（Anthropic Claude）で SPARQL クエリを生成 生成した SPARQL を Neptune 上で実行し、結果を Bedrock で自然言語に整形してユーザーに返す 中間結果と最終回答は AWS AppSync Events で配信し、フロントの 3D ビューワー上で対象オブジェクトをハイライト なお、ここで出てきた「Turtle（タートル）」は RDF を表現するファイル形式の 1 つで、人間が読み書きしやすいように設計された構文です。次章で実例を載せます。 3. 主要コンポーネントの実装 ここからは実装の中身に入ります。(B) のアプローチで実装上のポイントになるのは、「IFC をどんな形の RDF グラフにするか」と「AI にどう SPARQL を書かせるか」の 2 点です。この章では RDF グラフのモデリングや AI アプリの実装に踏み込むため、グラフデータベースや生成 AI の開発経験があると読み進めやすい内容です。各節の冒頭に要約を置いているので、詳細を飛ばしても流れは追えるようにしています。 3.1 IFC を RDF グラフに変換する 要約 : IFC を RDF に変換すると、「建物 → 階 → 要素」という階層構造が、そのままグラフのノードとエッジになります。リレーショナルデータベースのような JOIN なしで関係をたどれるので、後段の問い合わせが書きやすくなります。 本ブログで紹介するソリューションでは、IFC からの RDF 変換に IFCtoLBD という OSS を使用しています。これは、IFC ファイルを、グラフとして扱いやすい RDF（Turtle 形式）に変換してくれるツールです。変換後のデータは、Linked Building Data（LBD）で整備されている公開オントロジー（建物データの語彙を定めたもの。建物トポロジーを表す BOT など）に沿った形になります。本実装では、この変換作業を AWS Batch のコンテナで実行しています。 変換後の Turtle は、たとえば次のようになります（1 章で示した IFC と同じ建物の変換結果からの抜粋です）。 @prefix bot: <https://w3id.org/bot#> . @prefix props: <http://lbd.arch.rwth-aachen.de/props#> . @prefix inst: <https://lbd.example.com/> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . # 建物（Building）— 配下に階が 2 つ inst:building_3a24811f-0105-46f1-b13d-1c585f560635 a bot:Building ; bot:hasStorey inst:storey_3a24811f-0105-46f1-b13d-1c58a0a9fa61 , inst:storey_3a24811f-0105-46f1-b13d-1c58a0a9ff4b ; props:numberOfStoreys_property_simple 2 ; props:globalIdIfcRoot_attribute_simple "0w984V0GL6yR4z75XVLWOr" . # 階（Storey）が要素（Element）を含む inst:storey_3a24811f-0105-46f1-b13d-1c58a0a9fa61 a bot:Storey ; rdfs:label "Nivel 1" ; props:elevationIfcBuildingStorey_attribute_simple "0."^^xsd:double ; bot:containsElement inst:wall_ac9cc010-0e8f-4c9e-b289-81fb60a309bf , inst:slab_76178dce-ff53-4da5-b52a-f5f1ad7930e7 , inst:window_ac9cc010-0e8f-4c9e-b289-81fb60a3f63e . # ... (door, furniture など同階の要素が続く) # 壁（Element）— 9 つの窓をサブ要素として持つ inst:wall_ac9cc010-0e8f-4c9e-b289-81fb60a309bf a bot:Element ; rdfs:label "Muro básico:Partición con capa de yeso:163541" ; props:globalIdIfcRoot_attribute_simple "2idC0G3ezCdhA9WVjWemc$" ; props:objectTypeIfcObject_attribute_simple "Muro básico:Partición con capa de yeso" ; props:loadBearing_property_simple false ; props:isExternal_property_simple false ; bot:hasSubElement inst:window_ac9cc010-0e8f-4c9e-b289-81fb60a3f60b , inst:window_ac9cc010-0e8f-4c9e-b289-81fb60a3f608 , inst:window_ac9cc010-0e8f-4c9e-b289-81fb60a3f673 . # ... (計 9 個の窓が続く) # 窓（Element）— IFC 由来の属性がリテラル値で並ぶ inst:window_ac9cc010-0e8f-4c9e-b289-81fb60a3f60b a bot:Element ; rdfs:label "Ventana simple:100 x 100 cm:164193" ; props:globalIdIfcRoot_attribute_simple "2idC0G3ezCdhA9WVjWe$OB" ; props:objectTypeIfcObject_attribute_simple "Ventana simple:100 x 100 cm" ; props:overallWidthIfcWindow_attribute_simple "1."^^xsd:double ; props:overallHeightIfcWindow_attribute_simple "2.3"^^xsd:double ; props:thermalTransmittance_property_simple 6.7069 . 注目してほしいのは次の点です。 bot:Building / bot:Storey の階層と bot:Element のフラットな要素集合 : 建物 → 階など、馴染みのある階層関係が bot:hasStorey でグラフ化されます。各階が直接持つ部材は bot:containsElement で壁・スラブ・窓・扉・家具・方立などを指し、これらはすべて bot:Element クラスでラベル付けされます 壁と窓のようなサブ要素の関係 : 壁に埋まっている窓は bot:hasSubElement で壁と関係性を持ちます。上の壁は 9 個の窓を含む要素で、これをたどれば「この壁には窓が何個あるか」という質問がそのまま 1 ホップのグラフ走査になります props: 接頭辞の属性 : 寸法・面積・体積・グローバル ID・熱貫流率（ thermalTransmittance ）・外部面かどうか（ isExternal ）といった IFC 由来の属性は、 props: 名前空間配下のプロパティとしてリテラル値で付与されます。 props:globalIdIfcRoot_attribute_simple は IFC の GlobalId にあたり、ビューワー上のハイライトなど、3D モデルのオブジェクトと紐付ける際のキーになります。 このように、「Wall ノードが Window ノードを hasSubElement で含み、寸法はリテラル属性として持つ」というシンプルなモデルで建物全体を表現できます。リレーショナルデータベースのように「壁テーブル」「窓テーブル」を JOIN する必要はなく、関係をそのまま辿ることができます。 3.2 ファイル単位で名前空間を分ける（Named Graph） 要約 : 複数の IFC を 1 つの Neptune に同居させると要素 URI が衝突します。RDF の Named Graph でファイルごとにグラフ空間を分けておくと、衝突を防ぎつつ「特定の建物だけに問い合わせる」のも簡単になります。 複数の IFC ファイルを 1 つの Neptune クラスタに同居させると、要素 URI が衝突したり、特定のファイルだけを対象にした問い合わせが書きづらくなったりします。本実装では RDF の Named Graph を使い、ファイルごとに専用のグラフ空間を割り当てています。 ファイル building-A.ifc → Named Graph URI http://example.com/graphs/ifc/building-A ファイル building-B.ifc → Named Graph URI http://example.com/graphs/ifc/building-B SPARQL では GRAPH <...> 句で対象を絞り込めるため、後述のクエリも基本的にこの形になります。Neptune の bulk loader はリクエストパラメータの parserConfiguration.namedGraphUri でロード先のグラフを指定できるので、ロードの時点で分割しています。 3.3 自然言語を SPARQL に変換する（text-to-SPARQL） 要約 : ユーザーの質問を AI が SPARQL に翻訳し、Neptune で実行し、結果を再び自然言語に戻します。LangChain の既製チェーンをベースに、LangGraph で 2 ノード構成にまとめています。クエリの精度を上げるうえで一番効くのは、「お手本のクエリ例（Few-Shot）」をプロンプトに同梱することです。 問い合わせ系の中心は、ユーザーの自然言語の質問を SPARQL クエリに変換し、結果を再び自然言語で返す、いわゆる text-to-SPARQL の処理です。 本実装のベースには LangChain の create_neptune_sparql_qa_chain を採用しています。これは「スキーマを AI に渡して SPARQL を生成 → Neptune で実行 → 結果を AI に渡して自然言語化」という一連のチェーンが実装されています。 全体の処理フローは以下のとおりです。 実装上は、LangGraph を使って ① の要素選択ノード と ② 〜 ⑤ をまとめた SPARQL 処理ノード の 2 ノードにまとめており、後者のノードの中で LangChain のチェーンを順に呼び出しています。 AI に SPARQL を生成させるときに効果的になるのが Few-Shot プロンプティング 、つまり「こういう質問にはこういうクエリを書く」という例題をプロンプトに同梱することです。本実装では、IFC ファイルをロードするタイミングで、その IFC に含まれる要素タイプを参考にしながら、問い合わせ例の質問・SPARQL ペアを自動生成して DynamoDB に保存しています。問い合わせ時にはここから読み出してプロンプトに差し込みます。 3.4 必要なスキーマだけを DynamoDB から読み出す 要約 : 既製チェーンをそのまま使うと、DB 上の全クラス・全述語をプロンプトに載せてしまい、IFC のように要素が多いと応答が遅く、コストもかさみます。本節では、必要なスキーマだけを事前に切り出して持っておく工夫を紹介します。 LangChain の create_neptune_sparql_qa_chain をデフォルトのまま使うと、内部の NeptuneRdfGraph が、対象データベース上のすべてのクラスと述語をスキーマとして取得し、まるごとプロンプトに含めます。小さいオントロジーなら問題ありませんが、IFC のように要素タイプ・属性が多い場合は、初回応答の遅さとプロンプトサイズの増加が問題になります。既製チェーンの「全スキーマをそのまま渡す」前提が、IFC の規模では合わなくなる、ということです。 そこで本実装では、 NeptuneRdfGraph を継承した NamedGraphAwareNeptuneRdf クラスを用意し、次の 2 点を変えました。 スキーマクエリを Named Graph 単位に絞る : GRAPH <namedGraphUri> { ... } で囲み、ファイル単位のスキーマだけを取得する DynamoDB から事前ロード済みスキーマを使う : IFC ロード時にスキーマを抽出して DynamoDB に保存しておき、問い合わせ時は Neptune ではなく DynamoDB から読み出す DynamoDB には、IFC ファイル 1 つにつき 1 レコードの形でメタデータを保存しています。1 レコードには、そのファイルのスキーマ（登場するクラスや述語の一覧）、Few-Shot 用のサンプルなどをまとめています。中身のイメージは次のとおりです。 { "loadStatus": "READY", "fileName": "small-l1-p", "namedGraphUri": "http://example.com/graphs/ifc/small-l1-p", "schema": { "classes": [ {"uri": "https://w3id.org/bot#Building", "local": "Building"}, ... ], "rels": [ {"uri": "https://w3id.org/bot#hasSubElement", "local": "hasSubElement"}, ... ], "dtprops": [ {"uri": ".../thermalTransmittance_property_simple", "local": "..."}, ... ], "oprops": [] }, "resourceTypes": { "wall": 3, "window": 10, "door": 1, "slab": 2, ... }, "examples": "<question>...</question><sparql>...</sparql>" } これにより、Neptune へのスキーマ問い合わせの往復が省けて応答時間が短くなり、プロンプトに載せるスキーマもそのファイルに必要な分だけになるので、コンテキストの消費とトークンコストを抑えられます。 参考までに、最終的に AI が生成する SPARQL は次のような形になります（ユーザーの質問は「特定の壁に含まれる窓の数は？」）。 PREFIX props: <http://lbd.arch.rwth-aachen.de/props#> PREFIX bot: <https://w3id.org/bot#> PREFIX inst: <https://lbd.example.com/> SELECT (COUNT(?window) AS ?windowCount) WHERE { GRAPH <http://example.com/graphs/ifc/small-l1-p> { ?wall props:globalIdIfcRoot_attribute_simple "2idC0G3ezCdhA9WVjWemc$" . ?wall bot:hasSubElement ?window . FILTER(STRSTARTS(STR(?window), STR(inst:window_))) } } GRAPH <...> で対象 IFC を絞り、 hasSubElement で壁配下の要素をたどり、URI 接頭辞 inst:window_ の一致で窓に絞る、という意図がそのままクエリになっています。先ほどの 9 個の窓を持つ壁にこのクエリを実行すると、 windowCount = 9 が返ります。 3.5 動作イメージ ここまでの仕組みを通すと、ユーザーから見た動作は次のようになります。自然言語で質問を投げると、AI が SPARQL を生成・実行して自然言語で回答を返し、同時に該当する建物要素が 3D ビューワー上でハイライトされます。 質問する側は SPARQL や IFC の内部構造を知らなくても、「窓の熱貫流率を教えて」「家具は全部で何個ある？」と尋ねるだけで、回答と該当箇所の表示を同時に得られます。1 章で触れた、IFC の構造を知らないと素朴な問い合わせすら難しいという問題が、この画面の中で解消されていることが見て取れます。 4. GNN（Graph Neural Network）と組み合わせた発展 要約 : text-to-SPARQL は「決まった問い合わせ」に強い一方、BIM の繋がり方そのものから何かを予測するタスクは、生成 AI 単体では扱いづらい領域です。同じ RDF グラフを訓練データとして GNN を併用すると、干渉解消・熱負荷予測・意味付け補強といった、研究実績のあるタスクに広げられます。 生成 AI の発展により、「以前は自前で機械学習モデルを訓練していたタスクも、AI エージェントに任せれば対応できる」場面は増えています。本ブログの text-to-SPARQL もその流れの上にあります。 一方で、BIM のように、ノードとエッジの繋がり方そのものに意味があるデータに対しては、グラフ構造を学習する Graph Neural Network（GNN）が効果的なタスクも残っています。GNN は、各ノードの属性と隣接ノードからの情報を集約してベクトル表現を学習する深層学習モデルです。グラフデータベースに格納したデータをそのまま訓練データに利用できるため、本ブログのアーキテクチャと組み合わせやすい拡張先です。 BIM の分野で GNN が効果を発揮するユースケースを、3 つ紹介します。いずれも「答えが既存データの検索では得られず、予測が必要になる」という点で、GNN が効果的な領域です。 4.1 干渉解消（クラッシュ・レゾリューション）の予測 干渉チェックツールが出力する大量の候補のうち、多くは無視できる重なりで、本当に対処すべき干渉の仕分けと、どのコンポーネントを動かすかの判断に時間がかかります。これが GNN に向いているのは、「どれを直すべきか」が周辺コンポーネントとの関係に左右され、単体の属性だけでは決まらないからです。Hu ら（2023, Clash context representation and change component prediction based on graph convolutional network in MEP disciplines ）は、干渉が起きたコンポーネントと周辺の依存関係をグラフで表現し、Graph Convolutional Network で「どのコンポーネントを修正すべきか」を予測する手法を提案しています。周辺への波及を加味して判断できる点が特徴です。 4.2 部屋やゾーンを跨いだ熱負荷・エネルギー予測 従来の機械学習モデルは、建物全体を 1 ゾーンとして扱うか、各ゾーンを独立に扱うかのどちらかで、ゾーン間の熱の相互作用を捉えきれないという課題がありました。GNN はゾーンをノード、ゾーン間の隣接関係をエッジとしてグラフ化できるので、熱伝達を構造として取り込んだ上で予測できます。Lu ら（2023, Temporal graph attention network for building thermal load prediction ）は Graph Attention Network と GRU を組み合わせ、多ゾーンの熱負荷を同時に予測するモデルを提案しています。 4.3 BIM の意味付け補強（セマンティック・エンリッチメント） BIM モデルは、設計者やツールの違いによって要素の分類ラベルや属性が不揃い・不完全になりやすく、これが下流の数量積算や確認申請の自動チェックに影響します。Tarabishy & Sacks ら（2024, Incorporating Context into BIM-Derived Data—Leveraging Graph Neural Networks for Building Element Classification ）は、GNN ベースの要素分類が、幾何特徴のみを見る従来手法（SVM など）よりも精度で上回ることを示しています。「予測ラベルと登録ラベルが食い違う要素」を要レビュー候補として抽出する整合性チェックにも応用でき、ルールエンジンだけでは難しい BIM データの品質維持に有効な領域です。 AWS でのアプローチ GNN を AWS で動かす場合、まず候補になるのが Amazon Neptune ML です。Neptune に格納したグラフから、GNN モデルを訓練・推論できる機能で、ノード分類・回帰、エッジ分類・回帰、リンク予測が標準でサポートされています。 5. まとめ 本ブログでは、BIM データ（IFC）に AI エージェントからアクセスさせる 3 つのアプローチを整理した上で、そのうちの「IFC をグラフに変換してグラフデータベースに格納し、AI エージェントが問い合わせる」という構成を、実装レベルで解説しました。要点は次のとおりです。 IFC → Turtle の変換を AWS Batch で実行し、 bot: / props: 系のオントロジーで「建物 → 階 → 要素」のグラフを生成 自然言語の質問から SPARQL を生成して回答する仕組み（text-to-SPARQL）を構築。各ファイルのスキーマやサンプルクエリを事前に用意しておくことで AI エージェントが素早く正確に情報を取得できる 建物のグラフデータは、Amazon Neptune ML で GNN を組み合わせて、干渉解消の優先度予測・多ゾーンの熱負荷予測・BIM の意味付け補強といった、生成 AI 単体では解決しにくいタスクに広げられる可能性がある このアプローチの一番の利点は、データ構造を自分たちの用途に合わせて設計できることです。1 章で見たアプローチの比較に戻ると、ベンダー API の範囲で実現する方法や、ライブラリで IFC をその場で読む方法に対して、本ブログで紹介した手法は IFC を予め整理した状態で持っておくことで、複数ファイルの横断検索や集計の書きやすさも、他システムのデータとの突き合わせもスキーマ設計で吸収できます。一方、柔軟性と引き換えに変換パイプラインやデータベースを設計・運用するコストがかかるため、ユースケースに応じて、上手く使い分けるのが良いでしょう。