<a href="https://soe-irony.hateblo.jp/">SOEのひとりごと

その他）

2025-10-05

生成AIはSQLをどう変えるか？ AI時代のSQLエンジニアの生存戦略

駆け出しテック

はじめに
生成AIがSQLにもたらす圧倒的生産性
学習ツールとしての活用と、データの民主化
生成AIで警戒すべき点と、それでもSQLを学ぶべき理由
AI時代のSQLエンジニアの生存戦略
結論

はじめに

SQLは、数十年にわたりデータの世界の共通言語として君臨し、その重要性は今もなお増しています。

しかし、近年、私たちの働き方を根底から変えようとしている巨大な波、生成AI（Generative AI）が登場しました。 ChatGPTを筆頭に、これらのAIは、自然言語の指示から文章、画像、そしてプログラムコードまで生成することができます。

当然の流れとして、「SQLも生成AIでできる」という時代が、すでに来ています。「日本語で『〇〇なデータをください』と頼めば、AIがSQLを書いてくれるなら、もうSQLを苦労して学ぶ必要はないのでは？」そんな疑問を持つ方もいるでしょう。

それでは生成AIがSQLの世界に与える影響と、これからの時代にSQLを扱う私たちに求められるスキル、そして「AI時代のSQLエンジニアの生存戦略」について考察します。

生成AIがSQLにもたらす圧倒的生産性

生成AIは、SQLを扱う上で強力なアシスタントとなり、多くのメリットをもたらします。

まず、生産性の爆発的な向上が期待できます。これまで数十分、場合によっては数時間かけて書いていた複雑なJOINやサブクエリを含むSQLについて、生成AIならば数秒で生成してくれます。これにより、エンジニアやアナリストは、クエリの作成という「作業」から解放され、より本質的な「分析」や「課題解決」に時間を集中させることができます。

「顧客テーブルと注文テーブルを結合し、過去1年間に3回以上購入した優良顧客のリストを、最終購入日が新しい順に並べてください」これだけです。これだけの日本語の指示から、AIは精度の高いSQL案を生成します。

学習ツールとしての活用と、データの民主化

すでにそういった利用方法をされている方は多いと思いますが、生成AIは、SQLの優れたメンターにもなります。例えば次のようなことを依頼してみてください。

コードの解説 自分が書いた、あるいは他人が書いた複雑なSQLをAIに見せ、「このクエリは何をしていますか？」と尋ねれば、ステップごとに丁寧に解説してくれます。
リファクタリング 「このSQLをもっと効率的に（速く）するには？」と頼めば、よりパフォーマンスの高い書き方を提案してくれます。
エラーのデバッグ 実行してエラーになったSQLを貼り付け、「どこが間違っていますか？」と聞けば、問題点を指摘し、修正案を提示してくれます。

さらに、これまでSQLの専門知識がなかったビジネスユーザー（マーケターや営業など）でも、自然言語でAIに質問することで、データベースから直接インサイトを得られるようになります。これにより、組織全体のデータ活用レベルが向上し、より迅速な意思決定が可能になります。

生成AIで警戒すべき点と、それでもSQLを学ぶべき理由

AIは万能の魔法の杖ではありません。現状では無視できない課題や限界も存在し、それこそが、私たちがSQLスキルを磨き続けるべき理由となります。

AIは平気で「嘘」をつく（ハルシネーション）

AIが生成するSQLは、常に100%正しいとは限りません。存在しないテーブル名や列名を指定したり、JOINの条件を間違えたりと、一見もっともらしいが実際には動かない、あるいは意図しない結果を返すコードを生成することがあります（これをハルシネーションと呼びます）。

生成されたSQLが本当に正しいか、意図通りかを最終的に判断し、責任を負うのは、AIではなく人間です。 この判断を下すためには、SQLの基本的な知識が不可欠です。つまり、あなたがSQLを学ばなくてもいい理由にはならないし、学ぶことで得られるリターンも増えるのです。

複雑な業務ロジックの壁

「先月の売上トップ5の営業担当者」のような単純なクエリは得意でも、「キャンペーンAとBの両方に参加し、かつ商品Cを購入したが、メルマガDは購読していない顧客」といった、ビジネス特有の複雑な条件が絡み合うクエリになると、AIの精度は途端に落ちる場合があります。

複雑な業務要件を正確に理解し、それをSQLという論理的な言語に翻訳する能力は、依然として人間に求められる高度なスキルです。そして、それをAI活用に活かすのも人間に求められる高度なスキルです。

パフォーマンスとセキュリティへの配慮

AIは、とりあえず動くSQLを生成することは得意ですが、それが数百万、数千万件のデータに対しても効率的に動作する「パフォーマンスの良い」クエリであるとは限りません。非効率なクエリは、データベースに過剰な負荷をかけ、システム全体のパフォーマンスを低下させる可能性があります。

また、外部からの入力をそのままSQLに組み込むようなコードをAIが生成した場合、SQLインジェクションといった深刻なセキュリティ脆弱性の原因にもなり得ます。

生成されたコードを鵜呑みにせず、パフォーマンスやセキュリティの観点からレビューし、修正する能力が必須となります。

AI時代のSQLエンジニアの生存戦略

これからの時代、SQLを扱う私たちに求められるのは、「SQLを書ける」というスキルから、「SQLを使いこなせる」というスキルへのシフトです。

