生成AIアプリの点検を考える企業が知っておきたいOSS「SecureAI-Scan」の使いどころ

「社内で作った問い合わせの自動応答に、生成AIをつないだ。従来の脆弱性診断は通したが、AI特有の危なさまで見られているのか分からない」「開発部門がMCPサーバー（AIに外部の道具を使わせるための窓口）を次々に作っている。どこを確かめればよいのか、基準がない」——生成AIを業務のアプリに組み込み始めた企業の、情報システムやセキュリティの担当者から聞こえてくる声です。AIを組み込んだアプリの点検は、AIの答えの質を確かめる話だと思われがちです。しかし、それだけではありません。本当は、外から入った文章やAIの出力が、コードの中でどこまで流れ、何を動かしてしまうかを確かめることが点検の芯になります。この記事では、そうした点検をコードの段階で行うOSS「SecureAI-Scan」について、一次情報で確かめられる機能、企業での使いどころ、小規模な個人の開発であることを踏まえた注意点、人が決めるべき範囲を整理します。導入や操作の手順は扱いません。

SecureAI-Scanとは何か。2026年10月時点で確かめられる事実

SecureAI-Scan は、GitHub上で公開されている点検の道具です。リポジトリの説明では、生成AIを組み込んだコードの弱点を攻撃者より先に見つけるものとされ、対象として指示の乗っ取り、MCPの道具への毒の混入、RAG（社内文書などを検索してAIの回答に使う仕組み）のデータの汚染などが挙げられています。README は、大規模言語モデル・MCPサーバー・検索用のデータベース・エージェントのスキルとやり取りするコードを、手元で点検する道具だと説明しています。

公開の時期と規模も押さえておきます。リポジトリは2026年2月5日に作られ、2026年10月17日にも更新されています。2026年10月23日時点でスターは23、複製（フォーク）は1と、まだ小規模なプロジェクトです。最新の版は2026年10月4日に公開された0.12.0で、主に配布はパッケージの公開場所である npm を通じて行われています。作者は2017年7月に作られた個人のアカウントで、公開リポジトリは31あります。

ライセンスはOSI（オープンソースの定義を管理する団体）が承認したMITライセンスで、商用の利用や改変も認められた形のOSSです。README によると、点検できるのは TypeScript・JavaScript・Python のコード、MCPの設定ファイル、エージェントのスキルの一式で、種類は自動で見分けるとされています。

README は、既定の点検ではアカウントの登録もアップロードも不要で、何も手元の端末の外に出ないと書いています。一方で、後で触れる一部の機能では、点検する対象を配布元から取ってくるための通信が起きます。どこまでが手元で完結するかは、機能ごとに分けて理解しておく必要があります。

なぜ今、生成AIを組み込んだコードの点検が課題になるのか

生成AIを業務のアプリに組み込む動きが広がり、AIに社内の情報を検索させたり、外部の道具を呼び出させたりする作りが増えました。こうした作りでは、AIが受け取る文章が、利用者の入力だけでなく、外部の文書や道具の返事からも入ってくるという特徴があります。その文章に紛れた指示を、AIが本来の指示と区別できずに従ってしまうのが、指示の乗っ取り（プロンプトインジェクション）と呼ばれる問題です。

問題は、AIが乗っ取られたあと、その出力をコードがどう扱うかです。AIが書いた文字列がそのまま命令の実行や、データベースへの問い合わせ、画面の表示に使われていれば、乗っ取りがアプリの中の実際の操作に変わってしまうことになります。README も、MCPの道具に渡る引数はAIが書くもので、AIは文脈の中の文章が指示するとおりに書く、と説明しています。

こうした危なさは、大規模言語モデルのアプリに関するOWASP（ウェブの安全性に取り組む国際的な団体）の10大リスクや、MCPに関する10大リスクとしても整理が進んでいます。ただ、整理された一覧があっても、自社のコードのどこに当てはまるのかを人の目だけで探すのは手間がかかります。一覧の項目と自社のコードの箇所を結びつける作業を手伝う道具として、SecureAI-Scan のような点検の道具が出てきている、と捉えると位置づけが分かりやすくなります。

一般的な静的解析とどこが違うのか

コードを動かさずに読んで弱点を探す静的解析（SAST）の道具は、多くの企業ですでに使われています。SecureAI-Scan も同じくコードを読む道具ですが、README は範囲を大規模言語モデル・MCP・RAG・エージェントの危なさに意図して絞っていると書き、一般的な静的解析や、秘密の情報の書き込みを探す道具ではないので併用してほしい、と明記しています。

