LightGBMのシステム開発の発注/外注/依頼/委託方法について

LightGBMのシステムは、業務課題とデータを整理し、PoCで実現性を確かめ、本番開発と運用の条件を契約で定める順に発注すると、業務判断に活用できます。

発注形態、要件、開発の進め方、契約、費用、委託先の順に、発注側が決めることを取り上げます。

▼全体ガイドの記事
・LightGBMのシステム開発の完全ガイド

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

LightGBMのシステムを発注するときの全体像

発注の出発点は、LightGBMを導入することではなく、どの業務判断を、どのデータで、どの頻度で支援するかを決めることです。そのうえで、データの取り込みから予測結果の確認、承認や発注、アラート対応までを一連の流れとして設計します。

ライブラリ導入と業務システム開発の区別

LightGBMは、表形式データの分類・回帰・ランキングに使う勾配ブースティング決定木のフレームワークです。高速な学習や低メモリ利用が特徴です。ただ、コードを動かすだけでは業務システムにはなりません。業務システムとして動かすには、次の要素が必要です。

• データ連携：販売管理、CRM、POS、IoT、気象などのデータを集める部分
• 前処理：欠損値や外れ値の処理と、特徴量の作成
• 予測結果：学習済みモデルをAPIやバッチで呼び出し、画面や業務へつなぐ部分
• 発注成果物：データパイプライン、推論方式、権限、監査ログを含みます。手動運用、モデル更新、テスト、操作マニュアルも受け取ります。

「モデル精度を達成する」という提案では、入力データの品質や運用担当者の作業が含まれるかで、契約範囲が変わります。そこで、どこまでを契約範囲に入れるかを確認します。

向いている業務と向いていない業務の切り分け

過去の実績と正解データがそろい、複数の項目から数値や確率を推定する業務には向いています。国土交通省の空き家推定システム設計資料では、大規模で欠損値を含む複数データを扱う要件を背景に、LightGBMが採用されています（出典：国土交通省「LINKS SOMAシステム設計資料」、2026年）。

学習データがほとんどない業務、正解ラベルを定義できない業務、画像や長文の理解が中心の業務は、LightGBMが向きにくい例です。こうした業務では、最初からLightGBMに限定しないほうが安全です。適さない業務では他方式も比べ、精度に加えて、説明しやすさ、運用費、再学習のしやすさを判断材料にします。

• 活用例：需要・欠品予測、設備の異常検知、顧客の離反予測。
• 活用例：価格査定、与信の補助。
• 比較候補：ルール、移動平均、XGBoost、ランダムフォレスト、ニューラルネットワーク。

LightGBMの発注形態の選び方

発注形態は、データや業務効果の不確実性に応じて段階を分けて考えると、どこで判断すればよいかが見えてきます。社内にデータサイエンティストやクラウド担当がいるかどうかも、選び方に関係します。

さらに、連携する既存システムの数や、予測を人が確認するか自動で処理するかによっても、適した委託方法は変わります。

不確実性が高い場合のデータ診断とPoCからの委託

学習データの量や正解ラベルの品質が分からないときは、企画・データ診断の段階から発注します。

• 診断範囲：目的、KPI、データの期間・粒度・欠損率、個人情報の有無の洗い出し
• 方式比較：単純なルールや既存手法との比較
• 効果確認：業務KPIが改善する条件の検討
• 本番適合：現場での確認と、連携データがそろっているかの見極め

企画・データ診断は税別50万〜150万円、PoCは200万〜500万円程度が目安です。この金額はLightGBMの利用料ではなく、前処理や特徴量設計、複数モデルの比較などの人件費を含む推定レンジです。評価レポートや簡易画面の作業も含みます。

PoCの成果物には、対象データ、評価方法、未解決課題、本番化の追加条件を記します。本番化の条件まで明記しておくと、発注側は本番に進むかどうかを判断しやすくなります。

本番システムまで任せる場合の一気通貫型

予測結果を販売管理や発注業務に反映するには、機械学習のほかに、データ基盤、API、バッチ、画面が必要です。さらに、権限、テスト、クラウド、運用設計も欠かせません。

