想定読者

DX担当
情シス
非エンジニア事業企画
営業企画
BPO/BPaaS設計担当
SaaS PdM
Excel業務を抱える現場責任者
API連携を検討するSIer・Webエンジニア
再エネ・太陽光・蓄電池・補助金・電気料金など、複雑な見積・試算業務を扱う事業者

記事の狙い

この記事の主張はシンプルです。

Excelを壊すDXは、たいてい失敗します。
成功しやすいのは、Excelを現場UIとして残し、裏側の計算・データ更新・監査ログ・レポート生成をAPI化する設計です。

添付の技術記事制作プロンプトでは、読者の実務課題解決、再現可能な設計、コード・疑似コード・チェックリスト、そしてエネがえるAPIの自然導線を重視する方針が示されています。
また、エネがえるAPI仕様では、OpenAPI 3.0形式の共通公開API、ログイン、補助金検索、電気料金プラン取得、電気料金計算、電気使用量計算、太陽光発電量計算、設備導入シミュレーションなどのAPI群が整理されています。

Excelを壊さずAPI化する設計入門：現場を敵にしないDXの作り方

Excel業務をAPI化するとき、最初にやってはいけないことがあります。

それは、「Excelをなくしましょう」と言うことです。

現場にとってExcelは、単なる表計算ソフトではありません。
入力画面であり、メモ帳であり、見積書の下書きであり、顧客との会話履歴であり、ときには業務ルールそのものです。

だから、Excelをいきなり捨てるDXは、現場から見るとこう聞こえます。

明日から、あなたの仕事道具を取り上げます。
代わりに、まだ完成していない新システムを使ってください。

それはDXではなく、だいたい事故です。

この記事では、Excelを敵にせず、むしろExcelを入口として残したまま、裏側をAPI化する設計を解説します。

対象は、エンジニアだけではありません。
むしろ、Excel業務の現実を知っている非エンジニア、DX担当、営業企画、BPO担当、業務改善担当に読んでほしい内容です。

扱うテーマは次の通りです。

Excelを残すべき業務、消すべき業務の見分け方
ExcelをUIとして残し、APIを正本計算にする設計
AIエージェントに任せてよい領域、任せてはいけない領域
入力データ、計算ロジック、監査ログの分け方
エラー処理、権限、認証、再計算の考え方
エネがえるAPI・BPOのような業務特化APIを使うと何が楽になるか

OpenAPIは、HTTP APIを人間とコンピュータが理解できる標準的なインターフェース記述として定義する仕様です。つまり、APIを“使える部品”にするだけでなく、“説明可能な契約”にするための言語でもあります。(OpenAPI Initiative Publications)

Excel業務のAPI化で本当に重要なのは、最新の技術スタックではありません。

何をExcelに残し、何をAPIに逃がし、何をDBの正本にするか。

ここを間違えると、Next.jsでも、Pythonでも、AIエージェントでも、結局「きれいな画面を持った手作業」になります。

1. Excel業務の本当の問題は、Excelではない

結論から言います。

Excel業務の問題は、Excelを使っていることではありません。
問題は、Excelの中に“入力・計算・判断・履歴・承認・最新版管理”が全部混ざっていることです。

Excelそのものは優秀です。

誰でも開ける
表形式で理解しやすい
コピー・貼り付けが速い
現場が自分で調整できる
顧客に見せやすい
小さな業務なら開発不要で回せる

Google Sheets APIは、スプレッドシートのセル値の読み書き、書式変更、スプレッドシート作成などを行えるRESTfulインターフェースとして提供されています。(Google for Developers)
Microsoftも、Excelアドイン向けにExcel JavaScript APIを提供しており、ワークシート、範囲、表、グラフなどExcel内のオブジェクトを操作できます。(Microsoft Learn)

つまり、ExcelはAPI時代に消える道具ではありません。
むしろ、APIと接続できる業務UIとして再定義できます。

問題は、Excelの使い方です。

たとえば、次のような状態になっていないでしょうか。

状態	表面上の問題	本当の問題
見積Excelが担当者ごとに違う	フォーマットが統一されない	正本テンプレートがない
計算式が壊れる	関数ミスが起きる	計算ロジックが監査不能
最新単価がわからない	手入力が多い	データ更新元が分散
補助金条件が古い	調査に時間がかかる	制度DBがない
顧客別にファイルが散らばる	探せない	案件管理DBがない
AIに見積を作らせたい	自動化できない	API化された正本処理がない

