今更ですが、流行りのLLMエージェント（OpenClawとか…）の仕組みを学びながら、可愛くて有能なメイドさんを雇用しようという試みです。

概要

Ancilla-Bot クラウドに依存しない常駐型のローカルLLMアシスタントです。

OpenClawの後追い劣化エージェントの一体。

まあ、それは置いておいて……

このプロジェクトの個人的な狙いは、次の3つです。

• 最近のLLMエージェントの仕組みを学ぶ
• ローカル環境だけで完結する安心感（外部API前提にしない）
• 常駐して動く道具にする

ほぼ前回の記事に統合・拡張する形での作成となります。

LLMエージェントの構成要素

さて、LLMエージェントの構成要素って何なんでしょうか？

この分野はまだ発展途上なので、いろいろ定義がありますが、個人的には以下の3つが有名どころだと思ってます。

大まかな傾向として、MemoryとTools/Actionはほぼ共通で、3つ目に何を置くかで思想の違いが出る感じですね。

• 「どう考えるか」重視 → Planning / Reasoning
• 「どう連携するか」重視 → Subagents

もう少し詳しく見ていきましょう。

Lilian Weng「LLM Powered Autonomous Agents」(2023)

これは元OpenAIの研究者の人のブログですね。

LLMがエージェントの頭脳として機能し、Planning / Memory / Toolsの3要素で構成されるとしています。

• Planning: タスクを小さなサブゴールに分解し、過去の行動を自己批判・改善するReflection能力も含む
• Memory: コンテキスト内の短期記憶と、外部ベクトルDBを使った長期記憶の2層構造
• Tools: 外部API・検索・計算機など、実世界とのインターフェース

ほぼこれがプロジェクトの基幹になっています。

ReAct「Synergizing Reasoning and Acting in Language Models」(2022)

安心と信頼のGoogleの論文です。

LLMに「思考（Thought）→ 行動（Action）→ 観察（Observation）」のサイクルによって、推論が行動の方向性を決め、行動から得た情報が次の推論を改善するというのを繰り返させます。
構成要素というよりかはサイクルが近いですね。ReActは現在のLLMエージェントの基本的な設計思想に直結しており、ツールを使いながら推論するエージェント（Claude、GPT等）の原型です。

Anthropic「Building Effective Agents」(2024)

ClaudeのAnthropic君（はよモデル劣化直せ）の提唱するエージェントです。エージェントシステムの基本構成要素は、Retrieval・Tools・Memoryで拡張されたLLMであり、モデル自身が検索クエリを生成し、適切なツールを選び、何を記憶するかを判断できるらしいです。

これに加えて、マルチエージェント構成としてSubagentsの概念を追加しています

• Memory : コンテキスト外への情報保存・参照
• Tools : 外部サービス・環境との連携
• Subagents : 専門化されたサブエージェントへのタスク委譲。サブエージェントは独立してタスクをこなし、大量のトークンを使って作業しつつも、圧縮・要約した結果だけを親エージェントに返す

要は、「人間とやり取りしたり計画を立てたりするメインのエージェントと、実際に作業をするエージェントを分けましょう」って話ですね。

設計

では、これを踏まえた上で設計に移りましょう。長々とまとめましたが、結局のところOpenClawにある機能を小さく実装していくだけです。

1. LLM

コアとなるLLMは、当然ローカルです。
まあ、ちょっと弄るだけで外部APIも叩けるんですが

モデルの選定ですが、当初はQwen3を使用していました。しかし、2026/5現在はQwen3.5やQwen3.6、Gemma4など、より性能の高いオープンモデルが公開されているので、そちらを使っています。

まあ、なんでもいいと思いますよ。
ただし、画像を読み込ませたいので視覚対応モデル（VLM）であった方がいいでしょう。

2. ReAct

先述のReActです。これがないとお話にならない.。

3. Tool

このプロジェクトでは、例えば次のようなツール群を持たせています。

• web_search, fetch_page（Web情報の取得）
• read_file, write_file, edit_file_safe（ワークスペース操作）
• bash（コード実行）
• manage_state, search_memory, update_memory（状態/記憶操作）
• notify_user（通知）

できることはあればあるほどいいのですが、ツールを提供しすぎると、そこまで性能のよいLLMを動かせない以上、処理がおぼつかなくなるので、非推奨です。

これらツールは呼び出された時点で、メインのLLMからは切り離された、独立したセッションとしてサブエージェントが処理します。これにより、会話履歴の肥大化や汚染を防いでいるわけです。
つまり、メインエージェントとサブエージェント間で受け渡されるのは、指示と要約だけってことです。

4. 短期記憶（会話コンテキスト）

直近の対話を保って、文脈を崩さないための層です。

と言っても、ただの会話履歴です。
無限に積むとコンテキストが破綻するので、上限管理が必要です。

• 最大保持数（ここでは簡単に文字数）で肥大化を抑制
• 圧迫時は要約に逃がして会話継続性を維持

5. 長期記憶

会話ログを要約して保存し、必要時に検索で引き戻すことで、長期的な一貫性を作ります。

• バッチ要約
• 後述する Slow Heartbeat で定期的（深夜帯など）に要約
• search_memoryで関連過去情報を再注入

なんかもうちょっと要領のいい方法はないものか……

6. 常駐化

ただのn番煎じです。LLMアシスタントエージェントは、この機能で定期的に実行されることによって、バックグラウンドでの活動、つまり、自律感や常駐感を演出しています。

• Fast Heartbeat: リマインダーなど即時寄りイベント
• Slow Heartbeat: 要約など重め・定期処理

この層があると、ユーザー操作がない時間にも仕事を進められるってことですね。

といった感じで設計しています。

特筆すべき点はありません。

微妙な工夫点（未公開）

これだけだと面白みがないので、エッジデバイスと連携する機能も入れました。ノートPCやタブレットにアクセスして、カメラ映像やマイク音声を取得できます。また、TTS APIによってしゃべることもできます。
これらの機能は、エージェントを立ち上げた際に同時に立ち上がる WebSocket サーバーによって提供されます。

• クライアントが status_update(active) を送る
  • または、エージェントがエッジデバイスに接続要求を送る
• 必要に応じてvision_inputで画像を送る
• audio_inputで音声を送る
• サーバー側で STT -> ReAct -> TTS を回す
• agent_responseがテキスト+音声で返る

ちなみにこのエッジデバイスでのセッションはユーザーが呼び出すこともできますし、エージェント側から勝手に開始することもできます。
メイドさんに監視されながら生活できるってことですね。
ついでに感情パラメータも出力させて送っているので、Live2Dモデルを操作したりもできます。

これ（エッジデバイスクライアント側）は残念ながら粗削りすぎて未公開です。しかし、WebSocket サーバーは現在のプロジェクトにもありますので、クライアント側だけ書けばどうにかなります。

実現できること

• メイドさんに予定管理してもらう
• メイドさんに論文読んでもらう
• メイドさんに監視されながら作業
• メイドさんと作業通話

まあ、だいたい何でもできるんじゃないんですかね。

おお

いまの課題

同じ報告を繰り返したり、異常にキーボードに固執したりします。
（現在は解決済み）

OpenClawやHermesの足元にも及びません。
完全に劣化エージェントです。
この程度の機能を持った上位互換プロジェクトなんぞ、世に無数に存在します。

単純にシステムの最適化不足もありますが、現在の構成ではLLMの性能がものを言います。
つまり、でかいオープンウェイトモデルを動かせるだけの計算資源が必要ってことですね。
（プロンプトが悪い説もある）

結論

可愛ければいいんだよ。可愛ければ