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

Storybookのシステムとは、業務システム本体ではなく、UIコンポーネントを切り離して開発・確認・文書化・テストするフロントエンド開発基盤です。発注では、Storybookの導入だけでなく、既存UIの棚卸し、Story作成、デザイン連携、CI、公開、運用ルールまでを範囲に含めることが成功の条件です。

この記事では、Storybookのシステム開発を発注・外注・依頼・委託したい担当者に向けて、発注形態の選び方、RFPと要件の整理、準委任・請負などの契約形態、2026年時点の費用相場、委託先選定と見積比較のポイントを解説します。小規模なPoCから複数プロダクトのデザインシステムまで、実際に何を決めてから相談すればよいかを順番に整理します。

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

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

Storybookは、ボタン、入力フォーム、モーダル、テーブルなどのUI部品をアプリケーション本体から分離し、状態ごとに表示できる開発環境です。発注者が理解しておきたいのは、Storybook単体が販売管理や顧客管理を処理する業務システムではなく、業務システムの画面を安定して作り、共通化し、レビューするための仕組みだという点です。

業務システム本体には、顧客情報、受注、在庫、請求、権限、承認、会計連携などのデータ処理があります。一方、Storybookが扱う中心は、それらの業務を操作する画面の見た目と振る舞いです。例えば、受注管理画面の検索フォームをStorybookで表示し、通常状態だけでなく入力エラー、検索結果ゼロ、通信中、権限がない状態まで確認できます。データ処理の本番動作を置き換えるものではありませんが、画面の状態を早く共有できるため、手戻りの削減に役立ちます。

デザインシステムは、色、余白、文字、コンポーネント、アクセシビリティ、命名、利用ルールなどを組織で共有する設計体系です。Storybookは、その設計を実装したコンポーネントを動く状態で見せ、仕様書やテストの入口にできます。つまり、デザインシステムがルールと共通言語を含む考え方で、Storybookは実装・文書化・検証のための器です。FigmaのデザインとStorybookの実装を並べてレビューする場合も、両者の責任範囲をRFPに書いておく必要があります。

発注範囲には、Storyファイルの作成だけでなく、`.storybook/main.ts`などの設定、`preview`のテーマやデコレーター、MDXまたはAutodocsによる文書、アクセシビリティ・操作・Visual Regressionのテスト、CIでのビルド、レビュー用の公開先を含めます。さらに、誰がStoryを追加するか、コンポーネントを廃止するときにどうタグ付けするか、Storybookをどのバージョンへ更新するかまで決めて初めて、導入後も使える基盤になります。

バージョン選定も発注条件に含めます。Storybook 10はESM-onlyへ移行し、公開配布物を整理してStorybook 9よりインストールサイズを29％削減したと公式に案内されています。一方で、設定ファイルやプリセットをESM形式へそろえる必要があるため、CommonJS中心の既存プロジェクトではNode.js、アドオン、CIの互換性を先に検証します（出典：Storybook公式「Storybook 10」、2025年10月）。

Storybookの発注形態はどれを選ぶとよいですか？

発注形態は、OSSのStorybookを自社CIで運用する方法、StorybookとChromaticなどのクラウドサービスを組み合わせる方法、デザインシステムや社内ポータルまで個別設計する方法に分けて考えます。小さく効果を確かめるならOSSと既存CI、複数チームで差分レビューを回すならクラウド、大規模組織で権限・監査・データ保管を重視するならセルフホストやEnterpriseを比較します。

既存のReact、Vue、Angular、Svelte、Web ComponentsのプロジェクトにStorybookを追加し、Button、Input、Modal、Tableなど10〜20個の代表コンポーネントから始める方法です。`storybook build`で静的サイトを生成し、GitHub Pages、Netlify、Vercel、AWS S3などへ公開できます。ホスティングとCIを自社で管理するため、公開先やアクセス権を細かく決められる一方、バージョン更新、アドオンの互換性、CI障害、ベースラインの保守を自社または委託先が担います。

Pull RequestごとにStorybookをビルドし、UIの差分、アクセシビリティ、レビュー履歴をチームで確認したい場合は、Chromaticなどのクラウドサービスが候補です。Chromatic公式の2026年時点の公開料金は、Freeが月額0ドルで5,000 billed snapshots、Starterが月額179ドルで35,000、Proが月額399ドルで85,000です。Enterpriseは個別見積もりで、SSO、カスタムGit連携、SLA、データ保持などを含む構成です。出典はChromatic公式Pricing（2026年8月確認）です。

