IT企業・インターネットビジネスの法律相談

なぜ「完成トラブル」がベンダを苦しめるのか

 例えば、次のような場面でお困りになったことはないでしょうか。

・仕様どおりに作ったつもりだが「思っていたのと違う」と言われ検収してもらえない

・App Store の審査が通らず「公開できていないから支払わない」と言われている

・要件が増え続け、いつまでも「完成」と言ってもらえない

システム開発の現場では、「システムが完成したかどうか」という点をめぐる対立が後を絶ちません。ベンダとしては仕様どおりに作ったつもりでも、ユーザ（注文者）から「思っていたものと違う」「まだ使えるレベルではない」と言われ、検収が行われず報酬の支払いも進まないことがあります。このような状況になると、プロジェクトは止まり、現場担当者の負担も大きくなり、経営にも影響が出てしまいます。

多くのベンダは、「納期までに仕様どおりのシステムを納品できれば、原則として報酬が支払われるはずだ」と考えています。しかし、ユーザ（注文者）は「自社の業務で問題なく使える状態になって初めて完成だ」と考えていることが少なくありません。この考え方の違いが、「完成した」と言うベンダと「完成していない」と言うユーザ（注文者）の対立を生みます。

特に厄介なのは、ユーザ（注文者）の不満の内容が、バグと言えるものなのか、それとも後から出てきた追加要望なのかがはっきりしない場合です。ユーザ（注文者）は「これは当然できるはずだ」と感じている一方で、ベンダは「そこまでは合意していない」と考えていることがあります。このギャップが整理されないまま話し合いが続くと、感情的な対立が強まり、前に進まなくなってしまいます。

あるいは、アプリ開発の分野では、App Store や Google Play の審査に通らないことが原因で、「公開できていないのだから、完成とは言えない」として報酬支払いが止まることがあります。ベンダとしては、ルールに配慮して実装していても、プラットフォーム側のガイドラインの解釈や運用の変更により、想定外の理由で却下されることがあります。それでもユーザ（注文者）からは「お金を払ってまで未公開のアプリを持っていても意味がない」と判断されてしまうことがあります。

こうした「完成トラブル」が悩ましいのは、単に技術の問題ではなく、契約書の書きぶりや、要件定義の進め方、検収のルール作りなど、プロジェクト全体の設計と深く結び付いている点です。トラブルが起きてから「言った・言わない」で争うよりも、「何をもって完成とするか」「どの段階で検収とみなすか」「想定外の事態が起きたときにどう費用と作業を分担するか」を、事前に決めておくことが重要です。

本記事では、ベンダの立場から、実際に起こりやすい「完成トラブル」の事例を取り上げながら、どのような点に気を付ければ紛争を防ぎやすくなるのか、また、トラブルが起きてしまったときにどのように対応すべきかを整理して説明します。

システム開発における「完成」の基本整理

システム開発の契約では、多くの場合「請負」という形で契約が結ばれます。請負は、民法上「ある仕事を完成させ、その結果に対して報酬を支払う」タイプの契約とされています。この考え方をシステム開発に当てはめると、「合意した仕様にしたがってシステムを作り、成果物を引き渡した状態」が完成のイメージとなります。

ここで重要なのは、「ユーザ（注文者）がどこまで満足しているか」と「法律上、仕事が一応完成しているか」は別に考えるという点です。システムが一通り動作し、合意した仕様に沿って機能しているのであれば「完成している」と評価される余地があります。そして、後から見つかった不具合や性能不足は、契約不適合責任（修正、減額、損害賠償、解除）で処理するのが法律の原則的考え方となります。

ところが、実務上は、「検収」が完成と深く結び付きます。

多くの契約では、システムを納品した後に受入テストを行い、検収合格とされた時点で、仕事の終了や報酬請求の基準時としているからです。

もっとも、検収が終わっていなくても、システムが稼働を開始し、ユーザ（注文者）がその成果物を実際に利用しているような場合には、事実上「完成している」と評価される場面もあります。その上で、不具合や不足があれば、それが契約内容と比べてどの程度のズレなのかを検討し、契約不適合責任（修正、減額、損害賠償、解除）といった話に進むことになります。