ここで大事なのは、Excelを責めないことです。

Excelは、現場の不足を埋めてきた“応急処置の集合体”です。
悪者ではありません。
むしろ、現場が何に困っているかを最も濃く記録している化石です。

Excel業務をAPI化するとは、Excelを消すことではなく、Excelに埋もれた業務ルールを外に取り出すことです。

2. 「Excelを捨てるDX」が失敗しやすい理由

よくあるDXの失敗は、こんな順番で起きます。

経営層が「Excel業務をなくそう」と言う
情シスやDX担当が新システムを検討する
現場は「今のExcelの方が早い」と言う
新システムは入力項目が多く、例外対応が弱い
現場はExcelで下書きしてからシステムに二重入力する
結果、業務量が増える
「現場が使ってくれない」で終わる

この構造は、かなり根が深いです。

現場がExcelを使う理由は、怠慢ではありません。
Excelが例外処理に強すぎるからです。

顧客から突然こう言われる。

「この月だけ使用量が特殊です」
「補助金ありとなしで比較したいです」
「この設備だけ単価を変えてください」
「社内稟議用に別パターンもください」
「去年の条件でもう一度見たいです」
「この数字、営業資料に貼れる形でください」

標準システムは、標準業務には強い。
しかし、現場は標準業務だけで生きていません。

だから、Excelを全廃する前に考えるべき問いはこれです。

Excelを消すべきなのか。
それとも、Excelに背負わせすぎている責任を分解すべきなのか。

ほとんどの場合、答えは後者です。

3. Excelを壊さないAPI化の基本思想

Excel業務を壊さずAPI化するには、業務を3層に分けます。

AI時代の業務システム三層構造

層	役割	具体例	注意点
UI層	人間が入力・確認する	Excel、Google Sheets、Web画面、フォーム	現場の使いやすさ重視
AI層	下書き・要約・候補提示	顧客ヒアリング整理、提案文生成、FAQ回答	正本計算を任せない
API/DB層	正本処理・正本データ・監査	料金計算、補助金検索、シミュレーション、ログ保存	説明責任と再現性を担保

ここで重要なのは、AI層とAPI層を混ぜないことです。

AIは便利です。
しかし、AIに任せるべき仕事と、APIに任せるべき仕事は違います。

領域	AI向き	API/DB向き
顧客メモの要約	◎	△
メール文面の下書き	◎	△
顧客ヒアリング項目の整理	◎	○
入力ミス候補の検出	○	◎
電気料金計算	△	◎
太陽光・蓄電池の経済効果試算	△	◎
補助金候補の検索	○	◎
投資回収の正本計算	△	◎
レポート文章の下書き	◎	○
監査ログ保存	△	◎

AIは、言葉と曖昧さに強い。
APIは、決まった入力から決まった処理を再現するのに強い。

AIに“考えさせる”ほど、APIには“間違えずに計算させる”必要があります。

これは、AI時代の業務設計でかなり重要なポイントです。

4. Before / After：Excel業務はこう変える

Excel業務をAPI化するときは、いきなりWebアプリに置き換えない方が成功しやすいです。

Before

この状態では、Excelが全部背負っています。

入力
計算
判断
レポート
履歴
承認
案件管理

だから壊れます。

After

この形にすると、Excelは「入口」と「確認画面」として残せます。

ただし、責任は分解されます。

責任	Excelに残すか	API/DBへ移すか
入力	○	△
入力チェック	△	◎
正本計算	×	◎
単価・制度データ	×	◎
結果表示	○	○
レポート出力	△	○
監査ログ	×	◎
承認履歴	×	◎

ここでの合言葉は、Excelを画面に、APIを心臓に、DBを記憶にするです。

5. 最小構成アーキテクチャ

Excel業務のAPI化は、最初から大きなシステムにしなくて構いません。

最小構成はこれです。

最小構成の役割

