Litのシステム開発の発注/外注/依頼/委託方法について

Litのシステム開発を発注・外注するときは、Litを業務システムそのものと考えず、Web Componentsを作る画面基盤として位置づけ、業務要件・API・認証・データ・運用まで含めて委託範囲を決めることが重要です。

「Litのシステム」で検索する担当者の多くは、既存のReactやVue、サーバーサイド画面と共存できるか、開発会社へ何を伝えれば見積を比較できるか、費用はいくら見ておくべきかで悩みます。この記事では、発注形態の選択、RFPと要件整理、契約形態、費用相場、委託先の選定、見積比較、セキュリティと保守まで、Litを採用した業務システムを外注する進め方を順番に解説します。

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

Litのシステムを発注・外注するときの全体像

Litの外注案件では、画面部品だけを作るのか、業務システム全体を構築するのかで、必要な会社・費用・契約・期間が変わります。最初に技術の役割を分解し、Litで解決できる範囲と、別途設計が必要な範囲を明確にします。

Litは、Custom Elements、Shadow DOM、HTMLテンプレートなどのWeb標準を使い、再利用可能なWeb ComponentsをTypeScriptまたはJavaScriptで作るための軽量ライブラリです。ボタン、入力欄、検索フォーム、テーブル、モーダル、通知、ナビゲーションなどを共通部品として定義でき、ブラウザからは通常のHTML要素に近い形で扱えます。

一方で、顧客・案件・受発注・在庫・勤怠などの業務ルール、データベース、API、認証認可、帳票、バッチ、監査ログ、クラウド、監視はLitだけでは提供されません。発注書やRFPには「Litで画面を作る」とだけ書かず、画面層、API層、業務サービス層、データ層、インフラ層のそれぞれを誰が担当するかまで記載します。

Litは、複数の社内サービスや拠点で同じUI部品を使いたい場合に適しています。たとえば、営業、購買、在庫、管理部門が利用する画面で、検索条件、一覧表、日付入力、権限による表示、エラー通知を共通化すると、操作のばらつきや重複開発を抑えやすくなります。

ReactやVueを一度に廃止せず、特定の画面や部品から置き換える段階移行にも向いています。Lit公式は、Shadow DOMによって部品内のDOMとスタイルをカプセル化し、他のWeb Componentsや既存コードとの相互運用をしやすくできると説明しています（出典: Lit公式「Working with Shadow DOM」、2026年8月確認）。ただし、イベント、フォーム、ルーティング、状態管理、E2Eテストの境界は設計が必要です。

Litのシステムの発注形態を選ぶ方法

発注形態は、パッケージやSaaSを使うか、既存システムと連携するか、スクラッチで独自業務を作るかの順に比較します。Litを採用することを先に決めるのではなく、業務の標準化と既存資産の活用を確認したうえで、画面基盤としての適性を評価します。

会計、勤怠、CRM、在庫など、業界標準の業務が中心なら、完成済みのSaaSやパッケージを先に比較します。導入期間と初期費用を抑えやすく、製品側のアップデートや運用ノウハウを利用できるためです。Litは製品内部を置き換える目的ではなく、SaaSのデータを集約する社内ポータルや、複数サービスに埋め込む共通ウィジェットに活用しやすい立場です。

ただし、標準機能にない独自処理を大量に追加すると、カスタマイズ費用、アップデート対応、操作テスト、保守負担が広がります。現場の要望を「必須」「標準機能で代替」「将来検討」に分け、製品に合わせられる業務と、会社独自の価値として残す業務を分離します。

既存のPHP、Java、C#、React、Vueなどをすべて作り直す必要はありません。既存APIが利用できるなら、Litで検索・登録・承認の新画面を作り、データと業務ロジックは既存サービスを利用する方式が候補になります。古い画面を一括刷新するより、利用頻度が高く課題の大きい1画面を先に置き換え、操作性と連携方式を検証できます。

この方式では、属性とプロパティの違い、CustomEventの命名、フォーム送信、エラー表示、認証状態の受け渡しを先に決めます。既存画面のCSSやグローバルJavaScriptが新しいWeb Componentへ影響しないかも確認します。Lit公式によれば、現行ブラウザのWeb標準を使う一方、ES2021やbare module specifierなどの要件があるため、対象ブラウザとビルドツールの確認も発注条件に含めます（出典: Lit公式「Requirements」、2026年8月確認）。

