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

Azure Functionsのシステムは、業務イベントを起点に処理を組み立て、周辺のサービスとつないで設計します。運用要件も踏まえると、拡張性と費用管理を両立しやすくなります。

できることや構成から、開発会社の選び方までを順に扱います。各テーマの詳細は、関連記事もご覧ください。

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

Azure Functionsのシステムの概要

関数の外側に保存・連携・監視の役割が広がります。

Azure Functionsは、必要な処理を実行するFaaS（Function as a Service）です。

HTTPリクエストやファイル登録を起点にできるほか、メッセージ到着や決まった時刻もきっかけになります。

サーバーの台数やOSの保守を開発者が直接管理する範囲を減らし、イベント単位で業務処理を組み立てられます。

Functionsが担う役割と周辺サービス

業務システムでは、データの保存をFunctionsだけに任せず、APIやデータベース、メッセージング、監視と組み合わせます。

データ保存と処理：HTTPで受けた注文をAzure SQLかCosmos DBへ保存し、Blob Storageのファイルは別の関数で加工します。
非同期処理と追跡：Service Busで後続の処理へ渡し、Application Insightsで実行の流れを追います。
公開・保護・配信：API Managementで公開を制御し、Key Vaultで秘密情報を保管します。Event GridやEvent Hubsで配信します。

構成は、関数の数よりも、入口から引き継ぎまでの流れで見ます。途中では、保存や非同期処理、再処理、監視が正しく働くかを確かめます。APIが正常でも、キューの滞留やDB接続数の詰まりで業務が止まる場合があります。

代表的なユースケース

注文受付から後続処理を切り離す構成や、イベントの量に合わせて処理を調整する構成で活用できます。

業務受付：注文受付APIや、通知・承認の処理。
定期・一括処理：定時集計、CSVや画像の処理。
データ連携：IoTデータ受信や基幹システム間の連携。

受注APIからService Busへ送り、別の関数で在庫確認や請求データを作る構成にすると、受付と後続処理を分けられます。また、処理インスタンスは繁忙時に増やし、夜間は実行量を抑えられます。

順次処理や承認待ち、失敗後の再開には、Durable Functionsが候補になります。自前で状態を管理するより実装しやすく、再実行や外部APIの二重呼び出しも考慮して設計します。

Azure Functionsでできることと苦手なこと

Functionsは、イベントを受けて短時間で終わる処理や、アクセス量が大きく変わる処理に向いています。

一方、常時接続や長時間のCPU処理が必要な場合は、別の実行基盤のほうが安定することがあります。複雑なセッション状態や細かなOS制御を扱う場合も、別の基盤が候補になります。

採用を目的にせず、業務要件に照らして適合性を判断します。

イベント処理と自動スケールに強い領域

ファイルの入稿時やキャンペーン時だけ処理量が増える業務では、イベントを受けて必要な分だけ処理する構成が有効です。

ファイル処理：Blob Storageへの画像追加を契機に、サムネイルを生成。
定時集計：毎朝、前日の売上を集計。
IoT通知：センサーの異常値を受けて通知。

関数を小さな責務に分けると、機能ごとのテストやリリースを進めやすくなります。一方で、細分化しすぎると、通信経路やログ、権限、データ整合性の管理対象が増えます。

分割の単位は、関数の短さよりも、失敗時の再開地点や一貫して更新するデータを基準に決めます。

常時稼働や重い処理の比較

次のような要件では、Functions以外の実行基盤も含めて適合性を見ます。

常時接続：WebSocket接続を長時間維持する要件。
大容量処理：巨大なファイルを一度に読み込む要件。
長時間処理：数時間にわたるCPU処理。
複雑な画面状態：状態を一つのアプリケーションで持つ要件。

比較の相手には、App Service、Container Apps、AKSがあります。仮想マシンや専用バッチ基盤も候補です。

Functionsをイベント受付や短い後続処理に限定する構成も選択肢になります。

HTTP APIであっても、Functionsが常に最適とは限りません。コールドスタートを避けたい場合や、同時接続数を確保したい場合、アプリ全体を一体でデバッグしたい場合には、常時稼働型も候補になります。

比べるときは、月額料金に加えて、障害対応や性能検証にかかる運用工数も含めます。

ポイント

イベントを受けて短時間で終わる処理や、アクセス量が大きく変わる処理ならFunctionsが候補になります。常時接続や長時間のCPU処理が中心なら、常時稼働型の基盤と比べて決めます。

Azure Functionsの種類とホスティングプランの選び方

Functionsの種類を考えるときは、処理の起点になるトリガーと、実行環境のホスティングプランを分けて考えます。