コンポーネント	役割
Excel / Google Sheets	現場入力UI
API Connector / Add-in	ExcelとAPIの橋渡し
Backend API	認証、入力変換、API呼び出し制御
Validation	入力値の型・範囲・必須チェック
Business API	正本計算、検索、シミュレーション
Result Normalizer	結果をExcelやPDF向けに整形
Audit Log DB	誰が、いつ、どの条件で実行したか保存
Report Generator	顧客・稟議向け出力

Google Sheets APIのようなRESTfulインターフェースを使えば、スプレッドシートの値の読み書きをプログラムから実行できます。(Google for Developers)
Microsoft 365環境では、Office JavaScript APIを使うことで、ExcelアドインからExcel内のオブジェクト操作が可能です。(Microsoft Learn)

つまり、最初から「脱Excel」を目指す必要はありません。

むしろ現実的には、

Excelを残す
計算だけAPI化する
データ更新だけAPI化する
ログ保存を追加する
レポート生成を自動化する
必要になったらWeb画面化する

この順番の方が成功しやすい。

6. データ設計：API化で最初に決めるべきこと

Excel業務をAPI化するとき、最初にコードを書いてはいけません。

最初に決めるべきは、データの責任分界です。

6-1. 入力データ

入力データとは、現場や顧客から受け取る値です。

例：

顧客名
住所
契約種別
月別使用量
30分デマンド
設備容量
初期費用
補助金の想定
比較パターン
営業担当メモ

入力データで重要なのは、自由入力を減らしすぎないことです。

現場は例外を抱えています。
すべてをプルダウンにすると、入力できない案件が出ます。

ただし、正本計算に使う項目は、自由入力のままにしてはいけません。

項目	入力方式	理由
顧客名	自由入力	表記揺れ許容
住所	自由入力＋住所正規化	地域判定に使う
都道府県コード	選択式	API検索条件に使う
電気料金プランID	選択式	正本計算に使う
月別使用量	数値入力	計算に使う
営業メモ	自由入力	AI要約向き
補助金ID	API取得	正本データ参照

6-2. マスターデータ

マスターデータとは、業務側で管理すべき正本データです。

電力会社マスター
料金プランマスター
補助金マスター
設備マスター
製品仕様マスター
地域コード
契約種別
権限ロール

エネがえるAPIの公開仕様では、電気事業者取得、電気料金プラン取得、電気料金プラン詳細取得、電気料金計算などのAPIが定義されています。
また、補助金情報一覧では、都道府県コード、市区町村、対象設備コード、補助対象区分などを組み合わせて検索できる仕様が示されています。

このような業務特化APIを使うと、自社で全マスターを持たなくても、外部APIを正本データとして参照する設計が可能になります。

6-3. 出力データ

出力データは、現場が使う形に戻す必要があります。

Excelの結果シート
PDF提案書
JSONレスポンス
CSV
管理画面
顧客向けレポート
稟議用サマリー
AI要約文

ここで大事なのは、APIレスポンスそのものを現場に渡さないことです。

APIレスポンスは機械が読むもの。
現場や顧客には、判断しやすい形に整形して返す必要があります。

7. API設計：Excel業務では「細かいAPI」より「業務単位API」が効く

API設計では、粒度が重要です。

細かすぎるAPIは、エンジニアには便利でも、業務側には扱いにくいことがあります。

たとえば、Excel業務をAPI化するときに、次のようなAPIだけを用意しても現場は困ります。

/customers
/plans
/rates
/subsidies
/calculate

もちろん必要です。
しかし、業務担当者が欲しいのは、もっと業務に近い単位です。

「この顧客条件で概算見積を作る」
「補助金あり/なしで比較する」
「A案/B案/C案の回収期間を比較する」
「営業資料用のサマリーを作る」
「稟議に必要な前提条件一覧を出す」

つまり、APIは2層に分けるとよいです。

API種別	役割	例
基礎API	データ取得・計算部品	料金プラン取得、補助金検索、発電量計算
業務API	現場の目的単位	見積作成、比較試算、提案書生成

エネがえるAPIの例では、補助金データ照会、電気料金計算、電気使用量計算、太陽光発電量計算、設備導入シミュレーションといった基礎的な業務APIが公開仕様として整理されています。

エネがえる共通公開用 API https://www-apidoc.enegaeru.com/sys/

これを自社業務に組み込む場合、さらに上位に「自社用ユースケースAPI」を作ると扱いやすくなります。