ただし、Visual Testの使用量はStory数、ビルド回数、ブラウザ数、テーマやビューポートの組み合わせで増減します。Chromaticは変更ファイルに応じて対象を絞るTurboSnapを案内していますが、見積時には対象ブランチ、実行頻度、ブラウザ範囲、スナップショットの保存期間を確認します。クラウドを選べば運用が不要になるのではなく、何を差分として承認するかという社内ルールが必要です。

複数の業務システムやプロダクトで同じUIを使い、Figmaのデザイントークン、実装コンポーネント、社内ポータル、権限、リリース手順まで統一したい場合は、デザインシステムの構築を含めて委託します。Storybookの設定だけを外注するより、命名規則、コンポーネントの責任者、採用・廃止のルール、変更通知の流れまで設計できますが、対象が広い分だけ期間と費用も増えます。最初から全画面を対象にせず、重複が多く再利用効果の高い部品を選ぶことが安全です。

Storybookの発注・外注はどのように進めますか？

発注では、いきなり「Storybookを導入したい」と伝えるより、UI開発のどこに困っているかを整理し、対象部品と成果指標を決めてから候補会社へ相談します。発注者が目的と前提をそろえ、委託先には技術方式と工数、運用方法を提案してもらう形にすると、会社ごとの見積を同じ土俵で比較できます。

まず、Storybookで解決したい課題を「UIの再利用」「デザインと実装の差分削減」「リグレッション検知」「アクセシビリティ改善」「非エンジニアを含むレビュー」のように分けます。次に、既存画面の数、フロントエンドのフレームワーク、共通部品、重複部品、頻繁に壊れる部品、状態の種類、個人情報の有無を一覧にします。現状が分からないまま全画面を対象にすると、Storyを作る工数だけが膨らみ、使われないカタログになりやすいです。

RFPには、背景、対象プロダクト、利用者、既存フレームワーク、Storybookの対象コンポーネント数、対応する状態、デザインデータ、テスト方式、CI、公開範囲、希望時期、予算の考え方を記載します。「Storybookを導入する」という機能名だけではなく、「主要20部品を状態別に確認できる」「PRごとに操作テストとa11yテストを実行する」「デザイナーがレビュー用URLで差分を承認できる」のように成果で表現します。

必須要件と希望要件も分けます。必須要件には、対象フレームワークへの対応、Storyの命名、テーマ切替、権限、個人情報を含まないサンプルデータ、CIの失敗通知、公開先のアクセス制御などを置きます。希望要件には、複数ブラウザのVisual Test、Figma連携、SSO、詳細なカバレッジレポートなどを置き、PoCで効果と費用を確かめてから広げます。

PoCでは、ButtonやInputだけでなく、実際に問題が起きやすい部品を選びます。例えば、権限によって表示が変わるTable、入力エラーを持つForm、ローディングと空状態を持つ一覧、モーダルのフォーカス制御などです。候補会社には同じサンプルデータとシナリオを渡し、Storyの粒度、作成時間、テストの失敗検出、デザイナーのレビューしやすさを確認します。

PoCの成果物には、設定ファイル、代表Story、AutodocsまたはMDX、CI設定、簡単な運用手順、残課題一覧を含めます。PoCの目的は本番と同じ完成品を作ることではなく、既存コードを大きく作り直さずに導入できるか、チームがStoryを更新できるか、テストの失敗を業務上の改善につなげられるかを確かめることです。PoC後に本導入へ移行する際、設定やStoryを再利用できるかも契約前に確認します。

Storybook 9では、Storyを起点にインタラクション、アクセシビリティ、Visual Test、カバレッジを組み合わせる流れが強化されています（出典：Storybook公式「Introducing Storybook 9」、2025年）。ただし、Storybookテストは本番のログインから請求完了までを確認するE2Eテストの代わりではありません。Story単位の状態確認、ページ間の業務フロー、本番監視を分け、CIでどのテストを必須にするかを決めます。

