API連携の幻想を破壊する：SaaS導入で「手入力」が消えない技術的真実

「API連携に対応しています」という謳い文句を、我々エンジニアは何度耳にしてきただろうか。しかし、現場に導入された瞬間に突きつけられるのは、自動化を期待していたはずの担当者からの「結局、画面を開いて手入力しないと終わらない」という悲痛な叫びである。この乖離は、単なるコミュニケーション不足ではない。APIという技術的インターフェースの「カタログスペック」と、実際の業務プロセスが要求する「データ構造の整合性」との間に横たわる、深くて暗い溝に起因している。

IT連携マップ編集部による公開82システム、922件のデータ対象を対象とした実測調査は、この「APIの罠」を冷徹な数値で可視化している。驚くべきことに、APIが提供する機能の91.6%は「Read（取得）」に偏っており、現場が喉から手が出るほど欲している「Create（作成）」や「Update（更新）」は、それぞれ56.7%、41.8%にまで低下する。つまり、多くのSaaSは「外からデータを見る」ことには寛容だが、「業務のステータスを書き換える」ことには極めて保守的、あるいは設計思想が追いついていないのだ。我々が設計時に陥りやすいのは、「APIがある＝業務が自動化できる」という短絡的な推論である。しかし、実際には「読み取り専用の窓口」が用意されているだけで、肝心の業務フローを完結させるための「書き込み口」が閉ざされているケースが多々ある。この事実は、仕様書を斜め読みしただけでは決して見抜けない。ベンダーの公開仕様書を精査し、CRUDの各操作がどのオブジェクトに対して許可されているかを、泥臭く1つずつ突合する以外に道はないのである。

マネーフォワード クラウド請求書および会計の全画面項目を対象とした詳細な突合調査は、我々に衝撃的な事実を突きつけた。請求書システムにおいて、画面上の450項目のうち、外部から投入すべき「業務入力項目」はわずか79項目（17.6%）に過ぎない。さらに、そのうちAPIで完全に書き込めるのは54.4%であり、制限付きを含めても72.2%という数字に留まる。会計システムに至っては、890項目のうち業務入力項目は126項目（14.2%）であり、APIによるカバー率はわずか17.5%という惨状である。なぜこれほどまでに低いのか。それは、Web画面上の「仕訳辞書」や「固定資産台帳」といった、現場が日常的に触れる機能領域が、APIの設計対象から完全に漏れているからだ。

ここで重要なのは、APIのカバー率が「製品の良し悪し」を示す指標ではないという点だ。APIが狙っている「仕訳」や「取引先」といったコアオブジェクトに絞れば、会計システムであっても81.5%のカバー率を誇る。問題は、我々が「自動化したい業務」と「APIが提供するオブジェクト」の粒度が一致しているかという一点に集約される。さらに厄介なのが、API利用における「内部ID」の依存関係だ。勘定科目名や部門名を文字列で渡すことは許されず、事前に取得した内部IDを指定しなければならないという制約は、マスタ管理APIが欠如しているシステムにおいて、現場に「手動での事前登録」という新たな工数を強いることになる。これはまさに、自動化を目的としたシステム連携が、逆に運用上のボトルネックを生み出すという「自動化のパラドックス」そのものである。

項目の突合を乗り越えたとしても、我々の前には「レート制限」と「プラン制約」という2つの巨大な壁が立ちはだかる。レート制限の単位は、1日、1時間、5分、1分、1秒とシステムごとにバラバラであり、単純な比較は不可能だ。例えば「1日3,000回」という制限があっても、「1秒3回」というバースト制限に抵触すれば、HTTP 429エラーが返り、連携は即座に停止する。また、プランによってAPIの利用可否や上限回数が変動する仕様は、契約時のコスト計算を複雑化させる。特に、NDA締結が必須であったり、上位プランへのアップグレードが前提となっていたりするケースを見落とすと、プロジェクトの予算計画は根底から崩壊する。

では、我々エンジニアは明日からどう動くべきか。まず、営業資料の「API連携可能」という言葉を一切信じないことだ。自社が自動化したい業務項目をリストアップし、相手のOpenAPI仕様書と1行ずつ突き合わせる。次に、Create/Updateの口が本当に開いているかをベンダーに書面で確認する。そして、内部IDの解決フローや、レート制限を考慮したリトライ設計を、実装の初期段階でアーキテクチャに組み込むこと。これらは遠回りに見えるかもしれないが、導入後の「こんなはずではなかった」という障害対応に追われる深夜の時間を考えれば、最も効率的な防衛策である。我々が問われているのは、単なるコーディング能力ではない。カタログの向こう側にある「業務の真実」を読み解き、システム間の不整合を運用でどう埋めるかという、泥臭い設計能力なのである。APIは魔法の杖ではない。それは、設計者の意図と現場の現実が交差する、極めてシビアなインターフェースに過ぎないのだ。