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

Storybookのシステム開発は、既存UIの洗い出し、代表部品でのPoC、RFPによる条件整理の順に進めると、運用できるUI開発基盤につながります。

発注形態、要件整理と契約、費用相場、委託先の選び方を順に決めていきます。全体像はStorybookのシステム開発の完全ガイドもご覧ください。

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

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

Storybookシステムの概要

Storybookは、ボタンや入力フォームなどのUI部品を本体から切り離し、状態ごとに表示できる開発環境です。

販売管理や顧客管理は処理せず、業務画面の開発、共通化、レビューを支えます。

業務システム本体との違い

業務システム本体とStorybookは、役割が次のように異なります。

• 業務システム本体：顧客情報、受注、在庫、請求、権限、承認、会計連携などを扱う役割です。
• Storybook：画面の見た目や振る舞いを扱い、入力エラー、検索結果ゼロ、通信中、権限なしの状態も確認できます。

本番のデータ処理は置き換えません。一方で、画面の状態を早く共有でき、手戻りの削減に役立ちます。

デザインシステムとの役割の違い

デザインシステムは、色、余白、文字の決まりを共有する設計体系です。部品や命名、アクセシビリティ、利用ルールも含みます。一方で、Storybookはその実装部品を動かし、仕様書やテストの入口にできます。

Figmaのデザインと実装を並べてレビューするなら、両者のどこまでを誰が受け持つかをRFPに明記しておきます。

Storyだけに限定しない発注範囲

発注範囲には、設定や文書、テスト、公開、導入後の運用までを含めます。

• 設定と文書：Story、`.storybook/main.ts`、`preview`、MDXまたはAutodocsが対象です。
• 検証と公開：アクセシビリティ、操作、Visual Regressionのテストに加えて、CIとレビュー用の公開先を整えます。
• 運用ルール：Story追加者、廃止時のタグ付け、Storybookの更新バージョンを、あらかじめ定めます。

これらを決めておくと、導入後も使える基盤になります。

Storybook 10はESM-onlyへ移行しました。

公開配布物も整理され、公式はStorybook 9よりインストールサイズを29％削減したと案内しています（出典：Storybook公式「Storybook 10」、2025年10月）。

設定やプリセットもESM形式にそろえる必要があります。そのため、CommonJS中心の既存環境では、Node.js、アドオン、CIの互換性を先に検証します。

Storybookの発注形態の選び方

発注形態は、OSSと自社CI、Chromaticなどのクラウド、デザインシステムを含む個別設計に分けられます。

小規模な検証はOSS、多チームの差分レビューはクラウドが候補になります。

権限、監査、データ保管を重視する大規模組織では、セルフホストやEnterpriseも比べます。

OSSとセルフホストで小さく始める方法

React、Vue、Angular、Svelte、Web Componentsのいずれの既存環境にも導入でき、代表部品10〜20個から始められます。

`storybook build`で静的サイトを作れば、GitHub Pages、Netlify、Vercel、AWS S3などへ公開できます。

公開先と権限を細かく決められます。一方で、更新、アドオンの互換性、CI障害、ベースラインの保守は、自社か委託先が担います。

Chromaticなどのクラウド利用

Pull RequestごとにUI差分やアクセシビリティ、レビュー履歴を確認したい場合は、Chromaticなどが候補になります。

• Free：2026年時点で月額0ドル、5,000 billed snapshotsです。
• Starter：月額179ドルで、35,000 billed snapshotsを含みます。
• Pro・Enterprise：Proは月額399ドルで85,000 billed snapshots。Enterpriseは個別見積もりです。
• 使用量：Story数、ビルド回数、ブラウザ数、テーマやビューポートによって増減します。
• TurboSnap：変更ファイルで対象を絞ります。見積時には、ブランチ、頻度、ブラウザ、保存期間を確認します。

EnterpriseではSSO、カスタムGit連携、SLA、データ保持などを含む構成を選べます（出典：Chromatic公式Pricing、2026年8月確認）。