AIの「副操縦士」になる: AIを、自分の思考を加速させるためのアシスタントとして積極的に活用しましょう。単純なクエリ作成はAIに任せ、自分はより高度な要件定義、AIが生成したコードのレビュー、そして最終的な分析に集中します。
SQLの「原理原則」を深く理解する: JOINやインデックスがデータベースの内部でどのように動作しているか、実行計画をどう読むかといった、パフォーマンスに直結する深い知識の価値は、むしろ高まります。AIが生成した非効率なクエリを改善できるスキルは、大きな差別化要因となります。
「問いを立てる力」を磨く: AIは与えられた問いに答えることはできますが、「ビジネスを成長させるためには、そもそも何を分析すべきか？」という、本質的な「問い」を立てることはできません。ビジネスの課題を理解し、それをデータ分析の問いに落とし込み、AIに的確な指示を与える能力が、最も重要なスキルになります。

結論

生成AIの登場によって、SQLの学習が無駄になることは決してありません。むしろ、AIという強力なツールを使いこなし、その限界を補うための、より深く、より本質的なSQLスキルが求められる時代になったと言えるでしょう。

逆を言うと、SQLを書くことだけを生業にしてきた人たちはリスキリングすべきタイミングでもあります。仕事というのは時代とともに、流行り廃りがくるものです

SQLは、これからもデータと対話するための普遍的な言語であり続けます。このガイドで得た知識を土台とし、AIの波を乗りこなしながら、データの世界で活躍されることを心から願っています。

関連記事

合格対策Salesforce認定アドミニストレーター資格試験テキスト&問題集

2025-10-02

SalesforceのExperience Cloudで使えるライセンスについて解説しますーーー！

Salesforce効率化

ライセンスのメンバーシップベース
ライセンスモデルの選定ケース
コスト最適化と将来の戦略
まとめ

ライセンスのメンバーシップベース

はじめに

Salesforce Experience Cloudは、顧客、パートナー、従業員と繋がるための強力なプラットフォームです。しかし、その真価を最大限に引き出すには、適切なライセンスモデルの選択が不可欠です。特に外部ユーザー向けのライセンスは、コストとユーザー体験に直結する重要な要素となります。

今回は外部ユーザ向けのExperience Cloudのライセンス、特に「メンバーシップベース」と「ログインベース」の違いについてご紹介します。

大まかな違いは下記の通りです。 1. メンバーシップベース（Member-Based）: ユーザー数に応じて課金 2. ログインベース（Login-Based）: 月々のログイン回数に応じて課金

メンバーシップベースライセンス

メンバーシップベースライセンスは、最もシンプルで分かりやすいモデルです。課金モデルは「ユーザー1人あたり月額いくら」という形式で課金されます。ライセンスを割り当てられたユーザーは、その月に何度でもログインすることが可能です。

例： Customer Communityライセンスを100ユーザー分購入した場合、100人がそれぞれ月に何回ログインしても、料金は一定です。

メリット

コストが予測可能: ユーザー数が固定されていれば、毎月の費用が安定します。予算管理が容易になる点は大きな利点です。
アクティブユーザーに最適: 毎日、あるいは頻繁にログインするユーザーが多いコミュニティに適しています。ログイン回数を気にする必要がありません。

デメリット

非アクティブユーザーには割高: たまにしかログインしないユーザーが多い場合、コスト効率が悪化します。例えば、月に一度しかログインしないユーザーにも、毎日ログインするユーザーと同じ費用がかかります。
大規模なBtoCには不向きな場合も: 不特定多数のユーザーがたまに利用するような大規模な消費者向けサイトの場合、ユーザー数ベースの課金は莫大なコストにつながる可能性があります。

ログインベースライセンス

ログインベースライセンスは、ユーザー数ではなく、月々の合計ログイン回数に基づいて課金されるモデルです。

課金モデルは毎月利用できる「ログイン回数の枠」を購入します。例えば、「月間1,000ログイン」という枠を購入した場合、その月の合計ログイン数が1,000回に達するまでサービスを利用できます。

メリット

低頻度アクセスの大規模ユーザーに強い: たまにしかログインしないユーザーが大多数を占めるコミュニティにおいて、非常に高いコスト効率を実現します。
スケーラビリティ: ユーザー数の増加に対して、ライセンスコストが比例して増加するわけではないため、ビジネスの成長に合わせて柔軟にスケールさせやすいです。

デメリット

コスト予測の難しさ: 利用状況が急増すると、月の途中でログイン枠を使い切り、追加のログインパックを購入する必要が出てくる場合があります。コストが変動しやすく、予算管理が難しくなる可能性があります。
超過料金のリスク: ログイン枠を超過した場合、割高な超過料金が発生する可能性があります。

ログイン数の考え方

ログインベースライセンスを検討する上で、最も重要なのが「ログインがどのようにカウントされるか」です。

まず「1人のユーザーが、同日中に何回ログインしても、カウントは『1』となる」です

これが基本ルールです。同じユーザーがログアウトして再度ログインしても、同日中であるなら新たなログインとしてはカウントしません。これを30日毎日ログインした場合は、カウントは『30』となります。

具体例で理解する

ケース1：同日中に複数回ログイン

あるユーザーが、月曜日の午前9時にログインしました。（→ ここで1カウント）
同じユーザーが、同日の午後3時に再度ログインしました。（→ カウントは増えない）
結果： このユーザーのログイン数は「1」です。

ケース2：日をまたいでログイン

