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

Stencilのシステム開発は、業務システム全体を一度に作り替えるのではなく、複数のアプリケーションで使うUI部品をWeb Componentsとして標準化し、既存画面へ段階的に組み込む進め方が基本です。

React・Angular・Vueが混在する企業で「画面ごとにボタンや入力フォームの仕様が違う」「共通部品を直すたびに複数チームが修正する」といった課題を解消したい場合、Stencil.jsは有力な選択肢になります。本記事では、Stencil.jsを使ったシステム開発の全体像、要件整理から定着までの6フェーズ、費用相場、見積もりの確認項目を実務目線で解説します。なお、BigCommerceのテーマ基盤や画像作成サービスにもStencilという名称がありますが、この記事ではIonicが開発するStencil.jsを扱います。

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

Stencilのシステムとは何ですか？全体像を理解する

Stencil.jsは、TypeScript・JSX・CSSで書いたコンポーネントを、標準仕様のWeb Componentsへ変換するコンパイラと開発ツール群です。ReactやAngularそのものの代替フレームワークではなく、異なるフレームワークから同じUI部品を呼び出せる共通基盤と考えると、導入範囲を判断しやすくなります。Stencil公式ドキュメントでも、Web Componentsに加えてOutput Targetやprerenderingなどを提供するツールとして説明されています（出典: Stencil公式Introduction、2026年閲覧）。

Stencilが主に担当するのは、業務アプリケーションのフロントエンドにある共通UI層です。たとえば、ボタン、入力フォーム、日付選択、テーブル、モーダル、タブ、ナビゲーション、通知、エラーメッセージといった部品を共通化し、複数の業務画面へ配布します。一方で、顧客情報や在庫情報を保存するデータベース、業務ルールを実行するバックエンド、認証基盤、外部サービスとのAPI連携までをStencilだけで作るものではありません。

この境界を曖昧にすると、「Stencilを採用すればシステム開発費が大幅に下がる」という誤解につながります。Stencilで重複するUI実装やデザイン調整の手戻りを減らせる可能性はありますが、既存データとの連携、権限設計、業務フローの見直し、テスト環境の構築は別途必要です。RFPでは、共通UI基盤の範囲と、各アプリケーション側に残す機能を分けて記載します。

Stencilの代表的な効果は、UI部品の再利用、CSSの影響範囲の分離、遅延読み込み、prerendering、各フレームワーク向けのラッパー生成です。Shadow DOMを使えば、ある画面のCSSが別の部品の見た目を壊すリスクを抑えられます。Output Targetを設定すれば、React・Angularなどのチームがそれぞれの開発体験を保ちながら、共通のWeb Componentsを利用できます。

ただし、共通化は「似ている画面を全部同じにする」ことではありません。部品の責務、プロパティ、イベント、slot、キーボード操作、ARIA属性、表示崩れ時の扱いまでを契約として決める必要があります。デザイン側ではFigmaのカラー・余白・文字サイズをデザイントークンとして管理し、コード側のCSS変数やテーマと対応させます。共通部品を増やすほど、実装だけでなく仕様を決めて守るガバナンスが重要になります。

Stencilのシステム開発の進め方は？6フェーズで解説

Stencilの開発は、いきなりコンポーネントを実装するより、現状の画面と組織の使い方を整理してから小さく検証する方が成功しやすいです。ここでは、要件整理、選定、設計開発、テスト、稼働、定着の6フェーズに分けます。各フェーズの終了条件を決めておくと、PoCが終わらない、作った部品が採用されない、リリース後に品質問題が出るといった事態を防ぎやすくなります。

最初に、Stencilを導入する目的を「見た目をそろえる」だけで終わらせず、測定できる形にします。たとえば、3つの業務アプリで同じ入力部品を使い、仕様変更時の改修箇所を9か所から1か所へ減らす、アクセシビリティ試験の共通不備を次期リリースまでに半減する、画面ごとのUIレビュー期間を短縮するといった目標です。現場の担当者、デザイナー、フロントエンド開発者、バックエンド担当、情報システム部門、決裁者を初期から巻き込みます。

要件整理のチェック項目は、(1)対象アプリと利用フレームワーク、(2)対象ブラウザと端末、(3)共通化候補の部品数、(4)既存デザインの差分、(5)認証・権限・APIとの接続方式、(6)SSRやSEOの要否、(7)キーボード操作やスクリーンリーダーの基準、(8)社内npmレジストリとCI/CDの制約、(9)運用責任者です。5〜10部品のPoCから始めるのか、15〜40部品を複数アプリへ導入するのかで、必要な体制も見積もりも大きく変わります。

