AIが書いたコードの欠陥をOSS「Ship Safe」はどう見つけて確かめるのか

「AIに書かせたコードが増えて、レビューが追いつかない」「検査ツールを入れたら警告が数百件出て、どれが本当に危ないのか分からない」——開発部門と一緒にAIの活用を進める情報システム担当やセキュリティ担当から、こうした声をよく聞くようになりました。多くの場合、答えはもっと多くの問題を見つける道具を入れることだと考えられがちです。しかし本当に必要なのは、見つかった問題が本物かどうかを、根拠と一緒に示してくれることです。この記事では、AIが書いたコードやエージェントの設定を手元で検査し、指摘ごとに「確定」「可能性あり」「未解決」「否定」を根拠付きで返すOSS「Ship Safe」を取り上げ、何を調べるのか、何が外部に送られうるのか、企業が導入前に決めておくべき点を整理します。導入や実行の手順は扱いません。

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

Ship Safeは、GitHubで公開されているOSSです。リポジトリの説明は「AIが書いたソフトウェアのための独立したセキュリティエージェント」で、READMEでは「問題を見つけ、それが本物かを調べ、証拠を示す」と説明されています。利用者の手元のリポジトリで動く道具で、決まった規則で動く中核部分と、鍵がなくても使える検査を前面に出しています。出力の形式は、機械で読める形式と、検査結果を共有するための標準形式のSARIFです。

公開元を確かめます。リポジトリは、2025年4月に作られた個人の開発者のアカウントで2026年2月2日に作られました。このアカウントの公開リポジトリは23件、フォロワーは59人です。ライセンスはMITです。このラインの精査を行った2026年10月19日時点で、スターは860、派生は113、最後の更新は10月17日でした。1日あたりのスターの伸びは約3.3件で、個人の作としては注目を集めつつも、伸び方は自然な範囲と読めます。

更新の速さも特徴です。リリースの一覧によると、9月1日に9.8.0版と9.9.0版、9月5日に10.0.0版、9月21日に10.1.0版、10月8日に11.0.0版が出ています。わずか5週間あまりで大きな版が二度上がっている計算です。READMEには有償の機能の案内もあり、手元で使う検査の道具そのものは無償でMITですが、クラウドで動く管理画面などの有償の機能は、公開されていない別のリポジトリで開発されていると書かれています。

なぜ今「AIが書いたコード」の検査が問われるのか

コード生成のAIやAIエージェントが開発の現場に入り、人が一行ずつ書いて確かめる前提が崩れつつあります。書く速さが上がった分、確かめる側の手が足りなくなります。Ship Safeの作者は、AIが生成したコードや大きく手を入れたコードが、リポジトリに入る前に危ない箇所を手早く確かめることを狙いとしています。

もう一つの変化は、検査の対象そのものが広がったことです。今のリポジトリには、アプリケーションのコードだけでなく、AIエージェントへの指示文、MCP（AIが外部の道具を使うための接続の仕組み）の設定、エージェントが読む文書が置かれます。そこに紛れ込んだ不正な指示は、従来のコード検査では見落とされやすい場所にあります。READMEが検査の対象として、AIと大規模言語モデルの安全性、MCPとエージェントの設定を最初に並べているのは、この変化を意識したものと考えられます。

三つ目は、警告の多さです。READMEによると、人気のある四つのOSSを検査したときの指摘の数は、ある版の前には合計1,031件あったものが、現在は38件に減ったとされています。作者自身が、誤った警告を減らすことを開発の大きな課題として扱っていることが読み取れます。数を誇るより絞り込みを重視する方向は、運用する側から見て歓迎できるものです。

一段目：決まった規則で問題を拾う検査

READMEによると、Ship Safeの一段目は「決定的なエンジン」と呼ばれる部分です。同じ入力には同じ結果を返す、規則に基づく検査で、READMEはこれを「感知の層」と位置づけています。速く、繰り返し同じ結果が出て、性能の測定もしているとされています。

検査の範囲は広く、READMEの表では六つの領域が挙げられています。AIと大規模言語モデルの安全性（指示の乗っ取り、エージェントへの過剰な権限、記憶や検索用データへの毒の混入、危険な道具の呼び出し）、MCPとエージェントの設定（広すぎる道具の権限、信用できない接続先）、アプリケーションの安全性（データベースへの不正な命令の差し込み、認証のすり抜けなど）、秘密情報（鍵や資格情報、履歴に残った秘密）、供給網（紛らわしい名前のパッケージ、インストール時に動く危険な処理）、CI/CDの設定（版を固定していない外部部品の利用、秘密の記録への書き出し）です。