あるユーザーが、月曜日の午後11時にログインしました。（→ ここで1カウント）
同じユーザーが、火曜日の午前1時に再度ログインしました。（→ 月曜23時のログインから24時間経過していないため、カウントは増えない）
同じユーザーが、火曜日の午後11時半に再度ログインしました。（→ 月曜23時のログインから24時間以上経過しているため、ここで新たに1カウント）
結果： このユーザーのログイン数は合計で「2」です。

このルールを理解することで、自社のユーザーの利用パターンから、より正確に必要なログイン数を予測することができます。

ライセンスモデルの選定ケース

1. ユーザーの利用頻度

高頻度（毎日、週に数回）: ユーザーが日常的にアクセスする場合、ログイン回数を気にする必要のないメンバーシップベースが適しています。コストが安定し、ユーザーエンゲージメントを阻害しません。
低頻度（月に数回、数ヶ月に1回）: ユーザーのアクセスが散発的である場合、ログインベースが圧倒的にコスト効率で優位です。

2. ユーザーベースの規模と性質

少数・特定: パートナーや特定の法人顧客など、ユーザーが限定的で身元が明確な場合は、メンバーシップベースが管理しやすく適しています。
多数・不特定: 一般消費者向けサービスなど、ユーザーベースが非常に大きく、今後も拡大が見込まれる場合は、ログインベースがスケーラビリティの面で有利です。

3. コストの予測可能性

予算の安定性を重視: 毎月のコストを固定し、予算管理を容易にしたい場合は、メンバーシップベースが最適です。
コスト効率を最優先: 多少のコスト変動リスクを受け入れてでも、トータルコストを最小限に抑えたい場合は、ログインベースが魅力的な選択肢となります。

比較サマリー表

観点	メンバーシップベース	ログインベース
課金単位	ユーザー数（/人・月）	ログイン回数（/回・月）
コスト予測	容易・安定的	難しい・変動的
得意な利用頻度	高頻度	低頻度
得意なユーザー規模	小〜中規模	大規模
主なメリット	予算管理が楽、アクティブユーザーに最適	コスト効率、スケーラビリティ
主なデメリット	非アクティブユーザーには割高	利用急増時の超過リスク

コスト最適化と将来の戦略

ライセンスを選択して終わりではありません。継続的なモニタリングと最適化が重要です。

1. ログイン履歴の監視

Salesforceの標準機能であるレポートとダッシュボードを活用し、月々のログイン数を定期的に監視しましょう。

2. ライセンスタイプの見直し

ビジネスの成長やユーザーの利用パターンの変化に応じて、ライセンスモデルを見直す柔軟性を持ちましょう。

3. 将来の成長予測

現在の利用傾向を基に、半年後、1年後のユーザー数やログイン数を予測し、事前にライセンスの追加購入やプラン変更を計画して、予算超過を防ぎましょう。

まとめ

メンバーシップベースは「深いつながりを持つ特定のユーザー」に、ログインベースは「広いつながりを持つ不特定のユーザー」に適しています。
ログインベースの「1ユーザー/24時間/1カウント」というルールは、正確なコスト試算のために必ず理解しておくべきです。
一度選んだら終わりではなく、継続的な監視と見直しを通じて、常に最適な状態を維持することが求められます。

本記事があなたのExperience Cloud活用を成功に導く一助となれば幸いです。

Salesforceで頑張りたいあなたへおすすめの本

成果を生み出すためのSalesforce運用ガイド

関連記事

エクスペリエンスクラウドの関連記事

そのほかSalesforce関係！

2025-09-25

フリーランスとして現場に出てから思ったこと

フリーランス日記

おはこんばんにちわ〜

フリーランスとして働き始めて、もうすぐ一カ月になります。

フリーランスとして働いてきたことで、会社員の頃には気づくことができなかった、いくつかのことに気づかされました。

つまり「想像とは違った現実」がそこにはありました。

まず一番に感じたのは、自分の価値が直接的に数字や成果に結びつくことの面白さと厳しさです。

会社員時代は、良くも悪くも組織という枠の中で守られており、システム化された評価ルールなどさいあくパフォーマンスが微妙でも収入を得られる安心感がありましたが、フリーランスは良くも悪くもすべてが自己責任で超絶シビアなパフォーマンス評価をされることになります。

自分のスキルが通用しなければ仕事は途絶えますし、良いパフォーマンスを出せば次の仕事につながります。このシビアな関係が、プロとしての意識をさらに高めてくれると感じました。

ポジショントークや結果論かもしれませんが、現在会社員してて出世や昇給と縁がなさそうな状態でまだ若手であるならば、一度独立して自分を鍛え直そうという気持ちを持ってみるのもありだと思います。

※安易にマネしゃちゃダメだぞ？

次に、人との繋がりが想像以上に大切だということです。

フリーランスは一人で働くイメージが強いかもしれませんが、実際にはクライアントや他のフリーランス、エージェントなど、多くの人と関わりながら仕事を進めます。

信頼関係を築くことで、質の高い仕事につながったり、新しい仕事を紹介してもらったりする機会も増えるのだと感じました。会社員であっても同じであるとは思いますが。。。

あえていうと

一つ一つの仕事に真摯に向き合うことで生まれる信頼こそが、一番の財産である

だと実感しました。

最後は、時間の使い方がすべて自分の裁量に委ねられることです。

これはフリーランスの大きなメリットであり、同時に難しい点でもあります。

