# 既存システムのAI管理移行（汎用版）

版：1.0（2026-10-24）　作成：JumpStack株式会社
本書は自由に複製・改変して利用できます。改変版を配布する場合は出典を明記してください。

すでに稼働しているシステムを、AIエージェント（Claude Code 等のコーディングエージェント全般）の管理下に移すときの、**移行前に用意するもの**と**任せる範囲の広げ方**の指針。
新規開発と違い、稼働中のシステムは「今どう動いているか」の記録が人の頭の中と散らばった資料にしかない。本書はそれをAIが読める形にし、壊さずに任せる順序を決めるためのもの。
新しい移行では、本書をそのまま `docs/` に置き、§8の `<...>` をそのシステムの値で埋める。**ファイルはこれ1つだけ**（別ファイルは作らない）。

姉妹編との関係（3本で1組）：
- **AI開発ハーネス設計**（`ai-harness-design.md`）：AIに何をさせないか、どこで止めるか（境界）
- **AI開発コンテキスト設計**（`ai-context-design.md`）：AIが判断するとき何を知っているか（材料）
- **本書**：今、何がどう動いているか（現状）と、任せる範囲をどう広げるか（順序）

既存システムでは、本書を**最初に**埋める。現状が分からないまま境界や材料を設計しても、実態と食い違う。

本書の読み方：
- **意思決定者・発注側**：「要約」と§6（段階的な委任）だけで足りる
- **実装者・運用担当**：全体。§8のテンプレートと§9の記入済み見本を手元に置いて作業する
- **AIエージェント**：§0の手順に従う

ツール名（WordPress、AWS、GitHub Actions 等）はすべて**例**であり、同じ役割を果たすものに読み替えてよい。

---

## 用語（本書で使う言葉）

| 用語 | 意味 |
|---|---|
| **台帳** | 何が・どこで・何の上で動いているかの一覧。リポジトリ・サーバー・ドメイン・DB・外部サービス・定期処理を含む |
| **動作確認（スモークテスト）** | 「正常に動いている」を確かめる最小限の手順。自動テストがないシステムでは、これが最初のテストになる |
| **復旧** | バックアップから元の状態に戻すこと。戻せることを一度試していなければ、バックアップがあるとは言えない |
| **暗黙知** | 文書になっていないが、運用している人が知っている取り決め。「ここは触ると壊れる」「月末だけ動く」など |
| **安全な作業環境** | 本番と切り離してAIが試せる場所。開発環境・ステージング・ローカルのコピー |
| **委任段階** | AIに任せる範囲のレベル。読むだけ→開発環境で変更→本番の軽微な変更→定型運用の自動化、の順に広げる |
| **昇格条件** | 次の委任段階に進んでよいと判断する条件。動作確認の通過、事故ゼロの期間など |
| **EOL** | サポート終了（End of Life）。EOL後はセキュリティ修正が出ない |
| **不明** | 調べても分からなかったことを、分からないまま記録する印。空欄とは区別する |

---

## 要約（意思決定者・発注側向け）

**何が違うのか。** 新規開発なら、作りながら記録が残る。稼働中のシステムは、動いているという事実だけがあり、なぜそう動いているかの記録がない。AIに任せる前に必要なのは、高度な設計ではなく、**今の状態を書き出すこと**と、**壊したときに戻せること**の2つ。

**3つの原則。**
1. **戻せることを先に確かめる。** 復旧を一度も試していないバックアップは、ないのと同じ
2. **分からないことは「不明」と書く。** 空欄は「調べていない」のか「存在しない」のか区別できない。「不明」と書いてあれば、AIは触る前に確認する
3. **任せる範囲は段階的に広げる。** 最初は読むだけ。壊さないことを確かめてから、次の段階へ

**人間が持つもの。** 「触ってはいけない場所」の判断、復旧を試す承認、委任段階を上げる判断、元の開発会社や契約先との連絡。

**移行前の4つの質問。** 次に答えられなければ、まだAIに変更を任せる段階ではない：
- このシステムが正常に動いていることを、何を見れば確認できるか
- 壊れたとき、何分で、誰が、どこから戻せるか。最後に試したのはいつか
- 本番と切り離して試せる場所はあるか
- 触ると壊れる場所、理由の分からない設定は、どこにあるか

「動いているから大丈夫」は、現状の把握ではなく運に近い。

---

## 0. AIエージェントへ：このファイルを読んだら最初にやること

