Web API利用の難しさ
原因の大きな部分は、Web API利用の難しさです。第一にRDBMS／SQLによるテーブル型のデータ利用がエンジニアと既存アプリケーションに強固に根付いていることです。RDBMS／SQLによるデータ利用は40年以上の歴史があります。実際に業務データを扱う方法としてRDBMS／SQLはとても優れており、今後も主要な業務アプリケーションではRDBMSとSQLが使い続けられると考えられます。Web APIの多くはRESTというソフトウェアアーキテクチャスタイルで設計されており、ACID特性を持つRDBMSとは根本的にスタイルが異なります。RDBMSの正規化という考え方は、APIのエンドポイントにはありません。APIの利用用途に合わせて必要十分なデータを階層構造ではなくフラットにデザインされています。REST APIの利用がRDBMS／SQLと比べて格段に難しいということではありません。重要なことは「すでに多くのエンタープライズエンジニアがRDBMS／SQLを習得している。そして既存のアプリケーションやツール群（IDEなどの開発、帳票、BI、ETLツールなど）、RDBMSを扱うことを前提に構築されている」ということです。新たにWeb APIでデータ連携に対応するには、エンジニアの技術習得コスト、既存システムの接続方法を改修するコスト、既存のツールでWeb APIを扱えない場合はリプレースのコストが発生します。企業もしくはシステムインテグレーターが敬遠してしまうのも無理がありません。
第二に、API習得には無駄が多いことです。SaaSごとにAPIは異なります。JDBCやODBCのように業界標準というものがあるわけではありません（GoogleやMicrosoftによるOPEN API Initiativeという業界標準化の活動は始まったばかりです）。複数のSaaSを導入したり、スイッチコストの低さから頻繁に使用するSaaSを変更したりする場合、API習得のコストは膨大になります。さらにWebサービスは早いペースで機能追加をしており、APIも年に複数回変更される場合があります。もしあなたが帳票、BI、ETLツールの開発担当者なら一般的に使われているSaaSとしてAPI連携対応をユーザーが期待する公開APIの数はゆうに数十を超えるでしょう（図4）。システムインテグレーターの場合も同様に、顧客がそれだけのAPI連携を要求してくることが予想されるわけです。
API連携ツールの活用がAPI利用拡大のカギに
なぜデータを連携することが必要なのか？ 実はデータをつなぐこと自体に価値はありません。データの価値は「どう使うか？」「何を読み取り、判断するか？」にあります。経営学的な内部調達と外部調達判断のセオリーでは、ビジネスにおいて本来的な価値を生むプロセスではなく、プロセスに無駄が多いプロセス、そして、誰がやっても変わらないようなプロセスは外部調達を選ぶことが定石です。複数のAPI連携を習得しなければならないシステムインテグレーターやBI、帳票、ETL、DWHなどの製品ベンダーがAPI連携にツールを使ってAPI連携の開発コストを低減し、資源（人、金、時間）を「データを使う」ことに集中させることは経営として理に適っていると言えます。これはユーザー企業でも同様です。
API連携をサポートするツール例
図6のように、データ連携の方式、サイクル、フォーマット、考え方はオンプレ時代とクラウド時代では大きく異なります。それ故にデータ連携に使われるツールも新しいものが求められます。
API利用の方法をツールの種類別に見てみます。
APIをユーザーが実際に操作する製品・サービス
APIプログラミング
最もシンプルな方法は、プログラム言語でHTTPリクエストの実行メソッド（GET／PUT／POST／DELETE）、レスポンス（JSON／XML）、認証（OAuthなど）をコードとして書き込む方法です。Webサービスに慣れたエンジニアには、この方法が一番シンプルで使いやすいでしょう。サービス提供元のAPI仕様をフルに活用することで高度かつ最新の仕様を利用できるといったメリットがあります。
API入力補助ツール
コマンドラインツールのcURL、GUIツールのPostmanなどで、APIを準備されたユーザーインターフェースから実行する方法です。実際の業務データの読み書きに利用するというよりは、API仕様確認やテストのためのツールという位置づけです。
APIマネジメントツール
Swagger、Apigee（Google社が買収）やCData API Serverなど。APIの生成、ホスト、ドキュメント作成、セキュリティ管理、モニタリング、テストなど、さまざまな面でAPIマネジメントを容易にしてくれます。APIを作る側のツールとしての位置づけが大きいですが、各種のAPIをODataなどの統一された方法で管理することもできます。
ユーザーが APIを意識せずに利用できる製品・サービス
Point-to-Point型サービス
IFTTT（If this, then that）、Zapier、Microsoft Flow、Yahoo myThingsなど。元となるSaaSにおいてトリガーとなるアクションが行われると相手先のSaaSで事前の登録しておいたオペレーションが行われるものです。「Facebookにタグ付けされた写真が投稿されたら、Dropboxに写真を保存する」といった例です。プログラミング不要で、Citizen Developerがパーソナライズされたフローを組むのに非常に便利です。
APIドライバー製品
Web APIエンドポイントをテーブルにモデル化して、JDBC、ODBC、ADO.NETなどのSQLの標準テクノロジーで使えるようにするライブラリ製品です。APIデータを見やすいテーブルとして扱えることや、IDE、その他JDBC、ODBC、ADO.NETに対応するBI・帳票・ETLツールであれば、ドライバーを配置するだけでAPIの利用が可能であり、RDBMS／SQL技術者には扱いやすい製品でしょう。既存アプリケーションやツールのREST受け入れのための改修が不要な点もメリットです。他のPoint-to-point型サービスや、API連携内包ツールにOEMとして使われることも多いです。
API連携機能内包ツール
BI、帳票、DWH、ETLツールなどで、ベンダーがWeb APIとの接続機能をネイティブに提供する形態です。ユーザーから見ると、慣れ親しんだツールを使うため、スイッチコスト・習得コストが不要で、API連携としてはハードルが最も低いでしょう。利用者の中にはWeb APIを利用しているという意識をせずにツールからSaaSデータを利用しているということも多いです。
