Stencilのシステム開発の完全ガイド - ブログ

Stencilのシステムとは、Stencil.jsで再利用可能なWeb Componentsを作り、React・Angular・Vueなど複数の画面へ共通UIを配布するフロントエンド基盤です。業務システムのデータベースや基幹業務そのものを置き換える技術ではなく、複数アプリの画面品質と開発速度をそろえるための仕組みです。

「Stencilを導入すれば何ができるのか」「既存システムと共存できるのか」「費用はいくらかかるのか」と悩む方に向けて、本記事ではStencilの全体像、向いているケース、開発の進め方、費用相場、発注時の確認事項、セキュリティ、よくある失敗までをまとめます。なお、ここで扱うStencilは、Web Componentsを生成するStencil.jsを指し、他のサービスやECテーマ基盤における同名機能とは区別します。

Stencilのシステムとは何ですか？

Stencilは、TypeScript・JSX・CSSで記述した部品を、標準仕様に準拠したWeb Componentsへビルドするツールチェーンです。公式情報では、Custom ElementsやShadow DOMなどのWeb標準を利用し、主要なフレームワークまたはフレームワークなしのHTMLから同じ部品を使えることが特徴とされています。ここが、単一フレームワークの画面開発とStencilのシステム開発を分ける重要なポイントです。

Stencilが担当するのは業務システムのどの部分ですか？

Stencilが主に担当するのは、利用者が触れるボタン、入力フォーム、テーブル、ダイアログ、タブ、ナビゲーションなどの共通画面部品です。これらをコンポーネントとして設計し、社内パッケージレジストリなどを通して複数アプリへ配布します。部品側に色、余白、文字サイズ、フォーカス表示、キーボード操作を集約すれば、各開発チームが毎回同じ仕様を作り直す必要がなくなります。

一方で、受注や在庫のデータを保存するデータベース、業務ルールを処理するバックエンド、認証、権限、外部API、帳票、データ移行などはStencilの担当範囲ではありません。Stencilを「業務システムを丸ごと作る製品」と考えると、見積もりも要件定義も大きくずれます。正しくは、既存または新規の業務アプリに組み込む共有UI基盤です。

Stencilで作れる共通部品には何がありますか？

代表例は、業務入力に使うテキストフィールド、日付選択、セレクトボックス、検索条件、エラー表示、確認ダイアログです。さらに、一覧画面のページネーション、並べ替え、空データ表示、読み込み中表示、権限による表示切り替え、社内ブランドのロゴやテーマも共通化できます。単に見た目をそろえるだけでなく、入力値の検証、エラー文言、フォーカスの移動、イベント名まで同じ契約にすることが大切です。

公式サイトでは、TypeScript対応、ホットリロード付きの開発サーバー、ドキュメント生成、ユニットテスト、遅延読み込み、Shadow DOM、プリレンダリングなどが案内されています。2026年5月28日の公式リリース一覧ではv4.43.5が公開されており、導入時は固定バージョン、更新方針、対応ブラウザを決めてから採用する必要があります（出典：Stencil公式サイト、Stencil Core公式リリース一覧、2026年）。

Stencilの種類と技術的な特徴を整理します

Stencilの価値は、部品を一度書けば何でも自動的に解決する点ではありません。Web標準の部品として配布し、複数のアプリが同じ設計ルールで利用できる状態を作る点にあります。そのため、実装方式だけでなく、デザイン、API、バージョン、テスト、ドキュメント、利用申請を含めて種類を考えることが重要です。

Web ComponentsとStencilコンポーネントの関係

Web Componentsは、Custom Elements、Shadow DOM、HTML Templatesなどの標準技術を組み合わせて、ブラウザで扱える独自要素を作る仕組みです。Stencilはその要素をTypeScriptやJSXで開発しやすくし、ビルド時に必要なコードを生成します。たとえば<company-button>のような部品を作れば、呼び出し側はフレームワーク固有の画面部品ではなく、Web標準に近い要素として利用できます。

Shadow DOMを使うと、部品内部のスタイルが外部CSSの影響を受けにくくなります。ただし、完全に閉じた設計にするとテーマ変更やアクセシビリティ対応が難しくなるため、CSSカスタムプロパティ、slot、公開属性、イベントの設計を事前に定義します。見た目だけを隠すのではなく、利用側が何を設定でき、何を設定してはいけないかをAPI仕様書に残すことが運用上の要点です。

React・Angular・Vueとの共存はどのように実現しますか？

