1. アーキテクチャ設計の基本方針
optimize_flex のアーキテクチャは、単なるコード整理ではなく、 研究現場で実際に起こる混乱を防ぐための設計として構築されています。
設計の中心にある方針は、次の 3 点です。
- 最適化アルゴリズムとモデルを分離する
- モデルの「所在」をフレームワークから隠蔽する
- 途中で人間が介入できる余地を残す
2. optimize_flex の多層構造
optimize_flex は、明確な責務分離を行った多層構造を持ちます。
- アプリケーション層：optimize_xxx.py
- mf（middle framework）層：optimize_xxx_mf.py
- lib 層：optimize_xxx_lib.py
- 最適化アルゴリズム層：tkFit_mxy_flex
- 最適化制御層：tkoptimize_flex
- 機械学習・サロゲート層：tkmlr
この分離により、ある層を変更しても他の層が壊れにくい構造になっています。
3. アプリケーション層（optimize_xxx.py）
アプリケーション層は、最適化そのものではなく、 「研究シナリオの制御」を担当します。
- CLI 引数の定義
- mode（plot / sim / fit / scan 等）の切り替え
- 結果の可視化
- 中間結果の保存
この層には、
- 最適化アルゴリズムの詳細
- 数値計算の実装
は一切書きません。
そのため optimize_mup / optimize_peakfit / optimize_ATLAS は、 見た目が似ていても中身のモデルは全く異なる という状態が成立します。
4. mf 層（optimize_xxx_mf.py）の役割
mf 層は、optimize_flex の中核となる層です。
この層の役割は一言で言えば、
「どんなモデルであっても、最適化可能な形に変換する」
ことです。
4.1 モデルの所在を吸収する
mf 層は、次の違いをすべて内部で吸収します。
- Python 内部モデル
- 可変パラメータ数モデル
- 外部計算エンジン（ATLAS 等）
tkFit や tkoptimize_flex は、 それらの違いを一切知りません。
4.2 評価関数の正体
mf 層が提供するのは、最終的に次の形です。
f(x) → y_list
その内部で、
- 内部モデルを呼ぶ
- 外部プロセスを実行する
- 結果を読み取る
- 補間・照合を行う
といった複雑な処理が行われます。
しかし最適化アルゴリズムから見れば、 それは「1 回の評価」に過ぎません。
5. lib 層（optimize_xxx_lib.py）
lib 層は、mf 層が肥大化するのを防ぐために存在します。
この層には、
- ATLAS の入力ファイル生成
- ログファイルの解析
- 実測データとの対応付け
- 補間アルゴリズム
といった、 外部世界に強く依存するコード だけを書きます。
その結果、
- mf 層は最適化に集中できる
- 外部エンジンが変わっても lib を差し替えればよい
という構造が成立します。
6. 最適化アルゴリズム層（tkFit_mxy_flex）
tkFit_mxy_flex は、 最適化アルゴリズムそのもの を実装する層です。
- SIMPLEX
- SciPy minimize
- GA / Swarm
- REMC
- サロゲート最適化
これらはすべて、 同一の minimize() インターフェース で呼び出されます。
評価関数が遅い・ノイジー・非連続であっても、 アルゴリズム側はそれを前提として動作します。
7. 最適化制御層（tkoptimize_flex）
tkoptimize_flex は、
- 履歴管理
- 途中停止・再開
- ログ保存
- 可視化フック
を担当します。
この層があることで、
- 計算を途中で止められる
- 探索過程を後から解析できる
- 同じ条件を再現できる
という「研究コードとして重要な性質」が保証されます。
8. 機械学習・サロゲート層（tkmlr）
tkmlr は、optimize_flex における 知的探索を担当する層 です。
外部エンジンのように評価コストが高い場合、
- 履歴データを学習
- 代理モデルを構築
- 評価点を賢く選択
することで、探索効率を大きく向上させます。
重要なのは、 tkmlr は必須ではない という点です。
必要になったときにだけ、 自然に組み込める 設計になっています。
9. 3 種類の optimize_xxx が共存できる理由
optimize_mup、optimize_peakfit、optimize_ATLAS は、
- モデルの性質
- 評価関数の所在
- パラメータ数
がすべて異なります。
それでも同一フレームワークで動作するのは、
「違いはすべて mf 層以下で吸収されている」
からです。
10. まとめ
optimize_flex のアーキテクチャは、
- 拡張しやすい
- 壊れにくい
- 研究現場に適している
という特徴を持ちます。
次のページでは、 このアーキテクチャの上で動作する 各個別最適化プログラムの具体像 を解説します。