もし後輩に「生成AIがプログラムを扱えて何が嬉しいんですか」と聞かれたら（中編）

出てきた当初は正直どう使うと嬉しいかが具体的にはわからなかったAgents for Amazon Bedrockのような機能の今日的な意義について、改めて考えてみるエッセイの中編となります

前編をまだお読みでない方はぜひそちらからお読みください

blog.serverworks.co.jp

また、以下のような概念・機能については、読者の理解がある前提で書きすすめておりますので、理解に自信のない方は先にそれぞれに関するブログを一読されることをおすすめします

AIエージェント的なソリューションを実装する上での気がかり
必要と考えられるデータソースについて
具体的な実装要領のイメージ
小括
脚注

AIエージェント的なソリューションを実装する上での気がかり

前編では

Agents for Amazon Bedrock のような機能の真価を考えるには、ちまちましたスケールではなく、ある程度大きなスケールで用法を考えてみた方がいいこと
その妄想に十分応えられる程度に生成AIを利用したソリューションの自律的なタスク計画能力は日に日に高まっていること
そして、昨今話題のAIエージェントを筆頭に、実際にその計画能力を活かして「単に質問に対して回答を返す」だけではなしにさまざまな処理を肩代わりしてくれるようなソリューションが実装段階を迎えつつあること

について話をしてきました。

前編の記事を読んでくださった方は、ぼんやり以下のことが気になっているのではないでしょうか。

データソースの整備はしなくていいのか
具体的な実装アーキテクチャはどんな具合になるのか
セキュリティやら権限管理やらはどうにかなるのか

中編では最初の二つの論点について順を追って説明していきたいと思います

必要と考えられるデータソースについて

まずデータソースについてのお話です

いくらLLMのタスク計画・実行能力が飛躍的に高まっているとはいえ、その立案の材料となる情報が貧弱では十分な働きをすることは期待できません。

この点についてはどう考えるべきでしょうか。

これから縷々、留意事項・補足事項は述べていきたいと思いますが、結論を先取りしてしまうとこの点に関しては実装を断念するほどの障害はなく

「RAGやファインチューニングのような手法でデータソースの補強が必要なケースは多々あるとは思われるが、現在出てきている技術の水準で概ねは乗り越えられるレベルのハードルであろう」と考えています。

データソースという言葉の含意

具体的に書き進めていく前に、私が「データソース」といった時に、どういったものを想起しているかを一応明記しておきたいと思います。

読者の皆さんのこれまでの業務経験によってはデータソース = RAGで用いるベクトルデータベースのようなもののみを想起する方も多いかもしれませんが

私としてはもう少し範囲を広げて、以下のようなものもデータソースとして捉えたいと考えています。

モデル内部の知識（訓練時にLLMが学習した知識）
プロンプト
- 常時参照させる固定のシステムプロンプトやinstruction
- 依頼の都度都度変動するコンテクスチュアルなユーザープロンプト
外部データソース
- ベクトルデータベースをはじめとした外部DB・ストレージ
- 参照系API
- Webページ

AWSに関するなんでも屋アプリ

前編同様「AWSに関するなんでも屋アプリ」と「社内業務をよしなにこなしてくれるアプリ」の二例で考えていきたいと思います

まず、前者についてですが、アソシエイトレベル程度の職務を担うbotであれば、実はClaudeだろうとOpenAIだろうとGeminiだろうとそんなに凝ったソースの補強をしなくても作成しうるのではないかと考えています。

根拠の一つは日常業務を通じての現行モデルの知識水準に関する手応えからです。

例えば、各社最新のLLMモデルのうち中級・上級のモデルであれば「こうこうこういう内容のリソースを作るCloudFormationのテンプレートを作成してほしい」という依頼に対しては抽象度が高いinputであってもかなり的確なテンプレートを生成してくれます。

また、私自身はAWSのソリューションアーキテクト歴が長く、設計やトラブルシューティング時にゴリゴリにLLMに頼るということは現状そこまでないのですが、そうした事項に関する社内のLLM botの受け答えをたまに眺めてみても精度は悪くなさそうです。*1

