業務システムの内製化｜AIに置き換える業務と残すシステムの線引き

業務システムの内製化で、AIに置き換えるのは「人が読んで別の表へ転記している業務」です。会計や勤怠のようにパッケージやSaaSで動いている業務は残し、Excelの関数やマクロで動いているものも止めずに、作った人しか直せない部分だけを切り出します。判断の条件が担当者の頭の中にしか無い業務は、置き換える前に条件を書き出します。この4つに分けたうえで、置き換える業務を入口・判断・出口の工程に切り、AIに任せるのは入口の読み取りと判断の候補出しまでにします。

この記事の答え

AIに置き換えるのは転記でつないでいる業務。パッケージで動く業務とExcelの関数・マクロは残す

AIに任せるのは読み取りと候補出しまで。確定は人かルールが持ち、確定した分だけ既存システムへ反映する

最初の1本は既存のExcel運用と並行して動かし、結果が一致することを業務データで確かめてから切り替える

Excelとメールの業務が、業務システムの代わりになっている

社内の仕組みは、システムとして作られたものだけではありません。誰かが作った管理表に各部門が追記し、更新をメールで知らせ、月末に別のファイルへ転記する。この形が長く続くと、正式なシステムではないのに業務がそこで止まるようになります。

作り替えを検討し始めるきっかけは、たいてい次のどれかです。作った人しか直せない、同じ内容のファイルが複数の場所にあってどれが最新か分からない、件数が増えて転記が終わらない、扱う情報の管理を問われて説明できない。

こうした状態に対して「業務システムを入れる」と考えると、パッケージの選定から始まって話が大きくなります。一方で、いま人が転記や突き合わせで埋めている部分は、システムの機能というより判断と作業の積み重ねです。この部分はAIを使えば自社で組める範囲が広がっており、全部を一度に置き換えなくても手を付けられます。

この記事が扱うのは、既に動いているものを作り替える場合です。社内には既存の業務システムがあり、その周りをExcelの管理表とメールが埋めている。この状態から、どこまでをAIを使った仕組みへ置き換え、どこを既存のまま残すかを決め、残すシステムとのつなぎ方、AIへ渡すデータの範囲、置き換えた後の情報システム部門の役割を順に決めていきます。どの業務を最初に選ぶかがまだ決まっていない場合は、候補を絞るところから始めます。

業務システムの内製化は、いまの仕組みを4つに分けてから

作り替える範囲を決める前に、いま何がどこで動いているかを分けます。分けずに「Excel運用をやめる」と決めると、やめられない部分まで対象に入って止まります。

置き換える業務と残す業務の4分類

いまの持ち方	何が起きているか	AIでの作り替えとの関係
人が転記でつないでいる	メールや書類の内容を、人が読んで別の表へ入れ直している	最初に置き換える対象。読み取りと候補出しを機械に寄せられる
Excelの関数・マクロ	集計や条件分岐が式やマクロに入っている	動いているなら残す。作った人しか直せない部分だけを切り出す
パッケージ・SaaS	会計や勤怠など、業務の型が決まっている領域	作り替えない。データの入口と出口だけを確かめる
どこにも無い	担当者の頭の中にだけ判断基準がある	作り替える前に、判断の条件を書き出す作業が要る

1つの業務の中に、4つが混ざっていることもよくあります。その場合は業務単位ではなく工程単位で分け、下の順番で問いに答えていくと扱いが決まります。

人が転記でつないでいる部分が、最初に置き換える対象です。

転記でつないでいる部分は、件数に比例して時間がかかり、担当者が増えると表記のゆれも増えます。置き換えの効果が最も見えやすく、間違えても確定の前に人が直せるため、転記でつないでいる部分が最初の対象に向いています。

マクロと、書かれていない判断の扱い方

Excelの関数やマクロで動いている部分は、扱いを間違えやすい箇所です。問題になるのは、式が長くなって誰も検証できない、マクロを作った人がすでにいない、という状態のときだけです。この場合も全体を作り替えるのではなく、その計算が何を決めているのかを取り出し、判断の条件として書き直します。

パッケージやSaaSの領域を自作すると、法改正のたびに自分たちで直すことになります。ここで確かめるのは、外からデータを入れる口があるか、出す口があるか、その形式は何かの3点です。

