CodeGen を採用前に読む: モデル重みと Jaxformer の分離構造

CodeGen が埋めようとしているのはモデル配布と学習コードの断絶

プログラム合成モデルを自前で扱おうとすると、重みの入手経路、トークナイザの互換性、学習スクリプトの依存関係という三つの障壁が別々に立ちはだかる。CodeGen はこのうち重みの公開と学習ライブラリの公開を担当し、モデルの配信自体は Hugging Face Hub に委ねる構成を取っている。README によれば CodeGen1 と CodeGen2 の 350M、1B、3B、7B、16B が公開対象で、2022 年 3 月の CodeGen1.0 は当時の OpenAI Codex と同等と位置づけられ、2023 年 5 月の CodeGen2.0 では infill sampling が強化され、2023 年 7 月の CodeGen2.5 は 7B で 16B パラメータモデルを上回ると記載されている。想定読者は、コード生成モデルを評価したい研究者と、自前のデータでファインチューニングを試したいエンジニアである。逆に、API 経由でコード補完を即座に製品へ入れたい開発者は対象外で、このリポジトリには推論サーバやエディタ統合が含まれていない。

モデル重みは Hub、学習は Jaxformer という二分割

リポジトリの構造を README から読み取ると、CodeGen 本体はモデルの重みとその読み込み例を提示する場所であり、データ前処理、学習、ファインチューニングは Jaxformer という別リポジトリ (https://github.com/salesforce/jaxformer) が担う。つまりデータフローは、Jaxformer 側で前処理と学習を行い、成果物としての重みを Hugging Face Hub に公開し、利用者は transformers 経由でそれを読み込む、という流れになる。この分離には実務上の意味がある。推論だけを試す人は Jaxformer を触る必要がなく、逆に学習を再現したい人は CodeGen リポジトリだけでは完結しない。CodeGen1 は AutoTokenizer と AutoModelForCausalLM をそのまま使う例が示されているのに対し、CodeGen2.0 では trust_remote_code=True と revision="main" を指定する例になっており、CodeGen2.5 でも trust_remote_code=True が付く。この違いは、モデル側でカスタムコードの実行を許容するかどうかが世代間で変わっていることを示しており、社内のセキュリティ方針によっては CodeGen1 系のほうが扱いやすい可能性がある。

動かすまでの手順は世代ごとに微妙に異なる

README が示す推論コードは三世代分あり、いずれも transformers の AutoTokenizer と AutoModelForCausalLM を使う。CodeGen1.0 の例では Salesforce/codegen-2B-mono を読み込み、tokenizer("# this function prints hello world", return_tensors="pt") でプロンプトを組み、model.generate(**inputs, max_length=128) を呼び、tokenizer.decode に truncate_before_pattern=[r"\n\n^#", "^'''", "\n\n\n"] を渡して出力を切り詰める。CodeGen2.0 では Salesforce/codegen2-7B を trust_remote_code=True, revision="main" 付きで読み込み、同じ truncate_before_pattern を使う。CodeGen2.5 では Salesforce/codegen25-7b-mono を trust_remote_code=True で読み込み、decode には切り詰めパターンを渡さない。モデル名の命名規則も揃っておらず、CodeGen1 と 2.5 は codegen-2B-mono や codegen25-7b-mono のように小文字とハイフン、CodeGen2 は codegen2-7B のように大文字 B を含む。設定キーとして明示されているのは trust_remote_code と revision の二つだけで、量子化やデバイスマップの指定は README には現れない。GPU に載せるための追加設定は自分で補う必要がある。

世代間の性能主張は README の News 節にしか根拠がない

CodeGen2.5 が 7B で 16B パラメータモデルを上回るという記述は README の News 節に一行で置かれているだけで、比較対象のモデル名、ベンチマーク名、評価条件は本文には示されていない。CodeGen1.0 についても「当時の OpenAI Codex と同等」という表現にとどまり、数値は記載されていない。論文は二本引用されており、CodeGen は ICLR 2023、CodeGen2 も ICLR 2023 となっているが、CodeGen2.5 に対応する論文の引用は README には見当たらない。したがって、あるタスクで CodeGen2.5 を選ぶべきかどうかを README だけで判断するのは無理がある。性能の主張を根拠にするなら、引用された arXiv の論文を読み、自分の評価セットで測り直す工程が必須になる。リポジトリにベンチマークスクリプトや評価用データが含まれているという記述も README にはない。

このリポジトリが答えを持たない領域

README の末尾には Salesforce AI モデル共通の倫理免責事項があり、このリリースは学術論文を支援する研究目的のもので、すべての下流用途を想定して設計・評価したものではないと明記されている。精度、安全性、公平性に関する懸念はデプロイ前に利用者自身が評価すべきだとされ、高リスクなシナリオでは特に注意が求められている。ライセンスは Apache-2.0 とされているが、この免責事項の存在は、ライセンスが許諾する範囲と Salesforce が想定する用途の間にずれがあることを意味する。商用利用の可否を判断するには、Apache-2.0 の条文だけでなく、参照されている AUP と AI AUP を確認する必要がある。ここは法的助言ではないので、最終判断は自組織の法務に委ねるべき領域である。もう一つの制約は、CodeGen がコード補完専用に作られた世代を持つ一方で、CodeGen2 の論文タイトルが示すように自然言語とプログラミング言語の両方を扱う設計になっている点で、汎用チャットモデルとして使うことは想定されていない。

比較対象としての StarCoder 系との違い

同じくコード生成を目的とした公開モデルとして StarCoder 系が知られているが、CodeGen との差は学習と配布の設計にある。CodeGen は学習ライブラリを Jaxformer として切り出し、JAX と TPU-v4 を前提とした学習経路を公開している。トピックにも tpu-acceleration が含まれており、TPU 環境での学習を想定した構成であることがうかがえる。これは、GPU クラスタを前提にファインチューニング手順を整備しているモデルとは前提が異なる。もう一つの差は世代の設計思想で、CodeGen2.0 では infill sampling が強化されたと README に記載されており、コードの穴埋めタスクを明示的に意識している。つまり CodeGen を選ぶ理由は、モデル単体の性能よりも、Jaxformer を含む学習経路と infill の扱いを自分で制御したいかどうかに寄っている。逆に、学習環境を触らず推論だけを回したい場合、この分離構造は利点にならない。

維持コストと更新の見通し

リポジトリはアーカイブされておらず、最終 push は 2026 年 6 月 2 日と記録されている。ただし取得できた範囲ではリリースが存在せず、バージョンタグやチェンジログにも言及がない。更新の実態は README の News 節と、codegen25 ディレクトリの追加のようなコミット単位でしか追えない。これは運用上のコストに直結する。依存する transformers のバージョンを上げたときに trust_remote_code=True で読み込むカスタムコードが動き続ける保証は、リポジトリ側からは与えられない。モデル重みは Hugging Face Hub 側でホストされているため、リポジトリが更新されなくても重みの取得は続けられるが、逆に言えば Hub 上のリビジョン指定を固定しないと再現性が失われる。CodeGen2.0 の例が revision="main" を指定しているのは、まさにこの可変性を明示している。バージョンを固定して使うなら、revision にコミットハッシュを渡す形へ書き換える必要がある。

編集部の結論

研究や論文再現、あるいは自前のファインチューニング実験の出発点として CodeGen を検討するなら、まず Hugging Face Hub 上のモデルカードと trust_remote_code の要否をバージョンごとに確認し、次に jaxformer リポジトリの学習手順が現在の JAX 環境で再現できるかを試すべきである。逆に、コード補完を製品に組み込む目的でこのリポジトリを選ぶのは筋が悪い。README は推論コードを提示するが、モデル配信は Hugging Face Hub 側で行われており、リポジトリ自体にはサービング用の仕組みがない。またリリースノートやバージョンタグは取得できておらず、更新履歴は README の News 節に依存している。採用を決める前に、利用予定のモデルサイズが手元の GPU メモリに収まるか、CodeGen2.5 の 7B が 16B 級を上回るという主張が自分のタスクでも成り立つかを、実際のプロンプトで確かめる必要がある。

公式情報源

1. Issues
2. License: Apache-2.0
3. README
4. salesforce/CodeGen on GitHub