Hun-Bot

通信会社の付加サービス照会
携帯電話番号で本人認証を行い、その番号に紐づく通信会社の付加サービスを照会するサービスの開発記

通信会社の付加サービス照会

telecom value-added-services

アイデア

このアイデアは「내 보험 찾아줌」というサービスを使っているときにふと思いつきました。住民登録番号、携帯電話番号、名前だけを入力すると、自分が加入している保険商品を一覧で確認できるサービスです。それと同じように、自分が加入している通信会社の付加サービスも一覧で確認できれば便利だと思いました。

たとえば、私がSKTを使っているとして、自分がどの付加サービスに加入しているのかわからない場合、Web上で「名前」と「携帯電話番号」だけを入力すれば、加入中のSKT付加サービスを一目で確認できるサービスを実装したいと考えました。

もちろん、T-worldにアクセスすれば加入中のサービスを確認できます。私もそうしています。ただ、T-worldに入るよりももっと簡単に付加サービスを確認できたらよいのではないかと思いました。

「名前」と「携帯電話番号」だけで照会できるのか調べたところ、それは不可能だそうです。本人認証手続きが必須であるため、韓国の通信MyData標準APIを確認しました。APIコードごとに通信会社の付加サービス照会APIが存在します。これを活用すれば、ユーザーが携帯電話番号で認証したあと、その番号の通信会社付加サービスを照会するサービスを開発できそうです。

照会して表示するだけで終わりなのか？ それだけだと少し物足りないので、RAG + チャットボット機能を付け、自分が加入している付加サービスをもとに質問すると回答してくれる機能を追加したいです。 料金プランも照会して推薦する機能まで作れば、かなり使えるサービスになりそうです。

3大通信会社ごとに付加サービスが異なるため、SKT、KT、LG U+それぞれのAPIを連携する手間があります。また、付加サービスに対するRAG機能を実装するには、付加サービスデータの収集と前処理も必要になります。

もしユーザーが集中してトラフィックが急増する場合に備えて、サーバーレスアーキテクチャで実装することも検討すべきです。AWS LambdaやGCP Cloud Functionsのようなサーバーレスプラットフォームを活用すれば、トラフィックに応じて自動で拡張されるため、安定したサービスを提供できるはずです。

まずは韓国の通信MyData標準APIを活用し、携帯電話番号で本人認証を行い、その番号の通信会社付加サービスを照会する機能から実装してみます。うまくいけば、その次に解約機能と詳細説明機能も追加してみます。

初期開発計画

前置きが少し長くなりましたが、まとめると、**「携帯電話番号で本人認証を行い、その番号の通信会社付加サービスを照会・推薦するサービス」**を開発することが目標です。

CategoryTech選定理由
LanguagesTypeScript & PythonWeb/API全体の型安全性を確保するTypeScript、LangGraphベースの複雑なAIオーケストレーションのためのPython。
FrontendNext.js 15+ (App Router)静的な通信料金プランページにServer ActionsとISRを適用し、高い性能を確保する。
Backend & AuthSupabasePostgres、Auth、RLSを統合提供するBaaSとして、機密性の高いMyData記録を最小設定で保護する。
Vector Databasepgvector (Supabase)既存のPostgres内で900以上のサービスRAGを可能にし、別途ベクトルDBを不要にする。
AI OrchestrationLangGraph状態ベースの多段階推論で利用ログ分析と数百通りの「無駄指数」計算を行う。
LLM & SDKsLLM / GPT-4o minisLLM構築とVercel AI SDKのモデルルーティングにより、追加作業をGPT-4o miniへ送る。
InfrastructureVercel (Edge Functions)200-500ms程度のほぼ小さいコールドスタートでグローバルなサーバーレス実行を行い、トラフィックスパイクに強くする。
Caching & ScalingUpstash (Redis)グローバルレート制限とプロンプトキャッシュでLLM費用の急増を防ぐ。
AI ObservabilityLangfuseユーザー別LLM費用追跡、エージェント判断段階のトレース、推薦理由のデバッグに必須。
System MonitoringSentryサーバーレス関数とフロントエンドクラッシュの自動エラー追跡により、個人運用の可用性を確保する。
Development MethodGitHub Spec KitSpec-Driven Developmentでアーキテクチャ上の開発目的と一貫性を維持する。
Data & SimulationMockoon & SmartChoice APIMockoonで2026 MyData標準API（通信-001/003）を模擬し、SmartChoice APIでリアルタイム料金プランデータを提供する。

