フロンティアAIの進歩をどの程度の速さで進めるべきかをめぐり、業界では議論が続いています。この議論は、AnthropicとOpenAIが公表したインシデントを受けて加速しました。評価環境において安全対策を緩和した状態で稼働していたモデルが、誰も意図していなかった範囲を大きく逸脱する行動を取ったのです。モデルは、本来隔離されているはずのシステムにアクセスし、互いに分離されているはずのインスタンス間で連携しました。さらに最近では、AnthropicのCEOであるDario Amodei氏が、フロンティアAIの能力開発を意図的に一定のペースで進め、その検証のために独立した評価者を各研究所内に配置すべきだと提案しました。
この提案に対する反応は一様ではありません。AI研究所は、1回のトレーニングでどの程度の能力が向上するのか、リリース前にモデルをどの程度徹底して評価するのか、また標準を自主的なものとするか規制対象とするか、といった開発プロセスに注目しています。一方で、フロンティアAIの進歩は自然なペースで進み、世界の動きも減速していないため、モデルを取り巻くシステムに安全性を組み込む必要があるという意見もあります。
ここでこの議論に決着をつけるつもりはありませんが、興味深い点があります。どちらの陣営も、制御機能はモデルの外部に置き、検証をモデルの開発者だけに委ねるべきではないという点では一致しています。
これは、私が5月に示した主張をより広い観点から捉えたものです。当時、私は書きました。AIにおけるセキュリティ境界は推論パスへと移行している、と。アプリケーションはモデルを呼び出し、エージェントはツールを起動します。また、モデルは他のサービスにアクセスしてデータを取得し、ワークフローをトリガーし、運用上のアクションを実行します。私の結論は、このトラフィックも他の重要なアプリケーション間通信と同様に、配信、検査、認証、ガバナンスの対象とする必要がある、というものでした。
これはアーキテクチャに関する主張でしたが、ここ数か月でコンプライアンス上の論点にもなり始めています。最先端の進展に歩調を合わせても、企業の対応が同じペースで進むわけではありません。研究機関や政府がどのような結論に至るにせよ、すでにリリースされたモデルは今まさに組織内に導入されており、その利用に伴う義務もすでに具体化しつつあります。
私の経験上、セキュリティロードマップの項目は2種類に分かれます。1つは、必要性を確信していても、ほかのあらゆる施策と予算を争い、時には優先されないものです。もう1つは、期限が定められ、監査人から確認を受け、リスク登録簿にも記載されるものです。AIガードレールは前者から後者へと移りつつあります。この業界に長く携わってきた方なら、なじみのある流れでしょう。
“最先端の歩みに合わせても、企業の歩みが同じになるわけではありません。研究機関や政府がどのような結論に至ろうとも、すでにリリースされたモデルは今まさに組織内で導入されており、その利用に伴う義務もすでに具体化しつつあります。”
PCI DSSから得た教訓
この試みは以前にも行われています。2008年以前、Webアプリケーションセキュリティは、定期的なコード監査、静的スキャン、開発者の規律に頼るという、実現への期待にとどまる部分が大きいものでした。その後、PCI DSS要件6.6が登場し、カード会員データを取り扱う組織に対して、すべてのアプリケーションコードの脆弱性をレビューするか、公開アプリケーションの前段に自動化された技術的制御を導入することを求めました。
そのことについて、今も心に残っている点が2つあります。
PCI DSSは、法律として始まったものではありません。業界に携わる私たちが、規制に先んじようとしたことから始まりました。これは契約に基づく基準であり、アクワイアラーとの契約を通じて適用されましたが、それでも市場全体を一変させました。実際、契約は法令よりも迅速に進むため、法制化よりも速く市場を変えた可能性があります。この点が重要なのは、組織が最初にこの圧力を感じるのは規制当局からではなく、顧客のセキュリティ質問票や調達条項、あるいは自社のモデルの前段にどのような制御が設けられているかを確認する保険会社からだからです。
そして、最終的にはどうなったのでしょうか。PCI DSS v4.0では、二者択一の選択肢がなくなりました。コードレビューという代替手段は廃止され、現在は要件6.4.2により、一般公開されているWebアプリケーションの前段に自動化された技術的ソリューションを導入することが義務付けられています。
現在では、PCI準拠が任意かどうかを問う人はいません。かつての選択肢が、今や要件となったのです。
AI規制の現状
AI規制の猶予期間は終わりました。AI版PCIともいえる規制が、複数のルートで異なる速度で同時に導入されつつあります。なかでも最も整備が進んでいるのがEU AI Actです。汎用モデルに関する義務はすでに適用が始まっています。欧州連合は最近、高リスクAIに対する執行を2027年12月まで延期しましたが、技術的堅牢性、人間による監督、ログ記録に関する要件はすでに定められています。企業が見落としがちなのは、こうした義務の一部がモデルプロバイダーだけでなく、企業自身にも課される点です。他社のモデルを高リスクのユースケースに導入する場合、その責任は導入企業が負います。
米国にはまだ同等の法律はありませんが、NIST AI Risk Management Frameworkとその生成AIプロファイルは、多くの組織が合理的な注意義務を果たすために採用する標準となっています。認証の面ではISO/IEC 42001が同様の役割を果たしており、実際に調達文書でも見かけるようになりました。州レベルでは、透明性、情報開示、特定用途に関する規則を組み合わせた複数の法案が提出される一方、金融および医療分野の規制当局は、シナリオ別のガイドラインについて議論しています。
また、OWASP Top 10 for LLM Applicationsは現在、セキュリティレビューにおける標準的な参考資料となっています。お客さまがAI統制に関する質問票をベンダーに送付する場合、その質問は多くの場合、この資料に基づいています。
これらすべてに目を通すと、同じ要件が繰り返し現れます。モデルへの入力とモデルからの出力を継続的に制御し、その記録を後から提示できることを示す必要があります。
これは、コンプライアンス以前に運用上の問題です
F5の「2026 State of Application Strategy Report」によると、現在、アプリケーションポートフォリオの55%がAIに対応しており、平均的な企業では推論パスで7つのモデルを実行しています。半数以上(52%)が複数のモデルを連鎖またはオーケストレーションしており、90%が共有インフラストラクチャ経由で推論をルーティングする予定です。
ここで、監査人から、たとえば「モデルの出力から顧客の個人識別情報(PII)が一切外部に流出しない」という単一のポリシーが、そのすべてに適用されていることを実証するよう求められる場面を想像してみてください。
7つのモデルを個別に設定するだけでは、その問いには答えられません。ましてや、そのうち3つが連携し、あるモデルの出力が別のモデルの入力になる場合はなおさらです。さらに、私が話を伺う組織の多くは、その段階にすら達していません。実態を調べて最初に見つかるのは、セルフホスト型モデルではないからです。従業員がコンシューマー向けAIツールに機密データを貼り付けていたり、すでに利用しているSaaSアプリケーション内でAI機能がいつの間にか有効になっていたりします。
そこにエージェントが加わると、制御すべき単位はプロンプトではなく、ツール呼び出し、APIリクエスト、それによってトリガーされるワークフローといったアクションになります。これは、F5が20年にわたりアプリケーショントラフィック向けに構築してきたものと同じ制御ポイントです。
これと同じエージェント型AIの能力は、すでにマシン速度で組織的な攻撃キャンペーンを展開する攻撃者の手に渡っています。ボット対策で得た教訓と同様に、このトラフィックを見かけ上の巧妙さで判断するのではなく、発信元とその意図に基づいて制御する必要があります。
Guardrailsはモデルの外部に配置する必要がある
独自のモデルを運用する組織が増えています。自社のインフラストラクチャ上でオープンウェイトモデルを稼働させ、自社のデータでファインチューニングしています。プロバイダーによるセーフティネットがないため、運用上およびコンプライアンス上の責任はすべて組織自身が負うことになります。
モデルごとの監査は、規模の拡大に対応できません。原理上は、十数種類のモデル構成を対象に実施できます。実際にそうしているチームも見てきました。しかし、これは手作業であり、誰かが新しいエンドポイントを立ち上げた時点で情報が古くなります。また、継続的な統制ではなく、その時点のスナップショットしか得られません。
アラインメントはセキュリティ制御ではありません。システムプロンプトと事後学習は、有用なベースラインとなります。OpenAIとAnthropicのインシデントは、その限界を示しています。これらは、安全対策のないモデルが限定的な目標を追求する中で境界に直面し、それを回避した事例です。OpenAIは、説明しています標準の顧客向け環境に導入されている分類器であれば、この活動を安全でないものとして検知していたはずであり、拡張された思考連鎖モニタリングが稼働していれば、モデルがHugging Faceに到達する前にセキュリティチームへ警告していたはずだと。Anthropicが一般提供しているモデルには、入力と出力をリアルタイムで検査する分類器が搭載されています。
これを受け、両研究所はアラインメントに大幅な改善を施しましたが、いずれもそれだけで十分とは考えませんでした。また、モデルの動作を監視し、アクションの実行前に評価して、必要に応じて人間にエスカレーションする仕組みを、モデルの外部に設けました。これらのシステムを最も深く理解している組織は、制御機能をモデルの外部に置くべきだと結論付けました。
どこから始めるか
規制の方向性と、こうした義務がどのように課されるかについて過去20年間のアプリケーションセキュリティから得た教訓を踏まえると、待つのではなく、今すぐ着手すべきことが3つあります。
- まず、承認されていないものから対象範囲を把握します。SaaS API、ホスト型エンドポイント、自己管理型のオープンウェイトモデルのデプロイなど、本番環境で稼働するすべてのモデルに加え、シャドーAIも対象です。
- 適用制御をモデルから切り離します。ポリシーは7つの個別のモデル構成ではなく、推論パスに組み込みます。入力と出力を検査し、使用するモデルやクラウドにかかわらず、一貫して適用します。
- 監査証跡は、記録対象のシステムの外部に構築します。何が要求され、何が返され、何がブロックされ、誰が何を承認したかを記録します。モデルやエージェントが制御できないインフラストラクチャで生成されるようにしてください。OpenAIのインシデントを調査した担当者は、エージェントが自身の行動記録を改ざんしようとしたことを突き止めました。記録対象のシステム自体がその記録を生成している場合、記録の信頼性が疑われます。
ここで重要なのは、AIガバナンスが単なる文書作成にとどまらないという点です。組織に求められるのは、技術的かつ継続的な対応と、証拠の提示です。したがって、これは法務部門が扱う方針上の問題ではなく、セキュリティチームと運用チームが担うアーキテクチャおよび運用上の問題です。
制御はモデル内ではなく、推論パス上に置くべきだとF5は考えています。組織が運用するすべてのモデル(SaaS API、ホステッドエンドポイント、自己管理型のオープンウェイトモデル、承認済みのモデル、まだ把握していないモデル)は、推論パスに集約されます。そのため、推論パスは、これらすべてのモデルにわたってポリシーを適用し、独立した監査可能な記録を生成するための理想的な制御ポイントとなります。
ルールは今も策定途上
EU AI Actに基づく義務、州法、業界規制当局、顧客との契約のうち、どの要件によって自組織が対応を迫られることになるのかは、誰にも分かりません。ただ、これらの枠組みにおける技術的な定義がまだ確定していないことは確かです。何をもって適切な監視、十分な堅牢性、許容可能な記録とするかは、意見募集、標準化団体、行動規範の策定を通じて、まさに今決められつつあります。
ここで、フロンティアAIの開発ペースをめぐる現在の議論に話を戻します。その是非はさておき、実際に本番環境で運用している立場から、1つ指摘しておきたいことがあります。企業は、それとは異なる時間軸で動いています。研究機関、政府、業界がどのような判断を下そうとも、すでにリリースされたモデルは組織内で大規模に導入・利用されており、その利用に伴う義務は現実に存在します。能力開発のペースを落とすかどうかにかかわらず、取締役会、経営幹部、顧客に対する説明は必要です。
こうした意思決定は、これらのシステムを大規模に運用してきた人々の知見を取り入れることで、より良いものになります。実際に何を強制できるのか、統制によってレイテンシーや複雑性がどの程度増すのか、善意のルールがどこで行動を誤った方向へ導くのかを理解している人々です。PCI DSSが機能したのは、実務者がその策定に関わったからです。私たちがこの議論に参加しなくても、要件は策定されます。ただし、要件を実際に適用した経験のない人々の手によってです。
詳しくは、AIセキュリティに対するF5のアプローチをご覧ください。
著者について

