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

Stencilのシステム開発を発注するなら、StencilJSを使った共通UI・デザインシステム基盤として範囲を定義し、段階的な外注と運用まで含めて見積もることが重要です。

「Stencilのシステム」と検索している方のなかには、StencilJSで業務システム全体を構築したい方、ReactやAngularなどが混在する社内アプリの画面部品を統一したい方、既存画面を止めずに段階移行したい方がいます。Stencilは業務データを保存するERPやバックエンド製品そのものではなく、TypeScript・JSX・CSSから標準仕様のWeb Componentsを生成し、複数のフレームワークへ配布しやすくするコンパイラです。この記事では、発注形態の選び方、RFPと要件整理、契約形態、2026年時点の費用レンジ、委託先と見積書の比較方法まで、発注担当者が社内稟議とベンダー選定に使える形で解説します。

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

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

発注の成否は、技術名を指定できるかよりも、何を共通化し、どのアプリへ、どの品質で届けるかを合意できるかで決まります。StencilJSの導入費だけを見ると無料に見えますが、実際には画面の棚卸し、デザイン設計、コンポーネント実装、配布、テスト、移行、教育、保守が費用になります。

Stencil公式ドキュメントでは、StencilはWeb Components、より正確にはCustom Elementsを生成するコンパイラと説明されています。TypeScript、JSX、CSSを使ってボタン、入力フォーム、テーブル、モーダル、ナビゲーションなどを部品化し、React、Angular、Vue、フレームワークを使わないHTMLからも呼び出せます。Output Targetによって各フレームワーク向けのラッパーを生成する方法も用意されています（出典：Stencil公式「Introduction」、2026年閲覧）。

そのため、RFPには「Stencilで業務システムを開発する」とだけ書かず、「既存のReactアプリとAngularアプリで共通利用するUIコンポーネントを、private npmレジストリから配布する」のように記載します。バックエンド、API、認証、データベース、業務ロジックまで対象にする場合は、Stencilとは別の開発範囲として分ける必要があります。

外注に向くのは、ReactとAngularなど複数フレームワークが混在している場合、全社で使うデザインシステムを短期間で立ち上げたい場合、Shadow DOMやアクセシビリティの知見が社内に不足している場合です。特に、部品のAPI設計と破壊的変更のルールは、画面を一つ作る作業とは異なるため、経験のある会社に初期設計を依頼する価値があります。

一方、数個のボタンやカードを一つの小規模画面で使うだけなら、Stencilの配布基盤やガバナンスを整える工数が割高になる場合があります。まずReactやVueの標準コンポーネントで足りるのか、Litなど別のWeb Components基盤が適するのかを比較し、Stencilを採用する理由を「複数製品への再利用」「段階移行」「ブランド横断の統一」のいずれかで説明できる状態にします。

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

発注形態は、作業を誰に任せるかだけでなく、要件の不確実さ、社内に残したい知識、納期、運用責任を基準に選びます。Stencil案件では、最初から全工程を一括請負にするより、要件整理やPoCで不確実さを減らしてから本開発へ進む方式が合いやすいです。

請負契約は、合意した成果物を完成させることを委託し、納品や検収を基準に進める発注形態です。コンポーネント数、対応ブラウザ、Storybookなどのドキュメント、テスト項目、npmパッケージの納品といった範囲を明確にできる場合は、社内で予算を立てやすくなります。

ただし、画面を調査してみないと共通部品の数が分からない段階で固定価格だけを求めると、見積条件から外れた追加費用が発生しやすくなります。全社デザインシステムの初期構想や既存画面の棚卸しは、準委任の調査・設計フェーズとし、仕様が定まった実装フェーズから請負に切り替える方法も現実的です。

準委任契約は、一定期間の専門作業やプロジェクト支援を依頼する形態です。Stencilの設計方針、コンポーネントAPI、テスト戦略、既存アプリへの組み込み方を共同で検討する場合に向いています。要件が変わるたびに請負範囲を変更する必要が少なく、社内担当者がレビューと意思決定に参加しやすい点が利点です。

ラボ型やチーム型の外注では、フロントエンドエンジニアだけでなく、デザイナー、QA、テックリード、プロジェクトマネージャーを必要な期間だけ組み合わせます。月ごとの稼働時間、担当者の経験、成果物の扱い、途中解約、引き継ぎ条件を契約書に記載しないと、単価比較だけでは実態が分かりにくくなります。

Stencilを初めて使う企業では、5〜10部品を一つのReactまたはAngular画面に組み込み、実際の入力操作、イベント連携、スタイル分離、読み込み性能、アクセシビリティを確認するPoCから始める方法があります。PoCの目的は完成品を作ることではなく、共通化の単位と開発・運用の課題を明らかにすることです。

PoCの受け入れ条件を満たした後に、15〜40部品のライブラリ、2〜3アプリへの展開、CI/CD、ドキュメント、移行支援を本開発として発注します。この二段階なら、Stencilの採用を続けるか、別の基盤へ切り替えるかを早い段階で判断でき、社内稟議でも「小さく検証してから本投資する」という説明ができます。

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

