Luaのシステム開発の完全ガイド

Luaのシステムは、既存の業務基盤に処理を足す形で導入するのが現実的です。API連携、認証・データ変換、ルール実行、機器連携に分けて考えると、既存基盤を生かした導入の範囲を決めやすくなります。

全体の流れは、システムの種類、開発の進め方、費用、構成の選択肢、保守と発注先の選び方の順です。

▼関連記事一覧
・Luaのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・Luaのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・Luaのシステム開発の見積相場や費用/コスト/値段について
・Luaのシステム開発の発注/外注/依頼/委託方法について

Luaのシステムの全体像

業務画面やAPI、Lua実行環境、データストア、運用基盤を4層で示した図解。
Luaの実行環境をデータと運用の層の間に配置しています。

Luaは、C言語などで作られたアプリに組み込みやすい軽量なスクリプト言語です。仕様はLua 5.4の公式リファレンスマニュアルで定義されており(Lua 5.4リファレンスマニュアル)、テーブル、メタテーブル、コルーチン、ガベージコレクション、モジュールなどが含まれます。

業務システムでは、Luaだけで画面や会計機能を作るより、既存基盤へ業務ルールや拡張処理を追加する使い方が現実的です。

Luaの役割は業務システムの差分を埋めること

業務システムには、画面、API、データベースなど複数の層があり、認証や監査ログ、バックアップ、監視なども含まれます。

  • API処理:リクエストの振り分けや入力値の変換を受け持ちます。
  • 権限・ルール:ユーザー権限に応じた処理と、在庫・IoTデータの判定を行います。
  • 機能追加:既存のC・C++資産やWeb基盤を生かした段階的な拡張です。

特に、変更が多く応答速度も求められる層に置くと、効果を出しやすくなります。全面刷新よりも、既存業務への機能追加に向いています。

基本構成は、画面・Lua実行環境・データ・運用基盤

基本構成は、業務画面とAPI、LuaランタイムまたはLua対応ミドルウェア、RDBやNoSQLなどのデータストアです。

運用基盤には、認証、監査ログ、監視を含めます。たとえば、画面は別のWebフレームワークで作り、APIゲートウェイでLuaを使って認証やレート制限を行い、業務データはRDBへ保存します。

Luaの実行場所、読み書きするデータ、障害時に戻す処理を図にしておくと、どこまでを誰が受け持つかと見積もりの範囲がはっきりします。

Luaのシステムの種類と向いている業務

Luaの採用領域は、接続するホスト製品や既存資産によって変わります。処理のどこで低遅延や柔軟なルール変更、組込み性が必要かを確かめると、選ぶ方向が見えてきます。業務システムで検討しやすいタイプは4つあり、最後の基幹機能をLuaだけで作る場合には注意が要ります。

APIゲートウェイ・Web基盤の拡張

APIゲートウェイでは、認証やアクセス制御、レート制限を実行できます。さらに、ヘッダー変換やキャッシュ制御、ログ付与、バックエンドへのルーティングも行えます。

Kong Gatewayは、標準・独自のLuaプラグインで機能を拡張できます(公式プラグイン資料)。共通認証や監査処理を業務APIにまとめたい場合に、候補になります。

ルールエンジン・データ変換

Luaは、受注別の配送区分や在庫の補充通知に加え、IoT値のアラートや取引先別の項目変換にも使えます。条件を設定ファイルやテーブルで管理しておけば、システム全体を止めずにルールを変えやすくなります。

ルールを柔軟に変えられる一方で、誰がいつ何を変えたかを追えないと、監査ができなくなります。そこで、編集者、承認者、適用日時、旧版への戻し方を設計しておきます。

組込み機器・業務端末のスクリプト拡張

製造設備や計測機器、物流端末、業務用ゲートウェイでは、基本制御をCやC++で保ったまま、顧客別の設定や現場ルールをLuaで差し替える方法もあります。

再コンパイルせずに、導入先ごとの閾値や通信先を変えられるのが利点です。一方で、メモリ上限や停電時の復旧、オフライン動作は、事前に検証する必要があります。加えて、ファームウェア更新と署名付きスクリプトの配布も検証の対象です。

