医用画像管理システム（PACS）開発の進め方/やり方/流れや方法/手法/工程/手順

医用画像管理システム（PACS）の開発は、要件整理から教育・定着まで6つのフェーズを順に進めます。各フェーズの完了条件を決めてから次へ進めると、診療継続につながります。

▼全体ガイドの記事
・医用画像管理システム（PACS）開発の完全ガイド

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

医用画像管理システム（PACS）開発の全体像

PACSは、X線、CT、MRI、超音波、内視鏡などの画像を扱うシステムです。DICOM規格に沿って画像を受信して保存し、検索、表示、配信に使えるようにします。

導入時は、HIS・電子カルテやRISとの連携を設計します。モダリティやレポート、画像診断AIとの連携も含めます。地域連携や遠隔読影まで見すえ、画像診療の基盤として捉えます。

PACSの役割と周辺システムの違い

PACSと周辺システムは、患者情報や画像をどこまで管理するかで役割が分かれます。そのため、各システムの役割と管理範囲を分けて確認します。

• PACS：検査画像を患者・検査単位で管理し、医師が必要なときに参照できるようにする役割です。
• Viewer：多断面再構成、比較表示、計測、ハンギングプロトコル、動画・3D表示などを備える場合があります。
• RIS：検査予約、受付、実施、読影進捗など、放射線部門の業務を管理する仕組みです。
• VNA：複数のPACSや施設に分散した画像・PDF・JPEGなどを、中立的に統合して保管する仕組みです。
• 正本の所在：患者情報、検査情報、画像、レポートのうち、どのシステムが保持するかを決めることです。

最初に決めるべき方式と優先順位

方式は、施設の運用や優先条件に合うものを比べて選びます。たとえば、標準パッケージは既存運用を大きく変えず、短期間で導入したい施設に適しています。

• クラウド：サーバー更新、遠隔参照、施設間連携、災害対策を考えやすい方式です。
• オンプレミス：院内ネットワークでの高速表示や、設備の細かな管理に適した方式です。
• ハイブリッド：直近の画像を院内キャッシュに置き、長期保存の画像をクラウドに置く構成です。

独自業務や複数ベンダーの統合が主目的でなければ、最初からフルスクラッチを前提にする必要はありません。そのうえで、標準機能と追加開発の境界を見極めると、費用とリスクを抑えやすくなります。

医用画像管理システム（PACS）の進め方・開発工程

製品デモを見てすぐ契約するより、まず現状調査と要件整理から始めるほうが安全です。画像診療には、救急、病棟、外来、カンファレンスなどの例外運用や、他院画像の持ち込みがあります。

そのため、通常業務だけで要件を組むと抜けが出やすくなります。そこで、6つのフェーズを一つの計画としてつなぎ、各フェーズの完了条件を決めてから次へ進みます。

フェーズ1：現状とMUST条件の要件整理

要件整理では、施設の現状と診療上の必須条件をまとめます。現状の洗い出しと現場での確認は、分けて進めます。

• 現状の洗い出し：モダリティの種類・台数、年間検査件数、画像容量、保存年数、同時接続数、読影端末の場所。
• 既存環境：連携先、旧PACSの保守期限、既存データの形式と件数。
• 現場の運用：救急画像の表示時間、比較する過去画像の年数、承認前レポートの閲覧者。
• 要件の優先度：要件をMUST、SHOULD、WANTに分けて、優先度を付けます。

MUSTには、患者ID取り違え防止と、画像と患者情報の紐付けを含めます。加えて、既存モダリティへの接続やバックアップ復元、監査証跡、障害時の代替手順も、MUST条件として扱います。

一方、将来のAI、地域連携、モバイル参照はWANTです。導入初日から必要か、稼働後に追加できるかを確かめます。

たとえば、鳥取大学の2026年2月の調達要件には、DICOMのC-STORE・C-FIND・C-MOVE・C-GETが記載されています。さらに、DICOMweb、IHE Radiology、MWL、MPPS、FHIR DiagnosticReportも含まれています（出典：政府公共調達データベース、2026年）。

