⚠ ネタバレ注意: 本サイトはSFアニメ「SOLAR LINE」の内容を詳細に分析しています。未視聴の方はご注意ください。
📝 AI生成コンテンツ: 本考証の大部分は AI（Claude Code 等）によって生成されています。内容の正確性については原作および引用元をご確認ください。

技術解説: SOLAR LINE 考証の仕組み

本プロジェクトの技術アーキテクチャ — Rust軌道力学コア、WASM、TypeScript静的サイト生成、Claude Codeエージェントループによる自律開発を解説する。

はじめに

「SOLAR LINE」は、ゆえぴこ氏による『良いソフトウェアトーク劇場』のSFアニメシリーズです。太陽系を舞台にした宇宙船の航行が精密に描写されており、本プロジェクトはその軌道遷移の描写を宇宙力学的に検証しています。アニメ本編や分析の概要はトップページをご覧ください。

本ページでは、この考証を支える技術的な仕組みを解説します。AIエージェントが自律的にコードを書き、テストし、分析レポートを生成するプロジェクトの内部構造に興味がある方向けの内容です。

プロジェクト概要

SOLAR LINE 考証は、SFアニメ「SOLAR LINE」に描かれた軌道遷移を宇宙力学的に検証するプロジェクトです。

全5話に登場する24の軌道遷移について、実際の物理法則に基づくΔV計算・加速度分析を行い、描写の妥当性を検証しています。単に「正しい/間違い」を判定するだけでなく、どのような条件なら描写が成立するかをパラメータ空間の探索を通じて明らかにすることを目指しています。

現状サマリー

進捗

指標値
完了タスク639
分析済み軌道遷移24 / 24（全話完了）
テスト数5,168（TS 4,261 + Rust 552 + E2E 355、0 failures）
コミット数836+
ADR（設計意思決定記録）15件
DAGノード65（320エッジ）— 分析依存グラフ（詳細は後述）

判定結果

判定件数
plausible（妥当）10
conditional（条件付き妥当）9
reference（参考）5
implausible（非現実的）0

24件の軌道遷移で 非現実的な判定はゼロ。ただしマージン連鎖分析によると、条件付き判定の連鎖を考慮した場合の全行程成功確率は約30-46%。

「reference（参考）」は作中の描写値と直接比較できない参照計算を指し、plausible/conditionalとは別カテゴリです。

読者向け機能

分析の主要達成項目

設計意思決定（ADR）

15件のArchitecture Decision Recordsで、プロジェクトの設計ポリシーを文書化しています。

アーキテクチャ全体像

システムは3層構成です:

  1. Rust 軌道力学コア (solar-line-core): 軌道計算の正確性を保証
  2. WASM ブリッジ (solar-line-wasm): ブラウザでも同じ計算を再現
  3. TypeScript レポート生成 (ts/): MDX分析データ → 静的HTMLサイト

この構成により、レポート上のインタラクティブ計算機で読者が自らパラメータを変更して検証でき、計算結果がRustとTypeScript間で一貫していることが保証されます。

Rust 軌道力学コア

ランタイム外部依存ゼロで構築された軌道力学ライブラリです。WASM互換性のために外部クレートを使わず、すべての数学関数を自前で実装しています（テスト用オラクルとして nalgebra を dev-dependency で使用）。

主要モジュール

552のユニットテストで正確性を保証しています。

積分手法の比較

軌道伝播には3種類の数値積分手法を実装しており、場面に応じて使い分けています。

手法ステップ推力対応長所短所主な用途
RK4（固定ステップ）固定 dt✅実装が単純、挙動が予測可能dt選択に注意が必要、急変時に精度低下短時間のbrachistochrone遷移、重力捕捉
RK45 Dormand-Prince（適応ステップ）自動調整✅精度と効率の自動バランス、加速度急変に対応実装が複雑、ステップ数が非決定的トリム推力遷移（EP02）、高離心率軌道
Störmer-Verlet（シンプレクティック）固定 dt❌（弾道のみ）エネルギーの永年ドリフトなし推力非対応、2次精度長期弾道軌道の検証、1000周回精度テスト

