記事一覧

採用 · July 29, 2026 · 約9分

AIエージェントエンジニアの採用方法:何をテストするか

AIエージェントエンジニアの採用方法。役割の実態、本当に必要なタイミング、排除すべき偽物、実力を予測するトレースデバッグのワークサンプルまでを解説します。

Aayesha Patel 著 · Co-founder, Hanzomon Inc

共有

「The five pillars of hiring: what assessments measure」の一部

採用
目次

これはエージェントのデモが魔法のようなことをするのを見て本番環境にゴーサインを出し、その後午前2時のページャーに出会ったエンジニアリングリーダーのためのものです:エージェントが不正なツール呼び出しでループし、輪を描いてリトライし、誰かが気づく前に1ヶ月分のトークンバジェットを燃やしました。AIエージェントエンジニアはそれが起きなくなるよう採用する人物です。モデルが多くのステップにわたって行動するシステムを構築します — 計画、ツール呼び出し、引き渡し、自らのミスからの回復 — そして自律性に伴う障害モードを担当します。これはAI時代の役割の中で最も新しく、特定の理由で今存在します:2025〜26年の単一呼び出しモデルフィーチャーから数十のステップにわたって行動するエージェントへのシフトが、通常のバックエンドエンジニアリング、さらには通常のAIエンジニアリングがカバーしない障害モードを生み出しました。役割はエンジニアリング組織の中に、信頼性を担当する人の近くに位置します。本番環境のエージェントは主として信頼性の問題だからです。採用を間違えても遅いフィーチャーにはなりません。誰も再現できない方法で、誰も予測しなかったコストで失敗するシステムになります。このガイドはそれに応募してくる多くの人の中から本物を見分ける方法です。

AIエージェントエンジニアは実際に何をしているのか?

AIエージェントエンジニアは、モデルがループで実行するシステムを構築・運用します。1回回答して止まるのではなく、ツールを通じて決定、行動、結果確認、再決定します。クラフトはそのループを囲むすべてのことです:制限された、観察可能な、回復可能な、そして手頃なコストでの実行。1週間の仕事はプロンプトライティングより小さな予測不能な分散システムの運用に近いです。

  • エージェントのコントロールループを設計する — どう計画し、いつツールを呼び出し、完了をどう判断し、永遠に実行し続けることを何が止めるか。
  • 爆発半径を制限する — 混乱したエージェントがチケットを読めるがテーブルを削除できず、顧客にメールを送れず、上限なしに使えないよう、パーミッショニングとサンドボックス化を行う。
  • ハンドオフを構築する — エージェントとサブエージェント間、またはエージェントと人間の間、各サイドの責任について明確なコントラクトを持って。
  • 障害回復を組み込む — ハンマリングではなくバックオフするリトライ、失敗したステップがランを最初からやり直さないためのチェックポイント、静かにではなくうるさく失敗するデッドエンド。
  • 全体を計装する — すべてのステップ、ツール呼び出し、決定のトレース。ランが失敗するとき原因は症状が現れる場所とめったに一致しないからです。
  • コストをコントロールする — トークンバジェット、ステップ制限、ループ検出。悪い呼び出しをリトライするエージェントは静かにお金を燃やしているエージェントです。
  • マルチステップタスクのevalを書く — エージェントが正しい結果に達したか、そして1回のランで偶然ではなく正気を保って達したか。

誰かがエージェントエンジニアとして考えているかの1行テスト:彼らの作業単位は呼び出しではなくループです。AIエンジニアは単一のリクエストとレスポンスを最適化します。エージェントエンジニアはステップ1から13が静かに脱線した後、ステップ14で何が起きるかを推論します。

本当に必要ですか?

要件を開く前に正直になってください。本物の副作用を伴う多くのステップで自律的に行動するエージェントを出荷する場合のみAIエージェントエンジニアが必要です。プロダクトがモデルを1回呼び出してテキストを返すだけ — 要約機能、分類器、スマート検索ボックス — ならエージェントの問題はなく、AIエンジニアリングの問題があります。エージェントのために採用することは時期尚早です。

小規模ではAIエンジニアがこの領域を快適にカバーし、多くの場合優れた判断力を持つ強いバックエンドエンジニアが最初のエージェントフィーチャーを本番環境まで持っていきます。専任採用の正直なトリガーは野心ではなく障害モードです:暴走するループ、間違った順序で発動するツール呼び出し、目で見ると消えてしまう非決定論的バグ、またはエージェントがエッジケースに当たるたびに急騰するコストカーブを見ているとき。それらのどれもまだ起きていないなら、この役割は自分を説得している採用です。われわれは生計として候補者評価を売っているため、お好みで割り引いてください — しかし、エージェントエンジニアを無駄にする最速の方法は、エンジニアリングに値するエージェントを持つ前に採用することです。

