SQLだけで半角⇔全角変換する方法（Oracle/SQL Server/PostgreSQLの実例つき）

半角⇔全角変換SQLが必要になる理由

半角と全角の混在は見た目が近くても別文字として扱われます。

データベースは文字コード上の差を厳密に区別するため同値判定がずれます。

表示上は同じに見えるのに一致しない現象は現場で最も時間を奪います。

ユーザー入力の自由度が高いほど入力時点での揺れは避けにくいです。

入力フォームやCSV取込など経路が増えるほど表記ゆれは起きやすくなります。

ETLやDWH連携が入ると文字種の混在が見えづらくなります。

システム移行や外部連携で文字種が混ざると後からの修正が重くなります。

社内システムとSaaSをつなぐと変換規約が分散して追跡が難しくなります。

取込元が複数あるならまず入口での正規化方針を整理します。

表記ゆれを放置すると検索条件にヒットしない事故が発生します。

LIKE検索でも全角と半角が混在すると想定外に漏れることがあります。

正規表現検索を使っても対象文字種が想定と違うと期待値が外れます。

検索の漏れは利用者の信頼を落とし問い合わせが増えます。

JOINキーが揺れると同一人物や同一商品が別レコードとして扱われます。

マスタ結合の漏れが発生すると売上や在庫など下流の数値が崩れます。

外部キーに相当する列で揺れると整合性チェックも機能しにくいです。

集計でも同じカテゴリが分割されて数値が合わなくなります。

グルーピング結果が分裂すると担当者の手修正が恒常化します。

二重計上や欠落が起きると原因調査に時間を奪われます。

原因が文字種だと気づくまでが長いので最初に疑う視点が重要です。

この手の揺れはアプリ側で統一するのが理想ですがDB内に既に混在している場面ではSQLだけで整える需要があります。

既存データの是正はアプリ改修を待たずに進めたい場面が多いです。

運用フェーズではバッチや一括更新でデータを揃える場面が多いです。

データ品質の改善は段階的に進める方が安全です。

変換前後で件数と差分を計測して数値で管理すると失敗しにくいです。

まず結論：DBMS別にできること／難しいこと

英数字の半角⇔全角は多くのDBMSで比較的扱いやすいです。

英数字は一対一の対応表を作りやすく検証もしやすいです。

英数字の統一は住所や型番など多くの列で共通の効果があります。

英数字は全角と半角で長さは同じでも見た目と入力が変わります。

一方でカナの半角⇔全角は濁点や半濁点が絡むためDBMS差が出やすいです。

カナは合成文字や互換文字が絡むため同じ見た目でも内部表現が揺れます。

ひらがなとカタカナの変換は別問題として扱う方が混乱が減ります。

半角カナは扱いを誤ると濁点だけが残るような不正データを生みます。

スペースの統一はSQLで実務対応しやすい部類に入ります。

ただし全角スペースが混在するとトリムの挙動と合わせて確認が必要です。

タブや改行など不可視文字が混ざる場合は別途検出が必要です。

不可視文字は見た目では気づけないので検出クエリが役立ちます。

反対に記号類は対応表の設計次第で抜け漏れが起きやすいです。

全角ハイフンや長音などは似た文字が多く置換方針を決める必要があります。

郵便番号のハイフンや電話番号の記号は列ごとに基準を分ける方が堅実です。

記号を全部統一しようとすると人名や製品名で想定外の変化が起きます。

本記事はOracleとSQL ServerとPostgreSQLを中心にSQLだけで書ける範囲を示します。

MySQLは補足として限定例に留めて現実的な線引きを示します。

DBMSの機能で難しい箇所は無理に万能化せず限界と代替策まで含めて整理します。

最初に対象文字種を決めて必要十分な変換に絞るのが成功しやすいです。

全列を一気に正規化するよりも重要なキー列から進める方が効果が大きいです。

正規化は更新と検索のどちらを主戦場にするかで設計が変わります。

英数字・記号・スペースの可否

英数字は対応表を作れば一括変換しやすいです。

数字だけ先に揃えると検証が楽になり作業も分割できます。

アルファベットは大小統一も合わせて検討すると検索条件が簡単になります。

大小統一は半角全角の問題とは別なので手順を分けて管理します。

記号は必要な文字だけを対象にする方が安全です。

例えばハイフンだけ統一するなど範囲を絞ると事故が減ります。

全角チルダやダッシュなどは利用実態を調べてから方針を決めます。

記号は似た字形が多いので一覧化して合意を取ると揉めません。

