DUCTILE: Agentic LLM Orchestration of Engineering Analysis in Product Development Practice

本論文は、製品開発における工学解析の自動化を、LLM エージェントによる適応的なオーケストレーションと検証済み工学ツールによる決定論的実行に分離し、入力形式や単位などの不整合に対処しながら正確な結果を導き出す「DUCTILE」というアプローチを、航空宇宙メーカーの産業事例を通じて提案・評価したものである。

要約

この論文は、**「エンジニアリング（技術開発）の現場で、AI がどうやって『頼れる部下』として働けるか」**という新しい方法を提案したものです。

タイトルにある「DUCTILE（ダクタイル）」とは、金属の**「延性（しなやかさ）」を意味します。硬くて壊れやすい従来の自動化システムではなく、「しなやかで、状況に合わせて曲がれる」**新しい自動化の考え方です。

以下に、難しい専門用語を排し、身近な例え話を使って解説します。

---

1. 従来の問題点：「硬いロボット」の悲劇

これまでのエンジニアリングの自動化は、**「硬いロボット」**のようなものでした。
例えば、料理のレシピを自動化する場合、従来のシステムは「材料が A なら B を混ぜる」というルールを厳格に守ります。

• ある日、材料の袋の形が変わった（ファイル形式の変更）。
• 単位が「グラム」から「オンス」に変わった。
• 材料の名前が「りんご」から「アップル」に変わった。

このように、少しの「変化」が起きただけで、硬いロボットは**「エラー！エラー！動けない！」とパニックを起こして止まってしまいます。エンジニアは、このロボットを直すために、本来やるべき「美味しい料理（製品開発）」ではなく、「ロボットの修理（データの手直し）」**に時間を取られてしまいます。

2. DUCTILE の解決策：「賢いマネージャー」の登場

この論文が提案する「DUCTILE」は、硬いロボットではなく、**「経験豊富なマネージャー（AI エージェント）」**を雇うようなものです。

• 役割の分担：
  • AI マネージャー（しなやか）： 指示書（設計書）を読み、状況を見て「あ、材料の袋が変わったね。じゃあ、この新しい袋から中身を取り出すように手順を変えよう」と柔軟に判断します。
  • エンジニアの道具（堅牢）： 実際の計算や作業は、昔から使われていて信頼性の高い「計算機」や「ツール」に任せます。AI は計算そのものをするのではなく、「誰に、何を、いつ頼むか」を指示するだけです。

【例え話：料理の現場】

• 従来の自動化： 「卵を割る」のがルールなら、卵が「殻付き」で来ないと動かない。
• DUCTILE： 「卵を割る」のが目的。卵が「殻付き」でも「殻なし」でも、AI が「あ、殻付きだ。まずは殻を剥く手順を追加しよう」と判断し、その後に「殻を剥いた卵」を信頼できる料理人（既存のツール）に渡して料理させます。

3. このシステムのすごいところ（3 つのポイント）

① 「しなやかさ」で変化に対応

航空機メーカーの実際のテストでは、以下の 4 つの「変化」が起きました。

1. データの形式が「JSON」から「YAML」に変わった。
2. 単位が「メートル」から「インチ」に変わった。
3. 部品の名前が「左/右」から「ポート/スターボード」に変わった。
4. 計算の掛け数が 1.04 倍に修正された。

従来のシステムなら全部止まりますが、この AI マネージャーは**「あ、これらは仕様変更だね。手順を調整しよう」**と瞬時に判断し、すべて正しく処理しました。

② 「人間が最終責任を持つ」仕組み

AI が勝手に全部やるわけではありません。

• AI： 「私はこう考えて、こう手順を変えました。実行しますか？」と提案します。
• 人間（エンジニア）： 「よし、その判断で OK。実行して」と承認します。
• AI： 承認されたら、信頼できるツールを使って実行し、結果を報告します。

これにより、**「AI が間違っても、人間がチェックしているから安全」**という、航空宇宙業界が求める厳格な基準（安全性）を満たしています。