判断の条件がどこにも書かれていない業務は、作り始めてから見つかります。「この取引先はこの条件のときだけ扱いが違う」といった判断が、書かれた場所を持たずに続いてきたものです。ここを書き出す作業を飛ばすと、作った後に例外が次々に出てきます。

入口・判断・出口に分けて、AIに任せる範囲を決める

置き換える業務が決まったら、工程で切ります。切り方は次の3つで足ります。

工程	やること	担う人・仕組み
入口	届いたものを読む、必要な項目を取り出す、フォームや画面から入力を受け取る	AI
判断	分類する、既存のデータと突き合わせる、条件に合うかを判定する	候補出しはAI、確定は人かルール
出口	既存のシステムへ反映する、管理表を更新する、帳票や連絡文を作る	既存システムと、確定した結果を渡す処理

AIに任せるのは入口と判断の候補出しまでで、判断の結果を確定させるのは人か、書き下したルールです。

AIに任せるのは、入口の読み取りと判断の候補出しまでです。
反映できなかったものは判断へ戻します。

入口の読み取りから始める

入口は、件数が多く、届く形が揃っていない業務ほど効果が出ます。読み取った値が違っていても確定の前に直せるため、最初に機械へ寄せても業務の結果を壊しません。読み取りの精度は項目ごとに一致率を測り、合格ラインを決めてから範囲を広げます。

判断は候補と根拠まで、出口は確定した分だけ

判断の工程では、AIに結論を出させず、候補と根拠を出させます。「この取引先の登録はこれだと思われる。名称と住所が一致するため」まで出させて、選ぶのは人かルールです。同じ条件で毎回同じ結果になるものは、AIではなくルールとして書き下したほうが、後から検証できます。

出口は、既存のシステムへの書き込みや帳票の出力です。自動化してよい工程ですが、確定したものだけを流し、反映できなかったものを黙って捨てずに判断へ戻す先を作っておきます。どの項目をAIが決めてよいか、どこから人が確定させるかは、最初に文章で書いておくと、後で範囲が動いたときに気づけます。

残す業務システムとAIのつなぎ方

置き換えないと決めた部分は、そのまま動かし続けます。ここで決めるのが、作り替えた側との間でデータをどう渡すかです。つなぎ方を決めずに作り始めると、出口の工程だけが最後まで人の手作業で残ります。

4つのつなぎ方を上から順に当てる

手段は4つあります。上から順に当てて、使えるものが見つかった時点で下は見なくて構いません。

順番	つなぎ方	使える条件	気をつける点
1	提供されている連携の口を使う	提供元が外部からの読み書きを想定している	読める項目と書ける項目が同じとは限らない
2	ファイルで受け渡す	取り込み用・出力用の形式が決まっている	取り込みの時刻が決まっており、その場では反映されない
3	データベースを直接参照する	社内に置かれていて、参照の権限を出せる	参照だけにとどめる。書き込むとシステム側の整合の処理を飛ばす
4	画面を操作する	上の3つがどれも使えない	画面の変更で止まる。当面のつなぎとして使う

連携の口がある場合でも、参照はできても更新は対象外、更新はできても特定の項目だけ、という作りは珍しくありません。書きたい項目が対象に入っているかを作り始める前に確かめないと、出口の設計をやり直すことになります。

ファイルでの受け渡しは即時には反映されませんが、渡した内容がファイルとして残るため、後から差を追えます。日次や週次でまとめて処理する業務なら、これで足りることが多くあります。データベースへ直接書き込まないのは、業務システムが画面からの入力に対して、関連する値の更新や整合の確認を裏で行っているためです。画面を操作する形を使う場合は、止まったときに人が同じ操作で代わりを務められることを確かめておきます。

既存の業務システム側で確かめる4点

つなぎ方とは別に、既存システムの側にも確認が要ります。次の4点は、作り始めてから分かると設計のやり直しになる項目です。

確かめること	分からないまま進めると	確認先
試せる環境があるか	本番のデータで書き込みを試すことになる	既存システムの管理担当、または提供元
反映が誰の操作として記録に残るか	誰が入れた値か、後から追えない	既存システムの操作記録の仕様
保守の契約で外部からの接続が認められているか	障害時に契約の範囲外と判断されうる	保守契約の書面、提供元の窓口
何件まとめて渡してよいか	件数が増えた月に処理が詰まる、または止められる	提供元の制限、社内の運用担当

