「この障害って半年前の、あのプロジェクトと同じ原因ですよね？なぜ防げないんですか？」を終わらせる〜Reusable Workflows x Claudeで実装するプロジェクトを横断する障害防止戦略〜

by tom

Embed

Start on current slide

Slide 1

Slide 1 text

Slide 2

Slide 2 text

鈴木斗夢 Tomu Suzuki PLAY, inc. モバイルエンジニア ― 動画配信基盤を開発する会社 2024 PLAY 入社大規模動画配信サービスの iOS / Android アプリを開発・保守パーソルパ・リーグTV / WOWOW オンデマンドなど 2026 AI タスクフォース開発プロセス改善チームリーダー自動コードレビューの全社リポジトリ展開、仕様駆動開発、Docs as Code の仕組み化など、AIを活用した組織全体の開発生産性の向上に注力 copyright (c) 2026 - PLAY, inc. 2 / 80

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

なぜ防げない? チームは複数案件を掛け持ち 👤 Aさん 👤 情報共有はチーム MTG と Slack にしかない案件 A 先月 targetSdk 34 で foreground service の… 案件 B 2ヶ月前 R8 で release だけ落ちる件、解決案件 C Bさん 👤 Cさん全員が全リポジトリを見るのは不可能 copyright (c) 2026 - PLAY, inc. 案件 D 3ヶ月前 Room の Migration 漏れでデータ消えた… 案件 E …×15 古いものから沈み、薄れて、消えていく 5 / 80

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

当時の AI コードレビューの仕組みリポジトリごとにドメイン知識を MD ファイルで用意 .github/instructions/ 01_XXX.instructions.md 02_XXX.instructions.md 03_XXX.instructions.md 04_XXX.instructions.md 05_XXX.instructions.md PR を作成案件ごとに作成した MD ファイル Copilot が起動ドメイン知識 (MD) を読んでコードレビュー PR をすると Copilot がドメイン知識 (MD ファイル) を読んでコードレビュー copyright (c) 2026 - PLAY, inc. 10 / 80

Slide 11

Slide 11 text

共通障害ファイルを AI コードレビューのコンテキストにリポジトリごとにドメイン知識を MD ファイルで用意 .github/instructions/ 01_XXX.instructions.md 02_XXX.instructions.md 03_XXX.instructions.md 04_XXX.instructions.md 05_XXX.instructions.md PR を作成案件ごとに作成した MD ファイル New 06_COMMON_INCIDENT.instructions.md Copilot が起動 (共通障害ファイル) ドメイン知識 (MD) を読んでコードレビュー Copilot が共通障害ファイルも読んでコードレビュー copyright (c) 2026 - PLAY, inc. 11 / 80

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Reusable Workflows とは GitHub Actions の公式機能ワークフローから別のワークフローを、関数のように呼び出せる呼び出し側定義側関数を呼ぶ側関数を定義する側 uses で呼ぶ jobs: on: fanout: workflow_call: uses: 定義側 yml のパス jobs: # 再利用したい処理呼び出し側は uses で指定し、定義側は on: workflow_call で受ける出典: GitHub Docs「Reuse workflows」 copyright (c) 2026 - PLAY, inc. 19 / 80

Slide 20

Slide 20 text

Reusable Workflows を動かすリポジトリ構成中央リポジトリ/ ├─ COMMON_INCIDENT_ANDROID.md 共通障害ファイルの原本 ― 障害の知見はここに集まる └─ .github/ └─ workflows/ ├─ distribute-on-merge.yml マージを検知して15リポジトリ分呼び出す(呼び出し側) └─ _distribute-incidents.yml 1リポジトリへ PR を出す処理の本体(定義側) 原本1つと、配るためのワークフロー2本 ― これだけ copyright (c) 2026 - PLAY, inc. 20 / 80

Slide 21

Slide 21 text

