データ構造を具体的に伝える
AIを活用してExcel業務を自動化しようとする際、最も頻繁に発生し、かつ最も解決が容易なトラブルの一つが「データ範囲の認識ズレ」です。あなたが「この表を集計して」とAIに頼んだとき、あなたの脳内には具体的な表のイメージがありますが、AIには真っ暗な画面しか見えていません。多くのAIは、指示がない限り「表はA1セルから始まり、1行目がヘッダーで、データは連続している」という理想的な（しかし現実には稀な）状態を勝手に仮定してコードを書きます。
現実のExcelファイルは、タイトルが大きく1行目にあり、表は3行目から始まっていたり、途中に空白行があったり、結合セルが存在したりと複雑です。この「あなたの目の前の現実」と「AIの仮定」のギャップを埋める作業こそが、ステップ7のテーマである「データ構造の具体的な伝達」です。このスキルを習得すれば、AIが生成するコードは「動かないサンプルコード」から「あなたの業務ですぐに使える実用ツール」へと劇的に進化します。
AIは画面を見られない：「A1セルバイアス」の罠を理解する
私たちがExcelを開くとき、視覚的に情報を処理しています。「売上データは真ん中のあのあたりにあるな」「右側には備考欄があるな」と一瞬で把握できます。しかし、ChatGPTやGeminiといったテキストベースのAIには、画像認識機能を使わない限り「視覚」がありません。彼らはテキスト情報だけで世界を構築しなければならないのです。
ここで発生するのが「A1セルバイアス」とも呼べる現象です。具体的な座標指示がない場合、AIは確率的に最もありふれたExcelの構造、すなわち「A1セルから表が始まっている」という前提でコードを生成する傾向があります。例えば、「C列の合計を出して」と頼むと、AIは「1行目からデータが始まっている」あるいは「1行目はヘッダーで2行目からデータ」と勝手に解釈します。もしあなたの表が、上部に3行の余白やタイトル行を持っていて、実際のデータが5行目から始まっていた場合、AIが作ったマクロはタイトル行や空行まで計算に含めてしまい、エラーや誤った集計結果を引き起こします。
さらに厄介なのが、AIは「空気を読んで」くれない点です。人間なら「表の上にあるタイトルは集計しないだろう」と推測できますが、AIは指示されなければタイトルも「文字列データ」として処理しようとし、数値計算で型エラー（Type Mismatch）を起こすことがよくあります。したがって、プロンプトを作成する際は、AIに対して「あなたは目隠しをしている」という前提に立ち、盲目のパートナーに道案内をするように、データの座標と構造を言葉で説明する責任があるのです。
「ActiveSheet」依存の危険性とシート名の明示的指定
VBAマクロにおける最大の事故要因の一つに「ActiveSheet（アクティブシート）」への依存があります。AIに単に「データを転記して」と依頼すると、AIはしばしば Range("A1").Value のように、シートを指定しないコードを書きます。これは「現在開いているシートのA1セル」を意味します。
開発中は対象のシートを開いているため問題なく動作しますが、実務では別のシート（例えばメニュー画面や集計結果シート）を開いた状態でマクロボタンを押すことがあります。すると、マクロは「今見ている無関係なシート」のデータを上書きしたり、削除したりしてしまいます。これはデータ消失事故の典型的なパターンです。
これを防ぐためには、プロンプトで必ず「シート名」を固有名詞で定義する必要があります。「現在開いているシートではなく、必ず “売上管理” シートを対象に処理を行ってください」と指示することで、AIは Worksheets("売上管理").Range("A1") というように、対象を限定した安全なコードを生成します。シート名が決まっていない場合でも、「”Sheet1″ を対象としてください」や「処理対象のシートを変数で設定できるようにしてください」と指示し、コードの中でシート指定箇所を明確にさせることが重要です。これにより、どのシートが開かれていようと、マクロは正しい場所を見つけ出して処理を行えるようになります。
「表の開始位置」の座標定義：ヘッダーとデータの境界線
実務で使われるExcelシートは、A1セルからきれいにデータが始まっていることの方が稀です。請求書や見積書のように、上部に宛名や日付、会社ロゴなどがあり、明細データはずっと下の行から始まるケースが多々あります。この「開始位置のズレ」をAIに伝えないことが、多くのエラーの原因です。
プロンプトでは、「ヘッダー行（項目名）」が何行目にあり、「実際のデータ」が何行目から始まるのかを、正確な行番号で伝える必要があります。例えば、「データは “請求明細” シートにあります。ヘッダー行は10行目で、データは11行目から始まります」と明記します。
また、列方向の開始位置も重要です。「表はB列から始まり、F列まで続きます」といった情報も併せて伝えます。もし表の左側（A列）に余白列がある場合、AIにそれを伝えないと、AIはA列をデータの1列目だと勘違いして処理を記述してしまいます。 「ヘッダーの位置」と「データの開始位置」。この2つの座標を与えるだけで、AIは表の全体像を正しく認識し、ループ処理の開始地点（例：For i = 11 To ...）を正確に設定できるようになります。
データの「最終行」の動的取得：データは増減する生き物である
Excelのデータ行数は日々変動します。今日は100行でも、来月は200行になっているかもしれません。しかし、初心者がAIに指示を出す際、「A1からA100までを集計して」と具体的な範囲を指定してしまうことがあります。するとAIは、素直に Range("A1:A100") という固定範囲のコードを書きます。これでは、データが101行目以降に増えたときに、それらが集計から漏れてしまいます。
これを防ぐためには、「データの行数は可変（増減する）である」という前提をAIに伝え、「最終行を自動的に取得するコードにしてください」と指示する必要があります。VBAには、データが入っている最後の行を自動で見つけるテクニック（例：Cells(Rows.Count, 1).End(xlUp).Row）があります。AIはこの定石を知っていますが、指示されなければ固定範囲で書くこともあります。
プロンプトには必ず「データ件数は変動するため、A列の最終行を動的に取得してループ処理を行ってください」という一文を加えましょう。これにより、データが1件の時でも10万件の時でも、正しくデータの終わりまでを処理できる堅牢なマクロが完成します。
列の役割とデータ型（Type）の定義：数値か文字列か
人間が見れば「1,000」は数値だと分かりますが、Excel上では「文字列」として保存されている場合があります。また、日付に見える「2025/12/01」が、実は単なる文字の羅列であることもあります。VBAで計算や比較を行う際、この「データ型」の違いは致命的なエラーや判定ミスを引き起こします。
AIにデータ構造を伝える際は、各列に「何が入っているか」だけでなく、「どのような形式（型）で入っているか」まで伝えると精度が向上します。 例えば以下のように記述します。
• A列：ID（文字列、例：”A001″）
• B列：売上日（日付形式、yyyy/mm/dd）
• C列：金額（数値、カンマあり）
特にIDなどは、数字だけで構成されていても「001」のように頭に0がつく場合、数値として扱うと「1」になってしまい情報が変わってしまいます。「文字列として扱ってください」と指示することで、AIはデータを壊さない適切な処理（CStr関数など）を用いたコードを生成します。
イレギュラーなデータの扱い：結合セルと空白セルの罠
Excelの「セルの結合」は、見た目を整えるには便利ですが、プログラミング（VBA）にとっては悪夢のような存在です。結合されたセルは、VBAからは左上のセルだけに値が入っているように見えたり、範囲指定が複雑になったりするため、予期せぬエラーの温床となります。
もし処理対象の表に結合セルが含まれている場合は、必ずその事実をAIに伝えてください。「A列のセルは行方向に結合されています」や「ヘッダーは2行分結合されています」といった情報です。AIはそれを考慮して、MergeAreaプロパティを使ったり、結合を解除して処理するロジックを提案したりしてくれます。
また、データ途中の「空白セル」も問題になります。AIが書くループ処理の多くは、「空白セルに当たったらそこで表が終わりだと判断して停止する」というロジックを採用しがちです。しかし、実際には「備考欄だけ空白」という行もあるでしょう。 「途中に空白セルが含まれる可能性があるため、最終行の取得にはEnd(xlUp)を使用し、途中で止まらないようにしてください」や「B列が空白でもスキップせずに処理してください」といった例外処理の指示を加えることで、データの取りこぼしを防ぐことができます。
構造化プロンプトの実践：データ定義テンプレートの活用
ここまで解説した要素を、毎回文章で説明するのは大変です。そこで、第6ステップで学んだ「プロンプトの型」の中に、「#入力データ構造」という専用のセクションを設け、箇条書きで定義するテンプレートを活用しましょう。
以下のようなフォーマットを推奨します。
#入力データ構造
・対象ブック：現在のアクティブなブック
・対象シート名："受注リスト"
・ヘッダー位置：3行目
・データ開始位置：4行目
・データ最終行：可変（A列を基準に自動取得）
・列構成：
- A列：受注番号（文字列、ユニークキー）
- B列：受注日（日付）
- C列：顧客名（文字列）
- D列：受注金額（数値、空白の場合は0とみなす）
このように構造化して記述することで、AIはコードを書くための「設計図」を正確に読み取ることができます。自然言語で「えーっと、3行目が見出しで…」と書くよりも、圧倒的にトークン（文字数）の節約になり、かつAIの解釈ミスも減ります。このテンプレートを辞書登録しておき、マクロ作成のたびに呼び出して埋めるだけで、作業効率は格段に上がります。
マスキングとダミーデータによる構造伝達のセキュリティ
データ構造を詳細に伝える際、絶対に守るべきルールがあります。それは「実際の機密データをそのまま書かない」ことです。第3章のリスク管理でも触れましたが、プロンプトに「顧客名：トヨタ自動車」などと具体名を書く必要はありません。
AIが必要としているのは「具体的な中身」ではなく「データの性質」です。「トヨタ自動車」という情報の代わりに、「文字列（企業名）」あるいはダミーデータとして「株式会社A」と書けば十分です。金額も「1億2345万円」と書く必要はなく、「数値（通貨）」や「10000」で伝わります。
データの中身を抽象化（マスキング）して伝えることは、セキュリティを守るだけでなく、AIに「この値は可変である（固定値ではない）」と認識させる効果もあります。具体的な値を入れると、AIがその値専用の（汎用性のない）コードを書いてしまうリスクがあるため、あえて「文字列」「数値」といった型情報やダミーデータで構造を伝えるテクニックは、質の高いコード生成にも寄与します
GeminiとChatGPTの特性に合わせた伝え方の微調整
最新のGPT-5.2（ChatGPT）とGemini 1.5 Proでは、データ構造の理解力に若干の「性格差」があります。
ChatGPTは非常に論理的で、提示されたデータ構造（テンプレート）を厳密に守ろうとします。したがって、先述のテンプレート形式でカチッと条件を渡すと、非常に精度の高いVBAコードを一発で出力します。変数名やデータ型も指示通りに実装してくれるため、実務の実装フェーズではChatGPTが強力です。
一方、Geminiはコンテキスト（文脈）を読み取る力に長けており、Googleスプレッドシートとの親和性が高いです。もしあなたのデータ構造が複雑で、テンプレートで表現しきれない場合（例：不規則な結合や、複数の表が散在しているなど）、Geminiに対しては自然言語で「この表はちょっと特殊で、A列とB列が結合されているところとされていないところが混ざっています」のように、人間に対するような補足説明を加えると、意図を汲み取ってくれることがあります。また、Geminiは表を画像として認識させる（マルチモーダル機能）ことも得意なため、言葉で説明しづらい構造の場合は、ダミーデータを入れたスクリーンショットを貼り付けて「この表構造を読み取ってVBAを書いて」と指示するのも有効な手です。
結論：「定義力」こそがAI時代のプログラミング能力
「AIにコードを書かせる」というと、人間は何も考えなくて良いように思えます。しかし実際は逆です。人間は、これまで以上に自分の扱っているデータが「どのような構造になっているか」を深く理解し、それを言語化する能力（定義力）が求められます。
自分が普段何気なく使っている表が、どこから始まり、どこで終わり、どんなデータを含んでいるのか。それをAIという他者に説明できるレベルまで解像度を高めること。これこそが、AI時代の新しい「プログラミング能力」です。
コードの構文（If文やFor文）の書き方を覚える必要はありません。その代わり、「データの地図」を正確に描く練習をしてください。正確な地図さえ渡せば、AIという優秀なドライバーは、あなたを目的地（業務自動化）まで最短ルートで連れて行ってくれます。まずは手元のExcelファイルを開き、その構造を言葉で書き出すことから始めてみましょう。