思うに、AWSに限らず、全世界的に利用されているサービス・SaaSの類であれば、各モデルの学習ソースに十分な質・量のドキュメントが織り込まれているということはある程度期待してよいとは思うので当然と言えば当然なのかもしれません*2

ソースが豊富なSaaSに関するエージェントであっても必要なチューニング

ただし、注意しなくてはいけないことはやはりいくつかあります。

最新のサービス・最新の機能に関するタスクまで適切にこなしてもらうことは当然ながら期待できません。

この水準を求めるのであれば当然「最新の公式ドキュメントをクローリングする」等の補強策が必要でしょう。

さらにもう1点。

既存環境の調査・リファクタリング・追加実装 に関する依頼をこなしてもらうことを想定する場合も是非とも考慮しなければいけない点があります。

この点の説明をするために、前編で「手抜きがある」と言い訳しておいた「エージェントのECSに関するトラブルシューティングに関する仮想フロー」を以下に再掲します。

皆さんはどこに穴があるかお分かりになるでしょうか。

Thought 1: まず、問題の全体像を把握するために、ALBとECSの基本的な状態確認が必要です。
ALBのヘルスチェック状態とECSタスクの状態を確認します。

Action 1: 
- ALBのターゲットグループのヘルスチェック状態を確認
- ECSクラスターのサービス状態とタスク数を確認

Observation 1:
- ALBのターゲットグループでヘルスチェックが失敗している
- ECSタスクは期待数通り実行中

Thought 2: ヘルスチェックの失敗が確認されました。
より詳細な原因特定のため、以下の情報を収集する必要があります：
1. ALBのアクセスログで最近のエラーパターン
2. ECSコンテナのログでnginxの状態

Action 2:
- Athenaを使用してS3のALBアクセスログを直近の30分ほど分析
- CloudWatch Logs Insightsでnginxのエラーログを確認

Observation 2:
- ALBログで大量の503エラーを確認
- nginxログで"no live upstreams while connecting to upstream"エラーを検出

Thought 3: nginx設定かアプリケーションの問題の可能性が高いです。
直近の変更履歴を確認し、問題の発生タイミングと関連付けを行います。

Action 3:
- CloudTrailでECS関連の設定変更履歴を確認
- AWS Configで構成変更履歴を確認

Observation 3:
- 30分前にECSタスク定義の更新が行われている
- メモリ設定値が何らかの理由で低く設定されていることを確認

Thought 4: 問題の根本原因が特定できました：
- タスク定義更新時にメモリ制限が誤って設定され、コンテナが頻繁にOOMKillされている
- これによりnginxプロセスが断続的に停止し、ALBのヘルスチェックが失敗している

導き出された対処方法：
1. タスク定義のメモリ制限を適切な値（前回の正常動作時の値）に戻す
2. ECSサービスを更新して新しいタスク定義を適用する

答えの一つは

詳細を把握すべきリソース・クエリ先となるべきリソース（GetやQuery系のAPIの対象となるリソース）を特定するフェーズが抜け落ちている

ことです。

全く知識の補強がない状況下の場合、Agentの実挙動としては詳細を把握すべきサービスについてまずList系のAPIを叩いて、その中から依頼に該当しそうなものをピックアップしてから追加の探索を進めていくようなアプローチが採られるでしょう。

そのピックアップ作業のヒントとなる、タグや各リソースのdescription、GlueのData Catalogといったものの設計・設定を怠ってきた環境にあっては、この時点でよしなにやってもらえる可能性は頓挫する可能性が高い。

また、たとえその種の類の設定を綺麗に整備している環境であったとしても、いちいちゼロからAgentに環境を探索させていては一つの依頼に対してかかるコストはかなり割高になってしまうでしょう。

精度を高めたり推論の負担を下げるためには、今回の例で言えば、依頼に関連するシステムの設計情報*3や、タスクを遂行する上で利用することが想定されるデータベースの種類およびそれぞれの構造情報などを前もって整備しておき、それらを推論の前半段階でスムーズに取得・連携できるような仕組みは不可欠であるように思われます。

