データ基盤チーム & Unit9（エビデンス創出プロダクトチーム）ブログリレー 4日目は、SQLプログラミングのお話をお届けします。Unit9エンジニアの三浦[記事一覧 ]です。昨日は木田さんの『巨大テーブルにインデックスを追加したい、Flywayで』でした。 今回の課題はタイトル通り、月の集合（たとえば、ユーザーがアクティブであった月の集合）から「何年何月から何年何月まで連続していた（アクティブだった）」という期間の集合に変換せよというものです。連続した期間ってのがまとまっていると判定で便利な局面があるんですよね。具体的にどう役に立つかは後述しますが、大変に実用を意識したデータ基盤プログラミング課題であります。 さて私自身がややこしいコードの書かれた記事を見るとコード部分を読み流してしまいがちなので偉そうなことが言えないのですが、やはりプログラミング課題の解説はコードを精読してこそです
エムスリーエンジニアリンググループGMで、データ基盤チームの木田です。 この記事はデータ基盤チーム & Unit9（エビデンス創出プロダクトチーム） ブログリレー3日目の記事です。前回は橋口さんの データ整備の「曖昧さ」に立ち向かう、ドメインエキスパートと協業するための実践的Tipsでした。 本日は、既存のPostgreSQLのさるテーブル (レコード数 100億超) に対して、差分データをSQLで抽出してBigQueryに連携するための索引追加をしたときの経験を元に、PostgreSQLの巨大テーブルに対してFlywayを使用してインデックスを安全に追加する方法についていくつかのテクニックを紹介します。 背景 ナイーブな実装の問題点 CREATE INDEX CONCURRENTLYの使用 Flywayから実行する時の注意点 タイムアウトへの対処 一時領域不足 インデックスサイズを抑える
秋のブログ週間の5本目です。 3年前の秋のブログ週間でデータベースと向き合う決意というエントリーを書きました。3年経ちましたが、多少ベクトルは変わりましたが今も基本的な気持ちは変わっていません。むしろ、「生成AIによって自然言語で気軽に作れるようになった」ことで、SQLの敷居は大きく下がりました。 DFDのガイドライン作りを始めた今年はDFDの本が出ました。5月にブログも書きました。 データフローダイアグラム本の献本をいただきました本書を読んだことで、フューチャー社内のDFDが何を工夫してどのように活用してきたのか、というのを相対的に見れるようになりました。フューチャースタイルも有志で公開しているガイドライン集にいつか入れられたらいいな、ということを思いました。そして、いつか他社のDFD図の発展がどのようになっているのかとかも世の中に出てきて、50年分の図の進化が行われると良いな、という気
膨大なデータが日々生まれる現代、企業の意思決定は「どれだけ迅速かつ正確にデータを活用できるか」にかかっています。 生成AIや高度な分析技術の活用が広がるなか、ベクトル検索やリアルタイム集計など、新しいデータ活用の手法も注目を集めています。 本カオスマップでは、代表的な分析向けデータ基盤ツールを、「DWH」「レイクハウス」「データレイク／補助ツール」「ベクトルDB」「リアルタイム分析DB」「クエリエンジン」といったカテゴリに整理し、それぞれの特徴や選定ポイントを解説します。 ※本記事で取り上げるカテゴリには、純粋なデータベース製品に加え、データレイク管理基盤やクエリエンジン、リアルタイム分析基盤なども含まれています。これらは厳密には役割や機能が異なりますが、いずれも「データ分析を支えるストレージ／処理レイヤー」として活用されるケースが多いため、便宜上ひとつのマップに整理しています。 また、分
みなさん、普段から開発者体験（DX）を気にしてますか？ DXとは、開発中に感じる“心地よさ”や“効率の良さ”を指します。 車輪の再開発のようなDXを損なう体験がなければ開発はずっと楽しいんです！ そこでこの記事では、「心から開発を楽しめる」相棒たちを10選紹介します！ 1. Convex “SQLの呪縛”からの解放 歴史のあるSQLはどうしても、歴史に引っ張られます。 Supabaseとかを使ってると、Row Level SecurityやSQL Functionsとかで、死ぬほど書きにくいSQLを書かなきゃいけなくなることありますよね。まるでFirebaseの認証ルール並み。良くも悪くも結局SQLだから、隠しきれない歴史の重み、つまりDXの悪さがでてくる。 しかしConvexは一切そういうのはありません！！！！ 全てがDXを中心に一から考えられて作られたサービス。そう、React時代のバ
システムを運用していると時折直面するのが「移行作業」です。 新しい技術に触れられるのは楽しいです。一方、大量のコードの書き換えはちょっと辛いですよね。単純な置換で済めばよいのですが、そううまくはいかないことがほとんどです。 今回はこの書き換えを Claude Code を活用して楽に、精度良く実施したお話です。 データ基盤チーム/Unit9（エビデンス創出プロダクトチーム）エンジニアの坂元です。このブログはデータ基盤チーム/Unit9 ブログリレー 1 日目の記事です。 背景 はじめの一歩 独り立ち そして検証も… できたこと 残った課題 細かい工夫 全文読んでから対応すること セルフレビューしてもらう まとめ We are hiring! 背景 エムスリーのデータ基盤（BigQuery）上では数多のデータパイプラインが稼働しています。今回はそのうちの一部を dbt (data build
OSSデータベース取り取り時報 第123回企画セミナー「データ活用の現状と近未来」開催報告、MySQL 9.5.0のリリースとMySQL AIの登場、オラクルが運営するPostgreSQLサービス！？ この連載はOSSコンソーシアム データベース部会のメンバーがオープンソースデータベースの毎月の出来事をお伝えしています。 連載10周年企画セミナー「データ活用の現状と近未来 —— データベースからデータスペースへ」を開催 この「OSSデータベース取り取り時報」の連載10周年とデータベース部会発足10周年を記念して、オープンソースカンファレンス2025 Online/Fallの中で企画イベントを開催しました。この企画の概要は前回にも説明しましたが、少し補足しておきます。 今回の目玉は、独立行政法人情報処理推進機構（IPA）の協力を得て、これからのデータ活用の形を考えるために、データス
こんにちは otsubo です。MySQL (InnoDB) のロックについて整理する機会があったので記事にします。 はじめに 全ての ロックタイプ を網羅するのは大変なため、 レコードロック ギャップロック ネクストキーロック を中心にまとめます。この3つはトランザクション内で UPDATE、DELETE、 SELECT ... FOR UPDATE / SHARE するときに獲得されるロックです。INSERT 時のインサートインテンションロックもちょっとだけ扱います。テーブルロックやメタデータロックは扱いません。 InnoDB ではクエリによって特定の「範囲」がロックされることがあります。これを知らないと思わぬ不具合に繋がります。 範囲をロックして InnoDB は何を実現したいのか、どのような仕組みでロックするのかを知っておくと開発に役立ちます。 記事を通して下記を前提とします。 M
背景 PostgreSQLのランダムデータ生成方法 uuid createではgetrandom()を使っていた 実際どれくらい違うのか？ PostgreSQLでもgetrandom()が使えるのか？ getrandom()のvDSO実装でUUID生成を比べてみる vDSO実装のgetrandomを使ってUUIDを生成してみる 参考資料 以前PostgreSQL 18でUUIDv7がサポートされたという記事を書きました。今回は現在取り組んでいるUUIDv7の生成を早くするための改善について、その背景や検証内容についてです。 背景 UUIDの生成速度が気になったきっかけは、PostgreSQLで色々なUUIDv7生成方法を比較していた時に、PostgreSQL 18で導入される予定のuuidv7()関数とpgrxで自前で作ったUUIDv7生成関数の性能比較をしていたときでした。 Postgr
大規模データ×AI活用の現在地 〜 Online Conference 2025 〜での登壇内容です
確率的データ構造を用いた DB 負荷軽減と Valkey での実装 | CyberAgent Developers Blog
はじめに こんにちは。ABEMA の広告配信システム開発チームでバックエンドを担当している戸田朋花です。 ABEMA ではパーソナライズした広告配信ができるため、「ユーザー × 属性」がキーとなる高カーディナリティなデータに対する読み書きのリクエストが大量に発生します。 また全てのユーザーが全ての属性を持っているわけではないので、リクエストに対して実際にデータが存在しないことが多くあります。 その結果、読み取りのアクセスパターンとして「リクエストのカーディナリティがデータのカーディナリティを大きく上回る」状態になります。 ABEMA の広告配信サーバーには、このような性質のリクエストがピーク時には数千から数万 RPS で発生します。 データベースへ大量にリクエストが発生するとデータベースが高負荷となりシステム全体のボトルネックになります。 これを防ぐための一般的な方法として、キャッシュ用デ
はじめに スキーマ分離と行分離 目的と結論 目的 結論のサマリ 試験内容 試験環境とツール 負荷の設計 本番環境でのクエリ傾向の分析 QPSの測定 進め方 試験結果 スキーマ分離のボトルネック スキーマ数を固定して負荷をあげてみる 結果まとめ なんとか延命したい はじめに 弊社が採用しているDB設計は、テナントごとに独立したスキーマを持つ「スキーマ分離」 のデータ構造に基づいています。このアーキテクチャは、高いデータ分離性とセキュリティを確保できる一方で、「スキーマ数の増加に伴ってパフォーマンスが劣化する」という性質が指摘されます。 サービスのスケールにおいてこの「性能劣化」が、いつ、どのように顕在化するのかは、設計上の大きな課題でした。この漠然としたリスクを定量的に評価し、将来的な「行分離」アーキテクチャへの移行の是非を判断することを目的に、負荷試験を実施しました。 本記事では、この試験
株式会社アークエッジ・スペースの id:koba789 です。 アークエッジ・スペースでは、衛星データを活用するためのアプリケーションを開発しています。人工衛星のカバレッジはグローバルなため、それを活用するアプリケーションもグローバルであるべきでしょう。 グローバルなアプリケーションをコスト効率高く提供するため、私たちはサーバレスなプラットフォームを積極的に活用しています。 それは DBMS についても例外ではなく、昨年の re:Invent で発表された Amazon Aurora DSQL を活用しています。課金モデルが従量課金であるため、固定費を押さえたままスモールスタートできるというのも大きなメリットです。 さて、今回はそんな Aurora DSQL を使うときにハマった PostgreSQL との非互換ポイントを紹介します。Aurora DSQL はプロトコルこそ Postgre
この記事は、CYBOZU SUMMER BLOG FES '25の記事です。 クラウド基盤本部の新井です。 この記事では、DB へのアクセスを伴う Go の単体テストについての私たちの考え方、そしてそれを実践するために開発・公開したライブラリをご紹介します。 DB のモックとその問題点 DB へのアクセスを伴う Go のプログラムをどのように単体テストしたいとき、最初に思いつくのは go-sqlmock などのツールを使って DB をモックする方法です。 サンプルコードでは、次のようなテストを書いています。 package main import ( "fmt" "testing" "github.com/DATA-DOG/go-sqlmock" ) // a successful case func TestShouldUpdateStats(t *testing.T) { db, mo
type そのもの、 あるいは _type のようなsuffixを持つ名前を変数や、構造体・クラスのメンバーや、データベースのcolumnなどに付けてしまうことがしばしばあると思うのですが、個人的にはあまりこれはやらない方が良いのではないかと考えています。 理由としては type はいくつかのプログラミング言語において予約語になっており、そのセマンティクスにおいて特別な役割を果たすことが多い。 Ruby on RailsにおいてはDelegated Typesという機能において、 _type というcolumnは特別な意味を持つ (もちろんアプリケーションコード側でDelegated Typesであるという宣言をしなければ副作用は無いのですが)。 その他のフレームワークに似たようなものがあるのかは知りませんが…… というものがあると思っており、そういった概念との衝突を避けるために特別かつ強
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
MySQLのパフォーマンスを改善するうえで、「インデックス」は重要な要素の一つです。しかし、MySQLの内部でオプティマイザがどのようにインデックスを選択し、データを処理しているのかを正確に理解しているエンジニアは多くありません。どうすれば、インデックスを適切に使いこなせるのでしょうか。今回は、MySQL運用のスペシャリストとして知られるyoku0825さんに、インデックスの活用方法について解説していただきました。 B-treeインデックスの基本構造― 今回のインタビューでは、MySQLのインデックスの知見を詳細に伺っていきます。 インデックスを適切に活用するためには、その仕組みを理解することが重要です。そこでまずは、MySQLのInnoDBで最も基本となるB-treeインデックスの構造からお話しします。内部的にどのような構造になっているか、イメージを掴んでいきましょう。 今回は、MySQ
【AIとクラウドの文化祭！】DevelopersIO2025 TOKYO GRAND FINALE https://classmethod.connpass.com/event/366750/ 「[自由研究発表] クラスメソッド社員による怒涛のLT大会、11連発」
PostgreSQL18連載の6本目の記事です。 PostgreSQL 18がリリースされました。リリースされた機能のうち私は「B-treeインデックスのスキップスキャン」機能が気になったので、機能の特徴を深堀りしつつ、実際の挙動を確認してみます。 B-treeインデックスのスキップスキャンとは複合インデックス（複数の列で構成されるインデックス）の利用効率を劇的に向上させる新しいスキャン方法です。 従来の課題PostgreSQLでは、例えば(列A, 列B)という順番で複合インデックスを作成した場合、これまではWHERE句に先頭の「列A」の条件がないと、インデックスを効率的に使えませんでした。 例えば、WHERE 列B = 'hoge'というクエリでは、せっかくの (列A, 列B) インデックスをうまく使えず、結果としてテーブル全体をスキャン（シーケンシャルスキャン）してしまう、あるいは、イ
この設計は、注文エンティティと発送エンティティの一部が混在してしまっている状態です。発送エンティティが混在しているのであとから発送に関する情報をもっと入れたいとなったときに、ここに追加し続けてしまうことになるでしょう。この場合も発送は別のテーブルとして切り出すのが適切です。 よくある失敗パターンとしては安直に日時(xxx_at / xxx_on)やフラグ(xxx_flag)やステータス(xxx_status)のカラムを追加することです。これらを追加したくなったときには他のエンティティではないかと疑いましょう。 変更のコストが大きい アプリケーションのリファクタリングと比べて、データベースのリファクタリングはコスト（時間・工数・リスク）が大きいです。影響範囲がどの程度あるか、既存データがどの程度あるか、ダウンタイムがどの程度許容されるか、などを考慮する必要があります。データベースのリファクタ
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
追記 npxコマンド一発で蔵書リストが取れるツール作ったので、結果だけが欲しい人はそっち使う方がいいです。 npx kindle-title-exporter > books.csv dominion525.hatenablog.jp 背景 Kindleの蔵書、主に漫画なんですが、現在ざっくり3500冊、600シリーズくらいあるんですよ。 なお、継続購入してるシリーズが100件くらい。 こうなるとあんまり上手く把握できなくなっちゃうからなんとかしたいなーと思ってたわけです。 しかもAmazonは公式なエクスポート機能を提供してくれないし…。 で、以前調べた時は下記くらいが挙がってたものの、ちょっとなんだかなあと思ってたんですよ。 蔵書ページをスクレイピングする方法 Kindleの蔵書を取得する - TypeScript入門 Kindle Cloud reader のWebDBを取得する方法
サービスが成長するにつれてデータベースは肥大化する。 肥大化したデータベースは最初は良かった設計も、パフォーマンスの低下やメンテナンスが難しくなる。 もちろん、そうならないように最初から設計を工夫することもできるが、サービスの成長に伴い要件が変化することも多い。 そうなると全ての変更を予見することは難しいため、データベースのリファクタリングは必要不可欠だ。 実際にAIを利用したソフトウェア開発が主流になっていきつつある昨今はよりデータベースの成長速度は加速している。 だからこそ、データベースリファクタリングは重要であり、AIが台頭して来た時代でも変わらず必要なスキルである。 そこで今回は実際にサービスの成長と共にデータベースをリファクタリングする際の戦略と実践的な手法について解説する。 なお、AI時代でもデータベースの技術が重要であることは変わらない話はこちらを参照されたい。 データベース
概要 SQLはデータベース操作に特化した言語で、柔軟にデータを操作できます。ただし、独自のロジックに基づいているため、それを正しく理解しなければ、読みづらくパフォーマンスの出ないSQLになってしまいます。本書では、「条件分岐」「集約」「ループ」「結合」「更新」など日常的に実行する処理の良い書き方・悪い書き方を解説します。その際、データベース内部でどう処理が実行されているかを示す実行計画を読み解くことで、「なぜそう書くと効率が良いのか」「可読性や保守性が向上するのか」を実感を持って理解することを目指します。改訂に伴い、SQLに追加された機能など現在の現場に対応する形に加筆・修正しています。 目次 はじめに──クラウドネイティブ時代にパフォーマンスチューニングはどのような意味を持つか 動作環境 サンプルコードのダウンロード 本書の構成 目次 第1章：DBMSのアーキテクチャ──この世にただ飯は
本記事では、2025年7月28日に開催され、約1,500名が申し込んだイベント「t-wadaさんに聞く！SQLアンチパターン第2版 - 全27章まとめて紹介！」の内容をお届けします。イベントでは、書籍『SQLアンチパターン 第2版 ―データベースプログラミングで陥りがちな失敗とその対策』の出版を記念して、監訳者であるt-wada（和田卓人）さんをお招きし、本書の魅力についてご講演いただきました。ぜひ本編のアーカイブ動画とあわせてご覧ください。 t-wada： 本日は『SQLアンチパターン 第2版』という本についてお話しします。第2版も私が監訳しています。本日の講演では、先日の「Developers Summit 2025 Summer」で講演した内容をより厚く、各章の内容に踏み込んで説明します。 はじめに時は2025年、世界はバイブコーディングの炎に包まれました。 AIと一緒にコードを書く
はじめに こんにちは。商品基盤部・商品基盤2ブロックの小原です。私が所属するブロックではお気に入り機能のマイクロサービスを担当しています。 ZOZOTOWNではさらなる成長に向けて、さまざまなリプレイスプロジェクトが進行中です。本記事では、その中でもお気に入り機能のリプレイスについて紹介します。SQL ServerからAurora MySQLへ数十億レコードをゼロダウンタイムで移行するために設計したデュアルデータベース戦略を解説します。 こんな方に読んでもらいたい 段階的なマイクロサービス移行戦略を策定する担当者 ゼロダウンタイム移行の手法を探すアーキテクト Spring BootでマルチDataSourceを実装する開発者 数十億レコード規模の移行戦略に関心があるデータエンジニア オンプレミスからAWS移行でダウンタイム最小化に課題を抱えるチーム なぜデュアルデータベース構成を採用したの
先日、DuckDBで ST_AsMVT、ST_AsMVTGeom関数が利用できるようになりました。 ということは、DuckDB WASMを用いることで、ファイルをアップロード、格納、MVTの配信がフロントエンドで完結するということなのでは？と思ったのが始まりでした。 恥ずかしながらDuckDBというツール自体をあまり使ったことがなかったので、勉強がてら実装してみました。 (使用するツール・フレームワークはSveltekit、DuckDB WASMです。) 本編 DuckDB WASMの使い方はありふれていると思うので導入部分は割愛します。 今回やりたいことは「ブラウザで適当にGeoなファイルを投げてMVTを配信して表示する」です。 出来上がったものがこちらです。 リポジトリはこちらです。 この2つのファイルを読んでおけばひととおり網羅できます。 さて、以下のようにコードを書いていきます。全
昨日は、FOSS4G Hokkaido 2025 が開催されていました。様々なトピックが飛び交う中、DuckDB に関する発表はなんと2つもありました。GIS 分野での DuckDB の盛り上がりが伺えますね。 そんな中、Geospatialの世界最前線を探る [2025年版] という発表[1]での DuckDB の紹介のスライドに、なにやら気になるキーワードが... SedonaDB、みなさんは聞いたことありますか？ 「Apache Sedona なら聞いたことあるよ」という人もいるかもしれません。実は SedonaDB は、数日前に発表されたばかりの新しい OSS です。まだネット上に情報もあまりないので、ここで軽くまとめておこうと思います。 以下が Apache Sedona、Wherobots それぞれのブログ記事です。 Apache SedonaDB とは SedonaDB につ
オープンソースのリレーショナルデータベース「PostgreSQL 18」正式版のリリースが発表されました（日本語版のプレスリリース）。 PostgreSQLはITエンジニアのコミュニティであるStackoverflowの調査で2023年にMySQLを抜いて以来、3年連続でITエンジニアに最も人気のあるデータベースとなっています。 非同期I/O処理の採用による性能向上 PostgreSQL 18で最も注目すべき点は、非同期I/Oの導入による大幅な性能向上でしょう。 これまでのPostgreSQLでは同期I/O処理を採用していました。これは例えばOSにファイルリードのようなI/O処理を依頼すると、処理が終了して結果が返ってくるまで、同一プロセス（もしくはスレッド）の処理が一時停止することを意味します。 同期I/O処理の利点は実装が比較的シンプルで容易であり、バグが発生しにくい点にありますが、ひ
Kaigi on Rails 2025 登壇資料
はじめに こんにちは、『Airレジ オーダー』の開発に携わっている岡本です。 『Airレジ オーダー』は、飲⾷店の業務をカンタンにするオーダーシステムです。 お店のオペレーションや予算から、注⽂⽅法と調理・配膳の管理⽅法を選んで利用できます。 本記事では、DBマイグレーションツールをFlywayからsqldefに移行した経緯と、その過程で得られた知見について共有します。 Flywayでの課題 『Airレジ オーダー』では、もともと一般的なDBマイグレーションツールであるFlywayを採用していました。Flywayは手続き型のマイグレーションツールで、マイグレーションファイルを時系列順に実行することでDBスキーマの変更を管理します。 Flyway自体は優れたツールですが、私たちのプロジェクトでは以下のような課題が発生していました。 複数環境で開発することによるマイグレーションの衝突 : 複数
The PostgreSQL Global Development Group today announced the release of PostgreSQL 18, the latest version of the world's most advanced open source database. Translations of this press release are available in the PostgreSQL 18 press kit. PostgreSQL 18 improves performance for workloads of all sizes through a new I/O subsystem that has demonstrated up to 3× performance improvements when reading from
藩 一覧 データセットの領分一覧です。藩IDデータセットに含まれる藩については、同一の藩に属する複数の領分を統合して表示します。なお村数および石高合計については、複数の領主が存在する村（相給）を分けていません。ゆえに石高合計は藩の実際の石高とは異なります。地図表示についてはベクトルタイル地図もご利用ください。 検索 歴史的地名／現代地名による統合検索では、現代および歴史的な市区町村名や現代の町丁・字名による検索が可能です。 地名（の一部）を入力： 概要 幕末期近世村領域データセットとは、幕末期（慶応年間頃）近世村の領域データと点データを含む幕末期近世村領域データ（02_kyudaka_v2.01）（作成：本田謙一氏）を加工したデータセットです。石高については、旧高旧領取調帳データベース（国立歴史民俗博物館）を参照しています。2025年9月現在、近世村＝66,581件を提供しています。利用上
We are proud to release DuckDB v1.4.0, named “Andium” after the Andean teal (Anas andium), which lives in the Andean highlands of Colombia, Venezuela and Ecuador. In this blog post, we cover the most important updates for this release around support, features and extensions. DuckDB is moving rather quickly, and we could cover only a small fraction of the changes in this release. For the complete r
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
朝起きたら、突然片方の耳が聞こえなくなった。 突発性難聴だ。 昔に急性感音性難聴になったことがあり、その瞬間に悟った。 これは2週間以内に治療しないと治らないヤバい病気だ。1か月たつと完全に手遅れだ。 すべての予定をキャンセルして、かかりつけの大学病院に行った。 聴力検査の結果、片耳は完全に失聴していた。 どんな音も完全に聞こえていない。 聴力検査のスピーカーがでかい音で振動しているのはわかるんだけど、音として全く聞こえないのだ。(100dbでも聞こえない。通常は10-30dbぐらいで聞こえるはず) 医者から、大量にステロイドを入れる全身ステロイド療法を提案され、受け入れる。 ステロイド剤のプレドニゾロン5mgを 朝30mg(6錠) 昼30mgで合計60mgを3日飲むことになった。 その後、量を減らしていくというのを合計1週間やることになった。 //全身ステロイドはステロイドパルスとは厳密
はじめに こんにちは。MCPを使ったデータ分析をやって感動したのでシェアします。 私は、社内チームで使えるLLMサービス（以下、部内ツール）をチームメンバー限定で運用しています。 日毎の利用状況はどうか？どのLLMが使われていなくて置き換えた方がいいのか？よく使うユーザーは誰か？など、知りたいとは思っていても、なかなかSQLを叩いて分析するのは面倒だなと感じていました。 （部内ツールのDBはSQLiteなので）SQLite MCPを導入してからというもの、日本語で分析して欲しいことを指示するだけで、これらのデータ分析がものの2分でできるようになりました！とにかくデータ分析をするのが楽で、楽しくなりました。 本記事では、MCPの導入、実際の分析のやり方を説明します。 筆者の環境 M4 Macbook Pro: Sequoia 15.6.1 Claude Code: 1.0.100 sqlit
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
