こんにちは。ITコンサルティングと受託開発、それにプログラミングスクールをやっている会社の代表、沼田です。17人・フルリモートの小さな会社で、そのうち8人が高専卒です。
先日、ある中堅企業との商談で、話が一瞬止まりました。要件も費用も体制も、ほぼ合意していたところで、先方の情シス部長がこう言ったんです。
「ひとつだけ。……そのコード、AIが書いたものですか？ うちのものになりますか？」
正直に言うと、2年前ならこの質問は来ませんでした。でも2026年のいま、発注する側が本気で気にし始めています。今日は、AI駆動開発の「権利」の話です。技術でもセキュリティでもなく、納品したコードが誰のものになるのかという、これまで誰も真剣に問わなかった論点について書きます。
先に断っておくと、僕は弁護士ではありません。ここに書くのは法的な結論ではなく、受託開発を回している側が実務としてどう構えているか、という話です。
権利は増えないのに、義務だけ増える
まず、いま何が起きているのか。
日本の著作権法では、著作物として保護されるには「人間の創作的寄与」が必要とされています。ここが問題で、生成AIがほぼ丸ごと書き上げたコードは、人の創作的寄与が薄いと判断されれば、著作権が発生しない可能性がある。専門家のあいだでも、そう指摘されています。
著作権が発生しない、と聞くと「自由に使えるならむしろ得では」と思うかもしれません。でも受託開発では逆です。権利が発生しないということは、納品したコードを第三者がそっくり使っても、文句を言えないということです。「御社専用に作りました」と言って納めたものが、実は誰のものでもない。発注側からすれば、これは払った金額に対して受け取ったものが揺らぐ話です。
さらに厄介なのが、もう一方の側です。生成AIは学習したコードを再生産することがあり、そこにOSS（オープンソース）のコードが混ざり込むことがある。混ざったのがGPLのような「同じライセンスで公開せよ」という条件のコードだった場合、こちらには義務だけが発生します。日経も「普及するAI駆動開発、古いコード混入や規約違反の懸念 人の責任重く」と報じていました。
つまり、AIに全部書かせると、権利は生まれにくいのに、義務は生まれやすい。これがいまの構図です。うちのエンジニアと話していて、この非対称性に気づいたときは、正直ぞっとしました。
「請負」「準委任」「伴走」で、責任の置き場所が変わる
受託の現場では、契約の型によってこの問題の重さが変わります。ざっくり3つです。
請負は、完成した成果物を納めて、その品質に責任を負う型です。ここが一番重い。「納品物に第三者の権利を侵害するものは含まれていません」と保証する条項が入るのが普通なので、OSS混入が起きれば、それは受託側の責任になります。AIを使ったかどうかは、発注側の知ったことではない、という立て付けです。
準委任は、作業そのものを引き受ける型です。成果物の完成責任は負わないぶん、責任は軽くなる……ように見えますが、実務では「じゃあAIが混ぜたライセンス違反は誰が拭くのか」が宙に浮きます。曖昧なまま進めるのが一番まずい。
伴走型（内製支援）は、顧客の中の人が手を動かし、うちが横で支える型です。この場合、コードを書いているのは顧客側なので、権利も責任も顧客に寄ります。だからこそ、「AIをどこまで使っていいか」のルールを、こちらが先に渡しておく必要がある。
大事なのは、どの型でも「AIを使っていない前提」の契約書のままにしないことです。前職のスタートアップITコンサルにいた頃から使われている雛形は、当然ながらAIを想定していません。そこに新しい現実だけが流れ込んでいる状態が、いま一番危ないと思っています。
うちが契約と工程に足した「3行」
じゃあ実際に何をしたか。大げさな法務体制を組んだわけではありません。契約と工程に、3つ足しただけです。
ひとつめ、AIを使うことを、事前に伝える。「生成AIを開発工程で利用します。利用するツールとバージョンは書面で明示します」と、契約前に伝える。隠して後でバレるのが最悪で、先に言えばむしろ信頼になります。実際、冒頭の情シス部長も、「使わない」と言われるより「こう使って、こう検査しています」と言われるほうが安心だ、と話していました。
ふたつめ、納品前のOSS混入チェックを、工程に組み込む。気合いや善意では防げないので、納品前の工程として固定します。ライセンススキャンをCIに載せて、引っかかったら止まる。「レビューのときに気をつける」は、忙しい月に必ず飛びます。仕組みに落として初めて、保証できるものになる。
みっつめ、「人間の創作的寄与」を、記録として残す。どこを人が設計し、どこを直し、なぜその実装を選んだのか。レビューのやり取りやコミットを、成果物とセットで残す。これは著作物性のためだけではなく、あとで「なぜこうなっているのか」を説明できる会社かどうかの分かれ目でもあります。AIに書かせた部分ほど、人の判断の跡を残しておく。
24歳で起業して、この3期目（27歳）まで受託をやってきて思うのは、こういう地味な工程が、結局いちばん営業に効くということです。派手な提案より、「うちはこう検査して納めます」と言い切れるほうが、発注する側は安心する。
うちでは、こういう「新しい現実に、契約と工程をどう合わせるか」を一緒に考えられるエンジニアを募集しています。コードを書く力だけでなく、「納品したものに責任を持つ」ところまで面白がれる方は、ぜひK.Platinumのエンジニア募集要項をのぞいてみてください。
受託の売り物は「作る」から「保証する」へ
まとめます。2026年、AIはコードを書きます。でもそのコードには、権利が生まれないかもしれないし、他人のライセンス義務が紛れ込むかもしれない。発注する側は、それに気づき始めています。
以前、「作れる会社は増えたが、支え続けられる会社は増えていない」という話を書きました。今回はその隣にある話です。作れる会社は増えたが、"これは確かにあなたのものです"と保証できる会社は増えていない。 受託の売り物が、作ることから保証することへ移っている。僕はそう見ています。
最後に、発注する側として確認すべき3項目を置いておきます。①開発工程でAIを使うか、使うならどのツールか。②OSSライセンスの混入チェックを、どの工程でやっているか。③人がどこを設計・レビューしたか、記録として残るか。
この3つに即答できない相手なら、いったん立ち止まったほうがいい。逆に言えば、これに答えられるようにしておくことが、これからの受託会社の最低条件だと思っています。
沼田海斗（ぬまた・かいと）
株式会社K.Platinum代表。24歳で起業し、17人・フルリモートのチームでITコンサルティング・受託開発・プログラミングスクールを手がける。AIを"使う"ことと同じくらい、"納品したものに責任を持つ"仕組みづくりにこだわっている。
K.Platinumでは一緒に働くエンジニアを募集しています。「実力で正当に評価される環境」に興味がある方は、ぜひ採用ページをご覧ください。