公式ドキュメントでは、これらを受け持つ専門の検査役が29あるとされ、READMEの表では30、例の中には31という数も出てきます。資料によって検査役の数が食い違っているのは、版の更新が速いことの表れと考えられます。数そのものより、自社のリポジトリに関係する領域が含まれているかを見るのが現実的です。

二段目：指摘が本物かを調べる層

Ship Safeの特徴は、二段目の「調査の層」にあります。READMEによると、この層は一段目の指摘にどれだけの価値があるかを決める部分です。外から入ってきた値が危ない処理まで実際に届くかをたどる、規則が「ない」と言う対策が本当にどこにもないかをプロジェクト全体から探す、一つのファイルだけでは分からない設定のつながりから攻撃の筋道を組み立てる、といった調べ方が挙げられています。

調べた結果、指摘は四つに分けられます。確定、可能性あり、未解決、否定です。READMEは、結論ごとに、それを出した調べ方と、読んだ行を必ず示すと説明しています。READMEに載っている例では、教材用にわざと弱点を入れたNodeGoatという練習用アプリを調べ、外からの値が三つのファイルをまたいで危ない処理に届く経路を、行番号付きで示しています。

調べ方の間には優先順位があります。READMEによると、値の流れを実際にたどった結果は、AIが同じファイルを読んだ解釈より上に置かれ、安い調べ方が、より確かな調べ方の結論をひっくり返すことはないとされています。利用者は重要度の札ではなく、判定の一つひとつの段階に対して異を唱えられる、という考え方です。AIの読みを最上位に置かない設計は、守りの側から見ても筋が通っています。

エージェントの周りを確かめる機能

READMEには、AIエージェントを使う開発者向けの機能もいくつか載っています。一つは、知らないフォルダをエージェントで開く前に、開いただけで自動的に動くものがないかを確かめる機能です。採用試験の課題や外部から受け取ったコードを、エージェント付きの編集ソフトで開く場面を想定したものと読めます。

もう一つは、そのリポジトリで作業するAIエージェントが、実際に何に届きうるかを示す機能です。10.0.0版のリリースノートでは、この機能が新しく加わったと書かれています。エージェントに渡している権限の棚卸しに近い考え方で、「エージェントに何ができてしまうか」を先に見える形にすることは、権限を絞る判断の材料になります。

このほか、公式ドキュメントでは、エージェントが読む文書、指示文、MCPや道具の設定に対して、AI同士に攻め役・守り役・審判役を演じさせる模擬攻撃の機能が紹介されています。この機能は外部のAIを使います。中身を外に出してよいかの判断が要る機能であり、後の章で扱う情報の流れと合わせて考える必要があります。

修正を提案する機能と、その限界

Ship Safeには、指摘への修正を提案する機能もあります。READMEによると、修正のエージェントは計画と変更の差分を示し、書き込む前に利用者に確認し、変更を元に戻せる形で残します。修正を別の作業用の枝で行い、取り込みの依頼まで作る使い方も紹介されています。

注目したいのは、作者が修正の確かめ方の限界を自ら文書にしている点です。修正の検証についての文書は、検査で指摘が出なくなったことは、修正できた証明ではないと明記しています。行っているのは修正の前後の検査結果を比べる静的な確認で、攻撃を再現したり、独立に試験し直したりするものではないとされています。

文書には、ほかにも限界が並んでいます。指摘の照合は規則・ファイル・近くの行の範囲で行うため、指摘が別の場所に動いただけの場合は修正済みと証明されないこと、依存パッケージや外部への問い合わせは比べる範囲に入らないことなどです。一方で、公式ドキュメントには、人の確認を挟まずに修正を当て続ける使い方も用意されていると書かれています。限界を明記した文書と、無人で修正を当てる使い方が同じ道具の中にある以上、どちらを使うかは導入する側が決める話です。

CIに組み込むときの考え方

Ship Safeは、CI（コードを変更するたびに自動で検査や試験を走らせる仕組み）に組み込む使い方も想定しています。READMEによると、重要度が一定以上の指摘があれば処理を失敗させることができ、検査結果をGitHubのコード検査の画面に送ることもできます。