この設計にすると、Excel側は複雑なAPIを直接呼ばずに済みます。

Excelは単に、

入力する
実行ボタンを押す
結果を受け取る

だけでよい。

裏側でどのAPIをどの順番で呼ぶかは、Backend側が持ちます。

8. 認証・権限・監査ログ：Excel API化で甘く見てはいけない領域

Excel業務をAPI化すると、セキュリティの問題が一気に表面化します。

特に危ないのは、次の3つです。

APIキーをExcelファイルに直接書く
顧客データを誰でも見られる状態にする
誰がどの条件で計算したか残さない

OWASP API Security Top 10は、API開発・保守に関わる開発者、設計者、管理者、組織に対して、APIの一般的なセキュリティリスクへの認識を高める目的で公開されています。(OWASP Foundation)
同リストでは、認可不備やオブジェクトプロパティレベルの認可不備など、APIで起きやすいリスクが整理されています。(OWASP Foundation)

8-1. APIキーはExcelに置かない

これは絶対です。

ExcelにAPIキーを書くと、ファイルをコピーした瞬間に認証情報も拡散します。

正しい構成はこうです。

Excelは自社Backendを呼びます。
外部APIキーはBackend側で保管します。

8-2. 権限は「部署」ではなく「操作」で見る

Excel業務では、権限設計が雑になりがちです。

しかしAPI化するなら、最低限こう分けるべきです。

権限	できること
閲覧者	結果を見る
入力者	条件を入力し、試算する
承認者	提案用の正式結果として承認する
管理者	マスター設定、ユーザー管理
監査者	ログ確認、履歴確認

特に見積、補助金、料金計算、投資回収のような業務では、誰が最終版として使うことを承認したかが重要になります。

8-3. 監査ログは“後から怒られたとき用”ではない

監査ログは、守りの機能に見えます。
しかし実務では、攻めの機能でもあります。

ログがあると、次のことができます。

過去提案の再現
顧客からの問い合わせ対応
社内稟議の前提確認
AI回答の根拠確認
担当者交代時の引き継ぎ
BPO委託時の品質管理
成約/失注分析

最低限、以下を保存します。

{
  "request_id": "req_20260501_0001",
  "user_id": "user_123",
  "customer_id": "customer_456",
  "operation": "solar_battery_simulation",
  "input_hash": "sha256:xxxx",
  "api_version": "v1",
  "master_data_version": "2026-05",
  "created_at": "2026-05-01T12:00:00+09:00",
  "status": "success"
}

ポイントは、入力値そのものを全部保存するか、ハッシュと別保管にするかを設計することです。

個人情報や機密情報が含まれる場合は、ログの粒度も設計対象になります。

9. エラーハンドリング：Excel業務では「失敗理由」が価値になる

API化でよくある失敗は、エラー時にこう返すことです。

{
  "error": "Bad Request"
}

これでは現場が詰みます。

Excel業務のAPI化では、エラーは単なる失敗通知ではなく、現場が次に何を直せばよいかを示すガイドでなければなりません。

悪いエラー

{
  "message": "Invalid parameter"
}

良いエラー

{
  "code": "INVALID_MONTHLY_USAGE",
  "message": "月別使用量は12か月分必要です。",
  "field": "monthly_usage",
  "how_to_fix": "1月〜12月の使用量をkWh単位で入力してください。",
  "example": [420, 380, 350, 310, 290, 330, 410, 450, 390, 360, 340, 400]
}

エネがえるAPI仕様では、共通エラーとして400、403、500、504などのHTTPレスポンスが整理されています。400はリクエスト内容に起因するエラー、403は認証エラー、500はAPI内部処理エラー、504はタイムアウトとして扱われます。

Excel業務側では、これをさらに現場向けに翻訳する必要があります。

HTTPステータス	技術的意味	現場向けメッセージ
400	入力エラー	入力条件に不足または形式ミスがあります
401/403	認証・権限エラー	ログイン状態または権限を確認してください
500	サーバ内部エラー	システム側で処理に失敗しました
504	タイムアウト	条件を分割するか、時間を置いて再実行してください

エラーを現場語に翻訳する。
これだけでAPI導入のストレスは大きく下がります。

10. TypeScript実装例：Excel入力を業務APIに渡すBackend

