GitHub Actionsのシステム開発の見積相場や費用/コスト/値段について

GitHub Actionsのシステム開発費用は、対象の規模、実装する範囲、運用の条件によって、50万〜1,500万円以上まで幅があります。

費用を左右するのは、対象リポジトリの数と実装範囲、そして導入後の運用を誰がどう担うかです。全体の流れは、次に紹介する完全ガイドでも確認できます。

▼全体ガイドの記事
・GitHub Actionsのシステム開発の完全ガイド

GitHub Actionsのシステム費用を決める全体像

GitHub Actionsの費用要素をGitHubのプラン、初期構築、外部基盤、運用保守の4層で示す図
費目を分けると、見積もりの確認先が整理できます。

GitHub Actionsのシステムにかかる費用は、複数の要素を合わせて決まります。見積もりでは、次の層ごとに費用を確認します。

  • GitHubのプラン:契約費とActionsの従量料金
  • 初期構築:導入会社へ支払う設計・実装費
  • 外部基盤:AWSやAzureなどの利用費
  • 運用保守:導入後の保守や担当者の工数

GitHubのプランと製品ライセンスの費用

GitHubのプランと製品ライセンスは、利用者やリポジトリに合わせて選びます。プランごとに、無料で使える分数や容量が異なるためです。

  • プラン:個人向けのFree・Pro、組織向けのTeam、企業向けのEnterprise CloudまたはEnterprise Server
  • プライベートリポジトリ:プランごとの無料分数と、成果物・キャッシュの保存容量

無料分数や容量を超えた分は、従量課金の対象になります。なお、Enterprise Cloudには標準Runner向けに月50,000分が含まれます。

大型RunnerやAdvanced Securityは、プランごとの含有内容を別に確認しておく必要があります(出典: GitHub Docs「Product usage included with each plan」、2026年)。

CI/CD基盤の設計・実装費用

依頼費用は、Workflowの作成に加えて、調査、ブランチ戦略、テスト方針、環境ごとの承認フローを含むかどうかで変わります。

Reusable Workflow、Secrets、OIDC、通知、ログ、ロールバックも設計の対象です。たとえば、PRチェックだけを扱う1リポジトリの案件と、数十のリポジトリを統制する案件では、設計と検証の量が大きく異なります。

クラウド・ネットワーク・運用の費用

AWS、Azure、Google Cloud、コンテナレジストリ、秘密情報の管理、監視サービスなどにも、別途費用がかかります。

self-hosted Runnerでは、仮想マシンやKubernetesの費用も考慮します。OS更新や脆弱性対応、ネットワーク分離の担当を決めます。Runner交換や容量監視の担当も、あわせて決めておく必要があります。

社内の対応を無料として扱うと、担当者の工数や障害対応費が見積もりから抜け落ちがちです。そのため、社内の作業も費用として見積もりに入れておく必要があります。

GitHub Actionsの規模別の開発費用相場

小規模、中規模、大規模・エンタープライズの導入支援費の目安を横棒で並べた図
規模が上がるにつれて、費用レンジも広がります。

導入支援費の目安は、小規模で50万〜150万円、中規模で150万〜500万円、大規模・エンタープライズで500万〜1,500万円以上です。

この金額は、国内の業務システムやCI/CD基盤の相場と、エンジニアの人月単価50万〜150万円程度をもとにした推定です。GitHub自体が一律に定めた価格ではない点に注意が必要です。

GitHubの契約費、Runner、クラウド、保守は、別途かかる場合があります。

小規模なら50万〜150万円が目安

小規模案件では、1〜3リポジトリを対象に、次の自動化を行います。

  • Pull Request時:静的解析と単体テストの自動化
  • staging環境:基本的なデプロイの自動化

ブランチ運用を確認したうえで、GitHub-hosted Runner、Secrets、Environmentを設定し、操作方法も説明します。期間は2〜6週間ほどで進むことがあります。

既存テストが整っていて、デプロイ先の権限設計も決まっていれば、50万〜100万円程度に収まる可能性があります。

