バクラクによるコーポレート業務の自動運転 #BetAIDay

Slide 1

Slide 1 text

Slide 2

Slide 2 text

© LayerX Inc. Speaker 執⾏役員バクラク事業 CTO 株式会社エウレカにて、国内最⼤のマッチングアプリのバックエンド開発とインフラエンジニアとしても従事。その後フリーランスとして、動画ストリーミングアプリ、⾦融サービス、産学連携の機械学習プロジェクトを経験。 2020年6⽉株式会社LayerXに⼊社後、バクラク前⾝の⽴ち上げから開発。テックリード、プロダクト横断の開発組織 Enabling Team を経て、2024年1⽉より現職。中川佳希 NAKAGAWA, Yoshiki

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

© LayerX Inc. エンジニアリングの現場で起きている変化 2021/06 GitHub Copilot テクニカルプレビュー公開 OpenAI との共同開発 (GPT-3 後継のCodex) 2022/06 GitHub Copilot 正式リリースコード補完 2022/11 ChatGPT リリース (GPT-3.5) 2023/03 Cursor（Anysphere）登場ルールとコード⽣成 2024/12 Devin（Cognition）リリースリモート環境 Agents 2025/05 Claude Code（Anthropic）GA リリース Terminal Agents

Slide 18

Slide 18 text

© LayerX Inc. エンジニアリングの現場で起きている変化⽣成AIカテゴリーの中で最も資⾦調達額の多いのは、AI Coding の分野 2024年上半期のみで10億ドル（約1,500億円）以上と⾔われる ● デジタル上でタスク完結するものが多い ● ユーザー側（エンジニア）に試す⽂化がある ○ 間違いやバグを許容、利⽤者側でコントロールして使う ● ソフトウェアエンジニアの給与が⾼騰している ● AIツールの開発者⾃⾝がソフトウェア開発ドメインのエキスパート

Slide 19

Slide 19 text

© LayerX Inc. AI ツールは⼈のアシスト (近傍コードからの補完) から、⾃律的にコードを書く Agent へ⼈間が「スクラッチでコードを書く」時代は終わりを迎え、少なくともコーディングは全く別の仕事になった。ただそれがエンジニアの仕事がなくなった事を意味しない（少なくとも現⾏ツール延⻑線上でソフトウェアエンジニアを置き換えることにはまだ隔たりがある）。エンジニアリングの現場で先⾏して起きた変化、エージェントの⼒ Chat-oriented programming (CHOP)：チャット形式で AI と反復的なやり取りを⾏い、コードの完成を⽬指すプログラミング。Steve Yegge が提唱。

Slide 20

Slide 20 text

© LayerX Inc. デジタルな労働⼒スケール従業員数が増えても、同じパフォーマンスで 24/7 稼働季節性など⼈的リソースに依存しない AI による柔軟性固定やルールベースではカバーできない、より⼈間らしい対応が可能機械的な動作システムは予め定められた⼿順に従う、⽂字通り「機械的」に動作しルーチン業務を迅速に処理ガバナンス内部統制‧監査対応の⾃動化を促進する全社で再現性を持ったプロセス‧ルールを実現できる

Slide 21

Slide 21 text

© LayerX Inc. SaaS の勃興は「コンピューティングリソースの調達やアプリケーションの開発、保守」を不要にし業務システムの導⼊障壁を下げた。今後はデジタルな労働⼒の活⽤へと移る。 SaaS の岐路コーポレート業務の⾃動運転バックグラウンドでのタスク遂⾏へ as-is to-be 要求を満たすソフトウェアだけでなく、タスク完了までが提供価値に。従来的なサブスクリプションだけでなく、タスク従量でも評価される。継続的にシステムが利⽤されることを前提に常に機能拡張が⾏われる。 LTV（顧客⽣涯価値）という形で評価される。

Slide 22

Slide 22 text

