Stencilのシステム開発の完全ガイド

Stencilのシステム開発は、共通部品の設計、複数アプリへの配布、継続的な運用を組み合わせて、画面の品質と開発速度をそろえる取り組みです。業務アプリの画面に使う部品を一度作り、複数のアプリで同じ見た目と操作にそろえられる点が特徴です。

▼関連記事一覧
・Stencilのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・Stencilのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・Stencilのシステム開発の見積相場や費用/コスト/値段について
・Stencilのシステム開発の発注/外注/依頼/委託方法について

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

Stencilの概要

Stencilは、TypeScript・JSX・CSSで書いた部品を、標準仕様に準拠するWeb Componentsにビルドするツールチェーンです。Custom ElementsやShadow DOMといったWeb標準を使うため、主要なフレームワークやHTMLから共通部品を利用できます。Web標準を使う点が、単一フレームワークの画面開発とStencil開発を分ける違いです。

Stencilが担当する範囲

Stencilが主に担うのは、利用者が操作する共通の画面部品です。ボタンや入力フォーム、テーブルなどを、コンポーネントとして設計します。ダイアログやタブ、ナビゲーションも含みます。

• 部品の配布：社内パッケージレジストリなどを通じて、複数のアプリへ届けます。
• 表示仕様の統一：色や余白、文字サイズ、フォーカス表示を部品側で決め、画面の見え方をそろえます。
• 操作仕様の統一：キーボード操作などを共通化し、各チームの作り直しを減らします。

受注や在庫を保存するデータベースや、業務ルールを処理するバックエンドは、担当範囲外です。認証や権限、外部APIも含まれません。帳票やデータ移行も、担当範囲には入りません。

つまり、Stencilは業務アプリに組み込む共有UI基盤であり、業務システム全体を作る製品ではありません。

Stencilで作れる共通部品の例

業務入力や一覧表示で繰り返し使う部品は、共通化しやすい対象です。入力値の検証やエラー文言、フォーカス移動、イベント名まで同じ決まりにそろえると、画面ごとの差が出にくくなります。共通化の対象になる部品は、入力、状態表示、一覧操作、ブランド表現の4つに分けられます。

• 入力部品：テキストフィールド、日付選択、セレクトボックス、検索条件。
• 状態表示：エラー、確認ダイアログ、空データ、読み込み中の表示。
• 一覧操作：ページネーション、並べ替え、権限による表示切り替え。
• ブランド表現：社内ブランドのロゴやテーマ。

公式サイトでは、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の影響を抑える一方、閉じすぎるとテーマ変更やアクセシビリティ対応が難しくなります。
• API設計：CSSカスタムプロパティやslot、公開属性、イベントを定義し、設定できる内容と禁止事項をAPI仕様書に残します。

React・Angular・Vueとの共存の仕組み

Stencilは、Output Targetやラッパーを生成することで、React、Angular、VueなどからWeb Componentsを使えるようにします。

実際の画面では、フォーム連携やSSRの初期HTML、ルーティング、テスト環境を確かめます。

• フレームワーク差：イベント購読や型定義の扱いを、サンプル画面で検証します。
• 段階移行：全画面を一度に移行せず、新規画面の入力部品から既存画面のヘッダーやテーブルへ広げます。
• 小規模アプリ：部品が数個だけなら、標準機能で設計や配布の負担を抑えられる場合があります。

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

導入の判断は、技術の流行ではなく、共通部品を何個のアプリで何年使うかで決めます。初期設計が必要でも、重複実装やデザイン差分を減らせるなら、中長期の効果が期待できます。アクセシビリティ修正とブラウザ検証も、減らせる作業に含まれます。

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

複数のチームや複数のアプリで画面部品を共有する環境では、Stencilの効果を検討しやすくなります。特に、共通部品を直した効果が複数の画面へ広がる構成は、候補になりやすいです。当てはまりやすい環境は、技術の混在、チームの分散、画面差分の増加、共通部品の多さの4つです。

• 技術が混在：ReactとAngularなど、複数のフレームワークを使う。
• チームが分散：別々のチームが複数の業務アプリを開発する。
• 画面差分が増加：ブランドやサービスごとに画面の差が広がっている。
• 共通部品が多い：検索フォーム、一覧表、承認ダイアログ、通知、権限表示を再利用する。