納期やタスクの管理、休憩の取り方まで、すべて自分で決めなければなりません。

最初は戸惑うことも多かったですが、今では自分に合った働き方を見つけ、効率よく仕事を進められるようになりましたし、個人のスキルアップの時間等は会社員の頃は「これじゃぁ仕事じゃん」とずっと思っておりましたが、今では「これも仕事のうち🎵」と気持ちも大きく切り替わって前よりも前向きになれたと思います。

ということで、プライベートと仕事のバランスを自分でコントロールできるようになったことで、より充実した日々を送れています。自分の働き方や生き方について深く考えるようになりました。

これからも日々成長しながら、自分らしいキャリアを築いていきたいと思います。

他の日記はこちらから！

合格対策Salesforce認定アドミニストレーター資格試験テキスト&問題集

ーーーーーー

よければなコーナー

カラー版マンガでわかる個人事業の始め方

世界一やさしいフリーランスの教科書 1年生

2025-09-24

Experience Cloudの主要機能とライセンスについて

Salesforce効率化

サイト構築の中核「エクスペリエンスビルダー」
Salesforce CRMとの強力なデータ連携機能
コンテンツ管理を効率化する「Salesforce CMS」
ライセンスの種類：誰が何をするかで選ぶ
課金モデル：メンバーベース vs ログインベース

サイト構築の中核「エクスペリエンスビルダー」

エクスペリエンスビルダーは、Experience Cloudサイトの構築と管理を行うための中心的なツールです。直感的なUIで、コーディング不要で多くの操作が可能です。

コンポーネントベースの構築: ページは「コンポーネント」と呼ばれる部品を組み合わせて作成します。テキスト、画像、Salesforceのレコードリスト、レポート、ダッシュボードなど、様々な標準コンポーネントが用意されており、ドラッグ＆ドロップで自由に配置できます。
テーマとブランディング: サイト全体のデザイン（色、フォント、ロゴなど）を簡単にカスタマイズできます。数クリックでブランドイメージに合った外観に変更可能です。
ページ管理: 新規ページの作成、ページレイアウトの変更、プロパティの編集などを一元的に管理します。
オーディエンス設定: ユーザーの属性に応じて、特定のコンポーネントやページの表示/非表示を切り替えるパーソナライゼーション設定もこのビルダー上で行います。

Salesforce CRMとの強力なデータ連携機能

Experience Cloudの真価は、Salesforce CRMとのデータ連携にあります。

オブジェクトの直接参照: 取引先、商談、ケース、カスタムオブジェクトなど、Salesforce内のほぼ全てのオブジェクトデータをサイト上に表示できます。例えば、顧客がログインすれば、自身の問い合わせ履歴（ケース）一覧を表示させることができます。
リアルタイム同期: Experience Cloud上のデータはSalesforce CRMと常に同期しています。パートナーがポータルサイトで商談を更新すれば、その内容は即座に営業担当者のSalesforce画面にも反映されます。
共有設定の継承: Salesforceで設定されている共有ルールや権限設定がExperience Cloudにも適用されます。これにより、誰にどのレコードを見せるかを厳密にコントロールでき、セキュアな情報共有が実現します。

コンテンツ管理を効率化する「Salesforce CMS」

Salesforce CMSは、Experience Cloudサイト内外で利用するコンテンツ（テキスト、画像、動画、ドキュメントなど）を一元管理するための機能です。

コンテンツの再利用: 一度作成したコンテンツは、複数のExperience Cloudサイトや、Marketing Cloudのメール、Commerce CloudのECサイトなど、様々なチャネルで再利用できます。
パーソナライズ: コンテンツを特定のオーディエンス向けにパーソナライズして配信することが可能です。
ワークフローと承認プロセス: コンテンツの作成から承認、公開までのプロセスを管理し、コンテンツの品質を担保します。

ライセンスの種類：誰が何をするかで選ぶ

Experience Cloudのライセンスは、サイトにアクセスする「外部ユーザー」向けに提供され、その役割や必要な機能に応じて複数の種類があります。

ぶっちゃけここはかなりめんどくさい

Customer Community:
- 用途: 顧客向けのセルフサービスポータル（BtoC）が主な目的。
- 機能: ケース（問い合わせ）の作成・閲覧、ナレッジ記事の参照など。レポート＆ダッシュボードや高度な共有設定は利用不可。
- 例: FAQサイト、顧客フォーラム。
Customer Community Plus:
- 用途: より高度な権限管理やレポート機能が必要な顧客向けポータル（BtoC/BtoB）。
- 機能: Customer Communityの全機能に加え、レポート＆ダッシュボードの閲覧、役割や権限セットに基づく高度な共有設定が可能。
- 例: 代理店ポータル、会員制サイト。
Partner Community:
- 用途: パートナーとの協業（販売支援など）を目的としたポータル（B2B）。
- 機能: Customer Community Plusの全機能に加え、リード（見込み客）や商談オブジェクトへのアクセスが可能。
- 例: パートナーリレーションシップマネジメント（PRM）サイト。
External Apps:
- 用途: 非常に高度なカスタマイズや大量のカスタムオブジェクトを必要とする外部向けアプリケーション。
- 機能: 最も多くのカスタムオブジェクトを利用可能。外部データとの連携を多用する複雑なサイトに向いています。
- 例: ディーラーポータル、フランチャイズ管理システム。

課金モデル：メンバーベース vs ログインベース

