学習内容 · DMSD · QTS · AC 入試

Learning Inventory

学習計画ではない — itsuki が自身の 5クライアントプロジェクトをリバースエンジニアリングし、プログラミング基礎 + AC 入試で触れるべき内容を、「DMSD で最もよく使う + 学んですぐ使える」順に並べた一覧。

Part A · DMSD 第 0-13 章 Part B · QTS Q1-Q16 v0.2.0 · 2026-05-28

学習内容一覧 — DMSD / QTS / プログラミング / AC 入試

起草: 2026-05-25 by CC、2026-05-26 拡張（DMSD 第 9-12 章を追加 + QTS Part B 全 16 章）、2026-05-28 拡張（第 7 章 点呼機の深掘り知識パック 7.6-7.16 + 第 1 章 1.7 プロジェクト進捗パノラマ 12 小節：段階 0-8 + マイルストーン + 意思決定記録 + リポジトリ地図）
対象: itsuki — プログラミングはゼロ基礎だが 5クライアントプロジェクト DMSD をすでに実装済み。在学中の空き時間で自分のプロジェクトをリバースエンジニアリングしたい。並行して QTS クオンツ取引システムも準備中（ペースは DMSD 優先）。
性質: 学習内容一覧であり、学習計画ではない（itsuki の原話：「計画じゃなくて、学ぶべき内容を列挙してほしい」）
構造: 大きく 2 ブロック — Part A · DMSD + AC 入試（目の前の主線、第 0-13 章）/ Part B · QTS クオンツ取引（最終地図、Q1-Q16。#008 の意思決定により DMSD 優先へ譲歩。「方向の地図」であり「明日すぐ学ぶもの」ではない）
関連: 02_分析与调研/AC入試制度総覧_2027.html とセット — Part A の内容は AC 採点の 3 点（関心 / 能力 / 表現）に直接対応
この一覧の書き方:

目次

Part A · DMSD + AC 入試
  1. 第 0 章 — この一覧をこう書いた理由
  2. 第 1 章 — 自分のプロジェクトへの習熟度（最優先 / プログラミングのハードル 0）
  3. 第 2 章 — 基礎の共通知識（5クライアントすべてに必要）
  4. 第 3 章 — Python（バックエンド + 点呼機、2クライアントで使用）
  5. 第 4 章 — Swift + SwiftUI（iOS / AC デモの重点）
  6. 第 5 章 — Kotlin + Compose（Android）
  7. 第 6 章 — TypeScript + Vue（教員 Web）
  8. 第 7 章 — ハードウェア + 組み込み（点呼機）
  9. 第 8 章 — AC 入試に直結する知識
  10. 第 9 章 — プロジェクト基盤の稼働ロジック 🆕
  11. 第 10 章 — コンピュータサイエンス基礎（情報科学類 1-2 年の共通科目の予習）🆕
  12. 第 11 章 — 情報セキュリティ深掘り（CTF / SecHack365）🆕
  13. 第 12 章 — ソフトウェア工学（DMSD を工学化する理論）🆕
  14. 第 13 章 — 推奨学習順（参考、強制ではない）
Part B · QTS クオンツ取引（最終地図）
  1. Part B 序 — QTS を別枠にした理由
  2. Q1 — プログラミング基礎（前提として必須）
  3. Q2 — 数学と統計の基礎
  4. Q3 — 金融市場の基礎
  5. Q4 — 市場のミクロ構造
  6. Q5 — 日本市場特化（TSE / moomoo）
  7. Q6 — クオンツ取引の理論
  8. Q7 — データ
  9. Q8 — データ処理のツールチェーン
  10. Q9 — 戦略開発
  11. Q10 — バックテスト（手法より落とし穴が重要）
  12. Q11 — リスク管理
  13. Q12 — 実運用への配備
  14. Q13 — 機械学習のクオンツへの応用
  15. Q14 — AI Agent 多層アーキテクチャ（QTS の特色）
  16. Q15 — 行動ファイナンスと心理
  17. Q16 — エンジニアリングと運用

第 0 章 — この一覧をこう書いた理由

0.1 itsuki の現在地

0.2 AC 入試の 3 つの採点点と学習の関係

採点点 AC の要求 学習との対応
関心 情報科学への強い興味があり、継続的に追っている軌跡があること 学習記録（05_logs/learning_path.md）そのものが追跡の証拠 — 学ぶたびに 1 条目「なぜ学んだか / 何を学んだか / 気づき」を書く
能力 自ら課題を設定し、創造的に解決すること DMSD プロジェクト自体が中核の証拠 — 深掘りするほど、自分の設計選択を説明できる
表現 過程と結果を論理的に説明すること（書面 + 口頭） 広さを追わず、学んだものを一つずつはっきり話せることを追う — 審査員が「なぜ NFC を使うのか」と聞いたら、物理原理からコードまで語る

0.3 学習設計の 5 原則

  1. 学ぶたびに DMSD の既存コードとつなげる — プロジェクトと無関係なことは学ばない
  2. 学ぶたびに「それで何をしたか」を一文で書けること — それが AC 面接の素材になる
  3. 広さを追わず、はっきり話せることを追う — 審査員がどんな技術細部を聞いても、原理からコードまで語れること
  4. 作りながら学ぶ（既存の原則、05_logs/learning_path.md §中核の学習哲学）— 「先に何か月もプログラミングを学んでから始める」従来ルートは取らない
  5. 三つの鉄則：各行のコードを説明できる / 先に予想してから走らせる / dev_log を書く（dev_log = 開発日誌。毎日ぶつかったこと・変えたことを記す）

第 1 章 — 自分のプロジェクトへの習熟度（最優先 / プログラミングのハードル 0）

itsuki の原話：「今は自分のプロジェクトのファイルすら全部見分けられない」。この章では一行もコードを書かない。読む + 見る + 頭の中にプロジェクト地図を作るだけ。最優先なのは、AC 面接で審査員が「あなたのプロジェクトには何があるか」と聞いたときに自分で答え切れないと、最も致命的な失点になるから。

1.1 プロジェクト地図（630+ ファイルをディレクトリ別に）

DMSD のトップレベルディレクトリ構成（11 ディレクトリ）
必学 難易度 ★
DMSD プロジェクトルート ~/dev/DMSD/ 直下の 11 ディレクトリ、それぞれの役割
読む .claude/skills/project-overview/SKILL.md §1 — このファイルは itsuki が CC に代わりに保守させている「プロジェクトファイル総覧」。630+ ファイルの全一覧。1 回読めば各ファイルの役割がわかる。
AC の話：審査員が「プロジェクトの規模は」→「トップレベル 11 ディレクトリ、約 630+ ファイル。5クライアントのコード + 仕様 + 設計 + 運用 + 日誌 + 資産に分かれる」と答える
5クライアントのコード配置（03_dev/ 直下の 5 サブディレクトリ）
必学 難易度 ★
backend（バックエンド）/ student_ios（iOS 学生端）/ student_android（Android 学生端）/ teacher_web（教員 Web 端）/ rollcall_device（点呼機端、Raspberry Pi 上で動作）
読む 03_dev/ 各サブディレクトリの README または DESIGN_LOG.md
AC の話：審査員が「なぜ 5クライアントか」→ 「学生はスマホで出席（iOS / Android）、教員はパソコンで学生を管理（Web）、出席はハードウェアで刷る（点呼機）、全データを一つのバックエンドに集約する」と答える

1.2 プロジェクトの変遷（v0.1 → v0.8 の意思決定ライン）

8 回のバージョン反復で毎回何をしたか / なぜか
必学 難易度 ★★
v0.1 仕様凍結 → v0.3 仕様の大幅改訂 → v0.4 点数体系を決定 → v0.5 設計文書を書き直し → v0.6 三クライアントのコード bootstrap（bootstrap = プロジェクトの最初の枠組みを立てること）→ v0.7 学生登録コード + 教員お知らせ → v0.8 ツールチェーンの定型化
読む CHANGELOG.md（トップレベル）+ 00_admin/progress_overview.md
AC の話：審査員が「プロジェクトはどう進化したか」→ 各バージョンでなぜ bump したか（bump = バージョン番号の上げ）を順に説明できること。AC が最も聞きたい「反復の思考過程」

1.3 仕様文書（spec）— プロジェクトの「コードを書かない真の情報源」

RollCall 仕様 = 点呼システムの要件定義
高優先 難易度 ★★
spec = specification（仕様書）— コードを書く前に、文章 + 表で「この機能は何をする / 何をしない / エラーをどう扱うか」を定義する。5クライアントすべてのコードは仕様どおりに実装しなければならない。
読む 01_specs/rollcall/RollCall_Spec_v0.1.md（本体）+ 01_specs/rollcall/字典/ 直下の三点セット（用語辞書 / 状態辞書 / エラー辞書）
AC の話：審査員が「5クライアントの振る舞いをどう揃えるか」→ 「先に仕様を凍結してから実装する。仕様が単一の真の情報源で、5クライアントとも仕様に従う」と答える

1.4 設計文書の二層構造

共用層 vs 専属層
高優先 難易度 ★★
2 クライアント以上にまたがる設計は共用層（02_design/system_features.md）に、単一クライアントの設計は専属層（各クライアントごとの *_DESIGN_LOG.md）に書く。こうすると改訂時に 5 か所を重複して直さなくてよい。
読む 02_design/system_features.md（共用層 830 行）+ いずれか一端の DESIGN_LOG（まず iOS が直感的）
AC の話：審査員が「5クライアントの文書はどう衝突しないか」→「二層構造 + ファイル連動マトリクス」と答える

1.5 ファイル連動マトリクス

A を直したら必ず B を見る 17 ルール
中優先 難易度 ★★
5クライアントプロジェクト最大のリスク = 一か所を直して別の一か所を忘れ、フィールドが食い違うこと。DMSD は「連動マトリクス」(matrix) で 17 本の「A を直したら必ず B」ルールを固定し、CC がコードを書くたびに連動チェックスクリプトを自動実行する。
読む .claude/skills/file-linkage/SKILL.md + 00_admin/hooks/lib/sync-rules.sh
AC の話：審査員が「5クライアントのコードはどうドリフトしないか」→「PostToolUse hook が sync-check スクリプトを自動実行し、一か所直したらすぐ別の一か所を確認するよう促す」と答える

1.6 プロジェクトのツールチェーン（hook / skill / agent）

DMSD に入れた 7 個の PostToolUse hook + 1 個の SessionStart hook + 30+ skill
中優先 難易度 ★★★
hook = フック。特定イベント発生時に自動で走るスクリプト（例：CC がファイルを直したあと連動チェックを自動実行）。skill = スキル。CC が特定キーワードで自動読み込みする作業手順書。DMSD はすでに 7 個の hook + 30+ skill を入れ、CC の職務不履行を防ぐ。
読む 00_admin/hooks/README.md + .claude/skills/ 配下の各 SKILL.md（まず session-wrap と version-bump。最もよく使う）
AC の話：審査員が「AI との協働をどう管理するか」→「自分で hook + skill を設計し、AI に規則どおりに働かせる。AI はブラックボックスではなく道具」と答える

1.7 プロジェクト進捗パノラマ（v0.1 → v0.8 + 以降の累積推進）

🆕 2026-05-28 追加：この節は DMSD プロジェクト状態総覧のミラー （同等は 00_admin/progress_overview.md）。 itsuki は時間があるときに一通り見て、各ディレクトリ / 段階の前後（原因と結果 + 現在の状態）を把握する。 詳細日誌は 05_logs/にあり、本節はスナップショットにすぎない。

1.7.1 プロジェクト身分カード

  • リポジトリ / 開発コードネーム：DMSD（Dormitory Management System Digitalization）
  • システム / 製品名（対外）：Tomoshibi（灯火 / ともしび，2026-04-21 定名）
  • 一言で：寮の紙の点呼・出席管理と規律管理の流れをデジタル化し、NFC カード + バックエンドサーバ + スマホ App で実現する
  • 開発者：itsuki（一人で独立開発）
  • 開始時期：2026 年 2 月
  • GitHub：otogi2025/DMSD（2026-04-29 から public）

1.7.2 段階分け戦略（2026-04-19 G2 意思決定後、段階分けは取消）

⚠️ 2026-04-19 G2 意思決定：当初計画「Phase 1 = カード + 点呼機 / Phase 2 = スマホ App」は廃止済み。 v1.0 で iOS + Android + カードを一括リリース。 理由：itsuki が「段階分けはユーザー体験を分断し、二重ロジックの保守コストが増える」と決定。 内部の開発ペースはなお M1 → M5 マイルストーン（最低ライン：終わらなくても少なくとも M1 + M2 でデモ可能）。
4-19 以前の旧段階分け（履歴）
段階内容不要
Phase 1NFC カード + バックエンド + 点呼機 (Raspberry Pi)学生 App
Phase 2スマホ App を追加 (iOS + Android)—

1.7.3 システムアーキテクチャ（5クライアント monorepo の実トポロジ）

  点呼室入口                          VPS サーバ
┌─────────────┐                  ┌──────────────┐
│ 点呼機 A    │───── HTTP ──────→│              │
│ (Pi 3A+ +   │←── 学生の名前 ───│  FastAPI     │
│  PN532 V3 + │                  │  + PostgreSQL│
│  USB 音響)  │                  │  + Alembic   │
└─────────────┘                  │              │
                                 │              │
