作業フォルダを作り、実行環境を確認コマンドで整える

この記事の会社名・題材フォルダ名は架空の設定です。実在する会社や案件とは関係ありません。本文のコマンドと実行結果は、この記事の作成時に実際にローカル環境で実行して確認したものです（第7節）。教材演習用のフォルダ内だけで完結し、本番環境・実データ・外部サービスへの送信は行っていません。

この記事は何の話か。03-03で技術の選び方の基準を決めましたが、実際に手を動かす場所（作業フォルダ）と、コマンドを打ち込む環境（実行環境）はまだ整っていません。この記事では、それを整え、確認した手順を「環境構築手順」として書き残す話です。

なぜ必要か。作業場所や実行環境の確認を一度だけ口頭やその場の記憶で済ませると、別の端末で作業する人（自分自身の別の日も含む）が同じ状態を再現できず、「私の環境では動いたのに」という食い違いが起こります。

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

• フォルダ・エディタ・コマンド操作・実行環境の役割と、再現手順を残す理由を説明できる
• 題材アプリ用の作業フォルダを作り、実行環境の確認コマンドと結果を環境構築手順に記録できる
• 環境構築の手間と再現性を比較し、手順書のどこまでを人が確認し、どこをAIに任せてよいかを判断できる

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

• 基本だけ理解する：第1節→第3節→第4節→第5.2節の表→第9節。ここまでで「何を確認するか」と「環境構築手順の形」が分かり、ひな形を埋め始められます。
• 作って確かめる：上に加えて第5.3節（AIへの依頼）→第6節（失敗例と直し方）→第7節（実際の実行結果）。
• 設計判断を深める：上に加えて第8節（手順書に残す手間と再現性の比較、適用限界）。

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

この記事でやることは、依頼・承認管理アプリの作業を始めるための作業フォルダを作り、実行環境（この記事の演習ではGit・教材演習用のNode.js）が使える状態かをコマンドで確認し、その手順を「環境構築手順」として書き残すことです。

03-03で「どの技術を選ぶか」の基準は決めましたが、まだ具体的な製品名までは確定していません（技術選定を先走らないため）。この記事では、その決定を待たずに準備できる、作業場所そのものと、確認の仕方を整えます。

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

• 題材アプリ用の作業フォルダ
• 環境構築手順（前提、手順、確認コマンド、期待結果、実行確認済み／未検証、つまずき例）

2. 前提知識と読む順路

この記事で使う言葉を先に説明します。基礎用語（フォルダ・ファイル・エディタ・コマンド・実行環境）は、まだ独立した記事（00-02）がないため、ここで平易に説明します。

フォルダとファイル

一言でいうと、フォルダは書類を整理するための箱、ファイルはその箱の中に入っている1つ1つの書類です。たとえば、「みらい業務サービスの依頼管理アプリ」という1つのフォルダの中に、設定を書いたファイルやプログラムのファイルをまとめて入れます。

これがないと、作業に関係するファイルがパソコンのあちこちに散らばり、どれが最新か、どれが不要かが分からなくなります。

エディタ

一言でいうと、プログラムや設定を書くための、文字入力に特化したアプリです。たとえば、Wordのような文書作成ソフトと違い、ファイルの種類ごとの色分け表示など、プログラムを書きやすくする工夫があります。

これがないと、プログラムの誤字脱字に気づきにくく、修正のたびに手間がかかります。

コマンド（コマンド操作）

一言でいうと、キーボードで文字を打ち込んで、パソコンに指示を出す方法です。たとえば、「このフォルダの中身を見せて」という指示を、マウスでクリックする代わりに ls という文字列で行います。

これがないと、同じ操作を何十回も手作業で繰り返すことになり、時間がかかり、間違いも増えます。

システム開発では、コマンドを打ち込む画面のことを「ターミナル」と呼びます。

実行環境

一言でいうと、プログラムを実際に動かすために必要な、パソコン側の準備（プログラムを解釈する仕組みや、その正しいバージョン）です。たとえば、この記事の演習では、教材演習用にNode.jsという実行環境を使います。

これがないと、プログラムを書いても実際に動かして確かめることができません。

