2026 年 11 月 5 日 : 11 月の全日程（6 回）を掲載しました。11 月 6 日の回は満席のため、同じ内容の回を 11 月 27 日 に追加しました。 2026 年 10 月 30 日 : 11 月 11 日の回を掲載しました。 2026 年 10 月 29 日 : 初版を公開しました。 AWS Japan では、2026 年 11 月から、AWS のセキュリティサービスを実際に操作するオンラインハンズオンを週次で開催します。各回は座学とハンズオンの 2 部構成で、AWS Security Agent (now part of AWS Continuum)、AWS WAF、Amazon Inspector などを題材に、ご自身の組織で試すための最初の一歩までをお伝えします。業界を問わず、ユーザー企業・団体の方を対象としています。 本記事はその案内ページです。2026 年 11 月の開催日程（6 回）がすべて決まりました。12 月以降の日程も決まり次第この記事に追記していきますので、ブックマークしてご活用ください。 これまでの取り組み AWS Japan パブリックセクター技術統括本部では、2026 年 4 月から、座学とハンズオンを組み合わせたセキュリティワークショップを月 1 回開催してきました。6 月からはフロンティア AI 時代の脅威対策をテーマにしており、7 月には本シリーズで使う AWS Security Agent のハンズオンも実施しています（開催報告: ランサムウェア対策（脅威検知・統合セキュリティ管理） ／ Claude Mythos 時代の脅威対策（脆弱性管理・AI エージェントによるセキュリティ評価） ／ 耐障害性ライフサイクル ／ AI 時代の Web アプリケーション防御 ）。 10 月には「 ［臨時開催］FY2026 AWS セキュリティセミナー ― フロンティア AI 時代のサイバー攻撃に備える ― 」を開催し、多くの方にご参加いただきました。10 月 30 日にも、同じ内容で 第 2 回 を開催しました。 これらのセミナーでお伝えしたのは「いま何をすべきか」です。次の一歩は、実際に手を動かして、自組織のアプリケーションで試せる状態になることです。 なぜ月 1 回から週次に広げるのか AI の活用が進み、脆弱性を見つけて直す取り組みを、これまでより早く進められるようになっています。本シリーズは、その取り組みを実際に体験していただく場です。 10 月の臨時セミナーには想定を大きく上回るお申し込みをいただき、あわせて案内した 11 月の対面ハンズオンも、募集開始後すぐに満席となりました。そこで開催の頻度を増やし、より多くのお客様に手を動かして試していただけるよう、ハンズオンをオンラインで毎週繰り返し、日程の合う回にご参加いただける形にしました。 どんなことを体験できるか 各回とも、座学とハンズオンの 2 部構成です。座学で考え方を整理したうえで、ハンズオンでは AWS のセキュリティサービスを実際に操作していただきます。ハンズオンで使う環境は AWS 側で用意します。 現在、次のようなテーマを予定しています。各回のテーマは開催日程の表をご覧ください。 AWS Security Agent (now part of AWS Continuum) : AI エージェントによるアプリケーションのセキュリティレビューとペネトレーションテスト AWS WAF : 公開 Web アプリケーションの入り口での防御 Amazon Inspector : OS やミドルウェアの脆弱性管理 Claude/GPT などのフロンティアモデルを活用したソースコードの脆弱性対策 : フロンティアモデルを使ってソースコードの脆弱性を見つけ、対策する方法 AI エージェントと進めるマイグレーション・モダナイゼーション : サポートが終了したランタイムやフレームワークで動くアプリケーションを、AI エージェントと一緒に新しい環境へ移行する方法 テーマは、お寄せいただくご要望に応じて追加・変更します。各回の詳しい内容は、決まり次第この記事と申込ページでお知らせします。 対象となる方 ソフトウェア開発者、DevSecOps エンジニア、セキュリティエンジニアの方 公開 Web アプリケーションや API を開発・運用している組織の方 前提知識: 最新のブラウザが使えること 本ハンズオンは、ご自身のシステムをお持ちのユーザー企業・団体の方を対象としています。パートナー企業の方は、担当の AWS パートナー部門へご相談ください。 開催日程 同じテーマを複数回開催します。ご都合の合う回にお申し込みください。いずれもオンライン開催です。日程が決まり次第、この表に行を追加します。終了した回は一覧から下げていきます。 日時 テーマ 申込 2026 年 11 月 6 日（金）14:30 – 17:30 AWS Security Agent (now part of AWS Continuum) ハンズオン ※ 満席のため、同じ内容の回を 11 月 27 日 に追加しました 満席 2026 年 11 月 11 日（水）15:00 – 17:00 Claude/GPT などのフロンティアモデルを活用したソースコードの脆弱性対策 ハンズオン 申込ページ 2026 年 11 月 18 日（水）14:30 – 17:30 AI エージェントと進めるマイグレーション・モダナイゼーション ハンズオン 申込ページ 2026 年 11 月 20 日（金）14:30 – 17:30 AWS WAF ハンズオン 申込ページ 2026 年 11 月 25 日（水）14:30 – 17:30 Amazon Inspector ハンズオン 申込ページ 2026 年 11 月 27 日（金）14:30 – 17:30 AWS Security Agent (now part of AWS Continuum) ハンズオン （11 月 6 日の回と同じ内容） 申込ページ 2026 年 12 月（日程調整中） AWS WAF AWS Security Agent Amazon Inspector Claude/GPT などのフロンティアモデルを活用したソースコードの脆弱性対策 準備中 お申し込みについて 申込ページからお申し込みいただくと、参加用の URL がメールで届きます 申込には AWS のイベントサイト（Connected Community）への会員登録（無料）が必要です。勤務先のメールアドレスでご登録ください 定員を超えた場合はキャンセル待ちとなります。枠が空くと自動的に繰り上がり、確認メールが届きます 各回の定員は、当日のサポート体制に合わせて設定しています ハンズオンの先にあるもの このハンズオンのゴールは、体験した内容を ご自身の組織のシステムで実際に試せる状態 になることです。 そのために、各回の最後には、ご自身の環境で始めるときの最初の一歩をご案内します。たとえば、どのシステムから始めるか、まず何を有効にして何を確認するか、といった点です。ハンズオン後に具体的なご相談がある場合は、担当の AWS アカウントチームまでお問い合わせください。 著者 梅田 昌太 (Shota Umeda) アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター技術統括本部 シニアソリューションアーキテクト パブリックセクターのお客様の技術支援を担当。2026 年 4 月から、本記事で紹介したセキュリティワークショップシリーズと 10 月の臨時セミナーの企画・運営に携わっています。