つまりは操作対象となるリソースに関する メタデータ・メタデータストアの整備状況 がAIエージェントの円滑な利活用の鍵を握るということです。

人間にとって状況把握が容易で作業しやすい環境はAIエージェントにとっても同様であり、その逆もまた然りです。

このことは本格的な利活用を検討する初期の段階で押さえておいた方がいいポイントのように思います。

社内業務をよしなにこなしてくれるアプリ

1つ目の例と打って変わって、社内業務の効率化エージェントを考えた場合、多くの企業にとってはそれなりの作り込みが必須になるだろうと思われます。

各社毎に利用ツール(スクラッチ開発のものも多々あるものと思われます)も業務フローも千社千様であり、そのような個社特有の作法・環境情報がLLMの学習ソースに織り込まれていることは当然期待できないからです。*4

仮にマイナーなツール・自社独自のツールをフロー上で利用している場合においては、それらのツールに関する各種仕様書・運用手順書のようなものの補強は不可欠でしょう。

ただ、フローを遂行する上で操作が必要なツールについて、データソースを用意できたから大丈夫かというとそう単純な話でもありません。

以下のような作業については、エージェントがツールを十全に使いこなすための情報が提供さえすれば解決されるでしょうが

◯◯さんと△△さんとの30分間のMTGを来週のどこかで押さえてほしい
こうこうこういう要件の案件に関する見積もり書のたたき台を作成してほしい

前編の記事の例に出した出張申請のような用途を処理させることを考えた場合には、そうはいきません。

このような業務に関しては依頼したことが単に達成されればよいわけではなく言外のステップとして必須でこなしてほしいこと（上長承認、予算確認etc）があります。

また、ある工程を必ず経るということだけではなしに、その経る順番が重要になるような業務も一部には存在するでしょう。

このような「ある処理を漏れなくこなすことであったり、処理順番が重要となる業務」について我々はどう対処すればよいのか。

一つの考え方としては、以下のような情報を1レコードとして管理するフロー構造管理用のベクトルデータベースを用意して、自然言語による依頼に対して関連する可能性が高いフローをAIエージェントに抽出させた上で、その抽出したフローの構造に則って作業を進めるようにしてもらう・・・といった工夫でアプローチをしてみることが考えられます。*5

フローの概要（ベクトル化データ）
フローの構造（1ステップ1オブジェクト1要素として格納する配列。オブジェクトには期待するアクションや注意事項について記載）

かっちりした業務フローを効率化するためのワークアラウンド

ただし、個別の処理内容に関する事前定義を前提としない汎用志向のAIエージェントソリューションについて

「ある規則・構造にのっとったユーザープロンプトやjsonを伴ったリクエストを実施することにより、そこで示された『特定ステップの経由』あるいは『特定の処理順序』が守られることを100%保証するような技術・機能」は2025年2月14日の段階では未だ発明されていません。

その意味で、今日の段階では汎用志向のAIエージェントでもって全業務をカバーしきるのは本質的に限界がある と言えます。

当座の間、かっちりした業務の効率化に関しては「既存のワークフローを踏襲しつつも、そのフローの随所随所にAIエージェントや生成AIを用いたプログラムを採用して効率化を図る」ハイブリッド式のアプローチでもって臨むことになるでしょう*6。

この用途で実装するAIエージェント・プログラムに対しては各ステップでの業務を遂行する上で必要最小限・個別具体的なデータソースさえ用意すればよくなるので実現可能性の見通しはグッと立てやすくなります。

例えば、以下のような処理であれば工数削減の効力はそれなりのものを期待できつつも実装コストは比較的低く抑えられるでしょう。

各社員の申請記入・アクションの手間を省く
- 出張申請について、「申請の趣旨」に関する文章を入力しただけで、他項目については推論の上自動で記入案を埋めてもらえる
- 本来承認後に自身で行わなければいけなかった事後処理(ex.各DBへの登録処理・関係部員への連絡処理)についてAgentに肩代わりさせる
  - 実際に処理を行わせる前の作業計画を人・別Agentが承認したり、処理の事後確認を人・別Agentが行なったりするステップを明示的に設けて、安全性を高める・承認履歴/過程を残すようにする
