用語解説

56記事の本文に出てくる用語を、本文の説明を基に短くまとめたものです（137語、うち「基本」79語）。本文の説明はそのまま残しており、ここは入口です。各項目の「本文へ」から、その用語を最初に、または最も詳しく説明している節に移動できます。「基本」は非エンジニアが最初に知るべき語、「応用」はそれ以外です。

API（API）基本実装・開発の道具

ひとことでプログラム同士が「この形で頼めば、この形で返す」と決めた連携の約束。例画面が POST /submit に依頼の内容を送ると、処理側が受け付け結果を返す。本文へ08-03 第3.1節

assertion（アサーション）（assertion）応用テスト・検証

ひとことでテストの中で「この条件が成り立つはず」と書いた検査。成り立たなければテストが失敗する。例self.assertFalse(r.ok) は結果が拒否であることを検査する。本文へ記事B 第5.3節

Claude Code（AIコーディングツール）（Claude Code）応用AIとの協働

ひとことでこの教材の記事・コードの作成に使ったAIの道具。文章だけでなく、コードの作成・実行・修正まで行う。例記事Bの検証状況に「実装者と同じAI（Claude Code）」とあるのは、独立した確認ではないという注記。本文へ記事B 第11節

CSV（CSV）基本実装・開発の道具

ひとことで値をカンマで区切って1行に1件ずつ並べた、表計算でも開ける文字だけのデータ形式。例件名にカンマが入っていると列がずれて読み違える（00-02 の演習）。本文へ00-02 第3.1節

Git（バージョン管理）（Git / version control）基本実装・開発の道具

ひとことでファイルの変更を「いつ・誰が・なぜ」とともに記録し、前の状態に戻したり分岐したりできる道具。例演習の drill.sh で、変更→差分→保存→やり直しの流れを使い捨ての置き場で試す。本文へ06-03 第3.1節

HTML・CSS・JavaScript（HTML / CSS / JavaScript）応用実装・開発の道具

ひとことでブラウザで画面を作る3つの言語。HTMLが中身の構造、CSSが見た目、JavaScriptが動き。例入力フォームは HTML、色や並びは CSS、提出ボタンを押したときに処理へ送るのは JavaScript。本文へ08-03 第5.3節

JSON（JSON）基本実装・開発の道具

ひとことで「項目名: 値」の組を波括弧で囲んで表す、プログラム同士のやり取りに使う文字だけのデータ形式。例{"id": "REQ-001", "state": "提出済み"} のように1件を表す。本文へ00-02 第3.1節

Node.js（Node.js）応用実装・開発の道具

ひとことでJavaScript をブラウザの外（自分のパソコン）で動かすための実行環境。この教材の演習コードの多くが使う。例node run.js のように打つと、run.js が実行される。本文へ06-01 第5.2節

OS（operating system）基本実装・開発の道具

ひとことでパソコンや機器の土台になる基本ソフト。ファイルの管理やプログラムの起動を担う。例macOS、Windows、Linux。演習コードは OS が違うと動き方が変わることがある。本文へ00-02 第3節

Python（Python）応用実装・開発の道具

ひとことで読みやすさで知られるプログラミング言語。記事B・Cの最小実験コードはこれで書かれている。例python3 test_approval.py approval_v2 でテストを実行する。本文へ記事B 第5.5節

README（README）基本実装・開発の道具

ひとことでそのフォルダの中身と動かし方・注意を書いた案内ファイル。最初に読む。例各実験コードの README.md に起動手順と「業務データでは実行しない」注意がある。本文へ06-01 第5.2節

SQL（SQL）応用実装・開発の道具

ひとことでデータベースに「この条件の行を更新して」「この行を追加して」と頼むための言語。例UPDATE（更新）と INSERT（追加）。本文へ記事B 第2節

SQLite（SQLite）応用実装・開発の道具

ひとことで1つのファイルの中にデータベースを持てる軽量なデータベース。例最小実験ではテストのたびにメモリ上に作って捨てる。本文へ記事B 第2節

unittest（unittest）応用テスト・検証

ひとことでPython に最初から付いているテストの仕組み。テストごとに「成功」「失敗」を表示する。例python3 test_approval.py approval_v2 で12件の結果が出る。本文へ記事B 第2節

URL（URL）基本実装・開発の道具

ひとことでWeb上の場所を示す住所。ブラウザはこれを頼りに画面や処理へつなぐ。例http://localhost:8931/submit は「自分のパソコンの中の処理側にある submit という入口」を指す。本文へ08-03 第3.1節

アプリ（application）基本実装・開発の道具

ひとことで利用者が画面で操作し、処理が判断し、保存先に記録し、それらが通信でつながって動く仕組み全体。例承認アプリ＝ブラウザの画面＋承認可否を判定する処理＋依頼を記録する保存先。本文へ00-01 第3.1節

依存関係（外部部品）（dependency）応用実装・開発の道具

ひとことで自分のプログラムが動くために必要な、他のライブラリやサービス。出所・更新・利用条件を確認して使う。例外部部品の一覧に、名前・版・出所・更新の確認方法を書いておく。本文へ06-04 第5.5節