© LayerX Inc. 技術組織としての分岐点バクラクが担う本質的価値の再定義業務のメンタルモデルを提供ユーザーが⾃分の業務全体像を直感的に理解できる「体験」をデザインすること SaaS は業務フローそのものをユーザーにとって⾒える形にして⽰し認知負荷を下げ、業務環境を作る。正しいビジネスロジックを提供法令や会計規程、社内ルールに沿った厳密なチェックと処理を担保することエージェントが⾃動化‧効率化を図っても、最終的に不正やミスが起きないことをシステムが保証する。AI の提案や⾃動処理を⼈が安⼼して受け⼊れられ、最終的な統合判断を⼈が⾏う。 LLM からみたタスク実⾏基盤エージェントが実際に業務を動かす実⾏ツールとその基盤を提供すること信頼性の⾼い実⾏基盤を提供することで、⼈が信頼性を持ってエージェントに仕事を依頼出来る。

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

© LayerX Inc. ● バックグラウンドでのタスク⾃動化 ● AI での学習がまわり始めたら、⼈を判断‧例外処理のみに集中させる繰り返し発⽣するルーチン業務が多くある。⼀⽅で、例外判断や規程違反の検出は⽋かせない。技術組織としての分岐点バックオフィス業務の特性 AI エージェントの狙い SaaS としての UX での視点 ● SaaS はフォアグラウンドとしてユーザーの業務メンタルモデルを⽀える⼟台（完全にエージェントで代替までの距離を把握する） ● ユーザーのメンタルモデル（経験則、慣性）に沿った設計は必要

Slide 27

Slide 27 text

Slide 28

Slide 28 text

© LayerX Inc. デザインパターン Single-path plan generator パターンで、ルーチンをプランニングする “Agent Design Pattern Catalogue: A Collection of Architectural Patterns for Foundation Model based Agents” Liu et al. (2024), arXiv:2405.10467 技術組織としての分岐点

Slide 29

Slide 29 text

Slide 30

Slide 30 text

© LayerX Inc. Building Eﬀective AI Agents \ Anthropic > Consistently, the most successful implementations use simple, composable patterns rather than complex frameworks. 「⼀貫して、最も成功する実装では、複雑なフレームワークではなく、シンプルで構成可能なパターンが使⽤されます。」技術組織としての分岐点エージェントの構成要素 The augmented LLM 拡張 LLM の構成要素となる Tools, Memory を取り上げます

Slide 31

Slide 31 text

© LayerX Inc. Building Eﬀective AI Agents \ Anthropic > Agents can handle sophisticated tasks, but their implementation is often straightforward. They are typically just LLMs using tools based on environmental feedback in a loop. 「エージェントは⾼度なタスクを処理できますが、その実装はたいてい単純です。多くの場合、ループ内で周辺環境からのフィードバックを元にツールを利⽤する LLM に過ぎません。」技術組織としての分岐点エージェントの構成要素 Autonomous agent マイクロなエージェント：前ページでの構成要素を持つ拡張 LLM がフィードバックループをえて動く

Slide 32

Slide 32 text

© LayerX Inc. How to Build an Agent - Amp 今年4⽉ Sourcegraph が投稿したブログ Run というメインルーチンは 40⾏程の for ループで、ユーザー対話, ツール実⾏, 推論 (API) を実装している。（実装は素朴で素直なもの、しかしツール実装とその協調でパワフルな CLI 型のエージェントに）技術組織としての分岐点 their implementation is straightforward 400⾏に満たない Go コードで実装された code-editing agent

Slide 33

Slide 33 text

© LayerX Inc. 思考（ユーザーとの対話）を担当するモデルに対し、ツールは具体的な処理を⾏うこれを分ける（環境として識別する）ことでエージェントの開発、運⽤の⾒通しがたつ ● ツール単位で開発‧デバッグ‧テストが可能 ● トレーサビリティ（追跡可能性）を⾼める ● コンテキストウィンドウの消費を⼩さくする ○ Hallucination を防ぐ（ノイズを拾わない） ● 認可 ○ 誤りが認められず、決定的な動きのみが求められる技術組織としての分岐点構成要素：Tools High-level ﬂow of a coding agent

