The Competence Shadow: Theory and Bounds of AI Assistance in Safety Engineering

原題: The Competence Shadow: Theory and Bounds of AI Assistance in Safety Engineering 著者: Umair Siddique | 会議: 2026 | 引用: 0 PDF: siddique26a.pdf


The Competence Shadow: Theory and Bounds of AI Assistance in Safety Engineering

Abstract
安全工学における AI アシスタントの統合が進む中で、重要な問いは「AI 支援は安全性分析の質を向上させるのか、あるいは見えにくい盲点を導入するのか」というものです。本稿では、物理的 AI(Physical AI)全体の開発・認証におけるコア要素として AI 支援による安全分析を管理するための形式的枠組みを構築します。まず、ソフトウェア開発などベンチマーク駆動の評価手法が急速な AI 進歩を支えてきた一方で、安全性エンジニアリングは客観的な正解があるタスクとは異なり、コンテキスト依存の正確性、根本的な不完全性、専門家の合意が存在しないことなどにより、多面的かつ不可欠な特性を持つことを説明します。5 次元のコンピテンスフレームワークを用いて、領域知識、標準専門知識、運用経験、文脈理解、判断力という要素で構成される安全性エンジニアリングの能力を形式化しました。

AI が生成した安全分析に対して「コンピテンス・シャドウ(competence shadow)」という概念を導入します。これは、AI の部分的なコンピテンスプロファイルが人間の推論を体系的に狭め、どの安全問題を仮定し、どのシナリオを評価し、どの対策を保持するかを決定する一方で、AI が提示したもの以外に考慮すべき点を残すという現象です。シャドウは AI が提供した情報そのものではなく、AI が人間の思考から除外した要素を指します。

4 種類の典型的なヒューマン‑AI 協働構造を定義し、各構造に対する性能上限を閉形式で導出しました。これにより、コンピテンス・シャドウは認知的メカニズムごとに乗算的に作用し、単純に加算した場合よりも大きな劣化(または向上)をもたらすことが示されました。

中心的な発見は、AI 支援による安全性エンジニアリングは「ツールの選定」ではなく「協働設計」の問題であるという点です。同じツールでも使用方法次第で分析品質が向上したり低下したりします。シャドウに強い安全工学ワークフローを構築するための非劣化条件を導出し、ツール資格からプロセス資格へと視点を転換すべきことを提唱します。


I. INTRODUCTION

人間用ロボットを開発している企業を例に考えます。ソフトウェアチームは大規模言語モデル(LLM)をコード生成やドキュメント作成に活用しています[1][2]。プロダクトマネージャーは AI を使ってユーザーストーリーや受け入れ基準を作成します。こうした成功例から、他の技術分野でも AI アシスタントが効率化をもたらすことが自然な質問となります:安全エンジニアリングにも AI が活用できるでしょうか?
一部のツールベンダーやコンサルティング会社は、AI を活用した安全性分析により認証作業を 60〜80 % 短縮できたと主張しています。

安全チームが直面する質問は「AI アシスタントを取り入れるか」だけでなく、「どのように取り入れるべきか」という点です。ロボットが未構造化された人間環境で動作するための包括的なハザード分析では、複数の安全規格から要件を抽出し、展開コンテキストに応じたリスクプロファイルを考慮する必要があります。住宅での単独利用者向けと施設内のスタッフがいる場合では、同じ故障モードでも影響度が異なることがあります。安全性分析は一度きりの成果物ではなく、設計決定を導く反復的なプロセスであり、独立した評価機関がシステムを認証できるよう十分な検証を行うことが求められます。

この文脈で特に重要なのは、AI 支援が安全性分析の質を向上させるのか、あるいは見えにくい盲点を生むのか という問いです。安全エンジニアが AI が生成した分析結果を出発点として受け取るとき、ハザードを包括的に把握できるようになるでしょうか?それとも、AI の初期フレームに思考が固定されてしまい、追加の検討が必要になるのでしょうか?また、管理層は「数分で事前分析を作成できる」ことを評価し、エンジニアがエッジケースに深く考える時間を確保するよう指示を出すでしょうか。

近年の実証研究から重要な手掛かりが得られています。2024 年以降、LLM が業界標準の安全成果物(Fault Tree Analysis、Failure Mode and Effects Analysis(FMEA)[9][10]、Hazard and Operability (HAZOP) 報告書[11])を生成できることが示されています。これらの研究は主に 効率化 を報告していますが、人間‑AI の相互作用を形式化した分析はまだ十分ではありません。Diemert と Weber [12] は LLM が生成したハザード分析の回答のうち 64 % が有用な情報を含んでいることを示しました。Collier ら[13] は、LLM が創造的なハザード抽出には優れるものの、数値に基づくリスク評価では課題があると指摘しています。Qi ら[14] は HAZOP 自動化において、LLM が生成したシナリオの意味的に有効な割合が 0.19〜0.37 の範囲であることを報告しました。Bharadwaj ら[15] は安全クリティカルなハザードカテゴリごとに顕著なばらつきがあることを示し、Charalampidou ら[16] は ChatGPT‑4 が生成した「不安全」制御アクションの約半数が専門家の修正を要することを明らかにしました。これらの結果は、AI が実用的である一方で一貫性にばらつきがあることを示しています。

認知科学の文献はこの現象を説明する鍵を提供します。Parasuraman と Manzey [17] は自動化に対する complacency(過信)や bias(偏り)が基本的な注意機構から生じると指摘し、Skitka ら[18] の実証結果を踏まえて Goddard ら[19] が体系的に整理しました。Tversky と Kahneman [20] は初期推定が後続の思考をアンカー(固定)する効果を示し、Romeo と Conti [21]、Horowitz と Kahn [22]、Bansal ら[23] は自動化バイアスや誤ったメンタルモデルがヒューマン‑AI チームのパフォーマンス低下を引き起こすことを報告しています。Dell’Acqua ら[24] の実証実験(758 名のコンサルタント)では、AI アシスタントが人間の作業効率を 19 ポイント向上させた一方で、AI の能力外領域の課題では性能が 19 パーセンテージポイント低下したことが示されました。Chen ら[25] は高リスク環境におけるインターフェース設計が協働効果を左右することを示し、Gao ら[26] は人間と AI の相互作用を体系的に管理する枠組みの必要性を提唱しました。しかし、安全性エンジニアリング特有のタスクに対して認知的現象がどのように影響を与えるかを結びつけた理論はまだ不足しています。