以上を踏まえると、ベンダは次の三点を押さえておくことが大切です。

①何をもって完成とするか 仕様書や要件定義書、設計書に「求められる機能・性能・画面」などをできるだけ具体的に書き込むと共に、該当する案件に合った受入基準を決めておくことがポイントです。 ②誰がどの手順で検査するか ベンダ側のテストとユーザ（注文者）側の受入テストの役割分担を明確にし、検査期間や指摘方法（不具合票の起票など）を契約書等で決めておくことがポイントです。 ③検収や完成をめぐるトラブルが起きたときの扱い 不具合と仕様変更（追加要望）を分けて整理すると共に、無償対応となる場面と追加費用を要する場面とを予め決めておくことがポイントです。

 

「完成」という言葉だけを見るのではなく、「仕様」「検収」「契約不適合」の三つをセットで整理しておくと、ベンダとして自社がどこまで責任を負い、どこから先は別途協議とするのかが見えやすくなります。

具体的事例の検討

(1)品質不満を理由に検収拒否・報酬不払いとなるケース

【例】

ベンダが合意した仕様に基づき開発を行い、テストも実施したうえでシステムを納品した。 しかし、ユーザ（注文者）が「使いにくい」「期待したレベルではない」といった理由で検収書に押印せず、報酬も支払わない。

 

＜考え方＞

システム開発契約は、一般に「仕事を完成させ、その結果に対して報酬を支払う」請負契約と理解されています。

このため、ユーザ（注文者）から「完成していない」と主張されると、そもそも報酬請求の前提が否定される形になり、ベンダとしては大きなリスクを負うことになります。

もっとも、「完成していない」と評価されるかどうかは、ユーザ（注文者）の主観的な満足度だけで決まるわけではありません。多くの裁判例では、ベンダが約束した工程を終え、成果物が仕様や性能を客観的に満たしていれば、検収書がなくても完成を認めることが妥当とされています（東京地方裁判所平成14年4月22日判決など）。

ところで、現場実務では、仕事の完成と検収が不可分一体となっていることが通常です。

しかし、例えば、ユーザ（注文者）には検査を行い、見つけた不具合を一定期間内に通知する義務があり、これを怠った場合には権利行使が制限されることがあります。

また、一定期間内にユーザ（注文者）が不合格通知を行わない場合には自動的に検収合格とみなす「みなし検収」条項が、完成を裏付けるものとして機能することがあります。

さらに、ユーザ（注文者）が検収を拒んでいる場合でも、ユーザ（注文者）には受入検査を行い、問題がない部分については検収を進める義務があると考えられています（東京高等裁判所平成27年6月11日判決など）。

以上を踏まえると、納品後に見つかった不具合や性能不足については、「仕事そのものが未完成かどうか」とは別に、「契約内容と違う点があるかどうか」という観点から整理することが重要です。

そして、①システムとしては一応完成しているので報酬支払義務は生じていること、②残っている問題点は、契約不適合にあたる不具合は無償で対応し、追加開発に当たるものは有償対応となることを丁寧に説明することが、交渉や紛争対応の出発点になります。

なお、契約内容と違う点があるのであれば、ベンダは「契約不適合」があると認識し、ユーザ（注文者）による修補請求や代金減額、損害賠償、解除などを受け入れなければなりません。

＜トラブル予防策＞

ベンダの予防策としては、次の点を意識して主張と立証を組み立てることが重要です。

・契約書、仕様書、要件定義書などで、どのような機能や性能を実現すると合意していたか

・テスト計画書、テスト結果、不具合管理表などにより、合意した範囲については動作していると断定できるか

・納品後にユーザ（注文者）が実際の業務でシステムを利用している事実があるか

・ユーザ（注文者）が不満として挙げている点が、仕様上予定されていたものか、それとも後から出てきた追加要望に近いものか

(2)アプリ審査（App Store / Google Play）に通らず、報酬が支払われないケース