有用なゲート:現在ループし、リトライし、またはハンドオフする本番エージェントと、それがすでに引き起こした具体的な障害を名前を挙げられなければ、おそらくよりファンシーなタイトルを持つAIエンジニアを採用しています。ロードマップのスライドにある問題ではなく、実際に抱えている問題に役割のスコープを合わせてください。

優れたエージェントエンジニアとフレームワーク名前使いを分けるものは?

新しいタイトルはすべて名前を変えた職務経歴書を引き寄せます。これは特定の偽物を引き寄せます:フレームワーク名前使いです。今月の人気エージェントライブラリでデモを構築し、5つのオーケストレーションフレームワークを列挙でき、プランナーとツールについて流暢に話せます。それはどれもシグナルではありません。フレームワーク習熟度は最低限の条件です。ドキュメントを読んだことは教えますが、自律システムがあなたを傷つけないよう維持できるかは教えません。本物のスキルはデモ構築者が決して訪れる必要がなかった3つの場所で現れます。

  • エージェントの爆発半径をどう制限するか。エージェントが確信を持って間違っているとき何を行えるかを問いましょう。優れたエンジニアは具体的に話します:最小権限のツールアクセス、サンドボックス化された実行、支出上限、常に人間にルーティングされる不可逆アクションリスト。名前使いはフレームワークの組み込み安全機能について話してそこで止まります。
  • マルチステップタスクのevalをどう設計するか。単一の呼び出しを評価することは採点された回答です。ループを評価することは、エージェントが結果に達したか、そして正当な理由で達したかを、多くのランにわたって、各回を手でチェックせずに問うことを意味します。これを構築したことがない人は、怒りの中でエージェントを本当に実行したことがない人です — 録画の日にたまたま機能したデモを実行した人です。
  • 症状より4ステップ前に障害が起きたトレースをどうデバッグするか。これが1つの問いにおける全仕事です。エージェントはステップ14でエラーになりましたが、根本原因はステップ10で飲み込んだ不正なツール結果で、それ以来ずっとその周りで推論してきました。症状から逆向きにトレースを読む本能 — 症状を遅延指標として扱う — エンジニアが欲しい人物です。ステップ14にパッチを当てて完了とする人は午前2時に戻ってきます。

すべてのツール類の上に判断力のレイヤーがあり、最もまれなシグナルです:エージェントが間違った答えであることを知ること。本当に優れたエージェントエンジニアは、促されなくても、エージェントにしたいと思っていることの半分が1ステップにモデル呼び出しを含む単純な決定論的ワークフローであるべきだと教えてくれます — 安く、テスト可能で、本番システムが退屈であるべき方法で退屈です。すべてをエージェントにしたい人は、エージェントにまだ焼かれていないことを示しています。

シグナルは候補者がエージェントを構築できるかどうかではありません。今や誰でもできます。シグナルは、落ち着いて問題を見てエージェントであるべきではないと言えるかどうかです — そして、単純なワークフローでは節約できたコストをここでエージェントが何をもたらすかを説明できるかどうかです。

これらのスキルをどうテストしますか?

フレームワーク名前使いは面接が抜群に上手いため、質問だけでこのシグナルに面接でたどり着くことはできません。取り組む様子を見なければなりません。最も予測的な演習は職務に即したデバッグタスクです:誤動作するエージェントのトレースを渡します — 本物を軽くサニタイズしたもので、実際の原因より数ステップ後に障害が表面化した — そしてAIツールを使える状態でプロセスを観察しながら根本原因を見つけさせます。それが仕事です。デモ構築者がこれを偽れない唯一のことでもあります。なぜなら流暢なトレース読み取りは自分のエージェントにページャーで叩き起こされた経験からしか来ないからです。

あらゆるワークサンプルテストと同じように実施します:すべての候補者に同じタスク、同じ材料、同じルーブリックを使い、どれだけ自信に満ちていたかではなく観察可能な行動でスコアリングします。観察するのは、症状からトレースを逆向きに読むかどうか、何かを変え始める前にループがどこで間違ったかについて仮説を立てるかどうか、そしてステップ14のクラッシュにパッチを当てるのではなくステップ10で飲み込まれたエラーに気づくかどうかです。そして仕事は集中的にAIネイティブだから — これらのエンジニアは見知らぬトレースを移動するためにAIに常に頼っています — 存在しなくなった仕事を測定するためにバンしてではなく、取り組む際にAIをどう使うかを観察すべきです。