Stencilは、React、Angular、VueなどのアプリからWeb Componentsを利用できるように、フレームワークごとのOutput Targetやラッパーを生成できます。実際の画面で確認すべきなのは、イベントの受け渡し、プロパティの型、フォームの双方向連携、SSR時の初期HTML、ルーティング、テスト環境です。名称上は同じボタンでも、フレームワークによってイベント購読や型定義の扱いが異なるため、サンプル画面を作って検証します。

複数フレームワークを使う企業では、全画面を一度に移行する必要はありません。最初に新規画面の入力部品だけをStencil化し、次に既存画面のヘッダーやテーブルへ広げる方式が現実的です。反対に、単一の小規模アプリで部品が数個しかない場合は、既存フレームワークの標準機能を使う方が設計と配布の負担を抑えられる場合があります。

Stencilのシステム開発が向いている企業・向いていない企業

Stencilの導入判断は、技術の流行ではなく、共通部品を何個のアプリで何年間使うかで決めます。初期開発だけを見ると専用の設計や配布基盤が必要になりますが、複数チームの重複実装、デザイン差分、アクセシビリティ修正、ブラウザ検証を減らせる場合は、中長期の効果が期待できます。

導入効果を出しやすいケース

ReactとAngularが混在している、複数の業務アプリを別々のチームが開発している、ブランドやサービスごとの画面差分が増えている企業は、Stencilと相性がよい傾向があります。特に、共通の検索フォーム、一覧表、承認ダイアログ、通知、権限表示を複数画面で使う場合は、部品を直す効果が横展開されます。

大規模な導入事例では、60を超えるチームが40以上のアプリを開発する環境で、フレームワークをまたぐデザインシステムにStencilが使われています（出典：Stencil公式の導入事例、参照年2026年）。この数字はすべての企業が同じ規模で導入すべきという意味ではなく、複数チーム・複数アプリをまたぐほど共通基盤の投資効果を測りやすいことを示す材料です。

別の方法を検討した方がよいケース

一つの小規模画面だけを作る場合や、利用する部品が数個で将来の横展開もない場合は、Stencil専用のパッケージ設計、バージョニング、ドキュメント、テスト環境が負担になりやすいです。単一フレームワークの標準コンポーネントや、既存のUIライブラリで要件を満たせるなら、導入しない判断にも合理性があります。

また、デザインの決裁者が不在で、各チームが共通部品を採用するルールもないまま技術だけを先に入れると、部品の乱立が起こります。「必ず共通化する範囲」「個別画面に残す範囲」「例外を承認する人」を決められない組織では、Stencil以前にデザインシステムの運用体制を整えることが先になります。

Stencilのシステム開発の進め方

Stencil案件は、コンポーネントを作る工程だけでなく、採用する画面、配布方法、品質基準、保守担当を決める工程が成果を左右します。最初から全社の全画面を対象にせず、現状分析から小さな検証、段階移行へ進むと、技術リスクと合意形成の負担を抑えられます。

▶ 詳細はこちら：Stencilのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

現状分析とPoCで確認すること

まず既存画面を棚卸しし、部品名、利用画面、担当チーム、見た目の差分、入力ルール、ブラウザ、アクセシビリティ上の課題を一覧化します。次に、5〜10個程度の部品を1つの業務画面へ組み込み、プロパティ、イベント、フォーム連携、ビルドサイズ、初期表示、SSRの要否を確認します。PoCの合格条件は「動いた」ではなく、実際の利用者が既存画面と同じ業務を完了できることです。

PoCでは、Reactだけでなく、将来接続する可能性がある別フレームワークも1つ選び、同じ部品が使えるかを試します。Shadow DOMを使う場合のテーマ適用、slotの使い方、イベントの型、SSR後のハイドレーション、テスト用のセレクターも早期に確認します。ここで問題を見つけると、全社ライブラリを作った後の作り直しを防げます。

デザインとコンポーネントAPIを設計する

デザイナーが管理するカラー、余白、文字、角丸、影、ブレークポイントをデザイントークンとして整理し、StencilのCSSカスタムプロパティなどへ対応させます。コンポーネントごとに、必須属性、任意属性、イベント、slot、エラー表示、ローディング状態、キーボード操作、ARIA属性、レスポンシブ挙動を定義します。APIが曖昧なまま実装を始めると、各画面が独自の回避策を持ち、共通化の効果が失われます。

