本記事の対象
仕事で AI エージェント開発をやってみたい！AI エージェント開発にジョブチェンジして年収を上げたい！これからの時代で生き残るために AI エージェント関連の仕事をしたい！
でも、、、面接が受からない！内容が多すぎる！毎日新しいもの出てくるから覚えきれない！
そんなあなたに！今年頭から Bilibili でひたすら AI エージェント関連の面接対策動画をかき集めてプレイリストに厳選し、1 日で 72 動画の内容を手動蒸留して実際に受けた FDE と AI エンジニアの面接と照らし合わせて、面接で聞かれる要点を本記事にまとめました！
これだけ読めば受かる！ハンズオン経験が少なくても受かる！Bytedance、Alibaba、Tencent、NVIDIA、GAFA の年収数千万の開発職に受かる！少なくとも動画の人たちはみんなそう言ってる！落ちても責任は取らん！
というわけでまずは
AI エージェント開発の面接で覚えておくこと
- キーワードは常にトレードオフ：現状 AI Agent に関連する技術はまだ未熟であり、「この場合は絶対これ！」というソリューションはなかなかなく、常にトレードオフになります。
この考え方は、チュートリアルに沿ってデモを作ったことある API を叩けるだけのエンジニアと、エージェントのアーキテクチャを設計できるレベルのエンジニアの分け目になります。 - あくまでエンジニアリング：AI Agent にまつわる設計思想は汎用的なエンジニアリングの設計と同じく、可用性、安全性、有用性が求められます。今まで通りのエンジニアリング観点も必要です。場合によってはモデルを通さずに、汎用的なソリューションと合わせた方が良かったりします。
- 検証実験は欠かせない：Chunk の最適値や、Top-K など、明確な答えがないことがよくあります。設定して終了ではなく、検証実験とともに調整が必要になります。
- コストパフォーマンスが大事だったり：クラウドモデルの費用は中小企業にとってそれなりの出費です。企業の規模や需要に合わせてアーキテクチャを設計する必要があります。
- モデルについて知見があるとさらに評価が高い：同一モデルだと同じセッションを共有してしまうリスクがあり、同系列のモデルは同じような欠陥があったりします。同じエージェント内でも利用場面にモデルを変更することを設計に入れるとさらに高評価！
- できることを増やすよりさせないことを決める：何でもかんでもエージェントに詰め込むより、エージェントによる変更が期待通りに正確に反映されることと、環境を破壊しないことが重要です。連携先やツールをひとつ増やすごとにその動きを担保するために敷くガードレールや検証が増えていきます。面接ではそれを考慮できるかが高得点を狙えるかにつながります。
そして合わせて関連記事をお読みください
- LangChain LangGraph LangSmith 入門記事(Coming soon)
- ケーススタディでは体験するカスタムエージェント開発
- 個人で集めた面接対策動画プレイリスト（一部 AI 字幕機能で日本語字幕表示可能）
AIエージェント
エージェントの動きと設計
実装までのフロー
-
業務理解・ヒアリング（成功指標・業務フロー・データ更新・制約）
まずはお客さんと成功の定義を合意するところまで持っていく - ボトルネック整理（データ品質、検索性能、AIの誤回答、セキュリティ）
- MVP設計（まずは限定範囲でPoC）
- 技術構成（データ基盤 → 検索 → AIエージェント → 音声）
- 運用・改善（ログ分析、評価指標、継続的改善）
考慮すること
- Hallucination
- Context管理
- Tool権限
ポイント
- 要件整理
- Agent、サブAgent設計
- Tool設計
- Human in the Loop
まずはお客さんの業務フローを確認します
- 入力は何か
- 出力は何か
- 誰が使うか
- ミスが許されるか
┌─────────────┐
│ 音声データ │
└──────┬──────┘
│
▼
┌──────────────────┐
│ Speech to Text │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ Summarize Agent │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ CRM Agent │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ Report Agent │
└────────┬─────────┘
│
▼
日報完成
Agentの分割
責務を分離する
例
文字起こし
↓
要約
↓
CRM登録
↓
日報生成
CRM更新は事故る、場合によっては
AI提案
↓
営業確認
↓
登録
AI Agent/Coding Agent
具体的なツールやフレームワーク：LangChain, AutoGen など
Memory
コンテキスト、入力、ツール実行結果、タスク状態、パラメータなどが含まれる。
短期と長期に分けられ、長期 Memory に Semantic Memory、Episodic Memory、Procedural Memory が含まれる。
MCP
外部のデータやツールに安全かつ標準化された方法でアクセスするためのオープンプロトコル
外部リソースへの接続、利用可能なツールとその仕様、APIの呼び出しなど
Function calling
新しいサービスを登録する際は新たに SDK を学んで導入する必要がなく、同じリクエストは同一 Session 内で完結する。
しかし、誰が呼び出したかは記録しない。
Tools
ツールの使用手順を提供
ユーティリティ設定、各ツールの期待する戻り値と入力パラメータを設定して、コマンドや機能を用意しておく、CLIコマン実行機能、ディレクトリ作成、削除、Web ドライバーを呼び出すなど
登録済みツールと対応プロンプトをリストアップしてリジェストリ登録しておく
公開インターフェイスを用意して外部から呼び出せるようにしておく
実行結果を JSON 形式で返す
agent.md
入力に対してどのように実行するかをプロンプト化し、中でツールの呼び出し形式を設定
登録されたtools, skillsを読み込む
Skill Intent Spec Plan
intent.md から spec.md へ、spec.md から plan.mdへ、マージされた PR からデプロイへ進みます。
skill.md
- 基準や行動方針を定義する
- Tool を呼び出す際のユースケースとパラメータを提供
- Progressive Disclosure によって段階的に呼び出される、現段階で必要ないものは使わない
- Agent.md, Claude.md などでAgent全体の行動方針を設定し、各役割や特定行動の時だけ登録されているSkillを参照しにいく
intent.md（意図の定義）
役割：技術的な詳細やフレームワークを交えず、**「なぜこの変更や機能が必要なのか」「どんな課題を解決したいのか」**をプレーンな言葉で記録するファイルです。
作成方法：開発者やプロダクトマネージャーが、ClaudeなどのAIエージェントと壁打ち・対話を行い、背景や痛点を人間が読みやすく機械が実行可能な形式にまとめます。
位置づけ：AIネイティブな開発ライフサイクル（SDLC）の**最上流（起点）**に位置します。
spec.md（仕様の定義）
役割：intent.md で定義された大まかな意図や要求を受けて、AIが生成・整理する詳細な技術仕様書・コントラクトです。
変化する性質：従来は人間が最初から細かく書き下ろすものでしたが、AI開発が進むにつれて「人間が書くもの」から「AIが提案し、人間が選ぶ・例外を判断するもの」へ変わりつつあります。
位置づけ：intent.md の次につなぐ中間表現であり、ここからさらに plan.md（実装計画）やコード生成へとパイプラインが回っていきます。
plan.md
実行のステップ
なぜこのタイミングで実行するか、その後はどんな状態が期待されるかが記録されている。
全てのステップに前提状態と実行後の期待状態が記録されている。
Agent Loop
AIエージェントが目標を達成するために「観察（Observe）→思考・推論（Thought/Decide）→行動（Act）→結果の観察（Observation）」という一連のサイクルを自律的に繰り返す実行アーキテクチャ
Agent to Agent（A2A）
複数のAIエージェント同士が共通のプロトコルを使って直接メッセージをやり取りし、協調してタスクを実行する仕組み
セキュリティ
- 安全な実行環境（サンドボックス）の構築
コンテナや、OS レベルでの分離機能
Docker、macOS の Seatbelt、Linux の Bubblewrap など - 人間の介在（Human-in-the-Loop）の徹底
AIがやることと人間がやることの境界線を設ける - アクセス権限の厳格化
- 最小権限の原則: エージェントには「業務を遂行するために必要な最小限の権限」のみを付与し、他のシステムへの影響を最小化
- 資格情報の管理: APIキーやパスワードを直接ソースコードに書かず、セキュアなシークレット管理ツール（AWS Secrets Manager や HashiCorp Vaultなど）を利用
- 挙動の監視とログ記録
動作ログの取得
異常検知
リスク
- インジェクションによる情報流出や不正侵入のリスク
- AI モデルが攻撃される危険性
- 不正な指示入力による攻撃リスク
- 非公式AI利用の拡大によるリスク
- サプライチェーン上の脆弱性
具体例
- プロンプトインジェクション (Prompt Injection)
- 外部ツール連携の悪用 (Abuse of Tool/API Access)
- モデルの敵対的攻撃 (Adversarial Attacks)
- 自律的な行動による予期せぬリスク (Unintended Autonomous Actions)
セキュリティ基準
- 法的責任と倫理的な課題への対応（アカウンタビリティ）
- データセキュリティとコンプライアンス
- 法的リスクの回避
対策
- 情報セキュリティの強化
最小権限の原則 - AIモデルの強化と防御
学習データの品質管理とモデルの動作検証を継続的に実施する - リスク対策を備えたAI運用体制
明確な制約設定とHuman-in-the-Loop（人間の介在）の仕組みを運用体制に組み込む - セキュリティインシデント対応の準備と訓練
迅速かつ適切に対応するためには、事前の準備と定期的な訓練が不可欠 - 社員研修とセキュリティ意識向上
継続的な研修
ハーネス
モデルを取り巻くエンジン
-
定義
ツールを呼び出し、複数ステップのタスクを実行し、実行したことを思い出し、ジョブが完了するまで作業を続けるためには、モデルにラップされたランタイム。 -
動き
モデルを呼び出し、モデルが要求するツールを実行するループを実行し、会話履歴とコンテキストを管理して、モデルがその制限内に留まるようにし、アクションが実行される前に承認ポリシーと安全ポリシーを適用し、タスクの完了に向けてエージェントを進行させる。
Agent Framework ハーネス
| 能力 | Description |
|---|---|
| 関数の呼び出し | 構成可能な反復制限を持つ自動ツール呼び出しループ。 |
| サービスごとの呼び出し履歴の永続化 | チャット履歴は、個々のモデル呼び出しのたびに保持され、クラッシュの復旧と検査の途中実行が可能になります。 |
| 圧縮 | コンテキスト ウィンドウの圧縮により、長いツール呼び出しループがコンテキスト ウィンドウからオーバーフローするのを防ぐ。 トークン予算 (またはカスタム戦略) が指定されている場合にアクティブです。 |
| ToDo プロバイダー | エージェントがマルチステップ プランの追跡に使用する永続的な todo リスト。 |
| エージェント モード プロバイダー | エージェントの動作を構造化する計画/実行/カスタム モードの追跡。 |
| ファイル メモリ プロバイダー | 複数のターンにわたって保持されるノートとアーティファクトのファイル ベースのセッション メモリ。 |
| ファイル アクセス プロバイダー | 作業ディレクトリをスコープとした読み取り/書き込みファイル ツール。 |
| ツールの承認 | 「今後確認しない」承認ルールに加え、安全な無人実行のためのヒューリスティックによる自動承認。 |
| OpenTelemetry | 生成AIのセマンティック規約に準拠した組み込み型の可観測性。 |
| Web 検索 | 既定で追加されたホスト型 Web 検索ツール。 |
| スキル プロバイダー*(省略可能)* | エージェント スキルを検出し、ファイル システムから段階的に読み込みます。 |
| バックグラウンド エージェント*(省略可能)* | 並列作業をバックグラウンド サブエージェントに委任します。 |
| シェル環境*(省略可能)* | シェル コマンドの実行と OS/シェル/作業ディレクトリプローブ。 |
| ループ*（任意）* | 完了条件が満たされるまでエージェントを再呼び出します。 |
設計例
患者ー医師マッチングエージェント設計例
SMS text message / Voice Call-in, start the process
↓
Twilio
↓
Speech to Text
↓ If no match/hard to understand
Input Validation -----------------|-----|-----|-----> Escalation
・Confidence Score | | |
・Medical term | | |
・Fuzzy Matching loop loop |
・Confirmation flow | | |
↓ | | |
Ask questions and confirmation ----| | |
↓ | |
Final Confirmation -----------------------| |
↓ |
Intent / Planner |
↓ loop
Doctor Search Tool |
├─ Structured Search |
└─ Semantic Search |
↓ |
LLM Re-ranking and Response |
↓ |
Text to Speech / SMS Response |
↓ Retry | If still not satisfied
Confirm with patient to reserve or not --------|----> Escalation
↓ If yes ↓ Finish the call or message session timeout
Reserve Doctor ↓
↓ ↓
End the process
RAG
まず確認すること
- 利用シーンの確認
誰が使うのか、何を検索するか - Feedbackレビューと制度の改善
全体の流れ
- 文書収集
- Chunking
- Embedding
- 元データフィルタリング
- VectorDB Search
- Retrieval
- Re-ranking
- Top-K
- Augmented Generation（LLM 回答生成）
Chunking
文書を意味のある小さな断片（チャンク）に分割
Embedding
文章や単語の意味を数値の配列（ベクトル）に変換し、AIが「意味の近さ」で関連文書を検索できるようにする
Retrieval
ユーザーの質問に対し、社内文書やデータベース、ウェブ上の情報から関連するデータを探し出す
Re-ranking
初期検索で取得した複数の文書を、ユーザーのクエリとの関連性に基づいて再度スコアリングし、最も関連性の高い順に並べ替える
Top-K
ベクトルデータベースから関連性の高い上位 K 件の文書（チャンク）を抽出し、AI（LLM）にコンテキストとして渡す際の「取得件数」
例：Top-5 上位 5 件まで
クラスタリング
文書の埋め込みベクトルを類似度ごとにグループ化し、階層的な要約や効率的な検索を行う高度なインデックス手法
-
RAPTOR (Recursive Abstractive Processing for Tree-Organized Retrieval):
- 文章を分割（チャンク化）し、埋め込みベクトルに変換。
- ベクトルをクラスタリング（例：GMM や k-means）してグループ化。
- 各クラスタをLLMで要約し、その要約をさらに上位の階層としてツリー構造を構築。
-
RAGGraph / コミュニティ検出:
- 文書からエンティティ（固有表現）や関係性を抽出し、グラフ構造を構築。
- グラフのノードをクラスタリング（コミュニティ検出）してグループ化し、それぞれの要約を作成。
メリット
- 大局的な質問への対応: 個別の細切れなチャンクだけでなく、要約層を検索することで文書全体の要約や傾向を問う質問に答えられる。
- 検索精度の向上: 意味の似た情報をあらかじめ整理・統合するため、ノイズが減り、コンテキストの抜け漏れを防ぎやすくなる。トークン効率の最適化: 関連する文脈がまとまった要約を利用できるため、長文コンテキストを効率よく扱える。
検索
Hybrid Search
- Vector search and BM25など(keyword search)
- Reranker(BGEなど)
- Top-N で最も精度が高い回答を得る
再検索率（Recall）と精度のトレードオフ
Confidence Check
生成された回答の信用度を評価するロジックを追加
場合によっては手動レビューも挟む
RAGGraph
RAG：類似段落で検索、コンテキストウィンドを失いやすい、全体的な質問や多段飛躍した推理に向かない
コストが低く、応答が早い
RAGGraph：テキスト同士の関連ネットワークを作り、検索しながら推理も行う、ドキュメント超えの検索にも向いている
コストが高く、応答が遅い
例：経営リスクについて聞かれた時に、RAG はリスク関連のキーワードのみを検索して回答、RAGGraph は複数ドキュメントの関連性からリスクを分析できる
Agent 面接例題
Q. System Prompt vs User Prompt
A. 優先度：System Prompt > User Prompt
System Prompt は開発者が設定するベースライン、ロール、規則、出力形式制御など
User Prompt はエンドユーザーの単発のリクエストと処理対象データを入れる。
System Prompt には構造化したロールやルールを静的な形式で入れる。
権限の最小化や禁止事項の定義、プロンプト実行の再現度を重視。
動的情報はUser Prompt に入れる。
Q. Memory に間違った情報が書き込まれた場合はどうするか
A. すでに誤った情報が使用されたかによって対応が異なる
a. 使用される前
- 消極的対応
影響最小化するために Agent にデータの検索や参照のみを行い、更新は隔離環境で実施
- 容量制限と価値基準
Memory に記録するデータ上限を設定し、新たに記録する前に価値基準確認プロセスを入れる
リスクを検知した場合にスナップショットからロールバック
- 書き込み前に内容を評価する
b. すでに使用された場合
- Log から汚染 Memory Id を特定し、影響範囲の特定と評価
- 影響された外部コンポーネントに対してロールバックを実施
- Memory はヘルシーなスナップショットからロールバック
Q. 複数エージェントで Memory を共有する方法
A. ソリューションは 2 種類考えられます
- Blackboard Architecture
共有の Vector DB に都度 Embedding する
同一サブネットないの状況向け
維持コストが高く、Vector DB のオンライン状態に依存する
- Gossip プロトコルによる同期
ネット状に情報がエージェント間で伝達し、全体のメインメモリーとの差分を解消
ブロックチェーンによる改竄防止と TTL も組み込める
Q. 全員が同じ Agent を使う場合コンテキストはどうなるのか
A. 入り口が同じでも、セッションが異なれば別環境として考えることができる、干渉することはありません。
Q. 使いたい Skill が多すぎてコンテキストウィンドをオーバーしてしまう
A. Progressive Disclosure の徹底と、RAG 化して、Ranking で必要な Skill を取り出すこともできる
Q. Agent はどのようにタスクをステップ別に分解して実行するかを判断しているのか
A. いくつかの判断基準を設ける必要があります。
- タスクの複雑度判定
- タスク同士の依存度判定
- タスク実施状態判定、都度DBに状態を保存するなど
- リトライ、レベルダウン、エスカレーションを設定する
Q. Agent が外部 Tool またはモデルの呼び出しに失敗した場合はどのようにリトライまたはカバーするのか(NVIDIA 面接出題)
A.
- Tool Calling が失敗した場合、
- 起因が特定できる場合、Invalid argument などは、エラーメッセージを構造化して Prompt に埋めてリトライ
- 特定できない場合、Tool がネットワークに依存しており、影響を受ける場合
ランダム/指数バックオフでリトライ
- 以前として失敗する場合
ロールバックまたは中断 - モデルのコールが失敗する場合
上記に追加してトークン消費コストパフォーマンスを計算する必要がある
サブモデルをバックアップとして使うこともあるが、性能差やコンテキストウィンドの違いなどを考慮する必要がある
Q. MCP サーバーが必要な場面
A.
- AIに直接機密情報のAPIキーを持たせたくないとき
- 公開APIがないレガシーなシステムやウェブサイトとAIを連携させたいと
- 複数の独立したツールやデータをAIが組み合わせて判断・実行する必要があるとき
- 構造化されていないローカルファイルや社内データベースをAIの「文脈」として直接参照させたいとき
Q MCP に OAuth2.1 が使われる理由
A. データ連携において他サービスの無期限 Token や API Key を埋め込むと権限の制限を失う
プロンプトインジェクションなどにより漏洩のリスクもある
OAuth2.1 は安全でない認証を取り除き、パスワードによる承認を認めない
PKCE により最小限の権限で実行し、傍聴も防ぐ
都度ツール全てに認証を実施するのは現実的ではないので、MCP にて認証し、状態だけを渡す方式を採用。
Q. ReAct Agent が暴走する原因
A. ReAct は動的に意思決定をする循環です。
終了判断がされる状態まで回す：
- Next Step を決める
- Tool を呼び出し再実行することを繰り返す。
- 実行結果のレビュー、コンテキストのフィードバック
相互参照関係があるタスクには向いているが、同一の Tool の呼び出しなどで失敗した際、Token などリソースがない状態、本来のタスクから外れてしまった際、環境破壊のリスクがある動きをしている場合など、異常状態が続き、ループが終了しない。
RAG 面接例題
Q. 文書データに Word、PDF、スライド、グラフがなどが混ざっている場合
Word - XML コンテナに入っているので、タグがあり、ある程度構造化されている。
PDF：キャンパス上にピクセルの座標を記録しているだけなのでめんどくさい。
A. 解決方法：
- スライドと PDF はページ別にスライスし、隣接ページ同士で重複バッファーを設けて情報の完全性を保証する
- Unstructured で画像と文字を分離し、OCR で Markdown への変更を試みる
- 画像化し、視覚で画像解析する AI に読み込ませる
- テストを繰り返し、Chunk 方式とバッファーなどの設定を調整する
- Chunk を文字数だけでなく、Structure -Aware -Chunking または Recursive Chunking で設定
Chunck_size: 400-800
Overlap: 20%
- Semantic Chunking
AI で文章の流れの変わり目を検知して動的に分割 —> コストが高い
Q. RAG 全体の高速化に有効な施策
A. 主に以下のように分割してそれぞれ最適化できます
- Embedding:
- モデルをローカル環境に配置して GPU で高速化
- TensorRT/vLLM/ONNX などで加速を実施
- Cache query embedding、よく聞かれる質問をLLM通さずに回答
- Searching
- Vector DB の調整
精度と速度のトレードオフ
HNSW、efの調整、プリロードしておく - 元データの Index 化/フィルターの設定
- k 値の調整（テストで探索）
- Re-ranking（影響が大きい）
- モデルの軽量化
- Batch 化、非同期化
- いらない時もある
- LLM による回答生成段階
- コンテキストウィンドの調整
- vLLM で加速
- Streaming で UX 調整
- Cache を設定して LLM をスキップ
- 全体アーキテクチャ
- クラスタリング
- Cache で回答できるものは全部 Cache に
- Hot data をメモリに配置、メモリは大企業にとってはコスパいい
- 「iPhone 15pro の値段は？」などキーワードが明白で、回答が一意の場合、事前スコアリングで Vector を介さずに直接検索で回答
Q. RAG でハルシネーションが発生する原因
A. 実際にどこで発生しているかを切り分けて特定する必要がある
- 準備段階
元データ Chunk またはフィルター時にすでに誤った情報として保存されていた可能性があり、Semantic Chunking、Chunk 内にタイトルやサマリーの追加などを試みる
- Query Optimization
質問が不明瞭、DB のキーワードと一致しない場合
- Query Rewriting：LLM で問題の拡張または質問の再作成
- HyDE：仮定の回答を生成して逆検索を実施
- Retrieval：Vector 検索のみ対応している場合、当てはまるものがないと近いベクトルに吸い寄せられてしまう。またはRecall が低く、専門用語などが検索できない
- Hybrid 検索
- Top-K の拡大
- Re-Ranking
- Cross-Encoder による Re-rank、スコアで厳選
- コンテキスト圧縮して関連がないキーワードなどを削ぎ落とす
- Generation
- Prompt 制約再検討
- 参照先の出力
- SFT 調整：コンテキストによる影響度合を制御