呼び出し側ワークフローの中身 1 2 3 4 # 呼び出し側: distribute-on-merge.yml(配信の起点) on: push: branches: [main] paths: ["COMMON_INCIDENT_ANDROID.md"] permissions: # GITHUB_TOKEN の権限 contents: read jobs: fanout: strategy: matrix: include: - { repo: 案件 A } # …計15行 uses: ./.github/workflows/_distribute-incidents.yml with: target_repo: ${{ matrix.repo }} secrets: # App の ID と秘密鍵を名前指定で渡す copyright (c) 2026 - PLAY, inc. 1 いつ動く? 原本が main にマージされた時だけ on: push + paths で限定 2 配信先を増やすには? matrix に1行足すだけ 3 何をする? 配信先リスト(matrix)の数だけ定義側ワークフローを呼ぶ自分では PR を出さない ― 呼ぶだけ 4 何を渡す? with: で引数、secrets: で鍵を定義側へ手渡す 21 / 80

Slide 22

Slide 22 text

定義側ワークフローの中身 1 2 3 # 定義側: _distribute-incidents.yml on: workflow_call: inputs: # 配信先リポジトリ secrets: # App の ID と秘密鍵 jobs: distribute: steps: # 1. App トークンを発行 # 2. 原本から配信ファイルを生成 # 3. 案件リポへ同期 PR を作成 1 いつ動く? 呼ばれた時だけ動く on: workflow_call が入口 ― 自分からは起動しない 2 何を受け取る? 引数(配信先リポと platform)と鍵(App の ID と秘密鍵) 呼び出し側から手渡されたものだけ使える 3 何をする? トークンを発行 → ファイルを生成 → 案件リポへ同期 PR 「1リポジトリへ配る」処理の本体 copyright (c) 2026 - PLAY, inc. 22 / 80

Slide 23

Slide 23 text

初回だけのセットアップ ― GitHub App と secrets 他リポジトリへ PR を出すには、bot(GitHub App)の書き込み権限が必要 ① GitHub App を作成 ② 案件 org にインストール ③ 中央リポに secrets 登録組織で bot を1回だけ作る権限は2つだけ Contents: write Pull requests: write 作成すると ID と秘密鍵が発行される bot に自分の org への書き込みを許可する操作 APP_ID(識別番号) APP_PRIVATE_KEY(秘密鍵) これで中央からの同期 PR を bot 名義で受け取れる配信ワークフローがこの2つで書き込み用トークンを発行する secrets は処理を実行する側に、App のインストールは書き込まれる側にこの3つは最初に1回だけ ― 案件を増やすときの追加作業はゼロ copyright (c) 2026 - PLAY, inc. 23 / 80

Slide 24

Slide 24 text

Slide 25

Slide 25 text

共通障害ファイルを配信する作業コストが15分の1に ① 中央リポの共通障害ファイルに追記 PR ② マージが配信を起動 ③ 15案件に同期 PR ×15 Merged Open #123 ⚙ Distribute Incidents on Merge [INC-YYYY-NNNN] Room マイグレーション欠落を追記 ✓ fanout 15 jobs COMMON_INCIDENT_ANDROID.md +12 👤 人がレビューしてマージ呼び出し側 → 定義側 ×15 案件リポ A chore: sync COMMON_INCIDENT from 中央リポジトリ 🤖 bot 名義で自動作成 1箇所の更新のみで15リポジトリに配信数分後には、15リポジトリすべてに同じ内容の同期 PR が並ぶ copyright (c) 2026 - PLAY, inc. 25 / 80

Slide 26

Slide 26 text

Slide 27

Slide 27 text

呼び出し側から定義側への、この鍵の手渡し 1 2 3 4 # 呼び出し側: distribute-on-merge.yml(配信の起点) on: push: branches: [main] paths: ["COMMON_INCIDENT_ANDROID.md"] permissions: # GITHUB_TOKEN の権限 contents: read jobs: fanout: strategy: matrix: include: - { repo: 案件 A } # …計15行 uses: ./.github/workflows/_distribute-incidents.yml with: target_repo: ${{ matrix.repo }} secrets: # App の ID と秘密鍵を名前指定で渡す copyright (c) 2026 - PLAY, inc. ④ で出てきた secrets の手渡しこの渡し方は複数ある。 27 / 80

Slide 28

Slide 28 text

