Codonとは？Pythonを高速化するコンパイラの使い方とPythonとの違い【v0.20.4・AtCoder対応】

Codon（コドン）は、Pythonの文法をほぼそのまま使いながら、実行前にネイティブコードへコンパイルするコンパイラです。開発元はExaloop社で、原型はMIT CSAIL（コンピュータ科学・人工知能研究所）のゲノム解析向け言語Seqにあります。遺伝暗号のコドンと同じ綴りですが、この記事で扱うのはPythonコンパイラのほうです。

2026年10月22日時点の最新版はv0.20.4です。v0.20.0でUnicode文字列と挿入順を保つ辞書に対応し、数値演算の既定もPythonと同じ挙動に変わりました。一方、AtCoderの言語一覧に載っているのは1つ前の系列のCodon 0.19.3で、手元に最新版を入れて試すと割り算や小数の表示、入力の読み方が提出先と食い違います。導入手順と基本操作、既存のPythonコードへの組み込み方、Pythonとの違いを整理したうえで、0.19.3と0.20.4を同じコードで動かした結果を示します。

まとめ：v0.20.4時点のCodonと使う前に押さえる5点

• 最新版はv0.20.4（2026年10月17日公開）。ライセンスはv0.18.0からApache-2.0で、v0.17.0まではBusiness Source License 1.1でした（exaloop/codonのリリース一覧と各タグのLICENSEで確認）。
• 公式バイナリはLinuxとmacOSだけです。Windowsでは公式ドキュメントがWSL経由の利用を勧めています。
• 速度を測るときは-releaseを必ず付けます。既定はデバッグモードで、公式のfib(40)の計測では付けないと33倍、付けると46倍です。
• v0.20.0で互換性が大きく上がりました。Unicode文字列、辞書の挿入順、整数の割り算と剰余の丸め方がPythonと一致します。64ビット固定のintと固定長のタプルは今も残る差です。
• AtCoderで使えるのは「Python (Codon 0.19.3)」です。-7 // 2が-3、print(1 / 3)が0.333333になるなど最新版と挙動が違うので、手元の検証は0.19.3に合わせます。

Codonの位置づけ：MIT CSAIL発・Exaloopが開発するPython互換コンパイラ

Codonの土台は、2023年2月にACM SIGPLANの国際会議Compiler Construction（CC ’23）で発表された論文「Codon: A Compiler for High-Performance Pythonic Applications and DSLs」です。筆頭著者のAriya Shajii氏はMIT Newsの2023年3月14日の記事で、普段どおりPythonを書くだけで「通常のPythonより10倍から100倍速く動く」と述べています。同じ記事は、Pythonで書かれたゲノム解析アプリケーション約10本をCodonでコンパイルし、手作業で最適化した元の実装より5倍から10倍速くなったと報告しています。

速さの出どころは2つあります。ひとつは静的型付けで、実行前に型を確定させてCPythonが毎回払う型判定のコストを消します。もうひとつはLLVMによる事前コンパイルで、ループ展開やベクトル化をネイティブコード生成の段階で適用します。GIL（グローバルインタプリタロック）も無いので、マルチスレッドでコア数に応じた並列化が効きます。GitHubのリポジトリのスター数は2026年10月22日時点で16,863です。

遺伝暗号のコドンとPyPIのcodonパッケージ

「codon」で検索すると、コドン表のような分子生物学のページとPythonコンパイラのページが同じ結果に並びます。インストールでも同じ取り違えが起きます。PyPIのcodonは「Non-Stationary Codon Model Fitting」という説明のバージョン0.0.1の分子生物学向けパッケージで、Exaloopのコンパイラとは関係ありません。pip install codonはエラーにならずにこの別物を入れてしまいます。コンパイラ本体は後述のインストーラで入れ、Pythonから関数単位で使うときはcodon-jitを入れます。

ライセンス：v0.18.0でBusiness Source LicenseからApache-2.0へ

