第 1 回　なぜ作ったのか

武蔵野大学データサイエンス学部の年次成果発表会「未来創造発表会」を、準備から表彰まで 1 つの導線に統合したポータルシステム MIRAIS の設計・実装記録です。全 6 回に分けて公開します。

第 1 回では、企画の出発点となった課題認識、関係者へのヒアリング、そしてそこから引き出した要件定義までを扱います。

先に全体像だけ掴みたい方は、要約版の設計ノートからどうぞ。

0. この資料について

0-1. 何を書いたものか

学部の年次イベント「未来創造発表会」の運営を、Web システムで作り直したプロジェクトの記録です。企画の出発点となった課題認識から、関係者へのヒアリング、要件定義、情報設計、実装、アルゴリズム、外部サービス連携、そして残された課題までを一本の線で辿れるようにまとめています。

技術的な意思決定については「何を選んだか」だけでなく「なぜそれを選んだか」を必ず添えました。実装の細部より、制約の中でどう判断したかのほうが、読んでくださる方にとって価値があると考えたためです。

0-2. 公開にあたっての編集方針

本資料は対外公開版です。原本にあたる内部資料から、以下を編集しています。

• 関係者の実名・連絡先を削除しました。学内の事務職員・教員の方は役職表記に、学生は架空の例に置き換えています。ヒアリングでご協力いただいた方の業務内容についても、個人の負担感に触れる表現を中立的な記述に改めています。
• チームメンバーの表記は、私（執筆者）以外を役割表記としています。共同開発者の氏名を私の判断で公開しないためです。
• インフラの具体値（サーバー識別子、ディレクトリ構成、ポート番号、接続情報、デプロイ手順）を抽象化または削除しました。
• API エンドポイントの網羅的な一覧を、機能ドメイン単位の要約に置き換えています。
• セキュリティに関する記述は、設計上どう考えたかは残し、未対応事項については具体的な箇所や再現手順を伏せて、性質のみを記載しています。

技術的な設計思想・アルゴリズム・データモデルについては、内部版と同じ密度で記載しています。

0-3. 構成

第 I 部    プロジェクトの原点        (1〜4章)    なぜ作ったのか
第 II 部   現状分析                  (5〜7章)    何が起きていたのか
第 III 部  要件定義                  (8〜11章)   何を作ると決めたのか
第 IV 部   情報設計                  (12〜15章)  どう見せるのか
第 V 部    アーキテクチャ            (16〜18章)  どう組んだのか
第 VI 部   データモデル              (19〜21章)  何を保持するのか
第 VII 部  バックエンド              (22〜24章)  サーバは何をしているのか
第 VIII 部 フロントエンド            (25〜26章)  画面は何をしているのか
第 IX 部   3D バーチャル会場         (27〜31章)  メタバース展示の仕組み
第 X 部    アルゴリズム詳解          (32〜35章)  頭脳部分の設計
第 XI 部   外部サービス連携          (36〜39章)  既存の業務ツールとどう繋ぐか
第 XII 部  品質とセキュリティ設計    (40〜41章)  何をどう守るのか
第 XIII 部 到達点と展望              (42〜44章)  どこまでできたのか
第 XIV 部  付録                      (45〜47章)  逆引きリファレンス

---

---

第 I 部　プロジェクトの原点

---

1. 背景と目的

1-1. 未来創造発表会とは

武蔵野大学データサイエンス学部（MUDS）の年次イベントです。学生が 1 年間の研究成果をポスター形式で発表し、学内外——特に来場企業——へ発信する場として運営されています。

• 3 部制：1 部・2 部・3 部に分かれ、学生が入れ替わりで同じポスターボード位置に立ちます。
• 会場：大学キャンパス内の 2 フロア構成のホール。
• 当日の流れ：開場・受付 → 開式 → 第 1〜3 部（各 45 分）→ 審査・投票 → ソーシャル → 表彰式 → 閉式。おおよそ 6 時間のプログラムです。
• 表彰：ゼミから選出される「学科賞」と、参加企業が選ぶ「企業賞」の 2 系統があります。企業には序列があり、学科賞の候補リストから企業賞へ「格上げ」する調整が入ります。

1-2. 今年度の新しい変数：通信制学部の新設

今年度、通信制の「国際データサイエンス学部（MIDS）」が新設されました。これにより、従来は存在しなかった課題が生まれています。

• 遠隔地にいる学生の展示の場をどう確保するか
• 会場に来られない企業・学生の参加体験をどう成立させるか

MIRAIS の 3D バーチャル会場は、この課題への直接的な解として位置づけています。「3D 技術を使ってみたい」という動機が先にあったのは事実ですが、それを技術の披露で終わらせず、目の前にある具体的な課題への解答として設計し直したことが、このプロジェクトで私が最もこだわった点のひとつです。