クラウドを使う場合も運用は必要で、何を差分として承認するかは社内ルールで定めます。

デザインシステムまでの個別設計

複数プロダクトでUIを共通化するなら、Figmaのデザイントークンや実装部品に加えて、社内ポータル、権限、リリース手順まで整えます。

命名規則や部品の責任者、採用・廃止や変更通知も設計できます。ただし、対象が広いほど期間と費用は増えます。最初は、重複が多く再利用効果の高い部品から選びます。

Storybookの発注・外注の進め方

まずUI開発の課題、対象部品、成果指標を決めて、候補会社に相談します。

目的と前提をそろえておくと、技術方式、工数、運用方法の提案を受けたときに、見積を比べやすくなります。

目的と既存UIの洗い出し

課題は、UI再利用やデザイン差分の削減、回帰検知、アクセシビリティ改善、非エンジニアのレビューに分けます。

既存の画面数やフレームワークを確かめ、共通部品と重複部品を一覧にします。壊れやすい部品、状態、個人情報の有無も洗い出します。

現状を把握しないまま全画面を対象にすると、Story作成の工数が膨らみます。さらに、使われないカタログになりやすいです。

RFPの成果物と受入条件

RFPには、前提と成果条件を記したうえで、必須要件と希望要件を分けて書きます。

• 前提情報：背景や対象、利用者、既存フレームワーク、部品数と状態、デザイン、テスト、CI、公開、時期、予算を書きます。
• 成果と受入条件：主要20部品、PRごとの操作・a11yテスト、レビューURLでの差分承認を示します。
• 必須要件：フレームワーク、命名、テーマ、権限、匿名サンプル、CI通知、公開制御の条件を定めます。
• 希望要件：複数ブラウザのVisual Test、Figma連携、SSO、詳細なカバレッジは、必須とは別に扱います。

希望要件は、PoCで効果と費用を確かめてから広げます。

5〜10個の代表部品によるPoC

PoCでは、ButtonやInputに加えて、問題が起きやすい部品を選びます。たとえば、次のような部品が候補になります。

• 権限差のあるTable：利用者の権限によって表示がどう変わるかを見ます。
• 入力エラーのあるForm：入力時の表示を確かめます。
• 状態のある一覧：ローディングと空の表示を見ます。
• フォーカス制御のあるモーダル：操作したときの振る舞いを検証します。

同じサンプルデータとシナリオを候補会社へ渡し、Storyの粒度や作成時間を比べます。さらに、テストが失敗を検出できるか、デザイナーがレビューしやすいかも確かめます。

成果物は、設定ファイルと代表Storyです。AutodocsまたはMDX、CI設定、運用手順、残課題一覧も含めます。

既存コードを大きく作り直さずに導入できるか、チームがStoryを更新できるかを確かめます。

テストの失敗を改善に生かせるかを検証します。そのうえで、本導入で設定やStoryを再利用できるかを、契約前に確認します。

CI接続と運用責任

Storybook 9では、Storyを起点に、操作、アクセシビリティ、Visual Test、カバレッジを組み合わせる流れが強化されています（出典：Storybook公式「Introducing Storybook 9」、2025年）。

CIでの検査範囲と、更新・承認の担当者は、あらかじめ決めておきます。

• Story単位：状態を確認するStorybookテストをCIで実行します。
• 業務フローと本番：ページ間のE2Eテストや本番監視とは、役割を分けて扱います。
• 運用担当：Story追加者、デザイン変更時の更新者、Visual差分の承認者を置きます。
• 保守ルール：違反の修正期限や部品の廃止手順です。

なお、Storybookテストは、本番ログインから請求完了までを確かめるE2Eテストの代わりではありません。実装とStoryを同時に更新し、週次またはリリース単位で未更新Storyと失敗テストを確認すると、カタログが古くなるのを防げます。

