エージェント設計とは？
前回の記事では、ローカルLLMの使用感をベースにした内容をまとめました。
次のステップとして、このLLMを組み込んだ「エージェント」を構築する中で、設計面において重要だと感じたポイントについて、今回は詳しくお話ししたいと思います。
使用モデル：Gemma4 E2B
※テストをする際は、まず軽いモデルを使ってうまく作動するかを確認した後で
高性能モデルに切り替える方が良いと思います。（デバッグが速く、構造の問題なのかモデル側の問題なのか切り分けしやすいためです）
LLMに検索エンジンをつけて「今日の天気を教えて」と聞けばどうなるのでしょうか？
duckduckGO(検索ライブラリー)を使った場合
どうですか？ちなみに
私の場合は、天気や今日というキーワードが入ってきたら必ず検索するように設定しておいたため、ここまでできたのです。
強制検索設定がない場合は？
住んでいる所を教えてあげても答えられないんですけど
このように答えてくれました。
単に「今日の天気を教えて」と聞くだけでは、検索機能があっても必要な情報が足りず、正しく答えられません。
軽量モデルの場合、パラメータ数が少なく複雑な推論が苦手なため、
検索ツールを利用できる設定であっても、適切に機能しないことがあります。
たとえば「2026年4月の○○会社の株価情報を教えて」と入力された場合、
モデルは「不明な情報は検索ツールを呼び出す」という指示よりも、
「2026年の情報は学習データに存在しない（Gemma 4の場合は2025年1月時点まで）」
という安全基準を優先してしまうことがあります。
その結果、検索ツールを利用する手順をスキップし、
回答そのものを拒否してしまう現象が発生します。
そのため、プロンプトで非常に細かくルールを設定する必要があります。
- 天気、ニュース、株価などのリアルタイム情報は無条件で検索する
- 時間に関連するキーワードを含む場合も無条件で検索する
- 2025年以降の出来事は無条件で検索する（モデルの学習時点に合わせる）
といったルール付けです。
また、整理されたデータをLLMに渡すことも非常に重要です。
たとえば「天気を教えて」と指示した場合、
単純に検索エンジンで「今日の天気」と検索するだけでは、不要な文章や広告、関連リンクまで大量に取得してしまいます。
DuckDuckGoライブラリで検索した時に何を受け取ってくるのかを出力させてみました。
今日の天気に関連する内容は、ほとんど見当たりませんよね？
AIは、ユーザーがどこに住んでいるのか、現在何時なのかといった情報も持っていません。
そして、ユーザー情報を利用できる検索エンジンを接続したとしても、
本来であれば「晴れ、25度」といった必要な情報だけ取得できれば十分なのに、不要な情報まで大量に取得してしまいます。
そのため、
「天気関連のキーワードが含まれているかを判断する」
→ 「天気関連であれば get_weather(location='○○市') を呼び出す」
→ 「気象庁のDBから必要なデータを取得する」
→ 「AIがデータを整理し、『現在の天気は曇りで、気温は21度です』と出力する」
このような流れで動作するよう設計することが重要だと思います。
また、天気APIがエラーになった場合はどうするのか？
その場合は、代替手段としてウェブスクレイピングを実行して回答する、といった追加のエラーハンドリングを設計することもできます。
最終的には、エージェントに不可欠な「思考をループさせる」という概念が重要になります。
利用者への回答が完成した後も、
もう一度プロンプトを通して、利用者の要求を満たしているか確認させます。
2026年4月の情報を求められているのに、
出力しようとしているのは2026年3月の情報だ。条件が一致するまで、もう一度調べ直そう。
このように、AI自身が回答を検証し、
論理的な矛盾や条件のズレを修正しながら、正しいと判断できるまで繰り返し処理を行います。
まとめ
結局、ローカルLLMを使うということは、巨大な脳（クラウド）を借りて使うことから脱却し、自分の好みに合わせて動く手足を自ら組み立ててみることであります。
指先まで思い通りに動かそうとするのは、想像以上に大変でした。
ですが、その分「なぜ動かないのか」を考える機会も増えるので、個人的にはかなり面白かったです。
小さいモデルでも設計次第でかなり賢く動くので、興味があればぜひ試してみてください。
