情報システム・ソフトウェア取引トラブル事例集

はじめに/きっかけ

今回のシリーズでは、AIの発展に伴って受託、Saas様々なソフトウェアが開発されていく昨今で、要件が明確でないまま開発して後々訴訟、、という結末を迎えないために、経済産業省から出ているトラブル事例集を取り上げて詳細に解説を進めて行くようにしていくことを目的としています。

きっかけ

AIプロダクトの責任範囲や訴訟リスクについて調べるようになったきっかけは、私自身の経験に基づいています。普段、私はAIプロダクトの要件定義、開発、運用を担当しており、特に生成AIが一般化し、ユーザーが手軽に試せるようになった時代におけるプロダクト運営の難しさを感じることが多くなっています。生成AIの進化により、ユーザーはさまざまな用途でAIを活用し、その結果が予想外の方向に展開することも少なくありません。こうした背景の中で、プロダクトが提供するAIの出力や判断に対する責任がどこにあるのか、また、万が一その出力が予期せぬ結果を招いた場合の訴訟リスクはどうなるのかを深く考える必要があると感じました。

ユーザーが生成AIを利用する場面では、その結果が企業や個人に対して直接的な影響を与えることが増え、場合によっては重大な問題に発展することもあります。これにより、AIプロダクトを運営する側として、法的責任やリスク管理に関してより一層の注意が必要となっています。AIがどこまで自律的に判断を下し、その判断に伴う結果が誰に帰属するのかという問題は、単なる技術的な課題を超えて、法律や倫理の観点からも重要なテーマです。このような動機から、AIの責任範囲と訴訟リスクに対する調査を開始しました。

しかし、現時点ではAIに関連する責任や訴訟の事例はまだ豊富ではなく、これらの問題に対する明確な解決策や枠組みが確立されているとは言い難い状況です。そのため、まずはより広範なソフトウェアのトラブルやその対処法、責任の所在に関する知見を蓄積することが重要だと考えています。ソフトウェア業界では、バグやセキュリティの脆弱性が原因で発生するトラブルが頻繁に報告されており、その対応方法やリスクマネジメントの手法も多く存在しています。これらの実例をもとに、AIの分野に応用できる教訓やベストプラクティスを見出すことができるはずです。

ソフトウェアトラブルの一般的な知見を得ることで、AIプロダクトにおける潜在的なリスクや責任範囲をより深く理解し、さらにそれをプロダクト開発や運用に活かしていくことが私の目的です。そうすることで、今後のAIプロダクトの安全性や信頼性を高め、ユーザーに対して安心して利用できる環境を提供していきたいと考えています。

参照している文献

参照しているのは以下の資料です。経済産業省が提供している「ソフトウェアトラブル事例集」です。ソフトウェア開発や運用において発生する問題の具体的な事例をまとめ、その原因分析や対策を示しています。主な目的は、信頼性や安全性の向上のためにトラブルを未然に防ぎ、適切な対応を促すことです。この文書を通じて、一般的なソフトウェアのトラブルについての知識を深め、開発者や運用担当者が参考にできる内容が掲載されています。

https://www.meti.go.jp/policy/it_policy/softseibi/trouble%20cases.pdf

どのようなことを目的にしている資料か？

冒頭が非常に興味深い紹介から開始されています。

モデル契約書や契約・開発手順を 実践していれば、かかるトラブルは防げたかどうかを具体的に指摘した。特に、追補版との関係では、① 本来は顧客が行うべき業務要件定義の策定に関して、ベンダが顧客に対して重要事項説明書を用いて 要件定義支援契約等の具体的な契約内容を説明した上で要件定義支援契約等を締結していれば、深 6 刻なトラブルは防げたかどうか、②パッケージソフトウェアの選定責任を明確化していれば、選定されたパ ッケージソフトウェアが顧客の業務に合致しないというトラブルは防げたかどうか、③ユーザも自らの責任 を自覚してベンダと親密に協議して要件定義を実施するなど、ベンダとユーザの責任範囲を明確にして おけば、トラブルはある程度防げたかどうか、④検収のやり方やテストに用いるデータを事前に決めてお けばトラブルは防げたかどうかなどを具体的に指摘した。

AIのプロダクトを開発する身としては、グッと来る記載になっており、この後の展開に期待が持てる内容になっています。

資料の使い方

では、この資料の使い方をどのように想定しているかというのが以下で紹介されています。

(4) トラブル事例集の使い方 トラブル事例集は、これからシステム開発を行いたいと考えているユーザにとっては、システム開発に 伴う様々なリスクを認識し、実践すべきシステム開発の手順や用いるべき契約書の重要性をよく理解する ことができることに加えて、ベンダを選定する際の大きな力にもなる。他方、ソフトウェア開発を専門に行っ てきたベンダにおいても、トラブル発生の様々な原因を理解することにより、顧客への説明不足や契約書 の不備などの反省材料をよく認識して、これまでの商慣行を見直す契機となりうるものである。

ユーザーにとっての使い方/ベンダーにとっての使い方

＜ユーザー側の使い方＞

システム開発にかかるリスク
・・・経験から色々思い浮かぶ読者の方もいると思います。要件定義がうまくいかない、要件定義通り開発ができない、開発が遅れる、等々

を認識し、

実践すべきシステム開発の手順や用いるべき契約書の重要性をよく理解することができる
・・・実は私も特に契約書についての内容をそこまで認識できていないので、個人的にも勉強を進めたい

加えて、

ベンダー選定の際の大きな力
・・・ユーザー側としてベンダー選定を今やっている人、また、普段選定したベンダーに開発を丸投げしている場合には、ハッとくる。。？？

になるとされています。ソフトウェアを利用する際に起こり得るトラブルやリスクについての理解を深めることが目的です。ユーザーはこの事例集を参考に、利用するソフトウェアの信頼性や潜在的な問題点を事前に把握し、問題が発生した際に迅速かつ適切に対応できるようにすることが期待されています。また、トラブルの原因を知ることで、ベンダーと効果的にコミュニケーションを取ることができます。

一方

＜ベンダー側＞

トラブル発生の様々な原因
・・・どんなケースでどの用に事前に対応すればいいかを見ておくと、自分の身を守ることにもなりますね。

を理解することにより、

顧客への説明不足や契約書 の不備などの反省材料をよく認識して、これまでの商慣行を見直す契機
・・・なかなか大きな話ですが、最近のAIの開発にも関連して、従来の商慣行を認識しておき、あるべき商慣行を検討するきっかけになればいいと個人的にも思います。RAGシステムの開発や、エージェントの開発といった新しいものがでてきている中で、要件定義のあり方をどのようにしていくべきかというテーマについて個人的には興味があります（この資料の対象ではありませんが）

となる

と説明されています。提供するソフトウェアの品質向上やトラブル防止のために、事例を活用することが推奨されています。ベンダーは、過去の事例から学び、同様の問題が自社製品で発生しないようにするための予防策を講じることができます。また、これらの事例をプロジェクトのリスク管理や品質保証プロセスに取り入れることで、トラブル対応の効率化を図ることが可能です。

では、次回以降で具体的にモデル契約書について見ていきましょう。