一般論で埋める（filling gaps with generalities）基本AIとの協働

ひとことで材料が足りないとき、AIがその会社の事情ではなく世間一般の常識で空白を埋めてしまうこと。例Q-6 が未回答なのに「添付は5MBまで」と根拠のない要件を作る。本文へ記事A 第5.6節

受入確認（user acceptance）基本業務・要件

ひとことで実際の業務担当者が、要件どおりに動くかと使い勝手を確かめ、合格・不合格を記録すること。例不合格の条件を確認前に決めておき、依頼者役が必須項目を空にして作成すると拒否されることを確かめる。本文へ10-01 第5.2節

受入条件（Acceptance Criteria）基本業務・要件

ひとことで作った機能が要件を満たしたと判断するための具体的な条件。誰が、どんなデータに、何をしたら、何が起きるべきかまで決める。例AC-002：割当外の承認者（高橋）が承認 → 拒否。状態・履歴は変わらない。本文へ記事A 第5.5節

運用項目と確認頻度（監視）（operations / monitoring）基本公開・運用

ひとことで動いているか（稼働）だけでなく、処理結果・利用状況・費用を、何をどのくらいの頻度で見るか決めること。例「提出済みのまま3営業日を超える依頼が無いか」を週1回確認する（架空の仮定）。本文へ12-01 第3.1節

AI作業指示書（指示文）（AI work order）基本AIとの協働

ひとことでAIへの依頼を、成果物・期待結果・証拠・やり直し方まで書いた文書。指示文はAIに渡す文章そのもの。例「承認できるようにして」ではなく、成果物・期待結果・証拠・やり直し方を書いた指示にする。本文へ07-03 第5.3節

AI実行ルールと再開用メモ（AI rules / resume memo）応用AIとの協働

ひとことでAIがしてはいけないこと・止める条件を決めたルールと、止めたときに何を残して再開するかのメモ。例「外部の文章をそのまま命令にしない」「秘密情報を渡さない」「承認範囲を越えたら止める」。本文へ07-04 第5.2節

AIの初稿（AI first draft）基本AIとの協働

ひとことでAIが最初に返してきた下書き。そのまま使えるとは限らず、人が要件と照合して直す前提のもの。例記事Aの初稿4件は、勝手に決めた要件や正常系だけの受入条件を含む説明用の失敗例。本文へ記事A 第6節

AIへ渡す情報セット（AI input set）基本AIとの協働

ひとことでAIに仕事を頼むときに渡す、目的・要件・設計・既存コード・制約・完成条件を必要な範囲に絞った資料一式。例承認処理の実装を頼むなら、要件一覧・状態表・権限表・完成条件を渡し、実データは渡さない。本文へ07-01 第5.2節

エラー処理と例外（error handling / exception）応用実装・開発の道具

ひとことで想定外の入力や失敗が起きたときに、プログラムがどう振る舞うかを決めて書くこと。例外はその失敗の合図。例履歴が書けなかったら状態の変更も取り消し、失敗を記録して利用者に知らせる。本文へ08-04 第5.3節

改善要望（バックログ）（backlog）応用業務・要件

ひとことで使い始めてから出てきた追加・修正・廃止の要望を、優先順位を付けて一覧にしたもの。例「提出後に自分で取り下げたい」という要望を一覧に入れ、優先順位を決める。本文へ13-01 第5.1節

開発計画と役割（plan / roles）応用設計

ひとことで作業を小さく分け、順序・完了条件・費用の前提・誰が何をするかを決めた計画。例最初に「作成→提出→承認」の一巡だけを作る範囲に区切る。本文へ03-04 第5.2節

外部キー検査（foreign key constraint）応用実装・開発の道具

ひとことでテーブル定義で REFERENCES と宣言した関係（履歴は存在する依頼を指す、など）を保存先が守る仕組み。SQLite では接続ごとに有効化が必要。例存在しない依頼IDの履歴を追加しようとすると保存先が拒否する（T10）。本文へ記事B 第6.3節

確認事項（Q表）と不明点一覧（open questions）基本業務・要件

ひとことで要件を書く前に現場に確認すべきことを表にしたもので、未回答のものに頼った要件は作らない。例Q-6「個人情報・社外秘の扱い」が未回答なので、添付ファイルの要件は不明点一覧へ回す。本文へ記事A 第4.2節

画面遷移（screen flow）基本設計

ひとことである画面で操作すると次にどの画面へ移るかの流れ。実装前に利用者別にたどって抜けを見つける。例一覧→詳細→承認ボタン→一覧に戻り状態が承認済みになる。本文へ04-03 第5.2節

画面の原型（prototype / wireframe）基本設計

ひとことで色や飾りを付ける前に、入力項目・一覧・ボタンの並びと優先順位を紙や文字で描いた画面の下書き。例一覧画面には状態・件名・依頼者を先に、日付は後に並べる。本文へ04-02 第5.2節

画面（フロントエンド）（frontend）基本実装・開発の道具

ひとことで利用者が直接見て操作する部分。入力を受け取って処理に渡し、結果を表示する。例依頼の入力フォームと承認ボタンがある画面。判定そのものは処理側で行う。本文へ00-01 第8.1節

