AI開発を頼むときの役割分担の決め方 — データ準備・検証・運用のどこを自社が持つか

AIを使った仕組みの開発を依頼したところ、作業が始まってから「これはどちらの仕事なのか」という問いが次々と出てくる—— この形でつまずくご相談は少なくありません。データを出すのは自社でよいとして、 中身が古いかどうかは誰が見るのか。出てきた結果が合っているかは誰が判定するのか。 動き始めたあとに様子がおかしいとき、最初に気づくのはどちらなのか。 どれも作業が始まる前には話題にならず、始まってから一つずつ浮かび上がります。

これは誰かの怠りではなく、AIを使う開発では発注側の作業が通常の開発より多く残るという構造から来ています。仕様どおりに作って引き渡す形と違い、データを用意する人・出来を判定する人・ 動かし続けるかを決める人が必要になるためです。この記事では、AI活用と受託開発を手がけるCoconutWorksが、 役割分担をデータの用意・出来の確かめ・動かし続けること・社内の説明と承認の4つの領域に分けて、 どこまでを委託でき、どこからが自社に残るのかを整理します。費用の数字は扱わず、 発注前に決めておく中身の話に絞ります。発注前に押さえたい観点の全体像はAI開発を外注する前に押さえることで扱っているので、ここでは「作業と判断をどちらが持つか」という一点に絞って掘り下げます。

結論: 4つの領域で「作業」と「判断」を分ける

表の形で見ていただきたいのは、作業は委託できても判断は残るという並びです。 丸ごと任せるか自社で持つかの二択で考えると、どの領域も「任せたつもりだったのに手間がかかった」という感想になります。 作業と判断を別のものとして扱い、作業は頼み、判断は誰が下すのかを名前で決める。 この分け方にしておくと、話が進んだあとで出てくる問いにもその場で答えられます。以下、領域ごとに掘り下げます。

なぜAI開発では役割分担が曖昧になりやすいのか

通常のシステム開発では、何を作るかを決めて、作ったものが仕様どおりかを確かめて引き渡す、という流れが取れます。 仕様が判断の基準になるため、どちらの仕事かで迷う場面が比較的少ないわけです。 ところがAIを使う部分は、出てくる結果が入力によって変わるため、仕様書に「こうなる」と書き切れない部分が残ります。 書き切れないものは確認で埋めることになり、その確認を誰がどの目で行うのかという論点が生まれます。

もう一つの理由は、材料が発注側の手元にあることです。 業務の書類、過去のやりとり、担当者の頭の中にある判断の基準——AIに使わせるものはどれも社内にあり、 受託側は渡されたものしか見られません。渡す前の段階で「これは渡してよいのか」「これは最新なのか」という判断が入り、 その判断は業務を知っている人でなければ下せません。つまり、作業の順番の上流に発注側の判断が挟まる構造になっています。

この2つが重なると、見積もりの段階では見えていなかった作業が後から現れます。 よくある流れとしては、受託側が「データをご用意ください」と伝え、発注側が社内のファイルをまとめて渡し、 作業が進んだところで古い情報が混じっていることが分かって作り直しになる、というものです。 どちらも約束を破っていないのに手戻りが出るのは、 渡す・受け取るという言葉の中に中身の判断が含まれていなかったためです。 分担を決めるというのは、この言葉の中に隠れている作業を表に出すことだと考えてください。

データの用意 — 作業は頼めても、中身の判断は残る

集める・形をそろえる・保管する場所を用意するといった作業は、委託できる範囲です。 紙の書類を読み取れる形にする、ばらばらの表記をそろえる、置き場所を一か所にまとめる。 こうした手を動かす部分は受託側のほうが速く進められることが多く、頼んでしまったほうが早いところです。

一方で残るのが、中身が業務として正しいかの判断です。 価格表が2つ出てきたときにどちらが現行なのか、見積書のひな形が改訂されているのか、 特定の取引先だけ別の扱いになっているのか。これらは社内の事情であって、 渡されたファイルを見ているだけでは分かりません。判断を仰ぐ相手が決まっていないと、 受託側はその場で推測して進めるしかなくなり、推測が外れた分が後で手戻りになります。

