システムの開発を外注するとき、セキュリティの要件を「委託先にお任せ」にしていませんか。

要件定義書に書かれていない対策は、見積もりにも設計にも入りません。公開してから「その対策は契約に入っていません」と言われるのは、よくある行き違いです。

この記事は、社内にセキュリティの専任者がいない会社で、システムやアプリの発注を担当する方に向けて書いています。

IPA（情報処理推進機構）の「非機能要求グレード」のセキュリティ項目をもとに、何を決めて、どう書けば委託先に伝わるのかを、記入例つきで解説します。

セキュリティ要件は「対象・要件・目標値・確認方法・根拠」の5点で書きましょう！

まず、要件定義で決めることと、書き方の例を一覧で示します。

表の「書き方の例」は、本記事が考え方を示すために作った例です。推奨値ではないため、扱う情報や予算に合わせて決めてください。

引用元：IPA「システム構築の上流工程強化（非機能要求グレード）紹介ページ」 https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html

セキュリティ要件定義とは｜機能要件・非機能要件との関係

システムに求めることは、大きく「機能要件」と「非機能要件」に分かれます。

機能要件は「会員登録ができる」「請求書を出力できる」のように、システムが何をするかを決めるものです。非機能要件は、性能や使い続けやすさ、安全性など、機能をどの水準で提供するかを決めるものです。

セキュリティ要件は、主に非機能要件の一部として扱われます。ただし、ログイン画面や権限の設定画面のように、機能として作るものも含まれます。

デジタル庁の「政府情報システムにおけるセキュリティ・バイ・デザインガイドライン」は、セキュリティ要件定義で求められることを「システムで満たすべきセキュリティの状態が、機能面、非機能面ともに定義されていること」としています。

引用元：デジタル庁「政府情報システムにおけるセキュリティ・バイ・デザインガイドライン（DS-200）」 https://www.digital.go.jp/resources/standard_guidelines

なぜ発注者が書くのか

委託先は、要件定義書と見積もりに書かれた範囲で作ります。書かれていない対策は、作られないか、あとから追加費用になります。

デジタル庁の同じガイドラインは、企画の段階からセキュリティの方針を決めておくことで、致命的な対策漏れによる上流工程への手戻りを防げ、納期の確保やセキュリティのコスト低減につながると説明しています。

個人情報を扱うシステムでは、法律上の理由もあります。個人情報保護法第25条は、個人データの取扱いを委託するときに、委託先を「必要かつ適切」に監督することを求めています。

個人情報保護委員会のガイドラインは、その具体的な内容として、適切な委託先の選定、委託契約の締結、委託先での取扱状況の把握の3つを挙げています。

引用元：個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」3-4-4 委託先の監督 https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/

「何を守るか」と「どの水準まで守るか」は、発注者が決めて文書に残すものです。

AIで作ったアプリ・社内ツールのセキュリティ診断

公開して大丈夫か、第三者の目で確認します

• AIで作ったアプリを公開してよいか判断できない
• 社内にセキュリティを見られる担当者がいない
• 鍵やデータベースの権限設定が正しいか確認してほしい

八木（Last Scene）

AIで作ったアプリや社内ツールの診断に加えて、取引先からのセキュリティ要求への対応や、インシデント発生時の初動整理もご相談いただけます。
「このまま公開して大丈夫？」の一問からどうぞ。

セキュリティ顧問の詳細を見る

非機能要求グレードの「E セキュリティ」とは

非機能要求グレードは、発注者と開発者の間で非機能要求の認識の行き違いを防ぐために、IPAがまとめたツール群です。

非機能要求を「可用性」「性能・拡張性」「運用・保守性」「移行性」「セキュリティ」「システム環境・エコロジー」の6つの大項目に整理し、項目ごとに要求の水準をレベルで選べるようにしています。

セキュリティはこのうちの「E」にあたり、E.1からE.11までの11の中項目に分かれています。

