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

Stencilのシステム開発は、要件整理から定着までの6フェーズで進みます。共通化する範囲を先に決め、小さく検証してから段階的に導入します。

そうして進めると、複数のアプリで使えるUI基盤につながります。全体像は完全ガイドもご覧ください。

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

Stencilの役割と全体像

コンポーネントの変換先と対応機能を一覧できます。

Stencil.jsは、TypeScript・JSX・CSSで書いたコンポーネントを、Web Componentsに変換するコンパイラと開発ツール群です。ReactやAngularなど異なるフレームワークから、共通UI部品を呼び出すための基盤でもあります。

Stencil公式ドキュメントでは、Web Componentsを提供するツールと説明されており、Output Targetやprerenderingにも対応します（出典: Stencil公式Introduction、2026年閲覧）。

Stencilが担当する業務システムの範囲

Stencilの担当範囲は、共通UIとアプリケーション側の機能に分けて考えます。

共通UI：ボタン、フォーム、日付選択、テーブル、モーダル、タブ、ナビゲーション、通知、エラー表示
アプリ側の機能：顧客・在庫情報のデータベース、業務ルールを実行するバックエンド、認証基盤、外部サービスとのAPI連携

Stencilを使えば、重複するUI実装やデザイン調整の手戻りを減らせる可能性があります。ただし、既存データとの連携、権限設計、業務フローの見直し、テスト環境の構築は別途必要です。

RFPでは、共通UI基盤の範囲と、各アプリケーション側に残す機能を分けて記載します。

Stencilで共通化できる機能

Stencilの共通化は、UI部品を複数のアプリで使い回すことを中心にします。そのために、設計時に部品の契約を決めておきます。

再利用・読み込み：UI部品の再利用、遅延読み込み、prerendering
CSSの分離：Shadow DOMで、別の部品の表示を壊すリスクを抑える
FW連携：Output Targetやラッパーによる、共通Web Componentsの利用
部品の契約：責務、プロパティ、イベント、slot、キーボード操作、ARIA属性
デザイン連携：FigmaのデザイントークンとCSS変数・テーマの対応付け

共通部品を増やすほど、仕様を守るガバナンスが欠かせなくなるため、表示崩れ時の扱いも契約に含めておきます。

ポイント

Stencilが受け持つのは共通UIで、データベースや認証基盤などのアプリ側の機能は別に設計します。UIの重複は減らせても、既存データとの連携や権限設計は別途必要なので、RFPでは両者の範囲を分けて書きます。

Stencilのシステム開発の進め方と6フェーズ

Stencilの開発は、現状の画面と組織の使い方を整理してから小さく検証すると進めやすくなります。進め方は、要件整理と選定から始めます。その後、設計・開発とテストを経て、稼働と定着へ進み、全体を6フェーズに分けて考えます。

各フェーズに終了条件を決めておくと、PoCが終わらない、部品が採用されない、リリース後に品質問題が出るといった事態を避けられます。

フェーズ1：要件整理と共通化の目的・範囲の設定

Stencilの導入目的は、見た目をそろえるだけでなく、効果を測れる形で決めておきます。関係者は、初期の段階から巻き込みます。

巻き込む相手は、現場担当者とデザイナー、フロントエンド開発者、バックエンド担当です。さらに、情報システム部門と決裁者も加わります。

たとえば、3つの業務アプリで共通部品を使い、改修箇所を9か所から1か所へ減らす目標を置けます。アクセシビリティ試験の共通不備を次期リリースまでに半減する目標や、画面ごとのUIレビュー期間の短縮も、効果として測れます。

要件は、環境・接続・操作・規模の面から書き出します。面ごとに決める内容が違うため、現場担当者やフロントエンド開発者と一緒に確認します。

対象環境：アプリ、フレームワーク、ブラウザ、端末、部品候補、既存デザイン差
接続要件：認証・権限・API、SSR・SEOの要否
操作・開発環境：キーボード・読み上げ基準、社内npm、CI/CD制約
規模と責任者：運用責任者、5〜10部品のPoCか15〜40部品の複数アプリ導入か

規模の違いによって、必要な体制と見積もりも変わります。

フェーズ2：選定とStencilの適合性の比較

選定では、Stencilを使うこと自体を目的にせず、ほかの選択肢と比べて本当に合うかを判断します。比べる相手は、ReactやVueの単一FW向け部品ライブラリ、LitなどのWeb Components基盤、既存のIonic部品です。

比べるときは、導入条件と比較軸をそろえます。そのうえで、Stencilが適する環境かを見極めます。

StencilのOSS利用料は基本的に0円ですが、Enterprise支援の費用は個別見積もりです。そのため、費用は見積もりで比べ、共存や統制、保守の条件も合わせて判断します。