v0.17.0（2024年8月23日）までのライセンスはBusiness Source License 1.1でした。LicensorはExaloop, Inc.、Additional Use GrantはNone、Change Dateは2028年3月1日で、本番環境での利用は許諾の範囲外でした。LICENSEファイルは2025年1月29日のコミットでApache License 2.0に差し替えられ、翌日のv0.18.0（2025年1月30日）から適用されています。2024年以前の日本語の解説にはBSL前提の記述が残っているため、ライセンスを判断材料にするときは記事が前提にしている版を確かめてください。

インストール：LinuxとmacOSは1行、WindowsはWSL経由

公式インストーラはシェルスクリプト1本で、~/.codonに展開されます。

/bin/bash -c "$(curl -fsSL https://exaloop.io/install.sh)"
codon --version

スクリプトはGitHubのreleases/latestからOSとCPUに合うアーカイブを取ってくるので、入るのは常に最新版です。途中でシェルの設定ファイルにPATHを追記してよいか尋ねられます。v0.20.4の配布アーカイブはlinux-x86_64、linux-aarch64、manylinux2014-x86_64、manylinux2014-aarch64、darwin-arm64、darwin-x86_64の6種類で、macOS向けが約49MBから53MB、Linux向けが約74MBから81MBです。

特定の版を入れたいときは、リリースのアーカイブを直接展開します。AtCoderに合わせて0.19.3をmacOS（Intel）に入れる場合は次のとおりで、Apple シリコンならdarwin-arm64、Linuxならlinux-x86_64に置き換えます。

mkdir -p ~/codon-0.19.3
curl -L https://github.com/exaloop/codon/releases/download/v0.19.3/codon-darwin-x86_64.tar.gz \
  | tar zxf - --strip-components=1 -C ~/codon-0.19.3
~/codon-0.19.3/bin/codon --version   # 0.19.3

Windows対応：WSL経由の利用とネイティブ対応の予定

公式ドキュメントのインストールページには「CodonはLinuxとmacOSでネイティブにサポートされています。Windowsを使っている場合は、WSL経由でCodonを使うことを推奨します」と書かれています。インストーラもuname -sがlinuxでもdarwinでもなければ「Pre-built binaries only exist for Linux and macOS.」と出して終了します。

公式ロードマップの「Infrastructure & Tools」には「Windows support」が未完の項目として載っていますが、時期は示されていません。WindowsではWSL2上のUbuntuなどに入れるのが現実的な方法で、WSL2側の準備はWSL2とは？WSL1との違い・仕組み・インストール手順【WSL 3.0対応・2026年10月】で扱っています。

codon-jitの導入要件：Codon本体とNumPy

CPythonのコードの中で関数単位にCodonを使うためのパッケージがcodon-jitです。2026年10月22日時点の最新は0.5.4（2026年10月17日公開）で、PyPIにはソース配布物しか無く、インストール時にその場でビルドされます。

export CODON_DIR=~/.codon      # 標準の場所ならPATHから見つかる
pip install codon-jit numpy

macOS（Python 3.14.6）で試すと、Codon本体が見つからない状態では「Cannot find Codon. Please either install Codon … or set CODON_DIR」と出てビルドの段階で失敗しました。Codonを~/.codon以外に置いたときはCODON_DIRが必須です。もうひとつの落とし穴はNumPyで、0.5.4の依存パッケージはastunparseとcythonだけなのに、import codonの時点でNumPyを読み込みます。NumPyの無い環境ではModuleNotFoundError: No module named 'numpy'で止まるので、一緒に入れておきます。

基本操作：codon runによる実行とcodon buildによる成果物生成

codon runはコンパイルと実行をまとめて行い、codon buildは成果物をファイルとして書き出します。

from time import time

def fib(n):
    return n if n < 2 else fib(n - 1) + fib(n - 2)

t0 = time()
ans = fib(40)
t1 = time()
print(f'Computed fib(40) = {ans} in {t1 - t0} seconds.')

これをfib.pyとして保存し、codon run -release fib.pyで実行します。ファイル名の代わりに-を渡すと標準入力からプログラムを読むので、echo 'print("hello")' | codon run -release -のような使い方もできます。

-releaseの有無で変わる実行時間

公式ドキュメントはM1 MacBook Proで上のfib(40)を計測した結果を載せています。

