あるNPO様からのご相談を受け、利用者は普段使っているLINEで本人確認しつつ、相談のやり取りそのものはプライベートなWeb画面で行うチャット型の相談システムを開発しました。

本記事では、「なぜLINE公式アカウントでは不十分だったのか」という設計の前提から、モダンな技術構成と実装の考え方までを整理して紹介します。

課題の深掘り：NPO特有の「心理的障壁」

ここでいう課題は、単なる「連絡手段が古い」ではなく、相談という文脈に特有の心理的・運用面の負担に焦点を当てています。

電話・メールの限界

電話は同期コミュニケーションの負担が大きく、メールは往復に時間がかかります。いずれも「今すぐ相談を始める」までのハードルが高くなりがちです。

SNS（LINE公式アカウント等）だけに寄せた場合の懸念

友だち追加は導線として強力ですが、利用者によっては「つながりっぱなし」への抵抗や、トーク上に履歴が残り続けることへの不安があります。また、運営側としても、分析や業務フローに合わせた画面設計を公式の枠だけで完結させるのは難しい場面があります。

今回の切り分け

「いつものLINEで本人確認できる」一方で、相談の本文・履歴・運用は、団体が管理するWebアプリケーション側に集約する構成にしました。LINEはあくまで「入口と通知の補助」、相談の主戦場はブラウザ上、という役割分担です。

技術選定の「なぜ」：意思決定のプロセス

LINEアカウント連携 vs ID／パスワード

相談者に新規アカウントの発行やパスワード管理を求めると、離脱とサポートコストが跳ね上がります。スマホで慣れ親しんだLINEで本人確認できるようにすることで、「まず相談室に入れる」ことを最優先しました。

Next.js（App Router）

相談員向け管理画面と利用者向け画面を同一リポジトリで保守しやすくするため、App RouterベースのNext.jsを採用しました。ルーティングとAPIをまとめやすく、今後の機能追加（アンケート、フォローアップ、通知連携など）にも伸ばしやすい構成です。

Supabase（PostgreSQL を中心としたBaaS）

相談案件・メッセージ・アンケート回答などをリレーショナルに整理しつつ、相談員向けには別系統の認証（例：OAuth）を載せる、といった二種類の利用者を同居させやすい点が魅力でした。

• データ分離とポリシー
  マルチテナントに近い性質を持つ相談データでは、Row Level Security（RLS）で「誰の行を誰が読めるか」をDBレベルでも縛れることが、NPO案件における信頼説明として有効です（アプリ側のバグや漏れを補う最後の砦、という位置づけ）。
• リアルタイム性の取り方
  本件では、メッセージの反映は短い間隔のポーリングとし、既読の更新や一覧の定期更新で「置いていかれない」体験を優先しました。負荷・実装コスト・運用のバランスを見た選択であり、必要になればWebSocketやRealtime購読へ拡張する余地はデータモデル上残しています。

システムアーキテクチャ（概念図）

レイヤ	採用技術（概要）
フロントエンド	Next.js、Tailwind CSS
バックエンド	Next.js の Route Handlers、Supabase（PostgreSQL）
利用者認証	LINE（LIFF を入口にした本人確認・ユーザー紐づけ）
相談員認証	Supabase Auth（例：Google OAuth）
デプロイ	Vercel
通知（任意）	メッセージ到達時の外部Webhook通知、LINE Push など

こだわった「UXデザイン」

アクセシビリティと認知負荷

精神的に負荷が高い状況では、装飾より迷わない導線・短い文言・一画面での完結が効きます。相談員側も、案件・履歴・申し送りを同じ画面から辿れるよう情報設計を整えました。

プライバシー・ファーストの考え方

例として、利用者がLINEのトークに直接長文を送ってしまうケースへの備えとして、トーク上の本文をそのまま相談DBに積み増さないなど、どこに「正」の履歴を置くかを最初から決めました（運用ルールとセットで説明できることが重要です）。
アンケートやフォローアップのデータは、目的に応じた保存項目に絞り、不要な収集を避ける方針です。

開発を通じて得た知見：独自開発の価値

運用に効く「状態」と、それを扱う専用画面

汎用チャットSaaSでは表現しきれない相談業務の語彙——案件の開閉、担当者、重要度、未読、申し送りなど——を、データモデルとして整理したうえで、相談員向けの管理画面にそのまま落とし込みました。
「一覧で状況が一目で分かる」「チャットを開きながらアンケートや申し送りを見られる」といった業務フローに沿ったUIは、パッケージ品の設定だけでは難しく、専用実装の強みが出やすい部分だと実感しました。

拡張の余地

夜間や休日の一次応答を、将来的に外部の対話型AIサービスとAPI連携で補う、といった拡張も、メッセージと案件が自前スキーマにあることで検討しやすくなります（人間の相談員の判断を置き換えるのではなく、トリアージやFAQ寄りから始める想定が現実的です）。

計測と改善

友だち追加や初回接点の経路把握は、公式側の分析と、自前の初回アクセス情報・Webhookログとを役割分担させると、現場の「どこから来た相談か」が説明しやすくなります。

まとめ・お問い合わせ

既製のSaaSでは「あと一歩届かない」現場要件に対し、フルスクラッチに近い柔軟さで、かつ保守可能なモダンスタックで応える形にまとめました。

NPO、医療、福祉など、デリケートなコミュニケーションとデータ取り扱いが前提となる現場のシステム設計・開発を行っています。同種のご相談は、お気軽にお問い合わせください。