E.11の項目（E.11.1.1 セキュリティインシデントの対応体制）は、2018年版の改訂で新しく加わったものです。IPAは、標的型攻撃のように完全に防ぐことが事実上できない攻撃があるため、インシデントは起こるものとして、早期発見と早期対処の体制を決める項目を追加したと説明しています。

引用元：IPA「非機能要求グレード2018 改訂情報」 https://www.ipa.go.jp/archive/files/000072716.pdf

なお、非機能要求グレードの事業は2018年度で終了していますが、資料は紹介ページから今も入手できます。この記事の項目名やレベルは、2018年版の「項目一覧」と「樹系図」にもとづいています。

経営側の枠組みとの関係

経済産業省とIPAの「サイバーセキュリティ経営ガイドライン Ver3.0」は、経営者がセキュリティ担当の責任者に指示すべき「重要10項目」をまとめたものです。

その付録のチェックシートには、「システム設計時にリスクアセスメントを行い、必要なセキュリティ機能を具体化し、開発時に実装している」という項目があります。セキュリティ要件定義は、この項目を実際の発注に落とし込む作業ともいえます。

同じチェックシートは、各項目を米国NISTの「サイバーセキュリティフレームワーク（CSF）」の項目と対応づけています（対応づけはCSFの旧版1.1が基準です）。

引用元：経済産業省「サイバーセキュリティ経営ガイドラインと支援ツール」 https://www.meti.go.jp/policy/netsecurity/mng_guide.html

NISTのCSFは、2024年2月に2.0が公開されました。対策を「統治（Govern）」「識別」「防御」「検知」「対応」「復旧」の6つの機能で整理していて、統治は2.0で新しく加わりました。

引用元：NIST「NIST Releases Version 2.0 of Landmark Cybersecurity Framework」 https://www.nist.gov/news-events/news/2024/02/nist-releases-version-20-landmark-cybersecurity-framework

要件を書くときは、「防御」だけに偏っていないかを見直すと抜けに気づけます。ログ（検知）、事故時の連絡（対応）、バックアップ（復旧）まで入っているかを確かめましょう。

決める11項目｜非機能要求グレードE.1〜E.11を発注者の言葉に直す

ここからは、11の中項目を5つのまとまりに分けて、発注者が決めることを説明します。

項目一覧には、項目ごとに「レベル0（対策なし）」から段階的に強くなる選択肢が書かれています。全部を最高レベルにする必要はなく、システムに合わせて選ぶ道具です。

AIで作ったアプリ・社内ツールのセキュリティ診断

公開して大丈夫か、第三者の目で確認します

• AIで作ったアプリを公開してよいか判断できない
• 社内にセキュリティを見られる担当者がいない
• 鍵やデータベースの権限設定が正しいか確認してほしい

八木（Last Scene）

AIで作ったアプリや社内ツールの診断に加えて、取引先からのセキュリティ要求への対応や、インシデント発生時の初動整理もご相談いただけます。
「このまま公開して大丈夫？」の一問からどうぞ。

セキュリティ顧問の詳細を見る

前提・リスク分析（E.1・E.2）

E.1では、守るべき法令や社内規程、取引先から求められている基準があるかを確認します。項目一覧の例には、国内外の法律、プライバシーマークやISMSなどの認証、業界のガイドラインが挙がっています。

発注者が書くことは、次のとおりです。

• 個人情報を扱うか、扱うならどの種類か
• 取引先や業界から求められている基準があるか（取引先のセキュリティチェックシートなど）
• 社内の情報セキュリティ方針や規程があるか

E.2では、どの範囲で脅威を洗い出すかを決めます。レベルは「分析なし」「重要度が高い資産を扱う範囲、あるいは外部とつながる部分」「開発範囲」と段階が分かれています。

発注者は、守りたい情報（顧客の個人情報、取引データ、社外秘の資料など）と、それがどこに保存されるかを委託先に伝えましょう。脅威の洗い出しそのものは、委託先や専門家と一緒に行えます。

