後期高齢者医療システム開発の完全ガイド

後期高齢者医療システムは、資格・保険料・給付の事務を市区町村と広域連合でつなぐシステムです。標準仕様と移行条件に沿って構築します。

機能と業務範囲、標準化後の方式、開発と調達の進め方が全体の柱です。各テーマの詳細は、関連記事もご覧ください。

▼関連記事一覧
・後期高齢者医療システム開発の進め方
・後期高齢者医療システム開発でおすすめの開発会社6選と選び方
・後期高齢者医療システム開発の見積相場・費用
・後期高齢者医療システム開発の発注・外注・委託方法

後期高齢者医療システムの概要

後期高齢者医療システムを中心に、広域連合、市区町村、住民情報・税、収納・帳票との関係を示した図。
担当する業務と受け渡す情報を一枚で見渡せます。

後期高齢者医療システムは、資格、保険料、収納、給付、通知などの事務を処理します。対象となるのは、原則として75歳以上の人と、一定の障害認定を受けた65歳から74歳の人です。

市区町村と広域連合の役割分担

業務の責任分界を決めるには、広域連合と市区町村の役割を分けて確認するのが出発点です。

  • 広域連合:保険者として、財政運営、資格認定、保険料決定、給付を担います。
  • 市区町村:加入・脱退届、保険料徴収、申請受付、通知、相談対応が担当範囲です。
  • データ授受:広域連合の処理結果を受け取り、住民異動や所得情報を返す流れです。

画面だけを調達範囲にすると、接続テスト、再送、エラー訂正、責任分界が抜けやすくなります。そのため、市区町村と広域連合の担当者を、早い段階から体制に含めます。住民基本台帳、税、国保、収納、帳票印刷の担当者も、体制に加えておきます。

住民情報・税・収納をつなぐ基幹業務

資格、保険料、給付に必要なデータは、住民記録と突き合わせたうえで、収納業務とも連動させます。

  • 資格情報:転入・転出、死亡、世帯変更、年齢到達、障害認定を、住民記録と突合する情報です。
  • 保険料と収納:所得情報をもとに、普通・特別・併行徴収、還付、滞納を管理します。
  • 給付・申請:高額療養費などの受付と、審査・決定の進み具合を追跡します。

厚生労働省は、標準仕様書第1.4版を2026年1月に公開し、同年2月に正誤表を掲載しています(出典:厚生労働省「標準仕様書(後期高齢者医療)」、2026年)。

機能と帳票の要件に加えて、帳票の詳細要件とレイアウトも確認が必要です。そのうえで、自治体独自の便利機能と、制度上必要な処理を分けて整理してください。

主要な機能と業務範囲

機能一覧は、画面数ではなく、制度上のできごとやデータの流れを基準に整理します。あわせて、担当者、データ、確定時点も明らかにします。

資格・宛名・異動の一貫管理

資格管理では、住民記録との連携項目と、異動時の処理を決めておきます。

  • 管理情報:宛名、世帯、被保険者番号、資格の取得・喪失日、負担区分を扱います。
  • 異動処理:75歳到達、転入・転出、死亡、住所・世帯変更が対象です。
  • 訂正:所得更正などが重なった場合の優先順位と、訂正の方法を定めます。

賦課・収納・給付と年度処理の連携

保険料の算定から徴収、給付、年度更新まで、整合するように設計します。

  • 賦課・徴収:所得から算定し、軽減・減免、納付書、年金徴収、口座振替まで扱います。
  • 収納:還付と滞納の状況を管理し、年度更新や所得修正のときに再計算します。
  • 給付:申請受付から支給までの各段階と、代理人、添付書類、問い合わせ履歴を追跡します。

差額の徴収と還付、通知の再発行、広域連合への報告は、一連の処理として整合させます。

医療・所得・個人番号を扱います。そのため、検索表示と帳票出力の権限も、機能要件と同じ粒度で定義します。

広域連合連携・帳票・照会

連携、帳票、照会の仕様には、処理と運用の責任分界まで定めておきます。

  • データ授受:対象・頻度、形式、文字コード、再送と訂正、受信確認の責任を決めます。
  • 帳票:決定・変更・還付の各通知と、納付書の印刷から再発行までを確認します。
  • 照会:資格・賦課・収納・申請履歴を確認できる画面を設けます。