その観察されたAI使用レイヤーがわれわれのプラットフォーム見解が落ち着くところです。AI Sandboxはこの種のタスクをリアルな役割関連セッションとして実行し、AIツールが本当に使える状態で、修正だけでなくモデルへの委任の仕方と自信を持って間違っているときに捉える場所を見られます。使うべきルーブリックはAIフルーエンシーの4Dフレームワーク — 委任(Delegation)、説明(Description)、識別(Discernment)、勤勉(Diligence) — で、それらのシグナルをきれいに読む仕組みについてはAIフルーエンシー評価方法で全メソッドを書いています。エージェントエンジニアにはDiscernmentが最も重要です:この役割全体は、もっともらしく見える結果が4ステップ下流で複合する前に間違っている瞬間を捉えることです。

実践でのトレースデバッグワークサンプル:候補者がエージェントの実行をステップごとに読み、処理が最終的に落ちたより数ステップ上流の不正なツール結果を追っています。

ワークサンプルと、すべての候補者に同じ質問・同じ順序・同じスコアリングの構造化判断質問を組み合わせます。トレースだけでは表面化しない推論を目指します。本番ツールへのアクセスを持つエージェントの爆発半径境界を設計するよう求めます。正しい答えが変わるマルチステップタスクをどうevalするかを問います。最も示唆に富むのは、何かをエージェントにすることに反論したケースと、その議論に負けるか勝つかのコストが何だったかを問うことです。これは最悪の障害がコーディングの障害ではなく判断の障害である役割に適用された状況判断です。

トレースにデコイを仕込みましょう:エージェントがクラッシュしたステップでの明らかなエラーと、より数ステップ前の真の原因。フレームワーク名前使いは明らかなものを修正して完了を宣言します。本物のエージェントエンジニアは症状を信用せず、ループの実際のドリフトが現れるまで上流に読み続けます。

面接ループはどう設計すべきか?

引き締めましょう — 優れたエージェントエンジニアは希少で多くの求愛を受けているため、膨らんだループは単により速い競合に失います。4段階で十分です。そのうちの1つはワークサンプルであるべきで、5回目の会話ではありません。

  • 全員が同じ条件で受けるスキルスクリーン — 短い役割関連タスクで職務経歴書の選別を置き換え、通常の経歴を超えてプールを広げバイアスを削ります。哲学についてはスキルベース採用ガイドを参照してください。
  • AI Sandboxでのトレースデバッグワークサンプル、AIツールを使える状態でプロセスを観察 — 最もシグナルの高い単一ステージで、実際にエージェントを本番運用した経験を持つエンジニアが担当します。
  • オーケストレーション、サンドボックス化、eval、そしてエージェントをいつ使わないかの判断についての構造化面接。あなたのエージェント信頼性を担当する人が、固定ルーブリックで実施します。
  • 短いシステム設計会話:あなたが直面する実際の問題に対して制限された、観察可能な、回復可能なエージェントをスケッチさせ、トレードオフを探ります — コスト、レイテンシー、そして人間がループのどこに残るか。

誰かが意見を比べる前に書面でルーブリックに対して各ステージをスコアリングし、部屋で最も声が大きい意見を洗浄するのではなく証拠を集積させます。全足場 — 誰が何を実行するか、スコアカードをどう構築するか、順序がなぜ重要か — が必要なら、構造化面接が参照先であり、ここに変更なく適用されます。

シニオリティと最初の90日間

報酬とレベルについては、数字を作りたい誘惑に抵抗してください。これは速く動く市場における新しいタイトルであり、今日印刷したどんな範囲も次の資金調達ラウンドまでに古くなります。定性的に安全に言えること:役割がシニアのシステムエンジニアリングと本物の本番の経験を持つ人がほとんどいない真に新しいディシプリンを融合しているため、強い候補者はエンジニアリングバンドの上位に位置し、それを知っています。年数でも名前を挙げられるフレームワークでもなく、曖昧さの下での実証された判断力 — 実際にデバッグしたトレース、実際に制限したエージェント — でレベリングしてください。自社市場を基準にし、候補者が最初に提示するペイアンカーではなく証拠に基づいて採用してください。

