こんにちは。Kaggle Masterの阿田木です。

昨今、生成AIの応用先として生成AIエージェントが話題を集めています。

生成AIの進化が目覚ましく、生成AIエージェントがさまざまな分野で活躍する可能性が広がっています。

データ分析のような複雑なタスクにおいて使用されるようになってきており、世界的なデータ分析コンペティションであるKaggleにおいても例外ではない状況となってきています。

そこで、Kaggleにおける生成AIエージェントの現状と活用方法について、数回にわたって深掘りしていこうと思います。

※生成AIエージェントとは、目的を達成するためのタスクを生成AIが考え、自律的に実行するシステムです。生成AIエージェントについてさらに詳しく知りたい方は以下の記事を参照ください。

https://aitc.dentsusoken.com/column/llm_agent_column_summary

Kaggleと生成AIエージェントの現状

Kaggleでは、生成AIエージェントを活用したベンチマークやフレームワークが登場し始めています。

Kaggleで活用されているエージェントの一覧

ベンチマーク・フレームワーク	内容
MLE-Bench	MLE-Benchは、OpenAIが開発した機械学習エージェントの能力を評価するためのベンチマークです。このベンチマークは、Kaggleから選ばれた75の機械学習コンペティションを基にしており、データセットの準備、モデルの訓練、実験の実施といった、実務に求められる広いスキルを評価します。
AutoKaggle	AutoKaggleは、Kaggleコンペティションの課題を解決するための協調型マルチエージェントフレームワークです。このフレームワークは、カスタマイズ性が高く、データサイエンティストがデータパイプラインを効率的に完了できるように設計されているユーザ中心のフレームワークです。
kaggle-Agent	kaggle-Agentは、Kaggleコンペティションの課題を解決するための生成AI駆動の自動化ツールです。このエージェントは、スクレイピングやデータ分析、計画、コーディングなど、データサイエンスのワークフローを向上させることを目的としています。

上記のエージェントは、データ前処理、特徴量エンジニアリング、モデル選定、チューニング、予測の最適化といった多岐にわたるタスクの自動化と精度向上を目指しています。

現状の性能を確認すると、過去コンペでは銅メダル相当の性能を発揮しておりますが、まだKaggle Master（金メダルをとれるレベル）ほどの性能は期待できなさそうです。また、現在進行形で実施されているような新規性の高いコンペティションでは、メダル獲得も難しいのが実情かと思います。

しかし、生成AIの進化速度を考慮すると、近い将来、より高度なモデルやアーキテクチャの開発により、Kaggle Master/Kaggle Grandmaster相当の性能を持つエージェントが登場する可能性も否定できない状況かと思います。例えば、OpenAIの最新モデル“o1”は、推論能力が非常に高く、この分野での活用が期待されています。また、2024年の年末に発表されたo3に関しては、競技プログラミングでは世界175位と同等レベルを保有しているとも言われており、純粋なコーディングでは人間は勝てない世界となってきております。

Kaggleにおいては、既存手法の実装であれば現状の生成AIでも十分対応できそうな範囲なので、専用のエージェントを作成し、作業を委任することが可能です。一方で、上位入賞者の解法のようにKaggleのコンペ用に提案される独自の手法は、データを丁寧に分析した上で考え出されるので、難易度が高いものとなります。この点を生成AIエージェントで実現できる場合、人類の知能を超えるという意味でシンギュラリティやArtificial Superintelligence（人工超知能）の実現ともいえるくらいの難易度であると思います。

上記を踏まえると、現状は機械学習モデルのチューニングや既存手法の試行は生成AIエージェントに任せ、人間は分析結果からインサイトを得ることに集中するという世界をまずは実現していくのが第一ステップと思います。これら工程の言語化、形式化（特に、Kaggle Grandmasterレベルのスキルとノウハウの一般化）が進んだ場合は、より難易度の高いタスクを生成AIエージェントに任せることも可能になってくるかもしれません。

シングルエージェントとマルチエージェントの違い

Kaggleで活用できる生成AIエージェントについて、もう少し理解を深めるために、生成AIエージェントの特徴やアプローチを確認します。

以下に生成AIエージェントの要素を整理します。

生成AIエージェントの4つの要素

