生成AIエンジニアのスキルシートの書き方｜面談で評価される実績の見せ方

生成AIエンジニアのスキルシートは、「どの業務で、誰が、何のために使う仕組みか」を先に書き、そのうえで検索・評価・運用統制のどの層を担ったかと、回答の品質をどう確かめたかを書くのが基本です。生成AIの経歴は「大規模言語モデルを使ったチャットボットを開発」のような一行になりやすく、これでは試作を一度動かした人と、業務で使われ続ける仕組みを作った人の区別がつきません。

案件で求められるスキルの層は生成AIエンジニアのスキルの記事で整理しています。この記事では、その層をスキルシートの上でどう見せるかに絞って説明します。全体の構成はスキルシートの基本をご覧ください。

一行目に「業務」と「利用者」を書く

生成AIのプロジェクトは、技術の構成が似ていても、業務によって難しさがまったく違います。社内の規程を答える仕組みと、顧客からの問い合わせの下書きを作る仕組みでは、許される誤りの程度も、確かめる方法も違います。

プロジェクト欄の案件概要は、次の順で書くと読み手が全体をつかめます。

1. 業務（例：社内の問い合わせ対応、契約書の確認の補助、報告書の下書き）
2. 利用者（例：社内の窓口担当、営業部門、開発者）
3. 使われ方（例：回答を担当者が確認してから使う、利用者が直接読む）

3つめの「使われ方」は特に大切です。人が確認してから使う前提か、利用者が直接読む前提かで、求められる品質と評価の厳しさが変わるためです。

担った層を明記する

生成AIの仕組みは、いくつかの層に分けて考えると担当範囲が伝わります。スキルシートでは、プロジェクトごとに担った層に印をつけるつもりで書きます。

「アプリの土台」だけを担った場合も、そのとおりに書いてかまいません。生成AIの案件でも、既存のシステムにつなぐ部分の開発は多く募集されています。担っていない層まで書くと、面談で評価の方法を聞かれたときに答えに詰まります。

「評価の方法」の欄を独立させる

生成AIのシートで最も差がつくのが、評価の書き方です。ほかの職種の記入例にはない欄ですが、プロジェクト欄に「評価の方法」を1行追加することをおすすめします。

• 何で確かめたか：業務の担当者と作った質問と回答の組、実際の問い合わせから選んだ例など
• 何を見たか：回答が根拠の文書に沿っているか、必要な情報が抜けていないか、答えてはいけない質問に答えていないか
• いつ確かめたか：指示文やモデルを変えるたび、定期的に、など

件数や改善の幅を数字で書けない場合は、「数百件規模の評価用の組を作り、変更の前後で比べた」のように、進め方の形で書けば伝わります。評価の仕組みを作った経験は、試作で止まらずに改善を続けた証拠として読まれます。

モデル名とサービス名には時点を添える

生成AIは、使えるモデルや開発の道具の入れ替わりが速い分野です。スキルシートに「○○のモデルを使用」とだけ書くと、読み手には、それがいつの話なのかが分かりません。

• モデル名は、使った時期と一緒に書く（例：20XX年時点の○○系のモデル）
• 版の違いが大きいライブラリは、主な版を添える
• 途中でモデルを切り替えた経験があれば、切り替えた理由を書く（費用、応答時間、出力の安定など）

切り替えの経験は、特定のモデルに頼らずに仕組みを作れることを示す材料になります。複数のモデルを比べて選んだ経験も、選んだ基準と一緒に書くと評価されやすくなります。

指示文と社内文書の中身は書かない

生成AIの案件では、参画先の社内文書や、工夫を重ねた指示文に触れます。これらは参画先の資産なので、スキルシートに書き写さないでください。

• 指示文の全文や、その工夫の具体的な言い回し
• 検索の対象にした文書の名前や中身
• 評価に使った質問と回答の組そのもの
• 利用者の入力のログから拾った具体的な質問

代わりに、「指示文を役割・制約・出力形式に分けて管理し、変更の履歴を残した」のように、作り方と管理の方法を書きます。生成AIの仕組みに情報を渡すときの考え方は生成AIエンジニアのスキルの記事、スキルシート全般の線引きはスキルシートに書いてよいこと・いけないことをご覧ください。