独自の承認経路、料金計算、在庫引当、製造ルール、顧客対応などが業務の強みになる場合は、スクラッチ開発を検討します。Litは画面の再利用性を高める役割とし、業務ロジック、データモデル、権限、APIは別レイヤーで設計します。これにより、将来フロントエンド技術を変更しても、業務データとサービスを活用しやすくなります。

最初から全社機能を発注するのではなく、既存APIに接続した検索・登録・権限付き一覧など、1業務のPoCを依頼します。PoCでは見た目だけでなく、実データ、エラー、権限、キーボード操作、ブラウザ検証、ログ出力まで確認します。PoCの合格条件と、本番開発へ移行する場合の成果物・追加費用・期間を契約前に決めておくと、技術検証が無駄になりにくいです。

RFPと要件整理を行って見積の前提をそろえる方法

見積を比較できない最大の理由は、開発会社ごとに想定する画面数、ユーザー数、連携範囲、テスト範囲が違うことです。発注側がすべての仕様を完成させる必要はありませんが、目的、対象業務、優先順位、制約、受け入れ条件をRFPにまとめ、同じ条件で提案を受けます。

RFPの冒頭には、なぜ今発注するのかを記載します。たとえば、二重入力を減らして月次集計を短縮したい、部門をまたぐ承認状況を可視化したい、既存画面の保守切れに備えて段階移行したいなど、経営目的と現場課題を分けて書きます。Litの採用自体を目的にせず、導入後に測る業務指標を決めます。

対象範囲には、利用部門、利用者数、画面数、対象データ、権限区分、既存システム、外部API、帳票、通知、バッチ、データ移行、教育、保守を含めます。初回リリースに含めない範囲も明記します。「将来対応」と書くだけでは各社の解釈が分かれるため、今回の契約外であることと、将来追加する場合の見積方法まで確認します。

機能一覧だけでは、Litの画面部品と業務APIが正しく連携できるか判断できません。ログイン、検索、登録、承認、差し戻し、取消、再処理、CSV出力、権限エラー、通信失敗、二重送信などを業務シナリオにします。各シナリオに、利用者、前提データ、操作手順、期待結果、監査ログの要否を添えます。

特に、LitのコンポーネントAPIとイベント仕様はRFPの評価対象に含めます。プロパティと属性をどのように使い分けるか、イベント名やpayloadをどう型定義するか、親子コンポーネント間の状態をどこで管理するかを提案してもらいます。これらを決めずに画面を量産すると、見た目が似ていても利用方法が異なる部品が増え、再利用の効果が下がります。

非機能要件には、同時利用者数、画面応答時間、稼働時間、バックアップ、復旧目標、対応ブラウザ、スマートフォン対応、ログ保存期間、個人情報の取り扱い、アクセシビリティ、脆弱性診断、障害時の連絡方法を記載します。Lit公式が案内する現代ブラウザ要件と自社の利用環境が合わない場合は、ポリフィルやビルド設定の費用が発生する可能性も確認します。

納品物は、ソースコードだけでは不十分です。画面仕様書、API仕様書、コンポーネントカタログ、デザイン・トークン、イベント仕様、テスト仕様書、テスト結果、依存パッケージ一覧、脆弱性対応方針、インフラ構成、運用手順、データ移行手順、教育資料を含めます。将来の内製化や別会社への引き継ぎを考えるなら、コードリポジトリと設計資料を発注側が利用できる権利も確認します。

Litのシステム開発を発注してから稼働するまでの進め方

発注後は、要件定義、設計、開発、テスト、移行、パイロット稼働、全体展開、保守の順に進めます。各工程の終了条件と発注側のレビュー担当を決め、技術チームだけでなく業務担当者が受け入れ判断に参加できる体制を作ります。

要件定義では、現場のExcel、紙、メール、既存画面を確認し、業務フロー、マスタ、権限、例外処理、連携データを整理します。そのうえで、どの機能をWeb Componentとして共通化し、どの機能を画面固有のロジックとして残すかを決めます。共通化しすぎると使いにくい部品になり、共通化しなさすぎると重複開発になるため、利用シナリオと保守単位で判断します。

設計レビューでは、業務画面のワイヤーフレームだけでなく、コンポーネントの入力値、出力イベント、エラー状態、ローディング状態、空データ状態、権限不足状態を確認します。Lit公式が説明するリアクティブ更新は、プロパティ変更を契機に非同期でDOMを更新する仕組みです（出典: Lit公式「Lifecycle」、2026年8月確認）。状態変化を画面ごとに独自実装せず、設計書に共通ルールを残します。