長期共存：複数FWを併用し、レガシー画面を段階的に刷新する
UI統制：複数ブランドで共通UIを管理する
小規模導入：単一画面では配布・版管理・文書運用の負担が効果を上回る場合がある
比較軸：学習・テスト、SSR、FW接続、アクセシビリティ、支援、脆弱性、配布、移行性
保守方法：OSS自社保守と技術相談・優先対応付き支援を同条件で比べる

フェーズ3：設計・開発と部品の契約・運用方法の整備

設計では、見た目より先に部品の契約と運用方法を決めておきます。部品を複数のアプリで使い回すには、呼び出し方や変更時の扱いが先に定まっている必要があります。

部品API：責務、プロパティの型・初期値、イベント名、slotの構造
状態と操作：エラー、ローディング、レスポンシブ、フォーカス、ARIA、破壊的変更
デザイン基準：FigmaトークンとCSS変数の命名、デザイン・実装・文書の正本
試作対象：頻繁に使い差分が少なく測定しやすい5〜10部品を1アプリへ
配布準備：private npm、版管理、CHANGELOG、GitHub ActionsなどのCI

配布と更新の流れまで確認するには、StorybookまたはStencilのドキュメント機能も用意します。

実際に利用するReact・Angular・Vueの環境では、Output Targetやラッパーを検証します。

フェーズ4：テストによる品質と互換性の確認

単体テスト、業務操作のテスト、表示のテストを行い、リリース条件となる品質ゲートを決めます。品質は、部品の仕様から依存関係まで、観点ごとに分けて確かめます。

単体・E2E：プロパティとイベントの境界値、実際の業務操作
表示・フォーム：視覚回帰でテーマとブラウザの差を検出し、正常値、未入力、文字数超過、全角・半角、通信失敗、権限不足を確認する
アクセシビリティ：キーボード操作、読み上げ、社内基準のコントラスト・フォーカス表示
機能・性能：重大な不具合と主要ブラウザの表示崩れを0件にし、既存性能を悪化させない
依存関係：未対応の重大脆弱性を残さない

依存関係の確認は欠かせません。実際に、GitHub Security Labは、StencilリポジトリのCIワークフローに関する脆弱性を開示し、修正しました（出典: GitHub Security Lab、2024年）。採用後も、CIや依存関係の監視を続けます。

フェーズ5：稼働と既存画面への組み込み

稼働時は対象を絞って段階的にリリースします。導入する画面は、利用者の多さや停止の影響から選びます。リリース前の準備と、稼働後に見る指標も決めておきます。

導入画面：利用者が多すぎず、停止影響が限定され、効果を測りやすい1画面
リリース準備：切り戻し、npm固定版、承認者、障害連絡先、ログ確認。互換性のない変更はメジャー更新
稼働指標：採用率、再発件数、UIレビュー・表示・操作時間、アクセシビリティ指摘、失敗率、問い合わせ数
本番前検証：本番相当量のデータで、認証、権限、通信速度、端末差を確かめる

フェーズ6：定着と利用チームの自走体制づくり

利用チームが自走できるように、部品の学習資料や窓口、仕様変更と保守の担当を用意します。導入後も使い続けられるよう、日常運用から継続性、納品記録まで整えておきます。

利用資料：社内ポータル・Storybookの利用例・禁止例、選び方、プロパティ、アクセシビリティ、更新手順
申請・質問：質問窓口、採用申請、仕様変更を決める委員会または担当者
日常運用：部品オーナー、不具合・要望受付、リリース頻度、対象ブラウザ、脆弱性確認周期
継続性：メジャー更新予算、異動時の引き継ぎ、新規部品の判断基準
納品記録：設計書、テスト、CI設定、SBOM、利用規約

仕様を担当者だけが把握している状態を残さないよう、チーム内で引き継げる形にします。

ポイント

判断に迷ったら、各フェーズに終了条件を置き、小さく検証した結果で次へ進むかを決めます。導入の対象は、利用者が多すぎず停止の影響が限られる1画面から選びます。

Stencilのシステム開発費用相場とコストの内訳

規模ごとに想定される予算幅を見比べられます。

StencilはOSSなので、基本的なツールの利用料は0円です。ただし、実際の予算は作業の量で決まります。

作業には、UIの棚卸しやデザインシステムの設計、部品の実装、各アプリへの統合があります。テストやドキュメントに加え、教育と保守も含まれます。

2026年の一般的な開発相場は、小規模100万〜300万円、中規模500万〜1,000万円、大規模1,000万円から数千万円以上という幅です（出典: SIA「システム開発の費用・相場 2026年版」、2026年）。

Stencil案件は、共通UI基盤と既存アプリ統合の手間に応じて考えます。

規模別の費用レンジ

