AccessのIIF関数についてお探しですね。

広告

Accessの条件分岐とデータ型変換を使いこなそう

Accessでデータベースを作ったりVBAでプログラムを組んだりしていると、必ずぶつかるのが「条件によって処理を変えたい」「データの形式を揃えたい」という場面です。

特にExcelから移ってきた人にとって、Access特有の関数の動き方や厳しいデータ型のルールは、思わぬエラーの原因になりがちです。

この記事では、条件分岐でよく使うIIF関数とSwitch関数の使い分け方や注意点、そして計算や文字列をつなげるときにトラブルになりやすいデータ型変換（CIntやCStrなど）の正しい使い方について、実際の開発現場で役立つ視点から詳しく解説します。

これらをしっかり理解しておけば、エラーの少ない安定したアプリケーションが作れるようになりますよ。

IIF関数の基本と、知らないとハマる「全部評価される」問題

AccessのクエリやVBA、フォームのコントロールソースなどで一番よく使われる条件分岐が**IIF関数**です。

ExcelのIF関数と同じように、「条件式」「条件が合ってるときの値」「合ってないときの値」の3つを指定するだけのシンプルな作りですが、Access（特にVBA）で使うときには、Excelとは違う大事な注意点があります。

それは、IIF関数が動くとき、条件が合っていても合っていなくても、**両方の値を裏で計算してしまう**という性質です。

たとえば、割り算をする計算式で「割る数が0のときは0を表示して、それ以外は割り算の結果を表示する」というロジックを組んだとします。

IIF関数を使って書いた場合、たとえ割る数が0であっても、「条件が合わない方」の割り算処理が内部的に実行されてしまい、「0で割ることはできません」というエラーが出て処理が止まってしまうことがあるんです。

この「全部評価される」という動きは、開発者が最もハマりやすい落とし穴の一つです。

特に、時間のかかる処理を含む自作の関数を引数に指定している場合、パフォーマンスが落ちる原因にもなります。

条件に合わない方の重い処理も裏で実行されてしまうため、無駄にパソコンのパワーを使ってしまうからです。

なので、単純な値の置き換えや軽い計算ならIIF関数はとても便利で見やすいんですが、計算エラーが起きそうな処理や、実行に時間がかかる処理を分けたいときには、IIF関数だけに頼らず、VBAなら普通の**If…Then…Else文**を使うか、エラーを避けるための事前チェックを別の形で行う必要があります。

クエリの中で使う場合も、この特徴を理解した上で、計算式が安全に実行されるような工夫が必要です。

複雑な条件分岐を整理するSwitch関数のメリットと使いどころ

IIF関数は「YesかNoか」の二択を判断する場合には便利ですが、条件が3つ以上重なるような複雑な分岐処理では、コードがすごく読みにくくなるという欠点があります。

IIF関数の中にさらにIIF関数を入れる「入れ子（ネスト）」構造は、カッコの数が合わなくなったり、どういう流れになっているのか追いづらくなったりするため、後から修正するときに困る大きな原因になります。

こういう場面で活躍するのが**Switch関数**です。

Switch関数は、「条件1, 値1, 条件2, 値2, …」というように、条件と結果をペアで書いていくことができて、左から順に条件をチェックして、最初に条件に合った時点の値を返してくれます。

これによって、複雑な入れ子構造を作らなくても、複数の条件分岐を平らで読みやすい形で書くことができるんです。

たとえば、テストの点数に応じて「優」「良」「可」「不可」といった評価をつける場合、IIF関数を使うとカッコが何重にも重なって、修正が必要になったときにどこを直せばいいのかすぐに分かりません。

でもSwitch関数なら、条件と結果のペアが並んでいるだけなので、評価基準を変えたり新しいランクを追加したりするのが簡単です。

ただし、Switch関数もIIF関数と同じように、VBA環境では全部の引数が評価される可能性がある点には注意が必要です。

また、Switch関数はどの条件にも当てはまらない場合の「それ以外」に相当する引数が用意されていないため、どの条件にも合わない場合は**Null**が返されます。

デフォルト値を設定したい場合は、条件式の最後に「**True, “デフォルト値”**」というペアを追加することで、強制的に値を返すテクニックがよく使われます。

