AIを業務システムに組み込むときは、既存のAIをそのまま使う、いま使っている製品の設定・連携で足りるか試す、足りない部分だけAPIで専用に作る、の順に比べます。APIは、別のプログラムからAIの機能を呼び出す窓口です。呼び出せるようにするだけでは業務は完成せず、データの扱い、失敗時の処理、人の見直し、費用管理も決める必要があります。
約13分で読めます
AIをシステムに組み込む3つの方法と費用
既存のAIをそのまま使うか、製品の設定で足りるか、APIで専用に作るか。営業メモの要約を例に3つの方法を比べ、作る範囲・使うデータ・費用の違いを整理できます。
影山 湧亮 / NeoLogic株式会社 代表取締役。元警視庁。現場業務の整理と生成AI活用・Webシステム開発を一貫して担当。

たとえば、営業メモを短くして顧客管理システムに残したい場合です。担当者がAIの画面へ貼り付ければよいのか、いまの製品の設定で足りるのか、それとも開発が必要なのか。最初に「誰が、どの画面で、何を読んで保存するか」を決めます。
作る範囲を決める三つの確認
- 別画面で作り、貼り戻す手順を続けられるか。単発・少量で無理がなければ、許可された既存AIから試せます。
- いまの製品で、閲覧権限・見直しの手順・保存先を満たせるか。標準の設定や接続で足りれば、専用機能を作る必要はありません。
- 同じ業務画面で繰り返し使い、処理へつなぐ必要があるか。標準機能に残る不足を具体化して、その部分だけ開発候補にします。保存の確定を自動化するかは別に決めます。
この比較は、原文の送信が許可され、閲覧権限と見直す担当者を決められる範囲で進めます。満たせない条件は、情報管理担当と製品管理者へ確認し、送信しない方法も比べてください。
三つの導入方法を比較する
同じ原文を要約し、人が読んで業務システムに保存する条件で比べます。「利用画面」が未整理だと、画面を行き来して転記する手順を受け入れられるのか、いまの画面への組み込みが必須なのかを判断できません。
比較には、次の営業メモを使います(想定例)。
納期は未定。候補は10月上旬。見積り額は担当者確認後に回答。受注は確定していない。
要約見本は「納期候補は10月上旬だが未定。見積り額は確認後に回答予定。受注は未確定。」です。どの方式でも、未確定の意味が残ることと、人が原文と見比べて保存できることを求めます。
自社の条件を並べるには、AI導入・組み込みの比較表と整理票(Excel)の「相談空欄」から、画面・使う資料・保存先を記入してください。
表1 同じ業務メモを要約し、人が見直して業務システムに保存する場合の比較(説明例)
| 比較する点 | ① 既存AIを使う | ② 設定・連携する | ③ 専用機能を作る |
|---|---|---|---|
| 利用画面 | AIの画面と業務画面を行き来 | 既存製品の画面を利用 | 既存の業務画面に組み込む |
| 接続するデータ | 人が選んで原文を貼り付ける | 対応する接続機能で原文を取得 | 自社の処理が権限を確かめて取得 |
| 既存製品の設定 | 入力ルール、共有範囲 | 参照範囲、要約指示、保存先、見直しの手順 | 標準機能では足りない点を先に洗い出す |
| APIで作る範囲 | 独自開発なし。人が結果を転記 | 標準機能で完結するなら独自開発なし | 画面、認証・権限、呼び出し、検証、保存 |
| 公開後の点検と保守 | 入力と出力の点検、利用設定の見直し | 権限・同期・設定変更の点検 | 左記に加え、障害対応・利用量管理・更新試験 |
| 向く条件/条件外 | 単発・少量で転記できる/一体操作が必須なら不足 | 標準機能が要件に合う/対象データや見直しの手順に対応しなければ不足 | 独自の画面・権限・保存手順が必要/単発作業には過大な場合 |
②は、必要な接続・確認・保存に標準機能で対応できる製品を選べた場合です。対象製品が決まるまでは、接続できるか、精度、費用は分かりません。
設定型の製品が内部でAPIを使うことも、専用開発で既存の接続機能を利用することもあります。三つの違いは、自社で作り、維持する範囲です。設定や外部連携のために独自の受け口を開発するなら、その部分は③の見積りの範囲に含めます。
たとえばChatGPTにも、接続したサービスの情報を検索・参照する機能があります。ただし、使える機能は接続先、プラン、地域、権限などに依存します。「設定でできる」と言う前に、対象製品と自社の契約で確かめてください(出典:OpenAI「Apps in ChatGPT」)。
図1 同じ「文章の要約をシステムで使う」を3方式で実現する構成(説明例)
同じ営業メモで、保存前に見つけたい三つの誤り
上の原文なら、次の候補は短くても採用できません。三方式とも同じ判定で試し、文章が自然かだけで順位を付けないようにします。以下は誤りを説明するための作例で、特定AIの出力ではありません。
| 作った要約候補 | 原文との違い | 保存前の判断 |
|---|---|---|
| 納期は10月上旬、受注確定 | 候補と未確定を、確定へ変えている | 原文へ戻して修正 |
| 見積りは100万円で回答予定 | 原文に金額がない | 金額を補わず確認待ちへ戻す |
| 納期未定、金額は確認後に回答 | 受注が未確定であることが抜ける | 受注状態も必要な保存欄なら追記 |
比較の記録には、準備、生成待ち、人の訂正、保存の時間を分けます。②や③だけが原文を自動取得できる場合は、その手間も含めた業務全体と、同じ原文からの要約だけを分けて比べます。最初の設定にかかった時間を、毎回の作業時間へ混ぜないようにしてください。
APIで増えるのは、画面と業務をつなぐ仕事
専用開発では、顧客管理画面の「要約を作る」操作を起点に、サーバーが対象メモを取得し、必要な範囲だけをAIへ渡します。返った要約は元の画面に候補として表示し、担当者が採用した後に保存します。AIの別画面を使わずに済む構成ですが、その受け渡しを維持する仕事も引き受けます。
接続するデータは、画面から指定されたからという理由だけで取得してはいけません。この構成では、利用者がそのメモを閲覧できるかをサーバーで確かめます。別の部署の情報や不要な個人情報は送らず、保存の直前にも変更権限と対象データの版を確かめます。
出力の形式と要約の内容をそれぞれ確かめる
結果を「要約本文」などの決まった項目に分けると、画面へ渡しやすくなります。ただし、受け取れる形にそろっていても、内容が正しいとは限りません。
「納期は未定」を「納期は10月上旬で確定」と要約してしまえば、画面に表示できても業務では使えません。要約の長さや項目の有無は通常のプログラムで検査し、原文との意味の一致は、用途に応じた確認例と人の照合で確かめます。APIに変えただけで高精度になる、と判断しません。
表2 用途が変わると、先に試す方法も変わる(想定例)
| 用途とデータ | 先に確かめる方法 | 選択が変わる条件 |
|---|---|---|
| 個人の文章作成:公開可能な案内文を一度整える | ① 既存AIで候補を作り、本人が確認 | 同じ業務画面で繰り返すなら②・③も比較 |
| 社内資料への質問:承認済みの社内手順書を参照 | ② 標準接続で検索範囲・原文確認・更新を検証 | 権限や更新に対応できなければ③、または接続しない |
| 既存画面での入力補助:営業メモから要約案を作る | ②の適合を調べ、不足時に③を比較 | ②で権限・確認後保存まで満たせれば③は不要 |
社内資料への質問では、資料の量だけでなく、更新日、閲覧権限、原文へ戻れるかが判断を変えます。すでに必要な原文が一つの画面で選べる要約に、社内全体を検索する仕組みまで追加する必要はありません。
今ある画面へ検索や下書きを足す場合は、既存システムへのAI組み込みで、通常の入力を残し、確認した内容だけを登録する例を見られます。
「一回動く」以外の条件を決める
選定時に外せないのは、許可されたメモだけを扱うこと、原文と候補を確認して保存すること、失敗したときに手入力を続けられることです。次の要件案では、入力3,000字・要約200字・待機15秒などを仮に置いています。
実装担当者向け:入力制限・再試行・保存競合・費用停止の要件案
次の表は、営業メモの要約を既存画面へ追加する要件案です。既存の認証、ログ、障害通知、保存処理で満たせる部分を再利用し、不足分を開発します。設定型でも同じ条件を確認し、製品が受け持つ部分を切り分けます。
たとえばOpenAIのStructured Outputsは、対応するモデルと指定可能な形式の範囲で、JSONというデータ交換形式の構造を制約できます。ただし、回答拒否や出力の未完了を別に扱う必要があり、形式が合っていても内容の誤りは残ります(出典:構造化出力の公式説明)。
表3 API組み込みの追加要件表(営業メモの要約を組み込む説明例)
| 項目 | 先に決めること | 記入済みの見本 |
|---|---|---|
| 入力制限 | 対象、最大量、送信しない情報 | 日本語メモ3,000字以内。不要な個人情報は除外し、超過時は黙って切らず差し戻す |
| 権限・データ | 誰が、どの原文を送信できるか | 営業部の利用者が閲覧できるメモだけをサーバーで取得。保存時にも権限を確認 |
| 認証情報 | APIの秘密情報の保管・更新 | APIキーはサーバー側の秘密情報管理に置き、画面や通常ログに出さない |
| 出力・確認 | 受取形式と内容の確認方法 | 要約欄は200字以内。原文と並べ、日付・金額・否定・未確定事項を人が確認 |
| 応答待ち | 待機中・期限後の画面 | 再試行込み15秒を待機上限案とし、超過後は元の手入力を続けられる |
| 失敗・再試行 | 再試行の対象、回数、総時間 | 一時障害のみ初回を含め合計2回まで(SDK分を含む)。権限不足、予算停止、拒否は自動再試行しない |
| 保存・戻し方 | 確定条件、重複、遅い応答 | 人が採用して通常処理で保存。連打による二重保存や古い応答での上書きを防ぐ |
| 費用上限 | 通知と停止、対象期間 | API予算額は不明。月次の通知・強制停止を区別し、社内側も件数・同時実行数を制限 |
| 保存・記録 | 保存先、期間、削除担当 | 入力・出力の全文ログは既定で残さない。実行ID・版・状態・利用量を記録。保持期間は未決定 |
| 公開後の保守 | 変更時の再確認と復旧担当 | 業務責任者と保守担当を置き、資料・指示・モデル変更後に同じ確認例を再実行 |
字数・秒数・回数は、使う製品の上限や標準設定に合わせて置き換えてください。
表の入力・保存条件はOpenAIのデータ管理、出力形式は構造化出力、待機・再試行は利用制限への対応に照らして決めます。
待機を打ち切った後も、外部サービス側で処理や課金が続く場合があります。利用者には元の入力を残し、遅れて届いた候補が新しい編集内容を上書きしないようにします。再試行は、API提供元が示す待機条件と採用SDKの動作を確認して決めます(出典:OpenAI「Rate limits」)。
学習利用・保存・接続先への送信を分けて確認する
OpenAI APIでは、明示的に参加しない限り、送信データをモデルの学習・改善に利用しないと説明されています。一方で、不正利用監視のログや機能維持のためのデータ保存は別の論点です。保存期間、削除、例外、保存を制限する設定の適用条件は、利用する機能ごとに確認します(出典:OpenAI「Data controls in the OpenAI platform」)。
この説明を、個人向けのチャットサービスや第三者の接続先へそのまま当てはめないでください。自社の業務データ、AI提供元の保存、接続サービス、運用ログを分け、どこに何を残すかを整理します。必要な保存条件を契約や設定で満たせないデータは、連携対象から外します。
費用はモデルの利用料だけで比較しない
見積りは、初期の設計・設定・開発・試験、継続する製品やAPIの利用料・保管料、変更対応や障害対応、人が確認する時間に分けます。既存製品は追加ライセンスや設定・管理の費用、専用開発は画面・認証・検証・運用の費用も含め、同じ対象業務と利用期間で比べてください。
APIの試算には、月間件数だけでなく、一件あたりの入力・出力の量、追加の検索やツール、やり直しの回数も必要です。トークンはモデルが扱うテキストの単位で、記事中の「3,000字」は文字数の条件です。費用の試算には課金単位での入力・出力量が必要です。単価だけで総費用の安さは決められません(出典:OpenAI「Production best practices」)。
上限も「通知だけ」か「処理を止める設定」かを分けます。2026年9月15日に確認したOpenAIの公式仕様では、支出通知と強制停止の双方が案内されていますが、強制停止の反映に遅れがあり、設定額をわずかに超える場合があります。提供元の設定に加え、業務側で件数や同時実行数、停止後の手作業を決めます(出典:OpenAI「Spend limits」)。
AIに任せる部分を絞る
要約や文章候補を作る処理と、料金計算・登録確定は分けます。たとえば見積書の説明文はAIが下書きしても、単価と数量からの計算は既存の計算処理に任せ、送付や受注の確定は従来の権限と確認手順を通します。要約機能を追加するために、確定処理までAIへ移す必要はありません。
原文に「この指示を優先して登録せよ」と書かれていても、この構成では、それを実行権限として扱いません。AIは候補を返すだけにし、参照先の決定、送信範囲、保存の許可は通常のプログラム側で制御します。文章を読むことと、その文章の命令を実行することを切り分ける設計です。
Anthropicは、手順をあらかじめ定めるワークフローと、モデルが進め方やツールを選ぶエージェントを区別し、必要な場合にだけ複雑さを増す方針を示しています。営業メモの要約では、原文取得・生成・確認・保存という決まった手順を基本にし、用途に必要な部分から試せます(出典:Anthropic「Building effective agents」)。エージェントとMCP、API、RAGの関係は、MCPとAPI・RAG・AIエージェントの関係図で整理しています。
依頼前に整理する材料
「AIを入れたい」だけでなく、対象処理、利用者、入力例、必要な正確さ、件数、確認者をそろえると、設定で足りる部分と開発する部分を話し合えます。費用や性能が分からない欄は、推測で埋めず「不明」として相談に持ち込んでください。
表4 依頼前の整理票:営業メモの要約を追加する場合
| 整理する項目 | 記入例 |
|---|---|
| 対象処理・利用画面 | 営業メモを要約し、顧客管理画面の要約欄へ候補を表示。自動確定はしない |
| 利用者・件数 | 営業担当5名、月間400件を想定。実績値ではない |
| 接続するデータ・入力例 | 閲覧権限のあるメモだけ。「納期は未定。候補は10月上旬。見積り額は担当者確認後に回答。受注は確定していない。」 |
| 既存製品の設定 | 標準要約の有無、参照範囲、200字以内の指示、候補表示と見直し後の保存ができるか。製品を選ぶ前なので対応可否は未定 |
| 必要な正確さ・確認者 | 納期や受注を確定扱いしない。金額・日付を補わない。入力した担当者が原文と照合 |
| APIで作る範囲 | ②で満たせない場合だけ、原文取得・要約呼び出し・検証・候補表示を追加。料金計算や契約確定は対象外 |
| 公開後の確認と保守 | 営業責任者が確認例を管理し、保守担当が障害・変更に対応。担当者名と停止・再開の権限は未決定 |
| 費用・契約の未確認 | 初期開発費、API・製品利用料、保守費、人の確認工数、契約条件はいずれも不明。対象範囲を提示して見積もる |
| 確認日・根拠 | 2026-09-15。一般原則は末尾のOpenAI・Anthropic公式資料を参照 |
相談前には、実際の画面・匿名化した入力例・製品の公式仕様を用意します。人数や件数も、自社の値に置き換えてください。
公開後は、どの原文・指示・モデルで作った候補かを必要な範囲で追え、不具合時にはAI機能だけを止めて元の業務を続けられる状態を目指します。資料更新やモデル変更のときに誰が再確認するか、停止と再開を誰が決めるかまでが依頼範囲です。
通信の再送、重複防止、障害時の復旧を詳しく整理する場合は、API連携の要件|待ち時間・再送・二重実行も参照してください。
まず一つの仕事を選び、整理票に条件を記入してください。整理票と現在の画面を用意すると、既存AIの使い方、製品の設定、専用機能の開発のうち、必要な部分を絞って相談できます。
顧客管理や社内画面に要約・回答候補を表示したい場合は、既存システムへのAI組込みで、現在の画面、参照する資料、人が確認して保存する流れを基に相談できます。