右端の列は、Intel Core i9-9880HのmacOSでCodon 0.20.4とCPython 3.14.6を使って同じコードを1回ずつ流した値です（公式の計測はpython3.13）。-releaseによる高速化は今回の計測で2倍、公式の計測で約1.39倍です。最適化は-releaseを明示したときだけ有効になります。CythonやMojoとの倍率比較はCython・Codon・Mojo実測比較｜Pythonコードは何倍速くなるかで同じ条件のコードを使って計測しています。

codon buildの出力形式と配布時に要る共有ライブラリ

codon build -exe -release -o app program.py       # 実行ファイル
codon build -lib -release --relocation-model=pic -o libapp.so program.py  # 共有ライブラリ
codon build -obj -release program.py              # オブジェクトファイル
codon build -llvm -release program.py             # LLVM IR
codon build -pyext -release --relocation-model=pic -module mymod -o mymod.o program.py  # Python拡張用

形式のフラグを省いても、-oに渡した名前の拡張子から推測されます。実行ファイルは単体では完結しません。0.20.4で作ったfibの実行ファイルをotool -Lで見ると、libcodonrt.dylibとlibomp.dylibを@rpath経由で読み込む作りでした。別のマシンへ持っていくときは、この2つを~/.codon/lib/codonからコピーして読み込める場所に置きます。CやC++から共有ライブラリの関数を呼ぶ場合は、公開したい関数に@exportを付けます。

既存Pythonとの連携：@codon.jitとfrom python importの使い分け

プロジェクト全体をCodonへ移すと標準ライブラリの差分に当たります。既存のコードを残したまま使う入口は2つあり、CPythonから重い関数をCodonへ渡すのが@codon.jit、Codonのコードから既存のPythonモジュールを呼ぶのがfrom python importです。

@codon.jitの呼び出しコストとループ単位の処理

import time, codon

def count_primes_py(lo, hi):
    c = 0
    for k in range(lo, hi):
        if k > 1:
            p = True
            for i in range(2, k):
                if k % i == 0:
                    p = False
                    break
            if p:
                c += 1
    return c

@codon.jit
def is_prime(n):
    if n <= 1:
        return False
    for i in range(2, n):
        if n % i == 0:
            return False
    return True

@codon.jit
def count_primes(lo, hi):
    c = 0
    for k in range(lo, hi):
        if k > 1:
            p = True
            for i in range(2, k):
                if k % i == 0:
                    p = False
                    break
            if p:
                c += 1
    return c

is_prime(3); count_primes(2, 3)  # 初回のコンパイルを計測から外す

t = time.time(); print(count_primes_py(100000, 130000), "CPython", round(time.time() - t, 2))
t = time.time(); print(sum(1 for i in range(100000, 130000) if is_prime(i)), "is_prime x 30000", round(time.time() - t, 2))
t = time.time(); print(count_primes(100000, 130000), "count_primes x 1", round(time.time() - t, 2))
t = time.time(); [is_prime(2) for _ in range(30000)]; print("empty calls x 30000", round(time.time() - t, 2))

デコレータを付けた関数は、初回の呼び出しで引数の型に合わせてコンパイルされます。公式ドキュメントは10万個の素数判定で、CPythonの39.66秒が@codon.jit付きで0.998秒になったと記載しています。

ただし、呼び出しのたびに引数をPythonのオブジェクトからCodonの型へ変換するコストがかかります。上のコードをIntel Mac（ほかの処理が動いている状態）で3回実行すると、3万個の判定はCPythonで29.7秒から32.0秒、関数を3万回呼ぶis_primeで4.4秒から4.5秒、ループごと渡すcount_primesで1.8秒から2.1秒でした。最後の行の、判定がすぐ終わる呼び出しを3万回繰り返すだけで1.9秒から2.3秒かかっており、is_primeの時間の半分近くは変換のコストです。小さな関数を何度も呼ぶ形では効果が目減りするので、ループを関数の内側に入れて呼び出しを1回にまとめます。数値は初回のコンパイルを除いた時間です。

リストや辞書は変換時にコピーされるので、JIT関数の中でappendしても呼び出し元のリストは変わりません（実行しても[1, 2]のまま）。結果は戻り値で受け取ります。例外はNumPy配列で、データのポインタがそのまま渡されるため、中で書き換えると呼び出し元にも反映されます。JIT関数の中で並列ループを使うときは@parではなく_@parと書きます。

