配置前に、公開範囲・接続先・秘密情報など6項目をチェック表で確認する

原稿の管理表（13項目：記事ID・カテゴリ・要件ID・先に読むと理解しやすい記事・成果物パス・対象ツール・検証状況・最終更新日など）

管理項目	内容
記事ID	11-01
主な中カテゴリ	11-01 公開先と設定を確認する
関連中カテゴリ	06-02、06-04、10-04、11-02
関連要件ID	REQ-002
先に読むと理解しやすい記事	06-02（開発・検証・本番を分ける）、06-04（秘密情報と依存する部品を管理する）を読んでいると理解しやすい。未読でも本文で必要な内容は説明する
到達目標	公開範囲、接続先、設定値、秘密情報、権限、費用条件を配置前に確認する理由を説明できる
3層の配置	理解する＝第3〜4節／作って確かめる＝第5〜7節／設計を判断する＝第8節
成果物パス	templates/11-01-prerelease-check_template.md、templates/11-01-prerelease-check_example.md、examples/11-01-prerelease-check/（check_release.js、env.example.txt）、evidence_public/phase5b2c1-2026-09-21/11-01/run_log.md
出典	第11節参照
対象ツール・バージョン	教材演習用にNode.js v24.18.0（node:fs・node:path のみ使用）
検証状況	第5.3節の確認コードは examples/11-01-prerelease-check/ を正本とし、Claude Codeが2026-09-21にローカルで実行して stdout・stderr・終了コードを記録済み（第6〜7節、evidence_public/phase5b2c1-2026-09-21/11-01/run_log.md）。公開範囲・権限・費用条件は確かめる対象が存在せず未確認。人による実読・内容確認は未実施
残課題	第11節参照
最終更新日	2026-09-20（新規作成）。2026-09-21（Phase 5B-2C1：受入監査の「公開範囲・接続先・権限が存在しない・未確認なのに確認者・確認日つきの確認済みに近い扱い」指摘に対し、各項目を「演習で確認」「未確認」「実環境で確認が必要」「止める」に分類する確認コードを作り、実測に置き換えた。存在しない公開設定を確認済みにしない。読む順路・第4節の判断項目・第8.3節「Go判断に必要なもの」も追加）

この記事の会社・人物・データはすべて架空の設定です。実在する会社や案件とは関係ありません。この記事のチェックは、実際に公開・配置する前段階の確認であり、11-02より前に行うものです。実際の公開設定・本番の接続先・本番の権限設定はこの教材には存在しません。存在しないものを「確認済み」とは書きません。第5.3節の確認コードは examples/11-01-prerelease-check/ の正本と同じもので、実行結果は2026-09-21にローカル環境で実際に実行して記録したものです。

この記事は何の話か。アプリを配置する前に、公開範囲・接続先・設定値・秘密情報・権限・費用条件の6項目を公開前チェック表で確認し、「何が確認できていて、何が確認できていないか」を分けて、配置に進んでよいか（Go）を判断する話です。

なぜ必要か。配置してから「社内限定のつもりが誰でも見える状態だった」「本番のつもりが検証用の接続先だった」と気づいては手遅れです。配置前に確認しておく必要があります。同時に、確かめる対象がまだ無い項目を「確認済み」と書いてしまうと、後工程（10-04の判定、11-02の配置）が架空の確認の上に立ちます。

この記事を読むとできるようになること。

• 公開範囲、接続先、設定値、秘密情報、権限、費用条件を配置前に確認する理由を説明できる
• 題材アプリの公開前チェック表を作り、各項目を「演習で確認」「未確認」「実環境で確認が必要」「止める」に分けて記入できる
• 人が必ず目視する項目と自動確認に任せる項目を分け、何がそろえばGo判断できるかを言える

読む順路。この記事は3つの深さで読めます。全部を順に読む必要はありません。

• 基本だけ理解する：第1節→第3節（6項目を確認する理由と、確認の4区分）→第4節（判断すること）→第5.1節（確認方法の表）→第6.2節のチェック結果の表→第9節。コードを動かさなくても、「確認済み」と書けるのはどんなときかが分かります。
• 作って確かめる：上に加えて第5.2節（実行前に見るもの）→第5.3節（確認コード）→第6節（実行結果と読み方）→第7節（確かめたこと・確かめていないこと）。
• 設計判断を深める：上に加えて第8節（目視と自動確認の分担、未確認項目の扱い、Go判断に必要なもの）。