Jenkinsや個別スクリプトからの移行を含むと、調査と検証が増えます。Dockerイメージの生成や手動承認に加え、失敗通知やロールバックも、検証の対象になります。

対象が少なくても、テストが不足していたり、クラウド権限が未整理だったりすると、150万円近くまで上がることがあります。その場合は、検証を削らず、最初の対象を絞って品質を確かめます。

中規模なら150万〜500万円が目安

中規模では、10〜50リポジトリや複数チームを対象に、環境の分離や共通設定を整えます。

  • 環境・認証:staging・productionの分離とOIDC認証
  • 共通化:Reusable Workflow、通知、監査ルール
  • 既存CI移行:Jenkins、GitLab CI、CircleCIなどからの移行

既存CIの移行では、YAMLを書き換えるだけでは足りません。処理の同等性や権限、成果物を確認し、失敗時の挙動も見ておく必要があります。そのため、期間は1.5〜4か月が目安になります。

組織ルールやSSO、監査ログを含めると、工数は増えます。社内レジストリや複数クラウド、夜間通知、教育まで加えると、さらに工数がかさみます。

共通Workflowで個別設定を減らせる案件は、初期設計費がかかっても、後から加わるリポジトリの追加費用を小さくできます。

大規模・エンタープライズなら500万〜1,500万円以上が目安

大規模案件では、複数の部署や数十〜数百のリポジトリを扱います。GitHub Enterprise CloudまたはServerを使い、次の要件も対象になります。

  • 認証・統制:SAML SSO・SCIM、組織横断ポリシー、監査
  • 基盤・安全対策:self-hosted Runner、ネットワーク分離、Advanced Security

段階的な移行や教育を含めると、期間は3〜9か月以上かかることがあります。要件定義からPoC、本番展開、運用の引き継ぎまでが対象になるためです。構築費は500万〜1,500万円以上になる可能性があります。

閉域網や個人情報、特殊OS・GPU・大容量ビルドが絡むと、Runnerの設計と保守が費用の中心になります。

Enterpriseのライセンス価格や販売条件は、契約形態、ユーザー数、サポート条件によって変わります。そのため、公開情報だけで総額を決めるのは難しく、対象人数と必要な機能を書き出して、個別に見積もりを取ります。

ポイント

規模は、リポジトリ数と既存CIの移行、統制や閉域網の要否で見ます。契約費やRunner、クラウド、保守が別途かかるかは、先に確かめておきます。

GitHub Actionsの見積もりに含める費用の内訳

見積もりを「GitHub Actions構築一式」とまとめず、作業ごとに分けてもらいます。内訳が分かると、予算を削る場所と残す場所を判断でき、会社同士の比較もできます。

現状調査・要件定義・基本設計の費用

現状調査と要件定義では、次の項目を確認し、決めておきます。

  • 現状調査:リポジトリ、言語、テスト、ブランチ運用、リリース手順、既存CI、デプロイ先、Secrets、権限
  • 要件定義:実行イベント、production承認者、失敗時の通知先、成果物の保存日数

要件が曖昧なまま実装に入ると、対象環境や承認フローの追加で、工数が1.3〜1.5倍程度に膨らむ可能性があります。この倍率は、類似する業務システムの見積もりで使われるリスク見込みで、確定的な統計ではありません。

Workflow実装・移行・連携の費用

実装費には、Workflow、Job、Step、Actionの組み立てが含まれます。加えて、matrixテストやキャッシュ、成果物保存も対象です。コンテナイメージの作成や環境別デプロイまで含めて見積もります。

既存CIからの移行では、旧環境との並行稼働が必要になります。結果を比べるテストや切り戻しの手順、開発者への説明も欠かせません。

AWSやAzureのIAM、Kubernetes、社内レジストリとの連携には、クラウド側の作業も関わります。そのため、クラウド設計の担当範囲を見積書に明記しておきます。

テスト・セキュリティ・ドキュメントの費用

テスト、セキュリティ、納品物では、次の内容を押さえておきます。

  • テスト:本番に近い環境でのデプロイ、権限不足、再実行、ロールバック、並列実行時の競合
  • セキュリティ:GITHUB_TOKEN最小権限、第三者ActionのSHA固定、OIDC、Environment承認、Runner隔離、監査ログ
  • 納品物:設計書、Workflowコメント、運用Runbook、障害時の連絡先

