用語集

データに名前を付けて保存する「箱」。JavaScriptでは const（変更しない）か let（変更する）で宣言する。

const price = 100

「もし〜なら、こうする」という処理の切り替え。if / else if / else で書く。

if (age >= 18) { ... }

処理に名前を付けて再利用する仕組み。入力（引数）を受け取り、結果（戻り値）を返す。

function add(a, b) { return a + b }

複数のデータを順番に格納する入れ物。添字は0から始まる。map / filter / find で加工するのが定石。

const scores = [80, 92, 67]

「ダメな条件」を先に if で弾いて return する書き方。ネストが浅くなり可読性が上がる。コードレビューでも推奨される定石。

プログラムの不具合（バグ）を見つけて直す作業。基本は「ここまでは動く/ここから動かない」の二分探索。

代表的なエラーの3種。文法ミス / 型の誤用（undefinedへのメソッド呼出等）/ 未定義変数の使用。エラーは「種類→場所→内容」の順で読む。

ソフトウェア同士がやり取りするための窓口。Webでは「HTTPでJSONを返すURL」という形が多い。

ユーザーの画面側（ブラウザで動く部分）と、サーバー側（データ処理・保存を担う部分）。

DBをSQLではなくプログラムのオブジェクトとして操作する仕組み。便利だが、意識しないとN+1問題を踏む。

一覧取得（1回）の後、各レコードごとに追加クエリ（N回）を発行してしまう性能問題。JOINやIN句での一括取得（Eager Loading）で解決する。

認証=「あなたは誰？」の確認（ログイン）。認可=「あなたは何をしていい？」の判定（権限）。混同しやすいが別物。

開発に必要なソフト（言語・エディタ・Git等）をPCにセットアップすること。初学者の最初の壁。道場ではブラウザ演習でこれを後回しにできる。

アプリと実行環境をまとめてパッケージ化する技術。ホストOSのカーネルを共有するためVM（仮想マシン）より軽量に動く。Dockerが代表的な実装。

コンテナを起動するための「設計図」（読み取り専用）。イメージから起動された実行中のインスタンスがコンテナ。`Dockerfile`から`docker build`で自作できる。

Linuxでファイルの権限（owner/group/otherのread/write/execute）を変更するコマンド。`chmod 755 file`のように r=4, w=2, x=1 の合計値で数値指定するのが定石。

OSやプロセスの実行環境に設定する変数。APIキーやパスワードをコードに直書きせず`.env`ファイル経由で渡すことで、コードを共有してもシークレットが漏れないようにする。

ログイン中のブラウザがCookieを自動送信する性質を悪用し、意図しない操作を実行させる攻撃。CSRFトークンと`SameSite`Cookieの組み合わせで対策する。

JSON Web Tokenの略。署名付きのトークンで改ざんを検出できる認証方式。サーバー側にセッション状態を持たない一方、発行済みトークンの個別失効が難しいという弱点がある。

クラウドサービスの分類。IaaSはインフラをそのまま貸す形態、PaaSは実行環境ごと提供、SaaSは完成したソフトウェアをそのまま使う形態。Cloudflare Pages/WorkersやHerokuはPaaSの代表例。

CI(継続的インテグレーション)はpush毎の自動ビルド・テスト、CD(継続的デリバリー/デプロイ)はテスト通過後の自動デプロイ。手動デプロイの属人化やミスを防ぐ。

視覚・聴覚・運動機能などに制約があるユーザーも含めて誰もが使えるようにする設計思想(a11y)。alt属性・label要素・キーボード操作対応、色だけに頼らない情報伝達などが基本。

テストで外部依存(DBアクセス・API通信・時刻取得など)を置き換える偽物のオブジェクト・関数。本物に依存しないことでテストが安定し、CIでの自動実行もしやすくなる。

同じ操作を何度実行しても結果が同じになる性質。GET/PUT/DELETEは本来冪等だがPOSTは冪等でないため、決済など重複が許されない処理では冪等キー等の対策が必要。

「認可の委譲」を実現する仕組み。「Googleでログイン」のように、パスワードそのものを渡さずに、必要な情報へのアクセスだけを第三者アプリに許可できる。

