microCMSのシステム開発の完全ガイド - ブログ

microCMSのシステム開発は、コンテンツの管理、表示するフロントエンド、業務システムを分けて設計するのが基本です。情報発信と業務処理を両立しやすくなり、発注側は役割の分担を押さえるだけで全体像をつかみやすくなります。

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

microCMSのシステムの概要

表示側を分けることで、同じコンテンツを複数の公開先へ届けられます。

microCMSは、コンテンツを登録・編集する管理画面と、表示を担当するフロントエンドを分けたヘッドレスCMSです。

管理画面に入力した記事やニュース、商品、施設、FAQなどを、Content APIで取得します。その情報を、Webサイトやスマートフォンアプリ、デジタルサイネージなどに配信する形です。

CMSで管理する情報と業務システムに残す情報の分け方

microCMSと業務システムは、扱う情報の性質に応じて役割を分けて使います。

編集・配信する情報：人が編集し公開先へ配信するニュース、ブログ記事、採用情報、商品紹介、施設情報、キャンペーン、よくある質問。
専用システムで扱う情報：受注、在庫引当、請求、会員認証、決済、給与。

整合性やトランザクションが重要なデータは、既存の業務データベースや専用システムを正とするのが基本です。

業務データをmicroCMSへ複製する場合は、公開に必要な項目に絞ります。連携には、Webhook、バッチ、APIゲートウェイなどを使い、疎結合にします。

個人情報や更新頻度の高い基幹データを集めすぎると、権限管理、バックアップ、削除依頼への対応範囲が広がります。そのため、最初にデータの責任範囲を決めておきます。

ヘッドレス構成での表示部分の設計

従来型CMSとヘッドレスCMSでは、管理画面と表示画面の構成が異なります。

従来型CMS：管理画面とテンプレートが一体で、同じテーマで表示します。
ヘッドレスCMS：microCMSがコンテンツとAPIを受け持ちます。
表示側：Next.js、Nuxt.js、Astro、React、Vueなどによる実装。

同じコンテンツをWeb、アプリ、サイネージへ配信できるため、フロントエンドだけを刷新しやすくなります。

ヘッドレスCMSは自由度が高い一方で、URL設計、SEO、キャッシュ、プレビューなどを開発側で設計する必要があります。フォーム、検索、アクセシビリティ、エラー時の表示も、設計の対象です。

管理画面が使いやすくても、サイトが短期間で完成するとは限りません。そのため、CMSが担う範囲とフロントエンドで作る範囲を、見積もりの段階で分けておくことが大切です。

向いているケースと、別の仕組みを検討すべきケース

microCMSは、人が編集して公開先へ配信する情報の管理に向いています。

サイト運営：コーポレートサイトやオウンドメディア。
複数組織の発信：自治体、金融機関、複数ブランドや拠点。
情報の一元管理：商品情報や施設情報。

更新担当者は、定めた入力項目とレビュー手順に沿って公開できます。開発者へ毎回依頼せずに済むため、情報発信のスピードを上げやすくなります。

複雑な在庫引当、リアルタイム決済、会員ごとの権限判定、個人情報を含む業務処理をCMS単体で完結させる場合、要件を満たせない可能性があります。

そこで、公開コンテンツはmicroCMSで編集・配信し、認証や取引処理は専用システムに任せる構成が考えられます。役割を分けて連携すれば、要件に対応できる可能性があります。

ポイント

CMSで扱う情報と業務システムに残す情報を分けられるかが、導入判断の出発点です。公開先が増える予定があれば、ヘッドレス構成とCMSの向き不向きを合わせて見ると判断しやすくなります。

microCMSの主な機能とシステム構成の種類

microCMSの機能は、コンテンツを作る機能、公開フローを管理する機能、外部へ連携する機能に分けると理解しやすくなります。

プランによって、メンバー数、API数、権限、転送量、監査、環境管理などが変わります。そのため、機能の有無だけでなく、誰がどの頻度で使うかまで確認します。

