Claude Codeでローラーコースタータイクーンをプレイしてみた

 (labs.ramp.com)
16 ポイント 投稿者 GN⁺ 2026-01-19 | 1件のコメント | WhatsAppで共有
  • Claude Code をオープンソースゲーム RollerCoaster Tycoon 2(OpenRCT2) に統合し、AIが実際に遊園地を運営するように実験したプロジェクト
  • AIは 財務、来園者の不満、アトラクションの故障データ など100以上の指標を分析し、ドリンク売店の設置・スタッフ雇用・入場料調整などの管理判断を自動で実行
  • CLIツール rctctl を通じてゲーム内のすべての操作をコマンドラインで実行し、Kubernetesのkubectl に似た構造で設計
  • Claudeは データ分析・価格調整・スタッフ管理 には強みを見せた一方、経路接続・ジェットコースター配置・地形認識 など空間的な課題では限界を示した
  • 実験を通じて エージェント設計の核心は環境の可読性とインターフェース品質 であることを確認

プロジェクト概要

  • Ramp Labsは Claude Code を RollerCoaster Tycoon 2 に統合し、AIが公園運営を直接行うよう実験
    • Claudeはゲーム内の財務、来園者満足度、アトラクション状態など100以上のデータを分析
    • その結果をもとに ドリンク売店の追加、整備員の雇用、入場料の引き上げ などの措置を自動提案
  • 実験の目的は B2B SaaS環境におけるAIエージェント設計の教訓 を得ること
  • RollerCoaster Tycoonは 顧客中心のビジネス運営とデジタルなフィードバックループ を反映するゲームとして選ばれた

なぜRollerCoaster Tycoonなのか

  • Rampは 作業ごとの小規模エージェント を開発中であり、セキュリティとコンテキストの限界を考慮したアプローチを取っている
  • しかし 広範な権限を持つ単一エージェント に対する実験的な欲求があった
  • RollerCoaster Tycoonは 経済・顧客・運営管理 が結びついた環境で、SaaS運営に近い構造を提供
  • ゲームのインターフェースは B2B SaaSダッシュボード に似ており、Claudeの レトロフューチャリズム的なターミナルインターフェース とも相性が良い

Claudeの能力と限界

  • OpenRCT2をフォークして ターミナルウィンドウ を追加し、Claudeがコマンドラインでゲームを制御するよう実装
  • rctctl CLI はユーザーが可能なすべての操作をカバーし、JSON-RPC を通じてゲーム状態と通信
  • Claudeは視覚の代わりに ASCIIマップ出力 で空間情報を把握

Claudeの強み

  • ゲーム知識: RCT関連の知識が豊富で、90年代のゲーム環境でも自然に動作
  • 情報収集: 来園者フィードバック、財務データなど多様な指標を統合分析
  • デジタル操作: アトラクションの開閉、価格調整、スタッフ雇用、マーケティング実行など非空間的な作業に強い
  • 施設配置: トイレ・ドリンク売店など単純な構造物は安定して配置可能

Claudeの弱み

  • 経路接続: 道探し、入口・出口の接続など空間的な作業が苦手
  • ジェットコースター配置: 大型アトラクション設置時に障害物・地形認識に失敗
  • 立体空間認識: 傾斜、地下構造、カスタムコースター設計は不可能
  • 結論としてClaudeは 情報ベースの管理には強いが、視覚・空間的な操作には弱い

ビルド過程

  • OpenRCT2(C++)をベースに Claudeターミナルウィンドウ、rctctl CLI、RPCレイヤー、テストコード を追加
  • 初期バージョンは ChatGPT o3-Pro Deep Research で計画し、その後 GPT-5.1-codex で再実装
  • 合計40時間以上を要し、フィードバックループの不在 が最大のボトルネックとして指摘された
  • Claude自身が バグレポートをリポジトリに作成 するようにしてQA効率を高めた

主な教訓

  • 環境の可読性(Environment Legibility) : Claudeは明確なデータインターフェースでは優れているが、テキストベースの空間表現には弱い
  • コーディングエージェントの価値: 最新モデル更新(Claude Opus 4.5など)が即座に反映され、開発速度が向上
  • 開発ループの重要性: 自動QAループがなければ生産性は急激に低下
  • 経験の優位: LLMの動作原理を理解する最良の方法は、直接実験してプレイすること

実行とオープンソース情報

  • macOS(Sonoma以降)、Xcode、CMake、Ninja、RCT2(正規版)が必要
  • rctctl CLIは kubectlスタイルのコマンド構造 で、ClaudeがJSON-RPCを通じてゲームを制御
  • ビルド成果物:
    • OpenRCT2 (ターミナル内蔵版)
    • rctctl (CLIツール)
    • Spriteアセット
  • コード全体はGitHub(jaysobel/OpenRCT2)で公開され、Twitchでリアルタイム実演が可能

