本文へスキップ
NeoLogic
NeoLogic

AIをシステムに組み込む3つの方法と費用

既存のAIをそのまま使うか、製品の設定で足りるか、APIで専用に作るか。営業メモの要約を例に3つの方法を比べ、作る範囲・使うデータ・費用の違いを整理できます。

既存AIをそのまま使う、設定でつなぐ、専用に作る三つの選択肢

AIを業務システムに組み込むときは、既存のAIをそのまま使う、いま使っている製品の設定・連携で足りるか試す、足りない部分だけAPIで専用に作る、の順に比べます。APIは、別のプログラムからAIの機能を呼び出す窓口です。呼び出せるようにするだけでは業務は完成せず、データの扱い、失敗時の処理、人の見直し、費用管理も決める必要があります。

たとえば、営業メモを短くして顧客管理システムに残したい場合です。担当者がAIの画面へ貼り付ければよいのか、いまの製品の設定で足りるのか、それとも開発が必要なのか。最初に「誰が、どの画面で、何を読んで保存するか」を決めます。

作る範囲を決める三つの確認

  • 別画面で作り、貼り戻す手順を続けられるか。単発・少量で無理がなければ、許可された既存AIから試せます。
  • いまの製品で、閲覧権限・見直しの手順・保存先を満たせるか。標準の設定や接続で足りれば、専用機能を作る必要はありません。
  • 同じ業務画面で繰り返し使い、処理へつなぐ必要があるか。標準機能に残る不足を具体化して、その部分だけ開発候補にします。保存の確定を自動化するかは別に決めます。

この比較は、原文の送信が許可され、閲覧権限と見直す担当者を決められる範囲で進めます。満たせない条件は、情報管理担当と製品管理者へ確認し、送信しない方法も比べてください。

三つの導入方法を比較する

同じ原文を要約し、人が読んで業務システムに保存する条件で比べます。「利用画面」が未整理だと、画面を行き来して転記する手順を受け入れられるのか、いまの画面への組み込みが必須なのかを判断できません。

比較には、次の営業メモを使います(想定例)。

納期は未定。候補は10月上旬。見積り額は担当者確認後に回答。受注は確定していない。

要約見本は「納期候補は10月上旬だが未定。見積り額は確認後に回答予定。受注は未確定。」です。どの方式でも、未確定の意味が残ることと、人が原文と見比べて保存できることを求めます。

自社の条件を並べるには、AI導入・組み込みの比較表と整理票(Excel)の「相談空欄」から、画面・使う資料・保存先を記入してください。

表1 同じ業務メモを要約し、人が見直して業務システムに保存する場合の比較(説明例)

比較する点 ① 既存AIを使う ② 設定・連携する ③ 専用機能を作る
利用画面 AIの画面と業務画面を行き来 既存製品の画面を利用 既存の業務画面に組み込む
接続するデータ 人が選んで原文を貼り付ける 対応する接続機能で原文を取得 自社の処理が権限を確かめて取得
既存製品の設定 入力ルール、共有範囲 参照範囲、要約指示、保存先、見直しの手順 標準機能では足りない点を先に洗い出す
APIで作る範囲 独自開発なし。人が結果を転記 標準機能で完結するなら独自開発なし 画面、認証・権限、呼び出し、検証、保存
公開後の点検と保守 入力と出力の点検、利用設定の見直し 権限・同期・設定変更の点検 左記に加え、障害対応・利用量管理・更新試験
向く条件/条件外 単発・少量で転記できる/一体操作が必須なら不足 標準機能が要件に合う/対象データや見直しの手順に対応しなければ不足 独自の画面・権限・保存手順が必要/単発作業には過大な場合

②は、必要な接続・確認・保存に標準機能で対応できる製品を選べた場合です。対象製品が決まるまでは、接続できるか、精度、費用は分かりません。

設定型の製品が内部でAPIを使うことも、専用開発で既存の接続機能を利用することもあります。三つの違いは、自社で作り、維持する範囲です。設定や外部連携のために独自の受け口を開発するなら、その部分は③の見積りの範囲に含めます。

たとえばChatGPTにも、接続したサービスの情報を検索・参照する機能があります。ただし、使える機能は接続先、プラン、地域、権限などに依存します。「設定でできる」と言う前に、対象製品と自社の契約で確かめてください(出典:OpenAI「Apps in ChatGPT」)。

同じ営業メモの要約を、既存AIへの貼り付け、製品の標準接続、既存画面からのAPI呼び出しで作る3方式。API方式では権限・入力と返答の形式を確認し、人が原文と照合して通常の処理で保存します。

図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組込みで、現在の画面、参照する資料、人が確認して保存する流れを基に相談できます。

生成AIの導入・組み込みの支援内容を見る

参考出典

あわせて読む

状況にあわせてご相談ください

いまの状況を選ぶだけで、次に決めることが見えてきます。気になる点があれば、こちらからお返事します。