SaaSを使いこなすだけでは足りない？AI時代の業務アプリは「買う・作る・つなぐ」で考える

SaaSか自作か。答えは「業務ごとに組み合わせる」

これまでは、会計、勤怠、顧客管理などのSaaSを導入し、その使い方を覚えることが業務改善の中心でした。標準的な機能をすぐ利用でき、法改正やセキュリティ更新も提供会社が継続して行う。多くの会社にとって合理的な選択です。

一方で、SaaSに収まりきらない仕事も残ります。CSVを出してExcelへ貼る。別のシステムと数字を突き合わせる。自社だけの区分で並べ替える。報告書の形に整える。こうした隙間を、人の転記と記憶で埋めてきました。

AIによる開発支援は、この隙間に小さな仕組みを作るハードルを下げています。さらにAIエージェントは、許可されたAPIや画面操作を使い、複数の道具をまたぐ処理を実行できます。OpenAIのエージェント構築ガイドでも、外部システムを扱うためのツール設計と、APIがないシステムでのコンピューター操作が説明されています。

ただし、これは「SaaSを捨てる」という話ではありません。

標準業務はSaaSに任せる。会社固有の狭い部分だけを作る。既存の道具は連携で生かす。AIは操作と下書きを担い、人は目的、承認、例外判断を担う。

なぜ、小さな専用アプリを作りやすくなったのか

以前の自社開発では、画面、データベース、権限、集計、テストなどを一つずつ実装する必要がありました。小さな改善でも、要件書を作り、見積もりを取り、数か月待つことがあります。そのため、多少使いにくくてもSaaSへ仕事を合わせる方が現実的でした。

現在は、AIに現在の作業手順、入力項目、出力例、守るべき条件を伝えることで、画面や処理のたたき台を早く作れます。担当者が実物を触り、「この列は不要」「この場合だけ責任者へ戻す」と修正する進め方がしやすくなりました。

開発速度については、条件によって異なる結果が出ています。GitHubが95人の開発者を対象に行った実験では、JavaScriptでHTTPサーバーを作る限定課題を、Copilot利用群が平均55%早く終えました。GitHubの実験です。

一方、METRが2025年に行った実験では、使い慣れた大規模なオープンソースソフトウェアを扱う16人の開発者が、当時のAIを使うと完了まで19%長くかかりました。METRの研究は、AIが一般に開発を遅くするとは結論づけておらず、2026年の更新では新しいAIによる速度向上が大きくなっている可能性にも触れています。METRの更新

つまり、「AIなら必ず何倍も早い」とは言えません。新しい小規模な処理や試作は軽くしやすい。長年の変更が積み重なったシステムや、例外を多く含む業務では、理解と検証に時間がかかる。この違いを見ておく必要があります。

SaaSがなくならない三つの理由

AIでコードを書きやすくなっても、会計や勤怠などを各社が一から作る必要はありません。

標準機能をすぐ使える

ログイン、権限、検索、通知、データ出力など、業務システムには共通機能が多くあります。SaaSなら、すでに利用されている機能を契約後すぐに使えます。

更新と障害対応を任せられる

制度変更、OSやブラウザーの更新、脆弱性への対応は一度で終わりません。SaaSの料金には、継続的な更新と運用が含まれています。自作する場合、この責任は自社か開発会社が持ち続けます。

他社と同じでよい業務を個別化しなくて済む

独自性が利益につながらない部分まで専用化すると、変更のたびに費用と判断が発生します。標準に合わせられる仕事はSaaSへ寄せ、違いを残す価値がある部分に開発を集中した方が、全体を管理しやすくなります。

「買う・小さく作る・つなぐ」をどう選ぶか

製品名から選ぶのではなく、仕事の性質から考えます。

作ることが向いているのは、「自社だけの仕事」だからではありません。件数があり、手順がある程度決まり、入力と出力が分かり、失敗時に戻せる仕事です。

反対に、担当者ごとに正解が違う仕事をそのままアプリにすると、曖昧さがコードへ埋め込まれます。まず、誰が何を見て判断しているのかを整理する方が先です。

AIがアプリを使うとは、どういうことか