運用では、Storyの追加責任者、デザイン変更時の更新者、Visual差分の承認者、アクセシビリティ違反の修正期限、コンポーネントの廃止手順を決めます。Storybookは導入しただけで品質を保証する仕組みではなく、実装とStoryを同時に更新するルールがあって効果を発揮します。週次またはリリース単位で未更新Storyと失敗テストを確認する場を設けると、カタログの陳腐化を防ぎやすいです。

Storybookの契約形態はどのように選びますか？

Storybookの外注では、上流の現状分析・RFP支援・PoCと、仕様が固まった設定・Story・CIの実装で性質が異なります。要件が変化する工程には準委任、成果物と検収条件を明確にできる工程には請負を基本にし、必要に応じて工程を分けます。契約形態だけで安全性が決まるのではなく、成果物、前提、変更方法、保守範囲が具体的に書かれていることが重要です。

準委任契約は、委託先が専門家として調査、設計、開発支援、レビュー、チーム伴走を行い、稼働時間や役務に対して対価を支払う契約です。既存コンポーネントの棚卸し、Storyの粒度の検討、Figmaとの対応付け、テスト方針の整理など、作業を進めながら答えが具体化する工程に向いています。成果を「何画面完成」だけで固定しにくい場合は、週次の作業報告、レビュー記録、決定事項、次週計画を成果の確認単位にします。

請負契約は、合意した成果物の完成と検査を前提にする契約です。例えば、対象コンポーネント30個、各コンポーネントの通常・エラー・空状態のStory、Autodocsの公開、CIでのVitest実行、レビュー環境の構築というように、対象と完成条件を具体化できる工程に向いています。検収では「Storybookが起動する」だけでなく、指定したStoryが表示され、テストが実行され、権限のない情報が含まれないことを確認します。

請負で注意したいのは、既存コードの品質やデザイン変更が前提から外れたときの扱いです。共通部品の命名が途中で変わる、APIのモック仕様が決まっていない、Figmaのデザインが更新されるといった状況では、当初の完成条件を維持できない場合があります。対象外となる変更を定義し、追加作業の見積方法と承認者を契約書や変更管理票に記載します。

現実的には、最初の現状分析とPoCを準委任で行い、PoCの成果をもとに本導入の設定・Story作成・CI構築を請負で発注し、公開後の更新と相談を月次の準委任または保守契約にする形が使いやすいです。こうすると、要件が不明確な段階で完成責任を一括して固定するリスクを抑えられます。反対に、すべてを細かい請負に分けすぎると、画面間の整合性やデザイン変更への対応が遅れるため、責任者を一人に決めます。

契約では、知的財産権、ソースコードと設定ファイルの引き渡し、再委託、秘密保持、個人情報、利用するクラウドのデータ保管、障害対応の時間帯、Storybookのバージョン更新、アドオン互換性、解約時のデータ返却を確認します。特に、委託先が作成したStoryやデザイントークンを自社で更新できるかは、将来のベンダーロックインを左右します。

Storybookのシステム開発費用と相場はいくらですか？

Storybook単体の公表された一律の開発価格はなく、既存フロントエンドへの導入、Storyの数、デザインシステムの範囲、テスト、CI、公開、保守に必要な工数から見積もります。以下の金額は、フロントエンドエンジニアの5万〜10万円程度の人日単価を仮置きし、リサーチノートの想定工数から算出した目安です。人月単価、既存コードの品質、コンポーネントの状態数、デザイナーの参加範囲で変わるため、確定価格ではありません。

Storybookの設定、既存コンポーネント10〜20個のStory作成、基本的なCI、簡単な運用手順を対象にする小規模PoCは、50万〜150万円程度、期間は2〜4週間が一つの目安です。10〜30人日程度の作業を想定したレンジで、Figmaのデザイントークン整理、複数フレームワーク、認証付きのレビュー環境、既存UIの大幅な改修は別途加算されます。

30〜80コンポーネントを対象に、デザイントークン、MDXまたはAutodocs、操作テスト、アクセシビリティテスト、レビュー用の公開環境、CI、運用ルールまで整備する標準導入は、300万〜800万円程度、期間は2〜4か月が目安です。60〜160人日程度の作業を想定したレンジで、コンポーネントごとの状態数が多い場合や、既存画面から共通部品を抽出する作業が重い場合は上限を超えることがあります。

