SaaS・IT企業のAI人材活用:開発ではなく「開発以外」を切り出す

SaaS・IT企業にAI活用人材の話をすると、最初に返ってくるのは「うちにはエンジニアがいるので自分たちでやれます」という反応です。実際、生成AIをコード生成やレビューに組み込むところまでは自走できている会社が多く、そこに外部人材を入れる必要は薄いと考えられます。一方で同じ会社のカスタマーサクセス・マーケティング・インサイドセールス・カスタマーサポートに目を移すと、担当が1〜3名しかいない、専任がいない、という状態が珍しくありません。本稿では、SaaS・IT企業でAI活用人材に任せる対象を「開発」ではなく「開発以外」に置くべき理由と、その線引きを公表資料の数値をもとに整理します。

国の統計が数えている「IT人材」はエンジニア職である

経済産業省の「IT人材需給に関する調査」は、国勢調査の職業分類上の「システムコンサルタント・設計者」「ソフトウェア作成者」「その他の情報処理・通信技術者」をIT人材として試算しています。ユーザー企業の情報システム部門等も対象に含まれますが、数えられているのは技術職です。需要の伸びを年平均2.7%程度、労働生産性が年0.7%上昇することを前提とした需給ギャップは、2018年の22万人から2020年30万人、2025年36万人、2030年45万人と拡大すると試算されました。供給側は2018年の103万人から2030年の113万人へ増える見通しであり、不足は供給が減るからではなく需要が伸びるから生じています（出典:経済産業省「IT人材需給に関する調査（概要）」（平成31年4月）https://www.meti.go.jp/policy/it_policy/jinzai/gaiyou.pdf ）。

この数字が示しているのは、エンジニアの取り合いが続くという事実です。SaaS企業の採用予算と経営の注意はこの取り合いに優先配分され、結果としてエンジニア以外の職種の増員が後回しになります。SaaS・IT企業の人手不足が非エンジニア職の問題として語られにくいのは、このためだと考えられます。

不足しているのはコードを書く人ではない

職種別の不足感を見ると、この構図はもう少しはっきりします。IPAの「DX動向2025」では、DXを推進する人材の「量」の確保について「やや不足している」「大幅に不足している」と回答した日本企業の合計が85.1%でした。「質」については「過不足はない」と回答した企業が日本で3.8%にとどまり、米国52.9%、ドイツ25.1%と大きな差があります。そのうえで人材類型別に最も不足している人材を尋ねると、日本は「ビジネスアーキテクト」、米国とドイツは「データサイエンティスト」という結果でした。データ集では、日本はとくに「ビジネスアーキテクト」「デザイナー」「データサイエンティスト」が不足しているとされ、ソフトウェアエンジニアは筆頭に挙がっていません（出典:IPA「DX動向2025」https://www.ipa.go.jp/digital/chousa/dx-trend/tbl5kb0000001mn2-att/dx-trend-2025.pdf 、IPA「DX動向2025（データ集）」https://www.ipa.go.jp/digital/chousa/dx-trend/tbl5kb0000001mn2-att/dx-trend-data-collection-2025.pdf ）。

ビジネスアーキテクトは、経済産業省とIPAが策定したデジタルスキル標準において「DXの取組（新規事業開発/既存事業の高度化/社内業務の高度化、効率化）において、目的設定から導入、導入後の効果検証までを、関係者をコーディネートしながら一気通貫して推進する人材」と定義されています（出典:同上）。実装できる人ではなく、どの業務にどう当ててどう効果を確かめるかを設計し、関係者を巻き込んで最後まで持っていく人が足りていない、ということです。SaaS企業に置き換えると、これは開発チームの外側で不足している役割にほぼ重なります。なお同調査では、8割超が不足を認識しながら19.4%の日本企業が「人材確保を行っていない」と回答しています。

顧客が増えるほど、開発以外の業務が積み上がる

非エンジニア職に負荷が溜まるのは、事業モデルの性質でもあります。前提として、企業側のクラウド利用そのものは広がっています。総務省の「令和7年通信利用動向調査」によると、クラウドサービスを一部でも利用している企業の割合は83.5%、全社的に利用している企業の割合は60.0%で、前年から6.9ポイント増加しました。