特に業務画面では、見た目よりも入力の意味を統一することが重要です。日付の形式、必須項目の表示、エラーの出るタイミング、数値の丸め、権限がない場合の表示などを業務部門と合意します。画面部品の仕様書には、デザイン画像だけでなく、利用例、禁止例、アクセシビリティ試験結果、互換性方針も含めます。

実装・テスト・配布・段階移行を行う

実装後は、単体テスト、E2Eテスト、視覚回帰テスト、性能テスト、アクセシビリティテストを分けて実施します。セマンティックバージョニングを採用し、破壊的変更はメジャー更新、後方互換の機能追加はマイナー更新、修正はパッチ更新とするなど、リリースのルールを決めます。変更履歴、移行手順、非推奨化の期限までパッケージと一緒に公開します。

配布先は、社内のプライベートパッケージレジストリ、クラウド型レジストリ、セルフホスト型レジストリなどから、機密性、ネットワーク制限、運用者のスキルで選びます。CI/CDでは、依存関係の監査、秘密情報の分離、テスト、パッケージ署名または公開権限、ロールバックを組み込みます。移行は1画面または1部品から始め、利用率、障害件数、修正時間、共通部品の再利用数を測定すると、継続投資の判断がしやすくなります。

Stencilのシステム開発費用相場と期間

Stencil自体はOSSであり、基本的なツール利用料はかかりません。ただし、実際の予算はUIの棚卸し、デザインシステム設計、部品実装、各アプリへの組み込み、テスト、ドキュメント、教育、保守で決まります。以下はStencil固有の公式価格表ではなく、2026年の一般的なWeb・業務システム開発相場と、必要な作業量を対応させた予算仮説です。要件や体制で変動するため、初期見積もりのたたき台として利用します。

▶ 詳細はこちら：Stencilのシステム開発の見積相場や費用/コスト/値段について

規模別の初期費用と開発期間の目安

技術検証やPoCで5〜10部品を1アプリへ接続する場合は、100万〜300万円、期間は1〜2か月が目安です。15〜40部品を作り、2〜3アプリへ導入し、トークン、ドキュメント、CI、移行支援まで含める小〜中規模では、500万〜1,500万円、3〜6か月を見込みます。これらは公開されている2026年版のシステム開発相場に、Stencil特有の部品設計と統合作業を加味した推定です（出典：2026年版の公開システム開発費用資料、2026年）。

40〜100部品を複数フレームワーク・複数チームで使う共通基盤では、1,500万〜4,000万円、6〜12か月程度が一つの目安です。多ブランド、レガシー刷新、複数製品の段階移行、全社ガバナンスまで含む場合は、3,000万〜8,000万円超、9〜18か月になることもあります。人月単価はスキルや地域で大きく変わるため、金額だけでなく、何人月をどの作業に配分したかを確認します。

見積もりで別枠にすべき費用

見積書では、共通UI基盤の費用と、業務アプリ側の改修費を分けます。バックエンド、API、認証、権限、データ移行、クラウド基盤、既存画面の改修、デザイン管理ツールなどの有料プラン、外部セキュリティ診断はStencil本体の費用に含まれないことが多いです。データ移行は100万〜1,000万円以上、セキュリティテストは数十万〜数百万円になる場合があるため、対象データ量と試験範囲を確認します。

運用費としては、依存パッケージの更新、脆弱性対応、ブラウザ検証、アクセシビリティ、ドキュメント更新、利用チームからの問い合わせ、メジャーアップデート時の改修枠を確保します。暫定的には初期開発費の年10〜20％程度を保守予算として置き、障害対応の時間帯、修正優先度、リリース頻度、SLAを契約書で明文化します。OSSが無料でも、保守を無償で続けられるわけではありません。

Stencilの開発会社・ベンダーの選び方

Stencilの開発会社を選ぶときは、単に「Stencil.jsを使える」と書かれているかだけでは不十分です。Web Componentsの設計、複数フレームワークの接続、デザインシステム、CI/CD、アクセシビリティ、既存画面の移行、長期保守を一つの提案で説明できるかを確認します。技術者の経験だけでなく、社内で共通部品を採用し続ける仕組みまで設計できることが重要です。

StencilJSとWeb Componentsの実績を分けて確認する

提案企業には、StencilJSそのものの実績、一般的なWeb Componentsの実績、単一フレームワークのUI開発実績を分けて提示してもらいます。実績では、部品数、利用アプリ数、対応フレームワーク、配布方法、SSRの有無、アクセシビリティ試験、リリース後の保守期間を確認します。実績を公開できない場合でも、匿名化した構成図、テスト項目、納品物のサンプルを確認できれば、比較材料になります。