基幹機能をLuaだけで作る場合の注意点

会計や給与、販売管理、複雑な帳票をLuaだけで作る必然性は、通常高くありません。制度改正や画面、権限、移行、保守人材まで含めて考えると、標準SaaSや既存パッケージのほうが導入しやすい場合があります。

標準機能を業務の中心に置き、LuaをAPI連携やルール処理に限る構成と比べると、過剰なスクラッチ化を防げます。

ポイント

Luaは、低遅延や柔軟なルール変更、組込み性が必要な処理に限って使うと判断しやすくなります。基幹機能全体をLuaで作る案は、標準SaaSとの比較を先に行います。

Luaのシステム開発の進め方

業務整理から検証、設計・実装、テスト・移行へ進む開発工程の図解。
代表シナリオを確かめてから実装と移行へ進みます。

Luaのシステム開発では、言語を選ぶ前に業務の流れと責務を定めます。そのうえで、Lua 5.4にするかLuaJIT系のLua 5.1互換環境にするか、ホスト製品のバージョンとAPIをどう固定するかが、保守性を左右します。

PoCから本番運用までは、業務整理、検証、設計・実装、テスト・移行の順に進めます。

▶ 詳細はこちら:Luaのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

業務の洗い出しとLuaの責務の限定

電話やメール、Excel、手入力、担当者の経験則に頼る業務も含めて、「入力→判定→連携→承認→記録」の流れを洗い出します。

  • Luaを使う範囲:APIゲートウェイや認証補助、データ変換、ルール実行、機器側の設定処理のどこまでをLuaが担うかを分けます。
  • 他製品の担当範囲:画面や会計、マスタ、帳票を担う製品やサービスの選定です。
  • 処理ごとの仕様:入力、出力、失敗時の扱い、監査ログの要否を一覧にします。

この整理をしておくと、言語の選定そのものが目的になることを防げます。

PoCでのバージョンと代表シナリオの検証

PoCでは、価値の高い業務シナリオを一つか二つに絞ります。対象の例は、API認証とレート制限、在庫閾値の通知、機器データの受信とルール判定です。

  • 障害時の動作:外部API遅延、DB障害、タイムアウト、重複送信、ロールバックの各場面で動きを試します。
  • 実行環境:Lua 5.4、LuaJIT、OpenResty、Kong Gateway、Tarantoolを比べます。
  • 評価項目:実データ量と接続数で、処理時間、メモリ、ログ追跡性、修正できる範囲を記録します。

設計・実装で再現できる開発環境

Luaのソースやモジュール、ネイティブ拡張、設定、DBスキーマ、コンテナ定義を、同じリポジトリでまとめて管理します。そうすれば、誰でも同じ環境を再現できます。

テーブルやメタテーブルを多用すると、データ構造が暗黙的になりやすいです。そのため、入力と出力の型、エラーコード、ログ項目、タイムアウトを設計書に明記します。

単体テストに加えて、ホスト製品との結合テストや、将来のバージョンアップを想定した互換性テストも行います。

テスト・移行・運用引き継ぎの一体計画

本番への切り替えに備えて、テスト、移行、運用支援、納品までを一つの計画にまとめます。

  • テスト:機能試験、負荷試験、脆弱性試験、障害復旧試験を、それぞれ別に行います。
  • データ移行:マスタや履歴、権限、外部連携先のデータを、件数や文字コード、時刻、重複、欠損、金額の丸めの観点で確かめます。
  • 運用引き継ぎ:復元、障害連絡先、当番、SLA、ログ保存期間、Lua修正の承認者を決めます。
  • 納品:ソースコードや設計書、テスト結果、環境構築手順を受け取ります。

ポイント

言語を選ぶ前に業務の流れと責務を定め、代表的な業務シナリオをPoCで確かめてから本開発へ進むと、後戻りを減らせます。

Luaのシステム開発の費用相場と内訳

