LLMは設計司令塔にする（計算、意思決定は任せない）
物理計算はToolに任せる
Agent数よりTool整備が重要
自由会話よりワークフロー管理（昨今のトレンド）
状態管理と履歴保存が必須
Human承認点を組み込む
検証Agentを独立させる
MCPで設計Toolを接続する
初期は3Agentで十分
階層型は後から導入する

要旨
1. 背景：ターボ機械設計システムにおける生成AIの役割
2. 最近のMultiAgent技術トレンド
3. ターボ機械設計システムの本命アーキテクチャ
4. 初期実装でおすすめの最小構成
5. なぜ最初から階層型マルチエージェントにしなくてよいか
6. ターボ機械設計システムにおけるAgentの役割分担
7. 実装ロードマップ
8. 最終的な推奨構成
A.1 階層型マルチエージェントとは何か
A.2 階層型のメリット
A.3 階層型のデメリット
A.4 初期段階では階層型を避けるべき理由
A.5 階層型を導入すべきタイミング
A.6 ターボ機械設計における階層型の完成形
A.7 階層型にする場合の設計原則
A.8 階層型マルチエージェントの結論

要旨

生成AIのマルチエージェント技術は、単に複数のAIが会話して結論を出す段階から、状態管理、ワークフロー制御、外部ツール実行、検証、Human-in-the-loop、実行ログ管理を備えた設計自動化基盤へ移行している。

ターボ機械設計システムに適用する場合、重要なのは「LLM同士をたくさん会話させること」ではない。重要なのは、既存の1D設計コード、CFD、メッシュ生成、サロゲートモデル、最適化コード、設計基準PDF、過去設計DBを、生成AIエージェントが安全に呼び出し、設計プロセス全体を管理することである。

結論として、初期段階では本格的な階層型マルチエージェントは不要である。まずは、状態管理つきワークフロー、軽いOrchestrator、少数の専門Agent、強いTool群で始めるのが最も現実的である。階層型マルチエージェントは、CFD、最適化、サロゲート、レポート生成、設計DB連携まで統合された後に導入すればよい。

1. 背景：ターボ機械設計システムにおける生成AIの役割

ターボ機械設計は、単なる数値計算ではない。

要求仕様の整理、平均線設計、速度三角形、反動度、Mach数、流量整合、翼列設計、CFD条件設定、メッシュ品質確認、解析結果評価、サロゲートモデル作成、設計レビュー、報告書作成など、多数の工程が連続している。

このような設計プロセスでは、生成AIに直接物理計算をさせるよりも、生成AIを設計プロセスの司令塔として使う方が有効である。

つまり、LLMの役割は以下である。

- 要求仕様を整理する
- 設計条件を構造化する
- 適切な設計ツールを呼び出す
- 計算結果を解釈する
- 異常値を検出する
- 次の設計変更案を提案する
- 設計根拠を文書化する
- 人間のレビューに必要な情報をまとめる

一方で、以下はLLMではなく、既存の物理モデルや解析コードに担当させるべきである。

- 1D平均線設計計算
- 速度三角形計算
- 反動度計算
- Mach数評価
- CFD実行
- メッシュ生成
- サロゲートモデル推論
- 最適化計算
- グラフ作成
- CSV/JSON出力

したがって、ターボ機械設計システムにおける生成AI活用の本質は、LLM Agent + Tool実行 + 検証 + 状態管理である。

2. 最近のMultiAgent技術トレンド

2.1 AutoGen単体から、Microsoft Agent Framework / LangGraph型へ移行

以前は、Microsoft AutoGenのように、複数エージェントが会話しながらタスクを解く構成が中心だった。

しかし、2026年5月時点では、Microsoft AutoGenのGitHubリポジトリはMaintenance Modeと明記されており、新機能追加は行われず、今後はコミュニティ管理中心になると説明されている。MicrosoftはAutoGenからMicrosoft Agent Frameworkへの移行ガイドも公開している。

