はじめての DPSy 言語モデルを『プロンプト』ではなく『プログラミング』するための仕組み 株式会社ジェネラティブエージェンツ 西見 公宏 Generative Agents, Inc. / Masahiro Nishimi 2025/10/16 

会社名 株式会社ジェネラティブエージェンツ （英文：Generative Agents, Inc.） 所在地 東京都港区 ※ 全社員リモート勤務 役員構成 CEO 西見 公宏 COO 吉田 真吾 CTO 大嶋 勇樹 設立年月 2024年3月14日 事業内容 AIエージェント技術を軸とした生成 AIアプリケーション開発 支援、コンサルティング、教育・研修サービスの提供 AIエージェントインテグレーションサービスの提供 AIエージェントを実業務で本当に活用するためには、AIエージェントの技術特性 と問題解決領域の両面から検討を進める必要があります。当社は「LangChain」 の公式エキスパートとして、AIエージェントを開発するための確かな技術力を活 かし、生成AIアプリケーション開発支援からコンサルティング、教育・研修サービ スまでのあらゆる方面において、AIエージェントを活用した問題解決サービスを 提供します。 インテグレーションを支えるサービス群の提供 AIエージェントを効果的に運用するためには、AIエージェントを動かすためのイ ンフラが必要です。当社はマルチエージェントのオーケストレーション基盤である 「tasq0 - タスクゼロ（※開発中）」をはじめ、AIエージェントのためのツール群 「middleman.ai」の提供を通して、AIエージェント活用のための基盤構築をサ ポートします。 株式会社ジェネラティブエージェンツ - 会社概要 AIエージェントが「ハブ」となり 人間とAIエージェントの協働が 当たり前になる世界を実現する 

フェーズ1 個人：生成AI活用 フェーズ2 組織：生成AI活用 フェーズ3 組織：プロセス自動化 フェーズ4 組織：AIエージェント開発 フェーズ5 組織：AIエージェント駆動 Dify活用講座 Difyアプリ開発支援、コンサルティング LLMアプリケーション開発者養成講座 生成AIキャッチアップセミナー 生成AIアプリ開発支援、コンサルティング BYNAME（人材紹介事業） middleman.ai（Tools for AI Agents） タスクゼロ（Ambient Agent Platform） プロダクト 人材支援 開発支援 教育・研修 スケールアップ スケールアウト 初手AI 個人の生産性向上が中心 チームレベルの生産性向上が中心 組織レベルの生産性向上が中心 個々人がツールを使える 組織レベルでツール導入する 生成AIの利用を前提に自動化する ワークフローからエージェントへ 業務の初手がAIエージェント ジェネラティブエージェンツのサービス提供マップ 

AIエージェント開発に関する主な著書 2023年12月16日発売 一般向け AIエージェント解説書 2024年11月9日発売 開発者向け AIエージェント解説書 2023年10月号から連載 実践 LLMアプリケーション開発 

【最新】AIエージェント開発の解説書 現場で活用するための AIエージェント実践入門 7月17日発売、Amazonで好評発売中 著者：太田 真人（Sakana AI）, 宮脇 峻平 (Algomatic), 西見 公宏 (Generative Agents), 後藤 勇 輝 (電通総研), 阿田木 勇八 (電通総研) 「第1部 AIエージェントを知る」の前半では AIエージェントの定義や重要な性質、ビジネス状況、 活用例を説明します。 後半は技術観点で AIエージェントを構成する各技術要素の説明と実装上で気をつけることを説 明しています。開発者の方に興味を持っていただける内容です。 「第2部 AIエージェントを作る」では、どの会社でもありそうな課題に対して AIエージェントを開発 していきます。さまざまな応用事例をもとに、 AIエージェントの構築方法が学べます。実装した AI エージェントを業務に適合させるため、精度を高める方向性や課題にも触れています。読者が すぐに実装を再現でき、読者の環境に合わせて改変して業務利用できることを意識していま す。 「第3部 AIエージェントを活用する」では、実際に AIエージェントのプロジェクトを進めるうえで、 避けては通れない AIエージェントの評価や UX、リスクについて解説します。また、継続的な AI エージェントの改善についても解説します。 最後に各社の取り組み方法や考え方について説明します。 

本編 

本日の流れ 1. AIエージェント開発フレームワークの状況 2. プロンプトエンジニアリングが持つ課題 3. DSPyがこれらの課題をどのように解決するのか？ 【今日のゴール】 DSPyのことが何となく分かり、 触ってみようかなと思えること 

