1. LLMエージェントとは——「答えるAI」から「動くAI」へ
LLMエージェントとは、目標を与えると、必要な道具を自分で選んで使いながら、複数のステップを経てタスクを完了するAIのことです。従来のチャットAIが「聞かれたことに文章で答える」だけだったのに対し、エージェントは「調べる・計算する・システムを操作する」といった行動を伴います。人間に例えるなら、質問に答えてくれる物知りな同僚ではなく、「これお願い」と依頼すると段取りを組んで実際に手を動かしてくれる部下に近い存在です。
支える3つの基礎概念
- tool use（function calling）——LLMに「使ってよい道具の一覧」（例: 顧客データベースを検索する関数、メールを送る関数）をあらかじめ渡しておき、LLMが状況に応じて「この道具をこの引数で使いたい」と宣言する仕組みです。実際に道具を実行するのはLLMではなく周囲のプログラムで、その結果をLLMに返して続きを考えさせます。エージェントの手足にあたる、最も基本的な部品です。
- 計画と実行のループ——エージェントは「目標を確認→次の一手を考える→道具を実行→結果を観察→また次の一手を考える」というループを回します。一発で答えを出すのではなく、結果を見て軌道修正しながら進むのがポイントで、途中でエラーが出れば別の方法を試す、といった柔軟さが生まれます。
- マルチステップ処理——「経費データを取得→部署別に集計→レポートを作成→承認者に送付」のように、複数の工程をまたぐタスクを一連の流れとしてこなします。工程が増えるほど便利になる一方、どこか1ステップの誤りが後続すべてに波及するため、後述する信頼性設計が重要になります。
まとめると、エージェントとは「LLM＋道具＋ループ制御」の組み合わせです。仕組み自体は驚くほどシンプルですが、「どんな道具を、どんな制約付きで渡すか」の設計に品質のほとんどが詰まっています。
2. FDEの現場でどう使うか——実務の中心は「信頼性の設計」
FDE（Forward Deployed Engineer）の現場でエージェント案件がチャットボット案件と決定的に違うのは、AIが「情報を答える存在」から「業務システムを操作する主体」になる点です。社内文書に答えるだけのAIなら、間違えても人間が読んで気づけます。しかしエージェントは受注データを書き換え、メールを送り、ワークフローを進めます。間違いがそのまま業務上の実害になるため、顧客企業が最も気にするのは「賢いか」より「任せて大丈夫か」です。
そのため、FDEの実務時間の多くは派手なAIロジックではなく、次のような地道な信頼性設計に費やされます。
①ガードレールの設計
エージェントに渡す道具そのものに制約を埋め込みます。「参照はできるが削除はできない」「1回の操作金額に上限を設ける」「操作対象を特定の部署のデータに限定する」など、LLMが誤った判断をしても被害が及ばない範囲をシステム側で保証するのが基本です。プロンプトで「気をつけて」と指示するだけでは不十分、というのが現場の共通認識です。
②人間の承認フローの組み込み
取り返しのつかない操作（送信・決済・データ更新など）の前に、人間の確認を挟む設計です。「どの操作は自動でよく、どの操作は人間の承認が必要か」の線引きは技術だけでは決められず、顧客の業務ルールや責任の所在を理解した上での合意形成が必要になります。ここは要件の言語化スキルと直結する、FDEらしい仕事です。
③失敗時の挙動と監視
途中で止まったらどうするか、リトライするか人間に引き継ぐか、実行ログをどう残して後から検証可能にするか——運用に入ってから効いてくる設計です。PoC設計の段階で「成功率をどう測るか」を決めておくことが、本番移行の成否を分けます。
国内でもこの動きは明確で、Sansanは公式テックブログ（2026年1月）で、AIエージェントの開発・導入をFDEという職種の業務の中核に位置づけ、「ビジネス・データ・現場の全てを理解する」役割として紹介しています（出典は記事末尾）。エージェントを「作る」だけでなく「顧客の現場で安全に動かし切る」ところまでがFDEの職域、という整理です。
3. 今どうやって身につけるか——公式ドキュメントベースの3ステップ
エージェントは情報の鮮度が特に重要な分野です。フレームワークの流行り廃りが速いため、一次情報（モデル提供元の公式ドキュメント）を起点にするのが最も確実です。
Step 1: tool useの仕組みを公式ドキュメントで理解する（目安1〜2週間）
まずAnthropicの公式ドキュメントにあるtool use（function calling）のガイドと、OpenAIのAgents SDKのドキュメントに目を通し、サンプルコードを写経して「LLMが道具の使用を宣言→自分のコードが実行→結果を返す」という往復を手元で動かします。ループの1周を自分の目で観察することが、この後のすべての土台になります。エージェントの前提となるプロンプト設計に不安があれば、先にプロンプトエンジニアリングを押さえておくと理解が速くなります。
Step 2: 小さな業務自動化を自作する（目安2〜4週間）
チュートリアルの次は、自分の身の回りにある実在の反復作業をひとつ選んで自動化します。例: 受信メールを分類してタスク化する、複数サイトから情報を集めて週次レポートにまとめる、経費データを整形して集計する、など。道具は2〜4個の小さな構成で十分です。実在の作業を選ぶ理由は、「たまに失敗する」「想定外の入力が来る」という現実に必ず直面し、それこそが実務で問われる経験になるからです。
Step 3: 評価とフェイルセーフを設計する（目安1〜2ヶ月）
仕上げは「動く」の先です。想定タスク20〜30件で成功率を測る評価セットを作り、失敗パターンを分類し、危険な操作の前に確認を挟む・上限を設ける・ログを残すといったフェイルセーフを実装します。「成功率◯%で、失敗時はこう振る舞う」と数字と設計で語れるようになれば、それは選考でそのまま使えるポートフォリオになります。学習全体の順序は未経験からのロードマップも参考にしてください。なお、エージェントに社内ナレッジを参照させる場面ではRAG実装スキルと組み合わせるのが定番で、両方を押さえると設計の幅が一気に広がります。
4. FDE Outlook——エージェントスキルの現在地と見立て
今見えていること: 2025年が「エージェント元年」と呼ばれて以降、エージェントは各社のAI戦略の中心に据えられ、FDEの求人・業務内容でも名指しされる存在になりました。国内ではSansanがAIエージェント開発をFDE業務の中核に置くことを公式に発信しており、FDEになるにはで整理した3スキル（実装力×LLM活用×顧客対話）の「LLM活用」は、RAGに加えてエージェント設計まで含む方向に広がっています。
今後の見立て: エージェントを「作る」ためのSDKや基盤は急速に整備されており、単に動くものを組む難易度は今後も下がり続けると見ています。その結果、評価軸は「作れるか」から「安全に運用できるか」へ——つまり、権限設計・承認フロー・評価と監視・失敗時の振る舞いといった、顧客の業務と責任構造を理解しないと決められない部分に移っていくはずです。ここは自動化しにくく、現場に入り込むFDEの価値がむしろ濃くなる領域だと考えています（断定はできませんが、求人要件の記述の変化は当サイトの求人ウォッチで引き続き観測していきます）。他のスキルとの位置づけはFDEスキルマップをご覧ください。