Dataiku社主催の「AI Agent Hackathon」で1位を受賞しました！— Dataikuで構築するAIエージェント：アーキテクチャから実装のコツまで解説 —

Dataikuとは？

Dataikuが提供する価値

Dataikuは、データ活用・AI活用に必要な作業をひとつの環境でまとめて進められるプラットフォームです。データ準備から分析、機械学習の構築・運用、そして生成AIやAIエージェントまで、流れを分断せずに扱えるので、プロジェクト全体のスピードが上がり、品質も安定します。

ノーコードの操作とPython/Rによる高度な分析の両方に対応しているため、データ部門だけでなくビジネスやITの担当者も同じ場所で協力できます。その結果、部署ごとの断絶がなくなり、データを使った意思決定が自然と進むようになります。

さらに、処理内容やデータの流れがフローとして見える形で管理できるので、ガバナンスの面でも安心して使えます。企業活動の中でデータ×AIを本格的に活用していくために必要な土台が、最初から揃っているプラットフォーム──それがDataikuです。

詳細はこちらです。Dataikuについてのご質問やご導入に向けたご相談は、フォームよりお気軽にお問い合わせください！

Dataikuが実現するAIエージェントの世界

Dataikuは、生成AIやAIエージェントの開発に必要な機能も提供しています。OpenAIやAnthropicといった最新の大規模言語モデル（LLM）と連携することで、チャットボットやAIエージェントなどの高度なアプリケーションをスムーズに構築できます。これらの仕組みは、従来のデータ準備や機械学習ワークフローに自然に統合できるため、ビジネスの文脈に即したエージェント開発を進めやすい点が大きな強みです。

さらに、Dataikuは「最新技術を柔軟に取り入れる」という思想を持っており、直近のアップデートである Ver14.2 では、多様な役割を持つAIエージェントをオーケストレーションする基盤である「Agent Hub」が新たに追加されました。

今後も新しい仕組みやツールが登場していく中で、Dataikuはそうした技術進化に追随しつつ、最適なアプローチを取り込み続けるプラットフォームであり続けます。

ハッカソンで構築したシステムの全体像

ダッシュボード

ユーザーが確認・操作するダッシュボードの画面イメージはこちらです。

各品番の売上数の実績値／予測値は、チャートで確認できます。これを見ながら、「なぜ？」を追求するためにAIエージェントに質問をしていきます。チャットUIはver14.2の新機能であるAgent Hubを活用しており、ここで複数の役割を持ったエージェントがオーケストレートされます。

フロー

プロジェクトのフローはこちらです。

各ゾーンでは、それぞれ次のような処理が行われます。

実際の処理の流れ

次のシナリオを想定しています。

苦労した点／工夫した点

AIエージェントが参照できるように各種データを整備する

今回のテーマは「需要予測の考察をAI エージェントに支援してもらう」ことでしたが、そのためには エージェントが参照すべき“分析の土台データ”をどう準備するかが大きなポイントになりました。

モデルの説明や予測の振る舞いを人間が理解できるようにするには、Dataikuが提供する「説明可能なAI」としての仕組みに関するデータをきちんと構造化し、質問に応じてエージェントが利用できる状態にしておく必要があります。

モデルのインサイトをAIエージェントに参照させる

今回は以下の2種類のモデルのインサイトをデータ化する方針にしています。

• Feature importance：どの特徴量がどれだけ予測に効いているかの全体像（Shapley, Gini）

• Partial Dependence（PD）：特徴量が変化したときに予測がどう変動するか

これらを選んだ理由は、「予測の背景を説明するための根拠として最も汎用的で強力」だからです。需要予測モデルが“なぜそう予測したのか？”を説明する際に、多くのヒントを与えてくれます。

モデルのインサイトの情報をどこまで渡すべきか

情報を渡しすぎると説明が冗長になる一方、少なすぎると「なぜ？」に答えられなくなります。最終的には以下のように説明に必要な最小限かつ十分な情報に絞っています。

• Feature importance

  • Shapley：上位 15 件

  • Gini：上位 15 件

• Partial Dependence（PD）

  • Shapley 上位 5 特徴量のみ

  • PD の値に加え、bin edges（固定した値のレンジ）もセットで渡す

ここで、なぜ PD だけでなく bin edges も必要なのか？について補足します。PD スコア単体では「どの値でどのくらい効くのか」がわかりません。 bin edges と組み合わせることで、以下のような高度な説明が可能になります。

• どのレンジで効果が強いのか

• どこから効きが飽和するのか

• 例えば「Sales が 500 以上で急激に効いている」などの定量的説明

• 非線形効果の発見（閾値・変曲点の特定）

これにより、“予測の根拠になる具体的な数値”まで AI エージェントが提示できるようになることを目指しています。

モデルのインサイトのデータフレーム化

モデルのインサイトはDataikuの画面で当たり前のように確認できますが、それをAIエージェントが扱える形式のデータとして整備することが今回のチャレンジの１つでした。