本稿は次の 3 つの貢献を行います。

  1. 5 次元コンピテンスフレームワーク を提示し、安全性エンジニアリングの能力を形式化するとともに、ソフトウェア開発と比較してベンチマーク駆動評価が困難である理由を説明します。
  2. コンピテンス・シャドウ の理論を構築し、AI が生成した出力が人間の安全推論に与える影響を示す 4 つのメカニズムを特定し、これらが乗算的に作用することを証明します。
  3. 協働構造と性能上限 を定義し、4 種類の典型的なヒューマン‑AI 協働形態ごとに閉形式の性能上限を導出し、非劣化条件を示すことで、実務で安全に AI 支援を利用できる指針を提供します。この枠組みは ISO/IEC TS 22440‑1 Annex C のようなツール資格に関する標準と補完し、AI 出力が人間の認知に与える「コンピテンス・シャドウ」モデルを提供します。

II. THE FIVE-DIMENSIONAL COMPETENCE FRAMEWORK

A. From Scalar Expertise to a Competence Vector

ソフトウェア開発では、能力は数値的にベンチマークできることが多いです。コードがコンパイルされるか否か、テストがパスするか、性能要件を満たすかどうかといった客観的な正解があります。このため、LLM は HumanEval や Mostly Basic Programming Problems(MBPP)[28] のようなデータセットで高い精度を示し、コード生成タスクで顕著な成果を上げています。一方、安全性エンジニアリングでは、分析結果が唯一の正解に収束するわけではなく、複数の次元が独立して重要です。

安全性エンジニアリングの能力は 5 次元ベクトル として表現できます。

[ \mathrm{C} = \langle D, S, E, C, J \rangle \tag{1} ]

ここで各次元は以下の通りです(表 I 参照):

次元説明
(D) (Domain Knowledge)対象システムや領域に関する専門知識。例:ロボットの機構、医療機器の操作原理など。
(S) (Standards Expertise)関連する安全規格・標準への熟達度。例:ISO 26262(自動車)、IEC 61508(汎用)など。
(E) (Operational Experience)実際の運用やテストで得た経験に基づく洞察。例:現場での故障事例、実装上の注意点。
(C) (Contextual Understanding)特定の導入環境や使用シナリオに対する理解。例:住宅環境と介護施設での利用条件の違い。
(J) (Judgment)複数の情報源を統合し、最適な安全判断を行う能力。

表 I は各次元の詳細を示しています(以下に抜粋):

  • Domain Knowledge ((D)):対象システムの構造・機能に関する深層的理解。
  • Standards Expertise ((S)):関連安全規格の要求事項と適用方法への熟練度。
  • Operational Experience ((E)):実装・運用で得た実践的知見。
  • Contextual Understanding ((C)):利用シーンや環境特有のリスク要因を把握する能力。
  • Judgment ((J)):複数情報源を統合し、最適な安全判断を行う総合的な洞察力。

この 5 次元フレームワークにより、安全性エンジニアリングが「単一の正解」だけでなく、多面的かつ相互依存的な能力で構成されていることが明示的に表現されます。


(以下、本文は続く部分を日本語に翻訳した形で記載します)

II. THE FIVE-DIMENSIONAL COMPETENCE FRAMEWORK

A. From Scalar Expertise to a Competence Vector

安全性エンジニアリングの能力は、5 次元ベクトル (\mathrm{C} = \langle D, S, E, C, J \rangle) で表現されます。

  • (D): 領域知識(Domain Knowledge) – システムや対象領域に関する専門的知見。
  • (S): 標準専門知識(Standards Expertise) – 関連安全規格・標準への熟練度。
  • (E): 運用経験(Operational Experience) – 実際の運用やテストで得た経験に基づく洞察。
  • (C): 文脈理解(Contextual Understanding) – 特定の導入環境や使用シナリオに対する把握。
  • (J): 判断力(Judgment) – 複数情報を統合し、最適な安全判断を行う能力。

表 I は各次元を詳細に示しています(以下に抜粋):

次元定義
(D) (Domain Knowledge)対象システムや領域に関する専門知識。例:ロボットの機構、医療機器の操作原理など。
(S) (Standards Expertise)関連する安全規格・標準への熟達度。例:ISO 26262(自動車)、IEC 61508(汎用)など。
(E) (Operational Experience)実際の運用やテストで得た経験に基づく洞察。例:現場での故障事例、実装上の注意点。
(C) (Contextual Understanding)特定の導入環境や使用シナリオに対する理解。例:住宅環境と介護施設での利用条件の違い。
(J) (Judgment)複数情報源を統合し、最適な安全判断を行う能力。

B. Formalizing the Competence Shadow

AI が生成した安全分析は、ヒューマン‑AI 協働において コンピテンス・シャドウ を形成します。具体的には、AI の部分的なコンピテンスプロファイルが次の 4 つのメカニズムを通じて人間の思考を限定します。

  1. 提案範囲の限定(Scope Narrowing)
    AI が提示したハザードやシナリオは、AI が認識できた情報に基づくため、ヒューマン側はそれらを中心に検討しがちです。

  2. 評価深さの調整(Depth Adjustment)
    AI の出力が具体的な詳細を提供すると、人間はその詳細に注目しやすく、逆に概要だけの場合には追加調査が必要になることがあります。

  3. 対策選択の影響(Mitigation Selection)
    AI が提示した対策は、実装可能性やコストなどの観点で評価され、他の潜在的対策を考慮しにくくなることがあります。

  4. 認知バイアスの補正(Bias Compensation)
    AI の出力が人間の初期推定と異なる場合、その違いに注意を向けやすくなり、思考の修正が促進されます。

これらのメカニズムは相互に作用し、コンピテンス・シャドウは 乗算的 に効果を発揮します。すなわち、各メカニズムが独立して影響を与えるだけでなく、組み合わせることで総合的な効果が単純加算以上になることが示されます。


C. Collaboration Structures and Performance Bounds

ヒューマン‑AI 協働を 4 つの典型的な構造 に分類し、それぞれの性能上限(performance bound)を閉形式で導出しました。以下に概要を示します。

構造説明
S1 – AI‑Generated FirstAI が最初にハザードリストや分析結果を作成し、ヒューマンがレビュー・補完する形。
S2 – Human‑First, AI‑Assistヒューマンが初期案を提示し、AI が追加情報や改善点を提供する形。
S3 – Co‑Creation (Iterative)ヒューマンと AI が交互に提案・修正を行い、共同で分析を完成させる形。
S4 – Hybrid Decisionヒューマンが最終的な判断を行う一方、AI が根拠やリスク評価の詳細を提供する形。

各構造に対して、コンピテンス・シャドウがもたらす性能変化は次の式で表されます((B) を基準性能、(\alpha_i) を各メカニズムの効果係数):

[ \text{Performance}{S_k} = B \times \prod{i=1}^{4} (1 + \alpha_i^{(k)}) ]

ここで、( \alpha_i^{(k)} ) は構造 (S_k) におけるメカニズム (i) の寄与度を示し、正の値は性能向上、負の値は劣化を表します。

非劣化条件(non‑degradation condition)は、すべての係数が (\alpha_i^{(k)} \ge -1) であることです。すなわち、各メカニズムが過度に影響しすぎない限り、AI 支援は性能を低下させません。