このため、今からターボ機械設計システムのような長期運用を前提とするシステムを作るなら、AutoGenだけを前提にするよりも、以下のような選択が現実的である。

プロトタイプ：
- AutoGen
- LangGraph
- CrewAI
- OpenAI Agents SDK

本格運用：
- Microsoft Agent Framework
- LangGraph
- 自社ワークフロー基盤 + MCP

Microsoft Agent Frameworkは、Pythonと.NETに対応し、エージェントとマルチエージェントワークフローの構築、オーケストレーション、デプロイを目的とするフレームワークとして公開されている。

ターボ機械設計に置き換えると、今後の現実的な流れは以下である。

AutoGenでマルチエージェントの考え方を試す
  ↓
小さな設計ワークフローを実装する
  ↓
状態管理、ツール実行、検証、ログ保存を追加する
  ↓
本格運用ではMicrosoft Agent FrameworkまたはLangGraph型へ移行する

2.2 「自由会話型Agent」より「明示的ワークフロー制御」が重要

最近の重要な変化は、複数エージェントを自由に会話させる方向から、ワークフローとして明示的に制御する方向へ移っていることである。

Microsoft Agent Frameworkのワークフロー機能では、Sequential、Concurrent、Handoff、Group Chat、Magenticといった複数のマルチエージェント・オーケストレーションパターンが提供されている。

LangGraphも、長時間実行、状態保存、Human-in-the-loop、短期・長期メモリ、障害後の再開などを重視している。

これはターボ機械設計に非常に相性がよい。

ターボ機械設計は、自由会話ではなく、以下のような工程管理に近い。

要求仕様整理
  ↓
平均線設計
  ↓
速度三角形チェック
  ↓
反動度・Mach数・流量整合チェック
  ↓
翼列・通路設計
  ↓
CFD条件作成
  ↓
CFD実行
  ↓
解析結果評価
  ↓
設計修正
  ↓
設計レビュー
  ↓
報告書作成

この流れを、ただの会話として処理すると危険である。

なぜなら、設計条件、単位、計算結果、ファイル、設計変更履歴、承認状態が曖昧になりやすいからである。

したがって、ターボ機械設計システムでは、以下のような状態管理が必要になる。

Project State:
- project_id
- case_id
- requirement
- design_parameters
- calculation_results
- cfd_conditions
- mesh_status
- cfd_result_status
- validation_status
- human_approval_status
- report_status
- git_commit_id

つまり、必要なのは単なるMultiAgent Chatではなく、状態を持った設計ワークフローである。

2.3 MCPにより、外部ツール接続が標準化されつつある

MCP、Model Context Protocolは、LLMアプリケーションと外部データソースやツールを接続するためのオープンプロトコルである。MCP仕様では、外部のResources、Prompts、Toolsなどを標準的に扱う構造が定義されている。

ターボ機械設計システムにおいて、MCPの重要性は非常に大きい。

なぜなら、ターボ機械設計では、LLMに全部を考えさせるのではなく、社内の既存ツールや設計コードを安全に呼び出す必要があるからである。

例えば、MCP Toolとして以下を定義できる。

MCP Tools:
- 1D turbine design tool
- velocity triangle calculator
- reaction calculator
- Mach number checker
- CFD pre-processor
- mesh generator
- CFD job launcher
- CFD convergence checker
- post-processing tool
- surrogate model predictor
- optimizer
- plotting tool
- report generator
- design database search
- past trouble case search
- design manual PDF search

この構成にすると、生成AIは物理計算の中身を曖昧に推測するのではなく、確定したツールを呼び出す役割になる。

すなわち、

LLMが計算する

ではなく、

LLM Agentが正しい設計ツールを選び、正しい入力で実行し、結果を解釈する

という構造になる。

ターボ機械設計のような高信頼性が必要な分野では、この方が圧倒的に安全である。

2.4 A2Aにより、エージェント間連携も標準化されつつある

