スノーボードキッズ 初代：100% 非コンパイル化作業完了

🎉 プロジェクト完了の挨拶

非常に嬉しく思っております。初代『スノーボードキッズ』の非コンパイル化作業が遂に 100% に達しました。

• 意味: 全ての関数が対応する C 言語の実装を持ち、それをコンパイルした際、元のゲームと同じ機械語コードを生成することです。
• 感謝の声: このプロジェクトは単独での取り組みではありません。以下の皆様による多大なるご貢献に心より感謝申し上げます。
  • inspectredc
  • Bl00D4NGEL
  • queueRAM
  • ※いかに AI を活用しても、これらの功績を代替することは不可能です。

🤝 リソース提供への謝意

本事業にリソース（トークン）をご提供いただきました以下の皆様にも深く感謝いたします。

• iFuzzle
• JamesBLewis
• douglasjv

プロジェクトの目的:

• 完全な非コンパイル化が『スノーボードキッズ』コミュニティに有益であることを願っています。
• 特にスピードランナーの皆様にとって重要です。
  • 動作するソースコードを活用することで、CPU のパス処理やプレイヤーの速度に影響を与える正確な要因を解明できます。
• 将来への活用: ソースコードに関する完全な理解は、以下の活動にも役立ちます。
  • 静的再コンパイル (static recompilation)
  • より野心的なモディファイイング活動

⏱️ 驚異的な開発効率

プロジェクト完了までのスピードも印象的です。

• スノーボードキッズ 2: 約 596 日
• スノーボードキッズ（初代）: わずか 84 日
  • 所要時間の約 1/7 に過ぎない驚異的な効率を達成しました。

🔍 何が異なるのか？

言うまでもなく、今回はゼロから始めるわけではありませんでした。

• 経験値のアドバンテージ:
  • 今回の時点で、同様のプロジェクトでほぼ 2 年間費やしており、当初よりも大幅にスピードが上がっておりました。
  • ※このアドバンテージは定量化が困難ですが、コンパイラ変更という新たな課題によりやや相殺されました。
• 専門家介入: 対応したコミットの約 4.8% は専門家による介入が必要となりました。
• AI の役割について:
  • 現在（2026 年）ですので、AI が寄与していることは間違いありません。
  • ※しかし、この差を大規模言語モデル（LLM）のみによるものとして片付ける単純化は誤りです。

🛠️ IDO ツールおよびスキルに関する課題

IDO は、最適化とコード生成を複数のパスにまたがって行い、過程でコードを激しく変換します。

• 影響の波及: C 言語側に微小な変更を加えるだけで、各パスを通じて影響が波及し、全く異なるレジスタ割り当てを生み出す可能性があります。
• 現在の性質: コミュニティは IDO の特性について大きく前進しましたが、それは依然として「芸術」に近いものです。
• LLM の限界: LLM は、IDO の出力を再現するにはあまり適していませんでした。

通例のワークフローと限界

1. 理解と作成: 関数が何を行うかを理解し、目的に近似する C 言語コードを作成。
2. 微調整: パフォーマーによる微調整で残りの差分を特定・修正。
3. 壁: 根本的な構造が間違っている場合は、パフォーマーのみで完全に一致させることは不可能でした。
4. 不確実性: IDO の挙動は、このワークフローの不確実性をさらに高めていました。

結論: 適切な専門知識と直感を持つモチベーションの高い人間チームであれば、『スノーボードキッズ』のペースに追いつき、それ以上の成果も達成可能です。

• 参考例: 『パイロットウィングス 64』の非コンパイル化もわずか 74 日で完了しています。

🤖 エージェントが貢献した領域

1. ライブラリコードおよび「低 hanging fruit（容易な果実）」

エージェントが特に活躍したのは、標準ライブラリのコードと一致させる作業です。

• 対象: ゲーム固有ではなく、オンラインで入手可能なバージョンが存在するコード。
  • Nintendo の

    libultra

    (100 を超えるソースコードセグメント)

  • libmus

    オーディオライブラリ
• 手法:

  N64Sym

  などのツールで ROM 内の疑似的なライブラリ関数を特定。
• 戦略上の難点: エージェントを既存のライブラリソースに依存させ、同じ機能をゼロから再実装するのを防ぐこと。
  • 解決策: より強力なプロンプト設計を行い、疑似関数が特定されたらまず対応するソースコードを起点とし、SDK バージョンやコンパイラオプションを試行させる指示を出した。
• スクリプト化の導入:
  • 個別に対処せず、スクリプトで

    m2c

    をすべての未対応関数に実行し、完全一致したものを自動的に統合。
  • 実績: 1,830 件の関数のうち 17 件がマッチ (成功率 0.93%)。
  • これによってマッチングできた分は、エージェントトークンを浪費するコストより安価でした。

2. IDO ツールおよびスキルに関する継続的な学習

IDO は奇妙な挙動を示しますが、それが再帰的に現れる傾向があります。