申請を判断する管理職の判断負荷を減らす・円滑に判断するための材料を提供する
- 特定案件について与信に抵触している場合に、支払い能力以外の多面的な評価を行うために、その相手先の将来性や過去のお取引状況について調査して記述する
- 承認内容が形式的な内容に近いものなのか、熟慮を要するイレギュラーな内容なのか、診断結果・見解を申し添える

具体的な実装要領のイメージ

次に、今まで語ってきたようなソリューションについてAWSで実装にチャレンジするとしたらどのようなアーキテクチャになるかをざっくりと見ていきましょう。

色々な実装方法はあるのですが、一例を示すにあたりエージェントを実装するにあたりある程度網羅的な機能を備えておりかつ比較的実装が容易なAgents for Amazon Bedrockを中心に説明を試みたいと思います。

Step1

まず一番シンプルな形が以下のような形です。

Agents for Amazon BedrockとはAgent固有のinstructionやmemory(個々のユーザーセッションの履歴を長期に渡り保持するための機構)の内容を踏まえつつ以下のようなツールを駆使してユーザーからの指示を実行してくれるサービスなのでした。

Action Groupという複数のAPIアクションをひとまとめにした機構を通じて任意の外部APIやサーバーにアクセスさせる
- アクションの実行役はLambda関数
Knowledge baseから個社独自の情報を参照させる
API実行やKnowledge baseからのデータソース参照では実現できないラストワンマイルの処理をCode Interpreterを通じて達成する

データソースに関するセクションの段階では、私は「どのような性質のデータが必要になるか」を述べただけで、具体的な手段については言及しませんでしたが、これらのツールを利用することで基本的にはどのような外部ソースであっても推論のデータソースとして組み入れることが可能です。

また、エージェントはClaude 3.5 SonnetやAmazon Nova ProのようなLLMと連携します。

モデルの性能やinstructionの内容に質は左右はされますが、抽象的・曖昧な指示に対しても手持ちのツールの中からタスクの達成のために必要なツールを選択して、各ツールの実行結果に応じて次の振る舞いを柔軟に考える ReActライクな振る舞いがある程度期待できる味付けのサービスとなっています。

ですから、とりあえず1個のエージェントに「必要なデータソースが保存されたKnowledge base」と「必要な処理が行えるLambda関数」を多数設定してやりさえすれば、今まで本ブログで想定してきたようなソリューションをまがいなりにも立ち上げることが可能です。

Single Agentの限界

しかし、1個のエージェントで全ての業務をまかなえるようなスーパーエージェントが構築できるかというと、そのようなことはありません。

まず、2025年2月14日(金)の時点で以下の制約が存在しています。

この制約からして、極端にモノリシックなエージェントを作るようなユースケースは現状は想定されていないように思われます。

Agent 1つにつき紐づけられる Knowledge base は2個である
Agent 1つにつき紐づけられる Action Group は10個である
- https://docs.aws.amazon.com/general/latest/gr/bedrock.html
Action Group 1個につき紐づけられるLambda関数は1個であり管理できるAPIアクションも11個までである
- https://docs.aws.amazon.com/bedrock/latest/userguide/agents-lambda.html

もっとも、1つ目と2つ目の仕様はソフトリミットであるため、ある程度は上限緩和可能ではあります。

しかしながら、仮にかなりの程度の上限緩和が可能であったとしても、以下のような問題がついてまわるのでやはりモノリシックすぎる造りには「慎重になるべき」ということは言えそうです。

ある種別のサービス・APIの操作を扱うエージェントを作成するにあたって、それぞれのサービス・APIをうまく使いこなしてもらうためには固有のinstructionが必要である
- あまりにも幅広なサービス・API操作を紐づけると、1つのエージェントに与えるinstructionも膨大になってしまい、消費トークンが著しく多くなりinstructionの個々の記述の効力も薄まる結果になりかねない
1エージェントあたりの操作権限が過大になる他、チューニング・改修がしづらくなる

Step2

では、どうすればいいか？といいますと、一種のマイクロサービス化です。

