GPUなしの閉域AIをどう検証したか、IPA卒業プロジェクトの統制と限界

信頼を、点検できる条件に置き換える

プロジェクトの出発点は、AIを危険だと感じる背景に、内部で何が起きるか分からず、自分たちで評価・統制できない問題があるのではないか、という問いだ。そこでモデルの回答精度だけを比べるのではなく、推論エンジン、認証、暗号通信、ソフトウェア供給網、ログなどを横断して検証する。

公開ページは2026年3月のaxiosを巡る供給網攻撃も背景に挙げる。正規の配布経路を使っているというだけでは、依存する部品の安全性をすべて確認したことにはならない。同様に、AIサービスの名前や評判だけで、内部の構成や処理条件まで把握したことにはならない、という問題意識である。

ただし、クラウドの内部が見えにくいことから、ローカルなら自動的に安全だという結論には進まない。手元に置けば、自分で把握し、保守し、判断する責任が増える。その責任を果たす仕組みを実証した点に、このプロジェクトの読みどころがある。

三つの枠組みを、設計上の責任へつなぐ

リスク整理にはNIST AI RMF、英国政府のFutures Toolkit、ISO/IEC 42001が使われる。現在のAIリスク、将来の環境変化、組織のマネジメントをそれぞれ参照し、独自のICS-XAFへ落とし込んだ。成果物PDF

ICS-XAFの五層は、物理、通信、実行、モデル制御、データ・運用ガバナンスを整理する。部品ごとに機能を並べるだけでなく、誰がどの範囲を確認・制御するかという責任の境界を考える構成だ。入力に含まれる誘導への対策などは、モデルの指示だけでも、ネットワーク設定だけでも完結しない。

この仕組みでは「コントロール可能性」と「コンテキスト耐性」が重要な軸になる。前者は自ら把握して管理できること、後者は周囲の条件が変化しても運用を維持できることに関係する。外部APIの変更、供給の停止、規制や脅威の変化を想定し、現在動くことだけを合格基準にしない。

なお、既存規格を分析に使ったことと、その規格への準拠が公的に証明されたことは別である。成果物の冒頭も、規格や法令への適合を公認するものではなく、特定環境での概念実証だと明示している。NIST AI RMF、ISO/IEC 42001

GPUのないサーバーで、何を確かめたか

実証機はIntel Xeon E5-2690 v4を2基、128GBのDDR4メモリーを備えたリユースサーバーで、GPUは搭載しない。Debianを使い、llama.cppなどのOSSで推論基盤を構成する。画像や音声も含む処理を試し、21件のシナリオで有効性と限界を検証した。

この選択を「古い機材でも最新クラウドAIと同等」と受け取るのは適切でない。高性能な新規機材を購入することより、既存の資産で構成を理解し、検証を再現できるかに焦点がある。処理速度、扱えるモデル、同時利用数などは、機材や設定によって大きく変わる。

企業が参考にする場合も、機種名が同じだけで性能や安全性を引き継げるわけではない。モデルの種類、量子化、文章の長さ、メモリー使用量、利用者数を合わせて測る必要がある。資料に載る特定の実証を、自社のすべての用途への保証として使うことはできない。

また、コードやモデルを取得できることと、来歴を完全に確認できることは異なる。ローカルで推論しても、事前学習データがどう集められたかまで自動的に分かるわけではない。どこまで検証でき、どこから外部への信頼が残るかを分けて記録する必要がある。

閉域化は、外部通信を一行ずつ確かめる作業

実証ではAIDEによる変更の検知、SBOMによる構成の把握、LynisによるOS監査、AI-IDEによるコードのレビューを組み合わせる。どれか一つの診断結果だけで安全を判定しない。実装と運用条件を重ねて確認する構成だ。

興味深いのは、AIがコードを監査した初回の指摘と、その後の人による判断を掲載している点だ。監査は外部のRSS取得、接続先を環境変数で変えられる経路、履歴の取得、部品のバージョン記録などを問題として挙げる。成果物は、それらを修正するもの、誤検知と判断するもの、残存するリスクとして受け入れるものに分けて説明する。

AIの指摘が多いことは、実際の脆弱性が同じ数だけ存在することを意味しない。例えば、ネットワークの隔離、プロセスの権限、前段の認証といった条件を見ずに一部分のコードだけ読むと、危険性を過大にも過小にも評価し得る。逆に、運用側が想定した条件が崩れた場合に指摘が有効になることもある。

このため「AIが監査したので安全」ではなく、何を指摘し、どの事実を基に人が判断し、その判断をどの条件で維持するかを残すことが重要になる。同じAIが生成と監査の両方に関わる場合は、とくに独立した確認や別の観点を加える意味がある。

SBOMと更新作業が、閉域の外側に残る

SBOMは使う部品とバージョンを一覧にするための手段だが、ファイルが一つ存在するだけで完全ではない。推移的な依存、実際に導入した版、取得元、ハッシュ、ビルド条件が欠ければ、脆弱性情報が届いたときに自社へ関係するか判断しにくい。

