OSSに広がるAIコーディングエージェント痕跡から考える、ソフトウェア調達と保守の新しい確認項目

結論：問うべきは「AIで書いたか」ではなく「AIが書いた箇所を説明・検証・保守できるか」

オープンソース上のコミットやプルリクエストから、AIコーディングエージェントの利用痕跡を機械的に検出できることが研究で示され始めました。ここから調達側が学ぶべきなのは、「AIを使ったベンダーを避ける」ことではありません。すでにAIは開発現場に広く浸透しており、痕跡が残っていること自体は珍しくない、という前提に立つべきです。

危険なのは、AIを使ったこと自体ではなく、AIが関与した範囲・レビュー方法・テスト証跡・出所・保守可能性を発注者が確認できない状態で納品を受けることです。この記事では、システム発注者、CTO、情シス、開発会社選定担当が、開発会社選定・コードレビュー・保守引き継ぎ・AI生成コードの利用ルール・納品物監査の場面で、いま追加すべき確認項目を具体的に整理します。要件や体制の整理から相談したい場合は、システム開発・AI基盤の相談をご利用ください。

この記事を読むべき会社

• システム開発を外注し、納品物の中身をどこまで確認すべきか判断しかねている発注者
• 自社開発・受託開発でAIコーディングエージェントの利用ルールを整備したいCTO・開発責任者
• ベンダー選定基準を更新したいが、AI利用をどうRFPに書けばよいか分からない情シス・調達担当
• 過去に外注したシステムの保守を引き継ぐ・引き継がせる場面で、ソースの出所や品質に不安がある会社

この記事の根拠と最新性

根拠として参照した公式情報・研究は次の通りです（2026年7月10日確認）。法令・料金・ライセンス解釈・攻撃条件は流動的です。判断の前に最新版を確認し、法的効果の判断は顧問弁護士に確認したうえで使ってください。数値は各出典の公表値であり、記事末尾の「参考・出典」に一次情報のURLをまとめています。

• AIコーディングエージェントのOSSへの浸透（180万リポジトリ調査）: https://arxiv.org/abs/2606.24429
• AIエージェント導入による生産量への影響研究: https://arxiv.org/abs/2607.01418
• 生成AIが実在しないパッケージを提案する現象（USENIX Security 2025）: https://arxiv.org/abs/2406.10279
• 経済産業省 SBOM導入の手引 ver2.0: https://www.meti.go.jp/press/2024/08/20240829001/20240829001.html
• NIST AI RMF: https://www.nist.gov/itl/ai-risk-management-framework
• OWASP GenAI Security Project: https://genai.owasp.org/

OSS調査から見える変化：AI利用は「隠せる前提」で考える

研究が示すのは、コミットメッセージの言い回し、変更のまとまり方、レビューのやり取り、生成物の特徴といった複数の手掛かりから、人手だけでは判別しづらいAIエージェントの関与を推定できる、という点です。1億8,000万規模のリポジトリを横断した調査（arXiv:2606.24429）では、設定ファイル・コミットメッセージ・作者情報・ボット署名を組み合わせて検出しており、特定のツールだけでも数十万件規模のコミットが観測されたと報告されています。同調査では、ボットアカウントの照合だけに頼るとあるツールのコミットの3.3%しか捕捉できなかったとも述べられており、単一の目印でAI利用を見分けようとすると大きく取りこぼすことが数値でも示されています。「AIで作りましたか」という一問一答で確認しても、意味のある答えは返ってきません。

別のフィールド研究（arXiv:2607.01418）では、コマンドラインAIエージェントを導入した組織で、利用者のマージ済みプルリクエストがベースラインより約24%増えたと報告されています。ただし著者自身が、マージ数はあくまで出力の代理指標であり、実際に届いた価値を完全には表さないと断っています。この留保が調達側にとっては重要です。「AIで速く出せる」ことと「発注者が受け取る価値が高い」ことは別問題であり、速度の裏でレビューや検証の密度が落ちていないかを、発注者が別途確かめる必要があります。

調達側にとっての含意は3つです。

• AI利用の有無を白黒で問うのは実務的でない。すでに広く使われており、痕跡が残ること自体は品質の高低を意味しない。
• 見るべきは「AIが関与した箇所に、人間のレビューとテストが通っているか」という検証プロセスの証跡であり、AI生成そのものではない。
• 痕跡を隠せる以上、性善説の自己申告ではなく、契約と納品物で検証できる形に落とし込む必要がある。