同じ要件には、既存機器との継続接続やデータ移行も明記されています。こうした例にならい、自院の要件にも必要な接続と移行条件を具体的に記します。

フェーズ2：製品・方式の選定と実データに近いPoC

製品カタログの機能数で比べるより、自院の業務シナリオを同じ条件で比較します。そこで、PoCでは匿名化した実データに近い画像を使います。

• 業務シナリオ：救急CTの表示、前回画像との比較、電子カルテからの起動、他院CD取り込み、レポート承認・差し戻し、ネットワーク断時の閲覧。
• 画像とログ：CT・MRIの表示速度、画像欠損、患者属性、DICOMタグ変換、ログの内容を確かめます。
• クラウド：初期費用、保存容量、転送量、最低利用期間、追加Viewer、データ搬出、回線二重化、障害時の代替参照。
• オンプレミス・ハイブリッド：設備と、院内外の保存・連携条件を見ます。

オンプレミスでは、サーバーとストレージ、バックアップを確認します。保守更新、設置場所、電源、空調も確認の対象です。

ハイブリッドでは、院内キャッシュの期間とクラウドへの送信時期を、RFPに記します。さらに、消失時の再取得時間や責任分界も記します。

方式は、診療継続、予算、拠点数、ネットワーク品質から判断します。「クラウドなら安全」「オンプレミスなら速い」と決めつけず、施設の条件で比べます。

フェーズ3：設計・開発での連携と責任分界の具体化

設計では、データ、患者ID、連携、運用上の責任を仕様に反映します。具体的には、次の内容を定めます。

• データと画面：患者・検査・シリーズ・インスタンスの構造、患者IDの採番と名寄せ、DICOMタグ変換、画像受信経路、Viewer権限、レポート状態。
• 患者ID・AI：誤紐付けの隔離、承認者、修正履歴、関連レポートへの反映。AIは診断の代わりとはせず、補助情報の表示画面と確認者を決めます。
• 連携：連携先と接続条件を一覧にし、送受信の担当範囲を決めます。
• 責任分界：要件定義書と基本設計書の保有者、仕様変更の承認者、稼働後の問い合わせ窓口を、契約前に合意しておきます。

連携先には、HIS・RISの患者属性や検査予約、MWL、MPPSなどがあります。さらに、レポート、DICOMweb、他院画像も連携先に含まれます。

連携ごとに、送信元と送信先、プロトコルを記録します。再送条件やエラー通知、テストデータ、障害時の手作業も残しておきます。

責任分界が曖昧なままだと、開発終盤に別途費用が発生しやすくなります。そこで、費用の範囲と担当者を仕様書に残します。

フェーズ4：画像・連携・安全性のテスト

画面が表示されるかだけで終えず、テスト区分ごとに合否基準を事前に設定します。実機器と例外業務の検証も、合わせて行います。

• テスト区分：単体・連携・性能・セキュリティ・移行・障害復旧・受入の区分に分けて実施します。
• 画像データ：DICOMの受信・検索・取得、圧縮画像、動画、マルチフレーム、PR・SR・SEGなどの解析結果を対象に、文字化けや患者属性の欠落を確かめます。
• 接続・受入：機器間の接続と各職種の操作を、受入テストで検証する。
• 例外・記録：例外ケースを試し、結果と修正状況を記録する。

メーカーの異なるCT・MRI・超音波・内視鏡を接続し、新PACSへの継続送信を確かめます。現場では、診療放射線技師や放射線科医、救急担当、医療情報部門、事務担当が実際に操作します。

例外ケースには、患者ID入力ミスや検査キャンセル、再撮影が含まれます。他院画像、レポート差し戻し、夜間障害連絡も、例外ケースとして試します。

結果には、再現手順と影響範囲、暫定対応を残します。修正期限と再テスト結果も記録します。そのうえで、重要シナリオで未合格を残さず、診療の安全を確かめてから稼働します。

