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

関連リンク

• なぜAI AgentにSQLを直接触らせず、dbt showを使わせたのか

この記事では、AIエージェントに直接SQLを操作させることの課題と、それを解決するためにdbtのdbt showコマンドを組み合わせたデータ調査ワークフローについて解説しています。

まず、複雑なデータパイプラインでは、データの正確性や安全性が非常に重要です。しかし、商品データなどの調査は、専門知識が必要で手順も人によって異なり、時間もかかるという課題がありました。

AIエージェントにデータを調査させる際、直接SQL（データベースを操作する言語）を書かせると、以下のような問題が起こります。

• 知らないテーブルのフルパスを指定してしまい実行に失敗したり、重い処理でコストが増えたりする。
• AIにデータベースの詳しい構造を常に教える必要があり、情報が膨大になる。
• 誤ってデータを削除・変更するような危険なSQL（DDL）を生成するリスクがある。 これらのリスクから、AIに直接SQLを書かせる運用は難しいと筆者は考えました。

そこで登場するのが「dbt」というツールです。dbtは、SQLを直接書くのではなく、データ変換のロジックを「モデル」という形で管理します。開発者は複雑なデータベースのフルパスを知らなくても、ref('モデル名')のようにシンプルにモデル名を指定するだけでデータを操作できます。AIにもこの「モデル」のレベルで操作させれば、より安全で効率的だと考えました。

解決策として採用されたのが、dbtが持つdbt showコマンドです。これは、dbtのモデル定義に基づいてSELECT文（データを見るだけの操作）を実行できるコマンドです。 dbt showを使うメリットは次の通りです。

1. 安全: SELECT文に限定されるため、データの変更や削除といった副作用がありません。
2. 抽象化を活用: dbtのモデルや依存関係（DAG）をそのまま利用できるため、AIに複雑なデータベース構造を教える必要がなく、渡す情報を最小限に抑えられます。
3. 再現性: dbtのマクロや変数を解決して実行するため、人間が書いたSQLと同じロジックでデータを確認できます。

ただし、dbt show --inlineオプションには、任意のSQLが実行できてしまうという潜在的なセキュリティリスクがあることも判明しました。これに対し、記事では入力されたSQLをサブクエリ（SQLの中の小さなSQL）でラップし、危険なSQLが実行されないようにする「ラッパーコマンド」の暫定的な対策が紹介されています。

実際のワークフローでは、ユーザーが「この商品IDの商品を調べてください」とシンプルに依頼すると、AIエージェントはドキュメント化された手順（最終データから遡って原因を探るなど）に従い、dbt showを使いながらデータ調査を進めます。調査結果はファイルに保存され、後から人間が確認できるため、属人化していた調査が誰でも再現可能な形になりました。

この取り組みにより、AIエージェントを安全かつ最小限のコンテキストで動かすことができ、データ調査の効率と信頼性が大幅に向上しました。将来的には、dbtプロジェクト全体の情報をAIに提供できる「dbt MCP Server」のような技術と連携することで、AIの活用範囲はさらに広がると期待されています。モデルやカラムのドキュメント、テストを充実させることが、AI活用を成功させるための重要な鍵となります。

引用元: https://takimo.tokyo/2604aebf66ad8067a25ccd25e459da97

• Memento: Fine-tuning LLM Agents without Fine-tuning LLMs

今回ご紹介する「Memento」は、大規模言語モデル（LLM）を基盤としたAIエージェントの学習方法に、新しい風を吹き込む研究です。これまでのLLMエージェントは、特定のタスクに適応させるために、基盤となるLLM自体を「ファインチューニング」、つまり追加で学習させることが一般的でした。しかし、このファインチューニングは計算コストが非常に高く、時間もかかるため、AIエージェントを継続的に、そして柔軟に賢くしていく上での大きな課題でした。

「Memento」が画期的なのは、この基盤LLMをファインチューニングすることなく、低コストで、しかもリアルタイムにAIエージェントを賢く適応させる点にあります。どのように実現しているかというと、彼らは「メモリベースのオンライン強化学習」という手法を取り入れています。これは、AIエージェントが過去の経験を「エピソード記憶」として蓄え、その記憶を元に行動を決め、さらに環境からのフィードバックを受けて記憶を更新していく、という仕組みです。

具体的には、「Memory-augmented Markov Decision Process (M-MDP)」という枠組みで、過去の経験から適切な知識を選ぶ「ニューラルケース選択ポリシー」を使って、次の行動を導きます。この「記憶」は、環境から得た新しい情報や結果に応じて効率的に書き換えられ、また必要な時に素早く読み出されることで、エージェントは常に最適な行動を選べるようになるのです。まるで、人が新しい経験から学び、知恵を増やしていくように、AIエージェントも自ら進化できるイメージです。

この「Memento」を「Deep Research」という複雑な研究タスクに応用したところ、GAIA検証セットで87.88%のPass@3を達成し、従来の学習ベースの手法よりも優れた性能を示しました。また、学習時には遭遇しなかった新しい種類の問題（分布外のタスク）に対しても、記憶を活用することで大幅な性能向上を見せています。

この研究は、大規模な計算資源を必要とするファインチューニングなしに、AIエージェントが自律的に、かつ継続的に学習し、様々なタスクに適応していく新しい道筋を示しています。新人エンジニアの皆さんにとって、今後AIエージェントがどのように進化していくのかを理解する上で、非常に重要な一歩となるでしょう。将来的には、より汎用性が高く、人間に近い形でスキルを習得していくAIエージェントの開発に繋がる可能性を秘めています。コードもGitHubで公開されているので、興味があればぜひ見てみてください。

引用元: https://arxiv.org/abs/2508.16153

• Lessons on building an AI data analyst

AIデータアナリストの構築は、単に自然言語をSQLに変換するだけでは不十分です。本記事は、実際のAIデータアナリスト開発経験から得られた、重要な教訓と実践的なアプローチを共有しています。

1. Text-to-SQLの限界と多段階分析の必要性 実際のビジネス上の問いは、単一のSQLでは解決困難な複雑さを持ちます。「分析計画の策定」「SQL実行」「Pythonでのデータ処理」「結果検証」「視覚化」「次の質問提案」といった多段階のワークフローが必要です。AIデータアナリストには、エンドツーエンドの分析能力が求められます。

2. セマンティック層によるビジネス意味の定義 AIデータツールでは、データが持つ「ビジネス上の意味」（例：「売上」の計算方法）を一元的に定義する「セマンティック層」が極めて重要です。これにより、LLM（大規模言語モデル）はビジネスロジックを正確に理解し、適切なデータを選び、コード生成の信頼性を高めます。また、生成されたSQLやPythonコードは実行前に検証され、誤りが早期に検出されます。 FindlyではオープンソースのMalloyを採用し、データ関係性、メトリクス、ディメンションを定義。LLMにはRAG（検索拡張生成）と関数呼び出しを通じて、関連するセマンティックモデルの一部を提供し、推論精度を高めています。

3. 複数エージェントシステムによる複雑な問題解決 複雑なリクエストに対しては、複数のAIエージェントが協力して問題を分解するアプローチが効果的です。エージェントは「分析計画の策定」「精密な情報検索」「SQL/Pythonコードの生成と実行」「結果の検証と説明」といった役割を分担します。これにより、AIの幻覚（事実に基づかない誤った情報生成）を減らし、デバッグを容易にします。

4. RAGシステムをレコメンデ