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

Litのシステム開発は、Litを業務システム全体の製品として導入するのではなく、Web Componentsで再利用しやすい画面部品を整え、API・業務ロジック・データ基盤と組み合わせて段階的に進める方法が基本です。

「Litのシステム」と検索した方の中には、LitがERPやCRMの完成品なのか、ReactやVueの代替になるのか、導入するといくらかかるのかを知りたい方が多いです。この記事では、技術名としてのLitを前提に、要件整理から選定、設計開発、テスト、稼働、定着までの進め方を、実務で使える判断基準とチェックリストに落とし込んで解説します。

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

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

Litは、Custom ElementsやShadow DOMなどのWeb標準を利用して、再利用可能なWeb ComponentsをJavaScriptまたはTypeScriptで作るためのライブラリです。画面のボタン、検索フォーム、テーブル、入力ダイアログ、通知、ナビゲーションなどを部品化し、複数の業務画面や異なるフレームワークの画面で共有できます。

最初に押さえたいのは、LitがERP、CRM、販売管理、勤怠管理などの業務機能を提供する製品ではないことです。Litが主に担当するのは、利用者がブラウザで操作する画面層です。認証・認可、API、業務ルール、データベース、帳票、バッチ、監査ログ、クラウド基盤、バックアップ、運用監視は別途設計する必要があります。

したがって「Litを導入すれば開発費が下がる」と単純に考えるのは危険です。ライブラリ自体のライセンス費用より、業務要件の整理、共通コンポーネントの設計、API連携、データ移行、品質保証、社内への引き継ぎに工数がかかります。Litの再利用性が生きるのは、同じ操作部品を複数の画面やサービスで使う計画がある場合です。

Litの採用が向くのは、既存のReact、Vue、Angular、サーバーサイドHTMLが混在している社内ポータル、複数サービスで共通部品を利用したい場合、全面刷新ではなく一画面ずつ段階移行したい場合です。Shadow DOMでスタイルを閉じ込めやすく、既存画面にウィジェットを埋め込む構成にも適しています。

一方、短期間で豊富な業務向け部品、ルーティング、状態管理、チームの既存ノウハウをそろえることが最優先なら、ReactやVueなども候補に残すべきです。Litを選ぶこと自体を目的にせず、既存資産との境界、部品を何画面で再利用するか、将来の保守担当者が読めるかをPoCで比較することが重要です。Lit公式も、Lit 3はInternet Explorer 11やClassic Edgeをサポート対象としていないと説明しているため、対応ブラウザを先に確認します（出典: Lit公式「Requirements」、2026年閲覧、https://lit.dev/docs/tools/requirements/ です）。

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

Litのシステム開発は、技術選定から始めるよりも、業務上の目的と利用者の行動を整理し、画面層・API・データ・運用の責任範囲を決めてから進めます。ここでは、要件整理、選定、設計開発、テスト、稼働、定着の6フェーズに分けます。各フェーズの終了条件を文書化すると、見積もりの追加や認識違いを抑えやすくなります。

要件整理では、まず「誰が、どの業務を、何分短縮したいのか」「入力ミスや二重入力を何件減らしたいのか」を定義します。画面一覧だけでなく、現行のExcel、紙、メール、FAX、既存システムを使った業務フローを並べ、例外処理や承認経路まで確認します。現場の不便をそのまま画面に移すのではなく、不要な承認や重複入力を廃止できるかも検討します。

チェックリストとして、対象利用者と権限、業務上の目的、必須画面、入力項目、検索条件、承認状態、マスタの管理者、既存データの移行範囲、外部連携、保持期間、監査ログ、同時利用者数、目標応答時間、対応ブラウザ、アクセシビリティ要件、障害時の連絡先を確認します。Litで作る画面と、バックエンドや既存サービスが担う機能を境界図にしておくと、後工程で「そこまでLit側の見積もりに含まれると思わなかった」という問題を防げます。

選定では、Litを使うかどうかだけでなく、TypeScript、ビルドツール、ルーティング、状態管理、フォーム処理、UIコンポーネントの配布方法、API方式、認証方式、テストツール、監視方法を決めます。ReactやVueの既存画面と同居する場合は、属性とプロパティの渡し方、Custom Eventの命名、フォーム値の受け渡し、エラー表示、スタイルの共有方法を実データに近い条件で検証します。

