ID:84718さん

■ プロジェクト経験概要 ADS-B航空機情報と音楽を24時間365日配信するYouTube Live基盤を、個人で設計・開発・運用しています。 主要な信頼性要件は、「障害から復旧した後も、視聴者が同じURLから配信へ戻れること」です。プロセスの稼働だけでなく、公開URL、映像、音声、航空機データ、送信状態を分けて観測し、異常がある箇所に限定して復旧する仕組みを構築しています。 2026年9月11日時点の保持記録では、127日以上にわたる同一YouTube Live URLの維持を確認しています。 継続運用では、複数の自動復旧経路が競合し、新しい処理を追加するだけでは解決できない問題を経験しました。既存コードの依存関係と操作権限を棚卸しし、配信本体、Monitoring v4、Central Restart Authority（以下CRA）へ責務を分離する再設計を進めています。 配信本体は実運用中です。新しい監視・復旧基盤は、実装・自動テストと長時間検証（soak）を進めている段階です。既存配信の運用実績と、新基盤の検証状況は分けて管理しています。 ■ チーム情報・担当範囲 個人開発・個人運用、1名。本業の工場勤務と並行して取り組んでいます。 企画、要件定義、アーキテクチャ設計、実装、テスト、デプロイ、監視、障害解析、運用改善まで一貫して担当しています。第三者音源の導入では、提供者への利用可否の確認、許諾条件の整理、実装・運用への反映も行いました。 開発にはCodex等の生成AIを利用しています。コード探索・実装・テスト作成に活用する一方、AIの回答だけを正しさの根拠にはしていません。要求、不変条件、変更範囲、操作権限、合否判定の条件を定義し、コード・契約・検証基盤へ落とし込んでいます。 ■ 開発・実装内容A：同一URLを維持する配信と、障害箇所に限定した復旧 【課題】 障害時に新しいYouTube Liveを作成すると、既存のリンクや埋め込み先から視聴者が戻れなくなります。配信自体を再開できても、視聴者にとっての継続性は失われます。 また、通信断、FFmpeg停止、映像停止、音声異常、航空機データ停止を同じ障害として扱うと、正常な部分まで再起動し、復旧操作によって影響を広げる可能性があります。 【設計・実装】 「同一の公開URLを維持すること」を、稼働率とは別の守る条件として設定しました。 Python、FFmpeg、ブラウザ描画、音声処理、YouTube APIを組み合わせて配信基盤を構築しました。航空機の可視化にはMapLibreを使用しています。 航空機データの鮮度、描画準備、映像・音声、RTMPS送信、YouTubeの配信状態を個別に観測します。復旧対象も、音声処理、FFmpegの送信プロセス、配信コンテナ、YouTubeの配信状態を分けています。 送信量の低下や古い監視結果だけでは、配信URLの置換や広範囲な再起動へ進まない設計です。単一ホスト中心のv2から、k3sを用いたv3への移行でも同じ公開URLを引き継ぎました。 【成果】 ・2026年5月6日〜9月11日の保持記録から、127日以上にわたる同一の公開動画IDの維持を確認しました。 ・v3移行後の5月28日〜9月11日は、107日分の日次チェックポイントを保持しています。この台帳内で、選択された動画ID・URLの切り替わりは0件でした。 ・28日レビューに含まれるv3区間（5月29日〜6月3日）では、厳密な同一URL正常判定が6,558／6,568件、99.848％でした。 これは同一URLの維持と観測時点の判定結果です。映像・音声が一度も途切れなかったことや、127日間全体の可用性を示す数値とは区別しています。 ■ 開発・実装内容B：TCP stallの原因切り分けと観測粒度の改善 【課題】 RTMPSの送信が止まるTCP stallが繰り返し発生していました。 「YouTubeへの送信が止まった」という症状だけでは、YouTube側、DNS、TCP接続、NAT、WAN回線のどこに問題があるかを区別できません。原因を誤認すると、効果のないエンコーダー調整や不要な配信再作成につながります。 【設計・実装】 原因候補ごとに、「その仮説が正しければ、どの通信が成功・失敗するか」を定義しました。 RTMPSの送信量、未送信データ、未ACKデータに加え、Cloudflare・Google向けの独立したTCP/TLS通信を観測しました。既存接続と新規接続、DNS経由とIP直接接続、IPv4とIPv6を分け、デフォルトルートや外部アドレスの変化も記録しています。 60秒間隔の観測では短い状態遷移を取り逃す事象がありました。そのため、通常は60秒、再発しやすい時間帯は10秒、異常検知後は5秒間隔の追加観測とし、ログ量・負荷と診断粒度を調整しました。 【成果】 複数日にわたり、YouTube以外の既存接続と新規接続も同時に失敗することを確認しました。YouTube単独、DNS単独、既存NATセッションだけの問題という説明を切り分け、WAN/session層の一時障害を最有力と判断しました。 後続の高頻度観測ではIPv6デフォルトルートの一時消失も取得し、route層を含めた分類へ進めました。 宅内ルーター側か通信事業者側かの発生主体は未確定です。確認できた障害層と未確定の原因を分け、根拠のない推測を配信設定や復旧条件へ反映しない運用としています。 ■ 開発・実装内容C：配信・監視・公開の分離とMonitoring v4の開発 【課題】 配信と監視を同じホストに集中させると、配信ホストの停止や負荷上昇によって、障害解析に必要な観測も失われます。 また、状態集約、障害判定、通知、復旧操作が結合していると、一部の変更が別の処理へ波及します。内部監視系をインターネットへ直接公開しないことも必要でした。 【設計・実装】 既存の運用では、ADS-B取得・内部監視、配信、公開ステータス生成を、役割の異なる複数ホストへ分離しました。 Prometheus、Loki、Grafanaはプライベートネットワーク内に保持しています。Raspberry Piが公開を許可した情報だけを取得し、静的スナップショットとしてGCSへ送信します。Cloudflare経由で公開し、公開閲覧者から内部監視系や配信ホストへアクセスを中継しない構成にしました。 新しいMonitoring v4では、観測入力、現在状態、インシデント遷移、通知要求、公開用データ生成を分離しています。監視側は観測事実を提供し、復旧操作の許可・実行権限は持たせない設計です。 複数のk3sワークロードから単一SQLiteファイルを共有する結合を避けるため、PostgreSQLを導入しました。SQLiteは移行・検証・復旧の用途に残しています。 DBへの記録後にプロセスが停止し、公開用ファイルだけが古いまま残る問題にも対応しました。DB更新と公開予定データを同一トランザクションで保存し、未反映のデータを後続処理で照合・再公開する仕組みを実装しています。DBとファイルを一つのトランザクションで更新できるとは仮定せず、途中失敗から整合状態へ戻す設計です。 【成果・現在地】 Monitoring v4の状態管理、通知要求、DB移行、公開データの整合性回復を、設計・コード・テストで確認できる形にしました。 長時間検証では、検証対象と移行元のリビジョン、観測開始時点を固定しています。古い実装の記録を、新しい実装の検証期間に加算しない判定も組み込んでいます。 自動テスト、新旧の観測結果・判定結果の継続比較、本番への全面移行を、それぞれ別の段階として管理しています。 ■ 開発・実装内容D：復旧経路の競合を受けたCRAの設計・実装 【課題】 ローカルとリモートの復旧処理が、それぞれ独立して操作を判断する問題が顕在化しました。 切り替え試験では、別の復旧経路が実行環境を変更し、評価中の対象が失われてロールバックした事象がありました。後の操作台帳の確認では、同じFFmpeg世代を対象とした再起動試行の重複を7組確認しました。 これは、各組の両方が実際にプロセスを終了させたことを示すものではありません。ただし、要求IDごとの重複排除だけでは、別IDで発行された同一対象への要求を防げないことが課題でした。 CRAの新規実装に加え、既存のwatchdog、fast recovery、監視、実行処理に残った操作経路と判断権限を整理する必要がありました。新しいコードを書くことより、既存経路との相互作用を把握し、責務を移す作業が難しい局面でした。 【設計・実装】 復旧処理を次の責務に分けました。 ・Monitoring：観測事実とインシデント情報を提供する。 ・CRA：復旧方針、回数上限、待機時間、操作許可、結果確認を管理する。 ・配信側Executor：許可された特定のFFmpegプロセスだけを操作する。 CRAでは、操作判断と送信予定をローカルDBへ確定してから通信する、トランザクショナル・アウトボックスを実装しました。実行側も、対象と試行の予約を永続化してから操作に進みます。 要求IDに加え、対象の論理世代と操作範囲で実行を制限するfencingを導入しました。異なる要求IDでも、同じ対象への重複試行を制限する契約とテストを設けています。 応答が失われた場合は、「未実行」と決めつけずOUTCOME_UNKNOWNとして保持します。自動再試行を止め、後から得られた証拠を追記して結果を照合します。 ホスト間ではmTLSと署名付きメッセージを使用しています。ホストをまたぐ分散ACIDを前提にせず、ローカルトランザクション、対象識別、権限の有効期限、照合処理を組み合わせた構成です。 【成果・現在地】 観測・許可・実行を分離したCRAの中核実装と、重複要求、古い対象、クラッシュ前後、応答欠落を扱う自動テストを公開しました。 長時間検証は継続中です。公開スナップショットでは本番の復旧権限を無効化しており、CRAによる本番復旧時間の短縮や、重複操作の削減を完了済みの成果としては扱っていません。 ■ 開発・実装内容E：Harness Engineeringによる障害検証の前倒し 【課題】 既存コードの変更範囲が広がるにつれ、コードレビューや生成AIによる事前検討だけでは、状態遷移、永続化、通信、復旧処理の組み合わせに対する見落としが残りました。 soak中に不具合が見つかると、調査・修正に加え、修正後のリビジョンで検証期間を取り直す必要があります。コード生成よりも、変更後の検証とやり直しが、開発全体の所要時間を左右する状態になりました。 【設計・実装】 既存コードの責務・依存関係を整理し、短時間で再現可能な故障条件を、隔離環境で先に検証する工程を設けました。 検証基盤では、次の役割を分離しています。 ・SUT：検証対象となる監視・復旧制御と、その状態保存処理。 ・Injector：指定した境界へ、時間・回数・対象を制限して故障を注入する。 ・Observer：状態、メッセージ、識別子、時刻、終了結果などの証拠を記録する。 ・Oracle：事前に定義した不変条件と観測証拠を照合し、合否を判定する。 Oracleは、SUTの判断実装をそのまま呼び出して正解を作らない構成にしました。意図的に禁止状態を作るNegative Controlも用い、判定側がその違反を検出できるかを確認しています。 故障注入では、応答欠落、古い状態、重複要求、部分書き込み、永続化と操作の間のクラッシュなどを扱います。注入の要求だけでなく、故障条件が実際に発生したか、試験後に対象を片付けられたかも記録します。 判定は、対象システムの不具合、Harness自身の不具合、証拠不足、結果不明を区別します。故障が発生していない試験や証拠が足りない試験を、対象システムが耐えたという成功には数えない設計です。 再現条件、シナリオID、対象リビジョン、実行ID、観測証拠を関連付け、確認した不備を回帰テストとして残しています。 【成果・現在地】 Monitoring v4の状態遷移を連続して試す検証で、次の保存処理の不備を再現・修正しました。 ・同一時刻の状態変更が、スナップショットIDの並び順によって拒否される問題。 ・期限切れの現在状態が、鮮度条件を満たす代替候補への切り替えを妨げる問題。 修正前の再現条件、原因、修正後の再実行、保存処理と状態遷移の回帰テストを保持しています。 公開CIでは、配信本体、Monitoring v4、CRAを別ジョブで検証します。非公開証拠や専用の外部環境が必要な試験は、公開CIの実行対象と区別しています。 目的はsoakの必要期間を省略することではありません。事前に再現できる不具合を前段で見つけ、長時間検証のやり直しを減らすことです。開発効率の改善を実感していますが、soak失敗回数と総所要時間の削減率は未計測です。 ■ 開発・実装内容F：音源提供者との利用条件の確認と、配信・運用への反映 【課題】 配信で新しい音源を採用する際、再生機能を追加するだけでは公開運用を継続できません。提供元によって利用条件、クレジット要件、音量が異なるため、既存音源と同じ前提で扱わないことが必要でした。 許諾内容を個人の記憶ややり取りの履歴だけに残すのではなく、配信の設定変更や音源追加でも守れる形にすることを課題としました。 【外部との確認・条件整理】 音源提供者Floracoreへ、このYouTube Liveでの利用可否を確認し、クレジット表記を条件とした許諾を取得しました。 既存のNCS音源の利用条件と、Floracoreから個別に得た許諾を分けて管理しています。確認した利用範囲を、音源の再配布、別プラットフォーム、別チャンネルでの利用まで認められたものとは扱っていません。 YouTube説明欄へのクレジットを継続して守る運用要件とし、配信画面の提供元表示はその補足として位置付けました。 【実装・運用への反映】 音源の導入スクリプトはdry-runを既定とし、クレジットの準備を確認したことを操作者が明示しなければ、本適用できない仕組みにしました。この条件を満たさない導入が拒否されることをテストしています。 配信画面では、再生中の提供元に応じてNCSとFloracoreの表示・クレジットを切り替えます。夕方の時間帯はFloracoreの選曲枠とし、他の時間帯とは再生対象を分けました。 提供元間の音量差は、元の音源ファイルを変更せず、再生時の固定gainで補正する構成にしています。曲ごとの音量が完全に均一になる仕組みとは区別しています。 さらに、提供元、利用先、クレジット、再生設定を変更する場合の再確認事項を文書化しました。 【成果】 音源提供者への利用確認と許諾取得から、条件整理、導入時の確認、クレジット表示、再生設定、継続運用のルールまで一貫して担当しました。 外部との確認結果を文書に残すだけでなく、実際の導入手順と実装・テストへ対応付けました。技術面だけで完結させず、第三者との合意条件を満たした形で公開サービスを運用する経験になっています。 ■ 主な使用技術 Python、JavaScript、FFmpeg、MapLibre GL JS、YouTube API、Docker、k3s/Kubernetes、Linux/systemd、PostgreSQL、SQLite/WAL、Prometheus、Loki、Grafana、GCS、Cloudflare、JSON Schema、SHA-256、Ed25519、mTLS、pytest、unittest、GitHub Actions ■ 公開範囲・参考資料 公開リポジトリ： 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 公開版には、配信本体、Monitoring v4、CRAの設計・実装・テストと、運用・検証記録の要約を含めています。説明から対応するコード・テストへ進めるレビュー用の導線を用意しています。 本番の認証情報、運用DB、生ログ、音源、許諾に関する私的なやり取りは公開していません。実測済みの運用結果、隔離環境での検証結果、実装済みの機能、検証中の項目を区別して記載しています。 記載基準：2026年9月11日 公開ソース確認時点：cf5702847ed559532a283da99bf93c549ecb42f2

プロジェクト経験概要 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

プロジェクト経験概要 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の回答だけを正解として扱わず、入力データ、統計結果、モデル判断、それぞれの不確実性を追跡できる評価基盤としています。