カレントディレクトリ（current directory）応用実装・開発の道具

ひとことで今コマンドを実行しているフォルダ。例先に cd examples/sample-b で移動してからテストを実行する。本文へ記事B 第5.5節

環境（開発・検証・本番）（development / staging / production）基本実装・開発の道具

ひとことで試してよい場所（開発）、本番に近い条件で確かめる場所（検証）、実データがあり利用者が使う場所（本番）の区別。例演習の check_env.js は、接続先が本番なら処理を止める。本文へ06-02 第5.2節

関数と引数（function / argument）応用実装・開発の道具

ひとことで関数は「入力を受け取って処理をして結果を返す」ひとまとまりのコード。引数はその入力。例approve(conn, "REQ-A01", "u-suzuki") は承認関数に接続・依頼ID・操作者IDを渡す。本文へ記事B 第2節

完成条件（completion criteria）応用業務・要件

ひとことでひな形などの成果物が「ここまで埋まっていれば次の工程に渡せる」と判断する採点基準。例「要件が5つ以上あり、それぞれに受入条件が1つ以上対応している」。本文へ記事A 第7節

聞取りメモ（interview memo）基本業務・要件

ひとことで現場の人から聞いた言葉を、解釈を混ぜずにそのまま番号付きで記録したもの。要件の根拠になる。例M-3「差戻しの理由がメールに残らず、後で分からなくなる」。本文へ記事A 第3.3節

技術選定（technology selection）応用設計

ひとことで言語・保存先・配置先などを、保守できる人・費用・移行のしやすさ・学ぶ負担も含めて選び、理由を残すこと。例教材演習では Node.js と JSON ファイルを使うが、正式な選定は別に行う。本文へ03-03 第3.1節

基準の控え（manifest）（manifest）応用公開・運用

ひとことでバックアップの直後に、バックアップファイル自体から取った全行と指紋の記録。復元後の照合の基準になる。例work/backup/gen-001/manifest.json。本文へ記事C 第5.3節

境界値（boundary value）応用設計

ひとことで「ちょうど上限」「1つ超えた」など、条件の境目にある入力。抜けが出やすいので必ず試す。例状態が空文字（想定外の値）のとき、承認しない（false）という安全側に倒れるか（TC-06）。本文へ09-01 第5.1節

業務要件（business requirement）基本業務・要件

ひとことで業務上「誰が・どの条件で・何をできる／できない」を1文ずつ書いたもので、画面や技術の話はまだ含めない。例REQ-003「割り当てられた承認者は提出済みの依頼を承認できる。依頼者本人は承認できない」。本文へ記事A 第5.4節

切戻し（rollback (code)）基本公開・運用

ひとことでプログラムを問題のあった版から前の版に戻すこと。データを戻すこととは別の作業。例掃除スクリプトを v1.0 に戻しても、消えた履歴は戻らない。本文へ記事C 第2節

クラウド／ホスティング（cloud / hosting）応用実装・開発の道具

ひとことで自分で機器を持たず、他社のサーバーを借りてアプリを置き、外から使えるようにするサービス。例配置先の候補を選ぶとき、社外クラウドに実データを置けるかは制約で決まる。本文へ03-03 第3.1節

権限表（permission table）基本設計

ひとことで利用者の役割・対象データ・操作の組合せごとに「できる／できない」を書いた表。例承認者は自分に割り当てられた依頼を承認できるが、自分の依頼はできない。本文へ05-03 第5.2節

現状の業務フロー（current workflow）基本業務・要件

ひとことで今の仕事が誰から誰へどう流れ、どこで待ち時間や手戻りが起きているかを書き出したもの。例依頼者がメールやチャットで総務担当へ送り、総務担当が複数の経路を確認して依頼に気づく、という今の流れを図にする。本文へ01-02 第5.2節

公開前チェック（pre-release check）基本公開・運用

ひとことで公開範囲・接続先・設定値・秘密情報・権限・費用を、公開する前に確かめて記録すること。例「確認済み」と書けるのは、確かめる対象が実際にあるときだけ。本文へ11-01 第3.1節

恒久対応（permanent fix）応用公開・運用

ひとことで原因を取り除いて、同じ障害が起きないようにする本来の修正と再発防止。例部分失敗を取り消す修正を入れ、テストを足して再検証する。本文へ12-02 第5.2節

構成図と復旧方針（architecture / recovery policy）応用設計

ひとことで画面・処理・保存先をどう分けるかの図と、どこが壊れたら何が止まり、どう戻すかの方針。例保存先が壊れたら承認はできないが、バックアップから前日の状態に戻せる。本文へ05-04 第5.2節

困り事と課題（problem / issue）基本業務・要件

ひとことで「承認が遅い」のような現場の不満（困り事）を、何が起きているか（現象）と、なぜ起きるか（原因の仮説）に分けたものが課題。例「依頼が埋もれる」は困り事。「依頼がメールとチャットに分散して残る」が現象で、原因は仮説として分けて書き、確認方法を添える。本文へ01-02 第5.3節

コミット（保存単位）（commit）基本実装・開発の道具

