はじめに
最近はLLMやAIエージェントの進歩がものすごい勢いで進んでいます。
私はテック系が好きで、論文を読んだり実際にモデルを動かしたりしています。
その中で、
「自分でもAIを作ってみたい」
と思うようになりました。
しかし、すぐに現実にぶつかります。
巨大AIは個人では作れない
例えば最近のLLMは数十B〜数百Bパラメータ。
学習には大量のGPUが必要です。
さらに推論にも
- 高性能GPU
- 大容量VRAM
- 電気代
- サーバー維持費
- 長時間/高費用のモデル学習
などが必要になります。
金欠に悩む自分には到底用意できませんでした。
「やっぱり個人では無理なのかな。」
最初はそう思っていました。
MoEという考え方を知った
そんな時に知ったのが MoE（Mixture of Experts） というアーキテクチャでした。
MoEでは、
- 数百もの専門家（Expert）が存在し
- 毎回すべてを動かすのではなく
- 必要な専門家だけを起動する
という仕組みになっています。
つまり、
全部を毎回動かす必要はない
という考え方です。
ここで一つ疑問が浮かびました。
「専門家を別々の端末へ置けばいいのでは？」
MoEでは専門家は1台のGPUの中に存在しています。
でも、
専門家一人ひとりは独立しています。
だったら
スマホA
↓
数学担当
スマホB
↓
コード担当
スマホC
↓
翻訳担当
スマホD
↓
推論担当
このように
専門家ごとに別々の端末へ配置する
ことも理論上できるのでは？
と思いました。
つまり
GPUを巨大化するのではなく
専門家そのものをネットワークへ分散する
という発想です。
実はこの時点では、
実は、このアイデアを思いついた時点では「分散AI」という研究分野があることすら知りませんでした。
「MoEをネットワークに広げたら面白そう」
そんな素朴な発想から始まっています
そこで思い出したのが「アーカーシャ」
この構成を考えていた時、
ふと頭に浮かんだのが
**原神の「アーカーシャ」**でした。
ゲーム内では
- 知識を集約し
- 必要な情報へ瞬時にアクセスできる
- 人々を知識ネットワークで繋ぐ
というシステムとして描かれています。
「あれ？」
「これって今考えている仕組みに少し似ている。」
そう感じました。
もちろんゲームと現実は違います。
しかし
「知識をネットワーク全体で扱う」
という思想が非常に近かったため、
プロジェクト名を
『ArcAsha』
と名付けました。
名前だけではなく、
「知識をネットワーク全体で協調させる」
という思想そのものが、
このプロジェクトの原点になっています。
ArcAsha-OSとは？
ArcAsha-OSでは、
「巨大モデルを1台で動かす」
のではなく、
「複数の小さな専門家モデルを協調させる」
というアプローチを採っています。
Master
│
┌──────────────┐
│ │
Math Expert Coding Expert
│ │
Translation Reasoning Expert
各ノードは
それぞれ得意分野だけを担当します。
Masterは
- タスク分解
- 最適ノード選択
- 品質評価
- 学習
- 記憶
だけを担当します。
巨大GPUを作る代わりに、
ネットワーク全体を一つの知能として扱う
ことを目標にしています。
実際に作ってみると想像以上に難しかった
最初は
「専門家を選べば終わり」
くらいに考えていました。
しかし実際に作ってみると、
予想もしなかった問題が大量に発生しました。
例えば
- 一度評価が下がると二度と選ばれなくなる
- スピードを重視して軽いモデルばかり選んで品質が悪化する
- 試行回数が少ないだけで能力を誤判定する
- FP16とFP32で出力が分岐する
- WebGPUとPyTorchで挙動が変わる
など、
単純なルーティングでは全くうまく動きませんでした。
「なぜ失敗するのか」
を調べ始めると、
ルーティングアルゴリズムそのものを設計し直す必要があることが分かりました。
そこから現在の
「ODAR (Observation-Driven Adaptive Routing)」
というルーティング方式へ発展しています。
ODAR（Observation-Driven Adaptive Routing）とは？
ArcAsha-OSでは現在、ルーティングアルゴリズムとして ODAR（Observation-Driven Adaptive Routing） を採用しています。
僕の作った造語ではありますが、名前の通り、
「実際に観測（Observation）した結果から、ルーティングを継続的に学習していく」
ことを目的としたアルゴリズムです。
🔄 Observation → Belief → Routing
ODARでは、各モデルについて
- コーディング能力
- 数学能力
- 推論能力
- 翻訳能力
などを Belief（信念） として保持します。
タスクを処理するたびに、
Observation
↓
Belief Update
↓
Confidence Update
↓
Feature Generation
↓
LinUCB
↓
Routing
という流れで能力推定を更新していきます。
つまり、
「最初から誰が得意か決め打ちする」のではなく、経験から能力を学習するルーター
になっています。
🎯 なぜLinUCBなのか
モデルを選ぶだけなら、
「一番スコアが高いモデルを選べばいい」
ようにも思えます。
しかし実際には、
未知のモデルも試さなければ本当の能力は分かりません。
そこで、
- Exploration（探索）
- Exploitation（活用）
のバランスを取れる LinUCB を採用しました。
さらにArcAshaでは、
実際に採用したモデルだけではなく、
他のモデルも並列評価する Shadow Feedback を導入しています。
これにより、
「選ばれなかったモデルも学習できる」
という特徴があります。
オンライン学習でありながら、より効率的に各モデルの能力を更新できるようになっています。
📊 実験ではどうだったのか
ODARについては 30シードによる統計実験 を実施しました。
その結果、
- ✅ 固定ルーティングより有意に性能が向上
- ✅ 異なるモデル構成（Set A / Set B）でも結果を再現
- ✅ Feature Ablationでは Capability Feature が最重要であることを確認
など、
単なるアイデアではなく、
統計的な検証によって有効性を確認しています。
（ただし、もっと試行回数を増やした結果も検証しようと思います。）
現在は、このODARを npm（@arcasha/router） と Python（arcasha-router） の両方で利用できるようライブラリとして切り出し、ArcAsha-OSだけでなく他のAIシステムにも組み込める形で公開を進めています。
現在どこまで完成しているの？
現在のArcAsha-OSでは、
以下まで実装が進んでいます。
✅ WebGPUスマホノード
スマホ（iPhoneは難しい）とPCブラウザをAIノードとして接続
✅ Belief-Driven Routing
各モデルの能力を学習しながらルーティング
✅ Planner
複雑なタスクを複数へ分解
✅ Tree Search
複数プランを探索し最適なものを採用
✅ Self Reflection
失敗原因を分析して再実行
✅ Long-term Memory
過去の実行結果を次回ルーティングへ反映
✅ npm / PyPI
ODAR Routerをライブラリとして公開
おまけ１（原神について）
「ArcAsha」という名前や各機能（下の表に記載）の名前は原神のアーカーシャやスメールの物語等から着想を得ていますが、実際のアーキテクチャはゲーム内の設定を再現したものではなく、現実のLLM・MoE・オンライン学習・バンディットアルゴリズムを基に設計しています。
| ArcAsha-OS | 役割 | 命名のイメージ |
|---|---|---|
| ArcAsha | 分散AI基盤全体 | アーカーシャ |
| Heart of Wisdom | オーケストレーター（Master） | 知恵の心 |
| Expert Nodes | 各専門AI | 学者・知識の担い手のイメージ（＋MoE） |
| Belief | 各ノードの能力状態 | 知識（ネットワークが保持する） |
| ODAR | 適応型ルーティング | ※原神由来ではなく独自アルゴリズム |
※機能の命名やアーキテクチャの命名はやってるうちに子供の頃に戻った気分でちょっと厨二病っぽく命名してみました笑
最後に
ここまで読んでいただきありがとうございます。
↓（以下にアクセスしていただくと技術詳細が載っています）
ルーティングアルゴリズムについてはプレプリント論文も公開しました。
GitHub
Zenodo
振り返り
このプロジェクトは
「分散AIを作ろう」
から始まったわけではありません。
AIが好き
↓
自分でも作りたい
↓
でも巨大GPUは買えない
↓
MoEを知る
↓
専門家だけ動いている
↓
だったら専門家を別々の端末へ置けばいいのでは？
↓
そういえば原神のアーカーシャって、
知識をネットワーク全体で扱う仕組みだったな
↓
これならいけるかも...??
↓
じゃあ作ってみよう！！
そんな流れから自然に生まれたのが
ArcAsha-OSです。
まだまだ発展途上ですが、
「個人でもAI基盤そのものを設計できる」
そんな可能性を少しずつ形にしていきたいと思っています。
この記事が、
「自分でも何か作ってみようかな」
と思うきっかけになれば嬉しいです。
もし興味を持っていただけたら、
GitHubで開発状況を覗いていただけると嬉しいです！