Litのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

Litのシステム開発は、業務範囲の整理、既存資産との比較、小さなPoC、段階的な導入の順に進めると、利用者が継続して使える状態につながります。

Litは画面部品を作るライブラリで、業務機能は別途設計が必要なため、最初に担当範囲を分けることが進め方の出発点になります。

▼全体ガイドの記事
・Litのシステム開発の完全ガイド

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

Litのシステム開発の全体像

Litは、Custom ElementsやShadow DOMなどのWeb標準を使い、再利用できるWeb Componentsを作るJavaScriptまたはTypeScriptのライブラリです。

ボタンや検索フォーム、テーブル、入力ダイアログ、通知、ナビゲーションなどを部品にできます。さらに、こうした部品は複数の業務画面や異なるフレームワークの画面で共有できます。

Litは業務システムの完成品ではない点

Litが主に担うのは、利用者がブラウザで操作する画面層です。ERPやCRM、販売管理、勤怠管理などの業務機能を提供する製品ではありません。Litの外では、業務処理の機能と運用の基盤を別に用意します。

• 別途設計する機能：認証・認可、API、業務ルール、データベース、帳票、バッチ
• 運用基盤：監査ログ、クラウド基盤、バックアップ、運用監視

開発で工数がかかるのは、ライブラリのライセンス費用よりも、業務要件の整理と共通部品の設計です。さらに、API連携、データ移行、品質保証、社内への引き継ぎにも工数がかかります。

Litの再利用性が生きるのは、同じ操作部品を複数の画面やサービスで使う計画がある場合です。一方で、再利用の予定がないまま「Litを導入すれば開発費が下がる」と考えるのは危険です。

Litの採用が向くケースと慎重に比較すべきケース

Litが候補になりやすいのは、次のような場面です。

• 複数技術の共存：React、Vue、Angular、サーバーサイドHTMLが混在する社内ポータル
• 共通部品の利用：複数サービスで同じ部品を使う場合
• 段階移行：全面刷新を避け、一画面ずつ移行する場合
• 既存画面への埋め込み：Shadow DOMでスタイルを閉じ込め、ウィジェットを追加する場合

短期間で豊富な業務部品、ルーティング、状態管理、既存ノウハウをそろえることが最優先なら、ReactやVueも候補に残します。

採用を判断するときは、既存資産との境界、再利用する画面数、保守担当者が読めるかをPoCで比べます。

Lit 3は、Internet Explorer 11とClassic Edgeをサポート対象としていません。そのため、対応ブラウザを先に確認します（出典：Lit公式「Requirements」、2026年閲覧、https://lit.dev/docs/tools/requirements/）。

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

技術選定より先に、業務の目的と利用者の行動を整理します。そのうえで、画面層、API、データ、運用の責任範囲を決めておけば、後の工程で担当の抜けが生じにくくなります。

開発は6つのフェーズに分けて進めます。要件整理から定着まで、各フェーズの終了条件を文書にしておくと、見積もり追加や認識違いを抑えられます。

フェーズ1：要件整理で決める業務の目的と範囲

要件整理では、業務の目的を明らかにし、短縮したい時間や、減らしたい入力ミスと二重入力の件数を決めます。

現行の業務フロー（Excelや紙、メールなど）を並べ、例外処理や承認経路も確かめます。そのうえで、現場の不便をそのまま画面に移さず、不要な承認や重複入力を廃止できるかを検討します。

Litで作る画面と、バックエンドや既存サービスが担う機能を、境界図にまとめます。境界図を作っておけば、後工程で見積もり範囲の認識がずれる問題を防ぎやすくなります。見積もりのずれを防ぐには、この4つの側面を要件整理の段階で文書にしておきます。

• 利用者と業務：対象利用者、権限、目的、必須画面、入力項目、検索条件
• データと連携：承認状態、マスタ管理者、移行範囲、外部連携、保持期間、監査ログ
• 非機能要件：同時利用者数、応答時間、対応ブラウザ、アクセシビリティ
• 運用：障害時の連絡先と、Lit・バックエンド間の機能境界

