業務システムのAI内製化｜Excel運用をどこまで置き換え、既存システムとどうつなぐか

Excelとメールで回してきたものが、実質の基幹業務になっている

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

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

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

この記事が扱うのは、これから何かを始める場合ではなく、既に動いているものを作り替える場合です。社内には既存の業務システムがあり、その周りをExcelの管理表とメールが埋めている。この状態から、どこまでをAIを使った仕組みへ置き換え、どこを既存のまま残すか。その線引きと、残すと決めたシステムとのつなぎ方、置き換えた後に情報システム部門が何を持つことになるかを順に整理します。対象の業務をどう選ぶかは 生成AIの内製化は最初にどの業務から始めるか に譲り、ここでは対象が決まった後の話に絞ります。

いま動いている仕組みを4つに分ける

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

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

人が転記でつないでいる部分が、作り替えの主対象になります。届いたものを読んで、内容を確かめて、別のところへ入れる。この流れは件数に比例して時間がかかり、担当者が増えると表記のゆれも増えます。

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

パッケージやSaaSで置き換わっている部分は対象外です。会計や勤怠のように業務の型が決まっている領域を自作しても、法改正のたびに自分たちで直すことになります。ここで確認するのは、外からデータを入れる口があるか、出す口があるか、その形式は何かの3点だけです。

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

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

対象を決めたら、業務を工程で切ります。切り方は3つで足ります。

• 入口 … 届いたものを読む、必要な項目を取り出す、フォームや画面から入力を受け取る
• 判断 … 分類する、既存のデータと突き合わせる、条件に合うかを判定する
• 出口 … 既存のシステムへ反映する、管理表を更新する、帳票や連絡文を作る

このうちAIに任せるのは、入口と、判断の手前までです。判断の結果を確定させるのは人か、書き下したルールが行います。

入口は、作り替えの効果が出やすく、間違えても取り返しがつく工程です。読み取った値が違っていても、確定の前に直せます。件数が多く、届く形が揃っていない業務ほど効きます。

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

出口は、既存のシステムへの書き込みや帳票の出力です。ここは自動化してよい工程ですが、確定したものだけを流します。反映できなかったものを黙って捨てないよう、戻す先を作っておきます。

この線引きを最初に文章で書いておくと、後で範囲が動いたときに気づけます。どの項目をAIが決めてよいか、どこから人が確定させるかを含めた書き方は AIエージェントの要件定義はどう書くか で扱っています。

残すと決めたシステムと、どうつなぐか

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

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

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

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

ファイルでの受け渡しは、多くの既存システムで用意されている手段です。即時に反映されない代わりに、渡した内容がファイルとして残るため、後から差を追えます。日次や週次でまとまって処理する業務なら、これで足りることが多くあります。

データベースを直接参照する形は、読み取りには使えますが、書き込みには向きません。業務システムは画面からの入力に対して、関連する値の更新や整合の確認を裏で行っています。そこを飛ばして書くと、画面上では説明のつかない状態が残ります。

画面を操作する形は、他に手段が無いときの選択肢です。動かすこと自体はできますが、画面の配置が変わると止まります。使う場合は、止まったときに人が同じ操作で代替できることを確認したうえで、代替手段が用意できるまでのつなぎとして扱います。

どの手段を選んだかは、置き換える範囲を決めるのと同じ場所に書き残します。後から範囲を広げるとき、つなぎ方が理由で広げられない工程が出てくるためです。

つなぎ方を選ぶ前に、既存システム側で確認する4点

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

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

試せる環境が無い場合は、書き込みを伴うつなぎ方から始めないほうが安全です。参照だけで動く工程を先に作り、書き込みは人が既存システムの画面で行う形にしておけば、環境が用意できてから寄せられます。

反映の記録は、後から効いてくる項目です。内製した仕組みが担当者個人のIDで書き込むと、記録上はその人がすべて入力したことになります。仕組み専用のIDを用意できるかを先に確認し、できない場合は、いつ何を書いたかを内製側で残す形にします。

保守の契約は、既存システムを提供元に見てもらっている場合に確認します。外部から接続したことが原因だと判断されると、障害の切り分けが止まります。認められる手段が限られているなら、その範囲でつなぎ方を選びます。

渡す件数の上限は、平常月ではなく、いちばん多い月で見ます。月末や期末に件数が集まる業務では、平常月で足りていた渡し方が詰まります。

内製で持つか、既製品で足りるか

作り替えると決めた範囲について、次に自分たちで作るか、既にあるものを買うかを判断します。判断の軸は2つで足ります。

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

自社固有の業務ルールが多く、書式や取引先が頻繁に変わる業務は、既製品に合わせ込む作業が続きます。逆に、決まった形が業界で共有されている業務は、買ったほうが早く、維持も安くつきます。

判断で迷いやすいのは、既製品でおおむね足りるが一部が合わない場合です。この場合は全体を作り直さず、合わない工程だけを自作して既製品につなぐ形を先に検討します。費用や運用まで含めた比べ方と、切り替えるときの条件の決め方は AIエージェントは自作か既製ツールか で扱っています。

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

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

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