実務での進め方としては、データを渡す前に「中身の質問に答える人」を一人決めておくのが効きます。 全部を事前に点検する必要はなく、作業の途中で出てくる質問に数日のうちに答えられる体制があれば足ります。 また、見せてよい情報の範囲も発注側でしか決められません。 どこまで渡せるかの整理は社内データをAIに使わせる前に整えることで扱っているので、あわせてご覧ください。

出来の確かめ — 技術の目と業務の目を分ける

出てきた結果が使えるかどうかを確かめる工程は、受託側と発注側の両方に仕事があります。 混ざりやすいので分けて考えると、受託側は技術の目で、 想定した動きをしているか・入力が崩れたときに壊れないかを見ます。 発注側は業務の目で、出てきたものを次の工程にそのまま渡せるかを見ます。 この2つを一方に寄せると、どちらかの観点が抜け落ちます。

業務の目で見るというのは、専門的な評価をすることではありません。 たとえば書類の内容を読み取らせる仕組みなら、出てきた結果を受け取った担当者が そのまま次の処理に回せるか、直すとしたらどこを何件直すのかを見る、という程度です。 見る人は、できればその作業を普段している担当者が望ましいところです。

つまずきやすいのは、判定の基準を先に決めていない場合です。 基準がないと、同じ結果を見ても人によって結論が変わり、結局「もう少し様子を見よう」で止まります。 何が分かれば進める・やめると言えるのかを先に置いておく考え方はAIの試用（PoC）で止まらないための出口条件で整理しています。分担の話としては、基準を作るのは発注側の仕事という点を押さえておいてください。

動かし続けること — 誰が気づき、誰が決めるのか

引き渡しが済んだあとの領域です。監視する・不具合に対応する・設定を変える作業は委託できますが、変えてよいかの判断と、続ける・広げる・やめるの決定は発注側に残ります。 作業を頼んでいても、業務の都合で基準が変わるときに動くのは自社だからです。

AIを使う部分で特に注意したいのは、壊れていなくても結果が変わりうることです。 扱う書類の様式が変わった、取り扱う商品が増えた、現場の言い回しが変わった—— こうした変化で出てくる結果の傾向がずれることがあります。 動かなくなるのであれば気づけますが、動いてはいるのに結果だけがずれる形は見つけにくいところです。 だからこそ、誰がどの頻度で見るのかを引き渡しの時点から決めておく必要があります。 保守の取り決めの考え方はシステムの保守契約で確認すべきことで扱っています。

進め方としては、見る項目を多くしないことをおすすめします。 使われている回数、手直しが入った件数、現場から上がった不満の有無——この程度で十分です。 項目が多いと集めること自体が続かず、集まらなくなった時点で誰も見ていない状態に戻ります。 また、変えてよいかを判断する人は、出来の確かめで業務の目を担当した人と同じにしておくと、 基準が引き継がれて判断がぶれにくくなります。

社内の説明と承認 — 外からは代行できない部分

4つの領域のうち、委託できる幅が最も狭いのがここです。 説明資料の下書きや、仕組みの説明の場への同席は頼めます。 しかし、関係部署への根回しと承認の取り付けは社内の人でなければ進みません。 ここが抜けていると、出来上がったあとに別部署から反対が出て、使われないまま置かれることになります。

起こりやすい場面を挙げると、業務の一部をAIに任せる仕組みを作ったところ、 その業務を担当している部署が「確認の手間が増えるだけだ」と受け取る、というものがあります。 反対の理由が納得できるものである場合も多く、作る前に話を聞いていれば設計が変わっていた、 ということも起きます。社内の調整は、出来上がってから始めるのではなくデータを渡す前の段階で一度通しておくほうが手戻りが小さく済みます。

もう一つ、発注側に残る作業として見落とされやすいのが、 自社の担当者の時間を業務として確保しておくことです。 データの質問に答える、出てきた結果を見る、社内に説明する——これらはどれも時間を使いますが、 見積書には出てきません。手すきの時間で回そうとすると、確認の順番待ちで進みが落ちます。 分担を決めるときに、自社側の作業も一覧に書き出しておくと、 社内で必要な時間を説明しやすくなります。

契約や発注書で曖昧になりやすい書き方

ここまでの話は、書面に落ちていなければ口約束で終わります。 とはいえ、分担をめぐる食い違いは悪意から起きるものではなく、 どちらも自然に読める言葉が入っていることから起きます。よく出てくる書き方を並べます。

