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

FATCA対応システムの発注は、委託範囲と責任を決め、発注形態と要件を整理して同じ条件で見積もると、訂正や監査にも備えられます。

委託範囲の決め方から、発注形態、RFPと契約、費用相場、開発後の運用まで順に見ていきます。

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

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

FATCA対応システムを外注する前に知っておきたい全体像

FATCAは、米国の外国口座税務コンプライアンス法に基づく制度です。金融機関は、米国人などに関係する口座情報を確認し、所定の形式で報告します。

日本では国税庁への報告が関係し、米国側へ直接報告する場合はIRSのIDESを利用します。このため、発注時には判定機能と提出経路、形式、提出担当者を一体で設計します。

FATCA対応システムに必要な機能

扱う情報と確認機能を先に見ておくと、既存システムとの連携範囲を決めやすくなります。たとえば、氏名や住所などは、勘定系、CRM、証券・投信・保険システムから取り込みます。

• 顧客データ：氏名・住所・出生地・国籍、米国TIN、法人区分、GIINの取り込み。
• 口座情報：勘定系やCRMなどから残高と所得を取り込みます。
• 米国 indicia：米国住所・出生地・電話番号、米国への送金指図の検知。
• 証明書：W-8、W-9、自己証明書の回収状況と有効期限の管理。

顧客と口座の分類、必須項目やTIN形式の検証、重複確認などが必要です。そのあとに差戻し、承認、報告ファイルの生成が続きます。さらに、提出履歴の管理、訂正・取消、ルールの版管理も含めます。

国税庁は2026年1月、FATCAXML-v2.0のversion属性を「2.0」とし、必須項目や大文字小文字に注意するよう案内しています（出典：国税庁「FATCAスキーマ記載に係る留意事項」、2026年）。

FATCAとAML・CRSの違いと連携

FATCAは国際税務と口座情報の報告、AMLはマネーロンダリングやテロ資金供与への対策です。目的も判定ルールも提出先も異なります。そのため、制度ごとに項目と証跡を定義します。

FATCAとAMLを同じ機能として発注すると、個人情報の利用目的や責任範囲が曖昧になりやすくなります。一方で、本人確認や顧客マスター、法人属性、住所変更、文書管理は共通化できる可能性があります。

専用システムの新設、既存AML・KYC基盤への追加、FATCA・CRS・CARFの共通管理を比べます。その判断では、口座数や商品数、対象国、将来の制度対応も材料になります。

発注前に決めるべきFATCA対応の範囲

ベンダーへ相談する前に、委託する業務の境界を決めておきます。境界が曖昧なままだと、XML生成だけを扱う会社と、データ補正や年次運用まで含む会社を、価格の差だけで比べてしまいます。

対象法人・口座・報告経路の確定

対象範囲と提出先を先に決めておくと、必要なデータ項目と認証方式を見積もれます。

• 対象：法人、事業部、口座種別、商品、顧客区分、対象年度の一覧。
• 報告経路：国税庁への提出か、米国側への直接報告かを決める。
• 組織範囲：グループ会社や海外拠点ごとの違い。

提出先が決まらないまま画面や連携を設計すると、後から項目や認証方式が変わり、手戻りが生じます。

IRSのIDESは、金融機関や各国税務当局がFATCAデータを交換する電子窓口です。標準XMLの送信に加えて、SFTPによる一括転送にも対応します。

送信側には暗号化と通信経路の保護が必要で、直接報告を想定する場合は、電子証明書、鍵管理、送信担当者、再送手順も要件に含めます（出典：IRS「International Data Exchange Service」、2025年更新確認）。

業務責任者とシステム責任者の分担

制度判断、顧客対応、データ連携の担当を分けておくと、委託先との責任分界がはっきりします。

• 税務・コンプライアンス：分類と報告要否の最終判断。
• 業務部門：顧客への照会と書類回収を担います。
• 情報システム：データ連携と認証の担当。