各レンジは、Stencil固有の公式価格ではなく、一般的なWebシステム相場と想定工数から置いた予算仮説です。PoCの費用には、業務アプリ本体のバックエンドやデータ移行を含みません。規模ごとの目安は、部品数や期間、関わるチームの数とあわせて見ると区分の違いが分かります。

技術検証・PoC：100万〜300万円、5〜10部品、1〜2か月程度
小〜中規模ライブラリ：500万〜1,500万円、15〜40部品、2〜3アプリ、3〜6か月程度
業務共通基盤：1,500万〜4,000万円、40〜100部品、複数チーム・複数フレームワーク、6〜12か月程度
エンタープライズ級：3,000万〜8,000万円超、9〜18か月程度の場合

この規模の案件には、多ブランドやレガシー刷新、複数製品の段階移行を含むものがあります。SSO・権限・全社教育まで含むこともあります。

PoCの想定には、要件整理、主要部品の実装、Reactなどへの接続、簡易テストが含まれます。15〜40部品の開発では、UIの棚卸しやデザイントークンの整備も必要です。さらに、Storybookやドキュメント、CIを含め、private npmレジストリや移行支援を加えると、工数はさらに増えます。

エンタープライズ級の費用は、上限を一概には示せません。既存画面数やチーム数、移行対象の量によって大きく変動します。品質基準やセキュリティ要件、外部連携も、費用を動かす要因です。

見積もりは、最低3社へ同じ前提条件で依頼し、金額だけでなく含まれる作業も比べます。

見積もりに含める費用と別枠になりやすい費用

利用チームとの合意形成やレビュー回数も工数に含まれます。そのため、「開発者がコードを書く時間」だけで計算せず、人月単価や作業人月、担当者の役割を見積書で示してもらいます。成果物と検収条件も、あわせて確認します。

見積書では、初期費用、別枠の費用、運用保守の条件を分けて確認します。見積もりに含まれない費用が後から判明しないよう、内訳を分けて比べます。

初期費用：分析・要件整理、設計・デザイン、実装、連携、テスト、文書、CI/CD、移行、教育
別枠費用：バックエンド、API、認証、移行、クラウド、Figma有料版、診断、監視、保守
保守範囲：依存更新、脆弱性、ブラウザ、アクセシビリティ、文書、問い合わせ
予算例：初期開発費の年10〜20％程度を暫定保守費に置く例（出典: Casually「システム開発の料金相場」、2026年閲覧）
契約条件：月額・年額、未使用時間、緊急対応単価、メジャー更新費用

ポイント

実際の予算は作業の量で決まり、PoCは100万〜300万円、15〜40部品の複数アプリ向けは500万〜1,500万円程度が一般的な相場と想定工数からの目安です。

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

見積もり前にそろえる情報の領域を確認できます。

部品数だけでは、見積もりを正確に出せません。同じ20部品でも、1つのReactアプリへ組み込むのか、React・Angular・Vueの3環境へ配布するのかで、作業は異なります。

既存画面も移行する場合は、設計、テスト、ドキュメントの内容も変わります。発注の前に、対象範囲や現在の課題、想定利用者を1枚のRFPにまとめます。既存技術、納品物、運用体制も、同じRFPに書きます。

RFPと要件定義に書く項目

RFPには、対象環境、制約、納品物を記載し、見積もりの前提をそろえます。環境と移行から運用資料まで、項目を分けて書いておきます。

環境と移行：アプリ・FW、Node.js・TypeScript版、ブラウザ、部品候補、画面数、移行順位
技術条件：Output Target、SSR・prerendering、Figma・トークン、npm公開範囲、CI/CD
重要画面：業務上重要な画面や個人情報を扱う画面の停止可能時間、監査ログ、権限、秘密情報、バックアップ、脆弱性対応
開発納品物：仕様書、API・イベント一覧、利用例、Figma対応表、テスト、E2E・視覚回帰、CI/CD
運用資料：リリース手順、CHANGELOG、SBOM、運用マニュアル、教育資料、既知の制約

加えて、著作権とリポジトリの所有権、OSSライセンス、第三者パッケージの更新責任は、見積書と契約書の両方で確認します。

開発会社の比較軸（金額以外）

金額だけでは、含まれる作業や責任の範囲の違いが見えません。そのため、開発会社は次の5つの観点で比べます。

技術経験：Stencil.jsや関連技術の実案件・連携経験
開発・保守：Figma、トークン、アクセシビリティ、private npm、CI/CD、保守体制
担当と検証：事例の条件、設計担当、検証環境、リリース後の対応時間
契約形態：請負・準委任・人材支援の責任と成果物。短期PoCでは増員型も候補
責任と総額：長期運用では自社にも責任者を置くこと、要件から保守までの範囲、除外作業の有無