A2A、Agent2Agent Protocolは、Googleが発表したエージェント間連携のためのプロトコルである。GoogleはA2Aを、MCPを補完するプロトコルと説明している。MCPがツールやコンテキストへの接続を扱うのに対し、A2Aは異なるプラットフォームやクラウド環境にまたがるエージェント同士の連携を扱う。

ターボ機械設計システムでは、A2Aは初期段階では必須ではない。

しかし、将来的に以下のような構成を作る場合には重要になる。

社内設計Agent
  ↔ CFDベンダーAgent
  ↔ 最適化Agent
  ↔ PLM/PDM Agent
  ↔ 調達・コスト評価Agent
  ↔ 試験データ管理Agent

このように、複数ベンダー、複数部門、複数システムをまたぐ段階になると、Agent間連携の標準化が効いてくる。

ただし、初期のターボ機械設計支援システムでは、まずMCP的なTool接続を優先すべきである。

優先順位は以下でよい。

第1優先：Tool接続
第2優先：状態管理
第3優先：Human-in-the-loop
第4優先：実行ログ・検証
第5優先：Agent間プロトコル

2.5 Human-in-the-loopは前提条件になっている

ターボ機械設計では、完全自動化よりも、重要判断だけ人間が承認する設計支援システムの方が現実的である。

LangGraphはHuman-in-the-loopを明示的に扱い、実行中の状態を人間が確認・修正できることを重視している。Microsoft Agent Frameworkも、長時間実行やチェックポイントによる再開を重視している。

ターボ機械設計において、人間承認が必要なポイントは以下である。

フェーズ	人間承認が必要な判断
要求仕様	出力、効率、コスト、制約条件
基本設計	段数、回転数、反動度、流量条件
詳細設計	翼形、喉面積、クリアランス
CFD評価	境界条件、メッシュ品質、収束性
最適化	目的関数、制約条件、採用候補
最終判断	採用設計案、リスク、量産性

特に、以下のような判断はLLMに完全委任すべきではない。

- 設計案の最終採用
- CFD結果の最終妥当性判断
- 境界条件の最終確定
- 量産設計への移行判断
- 安全性に関わる設計判断
- 顧客提出資料の最終承認

生成AIは、人間の判断を置き換えるのではなく、人間の判断に必要な材料を揃えるべきである。

2.6 Engineering Design Agent / Scientific Agentが研究トレンドになっている

2025年以降、一般的なチャットエージェントではなく、設計、解析、実験、最適化に特化したScientific AgentやEngineering Design Agentの研究が増えている。

例えば、Engineering Design向けのMulti-Agent研究では、AI設計エージェントを従来の工学設計ワークフローへ統合し、エンジニアやデザイナーと相互作用しながら、設計サイクルを加速する枠組みが提案されている。

また、NACA翼型設計を例にした研究では、Graph Ontologist、Design Engineer、Systems Engineerという専門エージェントを分け、知識グラフと設計ツールを使って設計候補を選定する構成が提案されている。

さらに、MDO、Multidisciplinary Design and Optimization向けのエージェント研究では、自然言語によるパラメトリックモデリング、RAGによる知識活用、工学ソフトウェアのオーケストレーション、性能検証、最適化を半自動化する方向が示されている。

これはターボ機械設計にかなり近い。

ターボ機械設計に置き換えると、以下のようなAgent構成になる。

Graph / Knowledge Agent
  → 設計基準、過去設計、論文、トラブル事例を構造化する

System Engineer Agent
  → 要求仕様、制約条件、評価指標を整理する

Turbine Design Agent
  → 平均線設計、速度三角形、段落設計を実行する

CFD Agent
  → 解析条件、メッシュ、ジョブ投入、収束確認を行う

Surrogate / Optimization Agent
  → サロゲートモデル生成、DOE、感度分析、最適化を行う

Verification Agent
  → 物理妥当性、設計基準違反、単位、境界条件を検査する

Report Agent
  → 設計根拠、比較表、レビュー資料を作成する

ここで重要なのは、Agentを人間組織の役割に対応させることである。

