※参考書籍：『現場で活用するためのAIエージェント実践入門』（講談社, 太田真人, 2025）

実務設計での考慮点が整理された良書です。

AIエージェント設計の自由度設定

AIエージェントの設計では、「どの程度の自由度を持たせるか」が重要なポイントになります。 あらかじめワークフローを定義して動作させる方法もあれば、LLMにワークフローそのものを動的に制御させるパターンもあります。

たとえば、LangGraphでSupervisor（管理者）を利用するケースは後者の例です。Supervisorが状況に応じて別のエージェントにタスクを割り振り、結果を受け取って次のエージェントへ処理を引き継ぐ流れでタスクを解決していきます。

参考記事：LangGraphとOllamaでAIエージェントを構築

AIエージェント設計が難しい理由

実務的に見ると、AIエージェントの設計はかなり難易度が高いです。

①深い業務知識がないとまともなプロンプトが書けないし、処理の設計ができない。
②LLMの出力は確率的であるため、処理の再現性を完全に担保できない。
③LLMは長文コンテキストや複雑なタスクになると精度が低下しやすい。

AIエージェント設計は不要にならない理由

ただここで一つ疑問点が浮かびます。 「LLMが年々賢くなるなら、いずれAIエージェントの設計そのものもLLMが行うようになり、人間の設計者は不要になるのでは？」という懸念です。

確かに、実装の自動化はかなり進むでしょう。 業務要件と参照ドキュメントを与えれば、LLMがAIエージェントを設計・実装することは十分可能です。しかし、それでもAIエージェント設計者の仕事はなくならないと考えています。その理由は、LLMが原理的に解けない領域が存在するからです。

LLM単体では原理的に解けない領域

AIエージェントの判断処理では、人間の意図を再現できないケースがあります。たとえば、人間が「この状況下ではAよりBを優先してほしい」といった動的な価値判断を期待しても、LLMは訓練データ上の一般知識に基づくため、同じ判断を再現できない場合があります。

また、AIエージェントのタスクの一つとしてRAGを利用するケースは非常に多いですが、検索したい情報がそもそもドキュメントに含まれていないケースでは、情報欠落による限界が生じます。

さらに、業務には言語化されていない暗黙知が多く存在します。暗黙知は、現場の人の頭の中にあるので、何らかの方法で言語化する必要があります。どんな確認観点があるのか、どのような基準で判断しているのかなど、言語化のハードルは高いです。扱う語義も、専門用語なら教えればいいのでまだなんとかなりますが、一般用語と同じ言葉だけど意味が異なっている用語だと辛いです。

加えて、LLMは一般化ではなく平均的な判断を出しがちなため、例外的なケースの判断も難易度が高いです。

まとめると、LLMがこれから進歩しても、以下のような問題を解くのは難しいと思われます。

AIエージェントの設計経験の転職市場価値

今後、AIエージェントを作ること自体のハードルは下がっていくでしょう。 しかし、業務で使えるレベルに仕上げることは依然として難しい課題のままです。なので、いろんな会社や業務部門から、「AIエージェント作ってみたけど精度が低い、使えない」という言葉を、これから嫌というほど聞かされるようになるのではと思います。
今AIエージェント設計を学び、AIエージェントの実務経験を積むことは、これからの転職市場で生き残る有効な方法と言えそうです。 

参考記事：生成AI時代のITエンジニア向け転職エージェントの選び方