法務担当者の中には「ITやAIはIT企業やIT部門の仕事で、自分とは関係ない」と思っている方もいるかもしれません。

でも、情報化が進む現代社会では、IT・AIの法律問題への対応はもはや必須といっても過言ではありません！📱💻

今回は、「システム開発」と「AI」の2つに関して、よくある失敗事例をもとに法務実務のポイントを解説します。

📋 目次

1. システム開発契約の失敗と解決策
   • ユーザの協力義務とベンダのPM義務
   • 完成と契約不適合
2. AIにまつわる失敗と解決策
   • AIと著作権
   • AI開発
   • プロファイリング

第1章 システム開発契約の失敗と解決策

🤝 Theme1：ユーザの協力義務とベンダのPM義務

💥 失敗事例

あるベンダ企業がユーザ企業の依頼を受けてシステム開発を行っていました。

ところが、開発の途中でプロジェクトが頓挫…😰

何が起きたかというと：

• ユーザ企業が「ベンダにお任せ」という態度を取っていた
• そのためユーザ企業は大量の仕様変更を出し続けた
• ベンダ企業はそれを受け入れて仕様変更を続けていた
• 稼働予定から1年が経過して、ユーザが「いつ頃できるの？」と聞いたところ…
• ベンダは「いつできるか分からない。契約額の10倍を追加で請求しないといけない」と回答

当然、ユーザ企業はプロジェクトを終わらせました。

ベンダ側の弁護士は「ユーザの協力義務違反だ！悪いのはユーザだ」と考えましたが、先輩弁護士から「ベンダのPM義務違反もありそうだ」と指摘されて困惑…。

仕様変更を要求したのはユーザなのに、それを受け入れるとなぜベンダの義務違反になるのでしょうか？🤔

📖 解説

（1）失敗の原因

この弁護士は協力義務の概念は勉強していましたが、PM義務を勉強していなかったのです。

システム開発は専門性がありますが、企業法務においてシステム開発案件は必ずどこかで出てきます。だからこそ、基礎を理解すべきなのです。

（2）ウォーターフォール開発の進め方

システム開発にはアジャイル開発などの手法もありますが、一般的なのはウォーターフォール開発です。

「ウォーターフォール（滝）」の名の通り、各段階において前段階で決まった内容を詳細化・具体化しながら、水が流れ落ちるように進めていきます。

企画 → 要件定義 → 基本設計 → 詳細設計 → プログラミング
                                              ↓
受け入れテスト ← システムテスト ← 統合テスト ← 単体テスト

重要なポイント：工程の後戻りは本来想定されていません！⚠️

例えば、すでに詳細設計に入っているのに「この画面にしてほしい」と基本設計の内容について変更を要求すると、基本設計へと後戻りが必要になります。

このような仕様変更は：

• 工数増大の原因になる
• プロジェクト遅延の原因になる
• 品質向上の対応が阻害され、品質低下につながる

つまり、仕様変更は本来的には出してはならないものなのです。

しかし実務上、大規模開発では仕様変更をゼロにすることはできず、一定数の仕様変更は発生してしまいます。だからこそ、ユーザもベンダも予防措置を講じるとともに、適切に対応する必要があるのです。

（3）二重の専門性と協力義務

システム開発には二重の専門性があります。

お互い専門外の分野をカバーし合わないとシステム開発は失敗します！

ベンダはユーザの業務を十分に理解していないため、ユーザの業務に適合したシステムを開発できません。

だからユーザはベンダに対してシステム開発を「お任せ」にはできず、以下のような協力を行う必要があります：

• ✅ 適時適切な（主にユーザのビジネスに関する）情報を提供する
• ✅ 適時に意思決定を行う（例えば仕様書の承認）
• ✅ 仕様変更を合理的な時期・分量に抑え、プロジェクトを阻害しない

ユーザがこのような協力義務を果たさない場合の効果：

• システムが完成しない場合などに、ベンダに帰責性がないとされる
• ベンダに対する損害賠償請求等ができなくなる
• 協力義務違反そのものが債務不履行として、ベンダから損害賠償請求される可能性もある