【例】

スマートフォンアプリの受託開発を行い、テストでも問題なく動作した。 しかし、ユーザ（注文者）は「ストア審査に通らない」という理由で、報酬を支払わない。

 

＜考え方＞

請負契約では、仕事の目的物の引渡しと同時、または仕事の完成後に報酬を支払うと定められています。

上記事例では、「どこまでできたら仕事が完成したと言えるか」が重要となります。

この点、App Store や Google Play には、それぞれ独自の審査基準やポリシーがあります。特にApple は App Store Review ガイドラインで、技術・内容・デザインについて詳細な基準を示しており、違反があればアプリを却下することがあると説明しています。

これらの審査やポリシーの運用は、ベンダやユーザ（注文者）ではなくプラットフォーム事業者が決めるものであり、ベンダが完全にコントロールできるものではありません。

そのため、契約の文言や交渉の経緯で特に約束していない限り、「ストア審査を必ず通すこと」までがベンダの義務だとまでは言えない場面が多いと考えられます。すなわち、「仕様どおりに動作し、ストアに申請できる品質のアプリを開発して引き渡すこと」が、仕事の完成と評価されることになります。

一方で、契約書や提案書、見積書などに「ストア公開まで対応します」「審査通過を前提としたプロジェクトです」といった表現がある場合、ユーザ（注文者）は「公開まで含めて完成だ」と理解している可能性が高く、ベンダもその点を認識していたのではないか（＝契約内容になっていたのではないか）と指摘されるリスクは高くなります。しかし、例えば、

・ユーザ（注文者）が提供した画像や文言がポリシーに反している場合

・課金の設計や広告の入れ方がガイドラインに反している場合

・開発途中でガイドラインやポリシーが変更された場合

はベンダに帰責事由があるとは言い難く、ベンダが責任を免れる可能性は高いと考えられます。

以上を踏まえると、契約書、仕様書、メールや議事録に加えて、App Store Connect や Google Play Console 上の審査結果画面、リジェクト理由、再申請の履歴などを整理し、どこまでが仕様どおりの開発の問題で、どこからがプラットフォーム側の判断やユーザ（注文者）側の事情によるものかを切り分け、ユーザ（注文者）に丁寧に説明することがポイントとなります。

＜トラブル予防策＞

ベンダの予防策としては、次のような点を契約書と実務の両面で整理しておくことが望ましいといえます。

・成果物の定義を「端末上で正常に動作し、ストアに申請可能なアプリ」とするか、「ストアで公開されたアプリ」とするかを明確にすること

・ストア審査の結果に応じた対応範囲（無償で対応するリジェクト理由、回数の上限、それ以降は追加費用とするかどうか）を決めておくこと

・ユーザ（注文者）が用意するコンテンツや企画内容がガイドライン違反となった場合の責任分担を定めておくこと

・プラットフォーム側のルール変更や運用変更による影響について、双方で協議のうえ対応を決めるといった条項を設けること

(3)要件定義が甘いため、いつまでも完成扱いにならないケース

【例】

要件定義が曖昧なまま開発に着手し、その後も具体的な決定が先送りされた。 この結果、プロジェクト終盤になって、ユーザ（注文者）は「まだ足りない」と主張し、ベンダは「当初の説明より範囲が広がっている」と主張し、見解の相違が表面化する事態となった。

 

＜考え方＞

ユーザ（注文者）は、仕様の決定やマスタデータ作成などに協力する義務があります。一方、ベンダには、追加要望がスケジュールや費用に与える影響を説明し、必要に応じて断る、あるいは別途契約とするなど、プロジェクトを管理する義務があるとされています。

結局のところ、上記のような事例は双方が負担する義務を履行しなかったことに起因することが多く、どちらか一方に責任があると言い難いのが特徴となります。

以上を踏まえると、見解の相違が表面化した時点でベンダはユーザ（注文者）と協議の場を持ち、改めて開発範囲を確定させることが重要となります。