スペースは半角スペースと全角スペースの置換で統一できます。

前後スペースの削除はREPLACEとTRIMの組み合わせで段階的に行います。

スペース統一は画面表示よりも比較条件の安定化に効きます。

スペースの正規化は住所のような自由入力列で特に効果があります。

カナ（濁点/半濁点含む）の可否

カナは単純な一対一置換では濁点付きの扱いが崩れることがあります。

半角カナは濁点が別文字として後置される場合があります。

この差があると見た目が同じでも一致判定が外れることがあります。

さらにUnicode正規化の影響で別の同等文字に見えることがあります。

そのためDBMS標準の変換に頼るかアプリ側の正規化と組み合わせる判断が必要です。

運用上は入力段階でカナを統一してDB内では英数字のみを整える方が安定しやすいです。

カナを扱う場合は事前に対象列と用途を必ず確認します。

テストには濁点付きと半濁点付きと長音を必ず含めます。

Oracleでの半角⇔全角変換SQL（CONVERT / TRANSLATE）

Oracleは文字種の変換にCONVERTやTRANSLATEを組み合わせて使う発想が基本です。

Oracleは設定要素が多いため環境差を前提に手順を組みます。

文字セットやNLS設定の影響もあるため最初に前提を押さえます。

まずは英数字の統一から作り込みます。

英数字が揃うだけでも検索やJOINの事故が大きく減ります。

次に必要に応じてカナを扱います。

カナは期待通りにならない可能性を前提に検証手順を用意します。

最後にNLS設定や文字コードが結果に影響する点を確認します。

環境差は本番相当で確認しないと後で再発しやすいです。

変換前後で差分件数を確認するチェックSQLを作っておくと安心です。

変換対象を抽出するために正規表現やLENGTH差分を使うこともあります。

半角→全角（英数字）

英数字を全角へ寄せたい場合は対応表を使ったTRANSLATEが分かりやすいです。

TRANSLATE(列,’0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz’,’０１２３４５６７８９ＡＢＣＤＥＦＧＨＩＪＫＬＭＮＯＰＱＲＳＴＵＶＷＸＹＺａｂｃｄｅｆｇｈｉｊｋｌｍｎｏｐｑｒｓｔｕｖｗｘｙｚ’)

上記は数字と英字だけを対象にする例です。

対象外の文字は変換されずに残るので安全側の動きになります。

変換対象を増やす前に対象外文字が何かを調べると設計が楽になります。

記号まで含めるなら対象文字を明示して段階的に追加します。

追加時はテストケースを増やして変換漏れを確認します。

更新に使う場合はWHEREで対象行を絞ると負荷を抑えられます。

更新前に変換対象行をSELECTで確認してから実行すると事故を防げます。

UPDATE前にバックアップテーブルへ退避する運用も有効です。

更新後は変換前の値を保持する監査列があると追跡が簡単です。

全角→半角（英数字）

全角英数字を半角に戻す場合も同じ考え方で逆表を用意します。

TRANSLATE(列,’０１２３４５６７８９ＡＢＣＤＥＦＧＨＩＪＫＬＭＮＯＰＱＲＳＴＵＶＷＸＹＺａｂｃｄｅｆｇｈｉｊｋｌｍｎｏｐｑｒｓｔｕｖｗｘｙｚ’,’0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz’)

英字の大小を揃えたい場合はUPPERやLOWERも併用します。

変換と大小統一は目的が違うので段階を分けると事故が減ります。

検索に使う標準形を決めてから更新する方が運用が安定します。

標準形はドキュメントとテストに落としておくと長期運用で効きます。

標準形に揃えた後は入口で同じ規約を強制して再混入を防ぎます。

半角→全角（カナ）

半角カナを全角へ寄せたい需要は住所や氏名の管理で多いです。

Oracleの環境によってはCONVERTで期待通りにいかないケースがあります。

カナ変換をSQLだけで完結させたい場合は検証用のサンプル文字列を用意して結果を確認します。

ｱｲｳｴｵ と ｶﾞｷﾞｸﾞｹﾞｺﾞ を両方入れて確認します。

ﾊﾟﾋﾟﾌﾟﾍﾟﾎﾟ のような濁点付き文字を含めて確認します。

半角カナが混ざる列は事前に抽出して影響範囲を把握します。

どの列でカナを正規化するべきかは用途と検索条件で決めます。

カナを全面変換するよりも入力規約で全角に統一して以後は英数字だけをSQLで整える方が運用として安定する場合があります。

必要な文字だけを対象にして小さく始めるのが安全です。

