大塚商会が30万円からの業務自動化AIサービスを開始｜安く作れる時代に、そのシステムを誰が直すのか

結論：安くなったのは作る工程だけで、決める工程と維持する工程は安くなっていない

大塚商会が2026年7月23日に発表し、翌24日から「業務プロセス自動化 AIサービス」の提供を開始しました。生成AIとの対話を通じて開発を進める手法を用い、転記・集計・帳票作成といった定型業務の自動化システムを短期間で構築するというものです。

公表されている内容を整理すると、価格は30万円から、販売目標は提供開始後12カ月で100社。提供形態は、大塚商会のクラウド基盤で動くSaaS型AIエージェント、NVIDIA DGX Sparkベースのオンプレミス環境、Microsoft Azure上での稼働の3種類。プロセスは、ヒアリング・コンサルティングから始まり、プロトタイプを対話的に改善しながら納品に至る流れで、Microsoft 365やkintoneなどとのAPI連携も実装するとされています。

この発表の意味は明快です。大手SIerが、30万円という価格帯でシステム開発を販売し始めたということです。これまで「システム開発を頼むと数百万から」という感覚だった中堅・中小企業にとって、心理的な壁が一気に下がります。

歓迎すべき変化です。定型業務の自動化を諦めてきた企業に、現実的な選択肢が生まれました。

同時に、発注側が新たに考えるべきことも生まれています。そのシステムは、作った後どうなるのかという問いです。

3行サマリー（先に結論）

• 大塚商会が生成AIとの対話で業務自動化システムを構築するサービスを開始（発表7月23日、提供開始7月24日）。30万円から、12カ月で100社が販売目標。
• 安くなったのは「作る工程」で、業務要件を決める工程と、作った後を維持する工程のコストは変わっていない。
• 契約前に決めるべきは、①成果物に何が含まれるか ②仕様と設計の記録 ③改修の依頼先と単価 ④連携先の仕様変更時の扱い ⑤終了時のデータ取り出し、の5点。

要点表：サービスの概要

※サービスの詳細・価格の適用条件については、提供元の公式情報でご確認ください。

何が安くなり、何が安くなっていないのか

システム開発の費用は、大きく3つの工程に分かれます。

工程1：決める（要件定義） 何を作るのかを決める工程です。現在の業務手順を把握し、どこを自動化するのか、例外はどう扱うのか、誰が使うのかを決めます。

工程2：作る（設計・実装・テスト） 決まったものを実際に動くようにする工程です。

工程3：維持する（保守・改修） 稼働後、不具合を直し、業務の変化に合わせて改修し、連携先の仕様変更に追随する工程です。

生成AIによる開発が劇的に変えたのは、工程2だけです。コードを書く速度は上がり、試作から改善までの反復が速くなりました。だから価格が下がります。

一方、工程1は人が判断する領域です。「請求書の転記を自動化したい」と言われても、請求書の様式が取引先ごとに違い、月末だけ処理が変わり、特定の得意先だけ手作業の確認が入る——こうした実態は、業務を知っている人にヒアリングしなければ分かりません。AIが速くなっても、この工程は短縮されません。

工程3も同様です。むしろ、対話的に作られたシステムでは、この工程が難しくなる可能性があります。

「仕様書が残らない」という構造的な問題

従来の受託開発では、要件定義書、基本設計書、詳細設計書、テスト仕様書といった文書が作られました。これらは形式的で費用がかさむと批判されることもありましたが、一つの重要な役割を果たしていました。担当者がいなくなっても、システムの中身を第三者が理解できるという役割です。

対話を通じてプロトタイプを改善していく開発では、この文書が自然には生まれません。「もう少しこうしてほしい」「この場合はこう処理して」というやりとりの積み重ねが、そのまま動くものになる。速いのですが、なぜそう作られたのかの記録は残りません。

その結果、次のような事態が起こり得ます。

