AIエージェント開発の見積もり前に｜データ連携・実行権限・受入テストの決め方

「問い合わせを読んで、必要な情報を調べ、回答案を作るAIを開発したい」。

ここまで決まっていても、見積もりに必要な条件は残っています。顧客情報はどこから取得するのか。AIは回答案を作るだけか、顧客管理システムへ登録もするのか。途中で通信が切れたら、同じ処理を繰り返してよいのか。

AIエージェント開発を外注するときは、データ連携・実行権限・受入テストを同じ業務の流れに沿って整理します。 この三つがつながると、開発会社が作る範囲と、発注側が確認する条件を具体化できます。

対象業務が決まり、開発会社への相談や見積もり依頼を準備している事業責任者・DX担当者・情報システム担当者に向けた記事です。

この記事の要点

✅ 連携先はサービス名だけでなく、読み取る項目・書き込む項目・失敗時の処理まで整理します。

✅ AIの提案と外部システムへの実行を分け、承認した内容だけが実行される仕組みを確認します。

✅ 受入テストには正常時に加え、情報不足・権限外・承認後の変更・通信失敗を含めます。

「回答を作る」と「業務を完了する」で、開発範囲は変わる

AIエージェントは、目標に応じて情報を参照し、利用可能なツールを選びながら処理を進める仕組みです。一方、あらかじめ決めた順番で検索や生成を行うワークフローでも、業務の目的を満たせる場合があります。

Anthropicは「Building effective agents」で、この二つを区別し、必要性に応じて構成を複雑にする考え方を示しています。この記事でも、最初に自律性の高い構成へ決め打ちせず、必要な業務から設計を考えます。出典：Anthropic

例えば、次の二つは同じ「問い合わせ対応AI」でも、作るものが違います。

• 回答案の作成まで：承認済みFAQを参照し、回答案と出典を担当者へ表示する。

• 業務システムへの登録まで：担当者が確認した内容を顧客管理システムへ登録し、登録結果を記録する。

後者には、書き込み権限、承認、通信失敗への対応、登録結果の確認が加わります。見積もりを比較するときも、どちらの完成形を含むかをそろえる必要があります。

1．データ連携は「何を読んで、何を変えるか」で書く

「顧客管理システムと連携する」だけでは、読み取りだけなのか、情報の更新まで含むのかが伝わりません。

連携先ごとに、読み取りと書き込みを分けてください。 APIとは、システム同士がデータや処理をやり取りするための窓口です。利用できるAPIや操作範囲は、製品・契約・社内設定により確認が必要です。

以下は、問い合わせ対応AIを想定した説明用の設計例です。AIworkerの顧客案件や導入実績ではありません。

連携条件の記入例

問い合わせ受付

読むものは、問い合わせID、本文、受付日時。処理を始める条件は、担当者が対象の問い合わせを選んだとき、とします。最初は受信した全件を自動処理する範囲まで広げません。

FAQの保管場所

読むものは、承認済みの回答、適用条件、更新日、参照先。下書きや失効した回答は参照対象から外す設計にします。どれが正式版かを決める担当者も必要です。

顧客管理システム

読むものは、その担当者が閲覧できる顧客の必要項目。書くものは、承認済みの対応記録だけに絞ります。連絡先の変更やデータ削除は、この例では対象に含めません。

処理履歴

問い合わせID、参照元、承認した内容の版、実行結果を関連づけて記録します。入力の全文を無条件に保存するのではなく、調査に必要な項目、保存期間、閲覧できる担当者を決めます。

この整理で、データ不足と接続方法の問題を切り分けられます。FAQが古いなら更新管理、必要な項目を取得できないなら連携方式を先に検討できます。

2．実行権限は「人が確認する」を動く仕様にする

「最後は人が確認します」と書いてあっても、確認する画面に登録先や変更内容が表示されなければ、判断できません。

承認画面には、実行先・対象データ・変更内容をまとめて表示する設計をおすすめします。この例では、問い合わせID、顧客の識別情報、回答案、参照元、登録する対応記録を確認対象にします。