システム開発では、実行環境が「ある」か「ない」かだけでなく、「どのバージョンか」まで確認する必要があります。バージョンが違うと、同じプログラムでも動き方が変わることがあるためです。

読む順路：技術選定の基準は03-03が該当します。この環境をもとにした開発・検証・本番の分離は06-02、変更履歴の管理は06-03、最初のコード実装は08-01が該当します。この記事だけでも進められるように、必要な説明は本文に含めています。

3. 理解する：なぜ手順を書き残すか

3.1 「その場で確認して終わり」の危険

3.2 教材演習用の環境と、正式な技術選定は別

この記事の演習では、確認や動作の説明にGit・教材演習用のNode.jsを使います。これは、依頼・承認管理アプリを実際に作るときの正式な言語や保存先を決めるものではありません。03-03で説明したとおり、正式な技術選定はまだ「候補1」という仮置きの段階です。Node.jsを選んだ理由は、このMacに既にサポート中の版（v24.18.0）が入っており、新しくソフトを追加せずに確認できるためです（第11節）。教材演習で使うツールは、あくまで確認の手段として選んだものであり、「このプロジェクトの本番言語としてNode.jsを選定した」という意味ではありません。

3.3 よくある誤解

「動けば確認は済んでいる」。1回動いたことと、別の端末でも同じ手順で動くことは別です。この記事では、確認コマンドと期待結果を記録し、再現できる形にします（第5.2節）。

「エラーメッセージは無視してもう一度実行すればよい」。エラーメッセージには、何が足りないか、どこが間違っているかの手がかりが書かれています。この記事の失敗例（第6節）で、実際のエラーメッセージの読み方を扱います。

「教材演習で使うツールが、そのままこのプロジェクトの正式な技術になる」。第3.2節のとおり、教材演習用の確認と正式な技術選定は別です。

「AIに環境構築をすべて任せればよい」。AIは確認コマンドの候補や、つまずきやすい点の一般的な例を提示できますが、実際にコマンドを実行して結果を確認するのは人が行います。AIに実行結果を推測させたり、断定させたりしません（第4.3節）。

4. 判断すること

4.1 何を確認すればよいか

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

• 03-03でまだ確定していない正式な技術（言語・保存先・配置先）を、この記事で確定しません。
• 本番環境・実データ・外部サービスへの送信を行いません。
• 教材演習専用のフォルダの外（利用者のホームフォルダ全体など）に影響する操作を行いません。
• sudo（管理者権限での実行）や、パソコン全体に影響するインストール（グローバルインストール）を行いません。
• ファイルやフォルダを削除する操作、パスワードや鍵などの秘密情報を扱う操作を行いません。
• 実行していないコマンドの結果を、実行確認済みであるかのように書きません（第7節）。

4.3 AIに任せる範囲

確認コマンドの候補や、一般的なつまずき例の提示はAIに任せられます。しかし、実際にそのコマンドを実行して、どんな結果が返るかを確認するのは人（この記事ではClaude Code自身）が行い、AIに実行結果を推測させたり断定させたりしません。

5. 作って確かめる：環境構築手順を作る

5.1 準備

ターミナル（コマンドを打ち込む画面）が開けることを確認します。この記事の演習では、教材演習専用のフォルダとして 06-01-practice/mirai-business-app という名前を使います（架空の名称）。

5.2 環境構築手順

作業フォルダの範囲：この記事の確認・演習は、教材演習専用のフォルダ（06-01-practice/以下）の中だけで行います。利用者のホームフォルダ全体や、それ以外の場所には影響しません。

5.3 AIに手順の下書きを頼む

確認コマンドの候補と、一般的なつまずき例の下書きをAIに作らせます。

依頼・承認管理アプリの作業を始めるにあたり、作業フォルダを作り、バージョン管理ツールと教材演習用の実行環境が使える状態かを確認したいです。

依頼：
1. 作業フォルダを作るコマンド、Gitとバージョン確認、教材演習用の実行環境のバージョン確認コマンドの候補を挙げてください。
2. それぞれのコマンドで、初心者がつまずきやすい点の一般的な例を挙げてください。