照会画面は、担当業務に応じて表示を制御します。情報を集約しすぎると閲覧権限や誤操作のリスクが増すため、操作ログも設けます。

標準化・ガバメントクラウドによる変化

標準化では、業務とデータを共通仕様に合わせるのが基本です。自治体独自の仕様を残し続ける進め方とは、考え方が異なります。また、2026年度は、移行後の運用と仕様改版への追随も判断します。

標準仕様書の版と適合時期

要件定義書には、標準仕様書の版を記載します。あわせて、機能と帳票の要件、帳票レイアウト、データと連携の要件も書きます。

第1.4版は2026年1月に示され、同年2月には正誤表も掲載されました(出典:厚生労働省「標準仕様書(後期高齢者医療)」、2026年)。

契約後に改版が出たときに備えて、適合基準日、改修責任、費用負担、試験方法を決めておきます。こうした取り決めは、制度改正時の追加請求や納期の不確実性を抑えるうえで役立ちます。

2026年度以降の特定移行支援の扱い

標準準拠システムへの移行は、原則として2025年度末までが目標でした。ただし、2026年度以降の移行が避けられないことが具体化したシステムは、特定移行支援システムとして扱われる場合があります。

デジタル庁は2026年6月30日に対象システムの把握状況を更新しました(出典:デジタル庁「地方公共団体の基幹業務システムの統一・標準化」、2026年6月30日)。

未移行のシステムでは、対象条件と移行計画の根拠を、自治体の進捗資料や契約書で確かめます。そのうえで、次の事項を整理します。

  • 支援条件:期限には上限があるため、対象理由、移行期限、支援範囲、現行システムの維持期間を確かめます。
  • 未移行時の記録:データ移行の難所、事業者の対応時期、連携先への影響、暫定運用の安全性を文書に残します。

ガバメントクラウドの非機能要件

クラウドでは、システム機能だけでなく、基盤の運用と費用もあわせて評価します。

  • 非機能要件:認証、ネットワーク、バックアップ、監視、ログ、障害復旧を設計します。
  • 責任分界:データ移行と運用窓口も含めて、担当範囲を決めます。
  • TCO:月額利用料、従量課金、運用人員、改版費で比較します。

デジタル庁の資料では基幹業務を20の標準化対象事務として整理し、移行後の運用経費の適正化も目標にしています(出典:デジタル庁「地方公共団体の基幹業務システムの統一・標準化」、2026年)。

クラウドに移すだけで費用が下がるとは限りません。そのため、月額利用料や運用費を含むTCOで判断します。

ポイント

標準化の判断は、標準仕様書の版と移行期限、クラウドの運用費を一体で見るのが基本です。どれか一つだけで決めると、制度改正時の追加請求や納期の不確実性につながりかねません。

方式の選び方

過渡期連携、標準準拠パッケージ、スクラッチ開発を、それぞれの特徴とともに並べた図。
選択肢ごとに確認したい条件が異なります。

方式は、標準仕様への適合、移行期限、独自業務で選びます。データ品質と将来の保守体制も、あわせて見ておきます。標準パッケージを基礎に、設定と必要最小限の連携拡張を組み合わせる方法が現実的です。

既存パッケージの過渡期連携

すぐに全面移行できない場合は、現行システムを維持し、標準準拠システムとのデータ連携を整える方法があります。

初期費用と期間を抑えやすい一方で、変換処理と文字コード、エラー再送の扱いを決めておく必要があります。二重入力と暫定運用の終了条件も、あわせて決めます。先送りすると、複雑な連携が長期化します。

標準準拠パッケージ・クラウドと将来運用

標準準拠パッケージとクラウドは、標準仕様の改版、基盤運用、独自機能の扱いを合わせて評価します。

  • 標準準拠パッケージ:共通機能や帳票を使いやすく、仕様書の改版に追随する運用を組み立てやすい方式です。
  • クラウド:冗長化や災害対策を共通化しやすい一方で、利用料、回線、監視、権限、障害時の連絡経路も評価対象です。
  • 独自機能:標準機能の外側に連携アプリを置けるかを確かめます。

標準本体の大幅改修は、改版のたびに再試験が必要になります。その結果、移行の利点と運用費削減の効果が小さくなります。

