主催のTech.Uniってどんな団体？#

Tech.Uniさんは、全国から集まった学生同士が出会える場所をコンセプトにした学生エンジニア団体です。
2020年10月26日に設立されて、メンバーは約200名もいるそうです。
関西学院大学の社会連携センターが広報支援をしていて、顧問や技術アドバイザーにも関西学院大学の先生がついています。

MVVはこんな感じでした。

• Mission：楽しみ，つながり，築く
• Vision：テクノロジーを用いて新たなサービスを作りたい積極性のあるメンバーが、十二分に力を発揮できる組織を作る
• Value：Be innovate / Be active / Be responsive

ハッカソン以外にも、いろいろなイベントを開催しています。

• AIディアソン2026：ChatGPTやv0を使って、アイデア出しからアプリ開発、成果発表までを1日で体験する1dayものづくりイベント
• AIネタナイト2026：watnowさん、PKSHA Technologiesさんと共同開催した、関西の学生エンジニアによる交流イベント
• サイボウズ勉強会：サイボウズの大阪オフィスを貸し切っての勉強会
• STORESオンライン勉強会：エンジニアを目指す女子学生向けのオンライン勉強会

他にも、メンバー向けにTechTrain、Udemy、Progate、paizaなどの学習ツールを使える独学支援や、オンライン勉強会、外部勉強会への参加といった学習支援もしているみたいです。
有料コンテンツを団体で購入しているものもあるらしく、学生にとってはかなりありがたい環境だと思います。

スポンサー#

会場は2日間とも企業さんのオフィスをお借りしていました。

• 会場協賛：株式会社ストライク（9/20）、サイボウズ株式会社（9/27）
• 運営サポート・企業賞：株式会社TechBowl
• 企業賞：シナジーマーケティング株式会社

1. 立てる（主催者）#

タイトルと候補日を書くだけでLT会を作れます。入力するたびに、横の稲妻が充電されていきます。

2. 集まる（参加者）#

主催者が共有URLを送ると、参加者はログインなしで ○△× を回答できます。

3. 決まる（主催者）#

候補日ごとの人数を見て「この日に決定」を押すと、回答した人に通知が届きます。Discordに自動で投稿することもできます。

他にも、タグ・キーワード・開催形式（オンライン / オフライン）での検索、ユーザーのフォロー、公開プロフィール、登壇・聴講の参加表明、みんなのカレンダー、団体（サークル・研究室）ごとの管理などの機能があります。

触りたくなる仕掛け#

審査項目に「オモシロさ」があったので、触ってみたくなる小さな仕掛けも入れました。

• 読み込み中は、ハリネズミが稲妻を充電して、満タンになると跳ねる
• 見出しのアイコンがカーソルから逃げる
• ○△× を選ぶと、その色の輪が広がる
• 動きが苦手な人はOFFにできて、OSの「視差効果を減らす」設定にも従う

フロントとバックを分けた理由：Webとスマホの両方に対応するため#

このアプリは、まずWebアプリとして作って、将来的にはスマホアプリにも展開する前提で設計しました。
なので、LT会の作成・日程調整・フォローといった業務ルールとデータは全部NestJSのAPIに集めて、WebとスマホのどちらからでもAPIを使える形にしています。

その上で、Webの画面とNestJSの間には、Next.jsをBFF（Backend For Frontend）として挟んでいます。

Webブラウザ ⇄ Next.js（Web用のBFF） ─┐
                                     ├→ NestJS（共通のAPI） → PostgreSQL
スマホアプリ（今後） ────────────────┘

Next.jsだけでも、Route HandlersでAPIを作ることはできます。
ただ、それだとスマホ向けのAPIがWebの画面のコードと同じ場所に混ざってしまい、Webの都合（Cookieや、画面ごとのデータの形など）がAPIに入り込みやすくなります。
NestJSを独立させて、Webの都合はBFFのNext.jsに閉じ込めることで、NestJSはどのクライアントからも使えるシンプルなAPIのままにできます。
スマホアプリを作るときも、NestJSのAPIはそのまま使えて、スマホ側の都合はスマホ側（必要ならスマホ用のBFF）で引き受ければいい、という形です。

TechBowlの方に褒めていただいたのも、まさにこの「スマホとWebの両方に対応するために、BFFを挟んでNestJSにつなげる」ところでした。