違いの一つは、何を「AIの呼び出し」とみなすかです。README によると、OpenAI・Anthropic・Google などの公式の開発キット、LangChain、Bedrock、MCPの開発キットといった実際の部品に、読み込みの関係をたどって行き着く呼び出しだけを対象にします。名前が似ているだけの別の部品は対象にしない、という説明です。名前の一致だけで判定すると関係のない箇所まで拾ってしまうため、それを避ける作りだと読めます。

もう一つは、外から入った文章がどこに届くかの流れを、関数やファイルの境目をまたいでたどる点です。README は、入口（どこから文章が入るか）と出口（どこで危ない操作に使われるか）の組を示して、一つ一つの検出を、実際のコードの流れで裏づけると説明しています。一般的な静的解析の道具でも流れをたどるものはありますが、AIの呼び出しや道具の引数を入口として扱う点が、この道具の特色と言えます。

主な機能1：指示の乗っ取りと、AIの出力の扱いを追う

README で確かめられる一つ目の機能は、指示の乗っ取りにつながる流れの検出です。利用者の入力が、AIの振る舞いを決める指示の部分（システムの指示）に入り込んでいないかを、関数やファイルをまたいでたどります。一方で、利用者の発言として扱う欄に入力を入れるのは推奨される書き方なので、そこは指摘しないと書かれています。正しい書き方まで警告して、担当者を疲れさせない配慮です。

二つ目は、AIの出力の扱いです。AIの出力が、文字列を命令として実行する仕組み、データベースへの問い合わせ、画面に表示する部品に届いていないか、また形式を決めずに読み取っていないかを調べる、と README は説明しています。AIの出力は外から来た文章と同じく信用できないものとして扱う、という考え方を、コードの上で確かめる機能です。

どちらも、AIに渡す前と、AIから受け取った後の両方を見るという点で共通しています。指示の乗っ取りそのものを完全に防ぐ方法は、現時点では確立していません。だからこそ、乗っ取られた場合でも被害が操作に変わらないよう、コードの側で出口を絞っておくことが大切になります。この道具は、その出口の絞り忘れを探すものだと理解すると、期待と実際がずれにくくなります。

主な機能2：MCPサーバーと設定ファイルの点検

README で最も詳しく説明されているのが、MCPに関する点検です。自社で作ったMCPサーバーのコードについては、AIが書いた道具の引数が、そのまま命令の実行やファイルの場所の指定に届いていないかを調べます。命令の注入やファイルの場所の書き換え（パストラバーサル）と呼ばれる弱点で、README の例でも、道具の引数がそのまま命令の文字列に組み込まれた箇所を、深刻度の高い問題として報告しています。

道具の説明文に見えない文字や紛れた指示がないか、ほかの道具の振る舞いを横取りするような説明になっていないか、道具の返事を信用しすぎていないか、といった点も対象とされています。これは、道具の説明文そのものを悪用する「道具への毒の混入」と呼ばれる手口への備えです。

MCPの設定ファイルも点検の対象です。README によると、版を固定せずに配布元から毎回取ってくる設定、設定ファイルへの秘密の情報の直書き、暗号化されていない通信、命令を解釈する仕組みを経由した起動の仕方などを指摘します。対象として、Claude Code や Claude Desktop、Cursor の設定ファイルの名前が挙げられています。設定の書き方一つで、知らないうちに版が入れ替わる危なさを見つける点は、運用の担当者にも分かりやすい効用です。

主な機能3：エージェントのスキルとRAGの点検

三つ目は、エージェントのスキル（AIエージェントに読ませる手順書の一式）の点検です。README によると、毒の混じったスキルの手順書や一式をフォルダごと調べ、見た目の似た別の文字への置き換えや、幅のない文字での分断、別の場所に隠した中身といった、見つかりにくくする工夫にも対応すると説明されています。

スキルは、AIエージェントの振る舞いを決める手順書です。外から取り込んだスキルに悪い指示が紛れていれば、エージェントはそれに従ってしまうおそれがあります。README は、スキルが端末の決まった場所に置かれたり、MCPサーバーが設定に加えられたりする入れる前の時点こそが、最も大事な確認の機会だと強調し、入れる前に点検する機能を用意しています。

