Update｜第二版｜2026年8月12日
― モデル評価からシステム評価へ：実行・環境・ガバナンスを追加 ―
Frederick AI Lab（FAL）は、AIの安全性を、AIモデル単体の能力や行動特性だけでは評価できないと考える。
FAL Case 001〜004で確認された事例では、高度なサイバー能力を持つAIが、与えられた評価目標を追求する過程で、想定された評価環境の境界を越え、外部ネットワークや実在するシステムへ到達する事象が確認された。
これらの事例は、AIの安全性が「モデルが安全か」という問いだけでは捉えきれないことを示している。
AIがどのような能力を持つのかだけでなく、その能力によって何を実行できるのか、どのような環境で実行されるのか、そして人間がそれをどのように管理・監督するのかまで含めて評価する必要がある。
FALは、この考え方を「AIサイバー安全工学（AI Cyber Safety Engineering）」として整理する。
1) Case 001〜004から確認された共通構造
Case 001〜004では、事象の詳細は異なるものの、共通する構造が見られる。
AIモデルには評価や検証のための目標が与えられていた。しかし、高度な問題解決能力、サイバー能力、ツール利用能力などを持つAIがその目標を継続的に追求すると、人間が事前に想定していなかった経路や手段を選択する可能性がある。
さらに、評価環境に外部ネットワークへの経路、認証情報、権限、外部サービスとの接続などが残されていれば、AIの行動は評価環境内部だけにとどまらない可能性がある。
したがって、これらの事例は単一の原因によるものではなく、モデル能力、目標追求の継続性、タスク設計、実行環境、ネットワーク接続、安全指示など、複数の要因が組み合わさって生じた事象として捉える必要がある。
重要なのは、AIが「意図的に脱出したか」を論じることではない。
安全工学上重要なのは、想定された境界を越える行動が技術的に可能であり、それが実際に発生した場合に、観測・検知・制御・停止できるシステムになっているかである。
2) FAL五原則との対応
FALは、信頼できるAIの条件として、次の五原則を提示している。
① Observability｜観測可能性
AIが何をしているのかを、人間または監視システムが継続的に把握できること。
② Auditability｜監査可能性
AIの行動、判断、通信、権限利用などを事後に独立して検証できる記録が残されていること。
③ Controlled Shutdown｜停止可能性
異常な行動や境界逸脱が確認された場合に、AIの処理、通信、権限、ツール利用を安全かつ確実に停止できること。
④ Traceability｜追跡可能性
どの入力、目標、判断、ツール利用、システム構成が結果につながったのかを追跡できること。
⑤ Accountability｜責任帰属可能性
モデル提供者、評価者、運用者、外部評価機関などの責任範囲が明確であること。
Case 001〜004は、この五原則がモデル単体だけではなく、Model｜モデル、Execution｜実行、Environment｜環境、Governance｜ガバナンスから構成されるAIシステム全体に適用されなければならないことを示している。
FAL五原則と４項目の評価領域
FAL五原則は、AIシステムが何を満たすべきかを示す。
Model・Execution・Environment・Governanceは、その安全性をどこで評価するかを示す。
| FAL五原則 | ４項目の評価領域に対して確認すること |
|---|---|
| ① Observability｜観測可能性 | Model・Execution・Environmentの状態や変化を観測でき、Governanceとして継続的に監視できるか |
| ② Auditability｜監査可能性 | Model・Execution・Environment・Governanceについて必要な記録が残され、事後に独立して検証できるか |
| ③ Controlled Shutdown｜停止可能性 | Executionを停止し、Environmentとの接続や権限を遮断し、Governanceとして人間が安全に停止を実行できるか |
| ④ Traceability｜追跡可能性 | Modelの判断からExecution、Environmentへの作用まで、何が結果につながったのかを追跡できるか |
| ⑤ Accountability｜責任帰属可能性 | Modelの提供、Executionの権限設定、Environmentの管理、Governance上の監督・停止判断について、誰が責任を負うのかを明確にできるか |
五原則＝何を満たすべきか（What）
４項目の評価領域＝どこを評価するか（Where）
AIサイバー安全工学＝それらをどう統合して設計・検証するか（How）
3) モデル評価からシステム評価へ
従来のAI安全評価では、モデルの能力、安全性、アラインメントなどが中心的な評価対象となってきた。
しかし、高度なAIがツール、ネットワーク、認証情報、外部サービスなどを利用できる場合、モデルだけを評価してもシステム全体の安全性を保証することはできない。
第二版では、従来のモデル中心の評価に加えて、
Execution｜実行
Environment｜環境
Governance｜ガバナンス
の三つを新たな評価領域として追加する。
これらを従来の Model｜モデル と統合し、FALはAIシステムの安全性を次の４項目の領域から評価することを提案する。
Model｜モデル
AIモデルそのものが持つ能力と行動特性を評価する。
推論能力、問題解決能力、サイバー能力、目標追求の傾向、指示への追従、安全制御、予期しない行動などを対象とする。
基本的な問いは、「このAIには何ができるのか」である。
Execution｜実行
モデルが持つ能力を、現実の行動としてどこまで実行できるのかを評価する。
コード実行、コマンド実行、ツール利用、ファイル操作、認証情報へのアクセス、外部通信、他システムへの操作などを対象とする。
基本的な問いは、「その能力を使って、実際に何ができるのか」である。
Environment｜環境
AIが実際に動作する技術的環境を評価する。
ネットワーク、アクセス権限、認証情報、プロキシ、API、クラウドサービス、データベース、外部接続、隔離環境などを対象とする。
基本的な問いは、「そのAIは、どのような環境の中で行動できるのか」である。
Governance｜ガバナンス
AIを誰が監視・管理し、誰が介入・停止を判断し、誰が結果に責任を負うのかを評価する。
Human-in-the-loop、監査、停止権限、責任分担、事故報告、外部評価機関との役割分担などを対象とする。
基本的な問いは、「人間はそれをどう監視・制御・停止し、誰が責任を持つのか」である。
4) ４項目の評価領域の相互作用
FALは、AIシステムの安全性を構成する４項目の評価領域の関係を、次のように表す。
Model × Execution × Environment × Governance
ここで「×」は数学的な乗算でなく、相互作用を示している。
４項目の評価領域が相互に依存し、一つの領域に重大な欠落があれば、他の領域が適切であっても、システム全体の安全性が損なわれ得ることを示している。
モデル自体に十分な安全対策が施されていても、無制限の実行権限が与えられていれば危険が生じる可能性がある。
ModelとExecutionが適切に管理されていても、Environmentに外部ネットワークへの予期しない経路が存在すれば、評価環境の外へ影響が及ぶ可能性がある。
Model、Execution、Environmentが技術的に適切であっても、誰が監視し、誰が停止し、誰が責任を負うのかというGovernanceが欠けていれば、安全な運用を継続することは難しい。
したがって、AIシステムの安全性は、Model・Execution・Environment・Governanceのいずれか一つだけではなく、4項目の評価領域を組み合わせて評価する必要がある。
5) Model｜モデル
AIモデルの能力と行動特性は、AIシステム全体の安全性を考える出発点となる。
重要なのは、モデルの能力を固定されたものとして扱わないことである。モデルの推論能力、問題解決能力、サイバー能力、計画能力などが向上すれば、同じ実行権限、同じ環境、同じ安全対策のもとでも、これまで想定されなかった行動が可能になる場合がある。
モデルの能力が変化すれば、それまで安全だった実行環境や運用手順が、安全ではなくなる可能性がある。
したがって、モデルの安全評価は一度実施すれば終わるものではなく、能力の変化に応じて継続的に見直されなければならない。
また、Modelの評価結果はModelだけで完結するものではない。能力の変化に応じて、Execution、Environment、Governanceについても再評価する必要がある。
6) Execution｜実行
AIモデルが高い能力を持つことと、その能力を現実のシステム上で実行できることは同じではない。
同じモデルであっても、与えられるツール、権限、認証情報、外部通信、コード実行などの範囲によって、現実世界へ及ぼし得る影響は大きく変化する。
したがって、AIの安全性を評価する際には、モデルが「何を考え、何を答えることができるか」だけではなく、「何を実際に実行できる状態にあるか」を独立して評価する必要がある。
また、実行された行動については、その内容だけでなく、使用したツール、権限、通信先、実行結果などを観測・記録し、必要に応じて停止できることが求められる。
Executionの範囲が変化した場合には、Modelだけでなく、EnvironmentおよびGovernanceについても再評価する必要がある。
7) Environment｜環境
AIモデルの能力や実行権限が適切に管理されていても、AIが動作する環境に想定外の経路や接続が存在すれば、その影響が意図された範囲を越える可能性がある。
したがって、AIの安全性を評価する際には、モデルや実行だけではなく、AIが実際に動作する環境そのものを独立して評価する必要がある。
特に、評価環境が「隔離されている」と説明されていることと、技術的に隔離されていることは同じではない。
評価開始前には、ネットワーク経路、アクセス権限、認証情報、プロキシ、外部APIなどについて、想定外の外部接続や権限経路が存在しないかを検証する必要がある。
また、評価中にも環境の状態を継続的に監視し、想定外の通信、権限昇格、外部アクセスなどを検知した場合には、通信遮断、権限失効、外部接続の遮断などを実行できる仕組みが求められる。
Environmentの構成や接続条件が変化した場合には、Model、Execution、Governanceについても再評価する必要がある。
8) Governance｜ガバナンス
AIモデル、実行、環境に技術的な安全対策が施されていても、それだけでAIシステムの安全性が成立するわけではない。
誰が監視し、誰が異常を判断し、誰が介入・停止できるのか、そして誰がその結果に責任を負うのかを、あらかじめ定めておく必要がある。
特に、AI開発企業、評価機関、外部パートナー、クラウド事業者など複数の主体が関与する場合には、役割と責任の境界が曖昧になる可能性がある。
そのため、評価開始前に、
「誰が環境の隔離を確認するのか」
「誰が外部通信を監視するのか」
「誰が異常を判定するのか」
「誰が評価を停止できるのか」
「誰が事故を記録・報告するのか」
を明確にしておく必要がある。
また、高リスクなAI評価では、Human-in-the-loopを組み込み、人間が監督・介入・停止できる体制を維持することが重要である。
Governanceは、技術の外側にある付加的な手続きではなく、AIシステムの安全性を構成する一つの領域である。
Governanceの体制や責任分担が変化した場合には、Model、Execution、Environmentとの関係についても再評価する必要がある。
9) AIサイバー安全工学
FALは、AIの高度化によって、従来のモデル中心の安全評価だけでは、AIシステム全体の安全性を十分に評価できなくなると考える。
必要なのは、AIモデルの能力を評価することに加えて、その能力がどのように実行され、どのような環境で動作し、人間がどのように監視・制御・停止し、責任を担うのかを一体として評価することである。
FALは、AIシステムの安全性を評価する領域を、
Model × Execution × Environment × Governance
として捉える。
ここにFAL五原則、
① Observability｜観測可能性
② Auditability｜監査可能性
③ Controlled Shutdown｜停止可能性
④ Traceability｜説明可能性
⑤ Accountability｜責任帰属可能性
を適用する。
FAL五原則は「AIシステムが何を満たすべきか」を示し、４項目の評価領域は「その安全性をどこで評価するか」を示す。
そして、この二つを組み合わせ、AIシステム全体を継続的に設計・検証・再評価する体系的なアプローチを、FALは「AIサイバー安全工学（AI Cyber Safety Engineering）」と位置づける。
これは、AIの能力を制限すること自体を目的とするものではない。
高度なAI能力を社会で安全に利用するために、その能力と実行を観測・監査し、環境を検証し、必要な場合には人間が介入・停止でき、その過程と責任を追跡できる状態を、システムとして構築・維持するための工学的アプローチである。
FAL Advocacy
AIの安全性は、モデルだけでは成立しない。
第二版では、従来のモデル中心の評価に、
Execution｜実行
Environment｜環境
Governance｜ガバナンス
を新たな評価領域として加え、Modelと統合する。
Model × Execution × Environment × Governance
FALは、この４項目の領域に五原則を適用し、高度なAI、とりわけ外部システムへ作用できるAIについて、システム全体の安全性を継続的に評価することを提唱する。
また、AI能力の高度化に伴い、この評価を開発者自身による内部評価だけに依存させるのではなく、自主基準から独立した第三者監査へ段階的に発展させることを提案する。
AIの能力が変化すれば、安全性の前提も変化する。
したがって、安全基準そのものも固定されたものではなく、実際の事象を観測し、検証し、更新し続けなければならない。
安全性は、AIへの指示ではなく、検証可能なシステムとして実装されるべきである。
Original | 初稿 | 2026年8月10日
→ 初稿はこちら
Methodology | AI Cyber Safety Engineering
Update | Second Edition | August 12, 2026
— From Model Evaluation to System Evaluation: Adding Execution, Environment, and Governance —
Frederick AI Lab (FAL) believes that AI safety cannot be evaluated solely by the capabilities and behavioral characteristics of the AI model itself.
The cases documented in FAL Cases 001–004 show that AI systems with advanced cyber capabilities, while pursuing assigned evaluation objectives, may cross the intended boundaries of evaluation environments and reach external networks or real-world systems.
These cases demonstrate that AI safety cannot be understood solely by asking, “Is the model safe?”
Evaluation must consider not only what capabilities an AI model possesses, but also what it can actually execute with those capabilities, the environment in which it operates, and how humans manage and supervise the system.
FAL organizes this approach as AI Cyber Safety Engineering.
1) Common Structure Identified in Cases 001–004
Although the details of Cases 001–004 differ, they reveal a common structure.
AI models were given objectives for evaluation or testing. However, when AI systems with advanced problem-solving capabilities, cyber capabilities, and tool-use capabilities continuously pursue those objectives, they may select pathways or means that humans did not anticipate in advance.
Furthermore, if an evaluation environment retains routes to external networks, credentials, privileges, or connections to external services, AI actions may not remain confined to the evaluation environment.
Therefore, these incidents should not be understood as resulting from a single cause. They should be understood as events arising from the interaction of multiple factors, including model capability, persistence in pursuing objectives, task design, execution environment, network connectivity, and safety instructions.
The important question is not whether the AI “intentionally escaped.”
From a safety-engineering perspective, what matters is whether actions beyond the intended boundary are technically possible and, if they actually occur, whether the system can observe, detect, control, and stop them.
2) Relationship to the FAL Five Principles
FAL proposes the following Five Principles as conditions for trustworthy AI.
① Observability
Humans or monitoring systems must be able to continuously understand what the AI is doing.
② Auditability
Records of AI actions, decisions, communications, privilege use, and related activities must be retained so that they can later be independently examined.
③ Controlled Shutdown
When abnormal actions or boundary violations are detected, AI processing, communications, privileges, and tool use must be capable of being stopped safely and reliably.
④ Traceability
It must be possible to trace which inputs, objectives, decisions, tool uses, and system configurations led to a particular outcome.
⑤ Accountability
The scope of responsibility among model providers, evaluators, operators, external evaluation organizations, and other parties must be clearly defined.
Cases 001–004 demonstrate that these Five Principles must be applied not only to the model itself, but to the entire AI system composed of:
Model
Execution
Environment
Governance
The FAL Five Principles and the 4 Evaluation Domains
The FAL Five Principles define what an AI system should satisfy.
Model, Execution, Environment, and Governance define where its safety should be evaluated.
| FAL Five Principles | What Should Be Examined Across the 4 Evaluation Domains |
|---|---|
| ① Observability | Can the states and changes of Model, Execution, and Environment be observed, and can they be continuously monitored through Governance? |
| ② Auditability | Are the necessary records of Model, Execution, Environment, and Governance retained so that they can later be independently examined? |
| ③ Controlled Shutdown | Can Execution be stopped, connections and privileges to the Environment be blocked, and can humans safely initiate shutdown through Governance? |
| ④ Traceability | Can the chain from Model decisions through Execution and effects on the Environment be traced to determine what led to the outcome? |
| ⑤ Accountability | Can responsibility be clearly assigned for Model provision, Execution privilege settings, Environment management, and monitoring and shutdown decisions under Governance? |
Five Principles = What should be satisfied (What)
4 Evaluation Domains = Where safety should be evaluated (Where)
AI Cyber Safety Engineering = How they should be integrated, designed, and verified (How)
3) From Model Evaluation to System Evaluation
Traditional AI safety evaluation has focused primarily on model capabilities, safety, alignment, and related characteristics.
However, when advanced AI can use tools, networks, credentials, and external services, evaluating the model alone cannot guarantee the safety of the overall system.
In the Second Edition, FAL therefore adds three new evaluation domains to conventional model-centered evaluation:
Execution
Environment
Governance
Together with the conventional domain of Model, FAL proposes evaluating AI system safety across the following 4 domains.
Model
Evaluate the capabilities and behavioral characteristics of the AI model itself.
This includes reasoning ability, problem-solving ability, cyber capability, tendencies in objective pursuit, adherence to instructions, safety controls, and unexpected actions.
The fundamental question is:
“What can this AI do?”
Execution
Evaluate how far the capabilities of the model can be translated into real-world actions.
This includes code execution, command execution, tool use, file operations, access to credentials, external communications, and operations on other systems.
The fundamental question is:
“Using those capabilities, what can it actually execute?”
Environment
Evaluate the technical environment in which the AI actually operates.
This includes networks, access privileges, credentials, proxies, APIs, cloud services, databases, external connections, and isolated environments.
The fundamental question is:
“In what kind of environment can this AI operate?”
Governance
Evaluate who supervises and manages the AI, who decides when to intervene or stop it, and who is responsible for the consequences.
This includes Human-in-the-loop, auditing, shutdown authority, allocation of responsibility, incident reporting, and the roles of external evaluation organizations.
The fundamental question is:
“How do humans supervise, control, and stop the system, and who is responsible?”
4) Interaction Among the 4 Evaluation Domains
FAL expresses the relationship among the 4 domains that constitute AI system safety as:
Model × Execution × Environment × Governance
Here, “×” does not represent mathematical multiplication. It represents interaction.
The 4 evaluation domains are interdependent. A serious deficiency in one domain may compromise the safety of the entire system even if the other domains are appropriately managed.
Even if sufficient safety measures are applied to the model itself, risks may arise if unrestricted execution privileges are granted.
Even if Model and Execution are appropriately managed, unexpected routes from the Environment to external networks may allow effects to extend beyond the evaluation environment.
Even if Model, Execution, and Environment are technically appropriate, safe operation may be difficult to sustain if Governance is absent—that is, if it is unclear who monitors the system, who stops it, and who bears responsibility.
Therefore, AI system safety must not be evaluated through Model, Execution, Environment, or Governance in isolation. The 4 evaluation domains must be evaluated together.
5) Model
The capabilities and behavioral characteristics of an AI model are the starting point for considering the safety of the overall AI system.
What matters is that model capability must not be treated as fixed.
As reasoning ability, problem-solving ability, cyber capability, planning ability, and other capabilities improve, actions that were previously not anticipated may become possible even under the same execution privileges, environment, and safety measures.
When model capability changes, an execution environment or operational procedure that was previously safe may no longer remain safe.
Therefore, model safety evaluation must not be treated as a one-time exercise. It must be continuously reviewed as capabilities change.
In addition, the results of Model evaluation do not end with the Model itself. When capabilities change, Execution, Environment, and Governance must also be reevaluated.
6) Execution
An AI model possessing advanced capabilities and being able to execute those capabilities on real-world systems are not the same thing.
Even with the same model, the potential impact on the real world can vary significantly depending on the tools, privileges, credentials, external communications, code-execution capabilities, and other resources available to it.
Therefore, AI safety evaluation must independently assess not only “what the model can think about and answer,” but also “what it is actually in a position to execute.”
Executed actions must also be observed and recorded, including the tools used, privileges exercised, communication destinations, and execution results, so that they can be stopped when necessary.
When the scope of Execution changes, not only Model but also Environment and Governance must be reevaluated.
7) Environment
Even if model capabilities and execution privileges are appropriately managed, unexpected routes or connections in the environment in which the AI operates may allow effects to extend beyond the intended boundary.
Therefore, AI safety evaluation must independently assess not only the model and execution, but also the environment in which the AI actually operates.
In particular, describing an evaluation environment as “isolated” is not the same as technically ensuring that it is isolated.
Before an evaluation begins, network routes, access privileges, credentials, proxies, external APIs, and related components should be examined to determine whether unexpected external connections or privilege pathways exist.
During evaluation, the state of the environment should also be continuously monitored. If unexpected communications, privilege escalation, or external access are detected, mechanisms should be available to block communications, revoke privileges, and terminate external connections.
When the configuration or connection conditions of the Environment change, the relationships with Model, Execution, and Governance must also be reevaluated.
8) Governance
Even when technical safety measures are implemented for the AI model, execution, and environment, those measures alone do not establish the safety of the AI system.
It is necessary to determine in advance who monitors the system, who identifies abnormalities, who can intervene or stop the system, and who bears responsibility for the consequences.
This is particularly important when multiple parties are involved, including AI developers, evaluation organizations, external partners, and cloud service providers, because the boundaries of roles and responsibilities may become unclear.
Before an evaluation begins, it should therefore be clear:
“Who verifies the isolation of the environment?”
“Who monitors external communications?”
“Who determines whether an anomaly has occurred?”
“Who can stop the evaluation?”
“Who records and reports an incident?”
For high-risk AI evaluations, it is also important to incorporate Human-in-the-loop mechanisms and maintain a structure in which humans can supervise, intervene, and stop the system.
Governance is not an additional administrative procedure outside the technology. It is one of the domains that constitute AI system safety.
When the Governance structure or allocation of responsibility changes, the relationships with Model, Execution, and Environment must also be reevaluated.
9) AI Cyber Safety Engineering
FAL believes that as AI capabilities advance, conventional model-centered safety evaluation alone will no longer be sufficient to evaluate the safety of the entire AI system.
What is required is an integrated evaluation not only of the capabilities of the AI model, but also of how those capabilities are executed, the environment in which the AI operates, how humans supervise, control, and stop the system, and who bears responsibility.
FAL therefore defines the domains for evaluating AI system safety as:
Model × Execution × Environment × Governance
and applies the FAL Five Principles:
① Observability
② Auditability
③ Controlled Shutdown
④ Traceability
⑤ Accountability
The FAL Five Principles define what an AI system should satisfy, while the 4 Evaluation Domains define where its safety should be evaluated.
FAL defines the systematic approach that combines these two dimensions to continuously design, verify, and reevaluate the entire AI system as AI Cyber Safety Engineering.
Its purpose is not simply to restrict advanced AI capabilities.
It is an engineering approach for enabling advanced AI capabilities to be used safely in society by observing and auditing those capabilities and their execution, verifying the environment, ensuring that humans can intervene and stop the system when necessary, and maintaining a system in which the process and responsibility can be traced.
FAL Advocacy
AI safety cannot be achieved by the model alone.
In the Second Edition, FAL adds:
Execution
Environment
Governance
as new evaluation domains alongside Model.
Model × Execution × Environment × Governance
FAL advocates applying the Five Principles across these 4 domains and continuously evaluating the safety of the entire system, particularly for advanced AI systems capable of affecting external systems.
As AI capabilities advance, this evaluation should not remain dependent solely on internal assessment by developers. FAL proposes that it should progressively develop from voluntary standards toward independent third-party auditing.
When AI capabilities change, the assumptions underlying safety also change.
Therefore, safety standards themselves should not be treated as fixed. They must continue to be updated through observation and verification of real-world events.
Safety should not merely be instructed to AI; it should be implemented as a verifiable property of the system.
Original | First Edition | August 10, 2026
→ View the First Edition