以下は、ExcelやGoogle Sheetsから受け取った入力をBackendで検証し、外部業務APIに渡すイメージです。

本番では、認証、レート制限、監査ログ、暗号化、個人情報保護、リトライ制御を追加してください。

import { z } from "zod";

const SimulationInputSchema = z.object({
  customerId: z.string().min(1),
  prefectureCode: z.string().regex(/^\d{2}$/),
  city: z.string().min(1),
  monthlyUsageKwh: z.array(z.number().nonnegative()).length(12),
  pvKw: z.number().positive().optional(),
  batteryKwh: z.number().nonnegative().optional(),
  tariffPlanId: z.string().min(1),
});

type SimulationInput = z.infer<typeof SimulationInputSchema>;

type ApiResult<T> =
  | { ok: true; data: T; requestId: string }
  | { ok: false; errorCode: string; message: string; field?: string; requestId: string };

async function callBusinessApi(input: SimulationInput): Promise<ApiResult<any>> {
  const requestId = crypto.randomUUID();

  const parsed = SimulationInputSchema.safeParse(input);

  if (!parsed.success) {
    const firstError = parsed.error.issues[0];

    return {
      ok: false,
      errorCode: "VALIDATION_ERROR",
      message: "入力値に不足または形式ミスがあります。",
      field: firstError.path.join("."),
      requestId,
    };
  }

  try {
    // 実際のAPIキーや認証情報は.envやSecret Managerで管理する。
    // Excelファイルやフロントエンドに置かない。
    const response = await fetch(`${process.env.BUSINESS_API_BASE_URL}/simulate`, {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
        Authorization: `Bearer ${process.env.BUSINESS_API_TOKEN}`,
      },
      body: JSON.stringify(parsed.data),
    });

    if (!response.ok) {
      if (response.status === 400) {
        return {
          ok: false,
          errorCode: "BUSINESS_API_BAD_REQUEST",
          message: "試算条件に不備があります。入力項目を確認してください。",
          requestId,
        };
      }

      if (response.status === 403) {
        return {
          ok: false,
          errorCode: "BUSINESS_API_FORBIDDEN",
          message: "APIの認証または権限に問題があります。",
          requestId,
        };
      }

      return {
        ok: false,
        errorCode: "BUSINESS_API_ERROR",
        message: "外部APIの処理に失敗しました。",
        requestId,
      };
    }

    const data = await response.json();

    // auditLogは疑似コード。本番ではDBへ保存。
    await auditLog({
      requestId,
      customerId: parsed.data.customerId,
      operation: "simulate",
      inputHash: await hashInput(parsed.data),
      status: "success",
    });

    return {
      ok: true,
      data,
      requestId,
    };
  } catch (error) {
    await auditLog({
      requestId,
      customerId: input.customerId,
      operation: "simulate",
      status: "network_error",
    });

    return {
      ok: false,
      errorCode: "NETWORK_ERROR",
      message: "通信エラーが発生しました。時間を置いて再実行してください。",
      requestId,
    };
  }
}

async function hashInput(input: unknown): Promise<string> {
  const encoded = new TextEncoder().encode(JSON.stringify(input));
  const hashBuffer = await crypto.subtle.digest("SHA-256", encoded);
  return Array.from(new Uint8Array(hashBuffer))
    .map((b) => b.toString(16).padStart(2, "0"))
    .join("");
}

async function auditLog(record: {
  requestId: string;
  customerId: string;
  operation: string;
  inputHash?: string;
  status: string;
}) {
  console.log("AUDIT_LOG", record);
}

重要なのは、Excelから直接外部APIを呼ばせないことです。

Excel
→ 自社Backend
→ 業務API
→ ログ保存
→ Excelへ返却

この一段を挟むだけで、認証情報、ログ、エラー翻訳、データ整形を管理しやすくなります。

11. Python実装例：Excel/CSVから読み込み、API用JSONに変換する

非エンジニアチームやBPOでは、PythonでCSV/Excelを処理する方が現実的なこともあります。

from __future__ import annotations

import os
import json
import hashlib
from dataclasses import dataclass
from typing import Any

import pandas as pd
import requests
from pydantic import BaseModel, Field, ValidationError