要素	意味	メリット
プランニング	ゴール達成に向けて、タスクをどのように進めるかをLLMが立案するプロセス。	大きなタスクや複雑なタスクを分割し、手順を明確にしてから実行できる。
ツールの使用	LLM自身だけでは行えない操作・機能（例: Web検索、計算ツール、DBアクセス）を外部のツールを呼び出すことで実現するプロセス。	外部機能との連携により、より複雑かつ現実的なタスクを実行可能。
リフレクション	LLMが自らの出力を振り返り・見直し、修正・改善を行うプロセス。	出力の質向上、誤りの検知などを自律的に行う。
マルチエージェント協働	複数のエージェント同士が協力・競争しながら、より複雑なタスクや対話を実現する枠組み。	各エージェントが別の専門性・視点を持つことで、高度なシミュレーションや問題解決が可能。

参考：Four AI Agent Strategies That Improve GPT-4 and GPT-3.5 Performance

ほとんどの生成AIエージェントは上記の要素を組み合わせて実現することができます。

次に生成AIエージェントのアプローチ方法を見ていきます。

生成AIエージェントにおけるアプローチは、シングルエージェントとマルチエージェントの2つに大別することができるかと思います。

シングルエージェントとマルチエージェントの違いについては色々な考え方があると思いますが、以下では、論文やエージェント開発フレームワーク（LangGraph等）でよくみるパターンをもとに簡単に紹介していきます。

シングルエージェントの概要

シングルエージェントシステムは、単一のエージェントが環境と相互作用し、タスクを遂行します。与えられた目標に向かって独立して行動し、必要なデータを収集し、意思決定を行います。シングルエージェントは、比較的単純なタスクに対して効果的であり、実装も容易です。例えば、特定のデータを分析してレポートを生成するタスクなどが該当します。

マルチエージェントの概要

一方、マルチエージェントは、複数のエージェントが協力してタスクを遂行します。これらのエージェントは情報を共有し、連携してより複雑なタスクをこなすことができます。マルチエージェントは、エージェント間の相互作用を通じて、エラー耐性や信頼性を向上させることが可能です。例えば、異なるエージェントがそれぞれの専門分野に基づいてタスクを分担し、協力して問題を解決するシナリオが考えられます。

※マルチエージェントに関しては同グループの太田さんがまとめてくださっているので、ぜひ参考にしてください。

https://aitc.dentsusoken.com/column/What_can_LLM_Multiagents_do

主な違い

構造: シングルエージェントは単一のエージェントで構成され、マルチエージェントは複数のエージェントで構成されます。
タスクの複雑さ: シングルエージェントは比較的単純なタスクに適しているのに対し、マルチエージェントは複雑なタスクを効率的に処理できます。
協力と情報共有: マルチエージェントはエージェント間での協力や情報共有が可能ですが、シングルエージェントは独立して動作します。

このように、シングルエージェントとマルチエージェントは、それぞれ異なる特性と利点を持っており、特定のアプリケーションやタスクに応じて使い分けが必要です。

Kaggleで活用されるエージェントの多くは、マルチエージェント構成を採用しています。これは、データの前処理や分析、モデル選定、ハイパーパラメータ調整や改善など、Kaggleでの作業が多岐にわたるため理にかなっていると言えます。一方で、シングルエージェントは1つのエージェントで全てのタスクをこなす仕組みを目指しており、その構造は非常に洗練されています（特に、プランニング、ツール利用、リフレクションに忠実な設計）。

マルチエージェント構成においても、個々のエージェントの質が重要であり、シングルエージェントのアプローチを理解することで、各エージェントを高度に洗練させることができます。

そこで、今回は、まずはシングルエージェントに焦点を当てて、代表的な実装手法をみていきます。

シングルエージェントの代表的な実装手法

今回の記事では、シングルエージェントの理解を深めるため、以下の3つの代表的な実装手法（ReACT / Plan-and-Execute / LATS ）について、LangGraphを用いた実装例としてご紹介します。

※LangGraphは、ステートフルなエージェントやワークフローを作成するためのライブラリです。 LLMエージェントのステップなどをグラフ化して状態管理を行うことができます。以下はツールに文章検索を用いたRAGチャットボットのグラフ例です。