フェーズ2：PoCで判断するLitと周辺技術の選定

選定では、Litだけでなく周辺の技術も決めます。TypeScriptやビルドツールといった開発環境、ルーティングや状態管理などの画面の仕組み、フォーム処理とUI部品の配布方法が対象です。

API・認証まわり、テストツール、監視方法も選びます。ReactやVueと同居する場合は、実データに近い条件で連携を検証し、属性・プロパティの渡し方やCustom Eventの命名を確かめます。

フォーム値やエラー表示、スタイル共有も、同じPoCの中で検証します。

検証は、見た目だけのボタンで確かめず、一つの業務シナリオを通して実施します。シナリオには、検索から登録までの流れに加えて、入力エラー、権限制御、API失敗時の再試行を含めます。評価は次の4つの観点で行います。

• 再利用性：別画面でも部品を利用できるか
• 操作性：キーボード操作ができるか
• テスト性：E2Eテストで要素を安定して取得できるか
• 連携性：開発者がAPI仕様を理解でき、既存画面に影響しないか

PoCの結果は資料にまとめ、採用理由に加えて、不採用時の代替案や未解決の制約、追加費用が発生する条件も残します。

フェーズ3：コンポーネント設計と業務機能開発の切り分け

画面ごとの仕様に加えて、共通コンポーネントのAPIも定義します。たとえば日付入力では、値の形式や最小日・最大日、タイムゾーンを決めるほか、エラー文やフォーカス移動、変更イベントも定めます。

テーブルでは、ページングや並び替え、絞り込みを設計します。さらに、空データや読み込み中、通信エラー、大量データ時の表示も設計します。

Shadow DOMは、コンポーネント内のDOMやスタイルを外部から分けるため、他のWeb Componentsや既存コードとの相互運用がしやすくなります。ただし、認証やデータ秘匿の境界ではありません（出典：Lit公式「Working with Shadow DOM」、2026年閲覧、https://lit.dev/docs/components/shadow-dom/）。

認可はAPIやサーバー側で行い、画面で非表示にしただけの機能を安全とみなさないようにします。そのうえで、設計段階でそろえておく資料は、次の3種類です。

• 設計資料：コンポーネントカタログ、プロパティとイベントの仕様
• 開発資料：デザイントークン、ブラウザ対応表、テストコード
• 運用資料：依存パッケージ一覧、脆弱性対応方針、運用手順

部品と業務画面を別のレイヤーに分けておくと、ReactやVueの画面から部品を使ったり、別のサービスへ移植したりできます。

フェーズ4：機能・連携・アクセシビリティのテスト

単体テストだけでは完了とせず、テストの観点を広げます。コンポーネントや画面結合、API、権限が対象になります。さらに、業務シナリオと性能、障害復旧、ブラウザ、アクセシビリティも確かめます。

Shadow DOMを使う場合は、フォーカスが内部に閉じ込められないかを確かめます。そのうえで、ラベルとエラーが支援技術に伝わるか、キーボードだけで登録を完了できるかを実機で確認します。

受け入れ基準の候補には、W3CのWCAG 2.2を使えます。

達成基準には、「名前・役割・値」、キーボード操作、入力ラベル、エラー防止などが含まれます（出典：W3C「Web Content Accessibility Guidelines 2.2」、2024年勧告、https://www.w3.org/TR/WCAG22/）。

• 操作：Tabキーの順序とフォーカス表示
• 構造：見出し階層とフォームラベル
• 状態案内：エラーの読み上げ、色だけに依存しない表示
• 中断時：タイムアウト時の案内

フェーズ5：段階的な稼働による業務影響の抑制

全社へ一度に切り替えるより、対象部門や一つの業務から始めるほうが安全です。移行の前に、切り替えの条件と担当を決めておきます。稼働の直前には、移行から負荷対策まで4つの準備が要ります。