• 作った担当者（発注側・受注側の双方）が異動・退職すると、誰もその処理の意図を説明できない。
• 業務が変わって改修が必要になったとき、どこを直せばよいか分からず、作り直しになる。
• 動作が想定と違ったとき、それが仕様なのか不具合なのか判別できない。
• 連携先（Microsoft 365やkintone側）の仕様が変わったとき、影響範囲を特定できない。

30万円で作ったものが、3年後に「誰も触れないブラックボックス」になる。これは、金額の安さと引き換えに引き受けているリスクです。

だからこそ、契約時に「何を記録として残すか」を取り決めることが、従来以上に重要になります。

契約前に取り決めるべき5点

具体的に、発注前に確認・合意すべき項目を挙げます。金額が小さいからこそ、契約書を交わさずに進んでしまいがちですが、ここは省略すべきではありません。

取り決め1：成果物に何が含まれるか

「動くシステム」以外に何が納品されるのかを明記します。

• ソースコード・設定情報の引き渡しはあるか。
• 業務フローの記録（どの作業を、どんな順序で自動化しているか）はあるか。
• 例外処理の一覧（こういう場合はこう処理する、という条件の記録）はあるか。
• 操作手順書はあるか。

最低限、2つ目と3つ目は求めてください。詳細な設計書までは不要でも、「何をどう処理しているか」の記録がないと、後で誰も判断できません。

取り決め2：仕様と設計の記録をどう残すか

対話で作る手法であっても、完成時点でのふるまいを文書化することは可能です。「納品時に、実装された処理内容を一覧形式で提出してほしい」と依頼してください。これは追加費用が発生する場合がありますが、その費用は将来の改修費用を下げます。

取り決め3：改修の依頼先と単価

稼働後、必ず改修が必要になります。そのときの窓口と費用の考え方を決めておきます。

• 軽微な変更はいくらか、どれくらいの期間で対応されるか。
• 対応できる担当者は複数いるか（属人化していないか）。
• 保守契約はあるか。あるなら何が含まれるか。

30万円で作って、改修のたびに20万円かかるなら、総額は当初の想定と大きく変わります。

取り決め4：連携先の仕様変更時の扱い

Microsoft 365やkintoneといった外部サービスと連携する場合、それらの仕様は提供元の都合で変わります。変わったときに自動化が止まる可能性があります。

• 連携先の仕様変更で動かなくなった場合、修正は誰の責任・誰の費用か。
• 変更を事前に検知する仕組みはあるか。
• 止まったときに、誰がどう気づくか。

最後の項目が意外に重要です。夜間に動く自動処理が止まっていても、誰も気づかず、月末になって「データが入っていない」と発覚する——という事態は、実際によく起こります。

取り決め5：終了時のデータ取り出し

サービスを解約する、または別の方式に切り替えるときのことを決めておきます。

• 蓄積されたデータをどの形式で取り出せるか。
• 取り出しに費用は発生するか。
• 解約後、データはいつまで保持され、いつ削除されるか。

載せてよい業務、載せてはいけない業務

もう一つ重要なのが、対象業務の線引きです。同じ「業務の自動化」でも、リスクの大きさはまったく違います。

判断の軸はシンプルです。間違えたときに、気づけるか。気づいたときに、取り返せるか。この2つがどちらも「はい」なら適します。どちらかが「いいえ」なら、承認工程を挟むか、対象から外します。

30万円という価格帯のサービスは、上の表の上半分に適しています。下半分の業務を安さで選ぶと、後の事故で何倍もの費用がかかります。

30万円は何時間の削減で回収できるか

投資判断の材料として、回収の計算をしておきます。金額が小さいと「まあいいか」で決裁されがちですが、それは投資判断の放棄です。

単純な計算

仮に、社内の作業を外注費に換算する単価を時給3,000円とします。30万円の投資は、100時間の作業削減で回収できる計算になります。

• 毎日30分削減できる作業なら：月10時間、10ヶ月で回収。
• 毎日1時間削減できる作業なら：月20時間、5ヶ月で回収。
• 月次の作業で8時間削減できるなら：12.5ヶ月で回収。

この計算が示すのは、日次で発生する作業を対象にしないと回収が遅くなるということです。月に1回しか発生しない作業を自動化しても、回収に1年以上かかります。

