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

Stencilのシステム開発は、共通化の範囲と対象アプリを定めたうえで、発注形態を選び、RFPで要件を整理し、契約と費用を確かめてから委託先を決める流れで進みます。この順で決めると、無理のない開発と継続利用につながります。全体像は、Stencilのシステム開発の完全ガイドでも確認できます。

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

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

Stencilのシステムを発注する前に知っておきたい全体像

発注の成否は、Stencilという技術名よりも、何を共通化し、どのアプリに、どの品質で届けるかを発注側と開発会社が合意できるかで決まります。

StencilJS自体は無料で使えても、部品の実装やテスト、移行、保守には費用がかかります。

StencilJSは共通UIを配布する基盤

Stencil公式は、Stencilを、Web Components、より正確にはCustom Elementsを生成するコンパイラと説明しています（出典：Stencil公式「Introduction」、2026年閲覧）。そのため、StencilJSの役割は、共通UIを複数のアプリへ配ることと考えると分かりやすいです。

Stencilが担う範囲は、部品化から配布までと、それ以外の別範囲に分けて考えます。

• 部品化：TypeScript、JSX、CSSで、ボタン、入力フォーム、テーブル、モーダル、ナビなどの部品を作ります。
• 接続：React、Angular、Vue、標準HTMLから利用でき、Output Targetを使えば各フレームワーク向けのラッパーも生成できます。
• RFP：共通部品と配布先を具体化し、React・Angularのアプリへprivate npmレジストリから配布する例のように書きます。
• 別範囲：バックエンド、API、認証、データベース、業務ロジックは、Stencilとは別に設計します。

外注と自社主導の向き不向き

外注にするか自社主導にするかは、共通化の規模と社内の知見を照らし合わせて決めます。

• 外注向き：複数フレームワークの共通化や、全社デザインシステムを短期間で立ち上げたい場合。
• 専門知識：Shadow DOMやアクセシビリティの知見が社内に足りない場合も、外注を考える理由になります。
• 初期設計：部品APIや破壊的変更のルールは画面開発と性質が異なるため、経験のある会社に依頼する価値があります。
• 小規模利用：数個のボタンやカードだけなら、配布基盤やガバナンスの整備が割高になることがあります。
• 採用判断：React・Vueの標準部品やLitとも比べ、再利用、段階移行、ブランド統一の必要性を確かめます。

Stencilのシステム開発で選べる発注形態

発注形態は、要件がどこまで固まっているか、社内にどの知識を残すか、納期はいつか、運用の責任を誰が持つかで選びます。

特にStencil案件では、要件整理やPoCで不確実さを減らしてから本開発へ進む方法が合いやすいです。

一括請負が向く場合

請負契約は、成果物の完成を依頼し、納品と検収を基準に進める形態です。

この形態は、成果物と納期を固められる場合に合います。

• 予算化：部品数、対応ブラウザ、Storybookなどの文書、テスト、npm納品を明確にして、見積の前提をそろえます。
• 注意点：部品数が分からない調査前に固定価格を求めると、条件外の追加費用が生じるおそれがあります。
• 段階発注：構想や画面棚卸しは準委任とし、仕様が決まった後の実装を請負にする方法もあります。

準委任とラボ型：要件変化と知識移管への対応

準委任契約は、一定期間の専門作業やプロジェクト支援を依頼する形態です。

要件が動きやすい案件では、準委任なら変更のたびに請負範囲を組み替えずに済むことが利点になります。

• 共同検討：Stencilの設計方針、部品API、テスト、既存アプリへの組み込みを、委託先と一緒に進める場面に向きます。
• 柔軟性：要件変更ごとに請負範囲を変える必要が少なく、社内担当者もレビューや意思決定に加われます。
• 体制：ラボ型では、エンジニア、デザイナー、QA、テックリード、PMを必要な期間だけ組み合わせます。
• 契約条件：月ごとの稼働時間、経験、成果物、途中解約、引き継ぎを定めます。曖昧なままだと、単価だけで実態を比べにくくなります。

PoCから本開発へ進むハイブリッド発注

Stencilを初めて使う場合は、PoCで適合性を確かめてから本開発へ進みます。

1. 5〜10部品をReactまたはAngularの画面に組み込み、入力操作、イベント、スタイル分離、性能、アクセシビリティを確かめます。
2. 受け入れ条件を満たしたら、15〜40部品、2〜3アプリ、CI/CD、文書、移行支援を本開発として発注します。

PoCは完成品ではなく、共通化の単位と開発・運用の課題を明らかにする工程です。また、二段階にすると、Stencilを続けるか別の基盤へ切り替えるかを早く判断できます。社内稟議でも、小さく検証してから投資する方針を説明できます。