既存システムの移行で本書を渡されたAIは、次の手順で**この同じファイルの§8を埋める**。別ファイルは作らない。この段階ではAIの委任段階は「0：読むだけ」であり、**システムの設定・データ・本番環境を一切変更しない**。

1. **台帳（§8-A）を作る。** リポジトリ・設定ファイル・CI定義・インフラ定義・依存関係の一覧から、何が・どこで・何の版の上で動いているかを列挙する。版はEOL日と並べる。読み取れないもの（サーバーの中身・管理画面にしかない設定）は「不明（確認先：<誰・どこ>）」と書く
2. **動作確認の手順（§8-B）の案を作る。** コードと設定から、主要な機能（利用者に見える画面・外部との連携・定期処理）を拾い、「何をすると、何が起きれば正常か」の形で5〜10項目に絞る。人間に確認を依頼し、実際に通ることを確かめた日付を入れる
3. **復旧（§8-C）の現状を調べる。** バックアップの設定・保存先・世代数をコードと設定から読み取る。**復旧を試す手順を提案し、実施は人間に依頼する**（AIは実施しない）
4. **暗黙知（§8-D）を質問として列挙する。** コードから読み取れる「理由の分からない設定」「直接編集されている形跡」「コメントで警告されている箇所」を挙げ、人間に「触ってよいか」「なぜそうなっているか」を尋ねる。答えが分からなければ「不明」のまま記録する
5. **安全な作業環境（§8-E）の有無を確認する。** なければ、作る手順を提案する（本番のコピー・ダミーデータ・ステージング）
6. **段階的な委任（§8-F）の初期値を提案する。** 全項目を「段階0」から始め、昇格条件の案を添える
7. **関係者（§8-G）は人間に確認する。** コードやドキュメントに名前があっても、現在の担当とは限らない
8. 本ファイルを指示書から1行で参照させる（例：「現状と委任段階は `docs/ai-migration-design.md` §8 を正とする」）

判断を求める際は、選択肢と推奨を添える。

**人間が判断できない項目、または「おすすめで」と返された項目は、推奨案で仮決定して先へ進む。** 仮決定した値には「（仮：<YYYY-MM-DD> AI推奨）」と付け、作業の最後に「決めたこと」と「仮決定したこと」を分けて一覧で報告する。迷ったら安全側（委任段階を低く、触ってはいけない場所を広く）を選ぶ。人間が確認した時点で「仮」を外す。ただし、**委任段階の昇格・復旧の実施・本番への変更・外部契約**は仮決定せず、人間の判断を待つ。

空欄のまま「未定」と書く場合は、いつまでに決めるかを必ず付ける。

---

## 1. 考え方

稼働中のシステムに手を入れるとき、最大の危険は「壊すこと」ではなく、**壊したことに気づかないこと**と**戻せないこと**である。
AIは人より速く変更できる。速さは、気づく仕組みと戻す手段がなければ、損害の速さになる。

だから順序は、

1. 今の状態を書き出す（台帳）
2. 正常を定義する（動作確認）
3. 戻せることを確かめる（復旧）
4. 触ってはいけない場所を決める（暗黙知）
5. 安全に試せる場所を用意する（作業環境）
6. そのうえで、少しずつ任せる（委任段階）

1〜5が整うまで、AIは「読むだけ」に留める。読むだけでも、台帳づくりと質問の列挙はAIが担えるので、移行の作業自体は最初から速い。

ハーネス設計（止める仕組み）とコンテキスト設計（判断の材料）は、この現状把握の上に載せる。現状が分からないまま境界を引いても、実態とずれた境界になる。

## 2. 基本原則（優先順）

1. **読むだけから始める。** 最初の委任段階は「変更しない」。台帳・質問・提案を出すところまで。
2. **戻せるまで変えない。** 復旧を一度試してから、本番に関わる変更を許可する。
3. **「不明」を許す。** 分からないことを分からないまま記録する。埋めるために推測で書かない。
4. **正常を先に定義する。** 動作確認の手順がなければ、変更後に「壊していない」と言えない。
5. **本番で試さない。** 安全な作業環境で試してから本番へ。作業環境がなければ、作ることが最初の仕事。
6. **段階は条件で上げる。** 期間や気分ではなく、昇格条件（動作確認の通過・事故ゼロの期間・復旧の実施）を満たしたら上げる。
7. **関係者を切らない。** 元の開発会社・契約先・鍵の管理者を把握し、AIが「誰の承認が要るか」を判断できるようにする。

