大田に来て一年経ちました
おごちゃん
今日でちょうどこちらに来て一年経ちました。
まだ十分な売り上げがないので苦しい状態は続いておりますが、そうった状態であっても「一年」過ごすことができました。
陰に日向に様々な人達に助けられて今があると思うと、感謝に堪えません。
「慧仕(Huìshì)」というAIエージェントフレームワークを作っています。
Huishi(以下この記法にします)の詳細についてはまたそのうち書くとして、これで使っている「思考構造」について公開したいと思います。 これは、世の中にある様々なAIエージェントを調べていて、類似の構造のものがなかったからです。
「なかった」理由はよくわかりません。有効でないと考えられているのか、そこに考えが至らなかったのか、その辺はよくわかりません。 とは言え、「なかった」のは事実なので、文章にまとめて公開して公知にしておきます。 そうすれば、少なくとも私が使えないことはないからです。
背景
以前、CatchUpというニュース解説のエージェントを作っているという話はしました。
元々が「お好みのニュースを楽して読みたい」という希望から作ったものですが、裏の背景として「LLMを応用した文書管理システム」の話が来ていたということも書いていると思います。 そして、この話に関連して「ある種の教育システム」という話も一緒に来ていました。 時を同じくして、複数のAIエージェントを作るということになっていたわけです。
私の習性として、そういった「似たような話」が複数ある時には「個別にアプリ作るのをやめてフレームワーク的なものをまず作る」というアプローチを取ります。 そこで、「汎用AIアシスタント」を構築するためのフレームワークを考え始めました。 それが「Huishi」です。
「Huishi」の詳細については、そのうちあらためて書きます。
最初は「ユーザの入力」を元にLLMで解析をして、処理の分岐を行い… というありがちのアプローチを取ろうとしたのですが(前述のエントリにそれが書いてありますね)、「ある種の教育システム」に関わる人達は、基本的に非ITエンジニアです(教育学系の人達)。 そうなると、このアプローチは取れません。 そこで「より汎用的でわかりやすい何か」を実現することが必要となります。
従来手法
「大きな問題」を解くためのAIエージェントは「思考のルーティング」が必要です。
つまり、「強いプロンプトを考案して、どーんとLLMに食わせる」よりは、問題を分割して個々の問題を解くエージェントを作り、その思考をルーティングしてやることが必要となります。
そして、「従来手法」として「思考のルーティング」は大別して以下の方法と得失があります(この部分はChatGPTに聞いてます)。
- コードベースでの明示的ルーティング（静的選択）
- 特徴
- 事前に「どの状況でどのtool/agentを呼ぶか」をコードで書いておく
- 条件分岐（if, switch, ルールエンジン）やタスクグラフで制御
- 使用例
- LangChain（SequentialChain, RouterChain, ToolSelector）
- Semantic Kernel（Plannerがコードで選択を生成）
- AutoGPT系（初期）（yaml/jsonでプラン構築）
- メリット
- 動作が予測可能、テスト可能
- セキュリティ・権限制御しやすい
- デメリット
- 柔軟性が低い、対応漏れが起きやすい
- スクリプト・DSLが複雑化しがち
- LLMによる説明ベースの自動選択（動的選択）
- 特徴
- エージェントやツールに description を持たせ、LLMがその内容を読んで選択
- prompt + tools一覧 → LLMにYAMLで選ばせる のパターンが主流
- 使用例
- OpenAI function calling (tool_choice: auto)
- LangChain agent with tools + description
- ReAct, AutoGen, CrewAI など、対話中に選択
- メリット
- 柔軟性が高く、未知のケースにも対応できる
- ユーザ入力との親和性が高い
- デメリット
- 精度が不安定（特に選択肢が多いと混乱）
- LLMのhallucination（誤選択）の可能性
- セーフティ／制限が曖昧になる
この表の妥当性、あるいはこれらについての詳細の説明は省きますが、大別して2つくらいの手法があり、それぞれ得失が存在します。
考案した手法
Huishiの思考構造として取ったアプローチは、一言で言えば「SCRIPT」です。
「SCRIPT」とは、R.C.Schankの提唱していた「CD理論(Conceptual dependency theory)」の中の一つで、人間の行動の大部分がある種のパターン(台本)に当てはまるという理論です。 人間の行動のうちの「手続き的動作」について説明するためのものです。
しばしばSCRIPTの例に挙げられる「レストランスクリプト」だと、
- お店に入る
- 席を探す
- 着席する
- 注文する
…
というような一連の動作が「SCRIPT」であるというわけです。 元々は「SCRIPTがわかれば次に何をするかわかる」的なものでした。
AIエージェントの思考も、これを応用すれば良いではないかというのが今回の着想です。 つまり、
- ユーザが入力する
- その入力に対応するSCRIPTを識別する(探す)
- そのSCRIPTに従って思考する
- 結果をユーザに返す
というのが、Huishiの「思考」です。 この「思考」の過程で、細かいタスクを処理する専門的なエージェントがあって、そのエージェントをSCRIPTでオーケストレーションするというのが基本構造です。
以下はこの概念的な図です(実装は異なります)。
個々のエージェントは、ほとんどがMarkdownかYAMLで記述されていて、「特別な処理(DB検索とか外部アクセスとか)」のみがハードコードです。
SCRIPTはYAMLで記述で記述されます。 「あれやって、これやって」を列挙するだけですから、YAMLが一番書きやすかったという理由です。 とは言え、エージェントの動作と組み合わせて、Turing完全になるようにはなっています。
従来の手法との比較
今回提案する手法は、いずれの手法にも属さない手法であると共に、これらのデメリットを補う手法です。
- LLMとSCRIPTによる制御
- 特徴
- 静的に定義されたSCRIPTに description を持たせ、LLMがその内容を読んで選択
- SCRIPTを順序実行(分岐あり)
- 必要があればさらに追加の処理も可能
- メリット
- 柔軟性が高く、未知のケースにも対応できる(SCRIPTの自動生成機能もあります)
- 動作が予測可能、テスト可能
- デメリット
- 唯一無二なので、実効性が未検証
効果
現在のところ良好に動いていて、当初の予定であった「ニュース解説」はもちろんのこと、効果のデモとして作った「数当てゲーム」も共存できています。 また、SCRIPTにない問いがあった場合でも、適当にエージェントを組み合わせて答えを出すようなSCRIPTを自分で生成して処理したりもしてくれます。
SCRIPTの途中キャンセルにもある程度対応していて、「数当てゲーム」の途中で「今日の天気教えて」と言えば、「数当てゲーム」を中止して「天気予報」を教えてくれたりします。
まだエージェントやSCRIPTが少ないので、これらを増やした時にどうなるかは、今後の課題となっています。 現状直接LLMに選択させていますが、この部分はスケールするように改修する予定でいます。
おわりに
私は発見できませんでしたがこれは単純なアイディアに過ぎませんから、既に誰かが発明して特許化しているかも知れません。
また、現状のHuishiの実装は初期段階に過ぎませんし、実効性の検証もまだまだなので、有効性についてはよくわかっていません。
そういったこともあるとは思いますが、とりあえずこうやってネットの海に放流します。 つまり、「少なくとも今日からは公知」です。
例によって「公知」となっていますから、私及び弊社は何の権利も主張しませんので、もし本当に有用であれば自由に使って下さい。 この手法をより「強く」する方法があれば、それも同じように公知にして下さると嬉しいですし、特許化されたら「基本アイディアは公知だ」と言いに行くかも知れませんｗ
おごちゃん
弊社でもコーディングにAIを活用するようになりました。
まだ完全自動コーディングは「おもちゃ」の域を出てないと言うか、それ以上の使い方をするにはコストがかかり過ぎるという感じがあるので、あくまでも「補助」としてしか活用していません。 まぁ、たまにホームラン級の効率を叩き出してくれることがあるので、ある種の期待がありますし、使ってみたりしてますけどね。でも、主には「補助」です。
あくまで「補助」として使っていても、以前と比較すれば効率は爆上がりです。 そうなると… さてどうしましょうかというのが、このエントリの主題です。
おごちゃん
Orcinusについてシステムリリースした話ばかり書いていましたが、このエントリでは商品としてのリリースを書きます。 つまり、販売価格と代理店について説明します。
おごちゃん
今日は6月6日なので、年に一度の「ぴろろんの日」です。
「ぴろろんの日」についての解説は前弊社のブログにあります。
要するに6月6日であるというだけですけどね。
この時期に元気でいられるのは良いことですね。
おごちゃん
「Orcinus」のリリースに合わせて、コアアプリケーションのHieronymus Ver 2.0をリリースします。
今回からはリポジトリは(現)弊社のものとなっています。 以前のリポジトリは今後更新されません。 前のリポジトリは結構スターがついててもったいない気もするのですが、会社も新しくなりましたので、新しいリポジトリです。
今までHiernymusは純粋な「会計システム」でしたが、今回からは会計以外の機能も持っています。
CassetteOS Orcinus Hieronymus オープンソース
おごちゃん
全社(と言っても二人なんですが)を挙げて作っていた「Orcinus」についての発表をしたいと思います。
「Orcinus」は今まで会計システムとして開発して来たHieronymusを強化してERPシステムに昇華し、これをCasaOSからforkしたCassetteOSに載せたものを、Cassette Serverにパッケージしたシステムと、それを運用するためのサービスやネットワークと思想を含んだ概念です。
これは「バックオフィスオールインワンのサーバ」として提供するもので、今月から受注を開始します。
直接弊社の話そのものではないのですが、RK3588のNPUのオープンソースドライバがLinuxメインラインに入るかも？ とゆー期待を持たせてくれるニュースがありました。
Rockchip Open-Source NPU Driver “RKNN” Continues Making Progress
みなさんGWしてますか？ 私はCatchUp(RSSリーダのことです)を強化するのが楽しくなって色々やっています。
AI agentの要領がわかって来たので、どんな構成にするとかどんなプロンプトにするとかやっていると、完全にハマってしまいますね。
というわけで、公開してから
- 思考構造の変更
- 雑談機能
- 文脈やペルソナの処理
とかを強化してしまいました。
おごちゃん
相変わらずHieronymusをいじっております。
やりたかったことはほぼ完成し、ちゃんと数字の合う決算書も作れるようになりました。 これで、会計システムの必要最低限のことは実装されました。
元々、帳票の部分はExcel表を出していたのですが、やっぱり「紙」イメージのものが出た方が良いので、全部Playwriterを使ったPDF出力に書き換えました。 これが結構難物で、結構面倒臭いことでしたが、まぁ面倒臭いだけで技術的に凄い難しいということはありません。
で、とりあえずHTMLを作ってPDF化をPlaywriterを使って… とやってみたのですが、ページの長さがどうも合いません。 ChatGPTとごちゃごちゃ相談するのですが、「設定忘れパラメータ」の類を設定しても合ってくれません。
しょうがないので、画面に出したもの(これはぴったり合ってる)をブラウザの印刷しようとすると、よく見たらこれも合っていません。
そこで表題のような話です。
