為替予約管理システム開発の完全ガイド

為替予約管理システムは、外貨取引の把握から予約、決済、評価、会計処理までを一つの流れでつなぐ仕組みです。その規模は、業務範囲や連携先、必要なリアルタイム性によって、CSV中心の構成から金融機関向けの大規模な構成まで変わります。

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

為替予約管理システムの概要

為替予約管理システムは、外貨取引に伴う為替リスクと、銀行などとの予約契約を業務データで結び付けます。

予約の申込に加えて、対象取引、残高、決済、評価、会計・監査の証跡も管理します。

解決する課題

中心となる目的は、外貨建ての売上・仕入・借入・入出金予定と予約の対応関係を明確にすることです。

データを統一する：契約番号、通貨、金額、締結レート、受渡日を同じ基準で管理します。銀行、対象取引、承認履歴も、あわせて記録します。
決算を再現する：経理・財務部門が月次決算で残高と評価を確認できます。
影響を説明する：経営層が通貨別・拠点別・期間別のリスクを把握できます。

Excelで管理すると、担当者ごとに通貨の表記やレートの小数点、期日の持ち方が異なることがあります。こうした違いが原因で、予約の二重計上や、引当済みの予約を未使用として扱う誤りが生じる場合があります。

Excel管理との違い

Excelとシステムでは、履歴の追い方と、複数人で同時に更新するときの扱いが異なります。

Excel：小規模な記録には向いていますが、同時更新や予約の分割・延長・繰上げがあると、履歴の管理が難しくなります。
システム：登録から決済まで状態を分けて持ち、変更した人と変更時刻を監査ログに残せます。

ただし、正しい結果を得るには、通貨、金額、レート、評価日、ヘッジ対象の定義を先に決めておく必要があります。成功の条件は、業務用語とデータの正本を先に決め、Excelの曖昧さを新しい画面へ持ち込まないことです。

為替予約管理システムの業務フローと全体像

工程ごとの状態をつなぐと、後続の決済や会計まで追跡できます。

予約は、方針の決定から承認と締結、引当へ進み、決済と評価を経て会計処理へつながります。

予約方針の決定
承認と締結
引当
決済
評価

設計では画面の数より、各工程で増えるデータと変わっていく状態を整理することが大切です。

エクスポージャーの把握

受注、発注、請求、借入、海外子会社との取引から、将来の外貨の受取と支払を取り込みます。

取引情報：通貨、金額、発生日、決済予定日を、取引ごとに同じ基準でそろえます。取引先や拠点、部門、案件、確度も含めます。
連携方法：APIに限らず、ルールを整えたCSV取込でも転記の手間を減らせます。

項目の定義、重複チェック、取込エラーの表示、再取込のルールを決めておくと、通貨の不足や余剰が見えるようになります。そのうえで、販売管理、購買、会計、銀行のどのシステムをデータの正本にするかを決めます。

予約の締結と対象取引への引当

予約の登録から引当までは、データと承認の状態を分けて管理します。

予約情報：予約ごとに、契約番号、銀行、売買区分、通貨ペアを記録します。さらに、金額、締結レート、受渡日、手数料、約定日も残します。
承認：申請者と承認者を分け、承認済みの契約だけを正式な予約残高に含めます。
銀行照合：確認書や約定データは、契約番号を照合キーにすると不一致を見つけやすくなります。

予約と取引は一対一とは限りません。一つの予約を複数の請求に分けたり、複数の取引をまとめたりすることもあります。そのため、引当の履歴は上書きせず、マリー、期日の繰上げ・延長、取消の前後の変更を追跡できる設計にします。

決済・評価・会計への接続

決済、評価、会計の各段階では、後から結果を確認できるよう情報を残しておきます。

期日と決済：期日アラート、未使用残高、引当済み金額、実行状況を確かめ、銀行明細と照合します。
評価：評価日、レートの出所と時刻、通貨、換算方法を保存して、月次決算を後から再現できるようにします。
会計：評価差額、実現・未実現損益、手数料、振当処理の勘定科目を整理します。
ヘッジ会計：対象取引、予約との関係、指定日、レート、評価根拠を保存します。