• 移行：初期データ投入と既存データとの差分確認
• 運用準備：権限付与、バックアップ、問い合わせ窓口
• 障害対応：切り戻し条件と障害時の判断者
• 負荷対策：利用者増加時の応答性能とAPI停止時の入力保持

稼働を判定するときは、代表的な利用者が実際の業務を最後まで完了できるかを基準にします。たとえば案件登録なら、検索から登録、承認までを、通知や帳票出力、監査ログ確認も含めて一連のシナリオにします。

リリース当日は、利用者数やエラー率、API応答時間を監視します。未処理チケットと問い合わせ件数も、あわせて見ておきます。想定を超えた場合に備えて、段階的に止められるようにしておきます。

フェーズ6：運用で続ける定着と改善

稼働させただけでは、システムは定着しません。そこで、利用者向けの説明は機能一覧ではなく、実際の業務シナリオに沿って作ります。運用では、次の3種類の作業を続けます。

• 管理手順：ユーザー追加、権限変更、マスタ更新
• 障害・データ対応：ログ確認、障害連絡、データ訂正
• 変更管理：変更ルールとレビュー担当を決め、特定開発者への依存を避ける

定着後は、月次または四半期ごとに利用率や処理時間、入力エラーを確認します。問い合わせや画面別の離脱、障害、脆弱性、依存パッケージの更新状況も、同じ周期で見ていきます。

改善要望は、業務影響や利用者数に加えて、セキュリティ、法令、対応コストも基準にして順位をつけます。また、部品を増やす前に既存部品のAPIを安定させることは、長期的な保守性につながります。

Litのシステム開発にかかる費用相場とコストの内訳

Litはオープンソースのライブラリのため、完成品の利用料を払う製品とは費用の構造が異なります。

初期費用には、要件定義やUI・部品設計、画面開発が含まれます。さらに、API・認証、データ移行、テスト、教育、クラウド構築も含まれます。

ここに示す金額は、Lit専用の公開価格ではありません。2026年時点の一般的な業務システム相場と、Litを画面層に採用する場合を前提にした目安です。

規模別の費用レンジ（100万円台から数千万円以上）

費用相場は、規模と含める作業によって変わります。条件ごとの目安を、次の4段階で比べます。

• PoC：既存API接続で部品数・認証・実データ・テストを限定すると、100万〜300万円程度
• 小規模画面：検索・登録・権限管理・基本テストを含め、300万〜800万円程度
• 部門横断：顧客・案件・在庫を扱い、複数システム連携やデータ移行を伴う場合は500万〜1,000万円程度から
• 全社規模：基幹連携、大量データ、複数拠点、複雑な権限、帳票、バッチ、24時間運用を含め、1,000万円〜数千万円以上

いずれも、Lit専用の価格表ではありません。既存資産を再利用できるかどうかで、金額は変わります。大規模な案件では、要件によって億単位になることもあります。

SIA株式会社の2026年7月更新の記事でも、小規模は100万〜300万円、中規模は500万〜1,000万円、大規模は1,000万円〜数千万円以上が目安とされています。

人月単価は60万〜200万円程度と示されています（出典：SIA株式会社「システム開発の費用・相場 2026年版」、2026年7月、https://www.siainc.jp/topic/system-development-cost）。

費用を左右する業務と非機能の複雑さ

同じ10画面でも、単純な参照だけの画面と、複数承認や履歴管理、帳票、外部連携を持つ画面とでは工数が異なります。そのため、個別画面の開発費だけで比べないようにします。費用は、上流から導入までの工程と、Litで抜けやすい作業に分けて見ます。

• 上流工程：要件定義、基本設計、詳細設計
• 開発：共通部品、業務画面、API
• 導入：データ移行、テスト、導入支援
• Litで抜けやすい作業：部品初期設計、文書、アクセシビリティ、ブラウザ検証、ビジュアルリグレッションテスト

期間は、PoCなら1〜2か月、小規模画面なら2〜4か月、部門横断なら6〜12か月程度を検討することがあります。これは、画面数や体制、意思決定の速さ、既存APIの有無に左右される目安です。

