Tencent Hy4と防御的サイバーセキュリティAI：できることとできないこと

テンセントが11月4日に発表したHy4のリリースでは、サイバーセキュリティの防御的なトレーニング手法が説明されていますが、これは企業による安全性の主張であり、モデルが有害な活動を支援できないことの証明ではありません。また、このリリースは8月のHy4 Previewと区別する必要があります。既存のプレビュー版をダウンロードできるからといって、新たに発表されたモデルの重みが公開済みであることや、両者が同一であることの裏付けにはなりません。

重要なのは、トレーニング方針、評価済みチェックポイント、そして実際に利用するシステムを結び付ける根拠が何かという点です。この分析では、リリース記録と安全性に関する主張を分け、防御的な脆弱性調査がどこに当たるかを説明し、チームがモデルを信頼して使う前に独立評価で何を示す必要があるかを明らかにします。

テンセントは11月4日にHy4について何を発表したのか？

テンセントの11月4日の発表では、Hy4を視覚認識機能とコンピューター操作機能を備えた新たなリリースとして紹介し、モデルの重みとシステムカードは後日公開するとしています。また、サイバーセキュリティ対策について述べ、テンセントのセキュリティチームが実施した評価について報告しています。これらは開発元のリリースおよび評価プロセスに関する説明であり、独立した認証ではありません。

ロイターも防御的トレーニングのアプローチを報じました。閲覧可能なロイター配信記事では、システムの脆弱性をテストすることに関する資料が除外されていると説明されています。一方、テンセントの英語の声明では、分析のためのリバースエンジニアリングと侵入テストが含まれるとされています。これらの表現が示す範囲は同じではなく、どちらも網羅的なデータセット一覧と見なすべきではありません。

利用を検討している人がまずすべきことは、リリース名、モデル識別子、リビジョン、システムカード、サービング構成といった、対象の正確な成果物を特定することです。発表資料は意図を説明できますが、導入の判断にはバージョンが明確な技術的根拠が必要です。後の評価を実際にテストしたモデルと結び付けられるよう、これらの記録をまとめて保管してください。

防御的サイバーセキュリティトレーニングとは？

防御的トレーニングは一般に、ソフトウェアの弱点を理解し、どの調査結果が重要かを判断し、自分たちが管理するコードを修正できるよう支援することを目的としています。データの流れを推論したり、認可条件を確認したり、変更案を適用しても危険な挙動が引き続き可能な理由を説明したりする作業が含まれます。こうした作業は、第三者のシステムへの侵入をモデルに求めなくても有用です。

セキュリティの知識はデュアルユースであるため、その境界を定めるのは困難です。不備のある入力チェックを理解すれば、所有者が修正に役立てることも、別の人が攻撃の機会を見つけることもできます。したがって、学習時のラベルだけで信頼できるアクセス制御の境界が実現するわけではありません。モデルがどのコード、認証情報、ツール、ネットワーク宛先にアクセスできるかは、引き続き周囲のアプリケーションによって決まります。

一例として、自社が所有するアプリケーションの権限チェックをレビューするメンテナーを考えてみましょう。役立つ回答は、意図されたルール、不足しているチェック、許可されるケースと拒否されるケースのテストを特定します。同じ作業の範囲が、無断で無関係なホストのスキャンにまで広がってはなりません。回答が有用かどうかを評価する前に、許可された対象と期待する成果物を定めましょう。

当社のAI支援による修正ワークフローは、検出結果から検証済みの変更に至るまで、その防御的なライフサイクルに沿って進みます。学習ポリシーはモデルの挙動に関係しますが、提案がソフトウェア変更に反映される過程を決めるのはワークフローです。

カバー画像：Tencent Hy4 Previewリポジトリ、GitHubが生成したリポジトリカード。これはバージョン比較で取り上げるPreview成果物を示すもので、11月に予定されているチェックポイントファイルではありません。

AIはソフトウェアの欠陥の特定と修正にどう役立つか？

多くの場合、役立つのは、リポジトリ内に散在する証拠を結び付ける役割です。警告によって関数が特定されても、それが重要な理由は呼び出し元、設定、依存関係のバージョン、デプロイ経路によって決まる場合があります。AIは説明案や修正案を提示できますが、チームはその一連のつながりを一つずつ検証する必要があります。

2つのルートから管理操作にアクセスできる架空のサービスを考えてみましょう。一方のハンドラーを修正しても、もう一方のルートは変更されずに残る可能性があります。レビューでは、セキュリティ不変条件をどこに適用すべきか、両方のルートでそれが強制されているか、パッチによって正当な挙動が変わらないかを確認する必要があります。最初のハンドラーだけに言及した流暢な説明は、局所的な編集が正しくても不完全です。

OWASPコードレビューガイドは、コードを体系的に調査するための幅広い参考資料です。実践で大切なのは、変更された行だけでなく、セキュリティ上の性質をレビューすることです。パッチでは、どの挙動を防ぎ、どの挙動を維持するのか、そしてテストでその違いをどう見分けるのかを説明する必要があります。

