AIaW は非推奨、Nya AI への移行を前提に読むセルフホスト型 AI クライアント

このプロジェクトが埋めようとしている穴

一般的な AI チャットクライアントは、会話をベンダーのサーバーに預ける前提で作られている。モデルを乗り換えるたびに履歴が分断され、オフラインでは何も読めず、ツール連携はクライアントごとに独自実装になる。AIaW が狙うのはこの三点の分離である。README は対応プロバイダとして OpenAI、Anthropic、Google、DeepSeek、xAI、Azure を挙げ、会話データは「Data is stored locally first, accessible offline and loads instantly」と説明する。つまり保存の一次的な置き場は端末側で、クラウド同期は後から足す層という位置づけだ。想定読者は、複数のモデルを用途別に使い分け、社内のツールやローカルファイルを会話に引き込みたいが、履歴の所有権は手元に置いておきたい技術者である。Web (PWA)、Windows、Linux、macOS、Android と配布面が広いのも、同じ作業環境を複数の端末で行き来する使い方を想定しているためだ。

ローカル優先のデータと、後から乗る同期層

README の記述から読み取れるデータの流れはこうだ。会話はまず端末のローカルストレージに書き込まれ、その状態でオフラインでも参照でき、起動時の読み込みも待たされない。ログインするとクラウド同期が有効になり、端末間で同じワークスペースを共有できる。同じブラウザで複数のタブを開いた場合は、タブ間でデータが応答的に同期する「multi-window collaboration」が働く。ここで注意したいのは、同期はローカル保存の代替ではなく追加層だという点である。オフラインで編集した内容がどう競合解決されるかは README にもリポジトリ構成にも記述が見当たらず、この部分は採用前にドキュメント側で確認する必要がある。ワークスペースはテーマ単位で分離でき、フォルダに入れて入れ子にもできる。アシスタントはワークスペース単位でもグローバルにも作れるため、同じ人物設定を複数の作業領域で使い回せる。

MCP とプラグインは別物として設計されている

AIaW は MCP クライアントとして、Tools、Prompts、Resources の三種を扱い、接続方式として STDIO と HTTP の両方をサポートすると README は説明する。MCP サーバーはプラグインマーケットから入れることも、手動で追加することもできる。ここで混同しやすいのが、MCP と独自プラグインが別の仕組みだという点だ。README はプラグインについて「Plugins are more than just tool calling」と書き、計算機、ドキュメント解析、動画解析、画像生成を組み込みで挙げ、マーケットからの追加、Gradio アプリのプラグイン化、LobeChat プラグインとの部分的な互換にも触れている。つまりツール呼び出しの標準規格としての MCP と、UI や処理を差し込む拡張機構としてのプラグインが並立している。拡張を作る側にとっては、どちらの口に合わせるかで実装量が変わる。MCP 側は仕様に従えば他クライアントと共有できるが、プラグイン側は AIaW 固有の作法に寄る。

セルフホストまでの手順と設定の勘所

リポジトリの README に載っている開発手順は短い。依存の導入が pnpm i、開発モードの起動が quasar dev、リントが pnpm lint、本番ビルドが SPA なら quasar build、PWA なら quasar build -m pwa である。Quasar ベースの Vue アプリなので、ビルド成果物はそのまま静的ホスティングに置ける。セルフホスト固有の設定は README 本文には書かれておらず、docs.aiaw.app/self-host/ のガイドに委ねられている。Web 検索は SearXNG を基盤とし、README は「ready to use out of the box」と表現するが、SearXNG を自前で立てるのか公開インスタンスを使うのか、その接続先をどこで指定するかは本文からは分からない。同様にクラウド同期のサーバー側実装や保存先も、この資料だけでは確認できない。デプロイを計画するなら、ビルド手順よりも self-host ガイドの接続設定を先に読むべきである。

README が自分で宣言している非推奨

このプロジェクトを評価するうえで最も重い事実は、README 冒頭の警告である。AIaW は deprecated であり、新しい技術スタックで書き直された Nya AI が後継だと明記されている。後継は本プロジェクトのほとんどの機能と一貫した体験を提供し、加えて新しい機能と最適化があるとされる。既存ユーザー向けには docs.aiaw.app/migration/ への導線があり、リリース v1.8.10 には「Migrating to Nya AI」という注記が付いている。つまり移行は告知段階ではなく、リリース単位で進行している。ここから導ける実務的な帰結は単純で、新規に会話データを AIaW に積み始めるのは避けたほうがよい。バグ修正やモデル追加が今後 AIaW 側に入る保証は資料からは読み取れない。一方で BSD-3-Clause なので、コードを fork して自前で維持する道はライセンス上残っている。ただしそれは移行を捨てて保守を引き受けるという判断であり、軽い選択ではない。

向かない場面と、比較対象としての Nya AI

AIaW が向かないのは、まず新規採用の場面である。後継が明示されている以上、機能表の充実度で選ぶ理由は薄い。次に、組織で長期間運用し、モデル追加や MCP 仕様の更新に追随し続けたい場合も向かない。追随は後継側で起きる可能性が高い。比較対象は README が挙げる Nya AI そのもので、違いは機能の有無ではなく技術スタックの作り直しにある。README は「a complete rewrite with a new tech stack」と述べ、既存機能の大部分と一貫した体験を引き継ぐとしている。したがって比較の軸は、どの拡張機構が残り、どのプラグインがそのまま動くのかという互換性になる。なお、この資料には Nya AI のライセンス、対応プラットフォーム、セルフホスト手順は含まれていないため、AIaW と同じ BSD-3-Clause で扱えるかは判断できない。乗り換えを検討するなら、この点は別途確認が必要だ。

BSD-3-Clause で fork を維持する場合のコスト

ライセンスは BSD-3-Clause で、著作権表示と免責事項を保持すれば改変と再配布が許される。ソースを閉じた製品に組み込むことも可能で、GPL 系のような伝播はない。これは AIaW を fork して自社向けに維持する道が法的に開かれていることを意味する。ただしコストは別のところにある。TypeScript と Vue、Quasar で書かれたクライアントを継続的に保守するには、プロバイダ側 API の変更、MCP 仕様の更新、依存パッケージの更新を追う必要がある。README には保守体制やサポート期間に関する記述がないため、どれだけの頻度で更新が入るかを事前に見積もる材料は提供されていない。fork を選ぶなら、pnpm i と quasar build が手元で通る状態を最初に確認し、そのうえでどの依存を固定するかを決めることになる。ここに挙げたのは技術的な判断材料であり、ライセンス条項の解釈については必要に応じて専門家に確認してほしい。

編集部の結論

既に AIaW を動かしていて会話データをローカルに抱えているチームは、機能追加ではなく Nya AI への移行手順を先に読むべきである。docs.aiaw.app/migration/ の内容と、書き出したデータが Nya AI 側で読めるかを確認するのが最初の作業になる。逆に、これから AI クライアントを新規に選定する場合や、長期的なサポートと継続的なセキュリティ更新を前提にしたい場合は、README が後継として挙げる Nya AI を直接評価したほうがよい。AIaW をあえて選ぶ理由があるとすれば、BSD-3-Clause の下で既存の fork を維持したい、あるいは v1.8.12 時点の挙動を固定して使いたいといった、移行以外の事情がある場合に限られる。

公式情報源

1. License: BSD-3-Clause
2. NitroRCr/AIaW on GitHub
3. Project website
4. README
5. Releases