大規模な事例では、60を超えるチームが40以上のアプリを開発する環境で、フレームワークをまたぐデザインシステムにStencilが使われています（出典：Stencil公式の導入事例、参照年2026年）。

この規模は、導入の条件ではなく、複数のチームやアプリをまたぐ投資効果を測る材料です。

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

画面が一つだけの小規模なシステムで、利用する部品が数個にとどまり、将来の横展開もない場合は、専用パッケージの設計やバージョニングが負担になりやすいです。文書やテスト環境の準備も、手間がかかりやすいです。

既存の標準コンポーネントやUIライブラリで要件を満たせるなら、導入しないという選択にも十分な理由があります。

デザインの決裁者や共通部品の採用ルールがないまま技術だけを先に進めると、部品が乱立するおそれがあります。共通化する範囲と個別に作る範囲、例外を承認する人を決められない組織では、先にデザインシステムの運用体制を整えます。

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

成果を左右するのは、部品の実装だけではありません。対象の画面と配布方法を先に決め、品質基準と保守担当も定めます。そのうえで、現状分析、小さな検証、段階移行の順に進めると、技術リスクと合意形成の負担を抑えられます。

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

現状分析とPoCの確認項目

PoCの前に、既存画面と利用条件を洗い出します。合格条件は、利用者が既存画面と同じ業務を完了できることです。

• 現状分析：部品、画面、担当、見た目の差、入力ルール、ブラウザ、アクセシビリティ課題を一覧にします。
• 部品検証：5〜10個程度の部品を1画面に組み込み、プロパティやイベント、フォーム、ビルドサイズ、初期表示、SSRを確かめます。
• 環境検証：Reactと別のフレームワークで、テーマやslot、イベント型、ハイドレーション、テスト用セレクターを試します。

問題を早く見つけておけば、全社向けのライブラリを作った後での作り直しを防げます。

デザインとコンポーネントAPIの設計

APIが曖昧なまま実装を進めると、各画面に回避策が生まれ、共通化の効果が失われます。業務画面では、見た目と入力の意味をそろえます。設計では、トークン、部品仕様、業務ルール、仕様書の4つを決めておきます。

• デザイントークン：色、余白、文字、角丸、影、ブレークポイントを整理し、CSSカスタムプロパティへ対応させます。
• 部品仕様：属性、イベント、slot、エラー、読み込み、キーボード、ARIA、レスポンシブ挙動を定義します。
• 業務ルール：日付、必須項目、エラー時期、数値の丸め、権限表示を業務部門と合意します。
• 仕様書：画像、利用例、禁止例、アクセシビリティ試験、互換性方針を記載します。

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

移行後は、測った数値をもとに継続投資を判断します。作業は、試験、配布、CI/CD、段階移行の順に進めます。

1. 単体テスト、E2E、視覚回帰、性能、アクセシビリティの試験を行い、セマンティックバージョニングを採用します。
2. 変更履歴、移行手順、非推奨化期限を公開し、社内・クラウド型・セルフホスト型の中から、機密性やネットワーク制限、運用者のスキルに合う配布先を選びます。
3. CI/CDに、依存監査、秘密情報の分離、テスト、署名または公開権限、ロールバックを組み込みます。
4. まずは1画面または1部品から移行し、利用率、障害件数、修正時間、再利用数を測ります。

更新規則も、あらかじめ決めておきます。たとえば、破壊的変更はメジャー、後方互換の機能追加はマイナー、修正はパッチとします。

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

Stencil自体はOSSなので、基本的なツールの利用料はかかりません。ただし、実際の予算は既存UIの洗い出しや、デザインシステムの設計、部品の実装によって決まります。アプリへの組み込みやテストに加え、文書、教育、保守も費用に含まれます。

以下の金額は、2026年の一般的なWeb・業務システム開発の相場に、Stencil固有の作業量を当てはめた予算仮説で、Stencil固有の公式価格表ではありません。要件や体制によって変わるため、初期見積もりのたたき台として使います。

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

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

金額は、公開相場にStencil固有の部品設計と統合を加味した推定です（出典：2026年版の公開システム開発費用資料、2026年）。人月単価はスキルや地域によって異なるため、作業ごとの人月配分も確かめます。規模ごとの目安は、PoC、小〜中規模、共通基盤、大規模展開の4段階で示します。

