株式会社ずんだもん技術室AI放送局 podcast 20251204

youtube版(スライド付き)

関連リンク

• AI エージェント開発で失敗しないための 10 のデザインパターン - フレームワークに依存しない設計の共通言語を定義する

AIエージェント開発は、LangGraphやAutoGenのようなフレームワークのおかげで手軽に始められるようになりました。しかし、「制御が難しい」「無限ループでコストがかさむ」「デバッグが大変」といった問題に直面することも少なくありません。これは、ただフレームワークを使うだけでなく、「どんな構造でAIエージェントを設計すべきか」という共通の考え方（デザインパターン）が不足していることが原因だと筆者は指摘します。

この記事では、AnthropicやLangGraph、DeepLearning.AIなどの最先端の知見を元に、AIエージェント開発で役立つ10のデザインパターンを体系的に紹介しています。これにより、特定のフレームワークに依存せず、皆さんのプロジェクトに合った最適な設計を選べるようになることを目指しています。

最も大切なのは、「まずシンプルに始める」という考え方です。エージェントの複雑性は、以下の3段階で考えると良いでしょう。

1. Level 1: 単一プロンプト: 最も基本的な形です。LLM（大規模言語モデル）を一度呼び出して、要約や翻訳、単純な質問応答を行います。多くのタスクはまずこのシンプルさで解決できないか検討すべきです。
2. Level 2: Workflow（決定論的）: 事前に決められた手順で処理を進めるシステムです。LLMは一部の判断やデータ処理を担当しますが、全体の流れはコードで制御されます。例えば、複数のステップで情報を処理する「Prompt Chaining」や、質問内容に応じて処理を振り分ける「Routing」、タスクを分担して処理する「Orchestrator-Workers」などがあり、予測しやすくデバッグも比較的容易です。
3. Level 3: Agent（自律的）: LLM自身が「次に何をすべきか」を判断し、作業を繰り返すシステムです。例えば、「思考→行動→観察」を繰り返して問題を解決する「ReAct」や、まず計画を立ててから実行する「Planner-Executor」があります。これは非常に柔軟ですが、制御が難しく、コストも高くなりがちです。Level 1や2では解決できない、先の読めない複雑なタスクに限定して導入を検討しましょう。

これらの主要なパターンに加え、AIエージェントの品質や信頼性を高めるための補助的なパターンも紹介されています。例えば、LLM自身が自分の出力を見直して修正する「Reflection/Critic」や、大事な決定を人間が承認する「Human-in-the-Loop」などです。

AIエージェント開発を成功させるには、「とりあえず複雑なエージェントを作る」のではなく、「まずLevel 1や2で解決できないか試す」という段階的なアプローチが重要です。もし複雑なAgent（Level 3）が必要になった場合でも、必ず「Human-in-the-Loop」のような安全策を講じることが推奨されています。

結論として、どのフレームワークを使うか悩む前に、「目の前の課題を解決するために、どのデザインパターンが最もシンプルで確実か？」という問いを自分に投げかけてみましょう。流行のツールに飛びつくのではなく、まず「型」で考えることが、AIエージェント開発を成功させる鍵となるでしょう。

引用元: https://zenn.dev/loglass/articles/c7f4499ec8320b

• AIエージェント×因果グラフでLLMをテストしてみた：広告データで「調整すべき変数」を選ばせる（LangGraph実装付き）

この記事では、最新のAI技術であるLLM（大規模言語モデル）と「因果グラフ」という考え方を組み合わせ、AIが「なぜ？」という因果関係をどこまで理解できるかを検証する画期的な試みを紹介しています。特に新人エンジニアの方にも分かりやすく、その仕組みと意義を解説します。

データサイエンティストがLLMを使う際、「AIは本当に物事の因果関係（原因と結果）を理解しているのか？」という疑問を持つことがあります。例えば、「広告費を増やすと売上は上がるか？」という問いに対し、LLMはもっともらしい答えを返しますが、季節変動やキャンペーンといった「裏の影響（バックドアパス）」が隠れている可能性があります。これらの影響を公平に取り除き、純粋な広告費の効果だけを見るためには、「調整すべき変数」を正しく選ぶ必要があります。

そこでこの記事では、「因果推論テスト用のAIエージェント」を開発しました。このエージェントは、以下の2つの役割を持つ要素で構成されています。

1. LLM（ここではGemini）: 因果グラフ（変数間の関係を矢印で示した図）の情報をもとに、「公平に比較するために調整すべき変数」を提案する役割。
2. Pythonコード（自作のd-separationチェッカー）: LLMが提案した変数の組み合わせが、因果推論のルール（バックドアパスを適切に閉じるか）に照らして本当に正しいかを機械的に検証する役割。

この二つの役割をスムーズにつなぎ、全体を一つのワークフローとして動かすのが、LangGraphというフレームワークです。LangGraphは、LLMの思考ステップとPythonによる論理的なチェックステップを連携させる「司令塔」のような役割を果たします。

具体的な例として、広告費（AdSpend）と売上（Sales）の因果関係を調べたい場合を想定します。もし季節（Season）が広告費にも売上にも影響しているとしたら、「Season」を調整することで、純粋な広告費の効果が見えやすくなります。エージェントを動かした結果、LLMは「Season」を調整変数として提案し、Pythonコード側もその提案が「妥当である（backdoor_ok -> True）」と判断しました。

この試みは、LLMの柔軟な発想力と、コードによる厳密な論理チェックを組み合わせることで、AIがより信頼性の高い分析支援ツールとして機能する可能性を示しています。単にAIに答えを求めるだけでなく、その答えが論理的に正しいかを自動で検証する枠組みは、これからのAI活用において非常に重要になるでしょう。

引用元: https://techblog.insightedge.jp/entry/langgraph-agent-causal-inference

• Evaluating Deep Agents: Our Learnings

LangChainのブログ記事「Evaluating Deep Agents: Our Learnings」では、より高度なAIエージェントである「Deep Agents」の評価方法について、実践から得られた貴重な学びが共有されています。新人エンジニアの方にも分かりやすく、Deep Agentsの評価がなぜ重要で、どのようなポイントがあるのかを解説します。

Deep Agentsって何？なぜ評価が難しいの？

Deep Agentsは、単一の質問に答えるだけでなく、ツールを使いこなしたり、過去のやり取りを覚えてたりしながら、複雑なタスクをこなすAIです。普通のAIよりも賢く、まるで人間に近い動きをするため、その性能を評価するのが少し難しいんです。なぜなら、最終的な答えが合っているかだけでなく、そこに至るまでの過程や、エージェントが記憶した情報などもチェックする必要があるからです。

LangChainがDeep Agentsを開発・運用する中で見えてきた、評価の重要な5つのポイントを見ていきましょう。

1. 各テストケースに合わせた独自のチェックが必要

従来のAI評価では、すべてのテストに対して同じ基準でチェックしていました。しかし、Deep Agentsの場合、テストごとに「このエージェントは特定のファイルを編集したか？」「ユーザーにその変更を伝えたか？」のように、細かく異なる成功条件を設定してチェックする必要があります。LangSmithの機能を使うと、このようなきめ細かい評価が可能です。

2. エージェントの「次の一手」だけを評価するのも効果的

エージェントが長い一連の作業をする中で、どこかで間違った判断をしてしまうと、その後の作業も全て台無しになってしまいます。そこで、「次の一手」だけが正しいか（例：適切なツールを選び、正しい引数で呼び出したか）を評価する「シングルステップ評価」が役立ちます。これにより、問題点を早期に発見でき、無駄な計算（トークン消費）も減らせます。

3.