RFPは技術名を並べる文書ではなく、発注先が同じ前提で提案と見積を作るための文書です。Stencil案件では、現在の画面と将来の共通化範囲、利用するフレームワーク、デザインと業務の責任分界、リリース後の運用まで書くと、各社の提案を比較しやすくなります。

最初に、なぜStencilを検討するのかを記載します。たとえば、ReactとAngularの画面で同じボタンの挙動が異なる、ブランドごとに色や余白が分かれている、アクセシビリティ修正が各チームで重複している、レガシー画面を一度に置き換えられない、といった課題です。

成果指標は、コンポーネント数だけにしません。共通部品を採用した画面数、画面ごとの重複実装の削減、キーボード操作やコントラストの適合状況、リリースまでのレビュー時間、既存アプリを止めずに移行できた範囲などを設定します。目標値が難しい場合も、測定方法と基準日をRFPに残しておくと、納品後の評価ができます。

技術要件には、Stencilのバージョン、Node.jsの実行環境、TypeScriptの方針、Shadow DOMの利用、SSRまたはプリレンダリングの要否、React・Angular・Vueへの接続方式を含めます。さらに、対応ブラウザとスマートフォン、通信が不安定な環境、読み込み性能、エラー時の表示、キーボード操作、スクリーンリーダー、コントラストなどの非機能要件も必要です。

配布方式も曖昧にしません。private npmレジストリを使うのか、オンプレミスのレジストリにするのか、GitHub ActionsなどのCIで自動公開するのか、利用チームがどのバージョンを採用するのかを決めます。依存パッケージの脆弱性監視、SBOM、秘密情報の管理、監査ログ、ロールバック手順まで含めると、開発会社が実装後の運用費を見積もれます。

納品物は、ソースコードだけでは不十分です。コンポーネント仕様書、Props・Events・Slotsの定義、デザイントークン、Figmaとの対応表、Storybookまたは自動生成ドキュメント、単体・E2E・視覚回帰・アクセシビリティテスト、CI/CD設定、CHANGELOG、移行手順、運用マニュアル、脆弱性対応手順を一覧にします。

発注者側の役割もRFPに入れます。業務部門は入力項目と優先順位を決め、デザイン責任者はブランドとアクセシビリティの判断を行い、情報システム部門はレジストリ、認証、CI、セキュリティの制約を提示します。意思決定者が不明なまま外注すると、部品の見た目は完成しても、各プロダクトチームが採用しない状態になりやすいです。

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

契約形態は、見積金額の大小だけでなく、要件変更の扱い、検収の基準、損害が起きた場合の責任、知的財産権、保守の範囲に影響します。経済産業省の「情報システム・モデル取引・契約書」でも、要件定義支援と開発では作業の性質や契約の考え方が異なるため、工程ごとの責任分担を整理することが示されています。

請負契約で特に重要なのは、何をもって完成とするかです。「ボタンを10種類作る」だけでなく、キーボードで操作できること、定めたブラウザで表示が崩れないこと、イベントがReactとAngularの双方で受け取れること、テスト結果を提出することまで検収条件に落とし込みます。

後から新しい画面やコンポーネントを追加する場合の変更管理も必要です。追加見積の単位、承認者、納期への影響、既存部品との互換性、メジャーバージョンを上げる条件を定めます。Stencilのような共有基盤では、一つの変更が複数チームへ影響するため、納品時だけでなくリリース後の変更手順まで契約に含めると安全です。

納品されるコンポーネントのソースコード、デザインデータ、テストコード、CI設定、ドキュメントを誰が保有するかを明記します。Stencil本体はOSSですが、案件で作る独自コンポーネント、デザイントークン、業務画面、社内テンプレートの権利関係は別に確認が必要です。

依存パッケージのライセンス一覧と、公開パッケージを利用できる条件も納品物に含めます。npmに公開するのか、社内限定で配布するのか、退職や契約終了後も自社でビルドできるのかを確認します。CIのアカウント、秘密鍵、レジストリの管理者権限を発注者側へ移管する条件がないと、ベンダー解約後に更新できないリスクがあります。

保守の対象には、Stencilや依存パッケージの更新、脆弱性の調査と修正、主要ブラウザの動作確認、アクセシビリティ不具合、CI/CD障害、利用チームからの問い合わせ、ドキュメント更新を含めます。対応時間、一次回答の期限、重大度ごとの復旧目標、休日対応、対象外の追加開発をSLAに整理します。

Stencil Enterpriseのような開発元の支援を利用する場合は、サポートやアドバイザリー、優先修正、SLAが必要な規模かを確認します。公式のEnterprise支援は公開の一律価格ではなく個別見積と考えられるため、OSSを自社保守する案と、開発元または外部会社へ保守を委託する案を同じ条件で比較することが大切です。

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年）。

見積書では、要件整理、UI棚卸し、デザイントークン設計、コンポーネント設計、実装、各フレームワーク向けの接続、テスト、ドキュメント、移行、教育、プロジェクト管理を工程別に分けてもらいます。単価が安くても、テストや移行が別紙扱いなら、発注後に追加費用が発生して総額が高くなる場合があります。

