用語解説
第5章 手元で動かす作業場
手元で観察し、変更を扱う基本動作を学ぶ部である。 ローカルで動かし、Gitで履歴を残し、Web通信を見て、既存コードを小さく読む。 この部から、実務でそのまま使う技術用語が一気に増える。
この章では、自分のPC（ローカル）でアプリを動かすための基本用語を扱う。現在地とパスの考え方から、CLIでの読み取り操作、開発サーバーの起動と停止、ログの読み方、環境変数まで、実務でそのまま使う言葉を順に解説する。
プロジェクトルート
- 読み：プロジェクトルート（project root）
- 一言で言うと：プロジェクト全体を見渡す基準となるいちばん上のディレクトリ。
- くわしく：プロジェクトルートは、README、依存関係を示すファイル、ソースコードの入口、テスト、設定ファイルがそこから見える場所である。ルートは「根」を意味する。多くのコマンドは現在のディレクトリを基準に動くため、作業の根元を間違えると、コマンド自体は正しくても対象を間違える。だから作業の最初にどこがルートかを確認する。
- 具体例：支援ステータス機能を手元で動かすとき、
package.jsonやsrc/が並ぶディレクトリがプロジェクトルートになる。そこでnpm run devを打てば、期待したpackage.jsonを見て起動できる。 - つまずきやすい点：違うディレクトリにいるのに気づかず、起動や依存関係のインストールをして失敗する。
- 関連語：パス（第5章）、CLI（第5章）、依存関係（第5章）
- テキスト本文での登場箇所：第5章「作業場は、現在地から決まる」
ディレクトリ
- 読み：ディレクトリ（directory）
- 一言で言うと：ファイルやほかのディレクトリをまとめる入れ物。フォルダとほぼ同じ意味。
- くわしく：ディレクトリは、ファイルを階層的に整理するための入れ物である。GUIではフォルダと呼ぶことが多いが、CLIではディレクトリと呼ぶ。
pwdで表示される「いま作業しているディレクトリ」のことを、現在のディレクトリ（カレントディレクトリ）と呼ぶ。多くのコマンドは現在のディレクトリを基準に動くため、どのディレクトリにいるかを意識することが重要である。 - 具体例：支援ステータス機能のコードは
src/というディレクトリにまとまり、テストはtest/というディレクトリに入る。cd srcでsrc/ディレクトリへ移動できる。 - つまずきやすい点：フォルダとディレクトリを別物だと思う。指している対象はほぼ同じである。
- 関連語：プロジェクトルート（第5章）、パス（第5章）、CLI（第5章）
- テキスト本文での登場箇所：第5章「作業場は、現在地から決まる」
pwd
- 読み：ピーダブリューディー（print working directory）
- 一言で言うと：いま作業しているディレクトリを表示するコマンド。
- くわしく：
pwdは print working directory の略で、現在地（カレントディレクトリ）を表示する。多くのコマンドは現在のディレクトリを基準に動くため、作業を始める前にpwdで現在地を確認すると、対象の取り違えを防げる。状態を壊さない読み取り系コマンドなので、迷ったときほど最初に使う。 - 具体例：支援ステータス機能を起動する前に
pwdを打ち、出力がlearning-log-sampleのディレクトリであることを確かめてからnpm run devを実行する。 - つまずきやすい点：
pwdを確認せずにコマンドを打ち、違うディレクトリで起動して失敗する。 - 関連語：ls（第5章）、cd（第5章）、プロジェクトルート（第5章）
- テキスト本文での登場箇所：第5章「作業場は、現在地から決まる」
ls
- 読み：エルエス（list）
- 一言で言うと：ディレクトリの中身を一覧表示するコマンド。
- くわしく：
lsは list の略で、現在のディレクトリにあるファイルやディレクトリを一覧する。ls -laのように後ろにオプションを付けると、隠しファイルも含めて詳しく表示するなど、表示方法を変えられる。中身を見るだけで何も変更しない読み取り系のコマンドなので、現在地の確認と組み合わせて安全に状況を観察できる。 - 具体例：支援ステータス機能のディレクトリで
lsを打ち、package.jsonやsrcが一覧に出ることを確かめてから起動する。package.jsonが見当たらなければ、起動前に現在地を直す。 - つまずきやすい点：オプション（
-laなど）をコマンド名の一部だと思う。lsが道具、-laは表示方法の指定である。 - 関連語：pwd（第5章）、cd（第5章）、CLI（第5章）
- テキスト本文での登場箇所：第5章「作業場は、現在地から決まる」
cd
- 読み：シーディー（change directory）
- 一言で言うと：作業するディレクトリを移動するコマンド。
- くわしく：
cdは change directory の略で、現在のディレクトリを別の場所へ移す。多くのコマンドは現在のディレクトリを基準に動くため、対象のプロジェクトルートへcdしてから作業するのが基本である。移動先はパスで指定する。相対パスでも絶対パスでも指定できる。 - 具体例：支援ステータス機能を動かすとき、
cd starter-apps/learning-log-sampleでプロジェクトルートへ移動してからnpm run devを実行する。 - つまずきやすい点：移動したつもりが移動できていない。
cdのあとにpwdで現在地を確かめると確実である。 - 関連語：pwd（第5章）、ls（第5章）、パス（第5章）
- テキスト本文での登場箇所：第5章「作業場は、現在地から決まる」
パス
- 読み：パス（path）
- 一言で言うと：ファイルやディレクトリの場所を表す住所。
- くわしく：パスは、ファイルやディレクトリがどこにあるかを示す文字列である。住所のように、目的の場所までの道順を表す。パスには絶対パスと相対パスの二種類があり、どちらの書き方かで指す場所が変わる。コマンドの対象を間違えないために、パスがどの基準で書かれているかを意識する必要がある。
- 具体例：支援ステータス機能の入口ファイルは
src/server.jsというパスで指す。プロジェクトルートにいれば期待したファイルを指すが、別の場所にいると同じ文字列でも違う場所を指すことがある。 - つまずきやすい点：同じパス文字列なら、どこで打っても同じファイルを指すと思い込む。相対パスは現在地によって指す先が変わる。
- 関連語：絶対パス（第5章）、相対パス（第5章）、プロジェクトルート（第5章）
- テキスト本文での登場箇所：第5章「作業場は、現在地から決まる」
絶対パス
- 読み：ぜったいパス（absolute path）
- 一言で言うと：PCのいちばん上の階層からたどる、どこから見ても同じ住所。
- くわしく：絶対パスは、ファイルシステムの最上位（ルート）から目的地までを完全に書いたパスである。現在地がどこであっても同じ場所を指すため、誤解が起きにくい。一方で長くなりやすく、別のPCでは同じ絶対パスが存在しないこともある。確実に同じ場所を指したいときに使う。
- 具体例：支援ステータス機能のコードが
/Users/you/projects/learning-log-sample/src/server.jsにあるとき、この書き方なら、どのディレクトリから参照しても同じファイルを指す。 - つまずきやすい点：自分のPCの絶対パスを他人と共有しても、相手の環境には同じパスが無いことが多い。
- 関連語：相対パス（第5章）、パス（第5章）、プロジェクトルート（第5章）
- テキスト本文での登場箇所：第5章「作業場は、現在地から決まる」
相対パス
- 読み：そうたいパス（relative path）
- 一言で言うと：いまいる場所を基準にした住所。
- くわしく：相対パスは、現在のディレクトリを起点にして目的地を表すパスである。短く書けて、プロジェクト内で共有しやすい。ただし起点が変わると指す先も変わるため、どこから実行するかが大切になる。READMEや設定ファイルでは相対パスがよく使われる。
- 具体例：支援ステータス機能で
src/server.jsと書けば、プロジェクトルートにいるときは入口ファイルを指す。しかし別のディレクトリにいると、同じ文字列でも何も見つからないことがある。 - つまずきやすい点：相対パスは現在地によって指す先が変わることを忘れる。実行前に
pwdで起点を確かめる。 - 関連語：絶対パス（第5章）、パス（第5章）、pwd（第5章）
- テキスト本文での登場箇所：第5章「作業場は、現在地から決まる」
README
- 読み：リードミー（README）
- 一言で言うと：プロジェクトの入口として最初に読む説明文書。
- くわしく：READMEは、プロジェクトの概要、前提となるランタイム、依存関係の入れ方、起動コマンド、環境変数、テスト方法、既知の制約などを書いた文書である。初めて見るプロジェクトでは、まずここを読むと迷いにくい。起動コマンドだけを拾うと、前提を飛ばして失敗したときに戻る場所がなくなる。実行手順は記憶ではなく、READMEを根拠に確認する。
- 具体例：支援ステータス機能を動かす前にREADMEを読み、Node.jsのバージョン条件や
npm run devの手順、APIの例を確認してから起動する。 - つまずきやすい点：起動コマンドだけをコピーし、前提ランタイムや環境変数の説明を読み飛ばす。
- 関連語：package.json（第5章）、ランタイム（第5章）、環境変数（第5章）
- テキスト本文での登場箇所：第5章「まず壊さずに読む」
package.json
- 読み：パッケージジェイソン（package.json）
- 一言で言うと：Node.jsプロジェクトの設定や依存関係をまとめたファイル。
- くわしく：
package.jsonは、Node.jsプロジェクトでスクリプト、必要なバージョン条件、依存パッケージなどを記述するファイルである。scriptsにはnpm run devやnpm testで実行する内容を書く。enginesには必要なNode.jsのバージョン条件を書く。dependenciesとdevDependenciesには外部パッケージを書く。privateが真なら公開配布用ではないことを示す。何のコマンドが何を動かすかは、ここを見て確認する。 - 具体例：支援ステータス機能の
package.jsonを見ると、scripts.devがnode src/server.js、engines.nodeが>=18.18であると分かり、起動方法と必要なバージョンが確認できる。 - つまずきやすい点：
scriptsやenginesを見ずにコマンドだけ打ち、何が動くか分からないまま実行する。 - 関連語：依存関係（第5章）、ランタイム（第5章）、npm（第5章）
- テキスト本文での登場箇所：第5章「まず壊さずに読む」
lockファイル
- 読み：ロックファイル（lock file）
- 一言で言うと：依存パッケージの実際のバージョンを固定して記録するファイル。
- くわしく：lockファイルは、依存関係を入れたときに、どのパッケージのどのバージョンが実際に使われたかを記録するファイルである。npmでは
package-lock.jsonがこれにあたる。これがあると、別のPCでも同じバージョンの依存関係を再現でき、「自分の環境だけ動く」を防ぎやすい。package.jsonがバージョンの条件を書くのに対し、lockファイルは確定した結果を書く。 - 具体例：支援ステータス機能のディレクトリに
package-lock.jsonがあれば、チームの誰が依存を入れても同じバージョンで揃い、再現性が高まる。 - つまずきやすい点：
package.jsonと lockファイルの役割を混同する。前者は条件、後者は確定結果である。 - 関連語：package.json（第5章）、依存関係（第5章）、再現性（第5章）
- テキスト本文での登場箇所：第5章「この章でできるようになること」
ランタイム
- 読み：ランタイム（runtime）
- 一言で言うと：コードを動かすための土台となる実行環境。
- くわしく：ランタイムは、書いたコードを実際に実行するための土台である。Node.jsはJavaScriptを動かすランタイムの代表例である。ランタイムやそのバージョンが違うと、同じコードでも動き方が変わることがある。だからプロジェクトのREADMEや
package.jsonで、必要なランタイムとバージョンを確認する。 - 具体例：支援ステータス機能はNode.js 18.18以上で動く。手元のNode.jsがその条件を満たすかを
node --versionで確かめてから起動する。 - つまずきやすい点：ランタイムのバージョンを確認せず、条件を満たさない環境で起動して失敗する。
- 関連語：Node.js（第5章）、package.json（第5章）、環境変数（第5章）
- テキスト本文での登場箇所：第5章「まず壊さずに読む」
依存関係
- 読み：いぞんかんけい（dependency）
- 一言で言うと：アプリが動くために必要な外部のライブラリやパッケージ。
- くわしく：依存関係（依存パッケージ）は、自分のコードが使う外部のライブラリやパッケージである。Node.jsでは
package.jsonのdependenciesやdevDependenciesに書かれ、npm installで取り込む。依存パッケージのバージョンが違うと動き方が変わることがあるため、バージョンの管理が重要になる。外部依存が無いプロジェクトもある。 - 具体例：支援ステータス機能の題材アプリは外部npmパッケージに依存しないため、
npm installを省いてnpm run devから始められる。一方、実務のプロジェクトには依存があることが多い。 - つまずきやすい点：どのプロジェクトでも必ず
npm installが要ると思い込む。要否はそのプロジェクトのREADMEとpackage.jsonで確認する。 - 関連語：package.json（第5章）、ランタイム（第5章）、npm（第5章）
- テキスト本文での登場箇所：第5章「まず壊さずに読む」
CLI
- 読み：シーエルアイ（Command Line Interface）
- 一言で言うと：文字でコマンドを入力して操作する入口。
- くわしく：CLIは Command Line Interface の略で、文字でコマンドを打ってPCやアプリを操作する仕組みである。ボタンやメニューで操作するGUI（Graphical User Interface）と違い、CLIの操作は文字として残しやすい。そのため同じ手順を共有したり、失敗した操作を相談したりしやすい。コマンドは道具の名前とオプションなどの部品に分けて読める。
- 具体例：支援ステータス機能の起動手順を
pwd→npm run devのように文字で残せば、ほかのメンバーが同じ手順を再現できる。 - つまずきやすい点：短い単語や記号が多いので難しく見えるが、
ls -laのように「道具＋指定」の部品に分けて読める。 - 関連語：GUI（第5章）、ターミナル（第5章）、ログ（第5章）
- テキスト本文での登場箇所：第5章「CLIは、操作を文字として残す入口である」
GUI
- 読み：ジーユーアイ（Graphical User Interface）
- 一言で言うと：ボタンやメニューを画面で操作する入口。
- くわしく：GUIは Graphical User Interface の略で、画面上のボタン、メニュー、アイコンなどを使って操作する仕組みである。直感的に使える一方、行った操作が文字として残りにくく、同じ手順を正確に共有しづらい。CLIと対比される概念で、両者は競合ではなく、目的に応じて使い分ける。
- 具体例：支援ステータス機能の画面をブラウザで開いてクリックするのはGUI操作である。一方、起動手順を共有するときは、文字に残るCLIが向いている。
- つまずきやすい点：GUIとCLIのどちらかが優れていると考える。実際は目的によって使い分ける。
- 関連語：CLI（第5章）、エディタ（第5章）
- テキスト本文での登場箇所：第5章「CLIは、操作を文字として残す入口である」
ターミナル
- 読み：ターミナル（terminal）
- 一言で言うと：コマンドを入力し、その出力を表示する画面。
- くわしく：ターミナルは、CLIのコマンドを打ち込み、結果を文字で表示するための画面（ソフト）である。ここで
pwdやnpm run devなどを実行する。開発サーバーを起動したターミナルは、サーバーが動いている間は戻ってこないことがある。停止するときは、起動したのと同じターミナルでCtrl+Cを押すのが基本である。 - 具体例：支援ステータス機能を起動したターミナルにはURLとログが表示される。別の確認をしたいときは、もう一つ別のターミナルを開いて
curlなどを実行する。 - つまずきやすい点：起動でターミナルが戻ってこないのを「固まった」と誤解する。サーバーが動き続けている状態のことが多い。
- 関連語：CLI（第5章）、プロセス（第5章）、Ctrl+C（第5章）
- テキスト本文での登場箇所：第5章「CLIは、操作を文字として残す入口である」
Node.js
- 読み：ノードジェイエス（Node.js）
- 一言で言うと：JavaScriptをPC上で動かすためのランタイム。
- くわしく：Node.jsは、ブラウザの外でJavaScriptを実行するためのランタイムである。サーバーやコマンドラインツールを作るのに広く使われる。プロジェクトごとに必要なバージョンが決まっていることがあり、
package.jsonのengines.nodeに条件が書かれる。node --versionで、いま使っているバージョンを確認できる。 - 具体例：支援ステータス機能はNode.js 18.18以上で動く。
node --versionの結果がその条件を満たすかを確かめてからnpm run devを実行する。 - つまずきやすい点：Node.jsとnpmを同じものだと思う。Node.jsが実行環境、npmが付属するパッケージ管理ツールである。
- 関連語：npm（第5章）、ランタイム（第5章）、package.json（第5章）
- テキスト本文での登場箇所：第5章「この章でできるようになること」
npm
- 読み：エヌピーエム（npm／node package manager）
- 一言で言うと：Node.jsの依存パッケージとスクリプトを扱うツール。
- くわしく：npmは、Node.jsに付属するパッケージ管理ツールである。
npm installで依存関係を入れ、npm run devやnpm testでpackage.jsonに書かれたスクリプトを実行する。npm --versionで、いま使っているバージョンを確認できる。プロジェクトの起動やテストの多くは、npm経由のコマンドで行う。 - 具体例：支援ステータス機能では
npm run devで開発サーバーを起動し、npm testでテストを実行する。これらが何を動かすかはpackage.jsonのscriptsで確認できる。 - つまずきやすい点：
npm installを常に最初に打つ必要があると思う。外部依存が無いプロジェクトでは省ける。 - 関連語：Node.js（第5章）、package.json（第5章）、依存関係（第5章）
- テキスト本文での登場箇所：第5章「この章でできるようになること」
標準出力
- 読み：ひょうじゅんしゅつりょく（standard output／stdout）
- 一言で言うと：コマンドの通常の結果を流す出力の流れ。
- くわしく：標準出力（stdout）は、コマンドが正常な結果を表示するための流れである。これに対し、エラーや警告は標準エラー（stderr）という別の流れに出る。両者を分けて見ると、普通の結果とエラーを区別しやすい。OSの仕組みを細かく理解する必要はないが、出力を一つの大きな塊として見ないことが、ログを読む第一歩になる。
- 具体例：支援ステータス機能を起動すると、
listening on http://localhost:3000のような起動メッセージが標準出力に表示される。 - つまずきやすい点：標準出力と標準エラーを区別せず、出力全体をひとまとめに眺めてしまう。
- 関連語：標準エラー（第5章）、終了コード（第5章）、ログ（第5章）
- テキスト本文での登場箇所：第5章「出力は、成功と失敗の手がかりである」
標準エラー
- 読み：ひょうじゅんエラー（standard error／stderr）
- 一言で言うと：エラーや警告を流す出力の流れ。
- くわしく：標準エラー（stderr）は、コマンドがエラーや警告を表示するための流れである。通常の結果を流す標準出力とは別の流れになっている。分けておくことで、正常な出力に紛れずエラーや警告を拾いやすい。ログを読むときは、結果だけでなく、ここに出る警告やエラー名にも注目する。
- 具体例：支援ステータス機能の起動でポートが使われていると、
Error: listen EADDRINUSE ...のようなメッセージが標準エラーに出る。これが原因の手がかりになる。 - つまずきやすい点：エラーの最後の一行だけを見て原因を断定する。最初に失敗した場所も確認する。
- 関連語：標準出力（第5章）、終了コード（第5章）、ログ（第5章）
- テキスト本文での登場箇所：第5章「出力は、成功と失敗の手がかりである」
終了コード
- 読み：しゅうりょうコード（exit code／exit status）
- 一言で言うと：コマンドが成功したか失敗したかを表す数字。
- くわしく：終了コードは、コマンドが終わったときに返す数字で、成功か失敗かを示す。慣例として0が成功、0以外が失敗を表す。標準出力や標準エラーの内容だけでなく、終了コードを見ると、コマンドが本当に成功したかを機械的に判断できる。ログを読むときは、結果と終了したかどうかを分けて見る。
- 具体例：支援ステータス機能のテストを
npm testで実行したとき、終了コードが0なら成功、0以外なら失敗を意味する。 - つまずきやすい点：終了コードを意識せず、画面の表示だけで成功と判断する。0が成功という慣例も覚えておく。
- 関連語：標準出力（第5章）、標準エラー（第5章）、ログ（第5章）
- テキスト本文での登場箇所：第5章「出力は、成功と失敗の手がかりである」
ログ
- 読み：ログ（log）
- 一言で言うと：実行中に出力される記録のメッセージ。
- くわしく：ログは、コマンドやアプリが動いている間に出力する記録である。起動の成功、URL、警告、エラーなどが含まれる。ログは成功と失敗の手がかりになるため、一つの大きな塊として見ず、通常の結果、警告、エラー、終了状態を分けて読む。長いログを全部理解できなくても、実行した場所、コマンド、期待結果、実際の結果、主要なエラー名を残すだけで相談の質が上がる。
- 具体例：支援ステータス機能を起動したときのログに
listening on http://localhost:3000と出れば成功の手がかりになり、EADDRINUSEと出ればポート競合の手がかりになる。 - つまずきやすい点：エラーログの最後の一行だけを見て原因を断定する。最初に失敗した場所や対象ファイルも見る。
- 関連語：標準出力（第5章）、標準エラー（第5章）、CLI（第5章）
- テキスト本文での登場箇所：第5章「出力は、成功と失敗の手がかりである」
ローカル
- 読み：ローカル（local）
- 一言で言うと：自分の手元のPC上のこと。
- くわしく：ローカルは、自分の手元のPCの中を指す言葉である。本番サーバーや他人の環境ではなく、自分のPCで動かすことを「ローカルで動かす」と言う。ローカル開発サーバーを起動するとは、自分のPCの中でアプリを確認できる状態にすることである。ローカルで再現できることが、変更を安全にチームへ渡す前提になる。
- 具体例：支援ステータス機能をローカルで起動し、自分のPCのブラウザで画面を確認してから、変更をレビューに回す。
- つまずきやすい点：ローカルで動いたから本番でも必ず動くと考える。環境やバージョンの違いで動き方が変わることがある。
- 関連語：localhost（第5章）、開発サーバー（第5章）、再現性（第5章）
- テキスト本文での登場箇所：第5章「ローカル開発サーバーを起動し、止める」
開発サーバー
- 読み：かいはつサーバー（development server）
- 一言で言うと：開発中のアプリを手元で確認するために動かすサーバー。
- くわしく：開発サーバーは、開発中のアプリをローカルで動かして確認するためのサーバーである。起動するとURLが表示され、ブラウザからアクセスできる。多くの場合、動き続けるプロセスとして起動し、停止するまでアクセスを待ち受ける。起動できることだけでなく、アクセスできること、ログが出ること、止められることまでを確認する。
- 具体例：支援ステータス機能で
npm run devを実行すると開発サーバーが起動し、http://localhost:3000で一覧画面を確認できる。使い終わったらCtrl+Cで止める。 - つまずきやすい点：起動できたことだけで満足する。アクセス、ログ、停止までをセットで確認する。
- 関連語：ローカル（第5章）、localhost（第5章）、ポート（第5章）、プロセス（第5章）
- テキスト本文での登場箇所：第5章「ローカル開発サーバーを起動し、止める」
localhost
- 読み：ローカルホスト（localhost）
- 一言で言うと：このPC自身を指す名前。
- くわしく：localhostは、いま操作しているPC自身を指す特別な名前である。ローカルで起動したサーバーへアクセスするときに使う。
http://localhost:3000は、このPC自身の3000番ポートで待ち受けているサーバーへアクセスする、という意味になる。外部に公開された住所ではなく、自分のPCの中で完結するアクセス先である。 - 具体例：支援ステータス機能の開発サーバーを起動すると、
http://localhost:3000が表示され、自分のPCのブラウザでその住所を開くと画面を確認できる。 - つまずきやすい点：localhostのURLを他人に渡しても、その人のPCでは別のものを指す。共有できるアクセス先ではない。
- 関連語：ローカル（第5章）、ポート（第5章）、開発サーバー（第5章）
- テキスト本文での登場箇所：第5章「ローカル開発サーバーを起動し、止める」
ポート
- 読み：ポート（port）
- 一言で言うと：同じPCの中で通信先を区別する番号。
- くわしく：ポートは、同じPCの中で複数の通信の入口を区別するための番号である。たとえば3000番ポートと8080番ポートは別の入口になる。サーバーは特定のポートで待ち受け、URLの
:3000の部分がそれにあたる。一つのポートは同時に一つのプロセスしか使えないため、すでに使われていると競合のエラーが出る。 - 具体例：支援ステータス機能の開発サーバーは3000番ポートで待ち受ける。すでに別のサーバーが3000番を使っていると、
address already in use :::3000のエラーになる。 - つまずきやすい点：開発サーバーを止めずに重ねて起動し、前のプロセスが同じポートを使い続けて競合する。
- 関連語：localhost（第5章）、プロセス（第5章）、EADDRINUSE（第5章）
- テキスト本文での登場箇所：第5章「ローカル開発サーバーを起動し、止める」
プロセス
- 読み：プロセス（process）
- 一言で言うと：PC上で実行中の一つの仕事。
- くわしく：プロセスは、PC上で実行中のプログラムの単位である。開発サーバーを起動すると、多くの場合、動き続けるプロセスになる。起動後にターミナルが戻ってこないのは、プロセスが動き続けてアクセスを待っているからのことが多い。使い終わったらプロセスを止める。止め方を知らないまま起動を重ねると、前のプロセスがポートを使い続けて競合する。
- 具体例：支援ステータス機能を起動するとサーバーのプロセスが動き続ける。
Ctrl+Cでそのプロセスを止める。lsof -i :3000で、どのプロセスがポートを使っているか確認できることもある。 - つまずきやすい点：見つけたプロセスを無条件に終了してよいと思う。自分のものかチームで使うものか分からないときは止める前に相談する。
- 関連語：ポート（第5章）、Ctrl+C（第5章）、開発サーバー（第5章）
- テキスト本文での登場箇所：第5章「ローカル開発サーバーを起動し、止める」
Ctrl+C
- 読み：コントロールシー（Ctrl+C）
- 一言で言うと：実行中のコマンドやサーバーを止めるキー操作。
- くわしく：
Ctrl+Cは、ターミナルで動いているコマンドやプロセスに停止を伝えるキー操作である。開発サーバーを止める基本の方法で、起動したターミナルで押す。止め方を知らないまま起動を重ねると、前のサーバーが同じポートを使い続けて競合の原因になる。停止までを手順として記録しておくと、再現性が高まる。 - 具体例：支援ステータス機能の開発サーバーを使い終わったら、起動したターミナルで
Ctrl+Cを押して止め、停止方法も手順として記録に残す。 - つまずきやすい点：別のターミナルで
Ctrl+Cを押しても、起動したプロセスは止まらない。起動したターミナルで押す。 - 関連語：プロセス（第5章）、ターミナル（第5章）、開発サーバー（第5章）
- テキスト本文での登場箇所：第5章「ローカル開発サーバーを起動し、止める」
curl
- 読み：カール（curl）
- 一言で言うと：コマンドラインからURLにアクセスして応答を確認するツール。
- くわしく：curlは、CLIからURLへリクエストを送り、その応答を文字で表示するツールである。ブラウザを開かずに、サーバーやAPIが正しく応答するかを確認できる。開発サーバーの動作確認やAPIの結果確認に使える。実行するコマンドは、意味の分かるものに絞り、READMEに書かれているものから選ぶのが安全である。
- 具体例：支援ステータス機能で開発サーバーを起動したあと、別のターミナルで
curl http://localhost:3000/api/mentor/learnersを実行し、受講者一覧のAPI応答を確認する。 - つまずきやすい点：記事やAIに出てきたcurlコマンドを、意味を確認せずそのまま実行する。READMEにあるものから選ぶ。
- 関連語：localhost（第5章）、API（第5章）、CLI（第5章）
- テキスト本文での登場箇所：第5章「ローカル開発サーバーを起動し、止める」
API
- 読み：エーピーアイ（Application Programming Interface）
- 一言で言うと：プログラム同士がやり取りするための窓口。
- くわしく：APIは Application Programming Interface の略で、あるプログラムの機能やデータを、別のプログラムから決まった形で呼び出すための窓口である。Webアプリでは、ブラウザの画面側がサーバーのAPIを呼んでデータを取得することが多い。URLの形で提供され、curlやブラウザからアクセスして応答を確認できる。
- 具体例：支援ステータス機能では、画面が
/api/mentor/learnersというAPIを呼んで、メンターが担当する受講者の支援ステータス一覧を取得する。 - つまずきやすい点：画面（GUI）とAPIを同じものと考える。画面はAPIを呼んでデータを表示する側で、APIはデータを返す窓口である。
- 関連語：curl（第5章）、localhost（第5章）、開発サーバー（第5章）
- テキスト本文での登場箇所：第5章「ローカル開発サーバーを起動し、止める」
エディタ
- 読み：エディタ（editor）
- 一言で言うと：コードを書き、プロジェクト全体を見渡すための道具。
- くわしく：エディタは、文字を入力するだけでなく、ファイルを探す、文字列を検索する、エラー（診断）表示を見る、変更前後の差分を見る、といった作業を助ける道具である。CLIが手順を文字として残すのに向くのに対し、エディタはプロジェクト全体の中で今どこを見ているかを把握するのに向く。両方を行き来すると、作業の現在地を失いにくい。
- 具体例：支援ステータス機能のコードを直すとき、エディタの検索で関数名を探し、診断表示で構文エラーに気づき、差分表示で変更箇所を確認する。
- つまずきやすい点：CLIとエディタを競合する道具と考える。実際は役割が違い、組み合わせて使う。
- 関連語：CLI（第5章）、差分（第8章）
- テキスト本文での登場箇所：第5章「エディタは、プロジェクトの地図になる」
環境変数
- 読み：かんきょうへんすう（environment variable）
- 一言で言うと：コードの外から実行時の設定を渡す仕組み。
- くわしく：環境変数は、コードの中に直接書かず、外から実行時に渡す設定値である。ポート番号、接続先、識別子などをコードから切り離して扱える。秘密情報（接続文字列やAPIキー）も環境変数で渡すことが多いため、値の扱いには注意がいる。必要な変数名は
.env.exampleで共有し、実際の値は.envに入れて公開しないのが基本である。 - 具体例：支援ステータス機能では
PORT、MENTOR_ID、DATABASE_URLのような環境変数が使われ得る。第5章では、まず変数名と用途を確認できればよい。 - つまずきやすい点：実際の値（接続文字列やsecret）をAIやチャット、公開リポジトリに貼ってしまう。値は出さない。
- 関連語：.env.example（第5章）、secret（第5章）
- テキスト本文での登場箇所：第5章「失敗は、種類に分けると小さくなる」
.env.example
- 読み：ドットエンブイサンプル／ドットエンブイイグザンプル（.env.example）
- 一言で言うと：必要な環境変数名と用途を共有するための見本ファイル。
- くわしく：
.env.exampleは、アプリに必要な環境変数の名前と用途を共有するための見本である。実際の値を入れる.envとは分けて扱う。公開リポジトリでは、本物のパスワードやAPIキー、個人情報を.env.exampleに入れず、変数名と用途を書く。必要ならdummy-passwordのような非機密のサンプル値を添えてよい。各自はこれを見て、自分の.envに実際の値を設定する。 - 具体例：支援ステータス機能の
.env.exampleにDATABASE_URLの名前と用途が書かれていれば、各自がその名前で自分の.envに接続先を設定できる。本物の接続先や実在のパスワードは書かない。 - つまずきやすい点：
.env.exampleと.envの違いを意識せず、本物の値を見本ファイルや公開場所に書く。 - 関連語：環境変数（第5章）、secret（第5章）、README（第5章）
- テキスト本文での登場箇所：第5章「失敗は、種類に分けると小さくなる」
secret
- 読み：シークレット（secret）
- 一言で言うと：APIキーやパスワードなど、外に出してはいけない秘密情報。
- くわしく：secretは、APIキー、トークン、パスワード、秘密鍵など、外部に漏らしてはいけない情報の総称である。これらが漏れると、不正アクセスや情報流出につながる。ログをAIやチャットに貼る前、また
.env.exampleや公開リポジトリにコミットする前に、secretが含まれていないかを確認する。設定名は残してよいことが多いが、値は出さない。 - 具体例：支援ステータス機能のログに
DATABASE_URLの実際の接続文字列が含まれていたら、AIに渡す前に値を伏せる。変数名は残してよい。 - つまずきやすい点：設定名（変数名）と値を同じ扱いにする。名前は共有してよいことが多いが、値は秘密にする。
- 関連語：環境変数（第5章）、.env.example（第5章）、機微情報（第14章）
- テキスト本文での登場箇所：第5章「AIにログを読ませる前に安全確認をする」
再現性
- 読み：さいげんせい（reproducibility）
- 一言で言うと：同じ手順を、後からも他の人でも同じようにたどれること。
- くわしく：再現性は、同じ手順を踏めば同じ結果に近づけることを指す。手元で一度動いたことよりも、同じ手順をもう一度たどれること、失敗時にどこまで進んだか説明できること、他の人が同じ状況を再現できることが重要になる。再現性を支えるのが、現在地、コマンド、結果、停止方法などを記録に残す習慣である。
- 具体例：支援ステータス機能の起動手順、URL、ポート、停止方法を記録に残しておけば、別のメンバーや未来の自分が同じ手順で再現できる。
- つまずきやすい点：一度画面が表示されただけで「動いた」と考える。再現できて初めて作業場として説明できる。
- 関連語：ローカル（第5章）、ログ（第5章）、lockファイル（第5章）
- テキスト本文での登場箇所：第5章「この章でできるようになること」
EADDRINUSE
- 読み：イーアドレスインユース（EADDRINUSE／Error: ADDRess IN USE）
- 一言で言うと：使いたいポートがすでに使われているときに出るエラー。
- くわしく：EADDRINUSEは、起動しようとしたサーバーが使いたいポートを、別のプロセスがすでに使っているときに出るエラーである。
address already in useというメッセージで表示される。多くは、前の開発サーバーを止め忘れていたり、別のターミナルで同じアプリが動いていたりすることが原因である。すぐに強制終了せず、状況を確認してから対処する。 - 具体例：支援ステータス機能を起動して
Error: listen EADDRINUSE: address already in use :::3000が出たら、すでに3000番で起動済みのサーバーがないかを確認する。 - つまずきやすい点：見つけたプロセスをすぐ終了する。自分のものか分からないときは、止める前に状況を記録して相談する。
- 関連語：ポート（第5章）、プロセス（第5章）、ログ（第5章）
- テキスト本文での登場箇所：第5章「ローカル開発サーバーを起動し、止める」
which
- 読み：ウィッチ（which）
- 一言で言うと：あるコマンドが、どの場所にある実体を指しているかを表示するコマンド。
- くわしく：
which nodeのように使うと、その名前のコマンドが実際にどのパスの実行ファイルを呼ぶかが分かる。同じ名前で複数の版が入っていることがあり、意図しない方を呼んでいないか確かめられる。command not foundの切り分けにも使う。状態を変えない読み取り系のコマンドである。 - 具体例：
npm run devが動かないとき、which nodeとwhich npmで道具の場所を確認し、想定した版を使っているかを切り分ける。 - つまずきやすい点：出力が空のときは、その道具が入っていないかパスが通っていない。
node --versionなどのバージョン確認と組み合わせる。 - 関連語：CLI（第5章）、パス（第5章）、ランタイム（第5章）
- テキスト本文での登場箇所：第5章「まず壊さずに読む」「失敗は、種類に分けると小さくなる」