右側の列はいずれも、作業の主体と、判断する人、回数や頻度を加えているだけです。 難しい条文を書く必要はなく、打ち合わせの議事録に同じ粒度で書いて相手に確認してもらう形でも効きます。 むしろ、見積もりを依頼する段階で自社側の想定を書いて渡しておくほうが、 各社の回答がそろって比較しやすくなります。見積依頼の形は見積金額が会社ごとにバラつくときの揃え方で扱っているので、そちらもご覧ください。

迷ったときのチェックポイントと、決めていく順序

依頼を決める前に、次の5点に答えられるか確かめてみてください。 詰まった項目が、作業が始まったあとに「これはどちらの仕事か」として出てくる場所です。

• ①データの中身の質問に答える人が決まっているか — 名前で決まっているか、部署名で止まっていないか。
• ②出来を業務の目で見る人が決まっているか — 導入を進める人と、普段その作業をしている人の両方を入れられるか。
• ③進める・やめるの基準を自社で書けているか — 受託側の提案待ちになっていないか。
• ④引き渡し後に見る人と頻度が決まっているか — 別契約として先送りになっていないか。
• ⑤自社側の作業と必要な時間を書き出せているか — 社内に説明できる形になっているか。

決めていく順序としては、①対象の業務を一つに絞る → ②その業務について自社で判断する人を一人決める → ③4つの領域それぞれで「作業は頼む／判断は自社」の線を引く → ④自社側の作業を一覧にして時間を確保する → ⑤その内容を添えて見積もりを依頼する → ⑥届いた回答で前提のずれを確認して書面に残すという流れが無理がありません。 ②を先に置いているのは、人が決まっていないと③以降がどれも「後で決める」に流れるためです。

役割分担を決めると自社の負担が増えるように見えますが、実際には逆方向に働くことが多いところです。 線を引いていない部分は、どちらかが推測で進めることになり、推測が外れた分が手戻りとして返ってきます。 先に決めておけば、頼める部分は迷わず頼めます。 どこまで依頼できるかの全体像はAI開発を外注する前に押さえることで整理しています。

よくある誤解と、起きやすい失敗

「丸ごと任せられる会社を選べば分担を決める必要はない」 — 作業の大半を引き受ける会社はありますが、 データの中身が業務として正しいかの判断と、社内の承認はどこに頼んでも残ります。 丸ごと任せたつもりで進めると、その2つが誰の仕事でもない状態になり、 結果として判断待ちで止まります。任せる幅が広い場合こそ、残る判断を先に名前で決めておくほうが動きます。

「社内に詳しい人がいないから分担は決められない」 — 決めるのに必要なのは技術の知識ではなく、 対象の業務を知っていることと社内で話を通せることです。 技術的な判断は受託側に寄せてよく、発注側が担うのは業務の目での確認と社内の調整です。 詳しい人を採るまで待つ、という進め方にすると、待っている間に話が流れてしまいがちです。

「分担を細かく決めると融通が利かなくなる」 — 決めるのは作業の手順ではなく、 誰が判断するかという点です。判断する人が決まっていれば、途中で状況が変わったときにもその場で決められます。 逆に決まっていない状態は、融通が利くというより決められない状態に近く、持ち帰りが増えて進みが落ちます。

「運用の分担は動き出してから考えればよい」 — 引き渡しの前後は関係者の関心が高い時期で、 決めるのに最も適したタイミングです。動き出したあとは日々の業務が戻ってくるため、 見る人を決める話が後回しになり、気づいたときには誰も見ていない期間ができています。 引き渡しの条件として、見る人と頻度を一緒に決めておくほうが確実です。

よくある質問

まとめ

AI開発の役割分担は、丸ごと任せるか自社で持つかではなく、作業は頼み、判断は誰が下すか決めるという分け方で整理できます。 データの用意では中身が業務として正しいかの判断が残り、出来の確かめでは業務の目での判定が残ります。 動かし続ける部分では変えてよいかの決定が残り、社内の説明と承認は外から代わることができません。 この4つについて判断する人を名前で決め、自社側の作業を一覧にしてから見積もりを依頼すると、 各社の回答がそろい、始まったあとの手戻りも小さくなります。 依頼の範囲や分担のご相談はAI導入支援サービスのページから承っています。相談・お見積もりは無料です。