RFPと要件整理で決めるべき項目

RFPは、発注先が同じ前提で提案と見積を作るための文書です。そのため、共通化の範囲、利用フレームワーク、現在の画面を書いておくと、提案を比べやすくなります。さらに、デザインと業務の責任分担やリリース後の運用も書いておくと、提案を比べやすくなります。

背景と成果指標の書き方

Stencilを検討する業務上の課題と、導入後に測る成果は、分けて書いておきます。

• 背景：画面ごとにボタンの挙動が違う、ブランド間で色や余白が異なる、修正が重複する。
• 移行課題：レガシー画面を一度に置き換えられないことも、検討理由に含めます。
• 成果指標：採用画面数、重複実装の削減、操作やコントラストの適合、レビュー時間を測ります。
• 移行成果：既存アプリを止めずに移行できた範囲も、指標として使えます。

目標値を置きにくい場合でも、測定方法と基準日をRFPに残しておくと、納品後に評価できます。

技術要件：利用環境と品質条件まで

技術要件は、開発環境や利用先、品質、配布と運用まで指定します。指定の範囲が狭いと、開発会社は前提を推測したうえで見積を組むことになります。

• 開発環境：Stencilの版、Node.js、TypeScript、Shadow DOM、SSRやプリレンダリングの要否。
• 利用環境：React・Angular・Vueとの接続、対応ブラウザ・スマートフォン、通信が不安定な環境。
• 品質：読み込み性能、エラー表示、キーボード操作、スクリーンリーダー、コントラスト。
• 配布：private npmかオンプレミスか、CI自動公開の有無、利用チームが採用する版。
• 運用：脆弱性監視、SBOM、秘密情報、監査ログ、ロールバック手順。

配布と運用の条件が明確であれば、開発会社は実装後の運用費を見積もれます。

納品物と発注者側の役割

ソースコード以外の納品物と、発注者側の担当部門や判断の範囲も、あらかじめ書いておきます。

• 仕様：部品仕様書、Props・Events・Slots、デザイントークン、Figma対応表。
• 品質・配布：Storybookまたは自動生成文書、単体・E2E・視覚回帰・アクセシビリティテスト、CI/CD設定。
• 運用：CHANGELOG、移行手順、運用マニュアル、脆弱性対応手順。
• 発注者の役割：業務部門は入力と優先順位、デザイン責任者はブランドとアクセシビリティを判断します。
• 情報システム：レジストリ、認証、CI、セキュリティの制約を提示します。

意思決定者が決まっていないと、完成した部品が各プロダクトチームに採用されないこともあります。

Stencilの発注・外注で確認する契約形態

契約形態は金額だけでなく、要件変更や検収、損害時の責任にも影響します。経済産業省の「情報システム・モデル取引・契約書」も、要件定義支援と開発とでは作業の性質や契約の考え方が異なると示しています。そのため、工程ごとに責任分担を整理する考え方です。

請負の検収条件と変更管理

請負では、完成条件と、納品後に共有基盤を変更する手順を契約で決めておく必要があります。

• 検収：部品数だけでなく、キーボード操作、指定ブラウザでの表示、React・Angular双方のイベント受信、テスト結果を定めます。
• 変更管理：追加見積の単位、承認者、納期への影響、既存部品との互換性を、事前に取り決めます。
• 版の更新：メジャーバージョンを上げる条件を先に定めます。変更は複数チームに影響します。

ソースコード・ライセンス・知的財産権

案件で作る資産と、利用するパッケージのそれぞれについて、権利、配布、引き継ぎの条件を確かめます。

• 保有者：ソース、デザイン、テスト、CI設定、文書の保有者を明記します。
• 権利範囲：Stencil本体はOSSです。独自部品、トークン、業務画面、社内テンプレートは別に確認します。
• ライセンス：依存パッケージの一覧と、公開パッケージの利用条件を納品物に含めます。
• 継続運用：npm公開か社内限定か、自社ビルドの可否、CI・秘密鍵・レジストリ権限の移管を定めます。

権限の移管条件を決めていないと、委託先との契約を解約した後に、パッケージを更新できないリスクがあります。

保守契約の対象：脆弱性・ブラウザ・破壊的変更

保守契約では、対応対象とサービス水準を定めます。あわせて、OSSを自社で運用する案とも比べます。

• 保守対象：Stencilと依存パッケージの更新、脆弱性の調査と修正、主要ブラウザの確認。
• 問い合わせ等：アクセシビリティ不具合、CI/CD障害、利用チームの問い合わせ、文書更新。
• SLA：対応時間、一次回答期限、重大度別の復旧目標、休日対応、追加開発の対象外範囲。
• 開発元支援：Stencil Enterpriseも選択肢です。
• 費用比較：OSSの自社保守と外部委託を、同じ条件で比べます。

