S3 TablesのIcebergデータに、 AIエージェントからアクセスしてみた 2026/10/16 (金) DevelopersIO 2026 Joetsu 笠原 宏 

自己紹介 笠原 宏 (@kasacchiful) クラスメソッド株式会社 データ事業本部 ビジネスソリューション部 ソリューションアーキテクト 新潟県新潟市在住 JAWS-UG新潟 / Python機械学習勉強会 in 新潟 / JaSST Niigata / ASTER / SWANII / Cloudflare Meetup Niigata / AI CRAFT Hacks Niigata / KomeKaigi AWS Community Builder (Serverless) 2022, 2025 Japan AWS Top Engineer / 2022-2026 Japan All AWS Certifications Engineer AWS Samurai 2025 2 

去年のDevelopersIO 2025 Tokyoにて DevelopersIO 2025 Tokyo テーブル定義書（Excel）から、生成AIで DWH分析を試した やったこと Excel → PDF → CREATE TABLE 文（カラム コメント付き）を生成 その CREATE TABLE をプロンプトに貼っ て、SQLを生成 題材は今年も同じ、IoTセンサーのデータ 「東京オフィス3の2024年Q2の平均気温と 平均湿度」 https://dev.classmethod.jp/articles/extracting-structured-data-from-table-definition-documentsusing-generative-ai-developersio-2025-tokyo/ 3 

去年は、手動でやる部分が多かった 手順 ① テーブル定義抽出 ② テーブル定義貼付 ③ SQL生成 ④ SQLコピペ ⑤ 実行・可視化 CREATE TABLE 去年 ExcelファイルをPDF化して読み込ませ、 CREATE TABLE を作成 作成された CREATE TABLE をプロンプトに貼る CREATE TABLE を元にデータ分析用SQLクエリを生成 生成されたSQLを確認してコピー Athena等でクエリ実行、結果をグラフ化 誰がやる？ AI 自分 AI 自分 自分 の作成と、分析用SQLの作成以外は、手動でやる部分が多かった 4 

やりたいこと Slackで聞くだけ。あとはAIエージェントにおまかせ。 テーブルの探索 SQLの作成・実行 グラフの作成 全部エージェント側でやって、Slackのスレッドに返してほしい 5 

