ARI 設計哲学

ARI が存在する理由

研究の自動化には従来、以下のいずれかが必要でした:

• 高価なクラウドインフラストラクチャ
• 社内のエンジニアリング専門知識
• 他の分野に転用できないドメイン固有のツール

ARI は、「アイデアがある」から「結果がある」までのギャップは、リソースに関係なく月単位ではなく時間単位で測定されるべきだという信念に基づいて構築されています。

普遍性の 5 つの軸

1. コンピュート: ラップトップからスーパーコンピューターまで

ARI はラップトップ（mode: local）でも SLURM クラスターでも同一に動作します。同じ実験ファイル、同じ設定形式、同じ出力構造です。切り替えは workflow.yaml の 1 行だけです。

hpc:
  mode: local      # ラップトップ
  mode: slurm      # HPC クラスター
  partition: your_partition

2. LLM: ローカルからクラウドまで

ARI はすべての LLM 呼び出しを litellm 経由で委譲します。モデルは設定であり、コードではありません。

llm:
  model: qwen3:8b           # Ollama、API キー不要、オフライン実行
  model: gpt-5.2            # OpenAI API
  model: claude-sonnet-4-5    # Anthropic API
  base_url: http://...      # 任意の OpenAI 互換 API

3. 専門性: 初心者からエキスパートまで

実験 .md 形式で必須フィールドは研究目標のみです。初心者は 3 行、エキスパートは 200 行記述できます。ARI はどちらも読み取れます。

4. ドメイン: 計算から物理世界まで

ARI のコアには「実験の種類」という概念がありません。認識しているのは:

• 目標がある
• ツールがある（MCP skills）
• 品質シグナルがある（LLM が付与する scientific_score）
• エージェントは科学的貢献を最大化する構成を探索すべき

この抽象化は、ソフトウェア最適化、ML ハイパーパラメータチューニング、ロボットアームの軌道、ウェットラボプロトコルに等しく適用されます。

5. 出力: 結果から検証済み論文まで

ARI は「最良の結果が見つかった」で終わりません。以下を行います:

1. 完全な実験ツリーを走査（アブレーションと検証実行を含む）
2. LLM を使用して生の成果物から科学的文脈を抽出
3. 図表と引用付きの出版可能な LaTeX を生成
4. 品質フィードバックのために論文を LLM 査読者に提出
5. 再現性エージェントが実験を再実行し、主張された数値を検証

ゼロドメイン知識の原則

ARI のプロダクションコードにはドメイン知識が含まれていません。

これは単なる設計上の好みではなく、コードレビューで厳格に実施されるハードな不変条件です。

実際にこれが意味すること:

禁止	正しいアプローチ
if "score" in metric_name	LLM からの scientific_score
grep -i "compiler|flags"	LLM が成果物を自由に読み取る
プロンプト内の "compare against baseline"	LLM が何と比較するか決定
ハードコードされた図表の種類	LLM がどの図表を描くか決定
+0.2 のスコアリング重み	LLM が総合的にスコアリング
システムプロンプト内の lscpu	LLM が実行した場合にのみ lscpu 出力を読み取る

ARI のコアが規定するのは以下のみ:

• フォーマット: ツール呼び出しに JSON、実験に Markdown
• プロトコル: skill 通信に MCP
• シグナル: scientific_score（LLM が 0.0-1.0 を付与）が BFTS を駆動

その他すべて — 何を測定するか、どう比較するか、どのハードウェア詳細が重要か、どの図表を描くか、どの引用を含めるか — は実行時に LLM が自律的に決定します。

なぜ scientific_score か?

以前のバージョンでは、ドメイン固有のキーワード（score、throughput）を使用してノードをランク付けしていました。これは特定のドメインでは機能しましたが、他のドメインでは暗黙的に失敗しました。

scientific_score は、LLM エバリュエーターが査読者として付与する 0.0-1.0 の品質シグナルです。科学的厳密性を総合的に捉えます:

• 実験は実際の測定値を生成したか?
• 結果は既存のアプローチと比較されたか?
• 手法は再現可能か?
• 結果は明確な科学的主張を裏付けているか?

LLM が重みを決定します。ARI は数値を読み取るだけです。

なぜ MCP か?

Model Context Protocol は ARI に 3 つの特性を与えます:

1. 分離: 各 skill は独立したプロセスです。論文生成のバグが HPC ジョブを破損することはありません。
2. 置換可能性: 他の skill に手を加えずに任意の skill を交換できます。
3. 発見可能性: LLM エージェントは実行時に利用可能なツールを発見します。skill の追加 = 新機能の追加であり、エージェントの再プログラミングは不要です。

物理世界への道

現在の skill セットはデジタル計算をカバーしています。MCP アーキテクチャは拡張可能に設計されています:

センサー読み取り   → ari-skill-sensor
アクチュエータ制御 → ari-skill-robot
ラボ自動化         → ari-skill-labware
リアルタイムFB     → ari-skill-control

BFTS エージェントは、現在ソフトウェアパラメータを最適化しているのと同じインフラストラクチャを使用して、物理パラメータ — 反応温度、ロボット速度、混合比 — を最適化することになります。

アンチゴール

ARI は以下を明示的に意図していません:

• ドメイン専門知識の置き換え（増幅するものです）
• 物理的リスクの境界で人間の監視なしに動作すること
• ブラックボックスであること（すべての決定はログに記録され追跡可能）
• 特定のドメインにおける「良い科学」についてのハードコードされた意見を持つこと

系論: 失敗した実験は情報である

ノードが失敗した場合、ARI は同じアプローチをリトライしません。代わりに、失敗したノードはフロンティアに入り、expand() が失敗のコンテキストを引き継ぐ debug 子ノードを生成します。次の世代は失敗から学びます — これは失敗をシグナルではなくノイズとして扱うリトライロジックとは質的に異なります。

系論: 再現性はファーストクラスの原則である

ARI のエージェントシステムプロンプトには、一つの一般的な科学的原則が含まれています: 実験が再現可能であることを確認すること。これはドメインルールではなく、化学、HPC、機械学習に等しく適用されます。どの情報を記録する必要があるかはエージェントが自律的に決定します。論文査読者は、論文が再現可能かどうかを独立に評価し、ハードコードされた基準なしでループを閉じます。

関連

アーキテクチャ · BFTS アルゴリズム