最初の90日間の良い姿は地味です、それがポイントです。優れた採用は最初の月に3つの新しいエージェントを出荷しません。すでに実行しているエージェントを計装して障害が見えるようにし、持っていないループに支出上限とステップ制限を設け、マルチステップタスクのための最初の本物のevalスイートを構築して次の変更が信頼できるようにします。その中のどこかで、1つの過剰に野心的なエージェントを静かに単純なワークフローに戻して定期的なコストを節約してくれます。3ヶ月後、エージェントが静かにではなくうるさく失敗し、失敗するときにその理由がわかるなら、正しい人を採用しました。その信頼性ファーストの本能がこの役割全体です — そしてまさに払っていた採用品質です。

最も高コストなエージェントエンジニアの採用ミスは、エージェントを構築できない人ではありません。3つを構築し、すべて制限なく計装なしで、完璧にデモし、その後誰も再現できない方法で本番で失敗する人です。その請求は数ヶ月後に届き、そのころにはループが荷重を担っています。

これから1つだけ持ち帰るなら:エージェントエンジニアはデモが正しく動いたときの見た目ではなく、ループが間違ったときに何が起きるかで評価されます。同じ方法で評価してください — デバッグする本物のトレース、手元にAI、プロセスを観察 — そして症状にパッチを当ててページャーを待つのではなく、4ステップ上流の障害を読む人を採用できます。同じシフトの1ステップ前の兄弟役割、製品にモデルを接続してからループする人のために、AIエンジニアの採用方法を読んでください。

AI-era rolesAI agent engineerTechnical hiringCandidate evaluationAI-native hiringAI jobs
A

執筆者

Aayesha Patel · Co-founder, Hanzomon Inc

Co-founder of Hanzomon. Writes about skills-based hiring, fair assessment and building a better candidate experience.

よくある質問

AIエージェントエンジニアは何をする役職ですか?

言語モデルが多くのステップにわたって実行し、ツールを呼び出し、他のコンポーネントに引き渡し、自らのミスから回復するシステムを構築します。日々の業務はエージェントのループの設計、触れられる範囲の限定、マルチステップタスクのevalの作成、そして処理がループしたり脱線したりしたときのトレース読み取りです。彼らの作業単位は単一のモデル呼び出しではなくループです。

AIエージェントエンジニアは本当に必要ですか?

本物の副作用を伴う複数のステップで自律的に行動するエージェントを出荷する場合のみです。プロダクトがモデルを1回呼び出してテキストを返すだけなら、AIエンジニアで十分でありエージェントエンジニアは時期尚早です。トリガーは通常のバックエンドが決して見ない障害モードです:暴走するループ、間違った順序で発動するツール呼び出し、エージェントが輪を描いてリトライするときに急騰するコスト。

AIエンジニアとAIエージェントエンジニアの違いは何ですか?

AIエンジニアはモデル呼び出しの周りにフィーチャーを構築します:検索、プロンプティング、評価、モデルをプロダクトに接続すること。AIエージェントエンジニアは、ツールと副作用を伴いながら多くのステップにわたってループし、計画し、行動するシステムを担当します。エージェントエンジニアの作業単位は呼び出しではなくループです。これにより、呼び出し型の作業が決して要求しないオーケストレーション、サンドボックス化、障害回復、非決定論的デバッグが生じます。

AIエージェントエンジニアに必要なスキルは何ですか?

オーケストレーションとハンドオフ設計、爆発半径を制限するためのパーミッショニングとサンドボックス化、障害回復、非決定論的実行のためのオブザーバビリティ、エージェントがループでトークンを燃やす可能性があるときのコストコントロール。ツール類の上には判断力があります:エージェントが間違った答えで、単純なワークフローの方が安全である時を知ること。フレームワーク習熟度は最低限の条件であり、採用のシグナルではありません。

AIエージェントエンジニアをどう面接しますか?

職務に即したタスクを与えてください:症状より数ステップ前に障害が発生した、誤動作するエージェントのトレースをデバッグさせます。AIツールを使える状態で作業を観察します。エージェントの爆発半径の制限、マルチステップタスクのevalの設計、エージェントが間違ったツールである場合についての構造化判断質問を加えます。それはフレームワーククイズよりはるかに本物のスキルを読み取ります。

関連記事

あなたの求人票で試す

アーリーアクセスのウェイトリストに登録し、実際の求人でH-Evaluateがアセスメントを生成する様子をご覧ください。

あなたの求人票で試す