メインコンテンツへスキップ
  1. すべての記事 📚/

Engineering AIは実行と検証へ――CAD/CAE・MBD、閉ループ材料研究、Agent予算と統治

目次

今日のご案内 ☕✨
#

今日の中心は、Engineering AIが「説明するAI」から、既存の設計・解析・検証環境で成果物を直接つくる実行層へ移っていることだ。SimScaleはOnshape内でCAD形状から解析設定・メッシュ・物理計算・結果解釈まで進めるAgentを投入し、IBMはrequirementsからtest caseを生成、MathWorksはSimscape componentそのものを記述・検証するskillを加えた。評価対象は回答文ではなく、設定の正しさ、traceability、差分、override可能性へ移る。

航空・材料研究でも同じ構図が見える。GE AerospaceはXA102でMBDを設計から製造・検査・組立までつなぎ、M88 T-REXは既存modular architectureを保ちながら20%の最大推力増を狙う。一方、SynAgent、MatBrain、Andromeda 2は、仮説・証拠・実験・選択を閉ループ化しつつ、preprintの自己報告や比較条件を明示する必要性も示している。

Agentが実行範囲を広げるほど、model外側の制約が主役になる。Qwen Codeはtoken・turn・timeで実行予算を区切り、EYの調査では形式的なAI policyがほぼ普及していても、緊急時のgovernance bypassや無許可Agentの検知不足が残る。Open-weightの経済性も同様で、benchmark近接だけではなく、production移行時の運用・support・licensingまで含めて判断する段階に入った。

1. SimScale、Onshape内でCADから解析実行までつなぐEngineering AI Agent
#

SimScaleは9月15日、Onshape App Storeから利用できるEngineering AI Agentを公開した。CFD、thermal、electromagnetics、FEAを対象に、CAD geometryの理解からsimulation setup、meshing、適用physicsとboundary conditionの提案、計算実行、結果解釈までを同じOnshape環境で進める。engineerは途中でsetupやboundary conditionを修正し、assumptionを確認してからAgentへ制御を戻せる。

同社はこのAgentを、単なる会話UIではなくSimScale Agent API上で動くauditableなexecution layerとして説明している。各runを追跡可能にし、既存のcustomer governance下でdataを扱うというのが設計上の位置づけだ。性能や生産性の改善度合いは一次発表だけでは独立に検証されていないため、ここでは機能範囲と実装境界を事実として扱う。

💡 注目しておきたい理由: CAD contextを保ったままCAEのsetupとexecutionへ進むことで、Engineering Agentの評価軸が「解析を説明できるか」から「solver設定、境界条件、traceability、override、結果解釈まで一連のworkflowを正しく扱えるか」へ変わる。実務導入では、誤ったsetupをそれらしく生成する失敗をどう検知し、engineerのreview pointをどこに置くかが中心課題になる。

  • 🔗 情報源: SimScale
  • 🕰️ 公開日時: 2026-09-15
  • 🗂️ 分類: CAD・CAE・Engineering Agent

2. XA102、MBDを設計から製造・検査・組立まで通す
#

GE Aerospaceは9月14日、米空軍Next Generation Adaptive Propulsion(NGAP)向けXA102 adaptive-cycle engineについて、最初のtest assetのassemblyへ向けsupplierがhardwareとsubcomponentを調達していると発表した。XA100での知見を引き継ぎつつ、programはdigital designの成熟段階から実物assemblyとtestへ移行している。

重要なのは、GEがXA102を「MBDでbuiltされる最初のengine」と位置づけ、model-based definitionをdesignからmanufacturing、inspection、assemblyまでmachine-readableなproduct definitionとして接続している点だ。従来の2D drawingを主軸にするのではなく、supplier側の製造・検査も同じdigital definitionを消費する構成を明示している。

