ID:84718さん

Stream v3｜24時間ライブ配信基盤の設計・開発・運用 ■ プロジェクト経験概要 ADS-B航空機情報、気象情報、音楽を合成し、YouTube LiveとTwitchへ24時間配信するシステムを個人で設計・開発・運用しています。 最も重視する要件は、障害が発生しても既存のYouTube Live URLを維持し、視聴者が同じURLから配信へ戻れることです。 配信URL、映像、音声、航空機データ、送信経路、外部サービスの状態を分けて観測。障害の原因を切り分け、必要な範囲だけを復旧する構成を開発しました。 2026年5月6日から10月14日までの公開記録では、160日以上にわたり同一のYouTube動画IDを維持しています。2026年10月21日時点でも同じURLで運用を継続しています。 現在は、Dellワークステーションで配信映像を生成し、Oracle Cloud Infrastructure（OCI）のMediaMTXでYouTubeとTwitchへ分岐しています。OCI経路に障害が発生すると、DellからYouTubeのバックアップ入力へ直接送信する構成です。 2026年10月20〜21日に、リレーサービス停止、WireGuard通信断、OCI VMリセットの3種類の障害試験を実施。いずれもバックアップ起動、通常経路への復帰、同一動画IDの維持を確認しました。 また、長期運用中に復旧処理同士の競合を経験したことから、Monitoring v4とCentral Restart Authority（CRA）を別途設計・実装しています。 配信本体は実運用中です。Monitoring v4は一部の読み取り専用機能を本番利用しています。CRAによる中央復旧制御は本番無効とし、設計・自動テスト・隔離環境での検証対象として管理しています。 ■ チーム情報・担当範囲 個人開発・個人運用、1名。本業の工場勤務と並行して取り組んでいます。 要件定義、技術選定、アーキテクチャ設計、実装、テスト、デプロイ、監視、障害解析、復旧設計、継続改善を担当しています。 開発ではCodex等の生成AIを利用しています。コード探索、実装、テスト作成に活用する一方、生成結果そのものを正しさの根拠にはしていません。 要求仕様、不変条件、操作権限、変更範囲、合否判定を明文化し、ソースコード、自動テスト、実際の観測結果を突き合わせて検証しています。 ■ 開発・実装内容A：同一URLの維持とOCI障害時の自動復旧 【課題】 YouTube Liveの配信障害時に新しい動画IDを作成すると、既存のリンクや埋め込み先から視聴者が戻れなくなります。 また、Twitchへの配信を追加する際、自宅回線から2本の映像を常時送信すると、上り帯域の負荷が増加します。 配信先を増やしながら自宅側の帯域消費を抑え、OCI経路に障害が起きてもYouTubeの既存配信を維持することを課題としました。 【設計・実装】 Dell上のk3sで航空機地図、気象情報、音楽を合成。FFmpegとNVIDIA NVENCでエンコードし、WireGuardトンネル経由でOCI上のMediaMTXへRTMPS送信しています。 MediaMTXからYouTubeとTwitchへ映像を転送するため、正常時の自宅側アップロードは1系統です。 OCIの入力状態、受信バイト数、YouTube転送先の状態、送信バイト数を15秒間隔で確認します。 30秒間継続して経路が異常、または観測不能となった場合、Dell側の独立したバックアップPodを起動します。バックアップPodは独自に映像と音声を生成し、CPUエンコードでYouTubeのバックアップ入力へ直接送信します。 通常経路が復旧しても、直ちにバックアップを停止しません。300秒間の連続した正常観測を確認してから終了させます。 転送先の識別には配列の位置ではなく宛先ホストを使用。転送先の削除・再生成によって配列位置が変わっても、TwitchをYouTubeと誤認しないよう修正しました。 MediaMTXの設定変更後には実際の設定を再取得して照合します。設定変更要求が受理されても、実状態が一致しなければ完了として扱いません。 バックアップ制御のKubernetes権限は、専用ServiceAccountとRBACで対象Deploymentの取得・スケーリングに限定しました。 【成果】 - 2026年5月6日〜10月14日の公開記録で、160日以上にわたる同一動画IDの維持を確認。後半140日分の日次チェックポイントではURL切替0件。 - 10月20日のリレーサービス停止試験では、52秒後にバックアップを起動。送信断は約65秒でしたが、既存のYouTube配信は終了しませんでした。 - 10月21日のWireGuard通信断試験では、180秒間トンネルを遮断。58秒後にバックアップが起動し、トンネル復旧後はメイン経路が7秒で再接続しました。 - 同日のOCI VMリセット試験では、65秒後にバックアップが起動。VM再起動後、WireGuard、MediaMTX、keeperが自動起動し、通常経路へ復帰しました。 - 両試験とも正常経路の回復確認後、約300秒でバックアップを自動停止。YouTubeの動画IDは維持され、TwitchもLIVEへ復帰しました。 - 最新公開コミットに対するGitHub Actionsの配信本体・Monitoring v4・Recovery Controlの3ジョブが成功しました。 これらは定義した障害条件での復旧結果です。ローカル観測上の送信断と視聴者側の映像停止時間は区別しています。 長時間のOCI VM停止、配信事業者側の障害、現行経路の長期間の信頼性については、追加検証が必要です。 ■ 開発・実装内容B：TCP stallの原因切り分けと送信帯域の解析 【課題】 RTMPSの送信が停止するTCP stallが繰り返し発生していました。 送信停止だけを観測しても、YouTube、DNS、TCP、NAT、WANのどこに問題があるかを区別できません。 また、OCI経由への移行後、エンコーダ設定を変更していないにもかかわらず、自宅側の送信レートが約4.88Mbpsから約3.6Mbpsへ変化しました。 【設計・実装】 RTMPSの送信量、未送信データ、未ACKデータに加え、Cloudflare・Google向けの独立したTCP/TLS通信を観測しました。 既存接続と新規接続、DNS経由とIP直接接続、IPv4とIPv6を区別。デフォルトルート、外部アドレス、経路の状態変化も記録しています。 60秒間隔の観測では短時間の変化を取り逃すため、通常60秒、重点時間帯10秒、異常検知後5秒へ観測間隔を切り替える構成としました。 OCI経由への移行後は、送信バイト数と実際のメディアデータ量を区別するため、パケットキャプチャでTLSレコードのサイズと送信頻度を比較しました。 【成果】 複数日にわたり、YouTube以外の独立した通信も同時に失敗することを確認。YouTube単独、DNS単独、既存NATセッションだけの問題という仮説を切り分け、WAN/session層の障害を最有力と判断しました。 高頻度観測ではIPv6デフォルトルートの一時消失も取得しました。ただし、宅内ルーターと通信事業者のどちらが起点かは未確定です。 OCI経由への変更に伴う送信レート低下については、直接RTMPS送信時の小さなTLSレコードが原因で、メディアデータ量に対して約34%のフレーミング負荷が発生していたことを確認しました。 OCI経由ではフレーミング負荷が1%未満となり、約3.6Mbpsのメディア送信量を維持しながら、自宅側の送信帯域を約1.2Mbps削減できています。 ただし、YouTube側で断続的に報告される "bitrateLow" 警告の原因は未特定です。通信上の改善と、配信サービス側の品質判定を分けて評価しています。 ■ 開発・実装内容C：監視・配信・公開の責務分離とMonitoring v4 【課題】 配信ホストと監視ホストを共通化すると、配信側の障害によって原因調査に必要な証拠も失われます。 また、観測、障害判定、通知、復旧操作を密接に結合すると、監視側の誤判断が正常な配信へ影響する可能性があります。 内部監視情報をインターネットへ直接公開しないことも要件でした。 【設計・実装】 物理ホストを役割別に分離しました。 - HP ProDesk：ADS-B受信、readsb、Prometheus、Loki、Grafana、配信状態の監視。 - Dell：MapLibreによる地図描画、音声合成、FFmpegエンコード、k3sによる配信実行。 - OCI VM：MediaMTXによる配信分岐と転送先の自己復旧。 - Raspberry Pi：許可した監視情報の収集、静的ステータス生成、GCSへの送信。 公開閲覧者はCloudflare経由で静的データを参照します。内部Grafana、Prometheus、Loki、運用DBへの直接アクセスは提供しません。 Monitoring v4では、観測入力、現在状態、インシデント遷移、通知要求、公開データ生成を分離しました。 複数のk3sワークロードから単一SQLiteファイルを共有する構造を避け、PostgreSQLを導入。SQLiteは移行・ローカル検証・復旧用途に残しています。 DBへの記録と公開ファイルの更新が途中で分断されても、永続化した公開予定データを後続処理で照合・再公開できる仕組みを実装しました。 【成果・現在地】 内部の監視情報と公開ステータスを分離し、観測値の鮮度、欠損、履歴、現在状態を区別して表示しています。 Monitoring v4のOCIリレー観測と公開用データ投影は、読み取り専用機能として本番利用しています。 全面的な移行は完了していません。新旧監視の比較や長時間検証は、対象リビジョンと観測期間を固定した別の検証工程として扱っています。 復旧操作権限はMonitoring v4へ付与していません。既存監視系の条件付き再起動要求と、Monitoring v4の観測専用機能も区別しています。 ■ 開発・実装内容D：復旧操作の競合を防ぐCRAの設計・実装 【課題】 ローカルとリモートの復旧処理が独立して動作し、同じ対象へ複数の操作が行われる問題が発生しました。 切り替え試験では、別の復旧経路が実行環境を変更し、評価対象が失われてロールバックした事例がありました。 操作台帳の調査では、同じFFmpeg世代を対象とした再起動試行の重複を7組確認しました。 要求ID単位の冪等性だけでは、別IDで発行された同一対象への操作を防げません。 【設計・実装】 Central Restart Authority（CRA）では、復旧責務を3層へ分離しました。 - Monitoring：観測事実と障害情報を提供。 - CRA：復旧方針、回数上限、待機時間、操作許可、最終結果を管理。 - Dell Executor：指定されたFFmpegプロセスに限定して操作を実行。 操作の意図と送信予定をDBへ確定してから通信するトランザクショナル・アウトボックスを実装しました。 要求IDだけでなく、対象プロセスの論理世代と操作範囲に対してfencingを行い、別IDによる同一対象への重複試行を制限します。 通信応答が失われた場合、未実行と決めつけず "OUTCOME_UNKNOWN" を保持。自動再試行を停止し、後続の証拠で実行結果を照合します。 ホスト間の通信にはmTLSと署名付きメッセージを使用。ホストをまたぐ分散ACIDを仮定せず、ローカルトランザクション、永続化、対象識別、権限の有効期限、事後照合を組み合わせています。 【成果・現在地】 CRAの中核実装と、重複要求、古い対象、通信応答の欠落、クラッシュ前後の状態を扱う自動テストを実装しました。 ただし、CRAは現在のOCI配信経路では使用していません。 現行配信では運用と検証の複雑さを減らすため、局所的な自己復旧方式を選択しました。CRAは設計・検証用として保持し、本番での復旧時間短縮や重複操作削減を実証済みとは扱っていません。 ■ 開発・実装内容E：Harness Engineeringによる障害検証の前倒し 【課題】 復旧処理が複雑化すると、通常のコードレビューや単体テストだけでは、状態遷移、通信、永続化、障害復旧の組み合わせを確認しきれません。 長時間検証の途中で不具合が見つかると、修正後のリビジョンで観測期間を取り直す必要がありました。 【設計・実装】 隔離環境で故障条件を再現するHarnessを開発しました。 - SUT：検証対象システム。 - Injector：通信断、応答欠落、重複要求、古い状態、クラッシュなどを注入。 - Observer：状態遷移、識別子、タイムスタンプ、実行結果を記録。 - Oracle：不変条件と観測証拠から合否を判定。 OracleはSUTの判断結果をそのまま正解として利用しない構成です。 意図的に不変条件を破るNegative Controlを設け、判定側が違反を検出できるかも検証しています。 故障注入要求を発行しただけでは成功と判定せず、故障の発生、証拠の取得、試験後の状態まで確認します。 試験対象の不具合、Harness側の不具合、証拠不足、結果不明を区別しています。 【成果・現在地】 Monitoring v4の状態遷移を連続実行する検証で、同一時刻の更新順序による不正な拒否や、期限切れ状態から正常な代替候補へ移行できない問題を再現・修正しました。 不具合の再現条件、修正前後の結果、回帰テストを保持しています。 公開CIでは配信本体、Monitoring v4、Recovery Controlを別ジョブで検証しています。 Harnessの目的は長時間検証を省略することではありません。再現可能な不具合を事前に除去し、soakのやり直しを減らすことです。 検証時間や失敗回数の削減率は未計測のため、定量的な改善実績としては扱っていません。 ■ 開発・実装内容F：第三者音源の利用条件と公開運用への反映 【課題】 ライブ配信に第三者の音源を追加する際、利用許諾、クレジット表記、利用先、音量調整を管理する必要がありました。 【対応・実装】 音源提供者FloracoreへYouTube Liveでの利用可否を確認し、クレジット表記を条件とした利用許諾を取得しました。 NCSの利用条件とFloracoreからの個別許諾を分けて管理しています。YouTube向けの許諾をTwitchや別チャンネルまで拡張して解釈しないよう、利用範囲を区別しています。 導入スクリプトはdry-runを既定とし、許諾条件とクレジット準備の確認が明示されるまで本適用できない設計としました。 再生中の提供元に応じて表示を切り替え、再生時の固定gainによって提供元間の音量差も補正しています。 【成果】 外部への利用確認、条件整理、実装、テスト、継続運用までを一貫して担当しました。 技術的に再生できることと、公開サービスで継続利用できることを別の条件として管理しています。 ■ 主な使用技術 本番配信・運用 Python、JavaScript、FFmpeg、NVIDIA NVENC、MapLibre GL JS、YouTube Data API、Twitch Helix API、MediaMTX、RTMP/RTMPS、WireGuard、Docker、k3s/Kubernetes、Linux、systemd、Prometheus、Loki、Grafana、GCS、Cloudflare 監視・復旧制御・検証 PostgreSQL、SQLite/WAL、JSON Schema、SHA-256、Ed25519、mTLS、pytest、unittest、GitHub Actions、障害注入、状態遷移検証、SLI/エラーバジェット ※ 後者には本番未導入のCRA、Monitoring v4の一部機能、隔離環境用の検証基盤を含みます。 ■ 公開範囲・参考資料 公開リポジトリ https://github.com/yukimurata0421/live-stream-systems-case-study 採用担当者向けの読み順 https://github.com/yukimurata0421/live-stream-systems-case-study/blob/main/docs/hiring-reviewer-guide.md OCI経路と自動復旧の検証 https://github.com/yukimurata0421/live-stream-systems-case-study/blob/main/docs/v3/self-healing-oci-fanout.md 技術的な設計変更の判断記録 https://github.com/yukimurata0421/live-stream-systems-case-study/blob/main/docs/v3/oci-route-simplification-decision.md 公開リポジトリには、配信本体、監視・復旧制御の実装、テスト、設計資料、運用事例を含めています。 本番の認証情報、運用DB、生ログ、音源、許諾に関する私的なやり取りは公開していません。 実際の運用結果、障害試験、コードレベルの検証、未検証の機能を区別しています。 記載基準：2026年10月21日 公開ソース確認コミット： "7a23d306b6717e2a03a84cb77d7b9f86f62e7354" 同一URLの公開台帳最終確認： 2026年10月14日

