【Codex App Server】Codex App Serverをタービン設計システムに組み込む ― LLMを「計算機」ではなく「設計エージェント」として使う：2026/8/11

未分類
2026.08.11

1. はじめに

LLMを工学設計に利用しようとすると、最初に一つの疑問が出てくる。

「タービン性能計算や最適化そのものをLLMに計算させるのか？」

結論から言えば、必ずしもそうではない。

むしろ工学設計で有望なのは、

LLMに物理計算をさせるのではなく、既存の解析プログラムやPython、ファイル、最適化アルゴリズムを操作する“設計エージェント”としてLLMを使う

という考え方である。

この仕組みを実現する選択肢の一つが、OpenAIの Codex App Server である。

本稿では、Codex CLIとの違い、Codex App Serverの役割、ローカル環境への配置、既存タービン解析コードとの接続、そして実際のシステム構成までを整理する。

2. Codexに何をさせるのか

まず重要なのは、LLMと数値計算プログラムの役割を分離することである。

例えばユーザーが、

「この設計点の前後を探索して、効率が最大になる条件を探して」

と指示したとする。

このときLLM自身に大量のタービン性能計算をさせる必要はない。

理想的な処理は次のようになる。

ユーザー
   ↓
「最高効率となる設計条件を探して」
   ↓
Codex
   ↓
現在の計算結果を確認
   ↓
次に計算する条件を判断
   ↓
input.datを作成・変更
   ↓
既存のタービン解析コードを実行
   ↓
result.csvを読む
   ↓
結果を評価
   ↓
次の解析条件を決定
   ↓
再計算
   ↓
……
   ↓
最良設計を報告

つまり、

Codex = 設計を進める頭脳

既存解析コード = 物理現象を計算する専門家

という役割分担になる。

3. LLMがアルゴリズムそのものを計算するわけではない

例えば「データをシフトさせて相関最大位置を探す」という処理を考える。

LLMが大量の数値を一つ一つ内部で計算する方法も理論的には考えられるが、工学システムとしては望ましくない。

Codexなら、

  1. 問題を理解する
  2. 適切なアルゴリズムを考える
  3. 必要ならPythonコードを書く
  4. Pythonを実行する
  5. 結果を確認する
  6. 必要ならコードや条件を修正する
  7. 再実行する
  8. 結果を解釈する

という処理ができる。

例えば、

for shift in range(-100, 101):
    correlation = calc_correlation(data1, data2, shift)

のようなコードを生成し、Pythonに実際の数値計算をさせる。

したがって、

LLM
  ↓
アルゴリズムを考える
  ↓
Pythonを書く
  ↓
Pythonが計算する
  ↓
結果をLLMが読む

という関係になる。

これはタービン設計でも同じである。

4. Codex CLIとCodex App Serverの違い

Codex App Serverは、Codex CLIとまったく別の製品というより、Codexのエージェント機能を別のアプリケーションから利用するためのインターフェースと考えると分かりやすい。

通常のCodex CLIでは、

人間
 ↓
Terminal / VS Code
 ↓
Codex
 ↓
ファイル編集
Python実行
Shell実行

という使い方になる。

一方、Codex App Serverでは、

自作アプリ
 ↓
Codex App Server
 ↓
Codex
 ↓
ファイル編集
Python
Shell
解析コード

となる。

つまり、人間が直接Codexを操作するのではなく、

自分で開発したタービン設計システムがCodexを操作できる

ようになる。

OpenAIの公式仕様では、Codex App ServerはCodex VS Code extensionなどのリッチなインターフェースを動かすために利用されるインターフェースとして説明されている。

5. Codex App Serverの基本構造

Codex App Serverには主に、

  • Thread
  • Turn
  • Item

という3階層が存在する。

Thread

一連の設計作業全体に相当する。

例えば、

HP Turbine Stage Optimization

という設計案件を一つのThreadとして扱える。

Turn

ユーザーからの一回の指示と、それに対するCodexの処理である。

例えば、

「現在の設計点の±10%を探索してください」

が一つのTurnになる。

Item

Turnの中で発生する個々の処理である。

例えば、

User Message
Reasoning
Shell Command
File Edit
Python Execution
Agent Message

などである。

したがって、タービン設計では、

Thread
  │
  ├─ Turn
  │    ├─ ユーザー指示
  │    ├─ input.dat確認
  │    ├─ Python実行
  │    ├─ turbine.exe実行
  │    ├─ result.csv読込
  │    └─ Codexの回答
  │
  └─ Turn
       └─ 次の設計探索