コンテンツ管理と編集者向け機能

コンテンツ管理では、種類ごとのAPIと入力項目を定義します。

入力項目：タイトル、本文、画像、カテゴリー、公開日、関連コンテンツ。
編集機能：リッチエディタ、カスタムフィールド、コンテンツ参照。
素材管理：画像・ファイル管理、CSV入出力。

リッチエディタなどの機能は、入力内容のばらつきを抑えた運用に役立ちます。

複数人で更新する場合は、予約投稿とレビュー、ワークフローが役立ちます。メンバーの役割分けや編集履歴も、あわせて使うと管理しやすくなります。

機能を増やすほど、入力ルールと公開責任の設計が欠かせません。下書き、レビュー、公開のそれぞれを誰が担うかは、承認条件とあわせて業務フローに記しておきます。

Content APIと外部サービス連携

Content APIは、登録したコンテンツをフロントエンドから取得する窓口です。

更新通知：Webhookでコンテンツの更新を通知します。
運用自動化：マネジメントAPIやSDKを利用できます。
外部機能：検索、フォーム、認証、分析、翻訳などの外部サービスと連携。

業務データベースも含め、要件に応じて別サービスや自社APIを組み合わせます。

料金ページには、AIレビュー、AIエージェントによる入稿、MCPサーバーなどの連携機能も掲載されています。

AI入稿を使う場合も、公開前レビュー、権限、誤情報の確認、個人情報の入力禁止を運用ルールに定めます。そのうえで、編集品質と公開速度をどう改善するかを基準に導入を検討します。

フロントエンドとホスティングの組み合わせ

microCMSとは別に、表示側のフレームワークとホスティング環境を選びます。

小規模：既製テンプレートとクラウドホスティングの組み合わせ。
中規模：検索や移行を含む追加開発。
大規模：複数環境、監査、IP制限、SLA、シングルサインオン。

静的生成やサーバーサイドレンダリングは、表示速度やアクセス集中への対応を設計しやすくします。

再ビルドのタイミング、プレビュー、キャッシュ無効化、フォーム障害時の処理は実装課題です。そのため、CMS選定の時点で、公開後の監視や復旧方法も確認します。

microCMSのシステム開発の進め方

前段階で決めた内容が、次の設計と検証の土台になります。

開発は、いきなりAPIを作り始めるのではなく、目的、コンテンツ、業務フロー、公開先の順に整理するところから始めます。そのうえで設計に進み、小さなMVPで検証する流れが基本です。

特にヘッドレスCMSでは、管理画面の設計と表示画面の設計が別々に進みます。そのため、コンテンツモデルを共通言語にして、関係者の認識を揃えやすくします。

▶ 詳細はこちら：microCMSのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

1. 目的とコンテンツの定義

サイトやアプリで達成したいKPIを先に決めておくと、必要なAPI、権限、連携方式を選ぶときの判断の軸になります。目標と並行して、現行サイトの状態と移行の条件も把握しておくと、設計の手戻りを減らせます。

目標：更新時間の短縮、複数拠点の情報一元化、公開先の拡大。
現行サイト：URL、ページ種別、公開状態、画像、担当部署。
移行条件：更新頻度と移行の可否を洗い出します。

コンテンツは「ページ」単位でまとめず、再利用する単位に分けて整理します。

施設情報を複数のページやアプリで使う場合は、名称や住所、営業時間などを独立したモデルにします。画像、説明、関連リンクも、同じモデルに含めます。入力項目が曖昧なままだと、公開後にフィールドを追加したり、データ移行をやり直したりすることになります。

2. API、権限、公開フローの設計

次に、APIごとのフィールドと必須入力を定めます。文字数や画像サイズの制限、関連付けも、同じ単位で決めておきます。公開期間も忘れずに含めます。

あわせて、編集者、レビュアー、管理者の役割を分けます。そのうえで、下書き、レビュー、公開、公開終了の状態の移り変わりを決めます。