つまり、ターボ機械設計システムは、単なるAIチャットボットではなく、以下のような仮想設計組織になる。

設計主査
  ↓
平均線設計担当
  ↓
CFD担当
  ↓
最適化担当
  ↓
検証担当
  ↓
報告書担当

ただし、これを最初から複雑に作る必要はない。初期段階では、少数のAgentとToolで十分である。

2.7 Guardrails、Observability、Traceが必須になっている

最近の実務トレンドでは、エージェントを作るだけでなく、何を考え、どのツールを呼び、どこで失敗したかを追跡することが重視されている。

OpenAI Agents SDKでは、Handoffs、Guardrails、Tracing & Observabilityが主要機能として説明されている。

CrewAIも、Guardrails、Memory、Knowledge、Observabilityを含むマルチエージェント運用を前面に出している。

ターボ機械設計では、この考え方は特に重要である。

なぜなら、以下のようなミスが設計判断を大きく壊すからである。

- 単位ミス
- 流量条件の取り違え
- 絶対圧とゲージ圧の混同
- 温度単位の混同
- Mach数の異常
- 反動度の異常
- CFD境界条件の誤設定
- メッシュ品質不足
- 収束していないCFD結果の採用
- 古い設計基準の参照
- 過去ケースとの誤比較

したがって、ターボ機械設計システムには以下を入れるべきである。

- 全エージェント発話ログ
- ツール呼び出しログ
- 入力ファイル履歴
- 出力ファイル履歴
- 設計変更履歴
- CFD条件履歴
- エラーとリトライ履歴
- 人間承認ログ
- Gitコミット履歴
- 設計レビュー結果

このログがなければ、AIが出した設計案の根拠を追跡できない。

ターボ機械設計のような工学設計では、AIの答えそのものよりも、なぜその答えになったかを追跡できることが重要である。

3. ターボ機械設計システムの本命アーキテクチャ

ターボ機械設計システムに生成AIマルチエージェントを入れるなら、最初の本命構成は以下である。

Frontend
  Streamlit / React / VS Code UI

Orchestrator
  Microsoft Agent Framework または LangGraph

Knowledge Layer
  RAG + Knowledge Graph
  設計基準PDF、過去設計、解析報告書、トラブル事例

Tool Layer
  MCP Server
    - 1D turbine design tool
    - CFD pre/post
    - mesh generator
    - optimizer
    - surrogate model
    - plotting tool
    - report generator

Agent Layer
  - Requirement Agent
  - Meanline Design Agent
  - Blade / Flow Path Agent
  - CFD Agent
  - Optimization Agent
  - Verification Agent
  - Report Agent
  - Project Manager Agent

Governance Layer
  - Human approval
  - Trace
  - Validation
  - Git commit
  - Design review checklist

この中で特に重要なのは、Tool Layerである。

Agentを増やす前に、以下のToolを整備すべきである。

- 1D設計計算Tool
- 速度三角形計算Tool
- 反動度チェックTool
- Mach数チェックTool
- 流量整合チェックTool
- CSV出力Tool
- グラフ作成Tool
- 設計レポート生成Tool

なぜなら、設計システムの信頼性は、Agentの数ではなく、Toolの確実性で決まるからである。

4. 初期実装でおすすめの最小構成

最初から巨大なマルチエージェントにしない方がよい。

最初は以下で十分である。

User
 ↓
Main Orchestrator Agent
 ↓
Tool / Function
  - 1D設計計算
  - 速度三角形計算
  - 反動度チェック
  - Mach数チェック
  - CSV出力
  - グラフ作成
  - レポート生成

Agentとしては、最初は3体でよい。

1. Design Agent
   要求仕様から1D設計案を作る

2. Verification Agent
   物理式、単位、Mach数、反動度、流量整合性を確認する

3. Report Agent
   設計根拠と結果をまとめる

この構成で実現する最初の閉ループは以下である。

要求仕様
  ↓
1D設計
  ↓
検証
  ↓
レポート

この小さな閉ループを完成させることが最重要である。