「同じ情報を1か所にのみ持つ」ようテーブルを分割する設計手法。更新時の不整合を防ぐ。

「その時点の値」をコピーして保存すること。例: 注文時の商品価格は、商品マスタの価格が変わっても注文側に残す。

検索を高速化するための「索引」。WHERE や JOIN でよく使う列に貼る。ただし書き込みは少し遅くなるトレードオフあり。

複数の更新を「全部成功 or 全部取り消し」の1単位にまとめる仕組み。在庫引当と注文作成のように、中途半端だと困る処理に必須。

テーブル同士を結合して取り出す。JOINは両方にある行のみ、LEFT JOINは左側の全行を保持（対応なしはNULL）。

グループごとの集計と、集計「後」の絞り込み。WHEREは集計「前」の行を絞る、と対で覚える。

変更をリポジトリに記録する操作。スナップショットとして保存され、いつでも過去の状態に戻れる。メッセージで「何を変えたか」を記録する。

git commit -m "ログイン機能を追加"

メインの開発ラインから分岐した作業空間。「どのコミットを指しているか」のポインタ。feature/〇〇 のように機能名をつけるのが慣例。

git branch feature/login

2つのブランチを統合する操作。変更を取り込まれる側（main など）に向けて実行する。コンフリクトがあれば手動解消が必要。

git merge feature/login

GitHub など、ネット上に置いたリポジトリの別名。通常 `origin` という名前を付ける。`git push` で送信、`git pull` で取り込む。

git remote add origin https://github.com/...

2つのブランチで同じファイルの同じ行を変えたとき、Gitが「どちらを採用すべきか」判断できない状態。`<<<<<<` `=======` `>>>>>>` のマーカーで表示される。手動で正しい内容に書き換えてから `git add` と `git commit` で解消する。

GitHubなどで「このブランチをマージしてください」と提案しコードレビューを受ける仕組み。チーム開発での品質確保の要。レビュー→承認→マージの流れが標準。

作業途中の変更を一時退避させるコマンド。`git stash` で隠し、`git stash pop` で復元する。別ブランチに切り替える前に変更を中断したい場合に便利。

git stash / git stash pop

Gitで管理しないファイル・フォルダを指定するファイル。node_modules/ や .env（秘密鍵）などを除外する。プロジェクトのルートに配置する。

node_modules/
.env
*.log

認知→訪問→登録→購入のように、ユーザーが段階を経るごとに減っていく漏斗（ろうと）状のモデル。どこで離脱するか分析する。

「急いで作った歪み」の蓄積。放置すると開発速度が下がる。経営には「将来の利息が増える借金」として説明する。

「自作するか、既製品/SaaSを買うか」の判断軸。中核の強みは自作、それ以外は買うが原則。

「何を作るか」を明文化する工程。「言われたもの」をそのまま作るのではなく、背景の課題まで深掘りするのが一人前。

作業の工数・納期の予測。不確実性を隠さず「幅」で伝えるのが誠実。

短いサイクル（スプリント）で開発・テスト・改善を繰り返す開発手法。「完璧な計画」より「変化への適応」を重視する。スクラムが代表的な実践方法。

2週間スプリントで機能を少しずつリリース

Key Performance Indicator（重要業績評価指標）の略。目標達成の進捗を測る数値。「問い合わせ件数を月150件→30件にする」のような具体的な指標が良いKPI。

データ（数値・ログ）を根拠に意思決定・改善を行うアプローチ。「なんとなく改善」ではなく「閲覧数が低いページを優先改善する」のように数値で判断する。

現状（AS-IS）と目指す姿（TO-BE）を対比して整理するフレームワーク。要件定義やDX提案でよく使う。数値込みで書くと説得力が増す。

AS-IS: 問い合わせ月150件 / TO-BE: 自己解決率70%向上

最小限の機能から始めて、使われることを確認してから拡張するアプローチ。「作ったが使われない」リスクを最小化できる。DXプロジェクトの失敗を防ぐ鉄則。

デジタル技術で業務プロセスや価値創出の方法を根本から変えること。単なる「IT化」ではなく、業務の課題を解決し競争力を高めるのが本来の目的。