また、フロントとバックが分かれているので、画面を作る人とAPIを作る人が並行して開発しやすいのもメリットでした。
APIの形さえ決まっていれば、お互いを待たずに進められます。

その代わり、分けるとこんなコストがかかります。

• デプロイ先が2つになる
• CORSや、オリジンをまたいだ認証（Cookieやトークン）を自分で扱う必要がある
• フロントとバックで型定義が二重管理になりやすい

なので、このコストをそれぞれ潰す形で構成を決めました。

BFF構成：ブラウザからNestJSを直接叩かない#

ブラウザはNext.jsとだけ通信して、NestJSのAPIはNext.jsのサーバー側（Server Component / Server Function）からだけ呼ぶようにしました。
APIを呼ぶ処理は apiFetch という関数1つにまとめています。

// apps/web/src/lib/api.ts（抜粋）
import 'server-only';

export async function apiFetch<T>(path: string, init: ApiFetchInit = {}): Promise<T> {
  // ...
  if (auth) {
    const token = (await cookies()).get(TOKEN_COOKIE)?.value;
    if (token) headers.set('Authorization', `Bearer ${token}`);
  }
  const res = await fetch(`${API_URL}${path}`, { ...rest, headers /* ... */ });
  // ...
}

こうすると、

• ブラウザから見るとNext.jsしかいないので、CORSの設定がいらない
• JWTはNext.js側のhttpOnly Cookieに入れておけるので、ブラウザのJavaScriptからトークンが見えない
• NestJSはCookieを扱わず、Authorization ヘッダーのトークン（Bearer）だけを見るので、スマホアプリからも同じAPIをそのまま使える
• import 'server-only' を付けているので、間違ってクライアント側から呼ぶとビルドで気づける

というメリットがあります。
上のコードで、Cookieからトークンを取り出して Authorization ヘッダーに付け替えている部分が、まさにBFFの仕事です。

monorepo + 共有パッケージ：型を1か所に#

APIのリクエスト/レスポンスの型と列挙値は packages/shared に置いて、webとapiの両方からimportしています。
APIのレスポンスを変えたらweb側で型エラーになってすぐ気づけるので、4人で別々の機能を触っていても、フロントとバックの食い違いが起きにくくなります。

NestJSの中は Controller → Service → Repository の3層#

NestJS側は、レイヤードアーキテクチャで3層に分けました。

例えば、フォロー機能のServiceはこんな感じです。

// apps/api/src/modules/follows/follows.service.ts（抜粋）
async follow(followerId: string, followingId: string): Promise<void> {
  if (followerId === followingId) {
    throw new BadRequestException('自分自身はフォローできません');
  }
  const target = await this.users.findById(followingId);
  if (!target) {
    throw new NotFoundException('ユーザーが見つかりません');
  }
  await this.follows.upsertFollow(followerId, followingId);
}

「自分自身はフォローできない」「存在しないユーザーはフォローできない」といったルールはServiceに書いて、実際にDBに書き込む部分（Prismaの upsert）はRepositoryに任せています。
Controllerは受け取ったリクエストをServiceに渡すだけです。

実は、Repositoryを置くかどうかは設計を見直すときにも検討しました。
Prisma自体がDBアクセスを抽象化してくれているので、Repositoryを挟むと「Prismaを呼ぶだけのメソッド」が増えがちだからです。

それでもRepositoryを置いたのは、

• Serviceに PrismaService を直接注入しないので、ServiceのユニットテストをDBなしで書ける
• DBの型をそのまま返さず、*.mapper.ts で packages/shared の型に変換してから返すので、メールアドレスのような本人以外に返してはいけない情報が外に出にくい
• 機能ごとにNestJSのモジュール（events、responses、follows、notifications など）を分けて、どこに何を書くかが全員同じになる

からです。

ルールを文書にして、人もAIも同じルールで書く#

最後に、決めた構成を文書に残して守るようにしました。

• READMEに「APIを足すときは apps/api/src/modules/<機能>/ に module / controller / service / repository を追加して、レスポンス型は packages/shared に置く」のような開発の流れを書く
• 設計で決めたことと理由は docs/open-questions.md に記録して、あとから蒸し返さない
• Claude Code向けの CLAUDE.md にも「BFF構成」「APIの3層」「型は packages/shared」を守る約束として書いて、AIにも同じルールでコードを書かせる

4人＋AIで31個のPRを並行してマージしていくので、どこに何を書くかを全員で揃えておくことを大事にしました。