AIがスプレッドシートを扱う時代の「最強の指示書」: 列・条件・例外の書き方（参考プロンプト付き）
スプレッドシートをAIに扱わせる仕事は、2024年から2025年にかけて大きく変わった。以前は「この表を整理して」のような曖昧な依頼でもたまたま動けば十分と考えられがちだったが、現在の実務ではそれでは足りない。最新の研究と実装事例を追うと、精度を左右しているのはモデルの大きさだけではなく、列の定義、条件の優先順位、例外の扱い、出力形式の固定をどれだけ明示できるかにある。結論から言えば、AI向けの指示書は「自然言語のお願い」ではなく、表の仕様書として書くのが最も強い。
![[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]](https://hbb.afl.rakuten.co.jp/hgb/52d5546c.1d5dcb6f.52d5546d.353e37f8/?me_id=1400231&item_id=10001200&pc=https%3A%2F%2Fimage.rakuten.co.jp%2Fugreen-gear%2Fcabinet%2Fbiiino%2Fitem%2Fmain-image-2%2F20250314182744_7.jpg%3F_ex%3D128x128&s=128x128&t=picttext "[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]")
- なぜ今、スプレッドシート向けの指示書が重要なのか
- 最新動向1: 表はそのまま渡すより、構造を圧縮して渡す方向に進んでいる
- 最新動向2: 成功しているシステムほど、列の意味を言語化している
- 最新動向3: 条件は“箇条書き”より“優先順位つきのルール”で書くほうが強い
- 最新動向4: 例外は“最後に補足”ではなく“最初から仕様化”する
- 最新動向5: いま強いのは「自然言語だけで終えない」プロンプト
- 実務でそのまま使える「最強の指示書」テンプレート
- すぐ使えるプロンプト例1: 売上集計
- すぐ使えるプロンプト例2: 異常値検知
- すぐ使えるプロンプト例3: 関数生成
- すぐ使えるプロンプト例4: データクレンジング指示
- “弱い指示”と“強い指示”の差
- 2025年時点の実務的な結論
- 参考文献・参照
なぜ今、スプレッドシート向けの指示書が重要なのか
背景には3つの変化がある。第1に、研究の中心が「表を読めるか」から「表に対して複数段の操作を安全に実行できるか」へ移った。第2に、単に表をテキスト化して渡すだけではなく、コード生成やツール実行を組み合わせる方式が主流化してきた。第3に、現場で扱う表は、欠損値、列名の揺れ、例外ルール、集計前提など、人間には暗黙だがモデルには暗黙でない条件に満ちているためだ。
2024年のA Survey of Table Reasoning with Large Language Modelsは、LLMによる表推論が主流になった一方で、性能改善の鍵が表現方法、外部ツール利用、推論分解にあると整理した。2025年のSheetAgentは、実世界の長手順スプレッドシート操作を想定した評価で、Planner・Informer・Retrieverを分離したエージェント設計がベースラインを20〜40%上回ると報告している。さらにSemEval 2025の表QAシステムでは、表をそのまま読むより、Pandas関数やSQLを生成して実行する流れが高精度化の中核になっている。つまり、AIに渡す指示も「何を考えるか」だけでなく、「どの列を使い」「どんな条件で抽出し」「例外時にどう振る舞い」「何の形式で返すか」まで固定する必要がある。
最新動向1: 表はそのまま渡すより、構造を圧縮して渡す方向に進んでいる
Microsoft ResearchのSpreadsheetLLM: Encoding Spreadsheets for Large Language Modelsは、スプレッドシート全体を長いテキストとしてそのまま入力する方法の限界を示し、セルアドレス、構造、レイアウトを保ちながら圧縮するエンコーディングを提案した。実務上この示唆は大きい。AIへの指示書でも、表の全情報を丸投げするより、対象列・使用範囲・参照単位を先に限定したほうが精度とコストの両方で有利だからだ。
言い換えると、指示書の最初に書くべきなのは「この表を見て」ではない。まずは次のように、処理対象の座標系を固定する。
対象シート: 売上実績
対象範囲: A1:H5000
主キー列: 注文ID
日付列: 受注日
金額列: 売上金額
担当列: 営業担当
判定対象は2行目以降。見出し行は処理しない。このような書き方は単なる丁寧さではなく、最新研究でいう「構造を保った情報提示」に相当する。AIが誤ってヘッダ行や注記行を処理対象に含める事故を減らしやすい。
最新動向2: 成功しているシステムほど、列の意味を言語化している
表の処理エラーの多くは、計算能力ではなく列の意味解釈のズレから起きる。たとえば「金額」は税抜か税込か、「日付」は受注日か出荷日か、「担当者」は現在担当か初回担当か、が明示されていないだけで結果は大きく変わる。研究コミュニティでも、列名だけでは不十分で、ヘッダ説明やメタデータを加える設計が一貫して重視されている。
SemEval 2025のI2R-NLP at SemEval-2025 Task 8では、回答型の特定、Pandas関数生成、エラー修正という多段設計が有効だった。ここで重要なのは、モデルに「この質問は何型の答えを返すべきか」を先に決めさせている点だ。業務の指示書でも同じで、列の意味だけでなく、最終出力の型を先に固定すると大幅に安定する。
強い指示書の基本形は以下になる。
列定義:
- 注文ID: 1注文を一意に識別するID。同一IDの重複行がありうる。
- 売上金額: 税抜の整数。返金は負数。
- 受注日: YYYY-MM-DD形式。空欄は未登録。
- ステータス: 受注 / 出荷済 / キャンセル のいずれか。
出力:
- 集計結果はJSONで返す
- 金額は数値のまま返す
- 該当なしは0ではなく null を返すAIは「何が入っている列か」だけでなく、「どのように返すべきか」が決まると急に強くなる。これは近年の表QAが、自由文生成よりもコード生成や構造化出力へ寄っている流れとも一致する。
最新動向3: 条件は“箇条書き”より“優先順位つきのルール”で書くほうが強い
スプレッドシート実務では条件同士が衝突する。たとえば「キャンセルは除外」と「返金は含める」が同時に存在すると、キャンセル返金をどう扱うかが問題になる。人間は文脈で補うが、AIは補完方法を勝手に決めてしまう。そこで必要なのが、条件を単に列挙するのではなく、優先順位つきルールとして記述することだ。
SheetAgentのような近年の設計が、長手順操作でPlanと情報取得を分離しているのは、曖昧な要求を一気に解こうとすると失敗しやすいからだ。現場のプロンプトでも同じで、条件を上から順に評価するよう定義するだけで事故率が下がる。
判定ルールの優先順位:
1. ステータスが「キャンセル」の行は集計対象外
2. ただし返金理由列が埋まっている場合は、売上金額の負数として返金集計に含める
3. 受注日が空欄の行は日別集計から除外し、別途「日付不備件数」に加算する
4. 同じ注文IDが複数ある場合は最新更新日時の行だけを採用するこの形式は、AIが複数条件を同時に満たす行に遭遇したときの迷いを減らす。「どれが例外で、どれが原則か」を明示することが重要だ。
最新動向4: 例外は“最後に補足”ではなく“最初から仕様化”する
最新の表理解研究では、欠損、表記揺れ、視覚レイアウト、空セル、注記、結合セルが難所として繰り返し指摘されている。Microsoft ResearchのVision Language Models for Spreadsheet Understanding: Challenges and Opportunitiesでも、VLMはOCR自体は有望でも、セル抜けや位置ずれ、書式認識不足が問題になると報告されている。つまり、見た目で理解できそうに見えても、例外処理は依然として人間が明示すべき領域だ。
強いプロンプトでは例外を書き漏らさない。特に次の4種は最初から規定する価値が高い。
- 欠損値例外: 空欄、N/A、ハイフン、0を同じ扱いにするか分けるか
- 表記揺れ例外: 「東京」「東京都」「Tokyo」を同一カテゴリに寄せるか
- 重複例外: 重複注文や再登録行をどう扱うか
- 境界例外: ヘッダ下の注記行、合計行、途中の小見出し行を処理対象に含めるか
例外指定の書き方は、次のように短くても十分効く。
例外処理:
- 空欄、"N/A"、"-" は欠損として同じ扱いにする
- 地域名は "東京" と "東京都" を同一扱いに正規化する
- 最終行の "合計" 行は集計対象から除外する
- コメント列の自由記述は判定に使わない最新動向5: いま強いのは「自然言語だけで終えない」プロンプト
2025年の表QAシステム群を見ると、成績が良いものほど、AIに自由回答させるのではなく、SQLやPandasのような中間表現を作らせ、それを実行・検証させている。これは「AIに賢く読ませる」より「AIに手続きを明示させる」ほうが強いことを意味する。実務でも、可能なら以下のどちらかを指示に含めるべきだ。
- 途中で使う疑似手順を指定する
- 最終出力をJSON・CSV・式・関数などの構造化形式に固定する
たとえば、単なる依頼文より、以下のほうが再現性が高い。
手順:
1. 対象範囲からキャンセル行を除外
2. 注文IDごとに最新更新日時の行を残す
3. 営業担当別に売上金額を合計
4. 上位5件を降順で返す
出力JSONスキーマ:
{
"generated_at": "ISO8601 string",
"top_sales_reps": [
{"name": "string", "sales": "number"}
],
"excluded_rows_reason_summary": {
"cancelled": "number",
"missing_date": "number"
}
}この書き方だと、AIが途中で何をするか、どの例外をどう数えるかが明確になる。
実務でそのまま使える「最強の指示書」テンプレート
以下は、最新研究の示唆を実務向けに圧縮したテンプレートである。ポイントは、列、条件、例外、出力、禁止事項を独立セクションで書くことだ。
あなたはスプレッドシート分析アシスタントです。
[対象]
- シート名: {シート名}
- 範囲: {A1表記}
- 見出し行: {行番号}
- データ開始行: {行番号}
[列定義]
- {列名1}: {意味、型、注意点}
- {列名2}: {意味、型、注意点}
[目的]
- {何を抽出・集計・分類したいか}
[判定ルール]
1. {最優先ルール}
2. {次点ルール}
3. {境界条件}
[例外処理]
- {空欄の扱い}
- {重複の扱い}
- {表記揺れの扱い}
- {除外行の扱い}
[出力形式]
- 形式: JSON / CSV / 数式 / 箇条書き
- 必須項目: {項目名}
- 該当なしの表現: null / 空配列 / "該当なし"
[禁止事項]
- 列の意味を推測で補わない
- 指定されていない列は使わない
- 不明点があれば assumptions に明記するすぐ使えるプロンプト例1: 売上集計
あなたは表データ分析アシスタントです。
売上実績シート A1:H5000 を処理してください。
列定義:
- A列 注文ID: 1注文の一意ID
- B列 受注日: YYYY-MM-DD
- C列 営業担当: 担当者名
- D列 地域: 地域名。東京と東京都は同一扱い
- E列 売上金額: 税抜整数。返金は負数
- F列 ステータス: 受注 / 出荷済 / キャンセル
- G列 更新日時: 行の新しさ判定に使う
目的:
- 2025年Q1の営業担当別売上合計を算出し、上位10名を返す
条件:
1. ステータスがキャンセルの行は除外
2. ただし返金として記録された負数行は返金額として含める
3. 同一注文IDが複数ある場合は更新日時が最も新しい行のみ採用
例外:
- 受注日が空欄の行は集計から除外し、件数だけ記録
- 地域列は東京と東京都を同一カテゴリに正規化
- 最終行の合計行は除外
出力:
- JSON
- top10_reps, excluded_missing_date_count, assumptions を含める
- 金額は数値で返すすぐ使えるプロンプト例2: 異常値検知
在庫一覧シートを分析し、異常値候補を抽出してください。
対象列:
- 商品ID
- 商品名
- 在庫数
- 先週在庫数
- 更新日
異常値条件:
1. 在庫数が0未満なら異常
2. 在庫数が先週在庫数の3倍超なら異常候補
3. 更新日が30日以上前なら stale フラグを付与
例外:
- 廃番フラグが true の商品は除外
- 先週在庫数が空欄なら倍率判定をしない
出力:
- CSV形式
- 列は 商品ID, 商品名, anomaly_reason, stale_flag
- anomaly_reason は複数理由を | で連結するすぐ使えるプロンプト例3: 関数生成
次の要件を満たす Excel / Google Sheets 向けの式を1つ提案してください。
要件:
- 受注日が今月
- ステータスが "出荷済"
- 地域が "東京" または "東京都"
- 売上金額が 100000 以上
例外:
- 受注日が空欄なら除外
- 金額が文字列なら数値変換を試みる
出力:
- まず式を提示
- 次に各条件がどの部分に対応するかを1行ずつ説明
- 利用する列参照の前提を明記するすぐ使えるプロンプト例4: データクレンジング指示
顧客マスタを正規化してください。
正規化ルール:
1. 全角スペースと半角スペースを統一
2. 株式会社表記の有無は会社名比較時に無視
3. 電話番号はハイフンを除去して数字のみ保持
4. 都道府県名は正式名称へ統一
例外:
- 空欄は空欄のまま保持
- 備考列は変更しない
- 郵便番号の先頭ゼロは落とさない
出力:
- 変更後データ
- 変更点サマリー
- 自信が低い正規化候補一覧“弱い指示”と“強い指示”の差
弱い指示は、対象列、評価順序、例外、出力形式のどれかが抜けている。強い指示は、AIが迷うポイントを先回りして埋めている。次の比較がわかりやすい。
弱い指示:
「売上データを見て担当者別に集計して。おかしいデータは除いて」
強い指示:
「売上実績シート A1:H5000 を対象に、2行目以降を処理してください。
担当者別売上合計を算出します。キャンセル行は除外し、同一注文IDは更新日時が最新の行のみ採用します。
受注日空欄は除外して件数を記録してください。結果は JSON で返し、top10_reps と excluded_missing_date_count を含めてください。」差は情報量の多さではない。曖昧さの少なさである。
2025年時点の実務的な結論
2025年時点で最も再現性が高いのは、AIを“表の読心術師”として扱う方法ではなく、明示的な列仕様・条件順位・例外規定・構造化出力を守るオペレーターとして使う方法である。最新研究は、表を圧縮表現で与える工夫、長手順操作を分解するエージェント設計、コード生成と実行による検証、視覚表現の弱点補完へと進んでいる。実務のプロンプトも同じ方向へ寄せるべきだ。
要するに、AIにスプレッドシートを扱わせるなら、最強の指示書とは「うまく察してほしい文章」ではない。どの列を使い、どの条件をどの順で適用し、どの例外をどう処理し、どの形で返すかを固定したミニ仕様書である。ここまで書けば、モデルが変わっても、ツールが変わっても、成果の再現性は大きく落ちにくい。
参考文献・参照
- SheetAgent: Towards A Generalist Agent for Spreadsheet Reasoning and Manipulation via Large Language Models, arXiv / WWW 2025
- SpreadsheetLLM: Encoding Spreadsheets for Large Language Models, Microsoft Research, 2024
- A Survey of Table Reasoning with Large Language Models, arXiv, 2024
- I2R-NLP at SemEval-2025 Task 8: Question Answering on Tabular Data, ACL Anthology, 2025
- Vision Language Models for Spreadsheet Understanding: Challenges and Opportunities, Microsoft Research / ACL Workshop, 2024
コメント