運航管理システムの開発費は、300万〜800万円から数億円以上まで幅があります。その幅は、対象範囲、外部連携、安全性や24時間運用の要件で決まります。
「300万円で作れるか」「初期費用以外に何がかかるか」と迷う担当者も多いでしょう。全体像は運航管理システム開発の完全ガイドで扱っています。
▼全体ガイドの記事
・運航管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
運航管理システムの対象別の全体像
運航管理システム群は、飛行計画の作成、機体や便の状態把握、気象・空域情報の確認、異常時対応を支援します（出典: 国土交通省「航空分野における情報セキュリティ確保に係る安全ガイドライン」第7版、2026年）。なかでも国土交通省は、気象情報や積荷情報をもとに、燃料搭載量を含む飛行計画を作成する重要なシステムだと説明しています。
有人航空機向けOCCの管理範囲
OCCでは、平常時の運航管理に加えて、遅延や機材故障などが起きた際の再計画も扱います。
- 管理情報：運航便、機材、乗務員、空港、気象、燃料、整備、貨物、予約・搭乗
- 異常時対応：制約条件を確かめ、遅延便・代替機・勤務制限をふまえて計画を組み直す
市販製品には、フライトモニタリングや乗務員管理を一体で提供する構成があります。ロードコントロール、ハブ運用、フライトプランを含むものもあります。
Lufthansa SystemsはNetLine Ops ++などを含むOCCソリューションを提供し、AIによる意思決定支援も掲げています（出典: Lufthansa Systems公式製品情報、2025年）。
自社で開発する場合、見積もりは、同じ機能をすべて作り直すか、既存製品とAPIで連携するかによって変わります。
ドローン向けUTMSの管理範囲
UTMSでは、飛行情報の把握と、複数の事業者間での計画調整が管理の中心になります。
- 管理情報：飛行計画、機体位置、操縦者、空域、飛行禁止エリア、気象、アラート
- 計画調整：複数事業者の計画を地図上で照らし合わせ、接近や空域の重なりに応じて時間と経路を調整する
国土交通省は2026年4月にUSP制度の案内を公開しました。この制度は、USPの事故防止やDIPS2.0連携に関わる機能を踏まえ、適正な事業者にIDを交付する仕組みです（出典: 国土交通省「USP制度」、2026年）。
有人機向けOCCとドローンUTMSは、利用者や規制が違うだけでなく、データ形式や安全設計も異なります。そのため、見積依頼の冒頭で対象を明確にしてください。
運航管理システムの費用相場の目安
初期開発費は、小規模PoCの300万〜800万円、中規模業務システムの800万〜3,000万円、大規模OCC・UTMSの3,000万〜1億円、基幹刷新を含む1億〜数億円以上という4つの段階で考えると整理しやすくなります。上の段階ほど対象範囲が広がり、費用の幅も大きくなります。
航空向けの公開定価は多くないため、ここに示すのは、類似する運行管理システムの公開情報をもとにした推定レンジです。そこに、航空特有の連携、安全検証、24時間運用の工数を加味しています。個別案件の確定価格ではありません。
小規模PoCや周辺機能の費用目安（300万〜800万円）
300万〜800万円のPoCでは、単一の事業者・拠点での検証と、必要な周辺機能が費用の前提になります。
- 検証範囲：単一事業者・単一拠点での運航情報参照
- 周辺機能：気象API・地図表示、限定ユーザーへの通知
たとえば、飛行位置を地図に表示し、気象警報を担当者へ通知する構成です。通信が復旧した後に端末情報を再同期する程度であれば、業務全体の刷新より小さく始められます。
期間は2〜4か月程度が目安です。なお、既存データの形式が整っていて、API仕様が確定し、利用者も限られる場合は、期間を短くできます。
実証データの作成、現場ヒアリング、セキュリティ審査まで含めると、機能が少なくても費用は上がります。実機試験も含めると、その分の工数が加わります。
PoCの費用は、安く作ること自体が目的ではありません。本番投資の前に、必要な精度で使えるかを判断するための費用です。
中規模の業務システムの費用目安（800万〜3,000万円）
この価格帯に含まれやすいのは、機能と利用規模の両方が広がった案件です。
- 業務機能：フライト計画、リアルタイム運航状況、権限管理、通知、複数の気象・地図・機体API
- 利用環境：管理者向けWeb・現場向けモバイル、数十〜数百名、複数拠点、履歴検索・CSV・監査ログ
期間は4〜9か月程度です。工数を左右するのは画面数だけではなく、認証方式、データ欠損時の扱い、更新間隔です。通信断時の端末保存や通知重複の抑制も、工数に影響します。
中規模案件では、機能一覧よりも先に、例外シナリオを見積書に反映できるかが問われます。
大規模OCC・UTMSの費用目安（3,000万円〜数億円以上）
費用帯は、連携範囲と刷新内容によって分かれます。
- 3,000万〜1億円：複数拠点・部門、機材・乗務員・整備・貨物・予約・搭乗連携、再計画、監査、承認、24時間監視
- 1億〜数億円以上：基幹置き換え、データ移行、段階的な並行稼働を含む場合
大規模OCC・UTMSの期間は9〜18か月、基幹刷新や高可用性の運航基盤では18〜36か月以上が目安です。
異常時の切替と権限分離、監査証跡も必要です。障害復旧、訓練、受入試験も見込んでおく必要があります。これらを削ると、稼働後の障害対応や再開発で総額が膨らみやすくなります。
運航管理システムの費用内訳
見積書は、画面数だけでなく、企画から運用までの工程ごとに確認してください。
総額のうち、要件定義・設計に20〜30％、テストに15〜25％程度を見込む考え方があります。クラウド・気象・地図・通信の利用料は、開発費と分けて書いてもらうと比べやすくなります。
企画・要件定義・安全設計の費用
企画・要件定義では、発注側と開発会社が、対象範囲と既存システムとの境界を決めます。
- 共通条件：対象機体・拠点・利用者、運航規程、平常時・異常時の業務
- 航空会社：OCC、FMS、DCS、AODB、整備、貨物、予約との境界
- ドローン：DIPS2.0、USP、機体テレメトリ、空域情報の連携範囲
対象を広げすぎると、後工程で画面やAPIが増え、見積もりの前提が崩れます。あわせて、権限分離や承認、フェイルセーフ、監査ログ、データ保持期間を要件定義の段階で決めておきます。RTO・RPO、可用性、障害時の手動運用も定義しておくと、後の見積もりの前提がそろいます。
国土交通省の2026年改訂ガイドラインでは、サイバー攻撃で遅延・欠航や安全運航への支障が生じうる運航システムを保護対象としています（出典: 国土交通省「航空分野における情報セキュリティ確保に係る安全ガイドライン」第7版、2026年）。
セキュリティを後から付けると、認証やログの再設計が生じます。そのため、要件定義の段階から費用を確保してください。
画面・API・データ基盤の設計開発費
設計開発費は、画面や業務機能に加えて、更新の頻度や操作の要件によっても変わります。
- 画面・機能：ダッシュボード、計画、機体・乗務員・便、気象・地図、通知、承認、設定、モバイル
- 実装要件：リアルタイム更新、履歴、同時編集、操作取り消し、権限別表示
運航管理システムの中核には業務APIとデータ基盤があり、そこでフライト、機体、乗務員、空域、気象、貨物のモデルを揃えます。このデータ基盤の上に、イベントから遅延や接近を検知して通知する仕組みを載せます。
通信断に備えて、モバイルやエッジ側にデータをキャッシュし、復旧後は重複や古い更新を処理します。正規化や再同期は画面からは見えにくいものの、品質と費用を左右します。
外部連携・データ移行・テストの費用
費用が膨らみやすいのは、既存システムや外部サービスとの接続です。
- 連携候補：気象・地図API、NOTAM、機体テレメトリ、FMS、DCS、AODB、整備、貨物、予約、DIPS2.0
- 接続設計：相手側の仕様・認証・レート制限、障害時の代替、データ欠損・遅延への対応
- 試験負荷：接続先が増えるほど正常系・エラー系・再送の試験が増え、API本数×単価では費用を読み切れない
テストでは、画面やAPIの単体・結合、業務シナリオ、負荷、権限を確認します。さらに、障害切替と通信断、データ復旧を確かめます。脆弱性と現場受入も、テストの範囲に含めます。
特に、台風や大雪による多数便の遅延、機材故障による代替機、空域での飛行計画の重複を再現できるかが要点です。航空向けでは、テスト費を15〜25％程度確保する考え方が、とりわけ重要です。
クラウド・監視・保守の費用
運用関連費用は、利用基盤と継続保守に分けて見積もります。
- クラウド等：計算資源、DB、保存、ログ、バックアップ、監視、通信、通知、地図・気象API
- 年額保守：開発費の15〜20％を暫定目安に、障害対応、パッチ、規制・API変更、バックアップ検証、訓練を加算
位置情報やイベントを長期間保存すると、データ量と検索頻度が増えます。大規模案件では、複数リージョンや待機系、災害復旧環境も必要になります。そのため、平常時の利用料だけでは予算を把握しきれません。
小規模なら月額数十万円、大規模なら月額数百万円以上になる可能性があります。契約前には、24時間365日の一次監視、復旧目標、休日の連絡体制、改修の時間単価を確認してください。
運航管理システムの価格を左右する要因
費用は、運航の種類と止められない時間帯、連携するデータの数によって変わります。見積書を比べるときは、金額だけでなく、各社が置く前提条件も揃えてください。
対象機体・便・拠点・利用者の規模
規模によって、必要な機能や管理方式が異なります。
- 小規模：一空港・一事業者・数機なら登録、地図、通知に絞れる
- 広域・多組織：複数空港・会社、多数機材、交代制利用者、複数USPでは分離権限が必要
規模が大きくなると、データ共有の範囲や負荷分散、監査証跡も求められます。機体数や便数は、データ量だけでなく、同時に起きるイベントの数と判断の複雑さも増やします。
OCCとUTMSを一つのシステムにまとめる場合は、用語と権限の違いを吸収する共通化設計が必要です。規制やデータライフサイクルの違いも、同じ設計の中で扱います。
将来の拡張を見込むなら、両方を同じ画面に詰め込むより、共通APIや認証基盤を先に設計したほうが、初期費用を管理しやすくなります。
リアルタイム性・可用性・障害対策の水準
更新頻度と復旧要件を決めておくと、必要な構成と費用を見積もれます。
- 更新間隔：5分ごとの画面と、数秒単位で位置・運航状況を反映する構成
- 可用性：稼働率、RTO・RPO、待機系、バックアップ復旧頻度
イベントストリーミングや時系列データベースなどが必要になると、設計とテストが増えます。「リアルタイム」という言葉のままではなく、通常時とピーク時の許容遅延を数値で定義してください。
インフラ費用は、目標稼働率やRTO・RPO、待機系の有無によって変わります。バックアップからの復旧頻度も、費用に効いてきます。
通信断やクラウド障害のときも、最低限の確認と承認は続ける必要があります。そのため、エッジ側キャッシュや紙、無線などの代替手順を設計してください。
安全性・法規制・AIの扱い
AIを使う場合は、人による承認と、モデルを運用するための継続作業を一緒に設計します。
- 人の確認：制約違反を検知し、担当者が根拠を確認・承認するHuman-in-the-loop
- 運用費用：学習・検証データ、説明、手動復帰、更新、監査ログ、利用者訓練
- ドローン運用：接近通知と飛行計画の承認・変更を分ける
ANAはBlueWXのシステムを2025年7月に正式導入し、日本上空の予測モデルで86％の正答率を実現したと発表しました（出典: ANA・BlueWX共同プレスリリース、2025年）。
この導入では、パイロット2,500名超を対象に4年間評価したとされています。モデルを呼び出すだけでは、本番品質には届かない点に注意が必要です。
ドローンでは、空域の重なりや接近の自動通知と、人が行う計画の承認・変更を分けて設計します。制度改定への対応を見込んだ保守費を用意しないと、AIを追加した後に運用コストが増えます。
画面・モバイル・現場環境への対応
画面は、利用場所や端末の使い方に合わせて設計します。
- 利用環境：管理者の大画面と、現場担当者の短時間タブレット操作
- モバイル要件：通信不安定時の保存、GPS・カメラ、遠隔ロック、再ログイン、誤操作防止
多言語や夜間表示、アクセシビリティは、後から加えると費用が高くなりやすい要素です。複数モニターや印刷、無線連絡との併用も、後から加えると費用がふくらみやすくなります。
現場を観察して、運航停止につながる操作と、後から追加できる分析機能を分けておくと、不要なUI費用を抑えられます。
運航管理システムのコストを抑える方法
コストを抑えるといっても、機能を一律に削ればよいわけではありません。安全運航、法規制・監査、業務効率、将来の分析やAIに分けて、費用対効果とリスクに応じて投資します。
初期開発費だけでなく、導入後5年間のTCOで判断すると、安く見える構成の隠れた費用も比べられます。
標準機能に業務を合わせるFit to Standard
標準機能で賄える範囲と、個別に対応すべき範囲の境目を見極めます。
- 標準に合わせる業務：既存製品の、航空業界の用語や運用に沿った機能、更新、監視を活用
- 個別対応する業務：固有の運航規程・機材構成など、差別化が必要な部分
- 適合しない場合：安全要件や既存連携に合わない無理な改修は保守費を増やす
契約前には、標準、設定変更、追加開発、外部連携の境界を確認します。更新費用とデータ搬出の方法も確かめてください。5年後まで改修を維持できるかも、判断材料になります。
状況把握と通知から始める段階導入
再計画やAI、全システム連携は、初めから実装せず、段階ごとに機能と効果を確かめながら進めます。
- 第一段階：運航状況の把握と重要通知
- 次の段階：飛行計画、便、機材、乗務員との連携と承認
- 最後の段階：最適化やAIによる提案機能
各段階で、作業時間や遅延対応時間を測り、通知の見逃しや手入力件数も数えておくと、次の投資を決める材料になります。
PoCを、平常時の整ったデータだけで評価するのは避けてください。台風や大雪、機材故障、古い気象データを含めて検証します。通信断や空域重複、API停止が起きた場合の動きも確かめます。
NTTデータは2025年2月、KDDI、トラジェクトリー、Terra Droneと、複数USP間の飛行計画調整を実証したと発表しました（出典: NTTデータ「複数運航者間での飛行計画調整によるドローン接近回避の実証」、2025年）。
この実証では、重複の解消と、災害時の緊急用務空域での調整を検証しています。
標準API・イベント連携による将来の拡張費の抑制
将来の連携や移行に備えて、データの扱いと共通基盤を検討します。
- ベンダー依存：独自画面・形式に閉じると、連携追加や変更費用が増える
- 接続時の合意：データの意味、単位、時刻、位置精度、欠損時の扱いを決める
- 費用の注意：標準APIを採用しても自動的に安くなるとは限らず、変換層と監視も必要
フライト、機体、乗務員のデータモデルと、空域、気象のデータモデルを整理し、標準APIとイベント形式で疎結合にします。そうしておけば、画面を変えずに気象APIを交換したり、通知先を追加したりできます。
初期見積もりでは共通基盤に投資し、個別の画面は業務効果を確かめた順に追加します。こうすると、長期的な開発費を抑えやすくなります。
初期費用ではなく5年TCOでの比較
5年TCOには、初期開発以外の継続費用や、終了時の費用も含めます。
- 開発・運用：追加開発、クラウド、APIの費用がかかります。監視や保守、セキュリティも継続費用になり、規制改定や訓練も加わります。
- 移行・終了：データ移行、障害復旧、契約終了時のデータ搬出
初期費用が1,000万円安くても、月額利用料やカスタマイズ保守が高ければ、数年で逆転します。たとえば利用者数や機体数、便数、保存期間をそろえて、年ごとの総額を比べてください。稼働時間とSLAも、同じ条件に含めます。
障害時に運航が受ける損失も評価してください。復旧が遅れると欠航や代替輸送が起きる業務では、高可用性や二重化が合理的になる場合があります。
分析用の履歴検索は、運航系と同じ可用性を求めず、安価な別基盤に分けます。そうすれば、安全性を落とさずにコストを最適化できます。
運航管理システムの見積もりを取る際のポイント
見積もりを頼む前に、対象範囲や業務シナリオ、連携先を一枚に整理してください。非機能要件と運用体制も書き出しておくと、見積もりの前提が伝わりやすくなります。
仕様が未確定なら、機能ごとの確定額を求めない方法もあります。要件定義・PoCと本開発で概算レンジを分けておけば、後から増額した理由をたどれます。
RFPに含める業務フローと異常時シナリオ
RFPには、平常時に加えて、運航判断に影響する異常時の業務シナリオを記載します。
- 有人便の異常：遅延、欠航、代替機、乗務員交代、気象警報、機材故障
- システム・空域の異常：通信断、外部API停止、空域重複、緊急用務空域
各場面で誰が確認・承認し、どのシステムに反映し、どの記録を残すかを示してください。そうすると、ベンダーの想定と自社の期待がそろいます。
非機能要件には、利用者や機体・便の数、同時接続数を数値で記載します。更新間隔や稼働時間、目標稼働率、RTO・RPO、データ保持期間も含めます。
認証方式と権限、監査ログ、バックアップ、脆弱性対応も記してください。「高速」「安全」「いつでも使える」といった表現は、会社によって解釈が異なります。そのため、検収条件として確かめられる表現に変えてください。
複数社を同じ条件で比べる方法
会社の知名度だけで決めずに、候補企業の得意領域と運用実績を比べます。
- 候補の種類：OCC製品、UTMS・ドローン、通信・クラウドSIer、気象・地図専門企業
- 確認する経験：有人機・ドローン、製品・個別開発、既存連携、現場展開、24時間保守
初期費用や月額・年額、API利用料などの金額は、同じ様式で回答してもらいます。保守や規制改定、データ移行、訓練、データ搬出も、同じ形式で揃えてください。
前提条件や除外項目、再見積もりの条件が明確かどうかも比べてください。価格だけで選ぶより、発注後の予算超過を防ぐ助けになります。
要件の確度に応じた契約と発注範囲
要件の確度に応じて、調査・検証と開発の契約範囲を分けます。
- 要件が未確定：ヒアリング、業務整理、データ調査、技術検証を準委任やPoCで発注
- 仕様が確定：受入条件が決まった機能を請負で開発
- 固定価格の注意：曖昧な前提はリスク費用や変更時の追加請求に現れる場合がある
契約書では、成果物と役割分担、データやモデルの権利を定めます。第三者サービスが停止したときの責任や障害優先度、SLAも、契約書に書いておきます。さらに、再委託や脆弱性対応、規制変更、終了時の引き継ぎも定めます。
気象・地図APIが止まったときの代替処理を、誰が実装し運用するかを明確にしておきます。そうすると、障害時の追加費用や責任の押し付け合いを防げます。
受入基準と運用移行までの見積もり
受入基準は、画面表示に加えて、安全性や復旧時の動作を確認できる形にします。
- 制御とデータ：制約違反・古い情報を検知し、権限外の閲覧を防げるか
- 復旧と継続：通信復旧後の二重登録防止、障害時の手動運用切替ができるか
運用移行には、マスタの整備やデータ移行、アカウントの発行が含まれます。さらに、操作訓練や監視手順、障害連絡網、リリース判定、並行稼働、旧システムの停止も含まれます。
受入には、運航管理者や操縦者、整備の担当者が参加します。空港やセキュリティ担当者も、受入に加わります。移行費用は開発費の外に置かず、見積もりに入れてください。
運航管理システムのよくある質問
費用を検討するときによく寄せられる質問に、対象範囲や開発方法、維持費、AIや法規制の観点から答えます。
運航管理システムは300万円で開発できますか？
限定された事業者・拠点で、運航情報表示、気象・地図連携、通知に絞るPoCなら、300万〜800万円に収まる可能性があります。
複数システムとの本格連携や24時間監視に加えて、冗長化、安全検証、データ移行まで含む場合は、300万円では不足しやすくなります。
パッケージとスクラッチ開発はどちらが安いですか？
標準業務が多く、既存パッケージの機能や外部連携を使える場合、パッケージやSaaSは短期間で導入しやすく、初期費用を抑えられることがあります。
独自の運航規程や機材構成が競争力や安全要件に直結する場合は、スクラッチや拡張開発が適します。空域調整や既存基幹との連携が重要な場合も、スクラッチや拡張開発を検討します。
初期費用ではなく、5年TCOで比べてください。利用料やユーザー追加、カスタマイズ、更新、終了時のデータ搬出を含めると、総額が変わる場合があります。
開発後のランニングコストはいくらかかりますか？
年額保守は、開発費の15〜20％を暫定の目安とします。そこに、クラウドや気象・地図・通信APIの利用料を加えて考えます。さらに、監視やバックアップ、セキュリティの費用を見込みます。規制改定や訓練の費用も含めます。
小規模なら月額数十万円、大規模で24時間監視や冗長化を行う場合は月額数百万円以上になる可能性があります。
運航管理システムにAIを入れると高くなりますか？
AIには、モデル利用料のほかに、学習・評価データや外部APIが必要です。説明表示や承認フロー、ログ、更新、誤判断時の手動復帰、利用者訓練も、費用に含めて考えます。
そのため、単純な画面追加より高くなりやすいです。乱気流予測や再計画候補の提示のように、人の意思決定を支える用途に絞り、精度と安全性を検証しながら段階的に導入すると、費用とリスクを管理しやすくなります。
見積もり前に何を準備すればよいですか？
有人航空機かドローンかを、まず決めておきます。対象の機体・便・拠点を整理し、利用者の範囲も示します。そのうえで、平常時と異常時の業務と連携先を書き出します。
更新間隔や稼働時間、目標稼働率を用意します。RTO・RPOや監査ログ、データ保持期間も、あわせて準備します。現行画面や帳票、Excel、API仕様、運航規程、障害手順があれば、見積もりの前提を揃えられます。
まとめ
開発費の推定レンジは、小規模PoCが300万〜800万円、中規模業務システムが800万〜3,000万円、大規模OCC・UTMSが3,000万〜1億円です。基幹刷新や高可用性基盤は、1億〜数億円以上です。
航空向けには一律の公開相場がありません。そのため、対象範囲や連携、リアルタイム性、安全検証、運用保守を分けて見積もることが大切です。
初期費用ではなく安全性と5年TCOでの判断
費用を抑えるには、OCCとUTMSを分けて考え、状況把握と通知から段階的に導入します。標準APIで疎結合にしておけば、連携先を追加・交換する費用を抑えられます。
ただし、安全性、法規制、監査、通信断、障害復旧にかかる費用は削らないでください。5年TCOで比べるときは、クラウドやAPI、監視の費用を含めます。保守や規制改定の費用も入れます。訓練やデータ搬出も、同じ条件で見ておきます。
異常時シナリオを含む要件整理
平常時の機能一覧より先に、台風や大雪、機材故障、乗務員不足が起きたときの業務を一覧にします。通信断や空域重複の場合も、同じように整理してください。
PoCの範囲や成功指標、連携先、非機能要件、受入基準を整理します。そのうえで、同じ条件で複数社に見積もりを依頼すると、必要な投資額と削減できるコストを判断しやすくなります。
▼全体ガイドの記事
・運航管理システム開発の完全ガイド
▼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を創業。