Storybookの契約形態の選び方

現状分析やRFP支援、PoCと、仕様確定後の設定・Story・CI実装では、作業の性質が異なります。そのため、前者は準委任、後者は請負を基本に分けます。

契約形態を選ぶのと同時に、成果物、前提、変更方法、保守範囲を明記することが重要です。

調査・設計・伴走に向く準委任契約

準委任は、専門家として調査、設計、開発支援、レビュー、伴走を行い、稼働時間や役務に対して対価を払う契約です。部品の洗い出しやStory粒度、Figma対応、テスト方針のように、進めながら決める工程に向きます。

完成画面数で成果を固定しにくい場合は、週次報告やレビュー記録、決定事項、次週計画を確認の単位にします。

完成条件を定められる工程の請負契約

請負は、成果物の完成と検査を前提にする契約です。そのため、対象と検収条件を具体的に定めます。

• 成果物：対象30部品の通常・エラー・空状態のStory、Autodocsの公開、CIのVitest実行、レビュー環境の構築を、契約に明記します。
• 検収条件：指定Storyの表示やテストの実行、権限のない情報がないことを確かめます。
• 変更管理：前提外の変更、追加見積の方法、承認者を契約書などに記載します。

既存コードの品質やデザイン変更が前提から外れると、完成条件を維持できない場合があります。命名やAPIモックが未確定の段階では、対象外の条件、追加見積の方法、承認者を定めておきます。

工程ごとの準委任と請負の組み合わせ

要件の不確実さに応じて、工程ごとに契約形態を組み合わせます。

• 現状分析・PoC：準委任で進め、要件が不明な段階で一括請負にすることを避けます。
• 本導入：PoCの結果をもとに、設定、Story、CI構築を請負で進めます。
• 公開後：更新や相談は、月次の準委任か保守契約で扱います。

請負を細かく分けすぎると、画面間の整合やデザイン変更への対応が遅れます。そのため、責任者を一人に決めておきます。

契約では、知的財産権やソースと設定の引き渡し、再委託を確認します。

秘密保持、個人情報、クラウドの保管条件も含めて確かめます。

障害対応の時間、更新、アドオンの互換性、解約時のデータ返却を定めます。あわせて、自社でStoryやデザイントークンを更新できるかを確認します。

Storybookのシステム開発費用の相場

Storybook単体に一律の開発価格はありません。既存環境やStory数、設計の工数をもとに見積もります。テストやCI、公開、保守の工数も含めて考えます。

以下の金額は、人日単価を5万〜10万円程度と仮置きし、リサーチノートの想定工数から算出した目安です。人月単価、コード品質、状態数、デザイナーの参加範囲によって変わるため、確定価格ではありません。

小規模PoCの費用目安

設定、既存部品10〜20個のStory、基本CI、簡単な運用手順を対象にすると、50万〜150万円程度です。期間は2〜4週間で、10〜30人日程度を想定します。

Figmaのトークン整理や複数フレームワーク、認証付き環境、大幅なUI改修は、別途加算されます。

標準導入の費用目安

30〜80部品を対象に、トークン、MDXまたはAutodocs、操作・アクセシビリティテスト、公開環境、CI、運用ルールを整えます。

費用は300万〜800万円程度、期間は2〜4か月、60〜160人日程度が目安です。ただし、部品の状態が多い場合や、既存画面からの共通部品の抽出が重い場合は、上限を超えることがあります。

大規模導入で800万〜2,000万円以上の費用目安

100部品以上の規模で、複数プロダクトやUI移行、複数フレームワークが対象になります。加えて、SSOや権限、監査、社内ガバナンスも含まれます。

費用は800万〜2,000万円以上、期間は4〜9か月以上となる可能性があります。この推定は、デザインシステム、移行、管理、テスト、教育、保守準備を含む場合のものです。

運用費と業務システム本体費用の区別

運用費は、ホスティング、保守、クラウド利用、業務システム本体に分けて見積もります。