診断・パッチ（E.3・E.4）

E.3は、セキュリティ診断をするかどうかです。項目一覧では、ネットワーク診断、Web診断、DB診断の3つを分けて「実施の有無」を決めます。

診断は、公開前だけでなく運用中にも定期的に行うことを検討するよう、項目一覧の備考に書かれています。要件には「いつ」「どの範囲を」「誰が」診断するかまで書いておきましょう。

E.4は、公開後のリスクの見直しと、セキュリティパッチ（修正プログラム）の適用です。適用する範囲、方針、タイミングを決めます。

項目一覧は、パッチ適用の影響確認などは保守契約の内容として明記されることが望ましいとしています。開発の契約だけでなく、保守契約に何が入るかもあわせて確認しましょう。

認証・権限・暗号化（E.5・E.6）

E.5は、ログインと権限です。管理権限を持つ人と持たない人に分けて、認証を「1回」「複数回」「複数回、異なる方式で」のどれにするかを選びます。

パスワードに加えてスマートフォンのアプリなど別の方式でも確認する多要素認証は、この「複数回、異なる方式による認証」にあたります。

あわせて、役割ごとに使える機能と見られるデータを決めた「権限表」を作りましょう。OWASP Top 10:2025では、アクセス制御の不備（Broken Access Control）が1位に挙がっています。

引用元：OWASP「OWASP Top 10:2025」 https://owasp.org/Top10/2025/

E.6は、データの暗号化です。通信するデータと保存するデータのそれぞれについて、「暗号化しない」「パスワードなどの認証情報だけ暗号化」「重要な情報を暗号化」から選びます。

暗号の鍵をどう管理するかも、この項目に含まれます。

通信の暗号化は、OWASP ASVS 5.0でも、TLS1.2やTLS1.3のような推奨される最新のバージョンだけを有効にすることが求められています。

引用元：OWASP「Application Security Verification Standard 5.0.0」V12 Secure Communication https://github.com/OWASP/ASVS/blob/master/5.0/en/0x21-V12-Secure-Communication.md

IPAの「TLS暗号設定ガイドライン」は、サーバーの設定基準を3つに分け、特別な事情がなければ「推奨セキュリティ型」を採用するよう勧めています。付属のチェックリストは、構築を委託した先が設定を正しく行ったかの確認にも使えると説明されています。

引用元：IPA「TLS暗号設定ガイドライン」 https://www.ipa.go.jp/security/crypto/guideline/ssl_crypt_config.html

ログ・監視・ネットワーク・マルウェア・Web対策（E.7〜E.10）

E.7は、不正を見つけるためのログと監視です。ログを取るか、何年保管するか、どの範囲を監視するか、どのくらいの間隔で確認するかを決めます。

ログ保管期間の選択肢は、「6か月」「1年」「3年」「5年」「10年以上の有期」「永久保管」の6段階です。項目一覧の備考では、取得するログの例として、ログイン・ログアウトの履歴、操作ログ、通信ログ、データベースのログ、アプリケーションのログが挙がっています。

E.8は、ネットワーク対策です。不正な通信を遮断する制御、不正な通信の検知、大量の通信による停止（DoS攻撃など）への対策の有無を決めます。

E.9は、マルウェア対策です。対策の範囲、リアルタイムスキャン、定期的なフルスキャンの頻度を決めます。

クラウドのサービスだけで作る場合は、対象になるサーバーがあるかを委託先に確認しましょう。

E.10は、Webアプリ特有の対策です。安全な作り方（セキュアコーディング）やWebサーバーの設定による対策の強化と、WAF（Webアプリケーションファイアウォール）を入れるかどうかを決めます。

安全な作り方の拠り所としては、IPAの「安全なウェブサイトの作り方」が使えます。SQLインジェクションやクロスサイト・スクリプティングなど11種類の脆弱性について、根本的な対策と影響を減らす対策がまとめられ、巻末に実装状況を確かめるチェックリストも付いています。