上記のライセンスは、主に2つの課金モデルから選択できます。これにより、コストを最適化することが可能です。

メンバーベース (Member-Based):
- 概要: ユーザー一人ひとりに対してライセンスを割り当てるモデル。標準的なSalesforceライセンスと同じ考え方です。
- 適しているケース: 毎日、あるいは頻繁にサイトにアクセスする必要があるユーザー（例: パートナー企業の営業担当者、社内従業員）。
- コスト: ユーザー数に応じた月額または年額費用。
ログインベース (Login-Based):
- 概要: 毎月のログイン回数の合計を購入するモデル。一人のユーザーが同日内に複数回ログインしても、ログイン回数は1とカウントされます。
- 適しているケース: たまにしかサイトにアクセスしない不特定多数のユーザー（例: 製品購入後のユーザー登録、たまにサポート情報を確認する顧客）。
- コスト: 予想される月間ログイン回数に応じた費用。

ライセンス選択のポイント: どのライセンスと課金モデルの組み合わせが最適かは、「誰が」「どのくらいの頻度で」「何をするために」サイトを利用するのかによって決まります。導入前に入念な要件定義と利用シーンの想定を行うことが、コストの最適化と導入成功の鍵となります。

Salesforceで頑張りたいあなたへおすすめの本

成果を生み出すためのSalesforce運用ガイド

下記にSalesforce関係はいろいろあります！

2025-09-22

SQLは「慣れ」が9割

駆け出しテック

はじめに
なぜ「慣れ」が重要なのか？
実践力を鍛えるための具体的な練習方法
まとめ

はじめに

これまでにSQLの基本的な概念として. SELECT文に始まり、JOIN、GROUP BY、サブクエリと、多くの構文が登場しました。

しかし、これらの知識を本当に「使える」スキルにするためには、一つだけ欠けている要素があります。それは、圧倒的な「練習」です。

スポーツや楽器の演奏と同じように、SQLもルールを覚えただけでは上達しません。実際にたくさんのSQLを書き、エラーと格闘し、他人の書いたクエリを読み解く経験を通して、初めて血肉となるのです。この章のテーマは、まさに「SQLも結局は慣れ」という、学習における最も重要な真理です。

ここでは、SQLの実践力を飛躍的に高めるための具体的な練習方法と、役立つオンラインリソースを紹介します。

なぜ「慣れ」が重要なのか？

構文が体に染み付く: 何度も書くことで、SELECT ... FROM ... WHERE ...といった基本構造が、考えなくても自然に指から出てくるようになります。これにより、構文の細部ではなく、「何を取得したいか」というロジックの組み立てに集中できるようになります。
エラー解決能力が向上する: 初心者のうちは、エラーメッセージを見るだけで思考が停止しがちです。しかし、経験を積むと「Syntax errorならどこかのカンマが抜けているな」「Unknown columnなら列名のタイプミスか、JOINの指定が間違っているな」と、エラーの原因を推測し、迅速に解決できるようになります。この能力こそが、実務で最も役立つスキルの一つです。
クエリの「引き出し」が増える: 様々なパターンの問題を解くことで、「こういう集計をしたい時はGROUP BYとCASE式を組み合わせればいい」「この条件はサブクエリよりJOINの方が効率的だ」といった、クエリの組み立て方に関する多様な「引き出し」が自分の中に蓄積されていきます。

実践力を鍛えるための具体的な練習方法

ステップ1: 基本的なCRUDを反復練習する

まずは、これまでの章で学んだ基本的な構文を、何も見ずに書けるようになるまで反復します。オンラインのSQL実行環境（DB Fiddleなど）で、自分で簡単なテーブルを作成し、以下の操作を試してみましょう。

テーブル作成: CREATE TABLE
データ追加: INSERT
データ検索: SELECT (特定の条件で WHERE, 並べ替え ORDER BY)
データ更新: UPDATE (必ず WHERE をつける)
データ削除: DELETE (必ず WHERE をつける)

このサイクルを繰り返すだけで、SQLの基本操作に自信がつきます。

ステップ2: オンラインの練習問題サイトを活用する

自分で問題を作るのが大変だと感じたら、オンラインで公開されている練習問題サイトを積極的に活用しましょう。これらのサイトは、SQLを学ぶ多くの人々に利用されており、良質な問題が豊富に揃っています。

おすすめのSQL練習問題サイト: * SQLZOO (sqlzoo.net) * 古くからある定番サイト。基本からJOIN、サブクエリ、ウィンドウ関数まで、体系的に問題を解き進めることができます。日本語にも対応しています。

SQL Bolt (sqlbolt.com)
- 対話形式でSQLを学べるサイト。左側に問題、右側にエディタがあり、サクサクと問題を解いていくことができます。英語ですが、平易な文章なので挑戦しやすいです。
paizaスキルチェック (paiza.jp/works/mondai)
- プログラミング問題サイトですが、SQLに特化した問題も多数あります。「Dランク」の簡単な問題から始め、徐々に難易度を上げていくのがおすすめです。

ステップ3: 他人の書いたSQLを読んでみる

実務では、ゼロからSQLを書く場面だけでなく、既存のSQLを修正したり、機能を追加したりする場面も多くあります。そのため、他人の書いた（時には複雑で読みにくい）SQLを読み解く能力も非常に重要です。