なお、対立が避けられない事態となった場合、どこまでの要件が当初合意されていたのか、どの時点で仕様が変わったのか、ユーザ（注文者）がどこまで協力していたのかを、契約書・要件定義書・議事録・メールなどから具体的に導き出すことが求められます。そして、未了部分がユーザ（注文者）の協力不足や度重なる仕様変更によるものなのか、それともベンダの対応不足によるものなのかを検証しながら対処することになります。

＜トラブル予防策＞

ベンダの予防策としては、次のような点を契約と運用の両面で整えておくことが重要です。

・（規模が大きければ大きいほど）要件定義工程を別契約とし、この段階では「業務整理と要件の確定」をゴールとすること

・要件定義書が確定した時点を明確にし、その後の変更は変更管理手続を通すこと

・変更要求が出た場合は、影響範囲、期間、費用を再見積りし、合意できたものだけを反映すること

・会議体（検討会）を設け、議事録で決定事項と保留事項を整理しておくこと

(4)一部機能の未実装・バグを理由に全額不払いを主張されるケース

【例】

システムの大部分は動いているが、一部の機能が未実装又はバグが残っていることを理由に、ユーザ（注文者）が報酬を一切支払わない。

 

＜考え方＞

たしかに、請負契約は「仕事を完成させてから報酬請求ができる」とされていますので、どこか未完成な部分が残っているなら報酬は払わなくてよい…という考え方にも一定の合理性があるようにも思います。

しかし、民法は、引き渡された成果物に契約と違う点がある場合を「契約不適合」として整理し、修補や代金減額などで調整する考え方を採用しています。これは、システム全体としては利用可能な状態にあり、ユーザ（注文者）も実際に業務で使っている場合に、一部の不具合だけを理由に報酬をゼロにすることは公平でないという趣旨によるものです。

また、民法第634条は、仕事が途中で終了した場合でも、注文者が既に受けた利益の割合に応じて、請負人が報酬の一部を請求できることを定めています。このため、例えば、システムの一部が稼働し、ユーザ（注文者）が一定の利益を受けている場合には、少なくともその部分について報酬請求が認められる可能性があることになります。

以上を踏まえると、「一部機能の未実装・バグ」を理由とする全額不払いについては、次の観点をもって検討することが重要です。

・未実装、不具合の部分が、システム全体の中でどの程度の割合や重要性を持っているか

・既に稼働している機能により、ユーザ（注文者）がどの程度の利益を受けているか

・ベンダが修補の提案や対応を行っているか、それをユーザ（注文者）が拒んでいないか

その上で、どの機能が稼働しているか、ユーザ（注文者）がどの範囲を実務で利用しているか、未実装や不具合の影響がどこまで広がるのかを、テスト結果、ログ、議事録などで具体的に示しつつ、システム全体としての完成度と、残された問題点への対応方針を整理し、「全額不払いではなく、修補や一部減額、分割支払などで解決する余地がある」ことを丁寧に説明していくことが、ベンダの現実的な防御方法になります。

＜トラブル予防策＞

ベンダの予防策としては、次のような点を契約と運用の両面で整えておくことが重要です。

・契約書でフェーズ別、モジュール別に検収と支払を分ける仕組みを設けること（サブシステムごとの検収やマイルストーン払いなど）

・「重大な不具合」と「軽微な不具合」の違いを定義し、軽微な不具合があっても検収合格とし、修補は別途対応するという考え方を明記すること

・検収後に発見された不具合については、契約不適合として無償修補、減額、損害賠償などの枠組みで扱うことを予め合意しておくこと

(5)アジャイル開発の特殊性

アジャイル開発にはいくつか種類があるのですが、スプリントごとに機能を優先順位に沿って順次開発し、MVP（最小限の実用的な形）から段階的に価値を高めていく流れを指すことが多いようです。

この場合、アジャイル開発では最終的な成果物の内容が当初は完全には決まっておらず、開発の途中で見直しや変更が生じることを前提にしています。そのため、「あらかじめ決めた仕様どおりに完成させること」を前提とする従来型の開発と同じ考え方をそのまま当てはめることはできません。

