結論

AI開発プロジェクトの品質は、会社ではなく担当チームの数名に依存します。提案時のエースが受注後に別案件へ移る「バイトアンドスイッチ」や、開発途中でのML エンジニア離任は、スケジュール遅延と暗黙知の消失を直接引き起こします。対策は、契約でキー要員を氏名指定し、交代時の事前通知期間(30日以上)、後任候補への発注側の承認権、引き継ぎ完了の確認手続きの3点をセットで定めることです。ただし準委任契約での要員指定には指揮命令との線引きがあるため、書き方には注意が必要です。

キー要員条項とは何か

キー要員条項とは、プロジェクトの成否に重要な役割(PM、リードエンジニア、MLエンジニア、データサイエンティストなど)について、契約別紙に担当者を特定し、その交代に手続きを課す条項のことです。全員を縛るのではなく、代替が難しい2-4名に絞るのが実務です。

注意すべきは、準委任・請負のいずれでも、発注者がベンダーの労働者を直接指揮命令すると偽装請負(労働者派遣法違反)のリスクが生じることです。そのため条項は「特定個人を働かせる義務」ではなく、「体制変更時の通知・協議・承認の手続き」として書きます。厚生労働省の労働者派遣・請負区分基準では、業務遂行方法の指示を発注者が行わないことが請負の要件とされており、要員条項もこの範囲で設計します。

契約に入れる4点セット

あわせて、提案時の体制図に載っていた人物が着任しない場合の扱い(受注後の初回体制確認で相違があれば協議、悪質な場合は解除事由)も入れておくと、バイトアンドスイッチへの抑止になります。退職など真にやむを得ない交代を止めることはできないため、条項の目的は交代の禁止ではなく、交代コストをベンダー側に適切に負担させることに置きます。

後任承認の実務: 何を確認するか

後任候補の承認では、スキルシートの経歴だけでなく、本件固有の技術要素との適合を確認します。RAG構成なら検索基盤とプロンプト設計の実務経験、画像認識ならアノテーション運用の経験、というように案件の中核技術で1時間程度の技術面談を行います。面談で確認した内容は承認記録として残し、後日「承認したから品質責任は発注側にある」と言われないよう、承認は「拒否権の不行使」であり成果責任はベンダーに残る旨を条項に明記してください。

引き継ぎ完了の判定と証跡

要員交代で実際に品質が落ちるのは、引き継ぎが「ドキュメント渡して1回説明会」で終わるときです。引き継ぎ完了の判定条件を次のように決めます。

引き継ぎ期間中の費用は原則ベンダー負担です。交代がベンダー都合である以上、並走期間の2名分工数を発注側に請求する見積は拒否して構いません。この点も契約に書いておくと交渉が不要になります。

頻繁な交代はベンダー選定へのシグナル

半年で同じ役割が2回交代するようなら、個別対処より体制全体を疑うべきです。ベンダーの離職率や下請け構造(実作業が再委託先で行われていないか)を確認し、再委託先の要員も含めて体制図の開示を求めてください。月次報告に体制変更の予定を必須項目として入れておくと、交代の予兆を早期に掴めます。交代履歴は台帳化し、契約更新時の評価材料と、次回発注時のベンダー比較材料に使います。

実務チェックリスト

• キー要員2-4名を役割と氏名で契約別紙に特定したか
• 提案時体制図と着任者の一致を初回定例で確認したか
• 交代の30日前通知と後任承認権を契約に入れたか
• 承認は拒否権であり成果責任はベンダーに残る旨を明記したか
• 引き継ぎ完了の判定条件と並走期間を決めたか
• 並走期間の費用負担がベンダー側であることを合意したか
• 再委託先を含む体制図の開示と変更予告を月次報告に入れたか
• 指揮命令にあたる直接指示をしていないか運用を点検したか

図解で確認するポイント

この記事の画像は、プロジェクト体制の中で担当が交代する際に、通知・確認・承認のステップを経て新しい担当が組み込まれる流れを文字なしで図解しています。交代が無秩序に起きるのではなく、関門を通る構造を示しています。

AllAI内での次の行動

ベンダー選定段階での体制確認はベンダー面談の質問集と提案書の危険信号ガイドが参考になります。交代が続く場合の乗り換え判断はベンダー切替ガイドへ進んでください。これから発注する場合はAI発注診断で体制要件を整理し、AI開発パートナーで開発体制を比較できます。

FAQ

Q. キー要員の氏名指定は準委任契約でも有効ですか? A. 通知・協議・承認の手続き条項として書けば有効です。ただし特定個人の労働を直接義務づける書き方や、日々の作業指示を発注者が行う運用は偽装請負リスクがあるため、手続きと成果責任の枠内に収めてください。

Q. ベンダーが「人の指定は受けられない」と拒否したら? A. 全面拒否なら、せめて交代時の事前通知と引き継ぎ完了確認の2点は譲らないでください。それも拒否する場合、属人性の高いAI開発を任せる相手として体制リスクが大きいと評価すべきです。

Q. 交代後に品質が明らかに落ちた場合、何を主張できますか? A. 準委任なら善管注意義務、請負なら契約不適合の枠組みで、引き継ぎ不備の是正(再引き継ぎ、増員、スケジュール調整)を要求します。交代前後の品質指標(レビュー指摘数、バグ密度、ベロシティ)を記録しておくと主張の根拠になります。

Q. 発注側の担当者が交代する場合も同じですか? A. 発注側の交代もプロジェクトリスクです。判断基準や経緯を台帳・議事録で残す本記事の運用は、発注側交代時の引き継ぎ資産にもなります。相互に交代時手続きを定める書き方にすると、ベンダーの合意も得やすくなります。

出典と確認日

• 厚生労働省「労働者派遣事業と請負により行われる事業との区分に関する基準」: https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/koyou_roudou/koyou/haken-shoukai/07.html (確認日: 2026-07-10)
• IPA「情報システム・モデル取引・契約書」: https://www.ipa.go.jp/digital/model/index.html (確認日: 2026-07-10)
• 経済産業省「AI・データの利用に関する契約ガイドライン」: https://www.meti.go.jp/press/2018/06/20180615001/20180615001.html (確認日: 2026-07-10)
• 公正取引委員会「下請法・中小受託取引適正化法」: https://www.jftc.go.jp/shitauke/index.html (確認日: 2026-07-10)