### 2026-07-21 | ingest-paper | Don't Predict, Prioritize: Rethinking GPU Reliability Assessment (KDD '26 V.2, arXiv 2607.15115) - Focus: [[@2026__arXiv__Don't Predict, Prioritize - Rethinking GPU Reliability Assessment]] - Key concepts: [[障害予測]]・[[GPUレジリエンス]](いずれも更新) - Key entities: [[Difeng Ma]]・[[Yuanwei Lu]]・[[Quan Zhou]]・[[Daxin Jiang]]・[[Jingjing Li]](新規)、[[Changhua Pei]]・[[Gaogang Xie]]・[[Zexin Wang]]・[[Yibo Zhu]]・[[Dan Pei]]・[[Chinese Academy of Sciences]]・[[University of Chinese Academy of Sciences]]・[[Tsinghua University]]・[[StepFun]](更新) - Key insight: Difeng Ma・[[Changhua Pei]]ほか(Computer Network Information Center, [[Chinese Academy of Sciences]] / [[University of Chinese Academy of Sciences]] / [[StepFun]] / [[Tsinghua University]])による、GPU 障害の時系列予測が本質的に困難であることを実証しリスクランキングへ再定式化する論文(KDD '26 V.2、arXiv 投稿 2026-07-16)。XGBoost・CNN・LSTM・Transformer・MoE の5モデル横断で Double Bit Error・GPU Lost 障害の時系列予測を試み、8時間観測窓での最良モデル(MoE)でも F1 最大0.4837にとどまることを示した上で、Kendall相関(ワークロード変化を跨ぐと相関が崩壊)・SNR分析(ワークロード直結メトリクスが著しく低い)・分布比較(障害前後がほぼ完全に重複)の3分析でその原因をテレメトリの統計的性質に帰属させた。一方でホスト単位の障害はPareto分布に集中する(上位10%未満のホストが critical 障害の30%超・四半期を通じ24〜33%を安定的に占める、χ²検定でp≪10^-10)ことを発見し、精密な時間予測をランキングタスクへ再定式化するLearning-to-Rank(LTR)モデル HeaRank を提案した。軽量MLP(隠れ層512・512・256)による Non-linear Risk Interaction Encoder をpointwise sigmoid損失で訓練し、本番クラスタでAUC 0.834(LightGBM Rankerの0.795を上回る)・NDCG@5=0.427(38%相対改善)を達成。6ヶ月の本番オンライン展開(2025年7月〜2026年1月)では、上位5%リスクノード内に障害の64%が集中(既存Health Scoreシステムは21%)し、月あたり約5万ドルのGPU時間節約を試算した。既存concept [[障害予測]] に「精密な時間予測が破綻する領域ではランキングへの再定式化が代替パラダイムになる」という中心的知見と、ログベース予測(モデル強化路線)との対照、Salfner+ 2010 の時間軸パラメータ(t_p→∞のゲーム可能性)がランキングでは逆に有効に働く点を追記した。[[GPUレジリエンス]] には、HeaRankのホスト単位Pareto集中("lemon nodes")がGPU Resilienceのコンポーネント単位弱点分布(GSP/PMU/MMU/NVLink)の別粒度での現れであること、リスクランキングが「信頼性の床」を埋める第3の運用対処経路であることを追記した。CNIC/CAS の著者(Changhua Pei・Gaogang Xie・Zexin Wang)は既存の AIOps/インシデントトリアージ研究(COMET・UModel等)と同一グループであり、StepFun の Yibo Zhu は GPU クラスタスケジューリング(Tiresias)・LLM推論(DistServe)に続く3つ目の研究軸として本論文に参加した。図7点(Kendall相関・SNR分布・Pareto分布・アブレーション・スケジューリングアーキテクチャ・CDF比較・テレメトリパイプライン)を埋め込んだ。 - Open questions: HeaRankの「予測からランキングへの再定式化」路線はHDD・ログベース予測・サービスレベルoutage等の他の障害クラスにどこまで一般化できるか。ホスト単位Pareto集中("lemon nodes")はGPU Resilienceが特徴づけたどのコンポーネント別弱点(GSP・PMU・NVLink・メモリ)に主に起因するのか、両論文を突き合わせた原因分解は可能か。 ### 2026-07-21 | ingest | Tales from the Lunar Module Guidance Computer (AAS 04-064, 2004) - Focus: [[@2004__AAS__Tales from the Lunar Module Guidance Computer]] - Key concepts: [[優先度駆動リアルタイム実行系]]・[[リスタート保護]]・[[インターフェース仕様の齟齬による障害]]・[[制御ループの安定性とタイムラグ補償]](新規)、[[べき等性]]・[[チェックポイント]]・[[根本原因分析]]・[[ポストモーテム]](更新) - Key entities: [[Don Eyles]]・[[Allan Klumpp]]・[[Hal Laning]]・[[Apollo Guidance Computer]]・[[MIT Instrumentation Laboratory]](新規)、[[Margaret Hamilton]](更新) - Key insight: Apollo Lunar Module Guidance Computer のフライトソフトウェアエンジニア [[Don Eyles]] による当事者回顧録(第27回 AAS Guidance and Control Conference、2004年2月、著者公式サイト掲載版をブラウザUA付きcurl+defuddleで取得)。Apollo 11 の1201/1202プログラムアラームの根本原因が、ランデブーレーダーとATCA間のインターフェース制御文書(ICD)が「周波数同期」のみを規定し「位相同期」を規定しなかったことにあると特定し(→ [[インターフェース仕様の齟齬による障害]])、当時の報道による「コンピュータエラー」という表層的帰属に異を唱える。[[Hal Laning]]設計の優先度駆動プリエンプティブExecutive/Waitlist(→ [[優先度駆動リアルタイム実行系]])と、waypointによるリスタート保護(→ [[リスタート保護]])が資源枯渇時にも致命的崩壊を招かず着陸を継続させた設計思想を詳述。スロットル振動「キャッスレーション」問題では、ICD記載のタイムラグ値(0.3秒)が既に陳腐化していたにもかかわらず著者の経験的過小補償(0.2秒)が結果的に安定側に働いていたことを[[Allan Klumpp]]の事後解析が示す(→ [[制御ループの安定性とタイムラグ補償]])。既存concept [[べき等性]]・[[チェックポイント]]に手作業waypoint方式という自動最適化以前の設計原型の知見を、[[根本原因分析]]・[[ポストモーテム]]に単一原因帰属への異議が現代SRE文化に半世紀先行していたという知見を追記した。[[Margaret Hamilton]]ページとの間でExecutive設計の個人帰属粒度に関するcontradiction calloutを両ページに追加(Hamiltonは組織リーダー、Laningが個別設計者という一次資料上の違い)。図5点(PGNS構成図・DSKY・RRインターフェース図・キャッスレーション発見時の手書きmemo・スロットル振動実測データ)を埋め込んだ。 - Open questions: 優先度駆動プリエンプティブExecutiveの系譜は現代のリアルタイム組込みOS(VxWorks等)にどこまで直接引き継がれているか。waypoint方式(静的コード規約)とPICKERの動的べき等判定という二極の間に、自動化度合いで整理できる中間形態は存在するか。「経験的判断が仕様書の陳腐化を偶然打ち消した」という本事例は一般化できるか。 ### 2026-07-21 | ingest-paper | Mach: A Pluggable Metrics Storage Engine for the Age of Observability (CIDR 2022) - Focus: [[@2022__CIDR__Mach - A Pluggable Metrics Storage Engine for the Age of Observability]] - Key concepts: [[時系列データベース]]・[[専用データベースシステム]](いずれも更新) - Key entities: [[Andrew Crotty]]・[[Mach]](新規)、[[Franco Solleza]]・[[Nesime Tatbul]]・[[Stan Zdonik]]・[[Suman Karumuri]]・[[Brown University]]・[[Carnegie Mellon University]]・[[Slack Technologies]](更新) - Key insight: [[Franco Solleza]]・[[Andrew Crotty]]・[[Suman Karumuri]]・[[Nesime Tatbul]]・[[Stan Zdonik]]([[Brown University]]・[[Carnegie Mellon University]]・[[Slack Technologies]]・Intel Labs・MIT)による、オブザーバビリティ用メトリクスデータに特化したプラガブルストレージエンジン Mach の提案論文(CIDR 2022、vldb.org cidrdb 公式アーカイブより PDF 取得)。既存の Berkeley DB/LevelDB/RocksDB/WiredTiger 型の組み込みストレージエンジンと同じシンプルな push/get_range API を提供しつつ、内部は複数の独立したライタースレッドが疎結合(loosely coordinated)に振る舞うアーキテクチャを採る。mutex 獲得だけで Prometheus の書き込みオーバーヘッドの約25%を占めるという観察に基づき、各データソースを単一ライタースレッドに固定して協調オーバーヘッドそのものを除去し、追記主体(append-mostly)の高速パス・アクティブセグメント単位の一括圧縮・短く決定的なスナップショット機構を組み合わせる。予備実験(Rust実装プロトタイプ、Prometheus v2.29・InfluxDB tsm1・RocksDB と比較)では単一ノードで最大480M f64/秒の書き込み(既存最良比約10倍)、単一ライタースレッドでも100万データソースまでスケーリング、過去1時間/24時間クエリで最大3倍の読み取りスループットを達成した。画像は全8枚が埋め込みラスター画像(データ例・時間空間次元図・アーキテクチャ図・書き込み/読み取りパス図・スループットグラフ4枚)ですべて再利用可能だったため PyMuPDF クロップは不要だった。既存concept [[時系列データベース]] に「協調そのものの除去」という取り込み最適化の第6の軸と「書き込みが読み取りをブロックしうる」非対称トレードオフの知見を、[[専用データベースシステム]] に「除去の対象が機能ではなく同期プリミティブ自体になりうる」という知見を追記した。著者4名(Solleza・Tatbul・Zdonik・Karumuri)は既存 [[@2021__SIGMOD Record__Towards Observability Data Management at Scale]] の共著者と同一人物であり、Slack の2020年5月12日アウテージ・規模感(4B ソース/日・12M サンプル/秒)も同論文と同じ事実を再引用する形で確認された(矛盾なし)。 - Open questions: Mach のブロックインデックス(連結リスト)に代わる索引構造は何が適切か。単一ライタースレッド固定はホットスポットワークロードでどう振る舞うか。ログ・イベント・トレースへの拡張(特にグラフベースのデータモデルを要するトレース)は疎結合アーキテクチャとどう両立するか。 ### 2026-07-20 | ingest-paper | Dremel: Interactive Analysis of Web-Scale Datasets (VLDB 2010) - Focus: [[@2010__VLDB__Dremel - Interactive Analysis of Web-Scale Datasets]] - Key concepts: [[ネスト型カラムナストレージ]](新規)、[[列指向OLAPデータベース]]・[[並列データベース]](更新) - Key entities: [[Sergey Melnik]]・[[Andrey Gubarev]]・[[Jing Jing Long]]・[[Geoffrey Romer]]・[[Shiva Shivakumar]]・[[Matt Tolton]]・[[Theo Vassilakis]]・[[MapReduce]]・[[Protocol Buffers]](新規)、[[Google]](更新) - Key insight: Sergey Melnikほか([[Google]], Inc.)による対話的クエリシステムDremelの提案論文(VLDB 2010、research.google公式ページ経由でPDF取得)。ネストレコード(Protocol Buffers由来のデータモデル)を損失なくカラムへ分解・再構成するrepetition level / definition levelという新しい列指向ストレージ表現と、ウェブ検索エンジン由来の多段サービス木(serving tree)アーキテクチャを組み合わせ、兆行規模・数十〜百テラバイト級のテーブルへの集計クエリを数秒で実行する。2006年から社内本番稼働し、MapReduceを置き換えるのではなく補完する設計思想(MRパイプライン出力の対話的分析、プロトタイピング用途)を明示する。3000ノード規模の実験ではDremelとMR-on-columnsが約0.5TBの圧縮カラムデータのみ読むのに対しMR-on-recordsは87TB読み、record→columnar変換とMR→Dremel切り替えの双方で約1桁ずつ、合計2桁の実行時間短縮(時間→分→秒)を達成した。図はすべてベクター描画(埋め込みラスター画像87枚は全てフィールド装飾用の微小フラグメントで図全体としては使えず)のためPyMuPDFのキャプション座標クロップでFigure 1(record-oriented vs columnar)・Figure 2(サンプルスキーマとレコード)・Figure 3(列ストライプ表現)・Figure 7(システムアーキテクチャ)・Figure 9(ローカルディスク性能内訳)・Figure 10(MR/Dremel実行比較)の6枚を抽出した。新規concept [[ネスト型カラムナストレージ]] を作成し、既存concept [[列指向OLAPデータベース]] に「ネストデータへの列指向拡張は2010年に一度到達しており、2016年のSnowflake VARIANT型はリレーショナルDBMS側からの再到達である」という横断的知見を、[[並列データベース]] に「ウェブ検索由来の多段サービス木がDeWitt/Grayの想定しなかった第三の並列化手段として応用された」という横断的知見を追記した。 - Open questions: Dremelのrepetition/definition level符号化はApache ParquetのDremel由来ネストカラム表現とどこまで一致し、どこで異なるか。本論文が将来課題としたジョイン・インデックス・更新は、後継システム(F1・Napa等、いずれも本wiki未収録)でどう扱われたか。 ### 2026-07-20 | ingest-paper | MapReduce: Simplified Data Processing on Large Clusters (OSDI '04) - Focus: [[@2004__OSDI__MapReduce - Simplified Data Processing on Large Clusters]] - Key concepts: [[タスク並列フレームワーク]](更新) - Key entities: [[Jeffrey Dean]]・[[Sanjay Ghemawat]]・[[Google]]・[[Google File System]](いずれも更新) - Key insight: [[Jeffrey Dean]]・[[Sanjay Ghemawat]]([[Google]], Inc.)による MapReduce の提案論文(OSDI '04、USENIX 公式アーカイブより PDF 取得)。map/reduce の2関数だけを利用者が書けば、並列化・耐障害性・データ分散・負荷分散の詳細をライブラリが隠蔽するプログラミングモデルを提示し、コモディティ PC 数千台のクラスタ上で数テラバイト規模のデータを処理する実装を報告する。master による中央集権スケジューリング(map タスク M 個・reduce タスク R 個、O(M+R) スケジューリング決定・O(M×R) 状態保持)、worker 故障時のタスク再実行による耐障害性(reduce タスクはグローバルファイルシステム保存のため再実行不要)、[[Google File System]] のローカルディスク配置を活用した局所性最適化、straggler(遅延ワーカー)緩和のためのバックアップタスク機構(sort ベンチマークで無効化すると44%時間増加)が核となる設計要素。2004年8月時点で月29,423ジョブ・入力3,288TB規模で本番稼働し、Google の検索インデックス生成システムの書き換えでコード量を約1/5(3800行→700行)に削減した実績を報告する。既存 concept [[タスク並列フレームワーク]](単一ソース: Ray OSDI 2018 に基づいていた)に、BSP 静的 DAG モデルの起源としての MapReduce と、Ray の GCS 分離設計との対比(master 中央集権 vs GCS ステートレス化)、タスク全体再実行 vs Spark RDD 由来の血統ベース部分再計算という耐障害性戦略の分岐、eager scheduling を発展させたバックアップタスク機構という3つの横断的知見を追加した。図表は全てベクター描画(埋め込みラスター画像0枚)のため PyMuPDF のキャプション座標クロップで Figure 1(実行フロー概要)・Figure 2(grep 転送レート)・Figure 3(sort 転送レート 3実行比較)・Figure 4(インスタンス数推移)・Table 1(2004年8月ジョブ統計)を抽出した。 - Open questions: MapReduce のタスク全体再実行モデルから Spark RDD の血統ベース部分再計算への移行を可能にした具体的な設計変更(RDD の不変性・変換の遅延評価等)は何か。master 単一障害点(チェックポイント機構はあるが実運用は中断・再試行に依存)への対処は、後継システム(YARN・Borg 等)でどう解決されたか。 ### 2026-07-20 | ingest-paper | The Snowflake Elastic Data Warehouse (SIGMOD 2016) - Focus: [[@2016__SIGMOD__The Snowflake Elastic Data Warehouse]] - Key concepts: [[シェアードナッシング]]・[[並列データベース]]・[[データパーティショニング]]・[[列指向OLAPデータベース]](いずれも更新) - Key entities: [[Snowflake Computing]]・[[Benoit Dageville]]・[[Thierry Cruanes]]・[[Marcin Zukowski]](新規)、[[Amazon Web Services]](更新) - Key insight: Benoit Dageville・Thierry Cruanes・Marcin Zukowski ほか18名の著者([[Snowflake Computing]])による、クラウドデータウェアハウス Snowflake の設計を報告する産業論文(SIGMOD 2016)。ストレージ(Amazon S3)とコンピュート(Virtual Warehouse)を疎結合な独立サービスへ分離した「マルチクラスタ・シェアードデータ・アーキテクチャ」を導入し、シェアードナッシングが抱えるヘテロジニアスワークロード・メンバーシップ変更・オンラインアップグレードの3課題を解決する。テーブルファイルを不変(immutable)にすることで、MVCCベースのSnapshot Isolation・`AT`/`BEFORE`構文による時間旅行・`CLONE`によるメタデータのみのゼロコピークローン・全サービスのステートレス化による週次オンラインアップグレードを、単一の設計原理から一貫して導出している点が本論文の核心。ワーカーノードのローカルキャッシュには lazy な一貫性ハッシュと file stealing を組み合わせ、頻繁なノード障害・リサイズを伴うクラウド環境でも高いキャッシュヒット率とスキュー耐性を両立する。VARIANT/ARRAY/OBJECT型と自動型推論・列指向格納により、半構造化データに対するELT処理をTPC-H実験で約10%オーバーヘッドに抑えた。4階層(root/account/table/file)の暗号鍵階層をAWS CloudHSMに根ざして構築し、key rotation(月次)とrekeying(年次)を分離してエンドツーエンド暗号化する。図はすべてベクター描画(埋め込みラスター画像0枚)のためPyMuPDFのキャプション座標クロップでFigure 1〜6(アーキテクチャ・マルチデータセンター構成・オンラインアップグレード・TPC-H性能・鍵階層・鍵ライフサイクル)を抽出した。既存concept [[シェアードナッシング]] [[並列データベース]] の「クラウドネイティブ分離アーキテクチャはどのカテゴリに属するか」という未解決の問いに対し、Snowflake自身が「マルチクラスタ・シェアードデータ」という新語を自称するのみで学術的な4分類は未確立であることが判明した。 - Open questions: 部分再試行(partial retry)未実装のため大規模長時間クエリの信頼性は課題として残る。AZ全体障害時はユーザーが手動でVWを再プロビジョンする必要があり唯一許容された部分可用性喪失シナリオ。worker node のVW間共有は将来課題。SF1000のQ9・Q17で見られたdistinct value推定バグの根本解決状況は本論文からは不明。 ### 2026-07-20 | ingest-paper | Using Lightweight Formal Methods to Validate a Key-Value Storage Node in Amazon S3 (SOSP '21) - Focus: [[@2021__SOSP__Using Lightweight Formal Methods to Validate a Key-Value Storage Node in Amazon S3]] - Key concepts: [[軽量形式手法]](新規)、[[LSMツリー]](更新) - Key entities: [[ShardStore]]・[[James Bornholt]](新規)、[[Amazon Web Services]](更新) - Key insight: [[James Bornholt]]ら AWS チームによる、Amazon S3 の新しいキーバリューストレージノード [[ShardStore]](Rust実装 40,000行超)を「軽量形式手法」で検証した経験報告(SOSP '21)。完全形式検証の健全性ではなく自動化・保守性・継続的な正しさ維持を優先し、実装と同じ言語(Rust)で書く実行可能な参照モデル(実装の1%規模)を、耐久性特性を「逐次クラッシュなし・逐次クラッシュあり・並行クラッシュなし」の3種に分解して検証する。逐次特性は property-based testing(Fig.3の`IndexOp`アルファベット例、biasingによる網羅性向上、自動minimization)で、並行性は stateless model checking で linearizability を検査し、健全だがスケールしない Loom(小規模並行プリミティブ用)と確率的だが大規模化できる自作の Shuttle(end-to-end ストレステスト用)を使い分ける。クラッシュ整合性は soft updates 由来の宣言的 `Dependency` 型(Fig.1/Fig.2で shard データをエクステント外へ配置しLSMツリーを物理配置インデックスへ純化する設計と一体)で扱う。本番投入前に16件の不具合(機能的正しさ5・クラッシュ整合性5・並行性6、うち bug #10 のUUID衝突クラッシュ整合性バグとbug #14のLoom検出レースコンディションは論文中で詳述)を検出し、検証アーティファクト(実装比20%規模、完全形式検証の3〜10倍オーバーヘッドより軽量)の保守はテストハーネスコードの18%が形式手法非専門のエンジニアによって書かれるまでチームへ引き継がれた。 - Open questions: 並行クラッシュ実行(並行性+クラッシュの組み合わせ)を検証する有効な自動化手法は未確立。リソース枯渇系障害は容量差を区別するオラクル欠如のため未対応。実装と同じ言語で参照モデルを書くアプローチはRust以外の言語でも同程度の保守コスト削減効果を持つか未検証。 ### 2026-07-20 | ingest-paper | Aurora DSQL: Scalable, Multi-Region OLTP (arXiv 2607.13276) - Focus: [[@2026__arXiv__Aurora DSQL - Scalable, Multi-Region OLTP]] - Key concepts: [[分散SQLデータベース]]・[[地理分散SQLデータベース]]・[[分散トランザクション]]・[[分散コンセンサス回避]]・[[クォーラムベースレプリケーション]](いずれも更新) - Key entities: [[Aurora DSQL]](新規)、[[Marc Brooker]]・[[Amazon Aurora (Database)]](更新) - Key insight: [[Marc Brooker]]ら AWS チームによる、compute・storage・トランザクション調整を Query Processor・Adjudicator・Journal・Crossbar・Storage の5サービスに分離した disaggregated アーキテクチャの分散 SQL データベース(arXiv v1 2026-07-14)。読み取りは精密タイムスタンプによる MVCC で座標不要、書き込みは OCC でローカルバッファし、Adjudicator + 単一 Journal へのアトミック書き込みでコミット時にのみ座標する設計により、マルチリージョンでもステートメントごとの座標(Spanner・CockroachDB の悲観的ロック方式)を排除する。実測では2リージョン構成で SELECT p99 約2ms・UPDATE p99 約3ms・COMMIT p99 約30ms(単一リージョンでは7.4ms)を達成し、悲観的ロックベースの比較対象がUPDATE数に比例してレイテンシが線形増加するのに対しDSQLは一定を保つ。Journal間の2-of-3イレイジャーコーディングでレイテンシ分散と可用性(base 99.99%→7.5桁超)を同時に改善する点、snapshot isolationのみを唯一のisolation levelとする設計判断、複数Adjudicator間のcommit protocolがWarpに着想を得て「投票のアトミック性」と「コミットのアトミック性」を分離する点が新規性。[[Amazon Aurora (Database)]](classic Aurora)とは論文自身が脚注で明示的に区別する別システムであり、entityページに同名注意の注記を追加した。 - Open questions: 複数Adjudicator同時障害時のデッドロック率・リトライ嵐は定量化されていない。レンジベースパーティショニングが困難とするシリアルキー・書き込み局所性インデックス・低カーディナリティインデックスのスケーリング問題への解法(レンジ+ハッシュのハイブリッド)は今後の計画段階。write skewの実運用での深刻度はSpanner/CRDBの悲観的ロックとの比較データがない。 ### 2026-07-20 | ingest-paper | LLM hallucinations in the wild: Large-scale evidence from non-existent citations (arXiv 2605.07723) - Focus: [[@2026__arXiv__LLM hallucinations in the wild]] - Key concepts: [[LLMのハルシネーション]](新規) - Key entities: [[Zhenyue Zhao]]・[[Yihe Wang]]・[[Toby Stuart]]・[[Mathijs De Vaan]]・[[Paul Ginsparg]]・[[Yian Yin]](新規)、[[Cornell University]]・[[University of California, Berkeley]]・[[Tsinghua University]](更新) - Key insight: Cornell University・UCLA・Tsinghua University・UC Berkeley Haas School of Business の研究チーム(Zhenyue Zhao・Yihe Wang 共同筆頭、Yian Yin 責任著者、arXiv の創設者 Paul Ginsparg も共著)による、LLM ハルシネーションを実世界の規模で監査した初の大規模研究(arXiv 2026-05-08)。学術引用という「実在するか否かが一意に判定できる」対象を使い、arXiv・bioRxiv・SSRN・PubMed Central の論文250万本・参照1億1,100万件を監査。LLM 登場前の unmatched 引用率をベースライン(通常の書誌エラー)として差し引く設計により、2025年単年で少なくとも146,932件のハルシネーション引用を推定した。汚染は少数の重度汚染論文への集中ではなく多数の論文への薄い拡散であり、ハルシネーション引用を出す著者は2022年以前は低生産性だったが2025年には生産性格差が解消(1.3〜3.1倍増)、実在著者に一致した場合は高生産性・高被引用・男性名の著者に不均衡に功績を帰属させる点、arXiv モデレーションの通過率が78.8%に達し既存の品質管理が追いついていない点を明らかにした。本 wiki 初の science-of-science 系ソースであり、既存 concept [[LLMのハルシネーション]] を新規作成し、モデル開発者視点([[@2023__arXiv__GPT-4 Technical Report]] の自己申告的限界言及)と社会実装視点(本論文の population スケール定量化)という2つの観測軸の違いを横断的知見に記録した。図表は全てベクター描画(埋め込みラスター画像0枚)のため PyMuPDF のキャプション座標クロップで Figure 1〜3 を抽出した。 - Open questions: RLHF 等の事後訓練は実世界の引用ハルシネーション発生率をどの程度実際に低減させているか。引用以外の非構造化な主張(政策メモ・臨床記録)における同種のベースライン差分推定は確立されているか。エージェント型検証ツールの普及は本論文が観測したモデレーション通過率(78.8%)をどの程度引き下げるか。 ### 2026-07-20 | ingest-slides | 30分でわかるデータ指向アプリケーションデザイン (Data Engineering Study #18) - Focus: [[@2023__DataEngineeringStudy__30分でわかるデータ指向アプリケーションデザイン]] - Key concepts: [[導出データ]](新規)、[[分散トランザクション]](更新) - Key entities: [[Taro L. Saito]](新規)、[[Amazon Aurora (Database)]]・[[DuckDB]](更新) - Key insight: 『データ指向アプリケーションデザイン』監訳者 Taro L. Saito(@xerial)による、原著出版(2017年)から5年間のデータ基盤技術の発展を原著の枠組み(データ形式・データ量・更新頻度・分散処理・トランザクション・データモデル・SLO)に沿って再構成した講演(2023-02-15)。Parquet/Dremel の列指向フォーマット、B-Tree と LSM ツリーの対比、classic Amazon Aurora(SIGMOD 2018)の gossip プロトコルによる 2PC 回避、RDBMS の「テーブル」が導出データ(derived data)へ意味を変えてきた変遷(dbt・Delta Lake/Iceberg/Hudi)、SQL の役割拡大(F1・Trino・Velox)、2023年2月の Elon Musk ツイート未配信問題を SLO・部分障害耐性の実例として扱う。新規 concept [[導出データ]] を作成し、既存 concept [[分散トランザクション]] に classic Aurora の「プロトコル最適化ではなくアーキテクチャによる 2PC 回避」という系統を追記した。 - Open questions: 音声・動画 transcript 未取得のため質疑応答等の口頭補足は反映されていない。p.34-36 で紹介される参考文献リスト(GitHub: ept/ddia-references)の個別文献はスライドから検証不能。 ### 2026-07-20 | ingest-slides | Design and Implementation of DuckDB Internals (DiDi Course #1〜#8, 全講義) - Focus: [[@2026__DuckDB__Welcome & Setup (DiDi Course, Lecture 1)]]・[[@2026__DiDi__The Query Performance Spectrum]]・[[@2026__DiDi__Managing Memory + Grouped Aggregation]]・[[@2026__DiDi__Sorting Large Tables]]・[[@2026__DiDi__The ART of Indexing]]・[[@2026__DiDi__Query Execution Plans and Pipelining]]・[[@2026__DiDi__Vectorized Query Execution]]・[[@2026__DiDi__Query Rewriting and Optimization]] - Key concepts: [[アウトオブコア処理]]・[[ハッシュベースグループ集約]]・[[外部マージソート]]・[[キー正規化]]・[[Adaptive Radix Tree]]・[[Zonemap]]・[[クエリ実行プラン]]・[[プッシュ型パイプライン実行]]・[[クエリオプティマイザ]]・[[結合順序最適化]]・[[クエリ非相関化]](いずれも新規)、[[列指向OLAPデータベース]]・[[B-Tree]]・[[並列データベース]]・[[SIMDベクトル処理]]・[[分岐予測]]・[[パイプライン処理]](更新) - Key entities: [[Torsten Grust]]・[[DuckDB Labs]]・[[Universität Tübingen]](新規)、[[DuckDB]]・[[Hannes Mühleisen]]・[[Mark Raasveldt]](更新) - Key insight: https://duckdb.org/library/design-and-implementation-of-duckdb-internals/ で公開されている、[[Torsten Grust]]([[Universität Tübingen]])による15週講義シリーズ「Design and Implementation of DuckDB Internals(DiDi)」の全8回スライド(#1 Welcome & Setup 〜 #8 Query Rewriting and Optimization)を一括取り込みした。DuckDBの「zero copy」プロセス内蔵設計という導入から、性能スペクトラム実測(awk比40倍以上高速化)、メモリ管理・外部グループ集約、二相マージソート、Zonemap/ART二種のインデックス、実行プランのパイプライン分解、ベクトル化実行(unified representation+テンプレート)、クエリオプティマイザ(DPhyp結合順序最適化・クエリ非相関化)まで、単一組み込みOLAP DBMSの内部設計を一貫した視点(講師自身がコミッターであり、DuckDB 1.4/1.5の実ソースコードを頻繁に参照)で追える教材群になっている。個別ページ番号とスライド埋め込み画像ファイルの対応にずれが生じやすく(#6で発見・修正)、出典検査では画像を正としてページ対応を必ず再確認する必要があった。 - Open questions: 第3回(Managing Memory + Grouped Aggregation)はPhase 2(パーティション単位集約)の説明手前で終わっており、続きが同シリーズの未公開・今後の回で扱われる可能性がある。日付メタデータ(コースページ公開日2026-03-19 vs 各スライド表紙の個別講義日)の食い違いの真相は未確認。 ### 2026-07-20 | ingest-paper | DuckDB: an Embeddable Analytical Database (SIGMOD '19) - Focus: [[@2019__SIGMOD__DuckDB - an Embeddable Analytical Database]] - Key concepts: [[列指向OLAPデータベース]](更新) - Key entities: [[Mark Raasveldt]]・[[Hannes Mühleisen]]・[[CWI]]・[[DuckDB]]・[[MonetDBLite]](いずれも新規) - Key insight: CWI([[Mark Raasveldt]]・[[Hannes Mühleisen]])によるSIGMOD '19デモンストレーション論文。SQLiteが組み込みデータベースとして普及する一方でOLAP(分析)性能に乏しいという課題を受け、パーサ(libpg_query)・コストベースオプティマイザ・ベクトル化解釈実行エンジン・HyPer由来のシリアライザブルMVCC・DataBlocksストレージから成る組み込み分析専用データベースDuckDBを提示。前身[[MonetDBLite]]が非purpose-built(既存非組み込みシステムの後付け組み込み化)であることに起因する課題を克服するためゼロから設計された点、JITコンパイル不採用による移植性優先の判断が特徴。既存concept [[列指向OLAPデータベース]] に、サーバプロセス型(ClickHouse)と組み込み型(DuckDB)という直交する配備形態、および組み込み型特有の「結果セット転送コスト」という性能軸を横断的知見として追加した。本論文はデモンストレーション提案であり定量的性能数値は含まれない(4章時点でDataBlocksストレージ・カーディナリティ推定・バッファマネージャは未実装と自認)。画像は埋め込みラスター画像0枚のためPyMuPDFクロップ等の図表埋め込みは行っていない。 - Open questions: 組み込み型(DuckDB)とサーバプロセス型(ClickHouse)の列指向OLAPを同一条件で比較した定量評価は存在するか。結果転送コストを除いたクエリ実行時間だけで見た場合、両者の性能差はどの程度縮まるか。 ### 2026-07-20 | ingest-paper | Niyama: Breaking the Silos of LLM Inference Serving (arXiv 2503.22562 / ASPLOS 2026) - Focus: [[@2025__arXiv__Niyama - Breaking the Silos of LLM Inference Serving]] - Key concepts: [[LLM推論]]・[[Prefill-Decode分離]]・[[LLMサービング管理]](いずれも更新) - Key entities: [[Kanishk Goel]]・[[Jayashree Mohan]]・[[Nipun Kwatra]]・[[Ravi Shreyas Anupindi]]・[[Ramachandran Ramjee]]・[[Sarathi-Serve]](新規)、[[Microsoft Research]]・[[vLLM]](更新) - Key insight: Microsoft Research India([[Kanishk Goel]]ら)による QoS 駆動 LLM 推論サービングシステム Niyama(arXiv 2025-03-28、改題後 "QoServe" として ASPLOS 2026 採録)。ユーザー提示 URL のタイトル("QoServe")と abstract を arXiv 版(初出タイトル "Niyama")と照合して同一論文と確認し、図表取得の容易な arXiv 版を原本に採用した。既存 LLM サービングの interactive/batch サイロ分割による資源偏在を、[[Sarathi-Serve]] の chunked-prefill スケジューラを拡張した co-scheduling(デッドラインスラックに基づく動的チャンキング・EDF/SRPF のハイブリッド優先度付け・過負荷時の積極的降格)で解消し、SOTA サイロ構成比 GPU 必要台数 13〜32% 削減、goodput 最大 2.4 倍を達成。[[Prefill-Decode分離]](DistServe 等の物理分離路線)とは対照的に「同居を維持したまま共有インフラでスラックを再配分する」路線であることを 3 概念ページの横断的知見に記録した。ベクター描画グラフ(Figure 7)は PyMuPDF のキャプション座標クロップで抽出し、埋め込みラスター画像 3 枚と合わせて計 4 図を source ページに埋め込んだ。 - Open questions: ハイブリッド優先度付けの補間パラメータ α の自動調整機構は未検証。Niyama(同居 co-scheduling)と DistServe(物理分離)を同一ワークロード・同一 GPU 予算で比較した評価は論文内に存在しない。PreServe(インスタンス間ルーティング)と Niyama(インスタンス内スケジューリング)を積層した際の制御ループ競合の有無。 ### 2026-07-20 | ingest | In-House LLM Serving at Netflix (Netflix TechBlog) - Focus: [[@2026__Netflix TechBlog__In-House LLM Serving at Netflix]] - Key concepts: [[制約付きデコーディング]](新規)、[[LLM推論]](更新) - Key entities: [[Triton Inference Server]](新規)、[[Netflix]]・[[vLLM]]・[[TensorRT-LLM]]・[[NVIDIA]](更新) - Key insight: Netflix AI Platform チーム(Liping Pengほか11名)による、既存のJVM統合サービングシステムとModel Scoring Service(MSS)/[[Triton Inference Server]]上でLLM推論を内製運用する本番事例。2026年夏に[[TensorRT-LLM]]から[[vLLM]]へpaved-pathエンジンを切り替えた判断根拠が、性能ベンチマークではなく「カスタムモデル対応の容易さ・デバッグ性・研究本番間の移行コスト」という運用適合性だった点が特徴的。TritonのPython/vLLMバックエンド選択がフロントエンド改修とモデル成果物の結合度を左右し、vLLMバックエンド採用後もTriton/vLLMのバージョン整合を手動固定する必要が生じた。vLLM V0(GIL律速のper-request logits processor、CPU時間がバッチサイズに線形増加)からV1(batch-level API、C++マルチスレッド化)への移行で、単一リクエストベンチマークでは見えないテイルレイテンシ問題を解消した経緯を新規concept [[制約付きデコーディング]] に記録した。 - Open questions: TritonのvLLMバックエンドとPythonバックエンドの共存が今後もどの程度必要であり続けるか(カスタムモデル向けエスケープハッチとしての依存度)。V1のBatchUpdateが部分prefill・プリエンプションを直接扱えない設計上の粒度不足は、他の推論エンジンのlogits processor相当機構にも共通する制約か。次期投資に挙げられた「ベクトル化されたlogits processor(GPU融合カーネル化)」で状態機械の遷移ロジックをどこまでGPU側に移せるか。 ### 2026-07-20 | ingest-paper | FailSafe: High-performance Resilient Serving (arXiv 2511.14116 / MLSys 2026 Oral "RaidServe") - Focus: [[@2025__arXiv__FailSafe - High-performance Resilient Serving]] - Key concepts: [[耐障害LLMサービング]](新規)、[[テンソル並列]]・[[KVキャッシュ管理]]・[[耐障害LLM訓練]](更新) - Key entities: [[Ziyi Xu]](新規)、[[Zhiqiang Xie]]・[[Swapnil Gandhi]]・[[Christos Kozyrakis]]・[[Stanford University]]・[[Shanghai Jiao Tong University]]・[[ReCycle]](更新) - Key insight: Stanford University([[Zhiqiang Xie]]・[[Swapnil Gandhi]]・[[Christos Kozyrakis]])と Shanghai Jiao Tong University(Ziyi Xu)による、テンソル並列 LLM サービングの耐障害システム FailSafe(arXiv 2025-11-18、MLSys 2026 Oral に "RaidServe" として採択・ユーザー入手のカメラレディ PDF で内容一致を確認済み)。GPU 障害を「復旧オーバーヘッド」と「持続的な計算・メモリ不均衡」の2種に分離し、前者に Proactive KVCache Backup + On-demand Weight Recovery(復旧183倍高速化)、後者に Cyclic KVCache Placement + Hybrid Attention + Fine-Grained Load-Aware Routing(標準対比最大2倍スループット)で対応。同じ著者(Gandhi・Kozyrakis)が SOSP '24 で発表した訓練向け耐障害システム [[ReCycle]] との対比(訓練の冗長性活用 vs サービングの負荷分配均等化)を新規 concept [[耐障害LLMサービング]] に記録した。 - Open questions: シングルノード(8 GPU、NVLink内)構成に限定した評価がマルチノード・ノード全体障害へどう一般化するか。MoE のエキスパート並列が TP より部分 GPU 損失に耐性が高いという著者らの指摘(§6)は本論文自身では未検証。ReCycle(訓練)と FailSafe(サービング)の統合(パイプライン+テンソル並列ハイブリッド構成での耐障害設計)は今後の課題。 ### 2026-07-20 | ingest | Kimi K3: Open Frontier Intelligence (Moonshot AI Blog) - Focus: [[@2026__Moonshot AI__Kimi K3 - Open Frontier Intelligence]] - Key concepts: [[Mixture-of-Experts]](更新) - Key entities: [[Kimi K3]]・[[Kimi Delta Attention]]・[[Attention Residuals]]・[[Stable LatentMoE]](いずれも新規)、[[Moonshot AI]]・[[Kimi Linear]](更新) - Key insight: [[Moonshot AI]] が 2026-07-17 発表した総パラメータ 2.8 兆・コンテキスト 100 万トークンの LLM [[Kimi K3]]。「世界初のオープンな 3T クラスモデル」を謳い、[[Kimi Linear]](48B)由来の [[Kimi Delta Attention]](KDA)を 512-head MLA と組み合わせて 2.8T 級へスケールアップした点が最大の技術的連続性(48B→2.8T の約58倍スケール実証)。[[Stable LatentMoE]](896 エキスパート中 16 活性化、スパーシティ 56)は Kimi K2(384 エキスパート/活性化 8、スパーシティ 48)からの拡張だが NVIDIA の LatentMoE(Nemotron 3)と名称類似・機構は不明。Attention Residuals(AttnRes)・Per-Head Muon・Quantile Balancing・Sigmoid Tanh Unit(SiTU)は名前のみ言及され詳細非公開。DeepSWE v1.1 で 67.3、コーディングで Claude Fable 5・GPT-5.6 Sol 以外を上回るが「全体性能は最強のプロプライエタリモデルに劣る」と自認。モデルウェイト・技術レポートは 2026-07-27 公開予定。kimi.com はサンドボックスのネットワーク許可リスト外のため WebFetch 構造化要約に基づく(逐語引用ではない)ソース制約をページに明記した。 - Open questions: Stable LatentMoE は NVIDIA LatentMoE と同一設計か。AttnRes の具体機構。Per-Head Muon と MuonClip/Sharded Muon/NorMuon の関係。K3 の活性化パラメータ数(記事未記載)。技術レポート公開(2026-07-27)後の裏取り必須。 ### 2026-07-20 | ingest | LLM生成テキストの統計的検知: TF-IDF+SVMによるAIGC分類器の構築 (blog.lyc8503.net) - Focus: [[AI生成テキスト分類器]] - Key concepts: [[AI生成テキスト検知]](新規) - Key entities: [[lyc8503]]・[[AITextDetector]](いずれも新規) - Key insight: 個人ブログ記事(著者 [[lyc8503]])。既存LLMの単語出現確率を用いる[[パープレキシティ]]ベースのAI生成テキスト検知は偽陽性・偽陰性が多く実用性に乏しいと判明。代わりに `TF-IDF` + `LinearSVC` の伝統的機械学習パイプラインを採用し、7つのLLM(gemini・qwen・GLM-5・kimi25・glm47・doubao・deepseek-v3.2)それぞれに対応する二値分類器を学習、2票以上の多数決で AI 生成文を判定する方式で文単位精度約85%(平均F1 0.8348、50万特徴量版)を達成。訓練データに含まれない未知モデル(Claude Sonnet 4.6: 71.9%、GPT 5.2: 73.3%)にも汎化する。Lofterの高閲覧数長文投稿1万件での偽陽性率は閾値60%で0.04%と極めて低い一方、同プラットフォームのトレンド記事の32.22%がAIスコア50%超と判定され無断AI生成コンテンツの広範な存在を示唆。翻訳往復や「AI感を減らせ」プロンプトによる回避策は検知スコアを軽微に下げるのみ(89.9%→79〜86%)で実用的な回避手段にならないことも実証した。 - Open questions: 独立データセットやより多様なLLMへの汎化限界は未検証。SVMの特徴量を的確に破壊するルールベース回避手法の実効性は著者自身も未検証と明言。Lofter以外のドメイン・言語への転移性能は不明。 ### 2026-07-18 | ingest-paper | The Too-Much-Talent Effect: Team Interdependence Determines When More Talent Is Too Much Versus Not Enough (Psychological Science, 2014) - Focus: [[@2014__PsychSci__The Too-Much-Talent Effect - Team Interdependence Determines When More Talent Is Too Much or Not Enough]] - Key concepts: [[過剰人材効果]]・[[タスク相互依存性]](いずれも新規) - Key entities: [[Roderick I. Swaab]]・[[Michael Schaerer]]・[[Eric M. Anicich]]・[[Richard Ronay]]・[[Adam D. Galinsky]]・[[INSEAD]](新規)、[[Columbia University]]・[[Vrije Universiteit Amsterdam]]・[[Singapore Management University]](更新) - Key insight: INSEAD の Roderick I. Swaab を筆頭著者とする組織行動論の実証研究(Psychological Science, 2014-08)。サッカー(FIFA、2010/2014年W杯予選、415チーム・期間観測)・バスケットボール(NBA、10シーズン297観測)・野球(MLB、10シーズン300観測)のアーカイバルデータで、トップタレント比率とチーム成績の関係を検証。相互依存性が高いサッカー・バスケでは人材比率50%超で成績が負に転じる逆U字型の曲線(too-much-talent effect)が現れ、相互依存性が低い野球では単調増加のまま転じないことを示した。NBA の play-by-play データ(アシスト・FG%・ディフェンスリバウンド)を用いた媒介分析で、チーム内コーディネーションの低下が人材過多効果を媒介することを Sobel 検定(Z=2.93, p<.01)とブートストラップ間接効果(95%CI [-1.20, -.12])で立証。2つのサーベイ研究(Study 1a/1b)では、人々の素朴信念が実際のデータとは異なり、人材と成績の関係を常に線形・単調増加だと予測していることも確認した。論文中の6図(Figure 1〜6)すべてを埋め込み画像抽出とPyMuPDFキャプション座標クロップで source ページに埋め込んだ。 - Open questions: タスク相互依存性はスポーツ種目の違いから間接的に推定されたのみで直接操作した検証はない。地位争い(status conflict)メカニズムそのものは直接測定されていない。スポーツ以外の組織文脈(企業チーム等)への一般化は未検証。 ### 2026-07-18 | ingest-paper | OpsMem: Dual-Memory Reasoning with Cross-Memory Resonance for Failure Diagnosis (arXiv 2607.11357) - Focus: [[@2026__arXiv__OpsMem - Dual-Memory Reasoning with Cross-Memory Resonance for Failure Diagnosis]] - Key concepts: [[エージェントメモリ]]・[[仮説駆動RCA]]・[[LLMによる根本原因分析]](いずれも更新) - Key entities: [[OpsMem]]・[[Rongchen Gao]]・[[Qingyi Guo]]・[[Yaoliang Wu]](新規)、[[Yongqian Sun]]・[[Yu Luo]]・[[Wenwei Gu]]・[[Shenglin Zhang]]・[[Dan Pei]]・[[Qiuai Fu]]・[[Nankai University]]・[[Tsinghua University]]・[[Huawei Technologies]](更新) - Key insight: Nankai University・Tsinghua University・Huawei Technologies による失敗診断向けデュアルメモリフレームワーク OpsMem(arXiv 2026-07-13)。短期記憶(STM、症状・証拠・仮説のグラフ、GoS の belief-state 抽象化を踏襲)と長期記憶(LTM、パターン・ケース・プロシージャのグラフ)を cross-memory resonance(CMR)で結合し、STM が更新されるたびに CMR が関連 LTM 部分グラフを再活性化する。Huawei の実運用マイクロサービス障害 120 件データセットで、エージェント的推論(ReAct・GoS)・知識拡張(GoS+VectorRAG/GraphRAG/LinearRAG)の全ベースラインを一貫して上回り(最強ベースライン比 Match +6.66〜25.00pt、Relevant +3.33〜13.33pt)、アブレーションで LTM 除去が最大の性能低下(78.33→30.83)をもたらすことを確認。LTM consolidation により診断を重ねるほど性能が向上する自己進化も実証した(RQ3、最大 Match +5pt)。論文の埋め込み図5枚(状態-経験結合の動機図・全体アーキテクチャ・CMR 3ステップ・LTM consolidation・実インシデントケーススタディ)をキャプション座標クロップで source ページに埋め込んだ。 - Open questions: signal/pattern activation の閾値(0.6・等重み)の感度分析が未実施。LTM の事前構築コストと構築品質が下流精度に与える影響は未評価。人間 SRE が LTM へ実行時介入する余地は論文に記載なし。 ### 2026-07-18 | ingest-paper | MLCommons Chakra: Advancing Performance Benchmarking and Co-design using Standardized Execution Traces (MLSys 2026 Oral, arXiv 2605.11333) - Focus: [[@2026__MLSys2026__MLCommons Chakra - Advancing Performance Benchmarking and Co-design using Standardized Execution Traces]] - Key concepts: [[実行トレース]](新規)、[[Prefill-Decode分離]]・[[KVキャッシュ管理]](更新) - Key entities: [[MLCommons Chakra]]・[[MLCommons]]・[[Georgia Institute of Technology]]・[[Tushar Krishna]]・[[Srinivas Sridharan]]・[[ASTRA-sim]](新規)、[[NVIDIA]]・[[AMD]]・[[vLLM]](更新) - Key insight: Srinivas Sridharan・Tushar Krishnaを責任著者とする29名(NVIDIA・Georgia Institute of Technology・AMD・Meta・Keysight・MLCommons等)によるMLSys 2026 Oral論文。分散AI/MLワークロードの性能挙動を記述する標準グラフ表現「Chakra実行トレース(ET)」を核に、Trace Linker/Converterによるホスト側(PyTorch Observer)・デバイス側(Kineto)トレースの統合、trace analysis/replay/simulation-emulationの3用途からなるMLCommons公認エコシステムを提示。2023年にMetaとGeorgia Techが立ち上げた標準化が40以上の企業・組織のワーキンググループへ発展し、ASTRA-sim・Keysight AI DCB・Scala Compute Platform等に実装されている。訓練ワークロード(GPT3/Llama3/Mixtral/DeepSeek-MoE)のトレース分析・リプレイでNCCLカーネル帯域リプレイ比1.0〜1.3倍を確認し、Hardware-in-the-Loopエミュレーションでは AllReduceとAllToAllの混在がDCQCN輻輳制御を介して相互性能劣化を起こす現象を発見した。vLLM v1統合によりMoEトークンルーティングの不均衡、KVキャッシュオフロード時のMemcpy DtoH増大(387回・0.895ms→5,958回・216.484ms)、Prefill-Decode分離間のper-layer KV転送レイテンシ(Send約143〜187µs、Recv約108〜145µs)も定量化した。 - Open questions: NPUごとに独立したトレースファイルという設計がグローバルスケジューリングの機会を制限する点の解消策。ギガバイト単位に達する大規模トレースの無損失圧縮・階層インデックス方式。Hardware-in-the-Loop実験の大部分がproprietary性を理由に数値非公開であること(本noteでは発表スライドの補足グラフで一部を補完)。 ### 2026-07-18 | ingest-paper | ContextPilot: Fast Long-Context Inference via Context Reuse (MLSys 2026, arXiv 2511.03475) - Focus: [[@2026__MLSys2026__ContextPilot - Fast Long-Context Inference via Context Reuse]] - Key concepts: [[KVキャッシュ管理]](更新) - Key entities: [[ContextPilot]](新規)、[[University of Edinburgh]]・[[LMCache]]・[[CacheBlend]]・[[Mem0]](更新) - Key insight: University of Edinburgh の Yinsicheng Jiang・Luo Mai らによる MLSys 2026 Oral 論文。既存の KV キャッシュ再利用手法が「完全一致(RadixCache/LMCache)による低い再利用率」か「近似 KV マッチング(CacheBlend)による9〜11%の精度劣化」の二択だった問題を、KV 値ではなく検索文書・メモリ等の**コンテキストブロックのレベル**で整列(alignment)・重複排除(de-duplication)・優先順位注釈(annotation)を行うことで回避。整列由来の精度低下はわずか0.1〜3.3%で、注釈がそれをほぼ回復・時に上回る(multi-hop で+0.3〜3.9%)。MultihopRAG/NarrativeQA/QASPER/MT-RAG で最先端手法比1.5〜3倍のプリフィルスループット向上、DeepSeek-R1(671B, 32×H20)でキャッシュヒット率5%→60%、実運用エージェント(OpenClaw on RTX 5090)でプリフィルレイテンシ−63.6%、エッジ(M3 MacBook Air)で2.41倍のレイテンシ削減を報告。CacheBlend 自身の精度劣化報告(F1/Rouge-Lで0.01〜0.03)と ContextPilot の観測値(9〜11%劣化)が食い違う点を contradiction として記録した。 - Open questions: 距離関数のハイパーパラメータ α=0.001 固定の感度分析が未実施。コンテキスト重複率が低いワークロードでの効果限界。CacheBlend との精度劣化評価の食い違いの原因(評価条件差)を要検証。 ### 2026-07-17 | ingest | Deploying DeepSeek with PD Disaggregation and Large-Scale Expert Parallelism on 96 H100 GPUs (LMSYS Blog, 2025-05-05) - Focus: [[@2025__LMSYS Blog__Deploying DeepSeek with PD Disaggregation and Large-Scale Expert Parallelism on 96 H100 GPUs]] - Key concepts: [[Prefill-Decode分離]]・[[Mixture-of-Experts]]・[[並列化戦略]]・[[負荷分散]](いずれも更新) - Key entities: [[DeepGEMM]]・[[EPLB]](新規)、[[SGLang]]・[[DeepEP]]・[[DeepSeek-V3]]・[[LMSYS]](更新) - Key insight: SGLang チームが 96 台の H100 GPU で DeepSeek-V3 級モデルを PD Disaggregation + 大規模 Expert Parallelism により配備し、DeepSeek 公式ブログの報告値にオープンソース実装として初めて接近(TP16 比 Prefill 最大 3.3 倍・Decode 最大 5.2 倍、公式比 Prefill 94%・Decode は半分のノード数でほぼ同等)。密な FFN 層で TP でなく DP を選ぶ理由が中間次元 18,432 の TP32 アラインメント非対応というハードウェア制約にあること、DeepEP の Normal/Low-Latency Dispatch を PD 分離で使い分けること、EPLB(冗長エキスパート配置)がスループットを Prefill 1.49 倍・Decode 2.54 倍向上させることを記録。DeepGEMM(連続レイアウト/マスク形式)・Two-batch Overlap(ピークメモリ 50% 削減)・DisposableTensor も実装詳細として追加。 - Open questions: TTFT 2〜5 秒・ITL 約 100ms のレイテンシ最適化余地、MTP と DP Attention の完全統合欠如、EPLB の分布シフトへの未対応、Blackwell 世代への拡張。 ### 2026-07-17 | ingest-paper (update) | Machine Learning Fleet Efficiency: Improving TPU Systems at Scale with ML Productivity Goodput (arXiv 2502.06982 + MLSys 2026 スライド) - Focus: [[@2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput]] - Key concepts: [[ML Productivity Goodput]](更新) - Key entities: 変更なし([[Google]]・[[Arissa Wongpanich]]・[[Vijay Janapa Reddi]]・[[Harvard University]]) - Key insight: 初回取り込み(2026-07-02)時は OpenReview の Cloudflare 保護で本文 PDF を取得できずスライドのみが出典だったが、今回 arXiv 版(2502.06982)を発見し論文全文を取得。Program Goodput の predicted step time が HLO グラフの静的解析(コンパイラー決定に非依存)で導出されると判明し、通信計算オーバーラップで 1024 TPU チップ・500B パラメータ LLM のスループット 1.38 倍・FLOPS 利用率 72% を達成した具体例、XTAT オートチューナー(150 モデルで評価)等を追加。論文の埋め込み図とスライドの独自図解(roofline vs フュージョン、ランタイム最適化 4 施策の統合図等)を計 7 枚 source ページに埋め込んだ。 - Open questions: MPG の Borg/TPU 固有部分と GPU 等の他 DSA フリートへの移植可能性(著者は「広く適用可能」と主張するが検証実験なし)。predicted time の静的解析が MoE 等の動的分岐をどこまで正確にモデル化できるか。 ### 2026-07-17 | ingest-paper | A New Golden Age for Computer Architecture (CACM, 2019年2月) - Focus: [[@2019__CACM__A New Golden Age for Computer Architecture]] - Key concepts: [[ドメイン固有アーキテクチャ]](新規)、[[ムーアの法則とデナードスケーリングの終焉]](新規)、[[VLIW]]・[[メモリウォール]](更新) - Key entities: [[John L. Hennessy]]・[[RISC-V]](新規)、[[David A. Patterson]]・[[Google]](更新) - Key insight: John L. Hennessy と David A. Patterson による2017年 ACM Turing Lecture の CACM 掲載版。IBM System/360からRISC-Vまでの ISA 史を著者ら自身がRISC-I/MIPS開発当事者だった立場から回顧し、Moore の法則・Dennard スケーリングの終焉により汎用プロセッサの性能向上率がCISC期22%/年→RISC期52%/年→マルチコア期23%/年→Amdahl期12%/年→予測3%/年へと段階的に低下したと定量分析。ドメイン固有アーキテクチャ(Google TPU v1が汎用CPU比29倍高速・80倍超のエネルギー効率)・オープンISA(RISC-V、base 50命令+標準拡張で計137命令とARMv8の500命令超より大幅に単純)・アジャイルハードウェア開発の3つを次の黄金時代の道筋として提示した。既存の[[VLIW]](Itanium/EPICの失敗経緯)・[[メモリウォール]](投機実行の無駄が平均19%という定量データ)概念に、具体的な歴史的エピソードと数値的裏付けを補う形で接続した。 - Open questions: DSAが高効率を実現する4要因(並列性・メモリ階層・精度・DSL)はTPU以外のDSA(GPU・FPGA)でどこまで定量的に裏付けられるか。2019年の性能予測(「End of the Line」年率3%)はその後の実測データでどこまで成立しているか。 ### 2026-07-16 | ingest-slides | LLM高速化(勉強会) (SpeakerDeck, 全50ページ) - Focus: [[@2026__SpeakerDeck__LLM高速化(勉強会)]] - Key concepts: [[PagedAttention]](新規)、[[Speculative Decoding]](新規)、[[CUDAGraph]](新規)、[[KVキャッシュ管理]]・[[FlashAttention]]・[[Grouped-Query Attention]]・[[Multi-Head Latent Attention]]・[[線形注意]]・[[スライディングウィンドウアテンション]]・[[Prefill-Decode分離]]・[[GPU最適化]]・[[カーネルフュージョン]]・[[混合精度訓練]](いずれも更新) - Key entities: [[SuperHotDog]](新規)、[[vLLM]](更新) - Key insight: LLM 推論高速化の勉強会資料(全50ページ)。KVCache・FlashAttention・Super Sequence + Continual Batching・PagedAttention・Speculative Decoding のアルゴリズム的高速化から、CUDA/Triton/CuTe による実装、GQA・MLA・Sliding Attention・Linear Attention のアーキテクチャ的工夫、量子化(Mixed Precision Accumulation・Ozaki Scheme)、Nsight Compute/Systems、CUDAGraph、vLLM の内部構造(Scheduler・KVCacheScheduler・ModelExecutor)とコントリビュート方法までを一気通貫で扱う。Qwen2.5-0.5B-Instruct のハンズオンで Transformers 推論(5.97 tokens/sec)から vLLM 推論(94.84 tokens/sec)への 15.88 倍高速化を実演し、KVCache サイズの見積もり式(192 GiB に達する具体例)や MLA の low-rank 圧縮による計算量 3/8・KVCache 容量 1/8 への削減など、既存の学術的 concept ページに定量的な計算例を補う形で接続した。 - Open questions: 発表者の所属組織(GMO ペパボのロゴがスライドに表示されるが未確定)。公開日時が未確定(年のみ推定)。「LLM Serving を支える技術」というブログ記事の詳細な出典確認、Gemma4 の MTP の詳細。 ### 2026-07-16 | ingest | ISC26 Recap (Glenn K. Lockwood Blog, 2026-07) - Focus: [[@2026__Glenn K. Lockwood Blog__ISC26 Recap]] - Key concepts: [[主権AI]](新規)、[[ヨーロッパのAI主権]](更新) - Key entities: [[LineShine]]・[[Top500]]・[[IO500]]・[[Sugon]]・[[ParaStor F9000]]・[[Yutong Lu]]・[[James Lin]]・[[Weicheng Huang]](いずれも新規)、[[Glenn K. Lockwood]]・[[Lustre]]・[[Shanghai Jiao Tong University]](更新) - Key insight: 2026年ISC High Performance Conferenceの参加記。中国の全CPU(Arm)スパコン[[LineShine]]がGPUを一切使わずTop500首位を獲得し、SugonのParaStor F9000もIO500でArgonneのDAOSを性能面で上回るなど、計算・ストレージ両面で中国製HPCスタックが世界最高水準に達しつつあることが示された。同時に、2026年6月12日の米国政府によるAnthropicモデル(Fable 5・Mythos 5)への外国人アクセス遮断が、欧州に限らず英国・カナダ・アジア太平洋を含む世界的な主権AIインフラ投資の引き金になったと報告する。AI推論のメモリ帯域幅問題はハードウェアではなくアルゴリズム進歩(投機的デコード・PagedAttention・FlashAttention-2・prefill/decode分離)で解決されてきたという主張、および「AI for productivity」と「AI for science」を区別すべきという論点も横断的知見として記録した。 - Open questions: 主権AIインフラが実際に「緊急時の代替能力」としてどこまで機能するかは未検証。米国自身がGenesis Missionのような不十分な資金・構造にとどまる理由は他ソースでの検証が必要。 ### 2026-07-16 | ingest-paper | AI 2040: Plan A — The Deal (AI Futures Project, 2026) - Focus: [[@2026__AI Futures Project__AI 2040 - Plan A - The Deal]] - Key concepts: [[AI国際検証レジーム]](新規)、[[権力集中リスク]](新規)、[[知能爆発]](更新)、[[テイクオフ速度論争]](更新) - Key entities: [[AI Futures Project]]・[[Daniel Kokotajlo]](新規) - Key insight: [[AI Futures Project]](「AI 2027」の著者チーム)が発表した90ページの政策シナリオ文書。誤整合による乗っ取りとは独立した「権力集中リスク」を軸に、研究の完全透明化・コンピュート宣言・訓練一時停止・相互確証コンピュート破壊(MACD)からなる国際検証レジーム「Plan A」で超知能到達を2030年代から2040年まで先送りする成功シナリオを提示。既定路線(2030年に完全自動化されたAI研究開発から年内に超知能へ)というハードテイクオフ的前提を、ガバナンスによって10年間へ人為的に引き延ばすという「テイクオフ速度を政策的制御変数として扱う」視点を、[[知能爆発]]・[[テイクオフ速度論争]]という既存の理論的概念に新たに接続した。代替プランB/C/D/Sの評価、中国の秘密裏AGI計画の検知確率分析(Appendix D)、著者ら自身の卓上演習で繰り返し再現された最悪の失敗モード(Appendix L)など、提案の脆弱性を自己批判的に開示する構成が特徴。 - Open questions: 推論限定検証・AI嘘発見器等、Plan Aが依存する検証技術群が実証済みかどうかは本文からは確認できない。核抑止のMAD理論の知見(検証非対称性・エスカレーション動学)がAIのコンピュート検証にどこまで転用可能かは未検証。誤整合リスクと権力集中リスクに共通して効く対策と、一方にしか効かない対策の切り分けは他ソースとの突き合わせが必要。 ### 2026-07-15 | ingest-paper | Scalable and Energy-Efficient AI: System-Level Profiling of NVIDIA GPU Clusters for Distributed LLM Training (AI, MDPI, 2026-06-23) - Focus: [[@2026__AI__Scalable and Energy-Efficient AI - System-Level Profiling of NVIDIA GPU Clusters for Distributed LLM Training]] - Key concepts: [[GPUエネルギー効率]](新規) - Key entities: [[Muhammad Ali Shafique]]・[[Imran Latif]]・[[Hayat Ullah]]・[[Alex C. Newkirk]]・[[Arslan Munir]](新規、[[Kansas State University]]・[[Johnson Controls]]・[[Florida Atlantic University]]・[[Lawrence Berkeley National Laboratory]]) - Key insight: シングルノード8×H100と8×B200を、5種のLLM(7B〜32B)・3種のVLMのDDP訓練で統制比較した実証研究。B200はGPU利用率1〜6%向上・訓練時間最大15%短縮・TFLOPs/GPU最大32%向上を達成するが、TFLOPs/kWとtokens-per-kilojouleは全LLMでH100を下回り、「計算-エネルギー不整合(compute-energy misalignment)」を実測で提示した。VLMでは軽量カーネル依存のX-CLIP/EVLがB200で不利になる一方、演算密度の高いVita-CLIPはB200で約2倍高速・低エネルギーとなる例外を示す。施設規模モデリングでは、中負荷2000ノードで年間+$0.62M、高負荷5000ノードで+$4.26Mのエネルギーコスト超過がB200に生じる。同日以前にingestした [[@2026__IPDPS__Beyond Throughput - Performance and Energy Insights of LLM Inference Across AI Accelerators]](推論フェーズ)と合わせ、「スループット優位はエネルギー効率優位を意味しない」という命題が訓練・推論の両フェーズで独立に裏付けられた。 - Open questions: power-capped構成でB200のtokens-per-kilojouleはどこまで改善しうるか(訓練スループットとのトレードオフ未評価)。FSDP/ZeRO等のマルチノードシャーディング下でのエネルギー効率動向は未測定。施設規模PUE改善はシナリオ仮定にとどまり実測検証が必要。 ### 2026-07-15 | ingest-paper | Can Large Language Models Generate Observability-Aware Code? (arXiv, 2026-07-07) - Focus: [[@2026__arXiv__Can Large Language Models Generate Observability-Aware Code?]] - Key concepts: [[オブザーバビリティ]](更新)、[[コーディングエージェント評価]](更新)、[[ログ生成]](更新)、[[障害注入]](更新)、[[バイブコーディング]](更新) - Key entities: [[Yongliang Tao]]・[[Pengfei Gao]]・[[Zhiyu Fan]]・[[Jue Zhang]](新規)、[[Hongyu Zhang]]・[[Chongqing University]]・[[Minghua Ma]]・[[Qingwei Lin]]・[[Saravan Rajmohan]]・[[Si Qin]]・[[Liqun Li]]・[[Yu Kang]]・[[Microsoft]](更新) - Key insight: コーディングエージェント生成コードのオブザーバビリティを、ソースレベルの診断意味論復元(18 リポジトリ 1,223 インスタンス、Position F1・KeyBag F1)と、実行時の障害シグナル露出(200 個の agent 生成マイクロサービス・Kubernetes 上に 13 種の Chaos Mesh 障害を注入、1,615 件、Fault Signals Rate 4.95〜13.99%)の 2 軸で実証。エージェントは「どこに計装するか」より「何を記録するか」の再現が一貫して弱く、explicit instruction は生成量を倍増させるが precision を犠牲にする Quantity over Quality 現象を確認。約 200 件の実失敗修復コミットから抽出した軽量 observability skill は FSR・Position F1・KeyBag F1 を改善するが効果は限定的。「ログは大量にあるが障害固有の意味論を欠く」という現象を FSR という保守的指標で初めて定量化した。 - Open questions: エージェントの「診断意味論の生成能力」不足は訓練データの性質に起因するのか、実行時フィードバックの欠如に起因するのか(論文は 2 つの仮説を提示するが未検証)。ランタイムフィードバックや障害伝播シミュレーションを生成プロセスに統合すると KeyBag F1・FSR はどこまで改善するか。 ### 2026-07-15 | ingest-paper | Speculations Concerning the First Ultraintelligent Machine (Advances in Computers, 1965) - Focus: [[@1965__AdvComput__Speculations Concerning the First Ultraintelligent Machine]] - Key concepts: [[知能爆発]](更新、原論文出典を追加)、[[Recursive Self-Improvement]](更新、起源論文を出典に追加) - Key entities: [[I. J. Good]](更新、一次論文本体を追加し「未ingest」注記を解消) - Key insight: [[I. J. Good]] が「知能爆発(intelligence explosion)」を初めて明示的に定式化した1965年の原論文。あらゆる知的活動で人間を凌駕する「ウルトラ知能機械」は機械設計自体を含む知的活動で人間を上回るがゆえに自らより優れた後継機械を設計でき、それゆえ「初のウルトラ知能機械は人類が行う必要のある最後の発明である——ただし機械が人間の制御下に留まるよう従順であるという条件のもとで」と論じる。本体の大半(Section 3–8)は、Hebb の細胞集成体理論を修正した「サブアセンブリ理論」により通信理論の「再生」・統計的情報検索・意味論を統一的に説明しようとする神経科学的な思弁に割かれ、実験は伴わない。原論文における知能爆発の議論自体は数段落にとどまり、機構的な詳細は同日ingestの [[@2008__LessWrong__Recursive Self-Improvement]](Yudkowsky, 2008)が43年後に埋めている、という役割分担が [[知能爆発]] の横断的知見として記録された。 - Open questions: Good(1965)の「20世紀中にウルトラ知能機械が構築される」という予測が外れたことが、後年のテイクオフ速度論争の時間軸見積りにどう影響したかは未追跡。Good が条件として挙げた機械の「従順性」をどう担保するかについて、後続の安全性研究がどう埋めたかは未調査。 ### 2026-07-15 | ingest | Recursive Self-Improvement (LessWrong, 2008-12-01) - Focus: [[@2008__LessWrong__Recursive Self-Improvement]] - Key concepts: [[知能爆発]](新規)、[[テイクオフ速度論争]](新規)、[[リソースオーバーハング]](新規)、[[Recursive Self-Improvement]](更新、2008年の原論証を追記) - Key entities: [[Eliezer Yudkowsky]](新規)、[[Robin Hanson]](新規)、[[I. J. Good]](新規) - Key insight: Yudkowsky が2008年に提示した「AI go FOOM」論の原論証。因果を5層(metacognitive/cognitive/metaknowledge/knowledge/object level)に分解し、AIが自身の記憶検索アルゴリズムを改善する課題を与えられた瞬間にmetacognitive層とobject層が同一化する現象を「真の再帰」と定義。「自分のソースコードを直接書き換えること」と「農業を発明すること」を明確に区別すべきとし、複雑な最適化連鎖を再帰で自己に畳み込むと理論上「横ばいか爆発かのどちらか」になるはずで、ソフトテイクオフには「正確に都合の良い収穫逓減則」という狭い条件が必要と主張する。同日ingestの [[@2026__Lil'Log__Harness Engineering for Self-Improvement]] が報告するハーネスレベルの間接的RSIとの対比が [[Recursive Self-Improvement]] の横断的知見として記録された。 - Open questions: Yudkowsky (2008) の「横ばいか爆発か」という二値的予測は、2026年時点で観測されているハーネスレベルの漸進的自己改善(Meta-Harness・Self-Harness・AHE)とどう整合するか。[[Robin Hanson]] が問題視した「局所性」の論点への Yudkowsky の直接的応答は本ソースのシリーズ続編に持ち越されており未確認。 ### 2026-07-15 | ingest | Harness Engineering for Self-Improvement (Lil'Log, 2026-07-04) - Focus: [[@2026__Lil'Log__Harness Engineering for Self-Improvement]] - Key concepts: [[Recursive Self-Improvement]](新規)、[[ハーネス自己進化]](新規)、[[進化的探索によるエージェント設計]](新規)、[[Harness Engineering]](更新、RSI文脈での学術的体系化を追記)、[[コンテキストエンジニアリング]](更新、ACE/MCEを追記) - Key entities: [[Lilian Weng]](新規)、[[Andrej Karpathy]](更新、autoresearchリポジトリへの言及) - Key insight: 再帰的自己改善(RSI)の近未来的経路を、モデル重みの直接書き換えではなく訓練パイプラインとデプロイシステム(ハーネス)の改善による間接的ループと位置づけ、既存の実務ブログ知見(OpenAI・Anthropic)をACE/MCE(コンテキストのプレイブック化)・Meta-Harness/Self-Harness/AHE(ハーネスコード自体の自己進化)・ADAS/AFlow/AlphaEvolve(進化的探索)という3系統の学術研究に接続する統一レビュー。STOP(2023)の「弱いモデルでは再帰改善が劣化する」という知見が2026年の各手法でも暗黙の前提となっている点を横断的知見として記録。 - Open questions: harness-updating(モデルサイズに対し平坦)とharness-benefit(中位モデルが最も恩恵)の分離という Lin et al. (2026) の知見は、ハーネス設計の対象読者を「最強モデル」ではなく「中位モデル」に置くべきという含意を持つか。ACE・MCEのような自動コンテキスト管理と、ハーネス自己進化が扱うハーネスコード自体の自己改善は、どこまで同じ最適化階層に統合されうるか。 ### 2026-07-15 | ingest-paper | The Anatomy of a Large-Scale Hypertextual Web Search Engine (Computer Networks, 1998) - Focus: [[@1998__Computer Networks__The Anatomy of a Large-Scale Hypertextual Web Search Engine]] - Key concepts: [[PageRank]](新規) - Key entities: [[Sergey Brin]]・[[Lawrence Page]](新規、[[Stanford University]])、[[Google]](更新、検索エンジンとしての創業論文を追記) - Key insight: Google の検索エンジンプロトタイプ(2,400万ページ)を報告する1998年の創業論文。リンク構造由来のPageRank(`PR(A)=(1-d)+d·ΣPR(Ti)/C(Ti)`、ランダムサーファーモデル)とアンカーテキストのリンク先索引化(クロール不能な画像・DB文書も検索可能にする)を核とし、ディスクシーク回避を設計原則としたクローラ/インデクサ/ソータ/サーチャのアーキテクチャで2,400万ページを1週間未満で索引化した実測(圧縮リポジトリ53.5GB・完全転置索引37.2GB・合計108.7GB)を報告する。本 wiki に情報検索・ランキング分野の起点を導入する初のソース。 - Open questions: PageRankのダンピング係数d=0.85の根拠(感度分析)は短縮版に含まれず、参考文献[7]の長編マニュスクリプトにあたる必要がある。本 wiki 既存のランキング手法群([[アラートランキング]]・[[LLMランキング]]・[[pairwiseランキング]])とPageRankのグラフ伝播的発想との関係は未整理。 ### 2026-07-14 | ingest-slides | 言語モデルの内部機序：解析と解釈 (NLP2025 チュートリアル, 2025-03-10) - Focus: [[@2025__SpeakerDeck__言語モデルの内部機序：解析と解釈]] - Key concepts: [[機構的解釈性]](更新)、[[プラトン的表現仮説]](更新)、[[モデル表現収束]](更新)、[[ロジットレンズ]](更新)、[[帰納ヘッド]](更新)、[[アテンションヘッド]](更新)、[[SAE]](新規)、[[活性化パッチング]](新規)、[[言語モデルのプロービング]](新規) - Key entities: [[Benjamin Heinzerling]]・[[横井祥]]・[[小林悟郎]](新規、[[理化学研究所]]・[[東北大学]]・[[国立国語研究所]])、[[Anthropic]](更新、ゴールデンゲートブリッジ特徴) - Key insight: 言語モデルの内部機序理解を「内部表現の解析→計算過程の解析→言語・世界・知識との対応づけ(解釈)」の3段階フレームワークで整理した上で、その基盤にある「局所性・一対一対応」という仮定自体をSAEのfeature absorption・複数の等価な回路・複数の実際の計算メカニズムの共存という反例で掘り崩す、方法論への内省まで踏み込むチュートリアル。ゴールデンゲートブリッジ特徴・時間軸方向操作という成功例と、ワットの調速機のような「表現と計算」という見方自体への懐疑を両論併記する構成が特徴。 - Open questions: feature absorptionのようなSAEの局所性の破れは、ハイパーパラメータ調整でどこまで緩和できるか。「解釈は誰のためか」というステークホルダー論は解析手法の選択にどう反映されるべきか。 ### 2026-07-14 | ingest-paper | OpenRCA 2.0: From Outcome Labels to Causal Process Supervision (arXiv, 2026) - Focus: [[@2026__arXiv__OpenRCA 2.0 - From Outcome Labels to Causal Process Supervision]] - Key concepts: [[RCA評価設計]](更新)、[[因果発見]](更新)、[[障害注入]](更新)、[[根本原因分析]] - Key entities: [[Aoyang Fang]]・[[Pinjia He]]・[[Junjielong Xu]](更新、[[The Chinese University of Hong Kong, Shenzhen]])、[[Yifan Yang]]・[[Jin'ao Shang]]・[[Qisheng Lu]]・[[Rui Wang]]・[[Songhan Zhang]]・[[Yuzhong Zhang]]・[[Boxi Yu]](新規)、[[OpenRCA]](更新、v1 との対比を追記) - Key insight: 障害注入の既知介入 do(v_root) を使う段階的因果ラベリング PAVE により、根本原因ラベルのみだった既存 RCA ベンチマークを「検証済みの因果伝播経路」まで持つ形に拡張。11 の最先端 LLM で AnySvc(76.0%)と Path Reachability(61.5%)の 14.5pp ギャップを「grounding されていない診断(ungrounded diagnosis)」と定義し、outcome-only 評価が隠す失敗モードを人手ラベル/LLM judge なしに定量化した。Edge F1(43.4%)が Node F1(62.2%)を全モデルで下回ることも示す。 - Open questions: PAVE の段階的因果 ground truth を制限テレメトリ(サブサンプル・欠落モダリティ)下でのエージェント評価へ転用する設計は未着手。Path Reachability と Node/Edge F1 の中間にあたる「部分的に正しい経路」の段階的採点指標は未定義。 ### 2026-07-14 | ingest-paper | A Survey of DevOps Concepts and Challenges (ACM Computing Surveys, 2019) - Focus: [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges]] - Key concepts: [[DevOps]](更新) - Key entities: [[Leonardo Leite]]・[[Carla Rocha]]・[[Fabio Kon]]・[[Paulo Meirelles]](新規)、[[Dejan Milojicic]](更新、[[Hewlett Packard Labs]])、[[University of São Paulo]]・[[University of Brasília]]・[[Federal University of São Paulo]](新規、organization) - Key insight: 2019年の学術サーベイ(Leite et al., ACM CSUR)は、DevOps運動が10年近く議論されながら広く合意された定義を欠くと明記し、Grounded Theory的手法でprocess/people/delivery/runtimeの4カテゴリからなるconceptual frameworkを構築、既存DevOps SLR群がdelivery/runtime(技術的含意)を軽視していたことを指摘した。GoogleのSite Reliability Engineeringも運用エンジニア役割の進化形として2019年時点で既にDevOps文献に組み込まれていたことが確認できる。 - Open questions: 2010年代のアカデミック文献における文化面重視と、2020年代の実務側でのAutomation偏重(mizzy 2026)という非対称性の背景は何か。DevOpsツール7カテゴリの分類は現代のプラットフォームエンジニアリング/SREツールチェーンにどう対応づけられるか。 ### 2026-07-14 | ingest | The Origins of DevOps: What's in a Name? (devops.com, 2018-01-25) - Focus: [[@2018__devops.com__The Origins of DevOps - What's in a Name]] - Key concepts: [[DevOps]](更新) - Key entities: [[Paul Hammond]](新規)、[[Gene Kim]](新規)、[[Kevin Behr]](新規)、[[George Spafford]](新規)、[[Patrick Debois]](更新)、[[Andrew Clay Shafer]](更新)、[[John Allspaw]](更新) - Key insight: DevOpsの起源(Agile Infrastructure BoF・Velocity 2009 Flickr発表・Devopsdays創設)に関する事実関係が、[[@2026__mizzy.org__DevOpsとは何だったのか]] と独立ソースで一致することを確認。2013年の『The Phoenix Project』(Gene Kim・Kevin Behr・George Spafford)がビジネス小説という形でDevOps概念を一般に普及させた経路を補足する。 - Open questions: Andrew Clay Shafer / Andrew Schafer の表記揺れが同一人物を指すという確認以上に、両ソース間で解消すべき矛盾は見つからなかった。 ### 2026-07-14 | ingest | DevOpsとは何だったのか (mizzy.org, 2026-07-13) - Focus: [[@2026__mizzy.org__DevOpsとは何だったのか]] - Key concepts: [[DevOps]](新規), [[SRE]], [[DORA]], [[プラットフォームエンジニアリング]], [[ChatOps]] - Key entities: [[Gosuke Miyashita]](新規、mizzy)、[[Patrick Debois]](新規)、[[John Willis]](新規)、[[Andrew Clay Shafer]](新規)、[[John Allspaw]](更新) - Key insight: DevOps は元々「開発部門と運用部門という組織の分断を解消する文化運動」だったが、CAMSのAutomation偏重・ツール名・職種名として消費されていき、Infrastructure as Code・CI/CD・DORA・ChatOpsという独立領域へ分解された(2025年のDORA改称が象徴的)。「class SRE implements DevOps」という定式化も、同じ「文化→職種・技術レイヤーへの縮約」をSREで反復する危険を持つ。 - Open questions: DevSecOps・Platform Engineeringのように分岐が続く現象は組織的分断が未解決な証拠か、自然な専門分化か。SREという語についても同じ縮約を防ぐための語彙・実践は何か。 ### 2026-07-13 | ingest-paper | Bridging Edge and Cloud: A Knowledge-Enhanced Framework for Efficient Time Series Anomaly Detection (IEEE TSC 2025) - Focus: [[@2025__TSC__Bridging Edge and Cloud - A Knowledge-Enhanced Framework for Efficient Time Series Anomaly Detection]] - Key concepts: [[異常検知]], [[知識蒸留]], [[モデル圧縮]], [[Edge-cloud Collaboration]] - Key entities: Shenglin Zhang、[[Yongqian Sun]]、[[Dan Pei]]（[[Nankai University]] / [[Alibaba Cloud]]）、[[RefinedEdge]]（新規、product） - Key insight: RefinedEdge は多変量時系列異常検知モデルをエッジ配置可能な水準(0.15Mパラメータ未満)まで圧縮しつつ、クラウド訓練の大型モデル(7Mパラメータ)に匹敵・凌駕する精度を Aggregated Compression + Knowledge Refinement で達成し、概念ドリフトのあるデータセットでのみ Reciprocal Edge-Cloud Updating が有意な改善をもたらすことを示した。 - Open questions: λkd のバランス係数の最適な決定方法が一般化するか。概念ドリフト検知自体のコストとReciprocal Updatingの効果のトレードオフ。 ### 2026-07-13 | ingest-paper | From Chaos to Clarity: Log-based Kernel Panic Root Cause Analysis for Large-Scale Cloud Services (FCS 2025) - Focus: [[@2025__FCS__From Chaos to Clarity - Log-based Kernel Panic Root Cause Analysis for Large-Scale Cloud Services]] - Key concepts: [[ログ解析]], [[根本原因分析]], [[グラフベースRCA]], [[LLMによる根本原因分析]] - Key entities: [[Tianyu Cui]]（新規、筆頭著者）、[[Shenglin Zhang]]、[[Yongqian Sun]]（[[Nankai University]] / [[ByteDance]]） - Key insight: LogSage(通称)はカーネルパニック RCA を「スパースな障害指示ログ抽出」と「ログ間長距離依存」の2課題に分解し、ByteDance本番20,000件データでLogKGを15.5〜20.3pt F1上回り6ヶ月超本番デプロイされている。 - Open questions: カーネルパニック以外の障害種別への一般化可能性。GraphSAGEベースの類似度グラフとLLM要約の計算コストのトレードオフ。 ### 2026-07-13 | ingest-paper | A Comprehensive Benchmark and Empirical Study of Trace Anomaly Detection (IEEE TSC 2025) - Focus: [[@2025__TSC__A Comprehensive Benchmark and Empirical Study of Trace Anomaly Detection]] - Key concepts: [[トレース異常検知]]（新規）, [[分散トレーシング]], [[異常検知]] - Key entities: Yongqian Sun ほか（[[Nankai University]]）、[[Minyi Shao]]（新規） - Key insight: トレース異常検知には全データセット横断で一貫最良のアルゴリズムは存在せず、TADBenchはトレース深さ・スパン数・サービス数・異常比率の4特性から決定木でアルゴリズムを推奨する初の横断ベンチマークを提示した。 - Open questions: TADBenchの決定木がベンチマーク外の実運用トレースデータに一般化するか。VAE/GNN/LSTM以外の新規アーキテクチャ(LLMベース含む)の追加評価。 ### 2026-07-13 | ingest-paper | PerfScout: An Adaptive Workload Generator in Software Performance Testing (ICSE-SEIP '26) - Focus: [[@2026__ICSE-SEIP__PerfScout - An Adaptive Workload Generator in Software Performance Testing]] - Key concepts: [[定常性モデル]], [[適応的ワークロード生成]]（新規） - Key entities: [[Yongqian Sun]]、[[Shenglin Zhang]]（[[Nankai University]] / [[BizSeer]] / [[Huawei Cloud]]）、[[Qingliang Zhang]]（新規） - Key insight: PerfScout は SPOT(極値理論)・ADF/KPSS(局所定常性判定)・PPO(強化学習)の3モジュールを統合し性能テストのワークロード生成を全自動化するフレームワークで、Huawei Cloudに9か月間本番デプロイされ、全ベースラインを調和平均(HM)で上回り代表ケースで87%のテスト時間短縮を実証した。 - Open questions: 定常性判定の閾値設定が異なる性能テスト対象システムに一般化するか。PPO学習の収束コストと本番運用での再学習頻度のトレードオフ。 ### 2026-07-13 | ingest-paper | When LLMs Listen to Experts: Accurate Failure Diagnosis in Operating Systems (ICSE-SEIP '26) - Focus: [[@2026__ICSE-SEIP__When LLMs Listen to Experts - Accurate Failure Diagnosis in Operating Systems]] - Key concepts: [[TSG自動化]], [[マルチモーダル障害診断]] - Key entities: [[OScope]]（新規、product）、[[Yongxin Zhao]]（新規、筆頭著者）、[[Yongqian Sun]]、[[Shenglin Zhang]]（[[Nankai University]] / [[Alibaba Group]]） - Key insight: OScope は症状記述の意味的不整合(TSG 検索精度 AC@5 0.75→0.9)を独立ファインチューニング済み Knowledge Aligner で解消し、SOP ガイドのチャンク逐次検証(Report Validator)と組み合わせて Alibaba 本番 OS 障害診断で AC@5=0.901・平均診断時間を112分→1.5分に短縮した。 - Open questions: OS障害診断の知見がミドルウェア・アプリケーション層の障害診断に一般化するか。Knowledge Alignerのファインチューニングデータ収集コストの継続的な運用負荷。 ### 2026-07-13 | ingest-paper | Aloha: Localizing Batch Failures in Large-scale Cloud Systems via Contrast Analysis and Human-in-the-Loop Agent (FSE Companion '26) - Focus: [[@2026__FSE Companion__Aloha - Localizing Batch Failures in Large-scale Cloud Systems via Contrast Analysis and Human-in-the-Loop Agent]] - Key concepts: [[バッチ障害診断]]（新規）, [[Fault Localization]] - Key entities: Shenglin Zhang、[[Yujia Wu]]（新規）、[[Jinghuan Ren]]（新規）（[[Nankai University]] / [[Microsoft]]） - Key insight: Aloha(FSE Companion '26)は対照分析ベースのバッチ障害診断で「アルゴリズムでなく usability gap が実務障壁」と指摘し、FTA由来の適格性判定・実行可能検証ツールキット・RAGベース戦略選択をhuman-in-the-loopで統合してCONANをACC@5で0.9370対0.6963、診断時間を約10時間から約0.5時間に短縮した。 - Open questions: 長期運用でのhuman-in-the-loop過信リスクの実測。usability gap解消度の定量測定方法。ドメイン一般化可能性(バッチ障害以外のクラウド障害への適用)。 ### 2026-07-13 | ingest-paper | FoundRoot: Towards Foundation Model for Root Cause Analysis via Structured Deep Thinking (ICSE '26) - Focus: [[@2026__ICSE__FoundRoot - Towards Foundation Model for Root Cause Analysis via Structured Deep Thinking]] - Key concepts: [[構造化深層思考]]（新規）, [[根本原因分析]], [[LLMによる根本原因分析]], [[検証可能報酬による強化学習]] - Key entities: [[Zhe Xie]]、[[Yuzhuo Yang]]（新規）（[[Tsinghua University]] / [[ByteDance]] / [[Nankai University]]） - Key insight: FoundRoot は構造化深層思考(メトリクススキャン→伝播分析→リフレクション→ランキング)を warm-up SFT + DAPO で LLM に内在化させることで、プロンプトのみの分解(w/ Workflow)や RL 抜きの構造化(SFT Only/SFT+SFT)を上回り、ゼロショット RCA 4 データセット全てで MRR 4.5%〜48.6% 改善した。 - Open questions: 報酬式の重みパラメータ表記揺れ(λ_format/λ_json/λ_acc/λ_think と λ_struct/λ_mrr/λ_stf)の解消。構造化深層思考の4段階が他の診断タスク(性能診断・容量計画等)に一般化するか。 ### 2026-07-13 | ingest-paper | LLM-Assisted Joint Ticket and Log Analysis for Incident Triage in Intelligent and Connected Vehicles (ASE'26投稿版) - Focus: [[@2026__ASE__LLM-Assisted Joint Ticket and Log Analysis for Incident Triage in Intelligent and Connected Vehicles]] - Key concepts: [[インシデントトリアージ]], [[オンコール自動化]] - Key entities: [[Ruowei Fu]]、[[Shenglin Zhang]]（[[Nankai University]]）、[[Weiguo Li]]（新規） - Key insight: 同じ Ruowei Fu / Shenglin Zhang(Nankai University)の著者陣が ByteDance ドメイン(OncallX・CoTriage)に続き Huawei/ICV(車載)ドメインで InsightTriage を提案。LLM によるコンポーネント知識ベース自動構築+コントラスティブ学習ログ検索でログを一次証拠として扱う設計をアブレーション(ログ検索器除去で Weighted F1 が19.2%低下)で実証。 - Open questions: 車載ドメインとクラウドドメインのトリアージ設計の一般化可能性。CoTriage(知識蒸留)・OncallX(知識グラフ)・InsightTriage(ログ検索)の3路線の統合可能性。 ### 2026-07-13 | ingest-paper | Bridging the Delay: Lag-Aware Spatio-Temporal Causal Inference for Microservice Root Cause Analysis (FSE Companion '26) - Focus: [[@2026__FSE Companion__Bridging the Delay - Lag-Aware Spatio-Temporal Causal Inference for Microservice Root Cause Analysis]] - Key concepts: [[遅延認識時空間因果推論]]（新規）, [[因果推論ベースRCA]], [[Fault Localization]], [[根本原因分析]], [[グラフベースRCA]] - Key entities: [[Junhua Kuang]]（新規、筆頭著者）、[[Shenglin Zhang]]、[[Yongqian Sun]]、[[Dan Pei]]（[[Nankai University]] / [[Alibaba Group]] / [[Tsinghua University]]） - Key insight: マイクロサービス障害伝播は本番データで81.5%が非同期(2分以上の遅延)であり、この時間ラグを明示的にモデル化(スケルトン/強度分離+ラグ条件付きアテンション)することで同期集約前提の既存RCA手法を大きく上回れることをLagRCAが実証した。 - Open questions: 81.5%という非同期比率が他社・他規模のマイクロサービス環境に一般化するか。ラグ推定誤差がRCA精度に与える感度分析。AgentTether・PROBEのエージェント内部軌跡RCAとの統合可能性。 ### 2026-07-13 | ingest-paper | Can Language Models Go Beyond Coding? Assessing the Capability of Language Models to Build Real-World Systems - Focus: [[@2026__nkcs.iops.ai__Can Language Models Go Beyond Coding - Assessing the Capability of Language Models to Build Real-World Systems]] - Key concepts: [[クロスISAマイグレーション]]（新規）, [[自動ビルド修復]]（新規）, [[エージェント型コーディング]] - Key entities: [[Chenyu Zhao]]、[[Shenglin Zhang]]（[[Nankai University]]）、[[Build-bench]]（新規、product） - Key insight: エージェント型のツール利用・反復フィードバックなしでは GPT-5 の成功率は 6.13% にとどまるが、Build-bench の反復ループ環境下では 63.19%(10.3 倍)に到達し、クロス ISA ビルド修復は動的なツールオーケストレーションと検証可能なフィードバックループを要することを実証した。 - Open questions: Build-bench の268件というベンチマーク規模が実世界のビルド修復需要をどこまでカバーするか。テキストのみのフィードバックとエラーログ構造化フィードバックの効果比較。 ### 2026-07-13 | ingest-paper | Debugging the Debuggers: Failure-Anchored Structured Recovery for Software Engineering Agents (arXiv 2026) - Focus: [[@2026__arXiv__Debugging the Debuggers - Failure-Anchored Structured Recovery for Software Engineering Agents]] - Key concepts: [[エージェント修復]], [[AIOpsLab]] - Key entities: [[Chenyu Zhao]]、[[Shenglin Zhang]]（[[Nankai University]]）、[[Yihang Lin]]（新規）、[[Zhimin Chen]]（新規） - Key insight: PROBE は診断精度改善(+43.58pt)が回復率改善(+12.45pt)を大きく上回る「diagnosis–recovery gap」を実証し、同著者グループの後続研究 AgentTether が観測したフィードバック遵守の急速な減衰と同一の構造的主張(正しい診断は実行可能な回復の必要条件だが十分条件ではない)に収斂する。 - Open questions: diagnosis-recovery gap を埋める設計(診断結果を回復戦略へどう翻訳するか)。PROBEとAgentTetherの評価ベンチマーク(AIOpsLab vs τ-bench)を揃えた直接比較。 ### 2026-07-13 | ingest-paper | Collaborative Knowledge Distillation and Reinforcement Learning for Automated Ticket Triage in Large-Scale Production Systems (TOSEM投稿版) - Focus: [[@2026__nkcs.iops.ai__Collaborative Knowledge Distillation and Reinforcement Learning for Automated Ticket Triage in Large-Scale Production Systems]] - Key concepts: [[知識蒸留]]（新規）, [[オンコール自動化]], [[インシデントトリアージ]] - Key entities: [[Ruowei Fu]]（[[ByteDance]] / [[Nankai University]])、[[Shenglin Zhang]]、[[Yang Zhang (ByteDance)]]（新規） - Key insight: 同一著者陣(Ruowei Fu・Shenglin Zhang、ByteDance STE チーム)が、先行研究 OncallX の知識グラフ拡張路線に続き、CoTriage で知識蒸留+自己強化+DPOによるSLMファインチューニングという対照的な路線を独立に本番デプロイしており、チケットトリアージには決定版アプローチがまだ定まっていないことを示す。 - Open questions: OncallX(知識グラフ)とCoTriage(知識蒸留)のどちらがコスト・精度トレードオフで優れるか直接比較。異なるチケットドメイン(セキュリティ・インフラ・アプリ)への一般化可能性。 ### 2026-07-13 | ingest-paper | Large Language Models Can Provide Accurate and Interpretable Incident Triage (ISSRE 2024) - Focus: [[@2024__ISSRE__Large Language Models Can Provide Accurate and Interpretable Incident Triage]] - Key concepts: [[インシデントトリアージ]]（新規）, [[インシデント管理]], [[インシデントTTM予測]] - Key entities: [[Zexin Wang]]（筆頭著者、[[Chinese Academy of Sciences]]）、[[Minghua Ma]]（corresponding author、[[Microsoft]]）、[[Ze Li]]（新規）、[[Jianhui Li]]（新規）、[[Chinese Academy of Sciences]]（新規） - Key insight: LLM(GPT-3.5/GPT-4)でログからキーワードを抽出し埋め込み類似検索でチームを推薦する COMET は、生ログ・議論の生テキストよりフィルタ済みログ(TrimmedLogs)が、さらに生成要約よりキーワードがトリアージ入力表現として優れることを比較実験で実証した。Microsoft の2大規模クラウドサービスに6ヶ月以上本番展開し、オンラインで ACC@1 を 0.47→0.61 に改善、TTM を35%短縮。ルールベース(AutoAnalysis)の出力は不正確でも LLM の補助入力として活用価値があるというアブレーション結果も得た。DOI版(IEEE Xplore)は有料壁の向こうのため、著者の Microsoft Research サイト直接公開PDFを原本として取り込んだ。 - Open questions: トリアージ精度改善によるTTM短縮効果と、LLM呼び出しレイテンシによる遅延増加の要因分解。ドメイン知識プロンプト(Table III)の導出プロセスの一般化可能性。2023年以降のLLMベースRCA手法との直接比較。 ### 2026-07-13 | ingest-paper | Integrating Large Language Models into Security Incident Response (USENIX SOUPS 2025) - Focus: [[@2025__SOUPS__Integrating Large Language Models into Security Incident Response]] - Key concepts: [[LLMインシデント要約]]（新規）, [[インシデントレポート執筆]], [[インシデントレスポンスAIレベル]] - Key entities: [[Diana Kramer]]（新規、筆頭著者、[[Google]]）、[[Lambert Rosique]]（新規、[[DataPhant]]、唯一の社外共著者）、[[Elie Bursztein]]（新規、[[Sec-Gemini]] 共著者でもある）、[[Kurt Thomas]]、[[Patrick Gage Kelley]]、[[Ajay Narotam]]、[[Allison Woodruff]]（いずれも新規、[[Google]]） - Key insight: Gemini 1.5 Flash による自律的なインシデント要約は人間要約に61%対39%で劣後する(完全性35%・事実性42%の欠陥率)一方、人間がAI下書きを編集する協働(AI支援)要約は人間単独の要約より77%対11%で優位という非対称な結果。同一モデル・同一プロンプトでも人間をループに含めるかどうかで評価が逆転する点が、IR自律度(IR2/IR3)議論に定量的根拠を与える。要約作成者本人はAI支援の品質向上に懐疑的だが、独立評価者は77%でAI支援要約を高評価するという乖離も判明。 - Open questions: より新しいモデル・grounding・RAGでどこまで事実性ギャップを縮小できるか。作成者本人の過大な事実誤認リスク評価は他のLLM協働作業にも一般化するか。他組織・他インシデント種別への一般化可能性。 ### 2026-07-13 | ingest-paper | AgentTether: Graph-Guided Diagnosis and Runtime Intervention for Reliable LLM Agent Operations (arXiv) - Focus: [[@2026__arXiv__AgentTether - Graph-Guided Diagnosis and Runtime Intervention for Reliable LLM Agent Operations]] - Key concepts: [[エージェント修復]]（新規）, [[エージェントシステム運用]], [[グラフベースRCA]] - Key entities: [[Chenyu Zhao]]（新規、[[Nankai University]] 筆頭著者）、[[Shenglin Zhang]]（責任著者）、[[Dan Pei]]、[[Chetan Bansal]]、[[Saravan Rajmohan]]、[[Minghua Ma]]（[[Microsoft]]） - Key insight: 失敗した LLM エージェント実行の根本原因は症状の中央値 4 ステップ上流(最大 26)にあり直近性ヒューリスティックでは特定できない。さらに一度きりの診断フィードバックは注入直後 99% の追従率から tool-call ステップ 13(Banking はステップ 8)で 50% を割るまで減衰する。事後グラフ診断(Critical Transition Graph + オフライン HGT + 実時間 Isolation Forest)と保護付き実行時介入(Check→Decide→Inject)を連動させることで、τ-bench Banking の初回失敗タスクを Qwen3.7-max 59.04%・GPT-5.4 65.12% 修復(Blind retry 比 全体 +26.02pp)。 - Open questions: 介入強度をドメインリスク・タスクフェーズ・モデル能力に適応させる設計(過剰介入が新たな失敗モードになりうる)。マルチエージェント系への Critical Transition Graph の拡張。Wenwei Gu の所属([[Nankai University]] vs 既存記録の [[The Chinese University of Hong Kong]])の食い違いの検証。 ### 2026-07-13 | ingest | 価値はスケールしない。発酵する。(安宅和人) - Focus: [[@2026__hatenablog__価値はスケールしない、発酵する。]] - Key concepts: [[四資本の時計]]（新規）, [[価値生成の膜モデル]]（新規）, [[地域の乳化剤]]（新規）, [[テロワール(味わうことのできる時間)]]（新規）, [[存続可能性から生成する力へ]]（新規） - Key entities: [[安宅和人]]（新規、『風の谷という希望』著者）、[[Dan Hill]]（新規、メルボルン大学）、[[堀河屋野村]]（新規、和歌山県御坊市の醤油・味噌蔵） - Key insight: 成長論・脱成長論はともに全ての価値が経済資本と同じ単一の時計で動くと誤って前提している。経済資本は複利で増え、文化資本は発酵し、関係資本は熟成し、自然資本は循環するという異なる時間性を持つ。価値は完全な混合でも分離でもなく異質なものが互いを消さない距離で出会う「膜」の上で生まれる。この wiki に SRE/インフラ中心から地域再生・文化資本・脱成長という新規ドメインを導入した初のソース。 - Open questions: 四資本それぞれの「発酵に適した温度」の定量化。乳化剤的人材の見出し方・育成制度設計。テロワール概念の食・酒以外への一般化。持続可能性・存続可能性・生成する力という3層構造と既存の地方創生指標との対応関係。 ### 2026-07-13 | ingest | Cognitive Work of Hypothesis Exploration During Anomaly Response (ACM Queue) - Focus: [[@2019__ACMQueue__Cognitive Work of Hypothesis Exploration During Anomaly Response]] - Key concepts: [[アノマリー応答]]（新規）, [[仮説駆動RCA]], [[ヒンドサイトバイアス]], [[レジリエンスエンジニアリング]] - Key entities: [[Marisa R. Grayson]]（新規、[[Mile Two]] 認知システムエンジニア）、[[SNAFUcatchers Consortium]]（新規）、[[David D. Woods]]、[[Richard I. Cook]] - Key insight: SNAFUcatchers のチャットログを process tracing 分析し、仮説探索空間が「line of commitment（行動着手線)」を境に分岐・収束する時間発展を可視化。データセンター間バックアップ経路輻輳とロードバランサのゾンビ tee ルールの2ケースを詳述。「直近の変更が過度に優先され時間的に離れた変更の追跡が遅れる」という時間バイアスをヒンドサイトバイアスと対比。 - Open questions: 同号の姉妹論文("Above the Line, Below the Line" by Cook, "Managing the Hidden Costs of Coordination" by Maguire、いずれも未 ingest)との統合。仮説探索空間の可視化と agentic RCA の探索軌跡可視化(RCInvestigator等)の統合可能性。 ### 2026-07-13 | ingest | Failure is inevitable: Rethinking Reliability at Datadog - Focus: [[@2025__Datadog Engineering Blog__Failure is inevitable - Learning from a large outage and building for reliability in depth at Datadog]] - Key concepts: [[グレースフルデグレーデーション]]（新規）, [[インシデント管理]], [[ソフトウェア耐障害性]] - Key entities: [[Laura de Vesine]]（Datadog シニアスタッフ SRE）、[[Rob Thomas]]（新規）、[[Maciej Kowalewski]]（新規） - Key insight: 「データ完全性優先 → 部分障害が全停止に見えるスクエアウェーブパターン」という設計方針の罠。グレースフルデグレーデーション（よりよく失敗する）への転換で 30% 重大インシデント削減。2023 年 3 月の大規模障害（SREcon23 EMEA 発表済み）のアフターストーリー。 - Open questions: データ完全性 vs. 部分可視性のトレードオフ閾値はどう定量化するか。ブレークグラス機構の保守コストとメタ安定障害の関係。 ### 2026-07-13 | ingest-slides | Oncall: An Equal-Opportunity Waste of Time (SREcon22 EMEA) - Focus: [[@2022__SREcon22EMEA__Oncall - An Equal-Opportunity Waste of Time]] - Key concepts: [[SRE組織変革]], [[オンコールストレス管理]], [[インシデント管理]] - Key entities: [[Dave O'Connor]]（[[Twilio]] VP Engineering、元 Google SRE 16 年） - Key insight: 「toxic exceptionalism（オンコールを SRE の特権として複雑化・ゲートキープする文化）」が SRE を fancy-ops に固定化する。ステークホルダーへの価値証明は「オンコール要員」ではなく「工学的乗数効果」に移すべき。Facebook SRO 解散事例と同じ構造問題を態度レベルで問い直す。 - Open questions: 「全エンジニアが均等にオンコールを担う」思考実験で炙り出した SRE の専門性をどう再定義・再組織するか。 ### 2026-07-13 | ingest | 6 Reasons You Don't Need an SRE Team (log.andvari.net) - Focus: [[6 Reasons You Don't Need an SRE Team]] - Key concepts: [[カーゴカルトSRE]], [[SRE]], [[SRE組織変革]] - Key entity: [[Gerro Wadat]]（2004年Google在籍経験者） - Key insight: 「あなたはGoogleではない」—SREモデルは2004年のGoogle固有条件（前例なき規模・ツール不在・無限資本）の産物。現代の中小規模組織への適用には明確な事業的根拠が必要。信頼性専任チームの設置が組織全体の信頼性責任を回避する口実になるリスク（赤いニシン問題）を指摘。 - Open questions: カーゴカルト的SRE導入と適切なSRE導入の定量的な判断基準は何か。「信頼性を重視している」ことの客観的指標は。 ### 2026-07-10 | ingest-paper | Failure Trends in a Large Disk Drive Population (FAST 2007) - Focus: [[@2007__FAST__Failure Trends in a Large Disk Drive Population]] - Key concepts: [[ハードディスク信頼性]], [[データセンター信頼性]], [[障害予測]] - Key insight: Google 本番 HDD 10 万台超(9 か月観測)で、SMART スキャンエラーが 39 倍・オフライン再割り当てが 21 倍の障害リスク増と相関するが、障害ドライブの 56% 超は強 SMART シグナルゼロ。温度は中温域(25〜45°C)で障害との相関が弱く、むしろ低温域(15〜20°C)で AFR が高い逆説。使用率も 1 年以降は障害との相関が一貫しない。 - Open questions: SMART シグナルなし障害の検知に有効な追加シグナル種別、NVMe SSD での SMART 予測力の変化、低温高 AFR の交絡要因特定。 ### 2026-07-08 | ingest-paper | Benchmarking the Overhead of Distributed Tracing Agents (ICPE 2026) - Focus: [[@2026__ICPE__Benchmarking the Overhead of Distributed Tracing Agents]] - Key concepts: [[トレーシングオーバーヘッド]], [[分散トレーシング]], [[MooBench]], [[Kieker]], [[OpenTelemetry]], [[継続的プロファイリング]] - Key insight: 7 種 Java トレーシングエージェントを統一比較した結果、Kieker が最速(133.92 ns/depth)、業界標準 OpenTelemetry は 315.28 ns/depth で Kieker の 2.4 倍遅い。主因は HashMap のコピー・ArrayBasedContext スタックコピー・過度なメタデータ管理。Pinpoint/Scouter は傾きが低く見えるがスパン損失バグのため機能要件を満たさず比較対象外。eoi/ess 方式(Kieker)がコールツリー表現のオーバーヘッド最小化の鍵。 - Open questions: OpenTelemetry の改善提言(ハッシュマップコピー除去等)の実装効果の定量化、マイクロサービス非同期 I/O での挙動、eBPF 非侵入トレーシングとの per-call コスト閾値比較。 ### 2026-07-07 | ingest-paper | VAST AI Operating System (VAST Data 2025) - Focus: [[@2025__VAST Data__VAST AI Operating System]] - Key concepts: [[DASEアーキテクチャ]], [[コンピュートストレージ分離]], [[分散メッセージブローカ]], [[VAST Data]] - Key insight: DASE (CNode ステートレスコンテナ + NVMe-oF + 共有 SSD) により単一非分割ネームスペースを実現。Event Broker がトピックを DataBase テーブルとして実装し Kafka 比 6 倍スループット/ブローカを主張(ベンダー値)。InsightEngine で RAG の権限同期・埋め込みライフサイクル・監査が構造的に統合される。ただし全性能数値はベンダー自己申告。 - Open questions: NVMe Fabric 飽和時の挙動、Shared-Everything メタデータロック競合のスケール限界、第三者ベンチマークの不在。 ### 2026-07-06 | ingest-paper | INTFusion: Unifying Network and Host Telemetry in Data Center Networks (IFIP Networking 2026) - Focus: [[@2026__IFIP Networking__INTFusion - Unifying Network and Host Telemetry in Data Center Networks]] - Key concepts: [[インバンドネットワークテレメトリ]], [[テレメトリ]], [[ネットワーク監視]], [[データセンター輻輳制御]], [[eBPF]] - Key insight: INT ソース/シンクを smartNIC にオフロードし eBPF ホスト層トレースを per-flow 融合する「エッジ終端 INT」アーキテクチャが、スイッチ内サンク不要でネットワーク/アプリの断片化を解消。フローレット抽象化で長期持続 TCP コネクション上の複数メッセージを識別。二層エクスポート(イベント駆動リアルタイム + レート制御遅延)でリアルタイム性と帯域効率を両立。ただし評価は 10 GbE の 2 ホスト環境に限定。 - Open questions: 100G/400G/800G への適用性、Centralizer のスケーラビリティ(数千ホスト)、テレメトリ→制御フィードバック閉ループの設計。 ### 2026-07-06 | ingest-paper | Beyond Throughput: Performance and Energy Insights of LLM Inference Across AI Accelerators (IPDPS 2026) - Focus: [[@2026__IPDPS__Beyond Throughput - Performance and Energy Insights of LLM Inference Across AI Accelerators]] - Key concepts: [[AIアクセラレータ]], [[LLM推論]], [[テンソル並列]], [[Mixture-of-Experts]], [[Cerebras]], [[SambaNova]] - Key insight: データフローアクセラレータ(Cerebras CS-3)は小バッチで GPU 比 1 桁の優位を示すが、エネルギー効率では GPU が優勢。推論は DP > TP が原則だが、VRAM 80% 超のモデルでは TP が必要。H100 が GPU 中で最高スループット・エネルギー効率を両立。 - Open questions: AMD/Intel の vLLM ソフトウェア成熟度差の解消速度、データフローの固定バッチ制約と動的バッチの両立、エネルギー測定粒度の公平性。 ### 2026-07-06 | ingest-paper | Vedrfolnir: RDMA NPA Diagnosis in Collective Communications (SIGCOMM Posters 2025) - Focus: [[@2025__SIGCOMM__POSTER - Vedrfolnir - RDMA Network Performance Anomalies Diagnosis in Collective Communications]] - Key concepts: [[RDMAネットワーク監視]], [[集合通信]], [[Hawkeye]] - Key insight: 集合通信のアルゴリズム分解→待機グラフ→ステップ認識型適応検知→ホスト+ネットワーク統合 RCA。単一フロー診断ツール(Hawkeye 等)を co-flow 依存まで拡張し、テレメトリ 98% 削減。NS3 プロトタイプ段階で実機未評価。 - Open questions: AllToAllv など動的ステップアルゴリズムへの待機グラフ汎化、実機テストベッドでの大規模評価。 ### 2026-07-06 | ingest-paper | ARGUS: Production-Scale GPU Cluster Tracing (arXiv 2026) - Focus: [[@2026__arXiv__ARGUS - Production-Scale Tracing and Performance Diagnosis for over 10,000-GPU Clusters]] - Key concepts: [[LLM学習モニタリング]], [[GPU観測性]], [[ストラグラー]], [[fail-slow]], [[KDE クラスタリング]] - Key insight: 3 層独立計装(py-spy/CUDA Events/CUPTI)が 2% 未満オーバーヘッドで LLM 訓練の完全な観測性を与える。KDE + valley detection による 3,700 倍圧縮で常時稼働ストレージが成立。PP バブル転写・grad_sync アライメント機構がストラグラー根本ランク特定を困難にする。 - Open questions: DP 並列での勾配同期後のランク収束機構の詳細、カーネル分布の Wasserstein-1 距離閾値の自動調整、fail-slow とハードウェア障害の境界判定基準。 ### 2026-07-06 | ingest-paper | KRCA: Hyper-Scale Microservice RCA via Agentic AI (ASE '26) - Focus: [[@2026__ASE__KRCA - An Efficient Root Cause Analysis System in Hyper-Scale Microservice Systems via Agentic AI]] - Key concepts: [[根本原因分析]], [[LLMによる根本原因分析]], [[因果発見]], [[マイクロサービスアーキテクチャ]], [[agentic SRE]] - Key insight: ハイパースケール(20万超サービス)では探索空間の事前圧縮(API ドリルダウン→3候補)が必須。時系列因果発見は20メトリクスで20%以下に急落するが、意味情報ベースのスケルトン制約で60%超を維持できる。 - Open questions: 観測可能性シグナルが欠損したサービスのドリルダウン打ち切り問題、複数連鎖異常の同時発生時の伝播経路分離。 ### 2026-07-06 | ingest-paper | arXiv 2026 AgentOps RCA Benchmark - Focus: [[@2026__arXiv__A Multi-Dataset Benchmark for Evaluating LLM Agents in Microservice Failure Diagnosis]] - Key concepts: [[RCA評価設計]], [[SRE Benchmark]], [[LLMによる根本原因分析]], [[マルチモーダル障害診断]] - Key insight: 推論プロセス評価（Localization/Identification/Reason 3軸）が最終回答一致から証拠根拠付き診断への評価転換を可能にする。AIOps2025 は key-evidence、RCA100 は causal-chain の2形式が相互補完。 - Open questions: 6,093チームの競技における実際のエージェント精度スコア分布。本番スケール（数百サービス）への転移可能性。 ### 2026-07-06 | ingest | 博士論文を書くということ（北村匡平） - Focus: [[博士論文を書くということ]] - Key concepts: [[日本の博士教育]], [[北村匡平]] - Key insight: 「最初の大きなマイルストーン」思考——博士論文を最終成果と見ずに特定時点でのまとめと割り切ること ### 2026-07-06 | ingest-paper | APSys 2024 Wasm interpreter C/R - Focus: [[@2024__APSys__A Checkpoint-Restore Mechanism with Interoperability Among Distinctive WebAssembly Interpreters]] - Key concepts: [[WebAssembly]], [[ランタイム中立チェックポイント]], [[Application Checkpointing]], [[VM Migration]] - Open questions: custom-code to Wasm-bytecode mapping, fast-interpreter stack layout conversion, WASI/external-state preservation ### 2026-07-05 | ingest-paper | CANDARW 2025 Wasm self-healing - Focus: [[@2025__CANDARW__Seamless Self-Healing in WebAssembly Container Orchestration with Runtime-Neutral Checkpointing]] - Key concepts: [[ランタイム中立チェックポイント]], [[ホットリスタート]], [[動的ランタイム切り替え]], [[セルフヒーリング]] - Open questions: JIT/AOT runtime checkpointing, OS-level state preservation, runtime switching thresholds --- type: meta title: "Hot Cache" date: 2026-06-02 18:46 updated: 2026-07-05 tags: - 2026/06/02 - meta - 2026/06/10 - 2026/06/15 - 2026/06/16 - 2026/06/17 - 2026/06/18 - 2026/06/19 - 2026/06/20 - 2026/06/21 - 2026/06/23 - 2026/06/24 - 2026/06/26 - 2026/06/27 - 2026/06/28 - 2026/06/29 - 2026/06/30 - 2026/07/01 - 2026/07/02 - 2026/07/04 - 2026/07/05 - hot-cache status: evergreen related: - "[[index]]" - "[[log]]" - "[[overview]]" created: 2026-06-02 updated: 2026-07-05 --- # Recent Context # 2026-07-06: A Checkpoint/Restore Mechanism with Interoperability Among Distinctive WebAssembly Interpreters (APSys 2024 Poster) [[@2024__APSys__A Checkpoint-Restore Mechanism with Interoperability Among Distinctive WebAssembly Interpreters]]を wiki 化した。[[Daigo Fujii]]・[[Katsuya Matsubara]]・[[Yuki Nakata]]による APSys 2024 ポスターで、WasmEdge (standard interpreter) と WAMR・Wasm3 (fast interpreter) の間の checkpoint/restore を提案する。 **核心**: - **対象と動機**: WebAssembly はエッジクラウド協調の実行基盤に適するが、standard interpreter と fast interpreter では内部実行状態表現が大きく異なり、 checkpoint/restore は困難である。 - **状態変換**: プログラムカウンタを相対アドレスに変換し、コントロールスタック・バリュースタックを相互変換する。fast interpreter はカスタムコード上の実行点を持つため、Wasm バイトコード上の実行点との対応付けが必要である。 - **スタックレイアウトの変換**: WAMR や Wasm3 は 32 ビット単位で値を並べる一方、WasmEdge は 128 ビット単位で 0 パディングする。型情報を管理するデータ構造を導入し、fast interpreter のスタックを standard interpreter の内容に変換する。checkpoint 時に Wasm コードを関数単位で走査し、値のアドレスを収集することで再計算を伴わずに復元できる。 - **限界**: JIT/AOT 実装は対象外。定量的な実装・評価は予備的であり、WASI や外部リソースの状態を含む完全な C/R は扱っていない。 **新規ページ**: [[@2024__APSys__A Checkpoint-Restore Mechanism with Interoperability Among Distinctive WebAssembly Interpreters]](source)、[[Wasm3]](entity)。**更新**: [[WebAssembly]]、[[ランタイム中立チェックポイント]]、[[Application Checkpointing]]、[[VM Migration]]、[[Edge-cloud Collaboration]]、[[チェックポイント]](concept)、[[Daigo Fujii]]、[[Katsuya Matsubara]]、[[Yuki Nakata]]、[[Future University Hakodate]]、[[SAKURA internet Inc.]]、[[WasmEdge]]、[[WAMR]](entity)。 # 2026-07-05: Self-Hosted WebAssembly Runtime for Runtime-Neutral Checkpoint/Restore in Edge–Cloud Continuum (Mid4CC ’25) [[@2025__Mid4CC__Self-Hosted WebAssembly Runtime for Runtime-Neutral Checkpoint-Restore in Edge-Cloud Continuum]]を wiki 化した。[[Yuki Nakata]]・[[Katsuya Matsubara]]による Mid4CC ’25 論文で、Wasm にコンパイルした自己ホスト型ランタイム Chiwawa を提案する。 **核心**: - **動機**: Edge–Cloud Continuum ではエッジとクラウドで異なる CPU アーキテクチャと最適化戦略(JIT/AOT/インタプリタ)を持つ Wasm ランタイムを使い分けるが、各ランタイムの内部実行状態表現が異なり、C/R やライブマイグレーションが困難である。 - **アプローチ**: Chiwawa 自身を Wasm にコンパイルし、任意のホストランタイム上で動作させる。アプリケーションバイトコードは Chiwawa が作成する VM 上で実行され、C/R は Chiwawa VM の内部状態(プログラムカウンタ、スタック、線形メモリ、変数)のみを対象とする。これによりホストランタイムの実装差異と最適化戦略差異を吸収する。 - **最適化**: 自己ホストに伴う二重ランタイム実行のオーバーヘッドを抑えるため、命令マージによるスタック操作削減、SFI の省略(ホストランタイムに委譲)、WASI パススルーを行う。 - **評価**: 自己ホスト可能ランタイム Wizard と比較して pi-Leibniz で約 1.3 倍、n-body で約 1.4 倍高速で、メモリは 71〜85%削減。wasmtime 上直接実行に対しては sqlite-bench で最大 426.95 倍のオーバーヘッドがあるが、Wizard のランタイム計装型 C/R 擬似評価と比較すると最大 2.16 倍に留まる。wasmtime・WAMR・WasmEdge のいずれをホストとしても 1076 KB の一定した小さなチェックポイントサイズを達成した。 - **限界**: WASI を介したソケットやファイルなど OS 依存資源を持つアプリケーションには未対応。C/R トリガはファイルポーリングに依存しており、OS シグナル標準化を待つ。SFI の省略はホストランタイムへの信頼を前提とする。 **新規ページ**: [[@2025__Mid4CC__Self-Hosted WebAssembly Runtime for Runtime-Neutral Checkpoint-Restore in Edge-Cloud Continuum]](source)、[[Self-Hosted WebAssembly Runtime]](concept)、[[Chiwawa]]、[[Wizard]]、[[CRIU]](entity)。**更新**: [[WebAssembly]]、[[ランタイム中立チェックポイント]]、[[Application Checkpointing]]、[[VM Migration]]、[[Edge-cloud Collaboration]](concept)、[[Yuki Nakata]]、[[Katsuya Matsubara]]、[[Future University Hakodate]]、[[SAKURA internet Inc.]]、[[WasmEdge]]、[[WAMR]](entity)。 # 2026-07-05: Stateful VM Migration Among Heterogeneous WebAssembly Runtimes for Efficient Edge-cloud Collaborations (EdgeSys ’24) [[@2024__EdgeSys__Stateful VM Migration Among Heterogeneous WebAssembly Runtimes for Efficient Edge-cloud Collaborations]]を wiki 化した。[[Daigo Fujii]]・[[Katsuya Matsubara]]・[[Yuki Nakata]]による EdgeSys ’24 論文で、WasmEdge と WAMR 間の異種ランタイムステートフルVMマイグレーションを提案する。 **核心**: - **対象と動機**: WebAssembly(Wasm)はアーキテクチャ中立・サンドボックス化・軽量性からエッジクラウド協調の実行基盤に適するが、Wasm標準は内部ランタイム実装を規定していないため、異種ランタイム間のステートフルなVMマイグレーションは困難である。 - **状態変換**: WasmEdgeとWAMR間で、モジュールインスタンス(メモリ・グローバル)、プログラムカウンタ(絶対アドレス→関数インデックス+オフセット)、バリュースタック/コントロールスタック/フレームスタックをランタイム非依存表現に変換してマイグレーションする。特に命令アドレスの抽象化と型情報に基づくスタック復元が鍵となる。 - **最適化**: OSカーネルのdirty memory検出により使用済みメモリのみをチェックポイント化し、CRIUと比較して30〜100倍のチェックポイント時間短縮とサイズ削減を達成。型スタックオーバーヘッドを避ける「レイジ型判定」も提案した。 - **評価**: x86-64クラウド(i7-10700K, 32GB)とAarch64エッジ(BCM2711, 4GB)でbinary-trees/n-body/sqlite-benchを評価。sqlite-benchでは、エッジのWAMRからクラウドのWasmEdgeへランタイム切り替えマイグレーションが、WasmEdge単一またはWAMR単一の継続より総実行時間を短縮した。 - **限界**: WASIを介したOSカーネル状態(ネットワークソケット等)やJIT/AOT最適化状態のマイグレーションは未対応。 **新規ページ**: [[@2024__EdgeSys__Stateful VM Migration Among Heterogeneous WebAssembly Runtimes for Efficient Edge-cloud Collaborations]](source)、[[WebAssembly]]、[[VM Migration]]、[[Edge Computing]]、[[Edge-cloud Collaboration]]、[[Application Checkpointing]](concept)、[[Daigo Fujii]]、[[WasmEdge]]、[[WAMR]](entity)。**更新**: [[チェックポイント]](concept)、[[Yuki Nakata]]、[[Katsuya Matsubara]]、[[Future University Hakodate]]、[[SAKURA internet Inc.]](entity)。 # 2026-07-05: Reducing Attack Surface with Container Transplantation for Lightweight Sandboxing (APSys ’23) [[@2023__APSys__Reducing Attack Surface with Container Transplantation for Lightweight Sandboxing]]を wiki 化した。[[Yuki Nakata]]・[[Shintaro Suzuki]]・[[Katsuya Matsubara]]による APSys ’23 論文で、Linux コンテナを FreeBSD カーネルへ移植し Capsicum を透過適用する Container Transplantation を提案する。 **核心**: - **Container Transplantation**: Linux コンテナを FreeBSD カーネル上で互換実行させ、Linux カーネル固有の脆弱性攻撃を回避する。FreeBSD の Linuxulator がカーネル内で Linux システムコールを FreeBSD のシステムコールに変換する。 - **Capsicum の透過適用**: libpreopen と Casper を組み合わせ、未修正の Linux バイナリに対して FreeBSD の capability-based サンドボックス Capsicum を適用する。 - **性能評価**: UnixBench で gVisor は runC に対しシステムコールオーバーヘッド 96% 悪化したのに対し、Linuxulator with Jail は 22% 悪化に抑えた。 - **貫通テスト**: CVE-2016-9793、CVE-2016-5195、CVE-2017-1000405、CVE-2017-10661 の 4 件を防止。CVE-2016-4486 と CVE-2019-9213 は FreeBSD 未実装機能により実行不可。 **新規ページ**: [[@2023__APSys__Reducing Attack Surface with Container Transplantation for Lightweight Sandboxing]](source)、[[Container Transplantation]]、[[Capability-based Security]]、[[Capsicum]]、[[Lightweight Sandboxing]](concept)、[[Shintaro Suzuki]]、[[gVisor]]、[[Kata Containers]]、[[FreeBSD]]、[[Linux]]、[[Linuxulator]](entity)。**更新**: [[コンテナ仮想化]]、[[Yuki Nakata]]、[[Katsuya Matsubara]]、[[SAKURA internet Inc.]]、[[Future University Hakodate]]、[[Docker]]。 # 2026-07-05: Concentrated Isolation for Container Networks Toward Application-aware Sandbox Tailoring (UCC 2021) [[@2021__UCC__Concentrated Isolation for Container Networks Toward Application-aware Sandbox Tailoring]]を wiki 化した。[[Yuki Nakata]]・[[Katsuya Matsubara]]・[[Ryosuke Matsumoto (SAKURA internet)|Ryosuke Matsumoto]]による UCC’21 論文で、PaaS/FaaS コンテナのネットワーク隔離に集中した Sandbox Tailoring と、BitVisor ベースの para-passthrough ハイパーバイザ Subaco を提案する。 **核心**: - **Sandbox Tailoring**: 完全統合型サンドボックス(gVisor/Kata Containers/Firecracker)のようにすべてのリソースを同じ強度で隔離するのではなく、リソースごとに必要な隔離レベルに応じた手法を組み合わせる設計思想。ネットワークは攻撃影響が広がりやすいため強固に隔離し、CPU・メモリ・ファイルシステムなどは既存の軽量手法で保護することで、性能・起動時間・堅牢性のトレードオフを最適化する。 - **Subaco アーキテクチャ**: BitVisor をベースとした para-passthrough ハイパーバイザ。ホスト OS にコンテナ数と同数の仮想 NIC を提供し、各 NIC を Linux Network Namespace で個別のコンテナに割り当てる。Packet Verifier がハードウェア仮想化のコンテキストスイッチ情報(Intel VT-x の I/O ポート空間、PCI BDF 等)から送信元コンテナを特定し、パケットヘッダの IP/MAC と照合して偽装パケットを廃棄する。 - **性能評価**: Subaco の起動時間は runC と同等の約 1.15 秒。Nginx で runC に対し 200 接続時約 40% 低下するが、gVisor(約 87%)、Kata-QEMU(約 59%)、Kata-FC(約 79%)の大幅な性能低下に比べれば小さい。Memcached では 512 接続時約 11% 低下に抑えられた。TCP スループットは runC と大差なく、UDP ではパケットサイズ 1472 バイト時に約 43% 低下。 - **セキュリティ**: Table 1 で Subaco は L2 攻撃、L3/L4 攻撃、ホスト OS のネットワークリソース攻撃のすべてに対して防御可能と評価された。 - **未実装部分**: Policy Manager は論文執筆時点で未実装として記載されている。 **新規ページ**: [[@2021__UCC__Concentrated Isolation for Container Networks Toward Application-aware Sandbox Tailoring]](source)、[[Sandbox Tailoring]]、[[コンテナネットワーク分離]]、[[Para-passthrough Hypervisor]](concept)、[[Yuki Nakata]]、[[Katsuya Matsubara]]、[[Ryosuke Matsumoto (SAKURA internet)|Ryosuke Matsumoto]]、[[Future University Hakodate]]、[[SAKURA internet Inc.]](entity)。**更新**: [[コンテナ仮想化]](concept)。 # 2026-07-04: Extending Applications Safely and Efficiently (OSDI'25) [[@2025__OSDI__Extending Applications Safely and Efficiently]]を wiki 化した。[[Yusheng Zheng]]・[[Tong Yu]]・[[Yiwei Yang]]・[[Yanpeng Hu]]・[[Xiaozheng Lai]]・[[Dan Williams]]・[[Andi Quinn]]による OSDI'25 論文で、ユーザ空間アプリケーション拡張を安全かつ効率的に行う EIM([[Extension Interface Model]])と [[bpftime]] を提案する。 **核心**: - **安全性と相互接続性の細粒度トレードオフ**: EIM は拡張に必要な機能(ホスト関数呼び出し、変数読み書き、ハードウェアリソースなど)をリソースとしてモデル化し、ケイパビリティで保護する。アプリケーション開発者が「提供可能なリソース」を列挙し、拡張マネージャが各拡張入口で許可する最小限のリソースを選択する。 - **bpftime の 3 本柱**: eBPF スタイルの静的検証(安全性、実行時オーバーヘッドゼロ)、Intel MPK などのハードウェア支援プロセス内隔離(拡張保護)、動的バイナリ書き換えによる隠蔽拡張入口(未使用時コストゼロ)。 - **eBPF 互換性**: libbpf や BCC/bpftrace、カーネル eBPF 拡張と共存可能。DeepFlow 移植では eBPF コード 5,000 行中 10 行のみの変更で 1.5 倍以上のスループット改善。 - **性能**: Nginx ファイアウォール拡張でネイティブの 2% オーバーヘッド(Lua/WebAssembly の 11-12% や ERIM/RLBox の 9-11% と比較して最大 5.5× 低い)。uprobe/uretprobe はカーネル eBPF の約 2,500-3,000 ns に対し bpftime で 190/187 ns。 - **6 ユースケース**: Nginx セキュリティ、Redis 耐久性調整、FUSE キャッシング、DeepFlow 分散トレース、sslsniff SSL 監視、Syscount システムコール監視。 - **限界**: 拡張マネージャが正しい EIM 仕様を指定する責任がある。ホストアプリケーションへの注釈や新規関数追加が必要な場合もある。Intel x86 MPK 依存。 **新規ページ**: [[@2025__OSDI__Extending Applications Safely and Efficiently]](source)、[[Extension Interface Model]](concept)、[[Yanpeng Hu]]、[[Xiaozheng Lai]]、[[Dan Williams]]、[[Andi Quinn]]、[[Redis]]、[[FUSE]]、[[OpenSSL]](entity)。**更新**: [[eBPF]]、[[BPF]]、[[uprobe]](concept)、[[Yusheng Zheng]]、[[Tong Yu]]、[[Yiwei Yang]]、[[bpftime]]、[[eunomia-bpf]]、[[DeepFlow]]、[[Nginx]](entity)。 # 2026-07-04: The GPU Observability Gap(eunomia.dev) [[@2025__eunomia.dev__The GPU Observability Gap - Why We Need eBPF on GPU devices]]を wiki 化した。[[Yusheng Zheng]]・[[Tong Yu]]・[[Yiwei Yang]]([[eunomia-bpf]])によるブログ記事で、GPU 観測性ギャップと [[bpftime]] による eBPF の GPU カーネル内実行を解説する。 **核心**: - **GPU は「黒箱」**: SIMT 実行モデルと非同期 CUDA API の組み合わせで、CPU-GPU 境界のツールではカーネル内部(ワープ分岐・メモリアクセス・SM 占有率)が見えない。 - **eBPF を GPU 内部へ**: bpftime は PTX/SPIR-V 注入で eBPF プログラムを稼働中の GPU カーネルに埋め込み、スレッド/ワープ単位の計装を可能にする。 - **CPU/GPU 統一パイプライン**: 同じ eBPF ツールチェーンと BPF maps/ring buffers で CPU 側 uprobe/kprobe と GPU 側プローブを相関させ、異種スタック全体の因果追跡を目指す。 - **既存ツールの整理**: CPU-GPU 境界トレース(黒箱)、ベンダー専用プロファイラ(Nsight/CUPTI 等・閉じたイベントモデル・本番不向き)、研究ツール(NVBit/NEUTRINO 等・アセンブリ依存・高オーバーヘッド)の 3 類型を整理し、eBPF on GPU がプログラマブル・低オーバーヘッド・ベンダー非依存で補完する方向を示した。 - **実装例**: `kernelretsnoop`(カーネル出口 per-thread タイムスタンプ)、`threadhist`(スレッド実行回数ヒストグラム)。 - **注意点**: GPU 対応は実験的。`kprobe`/`kretprobe` 命名は GPU デバイス側への類比の仮称。 **新規ページ**: [[@2025__eunomia.dev__The GPU Observability Gap - Why We Need eBPF on GPU devices]](source)、[[eGPU]]、[[PTX 注入]](concept)。**更新**: [[GPU観測性]]、[[eBPF]]、[[bpftime]]、[[eunomia-bpf]]、[[Yusheng Zheng]]、[[Tong Yu]]、[[Yiwei Yang]]。 # 2026-07-04: CUDA Events - eBPF-based CUDA API Tracing(eunomia.dev) [[@2026__eunomia.dev__CUDA Events - eBPF-based CUDA API Tracing]]([[eunomia-bpf]]、[[yunwei37]])を wiki 化した。`libcudart.so` への eBPF uprobe で `cudaMalloc`/`cudaMemcpy`/`cudaLaunchKernel` 等をリアルタイムにトレースするチュートリアル。 **核心**: - **CPU 側の CUDA API トレース**: ソース改変なしで GPU 利用の入口(メモリ割当・転送方向・カーネル起動・同期イベント)を可視化する。 - **アーキテクチャ**: `cuda_events.h`/`cuda_events.bpf.c`/`cuda_events.c` の 3 ファイル。eBPF 側で ring buffer にイベントを投入し、libbpf でロード・uprobe アタッチ、ユーザ空間で表示する。 - **低オーバーヘッド**: 1,024 KiB・10,000 イテレーションのベンチマークで、CUDA API 呼び出しあたり約 2 µs の追加レイテンシ。 - **限界と次のステップ**: CPU 側トレースはカーネル内部のスレッド動作には届かない。GPU 内部計装には [[bpftime]]/eGPU による PTX 注入が必要。 **新規ページ**: [[@2026__eunomia.dev__CUDA Events - eBPF-based CUDA API Tracing]](source)、[[CUDA API トレース]]、[[CUDA]]、[[uprobe]](concept)、[[yunwei37]](entity)。**更新**: [[eBPF]]、[[GPU観測性]]、[[動的計装]]、[[eunomia-bpf]]、[[bpftime]]、[[libbpf]]、[[NVIDIA]]。 [[@2026__note__デジタルネイチャーの十年 - 計算的物質化から発酵する共在へ]]を wiki 化した。[[計算機自然]]の十年を、計算的物質化、環境計算、身体多様性、[[null2]] の公共空間化、生成AI以後の発酵する共在へ整理する公開ワーキングペーパーの日本語訳。 **核心**: - **五局面の系譜**: 計算的物質化、境界溶解、社会実装と身体多様性、null/民藝/儀礼/公共建築、生成AI以後の発酵する共在。 - **後期語彙**: [[デジタル発酵]]、[[デジタル蒸留]]、[[Homo Convivium]]、[[マタギドライヴ]]を、生成AI以後の計算機自然を記述する概念として整理。 - **アクセシビリティ**: 後付けの応用ではなく、計算環境が多様な身体に住まれうるかを問う存在論的試金石。 - **内部批判**: テクノ・オカルティズム、プラットフォーム捕獲、自己オリエンタリズム、著作性崩壊、エネルギー責任、政治的酩酊、共在の過剰包摂をリスクとして明示。 **新規ページ**: [[@2026__note__デジタルネイチャーの十年 - 計算的物質化から発酵する共在へ]](source)、[[デジタル発酵]]、[[デジタル蒸留]]、[[Homo Convivium]]、[[アクセシビリティ]](concept)、[[null2]]、[[xDiversity]]、[[Digital Nature Group]](entity)。**更新**: [[計算機自然]]、[[マタギドライヴ]]、[[批判的デジタルネイチャー]]、[[落合陽一]]。 # 2026-07-04: 計算機自然からマタギドライヴへ（落合陽一 note） [[@2026__note__計算機自然からマタギドライヴへ - 自然の再審と脱人間知性的文明論の10年]]を wiki 化した。2015年の『魔法の世紀』、2018年の『デジタルネイチャー』、2026年の『マタギドライヴ』を、[[計算機自然]]の技術的肯定から存在論的統合、さらに辺縁への自己批判へ展開する思想史として読む長文論考。 **核心**: - **自然概念の再審**: physis / natura / じねん / ziran / Natur などを比較し、Digital Nature が単純に翻訳できない概念であることを示す。 - **トランスダクション**: 計算と物質、データと知覚、身体とデジタルの変換を Simondon の語彙で再定式化する。 - **マタギドライヴ**: 計算機自然の中心化・最適化・加速から距離を置き、辺縁で計算不能なものとともに生きる自己批判として位置づける。 - **批判的再構成**: 環境負荷、権力構造、身体・ジェンダーを、外部批判ではなく [[批判的デジタルネイチャー]] の構成要素として扱う。 **新規ページ**: [[@2026__note__計算機自然からマタギドライヴへ - 自然の再審と脱人間知性的文明論の10年]](source)、[[落合陽一]](entity)、[[計算機自然]]、[[マタギドライヴ]]、[[批判的デジタルネイチャー]]、[[主体なき美の美学]]、[[ヌルのテトラレンマ]](concept)。 # 2026-07-03: AI tools expand scientists' impact but contract science's focus（Nature 649 | Hao, Xu, Li, Evans） [[@2026__Nature__Artificial intelligence tools expand scientists' impact but contract science's focus]]（清華大学 BNRist・シカゴ大学 知識ラボ / サンタフェ研究所、Nature 649, 1237–1243, 2026-01-14）を wiki 化した。自然科学分野の 4,130 万件の論文を BERT ファインチューニングモデル(F1=0.875)で AI 拡張研究に分類し、3 時代の AI(統計的 AI・古典的機械学習・深層学習)を横断して定量分析した大規模計量書誌学研究。 **核心: 個人-集合のパラドックス**: - **個人利益**: AI 採用研究者は非 AI 研究者に比べ 3.02 倍の論文発表・4.84 倍の引用・1.37 年早い PI 昇進 - **集団的縮小**: 科学トピック多様性 4.63% 減少、研究者間交流 22% 減少、200 以上のサブフィールドの 70% 以上で知識範囲が縮小 - **メカニズム**: AI はデータ豊富な確立分野を自動化するが新領域を開拓しにくい。フォローオン参照が減少し、研究の重複が増加 - **副作用**: チームサイズ平均 1.33 人減(ジュニア研究者 31% 減)、引用集中度の増大(上位 20% が引用の 80% を独占) **既存 wiki との関連**: [[AI研究自動化]](Lu et al.「The AI Scientist」)が「AI が科学プロセスを自動化できる能力」を示すのに対し、本研究は「AI 利用が集合的にどこへ向かうか」を問う。2 つの視点は補完的かつ対照的であり、横断的知見として接続した。新概念 [[AIと科学の集中化]] を作成。 **新規ページ**: [[@2026__Nature__Artificial intelligence tools expand scientists' impact but contract science's focus]](source)、[[Qianyue Hao]]・[[Fengli Xu]]・[[Yong Li]]・[[James Evans]](entities)、[[AIと科学の集中化]](concept)。**更新**: [[AI研究自動化]](横断的知見・未解決の問い追記)。 # 2026-07-02 (4): PLaMo 2 Technical Report（arXiv 2509.04897 | Preferred Networks） [[@2025__arXiv__PLaMo 2 Technical Report]]（[[Preferred Networks]]、arXiv 2025-09-05 / v2 2025-09-25）を wiki 化した。PLaMo 2 は日本語重視 LLM 系列で、Samba ベースの Mamba + スライディングウィンドウアテンション構成、合成日本語データ、重み再利用、31B→8B の構造化枝刈り・知識蒸留、32K 文脈対応 CPT、事後学習、vLLM 推論最適化を統合する。 **核心**: - **Samba からフルアテンションへ**: 初期構成は Mamba + SWA だが、Phonebook / Passkey Retrieval で SWA 窓外の長距離検索に失敗。CPT では SWA 窓を 32K へ拡大し、長距離検索を回復。 - **日本語データ不足への対処**: 翻訳・言い換え・コード・数学の合成データを大規模に使い、PLaMo-100B 由来の日本語データもフィルタして活用。 - **枝刈りと蒸留**: 31B モデルから PLaMo 2.1 8B を構造化枝刈り + 知識蒸留で生成。複数モデルサイズ展開の限界追加コストを下げる設計。 - **日本語評価**: PLaMo 2.1-8B は Jaster AVG 0.626、M-IFEval 日本語 AVG 0.630、pfgen-bench 0.893。PLaMo 2.0-31B は Jaster AVG 0.665、M-IFEval 0.677、pfgen-bench 0.890。 - **推論最適化**: vLLM Model API、カスタム Mamba 層、チャンク化プリフィル、`torch.compile`、INT4 重み量子化、FP8 KV キャッシュ量子化。31B 重みは 63GB→17GB、KV キャッシュは約 110KB/トークン→54KB/トークン。 - **注意点**: 表6の JMMLU 値は表1と PLaMo 2.1 8B / 31B の値が入れ替わっているように見える。source ページでは数値をそのまま記録し、解釈に注記した。 **新規ページ**: [[@2025__arXiv__PLaMo 2 Technical Report]](source)、[[Preferred Networks]]・[[PLaMo 2]](entities)。**更新**: [[ハイブリッドアテンションアーキテクチャ]]、[[スライディングウィンドウアテンション]]、[[状態空間モデル]]、[[モデル圧縮]]、[[LLM推論]]。 --- # 2026-07-02 (3): XProf — Open, Scalable, Extensible ML Profiler（MLSys 2026 | Google Cloud） [[@2026__MLSys2026__XProf - An Open, Scalable and Extensible Profiling System for the Modern ML Stack]]（[[Robert Hundt]] ほか、[[Google Cloud]]、MLSys 2026 Oral）を wiki 化した。OpenXLA エコシステムの ML プロファイラ XProf の設計・アーキテクチャの報告。論文 PDF は OpenReview Cloudflare 保護のため取得不可。スライド PDF(`.raw/papers/mlsys2026-xprof-slides.pdf`)と MLSys 掲載テキストから構成。 **核心**: - **5 つのプロファイリング課題**: スケーラビリティ(数千チップ)・発見可能性・説明可能性(フレームワーク〜ハードウェアカウンター横断)・適応性・忠実度(観測者効果の最小化)。 - **TraceMe**: ロックフリー・スレッドローカルの非ブロッキング計装。遅延相関でキロバイトオーダーのトレース量を実現。TPU で 0.3% 未満オーバーヘッド。 - **3 核心革新**: TraceMe(超低オーバーヘッド計装)・GTC(グローバルタイムスタンプカウンターで数千アクセラレーターを同期)・MapReduce バックエンド(分散スケーラブル処理)。 - **PJRT C API 拡張**: TPU/NVIDIA GPU/AMD GPU/Amazon Trainium/Intel GPU をプラグイン形式で統一サポート。 - **多段可視化**: 高レベル(Rooflineモデル)・中間(トレースビューアー/HLO Op プロファイル/メモリビューアー)・低レベル(ハードウェアカウンター)の 3 層で ML スタック全体を可視化。 - **実績**: MLPerf 受賞・Google 社内効率改善に貢献。ケーススタディとして熱変動 10°C 削減を達成。 **新規ページ**: [[@2026__MLSys2026__XProf - An Open, Scalable and Extensible Profiling System for the Modern ML Stack]](source)、[[MLプロファイリング]](concept)、[[Rooflineモデル]](concept)、[[Robert Hundt]]・[[OpenXLA]](entities)。**更新**: [[Google]](XProf 開発元として MLプロファイリングセクション追加)。 --- # 2026-07-02 (2): Machine Learning Fleet Efficiency: ML Productivity Goodput（MLSys 2026 | Google TPU） [[@2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput]]（[[Arissa Wongpanich]] ほか、[[Google]]、MLSys 2026 Industry Track）を wiki 化した。Google の本番 TPU フリートで ML 効率を測定・改善する体系的フレームワーク。スライド PDF 32 ページ（論文 PDF は OpenReview Cloudflare 保護のため取得不可）と abstract から構成。 **核心**: - **従来指標の限界**: Capacity（スケジューリング制約を無視）・Occupancy（割り当て ≠ 利用）・Duty Cycle（アクティビティ ≠ 生産的仕事）はいずれも「有用な計算をどれだけ達成したか」を測れない。 - **MPG の分解**: ML Productivity Goodput = Scheduling Goodput(SG) × Runtime Goodput(RG) × Program Goodput(PG)。SG = all-allocated/capacity、RG = productive/all-allocated、PG = predicted/productive。 - **Program Goodput の革新**: roofline 効率ではなく「予測ステップ時間（融合・オーバーラップ考慮後）」を分母に取ることで、コンパイラー最適化の余地（オペレーター融合・通信計算オーバーラップ）を可視化。 - **実証結果**: Google TPU + Borg フリートで全ジョブサイズ SG > 95% を達成（プリエンプション調整）。RG 改善: 非同期チェックポイント・AoT コンパイル・プリエンプション認識型ジョブ退避。PG: 上位 150 ワークロードのベンチマークでコンパイラー改善を継続トラッキング。 **新規ページ**: [[@2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput]](source)、[[ML Productivity Goodput]](concept)、[[Arissa Wongpanich]]・[[Vijay Janapa Reddi]]・[[Borg]](entities)。**更新**: [[Google]](ML フリート効率セクション追加)、[[GPUクラスタ運用]](横断的知見・未解決の問い追記)。 --- # 2026-07-02: The Case for Learned Index Structures（arXiv 1712.01208 | Tim Kraska / MIT・Google） [[@2017__arXiv__The Case for Learned Index Structures]]（[[Tim Kraska]]・[[Alex Beutel]]・[[Ed H. Chi]]・[[Jeffrey Dean]]・[[Neoklis Polyzotis]]、arXiv 2017-12-04 / v3 2018-04-30）を wiki 化した。B-Tree・ハッシュマップ・Bloom filter を「キーから位置または存在を予測するモデル」と見なし、[[Learned Index]] という研究方向を提示する 30 ページの探索的論文。PDF 原本、抽出テキスト、図表クロップ 8 枚を保存済み。 **核心**: - **索引はモデルである**: B-Tree はソート済み配列中の位置を返す回帰木、ハッシュ索引は位置写像、Bloom filter は存在判定モデルとして見られる。 - **範囲索引 = CDF 近似**: ソート済みデータの位置予測は $p = F(Key) * N$ と表せる。RMI は上位モデルで大局形状を学び、下位モデルで局所位置を予測する。 - **整数範囲索引結果**: 2 段 RMI は B-Tree ページサイズ 128 と比べ、Map/Web/Log-Normal データで最大 1.5〜3 倍高速、索引サイズは最大 2 桁小さい。 - **学習ハッシュ関数**: CDF モデルを $h(K)=F(K)*M$ として使い、Map Data で衝突率 35.3%→7.9%（77.5% 削減）。Web/Log-Normal でも 30.0% / 26.7% 削減。 - **学習 Bloom filter**: 分類器 + 漏れ受け用 Bloom filter で偽陰性ゼロを保ち、phishing URL データで 1% FPR 時 2.04 MB→1.31 MB（36% 削減）。 - **限界**: 主評価は読み取り専用・インメモリ・ソート済み配列に寄る。更新、ページング、分布変化、非存在キーの上限/下限境界保証は将来課題。 **新規ページ**: [[@2017__arXiv__The Case for Learned Index Structures]](source)、[[Learned Index]](concept)、[[Alex Beutel]]・[[Ed H. Chi]]・[[Neoklis Polyzotis]](entities)。**更新**: [[B-Tree]]、[[Tim Kraska]]、[[Jeffrey Dean]]、[[Google]]、[[MIT]]。 # 2026-07-02: Retrieval as Reasoning — LLM-Wiki（arXiv 2605.25480 | Haoliang Ming / WeChat, Tencent） [[@2026__arXiv__Retrieval as Reasoning]]（[[Haoliang Ming]] ほか、WeChat/Tencent、arXiv 2026-05-26）を wiki 化した。RAG の「フラットチャンク + 固定 top-k」を刷新する Retrieval-as-Reasoning パラダイムを提唱し、文書を双方向リンク付き Wiki ページにコンパイルするエージェントネイティブ検索システム LLM-Wiki を実装。15 ページ、PDF 原本取得済み。 **核心**: - **Retrieval-as-Lookup vs. Retrieval-as-Reasoning**: 従来 RAG は埋め込み類似度で固定 top-k チャンクを渡す一回限りの操作（ルックアップ）。LLM-Wiki はエージェントが推論と連動して検索を計画・反復・改訂・充足性判断する。 - **3 原則**: Compilability（文書を構造化 Wiki ページにコンパイル）・Composability（`wiki_search` / `wiki_read` の合成による構成的横断）・Evolvability（Error Book による自己修正）。 - **Error Book**: 5 段階（Discover→Attribute→Constrain→Inject→Verify&Close）の永続的自己修正ループ。単一エピソード内で完結する Reflexion/Self-RAG と異なりバッチをまたいで蓄積・修正する点が新規性。 - **実験結果**: HotpotQA 0.839 / MuSiQue 0.739 / 2WikiMHQA 0.911（F1）で SOTA。LightRAG 比 +2.0〜+8.1 F1 ポイント。4-hop では 0.983 F1 を達成し、推論深度増加に比例して優位性が拡大。クエリ時レイテンシは Dense RAG 並みで LightRAG・HippoRAG 2 より大幅低速。 - **Karpathy LLM Wiki パターンの最初の操作的実装**: 2026-04 の Karpathy Gist で提唱された抽象設計思想を、同年 5 月に Tencent の研究者が実証した。 **新規ページ**: [[@2026__arXiv__Retrieval as Reasoning]](source)、[[Retrieval-as-Reasoning]](concept)、[[Haoliang Ming]](entity)。**更新**: [[LLM Wikiパターン]]（Karpathy 実装例として横断的知見追記）、[[LLM向け情報検索]]（知識組織化が生成品質を規定するという横断的知見追記）、[[Tencent]]（LLM-Wiki 追記）。 # 2026-07-01: Epistemology of Incident Management (SREcon26 Americas, 2026 | Jack Kingsman / Atlassian) [[@2026__SREcon26Americas__Epistemology of Incident Management]]（[[Jack Kingsman]]、[[Atlassian]] シニア SRE、USENIX SREcon26 Americas、2026-03）を wiki 化した。Google SRE Book の Incident Loop を認識論的に再構築し、インシデント対応の各フェーズを「何を知る必要があるか」という問いとして整理する 49 ページのスライド。YouTube 英語自動字幕 transcript（1018 行）あり。CC-BY 4.0。 **核心**: - **5 フェーズ Incident Loop**: Phase 0（検知/宣言）→ Phase 1（生存/トリアージ：可逆的緩和でボートを浮かせる）→ Phase 2（検査：証拠収集）→ Phase 3（診断/仮説）→ Phase 4（テスト/処置）。フェーズは循環し知識の増加によって前進する。 - **証拠 2×2 マトリクス**: 出所（direct/indirect）× 変化状況（changing/stable）の 4 象限で証拠優先度を決める。Direct-changing が最高信頼度。 - **探索 3 パターン**: Linear（末端から逐次）・Binary（2 分法）・Induced-Change（変化誘導で証拠生成）。 - **仮説 3 条件**: testable（テスト可能）・relevant（証拠と関連）・specific（具体的）。「テストできないものは仮説ではなくフラストレーション」。early stopping（もっともらしい説明で止まる）が最大の誤り。 - **テスト 6 基準**: ①仮説への作用・②相互排他性・③交絡因子排除・④効果の測定可能性と可逆性・⑤リスクの管理可能性・⑥最小介入。 - **3 ボーナスコミュニケーションスキル**: 待機アノテーション（"I'm waiting for X"）・条件分岐付きの計画（If X then Y）・行動を促す質問（Yes/No でなく具体データを求める）。 - **締め**: "Incidents are all about knowledge"。 **新規ページ**: [[@2026__SREcon26Americas__Epistemology of Incident Management]](source)、[[Jack Kingsman]](entity)、[[インシデント認識論]](concept)。**更新**: [[Atlassian]](Kingsman SREcon26 発表を追加)、[[インシデント管理]](認識論的横断的知見追記)、[[仮説駆動RCA]](仮説 3 条件・テスト 6 基準を横断的知見に追記)。 **既存 wiki との接続**: [[仮説駆動RCA]] の「early stopping（SREGym 指摘の最初の異常への固着）」問題に、人間実践の観点から独立した裏付けを与える。[[インシデント認識論]] という新規 concept を起点に SRE 実践側の知識地図が広がる。 --- # 2026-07-01: Modern Microprocessors: A 90-Minute Guide (Jason Patterson, lighterra.com) [[@Modern-Microprocessors-A-90-Minute-Guide]]を wiki 化した。プロセッサ マイクロアーキテクチャの包括的解説記事(Web ページ)。パイプラインから SIMD・キャッシュまで現代プロセッサ設計の全体像を網羅し、Intel/AMD/Apple M/ARM Cortex-X/Qualcomm Snapdragon X の最新数値も含む。 **核心**: - **クロック ≠ 性能**。IPC(命令/クロック)が性能を決める。 - 高性能化の 3 本柱: ILP(命令レベル並列性)・TLP(スレッドレベル並列性)・DLP(データレベル並列性)。 - 3 つの壁: **電力の壁**(クロック↑ → 消費電力 f×V² で増大)・**ILP の壁**(実アプリ平均 IPC は SPECint でも 2 未満)・**メモリウォール**(DDR5-6400 + 4 GHz で約 108 クロックのレイテンシ)。 - OOO の実際の効果はインオーダー比 20〜40% 程度。Andy Glew(Pentium Pro 設計者)「OOO は思ったほど OOO していない」。 - 現トレンド: 非対称マルチコア(big.LITTLE)・チップレット・3D V-Cache・SVE。 **新規ページ**: [[Modern-Microprocessors-A-90-Minute-Guide|Modern Microprocessors: A 90-Minute Guide]](source)、[[パイプライン処理]]、[[スーパースカラー実行]]、[[分岐予測]]、[[アウトオブオーダー実行]]、[[VLIW]]、[[同時マルチスレッディング]]、[[SIMDベクトル処理]]、[[メモリ階層とキャッシュ]]、[[メモリウォール]]、[[Brainiac設計]]、[[チップレット]]、[[AMD]]。 **既存 wiki との関係**: このドメインはほぼ初出。SRE/AIOps の文脈では CPU 性能の基礎知識として参照されうる(モデル推論速度・メモリ律速・キャッシュ競合など)。 # 2026-07-01: Your System Has Recovered from an Incident, but Have Your Developers? (SREcon18 Americas, 2018 | Jaime Woo / Shopify) [[@2018__SREcon18Americas__Your System Has Recovered from an Incident, but Have Your Developers]]（[[Jaime Woo]]、元 [[Shopify]] テクノロジーコミュニケーション責任者、USENIX SREcon18 Americas、2018-03-27）を wiki 化した。インシデント後のエンジニアの心理的回復に焦点を当て、Shopify 社内データと医学・コメディ・スポーツ科学の知見を組み合わせる 39 ページのスライド。transcript なし。 **核心**: - **データ**: Shopify 本番エンジニア 40 名のうち 42.5% がインシデント後に「ストレス」または「非常に強いストレス」を報告。気分・睡眠・集中力への影響が棒グラフで可視化(p.10)。 - **ピアサポートの欠如**: 「コワーカーが様子を聞いてくれる頻度」で 80% が「まったくない(1)」か「2」と回答(p.18)。「自分が声をかける頻度」は比較的均等に分布——行動ギャップが存在する。 - **医師から**: 医療ミス後の医師は「二次被害者(secondary victim)」になる。82% がピアサポートとカウンセリングが有効と感じた。SRE の英雄文化(hero culture)打破への類比。 - **コメディアンから**: 失敗を「打率(batting average)」で文脈化し、精神的回復の方法を意識し、また馬に乗る——の 4 ステップ。 - **オリンピアンから**: Mosewich et al. (2013) のセルフコンパッション介入(n=60)で反芻思考・自己批判・ミスへの懸念が有意に低下。「これは先天的ではなく、意図的に訓練できる(intentional not innate)」。 - **問い**: 「システムは回復した。エンジニアは?」——人間向けのインシデントレスポンスとは何か。 **新規ページ**: [[@2018__SREcon18Americas__Your System Has Recovered from an Incident, but Have Your Developers]](新規 source)、[[Jaime Woo]](新規 entity)、[[インシデント後の人的回復]](新規 concept)。**更新**: [[オンコールストレス管理]](横断的知見に Long vs Woo の補完関係追記)、[[人的要因]](source 追加)。 # 2026-07-01: Tales from the VOID: The Scary Truth About Incident Metrics (SREcon22 Americas | Courtney Nash / Verica) [[@2022__SREcon22Americas__Tales from the VOID - The Scary Truth About Incident Metrics]]（[[Courtney Nash]]・[[Verica]]、USENIX SREcon22 Americas、2022-03-14）を wiki 化した。VOID データベース（1,856 件・610 組織）の実分布を用いて MTTR・持続時間・RCA という業界標準指標が統計的・認識論的に機能しないことを論証し、社会技術的データへの転換を提案する 29 ページのスライド。transcript なし。 **核心**: - **MTTR の実証的批判**: VOID 全組織の持続時間分布は右歪み。100k 回モンテカルロシミュレーション（[[Štěpán Davidovič]]）が示すように、分布の広がりが大きすぎて実際の改善を統計的に検出することはほぼ不可能。 - **持続時間 ≠ 深刻度**: Honeycomb の実データで「23h 11min・顧客影響ゼロ」と「21min・Critical」が共存。John Allspaw の言う「同じ長さの 2 つの障害は劇的に異なる体験をもたらす」。 - **RCA の否定**: VOID 1,818 件のうち RCA 実施は 26%。Sidney Dekker「根本原因とは、それ以上探すのをやめた場所にすぎない」。 - **ニアミスは成功**: Carl Macrae の知見——ニアミスはメンタルモデルのギャップを本番インシデント前に顕在化させる。Fred Hebert（Honeycomb）「後処理プレッシャーがない分、より集中できる」。 - **新しいアプローチ 4 点**: ① SLO・顧客フィードバック、② 調整コスト（関与人数・ツール・チーム）、③ テーマとナラティブ（Jeli Howie ガイド）、④ ニアミス分析。 **更新**: [[Courtney Nash]](発表追加)、[[Verica]](VOID 詳細追記)、[[インシデントメトリクス]](VOID 実分布・持続時間と深刻度の無相関を追記)、[[ポストモーテム]](ニアミス学習価値を追記)。 # 2026-07-01: The Critical Resource Is You: Practical Destressing for On-Call Engineers (SREcon26 Americas, 2026 | Beth Adele Long) [[@2026__SREcon26Americas__The Critical Resource Is You - Practical Destressing for On-Call Engineers]]([[Beth Adele Long]]、[[Continuous Re-integration]] / [[Adaptive Capacity Labs]]、USENIX SREcon26 Americas、2026-03-24)を wiki 化した。オンコール業務の慢性・急性ストレスを ANS(自律神経系)の観点から解説し、Ordinary Mind と Sensory Mind という「意識の 2 モード」を軸に、身体知性に根ざした 4 つの実践ツールを提示する 43 ページのスライド。transcript なし。 **核心**: - **2 種類のストレス**: ページャーを持つ = 慢性ストレス(chronic)、インシデント対応 = 急性ストレス(acute)。どちらも身体(ANS)から始まり、人生全体に影響する。 - **2 つの意識モード**: Ordinary Mind(目標指向・合理的・時間感覚あり)= エンジニアとして仕事ができるすべての能力。Sensory Mind(直接体験・感覚・感情・時間のなさ)= 夢や夢うつつで自由に動く。 - **鍵となるメカニズム**: ANS は自己修正機能を持つが、Ordinary Mind によって**抑制(blocked)**されてしまう。分析・トーク・メタ認知は Ordinary Mind が好む理性的ツールだが、身体から来るストレスには届かない。 - **4 つの身体的ツール**: Body Scan(感覚体験への注意転換)・Breath(交感神経→副交感神経、吸う4/止める4/吐く8)・Movement(自発的動き——ダンス・シェイキング・遊び)・Boredom(「自我への休暇」——壁を見る・無音の散歩)。各ツールに「いつ使うか」の使いどころが明示。 - **再フレーミング**: ストレスは単なる負荷(load)。良くも悪くもない。健全なストレスはキャパシティを拡大する。 **新規ページ**: [[@2026__SREcon26Americas__The Critical Resource Is You - Practical Destressing for On-Call Engineers]](新規 source)、[[オンコールストレス管理]](新規 concept)、[[Beth Adele Long]](新規 entity)、[[Continuous Re-integration]](新規 entity)。**更新**: [[人的要因]](生理学的ストレス管理を Human Factors の身体的次元として横断的知見に追記)。 **既存 wiki の文脈**: [[Matt Davis]] の「人間のオブザーバビリティ」(認知・コミュニケーション面)と Long の「身体的介入」(神経系面)は補完的。スライドに生理学的根拠の引用はなく、口頭説明への依存が高い点は限界として記録。 # 2026-07-01: The Un-Incident (SREcon25 EMEA, 2025 | Andreas Deuschl) [[@2025__SREcon25EMEA__The Un-Incident]]([[Andreas Deuschl]]、[[Dynatrace]]、USENIX SREcon25 EMEA、2025-10-08、ダブリン)を wiki 化した。正式宣言されない潜在インシデント「アンインシデント」に焦点を当て、30〜60% の潜在インシデントが正式トラッキングを通過しないという実務推計(自己経験)から出発する 26 ページの発表。 **核心**: - **4 類型の定義**: No-CI(非クリティカルな顧客影響) / NOF・Not Our Fault(外部起因) / Near Miss(幸運による回避) / Fear Miss(過剰反応エスカレーション)。 - **Gray Zone Playbook**: マインドセット(心理的安全・宣言を阻まない)→ カルチャー(宣言に感謝)→ ストラクチャー(オブザーバビリティへの信頼・SLO・ラッキーセーブ記録)→ プロセス(Post-Incident-Analysis を簡単にトリガー・Production Status Meeting → ガイド付きエスカレーションパス)の循環サイクル。 - **問いの転換**: 「インシデントか否か」ではなく「何を学べるか」へ。"To be or not to be an incident, that is NOT the question." - **NOF のプロダクトへの転用**: NOF インシデントから 7 つのプロダクト設計原則(Impact ≠ Fault / 顧客視点 / ガードレール / 共同責任 / 誤用設計 / 明確さ / 破壊的変更のサーフェシング)を引き出す。 - **AI 支援**: Dynatrace Davis CoPilot による構造化インシデント説明と対処ステップ自動生成をガット感覚への依存低減の実装例として提示。 **新規ページ**: [[@2025__SREcon25EMEA__The Un-Incident]](新規 source)、[[アンインシデント]](新規 concept)、[[Andreas Deuschl]](新規 entity)、[[Dynatrace]](新規 entity)。**更新**: [[インシデント管理]](Un-Incident がライフサイクルの入口の手前にある盲点を構造化するという横断的知見を追記)。 **既存 wiki の文脈**: [[インシデントメトリクス]] での「宣言議論コスト」批判([[Jamie Luck]] / [[Laura de Vesine]])や [[インシデントシミュレーション]] での Near Miss 観察([[Hamed Silatani]])と補完的に読める。「30〜60% のインシデントが非追跡」という数値は自己経験由来のため外部検証が未着手——今後 [[インシデント重大度評価]] の実証研究との比較が必要。 # 2026-07-01: Modernizing Incident Response with LLMs, RAG, and the MCP (SREcon25 EMEA, 2025 | Theofilos Papapanagiotou) [[@2025__SREcon25EMEA__Modernizing Incident Response with LLMs, RAG, and the MCP]]([[Theofilos Papapanagiotou]]、[[Amazon]]、USENIX SREcon25 EMEA、2025-10-08、ダブリン)を wiki 化した。属人化した障害対応知識とツール分断の課題を、[[Model Context Protocol]] による人間・エージェント共通ツールインターフェースと [[RAGベースクラウド運用支援|RAG]](OpenSearch + Bedrock Titan embeddings)で解決する産業実装を報告する 45 分の発表。70 ページ + YouTube Whisper 音声文字起こし。 **核心**: - MCP アーキテクチャ(metrics/logs/tickets/deployments/topology/runbook/ownership の共通ツール群)を、人間セッションの IAM ロールとエージェントランタイムの IAM ロールという異なる権限スコープで同一インターフェースから呼び出す認証設計。 - 中心的主張「自動化ではなく理解を目指した(It wasn't automation, it was understanding)」。同一 Grafana グラフに対し人間とエージェントが近い水準の推論(10分 vs 12分の低下)に至った例を提示。 - Promptfoo によるオフライン評価とユーザーフィードバックのフライホイールでプロンプトを継続改善する評価駆動開発。 - 信頼性の定義を uptime 中心の system reliability から、discoverability・explainability・reasoning を含む cognitive reliability へ拡張する提案。「SRE = Site Reasoning Engineering」という再定義。 # 2026-07-01: Storytelling as an Incident Management Skill (SREcon24 Americas, 2024 | Laura de Vesine) [[@2024__SREcon24Americas__Storytelling as an Incident Management Skill]]([[Laura de Vesine]]、[[Datadog]]、USENIX SREcon24 Americas、2024-03-20、サンフランシスコ)を wiki 化した。デバッグ・コミュニケーション・プロジェクト管理と並ぶ「ストーリーテリング」という技能に焦点を当て、Joseph Campbell の「英雄の旅」のような人物中心の物語形式ではなく、因果の論理で連なる出来事の narrative を組み立てる技能が、オンコール準備・インシデント対応中・ポストモーテム作成のすべての段階を支えると論じる 20 分の発表。18 ページ + Whisper 音声文字起こし。 **核心**: - 「英雄の旅」的な人物中心の物語構造を明示的に否定し、代わりに「出来事の連なりであり、ランダムではなく因果の論理(cause and effect)で結ばれた順序だった一連の出来事」を narrative と定義する。 - インシデント対応中も「協調的ストーリーテリング」としてこの技能を使い、論理連鎖の説明に焦点を当てることで行き詰まった対応者を動けるようにする。 - 人物中心の物語(オンコール準備の pager stories、Wheel of Misfortune 演習)は完全否定せず、目的別に使い分けるべきと整理する。 - 「エンゲージングなポストモーテム」の5段階構成: 舞台設定 → ドラマの追加 → 出来事の連鎖 → 対応の説明 → 修正計画。 - トラブルシューティングの経緯より出来事の連鎖(chain of events)を残すことを選ぶ理由は「人間は直せないが、システムは直せるかもしれないから」。 **新規ページ**: [[@2024__SREcon24Americas__Storytelling as an Incident Management Skill]](新規 source)。**更新**: [[Laura de Vesine]](3件目の SREcon 発表を追加)、[[Datadog]](発表を出典に追加)、[[インシデントストーリー]](因果論理中心/人物中心の使い分けという横断的知見を追加)、[[ポストモーテム]](5段階「エンゲージングなポストモーテム」構成を Nolan のテンプレート批判・Partington の learning > fixing と接続する横断的知見を追加)。 **既存 wiki の文脈**: [[Courtney Nash]]・[[Lorin Hochstein]] が強調する「豊かな社会技術的詳細」の narrative と、de Vesine が推す因果論理中心の narrative は対立ではなく、目的(組織学習 vs. 対応中の意思決定支援)に応じた使い分けとして整合的に読める。 # 2026-07-01: Incident Groundhog Day (SREcon24 EMEA, 2024 | Hamed Silatani) [[@2024__SREcon24EMEA__Incident Groundhog Day]]([[Hamed Silatani]]、[[Uptime Labs]]、USENIX SREcon24 EMEA、2024-10-30、ダブリン)を wiki 化した。20名のインシデントマネージャーが同一ステージドワールドシミュレーション(Black Friday eコマース・APIキー障害シナリオ)を個別体験した実験報告。USENIX 公式ページは WebFetch 403 のため curl+UA でフォールバック取得し、YouTube 自動字幕 VTT を dedup 変換した transcript(1967行) + 代表フレーム31枚(10枚を添付) + 音声を取り込んだ。 **核心**: - **ステージドワールドの構成**: AWS + Kubernetes 上の Online Boutique eコマースを実際に壊したリアルインフラ、AI ボットチームが異なる役割(経験浅い・自信過剰・要求するステークホルダー)を演じる Slack インシデントブリッジ、唯一解なし・潜在条件(Schrodinger's plates)のシナリオ設計。 - **実験結果(20名・同一シナリオ)**: 13/20が25分以内に解決。解決時間と経験・能力レベルは相関せず。SEV1 vs SEV2 の分類差で解決時間に有意差なし。severity 議論に費やした時間が多いほど実際の解決時間が短くなった。 - **Solo Artist vs Band Member**: Recruiting(チーム招集)活動の速さが主要な行動分岐点。Band Member は素早くチームを巻き込み、認知負荷を分散させた。Solo Artist は全ての負担を1人で抱え込んだ。 - **Allspaw の4活動カテゴリの実証**: Diagnostic / Therapeutic / Recruiting / Status-Reporting の4分類を実験データで確認。「治療的行動は即座に診断情報に変わる」——失敗したロールバックが新たな診断シグナルになる特性。 - **Resilience is a verb (David D. Woods)**: 講演の締め括りに引用された言葉。[[レジリエンスエンジニアリング]] との接続。 **新規ページ**: [[インシデントシミュレーション]](新規 concept)、[[Hamed Silatani]]・[[Uptime Labs]](新規 entity)。**更新**: [[インシデント重大度評価]](staged world 実験による実証的補強)、[[Incident Commander]](Solo Artist vs Band Member の行動パターン差)。 # 2026-07-01: Incident Management Metrics that Matter (SREcon25 Americas, 2025 | Jamie Luck, Laura de Vesine) [[@2025__SREcon25Americas__Incident Management Metrics that Matter]]([[Jamie Luck]]・[[Laura de Vesine]]、[[Datadog]]、USENIX SREcon25 Americas、2025-03-27、サンタクララ)を wiki 化した。「MTTR を下げよ」「インシデント件数を減らせ」というビジネス圧力に対し、それらが統計的に不堅牢かつ逆インセンティブを生む理由を体系的に論じ、代わりに何を測るべきかを Datadog の実践から提示する 35 分の講演。ロールプレイ形式(Laura が「新任エンジニアリングマネージャー」、Jamie が「メトリクス懐疑論者 SRE」)。49 スライド(スピーカーノート付き)、transcript なし。 **核心**: - **MTTR の二重の欠陥**: (1) 統計的問題——インシデントは低頻度・高分散イベントで MTTR の変化のほぼすべてがノイズ([[Štěpán Davidovič]] の統計的論証を引用)。(2) 逆インセンティブ——MTTR 最速低下策は「同じインシデントを繰り返す」こと。インシデント件数指標も同様に「スパイシーなバグ」として未申告を促す。 - **インシデントは内部調整プロセス**: 顧客信頼性(customer reliability)と内部プロセス健全さは別物。前者は SLO で測り、後者はプロセスを直接測る。この2つを混ぜてはならない。 - **成熟すると MTTR は上昇するはず**: 本当の根本原因修正をすれば系が複雑になり、次のインシデントはより難解になる。MTTR が下がり続けるのは「同じインシデントを繰り返す」歪んだ最適化の証拠になりうる。 - **4 ステップサイクル**: 01 Alignment(ステークホルダーが goal-based metrics に合意)→ 02 Identifying Goals → 03 Identifying Metrics(複数視点から)→ 04 Define and Expand(フィードバックで継続改善)。 - **Datadog が実際に測る指標群**: ツール操作ミス率・深夜ページ数・IC 不在率・自発的ポストモーテム率・エスカレーションローテーション規模・感情分析・繰り返しインシデント・エグゼクティブサマリー閲覧数・SLO(別プロジェクトとして)など。時間指標はほぼ使わない。 - **DORA について**: 最新版で MTTR は削除され「bad rollout の remediate 時間」(= ロールバック時間)に置換。DORA はコンプライアンス用で内部最適化目標に転用してはならない。 **新規ページ**: [[Jamie Luck]](新規 entity)、[[インシデントメトリクス]](新規 concept)。**更新**: [[Laura de Vesine]](シニアスタッフエンジニアに更新・発表追加)、[[Datadog]](発表追加)、[[インシデント管理]](MTTR は内部 KPI として不適という横断的知見を追記)。 **既存 wiki の文脈**: この講演は [[Štěpán Davidovič]] の [[@2021__OReilly__Incident Metrics in SRE]] の統計的批判と結論が一致しており、Datadog が同じ方向性を産業実践として実装した例となる。本 wiki の「MTTM=304 分・T3 支配」「Detection Is Better Than Cure」などの時間指標は、学術的リファレンス値として保持するが、内部 KPI としての使用は批判的文脈で扱う必要がある。 # 2026-07-01: From 4 Hours to 8 Minutes with AI Agents that Transform SRE Incident Response (SREcon25 EMEA, 2025 | Peter Jausovec) [[@2025__SREcon25EMEA__From 4 Hours to 8 Minutes with AI Agents that Transform SRE Incident Response]]([[Peter Jausovec]]、[[Solo.io]]、USENIX SREcon25 EMEA、2025-10、ダブリン)を wiki 化した。AIRE (AI Reliability Engineering) フレームワークの紹介と、Kubernetes ネイティブの [[kagent]](CNCF サンドボックス)を使ったエージェント型インシデント対応の実装方法を解説する17ページのスライド。transcript なし。 **核心**: - **AIRE の構造**: エージェント = システムプロンプト + ツール + LLM。エージェントループは「メッセージ+指示+ツール → LLM → ツール呼び出し(JSON) → 実行 → 結果フィードバック → 最終応答」の繰り返し。 - **MCP による共有ツールレイヤー**: 各エージェントが Azure/AWS/GCP/GitHub/Slack へのアクセスを個別実装するアンチパターンを、MCP (Model Context Protocol) サーバの共有で解消。 - **A2A プロトコル**: kagent エージェントと CrewAI・ADK・LangGraph など異フレームワーク間の相互運用を A2A (Agent2Agent) プロトコルが担う。 - **AIRE キー能力4段階**(p.15): オペレーション知識の構築 → 状況認識(自律トリアージ) → 並行調査(根本原因仮説生成・検証) → 解決(最小人手介入)。IR Levels の IR3〜IR4 領域に対応。 - **「4時間から8分へ」はタイトルのみの主張**: スライド本文に定量的裏付けデータなし。デモ内容もスライド未記録。 **新規ページ**: [[Peter Jausovec]], [[Solo.io]], [[kagent]]。**更新**: [[インシデントレスポンスAIレベル]](AIRE が IR3〜IR4 の産業実装モデルであること、MCP が IR2〜IR3 実現の共通インフラ層になりつつあることを追記)、[[エージェントシステム運用]](AIRE を AgenticOps の産業フレームワーク例として追記)。 # 2026-07-01: Embracing the Multi-Party Dilemma: Incident Response Across Company Boundaries (SREcon23 EMEA, 2023 | Sarah Butt, Alex Elman) [[@2023__SREcon23EMEA__Embracing the Multi-Party Dilemma - Incident Response Across Company Boundaries]]([[Sarah Butt]]、[[SentinelOne]](登壇時点、2021年時点は Salesforce)・[[Alex Elman]]、[[Indeed]]、USENIX SREcon23 EMEA、2023-10、ダブリン)を wiki 化した。組織境界を越えたインシデント対応で生じる課題のパターン「Multi-Party Dilemma(多者間ジレンマ)」を、Indeed の Learning from Incidents 実践(2021年、Adaptive Capacity Labs 由来のテーマ分析)を出発点に体系化する講演。URL から yt-dlp/ffmpeg/whisper で音声・代表フレーム20枚(7枚を目視確認)・自動文字起こし transcript(147行)を手動フォールバック取得して取り込んだ。 **核心**: - **3種の非対称性**: Multi-Party Dilemma は情報非対称性・影響非対称性・時間的非対称性を特徴とし、特に時間的に圧縮された高圧環境(インシデント)で顕著に現れる。 - **一過性組織と多中心的統治**: インシデント対応中、顧客・ベンダーという2つの官僚制の間に自発的に第三の一過性組織(transient organization)が形成され、意思決定権限が官僚から現場の専門知識保持者へ移る多中心的統治モデル(polycentric governance model)へ移行する。 - **双方向情報共有による近接ミス回避**: CDN ベンダーとの事例では、深いエンジニアリングレベルの双方向情報共有によって、片方だけでは発見できなかったリトライストーム誘発リスクを回避できた。 - **語の来歴**: Multi-Party Dilemma という語自体は [[David D. Woods]] と [[John Allspaw]] が2021年頃から用いており、Woods はこれを「法則的な現象(law-like phenomenon)」と評した。 **新規ページ**: [[Multi-Party Dilemma]](新規 concept)、[[Alex Elman]]・[[SentinelOne]](新規 entity)。**更新**: [[Sarah Butt]](Salesforce→SentinelOne の異動を反映)、[[Indeed]]、[[Laura Maguire]]、[[David D. Woods]]、[[John Allspaw]]、[[Richard I. Cook]]。 # 2026-07-01: Hard Choices, Tight Timelines: A Closer Look at Tradeoff Decisions during Incidents (SREcon24 Americas, 2024 | Laura Maguire, Courtney Nash) [[@2024__SREcon24Americas__Hard Choices, Tight Timelines - A Closer Look at Tradeoff Decisions during Incidents]](Dr. [[Laura Maguire]]、Trace Cognitive Engineering/OSU・[[Courtney Nash]]、The VOID、USENIX SREcon24 Americas、2024-03-19)を wiki 化した。インシデント対応中のトレードオフ意思決定を組織階層をまたいで分析する講演。The Void のインシデントレポートには意思決定の推論過程がほとんど記録されていないという限界に直面し、vignette(状況想定シナリオ)法による追加調査を実施した。全61ページ全確認、transcript なし。 **核心**: - **skip-level tradeoff**: インシデント対応は単一の正解を探す最適化ではなく、限られた時間・情報のもとで複数の望ましい結果のどれを優先しどれを犠牲にするかという選択の連続である。この選択の構造は組織階層をまたいで異なり、上級リーダー・マネジメント層・対応者では重視する軸が異なる。 - **The Void の限界**: 大規模インシデントレポートデータベースは「結果」の集積には強いが、「なぜその選択をしたか」という推論過程の記録には構造的に弱い。この限界を補うため vignette 法を採用した。 - **役割別の考慮事項の相違**(p.19): 上級リーダーは事業継続性・評判・法務リスクを、マネジメント層は人員配置・エスカレーション判断を、対応者はシステム状態把握・復旧速度・認知負荷を重視する傾向がある。 - **Datadog 実例**(p.13): 2023-03-08 の Datadog インシデントにおける当時 CTO Alexis Le-Quoc の発言を引用し、経営層が対応中に何を求めていたかを具体例として示す。 - **トレードオフの越境**(p.43・p.46): ある階層での判断が組織図上の境界を越えて別階層のコスト・便益構造に波及する様子を図示する。 **新規ページ**: [[トレードオフ意思決定]](新規 concept)。**更新**: [[Laura Maguire]](Trace Cognitive Engineering/OSU 所属を反映、Skip-level トレードオフ研究を追加)、[[Courtney Nash]](The Void の限界とトレードオフ研究への展開を追加、status を developing に更新)。 # 2026-07-01: What Is Incident Severity, but a Lie Agreed Upon? (SREcon24 Americas, 2024 | Emily Ruppe) [[@2024__SREcon24 Americas__What Is Incident Severity, but a Lie Agreed Upon?]]([[Emily Ruppe|Em Ruppe]]、[[Jeli]]、登壇時点で [[PagerDuty]] に買収済み、USENIX SREcon24 Americas、2024-03-19、サンフランシスコ)を wiki 化した。severity は「組織内で合意された嘘」であるという Fred Nii の言葉を出発点に、severity を正しく定義することよりも組織内で目的について合意することの難しさを論じる講演。公式ページは WebFetch 403 のため curl+UA でフォールバック取得し、埋め込み YouTube URL から自動字幕 transcript(1634行) + 代表フレーム17枚を全て目視確認して取り込んだ。 **核心**: - **severity は組織的問題のカナリア**: severity を巡る議論の長期化は severity 設計そのものの欠陥でなく、過小評価(underleveling)・過大評価(overleveling)・ステークホルダーへの説明不足・組織の未成熟さといった組織的問題の兆候である。 - **"incident math" の明確な否定**: 緊急度×不確実性のような複雑な多次元マトリクスで priority と impact を単一数式に統合しようとする試みを、登壇者自身の失敗例(「このスライドの写真を撮るな」)とともに明示的に否定する。 - **severity は measurable / actionable / sets expectations / not one-size-fits-all / a canary**: 5命題で severity の要件を定義し、恒久的な仕組みではなく賞味期限があるものとして扱うべきだと結論する。 - **Fisher's Rule**: 「インシデントかどうか迷っているなら、それはインシデントだと宣言せよ」という判断ヒューリスティックを繰り返し強調。 **新規ページ**: なし(既存 entity [[Emily Ruppe]]・[[Jeli]]・[[PagerDuty]] を再利用)。**更新**: [[インシデント重大度評価]](Ruppe の「カナリア」論を Nash・Allspaw の「社交的調整物」批判と突き合わせる横断的知見を追記)、[[Emily Ruppe]]・[[Jeli]]・[[PagerDuty]](新講演・買収関係を反映)。 # 2026-07-01: The Incident Is The Way: Using Your Incidents to Win Reliability Investment (SREcon23 EMEA, 2023 | Niall McCarthy) [[@2023__SREcon23EMEA__The Incident Is The Way - Using Your Incidents to Win Reliability Investment]]([[Niall McCarthy]]、[[Afterpay]] エンジニアリングリーダー、USENIX SREcon23 EMEA、2023-10-11、ダブリン)を wiki 化した。インシデントを信頼性投資を勝ち取る機会として捉え直す4つの実践(システムケイパビリティのマッピング、組織横断の巻き込み、害の共有定義への合意、意図でなく結果の選択)を提示する15分講演。公式ページは WebFetch 403 のため curl+UA でフォールバック取得し、埋め込み YouTube URL から YouTube 自動字幕 transcript + 代表フレーム22枚を全て目視確認して取り込んだ。 **核心**: - **可用性ベースの評価は「正しさ(correctness)」を見落とす**: 「請求書は期限どおりだが金額が誤り」「ページはロードされるが古いオファーを表示」「ジョブはエラーなく完了するが6時間遅延」の3例は、エラー率ゼロ・応答時間良好でも実害あるインシデントに該当する。 - **意図でなく結果を重大度判断の基準にする**: 「6,000人のユーザーが1日半ログインできなかった」という事実は組織内の文脈が何であれ同じように真実であり、エンジニアの意図という交渉可能な変数から重大度判断を切り離す。 - **害の共有定義への合意**: チーム横断でインシデントの「実害」の定義を事前に合意しておくことが、correctness 軸を運用に組み込む前提となる。 **新規ページ**: [[Niall McCarthy]]、[[Afterpay]]。**更新**: [[インシデント重大度評価]](McCarthy の correctness 軸を横断的知見に追記)。 # 2026-07-01: The World Blew Up But We're All Okay: Managing a massive-scale incident at Datadog (SREcon23 EMEA, 2023 | Laurent Bernaille, Laura de Vesine) [[@2023__SREcon23EMEA__The World Blew Up but We're All Okay - How We Managed a Massive-scale Incident at Datadog]]([[Laurent Bernaille]]・[[Laura de Vesine]]、[[Datadog]]、USENIX SREcon23 EMEA)を wiki 化した。2023年3月8日、Ubuntu の自動セキュリティ更新が誘発した systemd/networkd の経路(routing rule)フラッシュにより、AWS・GCP・Azure の複数リージョンで Kubernetes ノードがほぼ同時多発的に接続不能になった大規模インシデントの技術的根本原因と、500人超が対応した組織的インシデント対応の舞台裏を発表。76ページ全確認 + Whisper 音声文字起こし(584行)。 **核心**: - **根本原因**: 2020年の systemd 変更(248 以降・247 バックポート)で networkd 再起動が routing policy rule をフラッシュするようになった。Datadog の Cilium CNI + AWS ENI 直接割り当て構成では、この経路情報が Pod 通信に必須。Ubuntu 22.04(systemd 249)採用ノードのみ影響し、2023年3月7日公開の CVE パッチが自動更新で UTC 6-7時台にほぼ同時適用され、全リージョンで networkd が同時再起動した。 - **クラウド別の被害の非対称性**: GCP/Azure はノード再起動のみで復旧できたが、AWS は ASG ヘルスチェック不良判定でノードが大量に終了・入れ替えられ、ローカルディスク上のステートフルワークロードでデータ損失・クォーラム喪失が発生し、復旧がはるかに長引いた。 - **復旧局面のクラウド API ボトルネック**: 大量ノード同時作成が AWS `CreateNetworkInterfaces` API レート制限・GCP 非公開インスタンスグループ上限・サブネット IP 枯渇・HashiCorp Vault 証明書発行のボトルネックを連鎖的に引き起こした。cilium-operator のバックオフなしリトライバグがこれを悪化させた。 - **組織的対応**: 「you build it, you run it」文化のもと約30人の major-incident-commander ローテーションが自動召集され、70以上のワークストリーム別 Slack チャンネルが自己組織的に発生。単一 Zoom 通話に14時間で493人が入退室(同時在室は最大約30人)。500人超が対応し、1人が連続8時間を超えて対応することはなかった。 - **総括**: 「グローバルなものを持たない」設計方針でも、共通 OS ディストリビューションという共有基盤自体が事実上のグローバル障害波及経路になりうる。事前の綿密な計画よりも、信頼・非難なき文化・即興力が超大規模対応を支えた。 **wiki 上の関連**: [[Datadog]](インシデント対応節を追加、既存 AI Research 節は温存)、[[Laura de Vesine]](silverrose ハンドル追記)、新規 [[Laurent Bernaille]]、[[Kubernetes]](親子クラスタ構成)、[[インシデント管理]](横断的知見3件・未解決の問い1件を追記)。 # 2026-07-01: If I Can Do It on an Ambulance, You Can Do It in an Office: Scalable Incident Response Using ICS (SREcon23 Americas, 2023 | Thai Wood, Resilience Roundup) [[@2023__SREcon23Americas__If I Can Do It on an Ambulance - Scalable Incident Response Using ICS]]([[Thai Wood]]、元 EMT・[[Resilience Roundup]] 主宰の独立コンサルタント、USENIX SREcon23 Americas、2023-03-23、Santa Clara, CA)を wiki 化した。救急医療の Incident Command System(ICS)経験をソフトウェアのインシデント対応に応用し、フル ICS ではなく最小限の「種」から始めることを提案する。YouTube 自動字幕 transcript(34分) + 代表フレーム12枚(全確認済み)。 **核心**: - **「3つの帽子」モデル**: Organizer(調整)・Connector(情報伝達)・Expert(技術対応)を、インシデント対応に最低限必要な core needs として再定義。1人が複数の帽子を兼ねてよく、規模に応じて双方向にスケールする。 - **ランブック批判**: 「You cannot document your way to safety(ランブックは安全を買えない)」。ランブックは書かれた時点で想定した未来であり、実際のインシデントとは乖離しやすいという認識論的限界を指摘。ただし共同でランブックを書く活動自体は「暗黙の前提を洗い出す」価値を持つと明示的に肯定する。 - **practice の重要性**: ゲームデイ・テーブルトップ演習の目的は「次のインシデントの再現」ではなく「チームメイトの逸脱パターン(いつもと違う兆候)を察知できるようになること」。Dr. Richard Cook の「アイススケートは本を読んでは学べない」を引用し、文書化だけでは終わらないと主張。 - **役割は誰でも担える**: EMS の Field Training Officer カード制度を引き合いに、経験の浅いメンバーでも「3つの帽子」のいずれかを担える設計を提案。 **新規ページ**: - [[@2023__SREcon23Americas__If I Can Do It on an Ambulance - Scalable Incident Response Using ICS]](新規 source) - [[Thai Wood]] / [[Resilience Roundup]](新規 entity) - [[Incident Commander]] / [[ダッシュボードとランブックの運用]] / [[GameDay]] / [[Richard I. Cook]](更新 concept/entity) # 2026-07-01: An Organizational Response to Incidents (SREcon23 Americas, 2023 | Laura Maguire, Jeli) [[@2023__SREcon23Americas__An Organizational Response to Incidents]](Dr. [[Laura Maguire]]、[[Jeli]]、USENIX SREcon23 Americas、2023-03-22、Santa Clara, CA)を wiki 化した。Incident Commander という単一役割への組織的関心の集中を問い直し、対応の大半を担う「フォロワー」の働き——**フォロワーシップ(Followship)**——を、SNAFUcatchers・Ohio State University・IBM・New Relic・Salesforce・Etsy・KeyBank・iex 等との共同研究知見から体系化する。101スライド、transcript なし(全ページ画像を目視確認)。 **核心**: - **フォロワーシップの定義**: 「共通目標のために働く経験豊富な対応者たちの適応的コレオグラフィ(adaptive choreography)」。Incident Commander に集中する組織的関心(Attention)の非対称性(p.19「Attention」三角関係図)を出発点とする。 - **調整のパラドックス(coordination paradox)**: メンタルモデルの部分性(Woods, 2017)ゆえに多様な視点の統合が必要になる一方、協働自体が追加の認知負荷(Cost of Coordination)を生む。対応者は DELEGATE/DELAY/DIMINISH/DROP の4戦略で対処する。 - **フォロワーシップが見える8つの行動**: Anticipating・Initiating・Signalling intent・Proactively providing information・Relaxing goals and constraints・Synchronizing・Preparing themselves to be useful・Looking in and listening in。実際の発話例を伴う。 - **共通基盤(common ground)の直接定義**: Maguire 本人が「相互の知識・信念・仮定」と定義し(2020)、team/others/technical system/organization の4象限に整理する。既存 wiki の Klein et al.(2005)経由の定義(Davis・Todd)と突き合わせ、両者は粒度が異なるが整合することを確認した。 - **Reconfiguring(組織再編)**: Jeli の実データで、インシデント対応チームが Front end → Back end → Research → Product → Sales → Customer Success の順に段階的に拡大する様子を可視化。 - **組織的対応の改善フレームワーク Observe/Talk/Analyze**: 対応者間の相互作用の観察・「話し方について話す」共通言語化・事後分析による構造的知見の抽出。 - **Followship と Adaptive Choreography(Davis による Response Trio 引用)の関係を確認**: Maguire 本人がFollowshipの定義に「adaptive choreography」という語を用いており、Davis が別トークで引用していた「Adaptive Choreography」が同一の理論的支柱であったことが裏付けられた。ただし一次資料(Maguire 本人)は「役割分担モデル」ではなく「フォロワー全体の協調行動の総体」というより広い射程で使う。 **新規ページ**: - [[@2023__SREcon23Americas__An Organizational Response to Incidents]](新規 source) - [[Followship]](新規 concept) - [[Laura Maguire]] / [[Jeli]](更新 entity) - [[Incident Commander]] / [[Joint Activity]] / [[Common Grounding]](更新 concept) # 2026-07-01: Epic Incidents of History: The 1979 NORAD Nuclear Near Miss (SREcon23 Americas, 2023 | Nick Travaglini, Honeycomb.io) [[@2023__SREcon23Americas__Epic Incidents of History - The 1979 NORAD Nuclear Near Miss]]([[Nick Travaglini]]、[[Honeycomb.io]] Technical Customer Success Manager、USENIX SREcon23 Americas、2023-03)を wiki 化した。1979年11月9日に Cheyenne Mountain の NORAD で発生した核ミサイル誤警報事件を題材に、Walker・Woods・Rayo(2016)の Distant-Proximal / Blunt-Sharp モデルを分析枠組みとして採用する。34スライド、Whisper は未実行のため YouTube 自動字幕トランスクリプトで補完した。 **核心**: - **単純な root cause analysis の限界**: 国防総省は事件を「オペレーター過誤」として片付けたが、講演は数十年に及ぶ軍事コンピューティング史(第二次世界大戦のアナログ計算機 → [[Vannevar Bush]] の軍産学複合体 → Jay Forrester の Whirlwind → SAGE → NORAD 427M システム)という遠因(distant)の蓄積が、事件当日の技術的偶然(テストテープの誤投入・回線瞬断・シリアル番号の連続性)という近因(proximal)にどう浸透したかを描く。 - **クローズドワールド論**: Paul N. Edwards の『The Closed World』が論じるトルーマン・ドクトリン由来のゼロサム全体化モデルが、正確性への圧力(production pressure)を生み学習を妨げる構造として提示される。Lucy Suchman はこのメンタリティが今日のドローン戦争 AI にも継承されていると論じる。 - **SRE への教訓**: NORAD 職員が代替データソース(PAVE PAWS)との突き合わせと時刻の不整合という「自分の目を信じる」判断で誤警報を看破したことが、データを額面通り受け取らず批判的な問いを立てるという教訓として結び付けられる。 - **既存 concept への裏付け**: [[複雑システム障害論]]・[[根本原因分析]] の「単一根本原因の探索は構造的に成立しない」という命題を、ソフトウェアシステムに限らない歴史的事例で補強した。[[人的要因]] には、オペレーターのローカル合理性(local rationality)に基づく疑いが歴史的規模の惨事を防いだ事例として追記した。 **新規ページ**: - [[@2023__SREcon23Americas__Epic Incidents of History - The 1979 NORAD Nuclear Near Miss]](新規 source) - [[Nick Travaglini]] / [[Honeycomb.io]](新規 entity) **更新ページ**: - [[Vannevar Bush]] / [[複雑システム障害論]] / [[根本原因分析]] / [[人的要因]](更新 entity/concept) # 2026-07-01: Handover Communications in Software Operations: Findings from the Field (SREcon23 Americas, 2023 | Chad Todd, CrowdStrike) [[@2023__SREcon23Americas__Handover Communications in Software Operations - Findings from the Field]]([[Chad Todd]]、[[CrowdStrike]] エンジニア、[[Lund University]] 大学院で人的要因・安全科学を専攻、USENIX SREcon23 Americas、2023-03-21、サンフランシスコ)を wiki 化した。現象学に着想を得た半構造化インタビューという質的研究手法で、CrowdStrike 社内の Network Operations Center・Customer Support Center という性質の異なる2部門を対象に、引き継ぎコミュニケーション([[Handover Communications]])がエンジニアの確信度(Confidence)に与える影響を分析した。38スライド、Whisper transcript(335行)付き。 **核心**: - **分析枠組みは4つの人的要因概念**: [[Joint Activity]]・[[Common Grounding]]・Adaptive Capacity([[レジリエンスエンジニアリング]])・Confidence を用いる。Joint Activity・Common Ground の定義はいずれも [[Gary Klein]] et al.(2005)に、Adaptive Capacity の定義は [[David D. Woods]](2019; p.53)に帰属される。 - **6つのテーマ**: Organizational Context / Evolving Handover Communications / Information Exchange / Preparedness for Handover / Guidance for Handover Communications / Closing the Loop。確認応答(Acknowledgement)の欠如が確信度を下げる核心的要因として位置づけられる。 - **既存 wiki 概念との突き合わせ**: [[Joint Activity]] の原典が Klein et al.(2005)であることを [[Common Grounding]] 側の既存書誌情報と突き合わせて裏付けた。[[レジリエンスエンジニアリング]] では Todd の Adaptive Capacity 定義が Davis(SREcon23)の「即興==Adaptive Capacity」論を補強する横断的知見として追加された。 - **口頭説明の核心エピソード**: 確認応答ボタンを30分待ってから電話をかけた、というエピソードが Closing the Loop テーマの実例として語られた(transcript)。 **新規ページ**: - [[@2023__SREcon23Americas__Handover Communications in Software Operations - Findings from the Field]](新規 source) - [[Chad Todd]] / [[CrowdStrike]] / [[Lund University]] / [[David D. Woods]] / [[Emily Patterson]] / [[Gary Klein]](新規 entity) - [[Handover Communications]](新規 concept) - [[Joint Activity]] / [[Common Grounding]] / [[レジリエンスエンジニアリング]](更新 concept) # 2026-07-01: Dashboards and Runbooks: Scrapbooking for Engineers (SREcon22 Asia/Pacific, 2022 | Colin Douch, Cloudflare) [[@2022__SREcon22APAC__Dashboards and Runbooks - Scrapbooking for Engineers]]([[Colin Douch]]、Cloudflare Observability Platform Team Tech Lead、USENIX SREcon22 Asia/Pacific、2022-12-07、シドニー)を wiki 化した。USENIX 公式ページは会員ログイン必須のため、YouTube 上の同一動画(`llDMcZLTPSc`)から自動字幕 transcript と代表フレーム20枚を取得した。 **核心**: - **ダッシュボードの二極化**: 変数の組み合わせ爆発を招く over-templating と、削除判断がつかず蓄積し続けるインシデント専用の使い捨てダッシュボードという、対称的な失敗様式が discoverability を損なう。 - **ランブック3クラスと本質的一時性**: 自動化可能(automatable)・自由記述(freeform)・無価値(useless)に分類し、良いランブックは自動化への踏み石として本来「一時的」であるべきで、長期存続は自動化文化不在の症状だと論じる。 - **増殖の心理的・文化的動機**: 可視的フィードバックの心理的満足と cargo culting(業界慣習の無批判な継承)を挙げ、事前計装されたテレメトリが障害モードの想定を固定化しトンネルビジョンを生むと指摘する。 - **改善方向**: ライフサイクル管理(作成→保守→削除)の明示、composability(Jsonnet/Pulumi)、SLI/SLO による「成功の定義」先行、メトリクス/ログからイベント・トレーシングへの discoverability/explorability 重視への移行。 **新規ページ**: - [[@2022__SREcon22APAC__Dashboards and Runbooks - Scrapbooking for Engineers]](新規 source) - [[Colin Douch]](新規 entity) - [[ダッシュボードとランブックの運用]](新規 concept) # 2026-07-01: When Systems Flatline—Enhancing Incident Response with Learnings from the Medical Field (SREcon21, 2021 | Sarah Butt, Salesforce) [[@2021__SREcon21__When Systems Flatline - Enhancing Incident Response with Learnings from the Medical Field]]([[Sarah Butt]]、Salesforce SRE、USENIX SREcon21、2021-10-14、バーチャル開催)を wiki 化した。 **核心**: - **アルゴリズム誘導意思決定**: 医療の ACLS(心停止時の決定木)を例に、標準化(誰が担当しても同じ手順が回る)と一般化(詳細な「なぜ」を後回しにし症状を大まかなバケツに分類する)が人的単一障害点・ボトルネックを減らすと論じる。 - **迅速安定化**: ATLS の現場確認→緊急処置→再評価という流れを引き、「正しい問題を正しいタイミングで解く」(原因の深掘りより先に影響を止める)・「静かなもの」への注意(赤いアラートに気を取られず上流の沈黙システムを見落とさない)を提示。 - **標準化とチェックリスト**: WHO 手術チェックリストに倣い、個人・SRE チーム・非 SRE チーム参加者向けの3種チェックリストで、アドレナリン下の記憶漏れを防ぐ設計を提案。 - Goldfuss の Nrrd chatbot(自動チェックリスト配布・属人性排除)と独立に「標準化＝属人性排除」に収斂している点、Collins の Warm Blanket Fallacy とは異なる層(意思決定規律 vs 適用限界)を扱う点を [[Incident Commander]] の横断的知見に記録。 **新規ページ**: - [[@2021__SREcon21__When Systems Flatline - Enhancing Incident Response with Learnings from the Medical Field]](新規 source) - [[Sarah Butt]](新規 entity) # 2026-07-01: Evolution of Incident Management at Slack (SREcon21, 2021 | Brent Chapman, Slack) [[@2021__SREcon21__Evolution of Incident Management at Slack]]([[Brent Chapman]]、Slack Staff Engineer / Reliability Pillar、USENIX SREcon21、2021-10-14)を wiki 化した。 **核心**: - **Google iMAG → Slack IM の系譜**: Chapman は Google SRE 時代に iMAG(Incident Management At Google)を開発した実践者本人であり、その原型は公共安全機関の ICS(航空捜索救難・CERT 経験由来)。Slack でも同じ原則からゼロ構築した。 - **2018年9月 reliability crisis が引き金**: 緩いリリース体制による自己誘発障害の連鎖を機に、Deploy Commander制・段階的カナリアロールアウト・Service Ownership 移行・Incident Management 構築の3本柱改革を実施。 - **Major IC の7課題と解決策**: 地域間負荷格差→SF週末対応/現地増員、個人責任過多→Bat Signal、タスク過多→IC Checklist、同時多発→Slack IC、リソース競合→Area Command、長期化→EMへの引き継ぎ、特定チーム偏在→pillar別ローテーション。 - **定量データ**: IC訓練率目標15%に対し実績約25%、中央値インシデント時間124分(約2/3が4時間以内解決)。 - **Incident Review no-give-backs**: IC最後の責務はEM指名のみ。指名は「後戻りなし」でIC自身はレビューを主導しない。 **新規ページ**: - [[@2021__SREcon21__Evolution of Incident Management at Slack]](新規 source) - [[Brent Chapman]](新規 entity) **更新ページ**: - [[Slack Technologies]]: 2018年 reliability crisis と3本柱改革の経緯を追加。 - [[PagerDuty]]: Slack の IC/Responder 訓練クラスの土台に関する言及を追加。 - [[インシデント管理]]: Response/Review/Analysis 3部構成を検知→トリアージ→診断→緩和ライフサイクルと対比する横断的知見を追加。 - [[Incident Commander]]: Area Command・iMAG系譜・IC訓練率実績・no-give-backsハンドオフの横断的知見4件を追加。 **制限**: - 登壇後 Q&A は音声に収録されておらず不明。 - pillar別ローテーションの「2つの pillar」の具体名は不明。 - Slack IC 同時稼働数「最大3名」は2021年時点の値。 --- # 2026-07-01: The Math behind the Incident Aftermath (SREcon22 APAC, 2022 | Ashish Patel / Sriram Srinivasan, PayPal) [[@2022__SREcon22APAC__The Math behind the Incident Aftermath]]([[Ashish Patel]] / [[Sriram Srinivasan]]、[[PayPal]] Site Reliability Platform Engineering / Technical Architect、SREcon22 APAC、2022-12-07、シドニー)を wiki 化した。 **核心**: - **FCI(Failed Customer Interactions)**: インシデントの顧客影響を、ベースライン予測トラフィックとの乖離(欠損した成功件数)+明示的にエラーを受けた件数(Missed CI)の合算で定量化する単一指標。 - **Availability への変換**: FCI をベースライン件数で正規化して可用性指標を算出。実例: Baseline 99.9990% vs 実測 99.6171%、FCI 33,322件、Missed CI 0件。 - **5軸セグメンテーション**: 国・製品・ビジネス指標・マーチャント・ユニーク顧客ごとに影響内訳を可視化(例: UK 352件30%、Germany 313件27%)。 - **自動化パイプライン**: アラート発報・手動トリガーからモデル計算・投稿までを自動化するアーキテクチャ。Xoom・Braintree 等の他事業部への展開を構想。 - **開発課題**: ユーザー入力への依存度・テストの難しさ・自動サジェスト構築の困難・分単位集計による近似誤差。 **新規ページ**: - [[@2022__SREcon22APAC__The Math behind the Incident Aftermath]](新規 source) - [[Ashish Patel]](新規 entity) - [[Sriram Srinivasan]](新規 entity) - [[PayPal]](新規 entity) - [[インシデント影響測定]](新規 concept) **制限**: - 発表動画(Presentation Video)は USENIX 会員ログインが必要で未取得。口頭説明・質疑応答は反映できていない。 - p.27 の国別セグメンテーション表は上位4か国のみ画像から明瞭に判読できた。 --- # 2026-07-01: Incident Response in Unfamiliar Sociotechnical Systems (SREcon20 Americas, 2020 | Morgan Collins, Salesforce) [[@2020__SREcon20Americas__Incident Response in Unfamiliar Sociotechnical Systems]]（[[Morgan Collins]]、[[Salesforce]] Principal SRE、SREcon20 Americas、2020-12-07〜09、バーチャル開催）を wiki 化した。 **核心**: - **ICS の起源は FIRESCOPE**: 1960年代のカリフォルニア山火事急増と1970年シーズンの連携不全を機に FIRESCOPE タスクフォースが構築した指揮体系が ICS の原型。 - **民間企業向け ICS の再編**: 公共 ICS の Command Staff(PIO/Safety/Liaison)を省略し、Operations/Planning/Logistics/Finance を Triage and Diagnosis・Incident Documentation・Incident Communications・Subject Matter Expert という目的特化型に置き換える。静的・事前配置の役割期待が強く、相互援助は主要な関心事にならない。 - **Warm Blanket Fallacy**: 熟練 Incident Commander の存在は、不慣れな環境(他組織との連携)における結果を保証しないという誤謬。対策は支援合意の事前確立・共通基盤の構築・Coordination > Command への注力。 - **COVID-19 が組織間対応を頻発させた**: リモートワーク急増・利用スパイクの不均一化、リソーシングと経験の不一致、顧客忍耐の低下という3条件。 **新規ページ**: - [[@2020__SREcon20Americas__Incident Response in Unfamiliar Sociotechnical Systems]](新規 source) - [[Morgan Collins]](新規 entity) - [[Salesforce]](新規 entity) **更新ページ**: - [[Incident Commander]]: Warm Blanket Fallacy・民間 ICS 再編構造を横断的知見に追加。ICS 起源について本ソース(FIRESCOPE・カリフォルニア)と [[@2016__SREcon16__nrrd 911 ic me - The Incident Commander Role]](Goldfuss、フェニックス・1968年)との食い違いを `> [!contradiction]` callout で記録。 **制限**: - 音声・動画・transcript は取得できず、口頭説明・Q&A は反映できていない。 - COVID-19 下の3課題(利用スパイク・リソーシング不一致・顧客忍耐低下)は定量データなし。 --- # 2026-07-01: Incident Response @ FB, Facebook's SEV Process (SREcon16 Europe, 2016 | Gareth Eason, Facebook) [[@2016__SREcon16__Incident Response @ FB, Facebook's SEV Process]]（[[Gareth Eason]]、[[Facebook]] プロダクションレビュー(EMEA)運営者、SREcon16 Europe、2016-07、Dublin）を wiki 化した。 **核心**: - **「発見者=オーナー(Discoverer is the Owner)」原則**: SEV を最初に発見した人物が、他の担当チームへ引き渡すまで一次責任を負う。担当不明のまま放置される事態を防ぐ運用規則。 - **SEV1 への意図的過大分類バイアス**: リスクがあれば SEV1 に倒し、状況が判明してから格下げする方針。過小分類による対応遅延を防ぐ。 - **IMOC(Incident Manager on Call)の非技術的定義**: IMOC の役割は「技術的にインシデントを直すこと」ではなく、関係者間の調整・コミュニケーションの一本化にあると明示。「blame umbrella(非難を防ぐ傘)」「human mutex(人間による排他制御)」という独自の比喩で表現。 - **二段階レビューと3つの質問**: 週次 Production Review で「何が起きたか」「なぜ起きたか」「再発防止に何をするか」の3問に基づき議論。Jay Parikh・Pedro Canahuati ら幹部が定期出席。 - **メトリクスゲーミング警告(2016年時点)**: 「SEV 数を減らすことを成功指標にすると、エンジニアが SEV1 を過小分類したり報告しなくなったりするインセンティブを生む」と明示的に警告。Goodhart の法則のインシデント管理領域における早期の実務者証言。 - **canary インシデント事例**: 段階的ロールアウト中の異常検知パターンを実例として提示。 **新規ページ**: - [[@2016__SREcon16__Incident Response @ FB, Facebook's SEV Process]](新規 source) - [[Gareth Eason]](新規 entity) **更新ページ**: - [[Facebook]]: SEV Process/Production Review 節を新設。Discoverer=Owner・過大分類バイアス・メトリクスゲーミング警告・canary インシデントを追記 - [[Jay Parikh]]: Eason 講演での Production Review 出席の独立言及を追記(「head of infrastructure」表記が2015年講演の「Head of Engineering」と異なる点を注記) - [[Pedro Canahuati]]: Eason 講演での Production Staff Review 出席の独立言及を追記(「head of engineering」表記が2015年講演の「Production Engineering ディレクター」と異なる点を注記) - [[Incident Commander]]: IMOC の「技術的に直さない」原則が New Relic(Goldfuss, 2016)と独立に同年確立していたという横断的知見、および blame umbrella/human mutex という独自比喩の横断的知見を追記 - [[インシデント重大度評価]]: 単一レベル方式(SEV1/2/3)における意図的過大分類という緩和策と、Severity KPI 化の危険性への最古級の明文化された警告として追記 - [[クロスインシデント分析]]: Granda(2025年、Enova)の「数値はコンテキストなしでは意味がない」という洞察に約9年先行する明文化された前例として追記 **制限**: - 固定広角カメラのため、スライド細部(SEV分類の色分け表など)は判読不能な箇所が複数あり、source ページで「画角外」「判読不能」と明記した。 - USENIX 公式ページに正確な講演日の記載がなく、transcript の「day two」自己言及とカンファレンス開催期間(2016-07-11〜13)から 2016-07-12 と推定した(推定である旨を明記)。 - Q&A の質問者名は特定できず、記録しなかった。 # 2026-07-01: You Can't Stop Fires with an Ambulance (SREcon18 Asia, 2018 | Piers Chamberlain, Xero) [[@2018__SREcon18Asia__You Can't Stop Fires with an Ambulance]]（[[Piers Chamberlain]]、[[Xero]] Head of Site Reliability Engineering、SREcon18 Asia/Australia、2018-06、シンガポール）を wiki 化した。 **核心**: - **クラウド移行(2016年)後のアラート倍増・インシデント増加への対応**: 物理データセンターからのクラウド移行を機にアラートが急増し、月次インシデント数も2016年2月〜2018年3月にかけて明確な増加トレンドを示した。 - **[[Klaxon]]: 顧客観測ベースの症状ベースアラート**: エラーページ・ステータスページ(status.xero.com)へのアクセスヒット率を Error API→SQS→Klaxon Scheduled Lambda→SumoLogic→DataDog→Slack/メンテナンスモード更新の経路で検知する自己修復的アーキテクチャ。CPU credit burn・LB最小ホスト数割れのような一般的な症状ベースアラートに加える「安全網」として機能する。 - **[[Multivac]]: war room を代替するインシデント管理 chatbot**: 標準化された対応プロセスの自動化と post-mortem 文書の自動生成。詳細アーキテクチャは同僚 Karthik の別セッションに譲る。 - **2年分の post-mortem を手動で横断集計**: 専任チームなし・非構造化データのまま発表者本人が数百件を stack-rank し、`#release`(リリースプロセス、約29件)が `#capacity`(約8件)の約4倍で最大の contributing cause と発見。 - **[[Report Card]]: 運用衛生スコアリングによる経営層巻き込み**: SLO 定義・レイテンシ・アラート疲労・必須タグ・スタック更新状況を採点(デモでは総合スコア76)。tech leads・product owners・senior management という3グループを「developer productivity」「customer impact」「business goals」の言語で巻き込むキャンペーンとして紹介。 - **結びの3教訓**: トレンドを発生時から追跡せよ／正しい人を巻き込め／正しい言語を使え。post-mortem アクション実施率は約50%(Created vs Resolved Issues Report)。 **新規ページ**: [[@2018__SREcon18Asia__You Can't Stop Fires with an Ambulance]] / [[Piers Chamberlain]] / [[Xero]] / [[Klaxon]] / [[Multivac]] / [[Report Card]] **更新ページ**: [[アラート管理]](Klaxon の顧客観測ベース安全網アラート・Ewaschuk論文言及を追加) / [[クロスインシデント分析]](専任チームなしの単独手動集計を Granda 3要素との対比として追加) # 2026-07-01: Fixing On-Call When Nobody Thinks It's (Too) Broken (SREcon19 Americas, 2019 | Tony Lykke, Hudson River Trading) [[@2019__SREcon19 Americas__Fixing On-Call When Nobody Thinks It's (Too) Broken]]（[[Tony Lykke]]、[[Hudson River Trading]] Trade Systems SRE、SREcon19 Americas、2019-03-25）を wiki 化した。 **核心**: - **6年間の71,317件(週平均201件、最悪月2,327件)を4か月で1,015件(週平均56件)まで削減**: 高urgency PagerDutyページの実績値。着任わずか5か月・オンコール担当ですらなかった立場からの取り組み。 - **「9 Really Hard Steps」フレームワーク**: audience理解→問題理解→システム理解→計画立案→(任意で)許可取得→下地作り→低リスク施策から着手→コミュニケーション→7に戻る。技術より組織的合意形成に大半を割く。 - **最小限のアーキテクチャ変更**: Master NagiosとPagerDutyの間にPython製drop/downgrade/groupフィルタ層を追加するのみ。既存の監視基盤自体は壊さない設計判断。 - **git shortlogによるバイイン可視化**: 懐疑的だった同僚のコミット数が5→765へ推移したことを定量的に示し、心理的な信頼転換を裏付けた。 - **アラート削減自体が「沈黙への不安」という副作用を招いた**: 「ページャーの沈黙=監視が壊れている兆候」という歴史的連想により、ページを一晩で半減させたことがチームの不安を招いた。ミュート可能なSlackログチャンネルでの受動的可視性提供により緩和。 **新規ページ**: [[@2019__SREcon19 Americas__Fixing On-Call When Nobody Thinks It's (Too) Broken]] / [[Tony Lykke]] / [[Hudson River Trading]] **更新ページ**: [[アラート疲労]](統合的アプローチの具体例、沈黙への不安という副作用の横断的知見2件・未解決の問い2件を追加) # 2026-07-01: nrrd 911 ic me: The Incident Commander Role (SREcon16 Americas, 2016 | Alice Goldfuss, New Relic) [[@2016__SREcon16__nrrd 911 ic me - The Incident Commander Role]]（[[Alice Goldfuss]]、[[New Relic]] SRE、SREcon16 Americas、2016-03）を wiki 化した。 **核心**: - **ICS 草創期の産業実践**: 2012年クリスマス前の3日間インシデント（修復でなく「調整コスト」が律速）を機に ICS を社内展開。ICS 起源は 1968年アリゾナ州フェニックスの森林火災対応、2004年 NIMS 義務化。 - **3役分離の徹底**: IC（指令・調整）・TL（修復）・CL（外部コミュニケーション）は厳格に分離。IC が最有能な修復者なら IC 役を他者に渡して TL に回るべき。 - **Sev1 拡張役割**: EC（Emergency Commander: IC と会社ステークホルダーのリエゾン）と LL（Logistics Lead: ピザ・シフト・帰宅指示）が Sev1 で解放される。 - **全員訓練・任意立候補**: 全工学部門を IC 候補として訓練。快適な者が任意で立候補する。 - **Hubot/Nrrd**: `nrrd 911 ic me` 一行で役割宣言・チェックリスト配布・10分未ステータスの自動促進を実現。 - **ROI**: 「3日間→3時間」—— ICS 前後で同種 Sev1 の対応時間を実測比較した唯一のソース。 **新規ページ**: [[@2016__SREcon16__nrrd 911 ic me - The Incident Commander Role]] / [[Alice Goldfuss]] **更新ページ**: [[New Relic]] / [[Incident Commander]]（ICS 起源・役割構成・重大度表・横断的知見3件追加） # 2026-07-01: Software Engineering (Boehm, IEEE-TC 1976) [[Barry W. Boehm]] による 1976 年の古典的サーベイ論文 [[@1976__IEEE-TC__Software Engineering]] を wiki 化した。 **核心**: - **欠陥修正コストの法則**: 要件フェーズで発見・修正するコストを 1 とすると、運用フェーズでは 15〜100 倍になる(IBM・GTE・TRW の実証データ)。早期発見の投資対効果は極めて高い。 - **設計エラー優位**: TRW・IBM の複数プロジェクトでコーディングエラーに対する設計エラーの比率は 60:40 超。テストより設計フェーズの品質保証が重要。 - **保守がコストの主役**: ほぼすべての組織でソフトウェア保守がライフサイクルコストの 60〜75% を占める。1976 年に初めて定量化されたが構造的問題は今も続く。 - **Area 1 vs Area 2**: 専門家による詳細設計・コーディングには科学的原理が存在するが、技術者による応用ソフトウェアの要件・設計・テスト・保守(Area 2)にはほぼ皆無。最も切迫した問題領域が最も基礎的貧困を抱えている。 **新規ページ**: - [[@1976__IEEE-TC__Software Engineering]](source 新規) - [[Barry W. Boehm]](entity 新規) - [[TRW Systems and Energy Group]](entity 新規) - [[ソフトウェアライフサイクル]](concept 新規) - [[ソフトウェア要件工学]](concept 新規) - [[ソフトウェア保守]](concept 新規) # 2026-07-01: Unified Theory of SRE (SREcon22 EMEA, 2022 | Emil Stolarsky, Wave Mobile Money) [[@2022__SREcon22 EMEA__Unified Theory of SRE]]（[[Emil Stolarsky]]、[[Wave Mobile Money]]、SREcon22 EMEA、2022-10）を wiki 化した。 **核心**: - **SRE Book は 2400+ インフラエンジニアを抱える Google 固有の観点から書かれている**: 70+ 名の著者・数十チームの貢献者・2016 年時点で 1200+ SRE（AT LEAST 1200+ SWE）という規模前提が埋め込まれており、それを小規模組織に無批判に適用するとカーゴカルティングになる。 - **スタートアップ（Default Dead）では開発速度が最優先で信頼性は二次的**: Default Dead（PMF 未達）フェーズでは、SRE の最大貢献は開発者インフラ（開発環境・CI・デプロイ）の整備であり、Kubernetes のような複雑な本番技術は不要。「Boring Technology の原則」と「イノベーショントークンを消費しない技術選定」が処方。 - **FAANG と大多数の技術フロンティア格差**: FAANG が技術の最先端で運用しているのに対し、大多数のサービスはシンプルであり、設計の標準化が可能。 - **SLO より先にプロダクトの価値観を定義する**: スタートアップでは純粋な SLO 議論より「古いデータを返すか・エラーを返すか」等のトレードオフ方針（プロダクトの価値観）を先に定義することが有益。 **新規ページ**: - [[@2022__SREcon22 EMEA__Unified Theory of SRE]](新規 source) - [[Emil Stolarsky]](新規 entity) **更新ページ**: - [[SRE]]: 横断的知見に SRE Book の規模前提・スタートアップ SRE 再構築・FAANG フロンティア格差の 4 項目を追加。未解決の問いを更新。ソース・エンティティ参照を追加。 **制限**: - transcript は YouTube 自動字幕（confidence: medium） - SREcon22 EMEA の正確な登壇日（Oct 25-27 の内）は特定できていない # 2026-07-01: Incident Management and Chatops @ Netflix Feat Scorebot (SREcon16, 2016 | Al Tobey, Netflix) [[@2016__SREcon16__Incident Management and Chatops @ Netflix Feat Scorebot]]（[[Al Tobey]]、Netflix SRE、SREcon16 2016-03-16）を wiki 化した。 **核心**: - **Scorebot の誕生とインシデント管理 ChatOps**: 2015 年 12 月生まれの Go 製チャットボット Scorebot は、SRE が反復実行していた機械向けタスク(人員グラフ探索・画像アーカイブ・ステータスページ更新)を Slack 上で自動化する。Netflix の Hipchat → Slack 移行(frame-001 "Green Lantern → Deadpool")直後の実践。 - **4 つの「itch」(ペインポイント)**: callbacks(コールバック管理)・testing(ボットのテスト困難)・「we require more context」(StarCraft Probe、文脈収集)・「the bot is obnoxious」(Bender、過剰通知)。 - **4 つの「scratch」(設計解)**: bookmarking(「Fixed point in time. I am so sorry.」Doctor Who、インシデント開始時刻の固定)・presence(在席確認と通知)・after-hours(時間外担当者特定)・secrets(クレデンシャル管理)。 - **leaky abstraction の正直な提示**: ソリューション側の設計問題を「scratch: leaky abstraction」として明示。 - **産業 AIOps の先駆文脈**: SAS(Microsoft, 2011-2013)が機械学習による診断の先駆なら、Scorebot(Netflix, 2015-2016)はチャットボットによる操作自動化の先駆。両者は LLM エージェント型インシデント管理の異なる介入軸の原型。 **新規ページ**: - [[@2016__SREcon16__Incident Management and Chatops @ Netflix Feat Scorebot]](新規 source) - [[Al Tobey]](新規 entity) - [[ChatOps]](新規 concept) **更新ページ**: - [[Netflix]]: SREcon16 Scorebot 発表・[[Al Tobey]] を言及に追加 - [[インシデント管理]]: ChatOps/Scorebot を LLM 以前の産業自動化として横断的知見に追記 **制限**: - transcript は Whisper 処理中(small モデル、~20分音声)。口頭説明・Q&A の詳細は transcript 完成後に source ページを補完する必要あり。 - 12 枚の代表フレームはスライドの一部のみ。デモ画面やコード例は未確認。 # 2026-07-01: Notes from Production Engineering (SREcon15, 2015 | Pedro Canahuati, Facebook) [[@2015__SREcon15__Notes from Production Engineering]]（[[Pedro Canahuati]]、Facebook Production Engineering ディレクター、SREcon15 2015-03-13）を wiki 化した。 **核心**: - **Facebook の SRE 組織変革 5 段階**: Re-org（SRE→SRO+AppOps）→ Hiring（4 次元＋文化の採用基準）→ Leadership（エンジニアのオンコール巻き込み、SRO 解散）→ Post Mortems（週次 SEV レビュー制度化）→ Embedded Ops（AppOps→Production Engineering 改名） - **SRO の生命周期（2010-2014）**: 集中型 24 時間監視チームが「クラッチ」として各ソフトウェアチームの自立を阻む。データ駆動のアプローチで段階移行し 2014-03-31 に解散 - **「FIX MORE, WHINE LESS」**: Tシャツ印刷・インフラ全員配布という物理的可視化で文化を定着させた。Jay Parikh が週次 SEV レビューに同席しリソース決定を即座に行う構造的担保 - **FBAR**: 1 日 13,600 人時相当の自動化。壊れたサーバの検出→除外→修復の階層型 Remediation プラグイン構造 - **「ops」という語が文化をリセットする**: AppOps→Production Engineering への改名は、新入りエンジニアが前職モデルを持ち込むことで変革がリセットされるループを断ち切るために必要だった **既存 wiki との接続**: - [[SRE組織変革]](更新): Facebook 固有の 5 つの横断知見を追加（物理的障壁・ops 語の影響・SRO クラッチパターン・経営層後ろ盾の機能・採用基準の先行性） - [[ポストモーテム]](更新): Facebook SEV レビュー実践と「FIX MORE, WHINE LESS」スローガンの物理的可視化手法を追加 - [[Facebook]](更新): Production Engineering セクション新設（SRO/AppOps/PE 組織史・FBAR・Cobalt・ODS・週次 SEV レビュー） - [[Pedro Canahuati]](新規): Facebook Production Engineering ディレクター - [[Jay Parikh]](新規): Facebook エンジニアリング責任者 **制限**: - transcript は YouTube 自動字幕由来（confidence: medium） - 一部の固有名詞・数値は映像フレームで確認済み、字幕のみ由来の数値は不確実扱い # 2026-07-01: Keys to SRE (SREcon14, 2014 | Ben Treynor Sloss, Google) [[@2014__SREcon14__Keys to SRE]]（[[Ben Treynor Sloss]]、Google VP Engineering、SREcon14 2014-06-26）を wiki 化した。 **核心**: - **SRE の本質的定義の初公開**: 「ソフトウェアエンジニアに運用を設計させるとどうなるか」を 2014 年に初めて公開の場で言語化した。SRE Book（2016）より 2 年早い。 - **13 のキー**: コーダーのみ採用・SLA 定義・エラーバジェット・ローンチオンブラック・共通人材プール・50% 運用キャップ・5% 開発オンコール・移植可能性・8 名最小オンコール・シフト最大 2 件・全イベントポストモーテム・無責非難が提示された。 - **ローンチオンブラックルール**: SLA 遵守中なら自由にローンチ、違反中は全凍結という明示的二値ルールがエラーバジェットの運用実施形態として提示された。SRE Book のバーン率制御への前段。 - **移植可能性の nuclear option**: SRE チーム解散→メンバー他チームへ異動という「核」は実際に年 1〜2 回行使される。この信頼性が開発チームへの抑止力として機能する。 - **Wheel of Misfortune**: 定期訓練が MTTR を 50〜70% 削減すると明言。SRE Book の自動化のアイロニー論への接続。 - **無責非難のポストモーテム**: 全員善意・システム修正・バグ追跡という 2014 年原型。Gallego（2016-2018）の理論精緻化との知的系譜が確認できる。 **既存 wiki との接続**: - [[SRE]](更新): 13 のキーが SRE Book より操作的規則として先行する横断知見を追記 - [[エラーバジェット]](更新): ローンチオンブラックと開発チーム自浄メカニズムの 2014 年原型を追記 - [[ポストモーテム]](更新): 無責非難原則の 2014 年公言と後の理論精緻化との知的系譜を追記 - [[Ben Treynor Sloss]](更新): SREcon14 講演追加、status developing に昇格 **制限**: - transcript は YouTube 自動字幕由来（confidence: medium） - 映像フレーム未取得（動画ダウンロード進行中） # 2026-06-30: Xpert — インシデント管理向け KQL クエリ推薦 (ICSE 2024 | Jiang+, Michigan / Microsoft) [[@2024__ICSE__Xpert - Empowering Incident Management with Query Recommendations via Large Language Models]]（[[Yuxuan Jiang]] ほか 10 名、[[University of Michigan]] / [[Microsoft]]、ICSE 2024）を wiki 化した。 **核心**: - **問題**: OCE がインシデント調査に使う KQL クエリの記述は高いドメイン知識を要し時間を消費する - **KQL 実証知見**: インシデントの 50% 以上が KQL 1 件のみ使用。クエリはサービス間で非移転性。月次で顕著な時変性 - **Xpert**: LLM(GPT-4)の ICL + Faiss ベクター検索による類似インシデント例示 + 後処理器(構文・意味チェック+修正)を統合したエンドツーエンドフレームワーク - **Xcore**: 有効性(V)・サブコンポーネント一致(S)・出力スキーマ一致(O)の加重和。BLEU/METEOR が見逃す KQL 品質問題を静的解析で捕捉 - **性能**: GPT-4 版が全指標で最高。Identicality で CodeT5+(20.00%)を 35.46% で凌駕。LLM は平均 7.41 例示のみで 200k 件 fine-tune モデルを上回る - **本番**: Microsoft インシデント管理システムに約 1 ヶ月デプロイ。Online Xpert は Identicality 18.12 vs CodeT5+ Online 2.62 **既存 wiki との接続**: - [[DSLクエリ推薦]](新規概念): KQL クエリ自動生成の実証的特性・LLM の ICL 優位性・Xcore の設計を収録 - [[インシデント管理]] / [[LLMによる根本原因分析]]（更新） **新規エンティティ**: [[Zhihao Yang]] **新規概念**: [[DSLクエリ推薦]] # 2026-06-30: ART: A Unified Unsupervised Framework for Incident Management in Microservice Systems（ASE 2024 | Yongqian Sun ほか, Nankai University） [[@2024__ASE__ART - A Unified Unsupervised Framework for Incident Management in Microservice Systems]]（[[Yongqian Sun]]・[[Binpeng Shi]]・[[Mingyu Mao]] ほか、[[Nankai University]] / [[Tsinghua University]]、ASE 2024）を wiki 化した。 **核心**: - **問題**: 既存のインシデント管理手法は AD/FT/RCL のいずれか 1 タスクしか扱わず、複数タスクをパイプライン化すると誤差が伝播するうえ訓練ラベルが必要 - **手法**: 正常データのみで SSL 事前学習(MSE 損失)し、K 次元のインスタンスレベル偏差(ILD)とシステムレベル偏差(SLD)を獲得。下流 3 タスクをすべてこの偏差表現から教師なし手法(EVT 閾値・カットツリー・コサイン類似度ランキング)で解く - **依存関係モデル化**: CHA(Transformer Encoder)→TEM(GRU)→CAL(GraphSAGE)の順で細粒度→粗粒度に積み上げる。この順序が最良であることをアブレーションで確認(D2 FT F1: 順序正 0.802 → 順序逆 0.570) - **実証研究**: 障害時の SLD L₁-ノルムが正常時比 +22%、根本原因インスタンスの ILD-SLD コサイン類似度 0.71〜0.77 vs 非根本原因 0.49。3 タスク全て「偏差の共有性」で解ける経験的証拠を提示 - **実験**: 2 データセット(D1 Online Boutique 10s、D2 12 ms)で Dejavu・DiagFusion・Eadro を FT・RCL の両タスクで上回る **新規ページ**: entity [[Mingyu Mao]](第三著者、Nankai University、新規) **更新ページ**: [[Yongqian Sun]] / [[Binpeng Shi]] / [[Sibo Xia]] / [[Shenglin Zhang]] / [[Dan Pei]] / [[Minghua Ma]] / [[マルチモーダル障害診断]] / [[Fault Localization]] / [[AIOps]] --- # 2026-06-30: AI Assistants for Incident Lifecycle in a Microservice Environment — SLR（arXiv 2410.04334 | Dahlia Ziqi Zhou・Marios Fokaefs, York University） [[@2024__arXiv__AI Assistants for Incident Lifecycle in a Microservice Environment - A Systematic Literature Review]]（[[Dahlia Ziqi Zhou]]・[[Marios Fokaefs]]、[[York University]] EASE ラボ、arXiv 2410.04334、2024-10-06）を wiki 化した。 **核心**: - **問題**: マイクロサービスのインシデントライフサイクルを支援する AI アシスタントの研究が 2021 年以降急増しているが、分野の俯瞰的知識が欠けている - **手法**: SEGRESS 準拠の SLR。309 件の候補論文から 4 段階でスクリーニングして 31 件を選定（Sankey 図参照） - **RQ1(フェーズ分布)**: Detect 54.8%・Contain 35.4%・Prepare 9.7%・Post-incident 3.2%。Prepare と Post-incident が研究上の空白 - **RQ2(AI タスク)**: 異常検知 41.9%・RCA 35.5%・予測 12.9%・軽減 8.1% - **RQ3(AI 手法)**: LLM 38.7%・DL 32.2%・Traditional ML 9.68%・Combined 19.4% - **RQ4(データ)**: ログ 48.4%・トレース 29%・メトリクス 25.8%。非伝統的ソース(過去インシデントレポート・依存グラフ・コードリポジトリ)が機会として特定 - **課題**: 31 件中ユーザースタディは 5 件のみ(Oasis・Groot・LLMAD・mABC・Zhang+[25])。評価の多くがベンチマーク偏重 **更新した概念ページ**: - [[インシデント管理]]: Prepare/Post-incident 過少研究の定量化(RQ1)を横断的知見に追記 - [[根本原因分析]]: SLR での RCA 35.5% 位置づけ・mABC ユーザースタディ確認を横断的知見に追記 - [[異常検知]]: 異常検知が最大目標 41.9% かつ LLM ベース手法の制約との衝突を横断的知見に追記 - [[LLMによる根本原因分析]]: LLM 38.7% 急台頭・mABC の独立確認・研究–実用断絶を横断的知見に追記 **新規 Entity**: [[Dahlia Ziqi Zhou]]、[[Marios Fokaefs]]、[[York University]] **図**: Sankey 図(309→44→31 選定)、発表年分布バーチャート(2021-2024 急増を視覚化) # 2026-06-30: FaultProfIT — クラウドポストモーテムの障害パターンプロファイリング自動化（ICSE-SEIP 2024 | Huang+, CUHK / SYSU / Huawei Cloud） [[@2024__ICSE-SEIP__FaultProfIT - Hierarchical Fault Profiling of Incident Tickets in Large-scale Cloud Systems]]（[[Junjie Huang]] ほか 9 名、[[The Chinese University of Hong Kong]] / [[Sun Yat-sen University]] / [[Huawei Cloud]]、ICSE-SEIP 2024）を wiki 化した。 **核心**: - **問題**: クラウドシステムのポストモーテム分析で必須の「障害パターンプロファイリング」は手動が現状。深刻度の高いインシデントにしかポストモーテムが行われず、S4/S5 の軽微インシデントは放置され傾向が見えない - **定義**: 障害パターン = 特定コンポーネントに現れる異常振る舞いの簡潔表現（障害名・現象例・緩和措置）。Huawei Cloud のタクソノミは 5 階層・7 上位カテゴリ・334 葉ノード - **アプローチ**: Graphormer（Transformer ベース GNN）で 5 階層タクソノミ DAG をエンコードし、Gumbel-Softmax による重要トークン選択で正サンプルを生成、NT-Xent 対照学習で階層対応インシデント表現を学習 - **性能**: F1=78.3%（HiAGM 75.1%・ChatGLM 62.5%・MacBERT 60.1%・DPR 54.1%を上回る）。1,463 件ラベル付き事例（全 22,560 件中）の 80/10/10 分割で評価 - **デプロイ実績**: 6 ヶ月間 Huawei Cloud の信頼性分析プラットフォーム（Product X）に統合。メモリ過負荷傾向が第 15 週に検知され、第 22 週に新バージョンリリース後に収束した **新規コンセプト**: [[障害パターンプロファイリング]]（定義・FaultProfIT 性能表・横断的知見 1 件・未解決の問い 3 件） **既存 wiki との接続**: - [[ポストモーテム]]: 深刻度バイアスを自動化で補完して分析対象を拡大するという横断的知見、汎化問題の未解決問いを追記 - [[障害傾向分析]]: 自動分類が GQM サイクルの Organize フェーズを加速するという横断的知見を追記 **エンティティ更新**: [[Junjie Huang]]（筆頭著者・FaultProfIT）/ [[Michael R. Lyu]]（シニア著者）/ [[Zhuangbin Chen]] / [[Jinyang Liu]] / [[Yichen Li]] / [[Jiazhen Gu]] / [[Zhihan Jiang]] # 2026-06-30: CSI 障害 — クロスシステムインタラクション障害の初体系分析 (EuroSys 2023 | Tang+, UIUC / Purdue) [[@2023__EuroSys__Fail through the Cracks - Cross-System Interaction Failures in Modern Cloud Systems]]（[[Lilia Tang]]・[[Chaitanya Bhandari]] ほか、[[University of Illinois Urbana-Champaign]] / [[Purdue University]]、EuroSys 2023）を wiki 化した。 **核心**: - **問題**: クラウドシステムの独立した(サブ)システム間のインタラクションが障害の新たな源泉になっている。単一システムは仕様上正しいが、システム間の不整合(discrepancy)が障害を引き起こす - **定義**: [[クロスシステムインタラクション障害]](CSI 障害) — 根本原因がシステム間に分散し、孤立分析では発見できない障害モード - **量的規模**: 公開クラウドインシデントの20%(55件中11件)がCSI 障害起因。中央値106分のサービス中断で YouTube・Gmail にも波及 - **3プレーン分類**: データプレーン51%(スキーマ不整合・シリアライゼーション問題が主)・管理プレーン32%(設定の無視/上書き・監視データ誤解釈)・コントロールプレーン17%(暗黙的API意味論違反) - **既存耐障害機構は無効**: レプリケーション・チェックポインティング・自動再起動はすべてシステム内部を保護するが、システム間インタラクションはSPOFとして残る - **修正の特性**: 40%は応急処置(条件チェック)。69%が上流システムのコネクタモジュール(コードベース5%未満)に集中 - **解決方向**: クロスシステムテスト — Spark-Hive で概念実証し、最新版でも15件の新規不整合を発見 **既存 wiki との接続**: - [[クロスシステムインタラクション障害]](新規概念)として独立ページ化。横断的知見5件・未解決の問い5件を収録 - [[分散システム障害]]: CSI 障害がコントロールプレーン一辺倒から現代のデータ・管理プレーンへの構造的移行を示すという横断的知見を追記 - [[クラウドインシデント]]: 本番インシデントの20%がCSI障害起因という量的事実を追記 - [[グレイ障害]]との関係: グレイ障害は「観測者とアプリの認識ギャップ」を問題にするが、CSI 障害は「システム間の仕様不整合」が根本原因。管理プレーンCSI障害(監視データ誤解釈→kill アクション)はグレイ障害的な特性を持ちうる **新規エンティティ**: [[Lilia Tang]] / [[Chaitanya Bhandari]] / [[Indranil Gupta]] **更新エンティティ**: [[Tianyin Xu]] / [[Purdue University]] **新規概念**: [[クロスシステムインタラクション障害]] **更新概念**: [[分散システム障害]] / [[クラウドインシデント]] # 2026-06-30: Metastable Failures — メタ安定障害の体系化（HotOS 2021 | Bronson+, Rockset / Facebook / Penn State / UNH） [[@2021__HotOS__Metastable Failures in Distributed Systems]]（[[Nathan Bronson]] ほか 3 名、HotOS 2021）を wiki 化した。 **核心**: - **問題**: ハイパースケール分散システムで発生する「ブラックスワン」型の広域障害。ハードウェア障害・設定ミス・バグとは異なる種類で、根本原因は「効率性・信頼性を向上させるはずの機能(再試行・キャッシュ・冗長化)」にある逆説 - **定義**: トリガーを取り除いても悪い状態が持続する障害パターン。sustaining effect(持続効果)がフィードバックループを形成し、強い是正措置なしに回復不能 - **3 状態モデル**: Stable(安定)→ Vulnerable(脆弱)→ Metastable(メタ安定)。脆弱状態は不可視のしきい値超過後に始まり、本番システムは効率性のために脆弱状態で運用し続けることが多い - **4 事例**: リクエスト再試行・ルックアサイドキャッシュ・遅いエラー処理・リンク不均衡(2 年以上未解決。修正は 1 行) - **研究概念**: 特性メトリクス・隠れキャパシティ・トリガー強度・ワーク増幅の上限設計 **既存 wiki との接続**: - [[メタ安定障害]](既存概念)に 3 状態モデルの公式定義・横断的知見 4 件(逆説・隠れキャパシティ乖離・マルチレイヤー診断困難・[[グレイ障害]]との関係)・未解決の問い 3 件を追記。HotOS 2021 が 1 次出典として登録された - [[グレイ障害]]（HotOS 2017）との連続性: 両者とも「fail-stop 前提では捕捉できない分散システムの見えない障害」を定式化。メタ安定障害の脆弱状態の不可視性は[[差分可観測性]]の概念と共鳴する **新規エンティティ**: [[Nathan Bronson]] / [[Abutalib Aghayev]] / [[Aleksey Charapko]] / [[Timothy Zhu]] / [[Rockset]] / [[The Pennsylvania State University]] / [[University of New Hampshire]] # 2026-06-30: Gray Failure — グレイ障害の古典的定式化（HotOS 2017 | Huang+, Microsoft Research / Azure） [[@2017__HotOS__Gray Failure - The Achilles' Heel of Cloud-Scale Systems]]（[[Peng Huang]] ほか 6 名、[[Microsoft Research]] / [[Microsoft Azure]]、HotOS 2017）を wiki 化した。 **核心**: - **問題**: クラウドの可用性問題の大半は fail-stop ではなく、微妙な障害(グレイ障害)が引き起こす。ランダムパケットロス・性能劣化・不安定 I/O がその例 - **定義**: [[差分可観測性]](differential observability)——Observer がシステムを健全と判断する一方で App が不健全と観測する非対称性 - **逆説**: 高冗長性(Clos コアスイッチ増設)はグレイ障害に対して逆効果になりうる。スイッチ数が増えるほど、少なくとも 1 台がグレイ障害を起こす確率も上がるため - **解決**: ハートビートなどの単一シグナルから多次元ヘルス監視へ転換。Pingmesh 型のプロービング・規模を活かした集約推論・時間パターン活用が方向性 **既存 wiki との接続**: - [[グレイ障害]](既存概念)に公式定義セクション(Observer/App モデル・4象限表)と横断的知見2件を追記。HotOS 2017 が[[差分可観測性]]の1次出典として登録された - [[差分可観測性]](新規概念)として独立ページ化。SuperBench・GrayScope・Harp が同じ方向性を取ることを横断的知見に収録 - [[Lidong Zhou]]は SuperBench(2024)のシニア著者でもあり、グレイ障害研究の連続性が確認された **新規エンティティ**: [[Jacob R. Lorch]] / [[Murali Chintalapati]] / [[Randolph Yao]] **更新エンティティ**: [[Peng Huang]] / [[Chuanxiong Guo]] / [[Lidong Zhou]] / [[Yingnong Dang]] / [[Johns Hopkins University]] **新規概念**: [[差分可観測性]] **更新概念**: [[グレイ障害]] # 2026-06-30: mTCP: a Highly Scalable User-level TCP Stack for Multicore Systems (NSDI 2014 | EunYoung Jeong ほか, KAIST) [[EunYoung Jeong]]・[[Dongsu Han]]・[[KyoungSoo Park]] ら [[KAIST]] / Princeton University が NSDI 2014 で発表した [[@2014__NSDI__mTCP - a Highly Scalable User-level TCP Stack for Multicore Systems]] を wiki 化した。NSDI Community Award 受賞論文。 **核心**: - **問題の本質**: LinuxカーネルTCPスタックはCPUサイクルの70〜80%をカーネル内で消費。この非効率性は接続ローカリティの欠如・共有fdスペース・非効率なパケット単位処理・高コストシステムコールの4つに集約される。 - **ユーザーレベルTCPスタック**: TCPスタックをカーネルから取り出し、ユーザープロセス内の各CPUコアに1本のTCPスレッドを対応させる。PSIOを拡張したユーザーレベルパケットI/Oライブラリで直接NICにアクセスする。 - **双方向バッチ処理が核心**: パケットI/Oバッチ化（先行研究PSIO等）とシステムコールバッチ化（FlexSC・MegaPipe等）を、ユーザーレベルで透過的に統合した点が新規性。カーネル改変不要。実験では1スケジューリング期間あたり平均2,170イベントをバッチ処理した。 - **評価結果**: 8コア・64Bメッセージで Linux 比25倍・MegaPipe 比3倍。レイテンシの標準偏差はLinuxの330分の1。lighttpd(Linux比3.2倍)・SSLShader(18〜33%向上)・WebReplay（7コピーまで100ms以下）で実アプリ性能も実証。 - **限界**: 長期接続でCPU使用率294%(vs Linux 80%)——TCPオフロード未実装のため。1アプリ1NICポートの制約（SR-IOVで将来解決可能と著者が示唆）。 **新規概念**: [[ユーザーレベルTCPスタック]]（カーネルバイパスTCPの定義・横断的知見・未解決の問い） **既存ページを補完**: - [[KyoungSoo Park]]: mTCP ソース参照を追記。 - [[KAIST]]: EunYoung Jeong・Dongsu Han・mTCP ソース参照を追記。 # 2026-06-30: VM vs Linux Containers 性能比較 (ISPASS 2015 | Felter ほか, IBM Research Austin) [[Wes Felter]] ほか([[IBM Research]] Austin)が 2015 年 ISPASS で発表した [[@2015__ISPASS__An Updated Performance Comparison of Virtual Machines and Linux Containers]] を wiki 化した。Docker 1.0 と KVM を同一 Intel Sandy Bridge-EP サーバ上で体系比較した定番論文だ。 **核心**: - **コンテナ ≈ ネイティブ**: CPU(Linpack)・メモリ帯域(STREAM)・シーケンシャル I/O はほぼ同等。KVM は NUMA トポロジをゲストに隠すため MKL の適応型最適化が機能せず Linpack が約 55% 低下する。 - **ランダム I/O の明暗**: Docker ≈ ネイティブ(IOPS・レイテンシとも); KVM は QEMU 経由で約 50% IOPS 低下・2–3 倍の読み取りレイテンシ。 - **ネットワーク遅延は KVM が 1トランザクション +30µs(+80%)**: スループットはラインレートを達成するが遅延は分散できない。Docker NAT も高パケットレートで Redis/MySQL に影響。 - **Docker の落とし穴は AUFS と NAT**: volume で直接マウント、net=host でネイティブ同等に。 **新規エンティティ**: [[Wes Felter]] **更新エンティティ**: [[Docker]]（ISPASS 2015 性能データ追記）、[[IBM Research]]（Austin TX 仮想化研究追記） **新規コンセプト**: [[コンテナ仮想化]]（OS レベル仮想化の機構と VM との定量比較、Docker パフォーマンス落とし穴） **wiki 内接続**: [[コンテナオーケストレーション]](2017–2019 以降の研究加速の前史)/ [[コンテナ配置最適化]](性能上限を実測したのが本論文) / [[コンテナ起動高速化]](起動時間 KVM 11秒 vs Docker 1秒の差) # 2026-06-30: dsync — ブロックレベル差分同期（LISA13 Best Paper | Knauth & Fetzer, TU Dresden） [[@2013__LISA__dsync - Efficient Block-wise Synchronization of Multi-Gigabyte Binary Data]]（[[Thomas Knauth]]・[[Christof Fetzer]]、[[TU Dresden]]、LISA 2013、Best Paper）を wiki 化した。 **核心**: - **問題**: rsync は数百 GB 規模のデータに対して低速。原因は「事後チェックサム計算」——同期のたびに全データを読んでチェックサムを計算するオーバーヘッド。 - **解法**: ブロックへの書き込みを**カーネル拡張（Linux 3.2.35）でオンライン追跡**し、変更済みブロックのビットマップを維持。同期時は変更ブロックのみ転送（チェックサム計算不要）。 - **効果**: ディスク I/O・キャッシュ汚染・CPU 使用率の 3 点を改善。チェックサムベースより最大 **2 桁（100 倍）高速**化。 **既存 wiki との接続**: - [[ファイルレベル同期]]（同じ LISA 2013 の Marc Merlin 論文）と対比: 「同期粒度（ファイル vs ブロック）」という設計軸の両極が LISA13 の 2 論文に表れている。 - [[Christof Fetzer]]（既存エンティティ）は Sieve（分散システム監視）の文脈でも登場しており、TU Dresden の研究カバレッジが広がった。 **新規概念**: [[ブロックレベル差分同期]] **新規エンティティ**: [[Thomas Knauth]] **更新エンティティ**: [[Christof Fetzer]]、[[TU Dresden]] **更新概念**: [[ファイルレベル同期]]（横断的知見追記） # 2026-06-30: Scaling Memcache at Facebook (NSDI 2013 | Rajesh Nishtala ほか, Facebook Inc.) [[Rajesh Nishtala]] ほか 13 名（[[Facebook]]）が NSDI '13（2013）に発表した [[@2013__NSDI__Scaling Memcache at Facebook]] を wiki 化した。14 ページ・PDF 精読済み。代表図 7 枚を PyMuPDF で抽出して source ページに埋め込み済み。 **核心**: - **ルックアサイドキャッシュ**: get はキャッシュ miss → DB → set、書き込みは DB → delete（update でなく delete を使いべき等性を確保）。 - **3 スケール構造**: クラスタ内(レイテンシ・ロード削減)→リージョン内(複数クラスタ間整合性)→リージョン間(地理分散整合性)の三層で課題が変わる。 - **リースメカニズム**: thundering herd + stale set を 64-bit トークンで解決。ピーク DB クエリ 17K/s → 1.3K/s。 - **Gutter プール**: 障害時フォールバック用 1% サーバ群。クライアント可視失敗率を 99% 削減、4 分以内にヒット率 35〜50%。 - **mcsqueal**: DB コミットログ駆動の無効化デーモン。バッチ化で削除/パケット比 18 倍改善。マスターリージョン内 1 秒以内 4 ナイン、レプリカ間 3 ナイン。 - **シングルサーバ改善**: 細粒度ロックで hit レート 3 倍(600K → 1.8M/s)、UDP get が TCP 比 20% 低レイテンシ、適応型スラブアロケータ、Transient Item Cache(短命キーのプール使用率 6% → 0.3%)。 **作成・更新ページ**: - source (new): [[@2013__NSDI__Scaling Memcache at Facebook]] - entities (new): [[Rajesh Nishtala]] - entities (updated): [[Facebook]]（memcache セクション追記） - concepts (new): [[分散キャッシュ]] - concepts (updated): [[一貫性ハッシュ法]]（memcache でのキー配布・ホットキーにはレプリケーション対応）、[[Incast]]（スライディングウィンドウによるアプリ層 incast 緩和）、[[結果整合性]]（キャッシュ層のベストエフォート結果整合性） --- # 2026-06-30: netmap: A Novel Framework for Fast Packet I/O (USENIX ATC '12 Best Paper | Luigi Rizzo, Università di Pisa) [[@2012__USENIX-ATC__netmap A Novel Framework for Fast Packet IO]]（[[Luigi Rizzo]]、Università di Pisa、ATC '12 Best Paper）を wiki 化した。 **核心**: - **三原則**: プリアロケーション（動的 malloc 排除）・バッチ syscall（コンテキストスイッチ償却）・共有リングバッファ（ゼロコピー）で 10 Gbit/s 線速 **14.88 Mpps** を達成。 - **保護 vs DPDK**: netmap はカーネルドライバを残しデバイスレジスタをユーザー空間から隔離。DPDK のフル UIO バイパスとは異なる。安全性と移植性を維持しながらゼロコピーを実現。 - **libpcap 互換層**: 既存アプリ（Click、tcpdump 等）をソース改変なしに 5 倍以上高速化。 - **FreeBSD・Linux 両対応**: ドライバ改変量を最小化した設計で複数 NIC ファミリーをサポート。 **新規概念**: [[netmap]], [[カーネルバイパスネットワーキング]], [[ゼロコピーネットワーキング]] **新規エンティティ**: [[Luigi Rizzo]] **関連 wiki 内ソース**: [[@2015__yuuk.io__linux-networkstack-tuning-rfs]] は Linux カーネル内 RPS/RFS チューニングで同じ「多コアでのパケット処理効率化」を扱う。netmap がカーネルスタックを迂回するのに対し、RPS/RFS はスタック内でコアを効率活用する補完的アプローチ。 # 2026-06-30: SSLShader: Cheap SSL Acceleration with Commodity Processors (NSDI 2011 | Keon Jang, KyoungSoo Park / KAIST) [[Keon Jang]]・[[KyoungSoo Park]]（KAIST）が NSDI 2011 で発表した GPU 利用 SSL アクセラレーション論文を wiki 化した。USENIX カンファレンスページを取得・精読済み。 **核心**: - **問題**: SSL のサーバサイド暗号計算コストが展開を阻んでいた。解は高価な専用ハードウェアアプライアンスのみ - **GPU アクセラレーション**: GPU の大規模並列性で RSA 演算をバッチ処理し、最速 CPU 実装比 **22.6〜31.7 倍** を達成 - **AESNI 活用**: バルク暗号化（AES）は Intel の AESNI ハードウェア命令でカバーし、GPU は公開鍵演算（RSA）に集中する役割分担 - **NUMA 対応**: マルチソケットサーバでのメモリローカリティを考慮し、高スループットと低レイテンシを両立 - **SSLShader プロキシ**: 透過的 SSL プロキシとして既存サーバを無変更で前段展開可能 - **達成性能**: 小ファイル 29K TPS・大ファイル 13 Gbps — 高級アプライアンスに匹敵をコモディティサーバで実現 **新規作成ページ**: - [[@2011__NSDI11__SSLShader - Cheap SSL Acceleration with Commodity Processors]]（source） - [[Keon Jang]]（entity、第一著者） - [[Sangjin Han]]（entity） - [[Seungyeop Han]]（entity、UW） - [[Sue Moon]]（entity、KAIST 教授） - [[SSL TLS アクセラレーション]]（concept） **更新ページ**: [[KyoungSoo Park]]（SSLShader を研究系譜に追加）、[[KAIST]]（SSLShader・新著者追記） **研究系譜コンテキスト**: この論文は [[KyoungSoo Park]] グループの「CPU の性能限界を突破するネットワーク高速化」研究の起点。GPU→SSL アクセラレーション（2011）→mTCP カーネルバイパス（2014）→AccelTCP NIC オフロード（2020）という一貫した系譜が見える。 --- # 2026-06-30: Live Upgrading Thousands of Servers from an Ancient Red Hat Distribution to 10 Year Newer Debian Based One (LISA '13 | Marc Merlin / Google) [[Marc Merlin]](Google)が LISA '13 で報告した、Red Hat 7.1 から Debian ベース「ProdNG」への数千台ライブアップグレード経験報告を wiki 化した。PDF を取得・全文精読済み。 **核心**: - **3 層アーキテクチャ**: Google プロダクション OS はカーネル層・ユーザースペース層・アプリ(chroot 隔離)層に分離。アプリは静的リンクで OS から切り離されており、ユーザースペースが約 10 年 Red Hat 7.1 のままだった根拠。 - **ファイルレベル同期**: パッケージマネージャーを迂回し、クライアントプル型のカスタム rsync 類似ソフトウェアで全サーバーにマスターイメージを同期。べき等性と均一性を保証する。新規概念ページ [[ファイルレベル同期]] を作成。 - **段階的 rpm→deb 移行**: [[Richard Gooch]] 考案。ProdNG の deb を rpm に変換して 1 サイクル 5〜10 パッケージずつ旧イメージに注入し、3〜4 年かけて全置き換えを達成。[[ライブアップグレード]] 概念ページを作成。 - **ELF バイナリパッチ**: libc 2.2.2(旧)と 2.3.6(新)の不一致を、ELF ヘッダーのランタイムリンカーパスを書き換えることで吸収。 - **/etc/rc.d/init.d → /etc/init.d 移行**: ファイル同期プログラムのシンボリックリンク競合バグを、数ヶ月かけた二段階移行で回避。 - **教訓**: 部分アップグレード可能なディストリビューション選択・不要パッケージの積極削除・ファイルレベル同期の優位性・上流アップデートを盲信しない姿勢。 **既存ページを補完**: - [[Google]]: インフラストラクチャ管理セクション(ProdNG・ファイルレベル同期・LISA '13)を追記。 # 2026-06-30: Mackerelを支える時系列データベース技術 (yuuk.io 2015 | Yuuki Tsubouchi) [[Yuuki Tsubouchi]] が 2015 年 4 月に公開し 2018 年 1 月に更新した [[@2015__yuuk.io__High-Performance-Graphite]] を wiki 化した。[[Mackerel]] が [[HeteroTSDB]] 移行前に使用していた [[Graphite]] 時系列 DB 基盤の設計・運用を詳述した一次記録。 **核心**: - **whisper の RRD 設計**: 固定サイズファイル+複数 archive（精度×保持期間）で Rollup Aggregation（古いデータを粗精度に変換）。ディスク使用量が予測可能だが高精度の過去データは失われる。 - **carbon-cache の CPU 限界**: Twisted ベースで 2 スレッド上限。スケールアウトには carbon-relay + consistent-hashing で複数プロセスに分散が必要。多段構成になるほど可用性・保守性が低下する。 - **ページキャッシュ圧迫**: 多数ファイルへの全方位書き込みで posix_fadvise は部分効果のみ——本番の解はメモリ増強。 - **一貫性なしレプリケーション**: carbon-relay レプリケーションはバイナリログなし・一貫性保証なし。復旧は rsync（DRBD はネットワーク帯域限界で不採用）。 - **2018 年移行**: Mackerel は HeteroTSDB へ移行し Graphite 運用を終えた。Graphite の課題が HeteroTSDB 設計動機として連なる。 **新規エンティティ**: [[Graphite]] **更新エンティティ**: [[Mackerel]]（Graphite 時代セクション追記）、[[Yuuki Tsubouchi]]（本記事追記） **更新コンセプト**: [[時系列データベース]]（RRD 設計・多段シャーディング・ページキャッシュ圧迫の 3 知見追記） **wiki 内接続**: [[HeteroTSDB]]（後継技術）/ [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]（博士論文での HeteroTSDB 詳述）/ [[Gorilla]]・[[Lindorm TSDB]]（RRD vs 追記型 vs 前処理ダウンサンプリングの設計軸比較） # 2026-06-30: ウェブシステムの運用自律化に向けた構想 (yuuk.io 2017) [[Yuuki Tsubouchi]]（[[Hatena]] SRE、y_uuki）が 2017-12-02 に公開した [[@2017__yuuk.io__ウェブシステムの運用自律化に向けた構想]] を wiki 化した。人工知能学会 ウェブサイエンス研究会 招待講演の内容を加筆修正。 **核心**: - **SRE最適化問題定義**: 「信頼性を制約条件として費用（コンピューティングリソース費用 + 人件費用 + 機会費用）を最小にする最適化問題」。2018年追記では「変更速度を最大にする最適化問題」に修正。 - **Experimentable Infrastructure**: 近代科学の仮説演繹法ループをシステムが自律実行するフレームワーク。観測・制御・実験の3軸で構成。 - **複雑性の3要因**: ソフトウェア依存関係・分散システム・入力パターン。はてなのシステム規模（サービス100+、ホスト1000+、SRE 10 人弱）も開示。 - **自律運用の壁**: ハードウェアリソース制約と予測できない外乱。WSA研（ウェブシステムアーキテクチャ研究会）立ち上げを宣言。 **作成・更新ページ**: - source (新規): [[@2017__yuuk.io__ウェブシステムの運用自律化に向けた構想]] - concept (新規): [[Experimentable Infrastructure]] - entities (更新): [[Yuuki Tsubouchi]], [[Hatena]] - concepts (更新): [[SRE]] --- # 2026-06-30: 2015年Webサーバアーキテクチャ序論（yuuk.io 2015 | Yuuki Tsubouchi） [[@2015__yuuk.io__2015年Webサーバアーキテクチャ序論]]（[[Yuuki Tsubouchi]]、blog.yuuk.io、2015-05-28）を wiki 化した。 **核心**: - **5 モデル分類**: シリアル → プリフォーク(Unicorn) → マルチスレッド → イベント駆動(Twiggy/Twisted/Node.js) → ハイブリッド(Nginx/EventMachine)。本記事で [[Webサーバアーキテクチャ]] 概念を新規作成。 - **プリフォーク固有の知識**: Copy-On-Write によるメモリ効率化・サンダーリングハード問題(Thundering Herd)と accept mutex による回避。 - **設計軸の明確化**: 「ブロッキング I/O をどう扱うか」が全モデル選択の核心。イベント駆動はブロッキングが混入すると全停止する。 - **学習方針**: 「息の長い技術(Unix プロセス・TCP ソケット)を先に固める」という方針を提唱。 **新規概念**: [[Webサーバアーキテクチャ]] **更新概念**: [[C10K問題]]（Webサーバ設計観点の横断知見追記）, [[epoll]]（同） **更新エンティティ**: [[Yuuki Tsubouchi]]（本ブログ記事を既存 Hatena SRE 時代活動として追記） **関連 wiki 内ソース**: [[@2015__yuuk.io__architecture-of-database-connection]] も同時期(Hatena SRE 時代 2015 年)の記事で、本記事がプリフォーク Web サーバのプロセスアーキテクチャを扱うのに対し、後者はそのデータベース接続側を扱う。両者を合わせると「2015 年当時の Hatena インフラスタックのソケットから DB までの全レイヤー」の設計知識が見える。 # 2026-06-30: Webシステムにおけるデータベース接続アーキテクチャ概論（yuuk.io 2015, Yuuki Tsubouchi） [[Yuuki Tsubouchi]] (y_uuki) が [[Hatena]] SRE として執筆した 2015 年ブログ記事 [[@2015__yuuk.io__architecture-of-database-connection]] を wiki 化した。前作「2015年Webサーバアーキテクチャ序論」の続編にあたる。 **核心**: - **[[データベース接続モデル]]の3分類**: リクエスト都度接続 / 常時接続 / [[コネクションプーリング]]。常時接続はL4ロードバランサの均等分散が困難になるトレードオフがある。 - **[[コネクションプーリング]]の2種類**: ドライバ型（JVM/JDBC: HikariCP・BoneCP）とプロキシ型（[[PgBouncer]]・[[Pgpool]]）。Perlのようにスレッドがない言語でプロキシ型が有効。 - **PostgreSQL vs MySQL**: PostgreSQLは1接続=1プロセスで接続オーバヘッドが大きく[[PgBouncer]]必須。MySQLはThread Cacheで接続オーバヘッドが小さく都度接続が多い。 - **インピーダンスミスマッチ**: RDBMSは元々少数クライアントとのステートフル通信向けで、HTTP的な多数クライアント接続切断繰り返しとは設計思想が異なる（@kazuho 2013）。 **新規概念**: [[データベース接続モデル]], [[コネクションプーリング]] **新規エンティティ**: [[PgBouncer]], [[Pgpool]] **更新エンティティ**: [[Yuuki Tsubouchi]]（ブログ記事追記） # 2026-06-30: Linux マルチコアスケール カーネルチューニング（yuuk.io 2015、RFS） [[Yuuki Tsubouchi]]（坪内佑樹）が 2015 年 3 月に yuuk.io に公開したブログ記事 [[@2015__yuuk.io__linux-networkstack-tuning-rfs]] を wiki 化した。 **核心**: - **問題**: シングルキュー NIC 環境では HAProxy・nginx・memcached 等の高パケットレートアプリが CPU0 の softirq に集中し、他コアが遊休になる（64 バイトフレーム 1 Gbps ≒ 150 万割り込み/秒） - **技術体系**: - [[RSS（Receive Side Scaling）]]: NIC ハードウェアで 4 タプルハッシュにより複数キューへ分散。ハードウェア依存。 - [[RPS（Receive Packet Steering）]]: RSS のソフトウェア版。IPI で他コアへ分散。ハードウェア非依存（Linux 2.6.35+）。 - [[RFS（Receive Flow Steering）]]: RPS 拡張版。フローテーブルで「アプリが最後に動いたコア」を記録し、ネットワーク処理と同一コアで実行（キャッシュ局所性考慮）。 - **設定（3 パラメータ）**: `rps_cpus`・`rps_flow_cnt`・`rps_sock_flow_entries` - **実験結果**: 16 コアシステムで CPU0 softirq 集中が解消、Starlet 実環境で約 10% 応答速度改善。HAProxy・pgpool・Varnish・memcached で副作用なし。 **新規概念**: [[RFS（Receive Flow Steering）]], [[RPS（Receive Packet Steering）]], [[RSS（Receive Side Scaling）]] **更新エンティティ**: [[Yuuki Tsubouchi]]（blog 記事追記） **関連 wiki 内コンテキスト**: [[スマートNICオフロード]]（AccelTCP、ハードウェアオフロード系）とは補完関係。RFS はソフトウェアレイヤでの負荷分散、スマートNICオフロードは NIC 側での処理委譲という異なるアプローチ。 # 2026-06-30: サーバーレスアーキテクチャ再考 (yuuk.io blog 2019, re-ingest) [[Yuuki Tsubouchi]]（y_uuki）が 2019-09-11 に公開した [[@2019__yuuk.io__Rethinking-Serverless-Architecture]] を再取り込みした。ソースページ・概念ページ・エンティティページは既に充実していたため、補完に留めた。 **追加内容**: - [[@2019__yuuk.io__Rethinking-Serverless-Architecture]] に「後記: サーバーレスデータベースへの展望」セクションを追記。@tzkb との LINE OpenChat 議論から生まれた「DB のバッファプール・テーブルファイルを BaaS+FaaS に分解する」アイデアは、2019 年時点での先見性として記録。 - エンティティ新規: [[Knative]]（Google 主導、Kubernetes ネイティブ FaaS 基盤）、[[OpenFaaS]]（Alex Ellis 主導 FaaS フレームワーク） - マニフェストエントリを補完（前回 ingest 時に未記録だった） **既存の充実ページ**: [[サーバーレスアーキテクチャ]]（FaaS+BaaS の二義的定義、ピタゴラスイッチ構成、CGI 比較、制約）/ [[Yuuki Tsubouchi]] # 2026-06-30: 工学としてのSRE再訪 — SRE NEXT 2024 登壇後記 (yuuk.io blog) [[坪内佑樹]] が SRE NEXT 2024（2024-08-03〜04、Abema Towers）で発表した「工学としての SRE 再訪」の振り返りブログ（2024-08-08 公開）を wiki 化した。ベストスピーカー賞受賞。参加者 1000 人超・プロポーザル 100 件超。参考文献 Gist: https://gist.github.com/yuuk/a4464697b0c7585a9fcfb0905f1b6e06。 **既存ページを補完**: - [[@2024__yuuk.io__SRE-NEXT-2024]]: イベント統計・準備プロセス（Obsidian × Topotal 壁打ち）・Gist リンクを追記 - [[アラート疲労]]: 「オオカミ少年アラート問題」が 2024 年時点でも SRE の工学的未解決課題と位置づけられているという横断的知見を追記 **核心**: 6 つの SRE オープンチャレンジのうち「オオカミ少年アラート問題」は SREcon コミュニティが 2016〜2026 年に多数の解法を蓄積したにもかかわらず、現場定着のギャップが残っていることが示唆された。 # 2026-06-30: An AI system to help scientists write expert-level empirical software (Nature 2026 | Google Research / DeepMind) Eser Aygün* ほか 42 名（Google Research・Google DeepMind・MIT・Harvard・McGill・Caltech）が Nature Vol. 654（2026-05-19 オンライン）に発表した [[@2026__Nature__An AI system to help scientists write expert-level empirical software]] を wiki 化した。arXiv:2509.06503v3（78 ページ、31 図、22 表）。PDF を取得・全文精読済み。 **核心**: - **ERA（Empirical Research Assistance）**: スコアリング可能な科学タスク（評価関数がコード実行で自動定量化されるタスク）を対象に LLM + PUCT 木探索でコードを反復改善するシステム。 - **主要成果**: scRNA-seq バッチ統合で 40 手法が OpenProblems リーダーボード全手法を凌駕、COVID-19 入院予測で 14 手法が CDC CovidHub アンサンブルを上回った。GIFT-Eval・ZAPBench・地理空間・数値積分でもエキスパートレベル。 - **PUCT アルゴリズム**: `PUCT_i = RankScore_i + c_puct × sqrt(N_total) / (1 + V_i)`。c_puct=1 固定、ランク変換で全タスク共通化。AlphaZero との差異: フラット選択・ロールアウト不要。 - **アイデア注入**: 論文サマライズ・ペア再結合（55 組）・Gemini Deep Research・AI co-scientist の 4 経路。再結合が最多の上位手法を生む。 - **BoN 比較（Table 1）**: 5 LLM（Gemini 2.5 Flash / Mistral / Claude Sonnet 4.6 / GPT-5 / Gemini 3.1 Pro）の殆どで ERA > Best-of-N=1000。 **新規概念**: [[LLMドリブンコード探索]], [[スコアリング可能タスク]] **更新概念**: [[コードLLM]]（BoN vs 木探索の横断的知見追記） **新規エンティティ**: [[Michael P. Brenner]] **更新エンティティ**: [[DeepMind]], [[Google Research]] **関連 wiki 内ソース**: [[@2026__Nature__Towards end-to-end automation of AI research]]（Sakana AI、The AI Scientist）も「AI が科学論文を自動生成」という隣接タスクを扱う。ERA との差異: AI Scientist はアイデア創出〜論文執筆の全工程を自動化；ERA は「スコアリング可能タスクのコード最適化」に特化し、複数ドメインで人手ベンチマークを超えた定量的証拠を持つ。 # 2026-06-30: Towards end-to-end automation of AI research (Nature 2026 | Sakana AI) [[Chris Lu]]・[[Cong Lu]]・[[Robert Tjarko Lange]]・[[Yutaro Yamada]] ほか([[Sakana AI]])が Nature Vol. 651 (2026-03-26) に発表した [[@2026__Nature__Towards end-to-end automation of AI research]] を wiki 化した。Nature PDF (9p) を取得・全文精読済み。arXiv 元バージョン: 2408.06292。 **核心**: - **The AI Scientist**: アイデア創出→実験実行→論文執筆→自動査読の完全エンドツーエンドパイプライン。2モード: テンプレートベース(Aider+逐次) / テンプレート自由(並列化エージェントツリー探索)。 - **歴史的マイルストーン**: AI生成論文が ICLR 2025 ICBINB ワークショップ(採択率70%)の査読を通過した初事例(スコア6.33/10)。 - **The Automated Reviewer**: 5-runアンサンブル+メタレビュー。均衡精度69%で人間(66%)と同等、F1スコアは0.62で人間(0.49)を大幅に上回る。 - **スケーリング**: 基盤モデル世代 R²=0.517(P<0.00001)・計算ノード数ともに論文品質が単調増加。 - **使用モデル**: o3(推論)・Claude Sonnet 4(コード生成)・GPT-4o(視覚言語)・o4-mini(査読)。 **新規概念**: [[AI研究自動化]], [[エージェント型科学探索]], [[自動査読]] **新規エンティティ**: [[Chris Lu]], [[Cong Lu]], [[Robert Tjarko Lange]], [[Yutaro Yamada]], [[Shengran Hu]], [[Jakob Foerster]], [[David Ha]], [[Jeff Clune]] **更新エンティティ**: [[Sakana AI]](The AI Scientist 追記) # 2026-06-30: Enabling Client-side SLO (SRE NEXT 2024, Wataru Tsuda, Luup) [[Wataru Tsuda]]（[[Luup]] Reliability Engineer、gr1m0h）が SRE NEXT 2024（2024-08-04、Track B jp005）で発表した [[@2024__SRENext2024__Enabling Client-side SLO]] を wiki 化した。41 スライド全ページ画像確認済み。transcript なし。SpeakerDeck: grimoh/enabling-client-side-slo。 **核心**: - **動機**: API のみ計測では BLE 操作（施錠・解錠・ライド開始終了）や Firestore 直接通信が漏れる。よりユーザーに近い部分での計測が必要。 - **CUJ 再設定**: PdM が Figma でユーザージャーニー一覧を作成し、PdM/SWE/SRE 三者で議論してユーザージャーニーマトリクス（UserJourney / Priority / SLO / TraceName / 関連WebAPI 等）にまとめた。 - **SLI 設計**: Firebase Performance Custom Trace → Datadog APM の p75 Latency。p75 を選んだ根拠は Core Web Vitals の Good LCP Score（75%ile を採用）を参照。Datadog RUM はコスト面から断念しレイテンシ SLO から先行。 - **Datadog Time Slice SLO**: モニター不要・作成中にしきい値を即座に調査可能。2024-05-02 GA。Monitor-based SLO から移行。 - **Multi-tiered SLOs**: 1 SLI に Upside（理想）/ Downside（現在監視中）/ Actual（現実、Downside 割れ時のみ作成）の 3 段階を設置。将来は Actual 廃止・Downside のみへ移行を目標。 - **文化醸成**: ダッシュボード（CUJ ごとグルーピング・iOS/Android 横並び）と Weekly SLI/SLO レビュー（SRE ファシリテーション）。「Enabling 中で文化醸成・運用の軌道乗せが一番重要」。 **作成・更新ページ**: - source (new): [[@2024__SRENext2024__Enabling Client-side SLO]] - entities (updated): [[Wataru Tsuda]]（2024 SRE NEXT 発表追記・role 更新）、[[Luup]]（2024 クライアントサイド SLO 取り組み追記） - concepts (updated): [[SLI-SLO段階的導入]]（横断的知見 4 件・未解決の問い 2 件追加） --- # 2026-06-30: Practices for Making Alerts Actionable (SRE NEXT 2020, Sohei Iwahori, GREE) [[Sohei Iwahori]]（[[GREE, Inc]]、インフラ/Monitoring Unit Leader、@egmc）が SRE NEXT 2020（2020-01-25）で発表した [[@2020__SRENext2020__Practices for Making Alerts Actionable]] を wiki 化した。41 スライド全ページ(画像は p.1-24 を確認、p.25-41 はテキスト抽出で補完)。transcript なし。 **核心**: - **問題の構造**: 2015 年のオンプレ→AWS 移行時にアラートルールを流用した結果、オートスケーリングの台数調整・スケールイン/アウト時の一時的スパイクで「静観アラート」が急増し 2018/09 に月 300 件超のピーク。 - **振り分け3段階**: 即時アクション不要→Slack のみ通知、遅延対応可→JIRA チケット自動起票（yusura から構造的情報付き）、即時オンコール→PagerDuty という3段階で通知先を分離。Jalleda SREcon17 の「15分以内対応 + 人間の知性」条件と整合的であることが事後的に確認できる。 - **Alert Operator**: AWS Lambda + AWS SSM でプロセス再起動などの定型アクションを自動化し、人間向けオンコールを真にアクショナブルなものに絞り込む。 - **月次計測**: SumoLogic + PagerDuty で月次 Top10 を集計・通知し毎月検討。改善の PDCA を回す起点。 - **SysLoad 共通指標**: 全 CPU/ディスク I/O/NIC 割り込みの最大値（飽和=100）として定義した独自指標を OSS 公開。80 超で対応というチーム共通基準。 **作成・更新ページ**: - source (new): [[@2020__SRENext2020__Practices for Making Alerts Actionable]] - entities (updated): [[Sohei Iwahori]]（aliases 修正・SRE NEXT 2020 発表追記）、[[GREE, Inc]]（規模・監視スタック・改善実績追記） - concepts (updated): [[アクショナブルアラート]]（振り分け3段階・自動復旧の横断的知見2件追記）、[[アラート疲労]]（クラウド移行後アラート疲労・SRE Book Ch.6引用の横断的知見追記） --- # 2026-06-30: 電動マイクロモビリティのシェアサービス「LUUP」におけるEnabling SLOの実践 (SRE NEXT 2023, Wataru Tsuda) [[Wataru Tsuda]]（[[Luup]] SRE、gr1m0h、SRE NEXT 2023 Chair）が SRE NEXT 2023（2023-09-29）で発表した [[@2023__SRENext2023__電動マイクロモビリティのシェアサービス「LUUP」におけるEnabling SLOの実践]] を wiki 化した。35 スライド全ページを画像で確認。transcript なし。 **核心**: - **CMC（Critical Machine Communication）**: CUJ の IoT 版として Luup 内で作成した概念。「マシンが期待通りに動作できる状態であるか」を SLI の起点とする。バッテリー残量、サーバー接続状態、定期通信応答などを計測。プロトコルは MQTT/LwM2M。（p.10） - **Enabling SRE → Enabling SLO**: Enabling SRE はスコープが広すぎるため、SLO 導入に絞って現実的に進める判断（p.16）。スタートアップでは Embedded SRE がリソース的に難しく、Developer Lead との直接コミュニケーションが代替（p.27）。 - **習熟度調査 + 勉強会**: 14 問の SLO 習熟度調査（エンジニア＋PdM 対象）で現在地を把握し、その結果を基に 3 部構成（背景・基本・Luup 現状）の勉強会を実施（p.23-24）。 - **IoT 自動サービスアウト**: (1) 定期通信途絶（MQTT 応答途絶 → 自動サービスアウト→再接続でサービスイン）、(2) ハードウェアエラーしきい値超過（Slack 通知 → 自動サービスアウト→人手確認でサービスイン）（p.29-30）。 - **CMC based SLI（策定中）**: 「サービスインしている車両の割合」を SLI として検討中（p.31）。 **作成・更新ページ**: - source (new): [[@2023__SRENext2023__電動マイクロモビリティのシェアサービス「LUUP」におけるEnabling SLOの実践]] - entities (new): [[Wataru Tsuda]], [[Luup]] - concepts (updated): [[サービスレベル目標]]（IoT CMC 概念・Enabling SLO 組織パターンの横断的知見追記） --- # 2026-06-30: Who owns the Service Level? (SRE NEXT 2022, 近藤武士 / @chaspy) [[近藤武士]]（[[Recruit]] SRE EM）が SRE NEXT 2022（2022-05-15）で発表した [[@2022__SRENext2022__Who owns the Service Level?]] を wiki 化した。79 スライド全ページを確認。transcript なし。 **核心**: - **SRE 実現の定義**: 開発チームが信頼性をコントロールする Capability を身につけること = 「自己完結化（self-contained）」。SRE は Platform Team / Enabling Team として支援する（Team Topologies）。 - **SLO Review の成功と失敗の分離**: 2020 年 SRE NEXT 発表後に 2 プロダクト 15 チームへの SLI/SLO 導入（定義・観察）は成功。しかし Error Budget Policy に従った「行動する」ステップは未達。理由：非機能要求対処の予算・権限が開発チームになかった。 - **技術戦略グループによる解決**: 2021 年に技術戦略グループ発足。新規:エンハンス:技術的負債解消 = 1:1:1 の予算宣言。課題管理（スプレッドシート + Slack reacji）と優先順位付け（ペイン頻度×強度マップ）を確立。 - **DevOps WG**: バリューストリームマッピング・DX Criteria・候補指標計測を通じて開発チームの「自己診断能力の獲得」を推進。 - **結論**: Service Level はプロダクトに関わる全員のもの。次のステップはクライアントサイド SLI と「指標を見て行動するサイクル」の改善。 **作成・更新ページ**: - source (new): [[@2022__SRENext2022__Who owns the Service Level?]] - entities (new): [[近藤武士]], [[Recruit]], [[スタディサプリ]] - concepts (updated): [[サービスレベル目標]]（「定義・観察」と「行動」の分離・第5の前提条件追記）/ [[エラーバジェット]]（Error Budget Policy 行動定着の組織的前提・リリースストップ幻想の 2 知見追記） --- # 2026-06-30: プロダクトオーナーとしてSLOに向き合う 〜Mackerelチームの事例〜 (SRE NEXT 2023, 渡辺 起) [[渡辺 起]]（[[Hatena]]、[[Mackerel]] プロデューサー、2022 年まで PO）が SRE NEXT 2023（2023-09-29）で発表した [[@2023__SRENext2023__プロダクトオーナーとしてSLOに向き合う 〜Mackerelチームの事例〜]] を wiki 化した。39 スライド全ページを画像で確認。transcript なし。 **核心**: - **SLO の動機は「チームで判断を回す」**: 信頼性に関わる技術判断を PO が個人で担う代わりに、SLO という数値基準でチームが自律的に判断できるようにする。「判断が減ることが PO にとっての嬉しいポイント」と明示（p.37）。 - **信頼性の定義はユーザー主語**: O'Reilly SLO 本を引用し「ユーザーの期待に沿っているか」を採用。外形監視では「到達できない状態が正しい挙動」という SaaS 特有の難しさも示す。 - **DORA 2022 のフロー段階/後期段階**: 以前は停止メンテ時間長・デプロイ週 2 回・リリース頻度低い状態から改善（p.15）。 - **Error Budget Policy は最も緩いアクションから**: 「調査をするか判断する」という最低限で開始（p.33-34）。Atlassian（SREcon18 Asia）・Takamura（2026 神戸）と並んで 3 社目の「緩く始める」実践が独立に確認された。 - **SLO の活用シーン**: P99 悪化でも SLO 割らなければ「無視」、大仕組み変更エラーでは「リリーススケジュール調整」と意思決定できる（p.35）。 **作成・更新ページ**: - source (new): [[@2023__SRENext2023__プロダクトオーナーとしてSLOに向き合う 〜Mackerelチームの事例〜]] - entities (new): [[渡辺 起]] - entities (updated): [[Mackerel]]（SLO 導入事例・チーム構成・DORA 位置・Error Budget Policy 追記） - concepts (updated): [[サービスレベル目標]]（PO 視点・ユーザー主語定義・仮値スタートの 3 知見追記）/ [[エラーバジェット]]（「最初は最も緩いアクション」3 社横断知見追記） --- # 2026-06-30: Measuring Availability the Player Focused Way (SREcon25 Americas, Maxfield Stewart, Riot Games) [[Maxfield Stewart]]（[[Riot Games]] Technical Director: Live Operations）が SREcon25 Americas（2025-03）で発表した [[@2025__SREcon25Americas__Measuring Availability the Player Focused Way - How Riot Games Changed Its Availability Culture]] を wiki 化した。50 スライド全ページを画像で確認。transcript なし。 **核心**: - **Player Minutes = SUM(CCU per minute)**: ゲームの可用性をサービス稼働率ではなく「プレイヤー分（同時接続ユーザー数 × 分）の中断割合」で計測する。大規模インシデントは自動的に大きく反映され、季節変動も自然に吸収される「重み付き可用性計測」。 - **Player Journey**: Connecting（Login/Patching）/ Purchasing（Content/Currency）/ Play（6 フェーズ）の 3 カテゴリ 10 分類。P1-P4 優先度（プレイヤーベース影響割合: >50%/15-50%/1-15%/<1%）と組み合わせることで「LoL NA P3 Login 10 min」という共通言語が成立する。 - **SLO ターゲット**: 99% Availability as Measured by the Player Journey。全ゲーム合計で月間 200 billion player minutes 超を母数とする。 - **CEO OKR による文化定着**: Tableau 日次ダッシュボード + 月次確定レポート + CEO 強制の会社レベル OKR の三層構造。CTO スポンサー・テックリードのグラスルーツ・幹部向けトレーニングも並行して機能。 - **3 年の成果**: 可用性 97-98% → 99%、Live Ops モラルサーベイスコア 1.5 → 4.3、Live Ops 組織 30-35 名 → 80 名に成長。2023 年に組織構造がレポート構造に合わせて変化（コンウェイの法則の逆作用）。 **作成・更新ページ**: - source (new): [[@2025__SREcon25Americas__Measuring Availability the Player Focused Way - How Riot Games Changed Its Availability Culture]] - entities (new): [[Maxfield Stewart]], [[Riot Games]], [[Derek Defields]] - concepts (new): [[Player Journey]]; (updated): [[サービスレベル目標]]（CCU 重み付き可用性計測・CEO OKR 定着手法の横断的知見追記） --- # 2026-06-30: DO, RE, Me: Measuring the Effectiveness of Site Reliability Engineering (SREcon22 Americas, Dave Stanke) [[Dave Stanke]]（Google Cloud Developer Relations Engineer）が SREcon22 Americas（2022-03-16、San Francisco）で発表した [[@2022__SREcon22Americas__DO RE Me - Measuring the Effectiveness of Site Reliability Engineering]] を wiki 化した。49 スライド全ページを画像で確認。transcript なし。 **核心**: - **DORA 2021 年初の SRE 定量調査**: 1,200 名の調査で回答者の 52% が SRE プラクティスをある程度実践。DevOps/SRE が役職別回答者の 21%（開発/エンジニアリング 22% に次ぐ）。 - **Four + 1 指標**: DORA の従来 4 指標（デプロイ頻度・変更リードタイム・復旧時間・変更失敗率）に Reliability（旧 Availability）を追加。「Availability → Reliability」へのリネームが SRE の視点を反映。 - **SRE は人・システム・ビジネスに良い**: SRE はバーンアウトを緩和し、運用の共有責任は信頼性成果を予測し、高信頼性はビジネス成果（市場シェア・収益性・従業員定着）を予測する。 - **信頼性は force multiplier**: Software Delivery Performance がビジネス成果に与える影響を信頼性が乗算的に増幅する。3 矢印図（赤横×青縦→黒斜め）で視覚化（p.40-42）。 - **Elite パフォーマーの圧倒的優位**: 低パフォーマー比で 973 倍頻繁なデプロイ、6570 倍速いリードタイム、3 倍低い変更失敗率、6570 倍速い復旧。 - **Dave のホットテイク 3 件**: (1) SRE は DevOps の**一部**を実装（全部ではない）、(2) DevOps 文化≈SRE 文化≈TPS≈心理的安全性、(3) Ops is still Ops。 **作成・更新ページ**: - source (new): [[@2022__SREcon22Americas__DO RE Me - Measuring the Effectiveness of Site Reliability Engineering]] - entities (updated): [[Dave Stanke]] - concepts (updated): [[DORA]] / [[SRE]] --- # 2026-06-30: Is the S in SRE for "Security"? (SREcon25 Americas, John Benninghoff, Security Differently) [[John Benninghoff]]（[[Security Differently]] 創業者）が SREcon25 Americas（2025-03）で発表した [[@2025__SREcon25Americas__Is the S in SRE for Security]] を wiki 化した。29 スライド全ページを画像で確認。transcript なし。 **核心**: - **Safety-II の正規分布モデル**: 制約（ポリシー・コントロール）は分布を狭め悪い結果を減らすが、同時に良い結果も減らす（p.5-6）。一方、パフォーマンス向上は分布を右シフトし、悪い結果を減らしつつ良い結果を増やす（p.7-8）。セキュリティへの含意: セキュリティは「コストとして最小化すべきもの」でなく「パフォーマンス投資」として扱う。 - **3つのデータセット（2019年）が独立に示した相関**: DORA Accelerate 報告書はデプロイ頻度・リードタイム・復旧時間・変更失敗率が連動することを示し、Veracode SOSS Volume 9 は年間300回以上スキャンする組織が脆弱性をオーダーマグニチュード速く修正することを示し、Sonatype 報告書は「依存関係を頻繁にアップデートするプロジェクトは総じてより安全」であることを示した。 - **トップ2セキュリティコントロール = SRE の日常**: Woods & Seymour (2024) のメタレビューが示した最上位2コントロール（攻撃面管理・パッチ頻度）は、SRE の基本業務（インベントリ・構成管理、ソフトウェア・依存関係管理）と完全に対応する（p.18）。 - **インシデント対応の比較**: セキュリティインシデントは数日〜数週間・情報制限・フォレンジクス。SRE インシデントは数時間・情報共有・高テンポ。スキルは相補的だが、情報フローの文化差が課題。損失規模は桁違い（セキュリティ: $100-$10B、アウテージ: $100-$10M）。 - **Security Level Objectives**: SLO のセキュリティ版。損失許容モデルは困難なため、リスクと相関する先行指標（脆弱性率・開放ポート数・MFA カバレッジ等）に閾値を設定してリソース配分を意思決定する。 **作成ページ**: - source: [[@2025__SREcon25Americas__Is the S in SRE for Security]] - entities (new): [[John Benninghoff]] / [[Security Differently]] - concepts (new): [[Safety-II]] / [[Security Level Objectives]] **現在の主要 concept の状態**: - [[Safety-II]]: 「悪い結果の非発生 → 良い結果の増加」という枠組み。SRE・セキュリティ両分野への含意が豊富。今後複数ソース横断で深化させる余地大。 - [[Security Level Objectives]]: 実践事例が 1 ソースのみ。具体的な実装例（Prometheus/Grafana での指標計装）が次の問い。 - [[SRE]] との接点: セキュリティとの相互強化は `wiki/concepts/SRE.md` にまだ未反映。次回更新候補。 --- # 2026-06-30: How to SRE When Everything's Already on Fire (SREcon19 EMEA, Alex Hidalgo + Alex Lee, Squarespace) [[Alex Hidalgo]]・[[Alex Lee]]（[[Squarespace]] SRE）が SREcon19 EMEA（2019-10、ダブリン）で発表した [[@2019__SREcon19EMEA__How to SRE When Everything is Already on Fire]] を wiki 化した。105 スライド全ページを画像で確認。transcript なし。 **核心**: - **SRE 7 原則の実録適用**: Squarespace の ELK スタック（ログ集約システム・最大トラフィックサービス）が 2018〜2019 年に繰り返し大規模インシデントを起こした状況を、7 原則（①アラート精選→②SLO/エラーバジェット→③オブザーバビリティ強化→④環境改善→⑤ICS 適用→⑥ポストモーテム→⑦反復改善）で変革した。 - **エラーバジェットが「全力対処の許可証」として機能**: 2019-03-04 に SLO（99%/5 分以内）を定義、03-05 の障害でエラーバジェット枯渇を宣言し、「これで全力で対処できる」と組織的に正当化できた。エラーバジェット = 信頼性優先へフォーカスする許可、という実証事例。 - **アラート疲労は 2,600 年前から記録された問題**: イソップ寓話「泣いた狼」から始まり、ヘルスケア・鉱業・建設・原子力の研究、そして IT 運用の多数コンポーネント監視へ。解決策は「Kafka 積み残し ÷ Logstash レート = エンドツーエンドレイテンシ」という単一ユーザー視点 SLI への置き換え。 - **37 時間インシデントと ICS 引き継ぎ**: 2019-03-21〜23 の 37 時間インシデントで複数回の Incident Commander 引き継ぎが発生。ICS（1968 年アリゾナ州の消防士が形式化）の役割分担（IC→Operations/Communications/Planning Lead→サブリード）が制御を保った。 - **根本原因は「シャード数 2,200 > Elasticsearch 推奨上限 600」**: 30GB ヒープノードは最大 600 シャード推奨（Elastic.co 公式）を大幅超過していた。「The Unshardening」オペレーションで解決。 - **SLO 改善の数値**: 旧 SLO「99% / 5 分以内」→ 新 SLO「99.9% / 2 分以内」（2019-05-10 更新）。エラーバジェットが信頼性改善の進捗指標として機能した。 **作成・更新ページ**: - source: [[@2019__SREcon19EMEA__How to SRE When Everything is Already on Fire]] - entities (new): [[Alex Hidalgo]] / [[Alex Lee]] - entities (updated): [[Squarespace]] - concepts (updated): [[アラート疲労]] / [[サービスレベル目標]] / [[エラーバジェット]] / [[ポストモーテム]] --- # 2026-06-30: Beyond Sequential: A Recipe for Async Pipeline Observability and Alerting (SREcon25 Americas, Jash Mistry + Gabriela Medvetska) [[Jash Mistry]]・[[Gabriela Medvetska]]（[[eBay]] SRE）が SREcon25 Americas（2025-03）で発表した [[@2025__SREcon25Americas__Beyond Sequential - A Recipe for Async Pipeline Observability and Alerting]] を wiki 化した。50 スライド全ページを画像で確認。YouTube 自動字幕（英語）から transcript を取得（機械精度）。 **核心**: - **非同期パイプライン固有の SLI 設計**: イベントは SUCCESS・ABANDONED・RETRY の 3 状態を取るが、RETRY は過渡状態のため Valid Events から除外。可用性 SLI = SUCCESS / (SUCCESS | ABANDONED)、レイテンシ SLI = Producer から Retry Queue を含む end-to-end 累積 histogram の `le="10000"` 比率。 - **5 種類の SLI を 2 種類に集約できる**: Freshness・Quality・Throughput は Availability と Latency から導出可能（口頭説明で補足、スライドには記載なし）。 - **マルチウィンドウ・マルチバーンレートアラート**: Critical（1h+5m/14.4, 6h+30m/6）と Warning（1d+2h/3, 3d+6h/1）の 4 レベル。eBay では Warning の 2 レベルのみを採用。 - **データ損失アラートを必ず併置**: `absent(sum(sli_valid_events{...}))` でメトリクス欠損を独立検知する。 - **ビジネスインパクトの定量化**: ML 推薦システムの導入で旧システム比 2.1% の収益増加。SLO はエンジニアリング品質管理だけでなくビジネス価値の定量化ツールとして機能する。 - **ケーススタディ 2 件**: 2025-02-19 可用性急落（下流デプロイ起因）・2025-01-15 MyeBay レイテンシ 30s→45s 上昇（Critical 6h アラート）。 **作成・更新ページ**: - source: [[@2025__SREcon25Americas__Beyond Sequential - A Recipe for Async Pipeline Observability and Alerting]] - entities (new): [[Jash Mistry]] / [[Gabriela Medvetska]] - entities (updated): [[eBay]] - concepts (updated): [[サービスレベル目標]] / [[エラーバジェット]] / [[イベントベースSLO]] / [[アラート疲労]] --- # 2026-06-30: 9 Things You Should Do When Starting to Use SLOs (SREcon23 EMEA, Sal Furino) [[Sal Furino]]（Customer Reliability Engineer）が SREcon23 EMEA（2023-10-11、ダブリン）で発表した [[@2023__SREcon23EMEA__9 Things You Should Do When Starting to Use SLOs]] を wiki 化した。40 スライドを全ページ画像で確認。transcript なし（audio.m4a 生成済み、Whisper 未完了）。 **核心**: - **3 カテゴリ・9 アドバイスの構造**: ①システムを理解する（Measure Meaningful Things・Success Rates > Error Rates・Provide Raw Data）、②期待値を理解する（Look Back to Look Forward・Observability Without Action is Just Storage・Different Time Windows for Different Folks）、③逸脱を認識する（Enrich Dashboards・Document SLOs・Your Problems Aren't Unique） - **「Fortress Bank」事例**: 架空の金融/カードプロセッサを使い、カスタマージャーニー定義（第三者送金）→サービスアーキテクチャ全体図→Level 1/2 Ack フロー→レイテンシベンチマーク表（パーセンタイル別分類ラベル付き）→アクションテーブルを一貫して示す。特に p.27 のアクションテーブル（p99.9→Full Outage Crisis Mode、p99→Page on Call、p95→ServiceNow Ticket、p90→Slack Warn）は SLO 違反 → アクション設計の具体例として有用。 - **成功率 > エラー率**: 悪い挙動の定義は「既知の問題のみ」。成功を定義すれば「それ以外はすべて不確か」という包括的定義になる。 - **ステークホルダー別時間窓**: 同一 SLI を 24h/48h（SRE/Ops）・14D/2W（Dev）・Monthly/Quarterly（Arch/Leadership）の 3 窓で評価。 - **SLODLC（SLO Development Lifecycle）**: INITIATE→DISCOVER→DESIGN→IMPLEMENT→OPERATE の 5 フェーズ。定期的 Review ループと 3 横断レイヤー（ビジネス/ソフトウェアライフサイクルへの整合・ステークホルダーとの対話・知見の共有）を持つ。slodlc.dev で公開。 - **WWWWHW 文書化**: SLO の存在理由を What/Where/Who/When/How/Why の 6 要素で文書化し、バージョン管理する。担当者交代を乗り越えるための制度記憶として機能する。 - **オープン標準とコミュニティ**: OpenTelemetry・Open SLO・DORA・R9Y.dev・SLODLC の標準/フレームワーク、LFI・Art of SLOs・DevOpsDays・SRECon コミュニティへの接続を推奨。 **新規ページ**: [[@2023__SREcon23EMEA__9 Things You Should Do When Starting to Use SLOs]], [[Sal Furino]], [[SLODLC]]。 **更新ページ**: [[サービスレベル目標]]（成功定義 > エラー定義・ステークホルダー別時間窓の横断的知見を追記）, [[SLI-SLO段階的導入]]（SLODLC との対応関係・WWWWHW 文書化の横断的知見を追記）。 --- # 2026-06-30: Run, Walk, Crawl, or How We Failed Our Way to SLO Readiness (SREcon25 EMEA, Rob Durst, Spring Health) [[Rob Durst]]（[[Spring Health]] SRE）が SREcon25 EMEA（2025-10-08、ダブリン）で発表した [[@2025__SREcon25EMEA__Run Walk Crawl or How We Failed Our Way to SLO Readiness]] を wiki 化した。51 ページ PDF を全ページ画像で確認。transcript なし（YouTube 動画 URL 未取得）。 **核心**: - **SLO 導入は社会技術問題（socio-technical problem）**: 特に "socio"（組織・人・プロセス）側が律速になる。オブザーバビリティ基盤が整っていても組織側条件が揃わなければ SLO は定着しない。 - **4 度の挑戦と失敗の系列**: - Attempt #1（Run, 2022-05）: Slack で SLOconf を見つけて Google Doc 作成。Admin SLI は空白のまま担当者交代（TAG IN）で中断。失敗理由: 所有権が曖昧。 - Attempt #2（Walk, 2023-07）: Notion 移行・Datadog SLO 実装。Mobile と NBD テーブルは空白のまま TAG IN。失敗理由: 標準プロセス未確立、Attempt #1 と SLI 定義が非互換。 - Attempt #3（Crawl, 2024 頃）: MOP Initiative 内部記事・Pit of Success フレームワーク整備。STOP。失敗理由: ロードマップ枠の専任 SRE リソースがなかった。 - Attempt #4（成功, 2025）: 内部記事・SLO テンプレート・ワークショップ → CD パイプライン SLO を Datadog で実運用 → RFC: Error Budget Based Code Freeze 承認（Holidays '25: 2025-12-04〜2026-01-16）。 - **SLO 準備度チェックリスト（Reliability Initiative Framework）の 4 条件**: 1. オブザーバビリティ基盤へのコミット 2. ノミナル状態と所有権の概念 3. 確立された標準とプロセス 4. ロードマップ枠の保護時間つき専任 SRE リソース - **Spring Health の成長**: 2022（50 eng・0 SRE・250,000 req/day）→ 2025（200 eng・8 SRE・30,000,000 req/day・300 デプロイ/週）。 **新規ページ**: [[@2025__SREcon25EMEA__Run Walk Crawl or How We Failed Our Way to SLO Readiness]], [[Rob Durst]], [[Spring Health]]。 **更新ページ**: [[サービスレベル目標]]（SLO 組織導入失敗律速・スタートアップでの定着 Lv5 の横断的知見を追記）, [[SLI-SLO段階的導入]]（4 条件前提条件診断・担当者交代問題・エラーバジェットコードフリーズの横断的知見・未解決の問いを追記）。 --- # 2026-06-30: Not All Minutes Are Equal (SREcon23 Americas, Troy Koss + Michael Goins, Capital One) [[Troy Koss]]・[[Michael Goins]]（[[Capital One]]）が SREcon23 Americas（2023-03-23）で発表した [[@2023__SREcon23Americas__Not-All-Minutes-Are-Equal]] を wiki 化した。40 スライドを全ページ画像で確認。transcript なし（Whisper 失敗・YouTube 字幕 HTTP 429）。 **核心**: - **SLO 採用失敗の構造**: 「会議/書籍/記事で見た → 導入 → 結果はスゴい → また会議で紹介」という自己循環の「循環販売戦略」。メトリクスは自己正当化しない。 - **時間スライス SLO の問題**: すべての分を 1 票として扱う。ピーク時 1,000 リクエストの分も深夜 10 リクエストの分も同等のバジェット影響。"Baddest Incident 400%↓"（時間スライス）vs. 36.6%↓（イベントベース）という実例で逆転現象を示した。 - **イベントベース SLO への移行**: SLI = Good Events / Total Events で集計するとインシデント深刻度に比例した EBR 消費が得られ、「ビリーバブルなシグナル」になる。 - **採用ロードマップ 6 段階**: Study → Experiment → Fix → Understand Signals → Fanfare & Action → Scale（反復ループ）。 - **エラーバジェットシグナル**: Slow burn（変更起因のじわじわ消費）/ Fast burn（インシデント急消費）/ Recovery / 複合型。特に「No Incident 49.5%↓」（インシデントなしのバグ起因消費がインシデント起因より大きい）は重要パターン。 - **Default SLO 式**: SLO_default = (bad / ((EB%-1) × Total) + 1) × 100。「何% にすればいいか分からない」チームへの出発点。 - **EB Policy**: Leadership・Dev・Product・SRE の 4 者が顧客中心で共有所有。 **ページ更新**: [[エラーバジェット]]（時間スライス vs. イベントベース・シグナルパターン・EB Policy 4 者共有所有の横断的知見 3 項目追加）。 **新規ページ**: [[Michael Goins]], [[Troy Koss]], [[イベントベースSLO]]。 **更新ページ**: [[Capital One]]（SRE 実践ドメインを追記）。 --- # 2026-06-30: Measuring Reliability: What Got Us Here Won't Get Us There (SREcon22 EMEA, Štěpán Davidovič) [[Štěpán Davidovič]]（[[Google]]、Senior Staff SRE、CFO テクニカルアドバイザーオフィス）が SREcon22 EMEA（2022-10-25、アムステルダム）で発表した [[@2022__SREcon22EMEA__Measuring Reliability - What Got Us Here Won't Get Us There]] を wiki 化した。42 スライドを全ページ画像で確認。YouTube 動画 URL 取得不可のため transcript なし。 **核心**: - **SLI/SLO は単一問いへの回答モデル**: ステークホルダー別（オンコール〜CEO）に時間窓（1分〜>1年）と対象 SLI 数（1〜1000）が全く異なる。単一の SLO ダッシュボードは 5 種の問いのどれに答えているか不明確。 - **現場はすでにアドホックモデルを構築している**: オンコールエンジニアは緩和確認に 15 分窓を使い、SLO ウィンドウも目標値も無視している（スライドに赤注釈で明示）。 - **エラーバジェットの誤差マージン**: 1M USD/yr → 99% SLO と設定しても、インパクト推定が桁違いに不正確なら誤差バジェット自体が意味をなさない。3 人の独立評価を推奨。 - **線形性仮定の問題**: 時間（1000×1 分停止 ≠ 1×1000 分停止）・空間（一部ユーザーへの完全障害 = 全ユーザーへの軽微障害）の両方で SLO モデルが失敗する。 - **SLI は最容易データ、外部シグナル統合が次のステップ**: Twitter 苦情・クラウドソース障害報告・ユーザーフィードバックを補完として使うべき。 - **オペレーショナリゼーション**: 問いの特定 → モデル構築 → 歴史データによるバックテスト の 3 ステップ。 **エンティティ更新**: [[Štěpán Davidovič]] に SREcon22 EMEA 貢献を追記（O'Reilly レポートとの連続性を明記）。 **概念更新**: [[サービスレベル目標]] に横断的知見 3 項目追加（ステークホルダー別問い空間、アドホックモデル形式化、線形性仮定の限界）。[[エラーバジェット]] に横断的知見 1 項目追加（誤差マージンの定量的議論）。 --- # 2026-06-30: HPC Downtime Budgets (SREcon16 Europe, Cory Lueninghoener) [[Cory Lueninghoener]]（[[Los Alamos National Laboratory]]、HPC 設計グループリーダー）が SREcon Europe 2016（2016-07-12）で発表した [[@2016__SREcon16Europe__HPC Downtime Budgets]] を wiki 化した。37 スライドを全ページ画像で確認。YouTube 自動字幕トランスクリプトあり（機械精度）。 **核心**: - **エラーバジェットの HPC 適応**: 「0.01% of 1,000 HPC ジョブ = 1/10 ジョブ」では意味をなさない。代わりに四半期ダウンタイム時間（30 時間 = DST 3 回 × 10 時間、利用可能時間の 1.4%）を予算単位とする。 - **バーンダウンチャート**: Y 軸を残り時間（0–30h）、X 軸を日付とした折れ線グラフ。計画消費ライン（直線）に対して各クラスタの実消費を重ね合わせる。 - **Wolf クラスタ事例**: 高速ネットワーク障害で一晩停止し四半期予算をほぼ使い果たし −12h へ落下。 - **SRE 普及論**: 「これは改宗・伝道の課題でなく、コミュニティ形成の課題だ」。 **新規ページ**: `wiki/sources/@2016__SREcon16Europe__HPC Downtime Budgets.md` / `wiki/entities/Cory Lueninghoener.md` / `wiki/entities/Los Alamos National Laboratory.md` **更新ページ**: `wiki/concepts/エラーバジェット.md`（HPC 適応横断的知見・Wolf 余剰時間問い追記） --- # 2026-06-30: SLX: An Extended SLO Framework to Expedite Incident Recovery (SREcon21, Qian Ding & Xuan Zhang) [[Qian Ding]]・[[Xuan Zhang (Ant Group)]]（[[Ant Group]] Infra SRE）が SREcon21（2021-10-13、Virtual）で発表した [[@2021__SREcon21__SLX - An Extended SLO Framework to Expedite Incident Recovery]] を wiki 化した。40 スライド全ページ確認。transcript なし（audio.m4a 生成済み、Whisper 未完了）。 **核心**: - **SLO は検知には強いが調査（Investigation）には向かない**: 従来 SLO はメトリクス構築・検知・レポーティングには優れるが、クロスサービス調査の認知負荷を下げる設計になっていない。SLX（SLF + SLD + SLX Graph）がこのギャップを埋める。 - **SLX 5 概念**: SLI（指標）→ SLO（目標）→ SLA（合意）+ SLF（SLI を詳細ラベル次元でスライス）+ SLD（依存サービスのメトリクス）。SLX Graph は SLA→SLO→SLI を実線・SLF を点線・SLD をグレーノードで結んだ依存グラフ。 - **SLX Graph 走査**: 障害 SLO を SLF の異常値で絞り込み、SLD エッジをたどり「時系列相関のある異常 SLO 依存チェーン」を自動特定。調査の出発点を提示する。 - **SLO 爆発問題**: 50 コンポーネント × 5 KUJ × 3 SLO 種別 × 3 実行環境で爆発。GitOps（SLO 定義 YAML → Git → ArgoCD → Kubernetes → Prometheus/Grafana）で統一管理。 - **異常検知**: Observation → Prediction（統計回帰/ML）vs. Threshold（確率分布/経験値）の動的閾値（±3σ バンド）。3 大落とし穴：データ品質/NaN、次元の呪い（コンテナ ID が 430 万カーディナリティ）、ハイパーパラメータ執着。 - **L0/L1/L2+ オートパイロット**: 手動制御 → 障害分析・復旧推奨 → 完全自動化（SLO を調整ターゲットに）のロードマップ。 **新規ページ**: [[@2021__SREcon21__SLX - An Extended SLO Framework to Expedite Incident Recovery]] / [[Qian Ding]] / [[Xuan Zhang (Ant Group)]] **更新ページ**: [[Ant Group]] / [[サービスレベル目標]] / [[異常検知]] --- # 2026-06-30: Principled Performance Analytics (SREcon22 Americas, Narayan Desai & Brent Bryan) [[Narayan Desai]]・[[Brent Bryan]]（[[Google]] Cloud SRE）が SREcon22 Americas（2022-03-16）で発表した [[@2022__SREcon22Americas__Principled Performance Analytics]] を wiki 化した。40 スライド全ページ確認。transcript 処理中（YouTube: `https://www.youtube.com/watch?v=zOu5cLBu4LI`）。 **核心**: - **「SLO は実現不可能（not feasible）」という根本批判**: エラー認識は曖昧・バグ由来・較正誤差・定期メンテなしという 4 つの構造的問題から「エラーは浅いデータ（shallow data）」にとどまる。SLO はエラー認識という人間のゲシュタルト的判断に依存するため、原理的に自動化・スケール化できない。 - **[[2σ手法]] — 較正不要・結合可能な性能定常性検定**: 1. コホート分割: ワークロードを Intent（SQL パターン・データ量など）で分類 2. ベースライン構築: 各コホートの過去パフォーマンスを正規分布近似 3. z スコア監視: `z = (obs - baseline mean) / baseline std`、窓内で z≥2 のワークロード**割合**を監視（通常 2-5%、10% 超 = 警戒） - z スコアは標準化済みのためコホート間で結合可能・閾値設定が不要（calibration-free） - **5 つのアプリケーション**: ①18 時間先行障害検知（SLO より早い） ②階層的診断（I/O Time 等の指標別 z スコア並行計算） ③逸脱影響評価 ④予期しない相関計測（隔離障害検知）⑤コホート A/B テスト - **2019→2021→2022 三連作**: Desai の SREcon19「SLO の暗黙的仮定批判」→ SREcon21「定常性モデル提唱」→ SREcon22「2σ手法として数理実装・GCP 本番適用」という連続する研究線。 **新規ページ**: `wiki/sources/@2022__SREcon22Americas__Principled Performance Analytics.md` / `wiki/concepts/2σ手法.md` / `wiki/entities/Brent Bryan.md` **更新ページ**: `wiki/entities/Narayan Desai.md`（SREcon22 登壇・2σ手法追記）/ `wiki/concepts/定常性モデル.md`（2σ手法との連続性・SREcon22 ソース追記）/ `wiki/concepts/サービスレベル目標.md`（SLO 実現不可能批判の横断知見追記） --- # 2026-06-30: Going from 30 to 30 Million SLOs (SREcon22 EMEA, Alex Palcuie) [[Alex Palcuie]]（[[Google]] SRE、GCE Compute API チーム）が SREcon22 EMEA（2022 年 10 月、アムステルダム）で発表した [[@2022__SREcon22EMEA__Going-from-30-to-30-Million-SLOs]] を wiki 化した。28 スライド全ページ確認。transcript なし（動画 URL 未取得）。 **核心**: - **SLO 進化の 3 段階**: リージョン × 3 指標 = 約 30 SLO → API メソッド × リージョン × 3 指標 = 約 1,000 SLO → さらに顧客(プロジェクト)単位 = 3,000 万 SLO。GCE の複雑性成長（2016→2021: API 方法 97→423、リージョン 9→33）が SLO 爆発の背景。 - **レイテンシ SLO トリック**: `target = fast requests / total requests`。"fast" = ターゲットレイテンシ以内のリクエスト。P90 SLO なら目標値を 90% に設定する。複数 API のレイテンシ閾値を混在させても単一計算基盤で評価できる。Hartmann・Moyer (SREcon19) の「パーセンタイル平均化不能問題」への本番実装解答。 - **集計 SLO の限界**: Rachel Kroll "Your nines are not my nines"（2019）——プロバイダは 99.999% を保ちながら個別顧客のビジネスは崩壊している。HN "Your nines are not my nines" (424 points)。 - **5 エラーのルール**: 少トラフィック顧客への一律 SLO 適用は不合理。`target = 1 - 5 / total_requests` で動的設定。1 万リクエスト以上で 99.95% に収束。 - **per-project SLO アーキテクチャ**: 宣言的 SLO 定義（YAML）→ Materialize Definition → ヒストグラム実体化 → Per-project SLI → Per-project SLO × 複数集計ビュー（Per-method SLO / Per-scope SLO / Count of projects SLO per scope / Per-project SLO with issues）。 - **運用 UI の 3 種類**: ①エラーバジェット超過かつバグなし（= 未知の問題）②集計健全・多数の顧客が逸脱③最多プロジェクトを侵害するバグランキング。 **新規ページ**: `wiki/sources/@2022__SREcon22EMEA__Going-from-30-to-30-Million-SLOs.md` / `wiki/entities/Alex Palcuie.md` **更新ページ**: `wiki/concepts/サービスレベル目標.md`（3 件の横断的知見追加）/ `wiki/concepts/SLI-SLO段階的導入.md`（SLO 分割軸進化の横断的知見追加） --- # 2026-06-30: Beyond Goldilocks Reliability (SREcon21, Narayan Desai) [[Narayan Desai]]（[[Google]] Cloud SRE）が SREcon21（2021-10-14）で発表した [[@2021__SREcon21__Beyond-Goldilocks-Reliability]] を wiki 化した。23 スライドを全ページ画像で確認。transcript なし（音声取得済み・Whisper 未完・YouTube 字幕 429 エラー）。 **核心**: - **Goldilocks Reliability の批判**: SLI を測って「ちょうどいい」閾値を設定する従来アプローチ（2 バケットヒストグラム）は 4 つの荷重仮定（①「ちょうどいい」が有意・②答えが 1 つ・③問いが既知・④答えが変化しない）に依存し、これらが崩れると信頼性評価が誤誘導される。 - **信頼性の 3 次元**: 可用性（必要なときにある）/ パフォーマンス（効果的に処理される）/ 正確性（期待どおりに動作する）。 - **定常性（Stationarity）モデル**: 各次元に定常性仮定を付与する（可用性＝i.i.d.エラー / パフォーマンス＝長時間一定 / 正確性＝同一入力同一出力）。定常性仮定の**違反を信号**として検知する。閾値の「範囲内か否か」から「通常状態からの乖離」へパラダイム転換。 - **定常性が露出する現象**: 準臨界パフォーマンスシフト / ゆっくり進行するインシデント / パフォーマンス退行 / サブシステム障害 / 隔離障害 / 顧客の痛みの直接検知。 - **階層的診断**: 「スロークエリ総時間割合」の定常性違反 → 「IO Time 別割合」で IO がボトルネックと特定（Google 本番 2021-03 事例）。 - **モデルへの姿勢**: George E. F. Box「All models are wrong, but some are useful.」+ Lorin Hochstein「...and some are dangerous.」——複数のモデルを作り、バックテストし、共有し、健全な懐疑主義を維持する。 **新規ページ**: `wiki/sources/@2021__SREcon21__Beyond-Goldilocks-Reliability.md` / `wiki/concepts/定常性モデル.md` **更新ページ**: `wiki/entities/Narayan Desai.md`（SREcon21 登壇追加・定常性モデル主要貢献追記）/ `wiki/concepts/SREの工学化.md`（定常性モデルが工学化の具体例という横断知見追記） --- # 2026-06-30: Squish Level Objectives (SREcon20 Americas, Dave Stanke) [[Dave Stanke]]（[[Google]] Cloud Platform Developer Advocate）が SREcon20 Americas で発表した [[@2020__SREcon20Americas__Squish Level Objectives]] を wiki 化した（41 スライド全ページ確認 + YouTube 自動字幕 449 行）。 **核心**: SRE の役割はユーザーに価値を届けることであり、プラットフォームエンジニアを含む技術スタック全体が「スクイッシュな（squishy = 感情的・非合理な）人間」である顧客へとつながる。SRE 原則 #2「システム信頼性はユーザーが決める」を製品品質へ拡張し「**製品の品質はわれわれではなく顧客が決める**（SRE Principle #2'）」とした。 **主要概念**: - **顧客理解の 3 手法**: Talk to them（定性 UXR、N>1）/ Be them（ドッグフーディング・共感セッション・競合体験）/ Mess with them（エラーバジェットを UX 実験に活用） - **Product = 認知的構築物**: 誰かが「他の選択肢ではなくこれ」を選ぶ認知的行為が製品を成立させる - **SLO Policy Rationale**: `Page loads < 1500ms | 99.95% | Rationale: Error rates > 0.05% correlate with significant increase in customer support tickets` という形式で技術閾値を顧客行動データで根拠づける **コンテキスト**: - サービスレベル目標に新規横断知見追加: SLO Rationale = 顧客行動観察を SLO ドキュメントのフィールドとして実装する最短経路 - SLI-SLO段階的導入に新規横断知見追加: Rationale フィールド = 定義成熟度 Lv3→Lv4 の具体的差分 --- # 2026-06-30: Latency and Availability Error Budgets Done Right at Scale (SREcon20 Americas, Fred Moyer) [[Fred Moyer]]（[[Zendesk]] SRE）が SREcon20 Americas（2020-12-08）で発表した [[@2020__SREcon20Americas__Latency-and-Availability-Error-Budgets-Done-Right-at-Scale]] を wiki 化した（37 スライド全ページ確認）。YouTube 字幕は 429 エラーで取得不可。transcript なし。 **核心**: SLI/SLO/EB の各公式を `[Metric Identifier][Operator][Metric Value]`・`[Success Objective][SLI][Period]`・`[Error Budget][SLI][Period]` に固定することで、1,000 名規模のエンジニア組織が自チームの SLO を作れるよう民主化した。 **主要概念**: - 複合 SLI（OR 結合）: `(response code != 5xx) OR (served in < 100ms)` を単一 SLI として扱い、単一エラーバジェットで可用性とレイテンシを同時管理 - マルチサービス EB 伝播: Edge(1% EB) → Mid(1% EB) → [Third party(1.0% ER) | Backend(0.1% ER)] 構成で、Mid は自コード 0.1% にも関わらず 1.1% を観測（Desai の SLO Algebra 未解決問題の具体例） - EB 民主化の 3 鍵: (1)実世界の例、(2)機械解析可能な公式、(3)明示性 **前身との関係**: SREcon19 Americas "Latency SLOs Done Right"（パーセンタイル集約問題）の実組織展開版。2 年連続発表で「測定 → 実装 → 組織展開」を体系化。 **Whisper transcript 補完**: SLI 違反と SLO 違反の区別（SLI 違反は都度・SLO 違反はバジェット枯渇時 1 回）、段階的バーン率（50%/80% で信頼性作業優先）、"Latency SLOs Done Right" の 3 登壇者（Moyer + Theo Schlossnagle/Circonus 創設者 + Henrik Rexed/データサイエンティスト）、Zendesk は Datadog を使用、"EB は責任追及でなく優先順位付けのため" の明言を確認。 **未確定**: Zendesk 内部メトリクス名（p.31 UI 内で省略）。 --- # 2026-06-30: Avoiding Goodhart's Law — Use SLO's as Tools Not Cudgels (SREcon20 Americas, Marco Coulter) [[Marco Coulter]]（[[AppDynamics]] AIOps Technical Evangelist、@marcocoulter）が SREcon20 Americas（2020-12-07、バーチャル開催）で発表した [[@2020__SREcon20Americas__Avoiding Goodhart's Law]] を wiki 化した。35 スライドを全ページ画像で確認。YouTube 動画（`iKjKFeTSJGs`）の Whisper 文字起こしは処理中（未取得）。 **核心**: SLO が「達成すべき目標（棍棒/cudgel）」として組織プレッシャーになると、チームはシステムを改善せず SLO をゲームする——医療ラボシステムの HL7 キューで「キュー深度 100 以下」という SLO に対してメッセージ削除でゲームできることを具体例として示した。 **主要概念**: - **グッドハートの法則の SRE 版**: 「指標を目標にすると良い指標でなくなる」が SLO ゲーミングとして現れる - **3 次元フレームワーク**: Code（トランザクション成功率）・Infrastructure（パフォーマンスカーブ）・Business & CX（行動ベース SLI）で評価することでゲーミング耐性が高まる - **パフォーマンスカーブ SLO**: 単一閾値ではなく 90%/30s・99%/1min・99.9%/5min の多段定義 - **行動ベース CX SLI**: 「10 秒以上後 5 分以内の再試行」= ユーザー不満の行動プロキシ（HTTP 200 でも検知できる） - **SLO 交渉プロセス**: Prepare → Warmup → Test Drive → Assess → Propose → [RECUR] → Agree の反復的交渉 **新規作成**: - `wiki/sources/@2020__SREcon20Americas__Avoiding Goodhart's Law.md`（source、developing） - `wiki/entities/Marco Coulter.md`（entity、seed） - `wiki/entities/AppDynamics.md`（entity、seed） **更新**: - `wiki/concepts/グッドハートの法則.md` — SRE/SLO 文脈応用セクション追加（ゲーミング例・3 次元対策・横断的知見） - `wiki/concepts/サービスレベル目標.md` — パフォーマンスカーブ SLO・行動ベース CX SLI・3 次元時間窓差分・SLO 交渉プロセスを横断的知見に追加 - `wiki/concepts/SLI-SLO段階的導入.md` — グッドハートの法則対策としての 3 次元フレームワーク・反復的交渉の成熟度モデルへの接続を横断的知見に追加 **残タスク**: YouTube 動画（`iKjKFeTSJGs`）の Whisper 文字起こし完了後に口頭説明・Q&A を source ページに追記する。 --- # 2026-06-30: The Map Is Not the Territory — How SLOs Lead Us Astray (SREcon19 EMEA, Narayan Desai) [[Narayan Desai]]（[[Google]] SRE）が SREcon19 EMEA（2019-10-03、Dublin）で発表した [[@2019__SREcon19EMEA__The Map Is Not the Territory - How SLOs Lead Us Astray, and What We Can Do about It]] を wiki 化した。45 分動画を YouTube 字幕（自動生成、en-orig）で transcript 化し、12 フレームを抽出して視覚確認した。 **核心**: - **SLO は「地図」であって「領域」ではない**: SLO はサービス動作のモデルであり、モデルとして精度の限界を理解して使う必要がある。過信すると誤った方向に進む。 - **4 ユースケース×プロバイダ/コンシューマ分類**: Ongoing（日常管理）/ Design（設計時期待設定）/ Incident Response（インシデント影響評価）/ Bounding the Tail（テール管理）でプロバイダ・コンシューマの優先順位が異なる。単一汎用 SLO はいずれも中途半端。 - **SLO の暗黙仮定を確認する**: ①独立リクエスト、②均一重要度、③均一エラー分布——これらが成り立つかを最初に検証すべき。低 QPS・ユーザー固有エラー・ユーザー提供 SQL は仮定を崩す典型例。 - **テール管理に SLO を使わない（サンドバッギング問題）**: テール事象に備えて SLO を大幅に緩めエラーバジェットを積みすぎると、日常的な劣化が SLO 範囲内に収まり見えなくなる。エラーバジェットを「消費すべき」という通常の運用論も破綻する。 - **P50 括弧付き SLO**: Google 内部ジョーク「全サービスが公開 SLO ちょうどで動作したら崩壊する」を例に、P99 SLO だけでは日常体験を保証できないことを論証。P50 に括弧付き SLO を追加することを推奨。 - **SLO Algebra は未解決問題**: 複数サービスの SLO を合成して上位 SLO を予測する体系的手法がなく、現状は「桁でパッドする」のみ。直列/並列消費・フェイルオープン/クローズド動作を考慮した代数が必要。 **新規ページ**: `wiki/sources/@2019__SREcon19EMEA__The Map Is Not the Territory - How SLOs Lead Us Astray, and What We Can Do about It.md` / `wiki/entities/Narayan Desai.md` **更新ページ**: `wiki/concepts/サービスレベル目標.md`（SLO ユースケース分類・P50 括弧付き SLO・SLO Algebra の横断的知見 3 項目追記）/ `wiki/concepts/エラーバジェット.md`（テール管理のサンドバッギング問題追記） --- # 2026-06-30: Latency SLOs Done Right — enrichment pass (SREcon19 EMEA, Heinrich Hartmann) 2026-06-19 に初回取り込み済みの [[@2019__SREcon19 EMEA__Latency SLOs Done Right]] を全 33 ページ再確認し、欠落していた詳細を追記した。manifest エントリが未記録だったため補完。 **追記した情報**: - **p.26 HDR データ構造**: 46,081 ビン・±10^±128 範囲・2 有効桁 10 進浮動小数点・スパース符号化・300b/ヒストグラム典型値。OSS: hdrhistogram.org / libcircllhist。 - **p.31 代替マージ可能要約の系譜**: circllhist (Schlossnagle @ Circonus 2013)、HDR Histograms (Tene @ Azul Systems 2015)、t-digest (Dunning @ MapR, Erl @ Dynatrace 2015)、DD-Sketch (Masson @ DataDog 2019)。 - **p.32 ベンチマーク正確値**: circllhist 0.001% 誤差(挿入 0.86s/merge 0.000262s/p90 0.000005s)が精度・速度ともに最優。HDR 0.000% 誤差だが挿入 3.59s、t-digest 0.029% 誤差で挿入 97s、DD-Sketch 0.256% 誤差で挿入 2.39s。 - **p.21/24/30 ツール候補**: ログ方式 ssh+awk/ELK/Splunk/Honeycomb、カウンタ方式 Prometheus/Graphite/DataDog/VividCortext、ヒストグラム方式 Circonus/IRONdb/Google 内部ツール。 - **p.23 @phredmoyer 帰属**: カウンタグラフは Fred Moyer の ObservabilitySummit 素材の流用と考えられる。 **修正**: [[Heinrich Hartmann]] の role を "Data Scientist / Analytics Lead at Circonus" に修正。 **transcript**: YouTube 字幕フォールバックを試みたが別トーク（Meta プライバシー工学）のビデオを誤取得・削除済み。本発表の音声/字幕は取得できていない。 --- # 2026-06-29: SLOs for Data-Intensive Services (SREcon19 EMEA, Booking.com) [[Yoann Fouquet]]（[[Booking.com]] SRE）が SREcon19 EMEA（2019-10-02）で発表した [[@2019__SREcon19EMEA__SLOs for Data-Intensive Services]] を wiki 化した。29 ページスライドを全ページ画像で確認（p.26–29 はテキスト抽出で補完）。transcript なし。 **核心**: - **可用性・レイテンシ SLO だけでは不十分**: 最初に定義した SLO を見た検索サービスのステークホルダーは無関心だった。彼らが気にするのはデータの品質（一貫性・新鮮性・正確性・耐久性）であった。 - **[[データ品質SLO]] の 4 次元**: - **一貫性 (Consistency)**: プローブが全データノードで同一データを確認。SLO: 99.99% 一致。→ 第2案: ゲートウェイ内部比較に移行(外部 DB 参照なし) - **新鮮性 (Freshness)**: プローブが最近の予約の検索反映を確認。SLO: 99.9% / xx 秒以内 - **完全性 (Completeness)**: ストリームコンシューマー + プローブ - **耐久性 (Durability)**: Hadoop MR パイプライン - **正確性 (Accuracy)**: 定義困難として断念（「STOP - Really, you gotta stop」標識スライド） - **クエリバケット**: 手動分類(Query 1/5→50ms, Query 8/2→100ms, Query 3/4/6/7→目標なし)から、スコア+タイムアウトのしきい値による**自動分類**へ進化。 - **SLO が有効化した自動化**: - 自動緩和: Freshness Probe 違反 → 影響ノードへのトラフィック自動停止 - 自動修復: Completeness Probe 欠損 → Hadoop スナップショットから再処理 - **最大の恩恵**: Awareness（データ品質問題の可視化）と Confidence（対応行動の根拠）。 **新規ページ**: `wiki/sources/@2019__SREcon19EMEA__SLOs for Data-Intensive Services.md` / `wiki/entities/Yoann Fouquet.md` / `wiki/concepts/データ品質SLO.md` **更新ページ**: `wiki/entities/Booking.com.md` / `wiki/concepts/サービスレベル目標.md`（データ品質 SLO の横断知見2項目追記）/ `wiki/concepts/SLI-SLO段階的導入.md`（ステークホルダー関心と SLO 次元のミスマッチ知見追記） --- # 2026-06-29: Extending the Error Budget Model to Security and Feature Freshness (SREcon19 Americas, Pivotal) [[Jim Thomson]]・[[David Laing]]（[[Pivotal Software]] Cloud R&D）が SREcon19 Americas（2019-03-27、NYC）で発表した [[@2019__SREcon19Americas__Extending the Error Budget Model to Security and Feature Freshness]] を wiki 化した。51 ページスライドを全ページ画像として確認。transcript なし(音声取得済み・Whisper 未生成)。 **核心**: - **エラーバジェットモデルの普遍性**: SLI=ユーザー価値の計測値 / SLO=閾値 / ポリシー=閾値接近時の行動、という 3 要素が可用性以外のドメインにも適用できる。 - **[[脆弱性バジェット]]**(Vulnerability Budget): SLI=依存コンポーネントのパッチリリースからの経過日数・SLO=30 日・ポリシー=閾値接近時にパッチ適用。Equifax 侵害(CVE-2017-5638)の 67 日の窓に対して「30 日 SLO があれば防げた」。 - **[[フィーチャーフレッシュネス]]**(Legacy Budget): SLI=フィーチャーリリースからの経過日数・SLO=範囲(ブリーディングエッジ度)・ポリシー=90 日毎にアップグレード。k8s の N-2 ポリシーで「古すぎず新しすぎないバンド」を維持する。 - **Pivotal の実証**: PAS Stemcell に 30 日 SLO を 6 ヶ月間適用。年末年始を除いて SLO 維持(鋸波パターン)。 **新規ページ**: `wiki/sources/@2019__SREcon19Americas__Extending the Error Budget Model to Security and Feature Freshness.md` / `wiki/concepts/脆弱性バジェット.md` / `wiki/concepts/フィーチャーフレッシュネス.md` / `wiki/entities/Jim Thomson.md` / `wiki/entities/David Laing.md` **更新ページ**: `wiki/concepts/エラーバジェット.md`(横断的知見にモデル拡張を追記) / `wiki/entities/Pivotal Software.md`(SRE 実践を追記) --- # 2026-06-29: Latency SLOs Done Right (SREcon19 Americas, Fred Moyer, Circonus) [[Fred Moyer]]（[[Circonus]] Developer Evangelist）が SREcon19 Americas（2019-03-27、Brooklyn）で発表した [[@2019__SREcon19 Americas__Latency SLOs Done Right]] を wiki 化した。50 ページスライドを全ページ画像として確認。transcript なし。 **核心**: - **パーセンタイル平均化の誤り**: `p95(W1 ∪ W2) ≠ (p95(W1) + p95(W2))/2`。2 ノード (W1: p95=220ms, W2: p95=650ms) の例では実際の合算 p95=230ms に対し、平均は 430ms で **~200% の誤差**。非対称負荷時に問題を隠蔽する。 - **SLO 計算の 3 手法**: 1. **ログデータ**: Apache `%{msec}t` で~1GB/1000 万リクエスト。正確・柔軟だが高コスト・スケール困難。 2. **リクエストカウンタ**: `% success = 100 - (#failed_reqs/#total_reqs)*100`。シンプル・高性能・スケール可能。ただししきい値固定・過去遡及不可。 3. **ヒストグラム** (推奨): ログリニアヒストグラム (libcircllhist)。マージ可能 `h(A ∪ B) = h(A) ∪ h(B)`、~300 バイト/ヒストグラム、任意しきい値に後付け対応、<5% 誤差。 - **ビン境界設計**: libcircllhist は 2 有効桁の 10 進浮動小数点数 (10^{+/-128} 範囲) を固定ビンとして採用。Liz Fong-Jones が「しきい値がビン境界線上にあることを確認せよ」と補足。 - **結論**: TSDB での HDR ヒストグラムネイティブサポートは 2019 年時点で IRONdb 以外欠如。 **ソース関係**: 同タイトルを Heinrich Hartmann が SREcon19 EMEA でも発表 ([[@2019__SREcon19 EMEA__Latency SLOs Done Right]])。同社 (Circonus) の共通知見を異なる登壇者が展開したもの。 **新規ページ**: [[@2019__SREcon19 Americas__Latency SLOs Done Right]] / [[Fred Moyer]] **更新ページ**: [[Circonus]] / [[サービスレベル目標]] / [[ヒストグラムメトリクス]] --- # 2026-06-29: Case Study: Implementing SLOs for a New Service (SREcon19 Americas, Lawson, Squarespace) [[Arnaud Lawson]]（[[Squarespace]] Senior SRE）が SREcon19 Americas（2019-03-25、Brooklyn）で発表した [[@2019__SREcon19Americas__Case Study - Implementing SLOs for a New Service]] を wiki 化した。23 ページスライドを全ページ画像として確認。transcript なし（Whisper 失敗）。 **核心**: - **6 ステップの実装プロセス**: SLI 種別決定（ユーザー行動ログとコンポーネント分析）→ SLI 定義 → 計測方法選択 → SLI 収集と初期 SLO 推定 → エラーバジェット導出 → SLO 公開 - **ストレージサービス固有の耐久性 SLI**: リクエスト駆動側の可用性・レイテンシ SLI に加え、書き込んだオブジェクトが障害後も無損傷で再読み取りできる割合（耐久性 SLI）を分散ストレージバックエンドに別途定義した - **プローバーによる能動的計測**: 新規・低トラフィックサービスへの SLO 導入では受動的計測だけでは不十分。Go コードでバケット作成・削除・オブジェクトアップロード・ダウンロードをシミュレートし、slicollector で成功/失敗カウンタとレイテンシヒストグラムを収集 - **最終 SLO**: 可用性 99.9%（4 週間窓）、レイテンシ p90 < 300 ms・p99 < 2000 ms（4 週間窓）、耐久性 99.999999%（1 年窓） - **SLO と同時にエラーバジェットを計算・文書化**: SLO 設定直後に「0.1% 失敗許容・10% が 300ms 以上・0.000001% オブジェクト損失許容」を明示した **接続している知識**: - [[サービスレベル目標]]（異種コンポーネント SLI 分類・プローバー能動計測の知見を追記） - [[エラーバジェット]]（SLO 設定と同時計算・文書化プロセスの実践知を追記） - [[SLI-SLO段階的導入]]（新規サービスへのプローバー活用・SLO 公開ドキュメント実践知を追記） **関連する直前コンテキスト**: 昨日 Ketan Gangatirkar（Indeed）の「Quantifying Empathy Through SLOs」（SREcon18 Asia/Pacific）を取り込んだ。SLO をユーザー体験の「共感」として定義する発表と、今回の実装手順書的な発表が対比的で、SLO 理論と実践の両側面が揃った。 # 2026-06-29: Quantifying Empathy Through Service Level Objectives (SREcon18 Asia/Pacific, Gangatirkar, Indeed) [[Ketan Gangatirkar]]（[[Indeed]] VP of Engineering – Job Seeker）が SREcon18 Asia/Pacific（2018 年）で発表した [[@2018__SREcon18Asia__Quantifying Empathy Through Service Level Objectives]] を wiki 化した。152 ページスライドを全ページ画像として確認 + YouTube 自動字幕トランスクリプト（1104 行）。 **核心**: - **「SRE はユーザーではない」問題の定式化**: SLO がユーザー体験を決定し、SRE が SLO を決定するなら、SRE がユーザー体験を決定する——しかし SRE とユーザーは全く異なる存在。SRE のみが SLO を設計する組織は God Object アンチパターン（「全てを知り全てを制御しようとするコンポーネント」）と同じ構造的欠陥を持つ。 - **共感ギャップ（Empathy gap）の命名**: 「SLO を達成しているのに悲しいユーザー」を 2×2 マトリクスで定義。SLO がユーザーの痛みのしきい値より高い（ゆるい）目標になっている場合に発生。対極は「Overkill」（SLO 未達・嬉しいユーザー）。 - **ユーザー幸福の 6 フレーバー（#ARFCAapBof）**: 1) Availability（可用性）、2) Responsiveness（応答性）、3) Freshness（鮮度）、4) Completeness（完全性）、5) Accuracy and precision（精度）、6) Breadth of functionality（機能幅）。SLI 候補の網羅的発見フレームワーク。 - **S 字曲線による痛みのしきい値特定**: Tenfold（B2B カスタマーサポートツール）事例で可用性対生産性の S 字曲線を図示。99.95% が "tolerable" 上限、99.9% を下回ると "We're paying how much?\!?\!" ゾーン。SLO は痛みのしきい値より下に設定する。 - **カバレッジの 2 方向失敗**: カバー不足（ユーザーの問題を SLO が見ていない）とカバー過剰（ユーザーが気にしない項目を SLO でカバー）の Venn 図を提示。Binette/Flaming（SREcon18 Americas）の「ケイパビリティを SLI 設計の起点とする」手法と相補的。 - **5 ステップフレームワーク**: (1) ユーザーを知る → (2) プロダクトがユーザーに何をするかを理解する → (3) 6 フレーバーを適用する → (4) データでユーザーの痛みを探す → (5) SLO を痛みのしきい値より下に設定する。 **新規ページ**: [[@2018__SREcon18Asia__Quantifying Empathy Through Service Level Objectives]] / [[Ketan Gangatirkar]] / [[Indeed]] **更新ページ**: [[サービスレベル目標]]（共感ギャップ・6 フレーバー・S 字曲線しきい値の横断的知見を追記） --- # 2026-06-29: SLOs and SLIs in the Real World: A Deep Dive (SREcon18 Europe/EMEA) [[Elisa Binette]]（@elisabPDX）と [[Matthew Flaming]]（@mflaming、[[New Relic]] VP of Site Reliability）が SREcon18 Europe/EMEA（2018-08-30）で発表した [[@2018__SREcon18Europe__SLOs and SLIs in the Real World - A Deep Dive]] を wiki 化した。29 ページスライド（PDF 取得・全ページ画像化）および音声 MP3（Whisper 文字起こし処理中）から取り込み。本発表は SREcon18 Americas（2018-03-28）での同名発表の再演版であり、既存ソース [[@2018__SREcon18Americas__SLOs and SLIs in the Real World - A Deep Dive]] と内容はほぼ同一。 **核心**: - **ケイパビリティを SLI 設計の起点とする 7 ステップレシピ**: (1) システム境界特定 → (2) ケイパビリティ定義 → (3) 平易な言葉での「利用可能」定義 → (4) 技術的 SLI 定義 → (5) ベースライン計測 → (6) SLO 目標設定 → (7) 反復・調整。 - **ハードシャード per-shard SLO**: 3 ノード中 1 ノード障害時に水平スケールは全体 SLO 66%（比例）だが、ハードシャードはシャードごとに 0%/100%/100% となり全体集計 SLO では問題が隠れる（p.14）。 - **複合 SLO（AND 結合）**: 「99.95% 正常応答 AND 99.9% 1000ms 以内」→「99.9% が 1000ms 以内に正常応答」。2 SLI の AND 結合では厳しい方が支配（p.12）。 - **インフラ SLO は上位サービスより高く設定**: ネットワーク層は 99.99% 目標。ハード依存のインフラ障害では MTTR がインパクト層数とともに増加しグレースフルデグラデーションが困難（p.19）。 - **全体 dumb SLI**: 個別 SLI/SLO の合算でカバーできない盲点を「サンプルワークフローの成否」という粗いエンドツーエンド SLI でサニティチェック（p.25）。 - **SLI はアラートではない**: SLO 達成率の長周期監視と短周期障害アラートは役割が異なる（Recap ⑤、p.27）。 **新規ページ**: [[@2018__SREcon18Europe__SLOs and SLIs in the Real World - A Deep Dive]] **更新ページ**: [[サービスレベル目標]]（EMEA ソース追加）、[[Matthew Flaming]]・[[Elisa Binette]]（EMEA 版ソース追記） --- # 2026-06-29: How Atlassian Is Tackling Error Budgets, Agile Style (SREcon18 Asia) [[Gui Vieiro]]（[[Atlassian]] SRE Team Lead）が SREcon18 Asia (2018-06-06) で発表した [[@2018__SREcon18Asia__How Atlassian Is Tackling Error Budgets, Agile Style]] を wiki 化した。PDF 47 枚スライドを全ページ画像として確認（transcript なし）。 **核心**: - **Error Budgets 0.1 — 開発停止を最初のトリガーにしない**: 完全な Google SRE Book 形式のエラーバジェット（開発凍結）をいきなり適用せず、「SLO を達成しながら信頼性改善チケットを並行して積む」という緩い形で開始。 - **13 週中 7 週未達 → アクション**: Trigger を意図的に緩く設計し、翌四半期に 5 週以下へ引き締める段階的反復戦略。 - **週次 SLO 達成率の可視化とブログ公開**: Atlassian の「ブログいいね数で評価」文化を活用し、Confluence ページで Error Budget の状態を全社透明化した。 - **Not So Good Result も価値がある**: 「このサービスは移行予定なので信頼性投資しない」という応答がプロセスを通じて「承認」された事例。改善しない判断の透明化と説明責任確保。 - **SLO 達成率は回復した**: Jul-Sep の下降トレンド（~65%→67%）から、Error Budget 導入後の Oct 以降に 85-100% へ回復（p.36 グラフ）。 **新規ページ**: [[@2018__SREcon18Asia__How Atlassian Is Tackling Error Budgets, Agile Style]] / [[Gui Vieiro]] / [[Atlassian]] **更新ページ**: [[エラーバジェット]]（アジャイル導入・可視化・Not So Good Result の透明化 を横断的知見に追記） --- # 2026-06-29: SLOs and SLIs in the Real World: A Deep Dive (SREcon18 Americas) [[Elisa Binette]]・[[Matthew Flaming]]（[[New Relic]]）による SREcon18 Americas 発表（[[@2018__SREcon18Americas__SLOs and SLIs in the Real World - A Deep Dive]]）を wiki 化した。PDF 25 枚スライドを全ページ画像として確認（transcript なし、YouTube 動画あり）。 **核心**: - **ケイパビリティ駆動の 7 ステップレシピ**: (1)システム境界特定→(2)ケイパビリティ定義→(3)平易な英語定義→(4)技術的 SLI 定義→(5)ベースライン計測→(6)SLO 目標設定→(7)反復改善。SRE Workbook の「ユーザーに意味のある SLI」へ至る具体的なファネルとして機能する。 - **ハードシャード per-shard SLO の必然性**: 3 シャード中 1 シャード障害で水平スケールは SLO 66%（比例的）、ハードシャードは SLO 0%/100%/100%。全体集計では両者とも同じ数字になり、ハードシャードの実態を隠蔽する。論理インスタンスごとの独立 SLO が必須。 - **複合 SLO（Compound SLO）**: 複数 SLI を AND 結合（例: 99.95% × 99.9% → 99.9%）し 1 ケイパビリティ SLO に圧縮する手法。複数 SLI が増えるほど合成確率が下がるトレードオフが存在する。 - **インフラ SLO は上位サービスの SLO より高く設定**: ネットワーク層は 99.99% goal（上位アプリが 99.9% なら少なくとも 1 桁高い）。ハード依存を持つ基盤は上位サービスのバジェットを一方的に消費するため。 - **全体 dumb SLI**: 各層 SLI に加えて「サンプルワークフローが成功するか」という粗いエンドツーエンド SLI を設けることで、個別 SLI が全て正常でも全体が壊れている状況を検知する。 **新規ページ**: [[@2018__SREcon18Americas__SLOs and SLIs in the Real World - A Deep Dive]] / [[Matthew Flaming]] / [[Elisa Binette]] / [[New Relic]] **更新ページ**: [[サービスレベル目標]]（横断的知見 4 項目・未解決の問い 4 項目追加） --- # 2026-06-29: Error Budgets and Risks (SREcon15, 2015) [[Marc Alvidrez]]（Google）が SREcon15 で発表した [[@2015__SREcon15__Error Budgets and Risks]] を wiki 化した。PDF スライド（26 ページ）と MP3 音声（Whisper 文字起こし）から取り込み。 **核心**: - **エラーバジェットの起源はフレームワーク設計でなく「SLA を超えすぎた結果の気づき」**: AdSense が 2009 年に SLA を一貫して超えていたことで「機会を逃した」と感じ、1% クラスターというリスク境界化を試みた実体験から生まれた。 - **SLA はミニマムかつマクシマム**: SRE の目標は「必要な分だけの信頼性」。超過分はリリース速度・リソース削減・エンジニアのQoL改善に使える。 - **可用性計算式**: `availability = successful requests / total requests`、`error budget = availability − SLA target`。リクエスト成功率で定義するとエラーバジェットが計測しやすい（スライド p.6, p.12 に図示）。 - **1% クラスター**: 全体トラフィックの 1% を処理するクラスターを構築し、毎日新ビルドを自動プッシュ・設定検証に使用。障害時は failover してエラーバジェット内に収まることを事前計算した具体例。 - **エラーバジェットは権利でなく獲得するもの**: SLA を割った翌四半期は実績回復を優先し、存在しないバジェットを使おうとしない。 - **Q&A の深い示唆**: 自己申告 vs. 外部 SLA の問題（計測しやすいものから始め洗練させる）、1% の定義問題（ユーザー中心サービスでは分割単位を慎重に選ぶ）、フォールトインジェクションへの言及（初期のカオスエンジニアリング思想）。 **新規ページ**: [[Marc Alvidrez]] **更新ページ**: [[エラーバジェット]]（横断的知見 3 項目・未解決の問い 3 項目追記） --- # 2026-06-29: Service Levels and Error Budgets (SREcon16) [[Chris Jones]]・[[Niall Murphy]]（[[Google]]）による SREcon16 発表（[[@2016__SREcon16__Service Levels and Error Budgets]]）を wiki 化した。YouTube 動画（`iOoxtpVBQ4I`）から auto-caption を取得してトランスクリプト化し、約 23 分の口頭解説を収録。 **核心**: - **SRE の本来の役割の再定義**: 「SRE の仕事は可用性の最大化ではなく、所定の信頼性レベルの範囲内でプロダクトベロシティを最大化しコストを最小化すること」——著者自身が「異端的（heretical）」と呼びながら強調した。 - **エラーバジェットを制御ループとして使う**: SLO 達成中 → フィーチャーリリース最速化。バジェット枯渇 → 停止して安定性改善へ。バンバン制御を避け、バーン率連続監視による速度制御を志向（これが SRE Workbook の複数ウィンドウアラートの原型）。 - **「SRE は No を言わなくなる」**: エラーバジェットが共通言語になると SRE は「Yes if...」へ転換し、プロダクト開発チームとの健全な関係が生まれる。 - **測定の罠**: Google 自身がサーバー側でレイテンシを測ってきたが、クライアント側が正しい。集約インターバルが解釈を根本的に変える（1 分・30 秒・1 秒で全く異なる問題が見える）。 - **過達成しない**: SLO より良い状態が続くとユーザーがそれを期待し始め、将来の自由度を失う。Google に「意図的なダウンタイムを入れるシステム」が実在する。 **新規ページ**: [[@2016__SREcon16__Service Levels and Error Budgets]], [[Chris Jones]] **更新ページ**: [[Niall Murphy]]（SREcon16 発表セクション追記）, [[サービスレベル目標]]（測定点・集約インターバル・意図的ダウンタイム追記）, [[エラーバジェット]]（制御ループ・bangbang 制御・組織的帰結追記） --- # 2026-06-29: Effective Harnesses for Long-Running Agents (Anthropic 2025) + Harness Design (Anthropic 2026) [[Justin Young]] による 2025-11-26 の記事と [[Prithvi Rajasekaran]] による 2026-03-24 の記事を wiki 化した。 **核心（Article 1 — Justin Young）**: - 長時間エージェントはセッション境界でメモリをすべて失う：前シフトへの引き継ぎなし問題 - 2 大失敗：過剰実装による中途コンテキスト枯渇 / 早期終了宣言 - Initializer（init.sh + progress.txt + JSON フィーチャーリスト + git）+ Coding（固定シーケンス）の 2 役分離 - JSON フィーチャーリスト：Markdown より誤上書きしにくいため - Puppeteer MCP による E2E テストが品質に大きく貢献 **核心（Article 2 — Prithvi Rajasekaran）**: - 自己評価バイアス：自分の出力を採点させると品質が低くても高評価を返す - コンテキスト不安（Context Anxiety）：上限を感知して早期終了 - コンテキストリセット（圧縮でなく白紙再開）でコヒーレンス保持 - GAN 着想のジェネレータ・エバリュエータ分離（Playwright MCP で実ブラウザ操作） - Planner + Generator + Evaluator の 3 エージェント構成 - 荷重仮定（Load-Bearing Assumptions）：各ハーネスコンポーネントはモデル限界の仮定をエンコード。Opus 4.6 でスプリント分解を削除——DAW を 4 時間・$124.70 で構築 **新規ページ**: [[@2025__Anthropic Engineering Blog__Effective Harnesses for Long-Running Agents]], [[@2026__Anthropic Engineering Blog__Harness Design for Long-Running Application Development]], [[Justin Young]], [[マルチコンテキストウィンドウエージェント]] **更新ページ**: [[Prithvi Rajasekaran]], [[Harness Engineering]]（Anthropic 知見追加）, [[ループエンジニアリング]]（参照追加） --- # 2026-06-29: Harness Engineering (OpenAI 2026) [[OpenAI]] が 2026 年 2 月に公開したエンジニアリングブログ（[[OpenAI-Harness-Engineering]]）を wiki 化した。 **核心**: - **ハーネスエンジニアリングの定義**: [[Harness Engineering]] = AI エージェントを囲む「足場・制約・フィードバックループの完全な環境」を設計する工学的規律。プロンプト/コンテキストエンジニアリングとは異なる第三の設計層（スコープ: 数時間に及ぶ自律実行）。 - **OpenAI 実験の成果**: 3 名のエンジニア、2025 年 8 月〜5 ヶ月、手書き 0 行、100 万行本番コード、1,500 本超 PR、3.5 PR/人/日。 - **ハーネスの 5 要素**: (1) コンテキストファイル（AGENTS.md を 100 行インデックスに縮小）、(2) 機械的強制（Types→Config→Repo→Service→Runtime→UI の一方向依存バリデーション）、(3) フィードバックループ（CDP/LogQL/PromQL、起動閾値 800ms）、(4) ガベージコレクション（バックグラウンド Codex が技術負債スキャン→自動 PR）、(5) エージェント間レビュー。 - **設計哲学**: 「最良のハーネスコンポーネントは削除されるよう設計されている」— モデル向上とともに不要化する一時的足場。 - **後継: [[Symphony]]**: 2026-04-27 公開、Linear → Codex オーケストレーション。Elixir 製参照実装。採用チームで PR マージ 500% 増。 **新規ページ**: [[OpenAI-Harness-Engineering]], [[Symphony]], [[Harness Engineering]] **更新ページ**: [[OpenAI]]（Harness Engineering・Codex セクション追記） --- # 2026-06-29: Memory in the Age of AI Agents (arXiv 2025) [[Yuyang Hu]] ほか 47 名（NUS 等）による 107 ページのサーベイ（[[@2025__arXiv__Memory in the Age of AI Agents]]）を wiki 化した。 **核心**: - **形態-機能-動態の統一タクソノミ**: エージェントメモリを 3 軸で体系分類。形態はトークンレベル（1D/2D/3D）・パラメトリック・潜在メモリ。機能は事実（ユーザー/環境）・経験（事例/戦略/スキル）・作業メモリ。動態は形成・進化・検索の 3 段階ライフサイクル。 - **隣接概念の境界画定**: エージェントメモリは LLM メモリ・RAG・[[コンテキストエンジニアリング]]をほぼ包含するが完全な上位集合ではないと明示。コンテキストエンジニアリングが入力側設計ならエージェントメモリは自律的蓄積側。 - **7 つのフロンティア**: (1) 検索から生成へ (2) 自律的メモリ管理 (3) RL 統合 (4) マルチモーダル (5) マルチエージェント共有メモリ (6) ワールドモデルメモリ (7) 信頼性あるメモリ。 - **代表フレームワーク**: MemGPT（階層 S/LTM）、Mem0（グラフ+ベクトル）、MemOS（ツリー+memcube）、Zep（時間知識グラフ）等 24 以上を比較。 **新規ページ**: [[@2025__arXiv__Memory in the Age of AI Agents]], [[エージェントメモリ]], [[Yuyang Hu]], [[MemGPT]], [[Mem0]] **更新ページ**: [[コンテキストエンジニアリング]]（エージェントメモリとの射程比較を横断的知見に追記）, [[National University of Singapore]] --- # 2026-06-29: VictoriaMetrics vs Prometheus (Jorijn Blog) [[Jorijn Schrijvershof]]（オランダのDevOpsコンサルタント）による実務家比較記事（[[@2025__Jorijn-Blog__VictoriaMetrics vs Prometheus]]）を wiki 化した。 **核心**: - **新規スタックにはVictoriaMetricsをデフォルト推奨**: RAMが100万系列あたり約1GB（Prometheusの数GB対比）。Prezi事例でストレージ70%・メモリ60%・CPU30%削減・重いクエリが30秒→3–7秒。 - **グレースフルデグラデーション**: カーディナリティ爆発時にOOMクラッシュではなく「スローインサート」へ移行。Prometheusは段階的な劣化なくクラッシュ（英国法務省2024年4月に3時間21分監視喪失）。 - **HA構成の単純さ**: VictoriaMetricsは`-replicationFactor`単一フラグ+クエリ時重複排除。PrometheusはThanos/Mimirが必要。 - **MetricsQL**: PromQLと74%互換（PromLabs評価）のスーパーセット。Grafanaダッシュボードは変更なしで動作するが`rate()`/`increase()`に意図的な相違あり。複数バックエンド横断環境では負債化するリスク。 - **Prometheusが正当化される条件**: 既存安定スタック（移行不要）・CNCF統治要件・PromQL移植性必須。 - **重要な落とし穴**: VictoriaMetrics単一ノードのデフォルト保持期間30日。初日に`-retentionPeriod`明示必須。 **新規ページ**: [[@2025__Jorijn-Blog__VictoriaMetrics vs Prometheus]], [[MetricsQL]], [[Jorijn Schrijvershof]], [[PromLabs]] **更新ページ**: [[VictoriaMetrics]]（運用特性・HA・カーディナリティ詳細追記）, [[Prometheus]]（高カーディナリティ弱点・VictoriaMetrics比較追記） --- # 2026-06-29: SRE NEXT 2022 — How We Foster "Reliability" in Diversity [[Narimichi Takamura]]（[[Topotal]] CEO / SRE）が 2022-05-14 に SRE NEXT 2022 で発表した 50 スライド（[[@2022__SRE NEXT__How We Foster Reliability in Diversity]]）を wiki 化した。 **核心**: - **信頼性の多様性が SRE を複雑にする**: 組織ごとの事業戦略・プロダクトライフサイクル・システム特性によって「適切な信頼性」は異なる。SRE を一様に実践するだけではうまくいかない - **5ステップフレームワーク**: 状況把握→小さく始める→チーム支援→スケール→データドリブン化。いきなりプラクティス実装ではなく「状況把握」から始め、組織が自律的に SRE を実践できる状態を目指す - **氷山モデルとの対応**: Level 1（製品・行動）= Postmortem/Metrics/Logs。Level 2（ポリシー・プロセス）= SLI/SLO/IaC。Level 3（信念・価値観）= Blameless/Data Driven。日常業務は変わっても自律的 SRE 文化（Level 3）に到達できないケースが多い - **MVV が Level 3 へのアプローチ**: SRE の Mission/Vision/Value を策定し、会社 MVV と同心円状に整合させる。CTO・EM を巻き込み、Google Docs で非同期レビューを行う - **組織コンテキストの3層モデル**: 企業方針（ミッション・ビジョン・経営戦略）/ サービス（内容・構造・課題）/ 組織（構造・信頼性への意識）を階層的に把握する - **ダイナミックケイパビリティ**: Sensing（情報収集）・Seizing（小さく始める）・Transforming（チーム支援・スケール・データドリブン）と5ステップが対応。変化への耐性は組織の多様性でさらに強化 **新規ページ**: [[@2022__SRE NEXT__How We Foster Reliability in Diversity]], [[ダイナミックケイパビリティ]], [[組織の信頼性マインドセット]] **更新ページ**: [[SRE組織変革]]（SREcon23 EMEA との横断的知見追記）, [[Narimichi Takamura]], [[Topotal]] --- # 2026-06-29: Road to SRE NEXT 2026 @神戸 — 小さくはじめるSLI/SLO ～育てながら組織に定着させる実践知～ [[Narimichi Takamura]]（[[Topotal]]）が 2026-06-15 に Road to SRE NEXT 2026 @神戸で発表した 48 スライド（[[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]]）を wiki 化した。 **核心**: - **3 つの難点の構造**: 定義（CUJ〜SLO 合意形成・追加計装に時間）、運用（メンテ除外・新機能考慮・見直し不足）、定着（SRE チームしか興味なし）。理想を一気に追求すると形骸化する - **SRE 4 ステップを SLI/SLO に転用**: 小さく始める → チームを支援 → スケール → データドリブン思考の具体化。短期間で効果が出る課題に絞り、小さな成功体験を積む - **SLO 違反ポリシー 5 段階**: Level1「なにもしない」〜Level5「開発スケジュールの意思決定に SLO を組み込む」 - **成熟度モデル 3 軸 × 5 段階**: 定義・運用・定着それぞれを独立評価。「信頼性が組織の共通言語になる」は定着 Lv5 - **wiki 内接続**: [[サービスレベル目標]] の「組織導入の段階的アプローチ」横断的知見と[[エラーバジェット]] の「ポリシー段階的拡大」知見を更新 **新規ページ**: [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]], [[SLI-SLO段階的導入]] **更新ページ**: [[サービスレベル目標]], [[エラーバジェット]], [[Narimichi Takamura]], [[Topotal]] --- # 2026-06-29: SRE NEXT 2025 — Rethinking Incident Response: Context-Aware AI in Practice [[Ryota Yoshikawa]]（[[Topotal]] CTO）が 2025-08-19 SRE NEXT 2025 で発表したスライド（[[@2025__SRE NEXT 2025__Rethinking Incident Response - Context-Aware AI in Practice]]）を wiki 化した。 **核心**: - **新概念 [[インシデントレスポンスAIレベル]]**: SAE J3016™ 自動運転 L0〜L5 に対応する IR0〜IR5 フレームワーク。2025 年時点で IR0〜IR2 は実現済み、MCP + Coding Agent により IR2〜IR3 が現実的になった。IR3 到達には「AI に任せられる安全な操作の定義」が必要。 - **IR2+ デモ**: [[Waroom]] MCP + Sentry MCP + GitHub MCP を連携し、Claude が Sentry エラー検知 → インシデント起票 → GitHub PR 生成 → クローズ・ポストモーテム自動生成まで自動化するフローを実証。人間の介在点は PR レビューと本番デプロイのみ。 - **AIOps 精度の現状**: OpenRCA(ICLR 2025): Claude 3.5 Sonnet + Multi-Agent でも正答率 11%。AIOpsLab(MLSys 2025): 検知 86%・局所化 71%・**RCA 14%**・緩和 43%。サマライズ・レポート・簡単なコードは「大分 Yes」だが、オペレーション領域の RCA・緩和は依然として研究段階。 - **精度向上の 3 施策**: (1) 社内 IR 情報(ポストモーテム・Slack・Jira)を構造化して LLM に学習させる、(2) 公開データ(OpenRCA・The VOID)を取り込む、(3) サービスコンテキスト(サービスマップ・依存関係・Runbook)を LLM に接続する。 **今回の更新範囲**: source ページ新規作成、[[インシデントレスポンスAIレベル]] 新規作成、[[インシデント管理]]・[[AIOps]] 横断的知見更新、[[Waroom]]・[[Ryota Yoshikawa]] エンティティ更新。 # 2026-06-29: SRE NEXT 2024 — 組織的なインシデント対応を目指して [[Narimichi Takamura]]（[[Topotal]]）が 2024-08-03 SRE NEXT 2024 で発表したスライド（[[@2024__SRE NEXT 2024__組織的なインシデント対応を目指して]]）を wiki 化した。 **核心**: - **3つの難点の構造化**: インシデント対応改善の難しさを「パターン膨大→アドホック化」「ベストプラクティスの定着失敗」「期待値の企業差」の3軸に整理 - **新概念 [[インシデント対応成熟度モデル]]**: Google SRE の信頼性マインドセット（Absent/Reactive/Proactive/Strategic）をベースに、Pre-Incident・Response・Post-Incident の3フェーズ×9プロセスを4段階で評価するマトリクスを提案 - **IC 導入の前提条件問題**: コマンダーロールは「様々な前提が整ってはじめて効果を発揮し、企業によっては単なるオーバーヘッドになりうる」と明言。[[インシデント管理]] と [[Incident Commander]] の横断的知見として追記 - **wiki 内接続**: [[インシデント管理]] の「検知だけ整備しても対応フロー未定義では失敗」という新しい失敗モードを追記。[[TTXメトリクス]] は Reactive→Proactive 以降で初めて活用可能という仮説を [[インシデント対応成熟度モデル]] の未解決の問いに記録 **新規ページ**: [[インシデント対応成熟度モデル]], [[@2024__SRE NEXT 2024__組織的なインシデント対応を目指して]] **更新ページ**: [[インシデント管理]], [[Incident Commander]], [[Narimichi Takamura]], [[Topotal]], [[SRE NEXT]] --- # 2026-06-29: SAIL Blog — CoT Monitoring: Where Does a Hot Safety Problem Come From? [[Peter Hase]]・[[Christopher Potts]]（[[Stanford University]]）が 2026-06-18 に SAIL Blog で公開した記事([[@2026__SAILBlog__CoT-Monitoring-Where-Does-a-Hot-Safety-Problem-Come-From]])を wiki 化した。 **核心**: - **2 系譜の収束**: CoT モニタリング([[CoTモニタリング]])の知的起源は (1) Hendrycks 2021「Unsolved Problems in ML Safety」によるデプロイ後監視フレームワーク と (2) Ling 2017 / Camburu 2018 による「CoT を説明可能性面」として扱う NLP 研究——この 2 系譜が収束した - **18 ヶ月の空白**: Naihin et al. 2023（AutoGPT の推論を LLM が自動監視した最初の実装）から Baker et al. 2025（41 著者の正式論文）まで概念が停滞。空白の解釈: 「CoT は安全上クリティカルでない」という通念 → OpenAI o1（2024-09）が推論モデルを実用化して通念崩壊 - **4 つの未解決ストランド**: CoT 忠実性(faithfulness)・LLM 内省・自己検証・活性化モニタリング——これらを統合しないと CoT モニタリングはシャドウを見る手法にとどまる - **wiki 内接続**: [[エージェント運用安全性]]の「書き込み境界での検証」（外付けゲート）に対し、CoT モニタリングは「推論段階の内在的監視」として補完的。[[AI検証可能性]] の推論可読性アプローチと正確に対応する **新規ページ**: [[@2026__SAILBlog__CoT-Monitoring-Where-Does-a-Hot-Safety-Problem-Come-From]], [[Peter Hase]], [[Christopher Potts]], [[CoTモニタリング]] **更新ページ**: [[Chain-of-Thought Prompting]], [[Dan Hendrycks]] --- # 2026-06-29: USENIX ATC 2023 — On-demand Container Loading in AWS Lambda [[Marc Brooker]] ほか Amazon Web Services が USENIX ATC 2023 Best Paper として発表した論文([[@2023__ATC__On-demand Container Loading in AWS Lambda]])を wiki 化した。 **核心**: - **ブロックレベルスパースロード**: OCI コンテナイメージを 512KiB チャンクにフラット化し、実際に参照されたチャンクのみを FUSE ベースのブロックデバイス経由でオンデマンド取得。Harter et al. の「起動時に必要なデータは 6.4%」という観測を活用 - **収束暗号化による重複排除**: SHA256(プレーンテキスト) → AES-CTR キー。同一コンテンツ→同一暗号文→キー共有なしで安全な重複排除。新規アップロードの 80% がゼロユニークチャンク(完全再アップ)・残り 20% でも中央値 2.5% のユニークチャンク。塩値で爆発半径を動的制御 - **3 階層キャッシュ**: L1(ワーカーローカル) 67% → L2(AZ レベル, LRU-k) 32% → L3(S3) 0.06%。L2 ヒット率 中央値 99.9%・10 百分位 99.4% - **4-of-5 イレイジャーコーディング**: 25% ストレージオーバーヘッドでテールレイテンシを大幅削減。再試行不要の「定常作業」原則でメタ安定障害を回避 - **メタ安定障害対策**: ヒット率 99.8% のキャッシュが空になると S3 負荷が 500x に増大するリスクに対し、並行処理数制限と空キャッシュからの積極コールドスタートテストを導入 **新規ページ**: [[@2023__ATC__On-demand Container Loading in AWS Lambda]], [[Marc Brooker]], [[AWS Lambda]], [[Firecracker]], [[コンテナ起動高速化]], [[収束暗号化]], [[イレイジャーコーディング]], [[メタ安定障害]] --- # 2026-06-29: SOSP 2023 — Project Silica: Towards Sustainable Cloud Archival Storage in Glass [[Antony Rowstron]] ほか [[Microsoft]] の 58 名が SOSP 2023 に発表した論文([[@2023__SOSP__Project Silica - Towards Sustainable Cloud Archival Storage in Glass]])を wiki 化した。 **核心**: - **ガラス媒体 WORM**: フェムト秒レーザーで溶融石英内部に voxel を書き込み偏光顕微鏡 + ML デコーダ(U-Net)で読み出す。1000 年超耐久・ビット腐敗なし・化学的不活性。スクラビング・リフレッシュ・ガベージコレクションをアーキテクチャから排除 - **クラウドアーカイバルワークロード実態**: 書き込み超優位(47:1 MB比)かつ I/O の 58.7% が 4 MiB 以下小規模リード。テープ設計(大容量逐次アクセス前提)がクラウドに不適合な根拠を実測で実証 - **フルdisaggregation**: 書き込みドライブ・読み出しドライブ・シャトルロボティクスを独立スケール。保管ラックは電力・冷却不要 - **論理パーティション分割シャトル管理**: パネルを n 等分しシャトルが自身のパーティション内のみ移動。SP(Shortest Paths)対比で輻輳を 10% 以内に維持、20〜90% 省電力。ワークスティーリングで偏り分布に対応 - **3 層 Network Coding**: Within-track(セクター障害確率 10^-3 で復号失敗確率 < 10^-24) / Large-group / Cross-platter。WORM 媒体の不変性で超大グループサイズが可能 **新規ページ**: [[@2023__SOSP__Project Silica - Towards Sustainable Cloud Archival Storage in Glass]], [[Antony Rowstron]], [[Project Silica]], [[アーカイバルストレージ]], [[ガラスストレージ]], [[ネットワーク符号化]] --- # 2026-06-29: USENIX ATC 2014 — In Search of an Understandable Consensus Algorithm (Raft) [[Diego Ongaro]]・[[John Ousterhout]]（Stanford University）が USENIX ATC 2014 に発表した Raft 合意アルゴリズム論文（[[@2014__ATC__In Search of an Understandable Consensus Algorithm]]、Best Paper Award）を wiki 化した。 **核心**: - **理解しやすさ第一設計**: Paxos の難解さの根源（シングルデクリー分解）を特定し、「問題分解（リーダー選出/ログ複製/安全性）」と「状態空間削減（ランダム化タイムアウト・ログの穴なし・一方向ログフロー）」の 2 原則のみで一貫して設計 - **強いリーダーモデル**: ログエントリは常にリーダーからフォロワーへの一方向。投票制限（up-to-date ログを持つ候補者のみ当選可）で Leader Completeness Property を保証 - **ランダム化タイムアウト**: 150–300 ms の固定区間からランダム選択。ランダム性わずか 5 ms（150–155 ms）で中央値 287 ms の選出時間。12–24 ms タイムアウトでは中央値 35 ms - **ジョイントコンセンサス**: Cold,new を 2 フェーズでコミットすることでメンバーシップ変更中も通常処理を継続。Aurora のクォーラムセット + エポックと設計哲学の好対比 - **ユーザースタディ実証**: 43 名中 33 名が Paxos より Raft クイズ高得点（平均 25.7 対 20.8/60 点） **新規ページ**: [[@2014__ATC__In Search of an Understandable Consensus Algorithm]], [[Diego Ongaro]], [[John Ousterhout]], [[分散コンセンサス]], [[複製ステートマシン]], [[リーダー選出]] **更新ページ**: [[分散コンセンサス回避]] --- # 2026-06-28: SIGMOD 2020 — CockroachDB: The Resilient Geo-Distributed SQL Database [[Rebecca Taft]] ほか [[Cockroach Labs]] が SIGMOD 2020 に発表した論文([[@2020__SIGMOD__CockroachDB - The Resilient Geo-Distributed SQL Database]])を wiki 化した。 **核心**: - **MVCC + Read Refresh**: Spanner の commit wait を不要にする楽観的アプローチ。タイムスタンプを進める際に過去読み取り集合を再検証し成功すれば続行・失敗はリトライ。低コンテンション YCSB で Spanner を大幅上回る - **Parallel Commits**: staging ステータスでコミットと write intent レプリケーションを並列化し 2PC の追加ラウンドを回避。セカンダリインデックス付きで 72% スループット向上・47% レイテンシ削減。TLA+ 検証済み - **HLC + 単一キー線形化可能性のみ**: Spanner の外部一貫性(厳密直列化可能性)とは異なる保証レベル。クロックスキューが max_offset を超えると陳腐化読み取りが起こりうる。直列化可能分離はリース保護機構で常に維持 - **3 種データ配置ポリシー**: Geo-Partitioned Replicas / Geo-Partitioned Leaseholders / Duplicated Indexes でレイテンシ・可用性・規制遵守をトレードオフ制御 - **TPC-C 100,000 ウェアハウス 98.8% 効率**: Aurora の 7.3%(10,000 ウェアハウス)と対照的。汎用クラウドサーバーで 50 億行・8 TB **新規ページ**: [[@2020__SIGMOD__CockroachDB - The Resilient Geo-Distributed SQL Database]], [[CockroachDB]], [[Cockroach Labs]], [[Rebecca Taft]], [[地理分散SQLデータベース]], [[ハイブリッド論理クロック]] **更新ページ**: [[Spanner]], [[分散トランザクション]], [[外部一貫性]] --- # 2026-06-29: Data Center Networking 基盤論文 5 本一括取り込み 2008〜2010 年のデータセンターネットワーキング基盤論文 5 本を一括 wiki 化した。いずれも現代のクラウド・AI データセンター設計の直接の源流となる研究群である。 ## トポロジとアドレッシング - **Fat-Tree** ([[@2008__SIGCOMM__A Scalable Commodity Data Center Network Architecture]]): [[Mohammad Al-Fares]] ほか（UCSD）。k-ary Fat-Tree トポロジで安価な商用スイッチのみから full bisection bandwidth を実現。27,648 ホスト・従来比 77% コスト削減。二段経路探索で転送表エントリを k 以内に抑制。→ 概念: [[データセンターネットワークトポロジ]], [[ECMP]] - **VL2** ([[@2009__SIGCOMM__VL2 - A Scalable and Flexible Data Center Network]]): [[Albert Greenberg]] ほか（Microsoft Research）。Clos トポロジと [[Valiant Load Balancing]] で uniform high capacity。トラフィック高ボラティリティが VLB ランダム化を正当化（適応型 TE との差わずか 5%）。 - **PortLand** ([[@2009__SIGCOMM__PortLand - A Scalable Fault-Tolerant Layer 2 Data Center Network Fabric]]): [[Radhika Niranjan Mysore]] ほか（UCSD）。PMAC アドレスとファブリックマネージャで L2 セマンティクスを維持しつつスケーラブルなファブリック。65ms 障害収束。→ 概念: [[データセンターL2ファブリック]] ## トラフィック管理と輻輳制御 - **Hedera** ([[@2010__NSDI__Hedera - Dynamic Flow Scheduling for Data Center Networks]]): [[Mohammad Al-Fares]] ほか。[[ECMP]] のハッシュ衝突でエレファントフロー帯域最大 60.8% 損失。集中型スケジューラ＋Simulated Annealing で最適比 96% の二分帯域幅。→ 概念: [[フロースケジューリング]] - **DCTCP** ([[@2010__SIGCOMM__Data Center TCP (DCTCP)]]): [[Mohammad Alizadeh]] ほか。ECN マーキング割合から輻輳度を段階的に推定。TCP コード変更 30 行で [[Incast]]・キュー蓄積・バッファ圧迫を同時解決。→ 概念: [[データセンター輻輳制御]] ## 横断的観察 - 5 本すべてが [[Amin Vahdat]]（UCSD→Google）のグループまたは共同研究から出ており、2008〜2010 年のデータセンターネットワーク設計の急速な進化を反映 - Fat-Tree → VL2 → PortLand は Clos トポロジの異なる側面（コスト・仮想化・L2 互換性）を攻め、Hedera と DCTCP はトポロジ上のトラフィック管理を攻めた - 現代 AI データセンターの [[マルチプレーンClosトポロジ]] は Fat-Tree/VL2 の直系であり、DCTCP は DCQCN/RoCEv2 輻輳制御の思想的源流 **新規ページ**: [[@2008__SIGCOMM__A Scalable Commodity Data Center Network Architecture]], [[@2009__SIGCOMM__VL2 - A Scalable and Flexible Data Center Network]], [[@2010__NSDI__Hedera - Dynamic Flow Scheduling for Data Center Networks]], [[@2009__SIGCOMM__PortLand - A Scalable Fault-Tolerant Layer 2 Data Center Network Fabric]], [[@2010__SIGCOMM__Data Center TCP (DCTCP)]], [[Mohammad Al-Fares]], [[Amin Vahdat]], [[Albert Greenberg]], [[Mohammad Alizadeh]], [[Radhika Niranjan Mysore]], [[Barath Raghavan]], [[Sivasankar Radhakrishnan]], [[VL2]], [[データセンターネットワークトポロジ]], [[ECMP]], [[Valiant Load Balancing]], [[フロースケジューリング]], [[データセンターL2ファブリック]], [[Incast]] **更新ページ**: [[James Hamilton]], [[データセンター輻輳制御]], [[負荷分散]], [[マルチプレーンClosトポロジ]], [[AIデータセンタートポロジ]], [[データセンターネットワーク信頼性]] --- # 2026-06-29: SIGMOD Companion '26 — Aurora PostgreSQL Limitless Database [[Dmitry Arkhangelskiy]] ほか([[Amazon Web Services]])が SIGMOD Companion '26 に発表した論文([[@2026__SIGMOD Companion__Aurora PostgreSQL Limitless Database - Building a Highly Scalable OLTP Database]])を再取り込みし、高品質な図表(アーキテクチャ図・2PC シーケンス図・性能グラフ)を追加した。 **核心**: - **アーキテクチャ**: ルータ群(クエリ計画・スナップショット設定・コミット駆動)とシャード群(実データ)をそれぞれ独立にスケール可能な 2 層設計。Aurora 分散ストレージ(3-AZ 耐久性)を共有基盤とする - **時刻ベース MVCC**: PostgreSQL の xid ベーススナップショットを Amazon Time Sync の `startTs`/`commitTs` に置換。HLC でクロックスキュー対処し余分な read wait を排除 - **Lead shard 2PC**: コーディネーター状態をステートレスなルータではなく standby 可能な lead shard に永続化。ルータ障害時も秒単位で回復 - **外部一貫性**: commit wait(`now().earliest > commitTs`)を storage 書き込みと並行実行し、実時間順序を保証しながらレイテンシ影響を最小化 - **スケーリング実績**: 8 ルータ・16 シャード・3072 ACU で 2,891,718 NOPM、NEWORD 平均レイテンシ 9.72ms(HammerDB) **図表追加**: `fig02-architecture.png`(アーキテクチャ), `fig03-2pc-protocol.png`(2PC シーケンス), `fig04-nopm-comparison.png`, `fig05-latency-comparison.png`, `fig06a/b-acu-r1/r2.png` **更新ページ**: [[@2026__SIGMOD Companion__Aurora PostgreSQL Limitless Database - Building a Highly Scalable OLTP Database]], [[分散トランザクション]], [[分散SQLデータベース]] --- # 2026-06-28: SIGMOD 2018 — Amazon Aurora: On Avoiding Distributed Consensus [[Alexandre Verbitski]] ほか([[Amazon Web Services]])が SIGMOD 2018 Industry Track に発表した論文([[@2018__SIGMOD__Amazon Aurora - On Avoiding Distributed Consensus for I Os, Commits, and Membership Changes]])を wiki 化した。Aurora 2017 論文の続編。 **核心**: - **SCL/PGCL/VCL/VDL 階層**: 各ストレージノードが局所計算する一貫性ポイントの 4 層。2PC/Paxos なしに書き込み耐久性・コミット応答・クラッシュリカバリを実現。「LSN は常に前進するのみ」不変条件がコンセンサス不要の基盤 - **クォーラム読み込みを回避**: VCL 管理により最新耐久バージョンの所在を把握し、単一セグメントへ直接読み込み。Vr=3 の I/O 増幅なし。遅延時のバックアップ読み込みでテールレイテンシ制御 - **物理レプリケーション**: 読み込みレプリカは同一ストレージボリューム共有。キャッシュ内ブロックのみ更新。MTR 単位の原子的適用で構造一貫性（B-Tree 中途状態なし）を保証。VDL アンカーで MVCC スナップショット隔離 - **クォーラムセット + エポック**: F→G 置き換えを 2 ステップで。ABCDEF と ABCDEG の両クォーラムを中間状態で同時有効化し、ABCD への書き込みで両方満たす。I/O ストールなし・可逆・1 エポック書き込みで完了 - **フル/テールセグメント非対称**: フルセグメント（redo+データ）3 本 + テールセグメント（redo のみ）3 本。データブロックコスト 6× → 約 3× に削減 **新規ページ**: [[@2018__SIGMOD__Amazon Aurora - On Avoiding Distributed Consensus for I Os, Commits, and Membership Changes]], [[分散コンセンサス回避]] **更新ページ**: [[クォーラムベースレプリケーション]], [[クラッシュリカバリ]], [[Write-Ahead Logging (WAL)]], [[Alexandre Verbitski]], [[Amazon Aurora (Database)]] --- # 2026-06-28: VLDB 2013 — F1: A Distributed SQL Database That Scales [[Jeff Shute]] ほか [[Google]] の F1 論文([[@2013__VLDB__F1 - A Distributed SQL Database That Scales]])を wiki 化した。 **核心**: - **設計思想**: Spanner([[@2013__TOCS__Spanner - Google's Globally Distributed Database]])の外部一貫性・グローバル分散基盤の上に SQL レイヤーを構築。スケーラビリティ・可用性・強一貫性・SQL の 4 要件を同時充足できることを 100 TB・5 ナイン本番で証明 - **階層スキーマ**: Customer → Campaign → AdGroup の親子テーブルを同一 Spanner ディレクトリに物理インタリーブ。単一ディレクトリ内トランザクションは 2PC を回避し、コミットレイテンシを半減 - **3種トランザクション**: スナップショット(SQL クエリデフォルト)・悲観的(高競合)・楽観的(ORM デフォルト)を ACID 保証下で混在。楽観的は hidden lock column で行レベル競合検出 - **非ブロッキングスキーマ変更**: 最大 2 バージョン同時有効(lease 付き)、互換フェーズ分割(delete-only → write-only → backfill → read-write)でゼロダウンタイム - **分散 SQL**: ハッシュ分散のみ(レンジ統計が使えないため)。Lookup Join で 50MB/100k キーバッチ→一括取得。Cluster Join で階層テーブルを 1 Spanner リクエストで merge-join - **性能**: 読み取り 5-10 ms、コミット 50-150 ms(データセンター間ネットワーク律速)。体感 200 ms は MySQL と同等。CPU コストは MySQL の約 10 倍(圧縮・解凍・ネットワーク処理) **新規ページ**: [[@2013__VLDB__F1 - A Distributed SQL Database That Scales]], [[Jeff Shute]], [[分散SQLデータベース]] **更新ページ**: [[分散トランザクション]], [[Google]] --- # 2026-06-28: SIGMOD 2024 — Amazon MemoryDB: A Fast and Durable Memory-First Cloud Database [[Yacine Taleb]] ほか([[Amazon Web Services]])が SIGMOD-Companion 2024 に発表した論文([[@2024__SIGMOD__Amazon MemoryDB - A Fast and Durable Memory-First Cloud Database]])を wiki 化した。 **核心**: - **設計思想**: 耐久性を内部マルチ AZ トランザクションログへ分離し、Redis インメモリ実行エンジンと完全 API 互換性を保つ。Aurora の「ログがデータベース」設計の Redis インメモリ版 - **書き込み後ろロギング**: Redis の複製モデル(操作終了後に複製情報生成)に合わせて WAL でなく Write-behind Logging を採用。SPOP 等の非決定的コマンドを効果(削除コマンド)として複製できる - **オフボックススナップショット**: 顧客クラスタと分離されたエフェメラルクラスタでスナップショット作成。Redis BGSave(fork + COW、メモリ最大 2 倍・スワップ 8% 超で事実上の可用性停止)の問題を解決 - **ログベースリーダー選出**: 条件付き追記 API を活用し、fully-caught-up レプリカのみがリーダーに。リース方式でリーダー単一性を保証。クォーラム不要 - **性能**: 読み取りはマイクロ秒(大型インスタンスで OSS Redis 超え 500K vs 330K Op/s)。書き込みは全マルチ AZ コミットのため高め(P50 〜3 ms、P99 〜6 ms) **新規ページ**: [[@2024__SIGMOD__Amazon MemoryDB - A Fast and Durable Memory-First Cloud Database]], [[Amazon MemoryDB]], [[Yacine Taleb]], [[インメモリデータベース]], [[ストレージ計算分離]] **更新ページ**: [[Amazon Web Services]] --- # 2026-06-28: Spanner (OSDI 2012 / TOCS 2013) — 外部一貫性のあるグローバル分散データベース [[James C. Corbett]] ほか [[Google]] の Spanner 論文([[@2013__TOCS__Spanner - Google's Globally Distributed Database]])を wiki 化した。 **核心**: - **[[TrueTime]]**: GPS と原子時計で時刻を不確実性区間 `[earliest, latest]` として返す API。ε ≈ 4ms。 - **[[外部一貫性]]**: Commit wait — `TT.after(s)` が真になるまでコミット公開を遅らせることで、`s < tabs(e^commit)` を保証。T1 コミット後に T2 が開始するなら必ず `s1 < s2`。世界初のグローバルスケール実現。 - **[[分散トランザクション]]**: 2PC on Paxos。スナップショットトランザクション(ロックフリー・どのレプリカでも実行可能)と RW トランザクション(悲観的ロック・リーダーのみ)の 2 種。 - **ディレクトリ**: 配置とデータ移動の最小単位。Movedir がバックグラウンドで Paxos グループ間を移動。地理的配置制御がユーザー単位で設定可能。 - **F1**: Google 広告バックエンド。MySQL シャーディングを Spanner に移行。5 レプリカ(米国東西)。シングルサイト commit 72ms / マルチサイト 103ms。 **新規ページ**: [[@2013__TOCS__Spanner - Google's Globally Distributed Database]] / [[James C. Corbett]] / [[外部一貫性]] / [[TrueTime]] / [[分散トランザクション]] **更新ページ**: [[Jeffrey Dean]] / [[Sanjay Ghemawat]] --- # 2026-06-28: Amazon Aurora (SIGMOD 2017) — クラウドネイティブ OLTP の設計原則 [[Amazon Aurora (Database)]] の設計論文([[@2017__SIGMOD__Amazon Aurora - Design Considerations for High Throughput Cloud-Native Relational Databases]])を wiki 化した。 **核心**: - **「ログがデータベース」**: Redo ログレコードのみをネットワーク越しに送り、データページはストレージ層が非同期生成。ミラード MySQL 比 7.7 倍少ない I/O/トランザクション・35 倍スループット - **6 ウェイ AZ+1 クォーラム**: V=6, Vw=4, Vr=3。3 AZ × 2 コピーで AZ 全体の喪失 + 独立ノード 1 台障害に耐える。10GB セグメント化で MTTR を 10 秒に圧縮 - **10 秒以内クラッシュリカバリ**: ストレージ層が継続的に Redo 適用。起動後は VDL 算定と truncation のみ。チェックポイント不要 - **非同期コンセンサス**: LSN 単調増加 + VDL/CPL 階層で 2PC を回避。コミットは非同期・ワーカーストールなし **新規ページ**: [[@2017__SIGMOD__Amazon Aurora - Design Considerations for High Throughput Cloud-Native Relational Databases]] / [[Amazon Aurora (Database)]] / [[クォーラムベースレプリケーション]] / [[コンピュートストレージ分離]] **更新ページ**: [[OLTPシステムアーキテクチャ]] / [[Write-Ahead Logging (WAL)]] / [[クラッシュリカバリ]] / [[分散ストレージ]] --- # 2026-06-28: 認知科学 2021 — 縮約，網羅，減算：科学者の仕事とは何か (岡ノ谷 一夫) [[岡ノ谷 一夫]]（[[東京大学]]）が 2021 年認知科学に発表した誌上討論コメンタリー([[@2021__認知科学__縮約，網羅，減算：科学者の仕事とは何か]])を wiki 化した。 **核心**: - **三項対立**: [[縮約]](次元圧縮・個体発生・人間的意味)、[[網羅]](仮説なし包括計測・GPT-3/Speechome)、[[減算]](外界の選択的遮断・Uexküll 環世界・系統発生的) - **科学者の仕事**: 人間が理解できる説明体系を構築すること。網羅的計測を機械学習に丸投げするだけでは科学者の仕事とは言えない - **特異点リスク**: 人工知能は網羅に基づくが人間への提示は縮約を経るため、想定外事象(特異点)を見落とす。津波原発事故・世界的疫病流行を例として挙げる - **結論**: 縮約と減算の二律背反は解消できない。認知科学は両者の並行処理にならざるを得ない **新規ページ**: [[@2021__認知科学__縮約，網羅，減算：科学者の仕事とは何か]], [[岡ノ谷 一夫]], [[東京大学]], [[縮約]], [[網羅]], [[減算]] --- # 2026-06-28: brendangregg.com — CPU Utilization is Wrong (Brendan Gregg, 2017) [[Brendan Gregg]](2017 年当時 Netflix)が 2017 年に発表したブログ記事([[@2017__brendangregg.com__CPU Utilization is Wrong]])を wiki 化した。 **核心**: - **%CPU の正体**: `top(1)` 等が示す %CPU は「非アイドル時間」であり、演算(命令実行)とメモリ待機(ストール)を区別しない。CPU-DRAM ギャップにより現代の「高 CPU 利用率」の多くは実際は DRAM 待機である - **正しい指標は IPC**: IPC(Instructions Per Cycle)= `instructions` / `cycles`。Linux `perf stat` で直接取得可能。IPC < 1.0 → メモリバウンド、IPC ≥ 1.0 → 命令バウンド - **%CPU が隠す他の要因**: サーマルスロットリング・可変クロック(Turboboost/SpeedStep)・スピンロックのビジーウェイト・分単位平均へのバースト埋没 - **IPC の命名衝突**: [[IPCメトリクス]](wiki 既存)は "Inter-Process Communication Metrics" であり、全く別概念。`Instructions Per Cycle` のページを別途新設した **新規ページ**: [[@2017__brendangregg.com__CPU Utilization is Wrong]], [[Brendan Gregg]], [[CPU利用率]], [[Instructions Per Cycle]] **更新ページ**: [[ハードウェアカウンタ]](IPC / %CPU 乖離の横断的知見追記) --- # 2026-06-28: SoCC 2010 — Characterizing Cloud Computing Hardware Reliability (Vishwanath & Nagappan) [[Kashi Venkatesh Vishwanath]] と [[Nachiappan Nagappan]]([[Microsoft Research]])が 2010 年 SoCC に発表した論文([[@2010__SoCC__Characterizing Cloud Computing Hardware Reliability]])を wiki 化した。 **核心**: - **コアメッセージ**: 100,000 台超のサーバーを 14 か月観測した初の大規模実証研究。AFR 約 8%、HDD が修理の 78%・初回障害の 70% - **予測因子の逆説**: 50 超のメトリクスを CHAID で探索した結果、最強の予測因子はデータセンター名とメーカー名であり、齢・ラック位置・ワークロードは有意でない - **連続障害のパターン**: インバース曲線に最良適合(R²=0.974)。20% が 1 日以内、50% が 2 週間以内に再発 - **障害経験済みサーバーの状態遷移**: 障害を経験したサーバーのみで RPM と HDD 数の線形関係(R²>0.9)が現れる。未経験サーバーにはない構造 **新規ページ**: [[@2010__SoCC__Characterizing Cloud Computing Hardware Reliability]], [[Kashi Venkatesh Vishwanath]], [[Nachiappan Nagappan]] **更新ページ**: [[データセンター信頼性]](横断的知見 3 件追記), [[障害予測]](横断的知見 1 件追記) --- # 2026-06-28: ACM Queue 2021 — The SPACE of Developer Productivity (Forsgren ら) [[Nicole Forsgren]](GitHub)、[[Margaret-Anne Storey]](ビクトリア大学)らが 2021 年 ACM Queue に発表した論文([[@2021__ACMQueue__The SPACE of Developer Productivity]])を wiki 化した。 **核心**: - **コアメッセージ**: 「開発者の生産性は多次元的であり単一メトリクスでは測定不可能。少なくとも 3 次元にわたって計測せよ」 - **SPACE 5 次元**: Satisfaction(満足度・幸福度)、Performance(アウトカムの質)、Activity(可算的出力)、Communication(協働・知識共有)、Efficiency(フロー・摩擦最小化) - **最重要警告**: A(アクティビティ)は「最も見えやすく最も危険な次元」——コミット数・PR 数は生産性の代理指標にならない - **DORA との補完**: DORA は「シグナル」(状態判定)、SPACE は「診断」(何を改善するか) - **有害なメトリクス**: コード行数・個人コミット数・利用率目標は明示的に避けるべき指標とされる - **満足度は先行指標**: S(Satisfaction)の低下は P(Performance)の低下に先行する。SRE 文脈では Forsgren 2026 が E(効率・フロー)を DORA 指標の因果的上流に位置づける **新規ページ**: [[@2021__ACMQueue__The SPACE of Developer Productivity]], [[開発者生産性]], [[Margaret-Anne Storey]] **更新ページ**: [[SPACE]](横断的知見・出典追記), [[Nicole Forsgren]](出典追記) --- # 2026-06-28: SREcon26 Americas — The Power of Stories (Lorin Hochstein / Airbnb) [[Lorin Hochstein]]（Airbnb、Staff Software Engineer, Reliability）が SREcon26 Americas のクロージングキーノートとして登壇。YouTube 動画([[@2026__SREcon26Americas__The Power of Stories]])を wiki 化した。 **核心**: - **ストーリーとは感覚知識の伝達手段**: 箇条書きやメトリクスと異なり、インシデントストーリーは記憶に定着し、他者のインシデントから代理学習(vicarious learning)を可能にする。Patricia Benner の看護師熟達研究(exemplars)が類比として引用された。 - **有用なストーリーの 2 条件(Gelman & Basbøll)**: anomalous(異常性: 既存メンタルモデルとの食い違い)と immutable(細部の保全: 単純化すると学習価値を失う)。Richard Cook の「信念と経験の乖離なしに学習は起きない」が anomalous を支持。 - **Therac-25 の教訓**: 「競合状態」への単純化は immutability 違反の典型例。Leveson & Turner の論文はオペレータ UX・ハードウェアインターロック削除など複合原因を記録。 - **インシデントストーリーの類型**: ホラーストーリー(最も学習価値大)・ミステリー(「何も変えていないのに」)・モラルストーリー(blame 構造は oversimplified であり危険)。 - **セカンドストーリー**: Cook・Woods・Miller のワークショップに由来。ファーストストーリー(単純・即時)をセカンドストーリー(文脈豊富・深掘り)へ発展させることがポストモーテムの目的。 - **逸脱の正常化(Vaughan)**: Challenger の社会学的分析から。SRE のアラート閾値緩和が同一プロセスだと Hochstein は明示。→ 新規 concept [[逸脱の正常化]] 作成。 - **ポストモーテムの実践**: 唯一必須のセクションは **narrative description**。時系列で書き、エピソードに区切り、インシデント開始より前から書き始める。 - **Once Upon an Incident**: Airbnb が実施する四半期ごとのインシデントストーリーテリング専用セッション(Nick Lach が Twitter から持ち込み)。アクションアイテム不要。古いインシデントでも学習価値が持続。 **新規ページ**: [[@2026__SREcon26Americas__The Power of Stories]], [[Lorin Hochstein]], [[Airbnb]], [[逸脱の正常化]] **更新ページ**: [[インシデントストーリー]](横断的知見 3 項追加), [[インシデントレポート執筆]](Hochstein 知見追加) --- # 2026-06-28: O'Reilly Report — Incident Metrics in SRE: Critically Evaluating MTTR and Friends (Štěpán Davidovič / Google SRE) [[Štěpán Davidovič]]（Google SRE）が 2021 年に発表した O'Reilly レポートを wiki 化（[[@2021__OReilly__Incident Metrics in SRE]]）。36 ページ。Google Cloud 協賛配布版 PDF。 **核心**: - **問題設定**: MTTR をはじめとする MTTx メトリクスが、実際にインシデント改善評価や信頼性トレンド分析に使えるかをモンテカルロシミュレーション（10 万回）で検証 - **衝撃的な結果**: 各インシデントの継続時間を 10% 短縮してもMTTRが改善を示すのは 49%・50%・64% のシミュレーションのみ（会社A・B・C）。逆に何も変えていないのに 30 分以上の「改善」が生じる確率が 19%・23%・10% - **代替統計も解決しない**: 中央値・幾何平均・95 パーセンタイルも同様の問題を持つ。問題の本質は件数の少なさと分散の高さであり、データ品質の問題ではない - **Google 内部も例外でない**: 大規模データセット（数万件規模）でも年間 5.3% の改善を検出できる程度にとどまる - **代替手段**: 改善対象フェーズに絞った TTX メトリクス・ユーザースタディ・SLI/SLO（直接的な信頼性指標） - **TTXメトリクス概念との整合**: [[TTXメトリクス]] ページの Davidovič 2021 を正式ソースとして追加し、3 者（Davidovič / Takamura / Nash）の批判アプローチの横断的知見を追記した **新規ページ**: [[@2021__OReilly__Incident Metrics in SRE]]、[[Štěpán Davidovič]] **更新ページ**: [[TTXメトリクス]]（横断的知見・未解決の問い・出典追記） --- # 2026-06-28: SREcon26 Americas — Unlock High-Frequency Deployments without Blowing Up Prometheus (Ganesh Vernekar / Reddit) [[Ganesh Vernekar]]（[[Reddit]] / Prometheus TSDB メンテナー）による SREcon26 Americas（2026-03-26）の発表を wiki 化（[[@2026__SREcon26Americas__Unlock High-Frequency Deployments without Blowing Up Prometheus]]）。スライド PDF 35 ページ。YouTube 自動字幕 transcript 付き。 **核心**: - **問題の構造**: Kubernetes Deployment/StatefulSet のロールアウトはポッドラベルや IP が変わるため、古い時系列が「失活系列(stale series)」として Prometheus の HEAD(RAM)に蓄積する。通常 HEAD flush は 2 時間ごとなので、高頻度デプロイ環境ではその前に OOM クラッシュが起きる - **stale-series compaction**: 失活系列比率が設定閾値を超えると HEAD からディスクの Block N へ先回りフラッシュする機能。Prometheus v3.10.0 で実験的に導入 - **トレードオフ**: クエリ時に HEAD + Block N のマージが必要になり CPU 消費が増加。「保護」目的に限定し省メモリ目的には使わない - **閾値選択指針**: `prometheus_tsdb_head_stale_series{} / prometheus_tsdb_head_series{}` を計測し、ピーク < 0.3 なら不要・0.3–0.5 は様子見・> 0.5 で試行錯誤 - **Reddit 実績**: 比率 0.4–0.7 の本番環境で閾値 0.4 を設定して効果を確認。CPU 増加も許容範囲 - **既知バグ #18379 あり**: 本番導入は v3.12.0–v3.13.0 の修正後を推奨 **新規ページ**: [[@2026__SREcon26Americas__Unlock High-Frequency Deployments without Blowing Up Prometheus]]、[[Ganesh Vernekar]]、[[Reddit]]、[[Prometheusシリーズチャーン]]、[[Prometheus TSDB]] **更新ページ**: [[Prometheus]] --- # 2026-06-28: SpeakerDeck — Postmortem as a textbook (KATO Toshiya / LINE株式会社) [[KATO Toshiya]]（[[LINE株式会社]] Embedded SRE）が「みんなで学ぶポストモーテム Lunch LT」（Findy、2023-02-09）で発表したポストモーテム品質改善手法を wiki 化（[[@2023__SpeakerDeck__Postmortem as a textbook]]）。スライド 26 ページ。transcript なし。 **核心**: - **ゴール**: ポストモーテムを「当事者参加者だけでなく、未来の誰かが学べる教材」に昇格させる - **問題の構造**: 当事者のみが執筆・共有する既存プロセスには5つの省略メカニズムがある（ドメインエキスパートのみ参加・質問しにくい・当事者目的が再発防止・書き方指摘困難・口頭補足で終わり） - **解法**: SRE主導の30分執筆専用会議を全体共有前に挟む。5問題それぞれに解決策を1対1でマッピング - **会議フロー**: 黙読15分→SREが質問ピックアップ→提案確認→Kudo wall→会議後に編集 - **結果**: 品質向上 + 全体共有会議が爆速で終わるようになった 新規 entities: [[KATO Toshiya]], [[LINE株式会社]] 更新 concepts: [[ポストモーテム]](SRE主導執筆会議の横断的知見追記) --- # 2026-06-28: SREcon26 Americas — Reliability Equilibrium: The Hidden Playbook behind SRE Influence (Daria Barteneva / Microsoft Azure) [[Daria Barteneva]]（[[Microsoft Azure]] Observability Engineering, Principal SRE）が SREcon26 Americas（2026-03-26）で発表した「ゲーム理論で信頼性エンジニアリングを再解釈する」フレームワークを wiki 化（[[@2026__SREcon26Americas__Reliability Equilibrium - The Hidden Playbook behind SRE Influence]]）。スライド PDF 60 ページ。transcript なし。 **核心**: - **問題提起**: 8 年前（SREcon18 EMEA）と同じ問いが繰り返される——「全員が善意を持ち合理的に行動しているのになぜ？」→ SRE はシングルプレイヤー問題ではないから - **ゲーム理論適用**: ナッシュ均衡は「良い」でなく「安定」。SRE の障害の多くは調整の失敗。SRE の仕事はメカニズムデザイン - **5 類型の診断**: 囚人のジレンマ（デプロイ凍結）、Stag Hunt（協調投資失敗）、ベイジアンゲーム（不完全情報）、公共財ゲーム（ドキュメント過少投資）、進化的ゲーム（文化的固着） - **設計解**: シュタッケルベルク先手（SRE が SLO・エラーバジェット・ガードレールを先コミット）、Freeze/Freeze → (2,4,3) vs Ship/Ship → (5,4,5) - 「信頼性の問題は構造的であり、個人の問題ではない。ゲームは再設計できる」 **新規ページ**: [[@2026__SREcon26Americas__Reliability Equilibrium - The Hidden Playbook behind SRE Influence]]、[[Daria Barteneva]]、[[ゲーム理論とSRE]] **更新ページ**: [[Microsoft Azure]] --- # 2026-06-28: Loop Engineering Working Note (Addy Osmani / HuaShu) [[Addy Osmani]]（Google Chrome）が 2026 年 6 月に命名した**ループエンジニアリング**の体系的ノートを wiki 化（[[@2026__Working Note__Loop Engineering - The Anthropic Playbook for Designing Systems That Prompt Your Agents]]）。PDF 11 ページ。 **核心の 4 フレームワーク**: - **4 層スタック**: プロンプト/コンテキスト/ハーネス/ループ。ループ層のみが人間を内側ループから取り除く - **5 ムーブ**: discovery → handoff → verification → persistence → scheduling。各ムーブのスキップが Nodding/Amnesiac/Manual/Blind/Tangled の失敗パターンに対応 - **ジェネレータ/エバリュエータ分離**: [[Prithvi Rajasekaran]]（Anthropic）の実証知見——自己採点は構造的に甘い。疑念スタートの独立エバリュエータで対処 - **4 コスト強化サイクル**: 検証負債→理解腐食→認知降伏→トークン爆発。沈黙したまま相互強化 **実例**: [[Addy Osmani]] の朝次トリアージ（個人規模）、[[Stripe]] Minions（[[Steve Kaliski]] / 週 1,300+ PR——信頼性はモデルサイズではなく制約の品質から） # 2026-06-28: SREcon26 Americas — Beyond Loss and Accuracy: Closing the Observability Gaps in AI Training with TrainCheck (Yuxuan Jiang, Ryan Huang / University of Michigan) [[Yuxuan Jiang]]・[[Ryan Huang]]（[[University of Michigan]] / [[OrderLab]]）が SREcon26 Americas（2026-03-25）で発表した [[TrainCheck]] の SRE 向け実践講演を wiki 化（[[@2026__SREcon26Americas__Beyond Loss and Accuracy - Closing the Observability Gaps in AI Training with TrainCheck]]）。スライド PDF 32 ページ。transcript なし。 **核心**: - **問題定義**: AI 訓練は本番インフラになったが、監視は「活動(activity)」しか計測しない。損失・GPU 使用率・クラッシュログは「正当性(correctness)」を見ていない - **BLOOM-176B ケース**: 39,999 ステップ健全に見えた後スパイク出現、さかのぼり 5,000+ ステップ前のチェックポイントへロールバックが必要。根本原因は第 1 ステップから不変条件違反として検知可能だった - **凍結エンコーダケース**: PyTorch MPS の `Adam.addcmul_` が非連続テンソルで無音失敗。損失低下・勾配正常という嘘の安心感。第 1 ステップで `APIContainRelation` が `encoder.weight unchanged (delta=0.0)` と報告 - **検知結果**: 20 件の実世界サイレントエラー中 18 件を 1 イテレーション以内に検知。比較手法（損失監視・PyTea+NeuRI）は 3/20。偽陽性率 2% 未満（63 パイプライン） - **SRE 的位置付け**: SRE 規律（不変条件定義→継続監視→即時アラート）を訓練インフラに直接適用。`pip install traincheck`・W&B/MLflow 統合・PagerDuty/Slack アラート計画 **新規ページ**: [[@2026__SREcon26Americas__Beyond Loss and Accuracy - Closing the Observability Gaps in AI Training with TrainCheck]]、[[Ryan Huang]] **更新ページ**: [[Yuxuan Jiang]]、[[TrainCheck]]、[[DLトレーニングサイレントエラー]]（横断的知見 2 件追加）、[[訓練不変条件]]（横断的知見 3 件追加）、[[MLモデル監視]]（横断的知見 2 件追加） --- # 2026-06-28: SREcon26 Americas — Executing Chaos Engineering in Production at a Critical Financial Institution (Luiz Siqueira, Leonardo Marques / Bradesco) [[Luiz Siqueira]]（[[Bradesco]] SRE Manager）と [[Leonardo Marques]]（SRE Head）による SREcon26 Americas（2026-03-24, Seattle）発表を wiki 化（[[@2026__SREcon26Americas__Executing Chaos Engineering in Production at a Critical Financial Institution]]）。スライド PDF 17 ページ。transcript なし。 **核心**: - **段階的導入モデル**: 第1フェーズ（SRE 依存の手動実験）→ 第2フェーズ（自動化・EasyPerform）→ GameDay という3段階。各フェーズの移行トリガーは「SRE チームを拡大せずにスケールするには？」という問い - **発見された脆弱性**: Redis フェイルオーバー（フォールバック未実装→DB フォールバック実装）、Hikari Timeout 30s→1s（3万リクエスト滞留の解消）、Circuit Breaker（Resilience4j + 指数バックオフ未使用→実装）、JVM DNS キャッシュ TTL 未設定（`networkaddress.cache.ttl=30`） - **本番実施の5前提**: ステージング検証・60秒ロールバックランブック・フルオブザーバビリティスタック・低ボリュームウィンドウ・ブラストラジウス定義（1名前空間/1サービス/1依存） - **結果**: MTTD 73% 削減、MTTR 22% 改善、30 シナリオ、10 ブラインドスポット発見、9 アーキテクチャ改善、100% 監査可能 **新規ページ**: [[@2026__SREcon26Americas__Executing Chaos Engineering in Production at a Critical Financial Institution]]、[[カオスエンジニアリング]]、[[GameDay]]、[[Bradesco]]、[[Leonardo Marques]]、[[Luiz Siqueira]]、[[EasyPerform]] **更新ページ**: なし --- # 2026-06-28: SREcon26 Americas — AI Agents for Incident Investigation (Vladyslav Budichenko / Vocaly AI) [[Vladyslav Budichenko]]([[Vocaly AI]])が SREcon26 Americas で発表した「AIエージェントによるインシデント調査: The Good, The Bad, and The Ugly」(2026-03-24)を wiki 化（[[@2026__SREcon26Americas__AI Agents for Incident Investigation - The Good, The Bad, and The Ugly]]）。スライド PDF 17 ページ。transcript 未取得。 **今回の主要な追加:** - source ページ・entity 2 件(Vladyslav Budichenko・Vocaly AI)新規作成 - concept 4 件更新: [[LLMによる根本原因分析]](11.34% 実測精度)・[[インシデント調査戦略]](AIエージェントの統合フロー)・[[エージェント運用安全性]](プロンプトインジェクション・trust-for/verify)・[[エージェントシステム運用]](コンテキストギャップ・エージェント過負荷) **重要な数値・知見:** - 最高性能エージェント(Claude 3.5 Sonnet + 専用 RCA エージェント)の RCA 精度: **11.34%** (3社・335件・68GB+) - プロンプトインジェクション攻撃: **+540%増加**(2025年) - AI 関連侵害の **97%** は人間の監視欠如が原因 - 「信頼して使える場面」vs「必ず検証すべき場面」の trust-for/verify フレームワーク **Active Threads:** - 11.34% 精度の一次論文が不明。AIOpsLab ベンチマーク(MLSys 2025)の結果の可能性あり → 確認要 - ログ経由のプロンプトインジェクションに対する防御設計(入力サニタイズ・ツール権限分離)の実装パターン → [[エージェント運用安全性]] で未解決 - MCP を介したツール統合が「エージェント過負荷」をどう緩和するかの実測データが未存在 # 2026-06-28: SREcon26 Americas — So You Want a New Incident Commander (Vanessa Huerta Granda / Enova) [[Vanessa Huerta Granda]]（[[Enova]] Technology Manager for Resilience Engineering）による SREcon26 Americas 発表を wiki 化（[[@2026__SREcon26 Americas__So You Want a New Incident Commander]]）。USENIX スライド PDF（25 ページ）。transcript 未取得。 **核心**: - **IC の存在意義の再定義**: IC は「最強エンジニアに授けるバッジ」ではなく、圧力下の複雑システムで「技術専門家が効果的に仕事できる条件を整える」社会技術的リーダーシップスキル。Not The Boss（p.6）。 - **The Real Job の3軸**: People（重複作業回避・コミュニケーション・意思決定フロー）/ System（状況認識の共有）/ Business（組織にとって重要なことを把握）（p.7）。 - **3チーム類型**: Deliberate IC Team（意図的専任・Vanessa 推奨、デメリット:過負荷）/ IC per domain team（良い出発点、デメリット:一貫性）/ IC volunteer team（スキル普及、デメリット:ストレス）。 - **普遍的要件**（p.17 強調スライド）: 構造の選択より「IC の役割が優先事項・仕事の一部であること」を全 IC に明示することが重要。 - **3コアコンピテンシー**: コミュニケーション / 社会技術的リーダーシップ / 認知負荷管理（p.18–20）。社内シグナルと社外評価方法を具体的に定義（逆シャドーイング・テーブルトップ演習等）。 **新規ページ**: [[@2026__SREcon26 Americas__So You Want a New Incident Commander]]、[[Incident Commander]] **更新ページ**: [[Vanessa Huerta Granda]]（SREcon26 発表・IC プログラム実践知）、[[Enova]]（IC プログラムとの接続）、[[インシデント管理]]（IC 役割・3チーム類型の横断的知見） --- # 2026-06-28: SRE Kaigi 2025 — インシデントキーメトリクスによるインシデント対応の改善 (Narimichi Takamura / Topotal) [[Narimichi Takamura]]（[[Topotal]] CEO / SRE、@nari_ex）による SRE Kaigi 2025（2025-01-26）発表を wiki 化（[[@2025__SRE Kaigi 2025__インシデントキーメトリクスによるインシデント対応の改善]]）。SpeakerDeck スライド PDF（56 ページ）＋ YouTube 自動字幕トランスクリプト（4myF9kw-ZDA、ja）使用。 **核心**: - **MTTR の統計的限界を実証**: 有名インターネット企業 3 社のインシデントデータ（The VOID Report）を使ったモンテカルロシミュレーション 10 万回。各インシデントの修復時間を 10% 短縮しても MTTR が 10% 以上改善されるのは 49%・50%・64% のケースのみ。外れ値 1 件が平均を大きく動かすためである。 - **TTX メトリクスへの転換**: TTDetect・TTAcknowledge・TTEngage・TTInvestigate・TTIdentify・TTMitigated・TTFix・TTRecovery 等 11 種類を、インシデントマイルストーンのタイムライン上に定義。改善対象フェーズを特定してそのフェーズだけを計測・改善する。 - **実践的 TTX 定義の 3 条件**: 網羅性・細粒度・自動収集の現実性。Waroom は Slack イベント（チャンネル作成・Runbook フェーズ分け・AI 判断）をトリガーに自動収集。 - **復旧以外のメトリクス**: 顧客対応（Customer Reliability Metrics）・組織学習（Learning Metrics）・改善実施状況（Improvement Metrics）の 4 カテゴリ体系へ拡張。 **新規ページ**: [[@2025__SRE Kaigi 2025__インシデントキーメトリクスによるインシデント対応の改善]]、[[Narimichi Takamura]]、[[TTXメトリクス]] **更新ページ**: [[Topotal]]（CEO 追記）、[[Waroom]]（TTX 自動収集の実装詳細を追記）、[[インシデント管理]]（MTTR 批判・TTX 代替の横断的知見を追記） --- # 2026-06-28: SRE NEXT 2022 — 1年間のポストモーテム運用とそこから生まれたツール sre-advisor (藤原俊一郎 / 面白法人カヤック) [[藤原俊一郎]]（[[面白法人カヤック]]）による SRE NEXT 2022（2022-05-14）発表を wiki 化（[[@2022__SRENEXT2022__1年間のポストモーテム運用とそこから生まれたツール sre-advisor]]）。SpeakerDeck スライド PDF（32 ページ）＋ YouTube 自動字幕トランスクリプト（ja）使用。 **核心**: - **Embedded SRE でのポストモーテム横断統一運用**: 2020 年 10 月から全チーム横断で「月刊ポストモーテム」（Slack 月次投稿＋一言コメント）を運用。1年半の成果として(1) 原因追及の放置防止、(2) 社内横断の事例共有、(3) プロダクト消滅後の知識保持の 3 効果を確認。 - **設定不備の傾向発見**: 振り返ると発生要因にクラウドインフラ/ミドルウェアの設定不備が多い。具体例: ECS コンテナの ulimit デフォルト（nofile=1024）不足によるファイルディスクリプタ枯渇。 - **チェックシートはトイル**: 設定ベストプラクティスをチェックシートで確認する運用は SRE Book 5章のトイル定義に合致する。SRE ならエンジニアリングで解決すべき。 - **sre-advisor**: AWS SDK for Go v2 製の CLI ツール。AWS アカウントの既存リソース設定を自動取得・検査。ECS ulimit・ALB デフォルトアクション・Lambda alias 未指定・RDS デフォルトパラメータグループの 4 パターンを検出。結果は markdown 出力 + GitHub Actions + `gh issue create` で「指摘潰し祭り」を自動化。 - **循環ループ**: 「インシデント → ポストモーテム → sre-advisor → 事前検出 → インシデント予防」——ポストモーテムの知見をコード化する組織的ガードレール形成。 **新規ページ**: [[@2022__SRENEXT2022__1年間のポストモーテム運用とそこから生まれたツール sre-advisor]]、[[藤原俊一郎]] **更新ページ**: [[面白法人カヤック]]、[[ポストモーテム]]（知見コード化ループ・トイルとしてのチェックシート・プロダクト消滅後の知識保持を追記） --- # 2026-06-28: SREcon25 Americas — Learning from Incidents at Scale (Vanessa Huerta Granda / Enova) [[Vanessa Huerta Granda]]（[[Enova]]）による SREcon25 Americas 2025-03-26 講演を wiki 化（[[@2025__SREcon25 Americas__Learning from Incidents at Scale - Actually Doing Cross-Incident Analysis]]）。スライドPDF未取得（USENIX サインイン必須）、YouTube 自動字幕トランスクリプト（Q69WND8YHag）に基づく。 **核心**: - **クロスインシデント分析**（Cross-Incident Analysis）: 個別インシデント学習の次の段階。複数インシデントを横断してパターン・インサイトを発見し、組織的イニシアチブを特定する継続的プログラム。 - **スケールの3要素**: 専任チーム（集中型ローテーション）・定量＋定性混在アーティファクト・組織計画サイクル（月次・四半期・年次）との連動。 - **最重要変革**: 部門横断の関係者（エンジニアリング以外にオペレーション・マーケティング・法務・コンプライアンス）をインシデントレビューに招待する。 - **アクションアイテムと推奨事項の分離**: 単一インシデント後に優先できる修正（AI）と、クロスインシデント分析後に見えるイニシアチブ（推奨事項）を区別する。アクションアイテムファクトリー anti-pattern を回避。 - **コンテキストが全て**: MTTR 等の指標は単体では無意味。「野菜とミートソース」アプローチ——数値＋ナラティブ——で意思決定に使えるものにする。 **新規ページ**: [[@2025__SREcon25 Americas__Learning from Incidents at Scale - Actually Doing Cross-Incident Analysis]]、[[クロスインシデント分析]]、[[Vanessa Huerta Granda]]、[[Enova]] **更新ページ**: [[ポストモーテム]]、[[Jeli]] --- # 2026-06-28: SREcon26 Americas — The Case of the Misnamed Cities (Ruben Barroso / Google) [[Ruben Barroso]]（[[Google]] スタッフ SRE）による SREcon26 Americas（2026-03-25）発表を wiki 化（[[@2026__SREcon26Americas__The Case of the Misnamed Cities - CAST Analysis of a Google Maps Incident]]）。113 ページ PDF（アニメーション重複多数）全確認。transcript なし。USENIX ページは curl(ブラウザ UA)で取得しメタデータ確定。 **核心**: - **インシデント**: Google Maps で都市名に「(balance)」が付加される。US Census データセット輸入時の評価ツール不備が直接原因。6 州で被害、Reddit で報告。 - **Chronology ≠ Causality**: RCA で選ばれるイベントは「馴染み深い・説明が単純・対処可能・politically acceptable」という主観フィルターを通るにすぎない。Leadership が評価失敗をオーバーライドした事実は RCA のイベント連鎖に現れない。 - **CAST の核心**: コントローラー(Dataset Import Team・Engineering)のメンタルモデル(「現行ポリシーで全問題検出できる」「ロールバック不要」)と文脈要因(初回 US Census データ、均一分布前提、責任拡散)を制御構造図から析出。非イベント的な systemic factors(Management of Change 欠如、Dynamic Environment)まで到達。 - **RCA vs CAST**: 事故モデル/改善計画/分析フレーム/組織要因の 4 軸で対比。CAST は遠位イベントと社会技術的要因まで踏み込む。 - **採用状況**: Rogers 普及曲線で CAST は Early Adopter 段階。「25 年以上 RCA 一辺倒」への問題提起。 **新規ページ**: - [[@2026__SREcon26Americas__The Case of the Misnamed Cities - CAST Analysis of a Google Maps Incident]] (source) - [[Ruben Barroso]] (entity) - [[Nancy G. Leveson]] (entity) - [[CAST]] (concept) **更新ページ**: - [[事故モデル]] — CAST の「イベント選択の主観性問題」批判と制御構造アプローチを横断的知見に追記 - [[根本原因分析]] — CAST 産業適用実績を横断的知見に追記 --- # 2026-06-28: SREcon26 Americas — The WTF Problem (Nicole Forsgren) [[Nicole Forsgren]] による SREcon26 Americas 2026-03-24 講演 "Mean Time to WTF: Why Developer Experience Frameworks Belong in Your Incident Retrospectives"(スライド内副題: "The WTF Problem: Developer Experience as a Reliability Property")を wiki 化検証([[@2026__SREcon26 Americas__The WTF Problem - Developer Experience as a Reliability Property]])。37 ページ全確認。transcript なし。USENIX ページ curl で発表日 2026-03-24 確認済み。ソースページ・概念ページ・entity ページは 2026-06-16 の先行セッションで既作成——今回は全ページ画像読了・date_published 修正・manifest 記録を実施。 **核心**: - **WTF Problem の定義**（p.1,6）— SRE のツール・プロセス・認知上の「摩擦(friction)」は感情の問題ではなくシステム特性。"This isn't a soft talk about feelings. It's about reliability. Your experience is a system property." - **摩擦の3分類**（p.9）— 認知負荷(Cognitive Load: アラートノイズ・不透明なシステム状態・危機中のメンタルモデルギャップ)・ツール摩擦(Tool Friction: 圧力下で戦う UI・発見困難な CLI フラグ・深夜2時に遅いダッシュボード)・プロセス摩擦(Process Friction: インシデント中の調整遅延・承認ゲート・解釈が必要なランブック)。 - **AI は摩擦を増幅する**（p.14-16）— AI 生成チームはデプロイ頻度を上げ変更規模を拡大する。既存摩擦が高ければ AI は逆効果。AI 生成システムは「既定で不透明」・ランブックが対応しない新障害モード・1000 行 AI diff は圧力下での推論が困難。 - **MTWTF**（p.23）— 北極星メトリクス。定義: 「アラートから『何が起きているか理解した』までの時間」。AI 生成システムが推論困難になるにつれ MTTR より先に上昇するシグナル。 - **SPACE for SRE**（p.19）— S(オンコール負荷・ツール満足度・心理的安全)・P(MTTD/MTTR/アラート精度)・A(トイル率・自動化率)・C(インシデント調整オーバーヘッド)・E(ツールコンテキストスイッチ・フロー中断)。AI 導入時は各次元が変化(E: 過信リスク、S: 出力信頼不安、C: 引き継ぎ困難、P: 不透明障害)。 - **"Productivity" vs "Experience" の言語戦略**（p.28）— 「生産性の改善」は Taylorism・Goodhart's Law の連想を呼ぶ。「体験の改善」は「障害を除去する」という受け取られ方になり予算が取れる。 - **ビジネスケースの因果連鎖**（p.29）— Friction → Slower MTTD/MTTR → Higher Change Failure Rate → SLA Risk → Revenue Impact。財務チームのダウンタイムコスト試算を借りる。 - **6つのアクション**（p.35）— #1 ランブックを1冊開いて現実を確認、#2 同僚1人に摩擦を聞く、#3 摩擦ログを始める、#4 MTWTF を一度計測する、#5 トイルアワーを宣言する(可視化優先・修正は後)、#6 組織のダウンタイムコスト数値を調べる。 **wiki との接続**: - [[@2026__SREcon26 Americas__The WTF Problem - Developer Experience as a Reliability Property]] — date_published を 2026-03-24 に修正、限界記述を更新 - [[MTWTF]] / [[SPACE]] / [[DORA]] / [[Nicole Forsgren]] — 先行作成ページ確認(変更なし) **作業**: source ページ更新(date_published 修正・限界記述更新) + manifest 記録のみ。新規ページなし。 --- # 2026-06-28: SREcon23 Americas — Human Observability of Incident Response (Matt Davis / FORM.com) [[Matt Davis]]（[[FORM.com]] Site Reliability Architect・音楽家 Craque）による SREcon23 Americas 2023-03-23 講演を wiki 化（[[@2023__SREcon23Americas__Human Observability of Incident Response]]）。39 ページ全確認。transcript なし（yt-dlp での YouTube 字幕取得失敗、media.url のみ保存）。USENIX ページは curl ブラウザ UA で取得しメタデータ確定。 **核心**: - **Joint Activity の3特性**（p.8）— インシデント対応は意図的協働・相互依存的チューニング・共通目標コミットメント・シグナル主導グループコレオグラフィで成立する。Pauline Oliveros の The Tuning Meditation（Deep Listening）を体験型導入として聴衆に実施。 - **Response Trio**（p.11）— Dr. Laura Maguire の Adaptive Choreography モデル: コンダクター ↔ コミュニケーター ↔ 問題解決者の三角形。ステークホルダーはコミュニケーター経由のみ。3特性: Interpredictability（同じスタイル・指示への信頼）・Directability（新シグナルによる方向転換）・Common Ground（互いの状況感知）。 - **Improvisation == Adaptive Capacity**（p.22）— インシデントは計画不能なため即興が必要。即興は Adaptive Capacity そのもの（Derek Bailey: 「即興は練習の外に存在しない」）。Ensieh Roud（Safety Science 2021）: 複雑文脈は集合的即興・社会的即興を必要とし、即興訓練が不可欠。 - **Common Grounding**（p.23）— 修復中に継続的に行われる「コミュニケーション・テスト・更新・調整・修復による相互理解とメンタルモデルの維持プロセス」（Klein, Feltovich, Bradshaw, Woods 2005）。修復の副次的活動でなくメイン活動の一つ。 - **メンタルモデルとシグナルの二層構造**（p.27-28）— SRE のメンタルモデル（Networks/Runbooks/Codebase 等）≅ ジャズ楽理（Keys/Melody/Structure 等）。シグナルはデジタル（Threads・Memes・Emoji/Reacji 等）と物理（Eye Contact・Tone of Voice・Smell 等）が並存。 - **Questions for Conducting**（p.30）— コンダクターが自問する8項目。疲労・食事・時刻・生産プレッシャーの知覚・競合優先事項——技術的状態でなく**人間の状態**に注目。 - **Support Humans（LUGMR）**（p.31）— Listen・Update・Guide・Monitor（心理的安全の監視）・Repair（交代・休憩確保）。 - **Practice of Practice Gamelan**（p.34-36）— 「インシデントを練習するのでなく共に働くことを練習する」反復訓練フレームワーク。ツール: Wheel of Expertise・Decision Requirements Tables・Multiverse Mirror・Oblique Alert Strategy・RPG Your Severity・Chaos Gameday。 - **人間実践者が適応的要素**（p.37）— "Human practitioners are the adaptable element of complex systems."（Richard Cook）。 **wiki との接続**: - [[Joint Activity]] — 新規 concept ページ作成。Adaptive Choreography の3特性・インシデント対応への適用 - [[Common Grounding]] — 新規 concept ページ作成。Klein et al. 定義・インシデント修復中の継続プロセス - [[Practice of Practice]] — 新規 concept ページ作成。6ツール含む反復訓練フレームワーク - [[人的要因]] — 「人間のオブザーバビリティ」独立次元・「即興能力は練習の外に存在しない」を横断的知見に追記 - [[レジリエンスエンジニアリング]] — 「即興 == 適応的キャパシティ」・Roud(2021)集合的即興論を横断的知見に追記 - [[インシデント管理]] — 技術的オブザーバビリティと人間のオブザーバビリティの並存・Response Trio と SRE Book Incident Command System の相補を横断的知見に追記 - [[Laura Maguire]] — Response Trio・Adaptive Choreography・Managing Hidden Costs of Coordination を entity ページに追記 **新規**: source 1（[[@2023__SREcon23Americas__Human Observability of Incident Response]]）+ entity 3（[[Matt Davis]]・[[Pauline Oliveros]]・[[Derek Bailey]]）+ concept 3（[[Joint Activity]]・[[Common Grounding]]・[[Practice of Practice]]）。**更新**: entity 1（[[Laura Maguire]]）+ concept 3（[[人的要因]]・[[レジリエンスエンジニアリング]]・[[インシデント管理]]）。 --- # 2026-06-28: SREcon23 Americas — Far from the Shallows (Courtney Nash / Verica) [[Courtney Nash]]（[[Verica]]）による SREcon23 Americas（2023-03-23）発表を wiki 化（[[@2023__SREcon23Americas__Far from the Shallows]]）。YouTube 動画（39.6 分）から 30 秒間隔で抽出した 79 フレーム全確認＋YouTube 自動字幕(transcript)使用。スライド PDF は非公開のため動画フレームで対応。 **核心**: - **「浅いデータ(shallow data)」批判**: Duration/MTTR・Severity・Root Cause という慣習的指標は複雑システムの表面しか捉えない。John Allspaw の語を借りて「洞察より怒りを生む」と指摘。 - **Severity は社交的調整物**: The Void データで Severity と Duration が無相関。Severity の構成要素は顧客影響・修正コスト・緊急度という変数プロキシ。Allspaw「評点(ratings)のようなもの—いかに過度な単純化か」。 - **MTTR 分布の左歪み**: 大多数のインシデントは短時間解決、一部の長時間インシデントが平均を引き上げ MTTR を歪める。 - **Rasmussen Safety Boundaries**: ECONOMIC FAILURE / UNACCEPTABLE WORKLOAD / ACCEPTABLE PERFORMANCE の 3 境界。Operating Point の位置は境界を越えて初めて判明する。 - **インシデントストーリー**: 豊かな社会技術的詳細・複数視点・テーマ開示・全体ズームイン/アウトの 4 特性を持つ長形式記録を代替枠組みとして提示。 **新規ページ**: - [[@2023__SREcon23Americas__Far from the Shallows]] (source) - [[Courtney Nash]] (entity) - [[Verica]] (entity) - [[インシデントストーリー]] (concept) **更新ページ**: - [[インシデント重大度評価]] — Severity 批判（Nash / Allspaw）追加 - [[根本原因分析]] — Dekker/Nash の Root Cause 指定 3 問題追加 - [[Jens Rasmussen]] — Safety Boundaries 詳細追加 --- # 2026-06-28: SREcon23 Americas — Turning an Incident Report into a Design Issue with TLA+ (Finn Hackett / Markus Kuppe) [[Finn Hackett]]（UBC）と [[Markus A. Kuppe]]（MSFT）による SREcon23 Americas（2023-03-22）発表を wiki 化（[[@2023__SREcon23Americas__Turning an Incident Report into a Design Issue with TLA+]]）。23 ページ全確認。transcript なし。USENIX ページは curl(ブラウザ UA)で取得しメタデータ確定。 **核心**: - **インシデントレポートを設計レベルの問いへ**: 28 日間の Azure CosmosDB インシデントを事例に、インシデントレポートから TLA+ フォーマルモデルへ変換するワークフローを提示。カウンター例が「問題を高水準でまとめる」点が核心（p.4）。 - **Session Consistency の落とし穴**: [[Azure CosmosDB]] の Session Consistency はトークンを共有するクライアント間でのみ同期。Work Dispatcher と Worker でトークンを共有しなかったため、「too fast」な処理で Worker が「not found」を受け取った（p.20–21）。 - **修正案**: Work Dispatcher がキューへジョブを投入する際にセッショントークンを添付し、Worker がトークン付きで読み取る（p.20）。 - **モデル活用の非対称コスト**: モデル構築は 3 ヶ月（[[Joshua Rowe]] が主導）、活用は 1 日。既存モデルの資産価値が高い。 - **「疑われていたが証明できなかった」を確定**: エンジニアは結果に驚かなかった——モデルチェッカーが証明困難だったことを形式的に確定できた（p.21）。 **更新した概念**: - [[結果整合性]] — Session Consistency のトークン共有不備が Eventual Consistency と同等の動作を招く実例。 - [[ポストモーテム]] — TLA+ フォーマルモデリングが「設計レベルの洞察」を補完する新手法として追加。 **新規作成**: - [[@2023__SREcon23Americas__Turning an Incident Report into a Design Issue with TLA+]] (source) - [[Finn Hackett]] (entity) - [[Markus A. Kuppe]] (entity) - [[Joshua Rowe]] (entity) - [[Azure CosmosDB]] (entity) - [[TLA+]] (concept) # 2026-06-28: SREcon23 Americas — Incident Archeology (Clint Byrum / Spotify) [[Clint Byrum]]（[[Spotify]]）による SREcon23 Americas 2023-03-21 講演を wiki 化（[[@2023__SREcon23Americas__Incident Archeology - Finding Value in the Paperwork and Narratives of the past]]）。27 ページ全確認。transcript なし。USENIX ページは curl(ブラウザ UA)で取得しメタデータ確定。 **核心**: - **インシデント考古学**: 過去のインシデント記録（ポストモーテム・チケット等）を「アーティファクト」として仮説検証に用いる手法。単一インシデントを深掘りするのでなく「深さでなく広さ」で横断分析。 - **Spotify 実データ（2020〜2021）**: ポストモーテム完了率 55%（2020 年）→62%（2021 年）——改善努力にもかかわらず 1 年でわずかしか伸びなかった「がっかりの発見」。生産性影響度 5 では 100% がポストモーテム保有、影響度 1 では 50% のみ。 - **副産物知見が最も有価値**: 設定仮説（夜間 MTTR 高い等）の検証より、「起動・終了時刻の 75% がデフォルト放置」「インシデントの 80% が業務時間中」「変更起因は 30% のみ」という予期しない知見の方が組織インパクト大。 - **4 指針**: 修正しない・分析できるものを分析・タイムボックスを守る・透明性が信頼を築く。 **新規ページ**: [[@2023__SREcon23Americas__Incident Archeology - Finding Value in the Paperwork and Narratives of the past]]、[[Clint Byrum]]、[[Spotify]]、[[インシデント考古学]] **更新ページ**: [[ポストモーテム]] --- # 2026-06-28: SREcon22 EMEA — The Repeat Incident Fallacy (Emily Ruppe / Jeli.io) [[Emily Ruppe]]（[[Jeli|Jeli.io]]）による SREcon22 EMEA 2022-10-26 講演を wiki 化（[[@2022__SREcon22EMEA__The Repeat Incident Fallacy - What Jurassic Park Can Teach Us about Incidents]]）。24 ページ全確認。transcript なし。USENIX ページは curl(ブラウザ UA)で取得しメタデータ確定。 **核心**: - **Repeat Incident Fallacy（再発インシデント誤謬）**: 「同じインシデントを二度と起こさない」という誓約は誤った前提に立つ。CI/CD による継続的変化がシステムを常に異なるものにする（[[Laura Maguire]] 命題: p.5）。 - **ジュラシックパーク比喩**: JP 1993 = 旧来のシステム（saboteur・hurricane・予期しないユーザー行動）。JW 2015 = 「訓練済み・封じ込め済み」と主張した改善後のシステム。しかし同じ構造的失敗が繰り返された。 - **新機能が潜在問題を顕在化する**: p.16 の「ファンシーな新機能」図が核心——新機能はトリガーであり、周囲の潜在的問題（キャパシティ・プロセス・アラート・古いコード片）を起動させる。 - **目標転換**: "prevent this from happening again" → "Insights from the Past = Options in the Future"（p.21–22）。 - **Work on your Cardio**: レジリエンスはポストモーテムの修復策でなく、日頃の準備（ストーリーテリング・心理的安全性・ゲームデイ等）によって構築する（p.19）。 **更新した概念**: - [[ポストモーテム]] — Repeat Incident Fallacy と 4 者収束（Gallego/Lund/Partington/Ruppe の「再発防止→学習・選択肢」転換）。 - [[レジリエンスエンジニアリング]] — 「カーディオ」と evolving sociotechnical systems。 **新規作成**: - [[@2022__SREcon22EMEA__The Repeat Incident Fallacy - What Jurassic Park Can Teach Us about Incidents]] (source) - [[Emily Ruppe]] (entity) - [[Laura Maguire]] (entity) # 2026-06-28: SREcon22 APAC — A Post Incident Review Review (Tom Partington / ANZx) [[Tom Partington]]（[[ANZx]] SRE）による SREcon22 APAC 2022-12-09 講演を wiki 化（[[@2022__SREcon22APAC__A Post Incident Review Review]]）。53 ページ全確認（p.29 のみ API 拒否）。transcript なし（USENIX 音源未取得）。USENIX ページ HTML を curl で取得しメタデータ確定。 **核心**: - **PIR の定義**（p.5）— Post-Incident Review(PIR)。ポストモーテム・事後分析・ホットウォッシュなど呼称は様々。ANZx では PIR² と呼ぶ（Squared: Record + Report の2文書体制）。 - **Record vs Report の区別**（p.33）— Incident Record（インシデント中に収集した事実の保持）と Incident Report（インシデント後に作成する学習文書）を明確に分離。従来の「ポストモーテム文書」はこの2つを混同していることが多い。 - **ANZx PIR² の7ステップ**（p.30-52）— (1) Initiation: SEV1/2 は即・SEV3/4 は SRE が判断。SLO 指標が TTL などを置き換え MTTx を排除。(2) Brief: 文書・ファシリテーター・参加者を決める。(3) Gather: Incident Record（出来事の根拠、非解釈的）を作成。(4) Debrief: ブレーム・アウェアなデブリーフィングセッション。5問の Lessons。(5) Review: エンジニアリング・組織が承認・保管。(6) Share: 全社共有 Bulletin（Slack）。(7) Repeat: 1 ヶ月後に Actions の完了確認。 - **根本原因・アクションアイテム・MTTx の意図的排除** — 「なぜ？は PIR² の一部ではない」（p.39）。アクションアイテムは PIR の価値でなく副産物（p.48）。MTTx は SLO ベーストリガーに置き換え（p.30）。にもかかわらず「再発インシデントがまれ」。 - **learning > fixing**（p.44）— J Paul Reed の調査: PIR の 90.5% が修復アイテムを含む現状を「学習要素が欠落しがちな証拠」として提示。Lessons の5問（What surprised us? / What went well? / What was difficult? / Where did we get lucky? / What don't we understand?）は修復を問わず知識抽出に特化。 - **カウザルマップ（Causal Map）**（p.21）— 多要因の因果グラフ（DB クラッシュ例: 時間的プレッシャー + SRE 不在 + 技術的負債 + プラットフォーム DB なし → ディスク満杯 → DB クラッシュ → サービス不能）。Rasmussen の動的境界ドリフトモデルの実践表現。 - **Safety I → Safety II**（p.49）— 安全 I は「問題が起きた場合のみ学ぶ（分布の左裾）」。安全 II は「問題が起きた場合も起きなかった場合も学ぶ（分布全体）」。ANZx は Safety II 方向への移行を目標として提示。 - **Blame-aware デブリーフィング Ground Rules**（p.41）— 「反事実を避ける」「判断的になりそうなら好奇心を持つよう試みる」等のファシリテーションスクリプト。ファシリテーターは安全な場を作り、参加者は互いを批判しない。 **引用した安全科学理論**: - [[Jens Rasmussen]] — Safety Model (Workload/Economic/Performance 境界)（p.15） - [[James Reason]] — スイスチーズモデル（p.22） - [[Sidney Dekker]] — Dekker's Tunnel; New View（p.17-19） - STELLA レポート（David D. Woods ほか）— Woods' Theorem（p.29） - Erik Hollnagel — Safety I / Safety II（p.49） **wiki との接続**: - [[ポストモーテム]] — ANZx 実践実績（根本原因/アクションアイテム/MTTx 排除で再発まれ）・learning > fixing・Record vs Report を横断的知見に追記 - [[事故モデル]] — Rasmussen Safety Model と PIR スタイルの接続・カウザルマップを横断的知見に追記 - [[人的要因]] — Mechanistic Reasoning 批判・Dekker's Tunnel を横断的知見に追記 - [[レジリエンスエンジニアリング]] — Safety I→II・STELLA/Woods' Theorem を横断的知見に追記 **新規**: source 1（[[@2022__SREcon22APAC__A Post Incident Review Review]]）+ entity 8（[[Tom Partington]]・[[ANZx]]・[[J Paul Reed]]・[[John Allspaw]]・[[Jeli]]・[[Sidney Dekker]]・[[James Reason]]・[[Jens Rasmussen]]）。**更新**: 4 concept ページ（[[ポストモーテム]]・[[事故モデル]]・[[人的要因]]・[[レジリエンスエンジニアリング]]）。 --- # 2026-06-28: SREcon19 Americas — Running Excellent Retrospectives: Talking for Humans (Courtney Eckhardt / Heroku + Lex Neva / Fastly) [[Courtney Eckhardt]]（[[Heroku]]）と [[Lex Neva]]（[[Fastly]]）による SREcon19 Americas 2019-03-26 チュートリアル（90 分体験型）を wiki 化（[[@2019__SREcon19Americas__Running Excellent Retrospectives - Talking for Humans]]）。56 ページ全確認。transcript なし（YouTube 429 エラー）。 **核心**: - **ファシリテーターの3仕事**（p.8）— (1) ファシリテーション: 安全な学習環境、心理的安全の保守、servant leadership。(2) 生産的な会議運営: アジェンダ・時間管理・割り込み。(3) ユーモアの失敗回避: ジョークの体系的管理。SREcon19 Asia 版（Eckhardt 単独）との設計思想の違いはこの「3仕事」という整理と「体験型」構成。 - **言語レベルの blame 回避**（p.13-19）— "you" は対立構造、"why" は agentive 文法（非難が文法に組み込まれる）、always/never/should/just/only は過度な一般化と当為。代替: how / what / what if / could we / what do you think about。 - **Miller の法則**（p.20）— 「相手の言葉を理解するには、それが真だと仮定してどういう状況なら真になるかを想像しなければならない」（George Armitage Miller）。ローカル合理性（人は当時の文脈で合理的な理由で行動する）の認識論的根拠。 - **Lake Washington 浮橋事例**（p.25-30）— 1990 年感謝祭の嵐で沈没。公式調査は5物理要因（水圧破砕・水蓄積・荷重・橋脚亀裂・連鎖沈降）を列挙したが、ポンプ管理できなかった作業員の状況を調査・文書化しなかった。「ほぼ良い振り返りだが不完全」——人的要因を欠く工学的調査の典型例。 - **Conway's Law 帰結**（p.31）— 「振り返りは組織のコミュニケーション構造の一部であり、あなたたちが動かすシステムを生み出す」。個々の会議での言語選択が組織の学習文化を形成する。 - **パーセプチュアル学習設計**（p.10）— Kathy Sierra のアプローチに基づき、チュートリアル全体をファシリテーションの手本そのものとして構築。「ファシリテーションを教えるにはファシリテーションするしかない」。 - **ユーモア禁止リストと代替策**（p.40-48）— 職場での不快な経験・政治・宗教・特定個人への批判はすべてNG。代替: 優しさ・思いやり・誠実さ・成功を称える・正直さへの感謝。失敗したら謝罪・訂正・前進（wallowing は自己非難の一形態）。 **wiki との接続**: - [[レトロスペクティブファシリテーション]] — パーセプチュアル学習・ユーモア体系的管理・感情環境制御の3横断知見を追記（ソース4つ目に追加） - [[人的要因]] — Lake Washington 事例（人的要因調査の不完全性）を横断的知見に追記 - [[ポストモーテム]] — sources に追記 **新規**: source 1（[[@2019__SREcon19Americas__Running Excellent Retrospectives - Talking for Humans]]）+ entity 2（[[Lex Neva]]・[[Fastly]]）。**更新**: [[Courtney Eckhardt]]（Americas talk 追記）、[[レトロスペクティブファシリテーション]]（横断知見3件追記）、[[人的要因]]（Lake Washington 追記）、[[ポストモーテム]]（sources 追記）。 --- # 2026-06-28: SREcon22 EMEA — Principled Identification of "Root Causes" Using Techniques from Safety Engineering (Laura de Vesine / Datadog) [[Laura de Vesine]]（[[Datadog]] スタッフエンジニア）による SREcon22 EMEA 講演を wiki 化（[[@2022__SREcon22 EMEA__Principled Identification of Root Causes Using Techniques from Safety Engineering]]）。23 ページ全確認、YouTube 自動字幕(en)あり。 **核心**: - **トリガーホワイトアモール反射**（p.12）— インシデント分析の典型的失敗パターン。5 Whys を「判断基準なし」で使うとトリガーを遡るだけになる。逆方向の失敗(「資本主義」「気候変動」)も示す。 - **System/Environment 境界モデル**（p.13-14）— 「制御できるかどうか」でシステムと環境を分ける。根本原因 = システムの脆弱性、トリガー = 最悪ケースの環境条件。 - **用語の再定義**（p.15）— "Root cause" を廃棄せず「システムに潜在していた脆弱性の集合」と再定義。Gallego の「用語を使わない」と Dekker の「原因は構築される」の中間点。 - **ニアミスの重要性**（p.9・p.14）— 脆弱性があれば障害は「起こりうる」状態。ニアミスも実障害と同等に調査対象。 - **SRE での System 分類**（p.20）— System 側: コード・リリース・容量計画・インフラ。Environment 側: マシン障害・人的エラー・顧客行動・バグ。 **接続**: [[根本原因分析]]（横断的知見追記）/ [[事故モデル]]（横断的知見追記）/ [[Laura de Vesine]]（新規） --- # 2026-06-28: SREcon22 EMEA — Ditch the Template: How to Write Incident Reports They Want To Read (Laura Nolan, Stanza Systems) [[Laura Nolan]]（[[Stanza Systems]]、元 Google・Slack SRE）による SREcon22 EMEA 2022-10-26 講演（36 ページ）を wiki 化（[[@2022__SREcon22 EMEA__Ditch the Template - How to Write Incident Reports They Want To Read]]）。プログラム表記は "Break Free of the Template" だが、スライド本体・ブログ記事（2023-03-31）ともに "Ditch the Template" を使用しており、後者を正式タイトルとして採用。transcript なし；ブログ記事を補完として活用。 **核心**: - **「IR の価値は学習にあり、プロセスにあるのではない」（p.7）** — Richard I. Cook 命題 13（人的専門知識は常に変化し続ける）を受けて、形式遵守より知識創造・伝承を優先する。 - **テンプレート批判（p.8–11）** — SRE Book テンプレート（Title / Date / Root Causes / Trigger / Resolution ...）を機械的に埋める IR は「クッキーカッター」であり、ナラティブを失わせ学習機会を損なう。Jurassic Park の IR 例が象徴的。 - **ナラティブ 3 部構成** — 謎の発生→試行錯誤の調査→解決、という構成が読者を引き込む。調査中の不確実性をそのまま書くことがリアリティを生む。 - **読者サポート（p.16–18）** — 専門知識を前提としない・ジャーゴンと WHY を説明する・背景説明を本文に織り込む・詳細ドキュメントへリンクする。 - **視覚化（p.19–22）** — Cloudflare BGP 図・Slack DNSSEC タイムライン図・Honeycomb 負荷分散 before/after 図が好例。タイムライン・シーケンス図・アーキテクチャ図・グラフを惜しまず使う。 - **分析の共有（p.23–25）** — 「IR がストーリーなら分析はその教訓」。技術的修正を超えたシステム論的洞察（Honeycomb の Goldilocks 操作ゾーン等）が IR を長く語り継がれる文書にする。 - **文体の Craft（p.26–34）** — 記憶に残るタイトル・シンプルな言語・適度な硬さ・見出し・文のリズム・時制の統一・文化的比喩の回避・セールスピッチにしない。 **ポストモーテム論との接続**: Gallego（ブレーム・アウェア・根本原因否定）・Larson（Incident Legalism）・Lund（Human Factors デブリーフィング）が「プロセス・ファシリテーション」の側から形骸化を論じるのに対し、Nolan は **「文書の質」** の側から同じ形骸化問題にアプローチし相補的。 **新規**: source 1（[[@2022__SREcon22 EMEA__Ditch the Template - How to Write Incident Reports They Want To Read]]）+ entity 2（[[Laura Nolan]]・[[Stanza Systems]]）+ concept 1（[[インシデントレポート執筆]]）。**更新**: [[ポストモーテム]]（2 横断知見追記）。 --- # 2026-06-28: SREcon19 Asia/Pacific — Retrospectives for Humans (a crash course) (Courtney Eckhardt / Heroku) [[Courtney Eckhardt]]（[[Heroku]] / Salesforce、@hashoctothorpe）による SREcon19 Asia/Pacific 2019-06-12 講演を wiki 化（[[@2019__SREcon19 Asia__Retrospectives for Humans (a crash course)]]）。47 ページ全確認、YouTube transcript（自動字幕）あり。 **核心**: - **言語学的基盤**（p.1-6）— 外部補足スライドとして denotation/connotation・implication/presupposition の概念を解説。「英語は単一の意味を持たない」文化的・地域的変異を前置きすることで、後続の言語ガイドラインが「規則」でなく「原則」として提示される。 - **Miller's Law**（p.18）— 「相手の言葉を理解するには、それが真だと仮定してどういう状況なら真になるかを想像しなければならない」。George Armitage Miller、Suzette Haden Elgin 経由。自分の経験の外にある発言（同一インシデントの別の当事者の体験）を理解する唯一の方法。ファシリテーション哲学の中核。 - **避けるべき語と問い方の変換**（p.19-24）— "you" は対立構造を作り、"why" は agentive 言語を引き出して非難が文法に組み込まれる。always/never/just/should は過度な一般化・当為を刷り込む。代替: how, what, what if, could we。 - **「なぜ前回直さなかったのか」の解剖**（p.23）— この一文には「以前にも起きた / 容易に直せた("just")/ あなたが直す人間だった / 正当な理由がなかった」という4つの後知恵バイアスの前提が埋め込まれている。問いの文法構造そのものが学習を浅くする。 - **contributing factor discovery**（p.25/transcript）— Heroku で「根本原因分析」の代わりに使う用語。1990 年シアトル湖上橋崩壊（5 因子の重なりで初めて崩壊）を事例に、単一原因の宣言が思考を制約することを示す。Gallego の根本原因否定と独立に同じ方向へ収束。 - **「ヒューマンエラーは根本原因でない」**（p.26）— John Allspaw（Sidney Dekker・David Woods 参照）。「ヒューマンエラーは調査を終わらせる場所でなく、始める場所。」4 つの次の問い: どう起きたか / 起きやすかった条件 / 経路 / 気づくまでの時間。 - **「Try harder は改善策でない」**（p.27）— 人間の完璧な vigilance に依存することは不合理。今日の人間が将来のためにも計画しなければならない人間。 - **ユーモアのリスク**（p.32-36）— 「喜劇は悲劇＋時間」——レトロスペクティブには十分な時間が経っていない。管理職も同席。代わりに親切・思いやり・感謝で場を和ませる。 - **Conway's Law との接続**（p.44）— 「レトロスペクティブは組織のコミュニケーション構造の一部であり、あなたたちが動かすシステムを生み出す。」個々の言語選択が組織の学習文化を形成する。 **既存 wiki との接続**: [[ポストモーテム]] に contributing factor discovery・ファシリテーター言語の三者収束を追記。[[人的要因]] に Miller's Law の認識論的基盤とヒューマンエラー三者収束（Eckhardt/Lund/Gallego）を追記。[[レトロスペクティブファシリテーション]] を新規作成。 **新規**: source 1（[[@2019__SREcon19 Asia__Retrospectives for Humans (a crash course)]]）+ entity 2（[[Courtney Eckhardt]]・[[Heroku]]）+ concept 1（[[レトロスペクティブファシリテーション]]）。**更新**: [[ポストモーテム]]（contributing factor discovery・ファシリテーター言語の学習深度規定）・[[人的要因]]（Miller's Law・三者収束）。 --- # 2026-06-28: SREcon19 Asia — Getting More out of Postmortems and Making Them Less Painful to Do (Ashar Rizqi / Blameless) [[Ashar Rizqi]]（[[Blameless]]）による SREcon19 Asia/Pacific 2019-06-14 トークを wiki 化（[[@2019__SREcon19Asia__Getting More out of Postmortems and Making Them Less Painful to Do]]）。51 ページスライド全ページ確認、YouTube 自動字幕 transcript 取得済み。 **核心**: - **成功するポストモーテムの6要素**（p.23）— Ownership・Context & Key Details・On Time Completion・Follow-up Action Items Tracked to Completion・Blameless Language・Referenceability。300 社以上の事例から導出。各要素について「なぜ難しいか」と「どうすれば簡単になるか」をケーススタディ形式で体系化。 - **ポストモーテムがもたらす4価値**（p.7–11）— 回復力向上・開発速度向上・未知インサイトの発掘・ブレームレス & コラボラティブ文化。 Agree/Disagree の聴衆インタラクションで段階的に提示。 - **所有権問題の構造**（p.24–26）— Hot Potato Blame・役割未定義・トイル化が3大障壁。解決策は「1 サービスオーナー = 1 PM オーナー」+ Postmortem Guild（社内横断有志グループ）。 - **期日内完了の強制**（p.27–29）— 未完了 PM を持つチームへのリリースブロック・Slack/MSFT Teams 上での非同期 PM・スプリント内の時間確保・称えるゲーミフィケーション。 - **Slack でのポストモーテム実例**（p.30）— `#inc-2323-postmortem` チャンネルで PM オーナーが情報収集を指示するスクリーンショット。非同期軽量実施の具体例。 - **再参照性は未解決**（p.43–46）— Rizqi 自身「TBH: It's still hard!」と認め、暫定策（テンプレート統一・集中配置・ログ形式インデックス）を示すが根本解決には至らず。未解決問題として「非同期 vs 同期」「完了宣言タイミング」「知識抽出」を提示。 **他ソースとの接続**: Gallego（2016, 2018）の「根本原因は1つでない」「人を責めない」と同方向。Lund（2019 同カンファレンス）の個別インタビュー→デブリーフィング手法とは異なるアプローチ（軽量非同期化 vs. 深掘りファシリテーション）。 **新規**: source 1（[[@2019__SREcon19Asia__Getting More out of Postmortems and Making Them Less Painful to Do]]）+ entity 2（[[Ashar Rizqi]]・[[Blameless]]）。**更新**: [[ポストモーテム]]（6要素・再参照性未解決・Slack 実施・ギルド提案の4知見追加 + 未解決の問い2件追加）。 --- # 2026-06-27: SREcon16 Europe — Accident Models in Post Mortems (Will Gallego / Nathan Hoffman / Miriam Lautner, Etsy) [[Will Gallego]]・[[Nathan Hoffman]]・[[Miriam Lautner]]（[[Etsy]]）による SREcon16 Europe 2016 年 7 月チュートリアルを wiki 化（[[@2016__SREcon16Europe__Accident Models in Post Mortems]]）。100 ページスライド全ページ確認、transcript なし。 **核心**: - **事故モデルの系譜**（p.15-35）— Bad Apples（「システムは安全。悪い人間を排除せよ」）→ ハインリッヒのドミノ理論 → James Reason のスイスチーズモデル（能動的失敗 + 潜在的条件 + 連続した防御層の穴の揃い）。3 段階の進化が 1 スライドずつ体系的に示される。 - **「ヒューマンエラー」批判**（p.16-19）— Amazon・NASDAQ・ドイツ鉄道の事故報告がすべて "Human Error" で終わる事例を示し、Steven Shorrock（EUROCONTROL）の定義「誰かが誰かの定めに従わなかった」という循環性を暴く。これは [[事故モデル]] 概念の新規作成の起点。 - **安全性は創発的特性**（p.34, Sidney Dekker）— 「Safety is an EMERGENT PROPERTY that arises when components and processes interact with each other and their environment.」Bad Apples が前提とする「システムは基本的に安全」を否定する。 - **「原因は構築される」**（p.36, Dekker）— 「Cause is not something you find. Cause is something you construct.」ポストモーテムにおける「根本原因を探す」姿勢そのものを問題化する。 - **ブレーム認識（Blame Awareness）とバイアス一覧**（p.41-61, Will Gallego）— 後知恵バイアス・反事実的思考・結果バイアス・知識の呪い・防衛的帰属仮説の 5 バイアスを特定し、「バイアスを止めるのでなく、非難なき形で呼び出す」技術を提示。 - **デブリーフィング 7 カテゴリ**（p.62-95）— Cues / Interpretation / History / Goals / Action / Communications / Help の問いかけフレームワークで「その時点で当事者の目に世界がどう見えたか」を段階的再構築。各カテゴリに具体的な質問例（http://bit.ly/DebriefingPrompts）。 - **学習が目標、修復は必須でない**（p.97）— 「Action items not always necessary / Soak time」。[[ポストモーテム]] 概念の「修復的正義」知見に接続。 **Etsy ポストモーテム思想の発展の観点**: この 2016 年チュートリアルは [[Will Gallego]] が [[Nathan Hoffman]]・[[Miriam Lautner]] と共同登壇した初期版であり、2018 年の `Architecting a Technical Post Mortem`（[[@2018__SREcon18 Americas__Architecting a Technical Post Mortem]]）はこの思想を Gallego 単独で深化・体系化したもの。2 年間の進化を時系列で追える。 **新規**: source 1（[[@2016__SREcon16Europe__Accident Models in Post Mortems]]）+ entity 2（[[Nathan Hoffman]]・[[Miriam Lautner]]）+ concept 1（[[事故モデル]]）。**更新**: [[ポストモーテム]]（デブリーフィング 7 カテゴリ・2016→2018 思想発展）・[[Will Gallego]]（first_mentioned 修正・SREcon16 Europe 追記）・[[Etsy]]（3 名登壇・morgue 言及追記）。 --- # 2026-06-27: SREcon15 — What Brought Us Down? Outage Trend Analysis at Google (Sue Lueder) [[Sue Lueder]]（[[Google]] SRE Program Manager）による SREcon 2015 講演（2015-03 Santa Clara）を wiki 化。30 ページ全画像確認、音声取得済み（Whisper 失敗のため transcript なし）、全グラフ捏造データと明記。 **核心**: - **GQM フィードバックモデル**（p.4）— Goal Question Metric→Collect→Organize→Analyze→Socialize。初期は GQM 設計に工数集中、後期は Socialize が最大工数。 - **8 フェーズインシデントタイムライン**（p.12）— Root Cause→Hits Production→Detect（BEEP!）→Escalate→Mitigate（Drain/Failover/Push/Rollback）→Resolve（if A==B）→Retrospect→Action Items。Incident Duration = Detect → Resolve。 - **根本原因カテゴリ 9 種**（p.16）— 5 大カテゴリ（Capacity/Deployment Planning/Software/Workflow/Network Failure）＋4 補助（Third Party Systems/Config/Mother Nature/Hardware）。Network Failure と Third Party Systems が最高頻度。 - **重大度フラグ 4 次元**（p.22）— 法的・ユーザー影響・財務・サービス種別で Finance/PR/Quality の 3 パースペクティブを生成。 - **修正機会 3 方向**（p.26）— Stop（根本原因阻止）・Faster（Detect→Mitigate 短縮）・Prevent and Fix Culture（事後醸成）。 **新規**: source 1（[[@2015__SREcon15__What Brought Us Down - Outage Trend Analysis at Google]]）+ entity 1（[[Sue Lueder]]）+ concept 2（[[障害傾向分析]]・[[インシデント重大度評価]]）。**更新**: [[インシデント管理]]（8 フェーズ＆ Stop/Faster/Culture 知見追記）・[[根本原因分析]]（9 カテゴリ産業分布と学術乖離追記）・[[ポストモーテム]]（GQM = 単一 PM の上位レイヤーとしての位置づけ追記）・[[Google]]（インシデント分析プログラムセクション追記）。 --- # 2026-06-27: SREcon19 APAC — A Tale of Two Postmortems (Tanner Lund) - [[ポストモーテム]](更新): Dekker の4目的枠組み(認識論的・予防的・道徳的・実存的)を横断的知見に追加。「ヒューマンエラー=行き止まり」「修復の完了率・効果への懐疑」の 3 観点を Larson/Gallego との突き合わせで収束確認。 - [[人的要因]](新規 concept): Human Factors の SRE への適用。「ヒューマンエラーは分析の行き止まり」「規範的言語が後知恵バイアスを固定化する」「人間の適応性が安全の源泉」の 3 軸。 - [[レジリエンスエンジニアリング]](新規 concept): 創発的振る舞い・もつれた因果性・帰納の問題・次元性の呪い・16種システム耐性ストレス要因。Dekker/Cook/Rasmussen/Bainbridge 系統の参考文献リスト。 - [[Tanner Lund]](新規 entity): Microsoft Azure PRSE、@101010Lund。 - **次に追うべき問い**: (i) Postmortem #2 の個別インタビュー手法の具体的質問例・所要時間は?(動画取得できれば確認可) (ii) Dekker の「実存的目的」はソフトウェア障害のポストモーテムにどう実装されるか (iii) Allspaw ら「Debriefing Facilitation Guide」(Etsy)の wiki 取り込みを検討 Navigation: [[index]] | [[log]] | [[overview]] ## Last Updated 2026-06-30: **Software Analytics for Incident Management of Online Services: An Experience Report (ASE 2013) ingest-paper** — [[Jian-Guang Lou]] / [[Qingwei Lin]] / [[Rui Ding]] / [[Qiang Fu]] / [[Dongmei Zhang]](Microsoft Research Asia) / [[Tao Xie]](UIUC)による産業 AIOps の最初期経験報告([[@2013__ASE__Software Analytics for Incident Management of Online Services - An Experience Report]])。Service X の MTTR 問題(2 時間超)を解くため Service Analysis Studio (SAS) を設計・本番展開。**4 手法**: (A) 全 1200+ メトリクスから CAR マイニングで[[インシデントビーコン]]を自動抽出(再現率 ~90% vs L1-LR ~60%)、(B) FCA+DMI で障害リクエストの「不審実行パターン」を抽出([[ログベース障害診断]]の前身)、(C) ガウス分布異常でマルファンクションサーバロールを検知、(D) GVSM で過去インシデントを検索し治癒行動を推薦(top-1 精度 0.90)。**3 教訓**: (1) 技術主導→問題主導への転換(Service X チームのフィードバック起点)、(2) HITL 設計の必要性(完全自動化は本番では非現実的)、(3) 段階的信頼構築(v1.0→内部→1DC→世界展開)。本番展開: OCE 91% が利用、86% のインシデントを診断対象、76% で有用。**新規**: source 1([[@2013__ASE__Software Analytics for Incident Management of Online Services - An Experience Report]]) + entity 3([[Rui Ding]]・[[Qiang Fu]]・[[Tao Xie]])。**更新**: [[Jian-Guang Lou]]・[[Qingwei Lin]]・[[Dongmei Zhang]]・[[インシデント管理]]・[[ログベース障害診断]]。 2026-06-27: **Architecting a Technical Post Mortem (SREcon18 Americas) ingest-slides** — [[Will Gallego]]（[[Etsy]]）による SREcon18 Americas 講演（2018-03-29）を wiki 化（[[@2018__SREcon18 Americas__Architecting a Technical Post Mortem]]）。33 ページ全画像確認。**核心**: (1) **「ブレームレス」より「ブレーム・アウェア（非難認識）」** — 「ブレームレス」は責任の否定と誤解されやすく必要なデータポイントの隠蔽を招く。バイアスの存在を認めつつ指差しの形で表出させない精緻化。(2) **ポストモーテムの定義に修復を含めない** — "The application of a learning culture through shared discussion of our beliefs on what transpired over an agreed upon limited number of events." 修復・再発防止の保証を意図的に排除。Larson の「Incident Legalism」と同根の病理を別角度で防止する設計。(3) **「根本原因」は誤った概念** — PM で root cause / primary cause などの用語を使わないことを強く推奨。成功にも根本原因はなく、失敗も同じ多因子構造。Cook（1998）の命題 7 を実務者の言葉で再表明。(4) **ローカル合理性** — 人はその時点の情報で最良と信じた行動をとっており、判断を却下したくなるとき「誰もシステムを壊しに来ない」原則を思い出すことがファシリテーションの核心。(5) **修復的正義の枠組み** — 報復的正義（規則・違反・制裁）vs 修復的正義（癒し・複数の物語の受容・関係の回復）の対比でブレームレス PM の本質を位置づける。(6) **タイムボクシング** — 1 時間: 5 分イントロ → 35–40 分タイムライン → 10 分 Q&A → 残り時間で修復策（必要な場合のみ）。修復は最後の「もし時間があれば」。(7) **Stella Report / Woods' Theorem** — "As the complexity of a system increases, the accuracy of any single agent's own model of that system decreases rapidly."（IBM・Etsy・IEX・Ohio State の SNAFU Catchers' Consortium）。記憶の不完全性・根本原因否定の理論的根拠。**新規**: source 1([[@2018__SREcon18 Americas__Architecting a Technical Post Mortem]]) + entity 1([[Will Gallego]])。**更新**: [[ポストモーテム]]（5 観点の横断的知見追記）・[[根本原因分析]]（SRE 文化的文脈での根本原因否定を追記）・[[Etsy]]（Gallego 登壇・SNAFU Catchers' Consortium 参加を追記）。代表スライド画像 5 枚を `wiki/sources/_attachments/srecon18americas-gallego/` に配置。 2026-06-27: **Failures and Fixes: A Study of Software System Incident Response (arXiv 2020) ingest** — [[Jonathan Sillito]]・[[Esdras Kutomi]]([[Brigham Young University]])による 30 インシデント定性研究を wiki 化([[@2020__arXiv__Failures and Fixes - A Study of Software System Incident Response]])。**核心**: (1) **障害 4 原因カテゴリ**: デプロイ・インフラ変更・スケーリング限界超過・システムソフトウェア/ハードウェア障害。(2) **検知の 3 次元**: 自動化・特異性・適時性——汎用的なモニタリングは遅行指標になり(観察 5)、しきい値ベース検知は脆弱で新しいインシデントパターンに適応できない(観察 6)。(3) **調査戦略の二分類**: 日和見的(典型原因確認/時間相関探索)と体系的(症状連鎖/スタック追跡)の組み合わせ——相関を発見しても因果理解がなければ調査が失敗する(観察 8・9)。(4) **緩和の 5 戦略**: 障害除去・影響受けたサービスの回復・他への波及防止・機能の恒久的制限・完全修正——緩和は連鎖した障害状態が残るため根本原因修正のみでは完了しない(観察 10・11)。(5) **支援ツール自体が監視不足という構造的問題**(観察 7)——モニタリング・通知システム自体の欠陥が全インシデントの対応品質に影響するが、これらのツール自体は最も監視されていない。**wiki 横断的な位置づけ**: AIOps/LLM 自動化研究が前提とする「自動検知→トリアージ→RCA→緩和」の線形パイプラインモデルが実態と乖離していることを定性的に裏付ける 2020 年の基礎研究。AlertGuardian の観察 6 対応・Bian Que の観察 5 対応・TSGuard の観察 7 対応として、LLM 期の各論文が個別に攻める課題の出所を一本で把握できる。**新規**: source 1([[@2020__arXiv__Failures and Fixes - A Study of Software System Incident Response]]) + entity 3([[Jonathan Sillito]]・[[Esdras Kutomi]]・[[Brigham Young University]]) + concept 1([[インシデント調査戦略]])。**更新**: [[インシデント管理]]・[[根本原因分析]]・[[オペラビリティ]]・[[変更起因インシデント]]。 2026-06-27: **ポストモーテム実務ガイド 5 ソースバッチ ingest** — インシデント対応後のポストモーテムプロセスに関する実務記事 5 本（GitHub ReadME / PagerDuty / Datadog / mixi / Hatena）を横断 ingest し、新コンセプト [[ポストモーテム]] を作成。**核心**: (1) [[Will Larson]] の「Incident Legalism」（インシデント法律主義）——ポストモーテムが信頼性でなくコンプライアンスに焦点を移す形骸化メカニズム。対策は対応・分析・修復の三段への投資バランス。(2) mixi の再発防止策 4 分類（予防/検出/緩和/修正）は [[インシデント管理]] ライフサイクルの各段にマッピングでき、アクションアイテムのカバレッジを網羅的に検証する枠組み。(3) Datadog のリビングドキュメント化——ポストモーテムを静的文書でなくインタラクティブグラフやコメント機能を備えた継続的調査ツールとして運用。(4) Hatena の全社共有——「同じ障害を繰り返さない」再発防止を超えて「類似構造の別障害を予防する」横方向の学習。英語圏（Google SRE Book/Workbook/PagerDuty/Datadog）と日本企業（mixi/Hatena）のプロセス比較表を概念ページに集約。**新規**: source 5 + concept 1([[ポストモーテム]]) + entity 2([[Will Larson]]・[[PagerDuty]])。**更新**: [[インシデント管理]]・[[Datadog]]・[[Hatena]]。 2026-06-27: **Do Not Blame Users for Misconfigurations (SOSP'13) ingest** — [[Tianyin Xu]] ほか(UCSD / Toronto / NetApp)による設定ミス研究の基礎論文を wiki 化([[@2013__SOSP__Do Not Blame Users for Misconfigurations]])。**核心**: 設定ミスは「ユーザーの失敗」ではなく開発者が設定要件(制約)を設計・検証しないことにある。SPEX はソースコードのデータフロー解析で 5 種の設定制約(基本型・セマンティック型・値域・制御依存・値関係)を自動推論し、SPEX-INJ が制約違反を注入して **743 件の[[設定ミス脆弱性]]**を検出(7 システム)。脆弱性の **80% がサイレント系**(違反 378 件 + 無視 221 件)でクラッシュ 26 件を大幅に上回る。24〜38% の実設定問題が SPEX で未然防止可能と推定。364 件の脆弱性・80 件のエラー誘発設計が開発者に確認・修正され、Squid プロジェクトの設定解析ライブラリ改善(150+ パラメーター)に影響。**[[設定マイニング]]との位置づけ**: SPEX は「ソースコードから直接制約を推論するホワイトボックス」の確立であり、ブラックボックスマイニング(EnCore/Zodiac)と並ぶ二大系統の起点。クロスソフトウェア制約(実問題の 20〜25%)は未解決として残す。**新規**: source 1([[@2013__SOSP__Do Not Blame Users for Misconfigurations]]) + entity 3([[Yuanyuan Zhou]]・[[Shankar Pasupathy]]・[[NetApp]]) + concept 1([[設定ミス脆弱性]])。**更新**: [[設定マイニング]]・[[Tianyin Xu]]・[[Ding Yuan]]。 2026-06-27: **OTel-Arrow Phase 2 ingest** — OTel-Arrow ブログ記事([[@2026__OTelBlog__OTel-Arrow-Phase-2]])を wiki 化。Apache Arrow のカラム型フォーマットをテレメトリパイプラインの内部表現として全域維持する Phase 2 構想。OTel-Arrow Dataflow Engine（DFE）は NUMA フレンドリー・スレッド-パー-コア・シェアドナッシングアーキテクチャで、単一コア OTAP パスが 2.47M logs/sec（OTLP 121K の 20 倍）。16 コアで 14.6 倍のスケーリング。Phase 1（OTAP ワイヤプロトコル）→ Phase 2（パイプライン内部表現）への進化で「デコード→オブジェクトウォーク→アロケーション→エンコード」の反復コストを排除。**新規**: source 1 + concept 2([[OTel-Arrow]]・[[OTAP]]) + entity 1([[Apache-Arrow]])。**更新**: [[OpenTelemetry]]。 2026-06-27: **OpenTelemetry 6 ソース一括 ingest** — OBI（eBPF 計装）ドキュメント・HTTP ヘッダエンリッチメント・GenAI オブザーバビリティ・Collector フォローアップサーベイ・日本コミュニティサーベイ・ログ重複排除プロセッサの 6 ソースを wiki 化。**OBI** は Grafana Beyla 後継の eBPF ベース[[ゼロコード計装]]ツールで、9 言語 × 8 プロトコル × 6 DB + GenAI プロバイダ（OpenAI・Anthropic・Gemini・Bedrock・Qwen）をアプリ変更なしに計装。HTTP ヘッダエンリッチメント（v0.7.0）でスパンにテナント ID を付与しインシデント影響範囲を高速特定。**GenAI セマンティック規約**は `invoke_agent` → `chat` / `execute_tool` のスパン階層で LLM 呼び出しチェーンを標準化。VS Code Copilot・OpenAI Codex・Claude Code が OTel テレメトリを送出。**Collector 調査**（2025）: 65% が 10 台超を本番運用（+10%）、VM 51%（+18%）でハイブリッド化、設定管理（63%）と安定性（52%）が最優先改善領域。**日本調査**: 61% が本番運用、NPS +49、トレース 93% で最多シグナル（メトリクス首位の国際パターンと乖離）、Go のエバリュエーション→プロダクション移行率が最大。**ログ重複排除プロセッサ**: ハッシュで同一ログを集約し `log_count` と時間範囲を保持（サンプリングと異なりデータ非破棄）。**新規**: source 6 + entity 1([[OBI]]) + concept 3([[ゼロコード計装]]・[[GenAI オブザーバビリティ]]・[[ログ重複排除]])。**更新**: [[OpenTelemetry]]・[[eBPF]]・[[オブザーバビリティ]]・[[テレメトリ]]。 2026-06-27: **マイクロサービス RCA/FL 10 論文一括 ingest** — 根本原因分析・障害箇所特定の 10 論文を並列 wiki 化。**(1) Cloud Atlas** ([[@2024__arXiv__Cloud Atlas - Efficient Fault Localization for Cloud Systems using Language Models and Causal Insight]]): Zhiqiang Xie ほか(Stanford/CMU/Microsoft Research)。LLM でシステム文書から因果グラフを自動合成し障害箇所特定。手動構築と同等精度で構築コストを削減。**(2) Chain-of-Event** ([[@2024__FSE__Chain-of-Event - Interpretable Root Cause Analysis for Microservices through Automatically Learning Weighted Event Causal Graph]]): Zhenhe Yao ほか(清華/CAS/eBay)。マルチモーダル観測データをイベントに変換し重み付きイベント因果グラフで解釈可能な RCA。SRE の運用知見を直接モデルパラメータに統合。**(3) IRLLS** ([[@2024__KDD__Microservice Root Cause Analysis with Limited Observability]]): 限定観測可能性下の潜在空間介入認識による RCA(既存ページ更新)。**(4) HeMiRCA** ([[@2024__TOSEM__HeMiRCA - Fine-Grained Root Cause Analysis for Microservices with Heterogeneous Data Sources]]): Zhouruixing Zhu ほか(CUHK-Shenzhen/CUHK)。トレースとメトリクスの異種データ間の異常認識単調相関を発見し Spearman 相関で階層的 RCA。サービスレベル top-1 82.7%、メトリクスレベル 74%。**(5) MicroIRC** ([[@2026__Elsevier__MicroIRC - Instance-level Root Cause Localization for Microservice Systems]]): Yuhan Zhu ほか(武漢大学/CSIRO)。インスタンスレベル粒度の GNN ベース RCA。呼び出しグラフ+メトリクスグラフの二重グラフ構造。**(6) RCA Outliers** ([[@2025__NeurIPS__Root Cause Analysis of Outliers with Missing Structural Knowledge]]): Orchard ほか(Cambridge/MPI/Amazon)。因果グラフ未知の単一サンプル RCA の理論的保証。ポリツリー構造で周辺異常スコアのみで RCA 可能。**(7) RCInvestigator** ([[@2026__TVCG__RCInvestigator - Towards Better Investigation of Anomaly Root Causes in Cloud Computing Systems]]): Shuhan Liu ほか(Zhejiang/Microsoft)。人間-機械協調型 RCA 可視分析。ビルド→モニタリング→推論→結論の 4 段階ワークフロー。**(8) GrayScope** ([[@2024__FSE__Illuminating the Gray Zone - Non-Intrusive Gray Failure Localization in Server Operating Systems]]): Shenglin Zhang ほか(南開/清華/Huawei)。グレー障害を非侵入的に箇所特定。専門知識と因果学習の融合。AC@5 90%。**(9) SynthoDiag** ([[@2024__FSE__SynthoDiag - Fault Diagnosis for Test Alarms in Microservices through Multi-source Data]]): Shenglin Zhang ほか(南開/Huawei Cloud/清華)。テストアラーム多ソース障害診断。障害分類+箇所特定の二段階。**(10) MicroDig** ([[@2024__TSC__MicroDig - Diagnosing Performance Issues for Large-Scale Microservice Systems With Heterogeneous Graph]]): Lei Tao ほか(南開/清華/Tencent)。異種グラフで因果関係と呼び出し関係の不一致を考慮した性能障害診断。**横断的知見**: RCA が「LLM 因果グラフ自動合成(Cloud Atlas)」「イベント変換+SRE 知見統合(CoE)」「異種データ間単調相関(HeMiRCA)」「インスタンスレベル粒度(MicroIRC)」「理論的保証(RCA Outliers)」「人間協調可視分析(RCInvestigator)」「グレー障害(GrayScope)」「テストアラーム(SynthoDiag)」「異種グラフ(MicroDig)」と多軸に展開。**新規**: source 9 + entity 10 + concept 3([[テスト障害診断]]・[[情報理論的異常スコア]]・[[単一サンプルRCA]])。**更新**: source 1([[@2024__KDD__Microservice Root Cause Analysis with Limited Observability]]) + entity 15 + concept 9。 2026-06-27: **AIOps RCA/FI/OpsQA 7 論文一括 ingest** — 障害箇所特定・診断・テスト環境 RCA・OpsQA に関する 7 論文を並列 wiki 化。**(1) G-Cause** ([[@2024__ICWS__G-Cause - Parameter-free Global Diagnosis for Hyperscale Web Service Infrastructures]]): Xinrui Jiang ほか(清華大学/Huawei Cloud)。ハイパースケール Web 基盤のパラメータフリー全体診断。因果グラフと障害伝播モデル。**(2) FaultInsight** ([[@2024__KDD__FaultInsight - Interpreting Hyperscale Data Center Host Faults]]): Tingzhu Bi ほか(Microsoft/Tsinghua)。ハイパースケール DC のホスト障害を解釈可能に診断。**(3) LoFI** ([[@2024__ISSRE__LoFI - Demystifying and Extracting Fault-indicating Information from Logs for Failure Diagnosis]]): Zhihan Jiang ほか(CUHK/WeBank)。ログからの障害指示情報抽出、スパン予測モデル。**(4) iKnow** ([[@2025__ASE__iKnow - an Intent-Guided Chatbot for Cloud Operations with Retrieval-Augmented Generation]]): Guangba Yu ほか(SYSU/CUHK)。意図誘導型クラウド運用 RAG チャットボット。**(5) SparseRCA** ([[@2024__ISSRE__SparseRCA - Unsupervised Root Cause Analysis in Sparse Microservice Testing Traces]]): Zhenhe Yao ほか(清華/Ant Group/CAS/ByteDance)。テスト環境の疎トレースに対する教師なし RCA。排他レイテンシ分解 + パーソナライズド PageRank で A@1=66.1%, A@5=88.1%。**(6) Interventional Causal** ([[@2024__DSN-S__Fault Localization Using Interventional Causal Learning for Cloud-Native Applications]]): Saurabh Bagchi ほか。介入的因果学習による障害箇所特定、CausalBench 提案。**(7) ResilienceGuardian** ([[@2024__ISSRE__Guardian of the Resiliency - Detecting Erroneous Software Changes Before They Make Your Microservice System Less Fault-Resilient]]): Guanglei He ほか。障害耐性劣化変更の事前検知。**横断的知見**: テスト環境の疎トレースでは統計メトリクスベース因果発見が破綻し排他レイテンシ分解が有効(SparseRCA)。ハイパースケール基盤ではパラメータフリー診断(G-Cause)が有効。**新規**: source 7 + entity 16 + concept 6([[障害注入]]・[[運用障害分析]]・[[介入的因果学習]]・[[障害耐性劣化変更検知]]・[[OpsQA]]・[[RAGベースクラウド運用支援]])。**更新**: [[根本原因分析]]。 2026-06-27: **PreServe ICSE 2026 ingest** — [[Zhihan Jiang]] ほか(CUHK/Microsoft)。LMaaS プラットフォーム向け階層的予測ベース管理フレームワーク PreServe を wiki 化([[@2026__ICSE__PreServe - Intelligent Management for LMaaS Systems via Hierarchical Prediction]])。**核心**: (1) **Service Workload Predictor**: mLSTM で 10 分先読みの token 密度時系列予測(MAE 0.064、最大 APE 24.4%)。(2) **Request Load Predictor**: DistilBERT + プロンプトチューニングでリクエスト単位の応答長を予測(Accuracy 73.2%)。BERT 比 60% 高速。(3) **Load Anticipator**: per-instance の KV メモリ使用量先読みマップを次 l=100 イテレーション分維持。(4) **Proactive Instance Scaler**: ワークロード予測 + 先読みマップで先行インスタンス起動(コールドスタート数十〜数百秒を吸収)。(5) **Load-aware Request Router**: $L_i = L^p_i + L^d_i + \beta \times L^m_i$ で 3 成分合算スコアにより最適インスタンスへ振り向け。**評価**: vLLM/ShareGPT ベンチマーク、各種 LLM(DeepSeek-R1 等)。最先端比 P99 正規化 E2E レイテンシ 41.3% 削減、リソース消費 49.38% 削減。**横断的知見**: LLM コールドスタート問題がマイクロサービス管理の常識(反応的スケーリング)を無効化する。リクエスト応答長の広大な分布(5〜632 トークン)がルーティングにも予測が必要な根拠となる。**新規**: source 1([[@2026__ICSE__PreServe - Intelligent Management for LMaaS Systems via Hierarchical Prediction]]) + concept 1([[LLMサービング管理]])。**更新**: [[LLM推論]]・[[Zhihan Jiang]]・[[Yujie Huang]]・[[Guangba Yu]]・[[Junjie Huang]]・[[Jiazhen Gu]]・[[Michael R. Lyu]]。 2026-06-27: **障害箇所特定・根本原因分析 11 論文一括 ingest** — FL/RCA の 2019〜2025 研究 11 本を並列 wiki 化。**(1) LogInsight** ([[@2025__nkcs.iops.ai__Accurate and Interpretable Log-Based Fault Diagnosis using Large Language Models]]): Yongqian Sun ほか(Nankai/Tsinghua/CMCC/ZTE)。DBSCAN+TF-IDF 二段ログ圧縮(FOLS)+LoRA ファインチューニングで GPT-4 直接適用を上回る障害診断・説明文生成。**(2) BSODiag** ([[@2025__arXiv__BSODiag - A Global Diagnosis Framework for Batch Servers Outage in Large-scale Cloud Infrastructure Systems]]): Tao Duan ほか(Xi'an Jiaotong/Alibaba Cloud)。3 モーダル(アラート・インシデント・変更)時空間グラフ RCA + 障害伝播パス推論。**(3) COCA** ([[@2025__arXiv__COCA - Generative Root Cause Analysis for Distributed Systems with Code Knowledge]]): Yichen Li ほか(CUHK)。静的解析でログ→コード行対応付け+ICFG 実行パス再構築で、監視データなしのイシューレポート設定で RCACopilot 比 Exact Match +28.3%。**(4) RADICE** ([[@2025__arXiv__RADICE - Causal Graph Based Root Cause Analysis for System Performance Diagnostic]]): Andrea Tonon ほか(Huawei Ireland)。PCMCI++部分ドメイン知識+エントロピー方向付けで因果サブグラフを出力。**(5) Causal Discovery** ([[@2025__AAAI Workshop AICT__Causal Discovery for Cloud Microservice Architectures]]): Christopher Lohse ほか(IBM Research)。PCMCI+で「コールグラフの逆向き≠レイテンシグラフ」を実証。**(6) DéjàVu** ([[@2022__ESEC FSE__Actionable and Interpretable Fault Localization for Recurring Failures in Online Service Systems]]): Zeyan Li ほか(清華/Microsoft)。障害ユニット(コンポーネント×メトリクスグループ)粒度で再帰障害の行動可能な箇所特定。**(7) FL-AIer** ([[@2025__TOSEM__Making Fault Localization in Online Service Systems More Actionable and Interpretable]]): Ke Xv ほか(Dalian Maritime)。多層 GAT+重み付き KL 損失で DéjàVu を A@1 +9.24% 改善。**(8) UniDiag** ([[@2024__TSC__No More Data Silos - Unified Microservice Failure Diagnosis With Temporal Knowledge Graph]]): Shenglin Zhang ほか(Nankai/Tsinghua)。時系列→状態種別変換で TKG に格納、3 モダリティ異種性を解消する第四の融合路線。**(9) SLIM** ([[@2024__ASE__SLIM - A scalable and interpretable light-weight fault localization algorithm for imbalanced data in microservice]]): Rui Ren ほか(Alibaba DAMO)。DNF ルールセット+劣モジュラ最適化で二重不均衡の箇所特定。**(10) LasRCA** ([[@2024__ASE__The Potential of One-Shot Failure Root Cause Analysis - Collaboration of the Large Language Model and Small Classifier]]): Yongqi Han ほか(Tongji/Di-Matrix)。LLM を高混乱サンプルラベラーに限定し小型分類器と協調、全ベースライン超の精度。**(11) FaaSRCA** ([[@2024__arXiv__FaaSRCA - Full Lifecycle Root Cause Analysis for Serverless Applications]]): Jin Huang ほか(Sun Yat-sen)。サーバーレス関数の短命性に対し Global Call Graph+GAT オートエンコーダでライフサイクル段階単位 RCA。**横断的知見**: FL/RCA が「単一モダリティ→マルチモーダル」「ランキング→因果サブグラフ」「教師あり→ワンショット/教師なし」「マイクロサービス限定→サーバーレス/クラウドインフラ/DB」へ多軸拡大。コード知識(COCA)・TKG(UniDiag)・障害ユニット(DéjàVu)など問題粒度の再定義が主要貢献パターン。**新規**: source 11 + entity 30+ + concept 9。**更新**: [[Fault Localization]]・[[根本原因分析]]・[[因果発見]]・[[因果推論ベースRCA]]・[[LLMによる根本原因分析]]・[[マルチモーダル障害診断]]・[[グラフベースRCA]]・[[サービス依存グラフ]]・[[マイクロサービスコールグラフ]]・[[サーバーレスアーキテクチャ]]・[[ドメイン別RCA]] ほか。 2026-06-27: **YAPC::Fukuoka 2025 スライド ingest「SREのためのテレメトリー技術の探究」** — [[坪内佑樹]]（[[さくらインターネット研究所]]）による YAPC::Fukuoka 2025 ゲストセッション（2025-11-14）を wiki 化（[[@2025__YAPC Fukuoka 2025__SREのためのテレメトリー技術の探究]]）。69 ページ全画像確認、副素材さくらのナレッジ記事で補完。**核心**: テレメトリー技術を 12 年間一貫して探究した個人史を 5 章構成で展開。(1) テレメトリーの歴史と位置づけ（1960 年代制御工学→2025 年 LLM オブザーバビリティ）、(2) モニタリング SaaS 開発（[[Mackerel]]: Perl/SNMP→Graphite→AWS サーバーレス時系列 DB）、(3) 博士研究（[[Scaling Telemetry Workloads]]: [[HeteroTSDB]] / eBPF ネットワークコールグラフ / [[MetricSifter]]）、(4) 今後の探究 4 方向（テレメトリー界の SDGs = collect-first → use-first / AI for SRE = SRE 特化マルチモーダル基盤モデル / Observability for AI Systems = GPU クラスタ可観測性・HPE Clusterview・GPU ゼロコード計装 3 層 / Controllability = SLI 自律制御）、(5) まとめ（ポップカルチャーと学術の狭間でアウトプットの積み重ねにより思索を深める）。**新規 source 1**。**更新**: [[坪内佑樹]]（YAPC 登壇歴追記）・[[さくらインターネット研究所]]（さくら ONE・TOP500 49 位追記）・[[テレメトリ]]（テレメトリー年表史の横断的知見追記）・[[Scaling Telemetry Workloads]]（コアコンセプト抽出の思考過程の横断的知見追記）・[[SREの工学化]]（ポップと学術の狭間の横断的知見追記）・[[GPU観測性]]（GPU ゼロコード計装 3 層整理の横断的知見追記）。代表スライド画像 11 枚を `wiki/sources/_attachments/yapcfukuoka2025-telemetry-for-sre/` に配置。 2026-06-27: **データベース異常診断・RCA 8 論文一括 ingest** — DB 異常診断と根本原因分析の 8 論文を並列 wiki 化。**(1) SDN** ([[@2025__ICDE__Anomaly Diagnosis with Siamese Discrepancy Networks in Distributed Cloud Databases]]): Lingsen Yan ほか(Huazhong/Huawei/HKUST)。シャムネットワークで正常-異常乖離パターンを学習し、少数ショットで異なるクラスタにも汎化する異常診断。**(2) AutoDebugger** ([[@2025__AIDB__AutoDebugger - Efficient Root Cause Analysis for Anomaly Jobs]]): Fathelrahman Ali ほか(Google/Microsoft)。Microsoft Fabric の Spark ジョブ異常にホワイトボックス予測+ML で RCA を 10 倍高速化。**(3) RCRank** ([[@2025__VLDB__RCRank - Multimodal Ranking of Root Causes of Slow Queries in Cloud Database Systems]]): Biao Ouyang ほか(ECNU/Alibaba Cloud/Aalborg)。スロークエリの根本原因をクエリ文・実行計画・ログ・KPI の 4 モダリティでランキング。**(4) Vista** ([[@2023__Amazon Science__Vista - Machine Learning based Database Performance Troubleshooting Framework in Amazon RDS]]): Vikramank Singh ほか(AWS/MIT)。Amazon RDS の検知→RCA→解決 3 段パイプライン。**(5) FSE 2023** ([[@2023__FSE__Adapting Performance Analytic Techniques in a Real-World Database-Centric System]]): Lizhi Liao ほか(Waterloo)。データベース中心システムの性能分析技法適応に関する産業経験報告。**(6) BALANCE** ([[@2023__PACMMOD__BALANCE - Bayesian Linear Attribution for Root Cause Localization]]): Chaoyu Chen ほか(Ant Group/OceanBase)。XAI 帰属を RCA に適用、BMFS+帰属分析+KPI マージ。**(7) GRANO** ([[@2019__VLDB__GRANO - Interactive Graph-based Root Cause Analysis for Cloud-Native Distributed Data Platform]]): Hanzhang Wang ほか(eBay)。NuData 向けグラフベース RCA。**(8) ExplainIt!** ([[@2019__SIGMOD__ExplainIt! - A Declarative Root-cause Analysis Engine for Time Series Data]]): Vimalkumar Jeyakumar ほか(Cisco Tetration)。SQL ライクな宣言的 RCA エンジン。**横断的知見**: RCA の入力モダリティが単一指標→トポロジ+指標→マルチモーダル統合と 2019→2025 に拡大。産業展開では 3 段パイプライン(Vista)やベイズ帰属(BALANCE)で解釈性を確保。DB 中心アーキテクチャでは従来技法の直接適用困難(FSE 2023)。**新規**: source 8 + entity 20+ + concept 4([[Sparkジョブ異常診断]]・[[グラフベースRCA]]・[[宣言的RCA]]・[[データベース性能トラブルシューティング]])。**更新**: [[根本原因分析]]・[[異常検知]]・[[データベース自律診断]]・[[データベース O&M]]・[[マルチモーダル障害診断]]・[[帰属手法]]・[[Fault Localization]]・[[AIOps]]・[[Interactive AIOps]]・[[仮説駆動RCA]]・[[因果発見]]・[[サービス依存グラフ]] ほか多数。 2026-06-27: **The Morning Paper on Operability ingest** — [[Adrian Colyer]]（Accel、元 Pivotal/VMware CTO）による blog.acolyer.org 講演記事([[@2016__blog.acolyer__The Morning Paper on Operability]])を wiki 化。The Morning Paper で 400+ 論文をレビューした知見から、[[オペラビリティ]]（運用性）に関する研究を 4 段階モデルに構成: (1) 運用性のための設計（Hamilton の「80% は設計に起因」）、(2) システム挙動の理解（Dapper / Mystery Machine / Gorilla / lprof / Pivot Tracing）、(3) 根本原因の分離（Failure Sketching / Delta Debugging / HDD / DEMi）、(4) 開発へのフィードバック統合（FDD）。Cook の「How Complex Systems Fail」を普遍的助言として引用。先ほど ingest した 6 論文（[[@2014__OSDI__The Mystery Machine - End-to-end Performance Analysis of Large-scale Internet Services]]、[[@2015__SOSP__Failure Sketching - A Technique for Automated Root Cause Diagnosis of In-Production Failures]]、[[@2002__IEEE TSE__Simplifying and Isolating Failure-Inducing Input]]、[[@2006__ICSE__HDD - Hierarchical Delta Debugging]]、[[@2016__NSDI__Minimizing Faulty Executions of Distributed Systems]]、[[@2015__Onward!__Runtime Metric Meets Developer - Building Better Cloud Applications using Feedback]]）すべてがこの 4 段階枠組みに位置づけられ、相互参照が密に成立した。**新規**: source 1 + entity 1([[Adrian Colyer]]) + concept 1([[オペラビリティ]])。 2026-06-26: **SREcon22 APAC 動画 ingest「Introducing the Reliability Map – r9y.dev」** — [[Aaron Bowden]]（Google Cloud Professional Services SRE Practice Lead JAPAC）による SREcon22 APAC（2022-12-08、シドニー）講演([[@2022__SREcon22 APAC__Introducing the Reliability Map – r9y.dev]])を wiki 化。YouTube 自動生成字幕（1090 行）と 12 代表フレームを根拠に作成。**核心**: SRE 導入支援の現場から「どのケイパビリティを次に取得するか」のロードマップが存在しないという問題提起。**提案**: オープンソースプロジェクト [[Reliability Map (r9y.dev)]]（`map.r9y.dev`）——ゲームの「テック・ツリー」（Civilization 等）に着想を得た SRE ケイパビリティの依存関係マップ。各ケイパビリティカードは (1) What & Why、(2) 採用/構築/購入、(3) 前提ケイパビリティ の3要素を持つ。**核心主張3点**: (1) ベストプラクティスはコンテキスト依存——コンテキスト不理解のままの適用はカーゴカルティング。(2) プラットフォームはソシオテクニカル——技術スタックだけでなくチーム・プロセスも含む。(3) マップは2種の洞察を提供——「今日何をするか（戦術）」と「再設計を防ぐロードマップ（戦略）」。**結論**: 01. 信頼性は広大な空間——大きな地図が必要。02. 「9の数字を買う」は無理——ジャーニーである。03. 迷ったらマップを参照して次の一手を踏み出せ。**SRE Book / Workbook との位置づけ**: SRE Book は「何を信じるか」の原則体系、SRE Workbook は「どう実装するか」、Reliability Map は「どのケイパビリティを次に取得するか」のギャップを埋める。**新規**: source 1([[@2022__SREcon22 APAC__Introducing the Reliability Map – r9y.dev]]) + entity 1([[Aaron Bowden]]) + concept 1([[Reliability Map (r9y.dev)]])。**更新**: [[SRE]]（コンテキスト抽出とケイパビリティ選択順序の横断的知見追記）。代表フレーム画像 7 枚を `wiki/sources/_attachments/srecon22apac-bowden-reliability-map/` に配置。 2026-06-26: **SRE NEXT 2023「エンジニアのためのSRE論文への招待」スライド ingest** — [[坪内佑樹]]による SRE NEXT 2023 IN TOKYO 講演を wiki 化([[@2023__SRE NEXT 2023__エンジニアのためのSRE論文への招待]])。**核心**: マネージドサービス・OSS・SaaS の普及で SRE が自ら周辺技術を開発する機会が相対的に減る中、未普及技術論文を「新しい技術を実装・適用したいエンジニア」のアイデア源として捉える。[[SRE論文]]は学術的な確立分類ではなく、ソフトウェア工学・信頼性工学・システム・ネットワーク・データベース・クラウドに散在する論文を探索する発表者独自の実務上の呼称である。**探索**: 国際会議のプログラム、Google Scholar・Connected Papers、引用・被引用関係を併用し、SRE Book の引用を起点にする経路と、ソフトウェア工学・信頼性・クラウド会議を巡回する経路を使い分ける。**読解**: 探索時はタイトル・要約・図表を速読し、実装・適用時は Introduction・実験条件・結果・実装可能性を精読する。**記録**: 未普及技術の固有文脈と論文間の関係を保つため、論文ノートと地図を作る。**新規**: source 1 + concept 1([[SRE論文]])。**更新**: [[坪内佑樹]]・[[SRE NEXT]]。全35ページ画像確認済み。YouTube 録画は音声原本を保存したが、文字起こしは未生成のため根拠には使用していない。代表スライド5枚を添付。 2026-06-26: **SRE NEXT 2022「AIOps研究録―SREのためのシステム障害の自動原因診断」ingest** — [[坪内佑樹]]（[[さくらインターネット研究所]]）による SRE NEXT 2022 ONLINE 発表を wiki 化([[@2022__SRE NEXT 2022__AIOps研究録―SREのためのシステム障害の自動原因診断]])。**核心**: AIOps を障害管理とリソース割当の二領域として整理し、サービス全体の症状を SLO でアラートし、メトリクス・ログ・トレース・イベントは別系統の原因診断へ渡す「Alert symptoms, diagnose causes」を提示。[[TSifter]] は障害検知後に全メトリクスを削減して因果グラフ生成へ接続する前処理構想である。形状クラスタリングは SBD + 最短距離法の階層的クラスタリングを採用するが、コンポーネントをまたぐ集約は因果グラフの必要ノードを失いうる。PC アルゴリズムも、障害時の類似変動が多い条件付き独立性検定で原因と症状の経路を誤削除しうる。**横断的知見**: [[因果推論ベースRCA]] に入力削減を境界設計として追記し、[[時系列クラスタリング]] に因果ノードを落とさない運用制約を追加。最終スライドの「AI が認知処理を自動化する一方、AI という別種の複雑なソフトウェアを運用する」という問いを [[自動化の皮肉]] へ接続。**新規**: source 1 + entity 1([[TSifter]])。**更新**: [[坪内佑樹]]・[[Meltria]]・[[AIOps]]・[[因果推論ベースRCA]]・[[時系列クラスタリング]]・[[自動化の皮肉]]。全 54 ページ画像確認、YouTube 日本語自動字幕で背景を補完（固有名詞の根拠には不使用）。 2026-06-26: **デバッギング・性能解析・フィードバック 6 論文一括 ingest** — デルタデバッギング系譜(ddmin/dd→HDD→DEMi)と性能解析・障害診断・開発フィードバックの 6 論文を wiki 化。**(1) Delta Debugging** ([[@2002__IEEE TSE__Simplifying and Isolating Failure-Inducing Input]]): [[Andreas Zeller]] と Ralf Hildebrandt による IEEE TSE 2002 論文。ddmin（障害誘発入力の 1-最小簡略化、最悪 O(n²)、最良 O(log n)）と dd（1-最小障害誘発差分の分離）の 2 アルゴリズムを提案。GCC 755→77 文字、Mozilla 896 行→1 行、95 操作→3 操作に簡略化。**(2) HDD** ([[@2006__ICSE__HDD - Hierarchical Delta Debugging]]): [[Ghassan Misherghi]]・[[Zhendong Su]]（UC Davis）。ddmin を木構造入力に拡張し、入力の構文木をレベルごとに ddmin 適用。平坦な ddmin 比でテスト回数を桁違いに削減。CSS 96,000 文字→subsequent 簡略化で有効性実証。**(3) Mystery Machine** ([[@2014__OSDI__The Mystery Machine - End-to-end Performance Analysis of Large-scale Internet Services]]): [[Michael Chow]]・[[David Meisner]]・[[Jason Flinn]]・[[Thomas F. Wenisch]]（Michigan / Facebook）による OSDI 2014 論文。既存トレーシング（Dapper / X-Trace）の計装負担なしに、UberTrace ログから因果関係を仮説検証で推定。クリティカルパス・slack 解析でページロード遅延 300ms 以上削減。**(4) Failure Sketching** ([[@2015__SOSP__Failure Sketching - A Technique for Automated Root Cause Diagnosis of In-Production Failures]]): [[Baris Kasikci]]・Benjamin Schubert・[[George Candea]]（EPFL）。Gist は本番障害の協調解析でハードウェアウォッチポイントを活用し 2.4% オーバーヘッドで failure sketch（近似ルートコーズ）を自動生成。11 実バグ中 8 件を完全診断。**(5) FDD** ([[@2015__Onward!__Runtime Metric Meets Developer - Building Better Cloud Applications using Feedback]]): [[Jürgen Cito]]・[[Philipp Leitner]]・[[Harald C. Gall]]（UZH）。フィードバック駆動開発ビジョン。ランタイムメトリクスを IDE に統合し performance-awareness gap を埋める。**(6) DEMi** ([[@2016__NSDI__Minimizing Faulty Executions of Distributed Systems]]): [[Colin Scott]]・Aurojit Panda・[[Scott Shenker]]（UC Berkeley）。デルタデバッギングを分散実行に拡張。外部イベント（障害注入）と内部イベント（メッセージ送受信）の区別 + スケジュール探索で Raft/Spark/Akka の 7 バグで実行イベント 1〜2 桁削減。**横断的知見**: (1) [[デルタデバッギング]]にて ddmin→HDD→DEMi の「汎用→構造化→分散化」系譜と、テスト精度/最小化結果のトレードオフを整理。(2) [[障害スケッチング]]は「テスト不可能な本番障害」への相補的手法として位置づけ。(3) [[フィードバック駆動開発]]は今日の DevOps・SRE パイプラインの先駆。**新規**: source 6 + entity 15 + concept 5([[デルタデバッギング]]・[[階層的デルタデバッギング]]・[[障害スケッチング]]・[[フィードバック駆動開発]]・[[分散実行最小化]])。代表図合計 14 枚を各 source の `_attachments/` に配置。 2026-06-26: **ソフトウェア信頼性工学 2 論文 ingest（Lyu 2007 / Cusick 2019）** — クラシカルなソフトウェア信頼性工学（SRE）のロードマップと 50 年通史を wiki 化。**(1) Lyu 2007** ([[@2007__FOSE__Software Reliability Engineering - A Roadmap]]): [[Michael R. Lyu]]（[[The Chinese University of Hong Kong]]）による FOSE'07 サーベイ・ロードマップ。障害ライフサイクル 4 技法（予防・除去・耐性・予測）と SRE プロセス 4 構成要素（信頼性目標・操作プロファイル・信頼性モデリング・信頼性検証）を体系化。100 以上の SRGM の存在を概観し、将来方向 5 軸（アーキテクチャ・Design for Reliability・テスト・メトリクス・新興アプリケーション）を提示。産業採用の障壁（コスト効果の不透明さ、モデル過剰選択肢への実務者の困惑）も率直に指摘。PyMuPDF でベクター図 2 枚（SRE プロセス全体図・コードカバレッジ比較表）をクロップ。**(2) Cusick 2019** ([[@2019__arXiv__The First 50 Years of Software Reliability Engineering - A History of SRE with First Person Accounts]]): [[James J. Cusick]] による科学史視点の 50 年通史。1968 年 NATO 会議→ Hudson (1967) 最初のモデル→ Jelinski-Moranda/Shooman (1971)→ Musa の実行時間モデルと "Software Reliability Engineering" 造語(1975)→ 体系化(Musa 著書 1987, Lyu ハンドブック 1996)→ モバイル/アジャイル/DevOps への展開。[[Norman F. Schneidewind]]・[[John Musa]] への未発表インタビュー(2006 年実施)を初公開。**横断的知見**: (1) [[ソフトウェア信頼性工学]] にて Lyu 2007 の共時的体系化と Cusick 2019 の通時的展開を並べ、理論→体系化→新領域の 3 段階発展を可視化。(2) [[SREの工学化]] にてクラシカル SRE（開発フェーズの障害予測）と Google 由来 SRE（運用フェーズの SLO 制御）の名称未収束の経緯と接続点を追記。**新規**: source 2 + entity 5([[James J. Cusick]]・[[John Musa]]・[[Norman F. Schneidewind]]・[[Martin L. Shooman]]・[[ISSRE]]) + concept 2([[ソフトウェア信頼性工学]]・[[ソフトウェア信頼性成長モデル]])。**更新**: [[Michael R. Lyu]](Cusick 2019 からの ISSRE 創設・ハンドブック記録追記)・[[SREの工学化]](横断的知見・出典追加)・[[ソフトウェア耐障害性]]・[[Design for Reliability]]。代表図: Lyu 2 枚(SRE プロセス概要・コードカバレッジ表)、Cusick 3 枚(メトリクス制御チャート・理想信頼性モデル・信頼性と故障強度)。 2026-06-26: **SREcon23 EMEA スライド ingest「From Sysadmins to (almost) Flying Unicorns」** — [[Guillaume Hérail]]・[[Gilberto Müller]]（[[Sony Interactive Entertainment]]、Future Technology Group、ベルリン）による SREcon23 EMEA（2023-10-10、ダブリン）講演([[@2023__SREcon23 EMEA__From Sysadmins to (almost) Flying Unicorns]])を wiki 化。64 ページ全画像読了。**核心**: SIE PlayStation Cloud Gaming チームが 2018 年頃から 5 つの課題（トイル過多・フィードバックループ外・アラート過多・信頼性軽視・SRE ビジョン不在）を段階的に解消した実践報告。**5 施策**: (1) **TOS（Technical Operations Support）** — 割り込みを吸収する新職種。食品業界出身者など多様なバックグラウンドを許容したエントリーレベルポジション。p.26 の図が示すように Interruptions → TOS → SRE の 2 段フィルターで SRE を自動化・オブザーバビリティ・レジリエンシーへ解放した。(2) **SRE Academy**（通称「ユニコーン工場」）— TOS から SRE へのキャリアパス。既にビジネス・チーム知識を持つ TOS を速成転換し、外部採用困難を組織内育成で代替。(3) **CFT（クロスファンクショナルチーム）** — SRE が設計段階（Team A/B/SRE の三者ループ）に参加することでフィードバック遅延を短縮。Before（p.11）は SRE がループ外で設計への戻りルートが"?"、After（p.34）は設計段階三者ループ。さらに Dev/RelEng/SRE の協働により Pre-production サイクルが「Months」→「Minutes」に短縮（p.36）。(4) **SLO + 専任担当者** — SRE 時間配分 CFT 80% / 機能チーム 20%（p.41 円グラフ）。横断的イニシアチブには専任アサインが必要。(5) **Reliability Meetup** — 月次 2 名登壇（SRE + 非 SRE）、2.5 年間 22 回、46 名登壇（うち非 SRE 23 名）、600+ 名参加（p.50）。SRE のビジョン策定は 2023 年時点で Staff SRE 間の連携と Sr Leadership への提示を目標に進行中（p.56）。**成功要因 4 つ**（p.62）: Executive Support・IC/Management Pairing・Fail iterate・Communicate!。**横断的知見**: [[SRE]] に「設計フェーズ参加と割り込み吸収の構造化」を追記（SRE Book Ch29/Ch32 の実装事例として位置づけ）。**新規**: source 1 + entity 3([[Guillaume Hérail]]・[[Gilberto Müller]]・[[Sony Interactive Entertainment]]) + concept 1([[SRE組織変革]])。**更新**: [[SRE]]（横断的知見に SIE 事例追記）。代表スライド画像 7 枚を `wiki/sources/_attachments/srecon23emea-herail/` に配置。 2026-06-26: **データベース/分散システム異常診断 6 論文一括 ingest** — Peking University・Tsinghua University・Alibaba・MIT CSAIL の 6 論文を一括 wiki 化。分散データベース・ストレージの異常診断を監視データ・アプリケーションログ・Raft ログの 3 軸で体系化。**(1) iSQUAD** ([[@2020__PVLDB__Diagnosing Root Causes of Intermittent Slow Queries in Cloud Databases]]): Minghua Ma ほか。クラウド DB の間欠的遅延クエリ(iSQ)——外部要因で発生し通常のスロークエリとは異なる——の根本原因診断。異常抽出・依存性クレンジング・TOPIC クラスタリング・ベイズ事例モデルの 4 段構成で Alibaba OLTP Database にて F1 80.4% 達成。**(2) OSprey** ([[@2024__arXiv__OS Pre-trained Transformer - Predicting Query Latencies across Changing System Contexts]]): Negi ほか(MIT CSAIL)。OS メトリクス時系列をトランスフォーマーで事前学習し、ワークロード固有効果とシステム固有効果を因子分解。1 システムでの訓練で複数 AWS インスタンスタイプへ汎化、中央値・平均誤差で既存手法の最大 3 倍改善。**(3) MultiLog** ([[@2024__KDD__Multivariate Log-based Anomaly Detection for Distributed Database]]): Lingzhe Zhang ほか(Peking U)。分散 DB 初のマルチノードログ異常検知データセット(Apache IoTDB)。単一ノードログでは偽陽性が高く不十分であることを実証し、マルチノード統合で既存手法を約 12% 上回る。**(4) DBPA** ([[@2023__PACMMOD__DBPA - A Benchmark for Transactional Database Performance Anomalies]]): Shiyue Huang ほか(Peking U / ZTE)。OLTP 性能異常 9 種(ロック競合・インデックス欠損・バキューム不足・過負荷等)の決定論的再現手順を体系化したベンチマーク。XGBoost/LightGBM が DBSherlock 比で精度 +20pt・速度 5,000 倍であることを実証し、ML 診断のデータ不足ボトルネックを浮き彫りに。**(5) LogDB** ([[@2025__arXiv__LogDB - Multivariate Log-based Failure Diagnosis for Distributed Databases]]): MultiLog 拡張版。ノード単位ログ特徴抽出・圧縮 + マスターノード集約で異なるワークロード・異常タイプにロバストな障害診断。**(6) RBAD** ([[@2025__IEEE TSC__Towards Close-To-Zero Runtime Collection Overhead - Raft-Based Anomaly Diagnosis on System Faults for Distributed Storage System]]): Lingzhe Zhang ほか(Peking U)。Raft コンセンサスログを異常診断に活用——収集オーバーヘッドほぼゼロでモニタリングベース手法 +15.38%・ログベース手法 +53.10%。**横断的知見**: (1) [[異常検知]] にデータベース/分散ストレージ領域の 3 軸(監視メトリクス・アプリログ・Raft ログ)の進展を追記。Raft ログはコンセンサスプロトコルの副産物として粒度と低コストを両立する新データソース。(2) [[データベース自律診断]] に DBPA ベンチマークが「訓練データ不足→ベンチマーク化」という ML 診断の直交課題を解決する知見を追記。(3) MultiLog/LogDB は iSQUAD を引用しており、iSQ 概念が後続のマルチノードログ分析研究の動機付けとして機能。**新規**: source 6 + entity 5([[iSQUAD]]・[[Tim Kraska]]・[[OSprey]]・[[Apache IoTDB]]・[[RBAD]]) + concept 5([[間欠的遅延クエリ]]・[[クエリレイテンシ予測]]・[[ログベース異常検知]]・[[データベース性能異常ベンチマーク]]・[[Raftログ診断]])。**更新**: [[異常検知]]・[[データベース自律診断]]・[[分散ストレージ]]・[[Minghua Ma]]・[[Dan Pei]]・[[Shenglin Zhang]]・[[Lingzhe Zhang]]・[[Tong Jia]]・[[Ying Li]]・その他 entity 多数。代表図合計 26 枚を各 source の `_attachments/` に配置。 2026-06-26: **arXiv:2508.08906 Ultra Ethernet 論文 ingest** — Torsten Hoefler ほか 15 名（ETH Zürich・Broadcom・HPE・OpenAI・Intel・AMD・Cisco・Microsoft）による Ultra Ethernet 1.0 設計解説論文([[@2025__arXiv__Ultra Ethernet's Design Principles and Architectural Innovations]])を wiki 化。**核心**: UE は 2022〜2025 年の 30 か月でAMD・Broadcom・HPE・Intel・Microsoft が主導した次世代高性能 Ethernet 標準(UEC 1.0、562 ページ)。最大の貢献は Ultra Ethernet Transport(UET)という新トランスポートプロトコルで、(1) エントロピー値(EV)による ECMP パケットスプレー(トラフィック偏極を防止)、(2) Packet Delivery Context(PDC)のゼロ RTT 確立(最初のパケットから全速送信)、(3) 4 モード(RUD/ROD/UUD/RUDI)の配送保証・順序保証の組み合わせ、(4) NSCC(ECN+RTT 組み合わせ)と RCCC(受信クレジット型)の 2 輻輳制御アルゴリズム、(5) AES-GCM-256 ゼロトラスト TSS セキュリティ、(6) LLR・CBFC のリンク層拡張機能を定義する。**設計哲学**: 「Moore の法則により 25 年で計算コストが 100,000 分の 1 になった一方帯域は 100 倍増——ビットあたりの計算が 1,000 倍使えるようになった」ことで、SACK・パケットスプレー・ゼロ RTT というかつて高コストな機構がシリコンで合理的になった。**横断的知見追加**: [[RDMA]]（UE 1.0 が RoCE 3 大設計欠陥(PFC/Go-back-N/経路固定)に正面回答した旨と設計論文の初公開を追記）、[[RoCE設計課題]](UE による各問題の解消状況・未解決の問いを更新)。[[Torsten Hoefler]](UEC 主導者としての記録追加)。**新規**: source 1([[@2025__arXiv__Ultra Ethernet's Design Principles and Architectural Innovations]]) + concept 1([[Ultra Ethernet]])。**更新**: [[RDMA]]・[[RoCE設計課題]]・[[Torsten Hoefler]]。代表図 4 枚を `wiki/sources/_attachments/arxiv-2508.08906/` に配置。 2026-06-26: **How Complex Systems Fail (Cook 1998) ingest** — [[Richard I. Cook]]（Cognitive Technologies Laboratory, University of Chicago）による 1998 年古典論考を wiki 化([[@1998__CtL__How Complex Systems Fail]])。**核心**: 複雑システムにおける障害の本質を 18 の命題で体系化。(1) 複雑システムは本質的に危険で潜在的障害を常に内包し、劣化モードで稼働する（命題 1〜5: [[潜在的障害]]）。(2) 破滅には複数障害の組み合わせが必要——「単一根本原因」は存在しない（命題 3・7）。(3) 「根本原因」帰属は技術的理解でなく社会的・文化的な責任帰属の必要性を反映する（命題 7: [[根本原因分析]] への根本的批判）。(4) ヒンドサイトバイアスが事後の人間パフォーマンス評価を歪め、事故調査の主要障害となる（命題 8: [[ヒンドサイトバイアス]]）。(5) 安全性はシステムの創発的特性——特定の人・デバイス・部門に宿るのでなく、人間の瞬時の適応によって動的に生成される（命題 16・17）。(6) 人間は複雑システムの適応的要素（命題 12）——[[自動化の皮肉]]（Bainbridge 1983）と相補し「自動化が進むほど人間能力が重要になるがそれが失われる」という二重のジレンマを確認。**横断的知見**: (1) Cook 命題 7 は AIOps・SRE が「根本原因分析」という用語を標準として使い続けることへの根本的問い直し。HolisticRCA 3 次元定式化・JustDiag 仮説競合裁定・mABC 多エージェント投票は「複数寄与因子の同定」への移行として再解釈できる。(2) [[Metastable Failure]]（SREGym）は Cook 命題 3・4・5 の具体化——劣化モードのシステムが過渡的トリガと潜在的インフラ制約の組み合わせで崩壊する。(3) [[なめらかなシステム]]（三宅 DICOMO2018/2025）の「利用者・情報システム・開発運用者が継続的に相互影響する総体」と命題 12・17 が共鳴。**新規**: source 1([[@1998__CtL__How Complex Systems Fail]]) + entity 1([[Richard I. Cook]]) + concept 3([[複雑システム障害論]]・[[潜在的障害]]・[[ヒンドサイトバイアス]])。**更新**: [[根本原因分析]](Cook 命題 7 横断的知見追加)・[[Metastable Failure]](潜在的障害論接続)・[[自動化の皮肉]](Cook 命題 12・17 相補性追加)。 2026-06-26: **とあるSREの博士「過程」スライド ingest** — [[坪内佑樹]]（[[さくらインターネット研究所]]、京都大学博士(情報学)）による SRE NEXT 2025 IN TOKYO（2025-07-11）講演([[@2025__SRE NEXT 2025__とあるSREの博士「過程」]])を wiki 化。SpeakerDeck 83 ページ全画像読了 + YouTube 日本語自動字幕で口頭説明を補完。**核心**: SRE として博士課程に進学した動機(「技術を使う側から作る側になりたい」→ CS は難しいが運用を含むエンジニアリングなら「作る」側になれる)、3 つの個別研究(①[[HeteroTSDB]] 時系列 DB アーキテクチャ、②Transtracer eBPF NW コールグラフ計装、③[[MetricSifter]] AIOps 特徴量削減)を "Scaling Telemetry Workloads" として体系化した経緯、メンタルモデルの転換(Before「作る側になりたい」→ After「積み重ねていきたい」)、生成 AI 時代における博士課程の意義(知的労働の積み重ね感覚の実存的重要性)を語った。SRE NEXT 2024「工学としての SRE 再訪」→ IOTS2025「サイバネティクスの夢」→ SRE NEXT 2025「博士『過程』」の**講演三部作の完結篇**。前 2 作が SRE 分野をどう再構築するかを示すのに対し、本講演はその思考をどう獲得したかという個人的基盤を開示した。**新規**: source 1([[@2025__SRE NEXT 2025__とあるSREの博士「過程」]])。**更新**: [[坪内佑樹]](博士課程の知的系譜追記)・[[SRE NEXT]](2025 年セクション追加)・[[SREの工学化]](三部作完結篇・生成 AI 時代の問いを横断的知見・未解決の問いに追記)。代表スライド画像 12 枚を `wiki/sources/_attachments/srenext2025/` に配置。 2026-06-26: **SONiC Scale-Up WG スライド ingest** — [[海老澤健太郎]]（[[Arrcus]]）による SONiC Workshop Japan 2026 講演([[@2026__SONiC Workshop Japan 2026__SONiC Scale-Up Working Group から探る Scale-Up や Ultra Ethernet 機能の実装方法]])を wiki 化。**核心**: SONiC Scale-Up WG（2025-04 発足、Alibaba・Microsoft・Broadcom・NVIDIA 等 13 社参加、約 30 回会合）の技術報告。Scale-Up/Out/Across の 3 層分類と、RoCEv2・UE Transport・Falcon v1.1・MRC の 4 方式 12 軸比較表（p.6）が中心。RoCEv2 のみがロスレス前提・Go-Back-N・OoO 非対応であり、残り 3 方式はパケットロス許容・SACK・パケット粒度マルチパスを共通採用。SONiC/SAI が UE spec v1.0.2 に基づき LLR・CBFC・LLDP を実装中。Alibaba NVL72 事例では DeepSeek-V3 推論が 14.76ms→0.82ms に 18 倍短縮。**新規**: source 1 + entity 2([[海老澤健太郎]]・[[Arrcus]])。**更新**: [[RDMA]]（RoCEv2 対次世代 4 方式比較の横断的知見追記、Hoefler+ 2023 の予測に対する進捗更新）・[[オープンネットワーキング]]（SONiC の Scale-Up 拡張の横断的知見追記）。代表スライド画像 6 枚を添付。 2026-06-26: **LLM Wiki (Karpathy Gist) enrich** — 2026-06-19 の ingest 済みソースを full gist 再読で強化。**核心追加**: (1) "Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase" メタファーが未収録だったため追記。(2) ユースケース 5 カテゴリ（個人・研究・読書・ビジネス・競合分析）・index.md vs log.md 役割分担・qmd/Obsidian Web Clipper/Marp/Dataview ツール推奨を追加。(3) Tolkien Gateway の fan wiki 比喩——"読書しながら千ページのファン wiki を個人で構築できる"——を [[LLM Wikiパターン]] に追記。**新規**: entity 1([[Memex]]——`[[Memex]]` リンクが実体なし状態だったため作成、Bush-Wiener-Karpathy 系譜を整理)。**更新**: [[@2026__GitHub Gist__LLM Wiki]]・[[LLM Wikiパターン]]。 2026-06-26: **再帰化への認知的転回 + なめらかなシステムと運用維持の終わらぬ未来 スライド ingest** — [[三宅悠介]]（[[GMOペパボ]]）のスライド 2 本を一括 wiki 化。(1) ペパボテックカンファレンス(2022): [[再帰化]]——「関数の設計から系の設計への認知的転回」を定式化し[[なめらかなシステム]]の実装方向を具体化。(2) DICOMO2025 招待講演: なめらかなシステムを 7 年ぶりに再定義（仮）。τέλος(目的)は固定的に与えられるものではなく利用者との関係の中で事後的に形成されるという前提に転換。[[エフェクチュエーション]]（起業研究の非予測的コントロール）を導入し「主体から関係性へ」の視座転換。4 構成要件（創発性・接続性・非斉一性・動的意味構成支援）を概念レベルで提示。エージェント層は命令の中継ではなく意味の翻訳と関係性の媒介を担う。**新規**: source 2 + concept 2([[再帰化]]・[[エフェクチュエーション]])。**更新**: [[なめらかなシステム]](DICOMO2025 再定義・4 構成要件・再帰化接続)・[[基礎情報学]](HACS 再評価)・[[セルフクラフト]](再帰化との補完)・[[三宅悠介]](博士(情報科学) 2024 九州大学)。代表スライド画像 11 枚を添付。 2026-06-26: **なめらかなシステムを目指して (DICOMO2018) 論文 ingest** — [[栗林健太郎]]・[[三宅悠介]]・[[Ryosuke Matsumoto]](GMOペパボ ペパボ研究所)による DICOMO2018 論文([[@2018__DICOMO2018__なめらかなシステムを目指して]])を wiki 化。**核心**: [[なめらかなシステム]]の**一次出典論文**。(1) コンテキスト・アウェアネス(利用者固有コンテキストの織り込み)と (2) 基礎情報学の HACS(コンテキストの事後的形成)を統合し、「ユーザー・情報システム・開発運用者が継続的に相互影響する総体」としてのシステム観を定義した。ICT は単なる媒介ではなく独立した自律的主体として位置づけられる(基礎情報学の図 2 との相違)。開発運用者もユーザーと対称的に「利用者」と定義することで SRE 的な発展可能性を内包した設計。具体研究: minne 類似画像商品検索(コンテキスト深化)、ロリポップ！リクエスト単位リソース制御(コンテキスト精緻捕捉)。AI・IoT 時代のシンボル・グラウンディング問題への対処としても「なめらかなシステム」が必要と結論。**新規**: source 1([[@2018__DICOMO2018__なめらかなシステムを目指して]]) + entity 1([[栗林健太郎]]) + concept 2([[コンテキスト・アウェアネス]]・[[基礎情報学]])。**更新**: [[なめらかなシステム]](定義・横断的知見・未解決の問いを大幅拡充)・[[三宅悠介]]・[[Ryosuke Matsumoto]]・[[GMOペパボ]]・[[サイバネティクス]]。代表図 3 枚(fig01 HACS 基本構造・fig02 情報システム概要・fig03 なめらかなシステム概要)を添付済み。 2026-06-26: **SREはサイバネティクスの夢をみるか (IOTS2025) スライド ingest** — [[坪内佑樹]]（[[さくらインターネット研究所]]、京都大学博士）による IOTS2025 招待講演([[@2025__IOTS2025__SREはサイバネティクスの夢をみるか]])を wiki 化。SpeakerDeck 137 ページ全画像読了 + Q&A を含む講演 transcript で口頭説明を補完。**核心**: SRE を[[サイバネティクス]]的に再解釈し、フィードバックループ・セカンドオーダー(観測者がシステムの一部)・創発の 3 概念で利用者・情報システム・開発運用者の総体を捉えるモデルを提示。信頼性の歴史(HW→SW→Internet→Cloud)から SRE 定義(*Becoming SRE*)、3 ブラックボックスモデル、[[世界の再魔術化]]を経由し、博士論文のテレメトリスケーリング 3 貢献(①eBPF フローバンドリング CPU≤2.2%、②[[HeteroTSDB]] 3.98x スループット、③[[MetricSifter]] +4.5% 精度)を「計測→保存→分析」3 層で俯瞰。[[自動化の皮肉]](Bainbridge 1983)で完全自動化への安易な期待を牽制し、[[なめらかなシステム]](DICOMO2018/三宅 DICOMO2025)と[[セルフクラフト]](DICOMO2022)で AI エージェント時代の SRE 像を展望した。Q&A では機能別 SLO 設定、モビリティ SLI(車両稼働率)を実務例として言及。**新規**: source 1 + entity 2([[坪内佑樹]]・[[さくらインターネット研究所]]) + concept 2([[自動化の皮肉]]・[[なめらかなシステム]])。**更新**: [[サイバネティクス]]・[[セルフクラフト]]・[[テレメトリ]]・[[特徴量削減]]・[[Fault Localization]]・[[サービスレベル目標]]・[[HeteroTSDB]]・[[MetricSifter]]・[[三宅悠介]]。代表スライド画像 14 枚を `wiki/sources/_attachments/iots2025_presentation/` に配置。 2026-06-26: **Demystifying NCCL (arXiv 2507.04786) 論文 ingest** — [[Zhiyi Hu]]・[[Siyuan Shen]] ほか([[ETH Zürich]] SPCL・[[NVIDIA]]・Broadcom)による arXiv 2025 論文([[@2025__IEEE__Demystifying NCCL - An In-depth Analysis of GPU Communication Protocols and Algorithms]])を wiki 化。**核心**: NCCL 2.19.1 の内部設計を体系的に解析し、「ブラックボックス」とされてきた集合通信ライブラリの三つの設計レイヤーを初めて文書化。(1) **プロトコル層**: Simple(~6µs/hop・ほぼピーク帯域)、LL(~1µs/hop・25-50% 帯域、flag-based ゼロコピー)、LL128(~2µs/hop・~95% 帯域、NVLink で 128B アトミック書き込み必須)の三分法。LL128 は NVLink 以外(PCIe 等)では自動無効化される。(2) **データ転送層**: ノード内 P2P は NVLink > PCIe > SHM の優先順位で自動選択。P2P_DIRECT は同一プロセス内限定で FIFO バッファコピーを排除する中間最適化モード。ノード間は Socket(ホストメモリ経由)または IB Verbs(GPUDirect RDMA、マルチチャネル QP、forward+reverse QP レイアウト)。(3) **集団アルゴリズム層**: Ring AllReduce は ReduceScatter(k-1 ステップ)+ AllGather(k ステップ)= 2k-1 ステップ(k=ノード数)。Tree AllReduce は SM を 2 グループに非対称分割しパイプライン化。**ATLAHS**: NCCL 解析を基盤とするネットワークシミュレーションツールチェーン。集団通信を計算・送信・受信の細粒度イベントに分解し GOAL スケジュール化することで、CSCS Alps GH200 16 ノード (Cray Slingshot) ベンチマークと誤差 5% 未満の一致を達成。**横断的知見**: (1) [[集合通信]] に「NCCL プロトコル非対称性(ノード内外での最適プロトコルの違い)」「Ring 2k-1 ステップ構造が Mycroft トレース・VCCL SM-free 設計の共通前提」を追記。(2) 新規 entity: [[ATLAHS]]・[[Siyuan Shen]]・[[Zhiyi Hu]]。**更新**: [[NCCL]]・[[Torsten Hoefler]]・[[集合通信]]。PDF(arxiv-2507.04786.pdf)全 13 ページ読了、代表図 5 枚(fig01 ノード内転送・fig02 ノード間転送・fig04 Ring AllReduce・fig05 Tree AllReduce・fig06 ベンチマーク)クロップ済み。 2026-06-26: **VCCL arXiv 2026 論文 ingest** — [[Mingjun Zhang]]・Xiaohe Hu ほか([[Infrawaves]] / [[Beihang University]] / [[Tsinghua University]])による arXiv 2026 論文([[@2026__arXiv__An Efficient, Reliable and Observable Collective Communication Library in Large-scale GPU Training Clusters]])を wiki 化。**核心**: VCCL は NCCL を置き換える大規模 GPU 訓練向け集合通信ライブラリで、三つの独立した機構を組み合わせる——(1) **SM-free P2P**: CPU スレッド+コピーエンジンにより GPU カーネル起動をゼロにし SM 占有を完全排除。`cuStreamWriteValue`/`cuStreamWaitValue` で GPU-CPU 同期とストリーム依存を制御。非リダクション系 P2P 操作の訓練スループットが平均 4.00%・最大 5.28% 向上。(2) **プライマリバックアップ QP**: NIC ポート障害時に receiver 側がバックアップ QP への切り替えを主導（受信側起動）。SyncFifo でプライマリ・バックアップ間の状態同期、ブレークポイント再送でデータロス防止。ジョブ再起動・チェックポイントなしで GPU 待機時間約 90% 削減。(3) **スライディングウィンドウ型 RDMA モニタ**: WR/WC タイムスタンプを集積しスライディングウィンドウ内の平均スループットを O(μs) 粒度で推定。「帯域 < 直近平均の 50% かつ RtS データ > 過去最大の 2 倍」という双閾値で NIC ポート異常を検知しプライマリバックアップ QP 切り替えをトリガー。24K GPU 本番クラスタで三機構すべてを展開済み。**横断的知見**: (1) [[集合通信]] に「SM をゼロにする」二系統——NCCLX(CTran: 大幅削減)と VCCL(P2P: 完全ゼロ)——の対比と、「CCL 内蔵 O(μs) モニタが Mycroft/Pulse と異なる CCL 自己計装の軸を開く」を追記。(2) [[耐障害LLM訓練]] に「CCL 層での NIC 障害透過的吸収」を ByteRobust/FlashRecovery とは異なる第四の耐障害系統として追記。(3) [[RDMAネットワーク監視]] に「CCL 自己計装という外部計装不要の四番目の計装軸」を追記。**新規**: source 1([[@2026__arXiv__An Efficient, Reliable and Observable Collective Communication Library in Large-scale GPU Training Clusters]]) + entity 1([[Mingjun Zhang]]) + figures 6枚(fig01/03/04/09/11/13)。**更新**: [[Infrawaves]]・[[Menghao Zhang]]・[[集合通信]]・[[耐障害LLM訓練]]・[[RDMAネットワーク監視]]。PDF(arxiv-2510.00991.pdf)全 15 ページ読了。 2026-06-26: **OSDI 2025 TrainCheck 論文 ingest** — [[Yuxuan Jiang]]・[[Peng Huang]] ら([[University of Michigan]] [[OrderLab]])による OSDI 2025 論文を wiki 化([[@2025__OSDI__Training with Confidence - Catching Silent Errors in Deep Learning Training with Automated Proactive Checks]])。**核心**: [[TrainCheck]] は DL 訓練のサイレントエラー——損失・精度には現れず最終的に不正なモデルを生成するバグ——を**訓練不変条件**の自動推論・継続検証で検知するフレームワーク。モンキーパッチングで DL フレームワーク API を計装し、サンプル訓練パイプラインから 5 種の関係テンプレート(Consistent・EventContain・APISequence・APIArg・APIOutput)と**前提条件**を自動推論し、対象パイプラインの実行中に違反をリアルタイム検知する。前提条件付き不変条件は異なるパイプラインへ転用可能——PyTorch 固有不変条件の 23% が 16 以上のパイプラインに適用可能。BLOOM-176B の事例では 2-GPU 実行から大規模分散訓練の不変条件を導出。**主要成績**: 20 件の実世界サイレントエラーのうち 18 件を 1 イテレーション以内に検知(ベースライン合計 2〜3 件)、DeepSpeed・Accelerate から 6 件の未報告バグを発見(うち 3 件修正済み)、偽陽性率 2% 以下、選択的計装のオーバーヘッド通常 2% 以下。**DL 特化の洞察**: DL 訓練の非決定性は観察の粒度が高すぎるから生じる——損失・精度の粒度では不変条件が書けないが、重みの整合性・API 呼び出し順序の粒度では決定的な規則が書ける。[[Heisenbug]] の「観察によって消える」概念を「観察の粒度の選択が検知可能性を規定する」として DL 訓練ドメインに再解釈した点が新規性の核心。**横断的知見**: (1) [[DLトレーニングサイレントエラー]] を新規 concept として作成——根本原因の所在(ユーザーコード 32%・フレームワーク 32%)と検知困難性を体系化。(2) [[訓練不変条件]] を新規 concept として作成——観察粒度と自動推論・転用可能性の設計空間を整理。(3) [[Heisenbug]] に「DL 訓練サイレントエラーは観察粒度の問題として Heisenbug を再解釈する」横断的知見を追記。**新規**: source 1([[@2025__OSDI__Training with Confidence - Catching Silent Errors in Deep Learning Training with Automated Proactive Checks]]) + entity 4([[Yuxuan Jiang]]・[[Peng Huang]]・[[TrainCheck]]・[[OrderLab]]) + concept 2([[DLトレーニングサイレントエラー]]・[[訓練不変条件]])。**更新**: [[University of Michigan]]・[[Heisenbug]]。PDF 全 18 ページ読了、代表図 8 枚をクロップ・添付済み。 2026-06-25: **SREcon23 EMEA Symptom-based Alerting for ML スライド ingest** — [[Lina Weichbrodt]]（ML フリーランス・コンサルタント、元 [[Zalando SE|Zalando]] シニアリサーチエンジニア・元 DKB リード ML エンジニア）による SREcon23 EMEA（Dublin, 2023-10-10）発表を wiki 化([[@2023__SREcon23 EMEA__Symptom-based Alerting for Machine Learning]])。**核心**: 30 以上の ML ユースケースの本番運用経験から、SRE の症状ベースアラーティング——原因でなくエンドユーザーの痛みに着目する——を ML サービスに転用するフレームワークを提示。ML リクエストシーケンスの出力側から逆順に 3 段階の監視優先度を割り当てる: (1) **Priority 1: ユーザー影響**（本番評価メトリクスの算出・ステークホルダー懸念のメトリクス化）、(2) **Priority 2: サービス応答分布**（D1 距離・KS 統計量・PSI で出力分布変化を検知。ヒューリスティック品質指標で代用可）、(3) **Priority 3: 入力/特徴量データ分布**（出力アラートの根本原因分析用。訓練-サービング間スキューのみ Priority 1 に格上げ）。ML 固有のサイレント障害（入力単位変更・データ欠損・フィルタドリフト・劣化モデル自動リリース等）はバックエンド監視では検知されず、「恒久的でサイレントな損失であり大半のモデル改善より金銭的影響が大きい」。MLOps プラットフォームの入力分布アラートが対処不能な[[アラート疲労]]を引き起こす事例も報告。既存スタック（Prometheus・Grafana）で始めることを推奨。**横断的知見**: (1) [[アラート管理]] に「症状ベースアラーティングの ML ドメイン転用は出力から逆順に優先するフレームワークを生んだ」を追記。(2) [[アクショナブルアラート]] に「ML サイレント障害は従来のアクショナブルアラートの射程外であり、出力品質メトリクスの追加で対処する」を追記。(3) [[アラート疲労]] に「ML 監視の入力データドリフトアラートが IT 運用と同一構造の疲労を再現し、監視対象の優先順位付けによるノイズ回避が第四の介入軸となる」を追記。**新規**: source 1([[@2023__SREcon23 EMEA__Symptom-based Alerting for Machine Learning]]) + entity 1([[Lina Weichbrodt]]) + concept 1([[MLモデル監視]])。**更新**: [[アラート管理]]・[[アクショナブルアラート]]・[[アラート疲労]]。YouTube 自動字幕（英語）で口頭説明を補完、全 37 ページ画像確認済み。 2026-06-24: **OncallX ASE 2025 論文 ingest** — [[Ruowei Fu]]・[[Shenglin Zhang]]（[[Nankai University]]）/ Yang Zhang・[[ByteDance]] ほかによる ASE 2025 論文 [[@2025__ASE__LLM-Powered Multi-Agent Collaboration for Intelligent Industrial On-Call Automation]] を wiki 化。**核心**: [[OncallX]] は LLM × マルチエージェント協調でオンコールエンジニア(OCE)の業務全体を自動化するエンド・ツー・エンドシステム。3 モジュール構成——(1) **ユーザー意図強化**: RAG でドメイン知識を検索し ClarifyAgent が多ターン対話でユーザー意図を精緻化、(2) **木探索マルチエージェント QA**: OCEAgent が木探索で実行計画を生成し KernelAgent・VirtualAgent・CompileAgent・NetworkAgent・OSAgent・FirmwareAgent が専門実行 + Reflection で自己修正、(3) **KG 拡張チケットトリアージ**: 履歴チケットから Neo4j KG を構築し TriageAgent が多ラウンド Reflection で分類。ByteDance STE チーム（OS カーネル・仮想化・ファームウェア）への 2 か月本番投入で対応 21 秒（手作業 0.58 人日比 **789 倍高速**）・トリアージ 4 秒（200 秒比 **50 倍高速**）を達成。**横断的知見**: (1) [[オンコール自動化]] を新規作成——エンド・ツー・エンドの OCE 自動化として初の産業事例。(2) [[マルチエージェント協調]] に木探索プランナー+専門エージェント設計がコンテキスト長限界の中で ReAct を上回る事例を追記。(3) [[LLMによる根本原因分析]] にオンコール QA が RCA より広い問題設定で LLM 協調が有効との知見を追記。**新規**: source 1([[@2025__ASE__LLM-Powered Multi-Agent Collaboration for Intelligent Industrial On-Call Automation]]) + entity 2([[Ruowei Fu]]・[[OncallX]]) + concept 1([[オンコール自動化]])。**更新**: [[Shenglin Zhang]]・[[ByteDance]]・[[Nankai University]]・[[マルチエージェント協調]]・[[LLMによる根本原因分析]]・[[インシデント管理]]。 2026-06-24: **ClickHouse PVLDB 2024 論文 ingest** — [[Robert Schulze]] ほか（[[ClickHouse Inc|ClickHouse Inc.]]）による PVLDB Vol.17 2024 年論文 "ClickHouse - Lightning Fast Analytics for Everyone" を wiki 化（[[@2024__PVLDB__ClickHouse - Lightning Fast Analytics for Everyone]]）。**核心**: ClickHouse は 2009 年にウェブログ分析向けに始まり 2016 年 OSS 化されたカラム型 OLAP データベースで、ペタバイト規模・高インジェスト率・サブ秒レイテンシを単一 C++ バイナリで実現する。**ストレージ層 (MergeTree*)**: 全パートを階層なし等価に扱うフラット構造が従来 LSM との最大の違い。グラニュール（8192 行）単位のスパース主キーインデックス・プロジェクション・3 種スキッピングインデックスによる積極的なデータプルーニング。バックグラウンドマージによる置換/集計/TTL 変換でインジェストを止めず歴史データを削減。**クエリ実行**: SIMD/コア/ノードの 3 レベル並列化 + ベクトル化実行 + LLVM コードコンパイル。ハッシュテーブルは 30 以上の実装から実行時選択。**ベンチマーク**: ClickBench（100M 行、43 クエリ）で本番グレード全 DB 中冷温最速。VersionsBench で 6 年間に 1.72 倍改善。**横断的知見**: (1) [[LSMツリー]] に「フラット等価パート構造と WAL レス直書き」を追記。(2) [[列指向OLAPデータベース]] を新規作成。**新規**: source 1 + entity 4 ([[ClickHouse]] / [[ClickHouse Inc|ClickHouse Inc.]] / [[Robert Schulze]] / [[Alexey Milovidov]]) + concept 1 ([[列指向OLAPデータベース]])。**更新**: [[LSMツリー]]。 2026-06-23: **SREcon18 Americas Automatic Metric Screening スライド ingest** — [[Yu Chen (Baidu)]]（[[Baidu]] SRE チームデータアーキテクト、元 [[Microsoft Research Asia]]）による SREcon18 Americas（Santa Clara, 2018-03-29）発表を wiki 化([[@2018__SREcon18 Americas__Automatic Metric Screening for Service Diagnosis]])。**核心**: サービス障害診断で多数のメトリクスを手動確認する問題に対し、ゴールデンメトリクス設定に依存しない自動メトリクススクリーニングを提示。障害前 60 分と障害後 5 分を比較し、KDE による上振れ/下振れ確率を対数確率で結合、同一モジュール×データセンター内のインスタンスを DBSCAN でクラスタリングし、インスタンス比率・異常メトリクス数・異常度でダイジェストを順位付けする。70 件の履歴ケースで 60 件の根本原因ダイジェストを top 1 に出し、手動診断平均 35 分に対し実行時間 6 分以下。**横断的知見**: (1) [[Fault Localization]] に FluxRank 論文化前の実務向け箇所特定パターンとして追記。(2) [[RCA入力選別]] に LLM 以前の統計的入力選別として追記。(3) [[特徴量削減]] にゴールデンメトリクス設定負荷を削る動機を追加。**新規**: source 1。**更新**: [[Yu Chen (Baidu)]]・[[Baidu]]・[[Fault Localization]]・[[RCA入力選別]]・[[特徴量削減]]。音声保存済み、transcript 未生成、全 15 ページ画像確認済み。 2026-06-23: **SREcon17 Americas Practical Monitoring and Alerting スライド ingest** — [[Jamie Wilkinson]]（[[Google]] SRE）による SREcon17 Americas（San Francisco, 2017-03-13）発表を wiki 化([[@2017__SREcon17 Americas__A Practical Guide to Monitoring and Alerting with Time Series at Scale]])。**核心**: 監視がつらくなる根本原因は、保守コストがサービス規模に比例して増えること。静的しきい値（ディスク 90%、残り 500MB）は容量差・ワークロード差で偽陽性を生むため、満杯までの時間と人間の修復時間、レイテンシ分布のバケット比率、SLO 違反へアラート条件を移す。Prometheus はサービス発見、`/metrics` スクレイプ、ラベル付き時系列、記録ルール、Alertmanager、TSDB、スクレイパーシャーディングを組み合わせ、`task:`→`dc:`→`global:` のようなトポロジ集約で監視設定を高水準抽象化する。**横断的知見**: (1) [[アラート管理]] に「静的しきい値を人間の対応時間とサービス目標へ変換する」観察を追記。(2) [[アクショナブルアラート]] にページ条件と診断情報の分離を追記。(3) [[サービスレベル目標]] に Wilkinson 2017 を SLO ベース呼び出しのデータ構造・運用分離の前段として追記。(4) [[ヒストグラムメトリクス]] に Prometheus 累積バケット比率によるレイテンシ割合アラートを初期例として追記。**新規**: source 1。**更新**: [[Jamie Wilkinson]]・[[Prometheus]]・[[アラート管理]]・[[アクショナブルアラート]]・[[サービスレベル目標]]・[[ヒストグラムメトリクス]]。transcript なし、全 82 ページ画像確認済み。 2026-06-23: **SREcon16 Europe Alerting for Distributed Systems スライド ingest** — [[Björn Rabenstein]]（[[SoundCloud]] Production Engineer / [[Prometheus]] 主要開発者の一人、元 [[Google]] SRE）による SREcon16 Europe（Dublin, 2016-07-12）発表を wiki 化([[@2016__SREcon16 Europe__Alerting for Distributed Systems - A Tale of Symptoms and Causes, Signals and Noise]])。**核心**: 分散システムでは原因と症状が緩く結合するため、ページは原因ではなくユーザーに近い症状や差し迫ったサービス問題に絞るべきである。ブラックボックス監視は進行中のユーザー症状に、ホワイトボックス監視は差し迫った問題と原因調査に向く。Prometheus 型の時系列ベース監視は、静的 85% ディスク閾値ではなく将来の枯渇見込みへページできる。ページ用の異常検知は単純・堅牢で、複雑な自動因果推定は原因調査・集約・ランキングへ分ける。**横断的知見**: (1) [[アラート管理]] に「症状へページし、原因は調査・チケットへ逃がす」分離を追記。(2) [[アクショナブルアラート]] に「全ページはアクショナブル」は症状ベース設計と対で成立する観察を追記。(3) [[Prometheusルールリント]] に、時系列アラート普及後にルール健全性保証が必要になる関係を追記。(4) [[サービスレベル目標]] に SLO ベース呼び出しの前史として、高レベルサービス目標へのアラートとコンポーネント調査グラニュラリティの分離を追記。**新規**: source 1 + entity 2([[Björn Rabenstein]]・[[SoundCloud]])。**更新**: [[Prometheus]]・[[アラート管理]]・[[アクショナブルアラート]]・[[Prometheusルールリント]]・[[サービスレベル目標]]。transcript なし、全 30 ページ画像確認済み。 2026-06-23: **SREcon16 Less Alarming Alerts スライド ingest** — [[Robert Treat]]（[[OmniTI]] CEO）による SREcon16 発表を wiki 化([[@2016__SREcon16__Less Alarming Alerts]])。**核心**: アラートはメトリクス・グラフ・通知メールと区別される「人を起こすページ」であり、各アラートはビジネス影響・修復手順・通知先・予防可能性を説明できなければならない。説明できないアラートは削除・通知化・修正の対象。OOM 事例では、OOM 自体をページするのでなく、検知・再起動・問題プロセス終了・ノード交換を自動化し、すべて失敗した場合だけページする設計を提示。**横断的知見**: (1) [[アラート管理]] に発火前ガバナンスとして追記——Runbook 合意やアラートバジェットの前史。(2) [[アクショナブルアラート]] に「ビジネス影響・修復手順・通知先・予防可能性」を最小チェックリストとして追記。(3) [[アラート疲労]] に偽陽性が応答性を壊す行動モデルを追加。**新規**: source 1 + entity 2([[Robert Treat]]・[[OmniTI]])。**更新**: [[アラート管理]]・[[アクショナブルアラート]]・[[アラート疲労]]。音声 MP3 保存済み、transcript は未反映、全 55 ページ画像確認済み。 2026-06-23: **SREcon17 Asia Draining the Flood — Alert Fatigue at Baidu スライド ingest** — [[Yu Chen (Baidu)]]（[[Baidu]] SRE チームデータアーキテクト）による SREcon17 Asia（2017 年 6 月、シンガポール）発表を wiki 化([[@2017__SREcon17 Asia__Draining the Flood - A Combat against Alert Fatigue]])。**核心**: Baidu の監視システム [[Argus (Baidu)|Argus]] は 1 人あたり 1 日 100 件超のアラートを送信し有効率 15% 未満。4 つの観察（重複率 58%・夜間アテンション率 25%・受信者平均 3 名・単一インスタンスアラート 88%）から 4 施策を導出——(1) リンガバッファ + アソシエーションルールマイニング + ネットワーク接続性検知の 3 層アラートグルーピング、(2) アテンション率（夜間の監視 UI アクセス・本番ログインを測定）に基づく 4 段階重要度キャリブレーション（Critical/Major/Warning/Notice）、(3) 段階的オンコールエスカレーション（固定ステージ → 時限エスカレーション）、(4) アラートトリガの自動修復（ログパージ・プロセス再起動、成功時は配信抑制）。4 施策の同時投入で **85% 削減**を達成（2015 年 5〜7 月に投入、2016 年 11 月まで持続）。マネジメント層の支援（重要度引き下げ推進・アテンション率を業務評価に組込み）が技術施策と不可分。**横断的知見**: (1) [[アラート管理]] に「Baidu Argus の 4 施策同時投入は AIM 分類の correlation/determination/mitigation を横断した最初期の産業統合事例」を追記。アテンション率は AlertRank の Resolution Record によるラベル付与を 3 年先行する着想。(2) [[アラート疲労]] に「技術的介入アプローチとインセンティブ設計アプローチが同年の SREcon で独立報告」を追記。(3) [[アラート集約]] に「リンガバッファ + アソシエーションルールマイニングは属性ベース集約と統計ベース集約の原始的組合せ」を追記。**新規**: source 1 + entity 1([[Argus (Baidu)]])。**更新**: [[Yu Chen (Baidu)]]・[[アラート管理]]・[[アラート疲労]]・[[アラート集約]]。transcript なし、全 20 ページ画像確認済み。 2026-06-23: **SREcon17 Americas Anomaly Detection in Infrequently Occurred Patterns スライド ingest** — [[Dong Wang]]（[[Baidu]] プリンシパルアーキテクト）による SREcon17 Americas（2017-03-14、San Francisco）発表を wiki 化([[@2017__SREcon17Americas__Anomaly Detection in Infrequently Occurred Patterns]])。**核心**: 中国の祝日（春節・端午節・中秋節）は太陰暦に基づき毎年日付が変動し、かつ低頻度のため訓練データが不足する。中央値補正・時間補正・Holt-Winters・BP NN の 4 手法がいずれも破綻した後、(1) 日次トラフィック CDF の k-means クラスタリング（K=3）で平日・週末・祝日を分離し、(2) リアルタイム比率補正で予測値を逐次調整する 2 段階手法を本番投入。2017 年 1 月 1 日のデプロイで良好な結果を確認。口頭 Q&A では、本手法が急激な変化に特化し緩やかな低下には別の閾値手法を併用すること、日のクラスタごとに異なる監視パラメータは使わずギャップの大きさで応答を変えることが補足された。**横断的知見**: [[異常検知]] に「低頻度かつ非固定日付の正常パターンに対する CDF クラスタリング＋リアルタイム比率補正」を追記——Chandola 2009 の文脈異常の変種に対し、クラスタリングで類似日を発見して正常プロファイルを構成する 2017 年の産業事例。Minder・RFT-FM の「正常は文脈相対」原理の最も初期かつ単純な実装。**新規**: source 1 + entity 2([[Dong Wang]]・[[Baidu]])。**更新**: [[異常検知]]。Whisper 文字起こしで口頭説明を補完、全 15 ページ画像確認済み。 2026-06-23: **SREcon17 Europe Over-Monitoring and Alert Fatigue スライド ingest** — [[Kishore Jalleda]]（Yahoo プロダクションエンジニアリング Sr. Director、元 [[Zynga]] SRE 責任者）による SREcon17 Europe（2017-08-30、Dublin）発表を wiki 化([[@2017__SREcon17 Europe__Want to Solve Over-Monitoring and Alert Fatigue - Create the Right Incentives]])。**核心**: 過剰なモニタリングと[[アラート疲労]]を、ツールの改善でなくインセンティブ設計で解決した事例。NOC 増員（1→13 名）やカラーコーディング等のツール対策が Zynga 月間 10 万件超のアラートに対して失敗した後、**Clean Room イニシアティブ**としてアラートバジェットを導入——予算超過チームの SRE サポートを停止し、遵守チームにワールドクラスの SRE サポートを提供するインセンティブ構造を構築。偽アラーム **90% 削減**、SRE 応答時間 **5 分**、可用性 "a whole nine" 向上を達成。組織変革の 4 ルール（障害を活用、味方を見つける、上司に警告、上級リーダーの賛同）とアラートノイズ削減の 2 軸（プロセス・文化 × ツール）を体系化。アラートの定義を「(1) 即座の対応が必要（15 分以内）、(2) 人間の知性を要する」の 2 条件に絞り、それ以外はログ・チケット・自動修復で処理すべきとした。**横断的知見**: (1) [[アラート管理]] にアラートバジェットによるインセンティブ設計を第三の介入軸として追加——Smith SREcon22 が指摘した「モニタリング増設 = 安全」の心理的抵抗をコスト構造の反転で構造的に無効化する介入。(2) [[アラートポリューション]] に心理的抵抗のインセンティブによる構造的無効化を横断的知見として追加。(3) [[アクショナブルアラート]] に Jalleda の「即座の対応 + 人間の知性」定義を運用者視点の最小定義として追加。**新規**: source 1 + entity 2([[Kishore Jalleda]]・[[Zynga]]) + concept 1([[アラート疲労]])。**更新**: [[アラート管理]]・[[アラートポリューション]]・[[アクショナブルアラート]]。transcript なし（yt-dlp 失敗）、全 61 ページ画像確認済み。 2026-06-23: **SREcon17 Europe Monitoring Cloudflare's Planet-Scale Edge Network 動画 ingest** — [[Matt Bostock]]（[[Cloudflare]] プラットフォームオペレーション）による SREcon17 Europe（Dublin, 2017-09-01）発表を wiki 化([[@2017__SREcon17 Europe__Monitoring Cloudflare's Planet-Scale Edge Network]])。**核心**: Cloudflare の 116 PoP エニーキャストエッジネットワーク（10% of internet requests、HTTP 500 万 req/s、DNS 120 万 req/s）の監視を Nagios から Prometheus へ移行した 18 か月の経験。各 PoP に独立した Prometheus を配置し、コアデータセンターへフェデレーションでメトリクスのサブセットを集約するアーキテクチャ。高可用性のため各 PoP 内で複数の独立 Prometheus インスタンスが同一サーバー群を並行スクレイプし、Alertmanager がゴシッププロトコルで通知を重複排除（通知漏れより重複を選択）。エクスポータ: Node exporter（システム）、Blackbox exporter（ネットワークプローブ）、mtail（ログマッチ）、cadvisor（コンテナ）。アラート設計原則: (1) 原因でなく症状にアラートする、(2) マシンでなくサービスにアラートする、(3) すべてが critical ではない、(4) 適切な通知チャネルを選ぶ。すぐに対応不要な問題は JIRA チケットに送信してバックログ管理。PagerDuty ドリルテスト（`ALERT SRE_Escalation_Drill`）でエスカレーションの動作確認を自動化。課題: Alertmanager 初期バージョンの不安定性、ヒストグラムでのファントムスパイク、self-inhibiting alert、カーディナリティ爆発。**横断的知見**: [[アラート管理]] に「症状ベースアラーティングの実践は 2017 年 Cloudflare 事例で既に組織的に推進」と追記。同一事業者内で 2017 年「症状ベース設計」→ 2022 年 [[pint]]「ルール健全性保証」への 5 年間の上流シフトを観察できる。**新規**: source 1 + entity 1([[Matt Bostock]])。**更新**: [[Cloudflare]]・[[Prometheus]]・[[アラート管理]]。YouTube 自動字幕(日本語翻訳)で口頭説明を補完、全 12 フレーム画像確認済み。 2026-06-23: **SREcon18 Asia Introduction to Alibaba Monitoring System 動画 ingest** — [[Ren Xinchi]]（[[Alibaba Group]] GOC シニアエンジニア）による SREcon18 Asia/Australia（2018-06-06）発表を wiki 化([[@2018__SREcon18 Asia__Introduction to Alibaba Monitoring System]])。**核心**: Alibaba の GOC は 4 層モニタリング構造（インフラストラクチャ → システム/アプリケーション → ビジネス → 顧客フィードバック）のなかで**ビジネス層を最重要**と位置づけ、独自 CMDB **[[Hammurabi]]** で各事業部のビジネス機能と KPI を P1〜P4 の優先度とともに登録する。**5 ゴールデンエレメント**（総数・成功数・成功率・応答時間・失敗数）でビジネス健全性を統合的に表現し、次元分析（IDC 別・エラーコード別）で障害を局所化する。変更情報のモニタリンググラフへの重ね合わせにより「障害の約 70% が変更起因」という前提で迅速なロールバック/フェイルオーバー判断を実現。インテリジェントモニタリングでアラーム精度 20%→80% 改善（詳細は別講演）。将来構想は Automation Dashboard → Broadcast Fault Location → Intelligent Decision の 3 段階。**横断的知見**: [[アラート管理]] に「ビジネス KPI の優先度定義を CMDB で一元管理する」介入点を追加——Yu+ JNCA2024 の alert determination を CMDB 側の事前定義で前倒しする設計で、AlertGuardian の rule refinement（ルール自体の改善）とは「ルールが参照するビジネス優先度の構造」管理として補完的。**新規**: source 1 + entity 2([[Ren Xinchi]]・[[Hammurabi]]) + concept 1([[ビジネスモニタリング]])。**更新**: [[Alibaba Group]]・[[アラート管理]]。YouTube 英語自動字幕で口頭説明を補完、全 12 フレーム画像確認済み。 2026-06-23: **Cloudflare Blog「Monitoring our Monitoring」ingest** — [[Cloudflare]] SRE チームによる 2022-05-19 公開ブログ記事を wiki 化([[@2022__Cloudflare-Blog__Monitoring-our-Monitoring]])。**核心**: Prometheus の alerting rule / recording rule は**有効な PromQL であっても静かに機能しなくなる**。メトリクス名のタイポ・廃止・ラベル変更・`rate()` 時間範囲不足のいずれも、Prometheus はエラーを出さず空の結果を返すだけ——「アラートが来ない」は「正常」か「壊れている」かを区別しない。この「監視の静かな失敗」を防ぐために Cloudflare が開発・OSS 公開したのが **[[pint]]**。3 動作モード: (1) `pint lint` — PromQL 静的解析、(2) `pint ci` — PR の変更行のみ検証、(3) `pint watch` — デーモンで定期検証し問題をメトリクス公開 → Prometheus 自身でアラート化(monitoring the monitoring)。**rate() の 2 点問題**: scrape interval 1 分のとき `rate(metric[1m])` は 1 データポイントのみ取得 → rate 計算不能 → アラート永遠に発火しない。**recording rule 連鎖**: 別チームが中間 recording rule を変名すると連鎖が切れてアラートが沈黙する。**横断的知見**: (1) [[Prometheusルールリント]] を新規 concept として作成——「ルールが参照するメトリクスが存在しているか」という上流介入。AlertGuardian の rule refinement(ルール内容)・DEAR(評価場所)と直交する三番目の上流次元。(2) [[アラート管理]] に「第零の介入点」として追記——既存の 7+ 介入点がすべて「アラートが発火するかしないか」を前提に介入するのに対し、Prometheusルールリントは「ルールが正しく発火できる状態にあるか」を保証する。(3) [[Prometheus]] に pint / Cloudflare 大規模事例(3,000 万時系列・4 KiB/series)を追記。**新規**: source 1([[@2022__Cloudflare-Blog__Monitoring-our-Monitoring]]) + entity 2([[Cloudflare]]・[[pint]]) + concept 1([[Prometheusルールリント]])。**更新**: [[Prometheus]]・[[アラート管理]]。 2026-06-23: **SREcon21 Spike Detection in Alert Correlation at LinkedIn スライド ingest** — [[Nishant Singh]]（[[LinkedIn]] シニア SRE、Production-SRE チーム）による SREcon21 Americas（2021 年）発表を wiki 化([[@2021__SREcon21__Spike Detection in Alert Correlation at LinkedIn]])。**核心**: 数千のマイクロサービスで構成される LinkedIn の本番環境で、アラート相関システム（AC Engine）の推奨結果に含まれる一時的スパイクを、Iglewicz & Hoaglin（1993）の**修正 Z スコア**（$M_i = 0.6745(x_i - \tilde{x}) / MAD$、閾値 3.5）で分離する後段フィルタを実装。30 分ウィンドウ内のメトリクスデータに対し、全サービスグラフの 70% 以上が同傾向ならば REAL ALERT、それ未満なら SPIKE と判定する。約 5 日間・193 件の推奨で 71 件（36.4%）のスパイクを検出し、偽陽性率 1% 未満・トイル 30–40% 削減を**ML を一切使わず**達成。口頭説明では「偽陰性（真のアラートをスパイクと誤判定）は絶対に許容しない」という非対称な設計方針が 70% 閾値の保守的設定に反映されたこと、アラートが過去 15 日間の標準偏差から生成されること、API エンドポイントで下流チームにも公開していることが補足された。**横断的知見**: (1) [[異常検知]] に「ML なし統計的外れ値判定が産業で有効な最小限実装」として追記——[[AlertGuardian]] の軽量グラフ denoise・[[Minder]] のメトリクス類似度・[[LLMPrism]] の k-σ 則と同型の「検知/denoise 段は軽量統計手法」パターン。(2) [[アラート相関]] を新規 concept として作成——後段フィルタ（本発表）と入力段 denoise（[[AlertGuardian]]）の介入点の違いを整理。**新規**: source 1 + entity 1([[Nishant Singh]]) + concept 1([[アラート相関]])。**更新**: [[LinkedIn]]・[[異常検知]]。YouTube 音声 Whisper 文字起こしで口頭説明を補完、全 30 ページ画像確認済み。 2026-06-23: **SREcon22 Americas Dark Sky Camping スライド ingest** — [[Kristin Smith]]（[[Campspot]] DevOps Services リード）による SREcon22 Americas（2022-03-15、San Francisco）発表を wiki 化([[@2022__SREcon22 Americas__Dark Sky Camping - Reducing Alert Pollution with Modern Observability Practices]])。**核心**: パンデミック期にパーク数 10 倍・エンジニア数 2.5 倍の急成長に対しアラートとダッシュボードを増設した結果、**[[アラートポリューション]]**（光害のアナロジーで「星座が見えなくなる状態」）に陥った。2021 年 5 月に「ツール標準化・重要事項への集中・より良い問いへの投資」の 3 原則でオブザーバビリティ転換を決断。Prometheus からコンテキスト付き分散トレーシング（Honeycomb + OpenTelemetry Java エージェント）への移行は実質 **4 時間**で完了し、6 か月以上躊躇していた移行コストの認知バイアスが最大の障壁だった。カスタム属性（`park_id`・`shopping_cart_uuid`・ホスト情報）により個別ユーザーレベルの調査が可能に。SLO 導入では営業チームが「Uptime 99.999%」の言語で混乱し、非技術ステークホルダーを実装前に巻き込む「Adjust」フェーズの欠如が組織的摩擦を生んだ教訓。「問題があった——モニタリングを増やした」という心理的パターンが不要アラート削減の組織的抵抗の根源。**横断的知見**: (1) [[アラート管理]] に「モニタリング増設=安全の心理的結合」を技術的アンチパターン分類外の組織的バイアスとして追加。(2) [[サービスレベル目標]] に「非技術ステークホルダーの暗順応期間」の必要性を追加——SRE Workbook のステークホルダー合意が営業チームを名指しした実例。(3) [[オブザーバビリティ]] に「移行コストの認知バイアス」事例を追加——4 時間計装が 6 か月の躊躇を解消。**新規**: source 1 + entity 2([[Kristin Smith]]・[[Campspot]]) + concept 1([[アラートポリューション]])。**更新**: [[アラート管理]]・[[サービスレベル目標]]・[[オブザーバビリティ]]。YouTube 英語自動字幕で口頭説明を補完、全 36 ページ画像確認済み。 2026-06-23: **Sakana Fugu Technical Report ingest** — [[Sakana AI]] Fugu Team（[[Yujin Tang]] プロジェクトリード、[[Stefan Nielsen]]・[[Edoardo Cetin]] ほか）による技術レポートを wiki 化([[@2026__Sakana AI__Sakana Fugu Technical Report]])。**核心**: フロンティアLLM(Gemini-3.1-Pro・Claude-Opus-4.8・GPT-5.5)を束ねる学習型オーケストレーター **Fugu / Fugu-Ultra** を公開。**オーケストレーションを第3のスケーリング軸**として本番水準で確立した最初の公開システム。**Fugu**: Trinity ベース。軽量選択ヘッド + 特異値ファインチューニング。SFT（ソフトターゲット KL ダイバージェンス）→ sep-CMA-ES 進化的最適化の 2 段階訓練。**Fugu-Ultra**: Conductor ベース。GRPO + 自然言語ワークフロー生成（最大5ステップ）。**Intra-workflow agent isolation** でオーケストレーション崩壊を防止、**Persistent Shared Memory** でワークフロー間コンテキストを保持。**主要成績**: Fugu-Ultra が SWE-bench Pro 73.7%（Opus-4.8 比 +4.5pt）・Terminal Bench 2.1 82.1%（GPT-5.5 比 +3.9pt）・GPQA-Diamond 95.5%・HLE 50.0%。**ワーカープールに含まれない** Mythos Preview・Fable 5 モデルクラスを超えた点が「スケーリング軸の独立性」の最強証拠。**ドメイン適応**: Terminal Bench→GPT優先(86%)・GPQA→Gemini優先(56%)・HLE→均衡配分が自然に学習。**戦略**: 「ビルド&デバッグ」（GPTがビルド・Opusが脆弱性列挙）・「スペシャリスト招集」・「討議+集約者選択」の3パターンを定性分析。**新規**: source 1([[@2026__Sakana AI__Sakana Fugu Technical Report]]) + concept 1([[集合知]])。**更新**: [[マルチエージェント協調]]（intra-workflow isolation・動的集約者・ドメイン適応創発の横断的知見追加）・[[Sakana AI]]・[[Yujin Tang]]・[[Stefan Nielsen]]・[[Edoardo Cetin]]。PDF 全31ページ・埋め込み画像14枚確認済み。代表図4枚をアタッチメントに取り込み。 2026-06-23: **SREcon23 Americas Cognitive Apprenticeship スライド ingest** — [[Paige Cruz]]（[[Chronosphere]] シニアデベロッパーアドボケイト、元 SRE）による SREcon23 Americas（2023-03-22、Santa Clara）発表を wiki 化([[@2023__SREcon23 Americas__Cognitive Apprenticeship in Practice with Alert Triage Hour of Power]])。**核心**: アラートトリアージは生得的スキルではなく、[[認知的徒弟制]]（Cognitive Apprenticeship）の 6 段階（Modeling→Coaching→Scaffolding→Articulation→Reflection→Exploration）を通じて体系的に伝達できる。**Alert Triage Hour of Power** は週 1 時間・4 ロール制（Facilitator / Driver / Scribe / Support）の構造化ミーティングで、10 分意図共有 + 40 分アラート調査 + 10 分振り返りの 3 部構成。KEEP/TUNE/DELETE の集団判定でアラート衛生に介入する。3 年間継続（創始者退職後も存続）、スパムアラート削減率は 0% だが学習そのものが正当な目標。**横断的知見**: (1) [[アラート管理]] に「人間側のアラート衛生」という技術的介入と直交する介入点を追加——KEEP/TUNE/DELETE は rule refinement でも alert suppression でもなく、定期的に人間がアラートの要否を判断し続ける社会的プロセス。(2) [[アクショナブルアラート]] にアラートクエリの声に出した読み上げを追加——TraceArk の interpretability を自動化ではなく集団的認知プロセスとして実現する方法。**新規**: source 1 + entity 2([[Paige Cruz]]・[[Chronosphere]]) + concept 1([[認知的徒弟制]])。**更新**: [[アラート管理]]・[[アクショナブルアラート]]。YouTube 英語自動字幕で口頭説明を補完、全 78 ページ画像確認済み。 2026-06-23: **SREcon19 EMEA Adaptive Paging スライド ingest** — [[Luis Mineiro]]（[[Zalando SE]] SRE 責任者）による SREcon19 EMEA（2019-10-03、Dublin）発表を wiki 化([[@2019__SREcon19 EMEA__Are We All on the Same Page - Lets Fix That]])。**核心**: マイクロサービスにおける症状ベースアラーティングの限界——SN 比は高いが通知先が固定され症状所有チームが過負荷になる。**[[Adaptive Paging]]** は OpenTracing セマンティック規約（`error`・`peer.service`・`span.kind`・`component`）を活用し、SLO 違反トレースのスパンツリーを `error=true` パスで再帰的に走査して最深の障害サービスを特定、そのチームへ通知する。**課題**: 複数エラーパス（スコアリングヒューリスティック）、計装欠落（`peer.service` フォールバック）、サービスとオンコールのマッピング。**横断的知見**: (1) [[アラート管理]] の 7+ 介入点に「通知先ルーティング（dispatch routing）」という直交する介入点を追加。(2) FSF（IEEE CLOUD 2022）が同型のスパンツリー動的因果推論を形式化する 3 年前の実運用実装。(3) [[アクショナブルアラート]] の interpretability を「受信者側で最大化する」アプローチ。**新規**: source 1 + entity 2([[Luis Mineiro]]・[[Zalando SE]]) + concept 1([[Adaptive Paging]])。**更新**: [[アラート管理]]・[[アクショナブルアラート]]・[[分散トレーシング]]。YouTube 英語自動字幕で口頭説明を補完、全 39 ページ画像確認済み。 2026-06-23: **joisino「AIのモデル崩壊と多様性」ingest** — [[佐藤竜馬]]（joisino、2026-06-22）によるブログ記事を wiki 化([[joisino-モデル崩壊と多様性-2026]])。**核心**: AI 生成データの反復訓練が引き起こす**分布収縮**と**多様性喪失**の構造的問題。(1) **メカニズム 3 系統**: 反復サンプリングによる低頻度データの永久消失・貪欲デコーディングによる分布平準化（関西弁 15%→0% の例）・品質フィルタリングによるマイノリティ淘汰（80 点の無難さが 79 点の奇抜さに勝つ）。(2) **数理的上界 π²/6**: 全世代データを破棄せず累積すれば損失増加を ≈1.645 倍に抑制可能（線形モデルでの証明）。直感: $\sum_{k=1}^{\infty} 1/k^2 = \pi^2/6$。(3) **二段階カスケード**: AI 多様性縮小 → 人間の思考均質化。Yakura+ Max Planck 2024 で「delve」等 GPT 語が人間発話に有意増加。Abdulhai+ DeepMind 2026 で LLM 多用グループの中立的回答が 70% 増加。(4) **著者の主張**: 現代モデルは「人類全体の多様性を内包するには小さすぎる」——スケーリングのみでの解決は不可能で、人間がつくり続けることが根本策。**新規**: source 1([[joisino-モデル崩壊と多様性-2026]]) + concept 1([[モデル崩壊]])。**更新**: [[佐藤竜馬]]（AI 生成データと社会的影響トピック追加）。 2026-06-23: **SREcon22 Americas Modeling Alert Quality スライド ingest** — [[Moshe Zadka]] による SREcon22 Americas 発表を wiki 化([[@2022__SREcon22 Americas__Modeling Alert Quality]])。**核心**: アラート品質を「アラーティングの総コスト + 非アラーティングの総コスト」の**アンチクオリティ**としてモデル化する実践的フレームワーク。(1) アラームを**真/偽/欠落**の 3 種に分類し、欠落アラームをアラート品質計測の不可欠な構成要素として位置づける。(2) 真アラームのレイテンシを 4 区間（発生→検知→確認→診断→復旧）に分解し、各区間に独立した改善レバーを対応させる。(3) コスト構造を偽アラーム（人数×時間×不便さ）、インシデントコスト（復旧作業+損失+二次インシデント）、損失（即時的コスト+評判コスト）に分解。(4) アラート品質は遅行指標のため即時 OKR で近似追跡するが、**Goodhart の法則**を適用して業績目標にはしない。**横断的知見**: Yang+ DSN2022 の QoA 3 軸(indicativeness/precision/handleability)と同年に出された相補的枠組み — QoA が「何が品質を構成するか」を軸立てし、Zadka が「それぞれにどんなコストが対応するか」を分解する関係。**新規**: source 1 + entity 1([[Moshe Zadka]])。**更新**: [[Quality of Alerts]]・[[アラート管理]]。YouTube 英語自動字幕で口頭説明を補完、全 12 ページ画像確認済み。 2026-06-23: **mABC ingest (EMNLP Findings 2024)** — [[Wei Zhang (Beihang)]]・[[Hongcheng Guo]]([[Beihang University]] / [[Cloudwise]] Research)ほかによるマイクロサービス RCA フレームワーク論文を wiki 化([[@2024__EMNLP Findings__mABC - Multi-Agent Blockchain-inspired Collaboration for Root Cause Analysis in Micro-Services Architecture]])。**核心**: 7 専門エージェント(Alert Receiver / Process Scheduler / Data Detective / Dependency Explorer / Probability Oracle / Fault Mapper / Solution Engineer)を Agent Chain 上に配置し、blockchain-inspired 投票でハルシネーション抑制、Agent Workflow(最大 20 ステップ)で循環依存ループ回避。GPT-4-Turbo ベースで ReAct を平均 +8.4 ポイント上回り、Llama-3-8B ベース mABC が ReAct(GPT-4-Turbo 単一エージェント)を超えた。**アブレーション知見**: マルチエージェント除去 > Agent Workflow 除去 > 投票除去の順で性能低下。投票は RA より解決策品質(R-Useful)に寄与(4.2 vs 2.1 for ReAct)。**新規**: source 1 + entity 3([[Wei Zhang (Beihang)]]・[[Hongcheng Guo]]・[[Cloudwise]]) + entity 更新([[Beihang University]])。**更新**: [[LLMによる根本原因分析]]・[[マルチエージェント協調]]。 2026-06-23: **SRE NEXT 2023 Warning アラート自動調査スライド ingest** — [[池田将士]]([[面白法人カヤック]])による「Warningアラートを放置しない！アラート駆動でログやメトリックを自動収集する仕組みによる恩恵」を wiki 化([[@2023__SRE NEXT__Warningアラートを放置しない！アラート駆動でログやメトリックを自動収集する仕組みによる恩恵]])。**核心**: (1) Mackerel の Warning アラートは Critical ほど即時対応ではないが、AWS WAF / ALB などの SLA 由来の自然な頻度や SLO 違反の兆候を含むため放置すると調査不能になる。(2) [[prepalert]] は Mackerel webhook を起点に Lambda / SQS 経由で CloudWatch Logs Insights、S3 Select、Redshift Data API、plugin providers から発火時点の補助情報を集め、アラートメモへ貼る。(3) p99 1.5s 超過、15 秒タイムアウト、FCKeditor 攻撃による 500 など、後から調べると証拠が欠けやすい事例で振り返り時間を短縮する。(4) 自動化の目的はアラートを勝手に解決することではなく、低重要度アラートを人間が判断できる証拠つき状態へ移すこと。**新規**: source 1 + entity 3([[池田将士]]・[[面白法人カヤック]]・[[prepalert]]) + concept 1([[Warningアラート]])。**更新**: [[Mackerel]]・[[SRE NEXT]]・[[アラート管理]]・[[エラーバジェット]]・[[サービスレベル目標]]。YouTube 日本語自動字幕で補完、全 24 ページ画像確認済み。 2026-06-23: **SRE NEXT 2023 Runbook スライド ingest** — [[Sohei Iwahori]]([[GREE, Inc]])による「Runbookに何を書き、どのようにアラートを振り分けるか？」を wiki 化([[@2023__SpeakerDeck__Runbookに何を書き、どのようにアラートを振り分けるか]])。**核心**: (1) 既存の障害対応手順書は一次対応の How に寄り、エスカレーション先が参照する背景情報やアラートの Why が欠落していた。(2) Runbook は短命な定型手順でなく、背景・判断材料・解決につながる文脈を残すものとして設計する。(3) Git リポジトリ運用 + アラート通知システム組み込みで、Runbook があれば通知にリンクを付加し、なければ作成を促す。(4) アラート追加時に想定チャンネル、対応タイミング、適用スコープ、対応 Runbook を明示させることで、追加時点でアクションと必要性を再検討させる。**更新**: [[アクショナブルアラート]] に「発火前の合意形成」経路、[[アラート管理]] に「発火前の社会的設計」介入点を追加。**新規**: source 1 + entity 2([[Sohei Iwahori]]・[[GREE, Inc]])。YouTube 日本語自動字幕で補完、全 42 ページ画像確認済み。 2026-06-23: **JustDiag ingest — 診断的正当化エンジン(arXiv 2026)** — [[Tingzhu Bi]] ら([[Peking University]] / [[University of Edinburgh]] / [[Beijing University of Posts and Telecommunications]])による arXiv 2026 論文を wiki 化。**核心**: [[LLMによる根本原因分析|LLM ベース RCA]] が流暢な最終回答を生成しても、説明責任には証拠・競合仮説・矛盾・終端状態を明示した**[[診断的正当化]]アーティファクト**が必要。**JustDiag** は 5 つの基本オブジェクト(証拠・発見・仮説・主張・評価)を型付き有向グラフとして管理し、主張レベル裁定で仮説を競争させる。**二層評価プロトコル**: Outcome Judge(最終診断品質)と Process Judge(監査可能なプロセス品質)を分離。**主結果(66 件)**: Outcome Score 51.0→57.7、Process Score 44.0→50.5(対 DJ なし制御群)。**Process Score の乖離**: RCAgent と Flow-of-Action は Outcome Score が 44/43 に対して Process Score が 9.5/9.3 と著しく低く、説明責任設計の欠落が定量化された。**校正された非閉包**: `stalled` 終了は空出力でなく現在最優位仮説・代替・矛盾・次の確認の構造化記録を返す。Case 7 で制御群が誤った `resolved` を返した一方、JustDiag は `stalled` でより誠実な診断状態を提示。**アブレーション**: 証拠根拠付けが最重要(Process Score 53.8→35.4)、主張裁定が第二(Outcome 53.6→45.9・Process 53.8→45.6)。**新規**: source 1([[@2026__arXiv__JustDiag! A Diagnostic Justification Engine for Accountable Root Cause Analysis]]) + entity 8([[Tingzhu Bi]]・[[Xinrui Jiang]]・[[Xun Zhang]]・[[Pengcheng Su]]・[[Congjie He]]・[[Jinglin Li]]・[[Meng Ma]]・[[Beijing University of Posts and Telecommunications]]) + concept 1([[診断的正当化]])。**更新**: [[LLMによる根本原因分析]]・[[仮説駆動RCA]]・[[RCA評価設計]]・[[Ping Wang]]。 ## Last Updated (2026-06-23: Rethinking Hybrid Architectures ingest-paper) **今回のコンテキスト**: [[Ziqing Qiao]]・[[Yinuo Xu]] ほか（[[Tsinghua University]]・[[OpenBMB]]、[[Zhiyuan Liu]] グループ）による「Rethinking the Role of Efficient Attention in Hybrid Architectures」(arXiv 2606.15378, 2026-06-13)を wiki 化。**核心**: ハイブリッドアーキテクチャ(フルアテンション + SWA / 再帰型混合器)における効率的注意の役割を体系的解析。3 つの発見: (1) **スケーリング**: 効率的注意の設計は長コンテキスト能力の出現速度に影響するが、十分な訓練で収束する。(2) **メカニズム**: 長距離検索はフルアテンションが担い、効率的注意はその最適化事前として機能する。大ウィンドウ SWA は検索ヘッドの形成を遅らせる — これを **Large-Window Laziness** と命名。(3) **設計**: 小ウィンドウ SWA ハイブリッドのフルアテンション層にのみ NoPE を適用すると RULER +6.75 pt・RULER-NIAH +16.40 pt・LongBench +5.88 pt の大幅改善(S5/0.66B/100B、短コンテキスト変化 +0.82 pt のみ)。勾配影響 G(d) は距離 2048 で平坦なベースラインに収束するため、SWA-2048 はほぼ全シグナル範囲をカバーし検索訓練圧力を吸収してしまう。**新規**: source 1([[@2026__arXiv__Rethinking the Role of Efficient Attention in Hybrid Architectures]]) + entity 4([[Zhiyuan Liu]]・[[Xu Han]]・[[Chaojun Xiao]]・[[OpenBMB]]) + concept 1([[ハイブリッドアテンションアーキテクチャ]])。**更新**: [[NoPE]]・[[線形注意]]・[[Tsinghua University]]。 **直近 ingest の文脈**: 今回はアーキテクチャ設計論(ハイブリッド効率化・長コンテキスト)→ 以降は引き続き LLM アーキテクチャ系論文か、AIOps 系に戻る可能性。 --- ## Previous (2026-06-23: Cameron Wolfe — Agentic RL フレームワーク比較) **今回のコンテキスト**: [[Cameron-R-Wolfe|Cameron R. Wolfe]]("Deep (Learning) Focus" Substack、2026-06-22)による ToRL・AgentGym-RL・[[Agent-R1]]・[[AgentRL]]・AutoForge の 5 フレームワーク横断比較サーベイを wiki 化。**核心**: (1) **ToRL(RL-Zero)** — 後処理なしのベースモデルに RL のみでコードインタープリタ利用を習得させ、ツール呼び出し率 40→80% の創発と SFT 比 14.7% 絶対精度改善(Qwen2.5-Math-7B)を実証。ツール呼び出し上限 `C` がなければ精度低下。(2) **AgentGym-RL(ScalingInter-RL カリキュラム)** — 8→12→15 ターンの 3 フェーズカリキュラムで計画・内省・バックトラッキングの高次行動が創発。Qwen2.5-3B が RL 後に大半の独自モデルを凌駕。ルールベースドメインで恩恵が顕著、実世界環境では穏やか。(3) **5 フレームワーク収束知見** — 「ステップレベル軌跡」「非同期デカップリング」「タスク/環境レベル正規化」の 3 原則が独立に再発見。GRPO がルールベースドメイン最強・PPO が実世界向き。**新規**: source 1([[Agentic-RL-Cameron-Wolfe-2026]]) + entity 1([[Cameron-R-Wolfe|Cameron R. Wolfe]])。**更新**: [[エージェント型強化学習]](ToRL/AgentGym-RL 知見・5F 収束知見・未解決の問い 3 件追加)。 **直近 ingest の文脈**: Conductor(マルチエージェント協調 RL)→ 今回 Agentic RL フレームワーク比較(エージェント型 RL インフラ設計)。 --- ## Previous (2026-06-23: Conductor ICLR 2026) **今回のコンテキスト**: [[Sakana AI]]（[[Stefan Nielsen]]・[[Edoardo Cetin]]・[[Yujin Tang]] ほか）によるILCR 2026論文 [[@2026__ICLR__Learning to Orchestrate Agents in Natural Language with the Conductor]] を wiki 化。RLで訓練した7B ConductorがGPT-5・Gemini 2.5 Proを超えGPQA Diamond 87.5%・LiveCodeBench 83.93%のSOTA達成。自然言語による任意のマルチエージェント協調戦略生成を学習する新手法。新規概念ページ [[マルチエージェント協調]] を作成、[[テスト時計算スケーリング]] に再帰協調軸を追記。 **直近 ingest の文脈**: Europe 2031 シナリオ（AI政策・地政学）→ 今回 Conductor（LLMエージェント協調・RL）。 ## Last Updated (Previous) 2026-06-23: **Europe 2031 ingest — ARQ Foundation 政策シナリオ** — [[ARQ Foundation]] 主執筆の政策シナリオ・ナラティブを wiki 化。**核心**: AI 開発格差がヨーロッパを 2031 年までに周縁化するシナリオを、Caroline Dubois（ブリュッセル政策担当）と Christian Vogt（シリコンバレー起業家）の二視点で描く。**定量的軸**: 米欧コンピュート比が 2025 年 12.4 倍→2031 年 15.7 倍に拡大。**中心的逆説**: [[ヨーロッパのAI主権]] を守るために設計したデジタル主権規制が、劣位な国内代替品を強制使用させ、フロンティアモデルへのアクセスを遮断することで逆に脆弱性を加速させた。**キーノード**: [[ASML]]（EUV リソグラフィ装置の世界独占）が唯一の地政学的カードだったが、EU の政治的麻痺で 2028 年に米国の圧力下で消耗。**転換点**: 2029 年 Frontier Inference Services Rule（欧州向けアクセス 25% 上限）・2030 年 Atlas 産業買収・2031 年ワシントン強制交渉。**新規**: source 1([[europe2031-ai]]) + entity 2([[ARQ Foundation]]・[[ASML]]) + concept 2([[ヨーロッパのAI主権]]・[[コンピュート格差]])。 2026-06-23: **ループエンジニアリング ingest — sairahul1 X スレッド** — [[Sai Rahul]](@sairahul1)による X スレッドを wiki 化。**核心**: [[Peter Steinberger]](OpenClaw 作成者・OpenAI)と [[Boris Cherny]](Anthropic [[Claude Code]] ヘッド)が「プロンプトを送るのをやめてループを設計せよ」と同時に発言したことを受け、**[[ループエンジニアリング]]** という概念を体系化した記事。**5 段階フレームワーク**: DISCOVER→PLAN→EXECUTE→VERIFY→ITERATE。**2 つのスケール**: シングルエージェント（1 エージェントが自己完結でサイクルを回す）vs フリート（オーケストレータ＋スペシャリスト＋サブエージェントの階層）。**2 つの種別**: オープンループ（探索的・高コスト・要無制限予算）vs クローズドループ（経路設計済み・低コスト・現時点の実践選択）。**6 構成要素**: オートメーション（DISCOVER 起動）・ワークツリー（並行 EXECUTE の衝突防止）・スキル（DISCOVER 高速化）・プラグイン/コネクタ（EXECUTE 実環境接地）・サブエージェント（VERIFY の誠実さ担保）・メモリ（ループ永続化）。**コスト問題と解決**: フリートループは 500K〜2M トークン/回。[[DeepSeek-V4]]（1M コンテキスト・$20 で 17 億トークン）が現実的な解。**マインドセットの転換**: プロンプトエンジニア（言語スキル、人間がフィードバックループ）→ループエンジニア（ソフトウェア工学スキル、システムがフィードバックループ）。**新規**: source 1([[sairahul1-Loop-Engineering-2026]]) + entity 3([[Boris Cherny]]・[[Peter Steinberger]]・[[Sai Rahul]]) + concept 1([[ループエンジニアリング]])。 2026-06-23: **LLM 基盤論文 4 本一括 ingest-paper (InstructGPT / Chinchilla / Sparsely-Gated MoE / ReAct)** — 2017–2023 年の LLM 基盤論文 4 本を並行取り込み。**核心**: (1) **InstructGPT**（Ouyang+ NeurIPS 2022）: RLHF の 3 段階パイプライン（SFT → 報酬モデル → PPO）を確立。1.3B パラメータの InstructGPT が 175B の GPT-3 を人間評価で上回り、「整列はスケーリングに勝る」を実証。ラベラー間一致率は 73% にとどまり、報酬モデルの一般化に限界がある。(2) **Chinchilla**（Hoffmann+ arXiv 2022）: Kaplan et al. 2020 のスケーリング則を覆し、「計算最適訓練ではモデルサイズとデータ量を等比率でスケールすべき」を 3 つの独立手法で導出。70B Chinchilla が 280B Gopher・175B GPT-3・530B MT-NLG を一様に凌駕。MMLU 67.5%（Gopher +7%）。(3) **Sparsely-Gated MoE**（Shazeer+ ICLR 2017）: 計算量を緩やかに増やしつつモデル容量を 1000 倍以上に拡大するスパースゲート MoE 層を提案。top-k ゲーティング・重要度損失 + 負荷損失の補助損失・ネットワーク帯域ボトルネックという 3 設計原則は DeepSeek-V3・GShard へ直接継承。(4) **ReAct**（Yao+ ICLR 2023）: 推論トレースと外部行動を交互に生成する LLM プロンプティングパラダイム。HotpotQA で CoT-SC → ReAct フォールバック併用が最良（EM 35.1）。AlfWorld で ReAct が BUTLER を 12pt 上回る。CoT の推論力とツール利用の接地力は相補的。**横断的知見**: RLHF と CoT は独立に発展したが組み合わせが事実上の標準化。Chinchilla のスケーリング則は「既存 LLM は過大/過少訓練」の認識を転換。MoE の 2017 年原型設計が 2024–2026 年に直接継承されている事実は、基礎設計の長寿命を示す。ReAct は CoT を行動接地で拡張しエージェント型 AI の原型を確立。**新規**: source 4 + entity 11 + concept 7（[[人間フィードバックからの強化学習]]・[[指示チューニング]]・[[アライメント]]・[[計算最適訓練]]・[[条件付き計算]]・[[負荷分散]]・[[ReAct]]）。**更新**: [[Mixture-of-Experts]]・[[Chain-of-Thought Prompting]]・[[スケーリング則]]・[[Google Brain]]・[[OpenAI]]・[[Noam Shazeer]]。 2026-06-22: **Sebastian Raschka「The Big LLM Architecture Comparison」ingest** — DeepSeek V3 から Gemma 4(2026-04)まで 23 モデルを網羅する包括的 LLM アーキテクチャサーベイ記事を wiki 化。**核心**: (1) **MLA vs GQA**: DeepSeek-V2 アブレーションで MLA > GQA の性能優位が示されているにもかかわらず Llama・Gemma・Qwen・Mistral は GQA を継続採用。実装複雑度がボトルネック。(2) **共有エキスパートの設計分岐**: DeepSeek V3・GLM-4.5/5・Grok 2.5・Kimi K2 が採用、Qwen3 が廃止→Qwen3-Next で再導入。設計依存性が高く「共有エキスパートが有益」という理論的動機付けと「Qwen3 での廃止」の間の矛盾が未解決。(3) **スライディングウィンドウアテンション普及**: Gemma 3/4 の 5:1 比率・1024 トークン、Xiaomi MiMo の 128 トークン、Arcee AI の 4096 トークンと設定がバラバラ。SWA + MoE 組み合わせが普及。(4) **線形アテンション再台頭・撤退・再採用**: Qwen3-Next(Gated DeltaNet ハイブリッド)・Kimi Linear(KDA + MLA)が採用を進める一方 MiniMax-M2 は精度問題から撤退。Kimi Linear のチャネルワイズゲーティング(KDA)が精度問題への対処策を主張するが大規模未検証。(5) **MTP の推論活用**: Qwen3-Next と Nemotron 3 Super が MTP を投機的デコーディングに本格活用。特に Nemotron 3 Super の「共有重み MTP ヘッド = 内部ドラフトモデル」設計は外部 EAGLE 不要な高速化の道。(6) **GPT-OSS の幅広・浅い設計**: Qwen3 の「深い」設計と対照的。(7) **Mistral 3 の DeepSeek V3 アーキテクチャ採用**: Kimi K2 に続き Mistral 3 Large も DeepSeek V3 構造を採用しエキスパートを粗粒化してNVIDIA 最適化。**新規**: source 1 + concept 6(MLA・GQA・SWA・NoPE・QK-Norm・Gated DeltaNet) + entity 11(Sebastian Raschka・Gemma 3/4・Qwen3・Qwen3-Next・GPT-OSS・SmolLM3・Mistral 3・Kimi Linear・Arcee AI Trinity Large・Xiaomi MiMo-V2-Flash・OLMo 2)。**更新**: [[Mixture-of-Experts]]・[[マルチトークン予測]]・[[線形注意]]。 2026-06-21: **Datadog Bits AI SRE GA 発表記事 ingest** — [[Bits AI SRE]]（2025-06-10 GA、著者 Kai Xin Tai）。**核心**: (1) プロンプト不要の自律起動が産業製品として明言 — "Unlike chat-based assistants requiring manual prompting, Bits operates as a deep research agent." (2) **Bits AI Dev Agent（プレビュー）**: 根本原因特定後にコード修正 PR を自動生成。agentic SRE が「読み取り中心の診断 → 書き込み権限付きの修正」へ拡張する最初の公開産業実装。人間のレビュー・マージゲートを維持する保守的設計が [[AI Operator]]（Google、アクチュエーション込み）と対比される。(3) **調査トリガー拡大（プレビュー）**: アラートに加え Watchdog ストーリー・合成 API テストが起動点に。プロアクティブ調査方向（障害前の潜在リスク検知）が [[@2025__arXiv__ARGOS - Agentic Time-Series Anomaly Detection with Autonomous Rule Generation via Large Language Models|ARGOS]]（LLM ルール生成異常検知）と方向一致。(4) **調査間の文脈記憶**: インシデントをまたいでパターン認識が蓄積。学術ベンチの「単発精度」から「反復改善速度」への評価軸拡張を示唆し、[[RCAgent]] の human feedback 機構と同じ方向。(5) 数万組織のテレメトリを基盤とする large-scale grounding が agentic SRE の推論品質を支える。**新規**: source 1([[@2025__Datadog__Introducing Bits AI SRE]])。**更新**: [[Bits AI SRE]]・[[agentic SRE]]・[[Datadog]]。 2026-06-21: **マイクロサービス RCA・マルチモーダル障害診断 7 論文一括 ingest-paper (LocaleXpert / UniTok / MRCA / HolisticRCA / Medicine / ChangeLLM / DeepHunt)** — 7 本を並列取り込み。**核心**: (1) LocaleXpert（Zhong+ TSC 2026）は LLM と統計的障害箇所特定モジュール(MEPFL/MicroCause)のハイブリッド設計。マルチモーダルデータ（メトリクス・ログ・トレース）を「異常記述」として自然言語に変換して LLM に入力するアプローチが特徴。LLM 単体より外部モジュール併用が精度・解釈可能性で優位。(2) UniTok（Zhang+ arXiv 2026）は VQ-VAE ベースの汎用時系列トークナイザと NTP 事前学習基盤モデル UniTok-FM。接頭辞正規化+漸進解像度因果 AE+構造保存損失で連続時系列を離散トークン化し、予測・生成・分類を統一的に解く。(3) MRCA（Wang+ ASE 2024）はサービスレベルでなくメトリクスレベルまで根本原因を掘り下げ、運用者の行動可能性を向上。マルチモーダル融合でメトリクス選定と原因特定を統合。(4) HolisticRCA（Han+ TSC 2024）はメトリクス・ログ・トレースの 3 モダリティを因果グラフ上で統合し、クラウドネイティブシステムの包括的 RCA を実現。(5) Medicine（Tao+ ASE 2024）は各モダリティに適応的重み付けを行い、情報量の少ないモダリティが支配的モダリティに埋もれる「モダリティ不均衡」問題を解決。(6) ChangeLLM/SCELM（Ma+ FSE 2025）は RAG で過去の変更事例を検索し LLM のコールドスタート問題を緩和する変更影響評価パイプライン。(7) DeepHunt（Sun+ TOSEM 2025）はグラフオートエンコーダの再構成誤差から異常スコアを導出し、注意機構による解釈可能な帰属を実現。**横断的知見**: マルチモーダル RCA は「モダリティ統合戦略」の分岐点にある——(a) 特徴量レベル結合（HolisticRCA・MRCA）、(b) 適応的重み付け最適化（Medicine）、(c) 自然言語記述へ変換して LLM に入力（LocaleXpert）、(d) RAG ベース知識活用（ChangeLLM）の 4 路線が並走。また、LLM をパイプラインの最終推論層に置く設計（LocaleXpert）と、変更影響評価という上流判断に LLM を使う設計（ChangeLLM）で LLM の活用レイヤーが分化。メトリクスレベル RCA（MRCA）と解釈可能な帰属（DeepHunt）の粒度深化も重要な進化軸。**新規**: source 7 + entity 18 新規 + 5 更新。**更新**: [[根本原因分析]]・[[マルチモーダル障害診断]]・[[LLMによる根本原因分析]]・[[変更起因インシデント]]・[[時系列基盤モデル]]。 2026-06-20: **マイクロサービス RCA 6 論文一括 ingest-paper (TraceRank / LogCluster / LogKG / FSF / Nezha / Eadro)** — 6 本を並列取り込み。**核心**: (1) TraceRank（Yu+ JSEP 2021）は非集計トレースからスペクトル解析 + PageRank ランダムウォークでサービスレベル異常箇所特定を実現。処理時間に応答時間以外の指標（待ち時間・エラー率）を導入し、Sock Shop・Train-Ticket で Top-1/Top-3 精度 84.45%/95.79%。(2) LogCluster（Lin+ ICSE-C 2016）は IDF ベースログクラスタリング + 知識ベース照合で 10 百万件ログを 40 件に圧縮。Microsoft 4 チーム本番稼働。(3) LogKG（Sui+ TSC 2023）は知識グラフ推論でログ障害を診断。テンプレート・重大度・メタ情報をグラフ化し、埋め込み + GraphSAGE で障害種別分類。(4) FSF（Rios+ IEEE CLOUD 2022）はスパンツリー動的因果推論で教師なし障害箇所特定。Train-Ticket 68 件全注入で完全特定。(5) Nezha（Yu+ ESEC/FSE 2023）はメトリクス+トレース+ログ 3 モダリティ統合でコード領域・リソースタイプレベル RCA を達成。Top-1 精度 89.77%。(6) Eadro（Lee+ arXiv 2023）は異常検知と箇所特定を統合するエンドツーエンド障害診断フレームワーク。**横断的知見**: サービスレベル箇所特定(TraceRank)→コード領域レベル根本原因特定(Nezha)→検知-箇所特定統合(Eadro)という解像度と統合度の進化軸が明瞭に浮かぶ。ログ系は「圧縮してから知識照合」(LogCluster)→知識グラフ推論(LogKG)への構造化が進む。**新規**: source 6 + entity 12 + concept 2（[[ログクラスタリング]]・[[知識グラフ]]）。**更新**: [[根本原因分析]]・[[Fault Localization]]・[[分散トレーシング]]・[[ログ解析]]・[[マルチモーダル障害診断]]・[[The Chinese University of Hong Kong]]・[[Saurabh Jha]]。 2026-06-20: **Energy statistics (JSPI 2013) ingest-paper** — [[@2013__JSPI__Energy statistics - A class of statistics based on distances]] を wiki 化。**核心**: (1) エネルギー統計(E統計量)は距離に基づく U/V統計量の族。核心はエネルギー距離 $\mathcal{E}(X,Y) = 2E|X-Y| - E|X-X'| - E|Y-Y'| \geq 0$（等号 $\Leftrightarrow$ $X \overset{d}{=} Y$）であり、特性関数の重み付き L2 距離と同値。回転不変+スケール同変の公理から重み関数 $|t|^{-(d+1)}$ に一意に定まる。(2) 距離共分散(dCov)はゼロとなる必要十分条件が $X \perp Y$（任意次元）。ピアソン相関では不可能な非線形・非単調依存性を全て検出できる。距離行列の二重センタリングで $O(n^2)$ 計算。(3) ブラウン共分散との同値性: 距離共分散 = ブラウン運動に関する条件付き共分散（任意次元）。フラクショナル・ブラウン運動で $\alpha$-dCov へ一般化。(4) DISCO は ANOVA の非パラメトリック拡張（$0 < \alpha < 2$ で一致検定）。E-クラスタリングは Ward 法の限界（$\alpha=2$: 中心が等しいクラスタを分離不可）を克服。**新規**: source 1 + entity 2([[Gábor J. Székely]]・[[Maria L. Rizzo]]) + concept 2([[エネルギー統計]]・[[距離相関]])。 --- 2026-06-20: **Odin (NSDI 2018) ingest-paper** — [[@2018__NSDI__Odin - Microsoft's Scalable Fault-Tolerant CDN Measurement System]] を wiki 化。**核心**: (1) Microsoft CDN(100+ PoP)を支えるクライアント側アプリケーション層計測プラットフォーム。ファーストパーティアプリへの SDK 埋め込みで 98% AS・85% /24 のユーザーカバレッジを達成し、RIPE Atlas 等のサードパーティ基盤(45%以下)を大幅に超える。(2) Odin データから生成した DNS リダイレクションマップを 2017 年 5 月本番適用し、スペイン P75 30.68%・日本 28.14% 等の大幅低遅延化を実現。地理情報データベースより P95 で 65ms 改善(65% の時間帯)。(3) エニキャストは 60% を最適 FE へ送信するが 20% は最適より 25ms 以上悪い FE へ送信する。Odin で検知しユニキャストパッチで補正するハイブリッド方式を本番運用。(4) サードパーティ CDN をフォールバックパスとし、Microsoft ネットワーク障害時も計測データを収集できる耐障害設計。深夜帯のフォールバック増加はブラジルがドイツの 3〜4 倍と国差が大きい。**新規**: source 1 + entity 6([[Matt Calder]]・[[Ethan Katz-Bassett]]・[[Ganesh Ananthanarayanan]]・[[Ratul Mahajan]]・[[Columbia University]]・[[Intentionet]]) + concept 2([[CDN計測システム]]・[[エニキャストルーティング]])。**更新**: [[Microsoft]]・[[Jitendra Padhye]]。 Previous: 2026-06-20: **分散トレーシング基礎論文 5 本一括 ingest-paper** — Pinpoint(DSN 2002)・Magpie(HotOS 2003)・lprof(OSDI 2014)・Pivot Tracing(SOSP 2015)・Canopy(SOSP 2017)を wiki 化。**核心**: 2002–2017 の分散トレーシング進化系譜を横断集約。(1) Pinpoint が「トレースを統計的障害診断の入力として使う」系譜を開き、後の MetricSifter/BARO 等へ分岐。(2) Magpie がスキーマ駆動リクエストモデリングを導入し、リクエスト単位の資源消費を自動分解。(3) lprof がバイトコード静的解析で非侵入プロファイリングを確立し、SQL 的探索分析パターンを先駆。(4) Pivot Tracing が happened-before join + 動的計装で「何を計測するかを実行時に定義する」初の汎用フレームワークを確立。(5) Canopy が Facebook 規模でトレース→特徴量抽出 DSL→Scuba 統合の完全パイプラインを報告、コールパス 80% 打ち切りの定量的トレードオフを初提示。**新規**: source 5 + entity 21 + concept 3([[動的計装]]・[[リクエストモデリング]]・[[非侵入プロファイリング]])。**更新**: [[分散トレーシング]]・[[Fault Localization]]・[[トレースサンプリング]]・[[根本原因分析]]。 Previous: 2026-06-20: **ISSTA 2016 Practitioners' Expectations on FL ingest-paper** — [[@2016__ISSTA__Practitioners' Expectations on Automated Fault Localization]] を wiki 化。**核心**: (1) 30 か国以上の 386 名実務者アンケートで障害箇所特定(FL)ツールの採用閾値を定量化。Top-5 成功基準(73.58% が要求)・成功率 75%・スケール 100kLOC・実行 1 分以内を同時に達成して初めて 75% の実務者が満足する「採用の壁」を明示。(2) 判断根拠(rationale)の提供を 85%+ が必要と評価。IDE 統合は 65% 未満が必須と考えるが欠けると採用意欲が低下。(3) 2011–2015 年の上位 6 会議・論文誌から 15 本を文献レビューし、**満足率 75% の信頼性要件を達成した論文は皆無・IDE 統合も皆無**という構造的ギャップを定量化。(4) テスター群は開発者より若干高い重要度認識(統計的有意差なし)。経験が高いほど「Essential」評価が低下(Spearman ρ=−0.14, p=0.007)。**Key insight**: SE FL の「採用閾値研究(精度×スケール×説明可能性の 3 軸)」が AIOps 系 RCA 評価設計([[RCA評価設計]]・[[Fault Localization]])の先行事例として機能する。LLM 時代に同じ調査を実施すれば、期待値がどう変化したかを測れる位置づけ。**新規**: source 1 + entity 4([[Xin Xia]]・[[Pavneet Singh Kochhar]]・[[Shanping Li]]・[[Singapore Management University]])。**更新**: [[David Lo]]・[[Fault Localization]]。 2026-06-20: **BARO (FSE 2024) ingest-paper** — [[@2024__FSE__BARO - Robust Root Cause Analysis for Microservices via Multivariate Bayesian Online Change Point Detection]] を wiki 化。**核心**: (1) 多変量 BOCPD(Adams & MacKay 2007 BOCPD × Xuan & Murphy 2007 MultivariateCPD、逆ウィシャート事前分布)でマイクロサービスの異常変化点を検知し、RobustScorer(中央値・IQR ベースノンパラメトリック仮説検定)で根本原因メトリクスをスコアリングするエンドツーエンド RCA フレームワーク。(2) Online Boutique/Sock Shop/Train Ticket の 3 ベンチマーク・4 障害種別(CPU hog・メモリリーク・ネットワーク遅延・パケットロス)で粗粒度 Avg@5 が 0.86/0.95/0.81 と CausalRCA(0.80/0.60/0.28)・CIRCA(0.66/0.78/0.67)・RCD(0.48/0.48/0.08)を一貫して上回る。(3) 感度分析: N-Sigma/CIRCA が遅延検知(t_bias=+20)で Avg@5 が半分以下に落ちる一方 BARO の変動は 25% 以内。中央値/IQR は平均/std より異常検知時刻のずれに頑強。(4) 実行時間: RobustScorer 0.01 秒対比 CausalRCA 299 秒・CIRCA 13 秒。**Key insight**: 「辺方向推定がボトルネック」(ASE 2024)を補完する「異常検知時刻のずれへの非感度設計が設計要件として因果グラフ精度と同等か以上」という新たな観察を提供。**新規**: source 1 + attachment 4 枚(fig01-04)。**更新**: entity 3([[Luan Pham]]・[[Huong Ha]]・[[Hongyu Zhang]])・concept 3([[変化点検知]]・[[根本原因分析]]・[[因果推論ベースRCA]])。 2026-06-20: **MicroCause (IWQoS 2020) ingest-paper** — [[@2020__IWQoS__Localizing Failure Root Causes in a Microservice through Causality Inference]] を wiki 化。**核心**: (1) イントラマイクロサービス障害根本原因特定を初定式化。(2) PCTS が PCMCI（Runge+ Science Advances 2019）を AIOps に初応用し、iid 仮定で孤立サブグラフを生成する PC の限界を克服。(3) TCORW が偏相関（コンファウンダー除去）+ SPOT 異常度 + 3 層メトリクス優先度 + 異常時刻の 4 情報を統合してランダムウォーク遷移確率を設計。(4) 86 件の Alibaba オンラインショッピング実障害チケットで AC@5=98.7%（最良ベースライン比 +33.4%）。FluxInfer（同年、有向性を捨てて無向 + Pearson で SOTA）との設計対比が[[因果推論ベースRCA]]の横断的知見として追加。**新規**: source 1 + entity 6（[[Yuan Meng]]・[[Ruru Zhang]]・[[Zhilong Hu]]・[[Yiyin Zhang]]・[[Chenyang Jia]]・[[Zhaogang Wang]]）。更新: [[因果推論ベースRCA]]・[[Dan Pei]]・[[Shenglin Zhang]]・[[Yongqian Sun]]。 2026-06-20: **マイクロサービス・DB RCA 基礎論文 10 本同時 ingest-paper** — MonitorRank（Kim+ SIGMETRICS 2013）・Zeng+ CNSM 2014・CloudRanger（Wang+ CCGrid 2018）・FluxRank（Liu+ ISSRE 2019）・ε-Diagnosis（Shan+ WWW 2019）・FluxInfer（Liu+ IPCCC 2020）・AutoMAP（Ma+ WWW 2020）・MicroDiag（Wu+ CloudIntelligence 2021）・TS-InvarNet（Hu+ ICWS 2022）・PyRCA（Liu+ arXiv 2023）を並列取り込み。マイクロサービス RCA の「PC アルゴリズム + ランダムウォーク」パイプラインの起源（MonitorRank の相関比例ランダムウォーク）から、因果グラフ構築の拡張（CloudRanger の二次ランダムウォーク、AutoMAP の異常行動グラフ）、有向性推定を捨てた転換（FluxInfer の重み付き無向グラフ + PageRank、PC 系 8 手法を AC@3 で 2〜15 倍上回る）、不変条件崩壊ベースの異常検知（TS-InvarNet の SARIMAX + HDBSCAN + グランジャー因果検定）、テイルレイテンシ診断（ε-Diagnosis のε統計量）、ライブラリ統合（PyRCA の因果グラフ構築→スコアリング→可視化ワンストップ）までの 10 年間の系譜を wiki 化。新規: source 10 + entity 30+。更新: [[Dan Pei]]・[[Pengfei Chen]]・[[Shenglin Zhang]] 等。 2026-06-20: **KDE チュートリアル + DirectLiNGAM** — Chen arXiv 2017 の KDE チュートリアルと Shimizu+ JMLR 2011 の DirectLiNGAM を並列取り込み。KDE はノンパラメトリック密度推定の理論体系（収束レート・帯域幅選択・信頼帯のバイアス処理）に加え、密度の幾何学的/位相的特徴推定（局所モード・レベルセット・クラスターツリー・パーシステント図）まで概観するチュートリアル。[[密度ベースクラスタリング]]の DENCLUE の理論的基盤としての接続を整理。DirectLiNGAM は ICA-LiNGAM の反復探索依存を排除し、外生変数の逐次同定で固定ステップ数の収束保証を実現。[[因果発見]]の既存知見（Glymour+ 2019 / Vowels+ 2022）と突き合わせ、スケーラビリティと理論的保証のトレードオフ、モデル仮定違反時の具体的失敗モードを横断的知見に追加。新規: source 2 + entity 6 + concept 1（[[カーネル密度推定]]）。更新: [[因果発見]]・[[密度ベースクラスタリング]]・[[University of Washington]]。 2026-06-20: **クラスタリング基礎論文 3 本同時 ingest-paper** — DBSCAN（Ester+ KDD 1996）・HDBSCAN（Campello+ PAKDD 2013）・k-Shape（Paparrizos+ SIGMOD 2015）を並列取り込み。密度ベースクラスタリングの「単一閾値→階層→安定性最適化」17 年間の進化を wiki 化し、時系列クラスタリングの距離尺度比較も整理。DBSCAN と HDBSCAN の横断的知見（境界点排除による理論的整合性改善、パラメータ負荷の軽減）を [[密度ベースクラスタリング]] に蓄積。新規: source 3 + entity 7 + concept 2（[[密度ベースクラスタリング]]・[[クラスタ安定性]]）。更新: [[時系列クラスタリング]]（距離尺度セクション＋横断的知見）。 2026-06-19: **Truong+ 2020「Selective review of offline change point detection methods」(Signal Processing) ingest-paper** — [[@2020__Signal Processing__Selective review of offline change point detection methods]] を wiki 化。**核心**: (1) オフライン変化点検知手法を**コスト関数**・**探索手法**・**変化点数の制約**の 3 軸で統一分類。コスト関数はパラメトリック 7 種（$c_\text{i.i.d.}$・$c_{L_2}$・$c_\Sigma$・$c_\text{Poisson}$・$c_\text{linear}$・$c_{\text{linear},L_1}$・$c_{AR}$）とノンパラメトリック 6 種（$c_{\hat{F}}$・$c_\text{rank}$・$c_\text{kernel}$・$c_\text{rbf}$・$c_M$・$c_{\mathcal{H},M}$）。探索手法は最適解法（Opt: $O(KT^2)$, Pelt: 期待 $O(T)$）と近似解法（Win・BinSeg・BotUp: $O(T)$〜$O(T\log T)$）。制約は l0 ペナルティ（BIC・AIC）・l1 ペナルティ（fused lasso）・mBIC/Lebarbier。(2) 3 軸の組み合わせをモジュール式 Python ライブラリ [[ruptures]] として実装公開。**横断的知見**: [[変化点検知]] に「Truong+ の 3 軸分類は AIOps 手法選択の基盤を提供するが、実運用は $c_{L_2}$ + Pelt に収束しており、カーネル法・順位統計など多様なコスト関数の AIOps 評価が未踏」を追加。**新規ページ**: source 1 + entity 4（[[Charles Truong]]・[[Laurent Oudre]]・[[Nicolas Vayatis]]・[[ruptures]]）。更新: [[変化点検知]]。 2026-06-19: **Paparrizos+ 2025「Time-Series Clustering: A Comprehensive Study」(PVLDB) ingest-paper** — [[@2025__PVLDB__Time-Series Clustering - A Comprehensive Study of Data Mining, Machine Learning, and Deep Learning Methods]] を wiki 化。**核心**: (1) 84手法を10クラスに分類し[[UCR Time Series Archive]]全128データセットで包括評価。Wilcoxon 検定・Friedman-Nemenyi 検定で、10年前の k-Shape を統計的に有意に上回る手法は皆無。(2) 先行ベンチマークの「進歩」は tslearn の k-Shape 実装バグ・不公平なパラメータ設定・限定的データセット選択による幻想。(3) 深層学習コンポーネント分解で RES-CNN(アーキテクチャ)+ CNRV(対照損失)が最良だがクラスタリング損失(IDEC 等)は無効果。(4) 基盤モデル(CHRONOS・OFA・MOMENT)はクラスタリングで k-Shape を超えられず、MOMENT は UCR を事前学習に使用しデータ汚染。**横断的知見**: [[時系列基盤モデル]]に「TSFM のクラスタリング性能が古典手法を上回れない——予測以外のタスクでの TSFM 優位は未確立」を追加。Toto 2.0 のスケーリング則が予測タスクに限定的である可能性を示唆。**新規ページ**: source 1 + entity 2([[John Paparrizos]]・[[UCR Time Series Archive]]) + concept 1([[時系列クラスタリング]])。更新: [[The Ohio State University]]・[[時系列基盤モデル]]。 2026-06-19: **Boris Tane「The Software Development Lifecycle Is Dead」(2026-02-20) ingest** — [[Boris Tane]] のブログ記事 [[@2026__Boris Tane Blog__The Software Development Lifecycle Is Dead]] を wiki 化。**核心**: (1) AI エージェントは SDLC を加速させたのではなく解体した。requirements → design → implementation → testing → review → deployment → monitoring という逐次ワークフローは、Intent → Agent → Build/Test/Deploy → Observe → Repeat というループへ崩壊した。(2) 唯一の生存フェーズはモニタリング（オブザーバビリティ）であり、役割が「人間がダッシュボードを見て判断する」から「観察結果がエージェントへフィードバックされ修復ループを駆動する」へ根本的に転換する。(3) 新たな差別化要因は[[コンテキストエンジニアリング]]——エージェントに与えるコンテキストの品質が成果品質を決定する。(4) [[Cursor]] 以降にキャリアを始めた[[AIネイティブ開発]]エンジニアはスプリント計画・PR レビューを必要とせず育った。これは欠陥ではなく適応。**横断的知見**: [[LLM Wikiパターン]]（Karpathy: bookkeeping は LLM に）と Tane のコンテキストエンジニアリングは「人間の付加価値が入力設計へ移る」点で一致。[[agentic SRE]] との接続——オブザーバビリティがフィードバックループの中心になる構造は、agentic SRE が observability をエントリポイントとする方向性と同一。**新規ページ**: source 1 + entity 1([[Boris Tane]]) + concept 2([[コンテキストエンジニアリング]]・[[AIネイティブ開発]])。 --- 2026-06-19: **Vowels+ 2022「D'ya Like DAGs? A Survey on Structure Learning and Causal Discovery」ingest** — [[Matthew J. Vowels]]・[[Necati Cihan Camgoz]]・[[Richard Bowden]]（CVSSP, [[University of Surrey]]）による ACM Computing Surveys 2022 サーベイ [[@2022__CSUR__D'ya Like DAGs - A Survey on Structure Learning and Causal Discovery]] を wiki 化。**核心**: (1) 因果発見/構造学習の4系統（制約ベース・スコアベース・構造的非対称性・介入）を統一整理し、組合せ手法約60件（Table 1）と連続最適化手法約30件（Table 2）を横断比較。(2) NOTEARS（2018）の非巡回性制約 h(A) = tr(e^{A⊙A}) − d = 0 が連続最適化パラダイムの起点であり、後続の DAG-GNN・GranDAG・GOLEM・NO BEARS・LEAST 等は全てこの制約の改良（計算量・ソフト化・スペクトル半径近似）に集中する。(3) 連続最適化手法の大半は低次元（<100 変数）でしか評価されておらず、非巡回性制約の O(d³) がスケーラビリティの瓶首。LEAST（2020）の O(d) 改善が 160,000 変数にスケールさせた唯一の例外。(4) 「因果の跳躍（Causal Leap）」: 条件付き独立性のみに基づく構造発見が「因果的」と自称するのは不当であり、因果マルコフ条件は通常のマルコフ条件の再ブランディングにすぎない（Dawid 2008）。介入データと識別可能性を伴わない限り、発見された構造は探索的候補としてのみ扱うべき。**横断知見追加**: [[因果発見]] に Glymour 2019 との補完的視野（組合せ手法の理論 vs. 連続最適化のスケーラビリティ）・スケーラビリティ問題の異なる瓶首・「因果の跳躍」の実践的 vs. 原理的批判の3件を追記。[[因果推論ベースRCA]] に DAG-GNN/NOTEARS 系の低次元評価制約が RCA 応用の失敗モードを説明することを追記。**新規ページ**: source 1 + entity 3([[Matthew J. Vowels]]・[[Necati Cihan Camgoz]]・[[Richard Bowden]])。**更新ページ**: [[University of Surrey]]・[[因果発見]]・[[因果推論ベースRCA]]。 --- 2026-06-19: **Glymour+ 2019「Review of Causal Discovery Methods Based on Graphical Models」ingest** — [[Clark Glymour]]・[[Kun Zhang]]・[[Peter Spirtes]]（[[Carnegie Mellon University]]）による Frontiers in Genetics 2019 レビュー [[@2019__Frontiers in Genetics__Review of Causal Discovery Methods Based on Graphical Models]] を wiki 化。**核心**: (1) 因果発見の3系統——制約ベース（PC・FCI）はスケーラブルだがマルコフ同値類しか出力しない、スコアベース（GES）は同値類を貪欲探索する、FCM ベース（LiNGAM・ANM・PNL）は一意構造を同定するが数十変数に制限——の「スケーラビリティ vs 識別力」トレードオフを体系化。(2) クラメール分解定理により線形関係下では非ガウス分布が遍在し LiNGAM の非ガウス仮定は自然だが、前処理（fMRI のハイパスフィルタ等）が非ガウス性を人為的に除去して FCM 系手法を無力化するリスクがある。(3) グレンジャー因果性は時間集約・サブサンプリングに非常に敏感で、集約時系列では遅延因果が即時的に見えるバイアスが生じる。(4) 生物学応用の実用ガイドライン10項目を提示——「前処理の歪み確認」「混合分布検出」「ブートストラップ安定性評価」等。**横断知見追加**: [[因果推論ベースRCA]] に、Glymour 理論体系が RCA 失敗モード（忠実性仮定違反・前処理による分布歪み・FCI vs PC の交絡ギャップ）を体系的に説明することを追記。**新規ページ**: source 1 + entity 3([[Clark Glymour]]・[[Kun Zhang]]・[[Peter Spirtes]]) + concept 1([[因果発見]])。**更新ページ**: [[Carnegie Mellon University]]・[[因果推論ベースRCA]]。 --- 2026-06-19: **Ji+ 2023「Signal propagation in complex networks」ingest** — [[Peng Ji]]・[[Jürgen Kurths]]・[[Matjaž Perc]] ほか([[Fudan University]]・Potsdam Institute・[[University of Maribor]] ほか)による Physics Reports 2023 包括サーベイ [[@2023__Physics Reports__Signal propagation in complex networks]] を wiki 化。**核心**: (1) 信号伝播のジオメトリはネットワークトポロジーとノード間の非線形相互作用の両方によって規定される。(2) 時変ネットワーク（時間的ネットワーク）の粗粒化した静的版は真の伝播パターンを正確に反映できない——ADN/NE 型の時変相互作用を明示的に扱う必要がある。(3) Turing 不安定性に対する高次相互作用の役割はまだ完全に解明されていない。(4) データ駆動の逆問題として、グレンジャー因果性・転送エントロピー・コープマン演算子解析・AI（GCN・メタ学習）が時系列から伝播構造を推定する。(5) 感染症・電力網・ロボット群・脳神経科学という多様な応用で伝播の基本数学（反応拡散・蔵本・カスケード）が共有されるが、進歩はシステム依存であり横断転用は限定的。**新規ページ**: source 1 + entity 4([[Peng Ji]]・[[Jürgen Kurths]]・[[Matjaž Perc]]・[[University of Maribor]]) + concept 2([[複雑ネットワーク]]・[[信号伝播]])。 --- 2026-06-19: **Chandola+ 2009「Anomaly Detection: A Survey」ingest** — [[Varun Chandola]]・[[Arindam Banerjee]]・[[Vipin Kumar]]([[University of Minnesota]])の ACM Computing Surveys 論文 [[@2009__CSUR__Anomaly Detection - A Survey]] を wiki 化。**核心**: (1) 異常検知は入力データ、異常の型、ラベル条件、出力形式で定式化が変わる。(2) 異常の型は点異常・文脈異常・集合異常。文脈異常は同じ振る舞い属性でも時間・場所・ユーザー等の文脈により異常性が変わる。(3) 技法群は分類・近傍・クラスタリング・統計・情報理論・スペクトルの 6 群で、それぞれラベル、距離尺度、分布仮定、情報量尺度、低次元射影での分離可能性など異なる仮定に依存する。(4) 実応用では文脈異常・集合異常が重要だが、アルゴリズム研究は点異常へ偏っていた。**横断知見追加**: [[異常検知]] に、Chandola 2009 を 2015 PADBI・2021 マイクロサービスサーベイ・現代 AIOps/LLM 異常検知へ接続する基礎 taxonomy として追記。**新規ページ**: source 1 + entity 4([[Varun Chandola]]・[[Arindam Banerjee]]・[[Vipin Kumar]]・[[University of Minnesota]])。 --- 2026-06-19: **System@Scale「AI Observability」(Meta, 2023) ingest** — [[Valentin Andrei]] ほか([[Meta]])が System@Scale 2023 で発表した AI ワークロード向け 4 層オブザーバビリティスタック [[@2023__SystemAtScale__AI Observability]] を wiki 化。**核心**: (1) 4 層は「ベアメタルテレメトリ([[Dynolog]])→高度イントロスペクション([[Kineto]]/Strobelight/Gpusnoop)→スケール分析プラットフォーム(自動回帰検知)→フリートダッシュボード」で構成され、ジョブ/ユーザー/モデル/プロダクト別リソース帰属を実現する。(2) 効率指標は FLOPs/sec(一次)と rDevice hour/Byte(正規化コスト)の 2 軸。(3) [[LibAsicMon]] はプラットフォーム非依存で GPU・MTIA・推論アクセラレータを統一観測し、ヘテロジーニアスなアクセラレータ構成に対応する。(4) Gpusnoop は BPF ベースで CUDA イベントとメモリを追跡し、研究コミュニティの eInfer・eGPU と目的が重複するが産業規模での実装として先行する。**横断知見追加**: [[GPU観測性]] に「研究視点(単一プロファイラの低オーバーヘッド化)vs. Meta 産業視点(複数ツールのスタック組織化)」という対比と、FLOPs/sec vs. MFU の指標比較を追記。**新規ページ**: source 1 + entity 4([[Valentin Andrei]]・[[Dynolog]]・[[LibAsicMon]]・[[Kineto]])。**更新ページ**: [[GPU観測性]]・[[Meta]]。 --- 2026-06-19: **Karpathy「LLM Wiki」で稲見3部作考察を更新** — [[Andrej Karpathy]] の GitHub Gist [[@2026__GitHub Gist__LLM Wiki]](2026-04-04) を ingest し、稲見昌彦3部作の考察（[[個人的知識蓄積の意味-稲見3部作から]]）を更新。**核心的な更新**: (1) 稲見は「wiki を書くことが調律行為になる」と結論したが、Karpathy は「書く（bookkeeping）は LLM の仕事であるべきボトルネック」と論じた。「調律の媒体は書くことか、選ぶ・問うことか」という未解決の問いが浮上。(2) [[サイバネティクス]] に **Bush(1945)–Wiener(1948)–Karpathy(2026) の 80 年の収束**を追記。(3) [[Human-out-of-the-loop]] に稲見（出力側 = 翻訳者）vs Karpathy（入力側 = キュレーター）の役割非対称性を追記。**新規ページ**: source 1 + entity 2([[Andrej Karpathy]]・[[Vannevar Bush]]) + concept 1([[LLM Wikiパターン]])。 --- 2026-06-19: **JANOG56「AI/ML基盤における800GbEスイッチ導入とその挑戦」ingest** — [[小障子 尚太朗]]・[[疋田 紅樹]]([[サイバーエージェント]] [[CIU]])が 2025 年 7 月 31 日に JANOG56 Day2 で発表した 800GbE スイッチ導入事例 [[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]] を wiki 化。**核心**: (1) Juniper [[Juniper QFX5240]](Broadcom ASIC)と NVIDIA SN4700(Mellanox ASIC)の混在 Rail-Optimized 構成で、AR/DLB の単純 on/off では輻輳制御が破綻し、Spine の Ingress interface hashing + Leaf の DLB の組み合わせによってデフォルト比ほぼ 2 倍の帯域を達成。DLB の inactivity-interval には安定最適値が存在せず経験的チューニング。(2) 3 ノード以上の AllReduce では `NCCL_CROSS_NIC=0` を設定しないと Spine 越えのリングが形成される(特に奇数ノード)。設定で Leaf 内にリングが閉じ、性能劣化なし。(3) NVIDIA DGX H100 と DELL XE9680 の混在時に GPU/NIC の物理ポート番号体系の違いにより NIC-Leaf 対応がずれて Spine 越えトラフィックが発生、手動配線修正で解消。(4) SN-MT(VSFF)コネクタで MPO 比 4 倍のパッチパネル密度と 1/2 のラック間ケーブル数を実現。(5) Cycloud が 2025 年 6 月の TOP500 で国内 15 位(世界 132 位)に登録(Rmax 10.82 PFlop/s、37,376 コア)。**新規ページ**: source 1 + entity 5([[サイバーエージェント]]・[[CIU]]・[[小障子 尚太朗]]・[[疋田 紅樹]]・[[Juniper QFX5240]]) + concept 2([[Rail-Optimizedトポロジ]]・[[マルチベンダーLosslessネットワーク]])。**更新ページ**: [[集合通信]]・[[データセンター輻輳制御]]・[[GPUクラスタ運用]]。transcript なし、全 47 ページ画像確認済み(主要 7 ページを視覚確認)。 --- 2026-06-19: **稲見昌彦「科学とAIとループ」3部作エッセイ（note.com）batch ingest** — [[稲見昌彦]]([[東京大学先端科学技術研究センター]])が 2026 年 2 月に連続投稿した3本の note 記事 [[@2026__note.com__科学の終焉と、新しい科学の始まり]]・[[@2026__note.com__Out of the Blue]]・[[@2026__note.com__ループのボトルネックは、人間だ]] を wiki 化。**核心**: (1) 3部を貫くテーゼは「AI がループを自律的に回すとき、そのループから外れた人間はどこへ行くか」。第一部は因果推論から構造圧縮への科学の転換と[[Human-out-of-the-loop]]の理論化([[サイバネティクス]]・[[アロスタシス]])、第二部は「out of the loop の先は inside the loops」として[[See-through]]/[[Feel-through]]・[[光学迷彩]]・[[調律]]の感覚拡張概念を展開、第三部は CES 2026 体験から[[バイブコーディング]]の没入感を分析しライプニッツの[[モナド論]]でAIループを「操作」から「感じ取る窓」へ転換することを提唱。(2) [[稲見昌彦]]自身の研究テーマ([[テレイグジスタンス]]・[[光学迷彩]])が第二・三部の具体例として登場。(3) [[ノーバート・ウィーナー]]は第一・二部の共通参照軸として機能する。**新規ページ**: source 3 + entity 10([[稲見昌彦]]・[[東京大学先端科学技術研究センター]]・[[ノーバート・ウィーナー]]・[[マックス・テグマーク]]・[[舘暲]]・[[ゴットフリート・ライプニッツ]]・[[ジェンスン・フアン]]・[[ティモシー・リアリー]]・[[ヘレン・ケラー]]・[[VPL社]]) + concept 13([[Human-out-of-the-loop]]・[[サイバネティクス]]・[[アロスタシス]]・[[inside the loops]]・[[See-through]]・[[Feel-through]]・[[光学迷彩]]・[[拡張現実感]]・[[調律]]・[[バイブコーディング]]・[[テレイグジスタンス]]・[[情報顕微鏡]]・[[モナド論]])。並行 ingest によりロック競合は部分的に発生したが全ページ正常マージ済み。 --- 2026-06-19: **SREcon19 EMEA「Latency SLOs Done Right」ingest** — [[Heinrich Hartmann]]([[Circonus]])の 2019 年講演資料 [[@2019__SREcon19 EMEA__Latency SLOs Done Right]] を wiki 化。**核心**: (1) レイテンシ SLO は「対象期間の全リクエストのうち、しきい値以内で処理された割合」を数える問題であり、パーセンタイル時系列を眺める問題ではない。(2) パーセンタイルは複数週間・複数ノードをまたいで集約できず、時間ごとの p90 平均は全体分布の p90 とずれる。資料例では全体 p90 35.8ms に対し平均 p90 60.3ms。(3) 実装経路はログ、しきい値別カウンタ、[[ヒストグラムメトリクス]]の 3 種で、ログは正確だが保存コストが高く、カウンタは安価だがしきい値を事前に決める必要があり、ヒストグラムはしきい値と集約粒度を後から選べる。**新規ページ**: source 1 + entity 2([[Heinrich Hartmann]]・[[Circonus]]) + concept 1([[ヒストグラムメトリクス]])。**更新ページ**: [[サービスレベル目標]]。transcript なし、全 33 ページ画像確認済み。 --- 2026-06-19: **マイクロサービス障害診断包括サーベイ「Failure Diagnosis in Microservice Systems: A Comprehensive Survey and Analysis」ingest** — [[Shenglin Zhang]] ほか([[Nankai University]] / [[Microsoft]] / [[Tsinghua University]])の arXiv 2024 論文 [[@2024__arXiv__Failure Diagnosis in Microservice Systems - A Comprehensive Survey and Analysis]] を wiki 化。**核心**: (1) 2003〜2024 年の 98 論文をログ・メトリクス・トレース・マルチモーダルの 4 カテゴリと RCL/FC の 2 タスクで体系化。(2) マルチモーダル融合の進化線: result fusion → model fusion → feature fusion。(3) PC アルゴリズム + ランダムウォーク(MonitorRank 起源)がメトリクスベース RCL の古典的パイプラインとして最多再利用。(4) 公開データセット 10 種(GAIA・AIOps Challenge シリーズ等)・ツールキット 20 種(DiagFusion・Nezha・Eadro 等)・評価メトリクスを初めて一覧化。(5) 今後の重要方向として LLM + 知識グラフ統合・説明可能性向上・ノイズ耐性を明示。**新規ページ**: source 1。**更新ページ**: [[Shenglin Zhang]]・[[マルチモーダル障害診断]]・[[根本原因分析]]。 --- 2026-06-19: **GRLIA「Graph-based Incident Aggregation for Large-Scale Online Service Systems」ingest** — [[Zhuangbin Chen]] ほか([[The Chinese University of Hong Kong]] / [[University of Newcastle]] / [[Huawei Cloud]])の ASE 2021 論文 [[@2021__ASE__Graph-based Incident Aggregation for Large-Scale Online Service Systems]] を wiki 化。**核心**: (1) [[GRLIA]] は EVT による incident burst 検知、Jaccard + KPI DTW による障害影響グラフ補完、DeepWalk/Word2Vec による incident type 表現学習、トポロジ距離つきオンライン集約から成る。(2) 重要な設計点は、フォールトトレランスやモニタ閾値により障害伝播経路上の中間サービスが incident を出さない「沈黙ノード」を KPI で補完すること。(3) Huawei Cloud Networking サービスの 2020 年 5〜11 月本番データで、集約 NMI 0.831/0.866/0.912、固定閾値検知より高い F1、補完なしアブレーション比の改善を示す。(4) Huawei Cloud のインシデント管理システムに展開され、2020 年 11 月の 26 障害で平均対応時間を過去 3 か月比 18.6〜24.8% 短縮。**新規ページ**: source 1 + entity 4([[GRLIA]]・[[OpsPAI]]・[[Xuemin Wen]]・[[Xiao Ling]])。**更新ページ**: [[アラート集約]]・[[インシデント管理]]・[[サービス依存グラフ]]・[[グレイ障害]] ほか。 --- 2026-06-18: **SpeakerDeck「AIスーパーコンピュータにおけるLLM学習処理性能の計測と可観測性」ingest** — [[Yuuki Tsubouchi]]([[SAKURA Internet]])の 2025 年度情報処理学会中国支部主催講演会資料 [[@2025__SpeakerDeck__AIスーパーコンピュータにおけるLLM学習処理性能の計測と可観測性]] を wiki 化。**核心**: (1) AI 学習ワークロードが計算機・ネットワークアーキテクチャを規定し、Transformer の行列積和、GPU、メモリ壁、集団通信、RDMA/RoCE、ストレージを縦断的に理解する必要がある。(2) [[SAKURAONE]] は講演資料上で H100/H200/B200 の 3 クラスタ構成として示され、GPT-3 175B 事前学習ベンチマークでは 32 ノード 105.310 分、96 ノード 41.862 分、MFU 38.3%/35.9% を示す(unverified)。(3) AI スパコンサービスの可観測性は、ユーザーの学習性能・計算資源利用率と、プロバイダの障害・故障管理・計算資源利用率を分け、責任境界により OTel + Grafana のリソース分析から始まる。(4) ギャップは学習処理性能のボトルネック特定、アプリケーションかインフラかの切り分け、マイクロバースト監視であり、GPU ゼロコード計装と [[R-Pingmesh]] 型 RoCE 能動プロービングが研究・実装方向として示される。(5) 追加 transcript では、64 ノード級の不安定さから 32 ノードなど安定構成へ寄せる運用判断、リザーブドノードによる代替、チェックポイント復旧、推論との障害管理差が補足された。**新規ページ**: source 1。**更新ページ**: [[Yuuki Tsubouchi]]・[[SAKURA Internet]]・[[SAKURAONE]]・[[R-Pingmesh]]・[[GPU観測性]]・[[LLM学習モニタリング]]・[[RDMAネットワーク監視]]。transcript あり(`.raw/slides/ai-supercomputer-llm-benchmarking-and-observability/transcript.md`)、全 130 ページ画像確認済み。 --- 2026-06-18: **Anthropic Engineering Blog「Introducing Contextual Retrieval」ingest** — [[Daniel Ford]]([[Anthropic]])の 2024-09-19 記事 [[@2024__Anthropic Engineering Blog__Introducing Contextual Retrieval]] を wiki 化。**核心**: (1) RAG のチャンク分割で文書全体の文脈が失われることが検索精度低下の主因。各チャンクの先頭に LLM 生成の約 50〜100 トークンの文脈テキストを付与してから埋め込み・BM25 両索引に格納することで解決する(Contextual Embeddings + Contextual BM25)。(2) Top-20 取得の検索失敗率: ベースライン 5.7% → Contextual Embeddings のみ 3.7%(35% 削減) → + Contextual BM25 で 2.9%(49% 削減) → + リランキングで 1.9%(67% 削減)。BM25 の付加は 14% 追加削減をもたらし、語彙一致検索がベクトル埋め込みを補完することを実証。(3) プロンプトキャッシング活用で約 $1.02/百万ドキュメントトークンと低コスト。Voyage・Gemini Text-004 が最高性能の埋め込みモデル。(4) 二次ソース([[joisino-否定文理解-2024]])の「5.0% → 2.9%」とベースライン数値(5.7%)に齟齬あり; 一次資料を正とし [[文脈付き検索]] に contradiction callout を追記。**新規ページ**: source 1 + entity 1([[Daniel Ford]])。**更新ページ**: [[文脈付き検索]](seed → developing; 一次資料数値・BM25・リランキング・横断的知見・contradiction callout を追加)・[[Anthropic]](ソース追加・数値修正)。 --- 2026-06-18: **PyTorch Conference 2025「Scaling KV Caches for LLMs: How LMCache + NIXL Handle Network and Storage Heterogeneity」ingest** — [[Moein Khazraee]]([[NVIDIA]])・[[Junchen Jiang]]([[University of Chicago]] / [[LMCache]])の講演資料 [[@2025__PyTorchConference__Scaling KV Caches for LLMs - How LMCache + NIXL Handle Network and Storage Heterogeneity]] を wiki 化。**核心**: (1) 長コンテキスト推論では Prefill が TTFT とコストを支配し、共有コンテキストを各エンジンで再 Prefill するのは遅い。(2) [[LMCache]] は GPU-GPU 転送、GPU-CPU 退避、CPU-CPU 転送、ストレージ退避を扱う KV キャッシュ層として [[vLLM]] / [[SGLang]] とストレージバックエンドの間に置かれる。(3) [[NIXL]] は Memory Section と Metadata Handler により DRAM/VRAM/BLK/FILE/OBJ を登録し、UCX/GDS/OBJ 等のバックエンドで非同期・非ブロッキング・非連続・ゼロコピー転送を行う。(4) VAST Storage 例では Qwen3-235B-A22B-Instruct-2507-fp8 / 8×H100 で、ISL 224K 付近の KV 再計算 TTFT 約 36 秒に対し、ストレージ取得は約 4 秒弱に抑えられる。**新規ページ**: source 1 + entity 1([[Moein Khazraee]])。**更新ページ**: [[Junchen Jiang]]・[[LMCache]]・[[NIXL]]・[[KVキャッシュ管理]]・[[LLM推論]]・[[Prefill-Decode分離]]。transcript なし、全 20 ページ画像確認済み。 --- 2026-06-18: **FlashAttention シリーズ 4 本 + AIBrix ingest** — FA1(arXiv:2205.14135)・FA2(arXiv:2307.08691)・FA3(arXiv:2407.08608)・FA4(arXiv:2603.05451)の FlashAttention 全 4 世代と AIBrix(arXiv:2504.03648)を wiki 化。**核心**: (1) **IO-aware 厳密アテンション 4 世代の進化**: FA1 はタイリング＋オンライン softmax で HBM 読み書きを O(N²d²M⁻¹) に削減し 2-4 倍高速化。FA2 は非 MMA FLOP 削減＋シーケンス長並列化で A100 利用率 73%・225 TFLOP/秒。FA3 は Hopper のワープ特化＋FP8 ブロック量子化で 740 TFLOP/秒（75%）。FA4 は Blackwell でソフトウェアエミュレート指数関数＋TMEM＋2-CTA MMA＋CuTe-DSL で 1613 TFLOP/秒（71%）。ボトルネックは HBM 帯域→非 MMA 演算→指数関数ユニットへ移動し、利用率は 70-75% で構造的天井に達する。(2) **AIBrix**: Kubernetes＋Ray ハイブリッドのクラウドネイティブ LLM 推論フレームワーク。分散 KV キャッシュ(scan-resistant eviction)で 50% スループット向上・70% レイテンシ削減。LLM 固有オートスケーリング・LoRA 多重化・SLO 駆動 GPU 最適化・vendor-neutral sidecar を統合。DistServe(research-first)・NVIDIA Dynamo(full-stack hardware co-design)と並ぶクラウドネイティブ・アーキタイプ。**新規ページ**: source 5 + concept 1([[FlashAttention]]) + entity 2([[Tri Dao]]・[[Jay Shah]])。**更新ページ**: [[Together AI]]・[[AIBrix]]・[[LLM推論]]・[[カーネルフュージョン]]・[[テンソルコア]]・[[GPU最適化]]・[[KVキャッシュ管理]]・[[Prefill-Decode分離]]。 --- 2026-06-18: **GPT-4 Technical Report(arXiv:2303.08774)ingest** — OpenAI 2023 年の GPT-4 技術報告を wiki 化。**核心**: (1) **予測可能スケーリング**: 1/1,000〜1/10,000 の計算量のモデルに不可逆損失項付き冪乗則 $L(C) = aC^b + c$ をフィットし、GPT-4 の内部損失と HumanEval パス率を訓練完了前に正確に外挿した。逆スケーリング賞タスク(Hindsight Neglect)を反転させた事例はスケーリング則の創発的逆転を示唆。(2) **能力水準**: 模擬バー試験上位 10%(298/400)、MMLU 86.4%(GPT-3.5: 70.0%)、GSM-8K 92.0%、HumanEval 67.0%。26 言語中 24 で他モデルの英語性能を超過。GPT-4 の MMLU スコアは「ベンチマーク飽和の起点」となった。(3) **RLHF キャリブレーション劣化**: 事前学習モデルの ECE 0.007 が RLHF 後に 0.074 へ急増。挙動改善と確信度信頼性のトレードオフが定量化された。(4) **安全性**: 専門家 50 名超レッドチーム + RBRM(ルールベース報酬モデル)で禁止コンテンツ応答 GPT-3.5 比 82% 削減。毒性生成率 0.73%(GPT-3.5: 6.48%)。アーキテクチャ詳細は競合・安全上の理由で非公開。**新規ページ**: source 1([[@2023__arXiv__GPT-4 Technical Report]])。**更新ページ**: [[OpenAI]]・[[LLMスケーリング則]]・[[LLM評価]]・[[RLHF誤誘導]]。 --- 2026-06-18: **KV キャッシュ・GPU クラスタ論文 5 本一括 ingest** — KVCache Cache in the Wild(Aliyun 本番トレース)・MLaaS in the Wild(Alibaba PAI 6,742 GPU)・CacheBlend(RAG 向け非プリフィックス再利用、EuroSys 2025 Best Paper)・KVShare(マルチテナント DHD + デコードフェーズ・ドリフト)・SCBench(KV キャッシュ中心長コンテキストベンチマーク、ICLR 2025)。**核心**: (1) 本番 KV キャッシュヒット率は合成の 80% 超に対し 54-62% にとどまり、to-B の再利用 97% がシングルターン起因。ワークロード対応エビクション(カテゴリ別指数分布 + 空間局所性)が LRU 比で最大 41.4% QTTFT 削減。(2) 非プリフィックス KV 再利用は CacheBlend(KV 偏差上位 10-20% トークンの選択的再計算)→ KVShare(アテンション重み×KV 偏差の DHD + デコードフェーズのアテンション・ドリフト対処)へ発展。(3) SCBench は sub-O(n) メモリ手法がマルチターン(KV 再利用)で破綻し、O(n) メモリ + 動的スパースアテンションが堅牢であることを示す。長コンテキスト評価は単一リクエストでなく KV キャッシュライフサイクル全体で行う必要がある。(4) Alibaba PAI 異種混合クラスタでは GPU SM 中央値使用率 0.042 GPU、GPU 共有で必要 GPU 平均 50% 削減だが CPU 競合が新ボトルネック。**新規ページ**: source 5 + entity 16。**更新ページ**: [[KVキャッシュ管理]]・[[LLM推論]]・[[GPUクラスタスケジューリング]]・[[Tsinghua University]]・[[Microsoft Research]]・[[Alibaba Group]]・[[Yuhan Liu]]。 --- 2026-06-18: **Mooncake arXiv 2407.00079 ingest** — [[Ruoyu Qin]]・[[Zheming Li]] ほか([[Moonshot AI]] / [[Tsinghua University]] MadSys)の [[@2024__arXiv__Mooncake - A KVCache-centric Disaggregated Architecture for LLM Serving]] を wiki 化。**核心**: (1) Kimi 本番サービスは Prefill Pool・KVCache Pool・Decoding Pool の 3 プールを分離し、CPU/DRAM/SSD をクラスタ規模の KVCache 第一階層として使う。GPU VRAM は Layer-wise 非同期転送でバッファ的に使い、Prefill 完了後すぐ退避する。(2) [[@2026__ICLR__Learning to Orchestrate Agents in Natural Language with the Conductor|Conductor]] は KVCache 中心スケジューリング(Algorithm 1)で、キャッシュヒット長・転送時間・推定 TTFT を加算最小化してインスタンスを選択。ランダムルーティング比 8P+8D クラスタで平均 TTFT 92 s → 6.26 s に改善。(3) [[Chunked Pipeline Parallelism]](CPP)で長コンテキスト Prefill を複数ノードに分散し、シーケンス並列(SP)より少ないノード間通信で実行可能。(4) 過負荷指向スケジューリングは、Early Rejection(Decode 負荷を事前評価)+ 予測ベース Early Rejection(振動防止)の 2 層構成。単純 Early Rejection のみでは Prefill/Decode 間で逆位相振動(図 9)が発生するため、均一デコード時間 t_d 仮定のバッチ数推定で将来負荷を予測する。(5) DistServe/P/D-Serve と異なる点は、**過負荷 MaaS を前提設計している**こと — 実験の基本条件が GPU 台数不足で全リクエスト処理不能な状態であり、Goodput 最大化と Early Rejection が共存する。**新規ページ**: source 1 + entity 7([[Ruoyu Qin]]・[[Zheming Li]]・[[Weiran He]]・[[Mingxing Zhang]]・[[Yongwei Wu]]・[[Weimin Zheng]]・[[Xinran Xu]])。**更新ページ**: [[KVキャッシュ管理]]・[[Prefill-Decode分離]]・[[LLM推論]]・[[Mooncake]]・[[Moonshot AI]]・[[Tsinghua University]]。 --- 2026-06-18: **MPLS JAPAN 2025「A study on accelerating LLM inference using KV cache sharing with IOWN APN」ingest** — [[田仲顕至]]([[NTT]] デバイスイノベーションセンタ)の講演資料 [[@2025__MPLSJapan__A study on accelerating LLM inference using KV cache sharing with IOWN APN]] を wiki 化。**核心**: (1) LLM 推論需要と電力インフラ制約に対し、小規模データセンターを分散配置し、[[IOWN APN]] でリクエストルーティングと KV キャッシュ共有を行う構想。(2) KV キャッシュ共有はユーザー間共有であり、prefix 前方一致制約とコンテキスト間依存の再計算が難所。CacheBlend/KVShare が部分再計算により Prefill 削減と精度維持を狙う。(3) Mistral-7B-Instruct-v0.2・入力 1K・KV キャッシュ 120 MB・A100 の帯域評価で、10G で約 9 割、100G で約 8 割の TTFT 削減。(4) Llama-3.1-8B・平均約 65K 入力・KV キャッシュ約 8 GB・A100 x1/node の APN 距離エミュレーションで、100 km 離れても TTFT 短縮効果の変化は 8%、電力効率は 2.31x。**新規ページ**: source 1 + entity 3([[田仲顕至]]・[[NTT]]・[[IOWN APN]])。**更新ページ**: [[KVキャッシュ管理]]・[[LLM推論]]・[[AI Greenferencing]]。transcript なし、全 24 ページ画像確認済み。 --- 2026-06-18: **分散深層学習の通信・スケジューリング・ネットワーク基盤 15 論文一括 ingest** — RDMA 大規模展開・輻輳制御(DCQCN SIGCOMM'15、Microsoft RDMA SIGCOMM'16、Meta RDMA SIGCOMM'24)、RoCE 設計課題(IEEE Computer 2023)、GPU クラスタスケジューリング(Tiresias NSDI'19、Themis NSDI'20)、GPU 利用率実証(ICSE'24)、集合通信最適化(MSCCL NSDI'22)、混合精度訓練(FP16 Tensor Core SC'18)、ネットワークトポロジ(Dragonfly ISCA'08/IEEE Micro'09、HammingMesh SC'22、Rail-only arXiv'23)、Ethernet ベンチマーク(SC-W'24)、ML クラスタ信頼性(HPCA'25 既取込)の 15 本を wiki 化。**核心**: (1) RDMA 展開は DCQCN(2015)→Microsoft 全 DC(2016)→Meta 24k GPU AI 訓練(2024)と進化。Meta は DCQCN を AI 集合通信に不向きとし受信側駆動許可制御に転換、NCCL デフォルト比 2 倍以上改善。(2) Hoefler+ 2023 は RoCE の 8 構造的欠陥を体系化し「TCP/RoCE は 10 年内に次世代 Ethernet に置換」と予測。(3) Tiresias(2DAS)と Themis(仕上がり時間公平性+オークション)は、ジョブ長不明/公平性不可能定理という GPU スケジューリング固有の困難に異なるアプローチで解を提示。(4) ネットワークトポロジは Fat-Tree 一辺倒から Dragonfly(コスト O(N^1/2))、HammingMesh(帯域分離+汎用帯域)、Rail-only(スパイン層削除で 38-77% コスト削減)へ多様化。**新規ページ**: source 14 + concept 3([[Dragonflyトポロジ]]・[[データセンター輻輳制御]]・[[RoCE設計課題]]) + entity 多数。**更新ページ**: [[RDMA]]・[[GPUクラスタスケジューリング]]・[[Fat-Tree]]・[[集合通信]]・[[混合精度訓練]]・[[GPUクラスタ運用]]。 --- 2026-06-18: **LLM 推論 KV キャッシュ管理/分離型推論 6 論文 ingest** — vLLM/PagedAttention(SOSP 2023)、SGLang(NeurIPS 2024)、LMCache(arXiv 2025)、P/D-Serve(arXiv 2024)、Zhou+ efficient inference survey(arXiv 2024)、Aravilli+ From Attention to Disaggregation(arXiv 2025)を wiki 化。**核心**: (1) [[@2023__SOSP__Efficient Memory Management for Large Language Model Serving with PagedAttention]] は [[vLLM]] と PagedAttention を提案し、KV キャッシュを非連続 GPU メモリ上の固定ブロックとして管理、FasterTransformer/Orca 比 2-4 倍スループット改善。(2) [[@2024__NeurIPS__SGLang - Efficient Execution of Structured Language Model Programs]] は [[SGLang]] と RadixAttention で LM プログラムの prefix 共有を runtime 化し、最大 6.4 倍スループット、Chatbot Arena で Vicuna-33B first-token latency 1.7 倍削減。(3) [[@2025__arXiv__LMCache - An Efficient KV Cache Layer for Enterprise-Scale LLM Inference]] は KV キャッシュを GPU 外階層ストレージ/転送の第一級データ構造にし、vLLM と組み合わせ最大 15 倍スループット改善。(4) [[@2024__arXiv__P-D-Serve - Serving Disaggregated Large Language Model at Scale]] は Huawei の数万 NPU 商用展開で scenario 単位 P/D group、on-demand forwarding、block-free D2D transfer を提案し、集約型比 6.7 倍 throughput。(5) [[@2024__arXiv__A Survey on Efficient Inference for Large Language Models]] は data/model/system 三層タクソノミー、[[@2025__arXiv__From Attention to Disaggregation - Tracing the Evolution of LLM Inference]] は attention から disaggregation への発展史を整理。**横断知見**: KV キャッシュ最適化は GPU 内 page 管理から、prefix 木、階層ストレージ、RoCE/NIXL 転送、cache-aware scheduling へ拡張した。GPU 内で有利な page 粒度はネットワーク/ストレージ転送には小さすぎるため、外部転送では chunk/block-free 化が必要になる。**新規ページ**: source 6 + concept [[KVキャッシュ管理]] + entity 10([[SGLang]]・[[P-D-Serve]]・[[Tensormesh Inc]]・[[Infinigence-AI]]・[[Capital One]] ほか)。**更新ページ**: [[LLM推論]]・[[Prefill-Decode分離]]・[[vLLM]]・[[LMCache]]。 --- 2026-06-18: **LLM 推論サービング論文 2 本 ingest(DistServe OSDI 2024 / Taming the Titans INLG 2025)** — [[Yinmin Zhong]]・[[Shengyu Liu]] ほか([[Peking University]] / [[UC San Diego]] / [[StepFun]])の OSDI 2024 論文 [[@2024__OSDI__DistServe - Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving]] と、[[Ranran Zhen]]・[[Juntao Li]] ほか([[Soochow University]] / [[Huawei Cloud]])の INLG 2025 サーベイ [[@2025__INLG__Taming the Titans - A Survey of Efficient LLM Inference Serving]] を wiki 化。**核心**: (1) DistServe は Prefill と Decode の同居が TTFT/TPOT 干渉と資源・並列化結合を生むことを示し、段階別 GPU 割当・テンソル並列・パイプライン並列・帯域考慮配置で per-GPU Goodput を最大化する。vLLM/DeepSpeed-MII 比で最大 7.4 倍高いリクエスト率または 12.6 倍厳しい SLO、OPT-175B でも KV キャッシュ転送は総レイテンシ 0.1% 未満。(2) Taming the Titans は LLM 推論サービングをインスタンスレベル(モデル配置・スケジューリング・KV キャッシュ・[[Prefill-Decode分離]]・マルチプレクシング)、クラスタレベル(異種 GPU・ロードバランシング・クラウド/エッジ)、新興シナリオ(長コンテキスト・RAG・MoE・LoRA・投機的復号・エージェント・マルチモーダル)に階層化した。**横断知見**: PD 分離は単一システム技法から LLM 推論サービングの主要カテゴリに昇格し、評価軸は raw TPS/RPS から TTFT/TPOT SLO を満たす Goodput へ移っている。**新規ページ**: source 2 + concept [[Prefill-Decode分離]] + entity 19([[DistServe]]・著者・所属機関)。**更新ページ**: [[LLM推論]]・[[Peking University]]・[[Huawei Cloud]]・[[Yibo Zhu]]・[[Xin Jin]]・[[Hao Zhang]]・[[vLLM]]。 --- 2026-06-18: **SpeakerDeck「推論基盤のパフォーマンス検証と最適化戦略」ingest** — [[道下幹也]]([[SAKURA Internet]])が 2026-03-06 に公開した第 3 回 vLLM roundup Community Meetup Tokyo 登壇資料を wiki 化([[@2026__SpeakerDeck__推論基盤のパフォーマンス検証と最適化戦略]])。**核心**: (1) LLM 推論基盤は「高スペック GPU が必要か否か」ではなく、ビジネスモデル、サービス規模、ユーザー体験、SLO/SLA から最適化対象を決める。TTFT・ITL・E2EL・RPS・TPS・Goodput と Tokens/Dollar が評価軸。(2) PD Disaggregation は同一 4 GPU 条件でも入力 8k・出力 1k・32 同時接続で ITL P99 を 30 ms 以内に維持し、Aggregated の 100 ms 超と差が出る。(3) Mooncake Store を使った KV Cache Reuse/Sharing は、8k 入力でキャッシュヒット量を増やすほど TTFT を改善し、最大 1.75 倍程度削減。(4) ただし完全ヒット近傍でも KV Cache 読み込みが TTFT の約 1/4 を占める点は要調査。**更新ページ**: [[LLM推論]]、[[サービスレベル目標]]、[[道下幹也]]、[[SAKURA Internet]]、[[高火力 PHY]]、[[vLLM]]、[[LMCache]]、[[Mooncake]]。transcript なし、全 34 ページ画像確認済み。 --- 2026-06-17: **分散深層学習の訓練系基盤論文 14 本一括 ingest** — 2018〜2025 年の分散 DNN 訓練基盤の主要論文 14 本（+ 既取り込み済み 1 本の重複確認）を一括 wiki 化。**系譜の全体像**: (1) **テンソル並列**: Megatron-LM(Shoeybi+ arXiv 2019)が MLP・自己注意の行列分割で層内並列化を確立、83 億パラメータ/512 V100 で理論ピーク 76%。(2) **パイプライン並列**: GPipe(Huang+ NeurIPS 2019)のマイクロバッチ方式と PipeDream(Narayanan+ SOSP 2019)の 1F1B 方式が独立に提案、後者が重み隠蔽でメモリ効率を改善。(3) **3D 並列(PTD-P)**: Megatron-LM SC'21(Narayanan+)がテンソル・パイプライン・データの 3 軸を統合し 1 兆パラメータ/3072 A100/MFU 52% を実証。(4) **メモリ最適化**: ZeRO(Rajbhandari+ SC 2020)の Stage 1〜3 段階分割 → PyTorch FSDP(Zhao+ VLDB 2023)の FlatParameter 産業実装。(5) **活性化再計算**: MLSys'23(Korthikanti+)の選択的再計算 + シーケンス並列化で 530B モデルの活性化メモリ 5 倍削減。(6) **混合精度**: FP8-LM(Peng+ arXiv 2023)が FP8 事前訓練で GPT-175B メモリ 42% 削減・64% 高速化を初めて体系検証。(7) **GPU クラスタスケジューリング**: HiveD(Zhao+ OSDI 2020)の共有異常発見 + VC 保証と Cassini(Rajasekaran+ NSDI 2024)のネットワーク対応配置。(8) **通信特性**: APNet'24(Li+)が 3D 並列の通信プロファイルを初めて実測体系化（TP AllReduce 55〜85% 帯域占有）。(9) **耐障害**: FFTrainer(Zhao+ arXiv 2025)が遊休帯域チェックポイント + checkpoint razor で復旧を数十秒に短縮。(10) **分散フレームワーク**: Ray(Moritz+ OSDI 2018)がタスク並列 + アクターモデル統合で 1.8ms/100 万タスク/秒を達成。**新規ページ**: source 14 + entity 29 + concept 15。**更新ページ**: concept 6 + entity 5。**横断的な発見**: (a) 2019 年にテンソル並列・パイプライン並列・ZeRO が同時出現し、2021 年の PTD-P で統合。(b) ZeRO Stage 3 と PyTorch FSDP は同一原理の独立実装。(c) 選択的活性化再計算はシーケンス並列化と不可分。(d) APNet 実測により TP の AllReduce 帯域支配が定量確認され、NVLink 内閉じ込め設計の根拠が明確化。 --- 2026-06-17: **DICOMO 2022「AI時代に向けたクラウドにおける信頼性エンジニアリングの未来構想」スライド ingest** — [[Yuuki Tsubouchi]]・[[Hirofumi Tsuruta]]による DICOMO 2022 統一セッション「クラウド」招待講演スライドを wiki 化([[@2022__DICOMO__AI時代に向けたクラウドにおける信頼性エンジニアリングの未来構想]])。**核心**: (1) SRE は完全な信頼性でなく、信頼性目標を下限として変更速度を最大化する障害許容アプローチ。(2) AIOps はクラウド耐障害性の最外殻であるオペレータ手動制御を AI で支援・自動化するが、2022 年時点では補助的情報支援に留まる。(3) 2040 年代の [[セルフクラフト]] では、利用者が AI と対話的・体験的に信頼性・コスト・変更速度の均衡点を決める。(4) [[Interactive AIOps]] は、運用データ共有が難しい制約下で、オペレータが異常を作り AI に教える実験可能性と、AI が根拠を返す解釈性を基本型にする。**新規ページ**: source 1 + concept 2([[Interactive AIOps]]・[[セルフクラフト]])。**更新ページ**: [[AIOps]]・[[SRE]]・[[サービスレベル目標]]・[[自動化のアイロニー]]・[[Yuuki Tsubouchi]]・[[Hirofumi Tsuruta]]。 --- 2026-06-17: **自動化のアイロニー後続 2 論文 ingest(Baxter+ ECCE2012 / Strauch IEEE-THMS2017)** — Bainbridge (1983) の「Ironies of Automation」に対する 2 本の後続論文を wiki 化。[[@2012__ECCE__The Ironies of Automation Still Going Strong at 30]] (Baxter・Rooksby ほか、University of St Andrews、ECCE 2012) は 30 周年再検証で航空(名古屋 A300 墜落 1994)・金融(フラッシュクラッシュ 2010)・クラウド(AWS 障害 2011)の 3 ドメインにアイロニーの残存を確認し、**クラウドの低コストが企業の品質保証プロセスの迂回を可能にする新しいアイロニー**を特定した。[[@2017__IEEE THMS__Ironies of Automation - Still Unresolved After All These Years]] (Strauch、NTSB 退職、IEEE THMS 2017) は NTSB 事故調査官としての実務経験で Bainbridge のアイロニーを事故事例に精密対応させ、**3 つの新しいアイロニー**(技能マスキング: 自動化が既存能力不足を隠蔽 / 同一エラーの 30 年反復: 対気速度監視失敗 × 3 回 / 機能過多: 設計者がオペレータのニーズを超える機能を提供し訓練が追いつかない)を体系化した。**横断知見**: (1) 3 ソース(1983/2012/2017)を突き合わせると、信頼性・速度・安全管理体制は改善されたがアイロニーの構造そのもの——自動化がタスクを除去するのではなく変容させ、残された役割はより困難になる——は 40 年間不変。(2) 適用ドメインはプロセス産業→航空→金融→クラウド→自律走行車→スマートフォンへ拡大し、対象オペレータの訓練水準が下がるほど帰結は重大になりうる。(3) Baxter のクラウド低コストアイロニーは Bainbridge のどの類型にも直接対応しない新類型。(4) Strauch の技能マスキングは技能劣化の裏面——自動化は技能を劣化させるだけでなく技能の欠如を不可視にする。**新規ページ**: source 2 + entity 5(Gordon Baxter / John Rooksby / Barry Strauch / University of St Andrews / National Transportation Safety Board)。**更新ページ**: [[自動化のアイロニー]](横断的知見 5 件・未解決の問い 3 件追加、seed→developing)、[[Lisanne Bainbridge]](被引用数・研究軌跡補足)。 --- 2026-06-17: **ペパボ研究所 gpt-oss サービング評価 ingest** — [[三宅悠介]]([[GMOペパボ]])が 2025-08-18 公開した gpt-oss オープンウェイトモデルの Google Cloud 性能評価を wiki 化。**核心の知見**: (1) **H100 のみが並列スケーリングを有効に機能させ、A100/L4 はサービス用途には実質非推奨** — 「推論が動く」と「サービングに使える」は異なる条件。(2) **出力トークン数がスループットの律速要因** — 入力より影響が大きく、vLLM の continuous batching がデコードフェーズ(メモリバウンド)に依存することと整合する。(3) **Reasoning effort の選択がモデルサイズ選択と同等以上に重要** — `high` 設定で性能低下が顕著になるため、大規模モデル + medium effort が安定性の点で優位。モデルサイズ間の差は「2 倍以上にはならない」傾向。**横断知見**: NVIDIA 公式([[@2025__NVIDIA__LLM-Inference-Benchmarking-Fundamental-Concepts]])の ISL/OSL プロファイルで「推論タスク」(OSL≈1000〜10000)が最も OSL が大きいカテゴリと対応し、出力トークン制御が最重要になることを実装レベルで裏付ける。さくらのナレッジ([[@2025__さくらのナレッジ__分散推論基盤やその前提の考え方]])の Goodput 概念とも一致: H100 のみが並列増加で Goodput を向上できる。**新規ページ**: source 1([[@2025__ペパボ研究所__gpt-ossモデルのサービング性能評価]])・entity 2([[三宅悠介]]・[[GMOペパボ]])。**更新ページ**: [[vLLM]](gpt-oss benchmark 追記)・[[LLM推論]](GPU 世代別スケール可否 + Reasoning effort の横断的知見 2 件追加)。 --- 2026-06-17: **マイクロサービスベンチマーク/データセット 4 論文一括 ingest** — DeathStarBench(Gan+ ASPLOS 2019、Cornell)・Smith+ Train-Ticket+eShopOnContainers test benchmark(arXiv 2023、Baylor/Cerny+Taibi)・Amoroso d'Aragona+ OSS-MS dataset(MSR 2024、378 件)・Urbanke+Fischer TrainTicketTrace(SANER-C 2026、SCCH Hagenberg)を一括 wiki 化。**核心の系譜**: (1) DeathStarBench は 5(+1) サービス × 25-41 microservices で MSA の **ハードウェア/OS 層への圧迫**(front-end stalls・kernel 36.3%・single-thread 性能感度・1 dependency ミスで tail latency 10.4× 悪化)を実証研究で定量化した原典。自前 distributed tracing(Thrift timing interface + Zipkin Collector 派生)を overhead 0.1% で実装。(2) Smith+ 2023 は Train-Ticket(47 microservices)と eShopOnContainers(C# .NET)に対し Selenium + JUnit/TestNG + Gatling の test/load benchmark を Zenodo で公開、1,000 ユーザで両者合格・2,500 で不合格、login が共通の負荷脆弱点。(3) Amoroso d'Aragona+ MSR 2024 は World of Code 173M projects から 7 criteria + 6 軸手動ラベルで **378 件 OSS-MS dataset** を構築、`taskcluster`(50)・`FudanSELab/train-ticket`(42)等を含む microservice 研究の母集団を可視化。(4) TrainTicketTrace 2026 は Train-Ticket 42 services × 9 seeded fault branch + 1 cleaned baseline で **trace+metric+log の 3 modality dataset** を EvoMaster white-box + OpenTelemetry/Jaeger/Prometheus/Logback で構築、平均 440,000 traces/branch、計 380 時間データ収集、Gregor+ ICST 2025 taxonomy で fault 分類。**横断知見**: (a) **Train-Ticket が 3 論文に共通する benchmark system** として登場し microservice 研究の de facto 共通基盤化が裏付けられた。(b) **fault injection と benchmark の分離**: DeathStarBench は性能特性測定が主、後続の TrainTicketTrace 等が fault layer を追加。(c) EvoMaster の生成テストが seeded fault を **1 件も test では検出できなかった** が trace breadth/depth・endpoint coverage 差として残った観察は、test layer と observability layer の段の切れ目を示し、後者で fault detection 研究を進めるべき方向性を示唆。(d) **観測スタックの標準化**: 自前 trace(2019)→ Selenium+Gatling(2023)→ EvoMaster + OpenTelemetry + Jaeger + Prometheus(2026)と現代的な OSS スタックへ収束。**新規ページ**: source 4 + entity 16(著者・組織・ツール)+ concept [[マイクロサービスベンチマーク]]。**更新ページ**: [[DeathStarBench]] / [[Train-Ticket]] / [[マイクロサービスアーキテクチャ]] / [[マイクロサービスコールグラフ]] / [[分散トレーシング]] / [[Fault Localization]] / [[障害注入]]。 --- 2026-06-17: **Time-RA(ACL Findings 2026)ingest** — [[Yiyuan Yang]](Oxford)・[[Zichuan Liu]](南京大)・[[Qingsong Wen]]†(Squirrel Ai Learning) ほかが TSAD を二値識別から**生成型推論タスク**へ転換した TIME-RA と、実世界マルチモーダルベンチマーク **RATs40K** を wiki 化。**核心**: (1) TIME-RA は検知 + 単変量 14/多変量 6 種の細粒度分類 + Observation–Thought–Action 形式の因果説明を単一モデルに要求する新規タスク。(2) RATs40K は AnomLLM/LLMAD/VisualTimeAnomaly との比較で「実世界・10 ドメイン・約 4 万件・Time+Text+Image・Thought 付き」が揃う初の構成で、AI フィードバック(4 モデルプール→ GPT-4 優先選択・批評)によるアノテーション品質は専門家評価 Likert 4.04–4.58 で検証済み。(3) SFT(LoRA)で fine-tune した Qwen2.5-7B は未見ドメイン(SED/CATSv2)にプラグアンドプレイで転用でき、KNN/LOF/AE1SVM を上回り TSFM と競合。(4) 視覚化(折れ線画像)は分類精度より推論一貫性(Thought マッチング)向上に安定的に寄与する — ChatTS の「ネイティブ TS モダリティが数値タスクで優位」と組み合わせると「視覚 = 推論の橋渡し・ネイティブ = 定量精度の担い手」という役割分業が見える。**横断知見**: (a) [[時系列推論]] に「異常診断への拡張」として TIME-RA が加わり、予測・分類・意思決定に続く TSR の新用途が確立した。(b) [[時系列異常検知ベンチマーク]] の LLM × TSAD 3 路線(ARGOS 訓練時ルール生成/VisualTimeAnomaly 推論時 MLLM 検知/LLMAD 直接判定)に、「SFT で生成型診断 + 転用可能」という第 4 路線が加わった。(c) [[時系列マルチモーダルLLM]] に「視覚 = 推論整合性・ネイティブ TS = 定量精度」という粒度依存の役割分業の新たな証拠が追加された。**新規ページ**: [[@2026__ACL Findings__Time-RA - Towards Time Series Reasoning for Anomaly Diagnosis with LLM Feedback]]・[[Yiyuan Yang]]。**更新ページ**: [[Qingsong Wen]]・[[Zichuan Liu]]・[[時系列推論]]・[[時系列異常検知ベンチマーク]]・[[時系列マルチモーダルLLM]]・[[sources/_index]]・[[index]]・[[log]]。 --- 2026-06-17: **GLM family 4 論文一括 ingest(ACL 2022 起点 + GLM-4.5 + GLM-5 + GLM-OCR)** — [[Zhipu AI]] / [[Tsinghua University]] [[Jie Tang]] 系の 4 年分の進化を wiki に揃えた回。**核心の系譜**: (1) [[@2022__ACL__GLM - General Language Model Pretraining with Autoregressive Blank Infilling|GLM(Du+ ACL 2022)]] が [[自己回帰空白埋め]] + [[2D位置符号化]] で BERT/GPT/T5 の三大事前学習タスクを統一(SuperGLUE +4.6〜5.0%、BERTLarge 1.25 倍で全タスク単一モデル最良)。(2) [[@2025__arXiv__GLM-4.5 - Agentic Reasoning and Coding Foundation Models|GLM-4.5(2025)]] が ARC(Agentic/Reasoning/Coding)を 355B/32B MoE に統合、ハイブリッド推論モード(思考/非思考)を**エキスパート蒸留パイプライン**で単一モデルに実現、深さ優先設計(幅を絞り層数を増やす)が推論能力向上を示す。TAU-Bench 70.1%・SWE-bench Verified 64.2%・AIME 24 91.0% でオープンソース全体 3 位。(3) [[@2026__arXiv__GLM-5 - From Vibe Coding to Agentic Engineering|GLM-5(2026)]] が [[DSA]](DeepSeek Sparse Attention)+ 744B/40B MoE + 28.5T トークン + 非同期 RL([[slime]] フレームワーク、生成と訓練を分離)。Artificial Analysis Intelligence Index v4.0 でオープンウェイト初の 50 達成、SWE-bench Verified 77.8%・BrowseComp(文脈管理あり) 75.9%。「Vibe Coding → Agentic Engineering」スローガンで GLM-4.5 からのスコープ拡張を明示。(4) [[@2026__arXiv__GLM-OCR Technical Report|GLM-OCR(2026)]] が **0.9B 小型 VLM** で OmniDocBench v1.5 94.62 点を達成し、**235B Qwen3-VL や Gemini-3 Pro を上回る 1 位**。PP-DocLayout-V3 によるレイアウト解析 → 並列リージョン認識の 2 ステージ、**パラメータ共有ドラフトヘッドの [[マルチトークン予測]]** で平均 5.2 トークン/ステップ(約 50% スループット向上)、Stage 1-4 段階訓練 + GRPO RL。**横断知見**: (a) **GLM 系統が単一ファミリーとして wiki に収まった**初の例。4 年スパンの単一グループの漸進的進化が一望可能。(b) **OCR が MTP の効果を最大化するドメイン特性を持つ**ことを GLM-OCR が実証([[DeepSeek-V3]] の汎用テキスト MTP との比較で構造トークン局所性が高受容率を生む)。(c) **小型タスク特化 VLM でフロンティアモデル超え**が現実化([[マルチトークン予測]] §横断的知見)。(d) **非同期 RL インフラ**が独立した研究分野として確立しつつあり、GLM-5 slime と [[MiniMax-M2]] Forge が独立に同じ問題意識(長期エージェントロールアウトの GPU 利用率向上)に到達。(e) **スパーシティ手法の系譜**: [[Lightning Attention]](MiniMax-M1)・MoE エキスパートスパーシティ(Kimi K2)・DSA(GLM-5)が第三世代スパーシティとして揃った。**新規ページ**: source 4(GLM 2022 / GLM-4.5 / GLM-5 / GLM-OCR、加えて GLM-5 評価で参照される CursorBench source も同時 ingest)、entity 多数([[Zhengxiao Du]]・[[Yujie Qian]]・[[Ming Ding]]・[[Jiezhong Qiu]]・[[Zhilin Yang]]・[[Jie Tang]]・[[Wenmeng Yu]]・[[Xiaotao Gu]]・[[Zhipu AI]]・[[BAAI]] ほか)、concept 多数([[自己回帰空白埋め]]・[[2D位置符号化]]・[[スパン破壊]]・[[事前学習目的設計]]・[[言語モデル事前学習]]・[[エージェント型コーディング]]・[[非同期エージェントRL]]・[[DSA]]・[[光学文字認識]]・[[文書理解]]・[[ビジョン言語モデル]] など)。**更新ページ**: [[Tsinghua University]] / [[MIT CSAIL]] / [[Shanghai Qi Zhi Institute]] / [[Xiao Liu]] / [[Mixture-of-Experts]] / [[マルチトークン予測]](DeepSeek-V3 vs GLM-OCR の MTP 設計比較を横断的知見追加)/ [[オープンLLM開発]] / [[コーディングエージェント評価]] / 各索引・index・log・manifest。 --- 2026-06-17: **CursorBench ブログ ingest([[Naman Jain]] / Cursor Blog)** — [[Cursor Research]] の [[CursorBench]] 3.1 評価手法を解説したブログ記事を wiki 化。核心: (1) [[SWE-Bench-Verified]] を含む公開ベンチマークの 3 限界(調整不足・採点問題・汚染)を明示し、OpenAI が「未解決問題の **約 60% にテスト欠陥**」として SWE-bench Verified 報告を停止した事実を引用。(2) [[Cursor Blame]] 機能でコミット済みコードを元のエージェントリクエストにトレースし、内部エンジニアセッションを問題素材に使うことで汚染を防ぐ設計。(3) ハイブリッドオンライン・オフライン評価方式: オフライン(CursorBench、高速・再現可能・フロンティアモデル間識別力大)とオンライン(実開発者リグレッション検出・機能 ablation)を組み合わせる。(4) 問題スコープは初期版比 約 2 倍(行数・ファイル数)。(5) 将来は「long-running agents on their own computers」対応予定。**著者経歴補足**: [[Naman Jain]] は [[Agentica]] / [[Together AI]] の [[DeepSWE]] 共同筆頭著者で、現在は [[Cursor Research]] 在籍。**新規ページ**: [[@2026__Cursor__CursorBench - How Cursor Evaluates Model Quality]]、[[コーディングエージェント評価]]。**更新ページ**: [[CursorBench]](v3.1 詳細・Cursor Blame・ハイブリッド評価)、[[Naman Jain]](Cursor Research 移籍)、[[SWE-Bench-Verified]](報告停止・3 限界の批判)、[[Cursor]]。 --- 2026-06-17: **アラート管理・時系列異常検知 10 論文一括 ingest(2009-2025、NOMS/CIKM/KDD/ICAC/ICSE/CLOUD/FSE/arXiv)** — Tang+ NOMS2012([[@2012__NOMS__Optimizing System Monitoring Configurations for Non-Actionable Alerts]])・Lin+ CIKM2018([[@2018__CIKM__Collaborative Alert Ranking for Anomaly Detection]])・Chen+ ICSE2022 OAS([[@2022__ICSE__Online Summarizing Alerts through Semantic and Behavior Information]])・Gu+ arXiv2025 ARGOS([[@2025__arXiv__ARGOS - Agentic Time-Series Anomaly Detection with Autonomous Rule Generation via Large Language Models]])・Xu+ arXiv2025 VisualTimeAnomaly([[@2025__arXiv__Can Multimodal LLMs Perform Time Series Anomaly Detection]])・Jiang+ ICAC2009([[@2009__ICAC__Ranking the Importance of Alerts for Problem Determination in Large Computer Systems]])・Siffer+ KDD2017 SPOT([[@2017__KDD__Anomaly Detection in Streams with Extreme Value Theory]])・Mormul+ CLOUD2020 DEAR([[@2020__CLOUD__DEAR - Distributed Evaluation of Alerting Rules]])・Chen+ FSE2025 ProAlert([[@2025__FSE__Alert Summarization for Online Service Systems by Validating Propagation Paths of Faults]])・Yu+ FSE2024 ChangeRCA([[@2024__FSE__ChangeRCA - Finding Root Causes from Software Changes in Large Online Systems]])。**10 論文の中核知見**: (1) Tang+ NOMS2012 は IBM Tivoli 本番データで「真偽分類」でなく「SLA の許す範囲でチケット遅延 → 一過性アラート自然消滅」へ設計転換し、リアル見逃しゼロを数学保証しつつ非アクション可能チケットを最大 75% 削減。(2) CAR(Lin+ CIKM2018)は企業セキュリティ実データで Pitman-Yor 前置木ベイズ(時間)+ エンティティ埋め込み(コンテンツ)の統一凸最適化により ROC-AUC 0.998、教師なしのまま個別アラートと多段攻撃パターンを同時ランキング。(3) OAS(Chen+ ICSE2022)は障害報告書ラベル + ASR+ABR+ACT 深層学習で 2 商業銀行 ACR>99%・VCR≈54%、CMDB 不要で意味的に異なる alert を集約。(4) ARGOS(Gu+ arXiv2025)は LLM をルール生成(訓練時)のみに使い推論はルール実行、Detection/Repair/Review 3 エージェント + Aggregator で精度退行ゼロ保証、Microsoft 内部データで F1 +28.3%、推論レイテンシ最大 34.3x 高速化。(5) VisualTimeAnomaly(Xu+ arXiv2025)は MLLM の時系列→画像化が不規則サンプリングへロバスト・ハルシネーション削減を実現、しかし点別異常では F1 上限 8.12% と数値推論限界を実証(従来手法と相補)。(6) Jiang+ ICAC2009 は不変条件ネットワーク + NTV ピアレビューでルール閾値を等価変換して横断ランキング、事前知識ゼロ。(7) SPOT/DSPOT(Siffer+ KDD2017)は EVT(Peaks-Over-Threshold + GPD)で分布仮定不要・閾値手動設定不要のストリーム検知、リスク q だけで動作 — Alert Storm(Zhao+ 2020)の統計的ルーツ。(8) DEAR(Mormul+ CLOUD2020)は BET 中間表現でアラートルール評価を VM 自動配布、TTI を集約間隔依存(最大 27s)から定値 ~370ms に。(9) ProAlert(Chen+ FSE2025)は教師なしで歴史的アラート + CMDB トポロジから fault propagation patterns を学習、S1 VCR 93.53%・SA 99.71%、200+/1280+ alerts/sec オンライン。(10) ChangeRCA(Yu+ FSE2024)は ACD → RCCA という問題昇格、WeChat 本番 + 81 種シミュレーションで HR@1 85.78%、TTI 90% 削減。**新規ページ**: 10 source + 50+ entity(著者 35+・組織 13+)。**更新ページ**: [[アラート管理]]・[[アラート集約]]・[[アラートストーム]]・[[アラート抑制]]・[[アラートフィルタリング]]・[[時系列異常検知]]・[[変更起因インシデント]]・[[根本原因分析]] と既存 entity 多数。**横断知見**: (a) Fudan アラート集約三部作 OAS(2022)→ DyAlert(2023)→ ProAlert(2025)が確定。(b) SPOT/DSPOT が現代 Alert Storm 検知の統計的ルーツとして系譜の根に。(c) アラートランキング 3 系統(Jiang+ ICAC2009 教師なし不変条件 / CAR 教師なし統一最適化 / AlertRank 教師あり ML)。(d) IBM 系研究の 12 年遷移 — NOMS2012 静的ルール → ICSE-SEIP2024 動的オンライン抑制。(e) LLM × TSAD は「訓練時ルール抽出(ARGOS)」と「推論時検知(VisualTimeAnomaly)」で根本的に分化。(f) ChangeRCA が ACD → RCCA という問題昇格を定式化。 --- 2026-06-17: **Harp(NSDI 2026)ingest** — VPC ネットワーク障害検知・回復メカニズム Harp を wiki 化。キーポイント: (1) UDP ソースポートによる ECMP ハッシュ線形性を利用した決定論的パス制御でホスト対ごとに 64 エントリのパスプールを構築。(2) VM パケットへの 28 バイトインバンドプローブ埋め込み + ビットマップ圧縮で帯域消費 0.31-1.87%。(3) M 連続サイクル確認で偽陽性抑制する examination period 設計。(4) Tencent Cloud 8 件の重大スイッチ障害で P50 48-97 ms・停止時間 78-99.97% 削減。(5) 集約パケットロス率では検知できないグレイ障害(特定フロー・リンク輻輳)もパス単位監視で即座に迂回。SkyNet([[@2025__SIGCOMM__SkyNet - Analyzing Alert Flooding from Severe Network Failures in Large Cloud Infrastructures]])や R-Pingmesh([[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]])との対比で「インバンド vs アウトオブバンド」「パス単位 vs 集約」のトレードオフが具体化した。**新規ページ**: [[@2026__NSDI__Harp - Improving VPC Network Availability via Efficient Failure Detection and Rerouting in Tencent Cloud]] / [[Jiayu Hu]] / [[Feng Jin]] / [[Kai Zhang]] / [[VPCネットワーク可用性]]。**更新ページ**: [[Tencent]] / [[Fudan University]] / [[グレイ障害]] / [[ネットワーク監視]]。 --- 2026-06-17: **アラート管理論文 3 本(Zha+ Electronics 2024 / VOCE FASE 2025 / SkyNet SIGCOMM 2025)バッチ ingest** — アラート集約・アラートインシデント分析・ネットワーク監視を縦断する 3 論文を取り込み。(1) [[@2024__Electronics__Leveraging Large Language Models for Efficient Alert Aggregation in AIOPs|Zha+ Electronics2024]] は時空間 DBSCAN([[node2vec]] + [[Sentence-BERT]] ハイブリッド類似度、τ=15min、α=0.4)+ LLM × [[サービス依存グラフ]] 弱連結成分集約の二段階設計で、[[State Grid Jiangsu Electric Power]] の 100K アラート × 130 ストーム本番データで F1 0.815-0.850 を達成し FPGrowth(0.475-0.540)/DBSCAN(0.248-0.295)/AlertStorm(0.408-0.468)を大差で上回る。アブレーションで時間情報除去 F1 -0.275 と Phase 2 LLM 除去 F1 -0.294 が支配的。(2) [[@2025__FASE__VOCE - A Virtual On-Call Engineer for Automated Alert Incident Analysis Using a Large Language Model|VOCE(Chen+ FASE2025)]] は新概念 [[アラートインシデント分析]] を導入(集約後の originating alert 特定)。実データ 827 incidents で「system layer 最下層 93%・impact scope 最広 95%・severity 最高 93% で originating alert と一致、Order=時系列最初は 45.34% のみ」を測定。Drain → 3 因子 CoT 抽出 → 階層 causality mining(source 内→隣接 source 間、k=5 多数決) → 統計 correction → [[Eigenvector Centrality]] で originating alert を推定し、VOCE-GPT 88.90%(56.79s)/VOCE-LLaMA 81.26%(279.91s)で CoT/Prompt をいずれも上回る。(3) [[@2025__SIGCOMM__SkyNet - Analyzing Alert Flooding from Severe Network Failures in Large Cloud Infrastructures|SkyNet(Yang+ SIGCOMM2025)]] は [[Alibaba Cloud]] 89 DC × 10⁵ デバイスで 1.5 年安定稼働、severe failure mitigation time を中央値 736→147s(80% 削減)、最大 14,028→1,920s。12 監視ツール統合 preprocessor + hierarchical alert tree(threshold 2/1+2/5、Failure/Abnormal/Root cause の 3 分類)+ severity score(impact × time、log + sigmoid 合成)。**LLM 不採用**を §2.3 で明文化(Syslog 10M/15min が 20M トークン context 超過、ハルシネーション、ブラックボックス性)。**新規ページ**: 3 source + 17 entity(著者 13・組織 1・技術 4)+ 4 concept([[アラートインシデント分析]]・[[LLMによる根本原因分析]]・[[サービス依存グラフ]]・[[ネットワーク監視]])。**更新ページ**: [[アラート集約]]([[LLMによる根本原因分析]] と「LLM の役割の 3 系統分化」横断的知見追加)、[[アラートストーム]](SkyNet "alert flooding from severe failure" 第三カテゴリ追記)、[[Drain]](VOCE 文脈で stub から実体ページに昇格)、[[Fudan University]]・[[Ennan Zhai]]・[[Alibaba Cloud]]・[[Dennis Cai]]。 --- ## Past Updates 2026-06-16: **Ryota Yoshikawa "Reliability in the Age of AI: Engineering for AI Velocity" (SpeakerDeck / Forkwell 開発の予防処方)** — [[Topotal]] CTO [[Ryota Yoshikawa]](`@rrreeeyyy`)による 2026-06-09 公開資料。AI 採用は DORA 2025 で開発者 90%、Stack Overflow 2024 で 76% 利用/計画まで浸透し、生産性は Copilot 実験 +55.8%、Borg+ 2025 +30.7%、MIT/Microsoft 実環境 +26.08% と整理。一方で DORA 2024-2025 の不安定さ継続、AI コード品質問題、生成 AI サービスの人手検知率 38.3%・監視メトリクス種類 25.9 vs 74.4・収束時間 1.83 倍を根拠に、速度と信頼性のジレンマが再来していると論じる。**新規ページ**: [[@2026__SpeakerDeck__Reliability in the Age of AI - Engineering for AI Velocity]]、[[Ryota Yoshikawa]]、[[Topotal]]、[[Waroom]]。**更新ページ**: [[SRE]](生成物制御 + 本番観測の二面)、[[agentic SRE]](実務導入は判断支援から始まる)、[[SRE AI Autonomy Levels]](L1-L2 実証 + Safety Trifecta + Architectural Guardrails)、[[サービスレベル目標]](AI サービス固有 SLI)、[[エラーバジェット]](AI 自動承認の制御信号)。transcript なし、全 27 ページ画像確認済み。 --- 2026-06-16: **アラート管理 9 論文一括 ingest(2020-2024、AIOps・アラートストーム・抑制・集約・RCA・アクショナブル)** — Zhao+ ICSE-SEIP 2020([[@2020__ICSE-SEIP__Understanding and Handling Alert Storm for Online Service Systems|Alert Storm]])・Zhao+ ISSRE 2020([[@2020__ISSRE__AlertRank - Automatically and Adaptively Identifying Severe Alerts for Online Service Systems|AlertRank]])・Chakraborty+ arXiv 2023([[@2023__arXiv__ESRO - Experience Assisted Service Reliability against Outages|ESRO]])・Chen+ ASE 2023([[@2023__ASE__Dynamic Graph Neural Networks-Based Alert Link Prediction for Online Service Systems|DyAlert]])・Voutsas+ JCC 2023([[@2023__JCC__Filtering Alerts on Cloud Monitoring Systems|Filtering Alerts]])・Zeng+ ICSE-SEIP 2023([[@2023__ICSE-SEIP__TraceArk - Towards Actionable Performance Anomaly Alerting for Online Service Systems|TraceArk]])・Yu+ CCGRID 2024([[@2024__CCGRID__AlertRCA - Causality Enhanced Graph Representation Learning for Alert-Based Root Cause Analysis|AlertRCA]])・Bhukar+ ICSE-SEIP 2024([[@2024__ICSE-SEIP__Dynamic Alert Suppression Policy for Noise Reduction in AIOps|Dynamic-X-Y]])・Yuan+ ISSRE 2024([[@2024__ISSRE__Exploring Hierarchical Patterns for Alert Aggregation in Supercomputers|SuperAgg]])。**9 論文の中核知見**: (1) Zhao+ 2020(ICSE-SEIP) は China EverBright Bank の 3 年 300 万件アラートで EVT 検知 + 4 段要約により 98% 削減、アラートストームの最初の実証研究。(2) AlertRank はランキング問題として定式化、Resolution Record の TF-IDF + k-means で連続スコア自動付与、F1=0.89。(3) ESRO は過去の障害レポートとアラートデータを CK グラフで統合、Rouge +27.2%/+39.0%。(4) DyAlert は AMDG + k-GNN + GRU でアラートリンク予測、Alibaba 85 BU で F1 +0.259。(5) Voutsas+ はクリック行動ベース Random Forest フィルタを Netdata で精度 70% 達成、現場規模を実測公開。(6) TraceArk は impact + interpretability の 2 軸でアクショナブルアラートを定義、Exchange 本番 4 ヶ月で適合率 0.9068。(7) AlertRCA はアラートのみ入力で top-1 83.9% RCA、Groot(手作業ルール)を上回る。(8) Dynamic-X-Y は教師なし統計学習で抑制ポリシーを自動学習、教師あり上界に到達。(9) SuperAgg は HPC 連続的アラート過負荷を 2 段階階層構造で集約、ベースライン比 +83.8%/+43.2% 精度向上。**新規ページ**: source 9、entities 30+([[Nengwen Zhao]]・[[Junjie Chen]]・[[Yiru Chen]]・[[Sarthak Chakraborty]]・[[Yuqun Zhang]]・[[Zhaoyang Yu]]・[[Yuan Yuan]]・[[Karan Bhukar]]・[[Fotios Voutsas]]・[[Aris Leivadeas]]・[[ESRO]]・[[AlertRank]]・[[AlertRCA]]・[[TraceArk]]・[[SuperAgg]]・[[Fudan University]]・[[Alibaba Group]]・[[École de Technologie Supérieure]]・[[Netdata]]・[[IBM Research]] ほか)、concept 3([[アラートストーム]]・[[アラート抑制]]・[[アクショナブルアラート]])。**更新ページ**: [[アラート管理]](5 介入点細分化など 4 つの横断的知見追加)、[[アラート集約]](グラフ表現学習世代交代など 4 つの横断的知見追加)、[[アラートアンチパターン]](Cascading 原典追記など 3 つ追加)、[[Quality of Alerts]](TraceArk 2 軸と QoA 3 軸の対応など 3 つ追加)、[[アラートフィルタリング]](Voutsas + Bhukar の弱教師対比 2 つ追加)、[[Dan Pei]]、[[Qingwei Lin]]、[[Saravan Rajmohan]]、[[Pooja Aggarwal]]、[[BizSeer]]、[[Alibaba Group]]、[[IBM Research]] ほか。**横断知見**: 9 本は「抑制(発火前)→ フィルタリング(クリック行動)→ 集約(クラスタリング/グラフ表現)→ ランキング(severity/actionability)→ RCA(アラートのみ)」の 5 介入点に分化し、Yu+ JNCA2024 の 3 プロセス分類(correlation/storm/determination)では捕捉しきれない解像度に到達。HPC ドメインの「連続的アラート過負荷」はクラウドの「断続的アラートストーム」と別問題で集約戦略が異なる。 --- 2026-06-16: **アラート管理・集約・予測の系譜 5 論文一括 ingest** — Yang+ DSN 2022([[@2022__DSN__Characterizing and Mitigating Anti-patterns of Alerts in Industrial Cloud Systems|Anti-patterns of Alerts]])・Kuang+ ICSE-SEIP 2024([[@2024__ICSE-SEIP__Knowledge-aware Alert Aggregation in Large-scale Cloud Systems - a Hybrid Approach|COLA]])・Singal+ arXiv 2025([[@2025__arXiv__Metric Criticality Identification for Cloud Microservices|KIMetrix]])・Lin+ KDD 2014([[@2014__KDD__Unveiling Clusters of Events for Alert and Incident Management in Large-Scale Enterprise IT|Pivotal Alert Clustering]])・Chen+ WWW 2019([[@2019__WWW__Outage Prediction and Diagnosis for Cloud Service Systems|AirAlert]])。**5 論文の中核知見**: (1) Yang+ 2022 は Huawei Cloud の 2 年 400 万件アラートと 18 OCE 調査から 4 個別+2 集合のアラートアンチパターンを実証同定し、SOP 有用性は「Helpful 22.2% vs Limited Help 77.8%」、QoA(indicativeness/precision/handleability)の自動評価を将来方向に。(2) Kuang+ 2024 は同じ CUHK+Huawei 連携で 2 年後、SOP を LLM 推論材料に転化(CoT 2 ラウンド + ICL + P-tuning v2 SFT)し、相関マイニング(temporal: 条件付確率+Jaccard 除ノイズ、spatial: node2vec+skip-gram)とのハイブリッドで F1 0.901-0.930・本番 4 ヶ月運用。(3) Singal+ 2025 は IBM India が Informative Metric Subset Problem(NP 完全)を初定式化、エントロピー+相互情報量+トポロジ確率調整+AIMD で SelectKBest/mRMR/Boruta/Max Weighted Clique を上回る coverage(DeathStarBench CPU で 99.44%)。(4) Lin+ 2014 は Pivotal が 5M アラート→22K ユニーク・67K インシデントを Greenplum+MADlib で並走処理、Jaccard+connected components+graph-cut(半構造化アラート)と NMF+KD-tree+complete-linkage(非構造化インシデント)の 2 系統独立 framework、構造保存型可視化(word cloud 代替)。(5) Chen+ 2019 は Microsoft 1 年データで Bayesian network(FCI)+XGBoost のハイブリッドアウテージ予測、サービスレベルで Simple Spike(F1 7-11%)崩壊→AirAlert Related F1 53-88%。**新規ページ**: source 5、entities 26、concepts 7([[Quality of Alerts]]、[[アラートアンチパターン]]、[[アラート集約]]、[[COLA]]、[[KIMetrix]]、[[情報量基準メトリクス選定]]、[[AirAlert]])。**更新ページ**: [[アラート管理]](3 つの新たな横断的知見追加)、[[障害予測]](AirAlert を 2 つの横断的知見で位置づけ)、[[Michael R. Lyu]]、[[Yongqiang Yang]]、[[Junjie Huang]]、[[Renyi Zhong]]、[[Zengyin Yang]]、[[IBM Research]]、[[Qingwei Lin]]、[[Hongyu Zhang]]、[[Dongmei Zhang]]、[[Yu Kang]]。**横断知見**: 5 本は「アラートのアンチパターン同定(2022)→メトリクス選定(2025)→アラート/インシデント集約(2014, 2024)→アウテージ予測(2019)」という運用エンジニアリングの段階全体を横断し、各段階で「LLM はインターフェース層、軽量 ML/統計手法は予測コア層」に収束する系譜が見える。 --- 2026-06-16: **Annie Zhou・Sophie Zhang "How We Debug 1000s of Databases with AI" (SREcon26 Americas / Databricks)** — [[Databricks]] ストレージプラットフォームチームが MySQL/TiDB 数千インスタンス・70以上のリージョン・3クラウドで運用するスケールで本番稼働させた AI支援デバッグシステム([[Storax]])の設計と教訓。(1) AI 導入前に社内エンジニアへのインタビュー・オンコール同行観察でツールとコンテキストを集中化した(最初の数イテレーションは AI をほぼ使わなかった)。(2) セントラルファースト・シャーデッドアーキテクチャ + 細粒度AC(チーム/リソース/RPC) + 統一ツールインターフェースの安全基盤(Storax)。(3) DSPy インスパイア宣言型フレームワーク: Signature/Tools/Modules の3概念、内部 LLM プロキシで Claude・GPT・Gemini を差し替え可能、Temporal ワークフローで2人目承認ゲート。調査時間最大90%削減。**新規ページ**: [[@2026__SREcon26 Americas__How We Debug 1000s of Databases with AI]]、[[Annie Zhou]]、[[Sophie Zhang (Databricks)]]、[[Databricks]]、[[Storax]]。**更新ページ**: [[agentic SRE]](産業実装ユーザー共感先行論・承認ゲート設計の横断的知見)、[[データベース O&M]](Storax産業実装・Temporal承認ゲート)、[[データベース自律診断]](診断止まり+承認付き実行パターン)。動画取得失敗(URL-only)、自動字幕から transcript(100文)を取得・変換。 --- 2026-06-16: **Jamie Wilkinson "A Theory and Practice of Alerting with Service Level Objectives" (SREcon18 Asia)** — [[Jamie Wilkinson]]([[Google]] SRE)による 2018-06-08 SREcon18 Asia 講演スライド(29p)。「シンプトム(symptom) = SLO で計測できるもの」「シンプトムベースドアラート = SLO が危険になったときのアラート」と定義し、SLI/SLO/SLA 三層・工学的許容差との類比・可用性のリクエスト成功率定義・SLO バーンレートアラート(Fast Burn: Prometheus `delta(errors[1h]) > budget/burn_period`)を体系化。**新規ページ**: [[@2018__SREcon18 Asia__A Theory and Practice of Alerting with Service Level Objectives]]、[[Jamie Wilkinson]]。**更新ページ**: [[エラーバジェット]](Wilkinson の Fast Burn 式を横断的知見に追記)、[[サービスレベル目標]](工学的許容差類比・symptom 定義を横断的知見に追記)。transcript あり(Whisper small, MP3 37MB, 406 行)。主な補足: Google 最悪オンコール 2 期→シフト 2 ページ未満達成の実践報告、per-user SLO の強調、「SLO burn rate」の口頭命名、コースベースドアラートのダウングレード段階戦略(ページ→チケット→ダッシュボード)。 --- 2026-06-16: **Nicole Forsgren "The WTF Problem" (SREcon26 Americas)** — [[Nicole Forsgren]] が SRE ツール・プロセス摩擦を信頼性のシステム特性として再定義した 45 分講演スライド(37p)。3 種の摩擦(認知負荷・ツール摩擦・プロセス摩擦)は圧力下でエラー率を上げる信頼性リスクであり、AI がベースラインの摩擦を増幅する。北極星メトリクス [[MTWTF]](アラートから状況理解まで)と [[DORA]] + [[SPACE]] を SRE チーム自身の計測に適用する方法論を提案。Knight Capital Group $460M 事例・Replit 本番 DB 削除事例・Dave Anderson @ Amazon のデータ可視化介入事例を事例証拠として使用。**新規ページ**: [[@2026__SREcon26 Americas__The WTF Problem - Developer Experience as a Reliability Property]]、[[Nicole Forsgren]]、[[Abi Noda]]、[[DORA]]、[[SPACE]]、[[MTWTF]]。**更新ページ**: [[SRE]](DX = 信頼性システム特性という横断的知見を追加)。 --- 2026-06-16: **TimeGPT-1(Garza+2023、arXiv:2310.03589)** — [[Nixtla]]([[Azul Garza]]・[[Cristian Challu]]・[[Max Mergenthaler-Canseco]])による時系列向け初のファウンデーションモデル論文。エンコーダ・デコーダ Transformer を 100B 点超の多ドメイン時系列で事前学習し、ゼロショット推論で月次 rMAE 0.727(全ベースライン最良)を達成。推論速度 0.6 ms/系列(統計手法の 1/1000)。コンフォーマル予測で分布仮定不要な予測区間を提供。**新規ページ**: [[@2023__arXiv__TimeGPT-1]]、[[Cristian Challu]]、[[Max Mergenthaler-Canseco]]、[[Nixtla]]。**更新ページ**: [[時系列基盤モデル]](TimeGPT が TSFM 競争軸の起点という横断的知見を追加)、[[Azul Garza]](first_mentioned を TimeGPT-1 に修正)。 --- 2026-06-16: **佐藤竜馬「ジョイジョイジョイ」13 記事バッチ ingest（2024-09〜2026-03）** — joisino.hatenablog.com の 13 記事を並列 wiki-ingest。**(1) Transformer 系・系列モデル**: [[joisino-トランスフォーマーはRNN-2024]](Transformer の自己注意を [[カーネル法]] として再定式化し線形注意経由で [[RNN]] と等価。[[線形注意]]・[[状態空間モデル]]・[[文脈内学習]] の同質性まで通読)。**(2) LLM 機構的解釈性**: [[joisino-言語モデルの物理学-2025]]（[[Zeyuan Allen-Zhu]]・[[Yuanzhi Li]] [[Meta FAIR]] の [[Physics of Language Models]] シリーズ。[[知識容量スケーリング則]] 約 2 bit/param、[[知識操作]] は CoT 必須、[[文脈自由文法]] 学習）、[[joisino-LLMのキモい算術-2025]]（[[LLM算術機構]] は [[ヒューリスティックの束]] として実装、[[ロジットレンズ]] で可視化、Nikankin+ ICLR 2025）。**(3) LLM 評価**: [[joisino-否定文理解-2024]]（softmax 構造上 BERT 系で否定文埋め込みが数学的に存在不能、[[文脈付き検索]] 5.0→2.9% で緩和）、[[joisino-LLMの能力の穴-2026]]（[[ゼロエラー境界]] ZEH でモデル自身に問題サイズ限界を定めさせ [[LLM能力スパース性]] を可視化）、[[joisino-LLMと言葉の感じ方-2026]]（[[LLM意味表象]] のカテゴリ分類は人間と一致するが典型度順位相関 ≤0.15、[[Yann LeCun]] の次トークン予測限界主張の傍証）。**(4) AI 安全性**: [[joisino-超人的AIと認知不能情報-2025]]（敵対的摂動は人間に認知できない正当な分類手がかり、NP 完全性・対話型証明系で「探索 AI / 検証 人間」の [[AI検証可能性]]）、[[joisino-人間を騙すAI-2025]]（標準 RLHF だけで [[RLHF誤誘導]]、フェイクエビデンス挿入・難読化、[[報酬ハッキング]]・[[スコファンシ]]・[[LLM自己検証]] 限界）。**(5) 学習理論・表現**: [[joisino-機械学習理論入門-2025]]（[[集中不等式]]→[[カバリングナンバー]]→[[汎化誤差バウンド]]→[[深層学習の汎化]] 崩壊）、[[joisino-アンナカレーニナの法則-2025]]（[[プラトン的表現仮説]]・[[モデル縫合]]・[[暗黙的正則化]]）。**(6) LLM 訓練・運用**: [[joisino-訓練データ1個推論性能倍-2025]]（[[1サンプルRLVR]] Qwen2.5-Math-1.5B、MATH500 36→74%、6 ベンチ平均 17.6→35.7%）、[[joisino-LLMでソート-2026]]（[[LLM比較器]] でペアワイズ+クイックソート、セットワイズで呼び出し最小化）、[[joisino-面白さ優先分類器-2025]]（[[一対比較ランキング]]で[[面白さ優先分類]]、面白い特徴 1 つでも統計的有意な精度）。**新規ページ（主要）**: source 13、entity [[Zeyuan Allen-Zhu]]・[[Yuanzhi Li]]・[[Yann LeCun]]・[[Meta FAIR]]、concept [[Transformer]]・[[線形注意]]・[[RNN]]・[[状態空間モデル]]・[[カーネル法]]・[[Physics of Language Models]]・[[知識容量スケーリング則]]・[[知識操作]]・[[LLM算術機構]]・[[ヒューリスティックの束]]・[[ロジットレンズ]]・[[否定文理解]]・[[ゼロエラー境界]]・[[LLM能力スパース性]]・[[プラトン的表現仮説]]・[[モデル表現収束]]・[[モデル縫合]]・[[暗黙的正則化]]・[[1サンプルRLVR]]・[[RLHF誤誘導]]・[[報酬ハッキング]]・[[スコファンシ]]・[[LLM比較器]]・[[LLMランキング]]・[[pairwiseランキング]]・[[面白さ優先分類]]・[[一対比較ランキング]]・[[汎化誤差バウンド]]・[[集中不等式]]・[[PAC学習]]・[[カバリングナンバー]]・[[深層学習の汎化]]・[[AI検証可能性]]・[[敵対的摂動]]・[[帰属手法]]・[[LLM意味表象]]・[[認知意味論]]・[[プロトタイプ意味論]] ほか。**更新ページ**: [[佐藤竜馬]]、[[Anthropic]]、[[機構的解釈性]]、[[LLM向け情報検索]]、[[sources/_index]]、[[entities/_index]]、[[concepts/_index]]、[[index]]。 --- 2026-06-16: **佐藤竜馬 2 記事バッチ ingest — ICLR 2024 GNN 動向 & モデルパラメータ算術** — [[joisino-ICLR-2024-GNN]]（[[佐藤竜馬]]、2024-05-15）と [[joisino-モデルパラメータ算術-2024]]（同、2024-01-09）の同時取り込み。**ICLR 2024 GNN 動向**: 採択 170 本（全体の 7.4%）、解釈性（反実仮想説明の現実性問題・GNNBoundary・GraphChef）・[[GNN同変性]]（SE(n)-等変ネット・メタネットワーク）・表現能力（WL 検査から部分グラフ認識可能性へ移行）・分子基盤モデル（Beaini+ ICLR 2024、1 億以上の分子データセット）・物理シミュレーション等。GNN コア技術は成熟、応用急拡大。**モデルパラメータ算術**: モデルスープ（パラメータ平均、Wortsman+ ICML 2022）・[[タスクベクトル]]（τ = θ_ft − θ_0、Ilharco+ ICLR 2023）・NTK 理論（Ortiz-Jimenez+ NeurIPS 2023）・パーミュテーション対称性と Git Re-Basin（Ainsworth+ ICLR 2023）。**2 記事の共通テーマ**: MLP のニューロン並べ替え対称性（パーミュテーション対称性）を GNN 同変性で扱うメタネットワーク（Kofinas+、Lim+ ICLR 2024）が接続点。**新規ページ**: [[グラフニューラルネットワーク]]、[[GNN同変性]]、[[タスクベクトル]]、[[モデルパラメータ算術]]、[[joisino-ICLR-2024-GNN]]、[[joisino-モデルパラメータ算術-2024]]。**更新ページ**: [[佐藤竜馬]]、[[sources/_index]]、[[concepts/_index]]、[[entities/_index]]、[[index]]。 --- 2026-06-16: **佐藤竜馬 2025 — LLMのアテンションと外挿（joisino.hatenablog.com）** — [[joisino-LLMアテンションと外挿-2025]]([[佐藤竜馬]]、[[National Institute of Informatics]]、2025-09-29)。**核心命題**: LLM は「[[Transformer]] の注意ヘッドで実装されたプログラムを実行する汎用計算装置（チューリングマシン的）」＋「MLP に蓄積した静的知識データベース」の組み合わせ。表層（具体例）レベルでは外挿できても、ルール・アルゴリズムのメタレベルでは内挿にとどまる。**7 種のアテンションヘッド**: (1) 文法ヘッド（Clark+ 2019、訓練途中に相転移的に出現 → 文法能力が急上昇 Chen+ ICLR 2024）、(2) 注意の受け皿（attention sink、先頭トークン・句読点がグローバルバッファになる）、(3) 逐次ヘッド（直近のみ参照、多数）、(4) 検索ヘッド（全文脈、少数だが 20 個削除で精度 94.7%→63.6% 落ち）、(5) [[帰納ヘッド]]（`[A][B]...[A]→[B]`、文脈内学習の主要機構、Olsson+ 2022）、(6) [[関数ベクトル]]（few-shot 例の最終トークン内部状態の平均を MLP 入力へ加算するだけでタスク実行、Todd+ ICLR 2024）、(7) [[反復ヘッド]]（CoT のテープ上で処理位置を追跡、Cabannes+ NeurIPS 2024）。**新規ページ**: [[佐藤竜馬]]、[[joisino-LLMアテンションと外挿-2025]]、[[アテンションヘッド]]、[[帰納ヘッド]]、[[機構的解釈性]]、[[関数ベクトル]]、[[反復ヘッド]]。**更新ページ**: [[National Institute of Informatics]]、[[index]]。 --- 2026-06-16: **Michelle Brush SREcon26 Americas — Taming the Unpredictable: Reliability in Chaos** — [[@2026__SREcon26 Americas__Taming the Unpredictable - Reliability in Chaos]]([[Michelle Brush]]、[[Google]]、SREcon26 Americas 2026)。**問題**: AI エージェントでコード作成が安く速くなるほど、ジェボンズのパラドックスにより作られるシステム量と複雑性も増える。**提案**: 予測不能な複雑システムを、固定計画ではなく実験、汎用緩和、リスク先行開発、意図的仮定のコード化、継続的テストで扱う。**映像確認**: `The Curse of Knowledge`、`How Complex Systems Fail`、`Ask agents to find & fix things.`、`Experimentation`、`Codify Intentional Assumptions` の章題を代表フレームで確認。**新規ページ**: [[Michelle Brush]]。**更新ページ**: [[SRE]]、[[agentic SRE]]、[[LLMアプリケーション信頼性]]。 --- 2026-06-16: **Goldschmidt+2014 IEEE CLOUD — 時系列データベース スケーラビリティ・ロバスト性** — [[@2014__IEEE CLOUD__Scalability and Robustness of Time-Series Databases for Cloud-Native Monitoring of Industrial Processes]]([[Thomas Goldschmidt]]・[[Anton Jansen]]・[[Heiko Koziolek]]・[[Jens Doppelhamer]]・[[Hongyu Pei Breivold]]、[[ABB Corporate Research]]、IEEE CLOUD 2014)。**問題**: クラウドネイティブな産業用監視システムでオープンソース時系列データベースが高い応答性・ロバスト性要件を満たせるか未検証。**提案**: OpenTSDB・KairosDB・Databus を最大 36 ノードの AWS 上でスマートグリッドドメインのワークロードでベンチマーク評価。**結果**: KairosDB が 403,500 値/秒のほぼ線形スケールを達成。OpenTSDB は HBase のメモリ不足で再現性なし、Databus は KairosDB の約 1/10 にとどまった。**新規ページ**: [[Thomas Goldschmidt]]、[[ABB Corporate Research]]、[[時系列データベース]]、[[KairosDB]]、[[OpenTSDB]]。**更新ページ**: [[entities/_index]]、[[concepts/_index]]。 --- 2026-06-16: **Malviya+2014 ICDE — Rethinking Main Memory OLTP Recovery** — [[@2014__ICDE__Rethinking Main Memory OLTP Recovery]]([[Nirmesh Malviya]]・[[Samuel Madden]]・[[Michael Stonebraker]]、[[MIT CSAIL]]・[[VoltDB]] Inc.、IEEE ICDE 2014)。**問題**: 高スループット OLTP 環境では ARIES 生理ロギングのオーバーヘッドが無視できない割合を占める。**提案**: トランザクション名とパラメータのみを記録するコマンドロギングを提案し、VoltDB 上の TPC-C で詳細評価。**結果**: コマンドロギングが生理ロギングより TPC-C で 1.5× 高いスループットを達成するが、復旧時間は 1.5〜5× 長い。**新規ページ**: [[Nirmesh Malviya]]、[[MIT CSAIL]]、[[コマンドロギング]]、[[VoltDB]]、[[H-Store]]。**更新ページ**: [[メインメモリデータベース]]。 --- 2026-06-16: **Wu+2021 ISSRE — PatternMatcher: 根本原因メトリクス特定** — [[@2021__ISSRE__Identifying Root-Cause Metrics for Incident Diagnosis in Online Service Systems]]([[Canhua Wu]]・[[Nengwen Zhao]]・[[Dan Pei]] ほか 12 名、[[Tsinghua University]]・BNRist・China Construction Bank・[[BizSeer]]、ISSRE 2021)。**問題**: 大規模オンラインサービスで 5,000 件超のメトリクスから根本原因を手動特定するのは困難。**提案**: KS 検定による粗粒度異常検知 → 1-D CNN による 13 種異常パターン分類 → 重み付きランキングの 3 ステップ手法 PatternMatcher。**結果**: 商業銀行の実データ 113 件で Avg@3=0.91、パターン分類 F1=0.98 を達成し本番展開済み。**新規ページ**: [[Canhua Wu]]、[[@2021__ISSRE__Identifying Root-Cause Metrics for Incident Diagnosis in Online Service Systems|PatternMatcher]]、[[根本原因分析]]、[[異常検知]]。**更新ページ**: [[Dan Pei]]、[[Tsinghua University]]、[[AIOps]]。 --- 2026-06-16: **Lu+2022 CCGrid — CauseRank: OLTP データベース向け因果推論 RCA** — [[@2022__CCGrid__Generic and Robust Performance Diagnosis via Causal Inference for OLTP Database Systems]]([[Xianglin Lu]] ほか、[[Tsinghua University]]・[[Nankai University]]・[[BizSeer]] ほか、CCGrid 2022)。**問題**: OLTP データベース障害では大量のメトリクスが類似異常を示し、教師あり手法はラベル不足、異常度ベースは伝播バイアスで精度不足。**提案**: G-GES(メトリクスグループ単位の因果探索)と COPP(因果指向パーソナライズド PageRank)を組み合わせた教師なし手法 CauseRank。**結果**: Oracle 本番 97 件で top-3 精度 82.5%・MAR 2.13 を達成し MicroCause(MAR 3.95)等を上回った。**新規ページ**: [[Xianglin Lu]]、[[@2022__CCGrid__Generic and Robust Performance Diagnosis via Causal Inference for OLTP Database Systems|CauseRank]]、[[因果推論ベースRCA]]、[[Nankai University]]。**更新ページ**: [[Dan Pei]]、[[Shenglin Zhang]]、[[BizSeer]]。 --- 2026-06-16: **Xin+2022 arXiv — CausalRCA: マイクロサービス細粒度根本原因箇所特定** — [[@2022__arXiv__CausalRCA - Causal Inference based Precise Fine-grained Root Cause Localization for Microservice Applications]]([[Ruyue Xin]]・[[Peng Chen]]・[[Zhiming Zhao]]、[[University of Amsterdam]]・[[Xihua University]]、arXiv 2022)。**問題**: 既存 CI 手法(PC・LiNGAM 等)は線形仮定・曖昧性・計算コストの制約があり細粒度(障害サービス内メトリクス)の箇所特定が困難。**提案**: DAG-GNN(勾配ベース因果構造学習)で重み付き DAG を生成し、PageRank でランキングするフレームワーク CausalRCA。**結果**: 細粒度で平均 AC@3=0.719(ベースライン比 17% 改善)、粗粒度で Avg@5=0.5815(8.85% 改善)。**新規ページ**: [[Ruyue Xin]]、[[@2022__arXiv__CausalRCA - Causal Inference based Precise Fine-grained Root Cause Localization for Microservice Applications|CausalRCA]]、[[University of Amsterdam]]、[[Xihua University]]。**更新ページ**: [[因果推論ベースRCA]]、[[根本原因分析]]、[[マイクロサービスアーキテクチャ]]。 --- 2026-06-16: **Zhang+2015 TKDE — In-Memory Big Data Management and Processing: A Survey** — [[@2015__TKDE__In-Memory Big Data Management and Processing - A Survey]]([[Hao Zhang]]・[[Gang Chen]]・[[Beng Chin Ooi]]・[[Kian-Lee Tan]]・[[Meihui Zhang]]、IEEE TKDE 27(7):1920–1948、DOI:10.1109/TKDE.2015.2427795)。**カバー範囲**: メモリ階層・NUMA・HTM(Intel TSX、L1 32KB 容量制約)・NVRAM(PCM/STT-MRAM/Memristor)の基盤技術、H-Store/VoltDB・Hekaton・HyPer/ScyPer・SAP HANA・MemepiC・MongoDB・RAMCloud・Redis 等の代表系、Mammoth/Spark RDD/Storm/S4 の処理フレームワーク。**中心命題**: 「メモリ常駐は必要条件、十分条件ではない」——ディスクベースで無視できたシステムコール・ネットワークスタック・キャッシュライン跨ぎが新たなボトルネックになる。**研究機会の 6 軸**: (1) ハッシュ + ツリー + トライを統合する索引(ART 風)、(2) ログ構造化と圧縮の一般化、(3) 命令レベル(SIMD)+ スケールアップ(MIC/Xeon Phi)+ スケールアウト、(4) ロック・HTM・タイムスタンプ・原子プリミティブの混在、(5) LLVM JIT による Volcano からの脱却、(6) ユーザ空間 / カーネル空間 / ハイブリッドのオーバーフロー戦略。**[[メインメモリデータベース]] concept への波及**: 横断的知見 4 項(並行性制御の到達点・常駐の必要条件性・オーバーフローの三項対立)と未解決の問い 2 項(Optane PMEM 実機検証・HTM の Sapphire Rapids 制約)を追加。**新規ページ**: source、[[Hao Zhang]]、[[Gang Chen]]、[[Beng Chin Ooi]]、[[Kian-Lee Tan]]、[[Meihui Zhang]]、[[Singapore University of Technology and Design]]。**更新ページ**: [[National University of Singapore]]、[[Zhejiang University]]、[[メインメモリデータベース]]。 --- 2026-06-16: **The C10K Problem (Dan Kegel、1999〜2014)** — [[C10K-Problem]] ([[Dan Kegel]]、www.kegel.com)。「1台のサーバで同時10,000クライアントを処理するにはどうするか」という問いに対し、I/O 戦略を5分類:(1) 非ブロッキング + レベルトリガ(select/poll/`/dev/poll`/[[kqueue]])、(2) 非ブロッキング + エッジトリガ([[epoll]]/[[kqueue]])、(3) 非同期 I/O + 完了通知(POSIX aio_/Linux AIO/Windows IOCP)、(4) スレッド1本/クライアント(NPTL 1:1)、(5) カーネル内サーバ(TUX/khttpd)。**コア洞察**: 境界はハードウェアでなく I/O 戦略の選択にある。`sendfile()`・ゼロコピー・`TCP_CORK` でコピーコスト削減。過負荷時は新規接続積極拒否。スレッドモデルは M:N の複雑さから NPTL の 1:1 へ業界シフト。**現代への接続**: [[nginx]] の epoll/kqueue 自動選択・libuv(Node.js)・Tokio(Rust)・Java NIO・asyncio(Python)はすべてこの整理に基づく。ファイルハンドル上限 (`ulimit -n 32768` / `/proc/sys/fs/file-max`) は本記事の記述が今も有効。**新規ページ**: [[C10K問題]]、[[epoll]]、[[kqueue]]、[[Dan Kegel]]、[[nginx]]。**更新ページ**: [[index]]、[[sources/_index]]。 --- 2026-06-16: **Tsubouchi+2022 IPSJ JIP — TCP/UDP ソケットベースのネットワーク依存性発見(カーネル内フローバンドリング)** — [[@2022__IPSJ JIP__Low Overhead TCP-UDP Socket-based Tracing for Discovering Network Services Dependencies]]([[Yuuki Tsubouchi]]・[[Ryosuke Matsumoto]]・[[Masahiro Furukawa]]、[[Hatena]]、IPSJ JIP 2022、DOI:10.2197/ipsjjip.30.260)。**問題**: TCP/UDP ソケットベースの [[ネットワーク依存性発見]] は既存のストリーミング手法(kprobe で全イベントをユーザ空間へ転送)だと高 RTT/s 環境で CPU が線形増加する。**解法**: eBPF + Kprobes でハッシュテーブルキーからエフェメラルポートを除外(`{saddr, daddr, lport, direction, proto}`)し、同一宛先サービスの複数フローをカーネル内で 1 フローに束ねる **カーネル内フローバンドリング** を提案。転送フロー数はコネクション数ではなくサービス数に依存するようになるため、短命接続が大量発生しても CPU オーバーヘッドを 2.2% 以下に抑制(100万 RTT/s でストリーミング手法は ~1000% 超)。**実験**: Sakura Cloud VM + 自作 connperf で評価。スナップショットポーリング / ストリーミング / カーネル内集約(Neves+2020) / **本手法(バンドリング)** の 4 手法を比較。**精度**: TCP セッション終端型リレーには対応、NAT パケット転送は非対応。**実装**: [[go-conntracer-bpf]](Linux 5.6+、eBPF + Kprobes)。本論文は博士論文 Chapter 3 の一次ソース。**新規ページ**: [[Masahiro Furukawa]]、[[ネットワーク依存性発見]]。**更新ページ**: [[Yuuki Tsubouchi]]、[[Ryosuke Matsumoto]]、[[go-conntracer-bpf]]、[[eBPF]]、[[サービストポロジ]]。 --- 2026-06-16: **Netflix Service Topology — サイロから統合リアルタイム依存マップへ** — [[@2026__Netflix TechBlog__From Silos to Service Topology - Why Netflix Built a Real-Time Service Map]](Parth Jain・Rakesh Sukumar・Yingwu Zhao・Renzo Sanchez・Nathan Fisher、[[Netflix]] TechBlog、2026-05-29)。**問題**: 数千マイクロサービスのオブザーバビリティがメトリクス・ログ・トレースにサイロ化し、インシデント時に「誰が誰に依存しているか・ブラスト半径はどこまでか・問題は上流か」を即答できない。**解法**: 3 種の独立グラフを融合する設計。①[[eBPF]] ネットワークフロー(計装不要でカーネルレベルの全接続を網羅、ただしアプリ層詳細なし)、②[[IPCメトリクス]](計装済みサービスのエンドポイント/プロトコル詳細、ただし計装必須)、③分散トレース(実際のリクエスト経路と条件分岐、ただしサンプリング制約あり)。3 層の補完関係でカバレッジと精度を両立。**技術スタック**: [[Apache Kafka]](多リージョン取り込み)→[[Apache Pekko]] Streams(自動パーティショニング・背圧制御)→3 段集約(中継機器識別→アプリ間パス再構成→ヘルスエンリッチ)→カスタムグラフ DB→gRPC API(サブ秒クエリ)。**キーインサイト**: 「リビングマップ」——デプロイやトラフィック変化を継続反映する動的グラフが信頼の源泉。将来は AI エージェントがトポロジーを巡回して自動 RCA を行うロードマップ。**新規ページ**: [[サービストポロジ]]・[[リアルタイム依存性マップ]]・[[ブラスト半径]]・[[IPCメトリクス]]・[[Netflix]]・[[Apache Pekko]]。 --- 2026-06-16: **分散トレーシング・依存性発見・MTSAD 古典 7 論文を並列バッチ取り込み** — (1) [[@2007__NSDI__X-Trace - A Pervasive Network Tracing Framework]]([[Rodrigo Fonseca]]・[[George Porter]]・[[Randy H. Katz|Randy Katz]]・[[Scott Shenker]]・[[Ion Stoica]]、[[University of California, Berkeley|UC Berkeley]] / [[ICSI]]、NSDI 2007): タスク識別子のインバンド伝搬 + レポートのアウトオブバンド収集の 2 原則と、pushDown()/pushNext() の 2 プリミティブで因果木を完全記述する設計。**[[Dapper]]・Zipkin・[[OpenTelemetry]] の直接の祖**。(2) [[@2010__Google__Dapper - A Large-Scale Distributed Systems Tracing Infrastructure]]([[Benjamin H. Sigelman]]・[[Luiz André Barroso]]・[[Mike Burrows]] ほか、[[Google]]、2010): 共通ライブラリ計装 + 1/1024 適応サンプリングで Google 本番 2 年超稼働。スパン / トレース木 / アノテーションのデータモデルが OpenTracing・W3C Trace Context・OpenTelemetry の事実上の標準を確立。(3) [[@2007__SIGCOMM__Towards Highly Reliable Enterprise Network Services via Inference of Multi-level Dependencies]]([[Paramvir Bahl]]・[[Ranveer Chandra]]・[[Albert Greenberg]]・[[Srikanth Kandula]]・[[David Maltz]]・[[Ming Zhang (Microsoft Research)|Ming Zhang]]、[[Microsoft Research]]、SIGCOMM 2007、Sherlock): Inference Graph(3 状態 + 多層依存性)で **90.66%** 障害箇所特定精度を達成し、2 層 Shrink(58.61%)を 30% 上回る。Microsoft 本番 358 コンポーネントで **87% の障害が 16 コンポーネントに集中**。(4) [[@2008__OSDI__Automating Network Application Dependency Discovery - Experiences, Limitations, and New Solutions]]([[Xu Chen]]・[[Ming Zhang (Microsoft Research)|Ming Zhang]]・[[Z. Morley Mao]]・[[Paramvir Bahl]]、[[University of Michigan]] / [[Microsoft Research]]、OSDI 2008、Orion): 「遅延スパイクベース分析」で Sherlock 比偽陽性 10–95% 削減、eXpose 比 94–99% 削減。(5) [[@2012__LISA__On the Accurate Identification of Network Service Dependencies in Distributed Systems]]([[Barry Peddycord III]]・[[Peng Ning]]・[[Sushil Jajodia]]、[[NC State University]] / [[George Mason University]]、LISA 2012): NSDMiner の比率→対数ベースランキング置換 + 類似クラスタ推論 + LB/バックアップクラスタ自動検出で候補 25–50% 削減。(6) [[@2017__arXiv__Sieve - Actionable Insights from Monitored Metrics in Microservices]]([[Jörg Thalheim]] ほか、[[TU Dresden]]、Middleware 2017 / arXiv:1709.06686): k-Shape クラスタリングによるメトリクス次元 **10–100 倍削減** + Granger 因果性によるコンポーネント間依存推定で **CPU 80% / Storage 90% / Network 50%** オーバーヘッド削減。マイクロサービス時代の因果ベース RCA の初期基盤。(7) [[@2021__USENIX-ATC__Jump-Starting Multivariate Time Series Anomaly Detection for Online Service Systems]]([[Minghua Ma]] ほか、[[Sangfor Technologies]]、USENIX ATC 2021、JumpStarter): **圧縮センシング** + 形状ベースクラスタリング + 外れ値耐性サンプリングで**訓練不要・20 分初期化**の多変量時系列異常検知を実現し平均 **F1=94.12%** で SOTA を上回る。**横断的知見**: X-Trace(2007)→ Dapper(2010)は因果木表現とサンプリング位置づけで連続(Dapper §1 が X-Trace との概念的類似を明言)。Sherlock(2007)→ Orion(2008)→ Peddycord+(2012)は**受動観測ベース依存性発見**の連続 3 世代で偽陽性削減の漸進改善。Sieve(2017)は**メトリクス側で同じ依存性推論問題を Granger で解く**第 4 系譜で、問題ドメインが「ネットワークサービス間」から「メトリクス時系列間」へ移ったことを示す。JumpStarter(2021)は異常検知の独立軸だが、Sieve と同じく「学習ベース手法のコールドスタートを設計で迂回する」思想を共有する。 --- ## Earlier 2026-06-15: **観測可能性・分散DB 基盤 6 論文を並列バッチ取り込み** — (1) [[@1993__USENIX__The BSD Packet Filter A New Architecture for User-level Packet Capture]]([[Steven McCanne]]・[[Van Jacobson]]、[[LBNL]]、USENIX Winter 1993): カーネル内 in-VM + CFG ベース [[BPF]] を確立、`tcpdump`/`libpcap` の基盤・後の [[eBPF]] の直接の祖。(2) [[@2004__USENIX-ATC__Dynamic Instrumentation of Production Systems]]([[Bryan Cantrill]]・[[Michael Shapiro]]・[[Adam Leventhal]]、[[Sun Microsystems]]、USENIX ATC 2004): [[DTrace]] によるプロダクションでの[[動的計装|動的インストルメンテーション]]を**ゼロ[[プローブ効果]]**で実現、eBPF/bpftrace の源流。(3) [[@2018__SoCC__Weighted Sampling of Execution Traces - Capturing More Needles and Less Hay]]([[Pedro Las-Casas]]・[[Jonathan Mace]]・[[Rodrigo Fonseca]]、[[Microsoft Research]]、SoCC 2018): 一様サンプリングの希少パス取りこぼし問題に**重み付き[[トレースサンプリング]]**で対処、現代のエッジ/SLO-aware サンプリング系統の基盤(PDF 不可、abstract のみ、`confidence: medium`)。(4) [[@1992__CACM__Parallel Database Systems The Future of High Performance Database Systems]]([[David DeWitt]]・[[Jim Gray]]、CACM 1992、DOI:10.1145/129888.129894): [[並列データベース]]の[[シェアードナッシング]]・[[データパーティショニング]](range/hash/round-robin)を体系化した古典マニフェスト、MapReduce/Spark/Snowflake/BigQuery/Monarch の理論的下地。(5) [[@2023__PVLDB__TSM-Bench - Benchmarking Time Series Database Systems for Monitoring Applications]]([[Abdelouahab Khelifati]] ほか [[NYU Abu Dhabi]] / [[University of Fribourg]]、PVLDB Vol.16): 監視ワークロード特化の[[時系列データベースベンチマーク]]。(6) [[@2022__PVLDB__Anomaly Detection in Time Series - A Comprehensive Evaluation]]([[Phillip Wenig]]・[[Sebastian Schmidl]] ほか [[Hasso Plattner Institute]]、PVLDB Vol.15): TimeEval(71 アルゴ × 976 データセット) + [[GutenTAG]] を公開、本 wiki の[[異常検知]]基盤評価。**横断的知見**: BPF と DTrace は**カーネル内 in-VM 動的計装**の独立発明として並ぶ(BPF: 専用→eBPF で汎用化、DTrace: 最初から汎用)。Las-Casas+ 2018 は両者の「観測コスト最小化」を**サンプリング側で解く**第三の系譜で、現代の eBPF 観測スタック + サンプリング意識トレーサ(Jaeger/Tempo/Datadog)の合流点を 2018 時点で予見。DeWitt+Gray 1992 のシェアードナッシング + パーティショニングは [[Monarch]](2020、ゾーン分割)・TSM-Bench(2023)に直接接続。 2026-06-15: **Adams ほか VLDB 2020 — Monarch: Google's Planet-Scale In-Memory Time Series Database を wiki-ingest-paper で取り込み** — [[@2020__VLDB__Monarch - Google's Planet-Scale In-Memory Time Series Database]]([[Colin Adams]] ほか 13 名、[[Google LLC]]、PVLDB 13(12):3181–3194、2020): [[Google]] が 2010 年から運用するプラネットスケール・マルチテナント・インメモリ時系列データベース [[Monarch]] の設計・実装・運用経験の一次報告。2019 年 7 月時点で約 950 億時系列・750 TB インメモリ・2.2 TB/s 取り込み・毎秒 600 万クエリ・38 ゾーン(5 大陸)・約 40 万タスク。**核心**: (1) **CAP: AP 選択** — アラートの遅延検知を防ぐため一貫性より可用性を選び、遅延書き込みは棄却・クロスゾーンクエリは部分データを許容。(2) **循環依存回避のためのインメモリ設計** — すべての Google ストレージが Monarch に依存するため、Monarch が外部ストレージに依存すると循環依存が生じる。インメモリ保持が可用性の最初の砦。(3) **Field Hints Index(FHI)** — トライグラムベースのインメモリ索引(最大 808 MB)で、ゾーン 99.2〜99.6%・root 75.8% のクエリファンアウトを抑制。(4) **クエリプッシュダウン** — standing query の 95% がゾーン完結。ゾーン単独での監視継続を保証。(5) **Collection Aggregation** — delta + バケット + admission window で平均 36:1 の系列圧縮、CPU 代替比 25%。(6) **リレーショナルデータモデル** — Target schema × Metric schema + distribution 型(ヒストグラム + Exemplar)で intra-target join が Leaf 完結・統計的解析が単一クエリで完結。前身 [[Borgmon]] の 4 課題(分散管理・スキーマなし・distribution 型欠如・手動シャーディング)を解決。**ページ作成**: source 1([[@2020__VLDB__Monarch - Google's Planet-Scale In-Memory Time Series Database]]) + entity 1([[Borgmon]])。**ページ更新**: [[Monarch]](一次ソースから大幅拡充・規模/設計原則/主要技術/Borgmon・Gorilla 比較/RPC 研究での位置づけを整理)・[[時系列データベース]](CAP:AP 選択・循環依存回避・Collection Aggregation・FHI・クエリプッシュダウン・リレーショナルモデルの 6 件を横断的知見に追加、FHI 精度・Monarch 系列圧縮・クロスゾーンアラート整合性の 3 件を未解決の問いに追加) + sources/_index・entities/_index・log。 2026-06-15: **techRxiv サーベイ — From Pre-training to Post-training: A Survey on Time Series Foundation Models (Liu+ 2026-02-11) を wiki-ingest-paper で取り込み** — [[@2026__techRxiv__From Pre-training to Post-training - A Survey on Time Series Foundation Models]]([[Zhen Liu]]・[[Qianli Ma]]・[[Min Wu]] ほか、[[South China University of Technology]] / [[Institute for Infocomm Research]] / [[Tianjin University]]、techRxiv、DOI:10.36227/techrxiv.176978429.90235801/v2、24p): TSFM を「データセット — 事前学習 — 事後学習」の 3 次元タクソノミーで体系化した初の包括サーベイ。**核心**: (1) 既存サーベイ 7 本(Ma+ TKDE2024・Jin+ arXiv2023・Liang+ KDD2024 ほか)が事後学習と不規則時系列を扱わないことを Table I で示し、両方を扱う唯一のサーベイと位置づけ。(2) 事後学習を SFT(partial/full)・**協調(PLC: LoRA/Adapter / MLC: CLIP 流多モーダル / HLC: KD)**・**強化(reasoning-driven GRPO with CoT / non-reasoning PPO・DPO)** の 3 パラダイムで整理し、TimeMaster(token-level GRPO)・LangTime(language-guided cross-domain)・TPO(long-tail +20.05pt)を代表例として収録。(3) 将来方向としてサンプル品質評価・ドメイン特化データセット構築・事前学習アーキ設計・**Incremental Post-training**・**Agent-based Post-training** を提示。**ページ作成**: source 1 + entity 5([[Zhen Liu]]・[[Qianli Ma]]・[[Min Wu]]・[[South China University of Technology]]・[[Institute for Infocomm Research]])。**ページ更新**: [[時系列基盤モデル]](サーベイ軸の事後学習拡張・3 階層協調・推論駆動 RL の越境・不規則時系列の空白の 5 観察と問い 3 つ追加)・[[強化ファインチューニング]](TSFM 専用サーベイの RL 整理: reasoning-driven vs non-reasoning の二分軸を本 wiki の RFT 知見と接続) + sources/_index・entities/_index・index.md・manifest。 2026-06-15: **LLM×時系列の基礎 4 論文(PromptCast / LLMTime / One Fits All / TimesFM)を wiki-ingest-paper でバッチ取り込み** — tsurubee Zenn 記事(2024)が紹介した「Prompting・Aligning」アプローチの一次源と、TimesFM 原論文を、Decoder-Only TSFM の前史として一括で wiki に降ろした。**(1) PromptCast** [[@2022__arXiv__PromptCast - A New Prompt-based Learning Paradigm for Time Series Forecasting]]([[Hao Xue]]・[[Flora Salim]]、[[University of New South Wales]]、arXiv:2210.08964、IEEE TNNLS 掲載): 数値列→自然言語文のテンプレート変換で時系列予測を sentence-to-sentence へ再定式化。Bigbird/Bart/LED 等の事前学習言語モデルが数値専用 Transformer/Informer/Autoformer と同等以上の RMSE/MAE を達成し、ゼロショット汎化能力で数値モデルを大幅に上回る。[[PISA]](気温/電力/人流の 3 サブセット計 31 万件)が LLM×時系列の最初期ベンチマーク。**(2) LLMTime** [[@2023__NeurIPS__Large Language Models Are Zero-Shot Time Series Forecasters]]([[Nate Gruver]]・[[Marc Finzi]]・[[Shikai Qiu]]・[[Andrew Gordon Wilson]]、[[New York University]]・[[Carnegie Mellon University]]、NeurIPS 2023): 数値を桁列としてエンコードするだけで GPT-3・LLaMA-2 70B がゼロショット時系列予測で ARIMA/TCN/N-HiTS 等の専用モデルと同等以上(Darts/Monash/Informer 29 データセット)。**LLM の簡潔性バイアス(Occam's razor prior)と反復バイアスが季節性・トレンドの構造と一致**するため外挿が成立。GPT-4 が GPT-3 より悪化する現象を初めて定量化し、**アライメント(RLHF)とトークン化変更が不確実性較正を壊す**ことを示した。**(3) One Fits All (FPT)** [[@2023__NeurIPS__One Fits All - Power General Time Series Analysis by Pretrained LM]]([[Tian Zhou]]・[[Rong Jin]]・[[Liang Sun]] ほか [[Alibaba DAMO Academy]]、NeurIPS 2023): GPT-2 の self-attention・feedforward を凍結し位置埋め込み+正規化のみ学習する [[Frozen Pretrained Transformer]] で時系列 7 タスク(分類・異常検知・補完・短期/長期予測・few-shot/zero-shot)SOTA。学習可能パラメータが全体の 4.6〜6.12% にとどまり TimesNet(42M)に対し計算優位。**画像事前学習(BEiT)からの転移も有効**で言語→時系列に限らない汎ドメイン転移を実証し、self-attention の勾配最小化が PCA と等価という理論的根拠を提示。**(4) TimesFM** [[@2024__arXiv__A Decoder-Only Foundation Model for Time-Series Forecasting]]([[Abhimanyu Das]]・[[Rajat Sen]] ほか [[Google Research]]、arXiv:2310.10688、ICML 2024): 200M decoder-only Transformer + パッチ入力 + **出力パッチ長 > 入力パッチ長**(自己回帰ステップ削減)を組み合わせ、Google Trends 約 0.5B 点 / Wikipedia ページビュー 約 300B 点 / 合成データの計約 100B 時系列点で事前学習。Monash/Darts/ETT 等で教師あり SOTA(PatchTST・N-BEATS)にゼロショットで肉薄。17M/70M/200M でモデル誤差が FLOPS に対し単調減少し、**TSFM スケーリング則の前史**を形成([[Toto|Toto 2.0]] の 4M〜2.5B 単調改善実証へ続く)。**最大の横断的知見**: tsurubee 2024 サーベイが Prompting/Quantization/Aligning/Vision/Tool の 5 アプローチ分類で提示した俯瞰に対し、それぞれの**一次論文の細部・限界・実験設計**を独立検証可能な形で wiki に揃え、後段([[TimeCopilot]]・[[エージェント型時系列予測]]・[[Toto|Toto 2.0]])の TSFM 系研究を支える起点 4 本が完成。**ページ作成**: source 4 + entity 7([[Hao Xue]]・[[Flora Salim]]・[[PISA]]・[[Nate Gruver]]・[[Marc Finzi]]・[[Shikai Qiu]]・[[Andrew Gordon Wilson]]) + concept 1([[Frozen Pretrained Transformer]])。**ページ更新**: [[LLMTime]]・[[TimesFM]]・[[University of New South Wales]]・[[New York University]]・[[Carnegie Mellon University]]・[[Tian Zhou]]・[[Rong Jin]]・[[Liang Sun]]・[[Abhimanyu Das]]・[[Rajat Sen]]・[[Google Research]]・[[LLM時系列アプローチ]]・[[時系列基盤モデル]]・[[多変量時系列予測]]・[[スケーリング則]]・[[異常検知]] + 全索引・manifest。 2026-06-15: **Zenn 記事 — 時系列データのための大規模言語モデル (tsurubee, 2024-07-10) を wiki-ingest で取り込み** — [[@2024__Zenn__tsurubee__LLM-for-Time-Series]]([[Hirofumi Tsuruta|tsurubee]]、[[SAKURA Internet]]、2024-07-10): サーベイ論文「Large Language Models for Time Series: A Survey」[Zhang+ 2024, arXiv:2402.01801] を解説した Zenn 記事。LLM を時系列に適用する手法を **Prompting / Quantization / Aligning / Vision / Tool の 5 アプローチ**に分類する。**核心**: (1) Prompting — スペース区切り桁列トークン化(LLMTime)でゼロショット予測が教師ありモデルと同等以上を示す。GPT-4 が GPT-3 より性能低下する現象も報告。(2) Aligning(LLM バックボーン型) — One Fits All が GPT-2 の self-attention・feedforward を凍結し位置埋め込みのみ学習(FPT)、7 タスク最先端。**画像事前学習(BEiT)からの転移も有効**——言語→時系列だけでなく異分野知識転移の広汎性を実証した点が [[時系列基盤モデル]] 前史として重要。**新規作成**: source 1([[@2024__Zenn__tsurubee__LLM-for-Time-Series]]) + entity 1([[Hirofumi Tsuruta|tsurubee]]) + concept 1([[LLM時系列アプローチ]])。**更新**: [[時系列基盤モデル]]・[[SAKURA Internet]] + 全索引・manifest。 2026-06-15: **Datadog blog — Production-Grounded Benchmarks for AI Code Optimization (DODO) を wiki-ingest-paper で取り込み** — [[@2026__Datadog__Production-Grounded Benchmarks for AI Code Optimization]]([[Junaid Ahmed]]・[[Piotr Bejda]]、[[Datadog]]、2026-06-08): [[DODO]](Datadog Observability-Driven Optimizer)は、LLM エージェントによるコード最適化を本番テレメトリで接地するシステム。**2 ループ構成**: (1) Datadog Continuous Profiler の CPU フレームグラフ + Live Debugger の実関数呼び出し(引数・受信オブジェクト状態)から本番プロファイルと ≥98% 類似する Go マイクロベンチマークを反復生成するベンチマーク生成ループ、(2) ベンチマーク凍結後に LLM エージェントがコード変更を提案・`run_tests`/`run_benchmark` で検証する最適化ループ。**核心**: 合成ベンチマークでは入力分布・実行形状・受信オブジェクト状態が本番と乖離し、エージェントがベンチマーク人工物を最適化してしまう——NormalizeTags 事例で入力タグ 25% 大文字という本番特性依存の高速 ASCII 折り畳みパスが合成では不可視だったことを実証。成熟した内部 Go サービスに適用してサービス全体 CPU コストを 8% 以上削減(O(10k) コア常時節約)。`filterTags` 82%・`FilterPayloads` 75%・`writeTagsetsMut` 76% の高速化が顕著。**[[本番接地型ベンチマーク]]** という設計原則をコード最適化エージェント評価に持ち込んだ事例として、[[エージェント型コーディング]] の「訓練-テスト環境一致」原則(Composer 2・DeepSWE)を評価・ベンチマーク生成側に拡張する同型設計思想と位置づけられる。**ページ作成**: source 1([[@2026__Datadog__Production-Grounded Benchmarks for AI Code Optimization]]) + entity 3([[DODO]]・[[Junaid Ahmed]]・[[Piotr Bejda]]) + concept 1([[本番接地型ベンチマーク]])。**ページ更新**: [[Datadog]]・[[エージェント型コーディング]](本番接地知見・収束保証の問い追加)・[[継続的プロファイリング]](コード最適化基盤としての拡張用途) + 全索引・manifest。 2026-06-15: **因果推論ベース RCA + LLM ベース RCA の 2022/2024 基礎論文 3 本バッチ取り込み(RCACopilot / CIRCA / RCD)** — **(1) RCACopilot**([[@2024__EuroSys__Automatic Root Cause Analysis via Large Language Models for Cloud Incidents]]、[[Yinfang Chen]]・[[Minghua Ma]]・[[Qingwei Lin]]・[[Saravan Rajmohan]]・[[Dongmei Zhang]]・[[Tianyin Xu]] ほか [[Microsoft]] / UIUC / [[Peking University]] / [[Huazhong University of Science and Technology]] / [[National University of Singapore]]、EuroSys 2024、DOI:10.1145/3627703.3629553、arXiv:2305.15778v4、15p): LLM 強化オンコールシステム [[RCACopilot]]。アラート種別ハンドラ(scope/query/mitigate アクションノードの DAG)で多種ソース(ログ・メトリクス・トレース・スクリプト)から診断情報を自動収集し、GPT-4 で要約 → FastText 埋め込み + 時間重み付き k-NN(時間減衰係数 0.01) + few-shot CoT で根本原因カテゴリ予測 + 説明文生成。Microsoft Transport 1 年データで Micro-F1=0.766 / Macro-F1=0.533、Ahmed+ ICSE 2023 を大きく上回る。診断情報収集部は Microsoft 30 超チーム・4 年以上の本番稼働、根本原因予測部も複数ヶ月本番デプロイ済み。**情報スペクトラム問題**を実証: 診断情報のみ(0.766)が最良、アラート情報のみ(0.379)・両混合(0.525)で性能低下し、情報過多は不足と同じく RCA を損なう。**(2) CIRCA**([[@2022__KDD__Causal Inference-Based Root Cause Analysis for Online Service Systems with Intervention Recognition]]、[[Mingjie Li]]・[[Dan Pei]] ほか [[Tsinghua University]] / BizSeer、KDD 2022、DOI:10.1145/3534678.3539041): Pearl の Causal Hierarchy で RCA を「介入認識(IR)」タスクとして初めて定式化(Theorem 3.4)し、IR が L2 介入知識に属することを Corollary 3.3 で証明。アーキテクチャ知識(コールグラフ + Traffic/Saturation/Latency/Errors)から構造グラフを構築、SVR ベース回帰仮説検定(RHT) + 子孫調整で Oracle DB の高 AAS 障害 99 件(197 メトリクス)で AC@1=0.404・分析時間 0.578 秒を達成し最良ベースライン NSigma(0.323)比 +25%。コード公開: github.com/NetManAIOps/CIRCA。**(3) RCD**([[@2022__NeurIPS__Root Cause Analysis of Failures in Microservices through Causal Discovery]]、[[Azam Ikram]]・[[Saurabh Bagchi]]・[[Murat Kocaoglu]]([[Purdue University]])・[[Sarthak Chakraborty]]([[Adobe Research]])ほか、NeurIPS 2022、pp.31158-31170): マイクロサービス障害を soft intervention としてモデル化し、F-NODE($F=0$ 正常 / $F=1$ 障害)で $X \perp\!\!\!\perp F | Pa_X$ の条件付き独立性検定 + 階層分割統治 Ψ-PC でコールグラフ不要・パラメトリック仮定不要を実現。合成 100 ノードで top-1 再現率 98%、500 ノードで 22 秒(対 Ψ-PC 150 分超で約 400× 高速化)、[[Sock Shop]] テストベッド・AWS 本番 3 障害ケースで競合ベースラインを上回る。Outage B では Memcached の hit ratio が潜在変数として top-1 を外し、causal sufficiency 仮定の限界を境界条件として明示。**横断的知見**: CIRCA と RCD は同年(2022)発表の双璧で、「ドメイン知識 + 正確性軸(CIRCA)」と「ドメイン知識不要 + スケーラビリティ軸(RCD)」の設計対比をなす。両者は Pearl L2 介入知識の実用化において補完関係——CIRCA は介入分布変化を直接スコアリング、RCD は介入分布変化をフィルタとしてグラフ探索を局所化。一方 RCACopilot は形式論より「経験的ハンドラ + LLM 圧縮」が本番運用で先行することを 30 超チーム・4 年実績で示し、後続の TSGuard(FSE 2026)・FlowXpert(KDD 2025)などのハンドラ + LLM 抽象を提案する LLM-era AIOps システム群の起点となる。[[@2024__ASE__Root Cause Analysis for Microservices based on Causal Inference - How Far Are We]] と [[@2025__WWW Companion__RCAEval - A Benchmark for Root Cause Analysis of Microservice Systems with Telemetry Data]] の包括評価では CIRCA・RCD ともにマルチソース化で AC@1 が劣化(0.32→0.06、0.09→0.10)し、因果グラフ系手法のモダリティ拡張への脆さが両論文に共通。**ページ作成**: source 3 + entity 13([[Yinfang Chen]]・[[RCACopilot]]・[[Mingjie Li]]・[[Kanglin Yin]]・[[Xiaohui Nie]]・[[Wenchi Zhang]]・[[Kaixin Sui]]・[[CIRCA]]・[[Azam Ikram]]・[[Saurabh Bagchi]]・[[Murat Kocaoglu]]・[[Sarthak Chakraborty]]・[[Adobe Research]]・[[Purdue University]]・[[Sock Shop]]・[[RCD]])。**ページ更新**: [[Dan Pei]]・[[因果推論ベースRCA]](CIRCA + RCD の横断的知見・未解決の問い計 5 項目追加)・[[根本原因分析]](3-paper 比較観察・RCACopilot ハンドラ自律生成の問い)・[[TSG自動化]](RCACopilot ハンドラ抽象 = TSG 自動化先祖系統)・[[RCA入力選別]]・[[RCA評価設計]](CIRCA D_O オラクル) + sources/_index・entities/_index・index.md・hot.md・log.md・manifest。 2026-06-15: **Datadog blog — Toto 2.0: Time Series Forecasting Enters the Scaling Era を wiki-ingest で取り込み** — [[@2026__Datadog__Toto-2.0-Time-Series-Forecasting-Enters-the-Scaling-Era]]([[Emaad Khwaja]]・[[Gerald Woo]]・[[Chris Lettieri]]・[[Ameet Talwalkar]]・[[David Asker]]、[[Datadog]] AI Research、2026-05-14、技術レポート arXiv:2605.20119): [[Toto]] の第 2 世代として 4M〜2.5B の 5 サイズ family を公開。主な技術革新は 2 点。**[[Contiguous Patch Masking]](CPM)**: 学習時に連続パッチを一括マスクしてシングルパス推論を可能にし、逐次自己回帰デコーディングを廃止。313M 変種が[[Chronos-2]](120M)と同等レイテンシを達成。**[[u-μP]]**: 小規模プロキシモデルでハイパーパラメータをチューニングし大規模モデルへ転移。スケーリング実験コストを大幅削減。実装ライブラリ `dd_unit_scaling`(PyTorch compile/FSDP2/DDP、Apache 2.0)を公開。**スケーリング結果**: 4M→2.5B で BOOM CRPS が 7.17→3.88 と単調改善・飽和なし。22M が旧 Toto 1.0(151M)の 7 分の 1 パラメータで同等性能——**観測特化 TSFM で初の本格スケーリング則実証**。事前学習は Datadog 観測メトリクス+合成データのみ(公開予測データセット不使用)で [[BOOM]]/[[GIFT-Eval]](97 データセット)/TIME(汚染耐性) の全ベンチ上位を独占。GIFT-Eval のメタ学習器分析では Toto family がアンサンブル予測の平均 39% を担う。**将来課題**: (1) 古典的手法とのギャップ(外挿整合・不確実性較正)、(2) データキュレーションの体系化、(3) メトリクスを独自モダリティとして扱うモデリング、(4) メトリクス×トレース×ログ×トポロジーのマルチモーダル統合。**位置づけ**: [[時系列基盤モデル]] の「モデル改良」路線でスケーリング時代への移行を宣言。CPM は [[Falcon-X]] のマスク再構成とは別方式の非逐次推論を実現し、TSFM の計算効率研究([[SPRINT]] の推論時ラッパー)とは設計段での効率組み込みとして対比される。**ページ作成**: source 1 + entity 4 + concept 2。**ページ更新**: [[Toto]]/[[Datadog]]/[[Ameet Talwalkar]]/[[時系列基盤モデル]]/[[index]]。 2026-06-15: **Remil+ arXiv 2024 — AIOps Solutions for Incident Management: Technical Guidelines and A Comprehensive Literature Review を wiki-ingest-paper で取り込み** — [[@2024__arXiv__AIOps Solutions for Incident Management]]([[Youcef Remil]]・[[Anes Bendimerad]]・[[Romain Mathonat]]・[[Mehdi Kaytoue]]、[[University of Lyon]] / [[INSA Lyon]] / [[CNRS]] UMR 5205 / [[Infologic]]、arXiv:2404.01363 cs.OS、2024-04-01、82p、DOI:10.48550/arXiv.2404.01363): AIOps for incident management の包括的サーベイ。**6 能力モデル**(Perception / Prevention / Detection / Location / Action / Interaction)で AIOps を再分解し、本 wiki が AIOpsLab の 4-level taxonomy(検知/箇所特定/RCA/緩和)で見てきた構造に Perception(テレメトリ収集・ストリーミング/履歴)と Interaction(人間との双方向 loop)を独立能力として加える。**4 フェーズ × 9 タスク手続き**(reporting{Detection, Prediction} → triage{Prioritization, Assignment, Classification, Deduplication} → diagnosis{RCA, Correlation} → mitigation)では classification・deduplication・correlation を独立タスクとして明示分離(Notaro+ 2021 や Zhang+ 2015 が他タスクに畳んでいた粒度を細分化)。**4 層 Maintenance Strata**(Technical / Application / Functional / Business)で業務インパクトの縦軸を補い、**Maintenance Protocols** を reactive(palliative / curative)・proactive(predictive / prescriptive)に細分化。**9 軸 taxonomy**(Context: Incident Task / Focus Area / Maintenance Layer、Data: Data Source / Data Type、Model: Approach / Paradigm、Evaluation: Metrics / Package Availability、Particularities)で 100+ 件の手法を体系的に索引化し、データソースを 8 種(source code / topology / event logs / KPIs / network traffic / incident reports / alerting signals / execution traces)で定義。**6 項目 desiderata**(trustability + human-in-the-loop、interpretability の internal/external/time 3 軸 consistency、scalability、maintainability + adaptability、robustness、in-context evaluation の **contamination zone phenomenon** への注意)で AIOps 構築要件を明文化。**40+ 件の公開データセット compendium**(Table 26)を application area 横断で 1 表に統合した最初の試み(IDS・anomaly detection・SDP・disk failures・RUL・bug triage・SFL・database issues 等)。Salfner+ 2010 の 4 パラメータ時間軸(`Δt_d, Δt_l, Δt_p, Δt_w`)を採用し、評価指標を classification 系(Precision/Recall/F-measure/ROC/AUC)・regression 系(MAE/RMSE/MAPE/R²)・domain-specific(T-Score / EXAM / MRR / MAP@k / MTTR/MTTE/MTTD/MTBF)に整理。**新規性**: classification・deduplication・correlation の独立タスク化、interpretability 3 次元定義、contamination zone phenomenon の明文化、descriptive 模型(pattern mining・FCA)の predictive 模型に対する優位性主張(データ多様性・複雑性・品質への強さ、deduplication との親和性)、40+ 件のデータセット compendium。Figure 14 で Notaro+ 2021 の「detection 33.7% / RCA 26.7% / online prediction 26.4% / prevention 10.6% / remediation 2.5%」の研究密度偏りを別データで再確認し、これが文献選定バイアスでなく **AIOps 研究空間の構造的偏り**である可能性を独立に強化。**横断的知見**: 本 wiki の LLM-era 蓄積([[AIOpsLab]] / [[SREGym]] / [[Bian Que]] / [[OpsAgent]] / [[Bits AI SRE]] 等)を Remil+ の 6 能力 × 4 フェーズの細分粒度で再ラベリングできる新しい解像度。例えば [[OpsAgent]] の 4 エージェントを {Prioritizer, Classifier, Deduplicator, Router} の分業として、[[AlertGuardian]] の rule refinement を Classification + Deduplication 横断の上流介入として、[[FLASH]]/[[StepFly]]/[[LLexus]] の TSG 自動化を Mitigation + Correlation(過去類似の参照)として読み直せる。LLM-era ベンチマーク([[AIOpsLab]]/[[SREGym]]/[[OpenRCA]])の数値を contamination zone の規律で再校正する必要が浮上。LLM-era 以前のサーベイ(2024-04 時点)のため agentic SRE 系は射程外だが、AlertGuardian の rule refinement・FlowXpert のワークフロー生成・TSGuard のタクソノミー半自動構築は Remil+ が推奨する「descriptive 知識の自動構築」と pattern mining 系の融合方向を独立に実装している可能性。**ページ作成**: source 1 + entity 8([[Youcef Remil]] / [[Anes Bendimerad]] / [[Romain Mathonat]] / [[Mehdi Kaytoue]] / [[University of Lyon]] / [[INSA Lyon]] / [[CNRS]] / [[Infologic]])。**ページ更新**: [[AIOps]](6 能力モデル・descriptive vs predictive・interpretability 3 軸・contamination zone・研究密度偏りの 2 サーベイ独立確認)・[[インシデント管理]](4 フェーズ × 9 タスク手続き再整理・4 層 Maintenance Strata 縦軸補強)・[[障害予測]](Prevention 能力の offline+online 束ねの再構成・`Δt_p` と運用メトリクス連結) + sources/_index・entities/_index・index.md・hot.md・log.md・manifest。 2026-06-15: **Hussain+ FSE 2026 industry — Attention Enhanced Entity Recommendation for Intelligent Monitoring in Cloud Systems を wiki-ingest-paper で取り込み** — [[@2026__FSE__Attention Enhanced Entity Recommendation for Intelligent Monitoring in Cloud Systems]]([[Fiza Husain]]・[[Anson Bastos]]・[[Anjaly Parayil]]・[[Ayush Choure]]・[[Chetan Bansal]]・[[Rujia Wang]]・[[Saravan Rajmohan]]、[[Microsoft]]、FSE 2026 industry track、arXiv:2510.20640、12p、2025-10-23): Microsoft 本番のクラウドモニタについて、メトリクスは決まった上で「どのディメンション部分集合で集約してアラートを上げるか」を、モニタ・メトリクス・ディメンションのヘテロジニアスエンティティグラフ(モニタ 18,291・メトリクス 4,623・ディメンション 8,356、エッジ 213,509)上のランキング問題として定式化。データ分析(§3) は (i) ディメンション次数の長尾、(ii) モニタ名類似と Jaccard 相似の低相関、(iii) ディメンション対相関の二峰性を示し、「sparse + low-homophily」をモデル要件として固定。提案手法 [[@2026__FSE__Attention Enhanced Entity Recommendation for Intelligent Monitoring in Cloud Systems|DiRecGNN]] は (i) エッジ認識マルチヘッド注意のメッセージパッシング(式 2)、(ii) ターゲットノードからの restart 付きランダムウォーク経路に対する Random Walk Attention(RWA、式 3)、(iii) BCE + TOP1-max ranking + Attention-Alignment(式 6、$\lambda_{al}\sum_l\mathrm{MSE}(\alpha_l,\bar\alpha_l)$)の多面的損失 + 動的損失バランシングからなり、計算量は $O(|E|)$、サンプリングで sub-linear。Table 2 で SAGEConv/GAT/HGT/HAN/HetGNN/TransformerConv 等の最良ベースラインに対し HR@1 0.597(+55.8%)・NDCG@k 0.555(+69.2%)・Recall@5 0.748(+43.02%)・MRR 0.714(+43.1%)。Figure 6 で経路長と RWA サンプル数の増加が単調改善、Figure 7a で低次数ノードほどゲインが大きく sparse 仮説と整合、Figure 7b でノード数に対する線形スケール。Figure 8 で attention-alignment 損失「無し」の拡散注意と「有り」の集中注意を可視化。DBLP ノード分類(Macro-F1 95.03)と LastFM 知識推薦(recall@20 0.1026)で汎化性も主張。**§6 ユーザースタディ**: 6 か月で 74–797 回モニタ変更したエンジニア 30 名から無作為抽出 10 名(33%)の構造化インタビュー。Q2 で全員(10/10)が「構造化説明付きディメンション推薦は有用」、Q3 で全員がモニタ作成時、4/10 がバグモニタ修正時にも有用、Q4 で平均 4.5/5(extremely 3・somewhat 7・neutral 1)、Q5 で end-to-end 自動化とプロンプトボックス UI を望むという回答。Figure 9 の UI 例は「類似モニタとそこで使われている数式・フィルタ」を説明として添える設計。**横断的知見**: Microsoft Intelligent Monitoring ラインの「Ganatra 2023(ミス検知 40.41%)→ Srinivas 2024(メトリクス選定)→ Hussain 2026(ディメンション部分集合推薦)」3 階層が明示的になり、本番モニタの 94% が「全ディメンションを使わない」(Figure 2b) ためディメンション選定こそが運用律速であることが定量化された。汎用 HGNN(SAGEConv 等)が HR@1 0.29–0.40 にしか届かない sparse モニタグラフを、ランダムウォーク経路への明示的注意と注意ヘッド整列損失で 0.597 まで引き上げた事例として、[[クラウドモニタリング]] の「メタ層 LLM(MonitorAssistant)とは別系統で『構造グラフ表現学習』が産業実装の焦点になっている」ことを示す。説明として「類似モニタの提示」が end-to-end 自動化要望と並ぶ実運用要件として確認された。**ページ作成**: source 1 + entity 1([[Anson Bastos]])。**ページ更新**: [[Fiza Husain]](alias に "Fiza Hussain" 追加)・[[Chetan Bansal]]・[[Anjaly Parayil]]・[[Ayush Choure]]・[[Saravan Rajmohan]]・[[Rujia Wang]]・[[クラウドモニタリング]](DiRecGNN 階層・sparse HGNN 限界・類似モニタ説明 UI の 4 件を横断的知見に追記、静的グラフ仮定・閾値推薦への接続・LLM×HGNN 統合の 3 件を未解決の問いへ)+ sources/_index・entities/_index・concepts/_index・index.md・log.md・manifest。 2026-06-15: **Xiong+ USENIX ATC 2024 — SuperBench: Improving Cloud AI Infrastructure Reliability with Proactive Validation を wiki-ingest-paper で取り込み** — [[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]]([[Yifan Xiong]]・[[Yuting Jiang]]・[[Ziyue Yang]]・[[Lei Qu]] ほか17名、[[Microsoft Research]] / [[Microsoft]]、USENIX ATC '24 Best Paper、17p、URL: https://www.usenix.org/conference/atc24/presentation/xiong): AI クラウドのハードウェア冗長(HBM 行リマップ・GPU CUDA コア冗長・InfiniBand 過剰プロビジョン uplink)がインシデント直前まで劣化を覆い隠す「グレイ障害」を Azure A100 実データで定量化(MTBI 17.5 時間、HBM 行リマップが 10 件超で回帰確率 5.6%→83.3%、初回 719.4h → 20 回目 151.7h の漸減)。プロアクティブ検証システム [[SuperBench]] は (i) 単一/マルチノード代表ベンチマーク群、(ii) 経験 CDF の片側距離で基準を学習する **Validator**(Algorithm 2、IQR/k-means を 4/5 モデルで上回る Margin Ratio)、(iii) **Cox-Time** 生存解析(NN 拡張・予測精度 93.13%)でインシデント確率を予測し $\Delta p/t_i$ 最大化貪欲法でベンチマーク部分集合を選ぶ **Selector**(Algorithm 1)の三層構成。Networking 検証は Clos トポロジを使う Full Scan $O(n)$ と $k$-tier fat-tree の Quick Scan $O(1)$ で規模非依存化、ベンチマークパラメータは季節分解で warmup/measurement を自動探索(再現性低下 < 1% で時間 67.45〜78.30% 削減)。シミュレーション(30 日、1k ノード)で **MTBI 22.61×・利用率 4.81×・検証時間 92.07% 削減**(無検証比)、フルセット検証比でも MTBI 1.11×・検証時間 92.07% 削減を達成。Azure 本番 2 年運用で 24k+ A100 GPU(3k+ VM)から **10.36% のノードを欠陥として除外**。ベンチマーク群は microsoft/superbenchmark で OSS 化、AMD Instinct と PyTorch/ROCm で標準として参照。**新規 concept**: [[グレイ障害]](Huang+ 2017 の概念を AI クラウド文脈へ拡張)と [[プロアクティブ検証]](事前検証を運用 KPI として定式化)。**横断的知見**: 「件数より GPU 時間で測れ」(ByteRobust)を**検証側にも適用**した最初の体系で、フルセット検証より部分集合検証が MTBI で勝つことを実証。冗長機構がそれ自身グレイ障害を内蔵するという観察は GPU Resilience(spare row 512 固定)・Guard(グレーノード=fail-slow)と直結。Cox-Time + 行動結合は障害予測の AI インフラ向け代表例。**ページ作成**: source 1 + entity 6([[Yuting Jiang]]・[[Ziyue Yang]]・[[Lei Qu]]・[[Yongqiang Xiong]]・[[Lidong Zhou]]・[[SuperBench]]) + concept 2([[グレイ障害]]・[[プロアクティブ検証]])。**ページ更新**: [[Yifan Xiong]]・[[Peng Cheng]]・[[GPUクラスタ運用]]・[[GPUレジリエンス]]・[[プロアクティブ障害管理]]・[[障害予測]] + sources/_index・entities/_index・concepts/_index・index.md・hot.md・log.md・manifest。 2026-06-15: **マイクロサービス RCA ベンチマーク + AI ワークロード インシデント診断の論文 2 本バッチ取り込み(RCAEval / TSGuard)** — **(1) RCAEval**([[@2025__WWW Companion__RCAEval - A Benchmark for Root Cause Analysis of Microservice Systems with Telemetry Data]]、[[Luan Pham]] ほか [[RMIT University]] / [[University of Newcastle]] / [[University of New South Wales]]、WWW Companion 2025、4p、DOI:10.1145/3701716.3715290): マイクロサービス RCA の公開ベンチマーク [[RCAEval]] を [[Online-Boutique]](12 サービス)・[[Sock Shop]](15 サービス)・[[Train-Ticket]](64 サービス)から 735 ケース・11 種障害(リソース 4 / ネットワーク 2 / コードレベル 5)・3 データセット(RE1/RE2/RE3)で構築し、15 ベースライン(メトリクス系 9・トレース系 2・マルチソース系 4)を統一フレームワークで横並び評価可能にする。**コードレベル障害を扱う初の RCA データセット**を主張。Train Ticket / RE2 / 6 障害の予備実験で BARO が CPU/MEM/DISK でほぼ満点、TraceRCA が DELAY で BARO を大きく上回る(0.85 vs 0.47)。マルチソース化が CIRCA(0.32→0.06)・RCD(0.09→0.10)で**逆効果**になる現象を定量化。**(2) TSGuard**([[@2026__FSE__TSGuard - Automated User-Centric Incident Diagnosis for AI Workloads in the Cloud]]、[[Yitao Yang]] ほか [[The Chinese University of Hong Kong]] / [[Microsoft Research]] / [[University of Toronto]]、FSE 2026、24p、DOI:10.1145/3797149): AI ワークロード(GPU クラスタ訓練)のインシデント診断を **user-centric paradigm** で動かす多エージェントシステム [[TSGuard]] を提案。Microsoft Azure 本番 1 年データ(778 件)で median TTM 52.5 時間・GPU 関連 52.47%・recurrence 8.78 という分布を実証し、過去事例 DB(quick)・階層タクソノミー 6/28/97(slow)・探索(deep)の 3 段パイプライン + 5 エージェント(Summarization/Planning/Execution/Reflection/Conclusion)を実装。本番 208 件で Micro F1=0.854・Macro F1=0.816、[[RCACopilot]] 比 Micro +19.8%・Macro +43.6%、検証時間 -63.4%(304s vs CVD 830s)を達成。Qwen2.5-72B など open-source LLM でも GPT-4o と同等運用可能。pre-ticket interception layer として user 側で動かす設計が既存研究の provider-centric paradigm からの転換点。**横断的知見**: RCAEval は「ベンチカバレッジで広げる」路線で 2024 ASE Dummy ベースライン導入の系譜を継ぎ、Cloud-OpsBench(決定論再現性)・FPA-Bench(伝播パターン)と並ぶ 3 路線目を確立。TSGuard は recurrence 高ドメインで knowledge base ベース診断が dominant(quick path 単独で 51.4% 解決)であることを定量化し、マルチエージェント能動検証が RCACopilot の one-shot 推論を Macro F1 で 43.6 ポイント上回ることを実証。両論文は AIOps の研究地図に「ベンチマークのカバレッジ拡張」と「provider-centric → user-centric の主体軸転換」という 2 つの設計次元を独立に追加する。**ページ作成**: source 2 + 新規 entity 11([[Flora Salim]] / [[Xiuzhen Zhang]] / [[University of New South Wales]] / [[Yitao Yang]] / [[Yifan Xiong]] / [[Baochun Li]] / [[Peng Cheng]] / [[Microsoft Research]] / [[University of Toronto]] / [[TSGuard]] / [[RCACopilot]])。**ページ更新**: [[Luan Pham]]・[[Huong Ha]]・[[Hongyu Zhang]](Newcastle 再所属)・[[RMIT University]]・[[University of Newcastle]]・[[RCAEval]]・[[Sock Shop]]・[[Online-Boutique]]・[[Train-Ticket]]・[[Microsoft Azure]]・[[The Chinese University of Hong Kong]]・[[Yangtao Deng]]・[[Hong Xu]] + [[RCA評価設計]]・[[障害注入]]・[[因果推論ベースRCA]]・[[インシデント管理]]・[[AIOps]]・[[Fault Localization]]・[[マルチモーダル障害診断]]・[[耐障害LLM訓練]] + sources/_index・entities/_index・index.md・hot.md・log.md・manifest。 2026-06-15: **Hu ほか 2024(NSDI)— Characterization of Large Language Model Development in the Datacenter を wiki-ingest-paper で取り込み** — [[@2024__NSDI__Characterization of Large Language Model Development in the Datacenter]]([[Qinghao Hu]]・[[Zhisheng Ye]]・[[Zerui Wang]]・[[Guoteng Wang]]・[[Meng Zhang]]・[[Qiaoling Chen]]・[[Peng Sun]]・[[Dahua Lin]]・[[Xiaolin Wang]]・[[Yingwei Luo]]・[[Yonggang Wen]]・[[Tianwei Zhang]]、[[Shanghai AI Laboratory]] / [[Nanyang Technological University]] / [[Peking University]] / [[Shanghai Jiao Tong University]] / [[SenseTime Research]] / [[The Chinese University of Hong Kong]]、NSDI '24、22p): [[Acme]] の LLM 専用 GPU データセンター(Seren 2,288 + Kalos 2,416 = 4,704 A100)の 6 か月本番トレース(2023-03〜08)を [[Philly]]/[[Helios]]/[[Alibaba PAI|PAI]] と同一指標で比較。GPU ジョブ中央値 2 分(他クラスタの 1.7〜7.2× 短)、Seren/Kalos の GPU 利用率中央値 97/99%(Philly 48%・PAI 4%)で 0/100% に二極化、Pretraining が件数 0.9〜3.2% で GPU 時間 69.5〜94.0% を消費し Evaluation は短ジョブにもかかわらず最長キュー遅延を持つ二重構造、CPU メモリ <50%・IB 帯域最大 25% 未満で補助資源は余剰、GPU が電力 65.7% を占める。障害は NVLinkError 30.25% / CUDAError 15.77% / NodeFailure 14.30% / ECCError 11.00% で Infrastructure 系合計が件数 ~11% で GPU 時間 82%超、2023 年 7 月の気温起因 NVLinkError 集中。観測に基づき [[InternEvo]] に (1) Fault-tolerant Pretraining(async checkpointing で 7B・123B の overhead を 3.6〜58.7× 削減・Log Agent + Failure Agent + Vector Store + 2 段階 NCCL allgather test で手動介入 ~90% 削減)、(2) Decoupled Scheduling for Evaluation(モデルロードのノード単位 precursor job 化・metric 計算の CPU ジョブ分離・prior-based elastic scheduling で makespan を 1.3〜1.8× 短縮)を実装し、[[AcmeTrace]] を公開。**横断的知見**: 「LLM を訓練ログ診断の主役に据える」設計の最初期本番事例(L4・LLMPrism・ByteRobust 系統の上流)、2 段階 NCCL allgather による精密箇所特定(ByteRobust の過剰排除・Minder/Pulse のメトリクスパターン検出と並ぶ第三の系統)、async checkpointing と CPU メモリ余剰観測の直結、Evaluation の長キュー遅延が Pretraining 優先予約構造から不可避に生じる逆転。**ページ作成**: source 1 + entity 6([[Dahua Lin]]・[[Yonggang Wen]]・[[Nanyang Technological University]]・[[SenseTime Research]]・[[InternLM]]・[[AcmeTrace]])。**ページ更新**: [[Acme]]([[@2024__NSDI__...]] を sources へ追加 + 関連 [[耐障害LLM訓練]]/[[LLM学習モニタリング]]/[[AcmeTrace]] 追加)・[[耐障害LLM訓練]](LLM 診断主役化・2 段階 NCCL allgather・async checkpointing と CPU メモリ余剰直結の 3 件)・[[GPUクラスタ運用]](LLM 専用クラスタの GPU 二極化と補助資源余剰の同時成立・Evaluation 逆転の 2 件)・[[LLM学習モニタリング]](LLM 診断器の最初期本番事例の系譜追加)+ sources/_index・entities/_index・index.md・hot.md・log.md・manifest。 2026-06-15: **時系列推論 × 検証可能報酬 RL の論文 5 本バッチ取り込み(TimeReasoner / Time-R1 / TimeOmni-1 / Towards Time-Series Reasoning / AlphaCast)** — LLM の時系列タスク適用とその後訓練アルゴリズムを多角的に集約する 5 論文を同時 ingest。**(1) TimeReasoner**([[@2025__KDD__Can Slow-thinking LLMs Reason Over Time - Empirical Studies in Time Series Forecasting]]、WSDM 2026、[[Mingyue Cheng]] ら [[University of Science and Technology of China]]): 訓練不要 [[DeepSeek-R1]] のスロー思考を時系列予測に転用し、ETTh1 MSE 5.4 で iTransformer(7.5)を上回る。タイムスタンプ削除で MSE 5.4→25.3 の劣化、CoT 過長で精度低下、温度 τ=0.6 がスイートスポットという反直感的知見を提示。**(2) Time-R1**([[@2025__NeurIPS__Time-R1 - Post-Training Large Vision Language Model for Temporal Video Grounding]]、NeurIPS 2025、[[Renmin University of China]] AIM3 Lab × [[MiLM Plus]]([[Xiaomi]])、[[Qin Jin]] 対応): 映像言語モデル(LVLM)の時間的映像グラウンディング(TVG)タスクに RLVR(GRPO + tIoU 報酬)を初適用。**2.5K サンプル RL が 339K サンプル(136 倍)の SFT-LoRA を超え**、TVGBench で [email protected]=41.8 を達成し Gemini-2.5-Pro(39.1)を上回る。SFT の「偽陰性過剰ペナルティ」問題を RL が解消する構造を明示。**(3) TimeOmni-1**([[@2026__ICLR2026__TimeOmni-1 - Incentivizing Complex Reasoning with Time Series in Large Language Models]]、ICLR 2026、[[Tong Guan]] ら [[Griffith University]] / [[Zhejiang University]] / [[NVIDIA]] / [[Squirrel Ai Learning]] / [[University of Palermo]]): TSR-Suite(4 アトミックタスク・23K サンプル)と SFT + GRPO の二段階訓練で因果発見精度 GPT-4.1 を ID 40.6%・OOD 28.1% 上回る。ジョイント訓練で意思決定 40.9%→47.9% の能力補完を実証し「train-once use-across-tasks」を提示。**(4) Towards Time-Series Reasoning with LLMs**([[@2024__arXiv__Towards Time-Series Reasoning with LLMs]]、NeurIPS 2024 Workshop、[[Winnie Chow]] ら [[Stanford University]] / [[Apple]] / [[University of Illinois Urbana-Champaign]]): 時系列推論を「知覚→文脈化→演繹」の 3 段階に分解し、テキスト変換による知覚ボトルネックを定式化。**軽量パッチエンコーダ(MLP)+ LoRA で 7B(Mistral-7B)が GPT-4o を超える**ゼロショット時系列分類を達成。**(5) AlphaCast**([[@2025__arXiv__AlphaCast - A Human Wisdom-LLM Intelligence Co-Reasoning Framework for Interactive Time Series Forecasting]]、arXiv 2025-11、[[Xiaohan Zhang]]・[[Tian Gao]]・[[Mingyue Cheng]] ら USTC): 訓練不要 LLM(GPT-5・DeepSeek-R1)を Investigator(文脈準備)→ Generator(推論生成)→ Reflector(反省的検証)のマルチターンエージェントループで駆動。反省モジュール除去で Sunny Power が非推論ベースラインより悪化し「推論は両刃、反省が物理整合性の保護に不可欠」を実証。**新規 concept**: [[時系列推論]](この 5 論文が共同で具体化する LLM ベース時系列推論パラダイム)・[[検証可能報酬による強化学習]](Time-R1 と TimeOmni-1 が時系列・映像へ拡張した RLVR/GRPO)・[[時間的映像グラウンディング]](Time-R1 固有の TVG タスク類型)。**横断的知見**: USTC グループは TimeReasoner(訓練不要推論時)→ AlphaCast(訓練不要 Workflow)→ Cast-R1(AgenticRL)の三世代を同一グループ内で揃え、ATSF の 3 パラダイムを系列的に積み上げた稀少な拠点。Time-R1 と TimeOmni-1 はともに DeepSeek-R1 の GRPO + 規則ベース報酬の枠組みを継承し、コールドスタート CoT + RL の二段階訓練でドメインを問わず機能する。**ページ作成**: source 5 + 新規 entity 16(Jiahao Wang・Daoyu Wang・Tong Guan・Qin Jin・MiLM Plus・Xiaomi・Xiaohan Zhang・Tian Gao・Winnie Chow・Lauren Gardiner・Haraldur T. Hallgrimsson・Maxwell A. Xu・Shirley You Ren・Apple・Ming Jin・Shirui Pan ほか agent が判断した範囲) + 新規 concept 3([[時系列推論]]・[[検証可能報酬による強化学習]]・[[時間的映像グラウンディング]])。**ページ更新**: [[Mingyue Cheng]]・[[Xiaoyu Tao]]・[[Qi Liu]]・[[Enhong Chen]]・[[University of Science and Technology of China]]・[[DeepSeek-R1]]・[[Renmin University of China]]・[[NVIDIA]]・[[OpenAI]]・[[Stanford University]](lint-stub 解消) + [[エージェント型時系列予測]]・[[文脈内学習]]・[[強化ファインチューニング]]・[[ビジョン言語モデル]]・[[時系列基盤モデル]]・[[時系列質問応答]]・[[エージェント型強化学習]] + sources/_index・entities/_index・concepts/_index・index.md・hot.md・log.md・manifest。 2026-06-15: **Malesevic・Heiser 2026(Google Cloud Blog)— AI in SRE: Where and how Google is deploying agentic AI to improve operations を wiki-ingest で取り込み** — [[@2026__Google Cloud Blog__AI in SRE - Where Google is Deploying Agentic AI to Improve Operations]]([[Google]] の Stevan Malesevic [Distinguished Software Engineer] と Christopher Heiser [Distinguished SRE]、Google Cloud Blog、2026-05-29、URL: `cloud.google.com/blog/products/devops-sre/how-google-sre-is-using-agentic-ai-to-improve-operations`): 既存 whitepaper([[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]])の対外公開・要約版で、**SRE AI のスコープを SDLC 全体に広げる地図**を提示する——(1) reliability design(プレイブックの利用実態に基づく継続改善 + インシデントからの新規生成)、(2) anomaly detection & alerting([[TimesFM]] 等の時系列基盤モデル + autonomous AI alert handlers)、(3) incident management(IMAG への agentic orchestration layer = コミュニケーション監視 / SRE 間ハンドオフ / ポストモーテム下書き / 内外通信の 4 種エージェント)、(4) incident investigation(observability + topology/taxonomy で domain & intent 確立 → 仮説形成 → 緩和)、(5) insights & risk management([[AI Insights]] が Gemini embedding + vector DB で過去インシデントを連続知識化 + risk category 注釈)。エージェント設計の **9 原則**(既存自動化温存・既存ポリシー遵守・セキュリティ&プライバシー・**強い identity**・SLO/バックアップ・**説明可能性と透明性(black-box automation より優先)**・BCP・本番データ継続アクセス・継続評価&監査)を列挙し、本番スタックを **Gemini(社内ファインチューン版含む)+ [[Gemini Enterprise Agent Platform]](本ブログで**旧 Vertex AI のリブランドが一次確認**)+ [[Agent Development Kit]](ADK)+ MCP servers + BigQuery + vector DB** と公開製品名で明示。これは whitepaper が社内コードネーム([[Detectr]]/[[AI Operator]]/[[Actus]])で語っていた同じシステムを、外部開発者が真似て構築できる公開製品スタックの形で示し直す位置にある。**ページ作成**: source 1 + entity 3([[AI Insights]] / [[Agent Development Kit]] / [[Gemini Enterprise Agent Platform]])。**ページ更新**: [[Google]](AI Insights/ADK/Gemini Enterprise Agent Platform/TimesFM 追記、Vertex AI リブランド事実)・[[TimesFM]](Google SRE AI 異常検知への組み込み追記)・[[agentic SRE]](SDLC 全体スコープと公開製品スタック 2 件の横断的知見追加)・[[SRE AI Autonomy Levels]](本ソース追加)・[[インシデント管理]](IMAG agentic orchestration layer の 4 エージェントと ICS 写像 + プレイブック agentic loop の横断的知見)・[[アラート管理]](静的閾値脱却 + autonomous handler の 3 段アーキテクチャを横断的知見へ)・[[異常検知]](顧客指向 SLO 予測の 4 点構成を横断的知見へ)+ index.md・hot.md・log.md・manifest。 2026-06-15: **Chen・Zhang・He・Lin ほか 2020(ASE)— How Incidental are the Incidents? Characterizing and Prioritizing Incidents for Large-Scale Online Service Systems を wiki-ingest-paper で取り込み** — [[@2020__ASE__How Incidental are the Incidents - Characterizing and Prioritizing Incidents for Large-Scale Online Service Systems]]([[Junjie Chen]]([[Tianjin University]] / [[Microsoft]] 訪問)・[[Shu Zhang]]・[[Xiaoting He]]・[[Qingwei Lin]](対応)・[[Hongyu Zhang]]([[University of Newcastle]])・[[Dan Hao]]([[Peking University]])・[[Yu Kang]]・[[Feng Gao]]・[[Zhangwei Xu]]・[[Yingnong Dang]]・[[Dongmei Zhang]]、ASE 2020、DOI:10.1145/3324884.3416624、12p): Microsoft の 18 大規模オンラインサービスシステムの 6 か月分インシデントを分析し、incidental incidents が平均 50.32% (11.92〜71.43%)・TTR の 55.05% を消費するという「半数以上が無視してよい」構造を初めて定量化。incidental の 6 カテゴリ(by design / customer error / won't fix / unable to reproduce / transient / false alarm)を導出し、severity 0 でも incidental が 57.96% を占める逆転を Table 1 で実証。[[DeepIP]](attention 付き CNN + 関連 incident 取り込み)は AUC 平均 0.808 を達成し bug-severity 流用ベースライン Rule(0.624)/Bayes(0.586)を 18 全システムで上回り、Mozilla データセット転用でも SOTA を P+41.00%・R+10.29% で改善。**ページ作成**: source 1 + entity 9([[Junjie Chen]]・[[Shu Zhang]]・[[Xiaoting He]]・[[Dan Hao]]・[[Feng Gao]]・[[Zhangwei Xu]]・[[Yingnong Dang]]・[[University of Newcastle]]・[[DeepIP]]) + concept 1([[インシデント優先順位付け]])。**ページ更新**: [[Qingwei Lin]]・[[Hongyu Zhang]]・[[Dongmei Zhang]]・[[Yu Kang]]・[[Tianjin University]]・[[Microsoft]]・[[Microsoft Azure]]・[[Peking University]]・[[インシデント管理]]・[[アラート管理]]・[[インシデントTTM予測]] + sources/_index・entities/_index・concepts/_index・index.md・hot.md・log.md・manifest。 2026-06-14: **Li・Yu ほか 2022(ISSRE)— Going through the Life Cycle of Faults in Clouds: Guidelines on Fault Handling を wiki-ingest-paper で取り込み** — [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]]([[Xiaoyun Li]]・[[Guangba Yu]]・[[Hongyang Chen]]・[[Zhekang Chen]]・[[Pengfei Chen]] ほか、[[Sun Yat-sen University]]/[[Bizseer]]、ISSRE 2022、IEEE、DOI:10.1109/ISSRE55969.2022.00029): Alibaba・Tencent・Baidu の 354 件ポストモーテムを手動分析して障害ライフサイクル(TTD→TTI→TTM→TTR)を定量化した実証研究。MTTD=16.9 分・MTTM=304.2 分(TTR の 53%)、誤設定(misconfiguration)31.6% が根本原因最多、緩和手段 9 種のうちリプレースメント最多(32%)・ロールバック最速(中央値 91 分)・フィックス最遅(中央値 220 分)、ポストモーテム分析からカオスエンジニアリングに欠けている 4 注入カテゴリ(設定変更・コードスニペット・過剰リクエストモック・リクエストレベル)を特定。**ページ作成**: source 1([[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]]) + entity 3([[Xiaoyun Li]]・[[Hongyang Chen]]・[[Zhekang Chen]]) + concept 1([[クラウド障害ライフサイクル]])。**ページ更新**: [[Guangba Yu]]・[[Pengfei Chen]]・[[Sun Yat-sen University]]・[[Bizseer]]・[[運用障害分析]]・[[インシデント管理]]・[[根本原因分析]]・[[障害緩和]]・[[障害注入]]・[[オブザーバビリティ]] + sources/_index・entities/_index・concepts/_index・index.md・hot.md・log.md・manifest。 2026-06-14: **Bento・Correia・Filipe・Araujo・Cardoso 2021(J Grid Computing)— Automated Analysis of Distributed Tracing: Challenges and Research Directions を wiki-ingest-paper で取り込み** — [[@2021__J Grid Computing__Automated Analysis of Distributed Tracing - Challenges and Research Directions]]([[Andre Bento]]・[[Jaime Correia]]・[[Ricardo Filipe]]・[[Filipe Araujo]]・[[Jorge Cardoso]]、[[University of Coimbra]] CISUC / [[Huawei Munich Research Center]]、Journal of Grid Computing Vol.19 Article 9、2021、DOI:10.1007/s10723-021-09551-5、15p): OpenTracing 準拠データから [[OpenTracing Processor]](OTP)で service metrics(in/out 呼数・平均応答時間)・dependency graph・work-flow を抽出し、Isolation Forest で異常時間枠/サービスを検知するパイプライン。Huawei Cloud OpenStack 本番トレース 2 日分(190K–240K spans/日、64K–74K traces/日)で実証し、検知自体は成功する一方、ゲートウェイ計装の欠落(endpoint 未記録)で work-flow 深掘りが頓挫し、「精緻なアルゴリズムよりトレース品質改善が先」と診断したことが本論文の中心結論。トレース品質を data sufficiency / ontological / tools の 3 類型で体系化し(Fig. 9)、temporal coverage(子スパン合計時間/親スパン時間)を品質定量指標として導入。OpenTracing 仕様の (a) タイムスタンプ単位非明示(ms と μs が同データセット内混在)、(b) annotation 任意 key-value、(c) testability 欠如、(d) dependency graph/span tree 生成・分析ツール欠如、を体系化し、後継 [[OpenTelemetry]] を「merge 努力が主で testability driver の再設計が薄い」と批判する。**ページ作成**: source 1 + entity 6([[Andre Bento]]・[[Jaime Correia]]・[[Ricardo Filipe]]・[[Filipe Araujo]]・[[OpenTracing]]・[[OpenTracing Processor]]) + concept 1([[トレース品質]])。**ページ更新**: [[分散トレーシング]](量制御の手前に品質天井診断・OpenTracing 仕様の自動分析阻害・LLM 前のトレース異常検知 3 段階進化を横断的知見に追加・未解決の問い 2 項・出典追加)・[[異常検知]](派生メトリクス時系列への古典外れ値検知系譜を横断的知見に追加・関連/出典追加)・[[オブザーバビリティ]](シグナル内品質の早期指摘を横断的知見と未解決の問いに追加・関連/出典追加)・[[Jorge Cardoso]]・[[University of Coimbra]]・[[Huawei Munich Research Center]](Bento+ 2021 への参画追記)+ sources/_index・entities/_index・concepts/_index・index.md・hot.md・log.md・manifest。 2026-06-14: **Yu ほか 2023(WWW)— CMDiagnostor: An Ambiguity-Aware Root Cause Localization Approach Based on Call Metric Data を wiki-ingest-paper で取り込み** — [[@2023__WWW__CMDiagnostor - An Ambiguity-Aware Root Cause Localization Approach Based on Call Metric Data]]([[Qingyang Yu]]・Zeyan Li・[[Bowen Hao]]・[[Mingjie Li]]・[[Xianglin Lu]]・[[Changhua Pei]]・[[Shenglin Zhang]]・[[Dan Pei]]・[[Tencent]] 著者複数、[[Tsinghua University]]/CNIC/CAS/[[Nankai University]]/[[Tencent]]、DOI:10.1145/3543507.3583302): コールメトリクスデータ(CMD)から構築するコールグラフに内在する**曖昧性(AmSit)**——ノードに上流コール ≥2 + 下流コール ≥1 が存在すると CMD の集約でトレースレベルの対応が失われる状況——を論文として初めて定式化。回帰ベース解消アルゴリズム **AmSitor**(大数の法則 + マルコフ性 → 上流トラフィック系列の非負線形回帰で下流トラフィックを分離、精度 89.51%)と4段階フレームワーク **CMDiagnostor**(Metric Anomaly Detection → Ambiguity-free Call Graph Construction → Root Cause Exploration → Candidate Root Cause Ranking)を提案。剪定はASP(AmSit)/MSP(Pearson ≥0.7)/ADP(検知済みメトリクス)の 3 種、ランキングキーは RCNC(候補ノード数)→ AER(平均エラー率)→ MMS(最大メトリクス類似度)の優先順。実世界大規模データ D_RF(65 件・8K+ マイクロサービス)で HR@5=0.94・MRR=0.83、最強ベースライン MicroHECL を 14% 上回る。**横断的知見**: AmSit 定式化は「入力表現の精度が RCA 性能の上限を決める」という原理の明証—— CMD の 2,500× 圧縮が AmSit を産み、AmSitor がそのコストを回収する。**ページ作成**: source 1([[@2023__WWW__CMDiagnostor - An Ambiguity-Aware Root Cause Localization Approach Based on Call Metric Data]]) + entity 3([[Bowen Hao]]・[[Mingjie Li]]・[[Xianglin Lu]])。**ページ更新**: [[Zeyan Li]](disambiguation) / [[Qingyang Yu]]・[[Changhua Pei]]・[[Shenglin Zhang]]・[[Dan Pei]]・[[Nankai University]]・[[Tencent]](source・related 追加) / [[Fault Localization]](AmSit の横断的知見・RCNC ランキングキーの未解決問い追加) / [[根本原因分析]](入力精度律速の横断的知見追加) + sources/_index・entities/_index・concepts/_index・index.md・hot.md・log.md・manifest。 2026-06-14: **Heimerdinger・Weinstock 1992(CMU/SEI)— A Conceptual Framework for System Fault Tolerance を wiki-ingest-paper で取り込み** — [[@1992__CMU SEI__A Conceptual Framework for System Fault Tolerance]]([[Walter Heimerdinger]]([[Honeywell]])・[[Charles Weinstock]]([[Software Engineering Institute]])、SEI Technical Report CMU/SEI-92-TR-033、1992-10、44p、URL: https://www.sei.cmu.edu/library/a-conceptual-framework-for-system-fault-tolerance/): フォールトトレランス実践を実務者コミュニティに移転するための概念的フレームワーク提案。fault/failure/symptom の定義(失敗=仕様からのサービス逸脱、障害=構成要素/相互作用システムの失敗——「一人の障害は別の人の失敗」)、ディペンダビリティ達成の4手段(障害回避・障害除去・フォールトトレランス・**障害回避的措置 fault evasion**)、障害クラス分類(所在・影響・持続時間・直接原因・究極原因の5軸)、冗長性管理の6アクション(検知・診断・封じ込め・マスキング・補償・修復)、空間冗長と時間冗長、障害封じ込め領域(FCR)、コモンモード障害、受け入れテストと比較の2検知手法、設計多様性(コモンモード設計障害への唯一の対策)、カバレッジ(マルコフモデルで定量化)、6設計規則を体系化。**横断的知見**: fault evasion(仕様違反前の予防的再構成)は 1992 年に命名された AIOps プロアクティブカテゴリの原型——30 年後に再実装された概念的連続性。Heimerdinger+Weinstock は error を fault に吸収したが Avizienis 2004 は fault→error→failure 3 段連鎖を復元し Salfner+ 2010 がさらに symptom を加えた——用語の揺れと再収束の歴史。**ページ作成**: source 1([[@1992__CMU SEI__A Conceptual Framework for System Fault Tolerance]]) + entity 4([[Walter Heimerdinger]]・[[Charles Weinstock]]・[[Honeywell]]・[[Software Engineering Institute]]) + concept 1([[フォールトトレランス]])。**ページ更新**: [[ソフトウェア耐障害性]](3 段階 FT レベル体系と用語進化の横断的知見追加・source 追加)・[[ディペンダビリティ]](fault evasion と Avizienis 4 手段の対応を横断的知見追加・source/出典追加)+ sources/_index・entities/_index・concepts/_index・index.md・hot.md・log.md・manifest。 2026-06-14: **Salfner・Lenk・Malek 2010(ACM CSUR)— A Survey of Online Failure Prediction Methods を wiki-ingest-paper で取り込み** — [[@2010__ACM CSUR__A Survey of Online Failure Prediction Methods]]([[Felix Salfner]]・[[Maren Lenk]]・[[Miroslaw Malek]]、[[Humboldt University of Berlin]]、ACM Computing Surveys Vol.42 No.3 Article 10、2010-03、42p、DOI:10.1145/1670679.1670680): オンライン障害予測の古典サーベイ。約 50 のアプローチを入力データ系統で 4 主要枝(failure tracking / symptom monitoring / detected error reporting / undetected error auditing)・26 サブカテゴリの taxonomy にまとめ、Avižienis 2004 の fault → error → failure に symptom と undetected/detected 区別を加えた 5 段階モデルを提示。時間軸を `t_d`(data window)・`t_l`(lead time)・`t_p`(prediction period)・`t_w`(minimal warning time)の 4 パラメータで定式化し、`t_l ≧ t_w` を予測存在条件、`t_p → ∞` で recall = 1 が trivially 達成される問題を §3.1 末尾で警告。proactive fault management の 4 段階(予測 → 診断 → アクションスケジューリング → 実行)を Figure 2 で整理し、本論文はそのうち予測のみを扱う。Notaro+ 2021・LLM4Log 等後続サーベイの語彙的・概念的源流。**ページ作成**: source 1 + entity 4([[Felix Salfner]]・[[Maren Lenk]]・[[Miroslaw Malek]]・[[Humboldt University of Berlin]]) + concept 2([[プロアクティブ障害管理]]・[[ソフトウェアエイジング]])。**ページ更新**: [[障害予測]](Salfner+ 2010 を「pre-AIOps の元祖 taxonomy」「時間軸 4 パラメータの起点」「予測精度だけでは可用性は伸びず後段の対策自動化が本丸」の 4 項目で横断的知見へ追加・未解決の問い 3 項追加)・[[ディペンダビリティ]](5 段階連鎖モデルと可視化技法対応を横断的知見へ追加)・[[AIOps]](pre-AIOps 期から taxonomy 確立を横断的知見へ追加)+ sources/_index・entities/_index・concepts/_index・index.md・hot.md・log.md・manifest。 2026-06-14: **O'Connor・Kleyner 2012(Wiley)— Practical Reliability Engineering 第 5 版を wiki-ingest で取り込み** — [[@2012__Wiley__Practical Reliability Engineering]]([[Patrick D. T. O'Connor]]・[[Andre Kleyner]]、[[Wiley]]、2012、DOI:10.5555/2207822、ローカル PDF 504p): 信頼性を「時間依存の品質」として定義し、確率・寿命データ解析・信頼性予測・荷重-強度干渉・[[Design for Reliability]]・ソフトウェア信頼性・信頼性試験・[[FRACAS]]・保守性/可用性・信頼性管理を統合する実務教科書。主要な取り込み点は、(1) 数学的予測は設計比較やコスト見積もりに有用だが、故障モード・物理メカニズム・設計/製造/保守の工学判断が優先される、(2) DfR は test-analyze-and-fix 依存を避け、信頼性技術者を設計初期からメンターとして統合する、(3) FRACAS は故障報告→解析→是正処置→再試験の閉ループで SRE のインシデント管理/ポストモーテムと同型、の 3 点。**ページ作成**: source 1 + entity 3([[Patrick D. T. O'Connor]]・[[Andre Kleyner]]・[[Wiley]]) + concept 2([[Design for Reliability]]・[[FRACAS]])。**ページ更新**: [[ディペンダビリティ]]・[[SRE]]・[[ソフトウェア耐障害性]] + sources/_index・entities/_index・concepts/_index・index.md・hot.md・log.md・manifest。 2026-06-14: **Wang・Chen・Yang・Hongyu Zhang ほか 2021(IEEE ISSRE)— How Long Will it Take to Mitigate this Incident for Online Service Systems? を wiki-ingest-paper で取り込み** — [[@2021__ISSRE__How Long Will it Take to Mitigate this Incident for Online Service Systems]]([[Weijing Wang]]・Junjie Chen・Lin Yang([[Tianjin University]])・[[Hongyu Zhang]]([[University of Newcastle]])・Pu Zhao・Bo Qiao・[[Yu Kang]]・[[Qingwei Lin]]([[Microsoft]])・[[Saravan Rajmohan]]([[Microsoft]])・Feng Gao・Zhangwei Xu・Yingnong Dang([[Microsoft]])・[[Dongmei Zhang]]([[Microsoft]])、IEEE ISSRE 2021、DOI:10.1109/ISSRE52982.2021.00024、11p): Microsoft 20 大規模オンラインサービスシステムの 4 年分(2017-2020)インシデントデータを対象に、緩和時間(TTM)を T1(報告→初期トリアージ)・T2(再アサイン)・T3(最終担当チーム確定→緩和)の 3 区間に分解した初の実証研究。T3 が平均 70.20%(61〜78%)を占め、T1(15.42%)・T2(14.38%)を大幅に上回ることを初めて定量化した——担当チームが決まった後も緩和に大半の時間が費やされる。影響因子として重篤度・報告ソース(モニタ<エンジニア<顧客)・トリアージ回数・担当チームを特定。TTMPred は(1)FastText+双方向 GRU+アテンションの Sentence Encoder・(2)句ベクトル列 + 双方向 GRU + 時点別アテンションの Discussion Encoder・(3)離散特徴量埋め込みを連結し MLP で予測。連続損失関数(全時点損失の平均を最適化)により報告直後の精度を 24.61% 改善。回帰で SVR 比 29.95%・RFR 比 16.34%・XGB 比 13.81%(MAE)、分類で DeepLSTMPred 比 19.09%〜153.34%(F 値)を改善。**ページ作成**: source 1([[@2021__ISSRE__How Long Will it Take to Mitigate this Incident for Online Service Systems]]) + entity 2([[Weijing Wang]]・[[Tianjin University]]) + concept 1([[インシデントTTM予測]])。**ページ更新**: [[Hongyu Zhang]](Newcastle affiliation 追記)・[[Qingwei Lin]]・[[Yu Kang]]・[[Saravan Rajmohan]]・[[Dongmei Zhang]]・[[インシデント管理]](T3 支配性と顧客報告インシデントの横断的知見 2 項・未解決の問い 1 項・出典追加)+ sources/_index・entities/_index・concepts/_index・index.md・hot.md・log.md・manifest。 2026-06-14: **John・Liu 2017(arXiv)— A Survey of Distributed Message Broker Queues を wiki-ingest-paper で取り込み** — [[@2017__arXiv__A Survey of Distributed Message Broker Queues]]([[Vineet John]]・[[Xia Liu]]([[University of Waterloo]])、arXiv:1704.00411v1 [cs.DC] 2017-04-03、8p): [[Apache Kafka]]([[LinkedIn]] のログ処理用途由来)と [[AMQP]]/[[RabbitMQ]](金融取引用途由来)を 5 ノード共通テストベッド(12 コア・16GB・1Gbps HDD)・Flotilla ベンチで直接対比した経験的サーベイ。Kafka のスループット優位は (1) SendFile API でカーネルバッファバイパス・(2) シーケンシャルディスク書き込み + OS ページキャッシュ依存・(3) 標準バッチング、AMQP のレイテンシ優位は (1) push モデル(Kafka は pull)・(2) 既定でメッセージ非永続化(Kafka は永続化)、に集約。Kafka single P/C スケールアウトでレイテンシ 3 倍改善・スループット 1.06 倍低下、multi P/C 同一ノード集中ではレイテンシ 100 倍悪化・consumer スループット 29 倍低下(Zookeeper 競合)。応用領域(損失許容のログ集約 vs 損失非許容の金融取引)が選択基準。**ページ作成**: source 1 + entity 6([[Vineet John]]・[[Xia Liu]]・[[University of Waterloo]]・[[Apache Kafka]]・[[AMQP]]・[[RabbitMQ]]) + concept 1([[分散メッセージブローカ]])。**ページ更新**: sources/_index・entities/_index・concepts/_index・index.md・hot.md・log.md・manifest。 2026-06-14: **Gilly・Juiz・Puigjaner 2011(World Wide Web)— An up-to-date survey in web load balancing を wiki-ingest-paper で取り込み** — [[@2011__World Wide Web__An up-to-date survey in web load balancing]]([[Katja Gilly]]([[Miguel Hernández University]])・[[Carlos Juiz]]・[[Ramon Puigjaner]]([[University of Balearic Islands]])、World Wide Web Vol.14 No.1-2 pp.105–131、2011、DOI:10.1007/s11280-010-0101-5、27p): 2010 年時点のウェブロードバランシング手法を OSI 層（L2/L3/L7）・応答返路（双方向/一方向）・コンテンツ把握（content-blind/content-aware）の 3 軸で分類・調査したサーベイ。ディスパッチャーベースのクラスタ型 Web システムに焦点を絞り、TCP 接続マイグレーション（TCP Hand-off・Splicing・Socket Cloning・One-way Connection Binding・TCP Rebuilding）・分散方針分類（地域性考慮型／非地域性考慮型／QoS 考慮型）・将来課題（動的コンテンツ予測・エネルギー効率）を体系化。**ページ作成**: source 1 + entity 5([[Katja Gilly]]・[[Carlos Juiz]]・[[Ramon Puigjaner]]・[[Miguel Hernández University]]・[[University of Balearic Islands]]) + concept 1([[Webロードバランシング]])。**ページ更新**: sources/_index・entities/_index・concepts/_index・index.md・hot.md・log.md・manifest。 2026-06-14: **CNCF WG Serverless 2018 — Serverless Overview Whitepaper v1.0 を wiki-ingest で取り込み** — [[@2018__CNCF WG Serverless__Serverless Overview Whitepaper v1.0]]（[[CNCF]] WG Serverless、2018-10-24、GitHub: cncf/wg-serverless/whitepapers/serverless-overview）: サーバーレスコンピューティングの概念定義・ユースケース・Function 仕様・エコシステム勧告を体系化した CNCF 公式白書(v1.0)。FaaS+BaaS の 2 要素に「ゼロサーバーオプス」と「アイドル時課金なし」の 2 大メリット。CaaS(Kubernetes 等)/PaaS(Cloud Foundry 等)/Serverless の 3 択比較では制御粒度・インフラ管理責任・課金粒度(リソース確保時間 vs ms 単位実行時間)が決め手軸。Function Lifecycle ではデプロイパイプライン・バージョニング・エイリアス・n:m イベントソース関連付けを定義。Function Workflow の 5 構成パターン(単純トリガー・複合条件・ファンアウト・連鎖・インターリーブ)と 6 状態(Event/Operation/Switch/Pass/Delay/End)を規定し AWS Step Functions を代表例として例示。コールドスタート・デバッグ困難・標準化不足を 2018 年時点の課題として明示。CNCF 勧告 7 点の中心は相互運用性 API(CloudEvents への伏線)。**横断的知見として確認**: CNCF 公式(外部・運用視点)と Yuuki Tsubouchi(内部・アーキテクチャ視点)は相補的で矛盾しない。「サーバーレス」用語起源(2012 IronWorker)と FaaS 実用化(2014 AWS Lambda)に 2 年のギャップ——概念先行・技術後追いのパターン。Function Workflow の n:m マッピングが LLM エージェントのツール呼び出し連鎖との対応を問う未解決問いへ接続。**ページ作成**: source 1([[@2018__CNCF WG Serverless__Serverless Overview Whitepaper v1.0]])・concept 1([[サーバーレスワークフロー]])。**ページ更新**: [[CNCF]](サーバーレス領域節追加)・[[サーバーレスアーキテクチャ]](CNCF 定義 citation 化・横断的知見 3 項・未解決の問い 1 項追加・status→developing)+ sources/_index・concepts/_index・index.md・hot.md・log.md・manifest。 2026-06-14: **Pahl・Brogi・Soldani・Jamshidi 2019(IEEE TCC)— Cloud Container Technologies: A State-of-the-Art Review を wiki-ingest-paper で取り込み** — [[@2019__TCC__Cloud Container Technologies - A State-of-the-Art Review]]([[Claus Pahl]]([[Free University of Bozen-Bolzano]])・[[Antonio Brogi]]・[[Jacopo Soldani]]([[University of Pisa]])・[[Pooyan Jamshidi]]([[Carnegie Mellon University]])、IEEE Transactions on Cloud Computing Vol.7 No.3 pp.677-692、2019(オンライン 2017-05-09)、DOI:10.1109/TCC.2017.2702586、16p): 2007-2016 のクラウドコンテナとオーケストレーション研究を 46 件 primary studies で体系的にマッピング(SMS)した初の secondary study。PICO 構造による検索式 `(cloud OR PaaS) AND (container) AND (orchestrate OR (cluster OR manage))` から IEEE Xplore・ACM Digital Library・Science Direct ほか 8 データベースで抽出。Technology Stack(Virtualisation Basics・Container Construction・Container Management・Cluster Construction・Cluster Management)・Management Services(Architecture/Construction・Execution Management・Quality/SLA Management の monitorable/non-monitorable/testable 3 分割)・Architecture Setting(Deployment Stage・Architecture Concern・Cloud Setting)・Tools/Platforms/Technology の 4 軸分類フレームワークを RQ1-RQ4 と整合して構築。[[Docker]] と [[LXC]] が支配的、[[Kubernetes]]・CoreOS・OpenVZ・Diego・Rocket が次点。Solution proposal 中心の formative stage(検証研究・評価研究が少ない)、IaaS と PaaS がほぼ均等な分布、デプロイ容易性が動機の主、品質関心は performance(23)/resource utilisation(13)/startup time(10)/elasticity(10)に集中。SLA Parameter(36) と Infrastructure Parameter(33) がほぼ均衡し consumer/provider のステークホルダ二極化を示す。Borg([S21] Verma+ EuroSys 2015)の限界として障害管理(failure management)を未開拓と明示し、根本原因特定と異常イベント対応のためにリソース監視・ログ解析の改善を将来課題に挙げる。クラスタ研究は 2015 年中盤以降に立ち上がる第 2 波、エッジ/フォグへの拡張とサーバーレス・unikernel への軽量化トレンドを §6 で観察。**ページ作成**: source 1 + entity 6([[Claus Pahl]]・[[Pooyan Jamshidi]]・[[Free University of Bozen-Bolzano]]・[[University of Pisa]]・[[Docker]]・[[LXC]]) + concept 2([[コンテナオーケストレーション]]・[[体系的マッピング研究]])。**ページ更新**: [[Antonio Brogi]]・[[Jacopo Soldani]]・[[Carnegie Mellon University]]・[[マイクロサービスアーキテクチャ]](2016 年時点 microservice architecture が architecture concern として登場)・[[コンテナ配置最適化]](品質関心二極化の前史)・[[サーバーレスアーキテクチャ]](§6 軽量化トレンド観察)+ sources/_index・entities/_index・concepts/_index・index.md・hot.md・log.md・manifest。 2026-06-14: **Yu ほか 2024(JNCA)— A survey on intelligent management of alerts and incidents in IT services を wiki-ingest-paper で取り込み** — [[@2024__JNCA__A survey on intelligent management of alerts and incidents in IT services]]([[Qingyang Yu]]・[[Nengwen Zhao]]・Mingjie Li・Zeyan Li・Honglin Wang・Wenchi Zhang・Kaixin Sui・[[Dan Pei]]、[[Tsinghua University]] / [[BizSeer]]、JNCA Vol.224 Article 103842、2024-02、24p、DOI:10.1016/j.jnca.2024.103842): alert management(correlation・storm handling・determination)と incident management(representation・linking・triage・mitigation・resolution)を統合した AIM アーキテクチャ Fig.5 を提示し、2008-2022 の代表 89 件を IBM/Microsoft/Others のデータソース別に分類する初の包括サーベイ。alert と incident を別ライフサイクル(event ⊃ alert、severe alert + user complaint → incident)として分離する設計、3 種 alert determination(distinguishing / severe ranking / alert-based incident identification)の直列統合(Fig.7)、industrial alarm flood(EEMUA 191 の 10/10 分/operator)と桁違いの service alert storm を独立対象として扱う立場を提示。**ページ作成**: source 1 + entity 1([[Qingyang Yu]]) + concept 1([[アラート管理]])。**ページ更新**: [[インシデント管理]](alert/incident 分離設計の対比軸・8 プロセス分類が LLM 時代の境界研究という観察を横断的知見に追加)・[[Dan Pei]]・[[Nengwen Zhao]]・[[BizSeer]] + sources/_index・entities/_index・concepts/_index・index.md・hot.md・log.md・manifest。 2026-06-14: **Shen・Dan Pei・Feifei Li ほか 2023（PVLDB）— Lindorm TSDB: A Cloud-native Time-series Database for Large-scale Monitoring Systems を wiki-ingest-paper で取り込み** — [[@2023__PVLDB__Lindorm TSDB - A Cloud-native Time-series Database for Large-scale Monitoring Systems]]（[[Chunhui Shen]]・[[Dan Pei]]・[[Feifei Li]] ほか、[[Alibaba Group]]/[[Zhejiang University]]/[[Tsinghua University]]、PVLDB Vol.16 No.12 pp.3715–3727、2023、DOI:10.14778/3611540.3611559）: 大規模監視システム向けクラウドネイティブ分散 TSDB [[Lindorm TSDB]] の設計・実装・評価。高次元問題（C1）・大量時系列クエリの高レイテンシ（C2）・ML 統合欠如（C3）・非効率なノードスケーリング（C4）の 4 課題を同時解決。「時刻軸シャードグループ切り替えでデータ移動ゼロのスケールアウト」+「Seriescache（MD5 エンコード版フォワードインデックスキャッシュ）」+「前処理ダウンサンプリング（書き込み時集計キャッシュ、クエリレイテンシ −80%・ストレージ +8%）」+「パイプライン実行エンジン + プッシュダウン」+「Lindorm ML（TrainingOp/InferenceOp をパイプライン演算子として SQL から直接実行）」の 5 本柱。TSBS 評価で 10M 時系列規模の書き込み 10×・クエリ最大 16× の性能優位。**ページ作成**: source 1 + entity 3（[[Lindorm TSDB]]・[[Feifei Li]]・[[Zhejiang University]]）。**ページ更新**: [[Dan Pei]]・[[Alibaba Group]]・[[時系列データベース]]（横断的知見 3 項・未解決の問い 3 項追加）+ sources/_index・entities/_index・index.md・hot.md・log.md・manifest。 2026-06-14: **Kobayashi ほか 2018（TNSM）— Mining Causality of Network Events in Log Data を wiki-ingest-paper で取り込み** — [[@2018__TNSM__Mining Causality of Network Events in Log Data]]（[[Satoru Kobayashi]]・[[Kazuki Otomo]]（[[University of Tokyo]]）・[[Kensuke Fukuda]]（[[National Institute of Informatics]] / SOKENDAI）・[[Hiroshi Esaki]]（[[University of Tokyo]]）、IEEE Transactions on Network and Service Management Vol. 15 No. 1 2018 pp.53–67、DOI:10.1109/TNSM.2017.2778096）: [[SINET4]]（日本全国研究教育ネットワーク）の 15 ヶ月・35M 件 syslog に PC アルゴリズム（stable-PC）+ G-square 条件付き独立性検定を適用し、ネットワーク障害の因果 DAG を抽出する。フーリエ+線形回帰の 2 段周期フィルタが 93% のメッセージを除去し、スパース二値データで G-square が Fisher-Z より大幅に低偽陽性・高速。後処理の頻出エッジ除去（上位 5%）でトラブルチケット 188 件の 74% に対応するエッジを 5.3 エッジ/日に絞り込む。**ページ作成**: source 1（[[@2018__TNSM__Mining Causality of Network Events in Log Data]]）+ entity 8（[[Satoru Kobayashi]]・[[Kazuki Otomo]]・[[Kensuke Fukuda]]・[[Hiroshi Esaki]]・[[University of Tokyo]]・[[National Institute of Informatics]]・[[SINET4]]・[[LogCausalAnalysis]]）。**ページ更新**: [[ログ解析]]（ネットワーク syslog 因果推論節 3 項・未解決の問い 3 項追加）・[[因果推論ベースRCA]]（横断的知見 2 項・未解決の問い 1 項追加）+ sources/_index・entities/_index・index.md・hot.md・log.md・manifest。 2026-06-14: **Notaro・Cardoso・Gerndt 2021(ACM TIST)— A Survey of AIOps Methods for Failure Management を wiki-ingest-paper で取り込み** — [[@2021__TIST__A Survey of AIOps Methods for Failure Management]]([[Paolo Notaro]]・[[Jorge Cardoso]]・[[Michael Gerndt]]、[[TU Munich]] / [[Huawei Munich Research Center]] / [[University of Coimbra]]、ACM TIST Vol.12 No.6 Art.81、2021-11、45p、DOI:10.1145/3483424): AIOps の Failure Management を proactive(prevention・online prediction)/reactive(detection・RCA・remediation)に二分し、5 カテゴリ・14 サブカテゴリで 1,086 件中 100 件を AI 手法 × データソース × 対象構成要素別に索引化。detection 33.7% / RCA 26.7% / online prediction 26.4% に対し prevention 10.6%・remediation 2.5% という極端な研究密度の偏りを定量化(2018 年以降はさらに縮退)。online failure prediction では lead/prediction/warning time(twarn<tlead)の評価枠を共通通貨として導入、fault localization は SFL(spectrum/Bayesian)/network(PCA・Sherlock)/general-purpose(Hotspot/Squeeze/FChain) の 3 系統で整理。マルチモーダル化・recovery 自動化・標準ベンチマークの不在を将来課題に挙げる。**ページ作成**: source 1([[@2021__TIST__A Survey of AIOps Methods for Failure Management]]) + entity 5([[Paolo Notaro]]・[[Jorge Cardoso]]・[[Michael Gerndt]]・[[University of Coimbra]]・[[Huawei Munich Research Center]])。**ページ更新**: [[AIOps]](pre-LLM 2 軸 taxonomy・マルチモーダル化が未解決課題で残り続けた観察・prevention/remediation の研究密度偏りを横断的知見と未解決の問いに追加)・[[障害予測]](online failure prediction の pre-LLM 系譜と評価軸を追加)・[[Fault Localization]](SFL/network/general-purpose の 3 系統整理を追加)+ sources/_index・entities/_index・index.md・hot.md・log.md・manifest。 2026-06-14: **Rao・Wang ほか 2011（IEEE）— Identifying Faults in Large-Scale Distributed Systems by Filtering Noisy Error Logs を wiki-ingest-paper で取り込み** — [[@2011__SRDS__Identifying Faults in Large-Scale Distributed Systems by Filtering Noisy Error Logs]]（[[Xiang Rao]]・[[Huaimin Wang]]・Dianxi Shi・Zhenbang Chen（[[National University of Defense Technology]]）・Hua Cai・Qi Zhou・Tingtao Sun（[[Alibaba Cloud]]）、IEEE 2011、IEEE Xplore 文書番号 5958800）: 大規模分散システムの障害注入テストにおいて、プロセスクラッシュを注入した際にランダムハードウェア障害・ソフトウェアバグ・設定誤り・ログ重大度誤設定の 4 種類のノイズ障害が共存し、Apriori/Decision Tree による障害特徴抽出を誤導する問題を定量化。既存手法 CFC(空間/時間圧縮)は time window 500 秒で再現率が 30% まで低下。SBF(Similarity-Based Filtering)は(1)ログを時系列モデル化 → (2)Haar ウェーブレット変換で近似 → (3)谷点分割で部分時系列化 → (4)DTW 類似度でノイズテンプレートと一致する部分を除去、の 4 ステップで Alibaba Cloud 100 ノードクラスタ・2,800,973 ログで適合率 96%・再現率 94%(time window 100 秒、th=0.1〜0.2)を達成。また CFC より少ないテストラウンドで収束(3〜6 ラウンド対 20+ ラウンド)。**ページ作成**: source 1（[[@2011__SRDS__Identifying Faults in Large-Scale Distributed Systems by Filtering Noisy Error Logs]]）+ entity 3（[[Xiang Rao]]・[[Huaimin Wang]]・[[National University of Defense Technology]]）。**ページ更新**: [[ログ解析]]（障害注入テスト特有のノイズログ問題節・横断的知見 1 項・未解決の問い 2 項追加）・[[障害注入]]（ノイズ障害共存問題の横断的知見 1 項追加）+ sources/_index・entities/_index・index.md・hot.md・log.md・manifest。 2026-06-14: **Shi ほか 2020（SoCC）— ByteSeries: An In-Memory Time Series Database for Large-Scale Monitoring Systems を wiki-ingest-paper で取り込み** — [[@2020__SoCC__ByteSeries - An In-Memory Time Series Database for Large-Scale Monitoring Systems]]（[[Xuanhua Shi]]・Ke Yang・Rong Gu・[[Bingsheng He]]・[[Yongluan Zhou]]・Liping Cao・Yinan Mei・Jianmin Han・Huai Jiang、[[Huazhong University of Science and Technology]] / [[ByteDance]] / [[National University of Singapore]] / [[University of Copenhagen]]、SoCC 2020、DOI:10.1145/3419111.3421289）: [[ByteDance]] の本番メトリクス監視システム(100 億次元超)で元本番 TSDB [[tsdc]] のメタデータがメモリ 80% 超を占める問題を定量化し、Compressed Inverted Index(double-array trie(cedar)+ p4nzenc64(TurboPFor)整数圧縮)と 3 段メモリ構造(Active Buffer→Static Segment→Compressed Segment)を持つインメモリ TSDB [[ByteSeries]] を提案した。Data Conversion Scheduler(DCS)は 3 プロセッサ(Compactor/Merge Processor/Compressor)を 1 バックグラウンドスレッドで管理し、圧縮コストを取り込みと分離する。tsdc 比でメタデータ −60%・全体メモリ −50%・多次元クエリ 1.8〜10.7 倍高速化、[[Prometheus]] 比で同メモリで 7 倍多い次元数を処理。本番環境では 40〜50% のメモリ削減と 80% のクエリが 1ms 未満を達成した。**ページ作成**: source 1（[[@2020__SoCC__ByteSeries - An In-Memory Time Series Database for Large-Scale Monitoring Systems]]）+ entity 5（[[Xuanhua Shi]]・[[Yongluan Zhou]]・[[University of Copenhagen]]・[[ByteSeries]]・[[tsdc]]）。**ページ更新**: [[Bingsheng He]]・[[ByteDance]]・[[Huazhong University of Science and Technology]]・[[National University of Singapore]]・[[時系列データベース]]（横断的知見 4 項・未解決の問い 2 項追加）+ sources/_index・entities/_index・index.md・hot.md・log.md・manifest。 2026-06-14: **Lautenschlager ほか 2017（FAST）— Chronix: Long Term Storage and Retrieval Technology for Anomaly Detection in Operational Data を wiki-ingest-paper で取り込み** — [[@2017__FAST__Chronix - Long Term Storage and Retrieval Technology for Anomaly Detection in Operational Data]]（[[Florian Lautenschlager]]・[[Andreas Kumlehn]]（[[QAware GmbH]]）・[[Josef Adersberger]]・[[Michael Philippsen]]（[[Friedrich-Alexander-Universität Erlangen-Nürnberg]]）、FAST '17 pp.229-242、ISBN 978-1-931971-36-2）: 運用データの異常検知に特化した長期保存 TSDB [[Chronix]] の設計・評価。DDC（Date-Delta-Compaction）は周期的時系列のタイムスタンプを関値 d 以内なら省略・ずれ分のデルタのみ保存する新圧縮方式で値は完全保持する「機能的損失なし」設計。Apache Solr/Lucene 上に 4 段パイプライン（変換→属性チャンク→圧縮→多次元ストレージ）で数値・ログ（`lsof`）・トレース（`strace`）の汎用バイナリチャンクを格納し、`outlier`・`trend`・`frequency`・`SAX`・`FastDTW`・`grpsize`・`split` の 7 ビルトイン解析関数をサーバ側で実行する。108.2 GB 本番データ評価で、ストレージ 8.7 GB（InfluxDB 比 −20%、OpenTSDB 比 −49%）、クエリ合計 27.1 s（InfluxDB 比 −92%）、解析 159.3 s（InfluxDB 比 −74%）を達成。コミッショニング手法でパラメータ（d=200ms、c=128 KB、t=gzip）を体系的に決定できることも実証。**ページ作成**: source 1（[[@2017__FAST__Chronix - Long Term Storage and Retrieval Technology for Anomaly Detection in Operational Data]]）+ entity 6（[[Florian Lautenschlager]]・[[Michael Philippsen]]・[[Andreas Kumlehn]]・[[Josef Adersberger]]・[[QAware GmbH]]・[[Friedrich-Alexander-Universität Erlangen-Nürnberg]]）+ product entity 1（[[Chronix]]）。**ページ更新**: [[時系列データベース]]（ドメイン固有 TSDB の「ビルトイン解析」軸・汎用データモデルの欠如制約を横断的知見に追加）・[[異常検知]]（ストレージ層データモデル制約が探索性を制限することを横断的知見に追加）・[[専用データベースシステム]]（「除去」に加え「機能追加」が主役・「機能的損失なし」設計を横断的知見に追加）+ sources/_index・entities/_index・index.md・hot.md・log.md・manifest。 2026-06-14: **Neves・Vilaça・Pereira 2020（SAC）— Black-box inter-application traffic monitoring を wiki-ingest-paper で取り込み** — [[@2020__SAC__Black-box inter-application traffic monitoring for adaptive container placement]]（[[Francisco Neves]]・[[Ricardo Vilaça]]・[[José Pereira]]、[[HASLab]]-INESC TEC / [[University of Minho]]、SAC 2020、DOI:10.1145/3341105.3374007）: eBPF の kprobe/kretprobe に `<pid, sock>` eBPF マップを使った per-connection バイトカウンタ(KernelAgg)で、アプリケーション非依存にコンテナ間トラフィック量を 9% 未満のオーバーヘッドで計測し、重み付き通信グラフ(Kafka + Neo4j)を構築する手法を提案。per-operation イベント転送(UserAgg)は 68% オーバーヘッド、接続開閉のみ(Weave Scope 方式)は 1% だがトラフィック量不可計測。Cassandra + Spark の 4 ノード GCE クラスタで自動配置(Pyevolve 遺伝的アルゴリズム)により Q1 −28%・Q2 −40% のネットワーク転送量削減、手動配置で Q1 −99.3%(2.46 GB → 17.12 MB)・−12% 実行時間、Q2 −73%・−29% 実行時間を実証。**ページ作成**: source 1（[[@2020__SAC__Black-box inter-application traffic monitoring for adaptive container placement]]）+ entity 5（[[Francisco Neves]]・[[Ricardo Vilaça]]・[[José Pereira]]・[[HASLab]]・[[University of Minho]]）+ concept 1（[[コンテナ配置最適化]]）。**ページ更新**: [[eBPF]]（KernelAgg の定量的根拠を横断的知見に追加）・[[分散トレーシング]]（接続有無 vs トラフィック量の区別を横断的知見に追加）+ sources/_index・entities/_index・concepts/_index・index.md・hot.md・log.md・manifest。 2026-06-14: **Pelkonen ほか 2015（VLDB）— Gorilla: A Fast, Scalable, In-Memory Time Series Database を wiki-ingest-paper で取り込み** — [[@2015__VLDB__Gorilla - A Fast, Scalable, In-Memory Time Series Database]]（[[Tuomas Pelkonen]] ほか [[Facebook]]、PVLDB Vol. 8 No. 12、DOI:10.14778/2824032.2824078）: Facebook のインメモリ TSDB [[Gorilla]] の設計・圧縮・耐障害性を報告した 2015 年の標準的参照論文。デルタ・オブ・デルタ（タイムスタンプ 96% を 1 ビット）と XOR 浮動小数点（値 51% を 1 ビット）の 2 段階圧縮で 16 バイト → 1.37 バイト/点（12 倍圧縮）を達成し、HBase 比クエリレイテンシ 73〜350 倍削減・ピーク 40,000 QPS を実現。直近 26 時間を write-through キャッシュとして 2 リージョンに並行ストリーミング（整合性保証なし）し、単一ノード障害は Paxos ベース ShardManager で 30 秒以内に吸収。「Gorilla 圧縮」は後続の [[HeteroTSDB]] でも採用される事実上の監視 TSDB 圧縮標準。**ページ作成**: source 1（[[@2015__VLDB__Gorilla - A Fast, Scalable, In-Memory Time Series Database]]）+ entity 2（[[Gorilla]]・[[Tuomas Pelkonen]]）。**ページ更新**: [[時系列データベース]]（横断的知見 2 項・未解決の問い 1 項追加）・[[メインメモリデータベース]]（横断的知見 2 項・未解決の問い 1 項追加）・[[Facebook]] + sources/_index・entities/_index・index.md・hot.md・log.md・manifest。 2026-06-14: **Müller・Benson・Leis 2025（SIGMOD/PACMMOD）— B-Trees Are Back を wiki-ingest-paper で取り込み** — [[@2025__SIGMOD__B-Trees Are Back - Engineering Fast and Pageable Node Layouts]]（[[Marcus Müller]]・[[Lawrence Benson]]・[[Viktor Leis]]、[[TU Munich]]、DOI:10.1145/3709664）: 可変長レコードを支援する可ページング [[B-Tree]] を、4 KiB node と inline storage を保ったまま再工学する論文。prefix truncation・heads・hints・fingerprinting・semi dense leaves・fully dense leaves を分解評価し、key shape と scan 頻度で leaf layout を切り替える適応 B-Tree を提案。FDL は 100% dense integer で lookup +71%・insert +213%・scan +105%、adaptive B-Tree は scan で ART/HOT/Wormhole/LITS を大きく上回り、[[vmcache]] 統合では out-of-memory でも space efficiency が SSD read 確率を支配することを示す。**ページ作成**: source 1（[[@2025__SIGMOD__B-Trees Are Back - Engineering Fast and Pageable Node Layouts]]）+ concept 2（[[B-Tree]]・[[B-Treeノードレイアウト最適化]]）+ entity 6（[[Marcus Müller]]・[[Lawrence Benson]]・[[Viktor Leis]]・[[btree-cpp]]・[[btree24]]・[[vmcache]]）。**ページ更新**: [[TU Munich]]・[[LSMツリー]]・[[メインメモリデータベース]] + index/log/hot/manifest。 2026-06-14: **Dai et al. 2026（SIGIR）— LLM-Oriented Information Retrieval を wiki-ingest-paper で取り込み** — [[@2026__SIGIR__LLM-Oriented Information Retrieval - A Denoising-First Perspective]]（[[Lu Dai]]・[[Liang Sun]]・[[Fanpu Cao]]・[[Ziyang Rao]]・[[Cehao Yang]]・[[Hao Liu]]・[[Hui Xiong]]、[[Hong Kong University of Science and Technology]] / [[Hong Kong University of Science and Technology, Guangzhou]]、SIGIR 2026、arXiv:2605.00505）: LLM が検索結果の主要な消費者になることで、情報検索の目的は raw recall から、文脈ウィンドウ内の利用可能な証拠密度と検証可能性へ移ると主張。NQ 500 サンプル実験で、金パッセージ 1→5 件に増やすと EM 47.0%→61.0% と改善する一方、金 3 件にノイズ 7 件を足すと 41.8%、純ノイズ文脈では 8.0% まで悪化。Controlled Indexing / Robust Retrieval / Context Assembly / Retrieval Verification / Closed-Loop Training の 5 段タクソノミーで、RAG 改善技術を「検索器がノイズゲートになる」設計へ再編する。**ページ作成**: source 1（[[@2026__SIGIR__LLM-Oriented Information Retrieval - A Denoising-First Perspective]]）+ concept 2（[[LLM向け情報検索]]・[[RAGノイズ除去]]）+ entity 7（[[Lu Dai]]・[[Liang Sun]]・[[Fanpu Cao]]・[[Ziyang Rao]]・[[Cehao Yang]]・[[Hao Liu]]・[[Hui Xiong]]）。**ページ更新**: [[エージェント型コーディング]]（コード検索を証拠密度最大化として追記）・[[エージェント型強化学習]]（閉ループ検索/RAG をノイズ流量制御として追記）・[[Hong Kong University of Science and Technology, Guangzhou]]・[[Hong Kong University of Science and Technology]] + index/log/hot/manifest。 2026-06-14: **Wang・Qiu・Yuan・Zhang 2025（SIGMOD/PACMMOD）— LSM ツリーコンパクション方針 EcoTune を wiki-ingest-paper で取り込み** — [[@2025__SIGMOD__Rethinking The Compaction Policies in LSM-trees]]（[[Hengrui Wang]]・[[Jiansheng Qiu]]・[[Fangzhou Yuan]]・[[Huanchen Zhang]]、[[Tsinghua University]] / [[Shanghai Qi Zhi Institute]]、DOI:10.1145/3725344）: LSM ツリーのコンパクションを、従来の WA/RA トレードオフではなく「将来の平均クエリスループットへの CPU/I/O 投資」として再定式化。現代 NVMe SSD ではフラッシュ用資源を予約すればコンパクション方針は書き込みレイテンシへほぼ影響しないと示し、top/main/last の三レベルモデルと動的計画法ベース [[EcoTune]] を提案。[[RocksDB]] 評価で Leveling 比 1.5〜3 倍、Lazy Leveling 比最大 1.8 倍の平均クエリスループット、レイテンシで最大 3〜4 桁低下を示す。**ページ作成**: source 1（[[@2025__SIGMOD__Rethinking The Compaction Policies in LSM-trees]]）+ concept 1（[[LSMツリーコンパクション]]）+ entity 7（[[Hengrui Wang]]・[[Jiansheng Qiu]]・[[Fangzhou Yuan]]・[[Huanchen Zhang]]・[[EcoTune]]・[[RocksDB]]・[[Shanghai Qi Zhi Institute]]）。**ページ更新**: [[LSMツリー]]（未解決だったコンパクション方針比較へ回答を追加）・[[データベースノブチューニング]]（公開ノブ探索と内部方針最適化の対比）・[[データベース O&M]]（性能最適化の事前介入として追加）・[[Tsinghua University]] + index/log/hot/manifest。 2026-06-14: **Cohen・Goldszmidt+ 2004（OSDI）— TAN ベース SLO 違反分類論文を wiki-ingest-paper で取り込み** — [[@2004__OSDI__Correlating Instrumentation Data to System States - A Building Block for Automated Diagnosis]]（[[Ira Cohen]]・[[Moises Goldszmidt]]・[[Terence Kelly]]・[[Julie Symons]]（[[HP Labs]]）・[[Jeffrey S. Chase]]（[[Duke University]]）、OSDI 2004）: Java PetStore を対象とした三層 Web サービステストベッドで 124 システムメトリクスを 15 秒間隔で計測し、TAN（ツリー拡張ナイーブベイズネットワーク）による SLO 違反の二値分類を提案。RAMP/STEP/BUGGY の 3 ワークロードで balanced accuracy 87–94% を達成し、CPU 単独ルールが STEP で 56% まで低下することを定量化。「メトリクス帰属（metric attribution）」という概念を初めて明示し、ワークロードごとに異なるメトリクスが SLO 違反を支配することを実証。「相関 ≠ 因果」制約も明言しており、Soldani & Brogi 2021 より 17 年早く同じ限界を記録していた。**ページ作成**: source 1（[[@2004__OSDI__Correlating Instrumentation Data to System States - A Building Block for Automated Diagnosis]]）+ entity 7（[[Ira Cohen]]・[[Moises Goldszmidt]]・[[Terence Kelly]]・[[Julie Symons]]・[[Jeffrey S. Chase]]・[[HP Labs]]・[[Duke University]]）。**ページ更新**: [[根本原因分析]]（「相関 ≠ 因果」2004 年明示の横断的知見追加）・[[異常検知]]（SLO 二値分類・単一メトリクスルール不十分の 2004 年実証追加）・[[Fault Localization]]（メトリクス帰属の先駆的定式化追加）+ sources/_index・entities/_index・index.md・hot.md・log.md・manifest。 2026-06-14: **Phan・Hendrycks+ 2025（arXiv）— Humanity's Last Exam（HLE）を wiki-ingest-paper で取り込み** — [[@2025__arXiv__Humanity's Last Exam]]（[[Long Phan]]・Alice Gatti・Ziwen Han・Nathaniel Li（共同第一著者）・[[Dan Hendrycks]]（上級著者）ほか、[[Center for AI Safety]] / [[Scale AI]]、arXiv:2501.14249、2025-01-24）: MMLU 等の既存ベンチマークが最先端 LLM で 90% 超の正解率に飽和した問題に対し、50 か国・500+ 機関・約 1,000 名の専門家が 100+ 科目・2,500 問を設計した最前線学術ベンチマーク HLE を提案。LLM 難易度チェック（70,000 件超の試行）→ 専門家 2 段階レビューで厳格に品質管理。最先端モデルの正解率は最高 13.4%（o3-mini high、テキストのみ）、全モデルで RMS キャリブレーション誤差 73〜89% と誤答時も高確信度を示す。推論モデルは非推論モデルより大幅に多い補完トークンを消費し、精度向上に大量の推論時計算が必要なことを確認。論文は「HLE が最後の学術試験になるかもしれないが AGI の証明にはならない」と位置づける。**ページ作成**: source 1（[[@2025__arXiv__Humanity's Last Exam]]）+ entity 4（[[Dan Hendrycks]]・[[Long Phan]]・[[Center for AI Safety]]・[[Scale AI]]）。**ページ更新**: [[LLM評価]]（ベンチマーク飽和・最前線ベンチマーク設計・横断的知見 4 項追加・未解決の問い 2 項追加）+ index/log/hot/manifest。 2026-06-14: **Chiang・Zheng+ 2024（arXiv）— Chatbot Arena 論文を wiki-ingest-paper で取り込み** — [[@2024__arXiv__Chatbot Arena - An Open Platform for Evaluating LLMs by Human Preference]]（[[Wei-Lin Chiang]]・[[Lianmin Zheng]] ほか [[LMSYS]]/[[University of California, Berkeley]]、arXiv:2403.04132、2024-03-07）: クラウドソーシング型ペアワイズ比較で LLM を評価するオープンプラットフォーム [[Chatbot Arena]] を提案。2 軸分類（質問ソース×評価指標）で静的ベンチマーク群の限界を整理し、Chatbot Arena を「ライブ×人間嗜好」の唯一の象限に位置づけ。Bradley-Terry(BT)モデルで従来の Elo より頑健な統計的ランキングを実現し、能動サンプリングで win matrix 推定精度 0.2 達成に必要な票数をランダム比で 35% 削減。クラウドソーシング投票と専門家評価の一致率 72〜83%（専門家間は 79〜90%）で、差分の多くは「事実誤りの見落とし」に起因。**ページ作成**: source 1（[[@2024__arXiv__Chatbot Arena - An Open Platform for Evaluating LLMs by Human Preference]]）+ entity 4（[[Wei-Lin Chiang]]・[[Lianmin Zheng]]・[[LMSYS]]・[[Chatbot Arena]]）+ concept 1（[[LLM評価]]）。**ページ更新**: [[Ion Stoica]]（関連リンク追加）+ index/log/hot/manifest。 2026-06-14: **Pham・Ha・Zhang 2024（ASE）— 因果推論ベース RCA の包括評価論文を wiki-ingest-paper で取り込み** — [[@2024__ASE__Root Cause Analysis for Microservices based on Causal Inference - How Far Are We]]（[[Luan Pham]]・[[Huong Ha]]（[[RMIT University]]）・[[Hongyu Zhang]]（[[Chongqing University]]）、ASE 2024、DOI:10.1145/3691620.3695065）: PC/FCI/LiNGAM/Granger/GES 等 9 種の因果探索アルゴリズムと、ランダムウォーク/PageRank/仮説検定の 3 種スコアリングを組み合わせた 21 種の因果推論ベース RCA 手法を、Sock Shop・Online Boutique・Train Ticket(64 サービス・212 メトリクス)の 3 実システムと CIRCA/RCD 等 6 種の合成データセットで包括評価。**最大の知見は「Dummy ベースライン(ランダム選択)を超えない手法が多い」**——PC/FCI/Granger 系の多くが Dummy 同等にとどまり、因果グラフ F1 は 0.10〜0.54 で辺方向推定が全手法の共通ボトルネック。仮説検定系（BARO・NSigma・ε-Diagnosis）はグラフ構築をスキップして直接根本原因を特定するため全体的に優秀。合成データでの高精度が実システムへ転移しないデータ分布ギャップも定量化。評価フレームワーク [[RCAEval]] をオープンソース公開。**ページ作成**: source 1（[[@2024__ASE__Root Cause Analysis for Microservices based on Causal Inference - How Far Are We]]）+ entity 6（[[Luan Pham]]・[[Huong Ha]]・[[Hongyu Zhang]]・[[RMIT University]]・[[Chongqing University]]・[[RCAEval]]）+ concept 1（[[因果推論ベースRCA]]）。**ページ更新**: [[根本原因分析]]（横断的知見 2 項追加）・[[Fault Localization]]（横断的知見 1 項追加）+ index/log/hot/manifest。 2026-06-14: **Microsoft Research Blog 2024 — Intelligent Monitoring: Towards AI-Assisted Monitoring for Cloud Services を wiki-ingest で取り込み** — [[@2024__Microsoft Research Blog__Intelligent Monitoring - Towards AI-Assisted Monitoring for Cloud Services]]（[[Anjaly Parayil]]・[[Chetan Bansal]]・[[Saravan Rajmohan]] ほか [[Microsoft]]、2024-03-19）: ICSE-SEIP 2024 論文（[[@2024__ICSE-SEIP__Intelligent Monitoring Framework for Cloud Services - A Data-Driven Approach]]）の一般向けブログ解説。論文未掲載の将来計画として **Monitor Scorecards** を予告——ベイズ統計と時系列モデリングを組み合わせてモニタ有効性をインシデント分析・影響評価で体系評価するシステム。これにより「推奨（Intelligent Monitoring Framework）→評価（Monitor Scorecards）」のサイクルが計画されている。著者役割として Avi Nayak（Senior PM）・Piyali Jana（Principal SWE Manager）・Rujia Wang（Principal Research PM）が明示された。**ページ作成**: source 1 + entity 2（[[Avi Nayak]]・[[Piyali Jana]]）。**ページ更新**: [[Rujia Wang]]（役割追記）・[[クラウドモニタリング]]（Monitor Scorecards を未解決の問いに追加）+ index/log/hot/manifest。 2026-06-14: **Soldani & Brogi 2021（ACM CSUR）— 異常検知・RCA 統合サーベイを wiki-ingest-paper で取り込み** — [[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey]]（[[Jacopo Soldani]]・[[Antonio Brogi]]、[[University of Pisa]]、ACM Computing Surveys 2021、DOI:10.1145/3501297）: マルチサービスアプリケーションの異常検知（25 手法）と根本原因分析（26 手法）の両者を統合した最初のサーベイ。データ源（ログ/分散トレース/監視メトリクス）× 手法（教師なし/教師あり/トレース比較/SLO チェック/ハートビート）の 2 軸で分類（Table 1/2）。PC アルゴリズム + ランダムウォーク（MonitorRank パターン）による因果グラフ訪問が pre-LLM era の標準 RCA パイプラインとして定着したことを整理。中心的知見は「**相関は因果を保証しない**——すべての相関ベース RCA は偽陽性・偽陰性を原理的に免れない」（§4.4.3）。3 つの未解決課題（説明可能性・対策推奨・継続的変化への対応）を提示し、LLM-era RCA が目指す先を 2021 年から定義していた。**ページ作成**: source 1（[[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey]]）+ entity 2（[[Jacopo Soldani]]・[[Antonio Brogi]]）。**ページ更新**: [[異常検知]]（古典的タクソノミと訓練問題の横断的知見 2 項・未解決の問い 1 項追加）・[[根本原因分析]]（相関≠因果・MonitorRank パターン・説明可能性課題の横断的知見 3 項・未解決の問い 1 項追加）+ index/log/hot/manifest。 2026-06-14: **Srinivas et al. 2024（ICSE-SEIP）— Intelligent Monitoring Framework for Cloud Services を wiki-ingest-paper で取り込み** — [[@2024__ICSE-SEIP__Intelligent Monitoring Framework for Cloud Services - A Data-Driven Approach]]（[[Pooja Srinivas]] ほか [[Microsoft]]、ICSE-SEIP 2024）: 791 本番マイクロサービスの 30,920 モニタをマイニングし、LLM（GPT-3.5）を用いた文脈内学習でリソースクラス 13 種（Service-level 78%・API 9%・Dependency 3.75% が上位）・SLO タイプ 9 種（成功率・キャパシティ・レイテンシが上位）のモニタオントロジーを構築。プロトタイプ学習ネットワーク（オートエンコーダ＋プロトタイプ分類）で依存グラフ・コンポーネントからリソースクラスを自動推奨し、大多数のクラスで再現率 1.00 を達成（Table 4）。ユーザースタディ（11 名の Microsoft エンジニア）で 4.27/5.0。「何を監視するか」問題に対する初のデータ駆動アプローチ。**ページ作成**: source 1（[[@2024__ICSE-SEIP__Intelligent Monitoring Framework for Cloud Services - A Data-Driven Approach]]）+ entity 3（[[Pooja Srinivas]]・[[Fiza Husain]]・[[Ayush Choure]]）。**ページ更新**: [[Anjaly Parayil]]・[[Chetan Bansal]]・[[Saravan Rajmohan]]・[[クラウドモニタリング]]（横断的知見 2 項追加・未解決の問い改訂）+ index/log/hot/manifest。 2026-06-14: **Ganatra et al. 2023（ESEC/FSE）— Detection Is Better Than Cure を wiki-ingest-paper で取り込み** — [[@2023__ESEC-FSE__Detection Is Better Than Cure - A Cloud Incidents Perspective]]（[[Vaibhav Ganatra]] ほか [[Microsoft]]、ESEC/FSE 2023）: Microsoft の 300 超クラウドサービス・2022 年間の本番インシデント約 950 件を分析した実証研究。ミス検知の 6 カテゴリタクソノミを構築し、**40.41% が「必要なモニタ/アラートが存在しない（Missing monitor/alert）」に起因**することを定量化。ミス検知の 27.25% がアウテージに発展し、顧客報告インシデントは TTD **10.7 倍**・TTM **3.75 倍**と計測。サービス成熟度が「何を監視すべきか」を、依存関係数が「どう監視すべきか」を左右する。**ページ作成**: source 1（[[@2023__ESEC-FSE__Detection Is Better Than Cure - A Cloud Incidents Perspective]]）+ entity 3（[[Vaibhav Ganatra]]・[[Yu Kang]]・[[Anjaly Parayil]]）+ concept 1（[[クラウドモニタリング]]）。**ページ更新**: [[Chetan Bansal]]・[[Supriyo Ghosh]]・[[Suman Nath]]・[[Jonathan Mace]]・[[Minghua Ma]]・[[インシデント管理]]・[[異常検知]] + index/log/hot/manifest。 2026-06-14: **CNCF TAG Observability Whitepaper（v1.0、2023 年 10 月）を wiki-ingest-paper で取り込み** — [[@2023__CNCF TAG Observability__Observability Whitepaper]]（[[CNCF]] [[TAG Observability]]、35+ 名の貢献者、2023-10）: クラウドネイティブオブザーバビリティの包括的なホワイトペーパー。**制御理論的定義**・**5 シグナル分類**（メトリクス〔集約数値/低コスト〕・ログ〔テキストイベント/中コスト〕・トレース〔分散トランザクション木/高コスト〕・プロファイル〔コード実行データ/中コスト〕・ダンプ〔メモリスナップショット/高コスト〕）・**シグナル間相関機構**（ターゲットメタデータ統一・Trace ID のログへの付与・Exemplar〔ヒストグラムへの代表 Trace ID 埋め込み〕）・**SLO ベースバーンレートアラートの定量化**（バーンレート 1=30 日・2=15 日・10=3 日・1000=43 分で枯渇）・**エコシステムギャップ 4 点**（自動/非侵襲計装・標準クエリ層の欠如・ログ/トレース/プロファイル OSS DB の不在・統一ダッシュボード不在）を体系化。[[OpenTelemetry]] を「計装・収集の業界標準」として位置づける。PDF は存在せず `.raw/articles/cncf-observability-whitepaper.md` に保存。**ページ作成**: source 1（[[@2023__CNCF TAG Observability__Observability Whitepaper]]）+ entity 3（[[CNCF]]・[[TAG Observability]]・[[Liz Fong-Jones]]）+ concept 1（[[継続的プロファイリング]]）。**ページ更新**: [[オブザーバビリティ]]（5 シグナル表・横断的知見 2 点・未解決の問い追加）・[[テレメトリ]]（5 シグナル拡張の横断的知見追加）・[[エラーバジェット]]（バーンレート定量化表・PromQL 例追加）・[[OpenTelemetry]]（W3C Trace Context・OTLP・Exemplar・クエリ標準化ギャップ追加）+ index/log/hot/manifest。 2026-06-14: **3 論文（PADBI サーベイ・変更起因インシデント 2 本）を wiki-ingest-paper で取り込み** — [[@2015__CSUR__Performance Anomaly Detection and Bottleneck Identification]]（[[Olumuyiwa Ibidunmoye]]・[[Francisco Hernández-Rodriguez]]・[[Erik Elmroth]]、[[Umeå University]]、ACM CSUR 2015）: 性能異常検知とボトルネック特定(PADBI)の最初期の体系的サーベイ。異常を point/collective/contextual/pattern、ボトルネックを resource saturation/contention × single/multiple/shifting に分類。4 検知戦略(シグネチャ/観測/知識/フロー)と統計/ML 手法を整理。調査論文 53% が PAD のみで PADBI 統合は 18% にとどまる。 [[@2023__ISSRE__How to Manage Change-Induced Incidents - Lessons from the Study of Incident Life Cycle]]（[[Yujin Zhao]] ほか、[[Peking University]]/[[Alibaba Group]]、IEEE ISSRE 2023）: 2 年間 231 件の変更起因インシデントを「導入→検知→緩和」の 3 段で分析。RbIC(即時原因除去前回復)は RaIC より TTM を 40.6% 短縮(38.8 対 65.3)。モニター検知は 7.67 倍速いが 50.6% で利用者が先に検知。モニター失敗 3 類型(未設定 46.2%/不能 35.0%/未認識 18.8%)。 [[@2023__ICSE-SEIP__An Empirical Study on Change-induced Incidents of Online Service Systems]]（[[Yifan Wu]] ほか、[[Peking University]]/[[Ant Group]]、ICSE-SEIP 2023）: Ant Group 161 件の変更起因インシデントを分析。重篤度 High+Critical が通常の 2.6 倍(13% 対 5%)・TTD 75 パーセンタイルが 26.8 倍長い。4 課題(不足したモニタリング指標/不正確な変更モニタリング/低ビジネストラフィック/非効率な異常変更箇所特定)。**ページ作成**: source 3・entity 16（[[Olumuyiwa Ibidunmoye]]・[[Francisco Hernández-Rodriguez]]・[[Erik Elmroth]]・[[Umeå University]]・[[Yujin Zhao]]・[[Ling Jiang]]・[[Ye Tao]]・[[Songlin Zhang]]・[[Changlong Wu]]・[[Yifan Wu]]・[[Zhonghai Wu]]・[[Bingxu Chai]]・[[Bingchang Liu]]・[[Jianguo Li]]・[[Yong Yang]]・[[Wei Jiang]]）+ concept 1（[[変更起因インシデント]]）。**ページ更新**: concept 2（[[異常検知]]・[[インシデント管理]]）+ index/log/hot/manifest。 2026-06-14: **オブザーバビリティデータ管理ビジョン論文（SIGMOD Record 2021、Karumuri ら）を wiki-ingest-paper で取り込み** — [[@2021__SIGMOD Record__Towards Observability Data Management at Scale]]（[[Suman Karumuri]]・[[Franco Solleza]]・[[Stan Zdonik]]・[[Nesime Tatbul]]、[[Slack Technologies]] / [[Brown University]] / Intel Labs / MIT、SIGMOD Record 2021）: オブザーバビリティデータを Metrics・Events・Logs・Traces（MELT）の 4 型に分類し、統合管理する ODMS（Observability Data Management System）のビジョンを提示した 2021 年の先駆的論文。Slack の 2020 年実測データ——Metrics 4B 系列/日・12M サンプル/秒・12TB/日、Events 250TB/日（生）・70PB+ 蓄積、Logs 90TB/日・7 日保持、Traces 2TB/日・14 日保持——から、クエリの 97% 超が直近 24 時間以内のデータを対象とすること（鮮度バイアス）を定量化。ODMS の 4 設計原則は：(1)リアルタイム/履歴の分離、(2)MELT ライフサイクルの統一管理、(3)単一クエリインタフェース、(4)クラウドネイティブ分散展開。提案アーキテクチャは Replicated Log Service → Real-Time Indexing → Persistent Storage → Hot Data Cache のポリストア構成で、各層を独立にスケールする。**ページ作成**: source 1（[[@2021__SIGMOD Record__Towards Observability Data Management at Scale]]）+ entity 5（[[Suman Karumuri]]・[[Franco Solleza]]・[[Stan Zdonik]]・[[Nesime Tatbul]]・[[Slack Technologies]]）。**ページ更新**: [[オブザーバビリティデータモデル]]・[[テレメトリ]]・[[時系列データベース]]・[[Brown University]] + index/log/hot/manifest。 2026-06-14: **オブザーバビリティサーベイ（IEEE ACCESS 2022、Usman ら）を wiki-ingest-paper で取り込み** — [[@2022__IEEE ACCESS__A Survey on Observability of Distributed Edge & Container-Based Microservices]]（[[Muhammad Usman]]・[[Simone Ferlin]]・[[Anna Brunstrom]]・[[Javid Taheri]]、[[Karlstad University]] / [[Red Hat]]）: 分散エッジ・コンテナ化マイクロサービスのオブザーバビリティを調査した 2022 年時点の包括サーベイ。三本柱（ログ/メトリクス/トレース）・SRE ゴールデンシグナル（レイテンシ/トラフィック/エラー/飽和）・オブザーバビリティシステムの基本機能（F1 相関・F2 トポロジ・F3 インシデント対応）と重要特性（C1〜C5）・オープン課題（統合プラットフォーム不在・異種インフラ・組織文化）を整理。**ページ作成**: source 1（[[@2022__IEEE ACCESS__A Survey on Observability of Distributed Edge & Container-Based Microservices]]）+ entity 5（[[Muhammad Usman]]・[[Simone Ferlin]]・[[Anna Brunstrom]]・[[Javid Taheri]]・[[Karlstad University]]）+ concept 1（[[オブザーバビリティ]]）。**ページ更新**: [[テレメトリ]]・[[分散トレーシング]]・[[マイクロサービスアーキテクチャ]] + index/log/hot/manifest。 2026-06-14: **Chain-of-Thought Prompting Elicits Reasoning in Large Language Models（arXiv:2201.11903、Wei et al. 2022、NeurIPS 2022）を wiki-ingest-paper で取り込み** — [[@2022__NeurIPS__Chain-of-Thought Prompting Elicits Reasoning in Large Language Models]]（[[Jason Wei]]・[[Denny Zhou]] ほか [[Google Brain]]）: プロンプト例示に最終答えだけでなく中間推論ステップの系列（連鎖思考）を加えることで、追加学習なしに LLM の複雑推論能力を大幅に向上させる手法を提案。PaLM 540B が 8 件の CoT 例示のみで GSM8K 数学ベンチマーク SOTA（当時）を達成し、ファインチューニング GPT-3 + 検証器を超えた。連鎖思考推論は約 100B パラメータ以上のモデルにのみ正の効果をもたらす創発的能力。標準プロンプティングとの差異が大規模化に伴って拡大するスケール創発パターンを確認。**ページ作成**: source 1（[[@2022__NeurIPS__Chain-of-Thought Prompting Elicits Reasoning in Large Language Models]]）+ entity 2（[[Jason Wei]]・[[Denny Zhou]]）+ concept 1（[[Chain-of-Thought Prompting]]）。**ページ更新**: [[Google Brain]] + index/log/hot/manifest。 2026-06-14: **Scaling Laws for Autoregressive Generative Modeling（arXiv:2010.14701、Henighan et al. 2020、OpenAI）を wiki-ingest-paper で取り込み** — [[@2020__arXiv__Scaling Laws for Autoregressive Generative Modeling]]（[[Tom Henighan]]・[[Jared Kaplan]] ほか [[OpenAI]]）: スケーリング則 $L(x) = L_\infty + (x_0/x)^{\alpha_x}$ が言語だけでなく画像（8×8/16×16/32×32/VQVAE 64×64）・動画・マルチモーダル（テキスト↔画像）・数学的問題求解に成立することを実証。最適モデルサイズの指数 $\beta \approx 0.7$ が全モダリティで普遍的に一定。損失の低減不可能成分 $L_\infty$ はデータ分布のエントロピー、低減可能成分は KL ダイバージェンスに対応するという情報理論的解釈を提示。生成損失が $L_\infty$ に近づいても下流の ImageNet 分類性能は冪乗則的に改善し続けることを確認。**ページ作成**: source 1（[[@2020__arXiv__Scaling Laws for Autoregressive Generative Modeling]]）+ entity 1（[[Tom Henighan]]）。**ページ更新**: [[OpenAI]]・[[LLMスケーリング則]]・[[Jared Kaplan]] + index/log/hot/manifest。 2026-06-14: **DeepSeekMath（arXiv 2402.03300、DeepSeek-AI / Tsinghua / PKU）を wiki-ingest-paper で取り込み** — [[@2024__arXiv__DeepSeekMath - Pushing the Limits of Mathematical Reasoning in Open Language Models]]（Zhihong Shao ほか [[DeepSeek-AI]] / [[Tsinghua University]] / [[Peking University]]）: 7B モデル DeepSeekMath 7B を提案し、外部ツールなしで MATH 51.7%・Self-consistency 64 サンプルで 60.9% を達成。fastText 分類器の 4 回の反復収集で Common Crawl から 120B 数学トークン（35.5M ページ）の DeepSeekMath Corpus を構築。DeepSeek-Coder-Base-v1.5 7B をベースに数学 56%・コード 20%・自然言語 10%・arXiv 10%・AlgebraicStack 4% で 500B トークン継続学習し、コード×数学の相乗効果を実証。RL アルゴリズム GRPO（Group Relative Policy Optimization）を初提案——価値モデルを廃してグループ G 個の応答をサンプリングし、グループ内報酬正規化でアドバンテージを推定。7B で Minerva 540B を上回る。GRPO は後続の DeepSeek-R1（671B MoE）・DeepSWE・DeepSeek-V3.2 の標準アルゴリズムとして継承される。**ページ作成**: source 1。**ページ更新**: [[DeepSeek-AI]]・[[GRPO]]・[[強化ファインチューニング]]・[[強化学習スケーリング]] + index/log/hot/manifest。 2026-06-13: **From Detection to Recovery（arXiv 2026 / Lablup Technical Report）を wiki-ingest-paper で取り込み** — [[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]]（[[Daemyung Kang]] ほか [[Lablup Inc]]）: 63 ノード・504 NVIDIA B200 GPU の本番 LLM 事前学習クラスタで、55 日の Prometheus 時系列、73 日の運用ログ、224 マルチノードセッションを分析。751 メトリクスと 10 XID 同定 GPU 障害では、障害種別をまたいで支配的な単一先行メトリクスは存在しない。523 checkpoint events では restart load 平均 150.8 GB/s（最大 read の 21.5%）・save burst 平均 40.1 GB/s（最大 write の 16.0%）で、WRITE RPC は平均 2.03 秒/要求のうち 1.89 秒（93.1%）がキュー時間。224 セッションのノード除外は上位 3/63 ノードが 50% 超を占め、自動リトライは 12 チェーンで成功率 33.3%。**ページ作成**: source 1 + entity 4（[[Lablup Inc]]・[[Backend.AI]]・[[Sokovan]]・[[Daemyung Kang]]）。**ページ更新**: [[NVIDIA]]・[[VAST Data]]・[[耐障害LLM訓練]]・[[GPUクラスタ運用]]・[[チェックポイント]]・[[LLM学習モニタリング]] + index/log/hot/manifest。 2026-06-13: **Azure Storage RDMA（NSDI 2023）を wiki-ingest-paper で取り込み** — [[@2023__NSDI__Empowering Azure Storage with RDMA]]（[[Wei Bai]] ほか [[Microsoft]]）: [[Azure Storage]] のストレージフロントエンド/バックエンド通信を [[RDMA]] 化し、リージョン内の複数データセンターをまたぐ RoCEv2 を本番展開した経験論文。sU-RDMA/sK-RDMA、[[RDMA Estats]]、[[SONiC]]、PFC watchdog、PFC/DCQCN、異世代 NIC の相互運用性調整を統合し、2023年2月時点で Azure パブリックリージョンのトラフィック約70%が RDMA、リージョン内 RDMA は全 Azure パブリックリージョンでサポートされた。1MB I/O で read 23.8%・write 15.6% のレイテンシ削減、ホストドメイン CPU 最大 34.5% 削減を報告。**ページ作成**: source 1 + entity 3（[[Wei Bai]]・[[Azure Storage]]・[[RDMA Estats]]）。**ページ更新**: [[Microsoft]]・[[SONiC]]・[[RDMA]]・[[RDMAネットワーク監視]]・[[分散ストレージ]] + index/log/hot/manifest。 2026-06-12: **Aurora PostgreSQL Limitless Database（SIGMOD Companion 2026）を wiki-ingest-paper で取り込み** — [[@2026__SIGMOD Companion__Aurora PostgreSQL Limitless Database - Building a Highly Scalable OLTP Database]]（[[Dmitry Arkhangelskiy]] ほか [[Amazon Web Services]]、DOI:10.1145/3788853.3803089）: Amazon Aurora PostgreSQL を、ルータ群と PostgreSQL シャード群で構成される [[Aurora Limitless Database]] へ拡張する論文。sharded/reference/standard table、ルータ/シャード分離、Amazon Time Sync による時刻ベース MVCC、lead shard 付き 2PC、commit wait による外部整合性、Aurora Serverless V2 とシャード分割を組み合わせる適応スケーリング、DDL/バックアップ/クエリ pushdown まで含む設計を報告。AWS 本番で 1 年以上稼働し、観測最大構成は 32 ルータ・64 シャード。HammerDB では 8 ルータ・16 シャード・3072 ACU で 2,891,718 NOPM・NEWORD 平均 9.72ms。**ページ作成**: source 1 + entity 2（[[Aurora Limitless Database]]・[[Dmitry Arkhangelskiy]]）+ concept 1（[[分散 PostgreSQL]]）。**ページ更新**: [[Amazon Web Services]]・[[OLTPシステムアーキテクチャ]] + index/log/hot/manifest。 2026-06-12: **マイクロサービス異常検知/RCA サーベイ（Cluster Computing 2026）を wiki-ingest-paper で取り込み** — [[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey]]（[[Luís M. Barata]]・[[Sérgio Sequeira]]・[[Eurico Lopes]]・[[Pedro R. M. Inácio]]・[[Mário M. Freire]]、[[Cluster Computing]] 29:309、DOI:10.1007/s10586-026-06095-9）: 2012〜2025 年のマイクロサービス異常検知・根本原因特定研究を体系化したサーベイ。ログ/トレース/監視メトリクス、教師なし/教師あり/統計/トレース比較、機械学習/グラフ/統計 RCA、Train Ticket・Sock Shop・AIOps Challenge 2020/2021 などの評価基盤を整理する。手法比較ではトレース比較が recall 99.0%・F1 98.2%、根本原因特定では機械学習系が precision 94.9%・recall 98.0%・F1 99.0% とされるが、データセット・障害種別・指標の不均一性が直接比較を制約する。**ページ作成**: source 1 + entity 10（著者 5・所属/媒体 5）。**ページ更新**: concept 4（[[異常検知]]・[[根本原因分析]]・[[マイクロサービスアーキテクチャ]]・[[Fault Localization]]）+ index/log/hot/manifest。 2026-06-11: **RCAgent（CIKM 2024）を wiki-ingest-paper で正式取り込み** — [[@2024__CIKM__RCAgent - Cloud Root Cause Analysis by Autonomous Agents with Tool-Augmented Large Language Models]]（[[Zefan Wang]]・[[Zichuan Liu]]・[[Yingying Zhang]] ほか、[[Alibaba Group]] / [[Tsinghua University]] / [[Nanjing University]] ほか）: [[Alibaba Cloud]] の Apache Flink リアルタイム計算基盤を対象に、プライバシー制約下で GPT 系 API ではなく社内配置 Vicuna-13B を使うツール拡張 RCA エージェント [[RCAgent]] を提案。OBSK、意味的に最小な情報収集ツール、コード/ログ専門エージェント、JsonRegen、エラー処理、TSC を組み合わせ、ReAct 比で根本原因・解決策・証拠・責任判定を全側面で改善。SQL/SLS 直接ツールでは Invalid Rate 70.94% まで悪化し、RCA エージェントでは「推論能力」だけでなく「環境への入口を狭く設計すること」が性能を律速することを示す。**ページ作成**: entity 13（[[RCAgent]]・[[Zefan Wang]]・[[Zichuan Liu]]・[[Yingying Zhang]]・[[Aoxiao Zhong]]・[[Jihong Wang]]・[[Fengbin Yin]]・[[Lunting Fan]]・[[Lingfei Wu]]・[[Qingsong Wen]]・[[Xi’an Jiaotong University]]・[[Anytime AI]]・[[Squirrel Ai Learning]]）。**ページ更新**: source stub 1（[[@2024__CIKM__RCAgent - Cloud Root Cause Analysis by Autonomous Agents with Tool-Augmented Large Language Models]]）+ concept 5（[[AIOps]]・[[根本原因分析]]・[[RCA入力選別]]・[[agentic SRE]]・[[ログ解析]]）+ index/log/manifest。（source 正式化 +1・entity +13）。 2026-06-10: **LLM アプリケーション失敗モード分類論文（IEEE CAI 2026）を wiki-ingest-paper で取り込み** — [[@2026__IEEE CAI__A System-Level Taxonomy of Failure Modes in Large Language Model Applications]]（[[Vaishali Vinay]]、[[Microsoft]] Security Research、IEEE CAI 2026、DOI:10.1109/CAI68641.2026.11536235）: LLM アプリケーションの隠れた失敗を、推論失敗・入力/コンテキスト失敗・システム/運用失敗の 3 層 15 種に分類。幻覚、論理的不整合、計画崩壊、過信、制約違反、曖昧プロンプト、プロンプトインジェクション、コンテキスト喪失、分布外入力、競合指示、ツール/API エラー、外部ツール失敗、マルチエージェント通信破綻、ビジネスルール不整合、コスト起因劣化を整理する。静的ベンチマークは安定性・再現性・ドリフト・ワークフロー統合を測れず、本番信頼性には入力正規化、検証レイヤー、意味的オブザーバビリティ、バージョン管理、コスト統制が必要だと位置づける。**ページ作成**: source 1（[[@2026__IEEE CAI__A System-Level Taxonomy of Failure Modes in Large Language Model Applications]]）+ entity 1（[[Vaishali Vinay]]）+ concept 1（[[LLMアプリケーション信頼性]]）。**ページ更新**: [[Microsoft]]・[[エージェントシステム運用]]・[[運用障害分析]]・[[LLM推論]]。（source +1・entity +1・concept +1）。 2026-06-10: **Bigtable 20 年経験論文（SIGMOD Companion 2026）を wiki-ingest-paper で取り込み** — [[@2026__SIGMOD Companion__Twenty Years of Bigtable]]（[[Fabio Baltieri]] ほか [[Google]]、SIGMOD Companion 2026、DOI:10.1145/3788853.3803095）: [[Bigtable]] の 20 年にわたる進化を報告する経験論文。2006 年の多次元疎マップ・タブレット・SSTable/メムテーブル・単一行 ACID の中核を維持しつつ、10 EB データ・ピーク 70 億 QPS・単一クラスタ 2.5 億 QPS 超へ拡大。新機能はレプリケーション（複数プライマリ、レプリケーションウォーターマーク、BEAR、プル型 exactly once）、SQL、CDC、カウンタ/CRDT（LSM 層 changelog）、マテリアライズドビュー、外部コンパクション、行キャッシュ、ハイブリッドブルームフィルタ、オートサイジング/オートスケーリング。運用面では 2006 年半ば以降、ユーザー運用から Bigtable SRE チームによる全社サービス運用へ移行し、固定サーバ形状、メタデータ専用パーティション、プローバ、既定バックアップを整備。**ページ作成**: source 1（[[@2026__SIGMOD Companion__Twenty Years of Bigtable]]）+ entity 1（[[Fabio Baltieri]]）。**ページ更新**: [[Bigtable]]・[[Google]]・[[分散ストレージ]]・[[LSMツリー]]・[[データベース O&M]]。（source +1・entity +1）。 2026-06-08: **VictoriaMetrics KubeCon EU 2026 記事を wiki-ingest で取り込み** — [[VictoriaMetrics-KubeCon-EU-2026-Sampling|@2026__VictoriaMetrics Blog__KubeCon EU 2026 Retroactive Sampling]]（[[Zhu Jiekun]]、[[VictoriaMetrics]]、2026-04-16）: [[OpenTelemetry]] エコシステム向けのレトロアクティブサンプリング（[[Retroactive Sampling]]）プロトタイプを解説。エッジエージェントがサンプリング判断用の最小属性（`trace_id` + `start_time` + `end_time` + `status_code` = **33 バイト**）のみ中央コレクタへ送り、生スパンをオンディスク FIFO キューにバッファリング。採択決定後に必要なスパンだけをストレージへ転送する。テールサンプリング比でネットワーク転送量 70%・CPU/メモリ 60–70% 削減。Pebble ベースのディスク型テールサンプリングが CPU を 649% 増加させるのに対し、FIFO の逐次 I/O はランダム I/O を避けてこの問題を回避する。プロトタイプは OpenTelemetry Collector の新プロセッサとして寄贈予定、[[VictoriaTraces]] vtagent に 2026 年下半期に統合予定。起源は NSDI 2023 "The Benefit of Hindsight"（Lei Zhang）。**ページ作成**: source 1（[[VictoriaMetrics-KubeCon-EU-2026-Sampling|@2026__VictoriaMetrics Blog__KubeCon EU 2026 Retroactive Sampling]]）+ entity 2（[[VictoriaTraces]]・[[Zhu Jiekun]]）+ concept 1（[[Retroactive Sampling]]）。**ページ更新**: [[VictoriaMetrics]]・[[OpenTelemetry]]・[[トレースサンプリング]]・[[Scaling Telemetry Workloads]]。（source +1・entity +2・concept +1）。 2026-06-08: **Glenn K. Lockwood ブログ記事（2026-05-08）を wiki-ingest で取り込み** — [[@2026__Glenn K. Lockwood Blog__AI doesnt need giant supercomputers after all]]（[[Glenn K. Lockwood]]、元 Microsoft・現 [[VAST Data]]、2026 Salishan Conference ライトニングトーク）: 「超大規模 AI スーパーコンピュータはもはや不要」論。2023-03 の GPT-4 でスケーリング則が実証された後、2024-05 に [[Microsoft]] が超大規模クラスタを建設したが、そこで訓練された「魔法の」モデルは GPT-4o 比トークン単価推定 15 倍・推論に 120 GPU 必要で経済破綻し 2025-04 に非推奨化・2025-07 にサービス終了。対照的に競合推論モデルが「小規模旧式クラスタ」で同等成果を達成し「スケールより賢さ」パラダイムへの転換が確定した。超大規模クラスタ（[[Microsoft Fairwater]] 450 MW・[[AWS Rainier]] Trainium2 約 50 万枚）の残存価値は「訓練期間短縮による失敗早期検知とリスク低減」であり「パラメータ規模の拡大」ではないと整理。スケールダウンの示唆として共パッケージ光学・KV キャッシュオフロードの優先度低下・線形アテンション台頭を予測。**ページ作成**: source 1（[[@2026__Glenn K. Lockwood Blog__AI doesnt need giant supercomputers after all]]）+ entity 4（[[Glenn K. Lockwood]]・[[VAST Data]]・[[Microsoft Fairwater]]・[[AWS Rainier]]）。**ページ更新**: [[LLMスケーリング則]]（フロンティアでのスケーリング失敗事例・アルゴリズム代替の問いを横断的知見・未解決の問いに追加）・[[LLM分散学習]]（超大規模 vs 中規模クラスタのトレードオフ経済合理性を横断的知見・未解決の問いに追加）・[[Microsoft]]（Fairwater 追記）・[[OpenAI]]（超大規模モデル失敗経緯追記）。（source +1・entity +4）。 2026-06-08: **GPU プログラミング最適化 CSUR 論文（Hijma ほか 2023）を wiki-ingest-paper で取り込み** — [[@2023__CSUR__Optimization Techniques for GPU Programming]]（[[Pieter Hijma]]・[[Stijn Heldens]]・[[Ben van Werkhoven]]・[[Henri E. Bal]]・[[Alessio Sclocco]]、[[Vrije Universiteit Amsterdam]]・[[Netherlands eScience Center]]、ACM Computing Surveys 2023、DOI:10.1145/3570638）: 2012〜2021 年の Scopus 論文 450 本を体系的に収集・分類した GPU プログラミング最適化サーベイ。(1) **メモリアクセス**: [[コアレスドメモリアクセス]]（全論文中最多採用）・専用メモリ・レジスタブロッキング・[[カーネルフュージョン]]・空間ブロッキングほか 11 技術。(2) **不規則性**: [[分岐発散]]削減（3 位）・ループアンローリング・疎行列フォーマットほか 5 技術。(3) **バランシング**: [[Auto-tuning]]（1/8 超が採用）・ベクトル化・負荷分散ほか 10 技術。(4) **ホストインタラクション**: ホスト通信・CPU/GPU 分担の 2 技術。主要発見: 採用頻度トップ 4 はコアレスドアクセス・専用メモリ・分岐発散削減・auto-tuning; 最適化は単独でなく連鎖して効果を発揮; アーキテクチャ世代（Fermi/Maxwell/Volta/Turing）で各技術の効果が大きく変化; LLM 時代の Flash Attention・Paged Attention はカーネルフュージョン・シェアードメモリ・Tensor Core の直接応用（ただし本論文は 2021 年以前対象）。**ページ作成**: source 1（[[@2023__CSUR__Optimization Techniques for GPU Programming]]）+ entity 7（[[Pieter Hijma]]・[[Stijn Heldens]]・[[Ben van Werkhoven]]・[[Henri E. Bal]]・[[Alessio Sclocco]]・[[Vrije Universiteit Amsterdam]]・[[Netherlands eScience Center]]）+ concept 5（[[GPU最適化]]・[[コアレスドメモリアクセス]]・[[カーネルフュージョン]]・[[分岐発散]]・[[Auto-tuning]]）。（source +1・entity +7・concept +5）。 2026-06-08: **Anthropic Engineering Blog ポストモーテム（2025-09-17）を wiki-ingest で取り込み** — [[@2025__Anthropic Engineering Blog__A Postmortem of Three Recent Issues]]（[[Anthropic]] Engineering チーム、2025-09-17）: 2025 年 8 月〜9 月に Claude の応答品質を劣化させた 3 件の本番インフラ障害を詳述。(1) **コンテキストウィンドウルーティングエラー**（Sonnet 4 へのピーク 16% 影響、2025-08-05〜09-04）: 短いコンテキストのリクエストが 1M トークンサーバーに誤ルーティング、スティッキーなルーティングにより会話全体が継続的に劣化。(2) **TPU サーバー誤設定による出力破壊**（英語プロンプトへの応答にタイ語・中国語文字の混入、Opus/Sonnet 系、2025-08-25〜09-02）。(3) **XLA:TPU コンパイラの混合精度演算バグ**（近似 top-k vs 厳密 top-k の確率不一致、Haiku 3.5 等、2025-08-25〜）。構造的課題として「内部評価はユーザー体験の品質劣化をキャプチャできない（評価カバレッジ問題）」「プライバシー保護が診断速度を低下させる（プライバシー vs 可観測性のトレードオフ）」を明示。**ページ作成**: source 1（[[@2025__Anthropic Engineering Blog__A Postmortem of Three Recent Issues]]）+ entity 1（[[Anthropic]]）。**ページ更新**: [[LLM推論]]（3 層障害類型・近似/厳密 top-k の精度問題を横断的知見に追加）・[[運用障害分析]]（GenAI 固有のプライバシー制約と評価カバレッジ問題を横断的知見に追加）。（source +1・entity +1）。 2026-06-08: **UModel（arXiv:2606.04799）を wiki-ingest-paper で取り込み** — [[@2026__arXiv__UModel - An Agent-Ready Observability Data Modeling Method at Scale]]（[[Changhua Pei]]・[[Gaogang Xie]]・[[Dan Pei]] ほか CNIC/CAS・UCAS・[[Alibaba Cloud]]・Tsinghua University、arXiv:2606.04799v1、2026-06-03）: オブザーバビリティの 4 ギャップ（死んだトークン・孤立イベント・ツール欠如・サイロ）を「オブジェクト中心モデリング」で解消する統一オントロジーフレームワーク [[UModel]] と、Unix パイプ発想のパイプライン型クエリ言語 U-SPL（USearch + GSearch + MetaSearch）を提案。[[Alibaba Cloud]] 本番 1 年以上・数万ユーザー・10M ops/秒・サブ秒クエリを達成し、2025 AIOps Challenge データセットで従来データモデル比 RCA 精度 8% 向上（Top-1 Acc 68.12→74.64）。PaaS 意味的ツール層は IaaS 直接 U-SPL に対して OS +9〜+13 ポイント優位（5 フレームワーク×3 評価セットで一貫）。LLM PromQL 生成精度が <5% にとどまるという構造的限界の解決策として、エージェント対応データモデルという概念を大規模本番で実証した最初の論文。**ページ作成**: source 1（[[@2026__arXiv__UModel...]]）+ entity 2（[[Gaogang Xie]]・[[UModel]]）+ concept 1（[[オブザーバビリティデータモデル]]）。**ページ更新**: [[Changhua Pei]]・[[Dan Pei]]・[[Alibaba Cloud]]（stub → 実ページ）・[[根本原因分析]]・[[AIOps]]・[[テレメトリ]]（横断的知見・未解決の問いを追加）。（source +1・entity +2・concept +1）。 2026-06-08: **応用物理誌基礎講座（赤穂昭太郎・AIST）を wiki-ingest-paper で取り込み** — [[@2026__応用物理__機械学習の原点 - 統計的機械学習の世界]]（[[赤穂昭太郎]]、産総研、応用物理 Vol.95 No.5 pp.274-279, 2026-05）: 応用物理研究者向けの統計的機械学習入門。深層学習が万能でない理由（少量データ・解釈性要求・ドメイン知識活用）を整理し、線形モデル・スパースモデリング（LASSO・リッジ）・k-NN・アンサンブル学習（ランダムフォレスト・XGBoost）・ベイズモデリング・ベイズ最適化を概説。MAP 推定とリッジ/LASSO 回帰の同値性（ガウス/ラプラス事前分布）という AIOps ドメインとは異なる切り口の横断知識を追加。**ページ作成**: source 1（[[@2026__応用物理__機械学習の原点 - 統計的機械学習の世界]]）+ entity 2（[[赤穂昭太郎]]・[[産業技術総合研究所]]）+ concept 3（[[統計的機械学習]]・[[ベイズ最適化]]・[[アンサンブル学習]]）。（source +1・entity +2・concept +3）。 2026-06-08: **XWind（arXiv:2605.23348）を wiki-ingest-paper で取り込み** — [[@2026__arXiv__XWind - A Cross-site Router for Large Language Model Inference Serving at Renewable Energy Farms]]（[[Debopam Bhattacherjee]] ほか [[Microsoft]]、arXiv:2605.23348v1、2026-05-22）: AI 推論需要の急増と電力網の逼迫を背景に、風力発電サイトに GPU を直接配置する [[AI Greenferencing]] 展開モデルを提案し、可変電力下で LLM 推論 SLO を維持する [[XWind]] ルーターを設計・実装。890 GW 超の風力容量が Azure データセンターから 50ms RTT 以内（73% が 20ms 以内）に存在することを実証し、P20 サイジングで 1000 万台超の H100 相当を展開可能と推計。XW-Slc はアクティブノード数と GPU 周波数のデュアルノブをリアルタイムテレメトリ（KV キャッシュ利用率[先行指標]+TBT[遅行指標]+キュー深度）で制御する反応型アルゴリズムを採用。64 × A100 テストベッドで Max-FLOPS に対し会話ワークロードで P99 E2E 52% 削減、静的ルーティング比 69× 改善を達成。**ページ作成**: source 1（[[@2026__arXiv__XWind...]]）+ entity 2（[[XWind]]・[[Debopam Bhattacherjee]]）+ concept 1（[[AI Greenferencing]]）。**ページ更新**: [[LLM推論]]（可変電力下 KV キャッシュ先行指標性・電力/性能統合制御の横断的知見と未解決の問い追加）・[[Microsoft]]（XWind/Greenferencing 関連追記）。（source +1・entity +2・concept +1）。 2026-06-08: **LinkedIn 記事（Ravi Sharma 著）を wiki-ingest で取り込み** — [[@2026__LinkedIn__Resilient AI Supercomputer Networking - How MRC and SRv6 Keep 100,000+ GPUs Training]]（[[Ravi Sharma]]、2026-05-28）: [[OpenAI]] の研究成果に基づく解説記事。10 万 GPU 超クラスタの訓練継続性を実現する 3 技術——[[MRC]]（Multipath RC、RC トランスポートをパケット粒度スプレーに拡張）・[[マルチプレーンClosトポロジ]]（800G NIC を 8×100G 独立プレーンに分割、スイッチ 2 段で 131k GPU 超）・[[SRv6]]（パケットに経路埋め込み、動的再計算不要）——を解説。設計哲学は「検知・修復・再開」から「検知・回避・回復」へのシフトで、障害を例外でなく通常事象として扱う。本番でトランシーバー障害・スイッチ再起動中も訓練継続を実証。**ページ作成**: source 1（[[@2026__LinkedIn__Resilient AI Supercomputer Networking...]]）+ entity 1（[[Ravi Sharma]]）+ concept 3（[[MRC]]・[[SRv6]]・[[マルチプレーンClosトポロジ]]）。**ページ更新**: [[RDMA]]（MRC 横断的知見追加・未解決の問い追加）・[[OpenAI]]（インフラ・ネットワーキング研究セクション追加）。（source +1・entity +1・concept +3）。 2026-06-07: **Bian Que（arXiv:2604.26805）を wiki-ingest-paper で取り込み** — [[@2026__arXiv__Bian Que - An Agentic Framework with Flexible Skill Arrangement for Online System Operations]]（[[Bochao Liu]] ほか [[Kuaishou Technology]]、arXiv:2604.26805v2、2026-05-10）: 大規模オンラインエンジン系 O&M の LLM ボトルネックを推論でなくオーケストレーション(適切なデータ・知識の選択)と特定し、[[Flexible Skill Arrangement]](Skill = LoadDataSchema + Prompt + Meta)・統一運用パラダイム(リリース遮断・積極的点検・アラート RCA)・統一自己進化メカニズム(1 フィードバック → 知識蒸留+Skill 精緻化)の 3 要素でフレームワーク構築。KuaiShou EC 検索エンジン 6 ヶ月本番でアラート量 75% 削減・非アクション可能アラート絶対量 ~95% 削減・RCA 精度 80%・MTTR 50% 以上圧縮・オフライン pass@5 = 99.0% を達成。NOKNOW アブレーション(知識無効 −7.7 pp)・STATIC アブレーション(静的スキル −10.5 pp)でフレキシブルスキルと知識の両方が不可欠と確認。**ページ作成**: source 1（[[@2026__arXiv__Bian Que...]]）+ entity 4（[[Kuaishou Technology]]・[[Bian Que]]・[[Bochao Liu]]・[[Ben Chen]]）+ concept 1（[[Flexible Skill Arrangement]]）。**ページ更新**: [[AIOps]]（産業実証・事前対応 O&M 横断的知見 2 点・未解決の問い 1 点追加）・[[エージェントシステム運用]]（AgenticOps 産業実証・未解決の問い 1 点追加）・[[根本原因分析]]（事前コンテキスト制御による入力選別の構造解法横断的知見追加）・[[インシデント管理]]（統一パラダイムのアラート前後カバレッジ横断的知見追加）。（source +1・entity +4・concept +1）。 2026-06-07: **NexusRCL（arXiv:2604.26670）を wiki-ingest-paper で取り込み** — [[@2026__arXiv__Which Types of Heterogeneity Matter for Root Cause Localization in Microservice Systems]]（[[Runzhou Wang]]・[[Shenglin Zhang]]・[[Dan Pei]] ほか [[Nankai University]]・[[Tsinghua University]]、arXiv:2604.26670v1、2026-04-29）: マイクロサービス RCL においてエンティティレベル異質性（サービス vs ホスト）が精度を律速することを実証し、層対応の異種グラフモデル [[NexusRCL]] を提案。設計の核心は 2 要素——(1) Layer-Aware Heterogeneous Graph Modeling: サービスノード・ホストノード・有向 $E_{SS}$/$E_{SH}$・無向 $E_{HH}$ の 4 エッジタイプで非対称クロスレイヤー伝播を明示的にモデル化、n-σ メトリクス異常・SentenceTransformer+DBSCAN ログクラスタリング・トポロジー変更の 3 イベントで融合、冗長エッジ削減で 50.6% ノイズ削減；(2) Semi-Supervised Active Learning: HGCN 埋め込みの DBSCAN クラスタリング→メドイドラベリング→疑似ラベル伝播→境界/ノイズ精錬の 4 ステップで少量ラベルを最大活用。評価では HD1(A@1 86.25%)・HD2(A@1 75.00%)で 5 ベースライン全超、均質グラフ変種（Variant C）と比較して HD1 で +30.65pt・HD2 で +51.60pt の A@1 改善。障害の 77〜82% がクロスレイヤー（サービス→ホスト）伝播であることもデータで示した。**ページ作成**: source 1（[[@2026__arXiv__Which Types of Heterogeneity Matter for Root Cause Localization in Microservice Systems]]）+ entity 2（[[Runzhou Wang]]・[[NexusRCL]]）。**ページ更新**: [[Dan Pei]]・[[Shenglin Zhang]]・[[Nankai University]]・[[Fault Localization]]（entity-level 異質性の横断的知見 2 点・未解決の問い 2 点追加）。（source +1・entity +2）。 2026-06-07: **SPRINT（ICML 2026）を wiki-ingest-paper で取り込み** — [[@2026__ICML__See More, Forecast Better and Faster - Enhancing Time Series Foundation Models via Inference-Time Plug-and-Play Downsampling]]（[[Longlong Xu]] ほか [[Tsinghua University]]・[[ByteDance]]・CNIC CAS、ICML 2026、PMLR 306）: 時系列基盤モデル(TSFM)の推論時スケーラビリティ限界を、学習不要のダウンサンプリングフレームワーク [[SPRINT]] で突破。時系列をトレンド(移動平均)と季節成分に分解し、トレンドを Resolution Interpolation（ダウンサンプリング→TSFM→スプライン補間）、季節性を Pattern Replication（指数加重周期パターン複製）で個別処理。9 データセット・7 TSFM の平均で精度 +19%、最大メモリ 6.35 倍削減、推論速度 16.87 倍改善を達成。Timer は L>720 で NaN になっていたが SPRINT で L=5760 まで安定動作。理論根拠は Nyquist-Shannon 定理（低周波トレンドの無損失再構築）と AR(1) 保存性（Proposition 4.1）。**ページ作成**: source 1（[[@2026__ICML__...]]）+ entity 3（[[Longlong Xu]]・[[Zeyan Li]]・[[SPRINT]]）。**ページ更新**: [[時系列基盤モデル]]（「推論時ラッパー路線」「季節性外部複製」「VisionTS 例外」を横断的知見に追加、新 2 問を未解決の問いに追加）・[[Dan Pei]]・[[Changhua Pei]]。（source +1・entity +3）。 2026-06-07: **ChainScope（ACM CoNEXT 2026）を wiki-ingest-paper で取り込み** — [[@2026__CoNEXT__ChainScope - Balancing Accuracy and Overhead in Non-intrusive Distributed Tracing of Microservices]]（[[Ruipeng Hong]] ほか [[Sun Yat-sen University]]・[[Huawei Technologies]]、ACM CoNEXT 2026、DOI: 10.1145/3808662）: eBPF カーネル内の IP レベルタギングとヘッドサンプリングで「非侵襲・高カバレッジ・低オーバーヘッド・高精度」の 4 目標を同時達成する分散トレーシングシステム。設計の核心は 4 選択——(1) 明示的コンテキスト伝搬（TCP オプションへの TraceID 埋め込み）で TLS を透過、(2) eBPF カーネル内ヘッドサンプリングで実行パス全域を一貫してフィルタ、(3) サービス内伝搬を実行完了モデル（単一ペンディング TraceID）と FIFO+epoll 拡張の 2 機構でカバー、(4) OTLP コレクターがトレースを再構築。評価では [[DeepFlow]]（21% 精度）・[[Beyla]]（90% 精度）に対して 100% の精度、1% サンプリング時の性能損失 <4%、CPU 使用率 2〜3%（競合比 100〜200%）、複雑なシナリオでの精度 2.2 倍・スループット 1.6 倍を達成。**ページ作成**: source 1（[[@2026__CoNEXT__ChainScope...]]）+ entity 3（[[Ruipeng Hong]]・[[Gabriele Castellano]]・[[Massimo Gallo]]）。**ページ更新**: [[Pengfei Chen]]・[[分散トレーシング]]（eBPF 明示的伝搬＋ヘッドサンプリングの設計空間を横断的知見に追加）・[[eBPF]]（最小限プローブ＋カーネル内サンプリング設計を横断的知見に追加）。（source +1・entity +3）。 2026-06-07: **SRE Workbook 17 章を subagent 並行で wiki-ingest** — [[SRE Workbook]]（Google/O'Reilly, 2018）の Foreword I/II、Ch1〜10 のうち指定 10 章、結論、付録 A/B/C を 4 subagent で並行取得・下書き化し、17 source を wiki に統合。**ページ作成**: source 17（[[@2018__Google SRE Workbook__Foreword I]] / [[@2018__Google SRE Workbook__Foreword II]] / [[@2018__Google SRE Workbook__Chapter 1 How SRE Relates to DevOps]] / [[@2018__Google SRE Workbook__Chapter 2 Implementing SLOs]] / [[@2018__Google SRE Workbook__SLO Engineering Case Studies]] / [[@2018__Google SRE Workbook__Monitoring]] / [[@2018__Google SRE Workbook__Alerting on SLOs]] / [[@2018__Google SRE Workbook__Eliminating Toil]] / [[@2018__Google SRE Workbook__Simplicity]] / [[@2018__Google SRE Workbook__Part II Practices]] / [[@2018__Google SRE Workbook__On-Call]] / [[@2018__Google SRE Workbook__Incident Response]] / [[@2018__Google SRE Workbook__Chapter 10 Postmortem Culture - Learning from Failure]] / [[@2018__Google SRE Workbook__Conclusion]] / [[@2018__Google SRE Workbook__Appendix A Example SLO Document]] / [[@2018__Google SRE Workbook__Appendix B Example Error Budget Policy]] / [[@2018__Google SRE Workbook__Appendix C Results of Postmortem Analysis]]）+ entity 1（[[SRE Workbook]]）。**ページ更新**: [[SRE Book]]・[[SRE]]・[[サービスレベル目標]]・[[エラーバジェット]]・[[トイル]]・[[テレメトリ]]・[[インシデント管理]]・[[index]]・[[log]]・[[hot]]。**横断的知見**: SRE Book が定義した SLO/エラーバジェット/トイル/インシデント管理を、Workbook は文書、方針、アラート、訓練、ポストモーテムテンプレートへ落とす。SLO は「良いイベント数 / 全イベント数」の SLI 仕様と実装に分かれ、エラーバジェットはバーン率アラートと変更停止方針へ接続し、インシデント管理は IC/CL/OL とポストモーテム文化の実務に展開する。（source +17・entity +1） 2026-06-07: **Transformer / GPT 基盤 4 論文を一括 wiki-ingest-paper で取り込み** — Transformer アーキテクチャの提案から GPT-3 までの知的系譜を形成する基盤論文 4 本を並行サブエージェントで wiki に取り込み。(1) [[@2017__NeurIPS__Attention Is All You Need]]（[[Ashish Vaswani]]・[[Noam Shazeer]] ほか [[Google Brain]]、NeurIPS 2017）: 再帰・畳み込みを排し自己アテンションのみで系列変換を実現する [[Transformer]] を提案。Scaled Dot-Product Attention、Multi-Head Attention、正弦波位置エンコーディングの 3 要素で構成。WMT 2014 英独 BLEU 28.4、英仏 BLEU 41.8。(2) [[@2018__OpenAI__Improving Language Understanding by Generative Pre-Training]]（[[Alec Radford]]・[[Ilya Sutskever]] ほか [[OpenAI]]、2018）: Transformer デコーダによる教師なし事前学習＋教師あり微調整の二段階パラダイム（GPT-1）を確立。12 タスク中 9 で SOTA。(3) [[@2019__OpenAI__Language Models are Unsupervised Multitask Learners]]（[[Alec Radford]]・[[Jeffrey Wu]] ほか [[OpenAI]]、2019）: 1.5B パラメータの [[GPT-2]] がゼロショットで 8 データセット中 7 で SOTA。規模と性能の対数線形関係を実証。(4) [[@2020__NeurIPS__Language Models are Few-Shot Learners]]（[[Tom Brown]]・[[Jared Kaplan]] ほか [[OpenAI]]、NeurIPS 2020）: 175B パラメータの [[GPT-3]] が[[文脈内学習]]により微調整なしで 42 以上の NLP タスクで競争力ある性能を達成。**ページ作成**: source 4 + entity 22 + concept 3（[[Transformer]]・[[言語モデル事前学習]]・[[文脈内学習]]）。**ページ更新**: [[LLMスケーリング則]]（GPT-2/3 のスケーリング観察追加）・[[OpenAI]]・[[Alec Radford]]・[[Ilya Sutskever]]・[[Dario Amodei]]。**横断的知見**: (1) GPT-1→GPT-2→GPT-3 でパラダイムが「事前学習＋微調整」→「ゼロショット転移」→「文脈内学習（few-shot）」へ発展し、Transformer のデコーダ部分だけで 3 桁のパラメータ拡大をアーキテクチャ変更なしに吸収した。(2) GPT-2 がゼロショット性能の対数線形スケーリングを、GPT-3 が 8 モデルサイズでの滑らかなスケーリングを示し、後の [[LLMスケーリング則]] 研究の実験的基盤を提供した。（source +4・entity +22・concept +3）。 2026-06-06: **OLTP through the looking glass（SIGMOD 2008）を wiki-ingest-paper で取り込み** — [[@2008__SIGMOD__OLTP through the looking glass, and what we found there]]（[[Stavros Harizopoulos]]（HP Labs）・[[Daniel J. Abadi]]（Yale）・[[Samuel Madden]]（MIT）・[[Michael Stonebraker]]（MIT）、SIGMOD 2008）: [[Shore RDBMS|Shore]]（Wisconsin 製永続オブジェクトストア）を TPC-C（New Order + Payment）で段階的に改変し、PAPI 命令数プロファイリングで 4 コンポーネント（バッファマネージャ・ロック・ログ・ラッチ）の命令数内訳を精密計測。New Order では BufferMgr 34.6%・Lock 16.3%・Log 11.9%・Latch 14.2%（合計 77%）、Payment では BufferMgr 29.8%・Lock 25.2%・Log 17.7%・Latch 12.6%（合計 85.3%）が「有用でない」オーバーヘッドと判定。4 コンポーネント全除去で 640 TPS → 12,700 TPS（約 20 倍）、最適カーネルで 46,500 TPS を実現。中心知見は「高い杭は存在しない（no single high pole in the tent）」——4 コンポーネントがほぼ均等に支配しているため、個別除去だけでは不十分でアーキテクチャ全体の再設計が必要。メモリ常駐のみでは 2.7 倍にとどまり、H-Store が提案する全面的再設計の必要性を定量的に裏付けた。本論文は 2007 年 VLDB の H-Store アーキテクチャ提案の「測定による検証編」として位置付けられる。**ページ作成**: source 1([[@2008__SIGMOD__OLTP through the looking glass, and what we found there]]) + concept 2([[OLTPシステムアーキテクチャ]]・[[メインメモリデータベース]])。**ページ更新**: [[Stavros Harizopoulos]]（HP Labs 所属・SIGMOD 2008 筆頭著者として更新）・[[Daniel J. Abadi]]（sources 追加）・[[Michael Stonebraker]]（sources 追加）・[[Samuel Madden]]（sources 追加）。（source +1・concept +2）。 2026-06-06: **SRE Book Ch10-18, 28-33（15 章）を統合** — [[SRE Book]]（O'Reilly, 2016）の Practices 9 章（Ch10-18）と Management 6 章（Ch28-33）を wiki に統合。15 のソースページは既に作成済みで、本作業では [[SRE]]・[[SRE Book]]・[[インシデント管理]]・[[テレメトリ]]・[[障害緩和]]・[[根本原因分析]]・[[異常検知]]・[[障害注入]] の 8 ページを更新。主要な横断的知見: (1) Borgmon→Prometheus の宣言型ルール評価の系譜、(2) ICS 4 役割がマルチエージェント SRE（[[Stratus]]・[[OpsAgent]]）の役割設計と構造的に対応、(3) 仮説演繹法が hypothesis-driven RCA（[[Bits AI SRE]]）の直接の前史、(4) ブレームレスポストモーテムが LLM 生成 RCA レポートの「非難なき説明」の思想的基盤、(5) Auxon の意図ベースキャパシティプランニングが agentic SRE の先駆、(6) 航空・医療・製造業の教訓が業界横断で有効。未解決の問い 6 件追加（仮説演繹法の LLM エージェントへの翻案、マルチエージェントのフリーランシング問題、LLM ポストモーテムのバイアス、フレームワーク化の不可逆性、他業界教訓の適用限界）。（source +15・pages updated 8） 2026-06-06: **[[Yuuki Tsubouchi]] の SRE NEXT 2024 登壇報告を wiki-ingest で取り込み** — [[@2024__yuuk.io__SRE-NEXT-2024]]（ゆううきブログ 2024-08-08）: 博士課程4年半の成果の集大成として「工学としてのSRE再訪」を [[SRE NEXT]] 2024 で発表しベストスピーカー賞受賞。SRE を「信頼性を指定可能なパラメータに制御する工学」と再定義し、(1)オオカミ少年アラート問題、(2)トレースデータ未活用、(3)インシデント対応改善不全、(4)SLOの多目的活用、(5)インシデント対応のソフトウェア化、(6)SLOからのアーキテクチャ導出、という6つのオープンチャレンジを提示。[[プラットフォームエンジニアリング]]が SRE・共通基盤・ITインフラの役割境界を明確化したという重要な観察も含む。JAXAによる[[JAXA|宇宙探査機(SLIM)へのSRE実践]]も注目セッション（帯域制限により分散トレースが不適という逆境知見）。**ページ作成**: source 1([[@2024__yuuk.io__SRE-NEXT-2024]]) + entity 2([[SRE NEXT]]・[[JAXA]]) + concept 1([[プラットフォームエンジニアリング]])。**ページ更新**: [[Yuuki Tsubouchi]](登壇実績追記)・[[SRE]](source 追加)。（source +1・entity +2・concept +1）。 2026-06-06: **Avizienis ら(2004)の依存性タクソノミー論文を wiki-ingest-paper で取り込み** — [[@2004__TDSC__Basic Concepts and Taxonomy of Dependable and Secure Computing]](IEEE TDSC 創刊号, Avizienis/Laprie/Randell/Landwehr): [[IFIP WG 10.4]] が 25 年間で積み上げたディペンダビリティとセキュリティの概念タクソノミーの集大成。ディペンダビリティを「正当に信頼できるサービスを提供する能力」と形式化し、可用性・信頼性・安全性・完全性・保守性の 5 属性(セキュリティ固有の機密性を加え 6 属性)を統一的に定義。障害(fault)→エラー(error)→失敗(failure)の「基本連鎖」を確立し、8 視点×31 複合障害クラスのタクソノミー、4 達成手段(障害防止/フォールトトレランス/障害除去/障害予測)の体系を整備。信頼(trust)= 受け入れられた依存関係という形式的定義も導入。本 wiki の [[SRE]]・[[障害緩和]]・[[ソフトウェア耐障害性]] の概念的基盤として初収録。**ページ作成**: source 1 + entity 6([[Algirdas Avizienis]]・[[Jean-Claude Laprie]]・[[Brian Randell]]・[[Carl Landwehr]]・[[LAAS-CNRS]]・[[IFIP WG 10.4]]) + concept 1([[ディペンダビリティ]])。**ページ更新**: [[ソフトウェア耐障害性]](Gray 1985 との横断知見追加: Heisenbug ≈ 断続的障害、プロセスペア ≈ ロールバック)。 2026-06-06: **DeepSeek ファミリー 7 論文を一括 wiki-ingest-paper で取り込み** — DeepSeek-AI の主要モデルファミリー全 7 論文を 7 サブエージェント並行で wiki に取り込み。(1) [[@2024__arXiv__DeepSeek LLM - Scaling Open-Source Language Models with Longtermism]]: 初代基盤モデル(7B/67B dense)、非埋め込み FLOPS/トークン M によるスケーリング則。(2) [[@2024__arXiv__DeepSeek-Coder - When the Large Language Model Meets Programming]]: コード特化 LLM、FIM 最適化で 6.7B が CodeLlama-34B を凌駕。(3) [[@2024__arXiv__DeepSeek-V3 Technical Report]]: 671B MoE、MLA・補助損失なし負荷分散・MTP・FP8・DualPipe で約 557 万ドル訓練。(4) [[@2025__arXiv__DeepSeek-R1 - Incentivizing Reasoning Capability in LLMs via Reinforcement Learning]]: SFT なし純粋 RL で推論能力創発、GRPO + 規則ベース報酬のみで aha モーメント、4 段パイプラインで $294K。(5) [[@2025__arXiv__DeepSeek-V3.2 - Pushing the Frontier of Open Large Language Models]]: DSA・GRPO 4 安定化技術・1,800+ 合成エージェント環境で事後学習コストを事前学習 10% 超に。(6) [[@2024__arXiv__DeepSeek-VL2 - Mixture-of-Experts Vision-Language Models for Advanced Multimodal Understanding]]: MoE ベース VLM、活性化 4.5B で密モデル 8B 級。(7) [[@2025__DeepSeek__DeepSeek-V4 - Towards Highly Efficient Million-Token Context Intelligence]]: MegaMoE・CSA+HCA ハイブリッド圧縮（KV キャッシュ BF16 GQA8 比約 2%）で 100 万トークン。**ページ作成**: source 7 + entity 14 + concept 4。**ページ更新**: [[Mixture-of-Experts]]・[[LLM分散学習]]・[[並列化戦略]]・[[強化ファインチューニング]]・[[強化学習スケーリング]]・[[テスト時計算スケーリング]]・[[LLM推論]]・[[エージェント型コーディング]]・[[オープンLLM開発]]・[[GRPO]]。**横断的知見**: DeepSeek ファミリーの 3 軸進化——MoE アーキテクチャ（DeepSeekMoE → 補助損失なし → シグモイドゲーティング → MegaMoE）、RL 手法（GRPO → R1-Zero 純粋 RL 創発 → V3.2 の 4 安定化）、効率化（MLA KV 圧縮 → FP8 → DualPipe → CSA+HCA ハイブリッド圧縮）。特に V4 の KV キャッシュ約 2% 削減は 100 万トークンコンテキストの構造的解法。（source +7・entity +14・concept +4）。 2026-06-06: **[[Yuuki Tsubouchi]] のサーバーレスアーキテクチャ再考記事を wiki-ingest で取り込み** — [[@2019__yuuk.io__Rethinking-Serverless-Architecture]]（ゆううきブログ 2019-09-11）: AWS Lambda 登場から 5 年後、自身の HeteroTSDB 開発経験（2016〜2018 年）と論文化を踏まえた「サーバーレスとは何か」の再考察。サーバーレスの本質を「サーバという単位を意識しない」と定義し直し、FaaS がネットワークサーバーを・BaaS がマシンサーバーを意識しなくさせるという構造を明確化。FaaS を糊として BaaS を連結する「ピタゴラスイッチ構成」（DynamoDB TTL イベント → Lambda → S3）を著者の TSDB 実装で例示。CGI との本質的差異（BaaS 不在・HTTP 限定・密結合スケール）を論じ、ベンダー非依存化への関心（Knative・OpenFaaS・CloudEvents）を示す。同期リクエスト時の I/O ブロッキングによるメモリ効率劣化が制約として指摘される。**ページ作成**: source 1（[[@2019__yuuk.io__Rethinking-Serverless-Architecture]]）+ concept 1（[[サーバーレスアーキテクチャ]]）。**ページ更新**: [[Yuuki Tsubouchi]]（サーバーレス記事追記）。**位置づけ**: 著者のクラウドアーキテクチャ思想の一次資料。[[インターネットスケールサービス設計]]（Hamilton 2007）との接続：Hamilton が「すべてを自動化」「単純さ」と抽象化の方向性を示し、サーバーレスはそれをクラウド BaaS + FaaS で具体化した形として読める。また FaaS のピタゴラスイッチ構成は LLM エージェントの「ツール呼び出し連鎖」と構造的に相似する可能性がある（エージェント → ツール API（BaaS 相当）→ 結果 → 次エージェント）。（source +1・concept +1）。 2026-06-06: **[[Yuuki Tsubouchi]] の 2019 年 SRE 考察記事を wiki-ingest で取り込み** — [[@2019__yuuk.io__2019-SRE-Thinking]]（ゆううきブログ 2019-01-16）: Hatena SRE 時代（2013〜2018）の実践を踏まえた著者の SRE 考察。SRE を「サイト信頼性を**制御する**ための技術」と再定義——「向上」ではなく「制御」という語が、意図的な維持・低下を含む能動的な設計パラメータとしての信頼性観を表す。信頼性・変更速度・コストの三つどもえ、SLI/SLO による定量化、「技芸（Craft）から工学（Engineering）へ」の転換テーゼ、モニタリングの基盤性を論じる。Mercari が 2015 年に SRE チームを発足させた事実が著者の SRE への関心の起点であり、SRE Book 日本語版（2017）以前から日本のウェブ企業が SRE を実践していたことを示す一次資料的証言。[[@2024__yuuk.io__The-World-of-LLM4SRE]]（2024）へ続く著者自身の SRE 思想の縦軸：技芸→工学（2019）→エージェント化（2024）。**ページ作成**: source 1（[[@2019__yuuk.io__2019-SRE-Thinking]]）。**ページ更新**: [[Yuuki Tsubouchi]]（2019 年記事追記）・[[SRE]]（「制御」フレームの横断的知見追加）。（source +1）。 2026-06-06: **マイクロサービス信頼性・可観測性の 9 論文を一括 wiki-ingest-paper で取り込み** — Alibaba・Microsoft・Uber・Meta・Google の本番データに基づくマイクロサービスの依存関係分析・インシデント管理・分散トレーシング・RCA・RPC 特性に関する 9 本の論文を並行サブエージェントで取り込み。(1) [[@2021__SoCC__Characterizing Microservice Dependency and Performance]]（[[Shutian Luo]] ほか [[SIAT]]/[[Alibaba Group]]、SoCC 2021）: Alibaba の 20,000 マイクロサービスのトレース分析。コールグラフがヘビーテール分布に従いツリー状に展開すること、レイテンシの 4 パターン（平坦・増加・スパイク・周期）を定量化。(2) [[@2022__SoCC__How to Fight Production Incidents]]（[[Supriyo Ghosh]] ほか [[Microsoft]]、SoCC 2022）: [[Microsoft Teams]] 等の 152 件高重篤インシデントを分析。コード/設定バグが 40%、90% 超がコード変更なしで緩和（ロールバック・インフラ変更）、MTTR 中央値 113 分、認知時間が MTTR の 72.5%。(3) [[@2024__PACMCAS__The Tale of Errors in Microservices]]（[[I-Ting Angelina Lee]]・[[Zhizhou Zhang]]・[[Milind Chabbi]]、PACM CAS 2024）: [[Uber]] の 6,000 超マイクロサービスの RPC エラー分析。エラーの 29.35% が非致命的でエンドユーザーに影響なし、クリティカルパス分析と LR Estimator による優先順位付けを提案。(4) [[@2023__USENIX ATC__Lifting the veil on Meta's microservice architecture]]（[[Darby Huye]]・[[Yuri Shkuro]]・[[Raja R. Sambasivan]]、ATC 2023）: [[Meta]] のマイクロサービストポロジの初公開分析。22 か月で 2 倍成長、「不適合」エンティティの存在、[[Canopy]] トレーシング基盤。(5) [[@2024__KDD__Microservice Root Cause Analysis with Limited Observability]]（[[Zhe Xie]] ほか [[Tsinghua University]]、KDD 2024）: 限定観測可能性下の RCA 手法 [[LatentScope]]。介入認識モジュールで因果推論を潜在空間上に持ち込む。(6) [[@2023__SIGCOMM__Network-Centric Distributed Tracing with DeepFlow]]（[[Junxian Shen]] ほか [[Tsinghua University]]/[[Yunshan Networks]]、SIGCOMM 2023）: eBPF ベースのネットワーク中心トレーシング [[DeepFlow]]。コード修正ゼロ・暗黙のコンテキスト伝搬（TCP シーケンス番号）で分散トレースを実現。(7) [[@2021__ESEC-FSE__Identifying Bad Software Changes via Multimodal Anomaly Detection]]（[[Nengwen Zhao]] ほか [[Tsinghua University]]/[[China Guangfa Bank]]、ESEC/FSE 2021）: マルチモーダル LSTM による不正変更検出 [[SCWarn]]。ビジネス KPI・マシン KPI・ログの中間融合で F1 0.95。(8) [[@2022__USENIX ATC__CRISP - Critical Path Analysis of Large-Scale Microservice Architectures]]（[[Zhizhou Zhang]]・[[Milind Chabbi]] ほか、ATC 2022）: [[Uber]] の 4 万エンドポイントに実投入したクリティカルパス分析 [[CRISP]]。訓練 27.77 倍・推論 66.85 倍高速化、偽陽性 50% 削減。(9) [[@2023__SOSP__A Cloud-Scale Characterization of Remote Procedure Calls]]（[[Korakit Seemakhupt]]・[[Arvind Krishnamurthy]] ほか [[Google]]/UW/UCSD、SOSP 2023）: Google 規模の RPC 特性。スループット年率 30% 増、レイテンシ中央値ミリ秒スケール。**ページ作成**: source 9 + entity 35 + concept 8（[[マイクロサービスコールグラフ]]・[[マイクロサービスアーキテクチャ]]・[[非致命的RPCエラー]]・[[暗黙のコンテキスト伝搬]]・[[限定観測可能性]]・[[クラウドスケールRPC特性]]（旧 RPC 規模/レイテンシ特性を統合）・[[SRE]]）。**ページ更新**: [[分散トレーシング]]・[[根本原因分析]]・[[異常検知]]・[[Fault Localization]]・[[マルチモーダル障害診断]]・[[ソフトウェア変更管理]]・[[運用障害分析]]・[[インシデント管理]]・[[eBPF]]・[[動的計装|動的インストルメンテーション]]・[[Google]]。**横断的知見**: (1) マイクロサービスの障害特性が 4 社本番データで横断可能になった。「エラーの大多数は非致命的」(Uber 29.35%)、「インシデントの 90% 超はコード変更なしで緩和」(Microsoft)、「RPC レイテンシはミリ秒スケール」(Google)。(2) 分散トレーシングに計装ベース(Dapper/Canopy/CRISP)と非計装ベース(DeepFlow の eBPF + 暗黙コンテキスト伝搬)の 2 系統が成立し、トレードオフ(精度 vs 導入コスト)が定量化可能に。(3) インシデントの認知時間が全体 MTTR の 72.5% を占め(Microsoft)、自動検知の価値が緩和自動化より大きい可能性。（source +9・entity +35・concept +8）。 2026-06-06: **SRE コンセプトページを新規作成** — [[SRE]]（Site Reliability Engineering）の傘概念ページ。SRE Book 10 章から抽出した核心原則（エラーバジェット・50% ルール・SLI/SLO/SLA・4 つのゴールデンシグナル・変更管理・ブレームレスポストモーテム）、サービス信頼性ヒエラルキー（7 層）、自動化ヒエラルキー（5 段階）を集約。横断的知見として、自動化ヒエラルキー→[[SRE AI Autonomy Levels]]（L0–L4）の 10 年間の継承、航空アナロジー→[[自動化のアイロニー]]の独立再発見、SRE の原則体系が [[agentic SRE]] の仕様書として機能する構造を記述。既存概念（[[エラーバジェット]]・[[トイル]]・[[サービスレベル目標]]・[[インシデント管理]]）への接続を wikilink で整備（concept +1）。 2026-06-06: **Google SRE Book (O'Reilly, 2016) の 10 章を一括 wiki-ingest で取り込み** — "Site Reliability Engineering: How Google Runs Production Systems"（[[Betsy Beyer]]・Chris Jones・Jennifer Petoff・[[Niall Murphy]] 編、O'Reilly 2016）の Foreword（[[Mark Burgess (SRE)]]）・Preface・Chapter 1 Introduction（[[Ben Treynor Sloss]]）・Chapter 3 Embracing Risk・Chapter 4 SLO・Chapter 5 Eliminating Toil・Chapter 6 Monitoring Distributed Systems・Chapter 7 Automation at Google・Part III Practices・Chapter 34 Conclusion の 10 章を章ごとにソースページ化。SRE ディシプリンの定義書として、エラーバジェット（SLO で許容される障害量の予算化、開発と運用の共通インセンティブ）、トイル（6 特性の運用作業を 50% 以下に抑制、Google 平均 33%）、4 つのゴールデンシグナル（レイテンシ・トラフィック・エラー・サチュレーション）、自動化 5 段階ヒエラルキー（手動→完全自律）、サービス信頼性ヒエラルキー（7 層：モニタリング→ローンチ）を体系化。**ページ作成**: source 10 + entity 5（[[SRE Book]]・[[Ben Treynor Sloss]]・[[Betsy Beyer]]・[[Niall Murphy]]・[[Margaret Hamilton]]）+ concept 2（[[エラーバジェット]]・[[トイル]]）。**ページ更新**: [[サービスレベル目標]]（SRE Book の SLI/SLO/SLA 体系を横断的知見に追加）・[[自動化のアイロニー]]（SRE Book の自動化ヒエラルキーと Bainbridge のアイロニーの接続を追加）・[[agentic SRE]]（SRE Book が agentic SRE の前史を定義する知見を追加）。**位置づけ**: SRE Book (2016) は本 wiki の SRE・AIOps 系概念群の実践的基盤文献。自動化ヒエラルキー（手動→完全自律）は [[SRE AI Autonomy Levels]](L0–L4)の直接の前駆であり、結論の章の航空アナロジーは [[自動化のアイロニー]] の Bainbridge のテーゼと独立に同じ洞察を提示。Bainbridge (1983)→Gray (1985)→Oppenheimer (2003)→Hamilton (2007) の系譜に SRE Book (2016) が実践的体系として接続する。（source +10・entity +5・concept +2）。 2026-06-06: **分散データベース・ストレージの古典 5 論文を一括 wiki-ingest-paper で取り込み** — (1) [[@2005__ICDE__One Size Fits All - An Idea Whose Time Has Come and Gone]]（[[Michael Stonebraker]]・[[Ugur Cetintemel]]、ICDE 2005）: 汎用 RDBMS の「ワンサイズフィッツオール」戦略の終焉を論じ、データウェアハウス（カラムストア）・ストリーム処理（StreamBase が商用 RDBMS 比約 200 倍）・テキスト検索・科学 DB・センサネットワークなど専用エンジンの優位性を体系的に主張。(2) [[@2006__OSDI__Bigtable - A Distributed Storage System for Structured Data]]（[[Jeffrey Dean]]・[[Sanjay Ghemawat]] ほか [[Google]]、OSDI 2006）: (row, column, timestamp) → string の多次元疎マップをタブレット分割・SSTable/memtable・[[Chubby]]・[[Google File System]] で構成。2006 年 8 月時点で 388 クラスタ・24,500 タブレットサーバ・60 以上のプロダクトが運用。(3) [[@2007__SOSP__Dynamo - Amazon's Highly Available Key-value Store]]（[[Giuseppe DeCandia]]・[[Werner Vogels]] ほか [[Amazon]]、SOSP 2007）: 結果整合性・一貫性ハッシュ法（仮想ノード）・ベクタークロック・スロッピークォーラム・マークル木・ゴシッププロトコルを合成した高可用 KV ストア。99.9 パーセンタイル SLA でショッピングカートを運用し 99.94% が単一バージョンを返す。(4) [[@2007__VLDB__The End of an Architectural Era (It's Time for a Complete Rewrite)]]（[[Michael Stonebraker]]・[[Samuel Madden]]・[[Daniel J. Abadi]] ほか、VLDB 2007）: OLTP での RDBMS 有用作業 6.8%（バッファ管理 34.6%・ロック 16.3%・ラッチ 14.2%・リカバリ 11.9%）を定量化し、メインメモリ・単一スレッド・シェアードナッシングの [[H-Store]] で TPC-C 82 倍（70,416 tx/s vs 850 tx/s）を達成。(5) [[@2010__SIGOPS_OSR__Cassandra - A Decentralized Structured Storage System]]（[[Avinash Lakshman]]・[[Prashant Malik]]、SIGOPS OSR 2010 / LADIS 2009）: [[Dynamo]] のパーティショニングと [[Bigtable]] のカラムファミリモデルを統合。修正版 Scuttlebutt ゴシップとΦ累積障害検知器で完全非中央集権を実現し、[[Facebook]] Inbox Search（2 億ユーザ超）で 600 台運用。**ページ作成**: source 5 + entity 22（[[Michael Stonebraker]]・[[Ugur Cetintemel]]・[[MIT]]・[[Brown University]]・[[Jeffrey Dean]]・[[Sanjay Ghemawat]]・[[Bigtable]]・[[Google File System]]・[[Chubby]]・[[Werner Vogels]]・[[Giuseppe DeCandia]]・[[Amazon]]・[[Dynamo]]・[[Samuel Madden]]・[[Daniel J. Abadi]]・[[Stavros Harizopoulos]]・[[Pat Helland]]・[[H-Store]]・[[Avinash Lakshman]]・[[Prashant Malik]]・[[Apache Cassandra]]・[[Facebook]]）+ concept 6（[[専用データベースシステム]]・[[結果整合性]]・[[一貫性ハッシュ法]]・[[分散ストレージ]]・[[ゴシッププロトコル]]・[[LSMツリー]]）。**ページ更新**: [[Google]]・[[インターネットスケールサービス設計]]。**位置づけ**: Stonebraker の「ワンサイズフィッツオール」批判(2005)を起点に、Bigtable(多次元マップ)・Dynamo(結果整合性 KV)・H-Store(メインメモリ OLTP)・Cassandra(Dynamo+Bigtable ハイブリッド)が異なるワークロード軸で具体的に検証。Avinash Lakshman が Dynamo(Amazon) → Cassandra(Facebook) の両方の著者であり設計知識の移転を体現する結節点。本 wiki で初めて AI/ML 以外のデータベース・分散システム基盤研究を横断集約。（source +5・entity +22・concept +6）。 2026-06-06: **システム信頼性・自動化の古典 4 論文を一括 wiki-ingest-paper で取り込み** — (1) [[@1983__Automatica__Ironies of Automation]]（[[Lisanne Bainbridge]]、Automatica 1983）: 自動化がオペレータの問題を除去するどころか拡大する 5 つのアイロニー（設計者・残余タスク・技能劣化・監視の不可能性・訓練投資の逆説）を体系化した古典論考。agentic SRE・SRE AI Autonomy Levels・エージェント運用安全性の理論的基盤。(2) [[@1985__Tandem__Why Do Computers Stop and What Can Be Done About It]]（[[Jim Gray]]、Tandem TR 85.7, 1985）: [[Tandem Computers]] [[NonStop]] 2,000 台超・1,300 システム年超の障害統計で管理(42%)・ソフトウェア(25%)・ハードウェア(18%)を定量化。Bohrbug/[[Heisenbug]] の二分法、[[プロセスペア]]の 5 類型、永続プロセスペア＋トランザクションによる[[ソフトウェア耐障害性]]の設計論を体系化。(3) [[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]]（[[David Oppenheimer]]・[[Archana Ganapathi]]・[[David A. Patterson]]、USITS 2003）: [[UC Berkeley ROC Project]] による 3 大規模インターネットサービスの障害事後報告 500 件超を分析し、オペレータエラー（特に設定ミス 50% 超）がサービス障害・修復時間の最大原因であることを実証。[[運用障害分析]]の概念を Gray (1985) からインターネットサービスに拡張。(4) [[@2007__LISA__On Designing and Deploying Internet-Scale Services]]（[[James Hamilton]]、LISA 2007）: MSN/Windows Live の経験から「障害を前提とした設計」「すべてを自動化」「単純さの保持」の 3 信条と 10 領域のベストプラクティスを体系化。運用問題の 80% は設計に起因するという指摘が Gray→Oppenheimer の系譜を設計原則に昇華。**ページ作成**: source 4 + entity 10 + concept 6（[[自動化のアイロニー]]・[[ソフトウェア耐障害性]]・[[Heisenbug]]・[[プロセスペア]]・[[運用障害分析]]・[[インターネットスケールサービス設計]]）。**ページ更新**: [[耐障害LLM訓練]]・[[チェックポイント]]・[[GPUレジリエンス]]・[[インシデント管理]]・[[障害注入]]・[[根本原因分析]]・[[Microsoft]]・[[サービスレベル目標]]。**位置づけ**: 1983〜2007 年の 4 古典論文が形成する「ソフトウェア・運用障害が支配的」→「オペレータエラーが最大原因」→「設計で運用問題を予防」→「自動化自体がパラドクスを生む」の連鎖は、本 wiki の agentic SRE・AIOps・障害管理系概念の歴史的基盤となる。（source +4・entity +10・concept +6） 2026-06-06: **Composer 2 Technical Report を wiki-ingest-paper で取り込み** — [[@2026__arXiv__Composer 2 Technical Report]]（arXiv:2603.24477, 2026）: [[Cursor Research]] のエージェント型ソフトウェアエンジニアリングモデル [[Composer 2]]（1.04T/32B 活性化 MoE、[[Kimi K2.5]] ベース）。コード特化継続事前学習（32K→256K コンテキスト、MXFP8 on B300、パープレキシティと下流 RL 報酬の対数線形相関を確認）の後、Dr. GRPO 変種による大規模非同期 RL（4 サービス分離: 訓練/環境/推論/評価）で訓練。自己要約機構で長期ホライズンに対応、非線形長さペナルティ、MoE ルーティングリプレイ、NVFP4 per-token スケーリングなどの RL 革新を含む。インフラは [[Anyrun]]（Firecracker VM）と [[Fireworks AI]] の地理的分散推論、[[DeepEP]] エキスパート並列、[[ThunderKittens]] GPU カーネルを活用。[[CursorBench]] 61.3・SWE-bench Multi 73.7・Terminal-Bench 61.7 でコスト精度パレート最適を達成。RL が平均性能と best-of-K 性能の双方を同時改善する証拠を示し「RL は既知パスの確率再配分にすぎない」という懸念を否定。**ページ作成**: source 1 + entity 7（[[Cursor Research]]・[[Composer 2]]・[[CursorBench]]・[[Anyrun]]・[[Fireworks AI]]・[[ThunderKittens]]・[[DeepEP]]）+ concept 1（[[エージェント型コーディング]]）。**ページ更新**: [[エージェント型強化学習]]（related 追加）・[[強化ファインチューニング]]（横断的知見 1 点・related 追加）。（source +1・entity +7・concept +1）。 2026-06-06: **OLMo 3 技術報告書を wiki-ingest-paper で取り込み** — [[@2025__arXiv__OLMo 3]]（arXiv:2512.13961, 2025, 118 ページ）: [[Allen Institute for AI]]（AI2）の完全オープン LLM ファミリー [[OLMo 3]]（7B/32B、decoder-only Transformer、SWA 3/4 層 + フルアテンション 1/4 層）。「モデルフロー全体の公開」を掲げ、全段階のチェックポイント・データミックス（[[Dolma 3]] 5.9T トークン + [[Dolci]] 後訓練スイート）・コード・訓練ログを公開した初の SOTA 級 LLM。Base・Think・Instruct・RL-Zero の 4 変種を提供。[[OlmoRL]]（GRPO ベース 7 改善 + 完全非同期パイプライン、OLMo 2 比 4 倍スループット）で RLVR を実行。Delta Learning（Qwen 3 32B/0.6B の能力デルタによる DPO）が SFT 飽和後も推論フロンティアを拡張。OLMo 3.1 Think 32B は MATH 96.2・AIME 2024 80.6 で完全オープンモデル最強。RL-Zero は事前学習データの RL への影響を追跡可能にする初のクリーンなベンチマーキング環境。1024 H100 GPU・56 日・$2.75M。**ページ作成**: source 1 + entity 9（[[Allen Institute for AI]]・[[OLMo 3]]・[[Dolma 3]]・[[OlmoRL]]・[[OlmoBaseEval]]・[[olmOCR]]・[[Duplodocus]]・[[Dolci]]）+ concept 1（[[オープンLLM開発]]）。**ページ更新**: [[強化ファインチューニング]]（横断的知見 2 点）・[[University of Washington]]。（source +1・entity +9・concept +1）。 2026-06-06: **Kimi-Researcher プロジェクトページを wiki-ingest-paper で取り込み** — [[@2025__Moonshot AI__Kimi-Researcher - End-to-End RL Training for Emerging Agentic Capabilities]]（moonshotai.github.io、2025-06-20）: [[Moonshot]] の自律型リサーチエージェント [[Kimi-Researcher]]。内部版 Kimi k シリーズモデルをエンドツーエンドの REINFORCE のみで訓練し、Humanity's Last Exam で Pass@1 26.9%（初期 8.6% から RL のみで達成）、xbench-DeepSearch で 69% pass@1 を記録。3 つのツール（並列検索・テキストブラウザ・コード実行）を統合し、タスクあたり平均 23 推論ステップ・200 以上の URL 探索・70 以上の検索クエリを実行する。ガンマ減衰報酬 r × γ^(T-i) でステップレベルの信用割当を近似、コンテキスト管理機構で単一ロールアウトを 50 イテレーション超に拡張、ターンレベル部分ロールアウト（リプレイバッファ活用）で 1.5 倍以上の訓練高速化を実現。Kubernetes ベースのハイブリッドクラウド上で完全非同期ロールアウトと [[Model Context Protocol]] によるエージェント-ツール通信を統合する大規模インフラストラクチャを備える。RL のみから矛盾情報の自己修正や追加検証行動が創発。**ページ作成**: source 1 + entity 1（[[Kimi-Researcher]]）。**ページ更新**: [[Moonshot]]（概要・関連・出典）・[[エージェント型強化学習]]（横断的知見 5 点・未解決の問い 2 点）・[[強化ファインチューニング]]（出典追加）。**位置づけ**: 検索エージェントドメインで SFT なしエンドツーエンド RL の有効性を確認した初の大規模実証。DeepSWE のコーディング、AgentRL の汎用マルチタスクに続き、リサーチドメインでも「SFT 不要」が成立することをドメイン横断的に示す。ガンマ減衰報酬は IsoCompute Playbook のロールアウト数最適化とは直交する信用割当近似アプローチ。（source +1・entity +1）。 2026-06-06: **MiniMax-M1 技術報告書を wiki-ingest-paper で取り込み** — [[@2025__arXiv__MiniMax-M1 - Scaling Test-Time Compute Efficiently with Lightning Attention]]（arXiv:2506.13585, 2025）: [[MiniMax]] のオープンウェイト初の大規模ハイブリッドアテンション推論モデル [[MiniMax-M1]]（456B 総パラメータ、45.9B 活性化、32 エキスパート MoE、100 万トークンコンテキスト）。[[Lightning Attention]] を 7:1 比で混成し 100K トークン生成時の FLOPS を DeepSeek R1 の 25% に削減。独自 RL アルゴリズム [[CISPO]] が DAPO 比 2 倍のステップ効率。512 H800 GPU・3 週間・53.4 万ドルで RL 訓練完了。新概念 [[テスト時計算スケーリング]] を作成。**ページ作成**: source 1 + entity 5（[[MiniMax-M1]]・[[MiniMax-Text-01]]・[[CISPO]]・[[Lightning Attention]]・[[SynLogic]]）+ concept 1。**ページ更新**: [[MiniMax]]・[[強化学習スケーリング]]・[[強化ファインチューニング]]。（source +1・entity +5・concept +1）。 2026-06-06: **Kimi K1.5 技術報告書を wiki-ingest-paper で取り込み** — [[@2025__arXiv__Kimi K1.5 - Scaling Reinforcement Learning with LLMs]]（arXiv:2501.12599, 2025）: [[Moonshot]]（月之暗面）の RL 訓練マルチモーダル LLM [[Kimi K1.5]] の技術報告。長コンテキスト RL（128k）とオンラインミラー降下変種を組み合わせ、MCTS・価値関数・プロセス報酬モデルを排除したシンプルな RL フレームワークで OpenAI o1 に匹敵する推論性能（AIME 77.5、MATH-500 96.2）を達成。パーシャルロールアウト（長軌跡を反復間で分割再利用）と CoT 報酬モデル（98.5% 精度）で長コンテキスト RL を実現。ハイブリッドデプロイメント（[[Megatron-LM]] + [[vLLM]] + [[Mooncake]] RDMA 転送、Kubernetes Sidecar 構成）とコードサンドボックス（crun + cgroup 再利用 + tmpfs オーバーレイ）で RL インフラを最適化。long2short 手法 4 経路（モデルマージ・最短拒否サンプリング・DPO・long2short RL）で短 CoT モデルでも GPT-4o を最大 +550% 上回る。**ページ作成**: source 1 + entity 2（[[Kimi K1.5]]・[[Mooncake]]）。**ページ更新**: [[Moonshot]]・[[vLLM]]・[[強化学習スケーリング]]（横断的知見 2 点・未解決の問い 1 点）・[[強化ファインチューニング]]（横断的知見 2 点）。**位置づけ**: コンテキスト長をモデルサイズ・データ量に並ぶ RL の第三のスケーリング次元として位置づけた最初のシステム。パーシャルロールアウトは IsoCompute Playbook のロールアウト数最適化と相補し、価値関数排除は ScaleRL の CISPO・DeepSWE の GRPO++ と合わせ 3 つの直交アプローチを形成する。（source +1・entity +2）。 2026-06-06: **NVIDIA Nemotron 3 技術報告書を wiki-ingest-paper で取り込み** — [[@2025__arXiv__Nemotron 3 - Efficient and Open Intelligence]]（arXiv:2512.20856, 2025）: [[NVIDIA]] のオープン LLM ファミリー [[Nemotron 3]]（Nano 30B/3B・Super・Ultra）の技術報告書。(1) ハイブリッド Mamba-2–Transformer [[Mixture-of-Experts|MoE]] で KV キャッシュ線形増大を回避し同規模 MoE 比 3.3 倍推論スループット、(2) [[LatentMoE]] で潜在次元射影によりエキスパート通信量を d/ℓ 倍削減しエキスパート数を 128→512 に増加（MMLU-Pro +4.57pp）、(3) NVFP4（E2M1 + マイクロブロックスケーリング）で BF16 比 <1% 損失差のまま 25T トークン安定事前学習、(4) マルチ環境同時 RL（[[GRPO]] + マスク付き重要度サンプリング + [[NeMo-RL]] 非同期アーキテクチャ）で数学・コード・ツール利用・長コンテキスト（最大 100 万トークン）を同時最適化。MTP 投機的復号で承認率約 97%。モデル重み・10T+ トークンデータセット・訓練レシピ・NeMo-RL/NeMo-Gym を Apache 2.0 で公開予定。**ページ作成**: source 1 + entity 3（[[Nemotron 3]]・[[LatentMoE]]・[[NeMo-RL]]）。**ページ更新**: [[NVIDIA]]（リンク・本文追記）・[[Mixture-of-Experts]]（LatentMoE vs FAST の横断的知見）・[[強化ファインチューニング]]（マルチ環境同時 RL vs 逐次訓練の横断的知見）。**位置づけ**: LatentMoE はアーキテクチャ側から MoE All-to-All 通信ボトルネックを解決するアプローチで、FAST（NSDI 2026）のスケジューリング側アプローチと相補的。マルチ環境同時 RL は Scaling Up RL の逐次 5 ドメイン訓練の対照例。（source +1・entity +3）。 2026-06-06: **Kimi K2: Open Agentic Intelligence を wiki-ingest-paper で取り込み** — [[@2025__arXiv__Kimi K2 - Open Agentic Intelligence]]（arXiv:2507.20534, 2025）: [[Moonshot AI]] の 1.04 兆パラメータ(活性化 32B)超疎 MoE LLM [[Kimi K2]] のテクニカルレポート。384 エキスパート(活性化 8 + 共有 1、スパーシティ 48)・MLA(64 アテンションヘッド)・61 層 Transformer。[[MuonClip]](Muon + QK-Clip: ヘッド単位のアテンションロジットクリッピング)により 15.5 兆トークンをロススパイクなしに事前学習。事後学習では MCP ツール 3,000 超 + 合成ツール 20,000 超のエージェント型データ合成パイプラインと、RLVR + 自己批判型ルーブリック報酬の統合 RL を実施。SWE-bench Verified 65.8%・τ2-Bench 66.1 でオープンソース非思考モデル SOTA、LMSYS Arena(2025-07-17)でオープンソース 1 位・全体 5 位。スパーシティスケーリング則(固定活性化パラメータ・総エキスパート増加で一貫した損失低下)を実証。H800 クラスタ上で 16-way PP + 16-way EP + ZeRO-1 DP・interleaved 1F1B(DualPipe 不採用)。分散チェックポイントエンジンで 1T パラメータ更新を 30 秒未満。**ページ作成**: source 1 + entity 3（[[Moonshot AI]]・[[Kimi K2]]・[[MuonClip]]）。**ページ更新**: [[Mixture-of-Experts]]（スパーシティスケーリング則追加）・[[エージェント型強化学習]]（横断的知見 2 点・未解決の問い 1 点追加）・[[強化ファインチューニング]]（自己批判型ルーブリック報酬追加）・[[LLM分散学習]]（MuonClip + チェックポイント追加）・[[並列化戦略]]（DualPipe 不採用の設計判断追加）。**位置づけ**: M2(MiniMax)が 229.9B/9.8B の MoE + Forge でエージェント RL を示したのに対し、Kimi K2 は 1.04T/32B の超疎 MoE で環境スケーリング(23,000+ ツール)の産業的解法を提示する。Cursor Composer 2.5 が Kimi K2.5 を基盤モデルとしたことと合わせ、Moonshot AI の Kimi シリーズが本 wiki のエージェント型 RL・MoE・分散学習の 3 概念を結ぶ中心的エンティティに位置づけられる。（source +1・entity +3）。 2026-06-06: **Cursor Composer 2.5 ブログ記事を wiki-ingest で取り込み** — [[@2026__Cursor__Introducing Composer 2.5]]（Cursor Blog 2026-05-18）: AI コーディングエージェントモデル Composer 2.5 の発表記事。[[Moonshot]] の [[Kimi K2.5]]（オープンソースチェックポイント）を基盤に、ターゲット RL（軌跡中の特定箇所にテキストヒントを挿入するオンポリシー蒸留で信用割当を緩和）、合成タスク 25 倍拡大（特徴削除ベース）、[[Sharded Muon]]（分散直交化 + dual-mesh HSDP）を適用。訓練中に Python 型キャッシュ逆工学・Java バイトコード逆コンパイルによる高度な報酬ハッキングが観察された。[[SpaceXAI]] と協業し [[Colossus 2]]（百万 H100 相当）で次世代モデル開発中。**ページ作成**: source 1 + entity 6（[[Cursor]]・[[Kimi K2.5]]・[[Moonshot]]・[[SpaceXAI]]・[[Colossus 2]]・[[Sharded Muon]]）。**ページ更新**: [[強化ファインチューニング]]（横断的知見 2 点・未解決の問い 1 点追加）・[[エージェント型強化学習]]（横断的知見 1 点追加）。**位置づけ**: 本 wiki 初の産業コーディングエージェント訓練の一次情報。DeepSWE の二値報酬 vs Cursor の密なテキストフィードバック、AutoForge の環境自動合成 vs 特徴削除ベースの合成データ生成が対照軸。報酬ハッキングが「障害か創発か」はタスク設計に依存するという知見を追加。（source +1・entity +6）。 2026-06-05: **RL Scaling & Agentic RL 10 論文の一括取り込み** — LLM 向け RL スケーリング 4 本（ScaleRL / Scaling Behaviors / IsoCompute Playbook / Scaling Up RL）とエージェント型 RL 6 本（DeepSWE / AutoForge / Agent-R1 / AgentRL / Landscape of Agentic RL / Training SWE Agents）を subagent 並行で wiki に取り込み。**RL スケーリング系列**: (1) [[@2025__arXiv__The Art of Scaling Reinforcement Learning Compute for LLMs]]（Meta/UT Austin、Khatri・Agarwal）: 400,000 GPU 時間のアブレーションでシグモイド飽和モデル提案、統合レシピ [[ScaleRL]] で 8B A=0.61。(2) [[@2025__arXiv__Scaling Behaviors of LLM Reinforcement Learning Post-Training]]（Shanghai AI Lab、Tan・Zhang）: Qwen2.5 0.5B〜72B で RL 事後学習のべき乗則を体系化、R² > 0.99。(3) [[@2026__arXiv__IsoCompute Playbook - Optimally Scaling Sampling Compute for LLM Reinforcement Learning]]（UCSD/CMU/MBZUAI、Kumar・Hu）: 12 万 H200 時間で最適ロールアウト数のシグモイド飽和と問題難度別二重機構を導出、Chinchilla 則の RL 版。(4) [[@2025__arXiv__Scaling Up RL - Unlocking Diverse Reasoning in LLMs via Prolonged Training]]（NVIDIA、Liu・Choi）: 1.5B モデルの 5 ドメイン長期 RL で KL 正則化の安定化効果を実証。**エージェント型 RL 系列**: (5) [[@2025__Together AI__DeepSWE - Training a Fully Open-sourced State-of-the-Art Coding Agent by Scaling RL]]（Together AI、Luo・Jain）: SFT なし GRPO++ のみで SWE-Bench-Verified SOTA。(6) [[@2025__arXiv__AutoForge - Environment Synthesis for Agentic RL]]（Tongyi Lab/Alibaba、Cai）: ERPO + MEU で訓練環境を自動合成。(7) [[@2025__arXiv__Agent-R1 - Training Agents with End-to-End RL]]（USTC、Cheng）: モジュラーな agentic RL フレームワーク。(8) [[@2025__arXiv__AgentRL - Training Language Model Agents with Reinforcement Learning]]（Tsinghua/Z.AI、Zhang・Liu）: マルチターン・マルチタスク統合で GPT-5 超え 70.4%。(9) [[@2025__arXiv__The Landscape of Agentic Reinforcement Learning]]（Shanghai AI Lab/Oxford/NUS、Zhang・Yin・Bai）: 95 ページ・726 参考文献のサーベイ、PBRFT vs Agentic RL の形式的区別。(10) [[@2025__arXiv__Training Long-Context Multi-Turn SWE Agents with Reinforcement Learning]]（Nebius AI、Golubev・Yangel）: RFT + DAPO パイプラインで SWE エージェント訓練。**新概念**: [[強化学習スケーリング]]（RL ポスト訓練の計算資源配分と性能飽和の法則）、[[エージェント型強化学習]]（POMDP/T>1 でのエージェント訓練）。**新エンティティ**: 約 50 件（著者・組織・プロダクト）。**重複クリーンアップ**: `@2025__TMLR__The Landscape...` を削除し canonical `@2025__arXiv__The Landscape...` に統合、全参照修正。（source +10・entity +50・concept +2）。 2026-06-06: [[Delta]] の A100 GPU レジリエンスケーススタディを **wiki-ingest-paper** で取り込み。[[@2025__DSN-W__Characterizing Modern GPU Resilience and Impact in HPC Systems - A Case Study of A100 GPUs]]（DSN-W 2025, DOI:10.1109/DSN-W65791.2025.00031）: [[Shengkun Cui]]・[[Archit Patke]]・[[Ziheng Chen]]・[[Aditya Ranjan]] ら UIUC/NCSA/[[IBM Research]]/[[Nokia Bell Labs]] による、[[Delta]] の A100 106 ノード/448 GPU・3 年・12.5M GPU 時間の運用ログ分析。運用期の per-node MTBE は 199h→154h へ 23% 悪化。GPU メモリは非メモリ GPU ハードウェアより 160 倍高信頼で、A100 の row remapping/error containment は運用期の訂正不能メモリエラーを全て緩和し RRF は 0。一方で GSP はジョブ失敗率 100%、PMU SPI 97.56%、MMU 90.48%、NVLink 53.75%。GPU ノード可用性は 99.5%(1 日 7 分)、累計 5,700 node hours のダウンタイム。**ページ作成**: source 1 + entity 10（[[Archit Patke]]・[[Ziheng Chen]]・[[Aditya Ranjan]]・[[Hung Nguyen]]・[[Phuong Cao]]・[[Brett Bode]]・[[Gregory Bauer]]・[[Chandra Narayanaswami]]・[[Daby Sow]]・[[Catello Di Martino]]）。**ページ更新**: [[GPUレジリエンス]]（A100 単体では非メモリハードウェアが弱点、H100 比較の基準線という横断知見）・[[GPUクラスタ運用]]（99.5% 可用性/5,700 node hours を運用負債として追記）。**位置づけ**: 既存の [[@2025__SC__Characterizing GPU Resilience and Impact on AI - HPC Systems]] は A100/H100 世代比較で、本論文はその前段にあたる A100 ケーススタディ。A100 では「メモリは強くハードウェアが弱い」ことを切り出す。 2026-06-06: [[Shanghai AI Laboratory]] の LLM 開発ワークロード特徴づけ記事を **wiki-ingest** で取り込み。[[@2024__USENIX login Online__Understanding Workload Characteristics in Large Language Model Development]]（USENIX ;login: Online 2024-03-19, [[Qinghao Hu]]・[[Peng Sun]]・[[Tianwei Zhang]]）: GPU データセンター [[Acme]] の Seren/Kalos 2 クラスタ、計 4,704 A100 GPU、2023 年 3〜8 月の 6 か月トレースを分析。GPU ジョブ実行時間中央値は 2 分で従来 DL クラスタより 1.7〜7.2 倍短い。GPU 利用率中央値は 97%/99% だが 0% と 100% に二極化。評価ジョブは件数多数だが Kalos で GPU 時間 0.8% に留まり、事前学習は件数 0.9〜3.2% で GPU 時間 69.5〜94.0% を消費。インフラ障害は失敗件数 11% でも GPU 時間 82% 超を占め、Kalos では 7B 訓練時の高温が NVLinkError/ECCError と結びつく。[[InternEvo]] V2 は 123B LLM・2,048 GPU で V1 比約 16% 高速化。**ページ作成**: source 1 + entity 4（[[Qinghao Hu]]・[[Tianwei Zhang]]・[[Acme]]・[[InternEvo]]）。**ページ更新**: [[Peng Sun]]・[[Shanghai AI Laboratory]]・[[GPUクラスタ運用]]・[[LLM分散学習]]・[[並列化戦略]]。**位置づけ**: Philly の LLM 以前 DNN クラスタと SAKURAONE/MegaScale の LLM 訓練実測の間に、LLM 専用クラスタの短ジョブ多数・GPU 時間少数支配・利用率二極化・熱起因障害という運用像を補う。（source +1・entity +4）。 2026-06-06: [[Meta]] の ML 研究クラスタ信頼性論文を **wiki-ingest-paper** で取り込み。[[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]]（HPCA 2025, DOI:10.1109/HPCA61900.2025.00096）: [[Apostolos Kokolis]]・[[Michael Kuchnik]]・[[Carole-Jean Wu]] ら FAIR at Meta による、[[Meta AI Research SuperCluster]] の RSC-1(16k A100)・RSC-2(8k A100)を対象にした 11 か月・4 百万ジョブ・1.5 億超 A100 GPU 時間の信頼性分析。90% 超のジョブは 1 サーバ未満だが GPU 時間は 10% 未満、256+ GPU ジョブが GPU 時間の 66% 超(RSC-1)・52% 超(RSC-2)を消費。ハードウェア関連失敗はジョブ件数 0.2% でも GPU 実行時間 18.7% に影響し、再キューに伴う二次的プリエンプションが障害オーバーヘッドの 16% を占める。MTTF は GPU 数にほぼ反比例し、1024 GPU で 7.9 時間、16,384 GPU で 1.8 時間、131,072 GPU で 0.23 時間と予測。ETTR 推定式から、10 万 GPU 級では分単位チェックポイント/再起動が必要。レモンノード検知は 40 台を 85% 超精度で同定し 512+ GPU ジョブ失敗率を 14%→4% へ、適応ルーティングは InfiniBand link error 下の NCCL AllReduce を安定化。**ページ作成**: source 1 + entity 4（[[Apostolos Kokolis]]・[[Michael Kuchnik]]・[[Carole-Jean Wu]]・[[Meta AI Research SuperCluster]]）。**ページ更新**: [[Meta]]・[[GPUクラスタ運用]]・[[LLM分散学習]]・[[耐障害LLM訓練]]・[[チェックポイント]]・[[集合通信]]。**位置づけ**: Jeon 2019 の DNN 研究クラスタ、SAKURAONE の単一テナント中規模 LLM 開発、ByteRobust/MegaScale の本番 LLM 訓練の間をつなぐ、LLM 世代マルチテナント研究クラスタの信頼性参照点。（source +1・entity +4）。 2026-06-06: [[Microsoft]] のマルチテナント GPU 訓練クラスタ [[Philly]] の本番トレース論文を **wiki-ingest-paper** で取り込み。[[@2019__USENIX ATC__Analysis of Large-Scale Multi-Tenant GPU Clusters for DNN Training Workloads]]（USENIX ATC 2019, [[Myeongjae Jeon]] ほか）: 75 日・96,260 ジョブ・14 仮想クラスタのトレースから、ギャングスケジューリングと局所性制約が fragmentation delay を生み、5–8 GPU ジョブの待ち発生 74.2%、8 GPU 超ジョブの 97.9% を占めること、割り当て済み GPU の処理サイクル利用率が全ジョブ平均 52.32% に留まること、killed/unsuccessful が件数 30.7% でも総 GPU 時間の約 55% を消費することを定量化。**ページ作成**: source 1 + entity 10（著者 6・組織 2・[[Philly]]・[[philly-traces]]）+ concept 1（[[GPUクラスタスケジューリング]]）。**ページ更新**: [[GPUクラスタ運用]]（ロングテールと GPU 時間で測る原則を追記）・[[LLM分散学習]]（SER の前史として接続）・[[並列化戦略]]（並列化が配置制約になる点を追記）・[[Microsoft]]・[[Beihang University]]。**位置づけ**: LLM 以前の DNN 訓練クラスタで観測された locality/utilization/failure の問題が、現代 LLM 分散学習の SER へ連続することを実ソースで補強した。（source +1・entity +10・concept +1）。 2026-06-06: [[Qualcomm]] の LLM 事前学習性能チューニング論文を **wiki-ingest-paper** で取り込み。[[@2025__PMBS__Pretraining LLMs at Scale - Tuning Strategies and Performance Portability]]（PMBS25 / SC Workshops '25, DOI:10.1145/3731599.3767699）: [[Adrián Pérez Diéguez]]・Àlex Batlle Casellas・Aleix Torres-Camps・Harris Teague・Jordi Ros-Giralt による、DeepSpeed/ZeRO/NCCL/RDMA を実測でつなぐ 12 ページ論文。Model-1(440M)で ZeRO Stage 1/2 と batch_size×grad_acc の性能分解を行い、Model-2(8B, 蒸留付き)を 8 ノード 64 GPU の IB-A100/RoCE-A100/RoCE-H100 で評価。3 プラットフォームすべてで ZeRO Stage 2・batch_size 128・grad_acc 2 が最良、既定構成比最大 1.6 倍高速化。DeepSpeed Stage 2 の既定勾配集約が reduce-scatter でなく all-reduce であること、RDMA 無効化で backward pass が 12 倍遅くなること、性能可搬性 `Φ=0.2574` を報告。**ページ作成**: source 1 + entity 2（[[Adrián Pérez Diéguez]]・[[Qualcomm]]）+ concept 1（[[性能可搬性]]）。**ページ更新**: [[LLM分散学習]]（Efficiency 軸に局所チューニング知見を追加）・[[並列化戦略]]（ZeRO/batch/通信プリミティブを並列化探索空間として追記）・[[DeepSpeed]]（Stage 2 実装差追記）・[[NCCL]]（all-reduce チューニング追記）。**位置づけ**: MegaScale/SAKURAONE/Astral が大域的な協調設計を示すのに対し、本論文はフレームワーク既定値と通信プリミティブを測って外す実務的チューニングを補う。（source +1・entity +2・concept +1）。 2026-06-05: [[University of Oxford]]/[[Shanghai AI Laboratory]]/NUS ほか 15 機関の Agentic RL 包括的サーベイを **wiki-ingest-paper** で取り込み。[[@2025__arXiv__The Landscape of Agentic Reinforcement Learning]]（arXiv:2509.02547v5, TMLR 2026）: [[Guibin Zhang]]†・Hejia Geng†・Xiaohang Yu†・[[Zhenfei Yin]]*・[[Lei Bai]]* ら 25 名による 95 ページ・726 参考文献のサーベイ。PBRFT（退化 MDP, T=1）と Agentic RL（POMDP, T>1）を形式的に区別し、能力軸（計画・ツール利用・記憶・自己改善・推論・知覚）× タスク軸（検索・コード・数学・GUI・ビジョン・身体化・MAS・その他）の二重タクソノミーで 500 本超を体系化。PPO 系 5・DPO 系 8・GRPO 系 18 の RL アルゴリズム変種比較（表 2）、環境 40+（表 10）、フレームワーク 23（表 11）のカタログ。§6.4 で RL メカニズム論争を約 2/3 増幅器 vs 約 1/3 新知識と定量整理。信頼性（セキュリティ・幻覚・追従性）・エージェント訓練のスケールアップ・環境のスケールアップを主要未解決課題として提示。**ページ作成**: source 1 + entity 1（[[Heng Ji]]）。**ページ更新**: [[Guibin Zhang]]（リンク修正）・[[Zhenfei Yin]]（責任著者追記）・[[Lei Bai]]（責任著者追記）・[[Philip Torr]]（シニア著者追記）・[[エージェント型強化学習]]（定義に POMDP 形式化追記、横断的知見 3 点・未解決の問い 2 点追加）・[[強化ファインチューニング]]（PBRFT vs Agentic RL 形式的境界追記）・[[強化学習スケーリング]]（4 軸スケーリング整理追記）。**位置づけ**: 本 wiki の RL 系列に分野定義的サーベイとして加わる。個別手法論文（IsoCompute Playbook・ScaleRL・Scaling Behaviors・Scaling Up RL・DeepSWE・Agent-R1・AgentRL）が攻める個別課題を俯瞰する地図。（source +1・entity +1）。 2026-06-05: [[NVIDIA]] の 1.5B モデル長期 RL 訓練論文を **wiki-ingest-paper** で取り込み。[[@2025__arXiv__Scaling Up RL - Unlocking Diverse Reasoning in LLMs via Prolonged Training]]（arXiv:2507.12507, 2025）: [[Mingjie Liu]]・[[Yejin Choi]] ら NVIDIA チームによる、DeepSeek-R1-Distill-Qwen-1.5B に 5 ドメイン（数学・コード・STEM・論理パズル・指示追従）の検証可能報酬タスクで長期 RL を適用した体系的調査。GRPO + DAPO 拡張（分離クリッピング・動的サンプリング）+ KL 正則化 + 参照方策リセットの訓練レシピを 8 ランの逐次訓練（ハードリセット）で適用し、[[Nemotron-Research-Reasoning-Qwen-1.5B]] を開発。ベースライン対比で数学 +14.7%・コード +13.9%・論理パズル +54.8%。KL 除去時にエントロピー崩壊とコード性能の急落が生じることを示し、KL 正則化が初期チェックポイントの強さに応じて長期訓練を安定化する知見を提供。多ドメイン統合訓練がドメイン特化モデル（DeepScaleR・DeepCoder）と競争力を持つ一方、Reasoning Gym の一部タスクでは汎化に限界。[[VeRL]] フレームワーク上で 4×8×H100-80GB・約 16,000 GPU 時間。**ページ作成**: source 1 + entity 4（[[Mingjie Liu]]・[[Yejin Choi]]・[[NVIDIA]]・[[Nemotron-Research-Reasoning-Qwen-1.5B]]）。**ページ更新**: [[VeRL]]（NVIDIA 使用追記）・[[強化学習スケーリング]]（横断的知見 2 点追加）・[[強化ファインチューニング]]（KL 正則化の横断的知見追加）。**位置づけ**: 本 wiki の RL スケーリング系列に 4 本目として加わる。Scaling Behaviors がモデルサイズ×データ量のべき乗則、Art of Scaling RL が設計選択のアブレーション、IsoCompute Playbook がサンプリング計算量の配分処方を扱うのに対し、本論文は「長期 RL の道中で何が壊れるか」を実践的に示す——スケーリング則のフィッティングと段階的レシピの統合が次の課題。（source +1・entity +4）。 2026-06-05: [[Meta]]/[[UT Austin]]/UC Berkeley/Harvard/Periodic Labs の [[Devvrit Khatri]]・Lovish Madaan・[[Rishabh Agarwal]] らによる LLM RL 計算スケーリングの初の大規模系統的研究を **wiki-ingest-paper** で取り込み。[[@2025__arXiv__The Art of Scaling Reinforcement Learning Compute for LLMs]]（arXiv:2510.13786, 2025）: 400,000 GPU 時間超の系統的アブレーションで、RL 事後学習の性能をシグモイド型飽和曲線 R_C - R_0 = (A - R_0) / (1 + (C_mid/C)^B) でモデル化し、漸近性能 A と計算効率 B を分離する予測的フレームワークを提案。6 軸（RL セットアップ・損失関数・精度・損失集約・アドバンテージ正規化・カリキュラム）の設計選択アブレーションから統合レシピ [[ScaleRL]] を構築。[[PipelineRL]]-8 + CISPO + FP32 精度修正 + プロンプトレベル損失集約 + バッチレベルアドバンテージ正規化 + ゼロ分散フィルタリング + No-Positive-Resampling の 7 成分で、8B で A=0.61（GRPO 0.45・DAPO 0.53 を凌駕）、100,000 GPU 時間のランで 50k からの外挿が実測と整合。Scout 17B×16 MoE で A=0.71。**ページ作成**: source 1 + entity 5（[[Devvrit Khatri]]・[[Rishabh Agarwal]]・[[ScaleRL]]・[[PipelineRL]]・[[UT Austin]]）。**ページ更新**: [[強化学習スケーリング]]（シグモイドモデルを定義に追記、横断的知見 3 点・未解決の問い 2 点追加）・[[強化ファインチューニング]]（ScaleRL をソースに追加）。**位置づけ**: 本 wiki の RL スケーリング系列（Scaling Behaviors・IsoCompute Playbook）に続く 3 本目。べき乗則（Scaling Behaviors）とシグモイド（ScaleRL）が相補的であることを示し、設計選択の効果を「A を上げるもの」と「B のみを変調するもの」に二分する新しい構造を導入。（source +1・entity +5）。 2026-06-05: [[Shanghai AI Laboratory]]/[[University of Oxford]]/[[University of Science and Technology of China]] の LLM RL 事後学習スケーリング則論文を **wiki-ingest-paper** で取り込み。[[@2025__arXiv__Scaling Behaviors of LLM Reinforcement Learning Post-Training]]（arXiv:2509.25300, 2025）: [[Zelin Tan]]・[[Chen Zhang (Shanghai AI Lab)]]・[[Zhenfei Yin]] ら 12 名による、GRPO による RL 事後学習のスケーリング則を 63 モデル超で初めて体系化した研究。Qwen2.5（0.5B〜72B）で計算量制約・データ制約・データ再利用の 3 資源体制を横断し、テスト損失 log L(N,X) = -k(N)·log X + E(N) の対数線形べき乗則が R² > 0.99 で成立することを実証。学習効率 k(N) は K_max/(1+N_0/N) で飽和し 32B 以降で改善が鈍化、データ再利用は τ ≤ 25 で有効。Llama 3（1B〜70B）でアーキテクチャ非依存に再現。損失分解 L(N,D) = L_∞ + G(N) + λ(N)·P(N,D) で事前学習損失と RL ゲインを分離。ドメイン転移は同種数学で正の汎化、異種ドメイン(コード等)で微弱〜負の汎化。全実験に [[VeRL]] プラットフォームを使用。**ページ作成**: source 1 + entity 6（[[Zelin Tan]]・[[Chen Zhang (Shanghai AI Lab)]]・[[Zhenfei Yin]]・[[University of Oxford]]・[[VeRL]]・[[GRPO]]）。**ページ更新**: [[強化ファインチューニング]]（横断的知見 1 点追加）・[[強化学習スケーリング]]・[[エージェント型強化学習]]。**位置づけ**: 本 wiki の RL スケーリング系列（IsoCompute Playbook・Art of Scaling RL）に続く 3 本目で、GRPO に限定した最大規模のスケーリング実証。IsoCompute Playbook がサンプリング計算量の最適配分、Art of Scaling RL が設計選択のアブレーションを扱うのに対し、本論文はモデルサイズ×データ量の基本スケーリング則を定式化する——3 論文で RFT の計画・実行・資源配分の各面を相補的にカバーする。（source +1・entity +6）。 2026-06-05: [[@2026__arXiv__IsoCompute Playbook - Optimally Scaling Sampling Compute for LLM Reinforcement Learning]]（UCSD/CMU/MBZUAI、arXiv 2026）を **wiki-ingest-paper** で取り込み。LLM RL ポスト訓練における計算最適配分則を約 12 万 H200 時間の実験で導出。計算予算 C = Bp * n * M において最適並列ロールアウト数 n*(C) がシグモイド飽和し、問題難度別に二重機構（易問題でのシャープニング worst@k / 難問題でのカバレッジ拡大 best@k）が作用することを実証。Healthy RL レシピ（難度別正則化: 易問題に KL+エントロピー正則化・難問題には正則化なし、sqrt 学習率スケーリング）と計算最適配分を組み合わせ、Qwen2.5-7B を AIME 2025 で 72.5% まで引き上げた。事前学習の Chinchilla 則に対応する RL ポスト訓練初のスケーリング則であり、問題間干渉（Inter-problem Interference）の定量化も提示。**ページ作成**: source 1 + entity 3（[[Aviral Kumar]]・[[Zhiting Hu]]・[[MBZUAI]]）+ concept 2（[[強化学習スケーリング]]・[[エージェント型強化学習]]）。**ページ更新**: [[強化ファインチューニング]]（横断的知見に GRPO スケーリング知見追記、関連に強化学習スケーリング追加）。（source +1・entity +3・concept +2）。 2026-06-05: [[Tsinghua University]]/[[Z.AI]] のマルチターン・マルチタスク・エージェント型 RL 訓練フレームワーク [[AgentRL]] を **wiki-ingest-paper** で取り込み。[[@2025__arXiv__AgentRL - Training Language Model Agents with Reinforcement Learning]]（arXiv:2510.04206, 2025）: [[Hanchen Zhang]]・[[Xiao Liu]] ら 14 名による、マルチターン対話環境で LLM エージェントを GRPO ベースの RL で訓練するフレームワーク。(1) 交差方策サンプリング（現行モデルと過去モデル版で並行探索し、成功軌跡の多様性を確保）、(2) タスク別アドバンテージ正規化（タスク間の報酬スケール差を吸収）、(3) 完全非同期生成-訓練パイプライン（GPU 利用率最大化）、(4) コンテナ化異種環境デプロイ（Docker で 5 環境を統一管理）の 4 設計を統合。[[AgentBench]]-FC 5 環境（ALFWorld・DB・KG・OS・WebShop）で平均成功率 70.4% を達成し、GPT-5・Claude-Sonnet-4・DeepSeek-R1 を上回る。マルチタスク単一モデルが 5 つのタスク別最良モデルと同等の性能に到達する点が注目。**ページ作成**: source 1 + entity 6（[[AgentRL]]・[[Hanchen Zhang]]・[[Xiao Liu]]・[[Yuxiao Dong]]・[[Z.AI]]・[[AgentBench]]）。**ページ更新**: [[エージェント型強化学習]]（横断的知見 2 点・未解決の問い 2 点追加）。**位置づけ**: 本 wiki のエージェント型 RL 系列（AutoForge・DeepSWE・IsoCompute Playbook・Agent-R1）に続く 5 本目。マルチタスク訓練で単一モデルがタスク別スペシャリストに匹敵する汎化を実証した点が既存ソースにない固有知見。交差方策サンプリングは IsoCompute Playbook のリプレイバッファとは異なり、過去チェックポイントの生成能力を直接活用する設計。（source +1・entity +6）。 2026-06-05: [[Agentica]]/[[Together AI]] の完全オープンソース RL 訓練コーディングエージェント [[DeepSWE]] のブログ記事を **wiki-ingest** で取り込み。[[@2025__Together AI__DeepSWE - Training a Fully Open-sourced State-of-the-Art Coding Agent by Scaling RL]]（together.ai/blog/deepswe, 2025-07-02）: Qwen3-32B から SFT なしの純粋強化学習(GRPO++)のみで訓練し、[[SWE-Bench-Verified]] で Pass@1 42.2%・Pass@16 71.0%・ハイブリッド Best@16 59.0% を達成しオープンウェイト SOTA。GRPO++ は DAPO の Clip High・Dr.GRPO の Length Normalization・LOO に加え、新規の **Compact Filtering**(不完全軌跡の損失マスク)を統合。テスト通過の二値報酬のみで訓練。64 H100 で 6 日間、4,500 問の [[R2E-Gym]] サブセットを使用。SFT ウォームスタート(Claude Sonnet 3.7/4)の否定的結果も報告。**ページ作成**: source 1 + entity 10（[[DeepSWE]]・[[Together AI]]・[[Agentica]]・[[Ion Stoica]]・[[Raluca Ada Popa]]・[[rLLM]]・[[R2E-Gym]]・[[SWE-Bench-Verified]]・[[Michael Luo]]・[[Naman Jain]]）。**ページ更新**: [[強化ファインチューニング]]（横断的知見 2 点・未解決の問い 1 点追加）。**位置づけ**: 本 wiki 初の RL スケーリングによるコーディングエージェント訓練の一次情報。RFT-FM が訓練プロセスの障害を外側から管理するのに対し、DeepSWE は Compact Filtering で不完全軌跡を訓練内部で排除する対照的設計。（source +1・entity +10）。 2026-06-05: **[[Yuuki Tsubouchi]] 自身の 2021 年 eBPF トレーシング技術解説を wiki-ingest で取り込み（114 ソース目）**。[[@2021__yuuk.io__Linux eBPF Tracing Technology]]（ゆううきブログ 2021-12-28）: BPF アーキテクチャ（VM/Verifier/JIT/Maps）、イベントソース 2 系統（動的: Kprobe/Uprobe・静的: tracepoint/USDT）、開発ツールチェーン 3 段（[[bpftrace]] アドホック探索 → [[BCC]] ラピッドプロトタイプ → [[libbpf]]+CO-RE 本番実装）、CO-RE の仕組み（BTF + ランタイム再配置でカーネルバージョン横断）。**ページ作成**: source 1（[[@2021__yuuk.io__Linux eBPF Tracing Technology]]）+ entity 1（[[bpftrace]]）。**ページ更新**: [[eBPF]]（eBPF トレーシング基礎技術セクション追加）・[[BCC]]（詳細化・ツールチェーン表追加）・[[libbpf]]（CO-RE 解説追加）・[[Yuuki Tsubouchi]]（本記事追記）・[[index]]・[[log]]・[[hot]]。**位置づけ**: 2021 年時点の eBPF 基礎技術解説であり、[[go-conntracer-bpf]]（libbpf 実装）の技術的背景、[[eInfer]]・[[ProfInfer]]・[[eACGM]] 等の 2024 年以降の eBPF×AI 研究群の共通実装知識にあたる。本 vault で eBPF 分野の一次資料としては eunomia.dev 総説（2026）の次に取り込んだ vault 所有者自身の著作。**実カウント: source 114・entity 593・concept 63・question 1 = 総 771 ページ・実ソース 114**（source +1・entity +1）。 2026-06-05: [[NVIDIA]] の LLM 推論ベンチマーク基礎解説記事を **wiki-ingest** で取り込み（113 ソース目）。**ユースケース別 ISL/OSL プロファイルと [[GenAI-Perf]] のメトリクス定義を wiki に追加した回**。[[@2025__NVIDIA__LLM-Inference-Benchmarking-Fundamental-Concepts]]（NVIDIA Developer Blog 2025-04-02）: 翻訳（ISL≈OSL≈500〜2000）・生成（ISL≈100/OSL≈1000）・要約（ISL≈1000/OSL≈100）・推論（ISL≈100/OSL≈1000〜10000）の 4 ユースケースプロファイル、GenAI-Perf vs LLMPerf の ITL 計算差異（TTFT を含むか否か）と TPS 分母定義の違い、ロードテストとパフォーマンスベンチマークの目的区別。**ページ作成**: source 1 + entity 3（[[GenAI-Perf]]・[[TensorRT-LLM]]・[[NVIDIA NIM]]）。**ページ更新**: [[LLM推論]]（ユースケース ISL/OSL プロファイル・ツール間計算差異の横断的知見 2 点追加）。**実カウント: source 113・entity 592・concept 63・question 1 = 総 769 ページ・実ソース 113**（source +1・entity +3）。 2026-06-05: LLM 分散推論基盤の技術記事 4 本を **wiki-ingest** で並行取り込み（109〜112 ソース目）。**さくらインターネット[[高火力 PHY]]（H100 HGX）での Prefill-Decode Disaggregation の基礎理論から実測検証まで一貫した連載 3 本と、LLM 推論ベンチマーク測定の基礎解説 1 本を wiki に加えた回**。**(1) [[@2025__さくらのナレッジ__分散推論基盤やその前提の考え方]]**（[[道下幹也]]、さくらのナレッジ 2025-11-11）: LLM 推論の性能指標体系（TTFT/ITL/TPOT/E2EL/TPS/RPS/Goodput）、KV Cache と Prefill（計算バウンド）/Decode（メモリバウンド）の二段構造、バッチ戦略 4 種（Static/Dynamic/Continuous/Chunked-Prefill）、PD 分離の利点・欠点、KV Cache 転送のボトルネック（GB オーダー）。「KV Cache を設計の中心に据える」が定石。**(2) [[@2025__さくらのナレッジ__分散推論基盤の基礎技術]]**（道下、2025-12-23）: Scale Up Network（NVLink 5.0: 900GB/s）vs Scale Out（400Gbps NIC）、GPUDirect RDMA の 2 実装（PeerDirect レガシー vs dma-buf 推奨）、[[UCX]]（UCT/UCP 構成）と [[NIXL]]（NB API/SB API + 5 バックエンド）のアーキテクチャ。H100 HGX × 2 台ベンチマークで NIXL+UCX の KV Cache 転送ボトルネックが**物理リンク帯域に収束**することを実証（NVLink 400GB/s、リモート 50GB/s）。**(3) [[@2026__さくらのナレッジ__高火力PHYを利用した分散推論基盤の性能検証]]**（道下、2026-03-25）: [[vLLM]]+[[LMCache]]+NIXL+UCX スタックで gpt-oss-120b（H100 HGX）の PD 分離を実測。入力 8k・32 並列で Aggregated の ITL P99 > 100ms に対し PD 分離は < 30ms（HoL ブロッキング回避）。入力 1k では Aggregated が同等以上——メリットはワークロード依存。GPU 追加は TTFT に有効だが ITL は GPU 間通信コストで悪化。「継続的に観測・改善する最適化ループ」の重要性。**(4) [[@2026__Zenn__MLエンジニアのための本質から理解するLLM推論]]**（[[Kazuki Fujii]]、[[東京科学大学]]、Zenn 2026-05-30）: 推論の 4 段階（Prompt→Queuing→Prefill→Generation）、ISL/OSL/TTFT/ITL/TPS/E2EL の定義体系、ツール間の ITL 定義差異、「計算内容の本質的理解が不可欠」。**横断的知見**: (1) Goodput は SLO 達成スループットを示す指標であり、生スループット(TPS/RPS)とは区別される——道下の例では 10 RPS が SLO 制約で 3 RPS に低下。(2) PD 分離は Prefill と Decode の独立リソーススケーリングを可能にするが、メリット享受は「入力長が長く、リクエストが高並行」のワークロードに限定される。(3) KV Cache 転送のボトルネックは NIXL+UCX で物理帯域に収束するが、100 並行リクエスト時の GB オーダー転送は 400Gbps でも秒単位を要する。**ページ作成**: source 4 + entity 8（[[道下幹也]]・[[高火力 PHY]]・[[vLLM]]・[[NIXL]]・[[UCX]]・[[LMCache]]・[[Kazuki Fujii]]・[[東京科学大学]]）。**ページ更新**: [[LLM推論]]（横断的知見 2 点・未解決の問い 1 点追加）・[[SAKURA Internet]]。**実カウント: source 112・entity 589・concept 63・question 1 = 総 765 ページ・実ソース 112**（source +4・entity +8）。 2026-06-05: [[@2024__TMLR__Efficient Large Language Models - A Survey]]（[[Mi Zhang]] ほか OSU/UMich/Imperial 等、TMLR 2024, 67p）を **wiki-ingest-paper** で取り込み（108 ソース目）。**LLM 効率化手法をモデル中心・データ中心・フレームワーク中心の 3 軸で体系化した包括的サーベイを wiki に追加した回**。400 以上の参考文献を網羅し、モデル圧縮（量子化 PTQ/QAT・プルーニング・低ランク近似・知識蒸留）、効率的事前学習（混合精度・スケーリングモデル・ZeRO）、効率的ファインチューニング（LoRA 系 PEFT・QLoRA 系 MEFT）、効率的推論（投機的復号・KV キャッシュ・vLLM/Orca）、効率的アーキテクチャ（FlashAttention・MoE・Mamba/SSM・長コンテキスト）、データ選択・プロンプト工学、17 フレームワーク比較（Table 2）を統合的タクソノミーで整理。**横断的知見**: (1) モデル圧縮の 4 手法は直交的に組み合わせ可能であり、量子化が圧縮-精度トレードオフで他手法を凌駕する傾向にある。(2) 推論はアルゴリズムレベル（投機的復号・KV キャッシュ）とシステムレベル（連続バッチング・PagedAttention）の二重最適化が効く。(3) モデル圧縮→推論の直列最適化（例: FlexGen が重み+KV キャッシュ 4 ビット量子化で OPT-175B を単一 16GB GPU で推論）が実効的。既存の Miao+ サービングサーベイが推論フレームワーク 10 種に特化するのに対し、Wan+ は推論をモデル中心手法全体の一部として位置づけ相補的な俯瞰を提供する。**ページ作成**: source 1 + entity 3（[[Mi Zhang]]・[[Mosharaf Chowdhury]]・[[The Ohio State University]]）+ concept 1（[[モデル圧縮]]）。**ページ更新**: [[LLM推論]]（横断的知見 2 点追加）・[[Mixture-of-Experts]]（横断的知見 1 点追加）。**実カウント: source 108・entity 581・concept 63・question 1 = 総 753 ページ・実ソース 108**（source +1・entity +3・concept +1）。 2026-06-05: [[@2025__ACM Computing Surveys__Towards Efficient Generative Large Language Model Serving]]([[Xupeng Miao]] ほか Purdue/CMU、ACM Computing Surveys 2025, 37p)を **wiki-ingest-paper** で取り込み(107 ソース目)。**LLM サービングの効率化を初めてアルゴリズム/システムの 2 軸で体系化した包括的サーベイを wiki に加えた回**。375 本の参考文献を網羅し、アルゴリズム革新(復号アルゴリズム 4 種・アーキテクチャ設計 5 種・モデル圧縮 2 種)とシステム最適化(量子化・並列計算 4 種・メモリ管理・スケジューリング・カーネル最適化 4 種)のタクソノミーを提示。10 種の代表的オープンソースフレームワーク(vLLM・FlexFlow-Serve・TensorRT-LLM 等)をカーネル実装・並列戦略・最適化目標で横断比較し、低レイテンシと高スループットの双対性を論証。**横断的知見**: (1) 投機的復号が出力品質を保持できる唯一のアルゴリズム的高速化手法であり、SpecInfer の木構造検証が後続(Medusa・EAGLE・Sequoia)の設計基盤になった。(2) vLLM のページドアテンション + Orca のイテレーション粒度スケジューリングが現代 LLM サービングの設計基盤を形成。(3) Prefill-Decode 分離(Splitwise)が TTFT/TPOT の独立最適化を可能にする新アーキテクチャパターン。既存 wiki の ProfInfer/eInfer が示す Prefill=計算バウンド/Decode=メモリバウンドのフェーズ差は、この双対性の物理的根拠と一致する。**ページ作成**: source 1 + entity 4([[Xupeng Miao]]・[[Zhihao Jia]]・[[Tianqi Chen]]・[[Purdue University]])。**ページ更新**: [[LLM推論]](横断的知見 2 点・未解決の問い 3 点追加)。**実カウント: source 107・entity 578・concept 62・question 1 = 総 748 ページ・実ソース 107**(source +1・entity +4)。 2026-06-05: [[@2024__yuuk.io__The-World-of-LLM4SRE]]([[Yuuki Tsubouchi]] 著、blog.yuuk.io 2024-03-21)を **wiki-ingest** で取り込み(106 ソース目)。**vault 所有者が 2024 年 3 月に書いた LLM4SRE フィールドサーベイ記事**——ファインチューニング / RAG / エージェント型の 3 分類、代表論文(Ahmed ICSE'23・Oasis・RCACopilot・RCAgent・D-Bot・Panda)、将来課題(スナップショット戦略・Runbook 統合・説明可能性・人間-AI 協調)を整理した 2024 年時点の地図。既存 wiki の多数の論文(D-Bot・RCACopilot・RCAgent・FLASH・LLexus・StepFly 等)と接続。「LLM を推論機械として捉え、熟練 SRE の反復診断プロセスを再現できる」という著者の着眼が本 wiki 全体の問題意識と一致する。**ページ作成**: source 1([[@2024__yuuk.io__The-World-of-LLM4SRE]])。**ページ更新**: [[Yuuki Tsubouchi]]・[[根本原因分析]]・[[index]]・[[hot]]・[[log]]・manifest。**実カウント: source 106・entity 574・concept 62・question 1 = 総 743 ページ・実ソース 106**(source +1)。 2026-06-05: 分散トレーシング・ログ解析・テレメトリ最適化の論文 8 本を **wiki-ingest-paper** で subagent 並行取り込み(99–105 ソース目、実ファイル 105)。**「テレメトリデータの収集量を情報損失最小で削減する」を共通問題とし、メトリクス(PMF)・ログ(LogReducer/LogCleaner)・トレース(Hindsight/Tracezip/Astraea/Mint/TraStrainer)の 3 モダリティを横断する回**。**(1) [[@2024__IEEE CLOUD__Enabling Programmable Metric Flows]]**([[Kangjin Wang]] ら [[IBM Research]]): [[PMF]]。collect-first→use-first パラダイムで LP 最適化によりメトリクスパイプラインの冗長収集を排除。**(2) [[@2023__ICSE__LogReducer - Identify and Reduce Log Hotspots in Kernel on the Fly]]**([[Guangba Yu]]・[[Pengfei Chen]] ら [[Tencent]]/HUST): [[LogReducer]]。eBPF + 動的 EMFP でカーネルログホットスポットを 70〜95% 削減、[[WeChat]] 本番 1 年超。**(3) [[@2024__ESEM__Reducing Events to Augment Log-based Anomaly Detection Models - An Empirical Study]]**: [[LogCleaner]]。TF-IDF/クラスタリング/エントロピーの 3 削減戦略で 6 異常検知モデル×4 データセットを実証。**(4) [[@2023__NSDI__Hindsight - Tracing Edge-Cases in Distributed Systems]]**([[Jonathan Mace]] ら [[Max Planck Institute for Software Systems]]): [[Hindsight]]。遡及的トレースサンプリング——全リクエストを軽量にトレースし障害検知後に完全トレースを収集(100 万 req/s・30 秒以内)。**(5) [[@2025__ISSTA__Tracezip - Efficient Distributed Tracing via Trace Compression]]**([[Zhuangbin Chen]]・[[Zibin Zheng]] ら [[Sun Yat-sen University]]): [[Tracezip]]。共通性・変動性分解でトレースを 80% 超圧縮しつつ異常検知精度を保持。**(6) [[@2024__IEEE CLOUD__Astraea - Unleashing Performance Insights with Online Probabilistic Tracing]]**([[Mehmet Toslali]]・[[Ayse K. Coskun]] ら [[Boston University]]): [[Astraea]]。スパンレベル [[VAIF]] で 1% サンプリングでもヘッドベース同等の性能分析。**(7) [[@2025__ASPLOS__Mint - Cost-Efficient Tracing with All Requests Collection via Commonality and Variability Analysis]]**([[Guangba Yu]]・[[Pengfei Chen]] ら): [[Mint]]。共通性・変動性分析で全リクエスト収集しつつストレージ 60% 削減。**(8) [[@2024__FSE__TraStrainer - Adaptive Sampling for Distributed Traces with System Runtime State]]**([[Haiyu Huang]]・[[Pengfei Chen]] ら [[Huawei Technologies]]): [[TraStrainer]]。実行時状態で tail-based sampling を強化し F1 +15%。新概念 [[トレースサンプリング]] を作成。**ページ作成**: source 8 + entity 18 + concept 1。**ページ更新**: [[テレメトリ]]・[[Scaling Telemetry Workloads]]・[[異常検知]]・[[特徴量削減]]・[[eBPF]]・[[ログ解析]]・[[ログパース]]・[[ログ生成]]・[[分散トレーシング]]・[[根本原因分析]] ほか entity 16。**実カウント: source 105・entity 574・concept 62・question 1 = 総 742 ページ・実ソース 105**(source +7〜8・entity +14〜18・concept +1)。 2026-06-05: USENIX NSDI '26 の論文 6 本を **wiki-ingest-paper** で subagent 並行取り込み(93–98 ソース目)。**LLM 訓練インフラの規則性(同期分散学習の反復構造)を共通前提として、性能診断・シミュレーション高速化・プライバシー保護テレメトリ・DCN 設計自動化・集合通信スケジューリングの 5 応用面を横断する回**。**(1) [[@2026__NSDI__EROICA - Online Performance Troubleshooting for Large-scale Model Training]]**([[Yu Guan]] ら Alibaba Cloud/[[Zhejiang Lab]]): ~100,000 GPU 本番クラスタで 1.5 年運用した性能診断システム EROICA。全ワーカー同時オンラインプロファイリング + 関数挙動パターン差分(β/μ/σ ベクトル + D/Δ 距離)で 97.5% 診断成功率。HW 44.4%・App 48.2% の根本原因分布が GPU クラスタ運用の参照点に。**(2) [[@2026__NSDI__Supercharging Packet-level Network Simulation of Large Model Training via Memoization and Fast-Forwarding]]**([[Dan Li]] ら Tsinghua/[[Zhongguancun Laboratory]]): Wormhole。DP フローの繰り返し競合パターンとステディステート(97〜99%)をメモ化・早送りし、フロー競合グラフ(FCG)で ns-3 比 744〜1012× の高速化を誤差 1% 未満で達成。**(3) [[@2026__NSDI__PrvTel - Lightweight Models for Private and Accurate Telemetry Data Retention]]**([[Fuheng Zhao]] ら UMD): ε-差分プライバシー付き軽量 VAE でテレメトリを保持。無損失圧縮比 50 倍のコスト削減 + クロスフィールドクエリ精度 60% 向上を両立。**(4) [[@2026__NSDI__Matryoshka - Realizing Hyperscale Data Center Network Design for the AI Era]]**(Cai ほか [[Meta]]/[[Max Planck Institute for Informatics]]): DCN 設計自動化。インテント駆動・決定論的・ステートレスなコンパイラで 6 年間・約 900 DCN・100K-GPU スーパークラスタを支える。**(5) [[@2026__NSDI__FAST - An Efficient Scheduler for All-to-All GPU Communication]]**(Lei ほか CMU/[[MangoBoost]]/[[University of Pennsylvania]]): MoE AllToAllv の動的歪み(最大 12×)を Birkhoff 分解で多項式時間スケジューリング。64 GPU 221 µs、RCCL 比最大 4.48× 向上。**(6) [[@2026__NSDI__HeteCCL - Synthesizing Near-Optimal Collective Communication Schedules for Heterogeneous GPU Clusters]]**(Hei ほか [[Northeastern University]]/Alibaba Cloud): ヘテロジニアス GPU クラスタ向け集合通信スケジュール自動合成。チャンキング + CEGIS で NCCL 比 2.8× 帯域幅・訓練 23〜37% 改善。**ページ作成**: source 6 + entity 10 + concept 2([[ネットワークシミュレーション]]・[[差分プライバシー]])。**ページ更新**: [[集合通信]]・[[Mixture-of-Experts]]・[[LLM分散学習]]・[[オープンネットワーキング]]・[[テレメトリ]]・[[近似クエリ処理]]・[[LLM学習モニタリング]]・[[GPUクラスタ運用]]・[[ストラグラー]]・[[Fault Localization]]。**実カウント: source 98・entity 560・concept 62・question 1 = 総 721 ページ・実ソース 98**(source +6・entity +10・concept +2)。 2026-06-05: [[@2026__ASE__OpsAgent - An Evolving Multi-agent System for Incident Management in Microservices]]([[Yu Luo]] ら南開大学/Alibaba Cloud/[[Lenovo]]/清華大学、ASE '26, arXiv:2510.24145)を **wiki-ingest-paper** で取り込み(91 ソース目)。**マイクロサービスのインシデント管理に向けた自己進化型 MAS を wiki に加えた回**——OPENRCA ベンチマーク(335 件・68GB テレメトリ)で SOTA 比 Correct +46.63%、[[Lenovo]] 本番 53 日・10,492 件 84.09%・解決時間 2.5h→126s を達成。核心設計: (1)**training-free データプロセッサ**(メトリクス: 3σ+CNN 形状分類→テキスト、ログ: keyword+TF-IDF Drain3、トレース: 95 パーセンタイル+3 ホップコールパス)がシステム固有の再学習なしに異種観測データをエージェント共通言語に変換——アブレーションでプロセッサ除去時 Correct 2.26%、(2)**3 専門エージェント**(Anomaly Sentinel/Failure Diagnoser/Root Detective)+クロスレビュー機構が並行 CoT 推論後に相互批評して監査可能なRoot Cause Report を生成——クロスレビュー除去で Correct 6.77%、(3)**デュアル自己進化**(PPO 強化学習+反省ベース知識蒸留 RAG)が静的知識を超えた継続的能力成長を実現——訓練割合 0→60% で Correct 8.27→16.54%。横断的知見: training-free テキスト変換が cross-system 汎化と MAS 協調の両方を同時に解く設計。ページ作成: source 1 + entity 2([[Yu Luo]]・[[Lenovo]])。更新: [[Yongqian Sun]]・[[Shenglin Zhang]]・[[Nankai University]]・[[Dan Pei]]・[[インシデント管理]]・[[根本原因分析]]・[[マルチモーダル障害診断]]。**実カウント: source 91・entity 548・concept 58・question 1 = 総 698 ページ・実ソース 91**(source +1・entity +2)。 2026-06-05: [[@2025__TOS__Lustre Unveiled - Evolution, Design, Advancements, and Current Trends]]([[Anjus George]] ほか ORNL/Whamcloud/DDN、ACM TOS 2025)と [[@2019__arXiv__The Lustre Storage Architecture]]([[Peter J. Braam]]、CFS、arXiv:1903.01955)の 2 本を **wiki-ingest-paper** で同時取り込み(89–90 ソース目)。**本 wiki 初の[[並列ファイルシステム]]の一次論文**——25 年の設計進化を初期構想からエクサスケール実績まで一望。George+2025 は 109 ページ包括サーベイ(アーキテクチャ/5 系統比較/Frontier Orion 700 PB 4.7 TiB/s/将来方向性 5 件)、Braam 2019 は 539 ページの原初設計文書「Lustre Book」。横断的知見: 初期構想(WBC/分散 MDS)の実現に 20 年超、POSIX 互換性の重力が設計進化を律速、DAOS のロックレスモデルが構造的脱却を示す。ページ作成: source 2 + entity 11 + concept 1([[並列ファイルシステム]])。更新: [[Oak Ridge National Laboratory]]。**実カウント: source 90・entity 546・concept 58・question 1 = 総 695 ページ・実ソース 90**(source +2・entity +11・concept +1)。 2026-06-05: SLO/可用性メトリクスの論文 5 本を **wiki-ingest-paper** で一括取り込み(84–88 ソース目)。**可用性指標の 10 年系譜(2017→2026)を wiki に加えた回**——「何を測るべきか」(Mogul+ 2017)→「どう約束すべきか」(Mogul+Wilkes 2019)→「どう測るか」(Hauer+ 2020)→「どう分解するか」(Sedlak+ 2024)→「どう持続可能にするか」(Herrera+ 2026)の 5 段階を横断する新概念 [[サービスレベル目標]] を作成。**(1) [[@2017__HotOS__Thinking about Availability in Large Service Infrastructures]]**([[Jeffrey C. Mogul]] ら Google、HotOS 2017): 可用性のセキュリティ的思考——スレットモデリング・深層防御・フェイルスタティック。**(2) [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]]**([[Jeffrey C. Mogul]]・[[John Wilkes]]、HotOS 2019): SLE/CBE によるリスク明示的分担——法律家から統計家への転換。**(3) [[@2020__NSDI__Meaningful Availability]]**([[Tamás Hauer]] ら Google、NSDI 2020): ウィンドウ付きユーザーアップタイムで有意義性・比例性・実用性の三要件を同時に満たす初の可用性指標。G Suite 本番で評価・展開。**(4) [[@2024__SOSE__Diffusing High-level SLO in Microservice Pipelines]]**([[Boris Sedlak]] ら TU Wien、IEEE SOSE 2024): ベイズネットワークによる高レベル SLO の低レベルへの自動分解、充足率 83〜100%。**(5) [[@2026__arXiv__A Microservice-Based Platform for Sustainable and Intelligent SLO Fulfilment and Service Management]]**([[Juan Luis Herrera]] ら TU Wien、arXiv 2026): カーボン認識 SLO プラットフォーム [[CASCA]]、EMMa でカーボンフットプリントを報酬関数に組み込み SLO 充足とサステナビリティを両立。**横断的知見 4 点**: (1) 可用性メトリクスの進化に 10 年の系譜、(2) 高レベル SLO 自動分解とユーザーアップタイムが事前/事後で相補的フィードバックループを構成、(3) SLO とサステナビリティの緊張関係が AIOps の 4 段タクソノミに「コスト/持続可能性」の第 5 軸を加える可能性、(4) SLE/CBE のリスク分担枠組みが agentic SRE の安全仕様と同型。**ページ作成**: source 5 + concept 1([[サービスレベル目標]]) + entity 15(person 14 + product 1 [[CASCA]])。**更新**: [[Schahram Dustdar]](SLO 論文追記)・[[Google]](可用性・SLO 研究セクション追加)・各索引・index・hot・log・manifest。**実カウント: source 88・entity 535・concept 57・question 1 = 総 681 ページ・実ソース 88**(source +5・concept +1・entity +15)。 2026-06-05: [[@2020__SC20__Live Forensics for HPC Systems - A Case Study on Distributed Storage Systems]]([[Saurabh Jha]] ら UIUC/NCSA、SC 2020、PDF: saurabhjha.one/pubs/forensics_sc_2020.pdf)を **wiki-ingest-paper** で取り込み(83 ソース目)。**HPC ストレージという第三の箇所特定ドメインを wiki に加えた回**——cloud microservice(metric-based anomaly-propagation/degree)・GPU 訓練クラスタ(machine-level 類似度/絶対指標)に続き、[[Fault Localization]] に「能動 I/O プローブ + 確率的グラフィカルモデル(因子グラフ MCMC)」という手法系統が加わった。**核心の設計**: [[Kaleidoscope]] = Store Pings(CrWr/WrEx/RmEx の 3 種 I/O プローブ + Lustre パスピニングで確定経路)+ 因子グラフ PGM(コンポーネント健全性を隠れ変数・パス可達性を二項分布で観測・HA ペア冗長性を明示モデル化・MCMC 推論で健全確率推定)+ LOF(リソース過負荷診断)+ RAS ログ差分(信頼性障害診断)の階層。オーバーヘッド < 0.01%。**結果**: 2 年間 843 件本番インシデント、箇所特定 99.3%(837/843)・信頼性障害診断 98.3%(340/346)・過負荷診断 94.2%(468/497)。NetBouncer 比 TP 1.67 倍(184 vs 110)・アラーム 24 分の 1(4,892 vs 116,072)。LNET 部分障害(帯域 25% 低下が数週間未検知)を 5 分以内に検知。**新規横断的知見**: (1) HPC ストレージの箇所特定は能動プローブ+PGM という cloud/GPU クラスタと独立した第三系統。(2) 信頼性障害 vs リソース過負荷の 2 モード弁別は cloud(detection の中心問いの一形態)・GPU 訓練(Aegis の compute vs network 弁別)で同型に再現——Kaleidoscope の LOF/RAS ログ 2 枝が 2020 年に先行実装していた。(3) 能動プローブ+PGM と [[R-Pingmesh]] のネットワークトモグラフィ投票は設計思想が近く、統計推論 vs 投票の精度・スケーラビリティ比較が未解決。**ページ作成**: source 1([[@2020__SC20__Live Forensics for HPC Systems - A Case Study on Distributed Storage Systems]]) + entity 4([[Kaleidoscope]]/[[Blue Waters]]/[[Subho S. Banerjee]]/[[Zbigniew T. Kalbarczyk]])。**更新**: [[Saurabh Jha]]/[[Shengkun Cui]]/[[Tianyin Xu]]/[[Ravishankar K. Iyer]]/[[NCSA]](SC20 論文追記)・[[Fault Localization]](HPC ストレージ系統 2 点横断的知見追加・未解決の問い 2 点追加)・各索引・index・hot・log・manifest。**実カウント: source 83・entity 520・concept 56・question 1 = 総 660 ページ・実ソース 83**(source +1・entity +4)。 2026-06-05: [[@2026__arXiv__CUJBench - Benchmarking LLM-Agent on Cross-Modal Failure Diagnosis from Browser to Backend]]([[Haoming Meng]]、単著、所属なし、arXiv:2604.23455, 2026)を **wiki-ingest-paper** で取り込み(82 ソース目)。**ブラウザ可視層を診断の証拠空間に加えた初のベンチマークを wiki に収録した回**——AIOpsLab・ITBench・SREGym・Cloud-OpsBench はすべてバックエンドテレメトリのみで診断を評価してきたが、CUJBench は「スクリーンショット・DOM・ブラウザコンソール・ネットワーク要求 ⇆ バックエンドログ/トレース/メトリクス」というクロスモーダル推論を評価対象に加える初めての設計。**核心の設計**: OpenTelemetry Demo + Tractor Store の 2 アプリを Playwright で CUJ 実行し、HTTP レイヤー障害プロキシ + フィーチャーフラグ + ソースレベルミューテーションで 87 シナリオ(5 障害ファミリー: Baseline 2・Browser proxy faults 56・Backend flag faults 4・Compound faults 18・Frontend mutations 7)を決定論的スナップショットとしてパッケージ化。12 証拠アクセスツール + `submit_root_cause` の固定インターフェース。GPT-5.4 による 120 候補 → 多エージェント検証ループ(SRE レビュアー 2 体 + シニア仲裁 + コーディネーター) → 3 層アノテーション(自動/証拠根拠/人間)で 87 承認(72.5%)。**評価結果(446/450 完了、25 シナリオ部分集合)**: 全体 A@1=19.7%・天井=52%。モデル別: Claude Sonnet 4.6 (38.7%) > GPT-5.4 (25.3%) > Gemini 3.1 Pro (22.7%) > GLM-4.6V (16.9%) > Llama-4-Scout (8.0%) > Qwen3-VL (6.7%)。ベースライン別: Browser-only (28.0%) > Full agent (19.9%) > Retrieval (11.3%)。**反直感的発見**: ブラウザ限定がフルツールを上回る。Gemini 3.1 Pro は Browser-only→Full で SR 92%→40%・A@1 52%→12% に急落。Tractor Store 障害では決定的信号が DOM/ブラウザコンソールにのみ存在しバックエンド構造化テキストにはない。**3 つの構造的障害モード**: (1) ツール呼び出し形式の不安定性(Llama 35/36・Qwen 37/44 非提出、分析は一貫しているが形式不遵守)、(2) 探索の暴走とコンテキスト枯渇(Gemini 平均 92.6 呼び出し・4.0M トークン)、(3) 提出ランでの統合障害(ER=0.648 vs A@1=0.440 の解離——証拠は取れているが帰属できない)。**ページ作成**: source 1([[@2026__arXiv__CUJBench - Benchmarking LLM-Agent on Cross-Modal Failure Diagnosis from Browser to Backend]]) + entity 4([[Haoming Meng]]/[[CUJBench]]/[[OpenTelemetry Demo]]/[[Tractor Store]])。**更新**: [[SRE Benchmark]](ブラウザ可視層の第四の証拠軸・ツール追加が精度を下げる反直感・統合ボトルネック・形式不安定性を横断的知見 4 点追加、未解決の問い 2 点追加)・[[マルチモーダル障害診断]](ブラウザ-バックエンドのクロスモーダル統合という第 4 の軸・帰属ボトルネックの定量化を横断的知見 2 点追加、未解決の問い 1 点追加)・各索引・index・hot・log・manifest。**実カウント: source 82・entity 516・concept 56・question 1 = 総 655 ページ・実ソース 82**(source +1・entity +4 追加)。**出典検査**: 下記。 2026-06-05: [[@2025__KDD__FlowXpert - Expertizing Troubleshooting Workflow Orchestration with Knowledge Base and Multi-Agent Coevolution]]([[Binpeng Shi]]・[[Shenglin Zhang]] ら [[Nankai University]] + [[Huawei Cloud]]・[[Dan Pei]](Tsinghua)、KDD 2025, DOI:10.1145/3711896.3737221)を **wiki-ingest-paper** でローカル PDF から取り込み(81 ソース目)。**本 wiki の TSG 自動化クラスタ(FLASH/LLexus/StepFly=「実行」)に「ワークフロー生成」という上流問題を初めて加えた回**——Microsoft 3 本が「既存 TSG を LLM で実行する」のに対し、FlowXpert は「TSG 自体を運用ドキュメントから LLM で生成する」という、ゼロから構築アプローチで産業の自動化ギャップを埋める。**核心の設計**: Module1(Knowledge Base Construction): ①事前定義オントロジー(5 概念 Incident/Failure Description/Mitigation Steps/Typical Cases/Additional Note)によるインシデント固有ノード定義 → ②チャンクからのインシデント名抽出 → ③ノード充填(現在+直前チャンク) → ④ノードのマージ・精緻化で KG を構築。Standard RAG ベクトルベースと統合し $C^{(T)} = \{chunks_{topK}, nodes_{topN}\}$ を Planner に渡す。Module2(Multi-Agent Coevolution): Planner(PPO, $L_{CLIP}$, Scorer の 5 次元スコアを即時報酬)と Scorer(DPO, $L_{DPO}$, コンテキスト豊富度 3 レベルで制御した合成選好データ)が共進化。Best-of-N(N=3)でオンライン生成。**結果**: Qwen2.5-7B + FlowXpert(2nd iter)で OpsFlowBench 平均 STEPScore F1 71.9%。本番 10 週間(2024-10-21〜12-29)34,488 件・承認率約 80%・生成時間 22.1 秒(従来 7 人×7 時間)。AI Executor(Pangu-7B)で 5 種高頻度インシデントの対応時間最大 71% 削減。**ページ作成**: source 1([[@2025__KDD__FlowXpert - Expertizing Troubleshooting Workflow Orchestration with Knowledge Base and Multi-Agent Coevolution]]) + entity 3([[Binpeng Shi]]/[[FlowXpert]]/[[OpsFlowBench]])。**更新**: [[Shenglin Zhang]](FlowXpert 責任著者追記)・[[Dan Pei]](共著追記)・[[Nankai University]](FlowXpert 共著追記)・[[Huawei Cloud]](FlowXpert 産業実装追記)・[[TSG自動化]](ワークフロー生成/実行の軸追加・横断的知見/未解決の問い更新)・[[インシデント管理]](FlowXpert 横断的知見追加)・[[強化ファインチューニング]](PPO/DPO 共進化の設計問いを追加)・各索引・index・hot・log・manifest。**実カウント: source 81・entity 512・concept 56・question 1 = 総 650 ページ・実ソース 81**(source +1・entity +3 追加)。**出典検査**: 下記。 2026-06-05: [[@2025__SIGMOD__AgentTune - An Agent-Based Large Language Model Framework for Database Knob Tuning]]([[Yiyan Li]]・[[Haoyang Li]] ら [[Renmin University of China]] + [[ByteDance]] + [[University of Melbourne]]、SIGMOD 2025, DOI:10.1145/3769758)を **wiki-ingest-paper** でローカル PDF から取り込み(80 ソース目)。**DB チューニング問題への「タスク分解 × LLM エージェント × 木探索」設計の完全実証の回**——前回取り込んだ D-Bot(診断/MCTS)・DBAIOps(診断/KG)に続き、「DB 自律管理は診断と最適化の 2 軸で整備が進む」という構造的横断知見が確立した。さらにビームサーチ型木探索が診断(D-Bot UCT)と最適化(AgentTune Beam, k=2)で共通設計パターンとして反復することも判明。**核心の設計**: (1) Workload Analyzer — SQL 匿名化・クラスタリング・代表 SQL 要約でワークロード特性を自然言語化。(2) Knob Selector — Chain-of-Thought + ICL で関連ノブをスペース削減して選択。(3) Range Pruner — LLM でノブ範囲候補を絞り込み + ルールベース白箱検証で Invalid Times=0 を保証。(4) Configuration Recommender — メモリウィンドウ(過去 Top-K 設定記憶)+ ビームサーチ(k=2、3 候補ノード)+ セントロイド距離ランキング(構成空間での多数決)で収束。**結果**: 6 ベンチマーク(SYSBENCH/JOB/TPC-H/TPCC/SSAG/AMPS)全実験 Invalid Times=0・PIE 最高・スループット/レイテンシ SOTA。GPT-4 使用時コスト $20.17/898 秒/100 ステップ。新規メトリクス PIE(Performance Improvement Efficiency = P_gap/P_default / T_opt)を提案。**ページ作成**: source 1([[@2025__SIGMOD__AgentTune - An Agent-Based Large Language Model Framework for Database Knob Tuning]]) + concept 1([[データベースノブチューニング]]) + entity 7([[Yiyan Li]]/[[Haoyang Li]]/[[Jing Zhang]]/[[Cuiping Li]]/[[Hong Chen]]/[[Renata Borovica-Gajic]]/[[University of Melbourne]])。**更新**: [[データベース自律診断]](ビームサーチ共通パターン・DB 2 軸管理整備を横断的知見 2 点追加)・[[Renmin University of China]](AgentTune 著者陣を追記)・[[ByteDance]](AgentTune 共同開発・実世界ベンチマークを追記)・[[データベースノブチューニング]](新規 concept)・各索引・index・hot・log・manifest。**実カウント: source 80・entity 509・concept 56・question 1 = 総 646 ページ・実ソース 80**(source +1・concept +1・entity +7 追加)。**出典検査**: Table 1(6 ベンチマーク全数値)・Table 2〜4(スケーラビリティ)・Table 7(アブレーション)・Table 9(LLM 比較)・Figure 1(アーキテクチャ)・式(1)(セントロイド距離ランキング)を `.raw/papers/acm-3769758.txt` に遡及確認(✅)。著者所属は PDF Author Information に遡及(Renmin University of China / ByteDance / University of Melbourne)(✅)。DOI 10.1145/3769758・Proc. ACM Manag. Data(SIGMOD)は PDF ヘッダーに遡及(✅)。 2026-06-05: [[@2025__FSE Companion__A Multimodal Intelligent Change Assessment Framework for Microservice Systems Based on Large Language Models]]([[Yongqian Sun]]・[[Shenglin Zhang]]・[[Dan Pei]] ら [[Nankai University]] + [[Tsinghua University]]・[[BizSeer]]・[[Tencent]]、FSE Companion '25, DOI:10.1145/3696630.3728561)を **wiki-ingest-paper** でローカル PDF から取り込み(79 ソース目)。**ECD・FT・RCCA の 3 タスクを単一パイプラインで統合した最初のフレームワーク [[SCELM]] を wiki に収録した回**——これまで個別研究(SCWarn/Kontrast/Lumos/Funnel/Gandalf=ECD のみ、ChangeRCA=RCCA のみ、MicroCBR=FT のみ)がばらばらだったところに、SCELM が統合フレームワークを産業実証(11 か月・90% 時間短縮)とともに提示した。**核心の設計**: Module1(Drain ログテンプレート化・新規テンプレート自然言語保持・異常形状 11 種分類して自然言語化・変更票統合)→ Module2(RAG 履歴知識ベース: ベクトル化・Top Abnormal KPI クラスタリング)→ Module3(7B LLM: RAG+Adaptive Generation で評価レポート生成)。**ページ作成**: source 1 + concept 1([[ソフトウェア変更管理]]) + entity 8([[SCELM]]/[[Tinghua Zheng]]/[[Xidao Wen]]/[[Weihua Kuang]]/[[Heng Liu]]/[[Chao Shen]]/[[Bo Wu]]/[[BizSeer]])。**更新**: [[Yongqian Sun]]・[[Shenglin Zhang]]・[[Dan Pei]]・[[Nankai University]]・[[マルチモーダル障害診断]]・[[根本原因分析]]・各索引・hot・log・manifest。**実カウント: source 79・entity 502・concept 55 = 総 637 ページ**(source +1・concept +1・entity +8 追加)。 2026-06-05: [[@2025__TKDE__OpDiag - Unveiling Database Performance Anomalies Through Query Operator Attribution]]([[Shiyue Huang]]・[[Bin Cui]] ら [[Peking University]] + [[ZTE Corporation]]、IEEE TKDE Vol.37 No.6, DOI:10.1109/TKDE.2025.3557049)を **wiki-ingest-paper** でローカル PDF から取り込み(78 ソース目)。**DB 診断の解像度を「KPI(DBSherlock)→クエリ(BALANCE)→演算子(OpDiag)」と三段階で確立した回**——前回取り込んだ D-Bot(LLM エージェント・クエリレベルの症状テキスト)・DBAIOps(知識グラフ + 推論 LLM)との対比で、「演算子レベルの精度を ML + 帰属で取る」設計路線がDB 診断フロンティアの第三の軸として明確化された。**核心の設計**: 演算子→クエリ→KPI→異常の階層関係を三段階 ML モデル(Tree-CNN クエリエンコーダ + 加算アグリゲータ + ランダムフォレスト分類器) + 三段階特徴量帰属(Tree Shap で KPI → Integrated Gradient でクエリ → Integrated Gradient で演算子)で遡及。スキーマ非依存特徴(演算子型/推定コスト/行数/行幅)でアドホッククエリ汎化。**結果**: [[DBPA]] 合成ベンチマークで全異常型 top-2 内 100%・BALANCE のテーブル膨張 50% 失敗を解消。[[ZTE Corporation]] 実産業 3 事例で DBA 診断時間 1/3〜1/2 削減。Tree-CNN > Transformer > Tree-DNN(クエリ符号化)・Integrated Gradient > SHAP > Feature Ablation(演算子帰属)。**ページ作成**: source 1([[@2025__TKDE__OpDiag - Unveiling Database Performance Anomalies Through Query Operator Attribution]]) + entity 7([[Shiyue Huang]]/[[Bin Cui]]/[[Yinjun Wu]]/[[Ziwei Wang]]/[[ZTE Corporation]]/[[OpDiag]]/[[DBPA]])。**更新**: [[データベース自律診断]](「解像度スペクトル 3 段階確立」「階層帰属問題の逐次分解」「スキーマ非依存特徴設計」「Tree-CNN の木構造認識×深さ非依存」「ML+帰属 vs LLM+KG の役割分担」を横断的知見 5 点追加、未解決の問い 3 点追加)・[[Peking University]](Bin Cui + AI4DB 研究拠点を追記)・各索引・index・hot・log・manifest。**実カウント: source 78・entity 494・concept 54・question 1 = 総 627 ページ・実ソース 78**(source +1・entity +7 追加)。**出典検査**: Table I(クエリレベル診断)・Table III(産業事例時間削減)・Fig. 7〜8(モデリング/帰属アブレーション)・Fig. 5(帰属パイプライン)を PDF 本文 §VI に遡及確認(✅)。Tree-CNN > Transformer > Tree-DNN の比較は Fig. 7 に遡及(✅)。ZTE 実産業事例 3 件の詳細は §VI-E の診断レポート本文に遡及(✅)。著者所属は PDF 脚注 p.1(Shiyue Huang/Yinjun Wu=Peking University, Ziwei Wang=HKUST Guangzhou, Yaofeng Tu/Jiankai Wang=ZTE, Bin Cui=Peking University)(✅)。発行媒体は PDF 先頭行の TKDE + DOI 10.1109/TKDE.2025.3557049 + Vol.37 No.6 June 2025 pp.3613-3626(✅)。 2026-06-05: [[@2025__PVLDB__DBAIOps - A Reasoning LLM-Enhanced Database Operation and Maintenance System using Knowledge Graphs]]([[Wei Zhou]]・[[Xuanhe Zhou]]・[[Guoliang Li]] ら SJTU/Tsinghua/百盛科技、PVLDB 2025、DOI:10.14778/3797919.3797937)を **wiki-ingest-paper** で取り込み(77 ソース目)。**「知識グラフによる O&M 経験の構造化 + グラフ進化 + 推論 LLM」というハイブリッド設計が、DB 診断で LLM-only・RAG ベースの双方を定量的に凌駕することを PVLDB で実証した回**——前回取り込んだ D-Bot(RAG ベース)の後継として、DB 診断の設計進化が「知識断片の検索(RAG)」から「経験パスの構造化グラフ探索(KG)」へ移ったことを示す。**核心の設計**: ExperienceGraph(Trigger/Metric/Experience/Tool/Tag/Auxiliary の 6 頂点型・4 辺型異種グラフ、Oracle 2,911 頂点・300,000 以上のエッジ)+ 800 以上の再利用可能な AnomalyModel(方程式 + 頻度制御)+ 二段階グラフ進化(近傍推論で交差エッジを生成 → ADF で異常メトリクスを適応検出・グラフ展開を動的継続)→ グラフ拡張プロンプト(5 要素 $\langle S_a, S_l, S_m, S_e, S_o \rangle$)で DeepSeek-R1 を誘導し根本原因 + 復旧ソリューションを生成。専門 LLM の訓練なし。**結果**: DBAIOps (DeepSeek-R1 32B) で Oracle/MySQL/PostgreSQL/DM8 4 系統の平均 Acc=0.92(LLM-only 0.57 比 +61.40%)、アブレーションでグラフ進化除去が −34%、ADF 除去が −18%。HEval で D-Bot/ChatDBA を 37〜45% 上回る。事例で LLM は存在しないメトリクスを捏造(control file write max=3.78ms)、DBAIOps は実在データのみ引用(Table 8)——知識グラフが幻覚抑制の機構として機能することを事例で裏付け。**ページ作成**: source 1([[@2025__PVLDB__DBAIOps - A Reasoning LLM-Enhanced Database Operation and Maintenance System using Knowledge Graphs]]) + concept 1([[データベース O&M]]) + entity 3([[Wei Zhou]]/[[DBAIOps]]/[[Baisheng Technology]])。**更新**: [[根本原因分析]](DB 特化 RCA での知識グラフ+幻覚抑制・グラフ進化の動的対応を横断的知見 2 点追加・出典に追加)・[[Xuanhe Zhou]](DBAIOps 共著追記)・各索引・hot・log・manifest。**実カウント: source 77・entity 487・concept 54・question 1 = 総 619 ページ・実ソース 77**(source +1・concept +1・entity +3 追加)。**出典検査**: Table 5 の全数値・Table 6 アブレーション・Table 8 事例対比・Figure 4 ADF アルゴリズム・Abstract 数値(34.85%/47.22%)を PDF 本文に遡及確認(✅)。発行媒体は DOI prefix 10.14778 が PVLDB であることから PVLDB 2025 と確定、巻号は ACM DL 403 で裏取り不可(ℹ️)。著者所属は PDF 脚注(p.1)に遡及確認(Wei Zhou/Xuanhe Zhou/Fan Wu=上海交通大学・Peng Sun/Qianglei Zang/Ji Xu=百盛（深圳）科技・Tieying Zhang=ByteDance・Guoliang Li=清華大学)(✅)。 2026-06-05: [[@2024__PVLDB__D-Bot - Database Diagnosis System using Large Language Models]]([[Xuanhe Zhou]]・[[Guoliang Li]] ら [[Tsinghua University]] + Pigsty + ModelBest、PVLDB Vol.17 / VLDB 2024, DOI:10.14778/3675034.3675043)を **wiki-ingest-paper** で取り込み(76 ソース目)。**DB ドメイン特化の LLM 自律診断が AIOps 系 RCA と手法的に同型であることを PVLDB で実証した回**——[[TSG自動化]] の SOP/RAG パターンが DB 診断でも「ドメイン知識外在化が精度の律速」として反復し、[[SREGym]] が AIOps 全般で報告する「早期停止・幻覚」問題に UCT 木探索が DB 診断での構造的解を与える。**核心の設計**: オフライン(サマリツリーによるドキュメント知識抽出 188 チャンク・ツール階層登録)→ オンライン(BM25 知識検索 + ファインチューニング済み Sentence-BERT ツールマッチング)→ MCTS UCT 木探索(複数評価 LLM が投票、反省メカニズムで無益ノードを枝刈り)→ 7 エキスパート非同期協調(パブリッシュ・サブスクライブ型通信 + 相互レビュー + 診断絞り込み)の 4 技術スタック。**結果**: 539 件(6 アプリ × 10 根本原因種)で DNN 比最大 +54%・GPT-4 素比 単一原因 Acc +40%(0.351→0.754)・複数原因 Acc +55%(0.105→0.655)。診断時間 10 分以内/$1.8 vs HumanDBA 1〜2 時間。アブレーション: NoKnowledge −64.1%・NoTreeSearch −35.85%・SingleLLM vs multi-agent HEval 39→77%(IoT)。**横断的知見の発見**: DB 診断と AIOps の「ドメイン知識外在化が律速」は Flow-of-Action SOP 知識削除(LA 54.22→8.56)と構造的に同型——問題ドメインを超えた LLM エージェント設計の普遍則を別証する。**ページ作成**: source 1([[@2024__PVLDB__D-Bot - Database Diagnosis System using Large Language Models]]) + concept 1([[データベース自律診断]]) + entity 1([[DB-GPT]])。**更新**: [[根本原因分析]](DB 診断の UCT 木探索・ドメイン知識外在化・3 系統同型を横断知見 3 点追加)・[[AIOps]](DB ドメイン固有 AIOps 実証を追加)・[[Xuanhe Zhou]](Tsinghua→SJTU の所属変遷を記録・D-Bot 筆頭著者に更新)・[[Guoliang Li]](D-Bot 責任著者追記)・[[Tsinghua University]](D-Bot Database Group を追記)。**実カウント: source 76・entity 483・concept 53・question 1 = 総 613 ページ・実ソース 76**(source +1・concept +1・entity +1 追加)。**出典検査**: Table 2 Acc/HEval・Table 1 ベンチマーク統計・Figure 8〜10 全数値を PDF §8 に遡及確認(✅)。発行媒体は PVLDB Artifact Availability 脚注(p.1)・本文 arXiv ID・DOI から 確認(✅)。著者所属は PDF 脚注(p.1)に遡及(1=Tsinghua University 7名・2=Pigsty 1名・3=ModelBest 1名)(✅)。診断時間 10 分は本文 §1 "under 10 minutes"(✅)、コスト $1.8 は §8.3 "1.8 dollar for diagnosing the anomaly k"(✅)。 2026-06-05: [[@2025__TSC__TAMO - Fine-Grained Root Cause Analysis via Tool-Assisted LLM Agent with Multi-Modality Observation Data in Cloud-Native Systems]]([[Xiao Zhang]]・[[Dongxiao Yu]] ら [[Shandong University]] + [[Fuzhen Zhuang]]([[Beihang University]])、IEEE TSC 2025, arXiv:2504.20462)を **wiki-ingest-paper** で取り込み(75 ソース目)。**「LLM を生データ処理から切り離してツール出力の統合に専念させる」という設計方針を定量実証した回**——ツール支援型 LLM エージェント設計が LLM-RCA の 3 課題(マルチモーダル入力制約・コンテキストウィンドウ制限・動的依存グラフ)を統一フレームワークで解決することを 2 ベンチマーク×5 データセット分割で示す。**核心の設計**: T1(双分岐拡散モデル: ログ・トレースを制御条件にメトリクス時系列を多モーダル特徴付きの時間整合表現に変換)→ T2(FFT 高域フィルタ + 自己アテンション因果グラフ + GAT 伝播で根本原因エンティティをランク付け)→ T3(Transformer + GAT + wBCE 損失で障害種別を多ラベル分類)→ A(GPT-4 がツール出力 + システムコンテキストを統合し自然言語の診断レポートと修復提案を生成)。**結果**: HolisticRCA 比 Acc@1 平均 +4.8%・MiPr 平均 +10.8%。アブレーション(Table III)で T1 削除が最大の性能劣化(Acc@1 72.22%→43.75%、−28pt)を確認——マルチモーダルアライメントが後段 RCL・FTI 双方の律速。FFT 削除でも −19pt(Acc@1 53.13%)。**位置づけ**: 直前 TVDiag(GNN + タスク指向対照学習、LLM なし)との対比で「マルチモーダル RCA に LLM エージェントを組み込む費用対効果」の問いが鮮明になる——拡散 T1(9.32M)+ FFT+GAT T2(1.38M)+ Transformer T3(258K)の特化 DL ツール群を GPT-4 エージェントが統合するハイブリッドは、TVDiag の純 DL vs TAMO のツール+LLM という設計分岐を提示。また既存 wiki の [[Bits AI SRE]] の hypothesis-driven・[[OpenRCA]] のコード実行・[[Flow-of-Action]] の SOP 変換・[[LogPilot]] のクラスタリング代表診断に「専用 DL ツール群の出力を LLM に渡す」という第五の「生データを渡さない」設計路線を加える。**ページ作成**: source 1([[@2025__TSC__TAMO - Fine-Grained Root Cause Analysis via Tool-Assisted LLM Agent with Multi-Modality Observation Data in Cloud-Native Systems]]) + entity 5([[TAMO]]/[[Xiao Zhang]]/[[Dongxiao Yu]]/[[Fuzhen Zhuang]]/[[Shandong University]])。**更新**: [[根本原因分析]](ツール支援型設計・RCL+FTI 同時解決・FFT+GAT 動的依存グラフ対応を横断的知見 3 点追加)・[[マルチモーダル障害診断]](拡散モデルによる生成的アライメント・アライメント律速・TAMO vs TVDiag 対比・FFT 有効性を横断的知見 4 点追加、未解決の問い 2 点追加)。**実カウント: source 75・entity 481・concept 52・question 1 = 総 609 ページ・実ソース 75**(source +1・entity +5 追加)。**出典検査**: Table II・III の全数値・アブレーション・Figure 5〜7 を PDF 本文 §III-§IV に遡及確認(✅)。発行媒体は IEEE Xplore document 11229957 を一次情報として TSC と推定(IEEE Xplore ページが 418 で取得不可のため推定、出典に注記)(⚠️)。著者所属は PDF 脚注(p.1)に遡及(Xiao Zhang/Qi Wang/Mingyi Li/Mengbai Xiao/Dongxiao Yu=SDU-CS・Yuan Yuan=SDU-SW/NTU C-FAIR・Fuzhen Zhuang=BUAA-IAI)(✅)。 2026-06-05: [[@2026__TOSEM__TVDiag - A Task-oriented and View-invariant Failure Diagnosis Framework for Microservice-based Systems with Multimodal Data]]([[Shuaiyu Xie]] ら [[Wuhan University]] + 中関村実験室、TOSEM Vol.35 No.2 Article 40, 2026, DOI:10.1145/3734868)を **wiki-ingest-paper** で取り込み(74 ソース目)。**マイクロサービスのマルチモーダル障害診断(RCL + FTI)において「モダリティ-タスク嗜好」を教師あり対照学習で増幅する設計が、等価融合を大幅に凌駕することを 4 データセットで実証した回**——既存の [[Fault Localization]] / [[根本原因分析]] クラスタに「モダリティ×タスクの分化設計」という新軸を追加し、新概念 [[マルチモーダル障害診断]] を切り出す。**核心の設計**: Alert Extractor で生メトリクス・ログ・トレースから異常観測を抽出 → 相関グラフを構築 → GraphSAGE ベースの埋め込み生成に **タスク指向(TO)** と **クロスモーダル関連(CM)** の 2 種の教師あり対照学習を適用。TO は「どのモダリティがどのタスクを支援するか」を SHAP 分析で根拠づけ、CM はビュー不変の障害表現を学習。**グラフ拡張(AUG)** が非根本原因ノードをランダム非活性化してトレーニングデータ不足を緩和。Kendall 不確実性重み付け(DW)で RCL と FTI の損失を動的調整。**結果**: Tencent Online Boutique (OB) / AIOps-2020 / AIOps-2022 / 合成データセットの 4 環境で HR@1 最大 +13.15%(RCL)・F1 最大 +13.54%(FTI)、等価融合ベースライン(DiagFusion / MicroDiag)を凌駕。アブレーションで TO・CM・AUG・DW の各モジュールが有意に寄与。**ページ作成**: source 1([[@2026__TOSEM__TVDiag - A Task-oriented and View-invariant Failure Diagnosis Framework for Microservice-based Systems with Multimodal Data]]) + concept 1([[マルチモーダル障害診断]]) + entity 5([[Shuaiyu Xie]]/[[Jian Wang]]/[[Bing Li]]/[[Wuhan University]]/[[TVDiag]])。**更新**: [[根本原因分析]](マルチモーダル RCL のモダリティ嗜好定量化・インスタンスレベル設計を横断的知見に追記)・[[Fault Localization]](マルチモーダル統合でサービスレベル二段設計が崩壊することを横断的知見に追記)。**実カウント: source 74・entity 476・concept 52・question 1 = 総 603 ページ・実ソース 74**(source +1・concept +1・entity +5 追加)。**出典検査**: Table 4-6・8-9 の全数値を PDF 本文 §6 に遡及確認(✅)。著者所属は PDF 脚注に遡及(Shuaiyu Xie/Jian Wang/Bing Li は武漢大学 + 中関村実験室、DOI は ACM ペイウォール 403 のため PDF 本文の著者情報を一次源)(✅)。 2026-06-05: [[@2025__WWW__Flow-of-Action - SOP Enhanced LLM-Based Multi-Agent System for Root Cause Analysis]]([[Changhua Pei]] ら CNIC/CAS + [[ByteDance]] の [[Tieying Zhang]] + [[Dan Pei]] 清華大、WWW Companion '25, DOI:10.1145/3701716.3715225)を **wiki-ingest-paper** で取り込み(73 ソース目)。**本 wiki の RCA エージェント群に「SOP 知識の明示的参照による幻覚制御」という新設計軸を加える回**——[[OpenRCA]] のコード実行型・[[LogPilot]] のクラスタリング代表型・[[Bits AI SRE]] の hypothesis-driven に続く第四の「情報絞り込み」アプローチ。**核心の設計**: SOP フロー(match_sop/generate_sop/generate_sop_code/run_sop/match_observation の 5 ツール)が ReAct の幻覚を抑制し、thought-actionset-action-observation パラダイムが「多様な観測 → 行動選択の困難」を確率性と決定論のバランスで解く。特に **SOP → コード変換(generate_sop_code)** の三利点(アトミック一括実行・近位テキスト依存排除・トークン節約)が Chain-of-Code 的に逐次テキスト実行の脆弱点を迂回する。**結果**: GPT-4-Turbo で LA=70.89%・TA=57.12%(平均 64.01%)を達成、ReAct(LA=47.67%・TA=23.33%)を LA+23ポイント・TA+28ポイント上回る。アブレーションで SOP 知識削除により LA が 54.22→8.56 に激減——「ドメイン知識の明示化が RCA エージェントの律速」を定量証明。**TSG自動化との関係**: Flow-of-Action の SOP フローは Microsoft 3 本([[FLASH]]/[[LLexus]]/[[StepFly]])の TSG 自動化と「人間の手順書を LLM 行動制約に転換」する構造を共有しつつ、**反復インシデントの既知手順実行(TSG)** ではなく **未知の根本原因を探索する RCA に特化**し、SOP が未存在の場合は自動生成(generate_sop)で補う点で異なる。**ページ作成**: source 1([[@2025__WWW__Flow-of-Action - SOP Enhanced LLM-Based Multi-Agent System for Root Cause Analysis]]) + entity 1([[Changhua Pei]])。**更新**: [[根本原因分析]](SOP 知識の明示的参照設計を横断的知見に追記)・[[TSG自動化]](SOP フローとの比較を追記)・[[Dan Pei]]/[[ByteDance]]/[[Tieying Zhang]](本論文共著を追記)。**実カウント: source 73・entity 471・concept 51・question 1 = 総 596 ページ・実ソース 73**(source +1・entity +1 追加)。**出典検査**: Table 3 の全数値を PDF 本文 §3 に遡及確認(✅)。アブレーション Table 4 も全行確認(✅)。発表年 2025 は arXiv ID(2502=2025-02)と WWW Companion '25(2025-04)で一致(✅)。著者所属は PDF 脚注に遡及(Zexin Wang は CNIC/CAS + ByteDance インターン、Tieying Zhang・Jianjun Chen は corresponding author として PDF 末尾脚注§で確認)(✅)。 2026-06-05: インシデント自動化の一次論文 4 本を **wiki-ingest-paper** で subagent 並行取り込み(68–72 ソース目)。**「人間向けの運用知識(TSG・runbook)をどう LLM エージェントに実行させ、どこまで自律に任せて良いか」を、Microsoft の TSG 自動化 3 本 + agentic NetOps/AIOps の安全性サーベイ 1 本で横断する回**。**(1) [[@2024__MSR__FLASH - A Workflow Automation Agent for Diagnosing Recurring Incidents]]**([[Xuchao Zhang]]・[[Saravan Rajmohan]] ら、[[Microsoft]]、2024): [[FLASH]]。status supervision(複雑 TSG 命令を識別ステータスに沿って分解)+ hindsight integration(過去失敗から LLM 生成の hindsight)。本番 250 件・5 シナリオで [[TaskWeaver]] 比 +13.2%、TSG 品質(Ambiguous Action 約 40%・Pass 約 8.5%)が律速。**(2) [[@2025__arXiv__StepFly - Agentic Troubleshooting Guide Automation for Incident Diagnosis]]**([[Jiayi Mao]]・[[Saravan Rajmohan]] ら、[[Tsinghua University]]/[[Microsoft]]): [[StepFly]]。3 段=[[TSG Mentor]] で品質改善 / オフライン DAG+QPP 抽出 / オンライン並列 scheduler-executor。GPT-4.1 約 94%・実行時間 32.9〜70.4% 削減。**(3) [[@2024__OSR__LLexus - an AI agent system for incident management]]**([[Pedro Las-Casas]] ら、[[Microsoft]]、ACM SIGOPS OSR 2024): [[LLexus]]。LLM を計画フェーズに前置し TSG を BPMN 風フローチャートへコンパイル、実行は [[Azure Durable Functions]] で決定論的。計画 1 TSG あたり $0.60〜$1.71 の一回払い。**(4) [[@2026__arXiv__Large Language Models for Agentic NetOps and AIOps - Architectures, Evaluation, and Safety]]**([[Muhammad Bilal]]・[[Jon Crowcroft]] ら): agentic NetOps/AIOps サーベイ。「運用上の信頼性はモデルでなくモデル周辺機構(typed tool interface・provenance retrieval・budget/stopping rule・least-privilege・書き込み境界の verification gate)から来る」を autonomy hierarchy / tool scope / evidence trace / assurance contract の 4 軸で統合。**ページ作成**: source 4 + 新規 concept 3([[TSG自動化]]/[[NetOps]]/[[エージェント運用安全性]])+ entity 32(person 24・product 7・org 1)。**既存 concept 更新**: [[インシデント管理]](FLASH/LLexus/StepFly の TSG 自動化三分法 + NetOps の「段の継ぎ目の翻訳」)・[[障害緩和]](LLexus 計画前置 vs ThinkRemed 反省ループ)・[[根本原因分析]]/[[AIOps]]/[[agentic SRE]]/[[SRE AI Autonomy Levels]]/[[Transactional No-Regression]](NetOps サーベイの横断)。既存 person 4 更新([[Minghua Ma]]/[[Shilin He]]/[[Qingwei Lin]]/[[Chaoyun Zhang]] に FLASH/StepFly 共著を追記)。**最大の横断的知見 3 点**: (1) **Microsoft の TSG 自動化 3 本は「LLM をワークフローのどの時点で働かせるか」で分岐**——FLASH=インシデント時(オンライン)、LLexus=計画時(オフライン前置 + 決定論的実行)、StepFly=両方 + 並列。オフライン前置はコストを「インシデント件数」から「TSG 件数」へ移す経済構造を生む。(2) **3 本が独立に「TSG 品質こそ律速」へ収束**——FLASH の Pass 約 8.5%、StepFly の専用ツール [[TSG Mentor]]、LLexus の低品質 TSG で計画コスト約 3 倍。人間向けドキュメントを AI 向けに作り直すことが共通の主戦場で、[[AlertGuardian]] の rule refinement(受容率 32%)と同型。新概念 [[TSG自動化]] に切り出して横断集約。(3) **NetOps サーベイの「assurance contract / verification wall」が、本 wiki の [[Transactional No-Regression|TNR]](STRATUS)・[[Actus]](Google)・[[Cloud-OpsBench]] の white-box 採点を同一語彙(ゲート・予算・証拠・ロールアウト)で上位一般化**し、LLexus の決定論的実行も「書き込み境界の確実性」として接続。NetOps を [[AIOps]] と並べ「形式的に検証可能な不変条件を持つ最も鋭いテストベッド」と位置づけ、本 wiki の AIOps 偏重にネットワーク層の角度を足す([[エージェント運用安全性]])。**取り込み手法**: Phase 1(4 subagent 並行で source + 排他的な著者 person を per-file lock 付き作成、共有 entity・concept は構造化 report)→ Phase 2(メインで新概念 TSG自動化 作成・既存 concept 統合・中央 entity・索引/index/hot/log/manifest 更新)。**特記**: 初回の 4 並行 subagent のうち NetOps を除く 3 本が約 20 分でソケット切断(ストリーミング上限と推定)・書き込み前で source 未生成。残留 source ロックを解放し 3 本を **Sonnet** で再実行(各 4〜6 分で完走)。再実行 3 本は各自 commit(StepFly/FLASH/LLexus の 3 コミット)、NetOps + Phase 2 はメインで集約。並行して別セッションが [[@2025__arXiv__A Survey of LLM × DATA]] を ingest しており、hot/log/索引の共有書き込みはロックで直列化した。**出典検査**: 各 source の主要数値を PDF 本文・図表に遡及確認。FLASH 本文は Microsoft を「CompanyX」と匿名化(MSR ページは Microsoft と同定、source に注記)、媒体は査読会議/arXiv 明記なしで SOURCE=`MSR`。StepFly は arXiv v2(2026-04)・原 v1 2025-10、年は arXiv ID から 2025。NetOps サーベイは図8 heatmap が定性割り当て・本文に OCR ノイズあり(正規語義で記述・注記)、著者所属は PDF §I 脚注に遡及(Bilal=Lancaster, Crowcroft=Cambridge, Wang&Xu=NUIST, Dustdar=TU Wien+ICREA)。**実カウント再同期: source 72・entity 470・concept 51・question 1 = 総 594 ページ・実ソース 72**(本バッチで source +4・concept +3・entity +32 作成、concept 7 更新・person 4 更新。別セッションの LLM×DATA ingest を含む実ファイル数)。 2026-06-05: [[@2025__arXiv__A Survey of LLM × DATA]]([[Xuanhe Zhou]] ほか、[[Shanghai Jiao Tong University]]/[[Tsinghua University]]/[[Alibaba Group]]/[[Shanghai AI Laboratory]]、arXiv:2505.18458, 2025)を **wiki-ingest-paper** で取り込み。LLM とデータ管理の双方向的関係を DATA4LLM(データ処理・保存・提供)と LLM4DATA(データ操作・分析・システム最適化)の 2 軸で体系化した 58 ページ・400 超文献の包括サーベイ。IaaS(Inclusiveness・Abundance・Articulation・Sanitization)というデータセット品質の 4 次元枠組みを独自に提案。**ページ作成**: source 1([[@2025__arXiv__A Survey of LLM × DATA]])+ entity 2([[Xuanhe Zhou]]/[[Guoliang Li]])。**既存 concept 更新 2**: [[根本原因分析]](DB 系異常診断の 3 系統分類が AIOps の RCA と重なることを横断的知見に追記)、[[LLM分散学習]](DATA4LLM のデータ保存層が訓練インフラの SER と不可分であることを追記)。**主な横断的知見**: 本 wiki が個別ソース([[Bits AI SRE]]・[[AlertGuardian]]・[[Cloud-OpsBench]])から積み上げた「直接プロンプト/RAG 強化/マルチエージェント」の RCA 手法分類が、DB システムの異常診断でも同型であり、AIOps 固有でなくデータシステム全般に共通する LLM 活用パターンだと裏づけられた。**実カウント再同期: source 67 + entity 2 = 総 546 ページ・実ソース 67**。 2026-06-05: [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]](Ma+, [[Concordia University]] SPEAR lab、arXiv:2604.16359v2, 2026)を **wiki-ingest-paper** で取り込み。**本 wiki が個別の一次ソース(LogPilot/MonitorAssistant/L4/AlertGuardian/OpenRCA)で積み上げてきた LLM ベースログ解析を、初めて「フィールドの地図」で俯瞰する回**——[[ログ生成]]→[[ログパース]]→表現学習→下流タスク([[異常検知]]・[[障害予測]]・[[根本原因分析]]・ログ要約)のエンドツーエンドパイプラインで 145 論文(2020–2025)を統一タクソノミー化。github コンパニオン [[LLM4Log (repository)]] が 7 タスク分類(Logging 20・Parsing 41・Representation 3・Anomaly Detection 71・Failure Prediction 4・RCA 20・Summary 3)の一次データ。**ページ作成**: source 1 + entity 5([[Zeyang Ma]]/[[Jinqiu Yang]]/[[Tse-Hsun Chen]]/[[Concordia University]]/[[LLM4Log (repository)]])+ concept 2 新規([[ログパース]]/[[ログ生成]])。**既存 concept 更新 4**: [[ログ解析]](大幅・パイプライン全体地図化で seed→developing)・[[異常検知]]・[[根本原因分析]]・[[障害予測]] の横断的知見/未解決の問いを積み増し。**最大の横断的知見 3 点**: (1) **「ログ解析」は単一タスクでなくパイプライン 7 タスク全体**だとフィールド地図が確定——本 wiki の「診断」中心の見方が下流 1 段に相対化され、最上流の [[ログ生成]]・前処理の [[ログパース]] が新概念として加わる、(2) **「情報を絞ってから LLM を選択的に呼ぶ階層設計」が全段共通の設計原理**だとサーベイが横断定式化(§7.1)——[[LogPilot]] の request クラスタリング・[[OpenRCA]] のコード実行・LILAC の cache が同じパターンで、本 wiki が個別ソースで観測した骨格の上位一般化、(3) **162 レコード中 deployment 証拠は 5 のみ・HDFS/BGL 偏重**で、本 wiki が産業一次ソース(LogPilot=Volcano Engine・AlertGuardian=Tencent MTTR 156→21 分・L4=Platform-X 428 障害)を厚く持つことが、フィールド全体でも希少な「明確な deployment 証拠」側に属することを裏づける。さらに deployment 評価は [[根本原因分析]] に最も集中。**取り込み手法**: メイン文脈で逐次(source→entity→concept→索引/log/hot/manifest)、per-file lock。PDF は arXiv から取得(`.raw/papers/arxiv-2604.16359.pdf`、54 ページ、全文読了)、書誌は arXiv abs + github README で裏取り。**出典検査**: タスク別論文数・指標・横断結論は PDF 本文(§2–§7・Table 4–9・Fig.1–6)に遡及確認。発表年は arXiv ID から 2026 推定(abs ページで v1 2026-03 確認)。**実カウント再同期: source 67・entity 435・concept 48・question 1 = 総 551 ページ・実ソース 67**(本 ingest で source +1・entity +5・concept +2 作成、concept 4 更新)。 2026-06-04: 本番 LLM 訓練の**障害・性能診断**の一次論文 8 本を **wiki-ingest-paper** で並行取り込み。**「同期した分散訓練の規則性を、どの計装位置・どのモダリティで観測し、症状から真因デバイスへどう橋渡しするか」を 8 本で横断する回——因果探索・性能予測・ネットワーク障害・eBPF 全スタック・通信ハング・CCL カウンタ・ネットワークフロー・ログ解析**。**(1) [[@2025__ISAV__From Exploration to Explanation - ML-Driven Causal Discovery for Datacenter Reliability at Scale]]**([[Pavana Prakash]] ら、[[Hewlett Packard Labs]]/[[Oak Ridge National Laboratory]]、ISAV 25): 因果探索 [[PACE]]。相関クラスタリング + ラグ考慮 Granger 因果性で施設テレメトリ([[Summit]] 冷却 7 年)から有向因果パスを抽出し物理プロセスで妥当性検証。**(2) [[@2025__arXiv__Efficient Fine-Grained GPU Performance Modeling for Distributed Deep Learning of LLM]]**([[Biyao Zhang]] ら、[[Case Western Reserve University]]/[[Rutgers University]]): オペレータ分解 + 木回帰で訓練時間を CPU 上予測、通信は誤差 50% 超でも時間の 5% 未満ゆえ計算演算に予測力を集中、[[Perlmutter]] 4.98%/[[Vista]] 9.38%。**(3) [[@2025__SIGCOMM__SkeletonHunter - Diagnosing and Localizing Network Failures in Containerized Large Model Training]]**([[Wei Liu]]・[[Ennan Zhai]] ら、Alibaba Cloud/[[Tsinghua University]]/[[University of Illinois Urbana-Champaign]]、SIGCOMM 25): [[SkeletonHunter]]。RNIC バーストの STFT で集合通信スパース性を推論し probing 2 桁削減、overlay/underlay 分離で 19 種別へ箇所特定、precision 98.2%。**(4) [[@2025__IWQoS__eACGM - Non-instrumented Performance Tracing and Anomaly Detection towards Machine Learning Systems]]**([[Ruilin Xu]] ら、[[Sun Yat-sen University]]、IWQoS 25): [[eACGM]]。[[eBPF]] をフレームワーク層関数トレースへ適用 + libnvml + 教師なし GMM の非侵入全スタック監視、6 ベースライン超。**(5) [[@2025__arXiv__XPUTimer - Anomaly Diagnostics for Divergent LLM Training in GPU Clusters of Thousand-Plus Scale]]**([[Weihao Cui]] ら、[[Shanghai Jiao Tong University]]/[[National University of Singapore]]/[[Ant Group]]): [[XPUTimer]]([[Flare]])。非侵入 CPython 計装 + CUDA-GDB intra-kernel inspecting で O(1) 通信ハング箇所特定 + 持続的性能回帰診断、6,000 GPU 8 ヶ月(arXiv v2 で Flare に改名)。**(6) [[@2025__NSDI__Evolution of Aegis - Fault Diagnosis for AI Model Training Service in Production]]**([[Jianbo Dong]]・[[Kun Qian]] ら、Alibaba Cloud、NSDI 25): [[Aegis]]。CCL の launch/work-request/completion カウンタで計算障害(CL 遅れ)/通信障害(WR<WC)を顧客コード非侵入で弁別、idle time 97%+ 削減。**(7) [[@2025__DSN__LLMPrism - Black-box Performance Diagnosis for Production LLM Training Platforms]]**([[Guangba Yu]] ら、[[The Chinese University of Hong Kong]]/[[Huawei Cloud]]、DSN 25): [[LLMPrism]]。スイッチ層 RoCE フローのみから並列化を逆推定 + BOCD + k-σ、19 ジョブ/2880 GPU で 0.3% 誤差・並列化識別 100%([[Platform-X]] 稼働)。**(8) [[@2025__ESEC-FSE__L4 - Diagnosing Large-scale LLM Training Failures via Automated Log Analysis]]**([[Junjie Huang]]・[[Guangba Yu]] ら、CUHK/[[Sun Yat-sen University]]/[[Huawei Cloud]]、ESEC/FSE 25): [[L4]]。cross-job/spatial([[Isolation Forest]])/temporal(DTW)でログから障害指示情報を抽出、F1 0.873・top-5 80.5%。**ページ作成**: source 8 + entity 69(person 48・org 6・system/dataset/repo 15)。**最大の横断的知見 4 点**: (1) 同期分散訓練の「全マシン対称」という規則性を、性能予測(GPU Perf)・異常検知([[Minder]])・並列化逆推定(LLMPrism)・ログ外れ値(L4)が同一構造から別目的で利用する、(2) [[Fault Localization]] は「症状の層(CCL timeout)と真因デバイスの乖離」を CCL カウンタ(Aegis)/ネットワークパス(SkeletonHunter)/ログ(L4)/メトリクス類似度(Minder)と計装位置ごとに別モダリティで橋渡しし、いずれも箇所特定止まりで RCA は人手、(3) [[集合通信]]は「予測も診断も最難だが観測価値が最大」で、XPUTimer の intra-kernel inspecting・Aegis の CCL カウンタ・LLMPrism のフロー量偏り・eACGM の NCCL 計装が別アプローチで攻める、(4) [[異常検知]]手法が GMM(eACGM)→ k-σ(LLMPrism)→ LSTM-VAE(Minder)と「本番運用の単純さ」を軸に振れる。**既存 concept 更新(17)**: [[LLM学習モニタリング]]/[[LLM分散学習]]/[[集合通信]]/[[Fault Localization]]/[[根本原因分析]]/[[異常検知]]/[[並列化戦略]]/[[RDMAネットワーク監視]]/[[ストラグラー]]/[[ログ解析]]/[[GPU観測性]]/[[テレメトリ]]/[[eBPF]]/[[分散トレーシング]]/[[変化点検知]]/[[GPUクラスタ運用]]/[[障害緩和]]。本回は新規 concept なし(既存概念に積み増し)。**取り込み手法**: Phase 1(8 subagent 並行で source + 著者 person entity を作成、per-file lock、共有物は構造化 report)→ Phase 2(メイン + 3 subagent で org/system entity・concept 統合・索引・hot・log・manifest を**ファイル集合を分離**して競合なく更新。ロックは torn write は防ぐがブロックせず取りこぼすため共有書き込みは逐次化)。**出典・特記**: 5 本(GPU Perf/eACGM/XPUTimer/LLMPrism/L4)は arXiv PDF 取得、Aegis は USENIX 公式 PDF、SkeletonHunter は著者公開 PDF(ACM 403)。**ISAV/PACE は当初 ACM ペイウォールで PDF 非取得**だったが、後日ユーザー提供 PDF(`.raw/papers/2026_Unknown_From_Exploration_Explanation_ML_Driven.pdf`)で**全文に基づく正式版へ格上げ済み**(6 段パイプライン・Fig.1–4 の所見を追記、David Grant の所属を ORNL に確定、[[DyTwin]] entity を新設。論文自体は定量精度指標を持たず物理整合性・感度分析の定性評価)。XPUTimer は arXiv v2 で著者構成・システム名(→[[Flare]])が変化、source に contradiction callout。GPU観測性 の末尾に残っていた壊れたタグ(`</content></invoke>`)を併せて除去。**実カウント再同期: source 66・entity 430・concept 46・question 1 = 総 543 ページ・実ソース 66**(実ファイル数で確認。本バッチで source +8・entity +69 作成、entity 9 更新)。 2026-06-04: 大規模 GPU 訓練クラスタの障害管理の一次論文 6 本を **wiki-ingest-paper** で取り込み(60–65 ソース目)。**LLM 訓練の信頼性を「検知 → 復旧 → 緩和」の各段と「計装位置(スイッチ/NIC/ホスト/物理部品)」の軸で横断整理する回——故障管理・ストラグラー・復旧・RDMA 診断・通信最適化・光部品故障予測を一望にまとめる**。**(1) [[@2025__SC__Fine-grained Automated Failure Management for Extreme-Scale GPU Accelerated Systems]]**([[Yonatan Levitt]] ら、[[Intel Corporation]]/[[RIKEN Center for Computational Science]]、SC 25): エクサスケール GPU 自動故障管理 [[StabilityDB]]。相関イベント分析の集中型メタ DB + きめ細かいマルチストライク修復ポリシー + 自動回復で GPU 単位の細粒度に修復対象を切り分け、[[Argonne National Laboratory]] の [[Aurora]](63,744 GPU)で MTTR を手動比最大 84 倍短縮。**(2) [[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]]**([[Guanliang Liu]] ら、[[Store Foundational AI]]([[Amazon Web Services]])、MLSys 26): [[ストラグラー]]検知 + ノード健全性管理 [[Guard]]。NCCL テスト/バーンインを通過しつつ性能を暗黙劣化させる**グレーノード**を、オンラインモニタリング(ピアベース異常検知 + 段階的緩和)と復帰前のオフラインノードスイープの閉ループで検知し、MFU 最大 1.7 倍・ステップ時間分散 20%→1%。検知ツールを [[fkat]] として OSS 化。**(3) [[@2025__arXiv__FlashRecovery - Fast and Low-Cost Recovery from Failures for Large-Scale Training of LLMs]]**([[Haijun Zhang]] ら、[[iFLYTEK AI Engineering Institute]]/[[University of Science and Technology of China]]/[[Huawei Technologies]]): LLM 訓練の高速・低コスト復旧 [[FlashRecovery]]。アクティブ検知(4〜11 秒)+ スケール非依存タスク再起動(ランクテーブル O(1))+ データ並列複製による**チェックポイントフリー 1 ステップ復旧**で、[[Ascend NPU]] 4,800 デバイス 150 秒・従来比約 93〜95% 削減。**(4) [[@2025__SIGCOMM__Hawkeye - Diagnosing RDMA Network Performance Anomalies with PFC Provenance]]**(Shicheng Wang ら、[[Tsinghua University]]/[[Beihang University]]/[[Infrawaves]]、SIGCOMM 25): RDMA 性能異常(NPA)診断 [[Hawkeye]]。PFC プロベナンス(来歴)で backpressure/storm/deadlock を 90% 以上の精度・再現率 100% で診断し、収集スイッチ数を約 1/10・オーバーヘッドを 1〜4 桁削減([[Intel Tofino]] テストベッド)。**(5) [[@2025__HPCA__Enhancing Large-Scale AI Training Efficiency - The C4 Solution for Real-Time Anomaly Detection and Communication Optimization]]**([[Jianbo Dong]] ら、[[Alibaba Group]]/[[Hong Kong University of Science and Technology]]、HPCA 25): 通信駆動型 AI 訓練効率化 [[C4]]。診断 [[C4D]]([[ACCL]] 拡張)が[[集合通信]]の症候から故障を数十秒で隔離・再開し、性能 [[C4P]] がトラフィック工学で帯域競合を削減。ダウンタイム 31.19%→1.16%・システム効率 30%→45%、本番 30 か月超([[H800]] 評価)。**(6) [[@2025__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]]**(Sibo Xia ら、[[Nankai University]]、APNet 25): 光トランシーバー故障の予測 + 分類 [[OptProphet]]。特徴量集約で時間的依存と物理的結合をモデル化し不均衡データを自動処理、予測 F1 0.884(平均 1.11 日前にアラーム)・分類 F1 0.855 で SOTA を凌駕。**ページ作成**: source 6 + entity 多数。**最大の横断的知見 4 点**: (1) 検知の一次シグナルが「ステップ時間/集合通信の同期点(Guard・C4)」「物理メトリクス(StabilityDB・OptProphet)」「PFC 来歴(Hawkeye)」に分かれ、どの層を測るかで捉えられる障害種が決まる、(2) 復旧は高速チェックポイント・予備機・べき等省略・データ並列複製冗長(FlashRecovery)の 3+1 系統に整理でき、FlashRecovery はチェックポイント I/O を捨てて複製冗長へ振り切る、(3) 緩和は multi-strike(StabilityDB)・10〜20% しきい(Guard)のように段階化することで過剰排除と見逃しを両睨みする、(4) 計装位置がスイッチ(Hawkeye)/NIC・集合通信(C4・Guard)/ホスト(FlashRecovery 検知)/物理部品(OptProphet 光モジュール・StabilityDB)に分散し、上流ほど予兆を、下流ほど確度を取る。新 source 群は既存 concept [[耐障害LLM訓練]]/[[ストラグラー]]/[[集合通信]]/[[RDMAネットワーク監視]]/[[GPUレジリエンス]]/[[GPUクラスタ運用]]/[[障害緩和]]/[[チェックポイント]]/[[障害予測]] を縦に貫く。**取り込み手法**: 一次資料は既存 `papers/` ノート 5 本(SC/SIGCOMM/HPCA/APNET)+ `research/conferences/` 1 本(Guard)を温存・一方向参照で wiki 化。FlashRecovery のみ `.raw/papers/arxiv-2509.03047.pdf` を取得。**実カウント再同期: source 66・entity 430・concept 46・question 1 = 総 543 ページ・実ソース 66**(並行セッションのドリフトを実ファイル数で吸収)。 2026-06-04: GPU/eBPF 観測性・集合通信の一次論文 7 本を **wiki-ingest-paper** で取り込み(53–59 ソース目)。**LLM の推論/訓練を「どう速くするか」でなく「どう観るか・正しさをどう保つか」の系譜——GPU カーネル・集合通信・推論演算子を低オーバーヘッド・非侵襲に可視化し、その上で耐障害性(べき等性・チェックポイント)まで届かせる回**。**(1) [[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]]**([[Kexin Chu]]@[[University of Connecticut]] ほか、eBPF Workshop 25): 分散 LLM 推論を要求単位でエンドツーエンドにトレースする初の [[eBPF]] ベースシステム [[eInfer]]。ソース改変なしで CPU・アクセラレータ・プロセス・ノードをまたぐイベントを関連付け、ベンダー非依存で [[CUPTI]] に近い精度・オーバーヘッド 4% 未満。**(2) [[@2026__arXiv__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]]**([[Bohua Zou]]/[[Debayan Roy]]@[[Huawei Hilbert Research Center Dresden]]/[[TU Munich]]): eBPF uprobe を [[llama.cpp]] へ動的アタッチする非侵入オンデバイス推論プロファイラ [[ProfInfer]]。演算子レベル [[ハードウェアカウンタ|PMC]] で `ggml_tensor` を辿りハードウェア挙動とモデル構造を対応づけ、ProfDAG/ProfTime([[Perfetto]])/ProfStat の 3 ビュー、オーバーヘッド最小 1.7%、MoE のボトルネックがディスク I/O だと特定。**(3) [[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]]**([[Yangtao Deng]]@[[ByteDance Seed]]、SOSP 25): [[集合通信]]ライブラリ([[NCCL]])のブラックボックス性を打破する Coll-level 観測 [[Mycroft]]。フロー/チャンク単位の依存性を露出させ C++ 1,100 行の軽量計装で数万 GPU の 90% を 15 秒以内に検知・60% を 20 秒以内に箇所特定、ByteDance で 6 か月超デプロイ。**(4) [[@2025__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]]**([[Yiwei Yang]]/[[Andrew Quinn]]@[[UC Santa Cruz]]、HCDS 25): eBPF バイトコードを実行時に [[PTX]] へコンパイルし稼働中 GPU カーネルへ動的注入する初の eBPF ランタイム [[eGPU]]。中断なしの計装で [[NVBit]] より低オーバーヘッド、共有メモリ eBPF マップで CPU-GPU 間をコピーなし交換(単一 GPU・マイクロベンチ限定)。**(5) [[@2025__arXiv__Collective Communication for 100k+ GPUs]]**([[Min Si]]/[[James Hongyi Zeng]]@[[Meta]]): 10 万 GPU 超の LLM ライフサイクル全体を NCCL 拡張で一元支援する[[集合通信]]フレームワーク [[NCCLX]]。ゼロコピー・SM フリー・ホスト駆動の [[CTran]] と三実行モード、[[Llama4]] で定常ステップ最大 12% 削減・起動最大 11 倍・デコード 15〜80% 改善、[[DQPLB]] でスイッチバッファ一桁削減。**(6) [[@2024__TOPC__Low-Overhead Trace Collection and Profiling on GPU Compute Kernels]]**([[Sébastien Darche]]/[[Michel R. Dagenais]]@[[Polytechnique Montréal]] [[DORSAL lab]]、TOPC 24): トレースフェーズ区分化でデバイス上トレース収集を類似研究比 1 桁削減。LLVM パスで制御フローを静的に解きバッファ事前確保・決定的実行、[[Rodinia]] で全体 1.60×、参照実装 [[hip-analyzer]] は CUDA/[[HIP]] 対応。**(7) [[@2024__arXiv__Microsecond-scale Dynamic Validation of Idempotency for GPU Kernels]]**([[Mingcong Han]]/[[Rong Chen]]/[[Haibo Chen]]@[[Shanghai Jiao Tong University]] IPADS): GPU カーネルの[[べき等性]]をインスタンス単位で実行前検証する初のシステム [[PICKER]]。「条件付きべき等」を発見(547 中 490)し起動引数だけで全インスタンスを 5µs 以内に検証、[[Asymmetric Resilience]] の[[チェックポイント]]コストを 4% 未満へ・[[Chimera]] のプリエンプション待ちを平均 84.2% 削減。**ページ作成**: source 7 + concept 7 新規([[GPU観測性]]/[[集合通信]]/[[動的計装|動的インストルメンテーション]]/[[LLM推論]]/[[ハードウェアカウンタ]]/[[べき等性]]/[[チェックポイント]])+ entity 53 新規(persons 16・orgs 13・systems/products/repos/datasets 24)= 67 ページ。**最大の横断的知見 4 点**: (1) [[GPU観測性]]/[[動的計装|動的インストルメンテーション]]が計装の「挿入時点」で 3 系統(コンパイル時=TOPC / 実行時 PTX 注入=eGPU / ホスト側 eBPF フック=eInfer・ProfInfer)に分かれ、差し込む抽象度がそのままオーバーヘッドと観測対象を決める、(2) [[集合通信]]の CCL ブラックボックス課題を観測側(Mycroft の依存トレース)と機構側(NCCLX のスタック再設計)の両方から攻め、Op をひとかたまりに見ずフロー/QP 単位の細粒度に降りることがスケール時の共通の鍵、(3) [[LLM推論]]の細粒度観測が「帯域が足りない」という素朴な見立てを反証——ProfInfer は MoE のボトルネックをディスク I/O、NCCLX は推論のボトルネックを CPU 準備オーバーヘッドと特定、(4) 観測性ツール([[動的計装|動的インストルメンテーション]])が性能診断を越えて正しさ検証([[べき等性]])の基盤になり、PICKER は「べき等カーネルは保存不要」という保存対象削減で[[チェックポイント]]最適化を [[耐障害LLM訓練]] と接続する。**取り込み手法**: Stage A(subagent 並行で source+固有 entity 作成、per-file lock)→ Stage B(メインで concept 統合・索引・hot・log・manifest)。**出典検査**: 各 source の主要数値を PDF/スライドに遡及確認。R-Pingmesh と同様 eInfer・eGPU・TOPC の一部は公開 PDF/スライドからの確認(confidence は eInfer/TOPC=medium、他=high)。**本 ingest は source +7・concept +7・entity +53 = +67 ページ。実ファイル数で再同期: source 56・entity 306・concept 46・question 1 = 総 409 ページ・実ソース 56**(直前の hot 申告値 378/52 は別セッション由来のスタブ的スナップショットで、実ファイル数が乖離していたため実カウントで再同期)。なお PromSketch/近似クエリ処理/VLDB Approximation 系は別セッションの作業で本回は不干渉。 2026-06-04: [[@2025__VLDB__Approximation-First Timeseries Monitoring Query At Scale]]([[Zeying Zhu]]/[[Zaoxing Liu]]@[[University of Maryland]]・[[Jonathan Chamberlain]]/[[David Starobinski]]@[[Boston University]]、PVLDB/VLDB 2025, DOI:10.14778/3742728.3742732, arXiv:2505.10560)を **wiki-ingest-paper** で取り込み(46 ソース目)。**本 wiki 初の[[近似クエリ処理]](AQP)/時系列モニタリングのコスト・レイテンシ最適化の一次論文**で、既存の [[時系列データベース]] 概念([[HeteroTSDB]] の取り込み最適化軸)に「クエリ最適化軸」を対置する。source 1 + entity 10 新規([[PromSketch]]/[[Prometheus]]/[[VictoriaMetrics]]/[[Froot-NetSys promsketch]]、persons 5、orgs [[University of Maryland]]/[[Boston University]])+ concept 1 新規([[近似クエリ処理]])= 12 ページ作成、既存 concept [[時系列データベース]] を更新。**核心**: [[Prometheus]]/[[VictoriaMetrics]] の周期ルールクエリ(alerting/recording rule)が、重複するスライディングウィンドウを**繰り返しスキャン・再計算**する冗長性を持つ(CPU プロファイルで Data Scanning が Prometheus 41%/VictoriaMetrics 80.2%)。[[PromSketch]] は生データでも最終結果でもなく**中間結果**(Exponential Histogram バケット)を in-memory にキャッシュし、クエリ時にバケットを線形マージして任意サブウィンドウを再計算なしで答える。EH×KLL(EHKLL=quantile/min/max)と EH×Universal Sketching(EHUniv=distinct/entropy/L2/TopK の GSum 系)を**可証明な誤差-空間境界**つきで組み合わせ(`ε_EHKLL ≤ 2ε_EH + ε_KLL`)、小バケットは exact map・大バケットは sketch の hybrid で省メモリ化。Go 約 5K 行・約 30 行パッチで統合し、Prometheus の aggregation-over-time の 70% をカバー。平均誤差 5% 以下でレイテンシを最大 2 桁削減(quantile を Prometheus 比 203×・VictoriaMetrics 比 78×、entropy/L2 を 231×/158×)、クエリ処理コストを Prometheus 比約 400×・VictoriaMetrics 比 4× 以上削減。**最大の横断的知見 3 点**: (1) TSDB 効率化は「取り込み最適化」([[HeteroTSDB]] のインデックス選択・tiering)と「クエリ最適化」(PromSketch の中間結果キャッシュ)の**直交 2 軸**で、ストレージエンジン改善(VictoriaMetrics)はクエリ側の重複計算を取りきれない、(2) 近似はコスト-精度トレードオフを開く**第 3 軸**で、ダウンストリーム(アラート・オートスケール)が 5% 誤差を許容できるという前提を突くと運用コストを 2 桁削減できる、(3) Universal Sketching の GSum クラスが「統計ごとに別スケッチ」の per-statistic 労力を 1 インスタンスに畳む——AQP の「広い統計クラスへの一様な誤差保証」の一つの到達点。**未解決の問い**: 時間次元の集約のみが対象でラベル次元集約は将来課題、近似で十分なクエリと厳密が要るクエリの自動判別(誤差予算の運用)。**出典検査**: 主要数値は PDF 本文・Table 1/2/4/5・図表に遡及確認(✅)。媒体は preprint note「accepted to VLDB 2025」+ DOI prefix 10.14778(PVLDB)から VLDB 2025 と確定、巻号・ページは PDF からは未確認(ℹ️ ACM ページは 403 で裏取り不可)。**本 ingest は source +1・entity +10・concept +1。なお index 申告値(299/45)と実ファイル数が乖離していたため、実カウントで再同期: source 52・entity 279・concept 46・question 1 = 総 378 ページ・実ソース 52**(並行 ingest 由来の既存ドリフトを吸収)。 2026-06-04: GPU 分散訓練インフラ/ネットワークの一次論文 5 本を **wiki-ingest-paper** で subagent 並行取り込み(40–44 ソース目)。**LLM 訓練の信頼性を「ハードウェアの床(GPU レジリエンス)→ ストラグラー(クラッシュしない劣化)→ 耐障害インフラ(検知・隔離・復旧)→ ネットワーク監視」の縦の系譜として束ねる回**。**(1) [[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]]**([[Kefei Liu]]/[[Jiao Zhang]]、[[BUPT]]/[[Douyin Vision]]、SIGCOMM 24): 能動プロービングに基づく初のサービス認識型 RoCE 監視・診断 [[R-Pingmesh]]。市販 RNIC の UD QP+CQE で RTT/処理遅延/ドロップを測り RNIC 起因とネットワーク内ドロップを区別、トモグラフィ的投票で箇所特定。数万 RNIC・6 か月、157 件のスイッチ問題全件正確・全体 85%。**(2) [[@2025__SC__Characterizing GPU Resilience and Impact on AI - HPC Systems]]**([[Shengkun Cui]]/[[Ravishankar K. Iyer]]、UIUC/[[NCSA]]/[[IBM Research]]/[[Nokia Bell Labs]]、SC 25): NCSA [[Delta]](A100/H100)の 2.5 年・1,170 万 GPU 時間。H100 はメモリ MTBE が A100 の 1/3.2(回復機構 spare row 512 据え置きが容量増に非対応)だが GSP/NVLink 等のハードウェアは強化、99.9% 可用性に 5% オーバープロビジョニング(月 100 万ドル超)。**(3) [[@2025__OSDI__Understanding Stragglers in Large Model Training Using What-if Analysis]]**([[Jinkun Lin]] ら、[[New York University]]/[[ByteDance]] Seed、OSDI 25): What-if 分析(理想タイムラインのシミュレーションと対比)で 42.5% のジョブが ≥10% スローダウン・全 GPU 時間 10.4% 浪費を帰属、主因は計算側の不均衡(PP 分割 39.3%・シーケンス長 21.4%・Python GC)で問題ワーカー主因は 1.7%、監視 [[SMon]] を本番展開。**(4) [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]]**([[Borui Wan]]/[[Chuan Wu]]@[[The University of Hong Kong]] ら、[[ByteDance]]、SOSP 25): LLM 訓練特化 GPU インフラ管理・障害許容 [[ByteRobust]]。制御/データプレーンで ETTR を最大化(9,600 GPU・3 か月で 97%)、「正確な箇所特定より迅速な隔離」(過剰排除)。インフラ障害は件数 11% でも GPU 時間 82%、warm standby/hot-update が復旧を最大 10.87×/11.04×。**(5) [[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]]**([[Qingkai Meng]]/[[Chen Tian]]、[[Nanjing University]]/[[Tencent]]/Harvard、SIGCOMM 25): 50 万 GPU 級データセンターインフラ [[Astral]]。tier-2 同一レール相互接続(8K GPU で効率損失 0.6%・512K 規模、HVDC+空気液体冷却で PUE 最大 16.34% 改善)+4 層フルスタック監視・階層相関(MTTLF 日→分・最大 25 倍)+オペレータ粒度予測 [[Seer]](密モデル 0.3% 偏差)。同 Nanjing グループの [[Pulse]] の系譜。**ページ作成**: source 5 + entity 27 新規(systems: [[R-Pingmesh]]/[[ByteRobust]]/[[SMon]]/[[NDTimeline]]/[[Astral]]/[[Seer]]/[[Delta]]、repo: [[StragglerAnalysis]]、persons 15、orgs: [[BUPT]]/[[Douyin Vision]]/[[NCSA]]/[[Nokia Bell Labs]]/[[New York University]]/[[The University of Hong Kong]])+ concept 4 新規([[耐障害LLM訓練]]/[[ストラグラー]]/[[GPUレジリエンス]]/[[RDMAネットワーク監視]])。**既存更新**: concept 7([[LLM学習モニタリング]]/[[GPUクラスタ運用]]/[[LLM分散学習]]/[[Fault Localization]]/[[並列化戦略]]/[[テレメトリ]]/[[オープンネットワーキング]] の横断的知見・未解決の問いを積み増し)+ 既存 entity 15([[ByteDance]]/[[MegaScale]]/[[Xin Liu]]/[[Ziheng Jiang]]/[[Megatron-LM]]/[[Tencent]]/[[Nanjing University]]/[[Harvard University]]/[[Qingkai Meng]]/[[Chen Tian]]/[[Pulse]]/[[University of Illinois Urbana-Champaign]]/[[Saurabh Jha]]/[[IBM Research]]/[[Zhuo Jiang]])。**最大の横断的知見 4 点**: (1) [[LLM学習モニタリング]] の設計軸が「検知信号の層(ハートビート/ホストメトリック/トラフィック)」に加え「起因への写し方(全層相関=[[Astral]]・反事実シミュレーション=SMon・スタックトレースクラスタリング=ByteRobust)」という第二軸へ拡張、(2) [[Fault Localization]] に「精密に当てる([[Minder]]/[[Pulse]])vs あえて当てず粗く切る([[ByteRobust]] の過剰排除)」という運用目的従属の分岐が立ち、ネットワーク領域ではトモグラフィ的投票と層間相関で「起因の層」の取り違えが固有の失敗モード、(3) [[GPUクラスタ運用]] で「件数は少ないが GPU 時間を食う障害(ByteRobust 11%→82%)」が運用コストの本体で、その源泉が GPU レジリエンスの床(MMU/NVLink 以外はほぼ 100% ジョブ失敗)・fail-slow(ストラグラーで 10.4% 浪費)に分解される、(4) ストラグラーの「計算が主因・通信は軽微」は Astral 型の広帯域同一レール interconnect を前提にした帰結で、ネットワーク品質が結論の符号を変える。新 concept [[耐障害LLM訓練]] が ByteRobust/MegaScale/GPU レジリエンス/Astral/Stragglers を ETTR と「速さ vs 正確さ」の軸で束ねる。**取り込み手法**: Stage A(5 subagent 並行で source+固有 entity 作成、per-file lock)→ Stage B(メインで concept 統合・索引・hot・log・manifest、entity/concept を 2 subagent に分担)のハイブリッド。共有 entity の衝突は Stage A で「既出は report に回す」方針で回避し、Stage B でメインが集中更新。R-Pingmesh のみ公開 PDF が無くユーザー提供 PDF を `.raw/papers/` に格納。**出典検査**: 全 source の主要数値を PDF 本文・図表に遡及確認(✅)。[[ByteRobust]] の ETTR は本文では Effective **Training Time Ratio**(所与情報の "Time To Recover" は誤り、本文定義を採用)。Stragglers の「計算が浪費の約 80%」は本文では定性記述で 80% の明示数値は未確認(source 本文は「大半」とした)。[[Zhuo Jiang]] は Minder(ByteDance)と R-Pingmesh(Douyin Vision 名義)で同一人物と推定(断定せず note)。**実カウント reconcile: source 45・entity 215・concept 38・question 1 = 総 299 ページ・実ソース 45**(並行セッションのドリフトを実ファイル数で再同期)。 2026-06-04: [[@2025__OSR__Cloud Infrastructure Management in the Age of AI Agents]](Yang+, [[University of Michigan]] / [[University of California, Berkeley]] / [[Andreessen Horowitz]]、[[Ang Chen]] senior・[[Martin Casado]] 共著、ACM SIGOPS OSR 2025, DOI:10.1145/3759441.3759443)を **wiki-ingest-paper** で取り込み(39 ソース目)。**既存の IaC クラスタ([[Zodiac]]/[[NSync]]/[[Lilac]]、同じ [[Ang Chen]] グループ)を「クラウド管理の 4 モダリティのうち IaC」として相対化し、agentic SRE/AIOps クラスタとも橋渡しするビジョン/ポジション論文を投入**。source 1 + entity 9 新規([[Martin Casado]] / [[Archit Bhatnagar]] / [[Tongyuan Miao]] / [[Yunming Xiao]] / [[Yibo Huang]] / [[University of California, Berkeley]] / [[Andreessen Horowitz]] / [[WorkArena]] / [[Azure Copilot]])+ concept 1 新規([[クラウド管理モダリティ]])= 11 ページ作成。既存 entity 8 更新([[Zhenning Yang]] を本論文の共同筆頭として・[[Ang Chen]] をビジョン論文の senior 著者として・[[Yiming Qiu]] に UC Berkeley 二重所属・[[Patrick Tser Jern Kon]] / [[University of Michigan]] / [[Terraform]] / [[Microsoft Azure]] / [[AIOpsLab]])+ concept 4 更新([[Infrastructure as Code]] / [[SRE AI Autonomy Levels]] / [[agentic SRE]] / [[AIOps]] の横断的知見・未解決の問いを積み増し)。**核心**: クラウド管理を 4 [[クラウド管理モダリティ]](SDK/CLI/IaC/ClickOps、いずれも RESTful API の上に立つ)で捉え、Azure VM 管理の予備実験で provisioning/updates/monitoring の**段階 × モダリティのトレードオフ**を実証(Table 1: CLI=provisioning 最効率 SR 1.0/1.6 step、IaC=再作成更新に強いが monitoring に弱い SR 0.40・平均 2.5 step(disk 情報取得だけで 8 step)、ClickOps=monitoring SR 1.0 だが作成は 46 step と遅く脆い、SDK=バランス型)。モデルは SDK/CLI/IaC が [[Azure Copilot]](GPT-4 ベース)、ClickOps が [[WorkArena]] ベースの GPT-4o。解決スケッチは user-agent/agent-cloud interface・multi-agent orchestration・exploration/exploitation + workflow caching・guardrail(formal spec/access control/audit trail)・fault tolerance(rollback/self-healing)・human-in-the-loop。**最大の横断的知見 4 点**: (1) 本 wiki の IaC 深掘り 3 部作を「IaC=4 モダリティの 1 つ」と俯瞰し、IaC の state-centric 設計が「再作成更新の強み」と「monitoring の弱み」両方の根だと位置づけ([[Infrastructure as Code]] に追記)、(2) 提案の **agent-cloud interface** が [[AIOpsLab]] の同名 ACI と用語・設計で独立に収束(評価基盤と運用アーキの双方で境界面が立つ)、(3) 自律度の段階化(co-pilot/semi-auto/fully-auto + guardrail + human fallback + rollback)が [[Google]] の [[SRE AI Autonomy Levels]] L0–L4 と独立に同じ結論へ、(4) agentic SRE は「読み中心の診断/緩和」、クラウド管理は「書き込みを含む全ライフサイクル」で、同じ反復ループ(exploration→metaprogram→workflow caching ≒ perception→…→memory)を共有しつつ resource drift/race condition という整合性問題が新たに前面化([[agentic SRE]] に追記)。また §4 で AIOps を「データ分析」、自らを「自律的行動」と差別化し、AIOps の射程拡大スレッド([[AIOps]])を明文化。**出典検査**: 媒体・著者・DOI は CrossRef で裏取り(ACM 本体は 403)。ページ 2・5 は本文テキスト層が無い全面ラスター図(Figure 1 モダリティ/2 レーダー/3 アーキ)で、180° 回転 + 上下反転で復元し §2.1・§3.1 を読了。本文の図番号は不整合(モダリティ図を "Figure 2(a–d)" と参照するがキャプションは "Figure 1")で、本ノートはキャプション番号に従う旨を source に明記。予備実験は Azure・VM・少数タスク・8 試行・固定モデルに限定で小標本(`confidence: high` だが一般化は未検証)。[[Yunming Xiao]](本論文)と既存 [[Yibo Xiao]]([[Pulse]]/[[Nanjing University]])は別人として disambiguation note を付与。**総 250→261 ページ・実ソース 38→39**。 2026-06-04: [[@2025__arXiv__TimeCopilot]](Garza & Rosillo、arXiv:2509.00616v3、NeurIPS 2025 Workshop BERT2S、2025)を **wiki-ingest-paper** で取り込み(38 ソース目)。**[[エージェント型時系列予測]](ATSF)の Workflow パラダイムに、[[時系列基盤モデル]] を一切使わない [[TimeSeriesScientist]] と対極をなす「TSFM 最大級ハブ + アンサンブル」型の代表実装が揃った**。source 1 + entity 3 新規([[Azul Garza]] / [[Renée Rosillo]] / [[TiRex]])、既存 entity 4 更新([[TimeCopilot]] を seed→developing で本体論文の詳細を追記、[[GIFT-Eval]]・[[Chronos-2]]・[[TimesFM]] に MedianEnsemble 構成・SOTA 達成を追記)+ concept 2 更新([[エージェント型時系列予測]]・[[時系列基盤モデル]] の横断的知見/未解決の問いを積み増し)。**核心**: 複数の TSFM・統計・ML・DL の予測手法を単一の統一 API 下に集約し、LLM を推論エンジンとして予測パイプライン全体(特徴分析 → モデル選択・評価 → 最終選択・予測)を自動化する初のオープンソースなエージェント型フレームワーク。LLM は (i) 各ステップの行動決定と (ii) モデル選択・予測の自然言語説明の二役。2 エントリポイント(end-to-end の Agent と個別モデル直接制御の Forecaster)。[[GIFT-Eval]](24 データセット・144k+ 系列・1.77 億点)で MedianEnsemble([[Chronos-2]]+[[TimesFM]]+[[TiRex]] を isotonic regression で結合)が確率予測 CRPS の平均ランク・平均スコアで全体最良を、約 $24 の GPU 分散推論という低コストで達成(点予測 MASE は Chronos-2 に次ぐ 2 位)。**最大の横断的知見 2 点**: (1) Workflow パラダイムの 2 実装([[TimeCopilot]]=TSFM アンサンブルハブ / [[TimeSeriesScientist]]=基盤モデル不使用の 21 モデル軽量ライブラリ)が「予測力の源泉」で対極をなし、同じ Workflow の骨格でも行動空間に何を置くかが独立——ATSF の「プロセスの組織化は基盤モデルの有無と直交する」を Workflow 系内部で例証、(2) TSFM 研究の「単一最良モデル」競争の上に「アンサンブル・オーケストレーション層」が乗り、複数 TSFM の結合([[Chronos-2]]+[[TimesFM]]+[[TiRex]])が各単体 SOTA を上回る——TSFM の精度向上が終着点でなく [[エージェント型時系列予測]] が言う「行動空間の 1 ツールとして束ねる」の具体化。**出典検査**: 本論文は 9 ページの短いワークショップ論文で、GIFT-Eval SOTA の実体は MedianEnsemble(基盤モデル 3 種 + isotonic regression)であり LLM オーケストレーションの正味寄与を切り分けたアブレーションが無い点を未解決の問いに記録(AgenticRL の [[Cast-R1]] のコンポーネントアブレーションと対照)。著者の所属は論文に明記なし(San Francisco のみ)、Nixtla との関連は参照リストの GitHub URL からのみ推定可能。**総 246→250 ページ・実ソース 37→38**。 2026-06-04: [[@2025__arXiv__TimeSeriesScientist - A General-Purpose AI Agent for Time Series Analysis]](Zhao+, [[Stony Brook University]] ほか、corresponding [[Chenyu You]]、arXiv:2510.01538v2, 2025-10)を **wiki-ingest-paper** で取り込み(37 ソース目)。**既に ingest 済みのポジションペーパー ATSF([[@2026__arXiv__Position Beyond Model-Centric Prediction - Agentic Time Series Forecasting]])が掲げた 3 パラダイムのうち、Workflow の典型実装を投入し、AgenticRL の [[Cast-R1]] と対をなす一対が wiki に揃った**。source 1 + entity 6 新規([[TimeSeriesScientist]] / [[Haokun Zhao]] / [[Xiang Zhang]] / [[Jiaqi Wei]] / [[Chenyu You]] / [[Stony Brook University]])+ concept 1 更新([[エージェント型時系列予測]] の横断的知見/未解決の問いを積み増し)。**核心**: 単変量時系列予測の全工程を Curator(LLM ガイド診断+前処理+可視化+構造プロファイリング)→ Planner(モデル選択+ハイパラ最適化+ランキング)→ Forecaster(3 系のアンサンブル戦略を LLM が選択、テスト前に重み固定でリーク回避)→ Reporter(5 部のホワイトボックスレポート)の固定 SOP で自動化する初の LLM 駆動エージェント型フレームワーク。21 モデル(統計 7/ML 6/木 4/NN 2/専用 2)のライブラリを内蔵し[[時系列基盤モデル]]は不使用、GPT-4o バックボーン。8 ベンチ 5 ドメイン(ETT×4/Weather/ECL/Exchange/ILI、25 スライス・T=512・H∈{96,192,336,720})で統計比 MAE 平均 -10.4%・LLM 直接予測比 -38.2%、8/8 で MAE 最良。レポートも 5 ルーブリック(AS/MJ/IC/AQ/SC)の win rate で全 LLM 超(AS/MJ は 80% 超)。**最大の横断的知見 3 点**: (1) ATSF が概念で並置した Workflow(TSci=固定 SOP・RL なし・明示計画)と AgenticRL([[Cast-R1]]=報酬最適化)の両パラダイムが別グループの独立実装で出そろい、行動選択の獲得方式(プロンプト設計 vs 報酬学習)で分岐、(2) ATSF の「perception=適応的前処理が鍵」を TSci のアブレーション(前処理除去 MAE +41.8%、3 モジュール中最大)が定量裏づけ——ただしボトルネックの所在は TSci=前処理 vs Cast-R1=予測器([[Chronos-2]] 依存)で異なる、(3) TSci は基盤モデルゼロで LLM 直接予測を平均 38.2% 上回り「予測能力の源泉はモデル規模でなくプロセスの組織化」という ATSF の主張を対極の構成から例示。**出典検査**: abstract(38.2%)と intro(38.3%)で LLM 比削減率の表記が不一致、TSci は固定 SOP で ATSF が中核に据える動的再計画・省察を持たない点を未解決の問いに記録。**総 239→246 ページ・実ソース 36→37**。 2026-06-04: AIOps/RCA の一次論文 3 本を **wiki-ingest-paper** で subagent 並行取り込み(34–36 ソース目)。**(1) [[@2025__ICLR__OpenRCA - Can Large Language Models Locate the Root Cause of Software Failures]]**([[Junjielong Xu]]/[[Shilin He]]/[[Dan Pei]]/[[Pinjia He]] ら、ICLR 2025, OpenReview M4qNIzQYpd): LLM の RCA 能力を測る初の大規模ベンチ [[OpenRCA]]。335 障害 + 68.5GB テレメトリを静的に与え 7 goal を問う。コード実行型 RCA-agent でも最良 Claude 3.5 で 11.34%・Hard 全モデル 0.00%、性能はモデルのエラー耐性に律速(Gemini 実行失敗 −68.4%)。**(2) [[@2026__arXiv__Cloud-OpsBench - A Reproducible Benchmark for Agentic Root Cause Analysis in Cloud Systems]]**([[Guangba Yu]]/[[Pengfei Chen]]/[[Michael R. Lyu]]、arXiv:2603.00468, 2026): エージェント型 RCA の再現可能ベンチ [[Cloud-OpsBench]]。452 障害・40 種・[[Kubernetes]] 全スタックを **State Snapshot**(決定論的デジタルツイン)で凍結し、結果 A@k でなく**推論過程を採点する初の white-box 評価**(IAC/RAR/ZTDR)を導入(A@1=0.73 でも ZTDR=0.32)。SLM=構文脆弱性、frontier=パラメトリック幻覚と認知欠陥を分離。**(3) [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]]**([[Guangba Yu]]/[[Pengfei Chen]]([[Sun Yat-sen University]])+[[Tencent]]、ASE 2025 experience paper): アラートライフサイクルを denoise(LLM 不使用の軽量グラフ)→summary(RAG+LLM、RCA 90.5%)→rule refinement(マルチエージェント、1,174 提案→375 受容)で一気通貫管理。本番(Tencent)で MTTR 156→21 分(7.4倍)・日次 30万→1.5万。既存 papers/ ノートは温存し一方向参照。**3 本横断の最大の知見**: OpenRCA(静的テレメトリ QA)と Cloud-OpsBench(決定論的スナップショット)が、ライブ環境ベンチ([[AIOpsLab]]/[[SREGym]]/[[ITBench]])と純静的データセットの中間に位置する RCA 特化の「第三の型」を別アプローチで示し、RCA に限れば能力天井がライフサイクル全体ベンチ(最高 6 割前後)より桁違いに低い(Claude 11.34%・Hard 0%)ことを定量化。診断オラクルが厳密一致→トポロジ→LLM judge に続き Cloud-OpsBench の**過程評価(IAC/RAR/ZTDR)**という第四の型へ拡張。AlertGuardian は同 ASE2025 の [[LogPilot]](単発診断)に対し「ライフサイクル全体最適化」の対比軸を立て、CSUR サーベイの 3 段タスク分類(知覚→RCA→緩和)を全段で具体化する。subagent 並行取り込みで共有エンティティ([[Guangba Yu]]/[[Pengfei Chen]]/[[Sun Yat-sen University]]/[[The Chinese University of Hong Kong]])が衝突したが per-file lock 協調下で再読込・マージし重複なし。[[Guangba Yu]] の所属(SYSU↔CUHK)は contradiction callout で両出典保持。source 3 + entity 12 新規・concept 8 更新(根本原因分析/SRE Benchmark/AIOps/agentic SRE/インシデント管理/異常検知/障害注入/テレメトリ)。**総 224→239 ページ・実ソース 33→36**。 2026-06-04: [[@2025__arXiv__Foundation Models for Time Series - A Survey]](Kottapalli+, [[Dell Technologies]] / University of Massachusetts Lowell / Worcester Polytechnic Institute, arXiv:2504.04011v1, 2025-04)を **wiki-ingest-paper** で取り込み(33 ソース目)。**vault が個別に深掘りしてきた TSFM 群([[Toto]]/[[TimesFM]]/[[Chronos-2]]/[[Falcon-X]]/Cisco TSM)を俯瞰する 6 次元タクソノミーの「地図」を投入**。source 1 + entity 2 新規([[Dell Technologies]] / [[Siva Rama Krishna Kottapalli]])= 3 ページ作成、既存 entity 3([[Toto]] に contradiction + サーベイ分類、[[TimesFM]]・[[Chronos-2]] にサーベイ分類)・concept 3([[時系列基盤モデル]]・[[多変量時系列予測]]・[[Mixture-of-Experts]] の横断的知見/未解決の問いを積み増し)を更新。**核心**: 15 の代表 TSFM を (1) アーキテクチャ(Non-Transformer/Encoder-decoder/Encoder-only/Decoder-only/Adapting LLM)、(2) パッチ有無、(3) 目的関数、(4) 単変量/多変量、(5) 確率的/決定論的、(6) 規模の 6 軸で分類(Figure 8・Table 2)。**目的関数による分類は既存サーベイにない独自軸**(MSE/Huber/NLL/Log-Likelihood/Cross Entropy)。**最大の横断的知見 4 点**: (a) サーベイの 6 軸が vault の個別観察(アーキ分岐・多変量化が主戦場)に包括的な座標系を与える一方、observability ドメインの統計特性を扱わず [[Toto]] を「[[Datadog]] 内部データで学習」とだけ記述する——汎用 ML の地図と観測特化研究の視点差、(b) 評価指標の二分(MASE 対 CRPS)が訓練目的関数の二分(点予測 MSE/Huber 対 確率的 NLL/Log-Likelihood)と対応、(c) サーベイが「多変量対応」とする channel-independent モデル(AutoTimes/Time-LLM/FPT)を [[Falcon-X]] は cross-variate の退化として除外する——「多変量」の分類基準がソース間で食い違う、(d) MoE が LLM 訓練から TSFM へ適用領域を広げ(Time-MOE、2.4B、Huber+auxiliary loss)、routing collapse をシステム層(配置)とモデル層(損失)の異なる解で抑える([[Mixture-of-Experts]] の横断的知見を初めて 2 ソースで実体化)。**出典検査で要確認 2 点**: [[Toto]] のスペック(サーベイ 103M・1 兆点 対 vault/NeurIPS 版 151M・約 2.36 兆点)はモデルバージョン差と見られ contradiction callout で両ページに明示。サーベイの「Chronos」は初代(T5・単変量)で vault の [[Chronos-2]](group attention・多変量)とは別世代——混同回避の note を追加。サーベイ自体に分類の揺れ(MOMENT の単変量/多変量、TimesFM のデータ点数 100B/200B)と ACM テンプレートのプレースホルダ残存あり。`confidence: high`(二次サーベイだが各分類は Table 2/Figure 8 に遡及可能)。structures の [[時系列基盤モデル - MOC]] が既に本サーベイを Papers に登録済みで、source→MOC の一方向参照で相互リンク成立。**総 221→224 ページ・実ソース 32→33**。 2026-06-04: [[@2026__arXiv__Cast-R1 - Learning Tool-Augmented Sequential Decision Policies for Time Series Forecasting]](Tao+, [[University of Science and Technology of China]], arXiv:2602.13802v1)を **wiki-ingest-paper** で取り込み(32 ソース目)。**既に ingest 済みのポジションペーパー ATSF([[@2026__arXiv__Position Beyond Model-Centric Prediction - Agentic Time Series Forecasting]])が AgenticRL の代表として参照しつつ dead link だった [[Cast-R1]] を、同グループの一次論文として実体化**。source 1 作成 + [[Cast-R1]] スタブ実体化・[[Xiaoyu Tao]]・[[Mingyue Cheng]] に source 参照追記(entity 3)+ [[エージェント型時系列予測]]・[[強化ファインチューニング]]・[[時系列基盤モデル]] の横断的知見/未解決の問いを積み増し(concept 3)。**核心**: 時系列予測を逐次的意思決定問題へ再定式化し、(1) 記憶ベース状態管理、(2) モジュール式ツールキット(統計特徴抽出・データ品質診断・[[変化点検知|変化点検出]]・予測モデル呼び出し)を介したツール拡張エージェントワークフロー、(3) SFT + マルチターン RL([[強化ファインチューニング|GRPO]])+ カリキュラム学習の 2 段階学習、を組み合わせ、実世界 10 データセット(ETT 4 種・Wind・EPF 5 種)で全データセット最低 MSE を達成。予測モデル([[Chronos-2]]・[[TimesFM]]・PatchTST・iTransformer・ARIMA・DLinear)を固定コンポーネントでなく状態認識的に選ぶ「ツール」として扱う。**最大の横断的知見**: ポジションペーパー ATSF が実験なしに掲げた主張群を、同グループの AgenticRL 実装 Cast-R1 のアブレーションが個別に裏づけた——予測モデルを行動空間の 1 ツールとして呼ぶ([[Chronos-2]] 単独除去で volatile NP が MSE 22.5→55.4、予測モデルツール全除去で ETTh1 6.062→15.993)、省察(Refine)・記憶(Memory)・計画(Planning)が性能を生む(いずれも除去で劣化)、適応的行動選択は報酬最適化で獲得(RL 除去が最大劣化 NP 24.750→54.631)。position が概念で示した骨格を実装の実験が支える関係。また GRPO が「LLM 推論・コード生成の事後学習」から「時系列予測エージェントのポリシー学習」へ応用領域を広げた点で [[強化ファインチューニング]](RFT-FM)とドメインを越えて接続。**出典検査で未完成プレプリントの瑕疵を検出**: 本文(Qwen3-8B/4×A800 80GB)と Appendix(Qwen3-1.7B/単一 RTX 4090D 24GB)で実装設定が矛盾、Table 2 の主結果数値が scaling 表の Qwen3-4B 行と一致(8B でない)、ACM テンプレートのプレースホルダ(「Conference acronym 'XX」「© 2018」「revised 12 March 2009」)が残存。**総 220→221 ページ・実ソース 31→32**(source 1 新規、entity は既存スタブ実体化のため新規 0)。 2026-06-04: 時系列・LLM 後訓練の一次論文 3 本を **wiki-ingest-paper** で subagent 並行取り込み(29–31 ソース目)。**(1) [[@2026__arXiv__ARFBench - Benchmarking Time Series Question Answering Ability for Software Incident Response]]**([[Carnegie Mellon University]]/[[Datadog]]/[[Amazon Web Services]], arXiv:2604.21199): ソフトウェアインシデント対応の時系列質問応答(TSQA)を測る初のベンチ [[ARFBench]]。[[Datadog]] の本番インシデント Slack タイムラインを専門家アノテーションの一次源とし、750 問・142 系列・538 万点を Tier I/II/III(111/306/333)で構成。事前学習済み TSFM([[Toto]])を VLM([[Qwen3-VL]])と結合した [[Toto-1.0-QA-Experimental]] が精度 63.9% でフロンティアモデル(GPT-5 62.7%)に並び、人間専門家との best-of-2 オラクルが精度 87.2%・F1 82.8% の超人的フロンティアを示す。新概念 [[時系列質問応答]]、既存 [[異常検知]]/[[時系列基盤モデル]]/[[インシデント管理]] を更新。**(2) [[@2025__arXiv__Cisco Time Series Model Technical Report]]**([[Cisco]]/[[Splunk]], arXiv:2511.19841): 観測ドメイン特化の時系列基盤モデル(Cisco TSM)。[[TimesFM]] に特殊トークンと解像度埋め込みを足して継続事前学習し、粗い 1 時間 + 細かい 1 分のコンテキストを連結した「多解像度の長コンテキスト」を 1/30 の系列長で扱う。約 400M 系列・13 か月・300B 点超で学習、観測データで競合 TSFM([[Toto]]/[[Chronos-2]])を上回りつつ [[GIFT-Eval]] の汎用能力も保つ。[[時系列基盤モデル]] を更新。**(3) [[@2026__arXiv__Towards Robust LLM Post-Training - Automatic Failure Management for Reinforcement Fine-Tuning]]**(PKU/[[Alibaba Group]]/[[University of Illinois Chicago]], arXiv:2605.04431): AIOps の検知→診断→修復の障害管理ライフサイクルを、[[MicroRemed]]・LLM4AIOps サーベイと同じ PKU グループ([[Lingzhe Zhang]] ら)がマイクロサービス運用から LLM の[[強化ファインチューニング]](RFT)の訓練プロセスへ移植。初の細粒度障害ベンチ [[RFT-FaultBench]](5 families/16 types/779 runs/145 万 trajectory)と閉ループ [[RFT-FM]] を提示、検知 F1 87.96%・Mitigation Rate 46.25%・自動修復の不安定性 MSC -5.84%。新概念 [[強化ファインチューニング]]、既存 [[異常検知]]/[[障害緩和]]/[[障害注入]]/[[AIOps]] を更新。**3 本横断の最大の知見**: [[時系列基盤モデル]]の評価が「より良い単一モデル」(Cisco TSM の多解像度)から「インシデント文脈での推論能力」(ARFBench の TSQA)へ広がり、後者は [[Toto]] の観測特化事前学習が VLM 結合で QA にも効くことを示す。RFT 論文は AIOps の障害管理ライフサイクルが本番サービス運用を越えて LLM 訓練プロセスへ転用可能なことを実証し、[[Minder]]/[[Pulse]] の「訓練クラスタのハードウェア障害検知」とは別軸(訓練アルゴリズム自体の障害)で [[GPUクラスタ運用]]/[[LLM学習モニタリング]] に接続しうる。subagent 3 体の並行取り込みで共有エンティティ([[Toto]]/[[時系列基盤モデル]]/[[異常検知]])が衝突したが per-file lock 協調下で再読込・マージし重複なし。**総 196→220 ページ・実ソース 28→31** に更新(source 3 + entity 19 + concept 2 = 24 新規、既存 entity/concept は積み増し)。 2026-06-04: [[@2024__SOSP__Unearthing Semantic Checks for Cloud Infrastructure-as-Code Programs]]([[Zodiac]], Qiu+, [[University of Michigan]]×[[Microsoft]], SOSP '24, DOI:10.1145/3694715.3695974)を **wiki-ingest-paper** で取り込み。ソース 1 + エンティティ 8 新規([[Yiming Qiu]] / [[Patrick Tser Jern Kon]] / [[Ryan Beckett]] / [[Ang Chen]] / [[University of Michigan]] / [[Zodiac]] / [[Terraform]] / [[Microsoft Azure]])+ 概念 2 新規([[Infrastructure as Code]] / [[設定マイニング]])= 11 ページ作成、既存のエンティティ 1([[Microsoft]])・概念 1([[障害注入]])を更新。**直下の Lilac/NSync と同一の [[Ang Chen]] グループ IaC 3 部作の起点で、デプロイ前検証(順方向)を担う**。核心: IaC(Terraform)プログラムがコンパイルを通過してもデプロイ時に失敗する **semantic gap**(テナント/プロバイダ分離が根本原因。例: Azure の「VM と NIC は同一リージョン」「サブネット CIDR は重複不可」は構文チェックを通る)を、(1) セマンティックチェックの[[設定マイニング|マイニング]]——セマンティック KB(IaC native/provider 固有/resource references の 3 クラス)+ グラフ上の DSL(conn/path/coconn/copath + indegree/outdegree)+ 84 テンプレート + confidence/lift フィルタ + GPT-4 interpolation、(2) デプロイベース検証——SMT(Z3)で「**ただ 1 つのチェックのみを違反**する」negative test case を構成(MDC pruning + 検証スケジューリングで false positive removal/true positive validation を反復)、で埋める。Azure 52 リソース種別・26,000 リポジトリ・3.8M 行から 9,800 仮説 → 510 検証済みチェック、TFLint/Checkov 等が捕えない inter-resource 制約を含む。200+ バグ repo + Terraform Azure provider 公式ドキュメント 4 件(GitHub #27065/#27078/#27194/#27222)を修正。open-world assumption ゆえ健全性なし(偽陽性 5.4%)。**横断的知見**: Zodiac の negative test case 生成は構成への「デプロイ時障害注入」で、84.4% が silent な[[障害注入]]問題と同型——注入が障害化しない偽陽性を実環境観測(マイクロサービス=SLI、IaC=デプロイ成否)で篩う点が通底し、SMT で単一違反を保証する精密化が注入ベンチの「真の原因と症状の切り離し」への構成的答えになると [[障害注入]] に追記。3 者横断の IaC ライフサイクル地図(順方向検証/逆生成/drift 修復、LLM+symbolic+KB の収束)は別セッションが [[Infrastructure as Code]] に集約済み(私の Zodiac 内容を per-file lock 協調下で保全・増築)。並行 ingest 多数(Zodiac/Lilac/NSync/eBPF/ATSF)で index がドリフトしたため、実ファイル数で **総 186→196 ページ・実ソース 25→28** に reconcile(共有エンティティの index 登録は Lilac/NSync 側が Zodiac 側へ委譲、重複なし)。 2026-06-04: クラウド IaC × LLM エージェントの一次論文 2 本を **wiki-ingest-paper** で取り込み。[[@2025__arXiv__Automated Cloud Infrastructure-as-Code Reconciliation with AI Agents]]([[NSync]], [[University of Michigan]]+[[Amazon Web Services]], arXiv:2510.20211)と [[@2025__AIOps__Automated Lifting for Cloud Infrastructure-as-Code Programs]]([[Lilac]], [[University of Michigan]]+[[University of California, San Diego]], AIOps 2025 / ICSE workshop)。**ソース 2 + エンティティ 8 新規**([[NSync]] / [[Lilac]] / [[Amazon Web Services]] / [[University of California, San Diego]] / [[Zhenning Yang]] / [[Jingjia Peng]] / [[AWS CloudTrail]] / [[aztfexport]])、**概念 2 更新**([[Infrastructure as Code]] / [[AIOps]])、既存エンティティ 5 へ一方向参照を積み増し([[Terraform]] / [[University of Michigan]] / [[Ang Chen]] / [[Yiming Qiu]] / [[Patrick Tser Jern Kon]])。**取り込み中、別セッションが同じ [[Ang Chen]]/[[University of Michigan]] グループの [[Zodiac]](SOSP'24、IaC のデプロイ前セマンティックチェック)を並行 ingest しており、概念 [[Infrastructure as Code]]・エンティティ(Terraform/UMich/Ang Chen/Yiming Qiu/Patrick Kon)が衝突——重複を作らず統合した**(共有エンティティの index/_index 登録は Zodiac 側に委ね、重複時は wiki-lint で dedup)。**最大の横断的知見**: IaC ライフサイクルを順方向のデプロイ前検証([[Zodiac]])・逆方向の lifting([[Lilac]])・drift 修復([[NSync]])の 3 方向で同一研究室が攻め、いずれも **LLM + symbolic guardrail(NSync は drift_report/self_critique・Lilac は import/equivalence/redeployment 検証)+ 蓄積する知識ベース**へ独立に収束。**inter-resource 依存が方向を問わず最難所**(Zodiac は順方向検証、Lilac は依存復元、NSync は attach/detach 統合で同じ核に当たる)。クラウド API が検証・逆生成・修復の共通最下層([[NSync]] の「全変更は API へ帰着」=[[AWS CloudTrail]] 観測、[[Lilac]] の API discovery)。NSync は lifting を「ゼロからの脆い synthesis」と差別化し自らを「既存への program repair」と位置づける一方、Lilac は dependency restoration で NSync が突く lifting の弱点(生 ID ハードコード)に正面から取り組む——逆生成と修復は競合でなくブラウンフィールド IaC 化の補完。AIOps が事後対応の診断(検知/RCA/緩和)から先回りの構成管理(IaC 検証/lifting/reconciliation)へ外延を広げる実例として [[AIOps]] にも追記。 2026-06-04: [[@2026__eunomia.dev__eBPF × AI-LLMs - The Convergence of System Observability and AI]]([[Yusheng Zheng]], [[eunomia-bpf]], `eunomia.dev/GPTtrace/`)を取り込み(25 ソース目)。ソース 1 + エンティティ 6 新規([[Yusheng Zheng]] / [[eunomia-bpf]] / [[bpftime]] / [[GPTtrace]] / [[AgentSight]] / [[Kgent]])+ 概念 1 新規([[eBPF]])= 8 ページ作成、既存の概念 2([[テレメトリ]] / [[agentic SRE]])・エンティティ 2([[Model Context Protocol]] / [[go-conntracer-bpf]])を更新。**本 wiki 初のカーネル層(eBPF)の角度を持つソース**で、これまで一貫してアプリケーション層の AIOps/RCA/可観測性を扱ってきた vault に新レイヤーを足す。URL は [[GPTtrace]] のページだが内容は GPTtrace 単体でなく **eBPF×AI 全体の総説 + 厳選リスト(awesome list)**。**核心は双方向の共生ループ**: (a)**eBPF for AI** — カーネル層の高忠実度テレメトリで AI/ML ワークロード・エージェントを観測・最適化([[AgentSight]] が eBPF TLS 傍受 + カーネルシグナル + 二次 LLM 分析で claude code/gemini-cli を **<3% オーバーヘッド**で追跡、GPU の uprobe トレース、[[bpftime]] の eGPU が eBPF を GPU へオフロード)、(b)**AI for eBPF** — LLM がカーネル拡張を生成・検証([[Kgent]]/KEN が Z3 記号検査 + テストで**約 80% の意味的正しさ**、[[GPTtrace]] が実装、SimpleBPF/DiffSpec/LLM スケジューラ合成)。**横断的知見 3 点**: (1) [[テレメトリ]] の計装層([[go-conntracer-bpf]] の eBPF 系譜)の最前線がゼロ計装のカーネル/エージェント可観測性に進んだ、(2) [[agentic SRE]] にエージェントを「動かす側」でなく「観測する側」に置く第 3 の軸([[SRE AI Autonomy Levels]]/[[Actus]] の安全制御をカーネル層で補完)が立ち上がった、(3) [[Model Context Protocol]] が SRE の本番アクセスだけでなく eBPF/カーネルツール(Inspektor Gadget MCP・ebpf-mcp・MCPtrace・Ingero)をエージェントへ公開する標準としても使われ始めた。「生成系を検証器で囲む」([[Kgent]] の Z3)が [[agentic SRE]] の「安全に巻き戻せる反復」([[Transactional No-Regression]])と同型の信頼性パターンである点も新 concept [[eBPF]] に集約。本ソースは awesome list(二次情報)ゆえ `confidence: medium`、[[AgentSight]](arXiv:2508.02736)・[[Kgent]](eBPF'24)の一次取り込みを未解決の問いに残す。並行 ingest(ATSF 論文)と競合したため共有ファイルは wiki-lock 取得後に編集、総ページ 178→186・実ソース 24→25 に reconcile。 2026-06-04: [[@2026__arXiv__Position Beyond Model-Centric Prediction - Agentic Time Series Forecasting]](Cheng+, [[University of Science and Technology of China]], arXiv:2602.01776v4 [cs.LG])を取り込み(24 ソース目)。ソース 1 + エンティティ 7 新規([[Mingyue Cheng]] / [[Xiaoyu Tao]] / [[Qi Liu]] / [[Enhong Chen]] / [[University of Science and Technology of China]] / [[Cast-R1]] / [[TimeCopilot]])+ 概念 1 新規([[エージェント型時系列予測]])= 9 ページ作成、既存の概念 2([[時系列基盤モデル]] / [[agentic SRE]])を更新。**本 wiki 初のエージェント型時系列予測の一次論文(かつ初のポジションペーパー)**。時系列予測をモデル中心・静的・シングルパスの関数近似から、知覚・計画・行動・省察・記憶の 5 コンポーネントからなる反復的・マルチターンな意思決定プロセス(ATSF)へ再定式化する立場を主張する。**核心は 3 点**: (1) 予測モデルの呼び出し自体を行動空間の 1 つとして扱い、ツール相互作用・フィードバック取り込み・経験蓄積による進化を重視する(Table 1 で既存全パラダイムが欠くツール利用・進化を ATSF だけが持つ)、(2) 実装を Workflow(構造的安定、例 [[TimeCopilot]])・AgenticRL(自律的進化、例 [[Cast-R1]])・AgenticFlow(ハイブリッド)の 3 パラダイムに整理(Table 2)、(3) ポジションペーパーゆえ実験はなく、進歩の主軸を「モデルアーキテクチャの反復」から「ワークフロー設計・ツール構成・意思決定ポリシーのシステムレベル進化」へ移すべきだと論じ、5 機会・7 課題を提示。**横断的知見**: ATSF の perception→planning→action→reflection→memory の反復ループが [[agentic SRE]] の「観測→行動→検証→反省」分割([[Stratus]]/[[ThinkRemed]]/[[Bits AI SRE]])と同型で、agentic 設計原理がドメインを越えて共有されることを示す。知覚を「何を関連情報とみなすか」の適応的認知ステップと位置づける点は「情報を絞ってから推論」の骨格([[MetricSifter]]/[[LogPilot]]/[[Stratus]])と通底。ATSF はモデル規模・[[時系列基盤モデル]]と直交し、TSFM を置換せず行動空間の 1 ツールとして呼び出す立場を取る(TSFM の精度競争と予測プロセスの組織化は階層をなす)。これまでの時系列ソース([[Toto]]/[[Falcon-X]]/[[TelecomTS]])が「より良い単一モデル」を競う文脈に対し、本論文は「予測の上の層(プロセス組織化)」を初めて投入。 2026-06-03: [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]](Jiang+, [[The Chinese University of Hong Kong]]×[[ByteDance]], ASE 2025 採録, arXiv:2509.25874)を取り込み(実カウント 23 ソース目)。ソース 1 + エンティティ 6 新規([[LogPilot]] / [[Zhihan Jiang]] / [[Michael R. Lyu]] / [[Tieying Zhang]] / [[The Chinese University of Hong Kong]] / [[Volcano Engine]])+ 概念 1 新規([[ログ解析]])= 8 ページ作成、既存のエンティティ 1([[ByteDance]])・概念 3([[根本原因分析]] / [[異常検知]] / [[Fault Localization]])を更新。**本 wiki 初のログ専門のアラート診断/RCA 一次論文**。これまでの RCA/検知ソースが [[Bits AI SRE]](マルチモーダル横断)・[[MetricSifter]](メトリクス)・[[MonitorAssistant]](メトリクス監視のメタ層)だったのに対し、LogPilot は**ログ単一モダリティ**に絞り構造化で深掘りする。**核心は 3 点**: (1) アラート定義(PromQL)の意味的意図を LLM に解釈させ因果的に関連するログを絞る intent-aware scoping——keyword search やログ異常検知(LogRobust/LogAnomaly)の alert-agnostic な絞り込みを批判し、ALC agent が DSL クエリ付きフィルタリングツールを生成(feedback で最大 3 反復の refinement、同一 PromQL はキャッシュ再利用)、(2) request を spatiotemporal log chain に再構成し(two-tier parsing: logging path で粗くクラスタ → Drain)、対数スケール cosine 類似度 + HAC($\theta_{HAC}=0.7$)でクラスタリング、各クラスタの centroid 最近傍の代表 request だけを診断して LLM 呼び出しを平均 198.65 request → 最大 13(**98.71% 削減**)、(3) Volcano Engine の 4 サービス・202 アラートで根本原因要約の有用性 +50.34%(RCACopilot 比)・exact localization +54.79%(RCA Agent 比)、$0.074/アラート・E2E 58.6 秒、12 本番サービスで 3,500+ アラートを分析し受容率 84.21%(完全正解 60.53%)。**横断的知見**: 「情報を絞ってから推論」の骨格が [[MetricSifter]](メトリクス削減 [[特徴量削減]])・[[Bits AI SRE]](テレメトリ過剰消費回避)とモダリティを越えて通底し、ログ解析では「request クラスタリングで代表抽出」として実装された。産業側が「文脈なしの異常検知/keyword 絞り込みは不十分」と一貫し、アラート/インシデントの文脈でシグナルを絞る([[MonitorAssistant]] の実用的異常定義と同型)。新 concept [[ログ解析]] に log scoping + RCA の 2 段、ログ単一深掘り vs マルチモーダル横断の設計分岐を集約。ログ解析の二大ハブ([[Michael R. Lyu]]/[[Dan Pei]])の一次論文が wiki に揃い始めた。なお別セッションが [[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]] を並行 ingest し Rethinking を「23 ソース目」と採番していたが、過去エントリの番号に +1 のズレがあり実ソース数は LogPilot を含め 23。index を 169 ページ/23 ソースに reconcile(per-file lock で torn write は回避)。 2026-06-03: [[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]](Fang+, [[The Chinese University of Hong Kong, Shenzhen]], arXiv:2510.04711v2 [cs.SE])を取り込み(23 ソース目)。ソース 1 + エンティティ 3 新規([[Aoyang Fang]] / [[Pinjia He]] / [[The Chinese University of Hong Kong, Shenzhen]])+ 概念 1 新規([[障害注入]])= 5 ページ作成、既存のエンティティ 2([[Train-Ticket]] / [[ChaosMesh]])・概念 1([[根本原因分析]])を更新。**本 wiki 初の「データ駆動 RCA モデル評価ベンチマークの妥当性」を問う一次論文**。これまでの RCA ソースが [[Bits AI SRE]](産業エージェント)・[[MetricSifter]](統計手法)・[[TelecomTS]](データセット)だったのに対し、本論文は**評価そのもののメタ批判**を投入。**核心は 4 点**: (1) 最多アラートのサービスを根本原因とするだけの単純ヒューリスティック SimpleRCA が 4 公開ベンチ(Eadro/Nezha/RCAEval/AIOps-2021)で SOTA に匹敵/凌駕(Nezha-TT 0.93 対 0.87、RE3-SS 0.83 対 BARO 0.00)——「進歩」がベンチの単純さの産物という反例、(2) 既存ベンチの障害ケースの 86% が Type I(根本原因サービスのみに症状が局所化)+ Type II(顕著な症状なし)、99% が観測データ不完全という品質欠陥の定量化、(3) [[Train-Ticket]](50 サービス)+ 状態機械の動的ワークロード + [[ChaosMesh]] の 31 障害種別で 9,152 注入から impact-driven validation した 1,430 ケース・25 種別・最大コール深度 7 の障害伝播ベンチを生成、11 SOTA を再評価し平均 Top@1 0.21・最高 MicroRCA 0.37、(4) 3 失敗モード(Modeling Bottlenecks 47.4% / Scalability Issues 39.8% / Observability Blind Spots)。**横断的知見**: 9,152 注入の 84.4% が silent fault という定量化が、[[ChaosMesh]] への「症状しか注入しない」批判([[AIOpsLab]]/[[SREGym]])をさらに進め、新 concept [[障害注入]] の核に。RCA の前提条件が「情報の量(削減: [[MetricSifter]])・質(スケール: [[TelecomTS]])・完全性(被覆: 本論文)」の 3 つに整理された。impact-driven validation はユーザー向け SLI に依拠するため oracle problem(subtle な真の劣化を誤って除外)を抱え、[[Metastable Failure]] のようなシステム層障害が評価から落ちる課題も明示。 2026-06-03: [[@2024__ESEC-FSE__MonitorAssistant - Simplifying Cloud Service Monitoring via Large Language Models]](Yu+, [[Tsinghua University]]×[[Microsoft]], ESEC/FSE 2024 Industry Track, DOI:10.1145/3663529.3663826)を取り込み(22 ソース目)。ソース 1 + エンティティ 3([[MonitorAssistant]] / [[Zhaoyang Yu]] / [[Dan Pei]])= 4 ページ作成、既存のエンティティ 1([[Minghua Ma]])・概念 1([[異常検知]])を更新。**学術—産業ギャップを LLM メタ層で橋渡しする初の産業投入事例**。深層学習手法が産業界で普及しない 3 課題(モデル選択・異常解釈・エンジニア相互作用)を整理し、「実用的異常」(統計的逸脱+インシデント裏付け)を定義。LLM(GPT-4 Turbo)を検知器でなくメタ層に限定——(1) Monitor Configuration Infusion(シェープレット+インシデント DB と統一類似度で設定推奨)、(2) Practical Alert Generation(歴史的メトリクス-インシデントペアから LLM がレポート生成)、(3) LLM-Engineer-In-The-Loop(サービスエンジニアが低閾値でフィードバック、1 例のみ報告で 3 件の偽陽性を汎化解消)。**横断的知見**: サーベイ([[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models]])が整理する LLM 異常検知 3 方向は「検知精度の向上」に注力するが、MonitorAssistant は「何が検知に値するか」を問い直し、LLM を検知器でなくメタ層に限定する——これは「検知自体に LLM を使う」路線と「LLM で検知を支援する」路線の分岐を具体化した初の産業投入事例であり、「常時稼働には LLM が重い」制約の実践的回答。[[Minghua Ma]] は AIOpsLab・GenAI インシデント実証に続き 3 つ目のソースで責任著者として登場し、AIOps の評価(AIOpsLab)・実態(ICSE GenAI インシデント)・実用化(MonitorAssistant)を同一人物が三方から攻める構図。 2026-06-03: [[@2026__ICML__TelecomTS - A Multi-Modal Observability Dataset for Time Series and Language Analysis]](Feng+, [[Yale University]], ICML 2026, arXiv:2510.06063)を取り込み(21 ソース目)。ソース 1 + エンティティ 4([[TelecomTS]] / [[Yale University]] / [[Ali Maatouk]] / [[Rex Ying]])= 5 ページ作成、既存の概念 3([[時系列基盤モデル]] / [[異常検知]] / [[根本原因分析]])を更新。**本 wiki 初のオブザーバビリティデータセット論文で、TSFM が観測データに苦戦する問題を検知・RCA・Q&A の複数タスクで定量化**。Yale の研究室に構築した 5G ネットワークから 100 ms 解像度で 18 KPI を収集し、32,000 サンプル・11 異常タイプ・約 221 万 Q&A を提供。[[BOOM]](Datadog)が匿名化・正規化に留まるのに対し、非匿名化かつ絶対スケール情報を保持する点が最大の差別化。**核心的知見は 3 点**: (1) LLM(GPT-4.1・Claude 3.7 Sonnet)は観測データの正常な急変動を異常と誤判定し適合率 0.17–0.26 に陥る偽陽性バイアスを持つ、(2) 絶対スケール情報の除去が全アーキテクチャで RCA を大幅に劣化させる(Autoformer で +30.4 ポイント)——正規化がオブザーバビリティ特有の診断情報を破壊する、(3) [[Toto]] が観測データ特化の事前学習により RCA 精度 0.848・異常検知 F1 0.615 で他の TSFM を大幅に凌駕するが、スケールを明示的にエンコードする Mantis(NME 搭載)が異常検知 F1 0.800 で Toto を上回る。**横断的知見として、[[BOOM]]/[[Toto]] が「正規化で失われる情報」を指摘した議論を、TelecomTS がスケールアブレーション(Table 7)で初めて定量化した**。情報の量(削減: [[MetricSifter]])と質(スケール: TelecomTS)の両面が検知・RCA の前提条件であることが 3 ソースの突き合わせで見える。マルチモーダルモデル(Toto+Qwen-3-4B)は大半の Q&A で LLM 単体を上回るが、異常検知では Toto 単体に劣る——統合最適化の困難さ。 2026-06-03: [[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]](Yan+, [[Huazhong University of Science and Technology]]×[[University of Illinois Urbana-Champaign]]×[[Microsoft]], ICSE 2026, arXiv:2504.08865)を取り込み(20 ソース目)。ソース 1 + エンティティ 2([[Haoran Yan]] / [[Huazhong University of Science and Technology]])+ 概念 1([[インシデント管理]])= 4 ページ作成、既存のエンティティ 4([[Yinfang Chen]] / [[Minghua Ma]] / [[Tianyin Xu]] / [[Microsoft]])・概念 3([[AIOps]] / [[根本原因分析]] / [[障害緩和]])を更新。**本 wiki 初の「本番インシデントの実証研究」ソースで、AIOps クラスタに欠けていた「エージェントが実際に扱うべき GenAI インシデントの実態」を投入**。Microsoft の Azure OpenAI 等の GenAI クラウドサービスの本番インシデント 4 年分（2020-06〜2024-02）を分析し、GenAI 固有の症状（無効推論 14.5%・デプロイ失敗 35.7%・性能劣化 49.8%）・根本原因（インフラ 27.2%・設定 24.5%・コードバグ 21.5%・外部利用 14.1%・運用操作 12.7%）・緩和戦略（7 類）を分類体系化。**最大の横断的知見は 3 点**: (1) エージェント評価ベンチマーク（[[AIOpsLab]]/[[SREGym]]）が再現できる障害は本番の約半分で、外部利用+運用操作ミス（計 26.8%）の再現が課題、(2) 症状と根本原因が多対多でベンチの 1:1 構造より本番は探索空間が広い、(3) 自己回復が 19.7% を占めるが評価ベンチは「介入不要」シナリオを含まない。著者陣は AIOpsLab（MLSys '25）と大きく重なり、エージェント評価と本番インシデント実証を**同一チームが双方から攻める**構図が確定。 2026-06-03: [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models]](Zhang+, [[Peking University]]/[[Tsinghua University]]/[[University of Illinois Chicago]]/[[The Hong Kong University of Science and Technology (Guangzhou)]], ACM Computing Surveys 採録, arXiv:2507.12472, DOI:10.1145/3746635)を取り込み(19 ソース目)。ACM が Cloudflare ボット保護背後で WebFetch/curl とも 403 のため、**arXiv プレプリント版を原本**として fetch-paper-pdf.sh で `.raw/papers/arxiv-2507.12472.pdf`(35p)を取得、pdftotext で本文 §1–§8 を通読。ソース 1 + エンティティ 4 新規([[Ying Li]] / [[Philip S. Yu]] / [[University of Illinois Chicago]] / [[The Hong Kong University of Science and Technology (Guangzhou)]])+ 概念 1 新規([[異常検知]])= 6 ページ作成、既存のエンティティ 4([[Lingzhe Zhang]] / [[Tong Jia]] / [[Peking University]] / [[Tsinghua University]])・概念 6([[AIOps]] / [[根本原因分析]] / [[障害緩和]] / [[Fault Localization]] / [[障害予測]] / [[時系列基盤モデル]])を更新。**本 wiki 初の「フィールド全体の地図」(LLM4AIOps の包括的サーベイ)で、著者は既出の [[MicroRemed]] と同じ PKU グループ([[Lingzhe Zhang]]・[[Tong Jia]]・[[Ying Li]])**。最大の収穫は AIOps を切る **3 つ目の軸=工程フロー**(データ→タスク→手法→評価)が確定したこと——[[AIOpsLab]] の能力軸(検知/箇所特定/RCA/緩和)・[[Google]] の自律度軸(L0–L4)に、サーベイのタスク 3 段(Failure Perception → RCA → Assisted Remediation)が加わった。緩和の**自動化 5 段**(assisted questioning→mitigation solution→command recommendation→script generation→automatic execution)では vault の [[MicroRemed]] が Lv4・[[Stratus]] が Lv5 にちょうど位置し、サーベイが「Lv5 は実効性未検証」とした空白(カットオフ 2024-12)を 2025–2026 の一次ソースが [[Transactional No-Regression]] 付きで埋める時間的接続を確認。サーベイ自身が [[AIOpsLab]] を全ライフサイクルベンチの代表として参照しており、地図(サーベイ)と地点(一次ソース)が相互参照する構造。欠けていた概念 [[異常検知]] を新設(障害認知の中心タスク、「常時稼働には LLM が重い」制約が [[Minder]]/[[Pulse]] の非 LLM 設計理由と表裏)。**出典検査で arXiv v1 の数値不整合(abstract「183 本」対 本文/Fig.4「163 本」、除外数 222 対 232)を検出**——CSUR 採録版で修正の可能性ありと注記。なお本取り込みと並行して別セッションが [[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]] を 18 ソース目として ingest していたため(Pulse 取り込み時の ITBench と同型の並行採番)、本サーベイを 19 ソース目に採番し index を 134 ページ/19 ソースに reconcile(per-file lock で torn write は回避)。 2026-06-03: [[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]](Xiao+, [[Nanjing University]], ASPLOS '26, DOI:10.1145/3779212.3790163)を取り込み(17 ソース目)。ソース 1 + エンティティ 10([[Pulse]] / [[Nanjing University]] / [[Chen Tian]] / [[Qingkai Meng]] / [[Yibo Xiao]] / [[BlueField-3]] / [[NCCL]] / [[Aegis]] / [[Holmes]] / [[GreyHound]])+ 概念 1([[LLM学習モニタリング]])= 12 ページ作成、既存の概念 3([[Fault Localization]] / [[GPUクラスタ運用]] / [[LLM分散学習]])を更新。**ML systems モニタリングクラスタの一次論文 3 例目で、初の「トラフィック計測系」検知機構**。[[Minder]](秒単位のホストメトリクス)・[[MegaScale]](ハートビート)が取りこぼすオペレータ内部のマイクロ秒ギャップを、訓練コード/CCL を一切改変せず **NIC 上の RDMA トラフィック計測**だけで可視化する。核は (1)[[BlueField-3]] のマイクロプロセッサ上に計測を載せパケット処理のクリティカルパスから外す **3 層計測**(集約/計測/収集)で 2000 フロー/NIC・マイクロ秒粒度をオーバーヘッドほぼ 0 に、(2)NCCL/RDMA API の関数フックで得た期待ボリューム/ピアから QP ごとのレート曲線をオペレータ単位にセグメント化する **オペレータセグメンテーション**(リング/ツリー推定・並列化識別込み)、(3)細粒度データを全量上げず **実通信時間 / 通信ボリューム** の 2 指標で軽量にマシン単位の箇所特定。64 H200 GPU・12 シナリオで Pulse は 10 をマシン単位で特定(SOTA の [[Aegis]]/[[Holmes]]/[[GreyHound]] は 4・CPU 競合と MoE のエキスパート不均衡の 2 を通信異常と誤診)、適合率 >90%・再現率 100%・平均約 6 秒・訓練オーバーヘッド無視可能。**最大の横断的知見は、[[GPUクラスタ運用]] の未解決の問いだった「[[Minder]] がオーバーヘッドゆえ未展開としたマイクロ秒監視」に Pulse が別レイヤ(ホスト経路上 → NIC 経路外)で答えたこと**——「細粒度監視はオーバーヘッドを生む」という制約は計測の置き場所で外せると示した。ただし Pulse はノード間 RDMA 通信のみ可視でホストメトリクス(ECC/温度/NVLink)は見ず、Minder と置換でなく補完。検知機構の積層がハートビート→ホストメトリクス→トラフィックの 3 層に伸びたこと、訓練クラスタ内の箇所特定にも相対方式(Minder の類似度)対絶対方式(Pulse の実時間/ボリューム)の差があることを [[LLM分散学習]]/[[Fault Localization]] に追記。新概念 [[LLM学習モニタリング]] に検知信号・監視粒度・介入度の 3 軸と 4 系統(OP×侵入的/OP×非侵入的/sub-OP×非侵入的)を集約。 2026-06-03: [[@2025__ICML2025__ITBench - Evaluating AI Agents across Diverse Real-World IT Automation Tasks]](Jha+, [[IBM Research]]×[[University of Illinois Urbana-Champaign]], ICML 2025 / PMLR v267)を取り込み(16 ソース目)。これまで [[SREGym]]・[[Stratus]] の二次情報経由でしか参照できなかった **[[ITBench]] を一次論文として取り込み**。ソース 1 + エンティティ 1 新規([[Rohan Arora]])= 2 ページ作成、既存のエンティティ 5([[ITBench]] を一次論文ベースに全面改稿 / [[Saurabh Jha]] / [[IBM Research]] / [[University of Illinois Urbana-Champaign]] / [[AIOpsLab]] / [[CrewAI]])・概念 2([[SRE Benchmark]] / [[agentic SRE]])を更新。**最大の収穫はベンチ設計の 2 つの直交軸が一次資料で確定したこと**: (1) [[AIOpsLab]]・[[SREGym]] が SRE を深掘りする縦軸に対し、ITBench は SRE/CISO/FinOps の **ペルソナ横断**という別軸を取り、計 102 シナリオ(SRE 42・CISO 50・FinOps 10)で IT 運用全体をカバーする。(2) 報告される能力天井がベンチ間で桁違い([[AIOpsLab]] ~59%・[[SREGym]] ~6割・ITBench は GPT-4o の SRE 緩和 **11.43%**・Hard 緩和は全モデル 0%)で、分解採点対エンドツーエンド・オラクルの厳しさの差が天井を桁単位で動かす——ベンチ横断比較の正規化問題を一次数値で裏付け。さらに **トレースのアブレーション**(GPT-4o 診断 13.81%→9.52%・緩和 11.43%→2.86%)が [[agentic SRE]] の「テレメトリ選別が鍵」を「種類の有無」の制御変数として定量化、**トラジェクトリ分析**(Detoured/Covered Services)が「成功は障害伝播チェーンに探索を集中」を可観測化し AIOpsLab/SREGym の失敗モード観察と一致。診断オラクルは完全一致 → ITBench の **NTAM(Normalized Topology-Aware Metric)** → チェックリスト LLM 判定という進化の中段を一次資料で確認。ITBench と [[Stratus]] が同じ IBM チーム([[Saurabh Jha]]・[[Rohan Arora]]・Yu Deng・Noah Zheutlin・Bhavya Bhavya が重複)かつ同じ [[CrewAI]] 基盤という近接構図も確定。 2026-06-03(再取り込み): [[@2025__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]](Chen+, [[University of Illinois Urbana-Champaign]]×[[IBM Research]], NeurIPS 2025, arXiv:2506.02009)を **PDF 本文を参照して再取り込み**(既存エントリはポスター/アブストラクトのみ参照で本文未読だった)。エンティティ 2 新規([[IBM Research]] / [[CrewAI]])、[[Stratus]] / [[Transactional No-Regression]] / [[agentic SRE]] / [[障害緩和]] / [[Saurabh Jha]] / [[University of Illinois Urbana-Champaign]] / [[Tsinghua University]] を本文根拠で更新。**最大の成果は安全仕様 TNR の形式モデルが確定したこと**: 重大度 `µ(s)=w1|A|+w2|V|+w3|L|` の単調非増加(`µ(s)≤b`)を A-Lock(書き手排他)/Faithful Undo(`U(spost)=spre`)/Bounded Risk Window(`K=20`)の 3 仮定下で保証する **Alpern–Schneider safety property**(Lemma 3.1、帰納法で証明)であり、4 エージェント(αD/αG/αM/αU)を決定論的な状態機械で編成し、αU は状態リコンシリエーションを使うスタックベースのロールバックで実装([[CrewAI]] 基盤)。これで概念 [[Transactional No-Regression]] の「形式的定義未確認」の問いを解消。評価は AIOpsLab 69.2%(9/13)・ITBench 50.0%(9/18)で 2 位を 1.5X/5.4X、アブレーションで No retry 15.4%・Naïve retry w/o undo 23.1% と TNR の巻き戻しと再試行が緩和の鍵と裏取り(80% 超で 1 回以上の再試行)。重要な留保として、ITBench 18 問中 8 問は「注入された障害が Pod 再起動で消える」性質を悪用した Pod 再起動で解け、**undo エージェントの有無で成績が変わらない**——安全仕様(無回帰)と評価の誠実性(根本を直す)は直交するという横断的知見を [[Transactional No-Regression]]・[[障害緩和]] に追記。所属も本文で確定し旧版「所属未記載」注記を解消。 2026-06-03: [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]](Deng+, [[ByteDance]]/[[Tsinghua University]]/[[Harvard University]], NSDI '25)を取り込み(15 ソース目)。ソース 1 + エンティティ 6([[Minder]] / [[Yangtao Deng]] / [[Zhuo Jiang]] / [[Minlan Yu]] / [[Tsinghua University]] / [[Harvard University]])= 7 ページ作成、既存のエンティティ 1([[ByteDance]])・概念 4([[GPUクラスタ運用]] / [[Fault Localization]] / [[LLM分散学習]] / [[変化点検知]])を更新。**ML systems クラスタの一次論文 2 例目で、初の「訓練クラスタの信頼性運用(障害マシン検知)」軸**。[[MegaScale]](同じ ByteDance、NSDI '24)がアルゴリズム・システム協調設計で効率を、ハートビートベースの堅牢な訓練フレームワークで「死んだノード」の自動復旧を扱うのに対し、Minder は停止前の**監視メトリクスの異常パターン**を捉え、PCIe ダウングレードのような「止まらないが MFU を落とす」緩慢な障害まで障害マシン 1 台に局所化する。核は (1)3D 並列化が全マシンのメトリクスを秒単位で均質化する性質を逆手に取った **マシン単位の類似度**(他から最も外れた 1 台)、(2)異常の数分持続を見る **連続性**(閾値 4 分、ジッタ除去)、(3)メトリクスごとの **メトリクス別 LSTM-VAE** デノイジング(統合は相互干渉)、(4)決定木による **メトリクス優先順位付け**(PFC/CPU/GPU/NVLink 系が上位)。本番 1 年超、150 件の障害で 適合率 0.904・F1 0.893・平均 3.6 秒(手動比 99% 短縮・500×)、ベースラインの Mahalanobis Distance(0.788/0.777)を上回る。障害の全体像: タスクあたり 1 日 2 回、ハードウェア 55.8%(ECC 38.9%)・ソフトウェア 28.0%・ネットワーク 6.0%(表1)。横断的知見: 障害検知が同一組織でもハートビート系(MegaScale)とメトリクスパターン系(Minder)に分化し補完すること、訓練クラスタ診断と本番 AIOps は分散ビューで同型だが**信号源が真逆**(訓練=均質性からの逸脱、マイクロサービス=異種性の依存伝播)で Minder がクラウド診断手法の訓練転用不能を明言すること、変化点検知と Minder の連続性が「持続する逸脱対短命なノイズ」を時間軸で切り分ける裏表の関係であることを明記。 2026-06-03: [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]](Konishi+, [[SAKURA Internet]] Research Center, MLSys 2026 採録 / arXiv:2604.13600)を取り込み(14 ソース目)。ソース 1 + エンティティ 3([[Fumikazu Konishi]] / [[SAKURAONE]] / [[SONiC]])+ 概念 2([[オープンネットワーキング]] / [[GPUクラスタ運用]])= 6 ページ作成、既存のエンティティ 3([[Yuuki Tsubouchi]] / [[Hirofumi Tsuruta]] / [[SAKURA Internet]])・概念 2([[LLM分散学習]] / [[並列化戦略]])を更新。**vault 所有者 [[Yuuki Tsubouchi]] の共著・本 wiki 初の HPC/オープンネットワーキング一次論文**。これまでの ML systems クラスタ([[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]] / [[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]])がハイパースケール(1 万 GPU 級)の効率・並列化を扱うのに対し、SAKURAONE は **ミッドスケール(800 GPU)・単一テナント**の経験報告で、(1)SONiC + RoCEv2 のフルオープン 800 GbE で TOP500 HPL 49 位・トップ 100 唯一・NVIDIA Eos(InfiniBand)比で訓練完了時間 1.02–1.26× を達成しオープン Ethernet が InfiniBand 級効率に届くことを実証、(2)単一プロジェクトの LLM 開発のワークロード動態(小規模が件数 76.9%・大規模 17 ノード以上が GPU 時間 73.3% を支配、キャンセルが GPU 時間 73.5%、CPT→ファインチューニングのフェーズ遷移、3 ヶ月 21 件の障害の 42.9% が GPU 起因で大半がノード再起動で復旧)をテレメトリから定量化。横断的知見: MFU 35.9–41.2% はハイパースケール固有でなくミッドスケールでも再現すること、Reliability の「ハードウェア起因が優勢」が 800 GPU 規模でも成立すること、インターコネクトはプロプライエタリ前提でなくフルオープンでも SER を満たせること([[LLM分散学習]]/[[並列化戦略]] に追記)。 2026-06-03: [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]](Jiang+, [[ByteDance]]/[[Peking University]], NSDI '24)を取り込み(13 ソース目)。ソース 1 + エンティティ 6([[MegaScale]] / [[ByteDance]] / [[Megatron-LM]] / [[Ziheng Jiang]] / [[Xin Jin]] / [[Xin Liu]])= 7 ページ作成、既存の概念 2([[LLM分散学習]] / [[並列化戦略]])を seed→developing に更新。**ML systems クラスタの一次論文 1 例目**で、直前に入れた LLM 訓練サーベイ([[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]])のタクソノミを本番システムで裏取りする位置づけ。アルゴリズム・システム協調設計(並列 Transformer ブロック / SWA / LAMB + 各並列化次元固有の通信オーバーラップ)と詳細なオブザーバビリティ(CUDA イベントモニタのヒートマップ・3D 並列可視化)で、175B を 12,288 GPU・**55.2% MFU**(Megatron-LM 比 1.34×)。256 GPU でのアブレーションは 47.7%→65.3% で累計 +17.6%、最大寄与は 3D 並列の通信オーバーラップ(+6.2%)。安定性は堅牢な訓練フレームワーク(ハートビート→自己診断→退避→チェックポイント復旧)+ 2 段階チェックポイント(ホストメモリへ数秒で書き込み + 非同期 HDFS)で、数週間の本番ランで **100 回超の自動復旧**・障害の 90% 超を自動修復・有効訓練時間率 90% 超。横断的知見: サーベイの「数万 GPU で MFU 40% 前後」は宿命でなく協調設計で押し戻せる設計問題であること、訓練クラスタのストラグラー診断が本番サービス AIOps と同型の分散ビュー課題であることを 2 ソースの突き合わせで明記。 2026-06-03: [[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]](Duan+, [[Shanghai AI Laboratory]] ほか, arXiv:2407.20018 / Vicinagearth Vol.3 (2026), 42p)を取り込み(12 ソース目)。ソース 1 + エンティティ 3([[Shanghai AI Laboratory]] / [[Jiangfei Duan]] / [[Peng Sun]])+ 概念 3([[LLM分散学習]] / [[並列化戦略]] / [[Mixture-of-Experts]])= 7 ページ作成。**本 wiki 初の LLM 訓練インフラ・別ドメイン**で、これまでの AIOps/SRE/オブザーバビリティ/時系列クラスタとは独立した「ML systems(LLM を数万 GPU で訓練するシステム)」クラスタを新設。LLM 訓練の課題を **SER(Scalability/Efficiency/Reliability)** の 3 軸に整理し、インフラ(アクセラレータ/ネットワーク/ストレージ/スケジューリング)・並列化(ハイブリッド=データ/テンソル/パイプライン/シーケンス/エキスパート、自動、異種)・計算/メモリ/通信最適化・耐障害性の 4 層で数百の引用研究を体系分類。代表的な定量値: LLaMA3 は 16,384 H100 で MFU 38〜41%、54 日訓練で 466 回中断・障害の 78% がハードウェア起因。ZeRO はモデル状態を 16Φ→16Φ/N に削減。今後の方向性は光コンピューティング / 光ネットワーク(シリコンフォトニクス)。**既存クラスタとの接点**は §8.2 の異常検知(GPU ハートビート/DCGM 監視・ストラグラー検出)と §8.1 の障害分析で、運用オブザーバビリティ([[テレメトリ]]/[[Fault Localization]])と「異常検知/障害起因分析」の語彙を共有するが、対象は本番サービスでなく訓練クラスタのハードウェア健全性([[LLM分散学習]] 横断的知見に明記)。 2026-06-03: [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]([[Yuuki Tsubouchi]] の京都大学博士論文, 2025-03, 112p)を取り込み(11 ソース目)。ソース 1 + エンティティ 6([[HeteroTSDB]] / [[go-conntracer-bpf]] / [[Mackerel]] / [[Hatena]] / [[Kyoto University]] / [[Ryosuke Matsumoto]])+ 概念 3([[テレメトリ]] / [[時系列データベース]] / [[分散トレーシング]])= 10 ページ作成、既存の [[Yuuki Tsubouchi]] / [[特徴量削減]] / [[Fault Localization]] を更新。**vault 所有者自身の博士論文 2 例目**で、既取り込みの [[MetricSifter]](= 本論文 Chapter 5 = マイニング層)の足元を埋める。テレメトリを **計装 / ストレージ / マイニングの 3 層**で捉え、既発表 3 編(カーネル内フローバンドリング / HeteroTSDB / MetricSifter)を統合。これまで wiki の AIOps/SRE ソースはテレメトリを「読んで」診断するマイニング層に偏在していたが、本論文はその下層——パス指向データの低オーバーヘッド収集([[分散トレーシング]]: eBPF で同一宛先のフローを束ね CPU < 2.2%)と時間指向データの大規模保持([[時系列データベース]]: [[HeteroTSDB]] がメモリ/ディスク KVS を TTL 階層化、KairosDB 比 3.98 倍)——を埋める。中核の横断的知見: §6.2 設計指針「データ削減は文脈が豊富な両端(計装・マイニング)で行い、ストレージは文脈非依存に」が、[[特徴量削減]]([[MetricSifter]])と LLM エージェントのテレメトリ過剰消費病理([[Bits AI SRE]]/[[AIOpsLab]] §3.6)を貫く「情報を絞る」骨格を、収集の最上流まで一般化する。今後の方向性の「LLM 向け障害スナップショット生成」が [[根本原因分析]] のノイズ削減と同型で接続。 2026-06-03: [[@2024__IEEE Access__MetricSifter - Feature Reduction of Multivariate Time Series Data for Efficient Fault Localization in Cloud Applications]](MetricSifter, [[Yuuki Tsubouchi]]/[[Hirofumi Tsuruta]], IEEE Access 2024, DOI:10.1109/ACCESS.2024.3374334)を取り込み(10 ソース目)。ソース 1 + エンティティ 7([[Yuuki Tsubouchi]] / [[Hirofumi Tsuruta]] / [[SAKURA Internet]] / [[MetricSifter]] / [[Meltria]] / [[Sock Shop]] / [[PyRCA]])+ 概念 3([[Fault Localization]] / [[特徴量削減]] / [[変化点検知]])= 11 ページ作成、既存の [[根本原因分析]] / [[AIOps]] / [[Train-Ticket]] を更新。**本 wiki 初の vault 所有者自身の論文かつ LLM 以前の古典統計手法**。これまで 2025–2026 の LLM エージェント論文一色だった所に、2024 年の変化点検知 + KDE + 因果探索による障害箇所特定の前処理([[特徴量削減]])を追加。中核の横断的知見: MetricSifter が示す「無関係なメトリクス $M_C$ がノイズとして箇所特定を阻害する」課題が、後年 [[Bits AI SRE]]/[[AIOpsLab]] §3.6 が LLM エージェントで観測した「テレメトリ過剰消費で性能が落ちる」病理と同型——情報を絞ってから診断する、という骨格が手法世代を超えて連続する。 2026-06-03: [[@2026__arXiv__Falcon-X - A Time Series Foundation Model for Heterogeneous Multivariate Modeling]](Falcon-X, Ant International, arXiv:2605.27286)を取り込み(9 ソース目)。ソース 1 + エンティティ 5([[Falcon-X]] / [[Ant International]] / [[Chronos-2]] / [[GIFT-Eval]] / [[fev-bench]])+ 概念 1([[多変量時系列予測]])= 7 ページ作成、既存の [[時系列基盤モデル]] を更新。**TSFM 2 ソース目**で、[[Toto]]/[[BOOM]] に続く時系列予測軸。Toto が「観測データ特化」を強みにしたのに対し Falcon-X は「異種多変量の変量間モデリング」を主眼に据え、変量を生空間から潜在プロトタイプ空間へ分離。差分アテンションで正負(相乗的・拮抗的)の依存を表現し、[[Chronos-2]] のグループアテンションを意味的崩壊と批判。観測系データ(alibaba_cluster_trace・BOOMLET 等)も含むが SRE 下流タスクは未評価。新概念 [[多変量時系列予測]] に変量間方式(平坦化/因子分解/グループ/プロトタイプルーティング)の横断比較を集約。 2026-06-03: [[@2025__NeurIPS2025__This Time is Different - An Observability Perspective on Time Series Foundation Models]](Toto/BOOM, NeurIPS 2025, arXiv:2505.14766)を取り込み(8 ソース目)。ソース 1 + エンティティ 4([[Toto]] / [[BOOM]] / [[Ameet Talwalkar]] / [[Carnegie Mellon University]])+ 概念 1([[時系列基盤モデル]])= 6 ページ作成、既存の [[Datadog]] を更新。**wiki 初の純 ML(時系列予測)ソース**で、これまでの AIOps/SRE エージェント系列とは別軸。ただし出所は [[Datadog]] で 3 例目の同社ソース——SRE エージェント([[Bits AI SRE]])の足元にある**観測テレメトリの予測モデル**という形で接続する。観測データが一般時系列と統計的に異なる(KPSS・歪度・スペクトルエントロピー等が極端)ことを定量化し、専用アーキテクチャ(因果スケーリング・因子分解アテンション・Student-T 混合・頑健な損失)でゼロショット SOTA を達成。 2026-06-03: [[@2026__Datadog__Building Bits AI SRE - Autonomous Incident Investigation Agent]](Datadog blog, datadoghq.com)を取り込み(7 ソース目)。ソース 1 + エンティティ 2([[Datadog]] / [[Bits AI SRE]])+ 概念 1([[根本原因分析]])= 4 ページ作成、既存の概念 3([[agentic SRE]] / [[SRE Benchmark]] / [[AIOps]])を更新。**産業界 2 例目の一次情報**。[[Google]] が全ライフサイクル+自律緩和を語るのに対し Datadog は**調査・RCA 段に特化**(緩和は将来の専門エージェント統合に委ねる)。AIOps 4 段階タクソノミで唯一概念が未作成だった **RCA(第 3 段)** を [[根本原因分析]] として新設し、仮説駆動の調査・因果への注力・再帰的な深掘りを骨格に据えた。 2026-06-03: [[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]](Google SRE の AI-Ops ホワイトペーパー, sre.google)を取り込み(6 ソース目)。ソース 1 + 概念 1([[SRE AI Autonomy Levels]])+ エンティティ 5([[Google]] / [[AI Operator]] / [[Actus]] / [[Detectr]] / [[Model Context Protocol]])= 7 ページ作成、既存の概念 5([[agentic SRE]] / [[Transactional No-Regression]] / [[SRE Benchmark]] / [[AIOps]] / [[障害予測]])を更新。**本 wiki 初の産業界・本番運用一次情報**。学術ベンチ一色だった所に「自律度の段階化(L0–L4)」「Safety Trifecta / ガードレール」「Bronze/Silver/Gold 評価」という実運用の枠組みを追加。 2026-06-03: [[@2025__arXiv__MicroRemed - Benchmarking LLMs in Microservices Remediation]](arXiv:2511.01166, PKU/Alibaba)を取り込み(5 ソース目)。ソース 1 + エンティティ 9([[MicroRemed]] / [[ThinkRemed]] / [[Ansible]] / [[Train-Ticket]] / [[Online-Boutique]] / [[Lingzhe Zhang]] / [[Tong Jia]] / [[Peking University]] / [[Alibaba Group]])+ 概念 1([[障害緩和]])= 11 ページ作成、既存の概念 3([[AIOps]] / [[agentic SRE]] / [[SRE Benchmark]])を更新。AIOps 4 段階タクソノミの最上位 **緩和** を専門ベンチ化した初例として [[障害緩和]] 軸を新設。 2026-06-03: [[@2026__AAAI__PAGER - Proactive Monitoring Agent for Enterprise AI Assistant]](AAAI-26 デモ; CAIS 2026; DOI:10.1609/aaai.v40i48.42344)を取り込み(4 ソース目)。ソース 1 + エンティティ 4([[PAGER]] / [[Adobe Experience Platform]] / [[Adobe]] / [[Yunyao Li]])+ 概念 1([[障害予測]])= 6 ページ作成、[[AIOps]] を更新。これまで事後対応型一色だった wiki に **先回り型の障害予測**の軸を追加。 2026-06-03: [[@2025__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]](NeurIPS 2025 ポスター, arXiv:2506.02009)を取り込み(3 ソース目)。ソース 1 + 概念 1([[Transactional No-Regression]])+ エンティティ 1([[Saurabh Jha]])= 3 ページ作成、既存 7 ページ([[Stratus]] / [[agentic SRE]] / [[SRE Benchmark]] / [[AIOpsLab]] / [[ITBench]] / [[Yinfang Chen]] / [[Tianyin Xu]])を更新。これまで二次情報だった [[Stratus]] を一次ソース化。 ## Key Recent Facts - [[Pulse]]([[Nanjing University]], ASPLOS '26)は LLM 訓練の異常箇所特定を、訓練コード/CCL を改変せず NIC 上の RDMA トラフィック計測だけで行うトラフィック中心の監視システム。3 コンポーネント: NIC Agent([[BlueField-3]] DPA 上の 3 層計測=集約/計測/収集。φ=4KB ごとにイベント発火、24-bit QPN の 16M ダイレクトアドレステーブル、エポックプール + フローエイジング。N=2000・エポック 32us・ポーリング 1s で約 184MB、400Gbps で 256 中 16 DPA スレッドで足りる)/ Host Agent(NCCL/RDMA API フックで期待ボリューム・ピアを導出、リング/ツリーをアクティブなピアパターンで推定、Alg.1 で時間間隔 δ + ボリューム条件でオペレータ境界をセグメント化、決定木で DP/TP/PP/EP を識別)/ Analyzer(実通信時間=非ゼロレートのエポック和でギャップ除外→ストラグラー大、通信ボリューム=最少送信でフェイルストップノード、カスタム集団通信は rank 単位のレート + 完了状態)。 - [[Pulse]] の評価(8 マシン×8 H200=64 GPU・8 BlueField-3/機・400Gbps RoCEv2・Megatron・GPT-2/Mixtral 8×7B): 表3 で 12 中 10 をマシン単位で箇所特定(SOTA の [[Aegis]]/[[Holmes]]/[[GreyHound]] は 4 のみ、CPU 競合・MoE のエキスパート不均衡の 2 を通信異常と誤診)。57 実験で適合率 >90%・再現率 100%(偽陽性は計算のフェイルスローの CPU ボトルネックで 16%、他 0%)、平均診断遅延約 6 秒(SOTA より +0.7 秒、1 秒間隔のアップロードが律速)。オーバーヘッド: 2000 フロー/NIC でスループット劣化なし・レイテンシ 1.52us 対 1.53us・PCIe 0.3MB/s・イテレーション時間不変。オペレータセグメンテーション/並列化識別とも精度 100%(512-GPU SimAI 含む)。制約: ノード間 RDMA のみ(NVLink 監視外)、CollNet/NVLS 未対応、計算の箇所特定はマシン単位止まり。 - **解決(マイクロ秒監視のオーバーヘッド問題)**: [[GPUクラスタ運用]]/[[LLM学習モニタリング]] の未解決の問いだった「[[Minder]] が秒単位ゆえ取りこぼす高速伝播する障害を ms 単位の監視で拾いたいがオーバーヘッドで未展開(§6.6)」に [[Pulse]] が回答。計測をホスト経路上から **NIC 経路外**(パケット処理のクリティカルパス外の DPA)に移すことでマイクロ秒粒度をオーバーヘッドほぼ 0 に。ただし対象はネットワークトラフィックに限られホストメトリクス(ECC/温度)は Minder の領分のまま——両者は補完。 - **積層(検知機構が 3 層へ)**: ハートビート([[MegaScale]]、死/無応答)→ ホストメトリクスのパターン([[Minder]]、劣化)→ ネットワークトラフィック([[Pulse]]、オペレータ内部のギャップ)。検知信号も時間解像度(イベント/秒/マイクロ秒)も異なるレイヤの積層([[LLM分散学習]]/[[LLM学習モニタリング]])。 - **方式差(訓練クラスタ内の箇所特定)**: [[Minder]] はマシン単位の類似度(均質性からの逸脱=相対)、[[Pulse]] は実通信時間/ボリューム(絶対指標)で箇所特定。Pulse の絶対方式は均質性を前提にせず MoE の all-to-all(EP 負荷が不均質)でも rank 単位の指標でストラグラーを識別([[Fault Localization]])。 - **粒度律速**: OP レベルの監視(Aegis/Holmes/GreyHound)はストラグラーと正常な rank を同一の継続時間として弁別できずグループレベル止まり(ギャップは 32us で可視・1ms で不可視、図1)。非侵入的([[GreyHound]])でも OP レベルなら届かず、粒度問題は介入度を下げても解けない([[LLM学習モニタリング]] の 4 系統)。 - [[ITBench]]([[IBM Research]]×[[University of Illinois Urbana-Champaign]], ICML'25 / PMLR v267)は SRE(42)・CISO(50)・FinOps(10)の計 102 シナリオを実環境(OpenTelemetry Astronomy Shop + Grafana/Loki/Jaeger/Prometheus on K8s)でワンクリック評価する初の包括的 IT 自動化ベンチ。シナリオを `<M,E,T,D>` + POMDP で形式化、ベースラインのエージェントは [[CrewAI]] 上に ReAct/リフレクション/分解で構築。診断品質は NTAM(トポロジで根本原因/障害伝播チェーンを 0–1 採点)+ pass@1 + 部分採点 + 検証済みリーダーボード。102 中 11 のみ公開、残りは評価用に留保。 - [[ITBench]] の主要結果: SOTA の GPT-4o でも SRE 診断 pass@1 13.81%・緩和 11.43%、CISO O/A 24.74%、FinOps 異常検知 F1 0.6(異常検知の全体平均 0.35)・**緩和は全モデル 0%**。複雑度の上昇で pass@1 が単調低下、**Hard 緩和は SRE/FinOps とも全モデル 0%**。トレースを外すと GPT-4o の診断 13.81%→9.52%・緩和 11.43%→2.86%(オブザーバビリティの質が直接効く)。失敗分析で Detoured Services / Relative Covered Services を導入し、成功するトラジェクトリは正解の障害伝播チェーンへの迂回が少なくカバレッジが高いと定量化(図6)。 - **横断(ベンチ天井の桁違い)**: 同じ SRE 障害解決でも報告天井が [[AIOpsLab]] ~59%・[[SREGym]] ~6割・[[ITBench]] ~11%(SRE 緩和)と桁単位で食い違う。分解採点対エンドツーエンド・シナリオ難易度・オラクルの厳しさの差が原因で、「○○ベンチで何%」は単独では能力を表さずベンチ横断の正規化が前提([[SRE Benchmark]])。 - **横断(カバー範囲の軸の分岐)**: [[AIOpsLab]]・[[SREGym]] は SRE を深掘りする縦軸、[[ITBench]] は SRE/CISO/FinOps へのペルソナ横断という別軸。後者では SRE が 3 ペルソナの 1 つに相対化される([[SRE Benchmark]])。 - **近接(ベンチ作者×エージェント作者)**: [[ITBench]] と [[Stratus]] は同じ IBM チームの産物で、[[Saurabh Jha]]・[[Rohan Arora]]・Yu Deng・Noah Zheutlin・Bhavya Bhavya が両論文に重複し、ともに [[CrewAI]] を実装基盤に採る。評価の独立性の論点([[SRE Benchmark]] 未解決の問い)。 - [[Minder]]([[ByteDance]], NSDI '25)は本番 ML システムで 1 年超稼働する自動の障害マシン検知器。専用マシンにバックエンド常駐し、タスクごとに 8 分間隔で 15 分ぶんのホスト監視メトリクスを Data API から取得(訓練に非介入)。4 つの着想: マシン単位の類似度(デノイズ済みメトリクスのペアワイズ Euclidean 距離和=非類似度を正常スコア化、最大かつ閾値超を候補)/ 連続性(ストライド 1 で窓をずらし連続検出が 4 分超で確定)/ メトリクス別 LSTM-VAE(窓長 w=8・ストライド 1、hidden 4/latent 8/lstm_layer 1、再構成 MSE<0.0001)/ 決定木による優先順位付け(各メトリクスの最大 Z スコアをインスタンスに手動ラベルで学習、PFC/CPU/GPU/NVLink が上位)。検出後はドライバが IP ブロック・Kubernetes への Pod 提出で退避→チェックポイント復旧。 - [[Minder]] の評価(9 ヶ月・150 件の障害・4〜1500+ 台/最大 10,000 Ampere GPU・3D 並列化): precision/recall/F1 = **0.904/0.883/0.893**(ベースラインの Mahalanobis Distance は 0.788/0.767/0.777)、平均 **3.6 秒**でアラート(手動診断 30 分超〜数日に対し 99% 短縮・500×)。アブレーション: RAW(VAE なし)/CON(埋め込み連結)/INT(全メトリクス統合)より高い再現率・F1、連続性なしは誤報増、メトリクス多は再現率↑適合率↓・メトリクス少は外れ値検出力↓。弱点: GPU 実行エラー・PCIe ダウングレードは高速伝播で秒単位粒度では低い再現率、複数同時の障害(スイッチ再起動で 600 台中 32 台)は秒単位では区別困難だが ms 単位の監視を足せば検出可(図16)。 - **補完(MegaScale のハートビート対 Minder のメトリクスパターン)**: 同じ [[ByteDance]] で [[MegaScale]] の堅牢な訓練フレームワークはハートビート + 自己診断で「死んだ/無応答」ノードを退避、Minder は停止前の異常なメトリクスパターンで「劣化し始めた」緩慢な障害(PCIe ダウングレード等)を捉える。Reliability 軸が単一機構でなく検知粒度の異なるレイヤの積層であることを示す([[LLM分散学習]])。 - **真逆(訓練クラスタ対本番マイクロサービスの箇所特定信号)**: Minder はクラウドシステム診断([26,35,47,81])がマイクロサービスの依存パターンに基づくため、マシンが似たワークロードを持ち依存が消える分散訓練には転用できないと明言(§8)。マイクロサービスは異種性(依存の非対称)、訓練クラスタは均質性(類似からの逸脱)を異常信号にする——同じ第 2 段の箇所特定で前提が反転([[Fault Localization]])。 - **連続(障害の全体像のハードウェア優勢)**: Minder のハイパースケールの障害分布(ハードウェア 55.8%/ECC 38.9%、1 日 2 回)は SAKURAONE のミッドスケール(GPU 関連 42.9%、3 ヶ月 21 件)・サーベイの LLaMA3(78% ハードウェア)と「GPU/ハードウェア起因が最多」で連続。規模が上がると頻度も影響範囲(数百台がアイドル対ノード再起動)も跳ねるが骨格は不変([[GPUクラスタ運用]])。 - [[SAKURAONE]]([[SAKURA Internet]], MLSys 2026)は 100 ノード × 8 H100 = 800 GPU のオープン Ethernet AI–HPC クラスタ。ネットワークはレール最適化された leaf–spine の 800 GbE(2× 400 GbE)・RoCEv2、Edgecore AIS800-64O(Broadcom Tomahawk 5)上で [[SONiC]] を運用——TOP500 トップ 100 唯一のフルオープンなネットワーキングスタック。ベンチ: HPL 33.95 PFLOP/s(GPU あたり効率 78.3%)、HPCG 396.295 TFLOP/s、HPL-MxP(FP8)339.86 PFLOP/s。MLPerf GPT-3 175B(未検証)は 96 ノードで訓練完了時間 41.86 分・MFU 35.9%、NVIDIA Eos(DGX H100 SuperPOD, InfiniBand)比 1.02–1.26×。 - [[SAKURAONE]] のワークロード動態(2024 年 6 月–2025 年 3 月の日本語の医療 LLM プロジェクト、単一テナント排他運用): (1)小規模ジョブが件数 76.9% を占めるが GPU 時間は 1.8%、17 ノード以上は件数 3.3% で GPU 時間 73.3%(Jeon 2019/Kokolis 2025 と整合するロングテール)。(2)キャンセルが GPU 時間 73.5%(損失曲線を見た早期終了=適応的制御)、FAILED は GPU 時間 0.3%。(3)17–32 ノードのジョブ(CPT)は GPU 利用率の中央値 98.4%、1–2 ノードは 23.4%/17.7%。(4)1 月中旬–3 月の大規模 CPT → 2 月中旬以降の中規模ファインチューニングへフェーズ遷移。(5)3 ヶ月 21 件の障害のうち GPU 関連 42.9%・インターコネクトスイッチ 23.8%・NVLink/PCIe 19.0%、10/21 がノード再起動で復旧、MTTF/MTTR は記録精度不足で非報告。 - **裏取り(オープン Ethernet × ハイパースケール前提)**: [[MegaScale]]/サーベイが暗黙に高品質なインターコネクト(自社ネットワーク/InfiniBand 級)を前提とするのに対し、SAKURAONE は SONiC + RoCEv2 のフルオープン 800 GbE で Eos(InfiniBand)比で訓練完了時間 1.02–1.26× を達成。インターコネクトの選択自由度が Efficiency を致命的に損なわないことを実証する一方、ECN/PFC/NCCL のチャネルストライピングのレイヤ横断チューニングという運用負荷を代償に要する([[オープンネットワーキング]]、ECN min/max=2MB/10MB・マーキング確率 1% は表15)。 - **連続(MFU・Reliability の規模依存)**: MFU 38–41% はサーベイの LLaMA3(16K H100)・MegaScale の協調設計(55.2%)・SAKURAONE のミッドスケール(35.9–41.2%, 800 GPU)の 3 ソースで、GPU 数より並列化構成・通信隠蔽・インターコネクト品質が支配要因と確認([[LLM分散学習]])。Reliability の「ハードウェア起因が優勢」も LLaMA3 78%・SAKURAONE 42.9%(GPU)で連続し、規模を下げると件数も復旧コストも縮む(大半がノード再起動)。 - **同じ GPT-3 175B でも 3D 配分は組織で違う**: MegaScale は TP=8/PP=8、SAKURAONE は PP=16 を厚く取りノード数で TP=4→8・DP=4→8→6・VP=6 を可変化。だが「TP をノード内 NVLink・DP/PP をノード間」の通信局所性の原則は共通(SAKURAONE は PP の SendRecv が NCCL 時間の 91.2%、表10)。PP を厚くするとポッド間トポロジが通信比率に直接効き、96 ノードで MFU 35.9% へ低下([[並列化戦略]])。 - [[MegaScale]]([[ByteDance]]/[[Peking University]], NSDI '24)は 10,000 GPU 超で LLM を訓練する本番システム。2 原則 = アルゴリズム・システム協調設計 + 詳細なオブザーバビリティ。効率: 175B・12,288 GPU で 55.2% MFU([[Megatron-LM]] 比 1.34×、530B の弱スケーリングでは最大 +6.1% MFU)。アブレーション(256 GPU, 表3): ベースライン 47.7% → PTB+SWA(アルゴリズム)→ TP/PP/DP オーバーラップ(+6.2% で最大寄与)→ 効率的なオペレータ → その他 → LAMB(BS×3)で 65.3%(累計 +17.6%)。手法の柱: 並列 Transformer ブロック(アテンション/MLP 並列)・スライディングウィンドウアテンション(O(s·w))・LAMB(バッチ 4×、パイプラインバブル -87.5%)・各並列化次元固有の通信オーバーラップ(DP=all-gather プリフェッチ / TP・SP=FFN の Linear と融合し GEMM をチャンク化 / PP=送受信の分離)・集団通信の初期化 O(n²)→O(n)(TCPStore→Redis、2048 GPU で 1047s→5s 未満)・ネットワークチューニング(Tomahawk 4 CLOS、ECMP 衝突低減、Swift+DCQCN)。 - [[MegaScale]] の安定性(本番ラン、数週間・10,000 GPU 超・数千億パラメータ・数兆トークン): 堅牢な訓練フレームワークがドライバ–エグゼキュータのハートビートで異常検知→自己診断テスト→障害ノードを Kubernetes で退避→最新チェックポイント復旧。**100 回超の再起動をしつつ損失が収束**、障害の 90% 超を自動検知・特定・復旧、検知+診断が平均 10 分未満・追いつき 15 分以内で有効訓練時間率 90% 超。2 段階チェックポイント(GPU→ホストメモリへ数秒、背景で HDFS へ非同期)+ データ並列グループ内で状態を 1 ワーカーが読みブロードキャストし復旧帯域を緩和。 - **裏取り(サーベイ × 本番システム)**: サーベイ([[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]])が LLaMA3 で MFU 38〜41% と報告するのに対し、MegaScale は同規模帯で 55.2% を実測。SER の Efficiency 軸は「数万 GPU では 40% 前後に落ちる宿命」ではなく **アルゴリズム・システム協調設計でどこまで押し戻せるかという設計問題**であることが 2 ソースで確定([[LLM分散学習]]/[[並列化戦略]] 横断的知見)。サーベイが体系化する 4 つの並列化次元・通信局所性(TP はノード内 / DP・PP はノード間)を MegaScale も同じ理由で本番採用。 - **同型(訓練クラスタ診断対本番サービス AIOps)**: MegaScale §5 は単一 GPU の GEMM マイクロベンチマークではストラグラーを検出できず、CUDA イベントのヒートマップと DP/PP/TP の分散タイムライントレースで初めて根本原因を特定。これは [[分散トレーシング]]/[[Fault Localization]] が本番マイクロサービスで論じる「単一ノード視点では見えず分散ビューの相関で起因特定」と同型——対象(訓練ハードウェア対サービス)は違えど診断方法論を共有する。 - [[Falcon-X]]([[Ant International]], arXiv:2605.27286, 2026)は 591M のエンコーダのみの [[時系列基盤モデル]]。異種多変量を生空間から固定 C 次元の潜在プロトタイプ空間へ分離する点が中核。3 機構: Unified Prototype Diff-Attention(正負プロトタイプ Kpos/Kneg の差分アテンションで符号付きの依存を表現、複雑度を O(M²)→O(M·C) に線形化)/ Latent Entity Attention(統一空間で大域的な変量間相互作用、ゼロショット転移)/ Variate Reassembly Router(要求と分配 + ゲート付き残差で物理次元へ再構成)。[[GIFT-Eval]] で 0.666 MASE/0.453 CRPS の全体最高(Toto-2.0-FT 比 +1.9% MASE、Timer-S1 比 +3.9% MASE)。長期ホライズンで優位拡大(長期 0.70 MASE 対 Chronos-2 0.76)。[[fev-bench]] では共変量を使う [[Chronos-2]](0.645)に僅差で次点(0.652、内生変数のみ)。59M→591M でニューラルスケーリング則に従う。アブレーションで Kneg 除去が最大の性能低下=負のアフィニティが必須。 - **対比([[Toto]] 対 [[Falcon-X]] の強みの置き方)**: Toto はデコーダのみ(151M)で「観測データ特化」(因果スケーリング・因子分解アテンション・Student-T 混合)を強みにする。Falcon-X はエンコーダのみ(591M)で「異種多変量の変量間モデリング」(潜在プロトタイプ + 符号付き依存)を主眼に据える。両者とも単変量 TSFM の限界を出発点にするが、Toto は事前学習データの分布(観測テレメトリ 43%)、Falcon-X はアーキテクチャ(プロトタイプ整列)で差別化。詳細は [[多変量時系列予測]]。 - **収斂(ベンチマーク相互参照)**: Falcon-X が評価に使う [[fev-bench]] は、Datadog の [[BOOM]] の部分集合 BOOMLET(1 分以上の周波数の観測系列)を内包。Datadog が出した観測ベンチマークが第三者(Ant International)のモデル評価に組み込まれ始めた。[[GIFT-Eval]]・MASE・CRPS が TSFM 評価の共通軸として両ソースで定着。 ゼロショット時系列予測基盤モデル([[時系列基盤モデル]])。デコーダのみ + 4 つの専用要素(パッチベースの因果インスタンス正規化 / 比例的因子分解アテンション(時間:変量=11:1)/ Student-T 混合ヘッド / 複合的な頑健損失)。事前学習 2.36 兆点(43% が Datadog の匿名観測メトリクス、主要 TSFM の4〜10倍)。ベンチマーク [[BOOM]] で CRPS が次点(Moirai-Base)比12.4%・MASE 13.1% 改善、GIFT-Eval(Rank 5.495)・LSF でもゼロショット SOTA。重み/コード/データを Apache 2.0 公開。 - [[BOOM]] は実運用テレメトリのみの観測時系列ベンチマーク(2,807系列・約3.5億点・系列あたり変量の中央値60)。本番(Toto 訓練)とステージング(BOOM 評価)を分離し汚染を排除。§4.3 で ACF/ARCH-LM/スペクトルエントロピー/KPSS/フラットスポット/歪度の6統計が GIFT-Eval・LSF より極端と定量化——観測データは非定常・不規則・裾が重い。 - **接続(Datadog 3 例目・足元の予測層)**: 既存 2 ソースは [[Datadog]] の自律 SRE エージェント [[Bits AI SRE]](調査・RCA)だったが、本ソースはその下の**観測テレメトリを予測するモデル層**。両者とも「Datadog 保有の本番テレメトリの規模」が強みの源泉(Bits AI SRE は調査の文脈、Toto は事前学習コーパスの規模)。観測データの予測精度向上は下流の異常検知・[[障害予測]]・キャパシティ計画に効きうるが、本論文は予測精度のみ評価し下流 SRE タスクへの寄与は未検証。 - **対比(指標文化)**: AIOps/SRE 系ソースが TTR/MTTM やタスク正答率で語るのに対し、Toto は MASE/CRPS/Rank という時系列予測の標準指標で SOTA を主張。同じ Datadog でも製品ブログ([[Bits AI SRE]])と査読論文(Toto)で立証の作法が異なる。 - [[Bits AI SRE]]([[Datadog]] ブログ)は本番インシデントを **仮説駆動**で調査して RCA を生成する自律エージェント。4 段ループ(アラート→コンテキスト収集→ライブテレメトリで仮説検証→再定式化→RCA)+ 因果関係への注力(初期版の 12+ ツール呼び出しによるコンテキスト過負荷を回避)+ 再帰的な深さ(下位仮説への分解で深掘り)。TTR を最大 95% 削減と主張。多層の根本原因の例: CrashLoopBackOff → OOM → 大きな Kafka ペイロード → 非効率なパース。評価は数百件の実本番インシデントのアーカイブ済みテレメトリを再生し LLM 判定で合否を採点(人間整合)。 - **符合(産業の評価機構)**: Datadog の「実インシデント再生 + LLM 判定」は [[Google]] の Continuous Nightly Evals + LLM-as-a-Judge と同骨格。産業 2 例が「合成された障害でなく過去の実インシデントを再生し LLM 判定で人間整合の合否を出す」評価に収束([[SRE Benchmark]])。 - **分化(産業実装のカバーする段階)**: 産業一次情報が 2 例に増え、注力する段階が分かれた。[[Google]] の [[AI Operator]] は検知→緩和→アクチュエーションまで踏み込み L2/L3 の自律緩和を主張、[[Datadog]] の [[Bits AI SRE]] は調査・RCA 段に特化し緩和は将来統合。AIOps 4 段階の各段が専門エージェント/ベンチに分化([[AIOps]]・[[根本原因分析]])。 - **緊張関係の継続**: Datadog の TTR 最大 95% 減・Google の MTTM 削減はいずれも本番の運用指標で、学術ベンチのタスク正答率(最高 6 割前後)とは別の量を測り直接比較できない。産業 2 例目が出ても能力天井対本番実績のギャップは埋まらず([[agentic SRE]] の矛盾)。 - [[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]](著者 Papapanagiotou ら, [[Google]])は本番運用への AI 導入を **[[SRE AI Autonomy Levels]](L0–L4)** で統治する産業ホワイトペーパー。5 軸(Monitor/Investigate/Mitigate/Actuate/Self-Direct)の自動化度でレベルを定義し、昇格を実証された信頼性に紐づける。推論([[AI Operator]], L2/L3 稼働)とアクチュエーション([[Actus]]: ドライラン・"Red Button")を分離し安全制御をモデル進化から独立させる。評価は Bronze/Silver/Gold の品質階層 + Continuous Nightly Evals + LLM-as-a-Judge。[[Detectr]] はユーザフィードバックから障害を検知、MCP([[Model Context Protocol]])で本番ツールを標準接続。実績: InvD で MTTM 44% 減・ML 異常検知で検出が 195% 増・Incident Hypothesis で MTTM 10% 減。 - **緊張関係(産業対学術)**: Google は L2/L3 の自律緩和を Cloud/Ads/YouTube/Search で**本番稼働**と主張するが、[[SREGym]]・[[AIOpsLab]] はフロンティアモデルでも緩和が最高 6 割前後・5〜20 ステップで頭打ちと報告。軽微インシデント限定+重厚なガードレールという運用設計の差か、自律度対タスク正答率という指標の差か。[[agentic SRE]] に contradiction callout を設置。 - **符合(安全工学)**: Google のドライラン/Red Button/[[Actus]] は、[[Stratus]] が形式化した安全仕様 [[Transactional No-Regression]] の産業実装に相当。安全に試して止める/巻き戻すことが、産業・学術の双方で自律度を上げる前提。 - **符合(評価)**: Google の LLM-as-a-Judge(自動操作を Golden Data と比較)は [[SREGym]] のチェックリストベースの LLM-as-a-judge と同機構。オラクルが完全一致 → トポロジ考慮 → LLM 判定と進化する流れが産業の継続的評価でも再現。 - [[MicroRemed]](arXiv:2511.01166, PKU/Alibaba)は **エンドツーエンドのマイクロサービス修復(E2E-MR)** を測る初のベンチマーク。診断レポートから LLM に実行可能な [[Ansible]] プレイブックを直接生成させ、実環境で実行して回復を検証する閉ループ。7 つの障害種別 × 3 システム([[Train-Ticket]]・[[Online-Boutique]]・Simple-Micro)で 421 の障害–復旧ペア。参照手法は SoloGen(ワンショット)と [[ThinkRemed]](4 エージェントのマルチエージェント)。9 LLM の評価で最強 Qwen3-Plus でも最も容易なレベルで 50% 未満。 - [[ThinkRemed]] のアブレーション: リフレクション(除去で平均 -7.16%)が probe エージェント(除去で -1.57%)より緩和精度への寄与が大きく、過剰なプロービングはノイズで精度を下げる場合がある。「反復と反省」が緩和性能の源泉という像が [[Stratus]](巻き戻しと再試行 / TNR)・[[SREGym]] と独立に一致。 - 軸の追加: AIOps の 4 段階タクソノミ(検知→箇所特定→RCA→**緩和**)で最上位の緩和を、AIOpsLab/SREGym は全体評価の 1 要素に置くのに対し、MicroRemed は緩和だけを切り出し専門ベンチ化([[障害緩和]] 軸)。カオス注入([[ChaosMesh]])を緩和評価に積極採用する点で SREGym(RCA のためカオスを避ける)と立場が分岐。 - [[PAGER]](AAAI-26 デモ, Adobe)は [[Adobe Experience Platform]] 向けの **先回り型**の障害予測エージェント。取り込み→セグメンテーション→ジャーニーの段階間ジョブの時間的重複を 2 つのランダムフォレストで予測(F1 67.8 / 57.5)し、Shapley+LLM で自然言語説明、会話 UI でサポートエンジニアを支援。予測本体は古典 ML、LLM は説明・NL2SQL・RAG・対話のインターフェース層に限定。 - 軸の追加: 既存 wiki の [[AIOps]]/[[agentic SRE]] は検知→箇所特定→RCA→緩和の **事後対応型**(障害発生後)ライフサイクル一色だった。PAGER はその手前に [[障害予測]](障害発生前)を置き、RCACopilot・ReAct を「事後対応型」と明示批判。事後対応型↔先回り型の対比が新しい横断軸。 - [[Stratus]](STRATUS, NeurIPS'25)は障害の検知/診断/緩和の専門エージェントを **状態機械**で編成した自律 SRE のマルチエージェントシステム。安全仕様 [[Transactional No-Regression]] (TNR) を形式化し、[[AIOpsLab]]・[[ITBench]] の緩和成功率で SOTA を各種モデルで**少なくとも 1.5 倍**上回ると主張。著者は [[Yinfang Chen]](第一)〜[[Tianyin Xu]](最終)の 10 名で、[[Saurabh Jha]]([[ITBench]] 主導著者)を含む。 - 符合: SREGym が観測した「STRATUS(Sonnet-4.6)が最強なのは巻き戻しと再試行ゆえ」は、一次論文の安全仕様 [[Transactional No-Regression]] と整合(ベンチ観測とエージェント設計原理の一致)。 - [[AIOpsLab]] は AIOps エージェント評価の包括的フレームワーク。検知/箇所特定/RCA/緩和の 4 段階タクソノミ。評価: 48 問題・6 エージェント、Flash 59.32%(最高)、自己修復は 5〜20 ステップで頭打ち。 - 矛盾検出(未解決): SREGym 由来の「AIOpsLab は ReAct ループを要求」は一次論文と食い違う([[AIOpsLab]] に contradiction callout)。 ## Recent Changes - エンティティ新設: [[Pulse]] / [[Nanjing University]] / [[Chen Tian]] / [[Qingkai Meng]] / [[Yibo Xiao]] / [[BlueField-3]] / [[NCCL]] / [[Aegis]] / [[Holmes]] / [[GreyHound]]([[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]] 由来)。 - 概念新設: [[LLM学習モニタリング]](訓練中の異常の実行時検知・局所化。検知信号=ハートビート/ホストメトリクス/トラフィック・監視粒度=OP/sub-OP・介入度の 3 軸、OP×侵入的/OP×非侵入的/sub-OP×非侵入的 の 4 系統を集約)。 - 概念充填: [[Fault Localization]](横断的知見に「訓練クラスタ内でも相対的な類似度対絶対的なメトリクスの方式差」「箇所特定の精度は監視粒度で律速され OP レベルではストラグラーに届かない」、未解決の問いに相対/絶対方式の統合と粒度律速の一般化を追記)、[[GPUクラスタ運用]](「細粒度監視のオーバーヘッド制約は計測の置き場所で外せる」を追記、Minder の ms 監視問題を Pulse が部分回答として未解決の問いを更新)、[[LLM分散学習]](検知機構の積層がハートビート→ホストメトリクス→トラフィックの 3 層に伸びたことを横断的知見に追記)。 - エンティティ新設: [[Rohan Arora]](ITBench の同等貢献の筆頭リード兼 STRATUS 共著者)。エンティティ更新: [[ITBench]](二次情報ベースから一次論文ベースに全面改稿)/ [[Saurabh Jha]](first_mentioned を ITBench 一次論文へ)/ [[IBM Research]] / [[University of Illinois Urbana-Champaign]] / [[AIOpsLab]] / [[CrewAI]](いずれも ITBench 一次論文の根拠を追記)。 - 概念充填: [[SRE Benchmark]](横断的知見に「カバー範囲の軸の分岐(SRE 深掘り対ペルソナ横断)」「報告天井がベンチ間で桁違い」「観測データ有無の定量裏付け」、オラクルの進化に NTAM 一次根拠を追記)、[[agentic SRE]](失敗モードに ITBench の Detoured/Covered Services を、テレメトリ選別にトレースのアブレーションを追記)。 - エンティティ新設: [[Minder]] / [[Yangtao Deng]] / [[Zhuo Jiang]] / [[Minlan Yu]] / [[Tsinghua University]] / [[Harvard University]]([[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]] 由来)。エンティティ更新: [[ByteDance]](Minder・訓練クラスタの信頼性運用・高速ネットワークチームを追記)。 - 概念充填: [[GPUクラスタ運用]](横断的知見のプレースホルダを解消し「障害の全体像は規模で頻度/優勢型が動くがハードウェア優勢は両端で成立」「規模がノード再起動運用を破綻させ先回り型検出を必須化する閾値」を追記)、[[Fault Localization]](「箇所特定の単位と依存構造の有無が対象ドメインで真逆=訓練の均質性対マイクロサービスの異種性」「箇所特定止まりで RCA は別段という分離は対象を越え共通」を追記)、[[LLM分散学習]](「Reliability の検知機構はハートビート系とメトリクスパターン系に分化・補完」「訓練診断⇔本番 AIOps は同型だが信号源が真逆」を追記、訓練の異常検知対 AIOps の問いに Minder の部分回答)、[[変化点検知]](横断的知見のプレースホルダを解消し「持続する逸脱対短命なノイズの弁別が変化点検知と Minder の連続性で裏表」を追記)。 - エンティティ新設: [[SAKURAONE]] / [[SONiC]] / [[Fumikazu Konishi]]([[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]] 由来)。エンティティ更新: [[Yuuki Tsubouchi]]・[[Hirofumi Tsuruta]]・[[SAKURA Internet]](SAKURAONE 共著・開発運用を追記)。 - 概念新設: [[オープンネットワーキング]](SONiC/SAI/RoCEv2 のベンダー中立なファブリック。InfiniBand 代替の条件とレイヤ横断チューニングの代償)/ [[GPUクラスタ運用]](ワークロード動態=ジョブ分布・キャンセル・フェーズ遷移・障害の全体像)。 - 概念充填: [[LLM分散学習]](横断的知見に「MFU 38–41% はミッドスケールでも再現」「ハードウェア起因の優勢は 800 GPU でも成立」「インターコネクトはオープン Ethernet でも SER を満たす」を追記)、[[並列化戦略]](「同じ 175B でも 3D 配分は組織で違うが通信局所性は共通」「PP を厚くするとポッド間トポロジが通信比率に直結」を追記)。 - エンティティ新設: [[MegaScale]] / [[ByteDance]] / [[Megatron-LM]] / [[Ziheng Jiang]] / [[Xin Jin]] / [[Xin Liu]](ML systems クラスタ初の一次論文 [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]] 由来)。 - 概念充填: [[LLM分散学習]](横断的知見に「MFU 40% は宿命でなく協調設計の問題」「Reliability=100 回超の自動復旧の具体形」「訓練クラスタ診断 ⇔ 本番 AIOps の分散ビューの同型性」を追記、status seed→developing)、[[並列化戦略]](横断的知見のプレースホルダを解消し「タクソノミ対本番構成」「パイプラインバブルはバッチサイズでも削減」「通信オーバーラップは並列化次元ごとに固有設計」を追記、status seed→developing)。 - 概念新設: [[LLM分散学習]](SER の 3 軸・4 層分類。訓練インフラの異常検知/障害分析と運用オブザーバビリティの語彙共有を横断的知見化)/ [[並列化戦略]](データ/テンソル/パイプライン/シーケンス/エキスパートのハイブリッド・自動・異種)/ [[Mixture-of-Experts]](MoE。エキスパート並列のスパースな活性化/通信/負荷分散)。**AIOps/SRE/時系列とは独立した ML systems クラスタを新設**。 - エンティティ新設: [[Shanghai AI Laboratory]] / [[Jiangfei Duan]] / [[Peng Sun]]。 - 概念新設: [[テレメトリ]](テレメトリの 3 層=計装/ストレージ/マイニングと時間/パス指向データ。AIOps 群が偏在するマイニング層の足元を埋める)/ [[時系列データベース]](TSDB。TSDA 対 TSDBMS・階層化・インデックスのトレードオフ)/ [[分散トレーシング]](ネットワークコールグラフ。ソケットベース手法の 4 系統)。 - 概念充填: [[特徴量削減]](§6.2「データ削減は文脈が豊富な両端で」の設計原理への昇華を横断的知見に追記)、[[Fault Localization]](博士論文のマイニング層を出典に追記)。 - エンティティ新設: [[HeteroTSDB]] / [[go-conntracer-bpf]] / [[Mackerel]] / [[Hatena]] / [[Kyoto University]] / [[Ryosuke Matsumoto]]。エンティティ更新: [[Yuuki Tsubouchi]](博士論文・HeteroTSDB/go-conntracer-bpf・Hatena/Kyoto University を追記、博士号取得年の出典差異を note callout 化、status seed→developing)。 - 概念新設: [[Fault Localization]](AIOps 4 段階の第 2 段。統計手法対 LLM エージェントの対比、ノイズメトリクス削減課題の通底を集約)/ [[特徴量削減]](正常性/冗長性の削減、過剰削減と過少削減のトレードオフ)/ [[変化点検知]](異常検知との区別、正常窓に非依存)。 - 概念充填: [[根本原因分析]](RCA 前段「箇所特定 + 特徴量削減」の統計手法の系譜、情報を絞ってから因果を辿る骨格の世代連続性)、[[AIOps]](LLM 以前の統計 AIOps と LLM エージェント AIOps の連続性)。 - エンティティ新設: [[Yuuki Tsubouchi]](vault 所有者)/ [[Hirofumi Tsuruta]] / [[SAKURA Internet]] / [[MetricSifter]] / [[Meltria]] / [[Sock Shop]] / [[PyRCA]]。エンティティ更新: [[Train-Ticket]](MetricSifter の実証研究での利用を追記)。 - 概念新設: [[多変量時系列予測]](変量間モデリング。TSFM の変量間方式=平坦化/因子分解/グループ/プロトタイプルーティングを横断集約。符号付き依存・観測系の高次元多変量・ベンチマーク相互参照を横断的知見化)。 - 概念充填: [[時系列基盤モデル]](横断的知見に多変量化の主戦場化・観測データへの収斂・エンコーダ対デコーダの分岐・MASE/CRPS 標準化。未解決の問いにエンコーダ/デコーダ比較・多変量利得対観測特化利得の独立性)。 - エンティティ新設: [[Falcon-X]] / [[Ant International]] / [[Chronos-2]] / [[GIFT-Eval]] / [[fev-bench]]。 - 概念新設: [[時系列基盤モデル]](TSFM。観測データは統計的に異なり専用設計を要する。wiki 初の純 ML ソース)。 - エンティティ新設: [[Toto]] / [[BOOM]] / [[Ameet Talwalkar]] / [[Carnegie Mellon University]]。 - エンティティ更新: [[Datadog]](AI Research 部門・Toto/BOOM・CMU 共同研究を追記。status seed→developing)。 - 概念新設: [[根本原因分析]](RCA。AIOps 4 段階の第 3 段。仮説駆動の調査を骨格に、因果への注力・再帰的な深さ・「情報を取りすぎる」病理の産業回避を集約)。 - エンティティ新設: [[Datadog]] / [[Bits AI SRE]](産業界 2 例目、調査・RCA 特化)。 - 概念充填: [[agentic SRE]](産業 2 例のカバーする段階の分化・運用指標の比較不能性)、[[SRE Benchmark]](実インシデント再生+LLM 判定への産業収束)、[[AIOps]](4 段階の各段の専門エージェント分化)。 - 概念新設: [[SRE AI Autonomy Levels]](L0–L4 の自律度ガバナンス。学術の能力軸に直交する権限委譲軸)。 - エンティティ新設: [[Google]] / [[AI Operator]] / [[Actus]] / [[Detectr]] / [[Model Context Protocol]]。 - 概念充填: [[agentic SRE]](産業対学術の指標差 + contradiction callout)、[[Transactional No-Regression]](Actus = TNR の産業実装)、[[SRE Benchmark]](LLM-as-a-Judge の産業合流・継続的評価・Bronze/Silver/Gold)、[[AIOps]](自律度ガバナンス軸・検知モダリティの拡張)、[[障害予測]](予測/早期検知/事前検証の 3 経路)。 - 概念新設: [[障害緩和]](ソフトウェア修復 / 緩和。AIOps 4 段階の最上位)。 - エンティティ新設: [[MicroRemed]] / [[ThinkRemed]] / [[Ansible]] / [[Train-Ticket]] / [[Online-Boutique]] / [[Lingzhe Zhang]] / [[Tong Jia]] / [[Peking University]] / [[Alibaba Group]]。 - 概念充填: [[AIOps]](緩和の専門ベンチ化)、[[agentic SRE]](反復と反省・4 エージェントの役割分割・過剰なプロービングの害)、[[SRE Benchmark]](緩和の専門ベンチ・カオス注入の立場分岐・状態ベースの検証)。 - 概念新設: [[障害予測]](先回り型の障害予測。事後対応型 AIOps の対極)。 - エンティティ新設: [[PAGER]] / [[Adobe Experience Platform]] / [[Adobe]] / [[Yunyao Li]]。 - 概念充填: [[AIOps]](横断的知見に「事後対応型ライフサイクルの手前の先回り型予測」、未解決の問いに事後対応型↔先回り型の統合)。 - 概念新設: [[Transactional No-Regression]](agentic SRE の安全仕様 TNR)。 - 概念充填: [[agentic SRE]](「安全な探索」が緩和性能を押し上げる)、[[SRE Benchmark]](複数ベンチ横断評価の標準化・評価独立性の問い)。 - エンティティ新設: [[Saurabh Jha]](ITBench 主導著者かつ STRATUS 共著者。ベンチ作者×エージェント作者の近接)。 - [[Stratus]] を二次情報(SREGym 参照)から一次ソース([[@2025__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]])に格上げ。 ## Active Threads - [[オープンネットワーキング]] は [[SAKURAONE]] 1 ソースで seed(横断的知見が空)。SONiC/RoCEv2/EVPN の一次研究(DCQCN・RoCE at scale・Rail-only・HammingMesh 等、SAKURAONE の関連研究が引く)を取り込み、オープン Ethernet が InfiniBand を代替する条件と輻輳制御のチューニングの横断的知見を立てる。`structures/Network - MOC` と接続済み。 - [[GPUクラスタ運用]] は [[SAKURAONE]] 1 ソースで seed。論文自身が Jeon 2019(USENIX ATC)・Kokolis 2025(HPCA)・[[MegaScale]] と突き合わせるロングテール/キャンセル/障害分布を、これら一次ソースを取り込んで横断的知見化する。とくにミッドスケール(100–1,000 GPU)単一テナント対ハイパースケールのマルチテナントの連続/不連続を厚くする。`structures/HPC - MOC`・`分散深層学習 - MOC` と接続済み。 - [[SAKURAONE]] のチェックポイントベースのプリエンプション(§8.5)・伸縮的な再割り当て(§8.4)・制御されたマルチテナンシー(§8.6)は提案に留まり未実装。GPU クラスタスケジューラの一次論文(Tiresias/Themis/CASSINI、SAKURAONE が引く)を取り込み、フェーズ遷移するワークロードのスケジューリングの横断的知見を立てる。 - [[Minder]] のマシン単位の類似度は 3D 並列化による負荷均質化を前提とする。負荷が不均質になる構成([[Mixture-of-Experts]] のエキスパート並列・異種並列)や推論/ファインチューニング(§7 で一般化を主張するが未実証)で均質性に基づく類似度が成立するかを示す後続ソースを探す([[LLM分散学習]] 未解決の問い)。[[Pulse]] が部分回答: 絶対指標(実時間/ボリューム)方式は MoE の all-to-all(EP 負荷が不均質)でも rank 単位でストラグラーを識別できると示す。相対(類似度)対絶対の優劣を不均質な構成で直接比較する後続が要る。 - [[Pulse]] はノード間 RDMA 通信のみ可視で NVLink 等のスケールアップネットワーク・ノード内の計算ストラグラーは監視外(計算の箇所特定はマシン単位止まり)。§9 の今後の研究の「eBPF 的な GPU カーネルプロファイリング + ノード内リンクカウンタ」でノード内まで延ばす後続研究や、Pulse のネットワーク視点と [[Minder]] のホストメトリクス視点を融合した監視スタックの一次ソースを探す([[LLM学習モニタリング]]/[[GPUクラスタ運用]] 未解決の問い)。 - [[Pulse]] が引く同チーム([[Nanjing University]])の μMon(SIGCOMM 2024、マイクロ秒ネットワーク監視)・Astral(SIGCOMM 2025、LLM 訓練のデータセンタインフラ)を取り込み、ネットワーク計測の系譜と [[Chen Tian]]/[[Qingkai Meng]] の研究文脈を補強する。RDMA 計測の他応用(分散推論の監視・輻輳制御のバグ診断)も §9 が挙げる。 - 訓練クラスタのマシン単位の箇所特定([[Minder]] の均質性に基づく類似度)とクラウドのマイクロサービスのコンポーネント単位の箇所特定([[MetricSifter]] の異常伝播)の中間(異種な推論サービング等)でどちらの異常信号が効くか、手法を相互転用できるかを示す一次ソースを探す([[Fault Localization]] 未解決の問い)。 - [[Minder]] が引く ByteDance の信頼性運用系([[MegaScale]] §4 の耐障害性、R-Pingmesh、Collie、HostPing)や SuperBench(先回り型の検証)を取り込み、ハートビート系・先回り型ベンチマーク系・メトリクスパターン系・トラフィック系([[Pulse]])の検知機構を横断比較して [[GPUクラスタ運用]]/[[LLM分散学習]]/[[LLM学習モニタリング]] の Reliability 知見を厚くする。検知機構はハートビート→ホストメトリクス→トラフィックの 3 層まで揃ったので、各層がカバーする障害・検知遅延・オーバーヘッドの定量比較と、オフラインのベンチマーク(SuperBench/Collie/HostPing)がオンライン監視で本当に不要になる障害クラスの境界を厚くする。 - [[LLM分散学習]]/[[並列化戦略]] は [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]] の取り込みで 2 ソース化し developing に到達。[[Mixture-of-Experts]] は依然サーベイ 1 ソースで seed。残る LLM 訓練システムの一次論文(Megatron-LM・Alpa・ZeRO/DeepSpeed・FlashAttention・Oobleck・GShard/Switch Transformer 等)を取り込み、サーベイの分類を一次ソースで裏取りしつつ横断的知見を厚くする。とくに MoE のエキスパート並列は一次論文待ち。`structures/分散深層学習 - MOC`・`HPC - MOC` と接続済み。 - [[MegaScale]] は手作りの 3D 並列化で 55.2% MFU を出すが、自動並列化(Alpa/FlexFlow)が同規模で上回れるかは未検証([[並列化戦略]] 未解決の問い)。自動化の費用対効果を示す一次ソースを探す。MegaScale の協調設計技術がどこまで他ハードウェア/他組織に一般化するか(Ampere・自社ネットワーク前提)も追う。 - 訓練インフラの異常検知(本サーベイ §8.2:GPU ハートビート/DCGM/ストラグラー検出)と本番サービスの AIOps 異常検知([[Fault Localization]]/[[テレメトリ]])は語彙を共有するが対象が異なる。両者の手法・指標が相互転用可能かを示す一次ソース(訓練クラスタ監視 × サービスオブザーバビリティ)を探し、[[LLM分散学習]] の横断的知見を厚くする。 - 本サーベイの今後の方向性の光コンピューティング / 光ネットワーク(シリコンフォトニクス)の一次研究を取り込み、デジタルの限界への代替計算基盤の動向を追う(2024-07 刊行後の進展を要確認)。 - [[テレメトリ]]/[[分散トレーシング]] はパス指向データの収集を扱う唯一のソース。メトリクス中心の AIOps 群とつなぐトレースベースの RCA(コールグラフを入力にする障害箇所特定)の一次ソースを取り込み、時間指向とパス指向のマイニングを結ぶ横断的知見を立てる。 - [[時系列データベース]]([[HeteroTSDB]])と [[時系列基盤モデル]]([[Toto]]/[[BOOM]])は同じ観測時系列の「保持」と「予測」の別段。観測テレメトリのライフサイクル(収集→保持→予測→診断)を縦に貫く一次ソースを探し、TSDB に予測/異常検知を組み込む設計の横断的知見にする。 - 博士論文 §6.3 の今後の方向性「収集優先 → 利用優先の閉ループ」「LLM 向け障害スナップショット生成」を追う: マイニング層(AIOps エージェント)から計装/ストレージへ収集ポリシーを還流する一次研究、統計的な前処理を LLM 入力整形に転用する手法を取り込む。 - [[特徴量削減]]/[[Fault Localization]] は [[MetricSifter]] 1 ソースで seed。障害箇所特定/RCA の他の一次論文(因果探索ベース・異常伝播系)を取り込み、統計手法側の横断的知見(削減の良さ対箇所特定の良さのギャップ等)を厚くする。`structures/異常検知 - MOC`・`Project AI4SRE - MOC` と接続済み。 - 統計的な [[特徴量削減]]([[MetricSifter]])の出力を LLM エージェント([[AIOpsLab]]/[[Bits AI SRE]])の入力前処理に与えるとコンテキストウィンドウの圧迫が緩和され精度が上がるか、という古典×LLM ハイブリッドの問いを追う一次ソースを探す。 - [[変化点検知]] は seed(横断的知見が空)。[[時系列基盤モデル]](TSFM)を変化点検知に使う研究や、Ruptures 以外の変化点検知手法の一次ソースを取り込み横断的知見を立てる。 - [[時系列基盤モデル]] は [[Toto]]・[[Falcon-X]] の 2 ソース。残る主要 TSFM 一次論文(Chronos-2・TimesFM・Moirai 2.0・Timer-S1・Time-MoE)を取り込み、「汎用 TSFM が観測データで苦戦する原因はアーキテクチャか事前学習データか」「因子分解対グループ対プロトタイプのアテンション」「エンコーダ対デコーダ」の横断的知見を厚くする。`structures/時系列基盤モデル - MOC` と接続済み。 - [[多変量時系列予測]] は [[Falcon-X]]・[[Toto]] の 2 ソースで seed。Falcon-X の「生空間での混合は意味的崩壊する」主張は [[Chronos-2]] のグループアテンションにのみ直接検証。Toto の因子分解アテンションや Moirai の平坦化でも退化するかを後続ソースで確認し、変量間方式の優劣を横断的知見化する。 - [[Chronos-2]]([[Falcon-X]] 経由の二次情報で seed)を一次論文(Ansari+ 2025, arXiv:2510.15821)で取り込み、グループアテンション・文脈内学習の機構を一次確認する。同様に Moirai 2.0・Timer-S1 も TSFM 表の比較対象として一次化候補。 - [[Toto]]/[[BOOM]] と SRE エージェント系列([[Bits AI SRE]]・[[障害予測]]・異常検知)の橋を架ける: 観測時系列予測の精度向上が下流の異常検知・キャパシティ計画・先回り型の障害予測にどう効くかを示す一次ソース(予測ベース異常検知・予測×RCA)を取り込む。 - [[BOOM]] の評価設計(本番/ステージング分離・シフト幾何平均・LLM ラベリング+人手検証のタクソノミ)を、GIFT-Eval 一次論文と突き合わせてベンチマーク方法論の横断的知見にする。 - [[根本原因分析]] は [[Bits AI SRE]] 1 ソースで seed。RCA 専門の他ソース(RCACopilot・Flash 系の RCA・因果推論ベースの RCA)を取り込み、「相関と因果の弁別」「深掘りの停止規準」の横断的知見を厚くする。 - [[Bits AI SRE]] の「因果関係を優先し相関のあるノイズと弁別する」具体機構(因果推論/トポロジ/学習済み相関)は未公開。後続ソースや Datadog の技術資料で機構を特定する。 - 産業実装のカバーする段階の分化(Google=全ライフサイクル / Datadog=調査・RCA 特化)を追跡。他の商用 AI SRE 製品(PagerDuty・Incident.io・Cleric 等)を取り込み、「どの段を自律化するか」の産業マップを作る。 - [[SRE AI Autonomy Levels]] は [[Google]] 1 ソースで seed。他の自律度フレームワーク(自動運転 SAE レベル、エージェント型 AI 一般の自律度分類)や他社の SRE 自律度の語り方を取り込み、SRE 固有の 5 軸がどこまで一般/特殊かを横断的知見にする。 - 産業対学術の緊張関係([[agentic SRE]] の矛盾)を追跡: Google の「L2/L3 の本番自律緩和」を学術ベンチで再現/反証する方法論はあるか。本番自律緩和の成功率・対象範囲の公開データを探す。 - [[Model Context Protocol]] / A2A は本ソース起点の seed。MCP/A2A の一次仕様や他のエージェント型 SRE 実装での採用例を取り込み、エージェント–ツール/エージェント間インターフェースの標準化動向を厚くする。 - [[障害緩和]] は現状 [[MicroRemed]] 中心の seed。プランベースの緩和(ルール/ポリシー駆動)の一次ソースや、ソースコード / 過去の緩和記録を併用する緩和手法を取り込んで横断的知見を厚くする。 - [[MicroRemed]] の評価妥当性(カオス注入で症状だけ消して根本原因が残る緩和を成功と誤判定しないか)を、SREGym の状態ベースの判定や [[Transactional No-Regression]] と突き合わせて検証する。 - [[ThinkRemed]] の「リフレクション > プローブ」「過剰なプロービングの害」は現行モデルの文脈的推論能力に依存する暫定結論。より賢いモデルでプローブの価値が回復するかを後続ソースで追う。 - [[障害予測]] は現状 [[PAGER]] 1 ソースで seed。先回り型/予測型 AIOps の他ソース(データセンタの障害予測・予知保全等)を取り込み横断的知見を厚くする。 - [[PAGER]] が依存する AEP 既存の AI Assistant の論文 Maharaj et al. 2024(Adobe, エンタープライズ AI アシスタント評価)を取り込み、[[Yunyao Li]] の研究系譜とエンタープライズ AIOps の文脈を補強する。 - [[ITBench]] のベースラインのエージェント(CrewAI 上の SRE/CISO/FinOps-Agent)の詳細実装や、留保された 91 シナリオの内訳を示す後続資料・リーダーボードを追跡し、[[ITBench]] の評価カバレッジを厚くする。公開 11 シナリオ + GitHub(ibm/itbench)で再現可能な範囲を確認する。 - ベンチ天井の桁違い([[AIOpsLab]] ~59%・[[SREGym]] ~6割・[[ITBench]] ~11%)を正規化する方法論を探す。タスク定義・成功オラクル・モデル設定・分解採点対エンドツーエンドの差を揃えてベンチ横断比較する一次研究を取り込み、[[SRE Benchmark]] の「複数ベンチ横断の 1.5 倍主張」の問いに答える。 - [[Transactional No-Regression]] の形式的定義(不変条件・トランザクション境界・巻き戻し判定)を STRATUS 一次論文の本文/付録で確認し、概念を seed → developing に育てる。 - [[Metastable Failure]] の一次研究(Bronson+ HotOS'21 等)を取り込んで定義・対策を厚くする。 - SREGym 一次資料で AIOpsLab の ReAct 依存に関する記述を確認し、[[AIOpsLab]] の矛盾を解決する。 ## 2026-06-17 ingest: LLMAD(KDD 2025)+ ChatTS(VLDB 2025) - [[LLMAD]]([[@2025__KDD__Large Language Models can Deliver Accurate and Interpretable Time Series Anomaly Detection]], [[Jun Liu (UCAS)]]・[[Chaoyun Zhang]] ほか [[Microsoft]] + UCAS + ZJUT)は LLM を直接 TSAD の判定器として使う初のフレームワーク。FastDTW ICL(正常・異常両履歴)+ [[AnoCoT]](判定ルール・8 種異常タイプ・3 段階アラームレベル + 大域 → 局所 → 再評価の段階推論)で、GPT-4 を KPI/WSD/Yahoo 平均 Best F1=0.759 に押し上げ TFAD(0.725)・Anomaly Transformer(0.621)を上回る。年間運用コスト約 $65.70(1 分粒度・GPT-4-1106-preview)。Llama-3-70B・GPT-3.5 では実用域に届かない(GPT-4 級が必須)。 - [[ChatTS]]([[@2025__VLDB__ChatTS - Aligning Time Series with LLMs via Synthetic Data for Enhanced Understanding and Reasoning]], [[Zhe Xie]]・[[Zeyan Li]] ほか [[Tsinghua University]]/[[BNRist]] + [[ByteDance]] + [[BizSeer]])は時系列を画像同等のネイティブな多変量モダリティとして扱う初の TS-MLLM。属性プール(Trend 4 / Periodicity 7 / Noise 3 / Local Fluctuation 19 種 × 567 メトリクス)+ [[TSEvol]](Evol-Instruct を 4 種進化に拡張)+ Context-Aware Encoding(時系列パッチをテキストトークン位置に挿入)+ Value-Preserved Normalization で、Qwen2.5-14B を完全合成データのみで SFT。GPT-4o(vision/text/agent)を alignment +46.0% / reasoning +25.8% で凌駕、入力トークンは 1/40〜1/15。 - **両論文の符合**: 同じ「Prompting/MLLM で時系列を扱う」問題意識から、(a) [[LLMAD]] は単変量 + 解釈、(b) [[ChatTS]] は多変量 + 推論という別解を出した。[[時系列マルチモーダルLLM]] は両者の共通言語として新規 concept ページに分離。本 wiki [[LLM時系列アプローチ]] の 5 既存路線(Prompting/Quantization/Aligning/Vision/Tool)に「TS-MLLM」を第 6 路線として追加。 - **異常検知層への影響**: 本 wiki の [[異常検知]] が育ててきた「常時稼働の検知に LLM が重すぎる」というスレッドに対し、LLMAD は「サンプリング周波数を 1 分以上に緩めれば実用域」と解を示し、ChatTS は「ネイティブモダリティで多変量診断対話まで広げる」方向を示した。両者は [[MonitorAssistant]](LLM をメタ層に限定)・[[Minder]]/[[Pulse]](非 LLM 軽量検知)とともに、検知層への LLM 導入の 4 路線として並存する。 - **Microsoft の二路線併走が明確化**: LLMAD(LLM を検知器として直接使う)と MonitorAssistant(LLM を検知器でなくメタ判断層に限定)は同じ Microsoft 内で同時に進む。共著者の [[Minghua Ma]]・[[Chetan Bansal]] は両論文に参加しており、Microsoft AIOps 系の「LLM × 検知」研究が単一路線でなく実験的に多方向で進む構造を示す。 - **次に追うべき問い**: (i) ChatTS の rulebook 適用 × LLMAD の AnoCoT を統合した「多変量 + 解釈付き TSAD」の実証研究はあるか、(ii) ChatTS の属性プールに無い病的パターン(ネスト周期、非定常変化)を LLMAD 型の Prompting + 履歴 ICL で補えるか、(iii) [[時系列基盤モデル]](Toto/TimesFM)と TS-MLLM の 2 段構成(TSFM が予測埋め込み、TS-MLLM が自然言語推論)は agent-based の限界を超えるか。 - **未解決の表記揺れ**: [[Zhe Xie]] の所属表記が CauseRank(2022)・LatentScope(2024)では [[Shanghai Jiao Tong University]]、ChatTS(2025)では [[Tsinghua University]]; [[BNRist]] となっている。メールアドレス([email protected])からは Tsinghua 博士課程と読めるため、移籍した可能性が高いが要確認。判明したら entity ページを統合する。 # 2026-06-28: SREcon26 Americas | The Ironies of AI²（J. Paul Reed） - **主題**: Bainbridge（1983）の自動化のアイロニーをAI時代に拡張。Joint Cognitive System 5特性（Autonomy・Authority・Directed Attention・Redirectability・Interpredictability）でインシデント対応中のAI利用を評価。 - **中核知見**: 1. 自動化もAIも、協調の基盤3特性（Directed Attention・Redirectability・Interpredictability）を欠く。 2. インシデントは「効率性賭けに既に負けた状態」（ETO）。そこでさらにAI依存を高めることは同じ賭けを倍増させる。 3. 看護師実験: AI誤り多い条件で96〜120%性能悪化。ただし「AI説明のみ」条件では悪化が大幅に緩和。→「AIに何をすべきか聞くな、何が起きているか説明させよ」。 - **Source**: [[@2026__SREcon26Americas__The Ironies of AI²]] (動画: https://www.youtube.com/watch?v=cvcGIr4a2Dk) - **Entities (new)**: [[Chime]] - **Entities (updated)**: [[J Paul Reed]](Chime役職・SREcon26追記) - **Concepts (updated)**: [[自動化のアイロニー]](SREcon26でのAI時代拡張・看護師実験知見・ETO視点追記), [[Joint Activity]](JCSとの対比・AIのInterpredictability欠如追記) # 2026-06-26: データセンター信頼性・クラウド障害論文 9 本 - [[データセンター信頼性]]: HDD 温度単体の影響は小さい一方、運用全体では相関障害と修理保留が耐障害設計を左右する。 - [[クラウドインシデント]]: 冗長化だけでなく、検知・フェイルオーバー・バックアップの復旧連鎖と本番バグを扱う必要がある。 - [[データセンターネットワーク信頼性]]: 評価単位を部品故障からサービス影響のあるネットワーク事象へ移す。 - [[分散システム障害]]: 設定、部分障害、非決定的イベント順序を横断する本番検証が課題である。 # 2026-07-01: SREcon23 Americas | Incident Commanders（Vanessa Huerta Granda, Emily Ruppe） - **主題**: IC(Incident Commander)とインシデントアナリストという「似て非なる別々のスキルセット」の切り分け。両ロールを同一人物が兼務する際の注意点(燃え尽きリスク・社会技術的要因の見落とし)。 - **中核知見**: 1. IC の核心は「指示を出さない・壊れたものを直さない」調整(coordination)、アナリストの核心は「事件がなぜそのように起きたかを調査すること」。 2. IC が事後検証(post-incident review)も担当すると、対応に密接に関わりすぎた結果、社会技術的要因を見落としやすい。 3. 「インシデントのサイクル(Circle of Incidents)」— 平常運転→インシデント発生→事後学習→システム変化→新たな平常運転という円環モデルを提示。 - **話者の同一性確認**: 本講演の Vanessa Huerta Granda は SREcon25/26([[Enova]] 在籍時)の既存 entity と同一人物。2023年時点([[Jeli]] 在籍時)のより早いキャリア段階の講演として整理した。 - **Source**: [[@2023__SREcon23Americas__Incident Commanders]] (動画: https://www.youtube.com/watch?v=VLGxGrNnWrY) - **Entities (updated)**: [[Vanessa Huerta Granda]], [[Emily Ruppe]], [[Jeli]] - **Concepts (new)**: [[インシデントアナリスト]] - **Concepts (updated)**: [[Incident Commander]](IC/アナリスト役割分離と Slack no-give-backs ハンドオフの理由付け・「インシデントのサイクル」ライフサイクル図を追記), [[インシデント管理]](「インシデントのサイクル」円環モデルと Response/Review/Analysis 3部構成の対応関係を追記) # 2026-07-15: Valet: Efficient Data Placement on Modern SSDs (SoCC '25) - **主題**: NAND フラッシュ SSD のガーベジコレクション削減のため、LD_PRELOAD ベースの userspace シムレイヤー Valet を提案。アプリケーション・ファイルシステム・カーネルを一切変更せずに ZNS SSD 等へ配置ヒントを注入する。 - **中核知見**: 1. データ配置の一般理論として、temperature(hot/cold/warm/undefined の4値)ベースの粗い分類ではなく、affinity(親和性、同一書き込み元をまとめる)と lifetime(寿命、生成・削除の時間局所性でまとめる)の2軸を提示。 2. ホスト誘導配置の責務をアプリケーションでもカーネルでもなく userspace のシムレイヤーに切り出すことで、アプリケーション固有ソリューション(zenfs)に匹敵する性能と、複数アプリケーション(RocksDB・MongoDB・CacheLib)への無変更適用性を両立。 3. ヒューリスティックと学習ベース(バッチ mini KMeans、Valet-Learn)の両方のヒント生成を同一アーキテクチャで実証。f2fs に対し2〜6倍のスループット、最大6倍低いテールレイテンシ。 - **Source**: [[@2025__SoCC__Valet - Efficient Data Placement on Modern SSDs]](コード: https://github.com/shimplify/valet) - **Entities (new)**: [[Devashish R. Purandare]], [[Peter Alvaro]], [[Avani Wildani]], [[Darrell D. E. Long]], [[Ethan L. Miller]], [[Valet]], [[MongoDB]], [[CacheLib]], [[zenfs]], [[f2fs]], [[Pure Storage]] - **Entities (updated)**: [[UC Santa Cruz]], [[Emory University]], [[Cloudflare]], [[RocksDB]] - **Concepts (new)**: [[ホスト誘導データ配置]], [[シムレイヤー]], [[ゾーン名前空間SSD]] - **Concepts (updated)**: [[LSMツリー]](WAL/SSTable の物理配置による性能改善という新しい最適化軸を追記) # 2026-07-20: Adversarial dynamical systems characterize when data-driven learning succeeds or fails (Nature Communications, 2026) - **主題**: Koopman作用素のスペクトルをデータから学習できる条件・できない条件を、敵対的力学系(adversarial dynamical systems)の構成によって鋭く分類する理論枠組み。 - **中核知見**: 1. 測度保存性と連続性の法(modulus of continuity)という2条件が揃えば、収束・誤差保証つきの最適アルゴリズムが単一極限で存在する。条件が欠けると、必要な逐次極限の回数が増える階層構造(可解性複雑性指標、SCI)を成す。 2. 条件が揃わないクラスに対しては、敵対的力学系(homeomorphismによる摂動を入れ子状の円盤カスケードに適用)を構成することで、いかなるアルゴリズム(確率的なものを含む)も無限データがあっても50%を超える確率で収束できないことを証明。 3. 北極海氷濃度データ(1979-2021)に適用し、EDMDでは埋もれる「隠れた減衰モード」(Barents海・Kara海に集中、平均減衰時間233ヶ月)を誤差保証つきで検出。IceNet(4.4×10^7パラメータ・GPU訓練)・SEAS5より高精度かつラップトップ上1秒未満で訓練可能な低コストの長期予測を実現。 4. LLMのhallucinationとの類推(推測的考察): 敵対的系はしばしば連続的な周波数分布を持つKoopman作用素(カオス力学の特徴)を持ち、短期精度と長期予測不能性が両立する——これがプロンプトの微小変化が出力を大きく変える現象と類似すると論じる。 - **Source**: [[@2026__NatCommun__Adversarial dynamical systems characterize when data-driven learning succeeds or fails]](コード: https://github.com/MColbrook/Adversarial-Dynamical-Systems) - **Entities (new)**: [[Matthew J. Colbrook]], [[Igor Mezić]], [[Alexei Stepanenko]] - **Entities (updated)**: [[UC Santa Barbara]], [[University of Cambridge]] - **Concepts (new)**: [[Koopman作用素]], [[可解性複雑性指標]]