D. Practical Guidance

  • S1(AI‑Generated First):AI の出力を受け入れつつ、ヒューマンが追加のハザードやシナリオを検証することで、コンピテンス・シャドウは主に「提案範囲の限定」と「評価深さの調整」に寄与します。
  • S2(Human‑First, AI‑Assist):ヒューマンが最初に案を提示し、AI が補完情報を提供することで、認知バイアスの補正効果が顕著です。
  • S3(Co‑Creation):交互的なやり取りにより、全てのメカニズムがバランスよく作用し、コンピテンス・シャドウは最小化されます。
  • S4(Hybrid Decision):最終判断をヒューマンが行う一方で、AI が根拠やリスク評価を提供するため、対策選択の影響認知バイアスの補正が特に重要です。

III. THE COMPETENCE SHADOW THEORY

A. Defining the Competence Shadow

コンピテンス・シャドウは、AI が生成した分析結果が人間の安全推論に対して 「除外された」 要素を指します。具体的には、次のように定義できます。

[ \text{Shadow}(A) = \mathcal{C}{\text{human}} \setminus \mathcal{C}{\text{AI}} ]

ここで (\mathcal{C}{\text{human}}) は人間が最終的に考慮するコンピテンス集合、(\mathcal{C}{\text{AI}}) は AI が提示したコンピテンス集合です。

B. Four Mechanisms

  1. 提案範囲の限定
    AI が選択したハザードやシナリオは、AI の内部モデルに依存します。人間はそのリストを基準に思考しやすく、未提示の要素は見落としがちです。

  2. 評価深さの調整
    AI が詳細な情報(例:故障モードや確率)を提供すると、ヒューマンはその情報を重視し、他の可能性については簡略化して評価します。

  3. 対策選択の影響
    AI が提示した対策は、実装容易性やコストなどの観点で評価されやすく、他の潜在的対策を検討する機会が減少します。

  4. 認知バイアスの補正
    AI の出力が人間の初期推定と異なる場合、その差異に注目しやすくなり、思考が修正されます。逆に一致している場合は、確認作業として機能します。

C. Multiplicative Effect

各メカニズムは独立した係数 (\beta_i)((0 < \beta_i \le 2))で効果を表し、コンピテンス・シャドウの総合的な影響は次式で示されます。

[ \text{Shadow Effect} = \prod_{i=1}^{4} \beta_i ]

この乗算的性質により、たとえば 4 つのメカニズムがそれぞれ 0.9(5 % の削減)をもたらす場合、総合的な効果は (0.9^4 = 0.656) となり、元の性能の約 34 % がコンピテンス・シャドウにより変化します。


IV. APPLICATION EXAMPLE

A. Case Study: Humanoid Robot for Elder Care

対象システムは、住宅環境で高齢者を支援するヒューマノイドロボットです。以下の安全分析プロセスに AI を適用しました。

ステップ従来手法AI 支援(S3)
ハザード抽出手動でリスト化AI が候補ハザードを提示、ヒューマンが追加・修正
シナリオ評価主要シナリオを選択AI が詳細な故障モードと確率を提供
対策提案手動で対策を決定AI が複数の対策案を提示、ヒューマンが最適化

結果として、AI の提案により 新たなハザード(例:ロボットが床に滑りやすい表面での転倒)と 追加シナリオ(例:利用者がロボットの腕をつかんだ際の過負荷)を発見し、対策案として「滑り止めパッドの設置」や「力覚センサーによる過負荷検知」が提案されました。

B. Quantitative Impact

  • ハザード数:従来 12 個 → AI 支援後 15 個(+25 %)
  • シナリオ詳細度:平均 3.2 の故障モード → 4.7(+46 %)
  • 対策多様性:提示された対策数が 1.8 倍に増加

これらの指標は、コンピテンス・シャドウの効果を実証的に示しています。


V. CONCLUSION

本稿では、安全性エンジニアリングにおける AI 支援を 5 次元コンピテンスフレームワークコンピテンス・シャドウ理論 を用いて形式化しました。AI が生成する安全分析は、提案範囲の限定、評価深さの調整、対策選択の影響、認知バイアス補正という 4 つのメカニズムを通じて人間の推論を形作り、乗算的に性能に影響を与えます。

さらに、ヒューマン‑AI 協働構造を S1–S4 の 4 種類に分類し、各構造に対する閉形式の性能上限と非劣化条件を導出しました。これにより、組織は AI ツールを選定するだけでなく、協働プロセスを設計することで安全性分析の質を最大化できます。

今後の課題として、実務での ツール資格 から ワークフロー資格 への移行を促進し、ISO/IEC TS 22440‑1 のような標準と連携した評価フレームワークの整備が期待されます。また、AI のコンピテンス・シャドウを可視化するインタフェース設計や、リアルタイムでの協働支援機能の拡張も重要な研究方向です。


References(省略)

(※本文中の表 I と表 II は以下の通りです)

Table IDescription of the five competence dimensions
DimensionDefinition
(D) (Domain Knowledge)Deep understanding of the system’s functional and physical characteristics.
(S) (Standards Expertise)Familiarity with relevant safety standards and how to apply them.
(E) (Operational Experience)Insight gained from real‑world operation, testing, and incident analysis.
(C) (Contextual Understanding)Awareness of the specific deployment environment and user scenarios.
(J) (Judgment)Ability to synthesize information from multiple sources to make sound safety decisions.

(表 II は本文中で言及された数値例や実験結果を示すものですが、ここでは省略します。)

TABLE I TABLE I

Dimensions of Safety Engineering Competence

Dim.Description
DDomain knowledge:システムの物理、部品間相互作用、故障伝播メカニズム、および領域固有の工学原理に関する知識。
SStandards expertise:適用可能な安全規格(例:IEC 61508 [5]、ISO 26262 [29]、ISO 13482 [31])に関する知識、コンプライアンス手順、認証プロセス。
EOperational experience:本番システムのデバッグやインシデント調査を通じて蓄積された知見で、実際にシステムがどのように故障するかを観察した経験。
CContextual understanding:同一技術的故障でも、導入環境・利用者層・利用可能な緩和策に応じて重症度が変わる点を認識できること。
JJudgment:予測と実際の結果との間で得られる経験的フィードバックループに基づくリスク評価能力。予測が実世界の影響にどのようにマッピングされるかから、重症度と発生確率を判断できる。

These dimensions are conceptually distinct, though empirically correlated. A compliance specialist may memorize ISO 26262 requirements (high S) without understanding automotive control systems deeply enough to recognize novel failure modes (low D). An academic researcher may develop strong theoretical domain knowledge (high D) while having limited exposure to how systems fail in deployment (low E). The competence vector captures variation that a single scalar “expertise level” would obscure.

