AIで作った社内ツールの脆弱性をどう確かめる？自社で行う診断の範囲と専門業者に頼む判断

AIの普及によって手軽に社内ツールを作れるようになった一方で、「AIで作ったものは本当に安全なのか」「以前作ったツールが攻撃されたら困る」と不安を抱える保守担当者は少なくありません。実際に、AIで作られた公開アプリを監査した研究では多くのアプリに脆弱性が見つかっており、そのまま運用することにはリスクが伴います。

本記事では、AIで作ったツールの脆弱性を自社でどこまで確かめ、どこから専門業者に頼むべきかを解説します。

結論として、まずはツールが持つ情報とアクセスできる人を書き出し、万が一の際のリスクを把握することから始めます。その上で、AIにソースコードを読ませて自社での確認を進め、動かして試す場合は事前に許可と対象範囲を書面にします。しかし、AIの確認には自社の業務ルールに絡む欠陥を見つけにくいといった限界があります。そのため、扱うデータや公開範囲に応じて、外部の専門業者へ診断を依頼する線引きが不可欠です。

見つかった問題を修正した後は同じ確認をやり直し、残るリスクを受け入れて運用を続けるかどうかを人が判断します。自社でできる確認と専門家の力を組み合わせ、安全にツールを運用するための基準を見ていきましょう。

最初に、ツールが持つ情報と触れる人を書き出す

AIで作ったツールの脆弱性をどこまで深く確認するかは、「そのツールがどのような情報を持ち、誰が触れる状態にあるか」によって決まります。

AIが生成したコードには、セキュリティ上の問題が含まれていることが少なくありません。2026年6月公開（9月改訂）の論文では、AIツール（Claude CodeとLovable）で作られた公開OSSアプリのうち、公開運用中の200件を監査した結果が報告されています。それによると、監査したアプリの91.0%に1件以上の脆弱性があり、見つかった脆弱性の65.77%が重大度の高い（CriticalまたはHigh）ものでした。特にアクセス制御の不備、インジェクション（不正な命令の注入）、認証の失敗に集中していたとされています。これは公開OSSアプリを対象とした調査であり、社内の非公開ツールの割合を直接示すものではありませんが、AIが作ったツールをそのまま運用することにはリスクが伴うことがわかります。

確認の深さを決めるために、まずはツールの現状を書き出してみましょう。ここでは架空の例として、「営業部がAIで作った見積もり依頼ツール」を考えます。このツールは、取引先が社名・担当者名・メールアドレスを入力するフォームと、社員がIDとパスワードでログインして依頼一覧を見る画面があり、自社契約のクラウド上で公開されているとします。

保守を任された担当者が書き出すべき材料は、主に以下の4点です。

• 保存しているデータ項目とその必要性
• 公開URLとログインの有無
• 誰がアクセスできるか
• どこに置いているか（契約名義など）

これらの情報を整理することで、万が一問題が起きたときの影響の大きさがわかります。たとえば、個人情報保護委員会の案内によると、個人データの漏えい等のうち、要配慮個人情報を含むものや、クレジットカード番号など不正利用によって財産的被害が生じるおそれがあるもの、不正の目的をもって行われたおそれがある行為によるもの、本人の数が1,000人を超えるものは、委員会への報告対象となります。速報は発覚日から3〜5日以内、確報は30日以内（不正の目的のおそれがある場合は60日以内）に行う必要があります。ツールがどのような個人データを持っているかによって、事故時の対応が大きく変わるのです。

不安を減らすための最初の打ち手は、「守る情報を持たない作りにする」ことです。見積もり依頼ツールであれば、本当に担当者名やメールアドレスをツール内に保存し続ける必要があるのかを見直します。不要な個人情報を保存しない仕組みにすれば、それだけリスクを減らすことができます。

また、「誰がアクセスできるか」という前提条件は、脆弱性の重大度を判定する基準にもなります。AnthropicのClaude Security（2026年11月時点でEnterpriseプラン向け公開ベータ）では、コードの配置の仕方や誰が到達できるかといった情報を脅威モデルに保存し、脆弱性の指摘と重大度の判定に使います。重大度は悪用のしやすさで決まり、ネットワーク越しに誰でもログインなしで悪用できるものはCritical（致命的）、ログインが必要なものはHigh（高）やMedium（中）といったように評価されます。

ツールが持つ情報と触れる人を書き出すことで、自社でどこまで確認すべきか、あるいは専門業者に頼むべきかの判断基準が見えてきます。

自社でできる確認は、AIにコードを読ませるところから

自社だけで安全に始められる確認は、ツールのソースコード（プログラムの設計図）をAIに読ませてセキュリティ上の問題を探すことです。実際に動いているツールに疑似的な攻撃を仕掛けるわけではないため、システムを壊してしまう危険がありません。