ただし、この調査でいう「クラウドサービス」はSaaS製品に限った概念ではありません。利用しているサービスの内容は「ファイル保管・データ共有」73.3%、「社内情報共有・ポータル」61.4%、「電子メール」57.4%が上位で、以下「給与、財務会計、人事」56.3%、「スケジュール共有」53.6%、「データバックアップ」46.4%と続き、「営業支援」は22.9%です（出典:総務省「令和7年通信利用動向調査の結果」（令和8年5月29日公表）https://www.soumu.go.jp/johotsusintokei/statistics/data/260529_1.pdf 、図表4-1および図表4-3）。ファイル共有・メール・サーバ利用を含む広い括りであり、SaaSの契約社数やARRを示す資料ではありません。したがってこの数字から個別のSaaS事業の顧客数が増え続けると読むことはできず、読み取れるのは、SaaSを含むクラウド利用が企業に定着し社内の利用範囲も広がっているという環境要因までです。

そのうえでサブスクリプション型の事業では、使い続けてもらう期間に収益が積み上がる構造上、契約社数が増えればオンボーディング・活用支援・問い合わせ対応・アップセル提案の件数もそれに応じて増えます。開発側は機能を1つ作れば全顧客に届きますが、顧客対応側はスケールしません。

この5つに共通するのは、情報を集めて整え、決まった型に落とし込み、相手に渡す工程が中心だという点です。判断そのものより、判断の手前の準備に時間が取られています。AI活用人材が関与できるのはこの領域です。

顧客対応のAI化は「入れたが効いていない」が起きやすい

ただし顧客対応領域のAI化は、他の業務より難度が高いというデータもあります。総務省「令和7年版 情報通信白書」のデータ集にある業務別の生成AI利用状況（日本の回答者442人ベース）を見ると、業務による差が出ています。

数字を読む前に、この設問の形式を確認しておきます。回答者は業務ごとに「業務で使用中（期待を上回る効果になっている／期待通りの効果になっている／期待を下回る効果になっている／効果は測定中または不明）」「トライアル中」「使用を検討中」「導入予定はない」の7区分から1つを選ぶ形式で、データ集CSVの回答者数を7区分で合計するとどの業務も回答者数442人と一致します。つまり公表されているパーセンテージは、いずれも回答者442人全体を分母とした構成比です。白書本文も「メールや議事録、資料作成等の補助」の47.3%を「『業務で使用中』と回答した割合」と説明しており、これは「業務で使用中」4区分の合計に当たります。

したがって「期待を下回る効果」の数値は、使用中の人のなかでの失敗率ではありません。下表では、公表ベースの全回答者を分母とした比率と、「業務で使用中」と回答した人だけを分母とした比率（データ集CSVの回答者数から本稿で算出）を分けて示します。

（出典:総務省「令和7年版 情報通信白書」データ集「企業における業務での生成AI利用率（業務別・国別）」https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r07/html/datashu.html 。回答者数は同ページからリンクされる日本分のCSV（f00046_01）による。「業務で使用中（合計）」と「使用中に占める比率」は、そのCSVの回答者数から本稿で算出したもので、白書に直接掲載されている数値ではありません。「期待を下回る効果」「導入予定はない」の各パーセンテージは全回答者442人を分母とした公表値です。SaaS業界に限定した調査ではなく、日本の回答者全体の数値です）

全回答者を分母とした公表値では、「期待を下回る効果」を選んだ割合は「顧客対応の自動化」が10.0%、「自社製品やサービスの機能として組み込み」が10.2%で、社内向けヘルプデスクやメール・議事録の補助の7.5%より高い水準にあります。ただしこの分母には使用していない人も含まれるため、そのままでは失敗率として読めません。使用中と回答した人だけを分母に取り直すと、顧客対応の自動化は26.3%、自社製品への組み込みは28.7%となり、メール・議事録の補助の15.8%、社内向けヘルプデスクの16.8%との差はむしろ広がります。分母をどちらに取っても、顧客対応の自動化が掲載業務のなかで期待を下回りやすい側にあるという傾向は変わりません。

社内向けなら回答が多少ぶれても担当者が補正できますが、社外の顧客に直接返す文面は誤りがそのまま信頼の毀損になります。品質の許容範囲が狭い分、設計と検証の工数がかかると考えられます。

SaaSの場合、この差はさらに開きやすいと考えられます。一次回答の根拠になるのは自社プロダクトの仕様であり、その仕様がリリースのたびに変わるためです。参照させるドキュメントが更新されていなければ、AIは古い仕様のまま自信のある文面を返します。加えて、問い合わせの向こう側にいるのは契約中の顧客企業であり、誤った一次回答は解約検討の材料にそのまま乗ります。顧客対応領域は、外部人材に丸投げして自動化してもらう対象ではなく、どこまでをAIに任せてどこから人が引き取るかの線と、仕様変更を参照情報へ反映し続ける運用を設計してもらう対象だと整理するのが現実的です。この領域で起こりやすい失敗の型はカスタマーサポートのAI導入が失敗する典型パターンと回避策で扱っています。