（4）PM義務

ユーザの協力義務の重要性は否定できません。

しかし、IT部分はベンダのほうに専門性があり、ベンダはその専門性を活かして適切にプロジェクトを進めていかなければなりません。

プロジェクト・マネジメント義務（PM義務） には2つの側面があります：

1️⃣ ベンダが自社内の要員を管理してスムーズにシステム開発を進める義務

2️⃣ ベンダがユーザに働きかけてシステム開発が阻害されないようにする義務

特に2️⃣が重要です！

ユーザはITについて十分に理解していないため、ベンダは：

• 適時適切に情報提供をする
• ユーザが適時適切な意思決定をできるよう働きかける
• 多大なる仕様変更を行ってプロジェクトを阻害しないよう、ユーザに働きかける
• 時にはプロジェクトの中止を提言する

（5）2つの義務の関係

協力義務とPM義務という2つの義務の相互関係については、「いずれかが他方の前提になるのでは？」という議論があります。

しかし、二重の専門性という前提からすると：

• ユーザが協力義務を果たさなければ → 業務に関する専門性がプロジェクトにおいて不足する
• ベンダがPM義務を果たさなければ → ITに関する専門性がプロジェクトにおいて不足する

**プロジェクトを成功させるためのあるべき姿としては、「相手が先に義務を果たしてから自分が義務を果たす」という姿勢ではなく、双方が率先して義務を果たすべきです！**💪

（6）実務対応

双方が義務を負うことから、積極的義務履行がない場合、「双方がともに悪い」 という状況が生じ得ます。

例えば、請負契約で締結されたシステム開発契約について：

• 期限までにシステムが完成しない
• 原因はユーザによる大量の仕様変更

この場合、ユーザは「期限までに完成させられないベンダの債務不履行」と考えるかもしれませんが、ユーザの協力義務違反として、ユーザの責任と判断されることがあります。

そして、民法536条2項（債務者主義）により、ユーザが報酬を支払わないといけない可能性があります。

しかし！ もしユーザの仕様変更がプロジェクトに悪影響を及ぼす程度に大量であることをベンダが知りながら、「ユーザの希望なのだからしょうがない」と唯々諾々として受け入れていたとしたら…

ベンダのPM義務違反と判断される可能性があり、ベンダが責任を負う可能性があるのです！⚠️

失敗事例では、ユーザは規模が10倍以上になるようなとんでもない量の仕様変更を行っており、もちろん責任重大です。

しかし、一連の仕様変更が積み重なる過程のどこかのタイミングで、ベンダとしても「仕様変更の分量が対応可能な範囲を超えており、プロジェクトの進捗に影響がある」と判断できた可能性があります。

もしそうであれば、ベンダとして：

• その仕様変更がプロジェクトに及ぼす影響を分析する
• ユーザに助言する（例：「この仕様変更をそのまま実施すると、予定の時期にシステムが完成しない」等）

ベンダがそのような助言をしたにもかかわらず、ユーザが不合理な主張をした場合には、ベンダとしてのPM義務は果たされたと評価されることはあり得ます。

結論：「ユーザの仕様変更希望がプロジェクト頓挫の原因だからユーザが100対0で悪い」とは結論づけられないのです！

✅ Theme2：完成と契約不適合

💥 失敗事例

ある弁護士がシステム開発契約の案件に対応していました。

• ユーザ企業がベンダ企業にシステム開発を依頼（請負契約）
• ベンダ企業はシステムを開発した
• ユーザ企業が確認したところ、システムがバグだらけで業務にも適合していない😱
• ユーザ企業は支払いを拒否

この弁護士は「システムが使えないならば完成しておらず、報酬を支払う必要がない」とアドバイスしました。

すると先輩弁護士が割って入り、「これは契約不適合の問題なので、仕様と実装を比較しないと」と指摘。

「契約不適合の問題だということは、システムは完成したということですか？でも使えないシステムですよね？」

「裁判所の判断枠組みを押さえないといけないね」と言われ、勉強することになりました…📚