外部通信を止める環境でも、更新のために何を持ち込むかという入口は残る。モデル、ライブラリ、証明書などの更新を、誰が検証して導入するかを決めなければ、閉域であるという前提が形だけになる。外へ送信しない構成と、入ってくるものを信頼できる構成は別の課題だ。

成果物では、監査ツールが挙げた警告に対し、閉域で想定される動作かどうかを判断している。ただし、そこでの受容判断を異なる会社へそのまま移すべきではない。接続範囲、端末の管理者、持ち込みファイルの種類が変われば、同じ設定の意味も変わる。

運用者が見るべきなのは、回答の外側にもある

モデルを手元で動かしても、誤情報が出ないわけではない。監査ログに機微な入力が蓄積する問題、閲覧権限、保存期間、バックアップの管理も残る。クラウドへ送らないことが利点になる用途ほど、手元に残るデータを誰が見られるかを丁寧に設定する必要がある。

例えば内部構成を含む脆弱性情報や業務帳票を処理する際、入力を外へ出さない価値はある。一方、生成された評価や要約が正しいかは、別途原資料に戻って確かめなければならない。情報の機密性と回答の正確性は異なる評価軸であり、一方への対策だけでは両方を満たせない。

複数のモデルを裏側で振り分けるサービスでは、どのモデルへ情報が渡ったかが見えにくくなることもある。利用者に一つの入口が見えるとしても、その先の処理経路が一つとは限らない。自社運用でも外部サービスでも、経路の記録と変更の把握が継続的な統制につながる。

21件の試験を、万能な合格率にしない

成果物の検証マトリクスは、テキスト対話と業務領域の理解、RAG、入力による誘導への対処、アクセス制御、可用性、改ざん検知、画像・音声、耐量子暗号の通信などを対応づける。21件は一つの能力を同じ条件で21回測った数字ではなく、異なる要件へ割り当てた試験の数である。

例えば、専門領域の質問に答えられることと、入力を不正な操作へつなげないことでは合格条件が違う。文書を検索して回答するRAGでも、参照した原文が正しいか、必要な箇所を取り出せたか、回答へ正しく反映したかを分ける必要がある。単に文章が返ったという結果だけでは、業務上の要件を満たしたと判断できない。

閉域環境の可用性についても、外部サービスが使えない条件で処理を続けられるかという評価と、同時利用が増えた際に十分な速さかという評価は別だ。実証された場面と、まだ確かめていない負荷を区別すると、PoCの成果を適切な大きさで受け止められる。

企業が追加の試験を設計する際には、日常的な正常系だけでなく、資料がない、権限が足りない、入力が長すぎる、根拠が矛盾するといった場面も候補になる。回答できないときに停止・保留できるか、人へどの情報を渡すかまで見ると、導入後の担当者の負担を想像しやすい。これは本編集部の検証設計上の考察であり、当該成果物で同じ試験がすべて実施済みという説明ではない。

そして、監査で受容したリスクには見直しの条件を付けたい。閉域であることを理由に対応不要とした経路も、将来外部接続を追加すれば再評価が必要になる。「受容した」という一語を永久の安全判定にしないためには、前提条件と確認日を一緒に残すことが有効だ。

公開資料の利用条件と、実証の期限

成果物はTLP:CLEARとして公開され、一般の読者がアクセスできる。ただしTLPは情報共有の範囲を示す区分であり、著作権上の利用条件を消すものではない。文書に記載された転載・再配布・改変等の条件は別途確認する必要がある。本記事は資料を再配布せず、出典を示して事実と論点を独自に整理している。FIRSTのTLP説明

資料は2026年4～6月の実証を基にし、有効性の目安を発行から2年程度としている。その期間内でも技術や脅威の変化によって内容が合わなくなる可能性を明示する。暗号方式やモデルの来歴など、今後に残る課題もある。期限を記した資料であること自体が、継続的に確認し直す必要性を示している。

編集部の考察：小さな基盤でも、判断記録を残す

一般企業がこの実証から学べるのは、すぐに同じサーバーを購入することより、判断の証拠を残す方法だ。目的と扱う情報を決め、構成を固定し、通信を確認し、代表的な業務で試し、問題があれば原因と対応を記録する。その一巡を回せる範囲から始めることが現実的だ。

比較対象には、機材費だけでなく、担当者の保守、監査、更新、障害対応の負担も含める必要がある。クラウドとオンプレミスのどちらかを一律に安全と呼ぶのではなく、自社が管理できる条件と管理できない条件を比較した方が、導入後の説明責任を果たしやすい。

会社情報やAI基盤の業務利用についての相談先として、本媒体の運営会社RO合同会社の公式サイトを案内する。実証の構成を参照する場合も、独自のリスク評価、ライセンス確認、対象環境での検証が必要だ。

参考報道：イノベトピア。IPA公開資料を2026年10月23日に確認した。卒業プロジェクトの成果と、編集部の実務上の考察を区別している。