💡 注目しておきたい理由: Aerospaceのdigital engineeringは、CAD/CAEをdigitizeしただけでは価値が閉じない。設計定義がsupplier hardware、inspection、assembly、最終testへ壊れずに流れるかがdigital threadの実効性を決める。AI-assisted designを組み込む場合も、生成したgeometryやrequirementがdownstreamの製造・検査定義へ追跡可能であることが採用条件になる。

  • 🔗 情報源: GE Aerospace
  • 🕰️ 公開日時: 2026-09-14
  • 🗂️ 分類: 航空機エンジン・Digital Engineering

3. SynAgent、18回の材料実験で仮説のverify/falsifyまで閉ループ化
#

9月16日提出のpreprintは、multimodal LLM Agentと自動材料合成・characterizationを結ぶSynAgentを報告した。XRD patternやelectron micrographなど新たに得たdataを読み、分析skillと仮説を更新し、成功すると予想する条件だけでなく失敗すると予想する条件も試すverify-falsify loopを採る。

著者らはLiCoO2 (001) thin filmを対象に18回の自律実験を行い、substrate temperatureとcrystallizationの関係を探索した結果、650–690°C付近の狭いoptimal growth windowへ収束したと報告している。これは著者報告のpreprint結果であり、第三者再現や査読済みの確立結果として扱うべきではない。

💡 注目しておきたい理由: Autonomous labの価値が「最適条件を当てる」だけでなく、仮説履歴と観測証拠を残し、反証実験まで含めて次のexperimentを選ぶ方向へ進んでいる。実務では、Agentの推薦値よりも、どの観測がどの仮説を支持・棄却し、その判断が次の実験条件へどうつながったかをauditできることが重要になる。

  • 🔗 情報源: arXiv
  • 🕰️ 公開日時: 2026-09-16
  • 🗂️ 分類: Scientific AI・材料・自動実験

4. IBM Engineering AI Hub 1.4、requirementsからverification artifactを生成
#

IBM Engineering AI Hub 1.4は9月17日から一般提供され、system/software requirementsを基にdraft test caseとdetailed test scriptを生成するAgentを追加した。precondition、postconditionを含むtest設計をsource requirementへ接続したまま生成し、最終review・refine・approvalはengineerが担う。

同releaseではMCP tool catalogを拡張し、既存MCP toolをproject configuration-awareにしたほか、Azure AI model runtimeへの対応、Redisによるshared state、MCP/A2A endpointを管理者がenable/disableするcontrolも加えた。

💡 注目しておきたい理由: Verificationで重要なのは生成量ではなく、requirementとのtraceabilityとconfiguration/version contextである。AI test generationを評価するなら、要求変更時の追従、対象configurationの識別、review gate、生成assetの差分をtest evidenceと一緒に追えるかを確認すべきだ。

  • 🔗 情報源: IBM
  • 🕰️ 公開日時: 2026-09-17
  • 🗂️ 分類: AIによる設計・Requirements・Verification

5. MathWorks SATK、AgentによるSimscape component authoringへ拡張
#

MathWorksは9月16日、Simulink Agentic Toolkit(SATK)v2026.09.cを公開した。新しいsimscape-write-ssc skillは、custom componentのbehavior、parameter、interfaceを定義するSimscape Language source file(.ssc)の作成・編集・validationを支援する。

💡 注目しておきたい理由: Agentがscriptを書く段階から、物理systemのequationとinterfaceを持つ実行可能なengineering artifactを直接編集する段階へ踏み込んだ。MBSE/CAE用途では、生成物を文章評価するのではなく、compile、simulation、regression、model diffを既存toolchainで自動検証する構成が実用的なguardrailになる。

  • 🔗 情報源: MathWorks / GitHub
  • 🕰️ 公開日時: 2026-09-16
  • 🗂️ 分類: AIによる設計・MBSE・Simulink Agent

6. M88 T-REX、既存modular architectureを保ちながら最大推力20%増を狙う
#