アーキテクチャ図

通信会社付加サービス照会サービスのアーキテクチャ図

<以下の文章はAIの助けを借りて作成しました。>

Add-on Doctor v1 アーキテクチャ概要

  1. 個人情報のセキュリティ: MyDataの原本は制限された保存領域にのみ置き、LLM/RAGレイヤーには非識別化・要約済みデータだけを渡す。
  2. sLLM優先、クラウドLLM補助: 主な推論は自前ホスティングのsLLMが処理し、複雑なリクエストだけ商用LLMへフォールバックする。 （そうしないと費用を負担できなさそうなので、実サービスではこの機能を制限するか、ユーザーに課金する方法を検討する）
  3. 運用効率: 運用複雑度を最小化するため、S3 + ローカルベクトルストア（Chroma） + サーバーレスフロントエンドを使う。

Front End: Vercel + Next.js + Redis

  • フロントエンドは Next.js (App Router) をVercelへデプロイする。

機能:

  • ユーザー入力の収集: 通信会社選択、付加サービス一覧確認リクエスト、分析実行ボタンなど
  • API Routes / Server Actions:
    • 通信MyData API呼び出しトリガー
    • SmartChoice API呼び出しトリガー
    • LangGraph分析API呼び出し（/api/analyze_addons）

ここではログイン機能を使わない。 リクエストごとにsession_idを生成し、そのセッションに対する分析を一度だけ実行して、結果をすぐに表示する単発構造にする。 画面はよく使われる簡単認証の形にし、ユーザーの通信会社に応じたデータを取得して表示したあと、ユーザーが分析ボタンを押すかチャットボットをクリックしたときだけ追加機能を実行する。

Upstash Redis (Rate Limit & Prompt Cache)

  • Edgeに近いサーバーレスRedisとして、2つの用途で使用する。
    1. Rate Limit: IPまたはsession_id基準で分析リクエスト回数を制限し、LLM費用の暴走を防ぐ。
    2. Prompt Cache:
      • 同じ付加サービス組み合わせと料金プランに対する再分析リクエストが入った場合、LLMを再度呼ばずにキャッシュ済み結果を返す。

Storage & Metadata: AWS S3

S3はサービスの**「原本データ保存所」**の役割を持つ。

  • 保存するデータ:
    • 通信3社の付加サービス説明、料金プラン案内書、ポリシー文書（HTML、Markdown、JSONなど）
    • 付加サービスマスターテーブル（サービス名、カテゴリ、月額料金、通信会社など）
    • モデル関連リソース（例: プロンプトテンプレート、ドメインルール定義）
    • 分析レポートスナップショット（任意: reports/{session_id}.json形式）

ここまで保存する価値があるかどうかは、開発しながら判断する必要がありそうです。

External Services: MyData API + SmartChoice API

通信MyData API

  • ユーザー同意を前提に、通信-001/003などのMyData標準APIを通じて:
    • 加入情報（通信会社、料金プラン名、約定/結合商品など）
    • 請求内訳（月別付加サービス請求項目/金額）を取得する。
  • このデータはS3/内部ストレージにsession_id基準でのみ保存し、LLM側には非識別化された要約だけを渡す。

SmartChoice API

  • 韓国通信事業者連合会（KTOA）が運営する料金プラン・付加サービス推薦open APIを使用する。
  • 役割:
    • 現在の加入料金プランと利用パターンを基に、公共ポータル基準の「料金プラン推薦結果」を受け取る。
    • sLLMが作成した推薦とクロスチェックしたり、代替料金プラン候補リストを補強したりする。

AI Orchestration & Observability: LangGraph + Chroma + Langfuse

LangGraph Orchestrator