AIを使った開発より、AIの利用を説明できない開発のほうが、後工程の監査・保守・事故対応でつまずきます。ここが調達判断の起点になります。

発注者が新しく足すべき7つの確認項目

従来のシステム調達チェック（機能・費用・納期・実績）に、AIコーディングエージェント時代の観点を上乗せします。特別な技術知識がなくても、次の7項目は発注者から聞けます。

1. AI利用の開示範囲 — どの工程（設計・実装・テスト・ドキュメント）でAIを使うか。全面禁止ではなく、使う前提でどう管理するかを聞く。
2. 人間レビューの単位 — AI生成コードを含むプルリクエストを、誰が、どの基準で、どこまでレビューして承認するか。
3. テスト証跡 — 自動テスト・カバレッジ・手動テストの記録が納品物として残るか。「動きました」ではなく、何を確認したかの記録を求める。
4. 依存関係と出所 — 使用したOSSライブラリの一覧、ライセンス、バージョン、既知脆弱性の確認結果（SBOM相当）を提出できるか。
5. セキュリティスキャン — 静的解析・依存脆弱性スキャン・シークレット混入チェックを実施し、結果を共有できるか。
6. 著作権・ライセンスの整理 — AIが出力したコードや取り込んだ依存物のライセンス整合を、誰が確認したか。
7. 保守引き継ぎ資料 — 設計意図、非自明な実装判断、テスト手順、運用手順を、担当者交代後も追える形で残すか。

この7項目は、AIを使うベンダーを落とすためのものではありません。AIを使っても品質と説明責任を担保できるベンダーを見分けるためのものです。回答をそろえさせるだけで、見積金額の差、責任範囲の差、保守思想の差が可視化されます。

RFPと契約に明記する条項

口頭の合意は納品時に食い違います。次の項目はRFPまたは契約に文言として残します。

特に「AIが生成したから責任を負わない」という抜け道を作らせないことが重要です。誰が書いたかにかかわらず、納品物の品質と権利処理はベンダー責任である、と明記します。

AI生成コードで見落としがちな3つのリスク

1. ライセンス混入 — 生成物が学習元の特定ライセンスコードに酷似する可能性はゼロではありません。コピーレフト系ライセンスの断片が商用クローズド製品に混じると、公開義務や利用制約の論点になり得ます。依存物・生成物のライセンス確認を工程に組み込みます。
2. もっともらしい欠陥 — AI生成コードは読みやすく自然に見えるため、レビューが甘くなりがちです。境界値処理、エラー処理、権限チェック、入力検証といった「地味だが事故る箇所」が抜けていないか、人間が重点的に見ます。OWASPのGenAI関連ガイドは、生成AIを含む開発のリスク観点を整理する出発点になります。
3. 説明できない実装 — 「なぜこの設計にしたか」が誰にも答えられないコードは、保守で必ず詰まります。非自明な判断には理由をコメント・ドキュメントに残す運用を、契約段階で求めます。

AIが提案した依存関係をそのまま入れると何が起きるか

AIコーディングエージェントは、コードだけでなく「このライブラリを使いましょう」という依存パッケージの提案も出します。ここに、非エンジニアの経営者が見落としやすい落とし穴が3つあります。

存在しないパッケージ名の提案（タイポスクワッティングの餌）。 生成AIは、実在しないパッケージ名をもっともらしく提案することがあります。16種類のモデルで57万6,000件のコードを生成した研究（arXiv:2406.10279、USENIX Security 2025採択）では、商用モデルで少なくとも5.2%、オープンソースモデルで21.7%の割合で実在しないパッケージが提案され、ユニークな架空パッケージ名は20万5,474件に上ったと報告されています。問題は、この「よく提案される架空の名前」を攻撃者が先回りして本物として登録しておく手口（いわゆるタイポスクワッティング／スロップスクワッティング）です。開発者やAIが疑わずにその名前を入れると、悪意あるコードを自ら取り込むことになります。名前が合っているというだけでは安全の証明になりません。