さらに、承認と実行の間を設計します。

1. 担当者が、特定の版の回答案と登録内容を承認する。

2. 実行直前に、利用者の権限と承認済み内容をシステム側で確認する。

3. 承認後に内容や登録先が変わった場合は、再承認へ戻す。

4. 実行結果を受け取り、成功・失敗・結果未確認を区別して表示する。

AIへの指示文だけに、権限管理を任せないことが大切です。 実行する仕組み側でも、許可された操作と対象かを確認できる構成を開発会社へ求めます。

例えば、回答案を承認した後に別の顧客へ切り替わっても、前の承認を流用してはいけません。承認する人がいたという事実に加え、「何を承認したか」が追跡できる必要があります。

3．通信失敗は「もう一度」で解決しない場合がある

登録ボタンを押した後に画面が止まり、結果が返ってこなかったとします。登録に失敗したのか、登録は成功したが返答だけ届かなかったのか、その時点では分かりません。

そこで処理をやり直すと、対応記録が二重に登録される可能性があります。

再試行の前に、実行済みか確認できる設計が必要です。 この例では、問い合わせIDと操作を識別するIDを使い、同じ登録を重ねない方法を検討します。

連携先が重複防止の仕組みに対応していれば活用します。対応していない場合は、実行履歴の管理や登録結果の照合を組み合わせます。結果を確定できなければ自動再試行を止め、人の確認へ渡す設計も必要です。

開発会社には、「通信に失敗したらどうなるか」だけでなく、「登録済みか分からないとき、どの情報で確かめるか」まで説明してもらってください。

受入テストは、期待する動作まで書く

受入テストとは、発注側が合意した条件を満たすかを確かめるための検証です。入力・期待する動作・確認する記録を一組にすると、デモの印象だけに頼らず判断できます。

問い合わせ対応AIなら、少なくとも次のケースを検討します。以下はこの設計例に対する確認項目であり、すべてのシステムに共通する合格基準ではありません。

正常な問い合わせ

承認済みFAQに回答がある入力を使います。期待する動作は、根拠付きの回答案を表示し、承認前には書き込まず、承認後に指定した記録だけを登録することです。画面と連携先の記録を照合します。

必要な情報が足りない問い合わせ

対象商品や条件を特定できない入力を使います。期待する動作は、不足項目を示して確認へ戻し、確定した回答として登録しないことです。保留理由が履歴から分かるかも見ます。

閲覧権限のない顧客情報

権限の異なるテスト利用者で同じ依頼を試します。期待する動作は、許可されていない情報を回答や参照元に出さず、その情報を使った操作も実行しないことです。

承認後に内容や登録先を変更

承認済みの回答案を変更し、そのまま実行を試します。期待する動作は、古い承認では登録せず、変更後の内容で再承認を求めることです。承認と実行が同じ版に結びついているか確認します。

登録結果が返らない・同じ依頼が再度届く

テスト環境で通信失敗や重複依頼を再現します。期待する動作は、二重登録を防ぎ、結果を確定できない場合は未確認として停止することです。画面の表示だけでなく、連携先に作られた記録も確認します。

試す件数や繰り返し回数は、対象業務と誤りの影響に合わせて決めます。一度成功しただけで、本番で同じように動くとは判断できません。

文章の品質と、誤った操作を止められるかは分けて評価します。 回答案が読みやすくても、別の顧客へ登録されるなら、本番へ進める条件を満たしません。

開発会社へ渡す「連携・権限・テスト」の整理シート

次の項目を、対象業務について埋めてみてください。AIworkerがこの記事向けに整理した記入用のひな形であり、公的な規格ではありません。

• 業務の開始と完了：何をきっかけに処理し、どの状態で終わるか。

• 連携するデータ：どこから何を読み、どこへ何を書くか。正式版と更新担当は誰か。

• 利用者と操作権限：誰が、どの対象に、どの操作を行えるか。

• 承認する内容：何を画面に示し、誰が承認するか。変更時はどう戻すか。

• 失敗したときの処理：止める条件、結果の確認方法、再試行できる条件、連絡先。