GitHubで検索する: GitHubで「.sql」拡張子を持つファイルを検索し、実際のプロジェクトで使われているSQLを覗いてみましょう。
会社の同僚や先輩のコードを見る: もし職場にSQLを使う環境があれば、それが最高のお手本です。なぜこのような書き方をしているのか、自分ならどう書くかを考えてみると、学びが深まります。

まとめ

SQL上達の秘訣は、知識をインプットすること以上に、手を動かしてアウトプットすることにあります。

「習うより慣れろ」: SQLはスポーツや楽器と同じスキルである。
反復練習: 基本的な構文は、何も見ずに書けるレベルまで体に覚えさせる。
練習問題サイト: SQLZOOなどのオンラインリソースを積極的に活用し、多様な問題に触れる。
コードリーディング: 他人の書いたSQLを読むことで、実践的な書き方や思考プロセスを学ぶ。

関連記事

前回

2025-09-22

サブクエリとCASE式 - SQLをさらに強力にするテクニック

駆け出しテック

はじめに
サブクエリ: クエリの中のクエリ
- WHERE句でサブクエリを使う
- その他のサブクエリ
CASE式: クエリ内で条件分岐を実現する
- 基本構文

はじめに

これまでの章で学んだSELECT, JOIN, GROUP BYなどを組み合わせるだけでも、多くのデータ抽出や集計が可能です。

しかし、より複雑な条件や、一回のクエリでは取得が難しい情報に対処するには、もう一歩進んだテクニックが必要になります。

この章では、SQLをさらに強力で柔軟なものにするための2つの応用テクニックを紹介します。使いこなせばSQLで表現できることの幅が飛躍的に向上します。

サブクエリ (Subquery): クエリの中に、別のクエリを埋め込む方法。
CASE式 (CASE Expression): クエリ内で条件分岐を行い、結果を動的に変更する方法。

サブクエリ: クエリの中のクエリ

サブクエリ（副問い合わせとも呼ばれる）は、SELECT文やWHERE句など、別のSQL文の中に埋め込まれたSELECT文のことです。

サブクエリを使うことで、あるクエリの実行結果を、別のクエリの条件として利用することができます。

`WHERE`句でサブクエリを使う

最も一般的なサブクエリの使い方です。

課題: 全社員の平均年齢よりも年上の社員一覧を取得したい。

この課題は、2つのステップに分解できます。 1. まず、全社員の平均年齢を計算する。 2. 次に、その平均年齢を条件として、社員情報を取得する。

これをサブクエリで1つのSQL文にまとめると、以下のようになります。

【サンプルテーブル: employees】

id	name	age
1	鈴木一郎	45
2	佐藤花子	28
3	高橋健太	35
4	田中由美	32

実行例:

SELECT name, age
FROM employees
WHERE age > (SELECT AVG(age) FROM employees);

サブクエリの動作イメージ: 1. まず、括弧内のサブクエリ (SELECT AVG(age) FROM employees) が実行されます。この結果、平均年齢である 35.0 という単一の値が返されます。 2. 次に、メインのクエリが、サブクエリの結果を使って以下のように解釈されます。 sql SELECT name, age FROM employees WHERE age > 35.0; 3. 最終的な結果が返されます。

実行結果:

name	age
鈴木一郎	45

その他のサブクエリ

サブクエリはWHERE句以外にも、SELECT句やFROM句の中でも使用でき、それぞれスカラ・サブクエリ、インライン・ビューなどと呼ばれます。これらは複雑になりがちですが、使いこなせると非常に強力です。

`CASE`式: クエリ内で条件分岐を実現する

CASE式を使うと、SELECT句の中などで、条件に応じた値を返すことができます。プログラミング言語におけるif-then-else文のような機能を提供します。

基本構文

CASE
  WHEN 条件1 THEN 結果1
  WHEN 条件2 THEN 結果2
  ...
  ELSE デフォルトの結果
END

課題: 社員の年齢に応じて、年代を分類して表示したい。 * 30歳未満: '若手' * 30歳以上、40歳未満: '中堅' * 40歳以上: 'ベテラン'

実行例:

SELECT
  name,
  age,
  CASE
    WHEN age < 30 THEN '若手'
    WHEN age >= 30 AND age < 40 THEN '中堅'
    ELSE 'ベテラン'
  END AS age_group
FROM
  employees;

CASE式の動作イメージ: employeesテーブルの各行に対して、age列の値を上から順にWHEN句の条件で評価します。 * 佐藤花子 (age: 28): age < 30 が真なので '若手' を返す。 * 高橋健太 (age: 35): age < 30 は偽。次の age >= 30 AND age < 40 が真なので '中堅' を返す。 * 鈴木一郎 (age: 45): 上の2つの条件が偽なので、ELSE句の 'ベテラン' を返す。

実行結果:

name	age	age_group
鈴木一郎	45	ベテラン
佐藤花子	28	若手
高橋健太	35	中堅
田中由美	32	中堅

CASE式は、データのラベリング、集計時のカテゴリ分けなど、データ分析の現場で非常に頻繁に使われる便利な機能です。

これらの構文をマスターすることで、あなたはより複雑なビジネス要件にもSQLで応えられるようになります。最初は難しく感じるかもしれませんが、まずは簡単な例から真似て書いてみることが上達への一番の近道です。

関連記事

前回 soe-irony.hateblo.jp

2025-09-18

集計とグループ化 - GROUP BYと集計関数を使いこなす

駆け出しテック

第六章: 集計とグループ化 - GROUP BYと集計関数を使いこなす

