DiSA公式 ウェブ用語辞典 システム開発
Web業界で使われる用語を定義・統一するオンライン辞典プロダクトです。 同一用語でも職種によって意味が異なる「認識のズレ」を解消し、新人の学習・クライアント説明・チーム内認識統一を支援します。 要件定義・コンテンツ設計・UXモック・実装を主担当し、UIデザイナー1名との協業で制作しました。

- ジャンル
- Webシステム
- 制作期間
- 約2ヶ月
- 納品日
- 2026.06
プロジェクト概要
項目 | 内容 |
|---|---|
プロジェクト形態 | 一般社団法人ディレクションサポート協会(DiSA)の自社プロダクト |
規模 | TypeScript/TSX ファイル 106 本 / 約 13,400 行、コミット数 139+ |
チーム構成 | 開発2名(エンジニア・UIデザイナー)+PM1名+コンテンツレビュアー複数 |
役割 | フルスタックエンジニア兼コンテンツ設計 |
背景・課題
Web業界では同じ用語が職種によって異なる意味を持つことが多く、チーム内の認識ズレやクライアントとのコミュニケーションコストが継続的な課題になっています。社団法人として「業界標準の用語集」を公開する構想はあったものの、既存のWikiツールや辞書サービスでは以下の要件を満たせませんでした。
- 職種ごとに異なる意味を、1 つの用語エントリの中で整理できない
- 「クライアントへの伝え方」のような実務視点の定義を付加できない
- 複数メンバーによる執筆・監修・承認のワークフローを管理できない
解決方針
専用Webアプリを構築しました。1つの用語に対して「広義 / 狭義」「利用文脈の違い」「目的・役割の違い」などの角度から複数の定義と「クライアントへの伝え方」を個別に持てるデータ構造を設計し、2人チェック制のレビューワークフローで品質を担保する仕組みを組み込んでいます。また、AIを活用した用語データ生成ツールを管理画面に内包することで、コンテンツの追加効率も向上させました。
技術スタック
フロントエンド
- Next.js 16 (App Router) — Server Components を積極活用
- React 19
- TypeScript 5 — 厳密な型付け、
anyは原則禁止 - CSS Modules — 公開ページ(Tailwind 不使用・UI 自由度確保)
- Tailwind CSS v4 + shadcn/ui — 管理画面(SaaS ライクなデザイン)
バックエンド / インフラ
- Supabase (PostgreSQL / Auth / Storage / Row Level Security)
- Vercel — Hosting
- Google Analytics 4 — カスタムイベント計測
- Google Search Console — SEO・サイト所有権確認
外部連携
- Google OAuth (Supabase Auth 経由)
- Slack Incoming Webhook — 編集ワークフロー通知
- Anthropic API — 用語データ AI 生成
主要ライブラリ・拡張
@supabase/ssr— Server Components 対応認証クライアント
技術的なハイライト
1. published_snapshot による公開継続
「レビュー中も旧内容を公開し続け、承認時に新内容へ切り替える」というビジネス要件を実現するために、承認・再公開時に published_snapshot(JSONB)へ内容をスナップショット保存する設計としました。
ステータス | 公開ページの表示 | 表示する内容 |
|---|---|---|
| 非表示 | — |
| 表示 | スナップショット(旧内容) |
| 表示 | 最新内容 |
| 非表示 | — |
レビュー中に用語ページが消えないため、利用者体験を損なわずにコンテンツを更新できます。
2. 差し戻し先の動的復元
レビュー申請はどのステータス(published / unpublished / draft)からでも行えるため、差し戻し時の「戻り先ステータス」が固定できません。term_activities(操作ログ)を解析して申請前のステータスを動的に推定・復元する設計を採用しました。ログベースの状態復元により、フロー分岐を増やさずに差し戻しロジックをシンプルに保っています。
3. ロールベースアクセス制御 × Supabase RLS
4段階のロール(admin / moderator / editor / user)に応じた権限マトリクスを設計し、アプリケーション側の権限チェックに加えてSupabase RLSでDBレベルのアクセス制限も二重に担保しています。
editor: 用語の作成・編集・レビュー申請までmoderator: 承認・差し戻し・非公開化など編集ワークフローの管理admin: 完全削除・一括操作・メンバーロール管理
「アプリにバグがあってもデータが漏れない」設計になっており、権限マトリクスは REQUIREMENTS.md に一元管理してコードと乖離しないようにしています。
4. Slack 通知によるワークフロー可視化
レビュー申請・承認・差し戻し・非公開化・コメントの各アクションでSlack Incoming Webhookに通知を送信します。
通知には申請者・レビュアーへのメンション(Slack ユーザー ID)と公開ページへのリンクを含め、チャット上でワークフローの流れを追えるようにしました。
SLACK_WEBHOOK_URL 環境変数が未設定の場合は通知が無効になるため、ローカル開発環境には影響しません。
5. AI用語データ生成ツール
管理画面内にAIを使った用語データ生成ツールを実装しました(3ステップ・JSON出力)。用語名を入力するとプロンプトを組み立ててAnthropic APIを呼び出し、意味別定義・クライアントへの伝え方・関連用語などをJSONで出力します。出力したJSONはそのまま一括インポート機能に投入できる設計です。
コンテンツ品質の一貫性を担保するため、執筆ルール・意味の分け方の判断基準・NGパターンをプロンプトに組み込んでおり、このプロンプト設計も自分が担当しました。
6. リアルタイムプレゼンス
Supabase Realtimeを活用し、同じ用語を同時に閲覧・編集中のメンバーをリアルタイム表示する機能を実装しました。
複数人が同時に編集して内容が競合するリスクを、UXレベルで可視化しています。
コンテンツ設計
辞典コンテンツの構造設計も担当しました。
- 意味の角度分け(viewpoint): 1つの用語に対して「広義 / 狭義」「利用文脈」「目的・役割」など内容ベースの角度で複数の定義を持たせる構造を設計。「どの角度・粒度で意味を分けるか」の判断基準(split_logic)を言語化し、AIプロンプトと監修ガイドライン両方に反映しています。
- 「クライアントへの伝え方」フィールド: 定義文とは別に、専門知識のないクライアントへの説明文を独立したフィールドとして設計。辞典をクライアントワーク上の共通言語として使える実務的な価値を付加しました。
- 監修ガイドライン: 執筆基準・NGパターン・チェックリストを管理画面内の
/admin/guidelinesページとして整備し、メンバーが常に参照できる状態を維持しています。
UI/UXデザイン
公開ページ
私が作成したUXモックをベースに、UIデザイナーが視覚デザインを担当しました。画面構成・情報アーキテクチャ・操作フローなどUXの設計はモックからほぼそのまま採用されています。
- 実装: CSS Modules で実装。Tailwind を使わずUIの自由度を確保し、デザイナーの表現を制約しない方針を選択
- アクセシビリティ: セマンティックマークアップ・フォーカストラップ・
prefers-reduced-motion対応を全体に徹底
管理画面
UI/UXともに自分1人で設計・実装しました。
- 実装: Tailwind CSS v4 + shadcn/ui でSaaSライクな操作感を実現
- ボタンカラーの設計: アクションの性質(保存・申請・承認・差し戻し・削除)で5種類に分類し、色と輪郭(塗り/アウトライン)で「前進系」と「後退・破壊系」を視覚的に区別。誤操作を抑制する設計。
主な機能
公開ページ(一般ユーザー向け)
- 用語一覧(あいうえお順グループ表示)
- カテゴリ絞り込み・キーワード検索
- 用語詳細(意味別定義・クライアントへの伝え方・関連用語・監修者・リビジョン番号)
- 自動サイトマップ生成(公開状態の用語を自動収集・SEO対応)
- GA4カスタムイベント計測(用語閲覧・検索・カテゴリ選択・関連用語クリックなど)
管理画面(admin / moderator / editor)
- ダッシュボード(用語数・レビュー待ち件数・レビュー依頼一覧・DB 使用量)
- 用語CRUD(下書き保存・文字数カウント・未保存離脱警告)
- ステータス管理(draft → in_review → published の多段階フロー)
- リアルタイムプレゼンス(同じ用語を同時閲覧・編集中のメンバー表示)
- JSON一括インポート(重複・ID検証・結果レポート)
- AI用語データ生成ツール(3ステップ・JSON出力)
- メンバー管理(ロール変更・Slack ID設定)
- 操作ログ・監査ログ(全用語の履歴一覧・フィルター・ページネーション)
- 監修ガイドライン・マニュアルページ
設計上の工夫
コード品質
- TypeScript strict、
anyの使用を最小化 - Server Components / Client Components の責務分離を明確化(
"use client"は最小限) useSearchParams()を使うコンポーネントは<Suspense>でラップ- ESLintでコード品質を統一
ドキュメント
REQUIREMENTS.mdで要件・データ構造・権限マトリクス・ステータスフローを一元管理CLAUDE.mdでコーディング規約・設計方針を明文化supabase/ディレクトリでDBスキーマ変更履歴を管理- 機能追加時はドキュメントと実装を同時に更新するワークフローを徹底
今後の展開(実装予定)
- 失敗談・事例記事の登録と用語への紐付け
- 一般ユーザー登録(Google認証)・マイ用語機能
- 組織登録・メンバー招待・組織用語共有(フリーミアム〜組織プラン)
- 意味的検索サジェスト(pgvectorによるベクトル検索)
- バナー広告管理画面(広告CRUD・PV / クリック計測)
個人としての成果
- 要件定義・設計: 用語辞典に必要なデータ構造・ステータスフロー・権限設計を主導
- コンテンツ設計: 意味の角度の分け方・AI プロンプト・監修ガイドラインを策定
- UX 設計: 画面構成・操作フローを設計し、UI デザイナーへの引き継ぎを実施(UX はモックからほぼ変更なし)
- 実装: フロントエンド・バックエンド・DB・インフラ全領域を担当
- デプロイ・運用: 継続中、機能追加とバグ対応を担当
「レビュー中も公開を継続する published_snapshot パターン」「操作ログから差し戻し先を動的復元する設計」など、ビジネスフローの複雑さを技術的にどう整理するかを考え抜いたプロジェクトとなりました。
- コメント
- メンバーの負担を少しでも抑えて更新しやすいように、管理画面のUXや用語たたきデータ生成のクオリティを徹底的に詰めました。 もちろんエンドユーザーに使ってもらえないと意味がないので、どうすれば「使いやすい」「見やすい」「分かりやすい」と思ってもらえるか、公開ページ側のUXにもこだわりました。 DiSAの一員として信頼のおけるメンバーと一緒に業界をよくしたいという想いで開発しました。
- タグ
- フルスタック
- 管理画面
- UI/UXデザイン
- 担当
- 要件定義
- API設計
- コンテンツ制作
- デザイン
- コーディング
- 運用
- データ入稿
- ツール・技術
タップで名称を表示します