プログラミング＝プロンプティング？ 

ワークフローとAIエージェント ワークフロー AIエージェント ● ユーザーが自分の手で個々の処理をフローとして繋 ぎ合わせ、作成する ● 決められた通りに動作するため安定性が高い ● ワークフローは増え続けるため、保守に注意が必要 ● AIエージェントがユーザーの要求に応じてオンデマン ドでワークフローを生成する ● ユーザーの要求を達成するフローが必ず生成される とは限らないため、新しいマネジメントが必要 

エージェンティックワークフロー ユーザー入力 分類タスク ワークフロー ワークフロー ヒューマン エスカレーション ヒューマン フィードバック AIモデルによる 評価 AIモデルを利用した 柔軟な分岐 LLM-as-a-Judgeなどを 用いた自律的実行 ヒューマン・イン・ザ ・ループによる実行 人間による代行 

主要なAIエージェント開発フレームワーク LangGraph / LangChain Strands Agent Mastra 開発元 LangChain Amazon Web Service(AWS) Mastra（元Gatsbyチーム） 初回リリース LangChain: 2022年11月 LangGraph: 2024年 プレビュー: 2025年5月 v1.0: 2025年7月 2024年10月 最新バージョン v1.0 alpha（2025年9月） v1.0（2025年7月） 頻繁にアップデート ライセンス MIT Apache 2.0 Apache 2.0 言語 Python、JavaScript/TypeScript Python TypeScript 設計思想 ワークフローベース／ステートグラフ による明示的な制御フロー モデル駆動アプローチでLLMの推論能 力を最大限に活用 フルスタック開発者向け／TypeScript ファーストのモジュラー設計 制御方法 開発者が明示的にノードとエッジを定 義（create_react_agentのようなReAct エージェントプリセットも利用可能） モデルが自律的にツール選択と実行を 判断 ワークフローのエージェントのハイブ リッド 比較ポイント 細かい制御フローも含めて開発したい 場合 AWSとの親和性を求めたい場合 フロントエンドも含めてフルスタック で開発したい場合 

共通する開発パターン ①ツール定義 ②プロンプト設計 ③ワークフロー構築 def weather_api(city: str) -> dict: """指定された都市の天気情報を取得 """ return get_weather(city) def search_database(query: str) -> list: """データベースから関連情報を検索 """ return db.search(query) system_prompt = """ あなたは親切な旅行アシスタントです。 ユーザーの質問に対して、利用可能なツールを使って 正確で役立つ情報を提供してください。 必ず天気情報を確認してから提案を行ってください。 """ LangGraph Strands エージェント + ツール Mastra ワークフロー + エージェント ※モデルが使用ツールを判断 エージェントが使用できるツールを定義 外部API呼び出し（天気情報取得、データ ベース検索、Web検索など）、データ処理 （計算、フォーマット変換など）、ファイル 操作（読み込み、書き込みなど）といった、 LLM単体では実現できない処理を『ツール』 としてエージェントに提供する。 LLMへの指示を自然言語で記述 各ツールや処理ステップについて、LLMへの 指示を自然言語で記述する。システムプロン プト（エージェントのペルソナ、役割、制 約）、タスク固有の指示（何をすべきか、ど のように振る舞うべきか）、Few-shotサンプ ル（望ましい挙動の例示）など。 最近のトレンドでは、ツール を『MCP』を用いて提供する ケースも多い ツールの利用方策など、あら ゆる情報を記述するため、非 常に長くなる傾向にある フレームワークにあまり関わらない部分 フレームワーク毎に特色のある部分 