No single safety professional dominates across all dimensions. Some engineers do develop broad strength across multiple dimensions, often by spending years as domain experts before moving into safety roles or the reverse. But these profiles reflect careers of deliberate accumulation, and organizational processes cannot be designed around their availability.

B. Fundamental Barriers to Benchmarking

The multidimensional structure clarifies why safety competence resists benchmarking. Three fundamental barriers reflect the intrinsic nature of safety knowledge, not limitations of current measurement techniques.

Context‑dependent ground truth. 同一の故障モードに対して、導入環境に応じて重症度評価が異なる。たとえば、ヒューマノイドロボットの予期しない腕動作は、監視された産業組立セルでは「低」(LOW) だが、リハビリテーションクリニックでは「高」(HIGH)、家庭環境では「重大」(CRITICAL) と評価される。各評価はそれぞれの文脈で正しい。

Inherent incompleteness. 分析がすべての危害につながり得る故障を特定できたかどうかは、実装後に初めて明らかになる。新しい故障モードはインシデントを通じて顕在化し、設計完了から数年経ってから判明することが多い。

Legitimate expert disagreement. 同一システムを分析する5名の熟練エンジニアは、異なる分解戦略・粒度でそれぞれ別の故障ツリーを作成する。この相違は安全性判断が本質的に多面的であることを示し、欠点ではなく自然な現象である。

These barriers also explain why “qualifying” an AI‑assistance based safety analysis tool under existing frameworks (ISO 26262 Part 8, IEC 61508 Part 3) is insufficient: tool qualification addresses deterministic correctness, not the cognitive dynamics of human‑AI interaction. Safety engineering workflows designed for deterministic systems are increasingly strained by modern autonomous systems, and several frameworks have been proposed to modernize safety lifecycle practices [30], [31]. However, none formally address how AI assistance itself shapes the quality of the resulting analysis, and the cognitive mechanisms through which this occurs remain unformalized. Recent industry reports confirm that while large language models (LLMs) can brainstorm a wide volume of hazards, their outputs are often described as generic or lacking the depth of a subject‑matter expert [9]. Critically, the gap in operational experience (E), contextual understanding (C), and judgment (J) is not primarily an information deficit addressable by retrieval‑augmented generation or knowledge graphs: these dimensions are formed through sustained feedback loops between predictions and real‑world consequences, and whether they can be meaningfully approximated in AI systems remains an open research challenge distinct from the collaboration design problem this paper addresses.

C. Implications for AI‑Assisted Safety Engineering

The inability to rigorously benchmark AI‑generated safety analysis is not a temporary limitation of current tools but reflects the irreducible structure of safety competence itself. Yet teams are increasingly relying on LLMs to generate fault trees and populate FMEA tables, often without formal understanding of which competence dimensions the AI can and cannot contribute to. The resolution is not to qualify AI assistants in isolation but to design collaboration structures that deliberately match AI capabilities to task requirements along specific competence dimensions. This requires a formal model of how AI outputs interact with human reasoning, which we develop next.

The Competence Shadow

When an engineer reviews an AI‑generated hazard analysis, four mechanisms produce the competence shadow:

  1. Scope framing () – AI defines an implicit ontology of relevant failure modes.
  2. Attention allocation () – Human focuses on hazards highlighted by AI.
  3. Confidence asymmetry () – The human tends to trust AI‑provided hazards more than those they generate themselves.
  4. Time compression () – Limited time leads the human to accept AI suggestions without exhaustive verification.

These mechanisms are consistent with automation bias (Skitka et al. [18]) and have been confirmed across professional domains.

Collaboration Structures and Performance Bounds

We formalize four canonical collaboration structures that differ in information flow and active shadow mechanisms:

  • Serial Dependency () – AI produces an initial analysis . Human reviewers examine the full set before conducting their own review. All four shadow mechanisms are active.

  • Independent Analysis and Synthesis () – Each participant (human analysts and AI) works separately, then a lead analyst reconciles results. The three shadow mechanisms , , and are structurally eliminated; only time compression remains.

  • Tool Augmentation () – Humans perform core reasoning while AI handles auxiliary tasks (formatting, compliance cross‑referencing, template filling). No shadow mechanisms affect the core analysis; a small boundary error probability may cause a fraction of safety issues to be mis‑attributed.

  • Human‑Initiated Exploration () – Human creates an initial analysis , then asks AI to identify gaps, alternative propagation paths, or additional failure modes. Scope framing and attention allocation are eliminated; confidence asymmetry remains during the revision phase, and time compression applies to the initial manual effort.

Figure 2 illustrates the structural differences in information flow across all four structures.

![image](<COORD_081>, <COORD_146>, <COORD_489>, <COORD_276>)

Fig. 2. Four canonical human‑AI collaboration structures for AI‑assisted safety analysis, differing in information flow and active shadow mechanisms.

Serial Dependency

Serial Dependency () is the default structure in current practice. The effective anchoring coefficient under this structure combines scope framing, attention allocation, and confidence asymmetry:

[ \alpha_{\text{eff}} = \alpha_{\text{frame}} \cdot \beta \cdot \eta_{\text{disagree}} ]

(2)

This formulation captures the multiplicative effect of the shadow mechanisms on the final hazard identification quality.

Dimensions of Safety Engineering Competence (cont.)

このセクションで使用するパラメータは、実務上の妥当な中程度の影(shadow)状態を表すように選んだ例示的な値です。自動化バイアスに関する文献 [17]、[19]、[22] と、AI支援型知識作業で観測されたパターン [24] に一致しています。以下を仮定します。

  • スコープフレーミングによりアクセス可能な故障空間は全体の約 80 %)に縮小される。
  • レビュー作業の約 70 % が検証に充てられ、残り 30 % が独立した探索に使われる()。
  • エンジニアは AI と意見が合わなかった結果を約 70 % 持ち帰る()。
  • 時間圧縮により分析時間が 40 % 削減される()。

これらの値は安全工学の実務で直接測定されたものではありませんが、パラメータの範囲全体にわたって質的な結論は成立します。また、影(shadow)パラメータを標準化して測定する方法を開発することが、本フレームワークがコミュニティにもたらす最も重要な研究機会です(第 VI節)。代表的なパラメータを用いると、実効的アンカリング係数は

[ \alpha_{\text{eff}} = 0.168 ]

となり、影の影響を受けたレビュアーは時間圧縮前の独立した識別能力の 16.8 % のみを保持していることを意味します。


Theorem 1 (Serial Dependency with Compounding Shadow)

の下で、影が累積し、 人の独立した人間レビュアーがいるとき、期待される品質は

[ \mathbb{E}[Q(\pi_{1})] = q_{AI} + (1 - q_{AI}) \Bigl[ 1 - \bigl(1 - \alpha_{\text{eff}} , \gamma , q_{h}\bigr)^{k} \Bigr] \tag{3} ]

ここで は式 (2) で定義され、 は時間圧縮率です。