1. 今回の業務課題と完成するもの

この記事でやることは、10-04で「演習成功（限定試行は延期条件付き）」と判定した題材アプリについて、配置サンドボックスへの配置（11-02）に先立ち、公開範囲・接続先・設定値・秘密情報・権限・費用条件の6項目を確認し、公開前チェック結果にまとめることです。

10-04では利用開始の可否を判断しましたが、実際に配置する直前に確認すべき技術的な項目はまだ扱っていませんでした。この記事では、それを扱います。ただし、この教材には実際の公開設定・本番環境・権限設定が存在しないため、6項目のうち今の環境で確かめられるものと、確かめようがないものを分けて記録します。

この記事を読み終えると、次のものが手元にできます。

• 公開前チェック結果（項目、確認方法、結果、区分、確認者、確認日、未確認の扱い）
• 今の環境で確かめられる項目を機械的に確かめ、区分を出す確認コードと実行記録（examples/11-01-prerelease-check/）

2. 前提知識と読む順路

この記事で使う言葉を先に説明します。

公開範囲

一言でいうと、誰がアクセスできるようにするかです。この題材アプリでは「社内限定」を想定しています（架空の仮定）。

接続先

一言でいうと、アプリがどの環境（検証用か本番用か）につながるように設定されているかです。06-02で決めた環境の区別が関わります。

確認の区分（演習で確認／未確認／実環境で確認が必要／止める）

一言でいうと、チェック表の各項目が「どこまで確かめられたか」を表す札です。

たとえば、設定見本に値が入っていないことは今の環境で確かめられるので「演習で確認」。公開設定はまだ存在しないので「実環境で確認が必要」。本番の接続先が設定されていたら「止める」です。

これがないと、「確認した」の一言に、実際に見たものと、見ようがなかったものが混ざり、Go判断の根拠が曖昧になります。

読む順路：環境の区別は06-02、秘密情報の管理は06-04、利用開始判定は10-04が該当します。この記事のチェック結果は、11-02（アプリとデータを配置する）の前提になります。

3. 理解する：なぜ配置前に確認するか

3.1 6項目を確認する理由

3.2 「確認済み」と書けるのは、確かめる対象があるときだけ

結論から言うと、チェック表の「確認済み」は、実際に存在するものを見た結果にだけ付けます。

みらい業務サービスの例で言うと、「公開範囲は社内限定」は設計上の想定です。しかし、この教材の時点では公開設定そのものが存在しません（配置先が03-03で仮置きのままです）。存在しないものを「社内限定になっていることを確認した」と書くと、後で本当に公開設定を作ったときに、誰もそれを見ていないのに「確認済み」の札だけが残ります。この記事では、そのような項目を「実環境で確認が必要」または「未確認」と書き、確かめられる項目（設定見本に値が無い、接続先が本番でない）だけを「演習で確認」と書きます。

3.3 よくある誤解

「配置してから確認すればよい」。配置してから公開範囲の誤りに気づいた場合、その間に外部からアクセスされてしまっている可能性があり、取り返しがつきません。配置前に確認します。

「秘密情報の確認は目視で十分」。06-04で確認したとおり、目視だけに頼ると見落とす可能性があります。機械的に確認できる項目（値が空欄かどうかなど）は、実際にコマンドで確認します（第5.3節）。

「想定どおりなら確認済みでよい」。「社内限定を想定」は確認ではありません。想定と確認を分けないと、チェック表が設計文書の写しになります（10-01の「設計文書に書いてあれば確認したことになる」と同じ誤解）。

4. 判断すること

公開前チェックで人が判断することは、次の5つです。

勝手に決めてはいけないこと：実際に配置・公開したかのように書きません。この記事は配置前の確認です（11-02で配置を扱います）。05-03の権限表、06-04の設定見本にない項目を、この記事で新たに作りません。存在しない公開設定・本番の接続先・権限設定を確認したことにしません。

AIに任せる範囲：チェック表の項目候補の提示、機械的に確かめられる項目の確認コードの下書き、実行して結果をそのまま返すことはAIに任せられます。任せてはいけないのは、各項目の区分を決めること（特に「未確認」を「確認済み」に上げないこと）、止める条件を決めること、目視項目の確認、そしてGoの判断です。AIは「設計上は社内限定です」と「社内限定を確認しました」を混同した文章を書きがちです。