secrets の渡し方 ― 全渡しか、名前指定か secrets: inherit(全渡し) ― 1行で楽。さて、どちらで書く? 全渡し secrets: inherit 名前指定 ― 本システムで採用 secrets: app_id: ${{ … }} app_private_key: ${{ … }} secrets: inherit 渡るもの: 見える secrets 全部署名鍵 AWS Store Slack App鍵 1行で楽。でも org の鍵まで丸ごと渡る後から secrets が増えても、黙って渡り続ける copyright (c) 2026 - PLAY, inc. … 渡るもの: この2件だけ APP_ID APP_PRIVATE_KEY 何の鍵を使うかが yml に明文で残る = レビューや監査で追える 28 / 80

Slide 29

Slide 29 text

配信は丸ごとコピーして、差分がある時だけ PR にする最初の実装は、全案件の PR に謎の空行コミットを配信してしまった最初の実装 ― 既存ファイルに切り貼り追記今の実装 ― 丸ごとコピーマーカーで挟んで、既存 instructions に追記再実行のたびに空行が1行増える専用ファイルを新設して丸ごと配信加工しない = 壊れる余地がない実際に全案件へ届いた diff: (空行だけの追加) + 差分ゼロなら何もしない (静かに終わる) 変更がある時だけ、同期専用の PR 人の PR を汚さない全 PR の push で起動し、PR ブランチに直接コミット → 案件側から修正依頼 copyright (c) 2026 - PLAY, inc. 29 / 80

Slide 30

Slide 30 text

matrix が生む15ジョブ ― 1つ失敗したら、残りは? 1 2 3 4 # 呼び出し側: distribute-on-merge.yml(配信の起点) on: push: branches: [main] paths: ["COMMON_INCIDENT_ANDROID.md"] permissions: # GITHUB_TOKEN の権限 contents: read jobs: fanout: strategy: matrix: include: - { repo: 案件 A } # …計15行 uses: ./.github/workflows/_distribute-incidents.yml with: target_repo: ${{ matrix.repo }} secrets: # App の ID と秘密鍵を名前指定で渡す copyright (c) 2026 - PLAY, inc. ② の matrix(配信先リスト) 一覧の数だけジョブが自動生成されて、同時に走るでは、15ジョブのうち 1つが失敗したら、残りは? 30 / 80

Slide 31

Slide 31 text

fail-fast ― 1案件のミスで全滅させない matrix の15ジョブ ― 3番目のリポで配信が失敗すると? fail-fast: true (デフォルト) ✓ ✓ ✕ －－－－－－－－－－－－ ✓ ✓ 失敗した時点で、実行中・待機中の残りジョブが全てキャンセル(完了済みだけが残る) fail-fast: false (本システムで採用) ✓ ✓ ✕ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ 失敗はそのリポだけに隔離 ― 14リポは完走。失敗分だけ後から再配信すればよい明示しないと true ― 1案件の設定ミスが、残りの案件への配信を道連れにする copyright (c) 2026 - PLAY, inc. 31 / 80

Slide 32

Slide 32 text

fail-fast: false は、strategy に1行 # 呼び出し側: distribute-on-merge.yml jobs: fanout: strategy: fail-fast: false # ← この1行を足すだけ max-parallel: 4 matrix: include: - { repo: 案件 A, platform: android } uses: ./…/_distribute-incidents.yml 置き場所は matrix と同じ strategy: の直下これで失敗はそのリポだけに隔離され、残り14リポは完走するデフォルトのままにしない ― ファンアウトする matrix には必ず明示する copyright (c) 2026 - PLAY, inc. 32 / 80

Slide 33

Slide 33 text

PAT ではなく App ― 人に紐づく鍵を仕組みに使わない個人の PAT でも動く ― 違いは「鍵が誰に紐づいているか」個人 PAT ― 鍵が個人アカウントと紐付く 🔑 退職で線ごと消える退職・失効の瞬間、全案件の配信が突然止まる 👤 個人 GitHub App ― 鍵は org の持ち物 🔑 人が替わっても切れない 🏢 org 担当者が辞めても、仕組みは動き続ける権限は本人が触れる範囲すべて PR も個人名義になる仕組みの鍵は、人ではなく組織に持たせる copyright (c) 2026 - PLAY, inc. 33 / 80

Slide 34

Slide 34 text

Slide 35

Slide 35 text