第三者ActionはリポジトリやSecretsに影響する可能性があるため、GitHub公式は完全なコミットSHAへの固定を推奨しています(出典: GitHub Docs「Secure use reference」、2026年)。

設計書やRunbookを納品に含めると、内製化後の再現性が高まります。

ポイント

内訳が出ない見積もりは、会社間で比べにくいものです。現状調査から移行、テスト、セキュリティ、納品物まで、作業ごとの金額が書かれているかを見ます。

GitHub Actionsの月額・従量ランニングコスト

運用費は、契約プランとRunnerの実行時間で分けて考えます。Artifacts・Packages・キャッシュの保存量、外部クラウド、保守工数は、別の費目として管理します。

無料枠だけで判断すると、プライベートリポジトリの超過料金や、長く保存する成果物の費用を見落とすおそれがあります。

Runnerの実行分数による費用

2026年時点の公式料金は、Runnerの種類によって異なります。

  • Linux 2-core:1分0.006米ドル
  • Windows 2-core:1分0.010米ドル
  • macOS 3〜4-core:1分0.062米ドル

GitHub-hosted Runnerは、ジョブごとに分単位で計算し、1分未満も切り上げます(出典: GitHub Docs「Actions runner pricing」、2026年)。為替を1米ドル=150円と仮定すると、Linuxで月1万分なら約9,000円、5万分なら約4万5,000円になります。macOSで月1,000分なら、約9,300円です。

これはRunnerの従量料金だけを試算したもので、プラン費用やクラウド費用は含まれていません。

GitHubは2026年1月、hosted Runnerの料金をマシン種別に応じて最大39%引き下げました。一方で、self-hosted Runnerへの1分0.002米ドルの課金は、再評価のために延期されています。

料金は変更される可能性があるため、契約や予算申請の時点で、利用レポートと公式料金表を確認し、予算上限も設定します(出典: GitHub Changelog「Update to GitHub Actions pricing」、2025年12月更新・2026年確認)。

Artifacts・Packages・キャッシュの保存費用

保存費用は、保存量と保持期間によって変わります。Enterprise Cloudの含まれる容量と、超過時の参考料金を見ておきます。

  • 含まれる容量:標準Actions分数は月50,000分、Artifacts・Packages共有ストレージは50GB、キャッシュはリポジトリごとに10GB
  • 超過料金:共有ストレージは1GB・月0.25米ドル、Actionsキャッシュ・カスタムイメージは1GB・月0.07米ドル

これらは参考料金です(出典: GitHub Docs「GitHub Actions billing」、2026年)。

テスト結果と本番リリース用の成果物は分けて、用途ごとに保持期間を決めます。ログや巨大なDockerイメージを長く残すと、実行分数よりもストレージが問題になることがあります。

キャッシュは実行時間を短くできます。ただし、キーを細かく分けすぎると古いキャッシュが増えます。そのため、容量と効果を同時に確かめます。

クラウド利用料と保守・運用費用

GitHub Actionsとは別に、クラウドの利用料がかかります。保守費は、対応範囲によって変わります。

  • クラウド利用料:デプロイ先のコンテナ、仮想マシン、データベース、ストレージ、ネットワーク、監視
  • 保守費の目安:初期構築費の年15〜25%程度、または月額5万〜30万円程度から

この相場はGitHub Actionsの定価ではなく、保守に含める範囲で変わります。対象には、Workflowの修正や問い合わせ、脆弱性対応、Runnerの更新、障害対応などがあります。

小規模であれば、月次の確認と軽微な修正で済むことがあります。一方で、大規模では、24時間監視や緊急連絡、監査が必要になり、Action更新やOSパッチ、Runnerの増減も加わります。

契約では、対応に含む時間と対応時間帯を決めておきます。緊急連絡や追加作業の単価もあらかじめ定めておくと、運用開始後の予算が安定しやすくなります。

ポイント

