「今どこにつながっているか」を確認してから操作する

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

管理項目	内容
記事ID	06-02
主な中カテゴリ	06-02 開発・検証・本番を分ける
関連中カテゴリ	06-01、05-04、11-01、12-04
関連要件ID	REQ-008
先に読むと理解しやすい記事	06-01（作業場所と実行環境を整える）を読んでいると理解しやすい。未読でも本文で必要な内容は説明する
到達目標	試してよい場所と実データがある場所を分ける理由と、接続先を確認してから操作する習慣を説明できる
3層の配置	理解する＝第3〜4節／作って確かめる＝第5〜7節／設計を判断する＝第8節
成果物パス	templates/06-02-environments_template.md、templates/06-02-environments_example.md、examples/06-02-environments/（check_env.js、env-development.json、env-staging.json、env-production.json）、evidence_public/phase5b1-2026-09-20/06-02/run_log.md
出典	第11節参照
対象ツール・バージョン	教材演習用にNode.js v24.18.0（06-01で確認済み。node:fs・node:path のみ使用。このプロジェクトの正式な技術選定ではない）
検証状況	本文の演習コードは examples/06-02-environments/ を正本とし、Claude Codeが2026-09-20にローカルで実行して stdout・stderr・終了コードを記録済み（第6〜7節、evidence_public/phase5b1-2026-09-20/06-02/run_log.md）。実際の検証・本番環境は存在せず、設定ファイルはすべて架空。人による実読・内容確認は未実施
残課題	第11節参照
最終更新日	2026-09-20（新規作成。同日、Phase 5B-1：Operate型のPilotとして、読む順路・第4節の判断項目・第5.3〜5.4節の再現可能な演習（目的・実行前に見るもの・コマンド・失敗したとき・元に戻せるか・誰が実施するか）・第6節の実測（正常・本番で止まる・失敗）を追加。確認コマンドを examples/ の正本（check_env.js）に置き換えた。環境一覧・完了条件・成果物は不変）

この記事の会社・人物・環境名はすべて架空の設定です。実在する会社や案件とは関係ありません。本文の演習コードは examples/06-02-environments/ の正本と同じもので、実行結果は2026-09-20にローカル環境で実際に実行して記録したものです（第6〜7節、実行記録は第9節）。3つの設定ファイルはすべて架空の設定で、実際の検証・本番環境や実データは存在しません。

この記事は何の話か。依頼・承認管理アプリを試してよい場所（開発・検証）と、実際の業務データがある場所（本番）を分け、「今どこにつながっているか」を確認してから操作する習慣を、実際に手を動かして作る話です。

なぜ必要か。開発中に試したつもりの操作が、実は本番環境に対して行われていた場合、実際の依頼データを壊してしまう危険があります。AIに操作を頼むときも同じで、AIは「今どこにつながっているか」を自分では知りません。人が確認する手順を持っていないと、AIの速さがそのまま事故の速さになります。

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

• 試してよい場所と実データがある場所を分ける理由を説明できる
• 開発・検証・本番の環境一覧を作り、「今どこにつながっているか」を確認する手順を、実行して結果を読めるところまで身につける
• 環境を3つ持つ費用・手間と、分けない場合の失敗の影響を比較できる

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

• 基本だけ理解する：第1節→第3節（環境を分ける理由）→第4節（判断すること）→第5.2節（環境一覧）→第5.3節の表（演習で何をするか）→第6節の「結果の読み方」→第9節。コードを動かさなくても、「確認してから操作する」が何を確認することかと、本番の設定を読んだら止まるという判定が分かります。
• 作って確かめる：上に加えて第5.4節（確認コード）→第6節（3通りの実行結果）→第7節（確かめたこと・確かめていないこと）。
• 設計判断を深める：上に加えて第8節（環境を分ける費用・手間の比較、適用限界）。

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

この記事でやることは、依頼・承認管理アプリの環境を「開発」「検証」「本番」に分け、それぞれの用途とデータの種別を一覧にし、「今どの環境につながっているか」を確認する手順を作って、実際に実行することです。

06-01では作業場所と実行環境を整えましたが、その環境は「開発」のためのものでした。この記事では、開発・検証・本番という複数の環境をどう分けるかを扱います。

場面で言うと、こうです。みらい業務サービスの依頼・承認管理アプリが本番で使われ始めたあと、開発担当が「差戻し理由の文言を直したい」と考え、AIに「依頼データを1件作って試して」と頼んだとします。このとき今の接続先が本番なら、実際の依頼の一覧に試験用の依頼が1件混ざります。接続先を確認する手順は、この1件を防ぐためのものです。

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

• 環境一覧（環境名、用途、データの種別、接続先の確認手順、操作してよい人）
• 接続先を確認するコードと、3通り（開発・本番・設定ファイルなし）の実行記録（examples/06-02-environments/）

2. 前提知識と読む順路

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

環境（開発・検証・本番）

一言でいうと、同じアプリを動かす場所を、目的ごとに分けたものです。

たとえば、開発は自由に試してよい場所、検証は本番に近い条件で確かめる場所、本番は実際の利用者が使う場所です。