本番化まで任せる場合は、必要な役割のうち、どこを自社で担うのかを確認します。

• 必要な役割：データサイエンティスト、業務側PM、データ・アプリ開発、インフラ担当。
• 分析を内製：社内でPoCを行い、外注は本番APIや監視だけに絞る形です。
• 一社へ委託：部署ごとのデータ定義の違いや業務改善も含むなら、企画から保守までを一社にまとめる方法があります。

AWS SageMakerのサンプルは、そのまま業務システムとみなせません。そこで、データ取り込み、例外処理、権限、監査を追加要件として定めます。

スクラッチ開発とマネージド基盤の比較

発注先を選ぶときは、既存環境へどこまで合わせられるか、基盤の準備をどこまで任せるかを比べます。

• スクラッチ開発：Pythonで業務に合わせやすい一方、学習、保管、配備、監視、再学習の仕組みを自前で作る必要があります。
• マネージド基盤：AWS SageMakerは、学習・推論の環境を整えやすい基盤です。

AWS SageMakerはCPU単一・複数インスタンスの分散学習に対応します（出典：AWS「LightGBM – Amazon SageMaker AI」、2026年）。

マネージド基盤は従量課金で、トレーニング、推論、ストレージ、ログなどに費用が発生します（出典：AWS「Amazon SageMaker AIの料金」、2026年）。

発注時は、リージョン、インスタンスタイプ、学習頻度、API同時実行数、ログ保存期間を前提にして、月額の試算を依頼します。また、表形式データの一般的な規模では、GPUを前提にせず、CPU構成も比べます。

RFPと要件整理による発注範囲の決め方

RFPは、開発会社に同じ条件で提案と見積を依頼するための資料です。そこには、業務課題、対象ユーザー、入力データを書きます。さらに、予測結果を使う場面、達成したいKPI、納期、予算の考え方も明確にします。

LightGBMの採用を必須にせず、他方式との比較提案も認めておくと、技術を必要以上に固定せずに済みます。

業務目的とデータ要件の整理

予測後の業務判断と学習データの条件は、次のとおり明文化します。

• 予測の使い方：店舗・商品別の7日先販売数を毎朝出し、担当者が確認したうえで発注
• 利用条件：予測対象・単位・時点、更新頻度、利用者、利用後の行動の定義
• 業務KPI：平均絶対誤差に加えて、欠品率、廃棄率、作業時間との結び付け
• データ要件：期間と更新時期、レコード数、項目定義、欠損率、訂正履歴、ラベル
• データ管理：個人・機密情報を含むかどうかの確認

時系列業務では、データリークを防ぐため、学習・検証・テストを時系列順に分けます。項目の意味が部署ごとに違う場合は、データ辞書も発注範囲に含めます。

予測の前後までを含む機能要件

予測の前後で必要になる機能を洗い出し、発注範囲を決めます。

• データ・学習：取込元と方式、前処理、特徴量生成、学習、モデル登録。
• 推論・結果：推論APIまたはバッチ、結果表示、CSV出力、通知。
• 利用者操作：再実行、手動上書き、権限管理。

予測を発注や審査に自動で反映する場合は、閾値、承認者、差し戻し、処理失敗時の扱いを決めておきます。予測値が欠けたときにも業務が止まらないよう、代替のルールも必要です。

説明可能性が求められる場合は、SHAPなどの特徴量寄与、モデルのバージョン、入力データの期間を保存しておきます。アラートの理由を利用者が確認できれば、現場の信頼を得やすくなります。

説明値は因果関係を示すものではないため、画面の文言と利用上の注意も要件に含めます。

非機能要件とセキュリティの確認

性能、監視、機密情報の管理について、条件を決めておきます。

• 性能・可用性：応答時間、同時利用者数、バッチ時刻、可用性、復旧時間。
• 運用基盤：バックアップ、ログ保存、監視通知、環境分離。
• モデル監視：入力分布、欠損率、予測分布、正解判明後の実績精度。
• 機密データ：個人・金融・医療・取引先の機密情報について、持ち出し、匿名化、暗号化、権限、再委託、国外保管。