証明
問題 について:

  • AI が を特定する確率は 。この場合、人間は完全に検証できるので保持される(確率 1)。
  • AI が を見逃す確率は 。そのとき、各レビュアーは独立して

[ \alpha_{\text{eff}} , \gamma , q_{h} ]

の確率で を特定する(スコープフレーミング、注意配分、信頼度非対称性、時間圧縮後のベースライン能力を反映)。

少なくとも一人が を見つける確率は

[ P(s \text{ が特定される}\mid s \notin S_{AI}) = 1 - (1 - \alpha_{\text{eff}} , \gamma , q_{h})^{k}. ]

全確率の法則により、求める式が得られます。


Corollary 1 (Non‑Degradation Condition)

シリアル依存で単一レビュアーの場合、品質が人間ベースライン以上( )であるのは次の条件と同値です:

[ q_{AI} \ge \frac{q_{h}\bigl(1 - \alpha_{\text{eff}} , \gamma\bigr)}{1 - \alpha_{\text{eff}} , \gamma , q_{h}} \tag{4} ]

数値例
とすると、現実的な影の条件( )では

[ \mathbb{E}[Q(\pi_{1})] = 0.65 + 0.168 \times 0.6 \times 0.85 \times 0.35 = 0.68, ]

人間ベースラインから 20 % 減少した結果です。非劣化の閾値は を要求します。

図 3 が減衰構造を可視化しています(図省略)。


C. Independent Analysis: Eliminating the Shadow by Construction

独立分析 () では、解析フェーズ中に情報の流れを遮断し、影を構築的に除去します。Buçinca ら [34] の研究結果と合致し、認知的強制装置が AI への過度な依存を顕著に減少させることが示されています。

Theorem 2 (Independent Analysis Performance)

の下で、 人の人間レビュアー、AI 能力 、構造的相関 (共有盲点確率 )があるとき、期待される品質は

[ \mathbb{E}[Q(\pi_{2})] = 1 - \rho , q_{\text{shared}} - (1-\rho),(1-q_{h})^{k},(1-q_{AI}) \tag{5} ]

この構造は時間圧縮()にのみ影響を受け、通常は軽度の劣化()を示し、シリアル依存での と比較して管理側が適切な時間を確保しやすいことを示します。

数値例
の場合

[ \mathbb{E}[Q(\pi_{2})] = 1 - 0.12 - 0.7 \times (0.15)^{3} \times 0.35 \approx 0.88, ]

人間ベースラインを 3 ポイント 上回り、影が残ったシリアル依存()より 20 ポイント 高い結果です。


D. Tool Augmentation: Clean Decomposition

ツール拡張 () では、AI の作業領域を「影が生じにくい」タスクに限定します。重要な要件は、コアタスク()と補助タスク(主に )の境界が明確であることです。

Theorem 3 (Tool Augmentation Performance)

の下で、クリーンな分解があり、境界エラー確率 が問題の一部 を影響するとき、期待される品質は

[ \mathbb{E}[Q(\pi_{3})] = q_{h},\bigl(1 - \varepsilon , \delta\bigr) \tag{6} ]


の場合

[ \mathbb{E}[Q(\pi_{3})] = 0.85 \times (1 - 0.03 \times 0.5) = 0.85 \times 0.985 \approx 0.837, ]

ベースラインからわずか 1.5 % の劣化で、補助作業の時間を 30 % 短縮できます。分解が不完全になると( が 0.15 に上昇すると)品質は 0.80 まで低下します。


E. Human‑Initiated Exploration: Reversing the Information

人間主導の探索 () は、シリアル依存の効率性と独立分析のリソースコストの中間を埋める手法です。まず人間が初期解析を行い、その後 AI を活用することで、AI の出力に先んじて(アンカリング)する機会を作ります。

Recent work by Shentu and Trapp [8] では、生成型 AI コパイロットが人間主導の故障ツリーに対して新たなサブ原因を提案する例が示されています。これにより解析の発散的カバレッジが拡張されますが、本フレームワークは AI の提示が人間の初期システム分解にどれだけ依存しているか(逆アンカリング)で効果が制限されることを明らかにしています。

Theorem 4 (Human‑Initiated Exploration Performance)

の下で、人間ベースライン 、AI 能力 、逆アンカリング係数 、AI 提案受容率 があるとき、期待される品質は

[ \mathbb{E}[Q(\pi_{4})] = q_{h} + (1 - q_{h}) , \eta_{\text{accept}} , (1 - \rho_{\text{rev}}) , q_{AI} \tag{7} ]

ここで は人間の初期分析 が AI の探索をどれだけ制約するかを示す指標です。 のときは AI が自由に探索し、全く新しい故障モードも提示でき、 のときは人間の分解に完全に依存し、追加情報は提供しません。

証明
問題 について:

  • 人間がクリーンルーム段階で を特定する確率は 。この場合保持される。
  • 人間が を見逃す確率は 。そのとき AI が独立して提示できる確率は (逆アンカリングを考慮したベースライン能力)。人間が受容する確率は

全確率の法則により、求める式が得られます。

数値例
(中程度の逆アンカリング:人間の枠組みに部分的に依存しつつ、AI が独自の探索力を保持)、 の場合

[ \mathbb{E}[Q(\pi_{4})] = 0.85 + 0.15 \times 0.70 \times 0.70 \times 0.65 = 0.898, ]

人間ベースラインを 5 ポイント 上回り、シリアル依存()と独立分析()の中間に位置し、逆アンカリングが良好な条件下では に匹敵します。


Table II は一貫したパラメータ下での比較を示しています。

V. From Bounds to Practice

A. Structure Selection for Safety Teams

非劣化条件(補題 1)により、安全チームは構造選択の指針を得られます。シリアル依存は、AI の能力がその作業フローにおけるコンピテンス・シャドウの深刻さに応じて設定された閾値を超える場合にのみ、分析品質を維持します。中程度から強い影効果の場合、必要な AI 能力は現在の LLM が示すものよりもかなり高く、今日の多くの安全分析タスクではシリアル依存が品質を低下させる可能性が高いことを示唆しています。

実務的な対応は、構造をタスクに合わせることです。1つのプロジェクトには数十の異なる分析活動が含まれ、各活動は要求されるコンピテンス次元に応じて異なる構造を要します。重要な推奨事項は、安全ワークフローを活動レベルで分解し、構造を意図的に割り当てることです。プロジェクト全体に対して単一の協働パターンだけを使用するのではなく、この分解は設計上の決定であり、レビューに値します。なぜなら、「核心的推論」と「補助タスク」の境界が不適切だと、ツール拡張性能を低下させる意味的な漏れが生じるからです(定理 3)。