PoCは、見た目だけのボタンではなく、検索、一覧表示、登録、入力エラー、権限による表示制御、API失敗時の再試行までを含む一つの業務シナリオで実施します。判断基準は、部品を別画面でも再利用できるか、キーボードで操作できるか、E2Eテストで安定して要素を取得できるか、開発者がAPI仕様を理解できるか、既存画面に影響を与えないかです。PoCの成果物には、採用理由だけでなく不採用時の代替案、未解決の制約、追加費用の条件も残します。

設計開発では、画面ごとの仕様だけでなく、共通コンポーネントのAPIを定義します。たとえば日付入力なら、受け取る値の形式、未入力の扱い、最小日・最大日、タイムゾーン、エラー文、フォーカス移動、変更イベントを決めます。テーブルなら、ページング、並び替え、絞り込み、空データ、読み込み中、通信エラー、大量データ時の表示を最初から設計します。

Lit公式が説明するShadow DOMは、コンポーネント内部のDOMやスタイルを外部から分離し、別のWeb Componentsや既存コードとの相互運用をしやすくする仕組みです。ただし、DOMの境界は認証やデータ秘匿の境界ではありません。認可は必ずAPIやサーバー側で実施し、画面で非表示にしただけの機能を安全と判断しないようにします（出典: Lit公式「Working with Shadow DOM」、2026年閲覧、https://lit.dev/docs/components/shadow-dom/ です）。

開発会社に依頼する場合は、ソースコードだけでなく、コンポーネントカタログ、プロパティとイベントの仕様、デザイントークン、ブラウザ対応表、テストコード、依存パッケージ一覧、脆弱性対応方針、運用手順を納品物に含めます。部品と業務画面を別レイヤーにしておくと、後でReactやVueの画面から利用したり、別サービスへ移植したりする判断がしやすくなります。

テストは単体テストだけで完了させず、コンポーネント単体、画面結合、API連携、権限、業務シナリオ、性能、障害復旧、ブラウザ、アクセシビリティの順に観点を広げます。特にShadow DOMを使う場合は、見た目が正しいかだけでなく、フォーカスが内部に閉じ込められないか、ラベルとエラーが支援技術に伝わるか、キーボードだけで登録を完了できるかを実機で確かめます。

アクセシビリティの受け入れ基準には、W3CのWCAG 2.2を候補にできます。WCAG 2.2には「名前・役割・値」やキーボード操作、入力ラベル、エラー防止などの達成基準が含まれます（出典: W3C「Web Content Accessibility Guidelines 2.2」、2024年勧告、https://www.w3.org/TR/WCAG22/ です）。チェック項目は、Tabキーの順序、フォーカス表示、見出し階層、フォームラベル、エラーの読み上げ、色だけに依存しない状態表示、タイムアウト時の案内を明文化します。

稼働では、いきなり全社へ切り替えるのではなく、対象部門や一つの業務から始める方法が安全です。移行前に、初期データの投入、既存データとの差分確認、権限付与、バックアップ、切り戻し条件、問い合わせ窓口、障害時の判断者を決めます。利用者が増える時間帯の応答性能や、APIが止まったときに入力内容を失わない設計も確認します。

稼働判定は「画面が表示される」ではなく、代表的な利用者が実際の業務を最後まで完了できることを基準にします。たとえば案件登録なら、検索、登録、承認、通知、帳票出力、監査ログ確認までを一連のシナリオにします。リリース当日は、利用者数、エラー率、API応答時間、未処理チケット、問い合わせ件数を監視し、想定を超えた場合に段階停止できるようにします。

システムは稼働させただけでは定着しません。利用者向けの操作説明を、機能一覧ではなく実際の業務シナリオで作り、管理者向けにはユーザー追加、権限変更、マスタ更新、ログ確認、障害連絡、データ訂正の手順を用意します。特定の開発者だけがLitのコンポーネントを変更できる状態を避けるため、変更ルールとレビュー担当も決めます。

定着後は、月次または四半期ごとに利用率、処理時間、入力エラー、問い合わせ、画面別の離脱、障害、脆弱性、依存パッケージの更新状況を確認します。改善要望はすべて同じ優先度で受けるのではなく、業務影響、利用者数、セキュリティ、法令、対応コストで順位をつけます。Litの部品を増やす前に、既存部品のAPIを安定させることが、長期的な保守性につながります。

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