スクラッチ開発の独自性と保守負担

スクラッチ開発は独自の窓口業務や周辺サービスに合わせやすい一方、継続的な保守が必要です。

採用時には、5年から10年の改修計画と技術文書を確かめ、ソースコードの権利や契約終了後の移行支援も見ておきます。また、制度改正や標準仕様書の改版、セキュリティ、障害対応、担当者の交代に備えておく必要があります。

方式を決める前に、独自の運用を「制度上必須」「住民サービス上必要」「慣例」に分けて整理します。慣例による過剰なカスタマイズを減らし、標準化で廃止する業務を決めると、費用と納期が安定しやすくなります。

ポイント

方式は、標準仕様への適合度と移行期限で候補を絞り、独自業務の多さで最終判断します。短期対応なら過渡期連携、将来の運用を重視するなら標準準拠パッケージかクラウドが候補になります。

後期高齢者医療システム開発の進め方

現状把握と責任分界からFit & GapとRFI、移行データと連携設計、総合テストと切替へ進む図。
責任分界とデータの準備を先に置く流れです。

開発は、現状把握と方式の検討、移行・連携の設計を経て、テストと切替、運用改善へと進みます。画面の開発に入る前に、責任分界と年度処理を合意しておきます。移行データの正解値や帳票の確定条件も、同じ段階で合意します。

現状業務と責任分界の整理

業務フローは、担当課ごとに、誰が入力し、誰が確定し、どこへ出力するかが分かるように作ります。入力元と処理期限も含めます。

  • 対象業務:資格異動、賦課・徴収、還付・給付、通知、問い合わせを整理します。
  • 連携先:住民基本台帳、税、国保、収納、広域連合、印刷・発送の一覧にします。
  • 例外処理:現行ベンダーだけが把握する手作業も、担当者への聞き取りで洗い出します。

Fit & GapとRFIによる実現可能性の確認

標準仕様書と現行業務を並べ、対応方法ごとに要件を分類します。

  • 標準機能:標準機能で対応できる項目です。
  • 設定・連携:設定や連携で補う項目です。
  • 見直し:廃止か業務変更の対象になる項目です。

RFIでは、複数の候補先に同じ条件で、仕様書の版、移行時期、連携実績を確認します。データ抽出と外字対応、制度改正費用も尋ねます。

移行データと連携インターフェースの先行設計

移行の対象は、宛名や資格、賦課、収納のデータです。還付、滞納、申請履歴も対象に含め、項目定義とコード変換を確かめます。

欠損、重複、外字、過去年度の保持期間も確かめます。

  1. データを抽出して、クレンジングと変換を行います。
  2. 新システムへ取り込み、件数・金額・サンプルで照合します。
  3. 本番直前まで、移行リハーサルを複数回行います。

連携テストでは、送信失敗や重複受信、訂正、再送を扱います。年度境界や文字化け、広域連合側の処理遅延も、テストの対象に含めます。

エラーを誰が検知・修正・再送するか、住民へどう案内するかを、運用手順にまとめます。

総合テストと切替後の運用計画

テストは種類ごとに分け、受入基準を数値で定めたうえで、実業務のシナリオで確かめます。

  • テスト:単体から受入まで、性能、復旧、セキュリティを試します。
  • 業務シナリオ:75歳到達、転入転出、所得更正、保険料変更、死亡、還付を扱います。
  • 切替:年度更新や再発行も試し、繁忙期を避けた日程と切戻し方法を決めます。

稼働後は、仕様書の改版と制度改正を定例で確認し、権限も見直します。バックアップ復元やログ監視、障害訓練、クラウド費も、同じ定例で確かめます。

導入効果は稼働日だけでなく、入力と問い合わせの時間、再処理件数、紙帳票、復旧時間を、3か月後と6か月後に測ります。

▶ 詳細はこちら:後期高齢者医療システム開発の進め方

ポイント

画面開発に入る前に、責任分界、年度処理、移行データの正解値、帳票の確定条件を合意しておくことが基本です。合意が遅れると、テストや切替の段階で手戻りが生じかねません。

費用相場とコストの内訳

全国一律の定価はありません。費用は、自治体の規模や被保険者数、連携業務、移行データによって変わります。さらに、帳票、契約期間、クラウド形態でも差が出ます。