• セルフホスト：アクセス量、ビルド回数、認証、ログ保存によって変わり、月数百円〜数万円程度と推定されます。
• 保守委託：初期費用の年10〜20％程度を比べる目安にしつつ、対応時間と改修上限を明記します。
• Chromatic：月額料金に加えて、スナップショットの使用量が別途かかります。

保守では、Story追加、更新、互換性の確認、デザイン変更、CI障害対応の範囲を定めます。

Storybook導入費は、受注、請求、在庫、顧客データを扱う業務システム本体の開発費とは別です。そのため、機能、API、データ移行、外部連携、非機能要件は、別工程で見積を依頼します。

委託先の選定と見積比較の確認事項

委託先は、部品設計、デザインシステム、コード移行を扱えるかを確認します。テストやCI、公開、運用ルールについても、対応範囲を確かめます。

公開情報に技術名があっても、自社と同じ複雑さの画面を担当したとは限りません。そのため、提案時に対象範囲と担当実績を具体的に聞いておきます。

Storybook以外の設計・テスト能力

Storybookの設定に加えて、実装からテスト、公開までの対応力を確認します。

• 設計・実装：React、Vue、Next.js、TypeScript、デザイントークン、Figma連携の対応範囲を見ます。
• テスト・公開：Vitest、Playwright、axe-core、GitHub Actions、認証付き静的公開への対応を確かめます。
• 業務画面の理解：APIやモック、権限による表示の違いを、デモで示してもらいます。
• 運用実例：代表Story、失敗画面、差分承認、Story廃止の決まりを見ます。

株式会社Gaji-LaboはStorybook駆動開発や導入支援を公開情報で扱っています。技術領域は、React・Vue・Next.js・Nuxt.js・TypeScript、アクセシビリティなどです。

株式会社シナップはデザインシステムの開発・導入支援を案内しています。

公開情報は候補を絞る材料です。そのうえで、担当者、案件規模、保守範囲への対応は、提案時に確認します。

公開事例の成果と役割

公開事例では、Storybook構築とデザインシステム運用のどこを担当したかを確認します。

• デザインシステム：Figmaのルール、部品の運用、内製化の支援までを見ます。
• 事例の適用性：既存コード、チーム体制、公開範囲を照らし合わせます。
• 大規模・内製化支援：Figma公式サービスパートナーとしての支援や、複数プロダクトでの経験を見ます。

株式会社LYZONは、2026年3月に自社UI部品カタログとしてStorybookを公開したと案内しています（出典：LYZON公式ニュース、2026年3月）。

株式会社ゆめみはデザインシステム構築と内製化支援を公開していますが、Storybookの対応範囲は個別に確認が必要です。

事例は、知名度よりも担当範囲、成果物、技術、引き継ぎ、稼働後の支援で比べます。

同じ前提での見積書の比較

作業項目を分けたうえで、同じ前提のもとに工数や受入条件を比べます。

• 内訳：要件定義、調査、UIの洗い出し、設定、Story、デザイン連携、テスト、CI、公開、教育、管理、保守に分けます。
• 比較条件：工数、単価、部品数、状態数、前提、対象外、納期、検収条件を各社でそろえます。
• 導入一式：Story数、エラー・空状態、既存部品の改修が含まれるかを確認します。
• CI構築一式：PR実行、失敗通知、対象ブラウザ、差分承認、再実行、ログ保存が含まれるかを見ます。

金額だけでなく、発注後に追加費用が生じる条件も明らかにします。

見積条件に入れるセキュリティとアクセシビリティ

セキュリティとアクセシビリティの範囲を、見積条件と受入条件に含めます。

• 情報保護：実データやAPIキーは成果物に含めず、修正版、秘密情報、CI、公開認証を確認します。
• アクセシビリティ：自動検査に加えて、キーボード、スクリーンリーダー、色覚、利用者による確認を分けて扱います。
• 法適用：EU向けサービスでは、欧州アクセシビリティ法が2025年6月28日から適用されました（出典：欧州委員会、2025年）。
• 対象地域：進出先があれば、法務や品質基準を委託先とすり合わせます。