複数ブランドや拠点がある場合は、全体管理と各現場の編集範囲を分ける設計が欠かせません。

外部連携では、どのシステムを正とするかを先に決めます。そのうえで、同期の方向と更新頻度を定めます。失敗時の再実行や重複登録の防止も、あわせて決めておきます。

フォームや会員機能を追加する場合も、個人情報をmicroCMSへ保存する必要があるのかを検討します。保存しない設計にできれば、権限と削除対応の負担を抑えられます。

代表的な記事、一覧、詳細、検索、フォームを含む小さなMVPの作成
編集者による入力、プレビュー、レビュー、公開後の修正の確認
移行、公開後の監視、研修、手順書の引き渡し

3. 小さな検証を経た移行・リリース

全ページを一度に作る代わりに、代表的な機能を含む小さなMVPで検証します。

記事、一覧、詳細、検索、フォームを含むMVPの作成
編集者による入力（入力しやすさ、プレビュー、レビュー）の確認
公開後の修正、表示速度、スマートフォン対応、SEO（タイトル、構造化）、アクセシビリティの試験
URL対応、リダイレクト、画像パス、公開日、著者、カテゴリーを決めた移行
公開後のアクセス解析、エラーログ、API応答、フォーム送信、検索結果の監視と、運用担当者への操作研修、手順書の引き渡し

移行では、canonicalとnoindexの扱いも決めておきます。公開後の監視と引き継ぎは、リリース工程の一部として含めます。

ポイント

開発は、目的とコンテンツの定義を先に固め、そのあとで権限や公開フローを設計する順に進めると、手戻りを抑えやすくなります。途中で迷ったら、決めた内容がMVPで動くかを基準に戻ると判断しやすくなります。

microCMSの費用相場とコストの内訳

規模が上がるにつれて、見積もりの幅も広がります。

microCMSの費用は、サービス利用料と開発費を分けて考えます。

利用料が低くても、フロントエンドやデザイン、既存データの移行の費用が必要になる場合があります。検索やフォーム、外部システム連携、テスト、保守にも、別途費用がかかることがあります。

以下の金額は案件の条件で変わるため、発注前の予算の仮置きとしてご利用ください。

▶ 詳細はこちら：microCMSのシステム開発の見積相場や費用/コスト/値段について

プラン、API数、転送量で変わるサービス利用料

2026年8月確認の公式料金では、Hobbyは0円、Teamは月4,900円からです。

Businessは月75,000円からで、Enterpriseは個別見積もりです（出典：microCMS公式料金ページ、2026年）。

Teamは転送量200GB、Businessは1TBが基準です。超過分は1GBあたり、Teamが20円、Businessが18円です。また、メンバー追加は1人あたり月1,200円、API追加は1個あたり月2,000円が目安です。

プランは、必要な上限や運用機能に応じて選びます。

Hobby：小規模検証向け。APIは5個、コンテンツは1万件まで。
Team：小規模チームや運用機能を試す場合。
Business：権限管理、IP制限、復元、複数環境が必要な標準的な案件。
Enterprise：監査ログ、SLA、シングルサインオン、専任サポートが必要な大規模案件。

料金体系は2025年6月10日に改定されました。Advancedの新規申し込みは終了し、Enterpriseへ統合されています。過去の記事に載っている料金は使わず、見積もりの時点で公式料金を確認します。

開発委託費の幅（150万円〜3,000万円以上）

サイト規模と必要な開発範囲を分けると、費用と期間の違いを見積もりやすくなります。

小規模：150万〜400万円、1〜3か月程度。
中規模：400万〜1,200万円、3〜6か月程度。
大規模：1,000万〜3,000万円以上、6〜12か月程度の場合があります。

小規模はコーポレートサイトやブログ1サイトで、デザイン、フロントエンド、API設定、公開環境、操作説明まで含む想定です。

中規模はメディアや会員向け情報サイトで、複数モデル、検索、移行、分析、外部API連携を含む想定です。