月額は、プラン費用、実行分数、保存容量、クラウド利用料、保守工数に分けて見積もります。無料枠の内側だけで判断すると、超過料金を見落とすおそれがあります。

開発の進め方と期間が費用に与える影響

現状調査とPoC、標準化と既存CI移行、エンタープライズ展開の順に期間の目安を示すタイムライン
段階ごとに対象と進める作業が変わります。

Workflowを短期間で書き始めても、そのぶん費用が必ず安くなるとは限りません。テストや権限の問題を見落とすと、本番前に作り直しが発生し、結果的に高くつきます。

まず小さなPoCで効果とリスクを確かめ、共通化を設計してから段階的に展開します。こうした順序を踏むと、品質と費用のバランスを取りやすくなります。

現状調査とPoC(2〜6週間)

最初は対象を1〜3リポジトリに絞ります。PR時のテストと依存関係キャッシュを試し、stagingデプロイと通知も、あわせて確かめます。

実行時間と失敗率を測ります。再実行の回数や、結果を確認するまでの時間も見ておきます。GitHub-hostedとself-hostedのどちらが必要か、既存CIから何を移すかも判断します。

小規模であれば、PoCを含めて2〜6週間程度が目安です。

標準化と既存CI移行(1.5〜4か月)

PoCの結果をもとに、Reusable Workflowや社内Actionを標準化します。命名やEnvironmentのルールもそろえ、Branch RulesetやSecrets管理も整えます。

コピー&ペーストを減らす設計には、初期の時間がかかります。ただし、後から対象を増やしたときの費用を小さくできます。

既存CIの移行では、旧環境との結果比較や段階的な切り替え、手動デプロイの代替手順を用意します。中規模では、1.5〜4か月かかることがあります。

エンタープライズ展開(3〜9か月以上)

展開では、先に組織ポリシーと責任分界を決めておきます。そのうえで、パイロット部署から対象を広げていきます。

  • 統制・基盤:SSO・SCIM、監査ログ、ネットワーク、self-hosted Runner
  • 展開支援:セキュリティ審査、教育、運用引き継ぎ

これらは並行して進むため、技術の実装だけでは期間を縮められません。

はてなは、GitHub ActionsをCI/CDだけでなく、開発ワークフローの統合にも活用しています。また、企業で定着させるには、運用ルールを育てる視点が必要です(出典: GitHub公式「株式会社はてな」導入事例、2022年公開・2026年確認)。

GitHub Actionsの費用が変動する主な要因

費用は、対象リポジトリの数やテストの重さ、デプロイ先によって変わります。セキュリティ要件や社内スキルも、費用を左右します。見積もり前に変動要因を洗い出しておくと、想定外の追加費用を防ぎやすくなります。

リポジトリ数・環境数・既存資産

リポジトリが増えると、確認すべき違いも増えます。言語やパッケージ管理、テストデータの違いに加え、ブランチルールやデプロイ先も見ていきます。

テンプレートで統一できれば、工数を抑えられます。一方で、サービスごとの例外が多いと、個別の設計が必要になります。

さらに、Jenkinsの共有ライブラリや古いシェルスクリプトに、文書化されていない決まりごとが見つかるほど、移行費用が増えます。

Runner方式とセキュリティ要件

Runnerの実行環境をどう選ぶかで、CI設計と保守の負担も変わります。

  • Runner方式:標準GitHub-hostedか、社内ネットワークや特殊ビルド向けself-hostedか
  • self-hostedの管理:コード隔離、エフェメラル構成、パッチ、アクセス制御、障害時の交換手順
  • 情報・権限管理:個人情報や本番権限にはOIDC短期トークン、Environment承認、最小権限、監査ログ

GitHub公式は、クラウド認証にOIDCを使うと、長期保管の認証情報を減らせると説明しています(出典: GitHub Docs「OpenID Connect」、2026年)。

社内体制と内製化の範囲

YAMLやクラウドIAMを扱える担当者がいるかどうかや、Workflowを作ったあとに誰が更新するかも、費用に影響します。また、設計、初期実装、教育、運用移管を分けて依頼すれば、外注費と内製化のバランスを調整できます。

