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

API Gatewayのシステム開発を発注・外注するなら、製品を選ぶだけでなく、認証・認可、APIの責任分界、運用体制までを要件に落とし込み、PoCから段階的に本番化することが成功の近道です。

API Gatewayは、Webアプリやスマートフォン、SaaS、社内業務システム、マイクロサービスから届くAPIリクエストを一つの入口で受け、適切なバックエンドへ振り分ける基盤です。ただし、発注時に「APIを何本つなぐか」だけを伝えると、認証方式、個人情報、ピーク時の通信量、障害時の復旧、保守の範囲が抜けて見積もりの比較が難しくなります。この記事では、発注形態の選び方、RFPと要件整理、契約形態、費用相場、委託先選定、見積書の比較方法を順番に解説します。

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

API Gatewayのシステムを発注する前に知っておきたい全体像

API Gatewayの発注は、クラウドサービスの初期設定を依頼する仕事に限定されません。外部公開API、社内API、モバイルアプリ用のBFF、オンプレミスの基幹システム連携では、求められる安全性と運用方法が異なります。まず「どの利用者が、どのデータを、どのバックエンドへ、どれほどの頻度で送るのか」を明らかにすると、委託先から同じ前提の見積もりを得やすくなります。

Gateway単体は、ルーティング、TLS終端、認証トークンの検証、レート制限、タイムアウト、ログ出力など、APIを安全に通過させる入口の役割が中心です。一方、API管理基盤は、APIの設計・公開・利用申請・分析・バージョン管理・開発者ポータルまでをライフサイクルとして管理します。社内サービス同士を数本つなぐ案件ならGateway単体で足りる場合がありますが、外部パートナーへAPIを製品として提供するなら、ポータルや利用状況分析を含むAPI管理の要件を検討します。

WAFは悪意のあるリクエストを検知・遮断する防御層、ロードバランサは通信を複数のサーバーへ分散する層、サービスメッシュはサービス間通信の可観測性や暗号化を担う層です。API GatewayはAPIの公開境界で、認証・認可、APIごとのポリシー、リクエスト変換、利用制御をまとめる位置づけになります。実際には同じクラウド上で複数の製品を組み合わせるため、RFPには「どの制御をどの製品が持つか」と「重複した制御をどちらで設定するか」を記載します。これを曖昧にすると、WAFとGatewayのレート制限が異なり、障害時の切り分けも難しくなります。

2025〜2026年は、API Gatewayを単なる入口ではなく、APIポータル、利用分析、セルフホストGateway、マルチリージョン運用と組み合わせて「APIを製品として管理する」方向が強まっています。Microsoft Learnでは、Azure API Managementのリソース上限が2026年3月以降、層ごとに段階的に更新されると案内されています（出典: Microsoft Learn「Understanding Azure API Management Service Limits」、2026年）。KubernetesのGateway APIとサービスメッシュの役割分担、複数の生成AIモデルを切り替えるAI Gatewayも、今後の拡張要件になり得ます。将来機能をすべて初期導入する必要はありませんが、APIポータルや自社環境内のGatewayが必要になったときに拡張できるかを選定条件へ含めます。

API Gatewayの発注形態はどの方法を選ぶべきですか？

発注形態は、クラウドのマネージド型を採用するか、パッケージやOSSを自社環境で運用するか、個別開発するかだけでなく、どこまでを外部へ任せるかで決まります。結論として、要件が固まっていない段階では企画・PoCを小さく委託し、標準化した後に設計・実装・運用の契約を分ける進め方が、費用と責任範囲を管理しやすい方法です。

Amazon API Gateway、Azure API Management、Google Cloud Apigeeなどのマネージド型は、基盤の冗長化やスケールを自社で構築する負担を抑えやすい選択肢です。AWSを利用中ならLambda、EKS、Cognito、WAF、CloudWatchとの統合、Microsoft環境ならEntra IDやVNetとの統合、Google CloudならAPI製品化・分析との連携を軸に比較します。ただし、マネージド型でも、認証設計、OpenAPI定義、ネットワーク接続、監視、権限設計は必要です。製品の設定代行だけを依頼すると、将来の変更を自社で行えない状態になりやすいため、IaCと運用手順の引き渡しを契約に含めます。