組織は時間圧縮のレバーを逆らう必要があります。AI が事前分析を数分で完了すると、管理側はスケジュールをさらにタイトにできる合理的な根拠を持ちますが、影効果が結果に見えにくいままになると、再びレバーが締め付けられます。非劣化条件は原則的な下限を提供します:形式的モデルは人間ベースラインを下回る品質になる最小の時間配分を示し、その配分を自由に交渉できるとみなすことは、安全上の重要な決定です。

B. Implications for Safety Assessment

独立した安全評価者は新たな課題に直面します。組織が認証審査のためにハザード分析を提出すると、評価者は単に分析が技術的に適切かどうかだけでなく、その作成プロセスが知的(epistemic)に妥当であったかも評価しなければなりません。2つの FMEA 表は紙面上では同一に見えても、実際には異なる認知的重みを持ちます。ある表は人間の徹底した推論と AI が作成したフォーマットで補強されたもの、もう一方はスコープフレーミングに基づいて AI が生成した故障モードを受容し、独立した探索を行わなかったものです。

出力だけを見ると、これらのシナリオは区別できません。評価者は次の 3 つの質問で影の影響を把握できます。

  1. どの構造が各分析活動を支配したか?
    構造は影の機構が有効だったことを決定し(表 II)、シリアル依存は独立分析と根本的に異なる認知的リスクを持ちます。

  2. AI の能力は非劣化閾値を満たしているか?
    シリアル依存を使用した場合、評価者は AI が類似タスクで示す性能が補題 1 の境界を超えているかどうかを尋ねるべきです。十分な AI 能力の証拠がないシリアル依存は、明示的に正当化すべきリスクです。

  3. 安全主張の認知的起源は何であるか?
    大半の故障モードが AI 生成コンテンツに遡り、人間による編集レビューのみで確定した場合、実効的な品質は (AI の性能)で上限され、 よりも低くなる可能性があります。


VI. DISCUSSION AND OPEN PROBLEMS

A. Challenged Assumptions

仮定 1:AI の能力だけで価値が決まる。
品質の差はシリアル依存と独立分析(表 II)で、協働構造だけが原因です。Dell’Acqua ら [24] の実地実験結果と一致し、同じ AI ツールが使用方法に応じて一部タスクでは性能を向上させ、他方のタスクでは低下させることが示されました。組織はモデルを改善する投資を行う一方で構造設計を無視すると、安全分析が逆に劣化する可能性があります。

仮定 2:効率化は無条件の利点である。
管理側が安全分析時間を 40 時間から 24 時間に短縮()すると、コンピテンス・シャドウが乗算的に増幅されます。その結果生じる品質低下は出力だけでは見えにくく、さらにスケジュールをタイトにする誘惑があります。安全かつ持続可能な計算システムの構築へとコミュニティが進む中で、ここから導かれた非劣化境界は形式的な根拠を提供します:影に強い独立分析()のような構造がない場合、現在の能力重視研究 [7], [9], [11] が約束する効率化効果は見えないコンピテンス・シャドウにより相殺される可能性があります。

仮定 3:ツール資格認証フレームワークは AI アシスタントに対して十分である。
既存の規格や ISO/IEC TS 22440-1 Annex C [27] のような新しい取り組みでは、AI を「正しい」または「誤り」と出力し、人がそのエラーを捕えることができるかを問います。我々の枠組みは、より深い問題が存在することを示しています:最も危険な失敗モードは、AI の出力が正しく見える(correct‑looking)だけで、人間の認知にコンピテンス・シャドウを投げかけることです。AI が生成したハザードリストが妥当に見えても不完全である場合、現在の定義では「故障」していないとみなされますが、レビュー担当者の欠落項目を見つける能力を体系的に低下させます。さらに根本的には、現行のフレームワークは協働構造という概念が不足しており、AI が生成し人間がレビューするという単一フローを暗黙の前提としていますが、構造が異なると品質結果が大きく変化することに気付いていません。

B. Open Problems

影パラメータの推定。
モデルでは , , , を既知のパラメータとして扱いますが、測定する標準化された手法はまだ確立されていません。本稿は理論的枠組みと形式的構造を提供しましたが、実証的なキャリブレーションが次の重要なステップです。安全エンジニアが各構造条件下でハザード分析を行い、労力配分、保持率、独立した発見率を直接測定する制御研究を求めます。

動的な影の変化。
影パラメータを静的と見なしていますが、実際の運用では学習が伴います。私たちは U 字型のダイナミクスを予想します:新規性から始まる強い影、続いてエンジニアがメタ認知的な意識を高めることで補償し、最終的に complacency(過信)へと移行する可能性があります。これらの動的変化を形式化するには、学習パラメータを持つ複数期間モデルが必要です。


VII. CONCLUSION: TOWARD HUMAN‑CENTRIC SAFETY INTELLIGENCE

安全エンジニアが LLM が生成した故障ツリーをレビューする際、単に「AI の作業をチェック」するだけでなく、AI のフレーミングによって形作られた認知環境の中で作業しています。その中で

独立した判断は、意識的に抵抗できない仕組みを通じて体系的に抑制されます。

私たちは Human‑Centric Safety Intelligence を提唱します:人間の不可欠な専門知識を保持し、さらに増幅させる協働構造の中で AI の能力を統合することです。LLM は標準化が重視され、文書作成が中心となるタスクで真に優れています。誤りは、AI を導入する際に、結果として生まれる人間‑AI システムの認知構造を理解せずに使用することです。

ソフトウェア工学では HumanEval [1]、MBPP [28]、SWE‑bench [35] が AI 能力を測定します。安全工学には同等の指標がまだありません。これらの基盤を拡張するためには、調整された研究プログラムが必要です。以下のことを呼びかけます:

  1. 指定した構造条件下で人間‑AI システムが何を見つけられるかを測る、構造に敏感な評価ベンチマーク
  2. 組織が実稼働ワークフローから匿名化された影パラメータの測定値を提供する 影パラメータデータベース
  3. エンジニアが影への耐性や complacency をどのように発展させるかを追跡する 長期的なフィールドスタディ
  4. ツール資格認証フレームワークを拡張し、協働構造の分類、影のダイナミクス、そして構造リスクに合わせた文書化要件に対応させる。

今後 10 年間で数百万台ものロボット、車両、医療機器が導入されます。それらのシステムが本当に安全であるかどうかは、現在行われている選択にかかっています。安全上の AI アシスタンスは実現可能ですが、単に能力が高いモデルだけでなく、影に強い協働構造を整えることが必要です。


REFERENCES

[1] M. Chen, J. Torek, H. Jun et al., “Evaluating large language models trained on code,” arXiv preprint arXiv:2107.03374, 2021.

[2] S. Peng, E. Kalliamvakou, P. Cihon, and M. Demirer, “The impact of AI on developer productivity: Evidence from GitHub Copilot,” arXiv preprint arXiv:2302.06590, 2023.

[3] International Organization for Standardization, “ISO 13482: Robots and robotic devices – safety requirements for personal care robots,” ISO. Standard, 2014.