その後に、以下を追加する。

第1段階:
既存の1Dターボ機械設計コードをTool化する

第2段階:
Requirement Agent + Design Agent + Verification Agent の3体で構成する

第3段階:
設計結果、CSV、グラフ、設計根拠を自動保存する

第4段階:
CFD Agentを追加する

第5段階:
Surrogate / Optimization Agentを追加する

第6段階:
設計DB、過去設計、PDF設計基準とRAG連携する

この順番がよい理由は、最初に設計計算と検証の基盤を作らないと、後からCFDや最適化を足しても、システム全体の妥当性が保証できないからである。

5. なぜ最初から階層型マルチエージェントにしなくてよいか

結論として、最初から階層型マルチエージェントにする必要はない。

むしろ、最初から本格的な階層型にしない方がよい。

初期段階では、以下の構成で十分である。

User
 ↓
Orchestrator / Project Manager Agent
 ↓
各専門Agent
 - Requirement Agent
 - 1D Design Agent
 - CFD Agent
 - Verification Agent
 - Report Agent

これは完全な階層型ではなく、軽い司令塔 + 専門エージェント群である。

この程度であれば実装しやすく、デバッグもしやすい。

一方、最初から以下のような構成にすると、急に複雑になる。

Chief Agent
 ├─ Design Manager Agent
 │   ├─ Meanline Agent
 │   ├─ Velocity Triangle Agent
 │   └─ Blade Design Agent
 ├─ Analysis Manager Agent
 │   ├─ CFD Agent
 │   ├─ Mesh Agent
 │   └─ Post Agent
 └─ Review Manager Agent
     ├─ Physics Check Agent
     └─ Cost Check Agent

この構成は大規模システムでは有効である。

しかし、初期開発では以下の問題が出る。

- 誰が最終判断するのか曖昧になる
- Agent間の通信が増える
- デバッグが難しくなる
- 同じことを複数Agentが言い始める
- プロンプト設計が複雑になる
- 状態管理が複雑になる
- Tool実行責任が曖昧になる
- エラー発生時の責任Agentが分かりにくい

したがって、初期段階で目指すべきなのは、階層構造の美しさではない。

目指すべきなのは、以下である。

- Toolが正しく動くこと
- AgentがToolを正しく呼べること
- 計算結果を検証できること
- 設計履歴が残ること
- 人間が承認できること
- レポート化できること

つまり、初期段階では、

階層型MultiAgent

ではなく、

状態管理つきワークフロー
+
軽いOrchestrator
+
専門Agent少数
+
強いTool群

で始めるのがよい。

6. ターボ機械設計システムにおけるAgentの役割分担

将来的には、以下のようなAgent構成が考えられる。

Agent	役割
Requirement Agent	要求仕様、制約条件、入力条件を整理する
Meanline Design Agent	平均線設計、段落設計、速度三角形を扱う
Blade / Flow Path Agent	翼列、流路、喉面積、反動度を扱う
CFD Agent	CFD条件作成、メッシュ、ジョブ投入、収束確認を扱う
Optimization Agent	DOE、感度分析、最適化、サロゲートモデルを扱う
Verification Agent	物理妥当性、単位、設計基準違反を検査する
Knowledge Agent	過去設計、PDF、設計基準、トラブル事例を検索する
Report Agent	設計根拠、比較表、レビュー資料を作る
Project Manager Agent	ワークフロー全体を制御する

ただし、初期段階では全部を作らない。

初期段階では、以下でよい。

- Design Agent
- Verification Agent
- Report Agent

CFD AgentやOptimization Agentは、後から追加すればよい。

7. 実装ロードマップ

Phase 1：既存設計コードのTool化

最初にやるべきことは、既存の1Dターボ機械設計コードをToolとして呼べるようにすることである。

Input:
- mass_flow
- inlet_pressure
- inlet_temperature
- outlet_pressure
- rotational_speed
- target_power
- stage_number
- constraints

