AIが書いたコードの弱点を手元で検査するOSS「CodeInspectus」を解説

「社員がAIに作らせた社内向けのアプリが、確認のないまま動き始めている。どこに穴があるのか見当がつかない」「AIの書いたコードを検査したいが、ソースを社外の検査サービスに送るのは避けたい」——AIによる開発を現場に任せ始めた企業の、情報システム部門から聞こえてくる声です。検査の道具を一つ入れれば片付く話に見えますが、そうではありません。本当は、検査の道具が何を見て何を見ないのかを知り、結果を人が確かめる仕組みとセットで使うことが要点です。この記事では、AIが書いたアプリの弱点をAIエージェントから呼び出して手元で検査するOSS「CodeInspectus」について、一次情報で確かめられる機能・検査の範囲と限界・通信が起きる場面・配布と運営体制の注意点・導入前に決めることを整理します。導入や操作の手順は扱いません。

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

CodeInspectus は、GitHub上で公開されている検査用のOSSです。READMEによると、AIが書いたアプリや、AIとの対話で勢いよく組み上げたアプリのコードを、利用者の機械の上で検査するもので、AIの開発支援の道具から呼び出せる部品（MCPのサーバー）と、命令を打ち込んで動かす道具の二つの形で提供されています。呼び出し元として、Claude Code、Cursor、Codex、Windsurf、Cline などが挙げられています。

公開の時期と規模も確かめておきます。リポジトリは2026年7月1日に作られ、パッケージの配布の仕組み（npm）にも同じ日に最初の版が登録されています。GitHubの公開版の一覧では、2026年7月27日の1.0から、10月3日の3.3.1まで10の版が並び、npmに登録された版は合わせて18です。2026年10月21日時点で、スターは49、複製（フォーク）は10です。npmの公開統計では、2026年9月19日から10月18日までの1か月の取得数はおよそ930でした。

ライセンスはApache-2.0で、OSI（オープンソースの定義を管理する団体）が承認したライセンスです。READMEは、「一人のセキュリティの実務家がSynvoyaの名前で作り、保守している。背後に会社はなく、売るものもない」と説明しています。公式サイトにも、有料の契約や、提供元の側で解析を行うサービスは見当たりませんでした。

なぜ今、AIが書いたコードの検査が話題なのか

AIの開発支援の道具が広まり、専門の開発者でない人も業務用のアプリを短期間で作れるようになりました。その一方で、READMEが指摘するように、AIが書いたアプリには利用者の画面側に置かれた秘密の鍵、甘い認証、加工しないまま画面に出す文字列、外から紛れ込んだ命令の通り道といった、特有の失敗が出やすいとされます。

こうした失敗は、従来の汎用の検査の道具では拾いにくいものがある、というのが CodeInspectus の出発点です。READMEには、データベースの提供サービス Supabase で、行ごとの読み書きの制限が効いていない作りを狙った問題（CVE-2025-48757 と同じ種類）を検査の対象に含めていると書かれています。誰でも使える部品を組み合わせて素早く作るほど、こうした設定の抜けが本番に紛れ込む危険は増します。

もう一つの背景は、AIの言語モデルの出力をそのまま別の処理に渡す作りの広がりです。OWASP（ウェブの安全性に関する国際的な非営利の団体）は、言語モデルを使う仕組みの主要な危険の一覧2025年版で、モデルの出力を確かめずに後ろの処理へ渡すことを独立した項目に挙げています。CodeInspectus の独自の検査には、この項目に対応するものが含まれています。

三つの既存の検査エンジンと独自の検査をまとめる仕組み

READMEによると、CodeInspectus は検査の中身をすべて自前で作っているわけではありません。広く使われている三つのOSSの検査エンジンを呼び出し、結果を共通の形にそろえたうえで、独自の検査を足す作りです。三つとは、ソースの書き方の危険を調べる Opengrep、コードに書き込まれた秘密の鍵を探す Gitleaks、依存する部品の既知の脆弱性や設定の誤りを調べる Trivy です。

加えて、独自の検査として、READMEでは合わせて94の検出の規則を同梱していると説明しています。そのうち72が CodeInspectus 自身の規則で、半分近くはウェブアプリで多く使われる言語向けです。残りは、スマートフォンのアプリの設定、言語モデルの出力を扱う部分、GitHubの自動実行の設定などに向けた、狙いを絞った少数の規則です。見つかった問題は、弱点の種類を示す国際的な分類番号（CWE）に結び付けて報告されます。