③ 2 人のエンジニアでテスト

このシステムは、2 人の異なるエンジニアに試されました。

• エンジニア A： 「全部任せるよ！」と丸投げして、結果だけ確認。
• エンジニア B： 「一つずつ教えて、確認しながら進めて」と、ステップバイステップで監視。

どちらのスタイルでも、AI は同じように正しく作業を完了しました。つまり、「AI に任せるか、AI と一緒にやるか」を選べるという柔軟性があります。

4. 注意点と未来

この論文は、**「AI がエンジニアを楽にする」という希望と同時に、「新しいリスク」**も指摘しています。

• 良い点： 面倒なデータの手直しから解放され、エンジニアは「本当に重要な判断」や「創造的な仕事」に集中できる。
• 懸念点： AI に任しすぎると、エンジニアが「なぜそうなるのか」という本質的な理解を失う恐れがある。また、AI の指示を常にチェックする「監視役」としての負担が、逆に疲れるかもしれない。

まとめ

この論文は、**「AI を『魔法の杖』ではなく、『状況を読み解く賢いアシスタント』として使い、人間が最終的に責任を持つ」**という、現実的で安全な自動化の未来を提案しています。

「硬くて壊れやすい自動化」から、「しなやかで人間と協力する自動化」へ。
それが「DUCTILE（しなやかさ）」の考え方です。

技術概要

この論文は、航空宇宙産業における製品開発プロセスにおける「工学分析の自動化」が抱える課題と、それを解決するための新しいアプローチ「DUCTILE」を提案・検証したものです。以下に、論文の技術的要点を問題、手法、貢献、結果、意義の観点から日本語で詳細に要約します。

1. 背景と課題 (Problem)

製品開発、特に航空宇宙分野の工学分析では、エンジニア、データ、手法、プロセス、専門ツールが複雑に絡み合っています。従来の自動化（スクリプトや PIDO プラットフォームなど）は、ツール間のインターフェース、データ形式、ドキュメント化されたプロセスが厳密に定義されていることを前提としています。

しかし、実際の開発現場では以下のような要因により、これらの前提が頻繁に変化します。

• ツールのアップデート
• 要件の変更
• 組織的な変化
• 異なるチームからのデータ受け渡し（形式や単位の不一致など）

従来の決定論的（Deterministic）な自動化システムは、これらの「変異（Variability）」に対して**脆い（Brittle）**という欠点があります。入力データが少し変わるだけでパイプラインが破綻し、エンジニアは工学判断そのものよりも、データの整形やツールの調整といった「データ・ワーリング（Data Wrangling）」に膨大な時間を費やすことになります。既存の知識ベース工学（KBE）やワークフロー管理システムは、事前に定義されたルールやオントロジーに依存しており、予期せぬ変化への適応が困難です。

2. 提案手法：DUCTILE (Methodology)

この課題に対し、著者らはDUCTILE（Delegated, User-supervised Coordination of Tool- and document-Integrated LLM-Enabled）という、LLM（大規模言語モデル）エージェントを活用したオーケストレーション手法を提案しました。

核となる概念：

• 適応的オーケストレーションと決定論的実行の分離:
  • LLM エージェント: 文書化された設計慣習を読み解き、入力データを検査し、処理パスを適応的に調整する「適応層」を担当します。
  • 検証済み工学ツール: 実際の計算やデータ処理は、エンジニアが従来から使用している検証済みで信頼性の高いツール（決定論的）に委ねます。
  • エージェントはツールを置き換えるのではなく、エンジニアの代わりにツールを呼び出し、コードを生成・実行します。

技術的基盤:

• 思考モード（Thinking Mode）: エージェントが回答を確定する前に、自己批判や代替案の検討を行う「思考の草稿（Scratchpad）」を使用し、曖昧な状況や予期せぬ入力への対応力を高めます。
• ツール呼び出し（Tool Calling）: エージェントは外部のツール（API、CLI、データベースなど）を呼び出す構造を持ち、トレーニングデータに含まれない最新の情報や組織固有のツールを動的に利用します。
• 人間による監督（Human-in-the-loop）: エージェントは計画を立てて実行しますが、最終的な承認と工学判断は人間（エンジニア）が行います。これにより、航空宇宙の認証基準（Traceability, Auditability）を遵守します。

