処理手順を箇条書きにする
AIを活用してExcelの業務自動化を行う際、多くの人が陥る最大の落とし穴は、人間同士の会話と同じ感覚で指示を出してしまうことです。「A列を並び替えてから重複を削除して、もし空白があったら詰めておいて」といった文章による指示は、人間には通じても、AIにとっては論理的な迷路のようなものです。特にVBAマクロのような正確な手順が求められるプログラム生成において、この曖昧さは致命的なエラーや予期せぬ動作を引き起こします。
本記事では、AIから正確で高品質なコードを引き出すための最も強力かつ基本的なテクニックである「処理手順の箇条書き（構造化）」について解説します。文章を分解し、論理的なステップとして定義し直すこのプロセスは、単なる書き方のテクニックではありません。それは、業務そのものをアルゴリズムとして再構築する「開発者」としての思考法そのものです。2025年12月現在の最新モデルであるGPT-5.2やGemini 1.5 Proの性能を極限まで引き出し、手戻りのない自動化を実現するための核心に迫ります。
なぜ「文章による指示」はVBA生成において失敗するのか
私たちが普段使っている自然言語は、非常に文脈依存度が高く、省略や曖昧さを多く含んでいます。「売上データを整理して」という一言には、「不要な列を削除する」「日付順に並べる」「書式を整える」といった複数の意味が含まれている可能性がありますが、それは受け手の解釈に委ねられています。人間同士であれば「いつものあれ」で通じますが、AIにはその「阿吽の呼吸」は通用しません。
文章で「AをしてBをしてCをする」と繋げて指示を出した場合、AI、特に大規模言語モデル（LLM）は、文中の接続詞や修飾語の関係性を解析するのに計算リソース（注意機構）を割くことになります。その結果、文が長くなればなるほど、後半の指示を忘れたり、前の指示と混同したりする「指示の希釈化」が発生しやすくなります。例えば、「A列が空白でなければB列に値を転記し、そうでなければC列を削除して、最後に保存する」といった指示では、「そうでなければ」が「A列が空白の場合」にかかるのか、「転記が失敗した場合」にかかるのか、AIが誤読するリスクが高まります。
VBAは、コンピュータに対する命令の集合体であり、その本質は「順序」と「論理」です。曖昧な自然言語を、厳密なプログラミング言語に変換する作業をAIに丸投げすると、AIは確率的に最もありそうな解釈を選びます。それがあなたの意図と一致する保証はどこにもありません。結果として、動かないコードや、意図とは異なるデータを削除してしまう危険なマクロが生成されることになります。この「解釈のズレ」をなくす唯一の方法が、自然言語の段階でプログラミング言語に近い構造、すなわち「箇条書き」に落とし込むことなのです。
プログラミングの3大要素「順次・分岐・反復」を意識する
VBAに限らず、あらゆるプログラミングは「順次（Sequence）」「分岐（Selection）」「反復（Iteration）」という3つの基本構造の組み合わせで成り立っています。AIに的確な指示を出すためには、あなたのやりたい業務をこの3つの要素に分解し、箇条書きとして表現する必要があります。
「順次」とは、処理を上から順番に行うことです。「ファイルを開く」「データをコピーする」「ファイルを閉じる」といった手順です。これを「ファイルを開いてコピーして閉じる」と一行で書くのではなく、番号付きリストで表現することで、AIはコードの実行順序を明確に認識できます。
「分岐」とは、条件によって処理を分けることです。「もしAならBをする」という処理です。これを箇条書きの中で表現する場合、「3. A列の値が100以上の場合、文字色を赤にする」というように、条件とアクションを明確に記述します。文章の中に条件分岐が埋め込まれていると、AIは「条件」と「結果」の対応関係を見誤ることがありますが、箇条書きであればそのリスクを最小限に抑えられます。
「反復」とは、同じ処理を繰り返すことです。「1行目から最終行まで繰り返す」という指示です。箇条書きでは「2. 以下の処理を最終行まで繰り返す」と宣言し、その下にインデント（字下げ）をして繰り返したい処理を記述することで、ループの範囲（スコープ）を視覚的にも論理的にも明確に伝えることができます。この3つの構造を意識して箇条書きを作ることは、AIに対する「仕様書」を書くことと同義であり、開発者としての必須スキルと言えます。
「Structured Chain-of-Thought（SCoT）」：構造化がAIの脳を活性化する
最新のAI研究において、「Structured Chain-of-Thought（SCoT）」という概念が注目されています。これは、AIに対して単に答えを求めるのではなく、プログラムの構造（順次、分岐、反復）を明示した中間的な思考プロセスを経由させることで、コード生成の精度が劇的に向上するという理論です。
従来の「Chain-of-Thought（思考の連鎖）」プロンプトでは、自然言語で思考過程を記述させていました。しかし、SCoTでは、その思考過程自体を構造化します。つまり、私たちがプロンプトで「箇条書き」を使って指示を出すことは、AIに対してこのSCoTを実行させるための「誘導」になっているのです。
具体的には、箇条書きで手順を示すことで、AIはコードを書き始める前に、全体のアルゴリズムを設計することができます。「まずはデータの読み込みが必要だ」「次にループ処理が必要だ」「ここで条件分岐が必要だ」というプランニングを行ってから、実際のVBAコード（If文やFor文）の生成に移ります。いきなりコードを書かせるのではなく、構造化された日本語でロジックを確定させる。このワンクッションが、複雑なマクロにおける論理破綻やエラーを防ぐ最大の防御壁となります。GPT-5.2などの高度な推論能力を持つモデルほど、この構造化された指示に対して敏感に反応し、人間が書いたかのような整然としたコードを出力してくれます。
劇的ビフォーアフター：文章指示と箇条書き指示の比較
実際に、同じ業務内容を「文章」で伝えた場合と「箇条書き」で伝えた場合で、AIへの伝わり方がどう変わるかを見てみましょう。ここでは、「売上リストから特定の商品を抽出して別シートにまとめる」というよくある業務を例にします。
【悪い例：文章での指示】 「Sheet1にある売上データから、商品名が『パソコン』で、かつ売上が5万円以上のものを探して、それをSheet2にコピーしてほしいんだけど、Sheet2は毎回新しく作って、以前のデータは消しておいて。あ、あとコピーが終わったらメッセージを出して。」
このプロンプトには多くのリスクが潜んでいます。「Sheet2を新しく作って」と「以前のデータは消して」は矛盾する可能性があります（シート自体を削除して作り直すのか、シートの中身をクリアするのか）。また、「コピーして」という指示も、行全体なのか特定のセルなのかが曖昧です。AIは混乱し、場合によってはシート削除のエラーや、不完全なコピー処理を実装してしまうでしょう。
【良い例：箇条書きでの指示】
1. 「Sheet1」の最終行を取得する。
2. 「Sheet2」という名前のシートが存在するか確認し、存在する場合はシート内の全データをクリアする。存在しない場合は新規作成し、名前を「Sheet2」とする。
3. 「Sheet1」の1行目（ヘッダー）を「Sheet2」の1行目にコピーする。
4. 「Sheet1」の2行目から最終行まで、以下の処理を繰り返す。
◦ もしC列（商品名）が「パソコン」かつ、E列（売上）が50,000以上の場合：
◦ その行全体を「Sheet2」の最終行の次の行にコピーする。
5. 処理が完了したら、「抽出完了」というメッセージボックスを表示する。
このように箇条書きにすることで、シートの扱い（クリアか新規作成か）、条件（AND条件であること）、処理の対象（行全体）が明確になります。AIはこの手順通りにコードを翻訳するだけで済むため、解釈の余地がなくなり、精度の高いコードが一発で生成されます。
複雑な処理を「分解」する技術：ネスト（入れ子）構造の活用
実務における自動化は、単純な一本道ではありません。「繰り返しの中に条件分岐があり、その中でさらに別の繰り返しがある」といった複雑な構造（ネスト）になることが多々あります。このような処理を文章で説明しようとすると、「〜して、その中で〜して、でも〜の場合は〜して」と、日本語としても破綻しがちです。
ここで有効なのが、箇条書きの「インデント（字下げ）」を活用した階層構造の表現です。 例えば、複数のブックを処理するマクロを考えてみましょう。
1. 指定したフォルダ内のファイル一覧を取得する。
2. 取得した各ファイルについて、以下の処理を繰り返す。 a. ファイル（ブック）を開く。 b. そのブック内の全シートについて、以下の処理を繰り返す。 i. シート名が「集計」の場合、A1セルの値をメインのブックに転記する。 ii. シート名が「集計」以外の場合、何もしない。 c. ブックを保存せずに閉じる。
3. 全ファイルの処理終了後、完了メッセージを表示する。
このように、親の処理（2）の下に子の処理（a, b, c）、さらにその下に孫の処理（i, ii）を字下げして記述することで、処理の「範囲（スコープ）」をAIに正確に伝えることができます。AIはこのインデント構造をそのままVBAの For...Next や If...End If のブロック構造として認識します。複雑な業務フローであっても、このように分解して階層化すれば、AIは迷うことなく実装できます。人間側にとっても、業務フローの整理になり、論理的な矛盾に気づきやすくなるというメリットがあります。
変数とオブジェクトの定義：AIとの共通言語を作る
箇条書きで手順を示す際、重要になるのが「何を」操作するのかという対象の定義です。文章の中に「あのデータ」や「右側の表」といった曖昧な表現が混ざっていると、手順が正しくてもコードは動きません。箇条書きの中では、Excelの用語（シート名、列番号、行番号）を具体的に指定することが鉄則です。
例えば、「売上を計算する」ではなく、「E列（単価）とF列（数量）を掛け算し、G列（小計）に代入する」と記述します。また、繰り返し処理で使う「変数」についても、プロンプト内で定義しておくとより確実です。「カウンタ変数 i を使用して、2行目から最終行までループする」といった具合です。
さらに効果的なのが、プロンプトの冒頭で「用語定義」を行うことです。 「以下、Sheet1を『元データ』、Sheet2を『出力先』と呼びます」と宣言しておけば、その後の箇条書きで「元データから出力先へコピー」と簡潔に書くことができます。AIは文脈理解能力が高いため、この定義を忠実に守ってコードを生成します。曖昧さを排除し、AIと人間との間で言葉の定義（共通言語）を揃えることが、スムーズな開発への近道です。
エラー処理の組み込み：箇条書きの一項目として明記する
マクロ開発において、初心者が最も見落としがちなのが「エラー処理（例外処理）」です。「ファイルが見つからなかったらどうするか」「データが空だったらどうするか」という想定外の事態に対する指示がないと、AIは「常に正常に動く」ことだけを想定したコードを書きます。その結果、実務で少しでもイレギュラーなデータが入るとマクロが停止し、業務がストップしてしまいます。
これを防ぐためには、処理手順の箇条書きの中に、明示的にエラーチェックのステップを組み込む必要があります。
1. 対象のファイルを探す。
2. 【エラー分岐】もしファイルが見つからない場合、「ファイルがありません」と表示して処理を終了する。
3. ファイルが見つかった場合、ファイルを開く。
4. 【データチェック】もしA列の最終行が1行目（ヘッダーのみ）の場合、「データがありません」と表示して処理を終了する。
このように、手順の中に「チェックポイント」と「失敗時の退路」を箇条書きで加えておくことで、AIは If Dir(FilePath) = "" Then Exit Sub のような安全装置をコードに実装してくれます。プロのエンジニアはコードの半分以上をエラー処理に費やすとも言われます。開発者として、正常なルートだけでなく、異常なルートの処理も手順に含める習慣をつけましょう。
モデルによる特性の違い：ChatGPTの論理とGeminiの文脈
箇条書きプロンプトに対する反応は、AIモデルによって若干の「癖」の違いがあります。これを理解しておくと、よりスムーズに開発が進められます。
ChatGPTは、論理的な構造を非常に好みます。番号付きリストで渡された手順書を、忠実に、かつ厳密にコードに変換しようとします。そのため、箇条書きの順序が間違っていたり、論理が飛躍していたりすると、そのまま間違ったコードが出力される傾向があります。ChatGPTを使う場合は、箇条書きのロジックが正しいかどうか、人間側がしっかりチェックする必要があります。その分、指示通りに動く堅牢なコードが得られます。
一方、Geminiは、文脈を読み取る力が強く、多少箇条書きが雑でも「おそらくこういうことだろう」と補完してコードを書いてくれる傾向があります。また、Google Workspaceとの連携が強いため、スプレッドシートのGAS（Google Apps Script）を生成する際は、箇条書きの中に「スプレッドシートの関数を使って」といった自然言語的なニュアンスを含めても柔軟に対応してくれます。ただし、その「気の利かせ方」が意図と異なる場合もあるため、やはり箇条書きで制約をかけることは重要です。どちらのAIを使うにせよ、構造化された指示は共通して有効な最良の手段です。
プロンプト自体をデバッグする：コードを書かせる前の確認作業
箇条書きで手順を作成したら、いきなり「コードを書いて」と依頼する前に、ワンステップ置くことをお勧めします。それは、AIに「この手順で論理的に問題がないかレビューして」と依頼することです。
「以下の箇条書きは、在庫管理システムの自動化手順です。この手順に論理的な矛盾や、実行時にエラーになりそうな箇所はありますか？コードを書く前に指摘してください」とAIに投げかけます。すると、AIはシミュレーションを行い、「手順3でファイルを閉じていますが、手順4でそのファイルからデータを読み込もうとしています。これではエラーになります」といった鋭い指摘をしてくれることがあります。
この「プロンプトのデバッグ（修正）」を行うことで、コード生成後の手戻りを大幅に減らすことができます。AIは単なるコーダーではなく、優秀なレビュアーでもあります。箇条書きという設計図の段階で品質を高めておくことが、結果として最短でツールを完成させる秘訣です。
開発者への進化：思考を整理する訓練としての箇条書き
「処理手順を箇条書きにする」という行為は、単にAIへの命令文を作る作業ではありません。それは、あなた自身の頭の中にある業務プロセスを棚卸しし、整理し、最適化する作業そのものです。
なんとなく行っていた手作業を一つ一つの動作に分解し、言葉にする。その過程で、「あ、この作業は実は無駄だったかも」「ここの順番を変えたほうが効率的だ」という業務改善の気づきが得られることも少なくありません。AIを活用した自動化に取り組むことは、業務フローそのものを見直す絶好の機会なのです。
あなたはもう、誰かが作ったツールを使うだけのユーザーではありません。業務をロジックとして定義し、AIという強力なエンジンを使ってそれを実装する「開発者」です。箇条書きというシンプルなツールを武器に、複雑な業務を支配下に置き、自由な時間を創出してください。その第一歩が、今開いているプロンプトの入力欄に「1. 」と打ち込むことから始まります。