API入門｜APIとは何かを身近なたとえで理解しシステム連携を見極める

打ち合わせの席で「これはAPIで連携できます」と言われた。別の場面では「APIが公開されていないので無理です」と言われた。どちらも、できる／できないの判断だけがこちらに求められるのに、何がどうつながるのかがピンとこない——「API連携」という言葉の正体が分からないまま、話を持ち帰っていないでしょうか。

APIとは、システム同士が決まった窓口・決まった作法でデータをやりとりする仕組みです。難しいプログラミングの話に聞こえますが、「画面の手作業を介さずに、システム同士が直接つながる窓口」と捉えれば、コードを書かない人でも「この業務はAPIでつなげそうか」「つなぐ前に何を確認すべきか」を判断できます。本講座は、その判断の入口に絞ります。実際にツール同士をつないで動かす操作はノーコードツール入門、APIが置かれている土台であるクラウドそのものの理解はクラウド基礎入門、どこを自動でつなぐかという自動化フロー全体の設計はAI業務自動化入門、DXの全体像はDXの基礎が、それぞれの正本です。本講座はそこには踏み込みません。

この講座を終えると、次の3つができるようになります。APIとは何かを身近なたとえで説明できること、「頼む→決まった形で返ってくる」という基本のやりとりの流れを説明できること、そして自分の業務から「APIでつなげそうな作業」を見つけ、つなぐ前に確認すべき点を書き出せることです。覚えて帰る型は「窓口（APIがあるか）→ 頼む→決まった形で返る → つなぐ前に3確認（有無・取れるデータ・安全面）」。本講座では、勤怠ツールのデータを毎月別のツールへ手で転記している作業（例）を題材に、これをAPIでつなぐとどうなるかを全章で追いかけます。

APIとは何か——システム同士をつなぐ窓口

APIは「システム同士が、決まった窓口でデータをやりとりする入口」

APIとは、プログラムの機能をその他のプログラムでも利用できるようにするための規約のことです（出典：総務省「平成30年版 情報通信白書」API公開の概要）。少しかみ砕くと、ソフトウェアやWebサービスの一部を公開する手段であり、「アプリケーション同士の接点（インターフェース）」と言いかえられます（出典：IPA「APIとは？」DX SQUARE）。本講座では、この「接点」をレストランの注文窓口にたとえます。客（別のシステム）がメニューから頼むと、キッチン（中身）は見えないまま、決まったものが窓口から出てくる——APIは、システム同士のあいだに置かれた、そういう「決まった窓口」だと思ってください。

人が画面を操作する代わりに、システムが直接データを受け取る

APIのいちばんの働きは、人が画面を操作しなくてもよくなることです。たとえば家計簿アプリと銀行口座をつないでおくと、インターネットバンキングにわざわざログインしなくても、家計簿アプリの側から残高が見られます。ここで両者をつないでいるのがAPIです（出典：IPA「APIとは？」DX SQUARE）。

共通例で考えましょう。勤怠ツールのデータを、毎月だれかが画面を見ながら別のツールへ手で転記している作業（例）があるとします。もし勤怠ツールに「勤怠データを渡す窓口（API）」があれば、人が写す代わりに、受け取る側のシステムが直接データを受け取れます。ビジネスでも、会計システムのデータを請求書発行のクラウドサービスへAPIで連携する、といった使い方が身近になってきています（出典：IPA「APIとは？」DX SQUARE）。つまりAPIが「ある」と、画面の手作業を介さずシステム同士が直接つながれる。「ない」と、人が画面を見て転記する手作業が残りやすい。ツール比較表の「API：あり／なし」が効いてくるのは、ここです。

「API＝難しいプログラミング」「あれば何でも自由に取れる」というつまずき

つまずきが2つあります。1つは「API＝エンジニアだけの難しい話」という思い込み。実際には、窓口で何が頼めて何が返るかという発想は、コードを書かなくても理解できます。もう1つは「APIがあれば、そのシステムから何でも自由に取れる」という思い込みです。APIで使える機能やデータは、提供する側が「どの部分を・どの範囲まで公開するか」を定めた範囲に限られます（出典：総務省「平成30年版 情報通信白書」API公開の効果と課題）。検討の段階から、公開の対象や範囲、利用者の認証を決めておく必要があるとも示されています（出典：IPA「APIとは？」DX SQUARE）。窓口で「出せると決められたもの」しか出てこない——この前提を押さえておくと、次の章の話がすっと入ります。なお、APIが置かれている土台であるクラウドそのものはクラウド基礎入門で扱います。

この章の確認（演習）

身のまわりのツール連携を1つ思い出してください（例：カレンダーに別アプリの予定が自動で出る、地図アプリが別サービスから店の情報を表示する）。そのうえで、「どのシステムが、何のデータを、どこに渡しているか」を、窓口のたとえを使って一文で言葉にしてみましょう。

APIのやりとりの流れ——頼む→決まった形で返ってくる

やりとりは「これをください（リクエスト）→決まった形で返す（レスポンス）」の往復

APIのやりとりは、こちらが「これをください」と頼み（リクエスト）、相手が処理した結果を返す（レスポンス）、という往復が基本です（出典：デジタル庁 e-Gov Developer「API共通仕様」）。注文窓口で「Aを1つ」と頼むと、決められた形でAが出てくるのと同じ構図です。頼みを受け付ける窓口そのものにも名前があり、エンドポイントと呼びます。エンドポイントとは、APIが提供する機能やデータにアクセスするための窓口となるURLのことです（出典：IPA「API標準設計ガイド・基礎編」）。つまり、決まった窓口（エンドポイント）に向かって頼み（リクエスト）を出すと、結果（レスポンス）が返ってくる——これがやりとりの骨格です。

