「Excelの関数で自動化したけれど、データが増えたら重くならない?」「VBAやPower Queryにした方がいい?」そんな疑問はありませんか。
AIに頼めば関数やマクロを作れる時代。でも、「動くものを作ること」と「どの方法で作るかを選ぶこと」は別です。今回は架空の商品カテゴリー判定を例に、はんちゃんとチャーが選び方を考えます。難しいコードを覚えるよりも、まずは実現方法を比べて選ぶところから始めましょう。
AIにお願いしたら、Excelの処理ができた!
はんちゃん(SE)商品名に「魔王」が含まれたら「焼酎」、「八海山」なら「清酒」って、カテゴリーを表示したいんだ。キーワードは増えるから、別シートで管理したい。



うんうん🐈 Excelの関数でできるよ。キーワードとカテゴリーをマスターにして、Excelのテーブルにしておけば追加にも対応しやすいね。
架空のサンプルで考えよう
| 商品名 | 判定結果 |
|---|---|
| 魔王 720ml | 焼酎 |
| 八海山 特別本醸造 | 清酒 |
| サンプル商品A | 対象外 |
Before/After:入力から結果までをイメージ
Before:商品名だけが並び、カテゴリー列は空欄。担当者が商品ごとに分類している状態です。
After:別シートのキーワードマスターと照合し、カテゴリー列へ「焼酎」「清酒」「対象外」を表示します。
| マスターのキーワード | 分類 |
|---|---|
| 魔王 | 焼酎 |
| 八海山 | 清酒 |
※説明用の架空例です。キーワードが複数一致するときの優先順位、空白、表記ゆれなども運用前に決める必要があります。ここでは関数の書き方そのものより、実現方法をどう選ぶかに注目します。
Excel関数なら、こんなふうに実現できる
Microsoft 365のExcelを使う例です。商品名をA2セルに入力し、別シートのキーワードとカテゴリーの一覧を「カテゴリマスタ」という名前のExcelテーブルにします。B2セルに次の式を入力します。
=IF(A2="","",LET(
k,カテゴリマスタ[キーワード],
c,カテゴリマスタ[カテゴリー],
hit,(k<>"")*ISNUMBER(SEARCH(k,A2)),
XLOOKUP(1,hit,c,"対象外")
))
- SEARCH:商品名にマスターのキーワードが含まれているか調べます。
- ISNUMBER:キーワードが見つかった場合を一致として判定します。
- XLOOKUP:マスターの上から最初に一致したカテゴリーを返します。該当なしなら「対象外」です。
Excelテーブルの参照を使っているため、マスターに行を追加した際も参照範囲を追従させやすくなります。ただし、複数のキーワードに一致する商品はマスターの上にあるものが優先されます。また、SEARCHは英字の大文字と小文字を区別しません。実務利用前に、空白キーワード・表記ゆれ・重複登録といった例外も確認しましょう。



なるほど、AIに式を作ってもらえば手軽だね。でも、商品が何万件にも増えたら、このままで大丈夫かな?



そこが設計判断のポイントだニャ。まずは今の件数で試して、処理時間や運用方法も含めて選ぶニャ🐈
商品が1,000〜2,000件なら?



商品は普段何件くらい?



1,000〜2,000件くらい。まずは関数でよさそうだよね。



そうだね。関数を第一候補にしよう。実装と修正が簡単なのは大きな利点。ただし「2,000件なら絶対に速い」とは言えないから、実データに近い条件で再計算時間を確認しよう。
もし商品が10万件に増えたら?



将来10万件になったら、各行で検索する関数は重くならない? VBAでメモリーにまとめて読み込んで、一括判定する方法もあるよね。



うん。Power Queryという選択肢もあるよ。例えば商品2,000件とマスター100件を総当たりすれば最大20万組、商品10万件なら最大1,000万組の照合になる。これは比較規模の概算で、処理時間の測定値ではないよ。



つまり、いきなり一括処理が正解というわけでもないんだよね。



その通り。VBAやPower Queryでも部分一致の組み方によっては重くなる。データ量、更新頻度、使う人、保守方法を見て比較するのが大切だね。
正解は一つじゃない。選ぶ理由が大切
| 方式 | メリット | 注意点 |
|---|---|---|
| Excel関数 | 導入と修正が容易。結果を確認しやすい | 行数・条件が増えると再計算が負担になる場合がある |
| VBA一括処理 | データをまとめて処理し、シートへの読み書きを減らせる | マクロの実行環境や保守が必要 |
| Power Query | 定型的なデータ加工を更新操作で繰り返せる | 部分一致照合の実装と性能の検証が必要 |



ポイントはここ! 選択肢を並べて、今回の条件なら関数を選ぼうと判断することだと思う。最初から最も高度な方法を使えばいいわけじゃない。



うんうん🐈 AIに候補を比較してもらってもいい。でも最後は、結果の正しさと処理時間を確認して決めたいね。
設計判断を流れで整理してみよう
商品名に特定のキーワードが含まれていたら、カテゴリーを自動表示したいとAIに相談します。
複数の実現方法を挙げて、メリットや注意点を比較します。
商品は1,000〜2,000件程度。更新頻度や、使う人・保守する人も確認します。
現在の規模では、導入や修正のしやすさからExcel関数を有力候補にします。
実データに近い条件で、判定結果と処理時間が要件を満たすか検証します。
採用理由を記録し、データが増えた場合のVBA一括処理やPower Queryも代替案として残します。
大切なのは「関数だから正解」ではなく、「条件を比較し、検証して選んだ」というプロセス。性能が要件を満たさなければ、ほかの方式を再検討します。
採用しなかった方法も、将来のために残す



今は採用しないVBAやPower Queryも、将来の対処案として残しておきたいんだ。あとから「なぜ関数にした?」が分かるように。



いいね。こんな簡単な設計判断メモだけでも役に立つよ。
設計判断メモ(例)
- 現状:商品1,000〜2,000件
- 第一候補:Excel関数
- 選定理由:導入・変更がしやすい
- 採用前の検証:判定結果と再計算時間を確認
- 代替案:VBA一括処理、Power Query
- 見直し条件:データ増加、処理時間の悪化、運用方法の変更



「何を採用したか」だけじゃなく、「なぜ選んだか」「どんなときに見直すか」を残す。それが運用しやすさにつながるよね。
まとめ:AIで作れる。だからこそ、選べるようになろう
AIはExcel関数やマクロを作る力強い助けになります。初心者が便利な処理を作れること自体は、とても良い変化です。次の一歩は、「関数・VBA・Power Queryのどれが今の条件に合う?」とAIと一緒に検討すること。
今回のポイントは「選択肢を比較する」「採用理由を残す」「採用しなかった案を将来に備えて記録する」の3つ。実用に移す前には、実際のデータで動作と性能を検証しましょう。
あわせて読みたい関連記事
- Power Queryが遅い!よくある原因5選:Power Queryでも処理方式によって速度が変わる理由を知る
- Access/Excel VBA|CopyFromRecordsetはなぜ速い?:データをまとめて処理する考え方を学ぶ



次回は「性能・保守性・使いやすさ」など、非機能要件の考え方を紹介するニャ🐈
※商品名と処理条件は説明用の架空例です。比較回数は概算であり、処理時間を保証するものではありません。



こちらも読んで欲しい二や🐈


コメント