Litのシステム開発の完全ガイド

Litのシステムとは、Web Componentsを作るJavaScriptライブラリ「Lit」を画面層に採用した業務システムで、Lit自体がERPやCRMの完成品になるわけではありません。

顧客管理、案件管理、受発注、在庫、勤怠、社内ポータルなどを検討している方に向けて、Litでできること、ReactやVueとの違い、構成、開発手順、費用相場、開発会社・ベンダーの選び方、セキュリティまでをまとめます。技術選定だけでなく、既存システムとの共存や将来の保守まで判断できるように解説します。

▼関連記事一覧
・Litのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・Litのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・Litのシステム開発の見積相場や費用/コスト/値段について
・Litのシステム開発の発注/外注/依頼/委託方法について

Litのシステムとは何ですか？

Litのシステムを一言で表すと、標準HTMLの仕組みを活用しながら、再利用しやすい画面部品を組み合わせて作るWebシステムです。Litは画面を表示するためのライブラリであり、データベース、認証、業務ルール、帳票、バッチ、監査ログ、クラウド基盤までを自動で用意する製品ではありません。

Litは、Custom Elements、Shadow DOM、HTMLテンプレートといったWeb標準を扱いやすくするライブラリです。状態を持つリアクティブプロパティが変わると必要な部分だけを更新し、宣言的なテンプレートで画面を記述できます。公式ドキュメントでは、圧縮後およそ5KBの小さなサイズが特徴として示されています（出典：Lit公式ドキュメント、2026年確認）。

たとえば、検索フォーム、日付入力、明細テーブル、通知、モーダル、承認ボタンをそれぞれCustom Elementとして作成できます。一度設計した部品を複数の画面や別のWebアプリで利用できるため、同じ操作感を保ちながら画面を増やせます。TypeScriptを使えば、部品が受け取る値や発火するイベントの型も定義できます。

業務システムの構成は、画面コンポーネント、API、業務サービス、データベース、認証認可、監視・ログに分けて考えると整理しやすくなります。Litはこのうち主に画面コンポーネントを担当し、APIや業務ロジックはJava、C#、PHP、Python、Goなど別の技術で構築できます。

したがって「Litを導入すれば開発費が必ず下がる」と考えるのは適切ではありません。画面部品を再利用できる一方で、業務要件の整理、データ移行、権限設計、結合テスト、運用設計は必要です。Litの採用効果は、画面数、利用する部門、既存フロントエンドとの共存期間、共通部品を将来も使い続けるかによって判断します。

Litのシステムでできることと向いている業務

Litは、画面の共通化と段階的な刷新に強みがあります。特定の業務だけを小さく作り、実際の利用状況を見ながら対象範囲を広げる方法と相性が良い技術です。反対に、画面以外の機能を含む製品を短期間で導入したい場合は、Lit単体ではなくパッケージやSaaSとの組み合わせを検討します。

顧客一覧、案件検索、受注登録、在庫照会、勤怠申請、経費承認などは、複数の業務システムで似た操作が繰り返されます。テーブル、ページネーション、絞り込み、入力エラー、確認ダイアログ、通知を部品化すれば、画面ごとに別の実装を作る必要が減ります。

特に、部門ごとにシステムが増え、ボタンの位置や入力ルールがばらばらになっている企業では、共通コンポーネントとデザイン・トークンが効果を発揮します。ただし、部品を増やすこと自体が目的になると、汎用性を高めるための設計費が膨らみます。最初は利用頻度が高く、業務ルールが安定している部品から始めるのが現実的です。

Litで作ったWeb Componentは、ブラウザからは通常のHTML要素として扱われます。そのため、既存のサーバーサイドHTML、React、Vue、Angularなどと同じ画面や同じポータル内に置く構成を取りやすくなります。全社システムを一括刷新するのではなく、検索画面や申請フォームなど一部の機能から置き換える方法が選べます。

段階移行では、旧画面と新画面の権限、URL、イベント、エラーメッセージ、データ取得方法をそろえることが重要です。見た目だけを移行してAPIや業務ルールが二重化すると、障害時に原因を追いにくくなります。最初の対象は、利用者が多く効果を測定しやすい一方、外部連携が複雑すぎない業務を選びます。

LitとReact・Vueの違いは何ですか？

結論として、LitはWeb標準に近い再利用部品を作りたい場合に向き、ReactやVueはアプリケーション全体の開発体験や周辺ライブラリを重視する場合に選ばれやすいです。どれが優れているかではなく、既存資産、チームの経験、必要な画面機能、将来の移行方針を基準に比較します。

