# AIが生成したシステムの設計を点検する

> 動く画面が出てきたあとに確かめるのは、見た目ではなくデータの持ち方、権限、変更への強さ、安全の四つ。AI が書いたコードの脆弱性の調査と公的な指針をもとに、情報システム担当が使える点検の観点をまとめた。

- URL: https://weaveai.jp/journal/reviewing-ai-generated-system-design/
- カテゴリ: AIで作る・確かめる
- 公開: 2026-10-04 / 更新: 2026-10-04
- 執筆: weaveAI 編集部（株式会社サオス）

AI が作った画面が動いたら、次に点検するのは画面の見た目ではなく、その下の設計です。見るところは四つあります。データの持ち方、権限、変更への強さ、安全。画面は作り直せばすみますが、設計の誤りはデータが溜まってから直すほど高くつきます。動いた直後が一番安く直せる時です。

## 動くだけでは足りない理由

Veracode が2025年に公表した調査では、100を超える言語モデルに書かせたコードの45%がセキュリティのテストに失敗し、OWASP Top 10 に当たる脆弱性を含んでいました。言語別では Java の失敗率が最も高く72%でした。調査は、モデルが新しくなってもセキュリティの成績は横ばいだとしています。

AI が書いたものは、動くことと安全であることが別々に決まります。業務システムでは、これに加えて、データが正しく積み上がるか、後から変えられるかも別に決まります。

## 1. データの持ち方

![「METADATA」の文字を並べた木のブロック](https://weaveai.jp/journal/img/30885765.jpg)

一番後から直しにくいのがここです。次の点を確かめます。

- 同じものを二か所に持っていないか。品目や取引先の一覧が、画面ごとに別のテーブルとしてコピーされていると、片方を直したときにもう片方が古いまま残ります。
- 参照がつながっているか。PostgreSQL の文書は、外部キー制約を、ある列の値が別の表のどこかの行の値と一致しなければならないという決まりとして説明し、これで二つの表のあいだの参照整合性が保たれるとしています。検査結果が存在しない品目を指したり、削除した設備の点検記録が宙に浮いたりしないよう、データベースの側で止めているかを見ます。
- 選ぶべき値が自由入力になっていないか。不良区分や工程名が自由入力だと、後で集計できません。
- 誰がいつ作り、いつ直したかが残るか。作成者・作成日時・更新者・更新日時の列があるかを確かめます。
- 単位と桁が決まっているか。数量の単位、重さの単位、小数の桁が画面ごとに違っていないか。

## 2. 権限

![鍵のマークが表示されたノートパソコン](https://weaveai.jp/journal/img/4973899.jpg)

OWASP が2025年にまとめた Web アプリケーションの主なリスクの一覧で、1位は「アクセス制御の不備」です。OWASP は、テストしたアプリケーションの100%に何らかのアクセス制御の不備が見つかったとしています。

情報処理推進機構（IPA）の「安全なウェブサイトの作り方」は、ログインの仕組みに加えて認可の処理を実装し、ログイン中の利用者が他人になりすましてアクセスできないようにすることを求めています。例として、データベースを検索するための注文番号が、ログイン中の利用者に閲覧を許可された番号かを常に確かめるよう書いています。

業務画面に置き換えると、確かめることは次のとおりです。

- 見るだけの人と入力する人が分かれているか。現場の人がマスタを書き換えられないか。
- 画面のボタンを隠しているだけで、URL や API を直接呼べば操作できてしまわないか。
- 他の工場や他部署のデータが見えないか。PostgreSQL には、利用者ごとに見える行や変えられる行を制限する行単位のセキュリティがあり、ポリシーが無ければ既定で何も見えず何も変えられない、と文書にあります。こうした仕組みをデータベース側で使っているかも点検の対象です。

## 3. 変更への強さ

業務システムは、取引先や規格や工程が変わるたびに直されます。AI が作ったものは、似た処理を画面ごとに少しずつ違う形で書いていることがよくあります。

- 同じ計算や同じ判定が、何か所にも書かれていないか。一か所を直して他を直し忘れると、画面によって結果が違ってきます。
- 使われていない処理が残っていないか。残ったままだと、どれが本物か分からなくなります。
- 税率、合否の上下限、承認の金額基準のような変わる値が、コードの中に直接書かれていないか。マスタや設定に出してあれば、作り直さずに変えられます。
- 在庫を増減させる処理のように、壊れると困る処理が一つの共通の関数にまとまっていて、どの画面もそれを通っているか。

## 4. 安全

- 入力値をそのまま SQL に組み込んでいないか。
- パスワードや接続情報がコードや画面に書かれていないか。
- エラー画面に、内部の表の名前や SQL がそのまま出ていないか。

ISO/IEC 25010（2023年版）は、ソフトウェア製品の品質を9つの特性に分けて定めています。点検の観点を一から考えるより、こうした規格の枠組みを下敷きにして、自社に関係する項目を拾うほうが漏れが少なくなります。

## 誰が点検するか

社内に専門の技術者がいなくても、上の項目の多くは質問の形で確かめられます。「この品目の一覧は、どの画面でも同じ表を見ていますか」「現場の権限で、この URL を直接開くとどうなりますか」「合格の上限値を変えるとき、どこを直しますか」。答えに詰まる設計は、たいてい後で困ります。

weaveAI では、画面を作るたびに、使われていないストアドプロシージャや、よく似た処理の重複を機械的に洗い出し、AI がコードを読んだ分析と合わせて1回で示すレビューを行います。候補ごとに、課題にするか対応しないかは人が決めます。点検を人の注意力だけに頼らず、毎回同じ観点で回すためです。

## 出典

- Veracode「2025 GenAI Code Security Report」（2025年7月30日） https://www.veracode.com/blog/genai-code-security-report/
- OWASP「OWASP Top 10:2025」 https://top10.owasp.org/2025
- OWASP「A01:2025 – Broken Access Control」 https://top10.owasp.org/2025/A01_2025-Broken_Access_Control/
- 情報処理推進機構「安全なウェブサイトの作り方 1.11 アクセス制御や認可制御の欠落」 https://www.ipa.go.jp/security/vuln/websecurity/access-control.html
- PostgreSQL「Constraints」（外部キー） https://www.postgresql.org/docs/current/ddl-constraints.html
- PostgreSQL「Row Security Policies」 https://www.postgresql.org/docs/current/ddl-rowsecurity.html
- ISO「ISO/IEC 25010:2023 Systems and software engineering — Product quality model」 https://www.iso.org/standard/78176.html