公開・本番移行学習記事全11節Operate
配置した範囲だけで、対象者・機能・期間を絞った初期利用を演習し記録する
この記事で身につくこと対象者・機能・時間帯を絞って利用を始める理由と、正常利用と異常の兆候を分けて見る考え方を説明できる。
記事内目次（19項目）
この記事の会社・人物・データはすべて架空の設定です。実在する会社や案件とは関係ありません。この記事の初期利用の確認記録は、11-02で配置したもの（承認可否の判定関数と移行データ3件）に対して、承認者役の操作を配置サンドボックスの中で再現した演習の記録です。実際の利用者による利用の記録ではありません（第8.1節）。
この記事は何の話か。10-04の判定を受けて利用を始めるときに、いきなり全員・全機能ではなく、対象者・機能・期間を絞って始め、正常に進んだ記録と異常の兆候を分けて確認記録に残す話です。この記事では、11-02で実際に配置した範囲（承認可否の判定だけ）を対象に、その絞り込みと記録を演習として行います。
なぜ必要か。範囲を絞らずに始めると、問題が起きたときの影響範囲や原因の特定が難しくなります。また、「配置していない機能」まで使い始めたことにして記録を作ると、記録が事実と食い違い、11-04の切戻し判断や12-01の運用項目の土台が崩れます。
この記事を読むとできるようになること。
- 対象者・機能・時間帯を絞って利用を始める理由を説明できる
- 実際に配置した範囲だけを対象に、初期利用計画を作り、正常の記録と異常の兆候を分けて確認記録に書ける
- 範囲を広げる条件と、止めて戻す条件を、業務への影響と確認できる情報から判断できる
- 「前工程が配置したもの」を配置し直さずにそのまま使い、記録の版・配置日時が前工程と一致することを確かめられる
読む順路。この記事は3つの深さで読めます。全部を順に読む必要はありません。
- 基本だけ理解する：第1節→第3節（絞り込みの3つの軸と「配置したもの」という上限、演習と実績の違い）→第4節（判断すること）→第5.1〜5.2節（初期利用計画と操作）→第6節の確認記録の表→第9節。コードを読まなくても、初期利用で何を絞り、何を記録し、何を記録しないかが分かります。
- 作って確かめる：上に加えて第5.3節（演習コード）→第5.4節（演習の設計：実行前に見るもの・失敗したとき・戻せるか・誰が）→第6節の実行結果→第7節（確かめたこと・確かめていないこと）。
- 設計判断を深める：上に加えて第8節（演習と実績、範囲を広げる条件と止めて戻す条件）。
1. 今回の業務課題と完成するもの
この記事でやることは、11-02で配置サンドボックスに配置したもの（canApprove 関数と移行データ3件、版 v0.1.0-sandbox）を対象に、対象者・機能・期間を絞った初期利用計画を作り、承認者役の操作を演習として行って、正常の記録と異常の兆候を初期利用の確認記録にまとめることです。
11-02では配置を行いましたが、実際にどの範囲で、誰が、何を使い始めるかはまだ決めていませんでした。この記事では、それを決めます。ただし、11-02が配置したのは承認可否の判定関数だけで、提出・差戻し・再提出・状態の更新・画面は配置していません。配置していないものは、この記事の初期利用の対象にしません。
この記事を読み終えると、次のものが手元にできます。
- 初期利用の確認記録（対象者、機能、期間、確認項目、正常の記録、異常の兆候、対象外のため未確認、次の範囲への条件）
- 配置した範囲で初期利用を演習するコードと実行記録（
examples/11-03-initial-use-record/）
2. 前提知識と読む順路
この記事で使う言葉を先に説明します。
段階的な利用開始
一言でいうと、いきなり全員・全機能で使い始めるのではなく、少人数・一部の機能・短い期間から始め、問題がなければ範囲を広げていくやり方です。
異常の兆候
一言でいうと、まだ大きな問題にはなっていないが、注意して見ておくべき事象です。エラーそのものだけでなく、想定と違う操作のパターンなども含みます。
演習と実績
一言でいうと、演習は「本物と同じ手順を、架空のデータと役の人で行うこと」、実績は「実際の利用者が実際の業務で使った記録」です。この記事の記録は演習です。演習の記録を実績のように書くと、10-04・11-04の判断が事実でないものの上に立ってしまいます。
これがないと、範囲を絞らずに始めた場合に問題の原因を特定しにくくなり、また、配置していない機能の「利用記録」が作られてしまいます。
読む順路：配置は11-02、利用開始判定は10-04が該当します。この記事の確認記録は、11-04（切戻しと初期安定を確認する）、12-01（稼働状況・業務結果・費用を把握する）で使います。
3. 理解する：対象者・機能・期間を絞る理由
3.1 絞り込みの3つの軸と、「配置したもの」という上限
| 軸 | この記事での絞り込み | 上限（11-02で配置した範囲） |
|---|---|---|
| 対象者 | 移行データで承認者に割り当てられている2名（鈴木、佐藤）のみ。依頼者役は対象外 | 依頼者が使う提出機能は配置していない |
| 機能 | 承認可否の判定（canApprove）のみ | 状態の更新・保存、提出、差戻し、再提出、画面は配置していない |
| 期間 | この演習の1回の実行 | 実際の利用期間（例：2週間）はまだ始まっていない |
絞り込みは「配置したものの中から選ぶ」ことです。配置していない機能を対象者に使ってもらうことはできません。
3.2 よくある誤解
「10-04で限定試行と決めたのだから、その部門全員で一斉に始めればよい」。10-04の「一部門」は、まだ広い範囲です。さらに少人数・一部の機能から始め、問題を早期に見つけやすくします。なお、10-04の判定は「演習成功」であり、実業務での限定試行はまだ延期中です（10-04第6節）。この記事の演習は、その延期条件が解けたときに同じ手順で実績の記録を取るための予行です。
「正常に動いていれば、細かい兆候は気にしなくてよい」。エラーが出ていなくても、想定と違う操作のパターン（例：割当外の人が承認を試みる）は、説明不足など後の問題につながる兆候である可能性があります。正常の記録と異常の兆候は分けて見ます（第5.2節・第6節）。
「使う予定の機能を書いておけば、初期利用の記録になる」。記録になるのは実際に行った操作とその結果だけです。この記事の初版は「提出・承認機能まで」を対象に「想定どおり進む想定」と書いていましたが、提出機能は配置されておらず、操作も行っていませんでした。それは記録ではありません（第8.1節）。
4. 判断すること
初期利用を始めるときに人が判断することは、次の5つです。
| 判断すること | なぜ判断が必要か | 仮置きしてよいか | 間違えた場合の影響 |
|---|---|---|---|
| いつ始めてよいか（前提がそろっているか） | 11-02の配置が健全性確認まで一致していること、11-01で「止める」が0件であることが前提 | 不可。配置が無い・不一致なら始めない（演習コードは終了コード1で止まる） | 配置されていないもの、壊れた配置に対して「初期利用」の記録が作られる |
| 対象者・機能・期間をどこまで絞るか | 絞らないと、問題が起きたときの影響範囲と原因を特定しにくい。上限は「配置したもの」（第3.1節） | 可（この記事は承認者役2名・判定のみ・1回。実際の限定試行では業務担当者と決める） | 配置していない提出機能を「使い始めた」ことにしてしまう |
| 何を証拠として残すか | 実際に行った操作と結果だけが記録。想定は記録ではない（第3.2節） | 不可。操作の記録（誰が・何に・結果）と、正常・兆候・対象外の3区分を残す | 想定が実績として11-04・12-01の判断材料になる |
| どんな条件なら止めて戻すか | 判断が事後にならないよう、始める前に決める（第8.2節） | 不可。例外・許可されないはずの操作の許可・データの不整合・苦情、を先に決める | 兆候が出ても「様子見」で進む |
| 誰が実施し、誰が判断するか | 演習の実施者（Claude Code）は実際の利用者ではない。範囲を広げる判断は運用管理者（架空） | 可（架空の体制で仮置き。実際の限定試行では業務担当者が実施し、運用管理者が判断） | 実施者と判断者が同じAIのまま「利用者が確認した」ことになる |
勝手に決めてはいけないこと：実際の利用者が使い始めたかのように書きません。この記事の記録は演習です（第8.1節）。11-02で配置していない機能（提出・差戻し・再提出・状態の更新・画面）を、この記事の初期利用の対象に含めません。演習で観測していないことを、確認記録の「正常の記録」に書きません。11-02の配置をこの記事で作り直しません（配置は11-02の責任範囲）。
AIに任せる範囲：演習コードの下書き、実行して結果をそのまま返すこと、確認記録の形への整理はAIに任せられます。任せてはいけないのは、絞り込みの範囲、止めて戻す条件、そして「範囲を広げてよいか」の判断です。AIが実施した演習を「利用者の確認」と書き換えることもしません。
5. 作って確かめる：初期利用計画を作る
5.1 初期利用計画
| 項目 | 内容 |
|---|---|
| 対象者 | 移行データで承認者に割り当てられている2名（鈴木、佐藤）。依頼者役は対象外（提出機能を配置していないため） |
| 機能 | 承認可否の判定（canApprove）のみ。状態の更新・保存、提出、差戻し、再提出は配置していないため対象外 |
| 期間 | この演習の1回の実行（実際の利用期間ではない） |
| 確認項目 | 判定を行った件数、許可された件数、拒否された件数、エラー（例外）の有無、想定と異なる操作パターンの有無 |
5.2 演習で行う操作（配置したデータに対して）
11-02で配置した移行データ3件（REQ-OLD-001、002、005。いずれも状態は「提出済み」）に対して、承認者役が承認できるかの判定を行います。最後の1件は、割当外の承認者が承認を試みるという想定外の操作パターンです。判定が拒否になれば正常な動作ですが、「異常の兆候」の欄に分けて記録します。
| 操作者 | 依頼 | 割当承認者 | 操作の種類 |
|---|---|---|---|
| 鈴木 | REQ-OLD-001 | 鈴木 | 割当承認者による承認 |
| 鈴木 | REQ-OLD-002 | 鈴木 | 割当承認者による承認 |
| 佐藤 | REQ-OLD-005 | 佐藤 | 割当承認者による承認 |
| 高橋 | REQ-OLD-001 | 鈴木 | 割当外の承認者が承認を試みる（想定外の操作パターン） |
佐藤について：記事A・01-01では佐藤は依頼者役です。それでもここで佐藤が承認者として操作するのは、10-02の旧データ REQ-OLD-005 の承認者欄に佐藤が記録されていて、移行がその値をそのまま移しているからです（10-02 は役割の確認をしていません）。配置した canApprove も「その人が承認者役か」（役割）は見ず、「その依頼の承認者か」（割当）だけを見るため、この承認は許可されます。役割と割当が別の条件であること、本番では両方を確かめる必要があることは記事Bで扱っています。この演習では、この件を「配置した範囲では判定できない未確認事項」として第7節に残します。
5.3 演習コード
11-02の正本（examples/11-02-deploy-record/deploy.js）が配置した deploy_target/ をそのまま使います。このフォルダで配置し直すことはせず、配置が無ければ止まります。配置記録（MANIFEST.json）の版・配置日時と、11-02と同じ健全性確認（5項目）が一致することを確かめてから、上の操作を行い、確認記録をこのフォルダの initial_use_record.json に保存します（examples/11-03-initial-use-record/run.js）。
// 教材演習用：11-02で配置した内容（承認可否の判定関数 canApprove と、移行データ3件）の範囲だけで、
// 対象者・機能・期間を絞った「初期利用」を演習として行い、確認記録を残す。
// これは実際の利用者による利用ではなく、配置サンドボックスの中で承認者役の操作を再現した演習である。
// 11-02で配置していない機能（提出、差戻し、再提出、状態の更新・保存）は対象にしない。
// 配置は 11-02 の正本（../11-02-deploy-record/deploy.js）が行ったものをそのまま使う。このフォルダでは配置しない。
const fs = require("node:fs");
const path = require("node:path");
const { healthCheck, SANDBOX_DIR } = require("../11-02-deploy-record/deploy.js");
const RECORD_FILE = path.join(__dirname, "initial_use_record.json");
// 手順1：11-02 が配置した配置サンドボックスが存在し、健全性確認が一致することを前提として確かめる（配置し直さない）
if (!fs.existsSync(path.join(SANDBOX_DIR, "MANIFEST.json"))) {
console.log(`11-02 の配置が見つかりません（${path.relative(__dirname, SANDBOX_DIR)}）。先に examples/10-02-migration-plan と examples/11-02-deploy-record で node run.js を実行してください`);
process.exit(1);
}
const manifest = JSON.parse(fs.readFileSync(path.join(SANDBOX_DIR, "MANIFEST.json"), "utf8"));
const health = healthCheck();
if (!health.every((r) => r.ok)) {
console.log("配置の健全性確認が一致しないため、初期利用の演習を始めない");
process.exit(1);
}
console.log(`手順1：11-02 が配置した内容を使う（版 ${manifest.version}、配置日時 ${manifest.deployedAt}）。健全性確認 ${health.length}件すべて一致`);
for (const f of manifest.files) console.log(` 配置元 ${f.source} → ${f.target}（sha256: ${f.sha256.slice(0, 12)}…）`);
// 手順2：初期利用の範囲を絞る（対象者・機能・期間）
const plan = {
対象者: "移行データで承認者に割り当てられている2名（鈴木、佐藤）。依頼者役は対象外（提出機能を配置していないため）",
機能: "承認可否の判定（canApprove）のみ。状態の更新・保存、提出、差戻し、再提出は配置していないため対象外",
期間: "この演習の1回の実行（実際の利用期間ではない）",
確認項目: ["判定を行った件数", "許可された件数", "拒否された件数", "エラー（例外）の有無", "想定と異なる操作パターンの有無"],
};
console.log("手順2：初期利用の範囲");
for (const [k, v] of Object.entries(plan)) console.log(` ${k}: ${Array.isArray(v) ? v.join("、") : v}`);
// 手順3：配置したデータに対して、承認者役の操作（承認できるかの判定）を行う
const { canApprove } = require(path.join(SANDBOX_DIR, "app", "approval.js"));
const requests = JSON.parse(fs.readFileSync(path.join(SANDBOX_DIR, "data", "requests.json"), "utf8"));
// 演習で行う操作（架空）。最後の1件は「割当外の承認者が承認を試みる」という想定外の操作パターン
const operations = [
{ actor: "鈴木", requestId: "REQ-OLD-001", note: "割当承認者による承認" },
{ actor: "鈴木", requestId: "REQ-OLD-002", note: "割当承認者による承認" },
{ actor: "佐藤", requestId: "REQ-OLD-005", note: "割当承認者による承認" },
{ actor: "高橋", requestId: "REQ-OLD-001", note: "割当外の承認者が承認を試みる（想定外の操作パターン）" },
];
console.log("手順3：承認者役の操作を配置したデータに対して行う");
const log = [];
let errors = 0;
for (const op of operations) {
const req = requests.find((r) => r.id === op.requestId);
let result;
try {
result = canApprove(req.state, req.approver === op.actor, req.requester === op.actor);
} catch (e) {
errors++;
result = `例外: ${e.message}`;
}
const entry = { actor: op.actor, requestId: op.requestId, state: req.state, approver: req.approver, result, note: op.note };
log.push(entry);
console.log(` ${op.actor} が ${op.requestId}（状態=${req.state}、割当=${req.approver}）を承認できるか → ${result}（${op.note}）`);
}
// 手順4：確認記録（正常の記録と異常の兆候を分ける）
const allowed = log.filter((e) => e.result === true).length;
const denied = log.filter((e) => e.result === false).length;
const unusual = log.filter((e) => e.note.includes("想定外"));
const record = {
版: manifest.version,
配置日時: manifest.deployedAt,
対象者: plan.対象者,
機能: plan.機能,
期間: plan.期間,
確認項目: plan.確認項目,
正常の記録: `判定 ${log.length} 件、許可 ${allowed} 件、拒否 ${denied} 件、例外 ${errors} 件。割当承認者による承認 ${allowed} 件はすべて許可された`,
異常の兆候: unusual.map((e) => `${e.actor} による ${e.requestId} への割当外の承認試行が ${unusual.length} 件。判定は拒否（正常な動作）。繰り返される場合は説明不足の兆候として扱う`),
対象外のため未確認: "状態の更新・保存（承認済みへの変更と履歴の記録）、提出・差戻し・再提出、画面の操作、実際の利用者による利用",
実施日: new Date().toISOString().slice(0, 10),
実施者: "Claude Code（演習。実際の利用者ではない）",
};
fs.writeFileSync(RECORD_FILE, JSON.stringify({ record, log }, null, 2));
console.log("手順4：確認記録");
console.log(JSON.stringify(record, null, 2));
console.log(`確認記録と操作の記録を ${path.relative(__dirname, RECORD_FILE)} に保存した`);
// 手順5：範囲を広げる条件・止めて戻す条件の判定（この演習の結果に対して）
const stop = errors > 0 || log.some((e) => e.note.includes("割当外") && e.result === true);
console.log("手順5：判定");
if (stop) {
console.log(" 止めて戻す条件に該当（例外、または許可されないはずの操作が許可された）");
process.exit(1);
}
console.log(" 止めて戻す条件には該当しない。ただし、状態の更新・提出などは配置していないため、この演習で『範囲を広げてよい』と判断できるのは承認可否の判定に限られる");
process.exit(0);「入力→判断・処理→出力→失敗時」の対応：
| 段階 | 内容 |
|---|---|
| 入力 | 11-02の配置（関数と移行データ3件）、第5.1節の計画、第5.2節の操作4件 |
| 判断・処理 | 配置した canApprove に、依頼の状態・割当承認者かどうか・自己承認かどうかを渡して判定する。結果を許可・拒否・例外に数え、想定外の操作パターンを異常の兆候に分ける |
| 出力 | 手順1〜5の表示と、確認記録（JSON）。止めて戻す条件に該当しなければ終了コード 0 |
| 失敗時 | 配置の健全性確認が一致しなければ演習を始めずに終了コード 1。例外が起きた場合、または割当外の承認が許可された場合は「止めて戻す条件に該当」として終了コード 1 |
5.4 演習の設計
| 項目 | 内容 |
|---|---|
| 何のための操作か | 配置した範囲だけで、承認者役の操作を行い、正常の記録と異常の兆候を分けて残す。実際の限定試行で同じ形式の実績記録を取るための予行 |
| 実行前に見るもの | 今いる場所が examples/11-03-initial-use-record/ か。10-02と11-02を順に実行し、../11-02-deploy-record/deploy_target/MANIFEST.json があるか |
| コマンド | node run.js |
| 期待結果 | 手順1で11-02の版・配置日時が表示され健全性確認5件が一致。手順3で割当承認者3件が true、割当外1件が false。手順5で止めて戻す条件に該当せず終了コード0 |
| 結果の読み方 | 「手順1」の版と配置日時が11-02の MANIFEST.json と同じか。「正常の記録」の件数が操作の数と合うか。「異常の兆候」に想定外の操作だけが入っているか |
| 失敗したとき | 配置が無い（終了コード1）→ 10-02・11-02を先に実行する。健全性確認が不一致（終了コード1）→ 11-02の配置を見直す。止めて戻す条件に該当（終了コード1）→ 11-04の切戻しへ |
| 元に戻せるか | この演習は判定関数を呼ぶだけで、配置先のファイルもデータも書き換えない。作るのはこのフォルダの initial_use_record.json だけ |
| 業務運用では誰が実施／判断するか | 実施：対象者（承認者役の業務担当者）。記録の整理：運用担当。範囲を広げる・止める判断：運用管理者（架空）。この演習では実施者は Claude Code |
6. 実行結果（初期利用の確認記録）
examples/11-03-initial-use-record/ で、10-02と11-02を実行したあとに実行した stdout です（整形・省略なし。stderr への出力はありませんでした。手順1の配置日時は11-02を実行するたびに変わります。確認記録の「実施日」は協定世界時（UTC）の日付です）。11-02の配置が無い状態で実行すると、配置を促して終了コード1で止まります（第9節の実行記録）。
$ node run.js
手順1：11-02 が配置した内容を使う（版 v0.1.0-sandbox、配置日時 2026-09-21T01:32:02.210Z）。健全性確認 5件すべて一致
配置元 ../08-01-minimal-example/approval.js → app/approval.js（sha256: 6dc21fe173b6…）
配置元 ../10-02-migration-plan/migrated_requests.json → data/requests.json（sha256: e1ec5e804e69…）
手順2：初期利用の範囲
対象者: 移行データで承認者に割り当てられている2名（鈴木、佐藤）。依頼者役は対象外（提出機能を配置していないため）
機能: 承認可否の判定（canApprove）のみ。状態の更新・保存、提出、差戻し、再提出は配置していないため対象外
期間: この演習の1回の実行（実際の利用期間ではない）
確認項目: 判定を行った件数、許可された件数、拒否された件数、エラー（例外）の有無、想定と異なる操作パターンの有無
手順3：承認者役の操作を配置したデータに対して行う
鈴木 が REQ-OLD-001（状態=提出済み、割当=鈴木）を承認できるか → true（割当承認者による承認）
鈴木 が REQ-OLD-002（状態=提出済み、割当=鈴木）を承認できるか → true（割当承認者による承認）
佐藤 が REQ-OLD-005（状態=提出済み、割当=佐藤）を承認できるか → true（割当承認者による承認）
高橋 が REQ-OLD-001（状態=提出済み、割当=鈴木）を承認できるか → false（割当外の承認者が承認を試みる（想定外の操作パターン））
手順4：確認記録
{
"版": "v0.1.0-sandbox",
"配置日時": "2026-09-21T01:32:02.210Z",
"対象者": "移行データで承認者に割り当てられている2名（鈴木、佐藤）。依頼者役は対象外（提出機能を配置していないため）",
"機能": "承認可否の判定（canApprove）のみ。状態の更新・保存、提出、差戻し、再提出は配置していないため対象外",
"期間": "この演習の1回の実行（実際の利用期間ではない）",
"確認項目": [
"判定を行った件数",
"許可された件数",
"拒否された件数",
"エラー（例外）の有無",
"想定と異なる操作パターンの有無"
],
"正常の記録": "判定 4 件、許可 3 件、拒否 1 件、例外 0 件。割当承認者による承認 3 件はすべて許可された",
"異常の兆候": [
"高橋 による REQ-OLD-001 への割当外の承認試行が 1 件。判定は拒否（正常な動作）。繰り返される場合は説明不足の兆候として扱う"
],
"対象外のため未確認": "状態の更新・保存（承認済みへの変更と履歴の記録）、提出・差戻し・再提出、画面の操作、実際の利用者による利用",
"実施日": "2026-09-21",
"実施者": "Claude Code（演習。実際の利用者ではない）"
}
確認記録と操作の記録を initial_use_record.json に保存した
手順5：判定
止めて戻す条件には該当しない。ただし、状態の更新・提出などは配置していないため、この演習で『範囲を広げてよい』と判断できるのは承認可否の判定に限られるこの結果をひな形の形にまとめた確認記録です。
| 対象者 | 機能 | 期間 | 確認項目 | 正常の記録 | 異常の兆候 | 対象外のため未確認 | 次の範囲への条件 |
|---|---|---|---|---|---|---|---|
| 移行データで承認者に割り当てられている2名（鈴木、佐藤） | 承認可否の判定（canApprove）のみ | この演習の1回の実行 | 判定件数、許可件数、拒否件数、例外の有無、想定外の操作パターンの有無 | 判定4件、許可3件、拒否1件、例外0件。割当承認者による承認3件はすべて許可された | 高橋によるREQ-OLD-001への割当外の承認試行が1件。判定は拒否（正常な動作）。繰り返される場合は説明不足の兆候として扱う | 状態の更新・保存、提出・差戻し・再提出、画面の操作、実際の利用者による利用 | 第8.2節参照 |
7. 確認結果
実行環境：macOS 26.6.2、Node.js v24.18.0（node:fs・node:path のみ使用）、2026-09-21に実行。実行場所は examples/11-03-initial-use-record/。使った配置は examples/11-02-deploy-record/deploy_target/（11-02の正本が作ったもの）だけで、外部のサーバー・サービスには接続していません。stdout・stderr・終了コードをそのまま記録した実行記録は第9節の run_log.md にあります。
| 手順 | 期待結果 | 実際の結果 | 一致 |
|---|---|---|---|
| 手順1 11-02の配置の確認 | 11-02の MANIFEST.json の版・配置日時が表示され、健全性確認5件が一致 | 版 v0.1.0-sandbox、5件すべて一致 | 一致 |
| 11-02未配置での実行 | 配置を促して終了コード1 | 「11-02 の配置が見つかりません」で終了コード1 | 一致 |
| 手順3 割当承認者による承認3件 | すべて true | true が3件 | 一致 |
| 手順3 割当外の承認試行1件 | false（拒否） | false | 一致 |
| 手順5 判定 | 止めて戻す条件に該当せず、終了コード0 | 該当せず、終了コード0 | 一致 |
完了条件との照合：
| 完了条件 | 確認結果 |
|---|---|
| 対象者・機能・時間帯の絞り込みが書かれている | 第5.1節に記載。いずれも11-02で配置した範囲の中 |
| 正常利用と異常の兆候が別欄にある | 第6節の表に別欄で記載。どちらも演習で実際に観測した結果 |
| 範囲拡大と中止の条件がある | 第8.2節に記載 |
この記事で確かめたこと：11-02が配置した内容（版・配置日時・配置元の指紋が MANIFEST.json と一致）に対して、承認者役の操作4件の結果。止めて戻す条件に該当しないこと。
この記事で確かめていないこと：
| 範囲 | 理由 | どこで確かめるか |
|---|---|---|
| 実際の利用者による利用 | 利用者も画面も無い。実施者は実装者と同じAI | 10-04の限定試行へ進む条件が満たされてから、同じ形式で実績を取る |
| 状態の更新・保存、提出・差戻し・再提出 | 11-02が配置していない | 配置に加えてから |
| 期間をまたいだ兆候（繰り返し、苦情） | 1回の実行 | 実際の限定試行の期間中 |
| 操作者が承認者役かどうか（役割の確認） | 配置した canApprove は割当だけを見る。旧データ REQ-OLD-005 の承認者欄が依頼者役の佐藤になっていても判定できない（第5.2節） | 記事Bの役割の確認を題材アプリに適用するときに |
残る制限：この記録は演習であり、実際の利用者による利用の記録ではありません。承認可否の判定以外（状態の更新・保存、提出・差戻し・再提出、画面）は配置していないため、初期利用の対象にできず未確認です。実施者は実装者と同じAI（Claude Code）です。この記事の本文はClaude Codeが作成したもので、業務担当者による内容確認は行っていません。
8. 設計を判断する
8.1 この記事の記録が演習である理由と、初版との違い
実際に動く画面も実際の利用者もまだ無いため、初期利用の記録を実績として取ることはできません。この記事では、11-02で配置したものに対して本物と同じ手順（範囲を絞る→操作する→正常と兆候を分けて記録する→条件と照らす）を演習として行い、その実測を記録しました。実際の利用が始まった段階で、この記事と同じ形式で実績の記録を取る必要があります。
初版のこの記事は、「提出・承認機能まで」を対象に「3件の提出・承認が想定どおり進む想定」と書いていました。提出機能は11-02で配置しておらず、操作も行っていなかったため、それは記録ではなく想定でした。対象を「配置した範囲」に絞り、演習で観測した結果だけを記録するように作り直しています。
8.2 範囲を広げる条件と、止めて戻す条件
| 条件の種類 | 内容 |
|---|---|
| 範囲を広げる条件 | 演習で例外が無く、許可されないはずの操作が許可されていないこと（今回は該当）。ただし広げられるのは配置した範囲の中だけであり、提出・差戻し・再提出や状態の更新は、それらを実装・配置し、10-01の受入確認を経てから対象に加える |
| 止めて戻す条件 | 権限判定の誤り（割当外・自己承認が許可される）、例外の発生、データの不整合、利用者からの複数の苦情が確認された場合。この場合は11-04の切戻し手順に従う。演習コードは前者2つを終了コード1で示す |
9. 持ち帰る成果物
| 成果物 | 空欄版 | 記入例 |
|---|---|---|
| 初期利用の確認記録ひな形（対象者、機能、期間、確認項目、正常の記録、異常の兆候、対象外のため未確認、次の範囲への条件） | templates/11-03-initial-use-record_template.md | templates/11-03-initial-use-record_example.md |
| 初期利用の演習コード（配置は11-02の正本を使う） | examples/11-03-initial-use-record/（run.js） | 同上 |
| 実行記録（stdout・stderr・終了コード、整形なし） | — | evidence_public/final-audit-2026-09-21/11-03/run_log.md（第6節の出力。Phase 5B-2C1 時点の記録は evidence_public/phase5b2c1-2026-09-21/11-03/run_log.md（Remediation Phase 1 時点の記録は evidence_public/remediation1-2026-09-20/11-03/run_log.md） |
自分の業務に使うときの手順は次のとおりです。
- 実際に配置したものの範囲を確認し、その中から対象者・機能・期間を絞った初期利用計画を作る
- 確認項目を決め、実際に行った操作の結果だけを、正常の記録と異常の兆候に分けて記録する
- 対象外にした機能を「未確認」として明記する
- 期間終了時に、範囲を広げる条件・止めて戻す条件と照らして判断する
10. 次工程への受渡し
次へ渡すもの：初期利用の確認記録（演習）、対象外のため未確認の一覧。
次工程での使われ方：11-04（切戻しと初期安定を確認する）では、この確認記録をもとに初期安定を確認し（演習である点を引き継ぎます）、同じ配置サンドボックスで切戻しを演習します。12-01（稼働状況・業務結果・費用を把握する）では、この確認項目を運用項目の土台として使います。
前工程へ戻る条件：止めて戻す条件に該当する場合は、11-04の切戻しに従い、11-02に戻って配置内容を見直します。初期利用の対象に加えたい機能が配置されていない場合は、08〜11-02へ戻ります。
11. 根拠と更新情報
- この記事の会社・人物・データはすべて架空の設定です。
- 初期利用の対象（
canApproveと移行データ3件、版 v0.1.0-sandbox）は11-02の配置内容、利用開始判定は10-04に基づきます。 - 制作の来歴：本文はClaude Codeが作成しました。第5.3節・第6節の演習コードは
examples/11-03-initial-use-record/run.jsを正本とし、配置はexamples/11-02-deploy-record/deploy.js（11-02の正本）が作ったものを使って、2026-09-21にmacOS 26.6.2・Node.js v24.18.0の環境で実際に実行し、stdout・stderr・終了コードをevidence_public/phase5b2c1-2026-09-21/11-03/run_log.mdに記録しています。人（ユーザー）による実読・内容確認は未実施です。 - 2026-09-20（Remediation Phase 1）：受入監査で「確認記録の全欄が『想定』であり、11-02で配置していない提出機能を対象にしている」と指摘された。対象を11-02で配置した範囲（承認可否の判定）に絞り、演習コードで実際に操作した結果だけを記録する記事に作り直した。
- 2026-09-21（Phase 5B-2C1）：11-02の
deploy.jsが「前工程の実ファイルをコピーして配置し、配置元の指紋を記録する」方式に変わったのに伴い、このフォルダに残っていた旧11-02版（文字列埋め込み）のdeploy.jsのコピーを削除し、run.jsを「11-02の正本が配置したdeploy_target/をそのまま使う（配置し直さない）」形に改めた。これにより、記事の「11-02と同じもののコピー」という説明の不正確さを解消した。あわせて読む順路、第4節の判断項目、第5.4節「演習の設計」、第7節の確かめていないことの表、CHECKLIST、記事間の参照を追加し、実行結果を再実行の実測に置き換えた。演習の操作・確認記録の内容は変えていない。 - 2026-09-21（Final Content Audit）：「対象者」を「承認者役の2名（鈴木、佐藤）」と書いていたが、記事A・01-01では佐藤は依頼者役であり、承認者役は鈴木・高橋である。佐藤が承認者として操作しているのは10-02の旧データ REQ-OLD-005 の承認者欄の値によるものなので、文言を「移行データで承認者に割り当てられている2名」に改め、第5.2節に理由と、配置した
canApproveが役割を見ないことを明記した。run.jsの文言変更に伴い第6節の出力を再実行し、evidence_public/final-audit-2026-09-21/11-03/run_log.mdに記録した（配置元の指紋・操作4件・判定・件数は不変）。 - 未確認事項：実際の利用者による利用とその記録、状態の更新・保存、提出・差戻し・再提出、画面の操作は、この記事の時点では行っていません。