AIエージェントについてまとめてみた

・AIエージェントとはなにか？
・AIエージェントの現在地はどこか？
・AIエージェントに関連した注目技術トレンド
・AIエージェントの課題と今後

Transcript

1. AIエージェントについてまとめてみた 2025.02.04 #pharmax_tech
2. （C）PharmaX Inc. 2024 All Rights Reserve 2 自己紹介 上野彰大 PharmaX共同創業者・エンジニアリング責任者 好きな料理はオムライスと白湯とコーラ マイブームはLLMとRust X：@ueeeeniki
3. （C）PharmaX Inc. 2024 All Rights Reserve 3 個人でも勉強会コミュニティ StudyCoも運営 自己紹介
4. （C）PharmaX Inc. 2024 All Rights Reserve 4 自社としては LLMを中心に勉強会を月 1回程度開催 自己紹介
5. （C）PharmaX Inc. 2024 All Rights Reserve 5 医療アドバイザーに体調 のことをいつでも気軽に相 談できる 相談型医療体験 30種類以上の漢方薬からあ なたに合ったものを月毎に 提案 パーソナライズ漢方薬 定期的に漢方をお届けし、 一人ひとりに寄り添うかか りつけ医療を提供 継続的なかかりつけ 一生涯にわたって寄り添うかかりつけ漢方薬局「 YOJO」
6. （C）PharmaX Inc. 2024 All Rights Reserve 6 患者向けチャットシステムと薬剤師向け管理画面を自作 患者とのスムーズなコミュニケーション 薬剤師向け管理画面 チャット形式での診断・相談・購入 患者向けチャットシステム
7. （C）PharmaX Inc. 2024 All Rights Reserve 7 YOJOで稼働する OTC医薬品相談 AIエージェント 患者さまからの一次対応をすべて AIエージェントが行う（裏側では百近いのプロンプトが稼働） 基本的にはメッセージを自動送信し、必要があれば薬剤師に承認を求める 一次的な漢方選択や、こちらから送信する体調確認などもエージェントが自律的に作成 薬剤師に重要な 返信や判断の確認を依頼 一次的な漢方選択なども行う 薬剤師が返信する場合もある AIエージェント 薬剤師 ユーザー AIが人に指示をするような体験
8. （C）PharmaX Inc. 2024 All Rights Reserve 8 YOJOにおけるAgentic Workflow（フローエンジニアリング） ① ② ④ • ①ルールベースでLLM処理可能かを 判定 • ②LLMで会話を分類しLLM処理可能 かを判定 • ③LLMで次のフェーズに移るべきかど うかを判定 • ④LLMでメッセージを作成 • ⑤LLMで作成されたメッセージを評価 （LLM-as-a-Judge）し、一定の水準を 下回ったら再生成して、クリアしたもの のみをサジェストする 現時点では精度高く メッセージ提案できない ため薬剤師が対応 ③ ⑤ ※②〜⑤： GPT-4o
9. （C）PharmaX Inc. 2024 All Rights Reserve 9 • 適した漢方の選択 • 漢方に関しての説明 • 飲み合わせの判断 YOJOで自動化or半自動化されている業務 • 購入までのオンボーディング • パーソナライズされたプラン提案 • 販促のためのリマインド • 配送等の問い合わせ対応 • 継続的な健康相談 • 漢方の変更判断 • 体調確認のためのリマインド • 患者ごとのサマリーの更新 • 副作用等への対応 YOJOではさまざまな業務の自動化 or半自動化を実現している
10. （C）PharmaX Inc. 2024 All Rights Reserve 10 LangGraphで実際に構築したグラフ ルール1 ルール2 LLM-メッセージ作成 _ 分類4 LLM-会話分類 LLM-メッセージ作成 _ 分類1 LLM-メッセージ作成 _ 分類2 LLM-メッセージ作成 _ 分類3 LLM-フェーズ切替 LangGraphで作成したグラフはmermaidで出力しテストにも使用している
11. （C）PharmaX Inc. 2024 All Rights Reserve 11 LangSmithによるトレーシング rule1 ① ② ③ ④ ⑤ ・・・ rule2 ④ ⑤ ① ② ④ ③ ⑤ ※②〜⑤： GPT-4o
12. 12 （C）PharmaX Inc. 2024 All Rights Reserve AIエージェントとは
13. （C）PharmaX Inc. 2024 All Rights Reserve 13 • 2024年末から2025年頭にかけて急激にAIエージェントという言葉がバズったが、「そもそも AI エージェントとは何のか？」ということもよく分からない ◦ なんとなく「人間がお願いしなくても業務を自動化してくれる AI」というぐらいの理解にとど まっている人が多そうな印象 → AIエージェントの定義について踏み込んで考察する • なぜ急にAIエージェントが叫ばれるようになったのか、今後どのように AIエージェントが発展して いくのか？がよく分からない ◦ 結局AIエージェントが出現くる中で、個人のビジネスパーソンとして、あるいは企業としてど のように振る舞っていくべきかがみなさんの知りたいことだと想定 → AIエージェントを取り巻く技術トレンドと今後の発展の予想について大枠を述べる はじめに〜本日のアジェンダ 2025年にはAIエージェントが流行ると言われているが、実際のところどうなの？というのが本日のお話
14. （C）PharmaX Inc. 2024 All Rights Reserve 14 エージェントとは何か？ • 「情報の認識」とアクションをループさせると、人間が調整せずともアプリケーションに自動的に作業させること ができる • 物理的な「自動音声調整装置」もエージェントと言うことができるかも？ （知覚した温度が目標よりも低いと温度を上げ、高いと温度を下げる装置） 参考：https://speakerdeck.com/os1ma/imakosoxue-bullmbesunoaiezientoru-men-ji-ben-de-nasikumi-slash-kai-fa-turu-slash-you-ming-naossyalun-wen-noshao-jie 情報の認識 アクション アクションした結果も 環境情報として認識する
15. （C）PharmaX Inc. 2024 All Rights Reserve 15 メディアでも AIエージェントが取り上げられている
16. （C）PharmaX Inc. 2024 All Rights Reserve 16 AIチームメイト（エンジニア） Devin
17. （C）PharmaX Inc. 2024 All Rights Reserve 17 Softbankが発表した Cristal構想
18. 18 （C）PharmaX Inc. 2024 All Rights Reserve Agentic WorkflowとAIエージェント
19. （C）PharmaX Inc. 2024 All Rights Reserve 19 プロンプト内に タスクのルールや 選択肢を明示する Agentic Workflow（フローエンジニアリング）とは • Agentic WorkflowとはLLMの組み合わせをデザインし、目的とする処理系を作り上げること • 途中で人が対応することがあってもいい • Agentic Workflowのようにワークフローを組むパターンはエージェントと呼ばないのでは？という指摘もある 分類タスク タスクA タスクB タスクC タスクD タスクE タスクF 分岐 人の承認を挟む 途中から人が引き継ぐ 分類結果によって 分岐させる
20. （C）PharmaX Inc. 2024 All Rights Reserve 20 完全自律型の AIエージェント 情報の認識 アクション • 必要な情報収集もアクションの決定も完全に自律的に決め、「内部的にかなりの自由度を持ち、必要ならプログ ラムも書き足して外部ツールを連携して …といった振る舞いができる」レベルのものを完全自律型と呼ぶこととす る アクションした結果も 環境情報として認識する 必要な情報を自由に収集 アクションも自由に考えて決定する
21. （C）PharmaX Inc. 2024 All Rights Reserve 21 • ユーザー目線 ◦ ユーザーがタスクを指示したあとは「ほぼ放っておいても結果を出してくれる」のであれば、 ユーザーからは“自律的に動いている”ように見える ◦ たとえ開発者が裏でワークフローを定義していようが、ユーザーが都度コマンドや選択を指 示しなくても動いてくれるのであれば、「エージェントっぽい」 • 開発者目線 ◦ “（開発者も含め）誰も行動手順を制御していないほど自由に動ける ”のがエージェント ◦ 「内部的にかなりの自由度を持ち、必要ならプログラムも書き足して外部ツールを連携して …といった振る舞いができる」レベルのものをエージェントと呼ぶべき 誰の目線からみて自律的なのか？という軸で整理 ユーザー目線で見るか、開発者目線で見るかによって意見が変わってしまっているように感じる
22. （C）PharmaX Inc. 2024 All Rights Reserve 22 ハイブリッド型もあり得ることには注意 下記のようなハイブリッドな設計自体も不可能ではない • ワークフローで分岐させたここから先は、 “完全自律型エージェント的な柔軟さ ”も混ざっている • 基本的には、ワークフローを構築するけれども、自律的に判断できる余地も残しておく
23. （C）PharmaX Inc. 2024 All Rights Reserve 23 AIエージェントと呼ぶかどうか • ユーザー目線で見れば、ワークフロー型もハイブリッド型も AIエージェントと呼ぶ • 開発者目線で見れば、完全自律型しか AIエージェントとは呼ばない という整理ができそう ハイブリッド型 完全自律型 ◯ ◯ ✕ ◯ ユーザー目線 開発者目線 ワークフロー型 ✕ ◯
24. 24 （C）PharmaX Inc. 2024 All Rights Reserve ルール設定・ワークフロー構築という現実解
25. （C）PharmaX Inc. 2024 All Rights Reserve 25 各LLMにルールやガードレールを定義するメリット 判断に必要な情報と判断基準が与えら得れているので、判断が正確になるかつ安定する • 性別、年齢、身長、体重などの基 本情報 • 体質に関する質問への回答 • ユーザーの好みの剤形（顆粒か 錠剤かなど） …etc {情報}を下に下記からユーザーに 合った漢方を選択してください ・A ・B ・C …etc ✕ 選択肢 選択 情 報 判 断 基 準 アクション 情報の認識
26. （C）PharmaX Inc. 2024 All Rights Reserve 26 自律的なアクションの決定 外部システム との連携 完全自律型のデメリット 情報の認識 過去の行動実績やDBの情報から毎度アクションを考える必要があるので不安定かつ負荷がかかる 自律的な • 状況判断 • 判断基準の策定 • 必要な情報収集 アクション 自分の状況 DB • ユーザー情報等 • 過去の行動ログ
27. （C）PharmaX Inc. 2024 All Rights Reserve 27 ワークフローを構築するメリット 分類タスク タスクA タスクB タスクC タスクD タスクE タスクF 分岐 ✕ 落ちた時に 途中から人が引き継ぐ パターンに切り替える デバッグできる 遂行できなかった ワークフローを構築しているので正確かつ、人間がデバッグや引き継ぎもしやすい
28. （C）PharmaX Inc. 2024 All Rights Reserve 28 完全自律型のデメリット 分類タスク タスクD タスクE タスクF 分岐 タスクB&C タスクA これまでの人間の想定と かけ離れたワークフロー 落ちた時に 途中から人が 引き継げない ✕ 遂行できなかった デバッグ不可 人間の想定とかけ離れた方法で作業をされると、失敗したときにデバッグや引き継ぎも難しい
29. （C）PharmaX Inc. 2024 All Rights Reserve 29 AIエージェントに関する私の個人的意見のまとめ • ワークフローを定義するAgentic Workflow型のAIアプリケーションをAIエージェントと呼ぶべき かどうかというAIエージェント定義論争は個人的にはどちらでもいい • 現時点の技術では、複雑な業務を安定的にこなすには、ある程度のワークフローを定義するのが 現実解ではないか • ユーザーから見て「ほぼ放っておいても結果を出してくれる」「勝手にタスクを実行してくれる」こと で実際に価値が出ているのであれば、裏側がどう作られていようともいいはず ◦ エージェント原理主義の方には申し訳ないが、ユーザーから見て（一部ユーザーに判断を仰 いだとしても）自律的であれば、 AIエージェントと呼ぶのが主流になるだろうと想定している 裏側の仕組みはどうでもよく、最もユーザーに価値が出るように作ればいいはず
30. 30 （C）PharmaX Inc. 2024 All Rights Reserve 他の“AIエージェント ”について調査
31. （C）PharmaX Inc. 2024 All Rights Reserve 31 コーディング AIエージェントの Cline / Roo Code 今回はClineをForkしたRoo Codeを実演します https://youtu.be/Fd_UK0zhhAQ?si=3aV7yB4Qol4BcjZH
32. （C）PharmaX Inc. 2024 All Rights Reserve 32 Roo Codeのコードの解説 Roo Codeもある程度のルール /ワークフローが定義されている 1. 基本的な役割定義： ◦ Rooという名前の高度なスキルを持つソフトウェアエンジニアとして定義されている 2. ツールの定義と使用のルール： ◦ read_file, search_files, list_filesなどのツールが利用可能 ◦ 1メッセージにつき1つのツールのみ使用可能 3. タスク実行の方法論： ◦ ユーザーのタスクを分析し、明確な目標を設定 ◦ 目標を順序立てて実行 ◦ タスク完了時はattempt_completionツールを使用 4. 重要な制約事項： ◦ 質問はask_followup_questionツールを使用してのみ可能 https://github.com/RooVetGit/Roo-Code/tree/main
33. （C）PharmaX Inc. 2024 All Rights Reserve 33 object.tsのプロンプト 効率的にタスクを実行するための基本的な行動指針を記載 目的 あなたは与えられたタスクを反復的に実行し、明確なステップに分解して、体系的に取り組みま す。 1. ユーザーのタスクを分析し、それを達成するための明確で実現可能な目標を設定します。これら の目標を論理的な順序で優先順位付けします。 2. これらの目標を順番に実行し、必要に応じて利用可能なツールを一度に1つずつ使用します。各 目標は、問題解決プロセスの個別のステップに対応する必要があります。作業の進捗状況と残り の作業について随時報告を受けます。 3. 各目標を達成するために必要な、広範なツールへのアクセス権を持っており、それらを強力か つ賢明な方法で使用できることを覚えておいてください。ツールを呼び出す前に、 <thinking></thinking>タグ内で分析を行ってください： - まず、environment_detailsで提供されているファイル構造を分析して、効果的に進めるための コンテキストと洞察を得ます - 次に、提供されているツールの中から、ユーザーのタスクを達成するために最も関連性の高い ツールを検討します - その後、関連するツールの必要なパラメータそれぞれについて、ユーザーが直接提供している か、または推測するのに十分な情報を提供しているかを判断します - パラメータを推測する際は、すべてのコンテキストを慎重に検討して、特定の値をサポートして いるかどうかを確認します - 必要なパラメータがすべて存在するか、合理的に推測できる場合は、thinkingタグを閉じてツー ルの使用を進めます - ただし、必要なパラメータの値が1つでも欠けている場合は、ツールを呼び出さず（欠けている パラメータにフィラーを使用することもしない）、代わりにask_followup_questionツールを使用して ユーザーに不足しているパラメータの提供を求めます - オプションのパラメータについては、提供されていない場合、追加情報を求めないでください 4. ユーザーのタスクを完了したら、attempt_completionツールを使用してタスクの結果をユーザー に提示する必要があります。また、タスクの結果を示すCLIコマンドを提供することもできます。これ は特にWeb開発タスクで有用で、例えば `open index.html` を実行して構築したウェブサイトを表 示できます。 5. ユーザーからフィードバックを受け取った場合、それを使用して改善を行い、再試行することが できます。ただし、無意味な往復会話は続けないでください。つまり、応答を質問や更なる支援の 申し出で終わらせないでください。
34. （C）PharmaX Inc. 2024 All Rights Reserve 34 read-file.tsのプロンプト ファイルを読む際のルールを記載 ## read_file 説明：指定されたパスにあるファイルの内容を読み取るためのリクエストです。既存のファイルの内 容を確認する必要がある場合に使用します。例えば： - コードの分析 - テキストファイルの確認 - 設定ファイルからの情報抽出 出力には各行に行番号が付与されます（例："1 | const x = 1"）。これにより、差分の作成やコード についての議論の際に特定の行を参照しやすくなります。PDFやDOCXファイルからは自動的に 生テキストを抽出します。他の種類のバイナリファイルには適していない場合があります（内容を文 字列として返すため）。 パラメータ： - path：（必須）読み取るファイルのパス（現在の作業ディレクトリ ${args.cwd} からの相対パス） 使用方法： <read_file> <path>ファイルパスをここに記入</path> </read_file> 例：frontend-config.jsonの読み取りをリクエストする場合 <read_file> <path>frontend-config.json</path> </read_file>
35. （C）PharmaX Inc. 2024 All Rights Reserve 35 attempt-completion.tsのプロンプト ツールの使用結果を表示するルールを記載 ## attempt_completion 説明：各ツールの使用後、ユーザーはそのツールの使用結果（成功したか失敗したか、失敗の理 由など）を回答します。ツールの使用結果を受け取り、タスクが完了したことを確認できたら、この ツールを使用してあなたの作業結果をユーザーに提示してください。オプションとして、作業結果を 示すCLIコマンドを提供することもできます。ユーザーが結果に満足していない場合、フィードバック を提供することがあり、それを基に改善して再試行することができます。 重要な注意事項：このツールは、以前のツールの使用が成功したことをユーザーから確認するま では使用できません。これを怠ると、コードの破損やシステム障害の原因となります。このツールを 使用する前に、<thinking></thinking>タグ内で、以前のツールの使用が成功したことをユーザー から確認したかどうかを自問する必要があります。確認していない場合は、このツールを使用しな いでください。 パラメータ： - result：（必須）タスクの結果。この結果は、ユーザーからの追加入力を必要としない最終的な形 で記述してください。結果を質問や更なる支援の申し出で終わらせないでください。 - command：（オプション）結果のライブデモをユーザーに表示するためのCLIコマンド。例えば、作 成したHTMLウェブサイトを表示するには `open index.html` を使用したり、ローカルで実行中の 開発サーバーを表示するには `open localhost:3000` を使用したりします。ただし、単にテキストを 表示するだけの `echo` や `cat` のようなコマンドは使用しないでください。このコマンドは現在のオ ペレーティングシステムで有効である必要があります。コマンドが適切にフォーマットされており、有 害な指示が含まれていないことを確認してください。 使用方法： <attempt_completion> <result> 最終結果の説明をここに記述 </result> <command>結果を示すコマンド（オプション）</command> </attempt_completion> 例：結果とコマンドを含む完了の試行要求 <attempt_completion> <result> CSSを更新しました </result> <command>open index.html</command> </attempt_completion>
36. （C）PharmaX Inc. 2024 All Rights Reserve 36 カスタムルールの記述 より安定的にタスクを遂行させようと思うと、結局はカスタムルールを丁寧に記述する必要がある https://zenn.dev/berry_blog/articles/c72564d4d89926 • 育てていくような感覚で自分 /自社なりのルール を記述する必要がある ◦ この記事のように自動でルールを更新す れば、ある程度勝手に学んでくれているよ うな感覚を得ることは可能
37. 37 （C）PharmaX Inc. 2024 All Rights Reserve AIエージェントの注目トレンド
38. （C）PharmaX Inc. 2024 All Rights Reserve 38 • マルチモーダルにより、これまでデータ化できていなかった情報までも取り込んで判断できるよ うになる ◦ DXが一定進んだ現在でもまだデータ化出来ていない情報というのは多く存在する • browser useやcomputer useによりAPI連携せずとも複数ツールをまたいだ操作の自動化 が可能に ◦ 各作業でどのようなツールを使っているかも関係ない • LLMの思考力向上とコンテクストサイズの増加によって、複雑なワークフローを組む場合でも 少ないプロンプト数で実現可能に AIエージェントの進化に関連する技術トレンド AIエージェントの進化を考える上では、下記のような技術トレンドに注目している
39. （C）PharmaX Inc. 2024 All Rights Reserve 39 マルチモーダルによって扱える情報が増える マルチモーダルによりこれまでデータ化できていなかった情報までも取り込んで判断できるようになる データ 判断基準 output • 現在時刻の予約情報 • 注文状況 • 最大キャパ（席数） D B 情 報 ✕ 非 D B 情 報 input 選択 受け入れ可 受け入れ不可 電話受付 AIエージェント 今から行って 空いてますか？ 店内の様子 キッチンの様子 現在時刻30分前以降の予約 者は全員来店されていない と仮定しても、 十分に席数に余裕があれば 受け入れ可能 しかし、注文が溜まっており、 キッチン人員的に早期に捌 けないようであれば、お待た せする可能性が高いことをお 伝えする
40. （C）PharmaX Inc. 2024 All Rights Reserve 40 複数業務・ツールをまたいだ AIエージェントの実現 例としてAlgomaticさんのリクルタAIを取り上げさせていただきます https://www.youtube.com/watch?v=nJWMCLn_WF8
41. （C）PharmaX Inc. 2024 All Rights Reserve 41 複数業務・ツールをまたいだ AIエージェントの実現 候補者の選定からスカウトの送信というまで一連のワークフローを自動化してくれる
42. （C）PharmaX Inc. 2024 All Rights Reserve 42 AIエージェントは SaaSを飲み込むか • AIエージェントがSaaSを操作するようになると、SaaSのUI/UXは人の使用を前提としていた時 ほどは競争優位性ではなくなる可能性はある ◦ SaaSは所詮データベースのラッパーに過ぎないと考えることもできる ◦ 社内業務用のSaaSを考えると、どのSaaSを使っても必要なデータが貯まれば同じという 考え方もできるようになる ◦ 一方で、人材系のマッチング（スカウト）ツールのように DBの量や質そのものに差がある 場合には、これまで通り十分価値になり得る • 今後は、既存SaaSをまたがって業務を自動化するAIエージェントの開発競争に入る ◦ browser useやcomputer useもしばらくは安定しない上にワークフローごとの業務の複 雑さも存在するので、少なくとも1〜2年程度は開発力による使い勝手の差分は発生する と予想 browser useやcomputer useによりAPI連携せずとも複数ツールをまたいだ操作の自動化が可能に
43. （C）PharmaX Inc. 2024 All Rights Reserve 43 マルチモーダル &browser/computer useによる扱える情報が増える APIやサービス連携でDBにアクセスするのではなく、直接 browser/computer useでデータを読み取る データ 判断基準 output • 現在時刻の予約情報 • 注文状況 →SaaSの画面を読取可 • 最大キャパ（席数） D B 情 報 ✕ 非 D B 情 報 input 選択 受け入れ可 受け入れ不可 電話受付 AIエージェント 今から行って 空いてますか？ 現在時刻30分前以降の予約 者は全員来店されていない と仮定しても、 十分に席数に余裕があれば 受け入れ可能 しかし、注文が溜まっており、 キッチン人員的に早期に捌 けないようであれば、お待た せする可能性が高いことをお 伝えする 店内の様子 キッチンの様子
44. （C）PharmaX Inc. 2024 All Rights Reserve 44 プロンプト内に タスクのルールや 選択肢を明示する Agentic Workflowのアーキテクチャの簡略化 • これまでは精度とコンテキストサイズの問題から下記の各タスクを別々のプロンプトととして実装することが多 かった • タスクAのプロンプトの後にタスク Bのプロンプトを呼び出してというのをアプリケーション側で実装する必要が あった 分類タスク タスクA タスクB タスクC タスクD タスクE タスクF 分岐 人の承認を挟む 途中から人が引き継ぐ 分類結果によって 分岐させる
45. （C）PharmaX Inc. 2024 All Rights Reserve 45 複雑なタスクを少数のプロンプトで行わせる すでに実行済みのタスクも管理しながら複雑なタスクを少数のプロンプトで行う ## 分類タスク ### ワークフロー甲に分類されるルール 〇〇〇〇〇〇 （略） ーーーーーーーーーーーーーーー ## ワークフロー甲 ワークフロー甲は下記の順番で実行する。 ### タスクA 〇〇 ーー ### タスクB □□ （略） ーーーーーーーーーーーーーーー 現在のタスクの進捗状況: {実行済みタスク} 次に実行すべきタスクとその結果をoutputしてください。 {“role”: “assistant”, “content”: {“分類”: 甲}} {“role”: “assistant”, “content”: {“タスク”: “A”, “result”: “xxxxxxxx”}} {“role”: “assistant”, “content”: {“タスク”: “B”, “result”: “xxxxxxxx”}} {“role”: “assistant”, “content”: {“タスク”: “C”, “result”: “xxxxxxxx”}} {“role”: “system”, “content”: {左のプロンプト}} 下記のように会話履歴の形式で与えることもできる
46. （C）PharmaX Inc. 2024 All Rights Reserve 46 プロンプト内に タスクのルールや 選択肢を明示する Agentic Workflowのアーキテクチャ 分類タスク タスクA タスクB タスクC タスクD タスクE タスクF 分岐 人の承認を挟む 途中から人が引き継ぐ 分類結果によって 分岐させる プロンプト数を減らして簡単なアーキテクチャにできる • これまでは精度とコンテキストサイズの問題から下記の各タスクを別々のプロンプトととして実装することが多 かった • タスクAのプロンプトの後にタスク Bのプロンプトを呼び出してというのをアプリケーション側で実装する必要が あった
47. （C）PharmaX Inc. 2024 All Rights Reserve 47 非エンジニアでも十分 Agentic Workflowを実装できる時代に Difyのようなノーコードツールを使えば Agentic Workflowを実装できる 参考：https://speakerdeck.com/os1ma/imakosoxue-bullmbesunoaiezientoru-men-ji-ben-de-nasikumi-slash-kai-fa-turu-slash-you-ming-naossyalun-wen-noshao-jie
48. 48 （C）PharmaX Inc. 2024 All Rights Reserve AIエージェントの課題と将来
49. （C）PharmaX Inc. 2024 All Rights Reserve 49 【課題】AIエージェントの権限管理は非常にややこしい論点 情報へのアクセスを正しく制御するだけではなく、アウトプットにも余計な情報が混ざってはならない データ 判断基準 output D B 情 報 ✕ 非 D B 情 報 input 選択 アクションA アクションB AIエージェント 〇〇の場合はAをして ✕✕の場合はBをする … 適切なデータへのアクセス 適切な情報の開示 /アクション 権限は下記の組み合わせで 管理する必要がある • 会社のルール • 遂行する業務 • 人（職種/役職など）
50. （C）PharmaX Inc. 2024 All Rights Reserve 50 【課題】AIエージェントの普及を妨げるものはなにか 経済全体にインパクトをもたらすには、革新がもう数段階必要だが、土台は十分に整いつつある • 業務特化したエージェントではなく、様々な業務を行える汎用的なエージェントをつくるためには、メモリの 仕組みとFBループを高速化する仕組みに革新が必要 ◦ メモリがClineやDevinのようにテキストで更新されていくだけでは、業務ごとにルールを更新する必 要があり、特化型の方が安定しそう（巨大なコンテクストサイズと性能向上だけで解決するだけの問 題なのかもしれない） ◦ 仮に業務のルールを記憶できる仕組みが作れたとしても、人間が FBしている以上、”育てる”のに時 間がかかってしまうので、シミュレーションして評価して報酬を与える強化学習のような仕組みが各 社の業務ごとに用意できるといいのかもしれない • AIエージェントはエージェントが人に指示をすると捉えると分かりやすい（人間 calling）が、時点でエージェ ントが指示しやすいのは大人しく PCの前に座って仕事している人間のみ ◦ 多くの労働は決してPCの前だけでできるものではない ◦ エージェントが機械やロボット、自動車などに指示できるようになればインパクトは大きい
51. （C）PharmaX Inc. 2024 All Rights Reserve 51 • 2025年時点では、完全自律型ではなく、業務特化である程度のワークフローやルールを与える ユーザー視点での”自律”型エージェントが現実解 • マルチモーダルによりこれまでデータ化できていなかった情報を扱えるようになり、 browser/computer useが既存のシステムを操作できるようになったことで一部の業務は十分 自動化できるようになる ◦ SaaSの立ち位置がこれまでとは大きく変わる可能性 ◦ 一方で、PC仕事以外の多くの仕事はまだ自動化できずに残る • 業務特化ではない汎用的なAIエージェントが安定的に動く世界になるにはまだ少し時間がかか るが、決して夢ではないところまで来ている まとめ 2025年のAIエージェントの現在地と今後の発展をまとめると以下の通り
52. 52 （C）PharmaX Inc. 2024 All Rights Reserve 宣伝
53. （C）PharmaX Inc. 2024 All Rights Reserve 53 ドラッグストア様等への提案サマリー サマリー 初期 ディスカッション PoC 評価 より発展的 取り組みへ • PharmaXが35万人のユーザ数を誇る自社サービス「 YOJO」で培った生成 AI ノウハウを医療業界に広めていきたい • 特に、企業と顧客間の ”エンゲージメント ”を向上するノウハウと技術を活用す ることで、ドラッグストア様が提供する既存サービスの LTVや顧客満足度を高 められると考えております • 初期的には、比較的導入ハードルが低く ROIが明瞭な領域から PoCの開発・ 実施・評価を行うことを想定しており、初期的な議論を行いたい