フリーランスの生成AI案件｜必要スキルと実績作り

「業務でLLMを触った経験がほとんどない」「個人でChatGPTやClaudeを使っているだけでは、スキルシートに書けることがない」。生成AIの案件に入りたいエンジニアが最初にぶつかるのが、この「経験の壁」です。ただ、生成AI・LLMの案件で求められる経験の中身が分かれば、実務経験が少ない段階からでも準備を始められます。この記事では、フリーランスや副業で入る生成AI案件の主な型と求められるスキル、実績の作り方、スキルシートと面談での伝え方をお伝えします。

生成AI案件の主な4つの型

「生成AI案件」とひとまとめに呼ばれますが、中身はかなり違います。どの型の案件かによって、求められるスキルも、経験の浅い人が入れる余地も変わります。

型	よくある内容	中心になるスキル
社内向けチャット・RAG	社内規程やマニュアルを検索して答えるチャットを作ります	検索の設計、文書の前処理、評価
業務への組み込み・API連携	既存の業務システムからLLMのAPIを呼び、要約・分類・抽出などを自動化します	Python などでのAPI実装、既存システムの理解
PoC支援	使えるかどうかを短い期間で試し、続けるかどうかの判断材料を作ります	素早い試作、効果の測り方、報告のまとめ方
データ整備・評価	検索対象の文書を整え、評価用の質問と正解を作り、精度を測ります	データの扱い、評価の設計、業務の理解

社内向けチャット・RAG

よく見られる型の一つです。RAG（検索拡張生成）は、質問に関係する情報を先に検索し、それを根拠に回答を作らせる仕組みです。Google Cloud の RAG Engine の概要では、取り込み・変換・エンベディング・インデックス登録・取得・生成の段階に分けて説明しています。案件では、この流れのどこかを担当することが多く、特に「文書の分け方」と「検索の当たり方」の調整に時間がかかります。

業務への組み込み・API連携

問い合わせの分類、議事録の要約、帳票からの項目抽出など、既存の業務の一部にLLMを組み込む型です。LLMそのものより、既存システムとの接続、入力データの整形、失敗したときの扱い（再実行・人への差し戻し）の実装が仕事の大半になります。業務システムの開発経験がそのまま活きる型です。

PoC支援

短い期間で試作し、「本番に進めるか」を判断する材料を作る型です。作ること以上に、何をもって成功とするかを先に決め、結果を数字で報告できるかが問われます。

データ整備・評価

RAGの検索対象となる文書の整理や、評価用の質問と期待する回答の作成、精度の測定を担う型です。目立ちにくい役割ですが、ここが弱いと回答の質は上がりません。

生成AI案件で求められるスキル

型ごとに比重は違いますが、多くの案件で共通して見られるのは次の5つです。

Python とAPIの実装

LLMの利用は、多くの場合APIを呼ぶ形になります。Python（または案件の既存言語）でAPIを呼び、入出力を整え、エラーや時間切れを扱える必要があります。モデルの学習や数式の知識が求められる案件は一部で、多くは「APIを使って業務の処理を組み立てる」開発です。

検索・RAGの設計

文書をどの単位で分けるか、どの検索方式を使うか、検索結果を何件渡すか、といった設計の判断です。回答がずれたときに、原因が検索の側にあるのか生成の側にあるのかを切り分けられると、現場で頼られます。

評価・テスト

生成AIの出力は毎回少しずつ変わるため、「動いた」だけでは品質を説明できません。Anthropic のドキュメント（成功基準の定義と評価の作り方）では、成功の基準を具体的で測れる形に決め、実際の利用に近いテストケースや例外的なケースを含めて、できるだけ自動で評価することを勧めています。評価用の質問と期待する回答を用意し、変更のたびに同じ評価を回す、という進め方を説明できることは強みになります。

業務の理解

生成AI案件の多くは、業務の課題を解くためのものです。「誰が、どの作業に、どれくらい時間をかけているか」を聞き取り、AIで置き換える部分と人が確認する部分を分けられると、PoCの先に進みやすくなります。

セキュリティ・情報管理

社内文書や顧客データを扱うため、情報の扱いには特に注意が必要です。OWASP の LLM・生成AIアプリケーション向け Top 10（2025年版）では、プロンプトインジェクションや機密情報の漏えい、出力の不適切な扱いなどを主なリスクとして挙げています。権限のない文書を検索結果に混ぜない、入力したデータがどこに送られるかを確かめる、といった基本を押さえていることは、どの型の案件でも求められます。

実務経験が少ないときの実績の作り方

生成AIの実務経験がまだ少ない段階では、「何ができるか」を相手が確かめられる形で示すことが大切です。ここでは、取り組みやすい方法を4つに分けてお伝えします。

公開できる小さな成果物を作る