これがないと、開発中のつもりの操作が、実は本番の実データに対して行われてしまう危険があります。

システム開発では、これを環境（environment）と呼び、開発（development）・検証（staging）・本番（production）のように名前を付けて区別します。この記事の設定ファイルもこの名前を使います。

接続先

一言でいうと、今の操作がどの環境（開発・検証・本番）に対して行われるかを示す情報です。

たとえば、設定ファイルに "environment": "production" と書いてあれば、接続先は本番です。

これがないと、画面もコマンドも同じ見た目なので、開発と本番の区別がつきません。

配置

一言でいうと、アプリを実際に動かす場所に置くことです（11-02で扱います）。

読む順路：作業場所と実行環境は06-01が該当します。構成図は05-04が該当します。この記事の環境一覧は、11-01（公開前チェック）、12-04（復元演習の隔離環境）で使います。

3. 理解する：なぜ環境を分けるか

3.1 分けないとどうなるか

結論から言うと、分けないと「試す」と「使う」の区別がなくなり、試した結果が実際の業務に混ざります。

3.2 よくある誤解

「小規模なアプリだから環境を分けなくてよい」。規模が小さくても、実データに誤って影響する危険は変わりません。第8節で、小規模アプリで最低限分けるべき境界を判断します。

「開発環境で動いたから、本番でも同じように動く」。環境によって設定やデータの量が異なることがあり、検証環境で本番に近い条件を確かめる意味があります。

「接続先の確認は面倒なので省略してよい」。確認を省略すると、誤った環境への操作に気づけません。この記事の演習では、確認は1コマンドで、何も書き換えません。省略する理由になるほどの手間ではありません。

「設定ファイルを見ずに、思い込みで環境を判断してよい」。「さっき開発で試していたから今も開発のはず」は確認ではありません。操作の直前に、設定を読んで表示させます。

「検証環境も『試してよい場所』だから実データを入れてよい」。検証環境も架空データのみとし、実データは本番でのみ扱います。

4. 判断すること

環境を分けるときに人が判断することは、次の4つです。

4.1 この記事で判断すること

4.2 勝手に決めてはいけないこと

• 開発・検証環境で、実際の依頼データ（実データ）を扱いません。
• 本番環境への操作条件（誰が、どんな確認を経て操作できるか）を、この記事で緩めません。
• 実際の検証・本番環境の接続先は、この記事では決めません。設定ファイルの値はすべて架空です。

4.3 AIに任せる範囲

確認コードの下書き、設定ファイルの形式の提案、実行結果の整理はAIに任せられます。しかし、実データをどの環境に置くか、本番へ操作する条件、本番の設定を読んだときに止めるかどうかは、運用に責任を持つ人が決めます。AIに操作を頼むときは、手順の先頭に接続先の確認を置き、確認の結果（第6節の判定）を人が読んでから次の操作を頼みます。

5. 作って確かめる：環境一覧を作り、接続先の確認を演習する

5.1 準備

06-01で確認した作業フォルダとNode.js、05-04の構成図（画面・処理・保存先）を用意します。

5.2 環境一覧

本番へ操作する条件：本番環境への操作（配置・設定変更など）は、運用管理者の確認を経てから行うこととします。これは11-01（公開前チェック）で具体化します。

5.3 演習の設計：接続先を確認してから操作する

教材演習では、今どの環境につながっているかを、環境ごとの設定ファイルを読み込んで確認します。実際の配置先が決まっていないので、設定ファイルは3つとも架空です。演習でやること・見ること・失敗したときを先に決めます。

5.4 確認コードと設定ファイル

開発環境の設定ファイルです（examples/06-02-environments/env-development.json）。検証用 env-staging.json、本番用 env-production.json も同じ形式で、environment の値だけが違います。本番用の dataType と connection は「架空の想定」と明記してあり、実際の接続先はありません。

{ "environment": "development", "dataType": "架空データのみ", "connection": "ローカルの練習用フォルダ" }

確認コードです（examples/06-02-environments/check_env.js）。

// 教材演習用：今どの環境につながっているかを、環境ごとの設定ファイルから確認してから操作する。
// 使い方: node check_env.js                       （env-development.json を読む）
//         node check_env.js env-staging.json      （検証環境の設定を読む）
//         node check_env.js env-production.json   （本番の設定を読む → 操作を止める）
// 終了コード: 0＝架空データの環境（操作してよい）、2＝本番（運用管理者の確認が要るため止める）、1＝設定ファイルが読めない
// この確認は設定ファイルを読むだけで、何も書き換えない（元に戻す操作は不要）。
const fs = require("node:fs");
const path = require("node:path");

const file = process.argv[2] || "env-development.json";
let config;
try {
  config = JSON.parse(fs.readFileSync(path.resolve(__dirname, file), "utf8"));
} catch (e) {
  console.error(`設定ファイルが読めません: ${file}（${e.code || e.name}）。今いる場所を pwd で確認し、ファイル名を見直してください`);
  process.exit(1);
}

console.log(`接続先確認: environment=${config.environment} / dataType=${config.dataType} / connection=${config.connection}`);