フランスDGAは9月10日、Rafale F5に向けた先行作業としてSafran Aircraft EnginesへM88 T-REXのpreliminary designを発注した。目標は最大推力を7.5 tonnesから9 tonnesへ引き上げる20%増で、M88-2のmodular architectureと基本構造、運用上の利点を維持しながら一部moduleを変更する。

💡 注目しておきたい理由: これは白紙設計ではなく、既存architecture、integration envelope、maintenance性、qualification pathを守りながら性能を伸ばす典型的なconstrained design problemである。AI-assisted trade studyでも、自由な最適化より「変えてよいmodule/変えてはいけないinterface」を明示した探索の方が実務価値を持つ。

7. MatBrain、30B reasoning modelと14B execution modelを役割分担
#

Nature Machine Intelligenceで9月10日に公開されたMatBrainは、domain reasoningを担うMat-R1(30B)とtool actionを担うMat-T1(14B)を組み合わせたcollaborative materials-research Agentである。著者らはcrystal candidate 30,000件を生成・screeningし、48時間以内に38件のpromising materialを特定したと報告している。

dataとcodeも公開されており、closed vendor demoより再現性を検討しやすい。ただし30,000→38という結果自体は著者らの実験系・評価基準に依存するため、別材料系への一般化を自動的に意味しない。

💡 注目しておきたい理由: すべてを一つのfrontier modelへ任せず、reasoningとexecutionを比較的小さい専門modelへ分解する設計は、cost、failure isolation、local deployment、traceabilityの点で実務的な選択肢になる。monolithic modelとの比較では最終精度だけでなく、tool-use failureの切り分けや再実行コストも見るべきだ。

8. Andromeda 2、evidence-groundedな実験選択をmatched budgetで比較
#

9月16日提出のpreprintは、structured in-house evidenceを検索し、formulation reasoningと自動実験をつなぐAndromeda 2を報告した。paclitaxel formulationを同一budgetで比較し、著者らはhigh-performance hit rateがAndromeda 2で50%、Andromeda 1で17%、wet-lab DoEで2%だったと報告する。四つのtarget product profileをすべて満たしたformulationはそれぞれ12、6、0件だった。

さらにablationでは、structured evidenceへのaccessによってmean AUCが34%改善したと著者らは報告している。結果はpreprintの自己報告であり、experimental platformやtask definitionをまたいだ一般的優位性はまだ確立していない。

💡 注目しておきたい理由: Autonomous R&Dでは「Agentを使ったか」より、同じexperiment budgetでevidence-grounded版とunguided版を比較できるかが重要になる。retrievalされた証拠がどのdecisionを変えたか、ablationで性能差が残るかを設計に組み込むと、Agentの寄与を単なる自動化効果から分離しやすい。

  • 🔗 情報源: arXiv
  • 🕰️ 公開日時: 2026-09-16
  • 🗂️ 分類: Scientific AI・化学・研究自動化

9. Qwen Code、異種subagentへtoken・turn・timeの実行予算を付与
#

Qwen Codeの9月17日updateでは、Claude CodeとCodexをbuilt-in subagentとして呼び出し、ACP対応のexternal agentも接続できるようになった。workflowは名前で起動でき、message末尾でtoken capを指定できるほか、Goalには最大turn数とactive timeの上限を設定できる。

subagentごとのtool restriction、permission approvalも用意され、Codexはdefaultでread-onlyとされる。異なるagent productを一つのconversationからbrokerする一方、実行量と権限をboundedにする設計になっている。

💡 注目しておきたい理由: Multi-Agent運用では、delegation先が増えるほどcostとprivilegeが同時に膨らむ。enterprise platformではmodel routingだけでなく、token、turn、wall-clock、tool scope、write permissionをjob単位でmeteringし、承認済みworkflowのversionまで固定することが運用条件になる。

  • 🔗 情報源: Qwen Team
  • 🕰️ 公開日時: 2026-09-17
  • 🗂️ 分類: AIエージェント・コーディング・Multi-Agent

10. EY調査、AI policy普及と運用governanceの間に大きなgap
#