ひとことで変更のひとまとまりに理由を添えて Git に記録すること。あとで1つずつ戻せる単位になる。例「自己承認を禁止する条件を追加（REQ-003）」という理由を付けて保存する。本文へ06-03 第5.4節

コンテキスト（この教材では「同じ会話」「渡した資料」）（context）基本AIとの協働

ひとことでAIが答えを作るときに手元に持っている情報のこと。渡した資料と、それまでの会話の内容。例同じ会話（コンテキスト）の中でのAIの自己点検は、実装の意図を知った上での確認になり独立していない。本文へ09-04 第3.3節

再検証（変更後のテスト）（regression test）応用テスト・検証

ひとことで変更を加えたあとで、新しいテストと既存のテストを両方実行し、前からある機能が壊れていないか確かめること。例「取り下げ」を足したあと、09-01 の承認テストも再実行して全部通るか見る。本文へ13-03 第5.3節

最小の動作例（minimal working example）基本実装・開発の道具

ひとことで本番の機能を作る前に、いちばん小さな処理だけを動かして仕組みを確かめる例。例承認できるかを判定する関数1つに、入力を変えて結果を見る。本文へ08-01 第5.5節

作業分解と依存関係（task breakdown / dependency）基本AIとの協働

ひとことで一回の変更と確認の範囲を小さく分け、どの作業がどれの後でないとできないかを表にすること。例「保存処理」ができてから「提出処理」に進む、という順序を表にする。本文へ07-02 第5.2節

差分（diff）（diff）応用実装・開発の道具

ひとことで変更の前後で、どのファイルの何行がどう変わったかを並べて示したもの。レビューはこれを見る。例AIに変更させたあと、まず status で変わったファイル、次に diff で変わった行を見る。本文へ06-03 第3.3節

暫定対応（workaround）応用公開・運用

ひとことで原因を完全に直す前に、業務を止めないために当面の間だけ取る対応。例拡大防止のために対象の操作を止め、関係者へ連絡し、切戻しが要るかを判断する。本文へ12-02 第5.2節

サンドボックス（sandbox）応用実装・開発の道具

ひとことで本物に影響しないように隔離した練習用の場所。演習の「配置先」や「演習領域」はこれ。例11-02 は deploy_target/ という配置サンドボックスにコードとデータを置く。本文へ11-02 第5.1節

実行環境（runtime environment）基本実装・開発の道具

ひとことでコードを実際に動かすために必要なソフトの組合せ。同じコードでも実行環境が無ければ動かない。例演習コードを動かすには Node.js か Python 3 が入っている必要がある。本文へ06-01 第3.2節

実行記録（証拠）（evidence / run log）基本テスト・検証

ひとことでテストや演習を実際に動かしたときの出力と終了コードを、整形せずに残したもの。「確認した」の裏付け。例run_log.md に 12 件のテスト結果と終了コード 0 が残っている。本文へ記事B 第6.1節

自動確定モード（autocommit mode）応用実装・開発の道具

ひとことで変更のたびに自動で確定される接続の設定。この設定では途中で失敗しても取り消せないため、修正版の処理は変更前に拒否する。例T12：自動確定モードの接続を渡すと、何も変えずに拒否される。本文へ記事B 第6.3節

シナリオ（scenario）基本設計

ひとことで役割ごとに「誰が・何をして・業務がどう変わるか」を順に書いた、操作の物語。例依頼者が下書きを作って提出し、承認者が承認すると依頼が承認済みになる。本文へ04-01 第5.2節

指紋（ハッシュ）（hash (SHA-256)）応用実装・開発の道具

ひとことでファイルの中身から計算した短い要約値で、変更の検出に使う。短い要約値なのでファイル全体と一対一に対応するわけではない。例復元の前に復元元の指紋が控えと一致するかを確かめる。本文へ記事C 第5.3節

終了コード（exit code）基本実装・開発の道具

ひとことでコマンドが終わるときに呼び出した側へ返す数字。0が成功、それ以外が失敗という約束。例照合（verify）は不一致があれば終了コード1を返す。本文へ記事C 第5.3節

主キー／ID（primary key / ID）基本実装・開発の道具

ひとことで1件のデータを他と取り違えないように付ける、重複しない識別子。例依頼が100件あっても、依頼ID「REQ-0031」と言えばその1件だけを指せる。本文へ05-01 第5.2節

障害（incident / failure）基本公開・運用

ひとことでアプリが期待どおりに動かず、業務に影響が出ている状態。原因が分かる前から対応が始まる。例掃除スクリプトの不備で履歴が消え、承認済みの根拠が確認できなくなった。本文へ記事C 第3.3節

照合（verification / comparison）基本テスト・検証

ひとことで「こうなるはず」と「実際にこうなった」を並べて、一致するかを確かめること。例復元後に件数・内容・関係の3つを基準の控えと照合する。本文へ12-04 第5.1節

状態（state）基本設計

ひとことで1件の依頼が今どの段階にあるかを表す札。この教材では「下書き」「提出済み」「差戻し」「承認済み」の4つに固定。例提出済み → 承認 → 承認済み。承認済みの内容は初期版では編集不可。本文へ記事A 第5.2節

