セキュア・バンク、独自Cyber AI研究を第4段階へ
― 異なる脆弱性タスクへ自律適応するCyber AI Harnessの動作を確認

SecureBankは2026年8月より、Open Weightモデルを基盤としたサイバーセキュリティ領域特化型AI「Cyber AI」の独自研究開発を進めています。これまでに確認してきた範囲は、次のとおりです。

1. 実行結果を観測
2. 結果を次の入力へ反映
3. 条件を変更して再試行
4. 反復に新しい情報があるかを事後評価

第2弾では、実行結果を観測して次の一手に反映し、条件を変えて再挑戦する仕組みを確認しました。第3弾では、その反復に新しい情報が生まれているかどうかを、実行後のログから事後評価できることを確認しています。

ここまでで残っていたのが、そもそも「どの方針で試すか」を誰が決めるのかという論点です。従来の構成では、脆弱性の原因をLLMが推論してPoC候補を生成し、Harnessがそれを実行・評価していました。この場合、探索の方向はLLMの出力に大きく依存します。あるタスクではうまくいっても、別のタイプのタスクでは同じやり方を繰り返してしまう可能性があります。

今回はこの点に取り組み、探索方針の決定そのものをHarness側へ移す構成で、異なる脆弱性タスクに対する挙動を確認しました。

ここでいう自律適応とは、一つの問題の答えや解き方をあらかじめ登録しておくのではなく、問題ごとに得られた証拠を読み取り、試す方法を変えられることを指します。

より平易に言い換えると、次のような動作です。

専門的には「汎化」と呼ばれる性質にあたります。今回確認したのは、その汎化型Harnessが実際に動作したという事実です。あらかじめ答えを持っているのではなく、手掛かりを読んで、やり方を選び直すという挙動が、性質の異なる2つのタスクで確認できました。汎化能力を持ち始めたことを実験的に確認した段階であり、自律適応に向けた初期的な動作の確認にあたります。

1つ目のタスク（arvo:46883）では、次の一連の動作を、人間の途中介入なしで確認しました。

1. Evidenceから攻撃Strategyを選択
2. PoC候補を生成
3. 実行
4. 評価
5. 再探索
6. Crashを検出
7. 修正前後の比較
8. Validation

Harnessはまず、脆弱性を含む版（Vulnerable Build）から得られるEvidenceを基に攻撃Strategyを選択し、LLMがPoC候補を生成、CyberGymで実行しました。1回目の結果はNO_CRASH、つまり問題が再現しない結果です。

ここで重要なのは、その時点で停止しなかったことです。Harnessは自律的に探索を継続し、別の候補でSegmentation Fault（Exit 139）を検出しました。

さらに今回の構成では、Crashしただけでは成功と判定しません。脆弱性を含む版（Vulnerable Build）と修正済みの版（Fixed Build）を自動で比較し、前者ではCrashが発生し、後者では正常終了することを確認したうえで、TARGET_DIFFERENTIALと判定しています。この条件を満たした時点で、VALIDATED_POCとして自動停止しました。

単にCrashを起こしたのではなく、修正前後の挙動の差を確認してから判定したという点が、今回の要点です。偶発的な異常終了と、修正対象となった問題の再現とを区別するための手順にあたります。

Harnessは、実行結果、Runtime Stack、Source CodeなどをEvidenceとして探索を行い、生成した候補についてVulnerable BuildとFixed Buildの動作差を確認しました。Task固有の正解PoCや攻略手順をHarnessへ直接与えたものではありません。

2つ目のタスク（arvo:38050）は、arvo:46883 とは異なるタイプの脆弱性タスクです。ここでは、arvo:46883 専用の攻略ロジックやTask固有の答えを追加せずに実行し、HarnessがEvidenceから複数の攻撃Strategyを評価しました。