変換後の表示崩れや外部連携への影響も合わせて確認します。

カナは例外処理が増えやすいので仕様を文章で残します。

文字コード/NLS設定と変換結果の差

変換結果はDB文字セットやNLS設定に依存します。

同じSQLでも環境が変わると一部文字が変換されないことがあります。

本番と同じNLS設定でテストすることが重要です。

検証環境だけで完了させると本番で再現しないバグになります。

移行やレプリケーションがある環境では双方の文字セットを先に確認します。

変換処理を行う側と参照する側で文字セットが違うと混乱が起きます。

ログ出力やエクスポート形式でも文字化けが出るため周辺も含めて確認します。

周辺システムの文字コード制約が変換方針を決めることもあります。

SQL Serverでの半角⇔全角変換SQL（TRANSLATE）

SQL ServerのTRANSLATEは一文字単位の対応表で置換します。

そのため対応表の作り方が品質を決めます。

英数字中心で確実に動く例を軸に説明します。

変換対象を増やすほど対応表の運用コストが上がります。

対応表はソースコードと同様にレビュー対象にするのが安全です。

対応表は列用途ごとに分けると意図が分かりやすいです。

半角→全角（英数字中心）

TRANSLATEは置換元文字列と置換先文字列の位置対応で変換します。

TRANSLATE(列,’0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz’,’０１２３４５６７８９ＡＢＣＤＥＦＧＨＩＪＫＬＭＮＯＰＱＲＳＴＵＶＷＸＹＺａｂｃｄｅｆｇｈｉｊｋｌｍｎｏｐｑｒｓｔｕｖｗｘｙｚ’)

対象外の文字はそのまま残るので安全側に倒れます。

変換できない文字は残るので後から検出しやすいです。

記号を混ぜると管理が難しくなるため必要な範囲だけを入れます。

列がNULLのときの扱いはCOALESCEで統一します。

NULLと空文字の扱いを先に決めておくと後工程で揉めません。

変換後の値に対して長さチェックやパターンチェックを追加すると安心です。

更新対象が多い場合は実行時間帯とロック戦略を先に決めます。

全角→半角（英数字中心）

逆変換では置換表を反転させます。

TRANSLATE(列,’０１２３４５６７８９ＡＢＣＤＥＦＧＨＩＪＫＬＭＮＯＰＱＲＳＴＵＶＷＸＹＺａｂｃｄｅｆｇｈｉｊｋｌｍｎｏｐｑｒｓｔｕｖｗｘｙｚ’,’0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz’)

更新で使う場合は一括UPDATEよりもバッチ分割の方がロックを避けやすいです。

更新件数が多い場合はトランザクションログの増加にも注意します。

変換後に想定外の文字が残るケースは事前に検出クエリを用意します。

変換前後の差分を確認するSELECTを作っておくと検証が速いです。

夜間バッチに組み込むならリトライ設計も考えておきます。

検出クエリは運用監視として定期実行して再混入を早期に拾います。

照合順序（Collation）と検索への影響

照合順序によって比較結果が変わることがあります。

特に大文字小文字の区別やアクセント感度は検索結果に影響します。

変換で統一しても照合順序が原因で一致しない場合がある点を覚えておきます。

照合順序を変える前に影響範囲を洗い出すのが安全です。

アプリ側の検索条件が照合順序を前提にしている場合もあります。

照合順序は列単位とDB単位で設定が違うことがある点に注意します。

PostgreSQLでの半角⇔全角変換SQL（translate関数）

PostgreSQLのtranslateはSQL ServerのTRANSLATEと同様に一対一の対応表で置換します。

英数字の統一には使いやすいです。

カナの全面変換はSQLだけで綺麗に完結しにくいことがあります。

変換結果が要求仕様を満たすかを先に確認してから採用します。

PostgreSQLは拡張機能の選択肢もあるため要件に応じて検討します。

拡張を使えない運用制約があるならSQLのみでの線引きを明確にします。

半角→全角（英数字中心）

translateは対象文字列に含まれる文字を対応表に従って置換します。

translate(col,’0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz’,’０１２３４５６７８９ＡＢＣＤＥＦＧＨＩＪＫＬＭＮＯＰＱＲＳＴＵＶＷＸＹＺａｂｃｄｅｆｇｈｉｊｋｌｍｎｏｐｑｒｓｔｕｖｗｘｙｚ’)

WHERE句で使うとインデックスが効きにくくなる可能性があります。

頻繁に検索するなら更新で正規化して保持する方が有利です。

正規化した値を別カラムに保持する設計も検討します。