Slide 34

Slide 34 text

© LayerX Inc. ● Divide and Conquer (Method): 分割統治法そのままでは解決できない⼤きな問題を⼩さな問題に分割し、その全てを解決することで、最終的に問題全体を解決する⼿法。 ● Peter H. Salus.『UNIXの1/4世紀』アスキー, 2000 ⼀つのことを⾏い、またそれをうまくやるプログラムを書け。協調して動くプログラムを書け。標準⼊出⼒（テキストストリーム）を扱うプログラムを書け。標準⼊出⼒は普遍的インターフェースだ。— ダグラス‧マキルロイ技術組織としての分岐点問題を解く単位はツール実装に委ねる Quicksort

Slide 35

Slide 35 text

© LayerX Inc. エージェントが実⾏するツールは、ただの API や関数ではなく、責務を持つモジュール 1. ビジネスロジック a. 会計処理、社内規定、稟議など、SaaS しか持ちえない「組織の判断基準」も含まれる 2. 認可とガードレール a. 認可スコープを明⽰し、誰がなにを出来るかを制御する b. これにより、誤実⾏‧不正実⾏の抑⽌や責任追跡ができる 3. 粒度制御 a. 実⾏結果に対して、「何が起きたか」「ログとして記録するべきか」の境界技術組織としての分岐点ツール = 単なる関数呼び出しではない

Slide 36

Slide 36 text

© LayerX Inc. エージェント向けのメモリを指す（単にチャットログを覚えているではなく、ユーザープロファイルやツール実⾏結果などがある）コンテキストエンジニアリングの中核をなす。技術組織としての分岐点構成要素：Memory Raw capability With Memory メモリを持たないエージェント毎回ユーザーとは「初対⾯」、「初めて遭遇する問題」にメモリからもコンテキストを補完「最⼩の⼿助け」で問題を解く

Slide 37

Slide 37 text

© LayerX Inc. 「⼈の辿った思考や⽅法を模倣する」ところから始める。⼈にアテンドしながら成功‧失敗を貯めて、進化を続けることが出来る。技術組織としての分岐点過去、⼈が⾏ったタスクの⾃動化エージェントが⻑期メモリを持つことで期待されること成功したもの ● ユーザーがやりたいことを反映したプレイブックになる失敗したもの ● 失敗理由をラーニング出来る ● 次回失敗時の⾃⼰修繕的なアクション（巧い活⽤はまだみえない）

Slide 38

Slide 38 text

© LayerX Inc. 消費するコンテキストウィンドウを⼩さくするためのアプローチ 1. 中間ステップを取り除き、コンテキストに追加する a. 導かれた過程の正確性を⽋く可能性がある 2. メモリ情報を圧縮しサマリーをつくり、コンテキストに追加する a. compaction についての知⾒、実験が必要 b. （ヒューリスティックにはコーディングエージェントでも有効に感じる事が少ない） 3. 外部記憶に保存された情報を現在のコンテキストから参照可能にする a. 情報の加⼯が不要、Immutability を担保できる b. 追加で外部記憶から取得するプログラム（か推論）が必要技術組織としての分岐点コンテキスト補完に効果的なメモリの活⽤

Slide 39

Slide 39 text

Slide 40

Slide 40 text

© LayerX Inc. 1. ⼈間の思考をトレースから始める 2. 愚直な実装から始める / Start with straightforward implementations a. ツールもシンプルな問題を解くところから始める 3. LLM モデルは（より安価に）強⼒になるが、⼀⽅でそれがメモリやツール実⾏、環境からのフィードバックの必要性に取って代わることはない技術組織としての分岐点 Lessons learned

Slide 41

Slide 41 text