必要な規模であれば、サポート、アドバイザリー、優先修正、SLAの内容を確かめます。Enterprise支援は、公開の一律価格ではなく、個別見積になると考えられます。

Stencilのシステム開発費用と2026年の相場

StencilJSはOSSのため、基本的なツール利用料は0円です。ただし、無料で使えることと、業務で継続して使えることは別の話です。

費用は、部品数や対象アプリとフレームワーク、デザインや業務ルールの複雑さによって変わります。品質試験、移行、運用体制も費用を左右します。

規模別の費用レンジ

この金額は、Stencil固有の公式価格表ではありません。リサーチノートで整理した2026年時点の、一般的なWebシステムとデザインシステム開発の公開相場と作業範囲を対応させた推定です。

要件や体制、アプリの状態、国内外の委託先によって金額は変わります。そのため、予算の仮説として扱い、最低3社から同じ条件で見積を取ります。

• PoC：5〜10部品を1アプリへ接続する技術検証は、100万〜300万円程度。
• 小〜中規模：15〜40部品を2〜3アプリへ導入し、トークン・文書・CI・移行支援を含めて500万〜1,500万円程度。
• 共通基盤：40〜100部品を複数チーム・複数フレームワークへ配布し、1,500万〜4,000万円程度。
• 大規模：多ブランド、レガシー刷新、複数製品の段階移行、全社教育、長期保守を含み、3,000万〜8,000万円超のケースもあります。

この金額は、Stencilだけで業務システム全体を作る価格ではありません。共通UI基盤と既存業務アプリへの統合を含めた、予算の仮説です。

2026年の開発費用解説は、人月単価、工数、付帯費用を分け、工程ごとに見る考え方を示しています（出典：イー・ジーシステム「システム開発の費用相場と見積書の読み方」、2026年）。

見積の内訳：人件費・工数・付帯費用

見積書は、開発工程と付帯費用が分けて書かれているかを見ます。そのうえで、どこまでが含まれるかを前提条件で確かめます。

• 開発工程：要件整理、画面棚卸し、トークン・部品設計、実装、接続、テスト。
• 関連作業：文書、移行、教育、プロジェクト管理。テストや移行が別なら、追加費用が出る場合があります。
• 付帯費用：クラウド、CI、private npm、Figma契約、セキュリティ診断、アクセシビリティ試験、出張、翻訳。
• 別範囲：バックエンド、API、認証、データ移行は、Stencil部品の実装とは別の費用になります。

初期開発費の10〜20％程度による運用費の暫定計上

運用費は、初期開発費の年10〜20％程度を暫定予算として置く方法があります。

• 対象：依存更新、脆弱性対応、ブラウザ検証、アクセシビリティ改善、文書、問い合わせ。
• 目安の扱い：この割合はStencil公式価格ではなく、リサーチノートの業務システム保守予算に基づきます。
• 見積：社内担当者の工数と外部保守費を分け、初年度と2年目以降も分けて提示してもらいます。
• 初期範囲：品質は保ち、利用頻度の高いボタン、入力、モーダル、テーブルから対象を絞ります。

効果を測れる画面から展開すると、投資の範囲を段階的に広げられます。保守費を予算から外すと、メジャー更新や退職時の引き継ぎ予算が不足するおそれがあります。

Stencilの委託先選定と見積比較のポイント

委託先は、Stencilの知識だけでなく、Web Componentsを複数アプリで運用した経験や、デザインシステムのガバナンスの経験で選びます。

業務要件の整理、テスト、移行の実績も確かめます。また、海外事例を見るときは、StencilJSの事例かWeb Components一般の事例か、BigCommerceのStencilの事例かを区別します。

公開実績で見る担当範囲

公開実績は、技術名だけでなく、導入後の運用と担当範囲まで見ます。

• 質問事項：StencilJSの部品数、利用フレームワーク、配布・テスト方法、保守体制。
• 参考事例：Volkswagen Groupの複数チーム運用を伴う発注事例が参考になります。

Ionicは、Volkswagen Groupの事例を紹介しています（出典：Ionic「Volkswagen Group Case Study」、2026年閲覧）。同社はStencilで複数ブランドのUIを標準化し、ReactやAngularなどへ組み込んでいます。

こうした事例は、技術を使ったという事実だけでなく、複数チームで運用する発注の進め方の参考にもなります。

Publicis Sapientの事例では、Figma、design tokens、文書、npm配布を連携させています。こうした経験のある会社なら、実装以外の設計についても相談できます。