Kong Gateway、Nginx、Envoyなどを基礎にした自社運用型は、オンプレミス、複数クラウド、Kubernetes、独自のネットワーク境界に合わせやすい一方、パッチ適用、冗長化、監視、障害対応を自社または委託先が担います。OSSを使えばライセンス費用を抑えられる可能性がありますが、設計・運用の人件費まで含めて判断しなければ、クラウドの従量課金型より総額が高くなる場合もあります。委託先には、製品のサポート期限、プラグインの保守主体、脆弱性対応の時間、別製品へ移行する場合の設定変換方法を確認します。

外注範囲は、現状調査と構想だけ、PoC、要件定義から本番導入、24時間365日の運用監視までに分けて提示します。社内にクラウドやセキュリティの専門家がいる場合は、アーキテクチャとセキュリティ方針を自社で決め、実装・テストを委託する方法があります。反対に、既存認証やネットワークが複雑で、APIを初めて統制する場合は、RFP作成支援や設計レビューを先に依頼すると、後工程の手戻りを抑えられます。発注者が意思決定すべき事項と、委託先が成果物として納める事項を表にしておくことが重要です。

RFPと要件整理でAPI Gatewayの発注条件を固める方法

RFPは、製品名を指定する資料ではなく、達成したい業務目的と受け入れ条件を委託先へ共有する資料です。最低限、現行構成、利用者、APIの用途、接続先、環境数、ピーク負荷、セキュリティ、運用、納品物、予算と希望時期を同じ書式で書きます。API本数だけでは工数を比較できないため、APIごとの認証・データ分類・変換・エラー処理・可用性を整理すると、ベンダーの見積もり精度が上がります。

最初に、既存APIの一覧を作り、API名、業務目的、呼び出し元、バックエンド、データの種類、認証方式、廃止予定日、担当部署を記録します。社内APIだけでなく、公開済みの古いエンドポイント、テスト用URL、使われていない鍵も確認します。顧客ID、住所、連絡先、購買履歴などを扱う場合は、データ分類とマスキング方針を明記します。個人情報保護委員会の「個人情報の保護に関する法律についてのガイドライン（通則編）」は、令和6年12月に一部改正されているため、法務・情報セキュリティ担当と最新版を確認して要件へ反映します（出典: 個人情報保護委員会、2024年）。

機能要件には、ルーティングだけでなく、OAuth 2.0やOIDC、JWT、APIキー、mTLS、IP制御のどれを採用するかを書きます。さらに、1利用者または1契約先あたりのレート制限、リクエストサイズの上限、ページング、タイムアウト、リトライ、冪等性キー、レスポンス形式、エラーコード、APIバージョンの共存期間を定義します。Gatewayで共通認証を行っても、顧客IDや注文IDに対するオブジェクト単位の認可まで任せるとは限りません。Gateway、認証基盤、業務APIの責任分界をRFPに記載し、受け入れテストで確認できる形にします。

非機能要件には、平均レスポンスタイムだけでなく、ピーク時のRPS、同時接続数、可用性、RTO、RPO、ログ保持期間、監視通知の時間、バックアップ、リージョン障害時の切り替えを含めます。例えば「繁忙期に毎分何リクエストか」「レスポンスの95パーセンタイルを何秒以内にするか」「障害を何分以内に検知するか」のように書けば、負荷試験と受け入れ判定に使えます。AWSのTapestry事例では、平均で1日50万回のAPI呼び出しを処理し、ホリデーシーズンは1日150万回、ピークは毎分1万回に拡大しています（出典: AWS Tapestry事例、2026年閲覧）。自社の平常値だけでなく、繁忙期の実測値をRFPへ入れることが大切です。

API Gatewayの発注から本番稼働までの進め方