引用元：IPA「安全なウェブサイトの作り方」 https://www.ipa.go.jp/security/vuln/websecurity/about.html

事故対応（E.11）

E.11は、セキュリティインシデントが起きたときに、早く見つけ、被害を小さくし、復旧するための体制です。項目一覧では、対応体制の有無を決めます。

発注者が要件に書いておきたいのは、次の3つです。

1. 委託先から発注者への連絡先と、第一報までの時間
2. 調査に必要なログを誰が保全するか
3. 原因と再発防止策を、いつまでにどの形で報告するか

運用を委託する場合は、保守契約にもこの3つを入れましょう。事故が起きてから決めようとすると、連絡や判断が遅れます。

書き方の型と記入例｜「対象・要件・目標値・確認方法・根拠」

項目が決まったら、1つずつ要件として文章にします。本記事では、次の5つをそろえる書き方をおすすめします。

1. 対象：どの画面、どの利用者、どのデータの話か
2. 要件：何をするか
3. 目標値：どの水準までか（回数、期間、バージョンなど）
4. 確認方法：受入れのとき、どうやって確かめるか
5. 根拠：なぜその水準にしたか（法令、取引先の基準、非機能要求グレードの項目など）

この5つの型は、本記事が整理したものです。国家サイバー統括室の「情報システムに係る政府調達におけるセキュリティ要件策定マニュアル」も、業務の整理からセキュリティ要件を決め、調達仕様書に記載例を使って書き込む手順を示しています。

引用元：内閣官房 国家サイバー統括室「情報システムに係る政府調達におけるセキュリティ要件策定マニュアル」（2025年7月1日） https://www.cyber.go.jp/pdf/policy/general/SBD_manual.pdf

あいまいな書き方と、伝わる書き方の比較

「適切に」「十分な」「安全に」のような言葉だけでは、委託先によって受け取り方が変わります。次の表は、あいまいな書き方を5つの型で書き直した例です。

右の列の数値や範囲は、書き方を示すための例です。自社の扱う情報、取引先の基準、予算に合わせて決めてください。

記入例テンプレート

要件定義書のセキュリティ節は、次のような表にまとめると、委託先との確認がしやすくなります。

「根拠」の列は、表が横に長くなるため、ここでは省きました。実際の要件定義書では、各行に「非機能要求グレード E.5.1.1」「取引先の基準 第○条」のように書き添えておくと、あとで水準を見直すときの判断材料になります。

AIで作ったアプリ・社内ツールのセキュリティ診断

公開して大丈夫か、第三者の目で確認します

• AIで作ったアプリを公開してよいか判断できない
• 社内にセキュリティを見られる担当者がいない
• 鍵やデータベースの権限設定が正しいか確認してほしい

八木（Last Scene）

AIで作ったアプリや社内ツールの診断に加えて、取引先からのセキュリティ要求への対応や、インシデント発生時の初動整理もご相談いただけます。
「このまま公開して大丈夫？」の一問からどうぞ。

セキュリティ顧問の詳細を見る

確認方法まで書く

要件に確認方法がないと、受入れのときに「できているか」を確かめられません。

OWASPのASVS（アプリケーションセキュリティ検証標準）は、使い道の1つとして、契約でアプリのセキュリティ検証要件を指定するための基礎を挙げています。発注者は「ASVSのレベルXで開発し、それを満たすことを示すこと」と求めることができる、と説明されています。

引用元：OWASP「Application Security Verification Standard」 https://owasp.org/www-project-application-security-verification-standard/ ／「ASVS 5.0.0 What is the ASVS?」 https://github.com/OWASP/ASVS/blob/master/5.0/en/0x03-What-is-the-ASVS.md

確認方法の書き方の例は、「診断報告書の提出」「設定画面の画面写真の提出」「受入れテストでの操作確認」「設計書での説明」などです。費用がかかるもの（第三者による診断など）は、誰が費用を持つかも書いておきましょう。

