URSとは？LIMS導入の要求仕様書｜書き方と無料テンプレート

URS（ユーザー要求仕様書：User Requirements Specification）とは、システムを導入する側（ユーザー）が、「システムに何をしてほしいか」を整理して文書にしたものです。
LIMS（ラボ情報管理システム）に限らず、ERPやMES、分析機器や製造設備の導入でも使われる、システム導入の出発点となる文書です。

LIMSの導入を検討し始めたとき、最初に直面するのが「要件をどう整理すればいいのか」という壁です。
ベンダーに直接相談しても要望をうまく伝えられなかったり、見積りの前提がずれていたり――そうしたトラブルを防ぐ鍵がURSです。

この記事では、URSの意味と位置づけ、記載する項目、良いURSの書き方、作成の進め方まで、実務者の視点で解説します。
記事の中ほどでは、LIMS向けに作った URSテンプレート（Excel） を無料でダウンロードできます。
前提となるLIMSの仕組みは、こちらでまとめて解説しています。

URSとは？「ユーザー要求仕様書」の意味

URSは、日本語では「ユーザー要求仕様書」と訳されます。
また、厚生労働省の「コンピュータ化システム適正管理ガイドライン」では、単に「要求仕様書」とも呼ばれています。

ポイントは、URSが「ユーザー側が書く文書」だという点です。
ベンダーが「こう作ります」と示す文書ではなく、導入する側が「こうなってほしい」を示す文書です。
そのため、システムの中身がどう作られるか（設計）ではなく、業務として何が必要か（要求）を記載します。

URS・RFP・要件定義書・FS・DSの違い

システム導入では、似たような名前の文書がいくつも登場します。
これらを「誰が書くか」「何のために書くか」で整理すると、次のように分かれます。

文書	書く人	目的	作る時期
URS（ユーザー要求仕様書）	ユーザー	システムに求めることを整理し、社内とベンダーの共通認識にする	導入検討の初期
RFP（提案依頼書）	ユーザー	URSを添えて、複数ベンダーに提案と見積りを依頼する	製品・ベンダー選定時
要件定義書	ベンダー（ユーザーと合意）	URSをもとに「何を作るか」を確定させる	契約後の要件定義工程
FS（機能仕様書）	ベンダー	要件をシステムの機能として具体化する	設計工程
DS（設計仕様書）	ベンダー	機能をどう実装するかを設計する	設計工程

LIMS導入では、URS作成 → RFP発行 → ベンダー提案・見積り → 要件定義書の合意という順で進むのが一般的です。
URSは、この流れ全体の「最初の一歩」にあたります。

システム導入におけるURSの位置づけ（V字モデル）

URSは、設計・構築・検証のすべての起点になります。
この関係を表すのが、システム導入やバリデーションでよく使われる「V字モデル」です。

左側で仕様を段階的に具体化し、右側でそれぞれの仕様どおりにできているかを検証します。
URSは左上の起点にあり、最後の受入テストで「要求どおり使えるか」を確かめるときの基準になります。
つまり、URSに書いていないことは、最後まで検証されません。

なお上の図は対応関係の典型例で、覚え方としては便利ですが、必ずこうしなければならないと決まっているわけではありません。
大事なことは、URSに書いた要求の一つひとつが、いずれかの検証で確かめられ、その対応関係を後から追えることです。

市販のLIMSを設定して使う場合は、段階を細かく分けず「URS → 受入テスト」とまとめることもよくあります。
検証をどのような形にするかは、ベンダーと早い段階ですり合わせておくと手戻りがありません。

規制産業ではCSV（バリデーション）の起点になる

製薬などGxP（GMP・GLP等）の対象となる業務では、コンピュータ化システムが意図どおりに動くことを文書で証明するCSV（コンピュータ化システムバリデーション）が求められます。
URSは、そのCSVの一連の文書の最初に位置づけられます。

業界標準のガイドである GAMP 5（第2版・2022年）では、システムをソフトウェアの種類（カテゴリ）とリスクに応じて分類し、URSの詳しさもそれに合わせて変える考え方を取っています。
市販のLIMSパッケージを設定して使う場合（カテゴリ4）は、細かい実装方法までは書かず、「業務として何が必要か」を中心に書けば十分です。
一方、独自開発が入る部分（カテゴリ5）は、要求をより具体的に書く必要があります。