### プロジェクト概要 公開されたインシデントレポートやポストモーテムの障害知識を、別のシステムの変更前検証に再利用するためのReliability Qualification Systemを開発しています。 目標は、過去に他のシステムで発生した障害の成立条件を抽出し、対象コードへの適用可能性を調べ、隔離環境で故障注入・修復・再注入・回帰検証を実施することです。 通常の検証を自動化し、人間の介入を例外的な判断に限定することを目指しています。 ### 開発背景と解決したい課題 24時間稼働するシステムの開発・運用を通じ、修正後の長時間試験や障害発生後の調査だけに依存しない検証方法が必要だと考えました。 障害レポートには原因や復旧方法が記録されています。しかし、その記録が別のシステムにも適用できるとは限りません。LLMが障害条件や修復方法を提案しても、対象コードの実際の動作を確認しなければ、耐障害性が改善したとは判断できません。 そこで、障害知識の解釈と実行権限を分離し、実験結果に基づいて修復の可否を判定する構成を採用しました。 ### 設計・実装した主な機能 **1. 障害知識の構造化と根拠管理** 障害記録を中間表現（Incident IR）として扱い、引用箇所、文字位置、原文ハッシュ、判定結果を関連付ける仕組みを実装しました。 System IRや適用可能性の評価インターフェースも用意しています。LLMの推論結果は仮説として管理し、実際の観測結果や仕様上の合否とは区別しています。 **2. 対象コードの静的解析と検証準備** PythonのAST、公開API、docstring、signatureを用い、対応可能な呼び出し箇所を静的に解析します。 複数リポジトリをTarget manifestに登録し、対象コード、所有者が定義した要件、実験条件、依存関係を固定して検証できるCLIを実装しました。 対応できないコード構造や、検証要件が不足する対象は実行せず、理由付きでHELDとして保持します。 **3. 故障注入・修復・再検証** 対応するPythonコードに限定し、原子書き込み、非同期リソース解放、時間経過による失効などの故障条件を検証します。 原実装での反例検出後、対応済みの修復方式または明示的に与えた候補を隔離コピーへ適用します。同じ故障の再注入、正常系回帰、別プロセスでの確認を行い、条件を満たした候補だけを派生スナップショットに採用します。 原本や稼働中のサービスは書き換えません。 **4. 隔離実行と安全制御** Linux namespace、bubblewrap、非root実行、capability制限、ネットワーク遮断、CPU・メモリ・実行時間制限を組み合わせました。 入力と実行計画はハッシュで固定します。実行回数と時間は永続的な台帳で管理し、失敗・結果不明の実行も消費として保持します。 モデルの確信度や修復提案だけでは実行を許可しない設計です。 **5. 比較評価・証拠管理・公開基盤** 障害記録を利用する群と利用しない群を、共通の要件・探索予算・修復条件で比較する仕組みを実装しました。 観測結果、適用した条件、修復候補、判定、実行時の証拠を保存し、後から再監査できるようにしています。 Python API・CLIに加え、障害記録の検索、実験準備、保存結果の閲覧を行うWeb UIを実装しました。 GitHub Actionsでテストとデプロイを管理し、GCPのVM・Cloud Run・Cloud StorageとCloudflareを組み合わせて公開環境を構築しています。公開閲覧機能と非公開の実験環境は分離しています。 ### 検証結果 2026年10月、所有下のPythonモジュール2種類を隔離コピーし、ファイル書き込み中のエラーによる一時ファイル残留と、非同期処理の例外・キャンセル時のロック解放漏れを再現しました。 8回のnative campaign、計56観測を実施。修復候補について、故障再注入12/12、正常系回帰12/12、別プロセスでの故障条件確認12/12を通過しました。修復は隔離スナップショット内に限定しています。 公開版のCIでは、Python 3.11と3.14でそれぞれ712テストを実行し、失敗0件でした。各29件のnativeテストはスキップとして管理しています。 開発版でも、2026年10月16日時点のオフライン全件検証で2,945件成功、354件保留、失敗0件を記録しました。 なお、現在の成功結果は既知の対象と有限な故障条件におけるものです。未知のOSSへの独立した一般化、外部障害記録による追加発見効果、確率校正、人間の作業時間削減は未実証として区別しています。 ### 使用技術 Python、AST、JSON Schema、SQLite FTS5、Linux namespaces、bubblewrap、GitHub Actions、Google Cloud（VM / Cloud Run / Cloud Storage）、Cloudflare ### 特に重視した設計方針 推論の正しさと、システムを実行してよいかという判断を分離することです。 証拠が不足している状態を成功へ変換せず、失敗・未実行・結果不明を区別します。検証結果から再現可能な範囲だけを認定し、対象コードへの変更は独立した確認を通過した後に限定しています。 **公開リポジトリ：** https://github.com/yukimurata0421/REQLOX **公開デモ：** https://reqlox.yukimurata0421.dev/demo/

