# メタ設計——「自動化の次に来る設計の仕事」

**Week 15 補足資料｜データマイニング**

---

## 0. この資料の目的

Week 5〜14 で学んできた「特徴量エンジニアリングの自動化」の流れは、「人がデータを設計する手間をモデルが肩代わりする」方向に進んできた。では Week 15 で学ぶ LLM エージェントの設計は、この流れの「終点」なのかというと、違う。設計の仕事は消えておらず、**設計の対象が一段上のレイヤーに移動している**。この資料はその「移動」を整理し、現代の研究事例で確認する。

---

## 1. 特徴量エンジニアリングの進化史

1週目振り返り: {ref}`feature_engineering_history`

上記をベースに少し加筆したものを以下に示す。

```
【手動】数値・カテゴリを人が変換する（Week 5〜6）
  正規化・離散化・対数変換・one-hot
  人がドメイン知識に基づき「どの値を・どの形で渡すか」を決める

【手動】テキストの意味を人が定義・設計する（Week 7〜9）
  BoW、TF-IDF、形態素解析
  「重要な語とは何か」を人がルールで定める

【半自動】コーパスからモデルが表現を学習する（Week 10）
  word2vec：分布仮説に基づき、大量テキストから意味ベクトルを自動獲得
  人は「コーパスを用意する」「窓幅を決める」だけになった

【自動】end-to-end でモデルが特徴を内部化する（Week 11〜14）
  RNN / seq2seq + Attention / Transformer：大量データ + 大きいモデル
  「どんな特徴が有効か」をモデルが自分で発見する
  ─── この段階で「特徴量エンジニアリングは終わった」と言われることがあるが、そうではないのが実情。

【メタ設計】入出力・アーキテクチャ・システム全体を設計する（Week 15）
  何をモデルに渡すか、どのモデルをどう組み合わせるか、
  誰がいつどのツールを呼ぶかを人がドメイン知識に基づいて設計する
```

**前処理は消えたのではなく、設計の粒度が上がった。**
「個々の特徴量の値」を設計するのではなく、「システム全体の構造」を設計するようになった。

---

## 2. 「大きいモデルを学習させれば良い」は本当か

「自動化」フェーズの教訓：大量データで大きな Transformer を学習させると、個別の特徴量設計なしに多くのタスクが解けた。これは本当であり、GPT-4・Gemini・Claude のような汎用 LLM が実用化された背景でもある。

では、次の問題には同じアプローチが通用するか。

| 問題 | 「大きい Transformer」の限界 |
|:---|:---|
| 専門ドメインの複合データ（地震・気象・タンパク質） | 一般コーパスには構造的ドメイン知識が薄い |
| リアルタイム情報が必要なタスク | 学習カットオフ以降の知識がない |
| 長い計算・大規模なデータ処理 | 1 回の生成で全ては賄えない |
| 安全性・倫理的アラインメント | 任意のデータで学習すると有害出力が混入する |
| タスクが複数ステップの依存関係を持つ | 1 回の生成では全ステップを処理できない |

これらの限界に直面したとき、「もっと大きいモデルを学習させる」よりも先に問うべきことがある。

> **「このタスクの構造はどうなっているか。その構造に合ったシステム設計は何か。」**

これがメタ設計の問いである。

---

## 3. メタ設計とは何か——3 つの設計軸

メタ設計を「3 つの軸」で整理する。