トリガーには、HTTP、Timer、Blob Storageを使えます。ほかにもQueue Storage、Service Bus、Event Grid、Event Hubsも使えます。いずれも、業務イベントを受けてデータサービスへ処理をつなぎます。

トリガーとバインディングの選び方

処理の起点と配信先に合わせて、次のようにトリガーを選びます。

同期API：HTTPトリガー。
定時処理：Timerトリガー。
ファイル到着：Blobトリガー。
順次処理：Queue StorageまたはService Bus。
複数先への大量配信：Event GridまたはEvent Hubs。

バインディングを使うと、ストレージやメッセージングの入出力を少ないコードで接続できます。

一方で、障害時の接続先エラーを細かく扱う場合や、トランザクション境界を明確にする場合は、SDKで明示的に接続する方法が適していることがあります。

簡潔さと制御性のどちらを優先するかは、処理単位で決めます。

Flex Consumption、Premium、App Serviceの使い分け

2026年時点の新規案件では、Flex Consumptionを第一候補にし、要件に応じて他のプランと比べます。

Flex Consumption：コールドスタート、メモリ、同時実行数、ネットワーク要件、Always Readyの必要性を見ます。
Premium：常時稼働性能や専用リソースが必要な場合の選択肢。
App Service：既存のApp Service環境と統合する場合の選択肢。

Flex Consumptionでは、従量実行とAlways Readyを組み合わせ、応答性とコストを調整できます。

既存のLinux Consumptionプランは、2025年9月30日以降に新機能が追加されず、2028年9月30日にホスティング終了予定です（出典: Azure Functionsのホスティング移行ガイド、2026年8月確認）。

既存アプリを変換するより、新しいFunction Appを作って再デプロイする計画を基本にします。そのうえで、ランタイムや設定、ネットワークを確認します。監視と切り戻しの手順も決めておきます。

プラン名だけでは決めず、ピーク時の同時実行数や許容応答時間などの数値で比べます。閉域接続や可用性、予算についても、同じ基準で確認します。

ポイント

トリガーは処理の起点と配信先に合わせて選びます。ホスティングプランは、プラン名ではなくコールドスタートや同時実行数などの数値で比べます。

Azure Functionsのシステム開発の進め方

業務要件の整理から運用準備までをひと続きに捉えます。

まず、業務イベントと非機能要件を定義してから開発に入ります。サーバーレスでは処理の分け方が、データ整合性や再処理に直結します。ログ追跡や月額料金にも影響します。

企画から始め、設計や実装、テストを順に進め、リリース後の運用まで一続きの計画にします。

企画・要件定義で決めること

要件定義では、業務イベントと非機能要件を次の観点で決めます。

処理内容：「いつ、何が起きたら、どのデータをどこまで処理するか」。
業務指標：処理時間、失敗率、通知遅延、1日あたりの件数、ピーク時の毎秒件数。
復旧・データ：RTO（目標復旧時間）、RPO（目標復旧時点）、ログ期間、個人情報、保管地域。
運用条件：許容コールドスタート、月額予算、運用時間帯。
外部依存：APIや基幹システムの制限、停止時の扱い、再送方法、担当部署。

処理時間の例は、受注登録から請求データ作成までの許容時間です。Functionsを採用すること自体よりも、業務KPIの改善を目的に置きます。

イベント分解・アーキテクチャ設計

業務フローを処理の性質で分け、実行先と再実行時の動作を設計します。

同期・非同期：即時応答はHTTP関数、時間のかかる処理はService Busへ渡します。
定時・長時間：定時処理や長時間ワークフローに分け、Durable Functionsなどで後続処理を組みます。
冪等性：受付IDや処理済みキーを保存し、再配信時の二重登録を防ぎます。

同じキーで再実行した場合は、結果を再利用します。公式ガイダンスも、関数をステートレスかつ可能な限り冪等に設計するよう推奨しています（出典: Azure Functions性能・信頼性ガイダンス、2026年8月確認）。

実装・テスト・リリース

実装から検証、リリース後の運用まで、次の順に準備します。

既存チームの技能や運用体制から言語を選びます。候補は、C#、Java、JavaScript、TypeScript、Python、PowerShellなどです。
Functions Core Toolsなどでローカル開発を行い、コードはリポジトリで管理します。
CI/CDで開発・検証・本番へ同じ手順でデプロイし、設定管理とKey Vaultで接続先や秘密情報を分けます。
タイムアウト、重複メッセージ、外部API停止、DB接続数超過、権限エラー、急増トラフィックを検証します。
途中失敗からの再開を試し、Application InsightsなどでリクエストIDを引き継ぎ、入口から後続処理まで追跡します。
エラー率、処理時間、キュー滞留、実行回数、メモリ使用量、料金を監視します。
Function App単位で環境を分け、BicepやTerraformなどのIaCで再現可能にします。
コード、IaC、設定一覧、運用手順、テスト結果、再処理手順を納品物として決めます。