三つの検査エンジンは、利用者が承認したときだけ取得され、npmのパッケージとは別の場所に置かれるとされています。READMEは、各エンジンは版ごとの指紋（ハッシュ値）を固定し、照合が合わなければ動かさないと説明しています。また、それぞれのエンジンは本家のライセンス（Opengrep はLGPL-2.1、Gitleaks はMIT、Trivy はApache-2.0）のまま使われ、改変した複製ではないとしています。

独自の検査が狙う、AIが書いたアプリに多い失敗

READMEに並ぶ独自の検査のうち、企業の防御担当者にとって意味の大きいものを挙げます。一つ目は、利用者の画面側のコードに、管理者用の鍵や秘密の値が含まれていないかです。画面側に置かれた鍵は、誰でも読み出せる状態にあると考えるべきものです。

二つ目は認証と権限です。管理用の機能に、ログインの確認や権限の確認が見当たらないもの、利用者自身が書き換えられる情報をもとに管理者かどうかを判断しているもの、などを指摘するとされます。三つ目は、言語モデルの出力の扱いです。モデルの出力が、そのまま画面に埋め込まれたり、命令として実行される処理に渡されたりしている箇所を探します。

四つ目は、外から紛れ込んだ命令の通り道です。ただしREADMEは、この検査は経験則に基づく未成熟なもので、「可能性がある」という言い方で、確度は中程度として示すと明記しています。ほかにも、記録に秘密を書き出していないか、受け取った内容をそのままデータベースに書き込んでいないか、といった点も見るとされます。いずれも一つのファイルの中で読み取れる範囲に限った検査で、ファイルをまたぐ処理の流れや、動かしたときの振る舞いまでは追わないと説明されています。

検査・修正・再検査を回す流れと「解決」の判定の厳しさ

CodeInspectus の特徴は、検査して終わりではなく、AIエージェントが修正を提案し、直したあとに再検査して、前回と比べる流れを前提にしている点です。READMEによると、再検査の結果は、前回あった問題が「解決」「残存」、新たに出た問題が「新規」に分けて示されます。

ここで評価したいのは、「解決」の扱いの慎重さです。READMEは、前回と同じ条件で、同じ範囲を最後まで調べられた場合に限って「解決」とし、条件がそろわないときは「再確認できていない」と表示すると説明しています。見えなくなっただけの問題を「直った」と扱わない考え方で、問題が消えたことと、問題を直したことを分けて記録する姿勢は、監査の記録としても扱いやすいものです。

同梱されている、AIエージェント向けの作業の決まりでも、修正は一つの問題ずつ、別途の承認を得てから行い、試験と再検査を経るよう求めています。CodeInspectus 自身はリポジトリの試験を動かさないため、試験の実行は呼び出したAIエージェントの側の責任だと明記されています。道具が「解決」と言っても、アプリが壊れていないかの確認は別に要る、ということです。

社内の開発の流れに組み込むための機能

READMEによると、検査の結果は、ほかの検査の道具と共通の形式（SARIF）、表計算ソフトで開ける形式、機械で読み取りやすい形式などで出力できます。表計算ソフト向けの出力では、開いたときに数式として動いてしまう文字を無害にする処理を入れているとされます。前回の検査を基準にして、新しく増えた重い問題だけを止める使い方もできると説明されています。

社内の自動の確認の流れに組み込む場合に重要なのは、調べきれなかったときは「合格」にしないという作りです。READMEは、検査の範囲が一部しか調べられなかったり、範囲が分からなかったりした場合は、問題が見つからなくても不合格として扱うと説明しています。

ほかにも、検査の結果を、改ざんを確かめられる形で一式にまとめて保管する機能や、課題管理の道具に登録するための下書きを作る機能があります。下書きは作るだけで、外部の課題管理の道具へ自動で送ることはしないとされています。秘密の値は、出力の中で伏せ字にされるとも書かれています。記録や証跡を残したい企業にとっては使いどころの多い機能ですが、保管先の権限は自社で決める必要があります。

