API Gatewayのシステム開発は、API棚卸し、RFPとPoC、段階構築と運用引き継ぎの順に進めると、安全性を保ったまま本番化しやすくなります。発注形態や契約、費用、委託先の選び方も、この流れに沿って考えると整理しやすくなります。
▼全体ガイドの記事
・API Gatewayのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
API Gatewayのシステムを発注する前に知っておきたい全体像
外部公開API、社内API、モバイルアプリ用BFF、オンプレミス連携では、安全性と運用方法が異なります。
まず、誰が、どのデータを、どの接続先へ、どれほど送るかを整理します。安全性や運用条件も、この整理をもとに見積もりに反映します。
Gateway単体とAPI管理基盤の違い
両者は、管理する範囲が違います。たとえば、社内サービスを数本つなぐ案件では、Gateway単体で足りる場合があります。
- Gateway単体：ルーティング、TLS終端、認証トークン検証、レート制限、タイムアウト、ログ出力が担当範囲です。
- API管理基盤：APIの設計・公開、利用申請、分析、バージョン管理、開発者ポータルまでを含みます。
外部パートナーへAPIを製品として提供する場合は、ポータルや利用状況の分析も要件に含めます。
WAF・ロードバランサ・サービスメッシュとの役割分担
同じクラウド上で複数の製品を組み合わせる場合は、担当する制御をRFPで明確にしておきます。
- WAF：悪意のあるリクエストの検知と遮断
- ロードバランサ：通信を複数サーバーへ分散させる仕組み
- サービスメッシュ：サービス間通信の可観測性と暗号化
- API Gateway：公開境界での認証・認可、APIポリシー、変換、利用制御
役割が曖昧なままだと、障害時の切り分けが難しくなります。たとえば、WAFとGatewayでレート制限が食い違う場合などです。
2025〜2026年には、APIポータルや利用分析と組み合わせる動きが見られます。また、セルフホストGatewayやマルチリージョン運用と組み合わせる動きもあります。
Microsoft Learnは、Azure API Managementのリソース上限を2026年3月以降、層ごとに段階更新すると案内しています（出典: Microsoft Learn「Understanding Azure API Management Service Limits」、2026年）。
KubernetesのGateway APIとサービスメッシュの分担や、複数の生成AIモデルを切り替えるAI Gatewayも、拡張要件になり得ます。
将来の機能は、初期導入の範囲に含めず、後から加えることもできます。そのため、ポータルや自社環境内Gatewayが必要になったときに拡張できるかを、選定条件にします。
API Gatewayの発注形態の選び方
発注形態は、基盤の方式と外注範囲の両面から決めます。たとえば、要件がまだ固まらない段階では、企画やPoCを小さく委託します。
標準化が進んだら、設計・実装・運用を分けて契約します。そうすると、費用と責任範囲を管理しやすくなります。
クラウドマネージド型の委託
マネージド型は、基盤の冗長化やスケールを自社で構築する負担を抑えやすい点が特徴です。一方で、設計や運用の引き継ぎは欠かせません。
- AWS：Lambda、EKS、Cognito、WAF、CloudWatchとの統合の可否
- Microsoft環境：Entra IDやVNetとの統合の可否
- Google Cloud：API製品化や分析との連携の範囲
主な候補は、Amazon API Gateway、Azure API Management、Google Cloud Apigeeなどです。利用中の環境との統合を軸に比べます。
設定代行だけだと、将来の変更を自社で行えない場合があります。そのため、契約には認証設計やOpenAPI、ネットワークの内容を含めます。さらに、監視と権限設計、IaC・運用手順の引き渡しも盛り込みます。
自社運用型・OSS型の選び方
自社運用型は、環境に合わせて構成を組みやすい反面、保守や障害対応を自社か委託先が担うことになります。
- 製品例：Kong Gateway、Nginx、Envoyなどを基礎にした構成
- 適合しやすい環境：オンプレミス、複数クラウド、Kubernetes、独自のネットワーク境界
- 確認事項：パッチ、冗長化、監視、障害対応のそれぞれの担当者
OSSはライセンス費用を抑えられる可能性があります。ただし、人件費を含めると、従量課金型より総額が高くなる場合もあります。
委託先には、サポート期限と脆弱性対応の時間を確認します。また、プラグインの保守主体や、別製品へ移る際の設定変換方法も聞いておく必要があります。
開発会社への外注範囲
外注範囲は、現状調査から24時間365日の運用監視までの間で区切り、社内の専門性に合わせて決めます。
- 専門家が社内にいる：方針は自社で決め、実装・テストを委託する形です。
- 認証やネットワークが複雑、API統制が初めて：RFP支援や設計レビューを先に任せる形です。
- 委託範囲：現状調査、構想、PoC、要件定義、本番導入、運用監視から選択
発注者の意思決定事項と委託先の納品物を一覧にすると、どこまでを誰が受け持つかがはっきりします。
RFPと要件整理でAPI Gatewayの発注条件を固める方法
RFPは、製品を指定するための資料ではなく、業務目的と受け入れ条件を共有するための資料です。そのうえで、APIごとの認証とデータ分類を整理します。変換やエラー処理、可用性の扱いも、同じ資料に書いておきます。
まず、現行構成と利用者、用途を示します。次に、接続先と環境数、ピーク負荷を書きます。
セキュリティと運用の条件も示します。最後に、納品物と予算、希望時期を同じ書式でまとめます。
API・利用者・データの棚卸し
棚卸しでは、APIの用途と所有者を記録します。あわせて、データの扱いも明確にしておきます。
- API情報：API名、業務目的、呼び出し元、バックエンド、認証方式、廃止予定日
- 利用状況：公開済みの古いエンドポイント、テストURL、使われていない鍵が残っていないか
- データ：顧客ID、住所、連絡先、購買履歴の分類と、マスキング方針の決定
担当部署も一覧に記録します。さらに、法務や情報セキュリティの担当と最新版を確認し、要件に反映します。
個人情報保護委員会の通則編ガイドラインは、令和6年12月に一部改正されています（出典: 個人情報保護委員会、2024年）。
機能要件に含める認証・制御・変換
要件には、認証方式と流量制御を含めます。さらに、エラー処理と責任分界も定めておきます。ただし、Gatewayで共通認証を行っても、業務データ単位の認可まで担うとは限りません。
- 認証・接続：OAuth 2.0、OIDC、JWT、APIキー、mTLS、IP制御の中から選ぶ方式
- 制御：利用者または契約先単位で決めるレート、サイズ上限、ページング、タイムアウト
- 処理仕様：リトライ、冪等性キー、レスポンス、エラーコードの定義
- バージョン：APIバージョンの共存期間と、認証・業務APIの責任分界
顧客IDや注文IDのオブジェクト認可を誰が担うかは、受け入れテストで確認できる形で書いておきます。
非機能要件と受け入れ条件の数値化
受け入れ判定に使えるよう、基準は数値で決めておきます。
- 負荷：ピークRPS、同時接続数、繁忙期の毎分リクエスト数
- 性能・可用性：平均応答、95パーセンタイルの秒数、稼働の数値
- 復旧・監視：RTO、RPO、ログ保持、通知時間、バックアップ、リージョン切替
たとえば、AWSのTapestry事例は、平均で1日50万回、繁忙期に1日150万回、ピーク毎分1万回を処理しています（出典: AWS Tapestry事例、2026年閲覧）。
自社の平常時の値だけでなく、繁忙期の実測値もRFPに入れておきます。こうした実測値は、負荷試験と受け入れ判定に役立ちます。
API Gatewayの発注から本番稼働までの進め方
発注から本番稼働までは、一連の流れとして管理します。要件定義から設計、構築、テストを経て、移行と運用引き継ぎへ進みます。
設定を急ぐより、設計判断と試験の証跡を残すことを優先します。特に基幹連携では、ネットワークと認証の計画が欠かせません。改修と監視、問い合わせ対応も計画に含めます。
企画・要件定義・基本設計
最初に、現行APIと利用者を棚卸しします。PoCでは、実環境との接続も確かめます。
- 利用形態：外部公開、社内連携、モバイルBFF、オンプレミス接続の区分
- API契約：OpenAPIで定義するエンドポイント、パラメータ、応答、エラー、認証
- 製品選定：プロトコル、接続、ログ、分析、ポータル、セルフホスト、マルチリージョン、移行性の比較
PoCの対象は1〜3本に絞ります。実際の認証基盤とバックエンドにつないで、設計どおりに動くかを確かめます。
構築・既存システム連携・データ移行
環境を分けて設定をコードで管理すると、変更の追跡や移行計画を整理できます。
- 環境：開発・ステージング・本番の分離
- 構成管理：画面からの直接変更を避けるためのIaC（Terraformなど）やCI/CDの検討
- オンプレ接続：専用線またはVPN、名前解決、ファイアウォール、タイムアウトの確認
- API移行：同時稼働、告知、変換、ロールバック、旧鍵の無効化の計画
テスト・段階リリース・運用引き継ぎ
正常系だけでなく、認証・負荷・障害時の挙動も試験します。そのうえで、利用範囲を段階的に広げていきます。
- 異常系：期限切れトークン、権限不足、リプレイ、過大ペイロード、レート超過の試験
- 障害系：バックエンド停止、遅延、重複送信の確認
- 性能：ピークRPS、エラー率、レイテンシ、スケール後の挙動の計測
- 段階公開：1業務か1利用者群から公開を始め、ログを見て範囲を広げる
試験の観点には、OWASP API Security Top 10 2023を使います（出典: OWASP API Security Top 10、2023年）。対象には、認証の不備やオブジェクト認可の欠落が含まれます。過剰なリソース消費や棚卸しの不備、安全でないAPI利用も対象です。
引き継ぎでは、監視画面の使い方と一次切り分けを文書にまとめます。設定変更と鍵の更新、問い合わせ窓口も文書に残します。
API Gateway開発で選ぶ契約形態と契約書の確認事項
契約形態は、要件がどこまで確定しているかと、成果物がどれだけ明確かで選びます。すべてを一括請負にすると、未確定の要件が追加変更になりやすくなります。一方で、時間精算だけでは、予算と納期を管理しにくくなります。
企画・現状調査は準委任、仕様が固まった構築は請負、稼働後の監視・改善は準委任か保守契約が候補になります。
請負・準委任・保守契約の使い分け
契約ごとに、成果物や作業条件を具体的に決め、検収と運用の範囲を明確にします。
- 請負：合意した成果物の完成と検収を伴う部分
- 準委任：要件整理、設計支援、調査、レビュー、運用改善が中心
- 保守：監視時間、一次対応、復旧目標、受付時間、脆弱性対応の取り決め
請負の納品物には、OpenAPI定義やGateway設定、IaCを含めます。加えて、テスト仕様と結果、運用手順書なども納品物に含め、検収条件を決めます。保守契約では、月次報告と追加作業の単価を分けて記載します。
納品物・知的財産権・引き継ぎ条件の明記
納品後に自社で運用できるよう、契約には設定と権利の扱いを明記します。また、データの返却と移行協力の条件も定めておきます。
- 納品物：コード、OpenAPI、ポリシー、IaC、CI/CD、環境変数、権限、監視、ログ、試験データ
- 管理・返却：クラウドアカウントとリポジトリの所有者、設定・ログ・データの引き渡し形式
- 権利・責任：著作権、OSS、共通部品、秘密保持、個人データ、再委託、脆弱性修正の協議
別ベンダーへ移る可能性がある場合は、移行に必要な資料と協力範囲も定めておきます。
追加変更と責任分界のルール
変更手続きと障害時の担当を決めておくと、追加作業や緊急時の混乱を抑えられます。
- 変更管理：認証追加、ログの1年間保存、別リージョン展開などが及ぼす影響の調査
- 承認：見積もり、承認者、納期への影響を契約や計画に記載
- 責任分界：Gateway、バックエンド、クラウド、ネットワーク、利用者起因それぞれの担当
連絡先とエスカレーションの時間まで、具体的に決めておきます。「別途協議」と書いたままだと、緊急時に責任が曖昧になります。
API Gatewayのシステム開発費用相場と料金の考え方
費用は、受託費と製品・インフラ利用料に分けて考えます。金額は、API本数、バックエンド、環境で変わります。さらに、ピークRPSとSLAの水準によっても変わり、既存改修や移行も金額に影響します。
国内のAPI Gateway単体について、公的に横断して比べられる統計は限られます。そのため、ここで示すのは企画段階の推定で、契約額を保証するものではありません。
推定の基礎は、業務システムの小規模が300万〜700万円、中規模が700万〜1,500万円、大規模が1,500万円以上です。また、人月単価は50万〜200万円が目安です（出典: NotebookLMリサーチノート）。
PoC・本番・エンタープライズの受託費レンジ
規模によって金額は変わり、含まれる機能と期間も異なります。
- PoC：API 1〜3本、JWT、簡易ログ、開発環境が前提で、50万〜150万円、2〜6週間程度
- 小規模本番：API 10本程度まで、WAF、制限、CI/CD、監視、バックアップが前提で、150万〜500万円、1〜3か月程度
- 標準的な業務連携：複数バックエンド、社内IdPのOIDC、監査ログ、障害試験、基幹接続が前提で、500万〜1,500万円、3〜6か月程度
- エンタープライズ：1,500万〜5,000万円以上で、6〜12か月以上かかる可能性があります
各レンジは、調査ノートと業務システムの相場を基にした推定です。見積もりでは、工数と前提条件を照合します。
このレンジは、オンプレミスや複数クラウド、マルチリージョンを含む場合の推定です。APIポータルや24時間運用、厳格なSLAも前提に含まれます。
製品利用料・クラウド費用と受託費の区分
クラウド料金は、従量か月額か、付随サービスを含むかで比べます。加えて、金額は利用量やリージョンで変わります。契約条件や為替によっても動くことがあります。
- AWS：HTTP APIとREST APIは呼び出し数と転送量が中心で、最低料金や前払いはありません
- Google Cloud Apigee：従量課金のStandard API Proxyは、100万回あたり20米ドルから
- Azure API Management：Consumptionは固定費なしで、リクエスト課金
- Azureの他の層：Developer、Basic、Standard、Premium系は、ユニットなどに応じた月額が基本
たとえば、AWS公式例では、REST API月500万回、応答1回3KBの場合、呼び出し17.50米ドルと転送1.29米ドルで計18.79米ドルです（出典: AWS Amazon API Gateway Pricing、2026年閲覧）。
Lambda、CloudWatch、WAFは別料金です。PrivateLinkや転送料も別途かかり、キャッシュやログ保存の費用も必要です。
Apigeeにも環境利用料や、分析・高度なセキュリティの追加料金があります（出典: Google Cloud Apigee公式ドキュメント、2026年閲覧）。
Azureでは、自ホストGatewayやワークスペースなどの月額も確認しておきます（出典: Microsoft Learn、2025年更新）。見積書には、換算日と料金の前提を分けて記載します。
保守・監視・改善のランニングコスト
保守費は、クラウド利用料に加えて、運用体制と作業範囲で決まります。年間費用の目安を見るだけでなく、受付時間や対応条件も確かめておきます。
- 継続作業：監視、ログ保管、脆弱性対応、証明書・鍵更新が対象
- 変更対応：利用者追加、バージョン移行、障害対応、性能改善の見積もり
- 体制：受付時間、月間作業時間、緊急対応、SLA、費用上限通知の明示
業務システムの目安では、年間保守費は初期開発費の15〜25%程度です（出典: NotebookLMリサーチノート）。ただし、平日日中と24時間365日では必要な体制が異なります。
利用量が増えたときに見る指標と、スケールやプラン変更を判断する人を決めておきます。そうすると、予算超過と性能劣化を防ぎやすくなります。
委託先の選定と見積比較で確認するポイント
知名度や単価だけでなく、業務の境界まで含めて設計し、稼働後も運用できる会社を選びます。そのうえで、認証連携やAPI本数、ピーク負荷の実績を確かめます。オンプレ接続や監視体制の実績も見ておきます。
製品ベンダーと受託開発会社では、役割が異なります。そのため、認定だけでなく、類似案件と運用体制も確認します。
類似案件の経験と技術力
回答が製品機能の説明で終わらず、業務への影響や運用担当の作業まで具体的かを見ます。
- 案件経験：Gateway、API本数、認証、ピークRPS、環境、試験、保守について質問
- 設計方法：OpenAPI、IaC、CI/CD、画面設定の管理方針
- 運用品質：個人情報をログに残さない方法と、API廃止の進め方
守秘義務で社名を聞けない場合でも、規模や課題は確認できます。担当範囲や成果物、障害対応の方法も確認できます。
見積書の工数・前提・除外事項
同じRFPをもとに、作業範囲と成果物、除外事項をそろえて比べます。そのうえで、追加条件や保守条件、金額の理由も確認します。
- 作業内訳：要件、設計、構築、改修、試験、移行、文書、管理、引き継ぎの工程ごとの工数
- 工数根拠：API、認証方式、バックエンド、環境、接続、ログ、監視、試験数ごとの内訳
- 除外事項：診断、負荷試験、バックアップ、障害訓練、IaC、手順書、利用料が含まれるか
マルチリージョンや24時間対応が要らない場合は、高額な見積もりを段階導入に分けて検討できることがあります。
選定基準としての保守体制と引き継ぎ
構築後も、API追加や鍵更新、パッチ適用を継続して管理します。利用増加やバックエンド変更、API廃止にも対応が必要です。
- 手順書：アラート、一次切り分け、クラウド問い合わせ、担当間の連携の記録
- 月次報告：リクエスト数、エラー率、レイテンシ、429・5xx、未使用API
- 内製化：設定変更や障害訓練を共同で行う期間の見積もり
月次報告に権限変更とコスト推移も含めると、改善の判断に使えます。また、担当者が不在のときにも対応できるよう、手順を残しておきます。
発注時に避けたい失敗とセキュリティ上の注意点
設定を誤ると、複数のバックエンドへ影響が及びます。そのため、安価な構築だけを優先するのではなく、業務データと運用体制で安全に使えるかを評価します。
認証・認可や監視を後回しにすると、本番後に大きな改修費が発生します。ログのマスキングやAPI棚卸し、障害対応も、早めに決めておく必要があります。
認証に加えるオブジェクト認可
ログイン済みかどうかと、対象データを操作できるかは別の問題です。そのため、認証と認可の両方を試験します。
- 顧客データ：顧客Aのトークンで顧客Bの注文IDを指定した場合に、参照・更新できないかの試験
- 管理操作：一般社員のトークンで、管理者向けの操作を実行できないかの試験
- 責任分界：Gateway側はJWTの署名と期限を検証し、業務API側は顧客・注文・部署などを認可
エラーには個人情報や内部構成を含めず、ログにはトークンや機密ペイロードを残さない条件も設けます。
APIの棚卸しと運用の設計
APIが増えると、管理者の分からないエンドポイントや古い版が残りやすくなります。公開テストURLや未使用キーも残りがちです。
- カタログ：所有部署、データ分類、利用者、公開範囲、廃止予定日、SLA、監視項目の登録
- 運用：変更申請、定期レビュー、廃止手順、利用状況報告の仕組み
- 納品：管理画面と、棚卸しの運用ルール
OWASPは2023年版で「Improper Inventory Management」をAPIの主要リスクに含めています。
ベンダーロックインと障害時の継続性
クラウドマネージド型は導入しやすい一方で、独自機能への依存は移行を難しくします。また、障害時にも、Gatewayを迂回してバックエンドを公開しない設計にします。
- 移行性：OpenAPI、標準認証、IaC、契約テスト、共通ログ形式の採用
- 固有機能：使う場合は、代替案と移行コストを記録
- 継続性：フェイルオーバー、通信制限、縮退運転、復旧後の再送の設計
候補会社には、障害の事例と復旧目標を質問します。連絡網や代替要員、クラウド障害時の責任範囲も聞いておきます。
API Gatewayのシステム発注でよくある質問
発注では、製品料金と開発範囲を一緒に考えます。契約と運用も、同じ流れで確認します。よくある質問を順に見ていきます。
API Gatewayの開発はどの段階で外注すべきですか？
要件が未確定なら、現状調査とPoCを先に外注し、検証の結果を見てから本番導入を発注します。そうすれば、追加変更を抑えやすくなります。
認証、ネットワーク、既存バックエンドへの接続を小さく検証し、成果物と前提を確かめます。社内に専門人材が少ない場合は、RFP支援や設計レビューも候補になります。
API Gatewayの見積もりは何社から取ればよいですか？
比べられるRFPを用意したうえで、少なくとも2〜3社へ依頼します。そうすると、価格と提案の差を把握できます。たとえば、既存クラウドに強い会社やAPI管理・外部公開に強い会社、オンプレ・マルチクラウドに強い会社など、タイプの異なる会社を含めます。
最安値だけで決めず、成果物やテスト、保守の内容を比べます。変更条件や提案の具体性、自社で運用できるかも確認します。
API Gatewayの開発費用を安く抑える方法はありますか？
費用を抑えたいときは、API本数を先に減らすより、まず対象業務と利用者を整理します。認証やピーク負荷、受け入れ条件の整理も欠かせません。
不要な機能は後続フェーズへ分けます。そのうえで、小規模で変動トラフィックなら従量課金型、既存クラウドが決まっていれば同じクラウドのマネージド型を選ぶと、基盤の工数を抑えられる場合があります。
監視やバックアップを削ると、将来の費用が増えます。セキュリティ試験や引き継ぎも、削ると後で費用がかさみます。そのため、削減の対象は優先度と段階導入で決めます。
契約書で特に注意すべき点は何ですか？
契約書では、成果物と検収、変更の条件を確認します。費用と権利、データの扱いも見ておきます。脆弱性や障害への対応、保守、再委託、終了時の移行協力も、条件に含めます。
設定だけを納品して、運用手順や試験の証跡が含まれない条件には注意が必要です。契約形態は、法務と情報システム部門と一緒に確認します。
影響の大きいAPIほど、受け入れ条件と復旧目標を具体的に決めておきます。
まとめ
発注では、製品名やAPI本数だけでなく、利用者、データ、認証・認可を含む条件をRFPに整理します。負荷と接続先も、RFPに書いておきます。さらに、監視と障害への対応、API廃止の扱いも含めます。
企画・PoC、成果物が明確な構築、継続的な運用で契約を分けると、予算と責任範囲を管理しやすくなります。
発注前に確認する項目
見積もりの前に、APIの運用条件と契約終了時の扱いを確認しておきます。受託費とクラウド利用料は、分けて考えます。
- API・体制：一覧、所有部署、認証・認可、データ分類、バックエンドの確認
- 負荷・運用：平常とピークの通信量、環境、SLA、ログ保持、保守時間の取り決め
- 契約・費用：試験、納品、変更条件、終了時の移行、費用前提の一致
費用レンジには、必ず前提を添えます。PoCの段階でも、本番化に必要な成果物と判断基準を決めておくと、発注の判断につながります。
自社に合う委託先への相談
候補会社に、業務整理から運用引き継ぎまで支援できるかを確かめます。セキュリティや既存連携、試験も、支援の範囲に入るかを見ます。
既存クラウドとの親和性に加えて、複数の提案を同じRFP基準で比べ、自社APIを安全に育てられる委託先を選びます。
▼全体ガイドの記事
・API Gatewayのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。