してはいけないこと：
- 実際に実行していない結果を、実行確認済みであるかのように書かないでください。
- 管理者権限（sudo）が必要な操作や、パソコン全体に影響するインストールを提案しないでください。
- 教材演習用の実行環境を、このプロジェクトの正式な技術選定であるかのように書かないでください。

6. 初稿・失敗例・修正

6.1 説明用の失敗例（AIの初稿という設定）

AIへの依頼の結果、次のような下書きが返ってきた、という設定にします（実際のAI出力を観測したものではありません）。

• エラーが出た場合の対処として「sudo npm install -g ... を実行してください」と、管理者権限でのグローバルインストールを提案していた
• 「Node.js 22でも動作確認済みです」と、実際には実行していないバージョンを確認済みであるかのように記載していた

6.2 見つけ方と直し方

• sudoの提案：第4.2節「してはいけないこと」に反します。管理者権限が必要になる時点で、この記事の演習の範囲を超えています。提案を削除し、うまく動かない場合は原因を確認してから対処する、という案内に修正します。
• 未実行のバージョンを確認済みと記載：実際に実行していません。「未検証」に修正します。

指摘：
1. sudoでのインストールは提案しないでください。この記事の演習では管理者権限を使いません。
2. Node.js 22での確認は実施していません。「未検証」としてください。

変えないこと：
- 実際に確認したNode.js v24.18.0での結果は変更しないでください。

6.3 実際に遭遇する失敗例（安全な演習領域での再現）

第5.2節の演習を進める中で、次の2つの失敗を実際に再現し、確認しました（教材演習専用のフォルダの中で行った、危険のない操作です）。

失敗例1：ファイル名を間違えて指定した場合

存在しないファイル missing-file.js を実行しようとすると、次のように表示されます（要点を抜き出したものです。実行結果の全文は下の技術詳細を参照）。

$ node missing-file.js
node:internal/modules/cjs/loader:1520
  throw err;
Error: Cannot find module '/…/mirai-business-app/missing-file.js'
    code: 'MODULE_NOT_FOUND'

読み方：「Cannot find module」「MODULE_NOT_FOUND」は「そのファイルが見つからない」という意味です。ファイル名の打ち間違い、または今いる場所（フォルダ）が違うことが主な原因です。

node:internal/modules/cjs/loader:1520
  throw err;
  ^

Error: Cannot find module '/private/tmp/.../06-01-practice/mirai-business-app/missing-file.js'
    at Module._resolveFilename (node:internal/modules/cjs/loader:1517:15)
    at wrapResolveFilename (node:internal/modules/cjs/loader:1071:27)
    at defaultResolveImplForCJSLoading (node:internal/modules/cjs/loader:1095:10)
    at resolveForCJSWithHooks (node:internal/modules/cjs/loader:1122:12)
    at Module._load (node:internal/modules/cjs/loader:1294:5)
    at wrapModuleLoad (node:internal/modules/cjs/loader:255:19)
    at Module.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:154:5)
    at node:internal/main/run_main_module:33:47 {
  code: 'MODULE_NOT_FOUND',
  requireStack: []
}

Node.js v24.18.0
終了コード: 1

失敗例2：作業フォルダの外で確認しようとした場合

教材演習専用のフォルダの外（利用者のホームフォルダ直下など）で、フォルダの中身を確認しようとすると、次のように表示されます。

$ ls mirai-business-app
ls: mirai-business-app: No such file or directory

読み方：今いる場所に、そのフォルダが無いという意味です。pwd（今いる場所を表示するコマンド）で、自分が今どこにいるかを確認してから、もう一度試します。

7. 確認結果

第5.2節の環境構築手順を、実際にローカル環境で実行した結果と照合します。

実行環境：macOS 26.6.2（Darwin）、2026-09-20に実行。教材演習用の実行環境としてNode.js v24.18.0を使用（このMacに既存のサポート中LTS版。第11節）。

完了条件との照合：

残る制限：この記事で確認したのは、macOS・特定のGit／Node.jsのバージョンでの結果です。別のOS（Windowsなど）や別のバージョンでの確認、複数人での同時作業、別の端末での再現は、この記事の時点では試していません。このMacには/usr/bin/python3 = Python 3.9.6も存在しますが、EOL（サポート終了）のため教材演習の主ランタイムには採用していません（第11節）。この記事の本文はClaude Codeが作成し、主要コマンドは実際に実行して確認し、2026-09-20にユーザーによる実読でPASSしましたが、実際の業務担当者による内容確認は行っていません。