class SimulationInput(BaseModel):
    customer_id: str = Field(min_length=1)
    prefecture_code: str = Field(pattern=r"^\d{2}$")
    city: str = Field(min_length=1)
    monthly_usage_kwh: list[float] = Field(min_length=12, max_length=12)
    tariff_plan_id: str = Field(min_length=1)
    pv_kw: float | None = None
    battery_kwh: float | None = None


@dataclass
class ApiClient:
    base_url: str
    token: str

    def simulate(self, payload: SimulationInput) -> dict[str, Any]:
        response = requests.post(
            f"{self.base_url}/simulate",
            headers={
                "Authorization": f"Bearer {self.token}",
                "Content-Type": "application/json",
            },
            json=payload.model_dump(),
            timeout=30,
        )

        if response.status_code == 400:
            raise ValueError("入力条件に不備があります。Excelの必須項目を確認してください。")

        if response.status_code in (401, 403):
            raise PermissionError("API認証または権限に問題があります。")

        if response.status_code >= 500:
            raise RuntimeError("API側で処理に失敗しました。時間を置いて再実行してください。")

        response.raise_for_status()
        return response.json()


def input_hash(payload: SimulationInput) -> str:
    raw = json.dumps(payload.model_dump(), ensure_ascii=False, sort_keys=True)
    return hashlib.sha256(raw.encode("utf-8")).hexdigest()


def load_input_from_excel(path: str) -> SimulationInput:
    df = pd.read_excel(path, sheet_name="input")

    row = df.iloc[0]

    monthly_usage = [
        float(row[f"usage_{month:02d}"])
        for month in range(1, 13)
    ]

    return SimulationInput(
        customer_id=str(row["customer_id"]),
        prefecture_code=str(row["prefecture_code"]).zfill(2),
        city=str(row["city"]),
        tariff_plan_id=str(row["tariff_plan_id"]),
        monthly_usage_kwh=monthly_usage,
        pv_kw=float(row["pv_kw"]) if not pd.isna(row["pv_kw"]) else None,
        battery_kwh=float(row["battery_kwh"]) if not pd.isna(row["battery_kwh"]) else None,
    )


def main() -> None:
    try:
        payload = load_input_from_excel("input.xlsx")

        client = ApiClient(
            base_url=os.environ["BUSINESS_API_BASE_URL"],
            token=os.environ["BUSINESS_API_TOKEN"],
        )

        result = client.simulate(payload)

        print("試算成功")
        print("入力ハッシュ:", input_hash(payload))

        with open("result.json", "w", encoding="utf-8") as f:
            json.dump(result, f, ensure_ascii=False, indent=2)

    except ValidationError as e:
        print("Excel入力に不備があります。")
        print(e)

    except Exception as e:
        print("処理に失敗しました。")
        print(str(e))


if __name__ == "__main__":
    main()

この構成なら、BPO担当者がExcelを扱いながら、裏側ではAPIとログを使えます。

12. 自前実装 vs 業務特化API活用

Excel業務をAPI化するとき、自社ですべて作るべきか、業務特化APIを使うべきかは悩みどころです。

比較するとこうなります。

観点	自前実装	業務特化API活用
初期開発	自由度は高いが重い	早く始めやすい
業務DB	自社で整備が必要	提供側に寄せられる
計算ロジック	完全に制御できる	API仕様に依存
監査性	設計次第	API仕様・ログ設計次第
保守	継続負荷が高い	外部依存はあるが軽くできる
法制度・単価更新	自社運用が必要	外部API側に寄せられる場合あり
AI連携	自前で整備	API化されていれば呼びやすい
BPO連携	個別設計が必要	標準化しやすい

再エネ、電気料金、補助金、太陽光・蓄電池・EV/V2H・PPAのような領域では、計算ロジックとデータ更新の両方が重くなります。

たとえばエネがえるAPIの仕様には、補助金検索、電気料金計算、太陽光発電量計算、設備導入シミュレーションなどが含まれています。2026年3月2日の更新履歴では、設備導入シミュレーションと太陽光発電量計算APIの追加が示されています。

こうした領域では、自社で全部を作るより、業務特化APIを組み合わせた方が現実的なケースがあります。

特に重要なのは、自社で差別化すべき領域と、外部APIに任せる領域を分けることです。