要件（Requirements）:
論文では、このアプローチが満たすべき 12 の要件（R1-R12）を定義しています。これには、結果の検証可能性（Inspectability）、再現性（Reproducibility）、追跡可能性（Traceability）、データガバナンス、そして「pass-k」メトリクスによる信頼性評価などが含まれます。

3. 主要な貢献 (Key Contributions)

1. DUCTILE フレームワークの提案: 工学分析タスクにおける LLM ベースのエージェント自動化の開発、実行、評価のための体系的なアプローチを提示しました。
2. 産業実証ケーススタディ: 航空宇宙メーカー（GKN Aerospace）における実際の構造強度評価タスク（タービン後部構造：TRS）で手法を適用し、以下の 4 つの入力変異に対して従来の自動化が破綻する状況でも、エージェントが正常に処理できることを実証しました。
   • ファイル形式の変更（JSON → YAML）
   • 単位系の不一致（SI → 英制）
   • ノード命名規則の変更（Port/Starboard → Left/Right）
   • 手法の変更（Fx 力に対する 1.04 倍の補正係数の適用）
3. オープンな評価基盤: 使用されたケース、ツール、評価スクリプトをライセンスなしで公開し、他の研究者による再現と改善を可能にしました。

4. 結果 (Results)

• 変異への対応: エージェントは、従来のスクリプトでは手動介入やコード修正が必要だった 4 つの変異をすべて検知し、適切な処理パス（パース、単位変換、マッピング、補正係数の適用など）を自動的に生成・実行しました。
• 信頼性の評価: 独立した 10 回の試行において、すべてのランが専門家が定義した受入基準（定量的な許容誤差と定性的なチェック）をクリアしました（Pass-k メトリクスにおける k=10）。
• 異なる監督スタイルへの適応: 2 名の異なるエンジニア（1 名はタスク全体を委任、もう 1 名はステップごとの逐次確認）がエージェントを使用しましたが、両者とも同じ正確な結果を導き出すことができました。これは、エージェントが人間の監督スタイルに適応できることを示しています。
• 透明性: エージェントの思考プロセス、ツール呼び出し、生成されたコードはすべて可視化され、エンジニアが監査・承認することが可能でした。

5. 意義と考察 (Significance)

• 工学自動化のパラダイムシフト: 従来の「ルールベースの硬直した自動化」から、「LLM による適応的オーケストレーションとツールによる厳密な実行の分離」という新しいモデルを確立しました。これにより、製品開発の進化に伴うワークフローの変化に対して、自動化システムが柔軟に対応できるようになります。
• エンジニアの役割の変化: 単純なデータ整理やツール操作から解放され、より高次な工学判断や設計意思決定にリソースを集中させる可能性を示唆しています。
• リスクと課題:
  • 過信のリスク: エージェントが「有能に見える」ことで、エンジニアが物理的な理解を怠るリスク（Superficial understanding）があります。
  • 監督の負担: 自動化が「退屈な作業」を減らす一方で、AI の出力を監視・検証する新しい役割がエンジニアに課され、それが疲弊（Exhaustion）を招く可能性も指摘されています。
  • ドキュメントの重要性: エージェントは文書化された知識に依存するため、組織内の暗黙知（Tacit Knowledge）を形式知として文書化する投資が不可欠であることが示されました。

結論:
DUCTILE アプローチは、航空宇宙のような安全性が極めて重要な分野において、LLM エージェントを「自律的な意思決定者」ではなく、「人間に代わってツールを操る適応的なオーケストレーター」として位置づけることで、既存の検証済みツールとの互換性を保ちつつ、入力変異に対する堅牢性を実現する有効な手段であることを示しました。