「検査の時点では外部に送らない」の意味と、通信が起きる場面

READMEと公式サイトは、アカウントは不要、利用状況の送信もしない、検査の時点では外部への通信が一切ないと繰り返し説明しています。ソースを社外の検査サービスに送らずに済む点は、社外秘のコードを扱う企業にとって大きな利点です。

ただし、READMEは言葉を正確に選んでいて、通信がないのは「検査の時点」に限られると自ら注記しています。検査エンジンの取得と、依存する部品の脆弱性の情報の更新は、利用者が承認した準備や修復の操作のときに通信して行われます。脆弱性の情報は、7日より古くなると更新の対象になるとされています。逆に言えば、準備の後に通信を止めた環境では、脆弱性の情報が古いまま検査が進む可能性があります。

また、署名を確かめるための道具（Cosign）を承認のうえで取り込むこと、画像などの出どころの証明を確かめる任意の部品は、その部品自体が導入時に別の取得を行うため既定では入れないこと、なども書かれています。検査の結果を読むAIエージェントの側は別の話で、結果がAIの提供元に送られるかどうかは、呼び出し元の道具の設定で決まります。手元で検査しても、結果に含まれるコードの断片がどこへ流れるかは、自社で確かめる必要があります。

法令や規格への対応表示は「認証」ではない

CodeInspectus は、見つかった問題を、NIST のサイバーセキュリティの枠組み、ISO/IEC 27001、SOC 2、CIS の管理策、OWASP の一覧などの項目に結び付けて報告する機能を持っています。経営層への説明や監査の準備に使いたくなる機能です。

しかしREADMEは、これは「コードから見える範囲の管理策の当てはまりで、認証や監査ではない」と明記し、「何割準拠」といった表示は決してしないとしています。さらに、規格の項目との結び付けはAIが下書きし、保守担当者が確認したもので、外部の第三者による確認を経たものは96のうち0だと、自ら公表しています。

この正直な書き方は評価できますが、受け取る側が取り違えると危険です。社内の報告書に対応表をそのまま貼り、規格への準拠の根拠のように扱うのは避けるべきです。規格への対応の判断は、自社の監査の担当者や外部の監査人が、規格の原文に照らして行うものです。CodeInspectus の対応表は、どの項目に関係しそうかを探す手がかりにとどめるのが妥当でしょう。

ほかの検査の手段との違い

AIが書いたコードの検査には、いくつかの手段が考えられます。READMEで確かめられる範囲で、CodeInspectus の位置づけを、よく比べられる手段と並べます。ほかの手段の欄は一般的な傾向を示したもので、個々の製品によって異なります。

観点	CodeInspectus	汎用の検査エンジンを個別に使う	AIにそのままコードを読ませる
検査の中身	三つの既存エンジンと独自の規則を一つの形式にまとめる	エンジンごとに結果の形式が異なる	決まった規則はなく、毎回の判断
AIが書いたアプリ特有の失敗	独自の規則で一部を狙う（範囲は狭い）	拾えないものがあるとされる	気付くこともあるが再現性がない
ソースの送り先	検査の時点では外部に送らない	製品や使い方による	AIの提供元に送られる
修正後の確認	前回と比べ「解決」「残存」「新規」に分ける	自分で比べる必要がある	前回との比較は保証されない
規格との対応表示	あり（認証ではないと明記）	製品による	根拠の確認が難しい

表から分かるように、CodeInspectus の強みは、決まった規則の検査をAIエージェントの作業の流れの中に組み込めることと、結果の比べ方が厳密なことです。一方で、独自の規則の範囲は狭く、汎用の検査エンジンや人による設計の確認を置き換えるものではありません。

安全性の評価：注意付きとした根拠

このラインでは、OSSを取得・導入・実行せず、公開されている情報と精査の記録をもとに安全性を判定しています。CodeInspectus の判定は「注意付き」です。根拠は次のとおりです。

一つ目は、利用の実績が乏しいことです。公開から4か月足らずで、スターは49、1日あたりの増え方は0.4ほどです。利用者が多い道具ほど不具合や問題が早く見つかりやすいことを考えると、外部の目による確かめはまだ少ないと見るべきです。二つ目は、npmで配布されるパッケージであることです。npmの登録者は一人で、版の更新の頻度も高く、取得する版によって中身が変わります。三つ目として、リポジトリの中に、セキュリティ上の問題の報告窓口を定めた方針の文書は見当たりませんでした。