EY Americas Assuranceは9月15日、米国の上場企業で年商10億ドル以上の企業に所属するsenior AI decision-maker 202人を対象としたonline surveyを公表した。調査期間は2026年5月28日〜6月15日で、full sampleのmargin of errorは95% confidenceで±7 percentage points。回答は自己申告で、対象も大規模な米国上場企業に限定される。

主要結果では、98%がformal AI governance policyを持つ一方、47%はurgent deploymentでgovernance processを適用しなかった経験があると回答した。agentic AIを利用する組織の回答者では26%がunauthorized Agentを検知できないとし、全体の36%はdata loss、financial damage、operational disruption、brand damageなどmaterially negativeなAI incident/failureを経験したと回答している。

前回waveとの直接比較は公開release上で成立しておらず、trendではなくcurrent-state snapshotとして読むべきだ。またEY自身がAI governance/assurance serviceを提供するcommercial contextもあるため、policyの不備を因果的にincidentへ結びつける資料ではない。

💡 注目しておきたい理由: 「policyがある」ことと「runtimeでcontrolできる」ことが別物だと数値で示している。Agent governanceでは、inventory/discovery、authorization、tool/action boundary、audit、incident detection、urgent workflowでのbypass耐性を測る必要があり、document coverageだけをKPIにすると実装上の穴を見落とす。

  • 🔗 情報源: EY
  • 🕰️ 公開日時: 2026-09-15
  • 🗂️ 分類: 企業AI・Agent Governance・Risk Survey

11. ILO中国企業調査、AI導入の広がりとproductivity測定の粗さを同時に示す
#

ILOは9月15日、中国企業21社へのin-depth interviewと、業種横断のprofessional 1,591人へのsurveyを組み合わせたresearch briefを公開した。interview対象の21社はすべてAIを利用中または導入予定だったが、productivity impactの測定方法や組織的な導入形態は揃っていない。これは中国企業全体を統計的に代表する21社panelではなく、AI-activeな組織を含むdescriptive evidenceとして読む必要がある。

professional surveyでは、56%がAI adoptionを「inevitable trend」と見なし、47%がjob displacementよりjob creationが多いと予想する一方、39%はincome declineを懸念した。これらはattitude/expectationの回答であり、実際の雇用・賃金への因果効果ではない。public summaryも、企業のproductivity measurementがpatchyであることを明記している。

前回と同一sampleによるmatched comparisonは示されていないため、時系列trendとしては扱えない。interviewとsurveyを組み合わせることで導入の実態像は得られるが、企業例のselectionや自己報告によるbiasは残る。

💡 注目しておきたい理由: Enterprise AIで「導入率が高い」ことと「どのtaskでどれだけ価値が出たか」は別問題である。scale前にtask-level productivity、quality、rework、workforce transitionを共通指標で測らなければ、adoptionの拡大だけが先行して効果測定が追いつかない。

12. Open-weightはbenchmark接近、productionでは運用差が残る
#

The State of Open Source AI v1.1は、open-weightとOSI定義のopen-source AIを明確に分けたうえで、benchmark、price、OpenRouter usage、developer surveyを横断してecosystemを整理している。ページは2026年9月版で、dataは9月1日時点、最終更新は9月14日と明示されるが、単一の「公開日」は示されていないため日付は補完しない。

capability/economicsでは、report上のbest open modelがleading closed modelより約3 index points低い一方、priceは約60%とされる。また2026年8月のOpenRouter token volume上位10 modelのうち8つがopen-weightだった。developer evidenceではopen model利用が79%、closed model利用が71%で、professional developer cutはn=954。一方、open modelはproduction到達率でclosedより約12 percentage points低いとされ、churn/challenge analysisではn=1,410、region別challenge tableではn=1,411が使われている。