更新と検索のどちらを重視するかで最適解が変わります。

部分一致検索が多い場合は正規化の効果が特に出やすいです。

表示用に変換するだけならSELECT時の一時変換で済むこともあります。

全角→半角（英数字中心）

逆方向も同様に反転表を使います。

translate(col,’０１２３４５６７８９ＡＢＣＤＥＦＧＨＩＪＫＬＭＮＯＰＱＲＳＴＵＶＷＸＹＺａｂｃｄｅｆｇｈｉｊｋｌｍｎｏｐｑｒｓｔｕｖｗｘｙｚ’,’0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz’)

変換表はテストデータとセットでバージョン管理すると安全です。

追加した文字の抜け漏れはサンプル一覧で検知します。

本番データから頻出文字を抽出して対応表を補強します。

検出クエリで未知の文字を洗い出してから対応表を更新します。

対応表の変更は互換性に影響するので変更履歴を残します。

拡張/正規化の選択肢

SQLだけで厳しい場合はアプリ側の正規化ライブラリを検討します。

Unicode正規化を含めると一致率が上がる場合があります。

DB側では取り込み時に統一して保持する戦略が性能面でも有利です。

検索用に生成列や関数インデックス相当の仕組みを使えるかをDBMSごとに確認します。

実装可否はバージョンや運用制約にも依存します。

監査要件がある場合は原本値と正規化値の両方を保持する設計も有効です。

原本値を残すと後から仕様変更が入っても再生成できます。

補足：MySQLでの半角⇔全角変換（REPLACEの現実解）

MySQLは一括の文字種変換がSQLだけでは難しい場面があります。

そのため限定対象に絞ったREPLACEの積み重ねが現実解になります。

本章は参考として最小限に扱います。

SQLだけで万能化しようとすると保守性が急に落ちます。

REPLACE連鎖はテストとレビューが弱いと変換漏れが残りやすいです。

REPLACE連鎖は実装者が変わると意図が伝わりにくいです。

半角→全角（数字の例）

数字だけを全角へ寄せるならREPLACEを連鎖させます。

REPLACE(REPLACE(REPLACE(col,’0′,’０’),’1′,’１’),’2′,’２’)

実務では0から9までを同様に積みます。

検証しやすいように変換前後の値を並べて確認します。

この方法は読みやすさが落ちるため対象が限定できるときだけ使います。

更新対象が多い場合は一時テーブルで段階更新する方が安全です。

対象列が複数ならビューで一時的に変換結果を提供する案もあります。

多文字種で破綻しやすい点と工夫

対象文字が増えるほどSQLが長くなり保守が難しくなります。

変換表を別テーブルで管理してアプリ側で生成する方が安全な場合があります。

SQLだけにこだわるなら対象を英数字やスペースに限定します。

更新よりも表示用の一時変換として使う方が適する場合もあります。

運用上は正規化済みの列を持つ設計の方が将来的に楽です。

大量更新を繰り返すよりも最初に規約を決めて再混入を止めます。

実務で使える半角⇔全角変換SQL：関数化例（Oracle）

同じ変換を複数箇所で使うなら関数化すると運用が楽になります。

呼び出し側のSQLが短くなりミスも減ります。

関数名は意図が分かる命名にします。

用途が増えるなら英数用とスペース用を分けると管理しやすいです。

テスト用の入力と期待値を合わせて管理します。

変更が入ったときに回帰確認ができるようにします。

関数は小さく保ち変換表の修正が安全にできる形にします。

関数にすべてを詰め込むと例外が増えて品質が下がります。

半角→全角

英数字の半角を全角にする関数はTRANSLATEの対応表を内部に持たせます。

入力がNULLのときはNULLを返す設計にします。

変換対象外の文字は変更しない方が事故が減ります。

対象外の記号を勝手に変えると人名や住所で問題になりやすいです。

例外ルールが増えるなら関数の責務を分割します。

関数の責務分割はテストの粒度も揃えやすいです。

全角→半角

全角英数字を半角に戻す関数も同様に対応表を反転して持ちます。

両方向の関数を用意して用途で使い分けます。

変換前後で長さが変わらないことを確認します。

想定外の文字が混ざるなら検出用の関数も用意します。

検出はエラーにせずログに出す運用も選択肢です。

検出ログが溜まれば対応表の拡張候補が見えてきます。

半角⇔全角変換を行う際の注意点（実務の落とし穴）

半角と全角の変換は一見単純ですが落とし穴が多いです。

仕様で決めないと現場判断がぶれて結果が揺れます。

