基幹システムを新しくしたい。でも、受注も出荷も止められない。長年使ってきた販売管理や在庫管理の仕組みを前に、どこから手を付けるべきか迷っている企業はあるでしょう。そこへサイバー攻撃のニュースが重なれば、システムを変える判断はさらに難しくなります。

2026年上半期のランサムウェア被害報告は123件となり、2020年下半期以降、半期として最多を記録しました。警視庁の被害報告

一方で、受注から出荷、請求まで、人が画面を開いて確認し、次の担当者へつなぐ仕事を、この先も続けるのか。人手と時間に限りがあるなか、基幹業務にAIをどう組み込むかは、競争力を維持するうえで避けて通れない課題だと、私たちキジトラは考えています。

目指しているのは、注文を受けたAIが必要な情報を集め、決められた条件のもとで業務を進め、人は例外や重要な判断を担う基幹システムです。その土台として、キジトラが推奨するのがAWSです。基盤の保守を任せながら、自社の業務に合わせて処理と権限を設計できるためです。

この記事では、オンプレミス・SaaS・AWSを基幹業務の観点で比較し、キジトラならどのようにAIを組み込み、既存システムから移していくかを説明します。

基幹システムの刷新で変えたいのは、人がシステムを行き来して進める業務

基幹システムとは、受発注、在庫、販売、生産、会計など、事業の中心となる業務を支えるシステムです。どれだけ新しい画面を用意しても、システムの間を人の手作業でつないでいるなら、その部分の負担は残ります。

たとえば、卸売業の受注を考えてみます。担当者が注文メールを読み、商品名を社内の品番に置き換え、在庫を確認する。得意先ごとの単価や支払い条件を調べ、欠品があれば仕入先に問い合わせる。その後、受注を登録し、倉庫へ出荷を指示し、納品に合わせて請求処理を進めます。

販売管理、倉庫管理、会計のシステムがそれぞれあっても、転記や照合、部門間の確認を人が担っている場合があります。「注文は来ているのに、担当者の確認待ちで進まない」という状態です。キジトラがAIで変えたいのは、この業務の進み方です。

AIが注文内容を読み取り、必要なシステムを呼び出し、次の処理を進められるようにする。そのためには、業務データを読み書きする窓口、処理の順序、承認が必要な条件を整える必要があります。サーバーの移転と合わせて、業務をどの単位で任せられるかまで考えることが、AI時代の基幹システム刷新だと考えています。

オンプレミスでも、侵入と業務停止への備えは必要になる

自社の設備で運用するオンプレミスでも、社内に置いてあるという理由だけで安全とは判断できません。警察庁は、社外から接続するためのVPN機器などを通じて、未修正の脆弱性や漏えいした認証情報を悪用し、ネットワーク内部へ侵入する手口を説明しています。警察庁のランサムウェア対策

基幹システムが直接インターネットに公開されていなくても、保守担当者の接続経路や、連携先のシステムを確認する必要があります。侵入された場合に、どのデータまで触れられるのか。受注や在庫の情報が使えなくなったとき、いつ、どこまで復旧できるのか。設置場所とともに、こうした運用を評価すべきです。

直近では、2026年10月22日にJPCERT/CCが、Webシステムに使われるプログラミング言語「PHP」の重大な脆弱性について注意を呼びかけました。影響を受けるシステムでは、修正の適用や侵害の調査が求められています。JPCERT/CCの注意喚起

こうした問題が起きたとき、自社のどのシステムが影響を受けるかを調べ、更新を検証し、適用する体制が問われます。長年改修を重ねたシステムで、構成が分からない、更新すると何が止まるか分からないという状態なら、対策そのものが難しくなります。なお、AWSへ移すだけでアプリケーションの脆弱性が解消されるわけではありません。使っているソフトウェアの更新は引き続き必要です。

「止められないから触れない」という状態を続ければ、修正も改善も後回しになります。基幹システムの刷新では、業務を続けながら変更を試せる環境と、障害から戻せる手順も一緒に作る必要があります。

SaaS・オンプレミス・AWSは、業務を変えられる範囲と運用責任で選ぶ

完成した業務ソフトをサービスとして使うSaaSは、導入や保守の負担を抑えやすい選択肢です。オンプレミスは、自社設備や接続方法まで管理できます。アマゾンのクラウド基盤であるAWS上に構築する場合は、基盤管理の一部を任せながら、独自のシステムを設計できます。

SaaSがAWS上で提供されることもあり、三つは同じ分類の言葉ではありません。ここでは、基幹業務を「提供済みのサービスに任せるか」「自社設備で運用するか」「自社のAWS環境で組み立てるか」として比較します。