返ってくる形が決まっているから、受け取った側が自動で処理できる

ここが、人の手作業とAPIの決定的な違いです。APIでやりとりするデータは、あらかじめ決められた形で受け渡されます。公的なAPIでも、リクエストとレスポンスのデータ形式はJSONという形式に統一する、と定められています（出典：デジタル庁 e-Gov Developer「API共通仕様」）。JSONはデータの記述形式の一種で、その構造やルールをあらかじめ定義しておくことで、データの整合性を保つ目的で使われます（出典：IPA「API標準設計ガイド・基礎編」）。

共通例に戻します。勤怠データの窓口（API）に「先月の全員の出退勤をください」と頼む（リクエスト）と、決まった形（例：名前・日付・出勤時刻・退勤時刻…）でデータが返ってきます（レスポンス）。返ってくる形が毎回決まっているからこそ、受け取った側のツールが、人の目で確認しなくてもそのまま取り込めるのです。これが、画面を見て手で写すのとの違いです。

「頼めば何でも好きな形で返る」「画面表示と同じ」というつまずき

つまずきは、「頼めば何でも、こちらの好きな形で返ってくる」という誤解です。実際には、頼むときに渡す指定（パラメータ）の形や制約も、返ってくるレスポンスの形式も、APIの仕様であらかじめ決められて統一されています（出典：IPA「API標準設計ガイド・基礎編」）。頼める内容も返る形も「決められた範囲」だ、と捉えてください。この「決まっている」性質こそが、システム同士の自動連携を成り立たせています。なお、この頼む→返るのつなぎ目を実際のツールで設定してつないで動かす操作は本講座の範囲外で、手を動かしてつなぐ手順はノーコードツール入門で扱います。

この章の確認（演習）

共通例の勤怠連携（例）について、3行で書き出してみましょう。1行目に「何を頼むか」、2行目に「どんな形で返ってきてほしいか（どんな項目が欲しいか）」、3行目に「返ってこないと困る項目は何か」。窓口に向かって頼む側の立場で考えるのがコツです。

APIでつなげる業務を見極める——つなぐ前に確認すること

つなぐ前の3確認——APIの有無／取れるデータ／安全面

APIは万能ではありません。つなげるかどうかを見極めるには、3つの確認が起点になります。

1つ目は、そもそもAPIが公開されているか、自社のシステムと連携できるかです。これは技術担当でなくても、ツールの提供事業者に直接聞けます。「API連携できますか？」「どんなAPIがありますか？ このAPIで当社が使っている○○システムとデータ連携できますか？」という聞き方ができると示されています（出典：IPA「APIとは？」DX SQUARE）。

2つ目は、何のデータを・どの範囲まで連携できるかです。前章で見たとおり、APIで取れるのは提供側が「どの部分を・どの範囲まで公開するか」を定めた範囲に限られます（出典：総務省「平成30年版 情報通信白書」API公開の効果と課題）。だから「APIはある」だけでは足りず、「自分が欲しいデータが、その窓口から取れるのか」まで確認する必要があります。

3つ目は、安全面です。勤怠データのように個人情報を含むものを流す場合、誰でもアクセスできては困ります。非公開とすべき情報を扱うときや、本人にのみ操作を許可したいときには、アクセス制御の仕組みが必要だとされています（出典：IPA「安全なウェブサイトの作り方」アクセス制御や認可制御の欠落）。APIでも、認証によって許可された利用者だけがデータを受け取れるようにする、という前提を確認します。

手で転記している「繰り返し・形の決まった」作業ほど効果が出やすい

どんな作業がAPIでつなぐのに向くか。目安は、人が手で繰り返している、形の決まった転記や集計です。共通例の勤怠転記（例）はまさにこれにあたります。毎月、同じ項目を、同じように別ツールへ写しているなら、窓口（API）でつなげる余地があります。そこで技術担当に持っていく論点は、3確認をそのままあてはめて、「勤怠ツールにAPIはあるか／勤怠データは取れるか／個人情報が流れるが扱いは大丈夫か」の3つに整理できます。

つまずきは2つです。1つは、APIの有無を確認しないまま「たぶんつなげるだろう」で話を進めてしまうこと。2つ目は、流れるデータ（個人情報など）の安全面の確認を後回しにしてしまうことです。確認の順番を3確認に固定しておけば、どちらも防げます。

なお、選んだ作業を含めて「どの工程をどう自動でつなぐか」という流れ全体の設計はAI業務自動化入門で扱います。ツール導入そのものを後押しする公的支援として、中小企業・小規模事業者がITツールの導入経費の一部を補助され業務効率化を図れるIT導入補助金などの制度もあります（出典：J-Net21「サービス等生産性向上IT導入支援事業」）。具体的な枠や補助額は年度で変わるため、IT導入支援事業者など窓口に相談しながら進めるのが確実です。

この章の確認（演習）

自分の業務から「APIでつなげそうな作業」を1つ選んでください（手で繰り返している、形の決まった転記・集計が候補です）。そのうえで、技術担当に確認する論点を「①APIの有無 ②取れるデータ ③安全面」の3つで書き出してみましょう。これがそのまま、打ち合わせに持っていける相談メモになります。