【徹底解説】BigQuery「Conversational Analytics」登場！既存のAI分析ツールと何が違うのか？
BigQueryのDataAgentの１つである、「Conversational Analytics」がpublic previewとして登場しました！ (日本語ドキュメントでは現在（2026年2月時点）も『早期アクセス』という表記になっていますが、パブリックプレビューとして利用可能です) 今回の記事では Conversational Analyticsでは何が出来るのか？既存のAIとの差分はどういうものなのかを紹介していきます。 1. はじめに：なぜ今、対話型分析なのか？ 「データを民主化したい」 多くの企業が掲げる目標ですが、現実は甘くありません。現場の担当者がデータにたどり着くには、SQLを習得するか、忙しいデータアナリストに依頼して数日待つ必要があります。 これまでも「自然言語でSQLを書くAI」は存在しました。しかし、実際に業務で使おうとすると、社内独自の専門用語や複雑な集計ルー
Databricks 宣言型特徴量エンジニアリング入門: オフライン経路で動かして理解する - Qiita
はじめに Databricks の Feature Store に「宣言型特徴量エンジニアリング (Declarative Feature Engineering)」という API が追加されました (本記事執筆時点ではベータ)。集計ロジックを自分で書かずに、特徴量の「定義」だけを宣言すると、計算・時点結合・テーブル化までをプラットフォームが引き受けてくれる仕組みです。 公式の宣言的な特徴のクイックスタートを動かそうとしたところ、オンラインストアの作成でつまずきました。オンラインストアは Lakebase を前提とするため、今回は「宣言型特徴量とは何か」を理解することを目的に、オンライン機能を使わないオフライン経路だけで一通り動かすことにしました。 その過程で複数のエラーを踏みましたが、どれも宣言型特徴量の設計思想を理解するうえで示唆的なものでした。本記事では次の3点をまとめます。 そもそ
DSPyの入門 ①
はじめに プロンプトの自動最適化の方法として、DSPyが話題になっていたので入門してみました。 最適化の主要コンポーネントのオプティマイザは、ボリュームが大きいので別でまとめます。 DSPyとは DSPy (Declarative Self-improving Language Programs) は、大規模言語モデル（LLM）を用いたアプリケーションのプロンプトや重みを、アルゴリズムによって自動的に最適化するためのフレームワークです。 スタンフォード大学の研究者らによって開発され、従来の「手動でのプロンプトエンジニアリング」を「プログラマブルなシステム構築」へと進化させることを目的としています。 1. プロンプトから宣言的なプログラミングへ 従来のLLM開発では、特定のモデル（例：GPT-4）に合わせて「プロンプトの文字列」を微調整する作業が中心でした。しかし、モデルを変更したりデータを
機械学習プロジェクトを「迷子」にさせないための個人的な教訓をつらつらと書いてみた - 虎の穴ラボ技術ブログ
こんにちは。 虎の穴ラボ株式会社の iwady です。 皆さん、Python してますか？ 今回は Python に直接関連するお話ではないのですが、 私がこれまで開発メンバーおよびマネージャーとして携わってきた「機械学習プロジェクト」について振り返ってみたいと思います。 プロジェクト全体の流れや、私個人が現場で感じた「注意すべき点」を、開発とマネジメント両方の視点からお話しします。 1. 機械学習プロジェクトとは 本記事では、「データを用いて自動で学習を行い、そのデータの特徴やパターンを活用したシステムを開発する案件」を機械学習プロジェクトと定義します。 具体的には、既存のデータから協調フィルタリングを用いて商品をおすすめしたり、画像から関連キーワードを予測したりといった機能です。 従来の明示的なルールベースや SQL、正規表現、単純な自動化だけでは実現が困難な課題を、データの力で解決す
ディップ 開発組織LT会｜AIエージェント、DDD、データ基盤を追求するLTレポート🚀
こんにちは！ディップ株式会社のDevRelです。 今回はディップのエンジニア、開発本部で隔週開催されている社内LT会の様子をレポートします。 ディップの開発組織では、知見の共有や外部登壇の練習などを目的に、組織全体でのLT会を隔週で行っています。今回のテーマはDDD（ドメイン駆動設計）、データ基盤、AIエージェント、コーディング規約など、非常に多岐にわたりました。 技術を楽しみ、常に一歩先を模索するメンバーたちの熱いLTを紹介します！🔥 今回からハイブリッド開催です🙌🏻 1. なぜ今私たちは DDD に向き合うのか 佐藤 薫さん(23年新卒入社) 新規プロジェクトに関わる佐藤さん。実務でのDDD実践について語りました。 開発の目的は、ビジネス言語をそのままコードに反映させ、ドメイン知識の断絶を防ぐことで、仮説検証のサイクルを早める強いプロダクトを作ること。手法として、イベントストーミ
個人開発のアイデアはもう枯渇している？競合だらけの市場で生き残るために考えていること
はじめに 自分はこれまでChrome拡張機能を中心に、14個ほどのプロダクトを開発・公開してきた。 その中で改めて感じていることがある。アイデアを見つけるのが本当に難しいということだ。 「誰も思いついていないアイデア」はもう存在しない おそらく、今ネット上には考えうるほぼすべてのアイデアが、すでに誰かの手で実装されている。もし存在していないとすれば、それは何かしらのリスクがあったり、技術的に困難な部分があるから開発されていないだけであって、「誰も思いついていないから作られていない」というケースはほとんどないと思っている。 たとえば自分がShorts KillerやX Detoxを作ったとき、「SNSのアルゴリズムを無効化したい」というニーズ自体はすでに顕在化していて、同じコンセプトの拡張機能はいくつも存在していた。Arbitraや楽天セラーズ・アナリティクスのようなEC系ツールも同様で、価
dbt の models のディレクトリ構成検討
概要 本記事にて dbt の models 配下のディレクトリ構成案を検討します。 前提 下記のデータアーキテクチャを前提として、 Enriched 以降と Development （Sandbox）を dbt で管理することを前提としています。 出所: https://qiita.com/manabian/items/57373e833df5b4f65184 models/ ├── m010_sources/ ... Source 定義。取り込み対象の宣言を集約 │ ├── common/ ... 共通 │ └── <system>/ ... システム別に分割 │ ├── m020_staging/ ... Staging層。型変換、列名標準化、NULL整形などの前処理 │ ├── common/ ... 共通 │ └── <system>/ ... システム別に分割 │ ├── m03
DMBOK入門（第2回）：データガバナンスとアーキテクチャの鶏と卵をSnowflake/dbtで解く
はじめに 第1回では、DMBOK の11の知識領域の全体像を俯瞰し、Snowflake/dbt の日常業務がどの領域に対応するかをボトムアップで整理しました。「ツールはあるが設計が不十分」な部分カバー領域として、データガバナンス・メタデータ管理・データ品質管理の3つを挙げました。 第2回となるこの記事では、DMBOKホイールの中心に位置する 第2章（データガバナンス） と、その骨格を形成する 第3章（データアーキテクチャ） の2章を一緒に扱います。2章まとめの理由は後述しますが、この2つは「鶏と卵」の関係にあり、片方だけ独立して設計することが実は難しいからです。 想定読者 第1回を読んでいる（または DMBOK の全体像を把握している） Snowflake および dbt を日常的に使っている 「ガバナンスをやれ」と言われたが何から手を付けてよいかわからない この記事で得られること データ
Pandasはもう古い？2026年のPythonデータ分析ライブラリを整理してみた - Qiita
はじめに Pythonを使い始めてはや十数年。他の言語も覚えないと思いつつ、研究、PoC用途で使う、簡単な解析や簡単なシミュレーションに使ってきました。 表計算で広く使われるPandasですが、Pandasを最近あまり使わなくなったというSNSの投稿をみて、使用するライブラリが変化しているのかなと思い調べる事にしました。 現状困っていないのですが、早めに対応しておかないと後で困る事もあるかと、LLMを使いながら調べてみました。 最近は、LLMに聞けば使い方がすぐに出てくるので、新しいライブラリの参入コストも低くなってきていますよね。 単に整理しただけなので、速度比較はしていません。 ※【Python】Pandas/Polars/duckDB/NumPyで簡単なベンチマークテストをしてみたという別記事で簡単なベンチマークテストを行いましたので、気になる方は見てください。 結論としては、データ
尤度と確率は何が違うのか？ダミーデータで直感的に理解する - Qiita
統計や機械学習を学び始めると、「尤度（likelihood）」と「確率（probability）」が似たように見えて混乱しがちです。 実際、数式の形はかなり似ています。 でも、見ている向きは逆です。 この記事では、コイン投げのダミーデータを使ってこの違いを直感的に整理します。 コードは Google Colab でそのまま実行できます。 まずは用語から この記事では次の3つが重要です。 データ: 実際に観測した結果 モデル: データが生まれる仕組みを数式で表したもの パラメータ: モデルの性質を決める値 今回の例では、次のように考えます。 コインを1回投げて、表なら 1、裏なら 0 とする コインが表を出す確率を p とする コインを20回投げた結果を観測する このとき p がパラメータ、20回の結果がデータです。 今回の結論を先に1枚で 観点 固定するもの 動かすもの 知りたいこと
スクレイピングデータの更新・差分取得の方法【Python実装付き】
diff_approaches = { "hash": "取得内容のハッシュを比較して変化を検知", "timestamp": "更新日時・Last-Modifiedヘッダーで変化を判定", "url_tracking": "未取得URLのみをスクレイピング（新規追加の検出）", } import hashlib import json import sqlite3 from contextlib import contextmanager from datetime import datetime from typing import Optional DB_PATH = "scraping.db" # スキーマ定義 SCHEMA = """ CREATE TABLE IF NOT EXISTS products ( id INTEGER PRIMARY KEY AUTOINCREMEN
専務、そのエリアでABテストは無理です！実験をやる前の因果推論の事前検証 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに こんにちは、事業会社で働いているデータサイエンティストです。 最近、おかげさまで社内のとあるデータサイエンスプロダクトが佳境を迎え、実際に営業現場へ提供し、その効果を検証する段階に入りました。 一般的なウェブサービスにおける効果検証であれば、ユーザーをランダムに処置群と統制群に割り付け、いわゆる AB テストを実施するのが標準的でしょう。しかし、営業現場や社内で同様の検証を行おうとすると事情は大きく異なります。仮に社員を完全に処置群と統制群に分けた場合、「なぜ隣の席の A さんには権限が付与されて、自分には付与されないのか。不
データ分析初学者のための目的設計・分析設計 - Qiita
はじめに Orbitics株式会社 データサイエンス部の上野です。 データ分析を学び始めた方が最初につまずくのは、分析手法そのものではなく、その前段階の「設計」です。 現場では「とりあえずSQLを動かす」「グラフを作る」といった手法先行型の分析がよく見られますが、なぜ分析を行うのか（Why）、何を明らかにしたいのか（What）を明確にできなければ、成果が断片的になりがちです。 本記事では、データ分析の上流工程である 目的設計（Why） と 分析設計（How / Where） を体系的に整理し、実務で頻出するシナリオをもとに「成果につながる分析設計」の考え方を解説します。 特に次のようなケースで役立つ内容です。 顧客離脱率を分析して原因を明らかにしたい キャンペーン効果を定量的に評価したい KPIダッシュボードを設計して経営層に示唆を提供したい 💡 本記事のゴール 分析を「意思決定のための
Zennブログ執筆用のAgent Skillを自作して運用してみた
はじめに 私はZennで技術ブログを書く際に、CursorのAgent Skillsを活用しています。具体的には、自分のブログ用にカスタマイズした「Zenn技術ブログ執筆スキル」という SKILL.md を作成し、日々アップデートしながら運用しています。 この記事では、そのスキルの中身と運用方法、そしてtextlintやObsidianとの組み合わせで得られた効果について紹介します。 この記事で伝えたいこと 自分のブログ用にカスタマイズしたAgent Skillの具体的な内容 日々の運用でスキルをどうアップデートしているか ObsidianのメモからZenn記事への変換でスキルが役立つ場面 textlintとの組み合わせによる文章品質の向上 前提: AIに全部書かせているわけではない 誤解されやすいので先に書いておくと、私はAIに記事を丸投げしているわけではありません。 実際の使い方として
J-Quants API を FastAPI + SQLAlchemy で実運用する際のハマりどころと設計パターン
はじめに J-Quants API は東証上場銘柄の株価・財務データを取得できる API です。個人開発で日本株分析サービスを構築する際、非常に便利なデータソースですが、実際にプロダクションレベルで運用しようとすると意外なハマりどころが多いです。 本記事では、FastAPI + SQLAlchemy (async) + PostgreSQL の構成で J-Quants API を実運用してきた中で得た知見を、以下の4つのテーマに絞って紹介します。 レート制限とリトライ戦略 差分更新とバックフィル — 効率的なデータ同期パイプライン PostgreSQL upsert パターン — 冪等なデータ取り込み 株式分割調整 — per-share 財務指標の正確な処理 1. レート制限とリトライ戦略 J-Quants API のレート制限 J-Quants API（Light）のレート制限は 1分
分析の前に、データの土壌を疑う（5） 〜分析を始めてよい、と判断できた理由
分析の前に、データの土壌を疑う（5） 分析を始めてよい、と判断できた理由 この連載では、実務でデータ分析基盤を立ち上げる中で、 「分析を始める前に何が必要だったのか」を、 実際の試行錯誤を交えて書いています。 筆者は、プロダクトのログを扱いながら、 分析・データ基盤の整備を行っている実務担当者です。 第1回では、処理が動かないところからの復旧。 第2回・第3回では、数字は出るのに信じきれなかった話。 第4回では、分析とコスト、開発と運用のバランスについて整理しました。 今回はシリーズの最終回として、 「何をもって、データが分析に使えると判断できたのか」 について書いていきます。 例として取り上げるのは、 アクティブユーザーの定義を決めるまでの試行錯誤です。 1. 「とりあえず1年間のMAUとDAUを見たい」 この話は第3回で触れました。 最初は、 「ログが1件でも上がっていればアクティブ」
BigQuery + dbt でデータパイプラインを構築してみた【DuckDB + dbt との比較付き】
はじめに 以前「DuckDB + S3 + dbt でローカルデータパイプラインを構築してみた」という記事で、DuckDB をターゲットにした dbt パイプラインを構築しました。dbt の基本的な使い方は分かったので、今回はBigQuery をターゲットにしたらどうなるのかを試してみます。 「【BigQuery入門】DuckDBユーザーが初めてクラウドDWHを触ってみた」で作成済みのデータセット・テーブルがあるので、それをそのまま活用します。DuckDB + dbt との違いを意識しながら進めていきます。 やったこと dbt-bigquery のセットアップとサービスアカウント認証 既存の BigQuery テーブルをソースにした staging → mart の2層構成 BigQuery 固有のマテリアライゼーション（table / view / incremental） パーティショ
ベイズ原理主義者ブチ切れ必至！因子分析の再学習を50倍速める運用の知恵 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに こんにちは、事業会社で働いているデータサイエンティストです。 本記事は、以下の記事の続編として、推定したベイズ機械学習モデル、とりわけ、いわゆる因子分析系のモデル、を「実際にどう運用するのか」に焦点を当てて解説します。 まず大前提として、本記事は信用区間を不要とする分析タスクを想定しています。そのため、法律や社内・組織内規定により厳密な信用区間を報告しないといけない場合は、本記事で紹介される手法を利用しないでください。 さて、私が民間企業でデータサイエンティストとして約5年間働きつつ、学会発表などを通じてアカデミアとの関係も保
【2026年版】Webスクレイピングの"3大つらみ"をBright Dataで解決する - Qiita
はじめに：この記事で得られること Webスクレイピングに挑戦したことがあるエンジニアなら、一度は「IPブロック」「CAPTCHA」「JavaScript動的レンダリング」という壁にぶつかったことがあるのではないでしょうか。 本記事では、世界20,000社以上が利用するWebデータプラットフォーム Bright Data を使って、これらの課題をどう解決できるのかを 公式ドキュメントとリソースに基づいて 体系的にまとめます。 対象読者 Webスクレイピングに興味があるが、ブロック対策に苦労している方 BeautifulSoupやSeleniumでの自前実装に限界を感じている方 AI/MLのためのデータ収集パイプラインを効率化したい方 Webスクレイピングを行う際は、対象サイトの利用規約（Terms of Service）やrobots.txtを必ず事前に確認し、許可された範囲で実施してくださ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
スクレイピング×OpenAIで記事を自動生成する【Python入門チュートリアル】