コードだけを納品すると、環境を再現できず、担当が代わった後の運用にも支障が出ます。

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

Azure Functionsの開発費用と月額料金の相場

Azure Functionsの費用は、受託開発費とAzure利用料金を分けて考えます。Functionsは実行量に応じて計算資源を使います。

実行分だけを見ると安く見えますが、DBやストレージ、ログには別に費用がかかります。ほかにも、メッセージングやAPI公開でも費用がかかります。ネットワークや保守も、見積に含める必要があります。

公開された標準価格が少ないため、要件の規模別に開発費の目安を見ていきます。

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

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

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

規模別の受託開発費と期間

受託開発費と期間は、要件の規模により次の幅があります。

PoC・小規模自動化：80万〜250万円、2〜6週間。
小規模業務API：300万〜800万円、2〜4か月程度。
中規模システム：800万〜2,000万円、4〜8か月程度。
エンタープライズ連携：2,000万〜5,000万円以上、6〜12か月以上の場合があります。

PoCの目安は1〜5関数で、HTTP・Timer・Blobを扱い、簡易DBと最低限のログを備えた規模です。一方、小規模APIでは、認証や5〜15関数、Azure SQLかCosmos DBを含みます。

小規模APIの目安には、外部API1〜3本、CI/CD、テストを含みます。既存認証や運用基盤を使える限定要件が、この規模に当てはまります。

中規模では、Durable FunctionsやService Busを使い、複数の業務フローを扱います。権限や監視のほか、データ移行と冗長化も含めます。

エンタープライズ連携では、基幹やオンプレミスとの連携、API Management、Private Endpointを扱います。監査ログや災害対策、24時間運用の設計を含む場合もあります。

金額は関数の数よりも、連携先や非機能要件、テストの範囲、移行量によって大きく変わります。

Azureの実行料金を計算する方法

Flex Consumptionの実行料金は、無料枠、超過単価、実行量から概算できます。

無料枠：月100,000GB秒、月250,000回（2026年8月時点）。
超過単価：0.000026米ドル/GB秒、0.40米ドル/100万回（出典: Azure Functions公式価格表、2026年8月確認）。
実行例：月1,000万回、1秒、512MBなら約500万GB秒。
無料枠を除かない概算：実行時間約130米ドル、回数約4米ドル。
円換算例：1米ドル=150円なら実行部分は約2万円。

円換算例は、計算資源と回数だけで試算したものです。StorageやApplication Insights、Log Analytics、Service Busなどは、別料金です。DBやAPI Management、Private Linkや通信量も、別に料金がかかります。

料金は、リージョンや契約、プランによって変わります。為替や割引も影響するため、見積時点の価格表で再計算します。

保守・運用費用の見方

保守・運用費は「Azure構築一式」のようにまとめず、項目別に見積もって、金額と対応範囲を比べます。

費用目安：初期開発費の年15〜25%または月15万〜80万円程度。
対応内容：ログ確認、障害対応（夜間休日の監視を含む）、更新、脆弱性対応、上限アラート、再処理支援。
見積項目：Function Appや周辺サービス、認証、CI/CD、テスト、移行、運用。
試算条件：月間イベント数、平均・最大実行時間、メモリ、保存期間。

周辺サービスには、DBやキュー、ログのほか、ネットワークも含まれます。月次のログ確認だけか、平日日中の障害対応まで含むかで、金額は変わります。対応時間は、契約書に明記します。

初期費用が安くても、ログの無制限保存や常時待機インスタンスの増加で、月額が膨らむ場合があります。

低・中・高の3パターンで試算すると、各社の見積を同じ前提で比べられます。

ポイント

受託開発費とAzure利用料金は分けて見積もり、周辺サービスや保守も含めて月額で比べます。金額は連携先や非機能要件によって大きく変わるため、前提をそろえて比べる必要があります。

セキュリティと個人情報保護で確認すべきこと

入口から接続先まで、守る領域を分けて確認できます。

サーバーの管理が不要でも、認証や権限、秘密情報の設計は欠かせません。通信やログ、依存ライブラリ、デプロイ経路も、確認対象になります。特に、匿名HTTPエンドポイントの不用意な公開は、入口から情報漏えいにつながります。

認証・権限・ネットワークと最小権限