すなわち

1つ1つの守備範囲は限定的なエージェントを協調して稼働させつつ、全体として大きな仕事を成し遂げられるようにすればいいのです。

この複数エージェントの協調を技術的に表現するための機能が 2024年のre:inventでプレビュー扱いでローンチされました。

それが、マルチエージェントコラボレーションの機能です。

aws.amazon.com

要約すると以下のようなイメージの機能になります。

従来型のエージェントに加えて、エージェント群をオーケストレーションする役割をもったsupervisorエージェントを作成することができる
supervisorエージェントには、他のエージェントをcollaboratorとして紐づけることができる
supervisorエージェントに対しては従来のAgents for Amazon Bedrock上でホストされたAgentと変わらぬ要領でAPIリクエストにてタスク指示が出せる
ユーザーからの指示をsupervisorエージェントが受け付けると、必要な処理に関する推論を行ったのちに、紐づけられたcollaboratorエージェント群の特性を踏まえつつ、各collaboratorエージェントに適切なタスク依頼を行う
最終的には、各collaboratorエージェントおよび自身の処理結果をそれぞれ統合・勘案して、ユーザーに対する返答を実施する

従来型のAgents for Amazon Bedrockを使ったことがある方であれば、追加の学習コストはほとんどかからない機能です*7

簡易的に図解すると以下のような具合です。*8

Bedrockのマルチエージェントコラボレーション以外にも、複数エージェントのコラボレーション・コンビネーションを意識することで高次元の効力を発揮するツール・サービスは着実に増えてきています。*9

「エージェントをある種のライブラリ・コンポーネントとして構成する」ような使い方とでも表現したらよいでしょうか。

マルチエージェントコラボレーションのような機能の存在を前提として、ある限定した業務範囲・サービスの取り扱いにおいては完璧な仕事をこなすエージェント を事前にいくつか作り込んでおき、以下のようにマルチユースで利用するような使い方が今後は徐々に浸透していくであろうと予想しています。*10

ときには単体で用いて
ときにはAというマルチエージェントコラボレーションに組み込んで使い
はたまたBという別のマルチエージェントコラボレーションにも組み込み
果てはBedrockのマルチエージェントコラボレーションの枠組み外のCというフレームワークやDというワークフローにも転用する

Step3

個々のAIエージェントの実装について、ライブラリ・コンポーネントという比喩をしましたが「可能であれば個別の環境でそれらを再構成することなく転用したい」というのが人間の心情であろうかと思われます。

この点を考える際にポイントとなるのが、Bedrockのマルチエージェントコラボレーション機能が単純な二層構造ではなく、多層構造も想定しているということです。

言い換えますと「あるワークロードではユーザーの依頼の受け口を務めるsupervisorエージェント」を「別のsupervisorエージェントのcollaboratorエージェント」として構成することもできます。

簡易的に図示してみますと以下のようなイメージです。

2025年2月14日(金)現在、Bedrockで構成したAgentは RAM の共有可能リソースの候補に含まれていませんが、恐らくはそのうち共有可能になることが見込まれます（この点についてはあくまで私個人の予想で、AWSが正式にワークロードとして謳っているのではないことはご承知おきください！！）

そうしたアカウントを跨いだエージェントの共有機能が実現したおりは、部署毎・組織毎に管理しているsupervisorエージェントを相互融通・参照するような機会も増えていくでしょう。

また、上記のような共有機能の登場を待たずに、自アカウントの外部にエージェント機能を公開したい・外部のエージェントとやり取りさせたい場合には、現時点では以下のような構成がありえます。

これは非常に単純な話で、あるエージェントへのinputをAPI経由で行えるようにして、リクエスト側が予期できるようなoutputで返すようにしてやるということですね。

Bedrockのエコシステム内で構成を完結させるのであれば、リクエスト側は上記のAPIにアクセスすることを想定したAction Groupを持ったBedrock Agentを用意してやればいいということになります。*11

コラム1：FastAPIについて

Step3の2つ目の構成図で緑の稲妻マークのロゴが気になった方がいるかもしれません。

