開発中 · 2026.12予定

Lingding

韓国人と日本人の学習者をつなぎ、1対1音声会話まで支援する言語交換アプリです。

韓国人と日本人が相手を探し、実際の会話まで進める言語交換アプリです。1対1音声通話、Go WebSocketシグナリングサーバー、ICEサーバー構成、サービスの基本CRUD API設計を担当しています。

マッチングした二人を実際の会話へつなぐ機能

Lingdingは、韓国人と日本人の学習者が相手を探し、会話を通じて互いの言語を学ぶアプリです。プロフィールやマッチングだけでは交流が始まらないため、アプリ内でそのまま1対1音声通話へ進める機能が必要でした。

私は通話機能全体に加え、Goシグナリングサーバー、ネットワーク環境に応じた接続経路を提供するICEサーバー構成、サービスの基本CRUD API設計を担当しました。

1対1通話

サーバーが二人を案内し、音声は端末間を流れる

プロフィールやマッチングのCRUDはレスポンスを返すと終わりますが、通話は終了までルーム、二つのWebSocket、Offer・Answer・ICE候補の順序を保持します。

二つのクライアントではルーム参加、Offer、Answer、ICE候補の到着順がずれることがあります。相手がいない状態、重複接続、切断後のメッセージも、通常のリクエストエラーとは別に扱う必要がありました。

通常のデータ処理はHTTP CRUDに残し、ルームとシグナリングイベントはGo WebSocketで管理しました。メッセージ種別とルームのライフサイクルを明示し、両クライアントが同じ通話状態を見ることをサーバーの責任にしました。

Go WebSocketサーバーでルーム参加、シグナリング中継、切断時解放を実装し、Flutterの1対1通話フローと接続しました。実環境の同時接続数やイベント遅延はまだ測定していません。

リアルタイムサーバーでは、一回のリクエストではなく接続全体の状態・イベント順序・終了処理を設計する必要がありました。

異なるNAT・ファイアウォール環境では端末同士が直接接続できず、TURNリレーが必要になる場合があります。しかし固定認証情報をモバイルアプリへ入れると、配布後も取り出して再利用できます。

初期要件は1対1音声であり、独自TURNサーバーを運用するより管理型サービスを使う方が範囲に合っていました。一方、認証情報の発行と費用統制をクライアント任せにはできませんでした。

STUNによる直接接続を優先し、必要な場合だけCloudflare TURNをフォールバックとして使いました。TURN認証情報はアプリへ固定せず、サーバーがCloudflare APIから短期認証情報を発行する境界を設けました。

短期認証情報発行とクライアント適用まで実装しました。実ネットワーク別のTURN使用率、認証情報発行レート制限、費用はまだ検証していないため、現時点では運用成果ではなく実装結果として記載しています。

クライアントへ渡す秘密情報は隠すだけでなく、寿命と発行主体、利用範囲をサーバー境界で管理する必要があると学びました。

Flutterの1対1音声通話、Go WebSocketシグナリングサーバー、STUN/TURNを含むICEサーバー構成、基本CRUD API設計を実装しています。

CRUD APIではリクエストごとの処理を考えていましたが、リアルタイム機能では接続中の状態とイベント順序、切断後の整理までサーバーが継続して管理する必要があると学びました。

Lingdingの実環境では、負荷、接続成功率、通信の遅延（レイテンシ）、長時間通話をまだ測定しておらず、実利用者の指標もありません。2026年12月は確定した公開日ではなく、現時点での予定です。