四つ目はRAGと検索用のデータベースです。利用者ごとの絞り込みをせずに検索している箇所、利用者が書いた内容を共有の保管場所に取り込んでいる箇所、検索で取ってきた文章を強い権限の指示の部分に置いている箇所を指摘する、と README は説明しています。ほかの利用者や取引先の情報が、検索を通じて混ざって見えてしまう事故は、RAGを社内で使うときに最も避けたいものの一つです。

主な機能4：端末に入っているものの棚卸しと、報告の形式

README によると、点検の道具は、端末に入っているMCPサーバーとスキルの棚卸しもできます。Claude Code、Claude Desktop、Cursor、Windsurf、Cline など9種類のAIの道具の利用者ごとの設定を読み、版を固定していない部品、既知の悪い版や弱点のある版、設定への秘密の直書き、暗号化されていない通信、毒の混じったスキルを、実際のファイルと行の位置とともに報告するとされています。

既知の問題がある部品の照合は、手元に持つ情報で行うと書かれています。大規模言語モデル・MCP・RAGの関連の部品について、公表された悪意のある版や、深刻度の高い既知の弱点を、版の範囲まで見て照合するという説明です。ただし、手元の情報がいつ時点のものかによって、新しい問題を拾えない可能性がある点は、使う側が意識しておくべきでしょう。

報告の形式は、画面への表示のほか、SARIF（静的解析の結果を受け渡す共通の形式）、JSON、HTML などに対応しています。SARIF の形式は GitHub のコード点検の画面にそのまま取り込めるとされ、GitHub の自動の仕組みで変更の提案ごとに指摘を表示する使い方も案内されています。このほか、AIの部品の一覧（AI版のSBOM、つまり部品表）や、OWASPの一覧との対応表をつけた脅威の整理を作る機能もある、と README は書いています。

「根拠のあるものだけを報告する」という考え方

点検の道具でよく問題になるのが、誤検知（問題でないものを問題と報告すること）の多さです。指摘が多すぎると、担当者は結果を読まなくなります。SecureAI-Scan の README は、既定の点検では、証明できたものだけを報告するという考え方を前面に出しています。

具体的には、検出に三つの根拠の段階をつけます。流れを実際にたどれたものや設定から読み取れた事実は「証明済み」、危ない出口は特定できたが一か所だけ推定を挟むものは「可能性が高い」、単なる形の一致は「推定」とし、推定の段階は、特別な指定をしない限り表示しないと説明しています。また、過去に誤検知を起こした書き方を試験用の見本として保存し、そこで一件でも検出が出れば試験を失敗させる、という開発の仕方も紹介されています。

この考え方は、担当者の負担を減らすうえで理にかなっています。ただし裏を返せば、既定の点検で何も出なかったことは、問題がないことを意味しないということです。README 自身も、静的な点検は「ふるい」であって安全の境界ではなく、信用できないコードは点検の結果にかかわらず信用できないものとして扱うよう書いています。何も出なかった結果をどう受け止めるかは、使う側が決めておく必要があります。

企業での使いどころ：三つの場面

一つ目の場面は、自社で開発している生成AIのアプリやMCPサーバーの点検です。開発の流れの中で、変更のたびに点検を回し、AIの出力や道具の引数が危ない出口に届く箇所を早めに見つける使い方です。既存の静的解析の道具と並べて使い、AI特有の観点を補う位置づけになります。

二つ目は、外から取り込むスキルやMCPサーバーの受け入れ前の確認です。社員が便利そうなスキルやMCPサーバーを見つけて入れたいと言ってきたとき、入れる前に点検の結果を確かめる、という社内の手続きに組み込めます。README によると、配布元から取ってきた対象は実行せず、点検の後は消す作りだとされています。

三つ目は、社員の端末に入っているMCPサーバーとスキルの棚卸しです。開発者の端末には、いつ誰が入れたか分からない部品が増えがちです。端末ごとの設定を読み、版を固定していないものや既知の問題がある版を洗い出せれば、社内のAIの道具の利用状況を把握する手がかりになります。ただし、確認した一次情報の範囲では、組織全体の端末を一か所でまとめて管理する機能は見当たりません。全社で使うなら、結果を集める仕組みを別に用意する必要があります。

類似の手段との違いを表で比べる

生成AIを組み込んだアプリの安全性を確かめる手段は、ほかにもあります。SecureAI-Scan がどこを受け持ち、どこを受け持たないのかを、代表的な手段と並べて整理します。下の表は一般的な整理で、個別の製品の優劣を比べるものではありません。

