ラクスCAIO、AI時代もSaaSの価値は残ると指摘

ラクスの取締役兼CAIO、本松慎一郎氏は、AIでアプリケーションを作れるようになっても、日本企業では既存SaaSが選ばれ続ける領域が多いと述べています。取材は2026年10月22日に行われました。本松氏は、業務をシステムに合わせる傾向が強い米国などに対し、日本企業は現在の業務手順に合うシステムを求めると説明します。

現在の業務フローを保ったままSaaSを置き換えるには、細かな機能の再現と正確な処理が必要です。経理業務には金額の照合や入力確認など、ミスを防ぐ手順が組み込まれており、長年磨かれた仕組みは新技術が登場しても簡単には変わりません。生成AIにはハルシネーション（事実と異なる出力）のリスクもあり、置き換えの難しさは技術だけでなく、企業が業務をどこまで変えられるかにも左右されると本松氏は見ています。

ラクスは、経費精算サービス「楽楽精算」をAI前提の仕組みで代替できるか、社内で思考実験や部分的なPoC（実現可能性の試験）を進めています。本松氏によると、楽楽精算は数百、場合によっては1,000に迫る機能の集合体です。仮に100機能をAIで再現しても、機能を組み合わせた際に正しく動くか人が確認する必要があります。AIに実装やテストを任せる場合も、正しい動作を定めた仕様が要り、仕様の作成と業務上の問題がないかの判断には、業務とシステム双方の理解が必要です。システム開発を専門とするラクスにとっても、全機能の仕様整理と確認は大きな負担だといいます。

本松氏は、SaaSの価値には機能だけでなく、複数の機能を業務で使える形に組み合わせ、正しく動くか検証する知識やノウハウも含まれると説明します。対象がシンプルな業務ならAIによる代替が進む可能性はある一方、自社構築では保守や修正を担う人の費用もかかります。品質や業務効率、運用費まで考えると、安価で品質のよい既存パッケージを使う方がよい場合があると述べています。

ラクスは、ルールベースのシステムを土台に、人が担ってきた作業をAIで自動化する「協働型AI」を進めています。楽楽精算の伝票作成支援AIエージェントでは、領収書の転記に加え、金額や勘定科目の判断を支援します。過去の申請や経理担当者の指示をAIに学習・参照させ、人が行っていた判断の自動化を目指します。社内規定と申請内容の照合のように、文章の解釈や多様な判断が必要で、条件分岐として書き出しにくい業務にも活用する考えです。過去の申請や承認結果をシステム内で活用できることが楽楽精算の強みで、どの情報を学習に使うかは継続して見直しています。

ラクスは経費精算業務の「完全自動化」を目指すものの、本松氏は人の関与がゼロにはならないと見ています。AIの確認結果を踏まえれば人の負担は減らせますが、誤りへの責任は人にあるため、最終承認などの確認は残るという考えです。同社のいう完全自動化は、多くの作業をシステムとAIが担い、人が責任を伴う判断や確認に関わる状態です。

ラクスは、顧客ごとの業務に合わせてAIでシステムを構築するサービス「ASURACORE（アスラコア）」にも取り組んでいます。ASURACOREディレクターが顧客に聞き取り、日常の言葉で伝えられた要望を機能に落とし込み、最短1カ月で利用開始できるとしています。構築の土台には、同社がサービス提供で蓄積した業務知識を、業務上の概念と関係を整理したオントロジー（概念間の関係を形式化した知識体系）として活用します。顧客固有の条件は要件定義で把握し、導入企業の暗黙知をすべて事前に整理することは前提にしていません。

本松氏によると、コンセプトテストでは、事前に用意した業務知識とディレクターが聞き取った情報を組み合わせてシステムを構築できています。共通で蓄積するのは、業務要件に対してどの機能を作ったかという知識で、顧客を特定する情報や具体的な業務情報は学習に使いません。運用時にAIが参照する社内規定や判断基準は、各企業に紐づく知識として扱います。構築経験を次のシステムの機能や画面、処理方法に反映する考えです。

本松氏は、ラクスが重視するのはSaaSという提供形態ではなく、顧客の業務と課題を理解して業務効率化を実現することだと述べます。既存SaaSで対応できる業務は機能を磨き、AIが有効な作業にはAIを組み合わせ、個別要件にはシステムを構築する方針です。AIを前提に企業が業務そのものを見直せば、システムに求める要件も変わるとしています。

