민간 기업의 IT 성과는 분기 실적, 효율성 향상, 경쟁력 확보 등으로 평가된다. 하지만 지자체 CIO가 마주하는 현실은 완전히 다르다. 이들이 상대해야 할 ‘고객’은 매일 시의 서비스에 영향을 받는 주민이다. 광대역 인터넷, 쓰레기 수거처럼 시민의 일상과 직결된 서비스는 언제나 원활해야 한다. 프로젝트가 성공하면 정당한 찬사를 받지만, 실패하면 즉각적이고 격렬한 비판에 직면한다. 미국 캘리포니아주 산타모니카, 호주 시드니,…
I cambiamenti guidati dalla tecnologia sono più frequenti che mai, ma il successo non è affatto garantito. Secondo la società di ricerca Gartner, solo un’organizzazione su cinque ha ottenuto i benefici attesi dalle proprie iniziative o progetti di trasformazione nel 75% o più dei casi. “Gli altri sono costosi fallimenti”, afferma Cynthia Phillips, direttore senior di…
클라우드플레어(Cloudflare)가 프로젝트 갈릴레오(Project Galileo)의 확대를 발표하며 비영리 단체와 독립 언론을 대상으로 AI 크롤러 차단 및 제어 기능을 무료 지원한다고 밝혔다. 프로젝트 갈릴레오는 DDoS 공격으로부터 위험에 처한 공익 단체를 보호해 온라인 접근성을 유지하도록 지원하는 클라우드플레어의 무료 서비스다. 이번 프로그램을 통해 전 세계 750여 명의 언론인, 독립 뉴스 기관 및 뉴스 수집을 지원하는 비영리 단체는 클라우드플레어의 ‘봇…
기술 인재 채용 기업 하비 내시(Harvey Nash)의 최근 보고서에 따르면, CIO는 정규직 IT 직무가 크게 감소할 것으로 예상하고 있다. 업계 전문가들은 IT 업무를 내부 인력, 계약직, 외부 파트너사 간에 어떻게 분배할지에 대한 방식이 큰 전환기를 맞고 있다고 설명한다. 동시에 AI 역시 중요한 요인으로, 필요한 경험과 교육 수준은 물론 경영진이 AI가 결국 인력 수요 감소로 이어질…
システム開発のトラブルが法廷に持ち込まれたとき、勝敗を分ける決定的な要因は、当事者の言い分や技術力の優劣とは限りません。多くの場合、その前に立ちはだかるのは「交わした契約は、法的に見て一体何だったのか？」という、きわめて根本的な問いです。成果物の「完成」を約束した請負契約なのか、それとも専門家としての業務「遂行」そのものを約束した準委任契約なのか。この線引き一つで、報酬を請求できるか、仕様変更にどう対応すべきか、そして納品物の不具合（契約不適合）の責任は誰にあるのか、といった議論の土台が全く変わってしまうのです。 この境界線は、単なる法律用語のパズルではありません。プロジェクトのリスクを誰が、どの範囲で背負うのかという、ビジネスの根幹に関わる「設計思想」そのものです。 この記事では、難解に思えるこのテーマを、二つの対照的な裁判例を読み解きながら、分かりやすく解説します。一つは、契約を「準委任」と判断しつつも、ベンダーに専門家としての重い責任を認めた令和2年9月24日東京地裁判決。もう一つは、契約書の具体的な条項の組み合わせを重視し、「請負」であると結論付けた平成28年4月20日東京地裁判決です。 これらの事例を深く掘り下げることで、条文の解釈論に留まらない、「実務で本当に役立つ」判断のポイントを明らかにします。契約書の書き方、日々のプロジェクト運営で残すべき記録、そしてアジャイル開発のような現代的な手法にも通じる「境界線の描き方」を体系的に整理します。「準委任だから安心」「請負だから危険」といった単純な思い込みを乗り越え、裁判所が実際にどこを見ているのか、その「思考の地図」を手に入れることが、この記事のゴールです。 なぜ契約類型が重要なのか？——「完成」を約束するか、「最善を尽くす」ことを約束するか そもそも、なぜ契約が「請負」か「準委任」かで、これほどまでに結論が変わるのでしょうか。答えは、民法が定めるそれぞれの「約束の本質」の違いにあります。 請負契約とは、一言でいえば「仕事の完成」を約束する契約です（民法632条）。家を建てる大工さんをイメージすると分かりやすいでしょう。約束通りに家が完成しなければ、代金はもらえません。システム開発でいえば、ベンダーは約束したシステムを完成させる結果責任を負います。もし完成しなければ報酬は請求できず、完成しても品質に問題があれば、契約不適合として責任を問われます。 一方、準委任契約は、「善良な管理者の注意をもって業務を処理する」ことを約束する契約です（民法656条、643条）。こちらは、弁護士やコンサルタントをイメージしてください。彼らは裁判での勝訴や経営改善という「結果」を100%保証するわけではなく、専門家として「最善を尽くす」ことを約束します。システム開発においても、ベンダーは結果としての「完成」ではなく、専門家としての能力と注意を尽くして開発プロセスを「遂行」することに責任を負います。極端な話、最善を尽くしてもシステムが完成しなかった場合でも、その過程に落ち度がなければ、作業した分に応じた報酬を請求できる可能性があるのです。 この違いが、報酬、検収、プロジェクト頓挫時のリスク負担など、あらゆる重要局面で決定的な差を生みます。しかし、仕様変更が当たり前で、ユーザーとベンダーが協力しながらゴールを目指す現代のプロジェクトでは、「完成」の姿を契約時に厳密に定義することが難しくなっています。この現実が、契約の性質を曖昧にし、深刻な紛争の火種を生んでいるのです。 「準委任だから安心」は大きな間違い——令和2年判決が示すベンダーの重い責任 開発ベンダーの間では、「準委任契約なら完成責任がないからリスクが低い」という声が聞かれます。しかし、この安易な期待は危険な誤解です。そのことを明確に示したのが、イベント管理システムの開発をめぐる令和2年9月24日の東京地裁判決でした。 この裁判で、裁判所は契約の性質を「準委任」と認定しました。しかし、それでベンダーが免責されたわけではありません。むしろ、準委任契約だからこそ問われる、専門家としての重い「善管注意義務」とは何かを具体的に示した点に、この判決の真の価値があります。 裁判所が指摘したのは、ベンダーには単に指示された作業を行うだけでなく、プロジェクトを適切に管理・運営する「プロジェクトマネジメント義務」が中核的な責任として含まれる、という点です。具体的には、 開発に必要な作業を正確に洗い出し、 現実的なスケジュールを見積もり、 適切なスキルを持つ人員を確保する、 といった、プロジェクト管理の基本を全うする責任です。さらに、進行中に問題が起きれば、速やかにユーザーへ報告し、専門家として解決策を示す「説明・警告義務」も含まれるとしました。 この事件では、ベンダーがこれらの義務を怠ったために開発が遅延し、プロジェクトが破綻したと判断されました。その結果、裁判所はベンダーの報酬請求を一部認めつつも、ユーザーからの損害賠償請求も一部認める、という実務的な「痛み分け」の結論を下しました。この判決が教えてくれるのは、たとえ契約名が「準委任」で、アジャイル的な進め方を想定していたとしても、ベンダーは専門家としてプロジェクトを主体的にコントロールし、ユーザーを正しく導く責任からは決して逃れられない、ということです。準委任契約は、責任の放棄を許す魔法の杖ではないのです。 「請負」認定の決め手は契約書の“構造”——平成28年判決に学ぶ条項の力学 対照的に、契約の性質を明確に「請負」だと判断したのが、無線LANルータのソフトウェア開発に関する平成28年4月20日の東京地裁判決です。この裁判で裁判所が重視したのは、契約書のタイトルに「請負」と書いてあるか否かではありませんでした。それよりも、個々の条項がどのように組み合わされ、リスクと対価の関係をどう規定しているかという、契約全体の構造でした。 裁判所が「請負」であることの決定打と見なしたのは、主に以下の三つの条項の組み合わせ、いわば「運命共同体」セットです。 報酬の支払条件：報酬は、成果物が納品され、ユーザーが「検収に合格」した後に支払われる。 契約不適合責任：成果物に不具合があった場合の、ベンダーの修補や賠償責任が明確に定められている。 権利の移転時期：ソフトウェアの著作権は、ユーザーが「代金を全額支払った後」にベンダーから移転する。 この判決が示す重要なメッセージは、契約の法的な性格は、当事者が付けた「名前」ではなく、「報酬・検収・権利移転」という三点セットがどう連動しているかで実質的に決まる、ということです。ベンダーが「完成」というリスクを引き受け、ユーザーがその「結果」を確認して対価を支払い、最終的に権利を手に入れる。この構造が契約書に組み込まれていれば、たとえ報酬が工数ベースで計算されるとしても、その契約は「請負」と評価される可能性が高いのです。 ちなみに、この判決は、請負契約であっても当初の範囲を超える追加・変更作業については、別途の報酬を支払う黙示の合意があったと認め、追加代金の請求を一部認めています。「請負契約だから、どんな仕様変更にも無償で応じなければならない」というのも、また短絡的な誤解なのです。 裁判所は「リスクと対価の結びつき」を見抜く——魂を込めた契約書作成のススメ 二つの判決を比べると、裁判所の視線は常に「リスクと対価は、契約上どのように結びついているか」という一点に注がれていることが分かります。準委任の事件では、ベンダーは「完成」という重いリスクを負わない代わりに、専門家として「プロセス」を適切に管理するリスクを負い、その手腕が問われました。請負の事件では、契約書の条項の配置から、ベンダーが「結果」に対するリスクを引き受けていると判断されました。つまり、契約類型とは、プロジェクトのガバナンスをどう設計したかという、当事者の「意思表示」にほかならないのです。 ここから、実務における重要な指針が導かれます。それは、契約書を作成する段階で、プロジェクトのリスク配分を意識的に設計することです。 準委任契約を選ぶ場合：「検収」という言葉が持つ「合格／不合格」の強い意味合いを避け、「受入基準」といった表現を使いましょう。スプリントやマイルストーンごとに、作業がその基準を満たしたことを確認し、その確認をもって当該期間の報酬支払いが確定する、というサイクルを明確に契約書に落とし込みます。 請負契約を選ぶ場合：「完成」とは具体的に何を指すのか、その定義を明確にすることが不可欠です。また、ユーザーによる「検収合格」のプロセス、不具合の重大性の判断基準、ユーザーが理由なく検収を引き延ばす場合に備えた「みなし検収」の条件などを具体的に定めておくことが、後の紛争を防ぎます。さらに、追加・変更作業が発生した際の合意形成プロセス（要望→見積→承認→着手）を文書化し、その記録を残す運用を徹底することが極めて重要です。 こうした基本的な設計を丁寧に行うことこそ、過去の多くの判例が教えてくれる、紛争を避けるための王道なのです。 アジャイル時代の落とし穴——「準委任」というラベルに安住する危険性 仕様の変動を前提とするアジャイル開発では、その柔軟性から準委任契約が好まれる傾向にあります。しかし、ここには「アジャイル開発だから準委任でいいだろう」という思考停止の罠が潜んでいます。前述の令和2年判決が示すように、準委任契約であってもベンダーのプロジェクトマネジメント義務は重く、それを怠れば責任を問われることに変わりはありません。 さらに注意したいのは、契約の「名前」と「実態」の乖離です。たとえ契約書に「準委任」「アジャイル」と書いてあっても、実際のプロジェクト運営が、最初に詳細な仕様を固め、厳格な納期を設け、開発環境も固定する、といったウォーターフォール的なものであればどうでしょうか。裁判所は、ラベルではなく実態を見て、これは実質的に「請負」に近いと判断し、ベンダーに完成責任に近い義務を課す可能性があります。 結局のところ、真のリスク管理とは、契約の名称に頼ることではなく、プロジェクトの実態に即した運用設計を地道に行い、その証拠を残すことに尽きます。スプリントごとの受入基準を明確に定義し、プロジェクト中止時の清算ルールを定め、仕様変更のやり取りをチケットシステム等で克明に記録する。こうした一つ一つの積み重ねこそが、契約の境界線を守るための、最も確実な防壁となるのです。 紛争に勝つための設計図——「条項・運用・証拠」の三層で考える 最後に、これまでの議論をまとめ、実践的なフレームワークとして「条項・運用・証拠」の三層構造で考えることを提案します。 第一層：条項（設計図） 契約書そのものです。「検収・支払・権利移転」を核に、責任限定、性能保証、変更・中止ルール、ユーザーの協力義務といった各パーツを、プロジェクトの性質に合わせて論理的に矛盾なく組み立てる設計力が問われます。 第二層：運用（日々の行動） 設計図を現実に動かすためのプロジェクト運営です。契約書で定めたルール（受入基準、課題管理、議事録など）を、いわば「プロジェクトの憲法」として関係者全員が遵守する規律が求められます。 第三層：証拠（行動の記録） 運用が設計図通りに行われたことを客観的に示す記録です。チャット、チケット、見積・承認の履歴など、日々の業務で生まれる電子データは、万一の際に、原因や責任の所在を明らかにする決定的な証拠となります。 準委任契約を選ぶなら、曖昧になりがちなユーザーの協力義務（レビュー期限など）を具体的に条項に書き込む。請負契約を選ぶなら、紛争の元になりやすい「完成」の定義や「みなし検収」の条件を明確にする。裁判所が見ているのは、この三層構造の整合性と、そこから浮かび上がるプロジェクト運営の実態なのです。 リスク配分の設計思想を契約書に明確に反映させよう 請負か、準委任か。この選択は、プロジェクトの特性とリスクを当事者間でどう分担するかを表現するための「手段」に過ぎず、どちらが絶対的に優れているというものではありません。 二つの裁判例が教えてくれたのは、準委任でもマネジメントを怠れば責任を負うという事実と、契約書の条項設計が請負という性質を強く方向付けるという事実でした。どちらの道を選ぶにせよ、プロジェクトを成功に導き、無用な争いを避けるために重要なことは共通しています。それは、リスク配分の設計思想を契約書に明確に反映させ、そのルールに沿った誠実な運用を心がけ、その過程を記録として残していくことです。 システム開発に関わるすべての人が、契約書の言葉の裏にある設計思想を深く理解し、自らのプロジェクトを守るための最適な境界線を、主体的に描いていくこと。それこそが、真のプロフェッショナリズムといえるのではないでしょうか。 Read More from This Article:…
Oracle’s announced $1.6 billion restructuring plan is barely underway, with just $415 million spent as of Aug. 31, which means a significant number of layoffs is still pending. Forrester projects there will be roughly 10,000 more by the end of December. Even though that is not a massive number for a company with a worldwide…
Amazon’s AWS European Sovereign Cloud, set to launch in Germany by the end of 2025, is starting to take shape with the announcement of SAP’s Sovereign Cloud as its latest partner. The announcement is part of a gradual expansion of the capabilities on offer to organizations looking to invest in the concept of sovereign clouds…
プロフィール：大柴 行人Robust Intelligence共同創業者、Cisco Foundation AIディレクター。高校卒業後、渡米。2019年、ハーバード大学にてコンピューターサイエンス・統計学の学位を取得。大学在学中に、「AIの脆弱性」を研究テーマにAIのトップ会議に複数論文が採択。2019年に当時の指導教授とRobust Intelligenceを創業。セコイア、タイガー・グローバルなどから資金調達し、シスコへ売却。Forbes 30 Under 30に北米・日本両地域で選出。Silicon Valley Japan Platform Executive Committee。デジタル庁先進的AI利活用アドバイザリーボード委員。AIガバナンス協会代表理事。 米国では株主総会の議題に、高まるAIガバナンスへの関心 大柴氏はまず、AIガバナンスについて「AI技術の活用にあたって、企業内でリスク管理、法への対応が必要になる。コーポレートガバナンスの一環としてITガバナンスをこれまでやってきたが、それと同様にAIにもガバナンスが必要」と説明する。 AIガバナンスに対する経営層の関心は高まっている。投資会社のBerkshire Hathaway（バークシャー・ハサウェイ）が株主総会で企業にAIの利用についての監視や管理について経営陣に求める提案があるなど、株主総会の場でAIガバナンスが重要な議題になりつつある。「この傾向は遅かれ早かれ日本にも波及するだろう」と大柴氏は予測する。投資家からAIの活用状況やAIリスクへの対応について質問が当然のように出てくる時代が迫っているのだ。 この変化は、AIガバナンスが従来のリスク管理部やセキュリティ部の範囲を超えた経営課題であることを示している。その重要性から経営課題となり、CISO（最高情報セキュリティ責任者）職が生まれたサイバーセキュリティと同じような道のりをたどっているといえる。 そのAIガバナンスを考えるにあたって、技術と組織の2つからのアプローチが必要と大柴氏は指摘する。技術面では、AIのハルシネーション（幻覚）やデータ漏洩などのリスクがあり、組織面では、それらリスクにどのような組織で対応していくのかを考える。組織では、ガバナンスは通常、第1線（ビジネスユースケースの当事者）、第2線（リスク管理者）、第3線（監査役）と3つのラインで組むことが多いが、AIガバナンスではこの3つのラインをどのように作るのかを考える必要があるという。 AIエージェントは生成AIよりもリスクが大きい AIガバナンスに取り組むにあたって、まずはリスクを理解する必要がある。経営者が把握しておくべきこととして、AIには技術リスクと社会リスクの2つがある、と大柴氏は整理する。 1つ目の技術リスクは、AIであるがゆえに間違ったことを言ってしまう（ハルシネーション）や、AIの活用によりデータが漏洩してしまうといった、AI技術の制約に起因するもの。技術リスクについては、技術が向上すれば改善されていく可能性もあるという。 2つ目の社会リスクには、学習データの著作権問題、オフショア人材を使ったデータラベリングで不適切な画像や有害コンテンツを低賃金で大量に閲覧・分類させる問題なども含まれる。これらは技術の進歩だけでは解決されず、むしろAIが高性能化すればするほど深刻化する可能性がある。 生成AIのトレンドに追いつくまもなく、AIエージェントの時代に突入しつつある。大柴氏はCIOなど幹部が知っておくべき点として、「AIよりもAIエージェントの方がリスクや脅威は大きい」と警告する。 「これまでの生成AIはコパイロットのように、あくまで助手として人がAIに助けてもらうという使い方だった。これに対して、AIエージェントはその名（エージェント＝代理人）の通り、代理人として人間のようにさまざまな意思決定をする」と大柴氏は説明する。このような性質の変化から、アシスタントのリスクよりエージェントのリスクの方が高いとする。 さらに深刻な点として、次のように説明する。「AIエージェントは人間よりも、意思決定のスピードが速く、短時間でより膨大なデータにアクセスしている」。つまり、AIエージェント時代のリスク管理は、従来のリスク管理と比べると脅威のレベルも、規模も大きくなるという。 プロンプトインジェクションだけではない、AIの脅威は？ 実際の脅威の例として、プロンプトインジェクション攻撃の実例を挙げる。論文サイト「arXiv（アーカイヴ）」で公開された一部の論文に、高評価するよう指示するプロンプトが仕込まれ、査読AIがそれらの論文を高く評価するといった事例が既に報告されている。 フィッシング攻撃とAIを組み合わせた新たな脅威も見られるという。フィッシングメールの中に、AIにしか分からないようなコマンドが仕込まれており、それをコピーペーストしてAIに入力すると、AIが機密データを取得して外部に送信してしまうといった攻撃手法が現実化している。従来のマルウェアやフィッシング攻撃にAI特有のリスクを組み合わせた新しい形の脅威である。 セキュリティコミュニティであるOWASP（Open Web Application Security Project）では、LLMアプリケーションの脅威トップ10を挙げている。その中には、上記のプロンプトインジェクション、機密情報の漏洩、データおよびモデルの汚染、社内の情報との連携に用いられることが多いRAG（Retrieval-Augmented Generation：検索拡張生成）システムでの埋め込み処理における脆弱性などが挙がっている、と紹介する。 国際的な規制動向：日本は米国と欧州の中間 パワフルな技術であるAIに対して、世界各国では規制を進めている。だが、アプローチは様々だ。大柴氏は米国、欧州、日本の3つのアプローチを分析した。 もともと、規制を作るよりガイドラインや基準を設けるソフトロー寄りだった米国は、トランプ政権の下、さらにその方向性が強まっている。トランプ政権は前政権の大統領令を取り消し、規制緩和の方向に舵を切っている。特にDEI（ダイバーシティ、エクイティ、インクルージョン）関連では、「発言の倫理性を取り締まる部分は、かなり緩くなってきている」と状況を説明した。一方で「セキュリティは、国防とも関連してくるので引き続きかなり投資がされている」という。 対照的なのが欧州だ。欧州連合（EU）のAI規制「EU AI Act」に代表されるように、規制強化の方向性をとっている。EU AI ActはAIシステムをリスクレベル別に分類し、高リスクシステムには厳格な要件を課すもので、2024年に成立し、発効している。段階的に施行が始まっており、今後新しいオープンソースAIモデルを出す際には、安全性や透明性などのチェックが求められる。 両極にある米国と欧州に対して、日本はちょうど良い中間にある、と大柴氏は評価する。2025年に「AI新法」が公布されたが、大柴氏は「日本政府は基本的には研究開発やAIの導入は促進しつつ、リスクへの対応もしっかりする。バランスを取ってAIを利用するというスタンス」と日本のアプローチを説明する。 実は大柴氏がAIガバナンス協会を立ち上げた理由は、このような日本のアプローチを支えるためだという。政府が大枠を決めた後、そこで具体的に何をどのようにチェックをすればいいのか、どのような組織や技術的な仕組みを作ればAIガバナンスを構築できるのかを考えている、と大柴氏は活動の狙いを説明する。 「攻めのAIガバナンス」：活用促進のためのリスク管理 ではAIガバナンスをどのように進めていくべきか。大柴氏が提唱するのは「攻めのAIガバナンス」だ。 「AIを使いたいがどこまで使っていいかわからない、なんとなく怖い、という声を日本企業からよく聞く。このような状況に対して、何が課題となり得るのかの解像度を高め、守るべき部分をしっかり守る。ラインを引くことで、安心してAIを使える」（大柴氏）。 実効性のあるAIガバナンス体制構築のポイントとして、大柴氏は「攻めと守りが同じ部屋にいること。SWATチームのようなものを作って一緒にやることが大切」とアドバイスする。 AI活用するプロジェクトを進めるにあたって、ローンチ準備や議論の段階から、AI、ビジネス、リスク管理、セキュリティなどそれぞれのステークホルダーが参加する。これにより、ビジネスがやりたいこと、AIでできることの議論に、リスク管理やセキュリティの観点からチェックを入れながら進めることができる。その都度チェックするというより、「可視性を確保し、リスク管理やセキュリティチームがプロジェクトを把握できている状態を作る」と大柴氏は強調する。 リスクやセキュリティが最後に入ると、せっかく進めてきたプロジェクトをリスクやセキュリティの観点から終了しなければならなくなる。もし、リスクやセキュリティを無視して推し進めた場合は、深刻なリスクを負うことになる。この点は、既存のソフトウェア開発でセキュリティチームが最初から関わるというやり方を踏襲できる。「新たに仕組みやプロセスを作るというより、既存のものを利用することが成功のポイント。その方がナレッジも溜まりやすい」と大柴氏は指摘する。「たとえば、AIやAIエージェントのPoCを進める際にAIガバナンスを組み込んでやってみる形で進めてはどうか」と助言した。 取り組みを進めるのは、当初はCISOやCRO（最高リスク責任者）など。最終的にはAIガバナンスを専門とする担当者や役職ができることが予想される。 難しい点は、「AIガバナンスはかなり複合的でマルチステークホルダーの領域」と大柴氏。「法律も絡み、プライバシーやサイバーセキュリティとの関わりもある。サプライチェーンの議論もあり、技術的な議論もある」。そこでAIガバナンス協会では社会全体の視点でAIガバナンスのあり方を探っており、取り組み項目として「AIガバナンス行動目標」の策定、実装のための自己診断ツール「AIガバナンスナビ」の開発などを行っている。 トップアジェンダとしての認識を…
Google Cloud is adding new features to Colab in BigQuery that, it said, will boost the productivity of data scientists. The role of the data scientist is undergoing a rapid transformation, according to Yasmeen Ahmad, managing director of Data Cloud at Google. In a blog post, Ahmad contends that, while data scientists have traditionally focused…
As bottom-line revenue from the use of LLMs continues to evade most companies, agentic AI with its purpose-driven autonomous capabilities may seem like the magic bullet for ROI. Not so fast. It’s true that agentic AI is on an accelerated growth path, with Capgemini estimating that the tech, …could generate up to $450 billion…