大規模案件には、複数ブランド・拠点や金融・自治体などの非機能要件を含む場合があります。既存業務システム連携、アクセシビリティ、負荷試験、脆弱性試験も、対象になり得ます。

この金額は、microCMS公式の一律価格ではなく、一般的な業務システム相場と導入工数をもとにした推定です。見積もりを比べるときは、金額だけでなく工程も比較します。

保守・運用費と見積もりの分け方

保守・改善費は、初期開発費の年15〜25％程度、または月15万〜80万円程度が目安です。

保守範囲：更新代行だけか、障害対応や監視まで含むか。
改善範囲：脆弱性・ライブラリ対応、軽微な改修、解析、改善提案。

月額に含まれる作業と、別途見積もりになる作業は、契約書に明記します。

見積書は、開発、導入、運用の三つに分けて示します。

開発項目：microCMS利用料、デザイン、フロントエンド、API・モデル。
導入項目：データ移行、外部連携、SEO・アクセシビリティ、テスト。
運用項目：研修、手順書、保守。

要件定義や受入試験を「一式」とせず、作業量と成果物を示してもらいます。そのため、追加費用の条件も把握できます。

ポイント

費用は、サービス利用料と開発委託費を分けて見積もると比べやすくなります。見積もりは金額だけでなく、工程や保守の範囲をそろえて比べることが大切です。

microCMSのシステム開発会社・ベンダーの選び方

開発会社やベンダーを選ぶときは、microCMSを使った制作実績の数よりも、要件定義から移行、運用保守までの対応範囲を見ます。

ヘッドレスCMSの導入では、管理画面の設定より、コンテンツモデル、表示側、既存システムとの境界、公開後の責任分担が成否を左右します。

同規模・同業種の実績と対応範囲

候補企業の実績は、自社と近い規模や要件を基準に確認します。

案件規模：コンテンツ数、更新者数、サイト数、アクセス規模、公開先。
担当範囲：microCMSで管理する部分と、フロントエンドや外部システムで実装する部分を質問します。
類似経験：多言語、検索、サイネージ、アプリ、会員、基幹連携。

要件定義から公開後の保守までを一社で担うか、別会社と分担するかを確認します。

引き渡し条件が曖昧だと、内製化や会社の切り替えが難しくなります。ソースコードやインフラ設定、デザインデータ、API仕様書、運用手順書は、引き渡しの範囲を明確にしておきます。

技術・セキュリティ・移行に関する質問の具体化

提案依頼では、技術・移行・アクセシビリティの確認事項を具体化します。

APIキー：保管場所、GETと書き込み権限の分離、サーバー経由の有無。
移行：件数、画像、カテゴリー、URL、転送、テスト、差分確認。
アクセシビリティ：見出し、代替テキスト、操作、コントラスト、フォーム。

障害時の連絡窓口と復旧目標は、提案ごとに比べます。バックアップや脆弱性情報への対応、ライブラリ更新、追加改修の単価も、同じ観点で比較します。

見積もりの金額よりも、提案書に自社の要件とリスクへの回答が含まれているかを確かめます。担当者が専門用語を運用担当者にも説明できるかも見ます。

提案と見積もりの同条件での比較

複数社へは同じ条件を伝え、提案の前提をそろえます。

共通資料：サイト、ページ数、API、移行件数、公開予定日。
運用条件：更新者数、連携先、必要なセキュリティ要件。
比較項目：価格、納期、実績、提案、体制、保守、内製化支援。

前提が異なるまま金額だけを比べると、移行やテストが含まれない提案を安く感じることがあります。

公式パートナーであるかどうかは、候補を選ぶ材料の一つです。ただし、業務要件に合うことまでは保証されません。初回の提案では、MVPの範囲、追加開発の条件、公開後90日程度の支援内容を確かめます。

▶ 詳細はこちら：microCMSのシステム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら：microCMSのシステム開発の発注/外注/依頼/委託方法について

ポイント