構成 ①「考え中...」を書込 への応答 Slack Event API Slack API Gateway Lambda (receiver) SQS FIFO Queue Lambda (worker) ② 結果を書込 ③ がファイルを取得し、 でSlackのスレッドに worker file_upload_v2 S3 グラフ画像を アップロード Strands Agents (ARM64 AgentCore Runtime S3 Tables MCP Server describe_table run_python 会話履歴の 読み書き AgentCore Memory 分析結果を元に描画⽤コ ードを⽣成して、送る 読み取り S3 Tables コンテナ) 結果を返す ファイル含む) Code Interpreter サンドボックス環境 (PNG 6 

構成の要点 Slackの3秒制限対策 SQSでの非同期化は必須 receiver用Lambdaが署名を検証してSlackにすぐ応答を返し、SQSへ SQSからworker用Lambdaが起動し、「考え中...」を送ってからエージェントで処理 セッションはスレッド単位、actorはチャンネル単位 同じスレッドで誰が聞いても、文脈を共有できる グラフはS3経由で返す PNGが100〜250KBあり、base64化すると SQS/Lambda のサイズ制限に当たりやすい MCPサーバはコンテナに同梱（stdio） まずはシンプルに 複数エージェントにも共有したくなったらAgentCore Gatewayへ 7 

検証の前提 データ S3 Tablesに、IoTセンサーのデータをIcebergで格納 (サンプルデータを生成) センサー情報 15件 / 時系列データ 約6.6万件 比較用に カラムコメントあり / なしの2セット分のテーブル Namespaceで分けて、テーブル名を統一 基盤モデル Claude Sonnet 4.6（Bedrock、東京リージョン） Sonnet 5.5 は、私のAWSアカウントで使えなかった (AWSサポート問合せ中) 今回の数字は4.6のもの。5.5で変わる可能性あり 計測値は、Slackの回答の末尾に出力（秒・トークン・SQL件数） 8 

カラム定義 各カラムのコメントにメタデータを仕込む 9 

サンプルデータ生成 いい感じに、Claude Codeに作ってもらった 10 

デモ 

デモ: Slackで3問 1. @iot-agent どんなデータが入ってる？ 2. @iot-agent 東京オフィス3の2024年Q2の平均気温と平均湿度は？ 3. @iot-agent その推移をグラフで ポイント プロンプトにテーブル定義を貼り付ける必要はないです 3問目は「その」で前の質問を参照してます（AgentCore Memory利用） 12 

Q1: どんなデータが入ってる？ バケット → 名前空間 → テーブルと探索 テーブルの情報を取得して表示 ts は「UTC」と明言 カラムコメントに記載している内容 13 

Q2: 東京オフィス3の2024年Q2の平均気温と平均湿度は？ 14 

Q3: その推移をグラフで 15 

Q3: 生成されたグラフ 16 

デモの計測値 # 質問 秒 in / out tokens 1 どんなデータが入ってる？ 17.6 47,891 / 1,343 2 平均気温と平均湿度は？ 12.2 43,531 / 1,038 3 その推移をグラフで 34.2 72,872 / 4,006 3問とも1回の質問で結果応答が返る（SQLの実行は各2本） 初回のコールドスタートは約20秒（Runtime検証時） 17 

やってみて分かったこと 

① MCP Server がカラムコメントを返さない S3 Tables MCP Server スキーマやコメントを返すツールがない DESCRIBE で返るのは、カラム名と型だけ Icebergにコメントを付けても、MCP経由ではエージェントに届かない 実行のたびに、タイムスタンプカラムの UTC / JST の判断が変わる 今回はカラムコメントも取得するために describe_table ツールを作成 PyIcebergでコメントを取得 19 

② コメントがあると、速くて正確 同じ3問を、コメントあり / なしで比較（Sonnet 4.6、実行3回） コメントあり 3問合計の時間 56秒 入力 tokens 15.6万 タイムゾーン UTC コメントなし 158秒 25.5万 「不明」 コメントなしは、データの中身を確かめるクエリが増える模様 コメントなしの別の回では、「JSTと推定」と誤答（実行ごとに変わる） 去年のテーマだった「カラムコメントの整備」は、エージェントでも効く 20 

③ SQLエンジン（Daft）の癖にハマる 今回利用したMCPサーバのツール query_database が利用するSQLエンジンはDaft。 ts >= 2024-04-01 で以下のように振る舞いが異なる。 書き方 ts >= '2024-04-01T00:00:00' ts >= TIMESTAMP '2024-04-01 00:00:00' ts >= CAST('2024-04-01 00:00:00' AS TIMESTAMP) ts >= to_date('2024-04-01', '%Y-%m-%d') 結果 エラー（型が合わない） エラー エラーなしで0件（正しくは49,500件） OK 他にも month() + ORDER BY でエラー、 date_trunc は無い 方言のルールを「システムプロンプトに追記」して対応 21 

④ Code Interpreterで日本語が文字化け Code Interpreterとは、AgentCore Runtimeのプロセスとは別に用意されたサンドボックス環 境 グラフの描画は、AgentCore Runtimeから呼び出して、Code Interpreter上で実行 (Amazon Linux 2023 / Python 3.12 / matplotlib 利用) グラフの日本語が文字化け (主に □（豆腐）) AgentCore Runtimeのサンドボックスは外部ネットワーク不可 後からフォント追加はできない 入っているフォントを使うように、セッション開始時に設定 すると今度は、エージェントが「フォント設定を上書き」 入っていた別の欧文専用フォントを探して設定上書き 「℃」の文字が消える事象発生 run_python (独自ツール) の docstring に「フォント設定は触らない」と明記 Code Interpreter呼び出しラッパー 22 

⑤ ローカルで動くが、コンテナで動かない 症状 Runtimeの初回呼び出しが 500 エラー ログには Connection closed だけ 原因 mcp のバージョン衝突 S3 Tables MCP Server mcp 1.x の依存、上限指定なし 新しく入れると mcp 2.x そのため起動できない ローカルで動いたのは、利用していた「uvxのキャッシュ」がたまたま効いていた 対策 MCP Serverを別環境に入れて、 mcp<2 と 0.0.10 を固定 23 

⑥ 色々修正した結果: 266秒 → 44秒 コメントあり、同じ3問の合計 最初（実行1） 所要時間 266秒 入力トークン 40.1万 SQLエラー 6回 グラフ 日本語が豆腐 対策後（実行5） 44秒 11.0万 1回 正常 基盤モデルよりも、「ツール」と「プロンプト」の整備が大事 24 

まとめ S3 TablesのIcebergデータに、AIエージェントからアクセスしてみました Slackから質問を投げるだけで、分析結果が返ってくる Slackに置くと、分析できる人が増える SQLを書けない人も、同じスレッドで聞ける メタデータは大事。エージェントにうまく届けないといけない。 コメントを付けるだけでは、MCP Serverは返さなかったので、自作ツールで対応 エージェントに任せきりにはできない 動作の癖・フォント・依存等は、ツールとプロンプトで対応 25 

次にやるなら 「AgentCore Gateway」でMCPを共有 複数エージェントで使い回すなら、コンテナ同梱から切り出す Sonnet 5.5 で再計測 今回は4.6。精度・速度がどう変わるか 質問の自由度を上げる 今回は決まった3問。もっと曖昧な質問でどうなるか Context Ontology Accelerator (COA) の利用 業務データやドキュメントからオントロジーを自動生成して、AIエージェントにコンテキス トを提供する オントロジー: 特定の領域における概念やその関係性を、コンピュータが理解・推論でき る形で記述するもの AWSがオープンソース (Apache 2.0) で公開 26 

宣伝 

KomeKaigi 2026 28 

No content