手段	主に見るもの	得意なこと	苦手なこと
SecureAI-Scan（コードの点検）	AIの呼び出し・MCP・RAG・スキルの周りのコードと設定	外から入った文章が危ない出口に届く流れを、動かさずに示す	動かしたときの実際の振る舞い、一般的な弱点や秘密の情報の書き込み
一般的な静的解析の道具	コード全体	広く知られた種類の弱点を幅広く探す	AIの出力や道具の引数を、信用できない入口として扱うこと
AIへの攻撃を試す評価（レッドチーム）	動いているアプリの応答	実際に乗っ取られるかを確かめる	コードのどこを直せばよいかの特定、早い段階での発見
人によるコードの確認	設計の意図と変更の中身	業務の文脈に合った判断	量が増えたときの見落とし、確認する人による差

表のとおり、どの手段にも得意と苦手があります。SecureAI-Scan は、コードを書いている段階で、AIの周りの危ない流れを早めに見つけることを受け持つ道具です。動かして確かめる評価や、人による確認の代わりにはならず、組み合わせて初めて守りが厚くなります。

安全性の評価：紹介可とした根拠

このラインでは、紹介するOSSをクローン・インストール・実行せず、公開情報だけで安全性を精査しています。SecureAI-Scan は、精査の基準に照らして「紹介可」と判定しました。根拠にした事実は次のとおりです。

第一に、ライセンスはOSI承認のMITです。第二に、2026年10月23日時点で、リポジトリのセキュリティの欄に公開済みの勧告はありません。第三に、パッケージの設定に、導入時に自動で動く処理は見当たりませんでした。第四に、作者のアカウントは2017年に作られたもので、作成直後のアカウントによる不自然な人気の集め方（スターの急増など）は見られません。スター数は23と小さく、1日あたりの増え方も緩やかです。

加えて、リポジトリにはセキュリティの報告窓口の文書があり、弱点は公開の場ではなく作者へ非公開で知らせるよう求めています。対応の対象は配布された最新の版だけとされています。ただし、問題が見つからなかったことは、安全の保証ではありません。この判定は公開情報から見た範囲のもので、コードの中身を一行ずつ監査したものではない点に注意してください。

注意点：個人の小規模な開発と、作者自身による評価

紹介可と判定したうえで、知っておきたい注意点があります。一つ目は運営体制です。README 自身が、作者一人で保守しているプロジェクトで、対応の期限の約束はないと明記しています。報告窓口の文書でも、数日以内の受け付けを目標にしつつ、正式な期限は設けていません。業務の要になる仕組みとして頼るなら、作者が保守を続けられなくなった場合の代わりの手段を考えておく必要があります。

二つ目は、検出の実績が作者自身の報告だという点です。作者が公開している調査の文書によると、公表済みのMCPの命令注入の弱点6件について、弱点のある版では6件とも検出し、直した版では検出が消えたとされています。また、弱点の公表がない有名なMCPサーバー25件では、既定の段階の検出は出なかったとしています。一方で同じ文書には、最初の版の規則では6件中1件しか検出できず、後から改良したことや、ほかの有名なリポジトリで多数の誤検知が出て直した経緯も書かれています。

こうした率直な記録は信頼の材料になりますが、第三者による独立した評価ではないことは押さえておくべきです。見本として選んだ対象に合わせて規則を改良していれば、見本以外のコードでは同じ精度が出ない可能性もあります。自社のコードでどの程度役立つかは、自社で小さく試して確かめるのが確実です。

悪用されうるリスク

SecureAI-Scan は守る側のための点検の道具ですが、どんな点検の道具にも、使う人しだいで別の目的に使われうる面があります。公開されているコードを点検すれば、そのコードの弱点の候補が見つかります。弱点の候補の一覧は、直す側にとっても、突く側にとっても手がかりになるという点は、ほかの点検の道具と同じです。

README には、検出した弱点について、どう突かれるかと直し方を説明する機能があるとされています。直し方を学ぶうえでは役立ちますが、点検の結果の扱いには注意が要ります。点検の報告を誰でも見られる場所に置いたままにすると、直す前の弱点の一覧を外に示すことになりかねません。報告は、扱える人を限った場所に置くのが基本です。

もう一つの危なさは、点検の道具そのものを過信することです。既定の点検で何も出なかったことを「安全の証明」と受け取り、外から取り込んだスキルやMCPサーバーを確かめずに広げてしまえば、道具がかえって油断の原因になります。現時点で、この道具が悪用されたという報告は確認できていませんが、結果をどう扱うかの決まりがないまま使い始めることが、最も現実的な危なさだと考えられます。

