Skip to content

NEXUS AI Studio (Japanese)

Rich Dunbar edited this page Oct 23, 2026 · 4 revisions

Nexus AI

Version 25

English · Français · 日本語 · 한국어

ブラウザー試用版を開く · 完全版アプリをダウンロード · README

対応モデルを独自の WebGPU または Nexus.cpp 推論エンジンで使用する、ローカル AI チャット環境です。

ブラウザー試用版

試用版を開き、Models & settings で GPU プロファイルとメモリー容量を設定した後、ローカルの GGUF モデルを選択して読み込むとチャットを試せます。モデルは同梱していません。WebGPU エンジンがアーキテクチャ、テンソル構造、量子化、トークナイザーを検証します。動作する WebGPU アダプターと十分なメモリーが必要です。GPU プロファイルの選択は互換性の証明や空き VRAM の測定ではありません。RX 7900 XT と XTX の設定値は、公称容量の 20 GB と 24 GB です。

単一 HTML に画面、推論コード、トークナイザーと会話テンプレートのライブラリーをまとめ、Python、インストール、ビルドなしでオンライン評価を始められるようにしています。モデルの選択と読み込みには別途時間がかかります。モデルデータのアップロード、ローカルサーバーの使用、CPU 推論への代替処理は行いません。ネイティブ Nexus.cpp、オンラインサービス、音声、カメラ、教師機能は含みません。

完全版と技術的な貢献

完全版は、独立したブラウザーエンジンとネイティブエンジンに、モデルの検証、会話状態の制御、確認可能な診断情報を統合します。ネイティブプロトコル 3 は Stop、New Chat、プレフィックスキャッシュ、サンプリング設定を提供します。これらの機能にはネイティブ実行ファイルの再ビルドが必要です。ネイティブのバッチは 1 ステップ 1 トークンで、ネイティブ Flash Attention と低精度 KV キャッシュは未実装です。

完全版の全ファイルをダウンロードし、番号付きデータファイル、マニフェスト、インストーラー、フォルダー構成を保持してください。Install_Nexus_AI.py には CPython 3.10 以上が必要です。記録済みの Linux 検証では 3.12.14 を使用しました。Nexus AI は PyTorch バックエンドを使用しません。完全版にはローカルサービスが必要です。Nexus.cpp の Radeon アクセラレーションには対応する実行ファイルとコンパイラー、HIP、ドライバー構成が必要です。任意のデスクトップウィンドウは pywebview>=5,<7 を使用します。

検証と利用条件

ブラウザー版はネットワーク通信なしの起動スクリプト検証を通過しています。これはモデル全体の GPU 品質・性能の認定ではありません。有限かつ一定でないロジットの確認は、基本的な準備状態の検査にすぎません。Windows/Radeon の性能や全モデルへの対応は保証していません。ブラウザー改訂番号は v25-browser-r1 です。ネイティブ版 25 のパッケージ、Candidate25 のパスとハッシュは変更せず、Candidate24 もロールバック用に残します。

新しいブラウザー版を含む Nexus 所有部分は、個人利用および社内の商用テスト・評価に利用できます。配布、改変、本番導入、その他の商用利用には明示的な書面による同意が必要です。第三者のライセンスと既に付与された権利は変更されません。

Rich Dunbar / Nexus Emerging Technology. License · Evaluation permission (English).

歴史資料 · 10月9~10日の元の本文

以下の原文はプロジェクトの履歴であり、現在のインストール、実行環境、ライセンスの案内ではありません。上記のバージョン 25 の説明とリンク先の資料を使用してください。

NEXUS AI Studio

数百回の「構築・計測・学習」を通じて育てたローカル AI

Rich Dunbar が、AI を活用したコーディングで開発。
NEXUS AI は、構築、テスト、スクリーンショットと診断情報の記録、失敗からの学習、ユーザーのフィードバックによる改善を、数百回にわたって繰り返すことで発展してきました。

ブラウザベースの推論 · 任意で利用する音声・表情モジュール · 検証条件を設けた選好学習 · パープレキシティ評価


1. NEXUS AI を作った理由

自分のハードウェアで動き、自分の作業に合わせてカスタマイズできるアシスタントが欲しいと考えていました。

開発は LM Studio から始まり、その後、独自のグラフィカルインターフェースへ、最終的には独自のブラウザベースの推論エンジンへと進みました。別途インストールする AI アプリケーションへの依存や、導入時に直面した制約も減らしたいと考えていました。