• 合格を確かめる方法：入力例、期待する動作、確認する記録、評価する担当者。

• 未確定事項：何が分からず、誰が、いつまでに確認するか。

空欄があっても、相談は始められます。「未確定」を明示すれば、調査する作業も見積もりの対象にできます。

対象業務をこの形へ整理するところから相談したい場合は、AIworkerのお問い合わせ窓口をご利用ください。相談内容に、業務名と現在使っているシステムを記載いただくと、検討の入口を共有できます。

開発着手より、先に条件を整えたい場合

データの利用許可を決める人や、出力の正しさを確認する担当者が不在なら、まず体制を整える必要があります。技術的に接続できても、利用範囲や正解を外部の開発会社だけで決めることはできません。

また、既存システムの設定変更や、決まった処理の自動化で目的を満たせる場合は、その方法も比較します。必要な工程にだけAIを使う判断も、開発設計の一部です。

提案依頼書全体の構成は、AI開発の要件定義とRFPで整理しています。今回のシートは、その中の連携・権限・評価を具体化する補足として使えます。

よくある質問（FAQ）

Q. APIがあるか分からなくても相談できますか？

相談できます。利用中の製品名、契約プラン、管理担当者、読み書きしたい項目を整理してください。接続方法の調査を、開発本体と分けて依頼する方法があります。

Q. データを社外へ渡せない場合はどうしますか？

最初は項目名や形式を説明し、必要に応じて架空データで画面や処理を検討します。実データでの品質検証は別工程です。どの環境で誰が検証できるかを、データの管理者と確認します。

Q. 人が承認すれば、誤った実行を防げますか？

承認を置くだけでは十分ではありません。対象と変更内容の表示、承認後の変更検知、実行時の権限確認が必要です。担当者が確認できる量や時間かも、運用前に確かめます。

Q. 開発費用は、どの条件で変わりますか？

連携先の数と接続方法、書き込み範囲、承認の仕組み、例外対応、テストと運用の範囲で変わります。AIworkerでは、業務と必要な作業を確認し、範囲をそろえて個別に見積もります。

Q. 納品時には何を確認すればよいですか？

動作する画面に加え、合意した設計、設定、テスト結果、権限、実行履歴、障害時の手順を確認します。受け取る成果物と、変更・保守を担当する範囲は発注時に合意してください。

AIworkerへのAIエージェント開発相談

株式会社AIworkerは、業務特化型AIエージェント開発サービス「業務AIプロ」を提供しています。業務のヒアリングから設計・開発、導入後の運用・改善までを支援します。

この支援方針は、日本AI導入支援協会のAIworkerへのインタビューでも紹介されています。掲載記事は事業や方針についての取材であり、個別システムの性能を認証するものではありません。

「問い合わせを効率化したい」という段階から、一つの問い合わせが入り、担当者が確認し、対応記録が残るまでを具体化する。その過程で、開発範囲と社内で必要な準備をそろえます。

▶️ AIエージェント開発・業務AIのご相談

具体的な開発と本番運用を確認する

下書き生成の入力と確認画面は、スカウト文作成AIの設計例で具体化しています。稼働後の記録・停止・再開は、AIエージェントの本番運用：監視・停止・復旧の設計例をご覧ください。

著者情報

株式会社AIworker。企業向けに業務特化型AI・AIエージェント開発、生成AI研修、導入後の伴走支援を提供しています。

株式会社AIworker 公式サイト

この記事が参考になりましたら、スキで教えていただけると今後の記事づくりの励みになります。

参考資料

• Anthropic「Building effective agents」（2024年12月19日公開、2026年10月3日確認）：https://www.anthropic.com/engineering/building-effective-agents

• 株式会社AIworker「AI開発の要件定義とRFP」（2026年8月18日公開、2026年10月3日確認）：https://note.com/ai__worker/n/nbcad872eb76f

• 日本AI導入支援協会「株式会社AIworkerにインタビュー」（2026年10月3日確認）：https://j-aix.or.jp/journal/1266/

#AIエージェント #AI開発 #システム開発 #業務改善 #AIworker