フェーズ5：診療を止めない移行と稼働の計画

診療を止めずに移行するには、移す画像の範囲と切替の方法を稼働の前に決めておく必要があります。移行と稼働の確認は、次の5点に分けて行います。

• 移行対象：DICOM Study・Series・Instance、患者・検査ID、レポート、キー画像、PR・SRの範囲を見て、対象期間と除外条件を決める。
• 照合・読影：検査件数、シリーズ数、画像枚数、容量を移行前後で照らし合わせる。救急・術前・経過観察などの重要症例を、サンプルで読影する。
• 切替方式：一括切替、段階切替、旧PACSとの並行運用から選び、繁忙期を避けた切替時間を決める。
• 診療継続：旧PACSの参照専用期間、紙や一時保存への退避、ネットワーク断時の読影手順、ベンダーの現地待機体制。
• 稼働判定：回線・クラウド障害時に、院内キャッシュや最低限の検査情報を見られるかを確かめる。診療影響のある課題は、解消するか代替手順を訓練しておく。

移行後の画像では、患者名や患者ID、検査日が正しく見えるかを確かめます。続けて、モダリティやシリーズ、過去比較の見え方も確認します。

フェーズ6：稼働後の教育と定着による効果の維持

稼働初日は、運用を安定させる出発点です。そこで、職種ごとに必要な教育と、稼働後に追う指標を決めます。

• 対象者：診療放射線技師、医師、看護師、事務職員、医療情報部門ごとに教育する。
• 教育内容：日常と例外の操作、障害時の連絡先、患者ID訂正、他院画像の取り込み、レポート承認。
• マニュアル：「救急CTを確認する」「前回画像を呼び出す」「誤紐付けを報告する」など、業務シナリオ単位で作る。
• 運用指標：画像受信エラーや表示時間、未読レポートの件数を定期的に見る。患者ID訂正件数、問い合わせ件数、容量増加率、バックアップ・復元テストも対象です。

厚生労働省は2026年6月、「医療情報システムの安全管理に関するガイドライン 第7.0版」を公開しました。同時に、医療機関・薬局向けのサイバーセキュリティ対策チェックリストも公開しています（出典：厚生労働省、2026年6月）。

定期運用には、監査ログのレビュー、脆弱性対応、アカウントの洗い出し、復元訓練を含めます。契約終了時には、データの返却も確認します。

医用画像管理システム（PACS）の費用相場とコスト内訳

PACSの価格は、モダリティ台数、年間検査件数、保存年数、画像容量、Viewer同時接続数で変わります。加えて、HIS・RIS連携やデータ移行、冗長化、教育、保守の範囲も価格に影響します。

公開されている価格は少ないため、ここで示す金額はPACS単独の公定価格ではありません。リサーチノートの公開情報と、業務システムの類似相場を組み合わせた推定です。

予算化では、初期費用と月額費用を別々に見るのではなく、契約期間をそろえた総保有コスト（TCO）で比べます。

規模別の費用レンジと期間の目安

規模別の推定レンジは、初期費用、運用費、導入期間で異なります。そのため、施設規模と連携範囲をそろえて比較します。

• 診療所・健診施設：クラウド・パッケージの場合、初期0万〜300万円程度、月額5.5万〜30万円程度、導入期間1〜3か月が目安です。
• 中小病院：複数モダリティと電子カルテ・RIS連携の場合、初期300万〜1,500万円程度、月額10万〜50万円程度です。
• 中〜大規模病院：PACS・RIS・VNA、冗長化、大量移行を含む場合、初期1,000万〜5,000万円超です。
• フルスクラッチ・大規模統合：3,000万〜1億円超、期間12〜24か月以上。

中小病院では、保守年額が初期費用の10〜20％程度になるケースを想定します。画像移行の量や切替条件によっては、期間が延びることもあります。

中〜大規模病院の運用費は、年額数百万円からが推定レンジです。これは個別の見積ではなく、要件を前提に置いた予算検討用の幅です。