見積もりは、本体、移行、連携・テストを分けて示します。教育、保守、クラウド利用料、制度改正対応も、別の行で挙げます。

公開調達の案件範囲と金額

公開調達の事例は、対象業務と契約内容を確かめて比べます。

  • 浦安市:2025年度の標準化過渡期連携は158万4,000円でした。
  • 富田林市:2025年度の過渡期連携は1,075万8,000円でした。

過渡期連携の公開契約額は、約150万円台から約1,100万円台です。富田林市の契約には、税データ連携や変換、テストが含まれます。文字変換や本稼働対応も入っています(出典:浦安市「一社随意契約の公表」、富田林市「令和7年度随意契約一覧表」、2025年度)。

移行と長期保守を含む案件は、数億円規模です。世田谷区の提案限度額は税込5億9,070万円で、2027年度から2031年度までの運用・保守を含みます。

同区の2025年度移行業務分は、税込5,623万2,000円です。ただし、大規模区の個別条件による参考値であり、新規開発費単独とはみなせません(出典:世田谷区「後期高齢者医療標準準拠システム移行及び運用・保守業務委託説明書」、2025年)。

初期相談での規模別の概算レンジ

次の金額は、RFI前に予算を仮置きするための推定レンジです。標準価格ではありません。

  • 過渡期連携・制度改修:150万〜1,500万円
  • 小・中規模移行:標準準拠パッケージへの移行で3,000万〜1億5,000万円
  • 大規模移行:大規模区や複数業務連携を含み、1億〜3億円程度
  • 大規模再構築:独自要件が多い場合は3億〜8億円超

期間の目安は、過渡期連携・制度改修が3〜9か月、標準準拠移行が12〜24か月、大規模再構築が18〜48か月です。

期間は、仕様書の版や広域連合との調整、年度切替によって変わります。データクレンジングや並行稼働も、期間を動かす要因です。見積もりには、被保険者数に加えて、連携本数、帳票数、移行年度、試験回数を示します。

初期費用以外のTCO(5年から10年)

総保有コスト(TCO)は、初期費用と5年・10年の運用費を同じ前提で比べます。

  • 運用費:監視と問い合わせのほか、バックアップや回線を含めます。帳票、クラウド、ライセンスも含めます。
  • 変更費:制度改正や仕様改版への対応、帳票、セキュリティ、障害訓練が対象です。
  • 終了費:データ返却、移行支援、環境撤去、保存ログの扱いです。

初期費用が低くても、毎年の改修や従量課金、二重入力が多ければ、総保有コストは上がります。

見積書は、初期構築、移行、接続・テストに分けて書きます。帳票、研修、保守、クラウド、制度改正も、別の行で示します。

▶ 詳細はこちら:後期高齢者医療システム開発の見積相場・費用

ポイント

費用は、初期費用だけで比べず、5年と10年の運用費まで同じ前提で並べて判断するのが基本です。金額は自治体の規模や連携業務で変わるため、概算レンジは仮置きとして扱います。

開発会社・サービスの選び方

会社やサービスは、知名度や価格だけでなく、業務理解と標準適合の証跡で選びます。広域連合との接続、移行品質、制度改正への対応も、選ぶときの柱です。

提案書に「対応可能」と書かれているだけでは判断せず、画面、帳票、試験計画、障害時の連絡網も確かめます。

制度業務と標準化の実績と証跡

導入件数だけでなく、制度業務や移行の実績を分けて提出してもらいます。

  • 業務実績:資格、賦課、徴収、給付、帳票の直接実績です。
  • 標準化実績:広域連合連携、対象版、標準準拠への移行経験を確かめます。
  • 証跡:匿名化したFit & Gap表、移行報告、試験項目、障害報告を求めます。

データ移行と連携の責任分界

移行と連携テストの担当範囲は、工程ごとに契約に明記します。

  • 移行工程:抽出から取込まで、段階を分けて担当を決めます。照合、リハーサル、切替も工程ごとに区切ります。
  • 費用・不整合:抽出費や外字、過去年度の扱い、再移行、修正期限を明確にします。
  • 合同テスト:自治体、広域連合、住民情報・税・収納の担当を含めます。