5. 作って確かめる：公開前チェック表を作る

5.1 6項目の確認方法と、今の環境で確かめられるか

5.2 実行前に見るもの

5.3 確認コード

今の環境で確かめられる項目を機械的に確かめ、6項目＋配置元を4区分に分けます（examples/11-01-prerelease-check/check_release.js）。何も書き換えません。

// 教材演習用：配置（11-02）の前に、公開前チェック6項目を「今この環境で確かめられること」に限って機械的に確かめ、
// 各項目を「演習で確認」「未確認」「実環境で確認が必要」のどれかに分類する。
// 実際の公開設定・本番の接続先・本番の権限設定は存在しないため、それらを「確認済み」にはしない。
// Node.js標準機能（node:fs、node:path）のみを使用する。何も書き換えない。
const fs = require("node:fs");
const path = require("node:path");

const ENV_FILE = path.join(__dirname, "..", "06-02-environments", "env-development.json"); // 06-02 の設定（架空）
const SECRETS_EXAMPLE = path.join(__dirname, "env.example.txt");                              // 06-04 と同じ設定見本
const DEPLOY_SOURCES = [                                                                       // 11-02 の配置元
  path.join(__dirname, "..", "08-01-minimal-example", "approval.js"),
  path.join(__dirname, "..", "10-02-migration-plan", "migrated_requests.json"),
];

const items = [];
function add(item, method, result, status, note) { items.push({ item, method, result, status, note }); }

// 1. 公開範囲：この演習に公開設定は存在しない。確かめようがないので「実環境で確認が必要」
add("公開範囲", "公開設定が社内限定になっているかを目視で確認する", "確かめる対象（公開設定）が存在しない", "実環境で確認が必要", "配置先が決まり、公開設定が存在してから、人が目視で確認する");

// 2. 接続先：06-02 の設定ファイルを読み、本番でないことを確かめる（架空の設定に対する演習）
try {
  const env = JSON.parse(fs.readFileSync(ENV_FILE, "utf8"));
  const notProd = env.environment !== "production";
  add("接続先", `06-02 の設定（${path.relative(__dirname, ENV_FILE)}）を読み、environment が production でないことを確かめる`, `environment=${env.environment} / dataType=${env.dataType}`, notProd ? "演習で確認" : "止める（本番）", "架空の設定に対する確認。実際の配置先の接続設定は存在しない");
} catch (e) {
  add("接続先", "06-02 の設定を読む", `読めない（${e.code || e.name}）`, "未確認", "06-02 の examples がそろっているか確認する");
}

// 3. 設定値：設定見本の項目名が 06-04 の見本（DB_CONNECTION_STRING、API_KEY）と一致するか
const expectedKeys = ["DB_CONNECTION_STRING", "API_KEY"];
const lines = fs.readFileSync(SECRETS_EXAMPLE, "utf8").split("\n").filter((l) => l.includes("="));
const keys = lines.map((l) => l.split("=")[0].trim());
const keysOk = expectedKeys.every((k) => keys.includes(k)) && keys.length === expectedKeys.length;
add("設定値", "設定見本の項目名が 06-04 の見本と一致するかを照合する", `項目: ${keys.join(", ")}`, keysOk ? "演習で確認" : "未確認", "設定見本の項目名だけの照合。実際の設定値は存在しない");

// 4. 秘密情報：設定見本に値が入っている行が 0 件か（06-04 の確認コマンドと同じ）
const filled = lines.filter((l) => l.split("=")[1] && l.split("=")[1].trim() !== "");
add("秘密情報", "設定見本で値が入っている行の数を数える（06-04 と同じ確認）", `値が入っている行の数: ${filled.length}`, filled.length === 0 ? "演習で確認" : "止める（値が入っている）", "設定見本に対する確認。実際の設定ファイルは存在しない");

// 5. 権限：権限どおりに動く設定は、画面が無いため確かめられない。判定関数のテスト（09-01）は別の確認
add("権限", "05-03 の権限表どおりに動く設定になっているかを、実際に動く画面で確認する", "確かめる対象（画面・権限設定）が存在しない。判定関数の単体テストは 09-01 で実施済み（権限設定の確認ではない）", "未確認", "画面と権限設定ができてから、業務担当者が受入確認（10-01）で確認する");

