containerdのシステム開発は、要件整理から始めて、基盤選定、設計・実装、テストを経たうえで、段階的に稼働させ、運用を定着させる順で進めます。この流れに沿うと、業務を支える構成を整えられます。
全体像は、containerdのシステム開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・containerdのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
containerdのシステム開発の全体像
containerdは、レジストリからイメージを取得して保存・展開し、コンテナのプロセスを起動・停止するコンテナランタイムです。
複数ノードへの配置や自動復旧は、Kubernetesなどが担います。
一方で、基盤の検討には、レジストリ、OCIランタイム、ネットワークを含めます。さらに、ストレージ、監視、CI/CDも検討の対象になります。
containerdが担当する範囲の決定
containerdと周辺コンポーネントの役割を分けておくと、発注範囲を決めやすくなります。
- containerd：OCIイメージのpullと保存、snapshotterによるrootfs展開、コンテナとタスクのライフサイクル管理を担う
- OCIランタイム：低レイヤーのプロセス起動を担い、通常はruncなどが使われる
- Kubernetes利用時：kubeletがCRIプラグインを経由して、containerdに要求を送る
業務画面やAPI、データベースは、containerdの機能に含まれません。
複数ノードのスケジューリングも、containerdの範囲外です。そのため、サービス公開やログ分析、アラート通知は、別に設計します。
担当範囲が曖昧なままだと、Kubernetes設定やバックアップ、監視が見積もりから漏れるおそれがあります。そこで、契約前に構成図を作り、どこまでを誰が受け持つかを責任分界表にまとめます。
その際は、アプリとクラスタ、データとセキュリティのそれぞれについて、担当を明確にします。
Docker・Kubernetes・runcとの違い
各ツールの役割を分けて把握すると、移行範囲を整理できます。
- Docker：イメージのビルドや開発者向けCLI、レジストリ連携をまとめて提供する、開発体験の入り口
- containerd：Docker Engineの内部でも使われるが、Docker API、Compose、ビルド機能はそのまま提供しない
- Kubernetes：複数ノードへの配置、自己修復、ローリング更新を担うオーケストレーター
Kubernetes 1.24では、Docker Engineとの直接統合に使われていたdockershimが削除されました。
Kubernetes 1.26以降では、CRI v1対応ランタイムが必要です（出典：Kubernetes公式「Container Runtimes」、2026年8月確認）。
Dockerで作ったOCIイメージを使える場合でも、移行テストは工程ごとに行います。対象は、ビルド、実行、配布、監視の4工程です。
マネージド型と自社構築の比較
方式ごとの利点と運用条件を照らし合わせて選びます。
- マネージド型：短期導入や運用者不足に向き、control planeの管理をサービス側に寄せられる
- 自社構築：閉域網やエッジ拠点、既存設備との強い接続が必要な場合の候補
- 選定基準：クラウド依存による移行負担と、継続できる運用体制を比べる
EKS・GKE・AKSなどは標準構成を採りやすいため、containerdのパッチやノード更新の責任範囲も整理できます。
クラウド固有の認証やネットワーク、ロードバランサーへの依存が強い場合は、将来の移行作業が増えます。
オンプレミスでは、OSや証明書、etcdに加えて、CNIやCSIも自社または委託先が担います。ハードウェアやバックアップ、障害時の交換も含まれます。
containerdのシステム開発の進め方
開発は6つのフェーズに分けると、判断の抜け漏れを減らせます。フェーズは、要件整理から始まり、運用の定着で終わります。
各フェーズでは、成果物と完了条件を先に決めておきます。
次の工程へ進む前に、技術と業務の担当者に加えて、運用とセキュリティの担当者にも確認してもらいます。
フェーズ1：要件整理による業務と非機能の定義
最初に、「なぜコンテナ化するのか」を一文にまとめます。目的によって必要な構成と優先順位が変わるため、この一文をもとに後の判断を進めます。
- リリース頻度：変更を素早く届けること
- 環境差異：環境ごとの差の縮小
- アクセス変動：変動への対応
- 既存VM：段階的な置き換え
対象業務、利用者数、ピーク時間を一覧にします。既存サーバーや連携先、データの保管場所も、同じ一覧に入れます。
停止許容時間、目標復旧時間（RTO）、目標復旧時点（RPO）は、数値で定めておきます。数値がないと、障害時にどこまで戻せばよいかが曖昧になります。
レスポンスタイムや同時実行数、可用性も、数値で示します。
監査ログと個人情報の扱いも決めておきます。
「高可用性」とだけ書くと、ノード障害時にどれくらいで復旧するかが分かりません。そこで、ノード障害時の復旧時間を記載します。
バックアップを何世代残すか、夜間の障害を誰が判断するかも、要件に含めます。
この段階では、現行構成図や対象アプリ一覧、非機能要件をまとめます。データ移行方針と運用体制案、PoCの検証項目も成果物になります。
DBやファイル共有をコンテナ化するか、本番と開発でクラスタを分けるか、24時間監視が必要かは、ここで決めておきます。そうすると、後工程の追加費用を抑えやすくなります。
フェーズ2：実行基盤とサービスの選定
基盤の選定では、次の方式を要件に照らして比較します。
- マネージドKubernetes：クラウド事業者のサービスとして提供される
- 商用コンテナプラットフォーム：製品の機能と支援を受けられる
- 自社構築：containerdとKubernetesを自社で運用
可用性やデータの保管場所、既存ネットワークとの接続を評価します。また、クラウドへの依存度と、アップデートの責任を比べます。監査機能や社内人材も、比較の対象です。
5年間のTCOも比べます。containerdの設定だけでなく、ノードと周辺サービスも含めて評価します。
バージョンの選定では、Kubernetesのサポート期間を確かめます。そのうえで、containerd、CRI、runcの組み合わせを一つの表にまとめます。OS、CNI、CSIとの互換性も、同じ表に書き込みます。
containerd公式によると、2026年4月の2.3はLTSとして2028年4月までサポートされます。一方で、2.2は2026年11月までActiveです（出典：containerd公式「Versioning and release」、2026年8月確認）。
採用時点の最新版だけでなく、更新時期と移行手順も選定条件に含めます。
小さなサンプルアプリを使い、ビルドからレジストリへのpush、containerdによるpull、起動までを確かめます。
ログ取得、停止、再起動も試します。
既存のDocker ComposeやCI/CDがある場合は、ビルド機能と実行機能を分けて考えます。
nerdctl、crictl、kubectlのどの操作を誰が使うかも、決めておきます。
フェーズ3：基盤とアプリケーションの設計・開発
基盤とアプリケーション、開発環境は、一連の設計作業として整理します。
- 基盤の構成と、containerdの設定項目の定義
- Kubernetesの設定と、業務の可用性要件との結び付け
- アプリの設定とデータ移行の条件の整理
- Infrastructure as Codeによる環境の再現
- CI/CDへの検査、承認、デプロイ、ロールバックの組み込み
ノード数やサイズ、クラスタと環境の分け方を決めます。
containerdのconfig.tomlやCRI、cgroupドライバも定めます。
snapshotterやイメージレジストリも設計します。
ネットワークと永続ボリュームも、設計の対象です。
Kubernetesでは、NamespaceとRBACを設定します。NetworkPolicyとIngressも組み込みます。Podのリソース要求とPodDisruptionBudgetも、あわせて設定します。
アプリ側では、Dockerfileに含まれる不要な権限や秘密情報を見直します。そのうえで、環境変数とSecret、設定ファイルを分けます。
状態を持たないAPIやバッチは、コンテナ化しやすい構成です。一方、DBや共有ファイルは、永続ボリュームの扱いを検証してから移行対象を決めます。バックアップやリストア、障害復旧も、あわせて確かめます。
CI/CDの検査項目には、脆弱性スキャンやSBOM生成、署名またはダイジェスト固定を含めます。承認の工程も組み込みます。
検証環境へのデプロイから本番への昇格、ロールバックまでを一つの流れにし、手作業だけに頼らない形を作ります。
フェーズ4：機能・性能・障害復旧のテスト
機能と性能、障害復旧を、利用者の業務シナリオに沿って検証します。
- 機能テストで、コンテナと業務シナリオの動作を確かめます
- 性能テストで、負荷とリソース使用量を測ります
- 障害テストで、停止や復旧の挙動を見ます
- 結果を記録し、合格基準を満たしてから本番へ進めます
機能テストでは、イメージの取得やPodの起動、設定の反映を確かめます。
ログ出力やヘルスチェック、サービス接続も確認します。
永続データの読み書きやローリング更新、ロールバックも試します。
CRI経由の動作は、crictlで確かめます。
機能検証では、実際の利用者が行う業務シナリオも対象にします。開発者のローカル操作だけで終わらせないためです。
性能テストでは、平常時とピーク時の同時利用数や起動時間を測ります。加えて、リソース使用量をCPUとメモリ、ディスクとネットワークに分けて確かめます。
コンテナ数を増やしても、必ず速くなるとは限りません。そこで、アプリのボトルネックとDB接続数を分けて分析します。
イメージサイズ、snapshotterのI/O、ノードの空き容量も確認します。
障害テストでは、ノードの停止やcontainerdの再起動を試します。runcやイメージ取得の失敗、レジストリの停止も対象です。
ディスクの枯渇やネットワーク断、PodのOOMも検証対象です。バックアップからのリストアも、そこに含まれます。
各テストでは、検知の状況や通知先、切り分け時間を記録します。業務データの損失の有無と、再発防止の状況も残します。
フェーズ5：段階的な稼働
本番への切り替えは、対象を絞って段階的に行います。業務の周期を一周するまで、状態を確認し続けます。
- 影響の小さい機能や限定ユーザーから始め、切り戻しの判断者、作業時間、連絡網、バックアップ取得時刻、データ同期の確認方法を事前に決めます。
- ブルーグリーン、カナリア、段階移行から、業務の停止許容時間に合う方式を選びます。
- 稼働当日は、基盤と業務の状態を見守ります。
- 初回リリース後の数時間では判断せず、日次バッチや月次締め、ピークアクセスなど業務の周期を一周するまでを安定化期間として扱います。
特に注意して見る項目は、クラスタとノードの状態、containerdのログ、イメージのdigest、Podの再起動数です。
エラー率やレスポンスタイム、データ連携、監査ログも確認します。
フェーズ6：運用の定着と改善
構築した基盤を、誰が、どの手順で、どの時間帯に運用するかを文書にします。
- 日次：アラートの確認
- 週次：容量の確認
- 月次：パッチ計画の策定
- 四半期：復旧訓練の実施
作業の頻度と担当者は、運用カレンダーに記します。障害時の確認の順序は、runbookにまとめます。
障害時の切り分けでは、containerdやKubernetes、ネットワーク、ストレージ、アプリのどこから調べるかを先に定めておきます。
セキュリティ面では、ホストOSやcontainerd、runc、shimを継続して更新します。containerdソケットへのアクセスは、特権相当として扱います。
公式指針は、レジストリのHTTPS、信頼できるプラグイン、ダイジェスト固定を推奨しています。
Seccomp・AppArmor・SELinuxの利用とディスク容量監視も推奨されています（出典：containerd公式「Operator Security Guidelines」、2026年8月確認）。
イメージの脆弱性や依存ライブラリを、SBOMや署名とあわせて定期的に洗い出します。廃止予定のバージョンも、対象に含めます。
経済産業省と国家サイバーセキュリティ室は2025年9月、SBOM共有ビジョンに署名しました（出典：経済産業省「A Shared Vision of Software Bill of Materials for Cybersecurity」、2025年）。
この動きは、脆弱性管理とソフトウェアサプライチェーンの透明性に向けた取り組みです。そのため、調達の時点から、部品表と脆弱性対応の役割を確認します。
containerdのシステム開発の費用相場
containerd単体の受託開発には、統一された公開価格がありません。費用を左右するのは、ランタイムの設定よりも、対象アプリの改修やデータ移行です。クラスタ数や環境数も影響します。
可用性や監視、セキュリティ、保守体制も費用を左右します。次に示す金額は、一般的な業務システムの費用データと追加作業に基づく編集上の推定です。
個別案件の確定価格ではないため、規模や要件を決めたうえで見積もりを取ります。
初期開発費の規模と移行範囲による違い
初期費は対象規模と移行範囲で異なるため、金額と期間をあわせて比較します。
- 学習環境・小規模PoC：100万〜300万円程度、2〜6週間程度
- 数ノードの小規模本番：500万〜1,500万円程度、2〜4か月程度
- 業務システム改修・データ移行込み：1,500万〜5,000万円程度、6〜12か月程度に広がる可能性
- 大規模案件：複数クラスタ、マルチAZまたはマルチサイトなどを含む場合、5,000万〜2億円以上、12〜24か月程度
PoCには、containerdとレジストリ、簡易CIを含みます。基本監視とサンプルアプリも、その範囲に入ります。既存ネットワークや認証を接続する場合は、費用や期間が増えます。
PoCで確かめるのは、起動や更新、ログ、監視、障害復旧の技術リスクです。本番の完成を目指す段階ではありません。
小規模本番の費用には、要件定義、ネットワーク、Kubernetes、containerdを含みます。CI/CD、ログ・監視、バックアップ、運用手順も含まれます。
金額と期間は、業務システム費用とコンテナ基盤の追加作業から算出した編集上の目安です（出典：本記事のリサーチノート「業務システム全般_12」の費用データ、2026年）。
ノード数と移行対象が定まらないまま、金額だけで比べると判断を誤るおそれがあります。
クラスタ以外も含むクラウド利用料の算出範囲
クラスタ管理料以外の利用料も含めて、サービスごとの条件を分けて試算します。
- 共通費用：ノード、ディスク、ロードバランサー、パブリックIP、ログ、レジストリ、バックアップ、データ転送
- EKS標準：1クラスタ・1時間あたり0.10米ドル
- EKS延長：1クラスタ・1時間あたり0.60米ドル
- GKE：1クラスタ・1時間あたり0.10米ドル。ゾーンまたはAutopilotには請求アカウント単位で月74.40米ドルの無料枠
- 追加条件：GKEのリージョンクラスタは無料枠対象外。Compute Engine、ストレージ、ネットワークは別料金
EKSを730時間稼働させる場合、標準サポート部分だけで約73米ドルです（出典：AWS公式「Amazon EKS pricing」、2026年8月確認）。ノードやストレージなどは含まれないため、月額を把握するには、それらの費用も合わせて確認します。
GKE料金は、Google Cloud公式「Google Kubernetes Engine pricing」を2026年8月に確認しました。
為替やリージョン、割引契約によって円換算は変わります。そのため、見積もりには通貨と料金の確認日も記載します。
保守・運用費の初期費用との分け方
保守契約の範囲と継続費用を、初期費用から分けて把握します。
- 更新・セキュリティ：containerd・runc・OS・Kubernetesの更新、脆弱性調査
- 日常運用：レジストリ管理、ログとメトリクスの保管、バックアップ確認
- 障害・改善：障害時の一次切り分け、改善改修
業務システムでは、保守・改修費を初期開発費の年15〜20%程度とする考え方があります。
24時間監視やオンコールを含む基盤の保守費は、この比率とは別に確かめる必要があります（出典：本記事のリサーチノート内の業務システム保守データ、2026年）。
「OSSなのでライセンス費用はかからない」という説明を聞いたら、夜間対応や更新検証を誰が担うかを確認します。
障害時の復旧保証も確認します。初期費用、クラウド実費、保守契約、社内人件費を合算し、3年または5年のTCOで比べます。そうすると、自社構築の運用負担も見えてきます。
containerdのシステム開発で見積もりを取る際のポイント
見積もりの金額差は、技術力の違いだけでなく、作業範囲の違いからも生まれます。そのため、複数社に同じ条件で依頼します。
対象アプリや環境数、ノード数、可用性はRFPに記載します。データや運用時間、納品物、検収条件も記載します。各社の前提は、同じ表で比べます。
見積もりの作業範囲と納品物
作業範囲は、次の工程ごとに分けて記載します。
- 調査・設計：現状調査、要件定義、PoC、クラスタ設計
- 基盤：containerd設定、レジストリ、ネットワーク、ストレージ
- 開発・検証：CI/CD、監視、セキュリティ、アプリ改修、データ移行、テスト
- 移行後：教育、稼働支援
containerdのインストールだけが安くても、業務アプリのコンテナ化やリリース自動化が別料金なら、総額で判断します。
納品物では、構成図や設計書、IaCを確認します。containerdの設定やKubernetesマニフェスト、CI/CD定義も、納品に含まれるかを確かめます。
監視・アラート一覧やバックアップとリストアの手順も、対象に含めます。障害対応のrunbookと脆弱性対応の方針、教育資料も、対象です。
ソースや設定を自社で再利用できる形式か、特定ベンダーの管理画面だけに閉じていないかも確認します。
見積もりの数量と前提条件
見積もりでは、次の数量を前提として明記します。
- 基盤規模：クラスタ数、ノード数、CPU・メモリ、環境数、リージョン数
- 保管量：レジストリ容量、ログ保存期間、バックアップ世代
- 利用規模：同時利用者数、ピーク時間
- 移行範囲：移行対象の画面数とAPI数
「中規模」や「高可用性」「大量アクセス」といった言葉は、会社によって意味が異なります。そのため、数量や目標値に置き換えて書きます。
見積もりの有効期限や、クラウド料金の変動、為替の扱いを確認します。ライセンスや既存契約の再利用も、確認の対象です。
データ移行の品質や休日・夜間作業、交通費も、見積もりの前提に入ります。教育や追加要員の単価も、対象になります。
前提が変わったときに増減する項目や作業単価、変更管理の方法が明示されていると、後から比較しやすくなります。
検証基準とリスク分担の契約条件
検収と契約で確かめる内容は、合格条件と責任分担に分けて整理します。
- 検収条件：業務シナリオ、性能値、可用性、復旧時間、バックアップ復元、ログ、アラート、権限、脆弱性スキャン、ロールバック
- 合格基準：Pod起動だけでなく、業務を継続できること
- 費用負担：想定外のアプリ改修、データ品質、クラウド仕様変更、サポート切れ、緊急対応の担当
- 保守責任：各バージョンの更新期限、パッチ、重大障害の連絡・復旧目標、契約終了後の引き継ぎ
更新の責任があいまいだと、サポート期限が来た後の対応を誰が担うのかが決まらなくなります。契約では、こうした対応の担当を先に書いておきます。
ベンダーの実績と運用体制
導入経験と本番後の支援内容を分けて比べ、類似案件を担当した人が関わるかを確かめます。
- 技術実績：containerd、Kubernetes、EKS・GKE・AKS、オンプレミス、ネットワーク、永続ストレージ、監視、既存VM移行
- 案件の範囲：containerd単体か、Kubernetes基盤や業務アプリも含むか
- 運用支援：一次切り分け時間、オンコール、月次報告、パッチ検証、障害訓練、改善提案、問い合わせ回数・対応時間、追加改修単価
似た要件を担当した人が、提案と運用の両方に参加するかも確認します。
よくある質問（FAQ）
containerdの開発では、Dockerとの違いや導入費用、セキュリティ、運用体制について、よく質問が寄せられます。発注や移行の判断に関わる疑問に答えます。
containerdを導入すればDockerは不要になりますか？
Dockerが不要になるとは限りません。containerdは実行基盤であり、Dockerの機能をすべて代わりに担うものではありません。
Dockerが提供してきたイメージビルドやCompose、開発者向けの操作とレジストリ連携が、必要になる場合があります。
ビルドはBuildKitなど、実行はcontainerd、オーケストレーションはKubernetesという分担になる場合があります。
containerdのnamespaceだけでテナントを安全に分離できますか？
containerdのnamespaceは、イメージやコンテナを管理上で分ける仕組みです。強いセキュリティ境界として扱わないほうが安全です。
複数テナントの分離には、要件に応じてKubernetesのNamespace、RBAC、NetworkPolicyを組み合わせます。
ノード分離やクラスタ分離、rootlessやuser namespaceも検討します。ホストOSの権限も、検討の対象です。
マネージドKubernetesと自社構築はどちらが向いていますか？
重視する条件と運用体制に応じて方式を選びます。
- マネージドKubernetes：短期導入や標準構成、運用人材の不足を重視する場合
- 自社構築：閉域網や既存設備、細かなランタイム制御、クラウド依存の抑制が必要な場合
自社構築では、アップデートや証明書の管理、障害復旧と監視を続けられる体制が必要です。
初期費用だけでなく、3〜5年のTCOと運用責任で比較します。
containerdのシステム開発はどの段階で外注すべきですか？
本番運用や移行に不安がある場合は、要件整理またはPoCから外部支援を検討します。
- 停止・移行リスク：本番業務を止められない、既存VM移行やデータ連携がある
- 運用要件：24時間監視や監査が必要、社内のKubernetes運用経験が少ない
- 依頼の進め方：現状調査、技術検証、設計書、運用手順を段階的に依頼
本番構築をいきなり任せず、自社に知識と成果物が残るかを確かめます。
containerdのシステム開発にはどのくらいの期間がかかりますか？
期間は、インストール日数だけでなく、対象範囲や移行作業も含めて見積もります。
- 小規模PoC：2〜6週間
- 小規模な本番基盤：2〜4か月
- 既存業務システムの改修・移行込み：6〜12か月程度かかる可能性
期間を左右するのは、要件整理やアプリ改修、データ移行です。性能試験や利用者教育、稼働後の安定化も、期間に影響します。
対象範囲を分けてPoCの合格条件を定め、その後に本番計画を作ると、現実的な日程を組みやすくなります。
まとめ
containerdのシステム開発は、6つのフェーズで進めます。要件整理から始めて、定着までを順に行います。
containerdは実行基盤であり、Kubernetesやrunc、レジストリと組み合わせて使います。ネットワークやストレージ、CI/CD、監視、セキュリティも、あわせて設計します。
どこまでを誰が受け持つかを構成図と見積もりに反映し、業務システムを支える構成を整えます。
成功させるための最終チェックリスト
発注前には、目的と対象業務、RTO・RPO・性能・監査の数値を確認します。基盤や保護・運用、契約の内容も、見積もりと運用設計に反映します。
- 目的・要件：対象業務、RTO・RPO・性能・監査の数値
- 基盤：マネージド型か自社構築か、各ソフトの対応バージョン
- 保護・運用：データ、バックアップ、署名、SBOM、脆弱性、監視、障害復旧
- 契約：納品物、保守範囲、クラスタ管理料以外のTCO
namespaceを、セキュリティの境界と見なさないよう注意します。
小さなPoCから始める進め方
まずは代表的なアプリで、本番移行の判断材料を確かめます。全業務を一度に移さないためです。
- イメージ生成、レジストリ連携、containerdによる起動の検証
- ログ、監視、更新、障害復旧、データのバックアップとリストアの確認
- PoCの合格条件と、本番移行の判断者の決定
PoCの条件を決めておくと、費用とリスクを把握しやすくなります。自社に合う構成と開発会社を選ぶ判断にもつながります。
▼全体ガイドの記事
・containerdのシステム開発の完全ガイド
▼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を創業。