ドリフトを検知したあとに、再学習するか、前のモデルへ戻すか、人の判断へ切り替えるかを明記します。

2026年3月改訂の「AI事業者ガイドライン」第1.2版では、入力データの適切性や正確性などが重視されています（出典：経済産業省・総務省・IPA・AISI「AI事業者ガイドライン 第1.2版」、2026年）。LightGBMだからといって規制の対象外とは考えず、用途と影響度に応じて法務・情報セキュリティ部門と確認します。

LightGBMのシステム開発を委託する進め方

発注後は、次の段階を順に進めます。開発中にデータの問題が見つかることもあるため、要件を一度で固めきれないと想定しておきます。

1. 企画
2. 要件定義
3. PoCまたは設計
4. 実装
5. テスト
6. リリース
7. 運用

各段階で何をもって終えるか、また、どのような場合に追加の作業が発生するかは、契約とスケジュールに定めておきます。

企画・要件定義への業務責任者の参加

初回の打ち合わせには、情報システム部門と、予測結果を使う業務部門の責任者を参加させます。特に需要予測では、欠品、廃棄、担当者の作業時間のどれを減らすかで、評価や画面設計が変わります。

開発会社には、現場の判断手順や例外処理、現在のExcelや手作業まで、ヒアリングしてもらいます。成果物は、データ診断結果、業務フロー、システム構成です。加えて、画面一覧、API・バッチ一覧、評価計画、リスク一覧も受け取ります。

データが足りない場合は、収集期間を延ばす、ラベルを付ける、対象業務を絞るなどを検討します。そのうえで、短期間で価値を確かめるMVP（Minimum Viable Product）を決めておくと、予算が膨らむのを防げます。

モデル開発と業務システム実装の分離管理

モデル開発では、単純なベースラインやLightGBM、必要に応じて他のモデルを、同じデータ分割と指標で比べます。LightGBMは、leaf-wise方式により、損失を大きく改善する葉を優先して成長させます。

データが少ないと過学習しやすいため、`num_leaves`、`max_depth`、`min_data_in_leaf`、学習回数、正則化を調整します（出典：LightGBM公式「Features」、2026年）。

比較するモデルの数、評価の回数、再実験の上限は、見積書に記載してもらいます。

実装では、学習と推論の管理方法や、必要な処理方式を決めておきます。

• 処理分離：学習ジョブと推論APIを分ける構成
• モデル記録：モデル版、データ期間、パラメータ、評価結果の保存
• APIの安全性：入力検証、タイムアウト、リトライ、認証、レート制限、ログの用意
• バッチ方式：日次・週次の予測で足りるなら、常時稼働の費用と障害点を抑えやすい

テスト・リリース・運用引き継ぎの受け入れ条件

機能だけでなく、データの条件や障害時の動きもテストの対象にします。

• 機能・再現：画面やAPIの機能と、過去期間での再現
• 入力データ：未知データ、欠損、異常値での動作確認
• システム：権限と性能の確認
• 障害対応：手動運用への切り替えができるかの確認

精度の受け入れ条件は、対象期間、データ分割、指標、比較対象、適用外ケースをそろえて定めます。「正解率90％」のような単一の値で示すと、条件が伝わりにくくなります。精度が下がったときの対応も、運用テストで確かめます。

リリース前には、ソースコード、学習済みモデル、特徴量定義、IaCを受け取ります。加えて、環境設定、テスト結果、データ辞書、運用手順、障害連絡先、第三者OSS一覧も渡してもらいます。

担当者への操作説明と、再学習・ロールバックの訓練も実施します。本番初期には、開発会社と発注者が予測結果と業務KPIを確認する伴走期間を、契約に含められます。

契約形態と成果物の決め方

企画やデータ診断の不確実性と、本番システムの完成責任を同じ契約で扱うと、追加費用や責任の分かれ目があいまいになりがちです。そこで、段階ごとに契約形態と成果物を分け、発注者が判断できる時点を設けます。