選定では、Stencilを使うこと自体を目的にせず、ReactやVueなど単一フレームワークのコンポーネントライブラリ、Litなど別のWeb Components基盤、既存のIonicコンポーネントを採用する案と比べます。複数フレームワークを長期に共存させる、レガシー画面を止めずに一部から刷新する、複数ブランドでUIを統制する、といった条件があればStencilの適性が高まります。一つの小規模画面だけを作る場合は、配布・バージョニング・ドキュメント運用の負担が効果を上回ることがあります。

比較表を作る場合は、技術機能だけでなく、既存チームの学習コスト、テストのしやすさ、SSR・prerendering、React・Angular・Vueへの接続、アクセシビリティ、開発元のサポート、脆弱性対応、社内配布方法、将来の移行可能性を評価します。StencilのOSS利用料は基本的に0円ですが、Enterprise支援は公開定価ではなく個別見積もりです。OSSを自社で保守する場合と、有償支援で技術相談や優先対応を受ける場合を同じ条件で比較します。

設計では、ボタンやフォームの見た目より先に、部品が担う責務と利用者から見えるAPIを決めます。プロパティの型、初期値、イベント名、slotの構造、エラー状態、ローディング状態、レスポンシブ挙動、フォーカス移動、ARIA属性、破壊的変更の扱いを仕様書へ落とします。FigmaのデザイントークンとCSS変数の命名をそろえ、デザイン、実装、ドキュメントのどれが正なのかも合意します。

実装時は、いきなり100部品を作らず、頻繁に使い、差分が少なく、業務影響を測りやすい部品から始めます。5〜10部品を1つの業務アプリへ組み込み、React・Angular・Vueのうち実際に利用する環境でOutput Targetやラッパーを検証します。StorybookまたはStencilのドキュメント機能、private npmレジストリ、セマンティックバージョニング、CHANGELOG、GitHub ActionsなどのCIをこの段階から用意し、完成品だけでなく配布と更新の流れまで確認します。

Stencilのテストは、部品単体が表示されるかだけでは不十分です。単体テストでプロパティやイベントの境界値を確認し、E2Eテストで実際の業務操作を確認し、視覚回帰テストでテーマやブラウザごとの表示差分を検出します。入力フォームなら、正常値、未入力、文字数超過、全角・半角、通信失敗、権限不足、キーボード操作、スクリーンリーダーの読み上げまで一連のシナリオに含めます。

品質ゲートは「テストを実施した」ではなく、リリース条件として定義します。たとえば、重大な機能不具合が0件、主要ブラウザの表示崩れが0件、キーボードだけで主要操作が完了、コントラストやフォーカス表示が社内基準を満たす、既存画面の性能指標を悪化させない、依存パッケージに未対応の重大脆弱性を残さない、といった基準です。GitHub Security LabがStencilリポジトリのCIワークフローに関する脆弱性を開示し修正した事例もあるため、フレームワークの採用後もCIや依存関係の監視を止めません（出典: GitHub Security Lab、2024年）。

稼働時は、全画面を一斉に置き換えるより、対象を限定した段階リリースが安全です。最初の1画面を選び、利用者が多すぎず、業務停止の影響が限定され、効果を測りやすい範囲で実証します。旧部品へ戻す切り戻し手順、npmパッケージの固定バージョン、リリース承認者、障害時の連絡先、ログの確認方法を事前に決めます。UI部品の更新で業務画面が壊れる可能性を考え、互換性のない変更はメジャーバージョンを上げる運用にします。

稼働後に見る指標は、導入部品数だけではありません。共通部品の採用率、同じ不具合の再発件数、画面ごとのUIレビュー時間、初期表示や操作完了までの時間、アクセシビリティ指摘数、リリース失敗率、利用チームからの問い合わせ数を計測します。ステージング環境で本番データに近い量を使い、認証・権限・通信速度・端末差を確認してから本番へ進めます。

共通UI基盤は、リリースした時点で完成ではありません。利用チームが部品の選び方、プロパティの使い方、アクセシビリティの確認方法、バージョンアップの手順を理解して初めて、投資効果が出ます。社内ポータルやStorybookに利用例と禁止例を掲載し、質問の窓口、採用を申請する流れ、仕様変更を決める委員会または担当者を明確にします。

定着のチェックリストには、(1)部品のオーナー、(2)不具合と機能要望の受付方法、(3)リリース頻度、(4)サポート対象ブラウザ、(5)脆弱性と依存パッケージの確認周期、(6)メジャーアップデートの予算、(7)退職や異動に備えた引き継ぎ、(8)新しい部品を追加する判断基準を含めます。Stencilを導入した担当者だけが理解している状態を避け、設計書・テスト・CI設定・SBOM・利用規約を納品物として残します。

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