共通障害ファイルは Copilot の instructions フォルダに入れる .github/instructions/ 01_XXX.instructions.md 02_XXX.instructions.md 03_XXX.instructions.md 04_XXX.instructions.md 05_XXX.instructions.md New 06_COMMON_INCIDENT.instructions.md 入れるだけで、次の PR から共通障害ファイルが指摘の根拠になる copyright (c) 2026 - PLAY, inc. 35 / 80

Slide 36

Slide 36 text

Copilot レビューのコンテキストとして入れるコツ冒頭でお見せした、案件リポジトリの instructions フォルダ .github/instructions/ 01_XXX.instructions.md 02_XXX.instructions.md 03_XXX.instructions.md 04_XXX.instructions.md 05_XXX.instructions.md その 1 ファイルの中身 ― 先頭に frontmatter --applyTo: "**" excludeAgent: "cloud-agent" --## 共通障害ファイル (以下、レビュー観点を Markdown で記述) applyTo: 効かせるファイルを glob で指定("**" = 全ファイル) excludeAgent: コーディング用途を除外しレビュー専用に先頭の frontmatter で、どのファイルに・どの用途で効かせるかを制御できる copyright (c) 2026 - PLAY, inc. 36 / 80

Slide 37

Slide 37 text

Copilot が共通障害ファイルを根拠に指摘してくる C Copilot AI review · いつもの案件の、いつもの PR で fallbackToDestructiveMigration() が追加されています。社内共通障害ファイル INC-YYYY-NNNN「Room マイグレーション欠落」に記録された既知障害のパターンです。Migration の実装を検討してください。参照: .github/instructions/06_COMMON_INCIDENT.instructions.md 半年前の障害情報から PR に指摘が入る copyright (c) 2026 - PLAY, inc. 37 / 80

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Slide 50

Slide 50 text

共通障害ファイルを育てる主体を、人から AI へ人交代案件リポジトリ内の開発 PR を共通障害なら自動 PR Claude が解析 COMMON_INCIDENT_ANDROID.md 育てる主体を人から AI へ Copilot コードレビューのコンテキストに copyright (c) 2026 - PLAY, inc. 共通障害ファイル配信 (Reusable Workflows) 案件リポジトリ × 15 マージ 50 / 80

Slide 51

Slide 51 text

起点は案件リポジトリでマージされた PR ― closed + merged の2段構え # 各案件リポ: .github/workflows/detect-incident.yml on: pull_request: types: [closed] jobs: detect: if: github.event.pull_request.merged == true uses: your-org/your-repository /.github/workflows/_detect-incident.yml@main secrets: anthropic_api_key: ${{ secrets.… }} copyright (c) 2026 - PLAY, inc. 51 / 80

Slide 52

Slide 52 text

Reusable Workflows で org を跨いで呼び出す中央リポジトリ案件リポジトリ × 15 呼び出し側 ― detect-incident.yml PR マージを検知して、中央を呼ぶだけ uses: your-org/your-repository 定義側 ― _detect-incident.yml 呼び出し共通障害かどうかの判定を実行中央に置くのは2ファイルだけ /.github/workflows/ _detect-incident.yml(受け口) _detect-incident.yml@main detect_incident.py(判定本体) 同じ判定処理を15リポジトリに置くこともできる ― ただし直すたびに15箇所ロジックは中央に1つ。呼び出し側が増えても、直すのは1ヶ所 copyright (c) 2026 - PLAY, inc. 52 / 80

Slide 53

Slide 53 text

org を跨いで呼ぶための3つのポイント 1 同一 enterprise 配下であること 2 呼ばれるリポジトリ(中央リポジトリ)が internal 設定 3 Actions の Access 設定で許可 enterprise の外からは呼び出せない中央リポジトリの Settings > Actions > General > Access で許可 copyright (c) 2026 - PLAY, inc. 53 / 80

Slide 54

Slide 54 text

Slide 55

Slide 55 text

ほとんどの PR は、障害と無関係 feat: 視聴履歴の一覧画面を追加 chore: ライブラリの依存を一括更新 fix: 番組詳細の文言修正 refactor: プレイヤー周りの整理 ✓ fix: 再生停止の不具合 ― 再発しうる障害パターン ← 載せるべきはこれだけ test: 課金フローのテスト追加 feat: お知らせバナーの出し分け必要なのは書く仕組みではなく、仕分ける仕組み copyright (c) 2026 - PLAY, inc. 55 / 80

