慧仕(Huìshì)の思考構造(公知化情報)

「慧仕(Huìshì)」というAIエージェントフレームワークを作っています。

Huishi(以下この記法にします)の詳細についてはまたそのうち書くとして、これで使っている「思考構造」について公開したいと思います。これは、世の中にある様々なAIエージェントを調べていて、類似の構造のものがなかったからです。

「なかった」理由はよくわかりません。有効でないと考えられているのか、そこに考えが至らなかったのか、その辺はよくわかりません。とは言え、「なかった」のは事実なので、文章にまとめて公開して公知にしておきます。そうすれば、少なくとも私が使えないことはないからです。

背景

以前、CatchUpというニュース解説のエージェントを作っているという話はしました。

RSSリーダを作りました

"CatchUp(RSSリーダ)"の強化

元々が「お好みのニュースを楽して読みたい」という希望から作ったものですが、裏の背景として「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の自動生成機能もあります)
- 動作が予測可能、テスト可能
デメリット
- 唯一無二なので、実効性が未検証