「紙やPDFの転記で毎日残業が続いている」「二重入力によるミスが増えてきた」「基幹システムの改修が怖くて先送りにしている」——こうした悩みを抱えるバックオフィス担当者は少なくありません。本記事では、私たちギグワークスクロスアイティが顧客の基幹システムを改善した事例に基づき、「レガシー基幹いきなり置き換えない改善の進め方」「kintoneへコア機能を先に移しAI-OCRで入力を減らす設計の勘所」そして「KPIで効果を示して次の完全クラウド移行へ繋げる方法」の3点を解説します。
【関連記事】データの分断に挑む！中堅小売企業の課題解決事例
D社で起きていた「詰まり」の正体
ここでは、D社が直面していた構造的な課題を整理します。表面上は「入力ミスが多い」「残業が減らない」という話に見えますが、その背景には、業務フロー全体に広がる4つの分断がありました。
D社に起きていた「4つの分断」
D社は、受発注から請求・入金管理までを担うバックオフィス業務を中心に、複数の拠点と部門を抱える企業です。創業から長年にわたって使い続けてきたレガシー基幹システムが業務の中核を担っており、その周辺にはExcelファイルやメール運用が複雑に絡み合った形で残存していました。
データの入口となるのは、紙の帳票・PDF・メール添付ファイルの混在です。取引先から届く注文書や請求書はフォーマットがまちまちで、担当者がその都度目視で確認しながら基幹システムへ手入力するという運用が長年続いていました。転記作業そのものがボトルネックになっており、担当者の時間の大半が、データを”運ぶ”作業に費やされている状態でした。
分断① 入力の分断
紙またはPDFを受け取った担当者が内容を読み取り、基幹システムへ手入力します。入力後は上長や経理担当がチェックし、不備があれば差戻し、担当者が修正して再提出——このループが日常的に発生していました。経理担当者は「入力よりも、差戻しの説明に時間が消えていく感覚があります」と当時を振り返りました。差戻しの理由を口頭やメールで説明するコミュニケーションコストも積み重なり、1件の登録に想定以上の時間がかかる構造が定着していました。
分断② データの分断
顧客情報・案件の進捗・請求の状況・入金の確認、これらが一気通貫で参照できる仕組みがありませんでした。基幹システムに蓄積されたデータとExcel台帳の内容が乖離していることも多く、営業・CS部門からは「請求の状況が見えないので、折り返し連絡ばかりになっています」という声が上がっていました。最新の状況を確認するには担当者に直接問い合わせるしかなく、情報が一箇所に集まっていないことで、意思決定や顧客対応に遅れが生まれていました。
分断③ 変更の分断
レガシー基幹システムは長年にわたる改修の積み重ねで内部構造が複雑化しており、一部の仕様はもはや現在の担当者では把握しきれない状態になっていました。業務要件が変わるたびに改修要望が上がるものの、そのリスクへの懸念から改修の優先度が常に下げられ続けていました。要望が積み上がるほど、改修への着手がさらに遠のくという悪循環に陥っていました。
分断④ 運用の分断
同じ業務でも担当者によって判断基準が微妙に異なり、入力ルールが属人化していました。「この取引先はこの表記で登録する」「この金額はこちらの科目にする」といったルールがドキュメント化されておらず、ベテラン担当者の知識に依存していました。異動や退職があるたびにルールが揺らぎ、誤入力や手戻りが増える構造が慢性化していました。
「残さざるを得ない機能」を見極める
現場のヒアリングを通じて明らかになったのは、すべての機能を移行できるわけではないという現実でした。なかでも伝票発行機能は既存の基幹システムに残す必要がありました。帳票のレイアウト、監査対応、周辺システムとの連携、いずれも現行システムに強く依存しており、短期間での切り替えは現実的ではありませんでした。
この制約を”障壁”として捉えるのではなく、「伝票発行は残す、その代わりにコアの参照・登録・進捗管理を別レイヤーへ逃がす」という方針を立てたことが、今回の提案の出発点になりました。これらの声が示すのは、問題が特定の部門や担当者にあるのではなく、業務フロー全体に構造的な課題が積み重なっているという事実です。第一段階として取り組むべきは、全部を置き換えることではありません。止められない機能を残したまま、データの入口と業務の流れを整え直すことが、改善への現実的な第一歩です。
コア機能をkintoneへ ＋ AI-OCRで入力を減らす
ここでは、私たちが提案した改善アプローチの全体像を解説します。技術ありきの提案ではなく、「何を残し、何を移し、どうつなぐか」という業務設計の問いから始めたことが、この取り組みを成功に導いた要因のひとつです。
アプローチの骨子：段階移行とアジャイル運用
最初に合意した基本方針は段階移行（フェーズ分割）です。いきなり全面刷新するのではなく、「壊しやすい所から着手する」という考え方を採用しました。具体的には、現場が毎日触れるコア業務を先にkintoneへ移行し、既存基幹はそのまま並走させる構成です。
開発・改善の進め方にはアジャイル運用を採用しました。数ヶ月かけて要件を固めてから開発するウォーターフォール型ではなく、短いスプリント（開発サイクル）を繰り返しながら現場で検証し、フィードバックをすぐに反映させる進め方です。担当者が実際に画面を操作しながら意見を出せる環境を整えることで、使える形に要件を固めていきました。
また、AI-OCRの導入における成功条件は精度よりも運用設計だという認識を、早い段階で現場と共有しました。全件の自動処理を目指すのではなく、例外が発生したときに人が確認できる仕組みを先に整えることを大切にしました。
何を移し、何を残すか
kintoneへ移行するのは、顧客情報・案件の進捗・請求ステータスの登録と参照など、現場が毎日触れるコア機能です。これらはレガシー基幹での操作性が低く、かつ他部門との情報共有ニーズが高い領域でした。
既存基幹に残すのは伝票発行です。帳票レイアウトの都合、監査対応の要件、既存の会計システムとの連携など、現行基幹に依存する理由が複数あり、短期での切り替えは現実的ではないと判断しました。
この「移す/残す」の切り分けをチーム全体で丁寧に確認したことが、プロジェクトを通じて方針がぶれなかった理由のひとつです。担当者のひとりは「全部変える話じゃないと分かった瞬間に、前に進めた気がしました」と振り返っています。API連携によって二重入力が発生しないよう、同期のルールと更新のタイミングをあらかじめ取り決めました。
連携の全体像
データの流れを整理すると、以下のようになります。
まず、入力の入口として紙やPDFをシステムに取り込み、AI-OCRが文字を自動認識してkintoneへ登録します。次に、kintone上で顧客・案件・請求のステータス管理が行われます。伝票発行や会計連携など、既存基幹が担う”止められない処理”は現行のまま継続します。kintoneと既存基幹の間はAPIで接続し、双方のデータが整合するよう同期します。さらに、誰がいつ何を修正したか、差戻しの理由、例外発生の記録をログとして残すことで、監査対応や業務改善にも活用できる設計としました。
AI-OCRの設計ポイント
AI-OCRを機能させるうえで特に重視した設計ポイントは3点です。
- 名寄せの設計：取引先名や担当者名の表記ゆれへの対処です。「株式会社〇〇」と「㈱〇〇」のように、同じ会社でも表記が異なる場合に候補を提示し、担当者が確定した情報を辞書として蓄積することで、精度を継続的に高められる仕組みにしました。
- 例外設計：すべての帳票を自動登録するのではなく、不自然な値・必須項目の欠落・取引先情報の不一致などが検出された場合は「要確認」として人の目を通す設計にしました。自動化と人によるチェックの境界線を明確にすることで、ミスが素通りするリスクを下げました。
- 入力動線の短縮：kintoneの画面上で「修正が必要な箇所だけ」を確認・修正して完了できる操作フローにしました。全件を最初から確認する必要がなくなり、担当者の作業量を大幅に圧縮しました。
この設計の肝について、現場からは「例外だけ見ればいいという話が腹落ちしてからは、運用がスムーズに回り始めました」という言葉が聞かれました。「全件確認が当たり前」だった運用から切り替えたことで、担当者が自分の判断で作業に集中できるようになりました。
LLMの位置づけ：OCR後段でのチェック
LLM（大規模言語モデル）は、AI-OCRの後段に組み込みました。目的は誤入力の削減です。文字の読み取りエラーだけでなく、形式チェックでは拾えない”文脈の違和感”を検知します。たとえば金額の桁の違和感、支払条件の矛盾、品目と税区分の不整合、摘要欄の記載不足といった、注意深く読まないと気づきにくいエラーを候補として提示します。LLMの役割はあくまでも注意喚起と修正候補の提示にとどめ、最終判断は人が行うことを運用上のルールとしました。
プロジェクト開始前のすり合わせ
このプロジェクトで特に時間をかけたのが、着手前の認識合わせです。以下の4点について、関係者間で丁寧に確認しました。
- 何をコアと呼ぶか：移す機能と残す機能の境界線を、関係者全員が納得できる形で定義しました。
- API同期のルール：どちらのシステムのデータを正とするか、更新のタイミング、データが衝突した場合の扱い方をあらかじめ決めました。
- 例外の定義：誰が、いつ、どこで確認するかを明文化しました。
- KPIの定義：何が減れば成功と言えるかを数値で確認しました。
技術の導入よりも、現場が納得できる運用設計を丁寧に作ることが、プロジェクトを前進させる原動力でした。
導入後の改善効果：「止まっていた業務」が流れ出す
第3章では、D社の支援において設定したKPI（重要業績評価指標）と、その達成状況を紹介します。「感覚的に楽になった」ではなく、数値で効果を示すことが、次の投資判断の根拠になりました。以下の数値はモデル試算による概数です。
KPIでみる導入効果
効果の試算にあたっては、以下の前提条件を設定しています。対象となる帳票は月あたり約5,000件、AI-OCR導入前の平均作業時間は1件あたり4.0分、人件費の換算単価は時間あたり3,500円です。
KPI①：入力・確認工数の削減
目標値として設定したのは工数70%削減でした。結果は78%削減となり、目標を上回りました。月あたりの削減時間に換算すると約333時間です。金額換算では333時間×3,500円＝約116万円/月、年換算では約1,400万円/年の効果となりました。
この数字は、入力作業の削減だけによるものではありません。差戻し対応の説明、部門間の確認メール、突合作業といった付随するコミュニケーションコストの削減が積み重なった結果です。担当者も「入力が減ったこと以上に、確認の連鎖が切れたのが一番大きかった」と話しており、数字には表れにくい部分ですが、業務の滞りが解消されたことを実感していました。
KPI②：自動処理率（直通率）
目標としていた自動処理率（人の手を介さずにシステムが自動で登録を完了できる割合）は75%でしたが、結果は80%となりました。残り20%は、確認が必要な案件だけに絞り込まれています。全件確認していた以前と比べ、担当者が集中すべき箇所が明確になりました。
KPI③：誤入力率の改善
導入前の誤入力率は1.6%でした。目標は0.5%以下への改善でしたが、結果は0.4%と目標を上回りました。OCR後段に組み込んだLLMによるチェックが、形式的なエラー以外の“違和感系”の誤入力を約30%追加で抑制した効果が大きく寄与しています。金額の桁違い、支払条件の矛盾、品目と税区分の不整合といったケースが、自動的にフラグを立てられるようになりました。
KPI④：処理リードタイムの短縮
帳票の受領から登録・承認完了までのリードタイム（所要日数）は、目標として半減を設定していました。結果は平均して6日から2日への改善となりました。登録待ちのキューが解消されたこと、差戻しのループが減ったこと、承認者が必要な情報に素早くアクセスできるようになったことが複合的に作用した結果です。「数字で効果が見えたから、次の投資判断ができました。感覚じゃなくて根拠で動けるのが違います」という声が上がったのも、このリードタイムの改善が可視化されたタイミングでした。
KPI⑤：部門間問い合わせの削減
請求状況や案件進捗を確認するための部門間問い合わせ件数は、目標の40%削減を超えて50%削減を達成しました。kintone上でリアルタイムに情報を参照できるようになったため、「折り返し確認します」という対応が大幅に減りました。数値には表れにくい変化としては、担当者の心理的な負荷の低下が現場から報告されています。
伝票発行を残した意味
ここまでで繰り返し触れてきた「伝票発行は既存基幹に残す」という判断が、ここで意味を持ちます。既存基幹を止めずに改善を先行できたからこそ、現場への影響を最小限に抑えながらKPIを達成できました。帳票の発行・会計連携などの「止められない処理」は現行のまま維持しつつ、その周辺に滞留していた手入力と煩雑な確認作業を先に改善できました。
導入後の変化
数値には表れにくいものの、現場が強く実感した変化は以下の通りです。
- 差戻しループの消滅：修正→再入力→再チェックの連鎖が断ち切られ、担当者のストレスが大きく減少しました。
- 説明責任への対応の安定化：ログが自動で残るようになったため、監査対応や問い合わせへの返答が記録の参照だけで完結するようになりました。
- 業務知識の可視化：属人化していた例外処理のルールが辞書や設定として記録され、チーム全体で共有できる資産になりました。
完全なクラウド移行へ向けて
今回の取り組みはあくまでも第一段階です。KPIで効果が可視化されたことで、次のフェーズへの投資を判断しやすい環境が整いました。D社では現在、以下のステップを検討しています。
- クラウドへの完全移行：既存基幹の機能を段階的にクラウドサービスへ置き換え、伝票発行も含めた全面移行を目指します。
- 周辺システムの拡充：ワークフロー管理、データ分析基盤、顧客対応の高度化など、kintoneを中心としたエコシステムを広げていきます。
- AIの適用拡大：今回は受発注・請求関連の帳票に限定しましたが、契約書・申込書・点検票など他の帳票類へのAI-OCRの横展開を計画しています。
AI-OCR+kintone導入の勘所
今回のD社の取り組みが示すのは、AI-OCR×kintoneは”入力削減”の手段ではなく、レガシー基幹を止めずに業務データの流れを作り直すための第一段階だということです。D社の事例が示したのは、技術の高度さよりも「移す・残す・つなぐ」の設計を丁寧に行うことが、改善を現実のものにするうえで重要だという点です。
成功要因は3点です。まずスモールスタート——移す機能と残す機能を割り切り、既存基幹を止めない設計を選んだことで、現場への影響を最小化しながら改善を前進させました。次に事前すり合わせ——同期ルール・例外の定義・KPIをプロジェクト開始前に確認したことで、開発中の手戻りと運用開始後の混乱を防ぎました。そして運用で育てる——例外設計とログの仕組みが改善サイクルを生み出し、精度と定着率を継続的に高めました。
同様の改善に着手する際は、まず「コア機能の棚卸し」から始めることをお勧めします。移せる機能と残すべき機能を見極め、例外条件を定義し、KPIを関係者で確認してから動き出す。この順序を踏むことが、プロジェクトを現実的に前進させる起点になります。
この記事を書いた人