以上を踏まえると、「プロジェクトの終わりに大きなシステムが一つ完成しているかどうか」だけで報酬の有無を決めるのではなく、「スプリントごとに合意した範囲の作業が行われたか」「どの程度の機能が提供されているか」を基準に報酬の有無を決めていくことが重要となります（要は請負契約ではなく、履行割合型準委任契約の方が実態に合致するということです）。

なお、現場実務を見ていると、アジャイル開発と銘打っているものの、実際には従来のシステム開発と変わらないというものが見られます。このため、ユーザ（注文者）が

・スプリントを重ねた結果、当初想定より機能範囲が変わり、「予定の機能がすべて入っていない」として支払いを拒絶する

・ベンダとしてはスプリントごとに合意した作業は実施しているが、ユーザ（注文者）が「全体としてまだ完成していない」として支払いを渋る

といったトラブルが発生しています。

このようなトラブルを避けるには、スプリントごとの成果の確認方法を文書で整理し、双方で合意しておくことが重要となります。

ベンダが整備するべき資料

システム開発トラブルの交渉段階はもちろん、裁判手続きまで進んだ場合、やはり重要となるのは証拠となります。

本記事にある「完成」トラブルを念頭に置いた場合、ベンダとしては次のような資料を日常的に整備したいところです。

(1)契約・仕様に関する資料

・基本契約書、個別契約書

・業務仕様書、要件定義書、外部設計書などの正式な仕様書一式

・契約変更合意書、追加発注書

(2)プロジェクトの経過を示す資料

・RFP、RFI、提案書、見積書

・キックオフ資料、プロジェクト体制図

・会議の議事録、決定事項一覧、未決事項一覧

・変更提案書、変更管理表、追加作業一覧表

(3)コミュニケーションの記録

・重要なやり取りを含む電子メール

・チケットシステムやチャットツールのログ（仕様確認や指摘対応のスレッドなど）

(4)品質・検収に関する資料

・テスト計画書、テスト仕様書、テスト結果報告

・不具合管理表（バグ票）、対応履歴

・検収依頼書（兼納品書）、検査合格書、業務終了報告書、業務終了確認書

(5)ソースコード・ログ等の技術資料

・ソースコードリポジトリのコミット履歴

・リリースノート、バージョン管理表

・障害発生時のログ、監視記録、障害対応記録

これらの資料は、トラブルが起きてから慌てて作成するものではなく、平常時からフォーマットと保存ルールを決め、プロジェクトごとに確実に残していくことが重要です。

どの文書を誰が作成・承認し、どこに保管するのかを社内ルールで定めておくことで、紛争予防と有事の「防御」の両方に役立つ体制を整えることができます。

「完成」トラブルに悩むベンダが弁護士に相談・依頼するメリット 

システムの「完成」をめぐるトラブルは、契約書の言い回しだけでなく、要件定義の進め方や仕様変更の履歴、検収のやり方など、現場の事情と結び付いています。

自社だけで判断しようとすると、感情的な対立になりやすく、対応が長期化しやすいことから、是非弁護士にご相談ください。

なお、弁護士に相談することで得られるメリットは次の通りです。

 

①自社の立場とリスクを冷静に整理できること 弁護士に相談することで、 ・ユーザ（注文者）の主張が法律上どこまで認められうるか ・自社の説明や資料がどの程度有利に働きうるか ・和解、交渉、訴訟など、現実的な選択肢が何か を第三者の目で整理できます。 これにより、「応じるべきか、争うべきか」「どこまで譲るか」といった判断を、感情論ではなく見通しに基づいて行いやすくなります。 ②交渉の筋と説明の仕方を整えられること 完成トラブルでは、 ・どこまでが当初の合意範囲か ・どこからが追加要望か ・どこまでを無償対応とし、どこからを有償とするか という線引きが重要になります。 弁護士は、契約書や仕様書、議事録、メールを踏まえて、「この順番で説明した方がよい」「ここは曖昧なのでこう整理しておきたい」といった形で、交渉のストーリー作りを手伝います。担当者ごとに説明がぶれないようにできる点もメリットです。 ③今後の契約書・運用改善につなげられること 一度完成トラブルが起きた案件について相談・依頼すると、 ・どの条項や運用に弱点があったのか ・標準契約書をどう直すべきか ・要件定義・仕様変更・検収のフローをどう見直すか といった点についてもフィードバックを受けられます。 その結果、個別案件の「火消し」にとどまらず、今後のプロジェクト全体のリスクを下げることができます。

 