## 3. 移行前に用意する7つ

| 用意するもの | 何のため | 最低限 | 整った状態 |
|---|---|---|---|
| **A. 台帳** | 何が・どこで・何の上で動いているか | リポジトリ・サーバー・ドメイン・DB・外部サービス・定期処理の一覧と版 | EOL日・契約先・更新の責任者まで揃い、四半期ごとに見直されている |
| **B. 動作確認の手順** | 変更後に「壊していない」と言うため | 人が手で確認できる5〜10項目 | 自動化され、変更ごとに実行される |
| **C. 復旧手順** | 壊したとき戻すため | バックアップの場所と戻し方。一度試した記録 | 復旧時間が分かっており、年1回試している |
| **D. 暗黙知の記録** | 触ってはいけない場所を知るため | 「直接編集している」「理由不明だが変えると壊れる」の一覧 | 理由が調べられ、「不明」が減っている。触ってよい範囲が明確 |
| **E. 安全な作業環境** | 本番で試さないため | 本番のコピー（ダミーデータ）で動く環境 | 本番と同じ構成のステージング。CIから自動で作れる |
| **F. 段階的な委任計画** | 任せる範囲を安全に広げるため | 現在の段階と、次に進む条件 | 段階ごとの実績が記録され、昇格の判断が記録で行える |
| **G. 関係者と連絡先** | 承認・契約・鍵の所在を知るため | 元の開発会社・サーバー契約者・ドメイン管理者・鍵の保持者 | 役割ごとの連絡先と、不在時の代替が決まっている |

AからEは、AIが「読むだけ」の段階で下書きを作れる。FとGは人間が決める。

## 4. 台帳の作り方

台帳は「何が動いているか」の一覧であり、移行のすべての土台になる。

- **単位は「動いているもの」ごと。** Webサイト、API、管理画面、バッチ、DB、外部サービス連携、ドメイン、証明書
- **各行に「版」と「EOL日」を並べる。** 版だけ書いても、古いかどうかが分からない。PHP・言語ランタイム・フレームワーク・CMS・主要プラグイン・OS・DB
- **「どこに」は、場所と契約の両方。** レンタルサーバー名・クラウドのアカウント・リージョン、そして契約者・支払い者
- **外から見えるものと見えないものを分ける。** 公開URLの応答ヘッダーやHTMLから読める版（CMSの版・プラグインの版）と、サーバーに入らないと分からない版（PHP・OS）がある。後者は「不明（確認先）」として残す
- **定期処理を忘れない。** cron・スケジューラ・メール送信・外部からの Webhook。月末・年度末だけ動くものは、動作確認の手順にも載せる

## 5. 動作確認・復旧・暗黙知

### 動作確認の手順
- 「何をすると、何が起きれば正常か」の形で書く。「トップページを開く → 200 で返り、最新のお知らせが表示される」
- 利用者に見える流れ（閲覧・登録・ログイン・決済・問い合わせ）、外部との連携（メール・決済・API）、定期処理（バッチの完了）から、5〜10項目に絞る
- 最初は手動でよい。AIに変更を任せる前に一度通し、通った日付を記録する
- 自動化できるものから自動化し、変更ごとに実行する。これが既存システムにおける「テスト」の出発点になる

### 復旧
- 「バックアップがある」と「戻せる」は別。**戻す手順を一度実行し、何分かかったかを記録する**まで、復旧手順があるとは言わない
- 戻す先は本番ではなく作業環境でよい。本番のバックアップを作業環境に展開できれば、復旧の確認と作業環境の構築が同時に済む
- DNS・証明書・ドメインの期限と更新方法も、復旧の一部として記録する。期限切れは「壊れた」のと同じ結果になる
- 復旧の実施は人間が行う（ハーネス設計§4）。AIは手順の提案と、結果の記録を担う

### 暗黙知の記録
- 「本番のファイルを直接編集している」「理由は分からないが、この設定を変えると壊れる」「このプラグインは更新すると表示が崩れる」「月末だけ動く処理がある」
- 分かっている人に聞き、分からなければ「不明」と書く。推測で理由を書かない
- 「触ってはいけない場所」は、ハーネス設計§11-A（不変条件）の候補になる。理由が分かったものから、仕組みで止める形に移す

## 6. 段階的な委任