from python importによる未実装モジュールの呼び出し

from python import matplotlib.pyplot as plt

data = [x**2 for x in range(10)]
plt.plot(data)
plt.show()

Codonがネイティブ実装していないモジュールや、pipで入れたライブラリはfrom python importでCPython側を呼びます。使う前に環境変数CODON_PYTHONにCPythonの共有ライブラリ（libpython3.13.soなど）のパスを設定します。同じ名前でも経路で中身が変わり、import sysはCodonのsys、from python import sysはCPythonのsysです。CPython側を呼んでいる区間はCPythonの速度で動きます。

Pythonとの違い：v0.20.0で消えた差分と残る制約

v0.20.0で変わった3点：Unicode・辞書の順序・数値演算の既定

v0.20.0のリリースノートには、Unicodeへの完全対応と、CPythonに合わせた順序付き辞書の採用が書かれています。公式ドキュメントの差分一覧では、「CodonはASCII文字列を使う」「辞書は挿入順を保持しない」という旧記述が取り消し線付きで残っているので、線を見落として古い制約を信じないよう注意が要ります。

リリースノートに書かれていない変更がもうひとつあります。整数の割り算や剰余を、Pythonと同じ規則で計算するかC言語と同じ規則で計算するかを決める-numericsの既定値です。ソースコードのllvm::cl::initを版ごとに見ると、0.19.6まではC、0.20.0からはPythonでした。0.19.3と0.20.4で同じコードを実行した結果は次のとおりです。

s = "コドンとPython"
print(len(s))
d = {}
for k in [5, 3, 9, 1, 7, 2]:
    d[k] = k * 10