プロジェクト欄の記入例

以下は書き方を示すための例で、実在の案件や実績ではありません。業界や規模はぼかしています。

期間：20XX年X月〜20XX年X月（8か月）
案件概要：製造業向け 社内の技術文書を検索して回答する仕組み（利用者は社内の技術者。回答には根拠の文書を常に表示し、利用者が確認してから使う前提）
規模・立場：開発3名（自分は検索と評価の担当）
担った層：検索、評価、運用（費用の監視）
使用技術：Python、20XX年時点の大規模言語モデルのAPI、ベクトル検索、全文検索、クラウドの関数実行サービス
担当内容：文書の分け方を見直し、ベクトル検索と全文検索を組み合わせた。表を含む文書の取り込み方を変えた
評価の方法：業務の担当者と評価用の質問と回答の組を作り、検索の方式を変えるたびに、根拠に沿った回答の割合を比べた
工夫・成果：根拠の文書が見つからないときは回答せずに問い合わせ先を示す作りにした。費用を日次で集計し、上限に近づいたら通知されるようにした

「回答には根拠の文書を常に表示」は仕組みの仕様の説明なので、案件概要に書いて問題ありません。利用者が誤った回答をそのまま使わないための工夫は、情報の扱いを任せられるかの判断材料になります。

個人開発と短い試作の並べ方

生成AIの分野では、業務の外で作ったアプリや、短い期間の試作が経歴の多くを占める方もいます。並べ方を工夫すると、件数の多さが散らかった印象になりません。

• 短い試作が続いた場合：期間が近く技術が似ている試作は、「生成AIの検証（3件）」のようにまとめ、共通して担った層と、その中で最も進んだ1件を書く
• 個人開発のアプリ：実務の欄とは分け、何を作り、何を確かめたかを書く。公開していれば場所も書く
• 社内の利用ルールづくり：開発ではなくても、入力してよい情報の範囲を決めた経験は、運用・統制の層の実績として書ける

費用と応答時間の工夫も一行で書く

生成AIの仕組みは、使われるほど費用がかかり、応答が遅いと使われなくなります。この点に手を打った経験は、試作から運用へ進めた人の実績として読まれます。

• 質問の種類によって、軽いモデルと重いモデルを使い分けた
• 同じ質問への回答を再利用し、呼び出しの回数を減らした
• 応答を少しずつ表示する作りにし、待ち時間の感じ方を和らげた

金額や応答時間の具体的な数字は書かなくても、「何を見て、何を変えたか」が書かれていれば伝わります。

資格の書き方

資格がなくても参画できる案件は多くあります。日本ディープラーニング協会のG検定は、ディープラーニングの基礎知識を持ち、事業での活用方針を決められるかを確かめる検定とされ、受験資格に制限はありません（2026年10月時点の公式サイトによる）。書く場合は、正式な名称と合格した年月をそろえます。基礎知識の確認としての位置づけなので、実務で担った層の説明とあわせて伝えることが大切です。

よくある質問

指示文（プロンプト）の設計しか担当していません。書けることはありますか？

あります。出力を決まった形式で受け取る工夫や、答えてはいけない質問への対応、変更の履歴の管理などは、指示文の設計の中でも実務の経験として読まれます。改善の前後で何を比べたかを書き添えると伝わりやすくなります。

機械学習の経験と生成AIの経験は、同じ欄に書いてよいですか？

プロジェクトは分けて書くことをおすすめします。機械学習の案件では学習とモデルの運用が、生成AIの案件では検索と評価と情報の扱いが読まれるため、書く観点が違います。機械学習の書き方は機械学習エンジニアのスキルシートの記事をご覧ください。

社内向けで利用者が少ない仕組みでも、実績になりますか？

なります。利用者の数より、業務で使われ続けたか、利用者の声をもとにどう直したかが読まれます。利用者の人数を書けない場合は「一部署の担当者が日常的に利用」のようにぼかして書けば十分です。