ハッカソンでは、Dataiku の Saved Model API を使い、モデルの各種インサイトを取得する Python レシピを作成しています。コードはおおよそ下記のような形です。

# Saved Model からアクティブバージョンを取得
savedModel    = project.get_saved_model(sm_id="xxxxxxxx")
activeVersion = savedModel.get_active_version()
versionDetails = savedModel.get_version_details(activeVersion["id"])

# モデルの説明可能性情報を取得（JSON形式）
absoluteImportance = versionDetails.get_raw()["globalExplanationsAbsoluteImportance"]
raw_importance = versionDetails.get_raw()["iperf"]["rawImportance"]
partialDependencies = versionDetails.get_raw()["iperf"]["partialDependencies"]

API で取得できる値はすべて JSON のネスト構造になっており、そのままでは扱いづらいため、最後に必要な情報だけを選別し、データフレームとして出力しています。

その他のデータ

「売上数の実績値／予測値」および「精度評価の履歴データ」についても、AIエージェントが参照できるようにデータフレームとして整備しています。

特に「精度評価の履歴データ」については、ハッカソンのプロジェクトでは、Dataikuの評価レシピで毎月の処理の中で過去の予測結果を評価し、その精度（MAPE）を自動的に記録する仕組みを構築しています。通常であれば、担当者がダッシュボードを確認しながら予測モデルの運用や監視（MLOps）を行いますが、今回はこれらの情報もAIエージェントが扱えるようにする必要がありました。

そこで、モデルのインサイトを扱ったときと同様に、API経由で必要な情報を取得するPythonレシピを作成し、それらをAIエージェントが直接参照できるデータフレームに変換しています。これにより、AIエージェントが過去の予測精度の推移を理解したうえで、より文脈に沿った応答や判断を行えるようになります。

AIエージェントの回答の品質を高めるプロンプトエンジニアリング

データを準備してAIエージェントを構成しても、一般的に、最初から期待どおりの質の高い回答を出力してくれることはありません。

Dataikuでは、AIエージェントやAgent Hub LLMのふるまいを制御するシステムインストラクション、SQL query toolのデータコンテキストなど、各所のプロンプトを詳細に設定できます。ハッカソンにおいても、AIエージェントの改善点を洗い出してプロンプトを見直し、再度テストするといった地道なトライ＆エラーによって、徐々に挙動が安定し現在の形に至っています。

そのプロンプトエンジニアリングのなかで特に重要だったポイントを整理してご紹介します。

システムプロンプトは英語で記載する

日本語での問い合わせを想定したAIエージェントのシステムプロンプトは、日本語／英語のどちらにすべきか様々な考え方があると思いますが、Dataikuを始めとしたノーコードツールを利用する場合は、「英語にすべき」と筆者は考えています。

一つ目の理由は経験則です。今回のハッカソンにおいても、日本語／英語をそれぞれ試し、英語のほうがAIエージェントの振る舞いが安定したという感触がありました。

二つ目の理由として、Dataikuを始めとしたノーコードツールでは、各機能の内部に英語のプロンプトがハードコーディングされている箇所が存在します。そのため、システムプロンプトに日本語を用いると言語が混在して精度に悪影響を及ぼす可能性があります。

こうしたノウハウはLLMがさらに進化すれば将来的には不要になるかもしれません。とはいえ、現時点においては、英語で記載しておくのが妥当ではないかと考えています。

データコンテキストを明確にする

データの背景情報をきちんと書いておくことも重要です。具体的には、SQL query toolのデータコンテキストに、「そのデータセットがどのようなものか」「どのようなシチュエーションで使われているか」「各カラムの説明」を明記しておきます。

例として、予測モデルの特徴量寄与度に紐づけるSQL query toolのデータコンテキストは、以下のように記載してあります。

The HACKATHON_FEATURE_IMPORTANCE dataset stores the contribution scores of each feature used in the prediction model.
The feature_shapley column contains the feature names, and the importance_shapley column represents their contribution scores based on SHAP values.
Please ignore all other columns in this dataset.

SQL query toolはデータコンテキストを踏まえてクエリ生成や回答を行うため、曖昧なままだと誤解に基づく誤った回答が出やすくなります。上記のように明確に記載しておくことで、AIエージェントの動作が安定します。

ツールは必要に応じて複数回使うよう明示する

これをあえてAIエージェントのシステムインストラクションに明示することで、AIエージェントが1回のツール呼び出しで満足せず、追加クエリや再取得を行いながら回答を精緻化してくれるようになりました。

一方で、これによりツールを繰り返し使い続けて終わらなくなってしまう場合もあったため、呼出し回数の上限も合わせて明示しておきます。

例として、売上数の実績値／予測値に関するAIエージェントであるSalesFiguresAgentのシステムインストラクションは、以下のように記載してあります。

# Sales Figures Agent

## Overview
You are the agent responsible for explaining sales figures.

## Responsibilities
* Report past sales figures
* Report predicted sales figures for the next 1-3 months

