AIに業務を実行させるには？API連携の設計と外注範囲
- 12 時間前
- 読了時間: 10分
生成AIに「回答」だけでなく、予約変更・顧客情報更新・取消・通知などの業務実行まで任せる場合、設計の難しさは一段上がります。
重要なのは、AIが操作候補を決めることと、その操作を本当に許可・実行することを分けることです。本記事では、SIer・開発会社が顧客案件でAI実行機能を外注するとき、実行制御バックエンドをどの粒度で設計・発注すべきかを整理します。
はじめに：AIが「答える」段階と「業務を動かす」段階は別物
OpenAIのResponses APIでは、モデルに利用可能なツールや独自関数を与え、モデルが必要に応じてそれらを呼び出す構成を取れます。つまり、自然言語の依頼を既存システムや外部サービスの処理へつなげること自体は可能です。
ただし、モデルが「この操作を使う」と判断したことと、その操作を業務上実行してよいことは同じではありません。
たとえばAIが「注文番号123をキャンセルする」という操作候補を返しても、実際にキャンセル可能な注文か、その利用者に権限があるか、すでに処理済みではないか、といった判断は通常の業務システムと同じようにバックエンド側で行う必要があります。
結論：発注単位は「AI」ではなく「実行制御バックエンド」にする
AIに業務を実行させる機能は、次の3層に分けると責任分界を整理しやすくなります。
生成AI：利用者の意図を読み取り、実行したい操作と引数の候補を出す
実行制御バックエンド：その操作を実行してよいか検証し、必要なら承認を挟み、状態とログを管
理する
既存システム・外部API：登録・更新・取消・送信など実際の業務処理を行う
AIを使う価値は、更新処理そのものではなく、複雑な状況から「どの業務処理を使うべきか」を判断・組み立てられる点にあります。実際の更新・取消・通知は、従来どおり決定的なプログラムへ任せるのが基本です。
本記事で扱う中心は2番目の実行制御バックエンドです。
生成AI案件を契約としてどう切り出すか、モデルAPI利用料やプロンプト保守、検収条件をどう決めるかは別の論点です。ここでは、すでに「AIを使う1機能」が決まった後、その中身を発注仕様へどう落とすかに絞ります。
発注仕様に書くべき5つの実行制御
1. AIから呼べる操作を業務単位で限定する
AIへ「任意のURLへリクエストする」「任意のSQLを実行する」といった広い機能を渡すと、意図しない操作まで実行できる余地が増えます。
たとえば受注管理なら、AIから利用できる操作を次のように業務単位で定義します。
注文情報を取得する
注文をキャンセルする
配送先変更の申請を作る
担当者へ確認依頼を送る
OWASPのLLM06:2025 Excessive Agencyでも、LLMから利用できる機能と権限を必要最小限にすることが対策として挙げられています。
発注仕様には「どのAPIを利用できるか」だけでなく、AIから呼べる操作の一覧と、各操作で許可する引数まで書ける状態が理想です。
2. 認証・認可をAIへ任せない
AIが選択した操作は、あくまで実行要求の候補であって、権限そのものではありません。
バックエンド側では、現在の利用者、所属、権限、対象データの状態などを確認し、条件を満たした場合だけ下流システムを呼び出します。
特に注意したいのが、AIからの操作を共通の高権限サービスアカウントで実行する構成です。本来その利用者には見えないデータや許可されていない操作まで到達できる設計になりかねません。
OWASPも、認可をLLMの判断へ依存せず下流システム側で実施し、可能なら利用者の権限コンテキストで操作することを推奨しています。
発注仕様では少なくとも次を決めます。
誰の権限で下流APIを実行するか
操作ごとに必要な権限は何か
高権限の共通アカウントを使う場合、どこで利用者単位の認可を行うか
権限不足時にAIへ何を返すか
3. AIの出力は「入力候補」として通常コードで再検証する
Function callingや構造化出力を使えば、モデルからJSON形式などで引数を受け取れます。
しかし、形式が正しいことと、業務上正しいことは別です。
数量が数値になっていても上限を超えているかもしれません。日付形式が正しくても、その予約では変更できない日時かもしれません。顧客IDが存在していても、その利用者が操作してよい顧客とは限りません。
そのため、AIの出力をそのまま下流APIへ渡さず、バックエンド側の決定的なロジックで次を検証します。
型・必須項目
値の範囲
対象データの存在
現在の業務状態
利用者の権限
操作可能な時間・期限
メール、Webページ、取得文書など外部由来の情報をAIへ読ませる場合は、間接プロンプトインジェクションによって操作候補が誘導される可能性もあります。外部情報を読ませることと、その内容を命令として実行することを分離する設計が必要です。
4. 影響の大きい操作には人の承認を入れる
すべてをAIだけで完結させる必要はありません。
削除、返金、契約変更、外部への大量送信など、失敗時の影響が大きい処理では、AIが操作内容を作成した後に人が確認してから実行する構成が有効です。
OWASP LLM06でも、高影響操作について利用者の承認を求めることが対策として示されています。
発注時には、「承認が必要」という抽象表現だけでなく、次まで決めておくと実装範囲が明確になります。
どの操作が自動実行可能か
どの条件で承認が必要か
誰が承認できるか
承認待ちをどこへ保存するか
承認後に同じ条件を再検証するか
5. マルチステップ実行では「途中まで成功した状態」を設計する
AIが1回だけAPIを呼ぶとは限りません。
たとえば「注文をキャンセルして顧客へメールを送り、CRMにも記録する」という処理なら、次の3ステップがあります。
受注システムでキャンセル
メール送信
CRMへ対応履歴を登録
ここで2番目が失敗した場合、1番目のキャンセルはすでに完了しています。処理全体を最初から再実行すると、同じキャンセル操作を再度呼び出す可能性があります。
このためマルチステップのAI実行では、単純な「成功／失敗」だけでなく、どのステップまで完了したかをバックエンド側で管理することが重要です。
設計時には、少なくとも次を整理します。
各ステップの完了状態を記録するか
失敗したステップだけを再実行できるか
完了済み処理を再度呼ばない仕組みがあるか
取り消せる処理と取り消せない処理をどう扱うか
途中失敗時に人へ引き継ぐ条件は何か
通常のWebhook連携でも重複や再実行への対策は必要ですが、AIが複数のツールを順番に選択する構成では、「一連の業務のどこまで進んだか」を含めて状態管理する必要があります。
Webhook連携の重複・再送については、顧客案件のWebhook連携は、重複・再送・通知が来ない場合までどこまで任せるかで詳しく解説しています。
具体例：受注キャンセル機能を元請け・外注先でどう分けるか
顧客から「担当者が自然文で指示すると、AIが注文をキャンセルする機能」を求められたケースを考えます。
悪い切り方は、外注先へ「生成AIから受注APIを呼べるようにしてください」とだけ依頼することです。
これでは、誰が権限を確認するのか、何をもってキャンセル可能とするのか、承認が必要な条件は何か、途中失敗をどう扱うのかが決まりません。
元請け側で顧客と業務条件を整理し、外注先へ次のような実行仕様として渡すと、責任境界を作りやすくなります。
元請け・顧客：キャンセル可能条件、承認ルール、利用者権限を決める
外注先：AIの操作候補を受けるAPI、認可、状態検証、承認待ち、下流API呼び出し、操作ログを
実装する
既存受注システム：最終的なキャンセル可否を業務ルールに従って判定・実行する
試験も「AIが自然な返答をするか」だけではなく、次のように業務実行単位で作れます。
権限がない担当者からのキャンセル要求は拒否される
キャンセル期限を過ぎた注文は実行されない
承認対象の注文は即時実行されず承認待ちになる
同じ要求が再送されても二重キャンセルにならない
後続処理が失敗した場合、完了済みステップを保持して再開できる
この粒度なら、元請け側も顧客へ「どこまで安全策を実装するのか」を説明しやすくなります。
外部API・決済連携の設計で以前から見る点は、AIでも変わらない
AI実行機能には新しい論点がありますが、バックエンド設計の基本がすべて新しくなるわけではありません。
筆者は、予約・会員・課金を伴うシステムや外部API連携に携わる中で、正常系だけでなく、二重実行をどう防ぐか、途中失敗時にどこから再開するか、結果をどの状態として残すか、障害時にどう復旧するかを設計上の重要な論点として扱ってきました。
生成AIが入っても、この考え方は共通しています。
一方でAI実行では、そこへさらに「モデルがどの操作を選ぶか」「外部入力に操作選択を誘導されないか」「AIの判断だけで高影響操作を実行しないか」という論点が加わります。
つまり、AIだから別世界の設計になるのではなく、従来のバックエンド設計に、AI固有の不確実性と権限制御を追加すると考えると整理しやすくなります。
通常のAPI連携を外注するときの基本的な確認事項は、API連携開発を外注するときに確認すべきポイントも参考にしてください。
AIに業務実行を任せないほうがよいケース
AIからAPIを実行できるからといって、すべての業務をAI経由にする必要はありません。
次のようなケースでは、通常の画面・ルールベース処理・ワークフローのほうが適しています。
操作パターンが数種類しかなく、通常UIで十分な場合
入力条件が完全に決まっており、自然言語を介するメリットが小さい場合
誤操作時の影響が極めて大きく、AIによる操作選択自体を許容しにくい場合
AIを挟むことで、利用者が「何が実行されるのか」を理解しにくくなる場合
生成AIは、曖昧な自然言語から意図や候補を整理する部分には向いています。しかし、決められた業務ルールそのものまでAIへ置き換える必要はありません。
発注前チェック：実行仕様をこの粒度まで書けるか
外注先へ依頼する前に、次の7点を確認します。
AIから利用可能な操作一覧を定義したか
各操作を誰の権限で実行するか決めたか
AIが生成した引数をどこで再検証するか決めたか
人の承認が必要な操作と条件を決めたか
複数ステップの処理順序と途中失敗時の扱いを決めたか
実行結果・操作主体・対象・時刻をどこまでログへ残すか決めたか
元請け・外注先・顧客側システムの責任境界を決めたか
この7点が未確定でも、実装を始められないわけではありません。ただし、曖昧なまま請負成果物として固定すると、後から「どこまで作れば完成か」がずれやすくなります。
要件が固まっていない段階では、まず既存APIや権限構造を調査し、実行可能な操作とリスクを整理してから成果物単位の開発へ移る方法もあります。
まとめ：AIに任せる範囲より、AIから取り戻す範囲を決める
生成AIへAPIを利用させるとき、重要なのは「AIにどこまで自由に操作させるか」ではありません。
AIが操作候補を出した後、どの判断を通常のバックエンドへ取り戻すかを先に決めることが重要です。
操作の限定、下流システムでの認可、入力値の再検証、人の承認、マルチステップの状態管理、監査ログ。これらを実行制御バックエンドの責務として発注仕様へ落とせれば、AI部分と業務システム部分を別担当へ分けても責任境界を作りやすくなります。
NISTのGenerative AI Profileも、生成AIを利用する組織に対し、用途やリスクに応じた人による監督、追跡、文書化を含むリスク管理を示しています。
SIer・Web開発会社・DX支援会社の方で、顧客から「生成AIから既存システムや外部APIを動かしたい」と求められ、実行制御をどこまでバックエンドとして切り出すか整理したい場合は、プレイリーソリューションズへご相談ください。外部API連携や既存システム改修の知見を軸に、既存API・権限構造・業務フローの調査から、実行制御バックエンドの設計・実装範囲まで整理します。