このreportは一つのcontrolled studyではなく、Artificial Analysis、OpenRouter、Mozilla/SlashData surveyなど異種のdata sourceを束ねたecosystem synthesisである。benchmarkとpriceは更新が速く、surveyもquestionごとにsampleが異なる。したがって「openがclosedを置き換えた」といった単純な結論ではなく、usage volume、cost、production friction、licensingを別軸として読む必要がある。

💡 注目しておきたい理由: Model strategyはbenchmark順位だけでは決められない。weightが取得可能でも、support、deployment、scaling、security、governance、license上の自由度が同じとは限らない。open-weightとopen sourceを区別し、total deployment economicsとproduction移行時のfrictionを比較することが調達・内製判断の前提になる。

  • 🔗 情報源: State of Open Source AI / Mozilla
  • 🕰️ 公開日時: 2026年9月(日付不明、ページ最終更新 2026-09-14)
  • 🗂️ 分類: オープンウェイト・OSS・Ecosystem Report

今日の紛れ枠
#

MTU/KIT、rotating detonation combustorの下流へturbineを統合
#

MTU Aero EnginesのWolfgang-Heilmann-Preisは、KITのJonas Beilによるrotating detonation combustorからpowerを取り出すturbine conceptのmaster thesisを選出した。MTUによると、simple turbine stageを実験的に統合し、hydrogenを燃料としてrotating detonation setupから電力を発生させた。full technical paperではなくaward release段階の情報で、効率・thermal loading・durabilityの詳細値は公開されていない。

追う理由: Rotating detonation研究はcombustor単体の成立性に寄りやすいが、engine architectureとして成立するには非定常flowを受ける下流turbineで有効workを取り出す必要がある。次に見るべきはturbine inlet unsteadiness、efficiency、熱負荷、耐久性の定量dataだ。

  • 🔗 情報源: MTU Aero Engines
  • 🕰️ 公開日時: 2026-09-15
  • 🗂️ 分類: 航空機エンジン・先進燃焼

Z.ai、10万超の中国製accelerator上のinference stackをInfra Agentで最適化
#

Z.aiはGLM-5.3-Flashのproduction inferenceを10万超の中国製AI accelerator上で動かし、そのinference stack構築にGLM-5.3-powered Infra Agentを使ったと報告した。memory optimizationやEPD disaggregationなどを組み合わせ、end-to-end serving performanceを約3倍へ改善し、initial adaptationからproduction readinessまで2週間未満だったとしている。規模・performanceはいずれも同社の自己報告である。

追う理由: Agentがapplication codeではなくmodel serving infrastructure自体を変更する例で、leverageとriskが大きい。load test、numerical correctness、microbenchmark、execution trace、rollback、人間によるrisk reviewを一体化した「dense feedback」が再現可能なengineering patternになるかが焦点になる。

  • 🔗 情報源: Z.ai
  • 🕰️ 公開日時: 2026-09-17
  • 🗂️ 分類: AIモデル・推論基盤・AIエージェント

デジタル庁、源内OSS Ver. 2.0でAgent・coding AI・deployment templateを計画
#

デジタル庁は9月18日、ガバメントAI「源内」OSS Ver. 2.0で公開予定の資材を説明した。2027年2月頃の公開を予定し、Agent chat、個人専用server上のcoding AI環境「源内工房」、基盤model deployment template、利用実績の分析資材などを含む。政府では2026年5月から全府省庁の約18万人を対象とする大規模実証を進めているが、Ver. 2.0の機能は開発中で変更可能と明記されている。

追う理由: 単一chatbotではなく、Agent、coding、model deployment、usage governanceを再利用可能なpublic infrastructureとして切り出す構想になっている。実物OSSでidentity、audit、model routing、data boundary、cost controlがどこまでdeployableな形で提供されるかを確認したい。

  • 🔗 情報源: デジタル庁
  • 🕰️ 公開日時: 2026-09-18
  • 🗂️ 分類: 日本・Government AI・OSS・AIエージェント

本記事は公開情報をもとに編集されています。重要な判断にはリンク先の一次情報をご確認ください。