100コンポーネント以上、複数プロダクト、既存UIの棚卸しと移行、複数フレームワーク、SSOや権限、監査、社内運用ガバナンスまで対象にする場合は、800万〜2,000万円以上、期間は4〜9か月以上になる可能性があります。160〜400人日程度の作業を仮置きしたレンジであり、Storybookの利用料だけではなく、デザインシステム設計、移行、プロジェクト管理、テスト環境、教育、保守準備が含まれる場合の費用です。

セルフホストの場合、GitHub Pages、Netlify、Vercel、AWS S3などのホスティングとCI利用料は、アクセス量、ビルド回数、認証、ログ保存によって月数百円〜数万円程度の推定です。Story追加、Storybookのバージョン更新、アドオン互換性の確認、デザイン変更、CI障害対応まで委託するなら、保守費として初期費用の年10〜20％程度を比較軸に置き、対応時間と改修上限を見積書へ明記します。

Chromaticを使う場合は、前述の月額料金とスナップショット使用量が別に発生します。また、Storybookの導入費と、受注・請求・在庫・顧客データを処理する業務システム全体の開発費は別物です。業務システム本体の機能開発、API、データ移行、外部連携、非機能要件まで含める場合は、Storybookのレンジに合算せず、別工程として見積を依頼します。

委託先の選定と見積比較では何を確認しますか？

委託先は「Storybookを使ったことがある」という一言だけでなく、コンポーネント設計、デザインシステム、既存コード移行、テスト、CI、公開、運用ルールまで扱えるかを確認します。開発会社の公開情報で技術名が見つかっても、自社の業務画面と同じ複雑さを担当したとは限らないため、提案時に対象範囲と担当実績を具体的に聞くことが必要です。

確認する技術領域は、Storybookの設定だけでは不十分です。React、Vue、Next.js、TypeScriptなどのフロントエンド実装、デザイントークン、Figma連携、VitestやPlaywright、axe-coreによるアクセシビリティ、GitHub ActionsなどのCI、認証付きの静的サイト公開を一連で説明できる会社を選びます。業務システムのAPIやモック、権限による表示差分を理解しているかも、デモで確認します。

候補会社には、代表的なStoryファイル、テスト失敗時の画面、Visual差分の承認フロー、Storyを廃止するルールを見せてもらいます。株式会社Gaji-LaboはStorybook駆動開発や導入支援、React・Vue・Next.js・Nuxt.js・TypeScript、アクセシビリティなどを公開情報で扱っています。株式会社シナップはデザインシステムの開発・導入支援を案内しています。公開情報は候補を絞る材料であり、担当者や案件規模、保守範囲まで対応できるかは提案時に確認します。

デザインシステムの実績を重視する場合は、Storybookそのものの構築だけでなく、Figmaのルール、コンポーネントの運用、内製化支援まで見ます。株式会社LYZONは2026年3月に自社UIコンポーネントカタログとしてStorybookを公開したと案内しており、デザイン原則と実装カタログの連携を確認する際の参考になります（出典：LYZON公式ニュース、2026年3月）。ただし、自社案件へ同じ方式を適用できるかは、既存コード、チーム体制、公開範囲を照合して判断します。

大規模なデザインシステムや内製化を重視する場合は、Figma公式サービスパートナーとしての支援や、複数プロダクトの開発経験を確認します。株式会社ゆめみはデザインシステム構築・内製化支援を公開していますが、Storybookの具体的な対応範囲は個別に確認する必要があります。会社名の知名度ではなく、担当範囲、成果物、利用技術、引き継ぎ方法、稼働後の支援を比較します。

見積書では、要件定義、現状調査、UI棚卸し、設定、Story作成、デザイン連携、テスト、CI、公開、教育、プロジェクト管理、保守を分けて記載してもらいます。各項目の工数、単価、対象コンポーネント数、状態数、前提条件、対象外、納期、検収条件をそろえると、安い見積が作業抜けによるものか、効率化によるものかを見分けやすくなります。

例えば「Storybook導入一式」と書かれている場合は、何個のStoryを作るのか、エラーや空状態を含むのか、既存コンポーネントの改修を含むのかを質問します。「CI構築一式」なら、Pull Requestごとの実行、失敗時の通知、Visual Testの対象ブラウザ、ベースライン承認、再実行、ログ保存まで確認します。金額だけでなく、発注後に追加費用が生まれる条件を見積書の段階で明らかにします。