決済データに差異があった場合は、原因と訂正した人を記録します。

会計面では、企業会計基準委員会の外貨建取引等会計処理基準を確認し、経理担当者と監査対応の要件を先に固めておく必要があります。

ポイント

各工程で増えるデータと変わっていく状態を整理し、決済や会計へ受け渡せる形になっているかで、設計の良し悪しを判断します。

為替予約管理システムの種類

事業会社の為替リスク管理と、金融機関が法人顧客に予約サービスを提供する仕組みとでは、求められる性能と責任の範囲が異なります。対象を分けて考えれば、必要以上の機能を入れたり、必要な連携を見落としたりするのを抑えられます。

事業会社向けの為替リスク管理型

輸出入や海外子会社との取引がある企業に向けて、外貨建ての債権・債務、入出金予定、社内予約、銀行予約をひとまとめに扱う型です。通貨ペアや拠点ごとのポジションを見て、予約方針に沿ったヘッジ比率を判断します。部門や案件、取引先の単位で見ることもあります。

優先する機能は、CSV・ERP取込と引当です。そのほか、未使用残高、期日アラート、会計連携も優先機能です。事業会社の場合は、少数の通貨・拠点から始め、標準機能で運用を定着させる導入が向いています。

金融機関の法人向け予約サービス型

顧客向けの画面は、利便性に加えて、約定の正確さと障害時の業務継続を中心に設計します。

顧客取引：ログイン、レート表示、予約申込・約定、取引照会を備えます。加えて、レートアラーム、権限、与信にも対応します。
業務基盤：勘定系・市場系システムと連携します。
安全対策：認証、通信の暗号化、否認防止、配信遅延、同時接続、災害対策を確かめます。

金融庁は2025年に金融分野のサイバーセキュリティガイドラインを改正しました。また、委託先や第三者サービスのリスク管理も要件に含めます（出典：金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」、2025年）。

金融市場取引・デリバティブ管理型

金融機関の資金、為替、デリバティブの取引を横断して管理する型です。

統合対象：約定やポジション、時価、リスク量を扱います。担保、決済、会計、規制報告も対象になります。
設計上の重点：商品や取引量が増えるほど、評価モデル、データ品質、連携遅延、再計算の重要性が高まります。

事業会社は、金融機関と同じ構成を採らなくても進められます。取引量、通貨・銀行・拠点数、リアルタイム性を基準にします。

そのうえで、SaaSやパッケージ、個別開発を組み合わせる方法が現実的です。ERP連携も、この組み合わせの中で考えます。

必要な機能と要件定義のポイント

取込から監査まで、業務領域ごとに要件を整理できます。

機能は画面ごとに考えるより、業務上の判断と証跡から逆算するほうが、要件の抜けを減らせます。

入力、承認、連携、計算、出力、監査の場面ごとに、誰が何を確認し、どのデータを残すかを定めておきます。この取り決めがあれば、要件の漏れを早く見つけられます。

四つの業務領域で整理する基本機能

機能要件は、取込から監査まで、業務領域の流れに沿って整理します。

取込・可視化：外貨取引や入出金予定を取り込み、エクスポージャーを表示します。
予約・承認：予約の登録と変更、取消を管理し、承認の流れも扱います。
引当・評価：残高と対象取引の引当、分割、マリー、期日変更を扱います。加えて、レートの取得と時価評価も行います。
決済・記録：決済、会計連携、レポート、監査ログを管理します。

検索では、通貨、期日、銀行、拠点を組み合わせて絞り込みます。取引先、案件、状態、予約番号でも絞り込めるようにします。

ダッシュボードには、通貨別ポジションと予約カバー率、未使用残高を表示します。さらに、直近の受渡日、承認待ち、連携エラーも並べます。

