採用 · August 2, 2026 · 約10分
AIエージェントエンジニアの求人票テンプレート(2026年版)
2026年版・無料のAIエージェントエンジニア求人票テンプレート:コピペ可能な職責・要件・他社テンプレートが省いているAIフルーエンシーセクション・評価すべき能力を網羅。
← 「採用の5つのピラー:アセスメントが測定するもの」の一部
目次
このページは、2年前にはほぼ存在しなかった職種の求人を開こうとするエンジニアリングリーダーやリクルーターのためのものです — そして、応募者の半数が自分を同じように表現していることにすでに気づいているあなたのために。AIエージェントエンジニアは、モデルが多段階にわたって動作するシステムを構築します — 計画を立て、ツールを呼び出し、ハンドオフし、そして自らのミスから回復する。一度答えて止まるのではありません。この求人票を書くのは、3つの理由が重なって本当に難しいのです。職種名が新しいため、参照できる確立された定型文がありません。誰もが手を伸ばす言葉 — 「エージェント型」— は2026年の履歴書で最も乱用されているキーワードになっているため、本物を選び取れる記述が必要です。そして、この職種はあなたの組織の中で信頼性担当に近い、居場所が曖昧な場所にいます — 本番のエージェントは、洗練された帽子をかぶった信頼性の問題に過ぎないからです。通常のバックエンドでは起こらない形でエージェントが失敗し始めたとき、それ以前ではなく、そのときにこの採用が必要です。以下は、コピペできるAIエージェントエンジニア求人票テンプレートと、競合他社のテンプレートがすべて省いているセクションです — この人物のAIフルーエンシーへの期待と、各要件の背景にある評価可能な能力について。
AIエージェントエンジニア求人票テンプレート
以下のセクションをコピーし、角括弧内のプレースホルダーを自社の内容に置き換えてください。候補者を評価する仕様書として使えるよう、テクノロジーのウィッシュリストではなく、テスト可能な形で書かれています。AIフルーエンシーセクションはそのまま残してください — このセクションが、あらゆる競合テンプレートとの違いを生む部分です。
ロール概要
[会社名]は、[プロダクトまたはワークフロー]を支える自律システムを設計・構築・運用するAIエージェントエンジニアを採用します。ループで実行されるエージェント — 計画、ツール呼び出し、ハンドオフ、障害回復 — を所有し、デモがうまくいったときだけでなく、ループが誤動作したときに何が起きるかについても責任を持っていただきます。[信頼性/プラットフォーム/応用AI]チームと連携し、[マネージャー名]のもとで、エージェントを本番環境で境界が明確で、オブザーバブルで、コスト効率よく動かすミッションを担います。
職責
- エージェントのオーケストレーションループを設計する — 計画の立て方、ツールを呼び出すタイミング、完了の判断方法、そして永遠に実行し続けないための制御。
- ツールと権限の設計でブラストラディウスを限定する — 自信を持ちながら誤ったエージェントがレコードを参照できても、データを削除したり、顧客にメッセージを送ったり、上限を超えて支出できないようにする。
- エージェントとサブエージェント間、エージェントと人間のハンドオフを設計し、各側が何に責任を持つかの明確なコントラクトを定義する。
- 障害回復を構築する — バックオフするリトライ、失敗したステップが全体を最初からやり直さないためのチェックポイント、そして静かにではなく大きく失敗するデッドエンド。
- 全実行に対してステップレベルのトレース(意思決定、ツール呼び出し、結果)を計装し、症状から数ステップ上流にある根本原因を発見可能にする。
- 多段階タスクの評価ハーネスを構築し、エージェントが正しい結果に到達したか、妥当な理由でそこに至ったかを、多数の実行にわたって判断する。
- トークンバジェット、ステップ制限、ループ検出でコストを管理し、静かに費用を燃やすリトライの支出カーブを監視する。
- 本番での非決定論的な障害をデバッグし、実行が崩れた場所の上流に修正を入れる。
- エージェントが誤った選択であり、単純な決定論的ワークフローのほうが安価で安全な場面について、チームに助言する。
要件
- 本番環境で自律エージェントを出荷・運用した実証済みの経験 — デモではなく、実トラフィックに対してループが実行され、少なくとも一度は自ら診断しなければならない形で失敗したもの。
- オーケストレーションループ設計への精通 — 計画立案、ツール呼び出し、終了条件、ループ制御とドリフト制御。
- ツールと権限設計の実践経験 — 最小権限アクセス、サンドボックス実行、不可逆なアクションの人間へのルーティング。
- 単一レスポンスの採点だけでなく、多段階動作の評価ハーネスを構築した経験。
- 非決定論的システムに対する強いオブザーバビリティ直感 — トレーシング、断続的な障害の再現、症状から遡っての実行読み解き。
- コストと信頼性エンジニアリングの判断力 — ループが自らのミスを増幅しうる、この職種のシステムエンジニアリング的側面への適用。
- トレードオフについての明確な推論 — ワークフローで十分な場面でエージェント構築に反論できる規律を含む。
あると望ましい経験
- 予測不能な負荷のかかる本番システムのオンコールや信頼性の所有経験。
- マルチエージェントのハンドオフパターンと人間参加型のエスカレーション設計の経験。
- エージェントの意思決定に影響する検索や長文コンテキスト入力の失敗モードへの精通。
- 失敗したエージェントとそこから何を変えたかについての公開されたレポート、ポストモーテム、または登壇発表。
AIフルーエンシーへの期待
このロールはメタです — 担当者は毎日AIを使って構築するため、自身のAIフルーエンシーはサイドスキルではなく職務の一部です。明示的に記載してください。
- ドリフト下でのモデル出力品質を判断する — もっともらしく見える結果が数ステップ下流で問題になる前に誤りを認識し、バージョン間でモデルの振る舞いが変化したことを検知する。
- 非決定論的な振る舞いに対するガードレールを設計する — 制限された権限、検証ステップ、不可逆なアクションへの人間チェックポイント。
- 再現しない障害をデバッグする — クラッシュを遅延指標として扱い、トレースを実際の原因まで上流に読む。
- 作業中はAIツールに賢く委任し、自信ある回答を信頼するのではなく、実際のシステムに照らして出力を検証する。
- モデルの選択、コスト、レイテンシーをリーダーボードのランキングではなくエンジニアリングのトレードオフとして推論する。
待遇
[会社名]は[報酬レンジ/バンドのプレースホルダー]、[株式]、[福利厚生の概要]を提供します。[範囲]を[自律性のレベル]で所有し、[チーム/スタック]と働き、[学習予算、オンコール体制、リモートまたはハイブリッドポリシー]を享受します。ここに真の差別化要素を加えてください — 新しい領域の実質的なオーナーシップは、この候補者にとって特典リストよりもはるかに価値があります。
上記のAIフルーエンシーセクションは、現在フィールドのどの求人票テンプレートにも含まれていない部分です — 確認済みです。モデル出力の判断と非決定論の設計に丸一日を費やすロールで、これを省略することは仕事そのものを省略することです。そのまま残し、候補者が評価されうる形で各箇条を記述してください。
このテンプレートはどう適応しますか?
シニアリティのダイヤルは「運用した」という言葉の比重で調整します。シニア採用は、稼働中のエージェントを境界設定・計装し、それを証明できる人物です。ミドルレベルはメンターのもとでループを構築し、近くにメンターがいる状態で信頼性を所有する準備ができた人物です。何を削っても評価ハーネスとブラストラディウスに関する箇条は残してください — それがこのロールの骨格です。
最初のエージェント機能を出荷しているスタートアップなら、マルチエージェントのハンドオフとオンコールの要件を削り、強いAIエンジニアまたは判断力のあるバックエンドエンジニアで今は賄えると正直に記載しましょう。本番ツールに対してエージェントを実行しているエンタープライズなら、サンドボックス化、権限設計、監査証跡の箇条はあると望ましいではなく必須になります。いずれにしても、求人票の書き方が論じるように、観察可能な行動を軸に記述してください — 求人票が評価できる仕様書のように読める必要があります。
削除すべき行は、レガシーなエンジニアリング求人票から反射的にコピーされたものです:
- 特定の学位要件。この分野で最も優れた人材は独学で習得しており、まだ学位課程が存在しない問題に取り組んでいます。学位フィルターは主に候補者プールを狭め、不利な影響をもたらします。
- 「[エージェントフレームワーク名]のX年経験」。フレームワークは要件が示唆するほど歴史がなく、ライブラリとの年数は判断力ではなく露出を測るものです。
- 長いツールチェックリスト。聞いたことのあるオーケストレーションフレームワークをすべて列挙することは、まさにこのロールが引き寄せる偽物に有利に働き、何も評価できません。
履歴書を信頼するのではなく、何を評価すべきですか?
履歴書では、候補者が本当に怒りをもってエージェントを運用したのか、それともたまたまその日だけうまくいったデモを録画しただけなのかを見分けることはできません。だから各要件を観察できる能力にマッピングし、その能力を直接評価してください。候補者評価が測定すべきことについての私たちの公開見解は5つの柱 — 認知、ドメイン、状況判断、行動、AIフルーエンシー — で成り立ち、このロールはそのすべてに関わりますが、後者2つへの比重が異例に大きくなります。
- ドメイン — オーケストレーション、ツール境界、評価ハーネスの設計。フレームワーク雑学ではなく、職務に即したタスクで評価する。
- 認知 — 多段階トレースを症状の場所ではない原因まで逆方向に読む力。
- 状況判断 — エージェントを構築しない判断、そして本番ツールにアクセスできるエージェントへの境界設定の仕方。
- 行動 — 出荷前に計装し、意図的に大きく失敗させる、信頼性ファーストの気質。
- AIフルーエンシー — ドリフト下でモデル出力を判断し、検証しながらAIに委任する能力。自己申告ではなく観察によって。
最も予測力の高い演習は、職務に即したワークサンプルテストです — 失敗が実際の原因の数ステップ後に表面化した、誤動作するエージェントトレースのデバッグ課題を、AIツールを使用可能な状態で実施し、プロセスを観察します。構造化面接が規定するように実行してください — 全員に同じタスク、同じ材料、同じルーブリック — そして候補者の自信ではなく観察可能な行動を採点します。AI Sandboxはまさにこの種のセッションをAIツールが実際に使用可能な状態で実施するため、修正だけでなく、どのようにモデルに委任し、どこで自信ある誤りを捕捉したかが見えます。そのシグナルを明確に読むには、4Dフレームワーク — 委任、記述、識別、勤勉 — がルーブリックであり、AIフルーエンシーの評価方法が手法を解説しています。このテンプレートの背景にある採用プロセス全体 — スコーピングからオファーまで — については、AIエージェントエンジニアの採用方法をお読みください。このページが成果物で、あちらがプレイブックです。

