RAG構築ができるエンジニアとは？業務委託で任せられる範囲
RAG構築ができるエンジニアとは、社内資料を検索し、その内容をもとに生成AIが回答する仕組みを設計・構築・運用できる人材です。求人や職務経歴書では「LLMアプリ開発エンジニア」などと呼ばれることもあります。
デジタル庁のガイドブックによると、RAGは質問に関連する文章を検索し、その内容をもとに大規模言語モデルが回答を生成する手法です。生成AI単体では回答が難しい自社の規程や手続きについても、根拠となる資料を示しながら回答できます。
▼参考：テキスト生成AI利活用におけるリスクへの対策ガイドブック（α版）｜デジタル庁
RAG構築で外部に任せられる工程と社内で持つべき役割
RAG構築は複数の工程に分かれ、それぞれ外部の専門人材に任せられる業務と、社内で担うべき役割が異なります。
| 工程 | 外部に任せられる内容 | 社内で担う役割 |
| 要件整理 | 対象業務や求める水準の明確化を支援 | 対象業務と合格基準の最終決定 |
| 文書の整備 | 資料の形式を統一し、検索できる状態にする | 対象資料や整備ルール、管理責任者の決定 |
| 検索と取り込みの設計 | 質問に合う資料を検索する仕組みの構築 | 部署ごとの閲覧権限の設定ルールの決定 |
| 回答生成の調整 | 資料に基づく回答と参照元の表示方法を設計 | 回答の言葉づかいや回答禁止範囲の決定 |
| 評価 | 精度を測る仕組みと評価用の質問の準備 | 合格基準に基づく最終判定 |
| 運用と改善 | 改善手順の整備と社内への引き継ぎ | 資料の更新と利用状況の確認 |
RAG構築の実装は多くを外部に任せられますが、どの資料を使うか、どの程度の精度なら合格かは、自社の業務を理解している社内担当者が決める必要があります。
特に、資料の整備ルールと評価の最終判断を社内で管理することが重要です。これにより、外部人材との契約終了後も継続して運用・改善できる体制を整えられます。
試作（PoC）と本番運用で求められる力の違い
RAGの試作品（デモ）は短期間で作れますが、社内で継続して使える仕組みにするには、別のスキルが必要です。本番運用では、主に次の4点が重要になります。
- 回答の正確さを測る仕組みがあるか
- 資料の更新を回答に反映できるか
- 利用者ごとに閲覧できる資料を制限できるか
- 利用料を見積もり、管理できるか
これらは、デジタル庁のガイドブックでも生成AIシステムの留意点として挙げられています。試作品が正常に動いても、こうした仕組みがなければ、運用開始後に誤った回答や古い情報が放置され、利用されなくなる恐れがあります。
本番運用まで任せられる人材かどうかを判断するために、記事の後半では人材の見極めで使える8つの質問を紹介します。
RAG構築ができるエンジニアを業務委託で採用するメリット
RAG構築ができるエンジニアを業務委託で迎えると、社内にない専門知識を必要な工程に絞って活用できます。正社員の採用や社内での人材育成を待たずに、導入を進められる点もメリットです。ここでは、主なメリットを3つ紹介します。
社内にない専門知識をすぐに取り込める
生成AIやRAGは技術の進歩が速く、使われる手法も短期間で変化しています。正社員の採用や社内での人材育成を待っていると、導入が遅れ、他社との差が広がる恐れがあります。
業務委託であれば、RAGの構築・運用経験がある人材に、必要なタイミングで依頼できます。社内に専門知識がなくても、経験者から自社の状況に合った進め方を提案してもらえるため、手探りで進めるよりも効率よく導入を進められます。
試作から運用まで必要な工程だけを依頼できる
業務委託では、依頼する工程や期間を区切って契約できます。例えば、「まずは試作で効果を確かめたい」「運用の立ち上げだけ支援してほしい」といった依頼が可能です。
試作の結果を見てから次の工程に進むか判断できるため、初期投資を抑えられます。期待した成果が得られなかった場合も、早い段階で方針を見直せるでしょう。また、役割分担表をもとに任せる工程を事前に決めておけば、依頼範囲のズレも防ぎやすくなります。
社内にノウハウを残しやすい
業務委託では、専門知識やノウハウが社内に残らないと思われがちです。しかし、前述の役割分担表にある「社内で担うべき役割」を自社で担当すれば、構築に必要な知識を蓄積できます。
あわせて、資料の整備方法や回答精度の評価方法を社内メンバーに共有し、引き継ぐ計画（範囲や方法）を決めておくと、円滑に進められます。外部の専門人材と協力して構築した経験は、将来的な内製化の土台にもなります。
RAG構築ができるエンジニアを採用する前に企業側で決めておく3つのこと
RAG構築ができるエンジニアを採用する前に、自社が何を、どの水準で実現したいのかを明確にしておく必要があります。デジタル庁のガイドブックでも、求める品質が明確でないと、期待を下回るシステムが納品されるリスクがあると指摘されています。
ここで決める3つの項目は、後半で紹介する見極め質問で候補者を評価する基準にもなります。人事担当者だけでなく、経営層や実際にシステムを使う部署の担当者と一緒に決めましょう。
▼参考：テキスト生成AI利活用におけるリスクへの対策ガイドブック（α版）｜デジタル庁
①RAGで解決したい業務と利用者を決める
まず、RAGで解決したい課題を明確にします。社内問い合わせ対応、営業資料の検索、社内規程の確認など、対象業務は最初に1つに絞るのがおすすめです。あわせて、利用する部署や人数も整理しておきましょう。
用途を広げすぎると、求める品質の基準が曖昧になり、確認すべき範囲も増えてしまいます。また、対象業務を明確にしておけば、候補者が過去に構築したRAGの用途や利用者が、自社の求めるものに近いかどうかを判断しやすくなります。
②対象にする資料の範囲・形式と閲覧権限を整理する
次に、RAGで検索する資料を決めます。社内規程やマニュアル、過去の問い合わせ履歴などから、対象を絞り込みましょう。
資料の形式も重要です。表の多いPDF、スキャンした書類、表計算ファイル、社内Wikiなど、形式によって取り込みの難しさが異なります。あわせて、更新頻度や部署ごとの閲覧権限も整理しておく必要があります。
事前に資料の形式を把握しておけば、候補者が難しい形式の資料を扱った経験を評価できます。また、閲覧権限の要件を明確にすることで、候補者が提案する仕組みが自社に適しているかも判断しやすくなります。
③どの程度正しく答えられれば合格かを決める
最後に、RAGの回答が合格といえる基準を決めます。具体的には、「よくある質問と正しい回答」のセットを用意し、評価方法と判定する担当者を決めておきましょう。
デジタル庁のガイドブックでも、過去の問い合わせとその回答を評価に活用する例が示されています。実際にシステムを使う部署の担当者が、用意した質問への回答を確認する方法がわかりやすいでしょう。
合格基準が曖昧だと、回答精度について候補者と認識がずれ、提案された評価方法が十分かどうかも判断しにくくなります。
RAG構築ができるエンジニアの探し方・絞り込み方
RAG構築ができるエンジニアを探す際は、職務経歴書や応募時の提案文に記載されたRAGの実績を確認し、候補者を絞り込みます。ここでは、具体的な探し方と絞り込みのポイントを紹介します。
職務経歴でRAGに関する実績の記載を探す
職務経歴書では、まずRAGに関する実績が記載されているかを確認します。「RAG」「検索拡張生成」「ナレッジ検索」「社内文書検索」「AIチャットボット」などが目印です。
職種名が「LLMアプリ開発エンジニア」や「生成AIエンジニア」でも、RAGの構築経験が記載されている場合があります。ただし、キーワードだけで判断せず、どのような業務向けの仕組みを構築し、どのくらいの期間関わったのかまで確認しましょう。
「試作のみ」か「運用まで」かを経歴から見分ける
RAGの実績が見つかったら、試作だけでなく、本番運用まで関わった経験があるかを確認します。「PoCを担当」「デモを開発」といった記載だけでは、試作段階で終わっている可能性があります。
一方、「社内公開」「利用者数」「精度改善」「運用保守」などの記載があれば、本番運用まで経験しているかを判断する手がかりになります。
応募時の提案文から進め方の考え方を確かめる
マッチングサービスなどで募集する場合は、応募時のメッセージや提案文も判断材料になります。特に、資料の整備方法や回答精度の評価方法に触れているかを確認しましょう。
「すぐに作れます」という提案よりも、作業の進め方や事前に確認すべき項目が具体的に書かれているほうが、本番運用を見据えている可能性があります。
提案文から候補者の考え方を比較できるため、面談に進む人材の絞り込みに役立ちます。また、記載された内容は面談で詳しく確認する際の手がかりにもなるでしょう。
RAG構築ができるエンジニアを見極める8つの質問
RAG構築ができるエンジニアを見極めるには、試作だけでなく、本番運用まで設計できるかを確認することが重要です。ここでは、候補者の経験や技術力を判断するための8つの質問を紹介します。
| 質問 | 確認すること | よい回答の例 | 注意が必要な回答の例 |
| ①これまで作ったRAGは、誰が何のために使っていましたか？ | 本番運用の経験 | 利用者・用途・運用期間・成果を具体的に説明できる | デモを作って発表しただけ |
| ②回答の正しさの評価は、どう設計しましたか？ | 精度の評価方法 | 評価用の質問と正解を用意し、精度を測った | 何度か試して問題なさそうだった |
| ③検索精度が出ないとき、どこから切り分けますか？ | 原因を特定する力 | 必要な資料が検索できているかを確認し、順番に原因を調べる | プロンプトを調整するだけ |
| ④扱いに苦労した文書形式は何でしたか？ | 実務経験 | 表・図面・スキャンしたPDFなどの課題と対処法を説明できる | 特に苦労しなかった |
| ⑤元の資料が更新されたら、どう反映しますか？ | 更新を続けられる仕組み | 資料の更新を自動で反映する方法を説明できる | 毎回手作業で登録し直す |
| ⑥部署ごとの閲覧権限は、どう実装しましたか？ | 閲覧権限の管理経験 | 利用者の権限に応じて検索対象を制限した | 全員が同じ資料を閲覧する前提だった |
| ⑦RAGを使わない方がよいのは、どんな場合ですか？ | 適切な技術を選ぶ力 | 既存サービスの利用や資料を直接渡す方法も提案できる | どんな場合もRAGを勧める |
| ⑧社内データを扱う前に、何を確認しておくべきですか？ | 情報管理への意識 | 個人情報の有無やAIの学習への利用設定を確認する | 情報管理はすべて依頼企業に任せる |
①これまで作ったRAGは、誰が何のために使っていましたか？
「これまで作ったRAGは、誰が何のために使っていましたか？」という質問では、試作だけでなく、実際の業務で使われる仕組みを構築した経験があるかを確認します。
【よい回答の例】
「人事部の社内問い合わせ対応向けに構築し、部署のメンバーが半年ほど利用しました。よくある質問に自動回答できるようにし、利用状況を見ながら改善しました」
【注意が必要な回答の例】
「デモを作って社内で発表しました」
判定のポイントは、利用者・用途・運用期間・成果を具体的に説明できるかどうかです。本番運用の経験があれば、利用者の反応や運用中に改善した内容まで説明できるでしょう。
②回答の正しさの評価は、どう設計しましたか？
「回答の正しさの評価は、どう設計しましたか？」という質問では、回答精度を測る仕組みを自分で設計できるかを確認します。
【よい回答の例】
「よくある質問と正しい回答をまとめた評価用のセットを作り、修正するたびに正答率を測りました。誤った回答は種類ごとに記録しました」
【注意が必要な回答の例】
「何度か試して問題なさそうだったので公開しました」
判定のポイントは、評価用の質問と正解を用意し、精度を測った経験があるかどうかです。自社で用意した質問セットを見せ、「これを使って精度を測れますか」と確認するのも有効です。
③検索精度が出ないとき、どこから切り分けますか？
「検索精度が出ないとき、どこから切り分けますか？」という質問では、回答が正しく生成されない原因を、順序立てて調べられるかを確認します。
【よい回答の例】
「まず、正しい資料を検索できているかを確認します。できていなければ、資料の区切り方（チャンク設計）や検索用データへの変換方法（埋め込み）、検索方式を見直します。正しい資料を検索できているのに回答が間違っている場合は、AIへの指示文（プロンプト）を調整します」
【注意が必要な回答の例】
「プロンプトを調整します」
判定のポイントは、原因を調べる順番を説明できるかどうかです。専門用語がわからなくても、確認する順序が明確かどうかは判断できます。
デジタル庁のガイドブックでも、正しい資料を検索できているか、回答が資料に基づいているかを分けて評価することが示されています。
④扱いに苦労した文書形式は何でしたか？
「扱いに苦労した文書形式は何でしたか？」という質問では、さまざまな形式の社内資料を扱った経験があるかを確認します。
【よい回答の例】
「表の多いPDFは、そのまま読み込むと行と列の関係が崩れるため、表だけ別の形式に変換しました。スキャンした書類は、文字を読み取る処理をしてから取り込みました」
【注意が必要な回答の例】
「特に苦労したことはありませんでした」
判定のポイントは、表・図面・スキャンしたPDFなど、具体的な文書形式と対処法を説明できるかどうかです。事前に整理した自社の資料形式と照らし合わせることで、すぐに業務を任せられるか判断しやすくなります。
⑤元の資料が更新されたら、どう反映しますか？
「元の資料が更新されたら、どう反映しますか？」という質問では、資料の更新を前提とした仕組みを設計できるかを確認します。
【よい回答の例】
「資料の保存場所を定期的に確認し、更新された資料だけを取り込み直す仕組みを作りました。古い版は検索対象から除外しています」
【注意が必要な回答の例】
「更新のたびに手作業で登録し直します」
判定のポイントは、人手に頼らず資料の更新を反映できる仕組みを説明できるかどうかです。社内規程やマニュアルは定期的に改定されるため、更新に対応できなければ、古い情報に基づく回答が残り続けるおそれがあります。
⑥部署ごとの閲覧権限は、どう実装しましたか？
「部署ごとの閲覧権限は、どう実装しましたか？」という質問では、利用者に応じて閲覧できる資料を制限した経験があるかを確認します。
【よい回答の例】
「資料ごとに閲覧可能な部署を設定し、質問した人の権限に合う資料だけを検索できるようにしました」
【注意が必要な回答の例】
「全員が同じ資料を閲覧できる前提で作りました」
判定のポイントは、閲覧権限を制御した具体的な方法を、自身の経験として説明できるかどうかです。特に、人事や経理などの機密情報を扱う場合は重要です。権限の設定を誤ると、本来閲覧できない情報がAIの回答に含まれる恐れがあります。
⑦RAGを使わない方がよいのは、どんな場合ですか？
「RAGを使わない方がよいのは、どんな場合ですか？」という質問では、技術ありきではなく、自社の状況に合った方法を提案できるかを確認します。
【よい回答の例】
「資料が数十ページ程度なら、検索の仕組みを作らず、資料をそのままAIに渡すほうが効率的です。資料がMicrosoft 365にまとまっていれば、既存のサービスで対応できる場合もあります」
【注意が必要な回答の例】
「どんな場合でもRAGの構築をおすすめします」
判定のポイントは、RAG以外の選択肢も挙げ、状況に応じて適切な方法を提案できるかどうかです。
開発元のAnthropicも、資料が少ない場合はRAGを使わず、資料全体をAIに渡す方法を紹介しています。また、デジタル庁のガイドブックでも、生成AIが本当に必要な処理かを事前に検討するよう推奨しています。
▼参考：Introducing Contextual Retrieval｜Anthropic
⑧社内データを扱う前に、何を確認しておくべきですか？
「社内データを扱う前に、何を確認しておくべきですか？」という質問では、社内データの適切な管理について意識があるかを確認します。
【よい回答の例】
「まず個人情報が含まれているかを確認し、利用するAIサービスが入力データを学習に使用しない設定になっているかを確かめます。試作段階では、ダミーデータや一部の資料を使うことをおすすめします」
【注意が必要な回答の例】
「そのあたりの確認は御社でお願いします」
判定のポイントは、企業側から指示される前に、情報管理に必要な確認事項を自ら挙げられるかどうかです。なお、8つの質問は複数の候補者に同じ内容で聞くと、経験や考え方の違いを比較しやすくなります。
RAG構築ができるエンジニアを業務委託で迎える際の注意点と対策
RAG構築ができるエンジニアを見極めても、依頼方法や受け入れ体制に問題があれば、期待する成果は得られません。特に、依頼範囲や社内データの扱いは、後から変更しにくい部分です。ここでは、代表的な3つの落とし穴と対策を紹介します。
試作の完成をゴールにしてしまう
よくある失敗は、試作の完成をゴールにして依頼を終えてしまうことです。精度の検証や資料更新の仕組みがないまま社内公開すると、誤った回答や古い情報が放置され、次第に使われなくなる恐れがあります。
これを防ぐには、依頼範囲に精度の検証と運用の引き継ぎを含めておきましょう。
また、フリーランスに業務委託する場合は、フリーランス新法に基づき、業務内容・報酬・支払い期日などを書面等で明示する必要があります。開発したプログラムや設定内容に関する著作権などの権利がどちらに帰属するかも、契約で決めておくことが重要です。
社内データの取り扱いルールを決めずに渡してしまう
社内規程や顧客対応の履歴には、機密情報や個人情報が含まれる場合があります。
個人情報保護委員会は2023年6月、生成AIサービスの利用について注意喚起を公表しました。個人データを入力する際は、利用目的の範囲内であることや、サービス提供事業者が入力データを機械学習に利用しないことなどを確認するよう求めています。
また、個人情報保護法第25条では、個人データの取り扱いを外部に委託する場合、委託先を監督する義務が定められています。
対策として、秘密保持契約を結び、提供するデータの範囲や保管・削除方法、作業環境、アカウントの管理方法を決めておきましょう。不要な個人情報は除き、判断に迷う場合は弁護士などの専門家に相談することをおすすめします。
▼参考：生成AIサービスの利用に関する注意喚起等について｜個人情報保護委員会
構築を任せきりにしてしまう
社内に担当者を置かず、RAG構築を外部に任せきりにすると、契約終了後に仕組みを改善できなくなる恐れがあります。資料の更新も滞り、回答の精度が徐々に低下する可能性があります。
対策として、依頼前に社内で担うべき役割を担当する人を決めておきましょう。あわせて、資料の整備方法や回答精度の評価方法を引き継ぐ計画も立てておくことが重要です。社内担当者は、業務の目的や求める成果を外部の専門人材と共有する窓口としても役立ちます。
SOKUDANではRAG構築ができるエンジニアが見つかる
先述した質問を活用してエンジニアを見極めるには、複数の候補者に同じ質問をして回答を比較することが重要です。候補者を比較しながら採用したい企業には、業務委託マッチングサービスのSOKUDAN（ソクダン）がおすすめです。
SOKUDANは、転職市場にはいないAI時代の即戦力人材と、最短60分でマッチングできるサービスです。登録者の約6割が実務経験5年以上で、LLMアプリ開発エンジニア、AIコンサルタント、データサイエンティストなど、幅広いAI人材が登録しています。
候補者はAIと人による二重スクリーニングを経て、条件に合う5名程度に絞って提案されます。複数の候補者を同じ基準で比較できるため、今回紹介した質問を活用した見極めにも役立ちます。
また、専任担当者のサポートにより、採用工数を70%削減できる点も特徴です。料金は初期費用0円から利用でき、契約は基本的に3者間契約となります。最短翌週から稼働できる人材も見つかるため、RAGの試作を早期に始めたい企業にも適しています。
RAG構築ができるエンジニアの業務委託採用に関するよくある質問
最後に、RAG構築ができるエンジニアを業務委託で採用する際のよくある質問に回答します。
RAG構築ができるエンジニアとAIエンジニアは何が違う？
AIエンジニアは、機械学習モデルの開発なども含む幅広い職種です。一方、RAG構築ができるエンジニアは、既存の大規模言語モデルと社内資料を組み合わせた仕組みの設計・開発を中心に担当します。そのため、「LLMアプリ開発エンジニア」と呼ばれることもあります。
社内に技術がわかる人がいなくても依頼できる？
社内に技術に詳しい人材がいなくても、RAG構築を外部に依頼できます。ただし、対象業務・資料・合格基準を事前に明確にしておくことが重要です。先述した「決めておく3つのこと」を整理すれば、面談で候補者の提案や回答を評価する基準にもなります。
社内だけで整理するのが難しい場合は、要件整理から支援してくれるマッチングサービスを活用する方法もあります。
社内文書を外部のエンジニアに扱わせて大丈夫？
適切な情報管理のルールを設ければ、外部のエンジニアにも依頼できます。まずは秘密保持契約を結び、提供するデータの範囲や保管・削除方法を決めましょう。アクセスできる資料や作業環境も、必要な範囲に制限します。
試作段階ではダミーデータや一部の資料を使い、検証後に本番用の資料を提供すると安心です。また、不要な個人情報は除き、契約内容は弁護士などの専門家に確認することをおすすめします。
業務委託のエンジニアにどこまで指示を出していい？
業務の目的や求める成果物の水準を伝えることは問題ありません。ただし、作業方法や勤務時間を細かく指示・管理すると、偽装フリーランスとみなされる恐れがあります。業務委託では、社内担当者を窓口とし、求める成果を共有しながら進めることが基本です。
まとめ
RAG構築ができるエンジニアを業務委託で採用するには、まず対象業務・資料・合格基準を社内で明確にすることが重要です。そのうえで、職務経歴書や提案文からRAGの実績を確認し、8つの質問で候補者の力量を見極めましょう。
特に重視したいのは、試作だけでなく、本番運用まで設計できるかという点です。技術に詳しくなくても、過去の経験や具体的な対応方法を説明できるかで判断できます。候補者の違いを見極めるには、複数人に同じ質問をして比較することが効果的です。
SOKUDANでは、AIと人による二重スクリーニングを経た候補者を5名程度に絞って提案するため、同じ基準で比較しながら選べます。初期費用0円から利用でき、最短60分で即戦力人材とのマッチングが可能です。
SOKUDANのサービス資料では、業務委託採用の進め方や費用感、導入事例を紹介しています。RAG構築を任せられる人材を探す際に、ぜひご活用ください。
