空港業務システムの費用は、対象業務の範囲、外部連携や機器の有無、24時間運用の要件で変わります。初期費用は対象範囲によって500万〜1,500万円から数十億円以上まで幅があり、範囲が広がるほど大きくなります。
空港業務システムの全体像は、次の完全ガイドでも確認できます。
▼全体ガイドの記事
・空港業務システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
空港業務システムの全体像
空港業務システムは、運航、旅客、設備、人員、請求、分析を連携させる総称です。
空港会社や航空会社、グランドハンドリング会社、管制、設備担当などが運航情報を共有する仕組みであり、2026年時点でも重要な業務基盤です。
費用を考えるときは、画面の数よりも、データを誰が更新し、どこへ配るかを先に整理します。
AODBが空港業務システムの中心になる理由
AODBはAirport Operational Databaseの略で、空港運用データベースを指し、次の役割を担います。
- 便情報：便名、機材、到着・出発の予定時刻と実績時刻、ゲート、スポットの管理
- 旅客関連：チェックインカウンターや手荷物受取場所の情報
- 共有基盤：FIDSやRMSへ渡す、基礎となる便情報
基礎となる便情報が不正確なら、FIDSやRMSの結果も不正確になります。到着予定時刻の更新元を決めておかないと、AODB、RMS、FIDSで時刻が食い違う可能性があります。
そのため、発注側は見積もり前に、正本と更新権限、時刻の基準を決めておきます。再送や重複排除の扱いも決めておくと、後工程の手戻りを抑えやすくなります。
FIDS・RMS・A-CDMなど周辺機能の範囲
周辺機能は、表示や資源配分などの目的ごとに分けて考えます。FIDSはFlight Information Display Systemの略で、RMSはResource Management Systemの略です。
- FIDS：搭乗口、遅延、到着、手荷物受取の情報を表示器やWebへ配信する機能
- RMS：便の制約に合わせた、スポット、ゲート、カウンター、ベルト、バス、スタッフの割当
- DCS・BHS：搭乗手続きや手荷物の受付、照合、仕分け、搬送の業務
A-CDMはAirport Collaborative Decision Makingの略で、空港、航空会社、ハンドラー、管制がターンアラウンド情報を共有し、出発や資源配分を協調する仕組みです。
2025年5月、SITAはボゴタのエルドラド国際空港での導入を発表しました。
ラテンアメリカ初のA-CDM導入と説明されており、効果はリアルタイムなデータ共有です。
出典はSITAの記事「El Dorado becomes first airport in Latin America to implement A-CDM system」で、発表年は2025年です。
連携範囲が広いほど、アプリ開発費に加えて関係者調整と運用設計の費用が必要になります。
空港業務システムの費用相場の目安
初期費用は対象範囲によって500万円程度から数十億円以上まで幅があります。
標準価格表はほとんどなく、ここに示す金額は、公開調達の情報をもとに規模、機器、移行の有無を加えて作った計画用の推定です。
発注時には、同じ条件のRFPを複数社へ渡して個別見積もりを取ります。
単一業務や小規模空港なら500万〜1,500万円
発注側は、単一業務の費用を対象範囲と外部接続の条件に分けて確認します。
- 対象業務：FIDSの一部刷新、設備台帳、作業モバイル、勤怠管理など
- 初期費用：500万〜1,500万円が一つの目安
- 期間：要件定義から本稼働まで3〜6カ月程度を想定
数本の連携であれば、パッケージの設定変更を中心に進められます。
端末、表示器、現地の配線工事を別契約にできれば、ソフトウェア費用を抑えられる可能性があります。
既存AODBや航空会社側と接続する場合は、データ仕様、接続試験、障害時の再送処理が必要です。このように、画面数が少なくても、外部接続の本数と受入試験の難しさで見積もりは変わります。
機器を含める場合は、台数と設置場所を確認します。電源、ネットワーク、保守部品も見積もりに関わります。
単一ターミナルのAODBやRMSなら1,500万〜5,000万円
単一ターミナルでは、開発費と導入作業を分けて見積もります。
- 対象範囲：AODB、スポット管理、ゲート割当、FIDSなど
- 初期費用：1,500万〜5,000万円程度の仮置き
- 期間：6〜12カ月程度の見込み
導入作業には、現行システムの調査や航空会社、ハンドラーとの調整が含まれます。過去データの移行、教育、並行稼働まで含めると、導入作業の割合が大きくなります。
2025年度の国土交通省航空局の入札結果では、開発要員、クラウド、保守が別案件として掲載されています（出典：国土交通省「令和7年度入札結果」、2025年）。
空港業務システムは、一括の開発費だけで考えず、開発要員、クラウド、保守を分けて予算化するのが現実的です。
複数部門の統合なら5,000万円〜3億円、ハブ級は数十億円以上
複数部門の統合では、連携範囲と可用性が費用を左右します。機器や切替条件も、費用に影響する要素です。さらに、二重化や24時間365日運用を求める場合も、費用は高くなります。
- 統合範囲：AODB、FIDS、RMSに加えて、DCS、BHS、設備、保安、請求、分析まで
- 初期費用：5,000万円〜3億円程度が計画上の目安
- 大規模化：複数空港や制御系まで含めた場合の3億円〜数十億円以上
複数ターミナルや複数空港では、表示器と現地ネットワークを含めます。
制御系との接続や段階的な切替も対象になります。
期間は12〜24カ月を見込み、ハブ級では2〜4年以上になる場合があります。
気象庁の2025年の落札情報では、東京国際空港の空港気象ドップラーレーダー業務処理ソフトウェアの設定変更と動作試験が1,782万円（税込）で契約されています。
出典は気象庁「落札情報 物品役務調達 随意契約 R7 9月分」、2025年です。
これはAODBの新規構築価格ではありませんが、既存システムの変更と機器間試験だけでも1,000万円台になる事例です。そのため、規模を小さく見積もるときほど、連携と試験の費用を別枠で確認します。
空港業務システムの費用・コストの内訳
ソフトウェア開発費だけを見ると、見積書が実態より安く見えてしまいます。見積書では、業務設計、連携、移行の作業を、ソフトウェアの外にある作業や運用と分けて確認します。クラウドから保守までの残りの項目は、次の各節で順に説明します。
要件定義・業務設計の費用
要件定義では、空港会社、航空会社、ハンドラーに加えて、保安、設備、旅客案内、請求担当から業務を聞き取ります。
- 現行整理：システム、業務フロー、データ項目、更新元の確認
- 連携整理：連携方式、端末、契約、障害時の手作業の洗い出し
- 文書化：整理した内容のRFPや要件定義書への記載
初期費用全体に占める割合は、10〜15%程度を仮置きできます。
関係者が多い案件では、その割合が高くなる場合があります。
業務設計を省くと、後から例外や閲覧者が追加されます。そのため、便の遅延や機材変更、ゲート閉鎖の場合にどう動くかを、あらかじめ確認しておきます。
欠航や通信断、臨時便も同じように扱い、通常時と異常時を同じ資料にまとめれば、追加開発を抑えられます。
外部連携・データ移行・現地試験の費用
費用が大きくなりやすいのは、外部連携と現地試験です。
- 接続先：AODB、FIDS、RMS、DCS、BHS、設備監視などとの接続
- 通信条件：データ形式、通信方式、更新頻度、認証、再送の整理
- 試験条件：接続先ごとの障害通知と動作の検証
航空会社のシステムやネットワークも接続の対象になります。
接続方式は、AIDXやSITA Type B、APIから選びます。メッセージングや専用回線も候補になります。
移行費用には、旧システムからのデータ抽出や対応付け、変換が含まれます。さらに、不要データの整理や検証、リハーサルも含まれます。
現地試験では、繁忙時間帯の同時更新や時刻の逆転、重複メッセージを再現します。
表示器の停止、地下やランプの通信断、外部システムの遅延も対象です。
価格差は、連携本数と移行対象の条件をそろえて比べます。
試験シナリオや実施回数も、同じ条件で見ます。
クラウド・サーバー・端末・表示器の費用
クラウドとオンプレミスでは、見積もる対象が異なります。クラウドは初期費用を抑えやすい一方で、月額は便数やユーザー数、保持期間によって変わり、メッセージ量やSLAによっても変わります。
- クラウド：環境構築、データベース、監視、ログ、冗長化などの見積もり
- オンプレミス：サーバーやラック、電源、空調、バックアップ装置、保守部品の確認
- 表示器：筐体、設置金具、配線、電源、施工管理、予備機まで含めた費用
クラウドでは、バックアップやネットワーク接続、セキュリティサービスも費用になります。
日立は2024年に、約600台のディスプレイを含む成田空港向けFIDS案件を公表しました。案件の内容は、最大約3.7m×3.5m×3面の大型表示を含む設計・構築・保守です。
出典は日立「空港の情報表示基盤『フライトインフォメーションシステム』事業に本格参入、成田国際空港で初採用」、2024年です。
画面の数だけでなく、設置や通信の設備まで含めると、費用の構造が変わります。
教育・切替・保守の費用
本稼働前の教育と切替作業も、初期費用に含めて確認します。
- 教育：管理者研修、操作説明、マニュアル、問い合わせ窓口の用意
- 切替：並行稼働や立会い、リハーサル、切戻し計画
- 保守：監視、障害受付、オンサイト対応、機器保守の範囲
業務を止められない空港では、夜間や閑散時間帯に切り替えます。ただし、教育や切替を削ると、本稼働後の問い合わせと手作業が増えます。
年間保守は、初期開発費の10〜15%程度を仮置きすることがあります。
実際の費用は、24時間365日の運用を前提とするかどうかで変わります。
脆弱性対応やパッチ、予備機を含めるかどうかでも、見積もりに差が出ます。
SLAや機器保守、クラウド利用料も、比べるときの違いになります。
導入後5年間の費用は、TCOとして合算して比べます。ライセンスやクラウド、保守に加えて、改修や機器更新も含めます。
空港業務システムの価格が変動する要因
見積もりは、空港の規模や連携先、可用性によって変わります。機器や導入方式も、金額を動かす要素です。
価格差を見るときは、ベンダーの高低より、見積もり条件がそろっているかを確認します。
空港規模・便数・ターミナル数
便数が多いほど、同時更新やピーク時の処理性能が必要になります。
- ターミナル数：ゲート、スポット、カウンター、表示器などの増加
- 小規模空港：一つの業務と少数の連携から始める進め方
- 複数ターミナル：共通AODBと拠点ごとの差を同時に設計すること
ターミナル数が増えるほど、バゲージベルトやネットワークの管理対象も増えます。
発注側は見積依頼時に、年間便数と繁忙日の時間当たり便数、対象ターミナル数を伝えます。
ゲートや表示器の台数、利用者数、ピーク時のメッセージ数も必要になります。
規模の情報が曖昧なまま「大規模対応」と書くと、過剰な構成で高くなるか、性能の足りない見積もりになります。
可用性・セキュリティ・障害時運用
空港では、数分の停止でも搭乗案内やゲート割当に影響します。手荷物や現場指示にも影響が及びます。
- 可用性：二重化、バックアップ、複数回線、監視の整備
- 復旧条件：障害通知、RTO、RPO、復旧訓練の取り決め
- 安全対策：権限、認証、ログ、脆弱性対応、障害時の手作業をRFPに記載すること
高可用性を求めるほど、初期構築費と年間保守費は高くなります。ただし、復旧対象と時間を決めないまま「高可用性」と書くと、提案を比べられません。
国土交通省は、2026年4月30日改訂の「空港分野における情報セキュリティ確保に係る安全ガイドライン第4版」を公開しています。
出典は国土交通省「航空及び空港分野における情報セキュリティ確保に係る安全ガイドライン」、2026年です。
RFPには、ITと設備・制御系の境界、資産台帳、最小権限を記載します。
多要素認証と監査ログも、あわせて書いておきます。
脆弱性対応やバックアップ、インシデント報告のほか、通信断やランサムウェア時の手作業も対象です。
パッケージ・クラウド・スクラッチの違い
導入方式は、標準機能を使う範囲と独自開発の範囲で比べます。
- パッケージ・クラウド：開発期間を短くしやすい一方、業務変更を伴います。
- スクラッチ：独自業務を再現しやすい反面、長期の保守体制が必要です。
- ハイブリッド：コアを標準機能にし、固有部分を追加開発する形
パッケージやクラウドは、既存機能や業界標準の連携を活用できます。
一方、スクラッチは要件定義や品質保証、標準連携を自ら確保する必要があります。可用性や保守人材も、長期にわたって確保します。
また、AODB、FIDS、RMSのコアを標準機能にし、請求や設備台帳を追加開発する方式も候補です。作業モバイルと分析を追加開発する形も考えられます。
標準機能に合わせられない理由は、必須条件と差別化要素に分けて整理します。そうすると、費用を管理しやすくなります。
空港業務システム開発・導入の進め方
開発では、現行業務とデータの関係を把握してから、小さく導入します。
AODBやスポット管理などの業務単位に分け、効果とリスクを一つずつ確かめます。
現状把握と要件定義の先行
最初に、現行のシステムや業務、データを洗い出します。連携や端末、表示器も、その範囲に含めます。
- 環境：ネットワークや保守契約、手作業のExcelの確認
- データ辞書：作成者、更新者、参照者、正本、代替方法の整理
- 要件分類：必須、標準、設定変更、追加開発、業務変更への分類
便情報ごとの更新タイミングも、この段階で決めておきます。
現場ごとの呼び方は統一し、便やゲートの識別キーを揃えます。
要件をすべて追加開発にすると、費用と納期が膨らみます。反対に、すべてを業務変更で済ませると、現場で使われにくくなります。そのため、優先順位は、費用と効果、安全性、将来の拡張性から決めます。
実データに近いPoCと開発
PoCでは、整ったサンプルより、実際の便ダイヤに近いデータを使います。
- 異常データ：遅延、欠航、機材変更、ゲート変更、臨時便の試行
- 連携異常：重複メッセージや時刻逆転、応答遅延の発生
- 現場条件：不安定な通信からの復旧可否の確認
AODBからRMS、FIDS、現場端末まで、正しい状態が伝わるかを確かめます。ランプや搭乗口、保安区域といった現場での試験も含めます。
PoCの結果をもとに、画面やAPI、データ連携を開発します。権限やログ、性能、監視も作り込み、切戻しの手順も用意します。
屋外や手袋着用の端末では、入力方法とオフライン時の保存方法を早めに確認します。後から現場条件を加えると、アプリだけでなくネットワークや機器の変更も必要になります。
移行・総合試験・切替・運用設計の範囲
受入試験は、一連の業務シナリオで行います。機能単体の確認だけでは、業務の流れがつながっているかを見落としやすくなります。
- 業務連携：便情報やゲート割当、DCS、BHSの結果の確認
- 性能・権限：繁忙日の性能や権限、バックアップ復元、障害通知の試験
- 切替：並行稼働や責任者、判断基準、手作業への復帰条件の決定
AODBの便情報がFIDSに表示され、RMSの割当が現場端末に届くまでを、一つの流れとして確かめます。切戻しのリハーサルも、この流れの中に含めます。
本稼働の段取りとして、旧システムを読み取り専用にする日時と、移行の最終時刻を決めます。
運用開始後の監視や一次受付、エスカレーションは、契約に落とし込みます。パッチや脆弱性対応、ログ保管、定期訓練も含め、業務を継続できる体制まで導入の範囲に入れます。
空港業務システムの見積もりを取る際のポイント
相場を把握するには、同じ前提条件で複数社から見積もりを取ります。会社によって、開発や導入支援、機器の範囲が違い、クラウドや保守の扱いも異なるため、総額だけで比べません。
RFPの対象範囲と前提条件
RFPには、空港やターミナルの数に加えて、ゲートやスポット、表示器の数を記載します。
- 規模：便数、利用者数、対象業務、希望時期、予算帯の提示
- システム：既存システム、連携先、保持期間、正本の提示
- 運用条件：権限やログ、SLA、RTO・RPO、教育、移行、保守の条件
標準規格やAPI、メッセージ方式も明示します。障害時の手作業と責任分界もはっきり示します。こうした条件が抽象的なままだと、提案会社ごとに想定する範囲が変わります。
FIDSをソフトウェアだけと考える会社と、筐体や施工、電源まで含める会社では、見積もりに差が出ます。含むもの、含まないもの、別途費用になる条件を確認します。
同じ評価軸での複数社の提案比較
候補会社は、空港や航空業界での実績に加えて、得意な領域も確認します。
- 技術範囲：AODB、FIDS、RMS、A-CDM、DCS、BHSの対応範囲
- 運用体制：国内対応や日本語体制、24時間SLA、保守拠点の確認
- 提案条件：初期費用や5年TCO、期間、体制、リスクの条件をそろえること
既存機器との接続や標準規格のほか、データ移行と責任分界も評価項目です。
知名度や営業資料だけでなく、類似案件の受入条件や障害対応も聞きます。
最安の提案は、移行や現地試験を含めていない場合があります。逆に高額な提案は、二重化や予備機、訓練、24時間監視を含むこともあります。差額の根拠は、項目単位で確認します。
契約・責任分界・追加費用の条件
契約前には、要件定義後の変更管理や追加開発の単価、接続先の仕様変更を確認します。データ移行の不備や機器の納期遅延、現地作業の時間外対応も確かめます。障害時の責任分界も、同じ場で決めておきます。
- 変更管理：要件定義後の変更と、追加開発の単価の確認
- 責任分界：接続先、移行、機器、現地作業、障害の範囲の取り決め
- 段階契約：成果物と、中止・見直しの条件を定める
概算、要件定義、実装、移行・切替の段階ごとに、契約を分ける方法もあります。
既存ベンダーしか変更できない接続や、未文書化の固有仕様には注意が必要です。発注前に、仕様書やテスト環境、サンプルデータを確認します。
ログや保守窓口の情報もそろえておきます。データ出力やAPIの権利を契約に含めると、ベンダーロックインを減らせます。
空港業務システムのコストを最適化するポイント
機能や試験を単純に削るより、手戻りや障害、二重入力を減らし、必要な品質へ予算を振り向けることが中心になります。ベンダー依存や未使用機能も、減らす対象です。
可用性と切戻しを保ったまま、段階導入で投資を分ける考え方が適しています。
コア業務からの段階導入
一度に刷新する範囲を絞れば、費用と切替リスクを分けて考えられます。
- 初期対象：便情報の正本、スポット管理、FIDS、作業管理からの開始
- 次段階：設備や分析を追加し、投資を分けること
- 先行確認：データ、操作性、通信、教育、障害時運用の検証
AODBやFIDSなどを一度に刷新すると、調整の手間も増えます。ただし、段階を分ける場合でも、将来連携できるデータモデルとAPIは最初に設計しておきます。
次期開発の条件は、KPIで決めます。再入力時間や表示誤り、反映時間などが指標になります。資源稼働率や問い合わせ件数も、KPIとして使えます。
標準機能と標準連携の優先
空港固有の手順をすべて画面に再現すると、開発費やテスト、保守費が増えます。
- 業務標準：業界標準やパッケージを基準にすること
- 例外整理：安全上、法令上、運用上必要なものへの絞り込み
- 連携整理：共通モデルやAPI、再送、認証方式の統一
標準機能に合わせると、導入後の更新や担当者の交代にも対応しやすくなります。さらに、AODBを正本にして周辺システムが参照すれば、便情報の二重入力を減らせます。将来のベンダー変更に備えて、データを取り出せる形式とログを残しておきます。
5年TCOと運用負担による判断
初期費用だけでなく、導入後の運用負担を含めて方式を比較します。
- 5年費用：クラウド、ライセンス、保守、機器更新の合算
- 運用負担：教育、夜間対応、追加開発、移行の負担
- 機能追加：KPIとデータが整った領域からの開始
保守や監視を削ると、障害復旧や改修の負担が空港側へ移ることがあります。あわせて、導入によって担当者の手作業や二重入力が減る時間も試算します。
AIや高度な分析は、目的を決めずに追加すると費用だけが増えます。そのため、遅延予測や設備異常検知などは、KPIとデータが明確な領域から始めます。正しい運航データと現場向けのダッシュボードを整えてから、予測や自動化へ進みます。
よくある質問
空港業務システムの費用や発注について、相談前の質問にお答えします。価格だけでなく、導入範囲や期間、運用体制まで確認することがポイントです。
小規模空港でも空港業務システムを導入できますか？
小規模空港でも導入できます。単一業務から始めるのが現実的です。
- 開始対象：FIDS、スポット管理、設備台帳、作業管理など
- 初期費用：500万〜1,500万円程度の仮置き
費用は、既存システムとの連携や表示器の有無で変わります。現地工事や保守を含むかどうかも、費用を左右します。
クラウドとスクラッチ開発はどちらが安いですか？
初期費用だけなら、標準機能を使えるクラウドのほうが抑えやすい傾向です。
- 比較対象：月額利用料、データ保持、冗長化、通信、監視、SLAを含めた比較
- 長期判断：追加開発を含む5年TCOでの比較
固有業務や既存設備との連携が多い場合は、ハイブリッド方式も候補になります。費用と使いやすさのバランスを取りやすくなります。
空港業務システムの開発には何カ月かかりますか？
開発期間は、業務範囲と連携数によって変わります。
- 単一業務：数本の連携なら3〜6カ月
- 単一ターミナル：AODBやスポット管理なら6〜12カ月
- 複数部門：統合なら12〜24カ月程度
複数ターミナルや表示器を含むと、期間は長くなります。ネットワーク工事や制御系との連携も、長期化の要因になります。
要件定義や現地試験、並行稼働、教育を、期間から外さないことが大切です。
見積もりを取る前に何を準備すればよいですか？
見積もり前には、対象業務と空港・ターミナルの規模を整理します。
- 現行情報：現行システム、連携先、データ項目のまとめ
- 計画条件：希望時期や予算帯、24時間運用の条件
- 障害対応・移行：手作業への復帰条件、旧システムの保持期間、データ更新者の決定
便数やゲート、表示器の台数も、資料に加えておきます。同じ資料を複数社へ渡すと、見積もりの比較精度が上がります。
まとめ
費用相場は、単一業務で500万〜1,500万円、単一ターミナルで1,500万〜5,000万円です。複数部門の統合は5,000万円〜3億円程度で、ハブ級は数十億円以上になる可能性があります。
複数ターミナルで機器やネットワーク、制御系、24時間運用まで含めると、3億円〜数十億円以上になる可能性があります。これらは公開価格ではなく、規模と公開調達から作成した計画用の推定です。
見積もりでの初期費用と5年TCOの確認
見積書は、要件定義やアプリ開発、外部連携などの作業ごとに分けて見ます。クラウドや機器、現地工事も、同じ単位で確認します。
- 初期費用：試験、教育、切替、保守まで含めた確認
- 障害対応：通信断や停電、遅延、表示器停止、ランサムウェアへの対応の比較
- 長期費用：クラウド、保守、機器更新、追加開発を含む5年TCOでの判断
障害時に、どの業務をどの方法で続けられるかも比べます。
正本データと段階導入に基づく発注
発注側は、コストを抑えながら失敗を避けるため、AODBを中心に正本と責任分界を決めます。
- 方式：標準機能を優先した、必要な業務からの段階導入
- RFP：範囲、連携、セキュリティ、SLA、移行、教育、BCPの記載
- 比較：複数社の提案を同じ条件で比べること
空港の現場で止まらず、導入後も運用できることが、費用対効果を高めます。
▼全体ガイドの記事
・空港業務システム開発の完全ガイド
▼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を創業。