なぜURSが必要なのか

LIMSを導入する際、多くの企業がつまずくのが「要件の整理」です。
「どんな機能が必要か」「誰がどのデータを扱うのか」が曖昧なままベンダーに相談すると、提案が的外れになったり、必要な機能が抜けていたり、稼働後に「思っていたのと違う」となるリスクが高まります。

実際の導入現場でよく起きるのは、次のようなすれ違いです。
営業段階でコストを抑えるために一部の要件を「対象外」として口頭で合意し、導入が始まってからその要件が復活する。
すると追加費用の根拠がないため、言った言わないの議論となり、ユーザーとベンダーの双方が消耗します。
URSがあれば、何が対象で何が対象外かが文書として残るため、こうした事態を防げます。

URSをきちんと作成しておくと、次のような効果があります。

• ベンダーからの提案や見積りの精度が上がる
  要件が明確になるため、機能の抜け漏れや過剰提案を防げる。
• 複数製品を同じ土俵で比較できる
  同じURSに対する各社の回答を並べれば、機能の充足度と費用を公平に比べられる。
• 要件定義以降の手戻りが減る
  構築中に「想定していなかった処理が必要」となるリスクを減らせる。
• 社内の合意形成がスムーズになる
  関係部署の要望をまとめた文書として、意思決定の根拠になる。
• 検証（テスト）と監査の根拠になる
  URSの各項目がPQの合格基準になり、査察で「なぜこの仕様にしたか」を説明できる。

URSはERPやMESなどシステム導入全般で用いられる文書ですが、ラボのシステムでは「試験データ」「分析機器」「帳票」「トレーサビリティ」など、現場特有の観点を盛り込むことがポイントです。

URSに記載する項目（章立てとLIMSでの記入例）

上の画像は、当サイトのテンプレートの「機能要件」シートの記載例です。
要求ごとに番号（ID）・カテゴリ・優先度を付けて一覧にしています。
URSの構成は企業によって異なりますが、LIMSの場合は次の10項目で整理すると抜け漏れが起きにくくなります。

項目	書く内容	LIMSでの記入例
1. 背景・目的	現状の課題と、導入で実現したい姿	紙記録の転記ミスをなくし、試験成績書を依頼から3日以内に発行する
2. 対象範囲（スコープ）	どの業務・どのデータを対象にするか、しないか	対象：試験依頼〜報告書発行、試薬・標準品管理。拠点1、品質管理部、製品A 対象外：安定性試験の統計解析。拠点2、研究開発部、製品B
3. 業務要件	現状と導入後の業務の流れ、担当者と役割	試験依頼→受付→試験→結果入力→承認→報告のフローと、各段階の担当部門
4. 機能要件	入力・処理・出力に分けて必要な機能	入力：試験依頼、試料情報 処理：合否判定、承認ワークフロー 出力：試験成績書、傾向グラフ
5. データ要件	扱うデータの種類、マスタ、保存期間、監査証跡	試験項目・規格値・試料種別のマスタ。記録は5年保存。変更履歴を残す
6. 連携（インターフェース）要件	分析機器や他システムとの接続	HPLC・天秤の測定値を自動取込。ERPと試料情報を連携
7. 非機能要件	性能・セキュリティ・可用性・使いやすさ	同時利用20名、画面応答3秒以内、権限は部門・役割ごとに設定、日次バックアップ
8. 規制・法令要件	準拠すべき規制と、それに伴う機能	GMP、21 CFR Part 11、ER/ES指針、ALCOA++に基づく監査証跡・電子署名
9. 運用・保守要件	稼働後の運用体制、教育、保守、障害対応	マスタ変更は品質保証部門が承認。障害時は翌営業日までに一次回答
10. プロジェクト条件	納期、予算、体制、成果物、教育	稼働目標は来年4月。予算上限、担当者、受け入れテストの実施者