2025年12月の勧告は、影響を受けるバージョンで、秘密入りの`.env`がある場所から静的ビルドしてWeb公開すると、環境変数が混入する条件を示しています。

対策には、修正版への更新、秘密情報のローテーション、CIでの変数管理、公開先認証を含めます（出典：Storybook公式Security advisory、2025年12月）。

Storybook公式ドキュメントは、a11yテストでWCAG違反の検出を支援できる一方、自動検査だけで全課題を保証するものではないと説明しています。

Storybookのシステム発注でよくある質問

発注時には、技術的な導入可否に加え、既存環境、運用負担、費用、セキュリティを確認します。

既存のReactやVueにStorybookを後から導入できますか？

導入できます。既存のフロントエンドに追加し、再利用効果の高い部品からStory化します。

依存パッケージ、ビルド方式、テーマ、APIモック、CSS設定に差があると、調整が必要になります。そのため、最初に5〜10個の代表部品でPoCを行います。

Storybookを導入すればUI品質は自動的に上がりますか？

自動的には上がりません。そのため、誰がどの状態のStoryを書くか、CIでテストを必須にするかを定めておきます。

Visual差分の承認者と、デザインと実装の変更を同期する方法を決めておくと、品質改善につながります。

Storybook 9のカバレッジやa11y機能は、未テストの状態を見つける補助です。業務フローや本番監視の代わりにはなりません。

社内限定のStorybookを公開しても問題ありませんか？

公開方式とデータを設計すれば可能です。ただし、実データ、個人情報、APIキー、秘密の環境変数は、Storyや成果物に含めません。

匿名化したモックを使い、SSO、VPN、Basic認証、IP制限のなかから要件に合う方式を選びます。あわせて、公開前の成果物検査と、Storybookやアドオンの更新責任者も決めておきます。

Storybookの導入費用と期間はどれくらいですか？

PoC・標準・大規模では対象範囲が異なるため、費用と期間を分けて見ます。

• 小規模PoC：50万〜150万円程度、2〜4週間です。
• 標準導入：300万〜800万円程度、2〜4か月です。
• 大規模導入：800万〜2,000万円以上、4〜9か月以上となる場合があります。

金額は、Story数や状態、設計によって変わる、推定のレンジです。テスト、CI、公開の範囲でも変わります。移行や保守の範囲も影響します。

正式な金額は、同じRFPとサンプルデータを渡したうえで、作業項目と対象外をそろえた見積を比べて決めます。

まとめ

Storybookの発注では、業務システム本体とUI基盤を分けて考え、対象画面と部品の状態を定めます。

OSS・セルフホスト、クラウド、デザインシステムを含む個別設計のなかから、公開範囲や体制に合う方式を選びます。

発注前にRFPへ書く内容

RFPには、目的、対象、フレームワーク、部品数と状態、Figmaを記します。成果物やテスト、CIも書き添えます。さらに、公開、セキュリティ、納期、保守の条件も書きます。

5〜10個の代表部品でPoCを行うと、本導入の範囲を決めやすくなり、不要な全画面移行を避けられます。同じサンプルと受入条件を委託先へ渡せば、提案を比べられます。

費用だけでなく運用後の責任

費用の目安は規模ごとのレンジを起点に、対象範囲をそろえて判断します。

• 小規模PoC：50万〜150万円です。
• 標準導入：300万〜800万円です。
• 大規模導入：800万〜2,000万円以上です。
• 運用責任：Story更新、差分承認、脆弱性、アクセシビリティ、Storybookの更新、終了時の引き継ぎを確認します。

実装とStoryを更新し続けられる委託先を選ぶことが、Storybookの定着につながります。

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

▼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を創業。