状態遷移表（state transition table）基本設計

ひとことでどの状態からどの操作でどの状態へ移れるかを表にしたもの。表に無い移り方は禁止。例下書き→提出済み→承認済み。承認済みから下書きへは戻れない。本文へ05-02 第5.2節

初期利用（initial (limited) use）応用公開・運用

ひとことで全員に開放する前に、対象者・機能・時間帯を絞って使い始め、正常利用と異常の兆候を確かめる段階。例承認者に割り当てられた2名・承認可否の判定だけ・演習1回分、に絞って始める。本文へ11-03 第3.1節

初動（first response）応用公開・運用

ひとことで異常に気づいたあと、事実確認→影響範囲→切り分け→暫定対応、と順に進める最初の対応。例申告を受けたら、まず記録を読み、何件が影響を受けたかを確かめる。本文へ12-02 第3.2節

処理（バックエンド）とサーバー（backend / server）基本実装・開発の道具

ひとことで画面の裏側で、ルールに従って判断し、保存先を読み書きする部分。それが動いているコンピュータがサーバー。例「この人はこの依頼を承認できるか」を判定するのは処理側の役目。本文へ08-03 第5.2節

真偽値（boolean）応用実装・開発の道具

ひとことで「はい／いいえ」の2つしか取らない値。判定の結果を表すのに使う。例canApprove の結果が true なら承認できる、false なら承認できない。本文へ08-01 第5.2節

シンボリックリンク（symbolic link）応用実装・開発の道具

ひとことで別の場所を指す名前。演習では、演習領域の中にあるリンク（リンク先がまだ無いものを含む）を拒否する。例practice.db が領域外へのリンクなら after-backup は拒否する。本文へ記事C 第5.1節

正常系・異常系（normal / abnormal case）応用設計

ひとことで想定どおりの操作（正常系）と、権限なし・入力不足など想定外の操作（異常系）の両方を確かめる考え方。例正常系：承認者が承認→承認済み。異常系：依頼者本人が承認→拒否。本文へ09-01 第5.1節

生成AI（この教材では「AI」）（generative AI）基本AIとの協働

ひとことで文章やコードを新しく作り出すAI。この教材で「AI」と書いているものはすべてこれを指す。例要件の下書き・コードの初稿・比較表の下書きなど、文章とコードの生成を任せる。本文へ00-04 第3.1節

制約・前提条件（constraints）基本設計

ひとことで端末・ネットワーク・データの持ち出し・使ってよいAI・予算など、作る前に決まっている「できないこと」の一覧。例「社外クラウドに実データを置けない」なら、配置先の候補が絞られる。本文へ03-01 第5.2節

設定ファイルと環境変数（.env）（config file / .env）応用実装・開発の道具

ひとことで接続先やパスワードなど環境ごとに変わる値を、コードから切り離して置くファイルや仕組み。例.env に本物の値、env.example.txt に空欄の見本を置き、.env は共有しない。本文へ06-04 第5.1節

選択肢比較と企画書（options comparison / proposal）応用業務・要件

ひとことで運用の変更・既存機能・既製サービス・新規開発を並べて比べ、「作らない」を含めて選んだ理由を説明する文書。例表計算の運用改善で済むかを先に比べ、それでも足りない理由を企画書に書く。本文へ01-04 第5.2節

ターミナルとコマンド（terminal / command）基本実装・開発の道具

ひとことでターミナルは文字で指示を打つ画面、コマンドはそこに打つ1行の指示。例ターミナルで cd examples/sample-b と打つと、そのフォルダに移動する。本文へ06-01 第5.2節

対象外（out of scope）基本業務・要件

ひとことで今回は作らないと決めたことを、要件に混ざらないように一覧にしておくこと。例代理承認・承認の取消・提出の取り下げは初期版では対象外。本文へ記事A 第5.2節

対象範囲と優先順位（scope / priority）基本業務・要件

ひとことで「最初に作る」「後で追加する」「今回はしない」の3つに機能を分けて、作る範囲を決めること。例依頼の作成・提出・承認は最初に作る。通知は後で。代理承認は今回はしない。本文へ02-02 第5.2節

単体テスト（unit test）基本テスト・検証

ひとことで処理の小さな単位（関数など）ごとに、入力と期待結果を決めて自動で確かめるテスト。例canApprove に「依頼者本人」を渡すと false になるかを1件のテストにする。本文へ09-01 第5節

通信（communication / network）基本実装・開発の道具

ひとことで画面と処理、処理と保存先など、離れた部品の間でデータをやり取りすること。失敗することがある前提で作る。例提出ボタンを押すと画面から処理へ依頼の内容が送られる。途中で切れたら再送や表示で対応する。本文へ00-01 第3.1節

データ移行（data migration）応用業務・要件

ひとことで今まで表計算などにあったデータを、新しいアプリの形式に変換して移し、件数と内容が合っているか照合すること。例過去の依頼CSVを読み込み、日付の形式を直し、件数が一致するか確かめる。本文へ10-02 第3.1節

データ項目と関係（データモデル）（data model）基本設計