• PoC：5〜10部品・1アプリで100万〜300万円、1〜2か月。
• 小〜中規模：15〜40部品・2〜3アプリ、トークン・文書・CI・移行支援を含み500万〜1,500万円、3〜6か月。
• 共通基盤：40〜100部品・複数フレームワークとチームで1,500万〜4,000万円、6〜12か月。
• 大規模展開：多ブランド、刷新、複数製品移行、全社統治を含むと3,000万〜8,000万円超、9〜18か月の場合があります。

見積もりで別枠にする費用

共通UI基盤と業務アプリ側の改修費は、分けて考えます。バックエンドやAPI、認証、権限は、Stencil本体に含まれないことが多いです。データ移行やクラウド基盤も、本体の費用には入らないことが多いです。

データ移行は100万〜1,000万円以上、セキュリティテストは数十万〜数百万円になる場合があります。金額は、対象データ量と試験範囲で変わります。

OSSは無料でも、保守は無償ではありません。見積もりでは、別枠の費用、別途見積もる費用、保守費、契約条件の4項目を確認します。

• 別枠の費用：既存画面改修、有料デザイン管理プラン、外部セキュリティ診断も分けます。
• 別途見積もる費用：データ移行費とセキュリティテスト費も別に確認します。
• 保守費：初期開発費の年10〜20％程度を暫定的な予算の目安にします。
• 契約条件：障害対応の時間帯、修正優先度、リリース頻度、SLAを契約書に明記します。

保守費には、依存パッケージの更新と脆弱性対応が含まれます。ブラウザ検証やアクセシビリティ、文書の更新、利用チームからの問い合わせも、同じ保守費に入れます。

破壊的変更を伴うメジャー更新の改修枠も、あらかじめ確保しておきます。

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

会社を選ぶ際は、Stencil.jsの利用実績を見るだけでは足りません。Web Componentsや複数フレームワークへの接続、デザインシステムを、一つの提案で説明できるかを見ます。さらに、CI/CDやアクセシビリティ、画面移行、長期保守まで、提案に含まれているかを確かめます。

技術者の経験に加えて、社内で共通部品を使い続ける仕組みを設計できるかも問われます。

StencilJSとWeb Componentsの実績の確認

StencilJS、一般的なWeb Components、単一フレームワークのUI開発について、実績を分けて示してもらいます。部品数やアプリ数、対応フレームワークに加え、配布方法やSSR、試験、保守期間も確かめます。比べる観点は、非公開実績、支援形態、体制選択、契約確認の4つです。

• 非公開実績：匿名構成図、テスト項目、納品物サンプルも比較材料になります。
• 支援形態：受託開発、人材支援、設計支援では発注側の負担が異なります。
• 体制選択：社内に責任者がいるなら人材支援も合います。要件整理から移行、教育、運用まで任せる場合は、一括請負が必要です。
• 契約確認：契約主体、再委託、コードの権利、OSSライセンス、終了後の引き継ぎを確認します。

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

RFPには、対象アプリや使うフレームワーク、部品数、ブラウザを記載します。SSRやプリレンダリングのほか、デザインやトークン、権限、フォームなどの要件も盛り込みます。アクセシビリティや性能目標、配布先、CI/CD、運用体制も明記します。

• 開発成果物：ソース、設計書、API仕様、トークン、文書サイト、テストコード、視覚回帰画像、CI設定。
• 運用成果物：CHANGELOG、SBOM、脆弱性手順、移行ガイド、教育資料、引き継ぎ資料。

「共通部品を作る」だけで終わらせず、何画面へいつ移行するかも対象範囲に含めます。納品物や検収条件、追加変更の単価は、同じ表にして比べます。

保守・ガバナンスの提案内容

共通部品の変更は、利用しているすべてのアプリに影響する可能性があります。そのため、提案の段階で、運用の取り決めまで示してもらいます。

会社を比べるときは、Stencilの名称だけでなく、発注後に自社で運用できるかを評価します。提案では、変更の手順、保守条件、自社運用、将来の移管まで示してもらいます。