試せる環境が無い場合は、参照だけで動く工程を先に作り、書き込みは人が既存システムの画面で行う形にしておけば、環境が用意できてから寄せられます。反映の記録は、内製した仕組みが担当者個人のIDで書き込むと、記録上はその人がすべて入力したことになります。仕組み専用のIDを用意できない場合は、いつ何を書いたかを内製側で残します。渡す件数の上限は、平常月ではなく、月末や期末など件数がいちばん多い月で見ます。

社内のデータを、どこまでAIへ渡すか

業務システムを内製すると、扱うデータの範囲を自分たちで工程ごとに選べます。裏を返すと、決めないまま作った場合は、届いた文書をそのまま全部AIへ渡す形になり、後から絞ろうとすると入口の作りから直すことになります。

渡す範囲は項目で決める

入口で読み取った内容のうち、判断に要る項目とそうでない項目は違います。区分と金額と日付があれば分類できる処理に、担当者の氏名や口座の番号まで渡す必要はありません。

扱う情報	渡すかどうか	渡す前にすること
判断に要る項目（区分、金額、日付、件名）	渡す前提で設計してよい	入力した内容が学習に使われない設定・契約か、契約の条項と管理画面の両方で確かめる
個人が特定できる項目（氏名、連絡先、口座）	判断に要らないなら渡さない	伏せ字や仮の番号へ置き換え、元の値は内製側で持って出口で戻す
取引先との取り決めで扱いが決まっているもの	取り決めを読んでから決める	範囲が読み取れないものは相手の窓口に確認し、確認できるまで渡さない
社内で公開していない情報（人事、価格の方針）	対象から外す	その業務を作り替えの対象に含めるかを先に決め直す

個人の情報を入口で置き換えて出口で戻す処理を内製側に持てるのは、既製品と比べたときの違いが出やすいところです。社内で公開していない情報は、扱いを絞りながら作るより、業務ごと対象から外したほうが早いことが多くあります。

ログに残す範囲も同時に決める

読み取りの結果を検証できるようにするため、入力と出力はふつう記録します。ただし原文をそのまま残すと、AIへは渡さないと決めた項目がログには溜まります。何をどこに、どれだけの期間残すかを、渡す範囲を書いた場所と同じところに書きます。全部を社内に閉じる作り方もありますが、その場合は動かす環境を維持する仕事が自分たちに乗ります。入口の読み取りは外部のサービス、社内のデータと突き合わせる判断は社内、と工程で分ける持ち方もできます。

業務システムをAIで内製するか、既製品で足りるか

作り替えると決めた範囲について、自分たちで作るか、既にあるものを買うかを決めます。見る点は次の5つです。

見る点	既製品で足りる	内製で持つほうが合う
業務ルールの出どころ	法令や商習慣で決まっている	自社で決めた条件が多く、例外も自社で判断する
書式や取引先の変化	ほとんど変わらない	追加や変更が定期的に起きる
直したいときの手間	設定を変えれば足りる	条件を1つ足すたびに提供元へ要望を出す必要がある
扱うデータの置き場所	外部サービスに預けてよい	社内に置く必要がある、または持ち出せるかを都度判断する
止まったときの復旧	提供元の対応を待てる	自社で原因を探して直せる状態にしておきたい

一部だけ合わない場合は、その工程だけ作る

迷いやすいのは、既製品でおおむね足りるが一部が合わない場合です。全体を作り直さず、合わない工程だけを自作して既製品につなぐ形を先に検討します。

費用は4つに分けて、同じ形で並べる

開発費と製品の利用料だけを並べると、どちらが安いかは対象の規模で簡単に逆転します。金額の目安は件数と使い方で変わるため一律には置けませんが、何を積み上げたのかを両方で揃えることはできます。

費用のかかり方	内製で持つ場合に入るもの	既製品を使う場合に入るもの
最初に一度かかる	業務の整理、実装、既存システムとのつなぎ込み、並行して動かす期間の人手	導入の作業、自社の業務に合わせる設定、既存システムとのつなぎ込み
毎月かかる	AIの利用料、動かす環境の費用、動いているかを見る手間	利用料、利用する人数が増えたときの追加分
変更のたびにかかる	条件を1つ足すときの作業時間	要望を出してから反映されるまでの待ち時間と、その間の手作業
止まったときにかかる	原因を探して直す時間	提供元の対応を待つ時間と、その間の手作業