結論

  • Claude Codeは 運用自動化の可能性と限界 を同時に示した
  • RollerCoaster Tycoonは グラフィカルインターフェースと知能システムの過渡期的な実験場 として機能
  • 核心的な洞察: AIエージェントの成否は環境の明瞭さとインターフェース設計の品質にかかっている

関連記事

1件のコメント

 
GN⁺ 2026-01-19
Hacker Newsのコメント

  • 自分のLLMが使うツールの水準が低すぎるのがいつも惜しい
    自分はIDEでリファクタリング、シンボル追跡、関数の参照箇所表示などをワンクリックで行うが、LLMは grep や diff、cat のような原始的なコマンドしか使わない
    LLMにもっと良いコード作成・リファクタリングツールを与えようとする試みがあるのか気になる

    • VSCode DiagnosticsやLSPサーバーへのアクセス権を与えても、LLMはいつも基本的なCLIツールばかり使おうとする
      AGENTS.mdに明記しても無視して単純なやり方に戻るので、もどかしい
    • AI開発ツールの大半がVSCodeベースなのは意外
      JetBrainsが持つリファクタリング・コードインスペクション能力をAIと結びつけていたら、もっと先に進んでいた気がする
    • Claude Codeは2025年12月版でLSPを正式サポートしたが、それでもなお単純なツール中心で学習されたように見える
      LLMはむしろ低水準ツールを組み合わせて問題を解くことに強みがある
      人間には複雑な20行のPythonスクリプトでも、LLMなら0.5秒で作れてしまう
    • Zed EditorはLSPベースの機能をそのままLLMに提供し、grep 依存を減らしてくれる
    • LLMには人間のようなIDE機能が必須というわけではない
      コード断片を素早く理解して組み合わせるので、refactoring機能はむしろ混乱を招くこともある
      ツールを与えすぎると判断力が鈍る危険がある

  • 投稿者です。おまけリンクを共有します
    Simon Willisonのclaude-code-transcriptsを使ったセッションスクリプト
    Redditの投稿
    OpenRCT2プロジェクトのRepo

    • CLIの代わりにスクリーンショットや可視化された画面で評価したのか気になる
      Claudeは画像ベースの入力には強いが、ASCII図式には弱いかもしれない
    • Claudeの視覚・空間認識の限界に触れつつ、画像理解ではOpenAIのモデルの方が優れていそうだという意見もある

  • 現実世界のエージェント設計と同じく、汎用エージェントの限界は環境の可視性とインターフェースの強さにある
    だから私たちは、エージェントを「知能」ではなく「勤勉さ」を自動化する存在として捉えるのが正しい

  • “revert”という言葉を誤って使ったせいで、Codexが実際に git revert を実行して作業内容を巻き戻した事件があった

    • こうしたツールが作業ログを再生可能な形で保存していないのは驚き
      git revert は破壊的なコマンドではないので、データ損失があったなら、おそらく git reset --hard だった可能性がある
    • こうした事故を防ぐにはコマンド権限制御機能が必要
    • だからJujutsuを使おうという意見もあり、jj status をプロンプトに入れておけば安全

  • このゲームがアセンブリコードでたった一人により開発されたという点に驚いた
    開発者を探して感謝を伝えたい
    Claude Codeの試みも印象的で、興味が湧いた

  • C++をまったく知らないままvibe-codingでプロジェクトを完成させたという部分が興味深い

    • 普通、vibe-codingは「数時間で終えた」と語られがちだが、今回は現実的なスケジュールが示されていたのが新鮮
    • 彼らの試行錯誤と問題解決の過程が本当に面白かった
    • 1997年にこれがあったなら、全財産をつぎ込んででも買っていたと思う
      今の世代はこうした環境の価値をあまり分かっていない気がする

  • 動画の最後のインタビューが印象的だった
    kubectlスタイルのCLI、Claudeのフィードバック、警告システムなど、AIと人間の協業ツールがますます重要になっている
    人間が視覚的に理解できる文脈をAIにも与えれば、はるかに良い結果が得られる

    • ただし、AIが自分自身を改善する構造は実際にはうまく機能しない
      単にコンテキストを増やすことだけでは学習は起きず、結局はファインチューニングが必要になる

  • 記事は面白かったが、AIが実際にゲームをどれだけ上手くプレイしたのかという結果分析が不足していた

    • 実際には財務管理は得意だったが、建設は苦手だった
      2Dマップの理解が難しく、トイレとホットドッグ屋台くらいしか建てられなかった
      マルチモーダルモデルならもっと良かった気がする
    • AIの本質は生成能力であって検証ではない、と見る人もいる

  • Claude Codeでコンテキスト残量をどう確認するのか気になった

    • /context コマンドですぐ確認できる
    • status lineにコンテキスト使用量表示を追加することもできる
      色のバーで残量を可視化するプラグインもある

  • こうした実験にはCivilizationのようなターン制ゲームの方が適していると思う
    マップがグリッド構造で、ターン単位で進行するため