モデル / データセット
he-yufeng/CoreCoder avatar
he-yufeng/CoreCoder

CoreCoder を読む: 1,161 行の Python に coding agent の骨格を見る

Minimal AI coding agent (~1,000 lines of Python) inspired by Claude Code. Works with any LLM. Think NanoGPT for coding agents. Formerly NanoCoder.

スター 1,740フォーク 414PythonMIT

ひと目でわかる

これは何?
CoreCoder は Claude Code 的な coding agent の中核を約 1,161 行で書き直した MIT ライセンスの教材兼実行ツールである。日常の相棒としてではなく、agent の仕組みを読み切って fork する土台として評価する。
誰に向いている?
CoreCoder は、coding agent が実際に何をしているのかを自分のマシン上で一行ずつ追いたい開発者に向く。逆に、明日から業務でコードを書かせたいだけのチームには向かない。
商用利用できる?
できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
今もメンテナンスされている?
されています。最後のコミットは 2 日前です。
何の言語で書かれている?
主に Python です(GitHub の言語統計による)。

回答はプロジェクトの GitHub データ(最終同期:2026年9月15日)と当サイトの分析に基づくもので、法的助言ではありません。

オープンソース詳細解説

CoreCoder が埋めようとしている穴

coding agent の説明は往々にして難解に語られる。README の書き手はそれを否定し、Claude Code や Cursor を剥がしていけば中身は大きなモデルを包んだ while ループと、実際に手を動かすための七つか八つのツールに過ぎないと述べている。難しいのはループそのものではなく、ループが現実世界に触れた後に処理しなければならない周辺のすべてだ、というのが著者の主張である。

CoreCoder はその中核を正直に書き出した最小版として提示されている。対象読者は二種類いる。一つは agent の内部構造を学びたい開発者。もう一つは nanoGPT のように、読んで理解した上で自分の派生版を作りたい人だ。README は nanoGPT を参照点として置き、同じ「最小で読める」性質を持ちながら、題材が GPT の学習ではなくコードを編集する agent であると説明している。

ここで注意したいのは、CoreCoder が Claude Code や aider の代替を狙っていないことだ。README は「同じレースにはいない」と明言し、それらから学びながら出発するための土台だと位置づけている。競合比較表を載せてはいるが、それは性能や機能の優劣ではなく、行数と読了時間という別の軸での比較である。

エンジン 1,161 行の内訳とループの置き場所

リポジトリの構成は README のコードマップで公開されている。中心は corecoder/agent.py で、agent ループと並列ツール実行を担当し 213 行。ここから読み始めることが推奨されている。次に llm.py がストリーミングを扱い、そのほかにコンテキスト、ツール、セッションといったモジュールが続く。エンジン部分は空行とコメントを除いて 1,161 行、CLI や設定、パッケージングを含めた全体は 24 ファイル、物理行で 2,384 行、正味 1,931 行と記載されている。

データの流れは README の説明からおおよそ次のように読める。ユーザーの入力がループに入り、llm.py 経由でモデルに渡され、応答として返るツール呼び出しを agent.py が解釈して実行する。ファイル読み書き、シェル実行、サブ agent の起動がこの段階で起きる。実行結果は再びモデルに戻され、ループが継続する。コンテキストは三層で圧縮され、トークンとドルは要求すればいつでも報告される。

設計上の判断として目を引くのは、破壊的な操作の前に必ず同意を求める点だ。ディスクを書き換える、あるいはコマンドを実行する類のツールは、ユーザーの承認なしには動かない。これは後述する権限レイヤーとして v0.5.0 で導入された。

導入は git clone と editable install から

README が推奨する手順は、単なる pip install ではなく clone して editable で入れる方法だ。読みながら変更することを前提としているためである。

git clone https://github.com/he-yufeng/CoreCoder を実行し、cd CoreCoder した後、pip install -e . とする。とりあえず動かしたいだけなら pip install corecoder でも構わないと README は書いている。Python は 3.10 以上が必要だ。

モデルとキーの設定は環境変数で行う。既定は OpenAI 互換 API で、プロバイダの切り替えは概ね二つの変数で済む。OpenAI なら OPENAI_API_KEY を設定するだけで、既定モデルは gpt-5.5 と記載されている。DeepSeek なら OPENAI_API_KEY に加えて OPENAI_BASE_URL=https://api.deepseek.com と CORECODER_MODEL=deepseek-chat を指定する。ローカルの Ollama なら OPENAI_API_KEY=ollama、OPENAI_BASE_URL=http://localhost:11434/v1、CORECODER_MODEL=qwen2.5-coder という組み合わせが例示されている。

キーは export してもよいし、プロジェクトルートの .env に書いてもよい。.env は起動時に読み込まれる。OpenAI 互換エンドポイントを提供しないプロバイダ向けには、オプションの LiteLLM バックエンドがあり、pip install "corecoder[litellm]" で導入できる。

起動は二通り。corecoder で対話 REPL、corecoder -p "add error handling to parse_config()" で一発実行モードになり、完了すると終了する。ここで注意すべき仕様が README に明記されている。-p は --yes を渡さない限り書き換え系ツールを拒否する。ワンショットのスクリプトから使う場合はこの点を先に把握しておく必要がある。

v0.4.2 から v0.6.0 までの三リリースが示す設計の重心