9.8.0版からは、重要度ではなく、調査の結果が「確定」になったものだけで止める使い方もできるとされています。可能性の段階の指摘で開発を止めず、裏付けが取れたものだけを止めるという考え方です。また、取り込みの依頼ごとに、信頼できる基準の検査結果と比べて、新しく入った指摘だけを扱う使い方も紹介されています。READMEによると、この比較用の記録には秘密の値そのものは保存されず、指摘の識別子は変換した値で残されます。

記録の扱いにも配慮が見られます。11.0.0版から、機械で読める形式の結果には版と作成時刻が入り、ファイルの場所は既定でプロジェクトからの相対の位置で書かれます。READMEは、手元の端末のフォルダ名が結果から漏れないようにするためと説明しています。また、コード内の除外の印では重大な指摘を隠せず、除外した数は結果に数えられるとされています。

何が外部に送られうるのか

検査の道具は、社内のコードを読む道具です。何が外に出るかは、導入の判断で最も重要な点の一つです。公式サイトの「セキュリティとデータの流れ」の資料によると、AIを使わない設定での手元の検査では、Ship Safeの運営にもAIの提供元にも何も送られないとされています。

一方で、外部に送られる場面もはっきり書かれています。AIの提供元を指定して判定させる場合は、指摘の情報と該当するコードの抜粋が送られ、標準の判定では抜粋は100字までですが、深い分析ではもっと広い範囲が含まれうるとされています。先に触れた模擬攻撃の機能では、標準で最大12ファイル・合計6万字まで、長い文脈を扱うモデルでは最大60ファイル・合計25万字までが送られうると書かれています。送る前に鍵らしき文字列を伏せる処理はありますが、資料自身が「できる限り」の処理で、社内の機微な情報をすべて捉える保証ではないと述べています。

特に注意したいのは、資料にある次の一文です。環境にAIの提供元の鍵が置かれていると、AIによる判定が既定で有効になることがある。完全に手元で済ませたい場合は、AIを使わない指定をするよう勧めています。このほかREADMEによると、漏れた鍵が有効かを提供元に問い合わせる機能は、その鍵を提供元に示すことになると明記された上で、利用者が選んだときだけ動きます。また、対話型の画面には、検査の結果を7日間公開の場所に載せる機能があるとされています。

似た手段と何が違うのか

コードの安全性を確かめる手段は、ほかにもあります。READMEは、Ship SafeをSemgrep、Gitleaks、Trivy、CodeQLといった既存の検査ツールの代わりではなく、それらを補うものと位置づけています。確認できた範囲の事実をもとに、どこを見るかの違いとして比べます。

見る点	人によるコードレビュー	従来の静的な検査ツール	Ship Safe
主な対象	変更されたコード	コードと依存パッケージ	コード、依存、CI/CD、エージェントやMCPの設定、指示文
指摘の確からしさ	レビューする人の力量しだい	ツールにより、多くは重要度の札で示す	確定・可能性あり・未解決・否定の四つに分け、根拠の行を示す
AIエージェント特有の危険	知識しだい	対象外のことが多い	検査の領域として明示
外部への送信	なし	ツールによる	手元の検査ではなし。AIによる判定などを使うと送られる
修正	人が書く	提案のみのものが多い	差分を示して確認の上で書き込む。無人で当てる使い方もある

表のとおり、Ship Safeが強みとするのは、検査の範囲の広さと、指摘の確からしさの示し方です。逆に、性能の裏付けはまだ限られています。既存の検査ツールと置き換えるのではなく、重ねて使うという作者自身の位置づけに沿って考えるのが妥当でしょう。セキュリティ方針の文書も、本ソフトを保証ではなく補助の道具と書き、他の検査や秘密情報の入れ替えと組み合わせるよう勧めています。

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

このラインでは、紹介するOSSを公開されている事実だけで精査しています。OSSを入手したり動かしたりはしていません。Ship Safeの判定は「注意付き」です。重大な問題が見つかったわけではありませんが、導入する側が先に確かめるべき点が二つあるため、迷った場合は注意付きに寄せるというこのラインの基準に従いました。

問題が見つからなかった点から挙げます。公開元は2025年4月に作られた個人の開発者のアカウントで、作られて間もないアカウントではありません。スターの伸びは1日あたり約3.3件で、不自然な水増しの兆候は見られませんでした。ライセンスはMITです。GitHub上にこのリポジトリのセキュリティ勧告は登録されていません。配布用のパッケージの設定には、インストールしたときに自動で動く処理は登録されていませんでした。セキュリティ方針の文書があり、弱点の報告は非公開の窓口で受け付け、48時間以内に受領を返すとしています。

