LLMView

AIの思考が『のぞける』『さわれる』教育アプリ

2025年7月〜現在（WebApp OpenBetaの途中）

🏆 U22プログラミング・コンテスト（U22procon）経済産業大臣賞（LLMView）

デモサイトを見る

スライドを見る

なぜ作ったのか

生成AIが普及する中、多くの人がAIを「魔法のように文章が降ってくるツール」として認識していて、AIの裏側で起きている「確率的な迷い」や「推論の過程」は見えていません。 AIを「いじる」という体験を通じて、AIへの本質的な理解を深めていけるような、初学者にも敷居が低くAI教育の最初の一歩となるサービスを目指して作りました。 LLMViewは、U22プログラミング・コンテスト（U22procon）2025で経済産業大臣賞<アイデア>を受賞しました。

主な機能

1 AIの推論過程をリアルタイムで可視化する思考ツリー
2 確率の分岐点に自ら介入し、『IF（もしも）』の世界線を切り拓く操作機能
3 チャット画面から裏側のツリーをのぞく、直感的なUI/UX

技術構成

フロントエンド

React

コンポーネントベースの開発と豊富なエコシステム。WebView内で動作するUI層を構築

TypeScript

型安全性による開発効率の向上と、大規模開発での保守性確保

バックエンド（第1層）

Rust

FrontendとLLM層を繋ぐブリッジとして、高速なプロセス間通信を実現

Tauri

デスクトップアプリとしての配布と、RustとReactの統合。さらにはスマホ向けアプリやWebアプリへの転換が容易なアーキテクチャ

バックエンド（第2層）

Python

LLMモデルの実行環境として、豊富なライブラリエコシステムを活用

llama-cpp-python

Llamaモデルの実行と次トークン確率の取得

fugashi

日本語の形態素解析による単語の確定判定

システム構成

図を読み込んでいます...

こだわり・苦労した点

開発中に直面した課題と、それを解決するためのアプローチ

日本語のトークン化問題

Challenge #1

チャレンジ

LLMが日本語を扱う際、トークンは「単語」ではなく「文字」単位（例：`高`→`さ`→`は`）で生成されることが多く、そのままツリー表示しても見にくくなってしまうという問題がありました。英語のように空白で区切られた言語なら開発は簡単ですが、日本語では一筋縄では行きません。 AIの出力は「コナ、ン、は、名、探、偵……」のように1-2文字程度のトークンごとに生成を行います。これをそのままツリーにすると、枝分かれが無意味に増え、人間には読みにくいグラフになってしまいます。

解決策

1 プロンプト構築と初期トークン取得: ユーザーからの「質問」と「生成途中の文章」を組み合わせ、会話形式のプロンプトを動的に生成し、次に続く全トークンの確率リストを取得します。
2 優先度付きキューによる単語探索: 取得したトークンと確率のタプルを優先度付きキューに格納し、確率の高い候補から順に取り出して探索します。結合後の文章で再度LLMに次のトークンを予測させ、元の確率と新しい確率を掛け合わせてより長い単語候補を生成します。
3 fugashiによる単語の確定: 形態素解析ライブラリ`fugashi`を用い、「(生成途中文章 + 新トークン)」の形態素数と「(生成途中文章)」の形態素数を比較します。この差が`2`になった瞬間、先行する単語を次単語として確定させます。
4 エントロピーによる最適化: AIが出力する「次トークンの確率分布」のエントロピーを判定に使用します。エントロピーが低いなら「まだ単語の途中」、高いなら「単語の切れ目」として判定し、計算コストの重い形態素解析の前段に挟むことで、精度と速度を両立させます。

code

# 優先度付きキューによる探索
import heapq

def explore_word_candidates(prompt, max_candidates=50):
    queue = []
    # 初期トークンと確率を取得
    tokens = get_next_tokens(prompt)
    
    for token, prob in tokens:
        heapq.heappush(queue, (-prob, prompt + token, [token]))
    
    candidates = []
    while queue and len(candidates) < max_candidates:
        neg_prob, current_text, tokens = heapq.heappop(queue)
        
        # 単語確定判定
        if is_word_complete(current_text):
            candidates.append((current_text, -neg_prob))
        else:
            # 次のトークンを取得して探索を続ける
            next_tokens = get_next_tokens(current_text)
            for next_token, next_prob in next_tokens:
                new_prob = -neg_prob * next_prob
                heapq.heappush(queue, (-new_prob, current_text + next_token, tokens + [next_token]))
    
    return candidates

学び

ストリーミングデータを扱う際の「遅延評価」の重要性を感じました。先読みができない状況で、限られたデータの中で適切なバッファリングと判定ロジックを用いてうまく単語判定をすることができました。また、アルゴリズムレベルでの最適化（エントロピー判定による形態素解析のスキップ）により、「正確性」と「リアルタイム性」の二兎を追うようなアプローチを実現できました。

アーキテクチャ設計の柔軟性

Challenge #2

チャレンジ

将来の拡張性を見据えスケールしやすいアーキテクチャを取る必要がありました。WebApp化、スマホアプリ、Desktopアプリなど様々なプラットフォーム、用途に対応したサービス展開を見据える必要がありました。

解決策

1 疎結合アーキテクチャ: バックエンドの構成を「スイッチ」することが可能になります。現在はRustとTauriを使った「デスクトップアプリ」の構成ですが、Webサービス化したくなれば、バックエンドのGPUサーバーを増設するだけで、フロントエンドのコードは1行も書き換える必要がありません。
2 実装効率の最大化: UI資産を共通化し、一度の開発で全プラットフォームに対応できます。
3 運用コストの最適化: サーバーの増設だけでサービス規模を自在にコントロールできます。
4 デプロイ戦略: マルチプラットフォームにアプローチできるので、ユーザーに合ったサービス展開が可能です。

学び

個人開発のスピード感と、将来的なビジネス拡張性。この二つを両立させるための戦略的なエンジニアリングの重要性を感じました。疎結合な設計により、将来の変更に対して柔軟に対応できます。

今後の展望

1WebAppの正式リリース
2より多くのLLMモデルへの対応
3モバイルアプリ版の開発
4教育機関向けの機能追加（授業での利用を想定）
5コラボレーション機能の実装（複数人でツリーを編集）