外注先が制度判断まで行うのか、それとも判断材料と機能の提供にとどまるのかは、契約前に明記しておきます。

たとえば、米国 indiciaを検知した顧客を報告対象として確定するのは、発注者側の承認者です。システムには、検知理由、参照データ、確認期限、承認履歴を表示します。

担当者の判断を無条件に自動化せず、例外案件は人が確認できるようにしておきます。そうしておくと、監査の場でも判断の過程を説明しやすくなります。

完成条件の具体化（「報告できる」から）

受入条件は、出力ファイルの有無だけでなく、抽出から訂正までを確認できる形にします。

• 抽出と検証：対象口座の漏れがなく、必須項目と文字種を検証できること。
• エラー対応：エラーの担当者への割り当て。
• 追跡：ルールの版と元データを後から追える状態。
• 報告区分：初回・訂正・取消を区別して保持できること。

数値で定めておきたいのは、サンプル件数、正常系と異常系の種類、提出ファイルの数です。さらに、過去データの訂正例と、月次・年次の処理時間も含めます。

検証データは、発注者が準備するのか、委託先が匿名化して作るのかを決めておきます。準備する主体をはっきりさせておくと、テストの遅れを防げます。

FATCA対応システムの発注形態の選び方

口座数や接続先が少なく、標準機能で足りる場合は、専門SaaSやパッケージが候補になります。また、複雑な連携や独自の業務があればSI開発が候補になり、規制対応と社内データ管理を両立させたいならハイブリッドを検討します。

どの形態でも、初期費用に加えて、制度改定、運用担当者の負荷、解約時のデータ移行も比べて選びます。

専門パッケージ・SaaSに委託する方法

候補製品の機能と国内提出への適合を確かめておくと、導入後に追加で必要になる作業を見積もれます。

• 標準機能：分類、データ補正、XML生成、提出履歴を備えた製品があります。
• 製品候補：Trans World ComplianceのCRS/FATCA One、Regnology、Wolters Kluwerが挙がっています。
• 国内要件：国税庁向け提出、FATCAXML-v2.0の版管理、日本語支援の有無。

SaaSは初期投資やインフラ運用を抑えやすい一方、発注者は保存地域とテナント分離を審査します。サブプロセッサとログ範囲も、審査の対象です。

障害時の復旧目標や契約終了時のデータ返却も見ておきます。社内のクラウド利用・委託先管理基準に合う証跡を、提案段階で出せるかどうかも大切です。

SI会社へ個別開発を委託する方法

連携要件と制度更新の体制を見て、自社に必要な個別開発の範囲を判断します。

• 適する場面：顧客マスター、勘定系、文書管理、AML・KYCと深く連携する場合。
• 利点：データ項目や承認フローを自社業務に合わせられる点。
• 拡張：グループ会社や独自商品への対応の広がり。

規制コンテンツやXML仕様の更新担当を決めておかないと、完成後の制度変更に対応できないおそれがあります。

開発力に加えて、税務専門家によるレビュー、改定の検知、更新費の見積方法を確かめます。担当が代わった後も保守できる文書も、あわせて必要です。

ハイブリッドで発注する方法

役割分担と統括者を決めておくと、外部委託と既存業務の統合を両立させやすくなります。

• 規制とXML：専門パッケージに任せる範囲。
• 顧客情報と権限：自社基盤での管理。
• 導入と連携：SI会社による設計・実装。

この分担なら、外へ出すデータを抑えつつ、制度変更への追随と既存業務との統合を図れます。

複数社が関わるため、障害の受付からデータ不整合の調査、規制判断、更新承認までを、統括者がまとめて扱えるようにします。発注者かプライムベンダーかを統括者として決め、責任分界表と連絡経路を契約書に添付します。

RFPと要件整理に入れるべき項目

RFPは、機能一覧だけでなく、目的と対象データ、制約、成果物、評価方法まで含めて示す資料です。画面数よりも、データの流れと承認根拠を中心に書きます。