評価対象となる出力はいくつかあります。

Tencentはトレーニングから何を除外したと述べたのか？

英語版の公式発表では、防御を重視し、攻撃的な悪用に関する資料を除外したと説明しています。また、分析を目的としたリバースエンジニアリングとペネトレーションテストは対象に含めたとも述べています。ロイターの配信記事では、脆弱性を調べるためのシステムテストなど、除外した資料をより広く説明しています。公開された説明だけでは、これらのカテゴリが正確にどう対応するのかは明らかではなく、どちらもデータセットの完全な一覧を示していません。

妥当な結論は限定的です。Tencentはトレーニング上の境界について説明していますが、読者はニュース報道だけから、対象に含まれた例や除外された例の正確な一覧を推測すべきではありません。また、あるトレーニング段階で特定のカテゴリがフィルタリングされたからといって、モデルに関連知識がまったくないと推測すべきでもありません。ほかのトレーニングデータや一般的な推論能力が、挙動に影響する可能性があります。

より検証しやすい説明では、カテゴリ、対象となったトレーニング段階、フィルタリングのプロセス、境界事例の扱いを明確にする必要があります。また、ポリシーが適用されるチェックポイントも示すべきです。こうした根拠が得られるまでは、技術的な保証にすり替えることなく、出典を明記した主張として伝え、不確実性を残してください。

Tencentの社内安全性テストを読者はどう解釈すべきか？

内部テストで重要な問題が明らかになることがありますが、その意味は何をテストしたかによって異なります。結果を評価するには、タスクの分布、採点方法、ベースライン、モデルのリビジョン、利用可能なツールの説明が必要です。また読者は、評価者がモデルの生の応答、設定済みのエージェント、あるいはその両方をテストしたのかを確認する必要があります。これらのシステムが示す能力はそれぞれ異なります。

ネットワークアクセスもシェルも使わずに行った評価を考えてみてください。その評価では、同じモデルをリポジトリへの書き込み権限と制限のないツールを持つエージェントに組み込んだ場合について、ほとんどわからないかもしれません。逆に、危険なプロンプトへの回答を拒否したからといって、そのモデルが微妙な認可バグを確実に特定できるかどうかはわかりません。安全性と防御への有用性は、別々に測定する必要があります。

公開された安全性レポートについて、確認するとよい点は次のとおりです。

• 明確なポリシー違反だけでなく、難しいケースや曖昧なケースも含まれていましたか？
• 読者が、拒否動作と能力不足を区別できるように、失敗は分類されていましたか？
• 試行に失敗した後、さまざまなプロンプトや追加のコンテキストを試しましたか？
• 独立した評価者が設定を再現できましたか？
• 調査結果は、限界や未解決のケースと併せて報告されていましたか？

これらは評価に関する問いであり、Tencentが特定のテストを省略したという主張ではありません。すべての資料がそろっていなければ、読者が不足している方法論を補うことはできません。証拠が不完全な場合に取るべき対応は、成功率を捏造することではなく、結論の範囲を狭めることです。

11月のHy4はHy4 Previewと同じ成果物か？

公開されているリリース記録から、これらは別個のリリースとして扱うのが妥当です。Tencentの8月28日のPreview発表は、11月のHy4より前のものです。Previewリポジトリには、総計770B、アクティブ49BのMoEバックボーンと1Mのコンテキスト長が記載され、Previewの重みへのリンクもあります。11月の発表では、Previewからの変更点と今後の重みのリリースが説明されています。

これで、広い意味での名称の曖昧さは解消されます。入手可能なPreviewを11月のモデルと呼び替えるべきではありません。ただし、Previewが同じサイバーセキュリティ訓練を受けたことや、同じ安全動作をすることが証明されたわけではありません。正確なチェックポイントの同一性、訓練の継続性、11月に報告された安全性に関する調査結果の再現性については、引き続き成果物ごとの文書が必要です。

テストでは、製品名、チェックポイントのリビジョン、モデルのエンドポイント、ランタイム、ツールの権限、評価日をそれぞれ記録する証拠記録を使用してください。同じ名前のままホスト型エンドポイントが変更された場合は、入手可能であればプロバイダーのバージョン情報も記録してください。プレビュー版、後続のエンドポイント、量子化された派生版の結果を、区別せずにまとめてはいけません。

この違いは、ローカル展開に関する主張にも影響します。ファミリーのダウンロード可能なモデルがあるからといって、新たに発表されたリリースも入手できるとは限りません。ローカルテストを計画する前に、実際のファイルと適用されるライセンスを確認し、そのうえでファミリー全体に関する主張がそのまま当てはまると決めつけず、選んだ構成を評価してください。

AI脆弱性モデルだけでは、何を確実に立証できないか?