はじめにお断りしておくと、arvo:38050 は脆弱性の再現やVALIDATED_POCへの到達を確認したTaskではありません。このTaskで確認したのは、攻撃Strategyの自律変更、Strategyに応じた実験手法の切り替え、LLMの生成失敗からのRecoveryという3点の挙動です。つまり、成果が出ないときに探索の進め方をどう変えるかを見るためのTaskにあたります。

実際に確認した流れは次のとおりです。

1. INPUT_BOUNDARY
2. Saturation判定
3. PARSER_STATE
4. Saturation判定
5. INTEGER_LENGTH_BOUNDARY

はじめにINPUT_BOUNDARYという方針で試行しましたが、成果が得られずSaturation（頭打ち）と判定し、PARSER_STATEへ変更しました。ここでもSaturationと判定し、さらにINTEGER_LENGTH_BOUNDARYへ変更しています。

あわせて、Strategyに応じて実験方法そのものも変更しました。方針が変わっても同じやり方で入力を作り続けるのではなく、着目点に合わせて実験の組み立て方を切り替えています。

経営的な観点で言い換えると、うまくいかない方法に固執せず、手掛かりを見て別のアプローチへ切り替えられるということです。異なる種類の問題に同じ仕組みで向き合うために必要な性質にあたります。

今回用いたのは7BクラスのローカルLLMです。規模の大きなモデルと比べると、要求した形式どおりの出力を返せない場合があります。実際、今回の検証でもLLMがINVALID_HEXを返し、PoC生成に失敗する場面がありました。

それでもHarnessは停止しませんでした。確認したRecoveryの流れは次のとおりです。

1. LLM生成失敗
2. Generation Failureを検出
3. Semantic Mutation
4. Source Evidenceを解析
5. 新しい実験Seedを生成
6. CyberGymへ投入
7. 探索を継続

HarnessはまずGeneration Failureを検出し、既存のPoCを基にSemantic Mutationを試みます。それも困難な場合は、Source CodeをSource Evidenceとして解析し、そこに現れる条件から新しい実験Seedを生成して、CyberGymへ投入しました。

Source Evidenceから実際に抽出・利用した条件には、LF、CRLF、digit、Whitespace、Input Boundary、input-end条件などがあります。いずれもTask固有の正解をハードコードしたものではなく、Source Evidenceを基に複数の実験Seedを生成できたことを示します。

LLMが探索の起点であれば、生成に失敗した時点で探索は止まります。今回の構成では、LLMは生成手段の一つであり、制御はHarness側にあるため、探索そのものは継続できました。

今回の変化を整理すると、探索全体の制御主体がLLMからHarnessへ移った、という一点に集約されます。観点ごとの違いは次のとおりです。

従来は、LLMがPoCを生成し、Harnessがそれを実行して結果を評価する構成でした。今回は、HarnessがEvidenceを収集し、Strategyを選択し、LLM生成・Mutation・Source解析を使い分けたうえで実行し、結果に応じてStrategyを変更するかValidationへ進むかを決めています。

今回の検証で用いたのは7Bクラスのモデルです。規模の大きなモデルほど単体での推論能力は高くありませんが、探索の制御をHarness側に置くことで、モデル単体の性能に依存しすぎない構成を検討できます。

研究段階の発表として、確認できた範囲と、確認できていない範囲を明確に区別します。今回のリリース時点における限界は次のとおりです。

そのうえで、今回の検証で確認できたこと・確認できていないことを整理すると次のとおりです。

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

今回確認したのは挙動までです。ここから先は、再現性の確認と定量評価へ進みます。次の段階を研究計画として想定しています。

SecureBankが目指しているのは、単純に大規模なクラウドAIへ依存することではありません。次の3つを研究開発の軸としています。

機密性が求められる国内・閉域環境でも運用可能なCyber AIを、将来的に実現することを目標としています。探索の制御を自社のHarnessが担い、推論部分に手元で動かせるモデルを用いる構成は、その目標に向けた研究上の選択です。

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企業・インフラ事業者・大学・研究機関との共同研究・共同開発、および技術的な情報交換を積極的に検討しています。

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