第2章：起点記事から学べること

たとえ話

料理に例えると、「おいしい刺身をAIに渡すには、先に包丁で食べやすい形に切っておく」必要があります。
生の丸ごと1本（生ログ全部）を渡すと、量・毒（秘密情報）・見た目のばらつきで困ります [S01]。

本資料の調査の出発点は、次の2本です（エアークローゼット CTO による実践報告）[S01][S02]。

ここでは長文の抜き書きはしません。企業向けに「安全に落とす」ための読み方を書きます。

AIの前に形を整える
生ログをそのまま渡すと、量で埋まって、エラーと正常が区別しづらく、メトリクスやトレースともつながりません [S01]。
全部を同じ箱に入れない
「いまいくら？」と「先月のチーム別合計」は問いが違う。道具も分けた方が楽、というのが設計編の核心です [S01]。
CIログは本番アプリと同じ場所で探せるようにする（例）
「毎回GitHub画面だけ見る」より、構造化して横断検索できるとAIも人間も楽、という実践例です [S01]。
PIIはAIで新しい抜け道になる
以前はDB権限がある人だけが触れがちだった個人情報が、ログ→AI経由で広がる可能性があります [S02]。
自動修復の上限は観測の入口
errorの定義やstacktrace（呼び出し履歴）が無いと、どれだけ賢いAIでも止まります [S02]。

用語: CI＝Continuous Integration（継続的インテグレーション）。変更のたびにテスト等を自動実行する開発側の仕組み。
本番監視＝ユーザーや業務への影響を見る仕組み。目的が違います。

起点記事には「CIが通れば bot が自動マージ」する例もあります [S02]。それはその組織の前提付きの成功例です。
一般企業向けの本資料では、修正PRを作ることと、マージ／本番反映することを分けます。

記事を読んだあと、次の表をチームで埋めます。埋まらない行は「まだ真似しない」側に置きます。

記事のヒント	自社で採用？	必要な前提／ゲート
問い別にデータ置き場を分ける	Yes / No / 一部	既存保管先・コスト上限
CIログを横断検索可能にする	Yes / No / 一部	秘匿・保持期間
PIIを信頼境界として設計	（原則Yes）	マスク方針の文書化（第12章）
CI成功→自動マージ	（原則保留）	本番反映と分離、承認WF
観測品質を自動修復の前提にする	Yes	error / stacktrace 必須化

成功条件は「記事を要約できた」ではなく、Yes行の次アクションとNo行の理由が1枚に残ることです。

運用担当者本番のアラームとCI失敗通知の宛先・手順を分けて書けるか

PGPRでerror処理・stacktrace・event_codeを確認する

SEPRレビュー項目をチーム標準とCIチェックへ組み込む

PM成功事例のコピーではなく、自社の承認ゲートに合わせる

経営層「他社が自動修復している」＝自社も即フル自動、ではない