AI-005

AI変更来歴記録

分類:AI DELIVERY実物サンプルあり

これは何か

AI変更来歴記録は、AI が行ったプログラムや設定の変更について、「誰が頼んだか」「どんな指示だったか」「AI がどこを変えたか」「人がどう確かめ、誰が承認したか」を、変更 1 件ごとに結びつけて残した成果物です。

AI-003 AI変更実行記録 が「AI が実行した作業の記録」なら、この成果物は「本番の変更を起点に、AI の関与をさかのぼれる来歴」です。世界で共有されている考え方では、物の由来をたどれる記録を「プロビナンス(来歴)」と呼びます。AI が書いたものと人が書いたものが混ざる開発では、来歴がないと「なぜこうなっているか」を誰も説明できなくなります。

なぜ作るか

誰が使うか・いつ作るか

CASE FACTFROZEN正本に記載されたアステリア案件の事実

AI の変更に関係する記載

  • AI活用あり。システムに SYS-10 AI開発エージェント、SYS-09 開発・CI/CD基盤 がある
  • AIは意思決定責任者ではない。人間が管理する作業実行・支援手段とする
  • AIへ最終委任しない事項:投資承認、要件確定、設計承認、セキュリティ例外承認、本番移行承認、Go / No-Go、重大障害判断
  • 成果物に AI-001 AI開発利用方針、AI-002 AIエージェント権限表、AI-003 AI変更実行記録 がある
  • P-013 木村 亮 — AIガバナンス責任者

アステリア案件で AI がどの変更を行い、誰が確かめ、承認したかは、正本に記載がありません。未確定

主な項目

一般的には、AI が関与した変更 1 件ごとに次の項目を結びつけます。

  1. 変更の識別:合流の識別子、含まれるリリース、本番に出た日時
  2. 頼んだ人と目的:誰が、どの課題や要件のために頼んだか
  3. 指示:AI に渡した指示(目的・触ってよい範囲・触ってはいけないもの・終わりの条件・確かめ方)。指示そのものを保存するか、保存場所を参照する
  4. AI の実行:使った AI の種類と版、与えた権限、実行の日時(AI-003 AI変更実行記録 への参照)
  5. 変更の範囲:AI が変えた場所の一覧と、頼んだ範囲との照合結果(範囲内か、範囲外があったか)
  6. 人の確認:誰が変更を読んだか、どのテストを人が確かめたか、AI の説明をそのまま信じていないか
  7. 承認:誰が、いつ、何を根拠に合流・配布を承認したか
  8. 事後:その変更に起因する不具合や差し戻しがあれば、その参照

教材用サンプル成果物の読み方を学ぶための例

教材用サンプル — 1 件の来歴と、範囲の照合

この成果物は学習用サンプルです。FROZEN正本に記載されたCASE FACTと、成果物の読み方を学ぶための教材用サンプル値を区別して表示しています。

次の表は、来歴の書き方を学ぶための例です。内容はすべて教材上の架空の例で、アステリア案件の記録ではありません。

項目(教材上の例) 内容
変更の識別 合流 #4821、リリース R-23、本番反映 今月 12 日
頼んだ人と目的 新基幹の開発者 A。課題「請求書の日付の表示形式を統一する」
指示 目的:日付の表示形式を統一。触ってよい範囲:請求の画面の表示処理。触ってはいけないもの:計算処理、データベースの定義、設定。終わりの条件:表示のテストが合格。確かめ方:表示のテストと、人が画面で確認
AI の実行 AI 開発エージェント(版 3.2)、権限:作業用の枝への書き込みのみ。実行記録 #AIX-0917
変更の範囲 変えた場所:表示処理の 3 か所、表示のテストの 2 か所。範囲外:なし(照合は自動)
人の確認 開発者 B が変更を読んだ。表示のテストの結果を自動の流れで確認。画面での確認は開発者 A
承認 開発リーダー C が今月 11 日に合流を承認。根拠:範囲内、テスト合格、2 人の確認
事後 不具合なし
照合の結果(教材上の例) 意味 次にすること
範囲内 変えた場所がすべて「触ってよい範囲」に入っている 通常のレビューへ
範囲外あり 「触ってはいけないもの」や指示にない場所が変わっている 合流を止め、頼んだ人と承認者が内容を確認。理由が正当なら指示を直して記録、正当でなければ差し戻し
照合できない 指示に範囲が書かれていない 指示の書き方を直してやり直す(範囲のない指示は受け付けない決まりにする)

