生成AI・RAGの案件|開発者・提供者・利用者の責任区分

📘 この記事でわかること
- 案件で最初に決まるのは自分がどの主体にあたるかということと、そこから対策の程度が変わってくる仕組み
- 既存システムへの生成AI組み込みがたいてい提供者側の仕事にあたることと、RAGが根拠をたどれる実装でもあること
- ガイドラインがLivingDocumentとして更新され続けることと、参照した版を記録に残す習慣の作り方
生成AIに関わる案件の情報を開くと、目に入るのは検索の仕組みや処理の方式ばかりです。実際の仕事で先に問われるのは、技術の選び方よりも、自分がどの立場で関わるのかということです。AI事業者ガイドラインは、対象者をAI開発者・AI提供者・AI利用者という3つの主体に大別しており1、立場が変わればできることも求められることも変わってきます。既存の業務システムに生成AIを組み込む仕事の輪郭は、この立場を起点にすると見えてきます。
1. 生成AIの案件で最初に決まるのは、立場である
生成AIを既存の業務システムに組み込む案件の情報を見比べていると、書かれている技術要素はどれも似通って見えます。けれど実際に現場へ入ってみると、求められる説明の重さがまったく違うことに気づきます。差を生んでいるのは技術の選定ではなく、自分がガイドライン上のどの主体に位置づけられるかという一点です。
AI事業者ガイドラインは、対象者をAI開発者・AI提供者・AI利用者という3つの主体に大別しています1。開発する側なのか、提供する側なのか、使う側なのかという立場の違いは、単なる呼び分けではありません。立場ごとに整理されている事項が異なるため、案件で担う役割が決まった瞬間に、確認する観点の中身も変わってきます。
技術の流行を追いかけることよりも、自分がこの3主体のどこに立つのかを先に押さえることのほうが、案件選びでは効きます。開発者としてモデルそのものを作り込む仕事と、提供者として既存の仕組みに組み込む仕事とでは、同じ生成AIの案件という言葉でも中身がまったく違うからです。
表で見る、3つの主体の違い
3つの主体を並べて見ると、案件でイメージしやすい仕事の形が見えてきます。同じ生成AIの案件という言葉であっても、開発者に近い仕事なのか、提供者に近い仕事なのか、利用者に近い仕事なのかによって、日々の作業も、必要になる経験も変わってきます。次の表は、ガイドラインでの位置づけと合わせて、3つの主体をそれぞれ整理したものです。
| 主体 | ガイドラインでの位置づけ | 案件でイメージしやすい仕事 |
|---|---|---|
| AI開発者 | 第3部 | モデルそのものを作り込み、学習や調整に関わる仕事 |
| AI提供者 | 第4部 | 既存の業務システムに組み込み、仕組みとして届ける仕事 |
| AI利用者 | 第5部 | 提供された仕組みを、日々の業務の中で使う仕事 |
開発者に関する事項は第3部、提供者に関する事項は第4部、利用者に関する事項は第5部に置かれています2。この並びを知っておくと、案件の情報を読むときにどの部を参照すればよいかの見当がつきます。
自分の経験は、どの主体に重なるか
データ基盤やアプリケーションの開発に関わってきた経験があるなら、重なりやすいのは提供者の立場です。モデルを一から作る仕事ではなく、既にある大規模言語モデルを、業務で使える形に組み込む仕事にあたることがたいていだからです。
提供者の立場だと分かれば、次に読むべき範囲もはっきりします。開発者向けの事項をすべて読み込む必要はなく、自分の役割に合った第4部から確認を始められます。この絞り込みだけでも、案件に向き合うときの見通しは変わってきます。
参画前の面談では、担当する範囲が第4部のどこにあたるのかを尋ねられる場面が増えています。ここで自分の経験を、第3部寄りなのか第4部寄りなのかで整理して答えられると、話が具体的に進みやすくなります。抽象的な得意分野ではなく、立場に沿った言葉で説明する準備をしておくとよいでしょう。
2. 組み込む仕事は、たいてい提供者側にあたる
既存の業務システムに生成AIを組み込む仕事は、開発・提供・利用という3つの部のうち、たいてい提供者側の仕事にあたります。モデルを新しく作るのではなく、既にある仕組みを土台にして、検索や問い合わせ対応といった機能を組み立てていく仕事だからです。
提供者の立場になると分かることは、開発者の事項をそのまま引き受ける必要がないという点です。とはいえ利用者に任せきりにしてよいわけでもありません。提供者には提供者なりに整理された事項があり2、そこを押さえることが仕事の輪郭になります。
案件の説明に「組み込み」「連携」「導入」といった言葉が並んでいたら、それは提供者の仕事を指していることがほとんどです。求められているのは新しい理論の理解よりも、既にある仕組みを業務に合わせて組み立てる設計の力になります。
案件の説明に「試作」から「本番での運用」へという言葉が並ぶときも、提供者としての仕事に重なることがほとんどです。試しに動かす段階から、日々の業務で使われる仕組みへと育てていく過程そのものが、既存システムへの組み込みにあたるからです。
3つの部の流れを図で押さえる
開発・提供・利用という3つの部は、上流から下流へと役割が渡っていく流れとしても読めます。次の図は、その流れの中で組み込みの仕事がどこに位置するかを示したものです。
出典:AI事業者ガイドライン(第1.1版)総務省をもとに作成
図にすると分かるとおり、組み込みの仕事は開発と利用の間に立つ仕事です。土台になる部分をどう作るかまでは踏み込まず、届いた仕組みをどう使うかにも留まらない、その中間の調整役にあたります。
調整役だからこそ、経験が活きる
提供者の立場は、右にも左にも配慮が要る調整役です。開発者が作った仕組みの特性を理解しつつ、利用者が業務で困らない形に整える役目を担います。データ基盤の設計やAPIの連携を経験してきたエンジニアであれば、この調整の感覚はすでに持っているものです。
モデルの中身を知り尽くすことよりも、業務の要件と仕組みの特性をつなぐ設計判断のほうが、この立場では重みを持ちます。ここで求められる経験は、目新しい技術の習得よりも、これまで積み上げてきたシステム連携の経験に近いものです。
提供者としての日々の進め方は、開発者としての進め方とは違います。モデルの内部を検証する時間よりも、既存のシステムとの接続部分を確認し、運用担当者や利用者からの問い合わせに応じて調整する時間のほうが長くなりがちです。この違いを知っておくと、参画後の仕事の見通しを立てやすくなります。
AI・LLMに関わるリモート案件の条件を確かめる →
3. どこまでやるかを決めるのが仕事になる
提供者の立場が決まったところで、次に問われるのは、どこまで対策するかということです。ガイドラインは、対策の程度をリスクの大きさに対応させるリスクベースアプローチを重要な考え方としています3。
一律にすべてを重くする発想ではありません。影響が大きい領域には手厚く、影響が限られる領域には身の丈に合った対応で応じる、という程度の調整そのものが仕事に組み込まれています。だからこそ、案件に入って最初にすることは、着手ではなく見立てになります。
手順どおりに手を動かすことよりも、この場面はどのくらいのリスクを持つ場面なのかを見立てることのほうが、提供者の仕事では先に来ます。見立てを誤ると、後の工程で対応の重さがちぐはぐになるからです。
案件の情報に「リスク評価」「影響範囲の整理」といった言葉が含まれているときは、対策の程度を見立てる仕事がすでに範囲に含まれているサインです。技術要素だけでなく、こうした言葉にも目を通しておくと、案件の実態をつかみやすくなります。
軽重をつける発想を図で確かめる
リスクの大きさと対策の重さを対応させるという考え方は、図にすると分かりやすくなります。次の図は、リスクの段階ごとに、どの程度の対応が想定されるかを整理したものです。
出典:AI事業者ガイドライン(第1.1版)総務省をもとに作成
図に示したとおり、リスクが小さい場面まで一律に重い手続きを課すわけではありません。これは提供者にとって、負担を減らせる考え方でもあります。どこまでやるかを自分で見立てて説明できることが、そのまま仕事の価値になります。
見立てを誤ったまま進めると、後になって対策の重さを見直す作業が発生し、スケジュールにも影響します。逆に、最初の見立てを丁寧に行い、その根拠を残しておけば、途中でクライアントと協議する場面でも説明がしやすくなります。
継続して回すサイクルという発想
対策は一度決めたら終わりではありません。ガイドラインは、環境・リスク分析、ゴール設定、システムデザイン、運用、評価という5つの段階を、継続的かつ高速に回すアジャイル・ガバナンスの実践を重要な考え方として示しています7。次の表は、この5段階を整理したものです。
| 段階 | 主な内容 |
|---|---|
| 環境・リスク分析 | 置かれている状況とリスクを把握する |
| ゴール設定 | 何を実現したいかを定める |
| システムデザイン | 定めたゴールを仕組みの設計に落とし込む |
| 運用 | 実際に動かし、状況を見続ける |
| 評価 | 結果を振り返り、次のサイクルにつなげる |
1周して終わりにしないという発想は、案件の座組みにもそのまま反映されます。作って納品して終わりではなく、運用と評価を含めて継続的に関わる座組みを前提にした案件が見られます。
4. RAGは、根拠をたどれるようにする実装でもある
既存システムへの組み込みで具体的な技術として名前が挙がりやすいのが、検索拡張生成という手法です。ガイドラインは、この手法の活用等により、ハルシネーションの抑制や出力過程・根拠の透明性向上等が期待されると述べています4。
検索対象の文書を根拠として参照させる仕組みは、単に回答の精度を上げるための工夫ではありません。どの文書を参照して、その回答に至ったのかを後からたどれるようにする実装でもあります。
回答の滑らかさよりも、根拠をたどれる設計のほうが、提供者としての仕事では評価されやすい部分です。参照元を残す設計は地味に見えますが、透明性とアカウンタビリティを果たすための土台になります。
根拠をたどれる設計を選んでおくと、後からクライアントに説明を求められた場面でも、参照した文書を示しながら答えられます。曖昧な回答で場を乗り切るのではなく、確認できる状態を用意しておくことが、提供者としての信頼につながります。
検証可能性と情報提供という2つの軸
各主体には、システムの検証可能性を確保しながら、ステークホルダーに適切な情報を提供することで透明性を向上させ、アカウンタビリティを果たすことが重要です5。作って終わりではなく、後から確かめられる状態にしておくことまでが仕事に含まれます。
とはいえ、持っている情報をすべて開示すればよいわけではありません。透明性の指針では、検証可能性を確保しながら、必要かつ技術的に可能な範囲で、合理的な範囲の情報提供をすることが重要です6。全部を明かす仕事ではなく、範囲を決める仕事です。
表で整理する、透明性を保つための取り組み
検証可能性の確保と、範囲を定めた情報提供、そして根拠をたどれる実装という3つの取り組みは、別々の作業に見えて、透明性とアカウンタビリティという一つの目的につながっています。提供者の立場でこの3つを仕事として引き受けるとき、それぞれが何を指しているのかを次の表に整理しました。
| 取り組み | 内容 |
|---|---|
| 検証可能性の確保 | システムの動きを後から検証できる状態にしておくこと |
| 範囲を定めた情報提供 | 必要かつ技術的に可能な範囲で、合理的な情報を届けること |
| 根拠をたどれる実装 | 検索対象の文書を参照させ、出力過程や根拠の透明性を高めること |
この3つを仕事として引き受けるのが、提供者の立場です。根拠をたどれる実装を選ぶことは、透明性を高めるための具体的な一手になります。
根拠をたどれる実装に関わる案件の条件を見る →
5. 版が動く領域なので、参照した版を残す
ここまで見てきた内容は、今この瞬間の版に基づくものです。ガイドラインはLiving Documentとして適宜更新を行うことが予定されています8。
つまり、この分野は一度読んで終わりにできる領域ではありません。参照した版がいつのものかを記録に残しておかないと、後から振り返ったときに、どの内容がどの版の話だったのか分からなくなります。
実際に令和7年度の更新内容には、AIエージェント、フィジカルAIに関する事項の追記が示されています9。関わる技術の幅が広がるにつれて、扱う事項も広がっていくことがうかがえます。
版の動きを図で確かめる
版が更新されていく様子を、時系列の図に整理しました。今回の更新内容だけでなく、更新が続いていく前提そのものを押さえておくことが大切です。
出典:総務省「AI事業者ガイドライン(第1.1版)」「AI事業者ガイドラインの令和7年度更新内容」をもとに作成
図の先に伸びる矢印は、これで更新が止まるわけではないことを示しています。今回の追記内容だけを覚えるのではなく、版を確かめる習慣そのものを身につけておくと、次の更新にも対応しやすくなります。
参照した版を残す、という仕事の作法
案件の資料や設計書に、参照したガイドラインの版と確認した日付を残しておくことは、地味ですが効果の大きい作法です。後から見返す人にとって、その判断がどの前提のもとで行われたのかが分かるようになります。
この作法を身につけておくと、版が更新されたときにも慌てずに済みます。何が変わったのかを、以前の版との差分として確認できるからです。継続的に関わる案件では、この積み重ねがそのまま信頼につながります。
継続的に関わる案件では、次の打ち合わせで「この判断はどの版に基づいていますか」と尋ねられる場面も出てきます。そのときに版と日付をすぐに示せるかどうかで、積み重ねてきた仕事の見え方が変わってきます。
6. まとめ
ここまで、生成AIの案件で最初に決まるのは立場であること、組み込む仕事はたいてい提供者側にあたること、対策の程度を見立てることが仕事になること、RAGが根拠をたどれる実装でもあること、そして版が動く領域だからこそ参照した版を残す必要があることを見てきました。
最後に、立場を確かめてから次の一歩に進むまでの流れを、図に整理しました。
図の作成:Remogu編集部。ここまでの内容を整理したもので、統計データではありません
提供者としての仕事は、既存の仕組みと日々向き合う仕事であり、常駐が前提になりにくい性質を持っています。Remoguでは、案件の90%以上がフルリモート可能です10。場所に縛られずに、この立場の仕事を続けていく選択肢は、思っている以上に近くにあります。
まずは自分の経験がどの立場に重なるのかを、Remoguに並ぶ案件の条件と照らし合わせてみるところから始められます。気になる条件が見えてきたら、登録して詳しい内容を確かめてみましょう。
7. よくある質問
生成AIの案件では、具体的に何を任されますか
既存の業務システムに生成AIを組み込む案件では、たいてい提供者としての仕事にあたります2。検索対象の文書を根拠として参照させ、出力過程や根拠の透明性を高める実装を組み立てる仕事が中心になります4。モデルそのものを開発する仕事とは、求められる経験の中身が異なります。
モデルを一から開発した経験がなくても、この案件に関われますか
関わりやすいのはむしろ提供者の立場です。開発者に関する事項と提供者に関する事項は別の部に整理されており2、提供者に求められるのは、既にある仕組みを業務の要件に合わせて組み立てる設計の力です。データ基盤の構築やシステム連携の経験は、この立場でそのまま活きてきます。
案件に入る前に、何を確認しておけばよいですか
まず、対策の程度をリスクの大きさに対応させるリスクベースアプローチの考え方を押さえておくと、案件の見積もりの見当がつきやすくなります3。加えて、ガイドラインはLiving Documentとして更新される前提のため8、参照している版がいつのものかを確認する習慣も欠かせません。
ガイドラインの版が更新されたら、案件での対応はどう変わりますか
版が更新されても、それまでの仕事がすべて無効になるわけではありません。ガイドラインはLiving Documentとして適宜更新される前提のため8、更新のたびに、前の版との差分を確認し、必要な箇所だけを見直す進め方になります。令和7年度の更新では、AIエージェント、フィジカルAIに関する事項が追記されています9。
Remoguでは、こうした案件をどのように探せますか
まずは、AI・LLMに関わるリモート案件の条件を一覧で見比べるところから始められます。案件によって求められる経験の範囲は異なるため、自分の経験がどこに重なるかを条件と照らし合わせながら確かめる進め方が向いています。登録すると、条件の詳細をより具体的に確認できます。
リモートワーク案件をお探しの方へ
Remoguは、株式会社LASSICが運営するITエンジニア・デザイナー専門のリモートワーク案件紹介サービスです。フルリモート・ハイブリッドの案件から、スキルに合うものを探せます。
生成AIを既存の仕組みに組み込む案件では、使うモデルや検索の方式より先に、自分がどの立場で関わるのかが決まります。まずはAI・LLMのリモート案件が、いまどんな条件で並んでいるかを見てみてください。
会員登録無料 / 案件閲覧・相談は無料
※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。
出典・参考情報
*1 総務省「AI事業者ガイドライン(第1.1版)」第1部 はじめに(2025年)
*2 総務省「AI事業者ガイドライン(第1.1版)」目次(2025年)
*3 総務省「AI事業者ガイドライン(第1.1版)」第1部 はじめに(2025年)
*4 総務省「AI事業者ガイドライン(第1.1版)」脚注18(2025年)
*5 総務省「AI事業者ガイドライン(第1.1版)」第1部 はじめに(2025年)
*6 総務省「AI事業者ガイドライン(第1.1版)」共通の指針 透明性(2025年)
*7 総務省「AI事業者ガイドライン(第1.1版)」AIガバナンスの構築(2025年)
*8 総務省「AI事業者ガイドライン(第1.1版)」第1部 はじめに(2025年)
*9 総務省「AI事業者ガイドラインの令和7年度更新内容」更新の全体像(2026年3月)
*10 Remoguサイト公開情報(フルリモート可能案件の割合)