社内限定の業務画面をStorybookで公開する場合は、実データやAPIキーを静的成果物へ含めないことが最優先です。Storybook公式の2025年12月のセキュリティアドバイザリでは、影響を受けるバージョンで、秘密情報を含む`.env`ファイルがあるディレクトリから静的ビルドし、Webへ公開した場合に環境変数が成果物へ混入する条件が示されています。修正版への更新、秘密情報のローテーション、CIでの環境変数管理、公開先の認証を見積と受入条件に含めます。出典はStorybook公式Security advisory（2025年12月）です。

アクセシビリティでは、axe-coreによる自動検査で検出できる範囲と、キーボード操作、スクリーンリーダー、色覚、実際の利用者による確認を分けます。Storybook公式ドキュメントは、a11yテストでWCAG違反の検出を支援できる一方、自動検査だけで全課題を保証するものではないと説明しています。EU向けサービスでは2025年6月28日から欧州アクセシビリティ法の適用が始まったため、対象地域がある場合は法務・品質基準も委託先と確認します。出典は欧州委員会（2025年）です。

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

Storybookの発注では、技術的な導入可否だけでなく、既存システムへの影響、運用負担、費用、セキュリティがよく質問されます。ここでは、外注前に確認しておきたい代表的な疑問へ直接回答します。

導入できます。Storybookは既存フロントエンドへ追加し、最初はButton、Input、Modal、Tableなど再利用効果の高い部品を選んでStory化する方法が一般的です。ただし、依存パッケージ、ビルド方式、テーマ、APIモック、CSSのグローバル設定に差異があると調整が必要になるため、最初に5〜10個の代表部品でPoCを行います。

自動的に上がるわけではありません。Storyを誰がどの状態まで書くか、テストをCIで必須にするか、Visual差分を誰が承認するか、デザイン変更と実装変更をどう同期するかを決めて運用することで、品質改善につながります。Storybook 9のカバレッジやa11y機能も、未テストの状態を見つける補助であり、業務フロー全体や本番監視の代替ではありません。

公開方式とデータの扱いを設計すれば可能です。実データ、個人情報、APIキー、秘密の環境変数をStoryや静的成果物へ入れず、匿名化したモックデータを使い、SSO、VPN、Basic認証、IP制限などから自社の要件に合う方式を選びます。公開前にビルド成果物を検査し、Storybookとアドオンを修正版へ更新する責任者も決めます。

小規模PoCなら50万〜150万円程度で2〜4週間、標準導入なら300万〜800万円程度で2〜4か月、大規模導入なら800万〜2,000万円以上で4〜9か月以上が目安です。いずれもStoryの数、状態、デザインシステム、テスト、CI、公開、移行、保守を含む範囲によって変わる推定レンジです。正式な金額は、同じRFPとサンプルデータを渡し、作業項目と対象外をそろえて見積比較します。

まとめ

Storybookのシステムを発注するときは、業務システム本体の開発とUI開発基盤の導入を分け、どの画面やコンポーネントをどの状態まで整備するかを決めることが出発点です。OSS・セルフホスト、Chromaticなどのクラウド、デザインシステムを含む個別設計を比較し、自社の公開範囲、チーム体制、テスト方針、運用能力に合う方式を選びます。

RFPには、導入目的、対象プロダクト、既存フレームワーク、部品数、状態、Figma、Storyの成果物、テスト、CI、公開方式、セキュリティ、納期、保守を記載します。まず5〜10個の代表部品でPoCを行い、その成果を使って本導入の範囲を決めると、不要な全画面移行を避けられます。委託先には同じサンプルと受入条件を渡し、提案内容の違いを比較します。

費用は、小規模PoCの50万〜150万円程度、標準導入の300万〜800万円程度、大規模導入の800万〜2,000万円以上というレンジを起点にし、Story数と状態、テスト、公開、移行、保守の前提を合わせて判断します。最後に、Storyの更新者、差分の承認者、脆弱性修正、アクセシビリティ改善、バージョンアップ、契約終了時の引き継ぎまで確認します。導入して終わりではなく、実装とStoryを更新し続けられる委託先を選ぶことが、Storybookのシステムを定着させるポイントです。

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

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。