---
title: "セキュアコーディングとは。開発会社に何を求めればよいか｜アメリア・テクノロジー株式会社"
url: https://www.ameliatechnology.co.jp/blog/secure-coding-requirements/
description: "セキュアコーディングとは、脆弱性を作り込まないようにプログラムを書くことです。IPAの「安全なウェブサイトの作り方」やOWASP Top 10などの基準、開発の段階ごとにすること、発注のときに要件や契約へどう書くかを説明します。"
updated: 2026-11-12
publisher: "アメリア・テクノロジー株式会社"
---
# セキュアコーディングとは。開発会社に何を求めればよいか

セキュアコーディングとは、脆弱性を作り込まないようにプログラムを書くことです。IPAの「安全なウェブサイトの作り方」やOWASP Top 10などの基準、開発の段階ごとにすること、発注のときに要件や契約へどう書くかを説明します。

2026.11.12 [Webとシステム開発](https://www.ameliatechnology.co.jp/blog/category/web/)

執筆 [石田誠](https://www.ameliatechnology.co.jp/blog/author/ishida/)（グループCTO）

Webとシステム開発（WEB & SYSTEMS）のコラム

## この記事の要点

- セキュアコーディングは、SQLインジェクションやクロスサイト・スクリプティングなど、よく知られた脆弱性を作り込まない書き方を、開発の決まりとして守ることです。
- 書き方だけでなく、要件と設計、レビュー、テストと診断、部品の更新まで、開発の各段階に守りを組み込むことが大切です。
- 発注するときは、参照する基準、レビューと診断のやり方、見つかった問題の直し方を、要件や契約に書いておきます。

[セキュアコーディング](https://www.ameliatechnology.co.jp/glossary/secure-coding/)とは、[脆弱性](https://www.ameliatechnology.co.jp/glossary/vulnerability/)を作り込まないようにプログラムを書くことです。よく知られた攻撃の手口に対する書き方の決まりを、開発の全員が守ることが中心になります。発注する側は、「セキュリティに配慮すること」とだけ書くのではなく、参照する基準、確かめ方、見つかった問題の直し方を、要件や契約に具体的に書いておくことが大切です。

## セキュアコーディングで防ぐこと

セキュアコーディングで防ぐのは、入力の扱いや権限の確かめ方の誤りから生じる脆弱性です。代表的なものに、データベースへの命令を書き換えられる[SQLインジェクション](https://www.ameliatechnology.co.jp/glossary/sql-injection/)や、ページに不正なスクリプトを埋め込まれる[クロスサイト・スクリプティング](https://www.ameliatechnology.co.jp/glossary/xss/)があります。

IPAの「安全なウェブサイトの作り方」は、Webサイトの開発者と運営者に向けて、よく知られた脆弱性と対策をまとめた資料です。IPAのページでは、次の脆弱性ごとに解説が設けられています。

- SQLインジェクション
- OSコマンド・インジェクション
- パス名パラメータの未チェック／ディレクトリ・トラバーサル
- セッション管理の不備
- クロスサイト・スクリプティング
- CSRF（クロスサイト・リクエスト・フォージェリ）
- HTTPヘッダ・インジェクション
- メールヘッダ・インジェクション
- クリックジャッキング
- バッファオーバーフロー
- アクセス制御や認可制御の欠落

運用の点検項目をまとめた「安全なウェブサイトの運用管理に向けての20ヶ条」も案内されています。

出典：[安全なウェブサイトの作り方（IPA）](https://www.ipa.go.jp/security/vuln/websecurity/index.html)

用語の短い説明は、用語集の[OSコマンドインジェクション](https://www.ameliatechnology.co.jp/glossary/os-command-injection/)、[ディレクトリトラバーサル](https://www.ameliatechnology.co.jp/glossary/directory-traversal/)、[CSRF](https://www.ameliatechnology.co.jp/glossary/csrf/)にもまとめています。

## 国際的によく使われる一覧

国際的には、OWASPの「OWASP Top 10」が、Webアプリケーションの主な危険を知るための資料としてよく使われています。2026年11月時点の最新は2025年版（OWASP Top 10:2025）で、次の10項目が挙げられています。

1. Broken Access Control（アクセス制御の不備）
2. Security Misconfiguration（セキュリティの設定の誤り）
3. Software Supply Chain Failures（ソフトウェアのサプライチェーンの失敗）
4. Cryptographic Failures（暗号の不備）
5. Injection（インジェクション）
6. Insecure Design（安全でない設計）
7. Authentication Failures（認証の不備）
8. Software or Data Integrity Failures（ソフトウェアやデータの完全性の不備）
9. Security Logging and Alerting Failures（記録と通知の不備）
10. Mishandling of Exceptional Conditions（例外的な状況の扱いの誤り）

かっこの中の日本語は、当社が内容を短く言い表したものです。書き方の誤りだけでなく、設計、設定、部品の管理、記録までが含まれている点が、セキュアコーディングを書き方だけの問題にしないための手がかりになります。

出典：[OWASP Top 10:2025（OWASP Foundation）](https://owasp.org/Top10/2025/)

## 開発の各段階で、何をするか

守りは、書く段階だけでなく、要件と設計、実装、テストと診断、運用の各段階に組み込みます。要件と設計の段階では、扱う情報の重さと、誰が何をできるかの権限を決めます。実装の段階では、書き方の決まりを守り、別の人がコードを確かめます。テストと診断の段階では、脆弱性を試し、見つかった問題を直します。運用の段階では、使っている部品に修正版が出たら当てます。

開発の各段階に組み込む守り

**要件と設計**：扱う情報の重さと、誰が何をできるかの権限を決める

**実装**：書き方の決まりを守り、別の人がコードを確かめる

**テストと診断**：脆弱性を試し、見つかった問題を直す

**運用**：使っている部品に修正版が出たら当てる

守りは**書く段階だけでなく**、各段階に組み込みます

### 要件と設計

扱う情報（個人情報、取引先の機密など）と、利用者の種類ごとにできる操作を、要件の段階で決めます。OWASP Top 10:2025 に「安全でない設計」が入っているように、作った後では直しにくい弱点は、設計の段階で防ぐことが大切です。ログインの方式、[多要素認証](https://www.ameliatechnology.co.jp/glossary/mfa/)の要否、記録する操作も、このときに決めます。

### 実装とレビュー

開発の会社やチームで、書き方の決まり（入力の扱い、データベースへの命令の組み立て方、出力のときの変換、エラーの表示のしかたなど）を文書にし、全員が同じ決まりで書きます。書いたコードは、書いた人とは別の人が[コードレビュー](https://www.ameliatechnology.co.jp/glossary/code-review/)で確かめます。ツールでコードを解析して、決まりに反する書き方を見つける方法もあります。

### テストと診断

公開する前に、脆弱性を試すテストを行います。重要なシステムや外部に公開するシステムでは、開発した会社とは別の立場からの[脆弱性診断](https://www.ameliatechnology.co.jp/glossary/vulnerability-assessment/)を受けることも検討します。診断の頼み方は、[脆弱性診断の頼み方と、報告書の読み方](https://www.ameliatechnology.co.jp/blog/vulnerability-assessment-how-to-order/)で説明しています。診断とペネトレーションテストの使い分けは、[ペネトレーションテストと脆弱性診断の違い](https://www.ameliatechnology.co.jp/blog/pentest-vs-vulnerability-assessment/)で説明しています。

### 運用と部品の更新

公開した後も、使っているフレームワークやライブラリに脆弱性が見つかれば、修正版を当てる必要があります。使っている部品を一覧にしておくと、影響を早く確かめられます。部品の一覧の作り方は、[SBOM（ソフトウェアの部品表）とは](https://www.ameliatechnology.co.jp/blog/sbom-software-inventory/)で扱っています。

## 発注のときに、要件と契約へ書くこと

発注する側は、セキュアコーディングを要件と契約に具体的に書くことで、開発会社との認識の違いを防げます。書いておきたい項目の例は次のとおりです。

- **参照する基準**：IPAの「安全なウェブサイトの作り方」や OWASP Top 10 など、どの基準に沿って開発するか
- **レビューのやり方**：コードレビューを誰が、どの範囲で行い、記録をどう残すか
- **テストと診断**：公開の前に脆弱性のテストや診断を行うか、誰が行うか、その費用をどちらが持つか
- **見つかった問題の扱い**：検収の前に見つかった問題、検収の後に見つかった問題を、どう直すか
- **部品の扱い**：使う[オープンソース](https://www.ameliatechnology.co.jp/glossary/oss/)の部品の一覧を納品物に含めるか、公開した後の更新を誰が担うか
- **記録と納品物**：レビューと診断の結果を、納品物として受け取るか

検収の後に見つかった不具合の扱いは、[契約不適合責任とは。期間と請求できること](https://www.ameliatechnology.co.jp/blog/contract-nonconformity-liability/)で、提案を依頼するときの書き方は[RFP（提案依頼書）の書き方：載せる項目と注意点](https://www.ameliatechnology.co.jp/blog/how-to-write-rfp/)で説明しています。契約の条項の書き方は、弁護士などの専門家にご確認ください。

## 発注する側が、確かめておきたいこと

開発会社に任せきりにせず、発注する側も、要所で確かめることが大切です。たとえば、開発の途中でレビューの記録を見せてもらう、公開の前の診断の結果と直した内容を受け取る、公開した後の更新の担当と連絡の方法を決めておく、といったことです。

セキュアコーディングは、すべての脆弱性をなくすことを保証するものではありません。作り込みを減らす取り組みと、診断で見つけて直す取り組み、公開した後に更新を続ける取り組みを組み合わせて、危険を下げていくものと考えると整理しやすくなります。Webシステムの守りの全体像は、[Webシステムのセキュリティ対策の基本](https://www.ameliatechnology.co.jp/blog/web-security-basics/)で説明しています。

## 当社のご支援

アメリア・テクノロジーの[Webシステム開発](https://www.ameliatechnology.co.jp/service/web-system/)では、要件定義から設計・開発・テスト、公開した後の運用まで受け持ち、その中で守りを組み込みます。他社が開発したシステムについては、[セキュリティ診断と対策](https://www.ameliatechnology.co.jp/service/security/)で、開発した会社とは別の立場から脆弱性を確かめ、直すところまでお手伝いします。当社が開発したシステムの診断は、自己点検として報告します。Webサイトの現状をおおまかに確かめたい場合は、無料の[Webサイト診断](https://www.ameliatechnology.co.jp/diagnosis/web/)をお使いください。

- セキュアコーディング
- 脆弱性
- 開発の発注
- Webセキュリティ

## この記事に出てくる用語

- [セキュアコーディング](https://www.ameliatechnology.co.jp/glossary/secure-coding/)
- [脆弱性](https://www.ameliatechnology.co.jp/glossary/vulnerability/)
- [データベース](https://www.ameliatechnology.co.jp/glossary/database/)
- [SQL](https://www.ameliatechnology.co.jp/glossary/sql/)
- [SQLインジェクション](https://www.ameliatechnology.co.jp/glossary/sql-injection/)
- [Webサイト](https://www.ameliatechnology.co.jp/glossary/website/)
- [OSコマンドインジェクション](https://www.ameliatechnology.co.jp/glossary/os-command-injection/)
- [ディレクトリトラバーサル](https://www.ameliatechnology.co.jp/glossary/directory-traversal/)

## 関連する法令・指針（参考情報）

- 指針
   独立行政法人情報処理推進機構（IPA）「安全なウェブサイトの作り方」
   Webサイトの開発者や運営者に向けて、SQLインジェクションやクロスサイト・スクリプティングなど、よく知られた脆弱性とその対策をまとめた資料です。運用の点検項目をまとめた「安全なウェブサイトの運用管理に向けての20ヶ条」も案内しています。
   [発行元の公式ページで開く](https://www.ipa.go.jp/security/vuln/websecurity/index.html)

法令は2026年10月21日時点の内容です。要旨は当社がまとめたもので、条文・判決・指針の全文ではありません。個別の事案への当てはめは、弁護士・社会保険労務士などの専門家にご確認ください。表記の決まりは[法令・指針の参考情報と凡例](https://www.ameliatechnology.co.jp/knowledge/legal/)をご覧ください。

この記事を書いた人

[石田誠](https://www.ameliatechnology.co.jp/blog/author/ishida/) グループCTO

インターネットの黎明期から、ホスティング事業の立ち上げや、インフラ・セキュリティのプロジェクトに携わってきました。現在は、AWS・Azure へのクラウド移行の支援と、業務アプリケーションの要件定義から実装までを担っています。

このコラムは一般的な情報の提供を目的としたもので、個別の状況への助言ではありません。製品・サービスの名前と内容は、記事の更新日の時点のものです。

## あわせて読みたい

- [ゼロトラストの考え方と、中小企業の始め方](https://www.ameliatechnology.co.jp/blog/zero-trust-for-smb/)
- [Webアクセシビリティの対応。合理的配慮の義務化と進め方](https://www.ameliatechnology.co.jp/blog/web-accessibility-obligation/)
- [発注者が知っておきたいテストの種類と確かめ方](https://www.ameliatechnology.co.jp/blog/testing-for-buyers/)

[Webとシステム開発のコラムを見る](https://www.ameliatechnology.co.jp/blog/category/web/) [コラムの一覧に戻る](https://www.ameliatechnology.co.jp/blog/)

## 次の一歩

### 業務で使うWebシステムをつくる

社内で使う業務システムやWebサービスを、要件定義から設計・開発・テスト、公開した後の運用まで受け持ちます。

[Webシステム開発を見る](https://www.ameliatechnology.co.jp/service/web-system/)

### まずは30分、オンラインで話してみる

何に使うかが決まっていない段階でも構いません。30分のオンライン相談は無料です。

[無料で相談する](https://www.ameliatechnology.co.jp/contact/)

## ご関心に合わせて、お選びください。

[情報を集めている方へ会社案内、AI開発の例、セキュリティ診断の報告書の見本をお送りします。資料をダウンロード](https://www.ameliatechnology.co.jp/download/)[課題が見えている方へオンラインで30分、お話をうかがいます。費用はかかりません。無料で相談する](https://www.ameliatechnology.co.jp/contact/)[進め方を決めたい方へ2〜4週間で、優先順位と計画をまとめるAI活用の診断です。診断について見る](https://www.ameliatechnology.co.jp/pricing/#diagnosis)

---

出典：アメリア・テクノロジー株式会社「セキュアコーディングとは。開発会社に何を求めればよいか｜アメリア・テクノロジー株式会社」 https://www.ameliatechnology.co.jp/blog/secure-coding-requirements/