また、受託開発型なのか、専門人材を加える支援型なのか、設計だけを支援する型なのかで、発注側の負担は変わります。社内にフロントエンドの責任者がいる場合は人材支援が合うこともありますが、要件整理から移行、教育、運用まで任せたい場合は一括請負の体制が必要です。契約主体、再委託、ソースコードの権利、OSSライセンス、退職や契約終了後の引き継ぎも確認します。

RFPと見積書に記載する納品物

RFPには、対象アプリ、対象フレームワーク、想定部品数、対応ブラウザ、SSRやプリレンダリング、デザインデータ、トークン、権限、フォーム仕様、アクセシビリティ基準、性能目標、配布先、CI/CD、運用体制を記載します。特に「共通部品を作る」だけで終わらず、何画面へいつ移行するかまで対象範囲に含めます。

納品物は、ソースコード、設計書、コンポーネントAPI仕様、デザイントークン、ドキュメントサイト、テストコード、視覚回帰の基準画像、CI設定、CHANGELOG、SBOM、脆弱性対応手順、移行ガイド、教育資料、運用引き継ぎ資料まで確認します。見積比較では、価格だけでなく、これらの納品物が含まれるか、検収条件が何か、追加変更の単価がいくらかを同じ表で比べます。

保守・ガバナンスを提案に含めてもらう

共通部品の変更は、利用しているすべてのアプリへ影響する可能性があります。そのため、破壊的変更の承認者、互換性を確認するアプリ一覧、リリース前の回帰テスト、非推奨期間、緊急時のロールバック方法を決めます。開発会社には、月次の依存関係更新、脆弱性の通知、ブラウザのサポート方針、問い合わせの応答時間、メジャーアップデート支援を提案書へ明記してもらいます。

開発会社やサービスを比較するときは、Stencilの名称だけでなく、発注後に自社で運用できるかを評価します。運用担当者が部品を追加できる教育、設計レビューの仕組み、ドキュメントの更新責任、社内チームへの権限移管がなければ、専門家への依存が残ります。将来の内製化または別パートナーへの切り替えを想定した契約にすることが、長期的なリスク低減につながります。

▶ 詳細はこちら：Stencilのシステム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら：Stencilのシステム開発の発注/外注/依頼/委託方法について

セキュリティ・アクセシビリティ・失敗例

StencilはWeb標準を利用する技術ですが、採用しただけで安全性やアクセシビリティが保証されるわけではありません。依存パッケージ、公開範囲、CIの権限、秘密情報、コンポーネントの入力値、外部API、利用者の操作環境を含むシステム全体で要件化します。

依存関係と開発パイプラインを守る

パッケージの脆弱性監視、ロックファイルの管理、SBOMの生成、依存関係更新ツールによる更新、公開権限の最小化、CIの秘密情報分離、監査ログ、レビュー必須化を基本にします。公開パッケージを使う場合は、名前のなりすましや依存関係の乗っ取りも確認します。公開セキュリティアドバイザリでは、2024年にStencilのCIワークフローに関する脆弱性と修正履歴が示されており、OSSだから安全と決めつけず、開発パイプラインを継続監視する必要性を確認できます（出典：Stencilに関する公開セキュリティアドバイザリ、2024年）。

個人情報を扱う業務システムでは、データを入力する画面部品と、保存・送信するバックエンドを分けて評価します。個人情報保護委員会のガイドラインでは、委託先の安全管理措置を確認し、委託契約、取扱状況の把握、再委託の管理を行う考え方が示されています（出典：個人情報保護委員会「個人情報保護法ガイドライン（通則編）」）。RFPには、テストデータの匿名化、アクセス権限、TLS、CSP、ログ、バックアップ、インシデント報告期限を記載します。

キーボード操作とスクリーンリーダーを検証する

共通部品は、一度直せば多くの画面に反映できる一方、誤った実装も広範囲へ広がります。ボタンやダイアログのフォーカス移動、Escキーでの閉じる操作、Tab順、ラベルとエラーの関連付け、コントラスト、拡大表示、スクリーンリーダーの読み上げを、部品単位と業務画面単位で試験します。