候補会社には、Web Components全般の経験も尋ねます。あわせて、BigCommerce Stencilとの区別や、React・Angular・Vueへの接続経験も確かめます。

公開事例があっても、自社と同じ規模・業務・契約形態とは限りません。移行や回帰テストが別料金なら、総額が逆転する可能性もあります。

失敗しやすいリスクと対策

利用チームの不採用や過剰な共通化を避けるため、PoCへの参加と判断基準を決めておきます。失敗しやすい場面ごとに、防ぐための手立てを挙げます。

不採用リスク：現場を観察し、採用画面を決め、減らしたい手戻りを数値化
早期検証：代表チームがPoCに参加し、使いにくいAPIや業務例外を確認
例外申請：採用を義務化する場合も、例外の扱いを決めておく
過剰共通化：個別業務の押し込み、プロパティ増加による複雑化やテスト増を避ける
共通化基準：3つ以上のアプリで共通の動作があるか、統制の必要性、変更頻度の低さ

共通化の基準に合わない機能は、個別画面に残す判断も正式な選択肢にします。

ポイント

部品数の多さではなく、移行の有無や納品物の範囲で見積もりは変わります。前提を書き切れたら、同じ条件で複数社に依頼して比べます。

よくある質問（FAQ）

Stencilの開発では、既存画面を止めずに移行できるか、費用をどこまで見込むか、Reactなどと共存できるかがよく問われます。既存業務への影響、保守担当者、契約範囲も含めて判断します。

Stencilで既存のReact・Angular・Vue画面を段階的に移行できますか？

既存画面をすべて止めて作り直す必要はありません。Web Componentsの部品を一部の画面から組み込む段階移行が可能です。

まず、代表的なボタンや入力フォームを1つの業務画面で検証します。表示、イベント、フォーム送信を確認します。さらに、フォーカス、性能、ブラウザ互換性も確かめます。

既存CSSのリセット、状態管理、SSRが移行の障害になる場合があります。ビルド設定やデザイン差分も、同じように注意が必要です。そのため、PoCでは実際のアプリ環境を使って確認します。

Stencilの導入費用は無料ですか？

StencilのOSS本体は基本的に無料ですが、システム開発全体が無料になるわけではありません。要件整理や設計、実装に費用がかかり、既存アプリへの統合も含まれます。さらに、テストやドキュメントの作成、教育、運用保守も費用の対象です。

5〜10個の部品を使うPoCは100万〜300万円程度、複数アプリ向けの15〜40部品は500万〜1,500万円程度が初期の検討レンジです。

金額は、一般的な開発相場と想定工数を組み合わせた目安で、個別案件の確定価格ではありません。

Stencilのシステム開発が向いている企業はどのような企業ですか？

Stencilの向き不向きは、共通UIの必要性と継続運用の体制から判断します。下の4つの条件と自社の状況を照らし合わせると、どちらに当てはまるかが見えてきます。

複数FW：業務アプリ間で同じUI・アクセシビリティ基準を使う
段階刷新・統一：既存システムを止めずに更新し、複数ブランドのデザインを統一
運用体制：社内に部品オーナーを置き、更新と品質保証を続けられる
別案が合理的：一つの小規模画面だけを短期間で作る場合や仕様管理者がいない場合は、単一FWの標準機能や既存ライブラリ

まとめ：Stencilのシステム開発は小さく始めて運用まで設計

Stencil.jsは、複数アプリへ再利用できるWeb Componentsを配布するフロントエンド基盤です。システム全体を自動的に安くするわけではないため、開発の範囲と費用は個別に見積もります。

導入の成否は、共通化の範囲や既存アプリとの境界、デザインとコードの対応を設計できるかで決まります。加えて、テストやバージョン管理、利用チームの定着も欠かせません。

まず実行する3つのアクション

試作を業務で使い続けられる共通基盤につなげるために、次の準備を順に進めます。

既存アプリの画面とUI部品を棚卸しし、共通化の目的と効果を数値にまとめます。
5〜10部品を対象にしたPoCで、React・Angular・Vueとの接続と性能を実環境で検証し、アクセシビリティや配布、テストも確かめます。
部品のオーナーとリリースルールを決め、脆弱性対応と問い合わせ窓口、教育と保守の予算も定めます。

採用判断で最後に確認する点

採用に迷ったら、複数のフレームワークへ同じ部品を配る必要があるか、既存画面を段階的に移行したいか、部品の品質と仕様を継続して管理できるかを確認します。条件が明確なら、6つの開発フェーズに終了条件を置き、複数社の見積もりを同じ前提で比べます。そのうえで、短期の制作費だけでなく、リリース後の保守と利用チームの自走まで含めて判断します。

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