📖 解説

（1）失敗の原因

この弁護士は、素朴な感覚で「使えないものなら、まだシステムは完成していない」と考えてしまい、完成に関する裁判所の判断枠組みを理解していませんでした。

確かにバグだらけのシステムは、素人目には「とんでもない」システムです。

また、業務に使うために高いお金を払っている以上、ベンダがその業務に適合しているものをつくるのは当然だと思うかもしれません。

しかし：

• バグが一定程度あっても最終工程まで到達すれば原則として完成となる
• 後は契約不適合責任の問題となる
• いくら業務に適合していなくても仕様書通りに実装されていれば、「債務の本旨」に従って「仕事」であるシステムを完成したことになり、契約不適合ではない

（2）完成基準＝最終工程完了説

ユーザとして、バグだらけのシステムが納入され、そのような使えないものが「完成した」と評価されることに不満があることは理解できます。

しかし、基本的には最終工程が完了している限り、それをもって法的には仕事は完成しているのです（最終工程完了説）。

例えば、①設計、②プログラミング、③テストが予定された工程であれば、③テスト工程という最終工程が完了していればこれで完成ということです。

「この結論は不当だ」と思われるかもしれません。

しかし、結局のところ契約不適合責任を理由として、解除の要件さえ満たされれば解除することができます（民法564条、541条、542条）。

もしその完成したシステムに重大な契約不適合があれば、それを理由に解除等を主張すればよいということになります。

（ただし、例えばランダムに並んだ英数字の入ったUSBメモリを送りつけても完成にはならないように、例外的に質が問題となることはまったくないわけではありませんが、あくまでも例外です）

（3）契約不適合の基準＝仕様

契約不適合の基準は仕様であり、業務ではありません！⚠️

例えば、法律事務所で利用する事件管理システムが、事件番号の管理の際に裁判所名を利用しなかったとします。

「東京地裁令和7年（ワ）1号」と「大阪地裁令和7年（ワ）1号」が同じ「令和7年（ワ）1号」になるというのは、業務との関係であまりにも実用性が低いため、ユーザである弁護士として到底受け入れられないでしょう。

しかし、ベンダには業務の専門性がありません。そこで、ベンダは合意された仕様書に従って構築（実装）すれば、原則としてその責任を全うしたとみなされます。

その結果として業務との関係でいくらおかしくても、そのような仕様に合意したのであれば、仕様書を承認したユーザが悪いということなのです。

**だからこそ、ユーザとしては仕様書の内容をしっかり確認し、分かりにくいならばベンダに説明を求めたうえで納得して仕様書を承認しなければなりません！**📋

（4）トラブル事案の実務対応

トラブルになった場合の判断フロー：

まず最終工程が完了しているか？
    │
    ├─ NO → 未完成 → 納期経過なら債務不履行（履行遅滞）
    │
    └─ YES（引き渡されている前提）→ 契約不適合の問題へ

契約不適合の判断において「バグ」等の問題が発生することは多いですが、そもそもシステムの実装が仕様と異なるかどうかが重要な問題となります。

• 実装がユーザの業務と異なっていても、合意された仕様通りであれば契約不適合ではない
• 多少のバグが出てもそれだけで契約不適合責任が生じるのではなく、それが容易に修補できるものかが問題となる
• 容易に修補できるのであれば、ベンダは修補する必要はあるが、修補をしたことでベンダは義務を果たしたことになる

これに対し、修補が容易でなかったり、1つを修補してもそれがまた別の問題を引き起こしてトラブルが拡大し続け収束しなかったりする場合等には、契約不適合責任の問題となり得ます。

まとめ：そもそも完成していないのか、それとも完成を前提とした契約不適合の問題なのか、そして仮に業務と適合していないとしても、仕様通りであって契約不適合責任は生じないのではないか等をしっかり確認しましょう！✅

第2章 AIにまつわる失敗と解決策

📚 Theme1：AIと著作権

💥 失敗事例

ある企業が、コンサルタント企業の支援の下、自社の手元にあるデータを活かしたナレッジマネジメントシステムを構築しようとしていました。

