Accessで文字列を数値に変換する方法｜Val・CLng・CDblの違い
Accessで業務システムを運用していると、
「見た目は数字なのに計算できない」「集計結果がおかしい」
といったトラブルに一度は遭遇します。
その原因の多くは、文字列として扱われている数値データです。
AccessはExcelと違い、
「見た目が数字＝数値型」とは扱ってくれません。
この違いを理解しないまま開発・改修を続けると、
後になって修正が難しい不具合として表面化します。
この記事では、Accessで文字列を数値に変換する代表的な方法である
Val・CLng・CDbl を取り上げ、
- それぞれの挙動の違い
- 実務で使う際の判断基準
- 将来の改修・移行で問題になりやすいポイント
を、業務システム視点で解説します。
Accessで「文字列が数値に見える」問題とは
見た目は数字なのに計算できない理由
Accessでは、フィールドの型が「テキスト型」であれば、
たとえ 123 と表示されていても 文字列 として扱われます。
この状態で、
- 合計を取る
- 比較演算をする
- 金額計算を行う
と、意図しない結果になることがあります。
特に次のような場面で起きがちです。
- CSVやExcelからデータを取り込んだ
- 外部システム連携で文字列として渡された
- フォーム入力時に型チェックをしていない
見た目だけでは判別できないため、
不具合として発見されにくいのが厄介な点です。
Accessは自動で型変換してくれない
Excelでは、
「数値っぽい文字列」を自動的に数値として扱ってくれる場面があります。
しかしAccessでは、
基本的に自動型変換は行われません。
Accessでは、
- フィールド型
- 変数の型
- 明示的な変換処理
がすべて一致して初めて、安全に数値として扱えます。
「たまたま動いている」状態に依存するのは、
業務システムでは非常に危険です。
Accessで文字列を数値に変換する代表的な方法
Val関数で変換する方法
Val 関数は、文字列の先頭から数値として解釈できる部分を
強引に数値として取り出す 関数です。
Val("123") ' 123
Val("123ABC") ' 123
Val("ABC123") ' 0
特徴
- 途中に文字が混じっていても先頭が数字なら変換できる
- NULL や 空文字でもエラーになりにくい
- 変換失敗時は 0 を返す
一見便利ですが、
「失敗してもエラーにならない」 点が、
実務ではリスクになります。
CLng関数で変換する方法
CLng は、文字列を Long型（整数） に変換します。
CLng("123") ' 123
CLng("123.4") ' 123（小数は切り捨て）
特徴
- 数値として正しくない場合はエラーになる
- NULL や 空文字でエラー
- 整数処理に向いている
「変換できないものは止める」
という挙動のため、業務ロジックでは重要な選択肢です。
CDbl関数で変換する方法
CDbl は、文字列を Double型（小数対応） に変換します。
CDbl("123.45") ' 123.45
特徴
- 小数計算に対応
- 金額・数量などでよく使われる
- 変換できない場合はエラー
業務データを扱う場合、
最も汎用性が高いのが CDbl です。
Val・CLng・CDblの違いを一覧で比較
挙動・エラーの違い
| 観点 | Val | CLng | CDbl |
|---|---|---|---|
| 返却型 | Double | Long | Double |
| 文字混在 | 途中までOK | エラー | エラー |
| NULL | 0 | エラー | エラー |
| 空文字 | 0 | エラー | エラー |
| 業務向き | △ | ○ | ◎ |
「動く」と「安全」は別物
Val関数は、
とにかく止まらない という点では優秀です。
しかし、
- 本来エラーにすべきデータ
- 想定外の入力
- 不正な値
を 静かに 0 に変換してしまう ため、
後から集計結果がおかしくなる原因になります。
業務システムでは、
「止まらない」より「間違えない」ことの方が重要です。
実務ではどの関数を選ぶべきか
Val関数が向いているケース
Valが向いているのは、次のようなケースです。
- 外部データ取込時の一次処理
- 不完全な文字列データの整理
- 一時的な値の補正
最終的な業務計算に使う前段階 に限定するのが安全です。
CLng / CDblを使うべきケース
次のような処理では、
CLng や CDbl を使うべきです。
- 金額計算
- 在庫数量
- 集計・帳票出力
- 請求・支払処理
多少手間が増えても、
明示的にエラーを出す設計の方が、
長期的には安全です。
文字列→数値変換でよくある失敗パターン
空文字・NULLで突然止まる
業務データでは、
- 未入力
- NULL
- 空白
が混在します。
If IsNull(strValue) Or strValue = "" Then
' 処理分岐
End If
Nz 関数を併用するなど、
事前チェックは必須です。
数値に見えるが実は文字列
よくある例として、
- 全角数字
- カンマ付き（”1,000″）
- 通貨記号付き（”¥1000″）
があります。
これらは そのままでは CLng / CDbl でエラーになります。
将来の改修・移行を見据えた型変換の考え方
型変換の曖昧さは移行時に表面化する
Accessから、
- SQL Server
- Webシステム
- 他DB
へ移行する際、
型の曖昧さは必ず問題になります。
Valだらけのシステムは、
- どこで不正値が混ざったか分からない
- 移行時に例外処理が増える
- テスト工数が膨らむ
という状態になりがちです。
「とりあえずVal」は技術的負債になりやすい
短期的には便利でも、
長期的には 負債になる典型例です。
- 誰も仕様を説明できない
- 修正が怖くて触れない
- 移行費用が高くなる
Accessを「長く使う」前提なら、
型変換は必ず設計の一部として考えるべきです。
まとめ｜Accessの文字列→数値変換は設計の話
- Valは万能ではない
- CLng / CDblは前提条件が重要
- 大事なのは「今後どう使われるか」
文字列を数値に変換する処理は、
単なるテクニックではなく 設計の話です。
Accessは手軽に作れるからこそ、
最初の判断が後々まで影響します。
システムキューブの「Accessの移行変換、mdb・adpのバージョンアップ」について