海外事例の規模は、自社の成果と同じものとは限りません。そのため、複数チーム運用の担当工程、再利用できる成果物、国内PMや保守窓口を確かめます。

見積比較の揃え方：総額・前提・成果物

工程と前提、成果物を同じ項目で照らし合わせてから、総額を比べます。

• 工程：要件整理、デザイン、実装、ラッパー生成、アプリ接続、テスト、移行。
• 条件：文書、教育、保守、管理も含め、工数、担当者、期間、成果物、前提を表にそろえます。
• 差額：アクセシビリティ試験などの含有範囲を確認します。別見積なら総額が逆転する場合があります。

JUASの2026年QCD研究資料も、機能、工程、非機能要件、制約をもとに見積の根拠を示すことの重要性を述べています（出典：日本情報システム・ユーザー協会「システム開発・保守QCDs研究会2025」、2026年公開）。

安すぎる提案の確認点

安い提案を見たときは、単価だけで判断せず、作業範囲と責任の抜けを確かめます。

• 作業範囲：設計・品質試験、既存画面への組み込み、文書、引き継ぎ、保守の有無。
• セキュリティ：CI秘密情報、npm依存関係、GitHub Actions、公開パッケージ、権限、監査ログ、脆弱性対応の担当。
• 委託先管理：IPAのサプライチェーン対策などを参照し、個人情報を扱う場合は、委託先管理と事故時の報告経路をRFP・契約書に記載します。
• アクセシビリティ：公共・大企業向け画面ではWCAG 2.2やJIS X 8341-3を意識し、操作、フォーカス、コントラスト、スクリーンリーダーを試験します。

個人情報保護委員会のガイドラインも参照します。Stencilが標準仕様に沿っていても、部品のラベルやエラー表示まで適切だとは限りません。そのため、技術の選定と品質の評価は分けて考えます。

よくある質問

発注時は、技術を採用してよいかだけでなく、費用、期間、外注後の運用まで含めて判断します。

Stencilだけで業務システム全体を開発できますか？

Stencilは、Web Componentsを作るフロントエンド基盤です。業務システム全体のバックエンドやデータベースまでは含みません。一般的な構成は、API、認証、データベース、業務ロジックを別に設計し、画面の共通UIをStencilで実装する形です。

Stencilのシステム開発は無料で発注できますか？

StencilJSはOSSのため基本的なツール利用料は0円ですが、委託費や運用費は無料になりません。PoCは100万〜300万円程度、15〜40部品を複数アプリへ展開する場合は500万〜1,500万円程度が推定レンジです。

要件定義、テスト、移行、保守の有無をそろえたうえで、見積を比べます。

StencilJSの外注先は何を基準に選べばよいですか？

StencilJSの実案件、複数フレームワークへの接続、デザインシステム、アクセシビリティ、CI/CD、移行、保守の経験を見ます。公開事例の会社名だけで判断せず、担当範囲、納品物、国内PM、契約終了後の引き継ぎ、脆弱性対応の役割を質問します。

同じRFPで3社以上の提案を比べると、判断しやすくなります。

最初から全社導入せずPoCから始めてもよいですか？

PoCから始める方法もあります。5〜10部品をReactまたはAngularの画面に組み込み、開発者体験も検証します。イベント、スタイル分離、性能、アクセシビリティを確かめると、本開発の範囲を現実的に決められます。

成功条件と本開発への判断基準を先に決め、試作だけで終わらせないことが大切です。

まとめ

StencilJSは、業務システム全体ではなく、複数のWebアプリへ共通UIを配布する基盤として位置づけます。

発注形態からRFP、契約、保守の責任まで分けて考えると、安さだけに左右されず、導入後も使われる仕組みを選べます。

発注前に確認する順番

対象と契約条件は、順を追って整理すると決めやすくなります。

1. 既存のReact、Angular、Vueなどのアプリと、共通化したい部品を洗い出す。
2. PoCまたは要件整理で、部品の役割、デザイントークン、テスト、配布、移行の条件を決める。
3. 要件の確実さと社内に残す知識に合わせて請負・準委任・ハイブリッドを選び、3社以上へ同じRFPを提示する。

最初の一歩：5〜10部品の検証範囲

全社導入を判断する前に、小規模な検証でStencilと委託先が適合するかを見極めます。

• 検証範囲：利用頻度が高く差分の少ない5〜10部品と、接続する1画面を決めます。
• 次の判断：PoCでStencilの適合性と発注先の力量を確かめ、小〜中規模のライブラリへ進むか検討します。
• 比較：500万〜1,500万円程度の開発か、既存フレームワークで足りるかを比べます。

相場は推定レンジとして扱い、要件、成果物、保守条件をそろえた見積で最終判断します。

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

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