施設規模や画像量を確かめないまま、特定の金額を相場と言い切ることはできません。

公開価格を読むときの注意点

公開価格は、自院の見積額ではなく、価格条件を知るための材料です。提供時期や対象の違いを踏まえて読みます。

• PAXiS-X：料金案内に付いた条件を見る。
• NOBORI：レンタル方式の月額条件。
• 提供側の投資：医療機関の導入費とは区別して読む。

たとえば、キッセイコムテックは、PAXiS-Xを2019年に月額55,000円からと案内しました。容量によって増減する価格です（出典：キッセイコムテック、2019年）。

ただし、この金額は2026年時点の医療機関向け見積ではありません。また、NOBORIは、専用アプライアンスのレンタルで初期投資ゼロとする方式を案内しています（出典：PSP株式会社、確認時点2026年）。

月額は、施設規模や容量、Viewer、連携、保守の範囲によって変わります。さらに、2025年の上場企業資料には、提供側がPACSのクラウド化に約600万円を投じる計画が載っています（出典：上場企業資料、2025年7月）。これはサービス提供側の開発やクラウド化への投資で、医療機関の導入費ではありません。

公開情報は、価格の下限や市場投資を見るための参考にとどめます。自院の予算根拠にはせず、見積では、画像容量の増加、移行対象の年数、追加連携、搬出、教育、夜間対応を分けて示してもらいます。

初期費用以外に見込むべきランニングコスト

初期費用以外のランニングコストも、方式ごとに洗い出します。そのうえで、契約期間をそろえた総保有コストで比べます。

• オンプレミス：サーバー、ストレージ、バックアップ、予備機を見込みます。OS・ミドルウェア更新、保守要員、電源・空調、災害対策も含めます。
• クラウド：保存容量、転送量、長期保存が月額や従量料金に影響します。追加Viewer、AI解析、外部連携、回線、サポートレベルも関わります。
• ハイブリッド：院内キャッシュとクラウド保管、それぞれの容量拡張、機器交換、再取得、保守の費用。
• 総保有コスト：3年または5年で、初期・月額・年額を並べます。画像移行、連携、端末・モニター、教育も含めます。

最低利用期間や容量超過、データ搬出の費用が高いと、更新時の選択肢が狭まることがあります。そのため、監視・保守、障害対応、契約終了時の搬出費も、契約期間の中で見込んでおきます。診療継続に必要な費用も、あわせて確認します。

医用画像管理システム（PACS）の見積もりを取るポイント

見積の精度は、ベンダーに渡す情報の具体性で決まります。「PACSを導入したい」だけでは、各社の前提がそろわず、金額を比べられません。

RFPには、現行構成と対象施設、モダリティ、検査件数を書きます。保存年数、利用者数、連携先、移行対象も記します。さらに、稼働希望日や障害時の目標、将来拡張も加えます。

そこで、同じ業務シナリオと回答形式で提案を求め、見積条件を同じ基準にそろえます。

要件定義書とRFPに入れるチェック項目

RFPでは、機能、運用、移行、契約終了時の条件を確かめます。対応できるかどうかに加え、標準機能か追加開発かも回答してもらいます。

• 機能：PACSの標準機能、連携、追加機能の対応範囲。
• 運用：安全管理、障害対応、サポート、接続実績を見る。
• データ移行：対象期間・モダリティ、画像・レポート・キー画像、件数照合の方法を定めます。欠損時の扱い、移行中の新規検査、サンプル読影、旧環境の保管期間も決めます。
• 契約終了：データの所有権、標準形式での返却、費用、期限を、契約書・仕様書に残します。削除証明や設計書・設定値・ログの引き渡し、他社への切替支援も対象です。

機能面では、DICOM Storage・Query/Retrieve、DICOMweb、MWL・MPPSを含めます。Viewerの表示・計測・比較・3Dも、対象に入ります。

レポートの作成や承認、音声認識のほか、他院画像、VNA、遠隔読影、AI連携の対応も確認します。