• 変更管理：承認者、互換性確認アプリ、回帰テスト、非推奨期間、緊急ロールバック。
• 保守条件：月次の依存関係更新、脆弱性通知、ブラウザのサポート方針、問い合わせ応答時間、メジャー更新支援を明記します。
• 自社運用：部品追加の教育や設計レビュー、文書更新の責任、社内チームへの権限移管がなければ、専門家への依存が残ります。
• 将来の移管：内製化や別会社への切り替えを想定した契約にします。

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

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

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

Stencilは、Web標準を使いますが、安全性やアクセシビリティは、採用しただけで保証されるわけではありません。

依存パッケージや公開範囲、CI権限、秘密情報などの扱いを、部品の入力値や外部API、利用者の操作環境と合わせて要件にします。

依存関係と開発パイプラインの保護

脆弱性の監視やロックファイルの管理、SBOMの用意を行い、依存更新も進めます。さらに、最小権限を守り、CIの秘密情報は分けて扱います。監査ログとレビューも行います。守りの範囲は、公開依存、継続監視、個人情報、RFPの4つに分けて考えます。

• 公開依存：パッケージ名のなりすましや依存関係の乗っ取りも確認します。
• 継続監視：OSSでも開発パイプラインを監視します。
• 個人情報：入力部品と保存・送信するバックエンドを分け、委託先の安全管理を確認します。
• RFP：匿名化、権限、TLS・CSP、ログ、バックアップ、報告期限を記載します。

2024年の公開アドバイザリには、StencilのCIワークフローの脆弱性と、その修正履歴が記載されています（出典：Stencilに関する公開セキュリティアドバイザリ、2024年）。

個人情報保護委員会のガイドラインは、委託契約や取扱状況の把握、再委託の管理についても示しています（出典：個人情報保護委員会「個人情報保護法ガイドライン（通則編）」）。

キーボード操作とスクリーンリーダーの検証

共通部品に誤りがあると、同じ不具合が多くの画面へ広がります。そのため、フォーカス移動やEscキー、Tab順を試験します。ラベルとエラーの関連、コントラスト、拡大表示、スクリーンリーダーの読み上げも、部品と業務画面の両方で確かめます。

WAICは2026年6月にWCAG 2.2日本語訳の更新を案内し、JIS X 8341-3の改正検討にも触れています（出典：WAIC「WCAG 2.2 日本語訳 更新のお知らせ」、2026年）。

公共性の高いサービスや大企業向けのシステムでは、契約前に達成レベルと対象ブラウザを決めておくと、認識違いを防げます。試験方法と改善期限も、あわせて決めておく必要があります。

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

現場の入力ルールや画面の差分を調べないまま共通化すると、状態や権限の違いによって個別拡張が増えます。そのため、作成後の採用と更新のルールも欠かせません。

• 部品選定：利用頻度が高く差分の少ない部品を選び、業務担当者と仕様をレビューします。
• 更新管理：カタログ、オーナー、リリースノート、サポート期間、例外申請を整えます。
• 引き継ぎ：コード、設計判断、テスト、配布権限、環境構築を複数人が再現できるようにします。

よくある質問（FAQ）

採用の可否は、部品数とあわせて、利用アプリ数やフレームワーク、SSR要件、運用体制、将来の移行計画から判断します。

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

Stencilは、業務システム全体ではなく、主に共通の画面部品やデザインシステムを構築する技術です。データベースや業務ロジック、認証は、別途設計が必要です。権限やAPI、データ移行、クラウド基盤も、別に設計する必要があります。

フロントエンドの共有基盤として位置づけると、役割と費用を分けて整理できます。

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の設計、実装、統合によって決まります。テストや配布、教育、保守も費用に含まれます。発注前には、費用の目安、共通基盤の金額、見積比較、運用準備、採用判断の5点を整理します。

• 費用の目安：PoCは100万〜300万円、小〜中規模は500万〜1,500万円です。
• 共通基盤：複数チームでは1,500万〜4,000万円程度を初期検討の起点にします。
• 見積比較：別費用を分け、アプリ数、運用組織、品質、移行範囲をそろえます。
• 運用準備：API承認者、破壊的変更、テスト条件、担当交代後の保守を明文化します。
• 採用判断：複数フレームワークへの配布需要と継続運用の可否を確認します。

▼関連記事一覧
・Stencilのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・Stencilのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・Stencilのシステム開発の見積相場や費用/コスト/値段について
・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を創業。