プロジェクト経験概要 ADS-B受信環境のハードウェア変更が、本当に受信性能を改善したのかを統計的に評価するための分析基盤「ARENA」を個人で設計・開発しました。 アンテナ、SDR、ケーブルなどの変更前後で受信件数を単純比較するのではなく、航空交通量や時間帯などの外部要因と、機材変更による効果を可能な限り分離して判断できる仕組みを目的としています。 チーム情報 個人開発、1名。 評価方法の設計、統計モデル選定、データパイプライン、Python実装、テスト、Docker化、CI、分析結果の検証方法まで担当しています。 開発・実装内容A：ハードウェア変更効果の統計評価 【概要】 ADS-B受信機材を変更した際の性能差を、複数の統計手法から検証する評価pipelineを実装しました。 【どのような機能の開発・実装か】 受信データを距離帯や期間ごとに集計し、Bayesian Negative Binomial GLM、頻度論Negative Binomial GLM、Mann-Whitney U検定、change-point detection、OpenSkyデータによる正規化など、異なる前提を持つ複数手法で分析します。 【課題・問題点】 例えばSDRを交換した翌日に受信件数が20％増えたとしても、それだけでは機材変更の効果とは判断できません。 航空機数は時間帯、曜日、季節などによって変動します。また、ADS-Bのカウントデータは分散が大きく、疎な距離帯や突発的にデータが集中する期間もあります。 単純な平均値のBefore/After比較では、これらの外部要因を機材の性能向上と誤認する可能性があります。 【打ち手・使用した技術】 カウントデータの性質を考慮し、Poissonだけでなく過分散を扱えるNegative Binomialモデルを中心に評価しました。 一方、単一モデルの仮定に結論を依存させることも避けるため、Bayesian NB-GLM、頻度論NB-GLM、ノンパラメトリック検定、change-point、外部データによる正規化、距離帯別評価を併用しました。 「最も高度なモデルの結果を正解とする」のではなく、異なる前提を持つ分析結果がどこで一致し、どこで不一致になるかを確認して判断する設計としています。 使用技術：Python、NumPyro、JAX、PyMC、statsmodels、pandas 開発・実装内容B：再現可能なデータ・証拠pipeline 【概要】 統計結果だけを保存するのではなく、「どの入力から、どの処理を経て、その結果になったか」を後から確認できるartifact pipelineを構築しました。 【課題・問題点】 分析コードを変更したり、入力データを追加したりすると、以前生成したグラフや数値がどの条件から生成されたものか分からなくなる可能性があります。 その状態では、分析結果に疑問が生じても再検証できません。 【打ち手・使用した技術】 解析処理を9段階のpipelineとして分離しました。 各stageの出力から、人間が確認するグラフやreportだけでなく、下流処理用のartifact bundleも生成します。 artifactにはSHA-256によるcontent identity、schema validation、provenance/lineageを持たせ、分析結果から入力データまで追跡できる構成としました。 また、一部stageが失敗しても原因を確認できるようfailure-resilient executionとappend-only audit logを採用しています。 使用技術：Python、SHA-256、JSON Schema、SQLite、pandas 開発・実装内容C：複数モデル・AIによる分析結果の統合 【概要】 統計pipelineの出力を複数AIへ提示し、各モデルが生成した主張を比較・レビューするsynthesis layerを実装しました。 【課題・問題点】 大量の統計結果を人間だけで横断確認するには時間がかかります。 一方で、LLMに「どの変更が有効だったか」を直接判断させると、モデルが統計結果を誤読したり、複数モデルの多数決が誤った結論を強化したりする可能性があります。 【打ち手・使用した技術】 LLMを最終判断者ではなく、仮説・論点の抽出器として使用しました。 複数AIの回答をstructured JSONとして取り込み、claim単位に分解。support、counter-evidence、caveat、validation targetを別々に保持し、モデル間の一致・不一致をreviewできるようにしました。 単純なweighted ensemble scoreには統合せず、異なるモデルが異なる判断をした場合は、その不一致自体を情報として残します。 SQLiteではproposition層とclaim層を分離し、元のモデル回答を保持しながら統合判断を管理できる構成にしています。 使用技術：Python、SQLite、structured JSON、複数LLM 開発・実装内容D：テスト・実行環境の再現性確保 【概要】 分析者のローカル環境に依存しない検証経路を整備しました。 【課題・問題点】 統計pipelineは依存ライブラリや実行環境の差によって結果や動作が変化する可能性があります。また、分析コードの変更によって過去の処理が壊れても、手動確認だけでは検出が難しくなります。 【打ち手・使用した技術】 CLIからvalidation、dry-run、artifact verification、synthesis smoke testを実行できるようにしました。 Docker Composeによるtest、validation、synthesis smoke環境を用意し、GitHub Actionsではlint、test matrix、coverage、smoke test、Docker testを自動実行しています。 使用技術：Docker、Docker Compose、GitHub Actions、pytest、Python 【成果】 統計解析、artifact生成、AI向けevidence生成、claim synthesisまでを1つの再現可能なpipelineとして構成しました。 特定の統計モデルやAIの回答だけを正解として扱わず、入力データ、統計結果、モデル判断、それぞれの不確実性を追跡できる評価基盤としています。

