Back to Blog
Excel生成AIプロンプトPower QueryVBA

Excel×AI「プロンプトの型」5選:関数・Power Query・VBAを安全に使う

Excel作業をAIに丸投げする「プロンプトの型」5選:関数・Power Query・VBAを非エンジニアが安全に使いこなす

【リード】AIはExcel作業をどこまで肩代わりできるのか

ChatGPTやGeminiなどの生成AI(文章やコードを自動生成するAI)は、Excelの関数やVBA(Excelの操作を自動化するプログラミング言語)のコードを出力できる。Excel自体にもMicrosoftのCopilotなどのAI機能が組み込まれており、利用条件は契約プランによって異なるものの、表の操作をAIに頼む選択肢は広がっている。

一方で、AIの出力には誤りが含まれることがある。指示が曖昧な場合は、意図と異なる数式やコードが返りやすい。生成AIは、もっともらしく見えるが実際には動かないコードを出力することもあり、見た目の自然さが正しさを保証しない点には注意が必要になる。

こうした問題に対しては、指示文(プロンプト)を一定の「型」にすることで、精度と安全性を両立しやすくなると見られる。本記事では次の5つの型を紹介する。

型 内容 主な対象
型1 目的・入力・出力例を先に伝える 関数
型2 実データの代わりにダミーデータで依頼する 全般
型3 工程を番号付きで分解して指示する Power Query
型4 実行前の「保険」を組み込む VBA
型5 エラー時に「検証と修正」を依頼する 全般

対象読者は、SUMやVLOOKUPなどは日常的に使うが、プログラミングは専門としないExcelユーザーである。

なぜ「なんとなくの指示」ではAIがExcel作業に失敗しやすいのか

AIは手元のファイルの中身を見ていない

チャット形式の生成AIは、基本的にユーザーのExcelファイルを直接見ていない。列がどの順に並んでいるか、日付が本物の日付データか文字列か、全角と半角が混在していないか、といった前提は、伝えない限りAIには分からない。AIは一般的な表を想定して回答するため、実際のファイルとのずれが生じやすい。

「集計して」では条件・範囲・出力形式が決まらない

「売上を集計して」という指示には、次の要素が含まれていない。

  • 何で区切って集計するのか(月別、担当者別、商品別など)
  • どの範囲を対象にするのか(見出し行の有無、データの行数など)
  • 結果をどこに、どの形式で出すのか

これらが確定しないまま、AIは補完して数式を返す。補完の内容が意図と違えば、数式自体は動いても結果は誤る。エラーが出ない分、誤りに気づきにくい点が厄介である。

型を用意する3つの利点

プロンプトを型にしておく利点は、次の3点に整理できる。

  1. 再現性の確保:誰が書いても同程度の品質の回答を得やすくなる。
  2. 確認作業の定型化:何をチェックすべきかが毎回決まるため、見落としが減る。
  3. 情報漏洩リスクの低減:実データを入力しない手順を型に組み込める。

型1:「目的・入力・出力例」を先に伝えると関数の精度は上がるのか

関数を依頼する場面では、要件を構造化して渡すことで、意図とのずれを減らしやすいと見られる。

プロンプトに含める4つの要素

  • やりたいこと:目的を一文で書く
  • 列名と各列のデータ型:日付、数値、文字列の区別を明記する
  • 期待する結果の具体例:2〜3行で十分である
  • 使用するExcelのバージョン:Microsoft 365、Excel 2019などを明記する

バージョン依存の関数を避ける指定

XLOOKUP(条件に合う値を表から検索する関数)やFILTER(条件に合う行を抽出する関数)などは、Excel 2019以前では使えない。社内に古いバージョンが混在している場合は、「XLOOKUPやFILTERなど新しい関数は使わず、VLOOKUPやSUMIFSなどで書いてください」のように、使う関数の範囲を指定しておくと、受け取った側のファイルでエラーになるのを防げる。

プロンプト例

「A列に日付、B列に売上がある。月ごとの合計をD列に出したい」という依頼を、型に沿って書くと次のようになる。

# 目的
A列の日付とB列の売上から、月ごとの売上合計を出したい。

# データの構成
- シート名:売上
- 1行目は見出し、2行目以降がデータ(約1,000行)
- A列:日付(日付型。例:2024/4/3)
- B列:売上金額(数値。単位は円)

# 結果の例
D列(月の初日)    E列(売上合計)
2024/4/1          120,000
2024/5/1          98,500

# 環境
Excel 2019。XLOOKUP、FILTERなどの新しい関数は使わないこと。

# 出力してほしいもの
E2セルに入力する数式と、その数式の仕組みの簡単な説明

この指示であれば、SUMIFS(複数の条件に合う数値を合計する関数)とEDATE(指定した月数だけ前後の日付を返す関数)を組み合わせた、次のような数式が返ると期待できる。

=SUMIFS($B:$B,$A:$A,">="&D2,$A:$A,"<"&EDATE(D2,1))

出力例を2〜3行添えておくと、AIが期待する形式を推測する余地が小さくなり、ずれが減ると見られる。返ってきた数式は、出力例の行と照合して一致するかを確かめる使い方が基本となる。