注意付きとした理由の一つ目は、外部への送信です。公式サイトの資料によると、環境にAIの提供元の鍵が置かれていると、外部のAIによる判定が既定で有効になることがあるとされています。送られる範囲は、標準の判定ではコードの抜粋100字までですが、模擬攻撃の機能では最大60ファイル・合計25万字に及びうると書かれています。二つ目は、セキュリティ方針の文書が支援の対象として10系と9系だけを挙げ、10月8日に出た最新の11系を挙げていない点です。最新版が修正の対象に入るのかが、確認した範囲では分かりませんでした。

なお、問題が見つからなかった点についても、安全の保証にはなりません。精査は公開情報の範囲に限られ、コードの中身を検証したものではないからです。本ソフトは社内のコードを丸ごと読む道具です。評価は導入する側でも重ねる必要があります。

導入前に知っておきたい注意点

第一に、運営の体制です。公開元は個人の開発者で、実績はまだ1年半ほどです。版の更新は速く、大きな版が5週間あまりで二度上がっています。さらに、確認した時点のセキュリティ方針の文書では、支援の対象は10系と9系とされており、10月8日に出た11系の扱いは書かれていませんでした。版を固定して検証し、更新の確認を担当として決めておく必要があります。

第二に、性能の裏付けです。公式サイトの性能の資料は、作者自身が9.5.2版で行った評価で、「独立した検証ではない」と明記されているものです。12組の人工的な見本で、弱点のある見本はすべて検出し、安全な見本では誤って指摘しなかったとされていますが、資料自身が、実際の本番のリポジトリでの性能や誤検知の割合を示すものではないと述べています。他の検査ツールとの比較も、今後の課題とされています。

第三に、情報の流れです。前の章で見たとおり、環境に提供元の鍵があるとAIによる判定が既定で有効になることがあり、送られる範囲は機能によって大きく変わります。検査の状態はプロジェクトの中の専用フォルダに保存され、AIの応答の一時的な記録も含まれるとされています。資料はこのフォルダを版の管理から外すよう勧めています。また、有償のクラウドの機能では、検査結果や指摘がShip Safeの運営側で処理されるとされ、その保存期間は確認した資料には書かれていませんでした。

悪用されうるリスク

Ship Safeは守りのための道具で、攻撃のための道具ではありません。それでも、使い方しだいで生まれうる危険はあります。最も大きいのは、「検査で何も出なかったから安全」という安心が独り歩きすることです。作者自身が、指摘が出なくなったことは修正の証明ではないと書いています。

次に挙げるのは推測ですが、検討の材料になります。この種の道具は、リポジトリの中の弱点や漏れた鍵の一覧を作ります。その結果が外部に出れば、攻撃者にとっての宝の地図になりえます。結果を公開の場所に載せる機能や、有償のクラウドの機能に結果を預ける場合は、誰が見られるのか、いつ消えるのかを確かめる必要があります。

もう一つは、検査の道具そのものが供給網の一部になる点です。Ship Safeは配布用の登録所を通じて配られ、更新も速い道具です。開発者の端末やCIで動き、社内のコードと、場合によってはAIの提供元の鍵に触れます。一般論として、こうした道具の配布経路が乗っ取られれば影響は大きくなります。なお、Ship Safeが実際に悪用された事例は、2026年10月19日時点で確認した一次情報からは見つけられませんでした。

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

検討するときは、動かす前に、資料と社内の取り決めで確かめられる点から整理します。下の手順は、OSSを動かす前の段階で終えられるものに絞っています。

この手順の要は、検査を始める前に、外に出してよい範囲と、指摘を誰が確かめるかを決めておくことです。道具の設定は、その決まりを機械に移したものにすぎません。

企業が取るべき対策

一つ目は、AIが書いたコードの扱いを社内の決まりに入れることです。Ship Safeを使うかどうかにかかわらず、AIが書いたコードを、人が書いたコードと同じかそれ以上の確認を経てから取り込むことを決めておきます。二つ目は、リポジトリの中にあるエージェントへの指示文やMCPの設定を、コードと同じく検査とレビューの対象に入れることです。

三つ目は、検査の道具に渡す情報の管理です。検査の道具が動く端末やCIに、AIの提供元の鍵をむやみに置かないようにし、どの道具がどこへ何を送るかを一覧にします。四つ目は、検査結果の管理です。弱点や漏れた鍵の一覧は機微な情報として扱い、保存場所と見られる人を絞ります。漏れた鍵が見つかった場合は、検査で消えたかどうかではなく、鍵そのものを無効にして入れ替えることを手順にします。

