AIエンジニア
AIエンジニアは、最も重要な構成要素を自分では学習させていないプロダクトを構築します。仕事の中身は、検索と根拠づけ、コンテキストの設計、評価の仕組み、ガードレール、そして足元のモデルが変わり続けるなかで応答時間と費用を予算内に収めることです。本ガイドでは、この職種が担う範囲、本当に適した採用となるのはどのような場合か、そして流暢さと実力をどう見分けるかを整理します。
AIエンジニアは何をする職種ですか
AIエンジニアは、振る舞いが基盤モデルに依存するソフトウェア製品を構築します。多くの場合、提供事業者のAPI経由で利用する大規模言語モデル、あるいは自社でホストするオープンウェイトのモデルです。担当範囲は、適切な文脈を取り出して出力をそれに根拠づけること、モデルへ送る指示を設計しバージョン管理すること、変更が本当に改善だったかを示す評価の仕組みを構築すること、操作された出力や安全でない出力に対するガードレールを設けること、そして実際のトラフィックが来た後に応答時間と費用を制御することです。確率的な構成要素に対して適用されるソフトウェアエンジニアリングであり、モデルの学習を伴うことはほとんどありません。
この職種を定義しているのは、エンジニアが内部を完全には確かめられない依存先の存在です。モデルにはバージョンがあり、価格があり、レート制限があり、提供事業者が更新を出せば変化する挙動があります。したがって工数のほぼすべては、その周囲に向かいます。コンテキストウィンドウに何を置くか、返ってきたものをどう扱うか、応答が誤っていたときシステムが何をするか、そしてそれをどうやって知るかです。
難しさが集中するのは計測です。デモは短時間で組み上がります。選び抜いた入力を与えれば、ほとんどどんな構成でも有能に見えるからです。難しいのは、二つ目の版が一つ目より良いと示すことです。二つの応答は、言い回しがまったく違っていて同じくらい正しいこともあれば、ほぼ同一なのに肝心の一点だけ食い違っていることもあります。回帰用のデータセット、採点基準、人手のラベルと突き合わせた自動採点、検索と生成を分けたスコアが通常の道具であり、これらを持たないチームは印象で出荷しています。
障害の現れ方も、従来のソフトウェアとは異なります。どの出典にも支えのない断定が返ってきます。関連するように読めて実際は関係のない文章が検索で返ります。利用者が与えた内容の中に紛れた指示がモデルへ届きます。提供事業者側の変更の後、エラーも警報も出ないまま品質が漂います。費用が、負荷試験では現れない形で会話の長さに比例して膨らみます。いずれも、あらかじめ設計しておくか、顧客に発見されるかのどちらかです。
この能力が必要になる場面
基盤モデルを使った機能は、たいてい誰かが週末に組み上げたものとして始まり、その週末版は本当に印象的です。そこから顧客が頼れるものまでの距離こそ、この職種が価値を持つ場所です。
試作をプロダクトにしなければならない
デモは、それに合わせてつくられた入力は処理でき、それ以外では品質が落ちます。頼れるものにするには、入力の範囲を定め、その外側で何が起きるかを決め、誰かの異論に耐える形で品質を数値にする必要があります。
回答を自社の資料に根拠づける必要がある
モデルが学習中に取り込んだ内容ではなく、社内文書、問い合わせ履歴、契約書、製品データから回答を返す必要があります。そこには文書の分割方針、埋め込みの選定、語彙検索とベクトル検索の併用、再ランク付け、鮮度、そして閲覧権限のない文書を利用者が取り出せないという要件が伴います。
システムが良くなっているか誰も言えない
手作業でいくつか確かめて良さそうだったから、という理由で変更が出荷されています。本番の基盤モデル機能で最もよくある状態であり、以降のすべての判断を当て推量に変えます。その機能を続けるべきかどうかという判断も含めてです。
信頼できないテキストがモデルへ届いている
アップロードされたファイル、受信メール、顧客からのメッセージ、収集したページ。取り出した内容が指示を含みうるようになった時点で、問いは「モデルは何をせよと言われたか」から「モデルは何を行ってよいのか」に変わります。
費用が利用量より速く伸びている
再試行、伸び続ける会話履歴、大きすぎるコンテキスト、キャッシュの不在、そしてすべてのリクエストが最大のモデルへ流れている状態です。確率的な機能の費用曲線は、チームが見慣れた費用曲線ではありません。
依存していたモデルのバージョンが提供終了になった
挙動がどこにも仕様として記述されていない構成要素に、移行の期限が来ます。回帰用のテスト群がなければ、新しいバージョンが何を変えたかを知る方法は、公開してみることだけになります。
中核となる能力
検索の設計
分割の境界、埋め込みの選定、語彙検索とベクトル検索の併用、再ランク付け、メタデータによる絞り込みです。「モデルが間違えた」という報告の多くは検索の失敗であり、その二つを切り分けることが最初の診断の一手になります。
根拠づけと出典表示
回答を、それを支えた文章まで辿れるようにし、支える文章が存在しない場合に何が起きるかを設計することです。答えを作り出すシステムより、答えられないと述べるシステムのほうが通常は価値があり、その振る舞いは要望するものではなく作り込むものです。
コンテキストの構成
有限のウィンドウを何が占めるかを決めることです。指示、取り出した根拠、会話履歴、ツールの実行結果、出力の形式。指示の言い回しは目に見える部分にすぎず、実質はウィンドウの配分と並び順の設計にあります。
評価の仕組み
実際の入力を反映した吟味済みのデータ、二人目が採点しても同じになる基準、人手のラベルと照合された自動採点、そして指示の変更とリリースの間に立つ回帰テストです。
ツール利用とオーケストレーション
関数呼び出し、複数段階のループ、停止条件、再試行の挙動、そして外部に影響を与える段階での冪等性です。止まらないループと繰り返される操作が、この領域の典型的な欠陥です。
ガードレールと悪用への耐性
モデルの出力を信頼できない入力として扱い、影響の大きい処理へ渡す前にスキーマで検証し、モデルが断ることに頼るのではなく到達できるツールそのものを制限することです。
応答時間と費用の制御
ストリーミング、キャッシュ、単純なリクエストの小さなモデルへの振り分け、コンテキストの削減、そして呼び出し単位ではなく完了した処理単位での費用把握です。請求額と連動するのは後者の数字です。
構造化された出力
スキーマで制約した生成、検証、失敗時の修復、そして境界での確定的な解析です。これによって、下流のコードが明日は違う解釈をしうる文章の読み取りを任されることがなくなります。
公開後の監視
取り出した文脈を含む完全なトレース、抽出した応答に対する定期的な人手の確認、エラーだけでなく品質の変動に対する警報、そして利用者から報告された失敗を評価データへ戻す経路です。
境界におけるデータの扱い
何が自社の管理領域の外へ出るのか、提供事業者が何を保持するのか、送信前に何を伏せるのか、そして複数の顧客が共有するインデックスでテナントの分離をどう強制するのかを正確に把握していることです。
技術エコシステム
AIエンジニアリングで一般的に用いられている技術を以下に挙げます。これは業界で実践されている領域全体の姿を示すものであり、特定のエンジニアのスキルを示すものではありません。この分野のフレームワークは毎年のように入れ替わるため、直近の案件に何が挙がっているかより、検索、コンテキスト、計測についてどう考えるかのほうがはるかに有用な手がかりになります。
言語・実行環境
- Python
- TypeScript
- Go
モデルの利用とホスティング
- OpenAI API
- Anthropic API
- Google Vertex AI
- Amazon Bedrock
- vLLM
- Ollama
オーケストレーションフレームワーク
- LangChain
- LlamaIndex
- Semantic Kernel
- Haystack
- DSPy
検索と全文検索
- pgvector
- Pinecone
- Qdrant
- Weaviate
- Elasticsearch
- OpenSearch
評価とトレーシング
- Ragas
- DeepEval
- promptfoo
- LangSmith
- Langfuse
- OpenTelemetry
検証とガードレール
- Pydantic
- Instructor
- Guardrails AI
- NeMo Guardrails
- JSON Schema
アプリケーション層
- FastAPI
- Next.js
- Vercel AI SDK
- Redis
- Celery
How this role works with your team
Engineers work inside your team, on your priorities, to your standards. You direct the work; Talent.ID carries the employment. The division below is the whole arrangement.
You keep
- プロダクト
- 事業の優先順位
- ロードマップ
- アーキテクチャ
- スプリントの優先順位
- エンジニアリング標準
- 日々の技術的な協働
Talent.ID handles
- 雇用関係
- 給与支払い
- 従業員福利厚生
- タレント管理
- 継続的な従業員関係
採用時に見るべき点
基盤モデルの領域は、流暢な説明を引き寄せます。語彙は公開されており、デモは短時間ででき、誤った回答が有料の顧客に届いた経験がなくても、検索やエージェントについて自信を持って語ることはできます。この二つを最も速く分けるのは評価です。唯一、暗唱では答えられない部分だからです。
評価に対する規律
この分野で最も多くを教えてくれる問いは、その変更が効いたとどうやって知ったのかです。データセット、その用例の出どころ、件数、誰がどの基準で採点したかを尋ねてください。ここでの曖昧さは説明力の問題ではなく、たいてい計測が存在しなかったことを意味します。
- 苦情が来てからではなく、変更の前に評価データを整えている
- 自動採点を人手の採点とどう突き合わせたかを説明できる
- 検索と生成を、ひとつの数字にまとめず別々に採点している
- 指示やモデルのバージョンを出す前に、回帰テストを実行している
検索の品質
そもそも正しい根拠が見つかっていたことを、どう確かめたかを尋ねてください。この種のシステムを実際に直したことのあるエンジニアは、指示より先に取り出された文章を見にいきます。デモしかつくったことのないエンジニアは、まず指示を書き直し、そのまま書き直し続けます。
- 正しい出典が返却された集合に含まれているかを計測している
- 勘ではなく根拠に基づいて分割方針を変え、再ランク付けを加えている
- 応答ではなく検索の時点でアクセス権限を強制している
- 検索という構成そのものが不適切だった事例を説明できる
根拠づけと正直な失敗
答えるだけの根拠がないときにシステムが何をするかは、すべてが揃っているときの挙動より多くを教えてくれます。商用の場面では、自信に満ちた作り話は拒否よりほぼ常に悪く、これを内面化しているかどうかで候補者は明確に分かれます。
- 回答に足る情報がない場合の経路を、明示的に設計している
- 出典が、その主張を本当に支える文章に解決される
- 根拠づけの度合いを、主張するのではなく計測している
- 支えはないがもっともらしい回答を、障害として扱うに値する欠陥と見なす
攻撃を想定した思考
自分で書いたのではない内容を読むシステムには、必ずインジェクションの面があります。弱い回答は、遭遇した指示を無視せよとモデルに告げる長い指示文です。強い回答はモデルにできることを制限し、説得しても攻撃者が何も得られない状態をつくります。
- 取り出したテキストと利用者が与えたテキストを、既定で敵対的として扱う
- 読み取りだけの能力と、外部に影響を与える能力を分離している
- ツール、問い合わせ、送信先へ届く前に出力を検証している
- 指示の言い回しをセキュリティ上の制御手段として当てにしていない
実トラフィック下での応答時間と費用
その機能は完了した処理あたりいくらかかるのか、検索と再ランク付けを含めた応答時間の九十五パーセンタイルはどれくらいかを尋ねてください。本番を動かしてきた候補者は両方をおおよそ把握しており、そうでない候補者はトークン単価を答えがちです。
- 呼び出し単位ではなく、成功した成果単位で費用を考えている
- 処理の一部を、より小さい経路やキャッシュされた経路へ振り分けたことがある
- 最初のトークンまでの時間だけでなく、端から端までの応答時間を計測している
- 費用を下げたうえで、品質が保たれたことを示している
公開後の監視
興味深いのは、想定していなかった問題をどうやって知ったかです。定期的に抽出して人が確認する仕組み、実際に送られたコンテキストを記録するトレース、そして提供事業者側の変更が何も失敗させずに挙動を変えた事例を探してください。
- 最終的な応答だけでなく、送信したコンテキスト全体を記録している
- 稼働中の出力を、決まった頻度で抽出して確認している
- エラーを伴わない品質の低下を捕まえた経験がある
- 報告された失敗を評価データへ戻している
モデルを使う場所についての抑制
優れた候補者は、モデル呼び出しを追加したのと同じくらいの頻度で削除しています。ルール、分類器、通常のコードのほうが適していると判断した場面と、その決め手を尋ねてください。
- 生成に頼っていた段階を、確定的なコードに置き換えたことがある
- 誤りの代償の大きさゆえに、この方式を退けた作業を挙げられる
- 足りるのであれば、小さく特化したモデルも検討する
- 構成を提案する前に、その出力がどの判断に使われるのかを尋ねる
確認しておきたい面接質問
御社の採用プロセスの参考として、使いやすい形でお役立てください。評価も結論も御社のものです。以下は、この分野で有用な答えが得られやすい問いを並べたもので、多くを読んできた人よりも、この種のシステムを実際に動かし続けてきた人から深い答えが返ってきます。
直近の変更でシステムが良くなったことを、どうやって知りましたか。
What a strong answer shows
この分野で最も予測力のある問いです。データセットの出どころ、その規模、採点の基準、誰が適用したか、そしてその結果によって、気に入っていた変更を取り下げたことがあるかを聞いてください。
顧客から、自信に満ちた誤った回答が返ったと報告がありました。切り分けを順番に説明してください。
What a strong answer shows
処理を分解できるかどうかです。優れた回答はトレースを取り出し、指示に触れる前に何が取り出されたかを確認し、根拠が存在しなかったのか、存在したが取り出されなかったのか、取り出されたが無視されたのか、取り出されて誤読されたのかを切り分けます。
利用者がアップロードした文書を取り込むプロダクトです。そのひとつに、モデル宛ての文章が含まれていました。何が起きますか。
What a strong answer shows
インジェクションへの意識と、より重要な点として、その防御が能力の境界なのか説得力のある指示なのかが分かります。試行を重ねる攻撃者に耐えるのは前者だけです。
検索は関連しそうな文章を返しているのに、回答は依然として誤っています。どこを見ますか。
What a strong answer shows
既定の設定を超えた深さです。答えを分断している分割の境界、語彙の重なりを欠いた意味的な類似、再ランク付けの不在、古い文書、あるいはそもそも答えを含まないコーパスといった論点が出てくるはずです。
公開後、利用量は二倍なのに費用は三倍になりました。どう調査しますか。
What a strong answer shows
費用に対する理解です。積み上がった会話履歴、表に出ない再試行、リリースのたびに膨らんだコンテキスト、上限のないツールのループ、そしてトークン単位ではなく処理単位の費用把握を見てください。
依存しているモデルのバージョンが提供終了になります。移行計画はどうなりますか。
What a strong answer shows
回帰テストが存在するかどうかです。確かな回答は、取り置いたデータセットに対して新しいバージョンを実行し、分類ごとにスコアを比較し、どの指示が変更の影響を受けやすいかを、トラフィックを動かす前に特定します。
言語モデルは適した道具ではないと、関係者に伝えたことはありますか。
What a strong answer shows
判断力と独立性です。優れた回答は、失敗の代償、応答時間の制約、監査可能性の要件、あるいは単純に確定的であることが求められたために従来型の手法が正しかった、具体的な作業を挙げます。
どれも関連して見えて、ウィンドウは有限です。何を入れるかをどう決めますか。
What a strong answer shows
コンテキストを、配分方針を伴う予算として扱っているかが分かります。並び順の影響、履歴の圧縮、コンテキストを増やしても常に良くなるとは限らないと確かめた形跡、そして現在の配分に計測上の根拠があるかを見てください。
What this looks like in practice
A hypothetical scenario, written to show how the working model applies. It does not describe a Talent.ID client or a completed project.
- Challenge
- あるプロダクトチームが、社内文書から質問に答えるアシスタントを公開しました。デモではよく動きますが、実際の顧客の資料に対しては挙動が安定せず、サポートは誤った回答を転送し始めています。そして先月の変更が良くなったのか悪くなったのかを、計測がなかったために誰も述べられません。
- Approach
- 増強された開発力は、チームが既に行っているやり方に加わります。リポジトリの規約、コードレビュー、リリース手順、そして定めてあるアーキテクチャの方向性です。プロダクトの判断と技術上の決定権は社内のエンジニアが持ち続け、増強分は同じスプリントの中で評価、検索、監視の作業を引き受けます。
- What this adds to the team
- チームは、プロダクトとアーキテクチャの所有権を保ったまま開発の余力を得ます。アシスタントが何をすべきか、公開前にどの水準を満たすべきかは、その結果に責任を負う人たちの判断であり続けます。
Related disciplines
Frequently asked questions
- AIエンジニアと機械学習エンジニアの違いは何ですか。
- AIエンジニアは他所でつくられたモデルの周囲を構築し、機械学習エンジニアはモデルそのものをつくり、維持します。前者は検索、コンテキスト、評価、ガードレール、そして稼働中のプロダクトの挙動に時間を使い、後者は特徴量、学習パイプライン、推論の基盤、ドリフト、再学習に時間を使います。提供事業者の基盤モデルを組み込むチームが求めるのは前者です。自社データで学習したモデルが競争力の源泉であるチームが求めるのは後者です。
- AIエンジニアはモデルを学習させる必要がありますか。
- 通常は必要ありません。ファインチューニングが登場することはありますが、多くは知識の追加ではなく出力形式や口調の調整のためで、検索とコンテキストの設計をやり尽くした後に検討されるのが一般的です。実際の要件が自社データで学習したモデルであるなら、それは道具立ての異なる別の領域であり、この肩書きで採用すると双方にとって望ましくない食い違いが生じます。
- プロンプトエンジニアリングは独立した職種ですか。
- 単独の職種としては、本番環境との接触をほとんど生き延びません。指示の言い回しは、検索、コンテキストの構成、評価、ガードレール、監視、費用管理と並ぶひとつの成果物にすぎず、しかも他のどれかがきちんと直されたときに最も書き直される可能性が高い成果物です。実務のすべてが言い回しである人は、興味深い問題がアーキテクチャの問題になった時点で行き詰まります。
- この職種で評価がそこまで重要なのはなぜですか。
- それがなければ、改善と単なる変更を区別できないからです。従来のソフトウェアは通るか落ちるかのテストを与えてくれますが、確率的な構成要素が与えるのは「違う応答」であり、違いは方向ではありません。評価の仕組みを持たないチームは、誰も正当化できない調整を積み上げ、やがてその機能が半年前より良くなっているのかどうかにも答えられなくなります。
- バックエンドエンジニアはこの仕事へ移れますか。
- よくあることで、成功しやすい転向のひとつです。持ち越せる部分は大きく、API設計、応答時間の予算、キャッシュ、キューイング、可観測性、障害処理がシステムの大半を占めます。新たに身につける必要があるのは、再現性のない依存先を本当の意味で許容することと、振る舞いをテストで断定するのではなく統計的に計測する習慣です。
- コンテキストウィンドウが非常に大きくなった今も、検索は必要ですか。
- 多くのプロダクトでは必要です。ウィンドウが大きくても、どの文書がその主張を支えたのかには答えられず、誰が何を見てよいかを強制することもできず、含めると決めたすべてに比例して費用と応答時間が伸びることを止められません。検索は依然として、出典、権限、経済性のための手段であり、これらの要件はウィンドウが広がっても消えません。
- AIエンジニアは既存のエンジニアリングチームとどのように働きますか。
- 開発チームの増強という形では、方向づけは御社のものです。御社のアーキテクチャ、コードレビュー、リリースの基準、そしてスプリントが向いている先が前提になり、日々の技術的な協働の相手は御社のエンジニアです。日々の開発の優先順位や技術的な判断はお客様のチームが管理し、Talent.IDは雇用に関する責任を担います。雇用関係、給与支払い、従業員福利厚生、タレント管理、そして継続的な従業員関係です。
Tell us what your team needs
Describe the gap — the work, the stack, the way your team runs — and we will tell you what we can support. If it is not something we can help with, we will say so.