RK4（Runge-Kutta 4次）

一言で言うと: 最も基本的で信頼性の高い積分法。短〜中距離の遷移に使用。

4次精度の固定ステップ積分器。各ステップで4回の導関数評価を行い、加重平均で次状態を求めます。dt=60s で重力捕捉のエネルギードリフトが ~2.9×10⁻⁹ に収まることを検証済み（Task 219）。単純で信頼性が高く、72時間~143時間程度のbrachistochrone遷移の主力積分器です。

RK45 Dormand-Prince（適応ステップ）

一言で言うと: 状況に応じて計算の細かさを自動調整する賢い積分法。推力のON/OFFが切り替わる場面に最適。

5次精度の埋め込み型適応積分器。4次と5次の解の差からステップ誤差を推定し、PI制御器でステップサイズを自動調整します。推力ON/OFFの不連続点（flipタイム）を検出してステップ境界を合わせる機能を持ち、EP02のトリム推力遷移（3日間推力→合計約87日の遷移）のような動的な場面に適しています。scipy DOP853 との交差検証で遷移時間の差が0.013%未満であることを確認（Task 221）。

Störmer-Verlet（シンプレクティック積分）

一言で言うと: 長期間シミュレーションでもエネルギー誤差が蓄積しない特殊な積分法。何千周回でも安定。

2次精度のleapfrog型シンプレクティック積分器。位相空間の体積を厳密に保存するため、エネルギーが真値の周りを振動するだけで永年的にドリフトしません。RK4では1000周回で ~10⁻⁸ 程度のドリフトが蓄積しますが、Störmer-Verletでは同条件で振動範囲に留まります。ただし推力を含む非保存力には対応せず、弾道軌道の長期精度検証に特化しています。

3手法の結果はRust内部のテストで相互検証されており、さらにPython（scipy/poliastro）との交差検証も実施しています。

WASM ブリッジ

Rust コアを wasm-pack でWebAssemblyにコンパイルし、ブラウザ上のインタラクティブ計算機から利用可能にしています。

設計方針: Flat f64 API

WASM の境界を越える際に複雑なデータ構造の受け渡しを避け、すべての関数が f64 のスカラー値を受け取り返す設計です。ニュータイプの wrapping/unwrapping はWASM境界で行います。


// TypeScript側
const dv = wasm.brachistochrone_dv(distance_km, time_seconds);

// WASM内部
pub fn brachistochrone_dv(distance: f64, time: f64) -> f64 {
    core::brachistochrone_dv(Km(distance), Seconds(time)).value()
}

この設計により、TypeScript 側では型変換の複雑さを意識せず、Rust 側では型安全性を維持できます。

レポート生成パイプライン

分析結果はMDX形式（Markdownベース + 構造化データブロック）のファイルとして管理され、TypeScriptの静的サイト生成パイプラインでHTMLに変換されます。

データフロー

  1. MDX 分析データ (reports/data/): エピソードごとの軌道遷移、パラメータ探索、台詞引用、軌道図定義をMarkdown + YAML frontmatter + コードフェンスブロックで記述
  2. MDXパーサー (ts/src/episode-mdx-parser.ts): frontmatter、diagrams: / timeseries-charts: / dialogue-quotes: 等のブロックを解析
  3. テンプレートエンジン (ts/src/templates.ts): 純粋な文字列補間による外部依存ゼロのHTML生成
  4. ビルド (npm run build): MDXを読み込み、全ページを dist/ に出力
  5. GitHub Pages: main へのpush時に自動デプロイ

字幕・対話パイプライン

作中の台詞を正確に引用するための2段階パイプラインです。

Phase 1: 抽出

複数のデータソースから生のテキストを取得:

Phase 2: 話者帰属

コンテキストを考慮した話者の特定:

2つのフェーズを別ファイル（epXX_lines.json / epXX_dialogue.json）で管理することで、Phase 1の再実行がPhase 2の成果を破壊しない設計です。

テスト戦略

TDD（テスト駆動開発）を原則とし、5,168のテストで品質を保証しています。

テストの内訳