Output:
- velocity_triangle
- reaction
- Mach_number
- pressure_distribution
- temperature_distribution
- efficiency_estimate
- warnings
- CSV
- JSON
- plots

この段階では、Agentは1体でもよい。

重要なのは、LLMから安定してToolを呼べることである。

Phase 2：検証Agentを追加する

次にVerification Agentを追加する。

Verification Agentは以下を確認する。

- 単位は正しいか
- 流量整合性はあるか
- Mach数が異常でないか
- 反動度が妥当か
- 圧力比が物理的におかしくないか
- 温度が非現実的でないか
- 設計制約を満たしているか
- 入力と出力の対応が取れているか

ここで重要なのは、Verification Agentに曖昧な感想を言わせるのではなく、チェック項目を明文化することである。

Phase 3：設計レポート自動生成

次にReport Agentを追加する。

Report Agentは以下を出力する。

- 入力条件
- 設計方針
- 計算結果
- 速度三角形
- 反動度
- Mach数
- 制約条件との比較
- 異常値の有無
- 次に試すべき設計案
- 人間レビュー項目

この段階で、設計システムはかなり実用的になる。

Phase 4：CFD Agentを追加する

1D設計と検証が安定した後で、CFD Agentを追加する。

CFD Agentは以下を担当する。

- CFD境界条件の作成
- メッシュ設定
- ジョブ投入
- 収束監視
- 結果読み込み
- 1D設計結果との比較
- 異常結果の検出

ここで重要なのは、CFD Agentを最初から入れないことである。

1D設計の入力・出力・検証が固まっていない状態でCFD Agentを入れると、システム全体が不安定になる。

Phase 5：Surrogate / Optimization Agentを追加する

次に、サロゲートモデルと最適化Agentを追加する。

このAgentは以下を担当する。

- DOE条件生成
- 複数ケース実行
- サロゲートモデル学習
- 感度分析
- 最適化
- Pareto front作成
- 設計候補のランキング

この段階になると、単なる設計支援ではなく、設計探索システムに近づく。

Phase 6：Knowledge Agentを追加する

最後に、設計基準PDF、過去設計、解析報告書、トラブル事例をRAGまたはKnowledge Graphで接続する。

Knowledge Agentは以下を担当する。

- 設計基準の検索
- 過去類似ケースの検索
- 過去トラブルの検索
- 関連論文の検索
- 設計判断の根拠提示

この段階で、システムは単なる計算自動化ではなく、設計知識を活用するAI設計システムになる。

8. 最終的な推奨構成

ターボ機械設計システムにおける推奨構成は以下である。

User
 ↓
Project Manager / Orchestrator Agent
 ↓
Design Workflow State
 ↓
Specialized Agents
  - Design Agent
  - Verification Agent
  - Report Agent
  - CFD Agent
  - Optimization Agent
  - Knowledge Agent
 ↓
MCP Tool Layer
  - 1D Design Tool
  - CFD Tool
  - Mesh Tool
  - Optimization Tool
  - Plot Tool
  - Report Tool
  - Database Search Tool
 ↓
Storage / Governance
  - outputs/project/case/run-id
  - CSV
  - JSON
  - plots
  - diagnostics
  - logs
  - human approvals
  - git commits

この構成では、LLMは設計計算の主役ではない。

LLMは以下を担当する。

- 設計プロセスの制御
- Tool選択
- 入力条件の整理
- 結果解釈
- 異常検出
- 次アクション提案
- レポート作成

物理計算は、既存の設計コード、CFD、サロゲート、最適化コードが担当する。

この分担が最も重要である。

付録A：階層型マルチエージェントをどう扱うべきか

A.1 階層型マルチエージェントとは何か

階層型マルチエージェントとは、Agentを単に横並びにするのではなく、上位Agentと下位Agentに分けて、組織構造のように制御する方式である。

例えば、以下のような構成である。