このように、Switch関数は複数の条件分岐を見やすくするための強力な道具ですが、その特徴を正しく理解して使いこなすことが大切です。

データ型変換（CInt, CStr）が必要になる場面とエラーを防ぐコツ

AccessはExcelと違って、データベースとしての厳密なデータ型を持っています。

そのため、見た目は数字でも内部的に「テキスト型」として扱われているデータを計算に使おうとしたり、逆に数値を文字列としてつなげようとしたりすると、予想外の結果になったり「型が一致しません」というエラーが出たりします。

ここで重要になるのが、データを明示的に目的の型へ変換する関数です。

**CInt関数**は値を整数型（Integer）に変換し、**CStr関数**は文字列型（String）に変換しますが、これらを使うときにはそれぞれの型の「限界」と「仕様」を知っておく必要があります。

特に注意すべきは**CInt関数**です。

AccessのInteger型は-32,768から32,767までの範囲しか扱えないため、ID番号や金額など、この範囲を超える数値をCIntで変換しようとすると「オーバーフロー」のエラーが発生します。

実際の開発では、より大きな整数を扱える**CLng関数**（Long型への変換）を使う方が安全なケースがほとんどです。

また、文字列への変換を行うCStr関数や、数値計算を行う前の型変換で最も警戒すべきなのが**Null値**です。

Accessのデータベースでは、値が入力されていない状態（Null）が含まれることがよくあります。

CIntやCLng、CStrといった変換関数は、引数にNullが渡されると即座にエラーを返してしまいます。

これを防ぐには、型変換関数を使う前に、必ず**Null処理**を行う必要があります。

具体的には、**Nz関数**を組み合わせて `CInt(Nz([フィールド名], 0))` のように、Nullの場合に代わりとなる数値（この場合は0）や空文字を与えてから変換を行うのが鉄則です。

Excel VBAではあまり意識しないNullの存在ですが、Access開発では「**データ型変換とNull対策はセットで考える**」という習慣をつけることが、エラーのない安定したシステム作りへの近道です。

クエリとVBAでIIF、Switch、型変換を組み合わせて使う実例

実際の現場では、これまで説明したIIFやSwitch、そして型変換関数を一つだけ使うことよりも、これらを組み合わせて複雑なデータ加工を行う場面の方がずっと多いです。

たとえば、クエリを使ってレポート用のデータを作るとき、「売上金額がNullの場合は0とみなして、かつ30,000円以上の場合は”高”、それ以外は”低”と表示する」といった要件があるとします。

この場合、まずはNz関数でNullを0に変換して、その結果を数値型として正しく認識させるためにCLngを通して、最後にIIF関数で判定を行うという複合的な式が必要になります。

このように関数を適切に組み合わせることで、元のデータが不完全であっても、出力の段階では整えられた情報をユーザーに提供することができます。

さらに、フォーム上のテキストボックスに入力された値を計算に使う場合、テキストボックスの値は基本的にバリアント型（文字列扱い）となることが多いです。

これをそのまま足し算記号（+）で計算しようとすると、数値の足し算ではなく文字列の連結（”10″ + “20” = “1020”）として処理されてしまうことがあります。

これを防ぐために `CLng(Me.txtKingaku1) + CLng(Me.txtKingaku2)` のように明示的に型変換を行いますが、ここでも入力が空（Null）である可能性を考えて**Nz関数**を挟む必要があります。

IIFやSwitchで分岐のロジックを組んで、その中で扱うデータに対して適切な型変換を施すことは、Access開発の基礎体力とも言えるスキルです。

クエリの計算フィールドやVBAのコードでこれらの関数を組み合わせるときは、常に「**どんなデータが流れてくるか（Nullや想定外の文字は含まれないか）**」を想像しながらコードを書くことが、トラブルを未然に防ぐ鍵になります。

まとめ

いかがでしたか? IIF関数とSwitch関数の使い分け、そしてデータ型変換とNull対策の重要性を理解すれば、Accessでの開発がぐっと楽になるはずです。

最初は難しく感じるかもしれませんが、一つひとつ実践していくうちに自然と身についていきますよ。

頑張ってください!

広告