ウェブアクセシビリティ基盤委員会は2026年6月にWCAG 2.2日本語訳の更新を案内し、JIS X 8341-3の改正検討にも触れています（出典：WAIC「WCAG 2.2 日本語訳更新のお知らせ」、2026年）。公共性の高いサービスや大企業向けの業務システムでは、達成レベル、対象ブラウザ、試験方法、改善期限を契約前に決めると、納品後の認識違いを防げます。

Stencil導入で起こりやすい失敗と対策

典型的な失敗は、トップダウンで共通化を決め、現場の入力ルールや画面差分を調べないことです。全社標準のボタンを作っても、承認業務ごとに必要な状態や権限が異なれば、結局は個別拡張が増えます。最初に利用頻度が高く、差分が少ない部品を選び、業務担当者を含めたレビューで仕様を決めます。

次に多いのは、部品を作った後の採用・更新ルールがないことです。誰も使わない部品、似た名前の部品、破壊的変更を含む無断更新が発生しないよう、カタログ、オーナー、リリースノート、サポート期間、例外申請を運用します。担当者の退職に備え、ソースコード、設計判断、テスト、配布権限、環境構築手順を複数人が再現できる状態にします。

よくある質問（FAQ）

最後に、Stencilのシステム開発を検討する際に特に質問されやすい点をまとめます。採用の可否は、部品数だけでなく、利用アプリ数、フレームワークの種類、SSR要件、運用体制、将来の移行計画を合わせて判断します。

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

Stencilだけで業務システム全体を開発するのではなく、主に画面の共通部品やデザインシステムを構築します。データベース、業務ロジック、認証、権限、API、データ移行、クラウド基盤は別途設計が必要です。Stencilをフロントエンドの共有基盤として位置づけると、役割と費用を正しく分けられます。

Stencilは無料ですか？開発費用はなぜ発生しますか？

Stencilの基本ツールはOSSで、利用料を抑えられる可能性があります。ただし、費用の中心はライセンスではなく、共通部品の要件整理、デザイン・API設計、実装、テスト、各アプリへの組み込み、ドキュメント、保守です。ツールが無料でも、品質と運用を担う人員や開発会社の工数は必要です。

既存のReactやAngularの画面を止めずに移行できますか？

段階移行は可能です。まず共通性が高い部品をStencilで作り、新規画面または既存画面の一部へ組み込み、入力業務、表示速度、テスト、運用負荷を確認してから対象を広げます。フレームワーク間のイベント、型、SSR、テーマ、アクセシビリティをPoCで確認し、旧部品をいつ廃止するかまで移行計画に記載します。

StencilはSEOや表示速度に不利ですか？

Stencilだから一律にSEOや表示速度が悪くなるわけではありません。遅延読み込み、バンドル分割、プリレンダリング、SSR、適切なHTML構造を要件にし、対象ページの初期表示、Largest Contentful Paint、操作可能になるまでの時間、JavaScript量を実測します。検索流入が重要なページでは、検索エンジンが取得する初期HTMLと、JavaScript実行後の内容が一致するかを確認します。

まとめ

Stencilを採用するか判断するポイント

Stencilのシステム開発は、Stencil.jsでWeb Componentsを作り、複数の業務アプリへ共通UIを配布する取り組みです。バックエンドやデータベースを作る技術ではないため、業務システム全体の構成の中でフロントエンド共有基盤として位置づけることが出発点になります。React、Angular、Vueなどが混在する環境、複数チームが同じ部品を使う環境、段階的な画面刷新を進めたい環境では、導入効果を検討しやすくなります。

発注前に整理する次の一歩

費用はOSSの利用料ではなく、UI棚卸し、デザイントークン、部品API、実装、各アプリへの統合、テスト、配布、教育、保守で決まります。PoCなら100万〜300万円、小〜中規模なら500万〜1,500万円、複数チームの共通基盤なら1,500万〜4,000万円程度を初期検討の起点にし、バックエンド、データ移行、セキュリティ診断などの別費用を分けて見積もります。最終的には、部品数だけでなく、利用アプリ数、運用組織、対応品質、移行範囲をそろえて複数の提案を比較します。

導入を成功させる鍵は、技術選定より先に共通化の目的と運用ルールを決めることです。誰がAPIを承認し、どの変更を破壊的と判断し、どのテストを合格条件とし、担当者が変わってもどのように保守するかを明文化します。Stencilを採用するかどうかは、「複数フレームワークへ共通部品を配る必要があるか」「その部品を継続的に運用できるか」の2点から判断すると、過剰導入を避けながら適切な選択ができます。