AIへの指示文。「なんとなく」ではなく、要件を言語化して渡すほど出力の質が上がる。

AIが「もっともらしい嘘」を生成すること。AIの出力は鵜呑みにせず、必ず検証する姿勢が求められる。

AIが書いたコードが正しいか、テスト実行・コード読解・エラー解析で確認すること。AI時代のエンジニアの中核スキル。

「何かを得ると何かを失う」という設計上の両立しなさ。速度 vs 安全性など。「正解」ではなく「判断」が問われる領域。

文章・コード・画像などを「生成」するAI。ChatGPT・GitHub Copilot・Claude等が代表例。入力（プロンプト）に対して「もっともらしい出力」を生成するため、検証が必須。

Large Language Model（大規模言語モデル）の略。膨大なテキストで学習した言語処理モデル。GPT-4・Claude等はLLM。「理解」ではなく「確率的な文字列生成」が仕組みの本質。

Retrieval-Augmented Generation（検索拡張生成）の略。AIが回答する前に関連ドキュメントを検索し、その情報を元に回答させる手法。ハルシネーション低減と最新情報の反映に有効。

社内マニュアルをAIに検索させて回答させるFAQシステム

既存のAIモデルを自社のデータで追加学習させること。特定ドメインの専門性を上げられる一方、高コストで過学習リスクもある。多くの場合RAGの方が費用対効果が高い。

AIに渡す「背景情報」。「言語・バージョン・コードの目的・制約」などをプロンプトに含めることでAIの出力精度が大幅に上がる。「なんとなく聞く」と「コンテキスト付きで聞く」では品質が全然違う。

AIが生成したコードに多い脆弱性の一つ。ユーザー入力をSQLに直接埋め込むと、悪意ある入力でDBを操作される攻撃を受ける。プレースホルダー（`?`）を使えば防げる。

"SELECT * FROM users WHERE id = " + userId は危険

AIからより良い出力を引き出すためのプロンプト設計技術。役割・コンテキスト・指示・制約の4要素を整え、反復改善するスキル。エンジニアの必須スキルになりつつある。

縦軸に深い専門知識（技術スキル）、横軸に幅広い応用力（ドメイン知識）を持つ人材像。AI時代は「コードを書く」技術だけでなく、「何を作るか」を判断するドメイン知識との組み合わせが差別化になる。

元医療事務のエンジニア → 医療ドメイン × 開発スキルでT型を形成

特定の業界・業務分野に関する専門的な知識・経験。医療・金融・物流・ECなど業界ごとに異なる「常識・規制・用語・業務プロセス」のこと。AIが苦手な「何を作るか」の判断に直結する。

コールセンター5年の経験 → 問い合わせ業務・FAQ整備・品質管理のドメイン知識

業界を問わずどこでも通用する汎用スキルのこと。SQLが書ける・Gitが使える・APIを設計できる・バグをデバッグできるなど。T型の「縦軸」にあたり、どの現場でも持ち運べる（ポータビリティが高い）スキル。

新しいスキルを習得し直すこと。AI・DXの進展により業務が変化するなか、既存の経験を活かしながら開発スキルを身につける（例: 元ヘルプデスク → エンジニア転職）のが典型的なリスキリング。技術は土台として学びながら、既存ドメイン知識を活かすのが効率的。

自分の作品・実績をまとめたもの。エンジニアの就職・転職では「GitHubのリポジトリ」や「自作Webアプリ」がポートフォリオになる。T型を意識し「自分のドメイン課題を解決するアプリ」で作ると採用担当者に強く刺さる。

ヘルプデスク経験者 → よくある質問検索ツールを作ってポートフォリオに

転職市場における自分のスキル・経験の需要度。職能（汎用スキル）と業界知識（ドメイン）の組み合わせが高いほど市場価値が高くなる。AI時代は「コードを書ける」だけでなく「何を作るか判断できる」エンジニアの市場価値が高い。

学ぶべき知識を①職能（普遍スキル）→②業界知識→③会社固有ルールの3層で整理するフレームワーク。初学者はまず①に集中し、②は並行して、③は入社後に覚えると効率的。汎用性が高い①②を厚くすると転職・独立でも強くなる。