LM Studio は、この出発点を支えたツールとして評価されるべきものです。ローカルモデル用のツールと API を提供していますが、現在の NEXUS のローカルランタイムは別の実装です。LM Studio 開発者向けドキュメント

制約について、区別しておくべきこと

導入に関する規則は、組織、製品、バージョンによって異なります。次の三つを混同してはいけません。

  • LM Studio: 独自の利用規約を持つデスクトップアプリケーション。
  • llama.cpp: MIT ライセンスで配布される推論ソフトウェア。
  • Meta Llama: 重みに対して、モデルごとに別の利用条件が適用されるモデルファミリー。

LM Studio は、商用利用のために個別に連絡するという要件を、2025 年 7 月に撤廃しました。私の開発経緯を、その旧要件が今も適用される、あるいはすべての組織がこれらのツールを禁止しているという主張として受け取るべきではありません。LM Studio の発表 · llama.cpp のライセンス · Llama 3.3 のライセンス例

実行ファイルによる配布から HTML へ

私の作業では、デスクトップ実行ファイルの配布に、署名やセキュリティ警告に関する手間がありました。HTML に移行したことで、インターフェースを修正しやすくなり、別の Windows 実行ファイルを配布する必要性も減りました。

Windows SmartScreen は、アプリケーションと発行元の評価を考慮します。署名があっても、新しいリリースで警告が出ないとは限りません。また、ブラウザ向けのパッケージにしただけで、組織の承認が得られたり、セキュリティポリシーが免除されたりするわけではありません。Microsoft SmartScreen のドキュメント


2. 一度のプロンプトではなく、数百回の反復

最初は複数ファイルの実装から始めました。私自身の開発経緯の説明では、その構成は数百のファイルへと膨らみました。AI を活用して編集する私の作業では、モノリシックなアプリケーション構成の方が、変更を素早く進めやすく、整合性も保ちやすいと感じました。

これは、このプロジェクトに合わせた開発上の選択です。単一ファイルのソフトウェアが、どのような場合でも高速で優れていると主張するものではありません。

flowchart LR
    A["対象を絞った変更を実装する"] --> B["テストして計測する"]
    B --> C["スクリーンショットと診断情報を確認する"]
    C --> D["結果とフィードバックから学ぶ"]
    D --> A
    B --> E["リグレッションチェック"]
    E --> F["動作する MVP"]
    F --> D

    style A fill:#123456,stroke:#38bdf8,color:#ffffff
    style B fill:#164e63,stroke:#22d3ee,color:#ffffff
    style D fill:#312e81,stroke:#a5b4fc,color:#ffffff
    style F fill:#14532d,stroke:#4ade80,color:#ffffff
Loading

AI は、実装とデバッグを支援しました。方向性を示し、実際の作業手順を試し、その結果を次の改訂につなげたのは私自身です。

動作する**実用最小限の製品(MVP)**ができると、実際にテストできる対象が生まれます。その後も、より分かりやすい操作、診断情報の改善、確実な保存、互換性の確認、フィードバックに基づく変更など、改善が続きます。

ここでいう「モノリシック」とは

主要なインターフェースとアプリケーションロジックは、HTML、CSS、JavaScript を使った一つの HTML ファイルにまとめて提供しています。

ただし、完全なオフラインパッケージには、別ファイルのモデルの重み、ランタイム資産、ワーカー用リソースも含まれます。入口が一つの HTML ファイルだからといって、すべてのニューラルモデルがその中に埋め込まれているわけではありません。

トレードオフには、ファイルの大型化、必要な箇所の探しにくさ、体系的なテストの必要性があります。AI のコンテキスト上限も、引き続き制約になります。


3. 現在のアプリケーション構成

確認したローカル言語モデルのランタイムは、独自の JavaScript、WebGPU、WGSL コードを使用しています。通常のローカル推論の実行経路では、LM Studio や llama.cpp を必要としません。

任意で利用するオンライン API バックエンドは、別の経路です。ブラウザのオリジン要件を満たすために、ローカルの静的ファイルサーバーが必要になる場合はありますが、それは LLM サーバーが必要ということとは異なります。