開発会社へ委託する場合は、要件定義、設計、構築、テスト、移行、運用引き継ぎを一つの工程として管理します。短期間で設定を完了させることより、設計判断の記録とテスト証跡を残すことが重要です。特に既存の基幹システムと外部APIを接続する案件では、Gatewayの設定だけでは完了せず、ネットワーク、認証、バックエンドの改修、監視、問い合わせ対応まで含めて計画します。

最初の工程では、現行APIと利用者を棚卸しし、外部公開、社内連携、モバイルBFF、オンプレミス接続などのパターンに分けます。そのうえで、OpenAPIを使ってエンドポイント、パラメータ、レスポンス、エラー形式、認証方式を契約として定義します。製品選定では、対応プロトコル、ネットワーク接続、ログと分析、APIポータル、セルフホストGateway、マルチリージョン、将来の移行可能性を比較します。要件定義の段階でPoC対象を1〜3本に絞り、実際の認証基盤とバックエンドへ接続して、想定した設計が動くことを確認します。

実装では、開発・ステージング・本番の環境を分離し、設定をコードで管理します。Gatewayの設定を画面で直接変更すると、誰がいつ何を変えたか追跡しにくくなるため、TerraformなどのIaCやCI/CDの採用を検討します。オンプレミスの基幹システムと接続する場合は、専用線やVPN、名前解決、ファイアウォール、タイムアウトの整合を事前に確認します。旧APIから新APIへ移行する場合は、同時稼働期間、利用者への告知、リクエストの変換、ロールバック、古い認証鍵の無効化までを移行計画へ含めます。

テストは、正常系だけでなく、期限切れトークン、権限不足、リプレイ、過大なペイロード、レート超過、バックエンド停止、遅延、重複送信を確認します。負荷試験では平均値だけでなく、ピークRPSとエラー率、レイテンシ、オートスケール後の挙動を測定します。セキュリティ面では、OWASP API Security Top 10 2023が挙げる認証不備、オブジェクトレベル認可の欠落、過剰なリソース消費、APIインベントリ管理不備、安全でないAPI利用などをテスト観点にします（出典: OWASP API Security Top 10、2023年）。本番は1業務または1利用者群から段階的に公開し、利用ログを確認しながら対象範囲を広げます。最後に、監視ダッシュボード、障害時の一次切り分け、設定変更、鍵のローテーション、問い合わせ窓口を引き継ぎます。

API Gateway開発で選ぶ契約形態と契約書の確認事項

契約形態は、要件の確定度と成果物の明確さで選びます。API Gatewayの案件では、企画・現状調査は準委任、仕様が固まった構築部分は請負、稼働後の監視や改善は準委任または保守契約という組み合わせが現実的です。すべてを一括請負にすると、未確定の認証・ネットワーク・既存システム改修が追加変更になりやすく、逆にすべてを時間精算にすると、予算と納期を管理しにくくなります。

請負契約は、合意した成果物を完成させ、検収する部分に向きます。OpenAPI定義、Gateway設定、IaCコード、テスト仕様書、試験結果、運用手順書などを納品物として具体化し、検収条件を定めます。準委任契約は、要件整理、設計支援、技術調査、アーキテクチャレビュー、運用改善のように、作業や専門知識の提供を受ける部分に向きます。保守契約では、監視時間、一次対応、復旧目標、問い合わせの受付時間、脆弱性対応、月次報告、追加作業の単価を分けて書きます。

納品物には、ソースコードだけでなく、OpenAPI定義、Gatewayのポリシー、IaC、CI/CD設定、環境変数の一覧、権限設計、監視設定、ログ項目、テストデータ、障害対応手順を含めます。クラウドの管理アカウントやリポジトリを誰が所有するか、契約終了時に設定・ログ・データをどの形式で返却するかも確認します。著作権の帰属、第三者OSSのライセンス、再利用可能な共通部品、秘密保持、個人データの取り扱い、再委託先、脆弱性が見つかった場合の修正責任を法務と協議します。将来別ベンダーへ移行する可能性があるなら、移行に必要な資料と協力範囲をあらかじめ定めます。