相手側の制約と現場の負担まで計画に入れられる候補先は、切替後の混乱を抑えやすくなります。

運用体制と契約終了時の選択肢

日常運用、障害対応、制度改正、仕様改版を、誰が担うのかを確かめます。

  • 窓口:問い合わせ、夜間・休日障害、セキュリティ事故の担当を決めます。
  • サービス水準:一次応答、復旧目標、代替運用、月次報告、再発防止期限を定めます。
  • 契約終了:標準形式のデータ、帳票定義、コード表、移行先への説明を確認します。

移行用データを契約中に定期出力できれば、再調達時の候補を増やし、ロックインを抑えられます。

▶ 詳細はこちら:後期高齢者医療システム開発でおすすめの開発会社6選と選び方

ポイント

会社やサービスを選ぶときは、知名度や価格より、制度業務の実績と標準化の証跡を先に確認することが基本です。移行と連携の担当範囲、運用窓口、契約終了時のデータ返却まで見て比べます。

発注・外注・委託のポイント

RFIとRFPでは、標準準拠の範囲と独自業務を分けて書きます。移行、連携、帳票、非機能要件、受入基準は、項目ごとに整理します。ただし、要件は細かく書けばよいとは限りません。

RFI・RFPで比較できる質問

RFIで候補先の実現可能性を確かめ、RFPで提案条件をそろえます。

  • RFI:仕様書の版・適合状況、移行時期、広域連合接続、抽出、外字、帳票を尋ねます。
  • RFI:特定移行支援の経験、クラウド構成、運用窓口も確認します。
  • RFP:必須と提案の要件を分けたうえで、未対応機能の時期と費用の見込みを示してもらいます。

評価配点と費用以外の契約条件

評価は、価格だけでなく、適合性、移行、運用、契約終了時の支援も対象にします。

  • 提案評価:機能・標準適合、移行、連携・総合テスト、体制、終了時支援を見ます。
  • 運用評価:操作性、セキュリティ、保守体制、費用が評価の対象です。
  • 費用評価:初期費用と5年・10年のTCOを、別々に採点します。

契約には、成果物と受入基準、遅延、再委託を記載します。個人情報、監査、障害、脆弱性対応も、契約に盛り込みます。

データ返却と終了時の移行支援も、契約に定めます。制度改正や仕様改版の追加費用については、無償と有償の範囲を分けておきます。

調達前のチェックリスト

未確定事項をRFIの質問とRFPの提案項目に分け、調達範囲を明らかにします。

  • 業務・移行:対象・対象外業務、責任分界、仕様書の版、移行年度、外字を整理します。
  • 連携・切替:帳票、連携本数、テスト、切替日、並行稼働、障害時運用を決めます。
  • 運用・契約:研修、時間、SLA、セキュリティ、再委託、データ返却を確認します。

契約を続ける場合も、随意契約の理由、代替の可能性、データ抽出、価格の妥当性、再調達時の出口を説明できるようにします。

業務フロー、データ項目、連携仕様、帳票定義は、自治体側の資産として保管します。

▶ 詳細はこちら:後期高齢者医療システム開発の発注・外注・委託方法

セキュリティと住民サービスを両立する設計

医療、所得、世帯、個人番号を扱うため、セキュリティは後付けにせず、最初から設計に組み込みます。本人、家族、代理人が使う窓口画面と帳票も、分かりやすく設計します。

最小権限・ログ・復元テスト

非機能要件には、情報保護の対策と委託先の管理を明記します。

  • アクセス:最小権限、多要素認証、通信・保存データの暗号化を定めます。
  • 記録・対応:管理者操作の記録、ログの改ざん防止、脆弱性、事故報告を扱います。
  • 復旧・委託:バックアップの世代管理、復元テスト、再委託先の管理を決めておきます。

特定個人情報保護評価との関係や、データの保存、返却、消去も、基盤と契約に合わせて確かめます。

窓口の分かりやすさと誤操作防止

窓口での案内、誤操作防止、受付経路の継続性は、次のように設計します。

  • 本人確認と案内:本人、家族、代理人を確認し、必要な届出と添付書類を案内します。
  • 誤操作防止:確認項目を順に表示し、資格変更、保険料再計算、通知再発行に二重確認と取消方法を設けます。
  • 受付履歴:紙通知とオンライン申請を併用する場合、申請番号、受付日時、添付ファイル、審査状況を同じ履歴で確認します。
  • 代替窓口:オンライン手続きを利用できない人には窓口・郵送・電話を残し、各経路を一つの台帳で管理します。