どこまで求めるか｜扱う情報と規模で決める

セキュリティ要件は、強くするほど開発と運用の費用が増えます。逆に弱すぎると、事故のときの被害が大きくなります。

サイバーセキュリティ経営ガイドラインも、自社の事業への影響を考えずに「厳し目の対策を定めればリスクは抑えられる」として計画を作ると、通常の業務に支障が出るおそれがあると指摘しています。

引用元：経済産業省・IPA「サイバーセキュリティ経営ガイドライン Ver3.0」 https://www.meti.go.jp/policy/netsecurity/downloadfiles/guide_v3.0.pdf

扱う情報で3段階に分ける

本記事では、最初の目安として、扱う情報で3つに分けて考えることをおすすめします。

この3段階は、本記事が独自に整理した目安です。業界の基準や取引先との契約で求められる水準があれば、そちらを優先してください。

非機能要求グレードのモデルシステムを参考にする

非機能要求グレードの「グレード表」では、社会への影響の大きさで3つのモデルシステムを置き、それぞれの重要な項目のレベルの例を示しています。セキュリティのいくつかの項目を抜き出すと、次のとおりです。

これは2018年版の例で、今のシステムにそのまま当てはめる値ではありません。自社のシステムがどれに近いかを考える目安として使いましょう。

引用元：IPA「非機能要求グレード2018」グレード表 https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html

国家サイバー統括室の要件策定マニュアルも、対策の強さを「低位」「中位」「高位」の3段階で表し、条件に応じて選ぶ形にしています。8つの対策区分に分けた対策要件ごとに、仕様書の記載例が用意されています。

同じマニュアルは、「中位」と「高位」のどちらにするか検討するとき、費用対効果の観点からできる限り「中位」の記載例を採用することが望ましいとしています。政府の調達向けの資料ですが、記載例は民間の要件定義書を書くときの参考になります。

引用元：内閣官房 国家サイバー統括室「情報システムに係る政府調達におけるセキュリティ要件策定マニュアル」 https://www.cyber.go.jp/pdf/policy/general/SBD_manual.pdf

OWASP ASVSのレベルの使い方（L1・L2・L3）

Webアプリの作り方の水準を決めるときは、OWASP ASVSの3つのレベルが使えます。最新版は2025年5月30日に公開された5.0.0です。

ASVSは、どのレベルにすべきかを一律には決めていません。扱う情報の重要度と利用者の期待に応じて組織が決めるもの、としています。

例として、限られた情報だけを扱う初期のスタートアップはL1から、銀行のオンラインバンキングはL3未満では説明が難しい、と書かれています。

引用元：OWASP「ASVS 5.0.0 What is the ASVS?」 https://github.com/OWASP/ASVS/blob/master/5.0/en/0x03-What-is-the-ASVS.md

やりすぎで費用が膨らむ例と、見積もりへの影響

すべての項目に最高レベルを書くと、委託先は対策の作業を見積もりに積み上げます。社内の数人だけが使うツールに、銀行と同じ水準を求める必要はありません。

逆に、要件を書かずに見積もりを取ると、委託先ごとに前提がばらばらになり、相見積もりで比べられなくなります。セキュリティ要件は、見積もりを依頼する前に固めておきましょう。

見積もりの見方は、システム開発の見積もりの見方で詳しく解説しています。

委託先との進め方｜RFP・見積もり・受入れ

要件を書いたら、提案依頼書（RFP）、契約、受入れの各場面で使います。

RFPに入れる文面

RFPには、要件の表に加えて、委託先に提案してほしいことを書きます。文面の例は次のとおりです。