導入を検討するときに確かめること

SecureAI-Scan を社内で使うかどうかを決める前に、確かめておきたい点を順に並べます。具体的な操作の手順ではなく、検討の進め方です。

企業が取るべき対策

SecureAI-Scan を使うかどうかにかかわらず、生成AIを組み込んだアプリを作る企業が備えておきたい点を五つ挙げます。第一に、AIの出力と道具の引数を、外から来た信用できない入力として扱うことを、開発の決まりとして明文化します。命令の実行やデータベースへの問い合わせに使う前に、使ってよい値の範囲を絞ることを原則にします。

第二に、RAGで社内文書を検索させるときは、利用者ごとの絞り込みを必ず入れ、ほかの利用者や取引先の情報が混ざらない作りにします。第三に、MCPサーバーやスキルは、取り込む前に中身を確かめ、版を固定して使います。設定ファイルに秘密の情報を直書きせず、会社が管理する場所にまとめます。

第四に、点検の道具は一つに頼らず、一般的な静的解析、動かして確かめる評価、人による確認と組み合わせます。第五に、社内のAI利用の規程に、外から取り込むAIの部品の受け入れ手順と、点検の結果の扱い方を書き込みます。道具を入れるだけでなく、誰が何を確かめ、何を止めるかを決めておくことが、守りを続ける前提になります。

AIに任せる範囲と、人が決める範囲

点検の道具が出す指摘は、判断の材料です。最近は、点検の結果をAIに読ませて直し方を提案させる使い方も広がっていますが、どの指摘を直し、どの指摘を受け入れるかは、AIに判断させず人が決める範囲です。AIに直し方を提案させる場合も、なぜその直し方なのかの根拠を書かせ、人が原文のコードを見て採否を決めます。

SecureAI-Scan には、確認済みの指摘を理由を添えて個別に抑止する仕組みがあるとされています。便利な仕組みですが、理由の妥当性を誰も確かめないまま抑止が増えれば、点検は形だけになります。人が確認する範囲を先に決めておくことが大切です。避けたい使い方を挙げます。

• 既定の点検で何も出なかったことを、安全の証明として扱う
• 点検の結果をAIに読ませ、直すかどうかの判断までAIに任せる
• 抑止した指摘の理由を、誰も確かめないまま放置する
• 外から取り込むスキルやMCPサーバーを、点検の結果だけ見て中身を読まずに広げる
• 直す前の弱点を含む報告を、誰でも見られる場所に置いたままにする

裏を返せば、人が決めるべきことははっきりしています。何を点検の対象にするか、どの深刻度で変更を止めるか、抑止を認めるのは誰か、外から取り込むものを最終的に承認するのは誰か。AIと点検の道具に任せてよいのは、決められた範囲の中で、候補を洗い出して材料をそろえる部分だけです。

• SecureAI-Scan の機能・設計・ライセンス・運営体制は、GitHubのリポジトリ（README・リリースの一覧・セキュリティの欄・作者の調査の文書）を2026年10月23日に確かめた範囲に基づきます。版の更新で内容は変わる可能性があります
• 検出の実績（公表済みの弱点6件の検出、有名なMCPサーバー25件での結果など）は作者自身の報告で、第三者による独立した評価は確認できませんでした
• 既知の問題がある部品の情報の更新の頻度、組織全体を管理する機能の有無は、確認した一次情報の範囲では確かめられませんでした
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順は扱いません

まとめ

SecureAI-Scan は、大規模言語モデル・MCP・RAG・エージェントのスキルを組み込んだコードと設定を手元で読み、外から入った文章やAIの出力が危ない出口に届く流れを示す、MITライセンスのOSSです。指示の乗っ取り、MCPサーバーの命令注入やファイルの場所の書き換え、道具への毒の混入、RAGの絞り込み漏れ、スキルの悪い指示などを対象とし、根拠のあるものだけを既定で報告すると説明しています。

企業での使いどころは、自社開発のAIのアプリの点検、外から取り込むスキルやMCPサーバーの受け入れ前の確認、社員の端末の棚卸しの三つです。一方で、作者一人の小規模な開発で、検出の実績は作者自身の報告です。一般的な静的解析や人による確認と組み合わせ、結果をどう扱うかを人が先に決めてから使うことが、SecureAI-Scan との現実的な付き合い方です。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。