## General Rules
* Always query the tool, and base your answers solely on their returned data.
* Do not make assumptions, interpretations, or generalizations beyond what the agents provide.
* If required data is missing, clearly state that the agent(s) did not return it.
* Present numbers factually without adding meaning, evaluation, or explanation.
* You may call the tool multiple times if necessary to fully answer the user's question
* Try to minimize the number of calls. Limit to at most 3 calls per user query.
* After obtaining data from multiple calls, you should integrate and synthesize all the data to create a final, well-founded, fact-based, and objective answer.

システムインストラクションは、Overview（概要）、Responsibilities（責務）、General Rules（一般ルール）の3パートに分けて記載してあります。General Rulesは、全てのAIエージェントで共通して使いまわしています。

AIエージェントの回答の品質を高めるその他の工夫

AIエージェントに画像を交えて説明させる

AIエージェントがデータに基づいた説明をしてくれるのはとても良いことなのですが、唐突に数値だけ説明されると分かりにくい場面は意外と多いです。例えば「”前月の販促費”はSHAP値が319であり、予測に大きく影響しています」と言われても、それがどの程度なのか、他の特徴量と比べてどの程度優位なのかは理解しづらいですよね。

そこで、AIエージェントがチャットUI上で、対応する画像も交えて説明してくれるような仕組みにチャレンジしました。考え方・やり方を簡単にご紹介します。

1. チャットUI上に表示させたい画像を、あらかじめフロー内のPythonレシピでマネージドフォルダに保存しておく

   1. 今回は特徴量寄与度のみを、画像として表示させる対象としました

2. 画像URLを何らかの方法でAIエージェントに渡す

   1. 今回は試験的な方法として、エージェントツールの中に画像URLを埋め込み、それをAIエージェントに渡すようにしました

   2. 実運用にむけては、フォルダ内に複数の画像ファイルが定期的に保存されることが想定されるため、エージェントツールがそれらのURLを動的に取得できるようなコードを準備する必要がありそうです

3. 必要なタイミングでAgent Hub LLMに表示させる

   1. Agent HubのチャットUIはHTMLベースで実装されているため、チャット本文にHTMLのimgタグに相当する記述が含まれていれば、ブラウザ上でそのまま画像を表示できます

   2. システムインストラクションで、「特徴量寄与度の説明をするときは画像を併せて表示するようにしてください」と明示しておきます

Agent Hub LLMのシステムインストラクションは、次のように記載してあります。

# Sales Forecast Interpretation Agent

## Overview
You are an agent responsible for interpreting the outputs of sales forecasting models. You must never answer a question without first querying the appropriate data-providing agents.

（中略）

## Specific Rules
### Feature Importance Visualization
* When presenting feature importance, include an image showing the contribution of all features.
* Since the UI is HTML-based, outputting an image tag like the following will display the image:
  `<img src="https://www.ashisuto-dataiku.net/dip/api/managedfolder/">`
* Use the image URL exactly as returned by the ModelInsightAgent. External URLs are allowed.

（後略）

LLMの選択

テーマによって最適なパフォーマンスを発揮するLLMは異なります。

弊社環境ではハッカソンにおいてGPT-5とClaude Sonnet 4を比較しました。GPT-5は回答が表面的にとどまることが多い一方で、Claude Sonnet 4は複数のデータを網羅的に確認したうえで情報を整理して回答することが確認できたため、後者を採用しました。

まとめ

本記事では、需要予測の考察を支援するAIエージェントをどのように設計・実装したのかをご紹介しました。単に予測値を出すだけでなく、「なぜその予測になったのか？」をデータに基づいて説明できるエージェントを目指した点が、今回の取り組みの大きなポイントです。

ハッカソンを通じて改めて感じたのは、Dataikuがデータ準備・分析・モデル運用・AIエージェント開発までを一気通貫で扱える基盤であることの強みです。特に、Agent Hubによる複数エージェントのオーケストレーションや、SQL Query Toolを活用したデータ連携は、「実務で使えるAIエージェント」を現実的な工数で実装できることを実感させてくれました。

また、AIエージェントの品質は「LLMの性能だけで決まるわけではない」という点も重要です。分析の土台となるデータをどう整備するか、データコンテキストやシステムプロンプトをどう書くか、といった設計の積み重ねが、最終的な回答の納得感を大きく左右します。これは、PoCだけでなく実運用を見据えたエージェント開発では特に重要な視点だと感じています。

今回ご紹介した内容は、あくまでプロトタイプではありますが、「分析結果を読み解く負担をAIエージェントが肩代わりする」という方向性は、今後のAI活用において非常に現実的で価値のあるアプローチだと思います。Dataikuを使えば、こうしたエージェントを既存の分析基盤の延長線上で試せる点も大きな魅力です。

本記事が、DataikuやAIエージェントに興味を持っている方のご参考になれば幸いです。
またアシストでは、Dataikuと併せてお客様が目指すデータドリブンを実現するための伴走型支援もご提供しています。ご質問・ご相談がありましたら、フォームよりお気軽にお問い合わせください。

最後までお読みいただき、ありがとうございました！