開発会社は、制作実績の数より、要件定義から移行、運用保守までの対応範囲で比べると、依頼後の認識差を減らせます。提案は同じ条件で受けて、前提をそろえてから比べます。

セキュリティ・法務・公開後の運用上の注意点

セキュリティは、microCMSを採用しただけでは完結しません。

APIキーや管理画面のアカウント、入力されたHTMLを含め、システム全体でリスクを確認します。公開前のデータや外部連携、フロントエンドの依存ライブラリも対象です。

CMSのサービス側と自社開発側の責任の境界も、RFPと契約に明記します。

APIキーの最小権限化と書き込み権限の非公開

APIキーには、GETや下書き取得、POST、PUT、PATCH、DELETEなどの権限があります。

公開サイト：必要なAPIのGET権限だけに絞ります。
書き込みキー：サーバー側か安全な管理環境だけで使います。
ブラウザから呼ぶ場合：公開情報のGET専用キーに限定します。

権限によって外部から書き込みや下書きの取得が可能になり、キーが漏れると不正操作につながる場合があります（出典：microCMS公式ドキュメント「APIキー（APIの認証と権限管理）」、2026年6月更新）。

そのため、APIごとの権限や、キーの用途・保管場所・ローテーションを運用手順に含めます。退職者や委託先のアクセスは、削除の手順も決めておきます。

個人情報、ISMS、ISMAP、アクセシビリティの分けた確認

個人情報、認証、調達要件は、それぞれ分けて確認します。

個人情報：組織・人的・物理的・技術的対策、委託先監督、漏えい時の連絡と調査。
ISMS：サービスの認証取得と自社要件への適合は別に判断します。
官公庁・自治体：ISMAPや独自のセキュリティチェックシートへの適合も別途確認します。

公開画面は、JIS X 8341-3:2016やWCAG 2.2を参照して検証します。確認するのは、見出し、代替テキスト、コントラスト、キーボード操作、フォーカス、フォームのエラー説明です（出典：デジタル庁「ウェブアクセシビリティ」、2026年確認）。

CMSで代替テキストを必須にするのに加えて、表示と操作も受入条件に含めます。

公開後のコンテンツ運用と技術運用の分担

公開後は、コンテンツ運用と技術運用を分けて進めます。

コンテンツ運用：編集カレンダー、レビュー期限、表記ルール、画像サイズ、公開終了日、緊急時の差し替え手順。
技術運用：APIやホスティングの監視、エラー通知、バックアップ、ライブラリ更新、脆弱性対応、アクセス解析。
継続体制：管理画面の操作、連携処理、復旧手順を文書化し、担当者が変わっても運用を続けます。

AIレビューや自動入稿では、内容の正確性、著作権、個人情報、公開承認者を明確にします。自動化を広げるほど、誤公開を止める仕組みとログ確認が重要です。

月次で、KPIや検索流入、更新時間を振り返ります。エラーや問い合わせの状況も踏まえて、必要なAPIや入力項目を改善します。

ポイント

APIキーの権限、個人情報の扱い、アクセシビリティ、公開後の運用は、別々に考えず、受入条件としてまとめて扱うことが大切です。

導入前のチェックポイント

導入を判断するときは、料金や画面の使いやすさに加えて、運用開始後に困りそうな条件を先に洗い出しておくことが大切です。次の項目をRFPや社内稟議に入れておくと、開発会社との認識の差や追加費用を抑えられます。

業務とデータの確認項目

業務とデータの範囲は、次の項目で確認します。

サイト運用：公開先、コンテンツ種、件数、月間更新数、編集者、承認者、期限。
データ境界：CMS、外部システム、連携データと個人・機密情報の保存先。
複数サイト：共通項目とサイト固有項目を分けます。

成果物は、サイトマップ、モデル、権限表が基本です。加えて、公開フロー、URL対応表、API仕様、移行計画、受入条件を揃えます。

揃えておけば、開発会社が変わっても要件を引き継ぎやすくなります。公開後の追加開発でも、優先順位を整理できます。