下の2行は見積書に出てこないため、比べるときに抜けます。作り替える前の運用で、変更の依頼が年に何件出ていたか、止まったときに業務が何時間止まったかを数えておくと、この2行を推測ではなく自社の実績で埋められます。

情報システム部門の分担をどう置くか

業務システムを内製で持つと決めたとき、体制の話は「作れる人がいるか」に寄りがちです。実際に足りなくなるのは、作った後の役割です。

作った後に要る3つの役割

役割	持つこと	置かないと起きること
作る人	業務の手順を仕様にして、動く形に組む	要望が集まっても着手されない
直す人	条件の追加や表記の変更に対応する	小さな変更のたびに新規開発と同じ手続きになる
止まったときに見る人	止まった原因を探し、業務側へ当面の回避策を伝える	業務が止まったまま、原因が分からずに待つことになる

3つを1人が兼ねる形でも始められますが、兼ねていること自体は書き出しておきます。書かずに始めると、その人が休んだ日に誰も動けないことが、止まってから分かります。

業務部門が自分で直せる範囲

すべての変更を情報システム部門が受けると、待ち行列ができます。全部を開放すると、誰がいつ何を変えたか分からなくなります。線は、変更が業務の結果を変えるかどうかで引きます。

直す人	対象になる変更
業務部門	表示する項目名、通知の文面、判定に使う一覧表（取引先名の別名、区分の対応表など）の中身
情報システム部門	判定の条件そのもの、他システムへ書き込む内容、権限の設定、データの保存先

表記のゆれや区分の追加は業務側でしか判断できず、件数も多いため、一覧表の中身を業務部門が持てると仕組み自体を触らずに直せます。

既存システムの提供元との役割分担

内製した仕組みが既存システムへつながると、止まったときに原因がどちら側にあるか分からない時間が生まれます。内製側は「渡しているはず」、提供元は「受け取っていない」と言い合う状態です。渡した内容と受け取った結果を内製側で記録しておけば、問い合わせるときにその記録を出せます。

決めておく分担は次の3つです。

渡すところまでの不具合は、情報システム部門が見る
受け取った後の処理は、提供元へ問い合わせる
どちらとも言えないものは、記録を添えて提供元と一緒に見る

3つ目の枠を置かないと、原因が分かるまで誰も動かない時間ができます。

既存システムの改修が必要だと分かった場合も、渡す形を変えれば済むなら内製側で回避したほうが早く戻せます。回避できないものだけを改修の依頼に回します。

作った後に仕様が残らない状態を避ける

内製で作った仕組みが数年後に扱いにくくなる理由は、たいてい性能ではなく、何をしているかが誰にも分からなくなることです。Excel運用で起きていたことが、そのまま繰り返されます。残すものは次の3つに絞ります。

業務の手順と判断の条件何を受け取り、どういう条件でどう分類し、どこへ書くかを業務の言葉で書く。作った本人以外が読んで同じ判断ができるかを基準にする
確認に使う入出力の例どの入力に対してどの出力になるはずかを、実際の業務データから作って残す。直した後に同じ例を通し、結果が変わっていないことを確かめる
人が直した記録出力に対して人が修正した内容を残す。同じ直しが繰り返されているなら、それは仕様の抜け

この3つは、作り終えてからまとめようとすると残りません。作りながら書き足していく形にして、置き場所を業務部門と情報システム部門の両方が見られるところに1か所だけ決めます。複数の場所に散ると、Excelのファイルが増えていったときと同じ状態になります。

最初の1本は既存の運用と並行して動かす

最初の1本では既存のExcel運用を止めず、同じ入力を両方に通して、結果が一致することを業務データで確かめてから切り替えます。並行の期間中に出た差は、仕様の抜けだったのか入力側の問題だったのかを分けて記録し、条件を書き足す材料にします。元のExcelを止めるときは、過去分をどこで見られるようにしておくかも同時に決めます。

まとめ：業務システムの内製化でAIに置き換える業務と残すシステム