メンテされていないライブラリ。 AIは過去のデータをもとに提案するため、すでに開発が止まったライブラリや、作者が更新をやめたものを勧めることがあります。動く時点では問題がなくても、脆弱性が見つかったときに直す人がいません。数年後の保守で、動かすために古い依存ごと塩漬けにするか、大きく作り直すかの二択を迫られます。

ライセンスの不整合。 AIは「使える」ことは示しても、「自社の事業で使ってよいか」までは判断しません。後述するように、ライブラリのライセンスによっては自社製品への組み込みや顧客への納品に条件が付く場合があり、そこを確認しないまま取り込むと、あとから整理し直す手戻りが発生します。

いずれも、AIが悪いのではなく、AIの提案を人が確認する工程が抜けていることが原因です。速く出せることと、そのまま入れてよいことは別だという前提を、発注側・受注側の双方で共有しておく必要があります。

取り込む前に確認する5つの観点：誰に何を確認させるか

依存ライブラリを1つ増やすことは、外部の他人が書いたコードを自社システムの一部として引き受けることです。経営者自身がコードを読む必要はありませんが、「誰に何を確認させるか」の形で次の5点を回せる状態にしておくと、事故の多くは入り口で止められます。

ポイントは、これを「感覚」ではなく「提出物」で回すことです。口頭の「大丈夫です」ではなく、依存一覧・スキャン結果・ライセンス一覧という紙で受け取れば、非技術者でも欠けている項目に気づけます。判断できる人が社内にいない場合は、開発の見積・提案を第三者視点でレビューする相談のように、外部の目を一度入れて確認の型を作るのが現実的です。

ソフトウェア部品表（SBOM）は中小企業でどこまで作れば回るか

SBOM（Software Bill of Materials、ソフトウェア部品表）とは、そのシステムが使っている部品（依存ライブラリ）の一覧を、名前・バージョン・ライセンスなどとともに機械可読な形でまとめたものです。食品の原材料表示に近いもので、「うちのシステムは何でできているか」を一枚で示せる状態を指します。

価値は明快です。脆弱性が公表されたときに「うちは使っているか」を一覧の検索で即答できること、ライセンスの棚卸しが定常的に回ること、そして保守や乗り換えの引き継ぎがしやすくなることです。経済産業省もSBOM導入の手引（ver2.0）を公表しており、脆弱性管理プロセスへの組み込み方、費用と効果を踏まえた導入範囲の決め方、委託先との契約に定めるべき事項（要求・責任・費用分担・権利など）まで整理されています。中小企業でも回せる範囲を意識して作られている点が実務的です。

中小企業で現実的に回す範囲としては、次のように段階を踏むと過負荷になりません。

• まずは自社にとって重要な1システムだけを対象にする（全システム一斉は挫折する）。
• 完璧な粒度を狙わず、直接使っている主要な依存と、そのライセンス・バージョンを台帳にする。
• 生成と更新は、ビルドの過程で自動的に吐き出す仕組みにして、人手更新を前提にしない。
• 受託開発を使っているなら、SBOMの提出を納品物の条件にして、自社で一から作らずに受け取る。

SBOMは「作ること」自体が目的ではありません。脆弱性が出た日に検索できて、ライセンスを説明でき、次の担当者に渡せる——この3つが回るなら、粒度は完璧でなくても十分に元が取れます。

ライセンスの種類が事業に効いてくる場面

OSSライセンスには、ゆるやかに使えるものから、二次的な公開や表示を条件とするものまで幅があります。ここで大切なのは、同じライブラリでも「どう使うか」で条件の効き方が変わり得るという点です。代表的な3場面を挙げます。

• 自社製品に組み込んで配る場合 — ソフトウェアを顧客の環境にインストールする形で渡すとき、組み込んだOSSのライセンス条件（表示義務や、改変部分の扱いなど）が関わってくることがあります。
• 顧客に納品する場合 — 受託開発の成果物として引き渡すとき、中に入っているOSSの条件と、契約上の権利処理（著作権の帰属、第三者権利の非侵害）の両方を確認する必要があります。
• SaaSとして提供する場合 — 自社サーバで動かして画面越しに使ってもらう形態は、配布とは条件の効き方が異なる場合があります。「配っていないから関係ない」と単純化できないケースがあることに注意します。