このロゴはFastAPIというサービスのロゴです。

fastapi.tiangolo.com

ご存知でない方のために簡単に説明すると、SplingやRuby on Rails・FlaskのようなWebフレームワークの一種なのですが、今回のブログの文脈で着目すべき点は

フレームワークを通じて定義・公開するAPIについて自動でドキュメントを作成し公開することができる機能を有していること

です。

OpenAPIというREST APIの仕様を記述するためのメジャーなフォーマットがあるのですが、FastAPIは自身の定義に基づいて自らがどのようなAPIをホストしているかを表現するOpenAPIベースの仕様書を自動生成する機能を持っています。

さらには /openapi.json や /docs という所定のパスへのリクエストを通じて、「OpenAPI形式の定義情報」や「その定義情報を元に構成したAPI説明書ページ(Swagger UI)」を外部に公開することもできます。

FastAPIのようなフレームワーク*12の利用は、Agent機能の外部公開上必須の機能であるわけではありません。

ただ、FastAPIが持つこのSelf-Descriptiveとでもいうべき性質は、LLMを活用した開発と非常に相性が良いとはいえます。

例えばあるFastAPIが公開しているOpenAPIの定義情報をinputにして「このAPIがホストするそれぞれのメソッドにアクセスするための関数を記述してほしい」と高性能なLLMに指示を出せば、たちどころにそのためのコードを手に入れることができ、BedrockのAction Group用のLambdaを構築するのも楽になるでしょう。*13

また、一部のLLMサービスでは（上記のような指示を出してコードを書かせるまでもなく）OpenAPIの定義情報を提供しているAPIをシームレスにインテグレーション対象として組み込むことができるようにもなっています。*14

AIエージェント機能を公開するAPIであるにせよそうでないにせよ、今後APIのリクエスタの比率においてAIエージェントのような生成AI系のソリューションの比重は高まっていくことが予想されます。

そうしたリクエスタに正しくAPIの機能を理解してもらいスムーズにAPIを利活用してもらうにあたっては、FastAPIのようなSelf-Descriptiveなフレームワークを用いて公開を行うように意識した方が後々のためにはいいことが多いように思います。

コラム2：Knowledge baseの管理のあり方について

今回の記事で紹介したBedrockのマルチエージェントコラボレーション機能については、全てのエージェントに対してAction Group・Knowledge base・Code Interpreterの完全武装が必須なわけではありません。

例えばKnowledge baseのみと連携したエージェントがあったとしても一向に構わないわけです。*15

むしろ以下のように敢えて意識的に分離して運用した方がメリットが大きいケースも多いのではないかと私は考えています。

「外部APIを用いて環境への働きかけを積極的に行う」Agentと、「サービス・ドメインに関する深い知識・豊富なリアルデータをもとに回答を行う」Agentとを積極的に分離する
後者のAgentの保守・性能向上に専任の人員を設けてベクトル化前のソース・ETL・ベクトルデータベース・システムプロンプトの諸々のチューニング・改良に努めてもらう
- 前者のAgent機能の実装・改良に引きずられて、後者のメンテナンスがないがしろにならないようにする
- 「サービス・ドメインに関する深い知識・豊富なリアルデータをもとに回答を行う」Agentを独立・専任化することで、特定のワークロードによる無意識的な囲い込み・密結合化を避けて、複数ワークロードで共有される可能性のあるSaaS・APIに準ずるようなものであるという意識で運用する
- 外部の利用者(前者のAgentや人)の学習コストを下げる。彼らが後者のAgentが所管するサービス・ドメインについて深く理解しておらずとも適切な回答を返せるように作り込みを進めてもらう

ところで、皆さんはAgentic RAGという概念はご存知でしょうか。

weaviate.io

私は以下のような点に注意を促す概念として捉えているのですが、こうした提唱を取り込みやすくして生成AIソリューションの品質を上げていくためにも、上記のような運用は意識する価値があるように思います（上記のブログのうち「Multi-agent RAG Systems」で紹介されている構成がそのものズバリの構成であったりします）