• 別紙「セキュリティ要件一覧」の各項目について、対応方法と、対応できない項目があればその理由を記載してください
• 公開前の脆弱性診断の実施方法（自社で行うか、外部に依頼するか）と費用を、見積もりで分けて記載してください
• 開発・保守の体制と、再委託の有無を記載してください
• 公開後のセキュリティ更新とライブラリの更新を、保守契約のどこで扱うかを記載してください

委託先に確認する質問

経済産業省の経営ガイドラインは、委託先との関係で、契約書でセキュリティ対策の責任主体を明確にすることや、委託先がSECURITY ACTIONに取り組んでいるかを確認することを対策例に挙げています。

発注前には、次のような点を委託先に確認しておきましょう。

• 開発チームにセキュリティの責任者はいるか
• 脆弱性診断の実績と、診断を自社で行うか外部に依頼するか
• 再委託先があるか、ある場合は同じ要件を守らせるか
• 使っているライブラリに脆弱性が見つかったとき、誰が、いつまでに対応するか
• 個人データを扱う場合、どこに保存し、誰がアクセスできるか

IPAの「情報セキュリティ10大脅威 2026」では、組織向けの2位に「サプライチェーンや委託先を狙った攻撃」が入っています。

引用元：IPA「情報セキュリティ10大脅威 2026」 https://www.ipa.go.jp/security/10threats/10threats2026.html

受入れ時の確認と、運用開始後の見直し

受入れのときは、要件の表の「確認方法」の列を使って、1行ずつ確かめます。提出された診断報告書で指摘が残っていないか、残っている場合はいつまでに直すかを書面で確認しましょう。

IPAの「ウェブ健康診断仕様」は、13の診断項目を定めた簡易な診断の仕様です。ただしIPAは、検査パターンを絞った診断のため、脆弱性が見つからなくても安全の宣言にはならないと注意しています。

引用元：IPA「安全なウェブサイトの作り方」（別冊：ウェブ健康診断仕様） https://www.ipa.go.jp/security/vuln/websecurity/about.html

公開後は、E.4のリスクの見直しを、少なくとも年に1回など時期を決めて行いましょう。機能を追加したとき、扱う情報が増えたときも見直しのタイミングです。

AIで作る・AIを組み込むシステムで足す項目

最近は、AIを使ってアプリを作ったり、生成AIをシステムに組み込んだりする発注も増えています。この場合は、ここまでの11項目に加えて、次の点を要件に足しましょう。

APIキー・秘密情報の置き場所と、データベースの権限

AIのサービスや決済サービスのAPIキーは、ブラウザやアプリの中に置かず、サーバー側の安全な場所で管理することを要件に書きます。

データベースは、ログインした人が自分のデータだけを見られるように、権限の設定を必須にしましょう。

たとえばSupabaseの公式ドキュメントは、外部に公開されるスキーマのテーブルでは、すべてにRLS（行単位のアクセス制御）を有効にするよう求めています。RLSがないテーブルは、権限を与えられた役割から読み書きできてしまうためです。

引用元：Supabase「Row Level Security」 https://supabase.com/docs/guides/database/postgres/row-level-security

具体的な確認項目は、AIで作ったアプリの公開前セキュリティチェックリストにまとめています。AIを使って開発する側の設定は、Claude Codeのセキュリティ設定で解説しています。

生成AIに渡すデータと、OWASP Top 10 for LLM

生成AIをシステムに組み込む場合は、AIにどのデータを渡すか、外部のAIサービスに送ってよいデータはどれかを要件で決めます。

OWASPは、大規模言語モデル（LLM）を使うアプリのリスクとして「OWASP Top 10 for LLM Applications 2025」を公開しています。1位はプロンプトインジェクション、2位は機密情報の漏えいです。

引用元：OWASP Gen AI Security Project「LLM Top 10 for 2025」 https://genai.owasp.org/llm-top-10/

ほかにも、AIに与える権限が大きすぎる問題（Excessive Agency）や、利用量に上限がないことによる問題（Unbounded Consumption）が挙がっています。AIが実行できる操作の範囲と、利用量の上限も要件に入れましょう。