// 6. 費用条件：技術選定（03-03）が仮置きのため確定していない
add("費用条件", "費用が発生する条件（従量課金など）を確認する", "技術選定が仮置きのため、費用条件が存在しない", "未確認", "03-03 の技術選定が確定してから確認する");

// 7. 配置元（11-02 が使う前工程の成果物）がそろっているか
const missing = DEPLOY_SOURCES.filter((f) => !fs.existsSync(f)).map((f) => path.relative(__dirname, f));
add("配置元の成果物", "11-02 が配置する前工程の成果物（08-01 の正本、10-02 の出力）が存在するかを確かめる", missing.length === 0 ? "2件とも存在する" : `不足: ${missing.join(", ")}`, missing.length === 0 ? "演習で確認" : "止める（配置元が無い）", "10-02 の出力は 10-02 を実行しないと存在しない。無ければ 11-02 も止まる");

console.log("公開前チェック（演習）");
for (const i of items) console.log(`  [${i.status}] ${i.item}: ${i.result}`);
const stop = items.filter((i) => i.status.startsWith("止める"));
const rehearsed = items.filter((i) => i.status === "演習で確認").length;
const unverified = items.filter((i) => i.status === "未確認" || i.status === "実環境で確認が必要");
console.log("");
console.log(`集計: 演習で確認 ${rehearsed} 件、未確認・実環境で確認が必要 ${unverified.length} 件、止める ${stop.length} 件`);
if (stop.length > 0) {
  console.log("判定: 止める条件に該当するため、配置に進まない");
  process.exit(2);
}
console.log("判定: 配置サンドボックスへの配置（11-02）には進める。実際の公開（本番）には進めない（未確認・実環境で確認が必要な項目が残るため）");
process.exit(0);

「入力→判断・処理→出力→失敗時」の対応：

6. 実行結果（公開前チェック結果）

6.1 実行結果

examples/11-01-prerelease-check/ で実行した stdout と終了コードです（整形・省略なし。stderr への出力はありませんでした）。

10-02を実行していない状態（配置元が無いので止まる）：

$ node check_release.js
公開前チェック（演習）
  [実環境で確認が必要] 公開範囲: 確かめる対象（公開設定）が存在しない
  [演習で確認] 接続先: environment=development / dataType=架空データのみ
  [演習で確認] 設定値: 項目: DB_CONNECTION_STRING, API_KEY
  [演習で確認] 秘密情報: 値が入っている行の数: 0
  [未確認] 権限: 確かめる対象（画面・権限設定）が存在しない。判定関数の単体テストは 09-01 で実施済み（権限設定の確認ではない）
  [未確認] 費用条件: 技術選定が仮置きのため、費用条件が存在しない
  [止める（配置元が無い）] 配置元の成果物: 不足: ../10-02-migration-plan/migrated_requests.json

集計: 演習で確認 3 件、未確認・実環境で確認が必要 3 件、止める 1 件
判定: 止める条件に該当するため、配置に進まない
終了コード: 2

10-02を実行したあと：

$ node check_release.js
公開前チェック（演習）
  [実環境で確認が必要] 公開範囲: 確かめる対象（公開設定）が存在しない
  [演習で確認] 接続先: environment=development / dataType=架空データのみ
  [演習で確認] 設定値: 項目: DB_CONNECTION_STRING, API_KEY
  [演習で確認] 秘密情報: 値が入っている行の数: 0
  [未確認] 権限: 確かめる対象（画面・権限設定）が存在しない。判定関数の単体テストは 09-01 で実施済み（権限設定の確認ではない）
  [未確認] 費用条件: 技術選定が仮置きのため、費用条件が存在しない
  [演習で確認] 配置元の成果物: 2件とも存在する

集計: 演習で確認 4 件、未確認・実環境で確認が必要 3 件、止める 0 件
判定: 配置サンドボックスへの配置（11-02）には進める。実際の公開（本番）には進めない（未確認・実環境で確認が必要な項目が残るため）
終了コード: 0

結果の読み方：[ ] の中が区分です。「止める」が1件でもあれば終了コード2で、配置に進みません。「止める」が無くても「未確認」「実環境で確認が必要」が残っている間は、判定は「サンドボックスへの配置には進める、実際の公開には進めない」です。「演習で確認」は架空の設定・見本に対する確認であり、実環境の確認ではありません。

6.2 公開前チェック結果

7. 確認結果