[4] ——, “ISO 12100: Safety of machinery – general principles for design – risk assessment and risk reduction,” ISO, Standard, 2010, second edition.

[5] International Electrotechnical Commission, “IEC 61508: Functional safety of electrical/programmable electronic safety-related systems,” IEC, Standard, 2010, second edition.

[6] International Organization for Standardization, “ISO 13849‑1: Safety of machinery – safety‑related parts of control systems – part 1: General principles for design,” ISO, Standard, 2023, fourth edition.

[7] S. Shetiya et al., “Fault tree analysis generation using GenAI with an autonomy sensor usecase,” SAE International Journal of Connected and Automated Vehicles, 2026.

[8] Y. Shentu and M. Trapp, “Facilitating fault tree analysis with generative AI,” in Computer Safety, Reliability, and Security. SAFECOMP 2025 Workshops, ser. Lecture Notes in Computer Science, M. Törgren, B. Gallina, E. Schoitsch, E. Troubitsyna, and F. Bitsch, Eds. Cham: Springer Nature Switzerland, 2026, pp. 524–536.

[9] I. El Hassani et al., “AI‑driven FMEA: Integration of LLMs for faster and more accurate risk analysis,” Design Science, 2025.

[10] R. Singh et al., “Application of LLM for failure modes and effects analysis (FMEA),” in Proceedings, Springer, 2025.

[11] E. Elhosary, “Utilization of artificial intelligence in HAZOP studies and reports,” in Proceedings of the International Symposium on Automation and Robotics in Construction (ISARC), 2025.

[12] S. Diemert and J. H. Weber, “Can large language models assist in hazard analysis?” arXiv preprint arXiv:2303.15473, 2023.

[13] Z. A. Collier et al., “How good are large language models at product risk assessment?” Risk Analysis, 2025.

[14] S. Qi et al., “Can large language models automate the HAZOP process without human intervention?” Safety Science, 2025.

[15] A. Bharadwaj et al., “From hallucinations to hazards: Benchmarking LLMs for hazard analysis in safety‑critical systems,” Safety Science, 2025.

[16] S. Charalampidou, I. Petroulias, and I. M. Dokas, “Hazard analysis in the era of AI: Assessing the usefulness of ChatGPT4 in STPA hazard analysis,” Safety Science, vol. 180, p. 106666, 2024.

[17] R. Parasuraman and D. H. Manzey, “Complacency and bias in human use of automation: An attentional integration,” Human Factors, vol. 52, no. 3, pp. 381–410, 2010.

[18] L. J. Skitka, K. L. Mosier, and M. Burdick, “Does automation bias decision‑making?” International Journal of Human‑Computer Studies, vol. 51, no. 5, pp. 991–1006, 1999.

[19] K. Goddard, A. Roudsari, and J. C. Wyatt, “Automation bias: A systematic review of frequency, effect mediators, and mitigators,” Journal of the American Medical Informatics Association, vol. 19, no. 1, pp. 121–127, 2012.

[20] A. Tversky and D. Kahneman, “Judgment under uncertainty: Heuristics and biases,” Science, vol. 185, no. 4157, pp. 1124–1131, 1974.

[21] G. Romeo and D. Conti, “Exploring automation bias in human‑AI collaboration: A review and implications for explainable AI,” AI & Society, 2025.

[22] M. C. Horowitz and L. Kahn, “Bending the automation bias curve: A study of human and AI‑based decision making in national security contexts,” International Studies Quarterly, vol. 68, no. 2, p. sqae020, 2024.

[23] G. Bansal, B. Nushi, E. Kamar, W. S. Lasecki, D. S. Weld, and E. Horvitz, “Beyond accuracy: The role of mental models in human‑AI team performance,” Proceedings of the AAAI Conference on Human Computation and Crowdsourcing, vol. 7, pp. 2–11, 2019.

[24] F. Dell’Acqua, E. McFowland III, E. R. Mollick, H. Lifshitz‑Assaf, K. C. Kellogg, S. Rajendran, L. Krayer, F. Candelon, and K. R. Lakhani, “Navigating the jagged technological frontier: Field experimental evidence of the effects of AI on knowledge worker productivity and quality,” Harvard Business School Technology & Operations Mgt. Unit Working Paper No. 24‑013, 2023.

[25] Z. Chen, Y. Luo, and M. Sra, “Engaging with AI: How interface design shapes human‑AI collaboration in high‑stakes decision‑making,” arXiv preprint arXiv:2501.16627, 2025.

[26] C. Gao et al., “Human‑AI collaboration is not very collaborative yet: A taxonomy of interaction patterns in AI‑assisted decision making from a systematic review,” Frontiers in Computer Science, vol. 6, p. 1521066, 2024.

[27] International Organization for Standardization and International Electrotechnical Commission, “ISO/IEC CD TS 22440‑1: Safety of machinery and autonomous systems – part 1: Safety requirements for AI‑based systems,” ISO/IEC JTC 1/SC 42 and ISO/TC 22/SC 32/WG 14, Committee Draft, 2026, Annex C: AI‑based Software Tools.

[28] J. Austin, A. Odera, M. Nye et al., “Program synthesis with large language models,” arXiv preprint arXiv:2108.07732, 2021.

[29] International Organization for Standardization, “ISO 26262: Road vehicles – functional safety,” ISO, Standard, 2018, second edition.

[30] U. Siddique, “SafetyOps,” arXiv preprint arXiv:2008.04461, 2020.

[31] C. Cárdenas, D. Ratiu, and M. Wagner, “Safety factories – a manifesto,” in Proc. 44th Int. Conf. on Computer Safety, Reliability and Security (SAFECOMP), 2025.

[32] B. Green and Y. Chen, “The principles and limits of algorithm‑in‑the‑loop decision making,” Proceedings of the ACM on Human‑Computer Interaction, vol. 3, no. CSCW, pp. 1–24, 2019.

[33] L. Shin et al., “Aegis: An advanced LLM‑based multi‑agent for intelligent functional safety engineering,” in Proceedings of the 2024 Conference on Empirical Methods in Natural Language Processing (EMNLP), 2024.


TABLE II

Four‑structure comparison (, )

指標シリアル依存 (Serial)独立分析 (Indep.)ツール拡張 (Tool Aug.)HIE
期待される品質68 %88 %84 %90 %
ベースラインとの差分(Δ)-17 ポイント+3 ポイント-1 ポイント+5 ポイント
影の機構が有効な数4/41/4ε のみ1/4

REFERENCES

[1] M. Chen, J. Torek, H. Jun et al., “Evaluating large language models trained on code,” arXiv preprint arXiv:2107.03374, 2021.

[2] S. Peng, E. Kalliamvakou, P. Cihon, and M. Demirer, “The impact of AI on developer productivity: Evidence from GitHub Copilot,” arXiv preprint arXiv:2302.06590, 2023.