if (config.environment === "production") {
  console.log("判定: 本番環境です。運用管理者の確認を経ていない操作はここで止めます（記事 第5.2節の「本番へ操作する条件」）");
  process.exit(2);
}
console.log("判定: 架空データの環境です。操作してよい環境です");
process.exit(0);

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

6. 実行結果（演習）

examples/06-02-environments/ で実行した stdout・stderr と終了コードです（整形・省略なし）。

開発の設定を読んだ場合（正常）：

$ node check_env.js
接続先確認: environment=development / dataType=架空データのみ / connection=ローカルの練習用フォルダ
判定: 架空データの環境です。操作してよい環境です
終了コード: 0

本番の設定を読んだ場合（止まる）：

$ node check_env.js env-production.json
接続先確認: environment=production / dataType=実データ（架空の想定。この演習に実データは存在しない） / connection=（架空の設定。演習では接続先は存在しない）
判定: 本番環境です。運用管理者の確認を経ていない操作はここで止めます（記事 第5.2節の「本番へ操作する条件」）
終了コード: 2

設定ファイルが無い場合（失敗）。stdout への出力はなく、stderr に次が出ます：

$ node check_env.js env-missing.json
設定ファイルが読めません: env-missing.json（ENOENT）。今いる場所を pwd で確認し、ファイル名を見直してください
終了コード: 1

結果の読み方：

検証の設定（env-staging.json）も実行し、開発と同じく終了コード0で「操作してよい環境」と判定されました（第9節の実行記録）。

7. 確認結果

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

完了条件との照合：

この演習で確かめたこと：架空の設定ファイル3つに対して、確認コードが接続先を表示し、本番なら止まり、ファイルが無ければエラーで止まること。

この演習で確かめていないこと：

残る制限：この環境一覧は架空の設定です。この記事の本文はClaude Codeが作成したもので、業務担当者による内容確認は行っていません。

8. 設計を判断する

8.1 環境を3つ持つ費用・手間と、分けない場合の影響を比較する

小規模な社内アプリであっても、実データへの影響を防ぐという理由から、最低限「実データを扱う本番」と「架空データのみの開発・検証」を分けることを採用します。検証環境を開発環境と完全に分けるかどうかは、規模や体制によって調整の余地があります。

8.2 本番の設定を読んだとき「止める」か「警告して続ける」か

この教材の題材では、本番作業は11-02の配置手順に限られるため、「止める」を採用しています。

8.3 適用限界

この環境一覧は、架空企業「みらい業務サービス」の小規模な利用を前提にした一例です。実際の検証環境の構築方法や、本番環境への具体的な接続方法は、この記事の範囲外です。

9. 持ち帰る成果物

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

1. 前工程（06-01の作業フォルダ、05-04の構成図）を用意する
2. 開発・検証・本番の環境を挙げ、それぞれの用途とデータの種別を書く
3. 今どの環境につながっているかを確認する手順を作り、正常・本番・失敗の3通りを実際に実行して記録する（第5.3〜6節）
4. 本番へ操作する条件と、本番の設定を読んだときの扱い（止める／警告）を明記する

10. 次工程への受渡し

次へ渡すもの：環境一覧、接続先の確認手順とコード、実行記録。

次工程での使われ方：11-01（公開前チェック）では、この環境一覧を前提に公開前の確認項目を作り、本番へ操作する条件を具体化します。11-02（配置手順）では、配置の直前にこの確認を置きます。12-04（バックアップから復元を確かめる）では、この環境一覧の考え方を隔離環境の定義に使います。

前工程へ戻る条件：環境一覧が05-04の構成図と食い違う場合は、05-04に戻って確認します。

11. 根拠と更新情報

• この記事の会社・人物・環境名はすべて架空の設定です。3つの設定ファイルの値も架空で、実際の接続先はありません。
• 実データを本番以外で扱わないという考え方は、教材設計書AI_SYSTEM_DEV_BLUEPRINT_v0.1.md第5.1節（架空データの原則）に基づきます。
• 制作の来歴：本文はClaude Codeが作成しました。第5.4〜7節の演習コードは examples/06-02-environments/ を正本とし、2026-09-20にmacOS 26.6.2・Node.js v24.18.0の環境で実際に実行して、stdout・stderr・終了コードを evidence_public/phase5b1-2026-09-20/06-02/run_log.md に記録しています。人（ユーザー）による実読・内容確認は未実施です。
• 2026-09-20（Phase 5B-1）：Operate型のPilotとして、読む順路（3つの深さ）、第4節の判断項目、第5.3節の演習の設計（目的・実行前に見るもの・コマンド・期待結果・結果の読み方・失敗したとき・元に戻せるか・誰が実施するか）、第5.4節の確認コード（正本 check_env.js。初版の node -e による1行コマンドは、正本ファイルが無く再現できなかったため置き換えた）、第6節の実測3通り（正常・本番で止まる・失敗）、第7節の確かめていないことの表、第8.2節、記事間の参照を追加した。環境一覧・完了条件は変えていない。
• 未確認事項：実際の検証・本番環境での接続先確認は、この記事の時点では行っていません（第7節）。