1-3. 目的

未来創造の参加者全員が、準備から表彰までをこのポータルで完結させ、これまで感じていた不便をこの代から解消する。

これをコア体験と定め、細かい要件がどれだけ変わってもこの一行だけはブレさせない、という合意をチームで最初に作りました。

同時に、これを「ハッカソンの提出作品」で終わらせず、来年度以降も動き続けるインフラとして設計することを前提条件に置いています。作った人間が卒業した後も回り続けなければ、解決したことにならないからです。

1-4. 前提条件：学内資源で完結させる

企画の段階で、外部の商用サービスに依存せず、学内の計算機資源だけで完結させるという前提を置きました。この前提が、以下のアーキテクチャ判断を直接規定しています。

• 商用 LLM API に依存せず、学内の GPU サーバー上で動く LLM を第一候補とする。かつ、それが使えない環境でも機能が停止しない構成にする。
• 認証基盤に外部 SaaS を使わず、Google ID Token の検証と自前の JWT 発行で賄う。
• ホスティングは学内の計算機資源を利用する。

開発の途中で学内サーバー上での運用許可が下りたため、現在は学内の GPU サーバーで稼働しています。継続的に発生するコストはありません。

制約は設計の敵ではなく、判断を強制的に明確にしてくれる材料でした。「使えるものが限られているから諦める」ではなく「限られているからこの構成になる」という順序で考えられたことが、結果的にアーキテクチャを筋の通ったものにしたと思っています。

---

2. 経緯：企画から実装まで

MIRAIS は一度に設計されたわけではありません。6 月からの一連のミーティングとヒアリングの積み重ねで形になりました。

2-1. 出発点

チーム 3 名で互いの得意領域とその深度を突き合わせるところから始めました。私はフルスタックで全体設計と実装、後輩 2 名はそれぞれ UI/UX とフロント寄りの実装、バックエンドと外部連携を担当することになりました。

次の回で「発表会で使うサイトを作る」という粒度の企画案を出し、含めたい要素を列挙しています。

• 現行サイトにある機能はすべて踏襲する
• 研究一覧をリアルタイムで反映する
• 投票機能
• ポスター管理
• 3D 技術の活用（要相談）
• 外部の商用サービスに依存しない

使いたい技術として FastAPI / Next.js / LLM とエンベディング / 3D ライブラリを挙げました。この時点で「事務・学生・企業の 3 パターンに分けるべき」という後輩の提案と、「リマインド機能・コメント機能」という別の後輩の提案が出ており、これが後のロール設計の原型になっています。

期間の呼称もここで決めました。キックオフ前＝開発研究期間／キックオフ後＝開発期間です。前者を技術検証にあて、後者で一気に作る、という組み立てです。

2-2. 軸を固定した回

議題は「要件定義のたたき上げ作成」でした。ここで最も重要な合意が形成されています。

細かい要件定義は今後たくさん変わる。ですが、コアな体験や本質的な部分は変えずに貫いていきたい。

各メンバーの課題意識も、この回で言語化されました。

• 発表会の運営プロセスに無駄が多いので、それを省きたい。
• 既存の仕組みが扱いづらいので、扱いやすいものにしたい。
• 共通の軸として「誰が、どんな時に、どう使って、どう思うのか」を常に問う。

機能一覧の書き方のルールもここで決めています。機能名 → なぜその機能が必要なのか（誰のどんな課題を解決するのか） を必ずセットで書く、というものです。本資料の第 10 章もこの形式を踏襲しています。機能名だけ並んだリストは、あとから読むと何を解決したかったのか分からなくなるからです。

2-3. 現状把握

現行システムの機能棚卸しと、関係者の業務フローの推測を行いました。ここで「セキュリティや個人情報にも対応した方がいい」「長く使えることも大事」という 2 つの非機能要件が追加されています。どちらも、後の設計に決定的な影響を与えました。

2-4. ヒアリング

発表会の運営を主に担当されている事務職員の方に、直接お話を伺いました。本プロジェクトで最も情報密度が高い一次情報であり、第 7 章に構造化して収録しています。

ここで得られた「現在管理しているスプレッドシートと同じ形にならなくてもよい」という一言が、システム側のデータベースを正暦（Single Source of Truth）とする設計判断を可能にしました。この一言がなければ、既存のスプレッドシート形式に引きずられた、はるかに窮屈なデータモデルになっていたはずです。

2-5. 設計の骨格

ヒアリング結果を反映して企画提案書をまとめ、続いてペイン × ソリューション × 実装アプローチのマトリクス、機能一覧 F-01〜F-12、技術アーキテクチャ、技術検証（PoC）計画を定義したグランドデザインを作成しました。

