すでに使っている受注管理や在庫管理の仕組みがあり、業務はそれで回っている。 一方で、生成AIを試してみたら手作業の一部は任せられそうだと分かった。 ここで多くの会社が同じ場所で止まります。「今のシステムはそのままに、AIだけ足せないか」という問いに、 社内で答えを出しづらいためです。作り直すほどの話にはしたくないが、 どこをどう触ればいいのかは分からない、という状態です。
この判断がしづらいのは、AIの性能を評価する問題ではなく、既存システムのどこに接点を作るかという設計の問題だからです。 同じ「AIを後付けする」でも、システムの外側で完結させる形と、画面の中に組み込む形とでは、 必要な作業も、失敗したときの影響も、社内で決めておくことも変わります。この記事では、 受託開発とAI活用を手がけるCoconutWorksが、既存の業務システムにAIを後付けする際の入り方の違いと、 どこから手を付けるかの考え方を、費用の数字を出さずに整理します。
結論: 既存システムへの手入れの度合いで4つに分かれる
| 入り方 | 何をするか | 既存システムへの手入れ | 向いている状況 |
|---|---|---|---|
| ① 外側で使う | 既存システムから出力したデータをAI側で処理し、結果は別ファイルや別画面で受け取る | ほぼ不要（出力機能を使うだけ） | 効果があるかをまず確かめたい段階 |
| ② 読み取り連携 | データベースやAPIから参照してAIが処理し、結果を通知やレポートとして届ける | 参照用の権限や接続経路の準備 | 毎回の手作業での出力をなくしたい場合 |
| ③ 書き戻し連携 | AIが出した結果を既存システムに登録・更新して、後工程をそのまま流す | 登録経路の用意と、誤った内容を防ぐ確認の設計 | 入力作業そのものを減らしたい場合 |
| ④ 画面に組み込む | 既存システムの画面上でAIの機能を呼び出せるようにする | 本体の改修が必要 | 使う人が日常的に触る場所に置きたい場合 |
並び順には意味があります。①から④へ進むほど効果が業務に直結しやすくなる一方で、 既存システムに触れる範囲が広がり、事前に確かめておくことも増えます。 検討の入口としておすすめしたいのは、最初から④を目指さず、①か②で効果の有無を確かめてから先に進むやり方です。 以下、それぞれを掘り下げます。
なぜ「既存システムにAI」は話が進まなくなるのか
止まる理由の一つは、社内の会話がいきなりシステム改修の話になってしまうことです。 「AIを入れたい」と相談すると、情報システム担当や取引のある開発会社から、 改修の可否・影響範囲・時期といった話が返ってきます。それ自体は正しい反応ですが、 まだ何に効くか分かっていない段階でこの話に入ると、判断材料がないまま重い検討を始めることになり、 結論が出ないまま時間だけが過ぎます。
もう一つは、AIに任せたい作業がシステムの中ではなく、システムの前後にあることに気づいていない場合です。 たとえば見積書作成のために、メールで届いた依頼文を読んで内容を整理し、 システムに手入力しているとします。この会社が減らしたいのは入力そのものよりも、 その前段の「読んで整理する」時間かもしれません。だとすれば、既存システムを改修しなくても、 届いた文面を整理して入力用の形に整えるところまでを外側で行えば足ります。 システムに手を入れる話に見えていたものが、実は入れなくてよい話だった、というのは珍しくありません。
逆の見落としもあります。AIの出力を人が見て、結局は手でシステムに打ち込んでいるなら、 入力の手間は残ったままです。効果を出したい場所が入力作業なら、 ③の書き戻しまで視野に入れないと期待した結果にはなりません。どこの時間を減らしたいのかを先に一つ決めると、 必要な入り方が自然に決まります。
4つの入り方をどう選ぶか
①外側で使うは、既存システムから出力したデータをAI側で処理し、 結果を別の形で受け取る方法です。既存システムには触れないため、うまくいかなくても元に戻すだけで済みます。 たとえば月次の集計データを出力して、そこから読み取れる傾向を要約させる、といった使い方が該当します。 ここで得られるのは効果の見立てで、続けるなら②以降で手作業をなくしていく流れになります。
②読み取り連携は、出力の手作業をなくす段階です。 データベースやAPIから必要な情報を参照し、AIの処理結果を通知やレポートとして届けます。 既存システムのデータは読むだけなので、書き換えによる事故は起きません。 小売や卸の会社で、在庫や受注のデータを毎朝参照し、注意が必要な品目を絞り込んで担当者に知らせる、 といった形が分かりやすい例です。この段階から「人が見に行く」から「向こうから届く」へ変わるため、 使われ方が定着しやすくなります。
③書き戻し連携になると、既存システムのデータを変える処理が入ります。 入力作業を減らせる分だけ効果は大きくなりますが、 誤った内容が登録されたときに後工程まで波及するため、確認の設計が要ります。 自動で登録してしまうのか、下書きの状態で作っておいて人が承認するのか。 この判断は業務の性質によって変わり、金額や在庫のように取り返しがつきにくいものほど、 人の確認を挟む設計が向きます。
④画面に組み込むは、既存システムの改修が前提です。 使う人が普段見ている画面の中にAIの機能があるため、 「別の画面を開く」という一手間がなくなり、いちばん使われやすい形になります。 ただし改修できるかどうかは、ソースコードが手元にあるか、 改修を頼める相手がいるか、という前提に左右されます。ここが確保できていない場合は、仕様書のない既存システムをどう引き継ぐかで扱っている現状把握が先になります。
選ぶときに見落とされやすいのが、社内で誰が判断するかという点です。 ①や②は業務側の判断だけでも動き出せますが、③以降は既存システムを管理している側の合意が要ります。 検討を始めるときに業務側とシステム管理側の両方を同じ場に置いておくと、 後から「その改修は聞いていない」と差し戻される展開を避けられます。 情報システムの担当を置いていない会社では、保守を任せている会社がその立場にあたることが多く、 早い段階で一声かけておくだけでも進み方が変わります。
技術的な分かれ目は「データを取り出せるか」
どの入り方を選ぶにしても、実務上の分かれ目はほぼ一点に集約されます。必要なデータを既存システムから取り出せるかどうかです。 システムが何年前に作られたか、どの言語で書かれているかより、 この一点のほうが検討の進みやすさを左右します。取り出す経路の候補と、 確認しておきたい点は次のとおりです。
| データの出入り口 | 確認しておきたいこと |
|---|---|
| CSV・Excelの出力機能 | 必要な項目が含まれているか。手動操作が毎回必要になっていないか |
| 提供されているAPI | 参照だけか、更新もできるか。利用できる範囲と認証の方法 |
| データベースへの直接参照 | 読み取り専用の接続を用意できるか。本番の動作に影響を与えないか |
| 定期的なファイル連携 | 出力の頻度と置き場所。失敗したときに気づける仕組みがあるか |
| 画面操作の自動化 | 他に手段がないときの最後の選択肢。画面が変わると止まりやすい |
社内で確認するときは、まず現場の担当者に「そのシステムからExcelやCSVを出せますか」と聞くのが早道です。 出せるなら、その出力に必要な項目が含まれているかを見ます。項目が足りない場合でも、 出力条件を変えられることがあるため、あきらめる前に確認する価値があります。
つまずきやすいのは、画面操作の自動化に飛びついてしまうことです。 他に取り出す手段がないときの選択肢としては成立しますが、画面の配置が少し変わるだけで動かなくなり、しかも止まったことに気づきにくいという弱さがあります。 まずは正規の出力経路がないかを探し、それでも見つからないときの手段として位置づけるのが安全です。
取り出せるかどうかと並んで決めておきたいのが、いつ・どのくらいの鮮度で取り出すかです。 一日一回まとめて処理すれば足りるのか、担当者が操作した直後に結果が返ってきてほしいのか。 ここを決めずに設計に入ると、必要以上に手間のかかる形になったり、 逆に「使いたいときに前日の情報しかない」という不満が残ったりします。 朝の確認作業を助けたいのであれば夜間にまとめて処理すれば済みますし、 接客中に使いたいのであればその場で参照できる形が要ります。 業務の場面から必要な鮮度を決めると、選ぶ経路も自然に絞られます。
あわせて、渡すデータの中身も見ておきます。取引先名や担当者名、個人情報が含まれる場合は、 どこまで渡すかを決めてから設計に入るほうが手戻りが減ります。 AIに渡すデータの整え方は社内データをAIに使わせる前に整えることでも扱っています。
迷ったときのチェックポイントと、進め方の順序
どこから手を付けるか決めかねているときは、次の点を社内で確認すると入り方の見当がつきます。 いずれも専門知識がなくても確かめられる項目です。
- 減らしたい時間はどこにあるか — 探す・読む・判断する・入力する。どの動作に時間を使っているかで、必要な入り方が①〜④のどこになるかが決まります。
- その作業は月に何回発生するか — 回数が少ない作業を仕組みにしても、作る手間に見合いません。頻度の高い作業から選ぶほうが判断を誤りにくくなります。
- 結果が間違っていたときに気づけるか — 人が目を通す場面が残っているなら書き戻しまで進めやすく、誰も見ずに次工程へ流れるなら確認の設計が先に必要です。
- データを出力できるか — 出力手段が一つでもあれば、既存システムに触れずに始められる可能性があります。
- 既存システムを改修できる状態か — ソースコードの所在と、改修を頼める相手がいるか。ここが不明なら④は当面の選択肢から外れます。
進め方の順序としては、対象業務を一つ決める、手作業で試して結果が使える水準かを確かめる、 取り出せるデータの経路を確認する、①か②の形で仕組みにする、使われ方を見ながら③④へ広げるかを決める、 という流れが無理がありません。とくに二番目の手作業で試す工程は省かないことをおすすめします。 実際の帳票やデータを何件か手で投入するだけで、使える水準かどうかはかなり分かります。 ここで見切りをつけられれば、作ってから気づく場合に比べて失うものが小さく済みます。 業務への組み込み方そのものはChatGPT止まりを卒業するで詳しく扱っています。
よくある誤解と、起きやすい失敗
この場面で繰り返されやすい誤解も挙げておきます。いずれも、 検討の入口で前提がずれることで起きるものです。
- 「既存システムにAIを入れるには作り直しが必要」 — 必ずしもそうとは限りません。データを取り出せるなら、外側で処理する形から始められます。作り直しの検討は、後付けでは届かない範囲が明確になってからでも遅くありません。
- 「システム全体をAIに読ませれば良い提案が返ってくる」 — 対象を絞らずに渡しても、業務で使える出力にはなりにくいものです。どの判断を助けてほしいのかを決め、その判断に必要なデータに絞って渡すほうが、結果は安定します。
- 「一度作れば手離れする」 — 業務のルールが変われば、渡すデータや期待する出力も変わります。誰が結果を見て、おかしいときに誰へ相談するかを決めておかないと、静かに使われなくなります。
- 「効果が出そうな一番大きい業務から手を付けたい」 — 影響範囲が広い業務は関係者も多く、確認と調整に時間がかかります。小さくても回数の多い業務のほうが、効果を確かめる題材としては扱いやすくなります。
よくある質問
まとめ
既存の業務システムにAIを後付けする話は、システムを作り直すかどうかの判断ではなく、どこに接点を作るかの判断です。 外側で使う、読み取って届ける、書き戻す、画面に組み込む。 この4つは効果の大きさと触れる範囲がそのまま比例していて、 最初から一番奥を目指す必要はありません。減らしたい時間を一つ決め、 データを取り出せる経路を確かめ、手作業で結果を試してから仕組みにする。 この順序であれば、途中で違うと分かっても引き返せます。
使っているシステムに手を入れられるか分からない、どこから試せばいいか決めかねている—— そうした段階からのご相談も承っています。現在お使いの仕組みと減らしたい作業をお伺いしたうえで、 どの入り方が現実的かの整理からお手伝いします。相談・お見積もりは無料です。