- 例: [Scalable intermediate-term earthquake forecasting with multimodal fusion neural networks, 2025](https://www.nature.com/articles/s41598-025-93877-7)

### 軸1：入力設計——「何を・どの粒度で・どのモダリティを入れるか」

Week 5〜9 では「どの特徴量の値を入れるか」を設計していた。メタ設計では「どのデータソース・粒度・モダリティを組み合わせるか」を設計する。

| 問い | 例 |
|:---|:---|
| どのデータを入力に含めるか | 地震予測に「地質マップ」「時系列統計」両方を入れる |
| どの時間窓・空間粒度を使うか | 直近 365 日のデータか 10 日分か |
| 複数のモダリティをどう扱うか | テキスト + 画像 + 数値をそれぞれ別モデルで Encode してから融合 |

### 軸2：アーキテクチャ設計——「どのモデルをどう組み合わせるか」

Week 11〜14 では「Transformer でよい」という判断が多かった。メタ設計では「このデータはどのモデルが最も適切か」を設計する。

| 問い | 例 |
|:---|:---|
| データの性質に合ったモデルは何か | 画像 → CNN / ResNet、時系列 → LSTM、関係性 → GNN、テキスト → Transformer |
| 各モデルの出力をどう融合するか | 早期融合（Early Fusion）か後期融合（Late Fusion）か |
| ドメイン制約をどこに組み込むか | 物理法則を損失関数に加える、幾何学的制約を出力層の設計に反映する |

### 軸3：処理フロー設計——「どの順序で・どこで判断して・どこを固定するか」

複数の処理ステップをどう順番につなぐか、どの判断をどのタイミングで行うかを設計する軸。Week 5〜9 の DM では「データ収集→前処理→特徴量抽出→モデル学習→評価」という固定の流れを人が事前に設計していた。メタ設計では、この「流れ自体」が設計の対象になる。

| 問い | 固定フローの例 | 動的フローの例 |
|:---|:---|:---|
| 処理の順序をどうするか | 常に検索→生成の順で実行 | クエリの種類に応じて順序を変える |
| どこで条件分岐を入れるか | なし（全クエリを同一フローで処理） | 「この結果で十分か？」を判断して必要なら再検索する |
| どの処理を並列実行できるか | 順次処理のみ | 調査・分析・要約を複数エージェントで並列実行する |
| フロー自体を誰が決めるか | 人間が設計時に固定する | LLM がタスクを読んで実行時に動的に決める |

プログラミングで言えば「if-else をどこに置くか、誰が評価するか」という設計判断と同じである。この軸は RAG を例に以下の節で掘り下げていく。

````{tip}
```
現状のシステムを動かしたとき、
  → どこで「設計の前提」が崩れたか？
  → そこにドメイン知識はどう関係しているか？
  → その知識をシステムの「どの層」に反映するか？
```

この問いの繰り返しがメタ設計のプロセスである。
````

---

## 4. 事例1：RAG → Agentic RAG → マルチエージェントの変遷

### RAG: 軸1 + 軸3 の設計判断例

RAG は「Transformer を大きくする」という方向ではなく、「知識をシステムの外に出す」という設計変更だった。

- 軸1(入力設計): どのデータを入力に含めるか
- 軸3(処理フロー設計): 検索するか

```
設計の判断：
  「知識を LLM の重みに焼き付けるな。
   検索系（ベクトル DB）と生成系（LLM）を分けろ」

        ↓ この判断の根拠は？

ドメイン知識：
  - LLM の知識はカットオフで止まる
  - 社内・専門データは事前学習コーパスにない
  - ハルシネーションは「記憶と検索が混在している」構造に起因する

        ↓ メタ設計の成果

固定処理フロー：
  クエリ → ベクトル検索 → 上位 k 件 → LLM → 回答
```

### Agentic RAG: 軸3 を深化

処理フローが「固定」から「動的」に変わった——これは軸3の設計変更である。

- 軸3(処理フロー設計): 検索するか・しないかを誰が決めるか

```
RAG の残課題：
  「常に検索する」という固定フローは非効率であり、
  複数の検索や再検索が必要なクエリに対応できない

        ↓ メタ設計の更新

「いつ・どの DB を・何回検索するかを LLM に判断させる」

  クエリ
    → LLM が「検索が必要か？」を判断
    → 必要なら [RAG ツール] を選択・呼び出す
    → 結果を読んで「再検索か回答か」を判断
    → 回答
```

### マルチエージェント: 軸2 + 軸3 の組み合わせ

「どの専門性をどの LLM インスタンスに担わせるか」——これは軸2（アーキテクチャ設計）の LLM 版である。

- 軸2(アーキテクチャ設計): データの性質に合ったモデルは何か
- 軸3(処理フロー設計): タスクをどこで分割するか

```
Agentic RAG の残課題：
  「単一エージェントのコンテキスト窓には限界がある」
  「調査と分析と要約を1つのエージェントにやらせると品質が下がる」

        ↓ メタ設計の更新

「タスクの専門性に応じてエージェントを分割する」

  ユーザーの問い
      ↓
  オーケストレーター（指揮役 LLM）
      ├─ 調査エージェント（Web 検索・RAG）
      ├─ 分析エージェント（コード実行）
      └─ 要約エージェント（最終生成）
      ↓
  回答
```

---

## 5. 事例2（自然科学）：地震予測 SafeNet（2025）

**Kimura, T. et al.** "Scalable intermediate-term earthquake forecasting with multimodal fusion neural networks," *Scientific Reports* 15 (2025).  
https://www.nature.com/articles/s41598-025-93877-7

### 問題設定

中国国内を 4°×4° の 85 地域に分割し、ある日 t を起点に「t+1 から 1 年間に発生する最大マグニチュードのクラス（4 クラス）」を予測する。

### 素朴なアプローチの限界

「大量の過去地震記録を 1 つの Transformer に与えて学習させる」という方針は理論上可能だが、次の問題が残る。

- **地震データは複数の異なる構造を持つ**：地質マップ（2D 画像）、カタログ指標（時系列の統計値 282 次元）、空間的な地域間の相関——これらは同じ Transformer トークンとして並べるだけでは構造が失われる
- **粒度の問題**：地質マップは静的な空間背景、時系列統計は直近の動的変化——異なる時間スケールのデータを同等に扱うと重要な差が埋もれる

### メタ設計の判断

| ドメイン知識 | 設計への反映 |
|:---|:---|
| 地質・断層は空間的な「背景」情報 | ResNet で 5ch × 50×50 の地図から Maps embedding を抽出 |
| 地震活動は時系列の「動的変化」 | 全結合で 282 次元統計量を Catalog embedding に変換 |
| 直近 10 日分の文脈が重要 | LSTM で 10 日分の融合 embedding から Time-aware embedding を生成 |
| 85 地域は互いに影響し合う | Vision Transformer で地域間相関を考慮して embedding を更新 |

```
入力
├─ 地質・地震分布マップ（5ch × 50×50）
│   └─ ResNet → Maps embedding（各地域の空間的背景）
│
└─ カタログ指標（282 次元 × 10 時点）
    └─ 全結合 → Catalog embedding（時点的な地震活動）

Maps embedding + Catalog embedding
  → 10 日分 → LSTM → Time-aware embedding（直近文脈）

85 地域 × Time-aware embedding
  → Vision Transformer → 地域間相関を考慮した更新ベクトル
  → 分類（4 クラス）
```

「地震がどのような物理的・時空間的構造を持つか」というドメイン知識が、モデルの組み合わせ方・融合の順序・時間窓の選択を規律している。

### 何が「自動」で何が「設計」か

| 自動化された部分 | 人が設計した部分 |
|:---|:---|
| 各 Encoder 内の重みパラメータ | どのデータにどの Encoder を対応させるか |
| 融合後の特徴量表現 | 融合の順序（空間→時系列→地域間） |
| クラス分類の境界 | マグニチュードのクラス境界（ドメイン知識） |

---

## 6. 事例3（生命科学）：タンパク質構造予測 AlphaFold2（2021）

**Jumper, J. et al.** "Highly accurate protein structure prediction with AlphaFold," *Nature* 596, 583–589 (2021).
https://www.nature.com/articles/s41586-021-03819-2

### 問題設定

アミノ酸配列（1 次構造）からタンパク質の 3 次元立体構造（3 次構造）を予測する。50 年以上解けなかった生物学の難問であり、CASP14（2020 年）で AlphaFold2 が圧倒的な精度で優勝した。

### 素朴なアプローチ「配列に BERT を当てる」の限界

アミノ酸はテキストのように 1 次元配列である。では BERT 的なアーキテクチャで配列を学習させれば構造を予測できるか？

- **情報が足りない**：単一配列だけでは「どのアミノ酸がどのアミノ酸と近い」という 3D 的な関係を学ぶのが困難
- **出力形式の問題**：構造とはアミノ酸それぞれの 3D 座標であり、通常の分類・生成とは根本的に異なる出力形式

### メタ設計の判断

**軸1：入力設計——MSA（多重配列アラインメント）の追加**

タンパク質の 3D 構造は、進化的に保存された配列の「変異パターン」に大きく依存する。同じ機能を持つタンパク質を多数の生物種で集め、どのアミノ酸位置が「一緒に変化するか」（共進化）を分析すると、3D 空間で近い残基対が見えてくる。

```
単一配列: A-R-N-D-C-Q-E-G-H...
MSA:
  種1: A-R-N-D-C-Q-E-G-H...
  種2: A-K-N-D-C-Q-E-G-H...   ← R→K（変異）
  種3: A-R-N-E-C-Q-D-G-H...   ← D→E, E→D（共変異）
  ...
共変異が多い位置対は 3D 空間で近い可能性が高い
```

MSA を入力に加えることは、「進化の記録が構造の手がかりを含む」というドメイン知識をシステムの入力設計に反映した判断である。

**軸2：アーキテクチャ設計——Evoformer**

AlphaFold2 は Evoformer という専用 Attention モジュールを設計した。通常の Transformer とは異なり、次の 2 つのテンソルを同時に処理する。

- **MSA 表現**（行列）：各配列の各アミノ酸位置の特徴
- **ペア表現**（行列）：すべてのアミノ酸ペア間の関係の特徴

```
通常の Transformer:
  配列 (N × d) → Self-Attention → 配列 (N × d)

Evoformer:
  MSA 表現 (S × N × d)   ──┐
                           ├→ 相互更新 → 両表現が更新される
  ペア表現 (N × N × d)   ──┘
```

「タンパク質構造はアミノ酸ペア間の距離・角度で決まる」というドメイン知識がアーキテクチャを規律している。

**軸2：出力設計——構造モジュール**

最終出力はアミノ酸ごとの 3D 座標（骨格の向き・位置）であり、通常のトークン生成とは異なる。構造モジュールは各アミノ酸を「剛体フレーム」として表現し、タンパク質の幾何学的制約（結合角・結合長の物理的制約）を出力形式に組み込んでいる。

```
通常の出力: [トークン確率] or [数値]
構造モジュールの出力: [各アミノ酸の位置 (x,y,z) + 向き (回転行列)]
                     ─── 化学結合の物理制約を満たすよう設計
```

### まとめ

| 設計軸 | ドメイン知識 | 設計の反映 |
|:---|:---|:---|
| 入力設計 | 進化的保存情報が構造を規律する | MSA を入力に追加 |
| アーキテクチャ設計 | ペア間距離が構造を決定する | Evoformer（MSA + ペア表現の相互更新） |
| 出力設計 | タンパク質は幾何学的制約を持つ剛体の連鎖 | 剛体フレームによる 3D 座標出力 |

AlphaFold2 は「配列 Transformer の大規模化」ではなく、「タンパク質折りたたみの物理的・進化的構造をアーキテクチャ全体に組み込む」という設計判断で突破した。

---

## 7. 事例4（気象科学）：天気予報 GraphCast（2023）——概要

**Lam, R. et al.** "Learning skillful medium-range global weather forecasting," *Science* 382, eadi2336 (2023).
https://www.science.org/doi/10.1126/science.adi2336

伝統的な数値天気予報（NWP）は物理方程式を数値的に解く——計算コストが莫大で、予報に数時間かかる。GraphCast はこれをグラフニューラルネットワーク（GNN）で置き換えた。

**メタ設計の判断：**

```
素朴な「大きい Transformer」方針の限界:
  気象データは球面上の空間構造を持つ。緯度・経度グリッドに
  Transformer を当てると、球面的な近傍関係が正しく表現されない。

GraphCast の設計:
  正二十面体メッシュ（球面の近似）上で GNN を動作させる
  ─── 空間的な近傍関係をドメイン知識で明示的に設計

  入力: 1,000hPa〜1hPa の 37 高度層 × 過去 6 時間分の大気状態
  ─── 気象学的に意味ある時空間窓をドメイン知識で選択

  評価: RMSE of 500hPa geopotential, 850hPa wind speed など
  ─── 気象学的に重要な指標で評価
```

「物理方程式は使わないが、気象学的なデータ構造・評価基準はそのまま使う」という設計方針がメタ設計の典型例である。

---

## 8. 事例5（LLM 安全性）：DATA ADVISOR（2024）——概要

**Chen, H. et al.** "DATA ADVISOR: Dynamic Data Curation for Safety Alignment of Large Language Models," *EMNLP* (2024). https://aclanthology.org/2024.emnlp-main.461.pdf

**メタ設計の判断：**

```
素朴なアプローチ:
  「安全性に関するデータを大量に集めて学習させる」
  → 偏り（特定カテゴリだけ多い）や重複が発生しやすい

DATA ADVISOR の設計:
  「現在の訓練データの弱点を LLM で推定してから追加収集する」

  Step1: 現在のデータセットを LLM で要約
  Step2: LLM が「どの安全性カテゴリが不足しているか」を推定
  Step3: 不足カテゴリのデータを LLM で制御生成

  → 訓練データのキュレーション工程自体が設計対象
```

「どのデータで学習させるか」という上流の設計がモデル品質を決める——この発想は Week 5〜9 の「どの特徴量を選ぶか」と同じ構造を、LLM の訓練データ選択で行っている。

---

## 9. 事例横断：メタ設計の共通パターン

5 つの事例に共通する設計のパターンを抽出する。

### パターン1：「ドメイン知識の組み込み先」を見つける

| 知識の種類 | 組み込み先 |
|:---|:---|
| データの物理的構造 | 入力設計・アーキテクチャ設計 |
| タスクの評価基準 | 損失関数・出力設計 |
| 処理の順序・依存関係 | 処理フロー設計 |
| データの偏り・不足 | 訓練データのキュレーション設計 |

### パターン2：「何を自動化し、何を設計するか」の境界を引く

```
自動化できること:
  各モジュール内のパラメータ学習（勾配降下）
  各モダリティの内部表現の獲得

設計が必要なこと:
  どのモジュールをどの順序でどのデータに当てるか
  各モジュールの出力をどう融合するか
  評価指標をどう定義するか
```

「自動化できる部分」と「ドメイン知識が必要な設計部分」の境界は、タスクによって異なる。その境界を見つけること自体がメタ設計の技能である。

### パターン3：「なぜ単一アーキテクチャでは届かないか」を問う

| 事例 | 単一アーキテクチャの限界 | 設計の突破口 |
|:---|:---|:---|
| RAG | カットオフ・ハルシネーション | 知識を外部 DB に分離 |
| Agentic RAG | 固定フローの硬直性 | LLM が動的に判断 |
| SafeNet | 異種データの性質の違い | データ毎に別 Encoder + 段階的融合 |
| AlphaFold2 | 1D 配列だけでは 3D 関係が見えない | MSA + ペア表現の専用 Attention |
| GraphCast | 格子グリッドが球面を正しく表現しない | 正二十面体メッシュ上の GNN |
| DATA ADVISOR | ランダム収集データは偏る | LLM による動的なデータ選択 |

---

## 10. DM パイプラインとの接続

Week 5〜9 で学んだ DM パイプラインとメタ設計は、**同じ問いを別の層で繰り返している。**

| DM パイプライン（Week 5〜9） | メタ設計（Week 15） |
|:---|:---|
| どの特徴量を使うか | どのデータソース・モダリティを入力に選ぶか |
| どのアルゴリズムを使うか | どのモデル・アーキテクチャを組み合わせるか |
| 前処理の順序はどうするか | 処理フローの処理順序・分岐条件はどうするか |
| 評価指標は何か | システム全体の評価基準は何か |
| 訓練データは何か | どのデータでどのモジュールを学習させるか |

**「データから知識を発見する」という DM の目標は変わっていない。変わったのは、その目標のために設計すべきシステムの複雑さである。**

---

## 11. まとめ

### メタ設計が問う 3 つのこと

```
問い1：何を入れるか
  ─ どのデータ・モダリティ・粒度がこのタスクに必要か
  ─ ドメイン知識はどこにあり、それをどの入力に反映するか

問い2：どう組み合わせるか
  ─ どのモデルが各データの性質に最も適しているか
  ─ 各モジュールの出力をどの順序でどう融合するか

問い3：誰がいつ何を判断するか
  ─ どこを自動化し、どこを人がルールとして与えるか
  ─ システム内で「判断の主体」はどのモジュールか
```

### 深層学習は設計の仕事を消したのか

消えたのは「個々の特徴量の値を手作業で作る」仕事である。残ったのは「ドメイン知識をシステムの構造に変換する」仕事——これがメタ設計。

Week 5〜9 で学んだ特徴量設計の思考形式（「何を・どう・なぜ」）は、Week 15 のエージェント設計でも同じように機能する。設計の対象が変わったのであって、問いの立て方は変わっていない。

---

## 参考文献

- Kimura, T. et al. "Scalable intermediate-term earthquake forecasting with multimodal fusion neural networks," *Scientific Reports* 15 (2025). https://www.nature.com/articles/s41598-025-93877-7
- Jumper, J. et al. "Highly accurate protein structure prediction with AlphaFold," *Nature* 596, 583–589 (2021).
- Lam, R. et al. "Learning skillful medium-range global weather forecasting," *Science* 382, eadi2336 (2023).
- Chen, H. et al. "DATA ADVISOR: Dynamic Data Curation for Safety Alignment of Large Language Models," *EMNLP* (2024). https://aclanthology.org/2024.emnlp-main.461.pdf
- Lewis, P. et al. "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks," *NeurIPS* (2020). ← RAG の提案論文
- Yao, S. et al. "ReAct: Synergizing Reasoning and Acting in Language Models," *ICLR* (2023). ← ReAct パターンの提案論文