従来型のRAGパイプラインは単一のデータソースを暗黙的に想定したものが多かったが、これからは動的に複数のデータソースを参照できるようにすべきである
- データソースの種別についても、ベクトルデータベース一種とは限らず、時には非ベクトルデータベースやWebスクレイピング、あるいは参照系のAPIが適当なケースを想定すべきである
またRAGを呼び出すタイミングについても固定のタイミング・固定の回数であるべきではなく、Agentの作業進捗・直面した課題に応じて動的に任意の回数呼び出されるべきである

小括

この中編では、さまざまな処理を肩代わりしてくれる生成AIソリューションを実装する上で必要となるであろう

「データソースの考慮の例」や「実際のアーキテクトの例」についていくらか解説を試みてみました。

正真正銘最後になるであろう後編では「セキュリティ・権限まわり」の考慮事項についていくらか触れた上で

「生成AIがプログラムを扱えて何が嬉しいのか」 という問いの答えを改めてまとめてみたいと思います

脚注

*1:みなさんもo3-mini-highやclaude3.5 sonnet v2に「このレベルのことをよしなに対処してくれるといいな」と思う事柄について、実際にタスクプランニングを尋ねてみるとよいと思います。私が直後に引き合いに出すECSのトラブルシューティングレベルの話であればファインチューニングやRAG抜きでも合格点の回答は出てきます（リンクはChatGPTのアカウントをお持ちの方のみアクセス可能です）

*2:AWSに限っていうのであれば、他のメガクラウドに先駆けてコミュニティ活動によるアウトプットを行う人材の裾野の拡大、良質な公式blogやBlackbelt等の啓蒙活動・執筆活動に力を入れてきた彼らはこの点で少し有利かもしれないということを想像してもいいのかもしれません

*3:設計wikiのような静的なdocumentでなくとも、List系のAPIでリソース一覧を取得 => それぞれのリソースについてGet系のAPI + αの処理で詳細情報を付与 => 詳細情報を付与した結果をDBに保存するようにして、そのDBを参照させる・・・みたいな形でもいいと思います（更新頻度・タイミングは要考慮ですが）

*4:この点で皆さんに思い起こしていただきたいのが

「『「製品が提供する機能に合わせて業務を変更する』のか『業務に合わせて製品をカスタマイズして導入するのか』」

というある種古典的な問題です。

この問題の題材として一番有名なのはSAPだと思いますが、社内業務のあり方についてはServiceNowも実に興味深い問題提起を行ってきた企業群の一つです。

彼らは「業界標準のワークフロー（フレームワーク）」に自社の業務をFitさせることが業務効率化のポイントの一つであると長らく提唱してきたわけですが、この「業界標準に合わせるか」「自らの企業のロジックにあくまでこだわるか」の程度は今後各企業の生き残りにおいて死活的な選択肢になる可能性があると考えています。

前者であればAgentのチューニングは軽微で済むかそもそもServiceNowのような会社（やそのエコシステムの恩恵を受けているベンダー）が高性能なAgentサービスをそもそもローンチ・提供してくれることが期待できるのに対して、後者式は個社の込み入ったロジックに合わせるためにそれなりのボリュームの個別開発が必要になるであろうからです。

私が語ったような対比はこの手の問題においてまさしく昔から語られてきた論法なのですが、LLMを使った業務効率化ソリューションの影響力の高さが見えてきた昨今においてこそ、その意義は大きくなるのではないかと考えています。つまりは、Agent的なソリューションの利活用をスムーズに開始できるか否かで「各企業の生産性・競争力には劇的な差が生じる」ことが懸念されるということです。

また「AWSに関するなんでも家アプリ」のセクションを通じて示唆したことではあるのですが、業務上利用されているサービスが「モデル内部の知識に十分に関連ドキュメントが含まれているであろう」メジャーなSaaS・ツールであるか否かも、AIエージェントを用いた業務効率化の導入・実装のしやすさに寄与するファクターになるでしょう。

この手の話題に親しみのない方は以下のようなスライド・記事も併せて参照いただければと思います