ラクスの取締役兼CAIO、本松慎一郎氏は、AIでアプリケーションを作れるようになっても、日本企業では既存SaaSが選ばれ続ける領域が多いと述べています。取材は2026年10月22日に行われました。本松氏は、業務をシステムに合わせる傾向が強い米国などに対し、日本企業は現在の業務手順に合うシステムを求めると説明します。

現在の業務フローを保ったままSaaSを置き換えるには、細かな機能の再現と正確な処理が必要です。経理業務には金額の照合や入力確認など、ミスを防ぐ手順が組み込まれており、長年磨かれた仕組みは新技術が登場しても簡単には変わりません。生成AIにはハルシネーション（事実と異なる出力）のリスクもあり、置き換えの難しさは技術だけでなく、企業が業務をどこまで変えられるかにも左右されると本松氏は見ています。

ラクスは、経費精算サービス「楽楽精算」をAI前提の仕組みで代替できるか、社内で思考実験や部分的なPoC（実現可能性の試験）を進めています。本松氏によると、楽楽精算は数百、場合によっては1,000に迫る機能の集合体です。仮に100機能をAIで再現しても、機能を組み合わせた際に正しく動くか人が確認する必要があります。AIに実装やテストを任せる場合も、正しい動作を定めた仕様が要り、仕様の作成と業務上の問題がないかの判断には、業務とシステム双方の理解が必要です。システム開発を専門とするラクスにとっても、全機能の仕様整理と確認は大きな負担だといいます。

本松氏は、SaaSの価値には機能だけでなく、複数の機能を業務で使える形に組み合わせ、正しく動くか検証する知識やノウハウも含まれると説明します。対象がシンプルな業務ならAIによる代替が進む可能性はある一方、自社構築では保守や修正を担う人の費用もかかります。品質や業務効率、運用費まで考えると、安価で品質のよい既存パッケージを使う方がよい場合があると述べています。

ラクスは、ルールベースのシステムを土台に、人が担ってきた作業をAIで自動化する「協働型AI」を進めています。楽楽精算の伝票作成支援AIエージェントでは、領収書の転記に加え、金額や勘定科目の判断を支援します。過去の申請や経理担当者の指示をAIに学習・参照させ、人が行っていた判断の自動化を目指します。社内規定と申請内容の照合のように、文章の解釈や多様な判断が必要で、条件分岐として書き出しにくい業務にも活用する考えです。過去の申請や承認結果をシステム内で活用できることが楽楽精算の強みで、どの情報を学習に使うかは継続して見直しています。

ラクスは経費精算業務の「完全自動化」を目指すものの、本松氏は人の関与がゼロにはならないと見ています。AIの確認結果を踏まえれば人の負担は減らせますが、誤りへの責任は人にあるため、最終承認などの確認は残るという考えです。同社のいう完全自動化は、多くの作業をシステムとAIが担い、人が責任を伴う判断や確認に関わる状態です。

ラクスは、顧客ごとの業務に合わせてAIでシステムを構築するサービス「ASURACORE（アスラコア）」にも取り組んでいます。ASURACOREディレクターが顧客に聞き取り、日常の言葉で伝えられた要望を機能に落とし込み、最短1カ月で利用開始できるとしています。構築の土台には、同社がサービス提供で蓄積した業務知識を、業務上の概念と関係を整理したオントロジー（概念間の関係を形式化した知識体系）として活用します。顧客固有の条件は要件定義で把握し、導入企業の暗黙知をすべて事前に整理することは前提にしていません。

本松氏によると、コンセプトテストでは、事前に用意した業務知識とディレクターが聞き取った情報を組み合わせてシステムを構築できています。共通で蓄積するのは、業務要件に対してどの機能を作ったかという知識で、顧客を特定する情報や具体的な業務情報は学習に使いません。運用時にAIが参照する社内規定や判断基準は、各企業に紐づく知識として扱います。構築経験を次のシステムの機能や画面、処理方法に反映する考えです。

本松氏は、ラクスが重視するのはSaaSという提供形態ではなく、顧客の業務と課題を理解して業務効率化を実現することだと述べます。既存SaaSで対応できる業務は機能を磨き、AIが有効な作業にはAIを組み合わせ、個別要件にはシステムを構築する方針です。AIを前提に企業が業務そのものを見直せば、システムに求める要件も変わるとしています。