## プロジェクト概要
- **サービス内容**: 会議のリアルタイム文字起こし・AI議事録自動生成を提供する法人向けSaaS
- **期間**: 2025年10月〜現在(継続中)
- **規模**: 0→1の新規立ち上げ
## チーム構成
- フルスタックエンジニア: 3〜5名
- **自分の役割**: サブリーダー(途中からリーダーと同等の役割を担当)
## 使用技術
- **言語**: TypeScript
- **フロントエンド**: Next.js, HeroUI, Tailwind CSS
- **バックエンド**: Hono, Socket.IO, Drizzle ORM
- **データベース**: PostgreSQL
- **インフラ**: AWS (ECS, ALB, RDS, S3, CloudWatch, WAF 等)
- **外部サービス**: Deepgram(リアルタイム音声文字起こし), ai-sdk(AI議事録生成)
- **認証**: BetterAuth(Google / Microsoft OAuth)
- **開発ツール**: Vitest, Docker, Docker Compose
- **AI**: Claude Code, Codex
## 担当領域
要件定義 / 設計 / 開発 / テスト / 保守運用 / コードレビュー
## 担当開発タスク(一部)
1. **認証基盤の構築**: Google/Microsoft OAuthによるソーシャルログイン、サインアップフロー
2. **リアルタイム文字起こし・議事録生成パイプライン**: 音声取得(getUserMedia/getDisplayMedia)→ リアルタイム送信(AudioWorklet+Socket.IO)→ 文字起こし・発話者紐づけ(Deepgram)→ AI議事録生成(ai-sdk)の全工程
3. **フロントエンド実装**: ルーム・ファイル管理・分析一覧等の各種画面
4. **ファイル管理**: S3アップロード/削除、プロジェクト紐付け
5. **インフラ整備**: AWSでのdev/prod環境構築、WAF/CloudWatch設定設計
6. **テスト基盤**: Vitest導入、Outside-In TDDの推進
7. **開発環境改善**: Claude Code / AIエージェント開発環境の構築
## 注力した取り組み
### 1. アーキテクチャ・ディレクトリ構成の設計
0→1の立ち上げで、かつAIエージェントによる開発を前提としていたため、誰が実装してもコード品質を維持できる構造が必要でした。
API側はレイヤードアーキテクチャ(Route → Service → Repository)を採用し、各層の責務を明確に分離しました。ルールベースで品質を担保できる設計にすることで、人間・AI問わず一定の品質で実装できる基盤を整えました。フロントエンドはfeatureベースのディレクトリ構成とし、機能単位でのコードの凝集性を高めました。
各層の責務やエラーハンドリング方針をドキュメント化し、新規参画メンバーが迷わず実装に入れる状態を整備しました。
### 2. AI駆動開発環境の構築・チーム展開
少人数チームで開発速度と品質を両立する必要がありました。また、新人エンジニアがレビューで同じ指摘を繰り返し受けることが他のプロジェクトでも問題視されており、この課題を仕組みで解決するためにAI駆動開発の導入に踏み切りました。
Claude Code / Codexを活用し、開発フローのほぼ全工程にAIを組み込みました。要件定義書の作成、設計の壁打ち、実装、コードレビュー、PR作成まで一貫してAIを活用する開発フローを確立し、チームに展開しました。
具体的には、プロジェクトの設計ルール・コーディング規約をClaude.mdやrulesとして整備し、AIが自動で読み込んだ状態で実装に入れる仕組みを構築しました。レビュー用のskillsには過去のレビュー指摘をナレッジとして蓄積し、PR提出前にAIが同じ観点でセルフチェックできるようにしました。また、git worktree runnerを導入し、作業中のブランチを中断せず複数機能の並行開発やレビュー対応ができる環境も整えました。
これにより、レビューで同じ指摘を2度受けることが0になり、チーム全体のコード品質と開発速度の両立を実現しました。
### 3. コア機能の設計・実装(音声取得 → 文字起こし → 議事録生成)
サービスのコア機能であるリアルタイム文字起こし〜AI議事録生成のパイプライン全体を設計・実装しました。
- **音声取得**: getUserMedia / getDisplayMediaを用いて、マイク音声・画面共有音声をブラウザ上で取得する仕組みを構築しました。
- **リアルタイム音声送信**: AudioWorkletで音声データを加工し、Socket.IOでサーバーとリアルタイムに双方向通信する基盤を実装しました。文字起こし結果を各クライアントに即時配信する仕組みも構築しました。
- **文字起こし・発話者紐づけ**: DeepgramのWebSocket APIによるリアルタイム文字起こしと、話者分離(Diarization)で識別されたSpeakerをアプリ上のユーザーに紐づける機能を実装しました。本番運用後に無音区間の重複保存が発生したため、無音判定の閾値調整と重複排除ロジックで解消しました。
- **AI議事録自動生成**: ai-sdkを用いて文字起こしデータからLLMで構造化された議事録を自動生成する機能を実装しました。専門用語の誤変換に対しては組織ごとの用語辞書をプロンプトに適用する仕組みで対応し、生成状態のポーリング制御とリトライ処理で安定稼働を実現しました。
### 4. PMの補助・チーム運営
プロジェクト初期は自分がアーキテクチャや基盤実装に集中しすぎた結果、リーダーに仕様確認・レビュー・スケジュール管理が集中してしまう課題がありました。この反省を踏まえ、途中からリーダーの負荷分散に動きました。
朝会・振り返り会の提案・運用、顧客との仕様MTGへの参加と直接確認、タスク分解・工数見積もりを自分が担当しました。コードレビューもリーダーから引き取り、他メンバーのレビューを担当しました。リリース作業やAWS環境構築など開発以外のタスクも自発的に担当し、リーダーがプロジェクト全体の推進に集中できる体制を作りました。
また、メンバー間でコミュニケーション上の摩擦が生じた際には双方の意見を聞いて間に入り、チームが分断しないよう調整役を担いました。
## 技術選定(一部)
**Hono(Express ではなく)**
新規プロジェクトのAPIフレームワーク選定で、ExpressとHonoを比較検討しました。
Honoを選定した決め手は3点です。
1. **型安全性**: @hono/zod-openapiとの統合により、Zodスキーマをルート定義に紐づけるだけでリクエスト/レスポンスの型チェックとOpenAPIドキュメント自動生成が同時に実現でき、実装と仕様の乖離を構造的に防げます。
2. **パフォーマンス**: あるベンチマークテストの記事ではExpressの3倍以上のスループットが記録されています。リアルタイム文字起こしに求められる低レイテンシ要件に適合しました。
3. **AI駆動開発との相性**: AIエージェントによる開発を前提としており、型で制約をかけられるフレームワークのほうがAI生成コードの品質を担保しやすいと判断しました。
**Socket.IO(生WebSocket ではなく)**
リアルタイム文字起こし機能の通信基盤として、生WebSocketとSocket.IOを比較検討しました。
Socket.IOを選定した決め手は3点です。
1. **Room機能**: 会議室単位での参加者全員へのブロードキャストが標準で実現でき、ルーム管理を自前実装する必要がありません。
2. **イベント駆動モデル**: 音声バイナリと制御イベント(録音開始/停止、文字起こし結果配信等)が混在する要件に対し、イベント名で整理できます。Namespace(/transcribe)で関心の分離も可能です。
3. **自動再接続**: 会議中のネットワーク切断時に自動復帰でき、ユーザー体験を損ないません。