Chief Engineer Agent
 ├─ Design Manager Agent
 │   ├─ Meanline Design Agent
 │   ├─ Velocity Triangle Agent
 │   ├─ Blade Design Agent
 │   └─ Flow Path Agent
 ├─ Analysis Manager Agent
 │   ├─ CFD Setup Agent
 │   ├─ Mesh Agent
 │   ├─ Solver Agent
 │   └─ Post Processing Agent
 ├─ Optimization Manager Agent
 │   ├─ DOE Agent
 │   ├─ Surrogate Agent
 │   └─ Pareto Analysis Agent
 └─ Review Manager Agent
     ├─ Physics Check Agent
     ├─ Cost Check Agent
     ├─ Manufacturability Check Agent
     └─ Report Agent

この構成は、人間の設計組織に近い。

上位Agentは、方針決定、タスク分解、進捗管理、下位Agentへの指示を担当する。

下位Agentは、専門タスクを担当する。

A.2 階層型のメリット

階層型マルチエージェントには、以下のメリットがある。

- 大規模タスクを分解しやすい
- 役割分担が明確になる
- 専門Agentを増やしやすい
- 設計組織に近い構造を再現できる
- 複数案の並列検討がしやすい
- 上位Agentがレビュー役になれる
- プロジェクト管理と専門作業を分離できる

特に、以下のような大規模システムでは有効である。

- 1D設計
- 3D翼設計
- CFD
- 構造解析
- 振動解析
- 最適化
- コスト評価
- 製造性評価
- 試験データ評価
- レポート作成

これらを全部1つのAgentに任せるのは無理がある。

したがって、最終的には階層型が有効になる可能性は高い。

A.3 階層型のデメリット

一方で、階層型には明確なデメリットもある。

- 初期実装が重くなる
- Agent間通信が増える
- 状態管理が難しくなる
- デバッグが難しくなる
- プロンプト設計が複雑になる
- 責任境界が曖昧になる
- 上位Agentの判断ミスが全体に波及する
- 同じ検討を複数Agentが重複して行う
- 実行コストが増える
- レイテンシが増える

特にターボ機械設計システムでは、以下が問題になる。

- 誰が最終設計案を決めるのか
- CFD結果が悪い場合、誰が再設計を指示するのか
- 設計制約違反を誰が止めるのか
- 最適化AgentとVerification Agentの意見が割れた場合どうするのか
- 上位Agentが誤った設計方針を出した場合どう検出するのか

このため、階層型は「設計思想としては魅力的」だが、「初期実装としては重い」。

A.4 初期段階では階層型を避けるべき理由

初期段階では、まだ以下が固まっていない。

- 入力仕様
- 出力仕様
- ToolのI/O
- 設計データ形式
- 検証ルール
- エラー処理
- 保存ルール
- Human approvalの位置
- レポート形式

この状態で階層型にすると、構造だけ複雑になり、実体が伴わない。

結果として、以下が起こりやすい。

- Agentはたくさんいるが、Toolが弱い
- 会話は長いが、計算結果が信用できない
- レポートは出るが、根拠が追えない
- 設計案は出るが、検証が甘い
- エラー時にどこを直せばよいか分からない

これは避けるべきである。

初期段階では、まず以下を固めるべきである。

- 1D設計Tool
- 検証Tool
- 出力保存
- 設計ログ
- レポート生成

その後で、Agentを増やせばよい。

A.5 階層型を導入すべきタイミング

階層型マルチエージェントは、以下の段階で導入すればよい。

- 1D設計、CFD、最適化、サロゲート、レポートが全部つながった
- 設計ケースが大量に増えた
- 複数案を並列に評価したい
- CFD担当、最適化担当、レビュー担当を明確に分けたい
- 人間の設計組織のように役割分担したい
- 設計レビューと設計実行を分離したい
- プロジェクト単位で進捗管理したい

つまり、階層型は初期構築用ではなく、スケールアップ用である。

初期構成は以下でよい。

User
 ↓
Main Orchestrator Agent
 ↓
Design Agent
Verification Agent
Report Agent
 ↓
Tool Layer

拡張後は以下にする。

User
 ↓