第六章: 集計とグループ化 - GROUP BYと集計関数を使いこなす

はじめに

これまでの章で、データベースから特定のデータを取り出したり、複数のテーブルを結合したりする方法を学びました。これらは、個々のデータ（レコード）に注目した操作でした。

しかし、ビジネスの現場では、「全社員の数は何人？」「部署ごとの平均年齢は？」「商品カテゴリ別の売上合計は？」といった、データを要約・集計した情報が必要になる場面が非常に多くあります。

このようなデータの集計を行うために使われるのが、集計関数とGROUP BY句です。この2つを組み合わせることで、単なるデータの羅列から、意味のある洞察を引き出す「データ分析」への扉が開かれます。

集計関数とは？

集計関数は、その名の通り、複数の行にまたがる値のセットを一つの値に集計するための関数です。

主要な集計関数

関数名	説明
`COUNT()`	行の数を数える
`SUM()`	数値の合計を計算する
`AVG()`	数値の平均を計算する
`MAX()`	最大値を求める
`MIN()`	最小値を求める

`COUNT()`: 行数を数える

COUNT(*)とすると、テーブルの全行数を数えることができます。

【サンプルテーブル: employees】

id	name	department	age	salary
1	鈴木一郎	営業部	45	600
2	佐藤花子	開発部	28	450
3	高橋健太	開発部	35	550
4	田中由美	営業部	32	500
5	渡辺徹	人事部	40	580

実行例: 社員の総数を取得する

SELECT COUNT(*)
FROM employees;

実行結果: | COUNT(*) | |---| | 5 |

`SUM()`, `AVG()`, `MAX()`, `MIN()`

これらの関数は、数値型の列に対して使用します。

実行例: 全社員の給与（salary）の合計、平均、最高、最低を一度に計算する

SELECT
  SUM(salary),
  AVG(salary),
  MAX(salary),
  MIN(salary)
FROM employees;

実行結果: | SUM(salary) | AVG(salary) | MAX(salary) | MIN(salary) | |---|---|---|---| | 2680 | 536.0000 | 600 | 450 |

ポイント: SELECT句でASを使うと、結果の列に別名をつけることができます。 SELECT COUNT(*) AS employee_count FROM employees;

`GROUP BY`句: データをグループ化する

集計関数はテーブル全体に対して機能しますが、「部署ごとに」「商品カテゴリごとに」といった、特定のグループに分けて集計したい場合にGROUP BY句を使います。

基本構文

SELECT 列名, 集計関数(列名)
FROM テーブル名
GROUP BY グループ化する列名;

GROUP BY句で指定された列の値が同じ行が、一つのグループとしてまとめられ、そのグループごとに集計関数が適用されます。

実行例: 部署（department）ごとの社員数と平均年齢を計算する

SELECT
  department,
  COUNT(*) AS number_of_employees,
  AVG(age) AS average_age
FROM
  employees
GROUP BY
  department;

GROUP BYの動作イメージ: 1. GROUP BY departmentの指示に基づき、department列の値が同じ行をグループに分ける。（「営業部」グループ、「開発部」グループ、「人事部」グループができる） 2. 各グループに対して、SELECT句で指定された集計関数（COUNT(*)とAVG(age)）をそれぞれ計算する。 3. グループの値（部署名）と、その集計結果を返す。

実行結果: | department | number_of_employees | average_age | |---|---|---| | 営業部 | 2 | 38.5000 | | 開発部 | 2 | 31.5000 | | 人事部 | 1 | 40.0000 |

`HAVING`句: グループ化した結果を絞り込む

WHERE句は、グループ化される前の個々の行に対して条件を指定するのに対し、HAVING句は、GROUP BYでグループ化された後の結果に対して条件を指定します。

基本構文

SELECT ...
FROM ...
GROUP BY ...
HAVING グループに対する条件式;

HAVING句には、集計関数を使った条件式を書くことができます。

実行例: 社員が2名以上いる部署だけを表示する WHERE句ではCOUNT(*)のような集計結果を条件にできないため、HAVING句を使います。

SELECT
  department,
  COUNT(*) AS number_of_employees
FROM
  employees
GROUP BY
  department
HAVING
  COUNT(*) >= 2;

実行結果: | department | number_of_employees | |---|---| | 営業部 | 2 | | 開発部 | 2 |

まとめ

この章では、データを集計し、分析するための強力なツールを学びました。

集計関数 (COUNT, SUM, AVGなど): データのセットを一つの値に要約する。
GROUP BY句: データを特定のグループに分け、グループごとに集計する。
HAVING句: グループ化した後の結果に対して、さらに条件を指定して絞り込む。

GROUP BYを使いこなせるようになると、単なるデータ取得から一歩進んで、データから傾向やパターンを読み解く「データ分析」が可能になります。

次の章では、クエリの中にさらにクエリを記述する「サブクエリ」など、SQLをさらに強力にする応用テクニックについて学びます。

関連記事

前回

2025-09-18

JOIN句で複数テーブルを結合する - データの世界を広げる鍵

駆け出しテック

はじめに
なぜテーブルを分けるのか？
INNER JOIN: 内部結合
- 基本構文
LEFT JOIN: 左外部結合
- 基本構文
その他のJOIN
まとめ

はじめに

これまでの章で、単一のテーブルからデータを取得・操作する方法を学びました。しかし、実際のデータベースでは、データは複数のテーブルに分割して管理されています。これを正規化と呼び、データの重複をなくし、整合性を保つための重要な設計原則です。