ひとことで保存する項目ごとに名前・型・必須か・重複してよいかを決め、データ同士のつながりを図にしたもの。例「依頼」1件に「履歴」が複数ぶら下がる、という関係を図にする。本文へ05-01 第5.2節

「できた」と「確認した」の違い（done vs verified）基本AIとの協働

ひとことでAIが「できました」と言うのは実装が終わった合図にすぎず、要件どおり動くかは人が期待結果と照合して初めて分かる。例テスト12件を実行して全部成功したときに、初めて「確認した」と言える。本文へ記事B 第3節

テスト／期待結果（test / expected result）基本テスト・検証

ひとことで「この入力なら、この結果になるはず」を先に決めておき、実際に動かして照合する作業。期待結果は実装を動かす前に要件から決める。例T2：割当外の承認者が承認 → 拒否。依頼と履歴の全行が操作前と同一。本文へ記事B 第2節

テストケース（test case）基本テスト・検証

ひとことで「この入力なら、この結果になるはず」を1件ずつ書いたもの。実装より先に要件から作る。例T2：割当外の承認者が承認 → 拒否。依頼と履歴は変わらない。本文へ09-01 第5.1節

テストの検出力（故意に壊した版）（mutation testing）応用テスト・検証

ひとことでわざと壊したコードにテストを当てて、ちゃんと失敗するかを見ることで、テストが本当に効いているか確かめる方法。例mutants.js の壊れ方ごとに、どのテストが FAIL になるかを確かめる。本文へ09-01 第5.4節

トークン（AIの入出力の単位）（token）応用AIとの協働

ひとことでAIが文章を読み書きするときの最小の区切り。一度に渡せる量に上限があるため、資料は必要な範囲に絞る。例AIへ渡す情報セットを絞る理由の一つ。全記事・全データを渡すより、要件と完成条件に絞る方が結果が安定する。本文へ07-01 第8.1節

独立した確認（自己レビューの限界）（independent verification）応用AIとの協働

ひとことで作った本人（同じAI・同じ会話）に点検を頼んでも独立した保証にならず、別の観点・別の人や道具で確かめる必要があること。例同じAIに「自分で点検して」と頼むのは自己レビュー。要件から作ったテストで確かめるのが独立した確認。本文へ09-04 第3.3節

トランザクション（transaction）応用実装・開発の道具

ひとことで複数の保存操作を「全部成功するか、全部なかったことにするか」のどちらかにする処理のまとまり。例「状態を承認済みに変える」と「承認の履歴を1件追加する」を1つのまとまりにする。本文へ記事B 第2節

入力データ（input data）基本実装・開発の道具

ひとことでプログラムに読み込ませる材料。プログラム本体とは別のファイルに置く。例requests.csv が入力データ、count_by_state.js がプログラム、画面の件数が出力。本文へ00-02 第5.2節

認可（authorization）基本設計

ひとことで本人だと分かった人に、その操作を許すかどうかを決めること。権限表で決める。例鈴木さんが承認者でも、割り当てられていない依頼は承認できない。本文へ05-03 第3.1節

認証（authentication）基本設計

ひとことで操作している人が本人かどうかを確かめること。何ができるかを決める「認可」とは別。例IDとパスワードで鈴木さん本人だと確かめる。教材の演習では本物の認証は作らない。本文へ05-03 第3.1節

バージョン（版）（version）基本公開・運用

ひとことでアプリやファイルの「どの時点のものか」を示す番号や名前。戻す・比べるときの目印。例v0.1.0-sandbox を配置し、問題があれば前の版へ切り戻す。本文へ11-04 第5.1節

配置（デプロイ）（deploy）基本公開・運用

ひとことで作ったアプリとデータを、利用者が使う場所に置いて動かせる状態にすること。例11-02 では配置対象・版・配置元を明確にし、配置元との同一性を指紋で記録する。本文へ11-02 第3.1節

バグ（bug）基本実装・開発の道具

ひとことでプログラムが意図と違う動きをする不具合。「動いた」ように見えても記録が違うものも含む。例部分失敗を正常完了として扱う storage_v1.js の不備がバグの例。本文へ08-04 第5.2節

バックアップ／基準時点（backup / recovery point）基本公開・運用

ひとことである時点のデータの複製を、元とは別の場所に取っておくこと。複製を取った時刻が基準時点。例依頼5件・履歴7件の時点で複製を取り、その内容を控えに記録する。本文へ記事C 第2節

パッケージ（package）応用実装・開発の道具

ひとことでライブラリを配布・導入しやすいようにまとめたもの。名前と版で管理する。例npm install で入れるものがパッケージ。入れたら版を記録しておく。本文へ06-04 第5.5節

ハルシネーション（この教材では「一般論で埋める」「根拠のない数値」）（hallucination）基本AIとの協働

ひとことでAIが、事実や渡した資料に無いことを、もっともらしく作ってしまうこと。例「承認時間が50%削減される」のように測っていない数値を書く（記事A 失敗例4）。本文へ記事A 第6節

引継ぎと終了（handover / closure）応用業務・要件

ひとことで担当者が変わるときに渡す資料と、アプリをやめるときに残すデータ・止めるアクセス・終える契約を整理すること。例担当交代で権限を移し、廃止時は依頼データを保存してからアクセスを止める。本文へ13-04 第3.1節