Litの大きな特徴は、作った部品が特定のアプリケーション構造だけに閉じにくいことです。HTML要素として扱えるため、複数のフロントエンドやサーバーサイド画面で共通部品を利用できます。小さなウィジェットを既存画面へ埋め込む、複数サービスで入力部品を共有する、といった用途ではメリットを説明しやすいです。

また、リアクティブプロパティの変更をまとめて更新する仕組みや、コンポーネント内のスタイルを分離するShadow DOMにより、不要な再描画やCSSの衝突を抑えやすくなります。2025年10月には、LitがOpenJS FoundationのImpact Projectに加わったことが公式に発表され、単一組織だけに依存しないオープンな運営への移行が示されました（出典：Lit公式ブログ、2025年）。

ReactやVueと比較する際は、画面部品の書きやすさだけを比べてはいけません。ルーティング、状態管理、フォーム、データ取得、サーバーサイドレンダリング、認証、テスト、開発者の採用しやすさまでを確認します。Litにも周辺ツールはありますが、必要な構成をプロジェクトごとに決める範囲が広い場合があります。

既存チームがReactを中心に運用しているなら、すべてをLitへ変更するより、共通ボタンや入力部品だけをLitで作って共存させる案が候補になります。一方、サービス全体を一つのフレームワークと豊富な周辺機能で統一したい場合は、ReactやVueを含めたPoCを比較します。採用理由を「軽いから」だけにせず、3年後の保守担当者が理解できるかまで確認します。

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

Lit案件では、最初にライブラリを選ぶのではなく、業務と既存資産を整理してから技術を決めます。現場のExcel、紙、二重入力、例外処理をそのまま画面に移すと、非効率な業務をデジタル化するだけになるためです。1画面のPoCで使い勝手と技術上のリスクを検証し、受け入れ条件を満たした構成を本開発へ広げます。

要件定義では、利用者、業務の開始条件、入力項目、承認者、例外処理、データの保存期間、他システムとの連携先を整理します。画面一覧だけでなく、権限マトリクス、業務状態の遷移、エラー時の対応、帳票や通知の要否まで明確にします。

非機能要件には、同時利用者数、応答時間、可用性、バックアップ、対応ブラウザ、ログの保持期間、障害時の復旧目標、オフライン可否、アクセシビリティを含めます。Lit公式のRequirementsでは、現代的なブラウザとWeb Componentsの利用を前提にし、古いブラウザではポリフィルなど追加対応が必要になると説明されています（出典：Lit公式Requirements、2026年確認）。

PoCでは、見栄えの良いデモだけでなく、実データに近い検索・登録・更新・エラー表示を作ります。LitコンポーネントのAPI、属性とプロパティの使い分け、イベントの命名、フォームのバリデーション、Shadow DOMの境界、Reactや既存HTMLとのイベント連携を確認します。

コンポーネントを増やす前に、デザイン・トークン、命名規則、状態の表現、画面幅、キーボード操作を決めます。部品カタログとテストを同時に整備すると、後から別画面へ展開するときの判断が速くなります。PoCの成果物には、ソースコードだけでなく、採用理由、制約、未解決リスク、代替技術の比較も含めます。

本開発では、Litの画面層とAPI、業務サービス、データベースを分離します。画面側に業務ルールを埋め込みすぎると、別画面やバッチで同じ計算を再利用できず、仕様変更時の修正漏れが起きやすくなります。APIでは、入力チェック、権限確認、エラーコード、ページング、監査対象の操作を定義します。

認証済みであることと、特定の顧客情報を閲覧してよいことは別の問題です。利用者、組織、役割、対象データの範囲をサーバー側で判定し、ブラウザの表示制御だけに頼らない設計にします。アクセストークンや秘密鍵をソースコードへ埋め込まず、通信暗号化、CSP、XSS対策、npm依存パッケージの脆弱性監査も工程に含めます。

テストは、コンポーネント単体、APIとの結合、複数画面をまたぐ業務シナリオ、権限、ブラウザ、負荷、障害復旧の順に重ねます。申請者が登録し、承認者が確認し、差し戻し後に再申請するような実際の流れを、テストデータと操作手順に落とし込みます。

