フリーランスや小さな開発会社に作ってもらったシステムが納品されたものの、「中にどんな部品が使われているのか」を誰も説明できない。あとから保守会社を替えたい、セキュリティの確認を求められた、といった場面で、はじめて困る方が少なくありません。
「フリーランスが作ったシステムに、オープンソースや共通部品が使われているか、納品物の中身をどう確認すればいいのか分からない…」
先に結論をお伝えします。ほぼすべての現代のシステムには、オープンソースの部品が使われています。使われていること自体は問題ではありません。確認したいのは「何が使われているかの一覧が手元にあるか」「その使用条件（ライセンス）が自社の使い方に合っているか」「古くて危ない部品が混ざっていないか」の3点です。プログラムが読めなくても、一覧を出してもらい、質問する形で確認できます。
この記事では、発注者が納品物の中身を確認する5つの方法と、そのまま使えるチェックリスト・開発会社への質問例を、執筆時点（2026年10月）の情報でまとめます。
なぜ納品物の中身が分からなくなるのか
オープンソースは「無料の既製部品」として広く使われている
オープンソース（＝作者がソースコードを公開し、決められた条件のもとで誰でも使える部品）は、現代の開発では当たり前に使われます。ログイン機能、画面の部品、PDFの出力、データベースとの接続など、一から作ると手間のかかる部分を既製の部品でまかなうことで、開発費と期間を抑えられるからです。
つまり、開発者が部品を使うのは通常の進め方であり、それだけで手抜きや契約違反になるわけではありません。
一人で作る場合ほど、記録が残りにくい
大きな会社の開発では、使う部品を台帳で管理するルールがあることが多い一方、フリーランスや少人数のチームでは、使った部品が設定ファイルに並んでいるだけで、発注者向けの一覧にはなっていないことがよくあります。悪意ではなく、「聞かれなかったので出していない」だけというケースが大半です。
国もこの管理の重要性を指摘しています。経済産業省は、ソフトウェアに含まれる部品を一覧にする「SBOM（エスボム＝ソフトウェア部品表）」の導入手引を公表しており、背景としてオープンソースの利用が一般化し、脆弱性管理とライセンス管理の重要性が高まっていることを挙げています。
📰 出典：経済産業省「ソフトウェア管理に向けたSBOM（ソフトウェア部品表）の導入に関する手引 ver 2.0」
手引は2024年8月に公表され、脆弱性管理の進め方のほか、契約で定める事項の参考例（SBOM取引モデル）も付録に含んでいます。ただし手引は主にソフトウェアを扱う事業者向けの内容であり、小規模なシステムにすべてを求める趣旨ではありません。発注者としては「部品の一覧を出してもらう」という考え方だけ持ち帰れば十分です。
納品物の中身を確認する5つの方法
方法1：「使っている部品の一覧」を出してもらう
最初にして、最も効果が大きいのがこれです。一覧には、次の項目が並んでいるのが理想です。
| 項目 | 例 | 何のために見るか |
|---|---|---|
| 部品の名前 | （部品の名称） | 何が使われているかを知る |
| バージョン | （版番号） | 古くないか、脆弱性が出ていないかを調べる |
| ライセンス | MIT、Apache-2.0、GPL など | 使用条件が自社の使い方に合うかを調べる |
| 用途 | ログイン、PDF出力など | 重要な部分に使われているかを知る |
開発者は、利用している開発環境の仕組み上、部品名とバージョンの一覧を機械的に書き出せることがほとんどです。「一覧を出すだけなら数時間もかからない」ことが多いので、依頼自体は過度に遠慮しなくて構いません（工数は案件で変わるため、事前に聞いてみましょう）。
方法2：ライセンスの種類を見て、自社の使い方と照らす
オープンソースは無料ですが、使い方の条件があります。大きくは次の2系統があり、確認の重みが違います。
- 条件がゆるいもの（MIT、Apache-2.0 など）：著作権表示などを残せば、商用利用や改造がしやすい
- 条件が厳しいもの（GPL、AGPL など。「コピーレフト」と呼ばれる）：これを使って作ったものを配布・提供する場合、自社のソースコードの公開を求められる可能性がある
たとえば、社内だけで使う業務システムでは問題になりにくい一方、自社の製品に組み込んで顧客に配る、あるいはサービスとして外部に提供する場合は、条件によって扱いが変わります。弁護士の解説では、コピーレフト型のライセンスでは、ソースコードの公開義務が秘密保持の約束と食い違う可能性があることも指摘されています。
📰 出典：モノリス法律事務所「OSSを利用したソフトウェア開発委託契約」
どのライセンスが問題になるかは、使い方によって変わります。個別の判断は、知的財産に詳しい弁護士など専門家に確認してください。発注者がやるべきことは、「どんなライセンスの部品が入っているか」「自社の使い方で問題ないか」を開発者に説明してもらうところまでです。
方法3：古い・危ない部品が混ざっていないか確認する
部品には、あとから弱点（脆弱性）が見つかります。使っている部品が古いまま止まっていると、そこから侵入されるおそれがあります。一覧のバージョンと、公開されている脆弱性情報を突き合わせることで確認できます。
- 開発者に「一覧の中で、既知の脆弱性が報告されている部品はありますか」と聞く
- 見つかった場合は、いつ・誰が更新するかを決める（納品後の保守に含まれるのか、別料金なのか）
なお、一覧に脆弱性が載っていることと、システムが実際に危険な状態であることは同じではありません（その部品の該当機能を使っていなければ影響しない場合もあります）。業界団体からも、この点の注意が指摘されています。「ある＝危険」と決めつけず、開発者に影響の有無を聞くのが現実的です。
方法4：共通部品と「その案件専用に書いた部分」を分けてもらう
納品物は、既製部品の部分と、開発者がその案件のために書いた部分に分かれます。この境界が分かると、次のことが見えてきます。
- 他社に保守を引き継ぐとき、どこまでが「その案件専用」で、どこからが世の中で使われている標準的な部品か
- 著作権や権利の取り扱いが及ぶ範囲はどこか（既製部品の権利は、通常、発注者へ譲渡されるものではなく、各部品のライセンスに従って使うことになります）
著作権の考え方については、別の記事で詳しく整理しています。
方法5：「その後」の更新を誰がやるかを決める
一覧を受け取ったら終わりではありません。部品は定期的に更新が必要で、放置すると古くなります。納品後に誰が一覧を更新し、脆弱性の連絡を受けたら誰が対応するのかを、保守の取り決めに入れておきましょう。
契約で「納品物に含まれるオープンソースの一覧を提出する」「使用条件に反した利用をしていないことを表明する」といった条項を入れる方法もあります。契約書の文言は、必要に応じて弁護士などの専門家に確認してください。
やりがちな失敗
- 「オープンソース＝危険」と考えて禁止する：現実的には、ほぼすべての開発が成り立たなくなります。禁止ではなく「一覧を出して管理する」が現実的な落としどころです。
- 納品後に一覧を請求する：納品後は、開発者が別案件に移っていて、対応に時間や費用がかかることがあります。契約時または検収時に提出物へ入れておくのが確実です。
- 一覧を受け取って安心する：受け取るだけでは何も変わりません。ライセンスと古さを見て、更新の担当者を決めるところまでがセットです。
- 開発者を疑う聞き方をする：「ちゃんと使ってるんですか」といった聞き方は関係を悪くします。「保守を引き継ぐ準備として、一覧をいただきたいです」と、目的を添えて伝えると、協力を得やすくなります。
発注者がやること チェックリスト
- ☐ 契約時または検収時に、使用部品の一覧（名前・バージョン・ライセンス）を提出物に入れた
- ☐ 一覧にコピーレフト型（GPL・AGPLなど）のライセンスがないか確認した
- ☐ 自社の使い方（社内利用か、顧客への提供か）を開発者に伝え、問題がないか説明を受けた
- ☐ 古い部品・脆弱性が報告されている部品がないか確認した
- ☐ 既製部品と、案件専用に書いた部分の境界を教えてもらった
- ☐ 納品後に一覧を更新する担当者と時期（保守の取り決め）を決めた
- ☐ 判断に迷う点は、弁護士などの専門家に確認することにした
開発会社（フリーランス）への質問例
- 「今回のシステムで使っているオープンソースや共通部品の一覧（名前・バージョン・ライセンス）をいただくことは可能でしょうか。保守の引き継ぎの準備に使いたいです」
- 「一覧の中に、GPLなど、使い方によって条件が厳しくなるライセンスのものはありますか。私たちは社内利用です（または、顧客にも提供します）が、問題ないでしょうか」
- 「一覧のバージョンに、既知の脆弱性が報告されているものはありますか。ある場合、今回のシステムへの影響はいかがでしょうか」
- 「この案件のために書いていただいた部分と、既製の部品の部分は、どのように分かれていますか」
- 「納品後に部品を更新する場合、どこまでが保守の範囲で、どこからが別途のご相談になりますか」
回答の中身はもちろん、一覧をすぐに出せるかどうかからも、納品物を把握して管理している開発者かどうかが見えてきます。
まとめ：禁止するのではなく「一覧を持つ」ことが出発点
- オープンソースが使われていること自体は普通で、問題は「把握していないこと」
- まずは使用部品の一覧（名前・バージョン・ライセンス）を出してもらう
- ライセンスは自社の使い方と照らし、迷ったら専門家に確認する
- 古い部品・脆弱性は「あるかどうか」と「影響があるか」を分けて聞く
- 契約時や検収時に一覧を提出物へ入れ、納品後の更新担当も決めておく
フリーランスとの取引でも、一覧を求めることは不自然ではありません。「次の担当者に引き継ぐための準備」と伝えて、一緒に整えていきましょう。
あわせて読みたい関連記事