社内で生成AIを使うときのルールづくりは、生成AIの情報漏えい対策を参考にしてください。

よくある質問

小さなシステムでもセキュリティ要件は必要ですか

必要です。ただし、項目の数や水準はシステムに合わせて減らせます。

社内の数人だけが使うツールでも、ログインと権限、通信の暗号化、更新の方針は決めておきましょう。個人情報を扱うなら、管理者の多要素認証と操作ログを加えるのがおすすめです。

要件を自分で書けないときは、誰に頼めばよいですか

まずは、この記事の表を使って「守りたい情報」と「取引先から求められている基準」だけでも書き出してください。そのうえで、開発の委託先とは別の立場の専門家に見てもらうと、抜けや強すぎる要求に気づきやすくなります。

外部の専門家に相談するタイミングは、セキュリティ顧問が必要なタイミングで解説しています。

脆弱性診断の費用は、誰が持つものですか

決まりはないため、要件定義書と見積もりで明確にしておく必要があります。委託先が自社で診断する場合と、発注者が別の診断会社に依頼する場合があり、どちらにするかで見積もりの中身が変わります。

RFPで「診断の費用を分けて記載すること」と求めておくと、相見積もりで比べやすくなります。

取引先のセキュリティチェックシートとは、何が違いますか

取引先のチェックシートは、会社としての対策状況を確認するものです。セキュリティ要件は、これから作るシステムにどんな対策を入れるかを決めるものです。

ただし、取引先のチェックシートに「システムの通信を暗号化しているか」のような項目があれば、それはE.1の「守るべき基準」として要件に反映しましょう。

まとめ｜「何を守るか」を決めて、5つの型で書く

セキュリティ要件定義は、システムに入れる対策を発注者が決めて、委託先と同じ理解で文書に残す作業です。

IPAの非機能要求グレードのE.1〜E.11に沿って項目を洗い出し、「対象・要件・目標値・確認方法・根拠」の5つの型で書くと、抜けとあいまいさを減らせます。

水準は、扱う情報で決めましょう。すべてを最高レベルにする必要はなく、非機能要求グレードのモデルシステムやOWASP ASVSのレベルが目安になります。

まずは「守りたい情報」と「保存する場所」を1枚に書き出しましょう！

発注前のチェックリスト

1. 守るべき法令、取引先の基準、社内ルールを書き出した
2. 守りたい情報と保存場所を委託先に伝えた
3. 11項目それぞれについて、求める水準を決めた（不要な項目は理由を書いた）
4. 各要件に、受入れ時の確認方法を書いた
5. 脆弱性診断と公開後の更新を、誰がいつ行い、費用を誰が持つか決めた

要件定義全体の進め方は、システム開発の要件定義とは？進め方7ステップと要件定義書の書き方で解説しています。会社全体の対策から始めたい場合は、小さな会社のセキュリティ対策も参考にしてください。

株式会社Last Sceneは、システムの発注前のセキュリティ要件の整理から、受入れ時の確認、公開後の見守りまで、セキュリティ顧問として伴走しています。

要件定義書やRFPのセキュリティ部分を一緒に読み、非機能要求グレードのE.1〜E.11に照らして抜けている項目や強すぎる要求を洗い出すところから進めます。

「どこまで書けばよいか分からない」という段階でも、気軽にご相談ください。

AIで作ったアプリ・社内ツールのセキュリティ診断

公開して大丈夫か、第三者の目で確認します

• AIで作ったアプリを公開してよいか判断できない
• 社内にセキュリティを見られる担当者がいない
• 鍵やデータベースの権限設定が正しいか確認してほしい

八木（Last Scene）

AIで作ったアプリや社内ツールの診断に加えて、取引先からのセキュリティ要求への対応や、インシデント発生時の初動整理もご相談いただけます。
「このまま公開して大丈夫？」の一問からどうぞ。

セキュリティ顧問の詳細を見る