ここで本記事は、どのライセンスがどの場面でどう効くかという法的効果を断定しません。ライセンスの解釈は使い方・改変の有無・提供形態で変わり、最終的な判断は顧問弁護士や専門家に確認すべき領域だからです。経営者がやるべきことは、法解釈を自分で下すことではなく、「自社は組み込み／納品／SaaSのどれに当たるか」を整理し、使っているOSSのライセンス一覧を用意したうえで、判断を専門家に委ねられる状態を作ることです。

脆弱性が公表された日に「うちは使っているか」を即答できる状態

依存ライブラリに深刻な脆弱性が公表される日は、いつか必ず来ます。そのとき事業の明暗を分けるのは、脆弱性そのものの深刻さより、「うちは影響を受けるか」を何分で答えられるかです。答えに数日かかる会社は、その間ずっと無防備なまま、しかも動くべきかどうかの判断もできません。

即答できる状態は、次の3つがそろっていれば作れます。

• 部品の一覧がある — 前述のSBOMや依存一覧があり、「使っているか」を検索で確認できる。
• バージョンが固定・記録されている — 「たぶんこのへんのバージョン」ではなく、どのシステムがどのバージョンを使っているかが台帳で分かる。
• 直す担当と手順が決まっている — 影響ありと分かった後、誰が、いつまでに、どうやって更新・再テスト・再デプロイするかが事前に決まっている。

受託開発に出しているシステムなら、この3つを自社でゼロから作る必要はありません。SBOMの提出、バージョン固定、脆弱性公表時の対応（連絡・修正・期限）を、あらかじめ契約と納品条件に書いておけば、いざというときに「誰が動くのか」で止まらずに済みます。逆に、ここが決まっていないシステムは、平時は問題なく見えても、脆弱性公表の当日に一気に露呈します。

受託開発会社に聞く、依存とOSSまわりの質問

技術に詳しくなくても、次の質問はそのまま発注先にぶつけられます。答え方のはっきりさが、そのまま保守のしやすさの差になって表れます。

• 何を使っていますか — 主要な依存ライブラリと、その選定理由。「AIが提案したから」で止まらず、人が確認したかを聞く。
• SBOM（部品一覧）は出せますか — 納品物として依存・バージョン・ライセンスの一覧を受け取れるか。出せない場合、その理由。
• 脆弱性が出たら誰が直しますか — 依存に問題が公表されたときの連絡・修正・期限の役割分担。自社・ベンダーどちらが動くか。
• ライセンスは誰が確認しましたか — 組み込み・納品・SaaS提供という自社の使い方に照らして、ライセンス整合を誰がチェックしたか。
• 契約にはどう書いてありますか — 上記が口約束でなく、成果物責任・脆弱性対応・引き継ぎ条項として契約に落ちているか。

これらは相手を試すための質問ではなく、事故が起きたときに誰が動くのかを、平時に確定させておくための質問です。回答が具体的なベンダーほど、保守フェーズでの追加費用やトラブルが少なくなります。

OSSと依存管理をめぐるよくある誤解

• 「OSSは無料だからコストゼロ」 — 使用料はかからなくても、選定・確認・更新・脆弱性対応・ライセンス整理という保守コストは発生します。無料なのはダウンロードだけで、運用は有料だと考えるほうが実態に近い。
• 「有名なライブラリなら安全」 — 広く使われていることは安心材料ですが、広く使われているからこそ攻撃対象にもなり、脆弱性が出れば影響範囲も大きくなります。有名かどうかではなく、更新が続いているか・自社が使うバージョンに問題がないかで見ます。
• 「AIが選んだなら妥当」 — 前述のとおり、AIは実在しないパッケージや保守の止まったものを提案することがあります。AIの提案は候補であって承認ではありません。人の確認工程を省く理由にはなりません。
• 「使っているだけなら責任はない」 — 自社サービスに組み込んで顧客に提供している以上、その部品に起因する不具合や情報漏えいの影響は、まず自社が引き受けます。「他人が書いたコードだから」は、顧客や取引先には通りません。

これらの誤解はいずれも、「入れる前に確認する」「契約で責任を決めておく」という一手間を省いた結果として表面化します。

コードレビューと納品物監査の実務手順

発注者側に開発者がいなくても、次の手順で「検証されているか」は確認できます。

