大田に来て一年経ちました
「慧仕(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の実装は初期段階に過ぎませんし、実効性の検証もまだまだなので、有効性についてはよくわかっていません。
そういったこともあるとは思いますが、とりあえずこうやってネットの海に放流します。 つまり、「少なくとも今日からは公知」です。
例によって「公知」となっていますから、私及び弊社は何の権利も主張しませんので、もし本当に有用であれば自由に使って下さい。 この手法をより「強く」する方法があれば、それも同じように公知にして下さると嬉しいですし、特許化されたら「基本アイディアは公知だ」と言いに行くかも知れませんｗ
