스크립트
00:00:00皆さんこんにちは、Composioの共同創業者兼CTOのカラン・ヴェディアです。
00:00:19現在、ほとんどのエージェントツールによる処理は
00:00:21まだ一つの分野に集中しています。
00:00:23言うまでもなく、ソフトウェアエンジニアリングです。
00:00:26他のあらゆる分野の業務は、はるかに遅れをとっています。
00:00:29AIモデルが進化し続けているのに、
00:00:32なぜ私たちはまだコーディングエージェントだけに制限されているのでしょうか？
00:00:35それこそが、私が今回お答えする1兆ドル規模の疑問です。
00:00:433年前、コーディングエージェントは単なるオートコンプリートでした。
00:00:47今日では、ソフトウェアエンジニアリングは完全に自律化しています。
00:00:50Tabキーを何度も押していた時代から、Claudeにすべてお任せする時代へと進化しました。
00:00:56まさに魔法のような進化です。
00:00:59なぜコーディングの分野ではこれほど急速に進展したのでしょうか？
00:01:04多くの人はモデルの性能だと言うでしょう。
00:01:06確かに、ここ2、3年でモデルは目覚ましく進化し、Claude Code、Codex、Cursorといった
00:01:13ハーネス（実行環境）も同様に進化しました。
00:01:17しかしそれ単体では不十分でした。
00:01:20うまくいったのは、コーディングを取り巻くすべてのインフラとシステムが、文字通り
00:01:26エージェント向けに作られていたからです。
00:01:27コードには、エージェントに必要なサポートが最初から備わっていました。
00:01:31リポジトリ、コミット履歴、テスト、CI/CD、レビュー、リンターがあり、何か問題があれば元に戻すことができます。
00:01:39問題が起きたら巻き戻せます。
00:01:39こうしたコードを取り巻くシステムこそが、私たちにエージェントへの信頼を与えてくれるのです。
00:01:45現在、私たちはこれと同じ素晴らしいエージェントを、カスタマーサポート、財務、営業といったあらゆる分野に向けようとしています。
00:01:54しかし、コーディングで驚異的な成果を上げているエージェントが、他の分野では完全に手探り状態になっています。
00:02:00コーディング周辺のインフラが、他の分野には存在しないからです。
00:02:04では、コーディングエージェントとナレッジワーク用エージェントの間の溝をどうやって埋めればよいのでしょうか？
00:02:11カギとなるのは6つのコアプリミティブ（基本要素）であり、コーディングにはそのすべてが揃っていましたが、ナレッジワークには
00:02:19何一つありません。
00:02:20それこそ私たちが構築する必要があるものです。
00:02:241つ目は「一元化」です。
00:02:26コーディングエージェントが非常にうまく機能したのは、真実の源泉（Single Source of Truth）のすぐ近くにいたからです。
00:02:34「何を」「なぜ」「どのように」を彼らは把握していました。
00:02:37リポジトリやIaC（Infrastructure as Code）を与えてループを閉じれば、モデルは自ら動き出します。
00:02:43処理を実行してくれます。
00:02:44エージェントは、コードベースという単一の場所に、必要なものすべてが揃った状態から作業を始められます。
00:02:51これこそが、現在のナレッジワークに欠けているものです。
00:02:55例えば、1つの商談に関するデータが5つの異なるプラットフォームに分散しています。
00:03:00レコードはSalesforce、ドキュメントはNotion、メールはGmail、会話は
00:03:05Slack、サポート履歴はZendeskにあります。
00:03:09すべての情報を得られる単一の真実の源泉や場所が存在しません。
00:03:14コーディングは独立しており、アプリごとにログインが必要なわけではありません。
00:03:18ナレッジワークのエージェントは、作業を始める前に、まずすべてのスレッドを引っ張ってきて
00:03:23自分で結びつける作業を行わなければなりません。
00:03:27そして、それはコーディングエージェントが始まった出発点に過ぎません。
00:03:30コーディングにはすべてが最初からありました。
00:03:32それでは、どうしてナレッジワークのエージェントにコーディングエージェントと同等のレベルの仕事を期待できるでしょうか？
00:03:39私たちが最初に構築すべきなのは、この「欠けている中心地」です。
00:03:42すべてのアプリ、すべての接続、すべてのログイン情報が存在するひとつの場所です。
00:03:46それにより、エージェントがそれらを自分で繋ぎ合わせるという面倒な作業をする必要がなくなります。
00:03:51すべてが一箇所で見つかるのです。
00:03:55そして、コーディングエージェントが最初に持っていたベースライン（リポジトリや、あらゆるスタックの情報を網羅した単一の場所）を手に入れます。
00:03:59すべての情報がひとつの場所にまとまっています。
00:04:02それがすべての出発点であり、エージェントに適切な書き込み権限を与えることができます。
00:04:09エージェントに次に必要なのは「歴史の感覚」、つまり過去を振り返る能力です。
00:04:16コードの世界では、これは無料で手に入ります。
00:04:18Gitは、投入されたすべての内容や行われたすべての変更の記録を保持しています。
00:04:23そのため、エージェントはいつでも過去を振り返り、特定の変更がどのように行われたかを確認できます。
00:04:27なぜ何かがうまくいったのか、なぜうまくいかなかったのかを把握できます。
00:04:31あなたが普段エージェントに頼むような作業を考えてみてください。
00:04:34過去に何らかの障害が原因で変更を差し戻したものの、それをやり直すのはかなり大変でした。
00:04:40その履歴を見て、元に戻してくれないか？といった依頼です。
00:04:43履歴を読み込んで状態を復元し、処理を実行してくれます。
00:04:46履歴はエージェントのためだけのものではありません。
00:04:49エージェントが何をしているのかをあなたが記録しておくためでもあります。
00:04:53エージェントが何をミスしているのか、どこでうまくやっているのかを確認できます。
00:04:58エージェントの言葉をただ信じる代わりに、該当するアプリに直接アクセスして何が行われたかを確認できます。
00:05:04実行結果を目で確かめられます。
00:05:09では、同じ質問をナレッジワークについて投げかけてみましょう。
00:05:12CRMが現在の状態に至った原因は何だったのか？
00:05:16同僚は、あの成約につながった素晴らしいメールをどのように作り上げたのか？
00:05:22サポートの問題をエスカレーションしたり、解決したりするための実際のプロセスはどうなっているのか？
00:05:27こうした答えは何百ものアプリに点在しており、履歴を保持しているものは一つもありません。
00:05:31そのため、エージェントには記憶がありません。
00:05:33ほとんどの場合、真っ白な状態からスタートします。
00:05:36過去に何を試したのか、何がうまくいって何がダメだったのか、全く把握していません。
00:05:40そして、人間側も確認する手段を持っていません。
00:05:44エージェントが実行を終えると、「うまく完了しました」と伝えてきます。
00:05:47しかし、本当に正しく完了したかどうかは分かりません。
00:05:49それが正しいか間違っているかを知る方法がないのです。
00:05:52そこに欠けているのは、「仕事の記録」です。
00:05:56すべてが一箇所を経由して実行されるようになると、その一元化のおかげで
00:06:02その上にレイヤー、すなわち「記録」を構築できるようになります。
00:06:06エージェントが他のすべてのアプリで行うすべての操作をログに記録できます。
00:06:12何に触れ、何をスキップし、何が機能し、何が機能しなかったのかを記録します。
00:06:17これにより、まずエージェントが記憶を獲得します。
00:06:20過去に同様のタスクがどのように実行され、何が成功したかを振り返り、それを再び再現できるようになります。
00:06:28毎回真っ白な状態から始める必要がなくなります。
00:06:31第二に、信頼が得られます。
00:06:33エージェントが実際に何をしているのかを最終的に正確に把握できるようになります。
00:06:36そのため、正しくやってくれることを祈る代わりに、振り返って確認し、悪いことをしていれば見つけ出すことができます。
00:06:44そして、エージェントが正しいことをするのを何度も目にするにつれて、信頼が育まれ、より多くのタスクを任せられるようになります。
00:06:50エージェントに次に必要なのは「コンテキスト」です。
00:06:53考えてみると、コンテキストには実質的に2つの種類があります。
00:06:571つ目は、プラットフォームの形状、すなわち「アーキテクチャ」です。
00:07:01物事がどのように流れ込み、どのように結びついているか、データフローの仕組みです。
00:07:05それはまるで、シニアエンジニアが頭の中に描いており、ジュニアエンジニアが身につけるのに3ヶ月はかかるような地図のようなものです。
00:07:122つ目は「スタイル」です。
00:07:13これは客観的に正しいかどうかではなく、あなたの会社では「何が良しとされるか」という基準です。
00:07:19つまり、リンターや型チェックなどを含めて、どのように仕事を進めるかという点です。
00:07:24もしかしたら、他の誰も使わないようなTypeScriptのデコレータを使っているかもしれません。
00:07:29こうしたことは、マニュアルのどこかにきちんと書かれているわけではありません。
00:07:32むしろコードベースに表れています。
00:07:34すべてはコードベースの中にあります。
00:07:35そのため、エージェントは自分で見て回り、仕様やあなたの好み、リンター、フォーマッターなどを把握することができます。
00:07:45では、ナレッジワークに話を移しましょう。同じことが言えます。
00:07:48顧客向けのドキュメントを書いているとします。
00:07:50書き始めるだけでも、データベースを開いて利用状況を抽出し、実際にどのように機能を利用してきたかの事後検証を行い、
00:07:58さらにSalesforceで商談の詳細を確認しなければなりません。
00:08:01それをして初めて、ドキュメントの最初の1行を書き始めることができます。
00:08:05答えは、それらのツールのうちのどれか一つだけに孤立して存在しているわけではありません。
00:08:09私がこのドキュメントを書けるのは、これらすべてのツールから情報を引き出し、頭の中で一つのコンテキストにまとめているからです。
00:08:15したがって、履歴とコンテキストを組み合わせることによって、組織がどのように機能しているかをマッピングできるのです。
00:08:21そして、その部分はエージェントにとって簡単に利用できる状態にはありません。
00:08:26私たちが centralization（一元化）とロギングを行った結果、構築された「記録」は、エージェントに記憶を与えて作業内容の確認を可能にするだけでなく、もう一つの興味深い役割を果たします。
00:08:36さらに興味深い効果をもたらします。
00:08:38各エージェントの動きを十分にログに記録すれば、パターンが見え始めます。
00:08:42組織がどのように機能しているかが分かり始め、組織がどのように働いてきたかの蒸留（抽出）である「スキル」が形成され始めます。
00:08:51どのようなアプローチが功を奏し、何がダメだったのか、過去に何が原因で失敗に至ったのか、といったことです。
00:08:57もはや記録は、単なる過去の出来事の履歴ではありません。
00:09:01それは、あなたの会社がどのように運営されているかを示す全体像です。
00:09:03そして、それは実際には3つの異なるレベルで機能します。
00:09:06ツールが一般的にどのように機能するか（すべての人に適用されるレベル）、
00:09:09会社がどのように物事を行うか、そしてあなた自身がどのように行うことを好むかというレベルです。
00:09:13あなたにとって「良い状態」とはどのようなものか。
00:09:15それこそが、ナレッジワーカー向けエージェントに欠けていたコンテキストなのです。
00:09:19仕事が実際にどのように遂行されるのか。
00:09:21いわば、本物のプレイブック（行動規範）です。
00:09:23そして、会社や個人のユーザーの好みです。
00:09:27これにより、エージェントはその情報を照会し、会社がどのように運営されているかを推測で補う必要がなくなります。
00:09:34コーディングエージェントがこれほど見事に機能するもう一つの理由があります。
00:09:37自分でテストを行う点です。
00:09:38作業が自己検証されます。
00:09:40検証です。
00:09:41エージェントがコードを書いた瞬間、一連のチェックが実行されます。
00:09:44単体テストで小さなミスを検知できます。
00:09:47結合テストは、離れたコンポーネントに影響する不具合を捉えます。
00:09:52何か問題があれば、型システムはそもそも動作せず実行できません。
00:09:57コンパイラもビルドを通しません。
00:10:00その上にはソフトウェアチェックがあります。
00:10:02リンター、フォーマッター、bugbot.md、レビュー基準などです。
00:10:06これらにより、コードがチームの規約や好みのスタイルに確実に従うようになります。
00:10:12人間が直接介入する必要はありません。
00:10:14エージェント自身がループを完結させ、標準に準拠してコードを正常に動作させます。
00:10:21少し前に、自分のOpen Clawをある採用の自動アウトリーチに適用したときのことを考えてみてください。
00:10:28候補者への大量メール送信です。
00:10:30実行されました。
00:10:31膨大な数のメールが送信されました。
00:10:34この中に私のOpen Clawから受け取った方もいるかもしれません。
00:10:37指示通りのことを完璧に実行しました。
00:10:40そしてそれは大惨事でもありました。
00:10:42自分の名前が添えられてTwitterで晒されるような類のものです。
00:10:46ええ、当時のひどい惨状が目に浮かぶことでしょう。
00:10:51それが起きたときは、決して嬉しい気持ちではありませんでした。
00:10:54ここで重要な点があります。
00:10:55前のスライドのチェック項目はすべてパスしていたはずです。
00:10:58メールは有効でした。
00:11:00アドレスも実在していました。
00:11:00投稿を行った実際の人々にちゃんと届いたのです。
00:11:04本当に重要なこと、つまり「これが本当に送られるべきものか」を問うテストは世界に存在しませんでした。
00:11:10そこにギャップがあります。
00:11:13それが欠落部分です。
00:11:14コードであればテストが正誤を教えてくれますが、ここでは違います。
00:11:17私の間違いを教えてくれたのはインターネットでした。
00:11:21そこで、不足しているチェック機能を構築します。
00:11:24先ほどの件の問題は、アウトリーチ自体が間違っていたわけではありません。
00:11:28私が気づく前に勝手に送信されてしまったことでした。
00:11:31したがって、修正策はシンプルです。
00:11:33現実になる前に捉えることです。
00:11:35そのために2つの方法を用意しています。
00:11:371つ目は、エージェントが送信する前に、過去に自分が送った下書きメールと照合し、自分のスタイルや好みに合致しているか確認することです。
00:11:472つ目は、現実世界のシナリオで破壊的な処理を行う前に、実際のツールを模した送信ボックス（サンドボックス）を提供し、そこでアクションを実行させることです。
00:11:59これにより、影響範囲が現実世界に及ぶ代わりにサンドボックスで留まり、エージェントが本番実行する前に私がレビューできます。
00:12:07この2つを組み合わせることで、ナレッジワークにはこれまでなかったものが手に入ります。
00:12:11現実の事象になる前に、エージェントが自身の作業をチェックする手段です。
00:12:16ついに人間を待って停止するのではなく自分でループを完結させることができ、ツイートで攻撃される爆撃を受けることなく、その行動を信頼できるようになります。
00:12:29次に、エージェントに必要なのはガバナンスです。
00:12:32信頼の構築とは、エージェントのできることの範囲を制御し、適切な壁を周囲に築くことです。
00:12:39コードの世界では、この問題は概ね解決されており、複数のレイヤーが存在します。
00:12:44エージェントは自分のブランチ上で自由に行動できますが、mainへのマージはできません。
00:12:49mainへのマージの仲立ちとして、人間のレビュアーが介在します。
00:12:52重要ファイルにはコードオーナーが設定されており、そこに触れると適切な人物が必ず関与するようになります。
00:12:58エージェントにはプレビュー環境へのデプロイを行わせ、本番デプロイには決して触れさせないことで、そこで制御しています。
00:13:04ガバナンスは単一のゲートではなく複数存在し、それぞれがもたらす影響範囲の大きさに応じて規模を変えています。
00:13:12安全な部分では処理を遅らせることはなく、ただ本番環境を台無しにするのを防ぐだけです。
00:13:19これらの制限がしっかりしているほど、エージェントを信頼して自由に暴れさせることができます。
00:13:25この一件をご存知かもしれません。
00:13:27Meta Super Intelligence Labのアライメントディレクターがエージェントをメールに接続したところ、メールを次々と削除して破壊し始めたという話です。
00:13:36彼女が停止するよう指示しても動き続け、最終的に物理的なマシンのところへ走って止めなければなりませんでしたが、その時にはすでに200通のメールが消えていました。
00:13:45事前にプロンプトでそのような場合には確認をとるよう指示していましたが、それはただのプロンプトにすぎず、コンテキストから押し出されて消えてしまったのでしょう。
00:13:53AIアライメントを専門とする人でさえエージェントに正しいプロンプトを与えられないのであれば、おそらく私たち誰にもできないでしょう。
00:14:03そして、これこそがこうしたエージェントを信頼するのが難しい本当の理由であり、コーディングエージェントより劣っているからではなく、周囲に壁が存在しないからなのです。
00:14:12コードの世界では、開発の初期段階からシステムに壁が組み込まれていました。
00:14:17ナレッジワークにもあちこちに断片的な仕組みは存在します。
00:14:20例えば、Gmailにはスコープがあります。
00:14:21Salesforceには権限レベルがあります。
00:14:23しかし、それが至る所に散らばっているため実際の制御が難しく、ほとんどの人がプロンプトで何とかしようとしています。
00:14:32そしてプロンプトは脆いものです。
00:14:34エージェントはその抜け穴を見つけ出します。
00:14:36指示が忘却されて消えていきます。
00:14:38規模が大きくなると、こうした防御のいずれかが破られ、あなたも重要なメール200通が消滅する同じ状況に陥るでしょう。
00:14:47では、何がそれを本当に食い止めるのか。優れた指示ではなく、エージェントがその壁の存在を忘れたとしても越えられない「壁」なのです。
00:15:00そこで、私たちはこうした壁を2つのレイヤーで構築します。
00:15:03第1のレイヤーは、エージェントがどこに到達できるか、何にアクセスできるかに対する確定的（デターミニスティック）な制御です。
00:15:09採用エージェントであれば、メールの「読み取り」のみを許可します。
00:15:13サポートエージェントなら、下書きメールを作成できても実際の送信はできません。
00:15:17境界線はエージェントの外側に存在します。
00:15:19エージェントが議論したり、忘れたり、圧縮されて消されたりすることはありません。
00:15:24プロンプト内のエージェントのメモリに依存する指示は失敗しました。
00:15:28このアプローチは違います。
00:15:30しかし、彼女はメールエージェントを実際に構築していたため、アクセス権単体では救えなかったでしょう。
00:15:36つまり、そのメールへのアクセス権は間違いなく必要でした。
00:15:39もう1つ私たちが行うのが、ポリシーの提供です。これにより、そうしたアクセス権を持った状態でも、エージェントができることについて自然言語でポリシーを定義できます。
00:15:49例えば「私の許可なしに10通を超えるメールを削除するな」といったものです。
00:15:53「特定のドメイン以外にメールを送信するな」などです。
00:15:56アクセス権を持たせた上で、さらにその挙動を制御するルールです。
00:16:00この2つの要素により、一方のレイヤーがエージェントの到達範囲を制御し、もう一方のレイヤーがその到達範囲で何ができるかの挙動を制御します。
00:16:09これらが合わさって初めて、エージェントのための真のガバナンスとなります。
00:16:11エージェントにお行儀よく振る舞うよう頼むのではなく、何ができるかを強制するのです。
00:16:17最後の柱は、可逆性（リバーシビリティ）です。
00:16:20そして、物事がうまくいかなくなったときに行き着くのがここです。
00:16:25「元に戻せるか？」という点です。
00:16:27コードの世界では、ほぼ常に元に戻せます。
00:16:30すべての変更が記録されています。
00:16:32作業をロールバックできます。
00:16:33直前のコミットをgit revertしたり、本番を壊したコミットをgit bisectで特定して元に戻したりできます。
00:16:41それが素晴らしいことだとは言いません。
00:16:44そんな風にごまかすつもりもありません。
00:16:45本番環境で問題が起きて壊れた場合、それは常に悪いことです。
00:16:48しかし、それでも取り返しがつかないわけではありません。
00:16:50依然としてそこから引き返すことができます。
00:16:51だからこそ、エージェントに自由に作業させ、魔法のような成果を出させる自信が持てるのです。
00:16:57たとえ物事を壊したとしても、引き返す道が用意されているからです。
00:17:03ナレッジワークには、元に戻すボタンはありません。
00:17:05先ほどの彼女の受信トレイの例を考えてみてください。
00:17:07その200通のメールは消え去っています。
00:17:09消失してしまったのです。
00:17:10ちなみにそれが通常の状態です。
00:17:12最悪のケースは、送信済みメールのように後から取り消せない場合です。
00:17:15すでに送金してしまった送金を取り戻せないような場合です。
00:17:18削除されたレコードは永遠に失われます。
00:17:20ナレッジワークにおけるほとんどのアクションには、実際には元に戻すボタンがありません。
00:17:24それが方程式全体を大きく変えます。
00:17:27それが影響範囲（ブラスト・ラディウス）の性質を変えるのです。
00:17:29コードであれば、事後的にエージェントを信用できます。
00:17:31実行させ、
00:17:32結果を確認し、
00:17:33間違っていれば元に戻す。
00:17:34しかしこちらでは、引き返しがつきません。
00:17:36残された唯一の方法は、エージェントが行動する「前」に信頼することです。
00:17:40これこそが、コーディングエージェントには決して感じなかった危険さをこれらのエージェントに感じさせる理由です。
00:17:44頻繁に失敗するからではありません。
00:17:46ここでの失敗は「取り返しがつかない」からです。
00:17:49だからこそ、完全に事前に許可するか、一切行動させないかのどちらかになります。
00:17:55正直に言いましょう。
00:17:56ナレッジワークにおいて可逆性を再現するのは最も困難です。
00:17:59コードにあるような真の「元に戻す機能」は、ナレッジワークのあらゆるシナリオには存在しないでしょう。
00:18:04しかし、元に戻せるシナリオも一部には存在し、私たちはそれらを活用しています。
00:18:09例えば、ラベルを追加した場合、
00:18:11後からそのラベルを削除できます。
00:18:14しかし、受信トレイからメールが消えてしまうハードデリートのように、全く元に戻せないアクションについては、
00:18:21エージェントがまずサンドボックス内でその処理を行い、
00:18:25人間がレビューした上で、実際に本番環境に反映される仕組みを提供しています。
00:18:30現実世界には直接触れません。
00:18:31それがパラダイムの転換です。
00:18:32コードでは、ミスが起きた「後」にそれを元に戻せます。
00:18:35ここでは、起きてしまう「前」に捉えます。
00:18:37タイミングは違えど、結果は同じです。
00:18:39ミスが定着することはありません。
00:18:41先ほどの彼女の例に戻りましょう。
00:18:42元に戻せるアクションであれば、リバースボタンを用意します。
00:18:45元に戻せないアクションであれば、エージェントはまずサンドボックスを実行し、
00:18:48彼女に「1200通のメールが削除されようとしていますが、実行しますか？」と通知されます。
00:18:52まだ実行されていません。
00:18:54まだ取り返しのつかないことにはなっていません。
00:18:57しかし、私たちが処理する何十億ものアクションを通じて、
00:19:00どれが巻き戻せるものでどれが不可能なのかを途中で学習し、
00:19:04それに応じてサンドボックスを準備しています。
00:19:09今日1つだけ持ち帰っていただきたいのはこの点です。
00:19:112年間、モデルがボトルネックでした。
00:19:14そのため誰もがより優れたモデルの開発を競い合っていました。
00:19:17現在、モデルはソフトウェア工学が100%自律的に行えるほど十分に優秀になりました。
00:19:23しかし今や、それ以外のすべてがボトルネックとなっています。
00:19:26コードを書くのと同じモデルが、採用活動、営業、その他のナレッジワークもこなすことができます。
00:19:36しかし現在は手探りの状態で作業しています。
00:19:39履歴も、コンテキストも、検証手段も、ガードレールも、元に戻す手段もありません。
00:19:44したがって、ボトルネックが移動したのです。
00:19:48それは誰もまだ構築していなかったインフラであり、私たちがComposioで構築しているのがまさにそれです。
00:19:54そう、私たちは合計で数十億回のツール呼び出しを支えており、毎月3億回のツール呼び出しが発生しています。
00:20:02もしあなたがエージェントを構築しているなら、Composioを組み込んでナレッジワークの魔法が起きるのを目撃してください。
00:20:08そしてAIエージェントの基盤の未来を築きたいなら、ぜひ私に声をかけてください。
00:20:13私たちは間違いなく採用を行っており、やるべきことはまだまだ山ほどあります。
00:20:17モデルはこれからも進化し続けます。
00:20:19ボトルネックはモデルではありません。
00:20:21その周囲にある環境です。
00:20:22ありがとうございました。
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기