連載08で業務自動化の基本を見ました。ここからは、AIと業務システムを「つなぐ技術」——API・MCP・RAG・自動化ツールの4つを、実装の視点で見ていきます。まず、すべての土台になるAPIから。
本題の前に、連載09全体を貫く一文を置きます。あなたの会社のAIが「調べ物・下書きどまり」なのは、AIの頭が悪いからではありません。自社の情報や道具に”つないでいない”からです。Anthropicも「どれだけ賢いモデルも、データから切り離され、情報のサイロの後ろに閉じ込められている」と指摘します。つなぐと、AIは初めて実務に効きます。
- APIとは「うちのソフトとよそのソフトをつなぐ、決まりごと付きの窓口（契約）」
- つなぐ＝全部丸見え、ではない。「この件に必要な分だけ」を窓口から出せる
- つなぐと「単一の正しいデータの出どころ」ができ、手入力・転記が消える
APIは「サービスの契約」——決まりごと付きの窓口
APIは難しそうな響きですが、本質はシンプルです。AWSの定義はこうです。
APIとは、2つのソフトウェアが、定義とプロトコル（リクエストとレスポンス）を用いて互いに通信できるようにする仕組みである。（…）インターフェースは、2つのアプリ間の「サービスの契約」と考えることができる。
（AWS「What is an API?」）
現場語に訳せば、「うちのソフトとよそのソフトをつなぐ、決まりごと付きの窓口」。レストランの注文窓口に似ています。客（あなたのソフト）は決まった形で注文（リクエスト）し、厨房（相手のソフト）が料理（レスポンス）を返す。「契約（contract）」という原語が肝で、やり取りの形が決まっているから、安定して自動でつながります。
つなぐ＝全部丸見え、ではない
中小企業の最大の不安は「AIや外部とつないだら、社内が丸裸になるのでは」でしょう。これは誤解です。IBMはこう説明します。
APIは、特定の問い合わせに必要なデータと機能だけを共有する、あらかじめ定義された窓口である。サーバーはデータを全部さらす必要がない。（…）内部のシステム詳細は隠したまま保てるので、セキュリティの健全性を守るのに役立つ。
（IBM「What is an API?」）
つまり「この件に必要な分だけを、窓口から出す」のがAPIです。第1幕の「人が確認する関所」と同じ発想で、出す情報を絞れる。「つなぐ」と「丸見え」は別物だと、原典で押さえておきましょう。
つなぐと「手入力・転記」が消える
では、つなぐと何が変わるのか。IBMの別の解説が、核心を突きます。
API連携は、ツール同士を同期させてデータを行き来させ、一貫した正確なデータの「単一の出どころ」を作る。
（IBM「What Is API Integration?」）
たとえば在庫管理ソフトと受注管理ソフトをAPIでつなぐと、受注が入った瞬間に在庫が自動で反映される。人が画面を見比べて転記する必要がなくなります。連載08で見た「人が転記しない会社」は、このAPI連携で実現します。AIにとっても、つながった「正しいデータの出どころ」があれば、調べ物でなく実際の自社データに基づいて動けるようになります。
中小の実務判断軸：「APIドキュメントが公開されているか」を見る。APIは「エンドポイント（窓口のURL）」と「契約（やり取りの形を定めた定義書）」で成り立ちます。SaaSやツールを選ぶとき、APIの説明書が公開されているかが「つなげる／つなげない」の現実的な分かれ目。情シスがいなくても、これは確認できます。
レストランの比喩：客（自社ソフト）→注文（リクエスト・決まった形）→窓口（API）→厨房（相手ソフト）→料理（レスポンス）。窓口から出るのは「必要な分だけ」（丸見えでない）と明示。下に在庫×受注の同期例「単一の正しい出どころ＝転記消滅」。
まとめ
- APIは「決まりごと付きの窓口（契約）」。決まった形でやり取りするから安定してつながる。
- つなぐ＝丸見えではない。必要な分だけを出せる。
- つなぐと単一の正しいデータの出どころができ、手入力・転記が消える。判断軸は「APIドキュメントの有無」。