運用面では、患者IDの入力と訂正、権限、監査ログを確認します。バックアップと復元、障害通知、容量監視、パッチ適用も見ておきます。

24時間365日のサポートや教育、問い合わせの責任分界も対象です。加えて、接続実績や検証環境での再現可否について、回答を求めます。

ベンダーロックインを避ける具体策は、契約条件を明記することです。

複数社を比べるときの評価軸

相見積もりでは、価格以外の条件も同じ基準で比べます。そのうえで、提案の前提と評価結果を記録します。

• 評価条件：医療安全、業務適合性、連携実績、移行計画を比べます。性能、セキュリティ、運用支援、拡張性、契約条件も対象です。
• 連携・クラウド：電子カルテとクラウドの対応範囲を比べる。
• 評価会議：医療情報部門、診療放射線技師、放射線科医、救急部門が参加し、事務、情報セキュリティ、経営企画も加わります。
• デモ・PoC：候補を3社程度に絞り、同じ匿名化データと業務シナリオで実施する。評価者ごとの点数とコメントも残す。

電子カルテ連携は、起動だけか、患者属性・検査情報・レポートまで双方向にやり取りするかで、工数が変わります。また、クラウド対応では、二拠点保管や暗号化、障害時キャッシュを確認します。

復旧目標とデータ搬出の範囲も、あわせて確かめます。未対応機能、追加費用、前提条件、納期、導入後の体制は、比較表に記録します。デモの印象だけで決めないようにします。

追加費用になりやすいリスクと対策

追加費用と納期のリスクは、見積の前に洗い出します。費用の項目と進行上の対策も、あわせて整理します。

• 追加費用の要因：古いモダリティ、特殊なDICOMタグ、名寄せ・患者ID訂正、他院画像・非DICOMファイル・過去レポートの移行、想定外の容量。
• 追加機能・設備：AI・音声認識・遠隔読影、端末・高精細モニター、夜間切替、追加教育を、見積に含めます。
• 見積明細：「一式」「別途」を残さず、数量、単価、前提、除外範囲、変更時の単価を書き出します。
• 納期対策：遅延の要因を洗い出し、関係者と事前に対応を決めておきます。

納期には、現場の承認や連携先ベンダーとの調整が影響します。移行データの品質、回線工事、医療機器側の検証期間も、納期を左右します。

意思決定者と承認期限を先に決め、データサンプルは早めに渡します。連携先を含めた合同テストも、あらかじめ予定に入れます。

契約前に、要件変更の手続き、遅延時の再計画、受入基準、瑕疵対応、保守開始日を明確にします。そうすると、金額と責任の境界がはっきりします。

医用画像管理システム（PACS）開発でよくある質問

PACS開発では、費用、クラウドの安全性、導入期間、既存画像の移行、AIの扱いについて質問があります。導入前に判断しやすいよう、それぞれの質問に答えます。

PACSはクラウドとオンプレミスのどちらがよいですか？

どちらが優れているかは一律に決まらず、自院の運用条件や費用に照らして比べます。

• 選定の観点：診療継続、ネットワーク品質、拠点数、更新負担、予算の各面で比べます。
• クラウドの費用面：初期投資やサーバー更新の負担を抑えやすい方式です。
• クラウドの運用面：二拠点保管や施設間連携を組み込みやすい一方、回線障害、データ搬出、月額増加の確認が要ります。
• オンプレミス：院内での高速参照や設備の統制に向いた方式です。機器更新、バックアップ、災害対策は自院で管理します。
• ハイブリッド：直近の画像を院内に、長期保存の画像をクラウドに置く構成も選べます。

既存のPACS画像はすべて移行した方がよいですか？

移行の範囲と旧環境の扱いは、保存や運用の条件を確かめたうえで決めます。

• 移行判断：保存義務、参照頻度、容量、移行費用、旧システムの保守期限を比べる。
• 移行対象：患者・検査ID、画像枚数、容量、レポート、キー画像、PR・SRの範囲。
• 移行検証：件数照合と、重要症例のサンプル読影を行います。
• 旧PACS：全件を移行しない場合は、参照専用で残す期間を決めます。
• 保管と返却：旧環境のバックアップ、必要な画像の取り出し手順、契約終了時のデータ返却も決めます。