一方で、精査の範囲では、公開済みのセキュリティ勧告はなく、パッケージの導入時に自動で動く処理も、npmの登録情報には見当たりませんでした。ライセンスはApache-2.0で、利用の条件に特別な制限はありません。作者のアカウントは2015年に作られており、新しく作られたばかりのものではありません。ただし、問題が見つからなかったことは安全の保証ではありません。検査の道具であっても、導入前の確認は他の道具と同じ水準で行うべきです。

配布と運営体制について確かめておきたいこと

CodeInspectus は、npmで配布され、利用者の機械で動くAIエージェント向けの部品として、1台の機械に一度登録して全プロジェクトで共有する作りだとREADMEは説明しています。一度登録すると、その機械で扱うすべてのリポジトリに対して働くことになるため、取得する版の管理が重要です。READMEのバッジによると、AIエージェント向け部品の公式の登録簿にも載っているとされますが、登録簿に載っていることは中身の安全の確認を意味しません。

版の更新は速く、2026年10月3日の3.3.1は、READMEの公開版の説明によると、悪意のある入力を想定して3.3.0を試した結果見つかった問題を直した版で、更新が推奨されています。たとえば、呼び出し側が意図しない場所を検査できてしまう問題や、ファイル名に仕込んだ改行で偽の検査結果の行を作れてしまう問題などが挙げられています。自ら弱点を探して直す姿勢は評価できる一方、古い版を使い続ける危険も示しています。

運営体制は、READMEのとおり個人の保守です。外部からの貢献は、保守担当者が確認して取り込む形とされています。個人の保守の道具は、保守担当者の事情で更新が止まることがありえます。READMEはまた、検査エンジンの一つである Trivy が2026年の初めに配布経路で二度乗っ取られたと述べ、それが指紋の固定を必須にした理由だとしています。この出来事について、この記事では一次情報までは確かめていません。

悪用されうるリスクと、検査の道具ならではの注意点

CodeInspectus は守りのための検査の道具で、攻撃のための機能は説明されていません。それでも、検査の道具ならではの注意点があります。一つは、検査の結果そのものが、弱点の一覧という機微な情報になることです。結果の保管先や、課題管理の道具への登録先が社外に見える場所だと、攻め手に弱点を教えることになりかねません。READMEも、登録の下書きに公開・非公開の別を必ず指定させ、その注意を残すとしています。

二つ目は、AIエージェントに強い権限を与える点です。CodeInspectus には、承認のうえでリポジトリの中の目に見えない文字や、画像などに埋め込まれた記録を取り除く機能が3.3で加わりました。READMEは、正確な計画と明示の承認、元に戻すための控えを前提にするとしていますが、書き換えの機能を持つ部品をAIエージェントにつなぐこと自体が、承認の仕組みに頼る運用になる点は意識しておくべきです。

三つ目は、攻め手が同じ道具を、公開されている他社のリポジトリに向けて使い、弱点を探す可能性です。ただしこれは CodeInspectus に固有の危険というより、汎用の検査エンジンがすでに広く公開されていることの表れと見るのが妥当でしょう。守る側が受け取るべき示唆は、公開しているリポジトリには外から機械的な検査がかけられる前提で、秘密の鍵や甘い権限設定を残さないことです。

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

CodeInspectus を社内の開発で使うかどうかを決める前に、少なくとも次の順で確かめておくと、後からの手戻りを防げます。

企業が取るべき対策

CodeInspectus を使うかどうかにかかわらず、AIによる開発を社内に広げる企業が取るべき対策は共通しています。第一に、AIが書いたアプリを公開する前の検査を、作った人の任意にしないことです。社内向けであっても、外から触れられる場所に置くアプリは、決まった規則の検査と人の確認を経る決まりにします。

第二に、秘密の鍵と権限の扱いを、AIの開発支援の道具に任せないことです。管理者用の鍵を画面側のコードに置かない、権限の判断はサーバーの側で行う、といった基本を、社内の開発の決まりとして明文化します。第三に、検査の道具そのものも、導入する他の部品と同じく、配布元・版・依存する部品の確認の対象にします。