プロジェクト経験概要 SREのインシデント調査を支援するAI分析基盤「Ops Evidence Synthesis（OES）」を個人で設計・実装しました。 LLMにログを渡して原因を推測させるのではなく、証拠を固定し、複数モデルの分析結果、反証、不足証拠を整理した上で、最終判断を人間へ戻すことを目的としています。 チーム情報 個人開発、1名。 課題設定、アーキテクチャ設計、Python実装、AI連携、テスト、GCPインフラ構築、Terraform、Cloud Runへの公開まで担当しました。 開発・実装内容A：AIへ渡す証拠とデータ境界の設計 【概要】 実運用ログをAIで分析しつつ、raw logや機密情報を外部へ出さないためのEvidence Pipelineを実装しました。 【どのような機能の開発・実装か】 raw logとsource codeはローカルに保持し、sanitization後のEvidence ItemだけをAI分析へ渡します。 システムの意味やログの解釈についてもAIだけで決定せず、人間が内容を確認・承認したOperational Profileを作成し、分析対象のEvidence BundleとともにSHAで固定する仕組みを実装しました。 【課題・問題点】 LLMによる障害解析では、入力したログやコードの境界が曖昧になると、どの情報を根拠に回答したのか後から確認できません。 また、分析途中で追加情報が暗黙に混入すると、同じ入力から同じ判断過程を再現できなくなります。 【打ち手・使用した技術】 「AIの精度を上げる」前に、「何を根拠としてAIに判断させたのかを固定する」方針を採用しました。 raw dataをローカルでsanitizationし、Evidence Itemへ変換。承認済みProfile、Evidence Bundle、model provenanceをSHAで固定しました。 承認後はsource contextへ再アクセスできない境界も設け、分析途中で証拠条件が変化しないようにしました。 使用技術：Python、SHA-256、JSON Schema、GCS、PostgreSQL、Cloud Run 開発・実装内容B：複数AIによる分析と誤判定防止 【概要】 複数AIが同一証拠を分析し、その結果を比較・検証するincident review pipelineを実装しました。 【どのような機能の開発・実装か】 各AIに同一のEvidence Bundleを入力し、回答にEvidence IDを付与させます。 その後、引用が実際の証拠と対応しているかを検証し、supporting evidence、counter-evidence、missing evidence、モデル間の不一致を保持したままreviewを生成します。 【課題・問題点】 複数AIが同じ原因を回答した場合、多数決で正しいと判断する実装も可能です。 しかし、全モデルが同じ誤った仮説を生成する可能性があり、「5モデルが同意した」という事実は原因を証明するものではありません。 特に障害対応では、誤った原因確定が不要な設定変更や別障害を引き起こす可能性があります。 【打ち手・使用した技術】 モデル間の一致度を「原因である確率」として扱わない設計にしました。 AIは原因を確定する役割ではなく、証拠、反証、不足証拠、次に確認すべき項目を整理する役割としました。 引用検証を行い、Evidence IDに存在しない根拠を使用した回答を検出します。また、証拠不足やモデル間の不一致を消さずにreviewへ残します。 最終的なcause promotionや運用操作はhuman gateを通過しなければ実行できない設計としました。 使用技術：Python、Gemini、Vertex AI、構造化JSON、citation validation、PostgreSQL 【成果】 実際のstream_v3ログ45,000行を入力した評価では、45,000件を再sanitizationし、1,036件のEvidence Itemを生成しました。 5/5 providerからschema-validな分析結果を取得しましたが、自動的に原因確定した項目は0件とし、6件をValidation Targetとして人間の確認対象に残しました。 「AIが答えを出すシステム」ではなく、「AIが判断に必要な証拠を整理し、証拠以上の判断をしないシステム」として動作させています。 開発・実装内容C：GCP上での安全な公開・再現環境 【概要】 開発環境だけでなく、第三者が実際の分析結果と判断過程を確認できる公開環境をGCP上に構築しました。 【課題・問題点】 公開デモで任意のログやURLを入力可能にすると、機密情報の送信、プロンプトコスト増加、不正利用などのリスクがあります。 一方、事前計算した静的画面だけでは、実際にAI処理が動作することを確認できません。 【打ち手・使用した技術】 公開reviewは事前計算した結果をread-onlyで表示し、モデル実行コストを発生させず確認できるようにしました。 別途Fast GCP Reviewを用意し、固定された2,000行のsanitized sampleのみを入力可能にすることで、実際のモデル実行も確認できる構成としました。任意ファイル、URL、ログ入力は受け付けません。 Cloud Build、Artifact Registry、digest固定したCloud Run revision、smoke testを用いてbuild・release経路を構成し、TerraformではCloud Run Job、Cloud SQL、BigQuery、Secret Manager、monitoringなどのproduction構成をコード化しました。 使用技術：Google Cloud Run、GCS、Cloud Build、Artifact Registry、Terraform、Cloud SQL/PostgreSQL、BigQuery、Secret Manager、Python