Luaだけを対象にした国内の業務システム開発の統計は少ないため、ここで示す数字は、一般的な開発費とLuaの利用範囲から算出した予算仮説です。

2026年版の公開相場情報では、人月単価は60万〜200万円程度とされ、規模やスキル、地域によって変動します(出典:2026年版の国内システム開発費用調査)。

Luaのライセンス費が低くても、要件定義やホスト基盤、連携、性能試験、保守人材の費用は別にかかります。

▶ 詳細はこちら:Luaのシステム開発の見積相場や費用/コスト/値段について

▶ 詳細はこちら:Luaのシステム開発の発注/外注/依頼/委託方法について

規模別の予算目安

開発規模ごとの予算と期間は、次の幅を目安にします。

  • 小規模PoC:既存APIへの認証・データ変換の追加で、100万〜300万円、1〜2か月が目安です。
  • 部門向け:業務APIやルールエンジンに、RDB、認証、管理画面、テストを含める場合は、300万〜800万円、2〜4か月程度です。
  • 複数連携:既存ERP、倉庫、会計、外部APIとの連携は、800万〜2,000万円、4〜8か月程度になります。
  • 高負荷基盤:高トラフィックのゲートウェイやリアルタイム処理は、1,500万〜5,000万円以上、6〜12か月程度が仮説です。

全社基幹刷新や大規模移行では、3,000万円〜1億円超になる場合もあります。なお、この総額には業務整理や画面、連携、移行、教育、運用設計が含まれ、Lua固有の費用ではありません。

機能数だけでなく、連携先数やピーク時の同時実行数、可用性、監査要件、切り替え方法も前提にして、見積もりの条件を比べます。

工程・連携・非機能要件に分けた費用の内訳

工程別の仮置きの比率は、要件定義が10〜15%、基本設計が15〜20%、詳細設計が10〜15%です。実装と単体テストは30〜40%、結合・総合テストは15〜20%、移行・導入は5〜10%です。

この比率は固定の標準ではなく、案件の複雑さを確かめる目安として使います。Lua案件では、ホスト製品の設定やネイティブ拡張、負荷試験、ログ、脆弱性対応、更新検証が抜けやすいものです。そのため、納品するものと作業量も明記しておきます。

初期費用と分けた保守・クラウド・監視費

初期費用とは別に、クラウドやサーバー、ログ保管、監視の費用がかかります。さらに、バックアップや脆弱性対応、問い合わせ、障害対応、機能追加の費用も発生します。

保守費を初期開発費の年15〜20%と仮定すると、3,000万円の開発費では年450万〜600万円、月37.5万〜50万円程度です(出典:業務システム全般の費用整理、2026年)。

24時間監視やSLA、現地対応、法改正対応の有無で金額は変わります。そのため、年額だけでなく、対応時間と対象範囲も確かめておきます。

ポイント

費用は、Luaのライセンス費だけでなく、要件定義や連携、性能試験、保守人材まで含めて見積もります。規模により100万円台から1億円超まで幅があるため、前提をそろえて比べます。

パッケージ・クラウド・スクラッチの選び方

標準サービスとのLua連携、API基盤、低遅延アプリケーション基盤、配置方式を並べた図解。
方式ごとに基盤や配置場所の検討対象が異なります。

選択肢には、完成済みクラウドサービスやパッケージ連携のほか、OpenRestyやKong Gateway、Tarantool、別言語の本体へのLua組込みがあります。

導入期間や自由度、保守人材、障害時にどこまでを誰が受け持つか、将来の移管のしやすさを同じ条件で比べます。そうすると、自社に合う方式を選びやすくなります。

標準SaaS・パッケージ+Lua連携

会計、販売、勤怠、顧客管理などはSaaSやパッケージを使い、API連携、データ変換、通知条件をLuaで補います。

業務標準化や法改正への対応、バックアップ、利用者管理をサービスに任せられるため、導入と運用の負荷を抑えられます。一方で、APIや実行環境、Luaの配置場所には制約があります。そのため、連携仕様とデータの所有権を確かめます。

OpenResty・Kong GatewayによるAPI基盤