例えば、「社員」の情報と「部署」の情報を1つの巨大なテーブルで管理すると、部署名が変わるたびに全社員のデータを更新する必要があり、非効率でミスも起きやすくなります。

そこで、「社員テーブル」と「部署テーブル」に分け、それぞれをIDで関連付けます。この関連付けられた複数のテーブルから、情報を組み合わせて取得するために使われるのがJOIN句です。

JOINは、SQL学習者がつまずきやすいポイントの一つですが、これをマスターすれば、扱えるデータの幅が格段に広がり、SQLの本当のパワーを実感できるでしょう。

なぜテーブルを分けるのか？

JOINを学ぶ前に、2つのサンプルテーブルを見てみましょう。

【employeesテーブル】

id	name	department_id
1	鈴木一郎	10
2	佐藤花子	20
3	高橋健太	20
4	田中由美	10

【departmentsテーブル】

id	name
10	営業部
20	開発部
30	人事部

employeesテーブルには、部署名そのものではなく、部署IDであるdepartment_idが格納されています。これにより、例えば「開発部」を「システム開発部」に名称変更したい場合、departmentsテーブルの1行を更新するだけで済みます。

しかし、このままでは「鈴木一郎さんの部署名は何？」という情報を得るのに不便です。そこでJOINの出番です。

`INNER JOIN`: 内部結合

INNER JOIN（内部結合）は、最もよく使われるJOINです。2つのテーブルに共通して存在するデータだけを結合します。

基本構文

SELECT テーブル1.列名, テーブル2.列名, ...
FROM テーブル1
INNER JOIN テーブル2 ON テーブル1.共通列 = テーブル2.共通列;

ON句: どの列をキー（目印）にしてテーブルを結合するかを指定します。今回の例では employees.department_id と departments.id です。
テーブル名.列名: 複数のテーブルに同じ名前の列（例: id）が存在する場合があるため、どちらのテーブルの列かを明示します。

実行例: 社員名と、その社員が所属する部署名を取得する

SELECT
  employees.name,
  departments.name
FROM
  employees
INNER JOIN
  departments ON employees.department_id = departments.id;

INNER JOINの動作イメージ: 1. employeesテーブルの各行について、department_idを見る。（例: 鈴木一郎のdepartment_idは10） 2. ON句の条件 employees.department_id = departments.id に基づき、departmentsテーブルからidが10の行を探す。 3. departmentsテーブルでidが10の行が見つかる（nameは'営業部'）。 4. 2つのテーブルの情報を結合して1行のデータとして返す。

実行結果:

employees.name	departments.name
鈴木一郎	営業部
佐藤花子	開発部
高橋健太	開発部
田中由美	営業部

departmentsテーブルにある「人事部」は、employeesテーブルに所属する社員がいないため、結果に含まれていない点に注目してください。これがINNER JOINの特徴です。

`LEFT JOIN`: 左外部結合

LEFT JOIN（左外部結合）は、FROM句で指定した左側のテーブルのデータを全て残し、それに紐づく右側のテーブルのデータを結合します。

基本構文

SELECT ...
FROM テーブル1 -- 左側のテーブル
LEFT JOIN テーブル2 ON テーブル1.共通列 = テーブル2.共通列;

実行例: 全ての社員と、もし所属部署があればその部署名を取得する 仮に、employeesテーブルに部署が未定の社員（department_idがNULL）がいたとします。

【employeesテーブル（変更後）】

id	name	department_id
1	鈴木一郎	10
2	佐藤花子	20
5	新井優子	NULL

この状態でINNER JOINを使うと、department_idがNULLの新井さんは、departmentsテーブルに一致するidがないため、結果から漏れてしまいます。

しかし、LEFT JOINを使うと...

SELECT
  employees.name,
  departments.name
FROM
  employees
LEFT JOIN
  departments ON employees.department_id = departments.id;

実行結果:

employees.name	departments.name
鈴木一郎	営業部
佐藤花子	開発部
新井優子	NULL

このように、左側のemployeesテーブルのデータは全て表示され、対応する部署がなかった新井さんのdepartments.nameはNULL（空）として表示されます。「社員の一覧は必ず全員分欲しい」といった場合にLEFT JOINは非常に役立ちます。

その他のJOIN

RIGHT JOIN (右外部結合): LEFT JOINの逆で、右側のテーブルのデータを全て残します。実務ではLEFT JOINでテーブルの順序を入れ替えて書くことが多いため、使用頻度は低めです。
FULL OUTER JOIN (完全外部結合): 左右両方のテーブルのデータを全て残し、対応するデータがない場合はNULLで埋めます。

まとめ

この章では、複数のテーブルを結合するJOINについて学びました。

JOINは、正規化されたデータベースから意味のある情報を引き出すための必須テクニック。
INNER JOIN: 2つのテーブルの両方に存在するデータのみを結合する。（最もよく使う）
LEFT JOIN: 左側のテーブルのデータを全て残し、右側のデータを結合する。紐付かない場合はNULLになる。
ON句で、テーブル同士を繋ぐキーとなる列を指定する。

JOINを使いこなせるようになると、SQLでできることの幅が一気に広がります。最初は少し難しく感じるかもしれませんが、図を描いてテーブルの関係性を整理しながら、何度も練習してみてください。

次の章では、取得したデータを要約・分析するための集計関数とGROUP BY句について学びます。

関連記事

前回