はじめに SB OAI Japanでエンジニアとして働くChanyaです。 2026年10月20日、東京で開催された OpenAI DevDay Exchange Tokyo 2026 に参加しました。 会場となったベルサール新宿グランドの入口。 この記事では、聴講したセッションを振り返りながら、OpenAIの技術を日々の開発や業務に取り入れるためのヒントを整理します。OpenAIのAPIやCodexを使っているエンジニア、AIを業務に組み込むことを検討している方に向けた参加レポートです。 会場内のイベントロゴ。 OpenAI DevDay Exchangeとは DevDay

AIエージェントによるデータ分析は、コーディングに続いてエージェント化が進む領域です。dotDataは、データ分析も今後1〜3年で大きく変わると見ています。ただし、カンファレンスのデモでは鮮やかに動くAIエージェントも、自社のデータに当てると誤答が増えるのが現実です。その原因の多くは、モデルの性能ではなく、エージェントに与えるデータと、そのデータの「意味」の側にあります。 本記事では、次の4点を解説します。 仕組みと現在地 ：AIエージェントによるデータ分析とは何か、どこまで進んでいるのか 事例と使い方 ：活用事例と、3つのアプローチ 失敗要因 ：デモでは動くのに、自社データでは精度が出ないのはなぜか 導入の進め方 ：成否を左右する要因と、導入に向けた4つのステップ AIエージェントによるデータ分析とは何か：レポート作成までを自律的に実行する仕組み AIエージェントによるデータ分析とは、AIエージェント（AI agent）が業務上の問いを受け取り、複数のデータソースにまたがるデータの探索・加工・集計・解釈・レポート化までを自律的に進める分析の形です。AIを使ったデータ分析（AIデータ分析）のなかでも、手順ごとに人の指示を待たずに、エージェントが分析の手順を自ら組み立てる点が、BIツールやAIアシスタントとの違いです。 エージェントによる分析は、一般的には次の流れで進みます。 問いを受け取る ：「来月解約しそうな顧客は？」「商品Aの売上が下がった理由は？」といったビジネス部門の問いを、自然言語で受け取る データを探す ：データ基盤とAPIなどで連携し、問いに答えるために必要なテーブルや文書を探す 加工・集計する ：SQLやPythonのコードを生成し、データを結合・集計する 解釈する ：集計した数字から、要因や傾向を読み解く レポートにまとめる ：読み手に合わせて、結果を可視化し、打ち手とあわせてまとめる この流れを実務で使える水準で回すには、エージェント単体ではなく、次の4つの構成要素をそろえる必要があると、dotDataは考えています。 構成要素 役割 例 データ基盤 分析の対象となる、正しく整ったデータをそろえる データウェアハウス、データマート、データカタログ 意味の層 指標の計算方法や用語の定義、業務の文脈をエージェントに伝える 指標の定義、用語集、マニュアルや議事録 AIエージェント 問いを受けて、探索・加工・集計・解釈・レポート化を進める 汎用エージェント、データ基盤と連携するエージェント 人の確認と評価 要所で方向を修正し、出力の正しさを確かめる Human-in-the-Loop、LLM as a Judge 多くの場合につまずくのは、2つ目の「意味の層」です。この点は、本記事の後半で詳しく説明します。 業務のエージェント化はどこまで進んだか 専門知識と判断を必要とする業務から、AIエージェントによる代替が始まっています。最も変化が早いのはソフトウェア開発です。 図：AIエージェントによる専門業務の変化と、次の主戦場としてのデータ分析（出典：dotData Webinar資料「AI Agentの新トレンド〜精度を決める『AI-Ready Data』〜」（2026年7月）より） dotDataでも、エンジニアはコーディングエージェントを日常的に使っており、自分でコードを書く時間は大きく減りました。エンジニアの主な仕事は、どのようなソフトウェアをどのようなアーキテクチャで作るかを設計すること、エージェントが書いたコードをレビューすること、そしてエージェントを正しく動かすことに移っています。1年ほど前には「まだ自分たちで書く部分のほうが多い」という声が社内でも聞かれましたが、その状況は短期間で大きく変わりました。 同様の変化は、ほかの専門業務にも広がっています。 業務 エージェントが担い始めている作業 ソフトウェア開発 コードの生成、テスト、修正 カスタマーサポート 一次対応、問い合わせの要約、回答の生成 法務・契約レビュー 条項の抽出、リスクのチェック リサーチ 情報収集、要約、レポート化 dotDataでは、次に大きく変わるのはUXデザインのようなクリエイティブの分野だと見ています。1年後には、いまのコーディングと同じように、デザイナーの仕事そのものが再定義されているかもしれません。 これらに共通するのは、「専門知識×判断」を必要としてきた点です。専門家にしかできなかった仕事ほど、エージェント化によるインパクトは大きくなります。 なぜデータ分析へのAIエージェント活用はまだ進んでいないのか：3つの課題 データ分析は、業務とデータの両方に深く接しているため、汎用的なAIエージェントだけでは完結しにくい領域です。そのため、コーディングに比べると、エージェントの活用は遅れています。 課題は大きく3つあります。 業務との接点が深い ：どのような問いを立てるか、指標が何を意味するか、分析がビジネスの意思決定にどう使われるかは、部門ごとに異なります。 データとの接点が深い ：自社のテーブル構造、指標の定義、データの加工ルールを理解しなければ、正しい分析はできません。 自由度が高い ：分析の問いには正解が1つに決まらないものが多く、進め方の選択肢も広くあります。 実際、dotDataが関わっている米国の企業を含め、グローバルに見ても、分析をAIエージェントに全面的に任せ、人が分析をしなくなったという組織は、現時点ではほとんど見られません。 一方で、コーディングやクリエイティブの分野で起きた変化の速さを踏まえると、データ分析も今後1〜3年で大きく変わると、dotDataは考えています。数年後には、人が行う分析よりもAIエージェントが行う分析のほうが多くなる時代が来るでしょう。 データ分析の3段階：ツール支援型から、エージェントが自律的に分析する段階へ 分析は、人がツールを使う段階から、AIが人を手伝う段階へと進んできました。その先にあるのが、AIエージェントが自ら分析・判断・実行する段階です。今後1〜3年で、分析の主役は人からAIエージェントへ移っていくと、dotDataは見ています。 図：AIによるデータ活用の進化（出典：dotData Webinar資料「AI Agentの価値は、データで決まる」（2026年12月）より） 段階 人とAIの関係 代表的な技術 ツール支援型 人間中心。人がツールを使って分析する BI、AutoML AI拡張型（現在） 人間中心。AIが人の分析を手伝う Copilot、AIアシスタント エージェント駆動型（これから） AIエージェントが分析・判断・実行を担い、人は方向付けと承認を行う（Human-in-the-Loop） 自律的に動くAIエージェント これまでと現在：ツールによる支援から、AIによる支援へ 最初の段階では、ノーコードのBIツールや、機械学習モデルの構築を自動化するAutoML（自動機械学習）が、分析を担う人を支えました。dotDataが2018年に最初に提供した製品も、AutoML製品（dotData Enterprise）です。この段階では、分析の中心はあくまで人でした。 現在は、AIが人の分析を手伝う段階にあります。分析を担う人がチャットで問いかけると、Copilot（人の作業を隣で補助するAI）やAIアシスタントが集計や可視化を手伝います。Databricks GenieやSnowflake Intelligenceのように、データ基盤上でAIに自然言語で問いかける製品が代表例です。 次の段階では、人とエージェントの役割分担はどう変わるか 次の段階では、繰り返し行う分析をエージェントが担い、人は要所で方向付けと承認を担います。この関わり方を、Human-in-the-Loop（HITL）と呼びます。 人が中心に残る分析 ：アドホックで複雑な分析や、新しい問いを立てる分析 エージェントが担う分析 ：経営指標の裏側で何が起きているかを定期的に確認するような、定例の分析 人の役割 ：エージェントの分析を使って意思決定し、ビジネスを改善すること AIエージェントをデータ分析に活用すると、どのようなメリットがあるか AIエージェントをデータ分析に活用する最大のメリットは、組織の中で繰り返し発生する数多くの分析を、人手に頼らず回せるようになることです。具体的には、次のような効果が期待できます。 分析の量とスピード ：たとえば、毎月の売上の変動要因を、地域別・商品別にエージェントが繰り返し分析できるようになります。人手が足りずに後回しになっていた分析も、対象にすることが可能になります。 業務の効率化 ：データの抽出や処理、集計、定例レポートの作成をエージェントが担い、担当の方は解釈と判断に時間を使えるようになります。 データ活用の民主化 ：営業や企画の部門が、専門の分析チームに依頼しなくても、自然言語で問いを投げて答えを得られるようになります。 ただし、こうした効果は、エージェントの分析が正しいことが前提です。後半では、その前提を崩す要因を見ていきます。 データ分析にAIエージェントを活用した事例 こうした取り組みは、自然言語でデータに問い合わせる機能から始まっています。ここでは、データ基盤ベンダーのSnowflakeが公表している2つの事例を紹介します（いずれもベンダー公表の事例です）。 Bayer（製薬・農業） ：Bayerは、Snowflakeの自然言語分析機能Cortex Analystを使い、自社データに対するセルフサービス分析を進めています。最初の段階では、営業部門の幹部が投げる「先月の製品Xの市場シェアは？」といった、経営上の価値が高い質問に答える用途から始めました（ Snowflake, 2024年8月 ）。 TUI（旅行） ：TUIは、Cortex Analystを基盤に、自然言語でデータに問い合わせられるAI基盤「TACO（Technology Analytics Companion）」を構築しました。Snowflakeの事例ページでは、こうした取り組みで年間30日以上の工数を削減できる可能性があるとしています。ただし、これは見込みであり、TUI自身も現段階で正確な効果を見極めるのは難しいとしています（ Snowflake ）。 2つの事例に共通するのは、問いと指標がはっきりした分析から始めている点です。誰に向けて、どの指標について答えるのかが明確であるほど、エージェントの答えを検証しやすくなります。 なお、Snowflakeは2026年8月に、Cortex Analystからエージェントの機能であるCortex Agentsへの移行を推奨すると発表しています（ Snowflake Docs, 2026年8月 ）。自然言語での問い合わせから、エージェントによる分析へと、製品の重心が移りつつあることがうかがえます。 データ分析にAIエージェントを使う3つのアプローチ：機能と前提の違い エージェントを分析に使うアプローチは、大きく3つに分けられます。いまの製品の多くはAIが人を手伝う形で使われていますが、エージェントが自ら分析する形へと機能を広げつつあると、dotDataは見ています。どのアプローチを選んでも、データ分析エージェントの答えの正しさを左右するのは、エージェントに与えるデータとコンテキスト（文脈）の質です。 アプローチ 代表例 得意なこと 前提・制約 汎用エージェント・コーディングエージェント ChatGPT、Claude、Gemini／Claude Code、OpenAI Codex、Cursor 柔軟に使え、PythonやSQLで分析用のコードも書ける 自社データの意味は知らない。成果が使う人のスキルに左右される データ基盤連動型 Databricks Genie、Snowflake Intelligence 基盤上のデータに直接アクセスでき、権限管理の下で使える 正しさは、基盤上に整備された定義の充実度に左右される 業務・分析アプリ Salesforce Agentforceなど業務アプリと連携するエージェント、特定目的の分析エージェント 特定の業務や目的に合わせて作り込まれている 対象とする範囲が限られる ツールの選び方は、本記事末尾のFAQで整理しています。いずれのアプローチでも、エージェントが自社データの意味を理解していなければ、正しい答えは返りません。この点が、次に述べる「期待と現実」のギャップにつながります。 期待と現実：AIエージェントのデータ分析は、なぜ自社データで精度が落ちるのか 自社データで精度が落ちる主な要因は、次の4つです。 図：AIエージェントの期待と現実（出典：dotData Webinar資料「AI Agentの価値は、データで決まる」（2026年12月）より、一部改変） 定義のずれ ：「売上」や「解約」の定義が、人とエージェントで食い違う 探索のコスト ：テーブルや文書が多すぎて、エージェントが必要な情報を探しきれない もっともらしい誤答 ：誤った答えでも説得力があり、使う側が誤りに気づけない 評価の手段がない ：出力の正しさを継続的に測っていないため、誤りが放置される こうしたリスクを放置したまま進めると、プロジェクトそのものが続かなくなるおそれがあります。Gartnerは、エージェント型AIプロジェクトの40%超が、コストの高騰、ビジネス価値の不明確さ、リスク管理の不備により、2027年末までに中止されると予測しています（ Gartner, 2025年6月 ）。 期待：デモとベンチマークでは高い正答率 dotDataも参加した2026年6月のData + AI Summit 2026をはじめ、データ基盤ベンダーのカンファレンスでは、AIエージェントが分析を次々にこなす華やかなデモが披露されます。学術的なベンチマークでも高い数字が並びます。自然言語の質問をSQLに変換するText-to-SQLの代表的なベンチマーク「Spider 1.0」では、2023年時点で実行精度91.2%が報告されています（ Spider ）。 現実：自社データでは誤答が増える 一方、実際の企業のデータベースを模したベンチマーク「Spider 2.0」の論文（2024年11月公開、ICLR 2025採択）では、当時のo1-previewを使ったエージェントでも、解けたタスクは21.3%にとどまりました（ Lei et al., 2024 ）。同じ論文は、Spider 1.0では91.2%、BIRDでは73.0%だったと比較しています。 その後、Spider 2.0のリーダーボード（Snowflake環境版のSpider 2.0-Snow）では、スキーマの理解や文脈の与え方を作り込んだエージェントシステムが、90%台のスコアを報告しています（自己申告の値）（ Spider 2.0 ）。LLMを単体で使うか、文脈を作り込むかで、成績が大きく変わることを示唆しています。 ベンチマークと実務の差を生むのは、実際のデータが持つ次のような特徴です。 規模が大きい ：テーブルが数千から数万に及ぶ 名前が曖昧 ：列名やコードだけでは、何を表すデータか分からない 定義が会社固有 ：「売上」や「解約」の数え方が、会社や部門ごとに違う なぜ計算は正しいのに、答えが違うのか：指標の定義のずれ 計算が正しくても答えが違ってしまうのは、人とエージェントが同じ言葉を別の定義で使っているからです。自社データでの誤答のうち、特に気づきにくいのがこのケースです。 たとえば「来月解約しそうな顧客は？」と尋ねたとします。「解約」には、次のように複数の定義がありえます。 解約手続きをした顧客だけを数える（ハードな解約） 利用率が大きく下がった顧客も含める（ソフトチャーン） 製品やサービスごとに、別の基準で数える 人とエージェントが別々の「解約」を思い浮かべたまま分析が進むと、計算自体は正しくても、問いとは違う答えが返ってきます。しかもその答えはもっともらしく見えるため、使う側は誤りに気づけません。 この誤りは、プロンプト（エージェントへの指示文）を工夫するだけでは防ぎきれません。指示がどれほど丁寧でも、指標の定義や業務の文脈がエージェントに共有されていなければ、エージェントは自分なりの解釈で計算を進めてしまうからです。この問題は、 AI-Ready Dataとは で詳しく解説します。 探索のコスト：どこを見ればよいか分からない データが大規模になると、エージェントは必要なデータや文書を探すだけで時間とコストを使います。DatabricksのAli Ghodsi CEOは、2026年6月のData + AI Summit 2026の基調講演で、エージェントがどこを探せばよいか分からないまま、その場で探し回るため、答えが返るまでに10〜15分かかることがあると指摘しました（ Databricks ）。 精度を決めるのはモデルではなく、データとコンテキスト 最新の大規模言語モデル（LLM）は、一般的なタスクをこなすうえで十分な推論力を備えていると、dotDataは考えています。自社データで誤答が増える主な原因は、モデルではなく、エージェントが参照する入力の側にあります。 コンテキストを与えると、正答率は大きく変わる データ基盤ベンダーの検証でも、この傾向が示されています。Snowflakeは、自社のプロダクト分析に関する58問の社内ベンチマークの結果を公表しています。業務のコンテキストを持たないまま、Snowflake MCP経由でデータにアクセスしたエージェント（Claude Code）の正答率は24.1%でした。MCPは、AIエージェントを外部のデータやツールと連携させるための標準規格で、Snowflake MCPはそのSnowflake用の接続口です。これに対し、コンテキストを与える機能（Cortex Sense）を使ったSnowflakeのエージェントでは86.3%でした（ Snowflake, 2026年6月 、 Snowflake Engineering Blog, 2026年8月 ）。ベンダー自身による測定で、比較したエージェントの構成も異なるため、単純な比較ではありません。それでも、コンテキストの有無で正答率が大きく変わりうることを示す例です。 Snowflakeは2026年6月のSnowflake Summit 26の基調講演でも、差別化の源泉はAIモデルではなく自社のデータにある、というメッセージを打ち出しています（ Snowflake Summit 26 Keynote ）。 調査会社も「データ」を課題に挙げる 調査会社も同様の見方を示しています。 Gartner ：AI-Readyなデータに支えられていないAIプロジェクトの60%が、2026年までに放棄されると予測しています。同社の調査では、63%の組織が「AIに適したデータ管理の実践を持っていない、または持っているか分からない」と回答しました（ Gartner, 2025年2月 ）。 Forrester ：生成AIの導入において「いま直面する主な制約要因は、自社のデータ品質である」と指摘しています（ Forrester, 2024年2月 ）。 BI・機械学習の時代と同じ構図：違いは「意味」が問われること 新しい技術が登場するたびに、同じことが起きてきました。BIの時代も機械学習の時代も、最初はツールやモデルに注目が集まりました。しかし、その性能が一定の水準に達すると、成否を分けるのは入力データの整備になりました。 AIエージェントの時代も同じ構図です。ただし、今回はデータをきれいに整えるだけでは足りません。エージェントがデータの「意味」を理解できるようにする必要があります。これが、近年注目されている「AI-Ready Data」という考え方です。詳しくは AI-Ready Dataとは で解説します。 AIエージェントによるデータ分析の導入は、どのように設計し、進めればよいか 導入は、LLMを選ぶ前に、対象業務、データの意味、人の関与、評価の方法を順に整えることから始めます。次の4つのステップで進めることを、dotDataは推奨します。 ステップ1：エージェントに任せる定型分析を洗い出す 経営KPIの要因分析や定例レポートのように、繰り返し発生し、指標の定義がはっきりしている分析から始めます。対象が明確であるほど、答えの検証もしやすくなります。 ステップ2：データの「意味の層」を整える 指標の計算方法、用語の定義、業務の文脈を、エージェントが参照できる形で整備します。これは人が読むドキュメントとは別に、エージェントが実行時に使う定義です（→ AI-Ready Dataとは ）。 ステップ3：Human-in-the-Loopを設計する エージェントが推論を何段も重ねると、小さな誤差が蓄積し、分析が誤った方向に進むことがあります。分析プロセスの重要な段階で人が文脈を補い、方向を修正するプロセスを組み込みます。 ステップ4：出力を評価する体制を作る エージェントの出力が正しいかどうかを継続的に測ることが、改善の出発点になります。LLMに評価させる「LLM as a Judge」は、その有力な手段です（→ AIがAIを評価するとは？LLM as a Judgeの基礎 、 AIエージェント開発でのLLM as a Judgeの運用知見 ）。 1つの定型分析でこの4ステップを回し、正しさを確かめてから、対象とする分析テーマを組織全体に広げていくのが現実的な進め方です。 dotDataの取り組み：データからの知識をエージェントに与える dotDataは、データの中にあるパターンである「特徴量」を、AIエージェントが使える定量的な根拠として提供することに取り組んでいます。特徴量とは、分析の目的に関係するデータ上のパターンです。たとえば、ローンを利用しそうな顧客に共通する行動パターンなどが、これにあたります。 AIエージェントが自社の分析で正しい答えを出すには、LLMが持つ世界知識や、文書に書かれたドメイン知識に加えて、自社のデータからしか得られない「データからの知識」が必要です。dotDataは、特徴量自動設計の技術によって、目的ごとに数多くのパターンをデータから網羅的に探索し、エージェントが使える形で提供する取り組みを、顧客とともに進めています。この考え方は、 AIエージェント時代のデータマート で詳しく解説します。 特徴量と生成AIを活用したビジネスアナリティクスについては、 dotData Insight をご覧ください。 まとめ AIエージェントによるデータ分析は、データ基盤、意味の層、エージェント、人の確認と評価の4つがそろって初めて、実務で使える水準になります。現在はAIが人の分析を手伝う段階にあり、今後1〜3年でエージェントが自ら分析する段階へ進んでいくと、dotDataは見ています。 自社データでAIエージェントの精度が出ない主な原因は、モデルではありません。定義のずれ、探索のコスト、評価の欠如など、エージェントに与えるデータとその意味の側にあります。 導入は、定型分析の洗い出し、意味の層の整備、Human-in-the-Loopの設計、評価の体制づくりの4ステップで進めます。 データの「意味」をどう整えるかは AI-Ready Dataとは で、エージェントに定量的な根拠を与える方法は AIエージェント時代のデータマート で解説しています。 The post AIエージェントを活用したデータ分析の現在地 ― 自社データで精度が出ない本当の理由 appeared first on dotData .