[3] International Organization for Standardization, “ISO 13482: Robots and robotic devices – safety requirements for personal care robots,” ISO. Standard, 2014.

[4] ——, “ISO 12100: Safety of machinery – general principles for design – risk assessment and risk reduction,” ISO, Standard, 2010, second edition.

[5] International Electrotechnical Commission, “IEC 61508: Functional safety of electrical/programmable electronic safety-related systems,” IEC, Standard, 2010, second edition.

[6] International Organization for Standardization, “ISO 13849‑1: Safety of machinery – safety‑related parts of control systems – part 1: General principles for design,” ISO, Standard, 2023, fourth edition.

[7] S. Shetiya et al., “Fault tree analysis generation using GenAI with an autonomy sensor usecase,” SAE International Journal of Connected and Automated Vehicles, 2026.

[8] Y. Shentu and M. Trapp, “Facilitating fault tree analysis with generative AI,” in Computer Safety, Reliability, and Security. SAFECOMP 2025 Workshops, ser. Lecture Notes in Computer Science, M. Törgren, B. Gallina, E. Schoitsch, E. Troubitsyna, and F. Bitsch, Eds. Cham: Springer Nature Switzerland, 2026, pp. 524–536.

[9] I. El Hassani et al., “AI‑driven FMEA: Integration of LLMs for faster and more accurate risk analysis,” Design Science, 2025.

[10] R. Singh et al., “Application of LLM for failure modes and effects analysis (FMEA),” in Proceedings, Springer, 2025.

[11] E. Elhosary, “Utilization of artificial intelligence in HAZOP studies and reports,” in Proceedings of the International Symposium on Automation and Robotics in Construction (ISARC), 2025.

[12] S. Diemert and J. H. Weber, “Can large language models assist in hazard analysis?” arXiv preprint arXiv:2303.15473, 2023.

[13] Z. A. Collier et al., “How good are large language models at product risk assessment?” Risk Analysis, 2025.

[14] S. Qi et al., “Can large language models automate the HAZOP process without human intervention?” Safety Science, 2025.

[15] A. Bharadwaj et al., “From hallucinations to hazards: Benchmarking LLMs for hazard analysis in safety‑critical systems,” Safety Science, 2025.

[16] S. Charalampidou, I. Petroulias, and I. M. Dokas, “Hazard analysis in the era of AI: Assessing the usefulness of ChatGPT4 in STPA hazard analysis,” Safety Science, vol. 180, p. 106666, 2024.

[17] R. Parasuraman and D. H. Manzey, “Complacency and bias in human use of automation: An attentional integration,” Human Factors, vol. 52, no. 3, pp. 381–410, 2010.

[18] L. J. Skitka, K. L. Mosier, and M. Burdick, “Does automation bias decision‑making?” International Journal of Human‑Computer Studies, vol. 51, no. 5, pp. 991–1006, 1999.

[19] K. Goddard, A. Roudsari, and J. C. Wyatt, “Automation bias: A systematic review of frequency, effect mediators, and mitigators,” Journal of the American Medical Informatics Association, vol. 19, no. 1, pp. 121–127, 2012.

[20] A. Tversky and D. Kahneman, “Judgment under uncertainty: Heuristics and biases,” Science, vol. 185, no. 4157, pp. 1124–1131, 1974.

[21] G. Romeo and D. Conti, “Exploring automation bias in human‑AI collaboration: A review and implications for explainable AI,” AI & Society, 2025.

[22] M. C. Horowitz and L. Kahn, “Bending the automation bias curve: A study of human and AI‑based decision making in national security contexts,” International Studies Quarterly, vol. 68, no. 2, p. sqae020, 2024.

[23] G. Bansal, B. Nushi, E. Kamar, W. S. Lasecki, D. S. Weld, and E. Horvitz, “Beyond accuracy: The role of mental models in human‑AI team performance,” Proceedings of the AAAI Conference on Human Computation and Crowdsourcing, vol. 7, pp. 2–11, 2019.

[24] F. Dell’Acqua, E. McFowland III, E. R. Mollick, H. Lifshitz‑Assaf, K. C. Kellogg, S. Rajendran, L. Krayer, F. Candelon, and K. R. Lakhani, “Navigating the jagged technological frontier: Field experimental evidence of the effects of AI on knowledge worker productivity and quality,” Harvard Business School Technology & Operations Mgt. Unit Working Paper No. 24‑013, 2023.

[25] Z. Chen, Y. Luo, and M. Sra, “Engaging with AI: How interface design shapes human‑AI collaboration in high‑stakes decision‑making,” arXiv preprint arXiv:2501.16627, 2025.

[26] C. Gao et al., “Human‑AI collaboration is not very collaborative yet: A taxonomy of interaction patterns in AI‑assisted decision making from a systematic review,” Frontiers in Computer Science, vol. 6, p. 1521066, 2024.

[27] International Organization for Standardization and International Electrotechnical Commission, “ISO/IEC CD TS 22440‑1: Safety of machinery and autonomous systems – part 1: Safety requirements for AI‑based systems,” ISO/IEC JTC 1/SC 42 and ISO/TC 22/SC 32/WG 14, Committee Draft, 2026, Annex C: AI‑based Software Tools.

[28] J. Austin, A. Odera, M. Nye et al., “Program synthesis with large language models,” arXiv preprint arXiv:2108.07732, 2021.

[29] International Organization for Standardization, “ISO 26262: Road vehicles – functional safety,” ISO, Standard, 2018, second edition.

[30] U. Siddique, “SafetyOps,” arXiv preprint arXiv:2008.04461, 2020.

[31] C. Cárdenas, D. Ratiu, and M. Wagner, “Safety factories – a manifesto,” in Proc. 44th Int. Conf. on Computer Safety, Reliability and Security (SAFECOMP), 2025.

[32] B. Green and Y. Chen, “The principles and limits of algorithm‑in‑the‑loop decision making,” Proceedings of the ACM on Human‑Computer Interaction, vol. 3, no. CSCW, pp. 1–24, 2019.

[33] L. Shin et al., “Aegis: An advanced LLM‑based multi‑agent for intelligent functional safety engineering,” in Proceedings of the 2024 Conference on Empirical Methods in Natural Language Processing (EMNLP), 2024.

TABLE II (cont.)

[34] Z. Bucinca, M. B. Malaya, and K. Z. Gajos, “信頼するか、考えるか:認知的強制機能は AI 補助の意思決定における AI への過度な依存を軽減できる”, Proceedings of the ACM on Human-Computer Interaction, vol. 5, no. CSCW1, pp. 1–21, 2021.

[35] C. E. Jimenez, J. Yang, A. Wettig, S. Yao, K. Pei, O. Press, and K. Narasimhan, “SWE‑bench: ラングエッジモデルは実世界の GitHub 問題を解決できるか?”, arXiv preprint arXiv:2310.06770, 2023.