はじめに
こんにちは、Databricksビジネス推進室の澁谷です。
2025年6月にサンフランシスコで開催されたDatabricksの年次カンファレンス「Data + AI Summit 2025」にてAIエージェント構築ツール「Agent Bricks」が発表されました。
2025年10月現在、Agent Bricksは限定されたリージョンでのベータ版提供となっており、該当の環境を触れるユーザーが先行して利用できます。
Agent Bricks は発表以降注目を集めており、実際に「触ってみた」「作ってみた」といった紹介も増えつつあります。また、AIエージェントを構築し実業務に取り込みたいというニーズを持ったお客様も増えており、Agent Bricksはその注目度を日々増しています。
今回、入社半年の新人である筆者がAgent Bricksを使ってAIエージェントを構築し、現場で活用してみました。
実際、専門的な開発スキルや知識が豊富ではない立場だからこその気付きや工夫も多くありました。
この記事では、Agent Bricksを使ってみて感じたポイントや工夫、構築の流れ、そして学びを、
新人エンジニアの等身大の目線でお伝えします。
またこの体験をもとに、Agent Bricksをどう使いこなせるかを探ってみたので、併せてお伝えしたいと思います。
この記事で伝えたいこと
- 新人がたった2時間で実践的なAIエージェントを構築できた。Agent Bricksの構築の容易さは確かなものである。
- ノーコードという強みに反して、技術者視点ではブラックボックスに感じてしまう可能性がある。
- ビジネスユーザーは「自然言語の表現」で挙動を操り、技術者は「技術記法」を活かしてLLMをチューニングできる。使いこなし方の工夫によって "誰でも" "優れたLLM設計者" になれる。
目次
- 構築編 - 「疑似顧客LLM」を作ってみた
- 活用編 - 実際に使ってみて感じたこと
- 分析編 - ブラックボックスを覗く：LLMの挙動実験
1.構築編 - 「疑似顧客LLM」を作ってみた
今回、我々の組織では2週間にわたって学生向けサマーインターンシップを開催しました。
そのプログラムの一環として、顧客課題整理ロールプレイと題し、学生が弊社コンサルタントとして顧客の抱える課題について考え、ヒアリングし、要件を整理するという実践型ワークを行いました。実業務に即した対顧客シーンのリアルな体験を通じて、学生が対顧客のコミュニケーションスキルと課題定義力、質問設計力を身に着けることが目的です。
この際、学生が対話する「疑似顧客」をAgent Bricksで構築しました。
想定設定
- 想定利用者：コンサルタント役学生
- 想定シーン：顧客へのヒアリングを通じた課題整理ワーク
- エージェントの役割：
- 国内大手の食品メーカーを想定した架空企業の経営層／IT戦略企画部門担当
- 自社のDX・データAI利活用を推進中
- 教育的な観点で、やや厳しく、簡単には情報が引き出せない顧客を演じる
- 学生の質問内容を見極めながら、的確かつリアルな回答を返す
※用いた設定・データは公開情報や一般的な知見をもとに再構成したものであり、実在の企業の機密情報・プロジェクトデータは一切含まれていません。
構築の流れ
上記記事を参考にしながら「Agent Bricks」が使用できる環境を準備しました。テンプレートで「カスタムLLM」を選択し、「基本情報」のタスク説明欄に指示文を入力しました。
指示文を要約すると以下の通りです。
- 国内大手の食品メーカーの経営層／IT戦略企画部門として回答。
- 抽象的・曖昧な質問には厳しく、具体的で丁寧な質問にのみ回答する。
- 質問内容に応じて表情（😊🙁😠） を変え、質問力を評価する。
- 丁寧な質問→😊 を先頭に付けて穏やかに回答
- 抽象的な質問→🙁 の表情と共に、質問意図や説明が不足している旨を回答する
- 敬語が使われていない質問→😠 と付けて「敬語を使うべき」と指摘する
- 企業背景として、健康志向の高まりで機能性食品が拡大中である。企業の強みは研究力とブランド力、課題は国内需要減少と海外比率の低さが挙げられる。競合企業は●●社・△△社・■■社・☆☆社など。
別途、想定される質問（学生質問 列）とそれに対する回答（顧客回答 列）を150件まとめたcsvファイルを用意し、Databricks NotebookでDeltaテーブル化しました。Agent Bricks画面「ソースデータ」で"ラベル付きデータセット"を選択し、入力例として学生質問 列、出力例として顧客回答 列を選択し、最後に「エージェントを作成」ボタンを押下するとわずか3分ほどでエンドポイントが作成されます。
完了すると、以下のようなエージェント設定画面に遷移します。
右側の 「指示（Instructions）」タブ には、前画面の 「タスクを説明してください」 に入力した内容がそのまま反映されています。
この画面でエージェントの応答を確認しながら、指示文を微調整 → 「保存して更新」をクリックすることで、チューニング（調整） が可能です。
または「ガイドライン」タブに、入力されたタスクの説明から自動的に作成されたエージェントの応答ガイドラインが複数作成されて自然言語（英語）で表示されます。ここを自然言語（日本語OK） で書き換えたり、新たなガイドラインを追加したり、意図の異なるガイドラインを削除することによってもチューニングが可能です。
また、同画面中央に、想定入力に対してエージェントの応答例が5件表示され、「これは良い反応ですか？」に対して「はい」/「いいえ」、「いいえ」の場合はエージェントの回答に対するフィードバックを自然言語で入力することができ、このルートで対話的にチューニングすることも可能です。
作成したエンドポイントは、ai_query 関数や Playground 画面から何度でも再利用できます。
ai_query(endpoint,input)
以上の方法で数回のチューニングとテストプレイを行い、想定通りの出力をするエージェントが完成しました。
ここまでにかかった時間は…たった2時間でした！
「自然言語でAIエージェントが作れる機能ですよね？」という程度の前提知識しかない新人でも、
半日かからず思い通りのエージェントを構築できてしまうのです。
新人の感想💭
思いついたことをそのまま書いてもエージェントが出来上がるのが驚き。
正直、日本語の文章として整った指示文を用意したわけではなく、むしろ思い付きで書いたようなタスク説明を入力しました。それでもAgent Bricksは文脈や意図を正確に理解して、人格を持ったような自然な応答をするAIエージェントが生成されました。体裁が大きく影響しないのはノンストレスですし、小さいながらも確かな工数の削減を実感しました。
UIが直感的で、作業ステップがとても少ない。
画面の流れに沿って数行入力、数クリックで構築が完了しました。コーディング知識がなくても、非常に簡単に自分のイメージをそのまま形にできます。作ったAIエージェントをすぐに自分のデータに適用し、インサイトを引き出したりアプリケーションに組み込めるのも驚きです。
専門用語でなくても指示が通ることに感動。
出力の文章が長く感じたので「やや厳しい顧客にしたい」「簡単には情報を出さない」という指示を追加し再学習したところ、クローズドクエスチョンにのみ簡潔に情報を出力させることができました。一般的にAI構築の文脈で使用されるような言葉ではないワードを使用しても、構築者の意図をくみ取って技術的に最適化される点は興味深いです。
次はAIエージェントを改善し、使い続けていくために、MLflowによるAIエージェントの評価などのLLMOpsについても学んでいきたいと思っています。
2.活用編 - 実際に使ってみて感じたこと
実際に使ってみた印象
-
想定どおり、「質問の質」によって表情（😊🙁😠）が変化し、リアルな顧客感が再現できた。
-
構築時に入力例として用意していなかった質問に対しても、顧客の状況を踏まえた自然な応答が返ってきた。
-
学生からは「思ったより自然に会話が成立する」「相手が“考えている感じ”がする」といった声が上がり、さらに「LLM相手ながら、ITコンサルタントとして顧客課題を一人称で考察する経験、クローズドクエスチョンで顧客の真のニーズを引き出す経験を通じてコンサルスキルを学べた」との感想も得られた。
→教育的な目的は十分に達成された。 -
従来、このようなワークは社員が顧客役を務めるロールプレイ形式で実施していたが、
今回はその役割をLLMが担うことで、社員の負担を軽減しつつ、より多くの学生が参加できる環境を整えることができた。
→ AIエージェントの果たす役割の大きさとAgent Bricksの構築の容易さは、工数削減に大きく寄与するものであり有効活用すべきである。 -
ただし、「なぜそのように出力されたのか？」「どのモデルが使われているのか？」といった質問には答えられなかった。
→理由は明確で、内部ロジックが見えない“ブラックボックス”構造だからである。
■ブラックボックスだと感じたポイント■
1. モデルの選択ができない
どのLLM（GPT・Claudeなど）が使われているかUI上で明示されず、手動での固定・切り替えは提供されていない（執筆時点）。モデル選定やパラメータ最適化は内部で自動化されている。
2. temperature や max_tokens などのパラメータを操作できない
出力の多様性や長さを明示的に調整できず、「なぜこの出力になったのか」を説明できない。
プロンプト以外の制御手段が限られるため、チューニングの感覚がつかみにくい。
3. 挙動学習・再現の仕組みが不透明
チューニングを繰り返すと確かに出力は改善されるが、どの要素がどのように学習・反映されたのかが可視化されない。
まとめ
Agent Bricks はノーコードで直感的にLLMを構築できるメリットの反面、2025年10月現在の仕様においては内部ロジックの非公開性が強く、「モデル理解」や「根拠ある検証」を行いたい人にとっては不安が残るかもしれないと気付きました。
ただし、非エンジニアでも即戦力レベルのAIを構築できる手軽さは確かであり、
今回の気付きは、仕組みの裏側を探り、理解を深める次の挑戦へのきっかけとなりました。
3.分析編 - ブラックボックスを覗く：LLMの挙動実験
ここまで、実業務の中でAgent BricksでLLMを構築・活用してみて、ノーコードでエージェントを作れる非常に優れた機能である一方で、技術者視点ではブラックボックスに感じてしまう可能性を示唆しました。
そんな環境で、技術に詳しい人もそうでない人も、
誰もが、効果的に、Agent Bricksを使いこなすにはどうすればよいか？
そのヒントを探るために、以下の3つの観点から実験を行いました。
実験①｜自然言語ディレクティブで temperature は動くか？
実験②｜技術的パラメータ記法はくみ取られるか？
実験③｜入出力サンプルの数の重要性はいかほどか？
実験①｜自然言語ディレクティブで temperature は動くか？
目的
タスク説明の言い回しを変化させることで、LLM出力の創造性や安定性を変化させられるのかどうかを検証しました。
→タスク説明欄における性格の指示の重要性を明らかにするとともに、技術パラメータtemperatureを変化させる自然言語の表現技法を探ります。
実験方法
タスク説明に、答え方を指定する文章を加えた、以下3種のエージェントを構築しました。
- Neutral：追加指示なし
- Low-var：「ぶれずに一貫して、簡潔に要点だけ答える」
- High-var：「自由な発想で、比喩や提案も交えて答える」
※赤枠・矢印はプロンプト（タスク説明）変更箇所を示しています。
これらに対して質問を3件行った際の、出力結果と以下の値を計測しました。
| 列名 | 説明 |
|---|---|
| tokens_mean | 出力されたトークン数（単語や記号）の平均値 |
| tokens_std | トークン数のばらつき（標準偏差） |
| latency_mean | 応答にかかった平均時間（秒） |
結果・考察
| condition | tokens_mean | tokens_std | latency_mean |
|---|---|---|---|
| High-var | 330.67 | 29.37 | 13.40 |
| Neutral | 76.67 | 50.20 | 8.33 |
| Low-var | 55.67 | 16.65 | 9.36 |
High-var は最も長文（約330トークン）で、応答時間もその分長い結果になりました。
Low-var は最短（約55トークン）で、出力の長さが安定しており、再現性の高さが読み取れます。
→この傾向は、LLM における高・低 temperature 設定時の挙動に酷似しています。
従って、自然言語指示で temperature 設定をした時と同等の挙動を誘発できると言えます。
同じ入力「御社の現状のデータ基盤で発生している課題はありますか？」に対する回答を定性的に比較してみると、3つのLLMの出力の差は歴然です。
(※High-varの出力にハルシネーションが起きている点は注意。Databricksのアーキテクチャはレイクハウスである。)
Low-varでは、出力が短く要点が明確で、情報の揺らぎは少ないです。
Neutralは、課題と解決策をつなぐ中程度の構成で、バランスの取れた出力がされており、
High-varでは、説明の広がりや概念の結合が多く、内容展開に創造性が見られました。
結論
- 自然言語でのトーン指定によって、temperatureを設定したときのような出力の違いが再現される傾向が見られました。
- 特に「ぶれずに」「簡潔に」「自由に」といった自然言語の表現は制御に有効です。
実験②｜技術的パラメータ記法はくみ取られるか？
目的
技術に詳しいユーザーが、自然言語タスク説明の中でtemperature=0.1 や model=gpt-4o のようにハイパーパラメータを明示的に記述した場合、挙動差が観測されるかどうかを検証しました。
→ノーコード環境でも、技術的知識を活かして精密制御できるかを確認します。もし無視されるなら、「プロンプト設計に集中すべき」と判断できます。
実験方法
タスク説明末尾にtemperatureを明示的に記述した以下2種のエージェントを構築しました。
- 0.1：temperature=0.1
- 0.9：temperature=0.9
またtemperatureとmodelを明示的に記述した以下2種のエージェントを構築しました。
- gpt-4o：temperature=0.5, model=gpt-4o
- claude：temperature=0.5, model=claude-3.5-sonnet
※赤枠・矢印はプロンプト（タスク説明）変更箇所を示しています。
これらに同一質問を行ったときの出力結果を比較しました。
計測した値は、実験①と同じ tokens_mean, tokens_std, latency_mean です。
結果・考察
| condition | tokens_mean | tokens_std | latency_mean |
|---|---|---|---|
| 0.1 | 133.33 | 80.87 | 10.51 |
| 0.9 | 440.67 | 36.67 | 14.14 |
temperature=0.1 をタスク説明に明示的記述したLLMでは、短く要点を押さえた応答が多く、反応速度も速かったです。
一方、temperature=0.9 LLMでは出力量が圧倒的に増え、応答が長く創造的になる傾向が見られました。
同じ入力「御社の現状のデータ基盤で発生している課題はありますか？」に対する回答を定性的に比較してみると、その差は歴然です。
これはまさに、タスク説明欄における明示的なtemperatureの記述（temperature=〇〇）が
Agent Bricksが内部的にtemperature指定を読み取っている可能性を示唆しています。
また、モデルの明示的指定を組み込んだ2つのLLMの出力結果は以下の通りでした。
| condition | tokens_mean | tokens_std | latency_mean |
|---|---|---|---|
| gpt-4o | 87.33 | 43.94 | 10.56 |
| claude | 94.33 | 20.84 | 8.93 |
GPT-4oは柔軟でばらつきが大きく、claudeは安定した出力を行う傾向を示しました。
これだけ見ると大きな違いはないように感じられますが…
同じ入力「御社の現状のデータ基盤で発生している課題はありますか？」に対する回答を比較してみると、両者の出力は全く異なっていました。
それぞれのモデルの一般的な特徴としては以下が挙げられます。
GPT-4o（OpenAI）
- 論理的で構造的。即座に答えを提示する。
- 推論・計算・コード生成に強い。
- 内容が整理され、形式的な出力が得意。
Claude 3.5 Sonnet（Anthropic）
- 丁寧で慎重。曖昧な質問では「目的を確認する」など前提確認型。
- 長文要約や会話の一貫性に強い。
- 共感的でヒューマンライクなトーン。
今回観測された同じ入力に対する応答文体の差は、
GPT-4o：「生産管理、販売管理…」と業務説明を展開。
Claude：「質問の意図が理解できませんね」と前提確認を含む慎重な応答。
→ 両者の応答パターンが、一般的なモデル特性と概ね一致していました。
以上より、temperatureの明示的記述を読み取れたのと同様に、モデルの指定が内部で解釈された可能性が示唆されました。
結論
- temperature= や model= のような技術的パラメータ記法のタスク説明欄への入力は、Agent Bricks内部で解釈され反映されている可能性が高いです。
- 技術的パラメータの明示的な記述も、ノーコード環境内での挙動誘導になり得ます。技術者にとってもAgent Bricksは活用価値のあるツールであると言えます。
実験③｜入出力サンプル数の重要性はいかほどか？
目的
入出力例の量が、LLMの出力にどれほど影響するかを確認します。
→「入出力例を増やせば増やすほど良いのか」それとも「自然言語でのチューニングに注力すべきか」を明らかにすることは、設計上のリソースバランス調整の判断材料になるため重要です。
実験方法
初期画面「ソースデータ」で「いくつかの例」を選択し、以下画像の通り入出力例を4件入力し、LLMを構築しました（=Fewshot条件）。
- Neutral：入出力例 150件
- Fewshot：入出力例 4件
実験①のNeutral条件で構築したLLMと、Fewshot条件のLLMに同じ入力を行った際の出力を比較しました。
結果・考察
150件の方が「やや厳しく、簡単には情報を出さない顧客」という出力方針の再現度は強いものの、4件でもほぼ同等の出力品質が得られました。
結論
- Fewshot（数行）で意図する出力が確認できました。
- 150行入れても改善は限定的であり、入出力サンプルを増やすことに注力したLLM教育は効率的とは言えません。
- エージェント構築の際は、入出力サンプルの数を増やすより、タスク説明の表現の工夫により注力するのが実践的であると言えます。
まとめ
| 実験 | 着目点 | 主な発見 |
|---|---|---|
| 実験① | 自然言語ディレクティブ | 自然言語で temperature の制御が可能 |
| 実験② | 技術的パラメータ記述 | temperature や model 記述が内部で解釈される可能性が示唆 |
| 実験③ | 入出力サンプル量 | 数例で十分であり、タスク説明の表現の工夫により注力すべき |
一見ブラックボックスのような環境でも、ビジネスユーザーは「自然言語の表現」で挙動を操り、技術者は「技術記法」を活かしてチューニングできます。
つまり、使いこなし方の工夫によって真に "誰でも" "LLM設計者"になれるのです。
この3つの実験は、Agent BricksがDatabricksのミッションである「データとAIの民主化」の実現に向けた大きな一歩である証拠を裏付けしたものであると言えます。
おわりに
本記事では、注目の高まる新機能Agent Bricksを使って新人が実践的なエージェントを構築・活用してみたリアルな感触や学びをお伝えしました。また、いくつかの実験を通してAgent Bricksの上手な使いこなし方を探ってみた結果をお伝えしました。
Agent Bricksは、どんな立場の方にとっても、使いこなし方の工夫によって実用的なAIエージェントを構築できる新機能であることを確信しています。
ぜひみなさんも、気軽に業務の中でAgent Bricksを活用してみてください！
※本記事の内容はあくまで2025年10月現在、ベータ版のAgent Bricksを使った結果です。
※本記事に登場する企業名・設定・会話内容はすべてフィクションであり、実在の企業・団体・個人とは関係ありません。
仲間募集
NTTデータ ソリューション事業本部 では、以下の職種を募集しています。
Databricks、生成AIを活用したデータ基盤構築/活用支援（Databricks Championとの協働）
Snowflake、生成AIを活用したデータ基盤構築/活用支援（Snowflake Data Superheroesとの協働）
プロジェクトマネージャー（データ分析プラットフォームソリューションの企画～開発～導入／生成AI活用）
クラウドを活用したデータ分析プラットフォームの開発(ITアーキテクト/PM/クラウドエンジニア)
データドリブンDXを推進するデータサイエンティスト
ソリューション紹介
Trusted Data Foundationについて
～データ資産を分析活用するための環境をオールインワンで提供するソリューション～
最新のクラウド技術を採用して弊社が独自に設計したリファレンスアーキテクチャ（Datalake+DWH+AI/BI）を顧客要件に合わせてカスタマイズして提供します。
可視化、機械学習、Deep Learningなどデータ資産を分析活用するための環境がオールインワンで用意されており、これまでとは別次元の量と質のデータを用いてアジリティ高くDX推進を実現できます。
TDFⓇ-AM（Trusted Data Foundation - Analytics Managed Service）について
～データ活用基盤の段階的な拡張支援（Quick Start) と保守運用のマネジメント（Analytics Managed）をご提供することでお客様のDXを成功に導く、データ活用プラットフォームサービス～ TDFⓇ-AMは、データ活用をQuickに始めることができ、データ活用の成熟度に応じて段階的に環境を拡張します。プラットフォームの保守運用はNTTデータが一括で実施し、お客様は成果創出に専念することが可能です。また、日々最新のテクノロジーをキャッチアップし、常に活用しやすい環境を提供します。なお、ご要望に応じて上流のコンサルティングフェーズからAI/BIなどのデータ活用支援に至るまで、End to Endで課題解決に向けて伴走することも可能です。
NTTデータとDatabricksについて
NTTデータは、お客様企業のデジタル変革・DXの成功に向けて、「Databricks」のソリューションの提供に加え、情報活用戦略の立案から、AI技術の活用も含めたアナリティクス、分析基盤構築・運用、分析業務のアウトソースまで、ワンストップの支援を提供いたします。
NTTデータとSnowflakeについて
NTTデータとSnowflakeについて
NTTデータでは、Snowflake Inc.とソリューションパートナー契約を締結し、クラウド・データプラットフォーム「Snowflake」の導入・構築、および活用支援を開始しています。
NTTデータではこれまでも、独自ノウハウに基づき、ビッグデータ・AIなど領域に係る市場競争力のあるさまざまなソリューションパートナーとともにエコシステムを形成し、お客さまのビジネス変革を導いてきました。
Snowflakeは、これら先端テクノロジーとのエコシステムの形成に強みがあり、NTTデータはこれらを組み合わせることでお客さまに最適なインテグレーションをご提供いたします。
NTTデータとInformaticaについて
NTTデータとInformaticaについて
データ連携や処理方式を専門領域として10年以上取り組んできたプロ集団であるNTTデータは、データマネジメント領域でグローバルでの高い評価を得ているInformatica社とパートナーシップを結び、サービス強化を推進しています。
NTTデータとTableauについて
NTTデータとTableauについて
ビジュアル分析プラットフォームのTableauと2014年にパートナー契約を締結し、自社の経営ダッシュボード基盤への採用や独自のコンピテンシーセンターの設置などの取り組みを進めてきました。さらに2019年度にはSalesforceとワンストップでのサービスを提供開始するなど、積極的にビジネスを展開しています。
これまでPartner of the Year, Japanを4年連続で受賞しており、2021年にはアジア太平洋地域で最もビジネスに貢献したパートナーとして表彰されました。
また、2020年度からは、Tableauを活用したデータ活用促進のコンサルティングや導入サービスの他、AI活用やデータマネジメント整備など、お客さまの企業全体のデータ活用民主化を成功させるためのノウハウ・方法論を体系化した「デジタルサクセス」プログラムを提供開始しています。
NTTデータとAlteryxについて
NTTデータとAlteryxについて
Alteryxは、業務ユーザーからIT部門まで誰でも使えるセルフサービス分析プラットフォームです。
Alteryx導入の豊富な実績を持つNTTデータは、最高位にあたるAlteryx Premiumパートナーとしてお客さまをご支援します。
導入時のプロフェッショナル支援など独自メニューを整備し、特定の業種によらない多くのお客さまに、Alteryxを活用したサービスの強化・拡充を提供します。
NTTデータとDataRobotについて
NTTデータとDataRobotについて
DataRobotは、包括的なAIライフサイクルプラットフォームです。
NTTデータはDataRobot社と戦略的資本業務提携を行い、経験豊富なデータサイエンティストがAI・データ活用を起点にお客様のビジネスにおける価値創出をご支援します。
NTT DATA公式アカウントです。 技術を愛するNTT DATAの技術者が、気軽に楽しく発信していきます。 当社のサービスなどについてのお問い合わせは、 お問い合わせフォーム nttdata.com/jp/ja/contact-us/ へお願いします。