セキュア・バンク、独自Cyber AI研究を第3段階へ
―「有益な再検証」と「情報を生まない反復」を区別する制御技術を初期検証

2026年8月24日に公開したプレスリリース「セキュア・バンク、独自Cyber AI研究を次の段階へ ― 実行結果を踏まえて再挑戦する仕組みを初期検証」では、実行結果を次の試行へ戻し、条件を変えて再挑戦できる構成を初期検証しました。

そこで確認できたのは、次の範囲です。

1. PoC候補の実行
2. 実行結果の観測
3. 結果を次の入力へ反映
4. 条件を変更して再試行

ここで用いているHarnessとは、AIとTool、評価環境をつなぎ、実行を制御する仕組みにあたるプログラムです。第2弾では、このHarnessが実行結果を次の試行へ戻せることまでを確認しました。

一方で、再挑戦できる構成にすると、別の問題が見えてきます。AIは失敗しても繰り返し挑戦しますが、その繰り返しが新しい情報を生んでいるのか、それとも同じ場所を回っているだけなのかを、仕組み自体は区別していないという点です。

今回は、この区別を扱う研究へ進みました。AIが賢くなったかどうかではなく、AIが繰り返している行動に意味があるのかを評価するための研究です。

今回、CyberGymの1課題において、攻撃推論チェーン――脆弱性の原因を分析し、検証方法を組み立て、実行結果までつなげる一連の処理――を最後までつなぎ、脆弱性の再現まで到達しました。

この課題では、直前の試行が失敗しています。失敗した版では、入力の終端に関する仮説自体は正しかったにもかかわらず、Tool側が意図した入力条件を実際には作れていませんでした。

1. 入力の終端に関する仮説を立てる
2. Toolが意図した入力条件を作れていない
3. 問題を再現できない

そこで、脆弱性を含む版と修正済みの版のコード差分（Patch Differential）を分析し、仮説そのものではなく、仮説を実際の入力へ変換するTool側に問題があると判断しました。

1. 脆弱性を含む版と修正済みの版のコード差分を分析
2. 仮説ではなくTool側の実現方法に問題があると判断

一般的な表現に言い換えると、AIの考え方が間違っていたのではなく、その考えを実際の入力へ変換するTool側に問題があったということです。

この判断にもとづき、Toolが入力を組み立てる方法を検証方針（Strategy）ごとに変更したうえで再検証したところ、意図した入力条件を実現でき、AddressSanitizerによってheap-buffer-overflowの発生を確認するところまで到達しました。

1. Toolの入力の組み立て方をStrategyごとに変更
2. 意図した入力条件を実現
3. AddressSanitizerでheap-buffer-overflowを確認

あわせて今回は、実案件4ケースのAI実行ログを解析しました。実際の案件でAIがどのように検証を繰り返していたかを、実行が終わったあとのログから評価する取り組みです。

ここで評価しているのがInformation Gain、すなわちAIが1回の検証によって、新しい判断材料をどの程度得られたかです。

実案件ログのうち1ケースでは、次の結果を確認しました。

Verification records

50

PROGRESS ＋ REVALIDATION

48 / 50

STAGNATION

0

Evidence Novelty

97.3%

このケースでは、50件の検証記録のうち37件がEvidenceを伴っており、そのうち36件が重複しない新しいEvidenceでした。Evidence Noveltyは97.3%です。

外形的には同じような検証を繰り返しているように見えても、新しいEvidenceを取得し続けている場合があるということです。研究上は、同じExecution Planであることがそのまま停滞を意味するわけではない、という示唆にあたります。今回はこれをUseful Revalidation（有益な再検証）として扱っています。

一方、別の実案件ログ1ケースでは、新しい情報の増え方が小さい区間が含まれていました。事後評価の結果は次のとおりです。

Verification records

17

PROGRESS

5

LOW_GAIN

5

STAGNATION

7

LOW_GAINは新しく得られる情報が少ない状態、STAGNATIONは検証を繰り返しても新しい情報がほとんど増えていない状態を指します。このケースでは、事後評価において、17件中12件をLOW_GAINまたはSTAGNATIONの候補として分類しました。

さらに、実案件ログのうち1ケースでは、検証方針（Strategy／Policy）の上ではRECON――事前の調査にあたる工程――を停止したあとにも、RECONが実行された区間を確認しました。

事後評価では、Strategy上RECONを停止した後にもRECONが実行された12 Roundを、 POLICY_VIOLATION候補として検出しました。POLICY_VIOLATIONとは、Strategy／Policy上避けるべき行動が、実際には実行されている状態を指します。

AIの内部で決めた方針と、実際の実行内容が一致しているかを事後に確認できる、という点が今回の確認事項です。

今回の研究では、Information Gain Control Phase 1として、事後評価による分類が想定どおりに機能するかを確認するための受入条件をあらかじめ設定しました。確認結果は次のとおりです。

すなわち今回確認したのは、実行が終わったあとのログに対して、有益な再検証と、新しい情報がほとんど増えていない反復とを区別できる、というところまでです。この分類が実行中のAIに対しても妥当かどうかは、今後の研究で評価します。

SecureBankでは、研究段階の発表において「確認できたこと」と「確認できていないこと」を明確に区別する方針としています。今回の検証結果は次のとおりです。

第1弾から一貫して、SecureBankは機能実装や分類を行った事実だけをもって性能向上を主張せず、客観的な評価結果が得られた段階で公表する方針を継続します。

今回のPhase 1は、実行が終わったあとのログを対象とした事後評価です。今後は、次の段階を研究計画として想定しています。

1. Phase 1 Offline Evaluation（今回）
2. Phase 2 Shadow Mode
3. Phase 3 Soft Intervention
4. Phase 4 Hard Gate

Phase 2 ― Shadow Mode

Control Layerは判定のみを行い、実際のExecutionには介入しません。PROGRESS、REVALIDATION、LOW_GAIN、STAGNATION、POLICY_VIOLATIONの判定が、実行中のAIに対してどの程度妥当かを評価することを目的とします。

Phase 3 ― Soft Intervention

STAGNATION等を検出した場合に、Toolの変更、Strategyの変更、別の探索方法などを推奨します。ただし、AIのExecutionを強制的に停止することはしません。

Phase 4 ― Hard Gate

十分な検証結果が得られた場合に限り、明確なPolicy Violationや、新しい情報を生まない再試行などに対する実行制御を検討します。

今後は、CyberGymの評価対象を拡大したうえで、次の指標を記録し、Information Gain Control導入前後で比較する研究を進める予定です。

• 成功率
• 試行回数
• LLM Token使用量
• Tool実行回数
• 実行時間
• LOW_GAIN率
• STAGNATION率
• Useful Revalidation率
• Policy Violation率

Cyber AIの研究には、攻撃側の技術、AIそのものの技術、計算基盤、評価手法、実データなど、複数領域の知見が必要です。

• Offensive Security
• Penetration Testing
• AI／LLM
• Cyber Security Products
• GPU／AI Infrastructure
• Cyber Security Research／Evaluation
• 実案件データ
• Dataset
• Agent／Harness／Control Layer

SecureBankでは、本研究を自社のみで完結させるのではなく、Offensive Security、AI／LLM、GPU／AI Infrastructure、Cyber Security Research等の各領域に強みを持つ企業・セキュリティベンダー・AI企業・インフラ事業者・大学・研究機関との共同研究・共同開発、および技術的な情報交換を積極的に検討しています。

現時点で特定の企業・機関との提携が決定している事実はありません。ご関心をお持ちの方は、お問い合わせ窓口よりご連絡ください。