共通する開発パターン ①ツール定義 ②プロンプト設計 ③ワークフロー構築 def weather_api(city: str) -> dict: """指定された都市の天気情報を取得 """ return get_weather(city) def search_database(query: str) -> list: """データベースから関連情報を検索 """ return db.search(query) system_prompt = """ あなたは親切な旅行アシスタントです。 ユーザーの質問に対して、利用可能なツールを使って 正確で役立つ情報を提供してください。 必ず天気情報を確認してから提案を行ってください。 """ LangGraph Strands エージェント + ツール Mastra ワークフロー + エージェント ※モデルが使用ツールを判断 エージェントが使用できるツールを定義 外部API呼び出し（天気情報取得、データ ベース検索、Web検索など）、データ処理 （計算、フォーマット変換など）、ファイル 操作（読み込み、書き込みなど）といった、 LLM単体では実現できない処理を『ツール』 としてエージェントに提供する。 LLMへの指示を自然言語で記述 各ツールや処理ステップについて、LLMへの 指示を自然言語で記述する。システムプロン プト（エージェントのペルソナ、役割、制 約）、タスク固有の指示（何をすべきか、ど のように振る舞うべきか）、Few-shotサンプ ル（望ましい挙動の例示）など。 最近のトレンドでは、ツール を『MCP』を用いて提供する ケースも多い ツールの利用方策など、あら ゆる情報を記述するため、非 常に長くなる傾向にある フレームワークにあまり関わらない部分 フレームワーク毎に特色のある部分 大きく性能を左右するポイント 

モデルによって性能の出るプロンプティングが異なる Figure 2:Cross-model optimization results on Llama.cpp. “Tuning LLM-based Code Optimization via Meta-Prompting: An Industrial Perspective” メタプロンプティングによるLLMベースのコード最適化のチューニング：産業界からの視点 2025/8 Jingzhi Gong52, Rafail Giavrimis32, Paul Brookes2 et al. 右図のグラフは、Llama.cppにおけるある モジュールのパフォーマンス最適化を、各 モデルに行わせた際の結果を表している。 各モデルに特化したプロンプトを用いた方 が、各モデルのパフォーマンスが向上して いることが分かる。 https://arxiv.org/html/2508.01443v2 

「評価の仕組み」は銀の弾丸ではない データセットからプロンプトを評価→プロンプトをアップデートするイテレーションを組んでも、そ のアップデート自体は人間が行わなくてはいけない。プロンプトの数が増えれば増えるほど、メンテ ナンス対象が増えていく。また、プロンプトのどの部分が評価に影響するのかは明らかでない。 

モデルの進化とRetirement モデル 提供開始 非推奨／停止 gpt-4 2023年7月 停止：2025年11月 gpt-4(32k) 2023年7月 停止：2025年6月 gpt-4 turbo 2023年11月 - gpt-4o 2024年5月 - gpt-4.5 Preview 2025年2月 停止：2025年7月 o1 2024年9月 miniは2025年10月停止 o3 / o3 mini / o4mini 2025年4月 - gpt-4.1 2025年4月 - gpt-5 2025年8月 - モデル 提供開始 非推奨／停止 claude 1系 2023年3月 停止：2024年11月 claude 2系 2023年7月 停止：2025年7月 claude 3 sonnet 2023年11月 停止：2025年7月 claude 3 opus 2024年3月 停止：2026年1月 claude 3.5 sonnet 2025年2月 停止：2025年10月 claude 3/3.5 haiku 2024年3月/10月 - claude 4 sonnet 2025年5月 - claude 4/4.1 opus 2025年5月/8月 - claude 4.5 sonnet 2025年9月 - OpenAI Anthropic ※Azureでの停止時期 数ヶ月単位でアップデート＆より高性能・低価格になるため、モデルバージョンの固定化が現実的ではない 

ここまでのまとめ ● AIエージェント開発フレームワークの基本的な構造は同じ ○ ツール／プロンプトの部分はほぼ共通で、ワークフロー定義や、フロ ントエンドへの組み込みといった要素で差分がある。 ● AIエージェントのパフォーマンスを左右する大きな要素が『プロンプト』 ○ AIエージェントはLLMによる判断の精度に性能を依存しているため、 良いプロンプト＝良い結果に結びつきやすい。 ● 『プロンプト』のパフォーマンスを左右する要素が多くメンテが困難 ○ 一方で、プロンプトはモデルの変化に敏感に反応する。 ○ モデルは早いスピードでアップデート＆非推奨化が進むため、性能維 持ないしは性能向上の工数が大きな課題となる。 

DSPyでこれらの課題に立ち向かっていく 

プロンプトを手書きするのではなく データと評価関数によって自動生成する 