その後、ロールを 4＋1（事務／教員／学生／参加企業／開発用）に確定し、データベースの星型スキーマ設計を確定。さらに 6 ロール（未ログインを含む）を前提としたサイトマップと権限マトリクスを定義し、未ログインに対してはポスターファイルを API・DOM ごと削除するというセキュリティ要件を明文化しました。

2-6. 実装

残ページの洗い出しと Phase 0〜5 のロードマップを引いて実装に入りました。基盤 → CI/CD → 機能実装（数次にわたる）→ 3D 空間 → デプロイ調整、という順に進んでいます。

---

3. チーム体制と技術検証

技術検証を最優先で回した理由は「技術が理由でコア体験が崩壊することを防ぐ」ためです。細かい要件は変わってよい。しかし LLM が動かない、3D が重すぎて実用にならない、Slack が通らない、といった技術的破綻だけは、企画が固まる前に潰しておく必要がありました。

結果として、3 つの検証はいずれも「動く」という結論を得て、そのまま本実装に移行しています。特に LLM については、検証の過程で「学内サーバーが使えない場合でも動く代替経路」を用意する判断につながりました（第 32 章 / 第 5 回）。

---

4. 命名

MIRAIS = MUDS & MIDS Innovative Research Activity Integrated System

名前を決めるにあたって重視したのは 3 点です。

1. 「未来（MIRAI）」との音の一致。「未来創造発表会」のためのシステムであることが、名前だけで伝わること。
2. 両学部を明示的に含むこと。MIDS 新設という今年度固有の文脈を、名前のレベルで引き受けること。
3. 学内で日常的に呼ばれる名前として親しみやすい語感であること。学内には既に学業支援システムがあり、それと並んで呼ばれる存在を目指しました。

親しみやすく、わかりやすく、かつプロジェクトの射程を正確に含む——この 3 つを同時に満たす候補を探すのに、意外と時間を使いました。

---

---

第 II 部　現状分析

---

5. 現行サイトの機能棚卸し

MIRAIS は既存サイトの完全上位互換であることを前提条件（F-01）に置きました。移行にあたって「あの機能がなくなった」が一つでも起きれば、それだけで導入は失敗するからです。まず現行サイトが提供している機能を漏れなく棚卸ししました。

5-1. トップページに存在する要素

• タイトル／日時／アクセス
• 参加申請フォームへのリンク
• お知らせ
• お問い合わせフォームへのリンク
• コンテンツタブ（学生テーマ一覧／参加者専用サイト／ゼミ紹介／式次第／FAQ）

5-2. 構造上の課題

• トップページ以外は、リンクタイトル程度の情報しかなく、実質的なコンテンツが薄い。
• 「参加者専用サイト」はボタンだけが存在し、承認後に別途 URL がメールで送付される二重構造になっている。サイトとしての導線が閉じていない。
• 研究テーマ一覧は、フォーム → スプレッドシート → サイトへ手動で転記されたもの。リアルタイム性がない。

5-3. 参加企業向けサイトの内容

ヒアリングで判明した内容です。

• テーマ一覧／会場マップ／投票フォーム／受賞ルール

MIRAIS ではこれらを研究一覧・3D 会場・投票 UI・お知らせ／FAQ として統合ポータル側に取り込み、「専用サイト」という別サイトの概念自体をなくしました。承認された企業には、同じポータルの中で見える情報が増える、という形に変えています。

---

6. 関係者の現行フロー

6-1. 運営事務担当

1. 外部の企業への案内を開始する
2. どの企業が参加されるかを集計する
3. 企業に公開する発表内容を、学生向けフォームを作成して回答させる
4. 収集した発表テーマをスプレッドシートにまとめて、サイトへ公開
5. 誰が 3 部制のどのタイミングで発表するかを割り振る
6. 学生へ、ポスター印刷の案内を送信
7. 学生へ、登校時間などの案内を送信

このフローは、フォーム → スプレッドシート → サイトという 3 段階の手動転記と、チャットツールでの個別連絡という 2 つの作業で構成されています。

6-2. 学生

1. フォームに研究のタイトルを入力
2. ポスターを作成し、クラウドストレージへ保存（保存場所が分かりにくい）
3. ポスターを各自で印刷し、当日まで保管
4. 当日、指定された時間と場所へポスターを貼り、前で説明

6-3. 参加企業

1. 参加フォームを送信
2. 参加者専用サイトへの案内メールを受け取り、アクセス
3. それ以降のフローは、運営側からは見えていない

3 番目が空白であること自体が課題でした。企業がどう体験しているかを誰も把握していない。MIRAIS ではブックマーク・オファー・投票をシステム内に取り込むことで、ここを可視化しています。

---

7. ヒアリングで得られたこと

運営事務を担当されている方に、年間スケジュールに沿って業務を伺いました。設計判断に最も強い影響を与えた一次情報です。

7-1. 年間の流れ