• プルリクエスト単位のレビュー記録（誰が承認したか、指摘と修正のやり取り）を見せてもらう
• テスト結果とカバレッジのレポートを納品物に含めてもらう
• 依存ライブラリ一覧とライセンス・脆弱性チェック結果（SBOM相当）を受け取る
• 静的解析・シークレットスキャンの実施ログを確認する
• 主要機能について、正常系だけでなく異常系（失敗・不正入力・権限外操作）の挙動を実機で確認する

自社に判断できる人がいない場合は、第三者によるコード監査・見積レビューを挟むと、納品前に手戻りを減らせます。判断軸を整理したい場合は、開発の見積・提案を第三者視点でレビューする相談から始められます。

保守引き継ぎで確認すること

AIで速く作ったシステムほど、作った本人以外が触れないブラックボックスになりがちです。引き継ぎ時には次を確認します。

• ソースコード・リポジトリ・CI設定・環境構築手順が一式そろっているか
• 設計意図と非自明な実装判断がドキュメント化されているか
• 依存ライブラリのバージョンとライセンスが固定・記録されているか
• テストが残っており、変更後に回帰確認できるか
• 障害時の連絡先・復旧手順・過去のインシデント記録があるか

これらが欠けたまま担当者が交代すると、小さな改修でも調査から始まり、費用と期間が膨らみます。引き継ぎ資料の有無は、次のベンダーの見積にも直結します。

よくある失敗パターンと回避策

• 失敗1：AI利用を一律禁止する → 現場は隠れて使い、痕跡だけ残る。禁止ではなく、開示・レビュー・テストを前提にした利用ルールを作る。
• 失敗2：デモの見栄えで発注する → 提案書の美しさより、前提条件・制約・監査証跡・保守思想の記述量を評価する。
• 失敗3：初期費用だけで比較する → API費用、レビュー工数、脆弱性対応、保守、教育、契約更新まで含めた総額で見る。
• 失敗4：責任分界を曖昧にする → AI・ベンダー・自社の責任範囲を契約で明文化し、事故時に「AIのせい」で止まらないようにする。
• 失敗5：テスト証跡を求めない → 「動きました」を成果とせず、何を検証したかの記録を納品条件にする。

これらは技術力の問題ではなく、発注前の問いが浅いことから起きます。

発注前チェックリスト

• 対象システムでAIコーディングエージェントを使う工程を、ベンダーに開示させたか
• AI生成部分を含めて成果物責任をベンダーが負う契約になっているか
• テスト範囲・カバレッジ・証跡の提出を納品条件にしたか
• 依存ライブラリのライセンスと脆弱性の確認結果を受け取れるか
• 静的解析・シークレットスキャンの実施が担保されているか
• 保守引き継ぎ資料（設計意図・運用手順・SBOM）が納品物に含まれるか
• 障害時の連絡・修正・期限が契約に明記されているか
• 自社に判断者がいない場合、第三者レビューを挟む段取りがあるか

90日で調達・保守体制を更新するロードマップ

一度に全社ルールを作ろうとすると止まります。90日で段階的に整えます。

いきなり全ベンダーへ厳格な要件を課すのではなく、重要度の高い1件から型を作り、横展開するのが現実的です。

初回相談で自社を診断する質問

次の質問に答えられる会社は、発注判断が速くなります。答えに詰まる箇所が、いま整理すべき論点です。

• いま外注しているシステムで、AIコーディングエージェントが使われているか把握しているか
• 納品物にテスト証跡・依存関係一覧・設計ドキュメントは含まれているか
• そのシステムを、開発した会社以外でも保守できる状態か
• AI生成部分を含む成果物の責任は、契約上どちらにあるか
• 脆弱性が見つかったとき、誰が、いつまでに、どう直すか決まっているか
• 自社にコードやライセンスを判断できる人はいるか。いない場合、誰に見てもらうか

これらは記事を読むだけでなく、相談前の自己診断として使えます。埋められない項目が多いほど、発注前に要件と契約の整理が必要だというサインです。

よくある質問

Q. AIを使うベンダーは避けるべきですか。 いいえ。AIは広く使われており、避けること自体が現実的ではありません。見るべきは、AIを使っても品質・出所・保守を説明できるかどうかです。