連携とデータモデル

連携先ごとに、方式だけでなく、データの扱いと停止時の運用も決めておきます。

対象と頻度：販売・購買、債権債務、会計、銀行を確認します。ERP、レート配信、認証基盤も対象で、それぞれの頻度も確かめます。
例外処理：再処理、欠損、時刻基準、通貨換算の丸め規則を定めます。
代替運用：API連携の場合でも、相手側の停止に備えて、手動取込へ切り替える運用を残しておきます。

予約契約、対象取引、引当履歴は、別々のデータとして管理します。決済とレート、評価、仕訳についても、それぞれ別に持ちます。

将来の監査や再計算に備えて、分割引当や期日変更の履歴を残しておきます。また、変更前の値と理由も記録できる構造にします。

権限・監査・セキュリティの要件

職務の分担と変更時の承認条件を明確にして、操作ミスや不正を検知できる状態を作ります。

担当を分ける：申請者、承認者、締結者、評価者、会計担当者、システム管理者を、それぞれ別の担当にします。
変更を記録する：金額、通貨、銀行、受渡日の変更には再承認を求め、取消や訂正には理由を必須にします。
権限を絞る：権限は最小限の範囲にとどめ、定期的に見直す運用を要件にします。

具体的には、多要素認証、通信と保存データの暗号化、改ざんに耐性のあるログを確認します。さらに、バックアップ、復旧目標、監視の内容も見ておきます。

金融機関向けでは、委託先からのアクセスや環境分離、脆弱性管理に加えて、インシデント報告も要件に含めます。

AIの予測や異常検知は判断支援に限ります。一方で、予約の締結や決済を確定する権限は人が持つ設計が安全です。

ポイント

要件は、入力や承認、監査の場面ごとに、誰が何を確認し、どのデータを残すかが決まっているかで判断します。業務の判断と証跡から逆算して、抜けがないかを見ます。

為替予約管理システム開発の進め方

実データで改善を確かめてから、連携範囲を広げます。

全社・全通貨・全銀行を一度に対象にせず、まず現状を洗い出し、小さく検証すると、失敗を抑えられます。

予約残高と引当の定義は部門ごとに食い違いやすいため、実データを使って早い段階で確かめます。

▶ 詳細はこちら：為替予約管理システム開発の進め方/やり方/流れや方法/手法/工程/手順

1. 現状の洗い出しと要件定義

まず、Excel台帳と銀行通知、販売・購買データを集めます。

会計仕訳と月次レポートも集め、関係者ごとの役割を確認します。

業務担当：予約登録、方針決定、承認、銀行との締結、引当確認を行う人を特定します。
決算担当：評価と仕訳を確定する人を明らかにし、必要なデータと証跡を整理します。

要件定義書には、通貨ペアや取引件数、拠点・子会社数、銀行数を書きます。

ERPの有無、更新頻度、会計処理、保存期間も記載します。

権限とRPO・RTOも定めておきます。異常系には、重複取込、レート欠損、銀行訂正を含めます。さらに、期日変更や休日受渡し、通信停止も想定しておきます。

2. 1通貨ペア・1部門でのPoC

PoCでは対象を絞って、実際の予約業務と改善効果を確かめます。

1通貨ペア・1部門で、CSV取込、予約残高、期日アラート、月次レポートを試します。
実際の予約を数件使い、登録、承認、引当、決済、評価を通します。
入力のしやすさ、経理での再現性、銀行データとの照合を確かめます。
集計時間、引当差異、入力エラー、期日確認漏れ、月次決算日数の改善を測ります。

成功かどうかは、業務上の改善が見られたかで判断します。効果が見えない場合は、機能を追加する前に、データ定義と業務ルールを見直します。

3. 連携の拡大と本番展開

PoCで確認したあと、連携範囲を段階的に広げ、本番運用へ移ります。