要件が固まらない企画の準委任型

データ診断、PoC、初期の要件定義では、専門家の作業時間を確保する準委任型が適する場合があります。

• 成果物：レポート、実験コード、評価結果、課題一覧
• 作業範囲：作業内容と時間の上限の合意
• 進捗管理：週次進捗、実験回数、参加者、時間単価、追加承認条件。
• 発注者側：データ提供期限とレビュー責任を負う

不確実な段階で精度だけを請負の完成条件にすると、開発会社はデータ品質のリスクを価格に上乗せしたり、難しい精度目標を避けたりするおそれがあります。

レビューが遅れた場合の納期への影響も、プロジェクト計画に含めます。

完成条件が明確な本番開発の請負型

要件定義と設計が固まり、画面、API、データ連携、テスト、受け入れ条件を確定できる段階なら、請負型で納品物と金額を固定する方法があります。

モデル精度は、データの追加や季節変動によって変わります。そのため契約では、固定した学習データと評価方法による検証値、本番後の精度保証の対象外となる条件、再学習の作業範囲を分けて定めます。

成果物の権利と、将来の利用や移管の条件も、契約に定めます。

• 成果物の帰属：コード、モデル、特徴量、加工ロジックが対象です。テストデータ、クラウド設定、評価レポートも含めます。
• 第三者資産：OSSのライセンス表示と第三者ライブラリの利用条件
• 将来の運用：別会社への保守移管と学習データの再利用可否
• 既存部品：開発会社の部品に関する権利範囲の、法務との確認

責任分界と保守範囲の契約条件

予測の誤りが損害につながる業務では、最終的に判断する人、自動反映の有無、人の承認が必要かどうかを決めておきます。2026年4月公表のAI利活用の民事責任手引きは、補助・支援型AIと依拠・代替型AIを整理しています。

同手引きの目的は、開発・提供・利用に関わる関係者が責任を検討するときの予測可能性を高めることです（出典：経済産業省「AI利活用における民事責任の解釈適用に関する手引き」、2026年）。

LightGBMの場合も、用途と人の関与を前提に責任を分けます。保守契約の対象とする運用範囲も、あわせて明確にします。

• 監視・障害：監視対象、対応時間、障害重要度、問い合わせ窓口
• モデル・データ：再学習頻度、データ追加、モデル更新
• 基盤対応：脆弱性対応とクラウド費の扱い

保守費は、初期開発費の年15〜25％程度が目安となる場合があります。SLA、監視範囲、再学習回数、データ量によって変わるため、見積を比べるときは3年分を確認します。

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

LightGBMのライセンス費用と、システムの発注費用は分けて考えます。予算は、データ整備、連携先数、画面、リアルタイム性の範囲で変わります。また、セキュリティ、監視、保守の範囲でも変わります。

次の金額は、リサーチノートの業務システム相場と公開AI開発事例を、LightGBM案件に読み替えた税別の目安です。個別の見積を保証するものではありません。

段階別の費用の幅

段階ごとの税別費用と期間は、対象範囲によって次のように変わります。

• 企画・データ診断：50万〜150万円程度、2〜6週間程度。
• PoC：200万〜500万円程度、1〜3か月程度。
• 小規模本番：500万〜1,500万円程度、3〜6か月程度。連携は1〜2本。
• 中規模：1,500万〜5,000万円程度、6〜12か月程度。
• 大規模：5,000万円〜1.5億円以上となる可能性があります。

PoCには、前処理、特徴量作成、複数モデル比較、精度評価、簡易画面などを含みます。公開されたAI異常判定システムにも200万〜500万円の例がありますが、範囲が異なるため参考値にとどまります。

小規模本番は、学習・推論、管理画面、APIまたはバッチ、権限、テストを含みます。中規模は、複数部門・拠点、DWH、基幹連携、監視、再学習を含む想定です。大規模案件では、全社データ、リアルタイム連携、高可用性、移行、教育まで含む場合があります。