公開されている文書（自治体の公開資料、オープンソースのドキュメントなど）を対象に、小さなRAGのアプリを作り、GitHub などで公開します。大きなものである必要はありません。READMEに「何を対象に」「どういう構成で」「どこで苦労したか」を書いておくと、面談で話す材料になります。社内の資料や前の案件のデータを使うのは避けてください。

評価の数字を残す

成果物を作ったら、評価用の質問を数十件ほど用意し、正しく答えられた割合を記録します。文書の分け方や検索の件数を変えたときに数字がどう動いたかを残しておくと、「試行錯誤の進め方」を具体的に示せます。数字の大きさよりも、測り方を自分で決めて改善を回した経験のほうが評価されます。

業務の課題から作る

「流行りの技術を試した」より、「この作業に毎週これだけ時間がかかっていたので、ここを自動化した」という形のほうが、案件の現場の話とつながります。自分の業務や身の回りの作業から課題を一つ選び、課題・やり方・結果の順にまとめておくと、PoC支援の案件でも説得力が出ます。

既存の案件の中でAIを使った改善を記録する

今の案件で、テストコードの作成、ログの要約、ドキュメントの下書きなどに生成AIを使っているなら、それも立派な経験です。ただし、現場のルールで許可された範囲で使っていることが前提です。何に使い、どれくらい手間が減ったか、どこは人が確かめたかを記録しておくと、スキルシートに書ける実績になります。

スキルシートと面談での伝え方

経験が少ないことを隠す必要はありません。何をどこまでやったかを、正確に、具体的に書くほうが信頼されます。

• 「生成AIの知見あり」のような書き方ではなく、「社内規程を対象にしたRAGの試作で、文書の分割方法を3通り比べ、評価用の質問50件で正答率を記録しました」のように、対象・やったこと・測ったことを書きます。
• 個人の成果物と業務の実績は分けて書きます。混ぜて書くと、面談で深く聞かれたときに説明が苦しくなります。
• 既存システムの開発経験は省かずに書きます。生成AI案件でも、API連携や既存システムの改修の経験が評価されることは多くあります。
• 面談では、うまくいかなかった点と、その原因をどう切り分けたかを話せるようにしておきます。生成AIの開発は試行錯誤が前提なので、その進め方が見られます。

未経験から入りやすい役割

生成AIの実務経験がない段階で、いきなりLLM周りの設計を任される案件に入るのは簡単ではありません。入り口として現実的なのは、次の2つの役割です。

既存システム側の開発

生成AIを業務に組み込む案件では、LLMを呼ぶ部分は全体の一部で、残りは画面・API・データベース・認証といった通常の開発です。既存システム側の開発メンバーとして入り、AIの部分を担当する人と一緒に仕事をすることで、実務の経験を積めます。

データ整備・評価の担当

文書の整理や評価用データの作成、精度の測定は、業務の理解と丁寧さが求められる仕事で、ここから生成AI案件に入る人もいます。評価の仕組みに関わると、なぜ回答がずれるのかが分かるようになり、次の案件で設計側に回る足がかりになります。

案件の内容だけでなく、契約の形や間に入る会社の数も、任される範囲や条件に影響します。商流の浅い案件の見分け方もあわせて確かめておくと、案件を選ぶときの判断がしやすくなります。

生成AI案件で気を付けたいこと

期待値のずれ

発注側が「AIを入れればすぐに業務が楽になる」と期待している場合、精度や運用の手間について早めに話しておかないと、後で「思っていたものと違う」となりがちです。できること・できないこと・確かめ方を、着手の前にすり合わせておくことが、自分の身を守ることにもつながります。

情報管理

社内文書や個人情報を扱う案件では、どのサービスにデータを送ってよいか、手元の端末にデータを置いてよいかといったルールが決まっています。個人で契約しているAIサービスに案件のデータを入れるのは、許可がない限り避けてください。

PoC止まり

PoCが「試してみた」で終わり、本番に進まないことは少なくありません。PoCの案件に入るときは、成功の基準と、次に進むかを誰がいつ判断するかを確かめておくと、成果を説明しやすくなり、継続や本番開発の案件につながりやすくなります。

生成AIの経験を積んだ後に、要件定義やPoCの計画づくりといった上流の役割へ広げたい場合は、上流・PMO案件で単価を上げる考え方も参考になります。

まとめ

• 生成AI案件には、社内向けチャット・RAG、業務への組み込み・API連携、PoC支援、データ整備・評価といった型があり、求められるスキルが違います。
• 共通して求められるのは、APIの実装、検索・RAGの設計、評価・テスト、業務の理解、セキュリティ・情報管理です。
• 実務経験が少ないうちは、公開できる小さな成果物を作り、評価の数字を残し、業務の課題から作った形でまとめると、相手が確かめられる実績になります。
• スキルシートでは「何を対象に、何をして、何を測ったか」を具体的に書き、既存システムの開発経験も省かずに伝えます。
• 入り口としては、既存システム側の開発やデータ整備・評価の役割が現実的です。期待値・情報管理・PoC止まりには、着手前のすり合わせで備えます。