開発会社には、工程ごとの前提と担当人数を明記してもらいます。加えて、成果物や顧客側の作業、遅延時の扱いも示してもらいます。

保守とクラウドのランニングコスト

稼働後のランニングコストは、次の4つに分けて確認します。

• クラウド費用：コンピュート、データベース、ストレージ、CDN、監視、バックアップ
• 保守対応：問い合わせ、障害対応、ブラウザ更新、脆弱性調査、軽微な改修
• 見積もり項目：月額固定保守、追加改修、クラウド実費、ライセンス、診断、保管、教育更新
• 依存パッケージ：Litやnpmパッケージの更新作業

保守費用は初期開発費の10〜20%程度などと語られることがあります。ただし、平日日中のみの監視か、夜間休日の障害対応やSLAを含むかで変わります。そのため、対応時間と作業範囲を確認します。

依存パッケージを更新しないままだと、短期的には安く見えても、脆弱性対応やブラウザ差分の修正が後回しになります。そこで、更新の担当と周期も運用設計に含めます。

Litのシステム開発で見積もりを取る際のポイント

複数社から見積もりを取るときは、合計額だけでなく、同じ前提で比べられるRFPを使います。

Litの部品実装にとどまらず、要件定義からAPI、認証、データ移行、運用まで担えるかを確かめます。

技術名の掲載の有無より、実データを使った説明と成果物で評価します。

要件と見積もりの前提のそろえ方

見積もり条件の解釈がずれないよう、RFPと依頼時の前提をそろえます。RFPを4つの区分に分けて書いておくと、見積もり条件の読み違いが減ります。

• 業務：目的、対象部門、利用者数、権限、画面一覧、業務シナリオ
• データ・連携：既存システム、API、データ量、移行方法、連携先、帳票
• 品質・時期：対応ブラウザ、性能、可用性、セキュリティ、アクセシビリティ、希望時期
• 技術前提：共通部品の種類と再利用先、ReactやVueとの共存、SSR、旧ブラウザ対応

画面一覧では、参照、検索、登録、承認、出力を区別して書き、例外時の動作も加えておくと、会社ごとの解釈差を小さくできます。

Litは、ES2021として公開され、現代的なWeb APIを使います。一方で、古いブラウザには、ポリフィルや別構成が必要になる場合があります。そのため、前提に含めます（出典：Lit公式「Requirements」、2026年閲覧、https://lit.dev/docs/tools/requirements/）。

開発会社の比較観点（技術・業務・運用）

開発会社は、技術・業務・運用の実務経験と、契約後の引き継ぎ条件を確かめて比べます。実績の確認から契約終了の条件まで、5つの項目で比べます。

• 実績確認：Litの実案件名を公開できる範囲で確認し、非公開なら匿名化したコード例やデモを見る
• 技術力：部品API・イベント・テスト・アクセシビリティの考え方、React・Vue連携、TypeScript、E2E、UI標準化
• 業務対応：要件定義、現場ヒアリング、データ移行、バックエンドの認証・認可・監査ログ
• 運用・契約：コード・設計書の権利、再委託、脆弱性、障害連絡、保守時間、担当交代時の引き継ぎ
• 契約終了：データと開発環境の返却条件

Litの掲載や自社サイトの記載だけで技術力を判断するのは避け、説明の内容も確かめます。

見積もりに含める個人情報とセキュリティの作業

顧客情報や従業員情報、個人番号などを扱う業務システムでは、Litの画面だけで安全性を説明できません。また、Shadow DOMも、攻撃者からデータを隠す仕組みではありません。見積もりには、秘密情報の扱いから記録まで4つの対策を含めます。

• 秘密情報：アクセストークンや秘密鍵をブラウザへ埋め込まない
• 通信と権限：API側で認可し、通信を暗号化する
• 脆弱性対策：CSP・XSS対策と依存パッケージ監査を行う
• 記録：管理操作を監査ログへ残す

個人情報保護委員会の通則ガイドラインは、安全管理措置として、組織体制や取扱状況の確認、漏えい時の対応を示しています。さらに、従業者教育や委託先監督も挙げられています。