非機能要件と契約の確認項目

非機能要件と契約では、技術要件と契約条件を分けて確認します。

性能・運用：負荷時の性能、速度、可用性、監視、復旧目標、バックアップ、ログ。
セキュリティ：脆弱性診断、IP制限、二要素認証、シングルサインオン、SLA。
Enterprise：管理機能の標準・オプション、サービス数、転送量の上限。

契約では、データの所有・返却・削除、再委託、障害通知を定めます。個人情報の扱いや、コードや設定の引き渡しも、あわせて決めておきます。保守時間と追加改修の単価も、契約で示します。

サービス利用料と委託費を一つの月額にまとめる場合は、内訳を確かめます。

microCMSのシステムに関するよくある質問

導入前によく相談される質問に、順に答えます。料金、開発体制、既存システムとの関係を分けて考えると、自社に必要な構成を判断しやすくなります。

microCMSとWordPressはどちらを選べばよいですか？

更新画面と表示テンプレートを一体で管理したい場合は、WordPressが候補です。

表示先の追加、フロントエンドの独立した刷新、API連携を重視する場合はmicroCMSが候補です。

既存資産を活かせるか、表示・会員・検索の機能をどちらで実装するかを比べます。知名度だけで決めないことが大切です。

フロントエンドエンジニアが社内にいなくても導入できますか？

導入は可能ですが、microCMSの契約を結んだだけでは、公開サイトは完成しません。

初期構築はフロントエンドやデザイン、API設計などを外部へ委託し、公開後の更新は社内で行う体制にできます。

そのため、保守契約の範囲や軽微な改修の依頼方法を、事前に決めておきます。障害時の連絡先と手順書の有無も、あらかじめ確認しておきます。

既存サイトからmicroCMSへ移行するときの注意点は何ですか？

最も重要なのは、ページとデータを移すことに加えて、URLや画像、公開日、カテゴリー、検索流入を引き継ぐことです。

旧URLと新URLの対応表を作り、301リダイレクトやcanonical、noindex、サイトマップ、内部リンクを確認します。そのうえで、代表的なページを先に移行し、差分を検証します。

移行件数が多い場合は、CSVやAPIを使った自動化と、人による目視確認を組み合わせます。

小規模サイトなら無料で運用できますか？

Hobbyは0円で始められますが、コンテンツ数、API数、メンバー数、転送量に上限があります。

小規模な検証には向いています。一方、本番でアクセスが増えた場合や、CSV出力、権限管理、監査、複数環境が必要な場合は、有料プランが必要になることがあります。

無料で試す段階から、本番の利用料と開発・保守費を合わせて予算に入れておきます。

まとめ

microCMSのシステムは、コンテンツの編集と配信の基盤をクラウドで用意し、フロントエンドや外部システムへの投資を集中させやすくする選択肢です。

CMSに向く情報と、在庫・会計・認証など別システムに残す業務を分けます。そのうえで、API、権限、移行、運用を一つのシステム設計として考えることが重要です。

判断で押さえる三つのポイント

第一に、Hobby、Team、Business、Enterpriseの各プランを、API数や転送量だけでなく、権限、監査、サポート、環境管理から比べます。

第二に、サービス利用料と開発委託費を分けて見ます。小規模案件（150万〜400万円）から大規模案件（1,000万〜3,000万円以上）まで、要件に合う工程を見積もります。

第三に、GETとWRITEのAPIキーを分けます。そのうえで、個人情報、XSS、アクセシビリティ、障害対応を受入条件に含めます。

次に作るべき資料

目的から保守までの条件をRFPにまとめ、同じ条件で提案を受けてからMVPで検証します。

目的とKPI、現行コンテンツを洗い出します。
データ境界、権限表、API連携、移行件数の整理
非機能要件と保守範囲を加えた一枚のRFPの作成
複数社から同条件で提案を受け、MVPで運用性を確認する
本番移行後の、編集品質と配信体験の継続的な改善

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