Anthropicの説明によると、一般に提供されているClaudeのモデルにコードを読み込ませて、自社のソースコードの脆弱性発見や、どこからどのような脅威が来るかを整理する脅威モデリングを行うことは誰でも可能です。さらに、Claude Codeというコマンド操作のツールには、自動セキュリティレビューの機能が備わっています。ProやMaxの個人有料プラン、またはAPI課金アカウントがあれば、コマンドを実行するだけで、SQLインジェクション（データベースへの不正な命令の注入）やクロスサイト・スクリプティング（悪意あるスクリプトの実行）、認証の不備などを探し出し、問題の説明と修正の実装までAIに頼むことができます。

また、Anthropicの公式記事にあるように、GitHub Actionという仕組みを使えば、コードの変更を提案するプルリクエストが作られたときに自動でセキュリティレビューを走らせ、懸念点や推奨事項を該当行にコメントさせることもできます。Anthropic社内でも、この自動レビューによって遠隔からコードを実行される脆弱性などを事前に発見できた例があると報告されています。

ただし、AIにコードを読ませる前に確認しておくべきことがあります。ソースコードがAIの提供元へ送信されるため、社内のAI利用ルールに反しないかを確かめる必要があります。また、Claude Codeのセキュリティレビューは、既定ではまだ確定していない変更箇所だけを対象にする設定になっています。前節の見積もり依頼ツールのように、すでに公開されているコード全体を後から確認したい場合は、確認対象の範囲を明示してAIに依頼する必要があります。

AIによるコード確認は手軽ですが、見落としが発生すること（何が漏れるか）も知っておかなければなりません。

OWASP（ウェブセキュリティの国際的な非営利団体）のガイドは、自動ツールは一般的な問題を見つけるのには向いているものの、独自の業務ルールに絡む深い欠陥を見つける文脈を欠くことが多いと指摘しています。たとえば、見積もり依頼ツールのコードを読ませても、「ログインしていない人でも、依頼一覧のURLを直接開くと中身が見えてしまう」といった業務上のアクセス制御の不備は、AIがツールの利用のされ方を深く理解していなければ欠陥だと判断できません。 さらに、サービス拒否（DoS）やレート制限（短時間に大量のアクセスを防ぐ仕組み）などの問題は、誤検知が多いためGitHub Actionのレビューでは既定で除外されています。

AIのセキュリティレビューは、既存のセキュリティの取り組みや人による確認を完全に置き換えるものではありません。AIの指摘を鵜呑みにして直すだけでなく、IPA（情報処理推進機構）の「安全なウェブサイトの作り方」の巻末にあるセキュリティ実装チェックリストなどを活用し、人が自社の事業リスクに照らして優先順位を判断することが求められます。

動かして試すなら、許可と対象範囲を先に書面にする

ソースコードをAIに読ませる確認の次に、ツールを実際に動かしながら脆弱性を探す方法があります。しかし、動いているツールに試験のための通信を送る前には、誰の管理下にあるシステムで、何を対象にするかを明確にし、許可を得る必要があります。

まず、試験は取引先の実際のデータが入った「本番環境」ではなく、ダミーデータを入れた「試験環境」で行うのが鉄則です。GMO Flatt Securityの解説では、AIエージェントに脆弱性の検証を頼んだ際、副作用のない安全な入力にとどまらず、データベースのテーブルを消去してしまうような破壊的な入力を生成することがあると指摘されています。万が一システムが壊れても業務に影響が出ないように、試験を行う場所を分けることが重要です。

次に、試験環境の「アクセス管理者」が誰かを確認します。不正アクセス行為の禁止等に関する法律（不正アクセス禁止法）の第2条では、コンピュータの動作を管理する者を「アクセス管理者」と定めています。第3条などでは、アクセス管理者の承諾を得ずにアクセス制御の機能を回避する行為などを禁止し、第11条で違反者には拘禁刑や罰金を設けています（本記事は法的助言ではなく、条文の紹介にとどめます）。自社のツールであっても、置かれている環境によって管理責任の所在が変わるため、承諾の有無は慎重に確認しなければなりません。

見積もり依頼ツールを自社契約のクラウドに置いている場合、クラウド事業者の規定も確認します。たとえばAWSのペネトレーションテスト（侵入テスト）方針では、対象として許可されたサービスであれば事前承認なしに自分の資産を試験できますが、サービス拒否（DoS）攻撃の模擬は自分の資産でも禁止されています。また、NTTPCのVPSクラウドのよくあるご質問では、利用者による脆弱性検査を自由としていますが、診断によってアクセスが集中して他の利用者に著しい影響が出る場合は、攻撃と判断して上位のネットワーク機器でブロックすることがあると説明しています。