データは（追加）学習に利用されるほか、RAG（データベースを検索して当該データに基づき回答を生成させる技術）やプロンプトとして投入されます。

また、「法律相談に強いAIを構築したい」との思いから、投入対象のデータの候補として：

• 法務担当者の作成したデータ
• 外部の顧問弁護士が作成したデータ

が含まれていました。企業は著作権が気になっている様子でした。

対応した弁護士は「日本の著作権法にはAIの例外規定があるから、著作権の問題はないですよ」と述べました。

すると先輩弁護士が割って入り、「出力されるデータが、外部の弁護士の回答の長めの要約等であれば、著作権の問題が生じる可能性は十分にあります」と言いました。

「でも先生、著作権法30条の4がありますよ」と言ったものの、「いや、ここは私に任せて」と返されてしまいました…😅

📖 解説

（1）失敗の原因

生成AI関係のプロジェクトでは：

• 著作物を生成AIに投入することが適法であるか
• AIが生成したものに第三者の著作物が含まれる可能性があるがそれは適法か

という疑問が出てきます。これは、生成AIを利用するうえで直面する典型的な著作権の問題です。

（2）学習・入力

まず、学習・入力段階と利用・出力段階では異なるルールが適用されるのでこれを区別すべきです。

ここで重要なのは、基盤モデルを構築するための学習や追加学習だけではなく、プロンプトやRAGとしての投入も学習・入力段階であることです。

学習・入力については、著作権法30条の4が注目されています。

著作権法30条の4のポイント：

著作物は、次に掲げる場合その他の当該著作物に表現された思想又は感情を自ら享受し又は他人に享受させることを目的としない場合には、その必要と認められる限度において、いずれの方法によるかを問わず、利用することができる。

つまり、「法律相談回答」を（追加）学習させることで、「法律相談一般に強いAIを構築する」というのは、AI に学習させた元の法律相談回答やその表現と類似したものを出力させることが目的とされていない、単なる情報解析（同条2号）に過ぎません。

このような、利用段階で学習したデータと類似性のあるものを生成させようとしない学習は、享受目的がない学習のための複製等とされ、同条を根拠にライセンスを得なくても許されています。

このルールは、RAGやプロンプトとしてAIに著作物を投入する場合にも適用されます。

しかし！ ⚠️

例えば外部の顧問弁護士の法律相談回答そのものを出力したり、まったく同じでなくてもその表現と類似するものが回答に含まれたりすることを目的として学習させる場合には、この例外は利用できません。

失敗事例のような、外部弁護士の法律相談回答や意見書を要約したものを出力するためのプロンプトの場合：

• 生成される回答が極めて短く、元の回答や意見書と類似した表現が出力されないのであれば → 著作権法30条の4が適用される可能性もなくはない
• 出力される要約文の長さが一定以上あれば → 元の表現の本質的特徴を直接感得できるような、元の回答や意見書と類似するものが出力される可能性は十分にある → 同法30条の4が適用されない

とはいえ、そのような場合においても、決して学習・入力ができないということではありません！

適法に学習・入力する方法の選択肢：

（3）利用・出力

利用・出力段階の著作権侵害も問題となります。利用・出力段階は原則として著作権法30条の4が利用できないことが重要です。

AI生成物はいかなる場合に著作権を侵害し得るのか？

一般には、元の著作物と類似性と依拠性が認められる場合に著作権侵害（複製または翻案）となります。

• 類似性：元の著作物の表現の本質的特徴を直接感得できるかにより判断
• 依拠性：原則として学習データに類似性のある著作物が含まれるか、または利用者がそのような著作物を認識してプロンプト等を入力した場合に認められる

出力したものがこのような観点から類似性なし、または依拠性なしとして著作権を侵害しないと判断される場合であれば、適法ということになります。

適法に利用・出力する方法の選択肢：

**教訓：著作権法30条の4に飛びつかず、学習だけではなく利用・出力過程を含めた全過程について、それを正当化するさまざまなスキームを検討すべき！**📝