DSPyの歴史 - 起源と思想 スタンフォードのHazy Researchグループ（Omar Khattab氏、Matei Zaharia氏ら）により、「プロンプトを文字列として書くのではなく、宣 言的モジュールとして組み立て、データ駆動で最適化する」試みとして誕生。 LLMに数例のデモを提示することで初期方針を作成し（Demonstrate/実例提示）、多数の候補出力を生成しスコアリング（Search/探索）、 最終的に最も良い探索結果を選択することで最適な結果を得る（Predict/予測）フローを取ることからDSPと名付けられている。 起源と思想（2023年以前）：DSP（Demonstrate-Search-Predict） DSPyの誕生（2023年10月）：論文 “DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines” Omar Khattab、Arnav Singhvi、Hanna Moazam、Matei Zaharia、Chris Pottsらによる、スタンフォードとDatabricks連名の論文により、「プ ロンプトをハードコードせず、言語モデルを使用したモジュールを宣言的に組み合わせ、コンパイル時に最適化する」という、コア設計が提 示される。 Stanford／Databricks ResearchのOmar Khattab（オマール・ハッターブ）氏がプロジェクトリードを務め、Databricks CTO 兼 UC Berkeley 教授のMatei Zaharia（マテイ・ザハリア）氏がメンターとして関与。GitHubでOSSとして公開される。 

DSPyの歴史 - タイムライン 時期 バージョン 主な機能・トピック Databricksとの関係 2023年10〜12月 v1.x（初期リリース） モジュール化・コンパイラ最適化の基本構造が確立され る。 研究者主導のPoC段階。Databricksか らもZaharia氏が参画。 2024年上旬 v2.0-2.5系 最適化器（Optimizer）改善・サンプル探索・評価ループ 自動化。 Databricksが公式ブログ「DSPy on Databricks」を公開。Model Serving／Vector Search統合開始。 2024年下旬 v2.6系 LM usage tracking、RAG Module強化。 Databricks OSSチームが内部統合を 進行。MLflow integration 着手。 2025年6月 v3.0メジャーリリース ・強化学習系オプティマイザ（GRPO via Arbor） ・リフレクションによるプロンプト最適化 GEPA ・サンプル探索 SIMBA ・MLflow 3.0 統合 （mlflow.dspy.autolog() 実装） ・Adapter / Type System 追加 ・並列・ストリーミング処理強化 Databricks DATA+AI SUMMITで DSPy3.0のアップデートが多数発表 される。 2025年8〜10月 v3.0.1-3.0.3 パッチ安定化、キャッシュ・型ヒント修正、Databricks Runtime 最適化。 MLflow DocsおよびDatabricks Model Serving ドキュメントにも「DSPy 対 応」が明記される。 

DSPyの基本構造 - シグネチャとモジュール シグネチャ：『LLMにどのような情報が入力され、どのような情報が出力されるのか』を定義 モジュール：シグネチャをどのように使うのかを定義 シグネチャ モジュール DSPyプログラム ※特に最適化せず、そのまま利用す ることもできる class ConversationSignature(dspy.Signature): """枝豆の妖精として対話する """ query = dspy.InputField(desc="ユーザーからの質問や発言 ") history = dspy.InputField(desc="過去の対話履歴", format=list, default=[]) response = dspy.OutputField(desc="枝豆の妖精としての応答。語尾に「のだ」「なのだ」を自然に 使い、一人称は「ボク」。親しみやすく可愛らしい口調で、日本語として自然な文章 ") class EdamameFairyBot(dspy.Module): """枝豆の妖精スタイルのチャットボット """ def __init__(self): super().__init__() self.respond = dspy.Predict(ConversationSignature) def forward(self, query: str, history: list | None = None) -> dspy.Prediction: if history is None: history = [] return self.respond(query=query, history=history) シグネチャのコード例 モジュールのコード例 

シグネチャとモジュールの利用例 # チャット用LM設定 lm = dspy.LM( model="openai/gpt-4.1-nano", temperature=0.0, max_tokens=1000 ) # DSPyのグローバル設定 dspy.configure(lm=lm) # モジュール読み込み chatbot = EdamameFairyBot() # モジュール実行 history_list = [] result = chatbot(query="こんにちは！", history=history_list) あなた: こんにちは！ 🌱妖精: やっほーなのだ！ボクは枝豆の妖精、エダマメちゃん なのだ。会えてうれしいのだ！何かお手伝いできることがあった ら教えてほしいのだ〜！ 実行結果 