納品物がYAMLだけで、設計の意図や障害時の手順が残っていない場合、担当者が退職した後に再委託が必要になります。そうなると、長期の費用が増える可能性があります。

ポイント

費用を動かすのは、リポジトリ数と既存資産、Runnerの方式とセキュリティ要件、社内体制の3つです。見積もり前に整理すると、想定外の追加費用を抑えるのに役立ちます。

GitHub Actionsのコストを最適化するポイント

最適化では、Runner料金だけでなく、テストの信頼性とデプロイの安全性を保ちながら、不要な実行や保存、保守を減らします。初期費用と月額費用に、開発者の待ち時間や障害の復旧にかかる費用も加えた、総保有コストで判断します。

対象の段階化と共通Workflowの先行整備

最初は代表的な1〜3リポジトリでPoCを行い、効果を確認してから対象を広げます。

  • 段階的に追加:PRチェック、stagingデプロイ、production承認
  • 共通処理を標準化:Reusable Workflowや社内Actionにまとめる

リポジトリごとの差分を入力値として切り出せば、後続の実装費と保守費を抑えられます。また、対象外のシステムまで一括で自動化しないことも、費用を守るための判断です。

実行時間と失敗による再実行の削減

不要なブランチや変更で重いテストが起動しないよう、トリガーとパス条件を設計します。

依存関係キャッシュやテストの並列化で、処理と待ち時間を短くできます。また、適切なRunnerサイズやmatrixの整理でも、処理と待ち時間を短くできます。

大きいRunnerは分単価も上がるため、短縮できる時間と料金の差を比べます。また、失敗の原因を放置すると、実行分数と確認時間が増えます。そのため、テストの安定化を優先します。

保存期間・予算上限・利用レポートの管理

ArtifactsやPackagesは用途ごとに保持期間を決め、リリースに必要な成果物だけを長く残します。請求画面で実行分数、ストレージ利用量、超過額を確認し、90%や100%に近づいた時点で通知します。

予算上限で利用が止まると、本番デプロイも止まる可能性があります。そのため、上限や通知先、緊急時の承認手順も設計しておきます。

見積もりを取る際のポイントと発注先の選び方

相見積もりでは、同じ条件で比べられるよう、依頼書を先に用意します。ライセンス販売だけの会社と、設計から保守まで担う会社では、見積もりの範囲が異なります。クラウドIAMやセキュリティ、教育も、どこまで担当するかを確認します。

価格とあわせて、成果物や担当範囲を確認します。前提条件と追加費用の条件も、見積もりの段階で確かめておきます。

提案依頼書で示す対象範囲と要件

依頼書には、対象範囲と必要な運用・セキュリティ要件を具体的に書きます。納品物も、あわせて指定します。

  • 対象と環境:リポジトリ数、言語、既存CI、テスト時間、デプロイ先、環境数
  • 運用・セキュリティ:Runner方式、ネットワーク制約、SSO、監査、Secrets、OIDC、通知、ロールバック、保守時間
  • 納品物:Workflow YAML、設計書、共通Actionソース、IaC、権限一覧、テスト結果、Runbook、教育資料

対象がまだ決まっていなければ、1〜3リポジトリのPoCと全体展開の概算を、分けて出してもらいます。

3社以上の費用と技術範囲の比較

発注先は、導入実績や技術範囲、費用の内訳を同じ条件で比べます。

  • 導入・移行:GitHub Enterprise、Workflow実装、既存CI移行
  • 技術範囲:AWS・Azure・Kubernetes連携、self-hosted Runner、セキュリティ、教育、保守
  • 費用項目:固定費、従量費、クラウド費、保守費、追加作業単価

失敗時の復旧や内製化の支援まで説明できるかどうかも、長期の費用を左右する判断材料です。

追加費用につながるリスクと対策

追加費用を防ぐには、実装の前に未確定事項と責任分担を洗い出し、契約条件に反映しておきます。

  • 環境・権限:テストが既存環境で動かない、クラウド権限申請が長引く
  • 運用担当:production承認者やRunner保守担当が未定
  • 安全確認:第三者Actionの安全性確認が後回しになる