特に見落とされやすいのが、2の「対象外」の明記と、5・6・10の項目です。
機能要件は自然と書けても、データの保存期間や機器連携、成果物は後から出てきて手戻りになりがちです。

なお機器連携の考え方は LIMS機器連携の記事 で、規制対応は データインテグリティの記事 で詳しく解説しています。
まだご覧になられていない方は、併せてご覧ください。

URSテンプレート（Excel）の無料ダウンロード

上記の10項目に沿って、LIMS向けに項目と記入例をあらかじめ入れたテンプレートです。
ゼロから書き始めるより、記入例を自社の言葉に置き換えていく方がはるかに早く仕上がります。
業務フロー図や機器リストなど、あわせて用意したい資料は ベンダー相談前に準備すべき5つの資料 にまとめています。

良いURSの書き方——5つのコツ

項目が揃っていても、書き方が曖昧だとURSは機能しません。
ベンダーが見積りに使え、後でテストの基準にもなる書き方には、いくつかのコツがあります。

コツ1：「測定できる・検証できる」表現で書く

「使いやすい画面」「高速に処理できる」といった表現は、人によって基準が違います。
数値や条件に置き換えて、できた・できないを第三者が判定できる形にします。

曖昧な書き方（NG）	検証できる書き方（OK）
使いやすい入力画面であること	1試料の結果入力が、画面遷移なしで完了すること
処理が速いこと	試験成績書のPDF出力が10秒以内に完了すること
データを安全に守れること	結果の修正時に、修正前の値・修正者・日時・理由が自動で記録されること
機器と連携できること	HPLC（製品名）の測定結果ファイルを、手入力なしでLIMSに取り込めること
帳票が出せること	現行の試験成績書（様式番号○○）と同じ項目・レイアウトで出力できること

コツ2：要求ごとにIDを振り、優先度を付ける

要求には「URS-F-001」のようにIDを振ります。
ベンダーの回答や、後のテスト項目とIDで紐づけられるため、どの要求が満たされたかを一覧で追跡できるようになります。
これをトレーサビリティといい、CSVでは必須の考え方です。

あわせて、各要求に優先度を付けます。
すべてを同じ重みで書くと、ベンダーは全部に対応する前提で見積もるため、費用が膨らみます。

• 必須（Must）：これがなければ導入の意味がない要求。規制要件はここに入る
• 推奨（Should）：あると業務が大きく改善する要求。標準機能で実現できるかをベンダーに確認する
• 任意（Could）：あれば便利だが、費用次第で見送れる要求。将来の拡張候補として残す
• 見送り（Won’t）：今回は対象外とする、あるいは運用や他システムで対応する

コツ3：「何が必要か」を書き、「どう作るか」は書かない

URSは要求の文書であり、設計の文書ではありません。
「○○というテーブルを持つこと」「画面のボタンは右上に置くこと」のような実現方法まで書くと、ベンダーの標準機能と合わず、不要なカスタマイズと費用を生みます。

市販のLIMSパッケージを使う場合は特に、「業務としてこうなってほしい」までを書き、実現方法はベンダーの提案に委ねるのが費用を抑えるコツです。
細かく書きすぎると、仕様変更のたびにURSから修正が必要になり、CSVの文書管理も重くなります。

コツ4：現状業務をそのまま写さない

現状の紙やExcelの運用を、そのままシステムの要求にしてしまうケースがよくあります。
しかしながら、現状の手順には「紙だから必要だった作業」が含まれています。
URSを書く前に業務フローを描き、導入後になくせる作業・変えるべき作業を洗い出しておくと、要求がすっきりします。
業務フローの整理方法は 業務フロー図の書き方 をご覧ください。

コツ5：規制要件は「根拠」とセットで書く

「監査証跡が必要」とだけ書くのではなく、「21 CFR Part 11 §11.10(e) に基づき、記録の作成・変更・削除の監査証跡を自動で残すこと」のように根拠を添えます。
査察のときに「なぜこの要求を置いたか」を説明でき、ベンダーも対応範囲を判断しやすくなります。

URS作成の進め方（5ステップ）