テストでは、コンポーネント単体、画面結合、API連携、権限、業務シナリオ、データ移行、性能、セキュリティ、ブラウザ互換性を分けて確認します。Shadow DOMの内部要素を直接参照するテストは壊れやすいため、利用者の操作や公開イベントを中心にE2Eテストを設計し、必要な内部検証はコンポーネントのテストで分担します。

リリースは、いきなり全社展開せず、1部門または1業務でパイロットを行います。検索、登録、承認だけでなく、通信失敗、セッション切れ、権限変更、二重送信、データ不整合、障害時の手動運用まで確認します。KPIには処理時間、入力ミス、問い合わせ件数、承認滞留、旧画面との二重入力件数などを設定し、導入後の改善判断につなげます。

稼働前には、デプロイ、ロールバック、障害切り分け、ログ確認、依存パッケージ更新、脆弱性対応、アカウント管理、バックアップ復元の手順を整備します。Litの部品が動くことだけでなく、ビルド環境やnpm依存が再現できることも確認します。更新を止めるとセキュリティとブラウザ互換性のリスクが高まるため、担当者とレビュー周期を決めます。

保守会社へ継続委託する場合も、発注側が業務判断をできるように、コンポーネントカタログ、API仕様、データ辞書、既知の制約、障害履歴、問い合わせ分類を引き継ぎます。別会社へ移行する可能性があるなら、リポジトリ、クラウドアカウント、ドメイン、証明書、監視、ログ、データ出力の所有者を契約書で確認します。

Litのシステム発注で契約形態を使い分けるポイント

契約形態は、成果物と受入条件がどこまで確定しているかで選びます。要件を調査しながら進める工程と、完成した画面・機能を納品する工程では、適した契約とリスク分担が異なります。契約名だけで判断せず、作業範囲、指揮命令、検収、変更管理、責任分界を具体化します。

現状分析、要件定義、技術調査、PoC、アジャイル開発のように、作業を進めながら内容を確定する工程では、準委任契約が候補になります。稼働時間、担当者の役割、レビュー方法、進捗報告、会議体、成果物の扱いを契約書に記載します。成果物が提出される場合でも、完成保証や検収の扱いを曖昧にしないことが重要です。

準委任だから品質責任がないという意味ではありません。設計レビュー、コードレビュー、テスト実施、課題管理、報告期限など、プロジェクト運営上の品質基準を合意します。月単位の稼働契約にする場合は、予定時間を超える作業の承認方法と、未消化時間の扱いも確認します。

画面仕様、API、テスト条件、納期、検収基準が確定し、完成した機能を納品する工程では、請負契約が検討対象になります。請負契約では、何を完成とみなすかを受入条件に落とし込みます。たとえば、指定したブラウザで検索・登録・承認が動くこと、権限ごとの表示が期待結果と一致すること、テスト仕様書と結果が納品されることなどです。

請負契約でも、仕様変更や前提条件の変化が自動的に無償になるわけではありません。追加画面、外部APIの仕様変更、移行データの不備、対象ブラウザの追加などが起きた場合の変更申請、影響評価、承認、再見積の手順を定めます。検収後の不具合対応期間、再委託、知的財産、OSSライセンス、契約終了時の引き継ぎも合わせて確認します。

保守契約には、障害対応、問い合わせ、監視、バックアップ、ブラウザ更新、依存パッケージ更新、脆弱性対応、軽微な改善、データ修正、利用者追加を分けて記載します。受付時間、一次回答、復旧目標、休日対応、重大度の定義、月の作業時間、追加作業単価が必要です。画面の軽微な修正と、新しい業務ロジックを追加する開発は、同じ保守費に含めない場合が多いです。

年間保守費は、リサーチノートで整理した一般的な目安として初期開発費の10〜20％程度を仮置きできますが、Lit専用の公定価格ではありません。24時間監視、個人情報を扱う高い可用性、複数環境、頻繁な改善、旧ブラウザ対応を含む場合は、別の見積になります。見積の根拠と含まれない作業を必ず確認します。

Litのシステム開発の費用相場と見積内訳

Litのライブラリ自体はオープンソースであり、製品ライセンス料を基準にした価格表はありません。費用の中心は、要件定義、画面設計、共通コンポーネント、業務ロジック、API、データベース、認証、データ移行、テスト、クラウド、教育、保守です。金額は画面数だけでなく、業務の複雑さと連携・品質要件で大きく変わります。