複数APIの認証やアクセス制御、ルーティング、レート制限、リクエスト変換をまとめたい場合は、Lua対応のWeb基盤が候補になります。

ゲートウェイに処理を集めると、同じロジックを各業務APIに何度も実装することを避けられます。

一方で、停止すると複数の業務に影響するため、冗長化や設定の版管理、段階リリース、負荷試験が欠かせません。商用サポートや診断を使う場合は、製品費、サポート費、導入支援費を分けて比べます。

Tarantoolなどの低遅延アプリケーション基盤

低遅延API、リアルタイムに近い処理、キャッシュと永続化を一体で扱う場合は、Luaアプリケーションサーバーとデータ処理基盤を組み合わせます。

  • 処理の集約:保存やトランザクション、レプリケーションをLuaから扱えるため、処理を短くできる可能性があります。
  • 運用の責任:DB障害時の復旧やクラスタ、バックアップ、スキーマ変更、担当者の育成まで、受け持つ範囲が広がります。
  • 管理機能の保護:管理ポートや認証、接続元の制限を確かめます(公式のセキュリティ資料)。
  • 秘密情報の管理:管理コンソールは外部に公開せず、Unixソケットや送信元IP制限で守り、コードに秘密の値を埋め込みません。

クラウド・オンプレミス・ハイブリッド

クラウドは計算資源を増減しやすく、監視やバックアップのサービスも組み合わせやすい方式です。

オンプレミスは、閉域網や機器との近距離通信、大量データ処理、社内規程への適合が必要な場合に検討します。

機密性の高い基幹データは社内に置き、APIゲートウェイや一部のルール処理はクラウドに置く方法もあります。この形では、通信断時の動作やデータ同期、時刻のずれ、障害時の切り戻しをPoCで確かめます。

ポイント

導入方式は、導入期間や自由度、保守人材、障害時の受け持ち範囲、将来の移管のしやすさを同じ条件で比べて決めます。

セキュリティと保守性を高める設計

Luaを使うこと自体で安全かどうかは決まらないため、リクエスト、DB接続、機器への配布の各層で安全策を設計します。

入力値検証や認証認可、権限分離を検討します。加えて、秘密情報管理や依存モジュール管理、監査ログ、バックアップ暗号化も含めて設計します。

Webアプリの対策は、公的指針の安全なウェブサイトの作り方も参考にし、業務の法令要件とあわせて確かめます。

Luaのバージョンと依存関係の固定

Lua 5.4とLuaJIT系のLua 5.1互換環境では、機能や標準ライブラリ、ネイティブ拡張、性能、互換性が違います。

  • 実行環境:エンジンの種類とバージョン、ビルド方法、利用モジュールを記録します。
  • 保守条件:ライセンスやサポート期間、アップデートの責任者を決めます。
  • 依存管理:モジュールの版を固定し、脆弱性スキャンと更新テストを定期的に行います。

入力・認証・データ・通信を一連で守る設計

APIやゲートウェイの入力値は、型や長さ、形式、許容範囲を検証します。これにより、SQLやコマンドのインジェクション、パストラバーサル、過剰なリクエストを防げます。

TLSの利用やトークンの有効期限を設け、ロール別の権限と管理者操作の監査ログも用意します。個人情報を含むログは、最小限にします。

外部サービスが止まったときに、再送するか保留するか、二重登録をどう防ぐかも、非機能要件に含めます。

平常時からの障害対応と引き継ぎの準備

監視対象は、CPU・メモリ、Lua実行時間、エラー率です。さらに、タイムアウト、キュー滞留、外部API応答時間も監視します。リクエストIDで追えないと、ゲートウェイ、Lua、業務API、DBのどこで障害が起きたかを特定できません。

月次の脆弱性確認、四半期ごとの復元テスト、担当者が不在の場合を想定した手順の確認を行います。ソースコードや設計書、設定、テストデータ、デプロイ手順は、発注者側でも保管しておきます。

Luaのシステム開発会社・ベンダーの選び方