という構造を作れる。

6. App Serverとの通信

Codex App Serverは、JSON-RPC 2.0に似た双方向通信を提供している。

標準ではstdioを利用し、newline-delimited JSON、つまりJSONLで通信できる。

したがってPythonアプリから、

Python Application
       ↓ stdin
Codex App Server
       ↓ stdout
Python Application

という非常にシンプルな構成も可能である。

WebSocket transportも存在するが、現時点の公式仕様ではexperimental/unsupported扱いであるため、最初のPoCではstdioを使うのが分かりやすい。

7. PythonからCodex App Serverを呼ぶ

概念的には次のようになる。

import subprocess
import json

codex = subprocess.Popen(
    ["codex", "app-server"],
    stdin=subprocess.PIPE,
    stdout=subprocess.PIPE,
    text=True
)

def send(data):
    codex.stdin.write(json.dumps(data) + "\n")
    codex.stdin.flush()

これだけでPython側からApp Serverプロセスを立ち上げられる。

最初にinitializeを行う。

send({
    "method": "initialize",
    "id": 1,
    "params": {
        "clientInfo": {
            "name": "turbine-design",
            "title": "Turbine Design System",
            "version": "0.1"
        }
    }
})

続いてThreadを作る。

send({
    "method": "thread/start",
    "id": 2,
    "params": {
        "cwd": r"D:\turbine_design"
    }
})

そしてCodexに仕事を依頼する。

send({
    "method": "turn/start",
    "id": 3,
    "params": {
        "threadId": thread_id,
        "input": [{
            "type": "text",
            "text":
            "result.csvを読み、最高効率となる設計条件を調べてください。"
        }]
    }
})

Codexからは、

turn/started
item/started
item/completed
turn/completed

などのイベントがストリーミングされる。

実際の実装ではresponseとnotificationが非同期に混在するので、request IDごとのresponse管理やイベントループを実装する必要がある。

8. 既存タービン解析プログラムをどう接続するか

ここが工学用途では最も重要である。

例えば既存の一次元タービン性能解析プログラムが、

turbine.exe

として存在するとする。

プロジェクトを例えば次のように構成する。

D:\turbine_design\

├─ AGENTS.md
├─ solver\
│    └─ turbine.exe
│
├─ input\
│    └─ input.dat
│
├─ output\
│    └─ result.csv
│
├─ scripts\
│    ├─ optimize.py
│    ├─ plot.py
│    └─ postprocess.py
│
└─ reports\

Codexに、

現在のresult.csvを確認してください。

効率改善の可能性がある設計変数を判断し、
必要であればinput.datを変更してください。

その後turbine.exeを実行し、
新しいresult.csvと旧結果を比較してください。

改善が見られる場合は探索を継続してください。

と指示する。

すると概念的には、

Codex
 ↓
result.csv
 ↓
結果を分析
 ↓
探索方針決定
 ↓
input.dat変更
 ↓
turbine.exe
 ↓
result.csv
 ↓
Codex
 ↓
次の探索条件

というループを形成できる。

9. Pythonによる最適化との組み合わせ

すべての探索点をCodexに考えさせる必要もない。

例えば、

  • Bayesian Optimization
  • Gaussian Process Regression
  • Genetic Algorithm
  • Differential Evolution
  • Gradient-based Optimization
  • DOE
  • Response Surface
  • Surrogate Model

などの既存アルゴリズムはPython側に担当させた方がよい。

構造としては、

                Codex
                  │
          「何を最適化するか」
                  │
                  ▼
            optimize.py
                  │
       ┌──────────┼──────────┐
       ▼          ▼          ▼
    Design A   Design B   Design C
       │          │          │
       └──────────┼──────────┘
                  ▼
             turbine.exe
                  │
                  ▼
             Results.csv
                  │
                  ▼
                Codex
                  │
        工学的意味を評価する

となる。

これなら数千ケースの計算をLLMに逐一判断させる必要がない。

10. Codexの本当の役割

この構成でCodexに期待するのは、単純な数値計算ではない。

むしろ、

「どの解析を実施するべきか判断する」

ことに価値がある。

例えば、

効率が低い
 ↓
Codex
 ↓
速度三角形を確認
 ↓
流入角が大きく変化している
 ↓
チョーク近傍の可能性を疑う
 ↓
追加の設計点を計算
 ↓
必要なら別のサロゲートモデルを提案

というような、設計者に近い判断である。

したがって、

Numerical Intelligence
        ↓
Python / Solver / CFD / FEM

Engineering Intelligence
        ↓
Codex