Litの共通コンポーネントや1画面を作り、既存APIへ接続するPoCは、リサーチノートで整理した類似フロントエンド検証の推定として100万〜300万円程度を仮置きできます。画面数が少なくても、認証、実データ、権限、テスト、デザインシステム、対応ブラウザを含めるほど増えます。この金額はLit専用の公開価格ではなく、画面範囲と検証条件を明記したうえで使う目安です。

PoCの見積には、成果物としてソースコード、コンポーネント仕様、実装方針、検証結果、残課題を含めます。本番へ進まない場合でも、他社や社内チームが検証結果を利用できる形にしておくと、調査費用を次の意思決定へつなげられます。

検索・登録・一覧・権限管理を備えた小規模な社内業務画面は、リサーチノートで整理した類似Webアプリの推定として300万〜800万円程度が一つの目安です。SIA株式会社の2026年公開相場では、簡易な業務管理ツールや社内向け単機能システムが100万〜300万円、中規模の部門横断業務システムが500万〜1,000万円、大規模システムが1,000万円〜数千万円以上とされています（出典: SIA株式会社「システム開発の費用・相場 2026年版」、2026年7月）。

Lit案件で小規模の下限に近づくのは、既存API、認証、クラウド、デザイン、マスタが整い、画面とテスト範囲が絞られている場合です。業務ルールの新規設計、複雑な承認、基幹連携、帳票、移行、アクセシビリティ試験、複数ブラウザ対応を含めると、中規模のレンジへ近づきます。価格だけでなく、何を含む見積かを確認します。

複数部門のCRM、案件、在庫、受発注を統合し、会計・ERP・人事・外部サービスと連携する場合は、1,000万円以上から数千万円、要件によっては数億円規模になる可能性があります。データ移行、拠点展開、監査ログ、可用性、性能、災害対策、教育、24時間運用が加わるためです。Litを使うだけでこの総額が一律に下がるとは考えず、共通部品の再利用による重複削減を個別に見積もります。

公開相場の人月単価は、SIA株式会社の同じ記事で60万〜200万円程度とされています（出典: SIA株式会社「システム開発の費用・相場 2026年版」、2026年7月）。実際の単価は、担当者の専門性、地域、契約、納期、セキュリティ水準で変わります。見積書では単価だけでなく、役割別の工数、レビュー、管理、テスト、移行、保守の費用を分けて確認します。

Litのシステム委託先選定と見積比較のポイント

委託先は、Litという単語をWebサイトに掲載しているかだけで決めません。Web Components、TypeScript、API・認証、業務要件定義、テスト、アクセシビリティ、運用移管を一つのプロジェクトで扱えるかを確認します。Lit専業会社の公開情報が少ない場合は、実案件の担当者やコードサンプルを確認し、公開実績と提案上の対応可能性を分けて評価します。

候補会社には、Web Componentsの実装例、ReactやVueとの共存例、Shadow DOMを含むE2Eテスト、TypeScriptの型定義、Storybookなどのカタログ運用、アクセシビリティ試験の方法を質問します。Litの採用実績が公開されていなくても、標準技術の理解と実装を証拠で確認できれば候補にできます。逆に、Litという名称だけで業務システムや保守まで任せられるとは限りません。

担当営業だけでなく、要件定義、フロントエンド、バックエンド、インフラ、QA、保守の責任者に会えるかも確認します。提案時に、検索・登録・権限エラー・通信失敗を含む小さなPoCを依頼し、説明した技術が実装とテストに反映されるかを確認すると、書面だけでは分からない差が見えます。

複数社へ同じRFPを渡し、要件定義、UI設計、共通コンポーネント、画面実装、API、認証、データ移行、テスト、インフラ、教育、保守を分けた見積を依頼します。「Litシステム開発一式」だけでは比較できません。画面数、コンポーネント数、利用者数、既存APIの有無、データ件数、対象ブラウザ、環境数、テスト範囲を前提欄に書いてもらいます。

比較表では、必須要件の対応可否、希望要件を削った場合の減額、追加した場合の単価、納期短縮の影響、再委託費、クラウド費、保守費、データ出力・解約費用を並べます。A社が既存APIを利用し、B社がAPIから新規開発するなら、金額の差は技術力ではなく前提差かもしれません。安い理由と高い理由を説明できる会社を評価します。

従業員情報、顧客情報、案件情報を扱う場合は、画面の見た目よりも認証、認可、通信、ログ、バックアップ、委託先管理が重要です。個人情報保護委員会の通則編ガイドラインは、委託先の選定時に安全管理措置を確認し、委託先に必要な監督を行う考え方を示しています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン 通則編」、2026年8月確認）。RFPには、再委託、保管場所、アクセス権、事故報告、削除・返却、監査協力を記載します。