LangGraphはPythonベースのエージェント/ワークフローオーケストレーションレイヤーとして使う。

  1. Next.jsが/api/analyze_addonsへリクエストを送ると、LangGraphに次の情報を渡す。[session_id, 要約済み加入情報/請求内訳]
  2. LangGraphは3段階で分析する。
    1. 前処理 & 非識別化
      • 通信-001/003の原本から必要なフィールドだけを抽出し、要約構造にする。
        例: {carrier, plan_name, addon_list[], monthly_addon_total}
      • 名前/電話番号/住民番号などの識別子はLLM/RAG入力から除去する。
    2. RAG + ルールベース判断
      • Chromaへ問い合わせ、付加サービス説明/ポリシー/代替オプションを取得する。
      • 料金プラン基本特典と有料付加サービスの重複有無など、単純なルールベースチェックも併用する。
    3. LLM呼び出し
      • sLLMにコンテキストを渡し、「解約/維持/条件付き維持 + 理由 + 予想節約額」を生成させる。
      • 必要であればクラウドLLMへフォールバックし、自然言語レポートをより滑らかに整える。

Chroma (Local RAG Index)

  • RAGインデックスはChromaを使い、LangGraphプロセスの横に配置する。
  • 初期化時:
    1. S3から通信3社の付加サービス文書をロードする。
    2. 埋め込みを生成し、Chromaコレクションにupsertする。
  • クエリ時:
    • 「スマートコールキーパー」、「Vカラーリング」、「PASS 전월세 안심케어」など、該当サービス名/キーワードを基準にtop-k文書を検索し、LLMコンテキストとして使用する。

Langfuse (LLM Trace & Costs)

  • すべてのLLM呼び出し/チェーンステップはLangfuseに記録する。
    • session_idまたは非識別化user_id基準でTraceをまとめる。
    • トークン使用量、費用、遅延時間などをモニタリングする。
  • この情報は:
    • 費用暴走の検知
    • プロンプト/チェーンチューニング
    • 「なぜこの推薦が出たのか」の説明（デバッグ/説明可能性）に活用する。

LLM Layer: sLLM + Vercel AI SDK

Local sLLM

  • 主推論エンジンは自前ホスティングsLLMである。
    • vLLM/Ollamaなどでサービングされる韓国語に強いモデル、たとえばK-EXAONE系、A.X系、Solarなどを使用できる。
  • 役割:
    • 付加サービス一覧/料金プラン/SmartChoice結果/Chromaコンテキストを受け取り:
      • 「解約/維持/条件付き維持」分類
      • 項目別説明
      • 簡単な要約レポート を生成する。

Vercel AI SDK + GPT-4o mini (Fallback)

  • より複雑な自然言語レポートや、sLLMが自信を持てないケースだけ、Vercel AI SDK経由で GPT-4o mini / Claude などの商用LLMを呼び出す。
  • LangGraphでフォールバック条件を定義する:
    • レポートが長くなる必要がある場合
    • 多言語説明が必要な場合
    • 内部評価スコアが低い場合など

Observability & Error Tracking: Sentry

  • Next.js/Vercel、LangGraph、sLLMゲートウェイで発生するエラーと警告はすべてSentryへ送信する。
  • 主な目的:
    • 外部API失敗（MyData/SmartChoice）
    • LLM呼び出し例外
    • 性能低下/タイムアウト
    • フロントエンド実行時エラーモニタリング

個人情報セキュリティ

  • MyData原本（通信-001/003 JSON）、名前/電話番号などはS3/内部ストレージにのみ保存し、LLM/RAGレイヤーには構造化された要約データだけを渡す。
  • セッション識別はsession_idで行い、一定期間が過ぎたらMyDataスナップショットとレポートを削除するTTLポリシーを置ける。
  • Langfuse/Sentryには非識別IDとメタデータのみを残し、機密性の高い原文は残さない。

おわりに

追加で思いついたロジック:

  • API呼び出し制限のため、API呼び出しログを画面に表示する機能。

これ以外には、この文章を書いている時点で思いつく追加実装アイデアはありません。実装しながら思いついたら、そのとき追加します。

Add-on Doctor 1 / 1
이전 편 없음
다음 편 없음

目次

댓글