flowchart TD
    U["ユーザーインターフェース"] --> L["ローカル WebGPU LLM ランタイム"]
    U --> R["メモリと検索"]
    U --> V["任意で利用する表情モジュール"]
    U --> S["独立した音声モジュール"]
    L --> A["任意で利用する出力ヘッドアダプター"]
    A --> E["未使用データによる評価と採用条件の確認"]
    V --> C["任意の慎重な口調調整の手がかり"]
    C --> L

    style L fill:#123456,stroke:#38bdf8,color:#ffffff
    style V fill:#312e81,stroke:#a5b4fc,color:#ffffff
    style S fill:#164e63,stroke:#22d3ee,color:#ffffff
    style E fill:#14532d,stroke:#4ade80,color:#ffffff
Loading

メモリ、検索、プロンプトのカスタマイズは、モデルの重みを変えずに応答を変化させられます。実際にアダプターを学習する処理は、これらとは別のものです。


4. どのモデルへの対応が実装されているか

対応コードが実装されていることと、実機で十分な動作検証が済んでいることは同じではありません。 読み込み・実行の可否は、正確なアーキテクチャ、テンソル配置、トークナイザー、チャットテンプレート、利用可能なメモリに依存します。

ファミリーまたはプロファイル 実装されている範囲 検証の範囲と限界
SmolLM / SmolLM2 ベースモデルと Instruct のプロファイルを含む、制約付きの GGUF デンスモデルの処理経路 過去の実モデルによる数値確認は、特定の SmolLM2-135M F16・Q8 ファイルを対象とする。他のサイズは十分な検証を終えていない
Mistral-7B-v0.3 確認済みのベースモデル向けテキスト補完プロファイル トークナイザーと縮小構成での数値確認
Mistral-Small-3.2-24B-Instruct-2506 確認済みのテキストプロファイル ヘッダー、トークナイザー、縮小した計算グラフでの確認。24B 全体での実行は未検証
Ministral-3-14B-Reasoning-2512 確認済みの推論用テキストプロファイル 縮小構成での数値確認、テンプレート、回転位置埋め込みの確認
Qwen2 / Qwen2.5 / Qwen3 制約付きのデンス型テキストモデルの処理経路 すべての派生モデルやサイズとの互換性を示すものではない
Gemma 3 独立したテキスト用計算グラフ 実際のヘッダー・トークナイザーの確認と、合成データによる数値確認。27B 全体の出力検証は未完了
GPT-oss-20B 独自の混合エキスパート型計算グラフ 合成テストのみ。実機での 20B 全体の実行は未検証
GPT-oss-120B 将来のハードウェア向けに明示的な実行条件を設定 申告されている GPU 20 GiB/RAM 32 GiB の構成では、動作検証済みではない
Qwen2.5-VL-7B 対応するローカル視覚コンパニオンを組み合わせた、特定のテキスト・静止画像プロファイル 縮小した合成テストのみ。画像を条件とした 7B 全体の動作検証は未完了
Custom LittleBit 対応するパック済み因子形式 正確なメタデータと符号化形式が必要

GGUF はコンテナ形式であり、あらゆるモデルとの互換性を保証するものではありません。任意のアーキテクチャ、分割 GGUF、未対応の量子化配置、汎用的な PyTorch/Safetensors の読み込みは、確認したローダーの対応範囲外です。

元のモデルの能力が、そのままアプリケーションの機能になるわけでもありません。例えば、このビルドで通常割り当てられるコンテキストの上限は、4,096 トークンです。

モデルの研究とクレジット:SmolLM2 · Gemma 3 · Qwen2.5-VL · GPT-oss モデルカード


5. 視覚:表情を参考にする対話と、その限界

現在のカメラモジュールが行うのは、顔の検出と表情の分類であり、人物の識別ではありません。

使用しているのは、次の技術です。

  • 顔とランドマークの検出に YuNet
  • 表情の分類に、MobileFaceNet をバックボーンとする ProgressiveTeacherFER
  • 独立したシングルスレッドの WASM CPU ワーカーで動作する ONNX Runtime Web

これは、言語モデルの WebGPU エンジンとは別の処理です。

分類器には、angry(怒り)、disgust(嫌悪)、fearful(恐れ)、happy(喜び)、neutral(中立)、sad(悲しみ)、surprised(驚き)の七つのカテゴリがあります。インターフェースでは、**「sad-like(悲しそうな表情)」や「surprise-like(驚いたような表情)」**のように、断定を避けたラベルを表示します。カメラから推定する「excited(興奮)」というクラスはありません。

