今日のご案内 ☕✨#
今回の中心は、Engineering AIが「正しそうな回答やコードを出す」段階から、専門ツールを実行し、その結果を次の判断へ戻す閉ループへ移っていることだ。RA-CADは生成したparametric CAD codeを実際に実行し、結果を観察してcritiqueとrewriteへ戻す。Architect LabsのRedwoodは、仕様からRTL、verification、firmware、kernelまでを一つの自動化loopとして扱い、COMSOLでは既存Java APIを介してmodel作成、study実行、可視化までをAgentが進める例が示されている。
Scientific AIでも同じ方向が見える。STCOは将来時刻のmotion、inflow、forcingをNeural Operatorへ明示的に与え、ferroelectric材料のPINN研究はMD dataとphase-field PDEを結び、同定したparameterをFEMへ戻してcross-verificationしている。学習モデルだけを最終回答器にするのではなく、既存のPDE/FEMや物理constraintと組み合わせ、検証可能な計算chainを残す構成が強い。
一方、企業側では導入量と組織全体のscaleの間にまだ大きな差がある。Gartner調査ではAI支出の増額意向が強い一方、複数business unitへscaleできた組織は22%にとどまる。Microsoftのdigital-trace研究も、AI利用後にproductivity系activityが増える一方、communicationとのバランスが変わることを示しており、「使った回数」だけでなくworkflowと組織行動を測る必要がある。
モデル・基盤側でも評価軸はbenchmark scoreだけでは足りない。Gemini 3.8 Flashはagentic workloadを意識した価格とtool-use性能を前面に出し、DeepSeekは305Bのmultimodal open weightsをself-host可能な形で公開した。NTTPCはphysical AI向けGPU環境を国内cloudとして提供している。AIを実工程へ入れるほど、実行コスト、tool権限、resource policy、human approvalまで含めたsystem設計が性能そのものになる。
1. RA-CAD、CAD生成を「一発生成」から実行結果を読むloopへ#
RA-CADは、自然言語からparametric CAD codeを作る処理をGenerate–Execute–Critique–Rewriteの反復loopとして構成する。各iterationで現在のcodeを実行し、その結果を観察したうえで、design instruction、code、execution feedbackを条件に明示的なpost-execution critiqueを生成する。critiqueは終了判定か次のrewrite指針として使われるため、単にcodeを生成して最後に通るか確認する構成とは異なる。
学習では、まずCAD Code Bootstrappingで基本的なparametric CAD coding能力を作り、その後Feedback-Driven Agent Optimizationでcodeとcritiqueのtrajectory全体を最適化する。著者らはCADFusionとText2CADでexecution validityとgeometric qualityが既存手法を上回ったと報告しているが、これは論文内benchmarkの結果であり、産業CAD kernelや複雑なassemblyへそのまま一般化できることを示すものではない。
💡 注目しておきたい理由: Text-to-CADの弱点は、見た目には妥当なcodeを出しても「実際にkernelで実行できたか」「生成geometryが意図どおりか」を生成側が知らないことにある。実行結果をAgentのstateへ戻す考え方は、CADだけでなくmesh生成、CAE setup、solver convergence、postprocessingにもそのまま展開でき、verificationを最後の検査ではなくcontrol loopの一部にできる。
- 🔗 情報源: arXiv
- 🕰️ 公開日時: 2026-08-06
- 🗂️ 分類: AIによる設計
2. Architect Labs Redwood、仕様からRTL・検証・firmwareまでを一つの自動化flowへ#
Architect LabsはRedwoodについて、2人のhuman architectが記述したhigh-level specificationから、performance model、RTL、UVM verification environment、formal proof、firmware、driver、custom compute kernelまでをAI systemが2週間未満で生成・co-optimizeしたと報告した。technical paperでは、各blockが95%以上のcode/functional coverageに達し、specification変更後のreverificationとFPGAへのredeploymentを48時間未満で実行したとしている。
ただし、現時点の実測hardwareはAMD Versal FPGA上のRedwood Nanoであり、Samsung 8 nmへprojectしたthroughputやpower efficiencyはASIC実測値ではない。同社自身もreal siliconを最終的なground truthと位置づけ、physical design、GDSII、tapeoutへ進めるとしている。したがってheadlineのperformance-per-wattを量産ASICの確立済み性能として扱うべきではない。
💡 注目しておきたい理由: 面白さは単発のRTL生成ではなく、specification→architecture→RTL→verification→firmware→kernel→hardware feedbackを一つのloopとして扱った点にある。Engineering Agentの価値を測るなら「codeを何行書いたか」より、変更後に再検証して実機まで戻せる時間とtraceabilityを見る方が重要になる。次の判定点は、このflowがphysical designとtapeout後のsilicon validationまで同じrigorを維持できるかどうかだ。
- 🔗 情報源: Architect Labs
- 🕰️ 公開日時: 2026-08-27
- 🗂️ 分類: AIによる設計
📚 追加で確認した資料:
3. Gartner、AI支出は増えるが複数部門へscaleできた組織は22%#
Gartnerは9月1日、2026年1月から4月に実施したenterprise AI調査を公表した。対象はFY2025の年間売上高が5,000万ドル以上の組織に属する1,303人で、22%がAIを複数business unitへscaleできた、またはAI-first approachを採用したと回答した。public releaseでは地域構成や質問文の全体は開示されていない。
支出側は拡大基調が強い。functional leaderの85%が2026年にAI支出を増やす予定と答え、2025年にはfunctional budgetの平均12%をAIへ配分していた。一方で11%は、自部門が2025年にAIへいくら使ったかを把握していないと回答している。つまりbudgetの増加速度に、組織横断scaleとfinancial visibilityが追いついていない。
💡 注目しておきたい理由: AI maturityをlicense数や利用者数だけで測ると、実装の核心を外しやすい。複数部門で再現可能なworkflowへ落とせるか、支出とoutcomeを紐付けられるか、成果の低いinitiativeを止められるかが次の段階になる。本調査はself-reported surveyであり、22%を市場全体の厳密な実測値としてではなく、支出拡大とscale停滞の構造を示すsignalとして読むのが妥当だ。
- 🔗 情報源: Gartner
- 🕰️ 公開日時: 2026-09-01
- 🗂️ 分類: 企業AI
4. COMSOL、既存solver APIをAgentから直接動かす実装例#
COMSOLは、Java-based APIを介してexternal LLMやAgentをCOMSOL Multiphysicsへ接続するworkflowを紹介した。demonstrationではAgentへ一つの指示を与え、equation-based modelを作成し、equationを定義し、studyを実行してvisualizationまで生成している。質問応答だけでなく、既存simulation softwareのmultistep operationをtoolとして扱う構成だ。
記事ではCosmonのNexusも紹介され、CAD preparationとgeometry cleanup、simulation setup、solver troubleshooting、parametric sweep、結果評価・可視化、reportingまでをCOMSOL API経由で扱うと説明している。Nexusはhuman-in-the-loopを前提とし、必要な場面ではengineerへ入力やapprovalを求める設計とされる。
💡 注目しておきたい理由: Agentic CAEのためにsolverをAI-nativeへ作り直さなくても、既存APIが十分包括的なら、成熟した数値solverをそのまま実行層にできる。実務ではmodel setup standard、solver failure時の処理、適用範囲、approval boundaryをskillやtool contractとして外出しし、Agentの自由度とverificationを分離することが重要になる。
- 🔗 情報源: COMSOL
- 🕰️ 公開日時: 2026-08-27
- 🗂️ 分類: CAD・CAE
5. STCO、将来の境界条件をNeural Operatorへ明示する#
STCO（Spatiotemporal Conditional Operator）は、time-dependent PDEのsurrogate predictionで、観測済みstateだけから未来を推測させるのではなく、target timeで予定されているbody motion、inflow、forcingをNeural Operatorへ明示的に入力する。controlやoptimizationでは将来の操作条件が現在stateから一意に決まらないため、それをfirst-class inputとして扱う設計だ。
著者らはimmersed-boundary CFD benchmarkで12種類のmatched backboneを比較し、平均でrelative-L2 field errorを31.1%、pressure-derived load errorを24.7%低減したと報告している。これらは論文benchmarkの結果であり、対象流れや外挿条件で同じ改善率を保証するものではない。
💡 注目しておきたい理由: Design/Control loop向けsurrogateでは、「未来の境界条件をモデルが暗黙に察する」前提は危険になる。motion、inflow、forceなどのprescribed conditionを明示的に渡す設計は、実機controlやdesign optimizationでcondition mismatchを減らし、surrogateの入出力契約を明確にする。
- 🔗 情報源: arXiv
- 🕰️ 公開日時: 2026-08-20
- 🗂️ 分類: AIによる設計
6. Ferroelectric材料のPINN、MDからcontinuum parameterを同定してFEMでcross-check#
npj Computational Materialsで9月2日に公開された研究は、ferroelectric材料のmultiscale modelingで、molecular dynamics（MD）dataとphase-field modelのPDE constraintを同じPINN lossへ組み込む。networkはpolarizationだけでなく、strain、stress、electric field、energy landscapeを再構成しながら、continuum phase-field modelに必要なcharacteristic energy density、length factor、anisotropy factor、Landau coefficientなどを同定する。
重要なのは、同定したparameterをPINNの中だけで使って終わらない点だ。parameterをfinite-element phase-field implementationへ入れて独立にPDEを解き、PINNとFEMの結果をcross-verifyしている。さらにlearned parameterのtransferabilityを3D phase-field simulationで確認し、tensileとbending load下のdomain evolutionを評価している。
💡 注目しておきたい理由: Scientific AIをblack-box surrogateではなく、atomistic dataから既存continuum modelへparameterを渡すbridgeとして使う好例だ。材料R&DでPINNを採用する場合も、prediction accuracyだけでなく、同定parameterを既存FEMへ戻して再現できるかというverification pathを持つことで、従来解析体系との接続がかなり容易になる。
- 🔗 情報源: npj Computational Materials
- 🕰️ 公開日時: 2026-09-02
- 🗂️ 分類: Scientific AI
7. Microsoftの実利用data、AI利用後はproductivity activityが21.2%増加#
Microsoft Researchの研究は、複数の大規模国際企業におけるMicrosoft 365のdigital traceを使い、生成AI導入後のwork pattern変化を分析した。self-reported productivityだけに頼らず、application上のactivityを観測し、Difference-in-Differencesで導入前後を比較している。
20週間のpost-adoption期間でAIを100回超使ったuserでは、productivity applicationのactionが21.2%、communication applicationのactionが7.1%増えたと報告する。communicationの増加が相対的に小さいため、個人・documentation中心のactivityへbalanceが動いた可能性があり、著者らはinterpersonal communicationやinformation diffusionが弱まらないかも論点として挙げている。これはobservational digital-trace analysisであり、randomized experimentによる因果効果の確定ではない。
💡 注目しておきたい理由: 企業AIの評価を「何時間短縮できたか」という自己申告だけから一段進め、実際のwork compositionがどう変わったかを見る材料になる。Engineering部門でも、document作成や個人作業の増加だけでなく、review、knowledge sharing、設計合意などcollaboration側がどう変化するかを合わせて測る必要がある。
- 🔗 情報源: Microsoft Research
- 🕰️ 公開日時: 2026-08-16
- 🗂️ 分類: 企業AI
8. Asynchronics、宇宙機digital twinを設計時のmodelから継続運用assetへ#
AsynchronicsはInfinite OrbitsとのOG3 mission向けcontractを発表し、space-hardware digital twin licenseから初のrecurring revenueが生じる商用契約だと説明した。Infinite Orbitsはこのdigital twinを、flight softwareのregression test、anomaly simulation、proximity operator trainingへ継続利用する予定としている。
同社の説明では、初期prototype validationを越えて、mission lifecycle中に使うcontinuous operational assetへ移行する位置付けになる。物理FlatSatだけに依存せず、flight softwareとhardware protocolのinteractionをsimulationで繰り返し検証する狙いだ。
💡 注目しておきたい理由: Aerospace Digital Twinの価値をdesign visualizationではなく、software regression、異常系試験、operator trainingという運用工程へつなげた事例として分かりやすい。設計段階で作った高忠実度modelを、運用・保守・trainingまで再利用できれば、model maintenanceとconfiguration management自体が長期的なengineering assetになる。
- 🔗 情報源: Asynchronics
- 🕰️ 公開日時: 2026-08-06
- 🗂️ 分類: CAD・CAE
9. NTTPC、physical AI向けBlackwell GPU cloudを国内提供#
NTTPCは9月2日、NVIDIA RTX PRO 6000 Blackwell Server Editionを採用した「GPUクラウド for フィジカルAI」を発表した。service自体は8月1日に提供開始しており、NVIDIA Omniverse librariesとIsaac Simに対応し、digital twin構築、robot simulation、AI modelの学習・推論を想定する。
提供形態はbare-metalの占有GPU serviceで、公開仕様ではRTX PRO 6000を8基搭載する。製造・物流領域でphysical AIを試す際、local clusterを購入して組む以外に、国内のelasticなexecution environmentを選べることになる。
💡 注目しておきたい理由: Physical AIではLLM APIだけでは完結せず、3D simulation、rendering、robotics、VLM学習などGPU-heavyなworkloadが同じloopへ入る。cloud移行では計算性能だけでなく、CAD/工場dataの配置、latency、占有性、simulation license、結果再現性まで含めて評価する必要がある。
- 🔗 情報源: NTTPCコミュニケーションズ
- 🕰️ 公開日時: 2026-09-02
- 🗂️ 分類: HPC・Physical AI
10. Computational Chemistry Agent、2年で「数件」から約50 systemへ#
computational chemistryのAgentを整理したPerspectiveは、2024年には約半ダース、2025年には約1ダースだった関連systemが、2026年8月8日時点では約50まで増えたとまとめる。対象systemの能力も、個別計算taskの補助から、in-silico experimentの設計、実行、解析、さらにmanuscript作成まで広がっているとする。
一方で著者らは、報告されているsystemはすべてhuman in the loopを残しており、開発者自身の外側へのadoptionはまだ限定的だと明記している。つまりsystem数の急増と、完全自律化・一般利用の成熟度は分けて見る必要がある。
💡 注目しておきたい理由: Scientific Agentの議論ではdemoの派手さより、どの段階でhuman approvalが残り、どこまで再現可能にtoolを動かせるかが成熟度を決める。計算化学で起きているtool orchestration、experiment planning、result interpretationの分業は、CAEや材料simulationへも近い形で波及する可能性が高い。
- 🔗 情報源: arXiv
- 🕰️ 公開日時: 2026-08-19
- 🗂️ 分類: Scientific AI
11. Gemini 3.8 Flash、Agent性能と「一仕事あたりのコスト」を同時に前面へ#
Googleは9月2日、Gemini 3.8 FlashとGemini 3.8 Flash Cyberを公開した。3.8 Flashのintroductory API priceは100万input tokenあたり0.75ドル、100万output tokenあたり3.75ドルで、coding、agentic task、multi-step reasoningを主な強化領域としている。GoogleはHLE-Verifiedで54.9%など複数benchmarkの改善を示しているが、これらはGoogle側の評価値として扱う必要がある。
同時にCyber variantはFairwind Programを通じてtrusted defenderへ限定提供される。Googleは、よりpermissiveなcyber mitigationを使うためaccessを制限すると説明している。一般modelの能力競争と、specialized high-risk tool useでaccess controlを分ける設計が同時に示された。
💡 注目しておきたい理由: Long-running Agentではstatic benchmark scoreより、taskを完了するまでのreasoning token数、tool call回数、retry、latencyがtotal costを決める。3.8 Flash自身も複雑taskではより多くreasoningする可能性を明記しており、導入比較は「1M token単価」ではなく、代表workflowあたりのquality・cost・tool-use reliabilityで行うべきだ。
- 🔗 情報源: Google
- 🕰️ 公開日時: 2026-09-02
- 🗂️ 分類: 最新AIモデル
📚 追加で確認した資料:
12. DeepSeek V4 Flash Vision、305B multimodal modelをMITで公開#
DeepSeekはDeepSeek-V4-Flash-Vision-ExpをHugging Faceで公開した。V4 familyで最初のexperimental multimodal modelとされ、model weights、tokenizer、reference inference assetsが提供されている。repositoryはMIT Licenseで、model sizeは305B parametersと表示されており、API-onlyではなくself-hosted evaluationが可能だ。
model cardではtext-agentとmultimodal-agent benchmarkの改善値が示され、たとえばToolathlon-Verified 75.9、ApexBench Pass@1 36.5などを報告している。ただしこれらはDeepSeekが掲載するsource-reported benchmarkであり、independent reproductionとは区別すべきだ。reference serving例も4×GB300 nodeを前提にしており、download可能であることと低costで運用できることは同義ではない。
💡 注目しておきたい理由: Open weightsの評価軸はlicenseの自由度だけでなく、実際のserving topology、VRAM、throughput、tool calling、multimodal pipelineまで広がっている。305B級を社内運用するなら、benchmark差よりhardware footprintと総運用費が採用判断を左右しやすい。
- 🔗 情報源: DeepSeek / Hugging Face
- 🕰️ 公開日時: 2026-08-31
- 🗂️ 分類: オープンウェイト
今日の紛れ枠#
COMSOL、room acousticsで境界modelの違いが11 dBのclarity差に#
COMSOLはwave-based time-domain room acousticsで、sound absorberをlocal reactionとextended reactionとして扱った場合の差を比較した。dG-FEMによる例では、reverberation parameterの差が広い帯域で5% JNDの2倍を超え、C50 clarityは最大11 dB差となった。local-reaction formulationはGPU accelerationに対応し、1,307,650 DOFs・40,000 timestepsの例をNVIDIA T400で約1時間と報告している。
追う理由: AI-assisted CAEが高度になっても、boundary conditionのmodel-form errorが支配的なら出力は正しくならない。Agentがsolverを自動操作するほど、「どの物理modelを選んだか」を監査可能にする価値が上がる。
- 🔗 情報源: COMSOL
- 🕰️ 公開日時: 2026-09-01
- 🗂️ 分類: CAD・CAE
AEGIS、MCP toolのresource abuseをmodel外のpolicyで制御#
AEGISは、text、image、video、locationなどschemaの異なるMCP tool invocationを、共通policyを適用できる表現へnormalizeする。Open Policy AgentとContextForge AI Gatewayへ統合し、巨大なsearch radiusや長時間video処理など、backend availabilityを圧迫するrequestをpolicy enforcementで制限する構成を提案している。
追う理由: Engineering AgentがHPC job、solver license、外部APIを自由に呼べるようになると、prompt safetyだけではresource governanceを担えない。quotaやjob size、tool scopeをmodel外で強制できるgateway設計が必要になる。
- 🔗 情報源: arXiv
- 🕰️ 公開日時: 2026-08-20
- 🗂️ 分類: Agent Protocol・安全性
RWKV-7 13.3B、KV cacheを増やさないrecurrent architectureの現行checkpoint#
RWKVはRWKV-7 Gooseの13.3B base checkpointをHugging Face Transformers形式で公開した。attention-free recurrent architectureで、recurrent stateはconstant size、generated tokenあたりのinference workもconstantと説明される。weightsとinference bundleはApache-2.0で、model cardはsafety、bias、factuality、高stakes用途の評価を主張していない。
追う理由: Long-running Agentではcontextが伸びたときのKV-cache growthが運用制約になり得る。Transformer/MoE以外のarchitectureとして、同規模modelとのquality・latency・memory比較が揃うかを追う価値がある。
- 🔗 情報源: RWKV / Hugging Face
- 🕰️ 公開日時: 2026-09-02
- 🗂️ 分類: オープンウェイト
本記事は公開情報をもとに編集されています。重要な判断にはリンク先の一次情報をご確認ください。