対象業務・データ・連携先の具体化

規模とデータの流れを明記しておくと、ベンダーは連携の工数と対象範囲を見積もれます。

• 業務規模：法人、口座数、年間の新規・変更件数、商品区分、対象国の記載。
• 履歴：扱う過去データの年数を明記する。
• 連携先：形式、更新頻度、APIの有無、ファイル連携の時間帯。

個人番号のように、取り扱いに注意が必要な項目があるかどうかも示しておきます。

source-to-target mappingでは、顧客・口座・法人の情報を扱います。残高・所得、自己証明書・GIINも対象です。報告項目ごとに、元のシステムと変換方法、必須性を定め、欠損時の処理と確認者も決めておきます。

Wiproの公開事例では、FATCA報告属性を10系統のデータソースから統合し、4か国へ12か月で展開しました（出典：Wipro「How a large global bank simplified FATCA compliance」）。

判定・書類・報告の機能要件の切り分け

機能ごとに担当者、入力、結果、例外、保存期間を決めておくと、提案を比べやすくなります。

• 収集・判定：顧客情報、米国 indicia、分類の扱い。
• 書類：自己証明書とW-8・W-9の登録・更新を管理する。
• 報告：エラー・差戻し・承認、XML、提出履歴、訂正・取消の扱い。
• 監査：証跡の記録と保存期間の設定。

「なぜ報告対象か」を再現できることも、必須要件にします。案件ごとに、ルールの版や判定日時、住所・出生地を追跡します。補正内容と承認者、提出ファイルの識別子も、あわせて残しておきます。

非機能要件・運用要件の抜け漏れ防止

金融機関の基準と運用上の制約をそろえておくと、提案が適合しているかを判断できます。

• 性能・復旧：可用性、処理時間、同時利用者数、バックアップ、復旧目標の記載。
• 保護：暗号化、MFA、権限分離、操作ログ、保存地域を含める。
• 委託管理：再委託先と、開発環境への本番データの持ち出し。
• 障害対応：脆弱性診断、監視、インシデント報告期限の設定。

金融情報システムセンターの「金融機関等コンピュータシステムの安全対策基準・解説書（第13版）」（2025年）は、2025年3月に公表されています。改訂では、金融庁のサイバーセキュリティガイドラインやオペレーショナル・レジリエンスなどを踏まえています。

ベンダーには、自社基準への適合方法を説明してもらいます。対応しない項目がある場合は、理由と代替策をRFP回答に残します。

FATCA対応システムの契約形態と責任分界

契約は、成果物の確定度、要件変更の可能性、発注者の管理体制で選びます。FATCA案件は制度解釈やデータ品質から途中で論点が見つかるため、調査・要件定義と開発・運用を分ける方法が現実的です。

請負契約が向くケース

成果物と受入条件が固まっている範囲なら、請負で進めやすく、変更の条件も契約で明確にできます。

• 対象例：確定済みデータ項目の取り込み、定義済みエラーの検証。
• 生成物：FATCAXML-v2.0、テスト仕様書、操作マニュアル。

仕様変更に伴う追加費用や納期、受入テストの不合格基準、瑕疵対応期間は、契約書に明記しておきます。第三者製品の仕様変更は、どう扱うかも決めておきます。

「FATCA対応一式」とだけ書くと、書類回収や運用設計を含むかどうかが曖昧になります。そのため、成果物一覧を契約書に添付しておきます。

準委任契約が向くケース

調査や選定支援のように、実施する作業そのものを委託する範囲は、準委任を検討できます。

• 上流作業：現状調査、データの洗い出し、RFP作成、制度要件の整理。
• 推進作業：ベンダー選定、プロジェクト管理、運用改善。

既存データを調べるまで工数が読めない場合でも、作業と報告物を決めておけば、実態に合わせて計画を更新できます。

準委任は、成果物の完成責任を相手に一括で負わせるものとは異なります。そのため、発注者が意思決定できる体制を用意しておきます。

