私はOasisと言うOpenWrt専用のAIアシスタントアプリを作っています。次のバージョンアップでRPCに対応するので様々な通信経路でAIが利用できるようになります。夏にはMCP対応と低レイヤー制御用の連携アプリであるspringも開発を始めます。全ての機能が実装されるとユニークなアプリになりそうです。

ローカルのMCPクライアントとMCPサーバーを自作のAIアプリに追加実装し始めました。ローカルに限定して言えば、MCPはツールのメタ情報の共通化を通してLLMとAIアプリ間でやり取りされる FunctionCallingのデータを自動生成してるんだと思いました。そしてサーバーがシェアされないと冗長性になる印象。

OpenWrtのUBUSを利用するMCPクライアントとMCPサーバーを実装していますが、通信方式がUNIXドメインソケットになります。この場合、MCPに準拠して仕様互換性を確保できても一般的なSDKとの実用互換性は確保できません。そのため、無駄な実装になってしまいます。やはり、実験的の側面が強いかな〜。

特殊な環境を持つOS上で、AIにリソース操作をさせたいと思ったときに一般的なMCP SDKを使ってローカルクライアントとサーバーが構築できない場合はFunctionCallingより先は独自実装をした方が良いと思いました。無理にMCPに準拠してもオーバーヘッドにしかならないと思います。

お盆休みで個人開発のOpenWrt用AIアシスタントアプリの改良がかなり進みました。バグ多いのでまだ最新版はリリースできませんが、OpenWrtのUBUSシステムをAIが実行して結果を得ることに成功しました。動画のTool Used: 〜の表示がそれです。

結局、個人制作のOpenWrt用AIアプリはローカル機能の認識と使用に関してUBUSのrpcdモジュールに独自の抽象化設計を適用しました。これで所定のルールでLuaまたはuCodeスクリプトを書けば直ぐさまAIがツールを認識します。MCPはAIサービスのサポートに委ね、アプリ側は認証情報のみ管理させるつもりです

やっと個人開発のAIアプリが安定稼働し始めました。拡張モジュールにデフォルトで同梱されるAI用ツール一式を整備した後に最終チェックしてリリース準備に入ります。しかし、uCodeスクリプト製のデフォルトツールは何の機能にすれば良いんだろう…

個人開発のOpenWrt専用AIアシスタント Oasisの最新版(v3.0.0)をリリースしました。恐らく、このバージョンから実用レベルだと思います。 年内はGeminiなどのAI対応やツール定義の拡張方法などの共有に力を入れてきます。流行るか分かりませんが。ちなみに、ブログの紹介記事の更新は遅れてます。