人とAIの役割分担（human / AI roles）基本AIとの協働

ひとことで作業ごとに「AIに任せる」「人が決める」「人が確かめる」を分け、AIが越えてはいけない範囲を決めること。例文章の下書きはAI、業務上の決定（自己承認の可否）は人。本文へ00-04 第5.2節

秘密情報（secrets）基本実装・開発の道具

ひとことでパスワード・APIキー・接続文字列など、漏れると他人になりすませたり実データに触れたりできる値。例AIへ渡す資料と公開する実行記録に秘密情報が混ざっていないかを確かめる。本文へ06-04 第3.1節

品質条件（非機能要件）（non-functional requirement）基本業務・要件

ひとことで「何ができるか」ではなく「どのくらい安全か・速いか・使いやすいか」など、機能以外に守るべき条件。例「自分に関係のない依頼は一覧にも詳細にも表示されない」「同じ承認操作を2回行っても履歴は1回分のまま」。速さの数値は実測していない限り架空の仮定と明記する。本文へ02-03 第5.2節

ファイルとフォルダ（file / folder）基本実装・開発の道具

ひとことでファイルは中身を持つ1つのまとまり、フォルダはそれを入れる箱。プログラムもデータも同じくファイル。例examples/sample-b/ というフォルダに approval_v2.py などのファイルが入っている。本文へ00-02 第5.2節

復元（restore）基本公開・運用

ひとことでバックアップの複製からデータを戻すこと。この教材では元のファイルに上書きせず、別の場所に戻す。例work/restore/gen-001/practice_restored.db へ複製し、基準時点と照合する。本文へ記事C 第2節

復元演習（restore drill）応用公開・運用

ひとことで本当に障害が起きる前に、バックアップから別の場所へ復元して、戻せることを実際に確かめる練習。例「保存した」と「復元できる」は別。演習で件数・内容・関係を照合して初めて確認できる。本文へ12-04 第3.1節

復旧時間の目標（RTO）（Recovery Time Objective）応用公開・運用

ひとことで業務への影響が出る前に復旧を終えるべき時間の目標。復元コマンドの実行時間だけではなく、検知から再開までの全体の時間。例検知 → 保全 → 復元 → 照合 → 業務確認 → 再開までの時間。本文へ記事C 第8.1節

復旧時点の目標（RPO）（Recovery Point Objective）応用公開・運用

ひとことで障害のあと、データをどの時点まで戻す必要があるかという目標（NIST SP 800-34 Rev.1 の定義に沿う）。例1日1回の複製なら、条件が満たされていれば最大1日分の再操作が必要になり得る。本文へ記事C 第8.1節

部分失敗（partial failure）応用設計

ひとことで複数の保存のうち一部だけ成功し、残りが失敗した状態。「動いた」ように見えて記録が食い違う。例状態は承認済みに変わったのに、承認の履歴が書けなかった。本文へ08-04 第3.1節

不変条件（invariant）応用設計

ひとことで処理の確定後や失敗の取消後など、外から見えるどの時点でも守られているべきルール。処理の内部で一時的に途中の状態を通ることはある。例承認済みの依頼には承認の履歴が必ず1件以上ある。承認を成功させた操作者は依頼者ではない。本文へ記事A 第8.2節

ブラウザ（web browser）基本実装・開発の道具

ひとことでWebページやアプリの画面を表示して操作するためのソフト。画面（フロントエンド）はこの中で動く。例承認アプリの画面をブラウザで開き、承認ボタンを押す。本文へ00-01 第3.1節

ブランチ（分岐）（branch）応用実装・開発の道具

ひとことで元の履歴を汚さずに変更を試すための、作業の枝分かれ。確認できたら元に合流する。例承認条件の変更をブランチで試し、レビューを通ってから main に合流する。本文へ06-03 第5.4節

プログラムとコード（program / code）基本実装・開発の道具

ひとことでコンピュータへの手順を書いた文章がコードで、それを動かせる形にしたものがプログラム。例count_by_state.js は「依頼一覧を読んで状態ごとに数える」手順を書いたコード。本文へ00-02 第5.4節

プロンプト（この教材では「指示文」）（prompt）基本AIとの協働

ひとことでAIに渡す文章そのもの。この教材では「指示文」と呼び、渡す資料・制約・返してほしい形式・完成条件を含める。例記入例「AIへ渡す資料と指示」の第7節にある指示文がプロンプトの実物。本文へ07-03 第5.3節

冪等性（idempotency）応用設計

ひとことで同じ操作を何度繰り返しても、意図した効果が1回分と同じで重複しない性質。返ってくる答えが同じかどうかは別の話。例2回目の承認を拒否する方式も、承認の効果は1回分しか起きないので冪等。本文へ記事B 第8.2節

変更影響調査（impact analysis）応用業務・要件

ひとことで1つの変更が、要件・データ・連携・権限・運用・教材のどこに及ぶかをたどって書き出すこと。例「取り下げ」を足すと、状態遷移表・権限表・利用手順書に影響する。本文へ13-02 第3.1節