認証と権限、秘密情報、ネットワークは、次のように設計します。

認証：利用者向けAPIはEntra IDなどと連携します。
実行権限：Managed Identityを使い、DBやストレージの権限を処理責務ごとに最小化します。
秘密情報：接続文字列やAPIキーをコードやログに置かず、Key Vaultなどで管理します。
ネットワーク：VNet統合、Private Endpoint、ファイアウォール、WAF、送信先許可リストを要件化します。

暗号化や監査ログも、あわせて検討します。閉域化すると、名前解決やDNS、デプロイ経路、監視サービスへの接続の設計が増えます。そのため、通信経路はPoCの段階で確認します。

個人情報・ログ・委託先の管理

個人情報やログ、委託先を管理するときは、データの扱いと確認事項を明確にします。

データ最小化：必要な情報だけを渡し、個人情報やトークンをログに残しません。
ログ確認：サンプリング後も例外、相関ID、処理結果が欠けないか検証します。
保管管理：保持期間、削除方法、バックアップ、アクセス記録を決めます。

個人情報保護委員会のガイドラインは、委託先の選定、契約、取扱状況の把握を含む監督を示しています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年8月確認）。

開発会社へ委託する場合は、再委託先やデータへアクセスできる担当者を確認します。あわせて、障害時のログ提出と、契約終了時のデータ削除も決めておきます。

ポイント

認証や権限、秘密情報、ネットワークは最小権限で設計します。個人情報は、委託先まで含めて取り扱いを決め、契約終了時の削除まで確認します。

Azure Functionsの開発で起きやすい失敗と対策

失敗は、コードのバグだけでなく、再実行や同時実行、依存サービスの設計不足からも起きます。ログや所有権の決め方が原因になることもあります。

PoCでは動いても、本番で二重登録や料金超過が起きることがあります。そのため、正常系のデモより、異常系の検証を重視します。

二重実行・タイムアウト・コールドスタート

関数が失敗すると、メッセージが再配信されることがあります。そのため、再処理しても同じ結果になる仕組みを用意します。

重複を防ぐ：DBの一意制約、受付ID、処理状態を使います。
失敗を隔離する：デッドレターキューを使います。
再試行を制御する：指数バックオフ、最大回数、手動再処理の条件を決めます。

リトライを増やすだけでは、停止中の外部APIに負荷をかけ続けてしまいます。そこで、再試行の条件を定めておきます。

コールドスタートについては、利用者が待てる業務か、許容応答時間が何秒かを測って判断します。

必要に応じて、Always ReadyやPremiumを選んだり、事前のウォームアップや関数の軽量化を検討したりします。

実行時間の上限に近い処理は、分割やキュー化を検討します。また、Durable Functionsや別のバッチ基盤への移行も比べます。

ログ不足・料金超過・ベンダー依存

運用の追跡性や費用管理、担当の交代に備えて、次のように整えます。

ログの追跡：受付IDや相関IDを使い、成功と失敗、再試行の履歴、最終結果を記録します。
料金監視：開発時はデイリー上限、本番は予算アラートを設定します。
使用量監視：実行回数、メモリ、ログ保存量を監視します。
引き継ぎ：コードやIaC、ビルド定義、Azure資産の所有者と、秘密情報の管理者を明確にします。

関数単位のログだけでは、業務上の1件がどの処理を通ったのか追えないことがあります。

監視のサンプリングによって必要なログが欠ける可能性もあるため、障害を再現して確認します。

特定の担当者だけがAzureポータルを操作できる状態は、引き継ぎ時のリスクになります。

Azure Functionsの開発会社・ベンダーの選び方

開発会社は、業務要件からAzureの構成までを一体で担えるかを見ます。セキュリティやテスト、運用も、同じ会社が扱えるかを確かめます。

認定に加えて、同程度のイベント量や連携先の案件実績を確かめます。個人情報やSLAを扱った実績も、あわせて確認します。

Functionsと業務システムの実績

実績を見るときは、「Azureに対応」と書かれているかだけでなく、どこまで担当したかを確認します。

処理設計：HTTPやService Busのトリガー、Durable Functions。
周辺設計：DB、認証、監視、IaC。
成果物：障害対応例、テスト項目、運用引き継ぎ資料。

公開情報が少ない場合は、匿名化した構成図やサンプルを見せてもらいます。

要件定義から保守まで同じ体制で担えるかを確かめ、担当が分かれるなら、どこまでを誰が受け持つかを明記します。問い合わせ窓口や障害時の一次対応、再委託、自社運用への知識移管計画も確認します。

見積書と提案書で確認する質問