🛠️ Theme2：AI開発

💥 失敗事例

ある企業が、AIベンダに今後30年の競争力の基盤となるAIシステムを構築してもらうことを考えていました。

ベンダは分割で支払いを行い、稼働前に代金10億円の支払いを終了することを提案。

弁護士は「稼働後に検収し、合格後に支払うほうが安全ですね」と述べ、後払いに変更したうえで開発が始まりました。

AIシステムは完成し、検収の後、代金を支払いました。

いざこのシステムを利用してみると：

• 確かにある程度の出力をするので、従業員は面白がって一度は使ってみる
• しかし実際に業務で利用すると、ハルシネーション等に対する確認業務が新たに発生
• 実業務に利用するうえでは質がいまひとつ
• 少し経つとほとんど誰も利用しなくなってしまった…😔

「一大プロジェクトが大失敗です。他にアドバイスはなかったんですか？」とクレームめいたメールが届きました。

📖 解説

（1）失敗の原因

この弁護士は、支払い時期という一般的なリスクの存在に気づいていましたが、より根本的な問題である**「大規模なAI開発案件は徐々に練り上げて進めないと危ない」**という点について指摘できていませんでした。

（2）AI開発ガイドラインの「探索的段階型」

AI開発は頻繁に失敗します！⚠️

例えば、こども家庭庁における予算10億円の「虐待判定AI」が導入見送りになったことが報じられました。

実務では、少なくとも失敗事例のような大規模AI開発であれば段階的に行うことが安全だと考えられています。

生成AIの開発契約については、「AI・データの利用に関する契約ガイドライン」や「オープン・イノベーションモデル契約書（AI編）」が参照されています。

これらの契約の特徴は、「探索的段階型モデル」 として提示している通り：

• 開発段階を複数に分割する
• それぞれの工程ごとに契約を締結する
• 徐々に精度を高めていく

AI、とりわけ生成AIを含む学習型AIは、さまざまな理由で予定通りの精度にならないことがあります：

• データの問題
• 学習の問題（過学習等）
• 開発環境や設計時の想定と実環境の相違

だからこそ、完成までの工程を複数に分割したうえで、それぞれの工程の終了時において、その段階でどの程度期待したものに近いか等を評価し、次の工程に進むかを判断することは合理的なのです。

（3）PoC

AI開発ガイドラインにおける特徴的な概念にPoC（Proof of Concept：概念検証） があります。

つまり、新たな概念やアイデアを、その実現可能性を示すために、部分的に実現することです。

実現したいアイデア
    ↓
PoC（概念検証）で実現可能か検証
    │
    ├─ ダメそうなら → やめる／差し戻す
    │
    └─ 可能そうなら → 進める
            ↓
      本格的な実施

例えば、生成AIプロダクトを作成する際に：

• 最初から完成品をつくるのではなく
• 少量のデータで最低限の「動くもの」をつくってみて
• それで前に進めるかを判断する

このような手続きは、まさにAI開発のリスク軽減のために有益です！💡

（4）業務への組み込み

AIがよいものとなるように一連の過程を経て練り上げることに加え、そうやって練り上げられたAIが実際に業務で活用されるように工夫することも重要です。

これまでAIを利用しない業務フローというものが存在していたはずです。そして多くの従業員は不満があったとしても、総じてその従来の業務に親しみを持っており、それを変更してAIを中心としたものとすることに対して大きな抵抗を持つことは十分にあり得ます。

そのためには：

1️⃣ プロジェクトの目的を明確にする（単に「AIを導入したい」というだけでは成功しない）

2️⃣ 従来の業務フローを前提とせず、いかに当該目的を実現するかという観点で新たな業務フローを検討する

3️⃣ PoCの過程等で新たな業務フローを試行し（スモールスタート）、自社におけるAI活用のベストプラクティスを確立する

4️⃣ 本格的にAIを利用して業務の実施をすると決めた場合には、それを個々の従業員の問題ではなく、会社全体の問題として、経営レベルで利用すると意思決定し、経営側から従業員に理解を求める

