はじめに サプライチェーンリスク管理クラウドサービスResilireでエンジニアをしている奥村 @arashigaoka3です。 最近このxを拝見し、これをきっかけとしてHacker Newsのスレッドを見て、おもしろい内容だなと感じました。 Resilireではsqlcを採用しており、現状と今後の把握は非常に重要です。この記事では、sqlcで採用されているbuilt-in analyzerとdatabase-backed analyzerについて説明します。 built-in analyzer の狙いとメリット 私がsqlcに感じているメリットとして、SQLからコード生成する際、通信をしない点が素晴らしいなと思っています。これによって安定して高速な開発体験が可能になっていると感じています。 これはsqlcに内蔵されたbuilt-in analyzerが実現しています。すなわち、sqlcで
はじめに はじめまして、テクノロジー戦略室室長の竹下です。現在、AI推進室として活動しており、今回こちらのブログにお邪魔して書かせてもらいました。Leverages Tech Blogでもいろいろ書いているので、そちらもぜひ見てください！ 業務上、アンケートの分析だったり、そこからの示唆の分析などを行うことも多々あるのですが、そんな時に最近はDuckDBを利用しています。この記事では、DuckDB + DuckDB MCP + VSCode copilotを利用した自然言語で分析を手軽にできる環境のご紹介をしたいと思います。 DuckDBとは DuckDBとは、ローカル、シングルノードで動作する、高性能な分析データベースシステム(列指向DB)です。 標準SQLに加えて、分析用の関数を豊富にサポート csv,json,parquetなど豊富な形式のimportが可能 CLI mode, no
夏の自由研究2025ブログ連載の3日目です。 こんにちは！Energy Transformation Groupの大前七奈です。 dbtは、データエンジニアリングの現場に革新をもたらしましたが、プロジェクトが大規模になるにつれて、いくつかの課題も浮き彫りになってきました。 本記事では、その課題を解決するために開発された次世代のエンジン「dbt Fusion Engine」について、実際に試してみた所感を交えながら、その凄さや移行方法、そして今後の展望について詳しくお話ししたいと思います。 改めてdbtすごいところdbt（Data Build Tool）は、データエンジニアリング界隈に革命をもたらしたELT（Extract, Load, Transform）ツールです。Gitバージョン管理システムで、SQLでデータ変換を管理でき、さらにデータ変換のステップを複数の小さなSQLファイルに分割し
はじめに toB向けの0->1のGoのバックエンドAPIの開発でsqlcを採用しました。 使い始めてから1年半くらい経ったので感想を書いてみようと思います。他の人のブログでよく言及されている点については同じことを書くことになるので書きません。 使っていたsqlcのバージョンは1.18~1.26です。 sqlcを採用した理由 sqlcに限らずバックエンドAPIの開発の技術選定をする上で技術的な要件は無かったです。開発効率や開発速度を高めることができる技術選定を求められていました。 バックエンドAPIの開発のリードエンジニアは私だったので、私が使い慣れているツールをなるべく使い、技術検証や使い方を調べる時間を極力減らし開発効率と開発速度を上げようとしていました。ただ、全て私が知っているツールだと私の開発のモチベーションが上がらなかったので、Product Ownerに相談してORMのみ使ったこ
はじめに GritQL を知ったのは去年 Biomeのプラグインに関するRFC に少し目お通した時に、GritQL の提案があったのがきっかけだったと思います。Biome のドキュメントには現在 GritQL [実験的機能] として載っています。そして、少し前のポスト Roadmap 2025 and Biome 2.0 で以下のような記述がありました。 プラグイン 2024年1月に始まったRFCプロセスを経て、Biomeプラグインの開発が始まった。Biome 2.0では、その最初の成果が搭載される： ユーザーはGritQLを使って独自のリントルールを作成できるようになる。 そこで以前 GritQL について軽く調べたんですが完全に忘れているので再度キャッチアップし直してみました。 GritQLとは？ GritQL はソースコードの検索と修正のために設計されたクエリ言語で、ざっと以下のよう
概要 kuqu は Kubernetes クラスタ内のリソースに対して SQL 構文でクエリを実行できる Rust 製のコマンドラインツールです。Apache DataFusion を活用し、動的スキーマ推論によって Kubernetes リソースをテーブルデータとして扱い、複雑な条件検索、集約、結合操作を SQL で実行します。 以下に、実行例を示します。 $ kuqu "SELECT metadata.name AS pod, status.phase AS phase FROM 'pod/kube-system' WHERE status.phase = 'Running'" +--------------------------------------------+---------+ | pod | phase | +-------------------------------
本記事では、2025年6月にパブリックプレビューが開始となったSnowflake Cortex AISQLのチュートリアルを通じて、Snowflakeの新しいSQL関数の性能について紹介します。 Snowflake Cortex AISQLとは Cortex AISQL関数 チュートリアル 前提条件 セットアップ setup.sql images.sql Cortex AISQL実行 AI_COMPLETE AI_FILTER AI_AGG AI_CLASSIFY おわりに Snowflake Cortex AISQLとは Snowflake Cortex AISQL（以下、Cortex AISQL）とは、Snowflake上でのSQLの様式にAIを組み込んだ、新しいSQLの機能群を指します。 こちらの機能を使うと、画像や図表などのマルチモーダルなデータ(非構造化データ)に対して、複雑なコ
Gemini Code Assist に DDL をレビューさせてみました。 レビューさせるDDL CREATE TABLE users (id int, user_name TEXT, create datetime); CREATE TABLE user_items (id int, user_id VARCHAR(10), itemName TEXT, status VARCHAR(250), created datetime); 以下のような問題点を意図的に仕込みました。はたして、Gemini Code Assist はうまく指摘してくれるのでしょうか？ Primary Key が指定されていない user_name の NOT NULL の指定漏れ 予約語 create が使用されてしまっている users の id と user_items の user_id の型の不一致 u
BigQuery StudioではGeminiを使用してSQLの生成をやってくれますが、 コンソールは、今どのプロジェクトやデータセットを見ているか、テーブルのスキーマ（カラム名、データ型など）がどうなっているかを自動的に理解してくれています。 これと似たようなことを外からでもできたら便利かもと思い、n8nのフローを使って構築できないか試してみました。 フロー全体図 チャットのメッセージを起点にし動作するフローになっています。 ※ 本記事での対象のテーブルは一つとしています。 ※ Chatモデルはgemini-2.5-flashを使用しています 一つのエージェントに全て任せるようにするとプロンプトが長くなりそう、多くて複雑な指示によりAIがどのフェーズにいて、どの指示に従うべきかを正しく判断できなくなってしまうことを考慮し、2つのエージェント（生成担当、実行・報告担当）に分けてみました。
ナレッジベースの構造化データ取得機能 AWS re:Invent 2024 で発表されたナレッジベースの新機能です。本記事では re:Invent のブレイクアウトセッション の内容を元に、Text2SQL の精度を向上させるためにナレッジベースがどんな仕組みで動いているのか、ユーザー側でどのようなカスタイマイズオプションがあるのかを掘り下げます。 本機能では自然言語から SQL を生成し、対応するクエリエンジン経由でデータを取得、LLM が結果をまとめて応答します。ざっくりいうとデータベースに格納されている構造化データに対する RAG をマネージドで実現する機能です。 Preview 時点でクエリエンジンは Amazon Redshift のみサポートしています。Redshift 上のデータの他、Glue Data Catalog との統合にも対応しており、SageMaker Lakeh
こんにちは。LINEヤフー株式会社ビジネスPF開発本部で LINE DMP の開発を担当している yamaguchi です。 この記事は、Testcontainers を活用して Apache Kyuubi を用いたユニットテスト環境をどのように構築したかを紹介します。 はじめに LINE DMP（Data Management Platform）は LINE 外部から同意を得てアップロードされた、あるいは LINE の内部で得られたデータをさまざまな形で ETL 処理をし、LINE広告やLINE公式アカウントのような B2B サービスで活用できるようにするためのプロダクトです。 膨大な累積データや非常に大きなトラフィックを扱うこともあり、リアルタイム処理から大規模バッチ処理までさまざまな LINE にまつわるデータ処理を行っています。 プロジェクトの背景 大規模データを取り扱うにあたり、
はじめに こんにちは、スタンバイでプロダクト企画をしている荒巻です。 スタンバイでは、日々サービスを改善するために様々な技術的挑戦をしています。今回はその中でも、求人データ保管・配信システムの刷新プロジェクトに伴って発生した大きな課題に対し、課題分析から要件定義、そして生成AIの力を借りて「自分で作ってみよう！」と思い立ち、社内ツール開発に至った経緯とそのプロセスをご紹介します。 開発したのは「SQL Converter」という、既存のSQLクエリを新しいデータ構造に合わせて自動変換するツールです。最大で約1200件ものクエリ書き換え作業を効率化するために、AI Co-Pilot（GitHub Copilot / Google Gemini）とAWS Bedrock (Claude) を活用しました。 この記事は、以下のような方に特におすすめです。 AI/LLMを活用した開発や業務効率化に
「1000人以上の組織で働く人々が最も使いたいと考えているインフラツールとその理由は何ですか？」 あなたがチャットアプリの開発者だとして、この質問にどう返すように設計しますか？ 単にOpenAIのAPIに質問を送った場合、APIは広大なネットの海から関連しそうな記事を取ってきて返答してくれます。 しかしその記事は本当に正しいのでしょうか。 関連しそうな記事がない場合は？ 「1000人以上の組織で働く人々が最も使いたいインフラツール」というコンテキストがあるので、ソースとなるドキュメントからSQLを実行したいですよね。 Text-To-SQLはクエリをSQLに変換する技術です。 回答の根拠が見えることやハルシネーションが起きないことなどメリットがありますが、反面テーブル名やカラム名、データを直接指す質問ばかりとは限らない(リンク先は課題の詳細)などの課題もあります。 またデータベースのカラム
はじめに シロクは「N organic」や「FAS」などのブランドを展開する化粧品会社です。顧客体験の向上とマーケティング効果の最大化のために、日々多様なデータが活用されています。 各ブランドの成長に伴い、データに基づく意思決定の重要性が増しており、複数の事業部からデータチームへのレポート作成や分析依頼が増加しています。その一方で、以下のような課題が顕在化してきています。 分析依頼の増加によるリソースの低下 類似の分析やアウトプットの増加 AI活用による効率化ニーズが高まり クエリの誤用によるリスクの拡大 ゴール Slackで分析依頼を投げるだけで、Snowflake側でSQLを生成・実行し、結果をSlack上に返すプラットフォームを構築することで、これらの課題を解決を試みました。 これにより、Snowflakeにアクセスできない人でも、簡単にかつ正確な分析を提供することを実現できると考え
はじめに 「GISエンジニア」というデカい主語で始まった本記事。最近話題のDuckDBですが、GISデータを扱うのに非常に有用で、今までGeoPandasやPostGISでやっていたような処理を、CLIで・最小の環境構築で・高速に実行できます。本記事では、GISデータのプロセッシングという観点で、使い方を紹介します。 DuckDBとは何か 正確な定義については私は間違えそうなので公式Webサイトなどをご覧いただくとして。 「DBというくらいだから、データベースなんでしょ？」正解です。しかしPostgreSQLなどのようなある種「重厚な」DBソフトウェアとはちょっと違います。PostgreSQLでいうとpsqlクライアントだけが利用出来るようなイメージです（厳密には永続的なデータベースも作成は出来るが）。 私の理解では、DuckDBは「DBクライアント」であり「CLIツール」です。DuckD
モチベーション 先日、GitHub で公開されている BigQuery 連携ツール mcp-bigquery-server を試用しました。 触ってみた第一印象としては、非常にポテンシャルを感じるツールでした。 一方で、特に分析用 SQL の自動生成のようなユースケースにおいては、事前の準備、すなわち「前提を揃える」ことの重要性を再認識しました。 テーブル構造、カラムの意味、データの状態などをツール側が正確に理解できるような情報を提供しなければ、意図した通りの SQL を生成させることは難しいという印象です。 このあたりは、プロンプトエンジニアリングやメタデータの整備が鍵になりそうです。 そんな中、Google から Agent Development Kit (ADK) と MCP Toolbox for Databases (genai-toolbox) という、生成AIアプリケーショ
最近 Model Context Protocol (以下 MCP) が流行っているので、個人的に親しんでいる Spanner のクエリ最適化を MCP を使ってできないかを試みてみた話をします。 MCP そのものについての説明はいくらでも見つかるので省略します。 AI によるクエリ最適化の課題 生成 AI に SQL クエリを書かせる時に問題になることとして、生成 AI はオプティマイザではないのでクエリがどう実行されるのかを知らないということがあげられます。 結果として、生成 AI が改善したと主張するクエリを人が確かめてがっかりすることを繰り返すようなことが起きてしまいます。 これは AI エージェントが実行計画を自分で取得して解釈し、クエリとスキーマの改善とフィードバックループを回していけるようになれば解決するのではないかと考えられます。 どのように実行計画を取得するか？そう、一つ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
