今日は、コード生成AIの「記憶」に関する、かなり重要な論文を取り上げます。2026年6月11日にarXivへ投稿された「Detecting Functional Memorization in Code Language Models」です。テーマは一言でいうと、コードモデルは訓練データを“そのまま暗記している”だけでなく、“同じ働きをするロジック”として覚えているのではないか、という問題です。(arxiv.org)
これまでLLMの記憶問題では、モデルが訓練データの文章やコードをどれだけ逐語的に再出力するかがよく調べられてきました。たとえば、GPT-2から訓練データの断片を抽出できることを示した研究や、大規模モデルの暗記がスケールに応じてどう現れるかを調べる研究があります。(arxiv.org) ただ、コードの場合は少し厄介です。変数名を変える、行を並べ替える、別の書き方にする。見た目は違っても、実行すると同じ処理になるコードはいくらでもあります。つまり、テキストの一致だけを見ていると、「覚えていないように見えるけれど、実は機能を覚えている」ケースを見逃す可能性があります。
今回の論文が提案するのが、この「functional memorization」、つまり機能的記憶という見方です。研究チームは、Olmo-3-32Bを使い、対象コードを見た途中段階のモデルと、まだ見ていない参照モデルを比較する反実仮想的な設定を作っています。プロンプトにはPython関数のシグネチャを与え、生成されたコードについて、テキストとしてどれだけ似ているかだけでなく、LLM-as-a-judgeや実行ベースの評価で機能的にどれだけ似ているかを測っています。論文の結論は、逐語的な一致では検出できない機能的記憶の証拠がある、というものです。(arxiv.org)
ここが面白いところです。もしコード生成AIが、単に「同じ文字列」を返すだけなら、重複除去や類似文字列検出である程度監査できます。しかし、モデルが「この関数はこういうロジックで動く」と内部化し、それを別の形で再構成できるなら、監査の対象は文字列から振る舞いへ移ります。著作権やライセンスの議論だけでなく、企業内コード、競技プログラミングの解法、脆弱性を含む実装パターンなど、実務上のリスク評価にも関わってきます。
この研究でOlmo系が使われている点も重要です。Ai2のOlmo 3は、最終モデルだけでなく、訓練段階のチェックポイント、データ、コード、評価ツールをできるだけ公開する「model flow」を重視しているため、途中段階のモデルと比較するような監査がやりやすい設計になっています。Ai2自身も、Olmo 3ではデータ、コード、モデル重み、チェックポイントを公開し、訓練データへのトレース可能性を重視していると説明しています。(allenai.org) これは、オープンモデルの価値が「無料で使える重み」だけではなく、「モデルが何をいつ学んだかを検証できること」に移っている、という流れを示しています。
もちろん、注意点もあります。今回の結果を、すべてのコードモデルにそのまま一般化するのは早いです。対象は特定のモデル、特定の設定、Python関数シグネチャを使った抽出実験です。また、LLM-as-a-judgeによる機能類似の判定には、評価器モデル自体のバイアスも入り得ます。実行ベース評価は強力ですが、テストケースが不十分なら「たまたま同じように見える」コードを見逃すこともあります。だからこの論文は、最終結論というより、監査方法を一段深くするための問題提起として読むのがよさそうです。
今後の焦点は、コードモデルの安全性評価が「出力が訓練データと何文字一致したか」から、「訓練データ由来の機能をどれだけ再現しているか」へ広がるかどうかです。コード生成AIが開発現場の中核になるほど、この違いは重くなります。見た目は新しいコードでも、機能としてはどこかの訓練データを引き出しているのか。それとも、一般化した知識から妥当な実装を作っているのか。今回の論文は、その境界線を測るための新しい物差しを提示したものだと言えます。
出典：arXiv「Detecting Functional Memorization in Code Language Models」、Ai2「Olmo 3」、Carlini et al.「Extracting Training Data from Large Language Models」、Biderman et al.「Emergent and Predictable Memorization in Large Language Models」。(arxiv.org)