対応言語の一覧にLuaと書かれているかだけでは判断できません。実装経験やホスト製品の運用経験、業務知識、非機能要件、保守・移管体制もあわせて確かめます。

公開されている実績でも、Luaが主要なロジックか一部のスクリプトかで適合性は変わります。そのため、実績でLuaを担当した範囲を質問します。

Luaとホスト製品の実績の具体的な確認

技術経験が合っているかは、利用した技術、Luaの担当範囲、実装と保守の体制から確かめます。

  • 経験の中身:Lua 5.4かLuaJITか、OpenResty・Kong Gateway・Tarantoolのどれを使ったかを聞きます。
  • 担当範囲:Luaが担った処理、同時実行数、遅延目標を示してもらいます。
  • 体制:匿名化した構成図や試験計画、障害対応の例、提案後も参加する技術者を見せてもらいます。

可能であれば、コードレビューや技術面談を行い、本開発と保守に参加するエンジニアの理解度も見ておきます。

業務理解とプロジェクト管理の見極め

現場の例外処理や承認経路を理解していないベンダーでは、技術力が高くても使われないシステムになりかねません。

  • 要件整理:現場担当者に質問し、業務フローとデータ項目を説明し直せるかを見ます。
  • 進行管理:課題や変更、判断を記録する会議体の有無です。
  • 発注者作業:マスタ整備やデータ提供、受入テスト、研修、切り替え判断の担当を、提案書に明記してもらいます。

契約前に定める納品物・保守・移管条件

契約後の認識違いを防ぐため、納品物、保守の条件、契約終了時の移管方法を定めておきます。

  • 納品物:Luaソースやモジュール、依存関係、設定、DB定義、API仕様を含みます。構成図や試験結果、運用・復旧手順も求めます。
  • 保守条件:受付時間、初動時間、復旧目標、対象バージョン、脆弱性対応、追加開発単価を、分けて記載します。
  • 契約終了時:データとコードを返却してもらい、別の担当者に引き継げるかを確かめて、ベンダーロックインのリスクを下げます。

▶ 詳細はこちら:Luaのシステム開発でおすすめの開発会社/ベンダー6選と選び方

ポイント

開発会社は、Luaに対応しているかだけでなく、ホスト製品の経験や業務理解、保守と移管の条件まで確かめて選びます。Luaが主要なロジックか一部のスクリプトかで、同じ実績でも適合性は変わります。

見積もりを取る際のポイントと失敗回避策

見積もりは総額だけでなく、前提や納品物、対象外の範囲、発注者作業、変更時の扱いをそろえて比べます。

業務画面の開発費だけを見ていると、ホスト製品の設定や性能試験、運用設計が後から加わることがあります。そのため、機能要件と非機能要件を分けて依頼書に記載しておきます。

依頼書に入れる代表的な業務シナリオと前提

業務の規模や例外時の条件も共有すると、各社の提案を同じ前提で比べられます。

  • 規模と負荷:利用者数や拠点数、同時実行数、ピーク時間、データ件数を書き入れます。
  • 連携と品質:連携先や許容遅延、稼働時間、目標復旧時間、保存期間を示します。
  • 業務シナリオ:認証成功や権限不足、API遅延、DB停止、再送、ルール変更承認の場面を含めます。

Luaを使う層がまだ決まっていなくても、課題と制約を書いておけば、別方式を含めた比較提案を受けられます。

複数社の見積もりの同条件での比較

要件定義、PoC、本開発、移行の各工程を、同じ区分で並べます。テスト、研修、リリース、保守も、区分をそろえて並べます。あわせて、Lua担当者の人数や、レビューや障害時の代替要員、業務責任者との連絡体制も確かめます。

3年分の初期費用や月額費用、保守、追加開発、クラウド、移行費を合算し、変更や終了の条件を含めた総保有コストで判断します。

言語ありき・機能過多・運用不足の回避

導入の目的や標準機能で足りる範囲、運用体制を事前に見直して、失敗につながる進め方を避けます。

  • 目的を明確にする:Luaを使うこと自体より、改善したい業務を定めます。
  • 標準機能を比べる:標準機能で足りる業務を、わざわざスクラッチで作らないようにします。
  • 運用も見積もる:正常系だけを試すPoCや、一人の知識、後回しの運用費に頼らない形です。