Shadow DOMを使う部品は、E2Eテストの要素取得やフォーカス移動が通常のDOMと異なる場合があります。スクリーンリーダー、キーボード、ズーム表示、エラー通知を実機で確認し、利用部門の代表者による受け入れテストを行います。リリース後は、利用率、入力完了率、エラー件数、処理時間を測り、段階的に対象業務を増やします。

Litのシステムの費用相場と開発期間

Lit自体はオープンソースのため、ライセンス購入費を中心に予算を考える技術ではありません。費用の中心は、要件定義、共通部品の設計、画面開発、APIと業務ロジック、データ移行、テスト、クラウド、教育、保守です。2026年公開の一般的なシステム開発相場では、小規模が100万〜300万円、中規模が500万〜1,000万円、大規模が1,000万円〜数千万円以上とされています（出典：2026年公開のシステム開発費用相場調査、2026年）。

既存APIに接続するLitコンポーネントのPoCなら、100万〜300万円程度が一つの目安です。検索・登録・権限管理を含む小規模な社内業務画面なら300万〜800万円程度、部門横断の顧客・案件・在庫管理なら500万〜1,000万円程度を起点に考えます。複数拠点、大量データ、基幹連携、複雑な承認や帳票がある場合は、1,000万円を超え、数千万円から億単位になることもあります。

この金額はLit専用の定価ではなく、画面層にLitを採用した場合の業務システム全体の推定です。画面数、ユーザー数、既存APIの有無、認証方式、データ移行量、対応ブラウザ、アクセシビリティ試験、リリース後のサポート範囲によって変動します。PoCは安く見えても、実データ接続や運用監視を追加すると本番費用は増えるため、見積書の前提を確認します。

見積金額は、人月単価に工数を掛けた開発費だけでは決まりません。企画と要件定義、UI設計、コンポーネント設計、API開発、データベース、外部連携、テスト、移行、マニュアル、教育、プロジェクト管理が積み上がります。共通部品を丁寧に作るほど初期設計は増えますが、複数画面に展開するなら後工程の重複を減らせます。

開発期間は、PoCなら1〜2か月、小規模な画面なら2〜4か月、部門横断システムなら6〜12か月を目安にします。基幹システムとの連携、データ移行、現場調整が多いと、画面の実装期間より要件調整とテスト期間が長くなります。工程を短くするためにテストや移行を削ると、本番後の障害対応費用が増えるため、削減対象は機能の優先順位から決めます。

保守費は、初期開発費の10〜20％程度を目安にする考え方があります。たとえば初期費用が3,000万円なら、年間300万〜600万円程度が一つの目安になりますが、これは契約範囲によって大きく変わります。脆弱性対応、依存パッケージ更新、ブラウザ更新、監視、バックアップ、障害対応、軽微な改修、問い合わせ対応を分けて確認します。

Litを使う場合は、ライブラリ本体だけでなく、TypeScript、ビルドツール、テストツール、UI部品、認証SDKなどの依存関係も管理対象です。更新を止めると脆弱性やブラウザ仕様変更への対応が遅れます。ソースコード、設計書、コンポーネントカタログ、依存パッケージ一覧、更新手順を納品物に含め、保守を社内へ移管できる状態にします。

パッケージ・クラウド・スクラッチの選び方

Litを使うかどうかと、業務システムをパッケージ、クラウド、スクラッチのどれで作るかは別の判断です。会計、勤怠、CRM、在庫などの標準機能が業務に合うなら、既製サービスを中心にして、Litで周辺ポータルや入力画面だけを作る構成もあります。独自ルールが競争力になる場合は、スクラッチ開発で業務に合わせます。

会計や勤怠のように一般的な業務で、標準機能と自社業務の差が小さいなら、パッケージやSaaSの導入が有力です。導入期間と初期費用を抑えやすく、アップデートも受けられます。Litは、複数サービスを横断する社内ポータル、独自の検索・申請画面、既製サービスに埋め込むウィジェットで活用できます。

標準機能に合わない部分をすべて個別開発すると、導入費、納期、保守の負担が増えます。業務をサービスに合わせられる範囲と、変えてはいけない競争力のある業務を分けます。追加開発の判断では、初期費用だけでなく、将来のバージョンアップ時に改修が必要かを確認します。

クラウド構成では、Litの静的な画面資産をCDNから配信し、API、認証、データベース、監視を別レイヤーにできます。小さく始めて利用者や画面を増やす段階リリースと相性が良く、環境ごとのデプロイやロールバックも設計しやすくなります。