という分担を目指す。

11. さらにCFD・FEMへ拡張する

一次元解析だけに限定する必要はない。

将来的には、

                     Codex
                       │
        ┌──────────────┼──────────────┐
        ▼              ▼              ▼
    1D Performance    CFD            FEM
        │              │              │
        ▼              ▼              ▼
     Efficiency     Flow Field      Stress
     Mass Flow      Loss            Vibration
     Velocity       Shock           Flutter
        │              │              │
        └──────────────┼──────────────┘
                       ▼
                     Codex
                       │
                       ▼
                Design Decision

という統合設計システムまで発展させられる。

Codexは各解析ソルバーそのものを置き換えるのではなく、

複数の専門解析ソルバーを統括するエージェント

になる。

12. Codex App Serverはクラウドに置く必要があるのか

ここは誤解しやすい。

Codex App Server自体はローカルプロセスとして動かすことができる。

例えば、

社内Windows PC

Turbine Design UI
       │
       ▼
Codex App Server
       │
       ▼
Python
       │
       ▼
turbine.exe

という部分はローカル環境に構築できる。

しかし、

Codex App ServerとLLM本体は同じものではない。

App Serverはエージェントを動かすためのハーネスであり、推論を担当するモデルとの接続は別問題である。

したがって、「社内PCからインターネットへ一切接続できない」という完全閉域環境の場合、

Codex App Serverをローカルに置けば全部解決

とはならない。

LLMをどこで動かすかも設計しなければならない。

13. 閉域環境で考えられる構成

理想的にはLLM層を交換可能にする。

                    Turbine Agent
                         │
              ┌──────────┼──────────┐
              ▼          ▼          ▼
           OpenAI     Azure     Local LLM
                                   │
                                 Ollama

このような抽象化をしておけば、

開発環境ではOpenAI、

社内環境ではAzure OpenAI、

完全閉域環境ではローカルLLM、

という切り替えが可能になる。

ただし、Codex App Serverと任意のローカルLLMの組み合わせについては、使用するCodexのバージョン、model provider、認証方式、モデル能力などを確認する必要がある。

「Codex App Serverさえあれば、どのLLMでも完全互換で動く」

と考えるべきではない。

14. なぜ単純なOpenAI API呼び出しではないのか

通常のLLMアプリなら、

Application
 ↓
LLM API
 ↓
回答

で終わる。

しかし設計エージェントでは、

Application
 ↓
Codex
 ↓
ファイルを読む
 ↓
Shellを実行
 ↓
Pythonを実行
 ↓
解析コードを実行
 ↓
結果を読む
 ↓
判断
 ↓
さらに解析

という反復処理が必要になる。

この「Agent Loop」を実装済みの仕組みとして利用できることがCodex App Serverの大きな意味である。

15. セキュリティは非常に重要

工学設計システムへ導入する場合、Codexに無制限の権限を与えるべきではない。

Codex App Serverには、shell commandやfile modificationについてapprovalを要求する仕組みがある。

したがって実システムでは、

Codex
 ↓
「turbine.exeを実行したい」
 ↓
Permission / Approval
 ↓
許可
 ↓
実行

のような制御が可能である。

さらに実用システムでは、

  • 読み込み可能ディレクトリ
  • 書き込み可能ディレクトリ
  • 実行可能EXE
  • Pythonスクリプト
  • ネットワークアクセス
  • 計算時間
  • CPU/GPU使用量
  • CFDジョブ投入権限

などを制限するべきである。

特に設計システムでは、Codexに任意のOSコマンドを自由に実行させる構成より、

run_1d_solver()
run_cfd()
run_fem()
get_design_result()
update_design_variables()

のような許可された操作だけをTool/API化する方が安全である。

16. AGENTS.mdを設計ルールとして使う

Codexを工学設計へ導入するときには、単に、

「最適設計してください」

と指示するだけでは不十分である。

例えばAGENTS.mdに、

# Turbine Design Agent Rules

## Objective

Maximize turbine efficiency while satisfying all
mechanical and aerodynamic constraints.

## Rules

- Never modify turbine.exe.
- Input files may only be written under /input.
- Results shall be stored under /output.
- Always preserve previous calculation results.
- Do not overwrite validated baseline designs.
- CFD shall only be executed after 1D screening.
- FEM shall only be executed for shortlisted designs.
- Report all constraint violations.

などを記述する。

これにより、Codexに「タービン設計者として守るべき作業手順」を与えられる。

17. 推奨するシステムアーキテクチャ

最終的には次のような構成が有力である。