URSはユーザー側が作る文書ですが、担当者1人で書くものではありません。
現場・品質保証・IT・経営層の要望を集めて、優先度を付けながらまとめていきます。

作成期間の目安は、業務範囲や組織の規模によりますが、おおむね1〜3ヶ月です。
ヒアリングと社内の合意形成に時間がかかるため、余裕を持って計画してください。
導入全体の流れは LIMS導入の手順 で解説しています。

URS作成でよくある失敗と対策

これまでに多くのURSを見てきた経験から、つまずきやすいポイントを整理しました。
書き終えた後のセルフチェックにもお使いいただけます。

よくある失敗	何が起きるか	対策
機能要件ばかりで非機能要件が抜ける	稼働後に「遅い」「権限が細かく設定できない」が判明する	性能・権限・バックアップ・保存期間など非機能要件を必ず書く
対象外を書いていない	不要な機能が入り、無駄な費用が発生する	スコープに「対象外」の欄を設け、明示する
曖昧な表現が多い	ベンダーごとに解釈が異なり、見積りを比較できない	数値・条件・様式番号で書く（コツ1）
現状業務をそのまま写す	紙時代の無駄な手順がシステム化され、効果が出ない	先に業務フローを描き、なくせる作業を整理する（コツ4）
現場と経営層の要求が食い違う	プロジェクト途中で方針が揺れ、手戻りが増える	目的の章で「導入で実現したい姿」を先に合意する
規制要件の取り込みが甘い	査察で指摘され、稼働後に改修が必要になる	Part 11・ER/ES指針・ALCOA++の要件を根拠付きで書く（コツ5）
作って終わりにする	要件定義以降で変更が入ってもURSが更新されず、検証と食い違う	改訂履歴を設け、変更のたびに版を上げる

GMP・GxP環境でURSを書くときの注意点

製薬や医療機器など規制の厳しい業界では、URSは「あると便利な文書」ではなく、査察で提示を求められる文書になります。
一般的なURSに加えて、次の点を押さえてください。

• 電子記録・電子署名：米国の 21 CFR Part 11 や、国内の ER/ES指針（電磁的記録・電子署名の利用に関する指針）に基づく要件を明記する
• データインテグリティ：ALCOA++の原則（帰属性・判読性・同時性・原本性・正確性など）を満たすため、監査証跡・タイムスタンプ・変更理由の記録を要求する
• アクセス管理：データアクセス範囲、役割ごとの権限、パスワードポリシー、操作ログを要求する
• データの保存と復元：保存期間、バックアップ、アーカイブ、システム更新時のデータ移行を要求する
• バリデーションへの協力：IQ・OQの文書提供、サプライヤー評価への対応など、ベンダーに求める協力範囲を書く
• 文書管理：URS自体を承認・版管理し、変更管理の対象にする

これらは製薬だけの話ではありません。
食品のHACCP、化学のGLP、環境分析の公定法など、記録の信頼性が問われる業務ではすべて同じ考え方が当てはまります。
詳しくは データインテグリティとALCOA++の記事 もご覧ください。

まとめ：URSは「LIMS導入を成功させる地図」

URSは単なる文書ではなく、LIMS導入の成否を左右する設計図です。
要件が曖昧なまま進めると、構築途中で手戻りが発生し、納期やコストが膨らむリスクがあります。

一方で、URSをきちんと作っておけば、

• ベンダーとの認識が一致し、複数製品を公平に比較でき、
• プロジェクト全体がスムーズに進み、
• 検証と査察の根拠が残り、導入後の満足度も高くなります。

まずは テンプレート をダウンロードし、自社の現状を書き出してみてください。
途中で詰まった場合や、書いた内容を確認してほしい場合、当社にご相談いただくことも可能です。
今回の記事が皆さまのURS作成のお役に立てば幸いです。

URSに関するよくある質問

Q1. URSとは何ですか？

URSは “User Requirements Specification” の略で、日本語では「ユーザー要求仕様書」と呼ばれます。ユーザー（発注者）がシステムや装置に対して「何ができてほしいか」「どんな業務要件があるか」を整理した文書で、LIMS導入の最上流工程で作成する重要なドキュメントです。

