はじめに 前回の記事でDatabricks Labs「Ontos」をローカルで動かして、機能をひと通り触ってみました。今回は、自社のデータ基盤に対して各機能を検証して、 今の時点での導入判断 を書きます。 先に結論だけ言うと、 今すぐのフル導入は見送り。ただしウォッチは続ける です。ツール自体のポテンシャルは感じていて、アップデートやチーム体制の変化次第では導入する可能性は十分ある。同じようにデータガバナンスツールの導入を検討しているチームの参考になればと思います。
はじめに 前回の記事でDatabricks Labs「Ontos」をローカルで動かして、機能をひと通り触ってみました。今回は、自社のデータ基盤に対して各機能を検証して、 今の時点での導入判断 を書きます。 先に結論だけ言うと、 今すぐのフル導入は見送り。ただしウォッチは続ける です。ツール自体のポテンシャルは感じていて、アップデートやチーム体制の変化次第では導入する可能性は十分ある。同じようにデータガバナンスツールの導入を検討しているチームの参考になればと思います。
オンチェーンデータ分析プラットフォームのDuneはデータ変換ツール「dbt」を利用して、同社のデータカタログをSnowflakeやBigQueryへ直接出力できる新機能「dbt Connector」を発表しました。 Your data team already knows dbt. Now they can use it on the most comprehensive onchain data catalog available, and deliver the output directly to Snowflake or BigQuery. Same tooling. No new infra. Just onchain data, shaped exactly how you need it. dbt Connector → Datashare… https://t.co/zQh
はじめに Apache Sparkを学ぼうと思ったとき、こんな経験はないでしょうか。 公式ドキュメントを開いたものの、内容が難しい 「Spark 入門」で検索すると記事が大量に出てきて、どれが良質か判断できない 理論は読んだけど、手を動かせる環境がなくて結局身につかない 私自身、実務でDatabricks上のSparkを使ってデータパイプラインを構築するデータエンジニアですが、学び始めた当初はまさにこの状態でした。あれこれ探し回った結果、「ここだけ押さえておけば大丈夫」と言えるリソースがいくつか見つかったので、この記事でまとめて紹介します。 対象読者 Sparkをこれから学び始める方 pandasは使えるが分散処理は未経験の方 実務でSparkを使い始めたが、体系的に理解し直したい方 1. Spark Playground ── ブラウザだけで理論もコーディングも学べる 個人的に最も推した
はじめに Power BIでレポートを作成する際、データの取り込み元としてExcelやCSV、あるいはSQL Serverなどのデータベースを利用するのが一般的です。 しかし、インポートモードで扱うデータが「数十GBクラスの大容量」になったとき、その運用に頭を抱えたことはありませんか?今回は、30〜60GBという膨大なデータを扱うプロジェクトにおいて、運用効率化のためにSharePoint接続を検証・導入した際の知見を共有します。 対象読者 ・Power BIで扱うデータ量が肥大化し、パフォーマンスや運用に課題を感じている方 ・複数人でダッシュボードを共同開発しており、ファイルの受け渡しが必要な方 ・SharePointをデータソースとして活用したことがない方 背景・困っていたこと スクラム開発の一環でPower BIのダッシュボード構築を担当していました。 当時の状況は以下の通りです。
🎯 この記事のゴール 【対象読者】 Difyを導入したものの、チャットの枠を超えた「実業務」への組み込みに苦戦している方 Googleの各サービスをAIの「拡張パーツ」として使い倒したいエンジニア・リーダー 【得られる成果】 実現したい要件に直結する3つの技術選定基準 セキュリティと運用性を両立した、2026年基準のシステム構成案 LLMアプリケーション開発プラットフォームとして不動の地位を築いた「Dify」 しかし、その真価は単なるチャットUIにとどまりません。GoogleカレンダーやGmail、Driveといった「既存業務の基盤」と繋がった瞬間に、圧倒的な価値を発揮します。 この記事では、Googleの各種サービスと連携させることで、Difyを単なる「相談相手」から「自律して動く相棒(エージェント)」に変えるための、3つの最適解を解説します。 1. 【Action】GCP (Clou
なぜAIは「文脈なし」だと薄い設計しか返せないのか AIは学習データの中から「もっともらしい設計」を返します。文脈がなければ、汎用的で無難な答えを選ぶしかありません。 たとえば「ユーザー管理機能の設計をして」とだけ伝えると、AIは次のように考えます。 どんな規模のシステムかわからない → 中規模を想定 どんな技術スタックかわからない → 一般的なREST APIを想定 セキュリティ要件がわからない → 標準的な対応を想定 結果として出てくるのは、どの現場にも当てはまりそうで、どの現場にも完全にはフィットしない設計です。 逆に言えば、文脈・制約・判断軸の3つを渡すだけで、AIの設計品質は劇的に変わります。私自身この3点を意識するようになってから、AIの出力をそのままレビューに出せるケースが増えました。 AIは「賢いツール」ではなく「優秀な実行者」です。何を重視して設計するかの判断は人間が担い
データの確認と欠損値 欠損値の確認し、欠損値を特定の値で置き換えます。 学習用データ(csv形式でダウンロードする事) # coding: utf-8 """ 1, Install $ python3 -m pip install pandas $ python3 -m pip install scikit-learn """ import pandas as pd import pickle import os.path from sklearn import tree COL_X = ["gaku_nagasa", "gaku_haba", "kaben_nagasa", "kaben_haba"] COL_Y = "type" MY_CSV = "my_iris.csv" MY_MODEL = "my_model.pkl" def main(): """ Main """ print
1. はじめに 株式会社 MBK デジタルの古畑です。 最近、データエンジニアリング界隈でひとつの記事が話題になっています。 Airbyteの共同創業者・CEOであるMichel Tricot氏による 「The Missing Context Layer」 です。 記事の主張を私なりに要約すると、「セマンティックレイヤーは指標の意味づけには有効だが、AIエージェントに必要な文脈を支えるには不十分であり、エンティティや関係性を扱うオントロジー的な層が必要になる」というものです。 記事タイトルにある「Context Layer」とはまさにこのオントロジー的な基盤を指しており、それが現代のデータスタックに欠けている、というのがTricot氏の問題提起です。 ここで登場するオントロジーとは、もともと哲学の概念ですが、データ・AI領域では「物事の概念・実体と、それらの間の関係性を体系的に定義・記述す
はじめに dbt Semantic Layer のサービストークンによる接続権限の分離と、モデルの出力先スキーマ分離を組み合わせた場合の動作を確認した際の内容を記事としました。 dbt Semantic Layer のクレデンシャル・サービストークンの概要 dbt Semantic Layer は dbt が提供するセマンティックレイヤーの実装を指します。 dbt Semantic Layer を経由する場合、BI などからは直接 DWH に接続せず、対象となる dbt プロジェクト専用のエンドポイントにアクセスします。BI からメトリクスなどを指定すると、内部エンジンの MetricFlow が SQL を組み立て、DWH 側にクエリを発行し結果を取得します。 この仕組みでは、2種類の認証情報を使用します。 サービストークン:BI などから dbt プロジェクトのエンドポイントに認証する
こんにちは!Finatextホールディングス/ナウキャスト 広報担当の及川です! 2026年4月6日、ナウキャスト主催の勉強会「DataOps Night#10」を開催しました。 記念すべき第10回目となる今回のテーマは、「エンタープライズAIエージェントを支える技術」です。昨今のAIブームを背景に、現地・オンライン合わせて217名もの方にお申し込みいただき、会場にも多くの方が足を運んでくださいました。 当日は、ナウキャストの六車のほか、サイバーエージェントの山田さん、LayerXの澁井さんをお迎えし、最新の知見を共有いただきました。 発表内容 1.「MCPゲートウェイ MCPassの設計と実装」(ナウキャスト 六車さん) 1番目に登壇したのは、株式会社ナウキャストの六車光貴さんです。 エンタープライズにおけるMCP運用の課題と、それを解決するプロダクト「MCPass」に関して、アーキテク
はじめに 私は機械学習エンジニアをしており、現在はLLMを扱うことが多く、RAGシステムの構築などを行っています。 バリバリのバックエンドエンジニアというわけではないので、SQLを日常的に使う機会はそれほど多くありません。 ただ、こういった場面ではDBを使用したくなることがあります。 RAGシステムでドキュメントのメタデータ(ファイル名・チャンクID・埋め込みベクトルのインデックス等)を管理したい データの結合・加工を行いたい 2つ目に関して、なんのこっちゃと思う方もいるかもしれませんが、複数の文書間でIDなどのデータで紐づいていたり、特定のフラグや文言が存在するデータのみを抽出して学習データに使用したい、といった場面がたびたびあります。 フォーマットがバラバラな文書をPandasでちまちま加工して必要なデータを成形していると、コードも複雑化してマジックストリング(ハードコードされたカラム
はじめに こんにちは!ひさふるです。 生成AIの中でも推論モデルってありますよね? OpenAIのo1-previewによって一気に有名になり、現在ではGPT-5にも推論機能が統合されるなど、すっかり当たり前の存在になりました。 私は今まで「よく考えてくれる頭の良いモデルなんだなぁ」と思って知ったかぶりをしていましたが、いざ他人に説明しようとすると...全然仕組みをわかっていなかったんですよね。 そこで今回は、「推論モデルって何?」という質問にちゃんと解答できるようになるために、仕組みから完全に推論モデルを理解していこうと思います。 そもそも"生成AI"って何...? 大事な前提として、"生成AI"や"LLM"という言葉を正しく理解するところから始めましょう。(何を言いたいかわかる方は飛ばしていただいてOKです!) まず、現在ではテキストの入出力により対話できるモデル(LLM)のことを生成
1.4 ペイオフ 満期日 T におけるオプションのペイオフ(Payoff)は以下の通りです。 コールオプション: \text{Payoff}_{\text{call}} = \max(S_T - K, 0) = (S_T - K)^+ S_T > K(原資産価格 > 行使価格)のとき権利を行使して利益 S_T - K を得ます。S_T \leq K のときは権利を行使せず、ペイオフは0です。 プットオプション: \text{Payoff}_{\text{put}} = \max(K - S_T, 0) = (K - S_T)^+ Python実装 S_range = np.linspace(50, 150, 200) K = 100 call_payoff = np.maximum(S_range - K, 0) put_payoff = np.maximum(K - S_range, 0
エンジニアの吉田です。 フォルシアにはdevゼミという文化があり、エンジニアが講師となって自身の詳しい分野に関する講義やハンズオンを行っています。 私もこれまでに何度かSQLチューニングを題材としたdevゼミを開講してきましたが、いずれもこちらが一方的に話すという形式に終始しており、実際に受講者が手を動かせる形式での講義も望まれていました。 色々とやり方を模索した結果、コンテスト形式で実際にPostgreSQLのチューニングを行ってもらう、という形の講義を行うことになりました。コンテスト形式での実施にあたりいろいろと工夫した点や学びがあったので、以下にそれらをまとめます。 SQLチューニングをハンズオンすることの難しさ これまでインプット中心の講義を行っていたのは、ひとえに SQLチューニングをハンズオン形式で実施することのハードルが高かった からです。 過去に社内でも何度かチューニングコ
Google Cloud アドベントカレンダー【通常版】 2025 の初日を務めます Customer Engineer の Shu Aiba です。このブログでは、データ分析のサービスである BigQuery の様々な機能をコンソールを見ながら紹介していきたいと思います。 BigQuery のコンソール画面はたまに仕様が変わったり、ん?なんだこれは。みたいなメニューが追加されたりします。このブログでは、私の独断と偏見で、コンソールの気になるところを7個かいつまんで紹介します。 はじめにお断りしておきますが、このブログを読むことで BigQuery の基本的な機能や使い方が完全にわかるというわけではありません。今お使いのみなさまもこれから使おうかなと考えていただいている皆様も、おっ、こんな機能もあるのね、とちょっと驚いていただくことが目的になっております。ということで、よろしくどうぞ。 と
こんにちは。食べログカンパニー 開発本部 国内メディア開発部 店舗情報チームの高橋です。 本記事では、案件の企画検討フェーズにおけるデータ分析の進め方を、AIコーディングエージェントのDevinを活用して見直した取り組みを紹介します。企画メンバー(PdM)とエンジニアが個別にAIを使う状態から、Devinを介して共同でデータ分析に取り組む進め方へ変えました。その結果、工数は約3人日から約1.6人日へ、リードタイムは2〜3日から1日へ短縮できました。 この変化の出発点にあったのは、企画検討フェーズでよくある進め方への疑問でした。「エンジニアがデータを取得し、企画メンバーが分析する」という分業スタイルです。私たちもそうしていましたが、この進め方には、個人がAIを使って作業を効率化するだけでは解決しない、構造的な課題がありました。 本記事では、その構造的な課題に対して「個人のAI活用」を「共同の
LayerX BizOps 部データグループのさえない (@saeeeeru) です。最近は娘と『名探偵プリキュア!』にハマっています。「自分で見て、感じて、考えて、"本当"の答えを出す」。AI 時代だからこそ刺さるメッセージです(推理パートをちゃんと解けるようになりたい)。 前回の記事では、dbt Python model から外部 API を呼び出す実装パターンを紹介しました。今回はその応用として、LLM の Web Search 機能を使って公開情報を取得し、それをデータパイプラインに組み込む実践例を書きます。 この記事では、まず LLM の Web Search 機能をどう使うとデータパイプラインに載せやすい形になるのか を説明し、そのうえで Snowflake / dbt にどう載せたのか、そして本番運用の中でどんな品質課題が見えてきたのか、という順に整理します。 Web Sea
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く