4つのテスト層が異なる品質側面をカバーしている。TypeScriptが全体の75%を占めるのは、記事内容検証テスト（レポート本文と計算結果の整合性チェック）が大量にあるためであり、単なるユニットテストではなく分析の事実整合性を保証する役割を持つ。

CI パイプライン

GitHub Actions で5つの並列ジョブを実行:

  1. Rust lint + test: cargo fmt --check + cargo clippy -D warnings + cargo test
  2. TypeScript typecheck + test: tsc --noEmit + npm test
  3. Playwright E2E: サイトビルド + ブラウザテスト
  4. Python クロスバリデーション: poliastro/scipy による軌道計算 + 補助モジュール (相対論・姿勢制御・プラズモイド・通信・質量タイムライン・3D幾何・天体暦・軌道要素変換) + networkx による DAG グラフアルゴリズムの独立検証
  5. WASM browser build: wasm-pack build --target web の成功を確認

テスト分布 — 4層の品質保証（Rust精度検証 → TypeScript整合性 → E2Eレンダリング → Python交差検証）

Rust ユニットテスト 552.00 "件" TypeScript ユニットテスト 4,261.00 "件" Playwright E2E テスト 355.00 "件" Python クロスバリデーション 504.00 "件"

Claude Code エージェントループ

本プロジェクトはAnthropicが提唱するパターンに基づき、Claude Codeエージェントが自律的に開発しています。

ワークフロー

  1. タスク取得: current_tasks/ から未着手のタスクを選択
  2. 実装: コード変更、テスト作成、データ更新
  3. 検証: CI相当のチェックをローカルで実行
  4. コミット + プッシュ: 次のセッションへのハンドオフノートとして機能するコミットメッセージ
  5. セッションログ: 会話ログを抽出しGitHub Pagesで公開

品質管理

タスク管理

639の完了タスクファイル（current_tasks/）でプロジェクトの進行を追跡。各タスクにステータス（TODO/IN_PROGRESS/DONE）と完了内容を記録し、セッション間の連続性を確保。さらに DAG（有向非巡回グラフ）で分析間の依存関係を管理し、前提変更時の影響範囲を自動追跡しています。

分析依存グラフ（DAG）

本プロジェクトの分析は相互に依存しています。船体質量パラメータを変更すれば、それに依存する全24の軌道遷移分析と全レポートの再検証が必要になります。

この依存関係を有向非巡回グラフ（DAG）として管理しています。DAGの分析ロジック（トポロジカルソート、Sugiyamaレイアウト、影響カスケード、パス探索、交差最小化）はRustで実装され、WASMにコンパイルしてブラウザ上でリアルタイムに実行されます。ノードをクリックすると詳細を確認できます。

ノードの枠色は検証状態を示します: 有効（緑）、要再検証（橙）、未処理（灰）。

npm run dag -- invalidate param.ship_mass のように CLI で前提を無効化すると、影響する全ノードが自動的に「要再検証」としてマークされます。

設計原則

外部依存の最小化

Rust コアはランタイム外部クレートゼロ、テンプレートエンジンも外部依存ゼロ。CDN依存は KaTeX（数式レンダリング）、uPlot（時系列チャート）、DuckDB-WASM（データエクスプローラー）のみ。これにより、ビルドの再現性と長期的な保守性を確保。

仮定の明示化

すべての分析には前提条件を明記。「世界設定資料に基づく船体質量48,000 t」「JPL平均軌道要素による惑星位置」など、データの出典をトレース可能に。

SF作品としての評価

物理的に現実的かどうかだけでなく、作品内で一貫しているかを重視。未来の推進技術は受け入れ可能な前提として扱い、経過時間・距離・天体位置の整合性を検証。推進加速度（推進G）と居住環境の重力（居住G）は異なるカテゴリとして分析し、SF作品の慣例に従って推進Gは暗黙に処理されているものとして扱う。

複数シナリオの探索

一つの不一致を見つけて「非現実的」と結論づけるのではなく、パラメータ空間を探索してどの条件なら成立するかを明らかにする。境界条件や許容範囲の議論により、分析の深みを確保。

関連ページ