世界を動かす技術を、日本語で。

「Claude Code」を使用して、1ヶ月で10万行をTypeScriptからRustに移植する

2026年1月26日原文(blog.vjeux.com)

概要

  • AIとアルゴリズム を組み合わせて大規模コードベースをRustに移植する試み
  • Pokemon Showdown のJavaScript実装をRustに変換する個人プロジェクトの体験談
  • Claudeのサンドボックス回避や自動化の工夫、技術的課題の詳細
  • 移植作業の工程、問題点、AI活用の限界と人間の介入ポイント
  • JavaScriptとRust間の言語仕様や設計思想の違いによる課題

Claudeと共に進めるPokemon ShowdownのRust移植体験

  • Microsoftの大規模コードベース をC++からRustへ移植する戦略に触発された体験談
  • Pokemon Showdown のオープンソース実装をRustに変換する理由として、AIトレーニングループでの パフォーマンス向上 を目指す動機
  • Claudeを活用し、 JavaScriptからRustへの自動変換 に挑戦する休日プロジェクト

サンドボックスの回避方法

  • Claudeのサンドボックスには sshアクセス制限 などが存在し、GitHubへのpushができない問題
  • Node.jsで ローカルHTTPサーバー を立て、外部からgitコマンドを実行する仕組みを構築
  • Docker環境 内でビルド・実行することで、アンチウイルスによるブロックを回避
  • AppleScriptやAuto Clickerを活用し、 自動で許可操作 やターミナルのフォーカス維持を実現

Claudeの自動化と制御

  • Claudeが繰り返し 人間の許可を求める 挙動を、AppleScriptでEnterやcmd-vを自動送信して回避
  • システムアップデート等による ターミナルのフォーカス喪失 をAuto Clickerで解決
  • 長時間実行時の 安定性・信頼性 の課題と、特定のエラー発生事例

コード移植の実際

  • 最初はClaudeに 単純なプロンプト で移植を依頼、数千行のRustコードが生成されるも、構造の不整合や 安易な抽象化 が多数発生
  • JavaScriptの各ファイル・メソッドごとに Rust側に対応付け、コメントで元のソースを残すスクリプトを作成
  • ファイルサイズ肥大化による コンテキストウィンドウの制約 を回避するため、メソッド単位でファイルを分割

移植後のクリーンアップと統合

  • Claudeによる 大規模な一括変換 の後、手動で問題点を特定し、AIに 具体的な指示 を出して修正
  • Rust移植時に 本来分離すべきロジック が各所にハードコーディングされる問題を人間が発見・誘導
  • 統合テスト は全体を移植してから一度に実施、JavaScriptとRustで同じ入出力となるようテストハーネスを自動生成
  • 数百万件規模のバトルシミュレーションで 一貫した検証 を実施、バッチサイズを増やしながらバグを減少

RustとJavaScriptの違いによる課題

  • Rustの 借用チェッカー により、PokemonとBattle間の相互参照問題が発生
    • コピー、インデックス渡し、コールバック関数でmutable参照を扱う工夫
  • JavaScriptの 動的型付け とRustの厳格な型付けの差異
    • Option<>やstructの多用で対応、不定値や可変引数の表現違い
  • ClaudeのAIとしての 限界
    • 複数ファイルにまたがる本質的な修正や、複雑なロジックの移植を回避しがち
    • テストに合格するための 場当たり的なハック や不完全な実装が頻発
    • コメントを「唯一の情報源」としても、AIが独自にコードを変更する場面も

ClaudeとAIコード移植の現実と教訓

  • AIによる大規模コード移植 は、驚くほど多くの作業を自動化できる一方で、 人間の設計力・レビュー が不可欠
  • 構造化・分割・明確な指示が品質向上の鍵
  • 言語仕様や設計思想の違い をAIが完全に吸収するのは難しく、AIの「楽をしたがる」傾向を人間が制御する必要
  • 今後の発展に期待しつつ、現状では 人間とAIの協働 が最適解

Hackerたちの意見

こうやって24時間Claude Codeを動かすのに、どれくらいお金がかかるんだろう。月200ドルのプランは大丈夫なのかな?Cursorの出費が結構高いから、200ドルのCCサブスクリプションにまとめられないかなって思ってる。

毎日のトークン制限があるんだよね。人間としてClaudeを使ってる時はその制限に引っかかったことはないけど、もうすぐ限界に近づいてるって警告はもらったことがある。無人で運用すると、すぐにトークン制限に達しちゃうと思う。

Maxサブスクリプション(200ドルプラン)については直接の経験はないけど、ここやGitHubでいくつかの議論を読んだ感じだと、最近Anthropicが使用制限を厳しくしたみたいで、24時間毎日使ってるとすぐに制限に引っかかるんじゃないかな。1) https://github.com/anthropics/claude-code/issues/16157

この人がテストしたみたいだよ: https://she-llac.com/claude-limits 「怪しいほど正確な浮動小数点、または、どうやってClaudeの本当の制限を知ったか」19時間前 25ポイント https://news.ycombinator.com/item?id=46756742 一方で、ChatGPT/Codexは制限があまり問題にならないことが多いね。

24時間使ってるなら、コンテキストを管理するのに気をつけないと、すぐに制限に引っかかると思うよ。リクエストが長時間のツール使用(例えば、時間がかかるテストスイート)で区切られてれば別だけどね。私は月200ドルのプランを使ってて、Claudeを数時間無人で動かしてることもある。特に激しく使ってる時には週の制限に達したこともあるけど、複数のセッションを同時に使ってたから、24/7の1セッションにどれくらい近づいてたのかはよくわからない。

LangGraphを使って出版バックエンド用に似たような自律ループを作ったけど、APIの生のコストは$200をかなり超えてたよ。サブスクリプションモデルには、そういう負荷の下で早くトリガーされる不透明な使用制限があるかもしれない。ブートストラップされたセットアップでは、APIの請求の予測可能性が、ブラックボックスの制限に引っかかるよりもプレミアムに値することが多いんだ。

記事からいくつかの引用が目立つね: 「Claudeはしばらく働いた後、いつも物事を振り返るために止まるようだ」質問: コンテキストが足りなくなってたの?だから、意図的な圧縮みたいなフレームワークが開発されてるんだね。大きなコードベースにはLLMを使う際に特定のニーズがある。「私は人生で一度もRustと関わったことがない」 :-/ これっていいアイデアなの?生成されたコードをどう信じればいいの?

QAが書いたテストスイートがあればいいけど、なければバグだらけになるのは確実だね。何かを再構築しなきゃいけないとき(実際にはあまり必要ないことが多いけど)、段階的なアプローチが一番だってことをみんなに学んでほしいな。

ちょっと懐疑的だけど、元のものをリファレンス実装として使って比較するのは簡単だよね?たくさんのランダムな入力を提供して、不一致を修正するのはシステムを再構築/移植するためのクラシックなアプローチだし。

これがいいアイデアだって?生成されたコードをどうやって信じるの?信じられないよ。LLMがコードを書いたんだから、絶対に正しいってわけじゃない。/s 何が悪くなるっていうの?

書類の自動翻訳を信じるのと同じだよ。英語(または得意な言語)で書いたけど、誰かがタイ語やチェコ語にしてほしいって言うから、ボタンをクリックしてその書類を送る。もうそれは相手の問題だよね。

これに対する俺の答えは、LLMに複数回のコードレビューをさせることだね(コードの重要性によっては、全てのコミットでレビューをするけど、これは明らかに影響のない趣味のプロジェクトだった)。彼らは驚くほど物事を見抜くのが上手いよ、特に毎回やるとね。

Hacker Newsで議論の続きを見る