AI時代、配布するPythonコードをどう守るか: 難読化の実験と判断軸
実務で、Pythonで開発した業務用ツールを顧客環境やオンプレミス環境に配布する機会がありました。その際、配布先でコードを動かす必要がある一方で、業務ロジックや実装上の工夫をそのまま開示したくない、という課題がありました。そこで選択肢になったのが、Pythonコードを読みにくくして解析コストを上げるPyArmorによる難読化です。
難読化は暗号化とは異なり、「読める/動くが、理解しづらい」状態にする技術です。完全に秘密を守るものではありません。では、AIによるコード生成・解析が一般化し、リバースエンジニアリングの容易化が議論される現在、コードを「読みにくくする」対策はどこまで有効なのでしょうか。
本発表では、PyArmorで難読化したPythonコードを題材に、暗号化と難読化の違い、元コードを取り戻す「復元」と、同じ振る舞いを作る「再現」の違いを整理します。そのうえで、pyarmor gen により生成される pyarmor 呼び出しとランタイムバイナリの役割、実行時のPythonオブジェクトやコードオブジェクトに残る関数名・変数名・定数・型注釈などの手がかりを観察します。さらに、デフォルト設定と追加の保護設定で残る情報がどう変わるのか、それらをAIに与えた場合に処理内容をどこまで推測・再現できるのかを検証します。
検証結果をもとに、難読化に任せてよい範囲、追加の保護を検討すべき情報、サーバー側に寄せるべき情報を整理します。難読化済みコードであっても、機密性の高い文字列や秘密情報を埋め込んでよいわけではありません。Pythonコードを外部配布する開発者に向けて、AI時代に難読化を使う際の現実的な判断軸を共有します。
このトピックに関するあなた自身の経験を教えてください
私は実務で、Pythonで実装されたコードを外部環境に配布・実行してもらう構成を検討する中で、ソースコード保護の必要性と限界を考える必要がありました。単に「PyArmorで難読化すればよい」とは考えず、デフォルト設定では関数名・変数名・定数・型注釈などの手がかりがどの程度残るのか、関数名や変数名を変換するオプションを使うことで何が変わるのか、ライセンス種別によって選べる保護手段がどう変わるのかを比較しながら検証しました。
また、生成されるファイル構造、pyarmor とランタイムバイナリの役割、実行時にCPython上へ現れる情報を調査し、元コードを完全に復元できなくても、AIを用いて同等の動作を再現できる可能性を確認しました。本発表では、実務上の制約、ライセンス、保護したい情報の性質、解析コストのバランスを考えながら試行錯誤した経験をもとに、Pythonコードを難読化して配布する際に何を確認し、どこに注意すべきかを共有します。
この発表を通じて、参加者とどんな議論が可能ですか？
難読化は、多くのPython開発者にとって日常的に使う技術ではないと思います。一方で、Pythonコードを顧客環境やオンプレミス環境に配布する実務では、「動かしてもらう必要はあるが、実装の詳細はそのまま開示したくない」という場面が実際にあり、その選択肢として難読化が使われることがあります。
そのような場面で、難読化は何を守れて、何を守れないのか。秘密情報をコードに埋め込むべきでない理由、サーバー側に寄せるべき処理の見極め方、AIによってコード解析のハードルが下がる中での防御線の引き方について議論できます。難読化そのものの経験がなくても、セキュリティや知財保護に関心のある方々に対し、実務上のリスク感覚や対策の落とし所を共有できる発表にしたいです。
株式会社PKSHA Technology のソフトウェアエンジニア。2026年に新卒入社し、現在は AI Research & Solution 事業部でシステム開発を担当。
大学院時代は自然言語処理（NLP）の研究に取り組み、NLPIR 2025にてBest Student Paper賞およびBest Presentation賞を受賞。PyCon JP は今回が初登壇。趣味はピアノとボルダリング。
wantedly: https://www.wantedly.com/id/shunsuke_yamamoto_an