API Gatewayでは、開発中に「認証を追加したい」「ログを1年間保存したい」「別リージョンにも展開したい」といった変更が発生しやすくなります。変更管理の手続き、影響調査、見積もり、承認者、納期への影響を契約書やプロジェクト計画に記載します。さらに、Gatewayの設定不備とバックエンドの障害、クラウドサービスの障害、ネットワーク変更、利用者側の不正リクエストをどの担当が一次切り分けするかを決めます。障害対応を「別途協議」とだけ書くと、緊急時に責任の押し付け合いが起きるため、連絡先とエスカレーション時間まで具体化します。

API Gatewayのシステム開発費用相場と料金の考え方

API Gatewayの費用は、開発会社へ支払う受託費と、AWS・Azure・Google Cloudなどへ支払う製品・インフラ利用料を分けて考えます。国内のAPI Gateway単体に関する公的な横断統計は限られるため、以下の金額は、NotebookLMリサーチノートにある業務システムの相場（小規模300万〜700万円、中規模700万〜1,500万円、大規模1,500万円以上、人月単価50万〜200万円の目安）に、API連携、認証、セキュリティ、非機能要件を加味した企画段階の推定レンジです。実際の契約額を保証するものではなく、API本数、バックエンド数、環境数、ピークRPS、SLA、既存システム改修、データ移行の有無で変わります。

PoCや技術検証は、1〜3本程度のAPI、JWT認証、簡易ログ、開発環境の構築を対象に、50万〜150万円、期間は2〜6週間程度が一つの目安です。小規模な本番導入は、10本程度までのAPI、WAF、レート制限、CI/CD、監視、バックアップを含め、150万〜500万円、1〜3か月程度のレンジで考えます。複数バックエンド、社内IdPとのOIDC連携、監査ログ、障害試験、既存基幹システムとの接続を含む標準的な業務連携は、500万〜1,500万円、3〜6か月程度が企画時の推定レンジです。オンプレミスと複数クラウド、マルチリージョン、APIポータル、24時間運用、厳格なSLAまで含むエンタープライズ案件は、1,500万〜5,000万円以上、6〜12か月以上となる可能性があります。これらは調査ノートと業務システム相場を基にした推定であり、見積もりの根拠として工数と前提条件を必ず確認します。

AWSの公式料金ページでは、HTTP APIとREST APIは受信したAPI呼び出し数と転送データ量を中心に課金され、最低料金や前払いコミットメントはないと説明されています。公式例では、REST APIが月500万回、レスポンスが1回3KBの場合、API呼び出し17.50米ドル、データ転送1.29米ドル、合計18.79米ドルとされています（出典: AWS Amazon API Gateway Pricing、2026年閲覧）。ただし、Lambda、CloudWatch、WAF、PrivateLink、データ転送、キャッシュ、ログ保存は別料金です。Google Cloud ApigeeのPay-as-you-goでは、Standard API Proxyが1,000,000回あたり20米ドルから始まり、環境利用料や分析・高度なセキュリティの追加料金が設定されています（出典: Google Cloud Apigee公式ドキュメント、2026年閲覧）。Azure API ManagementはConsumptionが固定費なしのリクエスト課金、Developer・Basic・Standard・Premium系がユニットやワークスペース、自ホストGatewayなどの月額課金を基本とする構造です（出典: Microsoft Learn、2025年更新）。料金はリージョンや契約、為替、利用量で変わるため、見積書では米ドル・円の換算日とクラウド料金の前提を分けて記載します。

運用費には、クラウド利用料のほか、監視、ログ保管、脆弱性対応、証明書・鍵の更新、API利用者の追加、バージョン移行、障害対応、性能改善が含まれます。NotebookLMリサーチノートにある業務システムの目安では、年間保守費は初期開発費の15〜25%程度を予算化します。ただし、平日日中の問い合わせ対応と24時間365日の監視では必要な体制が異なるため、割合だけでなく、受付時間、月間の作業時間、緊急対応、SLA、クラウド費用の上限通知を明示します。APIの利用量が増えたときに、どのメトリクスを見て、誰がスケールやプラン変更を判断するかまで決めておくと、予算超過と性能劣化の両方を防ぎやすくなります。

