AIエージェント自作

Transcript

1. AIエージェント自作 5/16 大LT
2. 自己紹介 名前:ナツ 最近の趣味:SFアニメ見ること 一言: LT半年ぶりだから10分に収めるの大変 twitter: @mtdnot
3. 経緯 先輩からリクエスト来てたのでAIの作り方をLTのネタにするかってなった LLMは無理だが、AIエージェントの作ってみたい
4. AI agentの例
5. AIエージェントの大まかな設計について伝えること - LLM APIの抽象化レイヤー - エージェントの手足 - 承認フロー
6. エージェント3分クッキング
7. LLM API抽象化レイヤー - 各プロバイダーで APIの形式が異なる - モデルを変えたい時に ここの設定で変えたい
8. プロバイダー間で仕様違う問題 APIを送る時のリクエスト // OpenAI / Anthropic { role : “user”, content : “質問” } // Google { role : “user”, parts: [{ text: “質問”}] }
9. データこねこねしてどのプロバイダーも同じ仕様にする 原則はどのプロバイダーでも共通
10. おすすめのツール この辺の実装をしてくれているもの - LiteLLM（今回使った） - Vercel AI SDK - aws Bedrock(awsと相性良く認証周り強い) そもそもプロバイダー自体を統合しているプロバイダー - OpenRouter
11. できたもの(テキストを返してくれるもの)
12. Function Calling（外部ツール呼び出し） toolCalls?: ToolCall[]; // 使用されたツールの呼び出し LLMがどのツールをどう呼ぶかの決まり 例： { “name” : “readFile”, “arguments” : {“path : “README.md”} }
13. ツールの作成(AIの手足) - 定義(JSON Schema) LLMの説明書 - 処理(TypeScript) CLIツール作る感じ - サンドボックス 権限や制約の管理
14. ツールの定義 ツールの概要と使い方をJSON Schemaで記述する
15. ツールの実装 　ファイルの読み込み 　ファイル操作ライブラリに - 容量制限(コンテキスト保護 ) - サンドボックス - 例外処理 　を追加したもの
16. サンドボックスとコンテキスト保護
17. ツールの実行 3. tool_callsでモデルがwikiを読まないと答えられないと判断 4. tool_results=1で1件の読み取り結果を取得した 5. massages=4 LLM自体はステートレス、会話内容覚えてない。 　だから、直近2件のメッセージとツール呼び出しと結果を送信 6. 最終的な答えを送信
18. なぜか処理速度１０倍になった 最低限の機能・情報しか入れてないため 特定の条件なら結構早くなる
19. ちなみに合ってる
20. システムとAIエージェント 運用 5/16 大LT
21. ところで 安全にAI使ってますか？
22. 最近の出来事：AIに管理者権限を剥奪された事件 権限管理はしっかりしないといけないと思った
23. 承認フローの実装 ツール定義に承認が必要なコマンド(書き換え、削除など)は、設定を加える。 ツール実行時に、ここをチェックすることで、安全装置を作る
24. </エージェント3分クッキング終わり> CUIだけだと日用使いが大変なので、 次はこれを運用し続けるためにGUIで実装します
25. エージェント開発で大事なこと（唐突） - AIエージェントの実用化例はすごく少ない 一部のスタートアップが公開しているブログか 論文から実装する必要がある - AIエージェントはコンピュータ上で人間とほぼ同じ なので、社内サービスの構築例などを参考にする
26. 承認フロー 承認フローってどうやって仕組み化するんやろ？ せや！ググるか！ ( ・∇・)
27. ワークフローシステム 承認フローを含め、業務フローをワークフローシステムというもので動かしているらしい。 また、ワークフローエンジンなるもので動いてるらしい
28. ワークフローエンジン Inngest - API豊富 - イベント駆動 - TypeScript / Python / Go に対応
29. 承認画面作成 ローコードでウェブアプリを作れるソフトを使う 　AIで書かせるより、いくつか優れている - 運用・保守 - 修正の早さ - 楽さ
30. appsmith - 社内向けウェブツール作るやつ - いろんなデータソースと繋がる （今回はREST APIだけ 外部サービス目的ならn8nも良い） - ローコードで楽 - OSS
31. 制作過程
32. 30分格闘して できた
33. ログ
34. ワークフローエンジンとか追加すると何が嬉しいか 以下のような責任（機能）を外部に任せることができること 関心の分離、責務の分離とかって言われる - いつエージェントを起動するか - どのようなフローで処理をするのか - LLMの性質上ステートレスであるから、外部に状態を持たせる。 - 通知、監視、管理のための機能を実装しなくて良い！ <-ここ大事 次のスライドでAIの外部で機能追加した例を紹介します。
35. 通知 _AI_
36. みんなでAIを活用するには - なんのサービス使ってたっけ - どう使うっけ - どういうアーキテクチャで 動いてるんこれ エージェントのための マニュアル作り大変 ->どこかでまとめる必要がある ↑なんか知らんが裏側で動きまくっ てるソフトウェアたち
37. IDP(内部開発者プラットフォーム) 引用:https://www.sbbit.jp/article/cont1/132753
38. Backstage サービスの一元化 - github repo - openapi - docs - 依存サービス - … などの情報をまとめられる プラットフォームエンジニアリングの実践例としてよく語られる (spotifyが社内のサービス管理するために開発した)
39. 承認フローをポータルで実用化した（iframeで接続してるだけ）
40. 何が嬉しかったの？ - サービス間のAIのコンテキスト保持させれたら任せられる範囲が増える - エージェントや人が見たときに、サービスの関係性が明瞭になった
41. サービス連携 議事録サービス+タスク管理サービス+日程管理サービス (notion,tl;dv+plane+googleカレンダー) 単にタスクを登録するとかではなく、 プロジェクト全体を管理できる 　　　会計とか
42. 肥大化
43. おまけ！失敗から学ぶAIエージェント（時間あれば） 実際に組織にAIを導入するとどうなるのか
44. 導入事例１ ワイ「時代は AIや！ 　　　OpenClaw導入して効率化したろ！ (^ω^) 　　　みんな喜ぶやろなあﾆﾀｧ」 タスク管理 slack github projects
46. プロンプトインジェクションs
47. 下手したらデータかネットワークやられてた 2つ目：イベント運営　技術座談会というイベントで、マニュアルや議事録からタスク管理 をさせようとした。後メールチェックとか
48. 失敗から学ぶAIエージェント２🤙🪚🩸
50. 教訓 AIとAIの生成元のマニュアルに依存してしまった 意思決定を全任せにする設計にしてはいけない
51. 完走した感想 - 必要な機能のみを実装することで処理時間が1/10になる事例があった - エージェントの原理を理解できた ->オーダーメイドのエージェントを作れるようになった - アーキテクチャの勉強になった - エージェントや人の運用の勉強できた - 新機能を実験できる
52. ご清聴ありがとうございました！ 参考図書 左：購買に売ってました 右：そのうち図書館に返します どちらも面白かったです ぜひ読んでみてね