品質確認、信頼度スコアのしきい値、繰り返しの推定、5 秒で失効する仕組みによって、十分な根拠がない場合は判定を控えます。これらの経験則は、その人の感情を正しく読み取れるという、較正された保証ではありません。

応答にどう影響するか

明示的な同意があり、初期状態ではオフになっている任意のローカルチャット設定を有効にした場合、直近の表情推定を基に、慎重な指示をシステムプロンプトへ加えられます。

その指示では、アシスタントに次のことを求めます。

  • 推定を不確かなものとして扱う
  • ユーザー自身の言葉を優先する
  • 役立つ場合に限り、口調を穏やかに調整する
  • 決めつけずに尋ねる
  • 身元、意図、診断、リスクを推測しない

別途ユーザー自身が選択した気分の情報がある場合は、そちらが優先され、明示的な口調のルールが適用されます。

私はこれを、プログラムで定めた、感情に配慮する応答調整と説明しています。システムが内面の感情を理解していることや、心理学的に検証された意味で情動知能を持つことの証拠ではありません。

感情コンピューティングは関連する研究背景を提供しています。一方、表情の研究では、顔の動きを、感情と一対一で対応する信頼できる読み取りとして扱うことに注意を促しています。Picard: Affective Computing—Challenges · Barrett ほか: Emotional Expressions Reconsidered

カメラ由来の情報を含むコンテキストは、アダプター学習用の自動収集から除外されます。表情機能は、顔画像の一覧や表情履歴を意図的に保持する設計にはなっていません。別途有効にしたオンラインサービスには、それぞれ独自のデータの流れがあります。


6. 音声:出力と入力は別の機能

ローカルでの音声出力

完全なパッケージには、Kokoro-82M ONNX Q8 の資産、Bella と Fenrir の音声、英語の音素変換器・辞書、ONNX Runtime ワーカーが含まれています。

同梱パックをブラウザのストレージへインポートすると、この経路ではローカルで音声を合成します。統合されているパックは英語専用です。この wiki を翻訳しても、音声の対応言語が増えるわけではありません。Kokoro モデルカード

音声入力

音声認識モデルは同梱していません。

厳格なオフライン認識には、ブラウザの対応するオンデバイス認識機能と、インストール済みの言語パックが必要です。利用できない場合は、無断でクラウド認識に切り替えるのではなく、処理が失敗します。

厳格なオフライン設定を無効にすると、ブラウザの認識機能や、別途設定した API がオンラインサービスを使う場合があります。

音声出力がオフラインでも、音声入力まで自動的にオフラインになるわけではありません。


7. 承認された対話から学習する

現在のアプリケーションには、実際に学習する出力ヘッドの LoRA 型適応が実装されています。

ベースの GGUF、Transformer ブロック、入力埋め込みは固定したままです。学習可能な低ランク行列が、出力ロジットを変更します。固定部分の順伝播計算には WebGPU を使い、アダプターの勾配計算とオプティマイザーは、CPU 上の JavaScript で実行します。

学習経路には、次のものがあります。

  • 承認済みの好ましい回答・好ましくない回答を使う、DPO 型の選好最適化
  • 承認済みの良い回答を使う、交差エントロピーによる学習
  • 教師モデルが生成したコーパスをレビューして使う、独立したワークフロー

LoRA は適応の仕組みを、DPO は選好学習の目的関数を指します。どちらも、すべての対話を強化学習による更新と呼ぶ根拠にはなりません。このビルドで、PPO に基づくオンライン RLHF ループが成立しているとはいえません。LoRA · Direct Preference Optimization

毎メッセージ後の自動成長ではなく、管理された適応

Learning インターフェースには、学習、評価、有効化の操作があります。End Session でも、承認済みの対象データと、確認済みの対応モデルが用意されている場合、任意の学習を試みることができます。

新しいアダプターを採用するには、学習に使っていないデータでの評価と、リグレッションチェックが必要です。ユーザーは学習せずに終了でき、失敗した場合は以前のアダプターが保持されます。

チェックポイントは、モデルとランタイムの識別情報にひも付けられています。カメラ情報の影響を受けたコンテキストや、明示的に画像について質問したコンテキストは、自動収集から除外されます。