ERP・会計連携、銀行データ、複数通貨・拠点、海外子会社、マリー、仕訳へ対象を広げます。
各段階で移行データを検証し、旧台帳と新システムの残高が一致する期間を設けます。
切替時は、未決済予約、引当済み取引、未使用残高、評価結果を確定してから移行します。
稼働後は、利用率、エラー件数、予約方針に沿った運用を定期的に確認します。

通貨や銀行、制度が変わったときや、担当者が異動したときは、権限、マスタ、教育、手順書を更新します。

ポイント

最初から全社を対象にせず、1通貨ペア・1部門で実データを使い、業務上の改善が見えてから次の段階へ進みます。判断の目安は、効果が見えるかどうかです。

為替予約管理システム開発の費用相場と開発期間

専用サービスは公開価格が少なく、見積もりは取引量や通貨・拠点数、連携範囲によって変わります。リアルタイム性や会計、セキュリティ要件も、金額を左右します。

次の金額は、2025〜2026年の予約管理・類似業務システムの公開価格と、為替・金融システムの連携・監査要件をもとにした推定です。なお、個別案件の見積もりを保証する金額ではありません。

▶ 詳細はこちら：為替予約管理システム開発の見積相場や費用/コスト/値段について

方式別の初期費用と開発期間の目安

初期費用や月額費用、期間の目安は、方式や連携範囲によって異なります。

SaaS・パッケージとCSV：初期0〜300万円、月額5〜30万円、期間は1〜3か月が目安です。
ERP・会計・銀行連携：初期300〜1,000万円、月額・保守10〜50万円、期間は3〜6か月が目安です。
ERP拡張：テンプレートやアドオンを大きく拡張する場合は、500〜1,500万円、4〜9か月程度です。
個別開発：独自のヘッジルール、複数銀行、海外子会社、詳細監査を含むと、1,000〜3,000万円、6〜12か月程度です。

SaaSの公開料金は、通貨ペアや利用者数で分かれるほか、会計・金融機関との連携や海外子会社の管理によっても違います（出典：為替リスク管理サービスの公開料金ページ、2026年8月参照）。

金融機関向けの費用が高くなりやすい理由

顧客向けの取引と金融機関の基幹要件を含むため、開発規模が大きくなります。

必要な構成：レート配信、即時約定、与信、カバー取引、勘定系・市場系連携を含みます。
費用と期間：高可用性、災害対策、24時間監視を含むと、初期3,000万円〜1億円超、12〜24か月の場合があります。

この金額は、公開されている要件と一般的な開発規模からの推定です。接続先や可用性の水準によって、大きく変わります。

費用を抑えるには、顧客サービスと内部管理を分けて考え、既存の認証、勘定系、市場データを使える範囲を確かめます。

ただし、レートの出所や約定時刻、障害時の切替、否認防止は削らないようにします。削ると、事故の影響が大きくなります。

5年TCOでの比較

比べるときは、初期費用に加えて、5年間の導入・運用コストと見積もりの範囲も確かめます。

利用・運用費：月額、保守、クラウド、監視を含めます。レートデータや銀行・API接続、ユーザー追加も、運用費として見積もります。
継続対応費：移行、教育、制度改定、バックアップ、復旧訓練の費用も合算します。
見積もりの内訳：標準機能、追加開発、移行、テスト、稼働後支援を分けてもらいます。

初期費用が低くても、後から加わる追加課金が大きい方式もあります。たとえば、「銀行連携一式」という項目では、銀行数や形式、エラー処理、テスト回数を確かめます。

ポイント

見積もりは、初期費用に加えて5年間の導入・運用コストで比べます。方式や連携範囲で金額が大きく変わるため、同じ前提で示された見積もりかどうかを基準にします。

為替予約管理システムの開発会社/ベンダーの選び方

選ぶときは、知名度や価格に加えて、為替業務と会計・金融連携の境界を理解しているかを見ます。事業会社向けと金融機関向けでは実績が異なるため、対象範囲を伝えて、同じ前提で提案と見積もりを依頼します。