未確定の事項を仮に置いた場合は、追加工数や変更管理、検収条件を契約書や提案書に残します。導入後は、Actionの更新やGitHubの料金変更を誰が確認するかも、保守範囲に含めておきます。

ポイント

相見積もりは、同じ依頼書の条件で比べられるかを基準に進めます。範囲の違う見積もりを並べても、金額の差は読み取れません。

よくある質問

GitHub Actionsの導入を検討する企業からは、費用と発注に関する質問が寄せられます。

GitHub Actionsは無料で使えますか?

公開リポジトリの標準Runnerやプラン内の無料分数では、追加料金なしで使える場合があります。

プライベートリポジトリでは、無料分数や保存容量を超えると従量課金が発生します。Runnerやストレージも、別に考えます。クラウドや導入支援費も、あわせて見ておきます。

公式案内によると、標準Runner向けの無料分数は、Freeが月2,000分、Teamが月3,000分、Enterprise Cloudが月50,000分です。

self-hosted Runnerにすると費用を下げられますか?

実行料金だけなら下がる可能性がありますが、必ず安くなるとは限りません。

サーバーやネットワークの管理、OS更新、監視は、自社で負担します。隔離や容量の管理、障害対応も、自社の作業になります。そのため、担当者の工数も含めて比較します。

特殊なビルド環境や閉域網が要らない場合は、まずGitHub-hosted Runnerで利用量を測り、実績をもとに移す方が判断しやすくなります。

GitHub Actionsの導入はどのような会社へ依頼すべきですか?

GitHubの機能に加え、CI/CD設計やクラウドIAM、セキュリティに対応できる会社を選びます。さらに、CI移行や教育、保守まで担えるかも確認します。

対象リポジトリ数やRunner方式、OIDCについて、具体的に説明できるかを確かめます。production承認やロールバックに関しても、同じ水準で答えられるかを見ます。

実装担当とクラウド担当の分業体制や、障害時の責任分界は、初期費用だけでは判断できない材料です。内製化したあとの支援も、長い目で見る材料です。

費用を正確に見積もるために何を準備すべきですか?

見積もりの前に、対象のリポジトリや既存CI、デプロイ先などを整理します。テスト時間や環境数、ユーザー数、Runnerの制約、クラウド権限、セキュリティ要件も、あわせて書き出しておきます。

PRチェックだけにするか、本番デプロイまで自動化するかを決めます。さらに、教育や保守を依頼するかどうかも決めておきます。

未確定の部分があっても、PoCの範囲と全体展開の前提を分けて伝えれば、初期費用と将来費用を分けた見積もりを受け取れます。

まとめ

開発費用の目安は、小規模で50万〜150万円、中規模で150万〜500万円、大規模・エンタープライズで500万〜1,500万円以上です。これは導入支援の推定レンジで、GitHubの契約費やRunnerの分数、ArtifactsやPackagesの保存、クラウド、保守は別途かかる場合があります。

価格だけでなく、初期構築、月額・従量費、追加作業の範囲も確認します。

費用判断の3層(初期・従量・運用)

初期費用では、調査や設計、実装を確認します。移行やテスト、セキュリティ、教育の費用も、あわせて見ておきます。

従量費では、Runnerの種類と分数を見ます。Linux、Windows、macOSの違いに加え、ストレージや外部クラウドの利用量も確認します。

運用費では、Actionの更新や監査、障害対応、内製化の支援を見ます。3層に分けて見ると、保守や従量料金の高い提案を見落としにくくなります。

対象範囲を絞った見積もり依頼

全社展開の費用は一つに決めず、PoCと標準化後の展開計画を分けて見積もります。

  • 対象範囲:代表リポジトリのPoCと標準化後の全社展開
  • 見積もり条件:リポジトリ数、既存CI、デプロイ先、Runner方式、セキュリティ、納品物、保守範囲

安全に定着させるには、安さだけでなく、開発速度の改善と運用責任を両立できる提案を選びます。

▼全体ガイドの記事
・GitHub Actionsのシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。