PACSの開発・導入にはどのくらいの期間がかかりますか？

導入期間は、施設規模と連携・移行の範囲によって変わります。たとえば、標準機能中心の小規模診療所や健診施設では、1〜3か月が目安です。

複数連携と移行を行う中小病院では3〜9か月程度、PACS・RIS・VNAや大量移行を含む中〜大規模病院では6〜18か月程度です。

フルスクラッチや複数施設の統合では、12〜24か月以上となる可能性があります。ただし、これは要件の確定、ベンダー調整、データ品質、テスト合格、切替時期によって変わる、一般的な想定レンジです。

PACSにAIを組み込めば読影を自動化できますか？

AI導入では、支援範囲、医療機器としての条件、運用効果を分けて確かめます。

• 支援範囲：AIは病変候補の検出、トリアージ、計測、過去画像との比較を支援します。ただし、導入だけで読影や診断が自動化されるわけではありません。
• 医療機器の条件：医療機器プログラムの承認・認証、対象画像、利用条件、責任者。
• 効果検証：導入事例を参考にしつつ、PoCで実運用の効果を測る。

富士フイルムの医療クラウドサービスには、AI技術を活用した画像診断支援の導入事例があります（出典：富士フイルム、確認時点2026年）。

効果は、対象検査や読影フロー、教育、結果確認の手順によって変わります。そのためPoCでは、精度も測ります。加えて、結果が届くタイミングと、読影者の操作負担も確かめます。

医用画像管理システム（PACS）開発のまとめ

PACS導入では、製品を選ぶ前に、画像診療を止めない要件を決めることが出発点です。要件整理では、モダリティや件数、容量、保存年数、連携先、例外運用を洗い出します。

選定では匿名化データと業務シナリオで比べます。設計では、患者ID、DICOM、連携、権限、監査ログ、責任分界を具体化します。

テストでは、移行画像や表示速度、障害復旧、現場の受入まで確かめます。稼働後の教育と運用評価も、計画に含めます。

発注前に確認する最終チェックリスト

発注前に確認する条件を整理します。契約と稼働を判断する材料として、担当者と根拠をそろえておきます。

• 要件・連携：MUSTとWANTを分け、モダリティ、HIS、RIS、レポート、AIの範囲を決める。
• 安全性：患者ID取り違え防止と監査証跡の検証。
• 移行・障害対応：移行対象、件数照合、サンプル読影の方法と、クラウド・オンプレミスの障害時手順を決める。
• 費用：初期・月額・移行・教育・保守・搬出費を分けて見る。
• 受入・契約終了：合格基準と稼働判定者を決め、契約終了時のデータ返却条件を定める。

次に取るべきアクション

導入準備は、現状の把握、提案の依頼、検証と運用計画の順に進めます。

1. 関係者を集め、現行PACSの構成図と画像データ量を確かめ、MUST条件を10項目以内に絞ります。
2. 匿名化した代表画像と業務シナリオを用意し、複数社に同じRFPを渡します。
3. PoC、移行テスト、受入テスト、教育、稼働後の評価指標を工程表に入れます。

工程表を関係者で共有すると、「使われない」「画像が探せない」「想定外の追加費用が出る」といった事態を防ぎやすくなります。

費用レンジは、診療所・健診施設のクラウドやパッケージで初期0万〜300万円程度です。中小病院は300万〜1,500万円程度、中〜大規模病院は1,000万〜5,000万円超という推定です。

公開価格は個別の条件で変わり、PACS単独の公定価格ではありません。そのため、検査件数、保存年数、画像容量、接続台数、移行範囲、可用性を整理し、同じ条件で複数社から見積を取ります。

▼全体ガイドの記事
・医用画像管理システム（PACS）開発の完全ガイド

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