計算に入れ忘れやすい費用

• 導入時の社内工数（ヒアリング対応、テスト、現場への説明）：初回は20〜40時間程度かかることがあります。
• 稼働後の確認作業：完全に無人にならず、結果の確認に時間がかかる場合があります。
• 改修費用：業務が変わるたびに発生します。
• 連携先の仕様変更への対応：発生時期は読めませんが、必ず発生します。

これらを含めた3年間の総額で判断してください。初期30万円でも、年間20万円の保守と改修が発生するなら、3年総額は90万円です。それでも回収できるかを見ます。

回収できない場合の判断

計算して回収できないという結論が出たら、その投資は見送るべきです。ただし、金額に表れない効果がある場合もあります。

• 属人化の解消（その人しかできない作業をなくす）。
• ミスの削減（手作業の転記ミスが減る）。
• 担当者の負荷軽減による定着率の改善。

これらは金額換算が難しいものの、実務上は重要です。定量的な回収に届かない場合は、これらの効果を明示したうえで、経営判断として決めるという進め方になります。「なんとなく良さそう」で決めるのとは違います。

「止まっていることに気づく」仕組みを設計する

自動化されたシステムで最も多い事故は、誤動作ではなく静かに止まることです。

夜間に動くはずの処理が動いていない。連携先の仕様変更でデータが取れなくなっている。エラーは記録されているが、誰も見ていない。そして月末になって「データが入っていない」と発覚する。

この事故を防ぐ設計は、難しいものではありません。

設計1：正常終了の通知を出す

異常時だけでなく、正常に終わったことも通知する設計にします。異常時のみ通知する設計だと、システム自体が止まったときに何も通知されません。「今日も正常に処理しました」という通知が来なくなったことで、異常に気づけます。

設計2：通知先を複数にする

担当者1名だけに通知が飛ぶ設計だと、その人が休暇のときに気づかれません。最低2名、または部署のメーリングリストへ送ります。

設計3：処理件数を通知に含める

「正常終了しました」だけでなく「◯件処理しました」と件数を含めます。件数が普段と大きく違えば、正常終了でも異常に気づけます。

設計4：最終確認を人の業務手順に組み込む

「毎朝、前日の処理結果を確認する」という手順を、担当者の業務に明示的に入れます。仕組みだけでなく、人の手順として定めることに意味があります。

これらは発注時に要件として伝えるべき事項です。「止まったときにどう気づくか」を発注時に聞かないことが、後の事故につながります。

内製する場合の記録の残し方

社内の担当者が生成AIを使って業務ツールを作る場合も増えています。外注より安く速い一方、記録が残らない問題はより深刻になります。

社内で最低限守るべきルールを示します。

ルール1：作った人と日付を残す ツールのどこかに、作成者・作成日・最終更新日を記載します。ファイル名やコメントで構いません。

ルール2：何をするツールかを1行で書く 「◯◯システムから受注データを取得し、△△の形式に変換してファイル出力する」という説明を残します。

ルール3：どこにつながっているかを書く 接続先のシステム、参照しているファイル、送信先。これがないと、接続先の変更時に影響範囲が分かりません。

ルール4：認証情報を直接書かない IDやパスワードをツールの中に直接書くと、そのファイルが共有された時点で漏えいします。設定ファイルや環境変数に分離する、という指示を出してください。

ルール5：一覧をどこかに集める 部署で作られたツールの一覧を、共有の場所に置きます。誰が何を作っているか把握できていないと、退職時に引き継げません。

この5つは、専門知識がなくても守れます。守られていない内製ツールが増えるほど、数年後に「誰も触れないものが社内に散在している」状態になります。

内製と外注をどう使い分けるか

このサービスの登場は、内製化の議論とも関係します。生成AIを使えば、社内の担当者が自分で業務自動化のツールを作ることも可能になってきています。では、外注する意味はどこにあるのか。

外注が向いている場合