5️⃣ スモールスタートで始め、その経験を踏まえ、当該業務フローへの移行の際に生じる抵抗感払拭のため、手厚いフォローを行う

さすがに、この業務改革に向けた過程についてアドバイスできる弁護士は多くはないものの、少なくとも：

• このような業務改革に関する準備ができているかを尋ねる
• 単に「AIを導入したい」というだけのプロジェクトであれば、AIは手段に過ぎず、目的を達成するうえで最善の方法がAIなのかを吟味すべきとアドバイスする

これくらいはできるのではないでしょうか。

教訓：AI開発のリスクとその軽減方法を理解し、徐々に検証してリスクを軽減することに向けたアドバイスをしましょう！✅

🔍 Theme3：プロファイリング

💥 失敗事例

ある企業が、自社の開発したAIで顧客の個人情報を処理することで、営業を効率化するシステムを開発しようとしていました。

「個人情報保護法の問題はないですか？」と問われた弁護士は：

「自社開発なので第三者提供の問題はないですし、個人情報の利用目的も『商品・サービスに関する情報のお知らせ』という、いわゆる営業目的に入っていることから、利用目的に変更はありません。特に対応は必要ないです」とアドバイスしました。

ある日、弁護士はセミナーを聞いて、プロファイリング（分析）についても利用目的として規定しなければならないということを思い出しました。

「そうだ！プロファイリングの規制があったんだ！」と急いで企業に電話する弁護士でした…😱

📖 解説

（1）失敗の原因

生成AIが勢いづく前の分析系AIの時期から、**プロファイリング（分析）**が問題となっていました。

プロファイリングについては、EUのGDPR（一般データ保護規則）が定義しています：

「自然人と関連する一定の個人的側面を評価するための、特に、当該自然人の業務遂行能力、経済状態、健康、個人的嗜好、興味関心、信頼性、行動、位置および移動に関する側面を分析または予測するための、個人データの利用によって構成される、あらゆる形式の、個人データの自動的な取り扱いを意味する」

 

有名な事例：

あるスーパーマーケットが、顧客である女子高生の買い物履歴から、その人が妊娠しているという、親さえも知らない事実を正確に言い当てたという事件がありました。

GDPRは、プロファイリングを含む個人に対する自動化された意思決定について厳しい規制を課しています。

これに対し、日本法のプロファイリングに対する規律は厳しいとはいえません（この点は今後の法改正の可能性もあります）。とはいえ、決して何の規制もないということではありません。

（2）プロファイリングに対するGDPRの規律

GDPR22条1項は：

「データ主体は、当該データ主体に関する法的効果を発生させる、または当該データ主体に対して同様の重大な影響を及ぼすプロファイリングを含むもっぱら自動化された取り扱いに基づいた決定の対象とされない権利を有する」

つまり、AIのみが評価・判断するのではなく、人間に評価・判断されることを求める権利を規定しているのです！

もちろん、同条2項以下で、一定のプロファイリングは本人が望まなくても可能とする等、この権利には一定の制限がありますが、プロファイリングに対する強い警戒が示されていることは重要です。

なお、EUのAI法も生体データに基づくセンシティブな個人情報を推知することを禁止する等、一定のプロファイリングを規制しています。

（3）日本の個人情報保護法による規制

❶就活生データ事件

2019年の就活生プロファイリング事件では、求職者である大学生の情報から、いわゆる「内定辞退率」を作成したことが問題となりました。

大学生がどのようなサイトを閲覧していたか等の情報を分析し、その結果をその学生が就職を希望する企業に通知していたことは驚きを与えるものでした。

このような事案以外にも、人事データをAIに処理させて人事考課を行うことについて、東京都労働委員会において争われ、企業と労働組合間でその透明性確保について合意が成立した事案等、日本においてもプロファイリングは問題となっています。

❷不適正利用

個人情報保護法19条は「個人情報取扱事業者は、違法又は不当な行為を助長し、又は誘発するおそれがある方法により個人情報を利用してはならない」として不適正利用規制をしており、2022年の改正後であれば前述の就活生データ事件は同条違反となり得ました。