業務領域と実績の適合性

自社の業態に合う為替業務の実装経験と、導入後の対応力を見ます。

事業会社向け：外貨債権・債務、社内予約、引当、マリー、時価評価、会計の経験を見ます。
金融機関向け：外為画面やレート配信、約定の経験を確かめます。与信、カバー、勘定系接続、災害対策の経験も見ます。
導入・運用実績：導入時期と対象ユーザー、通貨数、取引量を確かめます。連携先、保守範囲、障害時の体制も見ます。
技術・制度対応：クラウド構成、API、認証、ログ、制度改定への対応が、自社の要件に合うかを見ます。公開事例は、その確認の材料として使います。

金融システム全般の実績があっても、予約管理の業務ルールまで理解しているとは限りません。

提案と見積もりの比較条件

提案依頼と見積もりの前提をそろえておくと、機能、費用、契約条件を比べられます。

業務条件：通貨ペア、年間件数、拠点・子会社数、銀行数、取込方式、更新頻度を示します。
必要要件：分割・延長・マリー、評価レート、会計を示します。承認、権限、監査ログ、BCPの要件も示します。
費用：初期費用、月額・保守、追加ユーザー、通貨・銀行の追加費用を比べます。
連携・導入費：API、レートデータ、環境、教育、データ移行、制度改定の費用を分けます。
契約条件：SLA、納品物、受入条件、データ返却方法を確認します。

保守時間と移行量も明記してもらいます。匿名化した台帳や取引例を渡すと、機能の差や工数の差が見えてきます。さらに、標準機能と個別開発の境界を確かめ、費用と機能の条件が明確な提案を優先します。

運用体制と責任分界

導入後の障害対応と各関係者の責任範囲を、契約前に具体化します。

障害時の分担：レート欠損、銀行接続停止、連携エラー、誤引当、期日変更への対応を定めます。
連絡・復旧：ベンダー、利用企業、銀行・データ提供元の担当範囲、連絡先、復旧手順を文書にまとめます。
金融機関の確認：第三者リスク、攻撃、業務継続、復旧訓練、報告期限を評価します。
契約前の確認：監査資料、脆弱性対応、バックアップ場所、復旧テスト頻度、担当交代時の引継ぎを確かめます。

▶ 詳細はこちら：為替予約管理システム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら：為替予約管理システム開発の発注/外注/依頼/委託方法について

ポイント

開発会社は、為替業務の実績と、障害時の責任分界を同じ前提で提案できるかで選びます。事業会社向けと金融機関向けでは実績が異なるため、対象範囲を伝えて比べます。

導入時の失敗例と2026年の最新動向

取引量が増えたり、担当者や銀行が変わったりすると、導入後に差が出てきます。そのため、失敗の要因を要件に含め、規制やセキュリティの動向に応じて運用を更新します。

よくある失敗の五つのパターン

失敗を防ぐには、記録だけで終わらせず、引当と決済、残高まで検証します。評価や権限、連携停止時の運用も対象です。

引当・決済を設計しない：予約記録だけで業務を終えてしまう。
残高定義が異なる：部門ごとの認識差を残す。
評価根拠を保存しない：レートの出所や評価時刻が分からない。
権限を広くする：承認や訂正の範囲を絞らない。
停止時の手順がない：連携停止時の手動運用を決めない。

代表的な取引で業務シナリオのテストを行います。通常の予約に加えて、分割・複数引当、取消、期日変更も実行します。さらに、レート欠損や銀行データの訂正、月次締め後の修正も試し、帳票と仕訳を再現できるかを確かめます。

セキュリティと第三者リスクへの対応

金融分野のガイドライン改正を踏まえて、組織の種類に応じた対策を開発要件に含めます。

金融機関：MFA、ゼロトラスト、委託先アクセス、脆弱性情報共有、インシデント訓練を整えます。
事業会社：外部サービスに依存する場合は、障害時の代替手段とデータ持ち出しの制御を用意します。
AI利用：予測・候補のデータ、計算根拠、信頼度、承認者を記録し、自動締結へ直結させません。