第四に、検査の結果を規格への準拠の根拠として扱わないことです。対応表は手がかりにとどめ、準拠の判断は監査の担当者が行います。第五に、社内のAI利用の規程に、AIエージェントにつないでよい部品の一覧、書き換えの権限を与える条件、検査の結果の保管と公開の範囲を書き込んでおきます。道具を一度入れて終わりにせず、決まりと運用の両方に組み込むことが要点です。

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

CodeInspectus は、決まった規則の検査の結果をAIエージェントに返し、AIエージェントが修正を提案する、という分担を前提にしています。この分担は効率がよい反面、直すかどうかの最終判断をAIに委ねてはいけません。AIに任せてよいのは、検査の結果を読み、問題の箇所と直し方の候補を示すところまでです。

人が決めるのは、どのアプリを検査するか、どの指摘を本当の問題とみなすか、どう直すか、どこまで調べれば十分とするかです。AIエージェントに修正を提案させるときは、なぜその箇所が問題なのか、どの規則に当たったのかという根拠を必ず書かせ、人が読んで確かめることを手順に入れます。避けたい使い方を挙げます。

• AIエージェントが「解決した」と言ったことだけを理由に、修正を本番に出す
• 「再確認できていない」や、一部しか調べられなかった結果を、問題なしとみなす
• 規格への対応表を、そのまま準拠の証拠として社内外に示す
• 検査の結果を、公開のリポジトリの課題の欄にそのまま登録する
• 書き換えの機能を、承認する人を決めないままAIエージェントに使わせる

とくに一つ目は起きやすい失敗です。道具の「解決」は、同じ規則で同じ問題が見えなくなったという意味で、アプリ全体が安全になったという意味ではありません。検査の結果は判断の材料であり、判断そのものではないという線引きを、人が先に決めておくことが大切です。

よくある質問：検査で何も見つからなければ、そのアプリは安全と言えるのか

答えは「調べた規則と範囲では見つからなかった、という意味にとどまる」です。READMEは、独自の規則は一つのファイルの中で読み取れる範囲に限り、ファイルをまたぐ処理の流れ、動かしたときの振る舞い、本番の環境の設定までは確かめないと明記しています。対応していない言語や部品の組み合わせでは、独自の規則は何も働きません。READMEも「対象外」は安全を主張するものではないと書いています。

では検査に意味がないのかというと、そうではありません。AIが書いたアプリに出やすい失敗のいくつかを、同じ物差しで繰り返し確かめられ、修正の前後を厳密に比べられることは、品質の底上げに役立ちます。「安全の証明」ではなく「よくある失敗を早く見つける網」として位置づけるのが現実的です。

もう一つ、「AIに直接コードを読ませるのと何が違うのか」という問いもありそうです。決まった規則の検査は、同じ入力に同じ結果を返します。AIの読み取りは気付きを与えてくれることがある一方、毎回の結果が同じとは限りません。両者は置き換えではなく、組み合わせて使うものと考えるのがよいでしょう。

• CodeInspectus の機能・検査の範囲・通信の扱い・ライセンス・版の情報は、GitHubのリポジトリ（README・ライセンス文書・公開版の一覧・セキュリティの欄）、npmの登録情報、公式サイト、OWASPの項目を2026年10月21日に確かめた範囲に基づきます。版の更新は速く、内容は変わる可能性があります
• 規則の検出の精度、規格との対応の正しさ、Trivy の配布経路の乗っ取りの経緯は、この記事では一次情報で確かめていません
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順は扱いません

まとめ

CodeInspectus は、AIが書いたアプリの弱点を、三つの既存の検査エンジンと独自の規則で手元で検査し、AIエージェントから検査・修正・再検査を回せるOSSです。検査の時点では外部に送らない設計で、調べきれなかった結果を「合格」や「解決」と扱わない慎重さを備えています。

一方で、公開から日が浅く、個人の保守で、スターは49と実績は乏しく、npmで頻繁に版が更新されます。独自の規則の範囲は狭く、規格への対応表示は認証ではありません。人が確認する範囲と承認の決まりを先に整え、版と通信の範囲を確かめたうえで、AIに根拠を書かせ、結果を人が読んで判断することが、CodeInspectus との現実的な付き合い方です。

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