特にカナと性能の話は後から問題になりやすいです。

先に注意点を押さえて設計と運用に反映します。

変換方針は対象列ごとに決めて無闇に横展開しない方が安全です。

変換の失敗は後で戻せないのでロールバック手段が重要です。

① 濁点・半濁点が合成文字として扱われる

半角カナは濁点や半濁点が別文字として並ぶことがあります。

そのため単純な一対一変換だとパ と ﾊﾟ の対応が崩れやすいです。

見た目だけで一致を判断すると誤判定が起きます。

変換後に目視しやすい検証データを用意します。

実データから代表値を抜き出して回帰テストにします。

濁点だけが残るデータがないかも合わせて確認します。

濁点が単独で残ると表示が崩れるため特に注意します。

② DB文字コードで変換結果が異なる

DBの文字セットが違うと変換できる文字の範囲が変わります。

同一DBMSでも環境差で結果が変わる点を前提にします。

移行時は変換対象のカラムと文字種を棚卸しします。

文字種の割合を先に測ると作業規模が見積もれます。

外部連携の出力先で期待する文字種も確認しておきます。

出力先が全角を許容しないなら先に半角標準へ寄せます。

③ 変換をWHERE/JOINで使う時の性能

WHEREやJOINで毎回変換関数をかけるとインデックスが効きにくくなります。

大量データでは実行計画が変わって急に遅くなることがあります。

対策としては更新で正規化して保持する方法が堅実です。

検索用の正規化カラムを追加して運用する案も有効です。

更新頻度と参照頻度のバランスで最適な方式を決めます。

性能要件が厳しい場合は事前に実行計画を比較します。

性能評価はサンプルではなく本番相当件数で見るのが安全です。

よくある質問（Q＆A）

最後に現場でよく聞かれる疑問をまとめます。

短く結論を出しつつ判断材料も添えます。

半角スペースと全角スペースもSQLで統一できますか？

できます。

REPLACEで全角スペースを半角スペースへ統一するのが定番です。

前後の余計なスペースはTRIM系の関数で別途整えます。

タブや改行が混ざる場合は別途置換対象に含めます。

スペース統一は検索の安定化に直結するので早めに対応します。

半角⇔全角変換は検索やJOINにも影響しますか？

影響します。

一致条件で変換関数を使うと性能面の影響も出るため正規化して保持する方が安全です。

一時的に変換して比較するなら対象件数を絞るのが現実的です。

検索用カラムを作る場合は更新タイミングも設計に入れます。

検索用カラムは入口で必ず更新されるようにトリガーやアプリ実装で担保します。

検索用カラムは入口で必ず更新されるようにトリガーやアプリ実装で担保します。

Oracleに半角⇔全角の万能関数はありますか？

万能な一発変換だけで全ケースを安全に扱うのは難しいです。

英数字はTRANSLATEで安定しやすいので対象を絞って運用するのが現実的です。

カナまで含めるなら環境差を踏まえた検証が必須です。

万能を目指すよりも列ごとの仕様を決める方がトラブルが減ります。

列ごとの仕様は例示データとセットにすると誤解が減ります。

大量データでパフォーマンスに影響しますか？

影響します。

一括更新はロックやログ量が増えるためバッチ化や対象限定が重要です。

更新前にバックアップとロールバック手段を用意します。

段階更新とサンプリング検証を組み合わせると安全です。

実行時間が長い場合は監視と中断手順も決めておきます。

SQLだけ vs アプリ側、どっちが良い？

原則は入力時点で統一する設計が有利です。

ただし既存データの是正や一時的な補正にはSQLだけの変換が役立ちます。

長期運用ならSQLとアプリの役割分担を決めてから実装します。

決めた規約をデータ取り込みの入口に反映するのが再発防止になります。

入口の規約が弱いと何度でも混入するのでコストが増えます。

SQLだけで半角⇔全角変換は可能（ただしDB依存）

SQLだけでも英数字やスペースの統一は現実的に実装できます。

一方でカナの完全な往復変換はDBMS差と合成文字の問題で難易度が上がります。

まず対象文字種を限定して必要十分な対応表を作るのが成功の近道です。

変換対象の棚卸しとテストケース作りが品質を決めます。

未知の文字を検出する仕組みを用意すると運用が安定します。

最後に性能と運用を踏まえて正規化戦略を選びます。

決めた標準形をドキュメント化して再発を防ぎます。

運用で迷いが出たら標準形に立ち返れる状態を作ります。

標準形を守る仕組みまで作ると変換SQLに頼る頻度が減ります。