金融庁は2025年に金融分野のサイバーセキュリティガイドラインを改正しました。

2026年も、生成AIを含む脅威や第三者リスクに注目が集まっています（出典：金融庁「金融分野におけるサイバーセキュリティ対策」、2025〜2026年の公表情報）。

会計・外為報告の証跡

会計処理と外為報告では、対象や根拠を後から確認できる証跡を整えます。

ヘッジ会計：対象取引と予約の指定、方針、レート、評価、仕訳の根拠を追跡します。
外為報告：対象業務、報告者、提出時期、保存資料、抽出条件、作成者を確認します。

帳票の項目名を見たうえで、経理部門と監査資料を照らし合わせ、必要な帳票と出力時期を要件に加えます。

財務省はオンライン手続きを案内しています。ただし、すべての取引が同じ扱いになるとは限りません（出典：財務省「外為報告・届出：オンライン手続き」、2026年8月参照）。

為替予約管理システムに関するよくある質問

必要な対応は、取引量や会計方針によって変わります。そのため、下の質問に示す目安は、要件定義の段階で具体化してください。

小規模な事業会社でも為替予約管理システムは必要ですか？

取引が少なくても、期日や未使用残高の確認に時間がかかり、月次決算で差異が出ている場合は、導入の効果を見込めます。

導入は、CSV取込や予約台帳、期日アラート、残高レポートから始める方法が現実的です。

既存のERPや会計システムと連携できますか？

連携は可能です。ただし、既存システムの取引データと、為替予約側で必要な項目の粒度が合うかを確認します。APIがなくても、CSVやファイルで始められます。その場合も、重複の確認、エラーの再処理、締め、時刻と通貨の基準は決めておきます。

AIに予約締結やヘッジ判断を任せられますか？

AIは、エクスポージャー集計や異常検知、ヘッジ候補の提示、レポート作成などの判断支援に使えます。相場の予測には不確実さが伴い、予約の締結、送信、決済まで自動化すると、誤入力や説明できない判断が取引に影響します。また、利用したデータと根拠を記録し、承認者が確定するHuman-in-the-Loopを基本にします。

導入にはどのくらいの期間がかかりますか？

基本の台帳から始める構成と、複数拠点や勘定系連携を含む構成では、開発期間が異なります。

基本台帳：CSV取込と台帳・アラートを中心に始める場合は、1〜3か月です。
業務・会計連携：ERP・会計・銀行連携、承認、引当、評価を含む場合は、3〜6か月です。
広域・高可用性：複数拠点や海外子会社、リアルタイムレート、金融機関向けの可用性や勘定系連携を含むと、6〜24か月になることがあります。

期間は、要件がどこまで確定しているかと、既存の連携を再利用できるかどうかで変わります。そのため、PoCを挟んで見積もりを更新していきます。

まとめ

為替予約管理システムは、予約契約だけでなく、外貨取引から申請・承認、引当、残高、決済、評価を経て、会計と監査までをつなぐ仕組みです。

システムでつなぐことで、為替リスクの判断と、その根拠となる証跡を一か所にまとめられます。

導入判断で押さえる要点

まず、社内管理か顧客サービスかを分けます。そのうえで、通貨数や取引量、拠点・銀行数、ERP・会計連携を要件にします。リアルタイム性、権限、監査、BCPも、あわせて要件に入れます。

SaaSやパッケージ、ERP連携、個別開発を比べます。次に、連携、レートデータ、保守、制度対応を含めた5年TCOで評価します。

次に行うこと

業務ルールとシステムのずれを早く見つけるため、段階を追って展開します。

現状の洗い出し
1通貨ペアでのPoC
ERP・銀行との連携
全社への展開
運用の改善

AIは、説明できる判断支援から始めます。

予約締結や決済の確定には承認者を置くのが、2026年時点でも堅実です。

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