提案を比べるときは、見積の前提と契約後の運用範囲を確認します。

開発見積：イベントやピーク件数、実行時間、データ量、連携先や環境数、テスト範囲の前提。
Azure利用料：低・標準・ピーク負荷ごとに、Functionsと周辺サービスの金額を分けます。
資産・障害対応：所有者、コードとIaCの引き渡し、上限アラート、再処理の範囲。
運用設計：Private EndpointとKey Vaultの構成、リリース後の監視時間を確認します。
契約終了：データ返却、権限回収、手順更新。

3つの負荷パターンごとにサービス別の金額を示してもらうと、後から想定外の利用料が出る事態を避けやすくなります。

PoCと本番移行の合格条件

PoCから本番へ移る前に、検証項目と合格条件を決めます。

全機能を作る前に代表的な1業務を選びます。受注APIなら、認証から受付、Service Busへの送信、後続処理までを検証します。
重複時の扱いやログ、料金を確認したうえで、外部API停止やメッセージ重複、ピーク負荷、権限エラーを試します。
応答時間の95パーセンタイル、失敗率、再処理完了時間、月額料金上限を移行基準にします。
監査ログの保存期間や復旧テスト結果も基準に加え、撤退基準を合意します。

条件を満たさないまま関数を増やすと、後の移行費用が膨らむ可能性があります。

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

ポイント

開発会社は、要件定義から保守までの担当範囲が一社で完結するかで比べます。実績や見積の前提も、その範囲に合うかをあわせて見ます。

Azure Functionsのシステムに関するよくある質問

導入前によく出る疑問に答えます。料金のほか、既存システムとの関係や開発会社への依頼範囲、運用時の注意点も押さえておくと、判断材料がそろいます。

Azure Functionsならサーバー費用は無料ですか？

従量実行には無料枠が適用される場合もあります。枠を超えると実行時間と回数に課金され、ストレージやDB、ログのほか、メッセージングやネットワークにも料金がかかります。

開発費とAzure利用料を分けたうえで、周辺費用を含む月額のTCOで判断してください。

小規模な会社でもAzure Functionsのシステムを作れますか？

小規模企業でも構築はできますが、認証やデータ整合性、監視が欠かせません。再処理や料金管理も、あわせて考える必要があります。

小さなPoCのコードやIaC、テスト、手順を残しておくと、担当が代わった後も再現しやすくなります。

既存のLinux Consumptionプランはいつまで使えますか？

Linux Consumptionプランは、2025年9月30日以降に新機能が追加されず、2028年9月30日にホスティングが終了する予定です。

使い続ける場合も、ランタイムや言語バージョン、ネットワークのほか、監視や切り戻しを確認します。そのうえで、Flex Consumptionなどへの移行計画を早めに作ります。

Azure FunctionsとLogic Appsはどちらを選ぶべきですか？

処理の性質や運用方法に合わせて、次のように選びます。

Functions：独自ロジック、細かな性能制御、既存コードの再利用が中心。
Logic Apps：定型連携やワークフローを、見える形で運用したい場合。
併用：Logic Appsで業務をつなぎ、計算量の多い処理や独自ルールをFunctionsへ分けます。

処理の所有者や変更の頻度、テスト方法、月額料金を比べて決めます。

まとめ

Azure Functionsは、イベント駆動のAPIやバッチ、データ連携を構成できる基盤です。通知や長時間のワークフローにも使えます。

短い処理や、アクセス量が大きく変わる業務、Azureのほかのサービスとの連携に適しています。一方で、常時接続や重い処理では、App ServiceやContainer Apps、AKSなどと比べます。

関数数よりシステム全体での判断

採用前には、業務イベントやピーク件数、許容遅延を定義します。加えて、データ量やSLA、個人情報の扱いも決めておきます。また、再処理や月額予算も、あらかじめ把握しておきます。

開発費はPoCで80万〜250万円、小規模APIで300万〜800万円、中規模で800万〜2,000万円が目安です。

基幹連携を含む大規模案件は2,000万〜5,000万円以上です。Azure料金はDB、ログ、ネットワークまで含めて試算します。

小さな検証から運用できる形の本番移行

本番へ移す際は、技術面と委託範囲を整えておく必要があります。

本番前の確認：認証や最小権限、Key Vaultと閉域化、相関IDとApplication Insights、リトライと冪等性。
運用基盤：IaC、CI/CD、料金アラート。
委託条件：実績、コードとIaCの所有権、障害責任、再委託、運用引き継ぎを提案書と契約書に記載します。
段階展開：代表業務をPoCで検証し、合格した構成を段階的に広げます。

▼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を創業。