Litやnpm依存パッケージについては、ライセンス一覧、脆弱性検知、更新、影響調査、緊急パッチの手順を確認します。Shadow DOMはDOMとスタイルを隔離する仕組みですが、認証やデータ秘匿の境界ではありません。アクセストークンや秘密鍵をブラウザへ埋め込まず、API側で認証認可を行い、CSP、XSS対策、未検証HTMLの挿入制限、監査ログを設計します。

アクセシビリティは、業務システムでも発注条件に含めます。W3CのWCAG 2.2は2024年12月にRecommendationとして公開され、キーボード操作、フォーカス、フォームの名前・役割・値などを検証可能な基準として整理しています（出典: W3C「Web Content Accessibility Guidelines 2.2」、2024年12月公開・2026年8月確認）。自作のCustom Elementは、スクリーンリーダー、フォーカス移動、エラー通知、ズーム、コントラストを実機で確認します。

Litのシステム発注・外注でよくある質問

Litの発注では、技術の採用可否だけでなく、業務範囲、既存資産、開発体制、費用の前提をそろえることが大切です。ここでは、相談前によく寄せられる質問に直接回答します。

Litの掲載実績だけでなく、Web Components、TypeScript、Shadow DOM、API、認証、業務要件定義、テスト、保守の実績を確認します。問い合わせ時は、実案件の担当範囲、コードサンプル、ReactやVueとの共存方法、アクセシビリティ試験、納品物、脆弱性対応を質問し、必要なら小規模PoCで評価します。

既存APIに接続するPoCは100万〜300万円程度、小規模な業務画面は300万〜800万円程度、中規模の部門横断システムは500万〜1,000万円程度が検討時のレンジです。基幹連携、データ移行、複数拠点、厳格なセキュリティ、全社展開を含む場合は1,000万円以上から数千万円規模になる可能性があります。いずれもLit専用の確定価格ではなく、画面数、利用者数、既存API、認証、テスト、移行の前提で変動します。

発注できますが、共存方式をPoCで検証します。ReactやVueの画面にLitの部品を配置する場合は、属性・プロパティ・イベントの受け渡し、フォーム、状態管理、ルーティング、スタイル、E2Eテストの境界を設計します。既存システムの全面刷新ではなく、共通入力部品や特定業務から段階移行する計画にすると、リスクと費用を抑えやすくなります。

Lit自体はオープンソースのため、ライブラリの利用料だけで業務システムが完成するわけではありません。業務要件、画面設計、API、データベース、認証認可、テスト、クラウド、移行、教育、保守に費用がかかります。依存パッケージのライセンス確認、脆弱性監査、更新担当、障害対応も発注範囲に含めて見積を依頼します。

業務の目的、現状の課題、対象部門、利用者数、業務フロー、画面一覧、既存システム、連携先、データ件数、権限、希望時期、予算の上限、必須要件と希望要件を準備します。完成した仕様書がなくても、現場の画面やExcel、帳票、例外処理を見せられると要件整理が進みます。最終的にはRFPの作成自体を要件定義会社へ依頼する方法もあります。

まとめ

Litのシステムを発注・外注するときは、Litを業務システム全体ではなく、Web Componentsを共通化する画面基盤として扱います。SaaS・パッケージ、既存システムとの連携、スクラッチ開発を業務要件で比較し、必要なら1画面のPoCでReactやVueとの共存、API連携、テスト、アクセシビリティを検証します。

RFPには、目的、業務範囲、通常・例外シナリオ、利用者、権限、連携、非機能要件、納品物、保守範囲を記載します。見積は要件定義、共通部品、画面、API、認証、移行、テスト、教育、クラウド、保守に分け、含まれない作業と追加時の単価も比較します。契約は準委任と請負を工程ごとに使い分け、検収、変更管理、データ、OSS、知的財産、引き継ぎを明確にします。

委託先は、Litの名称だけでなく、Web Components、TypeScript、業務要件、API、認証、テスト、セキュリティ、アクセシビリティ、保守移管の証拠で選びます。費用相場は、PoCで100万〜300万円程度、小規模業務画面で300万〜800万円程度、中規模以上で500万〜1,000万円から、基幹連携では1,000万円以上という公開相場と推定レンジを起点にし、案件の前提を加えて見積もります。

▼全体ガイドの記事
・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を創業。