リーガルブレスD法律事務所によるサポート内容 

リーガルブレスD法律事務所は、IT企業・インターネットビジネスを主な対象とする法律事務所として、システム開発・クラウド・プラットフォーム・SESなどIT取引に特化したサポートを行っています。年間100本以上のIT契約書作成・審査と、通算200社以上の顧問実績を有しており、現場の実務と契約実務の両方に精通している点が特徴です。

とくにベンダ向けには、

・システム開発、保守、SaaS等の契約書の作成・チェック

・「完成」トラブルや検収拒否、未払い等に関する交渉、訴訟対応

・みなし検収条項、変更管理フロー、仕様書の整備といった紛争予防の設計

など、契約から紛争対応まで一連の流れを見据えたサポートが可能です。

ご相談は、スポットでの単発相談のほか、継続的な顧問契約にも対応しており、日本全国からのご相談（オンライン面談を含む）を受け付けています。

「自社の契約書や運用で本当に守り切れるのか不安がある」「すでにトラブルになりつつあり、どこまで争うべきか悩んでいる」といった場合には、お電話またはお問い合わせフォームから一度ご相談いただくことで、具体的な選択肢やリスクを整理していただけます。

(1)法律相談サービス

リーガルブレスD法律事務所では、これまでにお取引のない事業者様からのご相談を積極的に受け入れています。

早めのご相談であればあるほど、ダメージの少ない解決策をご提案することが可能です。

 

ご相談内容例	・ユーザ（注文者）から「完成していない」「品質が低い」と言われ検収を拒否されており、どのように対応すべきか相談したい ・App Store や各種クラウド審査が通らないことを理由にユーザ（注文者）が報酬支払いを拒絶しているので、支払義務の有無や対応策について相談したい ・要件追加や仕様変更が繰り返され、いつまでも「完成」と認めてもらえない上に追加費用の請求にも応じてもらえないため、今後の進め方と清算方法について相談したい
サポート内容例	・検収拒否や報酬未払いの案件について、契約書、仕様書、メール等を踏まえて法的な見通しをご説明の上、交渉方針をご提案します ・ストア審査を理由とする支払拒否について、契約上の義務範囲と審査経過を整理し、追加対応の要否や費用負担の線引きを含めた現実的な解決案をご提案します ・要件追加や終わらない開発の案件について、仕様変更の経緯を整理しつつ途中精算や追加請求、打切り等の選択肢などをご提案します
相談者が得られるメリット	・自社の立場とリスクが客観的に整理され、「どこまで争うか」「どこで折り合うか」の判断材料が明確になります ・ユーザ（注文者）への説明や交渉の筋が整い、担当者ごとに対応がぶれることを防ぎつつ、感情的な対立を避けやすくなります ・目の前の案件だけでなく、標準契約書や社内フローの改善ポイントが見えてきて、将来の同種トラブルの発生可能性を下げられます ・万が一、訴訟や調停に進んだ場合でも、事情を把握した弁護士にそのまま対応を任せることができ、経営者や担当者の負担を軽減できます
弁護士費用	1回90分以内で15,000円（税別）
実施方法	①ご予約（お問い合わせフォーム又はお電話にて日程調整） ②事前準備（関係資料を共有いただきます） ③相談実施（オンライン又は対面） ④解決策提示（リスク診断、交渉方針などを具体的にご提示） ⑤アフターフォロー（別途契約の上、交渉代理や訴訟対応、継続支援へ移行）

 

お問い合わせはこちら

(2)その他サービス（法律相談以外のサービス）

リーガルブレスD法律事務所では、法律相談サービス以外にも様々なサービスをご提供しています。