読み方

  1. 本番の変更から、頼んだ人・指示・AI の実行・人の確認・承認が 1 本の線でつながっているか
  2. 「変更の範囲」と「頼んだ範囲」の照合が自動で行われ、結果が残っているか
  3. 人の確認が「AI の説明を読んだ」ではなく「変更そのものを読んだ」「テストの結果を自分で見た」になっているか
  4. 承認の根拠が書かれているか(「問題なさそう」ではなく)
  5. 範囲外があった変更が、どう扱われたかの記録があるか

書き方

  1. 来歴の形式を決め、自動で残せる項目(識別、実行、範囲の照合)を自動の流れに組み込む
  2. 指示の書き方を標準にし、範囲のない指示は AI に渡せない仕組みにする
  3. 人の確認と承認の欄を、合流の手続きの必須項目にする
  4. 範囲外があった変更の扱いを決め、実際に 1 件通してみる
  5. 定期的に記録を見返し、範囲外の発生率や確認の形骸化を点検する

何を書いてはいけないか

どこを見るか

  1. 変更から承認までの 1 本の線
  2. 範囲の照合の結果
  3. 人の確認の実体
  4. 承認の根拠
  5. 範囲外の扱い

赤信号

  • 本番の変更のうち、AI が関与したものを一覧できない
  • 指示が残っておらず、AI が何を頼まれて何を変えたかが分からない
  • 「テストに合格」が AI の報告だけで、自動の流れの記録と一致しない
  • 範囲外の変更が繰り返されているのに、指示の書き方が直されていない

よくある失敗

関係するUnit・成果物・危機演習

AI WORKFLOW

AIは、来歴の記録の欄が埋まっているか、指示に範囲が書かれているかを点検する下書きに役立ちます(AI 自身の変更を AI に承認させることはしません)。

「次の来歴の記録について、1 件ごとに『指示に触ってよい範囲と触ってはいけないものが書かれているか』『範囲の照合の結果があるか』『人の確認と承認の根拠が書かれているか』を表にし、欠けている欄を示してください。変更の良し悪しや、承認の是非は判断しないでください。」

REVIEW

  • AIが「書かれている」とした欄が、意味のある内容か(「確認済み」の一語で終わっていないか)
  • 欠けている欄について、記録の仕組みの問題か、運用の問題かを人が区別したか
  • 来歴の記録を AI に渡す前に、秘密情報が伏せ字になっているか確かめたか

人間が判断すること

  • 来歴に残す項目と、自動で残す範囲
  • 範囲外の変更があったときの扱い
  • AI が関与した変更を本番に出すか

設計承認・本番移行承認は、AIへ最終委任しない事項です(正本の方針)。

いつ使うか

この教材では STAGE 09|120人で安全に開発する の文脈で扱います。 アステリア案件での正式な作成・使用時期(月)は正本に記載がないため、未確定としています。

最後の問い

この記録を見た監査や運用の担当は、本番で動いているある変更について、「誰が、どの指示で AI に頼み、AI が何を変え、誰がどう確かめて承認したか」を、推測なしにたどれますか?

学習上の接続

教材上の学習接続です。成果物とUnitの正式な対応表はbaselineにないため、正式な関連付けとしては登録していません。

  • Stage:未確定(baselineに対応表なし)
  • 危機演習:未確定(baselineに対応表なし)
  • 人物:未確定(baselineに対応表なし)