Slide 56

Slide 56 text

仕分ける仕組みは、中央の定義側の中中央リポジトリ案件リポジトリ × 15 定義側 ― _detect-incident.yml 呼び出し側 ― detect-incident.yml PR マージを検知して、中央の定義側ワークフローを呼ぶ uses: your-org/your-repository /.github/workflows/ _detect-incident.yml@main copyright (c) 2026 - PLAY, inc. 呼び出し共通障害かどうかの判定を実行中央に新設するのは2ファイル: _detect-incident.yml(受け口) detect_incident.py(判定本体) 56 / 80

Slide 57

Slide 57 text

定義側の中身は「受け口」と「判定本体」の2ファイル案件リポジトリから呼ばれる _detect-incident.yml ― 受け口 secrets を受け取り、判定スクリプトを起動する ― それだけ起動 ― PR 情報と鍵を渡す detect_incident.py ― 判定本体 1 マージされた PR の情報と、既存の共通障害ファイルを集める 2 Claude に「共通障害か?」を判定させる 3 共通障害なら、中央の共通障害ファイルへ候補 PR を作成ワークフローは配線だけ ― 判定のロジックは Python で実行 copyright (c) 2026 - PLAY, inc. 57 / 80

Slide 58

Slide 58 text

判定は3段構え ― 共通障害だけを通すフィルター ① 除外条件 bot の PR・差分なしを機械的に捨てる ― Claude を呼ぶ前に ② 重複チェック既存共通障害ファイルの全タイトル+冒頭をプロンプトに同梱し、既出なら止める ③ 重要度判定影響の大きさ × 再現性 × 学習価値 ― 3条件の AND で足切り通過するのは他の案件も踏み得る Android 障害だけ copyright (c) 2026 - PLAY, inc. 58 / 80

Slide 59

Slide 59 text

Android 障害の典型パターンを、判定基準としてプロンプトに載せる # 判定プロンプト(Android 固有基準の抜粋) 採用しやすい例(Android 固有の判定補足): - Room / DataStore のマイグレーション漏れ - Activity / Fragment ライフサイクル起因のクラッシュ - ProGuard / R8 の keep ルール漏れ - 社内 SDK・自社基盤に固有の障害パターン - EncryptedSharedPreferences / Keystore の誤用 - WorkManager / Coroutine / Flow の誤用迷ったら false ― 価値の高い事例だけを厳選 copyright (c) 2026 - PLAY, inc. 判定のものさしを Android の語彙で与える — 一般論の「重要そう」ではなく OS 固有の地雷リストで判定 — このリスト自体がチームの資産になる 59 / 80

Slide 60

Slide 60 text

最初のプロンプトは、Renovate の PR を障害だと言い張った ✗ 初期版 ✓ 改善版ライブラリ一斉更新の PR を bot 除外+差分なしスキップを追加「重大な非互換の兆候」と誤判定重要度判定を 3条件 AND に強化検証段階でノイズ PR が複数発生ノイズはほぼゼロに除外条件は机上で設計したものではなく、誤判定の失敗から生まれた copyright (c) 2026 - PLAY, inc. 60 / 80

Slide 61

Slide 61 text

判定結果は JSON で受け取り、そのまま共通障害ファイルへ整形する # Claude からの出力例(Tool Use でスキーマを強制) { "is_common_incident": true, "severity": "high", "title": "Room マイグレーション欠落による…", "phenomenon": "アップデート後にデータが失われ得る", "cause": "Migration 未実装のまま schema 変更", "prevention": "Migration テストを CI に追加…", "detection": "fallbackToDestructive… の使用" 自由文で返させない — 「JSON で返して」と頼まず Tool Use のスキーマで強制 — API が適合を保証するのでパース失敗が構造的に消える } copyright (c) 2026 - PLAY, inc. 61 / 80

Slide 62

Slide 62 text

ここからは ― ある日の普通の PRが共通障害ファイルを育てるフロー Merged fix: 動画再生画面の復帰時クラッシュを修正 developer-a が develop へマージ · 案件 A リポジトリ Fragment の onViewCreated で binding 参照が null になるケースを修正開発者は何も特別なことをしない ― いつも通りマージするだけ copyright (c) 2026 - PLAY, inc. 62 / 80

