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

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

45.1. 0. この資料の目的#

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

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

1週目振り返り: 特徴量工学（特徴量エンジニアリング）とその進化史

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

【手動】数値・カテゴリを人が変換する（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）
  何をモデルに渡すか、どのモデルをどう組み合わせるか、
  誰がいつどのツールを呼ぶかを人がドメイン知識に基づいて設計する

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

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

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

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

問題

「大きい Transformer」の限界

専門ドメインの複合データ（地震・気象・タンパク質）

一般コーパスには構造的ドメイン知識が薄い

リアルタイム情報が必要なタスク

学習カットオフ以降の知識がない

長い計算・大規模なデータ処理

1 回の生成で全ては賄えない

安全性・倫理的アラインメント

任意のデータで学習すると有害出力が混入する

タスクが複数ステップの依存関係を持つ

1 回の生成では全ステップを処理できない

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

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

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

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

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

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

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

問い

例

どのデータを入力に含めるか

地震予測に「地質マップ」「時系列統計」両方を入れる

どの時間窓・空間粒度を使うか

直近 365 日のデータか 10 日分か

複数のモダリティをどう扱うか

テキスト + 画像 + 数値をそれぞれ別モデルで Encode してから融合

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

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

問い

例

データの性質に合ったモデルは何か

画像 → CNN / ResNet、時系列 → LSTM、関係性 → GNN、テキスト → Transformer

各モデルの出力をどう融合するか

早期融合（Early Fusion）か後期融合（Late Fusion）か

ドメイン制約をどこに組み込むか

物理法則を損失関数に加える、幾何学的制約を出力層の設計に反映する

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

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

問い

固定フローの例

動的フローの例

処理の順序をどうするか

常に検索→生成の順で実行

クエリの種類に応じて順序を変える

どこで条件分岐を入れるか

なし（全クエリを同一フローで処理）

「この結果で十分か？」を判断して必要なら再検索する

どの処理を並列実行できるか

順次処理のみ

調査・分析・要約を複数エージェントで並列実行する

フロー自体を誰が決めるか

人間が設計時に固定する

LLM がタスクを読んで実行時に動的に決める

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

Tip

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

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

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

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

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

  • 軸1(入力設計): どのデータを入力に含めるか

  • 軸3(処理フロー設計): 検索するか

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

        ↓ この判断の根拠は？

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

        ↓ メタ設計の成果

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

45.5.2. Agentic RAG: 軸3 を深化#

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

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

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

        ↓ メタ設計の更新

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

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

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

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

  • 軸2(アーキテクチャ設計): データの性質に合ったモデルは何か

  • 軸3(処理フロー設計): タスクをどこで分割するか

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

        ↓ メタ設計の更新

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

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

45.6. 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

45.6.1. 問題設定#

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

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

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

  • 地震データは複数の異なる構造を持つ：地質マップ（2D 画像）、カタログ指標（時系列の統計値 282 次元）、空間的な地域間の相関——これらは同じ Transformer トークンとして並べるだけでは構造が失われる

  • 粒度の問題：地質マップは静的な空間背景、時系列統計は直近の動的変化——異なる時間スケールのデータを同等に扱うと重要な差が埋もれる

45.6.3. メタ設計の判断#

ドメイン知識

設計への反映

地質・断層は空間的な「背景」情報

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 クラス）

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

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

自動化された部分

人が設計した部分

各 Encoder 内の重みパラメータ

どのデータにどの Encoder を対応させるか

融合後の特徴量表現

融合の順序（空間→時系列→地域間）

クラス分類の境界

マグニチュードのクラス境界（ドメイン知識）

45.7. 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

45.7.1. 問題設定#

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

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

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

  • 情報が足りない：単一配列だけでは「どのアミノ酸がどのアミノ酸と近い」という 3D 的な関係を学ぶのが困難

  • 出力形式の問題：構造とはアミノ酸それぞれの 3D 座標であり、通常の分類・生成とは根本的に異なる出力形式

45.7.3. メタ設計の判断#

軸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) + 向き (回転行列)]
                     ─── 化学結合の物理制約を満たすよう設計

45.7.4. まとめ#

設計軸

ドメイン知識

設計の反映

入力設計

進化的保存情報が構造を規律する

MSA を入力に追加

アーキテクチャ設計

ペア間距離が構造を決定する

Evoformer（MSA + ペア表現の相互更新）

出力設計

タンパク質は幾何学的制約を持つ剛体の連鎖

剛体フレームによる 3D 座標出力

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

45.8. 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 など
  ─── 気象学的に重要な指標で評価

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

45.9. 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 の訓練データ選択で行っている。

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

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

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

知識の種類

組み込み先

データの物理的構造

入力設計・アーキテクチャ設計

タスクの評価基準

損失関数・出力設計

処理の順序・依存関係

処理フロー設計

データの偏り・不足

訓練データのキュレーション設計

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

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

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

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

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

事例

単一アーキテクチャの限界

設計の突破口

RAG

カットオフ・ハルシネーション

知識を外部 DB に分離

Agentic RAG

固定フローの硬直性

LLM が動的に判断

SafeNet

異種データの性質の違い

データ毎に別 Encoder + 段階的融合

AlphaFold2

1D 配列だけでは 3D 関係が見えない

MSA + ペア表現の専用 Attention

GraphCast

格子グリッドが球面を正しく表現しない

正二十面体メッシュ上の GNN

DATA ADVISOR

ランダム収集データは偏る

LLM による動的なデータ選択

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

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

DM パイプライン（Week 5〜9）

メタ設計（Week 15）

どの特徴量を使うか

どのデータソース・モダリティを入力に選ぶか

どのアルゴリズムを使うか

どのモデル・アーキテクチャを組み合わせるか

前処理の順序はどうするか

処理フローの処理順序・分岐条件はどうするか

評価指標は何か

システム全体の評価基準は何か

訓練データは何か

どのデータでどのモジュールを学習させるか

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

45.12. 11. まとめ#

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

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

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

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

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

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

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

45.13. 参考文献#

  • 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 パターンの提案論文