こうしたトラブルを防ぐため、通信を送る前に取り決めを書面に残します。診断事業者であるサイバートラストの案内などを参考にすると、以下の項目を整理して社内やクラウド事業者と合意しておくことが考えられます。

• 診断対象のサーバーと対象URL
• 実施期間と頻度
• 試験を行う会社名や担当者
• 接続元のIPアドレス（どこから通信が来るか）
• 緊急時の連絡先と、試験を止める条件

最後に、試験にAIを使う場合はAI提供元の規約も確認します。Anthropicの利用規約（Usage Policy）では、システムの所有者の許可なく脆弱性を発見・悪用することを禁止していますが、所有者の許可を得たシステムでのセキュリティ試験は禁止対象外として明記されています。ただし、公式のサポート記事にあるように、一般提供モデルでは悪用の検証などが安全分類器によって中断されることがあります。もしAIの安全装置で止められた場合は回避しようとせず、外部の専門家による診断へ切り替えるか、データの保持が参加条件となる審査制のセキュリティ専門家向けプログラムへの申請を検討してください。

専門業者に頼む線引きと、依頼先の選び方

AIで作った社内ツールの脆弱性を自社で確認するのには限界があります。どこから外部の専門業者に診断を依頼すべきか迷ったときは、ツールが事業に与えるリスクの大きさから線引きを検討します。

OWASP（ウェブセキュリティの国際的な非営利団体）のガイドでは、試験にかけられる時間と資源は限られるため、事業に実際のリスクを与える問題に時間を使い、優先順位を付け直し続けるよう求めています。公的な基準ではありませんが、本記事の例である「営業部がAIで作った見積もり依頼ツール」の場合、以下のような条件に当てはまれば、専門業者への依頼を検討する目安になります。

• 取引先の個人データを持っている
• インターネットに公開している
• ログイン後の権限（他人の依頼を見られないか）など、業務ルールに絡む確認がある
• AIの指摘を自社で直せるか判断できない

外部の診断を頼むと決めた場合、次はどの業者に依頼するかを選びます。診断には深さがあり、たとえばIPA（情報処理推進機構）の別冊「ウェブ健康診断仕様」に基づいた診断は、危険度の高い脆弱性など13の診断項目に絞ったものです。IPAの仕様書には、この診断で脆弱性が検出されなかった場合でも安全宣言にはつながらず、より詳細な診断を受けることや対策の実装を推奨すると明記されています。自社のツールが抱えるリスクに応じて、どこまで深い診断が必要かを決める必要があります。

専門知識を持たない保守担当者が、診断サービスの品質を自力で見極めるのは容易ではありません。そこで活用できるのが、経済産業省の「情報セキュリティサービス審査登録制度」です。一定の技術や品質要件を満たしているかを第三者が審査して登録する仕組みで、令和7年（2025年）4月施行の基準第4.1版に基づいて運用されています。

この制度に適合したサービスは、IPAの「情報セキュリティサービス基準適合サービスリスト」（最終更新2026年10月9日）としてPDFで公開されています。リストには「脆弱性診断サービス」が掲載されており、2024年4月の経済産業省の報道発表に合わせて追加された「ペネトレーションテスト（侵入試験）サービス」をオプションとして提供しているかも確認できます。ペネトレーションテストは既知の技術を用いて実際に侵入を試みる試験で、リスト上では脆弱性診断サービス欄の「ペネトレ」項目に星印が付いている業者が対応しています。ただし、リストへの掲載は一定の基準を満たしたことを示すものであり、IPAによるいかなる保証も意味しない点には留意してください。

依頼先を決めたら、診断を円滑に進めるための材料を渡します。これまで自社で整理してきた以下の情報を専門業者に共有することで、確認の漏れを防ぐことができます。

• 前の節までで作った棚卸し表
• AIの指摘一覧と対応状況
• 試験環境の情報と承諾の記録
• 診断してほしい範囲

自社で行ったAIへのコード読み込みや設定の整理は、決して無駄にはなりません。これらの事前準備があるからこそ、専門業者は業務ルールに絡む複雑な部分や、実際に侵入されるリスクの検証に時間を使い、効果的な診断を行えるのです。

見つかった問題を直し、同じ確認をもう一度通す

自社の確認や外部の診断で見つかった脆弱性を修正した後、何をもってツールを使い続けてよいと判断するのでしょうか。結論から言えば、修正によって新たな問題が起きていないかをもう一度確かめ、残るリスクを人が許容できると判断したときに運用の継続が決まります。