五つ目は、調達のときの確認です。個人の開発であること、版の更新が速いこと、性能の資料が作者自身の評価であること、セキュリティ方針の対象の版を踏まえ、社内で使える段階かどうかを文書で判断します。既存の検査ツールと重ねて使い、一つの道具の結果だけで合否を決めない運用にすることも大切です。

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

Ship Safeは、AIが書いたコードを確かめるための道具であり、その中でもAIを使えます。だからこそ、AIに判断させない部分を先に決める必要があります。道具の作りそのものも、値の流れをたどった結果をAIの読みより上に置き、結論ごとに根拠の行を示す形になっています。

具体的には、どの指摘で開発を止めるか、「否定」とされた指摘を本当に捨ててよいか、修正を取り込むか、何を外部に送ってよいか。この四つはAIにも道具にも委ねず、人が決めて記録に残します。AIによる判定を使う場合も、判定の根拠を書かせ、最後に人が確かめる流れにしておくと、後から判断を振り返れます。人が確認する範囲は、検査を始める前に決めておきます。やってはいけない向き合い方を挙げます。

• 検査で指摘が出なくなったことを、修正が終わった証明として扱う
• 「否定」と判定された指摘を、根拠の行を読まずにまとめて捨てる
• AIの提供元の鍵を置いたままの端末で、外部に送られていないと思い込んで検査する
• 人の確認を挟まずに修正を当てる使い方を、本番につながるリポジトリで常用する
• 弱点や漏れた鍵の一覧を、公開の場所や誰でも見られる共有先に置く
• 一つの検査ツールの結果だけで、リリースしてよいかを決める

裏を返せば、人が決める範囲ははっきりしています。何を外に出し、何で止め、誰が確かめ、誰が取り込むか。この四つが決まっていないまま道具を入れても、守りの厚みは増えません。

よくある質問：根拠付きの判定があれば人のレビューは要らないのか

答えは「要ります」です。Ship Safeの判定は、確定・可能性あり・未解決・否定のどれかに分けられ、根拠の行が示されます。しかし、セキュリティ方針の文書は本ソフトを保証ではなく補助の道具と書き、修正の検証の文書も静的な確認であって証明ではないと明記しています。根拠が示されることは、人が判断しやすくなることであって、人の判断が要らなくなることではないと受け止めるべきです。

では入れる意味がないのかというと、そうではありません。指摘ごとに根拠の行が示されれば、レビューする人は重要度の札ではなく、判定の段階のどこに異を唱えるかを考えられます。エージェントの設定やMCPの設定といった、従来の検査では見落とされやすい場所を対象に入れている点も、AIを使う開発では役に立つ可能性があります。

もう一つ、「無償で手元だけで動くなら、すぐ全社に広げてよいのではないか」という問いもありそうです。確認した範囲では、実際の本番のリポジトリでの性能を示す独立した評価は見つけられませんでした。まずは機微な情報を含まないリポジトリで、外部に送る機能を切った状態から試し、既存の検査ツールの結果と見比べる、という段階を踏むのが妥当でしょう。

• Ship Safeの機能・版・情報の流れ・制限は、GitHubのリポジトリとその中の文書、リリースの一覧、公式サイトの資料を2026年10月19日に確かめた範囲に基づきます。版の更新が速いため、内容は変わる可能性があります
• 検査役の数は資料によって29・30・31と食い違っていました。また、セキュリティ方針の文書で11系が支援の対象かどうか、有償の機能で預けた情報の保存期間は、確認した一次情報の範囲では確かめられませんでした
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順は扱いません

まとめ

Ship Safeは、AIが書いたコード、AIエージェントやMCPの設定、依存パッケージ、CI/CDの設定、秘密情報の漏れを手元で検査し、指摘が本物かを確定・可能性あり・未解決・否定に分けて、根拠の行と一緒に示すOSSです。個人の開発者がMITで公開しており、GitHub上にセキュリティ勧告は登録されておらず、インストール時に自動で動く処理も見つかりませんでした。

一方で、外部のAIにコードの一部を送る機能や結果を公開する機能があり、環境に置いた鍵で既定の動きが変わりうること、性能の資料が作者自身の評価であること、版の更新が速いことは押さえておく必要があります。外に出してよい範囲、止める基準、確かめる人、取り込む人を先に決めたうえで使うことが、AIがコードを書く時代のShip Safeとの付き合い方です。

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