任せる範囲は、次の段階で広げる。全システム一律ではなく、§8-Fで作業の種類ごとに段階を決める。

| 段階 | AIができること | 昇格の条件（次へ進むために満たすもの） |
|---|---|---|
| **0. 読むだけ** | コード・設定・ログの調査、台帳と質問の作成、変更の提案 | 台帳・動作確認・復旧・暗黙知・作業環境（§3のA〜E）が最低限揃う |
| **1. 作業環境で変更** | 作業環境でのコード変更・テスト・動作確認 | 作業環境での変更が動作確認を通る。本番の承認ゲート（ハーネス設計§6）が実動作で止まることを確認済み |
| **2. 本番の軽微な変更（承認付き）** | 文言・設定値・依存の更新など、戻しやすい変更を準備し、人間の承認で反映 | 一定期間（例：4週間）、承認付きの本番変更で事故ゼロ。復旧を一度実施済み |
| **3. 定型運用の自動化** | 更新の適用・監視・定期処理の実行を、決めた範囲で自動実行。異常時は人間へ | 自動化する作業の手順が文書化され、失敗時に止まる仕組みと通知がある |

段階は上げるだけでなく、事故やヒヤリがあれば下げる。下げた理由と、再昇格の条件を§8-Hに記録する。

## 7. よくある失敗と対策

| 起きること | 原因 | 対策 |
|---|---|---|
| 変更したあと、どこかが壊れたことに数週間気づかない | 正常の定義（動作確認）がなかった | 動作確認の手順を先に作り、変更ごとに通す |
| バックアップはあったが、戻し方が分からず数日止まる | 復旧を試したことがなかった | 作業環境への復旧を一度実施し、所要時間を記録する |
| 理由の分からない設定をAIが「整理」して壊す | 暗黙知が記録されていなかった | 触ってはいけない場所を先に列挙し、「不明」は触る前に確認する |
| 本番で試して、利用者に影響が出る | 安全な作業環境がなかった | 本番のコピーで動く環境を最初に作る |
| プラグインやライブラリを一斉更新して表示が崩れる | 戻しやすさを考えずに大きく変えた | 1つずつ更新し、動作確認を通してから次へ。戻せる単位で変える |
| CMS本体は最新なのに、PHPやプラグインが古いまま | 台帳が本体の版しか見ていなかった | ランタイム・プラグイン・OSまで台帳に載せ、EOL日と並べる |
| 元の開発会社に連絡がつかず、鍵や契約の所在が分からない | 関係者を把握していなかった | 移行前に関係者と連絡先を確認し、鍵の再発行・契約の移管を済ませる |
| AIに任せる範囲を一気に広げ、事故で全部止める | 段階と昇格条件がなかった | 段階を決め、条件を満たしてから上げる。事故があれば下げる |

教訓は「何が起きたか」ではなく「次に同じ状況で何を用意しておくか」の形で残す。

---

## 8. 適用テンプレート（システムごとに埋める）

### 使い方

1. 本ファイルをプロジェクトの `docs/` に置く（別ファイルは作らない。この§8をそのまま編集する）
2. 各項目の **「何を書くか」「なぜ必要か」「記入例」** を読み、`<...>` を自分のシステムの値に置き換える。説明文は残しても消してもよい
3. 分からない項目は空欄にせず、調べて分からなければ「不明（確認先：<誰・どこ>）」と書く。推奨案で仮決定できるものは「（仮）」と付ける
4. 項目B（動作確認）を一度手で通し、項目C（復旧）を一度実施して、日付を入れる。ここまでが移行準備の完了で、委任段階1に進める
5. 以後、段階を上げ下げしたら項目F、事故・ヒヤリがあれば項目Hに追記する

### 対象システム

- システム名：<システム名>
- 最終更新：<YYYY-MM-DD>　担当：<氏名>
- 現在の委任段階：<0〜3>（§6）

## A. 台帳

**何を書くか**：動いているものごとに、場所・版・EOL・契約・責任者。
**なぜ必要か**：何が動いているか分からなければ、何を守るかも、何が古いかも分からない。移行のすべての土台。
**書き方**：外から読める版と、サーバーに入らないと分からない版を区別し、後者は「不明（確認先）」と書く。
**記入例**：「Webサイト | WordPress 7.1.3 | — | レンタルサーバー〇〇 | 総務部 | PHP の版は不明（確認先：サーバー事業者の管理画面）」