ただし、クラウドを選べば安全になるわけではありません。アクセス制御、秘密情報の管理、ログの保存先、バックアップ、障害時の復旧、リージョン、通信遅延、月額料金の上限を決めます。LitのShadow DOMはCSSやDOMの境界を作りますが、認証やデータの秘匿境界ではないため、サーバー側の制御を別途実装します。

独自の料金計算、承認経路、在庫引当、製造ルールなどが業務の価値になっている場合は、スクラッチ開発を検討します。Litは画面の再利用と既存資産の段階移行に使い、業務ルールとデータモデルはAPI・サービス層に置きます。新旧画面を一定期間併用するなら、権限とデータの正本を一つに保つことが重要です。

移行対象を一度に広げず、1業務、1部門、1種類の申請から始めます。利用者が少なすぎる実験では本番の負荷や例外が分からず、反対に基幹処理から始めると失敗時の影響が大きくなります。利用率、処理時間、問い合わせ件数を評価し、次の対象を決めます。

セキュリティ・アクセシビリティ・運用の注意点

業務システムでは、画面の軽さだけでなく、個人情報、権限、ログ、利用者の多様性を扱います。特にShadow DOMやCustom Elementを使う場合は、部品の内部に隠れることが品質上の盲点になりやすいため、設計段階からテスト可能性とアクセシビリティを定義します。

顧客情報、従業員情報、取引情報を扱う場合、ブラウザの画面だけでなく、組織的、人的、物理的、技術的な安全管理措置を設計します。利用目的、アクセス権限、委託先の監督、従業者教育、ログの確認、バックアップ、漏えい時の報告と本人通知の体制を要件化します。個人情報保護委員会のガイドラインでも、事業者の業種や規模にかかわらず、安全管理に関する考え方が示されています（出典：個人情報保護委員会「通則編」ガイドライン、2026年確認）。

マイナンバーなど特に慎重な管理が必要な情報では、対象データを画面に表示する必要性を見直し、閲覧・出力・ダウンロード・削除の操作を記録します。フロントエンドに秘密情報を持たせず、API側で権限を再確認します。開発環境の実データ利用を避け、テストデータの匿名化とアクセスログの保管期間も決めます。

業務システムでも、キーボードだけで操作できること、フォーカス位置が分かること、フォームにラベルがあること、エラー内容が利用者に伝わることを確認します。W3CのWCAG 2.2は2024年12月12日付の勧告で、知覚可能、操作可能、理解可能、堅牢という4原則と、名前・役割・値などの検証可能な基準を定めています（出典：W3C「WCAG 2.2」、2024年）。

Custom Elementでは、見た目がボタンでも標準のbutton要素と同じ操作や読み上げになるとは限りません。可能な箇所は標準HTML要素を使い、独自部品ではrole、名前、状態、フォーカス、キーボードイベントを設計します。自動テストだけで終わらせず、実際のブラウザとスクリーンリーダーで確認し、受け入れ条件として記録します。

OSSは無料でも、導入後の更新や脆弱性確認には作業が必要です。依存パッケージを固定するだけでなく、更新の頻度、影響調査、テスト、緊急パッチ、ライセンス確認、廃止されたAPIへの対応者を決めます。依存関係の一覧とソフトウェア部品表を保管すると、問題が発生したときに影響範囲を確認しやすくなります。

開発会社へ依頼する場合は、担当者が変わっても保守できるよう、設計書、画面仕様、イベント仕様、API仕様、テスト結果、デプロイ手順、障害対応手順を引き継ぎます。社内で対応する範囲と外部へ依頼する範囲を契約書に分け、サービス停止を伴う更新の承認フローも用意します。

Litのシステム開発会社・ベンダーの選び方

Litの採用実績が公開されているかどうかだけで、開発会社を判断するのは危険です。Litの実装力に加えて、業務要件定義、API、認証認可、データ移行、アクセシビリティ、テスト、保守移管まで一つの計画にできるかを見ます。公開情報が少ない場合は、提案時のPoCや担当者への質問で確認します。

確認したいのは、単に「Litに対応できます」という営業資料ではありません。Web ComponentsやTypeScriptの実装例、Shadow DOMを含むテスト方法、ReactやVueとの共存経験、APIと認証の設計例、業務システムの要件定義経験、保守中の依存パッケージ更新体制を確認します。