※LangGraphでのエージェント実装については以下の記事で詳細に説明しているので参考にしてください。

https://aitc.dentsusoken.com/column/How_to_implement_workflows_for_generative_AI_agents

各手法（ReACT / Plan-and-Execute / LATS ）の概要は以下の通りです。

1. ReAct

ReActは、動的に計画を立てながら行動するエージェント設計です。この手法はタスクごとの柔軟性が高く、未確定のタスクに対しても適応できます。

2. Plan-and-Execute

Plan-and-Executeは、計画と実行を明確に分けるエージェント設計です。タスクを事前にサブタスクに細分化し、それぞれのステップを効率よくこなす構造が特徴です。

3. LATS（Language Agent Tree Search）

LATSは、ツリー型の探索を基にした動的計画を重視したエージェント設計です。モンテカルロ木探索を用いて、エージェントが複数の選択肢を評価し、最適な行動を選択することを可能にします。

以下に、生成AIエージェントの4つの要素（リフレクション、ツール使用、プランニング、マルチエージェント協働）と、ReACT / Plan-and-Execute / LATS との関係を整理した表を示します。

※シングルエージェントのためマルチエージェント協働は割愛

手法	プランニング (Planning)	ツール使用 (Tool Use)	リフレクション (Reflection)
ReACT	ユーザーリクエストやリフレクションの結果をもとに次に実施するタスクを考える（タスクの分解はしない）。	行動（Acting）の一部としてツールを使用。	各ステップの行動とその結果を評価し、次の行動計画に反映。
Plan-and-Execute	目標を細分化し、実現可能なサブタスクに分割します。	サブタスクにおいて、ツール使用が必要な場合はサブタスクごとにツールを使用。	実行結果を振り返り、計画の見直しが必要な場合は再計画を実施。
LATS	MCTSによる動的な探索・計画を行い、各ステップで計画を調整しながら最適な行動を選択する。	各選択肢の評価プロセスや探索段階で必要に応じてツールを活用し、評価結果に反映。	モンテカルロ木探索（MCTS）に基づき、探索結果を評価し、適切な選択肢を選ぶ過程で継続的なリフレクションを実施。

これらの手法を、同じ問題設定を用いてそれぞれの挙動を比較し、Kaggleでの活用方法を検討します。

※あくまで、手法を紹介することに重きを置いているため、Ｋaggleっぽい問題設定でない点はご容赦ください。

ReAct

ReActはもっとも基本的なエージェントアーキテクチャなので、実装もシンプルです。

LangGraphではcreate_react_agentクラスが用意されており、必要な実装はツールだけです。

ツールは、生成AIエージェントが外部環境などから情報を取得したりするために用意されます。

例えば、RAGの仕組みなどが該当します。

特徴

ReActの基本的な仕組みは以下の通りです。

ReActでは、計画と実行を厳密に分けるのではなく、以下のような流れでタスクを遂行します。

入力（質問やゴール）を受け取る。
必要に応じてツールを呼び出す。
ツールの結果を基に次の行動を決定する。

これにより、状況に応じて柔軟に対応することが可能です。

以下では、WEB検索ツールを用いることを想定して話します。

Duckduckgoなどのライブラリを使用することで簡単に実装することができますが、詳細な実装はここでは省略いたします。

WEB検索ツールには以下のツールを定義することにします。

web_search：ユーザーの質問からテキストベースの検索を実施し該当のURLを取得するツールです。
web_page_reader：該当のURLからWEBページ情報を取得することができらツールです。

ReActのアーキテクチャ

LangGraphで実装した場合、以下のグラフで表現できます。

エージェントは目的（質問）を達成するためにツールを利用します。

ReActについては、前述の通り、LangGraphではcreate_react_agentクラスが用意されているので、

使用する場合は以下のコードだけで使用可能です。

tools=[web_search,web_page_reader]
graph = create_react_agent(llm, tools=tools)

toolsにはWEB検索ツールを利用します。

llmはOpenAIのAPIを利用する場合は以下のようにして定義することができます。

import os
from dotenv import load_dotenv
from langchain_openai import ChatOpenAI