| 動いているもの | 版 | EOL日 | 場所（サーバー・契約） | 責任者 | 備考・不明点 |
|---|---|---|---|---|---|
| <Webサイト・CMS> | <版> | <日付／不明> | <...> | <...> | <...> |
| <言語ランタイム（PHP・Node.js 等）> | <版／不明> | <...> | <...> | <...> | <...> |
| <主要プラグイン・ライブラリ> | <...> | <...> | <...> | <...> | <...> |
| <DB> | <...> | <...> | <...> | <...> | <...> |
| <外部サービス連携（決済・メール・API）> | <...> | <...> | <契約者> | <...> | <...> |
| <定期処理（cron・バッチ）> | <...> | — | <...> | <...> | <実行タイミング> |
| <ドメイン・証明書> | — | <期限> | <登録事業者> | <...> | <...> |

## B. 動作確認の手順

**何を書くか**：「正常に動いている」を確かめる5〜10項目と、最後に通した日。
**なぜ必要か**：これがなければ、変更後に「壊していない」と言えない。既存システムにおける最初のテスト。
**書き方**：「何をすると、何が起きれば正常か」。手動か自動かを書く。
**記入例**：「問い合わせフォーム送信 | テスト内容を送信し、担当者のメールに届く | 手動 | 2026-10-24」

| 項目 | 手順と正常の条件 | 手動／自動 | 最後に通した日 |
|---|---|---|---|
| <トップページ表示> | <...> | <...> | <...> |
| <ログイン> | <...> | <...> | <...> |
| <主要な業務の流れ（登録・注文など）> | <...> | <...> | <...> |
| <外部連携（メール・決済）> | <...> | <...> | <...> |
| <定期処理の完了> | <...> | <...> | <...> |

## C. 復旧

**何を書くか**：バックアップの場所・世代・戻し方と、実際に戻してみた記録。期限のあるもの（DNS・証明書・ドメイン）。
**なぜ必要か**：戻せないなら、AIにもあなたにも、変更を任せられない。
**書き方**：「試した日」「かかった時間」「戻した先」を必ず書く。未実施なら「未実施（予定：<日付>）」。
**記入例**：「DB | 日次・7世代 | サーバー事業者の自動バックアップ | 管理画面から復元 | 2026-10-24・15分・作業環境へ」

| 対象 | 頻度・世代 | 保存先 | 戻し方 | 最後に試した日・所要時間・戻した先 |
|---|---|---|---|---|
| <ファイル> | <...> | <...> | <...> | <...／未実施> |
| <DB> | <...> | <...> | <...> | <...> |
| <設定（管理画面にしかないもの）> | <...> | <...> | <...> | <...> |

| 期限のあるもの | 期限 | 更新方法 | 担当 |
|---|---|---|---|
| <ドメイン> | <...> | <...> | <...> |
| <証明書> | <...> | <...> | <...> |

## D. 暗黙知・触ってはいけない場所

**何を書くか**：文書になっていない取り決め。直接編集している場所、理由不明だが変えると壊れる設定、特定の時期だけ動く処理。
**なぜ必要か**：AIは「整理」が得意で、理由の分からない設定を消しがち。先に「触るな」を伝える。
**書き方**：「場所」「何をすると壊れるか」「理由」「触ってよいか」。理由が分からなければ「不明」。
**記入例**：「`wp-config.php` の末尾の独自定数 | 消すと決済連携が止まる | 不明（元の開発会社が追加） | 触らない」

| 場所 | 何をすると壊れるか | 理由 | 触ってよいか |
|---|---|---|---|
| <...> | <...> | <...／不明> | <触らない／確認後に可／可> |

## E. 安全な作業環境

**何を書くか**：本番と切り離して試せる環境の有無と、本番との違い。
**なぜ必要か**：本番で試すと利用者に影響が出る。作業環境がなければ、作ることが最初の仕事。
**書き方**：なければ「なし（作る手順：<...>、予定：<日付>）」。
**記入例**：「ステージング | あり | 本番の前日コピー。決済はテストモード、メールは送信しない | 2026-10-20 に作成」

| 環境 | 有無 | 本番との違い（データ・外部連携・ドメイン） | 作った日／作る予定 |
|---|---|---|---|
| <ローカル／ステージング> | <あり／なし> | <...> | <...> |

## F. 段階的な委任計画