領域	自社で持つべきか	外部API活用向きか
顧客接点	◎	△
独自営業プロセス	◎	△
顧客別提案ロジック	○	○
電力料金マスター	△	◎
補助金DB	△	◎
太陽光・蓄電池試算ロジック	△〜○	○〜◎
レポートデザイン	◎	○
監査ログ	◎	○
BPO運用	○	◎

13. エネがえるAPI・BPOを具体例にすると何が見えるか

ここで、再エネ・太陽光・蓄電池・EV/V2H・PPA提案業務を例に考えます。

この領域のExcel業務は、かなり複雑です。

顧客情報
住所
電気料金プラン
月別使用量
30分デマンド
太陽光容量
蓄電池容量
売電単価
補助金
初期費用
保守費
劣化率
回収年数
CO2削減
提案書
稟議資料

これをExcelだけで管理すると、すぐに限界が来ます。

一方で、全部を新システムに置き換えると、現場がついてきません。

そこで現実解はこうです。

エネがえるAPI仕様では、ログインAPI、補助金情報一覧・詳細、電気事業者取得、電気料金プラン取得、電気料金計算、電気使用量計算、太陽光発電量計算、設備導入シミュレーションなどが整理されています。

エネがえる共通公開用 API https://www-apidoc.enegaeru.com/sys/

ここでエネがえるBPOを組み合わせると、APIだけでは吸収しきれない例外業務も扱いやすくなります。

たとえば、

検針票や請求書の読み取り
顧客別の条件整理
補助金の適用可能性確認
提案パターンの作成
営業用レポートの整形
Excelテンプレートの運用代行
API連携前のデータクレンジング

APIは標準化に強い。
BPOは例外処理に強い。

Excel業務のAPI化では、APIだけで完結させようとしない方がよい場合があります。
“APIで正本処理、BPOで例外吸収”という設計が、現場ではかなり強いです。

14. AIエージェントを入れるなら、API化はさらに重要になる

AIエージェントにExcel業務を任せたい、という相談は増えています。

しかし、AIエージェントにExcelを直接触らせるだけでは危険です。

なぜなら、AIは次のようなことを平気でやります。

それっぽい計算式を作る
存在しない前提を補完する
古いシートを正しいと思い込む
類似案件の数字を混ぜる
補助金条件を断定調に書く
計算結果と説明文をズラす

AIが悪いのではありません。
AIに正本計算を任せる設計が悪いのです。

AIエージェント時代の正しい分担はこうです。

AIに任せるのは、

入力の整理
不足項目の洗い出し
顧客への質問文作成
結果の要約
提案書の文章化
FAQ回答の下書き

APIに任せるのは、

電気料金計算
投資回収計算
補助金検索
太陽光発電量計算
蓄電池充放電シミュレーション
正本データ参照
ログ保存

AI時代のSaaS価値は、画面だけでは決まりません。

AIが安全に呼び出せる業務知識APIを持っているか。
ここが、次の競争力になります。

15. 導入ステップ：いきなり全部やらない

Excel業務のAPI化は、段階的に進めます。

Phase 1：Excel棚卸し

最初にやることは、システム開発ではありません。
Excel棚卸しです。

確認する項目：

どのExcelが使われているか
誰が作ったか
どの業務で使うか
どの列が入力か
どの列が計算か
どのシートが顧客提出用か
どの式が壊れると危険か
どのデータが外部更新されるか
誰が最終確認しているか

Phase 2：正本計算を切り出す

次に、Excel内の計算ロジックをAPI化します。

優先順位はこうです。

金額計算
契約・料金計算
投資回収計算
補助金判定
レポート生成
AI要約

金額に関わるものからAPI化する。
これは鉄則です。

Phase 3：マスター更新を外に出す

次に、Excelの中にあるマスターを外へ出します。

料金単価
商品マスター
補助金
地域コード
顧客区分
契約種別

Excel内マスターは、運用が進むほど腐ります。

Phase 4：監査ログを入れる

API化したら、必ずログを入れます。

ログがないAPI化は、あとで再現できません。

Phase 5：BPOとAIを接続する

最後に、BPOやAIエージェントを接続します。

ここで初めて、業務全体が自動化に近づきます。

16. API化チェックリスト

業務整理