3つを1人が兼ねる形でも始められますが、兼ねていること自体は書き出しておきます。書かずに始めると、その人が休んだ日に誰も動けないことが、止まってから分かります。工程ごとの担当の置き方や、異動が起きたときの引き継ぎは AIエージェントを社内で内製する で詳しく扱っています。

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

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

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

既存システムの提供元との切り分けを先に決める

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

決めておく分担は3つです。渡すところまでの不具合は情報システム部門が見る、受け取った後の処理は提供元へ問い合わせる、どちらとも言えないものは記録を添えて提供元と一緒に見る。この3つ目を置かないと、切り分けが終わるまで誰も動かない時間ができます。

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

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

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

残すものを3つに絞ると、続けられます。

業務の手順と判断の条件。 何を受け取り、どういう条件でどう分類し、どこへ書くかを、業務の言葉で書きます。画面や機能の一覧ではなく、判断の条件を残すのが要点です。作った本人以外が読んで、同じ判断ができるかを基準にします。

確認した結果。 どの入力に対してどの出力になるはずかを、実際の業務データから作った一組の例として残します。直した後に同じ例を通し、結果が変わっていないことを確かめられる形にしておきます。これが無いと、条件を1つ足すたびに全体を目視で確認することになります。

判断を人が直した記録。 出力に対して人が修正した内容を残しておくと、条件の書き足しに使えます。同じ直しが繰り返されているなら、それは仕様の抜けです。

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

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

どの業務から着手するかの選び方は 生成AIの内製化は最初にどの業務から始めるか で扱っているため、ここでは対象が決まった後の進め方だけを書きます。

最初の1本では、既存のExcel運用を止めずに並行して動かします。同じ入力を両方に通し、結果が一致するかを業務データで確かめてから切り替えます。並行の期間中に出た差は、仕様の抜けとして書き足す材料になります。

まとめ：社内の業務システムをAIで作り替えるときの要点

• いま動いている仕組みを、人が転記でつないでいる部分、Excelの関数やマクロで持っている部分、パッケージやSaaSで置き換わっている部分、どこにも書かれていない部分に分ける
• 作り替えの主対象は転記でつないでいる部分。パッケージで型が決まっている領域は作らず、連携の口だけ確認する
• 業務を入口・判断・出口に切り、AIに任せるのは入口と判断の候補出しまでにする。確定は人かルールが持つ
• 残すと決めたシステムとのつなぎ方は、連携の口・ファイル・データベースの参照・画面の操作の順に当てる。書き込みは提供されている口かファイルで行い、データベースへ直接書かない
• つなぎ方を選ぶ前に、試せる環境があるか、反映が誰の操作として記録に残るか、保守の契約で接続が認められているか、何件まとめて渡してよいかを確認する
• 内製か既製品かは、自社固有のルールが多いか、書式や取引先が頻繁に変わるかで分かれる。一部だけ合わない場合は、その工程だけ自作してつなぐ
• 体制は作る人・直す人・止まったときに見る人の3つを分けて置く。業務部門に開放するのは、判定に使う一覧表の中身のような、業務の結果を変えない範囲にとどめる
• 既存システムの提供元との切り分けは先に決める。渡した内容と受け取った結果を内製側で記録し、どちらとも言えないものを一緒に見る枠を置く
• 判断の条件、確認に使う入出力の例、人が直した記録の3つを、1か所に決めて作りながら残す
• 最初の1本は既存の運用と並行して動かし、結果が一致することを業務データで確かめてから切り替える

Augueでは、社内に散らばった業務の棚卸しから、AIを使った仕組みの設計・実装と、社内で直し続けられる体制づくりまでを支援しています。Excel運用のどこから作り替えられるかを整理したい方は、是非ご相談ください。

関連する記事

内製化全体の考え方と進める順序は 生成AI・AIエージェントの内製化の進め方、最初に手を付ける業務の選び方は 生成AIの内製化は最初にどの業務から始めるか を参照してください。

体制とスキルの分担、保守の持ち方は AIエージェントを社内で内製する、既製ツールとの比べ方は AIエージェントは自作か既製ツールか、仕様の書き方は AIエージェントの要件定義はどう書くか で扱っています。

よくある質問

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

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

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

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

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

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

作り替えた後、元のExcelはいつ止めればよいですか？

新しい仕組みの結果と元のExcelの結果が同じになることを、実際の業務データで一定期間くらべてから止めます。並行して動かす期間を決めずに切り替えると、差が出たときに戻れません。並行期間中に差が出た件は理由を記録し、仕様の抜けだったのか入力側の問題だったのかを分けます。止めるときは、過去分の閲覧をどこで残すかも同時に決めます。

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

誰が使えるかより先に、その仕組みが何のデータへ触れるかを決めます。参照だけでよいものに書き込みの権限を渡さない、対象の範囲を絞れるなら絞る、という形です。既存の社内システムへ書き込む場合は、その反映が誰の操作として記録に残るかを確認しておきます。担当者個人のIDで動かすと、異動したときに止まり、記録も追えなくなります。