**何を書くか**：作業の種類ごとの、現在の委任段階（§6）と昇格条件。
**なぜ必要か**：一律に任せると、戻しにくい作業まで同じ速さで進む。種類ごとに段階を分ける。
**書き方**：「作業の種類」「現在の段階」「次の段階に進む条件」「上げた・下げた記録」。
**記入例**：「文言の修正 | 2 | 4週間事故ゼロで3へ | 2026-10-24 に1→2」

| 作業の種類 | 現在の段階 | 次に進む条件 | 変更の記録 |
|---|---|---|---|
| <文言・コンテンツの修正> | <0〜3> | <...> | <...> |
| <プラグイン・依存の更新> | <...> | <...> | <...> |
| <機能の追加・変更> | <...> | <...> | <...> |
| <サーバー・インフラの変更> | <...> | <...> | <...> |
| <定期処理の実行・監視> | <...> | <...> | <...> |

## G. 関係者と連絡先

**何を書くか**：元の開発会社・サーバー契約者・ドメイン管理者・鍵の保持者・承認者。
**なぜ必要か**：AIが「この操作は誰の承認が要るか」を判断し、人間が契約や鍵の所在を見失わないため。
**書き方**：役割ごとに「誰」「連絡手段」「不在時の代替」。連絡がつかない相手は「連絡不能（最終：<日付>）」と正直に書く。
**記入例**：「サーバー契約 | 総務 山田 | 社内チャット | 経理 鈴木」

| 役割 | 誰 | 連絡手段 | 不在時の代替 |
|---|---|---|---|
| 元の開発会社・保守契約 | <...> | <...> | <...> |
| サーバー・クラウドの契約者 | <...> | <...> | <...> |
| ドメイン・証明書の管理者 | <...> | <...> | <...> |
| 鍵・パスワードの保持者 | <...> | <...> | <...> |
| 本番変更の承認者 | <...> | <...> | <...> |

## H. 教訓（このシステム固有）

**何を書くか**：移行の過程で起きた事故・ヒヤリと、段階を下げた記録。
**なぜ必要か**：同じ失敗を繰り返さないため。段階を下げた理由がなければ、再昇格の判断ができない。
**記入例**：「プラグインを3つ同時に更新して表示崩れ | 戻せる単位を超えて変更した | 1つずつ更新に変更。段階2→1に下げ、4週間後に再評価」

| 起きたこと | 原因 | 対策（次に何を用意するか／段階の変更） |
|---|---|---|
| <...> | <...> | <...> |

## 9. 記入済み見本（架空のシステム）

§8を埋めるとどうなるかの見本。中小企業のコーポレートサイト（WordPress）を、元の開発会社から引き継いでAI管理下に移す架空の例で、固有名はすべて仮のもの。粒度の参考にし、§8を埋め終えたらこの節は削除してよい。