付帯費用には、クラウドやCI、private npmレジストリ、Figmaの契約、セキュリティ診断、アクセシビリティ試験、データ移行、出張、翻訳などが含まれます。特にバックエンド、API、認証、データ移行はStencilの部品実装とは別のため、含む・含まないを見積書の前提条件で確認します。

運用費は、依存パッケージの更新、脆弱性対応、ブラウザ検証、アクセシビリティの改善、ドキュメント更新、利用チームの問い合わせを含め、初期開発費の年10〜20％程度を暫定予算として置く方法があります。この割合はStencil公式の定価ではなく、リサーチノートで整理した業務システムの保守予算を基にした目安です。実際には、社内担当者の工数と外部保守費を分けて確認します。

初期費用を抑えるために部品数を減らす場合でも、品質を落とすのではなく、最初の対象を絞ります。利用頻度の高いボタン、入力、モーダル、テーブルから始め、共通化の効果が測れる画面へ展開します。保守費を見積から外すと、メジャーアップデートや担当者退職時の引き継ぎに予算がなくなるため、初年度と2年目以降を分けて提示してもらいます。

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

委託先は、Stencilという単語を知っているかだけでなく、Web Componentsを複数アプリへ運用した経験、デザインシステムのガバナンス、業務部門との要件整理、テストと移行の実績で選びます。公開事例が海外向けであっても、StencilJSの実案件なのか、Web Components一般なのか、BigCommerceのStencilなのかを区別して確認します。

候補会社には、StencilJSで作ったコンポーネントの数、利用したフレームワーク、配布方法、テスト方法、導入後の保守体制を質問します。Ionicが公開するVolkswagen Groupの事例では、複数ブランドのUIを標準化するためにStencilを使い、ReactやAngularなど既存の技術スタックへ組み込める点が紹介されています（出典：Ionic「Volkswagen Group Case Study」、2026年閲覧）。このような事例は、単に「使った」ではなく、複数チームで運用する発注の参考になります。

Publicis Sapientの事例のように、Figma、design tokens、ドキュメント、npm配布をつないだ運用経験がある会社なら、実装以外の設計も相談しやすいです。ただし、海外事例の規模をそのまま自社の成果として扱わず、担当した工程、再利用できる成果物、国内でのPMや保守窓口を確認します。

見積比較では、総額の安い順に並べないことが大切です。各社の提案を、要件整理、デザイン、実装、ラッパー生成、アプリ組み込み、テスト、移行、ドキュメント、教育、保守、管理の項目に分け、工数、担当者、期間、成果物、前提条件を同じ表へ転記します。

金額差が大きい項目は、作業を含めるかどうかを確認します。たとえばA社がアクセシビリティ試験を含み、B社が別途見積なら、安いB社を選んだ後で予算が逆転する可能性があります。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で実装する構成が一般的です。

StencilJSはOSSのため、基本的なツール利用料は0円ですが、開発会社への委託費や運用費まで無料にはなりません。PoCなら100万〜300万円程度、15〜40部品と複数アプリへの展開なら500万〜1,500万円程度という推定レンジを起点にし、要件定義、テスト、移行、保守の有無をそろえて見積比較してください。

StencilJSの実案件、複数フレームワークへの接続、デザインシステム、アクセシビリティ、CI/CD、移行、保守の経験を確認します。公開事例の会社名だけで決めず、担当範囲、納品物、国内のPM体制、契約終了後の引き継ぎ、脆弱性対応の役割を質問し、同じRFPで3社以上の提案を比較すると判断しやすくなります。

PoCから始める方法が適しています。5〜10部品を実際のReactやAngular画面に組み込み、イベント、スタイル分離、性能、アクセシビリティ、開発者体験を検証すると、本開発の範囲を現実的に決められます。PoCの成功条件と本開発へ進む判断基準を先に決め、単なる試作で終わらせないことが重要です。

まとめ

Stencilのシステム開発を発注するときは、StencilJSを業務システム全体ではなく、複数のWebアプリへ共通UIを配布する基盤として位置づけます。そのうえで、発注形態、RFP、契約、費用、委託先、保守の責任を分けて考えると、安さだけに引っ張られず、導入後に使われる仕組みを選びやすくなります。

まずReact、Angular、Vueなど既存アプリと、共通化したい部品を棚卸しします。次にPoCまたは要件整理で、部品の責務、デザイントークン、テスト、配布、移行の条件を定めます。最後に、請負・準委任・ハイブリッドのうち、要件の確実さと社内に残したい知識に合う契約形態を選び、3社以上へ同じRFPを提示します。

いきなり全社共通基盤を発注するのではなく、利用頻度が高く差分の少ない5〜10部品と、接続する1画面を決めると、Stencilの適合性と発注先の力量を確認できます。PoCの結果をもとに、500万〜1,500万円程度の小〜中規模ライブラリへ進むのか、既存フレームワークで十分なのかを判断してください。相場はあくまで推定レンジとして扱い、要件・成果物・保守条件をそろえた見積で最終判断することが大切です。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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