AI SecurityAIセキュリティ事業AI × サイバーセキュリティ
その開発は、安全だと言えますか。
AI駆動開発で、社内のツールもシステムも作れるようになりました。残った問題は1つです。
できあがったものが本当にセキュリティを担保しているのかを、
作った本人も、情報システム部門も、確かめられません。
当社は、安全なAI駆動開発のやり方を先に教え、作られたものがその基準を満たしているかを第三者として見極め、基準を維持する運用までを担います。
作るのはお客様です。当社は作りません。
- 対象：
- 製造業を中心とする大企業
- 価格：
- 個別見積
01課題提起
The problem
作れるようになった。確かめる人がいない。
AI駆動開発が社内に入ると、3つのことが同時に起きます。
作る人が、セキュリティを知らない人に変わりました。
自然言語で指示すれば動くものができるため、業務部門が自分で作れるようになりました。作る人は増え、セキュリティを設計できる人は増えていません。
動くことと、安全であることは別です。
AIが生成したコードには、認証の欠落や認証情報の直書きといった古典的な欠陥が繰り返し現れます。動作確認では見つかりません。
安全かどうかを判定する基準が、社内にありません。
何を満たせば本番で使ってよいかが決まっていないため、問題を指摘することも、問題がないと言うこともできません。
作るのをやめる必要はありません。必要なのは、作る前に基準を入れ、その基準で見極め、基準を維持することです。
02数字で見る現状
By the numbers
数字で見る現状
45%
Veracodeが設計した80のコーディングタスクを100以上の大規模言語モデルで評価したところ、生成されたコードの45%に脆弱性が含まれていました。モデルの大きさによらず、結果はほぼ変わりませんでした。
出典：Veracode「2025 GenAI Code Security Report」2025年7月
75.8% ／ 56.4%
開発者の75.8%が、AIが生成したコードは人間が書いたものより安全だと考えています。一方で56.4%が、AIの提案にセキュリティ上の問題がよくあると回答しています。
出典：Snyk「2023 AI Code Security Report」（2023年後半、開発者約500名の調査）
96%
開発者の96%がAI生成コードを完全には信頼していません。一方で、コミット前に必ず検証する開発者は48%にとどまります。
出典：Sonar「State of Code Developer Survey」2026年1月（開発者1,100名超）
20%
回答した組織の20%が、AIが生成したコードに関連する重大なセキュリティインシデントを経験しています。
出典：Aikido Security「State of AI in Security & Development 2026」（欧米のCISO・開発者・AppSecエンジニア450名）
03サービス概要
Service overview
3つの段階で、安全を担保する
本事業は、3つの段階で構成されます。作るのはお客様です。当社は、作り方の基準を入れ、その基準で見極め、基準を維持する側に立ちます。
教え込む
安全なAI駆動開発
- 当社がやること
- 安全なAI駆動開発のやり方を、作る人と承認する人に教えます。本番で使ってよい条件を定義します。
- お客様がやること
- 受講と、基準の承認
- 成果物
- 判定基準、受講記録、理解度の確認結果
見極める
第三者による検証
- 当社がやること
- 作られたものを、定めた基準で検証します。問題と直し方を報告し、本番で使ってよいかを判定します。
- お客様がやること
- 対象の提示、指摘への対応
- 成果物
- 棚卸し結果、検証報告書、可否の判定
安全に運用する
基準の維持
- 当社がやること
- 再検証の条件を定め、棚卸しを維持します。運用で見つかった問題を教育に反映します。
- お客様がやること
- 再検証の依頼、止める判断
- 成果物
- 再検証の手順、更新された判定基準
当社は、お客様のツールを代わりに作りません。
作る側に立つと、自分で作ったものを自分で検証することになり、第三者による判定として成立しなくなるためです。
各段階は単独でも提供します。ただし01を経ずに02から入ると、判定の基準が社内にないまま検証結果だけが出ます。
01から順に進める形を標準とします。
04何を見るか
What we check
何を見るか
AIで作られたツールを、次の8点で確かめます。いずれも、動作確認では見つからない項目です。
認証
誰が使えるかが制御されているか
よくある状態社内ネットワークにあるから大丈夫、として認証がない
認可
元データの権限が引き継がれているか
よくある状態全員が全部門のデータを引ける
認証情報
APIキーやパスワードがコードや設定に直書きされていないか
よくある状態生成されたコードにそのまま残っている
入力の扱い
外部から与えられた値が検証されているか
よくある状態検証がなく、注入を受ける
外部への送信
どこに何が送られているか
よくある状態把握されていないサービスに業務データが出ている
データの保存
どこに、いつまで残るか
よくある状態保存場所も保持期間も決まっていない
記録
誰が何をしたかを後から追えるか
よくある状態ログがない
依存先
使っているライブラリや外部サービスに既知の脆弱性がないか
よくある状態更新されないまま使われ続ける
検証しないこと
次の3点は、検証の対象に含みません。
- 本番環境への攻撃を伴う試験
- 業務ロジックの正しさ
- AIモデルそのものの挙動
05導入の流れ
Onboarding
導入の流れ
棚卸しと、現状の把握社内でAIを使って何が作られているかを洗い出します。部門へのヒアリングと、使われているサービスの確認を行います。お客様に回答いただきます。
判定基準を決める何を満たせば本番で使ってよいかを、文書で定めます。論点と選択肢は当社が用意し、決めるのはお客様です。
研修で、基準を作る人に入れる安全なAI駆動開発のやり方と、定めた基準の意味を、作る人と承認する人に教えます。
検証する作られたものを基準で確かめ、問題と直し方を報告します。本番で使ってよいかを判定します。
運用に乗せる再検証の条件と、止める権限を持つ人を決めます。以後は、お客様自身で判定できる形にします。
標準期間は2〜4週間です。価格は個別見積です。
06特長
Features
3つの特長
当社は、作りません。
お客様のツールを代わりに作ることはしません。作る側に立たないため、「基準を満たしている」という判定が、第三者の判定として成立します。
基準を、作る前に入れます。
何を満たせばよいかを先に決め、作る人に教えます。動いているものを後から止める事態が起きないようにします。
製造現場（OT）まで見られます。
当社はOT／ICSセキュリティを本業としています。生産管理や設備に接続するツールも、制御系を含めて検証できます。
07安全設計
Safety by design
「安全だ」と言えるための6つの条件
「安全です」とは言えません。言えるのは、次の6つを満たしているかどうかです。当社は、この6つを判定の基準とします。
判定の基準が、作る前に決まっている。
「本番で使ってよい」の条件を、作る前に文書で定めます。できたものを見てから判断すると、動いているものを止められなくなります。
作る人が、基準を知っている。
基準は、守る人に伝わって初めて機能します。作る人と承認する人の両方が、何を満たすべきかを理解している状態を作ります。
何が作られているかが、把握されている。
社内にいくつあり、誰が作り、何のデータに触れているか。一覧がないものは、検証もできません。
作った人以外が、見ている。
自分で作ったものを自分で検証しても、見落とす前提は変わりません。第三者が見た、という事実が担保になります。
検証の項目と結果が、記録されている。
何を見て、何が問題で、どう直したかを残します。残っていなければ、安全だったとは後から言えません。
変わったらやり直し、直せなければ止められる。
一度の検証は、その時点の状態に対するものです。再検証の条件と、止める権限を持つ人を、あらかじめ決めておきます。
08他のやり方との違い
How we differ
他のやり方との違い
AIで作られたものの安全を確かめる方法は、ほかにもあります。進め方ごとに、本サービスとの違いを示します。
| 他のやり方 | その進め方 | 本サービス |
|---|---|---|
| AIツールの検査機能に任せる | 生成の際に、ツール側が持つ検査機能で確認します。 | 外から、定めた基準で確かめます。作ったものの外から、定めた基準で確かめます。生成したものと同じ系統が検査すると、同じ前提の見落としが残ります。 |
| 作ってもらい、作った会社に検証させる | 開発を外部に委託し、その会社の品質保証を受け取ります。 | 当社は作りません。当社は作りません。作る側に立たないため、判定が第三者の判定として成立します。 |
| 既存の脆弱性診断をかける | 公開システムを対象に、年に一度の頻度で診断します。 | 基準を先に定め、教えてから検証します。基準を先に定め、作る人に教えてから検証します。変わったときにやり直す条件も決めます。 |
| ガイドラインを配る | AI利用の方針を文書で示します。 | 満たしているかを、実際に確かめます。文書に加えて、満たしているかを実際に確かめ、可否を判定します。 |
| 内製を禁止する | AIを使った内製を認めません。 | 作ることは止めません。作ることは止めません。作ってよい条件を定義し、満たしたものを通します。 |
- 本サービス
- 外から、定めた基準で確かめます。作ったものの外から、定めた基準で確かめます。生成したものと同じ系統が検査すると、同じ前提の見落としが残ります。
- 他のやり方
- AIツールの検査機能に任せる
- その進め方
- 生成の際に、ツール側が持つ検査機能で確認します。
- 本サービス
- 当社は作りません。当社は作りません。作る側に立たないため、判定が第三者の判定として成立します。
- 他のやり方
- 作ってもらい、作った会社に検証させる
- その進め方
- 開発を外部に委託し、その会社の品質保証を受け取ります。
- 本サービス
- 基準を先に定め、教えてから検証します。基準を先に定め、作る人に教えてから検証します。変わったときにやり直す条件も決めます。
- 他のやり方
- 既存の脆弱性診断をかける
- その進め方
- 公開システムを対象に、年に一度の頻度で診断します。
- 本サービス
- 満たしているかを、実際に確かめます。文書に加えて、満たしているかを実際に確かめ、可否を判定します。
- 他のやり方
- ガイドラインを配る
- その進め方
- AI利用の方針を文書で示します。
- 本サービス
- 作ることは止めません。作ることは止めません。作ってよい条件を定義し、満たしたものを通します。
- 他のやり方
- 内製を禁止する
- その進め方
- AIを使った内製を認めません。
09実績・会社情報
Track record and company
実績と会社情報
- 大学発スタートアップ支援プラットフォーム「GTIE」のアクセラレーションプログラムに採択されました。
- サイバーセキュリティ研修を、18社に実施しました。
- 創業メンバーは、法人設立以前から、官公庁および大手通信事業者のセキュリティ支援案件に従事してきました。「第21回情報危機管理コンテスト（2026年5月）」において、文部科学大臣賞を受賞しています。