定例会議や課題管理表、判断期限を決めておきます。さらに、月次稼働報告、情報管理、再委託の承認手順も定め、請負部分との境界を文書にします。

運用・アウトソーシング契約の確認項目

開発契約と運用サービスの条件を分けておくと、承認者とサービス範囲をはっきりさせられます。

• 委託業務：データ補正、証明書確認、年次報告の準備、提出代行、差戻し対応。
• 規制対応：規制改定の反映と、税務判断の担当を決める。
• サービス：問い合わせ時間、SLA、障害時の代替手段の明記。

個人情報を扱う場合は、利用目的、権限、保存期間を確かめます。さらに、再委託先、監査権、事故通知期限も確認します。

契約が終わったときのデータ返却と消去、消去証明も決めておきます。委託しても発注者の責任は残るため、社内には承認と監督の仕組みを置いておきます。

FATCA対応システムの費用相場と見積の内訳

日本向けFATCA単独開発の公開価格は多くありません。そのため、以下の金額は2026年時点の概算で、予算取りのための初期目安になります。

金額は、口座数や接続先、過去データの品質によって変わります。さらに、対象法人・国、既存製品、オンプレミス要件、税務専門家の関与・保守範囲によっても動きます。

規模別の初期費用と期間の目安

規模別の費用と期間を把握しておくと、見積の条件が自社の対象範囲に合うかを判断できます。

• 限定導入：1法人・1〜2データソースなら800万〜2,000万円、4〜8か月が目安。
• 中規模：3〜10データソースやAPI連携を含み、2,000万〜6,000万円、8〜14か月程度。
• 大規模：複数法人・海外拠点の展開では6,000万〜2億円超、12〜24か月以上の可能性。

限定導入には証明書管理と分類が含まれ、XML生成・検証と手動提出も入ります。中規模では、複数商品や案件ワークフローに加えて、訂正と監査証跡も扱います。

大規模案件では、FATCAとCRS・AML連携を実装します。高可用性や権限分離も含め、データレイクと運用監視まで組み込みます。この金額は、公開価格の平均と見るより、機能と金融機関向けの要件に基づく条件付きの推定として読むのが適切です。

見積書で分けるべき費用項目

費目を分けておくと、仕様変更や不要な機能を見つけて、調整しやすくなります。

• 上流・製品：現状調査、要件定義、ライセンスまたはSaaS利用料。
• 構築：画面、ワークフロー、移行、データ補正、API・ETL連携。
• 報告機能：分類ルール、XML生成・検証、セキュリティ審査。
• 導入：テスト、教育、リリース支援。

移行費は、件数、欠損値、重複排除から、手作業の補正件数、リハーサル回数まで定めます。

報告ファイル作成費に、初回・訂正・取消、差戻し、再提出が含まれるかを確かめます。過去のMessageRefIdやDocRefIdの採番管理も、同じ費目に入るかを見ておきます。

ランニングコストと将来費用

年次費用と公開価格の適用範囲を分けて確かめておくと、総額を過小に見積もるのを防げます。

• 運用費：SaaS、規制更新、クラウド、監視、問い合わせ、年次レビュー、補正、障害対応。
• 保守費の仮置き：初期開発費の15〜25％を年間保守費とする方法があります。
• 運用予算：年300万〜3,000万円程度の予算例もあります。

金額は、口座数とサービスレベルによって変わります。公開比較サイトには、CRS/FATCA Oneの開始価格として年1,500米ドルの掲載例があります。

1ドル150円で換算すると約23万円になりますが、これを日本の金融機関向けの総額とみなすことはできません。日本語支援や連携、移行、e-Tax、監査、SLAは個別見積になるため、初年度と2年目以降を分けて確かめます。

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

委託先は、提案書にFATCAと書かれているかだけでなく、制度、データ、システム、運用を一つの責任体系で説明できるかで見ます。