ここでは、ユーザ（注文者）との交渉代理・バックアップサービスをご案内します。

■ユーザ（注文者）との交渉代理・バックアップサービス

ご依頼内容例	・ユーザ（注文者）から検収、支払を拒否されており、今後の交渉を弁護士に任せて、社内の負担を減らしたい ・取引継続は維持したいが、「今回だけの値引き」や「無償対応の範囲」について条件整理をしたうえで、相手方と冷静に交渉したい ・まずは自社がフロントに立ちつつ、メール文案や議事録案を弁護士にチェックしてもらい、交渉の裏方サポートを受けたい
サポート内容例	・検収拒否、支払拒絶が生じている案件について、弁護士が窓口となって相手方と直接交渉を行い、検収・支払条件や今後の対応範囲について合意形成を図ります ・取引関係を維持することを前提に、無償対応の上限、追加費用の取り扱い、スケジュール調整などの条件を整理し、ベンダの事業継続とリスク低減のバランスを踏まえた交渉支援を行います ・ベンダが自ら交渉窓口となる場合でも、弁護士がメール、議事録、提案書等の文案を事前にチェックし、発言内容や譲歩ラインについて助言することで、裏方として交渉を継続的にサポートします
依頼者が得られるメリット	・感情的なやり取りになりがちな局面でも、法的観点を踏まえた冷静な交渉ができるようになり、担当者の精神的・時間的負担を大きく減らせます ・「どこまで譲るか」「どこから譲らないか」という社内方針を事前に整理したうえで交渉に臨めるため、場当たり的な回答や社内でのブレを防ぎやすくなります。 ・交渉の過程で整理した資料や条件が、その後の合意書の作成や、万が一の訴訟対応にもそのまま活かせるため、次のステップへの移行もスムーズになります
弁護士費用	30万円（税別）～ ※緊急度、難易度、ボリュームなどを考慮して見積書をご提示します
実施方法	①オンラインヒアリング（30分程度）を実施し、課題の抽出とご要望事項を確認します ②実施計画案とお見積りを提示します ③ご依頼者様にて検証して頂き、ご要望を踏まえて実施計画を確定させます ④実施計画に沿って、順次作業を進めていきます

 

お問い合わせはこちら

(3)AIで生成したアドバイスを安全に使うためのサポートメニュー 

様々な事情で今すぐ弁護士に相談・依頼はできないが、AIを使った社内方針に間違いがないか判断してほしい方向けのサービスとなります。

 

まずは「合っているかだけ知りたい」事業者向け	【AI法務ジャッジ（無料スクリーニングβ版）】   ・ChatGPTやGoogle Geminiなどに聞いてみたものの、「本当に合っているのかどうかだけでも知りたい」という場合には、リーガルブレスD法律事務所の「AI法務ジャッジ（無料スクリーニングβ版）」をご利用いただけます。 ・質問内容とAIの回答内容をフォームから送っていただくと、担当弁護士が「○（おおむね妥当）」「×（誤りを含む）」「判定不能」のいずれかをお返しします（1日1件まで無料）。理由や修正文は省略し、正誤の判断に絞ったサービスです。 ・「まずはAIの答えが危険そうかどうかだけでも知りたい」「AIで作った契約書を使う前に、ざっくりとチェックしたい」という方に向いたサービスです。   お申込みはこちらから AI法務ジャッジ（無料スクリーニングβ版）
内容の理由や修正案まで知りたい事業者向け	【AI法務ジャッジ（ライトレビューβ版）】   ・AIの回答を現場実務でそのまま使う前に「どこがどう問題なのか」「どう直せばよいのか」まで知りたい場合には、「AI法務ジャッジ（ライトレビューβ版）」をご利用いただけます。 ・弁護士が回答内容を確認し、「誤っている理由」「修正した方がよいポイント（条項案の方向性）」「想定されるリスクや注意点」をA4×1枚程度のレポートにまとめてお送りします（5,500円～）。 AIの案をたたき台として活かしながら、「最低限ここだけは直しておきたい」というポイントを短時間で押さえたい事業者の方に向いたサービスです。   お申込みはこちらから AI法務ジャッジ（ライトレビューβ版）
社内でのAI活用まで含めて整えたい事業者向け	【AI法務ジャッジ（継続支援プランβ版）】   ・生成AIを本格的に業務に取り入れていきたい企業・事業者の方には、「AI法務ジャッジ（継続支援プランβ版）」として、継続的な伴走支援サービスをご用意しています。 ・プランに応じて、「毎月数件までのAI回答・AI契約書のレビュー（レポート付き）」「メールやチャットでの質問対応」「月1回のZoomレビュー」「プロンプト（AIへの指示文）の添削や条文テンプレートの整備支援」などを組み合わせた形で、AI活用と契約実務の両方を継続的にサポートします。 ・「AIに相談することが増えてきたので、社内での使い方やチェックのルールを整えたい」「AIを使うたびに不安にならない体制をつくりたい」というニーズに応えるサービスです。   お申込みはこちらから AI法務ジャッジ（継続支援プランβ版）

 

