SQLで文字列を数値に変換する方法を完全解説

SQLを使った開発やデータ分析の現場では、
「本来は数値として扱うべきデータが、なぜか文字列型で保存されている」
「集計しようとしたらエラーが出る」「WHERE句の条件が効かない」
といった悩みに一度は直面します。

実務では、外部システム連携・CSVインポート・古い設計のDBなどが原因で、数値データが文字列として保存されているケースは珍しくありません。そのまま放置すると、集計ミス・パフォーマンス劣化・障害の温床になります。

この記事では、

SQLで文字列を数値に変換する基本知識
CAST / CONVERT / TO_NUMBER の正しい使い分け
実務で頻発するエラーと回避策
ALTER TABLEによる安全な設計改善

までを体系的に解説します。

初心者が「なるほど」と理解でき、経験者が「現場で使える」と納得することをゴールにした完全版ガイドです。

SQLにおけるデータ型の基礎知識

SQLの主なデータ型と役割

SQLでは主に以下のようなデータ型が使われます。

文字列型（VARCHAR / CHAR / TEXT）
数値型（INT / BIGINT / DECIMAL / FLOAT）
日付・時刻型（DATE / DATETIME / TIMESTAMP）

この中でも、文字列型と数値型の混同はトラブルの原因になりやすいポイントです。

なぜ文字列のままでは問題なのか

文字列型のまま数値を扱うと、以下の問題が発生します。

大小比較が正しく行われない

（例：'100' < '20' が成立してしまう）
SUM / AVG などの集計関数が使えない
WHERE句でインデックスが効かない
想定外の変換エラーが本番で発生する

そのため、適切なタイミングで数値型へ変換する設計・実装が極めて重要です。

文字列を数値に変換する必要性とメリット

数値型へ変換するメリット

文字列を数値に変換することで、以下の恩恵があります。

四則演算・集計処理が正確に行える
ソート・比較が直感通りに動作する
クエリの可読性・保守性が向上する
データ品質と信頼性が高まる

特に分析・レポーティング用途では、数値型であることが前提条件になるケースがほとんどです。

CAST関数による文字列→数値変換（標準SQL）

CAST関数とは

CASTはSQL標準で定義されたデータ型変換関数で、
MySQL / PostgreSQL / SQL Server / Oracle など多くのRDBMSで利用できます。

移植性を重視する場合の第一選択肢です。

CASTの基本構文

CAST(変換対象 AS 変換後のデータ型)

使用例

SELECT CAST('10.5' AS DECIMAL(5,2));

CASTで注意すべきポイント

数値として解釈できない文字列はエラーになる
NULLはNULLのまま返る
RDBMSによって細かな挙動差がある

CAST使用時によくあるエラーと対処法

変換エラーが起きる典型例

英字や記号が混入している

（例：'10a', '1,000'）
空文字が含まれている
想定外の小数点・符号

エラー回避の実務テクニック

SQL Serverの場合

TRY_CAST(column_name AS INT)

→ 変換不可の場合はNULLを返す

事前チェックの例

CASE
WHEN column_name ~ '^[0-9]+$' THEN CAST(column_name AS INT)
ELSE NULL
END

CONVERT関数（SQL Server特有）

CONVERT関数の特徴

CONVERTはSQL Server専用の変換関数で、
CASTよりも書式指定や制御が細かい点が特徴です。

基本構文

CONVERT(変換後の型, 変換対象)

使用例

SELECT CONVERT(DECIMAL(5,2), '100.25');

TRY_CONVERTによる安全な変換

SELECT TRY_CONVERT(INT, 'abc'); -- NULLが返る

大量データやバッチ処理では、TRY_CONVERTの使用が強く推奨されます。

WHERE句で変換する際の注意点（重要）

パフォーマンス劣化の原因

WHERE CAST(column_name AS INT) > 100

このような書き方は、インデックスが使われない可能性があります。

実務的な回避策

可能な限り列の型を数値型にする
計算済み列（computed column）を使う
一時テーブルで事前変換する

「その場しのぎのCAST」は技術的負債になりやすい点に注意しましょう。

TO_NUMBER関数（Oracle）

Oracleでの文字列→数値変換

OracleではTO_NUMBERが実務でよく使われます。

TO_NUMBER(文字列, フォーマットマスク)

フォーマット指定の例

SELECT TO_NUMBER('1,234.56', '9,999.99') FROM dual;

NLS設定との関係

OracleではNLS_NUMERIC_CHARACTERSなどの設定が影響するため、

公式ドキュメントの確認が重要です。

参考：Oracle公式ドキュメント：https://docs.oracle.com/

ALTER TABLEによるデータ型変更（設計改善）

なぜALTER TABLEが重要なのか

クエリ上で毎回変換するよりも、

テーブル設計そのものを正す方が根本的な解決になります。

基本構文（例：MySQL）

ALTER TABLE sample_table
MODIFY column_name INT;

安全に変更するための手順

必ずバックアップを取得
不正データを事前に洗い出す
テスト環境で検証
メンテナンス時間を確保して実行

特に大規模テーブルでは、ダウンタイムとロックに注意が必要です。

よくある失敗と実務的な教訓

「とりあえずCAST」で本番障害
WHERE句の変換で性能劣化
フォーマット混在データの放置
設計改善を後回しにして技術的負債化

文字列→数値変換は、SQL力と設計力が試されるポイントです。

まとめ：文字列変換を制する者がSQLを制す

本記事では、SQLで文字列を数値に変換する方法を、

基礎から実務・設計改善まで網羅的に解説しました。

標準的にはCASTを使う
SQL ServerならCONVERT / TRY_CONVERT
OracleならTO_NUMBER
最終的にはテーブル設計を見直すことが最重要

この記事の内容を理解できた方は、
単なるSQL操作ではなく「データをどう設計・運用するか」
という一段上の視点を身につけ始めています。

技術を深く理解し、実務で活かしたいあなたへ

私たちは、SQLやデータベース設計といった基礎技術を本質から理解し、実務で使いこなせるエンジニアを大切にするチームです。

今回のような
「なぜエラーが起きるのか」
「どう設計すべきか」
を考える姿勢は、現場で本当に価値があります。

もし、

技術をもっと深く理解したい
データに強いエンジニアとして成長したい
同じ志向を持つ仲間と働きたい

そう感じたなら、ぜひ私たちの採用情報も覗いてみてください。
あなたの知的好奇心と技術力が、次のステージで活きるかもしれません。