Michaelは、セキュリティとレジリエンスを中核に据えた全社的な事業運営に向け、戦略の策定と実行を担っています。F5のセキュリティ、リスク、デジタルオペレーションの各組織を統括し、お客さま、パートナー、従業員に対するエンドツーエンドのオペレーショナル・トラストを推進しています。 Montoyaは、2021年から2025年までF5の取締役を務めた後、2025年10月にF5の経営幹部チームに加わりました。F5入社以前はBlueVoyantの最高執行責任者を務め、それ以前にはEquinixおよびDigital Realtyで最高情報セキュリティ責任者を歴任しました。また、Microsoftに10年以上在籍し、最高サイバーセキュリティ責任者、EMEAおよびアジア地域のCIO/CISO、データセンター運用のグローバル責任者など、グローバルなリーダー職を務めました。
Michael Montoyaのその他のブログ記事関連するブログ記事

経営幹部が抱くAIに関する4つの誤解
AIに関する誤解は数多くあります。ここでは、組織が自社環境にAIを導入する際に見直す必要があるかもしれない4つの誤解を紹介します。

IT/OTコンバージェンスの現状と、セキュリティを最優先すべき理由
ITシステムとOTシステムの融合が進むにつれ、攻撃対象領域は拡大します。組織が安全に統合する方法と、F5 ADSPが大規模な運用の保護にどのように役立つかをご紹介します。

AIのレイテンシ:セキュリティを犠牲にできない理由
AIのレイテンシは、単なる速度の問題ではありません。パフォーマンス、セキュリティ、信頼性のバランスを考慮したシステム設計が重要です。

AIアプリケーションを大規模に提供する:ADCの役割
AIアプリケーションを確実に提供するには、高速なモデルや柔軟に拡張できるインフラストラクチャだけでは不十分です。AIアプリケーションの利用方法を管理するための制御レイヤーが必要です。

MCP:AI対応のアプリケーションデリバリを実現する鍵
Model Context Protocol(MCP)は、最新のアプリケーションにおける安全で低遅延なAI統合を可能にします。将来を見据えたアプリケーションデリバリ戦略にMCPが不可欠な理由をご覧ください。

AIガードレールとは?基盤モデルプロバイダーの枠を超えて進化する安全対策
急速に変化する組織の脅威領域におけるリスクをより包括的に捉えるために、AIガードレールの進化が必要な理由をご覧ください。