Chief Engineer Agent
 ↓
Design Manager Agent
Analysis Manager Agent
Optimization Manager Agent
Review Manager Agent
 ↓
Specialized Agents
 ↓
Tool Layer

この順番が安全である。

A.6 ターボ機械設計における階層型の完成形

将来的な完成形は以下のようになる。

Chief Engineer Agent
  - プロジェクト全体の設計方針を管理
  - 顧客要求と設計制約を統合
  - 最終レビュー前の意思決定を整理

Requirement Manager Agent
  - 要求仕様を整理
  - 入力条件の不足を検出
  - 設計制約を構造化

Design Manager Agent
  - 平均線設計の方針を決定
  - 段数、反動度、速度三角形の整合を確認
  - 下位Design Agentへ指示

Meanline Agent
  - 平均線設計計算を実行
  - 段落ごとの圧力、温度、速度を出力

Velocity Triangle Agent
  - 静翼、動翼の速度三角形を作成
  - 周速、絶対速度、相対速度を確認

Blade / Flow Path Agent
  - 翼列、流路、喉面積、ピッチ、コードを扱う

CFD Manager Agent
  - CFD解析方針を決定
  - 解析対象ケースを選定
  - CFD Agent群を制御

Mesh Agent
  - メッシュ条件を作成
  - メッシュ品質を確認

Solver Agent
  - CFDジョブを投入
  - 収束状況を監視

Post Agent
  - CFD結果を処理
  - 圧力分布、Mach数分布、損失を整理

Optimization Manager Agent
  - DOE、サロゲート、最適化方針を決定

Surrogate Agent
  - サロゲートモデルを学習
  - 予測精度を評価

Optimization Agent
  - 最適化計算を実行
  - Pareto解を抽出

Review Manager Agent
  - 設計レビュー観点を整理
  - Verification Agent群を制御

Physics Check Agent
  - 物理妥当性を確認

Cost Check Agent
  - コスト、製造性、部品点数を確認

Report Agent
  - 設計根拠、比較表、レビュー資料を作成

これは非常に強力な構成である。

ただし、最初からここを目指して実装すると重すぎる。

まずは小さく始めて、必要になったら階層化するのが正しい。

A.7 階層型にする場合の設計原則

階層型を導入する場合は、以下の原則を守るべきである。

1. 上位Agentは計算しない
   方針決定、タスク分解、レビューに集中する

2. 下位Agentは専門タスクに集中する
   1つのAgentに複数の責任を持たせすぎない

3. Tool実行責任を明確にする
   どのAgentがどのToolを呼ぶかを固定する

4. 状態は中央管理する
   Agentごとに勝手に状態を持たせない

5. Verification Agentを独立させる
   設計Agent自身に自己検証だけを任せない

6. Human approval pointを明確にする
   どこで人間が承認するかをワークフローに組み込む

7. 全Tool呼び出しをログ化する
   後から設計根拠を追跡できるようにする

8. レポートは自動生成する
   設計判断の根拠を人間が確認できる形にする

特に重要なのは、Verification Agentを独立させることである。

Design Agentが作った設計案を、別のVerification Agentがチェックする。

これは、人間の設計組織における設計レビューと同じである。

A.8 階層型マルチエージェントの結論

階層型マルチエージェントは、最終的には有効である。

しかし、初期段階では不要である。

初期段階では、以下で始めるべきである。

状態管理つきワークフロー
+
軽いOrchestrator
+
Design Agent
+
Verification Agent
+
Report Agent
+
強いTool群

その後、CFD、最適化、サロゲート、Knowledge Agentが増えた段階で、階層化すればよい。

つまり、結論は以下である。

最初から階層型にしない。
ただし、将来の階層化を前提に、責任分担と状態管理だけは最初から設計しておく。

これが、ターボ機械設計システムにおける最も現実的なマルチエージェント導入方針である。

【マルチエージェント】生成AIマルチエージェントをターボ機械設計システム構築に活用する技術トレンドと実装方針＠2026/5

要旨