・【ServiceNow SNUG Meetup LT deck】ServiceNowのOOTBに合わせる価値を考える - Speaker Deck
・ ServiceNow導入で学ぶ OOTBを使う3つのメリット | 日経クロステック（xTECH）

*5:AWS(等の特定SaaS)の全APIの概要・用法を把握しているLLMアプリの類に関しても、特定のワークロードについてタスクプランニングがうまくいかない場合については、この種の補強を要したり・数回試行錯誤しても解決に至れない場合に人のアドバイスを求めるような仕組みで介助することを要したりというケースは多々あると思います

*6:仮に『特定の処理順序』を保証することが不可欠でないフローについても、頻繁に使うフローについては、いちいち実行のたびに処理順序を立案させるのは推論コストがもったいないですから、そういったもの（といっても結構な比重を占めると思われますが）もこうしたアプローチで効率化を図るのが良いと思われます。

*7:手っ取り早く全体像を掴みたいという方には以下のハンズオンに取り組むことをおすすめします。OpenSearch Service等を立ち上げるため検証費用はかかってしまいますが、従来型のAgents for Amazon Bedrockを触ったことのない方でもその概要を学びながら取り組めるような内容になっておりキャッチアップには最適な内容となっています

github.com

*8:あくまで直感的な把握用の簡易図解です。本当はEC2向けエージェント、VPC向けエージェント、Athena向けエージェントといったようにより細分化した方が取り回しは良くなるでしょう

*9: このブログを書いているさなかに LangChain から LangGraph Serverというマルチエージェント志向のツールが新たにリリースされました。

また、生成AI界隈では比較的以前から利用されており、ワークフロー作成ツールとして利用している方が多いであろうDifyのようなツールでも複数のエージェントをフロー内に組み込んで利用するケースはよく見られるようになってきています

例えば、Aというエージェントがコードや文章を起票して、後続のBというエージェントが特有の観点から品質を評価・フィードバックをおこない、結果によってフィードバックを添えてAに差し戻したり後続フローにつなげたりといったような実装です

*10:AWS Serverless Application Repository のようなものでコンポーネント用Agentの展開用ソリューションを目にすることも今後増えていくかもしれません。

*11:API GatewayはMarketplaceを通じてSaaS的に外部に公開・販売することが可能です

*12:FastAPI以外のフレームワークについても、メジャーなフレームワークであればプログラミング言語の種別を問わずOpenAPI形式の定義情報を出力させるようなプラグインがあるものが多いので、そのようなものを利用する形でもいいと思います

*13:もっとも、LLMの力を借りずとも、このようなことを便利に実現できるツールは各言語ごとにいくつかあります(例えば弊社のフロントエンドエンジニアの一部は Orvalというツールを用いています)

しかしながら、前編で紹介したようなDevinやclineといった開発エージェントにプログラム実装をかなりの程度依存するようになる未来を考えると、APIの定義情報が楽に得られることは彼らの実装精度の向上・工数の削減につながっていくと思います

*14: 別の脚注でも言及したDifyでは OpanAPIの定義書を読み込ませるだけでそのAPIに関する操作ツールをSaaSに追加できます

また、LangServeというLangChainが提供するパッケージでは、LangChain・LangGraphを使って構成された一連の処理(Chain)の中に、リモートにホストされたFastAPI上のLangChain処理を便利に組み込む機能を提供しています（ただし、ごく最近のLangChainは自社のクラウドプラットフォームであるLangGraph Platform上で生成AI開発のワークロードを包括的に管理させる方向にユーザーを誘導したがっているようで、LangServeは「バグfix等のメンテナンスはするが機能アップデートはしない」という微妙な位置付けにされてしまっています）

そのほか、Semantic Kernelというアプリ上にLLM機能を組み込みやすくするために提供されているSDKでは、Agents for Amazon BedrockでいうところのAction Group(このSDKの用語系ではPlugin)を簡単な定義で用意することができます

*15:もっというと、外部リソースに接続するための連携は一切なしの「単に固有のinstructionのみを備えたエージェント」を作るのもアリです。例えば特定のロールを与えてinputの判定・評価をさせたり、特定の品質・種別のコンテンツを生成させたりといった具体です