とはいえ、この不適正利用がAI利用の文脈でどのようなものが該当し、どのようなものが該当しないかは不明確であり、今後明確化されることが期待されます。

❸プライバシーポリシーへの記載

プロファイリング等の分析が行われる場合においては、予測可能性の担保のために分析を行う旨が利用目的として特定される必要があります。

個人情報保護法17条1項が求める「利用目的の特定」の趣旨は：

• 個人情報を取り扱う者が、個人情報がどのような事業の用に供され、どのような目的で利用されるかについて明確な認識を持つ
• できるだけ具体的に明確にすることにより、個人情報が取り扱われる範囲を確定する
• 本人の予測を可能とする

本人が、自らの個人情報がどのように取り扱われることとなるか、利用目的から合理的に予測・想定できないような場合は、この趣旨に沿ってできる限り利用目的を特定したことにはならないとされています。

特定すべき利用目的の具体例：

• 「取得した閲覧履歴や購買履歴等の情報を分析して、趣味・嗜好に応じた新商品・サービスに関する広告のために利用いたします」
• 「取得した行動履歴等の情報を分析し、信用スコアを算出したうえで、当該スコアを第三者へ提供いたします」

重要なポイント：

従来、利用目的は結果を記載するものと理解されていました。例えば、商品を送付する場合には「ご注文の商品のお届けのため」等と結果の部分を記載すればよく、商品の倉庫からのピックアップ、箱詰め、宛名シール作成、シール貼り、業者への引き渡し、業者による配送等の個々の過程を記載する必要はないとされていました。

しかし、ガイドライン改訂により、一種の過程であっても**「分析」について利用目的として特定することが求められるようになった**ことに特徴があります。

そこで、弁護士としては、プライバシーポリシーにおいて、すでにそのような分析に関する記載がなされているか等を確認して進めることになります。

失敗事例ではプライバシーポリシーには営業に使う旨の記載はあっても分析をする旨の記載がないところ、この点を指摘して分析も利用目的として特定し、プライバシーポリシー上に記載を追加するよう勧めるべきでした。

❹人事データ利活用原則

人事分野（HRテック）では、「人事データ利活用原則」等の各分野の自主的ガイドラインがプロファイリングに対し、特別な規制をかけています。

例えば、プロファイリングでつくられた健康等に関する情報はあくまでも推知情報なので要配慮個人情報（個人情報保護法2条3項）の定義には該当しません。

しかし、人事データ利活用制度は、少なくとも人事分野においてはそのような情報を要配慮個人情報に準じて取り扱う（例えば生成の際に本人の同意を得る）べきとしています。

（4）個人情報保護法改正の議論

AIと個人情報の関係では、現在：

• 要配慮個人情報の取得や第三者提供等、本来同意が必要な場合についてもAIの学習目的であれば不要といった、AI関係の個人情報保護法改正が議論されています

この限りでは、個人情報保護法の規制を緩める方向ですが、課徴金や団体訴訟等も議論されていることから、引き続き注視すべきといえます。

教訓：プロファイリングに関する規制を理解し、AIに分析が入ることによる個人情報利用目的記載の変更の必要性を指摘しましょう！✅

📌 まとめ

システム開発契約のポイント

• ✅ ユーザの協力義務とベンダのPM義務は車の両輪
• ✅ 「相手が悪い」と決めつけず、双方の義務履行状況を確認する
• ✅ 完成基準は「最終工程完了説」、契約不適合の基準は「仕様」
• ✅ 仕様書の確認は慎重に！

AI法務のポイント

• ✅ 著作権法30条の4は万能ではない！入力・出力の両段階を検討する
• ✅ AI開発は「探索的段階型」で徐々に練り上げる
• ✅ PoCを活用してリスクを軽減する
• ✅ プロファイリングはプライバシーポリシーに明記する

IT・AIの法律問題は、もはや専門家だけのものではありません。すべての法務担当者が基礎を理解しておくことが大切です！🚀

この記事が参考になりましたら、ぜひシェアしてください！ 📢