型2:実データを貼らずに「ダミーデータ」で依頼するにはどうすればよいのか

実データをそのまま入力するリスク

顧客名、住所、取引先名、金額などを含むデータを外部の生成AIサービスにそのまま入力すると、情報漏洩のリスクが生じる。サービスや契約形態によっては、入力内容が学習に使われる場合もある。業務データを扱う際は、入力しないことが基本的な安全策と位置づけられる。

ダミーデータの作り方

実データの代わりに、列構成だけを再現した架空のデータ(ダミーデータ)を作って渡す。手順の例を示す。

  1. 本番ファイルの見出し行(列名)だけをコピーする。ただし、列名自体に機密性がある場合は一般的な名称に置き換える
  2. 5〜10行程度、架空の値を入力する。氏名は「顧客A」「顧客B」、金額は実データと桁感が近い数値にする
  3. 実データで起こりうる「癖」を数行だけ再現する。全角・半角の混在、前後の空白、空欄、日付が文字列になっているケースなどが該当する
  4. AIにはダミーデータと「実データは約◯行ある」という規模感を伝える

ダミーデータそのものをAIに作らせる方法もある。「次の列構成で、架空のデータを10行作ってください。実在の人名・企業名は使わないでください」と依頼すればよい。

前提として確認しておきたいこと

ダミーデータを使う場合でも、次の点は事前の確認が必要になる。

  • 社内の生成AI利用ルール:利用が許可されているサービスか、入力してよい情報の範囲はどこか
  • 学習への利用設定:入力データが学習に使われるかどうか、設定で無効にできるかどうか
  • ファイル名・シート名・数式に含まれる情報:ダミーのつもりでも、シート名や既存の数式に社名や案件名が残っている場合がある

「ダミーで確認してから本番へ」という流れ

ダミーデータで数式やコードの動作を確認し、問題がなければ本番データに適用する。この順序であれば、機密情報を外部に出さずに済み、本番データを誤って壊すリスクも抑えられる。ただし、ダミーデータには実データの例外的な値が含まれにくい。本番適用後も、数行を目視で照合する手順は残しておく必要がある。

型3:Power Queryの手順は「段階分解」で指示すると何が変わるのか

Power Queryと段階的な指示の相性

Power Query(データの取り込みや整形を自動化するExcelの機能)は、「ステップ」を順に積み重ねて処理を組み立てる仕組みである。各ステップは画面右側の「適用したステップ」に一覧表示される。この構造は、工程を順番に指示するプロンプトと相性が良いと言える。

工程を番号付きで依頼する

「複数のCSVを整形して集計して」という一括の指示ではなく、工程を分けて書く。

Power Queryで次の処理を行いたい。工程ごとに分けて説明してください。

1. 取り込み:同じフォルダ内の売上CSV(12ファイル、列構成は共通)を結合して読み込む
2. 不要列の削除:「備考」「更新者」列を削除する
3. 型変換:「日付」列を日付型、「売上」列を数値型にする
4. 結合:「商品コード」をキーに、商品マスタ(別のテーブル)を左外部結合する
5. 集計:商品カテゴリ別・月別に売上を合計する

# 出力形式
- 各工程について、(a)画面操作の手順と(b)M言語のコードの両方を示すこと
- ステップ名は日本語で分かりやすく付けること
- 使用バージョン:Microsoft 365

画面操作とM言語の両方を出させる

M言語(Power Queryの記述言語)のコードは、「詳細エディター」に貼り付けて使える。ただしコードだけでは、何が起きているのかを把握しにくい。画面操作の手順も併せて出力させておけば、自分でステップを再現でき、コードの内容を理解する手がかりにもなる。

不具合の原因を特定しやすい

Power Queryでは、適用したステップを1つずつクリックして、その時点のデータの状態を確認できる。「型変換の時点でエラーが出ている」「結合後に行数が増えている」といった問題が起きた段階を特定しやすく、AIに修正を依頼する際も「ステップ3で、日付列にエラーが出ている」と範囲を絞って伝えられる。

型4:VBAを非エンジニアが安全に実行するための「保険付き」プロンプトとは

VBAに特有のリスク

VBAは、元データの書き換えや削除、複数ファイルの一括処理などを一度に実行できる。便利である反面、誤ったコードを実行した場合の影響も大きい。VBAの実行後は、通常の「元に戻す」(Ctrl+Z)が使えなくなる点も、実行前の備えが欠かせない理由として挙げられる。

プロンプトに入れる「保険」の条件

コードの生成を依頼する段階で、次のような制約を明記する。

ExcelのVBAマクロを作成してください。

# やりたいこと
「売上」シートの内容を、担当者ごとに集計して、新しいシートに出力したい。

# データの構成
(型1と同様に列名・データ型・例を記載)

# 条件(必ず守ること)
- 「売上」シートのデータは一切変更・削除しないこと。結果は新規シートに出力すること
- ファイルの削除、外部への送信、他のファイルを開く処理は含めないこと
- コードには、処理の区切りごとに日本語のコメントを付けること
- コードの後に、処理内容を日本語で1行ずつ解説すること
- 使用バージョン:Microsoft 365