委託先の選定と見積比較で確認するポイント

委託先は、知名度や単価だけでなく、API Gatewayを業務システムの境界として設計し、実装後も運用できるかで選びます。製品ベンダーと受託開発会社は役割が異なるため、AWSやMicrosoftなどの認定だけでなく、類似する認証連携、API本数、ピーク負荷、オンプレ接続、監視体制の実績を確認します。見積書は合計金額を比べるのではなく、同じRFPの前提で、作業範囲、成果物、除外事項、追加条件、保守条件を横並びにします。

候補会社には、利用したGateway製品、API本数、認証方式、ピークRPS、データセンターやクラウドの構成、テスト方法、稼働後の保守体制を、公開できる範囲で質問します。守秘義務のため社名を聞けない場合でも、規模、課題、担当範囲、成果物、障害対応の方法は確認できます。提案の場では、OpenAPIを先に作るか、設定を画面で管理するか、IaCやCI/CDをどう組み込むか、ログに個人情報を残さない方法、APIのバージョンをどう廃止するかを聞きます。質問への回答が製品機能の説明だけで、業務影響や運用担当者の作業まで具体化されない会社は、慎重に比較します。

見積書では、要件定義、基本設計、詳細設計、構築、既存システム改修、テスト、移行、ドキュメント、プロジェクト管理、運用引き継ぎを分けて記載してもらいます。API本数だけでなく、認証方式の数、バックエンド数、環境数、ネットワーク接続数、ログ保持期間、監視対象、テストケース数を工数の根拠にします。金額が低い場合は、セキュリティ診断、負荷試験、バックアップ、障害訓練、IaC、運用手順書、クラウド利用料が除外されていないか確認します。反対に高い見積もりでも、マルチリージョンや24時間対応が不要なら、段階導入で分割できる可能性があります。

API Gatewayは一度構築して終わりではなく、API追加、認証鍵の更新、脆弱性パッチ、利用量の増加、バックエンド変更、API廃止を継続的に管理します。保守会社の担当者が不在でも対応できるよう、監視アラートの意味、一次切り分け、クラウドへの問い合わせ、バックエンド担当との連携手順を文書化してもらいます。月次報告に、リクエスト数、エラー率、レイテンシ、429や5xxの発生、未使用API、権限変更、コスト推移を含めると、改善判断がしやすくなります。内製化を目指す場合は、納品時の説明会だけでなく、実際の設定変更や障害訓練を共同で行う期間を見積もりに含めます。

発注時に避けたい失敗とセキュリティ上の注意点

API Gatewayは入口を一元化できる反面、設定を誤ると複数のバックエンドへ影響が広がります。安価な構築だけを優先し、認証・認可、監視、ログのマスキング、APIインベントリ、障害対応を後回しにすると、本番稼働後に大きな改修費が発生します。発注者は「製品が機能を持っているか」ではなく、「自社の業務データと運用体制で安全に使えるか」を評価します。

ログイン済みであることと、対象データを参照・更新できることは別です。例えば、顧客Aのトークンで顧客Bの注文IDを指定しても情報が返らないこと、一般社員のトークンで管理者向け操作を実行できないことをテストします。GatewayでJWTの署名や有効期限を検証し、業務API側で顧客・注文・部署などのオブジェクト単位の認可を行う責任分界を決めます。エラーレスポンスに個人情報や内部構成を含めないこと、ログにはトークンや機密ペイロードを保存しないことも受け入れ条件へ入れます。

APIの数が増えると、誰が管理者か分からないエンドポイント、古いバージョン、テスト用の公開URL、使われていないAPIキーが残りやすくなります。APIカタログに所有部署、データ分類、利用者、公開範囲、廃止予定日、SLA、監視項目を登録し、変更申請と定期レビューを行います。OWASPは2023年版で「Improper Inventory Management」をAPIの主要リスクに含めています。発注時には、API管理画面だけでなく、棚卸しの運用ルール、廃止手順、利用状況レポートを納品してもらうことが重要です。