2026年6月改正のガイドラインも公開されています。そのため、対象となる情報と委託の範囲に応じて確認します（出典：個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年6月改正、https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/）。

見積もりには、脆弱性診断、権限レビュー、ログ設計のほか、委託先確認や教育、インシデント訓練の有無も含めます。

Litのシステム開発でよくある質問

Litの採用では、ライブラリの特徴に加えて、既存システムや利用者、チームの技術力、将来の保守も考えます。検討の初期によく出る質問に、順に答えます。

LitはReactやVueの代わりになりますか？

Litは、ReactやVueと同じ目的だけを持つライブラリではなく、Web Componentsを作る軽量な画面基盤です。既存の画面を残したまま、Litで共通部品を作って既存画面から使う構成も選べます。

ルーティングや状態管理を含むアプリ全体の最適な構成は、PoCで比較して決めます。

Litを使うとシステム開発費は安くなりますか？

Litのライセンス費用だけで開発費は決まらないため、必ず安くなるとは限りません。ただし、複数の画面で部品を再利用できれば、重複開発を抑えられる可能性があります。

一方で、共通部品の設計やアクセシビリティ、ブラウザ検証、異なるフレームワークとの接続には、初期の工数がかかります。見積もりは、画面数や再利用数、既存APIを前提にして比べます。認証や移行、テストの条件もそろえておきます。

Litの開発会社は何を基準に選べばよいですか？

開発会社には、Litの実績だけでなく、Web Components、TypeScript、UI設計、API・認証を説明できることが求められます。そのうえで、要件定義やテスト、アクセシビリティ、運用移管も確認して選びます。

実データを使う小規模なPoCで、検索や登録、権限、エラー表示を確かめます。あわせて、コードやテスト、文書、保守提案も比べます。

Litの公開実績が確認できない会社は、その事実を隠さず、担当チームの経験と提案内容で評価します。

Shadow DOMを使えばセキュリティ対策は十分ですか？

十分ではありません。Shadow DOMは、DOMとスタイルを部品の中に閉じ込める仕組みです。APIの認証・認可や通信暗号化、CSP、XSS対策の代わりにはなりません。秘密情報管理、ログ、脆弱性対応も、別に設計が必要です。

画面で隠しただけのデータは、保護されたとは判断しません。サーバー側の権限チェックと、個人情報の取扱規程を含めて設計します。

まとめ：Litのシステム開発は段階的な検証が成功の鍵

大切なのは、Litを採用すること自体ではありません。業務を整理し、再利用できる画面部品と業務ロジックを分けたうえで、利用者が継続して使える状態まで届けることです。

各段階で終了条件を決めておくと、技術の好みだけで計画が進むリスクを減らせます。要件整理、選定、設計開発、テスト、稼働、定着の順に、6つのフェーズを確かめます。

着手前に確認する5つの判断基準

契約の前に、Litの適用範囲と導入後の体制を整理しておくと、開発計画の前提をそろえやすくなります。確認する項目は次の5点です。

• 画面範囲：Litを使う画面と使わない画面の境界
• 再利用：共通部品を使う画面数
• 既存資産：ReactやVueなどとの接続方法
• 受け入れ条件：ブラウザ、アクセシビリティ、セキュリティ
• 運用：保守担当と更新予算

5点があいまいなまま契約すると、技術選定や対象範囲をやり直すことになり、費用と期間も膨らみやすくなります。

最初の一歩は実業務を使った小さなPoC

実業務から、検索・登録・承認のシナリオを一つ選びます。そのうえで、Lit部品やAPI、権限を含む小さなPoCを作ります。エラー表示やキーボード操作、テストも、この中で確かめます。

結果をもとに、Litを広げる範囲や別のフレームワークを使う範囲、開発会社、初期費用、保守費用を見直します。その後、根拠のある本開発の計画へ移行できます。

▼全体ガイドの記事
・Litのシステム開発の完全ガイド

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