Java Native Accessとは？警告の意味と許可方法を解説

まず「Java native access」は、JavaからOSのネイティブ機能やC/C++ライブラリへアクセスする仕組み全般を指します。例えばJNIや、近年整備が進むFFM API（Foreign Function & Memory API）などが該当します。2025年時点の動向としては、ネイティブアクセスの安全でない利用に対して、JDKが警告を出す方向へ進んでいます。

しかし、開発中に突然「restricted method」や「native access」関連の警告が出ると、何を直すべきか迷いやすいです。そのため本記事では、警告の意味、許可の考え方、運用での最小リスクな対応までを整理します。

Java Native Accessで何が起きているのか

まず、JavaはJVM上で動くため、本来はOSのネイティブ領域へ直接触れません。ところが実務では、暗号・圧縮・画像処理・端末制御などで、ネイティブライブラリを使うことがあります。そこで登場するのがJNI（Java Native Interface）やFFM APIです。

さらに、ネイティブ領域に触れる操作は、誤るとJVMのクラッシュやメモリ破損につながります。つまり「例外で安全に落ちる」とは限らず、気づかないまま不具合が潜むリスクがあります。したがってJDKは、危険度の高い呼び出しに対して警告を出し、利用者が意図を持って許可できるようにしています。

例えばOracle公式ドキュメントでは、FFM APIの一部メソッドが「制限されたメソッド」として扱われ、呼び出されると警告が表示されることが明記されています。その上で、警告なし利用のために --enable-native-access が案内されています。

JNIとFFM APIの違い（ざっくり）

一方で、JNIは歴史が長く、多くの既存ライブラリが利用しています。対してFFM APIは、Java側からより安全にネイティブ関数やメモリへアクセスするための新しい仕組みです。つまり「既存のJNIをすぐ捨てる」話ではなく、用途に応じて段階的に安全な選択肢へ寄せていく流れだと捉えるのが現実的です。

よくある警告メッセージと原因

次に、開発やCIで遭遇しやすいのが「A restricted method has been called」のような警告です。これは、JDKが「制限されたネイティブ操作（または危険な操作）」を検知したことを示します。とくに System.load や System.loadLibrary を内部で呼ぶ依存ライブラリがあると、アプリ側が直接書いていなくても警告が出る場合があります。

さらに厄介なのは、警告の発生源が「自分のコード」ではなく「依存ライブラリ」であるケースです。そのため、原因切り分けではメッセージに出る「呼び出し元のクラス名」「JAR名」「モジュール名（unnamed module等）」を確認するのが近道です。

典型例：ネイティブライブラリを読み込むコード

例えば、ネイティブ連携の入口としては次のような記述がよくあります。これ自体が直ちに悪いわけではありませんが、運用で「許可の範囲」を意識する必要があります。

System.loadLibrary("mylib");

そのため、警告が出たら「どのライブラリが読み込みを行っているか」を特定し、必要最小限の許可を与える設計に寄せます。

許可の基本：--enable-native-access を理解する

まず、ネイティブアクセスに関する許可は「全部OK」にすると運用が楽に見えます。ところが範囲を広げすぎると、意図しないネイティブ操作まで黙認することになります。したがって推奨は「必要なモジュールだけ許可する」です。

例えばOracle公式では、モジュールMのコードに対して警告なし利用を許可するには、次のように指定できると説明されています。クラスパス上のすべて（名前なしモジュール）を許可したい場合は ALL-UNNAMED を指定します。

java --enable-native-access=ALL-UNNAMED -jar app.jar

しかし、ALL-UNNAMED は範囲が広い指定です。可能なら、モジュール名で明示的に許可するほうが安全です。例えばモジュール化されたアプリなら、次のように「必要なモジュールだけ」を指定します。

java --enable-native-access=com.example.app -m com.example.app/com.example.Main

実務の判断基準：誰が許可を持つべきか

さらに実務では「開発者」だけでなく「運用者」も関わります。なぜなら、許可オプションは起動パラメータであり、デプロイや起動スクリプトの責務に入るためです。そのため、警告を握りつぶすのではなく、次の観点で合意しておくと事故が減ります。

• どの依存ライブラリがネイティブアクセスを必要としているか
• 許可範囲は最小化できているか（ALL-UNNAMEDの乱用を避ける）
• 本番環境での再現条件（OS差分、コンテナ差分）は何か

実行JARの場合：Enable-Native-Access マニフェスト属性

次に、実行JAR（fat jar等）で配布する場合、起動オプションを追加できない環境もあります。そこで、JEP 454では、実行JARのマニフェスト属性 Enable-Native-Access によって、特定条件で警告なし利用を可能にする仕組みが整理されています。

例えば、実行JARのマニフェストに次のような属性を入れることで、クラスパス上のコードに対して許可を与える使い方が説明されています。運用上は「起動オプションをいじれない」状況で役立つ一方、適用範囲や配布形態の制約がある点には注意が必要です。

Enable-Native-Access: ALL-UNNAMED

したがって、アプリの配布方式がJAR中心なら「起動オプション」か「マニフェスト」かを選べる設計にしておくと、環境差分に強くなります。

セキュリティと品質の観点：なぜ制限が強化されるのか

一方で「なぜ今さら厳しくするのか」と感じるかもしれません。背景には、ネイティブ操作がJVMの整合性（integrity）を破壊しうるという根本的なリスクがあります。つまり、同じJVM上で動く複数コンポーネントの安全性を保つには、危険な入口をデフォルトで抑える必要があるのです。

さらにJEP 472は、まず警告を出して開発者に気づかせ、将来の一貫した制限へ備える目的を明確にしています。したがって、現時点での最適解は「必要な場所だけ許可し、許可の理由を残す」運用です。

現場での対応手順（最短ルート）

まず、警告が出たらログから「呼び出し元（どのクラス／どのJAR）」を特定します。次に、そのライブラリが本当にネイティブアクセスを必要とするか確認します。さらに、必要なら許可方法を選びます。

• 起動オプションで許可できる：--enable-native-access=対象
• 配布JAR側で吸収したい：マニフェストの Enable-Native-Access
• 依存更新で解消できる：ライブラリの最新版や代替を検討

そのため、CIでは「警告をエラー扱いにするか」「許可を明示して通すか」を方針化すると、環境ごとの差分で詰まりにくくなります。

まとめ

最後に、Java native access はJNI/FFMなどを通じてネイティブ領域へ触れる仕組みです。だからこそJDKは警告で可視化し、将来的には必要箇所だけ許可する方向へ進んでいます。まずは発生源を特定し、--enable-native-access を最小範囲で適用する運用に寄せていきましょう。