AIで作ったツールの脆弱性を直す際、Claude Codeの機能のように、問題の指摘だけでなく修正の実装までAIに頼むことができます。しかし、AIにコードの修正を任せると、直した箇所とは別の部分に新しい問題が入り込む可能性があります。2026年6月公開（9月改訂）の論文では、AIエージェントの仕組みやプロンプトを改善することで脆弱性の発生は減るものの、根本的なセキュリティリスクはなくならないと結論づけられています。

そのため、修正が終わった後は最初と同じ方法で確認をやり直す必要があります。自社の確認であれば、再びAIにセキュリティレビューを実行させます。Anthropicのヘルプでは、重要な変更を確定する前にレビューを実行することや、本番コードを含む保管場所（リポジトリ）にはGitHub Actionを設定して自動で確認することを勧めています。AnthropicのClaude Security（Enterpriseプラン向け公開ベータ）では、コードが変わると未解決の指摘を自動で再確認し、修正が入れば修正済みとして扱い、後で同じ問題が再び混入した場合は自動で指摘を再開する仕組みが備わっています。専門業者に外部診断を依頼した場合は、指摘された箇所が本当に直っているかを診断会社の再診断によって確かめます。

再確認によって指摘が消えたとしても、ツールの安全が完全に保証されたわけではない点には注意が必要です。たとえばAIによる自動確認では、既定の仕様によってサービス拒否（DoS）攻撃や、短時間の大量アクセスを防ぐレート制限などの問題が除外されていることがあります。再確認で指摘がゼロになっても、除外された範囲については確かめていないことになります。IPA（情報処理推進機構）の「安全なウェブサイトの作り方」でも、絞り込んだ診断で脆弱性が検出されなかった場合でも安全宣言にはつながらないとしています。

最終的にツールを公開し続けてよいかを決めるのは人です。架空の例である「見積もり依頼ツール」の保守担当者は、再確認を経ても残った指摘や、確認の対象から除外した範囲のリスクについて、自社の事業に照らして許容できるか（受け入れるか）を判断します。AIの指摘の中には誤検知が含まれることもあり、Claude Securityの機能でも、指摘を誤検知や受け入れたリスク、重複などの理由で却下し、記録として残すことができます。

すべてのリスクを完全にゼロにすることは難しいため、「残ったリスクを受け入れて公開を続けるか」「今後ツールにどの程度の変更を加えたときに確認をやり直すか」という運用ルールを人が決めます。その判断の根拠と過程を記録に残すことで、AIで作った社内ツールと適切に向き合いながら運用していくことができます。

よくある質問

Q1. AWSなどのクラウドで自社のツールを診断する場合、事前の申請は必要ですか？

クラウド事業者や実施する試験の内容によって異なります。たとえばAWSのペネトレーションテスト方針では、許可されたサービス（Permitted Services）であれば事前承認なしに試験できます。しかし、模擬フィッシングやC2の運用といった「Simulated Events」を行う場合は、開始の2週間前までに専用フォームでの申請が求められます。また、サービス拒否（DoS）攻撃の模擬は一律で禁止されています。

Q2. 専門業者のリストにある「ペネトレーションテスト」とは何ですか？

既知の技術を用いて、実際にシステムへの侵入を試みる試験のことです。2024年4月の経済産業省の報道発表によると、情報セキュリティサービス基準第4版において、脆弱性診断サービスのオプションとして追加されました。IPAの適合サービスリストでは、ペネトレーションテストに対応している業者の欄に星印が付いており、ペネトレーションテストに登録されたサービスは脆弱性診断サービスを包含するものとして扱われます。

Q3. 万が一、ツールから個人データが漏えいした場合はどうすればよいですか？

漏えいしたデータの内容や規模によっては、個人情報保護委員会への報告が必要です。同委員会の案内によると、要配慮個人情報を含むものや、クレジットカード番号など不正利用で財産的被害が生じるおそれがあるもの、不正の目的をもって行われたおそれがある行為によるもの、本人の数が1,000人を超える場合などが報告対象となります。報告の期限は、速報が発覚日から3〜5日以内、確報が30日以内（不正の目的のおそれがある場合は60日以内）と定められています。

Q4. AIの自動セキュリティレビューは、どのような環境で利用できますか？

利用する機能によって必要な環境が異なります。Claude Codeの自動セキュリティレビューをターミナルで実行するには、ProまたはMaxの個人有料プラン、または従量課金のAPI Consoleアカウントが必要です。また、GitHub Actionを使った自動レビューを動かすには、Claude APIのAPIキーが必要になります。なお、公式リポジトリの説明では、GitHub ActionはプロンプトインジェクションへのAI側の耐性を強化していないため、信頼できるプルリクエストにだけ使うよう求めています。