ポータルサイトシステムは、利用者の種類、必要な業務機能、既存システムとの連携を分けて考えると、要件と運用を整理しやすくなります。
導入の判断から費用、会社選びまで順に取り上げ、セキュリティや失敗対策も扱います。各テーマの詳細は関連記事もご覧ください。
▼関連記事一覧
・ポータルサイトシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・ポータルサイトシステム開発でおすすめの開発会社/ベンダー6選と選び方
・ポータルサイトシステム開発の見積相場や費用/コスト/値段について
・ポータルサイトシステム開発の発注/外注/依頼/委託方法について
Webサービス開発の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。
ポータルサイトシステムの全体像
ポータルサイトシステムは、利用者が最初に訪れる画面から、必要な情報や業務処理へ迷わず進めるための業務基盤です。情報を集めて並べるだけでなく、その先の処理まで含めて設計します。具体的には、誰に何を見せるか、申請をどの順番で処理するか、既存システムとどのデータを交換するかまで決めていきます。
企業サイトやリンク集との違い
企業サイトは、不特定多数に向けて情報を発信することが中心です。一方、ポータルサイトシステムは、ログイン後の利用者の体験と業務処理を重視します。
同じトップ画面でも、利用者によって見え方を変えられます。たとえば、営業担当者には案件情報、管理職には承認待ちの申請、取引先には契約に応じた資料を表示できます。
検索、権限、ワークフロー、アクセスログを組み合わせると、メールや共有フォルダを探す時間を減らせます。
ポータルサイトシステムの種類
ポータルは、主な利用者と業務の目的に応じて分けて考えます。
- 社内ポータル：ナレッジ共有と申請の効率化が目的
- 顧客・会員ポータル：契約情報と問い合わせのセルフサービス化
- 代理店・取引先向けBtoBポータル：受発注と納期確認の窓口
- 自治体・学校のポータル：職員や利用者に向けた情報と機能の提供
- サービスハブ：複数のサービスを束ねる入口
対象ユーザーを混ぜると、認証や権限の設計が複雑になり、費用も膨らみやすくなります。そのため、最初に利用者と業務を分けて整理しておきます。
導入で得られる効果
導入すると、情報を探す時間が短くなり、同じ問い合わせが減るとともに、申請処理の流れを見やすくなります。さらに、顧客や取引先とのやり取りも標準化しやすくなります。
情報を載せた画面を用意しても、利用率が上がるとは限りません。そのため、検索結果の品質、スマートフォンでの使いやすさ、更新担当者の役割、古い情報を廃棄するルールまで設計し、業務改善につなげます。
ポータルサイトシステムの導入が向く企業の課題と判断基準
「ポータルが欲しい」という要望は、要件に落とす前に、分散している情報や業務、困っている人と場面、改善後に測る指標を明らかにしておく必要があります。
メール・共有フォルダ・チャットに分散した情報
同じ規程や手順書が複数の場所にあり、どれが最新版か分からない状態は、導入のきっかけとしてよく見られます。そこで、まず情報源、管理部門、更新頻度を一覧にします。保存期間と公開範囲も、同じ一覧に加えます。
古いファイルを無条件に移すと、検索結果が増えて目的の情報に届きにくくなります。そのため、移行する情報と廃棄する情報を分けて扱います。
問い合わせや申請を自分で完結させる仕組み
人事・総務・情報システム部門に同じ質問が届く場合は、FAQや申請フォーム、進捗確認を一か所にまとめます。そうすると、効果を測りやすくなります。
問い合わせ件数に加え、自己解決率や申請の差し戻し率もKPIに設定します。処理時間も見ておくと、導入後の改善点が見えてきます。
ポータルより別の仕組みが適する場合
情報発信だけが目的で、利用者ごとのログインや業務処理が不要なら、CMSで作る通常のWebサイトが適する場合があります。
複雑な受発注や基幹業務そのものを置き換える場合は、専門の業務システムと連携する設計が現実的です。ポータルは、その業務システムの入口として、情報や処理へ進む統合窓口の役割を担います。
ポータルサイトシステムに必要な主要機能
機能は、利用者の行動に沿って必要性を判断すると整理しやすくなります。たとえば、「知りたい」「探したい」「申請したい」「問い合わせたい」「別システムで処理したい」に分けると、優先順位の付け方が見えてきます。
CMS・検索・ナレッジ管理
CMSは、ニュースや規程、マニュアルのほか、FAQや動画も管理します。専門知識がなくても更新できるかを、まず確かめておきます。
全文検索に加えて、タイトルやタグ、部門で絞り込めるかを確認します。対象者や更新日でも絞り込めるかを見ておきます。
検索ログも分析できれば、「見つからない言葉」や、問い合わせに置き換わった検索を把握できます。そこから、コンテンツの改善につなげられます。
認証・認可・パーソナライズ表示
社内向けにはシングルサインオン、外部向けには会員登録や本人確認、管理者向けには多要素認証を検討します。認証は「誰か」を確かめ、認可は「何を見て操作できるか」を決めます。
権限は、部門や役職、契約状況を条件として、権限マトリクスに落とし込みます。地域や会員ランクを条件にする場合も、同じ表で扱います。
さらに、異動・退職・契約終了のときに権限が自動で変わる仕組みも設計します。
申請・問い合わせ・通知
申請フォームや承認ルート、差し戻しを用意すると、メール中心の業務を標準化できます。期限通知と問い合わせチケットも、あわせて用意します。
申請の種類ごとに承認者が異なる場合は、組織図や金額などの条件を承認ルートに反映します。受付だけをポータルに置き、処理を既存システムへ連携すれば、全面的な作り直しを避けられます。
API連携・ログ・セキュリティ
勤怠や経費、顧客管理、基幹業務などと連携する場合は、連携の方式と正とするデータを決めます。ファイル保管やチャットとつなぐ場合も、同じように整理します。そのうえで、更新時期と障害時の再送方法も決めておきます。
アクセスログ、操作ログ、監査ログは分けて記録し、必要な期間だけ参照できるようにします。入力値検証やセッション管理、脆弱性診断は、初期要件に含めます。バックアップ復元と退職者アカウント停止も、欠かせない項目として入れておきます。
ポータルサイトシステムの構築方式と選び方
構築方式は、利用者数だけでなく、独自業務の多さや外部公開の有無、既存契約、連携先、保守体制から選びます。標準機能を使うほど短期・低コストになりやすい一方、独自業務を無理に合わせると現場負担が増えます。
既存のSaaSやグループウェアを活用する方式
ニュースや文書管理、掲示板、簡単な申請が中心の社内ポータルなら、既存SaaSやグループウェアの標準機能が候補です。初期設定が早く済み、更新やインフラの運用を任せやすいことが利点です。
複雑な権限や独自画面、外部会員管理、特殊なワークフローには制約があります。そのため、標準機能で実現できる範囲を先に確認します。
ポータル基盤製品を導入する方式
複数組織やサイトを一つの基盤で運用し、社内・顧客・取引先向けの画面を分けたい場合は、ポータル基盤製品が適します。
多言語や複数サイト、細かな権限を備えやすい一方で、導入設計と運用管理には専門性が求められます。コンテンツ管理や外部ユーザー対応も、同じ基盤の中で扱いやすい傾向があります。機能数よりも、権限モデルと連携方式を標準で実現できるかを確かめます。
ローコードとAPIを組み合わせる方式
既存アプリやデータベースを生かし、ポータルの入口と申請画面を整えたい場合は、ローコードとAPIの組み合わせが有効です。小さく始めて、利用ログを見ながら広げることもできます。
APIの制限やデータ整合性、管理者が交代した後の保守を確認します。そのうえで、短期のPoCで権限と連携が実現できるかを検証します。
フルスクラッチで開発する方式
独自会員制度や複雑な受発注、固有の審査や料金計算などがあり、標準機能で事業要件を満たせない場合に検討します。自由度は高い一方で、自社が担う責任も大きくなります。
要件定義と品質管理、脆弱性対応が必要です。OSやミドルウェアの更新、担当者の引き継ぎも欠かせません。そのため、自由度だけで決めず、5年程度の保守・改修費用を含めて比較します。
ポータルサイトシステム開発の進め方
成否は、画面を作る前の整理で決まります。まず企画、要件定義、方式選定を先に固めます。そのうえで、設計・開発から移行・テスト、公開、運用改善までを一つの流れとして計画します。
各段階で何を形に残し、どの基準で次へ進むかも明確にします。
▶ 詳細はこちら：ポータルサイトシステム開発の進め方/やり方/流れや方法/手法/工程/手順
1. 目的・対象ユーザー・KPIの設定
主目的は、情報共有、申請のセルフサービス、顧客・取引先との取引、複数システムの統合から選びます。対象ユーザーは、社員や管理職、顧客、代理店などに分けます。そのうえで、利用場面を洗い出します。
検索時間や問い合わせ件数、申請処理時間などから、公開後に確認する指標を2〜4個に絞ります。少ない指標に絞ると、機能の優先順位を保ちやすくなります。
2. 情報・権限・連携先の棚卸しとRFP作成
現行の情報源や更新責任者、公開範囲、保存期間などを一覧にします。承認経路や連携先、移行対象も、同じ一覧に加えます。
権限は、どの単位で制御するかをマトリクスで表します。単位には、組織や役職、職務のほか、契約や個別例外も含めます。
RFPには、対象ユーザーや画面、機能の条件を記載します。連携APIと可用性、監査ログに関する条件も加えます。さらに、アクセシビリティや保守SLA、追加費用の条件も書きます。
3. PoCと画面設計による検証
全社に展開する前に、代表部門のトップ画面、検索、申請を小さく試します。利用者には、情報を見つける時間やスマートフォンでの操作、権限違いによる誤表示を確かめてもらいます。
PoCでは見た目だけでなく、認証連携やAPIを検証します。検索対象や通知、ログ取得も、同じ検証に含めます。そして、残課題を本開発の見積に反映します。
4. 開発・移行・テストと段階的な公開
データ移行では件数だけでなく、重複や古い版、個人情報を確認します。権限やリンク切れも対象です。テストでは、通常操作に加えて、異動・退職・契約終了や承認者不在の場合も試します。
連携先の停止や通信障害、バックアップからの復元も、テストの対象に入れます。部門や用途ごとに段階的に公開します。あわせて、問い合わせ窓口と障害時の連絡経路を用意すると、混乱を抑えられます。
5. 公開後のコンテンツと利用状況の改善
更新責任者や承認者、問い合わせ対応者、システム管理者の役割を分けておきます。月次では、検索語や閲覧数、未読通知、申請の滞留を確認します。エラーや権限変更も見ます。
ポータルは、納品後も利用データと現場の声をもとに育てていく業務基盤です。そのため、四半期ごとに不要な情報を棚卸しします。
ポータルサイトシステムの費用相場とコストの内訳
費用は、ライセンスや初期設定、要件定義・設計、画面開発の項目に分けて考えます。さらに、連携やデータ移行、教育、保守も項目として分けます。公開価格だけでなく、導入支援や個別連携を含めた同じ範囲で見積を比べます。
以下の開発費は、業務システムの人月相場とクラウド料金例をもとにした概算です。ポータル固有の全国統計ではありません。
▶ 詳細はこちら：ポータルサイトシステム開発の見積相場や費用/コスト/値段について
ライセンス費用の目安
2026年8月に確認した公式料金例では、クラウド型グループウェアに1ユーザー月額600円、800円、1,000円のプランがあります。別サービスは、1ユーザー月額900円、初期費用0円と案内しています。
300ユーザーでは月額18万円、24万円、30万円、27万円がライセンスの目安です（出典: 各サービスの公式価格表、2026年8月確認）。
税やオプション、認証、連携は、別料金になる場合があります。初期設定や移行、教育も、別に見ておく必要があります。そのため、年額ライセンスだけで導入費を判断しないようにします。
構築プロジェクトの費用相場
利用人数や構築範囲ごとに費用と期間を比べると、概算の違いを把握できます。
- 50〜100名向けで既存クラウドを使い、連携が少ない社内ポータルは、初期50万〜300万円、期間1〜3か月が目安です。
- 100〜500名向けでSSO、部門別ページ、検索、申請、問い合わせ、データ移行を含む場合、初期300万〜1,000万円、期間3〜6か月程度です。
- 外部公開の顧客・会員・取引先ポータルは、個人情報、本人確認、CRMや受発注連携が加わり、初期800万〜2,000万円、期間4〜9か月程度が目安です。
- 大規模統合ポータルは、初期1,000万〜3,000万円以上、期間6〜12か月以上になることがあります。
- 独自業務を全面的に作り込むスクラッチ開発は、1,500万〜4,000万円以上、半年〜1年以上を想定します。
大規模統合ポータルは、複数組織・複数システムにまたがり、監査や冗長化、移行、複雑なワークフローを含みます。
この金額は、要件ごとに見積もった目安です。実際の金額は、対象ユーザーや画面数、連携数によって変わり、データ量や品質要件でも変わります。
見積に含めるべき費用項目
見積書では、ライセンスや初期設定、要件定義、情報設計を分けて記載してもらいます。UI設計や開発・カスタマイズ、API連携も、分けて書いてもらいます。
データクレンジングと移行、テストは、別の項目として示してもらいます。脆弱性診断やマニュアルと教育、保守も、分けて記載します。
保守には、問い合わせ対応や障害対応、セキュリティ更新が含まれるかを確認します。バックアップ監視やコンテンツ運用支援、追加改修も、含まれるかを確かめます。
月額費用と将来コスト
ランニングコストには、ユーザーライセンス、ストレージ、追加認証、外部連携があります。加えて、監視やバックアップ、保守契約も対象です。コンテンツ更新や教育の再実施もあります。
ユーザーが増えたときの単価や閲覧専用ユーザー、外部ユーザーの課金を確認します。契約期間や解約時のデータ返却も、あわせて確かめます。初年度だけでなく、3年目にライセンス更新と大規模な情報棚卸しが重なる場合も試算しておきます。
ポータルサイトシステムの開発会社・ベンダー・サービスの選び方
知名度や機能数だけでなく、ポータルの種類に合う経験と導入後の体制を見ます。製品提供、構築、保守の会社が分かれる場合もあります。そのため、契約相手と担当範囲を明確にしておきます。
社内・顧客・取引先のポータルごとの実績
社内向けでは、組織変更やSSO、文書移行、申請運用の実績を確認します。顧客・会員向けでは、会員登録や本人確認、個人情報、問い合わせ、契約単位の表示制御を確かめます。
取引先向けでは、会社単位の権限や受発注、納期、請求、複数担当者の管理経験を確認します。画面が似ているかどうかより、同じ業務課題を解決した事例を見せてもらいます。
連携・移行・運用支援の範囲
連携先ごとの実装方法やエラー時の再処理を確認します。データ移行のサンプルや権限テストの方法も見ておきます。
公開後は、コンテンツ更新や利用状況の分析、管理者教育を任せられるかを確かめます。組織変更やセキュリティ更新を誰が担うかも、決めておく必要があります。そのうえで、設定一覧、データモデル、権限表、障害対応手順を納品物に含め、担当者が変わっても運用が続くようにします。
見積の透明性と追加費用の境界
初期費用と月額費用を分けて、前提条件と除外条件を見積書に記載してもらいます。オプションや連携、移行、保守も、それぞれ区別してもらいます。
画面数やユーザー数、データ件数、API本数が曖昧なままだと、契約後の追加請求につながります。テスト範囲や会議回数、納期変更の扱いも、曖昧なままだと追加費用が生じる場合があります。
要件が固まっていない段階では、要件定義を準委任で進め、仕様が確定した後に開発範囲を合意する方法も検討します。
比較時の評価軸と配点
候補を比べる前に、評価軸と配点をそろえて、同じ条件で採点します。
- 要件定義：25点
- 既存システム連携：25点
- 移行・運用：20点
- セキュリティ・権限：15点
- 見積の透明性：15点
各候補には同じ業務シナリオを示し、デモで確かめてもらいます。対象は、トップ画面と検索、権限違いの表示、申請、障害時の対応です。
営業資料だけでなく、構築・保守チームの経験も確認します。
▶ 詳細はこちら：ポータルサイトシステム開発でおすすめの開発会社/ベンダー6選と選び方
▶ 詳細はこちら：ポータルサイトシステム開発の発注/外注/依頼/委託方法について
セキュリティ・アクセシビリティ・2026年の動向
情報を集めるほど、漏えいや誤表示、不正操作の影響は大きくなります。2026年は、生成AIによる社内検索や問い合わせ回答、複数システムを横断したセルフサービスが注目されています。
回答元の権限を無視すると、新たなリスクになります。そのため、利便性より先に、アクセス権を引き継ぐ検索と、監査できるログを設計します。
最低限確認したいセキュリティ要件
シングルサインオンや多要素認証、最小権限を要件に入れます。組織・職務単位の認可やセッション管理、入力値検証も加えます。XSS・SQLインジェクションへの対策や脆弱性診断、ログ監視も確かめます。
バックアップと復元テストも必要です。退職・異動・契約終了時のアカウント停止を手作業に頼ると、漏れが起きやすくなります。そのため、ID情報との連携や定期的な棚卸しを設計します。
IPAの中小企業向け情報セキュリティ対策ガイドラインは、ウェブサービスの運用体制やバックアップを検討する公的な確認材料になります（出典: IPA「中小企業の情報セキュリティ対策ガイドライン」、2026年8月確認）。
アクセシビリティの調達条件
調達仕様には、操作環境や情報の伝わり方に関する条件を盛り込みます。
- キーボードだけで操作できること
- 読み上げ順が自然であること
- 文字と背景のコントラストが確保されていること
- スマートフォンでも入力しやすいこと
公共性の高いサイトでは、JIS X 8341-3:2016を参照し、WCAGの達成基準を調達仕様に落とし込みます。
デジタル庁のウェブアクセシビリティ導入ガイドブックは、2025年10月16日にデジタル社会推進標準ガイドラインへ編入されました。同ガイドブックには、スマートフォン対応を含む実践例が示されています（出典: デジタル庁「ウェブアクセシビリティ導入ガイドブック」、2025年）。
AI検索と統合セルフサービスの扱い方
自然文で質問し、規程やFAQから回答を探す機能も検討されています。導入時は、参照文書や更新日、回答の根拠を表示し、権限外の文書を検索対象から外します。
AIの担当範囲を、「候補提示」までにするか「申請起票」まで広げるかを決めます。誤回答が出た場合に備え、人へ引き継ぐ手順も用意します。
ポータルサイトシステムで起こりやすい失敗と対策
失敗は、機能の不足より、目的・権限・情報・運用の設計不足から起こります。そのため、公開前に利用場面を検証し、公開後も利用データを見て改善します。
情報の掲載だけで使われなくなる失敗
大量のリンクや文書をトップページに並べると、目的の情報を探しにくくなります。そこで、よく行う5〜10個の行動を起点に、導線を設計します。
検索語や閲覧数、離脱、問い合わせへの転換を確認します。古い情報には責任者と期限を設け、更新されないコンテンツは定期的に見直します。
権限設計の後回しによる誤表示
開発後半に権限を加えると、画面や検索、API、通知、ログのすべてに影響が及びます。そのため、要件定義の段階で、役割ごとの閲覧・作成・編集・承認・削除を表にします。
異動や兼務、退職、契約終了の場合も、権限をテストします。権限が複雑になりすぎる場合は、業務単位を整理して例外を減らします。
移行前の棚卸し不足による検索性の悪化
共有フォルダや表計算ファイルをそのまま移すと、重複や古い版、個人情報、権限の不整合が残ります。そのため、移行前に正本と所有者を決め、公開期限や分類、削除候補も定めます。少量のデータで試験します。
利用者が検索する言葉と文書のタグ名が違う場合は、同義語や表記揺れも検索設計に加えます。
運用責任者の不在による更新の停止
システム部門だけで運用すると、各部門の情報は更新されにくくなります。そこで、全体管理者や部門編集者、承認者、問い合わせ窓口を分けて、更新期限とエスカレーション先を決めます。
公開後の研修では、操作だけでなく、情報の掲載場所や公開前の確認担当者も伝えます。
ポータルサイトシステムのよくある質問（FAQ）
検討時によく寄せられる質問を取り上げます。自社に当てはめるときは、ユーザー数だけでなく、対象業務や権限、連携、運用担当者も考えに入れます。
ポータルサイトシステムの開発費用はいくらですか？
小規模な社内ポータルは初期50万〜300万円、標準的な社内ポータルは初期300万〜1,000万円が概算です。外部向けは初期800万〜2,000万円程度です。
ライセンスや導入支援、連携、移行、保守を含むかどうかで、金額は変わります。そのため、同じ前提条件で複数の見積を比べます。
ポータルサイトシステムの開発期間はどのくらいですか？
既存クラウドを使う小規模な社内ポータルは1〜3か月、SSO、検索、申請、移行を含む標準的な社内ポータルは3〜6か月が目安です。
外部ユーザーや本人確認、決済・受発注、複数の基幹システム連携が加わると、4〜9か月以上になることがあります。要件定義とデータ棚卸しを急ぐと後工程で手戻りが増えるため、期間だけを短く決めないようにします。
SaaSとスクラッチ開発はどちらがよいですか？
情報共有や定型申請が中心なら、SaaSや既存基盤の標準機能が短期・低コストになりやすいです。
独自会員制度や複雑な受発注、固有の審査や料金計算が競争力に直結するなら、基盤製品の拡張やスクラッチを検討します。
標準機能と連携、個別開発に分けて考え、将来の保守費用も含めて判断します。
ポータルサイトシステムのセキュリティで何を確認しますか？
認証方式や権限マトリクス、退職・異動時のアカウント停止を確認します。暗号化やログ監視、脆弱性診断、バックアップと復元、障害時の連絡経路も見ます。
外部ユーザーがいる場合は、登録や本人確認、パスワード再設定、不正利用検知、問い合わせ対応も対象になります。AI検索では、閲覧できる文書だけを回答に使うアクセス制御が欠かせません。
まとめ：要件と運用で選ぶポータルサイトシステム
ポータルサイトシステムは、利用者ごとに情報や検索、申請、問い合わせ、既存システムへの入口を整理する業務基盤です。社内、顧客、会員、取引先では、必要な認証や権限、連携、運用が異なります。
ポータルという名前や機能数だけで比べないことが重要です。
最初に決めるべき3つのこと
最初に決めるのは、誰が使うか、どの業務を改善するか、何をKPIにするかの3点です。次に、標準機能、既存システムとの連携、個別開発の範囲を切り分けます。
ライセンスや導入、移行、保守を分けて見積を取り、権限とセキュリティのテスト方法まで確認します。
公開後に見るべき指標
公開後は、ログイン率や検索成功率、問い合わせ件数、申請処理時間を定期的に確認します。エラーやコンテンツ更新期限、権限変更も見ておきます。
機能を増やすより、検索で見つからない情報や、申請で止まる箇所を直すほうが効果につながりやすいです。そのうえで、運用責任者と改善の会議体を決め、継続的に育てます。
▼関連記事一覧
・ポータルサイトシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・ポータルサイトシステム開発でおすすめの開発会社/ベンダー6選と選び方
・ポータルサイトシステム開発の見積相場や費用/コスト/値段について
・ポータルサイトシステム開発の発注/外注/依頼/委託方法について
▼開発を相談する前に読みたい無料ホワイトペーパー
・Webサービス開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。