• 学習の定着:
  • 一つの関数のマッチ成功で、他の関数にも適用されるコンパイラのクイック（奇抜な挙動）を明らかに。
  • 手法: コーデックス (Codex) はタスク間の学習を保持できるようになりましたが、単一エージェントを超えて活用するためには、エージェントに観測された IDO の挙動を

    DECOMPILATION_LEARNINGS.md

    に記録することを指示するプロンプト設計を行いました。
  • 効果: エージェントが汎用的なコンパイラクイックを発見した際、それを記録しておくことで有用なフィードバックループを生み出しました。
• 最大の助力:「N64 Decomp Workbench」:
  • 後期段階の MIPS 非コンパイル化における不一致をデバッグするためのツールおよびドキュメントのコレクション。
  • 機能:
    • 不整合の種類进行分类
    • 再配置 (relocation) の影響を考慮
    • 個々のコンパイラパスの再現
    • 構造上の問題かレジスタ割り当ての問題かの判別
  • メリット: 単純なアッセンブリの差分（「2 つの関数が異なる」のみ）とは異なり、なぜ差異が生じたか、どのように修正できるかのヒントを与えます。

🔄 ワークツリーと同期の問題

環境構成

• 非コンパイル化ハネスを 4 つの Git のワークツリー上で実行。
• 各ワークツリーがエージェントに対してリポジトリの独立したコピーを提供し、複数の関数を並列に試行可能。

期限管理の工夫

• 設定: すべてのタスクに明示的な期限を設定し、エージェントに暴露。
• 理由:
  • 「スノーボードキッズ 2」では、パフォーマーが完全なマッチを見つけるまで動作するため、エージェントが有効に使えずオーバーヒートすることがありました。
  • 明示的な期限を与えることで、エージェントは合理的なタイムアウトを設定でき、パフォーマリング時間を他の問題解決手段とのトレードオフとして調整可能に。

同期の問題と解決策

• 顕在化した課題: ワークツリーが増えるにつれ、同期の問題が発生しました。

  • あるワークツリーで成功裏に非コンパイルできた参照情報は、他のエージェントにはマージされるまで見えません。
  • 定期マージは有効でしたが、4 つのワークツリーすべてを同期するには 1 時間以上かかりました。
  • ジレンマ: 継続的な同期は時間の浪費になりつつも、待機時間が長すぎるとドリフト（乖離）が増大します。

• 解決策: 類似性検索の更新:

  • 類似性検索を更新して全てのワークツリーを検索するように設定。
  • 効果: 新たにマッチした関数は、メインブランチへのマージを待たずに、即座に別のエージェントのための参照点となり得ました。
  • 結果: 容易な関数が消えてゆくに従っても、プロセスの効率が維持されるようになりました。

エージェントによるメッセージ例:

候補 ["func_80094A94", "func_80094FF4 (../sbk-c)", "func_80094808", "func_8009491C (../sbk-a)", "func_8009469C (../sbk-c)", "func_80093144"] を修正しました。

📊 モデルの選択と評価

GPT-5.5/5.6, Claude 4.5/Fable, GLM 5.2 を試しました。

• 評価基準: 他のモデルによって部分的な進歩があった後に、変化し続ける困難な関数のセットに対してテストされました。
• 傾向:
  • Codex: 引き続き Claude よりも優位であり、前プロジェクトの終盤と同様の傾向。

    Sol xhigh

    が利用可能となった後は特に有効性を発揮。
  • GLM 5.2 (z.ai): 非常に失望しました。
    • 以前は Frontier モデルではないものの有効性があり、使用制限が寛大だったため不足を補えておりましたが、現在は制限が厳しくなりながらレイテンシー（遅延）が改善しないため、トレードオフの魅力が著しく低下。
    • フィードバックサイクルが長くなりすぎて作業を与えなくなり、サブスクリプションを取りやめることになりました。

🚀 次に何をするのか

1. ゲームの文書化改善 (最優先)

• 現状: 100% のマッチングとは、全ての関数に対する C 言語コードを手に入れたことを意味します。それぞれの関数が何を行うかを理解したわけではありません。
• 残された課題:
  • 置換すべき生成された名前の整理
  • 特定すべき未知の構造フィールドの探索
  • 整理すべき不自然なマッチ
  • 記述すべき膨大なデータの作成

2. 再コンパイル作業 (進行中)

• 初代作品は「スノーボードキッズ 2:Recompiled」で対応されたパッチと同じような多くのクイックを共有しています。
• 将来計画: 初代作品のステージやその他のコンテンツを、第二作のエンジンへの移植を検討中。

3. PlayStation 向け『スノーボードキッズ プラス』の非コンパイル化

• 日本限定発売で、追加ステージやキャラクターを備えた初代作品の拡張版です。

💬 ご協力のご招待

ここまでお読みになった皆様は、恐らく非コンパイル化と『スノーボードキッズ』に関心をお持ちのことでしょう。

• Snowboard Kids Decompilation Project に立ち寄ってみてください。
• まだ多くのクリーンアップ作業と文書化作業が残されており、ご貢献を熱心に歓迎しております。