そのアプリ、本当に「AIエージェント」である必要がありますか？
そのアプリケーション、LLMがタスク管理の役割を担うのは本当に適切なの？
実は決定的な処理スクリプトでいいんじゃない？
「ブラウザで拾ってDiscordに送るだけの英単語収集＆復習基盤を作った（OpenClaw × SQLite）」記事を引用してますが、この記事を批判するものではありません。
あくまで「なんでもかんでもタスクをAIエージェントにやらせよう」という風潮に逆張り意見を述べているだけです。
むしろ、上記の記事はアイデアの元になったので、ありがたく拝読しました。
本記事では「AIエージェント」を「ひとつのシステム」という意味で使います。
AIエージェントの構成要素はLLMでもいいし、Bashスクリプトとか、ごっちゃなプログラムで構成されてるパイプラインというイメージです。
この記事で喜ぶであろう人々
なんでもかんでもAIエージェントの世の中に一言物申したい大きいお友達。
古い機材の再利用に喜びを見出す大きいお友達。
こんなものを作った
Discordをインターフェースにした単語帳アプリ。
単語の翻訳と用法説明部分は小規模LLM(Qwen 3 4B)が担当。
自宅のよわよわGPU (MX150 2GB)の上でQwen 3 4Bで十分に動作している。
ケース-1: フランス語🇫🇷の単語を単語帳に登録する
ケース-2: 日本語表現🇯🇵をフランス語🇫🇷でなんていうの？
システムはおよそ１リクエストを15-20秒で処理してくれてます。
ぶっちゃけ、単語の意味を知るだけなら、Chromeの辞書機能がリアルタイムに表示してくれて十分。
「あー、この単語は単語帳に残しておこ」的な気持ちでこのアプリを運用してます。
あらすじ: 世はまさにAIエージェント大航海時代
2026年になってOpenclawが大脚光を浴びるようになりました。まさにAI Agent大時代の到来です。
少しPCを詳しく触れる人なら誰でもノーコードでAI Agentを構築できちゃうお手軽さを認めざるを得ません。
私も勉強のためにOpenclawで何かアプリケーションを作ってみようと思いました。
ちょうどいい具体に「ブラウザで拾ってDiscordに送るだけの英単語収集＆復習基盤を作った（OpenClaw × SQLite）」という記事を見つけました。
なるほど、これはイイ。
以前の記事でも紹介した通り、私は言語学習ガチ勢です。
単語帳アプリを手軽に構築できるなら、最高ですね。
さて、さくっと作ってみて、我に返りました。
「これって、本当にOpenclawが必要なのだろうか？」
アプリケーションのロジックを検証してみる
さて、雑にアプリケーションの動作ロジックを説明します。
この処理フローは決定的(deterministic)でしょうか？確率的(Probabilistic)でしょうか？
答えは決定的です。
ユーザー（つまり私）が望むのは次の２つだけ。
- 「ほぼ定形文のメッセージを与えたときに、メッセージに記述された外国語の意味を説明してくれる機能」
- 「自動的にDBへ保存してくれる機能」
つまり、処理フローの全体だけを見渡すと、確率的なLLM1の推論はまったく不要で、必要なのは定義された処理ロジックを実行してくれるシステムです。
つまり、処理ロジックを記述したPythonスクリプトで十分なのです。
「いやいや、LLM推論してるじゃん」と思う人もいるでしょう。
確かに外国語の翻訳と説明文を生成する箇所でLLM推論を実行してます。
しかし、LLM推論に至るまでのパラメータは例外なく決定できます。
なので、決定的な処理フローで十分。
または、こう思う人もいるかもしれません。
「DiscordのメッセージのパージングでLLM推論が必要かもしれないじゃん？」
Discordのメッセージはほぼ定型文なので、そんなものは正規表現で処理すればいいだけの話です。
なので、決定的な処理フローで十分。
結論: このアプリケーションにOpenclawはいらんかった
Openclaw2の代わりに、Discordが送信したメッセージを処理するサーバースクリプトを作りました。
このサーバースクリプトを自宅のよわよわPC (N95 CPU, 8GB RAM)で実行しておしまい。
１週間ちかく、このアプリを運用してますが、何にも困ってません。
ご注文は本当にAIエージェントで良いんですか？
AIエージェントは確かに便利です。
てきとーなプロンプトを入力しても、なんかいい感じに解釈し、だいたい期待通りに実行してくれます。
しかし、その「いい感じ」にユーザー意図を汲んでくれるAIエージェントの正体は、それなりにでかいLLMです。3
それなりにでかいLLMはそれなりにコストを食います。4
すくなくとも、電力をそれなりに消費します5。
エネルギー供給問題が騒がれたり、そもそも地球温暖化の問題がまだまだ山積みな状況を考えると、無駄なエネルギーを消費しないに越したことはありません。
少し工夫するだけで全体の処理フローを決定的にできるなら、AIエージェントは不要です。
もちろん、個別の分解したタスクでLLMが必要になるでしょう。
しかし、少なくとも全体のタスクフローを管理するLLMは不要になります。
この手の話をするときに、いつも思い出す話があります。
「顧客が本当に必要だったもの (Tree Swing Cartoon)」というエンジニア童話。
https://qiita.com/e99h2121/items/accd534d1a3cac1ce4ca
Openclawが提供してくれるのは「営業の表現、約束」だけど、今回のアプリケーションに必要だったのは「顧客が本当に必要だったもの」というオチですね。
Openclawの方がいい要件とはなんだろう
1 入力が定型文で表現できないケース。このケースではOpenclawの方が向いているでしょう。わかりやすくいえば、汎用的なチャットシステムですね。
2 LLMの出力型の定義が難しいケース。
人間世界の知識は多岐にわたるので型の定義が難しいものです。
Wikipediaでさえ、部分的なテンプレートに限定されているのを考えれば、すべての知識へ型付するのは無理ゲーだとわかるでしょう。
この場合、LLMが自然言語で応答し、LLMが自然言語で応答を理解するという流れが妥当です。
なので、このケースでもOpenclawを採用した方がいいでしょう。
せっかくなのでアプリの自慢をする
アイディアの元にした記事「ブラウザで拾ってDiscordに送るだけの英単語収集＆復習基盤を作った（OpenClaw × SQLite）は十分に実用的な設計をしているのですが、私はもっと欲しくなりました。
なので、次の機能をつけました。
「日本語 -> 外国語」の逆引き対応
日本語を一切使わない環境で暮らしたことがある人ならわかると思うのですが、日常生活では「XXX（日本語）っていう概念をなんて言えばいいんだ？？」と困るケースのことの方が多いです。
なので、Discordから送信するメッセージに「日本語 -> 外国語」のケースを扱うメッセージ定型文を定義しました。
気が向いた時に解ける「クイズ機能」
私の好みの問題ですが、「決まった時間にクイズが出題される」よりも「オレが求めるときにクイズを解きたい」のが正直なところです。
なので、Discordからのメッセージにクイズ専用のコマンド #quiz を設定し、いつでもクイズを解けるようにしました。
クイズの出題は「エビングハウスの忘却曲線」と「不正解率」でスコア付し、スコア順に出題してます。
よわよわGPU + 小規模LLM
これ、一番自慢したい。
VRAM 2GBしかない「GeForce MX150」で、Qwen-3 4Bが動いています。
私も本当に動くとは思ってなかったので、けっこー驚きました。
こんなに弱いGPUを利用してるのは、たまたま家に転がってたPCが積んでたGPUがこれだったから、というだけの話です。
Qwen 3 4Bはかなり小規模LLMに分類されるわけですが、自然言語の翻訳程度くらいならこれで十分です。 6
ただし4Bレベルの小規模モデルで注意したいのは、コンテストの制限です。
4Bクラスのモデルに複数の命令を一気に命令すると、不安定な動作をしがちです。
なので、たかが翻訳と用法説明のタスクでも、次のように３タスクに分割しました。
- 文を指定の言語へ翻訳するタスク
- 「わからない」と指定した単語の翻訳を発見するタスク
- 「わからない」と指定した単語の用法を説明するタスク
LLM呼び出しを3回も実行するのが無駄(CPU <-> GPUのオーバーヘッド)になりそうな気もしますが、結果的にタスク分割したほうが全体が早くなりました。
-
厳密にはLLMは決定的なモデルにすることも可能。Next token predictionタスクの $\tau$ パラメータを0.0にすればいい。けど、Prompt(conditional)を少し変更するだけで、出力が変化するという点では、やっぱり確率的モデルの側面が強い、と思う。 ↩
-
v2026.03.24時点でLLM推論をまったく経由しないパイプライン処理をOpenclawで定義するのは無理っぽい様子でした。少なともく「できる」と書いたドキュメントが見つからなかった。bindingは近いことを実現したい様子でしたが、それでもLLM推論を経由する仕組みになってました。 ↩ -
少なくとも小規模LLMでは無理でした。Qwen 4BモデルにOpenclawのAIエージェントを担当させようとしたが、動かなかった。コンテクスト長がオーバーしてしまうらしい。Agent.mdやらSkill.mdやらのファイルがコンテクストを圧迫するのだろう。 ↩
-
とはいいつつ、それなりに動くモデルGemini Flash は１日に1,000 callも無料枠があるんだけどネー。 ↩
-
"Measuring the environmental impact of AI inference"によると、1推論あたり0.10 Whの消費電力らしい。 ↩
-
そもそも、もっとモデルがもっと小さかったBert時代でもそれなりに翻訳タスクは解けていたので、その頃に比べれば4Bは立派なものです。 ↩