ひとつの職種ではない
AI / データ領域は、分析する人・モデルを作る人・基盤を作る人・可視化する人の集合です。
00 / First Map
新人営業がまず押さえる5点
細かい技術の前に、判断の軸を持ちます。ここを外すと、後の章を読んでも提案がズレます。
AI経験だけでは判断しない
趣味でChatGPTを触った人も、業務でモデルを本番運用した人も、同じ言葉を書くことがあります。
Python = AI人材ではない
PythonはWeb開発や自動化にも使われる汎用言語です。Pythonで何をしたかを確認します。
4軸で分ける
分析、モデル開発、データ基盤、生成AIは別物です。案件もスキルもこの4軸で仕分けます。
迷ったら面談で確認
わからないまま提案しないことが最大の事故防止です。確認は逃げではなく正しい仕事です。
01 / Why
この教材で判断できるようになること
案件概要を読み、スキルシートを分解し、面談で踏み込み、ミスマッチを防ぎ、提案コメントを書ける状態を目指します。
事故の原因は、言葉を分解しないこと
「AIやってました」を中身確認なしで機械学習案件に出す、Pythonが書けるだけの人をAI人材として出す、ChatGPT API利用をRAG構築と誤読する、分析者と基盤構築者を取り違える。これらは新人営業が起こしやすい典型例です。
ゴールは「この人を、どの案件に、どの強さで提案できるか」を自分で判断できることです。
営業向けポイント
技術を語れる必要はありません。表面の言葉を、案件適合の根拠に分解できることが重要です。
02 / Domain Map
AI / データ領域の主要職種
主要な7職種を、役割・技術・案件・提案しやすい人材・混同ポイントで整理します。生成AI / LLMエンジニアも独立した職種として見ます。
AIエンジニア
AIを使った機能・システムを開発・実装する人の総称。実務ではAIを組み込んだアプリやAPIを作る人を指すことが多いです。
- 技術: Python、MLライブラリ、AI API、クラウド
- 案件: AI機能組み込み、画像・音声認識、生成AIプロダクト
- 混同: モデルを作る人か、AIを組み込む人かを分解する
機械学習エンジニア
機械学習モデルを設計・学習・実装し、本番システムで動かす人です。
- 技術: PyTorch、TensorFlow、scikit-learn、MLOps、Docker
- 案件: レコメンド、需要予測、異常検知、画像/NLPモデル
- 混同: モデル作成と本番運用は別レベル
データサイエンティスト
ビジネス課題に対し、統計・機械学習で分析し、示唆やモデルを出す人です。
- 技術: Python、SQL、統計、機械学習、可視化
- 案件: 顧客分析、離反予測、価格最適化、需要予測分析
- 混同: 分析・示唆出しが軸で、本番実装中心とは限らない
データアナリスト
データを集計・可視化し、ビジネスの示唆を出す人。機械学習モデルは作らないことが多いです。
- 技術: SQL、Excel、Tableau、Power BI、Looker Studio
- 案件: KPI分析、ダッシュボード運用、レポーティング
- 混同: サイエンティスト案件に出すと事故りやすい
データエンジニア
データを溜める・流す・整える基盤を作る人。分析やAIが動くための土台を作ります。
- 技術: SQL、Python、BigQuery、Snowflake、Redshift、dbt、Airflow
- 案件: データ基盤、パイプライン、DWH移行、ETL/ELT
- 混同: データを使う人ではなく、作る側
BIエンジニア
BIツールでダッシュボードやレポートの仕組みを設計・構築する人です。
- 技術: Tableau、Power BI、Looker Studio、SQL、DWH連携
- 案件: BI導入、ダッシュボード構築、レポート自動化
- 混同: 見たことがある、作れる、運用できるは別
生成AI / LLMエンジニア
ChatGPT / Claude / Gemini などのLLMやAPIを活用して、チャットボット、業務支援ツール、RAG、社内文書検索などを開発する人です。
- 技術: OpenAI / Claude API、Azure OpenAI、Amazon Bedrock、Vertex AI、LangChain、LlamaIndex、ベクトルDB、Embedding
- 案件: 生成AIアプリ開発、社内文書検索、RAG構築、問い合わせ自動化、ナレッジ検索
- 混同: プロンプトを触っただけか、LLM APIを使ったか、RAGまで構築したかを分ける
主要職種 早見表（7職種）
スマホでは表を横にスクロールできます。
| 職種 | 一言でいうと | 軸 | キーになるスキル |
|---|---|---|---|
| AIエンジニア | AIを組み込む人（総称） | モデル開発〜実装 | Python＋ML/生成AI＋開発力 |
| 機械学習エンジニア | モデルを作って動かす人 | モデル開発・運用 | ML＋エンジニアリング＋MLOps |
| データサイエンティスト | 数字で示唆とモデルを出す人 | 分析・モデル | 統計＋ML＋SQL＋ビジネス理解 |
| データアナリスト | 集計・可視化で示唆を出す人 | 分析 | SQL＋BI＋統計基礎 |
| データエンジニア | 基盤・パイプラインを作る人 | 基盤 | SQL＋DWH＋ETL＋クラウド |
| BIエンジニア | 可視化の仕組みを作る人 | 可視化 | BIツール構築＋SQL |
| 生成AI / LLMエンジニア | LLMで業務アプリ・RAGを作る人 | 生成AI | LLM API＋RAG＋アプリ/API開発力 |
Figure 01 / 6職種ポジショニング（縦：つくる↔示す ／ 横：基盤↔活用）
03 / Keywords
案件キーワードと技術・ツールの地図
キーワードは丸暗記ではなく、職種や案件タイプを連想するためのグルーピングで押さえます。
案件でよく出るキーワード
スマホでは表を横にスクロールできます。
| キーワード | 営業が押さえる意味 | 連想する職種・レベル |
|---|---|---|
| Python | AI/データ領域の共通言語。ただしWeb等でも使う汎用言語 | ほぼ全職種。単体ではAIの証明にならない |
| SQL | データベースからデータを取り出す言語 | アナリスト/サイエンティスト/エンジニア全般。深さを見る |
| 統計 | データから傾向や法則を読む数学的手法 | サイエンティスト/アナリスト |
| 機械学習（ML） | データからパターンを学習し予測・分類する技術 | サイエンティスト/MLエンジニア |
| ディープラーニング（DL） | 画像・音声・言語など複雑な処理に強いMLの一分野 | MLエンジニア/AIエンジニア。専門性高め |
| 生成AI / LLM | 文章・画像などを生成するAIと、その中核の大規模言語モデル | 生成AI/LLMエンジニア |
| RAG | 社内文書等を検索してLLMに答えさせる仕組み | 生成AIエンジニア。LLM API利用より一段上 |
| プロンプト | LLMへの指示文 | 生成AI入門〜中級。単体では経験レベル低め |
| ベクトルDB / Embedding | RAGで文書を意味検索するためのDBと、文章を数値化する処理 | RAG構築経験者 |
| データ分析 / BI / ダッシュボード | 集計・解析・可視化で示唆を出す | アナリスト/BIエンジニア |
| DWH / ETL / ELT / パイプライン | データを溜め、変換し、流す処理 | データエンジニア |
| MLOps / クラウド / API | モデル運用、実行環境、システム連携 | エンジニア系全般。中身を確認する |
| Azure OpenAI | Azure上で使う企業向け生成AI。Microsoft環境と相性が強い | 生成AI/LLM（企業・Azure系） |
| Amazon Bedrock | AWS上で生成AIを使うサービス | 生成AI/LLM（AWS系） |
| Vertex AI | Google Cloud上のAI/ML基盤 | ML/生成AI（GCP系） |
| Databricks | データ分析・基盤・AI活用を束ねる統合基盤 | データエンジニア/サイエンティスト |
| Spark | 大量データの分散処理 | データエンジニア寄り |
| SageMaker | AWS上でMLモデルを作成・学習・運用 | MLエンジニア（AWS系） |
| MLflow | 機械学習モデルの実験・運用管理 | MLエンジニア / MLOps |
Pythonライブラリ
pandas / NumPy は基礎。scikit-learn 以上で機械学習の実務寄り、PyTorch / TensorFlow はディープラーニングの本格派です。
DWH・基盤
BigQuery / Snowflake / Redshift はDWH。dbt / Airflow まで出ると基盤を作る側の色が濃いです。
BIツール
Tableau / Power BI / Looker Studio は可視化の道具。閲覧しただけか、構築したかを分けます。
生成AI
OpenAI API / Claude API だけなら入門寄り。RAG、ベクトルDB、Embedding、LangChain / LlamaIndex が出ると本格的です。
Figure 02 / Python・SQL・BI・DWH・ML・生成AI・RAG の関係
Figure 03 / AI・機械学習・ディープラーニング・生成AIのざっくり関係
右：同じ生成AIでも、プロンプト → LLM API利用 → RAG構築の順に実務の深さが上がります。
04 / Phase
案件フェーズ別の見方
同じAI / データ案件でも、フェーズによって必要な人材は変わります。案件概要がどのフェーズかを先に見極めます。
調査・PoCフェーズ
技術検証、プロトタイプ、仮説検証、精度確認が中心です。
- 提案しやすい人: AI/データの知見があり、試行錯誤・検証ができる人
- 注意: PoC経験だけで本番運用までできるとは限らない
開発フェーズ
API連携、RAG構築、モデル実装、データ連携、画面/API開発が中心です。
- 提案しやすい人: AI知識に加え、Web/API/クラウド開発の経験がある人
- 注意: AIだけでなくシステム開発力も必要
本番運用フェーズ
監視、改善、障害対応、MLOps、セキュリティ、ログ管理が中心です。
- 提案しやすい人: 運用・監視・改善まで経験がある人
- 注意: モデルを作っただけの人では弱い可能性がある
分析活用フェーズ
KPI設計、BI、レポート、意思決定支援が中心です。
- 提案しやすい人: SQL、BI、分析、ビジネス部門との折衝ができる人
- 注意: 高度なMLより、業務理解・説明力が重視されることがある
まずはここだけ押さえればOK
案件概要に「AI」と書いてあっても、PoCなのか、開発なのか、本番運用なのか、分析活用なのかで提案すべき人材は変わります。まず「どのフェーズか」を読み取ってから人を当てます。
05 / Job Ticket
よくある案件パターン9種
案件概要を見たときに「これは何案件か」を即判断し、誰を出せるかを考えます。
スマホでは表を横にスクロールできます。
| 案件 | 概要で見るポイント | 提案しやすい人材 | 注意すべき人材 | 面談で確認 |
|---|---|---|---|---|
| データ分析 | 分析、示唆、レポート、KPIが中心 | SQL＋BIで集計・可視化し説明できるアナリスト | モデル開発しかない研究寄り、ExcelのみでSQLが薄い人 | データ規模、SQL頻度、報告先、示唆まで出したか |
| BIダッシュボード | Tableau、Power BI、ダッシュボード構築、可視化 | 指定BIツールでの構築経験者＋SQL | BIを見ていただけの人、指定ツール未経験者 | ツール、作成枚数、データソース、要件元、運用経験 |
| データサイエンティスト | 分析、予測、統計、機械学習、具体的なビジネス課題 | 統計・ML理解があり、業務でビジネス課題を分析した人 | BI・集計中心、Kaggleや独学のみの人 | 課題、手法、データ、精度・成果、本番に乗ったか |
| 機械学習モデル開発 | モデル開発、学習、推論、PyTorch/TensorFlow、本番組み込み | モデルを作り本番に乗せたMLエンジニア | 分析止まり、LLM APIを呼んだだけの人 | モデル設計・学習、本番運用、フレームワーク、MLOps |
| 生成AI / LLMアプリ | 生成AI、LLM、ChatGPT/Claude API、チャットボット、LangChain | LLM APIアプリ開発＋バックエンド/API開発力がある人 | プロンプトだけ、RAG必須にLLM API利用のみの人 | 何を作ったか、APIだけか/RAGまでか、本番・評価改善 |
| RAG構築 | RAG、社内文書検索、ベクトルDB、Embedding、LangChain/LlamaIndex | ベクトルDB・Embedding・検索精度調整まで経験した人 | LLM APIだけ、プロンプトだけの人 | ベクトルDB、Embedding理解、検索精度改善、データ量、運用 |
| データ基盤構築 | データ基盤、DWH、BigQuery/Snowflake/Redshift、クラウド | DWH・基盤を設計/構築/運用したデータエンジニア | 分析者、単発でツールを触っただけの人 | 一から作ったもの、DWH種類、担当範囲 |
| データパイプライン | パイプライン、ETL/ELT、Airflow、dbt、データ連携 | ETL/ELTやパイプラインを実装・運用した人 | 分析・可視化のみ、GUIで一度組んだだけの人 | データの流し方、ツール、障害対応、運用、データ量 |
| MLOps | MLOps、モデル本番運用、CI/CD、モデル監視、再学習 | デプロイ・監視・再学習の仕組みを作った人 | モデルを作っただけ、一般インフラのみの人 | 本番運用、CI/CD、コンテナ、監視・再学習、チーム規模 |
06 / Risk
AI / データ案件で営業が確認すべきリスク
AI案件は「作れるか」だけでなく、どのデータを扱い、本番利用か、責任範囲はどこまでかが重要です。
営業が確認するチェックリスト
スマホでは表を横にスクロールできます。
| 確認観点 | なぜ見るか / 何を聞くか |
|---|---|
| ✓ 扱うデータ | 顧客データ・個人情報を扱う案件か。匿名化・マスキングの有無。 |
| ✓ 機密情報とLLM | 社内文書・機密情報をLLMに投入する運用か。外部送信の可否。 |
| ✓ 利用サービス指定 | OpenAI / Claude API、Azure OpenAI、Amazon Bedrock、Vertex AI など指定があるか。 |
| ✓ PoCか本番か | 検証段階か、本番運用か。求められる品質・責任範囲が変わる。 |
| ✓ 精度と評価 | AIの回答精度や評価指標を誰が見るのか。合否基準はあるか。 |
| ✓ リスク考慮 | 誤回答、情報漏えい、著作権、ログ管理などの考慮が必要か。 |
| ✓ データ取扱い・体制 | データ取り扱いルールやセキュリティ部門との調整があるか。 |
まずはここだけ押さえればOK
AI案件は、作れるかだけでなく、どのデータを扱うか・本番利用か・責任範囲がどこまでかを確認することが重要です。「個人情報・社内文書を扱う」「本番運用」と分かったら、データ取り扱いとセキュリティを必ず確認します。
07 / Skill Sheet
スキルシートの読み方
AI / データ系のスキルシートは盛りやすいので、書かれた言葉を実態のレベルまで落とします。
Figure 04 / 「AI経験あり」は氷山の一角
AI経験あり
統計・データ分析
モデル構築（API利用と別）
本番運用・MLOps
RAG・ベクトルDB
チェックリスト 11観点
| 観点 | 確認すること |
|---|---|
| ✓ AI経験の分解 | 何をしたか、どの立場か、どこまでやったか。分析、モデル開発、API利用、PoC、本番運用を分ける。 |
| ✓ Python経験 | Pythonで何をしたか。pandas / scikit-learn / PyTorch 等のライブラリ名があるか。 |
| ✓ SQLの深さ | SELECTだけか、集計・結合・サブクエリ・ウィンドウ関数・性能設計までできるか。 |
| ✓ BIツール | 閲覧レベルか、ダッシュボード構築レベルか。作成枚数、データソース、運用有無を見る。 |
| ✓ 統計・ML理解 | 手法を知っているだけか、使って成果を出したか。評価指標まで語れるか。 |
| ✓ モデル構築とAPI利用 | 自分で学習させたモデル構築か、既存AI APIを呼んだだけかを分ける。 |
| ✓ 分析と基盤 | データを使う側か、溜める・流す土台を作る側かを分ける。 |
| ✓ Kaggle・個人学習 | 意欲・基礎力の証明にはなるが実務経験ではない。実務と同列に扱わない。 |
| ✓ RAGとLLM API | RAGはベクトルDB・Embedding・検索設計を伴う。API利用だけとは別。 |
| ✓ クラウド・Docker・Git | クラウド、Docker、Git、チーム開発経験が本番案件の裏付けになる。 |
| ✓ ビジネス側との経験 | 要件整理、報告、示唆を意思決定につなげた経験があるか。 |
混同しやすい境界
スマホでは表を横にスクロールできます。
| 対比 | 左側 | 右側 | 営業の見方 |
|---|---|---|---|
| API利用 vs モデル構築 | OpenAI API等を呼び出して使う | 自分でデータを学習させAIモデルを作る | 難易度も評価も別。AIを使ったとAIを作ったを混同しない。 |
| 分析 vs 基盤 | データを見て示唆を出す | データを溜める・流す土台を作る | 使う側か作る側かを必ず分ける。 |
| RAG vs LLM API利用 | 文書をベクトル化し検索してLLMに渡す | ChatGPT/Claude APIを呼んで回答を得る | RAG必須案件にAPI利用だけの人を出すのは事故。 |
08 / Interview
登録面談で確認する質問
スキルシートの「?」を、面談で潰します。新人はこの質問リストをそのまま使えます。
共通質問
- 直近の案件で、どんなデータを何のために扱いましたか？
- メインで担当したのはどの部分ですか？
- PoC止まりか、本番リリース・運用までいきましたか？
- 使った言語・ツール・クラウドは何ですか？
- ビジネス側とのやりとりはありましたか？
- チーム開発でしたか、何人規模でしたか？
データアナリスト
- SQLは集計・結合・ウィンドウ関数まで書けますか？
- BIツールは閲覧、構築、運用のどこまで使いましたか？
- 分析結果から示唆・提案まで出した経験はありますか？
- 扱ったデータ規模はどのくらいでしたか？
データサイエンティスト
- どんなビジネス課題を、どの統計/ML手法で解きましたか？
- モデルの精度や成果はどう評価しましたか？
- 分析止まりか、本番システムに組み込まれましたか？
- データ前処理はどこまでやりましたか？
機械学習エンジニア
- 自分でモデルを設計・学習させた経験を教えてください。
- 使ったフレームワークは何ですか？
- 本番環境にデプロイ・運用した経験はありますか？
- クラウド・Docker・CI/CDの利用経験はどの程度ですか？
データエンジニア
- どんなデータ基盤を一から構築しましたか？
- 使ったDWHは BigQuery / Snowflake / Redshift のどれですか？
- ETL/ELTやAirflow / dbtの構築経験はありますか？
- 設計・構築・運用・障害対応のどこを担当しましたか？
BIエンジニア
- どのBIツールで、どんなダッシュボードを何枚構築しましたか？
- データソースは何で、SQLは自分で書きましたか？
- 要件は誰から受け、運用・改善まで担当しましたか？
- 複数ツールの経験はありますか？
生成AI / RAG
- 生成AIで具体的に何を作りましたか？
- LLM APIを呼んだだけですか、RAGまで構築しましたか？
- RAGならベクトルDB・Embeddingは何を使いましたか？
- 検索精度をどう上げましたか？
- 本番リリースし、ユーザーが使う状態まで持っていきましたか？
09 / Level
レベル判定 △ / ○ / ◎
△はダメではなく、その記載だけでは弱い、面談で確認が必須という意味です。
スマホでは判定表を横にスクロールできます。
| 職種 | 弱い | 提案しやすい | 強く出せる |
|---|---|---|---|
| データアナリスト | Excelのみ／BI閲覧だけ／SQLは簡単なSELECTのみ | SQLで集計・結合、BIでダッシュボード構築。分析レポート作成 | 示唆・提案で意思決定に貢献。大規模データ・複数部署連携 |
| データサイエンティスト | Kaggle・独学のみ／統計やML知識のみ／集計中心でモデルなし | 業務で統計/ML分析。SQL自走、前処理〜モデル構築 | モデルが本番に乗り成果が出た。複数案件、ビジネス貢献を数字で説明 |
| 機械学習エンジニア | LLM APIを呼んだだけ／チュートリアルレベル／本番未経験 | 業務でモデルを設計・学習し本番システムに組み込み。クラウド・Docker利用 | MLOps構築、大規模・高難度モデル、チームリード |
| データエンジニア | データを使う側のみ／GUIで一度パイプライン／SQLが浅い | クラウド上でDWH・基盤を構築・運用。ETL/ELT実装。SQL強い | 基盤を一から設計。大規模データ、dbt・Airflow本格運用、障害対応・最適化 |
| BIエンジニア | BI閲覧だけ／無料ツールで簡単なグラフ／SQL未経験 | Tableau / Power BI 等でダッシュボード構築。SQLでデータソースを扱い運用 | 要件定義から運用改善まで一気通貫。複数ツール、全社BI基盤の推進 |
| 生成AI / RAG | プロンプトを試した／ChatGPT個人利用／LLM APIを一度呼んだだけ | LLM APIで業務アプリ・機能を開発。プロンプト設計、評価・改善 | RAGをベクトルDB・Embeddingまで構築。検索精度チューニング、本番運用 |
10 / Mismatch
営業がやりがちなNG提案
現場で起きやすいミスマッチを、なぜ危ないか、どう確認するかまでセットで覚えます。
スマホでは表を横にスクロールできます。
| よくあるNG提案 | なぜ危ないか | どうする |
|---|---|---|
| 「AI経験あり」だけで強く提案 | 自己申告の幅が広く、中身が伴わないことがある | 何を・どの立場で・どこまでの3軸で分解する |
| Python経験者をAIエンジニアとして提案 | PythonはWeb・自動化など汎用で、AIの証明ではない | scikit-learn / PyTorch 等と、AIで何を作ったか確認 |
| Kaggleや個人学習のみを実務AI人材として提案 | 実務の汚いデータ、調整、運用、納期の経験がない | 業務適用経験を確認。なければポテンシャル枠として正直に提案 |
| SQLとBI中心の人をデータサイエンティストとして提案 | 集計・可視化と、統計/MLによる予測は別スキル | 統計・MLの実務経験を確認。なければアナリスト案件へ |
| LLM API利用を機械学習モデル開発と混同 | AIを使ったとAIを作ったは別物 | 自分でモデルを学習・構築したか確認 |
| プロンプト経験だけでRAG構築経験ありと判断 | RAGはベクトルDB・Embedding・検索設計を伴う | ベクトルDB、Embedding、検索精度改善を確認 |
| Tableau経験だけでデータ基盤案件に提案 | BIは可視化、データ基盤は土台構築 | DWH・ETL・クラウドでの基盤構築経験を確認 |
| 分析経験者をデータエンジニア案件にそのまま提案 | 分析は使う側、エンジニアは作る側 | 基盤・パイプライン構築経験があるか確認 |
| 研究寄りAI人材を業務システム開発に確認なしで提案 | 研究と業務開発では、納期・チーム・本番運用の要求が違う | 業務システム開発、チーム開発、本番運用の経験と意向を確認 |
| PoC経験だけで本番運用フェーズの案件に強く提案 | 検証と、監視・改善・障害対応の本番運用は別フェーズ | 運用・監視・MLOps・セキュリティの経験を確認 |
| 個人情報・社内文書を扱う案件で取り扱いを確認しない | 情報漏えい・外部送信・著作権・ログ管理のリスクがある | 扱うデータ、利用サービス指定、セキュリティ部門調整を確認 |
11 / Practice
案件読解演習
案件と候補者を読み、提案可否、理由、追加確認を考えます。
SQL・Tableau実務が必須を満たすか
案件概要 / 必須・尚可
- 大手ECのマーケティング部門
- 購買データ分析、KPIダッシュボード運用
- 必須: SQL、Tableau構築、ビジネス側への報告
- 尚可: 統計基礎、Python（pandas）
候補者
- 事業会社で2年
- SQLで売上集計
- Tableauで月次KPIダッシュボードを運用
- マーケ担当に報告。Pythonは独学レベル
問い: この候補者を提案できるか。追加確認は何か。
回答・判断理由・追加確認を見る
○（提案できる）。必須のSQL、Tableau構築、報告を実務で満たします。Pythonは尚可なので弱くても致命的ではありません。Tableauの構築規模、SQLの複雑度、施策提案まで踏み込んだかを確認します。
LLM API利用をMLモデル開発とみなせるか
案件概要 / 必須・尚可
- 製造業の需要予測モデル開発
- 本番システムに組み込み・運用
- 必須: PythonでMLモデル開発、デプロイ、クラウド・Docker
- 尚可: MLOps、製造業ドメイン知識
候補者
- Web系エンジニア3年
- ChatGPT APIで社内チャットボットを個人試作
- 機械学習モデルの構築・本番運用経験なし
問い: このまま提案できるか。別案件なら何を検討するか。
回答・判断理由・追加確認を見る
×（このままでは提案不可）。必須の機械学習モデル開発と本番運用がありません。LLM API利用は需要予測モデル開発とは別物です。機械学習モデルの学習・構築経験を確認し、なければ生成AIアプリ開発など別案件を検討します。
OpenAI API経験だけでRAG必須に出せるか
案件概要 / 必須・尚可
- 社内文書検索の生成AIアシスタント
- RAG構築・精度改善が中心
- 必須: RAG、ベクトルDB・Embedding、LLM API、Python、本番運用
- 尚可: LangChain / LlamaIndex
候補者
- バックエンドエンジニア4年
- OpenAI APIで要約機能を実装
- ベクトルDBやEmbeddingは名前のみ、構築経験なし
問い: 提案可否と、面談で確認すべき点は何か。
回答・判断理由・追加確認を見る
△（要確認。このままでは弱い）。LLM API利用はありますが、RAGの核であるベクトルDB、Embedding、検索が未経験です。RAG理解度、自習経験、学習意欲、顧客がポテンシャル採用を許容するかを確認します。
BigQueryを使う経験を基盤構築とみなせるか
案件概要 / 必須・尚可
- BigQueryでデータ基盤を構築
- 各システムからETLで集約、dbtで変換管理
- 必須: DWH構築、ETL/ELT、高度SQL、dbt or Airflow
- 尚可: データモデリング、Terraform等のIaC
候補者
- データアナリスト3年
- BigQueryで分析クエリは日常的に書く
- 基盤構築やETL/dbtでの整備は未経験
問い: 基盤構築案件として提案できるか。何を確認するか。
回答・判断理由・追加確認を見る
×〜△（基盤構築としては不可、要確認）。BigQueryを使う経験はありますが、作る・整える経験がありません。ETL/dbt/パイプライン構築、基盤設計への関与、本人がエンジニア側へ移行したい意向を確認します。
PoC経験だけで本番運用案件に出せるか
案件概要 / 必須・尚可
- 生成AIチャットの本番運用・改善
- 監視、障害対応、ログ管理、セキュリティ対応
- 必須: 本番運用・監視・改善、クラウド、MLOpsの素養
- 尚可: RAG運用、セキュリティ部門との調整経験
候補者
- 事業会社で生成AIのPoCを担当
- 精度検証・プロトタイプ作成は経験あり
- 本番運用・監視・障害対応は未経験
問い: 本番運用案件に提案できるか。何を確認するか。
回答・判断理由・追加確認を見る
△〜×（このままでは弱い）。PoC経験と本番運用は別フェーズです。監視・改善・障害対応・ログ管理・セキュリティの経験を確認し、なければ調査・PoCフェーズの案件を検討します。扱うデータや本番の責任範囲への理解も合わせて確認します。
12 / Proposal
提案コメント例
提案コメントは、過大表現せず、強みと確認済みの事実で刺すことが重要です。
提案時の注意点
- 誇張せず、確認済みの事実を書く
- 「経験があります」で止めず、何をどこまで担当したかを書く
- 分析・モデル・基盤・生成AIのどの軸かを明確にする
- 不足がある場合は、ポテンシャルやキャッチアップ前提として正直に補足する
- PoCか本番運用か、扱うデータ（個人情報・社内文書）とセキュリティ前提を明確にする
- 顧客にそのまま送れる粒度で、強みと案件適合理由を添える
13 / Check
確認テスト
選択式、○×、記述、ケース判断を混在させています。解いてから解説を確認します。
1. 「データを集計・可視化し、現状の示唆を出すことが中心で、機械学習モデルは作らないことが多い」職種は？
答え: B. データアナリスト
集計・可視化・示唆が中心なのがデータアナリスト。モデルで予測まで踏み込むのがサイエンティストです。
2. 「Python経験あり」と書いてあれば、AIエンジニアとして提案してよい。○か×か。
答え: ×
PythonはWeb・自動化等の汎用言語です。何を作ったか、ライブラリや成果物を確認します。
3. ChatGPT APIでチャット機能を作った経験は、機械学習モデル開発経験と同等とみなせる。○か×か。
答え: ×
API利用は「AIを使った」、モデル開発は「AIを作った」。難易度も評価も別物です。
4. RAG構築経験者かを見るとき、特に注目すべきキーワードは？
答え: B. ベクトルDB・Embedding
RAGはベクトルDB・Embedding・検索が核です。LLM API利用だけならRAG経験者とは言いにくいです。
5. データアナリストを、そのままデータエンジニア案件に提案してよい。○か×か。
答え: ×
分析は使う側、エンジニアは作る側です。基盤構築経験を確認します。
6. データエンジニア案件を最も強く連想させるキーワードの組み合わせは？
答え: C. BigQuery・dbt・Airflow・ETL
DWH、dbt、Airflow、ETLはデータ基盤/パイプラインの領域です。
7. スキルシートに「AI経験あり」とだけ書かれていた。面談で何を確認すべきか3点挙げよ。
解答例:
何をしたか（分析／モデル開発／API利用）、どの立場か（メイン担当か一員か）、どこまでやったか（検証止まりか本番運用か）。
8. 「Tableau経験あり」と書く2人の候補者を、どう区別して評価すべきか。
解答例:
閲覧しただけか、ダッシュボードを構築・運用したかで価値が大きく異なります。構築枚数、データソース、SQLの有無、運用経験を確認します。
9. RAG必須案件に、OpenAI APIで要約機能を作ったがベクトルDB未経験の候補者がいる。どう対応するか。
解答例:
そのままRAG経験者として強く提案しません。RAG理解度、ベクトルDBの自習状況、学習意欲、顧客のポテンシャル許容を確認します。
10. Kaggle上位入賞、独学中、実務AI開発なしの候補者を、実務ML案件に提案してよいか。
答え: 基本は不可
Kaggle・独学は基礎力の証明ですが実務経験ではありません。ポテンシャル枠なら正直に提案します。
11. データサイエンティスト案件で最も提案しやすいのは？
A：SQL/Tableau集計2年
B：統計・MLで離反予測モデル構築
C：ChatGPTを個人利用
D：BigQuery基盤構築
答え: B
統計・MLでモデルを作り課題を解いた実務経験が要件に合います。Aは集計中心、Dは基盤側、Cは対象外です。
12. 生成AIのPoC（精度検証）経験がある候補者を、本番運用・監視まで必須の案件に強く提案してよい。○か×か。
答え: ×
PoCと本番運用は別フェーズです。監視・改善・障害対応・MLOps・セキュリティの経験を確認し、なければ強く提案しません。
13. 社内文書をLLMで検索する案件（RAG）。営業が確認すべきリスク観点を2つ挙げよ。
解答例:
機密情報を外部API（OpenAI等）へ送る運用か、利用サービスの指定（Azure OpenAI / Bedrock / Vertex AI 等）があるか、データ取り扱いルールやセキュリティ部門との調整、PoCか本番運用か、など。あわせて、ベクトルDB・Embedding・検索精度改善までの経験も確認します。
14 / Summary
まとめ
技術を語れる必要はありません。最終的に「この人を、どの案件に、どの強さで提案できるか」を自分の言葉で説明できる状態を目指します。正しく見極めて正しくつなぐことが、営業としての価値になります。
案件概要
AI / データはひとつの職種ではありません。分析・モデル開発・基盤・生成AIの軸と、PoC/開発/運用/分析のフェーズで読み分ける。
スキルシート
「AI経験あり」「Python経験あり」を言葉のまま信じず、何を・どの立場で・どこまでやったかに分解する。
面談
△ / ○ / ◎ の目安に当て、弱い記載は面談で確認する。わからないまま提案しない。
提案
分析と基盤、使ったと作った、LLM API利用とRAG構築を混同しない。誇張せず、確認済みの事実と強みで書く。
コメント例