Stencil自体はOSSのため、基本的なツール利用料は0円です。しかし実際の予算は、UIの棚卸し、デザインシステム設計、コンポーネント実装、各アプリへの統合、テスト、ドキュメント、教育、保守で決まります。2026年の一般的なシステム開発相場でも、小規模は100万〜300万円、中規模は500万〜1,000万円、大規模は1,000万円から数千万円以上という幅が示されています（出典: SIA「システム開発の費用・相場 2026年版」、2026年）。Stencil案件は共通UI基盤と既存アプリ統合の作業量に応じて、この相場を組み替えて考えます。

目安として、技術検証・PoCは100万〜300万円程度、5〜10部品を作り1つのアプリへ接続する期間は1〜2か月程度です。要件整理、主要部品の実装、Reactなどへの接続、簡易テストを含む想定ですが、業務アプリそのもののバックエンドやデータ移行は含みません。Stencil固有の公式価格ではなく、一般的なWebシステム相場と想定工数から置いた予算仮説です。

15〜40部品を2〜3アプリへ導入する小〜中規模ライブラリは500万〜1,500万円程度、期間は3〜6か月程度が推定レンジです。UI棚卸し、デザイントークン、Storybookまたはドキュメント、private npmレジストリ、CI、移行支援まで含めると、単純な部品制作より工数が増えます。40〜100部品を複数チーム・複数フレームワークで運用する業務共通基盤は1,500万〜4,000万円程度、6〜12か月程度が一つの検討レンジになります。

多ブランド、レガシー刷新、複数製品の段階移行、SSOや権限、全社教育まで含むエンタープライズ級では、3,000万〜8,000万円超、9〜18か月程度になる場合があります。上限を断定できるものではなく、既存画面の数、チーム数、移行対象、品質基準、セキュリティ要件、外部連携によって大きく変動します。最低3社へ同じ前提条件で見積もりを依頼し、金額だけでなく含まれる作業を比較します。

初期費用の内訳は、現状分析・要件整理、情報設計とデザイン、コンポーネント実装、フレームワーク連携、テスト、ドキュメント、CI/CD、移行支援、教育に分けて記載してもらいます。利用チームとの合意形成やレビューの回数も工数になるため、「開発者がコードを書く時間」だけで計算しません。人月単価、各作業の人月、担当者の役割、成果物、検収条件が分かる見積書ほど比較しやすくなります。

バックエンド、API、認証、データ移行、クラウド利用料、Figmaの有料プラン、外部セキュリティ診断、監視、運用保守は別枠になりやすいです。運用保守は、依存パッケージ更新、脆弱性対応、ブラウザ検証、アクセシビリティ、ドキュメント更新、問い合わせ対応を含め、初期開発費の年10〜20％程度を暫定予算に置く例があります（出典: Casually「システム開発の料金相場」、2026年閲覧）。契約前に、月額か年額か、未使用時間の扱い、緊急対応の単価、メジャーアップデートの費用を確認します。

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

Stencilの見積もりは、部品数だけを伝えても正確になりません。同じ20部品でも、1つのReactアプリへ組み込む場合と、React・Angular・Vueの3環境へ配布し、既存画面を移行する場合では必要な設計・テスト・ドキュメントが異なります。発注前に、対象範囲、現在の課題、想定する利用者、既存技術、納品物、運用体制を1枚のRFPにまとめます。

RFPには、対象アプリ名とフレームワーク、利用中のNode.jsやTypeScriptのバージョン、対象ブラウザ、部品の候補、画面数、移行の優先順位、必要なOutput Target、SSRやprerenderingの要否、Figmaやデザイン tokensの有無、npmの公開範囲、CI/CD環境を記載します。業務上の重要画面や個人情報を扱う画面がある場合は、停止可能な時間、監査ログ、権限、秘密情報、バックアップ、脆弱性対応も前提にします。

納品物は、ソースコードだけにしません。コンポーネント仕様書、APIとイベントの一覧、利用例、Figmaとの対応表、テストコード、E2Eや視覚回帰の設定、CI/CD設定、リリース手順、CHANGELOG、SBOM、運用マニュアル、教育資料、既知の制約を明記します。著作権やリポジトリの所有権、OSSライセンスの扱い、第三者パッケージの更新責任も見積書と契約書の両方で確認します。

候補会社には、Stencil.jsの実案件、Web Components全般の経験、BigCommerce Stencilとの区別、React・Angular・Vueの連携経験、Figmaやデザイントークン、アクセシビリティ、private npm運用、CI/CD、保守体制を質問します。公開事例があっても、自社と同じ規模・業務・契約形態とは限りません。誰が設計を担当するのか、サンプル部品をどの環境で検証できるのか、リリース後に誰が何時間対応するのかまで確認します。