• 社内に作れる人がいない、または育てる時間がない。
• 既存のシステムやSaaSとの連携が必要で、技術的な難度が高い。
• 業務が止まると影響が大きく、責任の所在を明確にしておきたい。
• 作った後の保守を、継続的に依頼できる相手が欲しい。

内製が向いている場合

• 業務の変化が速く、頻繁に手直しが必要。
• 対象が特定部署の小規模な作業で、影響範囲が限定的。
• 社内に興味と適性のある人材がいて、育成の機会にもしたい。

現実的には、併用が最も合理的です。基幹に近い部分や連携が複雑な部分は外注し、部署内で完結する軽い自動化は内製する。ただし内製する場合も、「誰が作ったか」「何を処理しているか」の記録は残す運用を課してください。記録なしの内製は、外注以上に属人化します。

FAQ

Q1. 30万円は安いのですか。 A. 従来のシステム開発と比べれば大幅に安い水準です。判断すべきは価格そのものより、その金額に何が含まれ、何が含まれないかです。改修費用や保守費用まで含めた3年間の総額で比較してください。

Q2. 生成AIで作ったシステムは品質が低いのではないですか。 A. 一概には言えません。作り方より、検証の仕組みがあるかで決まります。テストがどう行われ、誤りをどう検出するかを確認してください。

Q3. うちの業務は特殊なので合わないのでは。 A. 転記・集計・帳票作成といった作業は、業種を問わず存在します。むしろ「特殊だから自動化できない」と思われている作業のうち、実際に特殊なのは一部だけ、というのが通例です。

Q4. 社内に詳しい人がいなくても発注できますか。 A. できますが、業務の内容を説明できる人は必要です。「今どうやっているか」を正確に伝えられないと、出来上がるものが実務と合いません。ここは外部に代われません。

Q5. 作ったものが期待と違った場合はどうなりますか。 A. だからこそ、着手前に「完成の条件」を文書で合意してください。プロトタイプを見て判断できる進め方は利点ですが、どの時点で完成とするかは決めておく必要があります。

Q6. 既存の業務システムと連携できますか。 A. 連携先がAPIを提供しているかによります。古い基幹システムの場合、外部から接続する手段がないことがあります。事前に確認してください。

Q7. 他社の同種サービスとどう比較すればよいですか。 A. 価格だけでなく、本記事の5つの取り決めについて各社がどう回答するかで比較してください。回答が具体的な会社ほど、稼働後の運用も安定します。

GXOに相談すべきタイミング

次のいずれかに当てはまるなら、発注前の整理をおすすめします。

• 業務自動化のサービスに関心があるが、自社のどの業務に適用すべきか判断できない。
• 提示された見積もりに、保守や改修の費用が含まれているか読み取れない。
• 過去に作ったシステムが、誰も触れない状態になっている。
• 内製と外注のどちらで進めるべきか決めかねている。

GXOは特定の開発サービスを販売する立場ではないため、「そのサービスで十分」「そこは自社でできる」という結論も含めて整理できます。業務自動化の対象選定と発注条件の点検はシステム開発・DXの相談、AI活用の可否と範囲の第三者診断はAI導入診断、AI機能そのものの設計・実装はAI開発・活用の相談、現状の把握から始めたい場合はDX成熟度診断が入口です。受け取った提案書を一緒に読む形でも構いません。お問い合わせからご連絡いただけます。

安く作れるようになったこと自体は、中堅企業にとって明確な追い風です。気をつけるべきは、安さを理由に、作った後のことを決めないまま発注してしまうことのほうです。

参考文献

• 大塚商会「『業務プロセス自動化 AIサービス』を提供」（一次・公式リリース、2026年7月23日）: https://www.otsuka-shokai.co.jp/corporate/release/2026/260723.html
• IT Leaders「大塚商会、バイブコーディングによる業務自動化」（二次・報道）: https://it.impress.co.jp/articles/-/29618

※サービスの詳細、価格の適用条件、提供形態については、提供元の公式情報を一次情報としてご確認ください。本稿に示した回収計算は判断の目安であり、実際の効果を保証するものではありません。本稿は2026年7月24日時点の公表情報をもとにしています。