BRIDGECRM / AI BPO FOUNDATION
使うほど、
AIに仕事を渡せる。
今日の承認と修正を、明日のAIの力に。
判断根拠・HITL・自律実行ルール・学習ループを支える、AI BPOの共通基盤。
AIが下書きまで作り、人が承認する運用で、すでに効率化を検証しています。その業務から得られる正解・修正データを蓄積し、毎日の出力改善と自律実行範囲の拡大につなげる仕組みをつくります。
01 / VALUE & FEEDBACK
下書きと承認で、すでに効率化。
その仕事が、AIを育てていく。
ContactXが電話音声やFAXの注文書などの一次情報を受け取り、AIが内容を構造化して登録用の下書きを用意。人は内容を確認・承認し、必要な箇所だけを直します。この運用での効率化は検証済みです。
VERIFIED VALUE / 現在の価値
人がゼロから入力する仕事を減らす。
AIが下書きまで作ることで、人の作業を確認と承認へ移せます。完全な自律実行に至る前から、プロダクトとして効率化の価値を提供できます。
CONTINUOUS IMPROVEMENT / 育つ価値
確認・修正が、次に任せるためのデータになる。
どこが正解で、どこを人が直したかを業務の中で自然にラベル化。その蓄積を使い、精度と自律実行できる業務の範囲を広げていきます。
01 / CONTACTX
一次情報を受け取る
電話の音声やFAXの注文書を、元の情報として保持する。
02 / AI
登録用の下書きを作る
内容を構造化し、基幹システムの入力項目・形式に合わせる。
03 / HUMAN IN THE LOOP
人が確認・承認する
一次情報と判断根拠を確認。必要な箇所だけ直して承認する。
04 / EXISTING SYSTEM
基幹へ登録する
確認済みのデータを登録し、処理結果を記録する。
05 / BRIDGECRM
承認・修正を蓄積する
正解だった出力、修正前後の差分、登録結果をラベルとして残す。
06 / DAILY IMPROVEMENT
日々改善し、任せる範囲を広げる
蓄積したデータで出力を調整・評価し、自律実行ルールを育てる。
改善した出力とルールを、次の業務へ。使うほど、AIに渡せる仕事を増やしていく。
02 / HUMAN IN THE LOOP
いつもの確認が、
正解を教える仕事になる。
HITL（Human in the loop）は、AIの処理に人の確認・判断を組み込む仕組みです。BridgeCRMでは、構造化データが一次情報に合っているか、基幹システムへ正しく登録できる項目・形式かを人が確認します。
一次情報 / FAXの注文書
商品 A-102 3ケース
抽出した値から、注文書の該当欄へ戻って確認する。
AIが、基幹システムに渡す構造化データを用意する。
- 商品コード
- A-102
- 数量
- 3
- 単位
- 個
確認して修正不要だった下書きも、正解として確認されたデータになります。この表示は学習ループを説明する例で、実際の確認・登録・学習処理は行いません。
EVIDENCE
判断根拠に戻れる
電話の発言箇所やFAX原本の該当欄と、AIが抽出した値を紐づける。人が根拠と下書きを見比べて確認できる形にします。
LABELS
修正前後が、ラベルになる
修正なしの承認、修正した項目、修正前の値、確定した値を記録。別途ラベル付けだけの作業を設けず、普段の業務から改善データを得ます。
RESULTS
登録結果まで紐づける
下書きの形式、内容の正しさ、実際の登録結果を分けて扱います。入力チェックを通過したことと、業務が正しく完了したことを照合できる形にします。
03 / DAILY IMPROVEMENT
今日の修正を、明日の出力へ。
任せられる仕事を増やし続ける。
蓄積した正解例と修正例を使い、毎日の出力を調整・評価する。改善した結果を自律実行ルールへ反映し、人の承認なしに任せられる業務を広げる。BridgeCRMは、その継続的な学習・改善のための基盤です。
- 01 / ACCUMULATE
業務のデータを蓄積
一次情報、判断根拠、下書き、承認・修正、登録結果を一つの案件として紐づけます。
- 02 / ADJUST & EVALUATE
出力を日々調整・評価
繰り返す誤りを見つけ、出力の指示・抽出方法・参照する文脈などを調整。蓄積した事例で、修正が減るかを確かめます。
- 03 / EXPAND
自律実行ルールを育てる
安定して正解できる業務の種類と条件を見極め、自律実行を許す範囲を広げます。確認が必要な処理はHITLへ戻します。
精度と、任せられる範囲を一緒に見る。
- 確認した案件の正解率
- 人が確認し、修正不要と判断した割合。
- 修正の内容・傾向
- どの項目を、どの値へ直したか。改善後に同じ誤りが減ったか。
- 自律実行率（委任率）
- 全案件のうち、定義されたルール内で人の承認なしに完了した割合。
04 / WHY NOW
AIが、言葉とシステムの間を
つなげるようになってきた。
近年のLLMの能力向上と周辺技術の進展により、非定型の依頼を読み、必要な情報を調べ、処理の候補を組み立てる選択肢が広がりました。
01
会話や文章を、業務データにする
LLMは、表現の異なる依頼から、意図や必要な項目を取り出せます。構造化出力の技術を使えば、抽出結果をシステムが扱う形式へそろえることもできます。形式が合っていても内容の正しさは別に検証します。
構造化出力の技術背景02
必要な情報を調べ、処理をつなぐ
ツール利用によって、AIが外部の情報を照会し、その結果を次の処理に使う構成を組めます。顧客を調べる、契約を確認する、登録案を作る、といった複数の手順を業務に沿ってつなげます。
ツール利用の技術背景03
過去の経緯を、今の依頼と結びつける
会話履歴、参照データ、利用できるツールなどを、その時点で必要な文脈として渡す設計が進んでいます。長い情報を扱えることに加え、必要な情報を選んで届けることが、業務での理解を支えます。
コンテキスト設計の技術背景05 / ONTOLOGY
会社の仕事を、
AIと共有できる地図にする。
オントロジーとは、ある領域の言葉と、その意味・関係を明示する考え方です。BridgeCRMでは、何を「顧客」「注文」「正しい登録」と呼ぶかを共通の業務モデルとして整理する設計を目指します。これが、AIの出力を確認・評価し、どの条件で自律実行を許すかを定める土台になります。
オントロジーの技術背景 ↓OBJECTS
対象
顧客、契約、注文、案件、候補者。業務の中に何が存在するかを定義する。
RELATIONS
関係
誰の注文か、どの契約に基づく案件か。情報同士のつながりを定義する。
STATE
状態
受付済み、確認待ち、承認済み、完了。いまどこまで進んでいるかを管理する。
ACTIONS & RULES
操作と条件
照会、変更、手配、通知。誰が、どの条件で実行できるかを業務ルールとして定める。
注文する
届ける先
関連する条件
契約条件・配送可否・変更権限を、対象の注文と結びつける。
状態の変化
変更依頼 → 確認待ち → 承認済み → 基幹への登録結果を確認。
会社ごとにシステムの項目名が違っても、共通の業務モデルとの対応を定義することで、AI側の業務理解と接続先ごとの違いを整理できます。業務ルールの定義と、実際に条件を検証する処理は、導入時に設計・確認します。
06 / CONTEXT
言葉の前後と、
仕事の前後を理解する。
オントロジーが「何が何と関係するか」という地図なら、コンテキストは「今、誰が、どの案件で、何をしようとしているか」という現在地です。会話だけでなく、関連記録・時点・権限・未完了の処理を組み合わせて、AIに渡します。
「さっきの注文、明日の午前に。届け先はいつもの場所で。」
言葉は読めても、変更する注文は特定できない。
- 誰からの依頼か
- 発言だけでは不明
- 「さっきの注文」
- 注文番号・現在の状態が不明
- 「明日の午前」
- 基準日や配送可否を確定できない
- 「いつもの場所」
- 住所を特定できない
次の処理：顧客・注文・配送先など、足りない情報を確認する
文脈を使うとは、曖昧な点を推測で埋めることではありません。記録から候補と根拠を取り出し、未確認の情報を区別することです。この表示は仕組みを説明する例で、実際のAIによる処理結果ではありません。
必要な記録を選ぶ
全文を無制限に渡すのではなく、対象案件に関係する顧客・契約・履歴を取得します。アクセス権限も、情報を取り出す前に確認する設計です。
出典と時点をそろえる
会話で聞いた希望、基幹に登録された事実、AIが推定した候補を区別します。記録の更新時刻や情報の食い違いを確認できるようにします。
確定していない点を残す
情報不足や矛盾は、追加確認や人への引き継ぎにつなげます。長い文脈を扱える能力と、正しい業務判断ができることは分けて検証します。
07 / INTEGRATION
基幹を入れ替えず、
その手前の仕事を変える。
既存の基幹システムには、長年のデータと業務ルールが蓄積されています。BridgeCRMは、AIが整理した依頼を、そのシステムが受け取れる操作へ変換する橋渡しを目指します。
- INPUT
依頼を受け取る
電話・会議・応募など
- BRIDGECRM
業務として解釈する
対象・文脈・必要項目を整理
- CHECK & APPROVE
条件と承認を確認
権限・業務ルール・例外を検証
- EXECUTE & VERIFY
接続先で結果を確認
登録・手配・通知の成否を記録
API
用意された窓口に接続
既存のAPIを通して照会・登録します。接続先の権限、入力条件、戻り値を確認し、操作結果を照合します。
CSV
今の取り込み運用に接続
確認済みのデータを既存の形式に合わせて受け渡します。ファイルを作るだけでなく、取り込み結果を確認する手順を設計します。
UI / RPA
既存の入力画面に接続
APIやCSVが使えない場合は画面操作を検討します。画面変更への対応や確認手順を含め、適用できる範囲を見極めます。
情報をデジタルにしてシステム間をつなぐDXから、その情報と文脈を使ってAIが実務を担うAIXへ。基幹全体の刷新を待たず、一つの業務から段階的に進める考え方です。
08 / SHARED FOUNDATION
違う現場の仕事を、
同じ基盤の上で育てる。
受付の形や成果物は違っても、一次情報から下書きを作り、人が確認し、修正を改善へ返す流れは共通します。判断根拠・HITL・データ蓄積・自律実行ルールをBridgeCRMへ集め、現場ごとの違いを業務モデルと接続部品で扱う構想です。
| プロダクト | 扱う業務の対象 | 現場で担う仕事 |
|---|---|---|
| ContactX | 電話音声・FAX原本・顧客・注文 | 一次情報を受け取り、構造化した下書きを作る |
| MeetLogAI | 会議・決定事項・担当者・タスク | 議事録と次のアクションを整理する |
| AI Recruit Hub | 求人・候補者・選考・日程 | 採用活動の実務をつなぐ |
| MENREN | 求人・設問・回答・面接記録 | 一次面接の記録を、人の選考判断につなぐ |
上記は共通基盤化の設計上の整理です。全製品がBridgeCRMに連携済みという意味ではありません。
09 / DEVELOPMENT
検証済みの効率化を、
継続的な改善の基盤へ。
AIによる下書き作成と、人による承認での効率化を検証済みです。この運用を起点に、データの蓄積・日々の出力改善・自律実行範囲の拡大をつなぐ共通基盤を育てます。
効率化を検証済み
AIが下書き、人は承認
AIが一次情報を構造化し、登録用の下書きを用意。人がゼロから入力する作業を、確認・承認する作業へ移す価値を検証しています。
開発・設計の方針
HITLから、日々の改善へ
判断根拠と正解・修正データを紐づけ、日々の調整・評価と自律実行ルールの改善に使う仕組みを整えます。他のプロダクトにも展開する構想です。
導入時に確認
一つの仕事で、効果を確かめる
接続可否と完了条件を確認し、まずは人の承認を含む運用から。完了件数、修正、担当者に残る作業を検証します。
REFERENCES
技術背景の参考資料
オントロジー、構造化出力、ツール利用、コンテキスト設計の一般的な技術背景です。BridgeCRMの構成は、これらを踏まえた当社の設計方針であり、各資料が製品の実装や提供状況を示すものではありません。
- W3C — OWL 2 Web Ontology Language Document Overview ↗用語の定義と関係を共有する、オントロジーの考え方。
- OpenAI — Introducing Structured Outputs in the API ↗定義した形式に合わせてモデルの出力を構造化する技術。
- Anthropic — Building effective agents ↗検索・ツール・記憶を組み合わせ、処理をつなぐ構成。
- Anthropic — Effective context engineering for AI agents ↗必要な情報を選び、限られたコンテキストを設計する考え方。