> [!abstract] 概要(Abstract 日本語訳) > ソフトウェアエンジニアリングは、コード・フィールドデータ・社会技術的プロセスからのシグナルを使い、不確実性下での高リスクな意思決定をますます伴うようになっている。近年のAI駆動支援(例:異常検知、予測分析、AIOps、LLMベースのエージェント)は、エンジニアがパターンを検知しコンテンツや推奨を合成する能力を増幅してきたが、多くの重要な問いは介入的(interventional)あるいは反実仮想的(counterfactual)である。負荷分散戦略を変更した場合の期待される影響は何か? 別のリリース計画であれば障害は回避できたか? 相関モデルは「何が何と共起する傾向があるか」には答えられるが、「行動を起こしたら何が起きるか」には答えるのが難しい。 > 我々はCausal Software Engineering(CSE)を、因果モデルと因果推論がソフトウェアライフサイクル全体の活動に体系的に情報を与える将来のパラダイムとして提案する。CSEは既存の実践を、明示的な前提・不確実性を考慮した効果推定・反実仮想診断で拡張する。本稿では、(i) 開発と運用にまたがる因果ファーストのワークフロー観、(ii) ツールと組織的採用のための段階的ロードマップ、(iii) 進捗を測定するための評価・ベンチマークの課題設定、の3つを概説する。 ## 論文情報 - タイトル: Causal Software Engineering: A Vision and Roadmap - 著者: Roberto Pietrantuono・[[Luca Giamattei]]・[[Stefano Russo]](いずれも[[University of Naples Federico II]])、[[Julien Siebert]]([[Fraunhofer IESE]])、[[Neil Walkinshaw]]([[University of Sheffield]]) - 媒体: 34th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering(FSE Companion '26)、2026年7月5〜9日、モントリオール、カナダ - DOI: 10.1145/3803437.3805585 / ACM ISBN: 979-8-4007-2636-1/26/07 - ページ数: 5ページ(pp. 1346–1350) - ライセンス: Creative Commons Attribution 4.0 International License - 謝辞: DIETI COSMICプロジェクトの助成を受けた研究 ## 概要 本論文はビジョン・ロードマップ論文であり、実証実験は行っていない。現在のSEツール(異常検知・AIOps・LLMエージェント)が相関ベースの推論に留まっており、「介入したら何が起きるか」「別の行動をとっていたらどうだったか」という因果的な問いに答えられない、という課題認識から出発する。著者らはCausal Software Engineering(CSE)という新パラダイムを提唱し、SEにおける変更(コード・設定・デプロイ・是正措置)を明示的な因果的介入として扱う。CSEは既存のSE実践を置き換えるのではなく、明示的な前提・不確実性つきの因果効果推定・反実仮想診断で拡張するものと位置づけられる。論文はCauseal Readiness Level(CRL)という段階的な組織・ツール成熟度モデルに沿った4つのルート(因果的可観測性・介入可能性・反実仮想的保証・ガバナンス)のロードマップと、進捗測定のための評価計画を提示する。(Source: Abstract, §1, §5) ## 問題設定 入力は、ソフトウェアシステムの運用・開発から得られるメトリクス・ログ・トレース・依存関係・開発アーティファクトなどの多様なシグナルである。出力として期待されるのは、単なる相関的な検知・説明ではなく、「$X$に介入したら$Y$はどう変化するか($P(Y|do(X=x))$)」という介入的分布の推定と、「別の$x$のもとでは何が起きていたか」という反実仮想の評価である。前提条件として、変数間の因果構造(有向非巡回グラフなど)、交絡因子(confounder)の候補、識別可能性条件(何を測定すべきか・何が同時に変化してはいけないか)を明示的に指定できることが必要になる(Source: §1, §2)。 **動機付け事例(running example)**: マイクロサービスチームがテールレイテンシ削減のためクライアント側リトライポリシーを導入しリリースした。1時間後にレイテンシが低下し、AIOpsダッシュボードはこの改善をデプロイに帰属させ、「変更がレイテンシを改善した」と示唆した。オンコールエンジニアは同じパターンを他サービスにも適用しようとする。しかし同じ時間帯に、下流依存サービスでの別のオートスケーリング調整(レプリカ増加)と、あるリージョンからのトラフィックシフトも同時に発生しており、これらもキューイング遅延を減らしうる要因だった。改善の原因はリトライポリシー変更・スケーリング変更・トラフィックシフト・それらの相互作用のいずれかであり、曖昧である。同じロールアウトを同じスケーリング条件なしで再度行うと、テールレイテンシが悪化しインシデントが発生した。これは、元の因果的な要因を誤って特定していたためである(Source: §1)。 ## 提案手法 ### CSEの基本的な考え方 CSEでは、上記のリリースをdo演算子で示される介入($do(X=x)$)として扱い、並行して発生したオートスケーリング変更やトラフィック/リージョン構成の変化を、レイテンシに影響し変更と共変動しうる交絡因子($Z$)として介入ログに記録する。CSEエンジニア(またはツール)は、時間帯・キャッシュのウォームアップ・並行する構成変更などの他の交絡因子も調整したうえで、$Z$を調整した$X$の因果効果を推定する。交絡から自由な因果効果を不確実性つきで推定することで、システムは意思決定に足るレディネス(decision-ready)な推定値を報告し、次の具体的なステップ(ロールアウト継続/カナリア割合の増加、改善が真だが小さい場合はさらなるチューニングを避ける、特定要因が原因ならその要因を狙って対処する)を推奨する(Source: §1)。 ### 因果モデルとは何か(SE文脈での定義) 因果モデルは、関連する要因が互いにどのように因果的に影響し合うかをコンパクトに表現するものである。CSEはタスク固有のモデルを具体的な意思決定に紐付けて使う(例:「このリリースはp99レイテンシを削減したか」「どの設定変更がリグレッションを引き起こしたか」)。便利な形式の一つが有向非巡回グラフであり、ノードは観測可能または制御可能な変数(リリースバージョン、リトライポリシー、レプリカ数、キャッシュウォームアップ、リージョンミックス)、エッジは仮説化された因果関係を表し、データでパラメータ化された式がその強さを定量化する。モデルはドメイン知識・要件・設計文書から専門家が定義する、あるいは他のMLモデルと同様にデータから学習する、あるいはハイブリッドアプローチ([19])で構築することができる(Source: §2)。 ### 「明示的な前提」が既存手法と異なる理由 すべての予測ツールは前提に依存するが、多くは暗黙的なままである。どの変数が重要か、どれが単に相関しているだけか、どの隠れた要因が偽の結論を生みうるかといった点だ。CSEはこれらを明示化・レビュー可能にする。具体的には次の3つを扱う。 - **潜在的な交絡因子**: モデラーが、トラフィック/リージョンミックスやオートスケーリング変更が緩和策のデプロイの可能性と観測レイテンシの両方に影響しうると指定し、この調整のもとで効果を推定し安定性を検定する。 - **許可/禁止される因果リンク**: モデラーが $Latency \to Deployed\_Version$ という弧を禁止する(レイテンシスパイクがデプロイされるバージョンを変えることはない)、あるいは $Region\_Mix \to Latency$ を要求する(トラフィック構成がレイテンシに影響する)ことができ、因果分析はこれらの事前知識と整合するモデルに制約される。 - **因果的主張がいつ正当化されるか**: モデルは、効果推定が識別可能であるために何を測定しなければならないか(そして何を同時に変化させてはならないか)を明示する。 前提を外部化することで、CSEはエンジニアがコードレビューやADR・ランブックのレビューと同様に、前提を検査・異議申し立て・修正・エンコードできるようにする。ブラックボックスな相関と異なり、前提が成立しない場合、CSEはどの前提が破れたかを表面化する(仮説化した交絡因子が介入とともに変化した、禁止/必須のリンクが矛盾した、識別条件が満たされなかった、など)(Source: §2)。 ### ライフサイクル横断の因果ワークフロー(3種のCSEアーティファクト) この構想を実現するため、著者らは既存パイプラインに組み込める軽量なCSEアーティファクトを提案する。 1. **Causal design spec(因果設計仕様)**: 要件・設計・ADRに添付される小さくバージョン管理された因果的前提であり、(i) 主要な変数とアウトカム、(ii) 交絡因子の候補、(iii) 許容される介入、を捕捉する。例:決定=クライアント側リトライポリシー($X$)を有効化してエラー率を増やさずにテールレイテンシ($Y$)を削減する。交絡因子=オートスケーリングイベントとレプリカ数、トラフィック/リージョンミックス、リクエストレートと負荷、時間帯、並行する設定変更(タイムアウト、サーキットブレーカーなど)。許容される介入=フィーチャーフラグでリトライポリシーを切り替える、リトライ回数とバックオフを調整する、以前のポリシーに戻す。 2. **Intervention log(介入ログ)**: 変更(デプロイ、フィーチャートグル、是正措置)の構造化された記録で、意図された因果的アウトカム・コンテキスト・不確実性を伴い、CI/CDのアクションを運用上の現実(何が変わったか、いつ、どこで、他に何が変わったか、どのアウトカムが動くべきか)に接続する。例:リリースv2.3が eu-west で 10% のカナリアに対し `retry_policy=v2` を有効化した(介入)。同じ時間帯に下流サービスがレプリカ数を20から40にスケールし、トラフィックの12%が eu-west から移動した(交絡因子)。目的:エラー率を増やさずp99レイテンシを10%削減。 3. **Living Causal Model(生きた因果モデル)**: 設計仕様が因果構造を定義し、ランタイムモデルがそれをライブテレメトリ(可能な場合は実験データも含む)でインスタンス化し、最新の効果推定と不確実性を維持する。生きたモデルは部分的でよく、サービス境界・SLO・インシデントクラスに焦点を当ててよい。役割は介入下での意思決定支援であり、what-ifクエリと反実仮想診断を不確実性・反証チェックとともに提供する。 表1は、SEライフサイクル全体でどのように因果的な問いが生じるかを示す。各段階は軽量なアーティファクト(spec/log/生きたモデルの更新)を生成し、コードと同様にレビュー・バージョン管理・監査ができる。 **Table 1: Examples of causal questions across the lifecycle and their primary CSE artifact.** | Stage(段階) | Causal question(因果的な問いの例) | Output(CSEアーティファクト) | |---|---|---| | Requirements | ポリシー$X$(例:ランキングアルゴリズム)を変更した場合、ユーザーへの害や公平性$Y$への効果は? | Causal design spec(アウトカム・交絡因子・許容される介入) | | Architecture | サービス$A$を分割する、または同期/非同期トポロジーを変更した場合、テールレイテンシとインシデント率への効果は? | Causal design spec(アーキテクチャ介入、因果的前提) | | Testing | どのシナリオ介入が安全性クリティカルな障害の発見を最大化するか。どの要因が真に違反を引き起こすか? | Live causal model(要因モデルと不確実性) | | Debugging | 設定$X$が異なっていたら障害は発生していたか? | Live causal model(反実仮想RCAレポート) | | Operations | どの是正措置が改善を引き起こしたのか、それとも単なる相関的な回復ノイズか? | Intervention log(不確実性つきの効果推定) | (Table 1, Source: §2) ## 新規性 既存の相関ベースの手法(異常検知、予測分析、AIOps、LLMベースのエージェントを含む多くの今日のMLシステム)は大規模で洗練されていても、パターン学習を超えた構造を本質的に欠いており、単独では因果推論を行わない。CSEの核となる新規性は、SEの問いを因果的に定式化すること――何が介入で、何のアウトカムが影響を受け、効果を識別するために何の前提が必要か――にある。これは、事後的な相関ハンティングから、明示的な前提・定量化された不確実性・監査可能な因果的主張を伴う「介入を意識した意思決定」へとエンジニアを移行させることを目指す。著者らはこれを、既存のソフトウェアテストの学術的ロードマップ(Bertolino et al. [2]の"achievements–challenges–dreams"構造)に着想を得た形式で提示しており、単発の技術提案ではなく、分野横断的な研究アジェンダとして新規性を主張している(Source: §2, §3)。 ## ロードマップ(4ルート・Causal Readiness Level) 論文はソフトウェアテストのロードマップ論文([2])の"achievements–challenges–dreams"構造に着想を得て、(i) 既にあるもの(achievements)、(ii) 進捗を可能にする中心的課題(challenges)、(iii) 漸近的な目標としての長期的な「夢」(dreams)、を整理する。4つのルートに沿って課題が構成され、CSEへの進捗はCausal Readiness Level(CRL)を登ることとして解釈される。 **Figure 1: 4つの共進化するルートに沿ったCSEのロードマップと Causal Readiness Level(CRL)** ![[_attachments/2026_Unknown_Causal_Software_Engineering_Vision_Roadmap/fig01-roadmap-crl.png]] (Figure 1. 上段は4ルート(因果的可観測性・介入可能性・反実仮想的保証・ガバナンス&アラインメント)それぞれについて、既にある達成事項・研究課題・漸近的な夢を3列で示す。下段はCRL-0(相関ベース)からCRL-5(因果的認証)までの6段階のCausal Readiness Levelを示す。Source: Figure 1) - **Route 1(R1): 因果的可観測性(CRL-1: observe)**: 従来のオブザーバビリティを、明示的な因果構造でシグナル(メトリクス・ログ・トレース・依存関係・開発アーティファクト)を拡張することで拡張する。障害箇所特定・根本原因分析([3, 11, 13])、アーキテクチャ/設計上の意思決定・プロセス・品質トレードオフのモデリング([5, 12])はすでに因果グラフや依存モデルを構築しているが、多くは事後的なランキング(根本原因など)に使われ、システム進化のもとで不安定になりうる([10])。主な課題は、監視データ上の交絡因子を意識したモデル、アーティファクトからの因果的変数エンジニアリング、進化・ドリフトのもとで安定な因果グラフである。これが満たされれば「因果的説明」――明示的な因果構造に基づく信頼できるwhy/what-if回答――が可能になる。 - **Route 2(R2): 設計による介入可能性(CRL-2: intervene)**: チームはすでにCI/CD・フィーチャーフラグ・カナリア・段階的ロールアウト・迅速なロールバックといった強力な変更管理メカニズムを持ち、本番環境での介入を実行可能にしているが、これらを明示的な因果的介入として枠付けることは稀である。因果分析は依然として事後的であることが多く([8, 18])、変更が出荷されメトリクスが動き、影響は変動する負荷・トラフィックミックス・容量のもとで事後的に帰属される。主な課題は、安全な実験と識別(カナリア/ABや準実験デザインの設計)、不確実性の許容(go/no-go判断への不確実性の伝播、例:「エラー率増加の上限がSLO予算内であるときのみ昇格」)、設定/デプロイ変更の因果的影響である。これが満たされれば、性能・信頼性・コストを不確実性つきで最適化する「介入計画」が可能になる。 - **Route 3(R3): 反実仮想的保証(CRL-3: explain & assure)**: エンジニアはすでにデバッグ・回帰分析・コミット二分探索(`git bisect`など)・ポストモーテムで反実仮想的推論を使っており、研究側でも反実仮想を利用したプログラム分析・テスト手法が存在する([1, 4, 7, 14])。しかしこれらの手法はしばしば局所的(単一コンポーネント/実行)または定性的であり、分散した進化するシステムにはめったにスケールしない。主な課題は、大規模での反実仮想RCA(トレース・トポロジー・介入履歴を用いて代替行動を評価)、介入設計としての因果的テスト(障害を暴露またはカバレッジを最大化するよう因果的要因を変化させる)、標準的な反証チェック(プラセボ、調整セットへの感度、リリース間の安定性([17]))である。これが満たされれば「この代替のもとで何が起きていたか」への裏付けのある回答に導かれる予防計画である「反実仮想エンジニアリング」が可能になる。 - **Route 4(R4): ガバナンスとアラインメント(CRL-4/5: justify & certify)**: 組織はすでにセーフティケース・コンプライアンス・監査・モデルリスク管理といったガバナンス上の要求に直面しているが、継続的な変化のもとで、保証の議論はしばしばチェックリスト・相関的証拠・介入的または反実仮想的主張を直接裏付けない狭いスコープのテストに依存している。R4は、因果推論を保証と説明責任のために使えるものにする。安全性/公平性のための監査可能な因果的主張(前提・証拠・不確実性がステークホルダー/規制当局によりレビュー可能)、人間参加型の因果モデリング(必須/禁止リンクの宣言・修正、主張の正当化の検査)、因果的に制約されたLLMエージェント(識別に失敗した場合に過大主張を避け、許容される介入を尊重する行動/説明)である。これが満たされれば、因果的前提・不確実性・監査要件に基づく統治されたアシスタントである「因果的コパイロット(causal copilots)」に到達する。 ### 近い将来の研究の賭け(次の3〜5年、各ルートに対応) - (R1) SEアーティファクトからの因果的変数とモデルの抽出(ログ・トレース・設定・コード・自然言語アーティファクトから候補変数と因果関係を抽出。非構造化データからの因果学習の初期の試みが存在する[15])。 - (R1) 進化のもとでの識別:リリースをまたぎ環境が変化しても有効なバージョン対応の識別・転移可能性(transportability)手法の開発。 - (R2) 安全な介入:効果推定を段階的リリース(カナリア/ABテスト)に結び付け、不確実性を考慮したガードレール(最悪ケースの影響が許容できない場合に停止/ロールバック)を強制する。 - (R3) 大規模での反実仮想RCA:因果モデルを分散トレースと介入履歴と組み合わせ、反実仮想的なインシデントクエリに答え代替説明を定量化する。 - (R3) 因果的テストと保証:テスト生成を介入設計として扱い、感度/反証チェックを日常的なものにして脆い因果的主張を避ける。 - (R4) エンジニアのための因果的コパイロット:LLMエージェントを因果モデルとコンテキスト・制約として結合し、生成される仮説と行動が因果的に妥当で不確実性を考慮したものであることを保証する。 ## 評価計画(実験ではなく将来のベンチマークアジェンダ) 本論文は特定の定量実験を実施した論文ではなく、CSEの進捗を測定するための評価計画を将来課題として提案している。異なるアプローチを共通の土台で比較できるよう、共有の評価目標が必要だとし、3つのベンチマークファミリーを提案する。 - **Intervention-effectベンチマーク**(「$X$を行ったことで何が変わったか」): 既知の変更(キャッシング、タイムアウト、リリースなど)と正解の影響(制御実験・リプレイ・人手ラベルから)を含むキュレートされたデータセット。手法が因果効果を推定できるか、不確実性が適切に較正されているか(自信を持つのは正当な場合のみか)を検証する。 - **Counterfactual incidentベンチマーク**(「別の行動をとっていたら何が起きていたか」): バージョン管理されたトレース/ログ、介入タイムライン(デプロイ・ロールバック・是正措置)、アウトカムを含むインシデントデータセット。反実仮想RCAを評価する。すなわち「フィーチャーフラグ$F$がオフのままだったらアウトカムは回避できたか」に答え、既知のインシデント記述と整合する説明を生成できるかを評価する。 - **Causal testingベンチマーク**(「どの要因が単に相関するのではなく真に障害を引き起こすか」): 因果的要因が既知または制御可能なシナリオ空間(シミュレータ、フォールトインジェクション環境、再現可能なマイクロサービスワークロード)。テスト生成が因果的要因を特定でき、介入コスト(時間・計算・リスク)とのトレードオフのもとで高インパクトな障害を効率的に見つけられるかを評価する。 さらに、オフラインベンチマークだけでは不十分であり、カナリアデプロイのような制御されたオンライン設定でも、time-to-root-cause・回避されたリグレッション・意思決定の確信度といった指標を用いて進捗を実証すべきだとする。報告基準として、(i) 効果推定と不確実性、(ii) 感度・反証分析、(iii) 前提が破れた場合の失敗モード、を報告すべきとする。反証(refutation)とは、因果的主張を積極的に反証しようと試みることを意味する。例えば、プラセボ介入のもとで推定効果が消えるか、妥当な代替調整セットのもとで大きく変化するかを確認する([17])。「利用可能なデータのもとではこの主張を支持できない」と報告する手法は、自信を持ちながらも脆い帰属を生成する手法よりも望ましいとしている(Source: §4)。 ## 考察 著者らは、CSEが既存のSE実践を置き換えるものではなく、それらを拡張するものであると強調している。相関ベースのAIOps・異常検知・LLMエージェントは検知やトリアージの役には立つが、行動を正当化しない。CSEの価値は、前提を外部化しレビュー可能にすることで、前提が破れたときにどの前提が破れたかを表面化できる点にあり、これはコードレビューやADRのレビューに類似したガバナンスの文化をSEにもたらすと位置づけられている。ロードマップの4ルートは独立ではなく共進化するものとされ、CRLという段階的成熟度モデルによって、ツールと組織の両方の進捗を測定できるとする(Source: §2, §3, §5)。 ## 強み/弱点・課題 **強み** - 相関ベースのAIOps/LLMエージェントが抱える「もっともらしいが根拠のない帰属」という具体的な失敗モードを、リトライポリシーの動機付け事例で明確に示している。 - causal design spec・intervention log・living causal modelという3つの軽量アーティファクトは、既存のCI/CDパイプラインやADRのワークフローに接続可能な形で提案されており、抽象的な理念にとどまらない実装への道筋を示している。 - Bertolino et al.のソフトウェアテストロードマップ([2])の"achievements–challenges–dreams"構造を踏襲することで、分野としての合意形成を意図した提示になっている。 - 評価計画において、確信を持てない場合に「支持できない」と報告することを推奨するなど、過信を防ぐ反証重視の科学的姿勢を明示している。 **弱点・課題(論文自身が述べる範囲)** - 本論文はビジョン・ロードマップ論文であり、CSEアーティファクト(causal design spec、intervention log、living causal model)自体の実装や定量評価は行われていない。提案の実現可能性は今後の研究課題として残されている。 - 因果グラフは「システム進化のもとで不安定になりうる」(Route 1の課題として明記、[10]を引用)とされており、CSE自身が前提とする因果構造の安定性がまだ解決されていない未解決課題として扱われている。 - 反実仮想的手法は「しばしば局所的(単一コンポーネント/実行)または定性的であり、分散した進化するシステムにはめったにスケールしない」とRoute 3で明記されており、大規模分散システムへのスケーラビリティは論文執筆時点で未達成である。 - 提案する3つのベンチマークファミリーはいずれも「今後構築されるべきもの」として述べられており、本論文の時点で実在するベンチマークやデータセットは示されていない。