障害時の資格・徴収業務の継続計画

災害、通信障害、広域連合との連携停止時に、紙や代替端末で続ける業務と、復旧後の再入力を決めます。

目標とする復旧時間と時点、代替運用の期間、連絡先を、訓練で確かめます。住民への告知と二重処理の防止も、訓練の対象です。バックアップから実際に戻せるかも確認します。

よくある質問(FAQ)

制度の対象範囲、移行時期、費用、方式について、よくある質問をまとめます。自治体の規模や既存環境に応じて、確認に使える資料も示します。

後期高齢者医療システムは広域連合のシステムですか?

広域連合の資格・給付・保険料決定だけでなく、市区町村の窓口・徴収・通知・申請受付と連携機能も含めます。

調達時は、広域連合と市区町村の対象範囲を、業務フローと責任分界表で明確にします。

2026年度に未移行の場合はどうすればよいですか?

特定移行支援システムに該当するか、移行期限と支援対象を確認します。

対象であっても、現行システムを漫然と延命させず、移行の阻害要因、暫定連携の安全性、データ移行計画、契約終了条件を整理します。

自治体の進捗報告と調達計画に、確認結果を反映してください。

後期高齢者医療システムの開発費用はいくらですか?

初期相談時の推定レンジは、過渡期連携・制度改修が約150万〜1,500万円です。標準準拠移行は3,000万〜1億5,000万円、大規模移行は1億〜3億円程度以上です。

公開調達の過渡期連携は約150万円台〜約1,100万円台です。移行・長期保守を含む提案限度額は、税込5億9,070万円の事例があります。見積もりは、開発と移行、連携に加えて、保守、クラウド、制度改正を分けて出します。

パッケージとスクラッチ開発はどちらがよいですか?

標準仕様に合わせられる自治体では、標準準拠パッケージと設定・連携拡張の組み合わせが、制度改正や保守の負担を抑えやすいです。

独自要件が制度上必須で、標準機能の外側でも対応できない場合に、スクラッチを検討します。

5年から10年の改修費、技術者の確保、契約終了時の移行性まで比べてください。

開発会社・サービスを選ぶときの最重要ポイントは何ですか?

制度業務と標準化、移行、連携、運用を一体で説明できることが重要です。

標準仕様の対応版、移行の責任分界、広域連合接続、障害復旧目標、制度改正費用、終了時のデータ返却を、同じ質問票で比べます。

まとめ

後期高齢者医療システムは、市区町村の窓口・徴収と広域連合の資格・給付を、住民情報、税、収納、帳票、申請のデータでつなぎます。

2026年時点では、標準仕様書の版や特定移行支援、データ・連携要件の改版、クラウドの非機能要件を確認したうえで、現行業務を標準化していきます。

企画・調達で押さえる三つの視点

企画・調達では、業務範囲、長期費用、候補先の実力を一体で確認します。

  1. 広域連合と市区町村の役割から業務範囲を決め、資格・賦課・収納・給付・帳票・連携の分担を明確にします。
  2. 移行・連携・テストから保守、クラウド、制度改正、終了時支援までを含めたTCOで、費用を比べます。
  3. 標準適合の証跡、移行品質、セキュリティ、障害復旧、ロックイン回避で、会社・サービスを選びます。

次に作るべき資料と確認事項

まず、現行業務フローと、機能・帳票のFit & Gap表を作ります。データ・連携一覧、移行リハーサル計画、非機能要件も作ります。

5年・10年TCOの見積依頼書も用意します。標準仕様書とデジタル庁の更新資料を参照し、自治体の事情に合わせてRFIを行ったうえでRFPを作ると、移行リスクと運用負担を比べやすくなります。

▼関連記事一覧
・後期高齢者医療システム開発の進め方
・後期高齢者医療システム開発でおすすめの開発会社6選と選び方
・後期高齢者医療システム開発の見積相場・費用
・後期高齢者医療システム開発の発注・外注・委託方法

 

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。