print(list(d.keys()))
print(-7 // 2, -7 % 3)
print(1 / 3)

0.20.4でもC言語の規則は-numerics=cで選べ、実行すると-7 // 2は-3に戻ります。公式ドキュメントによるとC言語の規則のほうが最適化は効きやすいので、負数の除算・剰余に加え、ゼロ除算時の挙動の違いも許容できるコードで速度を詰めるときの選択肢になります。順序を気にしない辞書も、旧実装を-unordered-dictで選べます。

残る制約：64ビット整数・固定長タプル・アンパック

0.20.4でも残る差のうち、書いたコードが黙って誤った値を返すものから順に挙げます。

• 整数は64ビット符号付き固定。10**18 * 10はCPythonでは10000000000000000000ですが、Codonでは例外も警告も出ずに-8446744073709551616になります。より大きな値はInt[128]のように幅を指定すると扱え、Int[128](2) ** 100は正しく計算されました。
• タプルは長さがコンパイル時に決まる型。tuple([1, 2, 3])は0.19.3ではコンパイルエラーでしたが、0.20.4ではエラーにならず(0x10a86afe0, 3, 3)のような意味のない値を出力しました。リストをタプルへ変換するコードは書き換えます。
• mapの結果を直接アンパックできない。a, b = map(int, input().split())は両方の版で「’Generator[int]’ object has no attribute ‘__getitem__’」というコンパイルエラーになります。a, b = list(map(int, input().split()))なら通ります。
• 実行時の動的な書き換えは不可。クラスへ後からメソッドを足すモンキーパッチや、異なる型の値を1つのリストに混ぜる書き方は型検査で止まります。

標準モジュールの対応状況と欠けている関数

標準ライブラリはCodon自身で書き直したものが使われ、v0.20.2でjson、os、sys、pathlibが加わりました。対応しているモジュールの中にも無い関数があり、0.19.3と0.20.4のどちらでも次のものは使えませんでした。

collectionsのdeque、Counter、heapq、bisectは両方の版で期待どおり動きました。

AtCoderでCodonを使う：0.19.3と最新版の差

競技プログラミングのAtCoderでは、2025年の言語アップデートでCodonが提出言語に加わり、Pythonで参加する人はCPython、PyPy、Codonの3つから選べるようになりました。AtCoder自体の仕組みはAtCoderとは？色の目安と人数割合・難易度・コンテストの種類と始め方【2026年版】で扱っています。

AtCoderのCodon環境：版とコンパイルコマンド

AtCoderの言語一覧（2026年6月16日時点の情報）では、言語名は「Python (Codon 0.19.3)」、ファイル名はMain.py、コンパイルコマンドは次のとおりです。

export CODON_PYTHON=/usr/local/lib/libpython3.13.so
codon build --release -o a.out Main.py

実行は./a.outです。-numericsの指定が無いので、数値演算は0.19.3の既定であるC言語の規則になります。CODON_PYTHONにはCPython 3.13.7が設定されており、一覧にはnumpyやsortedcontainersなどのライブラリも並んでいます。ただしfrom python importで呼んだ部分はCPythonの速度で動くので、計算の中心には使えません。

0.19.3で手元の最新版と結果が変わる書き方

インストーラは常に最新版を入れるため、手元の0.20.4で通ったコードがAtCoderの0.19.3では誤答やコンパイルエラーになります。0.19.3と0.20.4で確かめた差は次のとおりです。

影響が大きいのは小数の出力です。0.19.3のprintは有効数字6桁で丸めるので、出力の丸め誤差が問題で指定された絶対誤差・相対誤差の許容範囲を超えると、計算が正しくても誤答になります。print(f"{x:.10f}")のように桁数を指定すれば、0.19.3でも0.3333333333と出ました。負の数の剰余は((x % m) + m) % mと書けば両方の版で同じ値になります。

入力はinput()かfor line in sys.stdinなら両方の版で動きます。PyPyでよく使うinput = sys.stdin.readlineは0.19.3では「’File’ object has no attribute ‘readline’」でコンパイルが止まります。手元で0.19.3を試すときの注意もあり、cat in.txt | ./a.outのようにパイプで渡すとsys.stdin.read()が空文字列を返しました。./a.out < in.txtのようにファイルからリダイレクトすれば読めます。

結論として、AtCoder向けのコードは0.19.3で確かめます。インストールの章の手順で0.19.3を別の場所に入れ、AtCoderと同じcodon build --release -o a.out Main.pyでコンパイルしてから入力例を流すのが確実です。0.20.4に-numerics=cを付けても、割り算以外の差（小数の表示、入力の関数）は残ります。

並列化とGPU：@parのOpenMPとNvidia限定のGPUバックエンド

@parによるマルチスレッド化

from sys import argv

def is_prime(n):
    factors = 0
    for i in range(2, n):
        if n % i == 0:
            factors += 1
    return factors == 0

limit = int(argv[1])
total = 0

@par(schedule='dynamic', chunk_size=100, num_threads=16)
for i in range(2, limit):
    if is_prime(i):
        total += 1

print(total)

codon run -release primes.py 100で実行すると、100未満の素数の個数として25が表示されます。ループ直前の@parがOpenMPによる並列実行の指定で、num_threads、schedule（static、dynamic、guided、auto、runtime）、chunk_size、ordered、collapseを指定できます。total += 1のような累積はコンパイラがリダクションに変換するので、アトミック操作を書く必要はありません。並列区間の中でリストや辞書を書き換える場合はロックで保護する必要があると公式ドキュメントが注意しています。反復ごとの処理時間が均一ならstatic、ばらつくならdynamicが基本です。

GPU実行の要件：NvidiaデバイスとCUDA

import gpu

@gpu.kernel
def add(a, b, c):
    i = gpu.thread.x
    c[i] = a[i] + b[i]

a = [i for i in range(16)]
b = [2*i for i in range(16)]
c = [0 for _ in range(16)]
add(a, b, c, grid=1, block=16)
print(c)

GPUバックエンドが対応するのはNvidiaのデバイスだけで、CUDAが必要です。Codonはlibcuda.soを自動で読み込み、標準の場所に無ければ環境変数CODON_CUDAで指定します。カーネルを書かずに@par(gpu=True)でループをGPUへ流すこともできます。v0.20.0でfloat16とbfloat16が加わりました。カーネルの中では例外処理とファイルI/Oが使えないので、前処理はCPU側で済ませて計算だけを渡します。Apple、AMD、IntelのGPUはロードマップの段階です。

Codonを選ぶ基準と、見送ったほうがよい条件

Codonが効くのは、処理時間の大半がPythonのループと関数呼び出しで消えているコードです。再帰、数値計算、文字列の走査のように、CPythonのバイトコード実行とオブジェクト生成がボトルネックになっている箇所では、書き換えを抑えて速くできます。倍率は対象のコードと環境で変わるので、自分のコードで-release付きで測ってから判断します。

次のどれかに当てはまるなら、採用は見送ったほうが確実です。

• Windowsネイティブで動くことが要件。WSLを挟めない環境では動きません。
• pandas、scipy、requestsのようなライブラリが処理の中心。from python importで呼べますが、その区間はCPythonの速度です。
• 任意精度整数に依存し、整数幅を事前に決められない計算。桁あふれしても例外が出ないので、暗号や会計の計算では結果が誤ったまま進みます。
• 実行時のメタプログラミングに頼る設計。プラグイン機構やORMのような作りは型検査を通りません。
• 1回の実行が短いバッチをcodon runで回す運用。毎回のコンパイル時間が短縮分を上回るので、codon buildで実行ファイルを作っておきます。

既存のプロジェクト全体を移すところから始めるのは勧めません。プロファイラで特定した重い関数を1本だけ@codon.jitで切り出し、入出力を数値・文字列・NumPy配列に絞り、ループを関数の中に入れて呼び出し回数を減らすところから試すと、効果と手間が読みやすくなります。書き換えをさらに減らしたいなら型宣言なしで動くNumbaとは？Pythonを高速化するJITコンパイラの使い方とインストール、C拡張として既存の資産と混ぜたいならCythonとは？使い方・インストールと型宣言の効果を実測（Cython 3.3対応）が比較の候補です。Pythonで書いた業務システムの処理速度が課題になっている場合は、フルスクラッチ開発の中で構成から見直す方法もあります。

よくある質問

Codonの読み方と意味は？

読み方は「コドン」です。分子生物学ではmRNA上の3つの塩基の並びで、アミノ酸か翻訳の終わりを指定する単位を指します。ソフトウェアの文脈では、この記事で扱っているExaloop社のPython互換コンパイラの製品名です。検索で両方が混ざるときは「codon python」や「exaloop codon」のように語を足すと絞り込めます。

CodonはWindowsで使えますか？

ネイティブでは使えません。公式ドキュメントはLinuxとmacOSをサポート対象とし、WindowsではWSL経由を勧めています。インストーラもLinuxとmacOS以外では事前ビルド済みのバイナリが無いというエラーで終了します。Windowsネイティブ対応はロードマップに載っていますが、提供時期は示されていません。

CodonはどれくらいPythonより速くなりますか？

公式ドキュメントの計測ではfib(40)で46倍（M1 MacBook Pro、python3.13との比較）、@codon.jitを使った素数判定の例で約40倍です。ただし-releaseを付けないと最適化が効かず、@codon.jitで小さな関数を何万回も呼ぶ形では変換のコストで効果が大きく減ります。ライブラリの呼び出しが中心のコードではほとんど変わりません。

AtCoderでCodonは使えますか？

使えます。言語一覧に「Python (Codon 0.19.3)」があり、codon build --releaseでコンパイルされます。0.19.3は負の数の割り算と剰余が0方向の丸めで、printの小数が6桁になり、sys.stdin.readlineも使えません。手元の検証は最新版ではなく0.19.3で行ってください。

pip install codonでインストールできますか？

できません。PyPIのcodonは分子生物学向けの無関係なパッケージです。コンパイラ本体は公式インストーラで入れ、Pythonのコードから関数単位で使う場合は本体を入れたあとでpip install codon-jit numpyを実行します。

関連記事

• Cython・Codon・Mojo実測比較｜Pythonコードは何倍速くなるか
• Cythonとは？使い方・インストールと型宣言の効果を実測（Cython 3.3対応）
• Numbaとは？Pythonを高速化するJITコンパイラの使い方とインストール
• Mojoとは？PythonスーパーセットのAI向け言語をfn/def・所有権・採用判断まで実装視点で解説
• WSL2とは？WSL1との違い・仕組み・インストール手順【WSL 3.0対応・2026年10月】