```markdown
### 対象システム
- システム名：サンプル商事 コーポレートサイト
- 最終更新：2026-10-24　担当：山田
- 現在の委任段階：1

## A. 台帳
| 動いているもの | 版 | EOL日 | 場所（サーバー・契約） | 責任者 | 備考・不明点 |
|---|---|---|---|---|---|
| コーポレートサイト（WordPress） | 7.1.3 | —（最新） | レンタルサーバー「サンプルホスティング」／契約者：総務 | 山田 | 自動更新オン |
| PHP | 不明（確認先：サーバー管理画面） | — | 同上 | 山田 | 2026-10-21 の脆弱性対応を要確認 |
| プラグイン：スライダー | 6.2.x | 不明 | 同上 | 山田 | 更新すると表示が崩れた記録あり（D参照） |
| プラグイン：問い合わせフォーム | 最新 | — | 同上 | 山田 | — |
| MySQL | 8.0 | 2026-04（Oracle の通常サポート） | 同上 | 山田 | サーバー事業者の対応を確認 |
| 問い合わせメール送信 | — | — | サーバーの SMTP | 山田 | 送信先：info@ |
| ドメイン | — | 2027-03-15 | レジストラ「サンプルドメイン」／契約者：総務 | 鈴木 | — |
| SSL証明書 | — | 自動更新 | サーバー事業者の無料SSL | — | — |

## B. 動作確認の手順
| 項目 | 手順と正常の条件 | 手動／自動 | 最後に通した日 |
|---|---|---|---|
| トップページ表示 | https://example.jp/ を開く → 200、最新のお知らせが表示される | 手動 | 2026-10-24 |
| 管理画面ログイン | /wp-admin/ にログインできる | 手動 | 2026-10-24 |
| 問い合わせ送信 | フォームからテスト送信 → info@ に届く | 手動 | 2026-10-24 |
| お知らせ投稿 | 下書きを作成・プレビュー・削除できる | 手動 | 2026-10-24 |
| スマホ表示 | トップと会社概要が崩れていない | 手動 | 2026-10-24 |

## C. 復旧
| 対象 | 頻度・世代 | 保存先 | 戻し方 | 最後に試した日・所要時間・戻した先 |
|---|---|---|---|---|
| ファイル一式 | 日次・7世代 | サーバー事業者の自動バックアップ | 管理画面から復元 | 2026-10-22・20分・ステージングへ |
| DB | 日次・7世代 | 同上 | 同上 | 2026-10-22・同時 |
| サーバー管理画面の設定（PHP版・SSL） | — | 画面にのみ存在 | 手動で再設定 | 控えを docs/ に記録（2026-10-22） |

| 期限のあるもの | 期限 | 更新方法 | 担当 |
|---|---|---|---|
| ドメイン | 2027-03-15 | レジストラの管理画面（自動更新オン） | 鈴木 |
| SSL証明書 | 自動更新 | — | — |

## D. 暗黙知・触ってはいけない場所
| 場所 | 何をすると壊れるか | 理由 | 触ってよいか |
|---|---|---|---|
| `wp-config.php` 末尾の独自定数 | 消すと問い合わせフォームの送信先が変わる | 元の開発会社が追加。詳細は不明 | 触らない |
| テーマ内 `functions.php` の末尾 | 直接編集されている形跡あり | 不明（確認先：元の開発会社、連絡不能・最終 2025-12） | 確認後に可 |
| スライダープラグイン | 更新すると表示が崩れた（2025-08） | テーマ側の独自CSS依存とみられる | ステージングで試してから |

## E. 安全な作業環境
| 環境 | 有無 | 本番との違い | 作った日／作る予定 |
|---|---|---|---|
| ステージング（サーバー事業者の機能） | あり | 本番の前日コピー。メールは送信しない設定。ドメインは staging.example.jp | 2026-10-22 |

## F. 段階的な委任計画
| 作業の種類 | 現在の段階 | 次に進む条件 | 変更の記録 |
|---|---|---|---|
| 文言・お知らせの修正 | 1 | ステージングで5回通し、本番承認ゲートの実動作確認が済んだら2へ | 2026-10-24 に0→1 |
| プラグイン・WordPress の更新 | 1 | 1つずつステージングで更新し動作確認が通ること。4週間事故ゼロで2へ | 2026-10-24 に0→1 |
| テーマの変更・機能追加 | 0 | D の「不明」が解消するまで0 | — |
| サーバー設定（PHP版など） | 0 | 人間が実施。AIは手順の提案のみ | — |
| 監視（表示・証明書期限） | 1 | 通知の仕組みができたら3へ | — |

## G. 関係者と連絡先
| 役割 | 誰 | 連絡手段 | 不在時の代替 |
|---|---|---|---|
| 元の開発会社 | 株式会社サンプル制作 | メール（連絡不能・最終 2025-12） | — |
| サーバー契約者 | 総務 山田 | 社内チャット | 経理 鈴木 |
| ドメイン管理者 | 総務 鈴木 | 社内チャット | 山田 |
| 鍵・パスワードの保持者 | 山田（パスワード管理ツール） | — | 鈴木（緊急時のみ） |
| 本番変更の承認者 | 山田 | 社内チャット | 代表 |

## H. 教訓
| 起きたこと | 原因 | 対策 |
|---|---|---|
| 2025-08 スライダー更新で表示崩れ、戻すのに半日 | 復旧手順が未確認だった。ステージングがなかった | ステージングを作成し、復旧を一度実施。プラグインは1つずつ更新 |
```

## 10. 更新方針

- 委任段階を上げ下げしたら§8-F、事故・ヒヤリがあれば§7（よくある失敗）と§8-Hに追記する
- 台帳（§8-A）は四半期に一度、版とEOL日を見直す。期限のあるもの（§8-C）は期限の2か月前に確認する
- 本書（汎用版）は四半期に一度、各システムの教訓を取り込んで改訂する
- 姉妹編「AI開発ハーネス設計」「AI開発コンテキスト設計」と用語・節番号の参照がずれていないかを、改訂のたびに確認する