クラウドマネージド型は導入しやすい反面、独自ポリシーや専用の変換処理に依存すると、別クラウドや自社運用型へ移行しにくくなります。OpenAPI定義、標準的な認証、IaC、アプリ側の契約テスト、ログの共通形式を採用し、製品固有の機能を使う場合は代替案と移行コストを記録します。障害時には、Gatewayを迂回してバックエンドを直接公開するような緊急対応を避け、フェイルオーバー、通信制限、縮退運転、復旧後の再送を設計します。候補会社には、過去の障害対応例、復旧目標、連絡網、代替要員、クラウド障害時の責任範囲を質問します。

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

最後に、API Gatewayの発注・外注で特に相談されやすい質問へ回答します。費用だけでなく、製品料金、開発範囲、契約、運用までを一緒に考えると、自社に合う発注計画を立てやすくなります。

要件が固まっていない場合は、最初から本番構築を一括発注するより、現状調査とPoCを外注する方法が適しています。認証、ネットワーク、既存バックエンドへの接続を小さく検証し、成果物と前提を確認してから本番導入を発注すると、追加変更の発生を抑えやすくなります。社内に専門人材が少ない場合は、RFP作成支援や設計レビューだけを先に依頼する方法もあります。

比較可能なRFPを作成したうえで、少なくとも2〜3社へ依頼すると、価格と提案内容の差を把握しやすくなります。候補は、既存クラウドに強い会社、API管理や外部公開に強い会社、オンプレミスやマルチクラウドに強い会社など、異なるタイプを含めます。最安値を選ぶのではなく、含まれる成果物、テスト、保守、追加変更の条件をそろえ、提案の具体性と社内で運用できるかを含めて判断します。

まずAPI本数を減らすのではなく、対象業務、利用者、必要な認証、ピーク負荷、受け入れ条件を整理し、不要な機能を後続フェーズへ分けます。変動トラフィックの小規模案件では従量課金型、既存クラウドが決まっている場合は同じクラウドのマネージドサービスを選ぶと、基盤構築の工数を抑えられる可能性があります。ただし、監視、バックアップ、セキュリティ試験、運用引き継ぎを削ると将来費用が増えるため、削減対象は機能の優先度と段階導入で決めます。

成果物、検収条件、追加変更の扱い、クラウド利用料の負担、ソースコードとIaCの権利、ログとデータの返却、脆弱性対応、障害時の連絡体制、保守時間、再委託、契約終了時の移行協力を確認します。特に「設定作業は納品するが、運用手順やテスト証跡は含まない」という条件になっていないか注意します。契約形態ごとの責任範囲は法務・情報システム部門と確認し、業務影響が大きいAPIほど受け入れ条件と復旧目標を具体化します。

まとめ

API Gatewayのシステムを発注・外注するときは、製品名やAPI本数だけで比較せず、利用者、データ、認証・認可、ピーク負荷、接続先、監視、障害対応、APIの廃止までをRFPに整理します。発注形態は、要件が曖昧な企画・PoC、成果物が明確な構築、継続的な改善・監視で契約を分けると、予算と責任範囲を管理しやすくなります。

見積もりを依頼する前に、API一覧と所有部署、認証・認可、データ分類、API本数とバックエンド数、平常時とピーク時の通信量、環境数、SLA、ログ保持、テスト、納品物、保守時間、追加変更、契約終了時の移行条件を確認します。受託費とクラウド利用料を分け、費用レンジには必ず前提条件を付けます。PoCから始める場合も、本番化に必要な成果物と判断基準を決めておくと、検証がそのまま発注判断につながります。

API Gatewayの設計・開発会社を選ぶときは、既存クラウドとの親和性だけでなく、業務要件の整理、セキュリティ設計、既存システム連携、テスト、運用引き継ぎまで一気通貫で支援できるかを確認します。自社のAPIを安全に成長させるために、候補会社へRFPの前提を共有し、複数の提案を同じ基準で比較することから始めます。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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