【VBAリファレンス】生成AI活用研究AI(Gemini)とエクセル数式対決 その3 複雑な条件分岐と配列数式の境界線

スポンサーリンク

概要:AIは「関数」をどこまで理解できるのか

Excel VBAの講師として長年現場に立っていると、「AIに数式を考えさせたら便利ではないか」という問いを頻繁に受けます。しかし、AIが生成する数式は時に驚くほど洗練されており、時に致命的な論理エラーを含んでいることがあります。本シリーズ第3弾となる今回は、単なる計算式ではなく、「多条件の複雑な抽出」と「配列数式の最適化」という、業務効率化の核心部分に焦点を当てます。

特にGeminiのような大規模言語モデル(LLM)は、人間が数分悩むようなネスト構造を数秒で提示します。しかし、それを実務の現場にそのまま投入できるかといえば、そうではありません。計算コスト、可読性、そしてメンテナンス性という「プロの視点」から、AIと人間の知恵をどう融合させるべきかを徹底的に検証します。

詳細解説:AIが生成する「数式」の罠と可能性

AIは、過去の膨大なデータから「最も確率が高い数式」を選択します。例えば、VLOOKUP関数の限界に悩むユーザーに対して、AIは即座にINDEX関数とMATCH関数の組み合わせ、あるいは最新のXLOOKUP関数を提案します。ここまでは非常に優秀です。

問題は、「条件が重なったとき」に発生します。例えば、以下のようなケースです。
「A列が〇〇かつB列が△△、かつC列が今日の値より大きいデータのみを抽出し、その合計を出す」
このような要求に対し、AIはFILTER関数やSUMIFS関数を駆使した非常に美しい数式を提示します。しかし、データ行数が10万行を超えた場合、その数式が再計算時にExcelをフリーズさせる原因になることを、AIは必ずしも警告してくれません。

私たちは、AIから提示された数式を「そのまま使う」のではなく、「数式の計算アルゴリズムを評価する」という役割を担う必要があります。配列数式(Spill機能)は強力ですが、揮発性関数(OFFSETやINDIRECTなど)と組み合わせることで、ワークブック全体を重くするリスクがあることを理解しなければなりません。

サンプルコード:AIとの対決・複雑な条件抽出の最適化

今回は、AIが生成しがちな「重い数式」を、実務で耐えうる「軽量かつ高速な数式」に変換するプロセスを紹介します。

以下の事例は、特定の条件を満たす行の売上合計を算出するものです。AIはしばしば、複雑なIF関数と配列を組み合わせた重い数式を提示します。


' AIが生成しがちな、処理が重くなる数式例(イメージ)
' =SUM(IF((A2:A10000="東京")*(B2:B10000="高額"),C2:C10000,0))

' プロが推奨する、高速かつメンテナンス性の高い数式(SUMIFS)
' =SUMIFS(C2:C10000, A2:A10000, "東京", B2:B10000, "高額")

' さらに、VBAで動的に範囲を定義する場合の最適化コード
Sub CalculateOptimized()
    Dim ws As Worksheet
    Set ws = ThisWorkbook.Sheets("Data")
    
    ' 名前付き範囲を利用して、データ範囲を可変にする(構造化参照の考え方)
    Dim lastRow As Long
    lastRow = ws.Cells(ws.Rows.Count, "A").End(xlUp).Row
    
    ' 数式の埋め込み
    ws.Range("E2").Formula2 = "=SUMIFS(C2:C" & lastRow & ", A2:A" & lastRow & ", ""東京"", B2:B" & lastRow & ", ""高額"")"
    
    Debug.Print "計算完了: " & ws.Range("E2").Value
End Sub

このサンプルを見て分かる通り、関数レベルで解決できるものは関数で、データ量が膨大で動的な制御が必要な場合はVBAで、という「住み分け」が重要です。AIは関数のプロフェッショナルですが、VBAによるシステム全体の安定性管理までは責任を負ってくれません。

実務アドバイス:AIと共存するための「三つのルール」

実務においてAIを「副操縦士」として扱うために、以下の三つのルールを徹底してください。

第一に、「計算量の可視化」です。数式を入力した後に、Excelの「数式」タブ内にある「計算方法の設定」を意識してください。AIが提案する配列数式が多用されると、自動計算設定下では編集のたびにストレスがかかります。

第二に、「検証用のダミーデータ」を作成することです。AIが提示した数式が正しいか確認するために、小さなサンプルデータセットを用意し、手計算の結果とAIの数式の結果を突き合わせる癖をつけてください。

第三に、「可読性の担保」です。自分がいなくなった後、他のメンバーがその数式を理解できるか。あまりに複雑なネスト構造(IF関数が5階層以上など)は、たとえ正しくても「負の遺産」になります。AIには「読みやすくシンプルな数式に書き直して」と指示し、可読性を優先する文化をチームに定着させましょう。

まとめ:AIは道具であり、主導権は人間にある

今回の研究を通じ、Geminiをはじめとする生成AIは、Excelの数式構築において間違いなく強力なパートナーであることが証明されました。しかし、AIは「効率」を追求するあまり、将来のメンテナンス性や、大規模データにおけるパフォーマンスを軽視することがあります。

Excel VBAのベテランとして言いたいのは、「AIに答えを求めるな。AIに選択肢を出させ、その中から実務に最適なものを選択せよ」ということです。

数式は、ただの結果を出すための道具ではありません。それは、業務プロセスそのものを定義する設計図です。AIが提示する数式を鵜呑みにせず、その背後にあるロジックを理解し、自分の管理下で実行させる。その姿勢こそが、これからのDX時代に求められる「Excel力」の正体なのです。

今後もAIの進化は続きますが、数式を組み立てる際の「美学」や「責任」を持つのは、常に私たち人間です。次回の研究では、さらに一歩進んで、AIを活用した「VBAコードの自動リファクタリング」について深く掘り下げていきます。自身の技術を磨きつつ、AIという最強の助っ人を使いこなす、そんなプロフェッショナルな姿勢をこれからも貫いていきましょう。

タイトルとURLをコピーしました