AI駆動開発 2026年8月28日

AIエージェントがCAEを動かす時代、人間に残る仕事は「判断」だけじゃない

2026年7月30日、「CAEユニバーシティ特別公開フォーラム 2026」で面白い実験が発表された。

AIエージェントにCAEツールを操作させたら、どこまでできるか。サイバネットシステムの宮堂泰寛氏が行ったその実験は、「AIが解析する時代」がすでに実験段階を越えようとしていることを、具体的な形で示している。

AIエージェントがCAEを動かした、という話

宮堂氏の着想はシンプルだ。「CAEツールはGUIのイメージが強いが、裏ではコマンドが動いている。コマンドはコードだから、AIがコードを書ければCAEを動かせるはず」というものだ。

実験の構成はこうなっている。AIエージェントにはChatGPTの「Codex」を使用。作成されたコードの確認と実行には「Visual Studio Code（VS Code）」を使い、CAEソルバーは「Ansys MAPDL」または「CalculiX」。AIがPythonコードを生成し、そのコードを実行することでCAEツールを操作する仕組みだ。

最初の実験対象は、中央に円孔を設けた薄板の引張解析だった。形状・材料特性・拘束条件・荷重条件・出力内容をプロンプトで与えると、AIはまず「解析計画」を立案する。いきなり解析を走らせるのではなく、計画→確認→実行という順序を踏ませたのが宮堂氏の判断だ。

この計画フェーズで、なかなか興味深いことが起きた。「右端にX方向へ10Nの分布荷重を与える」と記述したところ、AIが「それは合力10Nですか、線荷重10N/mmですか、面圧10MPaですか」と聞き返してきた。しかも、それぞれの意味を説明した上で推奨する選択肢まで提示したという。

CAEに慣れた人間なら当然確認する情報を、AIが自発的に問い返してきた。この一点だけで、「AIがCAEの勘所をある程度理解している」という事実が伝わる。

解析後には、解析目的・解析条件・結果・考察を含む解析結果レポートを自動生成。書式についての細かな指示はなかったが、一般的な解析報告書の構成に自然に収まったという。さらに、板厚が薄いことから2次元の平面応力モデルとして扱う方針を立て、板厚を厚くした場合には3次元ソリッドモデルへの変更を自ら提案した。メッシュ収束性や力の釣り合いも検証項目として盛り込まれた。

もう一つ注目したいのは、ソルバーの変更だ。Ansys MAPDLで動かした同じ解析を、CalculiXに切り替えても同様に実行できた。内部処理は大きく変わるが、「人間がAIへ指示する手順はおおむね変わらない」（宮堂氏）という。

なぜ今この話が重要か

ソフトウェア開発の現場ではすでに、人間がコードを書きAIがレビューする、というフローから、AIがコードを書き人間がレビューとマネジメントを担う、という逆転が起きつつある。宮堂氏はCAE解析にも同じ変化が来ると見ており、「AIが解析を担うようになれば、人の役割はツール操作から判断やマネジメントへ移る」と述べた。

この見立て自体は自然だ。ただ、ここで少し立ち止まって考えたいことがある。

「実装できる」という差分が意味すること

宮堂氏が「通常の生成AIとAIエージェントの違い」として強調していた点がある。通常の生成AIはプロンプトに回答を返すだけだが、AIエージェントは「自ら行動して結果を受け取り、次の判断につなげる一連の処理を自律的に実行できる」という点だ。

つまり、解析を実行→ログやエラーを取得→次のアクションを判断→また実行、というループを人間が介在しなくても回せる。今回の実験では「最終的なアウトプットを人間がレビューする」という設計になっているが、ループの中身はAIが完結させている。

これが意味するのは、「AIができる仕事の単位」が変わったということだ。以前は「一つの問いに答える」だったのが、「一連のタスクを完遂する」になっている。この差は小さくない。

ここからは見方だが──構造と期待値を整理する

この実験の位置づけについて、少し率直に書く。

宮堂氏は「簡単な例ではあるが、AIエージェントは想像以上に賢い」と語っている。この「簡単な例」という留保が重要だ。円孔薄板の引張解析は、CAE解析の中では比較的ワークフローが明確な問題だ。材料非線形・大変形・マルチフィジクス・実形状の複雑なメッシュを伴うケース、あるいは「そもそも何を解析すべきか」が曖昧な段階での問題設定は、今回の実験の射程に入っていない。

「AIエージェントが解析できる」という事実と、「実務で使える」という話は、まだ距離がある。この距離を見誤ると、導入を急いでも使える場面が想定より限られる、ということになる。

一方で、「いずれ来る」という見立てについては、かなりの確度があると思っている。ソフトウェア開発でのAI活用の進み方を見ていると、CAE業界はおそらくその1〜2年後を歩いている。今は「実験でここまでできた」という段階だが、ツールとエージェントの統合が進めば、適用できる問題の範囲は着実に広がる。

「人間に残る役割」論の落とし穴

よくある言い方として、「AIがやるようになれば、人間は判断やマネジメントをやればいい」というものがある。宮堂氏も同様の指摘をしており、重要なスキルとして「問題設定・検証・AI管理」を挙げている。

これ自体は正しいのだが、「判断やマネジメントに移る」という言葉が持つ落とし穴がある。判断やマネジメントも、それ自体を設計しなければ機能しない、という点だ。

AIが出した解析結果を「正しいかどうか判断する」には、CAEの基礎知識だけでなく、AIの挙動の特性・典型的な失敗パターン・検証の設計方法が必要になる。AIが解析計画を立てたとき、「この計画で大丈夫か」を問えるかどうかは、その人がCAEの本質的な部分を理解しているかどうかにかかっている。

今回の実験でAIが自発的に荷重の種類を確認してきたのは良い挙動だが、もし問い返さなかった場合、人間側がどこで気づけるか、というのも問われる。AIが正しく動いているかを見る目は、AIが使えるようになったからといって自動で身につくものではない。

つまり、「操作から判断へ」という移行は起きるが、判断できる人間を育てる仕組みそのものを設計しなければ、「AIが動かしているが誰も検証できていない」という状態になりかねない。CAE教育の再設計が必要だと宮堂氏が述べているのは、この文脈で読むべきだと思う。

実務担当者への示唆と次の論点

CAE技術者として今から考えるべきことは、いくつかある。

まず、「AIが動かせる解析」と「人間が設計すべき解析」の境界を自分なりに持っておくことだ。ワークフローが定型化されていて、入力と出力が明確な解析は、近い将来AIに移管されていく可能性が高い。一方で、問題設定そのものが曖昧な上流工程や、結果の物理的妥当性を判断するフェーズは、まだしばらく人間の領域だ。

次に、AIエージェントを「使う側」に回るための準備だ。プロンプトの書き方、解析条件の言語化、AIが出した計画への問い返し方──これらは従来のCAEスキルとは少し違う筋肉を使う。今のうちに試しておく価値がある。

組織レベルで言えば、「AIが出した解析結果をどう検証するか」のプロセスを先に設計しておくことを勧める。AIエージェントの出力は速い。速いからこそ、検証なしに先に進むリスクが上がる。特に、設計判断や安全性に関わる解析では、「AIがやったから正しい」という空気が組織に生まれないよう、意図的にレビューの場を設ける必要がある。

今後の論点として表面化してくるのは、責任の所在と品質保証の問題だと見ている。AIが解析計画を立て、AIが実行し、AIがレポートを書いたとき、その解析に誤りがあった場合の責任はどこに帰属するのか。今回の実験ではあくまり人間が最終レビューを行う設計になっているが、実務での運用ではそのレビューがどこまで実質的に機能するかが問われてくる。