┌─────────────┐                  │              │
│ 点呼機 B    │───── HTTP ──────→│              │
│ (Pi 3A+ + … │←── 学生の名前 ───│              │
└─────────────┘                  │              │
                                 │              │
┌─────────────┐                  │              │
│ 学生 App    │───── HTTP ──────→│              │
│ (iOS Swift /│←── JWT / data ───│              │
│  Android    │                  │              │
│  Compose)   │                  └──────┬───────┘
└─────────────┘                         │ HTTP
                                        ↓
                                 ┌──────────────┐
                                 │ 教員 Web     │
                                 │ (HTML stand, │
                                 │  Ryō スタイル,   │
                                 │  iPad ブラウザ)│
                                 └──────────────┘

NFC カード / タグ（学生がカード所持 + 入口の動的タグ）:
  - NTAG215      (学生カード, 7B UID)
  - ST25DV16K    (動的タグ, 10 秒ごとに nonce を更新)
教員 Web 意思決定ドリフト注：2026-05-02 に TS + Vite + Zustand 実装版を起案、 2026-05-26 itsuki が全体廃棄を決定（心の中の Ryō 24 学生座席表 + リアルタイム点呼ダッシュボードではなかった）、 4-21 の Ryō standalone 単一 HTML 主線に戻る。Vite 実装版 13 ファイルは 99_archive/2026-05-26_teacher_web_vite实装作废/。

1.7.4 中核機能：点呼システムの流れ

点呼 1 ラウンドの 8 ステップ
  1. 教員が管理画面で「点呼開始」をクリック
  2. 学生が NFC カード（または Phase 2 のスマホ）を点呼機にかざす
  3. 点呼機が UID を読み取り → バックエンドへ送信 → 学生氏名を返す
  4. 点呼機のスピーカーが学生氏名を読み上げる（不正防止の核心設計）
  5. 教員が横で顔を照合する
  6. システムが自動判定：定時 / 遅刻 / 欠席
  7. 教員は手動で判定を変更できる（理由の記入が必要。システムは監査記録を残す）
  8. 時間になっても未終了 → システムが自動終了して精算する
規律ルール（減点体系）
  • 遅刻：+0.5 点
  • 欠席：+1.0 点
  • 月累計 ≥ 4.0 → 翌月は罰掃
  • 月累計 ≥ 8.0 → 翌月は禁足
2026-04-29 itsuki 決定禁足の閾値を ≥9 から ≥8（等しい場合を含む）へ変更。 単一の真の情報源は 00_admin/文档同步点清单.md §10 + 01_specs/rollcall/v0.1_冻结决策.md §1。
不正防止の核心 = 音声読み上げ
点呼機がカードを読んだあと学生氏名を自動読み上げし、教員が目で照合する。 「機械による身分識別」と「教員の目視識別」をリアルタイムでペアにする → 攻撃者は本人が現場にいなければならない（詳細は 05_logs/decision_log.md）。

1.7.5 全体進捗（段階 0 → 段階 8）

段階 0 — 仕様設計 ✅ 完了（2026-02 月）
段階 0.5 — アーキテクチャ意思決定 ✅ 完了（2026-04-12）
段階 0.6 — バージョン管理と記録体系 ✅ 完了（2026-04-13）
段階 1 — プロジェクト立ち上げ ✅ 完了（2026-03-10）
段階 2 — プログラミング学習 🔄 進行中
段階 3 — バックエンド開発 🔄 進行中（v0.7 - v0.8 で大きく前進）
段階 4 — 点呼機デバイス開発 🔄 進行中（設計層は完了 / ハードウェア調達 + Pi 上でのプログラミングは未着手）

完了済み（設計層 + 文書層）：

未着手（実物層 + 実装層）：

段階 5 — 教員向け Web/iPad 画面 🔄 進行中
段階 6 — iOS 学生 App 🔄 進行中（v0.8 + 以降、bump なしのまま複数回推進）

完了（v0.8 close 5-02）：

v0.8 以降の推進（pending bump）：

段階 7 — Android 学生 App 🔄 進行中（v0.8 + 以降、bump なしのまま複数回推進）

完了（v0.8 bootstrap 5-02）：

v0.8 以降の推進（pending bump）：

v0.8 以降、bump なしのまま蓄積した推進（5-04 → 5-22）
日付主要な節目
2026-05-04ファイル連動ツール（pre-commit + sync-check.sh + ルール 18 条をコード化）+ 中国語の鉄則を強化
2026-05-08ハードウェア全確定（PN532 V3 + LED + スピーカー + 筐体）+ system_features を 4-30 に大幅書き換え
2026-05-10ac-radar skill を公開（グローバルに AC 素材をリアルタイム捕捉、プロジェクト横断の inbox）
2026-05-11cc-comm-rules skill を立ち上げ（コミュニケーション規則）+ graphify の試験 + 用語集 HTML + reviewer バックドア修正でのマシン横断コラボ
2026-05-13ファイル大整理（26 ファイルを rename / archive）+ project-overview skill を新設（630+ ファイルの一覧）
2026-05-14anti-ai-flavor skill を立ち上げ + cc-comm-rules の規則を v0.5.0 へ昇格
2026-05-16プロジェクト横断の大規模改修（SC26 / Tango / cc-project-template）+ AC 合格率の評価
2026-05-19project-overview の大改造（ドリフト修正 9 箇所 + §0.1 を再計算して 957 ファイル）+ ドリフト防止案 C（hook 全カバー + 起動時突合）+ post-edit-format.sh + check_overview_drift.sh
2026-05-20+bug findings 131 件を 4 セッション並行で修正（主セッション + Fix-Bot 1/2/3）
2026-05-21teacher_web/demo 一式 158 ファイルを 99_archive/ へアーカイブ + Fix-Bot 4 で effective_* フィールドを完全削除（spec 本体 + 辞書三点セット + backend models + 新規 alembic マイグレーション）
2026-05-22project-overview §0.1 を再校正 957 → 980 + 系统bug专栏.md / codex_audit_prompt.md の参照を追加 + Codex 第2ラウンドの全ファイル対象 audit（1003 ファイル / 39 件 = 独立 24 + 再確認 13 + positive 2）+ session-coord のセッション横断コラボボード（3 セッション並行：主 + 点呼機 + iOS 修正）
段階 8 — デプロイと試運転 ⬜ 未着手

1.7.6 プロジェクトマイルストーン（v0.4 → v0.8 + 以降）

4月末〜5月初めの集中推進の概観。詳細な commit 履歴 → git log / CHANGELOG.md。
バージョン日付テーマ主な成果物
v0.4 - v0.5 2026-04-17 → 04-29 RollCall spec の書き直し + プロジェクトレビュー + ドキュメント体系の確立 RollCall_Spec v0.2 辞書三点セット + v0.3 本体の書き直し / プロジェクトレビュー backlog 87 件 / 単一ソースの真実 + 同期点一覧 + pre-commit hook 三点セット
v0.6 2026-04-29 教員フィードバック 38 件を受領 + システム機能の大幅書き換え 教員 LINE 要件一覧 38 件 + R1-R4 の硬制約 / system_features.md 中国語スケルトンの大幅書き換え / Demo 4-28 を寮管理者にデモ + 4-29 に口頭で採用合意
v0.7 2026-04-30 3トラック A+B+C を同日完了し、38 件を消化 A 状態の棚卸し / B §9 の決定 / C 実装 brief の起草（backend / iOS / Web 各クライアントの REQUIREMENTS / DESIGN_LOG）+ 帰省実物表の evidence を入手
v0.8 2026-05-02 3クライアントのコード層を全面起動 Android Compose bootstrap（.kt 21 + 画面 10）/ iOS ネットワーク層の一式構築 + AppStore を本番バックエンドへ切替 / teacher_web v1 を TS+Vite+Zustand へアップグレード + 5 page / backend の rollcall+study+teachers routers + Alembic / iOS↔backend フィールド整合 F1-F5+Q1
v0.8 以降（pending bump） 2026-05-03 → 05-04 登録コード + お知らせ + ファイル連動ツール App Store 公開対策（学生登録コード 6 桁・5 分間有効）/ 教員お知らせ機能（4クライアント、backend + iOS 完了）/ A+B ファイル連動ツール（pre-commit + sync-check.sh + ルール 13 条をコード化）/ 中国語の鉄則を強化（叱責 3 回のあと規範ドキュメントへ拡大）

1.7.7 技術学習タイムライン

日付何を学んだか主な収穫
2026-02 月プロジェクト仕様設計システム要件の定義、範囲の凍結、仕様書の書き方を習得
2026-03-10Git 基礎バージョン管理の意味を理解し、複数デバイス間の同期フローを確立
2026-03-11Python の変数・データ型・条件分岐初めてコードを書いて実行
2026-03-11フロントエンド / バックエンド / API / データベースの概念システム全体の通信アーキテクチャを理解
2026-04-10NFC と NFD（Unicode normalization）クロスプラットフォーム開発の隠れた落とし穴。エラーメッセージは誤解を招くことがある
2026-04-12NFC の原理（電磁誘導 + 13.56MHz + UID）NFC は黒魔術ではなく、高校物理の応用
2026-04-12iOS Core NFC フレームワーク + SwiftUI 基礎カード読取の中核ロジック ~60 行の Swift
2026-04-12Python nfcpy + pyttsx3Raspberry Pi デバイス側コード ~20 行
2026-04-13SemVer セマンティックバージョニング規約バージョン番号は「リリース」用であり、毎回の commit 用ではない

1.7.8 重要決定の記録（索引）

詳細な経緯は 05_logs/decision_log.md。
日付決定
2026-02-12v0.1 仕様凍結
2026-03-10Git + GitHub でコードを管理
2026-03-11練習用コードは ~/dev/practice/に置き、DMSD には置かない
2026-03-11Claude Code で開発を補助
2026-04-12NFC を採用し二次元コードは使わない（不正防止）
2026-04-12段階的リリース（Phase 1 カード + Phase 2 App）
2026-04-12点呼機 = Raspberry Pi（iPad ではない）
2026-04-12音声読み上げによる不正防止の設計
2026-04-13バージョン番号体系をリセット v1.0 → v0.1
2026-04-19G2 決定：段階リリースをやめ、v1.0 で iOS + Android + カードを一括リリース
2026-04-19単一ソースの真実 + 同期点一覧 + pre-commit hook 三点セットを確立（ドキュメントのバージョン番号ドリフト防止）
2026-04-20動的 NFC シール ST25DV16K（10 秒 nonce）+ Pi 4B 2GB × 4 の調達を決定
2026-04-21システム / 製品名を Tomoshibi（灯火 / ともしび）
2026-04-28Demo 4-28 を寮管理者にデモ（NFC → バックエンド → iPad の座席が緑に変化 + 音声読み上げ）
2026-04-29管理者が口頭でシステム採用に合意；GitHub repo を初めて public に
2026-04-29教員 LINE フィードバック要件 38 件 + R1-R4 の硬制約（メール通知 / 高齢 UX の一本道 / 教員専用アカウント / 1·2 寮と 4 寮を分けて表示）
2026-04-29禁足閾値 ≥9 → ≥8 を単一ソースの真実で統一
2026-05-02Android 実装方針を決定：CC 主導で画面ごとに Compose へ対訳（sub agent は使わない）
2026-05-03学生登録コードを決定（教員が 6 桁数字を生成、5 分間有効）— App Store 公開対策
2026-05-03教員お知らせ機能を決定（Classroom 風、scope=all/male/female、学生の返信は全員が相互に閲覧可）
2026-05-03Apple Intelligence の on-device AI 路線を統一（Image Playground アバター / Foundation Models 要約 / Translation framework）
2026-05-04A+B ファイル連動ツールを決定（pre-commit による内容チェック + bin/sync-check.sh 途中で随時確認）
2026-05-04中国語の鉄則を強化（適用範囲を規範ドキュメントへ拡大、叱責 3 回）

1.7.9 問題解決の記録（索引）

詳細記録は 05_logs/problem_solving/。
日付問題種別
2026-03-10tar の打包でエラー「no files or directories specified」コマンドライン
2026-03-10scp でファイル転送時に宛先パスが欠けていたコマンドライン
2026-03-11Python NameError（変数が未定義）プログラミング
2026-03-11Python のブール値は True / False と大文字必須プログラミング
2026-04-10Git pull 失敗：NFC vs NFD のクロスプラットフォーム文字コード差Git / クロスプラットフォーム

1.7.10 開発環境

2026-04-19 更新：VPS は DMSD 用途で停止済み（itsuki が学校の iPad から DMSD 作業を進めない方針に決定）。 現在は自宅 Mac 1 台のみがホスト。
  • 自宅 Mac（~/dev/DMSD）→ Claude Code + Xcode（iOS 開発）+ VS Code — 現時点で唯一の dev 環境
  • GitHub otogi2025/DMSD = 唯一のリモート真実源、2026-04-29 から public
  • 独立 repo：otogi2025/Tomoshibi-iOS（iOS Swift 実装のミラー）+ otogi2025/Tomoshibi-Android（Android Compose）

1.7.11 現在の ToDo

優先（短期）
  • [ ] 4-10 の dev_log にある【】プレースホルダー 4 箇所を埋める
  • [ ] reflection_2026-04-10 の【】プレースホルダー 5 箇所を埋める（iCloud へ移行済み AC素材_成品/reflection/）
  • [ ] 回答する AC素材_成品/ac_入試准备/项目起源_真实观察.md にある AC 起源の問い（iCloud へ移行済み）
  • [ ] Python 学習を続ける（次：ループ + リスト）
中期
  • [ ] .pages ファイルを Markdown へ変換（4 ファイル）
  • [ ] 初期の throwaway iOS コードを削除 / アーカイブ
  • [ ] Swift / SwiftUI の基礎を学ぶ
  • [ ] VPS に PostgreSQL をインストール
  • [ ] FastAPI バックエンドの骨格を構築
長期
  • [ ] Raspberry Pi + NFC モジュールを調達し、点呼機プロトタイプ 1 台目を組み立てる
  • [ ] 作成 README.md（コードを書き始めたら）
  • [ ] 人とプロジェクトを議論する（iCloud の AC素材_成品/interview_log/）
  • [ ] 月次振り返り（毎月最終週、iCloud の AC素材_成品/monthly_review/）

1.7.12 リポジトリ構造マップ（トップレベルディレクトリの骨格）

2026-05-21 に書き直し：旧来の静的構造図は著しく陳腐化していた。 真実源は → .claude/skills/project-overview/SKILL.md （630+ ファイルの一覧 + 各ファイルの役割 + 状態 + AC 価値、957 ファイルの全統計 2026-05-16）へ移行済み。 本節ではトップレベルディレクトリの骨格のみ列挙（ドリフト防止）。詳細は上記 skill を参照。
トップレベルディレクトリ用途ファイル数（2026-05-16 時点）
ルート直下 6 ファイルCLAUDE / README / CHANGELOG / LICENSE / .gitignore / .graphifyignore6
00_admin/プロジェクト管理（WIP / TODO / progress_overview / hooks / ドキュメント同期点一覧）18
01_specs/仕様ドキュメント（rollcall 辞書三点セット + 本体）13
02_design/設計ドキュメント（system_features / hardware / flow）3
03_dev/5クライアントのコード（backend / teacher_web / student_ios / student_android / rollcall_device）546
04_ops/運用2
05_logs/開発 log（raw / dev_log / problem_solving / decision_log / learning_path / project_evolution）75
06_assets/icon 4 点 + 用語集 + 実物サンプル7
99_archive/初期アーカイブ273
.claude/CC 設定 + skill 7 本9+
bin/スクリプト（sync-check / check_overview_drift / create_local_dev_symlink）3
docs/Matt Pocock 外部 skill の適合設定3
合計957

第 2 章 — 基礎の共通知識（5クライアントすべてに必要）

本章は「学ばなければ 5クライアントが何をしているか理解できない」下層の知識。言語を問わず、5 クライアントすべてで使う。各項目はすでに DMSD で実装済みであり、抽象学習ではない。

2.1 コマンドライン / ターミナル基礎

cd / ls / cat / grep / find
必学 難度 ★
cd = change directory でディレクトリ移動 / ls = list でファイル一覧 / cat = ファイル内容の表示 / grep = 一致する文字列を探す / find = ファイルを探す。Mac ターミナル（Terminal.app）と zsh（Mac のデフォルト shell＝コマンドライン解釈器）の基本操作。
DMSD で日常的に触る：実行 bash bin/sync-check.sh 連動チェックを実行 / git status で変更を確認 / find . -name "*.md" でドキュメントを探す
AC ストーリー：面接の場でターミナルからプロジェクトディレクトリを開きファイルを見せられる = 加点要素

2.2 Git バージョン管理

commit / branch / push / pull / log
必学 難度 ★★
Git = コードのバージョン管理ツール。commit = 変更スナップショットを 1 回保存 / branch = ブランチ（別機能を同時開発しても干渉しない）/ push = リモートリポジトリへ送る / pull = リモートの最新を取得 / log = 履歴を見る。DMSD は v0.8 時点で 200+ commit。
DMSD で日常的に触る：各セッション終了時に CC が commit message（commit 説明文）を起草し itsuki が採否を決める。pre-commit hook（コミット前に自動実行されるスクリプト）はすでに 00_admin/hooks/pre-commit
AC ストーリー：審査員が GitHub を確認する可能性 otogi2025/DMSD で commit 履歴を見る → 200+ commit 自体が「継続的に追跡している」証拠

2.3 ファイルパス / ディレクトリ構造

絶対パス vs 相対パス / 隠しファイル / シンボリックリンク
高優先 難度 ★
絶対パス = ルートから始まる（/Users/kurekoduki/dev/DMSD/）/ 相対パス = 現在位置から辿る（./03_dev/）/ 隠しファイル = ドット始まり（.claude/）/ シンボリックリンク = あるファイルが別ファイルを指すショートカット
DMSD では：.claude/skills/ は隠しディレクトリ / 各種相対パスはスクリプト内に / Cloud iCloud パス ~/Library/Mobile Documents/com~apple~CloudDocs/ は Mac 上の iCloud の実パス

2.4 JSON / YAML / Markdown

テキスト形式 3 種
必学 難度 ★★
JSON = JavaScript Object Notation。オブジェクトデータの形式で、API データ転送の標準（DMSD backend が返すのも JSON）
YAML = YAML Ain't Markup Language。インデント型の設定形式（hooks 設定は YAML）
Markdown = 軽量な文書形式（DMSD のほぼすべての .md ファイルがこれ）
DMSD では：API は JSON を返す / hooks 設定 / すべての spec + design + log は Markdown

2.5 HTTP / API クライアント–サーバ構成

クライアントがサーバとどう会話するか
必学 難度 ★★★
HTTP = HyperText Transfer Protocol ハイパーテキスト転送プロトコル（ネットワーク上でクライアントとサーバが通信する規則）
GET / POST / PUT / DELETE = HTTP リクエストメソッド 4 種（GET は取得 / POST は作成 / PUT は更新 / DELETE は削除）
API = Application Programming Interface アプリケーション・プログラミング・インタフェース（サーバが外部に公開する「クライアントが呼び出せる機能一覧」）
REST = Representational State Transfer 表象状態転送（API 設計スタイルの一種。DMSD はこれを採用）
ステータスコード = 200 OK / 401 未認可 / 404 未検出 / 500 サーバ側障害
DMSD では：iOS / Android / Web の 3 クライアントがいずれも HTTP で backend と会話する。backend は 03_dev/backend/routers/ 配下で API エンドポイントを定義（API endpoint = 具体的な URL パスのひとつ）
AC ストーリー：審査員が「クライアントはどうデータを取るか」と問う → HTTP リクエストから backend の route、さらにデータベース照会まで語れる

2.6 データベース基礎（PostgreSQL）

表 / フィールド / 主キー / 外部キー / インデックス / クエリ
必学 難度 ★★★
PostgreSQL = Postgres。無料オープンソースのリレーショナルデータベース（DMSD はこれですべてのデータを保持）
表 (table) = Excel のシートに似たもの。1 行が 1 件のデータ
フィールド (column) = 表の列。例：student_id / name / dorm_room
主キー (primary key) = 行を一意に識別するフィールド（通常は id）
外部キー (foreign key) = 別表の主キーを指すフィールド（学生表の dorm_id が寮表の id を指す）
インデックス (index) = フィールドの検索を速くするデータ構造
SQL = Structured Query Language 構造化問い合わせ言語（データベースと会話するための言語）
DMSD では：03_dev/backend/models.py ですべての表を定義 / alembic/versions/ 配下はマイグレーションスクリプト（migration = データベース表構造の変更記録）
AC ストーリー：審査員が「点呼記録はどう保存するか」と問う → 表設計からフィールド型、クエリ性能まで語れる

2.7 セキュリティ基礎（hash / 暗号化 / 署名 / nonce）

なぜ DMSD の不正防止にこれらを使うのか
高優先 難度 ★★★★
hash = ハッシュ。任意長のデータを固定長の指紋に圧縮する（パスワードは生で保存せず、ハッシュを保存）
暗号化 (encryption) = データを、鍵を持つ者だけが読める乱文に変える
署名 (signature) = 「このデータは誰かが送ったものであり、改ざんされていない」ことを証明する
nonce = number used once の使い捨て乱数（再送攻撃の防止 — 攻撃者が一度の通信を録音して再送できないようにする）
ECDSA = Elliptic Curve Digital Signature Algorithm 楕円曲線デジタル署名アルゴリズム（DMSD の代理サイン防止にこれを使う）
DMSD では：NFC カード ST25DV16K が動的 nonce を 10 秒ごとに更新 / 学生登録コードは hash で検証 / 教員権限は ECDSA 署名を用いる
AC ストーリー：審査員が「代理サインをどう防ぐか」と問う → 物理 NFC の距離制限から nonce による再送防止、ECDSA 署名まで語れる = 完全な防御連鎖 = 極めて強い加点

第 3 章 — Python（backend + 点呼機、2クライアントで使用）

Python を最優先にする理由：DMSD の 5クライアントのうち 2クライアントが使用（backend + 点呼機）。一度学べば 2クライアント分のコードが読めるため、投資対効果（ROI = Return on Investment）が最も高い。

3.1 Python の基礎文法

6 つの下位項目を展開
変数 / 型 / 文字列 / 数値 / ブール
必修 難易度 ★
DMSD 03_dev/backend/main.py 1 行目からすぐ見える
リスト / 辞書 / タプル / 集合
必修 難易度 ★★
list は順序付きで可変 / dict はキーと値の組 / tuple は順序付きで不変 / set は順序なしで重複排除。Python の基本コンテナ 4 種。
backend の API が返すデータ構造はほぼ dict の入れ子に list
if / for / while / try-except
必修 難易度 ★★
制御フロー + 例外処理。except = エラーを捕捉してプログラムを落とさない。
関数 / 引数 / 戻り値 / デフォルト値 / キーワード引数
必修 難易度 ★★
クラス / オブジェクト / 継承 / メソッド
高優先 難易度 ★★★
オブジェクト指向プログラミング（OOP = Object-Oriented Programming）入門。SQLAlchemy の model はクラスそのもの。
モジュール / パッケージ / import / __init__.py
高優先 難易度 ★★
モジュール = 1 つの .py ファイル / パッケージ = 複数モジュールを入れるディレクトリ。backend のコードは routers/ services/ models/ schemas/ いくつかのパッケージに分かれている。

3.2 FastAPI（backend 用の Web フレームワーク）

FastAPI = Python でバックエンド API を書くフレームワーク
必修 難易度 ★★★
フレームワーク (framework) = 他人が用意したコードの骨格で、自分は業務ロジックだけ埋める
Route = ルーティング。1 つの URL に 1 つの関数が対応（GET /students が list_students() 関数を呼ぶ）
依存性注入 (Dependency Injection) = 関数が必要とするもの（データベース接続 / 現在のユーザー）をフレームワークが自動で差し込む
OpenAPI = 自動生成される API ドキュメント（FastAPI を起動すると付属の /docs パスで全 API を確認できる）
DMSD 03_dev/backend/routers/ 配下のすべての .py ファイル / 03_dev/backend/main.py 組み立て
AC ストーリー：審査員が「なぜ FastAPI で Django / Flask ではないのか」と聞いたら → 「OpenAPI ドキュメントの自動生成が 5クライアント連携に役立つ / Flask より高性能 / Django より軽量でデモ段階に合う」と答える

3.3 SQLAlchemy（データベース ORM）

Python のクラスでデータベースの表を操作する
必修 難易度 ★★★★
ORM = Object-Relational Mapping オブジェクト関係マッピング — Python のクラスをデータベースの表に対応させ、SQL を直接書かなくてよい。
Model = Python のクラス 1 つが表 1 枚に対応（class Student(Base)）
Session = 1 回のデータベースセッション。一連の操作のあと commit（コミット）または rollback（ロールバック）
DMSD 03_dev/backend/models.py — 5 クライアントの全データベース表の定義がこの 1 ファイルに集約

3.4 Pydantic（データ検証）

API 入出力の「型の門番」
必修 難易度 ★★★
Pydantic = Python のデータ検証ライブラリ — クライアントが送るデータ / サーバーが返すデータは、いずれも Pydantic schema（スキーマ）で定義する。フィールドの型が違えば自動でエラーになる。
Schema = スキーマ / データ形状の定義 — model とは違う：model はデータベースの表、schema は API の出入り口
DMSD 03_dev/backend/schemas.py — models.py と対になる
AC ストーリー：審査員が「クライアントが誤ったデータを送ったらどうする」と聞いたら → 「Pydantic が自動で拒否し、422 エラーを返す（HTTP ステータスコード = データ形式の誤り）」と答える

3.5 Alembic（データベースマイグレーション）

表構造を変えつつデータを失わないためのツール
高優先 難易度 ★★★★
Alembic = SQLAlchemy と対になるデータベースマイグレーションツール
マイグレーション (migration) = 表構造を変えるスクリプト（フィールド追加 / 削除 / 型変更）。バージョン番号がありロールバックできる
DMSD にはすでに 30+ 個の migration スクリプトがある
DMSD 03_dev/backend/alembic/versions/ ディレクトリ

3.6 nfcpy（点呼機用の NFC ライブラリ）

Python で NFC カードを読むライブラリ
中優先 難易度 ★★★
点呼機側はこのライブラリで、PN532 モジュール（NFC 読み書きモジュール）経由で NTAG215 カード（NFC カードの一種）と ST25DV16K（動的 NFC カード）を読む。
DMSD 03_dev/rollcall_device/src/ 配下

第 4 章 — Swift + SwiftUI（iOS 学生クライアント / AC デモの重点）

Swift の優先度は Python に次ぐ — iOS が itsuki が寮の管理者向けデモに使うクライアントだから（4-28 のデモは iPhone）。AC 面接で iPhone を持参してその場でデモするなら、Swift のコードを説明できなければならない。

4.1 Swift 文法の基礎

6 つの下位項目を展開
let / var / Optional / 型推論
必修 難易度 ★★
let = 定数（変更不可）/ var = 変数
Optional = オプショナル型 — Swift は「この値は空かもしれない」と「この値は必ずある」を区別し、 ? 空になりうることを表す。ゼロ基礎でつまずきやすい文法。
struct / class / enum
必修 難易度 ★★★
struct = 構造体（値型。代入はコピー）/ class = クラス（参照型。代入は同じ実体を指す）/ enum = 列挙（有限の取りうる値の集合）。SwiftUI では View のほぼすべてが struct。
func / クロージャ / 高階関数（map / filter / reduce）
高優先 難易度 ★★★
クロージャ (closure) = 匿名関数。他の関数に渡せる。Swift では至る所にある。
protocol / extension
高優先 難易度 ★★★★
protocol = プロトコル。「私を実装する型はこれらのメソッドを持たねばならない」を定義する / extension = 拡張。既存の型に新しいメソッドを足す。Swift の「プロトコル指向プログラミング」の核心。
async / await（非同期プログラミング）
高優先 難易度 ★★★★
ネットワーク要求は数百ミリ秒待つので、UI を塞いではいけない。async 関数は「私は非同期で動く」、await は「ここで結果を待つ」を表す。Swift 5.5+ の現代的な非同期構文。
Codable（JSON デコード）
必修 難易度 ★★★
Swift の構造体が、JSON を自動で struct のインスタンスに変換（デコード / decode）したり、その逆（エンコード / encode）したりできる。DMSD の iOS クライアントと backend の通信はすべてこれに依存する。

4.2 SwiftUI 宣言的 UI

SwiftUI = Apple の現代的な UI フレームワーク
必修 難易度 ★★★★
宣言的 (declarative) = 「UI がどう見えるか」を書くのであって、「どう一歩ずつ描くか」ではない
View プロトコル = すべての UI 要素が View プロトコルを実装する
合成 = 複雑な UI は単純な View を組み合わせて作る
従来の命令的な UIKit とは発想が別
DMSD 03_dev/student_ios/ 配下のすべての .swift ファイル / Foundation/ 配下は基礎 component

4.3 状態管理（@State / @Binding / @ObservedObject / @StateObject / @EnvironmentObject）

SwiftUI の 5 つのデータフロー注釈
必修 難易度 ★★★★★
@State = ローカル状態（この View の内部で使う）
@Binding = 子 View が親 View の状態への参照を受け取る
@ObservedObject = 外部オブジェクトの変化を監視する
@StateObject = 自分で外部オブジェクトを生成して保持する
@EnvironmentObject = グローバル共有オブジェクト（階層ごとに渡さなくてよい）
DMSD の iOS クライアントには至る所にある。ゼロ基礎でいちばんつまずきやすい点 — 誤用すると状態が更新されない、あるいは無限ループになる。

4.4 ナビゲーション（NavigationStack / Sheet / Alert）

画面間の遷移
必修 難易度 ★★★
DMSD 03_dev/student_ios/Route.swift + RootView.swift がナビゲーションの中枢

4.5 Core NFC（iOS システムの NFC フレームワーク）

iPhone で NFC カードを読む / URL を発火する
高優先 難易度 ★★★★
Core NFC = iOS システム層が提供する NFC 操作インタフェース
BTR = Background Tag Reading バックグラウンドタグ読み取り（App を開かず、NFC に近づけるだけで 発火する）
Universal Link = ユニバーサルリンク（特定の URL を Safari ではなく App に直接飛ばす）
AASA = Apple App Site Association（Universal Link の設定ファイル）
DMSD の iOS クライアントにおける点呼関連コード
AC ストーリー：審査員が「学生はどうサインインするのか」と聞いたら → 「NFC カードに触れる → BTR が Universal Link を発火 → App に飛んで自動サインイン → バックエンドが記録」という全リンクを説明できる

4.6 URLSession（ネットワーク要求）

iOS が HTTP 要求を送るためのシステムライブラリ
必修 難易度 ★★★
DMSD 03_dev/student_ios/Endpoints/ 配下の各 *API.swift ファイル

第 5 章 — Kotlin + Compose（Android 学生クライアント）

Kotlin は Swift と概念が高度に似ている（どちらも現代的な静的言語 + 宣言的 UI）。Swift を 学んでから Kotlin を学ぶと時間を半減できる。Android クライアントの学習優先度は 3 番目。

5.1 Kotlin と Swift の対応関係

Swift Kotlin 説明
let / var val / var 定数 / 変数
Optional (?) Nullable (?) オプショナル型
struct data class データクラス
protocol interface プロトコル / インタフェース
extension extension function 既存の型にメソッドを足す
async / await suspend / coroutine 非同期プログラミング
Codable kotlinx.serialization JSON デコード

5.2 Jetpack Compose（Android の宣言的 UI）

SwiftUI の Android 版に相当するもの
必修 難易度 ★★★★
Compose 関数 (@Composable) = SwiftUI の View
remember / mutableStateOf = SwiftUI の @State
ViewModel + StateFlow = SwiftUI の @StateObject + ObservableObject
DMSD 03_dev/student_android/ 配下の 10+ 画面分の Compose コード

5.3 Ktor / Retrofit（Android ネットワークライブラリ）

Android で HTTP 要求を送る
高優先 難易度 ★★★
iOS は URLSession のシステムライブラリを使う。Android は通常サードパーティの Ktor か Retrofit（DMSD がどちらを使うかは 03_dev/student_android/ build.gradle）

5.4 Android NFC API

Android で NFC を読む
中優先 難易度 ★★★★
Android の NFC 対応は iOS より早く、より開放的（AASA の設定が不要）。ただし Intent（Android のアプリ間メッセージ機構）を処理する必要がある。

第 6 章 — TypeScript + Vue（教員 Web クライアント）

教員 Web クライアントの利用頻度はいちばん低い — 学校の教員用パソコンで動かし、学生のスマホクライアントほど個人向けではない。優先度は 4 番目。ただし AC 面接で「なぜ全部 App にしないのか」と聞かれたら説明できなければならない。

6.1 TypeScript の基礎

TypeScript = JavaScript + 型システム
高優先 難易度 ★★★
JavaScript = ブラウザで動くスクリプト言語（動的な弱型付け。書き間違いは実行時まで分からない）
TypeScript = JS に型チェックを足したもの — コードを書いている時点でエディタがエラーを出す — 大規模プロジェクトではほぼ TS を使う
interface / type alias = データ形状を定義する
ジェネリクス (generics) = パラメータ化された型

6.2 Vue 3 Composition API

Vue = フロントエンドフレームワーク
高優先 難易度 ★★★★
Vue = Web フロントエンドフレームワーク（React / Angular と並ぶ三大のひとつ）
Composition API = Vue 3 の新しい書き方（React Hooks に似た発想）
ref / reactive = リアクティブなデータ
computed / watch = 算出プロパティ / 監視
Single File Component = .vue ファイル内で template（テンプレート）+ script（ロジック）+ style（スタイル）を同時に書く
DMSD 03_dev/teacher_web/src/ 配下 .vue ファイル

6.3 Vite（フロントエンドのバンドルツール）

Vite = 現代的なフロントエンド開発サーバー
中優先 難易度 ★★
Vite = フランス語の「速い」/ フロントエンドプロジェクトのローカル開発 + バンドルツール
Hot Module Replacement (HMR) = コードを変えてもページを再読み込みせず、ブラウザが自動更新する
古い Webpack と比べて起動が 10 倍速い

6.4 Pinia（Vue の状態管理）

コンポーネント横断でデータを共有する
中優先 難易度 ★★★
Pinia = Vue 公式推奨の状態管理ライブラリ（古い Vuex の後継）。複数コンポーネントでデータを共有するとき、props（属性）を階層ごとに渡さず Pinia store に置く。

第 7 章 — ハードウェア + 組み込み（点呼機クライアント）

ハードウェア層は、DMSD が純粋な App プロジェクトと違う「実物の作品」の証拠 — AC 面接の審査員が itsuki 自身が組み立てた Pi + NFC モジュールを見ると、極めて強い加点になる。この章で学ぶのはコードを書くことではなく、ハードウェアの原理を理解し、 各部品をなぜ選んだか説明できること。

7.1 NFC の物理原理

電磁誘導でどうデータを伝えるか
必修 難易度 ★★★
NFC = Near Field Communication 近距離無線通信 — 動作距離は 4cm 以内
原理 = 13.56 MHz の電磁場による誘導（高校物理のファラデーの電磁誘導の法則の応用）
パッシブカード (passive tag) = 自身は無電源で、リーダーの磁界で活性化される — NTAG215 がパッシブカード
動的カード (dynamic tag) = マイクロコントローラを持ち内容を書き換えられる — ST25DV16K が動的カード
02_design/hardware_design.md + 05_logs/learning_path.md 2026-04-12 の項目はすでに書いた
AC ストーリー：審査員が「なぜ 4cm の制限が利点なのか」と聞いたら → 「電磁場の強さは距離の 3 乗で減衰する → 遠いとそもそも結合できない → 物理的に近づく必要がある → 不正防止」と答える

7.2 NFC カード型番の比較（NTAG215 / ST25DV16K）

なぜ DMSD が ST25DV16K を選んだか
高優先 難易度 ★★
NTAG215 = NXP 社のパッシブカード — 内容は固定で、安い（約 5 元 / 枚）
ST25DV16K = STMicroelectronics 社の動的カード — マイクロコントローラが内容をリアルタイムで書き換えられる（DMSD は 10 秒ごとに nonce を更新）— 高い（約 25 元 / 枚）
ST25DV16K を選ぶ理由 = URL 複製攻撃の防止（NTAG215 は内容が固定なので、攻撃者が内容をコピーして別の場所に貼ってもサインインできてしまう）
02_design/hardware_design.md §カード選定の意思決定

7.3 PN532 モジュール

点呼機用の NFC リーダーモジュール
高優先 難易度 ★★★
PN532 = NXP 社の NFC 送受信チップ
Pi との接続インタフェース = I2C / SPI / UART の 3 種（DMSD は V3 版を採用 — 配線の仕方はハードウェア設計を参照）
nfcpy ライブラリと組み合わせて Python からカードを読む
02_design/hardware_design.md + 03_dev/rollcall_device/

7.4 Raspberry Pi の GPIO + 周辺機器

Raspberry Pi 3A+ と周辺機器の配線
高優先 難易度 ★★★
Raspberry Pi (ラズベリーパイ) = クレジットカード大の小型コンピュータ。Linux が動く（DMSD は 3A+ 型番を使用）
GPIO = General Purpose Input / Output 汎用入出力ピン — Pi 上の 40 本のピンに LED / スピーカー / モジュールを接続できる
DMSD 点呼機の周辺機器 = PN532 NFC モジュール + LED ランプ（サインイン成功で緑表示）+ スピーカー（日本語で「○○ さん おかえりなさい」とアナウンス）
02_design/hardware_design.md §配線 GPIO + モジュール選定

7.5 不正防止メカニズム（nonce + ECDSA）

3 層の防御
必修 難易度 ★★★★★
第 1 層 (物理) = NFC の 4cm 距離制限。遠隔からは攻撃できない
第 2 層 (動的) = ST25DV16K が 10 秒ごとに nonce を更新 — 一度 URL を 録画して再送しても期限切れ
第 3 層 (署名) = ECDSA 楕円曲線署名 — サーバーが「この nonce は自分が発行したものだ」と検証する。攻撃者は偽造できない
02_design/system_features.md §不正防止設計 + 03_dev/backend/services/ 配下の署名検証コード
AC ストーリー：審査員が「なぜ 3 層であって 1 層ではないのか」と聞いたら → 「単層はいずれも迂回されうる（物理の近距離でも強磁界で増幅できる / nonce がハードウェア上で破られる / 署名鍵が漏洩する）→ 3 層を重ねればどれか 1 層が持ちこたえても安全」= 防御深度の思考 = 極めて強い加点
🆕 2026-05-28 拡張：点呼機の深い知識パック（7.6 - 7.16）
以下、「全体構成 → 部品リスト → 動作原理 → 各部品の深掘り → 抽象概念 → 失敗モード」の 6 層で、点呼機を AC 口述に耐える粒度まで説明する。この段は、面接の審査員が「自分で組み立てたこの箱の中身はいったい何か」と聞いたときの弾薬庫。

7.6 全体構成と設計原則

点呼機 = 小型コンピュータ 1 台 + いくつかのモジュールが入った箱
必修 難易度 ★★
点呼機は Tomoshibi システム 5クライアントのうちの一端。寮のフロア廊下に 4 台配備し、 やること一つ：学生が寮に戻るときのサインインを受け、サインインデータをバックエンドへ送る。

中核の設計原則 — thin client / thick server（シンクライアント / シックサーバー）：
  • 点呼機が担うのはデータの搬送（カード読み取り、ネットワーク要求の送信、音と光のフィードバック）
  • すべての業務判断（定時かどうか / 欠席かどうか / 減点は何点か）はすべてバックエンドサーバーにあり、 サーバー時刻 server_now（JST 日本標準時）を基準にする
  • 点呼機自体は「正誤を判断する」ロジックを一切持たない
物理構成（部品 6 点 + マザーボード）： 
Raspberry Pi 3 Model A+（マザーボード / 頭脳）
 ├─ PN532 リーダーモジュール   → 学生の NFC カードを読む（経路 A）
 ├─ ST25DV16K ステッカーモジュール → スマホで触れる動的ステッカー（経路 B）
 ├─ LED 状態ランプ（4 色）  → 青＝待機 / 緑＝成功 / 赤＝失敗 / 白＝起動
 ├─ USB 小型スピーカー         → 学生氏名を日本語でアナウンス
 ├─ 冷却ファン           → 24×7 稼働の放熱
 └─ micro-USB 電源     → 壁コンセントから給電
02_design/hardware_design.md（ハードウェア選定の単一の真の情報源）+ 03_dev/rollcall_device/ROLLCALL_DEVICE_DESIGN_LOG.md
AC ストーリー：審査員が「この箱は何か」と聞いたら → 「Raspberry Pi の小型コンピュータ + 周辺モジュール 5 個。データを運ぶだけで判断はしない — 業務ロジックはすべてサーバー側。ハード側はできるだけ単純にする = 故障率が低く、保守しやすく、1 台が壊れても全体に影響しない」= シンクライアントアーキテクチャ思想の実践。

7.7 完全な部品リスト（11 項目 + 単価 + 調達先）

プラン A 初回注文 1 台のデモ機 — 日本国内で調達
高優先 難易度 ★
初回注文の合計は約 19,800 円。4 台配備すると合計約 56,600 円。
#部品型番 / 仕様単価 (¥)調達先インタフェース
1マザーボード Raspberry Pi 3 Model A+（512MB / デュアルバンド WiFi / 1× USB / 40-pin GPIO / 3.5mm オーディオ） 5,580秋月電子 (114878)—
2電源 micro-USB 5V 3A AD-K50P300 1,100秋月電子 (112001)micro-USB
3リーダー PN532 V3 赤ボード（3.3V/5V 自動適応 / SPI/I²C/UART） 約 1,100Amazon JP（Hailege キット）SPI（推奨）
4動的ステッカー ST25DV16K（Adafruit 4701 / STEMMA QT / 16 Kbit）× 5（配備 4 + 予備 1） 968 × 5 = 4,840Switch Science (7903)I²C
5学生カード NTAG215 白紙ブランクカード 10 枚入り（86×54mm） 約 1,500Amazon JP—
6状態ランプ 5mm LED 赤/緑/青/白 各1 + 220Ω 抵抗 × 4 約100秋月電子（緑 OSPG5111A / 112117）デジタル GPIO
7放熱 5V 30×30×7mm 静音ファン ⚠️ 必ず5V（12Vではない） 約800Amazon JP5V 電源ピン
8スピーカー USB給電 + 3.5mm 音声入力の小型スピーカー ⚠️ USB DAC 型は買わない 約1,300Amazon JPUSB + 3.5mm
9ブレッドボード 170穴ミニブレッドボード（BB-601 / SJB-17WH） 150 ~ 439秋月電子 / Sunhayato—
10配線 ジャンパー線 40P メス-メス 約250秋月電子 (g115868)—
11変換ケーブル ⚠️ STEMMA QT → デュポンオス変換ケーブル（ST25DV 必須） 約200Amazon / Switch Science—
見送ったもの：筐体（当面購入しない）/ microSD カード（既に所持）
本番展開時のアップグレード項目：学生証 NTAG215 → NTAG424 DNA（クローン防止、約200-400円/枚 × 100枚以上）
02_design/hardware_design.md §部品リスト（単一の情報源）

7.8 2つの出席登録パス（動作原理）

パス A — NFC カードをかざす（スマホなし / 主力方式）
必学 難易度 ★★★ 
学生が NTAG215 カードを点呼機の PN532 リーダーにかざす
 → PN532 がカードの UID（7バイトの一意番号）を読み取る
 → 点呼機が WiFi 経由で HTTP POST：UID + 点呼機番号 → バックエンド
 → バックエンドが UID に紐づく学生アカウントを照会し、定時かどうかを判定
 → バックエンドが WebSocket メッセージを教員端へ送り、座席がリアルタイムで緑に変わる
 → バックエンドが点呼機へ応答：成功 → 緑ランプ + スピーカーで「○○ さん、お帰りなさい」を再生
パス B — スマホでタッチ（動的ステッカーで代理出席防止）
必学 難易度 ★★★★
点呼機の Python プログラム10秒ごと（点呼時間窓の中だけ）： 
バックエンドに新しい nonce（10秒有効のワンタイム乱数）を要求
 → NDEF URL を組み立て：https://.../checkin?device=DEV001&nonce=XXX
 → I²C 経由で URL を ST25DV16K の EEPROM に書き込む

学生のスマホ（iPhone/Android）がステッカーにタッチ
 → スマホの NFC がステッカー内の URL を読み取る
 → Universal Link が発火して学生 App が開く
 → App が出席登録 API を呼ぶ（nonce 付き）
 → バックエンドが nonce が10秒の有効期内かを検証 → 出席登録完了
パス B の代理出席防止の仕組み：ステッカー内の URL は10秒ごとに変わる。 学生が URL をコピーして同級生に送り代理出席させようとしても → 10秒後にはその URL は無効になる。
AC ストーリー：審査員が「なぜ静的 NFC ステッカーを使わないのか」と問う → 「静的ステッカーは URL が変わらないので、学生が一通コピーしてグループに送れば遠隔で代理出席できてしまう → ST25DV16K の動的ステッカーは10秒ごとに URL が変わる → コピーしても意味がない」＝ 攻撃者の視点から防御を設計する＝セキュリティエンジニアリングの思考。
点呼機本体の6つの責務
高優先 難易度 ★★
  1. PN532 上の NFC カード UID を読む（パス A）
  2. I²C 経由で ST25DV16K の NDEF URL を書く（パス B の nonce 更新）
  3. 出席データを HTTP POST でバックエンドへ送る
  4. WebSocket でバックエンドの放送指示を購読する
  5. 日本語音声を再生する（pyttsx3 / OpenJTalk → 3.5mm スピーカー）
  6. LED 状態ランプを点灯する
注意：6項目のうち「学生が定時かどうかの判定」は一つもない — それはバックエンドの仕事。

7.9 Raspberry Pi 3 Model A+（マザーボード深掘り）

なぜ 3A+ を選び、4B / Zero / ESP32 を選ばないか
高優先 難易度 ★★★
仕様：4コア 1.4GHz CPU / 512MB メモリ（余裕は少ないが足りる）/ デュアルバンド WiFi / 1× USB 2.0 / 40ピン GPIO / 3.5mm アナログ音声端子 / micro-USB 給電。

機種選定の比較：
  • vs Pi 4B：4B は性能過剰（点呼機はシンクライアントなので不要）； 3A+ は「最も安く 3.5mm 音声端子付き」の公式 Pi
  • vs Pi Zero：Zero は 3.5mm 音声端子がない → スピーカーを直接つなげない
  • vs ESP32：完全な Python + ローカル日本語音声合成を動かせない
512MB メモリの余裕分析：
システム ~100MB + Python プログラム ~50MB + 音声エンジン ~30MB + ドライバ ~50MB + キャッシュ ~100MB ≈ 330MB、残り約180MB。
最適化の手段：swap を切って zram（メモリ圧縮）へ / GPU メモリを 16-32MB に設定 / 本機で VOICEVOX を動かさない（2GB 必要）。

headless 展開：キーボード・マウス・ディスプレイを差さず、全程 SSH で遠隔ログインしてデバッグ （USB 口がスピーカーに占有されるため、キーボード・マウス用ハブを差せない）。
AC ストーリー：審査員が「なぜこの Pi を選んだのか」と問う → 「3A+ は最も安く、かつ 3.5mm アナログ音声端子付きの公式 Pi — シンクライアントに 4B の性能は不要、Zero は音声端子なし、ESP32 は Python + ローカル日本語 TTS を動かせない。要件から逆算して選定したのであって、高いほど良いわけではない」。

7.10 PN532 リーダー（深掘り）

なぜ SPI を選び I²C を使わないか / なぜ RC522 を選ばないか
高優先 難易度 ★★★★
PN532 = NXP 社製の NFC リーダー界の事実上の標準チップ。 13.56MHz / ISO 14443A 規格のカードを読む（NTAG215 学生証はこの類）。 V3 赤基板は SPI / I²C / UART の3種インターフェースに対応し、基板上のジャンパで切替。

インターフェースに SPI（推奨）を選ぶ4つの理由：
  1. I²C バスの衝突：ST25DV がすでに I²C バスを占有しており、PN532 も I²C にすると バスロックしやすい → ロックすると機体の NFC がすべて止まり再起動しかない
  2. 落とし穴が多い：PN532 の I²C 接続は Pi 上で歴史的な問題が多い
  3. 主流ライブラリの対応：SPI モードは主流の Python ライブラリ対応がより充実
  4. チュートリアルが豊富：初心者向けチュートリアルはほぼ SPI 接続を解説している
SPI 配線：MOSI / MISO / SCK / SS（CE0）/ GND / VCC = 6本、 リセット線を1本追加するのが望ましい。

RC522 を選ばない理由：RC522 は NFC タグ書き込み / P2P に非対応、 本プロジェクト（動的 nonce を ST25DV に書く必要がある）と互換しない。
AC ストーリー：審査員が「PN532 の3種インターフェースでなぜ SPI か」と問う → 「I²C バスはすでに ST25DV が使っており、2つの NFC チップが同じ I²C だとロックしやすい、 ロックすると機体ごと再起動が必要 → 2つの NFC サブシステムを物理的に別バスへ隔離する＝故障隔離」＝ システム設計の耐障害性の考え方。

7.11 ST25DV16K 動的ステッカー（深掘り）

デュアルインターフェース EEPROM + 寿命アルゴリズム + Mailbox モード
必学 難易度 ★★★★★
ST25DV16K = 一種の「デュアルインターフェース EEPROM」： 一方ではスマホが NFC ステッカーとして読める（ISO 15693 / NFC Type 5）、 他方では点呼機が I²C 経由で書ける。16 Kbit = 2KB 容量（NDEF URL は約80バイトで余裕十分）。

EEPROM の書き換え寿命（重要パラメータ）：
  • 公式 25°C で約100万回
  • 85°C で約60万回
  • データ保持約40年
寿命アルゴリズム（重要）— 寿命は「1日に何回書くか」で決まる：
戦略1日の書き込み回数摩耗までの期間
❌ 7×24 終日10秒ごとに更新 8,640回 100万 ÷ 8,640 = 116日で摩耗
✅ 点呼時間窓の中だけ更新 120 ~ 360回 7 ~ 22年
結論：nonce の更新は必ず点呼時間窓の中に限定し、終日回してはいけない。

なぜ静的 NTAG215 をステッカーにしないか： 静的ステッカーは URL が変わらない → 学生がコピーすれば永久に有効 → 代理出席の抜け穴。 ST25DV は URL を動的に変えられるので代理出席を防げる。

Mailbox / Fast Transfer Mode：ST25DV には256バイトのメモリバッファがあり、 メモリ経由なら EEPROM に書かず寿命をほぼ消費しない。ただし「ホスト ↔ スマホ App のリアルタイム双方向ハンドシェイク」向きで、 「スマホが受動的に NDEF を読む」用途には向かない（スマホが読むのは EEPROM であり Mailbox ではない）→ DMSD のパス B は NDEF モードを使い Mailbox は使わない。

STEMMA QT / Qwiic インターフェース：4ピン JST-SH のプラグアンドプレイ端子、 ジャンパー線は差し込めず、専用変換ケーブルが必要（部品リスト #11）。
AC ストーリー：審査員が「ステッカーは書き込んで壊れないのか」と問う → 「10秒ごとに更新すれば確かに壊れる。終日回すと116日で寿命切れ → だからコードでは nonce 更新を点呼時間窓の中だけ起動する → 実際の書き込み回数は 8,640回/日から 120-360回/日へ減り → 寿命は116日から7-22年へ延びる」＝ ハードウェアの物理制約を理解してソフト制御に落とし込む＝組み込みエンジニアリングの思考。

7.12 NTAG215 学生証 → NTAG424 DNA アップグレード経路

UID クローン脆弱性 + AES-128 + SUN 機構
高優先 難易度 ★★★★
NTAG215：NXP 製の NFC カード、CR80 規格（85.6×54mm、銀行カードサイズ）。 7バイト UID / 540バイト EEPROM（本プロジェクトでは UID のみ使用し、データは書かない）。

致命的な限界：UID だけを読む方式では、UID は
  • Flipper Zero（携帯型ハッカー向け NFC ツール）でクローン可能
  • Android HCE（スマホのカードエミュレーション機能 Host Card Emulation）でクローン可能
アップグレード案 NTAG424 DNA：
  • 内蔵 AES-128 暗号エンジン
  • SUN（Secure Unique NFC）動的署名 — カードをかざすたびに異なる暗号文を出力
  • UID を物理クローンしても署名検証を通らない
注意：容量の大小はクローン防止と無関係で、重要なのはチップのハードウェア暗号能力。

学生証のライフサイクル： 入学時のカード発行 + App で UID 紐づけ → 日常の出席登録 → 紛失時は再発行して旧 UID を無効化 → 卒業時に紐づけ解除し次期生へ再利用。
AC ストーリー：審査員が「NTAG215 はクローンできるのでは」と問う → 「はい。これは意図したコストのトレードオフです。デモ段階ではまず NTAG215（5元/枚）で流れを通し、 本番展開で NTAG424 DNA（200-400円/枚）へ上げる — 内蔵 AES-128 + SUN 動的署名により、かざすたびに暗号文が変わり、UID を物理クローンしても検証を通らない」＝ 段階的な技術判断力 + より高度な方案の存在を知っていること。

7.13 LED / ファン / スピーカー / 配線（周辺機器の落とし穴総集）

LED 状態ランプ — デジタル GPIO、PWM は使わない
中優先 難易度 ★★
5mm LED 4個：青＝待機 / 緑＝出席登録成功 / 赤＝失敗 / 白＝システム起動中。
デジタル GPIO に接続（赤17 / 緑27 / 青22 / 白23、BCM 番号）、共通グランド。
各1個に 220Ω の電流制限抵抗を直列（過電流で LED が焼けるのを防ぐ）。
PWM（パルス幅変調で明るさ調整）は使わず、単純なデジタルスイッチで十分。
放熱ファン — 必ず5V + 電源ピンに接続し GPIO 信号ピンにはつながない ⚠️
必学 難易度 ★★★
30×30×7mm ファン、必ず 5V（12Vではない — 12V ファンを Pi の5Vピンにつけても回らない）。

接続の要点：
  • ✅ 接続先は 5V 電源ピン（物理2番または4番ピン）+ グランドピン
  • ❌ GPIO 信号ピンにはつなげない（信号ピン最大16 mA、ファンは100 mA必要で Pi を焼損する）
24×7 稼働の Pi はプラスチック筐体内で NFC を読み続けて発熱するので、ファンは安価な保険。
マザーボード焼損の典型的な初心者の落とし穴：「GPIO ピンは見た目が同じだから適当に挿す」→ 信号ピンの電流上限は16 mA、ファン起動瞬間の100+ mA で GPIO 駆動回路が即焼損 → Pi 全体が廃品になる。これは必ず覚えること。
USB 小型スピーカー + 日本語音声合成の方案比較
高優先 難易度 ★★★
スピーカー選定：USB給電 + 3.5mm 音声入力 （買ってはいけないのは USB データ伝送型 / USB DAC。Pi 唯一の USB 口を占有する）。

Pi 3A+ のデフォルト音声は HDMIなので、 raspi-config コマンドで「アナログ音声」に切り替え、3.5mm 端子へ出す。

日本語音声合成 3方案の比較：
方案説明評価
A 推奨 事前生成した音声ファイルのキャッシュ — 開発用PC上で OpenJTalk を使い 各学生の名前をあらかじめ .wav 化し Pi に保存、実行時はそのまま再生 ✅ 最安定 + 音質最良 + 省リソース
B Pi 上に OpenJTalk を入れリアルタイム合成 音質は良いが、毎回1-2秒の遅延
C 非推奨 pyttsx3 + espeak / VOICEVOX espeak は日本語人名の発音が機械的（最も弱い場面）/ VOICEVOX は2GB メモリが必要で動かない
AC ストーリー：審査員が「日本語のアナウンスはどう実装したか」と問う → 「3方案とも試し、最終的に事前生成キャッシュを選んだ — 学生名は固定名簿なので学期初めに一括生成し、 実行時は .wav を再生するだけで合成しない → CPU 負荷が低く、遅延ゼロ、音質も良い。 リアルタイム合成は予測不能な入力向けで、この場面には不要」＝ 工学的トレードオフを理解し「データ特性に合わせて方案を選ぶ」。
配線の落とし穴 — BCM 番号 vs 物理ピン番号
高優先 難易度 ★★
開発期：ブレッドボード + ジャンパー線、はんだ付けなし（いつでも付け替えられ、失敗しても基板を廃品にしない）。
展開期：万能基板（perfboard）へのはんだ付けを推奨。廊下の振動で配線が緩むのを防ぐ。

GPIO 番号の落とし穴（100% 踏む）：
  • BCM 番号：コードで使う（例： GPIO.setmode(GPIO.BCM)）
  • 物理ピン番号：基板に印刷されている、1から数える番号
  • 2系統の番号はまったく違い、初回配線では100% 混同する → LED が点かない / モジュールが認識されない
切り分け方：まず gpio readall で物理 ↔ BCM 対照表を見る。

7.14 重要技術概念の用語集（20語）

以下の20語は hardware_design.md / ROLLCALL_DEVICE_DESIGN_LOG.md / flow_design.md に登場し、 AC 面接でどれを聞かれてもおかしくない。各語を一文で説明できるようにしておく。
概念説明
NFC近距離無線通信。13.56MHz の短距離（2-5cm）無線技術
ISO 14443ANFC 規格の一つ。NTAG215 学生証がこれ、PN532 もこれを読む
ISO 15693 / NFC Type 5もう一つの NFC 規格。ST25DV ステッカーがこれ。 PN532 はこれを読めない（だから2チップが互いに誤読しない）
UIDカードの一意番号。7バイト、工場出荷時に固定
NDEFNFC データ交換フォーマット。ステッカーに URL を格納する標準形式
I²C2本線（データ SDA + クロック SCL）の低速通信バス。ST25DV が接続
SPI4本線の高速通信バス。PN532 の推奨接続
UARTシリアル通信。PN532 の第3の選択肢インターフェース
GPIO汎用入出力ピン。Pi 上は40ピン。LED / モジュールを接続
EEPROM繰り返し書き換え可能な記憶チップ。書き換え回数に寿命上限あり
nonceワンタイム乱数。10秒有効。URL コピーによる代理出席を防ぐ
Universal LinkiOS/Android のディープリンク。URL を開くと直接 App が起動
WebSocket長寿命接続プロトコル。バックエンドが点呼機 / 教員端へリアルタイムでメッセージを送る
HTTP POST点呼機が出席データをバックエンドへ送るネットワーク要求の方式
thin clientシンクライアント。データを運ぶだけで判定はしない
headlessディスプレイ/キーボード・マウスなし。SSH で遠隔操作
SSH別のコンピュータのコマンドラインへ遠隔ログインするツール
AES-128128ビット高度暗号化標準。NTAG424 DNA のクローン防止に使用
SUNSecure Unique NFC。NTAG424 DNA が毎回異なる暗号文を出す仕組み
PWMパルス幅変調。LED の明るさ / ファン回転数の調整に使う（本プロジェクトの LED では未使用）

7.15 24×7 展開でよくある失敗モード（発生確率順）

6種の失敗モード + 対応する防御
必学 難易度 ★★★★
#失敗モード原因防御
1 ブレッドボードのジャンパー線が緩む 廊下の振動 + 温度変化 展開期にはんだ付けして万能基板へ移す
2 SD カード破損 ログの頻繁な書き込み + 停電 高耐久カードを使う（Sandisk Max Endurance）
3 学校 WiFi の認証ポータル / WebSocket がプロキシで遮断される キャンパスネットによくある制限 ローカル出席キューのバッファ + 自動再接続
4 供給電圧の不安定 廊下コンセントの共用回路で電圧不足になり Pi がクロックダウン 5V 3A 安定化電源 + throttled ステータスビットの監視
5 ファンのホコリ堆積 / 故障 防塵ネットなし + 長期稼働 定期点検 + 予備部品
6 ST25DV EEPROM の摩耗 誤って終日 nonce を更新している 点呼時間窓の中だけ更新する（7.11 参照）
AC ストーリー：審査員が「24×7 稼働の安定をどう保証するか」と問う → 「最も起きやすい故障モードを6種挙げ、それぞれに防御を用意した — ハードウェア（はんだ付け、安定化電源）からソフトウェア（ローカルキューのバッファ）、運用（定期点検）まで。 重要なのはハードウェアは必ず壊れると認め、壊れたときにシステムが崩れないこと」＝ 信頼性エンジニアリングの思想（Reliability Engineering）。

7.16 学習材料の起点（ドキュメントの位置づけ）

3つのドキュメントを読めば点呼機がわかる
必学 難易度 ★
  1. 02_design/hardware_design.md — ハードウェア選定 + 部品リスト単一の情報源
  2. 03_dev/rollcall_device/ROLLCALL_DEVICE_DESIGN_LOG.md — 点呼機のソフトウェアレヤ
  3. 02_design/flow_design.md — 出席登録フローのエンドツーエンド
3ドキュメントの読む順：ハードウェア設計 → ソフトウェア設計 → エンドツーエンドの流れ。どれかがコードと食い違うときは、 ハードウェア設計ドキュメントを正とする（単一の情報源の原則）。

第8章 — AC 入試に直接関係する知識

この章は技術ではなく、AC 面接で審査員が聞きうる + itsuki が答えられなければならない「なぜ筑波を選ぶか / なぜ情報科学類を選ぶか」類の問いへの背景知識。

8.1 情報科学類の3つの分野

ソフトウェア科学 / 情報システム / 知能情報メディア
必学 難易度 ★★
ソフトウェア科学 (ソフトウェアサイエンス) = ソフトウェアそのものの理論 + 設計
情報システム (情報システム) = 情報社会を支えるインフラ
知能情報メディア (知能情報メディア) = コンピュータに「眼・智・安全」を与える
読む 02_分析与调研/AC入試制度総覧_2027.html §1.2 + 大学案内 2027 P80
AC ストーリー：審査員が「入学後にどの分野を学びたいか」と問う → DMSD プロジェクトはこの3 分野にまたがる（ソフトウェア設計 + バックエンドアーキテクチャ + NFC セキュリティ）。主な方向を1つ選び、理由を説明できるようにする

8.2 CTF（情報セキュリティ競技）

Capture The Flag 旗取り競技
高優先 難易度 ★★★★
CTF = 情報セキュリティ分野の競技形式 — システムの脆弱性を探す / 暗号を破る / リバースエンジニアリング
SECCON = 日本最大級の CTF の一つ
情報科学類の学生が 2026-03 に SECCON CTF 14 学生チームで優勝 — これは coins 公式サイト最新の対外アピール実績
AC ストーリー：審査員が「入学後に何をしたいか」と問う → 「DMSD ですでに不正防止設計をした → CTF の攻防をさらに学びたい → 筑波の SECCON 実績と接続する」＝ 筑波の募集方向との高い一致

8.3 SecHack365（日本総務省の人材育成プロジェクト）

若手情報セキュリティ人材プロジェクト
中優先 難易度 ★★
SecHack365 = 日本総務省主催の25歳以下向け若手情報セキュリティ人材育成プロジェクト（1 年制）。情報科学類の学生が 2026-03 に優秀修了認定を受けた。
AC ストーリー：「入学後に SecHack365 へ応募したい」と述べられる — 審査員に itsuki が筑波のリソースを知っていることを見せる

8.4 大学案内 P80 人材養成の目的

情報科学類が育てたい人材像
必学 難易度 ★
原文：「問題を定義でき + 情報技術で創造的に解決でき + 自分なぜそうするかを説明できる」人材。これが AC 入試の3つの評価点（関心 / 能力 / 表現）の源流。
読む 02_分析与调研/AC入試制度総覧_2027.html §1.2

第 9 章 — プロジェクト内部の動作ロジック（ソースコードから動くものになるまで）🆕

itsuki の言葉：「自分のプロジェクトがどう動いているか理解したい」。この章は「コードを一行書いてから、ユーザーのスマホで動くまでの全経路」。AC の面接官に「あなたの iPhone はどうやってデータをバックエンドに送るのか」と聞かれたら、アプリケーション層から物理層まで一気通貫で答えられること。

9.1 オペレーティングシステムの基礎

9.1.1 プロセス / スレッド / コルーチン（process / thread / coroutine — OS がプログラムを動かす 3 つの粒度）
高優先 難易度 ★★★
プロセス = OS がプログラムに割り当てる独立したメモリ空間（互いに隔離）/ スレッド = プロセス内で並行に動ける実行の流れ（メモリを共有）/ コルーチン = プログラム自身が切り替える軽量スレッド（OS による切り替え不要）
DMSD では：FastAPI（バックエンドフレームワーク）はリクエストごとに 1 コルーチン / iOS Swift async-await（非同期構文）の下層はコルーチン
ACストーリー：面接官が「学生 100 人が同時に点呼しても固まらないのはなぜ」→ 答え「コルーチンなら 1 スレッドで何千リクエストも処理でき、リクエストごとにプロセスを起動しなくてよい」
9.1.2 メモリ管理（memory management — プログラムがメモリをどう使うか）
中優先 難易度 ★★★
スタック（stack：局所変数を自動割当、関数から戻ると回収）/ ヒープ（heap：複雑なオブジェクトを手動割当）/ ARC（Automatic Reference Counting：自動参照カウント。コンパイル時に解放点を決める）/ GC（Garbage Collection：ガベージコレクション。実行時に定期スキャン）
DMSD では：Swift は ARC / Kotlin + Python は GC
ACストーリー：面接官が「なぜ Swift は GC を使わないのか」→ 答え「ARC はコンパイル時に解放点を決めるので予測しやすく、モバイルでは GC 一時停止によるカクつきを避けられる」
9.1.3 ファイルシステム（filesystem — ファイルがディスク上でどう置かれるか）
中優先 難易度 ★★
inode（ファイルのメタ情報：サイズ / タイムスタンプ / パーミッションビット）/ ディレクトリツリー（木構造）/ パーミッションビット rwx（read 読 / write 書 / execute 実行）
DMSD では：Mac では APFS（Apple File System アップルのファイルシステム）/ Raspberry Pi では ext4（Linux のファイルシステム）

9.2 ネットワークの基盤層（iPhone → バックエンドの物理経路）

9.2.1 TCP/IP 4 層モデル（インターネット通信の階層標準）
必須 難易度 ★★★
リンク層（Wi-Fi / 有線 — 物理伝送）/ ネットワーク層（IP アドレス + ルーティング — どのマシンへ送るかを決める）/ トランスポート層（TCP は信頼性が高く順序を保証 / UDP は信頼性は低いが速い）/ アプリケーション層（HTTP / WebSocket / DNS など）
DMSD では：あなたの HTTP リクエストは実際「HTTP が TCP に包まれ、TCP が IP に包まれ、IP が Wi-Fi フレームに包まれる」と層ごとに包まれて送られる
ACストーリー：面接官が「回線が切れたらどうする」→ TCP の再送機構からアプリケーション層のリトライ戦略まで語れること
9.2.2 DNS（Domain Name System ドメイン名解決システム）
高優先 難易度 ★★
〜を dmsd.example.jp のようなドメイン名を IP アドレスに変える。パソコンはまず DNS サーバーに「この名前はどの IP か」と聞いてから接続する。
DMSD では：iPhone がバックエンドサーバーを見つける手順 — まず DNS 照会で backend の IP を得て、それから HTTP リクエストを送る
9.2.3 TLS / HTTPS（Transport Layer Security トランスポート層セキュリティ）
必須 難易度 ★★★★
HTTP の平文伝送は中間者に盗聴されうる / TLS は TCP の上で暗号化し、証明書でサーバー身元を検証 / HTTPS = HTTP + TLS
DMSD では：NFC 不正防止設計の第 3 層 ECDSA 署名は、TLS 証明書と同じ楕円曲線の数学を使う
ACストーリー：面接官が「攻撃者が学生の点呼 URL を傍受したら」→ HTTPS による盗聴防止（暗号化）+ ECDSA による偽造防止（署名）の二重防護を語れること

9.3 コンパイルとインタプリト（書いたコードが動くものになるまで）

9.3.1 コンパイル型 vs インタプリタ型
高優先 難易度 ★★
コンパイル型：Swift / Kotlin / Rust — コンパイラ（compiler）がソースを一度に機械語またはバイトコードへ翻訳してから実行（実行が速い、誤りはコンパイル時に見つかる）
インタプリタ型：Python / JavaScript — インタプリタ（interpreter）がソースを読みながら実行（起動が速い、誤りは実行時に見つかる）
DMSD では：iPhone 上で動くのは Swift をコンパイルした ARM 機械語 / バックエンドは Python インタプリタが読む .py ソースコード
9.3.2 バイトコード / 仮想マシン（bytecode / virtual machine — 中間形態）
中優先 難易度 ★★★
ソースをまずクロスプラットフォームな「中間コード」（バイトコード）にコンパイルし、実行時に仮想マシンが機械語へ翻訳する。利点：同じコードを複数プラットフォームで動かせる。
Kotlin → JVM バイトコード（Java Virtual Machine：Java 仮想マシンが実行する中間コード）→ Android 上で ART ランタイムが ARM 機械語へ翻訳
DMSD では：あなたの Android コードもこの経路を通る
9.3.3 抽象構文木（AST = Abstract Syntax Tree — コンパイラがソースを見る内部データ構造）
低優先 難易度 ★★★
あなたが書いた let x = 1 + 2 を、コンパイラはまず木に変換する（代入ノード → 加算ノード → 二つの数字の葉）ことで処理できる。
DMSD では：あなたが入れた graphify ツールは AST でコード構造を解析し依存グラフを描く

9.4 データベース内部

9.4.1 B 木インデックス（B-tree / B+ 木 — PostgreSQL のデフォルト索引構造）
高優先 難易度 ★★★
平衡な多分木のデータ構造で、百万行のテーブルの照会を O(n) の全表走査から O(log n) へ落とす — 100 万行なら比較が約 100 万回から約 20 回に減る。
DMSD では：students テーブルの student_id 主キーは自動で B 木インデックスが付く； school_id フィールドにインデックスを付けるときも B 木になる
9.4.2 トランザクション ACID（Atomicity / Consistency / Isolation / Durability — データベース・トランザクションの 4 性質）
必須 難易度 ★★★
原子性（一連の操作は全部成功か全部失敗か）/ 一貫性（トランザクション前後で制約を満たす）/ 独立性（並行トランザクションが互いに干渉しない）/ 耐久性（コミット後は停電でも失われない）
DMSD では：学生の点呼 + 減点は同一トランザクションでなければならない — 点呼だけ成功して減点に失敗すると、不当な減点や不当な出席が残る
ACストーリー：面接官が「点呼の途中で DB が落ちたら」→ 答え「トランザクションのロールバックで、点呼済みなのに減点なし、という汚れたデータは出ない」
9.4.3 ロックと並行制御（lock / MVCC = Multi-Version Concurrency Control マルチバージョン並行制御）
高優先 難易度 ★★★★
従来のロック：読み書きが互いにブロック / MVCC：書き込みのたびに新バージョンを作り、読み取りは決してブロックしない（PostgreSQL のデフォルト）
DMSD では：学生 100 人が同時点呼しても、PostgreSQL は MVCC で並行を衝突なく処理する
ACストーリー：面接官が「同じ秒に 50 件の点呼をどう処理するか」→ MVCC のマルチバージョン機構で待ち行列が不要だと語れること

9.5 非同期プログラミングの深掘り

9.5.1 イベントループ（event loop — async の実装原理）
高優先 難易度 ★★★★
単一スレッドがタスクを切り替え続けて並行を模擬する：I/O 待ちに入ったら今のタスクを一時停止して別の処理へ回り、I/O が戻ったら再開。マルチスレッドよりメモリ節約（タスクごとにスレッドスタックを確保しない）。
DMSD では：FastAPI バックエンド + iOS Swift async はどちらもイベントループを使う
9.5.2 コールバック地獄 → Promise → async/await（非同期プログラミングの進化史）
中優先 難易度 ★★★
非同期構文の 3 世代：
① コールバック（callback）— ネストが深く読みにくい、エラー処理が散らばる
② Promise / Future — チェーン呼び出し .then().then()
③ async/await — 同期コードのように書けるが実態は非同期
ACストーリー：面接官が「なぜコールバックを直接使わないのか」→ 非同期構文の進化史を語れること

第 10 章 — コンピュータサイエンスの基礎（情報科学類 1-2 年共通課の予習）🆕

大学案内 P80 に情報科学類 1-2 年共通課 = 線形代数 / 微積分 / 確率統計 / 論理 / 形式言語 / プログラミング入門 / コンピュータのハード・ソフト構造 / 数値アルゴリズム / オブジェクト指向プログラミング、とある。この章で一通り予習する。AC 面接で「入学後に何を学びたいか」と聞かれ、具体科目を答えられれば加点。

10.1 離散数学（discrete mathematics）

10.1.1 命題論理 / 述語論理
高優先 難易度 ★★★
数理論理の基礎 — プログラミングの if 判定 / ブール代数 and / or / not ／量化子「存在する / 任意の」はすべてここから来る
10.1.2 集合 / 関係 / 関数
高優先 難易度 ★★★
データベースのテーブルの理論的土台は「集合 + 関係代数」— SQL の SELECT / JOIN / UNION はすべて関係演算
DMSD では：SQL で学生テーブルと出席テーブルを結合して調べる行為そのものが関係代数の演算
10.1.3 グラフ理論（graph theory）— 頂点 + 辺
中優先 難易度 ★★★
ソーシャルネットワーク / 経路計画 / Web のリンクはすべてグラフ。アルゴリズム：最短経路 / 最小全域木 / トポロジカルソート
DMSD では：学生寮のフロア平面図はグラフ（部屋 = 頂点、隣接 = 辺）；モジュール依存もグラフ
10.1.4 組合せ数学 — 順列組合せ / 包除原理
中優先 難易度 ★★★
確率計算の前提 / アルゴリズム複雑度の分析 / 暗号の探索空間の見積もり、すべてに必要

10.2 線形代数（linear algebra）

ベクトル / 行列 / 線形変換 / 固有値
高優先 難易度 ★★★★
機械学習 / コンピュータグラフィックス / 信号処理 / 量子計算はすべて線形代数に依る
ACストーリー：面接官が「機械学習をやりたいか」→「まず線形代数を補う必要がある」と答えられること自体が、論文を読める基礎がある証拠

10.3 微積分（calculus）

極限 / 導関数 / 積分 / 多変数の微積分
高優先 難易度 ★★★★
信号処理 / 機械学習の勾配降下 / 物理シミュレーションにすべて必要。導関数 = 変化率、積分 = 累積量。

10.4 確率と統計（probability and statistics）

確率 / 条件付き確率 / ベイズの定理 / 大数の法則 / 仮説検定
高優先 難易度 ★★★★
ベイズの定理 = 観測した証拠で事前信念を更新する / 仮説検定 = 観察結果が十分に「有意」かを判断する
DMSD では：減点体系は平均値 + 閾値 = 単純な統計を使っている
ACストーリー：面接官が「なぜ減点は 10 点ではなく 8 点か」→ 統計分布 / 過去の出席データの平均・分散を語れること

10.5 アルゴリズムとデータ構造（algorithms and data structures）

10.5.1 データ構造 — 配列 / 連結リスト / スタック / キュー / 木 / グラフ / ハッシュ表
必須 難易度 ★★★
構造ごとに得意な操作が違う：配列はランダムアクセスが速い / 連結リストは挿入が速い / ハッシュ表の探索は O(1) / 木は順序を保つ
10.5.2 ソートアルゴリズム — バブル / クイック / マージ / ヒープソート
高優先 難易度 ★★★
古典的な面接問題。それぞれの時間計算量 / 安定性 / 向く場面。
10.5.3 探索アルゴリズム — 二分探索 / 深さ優先 DFS / 幅優先 BFS
必須 難易度 ★★★
二分探索 = 整列済み配列で O(log n) に要素を探す / DFS = 一本道を突き進む / BFS = 層ごとに広げる
10.5.4 複雑度解析 — ビッグ O 記法 O(1) / O(log n) / O(n) / O(n²)
必須 難易度 ★★★
入力規模が大きくなったときの時間 / 空間の増え方を表す。アルゴリズムの良し悪しを語る共通言語。
ACストーリー：面接官がアルゴリズム問題を直接出すこともある

10.6 コンピュータアーキテクチャ（computer architecture）

CPU / レジスタ / キャッシュ L1 L2 L3 / メモリ / ディスク — 記憶階層
中優先 難易度 ★★★
CPU に近いほど速くて小さい / 遠いほど遅くて大きい。キャッシュヒット率がプログラム性能を左右する。
命令セット（ISA = Instruction Set Architecture）— ARM は Apple が採用 / x86 はデスクトップ向け
中優先 難易度 ★★★
ARM = 縮小命令セット（RISC、省電力、モバイル / Mac M シリーズ） / x86 = 複雑命令セット（CISC、高性能、Intel / AMD デスクトップ）
ACストーリー：面接官が「なぜ iPhone は Pi より速いのか」→ 命令セット + キャッシュ容量 + クロック周波数から語れること

10.7 形式言語とオートマトン（formal languages and automata）

正規表現 / 文脈自由文法 / チューリングマシン
低優先 難易度 ★★★★
正規表現 = 文字列パターンの記述 / 文脈自由文法 = プログラミング言語の構文の記述 / チューリングマシン = 計算可能性理論の源流
DMSD では：正規表現をすでに使っている（学生登録コード形式の検証）
ACストーリー：これはコンパイラ原理の基礎。「コンパイラを学びたい」と言えると大きく加点

10.8 オブジェクト指向プログラミング理論（OOP 理論）

カプセル化 / 継承 / ポリモーフィズム / 抽象 — 4 原則
高優先 難易度 ★★
カプセル化 = 内部詳細を隠しインターフェースだけ公開 / 継承 = 子クラスが親を再利用 / ポリモーフィズム = 同一インターフェースに複数実装 / 抽象 = 共通部分を抜き出す
DMSD では：バックエンドの SQLAlchemy model / iOS の Swift class はどちらも OOP
SOLID の 5 原則
中優先 難易度 ★★★
S 単一責任 / O 開放閉鎖 / L リスコフ置換 / I インターフェース分離 / D 依存性逆転 — OOP の発展的設計指針

第 11 章 — 情報セキュリティの深掘り（CTF / SecHack365 方向の予習）🆕

coins 公式サイト 2026-03 の実績 = SECCON CTF 14 学生優勝 + SecHack365 優秀修了。AC 面接で「入学後は情報セキュリティ方向をやりたい」と答えるなら、この分野の概念が必要。この章では DMSD の不正防止で既に使っている暗号を数学層まで引き上げ、さらに CTF 5 大分野へ広げる。

11.1 暗号の基礎

11.1.1 共通鍵暗号 — AES（Advanced Encryption Standard 高度暗号化標準）
必須 難易度 ★★★
同じ鍵で暗号化も復号もする / AES が現行標準 / DES は廃れた旧標準
11.1.2 公開鍵暗号 — RSA / ECC
必須 難易度 ★★★★
公開鍵で暗号化、秘密鍵で復号 / RSA が最も古典的（大きな整数の素因数分解の難しさ）/ ECC 楕円曲線暗号（同等の安全性で鍵が短い）
11.1.3 ハッシュ関数 — MD5（非推奨）/ SHA-256（現行）
必須 難易度 ★★
一方向で不可逆 / 任意長の入力 → 固定長の出力 / 雪崩効果（入力を 1 bit 変えると出力が激変）
DMSD では：学生登録コードを hash で偽造防止
11.1.4 デジタル署名 — 秘密鍵で署名 + 公開鍵で検証
必須 難易度 ★★★
「このメッセージは確かに秘密鍵の保持者が送った」+「改ざんされていない」ことを証明する
DMSD では：NFC 不正防止の第 3 層 ECDSA 署名

11.2 楕円曲線暗号（ECC = Elliptic Curve Cryptography）

楕円曲線の数学（y² = x³ + ax + b）
高優先 難易度 ★★★★★
楕円曲線上に「加法」を定義する / 基点 G を選ぶ / G を繰り返し加えて得られる点が鍵空間をなす
離散対数問題 — なぜ ECC は破りにくいか
高優先 難易度 ★★★★★
点 P と G が与えられたとき、P = k·G となる k を楕円曲線上で求めるのは、知られている最難の数学問題の一つ — それが ECC の安全性の源
ECDSA（Elliptic Curve Digital Signature Algorithm 楕円曲線デジタル署名アルゴリズム）
必須 難易度 ★★★★
ECC に基づくデジタル署名アルゴリズム / ビットコイン / TLS 1.3 / 現代の NFC カードでも採用
DMSD では：NFC 不正防止の第 3 層
ACストーリー：面接官が「なぜ RSA を使わないのか」→ 答え「ECC 256 ビット鍵は RSA 3072 ビット相当の安全性で、鍵長は約 10 分の 1。NFC カードの小さな記憶容量に向く」

11.3 ネットワークセキュリティの攻撃と防御

11.3.1 SQL インジェクション（SQL injection）
必須 難易度 ★★★
SQL 文字列とユーザー入力を連結する → 攻撃者が入力した ' OR '1'='1 だけでログイン検証を迂回できる。防御：パラメータ化クエリを使い、文字列連結をしない。
DMSD では：SQLAlchemy ORM はデフォルトでパラメータ化クエリなので、それ自体が SQL インジェクション対策になる
11.3.2 XSS（Cross-Site Scripting クロスサイトスクリプティング）
高優先 難易度 ★★★
悪意のある <script> を Web ページに注入 → 他者が訪問したときに cookie 窃取 / DOM 改変が実行される。防御：出力時にエスケープ / CSP ヘッダでスクリプトの出所を制限。
11.3.3 CSRF（Cross-Site Request Forgery クロスサイトリクエストフォージェリ）
中優先 難易度 ★★★
ログイン済みユーザーのブラウザを誘導してリクエストを送らせる（偽リンクをクリックさせて送金など）/ 防御：CSRF token / SameSite cookie
11.3.4 中間者攻撃（Man-in-the-Middle / MITM）
高優先 難易度 ★★★
攻撃者が通信の双方の間に入り盗聴 / 改ざん / 防御：TLS 証明書検証 + 公開鍵の固定（pinning）
11.3.5 リプレイ攻撃（replay attack）
必須 難易度 ★★★
正当なリクエストを録音して再送し正規ユーザーに成り済ます / 防御：nonce（使い捨ての乱数）+ タイムスタンプ
DMSD では：NFC 不正防止の第 2 層・動的 nonce（10 秒ごとに更新）がまさにリプレイ防止

11.4 CTF の 5 大分野

11.4.1 Reverse Engineering リバースエンジニアリング
中優先 難易度 ★★★★
他人のバイナリを逆コンパイルしてロジックや脆弱性を探す / ツール：IDA Pro / Ghidra / radare2
11.4.2 Web — サイト脆弱性の悪用
高優先 難易度 ★★★
SQL インジェクション / XSS / SSRF / コマンドインジェクションなどの悪用 / あなたの DMSD backend と直結
11.4.3 Crypto 暗号
高優先 難易度 ★★★★
弱い暗号の解読 / 暗号プロトコルの穴探し / あなたの ECDSA 知識とつながる
11.4.4 Pwn バイナリ悪用
低優先 難易度 ★★★★★
バッファオーバーフロー / ROP / メモリ破壊脆弱性の悪用 / 最もハードコアな分野
11.4.5 Forensics フォレンジック
中優先 難易度 ★★★
データ残留（メモリ dump / ネットワークパケット / ディスクイメージ）から証拠を探す
ACストーリー：「CTF 5 大分野では Web + Crypto に最も興味があり、その理由は…」と語れる = 筑波の SECCON 実績と高度に一致

第 12 章 — ソフトウェア工学（DMSD のエンジニアリング実践に対応する理論）🆕

DMSD ですでにやっているエンジニアリング（仕様凍結 / 連動チェック / hooks / commit 規範 / ドキュメント先行）の裏には理論がある。AC 面接官に「なぜそうするのか」と聞かれたら、理論用語を引用できなければならない。「感覚的に良い」だけでは足りない。

12.1 バージョン管理の理論

Git の内部構造 — blob / tree / commit / ref
高優先 難易度 ★★★
blob = ファイル内容のスナップショット / tree = ディレクトリ構造 / commit = 1 回のコミットスナップショット（ある tree + 親 commit を指す）/ ref = ブランチポインタ（branch の本質は、ある commit を指す移動可能なポインタ）
DMSD では：すでに 200+ commit を積んでおり、Git 内部モデルを理解すると rebase / cherry-pick をより安全に使える
merge vs rebase — 2 つの統合戦略
中優先 難易度 ★★★
merge = ブランチ履歴を残し merge commit を作る / rebase = ブランチのコミットを本流へ「移植」し履歴を直線にする / それぞれ取捨がある

12.2 テストの理論

12.2.1 単体テスト（unit test）
高優先 難易度 ★★
1つの関数 / メソッドの振る舞いを検証する / 実行が速い / 数が最も多い — テストピラミッドの底辺
12.2.2 統合テスト（integration test）
中優先 難易度 ★★★
複数コンポーネントの連携を検証する（例：バックエンド + データベースを一緒に動かす）/ 数は中程度 / 単体テストより遅い
12.2.3 エンドツーエンドテスト（E2E = end-to-end）
中優先 難易度 ★★★★
実ユーザーの全フローを模擬する（アプリ起動 → ボタン操作 → 結果確認）/ 遅い + 壊れやすい / 数が最も少ない
12.2.4 TDD（Test-Driven Development テスト駆動開発）
中優先 難易度 ★★★
赤 → 緑 → リファクタの循環：まず失敗するテストを書く → 通る最小限のコードを書く → リファクタ / インターフェース設計を強制的に考えさせる

12.3 デザインパターン（design patterns）

GoF の代表的な 23 パターン — まず 5〜6 個を選んで学ぶ
中優先 難易度 ★★★
Singleton シングルトン / Observer オブザーバー / Factory ファクトリ / Strategy ストラテジー / Decorator デコレータ / Adapter アダプタ — よく使うものから押さえる
DMSD では：SwiftUI の @ObservedObject / @StateObject がまさにオブザーバーパターン

12.4 リファクタリング（refactoring）

機能は変えず構造だけ変える — コードをより読みやすくする
高優先 難易度 ★★★
コードの臭い（code smell）の兆候：長い関数 / 重複コード / 神クラス（1クラスがすべてを担当）/ 謎めいた命名
DMSD では：v0.5 → v0.6 で書き直し system_features.md 357 行 → 830 行 = ドキュメント級のリファクタリング

12.5 継続的インテグレーション / 継続的デプロイ（CI/CD = Continuous Integration / Continuous Deployment）

CI は push のたびに自動でテストを走らせる / CD はテスト通過後に自動デプロイ
中優先 難易度 ★★★
「自分のマシンでは動く」系の問題を減らす / ツール：GitHub Actions / GitLab CI / Jenkins
DMSD では：正式な CI/CD はまだないが、pre-commit hook + sync-check.sh は CI の萌芽にあたる

12.6 監視 / ログ / 可観測性（observability）

ログ / メトリクス / 分散トレーシング — 3 本柱
中優先 難易度 ★★★
ログ（log イベント列）/ メトリクス（metrics 数値の時系列）/ 分散トレーシング（trace サービス横断の呼び出し鎖）/ システムが動いてからでないと問題を追えない
DMSD では：backend にログ出力はあるが、構造化ログ + Prometheus メトリクスはまだない

12.7 ドキュメント駆動開発（DDD = Documentation-Driven Development）

先に仕様 / 設計ドキュメントを書いてから → コードを書く
高優先 難易度 ★★
DMSD が採っているやり方 / TDD（テスト駆動）と並ぶもう一つの開発哲学 / 多クライアント連携のプロジェクトに向く（先にインターフェースを揃えてから各端で実装）
DMSD では：02_design/system_features.md が「先に凍結してからコードを書く」ための器になっている
AC ストーリー：審査員に「なぜ先にドキュメントを書いてからコードを書くのか」と問われたとき → DDD の理論 + DMSD の 5クライアント同期で得た実益を語れる

第 13 章 — 推奨学習順序（参考であり、強制ではない）

以下の順序は「AC スケジュール」+「1つ学べばすぐコードが読める」+「易から難へ」を総合して並べた。itsuki は自分のペースで調整してよい。新たに加わった第 9〜12 章は「Part A の主線に差し込む」のがよい — 具体的な技術点を学ぶときに、対応する基盤章をついでに開く（例：backend の HTTP を学ぶときに 9.2 ネットワークを開く）/ 単独の時間枠は設けない。

段階 A — いまから 6/15 R9 募集要項公表まで（21 日）

週 何を学ぶか 期待される成果
第 1 週（5/25-5/31） 第 1 章 プロジェクト習熟（全章 6 節） DMSD の 11 個のトップレベルディレクトリの役割 + 5クライアントそれぞれのコードの所在を口頭で説明できる
第 2 週（6/1-6/7） 第 2 章 共通基礎（2.1-2.4 コマンドライン / Git / パス / JSON） ターミナル + Git でプロジェクトを操作できる（CC にコマンド実行を頼らなくてよい）
第 3 週（6/8-6/14） 第 2 章 共通基礎（2.5-2.7 HTTP / データベース / セキュリティ） DMSD の「クライアント → HTTP → backend → データベース」の全経路を説明できる

段階 B — 6/15 から 9/3 出願締切まで（11 週）

この 11 週の itsuki の主任務は志望理由書 + 自己推薦書の執筆 + 添付資料の収集 — 学習時間は減らすべき。新しいことを学ぶために出願を遅らせてはいけない。
週 何を学ぶか 期待される成果
第 4-6 週 第 3 章 Python（3.1-3.4 文法 + FastAPI + SQLAlchemy + Pydantic） DMSD backend のコードの 60% を読める
第 7-9 週 第 4 章 Swift + SwiftUI（4.1-4.4 文法 + UI + 状態 + ナビゲーション） DMSD iOS 端のコードの 60% を読める — AC demo のデモで語れる
第 10-12 週 第 8 章 AC 直結（人材養成 / CTF / SecHack365）+ 第 7 章ハードウェア原理（7.1-7.2） 面接素材が形になる — なぜ筑波を選ぶか / 入学後に何をしたいかを語れる
第 13-14 週（出願前の最後の 2 週） 新しい学習は止める。全力で出願材料を執筆 / 点検する 9/3 出願締切前にすべての材料を整え終える

段階 C — 9/3 出願後から 11/2 最終合格まで（約 8 週）

段階 何を学ぶか 期待される成果
9/3 - 10/1（第 1 段結果通知前） 新しいことは学ばず、すでに学んだ内容すべてを「説明できる」訓練にする — 各項目を鏡の前か CC との模擬問答で 1 回ずつ通す 学んだ技術点ごとに、原理を 30 秒・DMSD での使い方を 1 分で説明できる
10/1 - 10/17（第 2 段面接前） 第 7 章ハードウェア深掘り（7.3-7.5 モジュール / GPIO / 不正防止 3 層）+ 第 2 章 2.7 セキュリティ深掘り 面接で審査員に技術詳細を問われても一通り答えられる
10/17 - 10/20（面接期間） 新しいことは学ばず、面接に集中する —
11/2 最終合格発表後 結果を見て調整 — 合格なら入学準備として Kotlin / Vue など残りの章を続ける —

段階 A/B/C の主線に入っていない章

章 学習の推奨タイミング
第 5 章 Kotlin + Compose 合格後 → 入学前の「先発優位」の準備
第 6 章 TypeScript + Vue 合格後 / 教員 Web 端で具体的な機能を実装する必要が出たときに学ぶ
第 3.5 Alembic データベース移行 backend の本番投入前に学ぶ（demo 段階では不要）
第 3.6 nfcpy 点呼機のハードウェアが届いてから学ぶ（実物が手元にあって初めて意味がある）
Part B

QTS クオンツ取引 — 究極の知識地図

16 章 / 90+ 項目 · 「明日までに全部学ぶ」ものではない / 「QTS の線に沿って実取引に至るまでにぶつかる知識の全集」である
#008 の決定どおり DMSD 優先 · QTS のペースは後回し · ここは「方向地図」で、itsuki が先にどんな山があるかを知るためのもの
この一覧自体が AC 素材になりうる — 「まったく未知の分野を自分で分解して 16 大分類の知識地図を作った」こと自体が、AC 入試で示せる能力である

Part B 序 — なぜ QTS を独立させて一ブロックにしたか

Part A との関係：Part A（DMSD + AC）が目の前の主線であり、時間がぶつかるときは Part A を優先する。Part B で触れる「Python / データベース / Linux / Docker / セキュリティ」などは Part A にも出る — 重複して列挙せず、QTS 固有の特化部分（金融 / 市場 / バックテスト / 戦略）こそが Part B の真の核心である。
性格：「究極の一覧」は「学習計画表」ではない / ゼロから始める / 学習経路の順に並べる（前提基礎 → 金融の理解 → 戦略 → バックテスト → 実取引 → 応用）。
範囲は QTS 関連に限定：日本語 / AC 出願準備 / 数学の大学入試は列挙していない。将来「学習内容全体」に広げるかは itsuki が決める。

QTSQ1 — プログラミング基礎（前提として必須）

コードを書く能力そのもの — これがないと他は学べない。Part A 第 3 章の Python 部分と重なるが、QTS の視点で補う：クオンツ界ではほぼ Python が独占なので、Python を学ぶのは双方への投資になる。
Q1.1 Python 基礎文法
必学 難易度 ★★
Python = クオンツ界でほぼ独占のツール / 変数 / 制御フロー / 関数 / クラス
QTS の視点：主要なクオンツライブラリ（pandas / numpy / backtrader / vnpy）はすべて Python
Q1.2 コマンドライン / ターミナル基礎
必学 難易度 ★
cd（ディレクトリ移動）/ ls（ファイル一覧）/ パイプ | / リダイレクト >
Q1.3 Git バージョン管理
必学 難易度 ★★
commit / ブランチ / リモートリポジトリ — 戦略の反復にはバージョン管理が必須。さもないと、ある日バックテストがうまくいってもどの版の戦略か分からなくなる
Q1.4 データ構造の基礎
高優先 難易度 ★★★
リスト / 辞書 / 集合 / 木 / グラフ — 相場データの処理で毎日使う
Q1.5 デバッグとテスト
高優先 難易度 ★★★
ログ出力 / ブレークポイント / 単体テスト — 戦略コードの記号ひとつで数百万損しうる。必ず直せて測れなければならない

QTSQ2 — 数学と統計の基礎

クオンツ取引の本質は数学で市場を記述すること。この土台がないと、他人の話さえ聞き取れない。
Q2.1 確率論
必学 難易度 ★★★★
条件付き確率 / ベイズの定理 / 主な分布（正規 / 対数正規 / ポアソン）/ 株価の対数リターンが近似的に正規分布になることは、大半のモデルの前提である
Q2.2 記述統計
必学 難易度 ★★★
平均 / 分散 / 歪度（分布が対称か）/ 尖度（裾の厚さ）/ 分位数 — 因子分析に必須
Q2.3 仮説検定
高優先 難易度 ★★★★
t 検定 / カイ二乗 / p 値（統計的有意性の指標）— 因子が「本当に有効」か運かを判断する
Q2.4 線形代数
高優先 難易度 ★★★★
行列演算 / 固有値 / 主成分分析 PCA — 多因子の合成 + リスクモデルに必須
Q2.5 時系列
必学 難易度 ★★★★★
自己相関 / 定常性 / ARMA / ARIMA（時系列予測モデル）/ 相場データは本質的に時系列である
Q2.6 微積分の基礎
高優先 難易度 ★★★★
微分 / 積分 / 最適化 — ポートフォリオ最適化 / オプション価格付けのすべてに必要
Q2.7 確率過程
中優先 難易度 ★★★★★
ブラウン運動 / マルチンゲール / マルコフ連鎖 — オプション価格付け / 高頻度モデリングの理論的源流

QTSQ3 — 金融市場の基礎

自分が何を相手にしているかをはっきりさせる。
Q3.1 金融市場の分類
必学 難易度 ★★
一次（発行）/ 二次（流通）/ 取引所（場内）/ 店頭（OTC）
Q3.2 市場参加者
必学 難易度 ★★
個人投資家 / 機関（公募 / 私募 / ヘッジファンド）/ マーケットメイカー / 規制当局
Q3.3 主な金融商品
必学 難易度 ★★★
株式（普通株 / 優先株 / ADR 米国預託証券）/ 債券（国債 / 社債 / 利回り曲線）/ 先物（契約 / 証拠金 / ロールオーバー）/ オプション（Call コール / Put プット / Greeks ギリシャ文字 / Black-Scholes オプション価格付けモデル）/ ETF（上場投資信託 / 指数 / レバレッジ / インバース）/ 外国為替 / 暗号資産
Q3.4 各市場の特徴（米 / 日 / 香港 / A 株）
必学 難易度 ★★★
取引時間帯 / 値幅制限 / 決済ルールの違い — クロスマーケット戦略の前に必ず押さえる

QTSQ4 — 市場のミクロ構造

「注文がどうマッチングされて約定するか」の基盤メカニズム — 実取引のあらゆる細部に影響する。
Q4.1 オーダーブック（買いと売りの注文キュー）
必学 難易度 ★★★
5 板 / 10 板 / フル（完全な limit order book）
Q4.2 マッチング機構
必学 難易度 ★★★
ザラバ（取引時間中）/ 板寄せ（寄り付き / 大引け）
Q4.3 流動性 / スプレッド / 市場の深さ
高優先 難易度 ★★★
流動性 = 約定したい量がどれだけ速く約定できるか / spread = 最良買いと最良売りの差 / 深さ = 各板の注文総量
Q4.4 マーケットメイカーの役割
中優先 難易度 ★★★
同時に買いと売りの注文を出してスプレッドを稼ぐ / 流動性を供給する / 在庫リスクを負う
Q4.5 高頻度取引が市場に与える影響
中優先 難易度 ★★★★
流動性を供給する / スプレッドを縮める / ただし極端な相場を増幅する（フラッシュクラッシュ）

QTSQ5 — 日本市場特化（TSE + moomoo）

汎用知識ではない — だが QTS を日本で回すなら必須。itsuki は日本にいて moomoo を使う。この章は「飛ばせない章」である。
Q5.1 東証 TSE（Tokyo Stock Exchange 東京証券取引所）のルール
必学 難易度 ★★★
前場（9:00-11:30）/ 後場（12:30-15:30）/ 立会外取引 / 値幅制限のルール / 単元株数（100 株）
Q5.2 税制
必学 難易度 ★★★
特定口座の源泉徴収 / 一般口座 / NISA（少額投資非課税制度）/ 確定申告の流れ
Q5.3 法律
高優先 難易度 ★★★★
金融商品取引法 / インサイダー取引の禁止 / 高頻度取引の制限
Q5.4 moomoo / 富途日本
必学 難易度 ★★★
取引可能な銘柄 / 手数料の構造 / openD ゲートウェイ / moomoo OpenAPI のインターフェース文書 / デモ口座 vs 実口座の違い

QTSQ6 — クオンツ取引の理論

本格的に「クオンツ」という学問に入る。
Q6.1 クオンツ取引とは何か
必学 難易度 ★★
裁量取引 / 高頻度取引との違い / 共通の特徴：ルール化 + データ駆動 + バックテスト可能
Q6.2 alpha / beta の概念
必学 難易度 ★★★
alpha = 超過リターン（市場を上回る部分）/ beta = 市場との相関 / 戦略の目標は通常「正の alpha + 制御可能な beta」
Q6.3 戦略の大分類
必学 難易度 ★★★★
トレンドフォロー（モメンタム / ブレイクアウト）/ 平均回帰（統計的アービトラージ / ペアトレード）/ アービトラージ（クロスマーケット / カレンダー / 三角）/ イベントドリブン（決算 / 買収合併）/ ファクター投資（バリュー / モメンタム / クオリティ / 低ボラティリティ）/ 高頻度マーケットメイク / 機械学習駆動の戦略
Q6.4 ファクターモデル
高優先 難易度 ★★★★
CAPM 資本資産価格モデル / Fama-French 3 ファクター + 5 ファクター / APT 裁定価格理論
Q6.5 ポートフォリオ理論
高優先 難易度 ★★★★
Markowitz 平均分散 / Black-Litterman / リスクパリティ（risk parity）
Q6.6 古典的著作
高優先 難易度 ★★★★
Ernest Chan『Quantitative Trading』シリーズ / López de Prado『Advances in Financial Machine Learning』/ Rishi Narang『Inside the Black Box』

QTSQ7 — データ

きれいなデータがなければ、どんなに良い戦略も砂上の楼閣である。
Q7.1 相場データの種類
必学 難易度 ★★
tick ティック / 1 分 / 5 分 / 日足 / 週足 — 頻度が戦略の種類を決める
Q7.2 ファンダメンタルデータ
必学 難易度 ★★★
決算 / バリュエーション / 業種分類
Q7.3 オルタナティブデータ
中優先 難易度 ★★★
ニュース / 衛星画像 / ソーシャルメディア / 検索トレンド — 現代クオンツの alpha の増分
Q7.4 データの落とし穴
必学 難易度 ★★★★
調整済み価格（前方調整 / 後方調整）/ タイムゾーン / タイムスタンプの揃え / 欠損値 / 異常値 / 生存者バイアス（上場廃止銘柄が除外されてバックテストが過大になる）
Q7.5 データの保存
高優先 難易度 ★★★
CSV / Parquet（列指向ストレージ形式、pandas と相性が良い）/ HDF5 / 時系列データベース（InfluxDB / TimescaleDB）/ リレーショナルデータベース（SQLite / PostgreSQL）

QTSQ8 — データ処理ツールチェーン（プログラミング層）

Q8.1 pandas（Python の表形式データライブラリ）
必学 難易度 ★★★
DataFrame 操作 / 時系列の揃え / groupby によるグループ集計 — クオンツでは毎日使う
Q8.2 numpy（Python の数値計算ライブラリ）
必学 難易度 ★★★
ベクトル化演算 — numpy で書くと純粋な Python ループより 100 倍速い
Q8.3 可視化 — matplotlib / plotly
必学 難易度 ★★
ローソク足チャートを描く / バックテストの純資産曲線 / ファクター分布 / 可視化しなければ問題に気づけない
Q8.4 SQL（構造化照会言語）の基礎
必学 難易度 ★★★
クエリ / テーブル結合 JOIN / 集約 GROUP BY — DMSD バックエンドの SQLAlchemy 知識と再利用できる

QTSQ9 — 戦略開発

Q9.1 ファクター構築
必学 難易度 ★★★★
テクニカルファクター（モメンタム / リバーサル / ボラティリティ / 出来高）/ ファンダメンタルファクター（PE 株価収益率 / PB 株価純資産倍率 / ROE 自己資本利益率 / 成長率）/ センチメントファクター（ニュース感情 / フォーラムの熱量）
Q9.2 シグナル生成
高優先 難易度 ★★★★
単一ファクター検定（IC / IR）/ マルチファクター合成 / ファクター直交化（ファクター間の相関を除去）
Q9.3 ポジション管理
必学 難易度 ★★★★
等加重 / 時価総額加重 / リスク加重 / Kelly ケリー基準 / 固定比率
Q9.4 ポートフォリオ最適化
高優先 難易度 ★★★★★
平均分散最適化 / リスク予算 / 業種 + 個別銘柄 + 売買回転率の制約

QTSQ10 — バックテスト（落とし穴のほうが手法より重要）

バックテストはクオンツ取引でもっとも自己欺瞞しやすい工程だ。この章の「落とし穴の知識」は「手法の知識」より重要 — 大半の戦略は戦略そのものではなく、バックテスト設計の誤りで失敗する。
Q10.1 バックテストエンジン設計 — イベント駆動 vs ベクトル化
必学 難易度 ★★★★
イベント駆動 = 1 本の bar ずつシミュレートし、より現実的だが遅い / ベクトル化 = 期間全体を一括計算し、速いが誤りやすい
Q10.2 よくあるバイアスの識別（重点）
必学 難易度 ★★★★★
先読みバイアス（look-ahead bias — 将来になって初めて分かる情報を使ってしまう）/ 生存者バイアス（survivorship bias — 上場廃止銘柄が除外されサンプルに偏りが生じる）/ 過学習（パラメータを過去データに合わせすぎて将来では効かなくなる）/ データスヌーピング（data snooping — 同じデータで繰り返し試し、有効に見えるまで続ける）
Q10.3 現実制約のモデリング
必学 難易度 ★★★★
手数料 / スリッページ（実際の約定価格が想定より悪い）/ 値幅制限 / 売買停止 / 流動性制約 — これらをモデル化しないバックテストはすべて偽もの
Q10.4 評価指標
必学 難易度 ★★★
年率リターン / 最大ドローダウン / Sharpe シャープレシオ（単位リスクあたりいくらリターンを得られるか）/ Sortino ソルティノレシオ / Calmar カルマーレシオ / 勝率 / 損益比 / 売買回転率
Q10.5 ロバスト性検証
必学 難易度 ★★★★
インサンプル vs アウトオブサンプル / Walk-forward ローリングウィンドウ検証 / モンテカルロシミュレーション / パラメータ感度分析

QTSQ11 — リスク管理

Q11.1 リスク計測
必学 難易度 ★★★★
VaR バリュー・アット・リスク（一定の信頼水準での最大損失）/ CVaR 条件付きバリュー・アット・リスク / 最大ドローダウン / ボラティリティ
Q11.2 リスク制御
必学 難易度 ★★★
損切りルール / ポジション上限 / 業種 + 個別銘柄 + レバレッジ制約
Q11.3 資金管理
必学 難易度 ★★★★
資金配分 / ポジション調整 / ブラック・スワンへの対応
Q11.4 心理的規律
必学 難易度 ★★★
シグナル執行に手を抜かない / 損失時に注文を取り消さない / システム化の最大の価値は、この規律を機械に委ねること

QTSQ12 — 実取引デプロイ

Q12.1 システムアーキテクチャ
必学 難易度 ★★★★
データ取得 → シグナル生成 → 発注 → リスク管理 → 監視 という主系列 / どの段階も落ちうるので、耐障害性が必要
Q12.2 非同期 / 並行処理の基礎
高優先 難易度 ★★★★
同期ブロッキング vs 非同期イベントループ — Part A 第 9.5 節と接続
Q12.3 注文執行
必学 難易度 ★★★★
注文タイプ（成行 / 指値 / ストップ / アイスバーグ）/ 執行アルゴリズム TWAP（時間加重平均価格）/ VWAP（出来高加重平均価格）/ POV（参加率）
Q12.4 監視とアラート
必学 難易度 ★★★
リアルタイム保有ポジション / 損益 / 異常検知 / 通知チャネル（メール / Slack / Telegram）
Q12.5 ログ監査（QTS の中核的特徴：監査可能性）
必学 難易度 ★★★★
注文 / シグナル / 意思決定の根拠を完全に記録 — ここが QTS と伝統的クオンツの差別化点
Q12.6 フォールトトレランスと障害復旧
必学 難易度 ★★★★
回線断 / サービス再起動 / データ補完 — 実取引ではいつでも想定外が起きるので、対応手順を事前に書いておく

QTSQ13 — 機械学習のクオンツへの応用

Q13.1 教師あり学習の基礎
高優先 難易度 ★★★★
回帰（連続値の予測）/ 分類（カテゴリの予測）
Q13.2 時系列予測
中優先 難易度 ★★★★★
ARIMA / LSTM 長短期記憶ネットワーク / Transformer
Q13.3 強化学習の取引への応用
中優先 難易度 ★★★★★
Q-learning / 方策勾配 — agent に最適な執行を自ら学ばせる
Q13.4 アンサンブル学習
高優先 難易度 ★★★★
XGBoost / LightGBM — 2 つの勾配ブースティングモデルで、ファクター合成でよく使われる
Q13.5 LLM の取引への応用
高優先 難易度 ★★★★
LLM = Large Language Model 大規模言語モデル / ニュース感情分析 / 決算の解釈 / 意思決定支援 — Q14 と接続
Q13.6 機械学習の落とし穴（重点）
必学 難易度 ★★★★★
データリーク（label がうっかり将来情報を含む）/ 時系列クロスバリデーション（ランダム分割は不可）/ 過学習 / 市場の非定常性（過去データで学んだパターンが将来は効かなくなる）

QTSQ14 — AI Agent 多層アーキテクチャ（QTS の特色）

archive にある「人と機械の協調 + 監査可能」という位置づけに対応し、QTS と伝統的クオンツの差別化点になっている。
Q14.1 多層アーキテクチャ設計
必学 難易度 ★★★★
戦略層 / 意思決定層 / 執行層 — それぞれの職責を明確にし、監査 + 差し替えをしやすくする
Q14.2 プロンプトエンジニアリング
必学 難易度 ★★★
大規模モデルに必要な出力をさせるには — 構造化プロンプト / 役割設定 / few-shot の例示
Q14.3 エビデンスパック設計
必学 難易度 ★★★★
すべての意思決定を「なぜそう決めたか」まで遡れるようにする — これが QTS の差別化の売り
Q14.4 LLM 出力の検証
必学 難易度 ★★★★
大規模モデルの根拠なき出力がそのまま取引に入るのを防ぐ — 複数モデルの交差検証 / ルールのホワイトリスト / 人手の review 関門

QTSQ15 — 行動ファイナンスと心理

Q15.1 よくある認知バイアス
高優先 難易度 ★★★
確証バイアス（自分の結論を支えるデータだけ見る）/ アンカリング効果 / 過信 / 処分効果（利益はすぐ確定し損失は握りしめる）
Q15.2 規律性 / システム化思考
必学 難易度 ★★
なぜ手作業ではなく機械に執行させるか — 機械に感情はなく、損したからといってルールをむやみに変えない
Q15.3 損失時のメンタル管理
必学 難易度 ★★★
連敗しても当初計画からずれない — 戦略そのものより難しい

QTSQ16 — エンジニアリングと運用

戦略を書き終えたら終わりではない — 安定して走り続けられてこそ。Part A 第 9 / 12 章と接続。
Q16.1 Linux 基礎
必学 難易度 ★★
サーバの常用コマンド / プロセス管理 / cron 定期実行
Q16.2 Docker コンテナ化
必学 難易度 ★★★
アプリ環境のパッケージ化 / 一度ビルドすればどこでも動く / docker-compose で複数サービスを編成
Q16.3 クラウドサービスの基礎
必学 難易度 ★★★
VPS（Virtual Private Server 仮想専用サーバ）/ デプロイ手順 / SSH リモート操作
Q16.4 監視 — Prometheus + Grafana
高優先 難易度 ★★★
監視データの収集 + 可視化のツールペア / 実取引に必須
Q16.5 CI/CD（継続的インテグレーション / 継続的デプロイ）の基礎
高優先 難易度 ★★★
push のたびに自動でテスト実行 + サーバへデプロイ — Part A 12.5 と接続

バージョン: v0.2.0 / 2026-05-26 拡張（DMSD 第 9-12 章 + QTS Part B 全 16 章を追加）

CC が起草、itsuki の査読 / フィードバック待ち。この一覧は固定ではない — itsuki が数項目学んだら、いつでも CC に調整させてよい。

関連ドキュメント: