AIと社内システムをAPIでつなぐ基本：仕組み・手順・安全の確かめ方

自社の「基盤とセキュリティ」の準備度は？10問・約3分で確かめる（無料・登録不要）

生成AIは、社内の在庫や顧客の情報、業務システムとつながることで、使える場面が大きく広がります。そのつなぎ役になるのがAPI（システムどうしがやりとりする窓口）です。この記事では、AIとAPIがどう組み合わさるのか、進める手順、安全に使うために確かめる点を、公開されている資料をもとにまとめます。

AIとAPIは、どう組み合わさるのですか？

生成AIに社内システムを使わせる代表的な方法が「ツール利用（Function Calling）」です。ある生成AIの提供元の公開資料は、仕組みを次のように説明しています。

• 自社のプログラムが、使えるツール（機能）の名前と、受け取る値の形をAIに伝えます
• AIは、質問に答えるためにツールが必要だと判断すると、どのツールをどの値で使うかを返します
• 自社のプログラムがツールを実行し、結果をAIに返します
• AIは結果をもとに回答を作ります。必要なら、この流れを繰り返します

この資料は、AIのモデルそのものは何も実行せず、実行するのはモデルの外の仕組みだと説明しています。社内のデータベースや業務システムを呼び出すツールは、自社のアプリケーションが実行します。言い換えると、AIが提案した呼び出しを、そのまま実行するか、確かめてから実行するかを、自社の側で決められます。

AIとツールのつなぎ方をそろえる取り決めとして、MCP（Model Context Protocol）もあります。仕様は、AIのアプリ（ホスト）、その中の接続役（クライアント）、データや機能を提供する側（サーバー）の3つの役割を定め、サーバーが提供するものとして、データ（リソース）、決まった形の指示（プロンプト）、AIが実行する機能（ツール）を挙げています。詳しくは「MCPとは：AIと社内のシステムをつなぐ仕組み」をご覧ください。

どんな場面で役立ちますか？

APIでつなぐと、AIが手元の情報だけで答えるのではなく、社内の最新の情報を使えるようになります。例を挙げます。

読み取りと書き込みでは、うまくいかなかったときの影響が大きく違います。読み取りの連携から始め、書き込みは下書きや承認を挟む形から広げると、影響を抑えながら進められます。

どう進めればよいですか？

① 目的とつなぐ範囲を決めます。 「誰の、どの業務の、どの手間を減らすか」を決め、そのために必要なシステムと機能だけを選びます。最初からすべてのシステムをつなごうとすると、確かめる範囲が広がりすぎます。

② つなぐ先のAPIを確かめます。 使っている業務システムやクラウドサービスに、APIがあるか、どんな操作ができるか、利用の条件や回数の上限はあるかを確かめます。APIがない古いシステムの場合は、「古いシステムとAIのつなぎ方」も参考になります。

③ ツールの形を決めます。 AIに渡すツールは、名前と説明、受け取る値の形をはっきりさせます。「顧客を検索する」「注文の状況を調べる」のように、1つのツールの役割を小さく分けると、権限を絞りやすくなります。

④ 読み取りで試します。 試験用の環境や、影響の小さいデータで動きを確かめます。AIが意図しないツールを呼んでいないか、値の誤りがないかを記録で見ます。

⑤ 書き込みは承認を入れて広げます。 登録・更新・送信などの操作は、まず下書きを作る形にし、人が確かめてから実行する流れにします。

⑥ 運用の決まりを作ります。 担当者、記録の確認の頻度、障害のときの止め方を決めます。

安全のために、何を確かめればよいですか？

APIは便利な反面、守りが弱いと情報の漏えいや不正な操作の入口になります。セキュリティの団体OWASPがまとめた「API Security Top 10」（2023年版）は、APIに多い問題として、オブジェクトの単位の認可の不備、認証の不備、リソースの消費の上限がないこと、機能の単位の認可の不備、APIの一覧（インベントリ）の管理の不備、外部のAPIを安全でない形で使うこと、などを挙げています。

AIとつなぐ場合も、基本は同じです。確かめる点を整理します。

• 認証：誰（どの仕組み）からの呼び出しかを確かめます。IPAの「API標準設計ガイド・基礎編」は、認証の方式としてAPIキー、OAuth 2.0、OpenID Connectを挙げ、通信をTLS（HTTPS）で守ることを示しています。APIキーなどの秘密の情報は、プログラムの中やAIへの指示に直接書かず、別に管理します。
• 認可（権限）：AIが使う接続の権限を、業務に必要な範囲に絞ります（最小権限の原則）。利用者ごとに見てよい情報が違う場合は、AIの接続にも、その利用者の権限を引き継がせる設計にします。
• 値の確認：AIが作った呼び出しの値を、そのまま信じずに確かめます。外部の文章を読んだAIが、細工された指示に従ってしまうことがあるためです（「自社のAIアプリのセキュリティの確かめ方」参照）。
• 回数と費用の上限：一定の時間の呼び出しの回数に上限を設けます。同じガイドも、一定時間内に許可するリクエストの数を制限すること（レートリミット）を挙げています。AIが同じ処理を繰り返すと、相手のシステムの負荷や、従量課金の利用料が増えるためです。
• 記録：誰の依頼で、AIがどのツールをどの値で呼び、結果がどうだったかを残します。問題が起きたときに原因を追えるようにするためです。
• 一覧の管理：どのAPIを、どのAIの仕組みにつないでいるかを一覧にし、使わなくなった接続は止めます。

MCPの仕様も、利用者がデータへのアクセスと操作を理解し同意すること、ツールの実行の前に利用者の同意を得ること、ツールの説明は信頼できるサーバーから得たものでない限り信用しないこと、などを原則に挙げています。AIエージェントに複数の操作を任せる場合は、「AIエージェントを安全に使うための権限と確認」もあわせてご覧ください。

作るか、既製の連携を使うか、どう考えますか？

業務システムやSaaSの中には、生成AIとの連携の機能や、MCPのサーバーをあらかじめ用意しているものもあります。既製の連携を使うと早く始められますが、どの情報がどこへ送られるか、権限をどこまで絞れるかは、サービスごとに確かめる必要があります。自社で作る場合は、権限や記録を細かく設計できる一方、作る手間と保守の担当が必要です。判断の目安は「AIは作るか買うか：判断の目安」にまとめています。

チェックリスト

• 連携の目的と、つなぐシステム・機能の範囲を決めている
• つなぐ先のAPIの操作の内容、利用の条件、回数の上限を確かめている
• 最初は読み取りの連携から始めている
• 書き込みの操作は、下書きと人の承認を挟む形にしている
• APIキーなどの秘密の情報を、プログラムやAIへの指示に直接書いていない
• AIが使う接続の権限を、業務に必要な範囲に絞っている
• AIが作った呼び出しの値を、実行の前に確かめる仕組みがある
• 呼び出しの回数と利用料に上限を設けている
• 誰の依頼で、どのツールが、どの値で呼ばれたかを記録している
• つないでいるAPIの一覧があり、使わない接続を止めている