System message: Your input fields are: 1. ` query ` (str): ユーザーからの質問や発言 2. ` history ` (str): 過去の対話履歴 Your output fields are: 1. ` response ` (str): 枝豆の妖精としての応答。語尾に「のだ」「なのだ」を自然に使い、一人称は「ボク」。親しみやすく可愛らしい口調で、日本語として自然な文章 All interactions will be structured in the following way, with the appropriate values filled in. [[ ## query ## ]] {query} [[ ## history ## ]] {history} [[ ## response ## ]] {response} [[ ## completed ## ]] In adhering to this structure, your objective is: 枝豆の妖精として対話する User message: [[ ## query ## ]] こんにちは！ [[ ## history ## ]] N/A Respond with the corresponding output fields, starting with the field ` [[ ## response ## ]]` , and then ending with the marker for ` [[ ## completed ## ]]` . Response: [[ ## response ## ]] やっほーなのだ！ボクは枝豆の妖精、エダマメちゃんなのだ。会えてうれしいのだ！何かお手伝いできることがあったら教えてほしいのだ〜！ dspy.inspect_history()を使うと、実際に出力されているプロンプトを確認できる 

シグネチャの定義 class ConversationSignature(dspy.Signature): """枝豆の妖精として対話する """ query = dspy.InputField(desc="ユーザーからの質問や発言 ") history = dspy.InputField(desc="過去の対話履歴", format=list, default=[]) response = dspy.OutputField(desc="枝豆の妖精としての応答。語尾に「のだ」「なのだ」を自然に 使い、一人称は「ボク」。親しみやすく可愛らしい口調で、日本語として自然な文章 ") シグネチャのコード例 パラメータ 役割 デフォルト値 最適化への影響 desc フィールドの説明文。LLMへの指示として使用 なし 主要な要素。詳細な記述が品質に影響 format 期待される型（str, int, list, dictなど） str 出力の形式を制約し、パース可能な結果を 保証 default デフォルト値 なし 省略可能なフィールドの初期値を提供 prefix プロンプト内での接頭辞 フィールド名 プロンプトの構造を明確化 

プリセットのモジュールの一例 モジュール名 説明 使用場面 dspy.Predict 質問に対して直接回答を生成する。 シンプルな質問応答、分類タ スク、チャットボット dspy.ChainOfThought 「まず〜を考えて、次に〜を検討し、結論は〜」のように段階的な 思考過程を明示してから最終回答を出力。例えば「13×17は？」に 対して「13×10=130、13×7=91、130+91=221」と計算過程を示す。 複雑な推論、数学問題、論理 パズル、判断根拠が必要な場 面 dspy.ReAct 思考と行動を交互に実行。「検索が必要→検索実行→結果を踏まえ て考察→追加情報が必要→再検索」のように外部ツールと対話しな がら問題解決する。一般にReActパターンと呼ばれる動作。 Web検索、データベース照会、 プログラム実行、API呼び出し を伴うタスク dspy.ProgramOfThought 問題をPythonコードのような擬似プログラムに変換して解く。「if 条件A then 処理B else 処理C」のような論理的な手順を生成する。 アルゴリズム的な問題、条件 分岐が多い処理、手順が明確 な作業 dspy.MultiChainComparison 同じ質問に対して複数の角度から回答を生成し比較する。例えば 「日本の首都は？」という質問に対し「歴史的観点：江戸→東京」 「政治的観点：国会がある東京」「地理的観点：関東の東京」と いった複数の推論を生成し、最も信頼できる答えを選択する。 医療診断、法律相談、重要な 意思決定など正確性が求めら れる場面 

DSPyプログラムを最適化する シグネチャ モジュール DSPyプログラム データセット 評価関数 最適化モジュール （オプティマイザー） シグネチャ モジュール DSPyプログラム v2 

DSPyで用意されているオプティマイザーの抜粋 オプティマイザー 最適化 アルゴリズム 計算コスト GEPA DSPyプログラム中のテキスト要素（指示・プロンプトなど）を 「反省（reflection）」に基づいて反復的に進化。実行トレース （推論、ツール呼び出し、出力）を言語で振り返り、問題診断→ 改善案生成→統合 リフレクションによ る進化的最適化 高 MIPROv2 プロンプトの命令文とfew-shot例の両方を最適化。「簡潔に答え て」を「技術的な根拠を含めて段階的に説明し、最後に要約を提 供」等へ自動変換し、同時に最適例を選択 ベイズ最適化+ミニ バッチ評価を用いた 探索 中〜高 BootstrapFewShot 訓練データから良い例だけを自動選択（例：100例から有用な5例 を選ぶ） ランダムサーチ 低 GRPO (Generalized RPO) プロンプト最適化に加えて、LoRA 等でローカル LM の『重み更 新』も同時に最適化するオンライン RL。モジュール横断の DSPy プログラム全体を対象に、報酬を最大化するように方策を改善す る。Arbor RL サーバと連携して数百〜数千ステップの学習を回す プロンプト最適化＋ ファインチューニン グ 高 

MIPROv2による最適化プロセス 

データセットの準備 databricks-dolly-15k-jaをベースにTakaaki Inada氏が作成された takaaki-inada/databricks-dolly-15k-ja-zundamonを利用させていただいております。 https://huggingface.co/datasets/takaaki-inada/databricks-dolly-15k-ja-zundamon 

評価関数の実装 以下の基準で0-10点で評価してください : 1. 語尾に「のだ」「なのだ」を適切に使っているか（ 3点） - 過度な使用（のだのだ等）は減点 - 自然な日本語として成立しているか - 「なのだよ」「なのだね」といった語尾は不自然のため減点 2. 一人称を使う際は「ボク」を使っているか（ 2点） 3. 親しみやすく可愛らしい口調か（ 3点） 4. 日本語として自然で読みやすいか（ 2点） - 不自然な繰り返しがないか - 文法的に正しいか 次のようなクライテリアを設け、LLM as a Judgeでスタイルを評価 

最適化の実行 ①トレース収集 スコアの高い few-shot例を生成 

最適化の実行 ②プロンプト候補生成 

最適化の実行 ③ベイズ最適化 1/2 

最適化の実行 ③ベイズ最適化 2/2 

MLflowでの実験管理 

今回利用したサンプルコード https://github.com/mahm/softwaredesign-llm-application/blob/main/25 

Software Design誌にてDSPyに関する連載を掲載しています 実践LLMアプリケーション開発 2023年（！？）からSoftware Design誌にて連載を続けさせて いただいております。第24回まではLangChain/LangGraphの 利用方法を中心にしていましたが、第25回からはDSPyの使い 方を中心に掲載しています。 日本語のまとまった情報が、まだまだない領域なので、ぜひ お手にとってご覧いただけると幸いです。 

まとめ ● 『シグネチャ』と『モジュール』によって処理を構造化する ○ 『LLMの入出力』と『その組み合わせ』を定義することで、言語モデ ルを利用したプログラムを作成する ● 状況に応じて適切な『オプティマイザー』を選定する ○ どの程度データセットがあるのか、few-shotだけでも性能が出るタス クなのかを見極め、オプティマイザーを選定する ● 『プロンプト』を手書きするのではなく、演算された『重み』として扱う ○ プロンプトを手書きでアップデートするのは限界があると認め、デー タセットと評価関数によって導き出される『重み』として扱う 

全体のまとめ ● AIエージェントの性能は『プロンプト』に依存する ○ コードによるルールベースの制御よりも、LLMの判断による制御のパ フォーマンスがAIエージェントの性能の鍵を握る ● 『プロンプト』の性能を維持・向上させていくのは困難 ○ モデルのアップデートやリタイアメントが繰り返される中で、人手に よるアップデートではプロンプトの性能を維持するだけでも大変 ● 『プロンプト』を手書きするのではなく、演算された『重み』として扱う ○ プロンプトを手書きでアップデートするのは限界があると認め、デー タセットと評価関数によって導き出される『重み』として扱う 

今後のDSPy関連のイベントについて 2025/10/29（水）19:30〜21:00 【Databricks共催】 プロンプトエンジニアリングから の脱却！DSPyによるプロンプト最 適化入門 2025/11/13（木）※時間調整中 DSPyミートアップ 会場：東京スクエアガーデンWeWork 

LLMアプリケーション開発者養成講座（合同研修） LLMアプリケーション開発の基礎から実践まで 体系的な講義とハンズオン 12月2日、12月9日、12月16日（火）10:00〜18:00 LangChain・RAG・AIエージェントのベストセラー書籍 著者による解説と手厚い質疑応答 合同研修として開催のため、 各社1名から参加可能 ✔ ✔ ✔ 詳細はこちら：https://generative-agents.notion.site/llm-app-dev-training-joint 

GAでは一緒にプロダクトを開発する仲間を募集しています！ AIエージェントを使って、こんな世界観を一緒につくる仲間の参戦をお待ちしております！ 

ご清聴ありがとうございました