変更管理（change management）応用公開・運用

ひとことで何をいつ誰が変えたかを記録し、レビューを経てから共有先に反映するルール。例保存単位・変更理由・分岐・レビュー・共有先の5つのルールを決める。本文へ06-03 第5.4節

方式比較（approach comparison）応用設計

ひとことで表計算の改善・ノーコード・ローカルツール・Webアプリなど、作り方の候補を目的と制約で比べること。例複数の利用者が別々の端末から同時に使う業務なら、1人のパソコン内で完結するローカルツールでは足りない、と比較表で示す。本文へ03-02 第5.2節

保守（maintenance）基本公開・運用

ひとことで使い始めたあとも、要望に応えて直し・足し・やめる作業を続けること。例改善要望の整理→影響調査→小さく更新→再検証、を繰り返す。本文へ13-01 第3.1節

保存先（データベース）（database）基本実装・開発の道具

ひとことで依頼や履歴を記録しておく場所。ファイル1つのこともあれば、専用のデータベースのこともある。例教材の演習では JSON ファイルや SQLite を保存先にする。本文へ00-01 第3.1節

目的と評価指標（goal / metric）基本業務・要件

ひとことで何が改善すれば「役立った」と言えるかを、測れる指標と測り方まで決めたもの。架空の数値を成果と混同しない。例目的・指標・測定方法の3つを決め、架空の仮定値と実際の測定結果を混同しない。本文へ01-03 第5.2節

役割（role）基本設計

ひとことで利用者を「できること」の違いで分けたもの。この教材では「依頼者」「承認者」「運用管理者」の3つ。例承認者は自分に割り当てられた提出済み依頼を承認・差戻しできるが、自分の依頼は承認できない。本文へ記事A 第5.2節

要件（requirement）基本業務・要件

ひとことで作るものが「何をできなければならないか」を、作る人と使う人の間で合意した文章。例「承認者は、自分に割り当てられた提出済みの依頼を承認できる」が1つの要件。本文へ記事A 第2節

ライブラリ（library）応用実装・開発の道具

ひとことで他の人が作った、部品として組み込めるプログラムのまとまり。例演習コードは Node.js の標準機能だけを使い、外部のライブラリを入れていない。本文へ06-04 第8.1節

リスク別の検証（risk-based verification）応用テスト・検証

ひとことで許可されない操作・重複・途中失敗・同時更新など、起きると困ることを一つずつ狙って確かめること。例同じ承認を2回送っても履歴が1件のままかを確かめる。本文へ09-03 第3.1節

利用開始判定（go / no-go decision）応用業務・要件

ひとことで未解決の問題・利用範囲・責任者・復旧手段を照らし合わせて、実業務で使い始めてよいかを決めること。例「演習成功」「限定試行」「実業務導入」のどの段階かを区別して判定する。本文へ10-04 第3.1節

利用者・関係者の整理（stakeholders）基本業務・要件

ひとことでアプリを使う人・仕事を頼む人・承認する人・管理する人を区別して一覧にすること。例利用者（依頼者・承認者）、担当者（総務担当）、承認者（総務課長）、管理者（運用管理者）の4つの立場を分ける。本文へ01-01 第5.2節

利用手順書と問い合わせ（user guide / support）基本公開・運用

ひとことで利用者の役割ごとの操作手順と、困ったときの連絡先・権限の申請先・担当をまとめたもの。例依頼者の手順、承認者の手順、運用管理者の手順、全員向けの問い合わせ手順の4つ。本文へ10-03 第5.5節

履歴（history）基本設計

ひとことで依頼に対して誰がいつ何をしたかを、追記だけで残す記録。例承認済みの依頼には承認の履歴が1件以上あるはず。本文へ記事A 第5.2節

例外時の画面（異常系）（error handling UI）基本設計

ひとことで入力ミス・差戻し・空の一覧・通信失敗など、うまくいかないときに何をどう表示するかの決まり。例必須項目が空なら、どの項目が足りないかを示して保存しない。本文へ04-04 第5.2節

レビューとレビュー記録（review）基本テスト・検証

ひとことで作った本人以外の視点で差分や成果物を読み、問題と残る課題を記録すること。例実装したAIとは別の観点で修正差分を読み、残課題を一覧にする。本文へ09-04 第5.2節

連携の確認（結合テスト）（integration test）応用テスト・検証

ひとことで画面・処理・保存先など複数の部品をつないで、一巡が通るかを確かめること。例画面役から提出を送り、処理側が受けて保存し、応答が戻るまでを確かめる。本文へ08-03 第3.1節

ローカル通信（localhost）（localhost）応用実装・開発の道具

ひとことで自分のパソコンの中だけで画面役と処理役をつないで試す通信先。外には出ない。例08-03 の演習は localhost で server.js と client.js をつなぐ。本文へ08-03 第5.2節

ログ（記録）（log）基本実装・開発の道具

ひとことでプログラムが「いつ何をしたか、何が失敗したか」を時系列で書き残したもの。障害時に最初に読む。例「状態は承認済みに更新、履歴の書き込みに失敗」というログから部分失敗に気づく。本文へ12-02 第3.1節