業務ごとの適性と、任せない範囲の線引き

SaaS・IT企業の業務をAI活用人材への適性で整理すると次のようになります。プロダクトの性質・顧客規模・社内体制によって変わるため、整理の一例です。

ここで「委ねない」と言っているのは、AIの出力や、開発・セキュリティの専門家ではないAI活用人材に判断を預けることです。開発会社に実装を外注する、セキュリティの専門家に設計レビューや脆弱性診断を依頼する、といった専門家への確認は別の話で、むしろ積極的に行うべき領域だと考えられます。そのうえで、プロダクト開発を外部のAI活用人材の主対象にしない理由は、能力の問題ではありません。プロダクトはSaaS企業の競争優位そのものであり、社内に知見を蓄積し続けること自体が事業価値だからです。加えて、開発・セキュリティの判断は顧客企業の情報資産に対する責任を伴い、業務を切り出しても責任は切り出せません。IPAの調査でも、日本企業は「先端的なAIアルゴリズムを開発したり、学術論文を書けたりするAI研究者」「AIを活用したソフトウェアやシステムを実装できるAI開発者」について「自社には必要ない」と回答した割合がそれぞれ56.4%、40.7%と、米国・ドイツより高い傾向にあります（出典:IPA「DX動向2025」https://www.ipa.go.jp/digital/chousa/dx-trend/tbl5kb0000001mn2-att/dx-trend-2025.pdf ）。研究・実装の内製と業務適用の設計は、必要とされる人材が別だという整理です。

顧客データとプロダクト機密を渡さない前提で業務を組む

外部人材を受け入れる際に最初に詰めるべきは、契約条件よりも情報の設計です。顧客企業から預かっているデータは自社の情報ではなく顧客の情報であり、多くの場合は利用目的と取扱範囲が契約で限定されています。したがって現実的な組み方は、情報に触れない工程から始めることになります。ヘルプドキュメントの構成整理、公開情報をもとにしたコンテンツ制作、ウェビナーの企画・運営は、顧客データにも本番環境にも触れずに着手できます。本番の顧客データや管理者権限に触れる工程は、必要性が明確になるまで社内に残すのが無難です。NDAの締結、閲覧範囲の限定、アカウント権限の最小化、利用する生成AIサービスと入力可能な情報の指定は、着手前に文書で確定させます。整理の観点はAI人材の情報漏洩対策｜外部委託時に整えるべきセキュリティ体制にまとめています。

MA・SFAの設定を任せると、本番の見込み客データに触れることになる

この線引きが最も崩れやすいのがMA・SFAです。リード対応やナーチャリングの仕組み化は前掲の表で適性「中」に置いた業務ですが、シナリオ設定やオブジェクト・項目の設計を本番環境で行おうとすると、見込み客の氏名・会社名・メールアドレス・電話番号や商談履歴が並ぶ画面を操作することになります。「顧客データは渡さない」と決めていても、管理画面のログインを1つ発行した時点で実質的に渡したのと同じです。動作確認のためにテスト配信を一度打つ、といった場面でも本番のリストに触れます。

分担は、外部人材の関与を設計と手順書化までにとどめ、実操作は社内が行う、という形を先に決めておくのが安全だと考えられます。運用上の分離としては、次のような手当てが挙げられます。構築と検証はサンドボックスや検証用テナントとダミーデータで行う。本番環境での作業がどうしても必要な場合は、参照できるオブジェクトと項目を限定した専用アカウントを発行し、氏名・連絡先など個人を特定できる項目は表示させない。アカウントは作業期間を区切って発行し、終了後に速やかに停止する。一括エクスポートと一括メール送信の権限は付与しない。作業ログを残し、誰がいつ何を参照したかを追えるようにする。

前提として、外部人材への委託が個人データの取扱いの委託に当たる場合、委託元には委託先に対する必要かつ適切な監督を行う義務があります（個人情報保護法第25条）。個人情報保護委員会のガイドラインは、この監督について「委託する業務内容に対して必要のない個人データを提供しないようにすることは当然のこと」としたうえで、適切な委託先の選定、委託契約の締結、委託先における個人データ取扱状況の把握という3点を求めています（出典:個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」3-4-4 委託先の監督 https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/ ）。権限を絞ることは、外部人材を信用しないという話ではなく、委託元に課された義務の履行に当たります。

「匿名化したデータなら渡せる」は法律上の整理と一致しない