Excelファイルの種類を棚卸しした
入力列、計算列、出力列を分けた
正本にすべきデータを特定した
担当者ごとのローカルルールを洗い出した
例外処理を一覧化した

データ設計

顧客データと案件データを分けた
マスターデータをExcel外に出す方針を決めた
入力値の単位を統一した
日付、期間、バージョンを持たせた
自由入力と選択式を分けた

API設計

Excelから直接外部APIキーを使わない
Backendを経由する
入力バリデーションを入れた
エラーを現場語に翻訳する
APIバージョンを記録する
タイムアウト時の扱いを決めた

監査・運用

誰が実行したか保存する
どの条件で実行したか保存する
どのマスター版を使ったか保存する
再計算できるようにする
BPO担当の確認フローを設計する
AIが生成した文章とAPI計算結果を分ける

17. よくある誤解

誤解1：ExcelをなくせばDXになる

違います。
Excelをなくしても、業務ルールが整理されていなければ、別の場所に混乱が移動するだけです。

誤解2：API化すれば自動化できる

半分だけ正しいです。
API化は自動化の土台ですが、入力品質、例外処理、ログ、権限、運用設計がなければ現場では回りません。

誤解3：AIがあればAPIはいらない

逆です。
AIを業務に入れるほど、APIとDBの正本性が重要になります。

誤解4：BPOはAPI化と逆方向である

これも違います。
現実の業務では、APIで標準化し、BPOで例外処理を吸収する設計が有効です。

誤解5：最初から完璧なWebシステムを作るべき

危険です。
現場業務がExcelで回っているなら、最初はExcelをUIとして残し、裏側だけAPI化する方が移行リスクを下げられます。

18. まとめ

Excel業務をAPI化する目的は、Excelを消すことではありません。

目的は、Excelに混ざっている責任を分けることです。

Excelは入力と確認に残す
APIは正本計算を担う
DBは正本データと履歴を持つ
AIは下書きと要約に使う
BPOは例外処理と品質管理を支える

この分担ができると、現場はExcelを使い続けながら、裏側ではAPI化・自動化・監査可能化が進みます。

再エネ、太陽光、蓄電池、EV/V2H、PPA、電気料金、補助金のように、データ更新と計算ロジックが複雑な業務では、業務特化APIを使う意味が大きくなります。

エネがえるAPIのような業務特化APIは、補助金、電気料金、発電量、設備導入シミュレーションなどの複雑な処理をAPI連携の対象にできるため、Excel業務を壊さずに裏側を標準化する選択肢になります。

Excelは、敵ではありません。
Excelは、現場の知恵が溜まった入口です。

壊すべきはExcelではなく、正本不在のまま人間が毎回がんばる構造です。

Mermaid図解まとめ

エネがえるAPI紹介

太陽光・蓄電池・EV/V2H・PPA提案のように、電気料金、補助金、発電量、設備条件、投資回収が絡む業務では、自社だけで全ロジックとデータ更新を持つのは重くなりがちです。こうした領域では、エネがえるAPIのような業務特化APIを“正本計算レイヤー”として使い、Excelや自社システムは入力・確認・顧客接点に集中させる設計が現実的です。

エネがえる共通公開用 API https://www-apidoc.enegaeru.com/sys/

参考文献・出典

OpenAPI Specification v3.2.0：HTTP APIを記述する標準仕様として参照。(OpenAPI Initiative Publications)
OpenAPI Initiative：OpenAPI仕様の位置づけ、API理解・テスト・コード生成などの用途確認に使用。(OpenAPI Initiative)
OWASP API Security Top 10 2023：API認可・データ露出・APIセキュリティリスクの整理に使用。(OWASP Foundation)
Microsoft Office JavaScript API Reference：ExcelアドインとExcel JavaScript APIの説明に使用。(Microsoft Learn)
Google Sheets API Overview：スプレッドシートの読み書き・作成・書式更新が可能なRESTful APIとして参照。(Google for Developers)
添付：技術記事制作プロンプト。記事構成・導線・品質要件の参照。
添付：エネがえる共通公開用API仕様。API構成・エンドポイント・エラー・認証・補助金・電気料金・シミュレーション仕様の参照。
添付：エネがえるブログ制作マスターシステム。Cited / Verified / Simulated / Approved、CFU/CAB/DB思想の参照。