Illustrative weights — configurable per role, locked at the first candidate for comparability.
なぜ「エージェント型」は履歴書で疑うべき言葉なのか?
「エージェント型」は2026年の履歴書で最も乱用されているキーワードです。このロールは新しく需要があるため、かつてプロンプトチェーンをつないだか、有名なエージェントライブラリの薄いラッパーを出荷した人が誰でも今やエージェントエンジニアリングを名乗っています。上記の求人票はその絞り込みのために存在します — 偽物と本物のエンジニアが紙の上ではほぼ同じに見えるからです。見分け方はエージェントを構築できるかどうかではありません — 今やほぼ誰でもできます。見分け方は、エージェントが牙をむいたときにそれを運用した経験があるかどうかです。
レッドフラグはパターンとして応募書類に現れます。単独の一文ではありません:
- 障害話の代わりにフレームワーク名を並べる — 5つのオーケストレーションライブラリを列挙しているが、本番でデバッグしたエージェントが1つもない。
- プロンプトチェーンをオーケストレーションであるかのように記述している。モデルコールをつなぎ合わせた連続はループではない。計画し、行動し、確認し、回復するループ。この違いが仕事そのものです。
- ブラストラディウス、評価ハーネス、コスト、またはエージェントが自信をもって誤った場合に何が起きるかへの言及がない — デモでは絶対に構築させられない部分です。
- 何でもエージェントにしたがる。一度痛い目にあったエンジニアは、促されなくても、エージェント型にしたいと思われるものの半分は単純なワークフローのままにすべきだと言います。
- その日の録画でうまくいったデモのポートフォリオがあるが、失敗したものの振り返りがない。
本物を素早く見分けるには、エージェントの構築に反対した経験と、その議論に勝ったか負けたかの代償を聞いてみましょう。プロンプトチェーニングの趣味人にそのような話はありません。本番でループを実行したエンジニアはいくつも持っており、促されなくても話し始めます。
このロールがまだ必要ない可能性があります。現在ループし、リトライし、ハンドオフする本番エージェントの名前と、それがすでに引き起こした具体的な障害を挙げられなければ、おそらくより豪華な職種名のついたAIエンジニアを採用しようとしています。ロードマップのスライドにある問題ではなく、今持っている問題にスコープを合わせ、失敗モードが現実のものになってから再検討してください。
最後に正直な一言。私たちは候補者評価を生業としているため、その分だけ割り引いて聞いてください。テンプレートはそれを使って何をするかほどに良いものにはなりません。ここでの価値は箇条書きにあるのではなく、すべての要件が評価可能な形で書かれているため、求人票と評価が同じ文書の2つの見え方になることにあります。求人票をそのように書き、それに照らして評価すれば、「エージェント型」という履歴書上の言葉は信頼しなければならないものではなくなります。
候補者がエージェントを構築できるかどうかが見分け方ではありません。今やほぼ誰でもできます。見分け方は、問題を見て「これはエージェントであるべきではない」と冷静に言えるかどうか、そして既に存在するエージェントを、それが崩れた場所から4ステップ上流でデバッグできるかどうかです。
執筆者
Aayesha Patel · Co-founder, Hanzomon Inc
Co-founder of Hanzomon. Writes about skills-based hiring, fair assessment and building a better candidate experience.