総合的なお問い合わせはこちらまで

お問い合わせはこちら

(4)法律顧問プラン（顧問弁護士サービス）のご案内

リーガルブレスD法律事務所では、完成トラブルのみならず、ベンダの円滑な事業活動の妨げとなる様々な課題の解決支援と事前予防を目的とした、継続的な伴走支援サービスをご提供しています。

 

ご依頼内容例	・システム開発、保守、SaaS など、自社の標準契約書、基本契約、個別契約ひな形を継続的に見直し、アップデートしてほしい ・大口案件やリスクが高そうな案件について、要件定義、見積、提案段階から契約条件のリスクチェックと交渉戦略の助言を受けたい ・営業担当、PM、エンジニア向けに、「完成トラブルを防ぐための契約・仕様確認」について、日常的に相談できる窓口や定期的な勉強会を用意したい
サポート内容例	・IT、システム取引の最新動向や判例、ガイドラインを踏まえ、自社の標準契約書・基本契約書・個別契約書ひな形を定期的にブラッシュアップし、個別案件ごとの修正案も提示します ・重要案件ごとに提案書・契約書案を事前チェックし、交渉で必ず死守すべきポイントと譲歩可能なポイントを整理したうえで、具体的な条項案や説明の仕方を助言します ・営業、PM、開発担当者向けに、完成トラブルや検収拒否を防ぐための研修・勉強会を実施し、日常的な個別相談にも応じることで、「どこで線を引くか」「いつ弁護士に上げるか」を判断できる体制づくりを支援します
利用者が得られるメリット	・契約書やプロジェクト運用の「弱い部分」を平時から継続的に修正でき、完成トラブルや未払いトラブルの発生リスクを下げられます ・大きな案件ごとに毎回ゼロから悩むことなく、顧問弁護士と共通の基準と方針に沿って意思決定できるため、経営判断と現場判断のズレを減らせます ・現場担当者が「契約で守れるライン」と「ビジネスとして譲るライン」を理解しやすくなり、属人的な交渉ではなく組織として一貫した対応ができるようになります ・万が一、完成トラブルが発生しても、日頃から事情を把握している顧問弁護士がすぐに交渉・訴訟対応に入れるため、スピーディかつ負担の少ない対応が期待できます
実施方法	①お問い合わせ、オンライン面談（ご要望事項、プランの説明） ②顧問契約の締結 ③窓口の開設（専用メール、チャットの提供） ④日常的な対応（契約書レビュー、相談に即応（即日～数日以内対応可）） ⑤ミーティング（必要に応じて経営課題、法務リスクを総点検） ⑥追加支援（必要に応じて交渉代理、訴訟対応、研修実施などを提供）

お問い合わせはこちら

下記のフォームを入力してください。

＜2025年12月執筆＞

※上記記載事項は弁護士湯原伸一の個人的見解をまとめたものです。今後の社会事情の変動や裁判所の判断などにより適宜見解を変更する場合がありますのでご注意下さい。