見積書で確認するモデル以外の費用

モデル費だけに偏らないよう、見積の作業区分をそろえて確認します。

• 要件・設計：要件定義、設計、環境構築。
• データ・モデル：データ連携、前処理、モデル開発。
• システム：アプリ実装とテスト。
• 移行・運用：移行、教育、運用設計。

業務システムの費用配分の例は、要件定義10〜12％、設計・環境22〜24％、実装48〜50％、テスト15〜17％程度です。ただし案件によって異なり、モデル開発が大半を占めるとは限りません。

データクレンジング、ラベル作成、既存システム改修、クラウド初期設定が別途かを確認します。監視画面、説明画面、セキュリティレビューも、含まれるかを確かめます。

必要な作業が除外された見積は、安く見えても、後から総額が高くなることがあります。反対に、不要な高可用性やGPUを含む見積は、過剰設計の可能性があります。

クラウド費と保守費の複数年の試算

クラウド費と保守費は、利用構成と対応範囲に応じた目安として比べます。

• 低頻度バッチ：学習・推論・保存・ログの構成で、月1万〜10万円程度になる例もあります。
• 常時稼働：API、監視、高可用性、データ増加を含めると、月10万〜50万円以上になる可能性があります。
• 保守：初期開発費の年15〜25％程度が目安です。再学習、データ定義変更、脆弱性対応、問い合わせ時間で変動します。

クラウド費は、リージョン、インスタンス、稼働時間、同時実行数によって変わるため、固定額ではありません。利用するサービスごとの前提と、停止時の費用も見積もってもらいます。

初期費用、月額クラウド費、月額保守費、追加開発単価を分けて示してもらい、1年目・2年目・3年目の総保有コストを比べます。AWSは、利用した分を支払う方式で、無料利用枠やSavings Plansなどの条件もあります。試算の前提日とリージョンも記録します（出典：AWS「Amazon SageMaker AIの料金」、2026年）。

LightGBMの委託先選定と見積比較のポイント

委託先は、LightGBMを使えるかだけでなく、データを業務システムにつなぎ、本番後も改善できるかで評価します。公開されている実績が、自社と同じ業界、データ規模、セキュリティ条件であるとは限りません。

実績の見せ方、担当者の経験、成果物、保守体制、見積の透明性は、同じ質問で比べます。

モデルと周辺システムを含む技術力の確認

モデル評価から本番運用まで、次の技術内容を説明できるかを確かめます。

• モデル評価：時系列分割、リーク防止、欠損値、カテゴリ特徴量、指標、説明可能性
• 本番運用：データ版管理、モデルレジストリ、API・バッチ、CI/CDの仕組み。監視、再学習、ロールバックも確認します。
• SageMaker：S3などの保管、IAM権限、ログ、ネットワーク、バックアップ構成
• 導入事例：業務、入力データ、監視指標、手動確認、保守担当者について尋ねる

Databricksの中古車価格査定事例では、LightGBMとAutoML、MLflow、モデル監視を組み合わせています（出典：Databricks「AUCNET中古車価格査定」事例、2023年公開）。技術名だけでなく、運用につながる実装まで確認します。

見積比較の前提と除外項目のそろえ方

提案条件と見積の前提をそろえると、会社ごとの差が見えやすくなります。

• 提案条件：期限、質問方法、データ閲覧条件、プレゼン項目
• 見積項目：作業、工数、担当者、単価、期間を揃えます。成果物、検収、前提、除外、追加単価も記載してもらいます。
• 別途作業：1社だけがデータクレンジングや本番監視を別途にしている場合は、他社にも同じ条件で再見積を依頼します。

評価軸は、業務理解、データ分析力、システム連携力、セキュリティ、管理です。さらに、保守体制、費用の透明性、コミュニケーションも見ます。また、価格を重視しすぎると、運用できない提案を選ぶおそれがあります。

PoCの評価レポートや、本番移行の判断基準が提案に含まれているかも確認します。

契約前のリスクと質問への回答の記録

契約前には、費用、精度、契約条件、責任範囲を確かめます。