AIエージェントは、人の文章による依頼を受け、決められた道具を選び、処理結果を返す仕組みです。たとえば「今月分を集計し、前月との差が大きい項目を挙げて、報告文の下書きを作る」と依頼します。

このとき、AIが自由に社内システムを歩き回る必要はありません。実際には、次のように操作範囲を狭く定義します。

1. 指定フォルダーにある今月分のCSVだけを読む
2. 決めた計算式で集計する専用処理を呼び出す
3. 前月差と欠損を確認候補として並べる
4. 確定前と明記した報告文の下書きを作る
5. 責任者が数字と文章を確認した後に送信する

AIは依頼内容の理解や文章作成に向いています。金額計算や形式変換など、毎回同じ結果が必要な処理は、通常のプログラムに任せた方が確かです。AIと専用アプリは競合するものではなく、それぞれ得意な部分を分けて使います。

人は「指示するだけ」ではなく、目的と責任を持つ

「人間はAIに指示すれば、あとは完成する」という姿は魅力的です。しかし、業務で必要なのは指示文だけではありません。

人が決めるのは、何を完了とするか、どの情報を使ってよいか、いくら以上なら承認が必要か、例外を誰へ戻すか、誤りがあったときにどう止めるかです。AIが作った結果について、最終的に誰が責任を持つかも変わりません。

NISTの安全なソフトウェア開発ガイドも、AIが生成した内容は人が監視・検証し、正確性と信頼性を確かめられる手順を持つ必要があると説明しています。

作るコストは下がっても、持ち続けるコストは消えない

AIを使うと、画面やコードが短時間で動くことがあります。そこで「完成した」と判断すると、後から困ります。

誰がアカウントを作るのか。異常をどう知らせるのか。元データが変わったらどうするのか。退職者の権限をどう止めるのか。バックアップから戻せるのか。担当した開発者がいなくても直せるのか。

これらは、コードを書く速さだけでは解決しません。DORAの2025年調査も、AIは組織の強みと弱みを増幅し、効果はツール単体より、開発や運用の仕組みに左右されると説明しています。DORA 2025

自作を検討するときは、初期開発費だけでなく、少なくとも次を一年単位で見積もります。

• 利用料、クラウド費、外部API費
• 修正、監視、問い合わせ対応に使う時間
• 権限管理、バックアップ、セキュリティ確認
• SaaSやデータ形式が変わったときの対応
• 担当者変更時の資料と引き継ぎ

安く作ることより、無理なく持ち続けられる範囲まで小さくすることが大切です。

具体例：月次報告は、全部を置き換えなくてよい

複数のSaaSからCSVを出し、Excelへ貼り、前月との差を探し、報告文を書く仕事を考えてみます。

この仕事のために、元のSaaSをすべて廃止して大きなシステムを作る必要はありません。正式なデータは既存SaaSから出す。固有の列整理と集計だけを専用処理にする。AIは差分の確認候補と報告文の下書きを作る。数字の確定と送信は人が行う。この分担なら、既存投資を生かしながら、間に残った手作業を減らせます。

病院で試す場合も、最初から患者情報や電子カルテへ接続する必要はありません。公開情報や個人情報を含まない管理資料など、影響を限定できる事務作業から始めます。医療情報を扱う設計は、この記事とは分けて、院内規程、関係するガイドライン、既存ベンダーとの責任分界を確認する必要があります。

最初の一歩は、アプリ名ではなく一つの手作業を選ぶこと

「何を作るか」から始めると、不要な機能が増えます。まず一つの手作業について、現在の流れを確認します。

1. 誰が、何を受け取るのか
2. どこへ入力し、何を転記するのか
3. どの条件で確認や差し戻しが発生するのか
4. 何が終われば完了なのか
5. 月に何件あり、どれだけ時間がかかるのか
6. 失敗したとき、元の手順へ戻せるか

この情報があれば、「SaaSで足りる」「連携だけでよい」「小さな専用画面が必要」「先に手順を整える」という選択ができます。最初から詳しい要件書を作る必要はありません。

FDEが現場で業務を整理し、試作から定着まで進める流れも、あわせて確認できます。

AI時代の業務アプリについてよくある質問