load_dotenv()  # これにより.envファイルが読み込まれます
api_key = os.environ.get("OPENAI_API_KEY")
deployment_name = os.environ.get("OPENAI_DEPLOYMENT_NAME")
openai_api_version = os.environ.get("OPENAI_API_VERSION")

llm = ChatOpenAI(model=deployment_name)

以下のリクエストに対するReActの実行例を示します。

ユーザーからのリクエスト

日本でラッコが見られる動物園を教えてください。
なぜその動物園でしか見られないかも調査し、レポートを作成してください。

実行例

■実行過程

==================================[1m Ai Message [0m==================================
Tool Calls:
web_search
Call ID: 
Args:
query: 日本 ラッコ 動物園
=================================[1m Tool Message [0m=================================
Name: web_search

[{"title": "ラッコのいる水族館・動物園は日本で2ヶ所、3頭のみ! | Goopass Animal Magazine", "snippet": "日本にいるラッコの数は3頭 「水族館や動物園の人気者」というイメージのあるラッコ。 日本で最初にラッコの飼育をはじめたのは静岡県の「伊豆・三津シーパラダイス」で、80～90年代にかけては100頭以上のラッコたちが日本の水族館・動物園を盛り上げました。", "url": "https://goopass.jp/animal/aquarium/seaotter"}, {"title": "【2024】日本にいるラッコは3頭だけ!？かわいい生態や会える水族館をご紹介 ｜じゃらんニュース", "snippet": "お腹の上で貝を割る姿がかわいらしいラッコ。存在は知っているけど「そういえば実物を見たことがない」という人も少なくないのでは？実はラッコは絶滅危惧種に指定されており、日本でも見られる水族館が減ってきているからです。今回は、かわいい生態や、ラッコと出会える貴重な水族館 ...", "url": "https://www.jalan.net/news/article/624144/"}, {"title": "ラッコがいる水族館は日本で2つ!キュートな行動や性格、浮く理由など特徴、生態も | るるぶKids", "snippet": "絶滅危惧種のラッコに会える水族館は日本に2つ（2023年7月現在）。 全部で3頭の写真・名前などを紹介するほか、ラッコの性格や貝をお気に入りの石で割る食事、水に浮く理由、寝るときの行動など、生態についても解説。 ... コアラがいる日本の動物園は7つ!", "url": "https://kids.rurubu.jp/article/36802/"}, {"title": "ラッコのいる動物園水族館は？飼育展示施設とラッコ個体情報まとめ - アリエスコム ARIEScom", "snippet": "日本動物園水族館協会（日動水・jaza）に非加盟の「ラッコ飼育施設」 日本動物園水族館協会（日動水・jaza）に加盟していない日本国内の施設（個人を含む）で、飼育されているラッコの情報を以下に記します。. また、情報をコメントにてお知らせいただけましたら掲載します。", "url": "https://www.ariescom.jp/entry/seaotter"}, {"title": "ラッコがいる水族館･動物園!日本で絶滅危惧種のラッコに会いにいこう - 旅go[タビ・ゴー]", "snippet": "水にまったり浮いているラッコは見ているだけで癒されますが、日本国内では年々飼育頭数が減っていて、現在は水族館や動物園で8頭のみが飼育されています。この記事では、ラッコを見ることができる水族館・動物園全6施設を一気にご紹介します。", "url": "https://tabigo-media.net/seaotter-aquarium/"}]
==================================[1m Ai Message [0m==================================
Tool Calls:
web_page_reader
Call ID:
Args:
url: https://goopass.jp/animal/aquarium/seaotter
=================================[1m Tool Message [0m=================================
Name: web_page_reader

※Call IDは省力

■最終回答

日本でラッコが見られる動物園や水族館は、以下の2ヶ所のみです。

1. **鳥羽水族館（とばすいぞくかん）** - 三重県鳥羽市
    - ここでは、15歳の「キラ」と19歳の「メイ（いずれもメス）」という2頭のラッコが飼育されています。
    - 鳥羽水族館は、1984年に日本で初めてラッコの繁殖に成功した場所であり、その歴史からラッコの飼育には豊富な経験があります。
2. **マリンワールド海の中道（まりんわーるど うみのなかみち）** - 福岡市東区
    - こちらでは、16歳の「リロ（オス）」という1頭のラッコが飼育されています。
    - リロは、日本にいる唯一のオスのラッコで、体長約130cmの巨体が特徴です。

これらの施設でしかラッコが見られない理由は、ラッコが絶滅危惧種に指定されていることや、米国からの輸入ができなくなったこと、国内での繁殖が成功していないことが挙げられます。環境問題や石油タンクによる事故などでラッコの個体数が減少し、保護のために輸出入が制限されています。これにより、日本での飼育個体数も限られてしまっています。

結果の考察

質問の前半部分（日本でラッコが見られる動物園を教えてください。）は「日本ラッコ動物園」と検索することで完璧な回答ができています。しかし、後半の特定の動物園でしか見られない理由については検索せずにLLMの知識だけで回答してしまっています。このようにReActはシンプルで簡単に利用できますが、実行の基準に不明確さがある点には留意する必要があるといえます。

Kaggleでの活用検討

ReActは逐次的に改善を行うタスクに適しており、仮説検証や初期的なEDA（探索的データ分析）などの短いフィードバックループを通じて素早く問題点を発見する作業に向いているいえます。

例えば、Code Interpreterのように、簡易的にデータを読み込み、加工し、分析するタスクが該当します。

その他にも、今回のようにWeb上の情報を取得し、知見を集約し、アイデアを創出するというような使い方も期待できそうです。
※Kaggleはスクレイピングやクローリングが禁止されているため、Kaggle以外から情報を取得しましょう

Plan-and-Execute

Plan-and-Executeは、タスクを達成するために「計画」と「実行」を分けて行う手法です。このアプローチでは、まずタスクを細かいサブタスクに分解する計画を立て、その後、各サブタスクを順番に実行します。特に、複数のツールやAPIを利用する複雑なタスクで効果を発揮し、全体的なパフォーマンス向上が期待できます。

特徴

Plan-and-Executeエージェントは、以下の役割に分かれます：

Planner（計画者）: タスクをサブタスクに分解し計画を立てる。
Executor（実行者）: 計画されたサブタスクを実行する。
Replaner（再計画者）: 必要に応じて計画を修正する。

Plan-and-Executeのアーキテクチャ

Plan-and-Executeのグラフは以下で表現できます。

上記グラフで黄色の枠に囲まれた部分がサブタスクをこなすExecutorに該当します。

Plan-and-Executeでもう1つ特徴的なのが再計画（Replan）です。

再計画では、初期の計画のサブタスクが実行された後、計画に修正が必要かを判断し、必要な場合は計画を追加します。

Plan-and-Executeと類似した計画を実施する手法にReWOOがありますが、こちらはPlan-and-Executeに対してサブタスクの振り返り（再計画）を実施せず、初期計画に基づいて実行のみを進める点が異なります。

実装は主に、Planer、Executer、Replanerからなります。

※LangGraphのチュートリアルを参考に実装しています。

https://github.com/langchain-ai/langgraph/blob/main/docs/docs/tutorials/plan-and-execute/plan-and-execute.ipynb

今回は分かりやすさのため、全体のグラフとplannerだけ紹介します。詳細はLangGraphのチュートリアルを参照ください。

また、LangChainライブラリを一部用いておりますが詳細な説明はここでは省略いたします。

グラフ構築

from langgraph.graph import START, StateGraph

workflow = StateGraph(PlanExecute)

# プラン ノードを追加します
workflow.add_node("planner", plan_step)

# 実行ステップを追加します
workflow.add_node("agent", execute_step)

# 再プラン ノードを追加します
workflow.add_node("replan", replan_step)

workflow.add_edge(START, "planner")

# プランからエージェントに移動します
workflow.add_edge("planner", "agent")

# エージェントから再プランを作成します
workflow.add_edge("agent", "replan")

workflow.add_conditional_edges(
"replan",
# 次にどのノードを呼び出すかを決定する関数を渡します。
should_end,
["agent", END],
)

# 最後にコンパイルします。
app = workflow.compile()

should_endでは、replanerからresponseが返ってこなければ、excuterを再度実行するようにしています。replanerからresponseが返ってくれば、実行を終了しresponseが最終回答となります。

Plannerの実装

from pydantic import BaseModel, Field
from langchain_core.prompts import ChatPromptTemplate

class Plan(BaseModel):
    """Plan to follow in future"""

    steps: List[str] = Field(
        description="実行すべきさまざまな手順は、順序どおりに並べる必要があります"
    )

planner_prompt = ChatPromptTemplate.from_messages(
    [
        (
            "system",
            """与えられた目標に対して、簡単なステップごとの計画を作成します。 \
この計画には、正しく実行すれば正しい答えが得られる個別のタスクを含める必要があります。 余分なステップを追加しないでください。 \
最終ステップの結果が最終的な答えになります。 各ステップに必要な情報がすべて含まれていることを確認してください。ステップを省略しないでください。""",
        ),
        ("placeholder", "{messages}"),
    ]
)
planner = planner_prompt | AzureChatOpenAI(
    azure_deployment=deployment_name, temperature=0
).with_structured_output(Plan)

async def plan_step(state: PlanExecute):
    plan = await planner.ainvoke({"messages": [("user", state["input"])]})
    return {"plan": plan.steps}

Plannerでは、ユーザーからのリクエストに応答するためタスクを細かなサブタスクに分解することでタスクを解決するための計画を立てます。

実装では、構造化された出力（with_structured_output）によってPlanクラスのstepsとしてリスト型で出力されます。

Plannerの出力結果（サブタスク）は、次の実行ステップとしてExecutor（実行者）に渡されます。

Executorとしては、ReActでも使用したcreate_react_agentを用いることができます。

その後、再計画ステップに進み、Replanerが再計画が必要か判断します。再計画が必要な場合は、計画を修正します。このサイクルをReplanerが実行不要と判断するまで回すことで、サブタスクを全て実行します。

実行例

■実行過程

初回の計画：

• **plan**: ['日本でラッコが見られる動物園をリストアップする。', '各動物園の公式ウェブサイトや信頼できる情報源を調査し、ラッコが見られる理由や特徴を確認する。', 'なぜその動物園でしかラッコが見られないのか、他の動物園と比較して特別な理由があるかを調査する。', '調査結果をまとめてレポートを作成する。']

日本でラッコが見られる動物園をリストアップする。

ユーザーからのリクエスト（日本でラッコが見られる動物園を教えてください。なぜその動物園でしか見られないかも調査し、レポートを作成してください。）を各タスクに分解できています。

再計画後の計画：

• **plan**: ['鳥羽水族館とマリンワールド海の中道の公式ウェブサイトや信頼できる情報源を調査し、ラッコが見られる理由や特徴を確認する。', 'なぜこれらの動物園でしかラッコが見られないのか、他の動物園と比較して特別な理由があるかを調査する。', '調査結果をまとめてレポートを作成する。']

「日本でラッコが見られる動物園をリストアップする」を調査することで、該当する動物園（本来は水族館ですが）を見つけることができたため、「各動物園」となっていた後続の計画の内容が具体化されています。

「動物園をリストアップ」が実行された後に再計画が実施されたことで、「各動物園」となっていた部分が具体的な名称となっています。

■最終回答

**response**: 日本でラッコが見られる動物園は、以下の2ヶ所です。

1. **鳥羽水族館**
    - 飼育されているラッコ: メイとキラ
    - 特徴: ラッコの飼育において40周年を迎え、記念活動を行っています。ラッコの行動や食事の様子を24時間ライブ配信しており、訪問者がラッコの自然な行動を観察できるようになっています。
2. **マリンワールド海の中道**
    - 飼育されているラッコ: リロ君
    - 特徴: 1980年代にアメリカからラッコが輸入され始め、ピーク時には日本国内で多くのラッコが飼育されていましたが、現在は数が減少し、少数の水族館でのみ見ることができます。

これらの水族館でしかラッコが見られない理由は、ラッコの飼育が非常に難しく、専門的な知識と設備が必要であるためです。また、ラッコの輸入が制限されていることも一因です。これにより、ラッコを飼育できる施設が限られており、特に鳥羽水族館は長年の飼育経験を持ち、マリンワールド海の中道はラッコの保護を目的とした展示を行っています。

結果の考察

Plan-and-Executeの結果も正解していました。計画により、包括的な調査を実施できたため、ReActの結果より、よりユーザーリクエストに沿った回答ができています。

「該当の動物園でしかラッコが見られない」理由についてもきちんと調査できており、正しいです。

ただ、実行によっては、現在見物できる動物園以外についても調査する場合があり、間違ってしまう場合も見られました。

注意点

Plan-and-Executeでは再計画の設定が適切でないと、無限ループに陥る可能性があります。対策として以下を検討してください：

再計画の回数を制限する。
必要に応じて、再計画を省略するReWOO型を採用する。

LangGraphのチュートリアル（参考リンク）を活用しつつ、プロンプト設計を工夫することでより安定した実行が可能になります。

Kaggleでの活用検討

Plan-and-Executeは、タスクを計画的に分割し、段階的に実行するアプローチであるため、Kaggleコンペにおいては、ReActよりもより広範で複雑な作業を実施することが期待できます。

特に、計画プロセスの考え方は、マルチエージェントにまで発展させることができ、それぞれの役割をもった複数のエージェントにタスクを依頼するために役立ちます。

Plan-and-Executeの計画→実行→評価（再計画）のようなアプローチを基本として、Kaggleで実施する作業をエージェントに依頼するフローを段階的に構築することで、Kaggleで生成AIエージェントを効率的に活用することができると考えます。

LATS

LATSはツリー型検索手法の中でもモンテカルロツリー探索（MCTS）とリフレクションを組合せた手法です。

このアプローチにより、エージェントは探索の過程で得た情報を活用し、次の行動を選択する際により良い判断を下すことができます。

特徴

モンテカルロツリー探索（MCTS）
- 候補となるすべての枝を評価し、スコアが最も高い枝を選択。
- 深く分岐した枝が最終的な回答となる。
リフレクション
- 探索中に得た情報を利用し、動的にタスクを調整。

LATSのアーキテクチャ

LATSのグラフは以下で表現できます。

実装は主に、初期応答generatorとExpanderから成ります。

初期応答Generator: ユーザー入力を受け取り、最初のルートノードを生成。
Expander: タスク候補の生成とリフレクションをバッチ処理で実行。

※LangGraphのチュートリアルを参考に実装しています。

https://github.com/langchain-ai/langgraph/tree/main/docs/docs/tutorials/lats

以下は、LATSの基本的なグラフ構造です。

グラフ構築

builder= StateGraph(TreeState)

# ノードの追加
builder.add_node("start", generate_initial_response)
builder.add_node("expand", expand)

# ノード間の遷移設定
builder.add_edge(START, "start")
builder.add_conditional_edges(
    "start",
# Either expand/rollout or finishshould_loop,
    ["expand", END],
)
builder.add_conditional_edges(
    "expand",
# Either continue to rollout or finishshould_loop,
    ["expand", END],
)

# グラフをコンパイル
graph= builder.compile()

実行例

以下は、LATSによる実行の過程と最終回答の例です。

■実行過程

※長いため実行過程は省略します。

初回の実行ではweb_searchを利用して情報を検索し、候補タスクを生成します。

{'args': {'query': '日本 ラッコ 見られる動物園'}, 'id': '', 'type': 'web_search'}

その後、新たなタスク候補としてweb_page_readerを利用し、検索で収集したURLを解析します。

その中で最も良かった検索の組合せを評価し、次の候補を探索しています。

■最終回答

日本でラッコが見られる動物園や水族館は、現在、主に以下の2か所だけです：

1. **鳥羽水族館（三重県）**
2. **マリンワールド海の中道（福岡県）**

### なぜこれらの施設だけでラッコが見られるのか？

ラッコがこれらの施設でしか見られない理由は以下の通りです：

1. **絶滅危惧種の指定**: ラッコは絶滅危惧種に指定されており、個体数の減少が著しいです。かつては日本各地の水族館で見られたラッコですが、現在は飼育頭数が大幅に減少しています。
2. **輸入制限**: アメリカではラッコの保護のために輸出が禁止されており、新たな個体の導入が困難です。これにより、日本国内でのラッコの飼育が制限されています。
3. **繁殖の難しさ**: 国内での繁殖がうまくいかず、既存のラッコたちの高齢化も進んでいます。これにより、飼育可能な個体数が限られています。
4. **生息環境の変化**: 野生におけるラッコの生息環境が石油タンカー事故や気候変動などにより変化し、個体数がさらに減少しています。

### 現在のラッコの状況

- 鳥羽水族館では、15歳と19歳のメスのラッコがいます。
- マリンワールド海の中道では、16歳のオスのラッコがいます。
- これらのラッコたちは高齢で、繁殖の可能性も低くなっています。

### 歴史と背景

ラッコはかつて日本全国の水族館で飼育され、人気のある動物でした。しかし、法律による保護や環境問題が影響し、飼育頭数が減少しました。これらの背景から、現在では限られた施設でしか見ることができません。

これらの情報をもとに、ラッコの見学を予定する際には、事前に各施設の公式サイトで詳細情報を確認することをお勧めします。

結果の考察

回答としては問題ありませんでした。3つの手法の中で最も情報の網羅性が高く、WEB検索のように、まずはあたりをつけてから目的を達成するという場合や深堀して調べたい場合には適している手法といえます。

ただし、各候補の中から最善の枝が選択されているかの評価を目視で実施するのは大変そうです。

注意点

以下の点に留意する必要があります

実行コスト: 他の手法に比べて計算リソースを多く消費する。
冗長化リスク: 深堀りしすぎると、元の質問趣旨から逸脱する可能性がある。

Kaggleでの活用検討

LATSは、探索的に最もよい組合せを探索することができるため、Optunaのパラメータチューニングのように、各施策（情報収集からアイデア抽出、データ加工、モデル構築、アンサンブル等）の最適な組合せを探索するといった使い方ができます。

計算リソースとの兼ね合いがあるため、サンプルデータを小さくしたり、モデルのサイズを小さくして探索を行うことで、効率的に探索できると考えます。

まとめ

生成AIエージェントは、今後ますます多くの分野でその可能性を発揮することが期待されています。Kaggleのようなデータ分析の最前線でも、既にいくつかのエージェント活用が検討されております。現在はトップクラスの成績（メダル獲得）を狙うにはまだ課題が多いものの、生成AIの進化スピードを考えれば、将来的にはKaggle MasterやGrandmaster相当の性能を持つエージェントが現れる可能性も否定できません。

本記事では、生成AIエージェントの構造や主要な実装手法として「ReAct」「Plan-and-Execute」「LATS」を取り上げ、それぞれの特徴と適用例を紹介しました。

今回紹介した手法は、さまざまな作業プロセスで応用がきく仕組みなので、シングルエージェントの仕組みを取り入れて、より高度なタスクを解くことを考えていければと思います。

Kaggleにおいては、Web検索などの知識取得やデータ加工などのツールがたくさん必要になると思いますので、シングルエージェントの構造を理解した上で、エージェント開発を進めるのが良いと思います。

生成AIエージェントを補助ツールとして活用し、人間の洞察力と組み合わせることで、より良い分析結果や成果を得ることが可能と考えます。エージェントができる範囲から徐々に作業を委任することで、人間はより難易度の高い課題に集中することができるでしょう。

次回は、「マルチエージェントの特徴と適用例」についてご紹介した後、論文で発表されているKaggleエージェントについて詳しく見ていこうと思います。ぜひお楽しみに！

筆者
AIソリューショングループ
阿田木勇八

AITC - ISID | AI トランスフォーメンションセンターコラム

Kaggleにおける生成AIエージェント①：Kaggleの最前線でも利用が進むか？AIエージェントの特徴や適用例

Kaggleと生成AIエージェントの現状

シングルエージェントとマルチエージェントの違い

シングルエージェントの概要

マルチエージェントの概要

主な違い

シングルエージェントの代表的な実装手法

1. ReAct

2. Plan-and-Execute

3. LATS（Language Agent Tree Search）

ReAct

特徴

ReActのアーキテクチャ

実行例

結果の考察

Kaggleでの活用検討

Plan-and-Execute

特徴

Plan-and-Executeのアーキテクチャ

実行例

結果の考察

注意点

Kaggleでの活用検討

LATS

特徴

LATSのアーキテクチャ

実行例

結果の考察

注意点

Kaggleでの活用検討

まとめ

お問い合わせ