Skip to Content
Docs08. コーディングエージェント顧客・プロジェクトへの導入合意形成
中級se-practiceclient-adoptioncontract更新: 2026-09-10この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

顧客・プロジェクトへの導入合意形成

この記事の目的

顧客のプロジェクトで AI コーディングエージェントコードベースを読み、ファイルを編集し、コマンドを実行して検証するループで開発タスクを遂行する Agent。コード補完と異なり「タスク単位の委任」を受けられる。を使うための合意形成を設計できるようになります。誰の合意が必要か・何を示すか、契約上の論点(品質責任・知的財産・データ取り扱い)、見積りへの影響の考え方、そして「小さく始める」導入の型を持ち帰れる状態を目指します。自社チームへの展開(チーム導入とレビュー体制)とは別に、顧客・商流の側でどう合意を取るかに焦点を当てます。

対象読者

  • 受託開発で、顧客のプロジェクトに AI コーディングエージェントを持ち込みたい SE・プロジェクトリーダー
  • 元請・顧客・自社の間で、AI 活用の可否と条件を調整する立場のマネージャー

前提知識

本文

概要: 合意形成は「誰に・何を・どの順で」

顧客プロジェクトでの AI 活用は、技術判断の前に合意形成が要ります。本記事は「誰の合意が必要か」「何を示すか」「どの順で広げるか」を扱います。自社内の展開・レビュー体制は チーム導入とレビュー体制 が、データ経路・提供形態の技術面は 企業システム環境の制約と対応 が正本です。

誰の合意が要るか、何を示すか

多重請負・多社協業の商流では、合意すべき相手が複数います。誰の承認が要るかを最初に棚卸しします。

相手主な関心示すべきもの
顧客(発注者)自社資産・データの安全、成果物品質データの扱い・品質担保の方法・責任分界
元請 / 上位ベンダー契約条件との整合、再委託の可否契約・規程への適合、承認範囲
自社(法務・情報システム)契約リスク・秘密保持・ツール承認提供形態・データ経路・監査対応
監査 / 品質保証部門証跡・プロセス準拠成果物の検証プロセス・記録

要点は、「使ってよいか」を判断する人が複数いることです。顧客の現場担当が了承しても、顧客の情報システム部門・自社法務が承認していなければ進められません。承認の抜けは後で最も高くつきます。

契約観点

AI 活用は契約条件に触れます。契約は法務の領分ですが、SE として論点を挙げて法務につなぐことはできます(契約文言の作成は本記事の範囲外)。

  • 成果物の品質責任: AI の利用だけを理由に既存の品質確認を省略しません。受託者・発注者・ツール提供者の責任分担は、契約類型・合意条項・適用法に基づいて法務と確認します。検証プロセスと不具合発生時の対応範囲も合意に含めます
  • 知的財産(IP): 生成物の権利帰属・第三者権利の非侵害をどう扱うか。既存契約の IP 条項と、使うツールの生成物に関する規約の整合を確認します
  • データの取り扱い: 顧客データ・ソースコードをツールに渡す場合、契約のデータ取り扱い条項・秘密保持条項に反しないか。ここは 企業システム環境の制約と対応 の提供形態・経路の判断と直結します
  • 規制産業では入口を確認: 金融・医療など規制の強い領域では、業界固有の要請が加わります(規制の地図は 業界別規制マップ)

見積り・工数モデルへの影響

効率化は、見積り・単価の議論に波及します。ここは立場で利害が分かれるため、結論を出さず論点を整理します。

  • 効率化を単価にどう反映するか: 工数削減を値下げに反映するのか、付加価値として維持するのか。人月商売との相性など、論点は多く、正解は契約形態・関係性で変わります
  • 品質・責任は減らない: 実装が速くなっても、レビュー・検証・品質責任はむしろ相対的に重くなります。「速くなったぶん安く・短く」が単純に成り立たないことを、見積りの前提として共有します
  • 本記事は観点の提示まで: 具体的な価格戦略・工数モデルは各社・各案件の経営判断です。効果測定の考え方は ROI とビジネスケースの作り方 を SE 文脈に当てはめます

小さく始める型

いきなり顧客の本番案件へ全面適用するのは、合意・リスクの両面で無理があります。段階的に広げるのが定石です。

  1. 社内検証: まず顧客に依存しない社内題材で、効果とリスクを測る。ツールの提供形態・データ経路も社内で確立する
  2. 顧客非依存と確認できた題材から: 契約・機密区分・内容を確認し、顧客情報を含まない自社共通資産や公開題材を選ぶ。自社が書いたコードでも顧客案件の契約・秘密保持の対象になり得るため、この段階で必要な社内・契約上の承認も先に得る
  3. 顧客合意のうえ本適用: データの扱い・品質担保・責任分界を合意し、承認を得たうえで、顧客資産に関わる作業へ広げる

各段階で効果を測って示すことで、次の段階の合意が取りやすくなります。飛び級して顧客資産にいきなり適用すると、1 件のインシデントで全体の信頼を失います。

効果の示し方

合意を前に進めるには、効果を測って示すことが要ります。

  • 体感でなく指標で: 「速くなった」ではなく、対象作業の工数・品質(手戻り・欠陥)・レビュー負荷の変化を測ります(ROI とビジネスケースの作り方の考え方)
  • リスクとセットで示す: 効果だけでなく、データの扱い・品質担保・失敗時の対応を併せて示すと、顧客・法務の合意が得やすくなります
  • 小さな実績を積む: 社内検証・顧客非依存作業での実績が、顧客合意の説得材料になります。最初の合意は小さく、実績で広げます

実務での注意点

アンチパターン

  • 顧客の現場担当の口頭了承だけで進める → 顧客情報システム部門・自社法務の未承認が後で発覚し、中断・信頼喪失になる → 承認が要る相手を棚卸しし、書面で合意を取る
  • 「AI が作った」だけで免責されると判断する → 契約上の責任分担を確認せず、必要な品質確認を省く → 契約・適用法を法務と確認し、検証プロセスと対応範囲を合意する
  • 効率化を単純に値下げ・短納期に直結させる → レビュー・品質責任の増加を見落とし、赤字・品質低下を招く → 品質責任は減らない前提で見積りを組む
  • 顧客資産にいきなり全面適用する → 1 件のインシデントで全体の信頼を失う → 社内 → 顧客非依存 → 顧客合意の段階で広げる
  • 効果を体感で主張する → 顧客・法務を説得できず合意が進まない → 工数・品質・レビュー負荷を測って示す

チェックリスト

  • 承認が必要な相手(顧客・元請・自社法務/情シス・監査)を棚卸しした
  • 成果物の品質責任・知的財産・データ取り扱いの契約論点を法務につないだ
  • 効率化と品質責任の関係を、見積りの前提として顧客・自社で共有した
  • 社内検証 → 顧客非依存作業 → 顧客合意のうえ本適用、の段階を設計した
  • 各段階で効果(工数・品質・レビュー負荷)を測って示している
  • データの扱い・経路の合意を 企業システム環境の制約と対応 に沿って取った

関連トピック

参考資料

TODO・未確認事項

なし

企業システム環境の制約と対応(閉域網・監査・持ち込み承認)セクション概要