はじめに

Pythonの柔軟性は、実行時にモジュールや関数を読み込む「動的import」という形でも発揮される。
とくにプラグイン機構・構成駆動の実装・動的ディスパッチなどで多用されるが、
静的解析・依存可視性・セキュリティ制御が弱くなりがちという構造的リスクがある。

レビューアーは、こうした構造に遭遇した際、単なる「importの使い方」ではなく、システム全体への波及リスクを評価する視点を持つ必要がある。

動的importの典型例とその背景

importlib使用例 
import importlib

def load_handler(name: str):
    module = importlib.import_module(f"handlers.{name}")
    return module.Handler()

これは柔軟な構造を実現する一方で、以下のような特徴を持つ。

  • ハンドラ名の指定は文字列であり、IDEや型検査から隠れる
  • handlers/配下の存在がコード上では明示されない
  • import失敗・存在チェック・初期化例外などが実行時まで分からない
Comment 
@Reviewer: モジュール指定が文字列化されており、静的解析や型検査の恩恵が受けられません。全候補の列挙や明示的マッピングが望ましいです。

レビュー観点1：可視性とトレース性の確保

動的import構造は、誰が・どこから・どのモジュールを使っているかの可視性が著しく低い。
とくにimportlib.import_moduleや__import__を使っている場合、依存関係をツールで検出するのが困難になる。

__import__の使用 
mod = __import__("tools.dynamic_tool")
Comment 
@Reviewer: `__import__()` による読み込みは依存解決ツールやIDEが解析できず、保守性が下がります。明示的な構成ファイルまたはリスト化された定義からの読み込みが望ましいです。

レビュー視点：

  • importlibや__import__の使用箇所は最小限か？
  • モジュール名の列挙・管理が明示的に設計されているか？
  • デバッグ・スタックトレースで追える設計になっているか？

レビュー観点2：セキュリティ制御の脆弱性

外部入力に基づいて任意モジュールをimportしている構造は、任意コード実行のリスクを孕む。

危険な動的import 
def load_from_input(modname: str):
    mod = importlib.import_module(modname)
Comment 
@Reviewer: `modname` が外部入力に由来する場合、意図しないモジュールの読み込みやファイル実行が発生する可能性があります。安全な名前空間制限とホワイトリスト化が必要です。

安全な設計例：

ホワイトリストによる制限 
ALLOWED_MODULES = {"json_handler", "xml_handler"}

def safe_import(name: str):
    if name not in ALLOWED_MODULES:
        raise ValueError("Invalid handler name")
    return importlib.import_module(f"handlers.{name}")

レビュー観点3：型安全性・IDE支援の欠落

動的importされたモジュールやクラスは、型ヒントや補完の対象外となるため、レビューでも誤用に気付きにくい。

型安全性の問題 
handler = importlib.import_module("handlers.foo").Handler()
handler.run()
Comment 
@Reviewer: `handler` の型が明示されておらず、IDEの補完や型検査が効きません。明示的にProtocolやBaseHandler継承を前提とした型アノテーションが望まれます。
Protocolによる補完支援 
class HandlerProtocol(Protocol):
    def run(self): ...

def load_handler(name: str) -> HandlerProtocol:
    ...

レビュー観点4：importの失敗・初期化不全への対策

importが失敗した場合の挙動がキャッチされていない設計は、ランタイムクラッシュを招く。

例外未処理の動的import 
mod = importlib.import_module(f"plugins.{name}")
Comment 
@Reviewer: モジュール読み込みに失敗した際の例外補足がありません。初期化処理や依存モジュールの不備によって実行時例外が発生するリスクがあります。
例外処理を含む安全な読み込み 
try:
    mod = importlib.import_module(f"plugins.{name}")
except ModuleNotFoundError:
    log.warning(f"No such plugin: {name}")
    raise

レビュー観点5：プラグイン機構と構成ファイルの役割

動的importを用いたプラグイン構造では、構成ファイルによる制御とimportの分離が必要である。
構成ファイルによってロード対象や順序・依存関係を明示し、コード側はそれに従って実行するだけにする設計が望ましい。

plugins.yaml 
- name: logging
- name: telemetry
- name: audit
動的importの構成駆動化 
def load_plugins(config_path: str):
    for item in yaml.safe_load(open(config_path)):
        name = item["name"]
        mod = importlib.import_module(f"plugins.{name}")
        mod.init()
Comment 
@Reviewer: 構成ファイルによる制御は可視性を高める良設計です。import対象の制限や順序制御も明示されており、保守性が向上しています。

補助視点：レビュー時に問うべき設計意図

  • なぜ動的importを選んだのか？（構成駆動？再帰的処理？プラグイン化？）
  • 読み込まれる対象がどこに定義されているかが明示されているか？
  • import失敗時のハンドリング方針が定められているか？
  • セキュリティ上の制限（スキャン対象、アクセス制御）が設けられているか？

レビュー観点チェックリスト

動的import構造のレビュー項目
  • モジュール名が外部入力に依存していないか？
  • 明示的なホワイトリストや構成ファイルによって対象が限定されているか？
  • import失敗や初期化失敗時の例外処理があるか？
  • 型安全性を確保するためのProtocolやABCが導入されているか？
  • IDE補完や静的解析に支障をきたさない工夫があるか？
  • セキュリティ上、想定外のファイル・モジュールへのアクセスが制限されているか？

おわりに

動的import構造は、柔軟性と引き換えに可視性・安全性・解析可能性を損なう危険な刃でもある。
レビューアーはその設計意図に立ち返り、「なぜ静的importで完結しないのか？」「どこまで柔軟性が必要なのか？」を問い直す必要がある。

特にプラグインや構成駆動の仕組みでは、import対象の明示性と制御性こそが品質を支える基盤であり、それが欠けている場合は早期に指摘・修正を促すべきである。