リリースノートからは、このプロジェクトが何を後回しにし、何を先に固めたかが読み取れる。v0.4.2 は /undo によるチェックポイント、v0.5.0 は権限レイヤー、v0.6.0 は MCP、hooks、plan mode である。

順序に意味がある。まず取り消し可能性を用意し、次に破壊的操作の承認を挟み、その上で外部連携と計画モードを載せた。agent がファイルを書き換える以上、戻せることと止められることが先に必要だという判断だろう。Claude Code 的な機能名が並ぶが、実装は 1,161 行のエンジンに収まる範囲に留まっていると推測される。README は「足りない部分は未完成ではなく、そこから分岐して自分のものにする場所だ」と述べている。

MCP と hooks が入ったことで、単なる読解用のおもちゃではなく、外部ツールをつなぐ拡張点ができたことになる。ただし README には MCP や hooks の設定キーの具体例は載っていない。この点はリポジトリ内の該当モジュールとリリースノートを直接確認する必要がある。

テスト 146 件と、それでも足りない部分

README はテストが 146 件あり全て通っていると記載している。これは動作の裏付けとして意味がある。ただしテストの存在は、agent としての実用性の証明にはならない。テストが検証しているのはおそらくループ、ツール呼び出し、コンテキスト圧縮、権限判定といった構成要素であり、モデルが現実の複雑なリポジトリで妥当な編集をするかどうかは別問題である。

実際に README が挙げている動作確認は、DeepSeek、Qwen3、Kimi K2 を単一の OpenRouter 互換エンドポイント経由で使い、ファイルを読み、編集し、実行し、報告する一連の流れが完走した、という範囲だ。ベンチマークの数値は提示されていない。性能を比較する材料はこのリポジトリにはない。

もう一つの制約は規模そのものだ。1,161 行に収めるという方針は、機能を足すたびにどこかを削ることを意味する。大規模リポジトリの横断的な理解、長いセッションの安定、多様な言語のビルド系への対応といった領域は、意図的に手薄なまま残されている可能性が高い。README 自身が「最小の中核だけを意図的に保つ」と書いている。

aider との違いは機能表ではなく読了時間にある

比較対象として最も近いのは aider だろう。どちらもターミナルで動く Python 製の coding agent で、モデルを差し替えられる。違いは規模と目的にある。README の比較表では、aider は数万行の Python で読了に数日かかるとされ、CoreCoder は 1,161 行で一午後とされている。

aider はターミナルでのペアプログラミングを目的とした実用ツールだ。CoreCoder はそれを目的としていない。breakpoint を張って変更して再実行できる点は両者に共通するが、aider では変更すべき箇所が多く、CoreCoder では全行が対象になる。この差は学習曲線の差ではなく、読む対象として何を想定しているかの差である。

Claude Code は閉源で数十万行、読むこと自体が不可能だと比較表は述べている。CoreCoder はその公開された分解分析から本質的な層を取り出し、できるだけ少ないコードで書き直したものだと README は説明する。つまり Claude Code の代替ではなく、Claude Code についての実行可能な注釈という位置づけになる。

どのツールを選ぶかは、何をしたいかで決まる。毎日のコーディングを任せたいなら aider や Claude Code の領域だ。中で何が起きているかを自分の手で確かめたいなら CoreCoder の領域である。

MIT ライセンスと、fork を前提にした保守コスト

ライセンスは MIT で、リポジトリの LICENSE に置かれている。fork して自分の派生版を作ることを README が明確に推奨している以上、ライセンスの緩さはこのプロジェクトの設計と整合している。派生物を公開する場合も MIT の表示を残す必要があるという一般的な条件は変わらないが、具体的な判断は法務に確認する領域であり、ここで断定はしない。

保守コストの観点は二つに分かれる。上流を追う場合、エンジンが 1,161 行しかないため差分の把握は容易だ。一方で、fork して独自のツールやフックを足した場合、上流の変更と自分の変更が同じファイル内で衝突しやすい。agent.py が 213 行しかないということは、ループの変更が一箇所に集中するという意味でもある。

依存関係は軽い。既定では OpenAI 互換 API を叩くだけで、LiteLLM はオプション扱いの extra である。モデル側のコストは使うプロバイダ次第で、README によれば実行ごとにトークンとドルが報告される。どのモデルを既定にするかで請求額が変わるため、CORECODER_MODEL の設定は費用管理の起点になる。

バージョンは v0.6.0 で、2026 年 9 月 8 日時点でアーカイブされていない。活発に更新が続いている段階であり、API や設定キーが今後変わる可能性は残る。

編集部の結論

CoreCoder は、coding agent が実際に何をしているのかを自分のマシン上で一行ずつ追いたい開発者に向く。逆に、明日から業務でコードを書かせたいだけのチームには向かない。README 自身が「daily driver になるためではなく、walkthrough が嘘をつかないために動く」と位置づけているからだ。導入前に確認すべきは、pip install -e . で入れた環境で corecoder -p を --yes なしに実行し、書き込み系ツールが本当に止まるかどうか。次に .env に OPENAI_BASE_URL と CORECODER_MODEL を書いて、使う予定のモデルでループが一周するかを見る。この二点が確認できて初めて、agent.py の 213 行を読み始める価値が出る。

公式情報源

  1. he-yufeng/CoreCoder on GitHub
  2. License: MIT
  3. Project website
  4. README
  5. Releases
コミュニティノート

コミュニティノート