7-2. 設計に直結した要望

「背景画像を変更できるようにする」 → F-12 ノーコード運営設定画面が生まれました。毎年サイトの見た目を変えたい、しかしプログラムは触れない。この 2 つを両立させるには、デザイン要素をデータとして持つしかありません。

名札の準備 「切ったり名札入れに入れたりするのは難しいが、切る前の紙を作るところまでは自動化できそう」 → A4 面付けデータの生成機能。どこまでを自動化の対象とするか、その線引きを利用者自身に引いてもらえたのは大きな収穫でした。

案内紙の準備 「ポスター掲示の上に貼る、誰がいつこのボードで発表するかを伝えるもの」 → ブース案内スライドの自動生成。実装では「1 スライド ＝ 1 物理ブース位置、同じ位置の 1〜3 部の発表者を 1 枚に集約」という形にしました。

表彰者発表スライド 「一覧を出し、アルゴリズムに応じて自動生成し、手動でも変更できるようにしたい。既存のマクロはあるが、名前の入力が大変で、レイアウトも合わない。テンプレートを用意しておき、それをコピーしてデータを入力する方式が良い」 → 表彰スライド自動生成。「テンプレをコピーして入れる」という言葉が、そのまま実装方針になっています。

7-3. 受賞ルールと企業の序列

• 参加企業には序列があり、手動で管理されている。
• ゼミ側から学科賞の候補リストを受け取り、そこから企業賞へ格上げする。
• 主担当の教員は持ち回りで学生を管理している。

→ 2 フェーズ表彰アルゴリズム（Phase 1: 教員推薦プールの生成 → Phase 2: 企業が序列順に推薦プールから選出し「学科賞 → 企業賞」に格上げ）が生まれました。第 33 章 / 第 5 回に詳述します。

7-4. 学生からの収集

• 2 週間前までに、各ゼミの学生からタイトルと概要を収集する（遅れる前提のスケジュールを組んでいる）。

「遅れる前提」という言葉が、リマインド機能を「あれば良い機能」から「前提を織り込んだ必須機能」へ格上げしました。

7-5. 運用上の実情と、それが設計に与えた影響

最後の 2 点が、このプロジェクトで私が学んだ最も大きなことでした。システムで運用を強制するのではなく、既存の運用を許容した上で、それが最小手数で済む機能を用意する。ロゴ収集を自動化しようとすれば、先方の稟議プロセスまで巻き込む大掛かりな話になります。しかし「運営の方が手でコピペする」という運用を前提に置けば、必要なのは画像 URL を保存する 1 カラムと、それを貼り付ける入力欄だけです。

「ユーザーファースト」を、要望を全部叶えることだと誤解しないこと。相手の運用のどこに手を入れないかを決めることも、同じくらい設計の一部だと考えています。

---

---

第 III 部　要件定義

---

8. 課題の一覧

ヒアリングと現行フロー分析から抽出した課題を、関係者別に整理します。

8-1. 運営事務・教員

8-2. 学生

8-3. 参加企業

---

9. 課題 × 解決策 × 実装アプローチ

9-1. 運営事務・教員

9-2. 学生

9-3. 参加企業

---

10. 機能一覧（F-01〜F-12）

各機能は「なぜ必要か（誰のどんな課題を解決するか）」とセットで定義しています。

実装状況は第 42 章 / 第 6 回にまとめています。

---

11. ロール別要件と非機能要件

11-1. ロール別のコア価値

開発ロールについて補足すると、審査や検証の場で「12 月の企業招待期」「開催 2 週間前の締切期」「当日の投票期」といった数ヶ月に及ぶ運用フェーズを、その場で切り替えて見せられることが必要でした。数ヶ月かけて起きることを 5 分で体験してもらうための仕組みです。この機能は本番環境では無効化されます。

11-2. 非機能要件

セキュリティ・個人情報

NF-S1 について補足します。「フロント側で出し分ければよい」という案もありましたが、それでは通信内容を見れば取得できてしまいます。CSS で隠すのはもちろん論外です。API レスポンスに載せないことが唯一の確実な担保だと判断し、公開用のレスポンスモデルを 3 フィールドだけを持つ型として定義して、型レベルでこのポリシーが保証されるようにしました。

継続性・保守性

運用コストと自立性

UI/UX

• 学内ツール感ではなく、企業の公式プロダクトサイト水準の体験を目指す。
• 強い視覚的アイデンティティ（カラートークン、タイポグラフィの意図）を定義する。
• 汎用テンプレート感の強い UI や単色ベタ背景を避ける。
• ロール別ダッシュボードで情報階層を明確化する。
• モーションは目的ベースで最小限に。
• モバイルとデスクトップを同時に成立させる。
• アクセシビリティ（キーボード操作、フォーカス表示、コントラスト）を担保する。