うたカモ技術ブログ

OpenWrt 個人開発 oasis

【個人開発】   Oasis AIツール動作試験その1

post: 

このメモ記事は、私が個人開発したOpenWrt専用AIアシスタントツールのOasisがサポートするツール実行基盤(Oasis Local Tool)の 動作確認結果をまとめたものです。

※このツール実行基盤はoasis-mod-toolと呼ばれるプラグインモジュールをOasisに追加インストールすることで利用可能になります。 私がGitHubで配布しているインストールスクリプトや、このサイトの導入記事では標準でインストールされるようになっています。

Oasis Local Tool(OLT)はModel Context Protocol(MCP)のアーキテクチャ概念の1つである「ツール定義をサーバー側に集約することでツール実行に関する責務をサーバー側が担う」 という考え方をOpenWrtのUBUSサーバー・クライアントシステムに投影して開発したAI用ツールの実行基盤です。

(正直、コア制御はUBUSなので正確には独自の実行基盤ではありません。 私はOpenWrtのUBUSがOSシステム内部に提供している公開サーバー機能をツールとしてAIに認識させるパスを作っただけにすぎません。それにしても、AIがUBUSを利用するとはOpenWrtプロジェクトの開発者の人も想定外でしょうね。。。)

この仕組みはOasis独自のものとなっていますが、MCPのツール配布のようにネットワークを介して仲間内でツールをシェアすることが事実上可能になっています。

補足

もちろん、このAIツール実行基盤を利用するにはOpenWrtにOasisをインストールすることが前提です。 しかしながら、OpenWrt環境でローカルおよびリモートMCPサーバーが利用可能なエコシステムは現時点で形成されていません。

そのため、私が開発したOasisとツール実行基盤は現在のところ、「OpenWrt上でAIと会話できてツールも使用可能」という意味では非常に強いポジションに位置していると思います。

まあ、このアプリを使う人が存在するかが一番重要なわけですが。。。

OLTに関わる情報やツールの定義・実装方法は以下のGitHubリポジトリに掲載しています。
GitHubリポジトリ:oasis-mod-tool

OasisのAIツールはOpenWrtシステムに影響を与えるために、AIツールの定義に応じていくつかの挙動変更を指定できます。 このメモ記事ではそれらのツール動作の確認結果を掲載します。

ちなみに、ここまで書くのはOasisの開発で協力者が現れたときのことを考慮しているからです。既に外部の活動を観測しています。

AIツールの動作確認では以下のテストツールを利用しています。
動作確認用AIツール:oasis-tool-test

[WebUI] Luaスクリプト製AIツールの動作確認結果

Luaスクリプト製のAIツールの動作確認結果です。AIがサボるときがあるので、動画ではやり直しを要求していたりもします。

[WebUI] Ucodeスクリプト製AIツールの動作確認結果

Ucodeスクリプト

Ucodeスクリプトとは、OpenWrtプロジェクトで開発が進んでいるOpenWrtの専用スクリプト言語です。 構文はJavascriptに似ており、システム上の立ち位置はLuaに非常に似ています(そのため、UcodeスクリプトはLuaスクリプトのように C言語ソフトウェアに組み込めるようにもなっています)。

Ucodeスクリプト製のAIツールの動作確認結果です。途中からAIがサボり始めたのでかなり口論しています。

評価

AIツールの実行自体は問題ないと見ました。しかし、とにかくサボろうとする挙動を何回も確認しました。

考えられる原因は大体以下のものだと思います。

  1. システムプロンプトの内容が悪い
  2. システムプロンプトの内容とツール情報の相性が悪い
  3. ツール情報の内容が悪い

おそらく、「ツール情報の内容が悪い」が原因でしょう。AIがツールを認識する際に読み込んでいる説明には「Test Tool A」や「Test tool B」などの 簡単なテキストしかありません。これを読み込んだAIは「正直、テストツールだから実行しても意味ないんか。。。」と認識しているのかもしれません。

ひとまず、WebUIの試験は完了です。
次はコンソール上からOasisを操作したときの動作試験をします。

余談

CursorやGitHub CopilotなどのAIアプリにLLM本体の挙動を調整する処理が大量に施されていることが関節的に分かる結果でもあると考えています。

AIサービス(サーバー)にAPIキーを使用してLLMを利用する場合、通常であればユーザーはAIサービス側で調整されただけのLLMと対話することになります。

対して、CursorやGitHub CopilotなどのAIアプリ越しでLLMと対話する場合、AIサービス側+AIアプリ側の調整が入った上でAIがユーザーに応答を返していると考えられます。

これらのAIアプリはユーザーの問い合わせの応答をサボったり、ハルシネーションが頻発しないような最適化調整をLLMにしていることでしょう。 それはプログラムコードレベルのアルゴリズム的な調整(例:オーケストレーション[Agent Modeなど])から、システムプロンプト(AIに対する指示用テキストデータ)の調整など様々だと思われます。

このようなことを考えると、私のアプリはまだまだ性能を上げる余地がありそうです。引き続き開発を継続していきたいと思います。