選択肢基幹業務でのメリット導入・運用で確認したいこと
SaaS標準的な業務機能を導入しやすく、提供者に保守を任せられる。用意されたAI機能を使える場合もある自社の取引条件に合うか。外部連携、データの取り出し、権限、障害時の対応、契約変更への対応に制約はないか
オンプレミス工場設備や既存機器との接続、厳しい通信制限などに合わせやすい機器・ソフトウェアの更新、監視、復旧を誰が続けるか。AIを動かす設備や連携機能も自社で維持できるか
自社のAWS環境独自の業務処理とAIを組み合わせ、データや実行権限を設計できる。管理を任せられるサービスを選べる開発・運用体制を確保できるか。設定ミス、過大な権限、AWS側の障害にどう備えるか。利用料に加え開発・保守費用も見積もれているか

販売や会計の業務がSaaSの機能に合うなら、その機能を使うのは合理的です。独自開発を増やせば、維持する仕事も増えます。SaaSの採用時には、必要な機能だけでなく、利用者の認証、操作記録、データの取り出しや削除まで確認します。英国政府のSaaS選定・管理ガイド

一方、得意先ごとの複雑な条件や、複数のシステムをまたぐ業務にAIを組み込みたいなら、自社で設計する範囲が出てきます。既存のSaaSを使い続けながら、業務の進行を担う部分をAWSに構築する方法もあります。

キジトラがAWSを推すのは、管理の自由と保守負担のバランスを取れるから

キジトラがAWSを推すのは、独自の基幹業務を作り込みながら、設備や基盤の保守を任せられるためです。たとえば、データベースを管理するAmazon RDSには、バックアップやソフトウェア更新を支援する仕組みがあります。こうしたマネージドサービス、つまり提供者が管理を担うサービスを活用し、自社は業務ルールやデータの管理に力を割けます。Amazon RDSの管理範囲

この分担には、条件があります。何をAWSに任せられるかはサービスごとに違い、自社で動かすアプリケーションやアクセス権限は利用側が管理します。仮想サーバーのAmazon EC2を使うなら、その中の基本ソフトであるOSの更新も利用側の責任です。AWSの責任共有モデル

キジトラが評価するのは、業務に必要な制御を保ちながら、自社で保守する範囲を減らせることです。AWSがどの企業にとっても最も安全、最も安いという意味ではありません。運用を担う人、障害対応、将来の変更まで含めて、自社が維持できる構成を選びます。

キジトラなら、AWSで受注から請求までをこう設計する

ここからは、卸売業の受注を題材にした設計例です。キジトラの構想を説明するための例であり、特定企業への導入事例ではありません。目標は、通常の注文をAIが進め、条件から外れる案件を理由と選択肢付きで担当者へ引き継げるようにすることです。

注文を受けたAIが、次の処理を進める

取引先から注文が届いたら、AIが商品、数量、希望納期を読み取ります。「いつもの商品を来週火曜に」といった表現も、取引履歴や商品マスターと照合して候補を出します。複数の商品が当てはまる場合には、確認が取れるまで注文を確定させません。

商品と数量が決まれば、在庫、単価、取引条件をシステムに照会します。在庫があり、登録済みの条件に合い、自動処理の対象となる注文なら、在庫を確保し、受注登録から出荷指示まで進めます。出荷の実績が戻ったら、確定した数量をもとに請求処理へつなぎます。

欠品が見つかれば、AIは別倉庫からの出荷、分納、仕入れなどの候補を集めます。担当者に届くのは「在庫がありません」という通知だけではなく、「別倉庫なら希望日に間に合う」「分納なら追加の送料がかかる」といった判断材料です。納期や価格の変更は、権限を持つ担当者が決めます。

この設計では、人が注文ごとに複数の画面を開く仕事を減らし、例外への対応に時間を使える状態を目指します。自動化できる範囲は、注文の種類やデータの品質を確かめながら広げていきます。

AIが選ぶ処理と、取引を確定する仕組みを分ける

基幹システムでは、もっともらしい回答よりも、注文や金額が正しく確定することが重要です。AIには「在庫を調べる」「受注を登録する」といった操作の窓口を用意します。システム同士が決まった方法でやり取りするこの窓口を、APIと呼びます。

たとえば在庫を確保するAPIは、実行時点の在庫を再確認し、同じ在庫を二つの注文に割り当てないように更新します。単価、取引上限、承認の要否も、AIの回答とは別に業務ルールで検証します。AIには、台帳を自由に書き換えたり、承認条件を変更したりする権限を渡しません。注文メールに処理ルールを変える指示が含まれていても、権限や承認を迂回できない設計にします。

AWSで組むなら、役割に合わせて次のような構成を検討します。