実行環境：macOS 26.6.2、Node.js v24.18.0（node:fs・node:path のみ使用）、2026-09-21に実行。教材演習用のフォルダの中で行い、何も書き換えていません。stdout・stderr・終了コードをそのまま記録した実行記録は第9節の run_log.md にあります。

完了条件との照合：

この記事で確かめたこと：架空の設定・見本に対して、接続先が本番でないこと、設定見本の項目名が一致すること、値が入っていないこと、配置元がそろっていること。配置元が無ければ止まること。

この記事で確かめていないこと：

残る制限：この記事のチェックは、実際に配置・公開する前段階のものであり、確かめられた項目も架空の設定・見本に対するものです。この記事の本文はClaude Codeが作成したもので、業務担当者による内容確認は行っていません。

8. 設計を判断する

8.1 人が必ず目視するものと、自動確認に任せるもの

設定値は、設定見本と機械的に突き合わせることもできますが、設定見本自体が正しいかどうかの判断は人が行う必要があります。自動確認は「止める条件」を機械的に見つける役で、Goを出す役ではありません。

8.2 未確認項目の扱い

費用条件のように、前提となる決定（技術選定）がまだ確定していないために確認できない項目は、確認できない理由を明記したうえで未確認とし、前提が確定した段階で確認します。確認せずに「問題なし」として進めることはしません。未確認が残っていても、配置サンドボックス（架空データのみ、外部に公開しない）への配置には進めます。実際の公開には進めません。

8.3 Go判断に必要なもの

「チェック表が全部埋まった」ではなく「止めるが0件で、進む先に必要な区分がそろった」がGoの条件です。

9. 持ち帰る成果物

自分の業務に使うときの手順は次のとおりです。

1. 公開範囲・接続先・設定値・秘密情報・権限・費用の6項目を洗い出し、止める条件を先に決める
2. 人が目視する項目と、自動確認に任せる項目を分ける
3. 確かめる対象があるものだけを確認し、確認者・確認日とともに「演習で確認」または「実環境で確認」と記録する
4. 確かめる対象が無い項目は「未確認」「実環境で確認が必要」とし、理由と確認できる時期を書く
5. 「止める」が0件で、進む先に必要な区分がそろっているかでGoを判断する

10. 次工程への受渡し

次へ渡すもの：公開前チェック結果（区分つき）、未確認の項目とその扱い。

次工程での使われ方：11-02（アプリとデータを配置する）では、このチェック結果で「止める」が0件であることを配置の前提にします。11-02の deploy.js も配置元の存在を確かめてから配置します。未確認の項目（公開範囲・権限・費用）は、10-04の限定試行へ進む条件と合わせて、実環境で確認するまで残ります。

前工程へ戻る条件：権限や設定が05-03・06-04の内容と食い違う場合は、それぞれに戻って確認します。接続先が本番になっていたら06-02に戻ります。

11. 根拠と更新情報

• この記事の会社・人物・データはすべて架空の設定です。
• 環境の区別は06-02、設定見本・確認コマンドは06-04、権限表は05-03、利用開始判定は10-04に基づきます。確認の4区分は、10-01の「観測・演習・未確認」と同じ考え方です。
• 制作の来歴：本文はClaude Codeが作成しました。第5.3節・第6節の確認コードは examples/11-01-prerelease-check/ を正本とし、2026-09-21にmacOS 26.6.2・Node.js v24.18.0の環境で実際に実行して、stdout・stderr・終了コードを evidence_public/phase5b2c1-2026-09-21/11-01/run_log.md に記録しています。人（ユーザー）による実読・内容確認は未実施です。
• 2026-09-21（Phase 5B-2C1）：受入監査で「公開範囲・接続先・権限が実際には存在しない・未確認なのに、確認者・確認日つきの確認済みに近い扱い」と指摘された。各項目を4区分に分ける確認コード（check_release.js）を作って実測に置き換え、存在しない項目は確認者・確認日を空欄にして理由と扱いを書いた。初版の node -e による秘密情報の確認は、正本ファイルとして置き直した。あわせて読む順路、第3.2節、第4節の判断項目、第5.2節「実行前に見るもの」、第7節の確かめていないことの表、第8.3節「Go判断に必要なもの」、CHECKLIST、記事間の参照を追加した。
• 未確認事項：公開範囲・権限・費用条件、実際の設定ファイル・接続設定は、この記事の時点では確認していません（第7節）。