Slide 63

Slide 63 text

マージの数分後 ― 共通障害ファイルへの PR が自動で立つ Open chore: 共通障害を追加 ― Fragment binding 参照 your-sync-app[bot] が your-org/your-repository に作成元 PR: 案件 A の障害修正 PR ― Claude 判定: is_common_incident = true 共通障害ファイルが自分で育った瞬間 copyright (c) 2026 - PLAY, inc. 63 / 80

Slide 64

Slide 64 text

現象・原因・再発防止策まで、構造化されて届く ### [INC-YYYY-NNNN]【ライフサイクル】 Fragment の binding 参照重大度: high 現象: バックグラウンド復帰時に NPE でクラッシュ原因: onDestroyView 後も binding を保持し、破棄済み View を参照再発防止策: viewLifecycleOwner スコープで参照する検出方法: onViewCreated 外での binding 直接参照元事例: 案件 A の障害修正 PR copyright (c) 2026 - PLAY, inc. 64 / 80

Slide 65

Slide 65 text

共通障害ファイルへのマージが、 15リポジトリへの配信を起動する ✓ distribute / 案件 A 34s ✓ distribute / 案件 B 31s ✓ distribute / 案件 C 36s ✓ distribute / 案件 D 29s … ほか 11 リポジトリ、すべて成功 instructions が15ヶ所で同時に更新される copyright (c) 2026 - PLAY, inc. 65 / 80

Slide 66

Slide 66 text

後日、別の案件の PR で ― ループが一周した C Copilot AI review · 案件 B の新規画面 PR で lateinit var binding が Fragment で宣言されています。社内共通障害ファイル INC-YYYY-NNNN(Fragment の binding 参照)の再発パターンです。 viewLifecycleOwner スコープでの参照に変更を検討してください。参照: .github/instructions/06_COMMON_INCIDENT.instructions.md 案件 A の失敗が、案件 B の障害を未然に止めた copyright (c) 2026 - PLAY, inc. 66 / 80

Slide 67

Slide 67 text

Slide 68

Slide 68 text

Slide 69

Slide 69 text

Slide 70

Slide 70 text

AI に読ませる量を増やさない 1 instructions は短い宣言文が最も効く 2 エントリは要点だけ ― 現象・原因は OS の一般語彙で1〜2文 3 膨張は前提 ― 将来は原本と配信版を分離する長文を注入するほど1件あたりの指示の効きは薄まっていく画面名・機能名を削るから、他案件がそのまま照合できる不変 ID(INC-)と重大度を今から記録済み ― 配信版を重大度で絞り込む準備 copyright (c) 2026 - PLAY, inc. 70 / 80

Slide 71

Slide 71 text

Slide 72

Slide 72 text

Slide 73

Slide 73 text

例 Room マイグレーション欠落現象: アップデート後の初回起動でローカルデータが失われ得る原因: Migration 未実装のまま schema 変更。 fallbackToDestructiveMigration() が本番でテーブルを再生成再発防止策: - fallbackToDestructiveMigration() の使用を原則禁止検出方法: version = の変更が Migration 追加なしで入っていたら要指摘 copyright (c) 2026 - PLAY, inc. 73 / 80

Slide 74

Slide 74 text

うちの案件の話を削ぎ、Android の話だけを残すプロジェクト固有の文脈は書かない画面名・機能名は消し、API とライフサイクルの言葉に置き換える再現条件を Android の一般語彙で書く「targetSdk 34 以上で」「プロセス再生成時に」― 他案件がそのまま照合できる対策はコードで示すスローガンではなく、参照できる修正パターンまで書く copyright (c) 2026 - PLAY, inc. 74 / 80

Slide 75

Slide 75 text

導入後 ― 障害情報は、自動で集まり続けている Claude が判定・起票自動で集まる共通障害なら自動 PR マージ差分を解析 COMMON_INCIDENT_ANDROID.md 今日も自動で回っている案件リポジトリ ×15 日々の PR と障害 copyright (c) 2026 - PLAY, inc. 共通障害ファイル Reusable Workflows 各リポへ配信配って防ぐ 75 / 80