一括請負、準委任、内製チームへの人材支援では、発注者側の責任と成果物の定義が異なります。短期PoCなら専門人材の増員型が合うことがありますが、長期運用では設計判断と保守の責任者を自社にも置きます。見積比較では、要件定義、設計、実装、テスト、移行、教育、保守を同じ欄に並べ、含まれない作業が明記されているかを確認します。安い見積もりでも、移行や回帰テストが別料金なら総額が逆転する可能性があります。

よくある失敗は、技術担当者だけで導入を決め、利用チームが部品を使わないことです。対策として、最初の要件整理で採用対象の画面を決め、現場の入力業務を観察し、共通化によって減らしたい手戻りを数値化します。次に、代表チームをPoCへ参加させ、利用しにくいAPIや業務上の例外を早期に見つけます。トップダウンで採用を義務化する場合でも、例外を申請できるルールを作ります。

もう一つのリスクは、共通化しすぎて個別業務の表現を無理に部品へ押し込むことです。汎用部品のプロパティが増えすぎると、使い方が難しくなり、テスト範囲も広がります。共通化する基準を「3つ以上のアプリで同じ振る舞いを使う」「アクセシビリティやセキュリティの統制が必要」「変更頻度が低く安定している」などと決め、個別画面に残す判断も正式な選択肢にします。

よくある質問（FAQ）

Stencilのシステム開発では、「既存画面を止めずに移行できるか」「費用をどこまで見込むか」「Reactなどと共存できるか」という質問が多く寄せられます。技術だけでなく、既存業務への影響、保守担当者、契約範囲まで含めて判断することが大切です。

はい、既存画面をすべて停止して作り直す必要はなく、Web Componentsとして作った部品を一部の画面から組み込む段階移行が可能です。まず代表的なボタンや入力フォームを1つの業務画面で検証し、表示、イベント、フォーム送信、フォーカス、性能、ブラウザ互換性を確認します。ただし、既存CSSのリセット、状態管理、SSR、ビルド設定、デザイン差分が移行の障害になる場合があるため、PoCで実際のアプリ環境を使って確認します。

StencilのOSS本体は基本的に無料で利用できますが、システム開発全体が無料になるわけではありません。要件整理、設計、実装、既存アプリへの統合、テスト、ドキュメント、教育、運用保守に費用が発生します。利用部品が5〜10個のPoCなら100万〜300万円程度、複数アプリ向けの15〜40部品なら500万〜1,500万円程度を初期の検討レンジにできますが、これは公開されている一般的な開発相場と想定工数を組み合わせた目安であり、個別案件の確定価格ではありません。

React・Angular・Vueなど複数のフレームワークが混在し、複数の業務アプリで同じUIやアクセシビリティ基準を使いたい企業に向いています。既存システムを止めずに段階刷新したい企業、複数ブランドやサービスのデザインを統一したい企業、社内にコンポーネントのオーナーと運用体制を置ける企業も適しています。

反対に、一つの小規模画面だけを短期間で作る場合や、組織として共通部品の仕様を管理する人がいない場合は、単一フレームワークの標準機能や既存ライブラリの方が合理的です。Stencilの採否は流行や無料という理由で決めず、複数アプリへ部品を配布する必要があるか、更新と品質保証を継続できるかで判断します。

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

Stencil.jsは、業務システム全体を自動的に安くする製品ではなく、複数のアプリケーションへ再利用可能なWeb Componentsを配布するためのフロントエンド基盤です。導入の成否は、Stencilの機能だけでなく、共通化する範囲、既存アプリとの境界、デザインとコードの対応、テスト、バージョン管理、利用チームの定着を設計できるかで決まります。

最初に、既存アプリの画面とUI部品を棚卸しし、共通化の目的と効果を数値化します。次に、5〜10部品を対象とするPoCで、React・Angular・Vueとの接続、アクセシビリティ、性能、配布、テストを実環境で検証します。最後に、部品のオーナー、リリースルール、脆弱性対応、問い合わせ窓口、教育と保守の予算を決めます。この順番なら、技術の試作で終わらず、業務で使い続けられる共通基盤へ発展させやすくなります。

Stencilを採用するか迷ったら、「複数フレームワークへ同じ部品を配る必要があるか」「既存画面を段階移行したいか」「部品の品質と仕様を継続管理できるか」の3点を確認します。3つの回答が明確なら、要件整理から選定、設計開発、テスト、稼働、定着の各フェーズに終了条件を置き、複数社の見積もりを同じ前提で比較してください。短期の制作費だけでなく、リリース後の保守と利用チームの自走まで含めて判断することが、Stencilのシステム開発を成功させる近道です。

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