Lit単体はオープンソースのライブラリであり、完成品の利用料を支払う製品とは費用構造が異なります。初期費用の中心は、要件定義、UI・コンポーネント設計、画面開発、API・認証、データ移行、テスト、教育、クラウド構築です。以下の金額はLit専用の公開価格ではなく、2026年時点で公開されている一般的な業務システム相場と、Litを画面層に採用する場合の前提付きの目安です。

既存APIに接続するLitコンポーネントのPoCは、対象部品数、認証、実データ接続、テスト範囲を限定した場合に100万〜300万円程度が一つの検討レンジです。小規模な社内業務画面で、検索・登録・権限管理・基本テストまで含める場合は、300万〜800万円程度が目安になります。ただし、どちらもLit専用の価格表ではなく、既存資産を再利用できるかで大きく変わります。

部門横断の顧客・案件・在庫などを扱い、複数の外部システムやデータ移行を伴う場合は、500万〜1,000万円程度のレンジから検討するケースがあります。全社基幹連携、大量データ、複数拠点、複雑な権限、帳票、バッチ、24時間運用まで含めると、1,000万円〜数千万円以上、要件によっては億単位になります。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画面でも、単純な参照画面と、複数承認・履歴管理・帳票・外部連携を持つ画面では工数が異なります。見積もりでは、要件定義、基本設計、詳細設計、コンポーネント開発、業務画面開発、API開発、データ移行、テスト、導入支援を分けます。特にLit案件では、共通部品の初期設計、ドキュメント、アクセシビリティ、ブラウザ検証、ビジュアルリグレッションテストが抜けやすいため、個別画面の開発費だけで比較しないことが大切です。

期間も、PoCなら1〜2か月、小規模画面なら2〜4か月、部門横断なら6〜12か月程度を検討することがありますが、これは画面数、体制、意思決定の速さ、既存APIの有無に左右される目安です。開発会社には、工程ごとの前提、担当人数、成果物、顧客側の作業、遅延時の扱いを明記してもらいます。

稼働後は、クラウドのコンピュート・データベース・ストレージ・CDN・監視・バックアップ費用に加え、問い合わせ、障害対応、ブラウザ更新、Litやnpm依存パッケージの更新、脆弱性調査、軽微な改修が発生します。保守費用は初期開発費の10〜20%程度などの目安で語られることがありますが、監視が平日日中だけか、夜間休日の障害対応を含むか、SLAを設けるかで変わります。相場をそのまま契約金額にせず、対応時間と含まれる作業を確認します。

見積もりには、月額の固定保守、時間単価の追加改修、クラウド実費、ライセンス、セキュリティ診断、バックアップ保管、教育更新を分けて記載します。依存パッケージを更新しないことは短期的に安く見えても、脆弱性対応やブラウザ差分の修正が後回しになるため、更新作業を誰がどの周期で行うかまで運用設計に含めます。

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

複数社から見積もりを取るときは、金額の合計だけを比べるのではなく、同じ前提で比較できるRFPを作ります。Litの経験をうたう会社でも、Web Componentsの部品実装だけが得意なのか、業務要件定義やAPI、認証、データ移行、運用まで担当できるのかは異なります。技術名の掲載有無ではなく、実データを使った説明と成果物で評価します。

RFPには、目的、対象部門、利用者数、権限、画面一覧、業務シナリオ、既存システム、API、データ量、移行方法、連携先、帳票、対応ブラウザ、性能、可用性、セキュリティ、アクセシビリティ、リリース希望時期を記載します。画面一覧には「参照」「検索」「登録」「承認」「出力」の区別と、例外時の動作を加えると、会社ごとの解釈差を小さくできます。

見積もり依頼時には、共通コンポーネントを何種類作るか、どの画面で再利用するか、ReactやVueとの共存が必要か、SSRが必要か、旧ブラウザ対応があるかを明示します。Lit公式の要件では、LitはES2021として公開され、現代的なWeb APIを使用します。古いブラウザを対象に含める場合は、ポリフィルや別の構成が必要になり得るため、見積もりの前提から外さないようにします（出典: Lit公式「Requirements」、2026年閲覧、https://lit.dev/docs/tools/requirements/ です）。

候補会社には、Web ComponentsやLitの実案件名を公開できる範囲で確認し、公開できない場合は匿名化したコード例やデモで、部品のAPI、イベント、テスト、アクセシビリティの考え方を説明してもらいます。ReactやVueとの連携経験、TypeScriptの型設計、Shadow DOMを含むE2Eテスト、UIデザインの標準化があるかも確認します。Litのキーワードが自社サイトにあるだけで「Litに強い」と判断しないことが重要です。

