「魔法の機械も魔法の運用者もいない」──テストをリポジトリの中に置いたHaskell製LeetCodeランナー Openleetcode

3行まとめ

1. Openleetcodeは、LeetCode形式のコーディング問題をローカルで解いて採点できるHaskell製のCLIツール。テストケース・採点ロジックがすべてリポジトリ内に公開されている。
2. 実行バックエンドはDocker上のPiston（デフォルト）で、cpp・rust・python3/2・ruby・java・csharp・kotlin・go・dart・swift・typescriptの12言語に対応。
3. 問題データの拡充には、LLM（OpenRouter経由）を使って問題文からマニフェスト草案を生成する補助スクリプトが用意されており、READMEはその出力を「無限に忍耐強いが要レビューのジュニア貢献者」と表現している。

「テストがブラックボックスの向こう側にある」ことへの異議

READMEはDHH（David Heinemeier Hansson）の言葉「There are no magic machines and no magic operators.（魔法の機械も魔法の運用者もいない）」を掲げてスタートする。GitHubで実際にリポジトリを確認すると、本記事執筆時点でスター166・フォーク6・ウォッチャー3。作成日は2026年1月12日で、ライセンスはMIT/Apacheではなく「Unlicense」（著作権を放棄し完全なパブリックドメインとする形式）が採用されていた。実際にLICENSEファイルの中身を取得すると、"This is free and unencumbered software released into the public domain."という定型文言が確認できた。Openleetcodeがやっているのは、ソリューションファイルを受け取り、対応する問題マニフェストを探し、その言語専用の小さな実行ハーネスを組み立て、実行バックエンドに送って、ローカルで採点する——という一連の処理だ。

$ openleetcode submit ./solution.py --id 1
$ openleetcode submit ./solution.rs --title two-sum

実行バックエンドにはPistonが使われ、Linux・macOSではインストーラがDocker Compose経由で自動的に起動を試みる（Windowsの場合、インストーラはCLIのみをインストールし、Docker自体は手動で用意する必要がある）。テストケースの置き場所自体もリポジトリの中にあり、tests/1-500/1. two-sum/manifest.yamlのようなディレクトリ構造で管理されている。

GitHubのディレクトリ一覧を実際に開いて、5つの番号帯ディレクトリそれぞれに含まれる問題数を数えたところ、次の内訳になった。

ディレクトリの命名（2001-2500まで）からは、将来的にLeetCode問題番号2500番台までをカバーする計画がうかがえるが、実際に収録済みの問題数は合計1,410件で、特に2001-2500番台はまだ17件しか埋まっていない。README「Status」節に書かれている「openleetcode is young and some manifests will be better than others.（openleetcodeはまだ若く、マニフェストの出来には差がある）」という自己申告は、この番号帯ごとの偏りとも整合する。

マニフェスト1件の中身——単純な「出力一致」だけではない

「テストがリポジトリの中にある」という主張を裏付けるため、実際にtests/1-500/1. two-sum/manifest.yamlを1件取得して中身を確認した。構成要素は次の通りだった。

• entry：12言語それぞれについて、Solution().twoSum({nums}, {target})のような呼び出しテンプレートを個別に定義（言語ごとにメソッド名の大文字小文字や呼び出し規約が異なるため）
• judge：この問題はtype: exact（厳密な出力一致）
• oracle：正解が複数あり得る問題向けに、Python製のチェッカー関数で「その回答が妥当かどうか」を動的に判定する仕組みも用意されている（Two Sumの場合、返された2つのインデックスが実際に配列内の異なる要素を指し、合計が目標値と一致するかを検証するコードが埋め込まれていた）
• limits：実行時間1,000ms・メモリ256MBという制限
• tests：具体的な入出力例（Example 1・Example 2……）

つまり、単純な「期待される出力の文字列と完全一致するか」だけでなく、複数の正解がありうる問題には専用の検証ロジック（oracle）を個別に書ける設計になっている。これは、READMEが強調する「テストと採点ロジックがブラックボックスの向こうにあるのではなく、リポジトリの中に平文で存在する」という主張の具体的な裏付けだ。

GitHub APIで見る実態──ほぼ1人で書かれたリポジトリ

GitHubのWeb画面ではなく、REST API（api.github.com/repos/therepanic/openleetcode）からメタデータを直接取得すると、README上の説明だけでは分からない実態が見えてくる。

さらに/contributorsエンドポイントを見ると、コミット数の内訳は作者本人（therepanic）が263件、github-actions[bot]（CIによる自動コミット）が7件のみで、人間のコントリビューターは実質1名だった。フォークが6件ある一方で、外部からのコード貢献がリポジトリの履歴に反映された形跡は今回確認した範囲では見当たらない。

/languagesエンドポイントで言語別のバイト数を取得すると、Haskell(176,058バイト)が全体306,398バイトの57.5%を占め、次いでPython(34,610バイト・11.3%)、Rust(15,713バイト・5.1%)と続く。残りはGo・C#・Kotlin・Swift・C++・Java・Dart・TypeScript・Ruby・PowerShell・Shell・Dockerfileに数千バイトずつ分散しており、対応12言語それぞれに小さな実行ハーネスを書いているという説明と整合する内訳だった。

対応言語は12種

READMEに掲載されている対応言語は次の通り：cpp rust python3 python2 ruby java csharp kotlin go dart swift typescript。各ランタイムはLeetCode特有の互換レイヤー（JSON出力、配列・行列・連結リスト・二分木など）を提供し、インポートや標準ライブラリの使い方も公式LeetCode実行環境に近づけているため、「Openleetcode専用のプログラムではなく、普通のLeetCode提出コードに見えるはず」とREADMEは説明している。

問題を増やす作業にLLMを使っている

コードを書かない形での貢献についてのセクションが興味深い。generate_prompt.pyは、あるLeetCode問題の問題文・コードスニペット・参照解答からLLM用のプロンプトを組み立てる。spartan.pyはこれをバッチで行い、OPENROUTER_API_KEYが設定されていればOpenRouter経由でLLMにマニフェスト草案をgenerated_problems/へ書かせることができる。molotov.pyはその生成フォルダからsol.{lang}ファイルを埋める。READMEはこの一連の生成物を「無限に忍耐強いジュニア貢献者だと思って扱え。有用で速いが、レビューは依然として必要」と表現しており、AIで問題データを量産しつつも、それをそのまま信頼しない姿勢を明記している。

マニフェストの精度そのものは検証していない

本記事はtherepanic/openleetcodeのGitHub README・LICENSE・tests/ディレクトリの実データを取得した内容にもとづく。実際にDockerでPistonバックエンドを起動し、複数言語での採点を試したわけではない。1,410件という問題数はディレクトリ名の一覧から数えたものであり、各問題のマニフェスト（テストケース）の中身が正しいかどうかは1件ずつ検証していない。プロジェクトのステータスは「young（若い）」とREADMEに明記されており、マニフェストの品質にはばらつきがあるともある。LLM生成部分（spartan.py・molotov.py）が実際にどの程度の精度で問題データを生成できているかも、README以上の裏取りはしていない。

ローカル完結のLeetCode環境という切り口はまだない

Zenn・Qiitaともに言及はゼロだった。競技プログラミング・LeetCode対策の日本語記事は多いが、「ローカルで動くLeetCode環境を自分で持つ」という発想の紹介はまだ見当たらない。

関連記事

• Claude Codeで初心者がゲームを作る手順──未経験から公開までの4ステップ
• AIコーディングアシスタント比較──Copilot/Cursor/Claude Code【2026年】