┌────────────────────────────┐
│      Turbine Design UI     │
│                            │
│ 「効率を改善して」          │
└─────────────┬──────────────┘
              │
              ▼
┌────────────────────────────┐
│      Agent Controller      │
│                            │
│  Codex App Server / Agent  │
└─────────────┬──────────────┘
              │
       ┌──────┼───────┐
       ▼      ▼       ▼
     Tools   Files   Python
       │
       ▼
┌────────────────────────────┐
│ Engineering Tool Layer     │
│                            │
│ run_1d_solver()            │
│ run_optimizer()            │
│ run_cfd()                  │
│ run_fem()                  │
│ evaluate_constraints()     │
└─────────────┬──────────────┘
              │
       ┌──────┼───────┐
       ▼      ▼       ▼
      1D     CFD     FEM
    Solver  Solver  Solver
       │      │       │
       └──────┼───────┘
              ▼
        Design Database
              │
              ▼
        Codex evaluates
              │
              ▼
         Next Action

この構成では、LLMと既存の工学解析資産を明確に分離できる。

18. 最初のPoCは小さく作る

いきなりCFDやFEMまで統合する必要はない。

最初は、

Codex
 ↓
input.dat変更
 ↓
1D Solver
 ↓
result.csv
 ↓
Codex
 ↓
結果評価

だけで十分である。

例えば設計変数を、

Nozzle Angle
Blade Angle
Pitch
Height
Reaction

の5変数程度に限定する。

そして、

「基準設計から効率を改善してください。ただし流量は±0.5%以内」

というタスクを与える。

これだけでも、

LLMが本当に“設計エージェント”として機能するのか

を評価できる。

19. 次の段階ではCodexに全部探索させない

PoCが成功したら、

Level 1
Codex → 1D Solver

Level 2
Codex → Python Optimizer → 1D Solver

Level 3
Codex
 ├→ 1D Solver
 ├→ Surrogate Model
 └→ Optimizer

Level 4
Codex
 ├→ 1D
 ├→ CFD
 ├→ FEM
 └→ Vibration

Level 5
Multi-Agent Turbine Design System

と段階的に高度化するのがよい。

特に大量のパラメータ探索はPythonや既存最適化アルゴリズムに任せ、

Codexには、

「どの解析をするべきか」

「結果に物理的な矛盾はないか」

「どの設計候補を次段階へ送るか」

「探索戦略を変更するべきか」

を判断させる。

これがLLMと数値最適化の適切な分業になる。

20. 最終的に目指せるもの

最終的にはユーザーが、

「この段落について、
現行設計と同等流量を維持しながら
効率を0.5ポイント改善する候補を探して。

強度・振動制約も確認して、
有望な3案を出して。」

と指示するだけで、

Codex
 ↓
既存設計を理解
 ↓
1D解析
 ↓
最適化
 ↓
候補抽出
 ↓
CFD
 ↓
強度解析
 ↓
振動解析
 ↓
結果比較
 ↓
追加解析
 ↓
設計案3案
 ↓
技術レポート

まで進められる可能性がある。

これは単なる「AIチャット付きタービン設計ソフト」ではない。

人間の設計者が行っていた、解析ツールの選択、条件設定、結果確認、再解析、比較、判断という一連の設計ワークフローそのものをAIエージェント化する

という発想である。

まとめ

Codex App Serverをタービン設計に導入するとき、最も重要なのは、

「Codexにタービンを計算させる」のではなく、「Codexにタービン設計作業を進めさせる」

という考え方である。

物理計算は、

  • 既存1D解析コード
  • CFD
  • FEM
  • Python
  • 最適化アルゴリズム
  • サロゲートモデル

に任せる。

Codexはその上位で、

Understand
   ↓
Plan
   ↓
Execute Tools
   ↓
Observe
   ↓
Evaluate
   ↓
Plan Again

というAgent Loopを担当する。

したがって、タービン設計システムの将来像は、

LLM = Engineering Brain

Codex App Server = Agent Harness

Python = Numerical / Optimization Layer

Existing Solvers = Physics Layer

Design Database = Engineering Memory

という階層構造になる。

このアーキテクチャなら、長年蓄積してきた既存の解析コードを捨てる必要はない。

むしろ、既存の1D性能解析、CFD、FEM、振動解析、最適化コードという専門技術資産を残したまま、その上にAIによる「設計判断・ツール選択・解析実行・結果評価」の層を追加できる。

Codex App Serverは、そのための有力なエージェント実行基盤の一つとして検討する価値がある。

コメント

タイトルとURLをコピーしました