担う役割構成の例
注文を読み取り、次に必要な操作を選ぶAmazon BedrockでAIモデルを利用。モデルが提案した操作を、アプリケーション側で検証して実行する
在庫照会、取引条件の検証、受注登録を行うサーバー管理をAWSに任せられるAWS Lambdaなどで業務APIを実装。利用者と処理ごとに、実行できる操作を制限する
承認待ち、処理の失敗、再開を管理するAWS Step Functionsで業務の進行状態を管理。人の判断が必要な場合は処理を止め、承認後に再開する
受注・在庫・請求の確定情報を保存する新たに構築する部分ではAmazon RDSなどを候補にする。既存パッケージは対応する構成と連携仕様を確認する

AIが選んだ操作を業務APIが検証・実行し、承認待ちや失敗があれば、処理を止めて次の対応につなぎます。この役割分担を実装し、業務に合うかを検証することで、AIの判断を実際の取引へつなげます。

途中で通信が切れて同じ処理をやり直しても、注文や請求が二重に作られないよう、取引ごとの識別番号と実行結果を管理します。どの注文をもとに、どの権限で、どの処理を実行したかも記録します。障害時にはAIによる新規処理を止め、人が状況を確認して引き継げるようにします。

接続経路とデータの扱いを、業務に合わせて絞る

基幹データを扱う処理は、必要な接続先と操作だけを許可します。AWS上に論理的に分離されたネットワークを作るAmazon VPCを使い、データベースを一般公開しない構成を検討します。Bedrockにも、公衆インターネットを経由せずに接続する方法があります。ただし、これは通信経路を制御する仕組みで、AIモデルを自社のVPC内に置くという意味ではありません。Bedrockへのプライベート接続

AIに渡す情報も注文処理に必要な範囲に限定します。入力や出力の保存条件は、採用するモデル、地域、設定に応じて確認します。Bedrockでも条件によって保持や人による確認が行われるため、利用する組み合わせで判断します。Bedrockのデータ保持条件

守る対象には、受注データだけでなく、処理履歴やバックアップも含まれます。バックアップまで同時に失わない保管方法を選び、戻したデータと処理待ちの注文を照合して、業務を再開できるかを試します。復元できることと、取引を重複なく再開できることを、両方確かめる設計です。

既存の基幹システムからは、業務単位で段階的に移す

最初から販売管理、倉庫管理、会計をまとめて入れ替える必要はありません。既存システムを動かしながら、一つの業務を切り出し、AWS上で作った仕組みへ段階的につなぎ替えます。既存機能を少しずつ置き換える方法は、AWSの移行設計ガイドでも紹介されています。AWSの段階移行パターン

受注業務なら、まずは注文を読み取って登録案を作り、現在の担当者が処理した結果と比べます。この段階では本番の注文を自動登録しません。商品を正しく特定できるか、特殊な取引条件を拾えるかを、普段の注文と例外の両方で確かめます。

次に、対象の取引先や商品を絞り、承認を受けた注文だけを業務APIから登録します。取り消しや再処理が正しくできることまで確認したうえで、条件に合う通常の注文を自動実行へ移します。受注で確かめた後に、出荷、請求、入金の照合へ対象を広げます。

移行中は、受注や在庫の正式な記録をどちらのシステムで管理するかを決めます。旧システムと新システムがそれぞれ勝手に在庫を更新すれば、数が合わなくなります。情報の同期が遅れたときの扱い、切り替え時の未処理注文、元の運用へ戻す条件まで設計します。

移行できたかどうかは、画面が動くことだけでは判断できません。注文の処理時間や、担当者が対応に入った件数を確認します。登録ミスや二重処理の有無、必要な時間内に復旧できるか、運用費用も確かめ、次の業務へ進むかを判断します。現行システムに連携の窓口がなければ、その整備や製品のサポート条件の確認から始めます。

基幹システムの刷新を、AIが業務を進める転機に

キジトラが考えているのは、受注から出荷、請求、入金確認まで、日々の業務をAIがつなぎ、人が例外や改善に集中できる未来です。朝、担当者が確認するのは、処理済みの注文と、判断を待つ欠品や特別な取引条件。そんな働き方を、基幹システムの設計から作りたいと考えています。

最初の一歩は、「止まると困る業務」と「人の確認や転記で滞っている業務」を並べることです。現行システムを使い続ける部分と、AIに任せるために作り直す部分を分け、移行の順序を考えます。

基幹システムの更新とAI活用を一緒に検討したい方は、キジトラにご相談ください。現在使っているシステム、日々つないでいる作業、止められない業務を伺いながら、何を残し、どこからAWSへ移し、どの処理をAIに任せるかを一緒に考えます。