Q. 自社に技術者がいなくても確認できますか。 基本的な確認（開示・テスト証跡・引き継ぎ資料・契約条項）は非技術者でも聞けます。コードの中身まで見る必要がある場面では、第三者のコード監査・見積レビューを挟むと安全です。

Q. すでに発注済みのシステムはどうすればよいですか。 保守引き継ぎの観点で、ソース・依存関係・ドキュメント・テストがそろっているかを棚卸しします。欠けている場合は、次の改修や乗り換えの前に整えると、費用の膨張を防げます。

Q. SBOM（部品一覧）は中小企業でも作れますか。 全システムを一度に完璧に作ろうとすると挫折します。重要な1システムから、直接使っている主要な依存とライセンス・バージョンを台帳にし、生成はビルド時に自動で吐き出す仕組みにするのが現実的です。受託開発を使っているなら、提出を納品条件にして受け取る手もあります。

Q. OSSライセンスの可否は自分で判断してよいですか。 使い方（自社製品への組み込み・顧客への納品・SaaSとしての提供）や改変の有無で条件の効き方が変わり得るため、最終的な法的判断は顧問弁護士や専門家に確認するのが安全です。経営者側の準備は、自社の使い方を整理し、使用しているOSSのライセンス一覧を用意して、判断を委ねられる状態を作ることです。本記事はライセンスの法的効果を断定するものではありません。

Q. AIが提案したライブラリは、そのまま使ってよいですか。 候補として受け取り、人が確認してから使うべきです。生成AIは実在しないパッケージや保守の止まったものを提案することがあり、名前が合っているだけでは安全の証明になりません。メンテ状況・依存の深さ・ライセンス・既知脆弱性・代替の有無を確認する工程を挟みます。

Q. 脆弱性が公表されたとき、何分で「うちは影響あるか」を答えられるべきですか。 明確な基準はありませんが、部品一覧があり、バージョンが記録され、直す担当と手順が決まっていれば、検索で当日中に一次判断ができます。ここが数日かかる状態は、その間の露出リスクと判断の遅れがそのまま事業リスクになります。

相談フェーズ別の整理表

あわせて読みたい記事

• 複数見積もりを比較して開発会社を選ぶ視点
• AI生成コードを本番投入する前のレビュー基準
• Claude Codeなどエージェント開発のガバナンス設計
• システム開発・AI基盤の相談

まとめ：痕跡を消せる時代だからこそ、契約と納品物で検証する

AIコーディングエージェントの痕跡がOSSに広がり、しかも隠せるという事実は、調達側にとって脅威ではなく、確認項目を更新する合図です。AIを使ったかどうかを問い詰めるのではなく、AIが関与した箇所に人間のレビューとテストが通り、出所とライセンスが整理され、別の担当者でも保守できる状態か——これを契約と納品物で検証できるようにすることが、これからのソフトウェア調達の核心です。

まずは、外注中のシステム1件について、テスト証跡・依存関係・設計ドキュメント・責任分界を1枚に並べてみてください。その表が作れない場合、次の発注や保守引き継ぎの前に、要件と契約の整理から始める価値があります。

OSS調達と監査の体制を相談する

参考・出典

以下はいずれも一次情報・公式情報・査読／公表済み研究です（確認日：2026年7月10日）。数値は各出典の公表値をそのまま参照しています。ライセンスの法的効果や脆弱性対応の要否は、自社の状況に応じて顧問弁護士・専門家に確認してください。

• Detecting AI Coding Agents in Open Source（1億8,000万リポジトリの調査）: https://arxiv.org/abs/2606.24429
• Command-Line AI Coding Agents の導入と生産量への影響研究（マージPR約24%増、著者は代理指標である旨を明記）: https://arxiv.org/abs/2607.01418
• We Have a Package for You!（生成AIによる実在しないパッケージ提案の分析、USENIX Security 2025）: https://arxiv.org/abs/2406.10279
• 経済産業省「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引 ver2.0」: https://www.meti.go.jp/press/2024/08/20240829001/20240829001.html
• NIST AI Risk Management Framework（AI RMF）: https://www.nist.gov/itl/ai-risk-management-framework
• OWASP GenAI Security Project: https://genai.owasp.org/
• 経済産業省 AI事業者ガイドライン: https://www.meti.go.jp/policy/it_policy/ai_guideline/