業務システムの内製化は、いまの仕組みを「転記でつないでいる」「Excelの関数・マクロ」「パッケージ・SaaS」「どこにも無い」の4つに分けてから始める
AIに置き換えるのは転記でつないでいる部分。パッケージの領域は作らず、Excelの関数・マクロは作った人しか直せない部分だけを切り出す
業務を入口・判断・出口に切り、AIに任せるのは入口と判断の候補出しまで。確定は人かルールが持つ
残すシステムとのつなぎ方は、連携の口・ファイル・データベースの参照・画面の操作の順に当て、データベースへ直接書き込まない
つなぐ前に、試せる環境、反映の記録、保守の契約、渡せる件数の4点を既存システム側で確かめる
AIへ渡す範囲は項目で決め、判断に要らない個人の情報は入口で置き換えて出口で戻す。ログに残す範囲も同時に決める
内製か既製品かは自社固有のルールと変更の多さで分かれる。費用は変更のたび・止まったときの分まで4つに分けて並べる
作る人・直す人・止まったときに見る人を分け、判断の条件・入出力の例・人が直した記録を1か所に残す
最初の1本は既存の運用と並行して動かし、結果が一致してから切り替える

Augueでは、Excelとメールに散らばった業務の棚卸しから、AIを使った仕組みの設計・実装、既存システムとのつなぎ込み、社内で直し続けられる体制づくりまでを支援しています。ご興味がある方は是非ご相談ください。

社内でAIを使いこなせる人を育てませんか？

研修だけで終わらせず、現場の業務で使い続けられる体制づくりまで伴走します。研修の内容と進め方は、サービス資料で紹介しています。

資料をダウンロードする無料相談に申し込む

よくある質問

作り替えにはどれくらいの期間がかかりますか？

対象の広さで変わるため一律には言えませんが、期間を先に決めるより、区切り方を決めたほうが進みます。入口の読み取りだけ、あるいは判断の候補出しだけといった単位で切り、1周分の業務量（週次なら1週、月次なら1か月）を通して動かしてから次を足す形です。1周通すと、直しがどの工程に集中するかが分かります。それを見てから範囲を広げると、途中で作り直しになりにくくなります。

RPAやノーコードツールで作った既存の仕組みはどう扱えばよいですか？

置き換える前提にはしません。決まった画面を決まった順に操作する処理は、そのまま動いているなら残したほうが安定します。壊れやすいのは、書式や文面のばらつきを条件分岐で吸収しようとして分岐が増えた部分です。その部分だけをAIによる判断へ寄せ、確定と反映は既存の仕組みに任せると、作り替える範囲が小さく済みます。

業務部門が独自に作った仕組みを情報システム部門が把握していません。まず何をすべきですか？

取り上げるのではなく、一覧に載せるところから始めます。何を扱っているか、誰が使っているか、止まると誰が困るか、個人情報や取引先の情報を含むかを聞き取り、業務の重要度で並べます。止まると業務が止まるものと、機微な情報を扱うものだけを情報システム部門の管理へ移し、それ以外は作った人が持ったままにします。

社内で作った仕組みの権限はどう決めればよいですか？

誰が使えるかより先に、その仕組みが何のデータへ触れるかを決めます。参照だけでよいものに書き込みの権限を渡さない、対象の範囲を絞れるなら絞る、という形です。担当者個人のIDで動かすと、異動したときに止まり、記録も追えなくなるため、仕組み専用のIDを用意できるかを確かめます。

既存の業務システムの入れ替えが1〜2年後に控えています。今から内製で作り替えてよいですか？

入れ替えの予定があるなら、既存システムに深く書き込む作りは避け、入口の読み取りと判断の候補出しまでに絞ります。この2つはどのシステムへ反映するかに左右されにくく、入れ替え後もそのまま使えます。出口のつなぎ込みは、新しいシステムの連携の口が分かってから作ります。入れ替えの要件に「外からデータを入れられるか」を加えておくと、後で困りません。

業務システムを内製するのに、社内にエンジニアは必要ですか？

最初の1本はエンジニアがいなくても作れる範囲がありますが、既存システムへ書き込む工程を含めるなら、つなぎ方と権限を判断できる人が要ります。多くの会社では情報システム部門の担当者がこの役を持ちます。業務の手順を書き出す人と、つなぎ込みを判断する人を分けて置き、実装だけを外部に頼む形でも始められます。

AIが出した候補を人が確定する形で、監査や内部統制の説明はつきますか？

確定したのが誰で、何を根拠にしたかが残っていれば説明はつきます。AIの出力、人が選んだ結果、選んだ人と日時を1件ずつ記録しておくのが前提です。AIの出力をそのまま反映する工程を作ると、誰の判断で入った値かを説明できなくなるため、確定の工程を人かルールに残す設計が、そのまま説明の材料になります。