• 費用・品質：データ不足時の追加費用と、目標精度に届かなかった場合の扱い
• 契約変更：仕様変更と納期遅延の条件
• 責任・委託：再委託、情報漏えい、障害時の損害の扱い
• OSS・コード：OSSの脆弱性への対応と、コードの引き渡し
• 契約終了：終了後のデータ削除条件

口頭での回答で終わらせず、提案書、議事録、契約書、仕様書のどこに反映するかを明確にします。

「AIなので精度は保証できない」とだけ説明され、評価や改善の方法も示されない場合は注意が必要です。保証しないこと自体は、直ちに問題になるわけではありません。

評価データ、指標、比較ベースライン、誤差の報告、再学習の費用と回数を定めます。根拠なく高い精度を言い切る提案にも注意します。

LightGBMのシステム発注でよくある質問

発注前によく出る疑問を、費用や期間がデータと業務範囲で変わる前提で取り上げます。

LightGBMのライセンス費用だけでシステムを作れますか？

できません。LightGBMはOSSとして利用できますが、システム化にはデータ整備、特徴量設計、モデル評価、APIやバッチの費用がかかります。さらに、画面、認証、監視、保守の費用も必要です。

ライセンス費用が小さくても、業務への組み込みと本番運用に必要な人件費やクラウド費は、別に見積もります。

LightGBMの開発は最初から本番発注すべきですか？

学習データ、正解ラベル、業務KPI、既存システムとの連携条件が明確なら、本番開発に進めます。

不確実性が高い場合は、企画・データ診断（50万〜150万円程度）とPoC（200万〜500万円程度）で実現性を確認できます。精度、業務効果、本番化の条件を確かめてから発注する方法が安全です。

PoCの成果物と本番の追加費用は、先に決めておきます。

LightGBMの予測精度は契約で保証してもらえますか？

精度を単一の数値で無条件に保証するのは難しいです。受け入れ条件は、データ期間、学習・検証の方法、対象範囲、評価指標、ベースラインを固定した検証値として定めます。

本番後は、データドリフトや季節変動を監視します。精度が下がったときの再学習、モデルの切り戻し、人手による判断への切り替えは、運用手順と保守範囲に含めます。

委託先には何を質問すればよいですか？

同じ業務やデータ規模の実績、PoCから本番への移行、評価指標とベースライン、本番後の監視内容を尋ねます。

再学習と障害対応の担当、コードとモデルの引き渡し、見積の除外項目も確認します。回答は提案書と契約書に反映し、担当者だけでなくチーム全体の体制も見ます。

まとめ

LightGBMの発注費用は、データを業務判断へつなぐ仕組み全体で考えます。OSSの利用料は、その一部にすぎません。データ診断・PoC、本番システム、運用保守と段階を分け、それぞれの成果物と継続条件を決めます。

発注前にRFPへ書く内容

RFPには、業務課題とKPI、予測対象と利用者を記載します。データの期間・粒度・欠損も、あわせて書いておきます。さらに、既存システムとの連携や、画面・API・バッチを含めます。評価指標、監視、再学習も、同じ資料に入れます。権限・監査、セキュリティの条件も示します。納期、予算、成果物、保守も明記します。

LightGBMに限定しすぎず、ベースラインや代替モデルとの比較を提案条件に含めると、目的に合う方式を選びやすくなります。

最初の一歩：データ診断と複数社への相談

発注先を比べる際は、次の条件を同じ基準で確認します。

• 評価範囲：精度、連携、使いやすさ、説明。監視、再学習、責任、3年間の総費用も含めます。
• 実績の適合：実績があっても、自社業務へ実装や保守ができるとは限らない
• 見積条件：同じRFPを複数社へ渡し、前提と除外項目をそろえる

まず業務とデータを洗い出し、企画・データ診断の範囲を相談します。

PoCの成功条件、本番化の条件、契約形態、成果物、運用体制を確かめ、予測結果を現場の判断と業務改善へつなげます。

▼全体ガイドの記事
・LightGBMのシステム開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

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