製品ベンダーやSI会社、税務専門会社、運用アウトソーサーは、それぞれ得意分野が違います。そのため、自社の不足を補う組み合わせを選びます。

実績の確認（案件の条件まで）

自社と近い条件の導入実績を調べておくと、提案の再現性や体制を判断できます。

• 業種・規模：金融機関かどうか、対象口座数や業態が近いか。
• 国内対応：日本の提出方式や既存連携を含む実績の有無。
• 運用実績：年次報告、納期、体制、障害、規制改定への対応。

導入社名だけでなく、同じ規模と業態、データ品質の案件かどうかを質問します。

比較候補には、複数国連携の個別SIとしてWipro、規制税務報告製品としてRegnologyが挙がります。FATCA・CRS統合ではWolters Kluwer、規制報告基盤との統合ではNasdaq AxiomSLが候補です。

専門SaaSではTrans World Compliance、SaaSとフルサービスの比較ではLabelが候補です。日本での契約可否や価格は、個別に確認します。

見積の前提をそろえた比較

同じ比較表を使うと、価格差が対象範囲の違いによるものかを確かめられます。

• 費用条件：初期費用、保守費、規制改定費、追加接続単価の記録。
• 提案条件：範囲、前提、除外項目、成果物、納期、体制の統一。
• 評価項目：連携、専門性、監査証跡、セキュリティ、管理、継続性を見ます。

最安値の提案が、データ移行やセキュリティ審査、年次運用を除外している場合もあります。そのため、価格差の理由を質問します。

「対応可能」という回答については、標準機能か個別開発か、追加料金、提供時期、テスト担当者まで、書面で確かめます。

金融機関の委託先管理への適合

委託先の管理状況と将来の制度対応を確かめておくと、継続利用の条件を評価できます。

• データ管理：保管場所、アクセス担当、再委託先、環境分離の確認。
• 安全対策：暗号化、鍵、ログ、脆弱性診断、バックアップ、災害復旧。
• 終了・障害：返却形式、消去証明、連絡体制、復旧目標を契約に含める。

委託先が制度判断まで行うのか、税務専門家の意見を得るのかを確かめます。規制改定を検知してから、何営業日で影響を知らせるのかも質問します。

2026年2月、LabelがSovosのパートナーネットワークに加わり、FATCA・CRSのワークフローとCARF対応を連携する動向が公表されました（出典：Sovos「Sovos and Label Announce Partnership」、2026年）。

将来のCRS・CARFも対象にする場合は、製品ロードマップと追加費用を尋ねます。

発注後の開発・テスト・運用を成功させる進め方

発注後は、現状調査とデータの洗い出し、基本設計、ルール設計の順に進めます。続いて、連携・画面・XML実装、テストと移行を行い、並行稼働を経て年次運用に入ります。

発注者の業務、税務・コンプライアンス、情シスと、委託先の責任者で定例会議を開きます。判断待ちの課題をそのままにしない体制を作ります。

制度・データ・システム・運用別のテスト

テストを層ごとに設計しておくと、制度への適合から担当者の実務まで確かめられます。

• 制度・スキーマ：XMLスキーマと業務ルールへの適合。
• データ：項目変換と欠損の検証。
• システム：権限と性能の確認。
• 業務受入：担当者が案件を処理できるかを試す。

異常系として、米国 indiciaありのケースや、自己証明書の未提出、TIN不備を用意します。さらに、法人区分変更、住所変更、訂正報告、取消報告のケースも加えます。

再提出のときに、元の報告との関係を追えるかも確かめます。あわせて、国税庁やIRSの検証結果、エラーメッセージ、修正内容、再生成日時を記録しておきます。

同じデータを再処理しても同じ結果になるかどうかも、受入条件に含めます。

初回報告の並行稼働と手順訓練

切替の前に、既存の手作業や旧システムと新システムを並行稼働させておくと、差分の原因を本番前に確かめられます。