もう一点、言葉の使い方に注意が必要です。個人情報保護法上の「匿名加工情報」は、氏名を消せば成立するものではありません。同法第43条第1項と個人情報保護委員会規則第34条は、特定の個人を識別することができる記述等の全部または一部の削除、個人識別符号の全部の削除、情報を相互に連結する符号の削除、特異な記述等の削除、そして元となる個人情報データベース等の性質を勘案したその他の措置、という5つの加工基準を定めています。作成した事業者には、含まれる個人に関する情報の項目を公表する義務（同条第3項）、第三者に提供する際に項目と提供方法を公表し「匿名加工情報である旨」を明示する義務（同条第4項）も課されます。

「仮名加工情報」もこれとは別の制度です。氏名等の記述、個人識別符号の全部、不正に利用されると財産的被害が生じるおそれのある記述等の削除が必要で（同法第41条第1項、規則第31条）、しかも法令に基づく場合を除いて第三者提供が禁止されています（同法第41条第6項。委託・事業の承継・共同利用に伴う提供は例外）。つまり、氏名列を落としただけのデータは匿名加工情報でも仮名加工情報でもなく、通常の個人データのまま扱う必要がある可能性が高いということです（出典:個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（仮名加工情報・匿名加工情報編）」 https://www.ppc.go.jp/personalinfo/legal/guidelines_anonymous/ ）。

実務で無理がないのは、「匿名化して渡す」ではなく「個人が特定できないレベルまで集約した統計データだけを渡す」と決めることです。統計情報を作成するために個人情報を加工する場合は匿名加工情報・仮名加工情報を「作成するとき」に該当しない、と同ガイドラインが明示しており、上記の加工基準や公表義務の枠組みに乗せずに済みます（出典:同上）。ただし集約すれば安全というわけではありません。顧客IDやテナントIDが残っていれば実質的に個票と変わらず、利用ログの時系列は行動パターンから利用者の推定につながり得ます。契約社数が少ないセグメントや、1社あたりの利用者が数名しかいないテナントでは、平均値や件数だけでも特定の企業や担当者に紐づきます。渡す前に、集計単位の最小件数、落とす列、テナントを識別できる情報の扱いを社内で先に決めてください。個々のデータが法律上どの区分に当たるかの最終判断は、法務・専門家の確認を経る前提で進めるのが安全です。

着手順序:公開情報から始めて、範囲を広げる

顧客に直接届かない・情報に触れない業務から始めるのが無理がありません。ヘルプドキュメントとFAQの整備、コンテンツ制作とウェビナー運営はここに入ります。次にオンボーディング資料の雛形化とリード対応シナリオの設計、そして問い合わせ一次対応の切り分け設計は確認工程を組んだうえで扱う、という順序です。リード対応シナリオの設計まで進む段階で、前節のMA・SFAの権限分離を先に決めておく必要があります。

効果の確認は、SaaSであればリリースサイクルで区切ると変化が見えやすいと考えられます。1リリースあたりのドキュメント更新にかかった時間と更新漏れの残件数、問い合わせの一次回答までのリードタイム、ウェビナー1本あたりの準備工数を着手前に記録し、削減できた時間が顧客との対話や解約予兆への対応に回っているかを見ます。指標の置き方はAI活用のROIをどう継続測定するかで扱っています。稼働量はリリース頻度と契約社数の増え方に合わせて決めるのが実際的で、週1日から始める場合の依頼範囲の切り方は週1日のAI人材活用で何が変わるかで整理しています。

まとめ

SaaS・IT企業の人材不足はエンジニア不足として語られがちで、経済産業省が試算した2030年45万人という需給ギャップも技術職を対象にした数字です。しかしIPAの調査で日本企業が最も不足していると答えたのはビジネスアーキテクト、すなわち目的設定から効果検証までを一気通貫で回す人材でした。SaaS企業でこの役割が最も欠けているのは、開発チームではなく、契約社数の増加に比例して業務が積み上がるカスタマーサクセス・マーケティング・インサイドセールス・カスタマーサポートの側です。AI活用人材を迎えるなら、対象はここに置くのが合理的だと考えられます。一方でプロダクトの設計・実装・セキュリティ判断は自社のコア資産と責任に直結する領域であり、AIの出力や非専門のAI活用人材に委ねる前提で設計してはいけません。開発やセキュリティの専門家に実装・レビュー・脆弱性診断を依頼することは、これとは区別して考えてください。顧客データを扱う工程では、MA・SFAのように設定作業がそのまま本番の見込み客データへのアクセス権限につながる業務があり、実操作を社内に残す権限分離を先に決める必要があります。また「匿名化したから渡せる」という整理は法律上の要件と一致しないため、渡す範囲は個人が特定できないレベルまで集約した統計データにとどめ、契約上の制約や個人情報保護法上の位置づけに関わる判断は、進める前に法務・専門家の確認を経てください。