このページの本文へ

前へ 1 2 次へ

エンジニアにとってのAIエージェントへの向き合い方 JAWS DAYS 2025で聞いた

AIエージェントの登場で開発者はプルリクのレビュアーに成り果てるのか?

2025年04月18日 09時00分更新

文● 大谷イビサ 編集●ASCII

  • この記事をはてなブックマークに追加
  • 本文印刷

 クラウドエンジニアの祭典である「JAWS DAYS 2025」。ソフトウェア開発を大きく変えそうなAIエージェントについて語ったのは、JAWS-UGのベテランであるSection-9の吉田真吾さん。AIエージェント時代のエンジニアが考慮すべきトレンドや技術的なポイントを持論を交えて解説した。

Section-9の吉田真吾さん

2025年、「AIエージェント」はなぜここまで隆盛となったのか

 「AIエージェント時代のエンジニアになろう:Agnostic Workflowから環境に溶け込むAmbient Agentsまで基礎と実践を50分で身につける」というタイトルで登壇したのはJAWS-UGに関わって15年近くになる吉田真吾さん。JAWS-UG横浜やServerless Confををはじめ、さまざまなコミュニティの顔役だ。「上位トップ10に入るキング・オブ・老害(笑)。いまだに現役でがんばってます」と謳う吉田さんは、現在はAWSによるモダナイズを実現するSection-9と「AIエージェントで会社を経営したい」という目的で設立されたジェネラティブエージェンツを運営している。

 そんな吉田さんは「これまで2年間やってきたことの総決算的なことを話します。胸にイチモツを持って、ここに来ている方が多いと思うので、最低でも10個くらい、できれば50個くらい持って帰ってもらいたい」と聴衆にアピール。まずは「2025年の現在、なぜ1日10回も、100回もAIエージェントを聞くようになったのか」をひもとくべく、LLMの歴史からおさらいする。

 AIの歴史は1960年代にさかのぼると言われる。1990年代に特定タスクを支援する統計型言語モデル、2013年代にタスクに依存しない機械学習、2018年に事前学習済みの言語モデルが登場。2020年に汎用的なタスク解決を支援する大規模言語モデルが台頭し、AIによる生成能力が高まってきたのがAIエージェント実現の背景にあった。

 一方で「環境を認識し、目標を達成するために自律的に行動する存在」と定義されるAIエージェントも、AIの進化と歩調を合わせて、さまざまな実践が行なわれてきた。「エキスパートシステムの時代からAIエージェントはあった。だから、LLMの話だけに限らない」と吉田さんは語る。

 では、なぜ今AIエージェントか? 吉田さんは、「LLMのテキスト生成能力ではなく、タスクを計画するリーズニング能力がめまぐるしく向上したから」と説明する。2022年10月に出た「ReAct:Synergizing Reasoning and Acting in Language Models」という論文では、タスクの計画や分解にLLMが使えるアプローチを提案。環境を認識し(Observe)、計画を立てて(Reasoning)、その計画を実行する(Act)を繰り返すと、複雑なタスクをこなせるというのがその概要だ。

 この論文以降、さまざまなAIエージェントがフレームワークとして登場する。2023年に登場した「Baby AGI」や「AutoGPT」などが登場。そして、最近エンジニアに身近になってきたのは、LLMと強化学習の技術を用いた完全自律型エンジニアAIエージェント「Devin」だ。「指示すると、言われたとおりに作って、山ほどプルリクを出してくる。われわれ開発者は、プログラマーではなく、プルリクのレビュアーに成り果てつつある」と吉田さんは自嘲気味に語る。

完全自律型のAIエージェントは幻 必要なのはワークフローの定義

 こうしたAIエージェントを、エンジニアはどのように作っていくべきか。これに対して吉田さんは「すべての仕事はワークフローである」というタイトルのスライドを披露し、なすべきことを語る。

すべての仕事はワークフローである

 「今までDXでいろいろな取り組みをしてきたと思いますが、AIエージェントだからといって、今までとまったく違った万能なシステムを作らなければいけないわけではない。ちゃんと業務をひもといて、LLMエージェントにやらせなければいけないタスクをワークフローとして事前に定義していくのが、われわれにとってもっか必要なアプローチだと思っている」と吉田さんは語る。

 特にB2Bのバーティカル領域では、業種・業界に特化したタスクが数多く存在し、これらをこなすAIエージェントでは、これらワークフローを定義する必要がある。「AIエージェントはソフトウェアなので、要件を固め、なによりテストしなければならない。どんな状況でも完璧に動くエージェントは、おそらく幻」と吉田さんは指摘する。

 たとえば、メールの下書きを書いて、承認して、勝手に送信するエージェントを作ったとする。でも、結局は予定調整やスパム判定も必要になる。「どこまでいっても完全に自律型のエージェントは作ることはできない。ちょっと哲学的な話だが、すべてを定義づけし、すべてをテストすることはできない」と吉田さんは語る。

 あくまで自分たちが切り出したワークフローを要件化し、出来のよいエージェントを作っていくのが、この先のAIエージェントの方向性だ。「ということで、みなさんがやらなければいけないのは、まずはAIになにをやらせたいのか、ワークフローを定義することだと思います」(吉田さん)。

AIエージェントの開発手法 ノーコードツールも登場

 ワークフローを実装するために、具体的にはフレームワークを構築する。ここで言うフレームワークとは、「ステートマシンを中心にワークフローを管理するオーケストレーター。(JAWS-UGの)僕らにわかりやすい言葉で言えば、StepFunctionsみたいなもの」(吉田さん)とのこと。LLMの言語処理に関しても、一定のステートを満たしたら、次の処理に進むというワークフローの仕組み自体は同じだ。

 ソフトウェアアーキテクチャの観点では、プロンプトを数珠つなぎにしていくプリミティブな「プロンプトチェーニング」のほか、タスクを定義し、必要に応じてルーティングや並列化を行なう「LLMタスク」、プロファイルや長期メモリなどを持ったエージェントをオーケストレーションさせる「マルチエージェントオーケストレーション」といった大きく3つのアプローチがある。

 この3つのアプローチを実現するツールが「LangGraph」と「LangChain」になる。自著の書籍を紹介しつつ、吉田さんは「crewAI」とLangGraphを組み合わせた実例を披露。「メールを自動的に受信し、返信メールを下書き生成し、承認を行なった後、送信するようなエージェントを簡単に作ることができる」と説明した。

 さらにAutoGenのようなリッチなフレームワークを使うと、複数の独立したエージェントを協調させることで、業務を遂行できる。もちろん、Agents for Amazon Bedrockでも同じような構成が可能。5月に発売される「AWS生成AIアプリ構築実践ガイド」では、サンプルで公開されている太陽光パネルの管理の例を用いてマルチエージェントのオーケストレーションを学ぶことができるという。

 最近では非エンジニアがノーコードでAIエージェントを構築できる「Dify」や「FlowWise」、「LangFlow」などのサービスも登場している。「本番環境に向けて、非機能要件も含めてロバストなアプリケーションを作りたいといった場合には若干不向きですが、PoCやアプリの本番の初期フェーズにおいては、Difyなどで作っていくのがビジネスを素早く立ち上げるヒントになる」(吉田さん)。

前へ 1 2 次へ

カテゴリートップへ