投稿管理システムは、投稿の受付、承認・審査、公開後の履歴管理を一つの仕組みにまとめ、投稿者や公開先に応じて投稿業務を整えるシステムです。
投稿者の数や承認段階、公開先によって、必要な機能も方式も費用も変わります。そのため、発注前に決めておく点を順に見ていきます。
▼関連記事一覧
・投稿管理システム開発の進め方/やり方/流れや方法/手法/工程/手順
・投稿管理システム開発でおすすめの開発会社/ベンダー6選と選び方
・投稿管理システム開発の見積相場や費用/コスト/値段について
・投稿管理システム開発の発注/外注/依頼/委託方法について
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
投稿管理システムの全体像
投稿管理システムは、文章を入力して公開するだけの仕組みではありません。投稿から承認、公開、運用までの役割を分け、公開前の品質確認と公開後の履歴管理まで業務を支えます。
投稿を集めて公開するまでの一連の業務
投稿者と管理者では必要な機能が異なるため、役割ごとに分けて考えると抜けを減らせます。
- 投稿者向け：投稿フォーム、ログイン、下書き、添付、プレビュー、履歴の機能
- 管理者向け：一覧、分類、検索、差し戻し、公開設定、CSVの入出力
- 承認履歴：下書きから公開までの状態を残し、判断者と時点を追えるようにする
「投稿」と呼ぶデータの種類を最初に決めておくことが大切です。種類が曖昧なままだと、確認すべき項目がずれてしまいます。
社員の記事と一般会員のレビュー、自治体や店舗の登録情報では、必要な本人確認や審査が異なります。保存期間、公開範囲、通報機能も種類ごとに変わります。
要件定義は、投稿者、承認者、公開先を確かめるところから始まります。個人情報や添付ファイルを扱うかどうかも、この段階で押さえます。
CMS・会員管理・ワークフローとの違い
似た役割のシステムでも、扱う情報と業務の範囲が異なります。
- CMS：Webページの作成・編集・公開が中心です。
- 投稿管理：投稿受付と業務上の承認・審査を扱い、CMS機能も含みます。
- 会員管理：認証、プロフィール、契約情報を扱い、投稿コンテンツとは役割が異なります。
- ワークフロー：申請・稟議が中心です。投稿管理では本文、画像、公開日時などを確認します。
会員管理と投稿管理は連携できても、同じ仕組みではありません。そのため、CMSで足りると決めつけず、投稿者と公開先、承認段階から必要な範囲を判断します。保管要件も、範囲を決める材料になります。
投稿管理システムに必要な機能
必要な機能は、投稿者側、管理者側、システム基盤の3つに分けて洗い出すと、漏れを防ぎやすくなります。
機能は最初から全部そろえるより、公開ミスや承認の滞留など、今の業務の問題に直結するものから優先順位を付けます。
投稿者が迷わず入力できる機能
投稿者向けの機能は、入力のしやすさと安全性の二つの面から考えます。
- 投稿機能：会員登録、ログイン、プロフィール、投稿・編集・削除、下書き、履歴、予約投稿の機能
- 入力支援：必須項目、文字数、画像サイズを示し、スマートフォンの入力や通信再開も確かめる
- 外部投稿者の保護：本人確認、規約同意、通報、ブロック、一時非公開、禁止語検知の検討
- 添付ファイル対策：容量制限、ウイルス検査、保存先の分離、公開URLの推測防止
画像や動画を受け付けるなら、拡張子を見るだけでなく、安全性を確かめる仕組みを設計に含めます。
業務に合わせた承認フローと権限
承認の停滞や閲覧範囲の広がりを防ぐため、流れと権限を分けて設計します。
- 承認状態：下書き、承認待ち、差し戻し・承認、公開の順での管理
- 複数段階の承認：編集者、法務担当、部門責任者の確認が必要なら、その段階を設定する
- 滞留への備え：代理承認、期限通知、担当者変更、承認履歴の要件化
- 権限管理：役割や部署、サイト、カテゴリーごとの閲覧、編集、公開の制御
権限を管理者と一般利用者の2種類だけにすると、業務の役割に足りなくなります。そのため、役割を細かく分けて設計し、投稿者から公開責任者、システム管理者まで権限の範囲を区切ります。
別部署から非公開の個人情報を見えないようにするには、画面だけでなく、APIやデータベースへのアクセスも同じ権限で制限する必要があります。
連携と分析による投稿業務の改善
連携先と記録する指標を決めておくと、二重入力を減らし、業務改善につなげやすくなります。
- 連携先：会員・顧客・基幹データ、配信、SNS、検索、解析、ストレージから検討する
- 連携方式と管理元：REST API、Webhook、CSV、バッチから選び、正とするシステムを決める
- 責任範囲：会員情報は会員DB、配信結果は配信基盤など、データごとの定義
- 改善指標：運用状況を定期的に見て、具体的な改善施策と結び付ける
導入後は、承認待ちの平均時間、差し戻し率、公開ミス件数を見ると、流れの詰まりに気づけます。月間投稿数と投稿完了率も合わせて確認します。
公開後の反応は、検索利用率と閲覧数を中心に、クリック率や配信成功率も見ます。
指標は施策と結び付けて初めて役立ちます。たとえば、承認待ちが24時間を超えたら通知し、差し戻しが多い項目はフォームで説明します。
投稿管理システムの種類と選び方
方式は大きく分けて、SaaSやクラウドCMS、パッケージを設定・拡張して使う方法と、独自にスクラッチ開発する方法があります。
選定では初期費用の安さだけで決めず、承認ルールや連携、移行まで含めて判断します。運用を誰が担うかも、方式を選ぶ際の大事な材料です。
標準的な記事投稿に向くSaaS・クラウドCMS
クラウド型は標準的な運用に合う反面、契約前に利用条件と安全性を確かめる必要があります。
- 向くケース：投稿者が少なく、記事の入力・確認・公開が中心で、会員情報や独自審査が複雑でない場合です。
- 利点：短期間で始められ、サーバー運用や機能更新を自社で抱えにくい方式です。
- 標準機能の限界：細かな権限、特殊な承認、独自移行、深い外部連携に対応しにくい場合があります。
- 契約前の確認：ユーザー数・投稿数の上限、添付容量、バックアップ世代、復旧目標、データのエクスポート、終了時の返却条件
クラウドであっても、安全性が自動的に保証されるわけではありません。そのため、脆弱性対応やWAF、管理者の認証方式を中心に比べます。アクセスログやリージョン、サポート時間も、契約前に合わせて確かめます。
複数部署の承認に向くパッケージの設定・拡張
共通機能が業務に合うかは、デモと拡張条件を使って見極めます。
複数部署が投稿し、編集者や責任者が段階的に承認する場合には、業務向けパッケージを設定・カスタマイズする方法が現実的です。
デモは、提案の説明を聞くだけでなく、業務上の操作が実際にできるかを確かめる機会になります。
- 向くケース：複数部署が投稿し、編集者や責任者が段階承認する場合です。
- 活用できる機能：ワークフロー、リビジョン、権限、監査ログを使い、投稿項目や公開画面を調整します。
- デモでの確認：差し戻し、代理承認、予約公開、権限別検索を試し、標準機能と個別開発の境界を示す
- 将来の確認：追加費用・納期と、バージョンアップ後に個別改修が使えなくなる可能性
共通機能を土台にできるため、ゼロから作るより品質を確かめやすく、SaaSより複雑な運用にも合わせやすい中間案です。
会員・基幹連携や独自審査が中核となる場合のスクラッチ開発
独自の要件があるかどうかと、開発後も続く運用の負担をあわせて、採用の条件を考えます。
- 検討するケース：投稿体験、複数システム連携、独自審査のいずれかがサービス価値や競争力になる場合です。
- 設計の自由度：データモデル、画面、権限を独自に組み立てられます。
- 継続する責任：要件定義、品質管理、保守、脆弱性対応を自社と開発パートナーで分担する
- 段階導入：迷う場合は投稿・承認・公開・検索・ログから始め、利用状況に応じて連携やAI支援を加える
判断の目安は、標準的な記事投稿ならSaaS、複数部署の承認ならパッケージ、会員・基幹連携や独自審査が中核ならスクラッチです。
投稿管理システム開発の進め方（6段階）
開発がうまくいくかどうかは、プログラミングより前に、投稿業務をどこまで具体化できるかで決まります。
工程は全部で6段階あり、現状整理と要件定義から始めて、方式選定、MVP実装、テスト・移行と進み、運用改善で終わります。この順番を守ると、要望の追加や責任範囲の曖昧さを抑えやすくなります。
▶ 詳細はこちら：投稿管理システム開発の進め方/やり方/流れや方法/手法/工程/手順
1. 現状整理と要件定義
開発の前に、担当者、データの所在、利用規模を把握しておきます。そのうえで、必要な要件を具体的な形にまとめます。
- 業務とデータの洗い出し：投稿者、編集者、承認者、公開責任者を挙げ、メール・表計算・CMS・会員DB・配信サービスのデータ所在を図にする
- 要件一覧：投稿種別、必須項目、状態、承認段階、公開範囲、添付、検索、保存・削除、通知、連携、KPIをまとめる
- 権限と規模：閲覧範囲を権限マトリクスにまとめ、投稿数、同時アクセス、1件あたりの添付容量、保存年数、利用者数を数値で押さえる
- 数値の前提：未確定なら現状値、初年度予測、3年後の上限を置いて、方式やインフラを比べる
2. 画面・データ・連携の設計と開発
要件が決まったら、画面、データ、連携の設計に進み、初回リリースに含める範囲も具体化します。
- 画面・データ設計：入力導線と滞留確認を優先し、本文、添付、カテゴリー、公開期間、投稿者、承認・変更履歴を分けて、検索と移行に備える
- API連携：送受信項目、認証、失敗時の再送、重複防止、障害時の責任者の取り決め
- 初回リリース：投稿、下書き、承認、公開、検索、権限、ログを中核に据える
- 後から追加する機能：自動要約、レコメンド、複雑な配信条件、AI分類（業務が安定してから追加）
- 開発期間：クラウドは2週間〜2か月、パッケージは2〜5か月、小規模スクラッチは3〜6か月、中規模は6〜12か月程度
中規模開発の期間には、連携と移行の作業も含まれています。実際の期間は、要件と体制によって変わります。
3. テスト・移行・リリース後の改善
リリースの前後は、テスト、データ移行、運用改善の順に作業を進めます。
- 正常系に加えて、権限のない投稿へのアクセス、承認者の差し戻し、予約公開の時刻ずれ、同時編集、添付容量超過を確かめる。
- 退会者データ、CSVの文字化け、外部連携の失敗、バックアップからの復元を試す。
- セキュリティでは、クロスサイトスクリプティング、SQLインジェクション、CSRF、認可制御の欠落を検査する。
- 移行対象、URL、画像と本文の対応、作成者、公開日時、カテゴリー、非公開データを取り決める。
- リリース後は、指標を週次で確認してフォームや承認ルートを改め、運用マニュアルと障害連絡先を用意する。
投稿管理システムの費用相場とコストの内訳
投稿管理システム単体の公的な費用統計は少ないため、以下の金額は、類似する業務システムの事例と公開価格をもとにした推定です。
特に費用を大きく左右するのは、投稿者数、月間投稿数、承認段階の3点です。添付容量や連携数、個人情報の有無も金額に響くため、金額を見るときは、何が含まれているかも合わせて確認しましょう。
▶ 詳細はこちら：投稿管理システム開発の見積相場や費用/コスト/値段について
方式ごとの初期費用の幅（0〜4,000万円以上）
方式ごとに初期費用と継続費用が違うため、金額の幅を分けて見ていきます。
- SaaS・クラウドCMS：初期0〜100万円、月額1万〜15万円程度
- パッケージ：初期150万〜800万円、年額の保守・利用料20万〜150万円程度
- 小規模・中規模スクラッチ：小規模300万〜700万円、中規模700万〜1,800万円
- 大規模スクラッチ：高可用性や大量投稿を求める場合の推定レンジは1,800万〜4,000万円以上
公開価格の例では、業務CMSの初年度ライセンスが44万円、88万円、132万円、264万円と段階的に設定されています。
WAFは初期3万8,500円、月額4万4,000円です。CDNの500GBプランは月額4万4,000円という例もあります（出典：業務向けCMS製品の公式価格表・公式クラウドオプション、2026年確認）。
これらは基盤などの価格です。画面制作や移行、保守などが含まれない場合もあるため、金額の内訳を確かめます。
見積書の工数と追加費用の条件
見積もりは、費用項目ごとの配分と、追加費用が発生する条件に分けて読むと分かりやすくなります。
- 見積項目：要件定義・UX、画面、アプリ、基盤・セキュリティ、移行、テスト、管理、教育、予備費
- 費用配分の目安：設計10〜20%、アプリ40〜55%、基盤10〜20%、移行・テスト10〜20%、管理等10〜20%
- 追加費用の要因：既存データ不整合、古い画像・URLの移行、外部API仕様変更、多言語、個別承認、アクセス集中対策、脆弱性診断、24時間監視
- 契約方式の差：要件が未確定のときは、固定価格契約と準委任で費用の傾向が変わる
固定価格契約は変更リスクを見込むため、準委任より1.3〜1.5倍程度になる傾向もあります（出典：NotebookLM Q&Aによる類似業務システムの整理、2026年）。
費用配分の比率は固定の相場ではなく、見積もりを読むための目安として使います。見積もりの幅は、個別の条件によって変わります。
月額・年額のランニングコスト
導入後の支出は、利用料に加えて、保守や契約終了時の費用も含めて比べます。
- 継続費用：クラウド、DB、保存・配信、WAF/CDN、メール、監視、バックアップ、保守、脆弱性対応、問い合わせ
- 月額目安：小規模な独自開発は5万〜30万円、中規模は10万〜50万円程度。SLAや24時間対応は個別見積もり
- 3年総額：初期、月額、追加開発、移行、教育、保守、契約終了時の返却費を含めた合計
初期費用だけで選ぶと、更新や障害対応を社内で担えず、結果として総額が高くなることがあります。
投稿管理システムの開発会社・ベンダーの選び方
開発会社やベンダーは、知名度や価格だけでなく、投稿業務への理解と導入後の運用体制から比べます。
候補を3社程度に絞り、同じ要件と同じ質問で提案と見積もりを依頼すると、標準機能と個別開発の差が見えやすくなります。
「記事更新」と「会員投稿・審査」を分けた実績の確認
公開事例は、単なるWebサイト制作の件数よりも、どんな投稿形態を扱ったかで判断します。
- 投稿形態：社内記事、外部ライター、会員レビュー、自治体配信、社内ポータルなどの経験
- 担当範囲：画面制作のほか、要件定義、移行、テスト、保守のどこを担ったか
- 条件の近さ：投稿者数、月間投稿数、承認段階、添付容量、連携先、個人情報の有無を伝えて比べる
- 業務理解：非公開事例でも匿名化した要件や体制を説明でき、業務の変化を示せる会社を候補にする
RFPと見積もりの前提
同じ条件で提案を比べるために、依頼情報と契約前の確認事項をそろえておきます。
- 依頼資料：目的、現状課題、利用者・投稿の種類、業務フロー、画面一覧、権限マトリクス、データ項目、連携先、移行対象を一枚にまとめる
- 優先度と前提：希望時期、予算上限、運用体制を記し、要件を必須、できれば必要、将来検討に分ける
- 見積書：要件定義、設計、開発、テスト、移行、教育、保守の作業範囲と成果物
- 契約前の確認：追加単価、仕様変更、検収、遅延、知財、再委託、障害連絡、契約終了時のデータ返却の明文化
要件をすべて確定できなくても、優先度を分けておけば、提案の精度を高められます。
セキュリティと保守の責任分界
安全性を評価するときは、技術対策に加えて、運用の責任と検証の方法も確かめます。
- 対策項目：認証、権限、ログ、暗号化、バックアップ、診断、マルウェア対策、監視、事故対応
- 責任分界：提供者の担当と、利用企業のアカウント管理・投稿審査・バックアップ確認の線引き
- SLA：障害時の復旧目標と通知時間を記載できるか
- 投稿機能の検査：入力・出力、SQL、CSRF、認可、ファイル処理の点検
IPAは、SQLインジェクションとクロスサイトスクリプティングを主要な脆弱性として解説し、CSRFやアクセス制御の欠落も取り上げています。
開発会社の説明に加えて、診断報告と修正後の再検査も確かめます（出典：IPA「安全なウェブサイトの作り方」）。
▶ 詳細はこちら：投稿管理システム開発でおすすめの開発会社/ベンダー6選と選び方
▶ 詳細はこちら：投稿管理システム開発の発注/外注/依頼/委託方法について
セキュリティと2026年時点の最新動向
投稿管理システムは外部からの入力を受け付け、個人情報や公開前の原稿を保存します。そのため、通常のWebサイトより多くのリスクを考える必要があり、なかでも入力、認証、権限には注意が要ります。
2026年時点では、AIによる作業補助とAPI連携を、初期要件の段階から扱う必要があります。アクセシビリティやクラウドの責任分界も、初期の段階で決めておくと後戻りが減ります。
個人情報の収集目的と漏えい時の対応
個人情報は、取得時の管理と漏えい時の対応を一続きで決めておく必要があります。
- 取得・保管：目的、項目、保存期間、削除、第三者提供、委託先、権限を整理し、必要以上には集めない
- 公開情報の分離：公開プロフィールと管理用個人情報を分け、退会後に残す投稿と削除情報を決める
- 漏えい時の判断：対象によって委員会報告と本人通知が必要になる。要配慮情報、不正目的、財産被害、1,000人超などが対象
報告は速やかに行い、概ね3〜5日以内とされています。そのため、連絡先と判断者、ログの保全方法を平時から決めておきます（出典：個人情報保護委員会「漏えい等報告・本人への通知の義務化について」）。
AIの活用と人の判断の補助
AI機能を導入するときは、用途に加えて、人の確認責任と入力データの扱いも整理します。
- 補助できる作業：要約、カテゴリー候補、重複検知、不適切表現の一次判定、タイトル案、問い合わせ分類
- 人の確認：誤判定、個人情報、著作権、説明責任に配慮し、提案の採否を履歴に残す
- 導入条件：学習利用、保存期間、モデル・API変更、上限、費用、障害時の代替策
- 重要な投稿：判定理由を承認者が確かめられるようにし、従来の確認フローは省かない
アクセシビリティとAPIの初期要件への組み込み
利用者向け画面への配慮と、複数のチャネルで情報を使う準備は、初期要件に含めておきます。
- 画面の配慮：キーボード操作、エラー説明、色以外の表示、代替テキスト、見出し、コントラスト
- 公開コンテンツ：画像や動画に必要な説明を入力する項目
- 初期要件：アクセシビリティに関する国の指針の要件への反映
- API再利用：Web、アプリ、検索、配信で公開状態・期間・権限・削除をそろえ、認証、制限、ログ、再送、版管理を定める
デジタル庁は2025年10月に導入ガイドブックを標準ガイドラインへ編入し、2026年6月に広報向け資料も示しています（出典：デジタル庁「デジタル社会推進標準ガイドライン」、2026年確認）。
投稿管理システムについてよくある質問
導入前によく相談される質問を並べました。自社の投稿者や公開先、既存データに当てはめると、必要な要件が見つけやすくなります。
WordPressでも投稿管理システムを作れますか？
作れます。標準の投稿・ユーザー・権限機能を土台に、承認やカスタム項目を加える方法があります。会員投稿、予約公開、監査ログ、通知なども追加できます。
ただし、一般会員の大量投稿や複雑な権限がある場合は、拡張機能だけで対応できるか検証します。個人情報や外部連携、厳格なセキュリティ要件が絡む場合は、より慎重に確かめます。将来の保守費を含めて判断します。
会員のレビュー投稿を承認制にできますか？
できます。投稿後はいったん非公開の承認待ちにし、内容と画像を確認したうえで、禁止表現をチェックして公開か差し戻しを決めるフローにします。
通報への対応、利用停止、公開後の再審査、削除依頼、審査履歴まで設計しておくと、投稿数が増えても対応しやすくなります。AIを使う場合は、一次判定のあとに人が確認する仕組みを残します。
既存の投稿データや画像を移行できますか？
移行はできます。ただし、事前に旧データの状態を確かめ、URLや画像と本文の対応も押さえておきます。
移行対象は、全件にするか公開中だけにするかを決めます。非公開、削除済み、退会者のデータの扱いも決め、変換ルールと件数の突合を行います。
本番の前にサンプル移行とリハーサルを行い、旧URLからの転送や検索結果も確かめます。
メッセージ配信やSNSと連携できますか？
連携できます。公開した投稿を配信対象にするだけでなく、条件指定や配信履歴、再送、エラー確認まで必要かを決めます。クリック計測や問い合わせ履歴も、要件に含めるかを検討します。
自治体の情報配信システムでは、条件指定配信や配信履歴・再送を含め、統計やチャットボットまで要件に入れた公開仕様書もあります（出典：自治体公開の情報配信システム仕様書、2025年確認）。
連携先が止まったときに、投稿公開を続けるか、再送するかも設計しておきます。
月額保守を削減できますか？AIで自動公開できますか？
月額保守を完全になくすことはおすすめしません。脆弱性対応や更新、バックアップ確認などを誰が担うかを明確にしたうえで、対応時間や対象範囲を調整します。問い合わせやデータ復元も、同じ確認の対象です。
AIによる要約や分類は自動化できます。ただし、法務や個人情報、公開責任に関わる投稿は、完全自動で公開せず、人の承認を残すのが安全です。
まとめ
投稿管理システムは、記事やレビューを保存し、投稿から承認、公開、配信、分析、保管・削除までを一つの業務として整える仕組みです。
まず、投稿者と公開先、承認段階を定義します。そのうえで、個人情報や添付ファイル、保存期間を整理し、CMS・会員管理・ワークフローのどこまでが必要かを切り分けます。
業務の複雑さに合わせた方式の選び方
標準的な記事投稿だけならSaaS、複数部署の承認ならパッケージ、会員・基幹・独自審査が中核ならスクラッチが基本的な判断軸です。どの方式も、投稿者数、投稿量、承認段階、連携数、移行範囲を同じ条件で見比べます。
費用は、クラウド導入の初期0〜100万円程度から、複雑な独自開発の4,000万円以上まで幅があります。金額を比べるときは、投稿者数や承認段階など、前提を同じにそろえることが欠かせません。
最初の一歩は、要件と責任範囲を一枚にまとめる作業
導入の準備では、開発会社に伝える情報、提案を比べる軸、導入後に見る指標をそろえておきます。
- 依頼内容：投稿種別、業務フロー、権限、移行、連携、セキュリティ、保守範囲
- 提案比較：3社程度から同条件で提案を受け、実績、標準・個別開発、受入テスト、障害支援、データ返却を比べる
- 導入後の改善：承認滞留、公開ミス、投稿完了率、配信成功率をKPIにする
▼関連記事一覧
・投稿管理システム開発の進め方/やり方/流れや方法/手法/工程/手順
・投稿管理システム開発でおすすめの開発会社/ベンダー6選と選び方
・投稿管理システム開発の見積相場や費用/コスト/値段について
・投稿管理システム開発の発注/外注/依頼/委託方法について
▼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を創業。