Q2. URSにはどんな項目を記載しますか？

LIMSのURSでは、①背景・目的、②対象範囲（対象外も明記）、③業務要件、④機能要件（入力・処理・出力）、⑤データ要件（マスタ・保存期間・監査証跡）、⑥機器や他システムとの連携要件、⑦非機能要件（性能・セキュリティ・可用性）、⑧規制・法令要件（GMP／21 CFR Part 11 等）、⑨運用・保守要件、⑩プロジェクト条件（納期・予算・体制）の10項目で整理すると抜け漏れが起きにくくなります。

Q3. URSとRFP・要件定義書の違いは？

URSは「ユーザー視点で何を求めるか」を記した文書、RFP（提案依頼書）はベンダー向けに「提案してください」と依頼する文書、要件定義書はベンダーがユーザーと合意して「これを作ります」とまとめた文書です。LIMS導入では URS作成 → RFP発行 → ベンダー提案 → 要件定義書合意の順で進むのが一般的です。

Q4. URSは誰が作成しますか？

URSは原則として「ユーザー（発注者）側」が作成します。LIMS導入では、品質管理部門・分析ラボの現場担当者が中心となり、品質保証部門・IT部門・経営層と協議して作成するケースが多いです。社内リソースが足りない場合、LIMS導入支援コンサルタントが伴走する形で作成支援することもあります。

Q5. URS作成にはどのくらい時間がかかりますか？

業務範囲・組織規模によりますが、およそ1〜3ヶ月が目安です。中小規模ラボなら4〜6週間、大規模・複数拠点なら2〜3ヶ月が一般的です。ヒアリング・業務整理・社内合意形成に時間を要するため、十分なバッファを取ることが重要です。

Q6. URSの無料テンプレートはありますか？

当サイトではLIMS導入向けに最適化したURSテンプレート（Excel形式）を無料で配布しています。本記事の中ほどからダウンロード可能で、10項目の章立てと記入例付きのため、ゼロから書き始める負担を大幅に軽減できます。

Q7. URS作成で失敗しがちなポイントは？

主な失敗パターンは、①機能要件ばかり書いて非機能要件が抜ける、②対象外を明記していない、③曖昧な表現（例：使いやすいシステム）が多く後工程で揉める、④現状業務に引きずられ将来要件が反映されない、⑤現場と経営層の要件が整合しない、⑥GMP等の規制要件の取り込みが甘い、⑦作った後に更新しない、などです。「測定可能・検証可能」な表現で書き、改訂履歴を残すことを意識しましょう。

Q8. GMP/医薬品環境でのURSと一般的なURSの違いは？

GMP（医薬品製造管理及び品質管理基準）環境では、URSがコンピュータ化システムバリデーション（CSV）の起点として位置づけられ、21 CFR Part 11、ER/ES指針、データインテグリティ（ALCOA++）、監査証跡などの規制要件を明文化する必要があります。一般的なURSと比べ、規制対応・トレーサビリティ・電子署名・データ保管期間などの記述がより厳密になり、URS自体も承認・版管理の対象になります。

Q9. URSはどのくらい詳しく書けばよいですか？

市販のLIMSパッケージを設定して使う場合は、「業務として何が必要か」が分かる粒度で十分で、実現方法（設計）までは書きません。細かく書きすぎると不要なカスタマイズや、仕様変更のたびのURS改訂につながります。GAMP 5 では、ソフトウェアのカテゴリとリスクに応じて詳しさを変える考え方が示されています。

Q10. URSとFS（機能仕様書）・DS（設計仕様書）の関係は？

URSは「ユーザーが何を求めるか」、FSは「それをシステムのどんな機能で実現するか」、DSは「その機能をどう実装するか」を記した文書で、この順に具体化されます。V字モデルでは、URSはPQ（性能適格性確認）、FSはOQ（運転時適格性確認）、DSはIQ（据付時適格性確認）と対応づけるのが典型例です。ただしGAMP 5では、仕様と検証の段階数はシステムのリスクと複雑さに応じて決めてよいとされており、この対応は固定ではありません。

サポート内容と料金は サービスプラン一覧 をご覧ください。