• 照合対象：抽出件数、分類、エラー件数、報告対象口座、生成ファイル。
• 差分調査：データ欠損、ルール差、担当者の補正に分けた記録。

運用担当者には、証明書不備や差戻し、期限切れを、実データに近いケースで訓練します。提出失敗、訂正、障害の対応も訓練の対象です。

障害時には、手動での準備、ベンダーへの連絡、業務責任者による承認の方法もあらかじめ用意しておくと、初年度の混乱を抑えられます。

制度改定と年次レビューの運用への組み込み

制度変更を継続して管理しておくと、リリース後も報告ルールと提出手順を保てます。

• 定期確認：国税庁・IRSのスキーマ、提出手順、IGA、対象項目の確認。
• 変更反映：改定、テスト、承認、本番反映、過去データへの影響確認を行う。
• 契約条件：通知期限、影響分析、更新費、発注者の承認手順。

年次レビューでは、未提出や差戻し、期限切れを振り返ります。加えて、データ欠損率、手作業の補正、ファイルエラー、権限変更、監査指摘も対象になります。

数値を記録しておくと、翌年度の保守費や追加開発の必要性を説明しやすくなります。そのうえで、委託先との改善協議も具体的に進められます。

よくある質問

外注では、費用だけでなく、制度判断やデータ品質も確認します。さらに、提出後の訂正、監査、将来の規制対応も含めて見ておく必要があります。よくある質問に順に答えます。

FATCA対応システムの外注費用はいくらですか？

初期費用の目安は、限定導入で800万〜2,000万円、中規模統合で2,000万〜6,000万円、大規模展開で6,000万〜2億円超です。

この金額は、データソース数や口座数、連携、移行、監査、運用を前提にした条件付きの概算です。公開価格の平均として扱うものではないため、RFPで条件をそろえて、複数社から見積もります。

FATCA対応はSaaSだけで完結できますか？

対象が限定され、既存データを標準形式で取り込めるなら、SaaSだけで運用できる可能性があります。証明書管理やXML生成も、標準機能で扱えるかを確かめます。

国税庁向けの提出、本人確認基盤、権限・監査、保存地域、手作業の補正範囲も確かめます。SaaSで不足する連携や運用は、別途委託が必要です。

RFPには最低限何を書けばよいですか？

最低限、対象法人・口座・年度と対象国を記載します。また、データ源と連携、証明書と分類も書きます。さらに、エラー処理、FATCAXML-v2.0、初回・訂正・取消の扱いも書きます。

監査証跡や権限、セキュリティも必要です。テストやSLA、規制改定への対応、データ返却も盛り込みます。加えて、責任分界と成果物、受入条件、除外項目を示しておくと、見積を比べやすくなります。

既存のAML・KYCシステムに追加するべきですか？

顧客マスター、本人確認、住所変更、文書管理を共有できる場合、既存基盤との連携や機能追加が候補です。

ただし、FATCAとAMLは目的や判定、提出先が異なります。そのため、ルールや利用目的、権限、証跡を分けたうえで、制度の最終判断者を決めてから統合します。

まとめ

発注を成功させる要点

外注では、対象法人・口座・報告経路を決め、税務・業務・情シス・委託先の責任分界も定めます。

専用製品、SaaS、SI、ハイブリッドは、連携と証明書、判定根拠まで含めて比べます。さらに、XMLや訂正、監査、年次運用も比較の対象にします。

最初に行うべきアクション

発注は、現状の整理から提案の評価まで、三つの段階で進めます。

1. 顧客・口座データと書類管理を洗い出し、報告業務のフローと既存の連携先を一枚にまとめます。
2. 機能、非機能、運用、契約終了時の返却をRFPに記載して、同じ条件で複数社へ相談する。
3. 提案後は、標準機能と個別開発、初年度と継続費、規制改定時の責任を分けて評価する。

この評価によって、導入後の追加費用や運用負担が膨らむリスクを抑えられます。

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

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