「対話するほどモデルが成長する」という表現は、承認された例と、任意のアダプター更新が時間とともに蓄積されることとして理解するのが適切です。ベースモデルのパラメータ数が増えるわけではなく、改善も保証されません。

検索に基づくメモリは、これとも異なる仕組みです。重みを再学習せずに、文脈を提供します。Retrieval-Augmented Generation


8. パープレキシティで変化を測る

アプリケーションには、正解トークンを順に与える teacher forcing による次トークンのスコア計算が実装されており、次の式を使います。

パープレキシティ = exp(負の対数尤度の合計 ÷ 評価対象トークン数)。

評価用テキスト、トークン化、モデル、ランタイム、アダプター、コンテキスト設定など、評価を特定する情報を記録します。意味のある変更前後の比較には、同じ評価手順が必要です。

これは、対応するアダプターの効果を評価する助けになります。ただし、事実の正確さ、推論能力、感情理解、全般的な知能を直接測る指標ではありません。

学習に使った資料でスコアが低くなっても、単に記憶した結果である可能性があります。実際に学習から除外したデータと、タスクごとの評価も使ってください。


9. テストから分かること

私の開発環境での経験

私は、AMD Radeon RX 7900 XT、Windows 11、Microsoft Edge の環境で、NEXUS の開発ビルドをテストしたと報告しています。

これは、私自身の開発経験です。対応するすべてのバックエンドや、正確に最新のビルドについて、独立に再現されたハードウェアベンチマークとして示すべきではありません。

コードとソフトウェアによる検証

確認したビルドには、動作する選好学習の計算、オプティマイザーの更新、モデルの識別情報チェック、パープレキシティ評価器が含まれています。対象を絞った合成テストで、勾配、固定されたデータ領域、評価ウィンドウの対象範囲を確認しています。

過去の実際の SmolLM2 による確認では、ソフトウェア CPU/Vulkan 上で、入力の先頭側にある限られた位置を使いました。表情機能の実行記録は、モデルの実行と、顔でない入力に対する判定の抑止を確認しています。音声機能の実行記録は、音声合成を確認しています。これらは、実際の顔に対する精度、ブラウザとデバイスの組み合わせ全体での信頼性、物理 Radeon GPU の性能を実証するものではありません。

学術論文は手法を説明するものです。NEXUS AI の実装を認証したり、そのベンチマークを再現したりするものではありません。

対象バージョン

このページは、2026 年 10 月 9 日にパッケージ化され、2026 年 10 月 10 日に確認したアプリケーションを説明しています。

アプリケーションの SHA-256:

1a1d6eb77958a8b276607843eb446a391d887c65612c5acfabb301ac7daca465

独立した Nexus Adapter Studio、Foundry、Recovery の各アプリケーションの機能を、このビルドの機能として扱ってはいけません。統合されていることが、別途確認されている場合に限ります。


10. クレジット、ライセンス、このプロジェクトの貢献

私の貢献は、NEXUS アプリケーション、独自の統合、インターフェース、ランタイムの開発、反復的な開発ワークフローです。モデルの作者と、基盤となるプロジェクトの貢献者の功績は、それぞれの方々に帰属します。

関連する依存技術には、次のものがあります。

  • Kokoro:hexgrad。ONNX への変換は ONNX Community/Xenova。
  • YuNet:Shiqi Yu と貢献者。
  • ProgressiveTeacherFER:Jing Jiang。ONNX 実装のクレジットとして Chengrui Wang を保持。
  • ONNX Runtime:Microsoft と貢献者。
  • HeadTTS 言語モジュール:Mika Suominen。
  • CMU 発音辞書:Carnegie Mellon University。

確認したアプリケーションパッケージは、UNLICENSED と宣言されています。オープンソースの依存技術を使っているからといって、アプリケーション全体に自動的にオープンソースライセンスが付与されるわけではありません。再配布や商用利用が許可されていると主張する前に、リポジトリの実際のライセンスを確認してください。

表情パッケージには、上流プロジェクトの宣言が保持されています。ただし、使用している正確なチェックポイントのライセンスと、学習データの出所には、未解決の問題が残っています。制限なく利用できると主張する前に、これらを解決する必要があります。

構築する。計測する。学ぶ。検証する。改善する。

Rich Dunbar · NEXUS Emerging Technology

Clone this wiki locally