8. 設計を判断する

8.1 手順を書き残す手間と、再現性を比較する

作業フォルダ・実行環境の確認は、これから何度も必要になる作業です（06-02以降、08-01など）。最初に記録の手間をかけても、繰り返し再現できることのほうが、この教材全体にとって価値が大きいと判断し、手順書として残す方法を採用します。

8.2 どこまで人が確認し、どこをAIに任せてよいか

8.3 適用限界

この記事の環境構築手順は、macOS・特定のGit／Node.jsのバージョンでの確認に基づく一例です。Windows等の別のOSでは、コマンドの一部（フォルダの作り方など）が異なります。この記事ではその違いまでは扱いません。

9. 持ち帰る成果物

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

1. 教材演習専用の作業フォルダを作る場所を決める
2. 確認したい対象（バージョン管理ツール、実行環境など）を挙げる
3. 各対象について、確認コマンドと期待結果を書く
4. 実際にコマンドを実行し、結果を記録する（実行確認済み／未検証を区別する）
5. つまずいた点があれば、つまずき例として書き残す

10. 次工程への受渡し

次へ渡すもの：教材演習専用の作業フォルダ、環境構築手順（確認コマンド・実行結果・つまずき例）。

次工程での使われ方：06-02（開発・検証・本番を分ける）、06-03（変更履歴を管理する）、08-01（最小の処理を動かす）では、この手順で確認した作業フォルダ・実行環境を前提に進めます。

前工程へ戻る条件：確認の過程で、03-03の技術選定の基準では対応できない制約が見つかったら、03-03に戻って確認します。

11. 根拠と更新情報

• この記事の会社名・題材フォルダ名はすべて架空の設定です。
• 第6.1節の初稿は説明用の失敗例であり、実際のAI出力を観測した記録ではありません。第6.3節の2つの失敗例は、教材演習専用のフォルダの中で実際に再現し、確認したものです。
• 教材演習用の実行環境と正式な技術選定は別、という考え方は、教材設計書AI_SYSTEM_DEV_BLUEPRINT_v0.1.md第8.4節「技術選定を先走らない」に基づきます。
• 教材演習用ランタイムの選定経緯：このMacで確認したところ、サポート中（EOLでない）のPython 3.10以降は見つかりませんでした（PATH、Homebrew、pyenv、python.orgインストーラ、Xcode Command Line Toolsのいずれにも無し）。既存だったのは/usr/bin/python3 = Python 3.9.6（サポート終了版）のみです。新規インストールは行わず、代わりにこのMacに既に入っていたサポート中のLTSランタイムであるNode.js v24.18.0を教材演習用に採用しました。Python 3.9.6は教材演習の主ランタイムから外していますが、この事実の記録として残しています。
• 制作の来歴：本文はClaude Codeが作成しました。第5.2節・第7節の主要コマンド（git --version、node --version、node -e "console.log(...)"、失敗例1・2）は、2026-09-20にmacOS 26.6.2の環境で実際に実行し、結果を確認しています。作成時点（2026-09-20）では人による実読・内容確認は未実施でした。
• 更新履歴：2026-09-20、ユーザーによる実読でPASS。本文・確認コマンド・実行結果は変更していません。
• 更新履歴：2026-09-20、ユーザーレビューにより、教材演習用ランタイムをEOLのPython 3.9.6から、このMacに既存のサポート中LTS版Node.js v24.18.0へ変更しました。新規ソフトのインストールは行っていません。題材アプリの正式な実装言語（03-03）は変更していません。
• 2026-09-21（Final Content Audit）：第7節の「実行確認済み」に対応する実行記録が evidence_public/ に無かったため、同じ確認コマンド4つを教材演習専用の一時フォルダで再実行し、evidence_public/final-audit-2026-09-21/06-01/run_log.md に記録した。結果は第7節の記載と同一。
• 未確認事項：別のOS（Windows等）での手順、複数人での同時作業、別の端末での再現は、この記事の時点では確認していません。