業務面では、要件定義に参加する担当者がいるか、現場ヒアリングとデータ移行を任せられるか、認証・認可・監査ログをバックエンドまで設計できるかを見ます。運用面では、ソースコードと設計書の権利、再委託先、脆弱性対応、障害時の連絡、保守の時間帯、担当者交代時の引き継ぎ、契約終了時のデータと開発環境の返却条件を確認します。

顧客情報、従業員情報、個人番号などを扱う業務システムでは、Litの画面実装だけで安全性を説明できません。アクセストークンや秘密鍵をブラウザへ埋め込まないこと、API側で認可すること、通信を暗号化すること、CSPやXSS対策を設定すること、依存パッケージを監査すること、管理操作を監査ログへ残すことを要件化します。Shadow DOMはスタイルとDOMを分離しますが、攻撃者からデータを隠す仕組みではありません。

個人情報保護委員会の通則ガイドラインでは、安全管理措置として組織体制、取扱状況の確認、漏えい時の対応体制、従業者教育、委託先の監督などが示されています。2026年6月改正のガイドラインも公開されているため、対象情報と委託範囲に応じて確認します（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年6月改正、https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/ です）。見積もりには、脆弱性診断、権限レビュー、ログ設計、委託先確認、教育、インシデント訓練の有無も含めます。

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

Litの採用判断では、ライブラリの特徴だけでなく、既存システム、利用者、チームの技術力、将来の保守を一緒に考える必要があります。ここでは、検討初期に特に多い質問へ直接回答します。

LitはReactやVueと同じ目的だけを持つライブラリではなく、Web Componentsを作るための軽量な画面基盤です。既存のReactやVueを全面的に置き換えるのではなく、共通ボタンや入力部品をLitで作り、既存画面から利用する構成も選べます。ルーティングや状態管理を含むアプリケーション全体の最適解は、PoCで比較して決めます。

Lit自体のライセンス費用が開発費を決めるわけではないため、必ず安くなるとはいえません。複数画面で同じ部品を再利用できれば重複開発を抑えられる一方、共通部品の設計、アクセシビリティ、ブラウザ検証、異なるフレームワークとの接続に初期工数がかかります。画面数、再利用数、既存API、認証、移行、テストを前提に見積もりを比較します。

Litの掲載実績だけでなく、Web Components、TypeScript、UI設計、API・認証、業務要件定義、テスト、アクセシビリティ、運用移管を一つの体制で説明できる会社を選びます。実データを使った検索・登録・権限・エラー表示の小規模PoCを依頼し、コード、テスト、ドキュメント、保守提案まで確認すると比較しやすくなります。Litの公開実績が確認できない会社は、確認できない事実を隠さず、担当チームの経験と提案内容で評価します。

十分ではありません。Shadow DOMはDOMとスタイルをコンポーネント内に閉じ込める仕組みであり、APIの認証・認可、通信暗号化、CSP、XSS対策、秘密情報の管理、ログ、脆弱性対応を代替しません。画面で隠しただけのデータを保護されたと判断せず、サーバー側の権限チェックと個人情報の取扱規程を含めて設計します。

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

Litのシステム開発で大切なのは、Litを採用することではなく、業務を整理し、再利用できる画面部品と業務ロジックを適切に分離し、利用者が継続して使える状態まで届けることです。要件整理、選定、設計開発、テスト、稼働、定着の各段階で終了条件を決めると、技術の好みだけで計画が進むリスクを減らせます。

着手前は、第一にLitを使う画面と使わない画面の境界、第二に共通部品を再利用する画面数、第三にReactやVueなど既存資産との接続方法、第四にブラウザ・アクセシビリティ・セキュリティの受け入れ条件、第五に稼働後の保守担当と更新予算を確認します。この5点が曖昧なまま契約すると、開発途中で技術選定や対象範囲が戻り、費用と期間が膨らみやすくなります。

次の一歩は、実際の業務から一つの検索・登録・承認シナリオを選び、Litの部品、API、権限、エラー表示、キーボード操作、テストを含む小さなPoCを作ることです。PoCの結果をもとに、Litを広げる範囲、別のフレームワークを使う範囲、必要な開発会社、初期費用と保守費用を見直せば、根拠のある本開発計画へ移行できます。

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

会社紹介

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

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

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