「元データは変更せず新規シートに出力」という条件は、最も効果の大きい保険と言える。万一コードに誤りがあっても、元のデータが残るためである。

実行前の手順

プロンプトによる制約に加え、実行環境の側でも備える。

  1. ファイルのコピーを作成する:本番ファイルは直接使わず、コピーに対して実行する
  2. テスト用ファイルで動作確認する:型2で作ったダミーデータ入りのファイルで先に実行する
  3. 解説と照らし合わせる:AIが出力した日本語の解説と、実際のコードの内容が合っているかを確認する
  4. 結果を検算する:出力されたシートの数値を、元データの一部と照合する

実行しないと決める判断基準

次のような処理を含むコードは、依頼していない限り実行しない、と決めておく方法も有効である。

  • ファイルやフォルダの削除(Kill、DeleteFile など)
  • 外部への送信やダウンロード(メール送信、ネットワーク通信を伴う処理)
  • 他のExcelファイルやアプリケーションの操作(Workbooks.Open、Shell など)

コードの意味が読み取れない場合は、「このコードで、ファイル削除・外部送信・他ファイルの操作に当たる処理はあるか」とAIに質問する方法もある。ただしAIの回答自体も誤る可能性があるため、確認の補助として位置づけるのが妥当である。

型5:エラーや想定外の結果が出たとき、AIに「検証と修正」をどう頼めばよいのか

1セットで伝える3つの情報

修正を依頼する際は、次の情報を1セットで渡す。

  • エラーメッセージ:表示された文言をそのまま貼る(例:#VALUE!、実行時エラー '13')
  • 実行した数式やコード:該当部分をそのまま貼る
  • 実際の結果と期待した結果の差:「E5が0になるが、本来は120,000になるはず」のように具体的に書く

「うまく動かない」だけでは、AIは原因を推測するしかない。

「原因の候補→確認方法→修正案」の順序を指定する

AIは、最初に思いついた原因を断定して修正案を返すことがある。順序を指定すると、この傾向を抑えやすい。

次の数式で想定外の結果が出ています。

# 数式
(貼り付け)
# 実際の結果
(貼り付け)
# 期待した結果
(記載)

# 依頼
1. 原因として考えられるものを3つ以上挙げてください
2. それぞれについて、私が自分で確認する方法を示してください
3. その後で、修正案を示してください

原因の候補を挙げさせれば、日付が文字列になっている、範囲がずれている、空白が含まれているなど、手元で確認できる項目が明確になる。

検算の習慣

AIの回答を鵜呑みにしない姿勢は、安全な活用の基本と言える。具体的には次のような照合が考えられる。

  • 数行を抜き出し、電卓や手計算で結果を確かめる
  • ピボットテーブルなど、別の集計方法による結果と合計値を比べる
  • 件数や合計金額が、元データと一致しているかを確認する

数式が動いていても結果が誤っている場合があるため、この検算が最後の砦となる。

修正を重ねて混乱したら、条件を整理して再依頼する

同じ会話の中で修正を繰り返すと、古い前提が残ったり、AIが以前の回答と矛盾する内容を返したりして、混乱する場合がある。その場合は、新しい会話を開き、現在の条件(データ構成、使用バージョン、やりたいこと、これまでに判明した問題点)を整理して、改めて依頼する方法がある。型1の形式で、確定した情報だけを書き直す形になる。

5つの型は実際の業務でどう使い分ければよいのか

作業の性質で手段を選ぶ

関数、Power Query、VBAは、向く作業が異なる。

手段 向く作業 主な型
関数 セル単位の計算、条件付き集計、単発の処理 型1・型2・型5
Power Query 毎月・毎週のように繰り返す、取り込み・整形・結合の定期処理 型2・型3・型5
VBA 画面操作そのものの自動化(シートの作成、印刷、ファイル保存など) 型2・型4・型5

「関数→Power Query→VBA」の順で検討する

手段を選ぶ際は、まず関数で実現できないかを考え、難しければPower Query、それでも足りなければVBAという順で検討すると、リスクを抑えやすいと見られる。

  • 関数は、セルを見れば計算内容を確認でき、元データを書き換える心配も小さい
  • Power Queryは、元データを保持したまま変換結果を別に出力でき、ステップも確認できる
  • VBAは自由度が高い反面、元データの変更や削除が可能で、確認の負担も大きい

手段の力が強いほど、確認の負担とリスクも大きくなる。必要な範囲で最も小さな手段を選ぶことが、安全性の観点で合理的と言える。

型をテンプレートとして共有する

型は、個人のメモにとどめず、チームのテンプレートとして共有する運用も考えられる。たとえば、次のような形である。

  • 型1〜5のプロンプトを、社内の共有ドキュメントに雛形として保存する
  • 「使用バージョン」「入力してはいけない情報」など、組織共通の前提をあらかじめ雛形に書き込んでおく
  • うまくいったプロンプトと、その検算方法を事例として蓄積する

共有しておけば、担当者によるばらつきが減り、新しく利用を始める人も同じ水準で始

Share:
View all posts