実績を聞くときは、案件名の羅列より、どの課題にどの構成で対応し、どの範囲を納品し、リリース後に何を保守しているかを尋ねます。顧客情報を理由に詳細を見せられない場合でも、匿名化したコード、画面部品のデモ、テスト計画、設計書の目次などで技術の深さを確かめられます。

提案依頼書には、検索、登録、権限別表示、エラー処理を含む小規模PoCを入れます。実データに近い項目を使い、Litを採用する理由、採用しない場合の代替案、既存フレームワークとの接続、テスト方法、見積もりの前提を提出してもらいます。見た目の完成度だけではなく、部品のAPIと将来の再利用性を評価します。

見積もりは、要件定義、設計、開発、テスト、移行、教育、保守を分けて比較します。画面数だけでなく、利用者数、権限数、外部連携数、データ件数、対応ブラウザ、SLA、納品ドキュメントを同じ条件にします。安い提案が、テストや保守を含まないために安く見えていないかを確認します。

契約前に、ソースコード、設計書、テストコード、コンポーネントカタログ、API仕様、依存パッケージ一覧、ライセンス情報、インフラ設定、運用手順の扱いを定めます。成果物の修正権限、OSSと新規コードの権利、第三者サービスの契約主体、データ返却、終了時の移管方法も確認します。

保守では、受付時間、一次回答、復旧目標、脆弱性対応、ブラウザ更新、軽微な改修の定義、追加費用の条件を分けます。Litの知識を持つ人が退職や異動をした場合に備え、複数人でレビューし、定期的に社内へ説明する体制が必要です。

▶ 詳細はこちら：Litのシステム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら：Litのシステム開発の発注/外注/依頼/委託方法について

Litのシステムに関するよくある質問

ここでは、Litのシステムを検討するときに特に多い疑問へ回答します。技術の特徴だけでなく、費用、既存技術との共存、業務システムとしての注意点を基準に判断します。

いいえ、LitはWeb Componentsを開発するための画面層のライブラリです。業務ロジック、データベース、認証、帳票、バッチ、監査ログなどは別途設計・開発します。完成品を導入したい場合はパッケージやSaaSと比較し、独自画面や既存システム連携が必要な場合にLitを組み合わせます。

必ず安くなるわけではありません。ライセンス費用を抑えやすい一方、共通部品の設計、アクセシビリティ、Shadow DOMを含むテスト、既存フレームワークとの接続に工数がかかる場合があります。複数画面や複数サービスで部品を再利用する計画があり、長期的に重複実装を減らせるときに費用対効果を出しやすいです。

導入できます。Web Componentsとして部品を公開し、属性、プロパティ、イベントの境界を明確にすれば、ReactやVue、既存HTMLと共存できます。ただし、フォームの値の受け渡し、イベントの購読、SSR、テスト、型定義はフレームワークごとに確認が必要です。全体移行ではなく、1部品または1画面のPoCから始めます。

Litの経験だけでなく、Web Components、TypeScript、業務要件定義、API、認証認可、テスト、アクセシビリティ、運用保守の経験を確認します。実データに近いPoC、担当チームの体制、納品物、OSSの脆弱性対応、保守移管の方法を提案に含めてもらうと、会社名や営業資料だけでは分からない実力を比較できます。

まとめ

Litのシステムは、Litを画面層に採用し、API、業務ロジック、データ、認証、運用を組み合わせて作る業務システムです。標準HTMLに近い再利用部品、フレームワークをまたいだ共通化、既存画面の段階移行に強みがあります。一方、完成品の業務パッケージではないため、要件定義とバックエンド設計を省略できません。

Litを選ぶなら、複数の画面やサービスで同じUIを使うか、既存のReact・Vue・サーバーサイドHTMLを段階的に移行するかを明確にします。反対に、チームが別のフレームワークに習熟しており、ルーティングや状態管理を一つの構成で短期間にそろえることを優先するなら、他の選択肢をPoCで比較します。

次の一歩は、全社刷新の構想をいきなり発注することではなく、対象業務、利用者、連携先、権限、成功指標を整理することです。そのうえで検索・登録・承認を含む1画面のPoCを作り、使いやすさ、性能、アクセシビリティ、保守性、費用を確認します。技術選定と同時に、現場の業務改善とデータ整備を進めることが、Litのシステムを定着させる近道です。

▼関連記事一覧
・Litのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・Litのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・Litのシステム開発の見積相場や費用/コスト/値段について
・Litのシステム開発の発注/外注/依頼/委託方法について