回答だけでは、アプリケーションの脅威モデルが完全であると証明できません。モデルは信頼境界を誤解したり、フレームワークが実際には行わないチェックを行うと思い込んだり、デプロイ済みビルドに含まれないコードの修正を提案したりする可能性があります。また、コードが安全に見える理由を説得力のある説明で示しながら、脆弱性を見逃すこともあります。

チームは「見つからなかった」と「存在しない」を区別する必要があります。検索範囲、依存関係の状況、またはランタイム設定が不完全な場合、警告がないことは弱い根拠にすぎません。同様に、再現可能な証拠のない警告は、確定したインシデントとして自動的に扱うのではなく、候補となる検出結果にとどめるべきです。

パッチ適用後も、運用環境での検証が必要です。アドバイザリーを追跡し、デプロイ済みパッチを検証するためのガイドでは、ソースコード上の修正と、稼働中のサービスの更新が別々の結果である理由を説明しています。コードアシスタントは変更の準備を支援できますが、パッケージ化、ロールアウト、下流への更新は把握できない場合があります。

独立した評価では何を測定する必要があるか

有用な評価では、防御上の価値と意図しない能力を別々に測定します。防御上の価値については、検証済みの検出結果、誤警告、見逃したケース、パッチの正確性、回帰率、レビューにかかる労力を考慮します。安全性については、脅威モデルを定義し、本番環境で実際に使われるツールと権限をテストします。これらを、説明のない単一のスコアにまとめないでください。

NISTセキュアソフトウェア開発フレームワークでは、脆弱性への取り組みをより広範な開発プロセスの中に位置づけています。実際には、評価において、候補となる問題を最初の説明だけで終わらせず、その後の経過を追う必要があります。問題が正しく理解され、修正され、テストされ、レビューされ、適切にリリースされたかを確認します。別の不具合を生む迅速な提案は、修正に成功したとは言えません。

データの取り扱いも評価の対象です。ソースコードとシークレットのトリアージガイドでは、範囲を絞ってサニタイズしたレビュー用パッケージについて説明しています。関連するパーソナルエージェントの権限チェックリストは、タスクとその実行に必要なアクセス権を切り分けるのに役立ちます。モデルの学習ポリシーがあっても、こうした境界を設ける必要はなくなりません。

セキュリティモデルを導入する前に、責任者、使用を許可されたコード、既知のベースライン、明示的な停止条件を定めた範囲の限られた試験運用を設計してください。有用な発見と、レビューの無駄の両方を記録しましょう。証拠が特定のワークフローを裏付ける場合に限って拡大してください。目標は、モデルが生成する発見の数を増やすことではなく、信頼できるセキュリティ業務を実現することです。

自動修正を受け入れる前に、エージェント型自動修正のレビュー用チェックリストを使い、提案された変更が有意義なテストと明示的なリリース判断につながっていることを確認してください。

よくある質問

Hy4はサイバーセキュリティ専用モデルですか？

Tencentは、複数の機能を備えた、より幅広いモデルとして説明しています。サイバーセキュリティに関するトレーニングポリシーは、そのリリースの一側面であり、すべての用途や応答がセキュリティ関連の作業に限定される証拠ではありません。

11月版のHy4とHy4 Previewは同じものとして扱えますか？

いいえ。リリースの記録では両者は区別されています。ダウンロード可能なPreviewの成果物や仕様を、11月のチェックポイントやその評価の証拠の代わりにするべきではありません。

防御目的のトレーニングによって、モデルの悪用を防げることが保証されますか？

いいえ。トレーニングポリシー、実際の動作、デプロイ権限はそれぞれ異なる管理策です。設定済みのシステムを評価し、重大な結果を伴う操作には適切なレビューを必須としてください。

チームは非公開リポジトリ全体をAIツールに送信できますか？

データポリシーとサービスの取り扱い条件の両方が、その利用を認めている場合に限ります。必要最小限の関連する許可済みコンテキストを使い、認証情報や無関係な個人情報は取り除いてください。

修正を信頼する前に、メンテナーはどのような証拠を求めるべきですか？

明確な説明、影響を受けるリビジョン、対象を絞ったパッチ、関連するテスト、レビュー記録、デプロイの検証を求めてください。モデルが防御目的でトレーニングされているという主張は、そうした証拠の代わりにはなりません。

結論

Hy4のリリースにより、防御目的のAIトレーニングは具体的な検証対象となりましたが、有意義な検証には正確な出典の特定とバージョンの確認が欠かせません。公式発表とReutersの説明は異なっており、Previewの成果物を新たに発表されたリリースの代わりにすることはできません。開発元による安全性の調査結果は、文書化された対象範囲内で検証すべき主張として扱ってください。

メンテナーにとって、実務上の基準は引き続き、発見事項からデプロイ済みの修正まで、検証可能な一連の流れです。AIを活用して調査を改善し、コードや認証情報の扱いを適切な範囲に限定し、回答の自信ではなく再現可能な証拠に基づいて結果を評価してください。