「Luaを使わない方式でも同じ成果を出せるか」「Luaで何が改善するか」を言語化し、費用、性能、保守性の優先順位を合意します。

目的がはっきりしていれば、途中で別言語や標準サービスへ切り替える判断もしやすくなります。

よくある質問(FAQ)

Luaのシステムを検討する際によくある疑問を、導入判断に必要な観点から答えます。業務や既存基盤、保守体制に応じて、自社の要件に置き換えて確かめてください。

Luaで受発注や会計の業務システムを作れますか?

作れますが、Luaだけで基幹機能全体を新規構築するより、標準SaaSや既存パッケージを中心にするほうが現実的です。

LuaはAPI連携やルール処理に限ったうえで、制度改正や帳票、権限、移行、保守人材まで含めて、効果がはっきりあるかを確かめます。

Lua 5.4とLuaJITはどちらを選べばよいですか?

既存のホスト製品や利用モジュール、互換性、性能要件、保守期間を比べて決めます。

Lua 5.4の新機能を使う場合と、LuaJIT系の既存エコシステムや実行性能を優先する場合で、候補が変わります。

代表シナリオを両環境で動かすPoCを行い、開発者の確保と将来の更新方法も含めて判断します。

Luaのシステム開発にはどのくらい費用がかかりますか?

既存APIへの小規模なプラグインやPoCは100万〜300万円、部門向けAPIやルールエンジンは300万〜800万円が予算仮説です。

複数システム連携は800万〜2,000万円程度です。さらに、高可用性や24時間運用、移行、全社基幹刷新を含めると、1,500万円以上から数千万円、1億円超まで広がります。

要件と非機能要件をそろえたうえで、見積もる必要があります。

Luaに詳しい開発会社・ベンダーはどう探せばよいですか?

対応言語だけでなく、Luaの版やホスト製品、担当範囲を確かめます。加えて、性能試験やセキュリティ、保守体制、コードの納品と移管条件も見ておきます。

業務シナリオと制約を共有し、技術面談や小規模PoCで、提案者と実装者の理解度を確かめると選びやすくなります。

まとめ

Luaのシステムは、既存のシステムや機器にAPI、認証、データ変換、ルール実行、組込み拡張を足していく使い方が基本です。Luaは、業務アプリを丸ごと担う万能な言語として使うものではありません。

そのため、軽量さや組込みやすさ、柔軟な実行が生きる箇所に、Luaの責務を絞ります。一方で、画面や基幹機能は標準サービスや別基盤と組み合わせると、導入効果と保守性のバランスを取りやすくなります。

採用判断のための、Luaの責務と代替案の比較

まず改善する業務を決めてから、標準SaaS+Lua連携、APIゲートウェイ、Luaアプリ基盤、別言語本体への限定的なLua組込みを比べます。

PoCでは、代表シナリオやピーク負荷、障害、ログ、ロールバック、版の互換性を確かめます。

費用は、小規模検証の100万〜300万円から、連携・移行・運用を含む数千万円以上まで幅があります。そのため、要件や工数、非機能要件、保守を含めた総額で判断します。

発注前に確認する5項目

提案と契約の条件をそろえるため、発注前に確かめておく項目を挙げます。

  • 実行環境:Luaのバージョンとホスト製品。
  • 責務:Luaが担当する処理と担当しない処理。
  • 非機能要件:同時実行数、可用性、復旧目標。
  • 納品物:ソースコード、設計書、テスト結果。
  • 保守・移管:保守費、脆弱性対応、将来の移管条件。

提案書と契約書に具体的に記載されていれば、技術選定、費用比較、開発会社・ベンダーの評価を同じ基準で進められます。

▼関連記事一覧
・Luaのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・Luaのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・Luaのシステム開発の見積相場や費用/コスト/値段について
・Luaのシステム開発の発注/外注/依頼/委託方法について

 

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。