Skip to Content
Docs13. ドメイン応用表計算・構造化データ操作エージェント
中級spreadsheetstructured-dataverificationexcel更新: 2026-09-10この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

表計算・構造化データ操作エージェント

この記事の目的

「業務の共通言語」である表計算(セル・数式・複数シート)を読み書きするエージェントを、壊さない・黙って間違えない構造で設計できるようになります。表の理解の難しさ・数式と値の使い分け・変更の差分承認・再計算による検証・大規模シートの分割・データ分析エージェントとの分担を、実務の判断として持ち帰れる状態を目指します。

対象読者

  • Excel・スプレッドシートを読み書きするエージェント(集計・転記・レポート作成の自動化)を設計するエンジニア
  • 現場の「生きた Excel」を壊さずに自動化したい業務部門・情報システム担当

前提知識

本文

概要: 表計算は「表」ではなく「生きた計算モデル」

スプレッドシートは、一見ただの表ですが、実際には数式で相互に依存し合う計算モデルです。あるセルの変更は、それを参照する数式の結果に影響します。ただし実際の再計算はアプリの計算モードや実行環境によります。Excel の再計算仕様 には自動・手動の設定があります。この「生きている」性質が、表計算エージェントの難しさの核心です。値だけを見て 1 セルを直すと、遠くの集計や条件分岐を静かに壊すことがあります。

したがって設計の中心は「壊さない・黙って間違えない」ことです。データ分析エージェントが「読み取って集計する」のに対し、表計算エージェントは「既存のブックを編集する」ため、破壊のリスクが加わります。以下の各節は、この破壊と誤りを防ぐ設計に収束します。帳票・PDF からの抽出(ドキュメント AI)が「静的な表を読む」問題なのに対し、本記事は「動く計算モデルを書き換える」問題を扱います。

表の理解(レイアウトの多様性・結合セル・暗黙の意味)

現場の表計算は、人が見て分かるように作られており、機械には読みにくい構造を持ちます。ここを取り違えると、以降の操作がすべて狂います。

操作の設計(数式を書くか値を書くか・差分承認)

表計算を「書き換える」操作は、何を書き込むかで結果の意味が変わります。原則を決めておきます。

  • 数式か値かを意識して書く: 集計結果を値で直書きすると、元データが変わっても追従せず、ブックの「生きた」性質を殺します。多くの場合、数式を書くほうが正しく、後の変更に耐えます。一方、確定値(スナップショット)を残したい場面では値で書きます。この区別を曖昧にしない設計にします
  • 既存の数式を尊重する: セルに既に数式が入っている場合、値で上書きするとその数式が失われます。既存の数式を壊す操作は、特に慎重にします
  • 変更をプレビューし、差分で承認する: 破壊的な編集の前に、「どのセルがどう変わるか」の差分を提示し、人が承認してから適用します(Human-in-the-Loop 設計)。ブック全体をいきなり書き換えず、変更を可視化・可逆にします
  • 原本を保護する: 元のブックのコピーに対して操作し、原本を直接壊さない運用にします。やり直せることが、安心して自動化を進める前提です

検証(再計算の突き合わせ・破壊検知)

表計算エージェントは、実行が成功しても壊れていないとは限りません。操作後に別の検証を挟みます(ループのフィードバックと検証)。

大規模シートの分割戦略

大きなブックは、そのままコンテキストに載せられません。必要な範囲に絞る設計が要ります。

  • 関係する範囲だけを渡す: 全セルを渡すのではなく、操作に関係するシート・範囲・依存する数式だけを抽出して渡します。無関係な領域を渡さないことが、精度とコストの両方に効きます
  • 構造を要約して渡す: シート一覧・各シートの見出し・表の位置といった地図を先に渡し、必要な箇所を掘り下げる二段構えにします(コンテキストの圧縮と隔離)
  • 依存を追って範囲を決める: あるセルを変えると影響する参照先を追い、影響範囲を操作・検証の対象に含めます。影響範囲を見誤ると、離れた場所を静かに壊します

データ分析エージェントとの分担(BI/SQL vs 現場の Excel)

表計算エージェントとデータ分析エージェントは、扱う世界が違います。混同すると設計を誤ります。

  • データ分析 = BI・SQL の世界: 整ったデータベース・データウェアハウスに対し、集計・可視化・分析を行います。データは「読む」対象で、構造が整っています
  • 表計算 = 現場の Excel の世界: 人が日々編集する、構造の不揃いな・生きたブックを読み書きします。データは「書き換える」対象で、破壊のリスクがあります
  • 使い分ける: 大量データの分析は分析エージェント(SQL・ノートブック)へ、現場の帳票・管理表の読み書きは表計算エージェントへ振り分けます。両者をつなぐ場合も、「分析結果を表計算に書き戻す」境界を明確にします

実務での注意点

アンチパターン

  • 表を「1 行 = 1 レコード」の綺麗なデータと仮定する → 複数表・小計行・結合セルで誤読する → 表の構造と前提を言語化させ人が確認する段を挟む
  • 集計結果を値で直書きする → 元データ変更に追従せず、生きた性質を殺す → 原則は数式で書き、確定値が要る場面だけ値にする
  • 既存の数式を値で上書きする → 数式が失われ後で壊れる → 既存数式を尊重し、破壊的操作は差分承認にする
  • ブック全体をいきなり書き換える → 離れた場所を静かに壊す → 原本のコピーに対し、変更をプレビュー・差分承認・可逆にする
  • 「エラーが出ないから正しい」と扱う → 静かに間違った数字が残る → 再計算の突き合わせ・数式破壊検知で意味を検証する
  • 大きなブックを丸ごと渡す → 精度もコストも悪化する → 構造の地図を先に渡し、関係する範囲と依存だけを抽出する

チェックリスト

  • 表の構造(複数表・小計・結合セル・単位などの暗黙の意味)を確認する段を設けたか
  • 数式で書くか値で書くかの原則を決め、既存数式を尊重しているか
  • 破壊的な編集を、差分プレビューと承認・原本保護・可逆性で守っているか
  • 対応する計算エンジンで再計算した値を突き合わせ、数式破壊(参照エラー・数式の値化)を検知しているか
  • 大規模シートを、構造の地図 + 関係範囲 + 依存の抽出で分割して扱っているか
  • データ分析(BI・SQL)と表計算(現場の Excel)の分担を明確にしたか

関連トピック

参考資料

TODO・未確認事項

なし

先端応用の概観(科学研究・シミュレーション・エージェント経済)予測・時系列タスクと LLM