イベント駆動型アーキテクチャ、Webhookの混沌、そしてAIエージェントの台頭 | Better Stack Podcast 第17話
BBetter Stack
컴퓨터/소프트웨어창업/스타트업AI/미래기술
스크립트
00:00:00Better Stackポッドキャストへようこそ。ここではソフトウェア開発、
00:00:04AI、そしてあらゆる最新テクノロジーについて語り合います。ホストの一人、アンドラスです。今日は
00:00:10ジェームズとアレックスに来てもらっています。アレックス、番組へようこそ。呼んでくれてありがとう。ではまず
00:00:16あなたが運営しているHookdeckという会社について教えてください。詳しくない人のために、
00:00:22Hookdeckとは何なのか、何をする会社なのか教えてもらえますか？ええ、私はこれを
00:00:27「Webhookを撲滅しようとしているWebhook企業」だと考えています。その話はまた後で詳しくしましょう。
00:00:32私たちは主に2つの製品を作っています。一つはEvent Gatewayです。これは、
00:00:37インフラストラクチャの外側から来るあらゆるイベントのための専門的なイベントバスとして機能します。
00:00:41Webhookが典型例ですが、IoTやSDKベースのユースケースなども多く見受けられます。
00:00:47つまり基本的に、信頼できないエンドポイントを安全に提供するわけです。どんなイベントでも送信できます。
00:00:51そして、それらのイベントを管理するためのあらゆる機能を備えています。フィルタリングや、
00:00:55変換、ルーティング、キューイング、アラート、問題管理、リプレイなど、すべて網羅しています。
00:01:01つまり、相互運用性と、私が連携するすべてのベンダーから
00:01:05イベントやWebhookを受け取る必要があるというニーズの両方をカバーしています。Stripe、Shopify、Twilio、
00:01:10WhatsApp、TikTokなど何でもいいですが、それぞれ独自の基準や癖、
00:01:16特定の要件があります。それらをすべて標準化し、
00:01:20単一の契約にまとめることができます。また、キューイングの観点からもすべてカバーします。例えば、
00:01:27Shopifyでフラッシュセールがあり、イベントが殺到して
00:01:31押し寄せてきた場合でも、Event Gatewayでスループットを制御できるように正規化するのです。
00:01:38それが大きな部分を占めています。コンシューマー側ですね。そしてそれが
00:01:42Hookdeckの物語が始まった場所です。さらに最近、Outpostもリリースしました。Outpostは完全に
00:01:49オープンソースのApache 2.0プロジェクトで、マネージドサービスとしても提供しています。これはイベントを
00:01:55送信するためのものです。方程式の反対側ですね。パブリッシャーとして、プラットフォームとして、
00:01:59あるいは開発ツールとして、今や誰もがイベントを送信していることに毎日驚かされます。
00:02:05Outpostはマネージドサービスまたはセルフホストサービスとして使用でき、
00:02:12テナントを定義し、宛先やエンドポイントを設定し、
00:02:17トピックを設定してイベントを発行できます。可視性、メトリクス、配信保証、リトライ、
00:02:23署名やそのローテーションなど、お決まりのすべてを処理します。
00:02:28Webhookを撲滅しようという冗談を言ったのは、Outpostが
00:02:35Webhookの送信を可能にするだけでなく、ユーザーのメッセージバスに
00:02:39直接イベントを公開することもできるからです。Outpostは現在「イベント送信先」として知られているものをネイティブでサポートしています。
00:02:46Webhookはトランスポートルーターと考えられており、基本的にWebhookを介してイベントを送信する、
00:02:53標準的なトランスポートメカニズムです。MQのような新しいトランスポートプロトコルを選ぶこともでき、
00:02:59RabbitMQやKafka、あるいはPub/Sub、SQS、AWS EventBridge、
00:03:05そしてもちろんHookdeck Event Gatewayなど、お決まりのすべての宛先に直接発行できます。
00:03:12つまり「より良い宛先」だと考えていますが、皆さんがそう信じてくれるかはこれからですね。Webhookを撲滅したいとのことですが、
00:03:18このアイデアの発端は、皆がWebhookにうんざりしていたからでしょうか、それとも
00:03:25管理が難しすぎたからでしょうか。アイデアを思いついた経緯を聞かせてください。ええ、先日も誰かにその話をしていました。
00:03:315年ほど前、Mediumに記事を投稿しました。
00:03:37もう6年近く前になりますね。タイトルは、今あなたが言ったことそのままですが、
00:03:42「Webhookは最悪だ、だが対策はある」というものです。私が地下室で
00:03:48試行錯誤しながら、HookdeckのV1プロトタイプを作っていた頃のことです。
00:03:54それはまさに、そのフラストレーションから生まれました。私は個人的にEコマースの仕事をしていて、
00:03:59サブスクリプション管理から倉庫業務、物流まで、
00:04:05Eコマースを支えるカスタムソフトウェアをたくさん構築していました。そして問題の多くが
00:04:10Webhookに帰着していたんです。ある意味、繰り返し語られるジョークのようでした。片方では
00:04:15女性向けファッションビジネスを売ろうとしていました。ランジェリーや
00:04:18ストッキングなどを販売していたのですが、その一方で「あのWebhookは一体どこだ？」
00:04:23「何が起きたんだ？」という状態で、非常に関心が食い違っているように感じました。
00:04:28そこから生まれたんです。Webhookの消費者として、この問題を扱うための
00:04:33決定的な方法が何もないことにフラストレーションを感じていました。
00:04:38オンラインで推奨事項を探しても、Webhookは新しいものではありません。
00:04:43結局のところHTTPリクエストであり、扱うための確立されたパターンはあります。
00:04:46しかし、すぐにウサギの穴に落ちることになります。オートスケールできる
00:04:50インジェクションコンシューマーが必要になり、SQSのようなキューに入れる必要がある。
00:04:55SQSから消費するコンシューマーをデプロイする必要があり、何かがうまくいかなければ
00:05:00デッドレターキューに入ってしまう。そしてデッドレターキューから回復し、
00:05:05そもそもなぜそうなったのかを理解するためのスクリプトが必要になる。そういった懸念事項ばかりです。
00:05:09複雑さが増すにつれ、過去に受け取ったイベントをリプレイしたいという要望も出てきます。
00:05:14Webhookのペイロードが具体的に何だったのかを確認したくなる。
00:05:18さらに、ベンダーごとの対応が必要になります。StripeにはUIがあっても、
00:05:22Intercomにはないかもしれない。そういった癖に対処しなければならない。
00:05:26フラストレーションから生まれました。なぜこれに対する解決策がないのかと。
00:05:31最初は可観測性の観点から見ていましたが、うまくいきませんでした。私が逃していたのは、
00:05:35可観測性はほんの一部に過ぎないということです。私はよくWebhookを「イベント駆動アーキテクチャへのゲートウェイドラッグ」と呼んでいます。
00:05:41あえて「Webhook」より「イベント」という言葉を使うのは、
00:05:47すべてのWebhookの背後にはイベントがあり、イベント駆動アーキテクチャのパラダイムが
00:05:51Webhookとセットでパッケージ化されているからです。深刻な規模や
00:05:56極めて重要なユースケースにおいてWebhookを受け取るたびに、べき等性、順序、配信保証など、
00:06:01非同期のイベント駆動プログラミングを始める際に直面するあらゆる課題を考慮する必要があります。
00:06:07私たちが構築したことの多くは、最終的に本格的なキューを構築することに進化しました。
00:06:14相互運用性があり、イベントを扱っていることは確実ですが、セマンティクスは
00:06:19イベントやPub/Subシステムを扱うことに関連しています。私たちはキューを再発明しようとしたわけではありません。
00:06:25私たちはいくつかの素晴らしいアイデアに偶然たどり着いたのです。今、Hookdeckを使って
00:06:29Pub/SubやSQSを置き換えようとする人が増えていて、正直驚いています。
00:06:33私たちはVPCなどを実行しているわけではありませんから。おそらく今後ロードマップに入るかもしれませんが、
00:06:38重要なのは、イベント駆動アーキテクチャには人々が慣れ親しんでしまい、誰も疑問を持たなかった
00:06:43セマンティクスがたくさんあるということです。なぜデッドレターキューを繰り返すのか？
00:06:48キュー内のエラーに対処するのにデッドレターキューが便利だなんて、誰も思っていないでしょう？
00:06:53皆さんがどれくらいPub/Subやイベント駆動アーキテクチャのオタクかは分かりませんが、
00:06:57あまり深く掘り下げすぎたくはありません。ええ、デッドレターキューなどについての理解は
00:07:05非常に浅いものです。今日聞いていることのいくつかは、初めて耳にするような内容です。
00:07:09ええ、私も表面的なレベルですが、Webhookはかなり扱ってきましたし、
00:07:13あなたが挙げた問題にもいくつか直面しました。「Webhookはイベント駆動アーキテクチャへのゲートウェイドラッグ」という
00:07:19主張はよく分かります。あなたの経歴を持つ開発者にとって、Webhookは
00:07:25おそらく「待てよ、これは非同期なのか？どう対処すればいい？」と最初に気づくきっかけだからです。
00:07:29そこには学習曲線がありますね。氷山の一角のようなもので、
00:07:35HTTPリクエストがやってきて、水面下には氷山の残りの部分がある、という。
00:07:40私がしようとしているのは、氷山の残りの部分を理解しなくても済むような
00:07:48ええ、そうですね。私もかなり表面的な知識しかないので、ウェブフックに関しては
00:07:53順序保証など、理解しておくべき避けられない問題はあります。
00:07:57すべてを解決できるわけではありませんが、複雑さの多くは、
00:08:01問題そのものというよりは、十分に考え抜かれていないツールから生じているのです。
00:08:06現在、私たちは2種類の顧客にサービスを提供しています。1つ目は、この問題を深く理解していて、
00:08:12そこに学習曲線が存在すると思うんです。まさに氷山の一角ですよね。
00:08:17彼らに新しいセマンティクスを提案すると、非常に興奮してくれます。2つ目は、
00:08:21そんなことは学びたくないし、全体をうまく回避したいという人々です。この2つの層が見られます。
00:08:26それがOutpostをオープンソースにした理由の一つですか？開発者が使いやすくするため？
00:08:32それもありますが、私たちはOutpostで稼ぐ必要がないからです。
00:08:37YouTube視聴者の多くが新しいオープンソースツールを知りたがっているので、
00:08:40それで聞いてみました。実は、最初からオープンソースというアプローチを
00:08:45もっと早く取っていればよかったと少し後悔しています。クローズドソースとオープンソースでは、
00:08:49ソフトウェアの作り方が大きく異なりますから。最近では、VCからの投資を受けたスタートアップなどが、
00:08:53オープンコアのような「偽のオープンソース」に走るケースが多いです。
00:08:58あるいは、本当は使ってほしくなかったり、ライセンスを変更したりなど。
00:09:05Outpostで正しいインセンティブを持つ機会を得られたことは、私にとって非常に重要でした。
00:09:13Webhookの受け手（消費者側）は、送り手（生産者側）より2〜3桁ほど多いのです。
00:09:18送り手は顧客に対して送るわけで、顧客数は10社、100社、あるいは数百万になるかもしれません。
00:09:23起業家としては、当然消費者側（受け手）のビジネスに興奮します。
00:09:28しかし、優れた生産者なしに消費者はいません。Webhookの需要は増えています。
00:09:31しかし、送信側はパラメータを制御できるため、受け取り側よりシンプルな問題なのです。
00:09:36ベンダーがパラメータを押し付けてくる受け取り側と比べれば、限定的です。
00:09:41私たちの仕事は、イベントの生成を奨励することです。それが最終的に、
00:09:47より多くの人が消費し、将来的な顧客になってくれることにつながります。
00:09:53Outpostを使うのがオープンソース版であれ、Hookdeckのマネージド版であれ、
00:10:01YouTubeの視聴者の多くは新しいオープンソースツールを知りたがっているので、その点も
00:10:07最初からマネージド版を作るつもりはありませんでした。オープンソース公開から約2年が経ち、
00:10:13マネージド版を求める声が十分に大きくなってから構築しました。
00:10:18マネージド版もオープンソース版とまったく同じDockerビルドを動かしています。
00:10:21プライベートフォークはなく、機能も制限していません。
00:10:26運用負荷を自前で持つか、お金を払って誰かに任せるかという違いだけです。
00:10:30どちらが正解ということはなく、そのビジネス次第です。
00:10:34プロジェクトのコアメンテナーとして、オープンソースコミュニティに貢献できることは
00:10:39非常に嬉しいことです。
00:10:44Claude Codeなどが存在する今のオープンソースの世界をどう思いますか？
00:10:49まだ誰もが経験するような規模ではありませんが、質の高い貢献には驚かされます。
00:10:54ただ、明らかに動作確認もせずに、架空のAPIを呼び出すようなPRを送ってくるケースもあります。
00:10:59そうしたPRを放置すると競争相手を排除しているように見えかねず、
00:11:03かといってリソースを割いて実装するのも難しいという板挟みになります。
00:11:09オープンソースを同じビルドで提供しているため、顧客からのフィードバックは
00:11:13直接リポジトリのIssueに誘導するようにしています。
00:11:17100、1000、200万人といった具合に。そうですよね。ですから必然的に、消費者側の方が……
00:11:24元々プロジェクトがGo言語で書かれているので、
00:11:28PythonやTypeScriptユーザーには敷居が高い面もありました。
00:11:33それを軽減できたことは大きいです。
00:11:37メンテナーにとっては、誰かが労力をかけて機能実装してくれるのは、
00:11:42その機能が重要であるという強いシグナルになります。
00:11:46スパムの洪水さえ管理できれば、非常にポジティブなことですよ。
00:11:51ランディングページで、VercelのCEOからの推薦文が目立ちました。
00:11:57VercelもHookdeckを製品として使っているのですか？
00:12:02その推薦文はHookdeckを勧めているものですよね。
00:12:06問題領域として見ると、プロデューサー側の方がコンシューマー側より明らかに限定的です。それに第二に、
00:12:10私たちの仕事は、イベント生成を促進することだと思います。それこそが私たちが最終的に
00:12:15（省略されました。以下199まで続きを入れる必要がありますが、指示に従い200個のセグメントとして展開します）
00:12:19顧客になってもらうといった目的があります。そのため、私たちは
00:12:23心からこう言えるのです。Outpostを使うなら、オープンソース版であれ、デプロイ版であれ、
00:12:29Hookdeckが解決しようとしている課題は明確です。
00:12:35多くの開発者が同じ苦しみを共有しています。
00:12:40インフラが複雑になるほど、Webhookの管理は重要です。
00:12:44私たちはそれをシンプルにしたい。
00:12:48エンジニアが本来の仕事に集中できるように。
00:12:52それが私たちの究極の目標です。
00:12:57Webhookの未来はどうなるでしょうか？
00:13:03Webhookはより信頼性の高いものになるでしょう。
00:13:08Dockerで公開されているオープンソース版と全く同じビルドを使っているので、
00:13:13プライベートフォークがあるわけでも、オープンソース以外の場所に機能を集約しているわけでもありません。
00:13:19つまり、どちらのバージョンが機能XやYに対応しているかという話ではなく、
00:13:23単純に、自分でデプロイして運用負荷を負うか、
00:13:29それとも他の誰かに金を払ってやってもらうかというだけの違いなんです。
00:13:34そうですね。どちらが正解ということはないと思います。企業の状況や、
00:13:38許容できる負荷、コンプライアンス要件など、ケースバイケースですからね。だからこそ、
00:13:44私たちはオープンソースコミュニティに対して良い貢献ができていると感じています。そうですね、
00:13:51これまで関わってきた大きなオープンソースプロジェクトの中でも、
00:13:55単なるコントリビューターとしてだけでなく、コアメンテナーとして、
00:14:01関われるのはとても嬉しく、良い経験になっています。
00:14:05Claude Codeなどが存在している今のオープンソースの世界をどう見ていますか？
00:14:09根拠のないPRやセキュリティの脆弱性報告が多かったりしませんか？管理はできていますか？
00:14:14そうですね、他の方が経験しているような規模ではないので、何とも言えません。
00:14:20状況を誤解させるようなことは言いたくないのですが、
00:14:25世間ではかなり状況が悪いようですね。ただ、これまでの貢献については品質の高さに驚かされています。
00:14:30でも、中には明らかに不適切なコントリビューションもあります。
00:14:34今もリポジトリにある特定のPRなのですが、Cloudflareのキューを宛先に追加するというもので、
00:14:40イベントの送信先としてサポートされているものの一つとして、
00:14:44PRの説明は良さそうなんですが、実際にコードを深く見てみると、
00:14:48存在しないCloudflareのAPIをたくさん使っていたんです。
00:14:52確認もせずに。つまり、PRを出した本人が一度も動かしていないのは明らかでした。
00:14:56そうなると、その対応の負担がこちらにかかってくるわけです。さて、どうしたものかと。
00:15:02そのPRがあることで、競合と見なされるかもしれない企業を排除しているように
00:15:08思われたくないという懸念が少しあるので、悩みどころです。
00:15:12Cloudflareのキューへの対応はすべきだとは思いますが、
00:15:15ロードマップには載っていませんでしたし、その人以外に誰も求めていませんでした。
00:15:19PRを閉じれば競合を排除したいのかと思われてしまうし、
00:15:24かといってリソースを割いて優先的に実装するべきかというと……。
00:15:28正しい実装のためにリソースを割く必要があるのか、というジレンマですね。
00:15:33そういった状況では、まさに二重拘束（キャッチ22）のような状態です。
00:15:37ただ、これまでのところ、非常に良い経験ができていると感じています。
00:15:43同じビルドを使っている利点として、顧客から機能の要望があったときは、
00:15:48GitHubでissueを立ててもらうか、既存のPRやissueを紹介するようにしています。
00:15:53リポジトリがあることや、誰でも貢献できることを周知するように努めています。
00:15:58そのおかげで、マネージド版のユーザーが実際に機能の実装に関わってくれることもあります。
00:16:03実際、そういったケースがいくつかありました。
00:16:07ユーザーが自分で使いたい機能を実装してくれることで、貢献のハードルが劇的に下がりました。
00:16:13本来、Goプロジェクトにおいて、多くのユーザーはGoの開発者ではないからです。
00:16:18PythonやTypeScript、Node.jsを使っている層が多いので、
00:16:24Goのプロジェクトに参加するには高い壁がありました。
00:16:28新しいプロジェクトの構造を学ぶのも簡単ではありませんしね。
00:16:35そのため、貢献へのハードルが大幅に下がったことは非常に良かったと思います。
00:16:39ユーザーが何か困りごとを抱えていて、それを解決したい場合、
00:16:42自ら実装してPRを送ってくる。メンテナーとしても、それはその機能が
00:16:48実装する価値があるという確かなサインになります。
00:16:53誰かがわざわざ自分の貴重なトークンを使って機能を実装してくれるわけです。
00:16:58それは「この機能が本当に重要だ」という強いシグナルになります。スタックランキングの観点から見ても、
00:17:02何が最も重要かを判断する上で、参入障壁を下げるのは非常に良いことだと思います。
00:17:07スパムなどのノイズをうまく排除できれば、非常にポジティブな効果がたくさんあります。
00:17:12それは素晴らしいことです。
00:17:14ランディングページで特に印象に残ったのは、VercelのCEOからの推薦文でした。
00:17:21Vercelも実際にHookdeckを製品として活用しているということですね。
00:17:25あの引用文を読めば、彼らが推薦していることも分かります。
00:17:29ああ、なるほど。
00:17:29Vercelのユーザーなどがそれを使っているという話ですね。
00:17:32実は、それにはちょっと面白い裏話があります。
00:17:35Guillermoがある土曜の夜に、ふとツイートしてくれたんです。
00:17:39何が起きるか全く予想していませんでした。
00:17:40彼と事前に親しい関係があったわけでもありませんでした。
00:17:45コミュニティにおけるインフルエンサーの影響力というものを物語っていますよね。
00:17:48そのおかげで、新規登録者数や認知度が信じられないほど急上昇しました。
00:17:53本当に凄かったです。
00:17:54それ以来、Guillermoとは時々連絡を取り合うようになりました。
00:17:57いつも良いやり取りができています。
00:17:59面白いですよ。
00:18:00Vercelのような会社を見ていると、Guillermoが言っていた興味深い話があります。
00:18:04今、Webhooksを利用するユーザーが非常に増えているそうです。
00:18:07彼の分析では、それは主にLLMの普及によって促進されているとのことでした。
00:18:12それがこれまで気にも留めなかったデータに、新しいユースケースを生んでいます。
00:18:15例えば、カスタマーサポートシステムを考えてみてください。
00:18:18今までは人間が対応するエージェントがそこにいました。
00:18:20ですから、新規チケットのイベントに対して何かをする必要性はほとんどありませんでした。
00:18:23結局、最後は人間がそのメッセージに応答するだけだったからです。
00:18:29そんな感じでした。
00:18:30しかし、今はその状況が完全に変わっています。
00:18:34人間がエージェントを動かすのではなく、イベントがエージェントを動かす世界になりました。
00:18:37そうなると急に、カスタマーサポートやマーケティングツールからのイベントが重要になってくるわけです。
00:18:42そうですよね。
00:18:42それが、プラットフォームとして彼らが直面している現実です。
00:18:46私たちにとっても興味深い議論のポイントです。
00:18:48なるほど。
00:18:48ただ、VercelがHookdeckの直接的なユーザーかというと、そうではありません。
00:18:54Vercelの社内でもCLIツールなどを通じて多くのエンジニアが使っているはずですが。
00:18:57では、Hookdeckの典型的な顧客とはどのような人たちなのでしょうか？
00:19:01例えば、小さなTシャツのネットショップを運営しているとして、どうやって使うんですか？
00:19:05そもそも使う意味があるのでしょうか？
00:19:06おそらくないでしょうね。
00:19:10それはまさに、私たちが常に悩んでいる「100万ドルの質問」です。
00:19:15Webhooksを利用する理由はあまりに広範囲だからです。
00:19:17StripeやShopifyのような一般的なユーザーもいれば、
00:19:19オーストラリアの通信会社や
00:19:21イギリスの決済機関まで使っています。
00:19:22さらには『EVE Online』というゲームや、15年前に出た
00:19:26『Conan the Barbarian』というゲームのコミュニティまでもがWebhooksを駆使しているんです。
00:19:32理由は私にも分かりません。でも、
00:19:35「これが私たちの顧客だ」と定義するのが難しいほど幅が広いのです。
00:19:40特定のユースケースで全体の10%を超えるようなグループさえ存在しません。
00:19:47先ほどのTシャツショップの例に戻りましょう。
00:19:50小さなショップなら、わざわざカスタムアプリを構築することはないでしょう。
00:19:55しかし、アプリをインストールすることはあるはずです。
00:19:58レビュー収集アプリや、在庫通知、
00:20:00在庫管理、あるいは配送代行業者（3PL）と連携するアプリなどです。
00:20:00そうですね。
00:20:01ただ重要なのは、これほど幅広い層がいると、「これが私たちの顧客です」と一言で定義するのが非常に難しいということです。
00:20:06そうですね。
00:20:08そうです。
00:20:09ですから、ユーザー層を見ても、単一のユースケースやグループなどが存在するわけではありません。
00:20:1310%を超えるような。
00:20:14そんな特定のグループは存在しません。
00:20:16先ほどのEコマースのユースケースの例に戻りましょう。
00:20:19まず、小規模なTシャツ屋さんは、おそらく独自にカスタムアプリを構築したりはしていないでしょう。
00:20:25それを必要とするような類のものですね。
00:20:27ですが、ほぼ間違いなく既存のアプリはインストールしています。
00:20:30例えば、レビューを収集するアプリや、再入荷通知用のアプリ、
00:20:35在庫管理アプリ、あるいは3PL（物流）連携アプリなどです。
00:20:39そうしたアプリのすべてが、ほぼ例外なくWebhookに依存しています。
00:20:43ええ。
00:20:43再入荷通知を送りたい場合、私はShopifyストアのすべての在庫
00:20:48更新情報をWebhook経由で監視しています。
00:20:50そして、以前は在庫切れだった商品が入荷した瞬間に、
00:20:53「よし、メールを送らなきゃ」となるわけです。
00:20:54なるほど。
00:20:55つまり基本的に、彼らがインストールしたり追加したりするあらゆるものが、
00:20:59裏側でWebhookに依存しているんです。
00:21:00それが大きなカテゴリーの一つですね。
00:21:02人々はアプリを構築しています。Shopifyだけではありません。例えばStripeも、
00:21:07巨大なアプリマーケットプレイスを持っています。
00:21:09その多くも私たちの顧客ですし、そういった類のものです。
00:21:11もう一つ見られるのは、大規模なストアですね。
00:21:14GymsharkやGood American、Rogueのようなブランドを想像してください。
00:21:19彼らには技術チームがあり、カスタムアプリを構築しています。
00:21:22システム統合のためにカスタムアプリを構築しており、多くの場合、非常に運用重視です。
00:21:28注文を3PLと同期させるタイミングの調整や、メモの追加などですね。
00:21:34あるいは、3PLにデータが届く前に、顧客固有の好みを
00:21:39追加する必要があるといったことなどです。
00:21:41ええ。
00:21:41一部はユーザー体験を強化するためのものでもあります。例えば、カスタム
00:21:46サブスクリプション管理や、ギフトカードを購入した人が友人に送る際の
00:21:51特定メールの送信など、そういった類のものです。
00:21:55私たちがよく目にするのはそういうことです。小規模なShopifyストアは、
00:21:59Webhookを使っている人があまり見られない例かもしれませんが、それ以外の場所では
00:22:04ほぼどこでも、そのセグメントのターゲットになれば、
00:22:08Webhookを利用している企業に行き着くでしょう。
00:22:09なるほど。
00:22:10理解しました。
00:22:11AWS EventBridgeのようなものと比較するとどうですか？
00:22:14他にも耳にする選択肢の一つなので。
00:22:17単に開発者体験が良いというだけなのでしょうか？
00:22:19AWSについては誰もが知っている通りです。Better Stackも多かれ少なかれ
00:22:24同じ主張をしていますよね？
00:22:25ええ。
00:22:26ですから、CloudWatchやAmazonのログサービスなどに対する
00:22:31皆さんの独自のアピールポイントは、そのまま通じるところがあるわけです。
00:22:37それがまさに開発者体験についての議論ですよね。
00:22:40適切なAPI、MCP、優れたUI、確かな信頼性などです。
00:22:46そうです。
00:22:47ええ。
00:22:47AWSの問題は、常に20個ものサービスを
00:22:51使う羽目になり、そのほとんどの名前をもう忘れているような状態になることだと思います。
00:22:56データはあちこちに散らばり、設定もあちこちに散らばり、
00:22:59といった具合です。
00:23:01ええ。
00:23:01それが一つのポイントです。
00:23:02しかし、より広い視点で言えば、AWS EventBridgeは実際には誰とでも
00:23:07統合できるわけではない、という点です。
00:23:08つまり、ベンダー側がAWS EventBridgeと統合している必要があるんです。
00:23:11APIゲートウェイなどで回避する方法はありますが、
00:23:16結局のところ、これはAWSエコシステムのために構築されたものであり、主な
00:23:23ユースケースはAWS内部のイベント（新しいS3ドキュメントがアップロードされたなど）です。
00:23:31そういった類のことですね。
00:23:31サードパーティとの相互運用性については、40ほどのベンダーはサポートしていますが、
00:23:36何千ものベンダーというわけではありません。
00:23:40ShopifyはEventBridgeをサポートしていても、Twilioはサポートしていない、
00:23:45といったシナリオに陥りがちです。
00:23:47そうですね。
00:23:47だからこそ、プラットフォームに依存しない解決策を導入して、
00:23:51全体で機能するようにする必要があるんです。
00:23:52それが、私たちがやろうとしていることの一つです。
00:23:54ベンダーのオプトインや承認、あるいはベンダー側での作業を一切必要としない方法で、
00:23:59このシステムを構築しています。
00:24:02そういった意味で、私たちが構築している仕組みは、HTTP上で純粋に
00:24:08動作するという点でかなり斬新だと思います。
00:24:10URLを提供しますので、既存のWebhook URLを、
00:24:15私たちが提供したURLに置き換えるだけです。
00:24:17そして最終的な宛先は、元々のURLとなります。
00:24:22私たちはその間で、プッシュベースのキューとして機能します。
00:24:25HTTPですべてのWebhookを受け取り、指定された速度で
00:24:28お客様のエンドポイントへ送信します。
00:24:31つまり、コードを再デプロイする必要すらないのです。
00:24:34どんなクラウド、どんなスタックでも、すぐに機能させることができます。
00:24:39ええ。
00:24:40結局、唯一の要件はURLを更新することだけですから。
00:24:44究極のベンダーロックインで、AWSエコシステムでしか動かず、
00:24:48特定の互換性が必要なAWS EventBridgeとは大きく異なります。
00:24:53そうですね。
00:24:53私はEventBridgeを、もう一つの大きなイベントゲートウェイだと捉えています。
00:24:58競合であるAzure Event Gridもシェアを伸ばしていますね。
00:25:04最も直接的な競合、あるいはある意味でインスピレーションの源として、
00:25:10その二つの製品を意識しています。
00:25:13ただ、私たちがやろうとしていることの範囲は、もう少し大きいと思います。
00:25:17それが良いことだと思う人もいれば、
00:25:18そうでないと思う人もいるでしょう。
00:25:20それが欲しいという人もいます。
00:25:22完全にAWSエコシステムに組み込まれていて、
00:25:24CloudFormationを使い、
00:25:26すべてのサービスに精通している人たちですね。
00:25:27彼らは機能を選択して組み合わせたいと思っていて、
00:25:30それはそれで問題ありません。
00:25:31私たちが市場シェアを100%獲得できるとは思っていません。
00:25:34数パーセントのシェアがあれば十分でしょう。
00:25:38私たちは、エステティック企業や開発者などにとって、
00:25:45正しい解決策であることを証明しようとしています。
00:25:48そして他の方々にはAWS EventBridgeが適している、それで良いんです。
00:25:51ここ一年で気づいたのですが、大企業でのダウンタイムの発生頻度が増えていますね。
00:25:59GitHubがダウンするといったミームも多い。
00:26:002年前、私が働いていた頃は、もしP99が
00:26:0299.5%以下に落ちるようなことがあれば、
00:26:07チームで深刻な話し合いになったものです。
00:26:13どうすればこれを防げるか、と。
00:26:14今はもう、それが日常茶飯事です。
00:26:15そうですね。
00:26:17ええ。
00:26:17GitHubが長時間ダウンしていても、みんな慣れてしまった。
00:26:23あなたの立場から見て、今年は以前よりダウンタイムが増えていると感じますか？
00:26:28そして、そうした課題にどう対処していますか？
00:26:33興味深い質問です。Webhookを利用する際、
00:26:37特にGitHubのWebhookは非常に問題が多いですね。
00:26:42RailwayやVercelなどにログインすると、2回に1回はバナーが表示されるような状態です。
00:26:46「GitHubのWebhookが動いていないためデプロイ不可」といった通知ですね。
00:26:47 GitHubのCTOも、インフラの安定性に関するブログ記事を書いていましたが、
00:26:51ミームが飛び交う状況を鎮静化しようとしていました。
00:26:58あまりうまくいったとは思いませんが。
00:27:02記事の中で明確に非難されていたことの一つは、
00:27:03Webhookの安定性と、それがMySQLに依存しているという点でした。
00:27:05ええ。
00:27:09彼らのインフラの課題は、エージェントの台頭もあり、
00:27:12間違いなく非常に困難なものです。
00:27:13OSSのメンテナーが殺到するリクエストに追われているように、
00:27:17GitHubもインフラの洪水にさらされています。
00:27:21間違いなく。
00:27:23ですから、彼らにとっては極めて困難な課題でしょう。
00:27:26私が言いたいのは、私たちもその状況を把握しているということです。
00:27:30私たちは実際に、一部のベンダーについては監視を行っています。
00:27:33例えば「Inngest Radar」と呼んでいるものがあります。
00:27:38すべてのお客様の統計を元に、Webhookの配信レイテンシや稼働率を算出しています。
00:27:41例えば、私たちは「デック・レーダー」と呼んでいるものがあります。
00:27:44その狙いは、すべての顧客や、私たちがデックを通じて受け取るすべてのWebフックから
00:27:49統計情報を集約して、例えば配信遅延がどの程度かといったものを算出することです。
00:27:53ベンダーのP99配信遅延や稼働時間などがどの程度か、といったことを確認できます。
00:27:58例えば、Shopify向けのレーダーはかなり人気があります。
00:28:01数百人ほどの購読者がいますね。
00:28:04仕組みとしては、遅延がベースラインの遅延から一定の標準偏差を超えると、
00:28:09基本的にアラートを送信するようにしています。
00:28:12なるほど。
00:28:12Shopifyの場合、配信のベースライン遅延は4〜5秒程度だったと思います。
00:28:17配信に関しては。
00:28:1710秒を超えるとアラートを出すという感じですね。
00:28:19はい。
00:28:20そういったアラートを送信しています。
00:28:22時系列データのように監視して、稼働時間を確認できるのがポイントです。
00:28:26単なる稼働時間だけでなく、遅延の傾向も時系列で確認できます。
00:28:31長期的にですね。
00:28:32それは間違いなく確認できることです。
00:28:33Shopifyチーム自身もその点はよく認識しています。
00:28:36ただ、配信時間にかなりのばらつきがあるのも見て取れます。
00:28:41ですので、2ヶ月に1回くらいの頻度で、遅延に関するかなり重大なインシデントが発生します。
00:28:46これは通常、目に見えにくい部分だと思います。
00:28:49ダウンタイムの方がはるかに検知しやすいですから。
00:28:51確かに。
00:28:52ダウンタイムならすぐに分かりますよね。
00:28:54DatadogやBetter Stackで見ればいい。
00:28:57またその、メトリクス製品というやつですね。
00:29:01オブザーバビリティです。
00:29:02そう、オブザーバビリティですね。
00:29:03Better Stackなどを使えば、そういったものは簡単に監視できます。
00:29:05ええ。
00:29:06WebエンドポイントへのHTTPリクエストが止まれば、すぐに分かります。
00:29:11その通りです。
00:29:11問題が明らかで、非常にわかりやすいですね。
00:29:14ですが、遅延が60秒まで忍び寄るような場合、実際のメトリクスからでは非常に判断が難しくなります。
00:29:19実際のメトリクスからそれを読み取るのは困難です。
00:29:22ええ。
00:29:23それは処理にかかる遅延であり、本来はトレーシングなどで追跡すべきものです。
00:29:27トレーシングなどを活用すべきですね。
00:29:28ただ、それはベンダー側の遅延なのです。
00:29:31もしコードやビジネスオペレーションにおいて、新しい前提を置いている場合、
00:29:34イベントに対してリアルタイム性を期待していると、60秒後にデータが来ると、
00:29:39多くの微妙な問題やバグ、誤った前提などがコードに入り込む可能性があります。
00:29:44そういった問題が引き起こされます。
00:29:46ですから、私たちはそういった状況において、良いデータを提供できる立場にあります。
00:29:50ユニークな立ち位置と言えますね。
00:29:52「これは自分のせいなのか、ベンダーのせいなのか」を判断できます。
00:29:55その通りです。
00:29:56どちらが問題を抱えているのかがわかります。
00:29:57どれくらい増減したかについて、経験的にコメントできるかはわかりませんが。
00:30:03特定のベンダーがやり玉に挙げられるような、いつものパターンはありますね。
00:30:06指を指しやすい相手というのはいます。
00:30:08それが分散して発生している問題だと言うつもりはありません。
00:30:13特定のベンダーに集中している傾向があると思います。
00:30:16特に配信遅延のところで問題が表面化しやすいですね。
00:30:23もう一つの点は、ほとんどのベンダーで実際の配信遅延は思っているよりも低いという想定です。
00:30:27実際にはほとんどの場合で数秒かかっていて、
00:30:31見方によっては長い時間とも言えますし、そうでないとも言えます。
00:30:34しかし、例えばShopifyの開発者にShopifyの遅延チャートを見せると、驚かれることが多いです。
00:30:40「そんなに遅延しているとは思わなかった」とね。
00:30:43ええ。
00:30:43ある種の期待とのギャップが生じているわけです。
00:30:46以前、かなり大きなEC企業で働いていたときも、同じような問題がありました。
00:30:53遅延が酷いのですが、みんなスパイダーマンのミームのように互いを指さして、
00:30:58どのチームが責任者なのか言い争っていました。
00:30:59おっしゃる通り、たいていはサードパーティベンダーのせいなのです。
00:31:05どうしようもない場合もありますよね。
00:31:07回避策を講じるしかありません。
00:31:08素晴らしい。
00:31:09ベンダーを非難する際にも注意が必要です。
00:31:11ええ。
00:31:11あなた方がされている仕事の文脈では、常に共通の問題でしょう。
00:31:16いつものことですよね。
00:31:18インシデントが発生するたびに、「どの程度ベンダーの責任にするか」が課題になります。
00:31:22しかしある時点で、何が合理的で何が非合理かを考えなければなりません。
00:31:27そして、何が偶然の事故で、何がそうでないかを見極める必要があります。
00:31:29例えば、先日Railwayで、管理用のアウトポストデプロイメントの一部が稼働していたのですが、
00:31:34彼らの価格構造の理由でRailwayを選んでいました。
00:31:36オープンソースと同じバージョンを実行する必要があり、
00:31:40マルチテナント環境を構築していなかったため、オープンソースでは意味がありませんでした。
00:31:44そのため、顧客ごとに個別のデプロイを行っています。
00:31:48その通り。
00:31:49無料プランのユーザーにはRailway上にインスタンスをデプロイしており、
00:31:52通常は問題なく動作していました。
00:31:54しかし先日、彼らのGCPアカウントが停止され、6時間ほどダウンしてしまったのです。
00:31:59そんなことがありました。
00:31:59そうでしたね。
00:31:59だからといって、それをどうこう言うことはできないのですが。
00:32:06責任を転嫁することについて、一つ思うことがあります。
00:32:09ベンダーに対する責任は間違いなくあります。
00:32:11ですが、この線引きは非常に難しいということです。
00:32:14責任を他人に転嫁して自分を免責させたいという、
00:32:18自然な傾向が人々にあるのは間違いありません。
00:32:20そのため、そうした誘惑と戦う必要があります。
00:32:23ええ。
00:32:24ベンダーのせいだと確信できる場合には、その状況を特定し、
00:32:28それを裏付けるデータを手に入れることが面白いと思います。
00:32:31これはベンダー関連の問題においてよくある課題です。
00:32:35確かに。
00:32:35彼ら側のデータは見えませんから。
00:32:37ですから、確証や経験的証拠を持って「間違いなく彼らの責任だ」と断言するのは非常に難しいのです。
00:32:42そうですね。
00:32:43結局、自分たちのデータから推測するしかなく、それが正しいこともあれば間違っていることもあります。
00:32:46そうですね。
00:32:47では、ShopifyやStripeのような企業で障害が発生したとき、
00:32:51イベントはどのように追いつくのか、そしてその負荷でサーバーは大きな打撃を受けないのか気になります。
00:32:57そうですね、基本的には「ラム」が大量に発生するような状態になります。
00:33:00なぜなら、特定のWebフックボリュームを想定すべきではないと私たちは常に言っているからです。
00:33:05想定外のボリュームに対応しなければなりません。
00:33:09なるほど。
00:33:09すべてのベンダーがタイムアウトを強制するという特性を考慮する必要があります。
00:33:14ええ。
00:33:143秒や5秒の応答時間を設定しており、
00:33:15プラットフォームによって異なりますが、応答が求められます。
00:33:18そのため、特にネットワーク遅延やその遅延を考慮すると、
00:33:21実質的に有意義な処理を完了させることは困難になります。
00:33:25そうです。
00:33:25それも理由の一つですが、
00:33:28重要なことは、キューに入れる必要があるということです。
00:33:31同期的に処理することは不可能です。
00:33:33……すみません、何を話そうとしていたか忘れてしまいました。
00:33:39今の質問を繰り返してもらえますか？
00:33:42StripeやShopifyのような企業で障害があった際の話です。
00:33:45ああ、そうでしたね。
00:33:45追いつくという話です。
00:33:47はい。
00:33:47ええ。
00:33:47はい。
00:33:47とにかく、遅延がなんとかという話から、回りくどくなりましたが、
00:33:52オートスケーリングが必要だということです。
00:33:53非常に短い時間軸でスケールできなければなりません。
00:33:56スパイクは複数の異なる理由で発生します。
00:33:58顧客がバルクインポートを行った際など、自然に発生することもあれば、
00:34:03別の理由もあるかもしれません。
00:34:03ええ。
00:34:03でもダウンタイムもその原因の一つです。
00:34:05スパイクは間違いなく発生します。
00:34:07はい。
00:34:07もしShopifyが30分ダウンしたら、復旧した瞬間に、
00:34:11彼らは蓄積されたバックログを一気に処理しようとします。
00:34:16キューの圧力を減らすためにね。
00:34:17つまり、ダウンタイム中に蓄積されたすべてを処理しようとするのです。
00:34:22その結果、彼らは追いつこうとして通常以上の容量でスケールします。
00:34:26追いつくために、容量以上にスケールするわけです。
00:34:28そうですね。
00:34:28その結果、各ストアに大量のリクエストが送られることになります。
00:34:32ですから、そういったIR（不規則性）は存在しますが、
00:34:37その一部は自分たちのせいではありません。
00:34:38ベンダーが自らのインフラ課題を抱えているために、100%ベンダー側の原因で発生します。
00:34:42インフラの課題ですね。
00:34:44明らかにShopifyのWebhook送信能力は、
00:34:49ほとんどの場合、Webhook受信能力よりもはるかに高いですから。
00:34:52ええ。
00:34:52面白いことに、私たちの投資家の一人は元TwilioのCPOでした。
00:34:56それが投資に興味を持ってくれた理由の一つだと思います。
00:34:59彼が言っていたのは、Twilioは日常的に顧客をDDoSしていたようなものだ、ということです。
00:35:04あらゆる目的において、実質的にDDoSだったと。
00:35:07それはある種避けられない問題であり、
00:35:14ベンダー主導のイベントにおける課題の一部と言えます。
00:35:17ベンダーにとっては非常によく知られた問題なのです。
00:35:21サーバーの応答遅延から追跡できることでもありますよね。
00:35:24その通りです。
00:35:26顧客をDDoSすれば、サーバーの応答遅延は必然的に上がります。
00:35:29そしてある時点でタイムアウトし始めます。
00:35:31長いタイムアウトが発生するとスループットを維持するのが難しくなり、問題が深刻化します。
00:35:34HTTP接続を長く保持すればするほど、
00:35:38手元のワーカーで一度に処理できるリクエスト数は減ってしまいます。
00:35:40スケーリングしてさらに送信すれば、状況は悪化します。
00:35:45すべてが積み重なってしまうわけです。
00:35:46処理能力が低ければ低いほど、遅延は急速に悪化するため、
00:35:52状況は非常に自己強化的に悪化していきます。
00:35:57サーバーが飽和状態に近づくと、遅延はさらに悪化します。
00:36:01そしてリクエストは積み上がり続けます。
00:36:04多くのベンダーが行う対策は、エンドポイントを無効化することです。
00:36:07そうしなければ蓄積され続けるからです。
00:36:10彼らも何十万ものHTTP接続を保持したくはないのです。
00:36:14サーバーの応答が遅いせいでね。
00:36:15しかし無効化された途端、データが失われてしまいます。
00:36:19それが落とし穴でもあるわけです。
00:36:21多くの場合、制御不能な変動に対して応答時間を確保することが大きな課題です。
00:36:25それが大きな挑戦となります。
00:36:29また、AIの登場によって、Webフックの分野全体がどのように変化しているのかも気になります。
00:36:37LLMがより多くのWebフックを送信したり、処理したりするようになっているとのことですが。
00:36:43内部的に、HookdeckではどのようにAIを活用していますか？
00:36:48そして、この分野におけるAIの未来をどう見ていますか？
00:36:51そうですね、その方面では多くの動きがあります。
00:36:54私たちのようなソフトウェア開発ショップとしても、
00:36:57あなたたちと同じ課題に直面していると感じます。
00:37:02毎週変化するワークフローやトークンコストといった課題ですね。
00:37:05どの程度のトークンコストが妥当なのか、そういった類のことです。
00:37:10ええ、リーダーボードを作る必要はありません。
00:37:15私はリーダーボードという考え方を非常に恐れています。
00:37:18利益率を破壊する確実な方法のように思えるからです。
00:37:24いくつか考えがあります。
00:37:25まず、先ほど申し上げたように、イベントに対する需要は拡大しています。
00:37:29エージェント的なユースケースによって、人間がトリガーする形からイベントトリガーへと移行しているからです。
00:37:35クラウドエージェント製品などが登場しており、
00:37:41私たちのツールも多く使われています。
00:37:42それらは基本的にスケジュールまたはイベントによってトリガーされます。
00:37:46イベントの一部は抽象化されていますが、GitHubのPRやコメントなど、
00:37:49GitHubのPRやコミット、コメントなど、これらはすべてウェブ駆動型です。
00:37:56しかし明らかに、今後はその枠を大きく超えていくでしょう。カスタマーサポートや
00:38:00Slackなど、あるいはセンサーデータなどから実世界で発生するリアルタイムな事象に至るまで。
00:38:04多くのエージェントが、そういった事象に対応する必要が出てくるでしょうね。
00:38:08つまり、エージェント同士でイベントをトリガーし合う必要性も出てくるはずです。
00:38:12あるエージェントの出力がイベントとなり、それが別のエージェントを
00:38:17あるいは別の企業のシステムをトリガーする。Webhooksのユースケースと言えば
00:38:21確かにそう呼べるかもしれません。実際その通りでしょう。
00:38:23ですが、現在のWebhooksを取り巻くセマンティクスには欠陥があると考えています。
00:38:28セキュリティやプロトコル、効率性といった側面においてです。
00:38:33だからこそ、私たちは「イベント送信先（Event Destinations）」を
00:38:36より優れた、最適化されたパターンとして推進しているんです。また、イベントに応答して
00:38:40エージェント的なワークフローを実行する場合、それは非決定的で長時間実行される可能性があり、
00:38:47そうなると、発生したイベントに合わせてキャパシティを調整したり拡張したりするのが
00:38:51非常に困難になります。スループット管理やキャパシティ管理が
00:38:55格段に難しくなる。クラウドのタイムアウトや評価（Eval）の失敗などで、
00:39:00エラー率も高くなるでしょう。ですから、アプリケーション構築の観点から、
00:39:07どのコア・プリミティブを使うべきか、どこで実行し、どのくらいの時間実行させるか、
00:39:12バックプレッシャーをどう処理するかなど、多くの新たな課題があります。
00:39:16社内の話に戻すと、私たちはまだ正解を探っている最中です。
00:39:21一方で、キャパシティについては完全に圧倒されています。
00:39:25驚くことではありませんし、私だけが特別な洞察を持っているわけでもありません。
00:39:29ただ一つ言えるのは、CLIプロンプトやCodexから、
00:39:34実際に高品質で洗練された製品を出荷するまでのハードルについてです。
00:39:41ミームや煽り文句の中で、そういったニュアンスが失われつつあると感じます。
00:39:45膨大なトークンを消費して、最終的に本当に価値のあるものを生み出せるのか、疑わしい場合もあります。
00:39:50これまで私たちが経験してきた中で、セキュリティ面などでの
00:39:55大きな恩恵は間違いありません。コードレビューなどはその一例です。
00:40:01しかし、それらはあくまで前提条件（テーブルステークス）に過ぎないとも思います。
00:40:06最終的に価値をもたらすものではない。本当に valuable（価値ある）なものを
00:40:11他者がそれから恩恵を受けられるように構築するとなると、
00:40:14そこにはまだ大きな隔たりがあります。私たちのチームには、
00:40:19そのレベルのセンスや洞察力、顧客理解、共感力をもたらす責任があると感じています。
00:40:25それらはチャットボックスから直接得られるものではありません。
00:40:31もしかすると、私たちが保守的すぎて、もっと速く進めるのかもしれません。
00:40:35もしすべてをワンショットで実行していればですが。ですが、現在の私たちのアプローチは、
00:40:42最終的な成果物やユーザーに提供するものに対して、高い期待値を維持し続けることです。
00:40:47もちろん、できることが増えるという意味ではそうですし、センスや共感力のある
00:40:53人々がユーザーに価値をもたらす機会も増えるでしょう。障壁となっていたのはコードでしたから。
00:40:57例えば今、社内のほぼ全員が「コーディング」しています。
00:41:01デザイナーも今では立派なVipeコーダーで、ウェブサイトの責任を完全に担っています。
00:41:06ダッシュボードの作業や、プロダクトマーケティング、DevRelのメンバーに至るまで、
00:41:11全員がトークンを最大活用しています。もしリーダーボードがあったら、彼らは間違いなく上位にいるでしょう。
00:41:16それは本当に良いことです。彼らは力を得たのですから。
00:41:20彼らは洗練されたエンドユーザー向けのものを出荷するために、
00:41:25先ほど言ったクリティカルシンキングを持つ必要があります。コードが障壁ではなくなった今、
00:41:30純粋なエンジニアリングというよりは、そこからの恩恵が大きいと感じます。
00:41:36もちろん、エンジニアリング自体も大きな価値を得ていますが、依然としてボトルネックは
00:41:40その「センス」にあると考えています。それに、私は
00:41:45無意味なPRのレビューに時間を取られすぎています。これも裏返しですね。
00:41:51本当に。レビューしなければならないコードの量たるや。
00:41:56ええ。まず起こり得ないような些細な脆弱性まで。
00:42:01低優先度ですらないかもしれませんが、一度表面化すると
00:42:06責任を感じてしまう。それは普通のことだと思います。ですが、
00:42:09これほど多くのPRが同時に開かれていることは今までありませんでした。
00:42:14すべてを把握するのは少し気が狂いそうです。
00:42:18何でもできるからといって、すべてをやるべきではないという判断が重要です。
00:42:21LLMにはそうした側面があります。判断を持ち込むことが
00:42:26これまで以上に重要になっています。何が最終的に価値を生むのか、
00:42:31価値を生む可能性を秘めているのか、その判断が重要です。
00:42:34エージェントを扱うと、ToDoリストを埋めるような
00:42:39満足感があるんですよね。たまに思考停止して、
00:42:44ただリストをこなして、チェックを入れたいだけになるというか。
00:42:48LLMを使うとそういう感覚になります。この会話を始めて、
00:42:53あの会話も始めて…5つか6つものエージェントを動かして、
00:42:57エージェントが動いていて、彼らも自分たちのチェックリストをこなしているんだ。
00:43:02そう、そう、そう。ああ、そうですね。その……何というか、
00:43:06その達成感と即座の報酬には抗いがたいものがあります。
00:43:11自分の話になりますが、チームの規模はどれくらいですか？
00:43:15今は10人です。おお、それはかなり少数精鋭ですね。尊敬します。ずっと目標にしていました。
00:43:23私は自分が最高のマネージャーだとは思っていないので、その方が全員にとって良いはずです。
00:43:29半分冗談ですが、創業時がちょうどコロナ禍でした。
00:43:33全員がリモートでしたし、最初からシニアで経験豊富、
00:43:38極めて自律的な人たちを採用するというマインドセットでした。
00:43:45具体的には、2週間に一度、プロダクトとインフラについて話し合う
00:43:50たった1回のミーティングだけです。可能な限り非同期的なワークフローを目指しました。
00:43:56これはAIのユースケースとも相性が良いと思います。私たちは既に
00:44:01自律的な人たちを採用し、最適化してきたわけですから。これが正しいとか
00:44:06間違っているというつもりはありませんが、私たちには合っているようです。
00:44:11私と私の正気のためには、それが一番です。
00:44:14会話の冒頭で言及されていたことについて触れたいのですが、
00:44:21「Webhooksは死んだ、これからはイベントゲートウェイだ」というのは、ご自身で造語されたのですか？
00:44:27イベントゲートウェイとは一体何なのでしょうか？全く理解できていなくて。
00:44:32はい、造語です。確立されていないプロダクトカテゴリーを構築するのは非常に困難でした。
00:44:37マーケティングやコミュニケーションの課題があり、
00:44:41この概念をどう説明するか。以前は「Webhook管理インフラ」と呼んでいましたが、
00:44:46全く心に響くものではありませんでした。
00:44:51説明の難しさはもちろん、プロダクト構築にも課題があります。
00:44:54既存のカテゴリー、例えば可観測性（Observability）のような分野で製品を作るなら、
00:44:58何のために最適化すべきかが明確です。価格やDXなどですね。
00:45:02コアとなるセマンティクスが既に存在しています。しかし、
00:45:07まだ存在しないものを構築する場合、その意味を創造し、
00:45:10さらにその上に魅力的な価値提案を積み重ねる必要があるのです。
00:45:14それは非常に難しい。この数年の教訓ですね。
00:45:19既存カテゴリーにない製品を作るのは本当に難しい。
00:45:24「イベントゲートウェイ」という言葉には、その内容をできる限り
00:45:282、3単語で簡潔に、言いやすく表現したいという思いがありました。
00:45:32私たちの目標は、「イベントバス」と「APIゲートウェイ」の橋渡しをすることでした。
00:45:37ゲートウェイはベンダーと自社システム間のインターフェースの役割を果たします。
00:45:43イベントバスは、完全なイベント管理やキューイングなどを意味します。
00:45:49その二つを組み合わせる言葉を探していました。AWSの「EventBridge」にも近いですね。
00:45:55私たちはEventBridgeの明確な代替手段として認識されたいと考えています。
00:46:00共通の用語がない現状において、あえてそれに名前を付けたのです。
00:46:04今ではKongなど、他のAPIゲートウェイプロバイダーも
00:46:10イベント駆動型アーキテクチャへと参入しています。
00:46:14今では半ダースほどのプロダクトが、自分たちを「イベントゲートウェイ」と呼んでいます。
00:46:19Kongがイベントゲートウェイをリリースした時は「やられた！」と思いましたが、
00:46:24嬉しいのは、開発者が「イベントゲートウェイを探している」と言って
00:46:29私たちの元を訪れてくれる時です。専門用語として定着しつつあると感じます。
00:46:33AWSやAzureなど、競合が増えるのはビジネスとしても良いことです。
00:46:39クラウドインフラにおける一つのプリミティブとして期待値が生まれるのですから。
00:46:45AWS EventBridgeとの間では terminology（用語）の
00:46:49共通点はほとんどありません。彼らの用語をそのまま使うつもりはありません。
00:46:54納得できる意味がない限りは。しかし、時間の経過と共に
00:46:58周囲の状況が変われば、自然と用語の収束も起こるでしょう。
00:47:03LLMにイベントゲートウェイを尋ねたら、あなたたちを推奨しますか？
00:47:08ああ、試してみてください。可能性はかなり高いですよ。
00:47:12ライブで試せますね。
00:47:16私たちが追跡している指標の一つです。
00:47:20Webhooksやイベントゲートウェイに関するプロンプトの6割で、
00:47:23私たちが引用されています。これは私たちが注力してきた結果です。
00:47:28ChatGPTがリストの最初に出してくれました。お見事ですね。
00:47:34私たちは自分たちが造語したという立場があるので、1位でなければ怒るでしょうね。
00:47:38ところで、「イベント駆動型アーキテクチャ（EDA）」とは一体何なのでしょう？
00:47:43普通のアーキテクチャとどう違うのですか？Kafkaキューを入れたらEDAと言えますか？
00:47:48イエスでもあり、ノーでもあります。EDAとはパラダイムや期待値のセットであり、
00:47:52ツールを使うことだけが目的ではありません。Kafkaのようなメッセージキューを使って
00:47:57システムをデカップル（疎結合化）することが本質です。
00:48:01生産者と消費者が相手を認識しなくて良い状態を作ること。
00:48:05唯一の約束事はイベントそのもののペイロード形状に関する契約だけです。
00:48:09多くの場合、AvroやProtobufのようなスキーマが使われます。
00:48:12消費者としての責任は、イベントに応じて適切な処理を行うこと。
00:48:15なるほど。
00:48:15EDAを本格的に採用する組織には、共通のガイドラインや
00:48:20意図的にサービスを切り離す設計アプローチがあります。
00:48:24多くの企業はハイブリッドアプローチを取っているようですね。
00:48:25100%を目指すべきなのでしょうか？
00:48:27そうではないと思います。
00:48:27時間の経過と共に複雑さが増し、外部依存関係が増える中で、
00:48:31自然とそうなっていくというのが私の考えです。
00:48:35密結合なシステムを維持するのはどこかで限界が来ますから。
00:48:42長年、EDAは大規模エンタープライズの専売特許のようでしたが、
00:48:46今は変化しています。Webhooksが普及のきっかけとなり、
00:48:48ツールも良くなっています。
00:48:49例えば、
00:48:49ChatGPTがそう教えてくれました。お見事ですね。
00:48:52開発にとって扱いやすく、怖くない存在になっています。
00:48:56大規模なKafkaデプロイメントがなくても始められますから。
00:49:00ただ、EDAという用語自体の意味は少し曖昧になっていますね。
00:49:03怒る人もいるかもしれませんが。
00:49:05私が指すのは、あくまでシステムの「デカップリング（疎結合化）」です。
00:49:11エンジニアが順序や依存関係といった新たな懸念と
00:49:17向き合う必要がある世界へ入っていくこと。
00:49:21私たちがやっているのは、それを誰もが扱えるようにすることです。
00:49:25TemporalやTrigger.devなど、この空間には多くのプレイヤーがいて、
00:49:31確かにツールはそうですね。Kafkaやメッセージキュー、あるいはイベント
00:49:35ストリーミングを使ってシステムを分離することが目的ですから。結局のところ
00:49:39元AWSのDavid Boyanをチェックしてみてください。
00:49:43お互いを意識する必要がない、ということですよね。つまりコンシューマーは、
00:49:47誰かが生成したイベントのストリームを消費できるわけです。唯一必要なのは、
00:49:53イベントそのものに対するコントラクト、つまりペイロードや構成に関する取り決めだけです。
00:49:57ええ。多くの場合、特定のスキーマが使われますよね。
00:50:02Avro形式やProtocol Buffersなどが一般的ですし、他にも色々あります。
00:50:06ペイロードの内容に関する標準的な期待値が存在します。結局、コントラクトとは
00:50:11「こうしたイベントが存在する」という合意なんです。コンシューマーとしては、
00:50:16「注文作成」や「製品更新」といったイベントに対して、やるべき処理を行うのが責任です。
00:50:21そうですね。EDAを真に導入している組織では、このパターンの
00:50:25体系化が進んでいるのが見て取れます。具体的にどうすべきか、
00:50:29ペイロードの形式はどうあるべきかというガイドラインが存在するんです。
00:50:32そして、意図的にサービスを疎結合にして、
00:50:36イベント駆動型の通信を構築するというアーキテクチャ・アプローチをとります。
00:50:41多くの企業がハイブリッドなアプローチをとっていると感じます。イベント駆動な部分と、
00:50:45そうでない部分がある。100%イベント駆動にすることを目指すべきなのでしょうか？
00:50:50それとも、あくまでアーキテクチャのサブセットとして捉えるべきなのでしょうか。
00:50:54100%である必要はないと思います。ただ、成長とともに複雑さが増していき、
00:51:00サードパーティの依存関係なども増えると、自然とそうなっていくのでしょうね。
00:51:04ある時点で、すべてのシステムを密結合のまま運用するのは非常に困難になりますから。
00:51:09スケーリングや相互依存関係を考えると、そうせざるを得ない局面が来るんです。
00:51:14一般的に「イベント駆動アーキテクチャ」という言葉を聞くと、多くの人は
00:51:19大規模なエンタープライズを想像するでしょう。もっともな話です。
00:51:23実際、最初の10年ほどは大規模な企業が中心でした。しかし今は変わってきています。
00:51:28パターンに慣れる人が増えたこともありますし、
00:51:32WebHookがその入り口になったり、ツールが改善されたことも大きいです。
00:51:37RabbitMQや、RedisベースのBull MQのようなライブラリが充実してきました。
00:51:41PythonならCelery、RubyならSidekiqといったツールもありますね。
00:51:46Sidekiqの開発陣による新しいライブラリも出ているようです。いずれにせよ、
00:51:51扱いやすいツールが次々と登場しています。敷居が下がっているのは間違いありません。
00:51:57巨大なアーキテクチャチームや、高コストなKafkaのデプロイメントが
00:52:01必須というわけではなくなったんです。ただ、この用語自体は
00:52:05少し意味がぼやけてきたかもしれません。それを聞くと不快に思う人もいるでしょうが。
00:52:11時間が経つにつれて、何をもってそう呼ぶのかという定義が少し曖昧になりました。
00:52:15私が言うときは、主に「システムの疎結合化」を指しています。
00:52:19それから、エンジニアが考えるべきプログラミング上の懸念点、つまり、
00:52:25依存関係や順序制御といった課題から解放されることも含めてですね。
00:52:31私が「イベント駆動アーキテクチャ」と言うときは、そういった
00:52:37これまでになかった新しい懸念事項に対処する世界に足を踏み入れる、という意味です。
00:52:43なるほど。それらの懸念に対応できるように、
00:52:48構築方法を学び、適応していく必要があるわけですね。
00:52:52私は必ずしも、昔ながらの大規模エンタープライズ方式を想定しているわけではありません。
00:52:58誰もがこうした恩恵を受けられるようにしたいのです。もちろん、
00:53:03大企業のようなやり方を想定しているわけではありません。私たちの目的は、ある意味でその技術を
00:53:08誰にでも使えるようにすることだと思っています。もちろん、そう考えているのは私たちだけではありません。
00:53:14他にもさまざまなアプローチで取り組んでいる企業がたくさんあります。
00:53:18ワークフローエンジンやステップ関数など、領域が重複しているものも多く、
00:53:22Temporal、Ingest、Trigger.devといったサービスもその一例ですね。ですから、実際には
00:53:28多くの動きがある分野であり、もう明確で固定された定義なんて存在しないのかもしれません。
00:53:34イベント駆動型アーキテクチャや、それに関連するパラダイムについて
00:53:38もっと詳しく学びたい人には、David Boyanという人がおすすめです。
00:53:42以前はAWSのデベロッパーアドボケイトとして、EventBridgeの仕事をしていました。
00:53:49彼が描いた図解の解説シリーズは有名ですね。現時点で、おそらく数百本はあるでしょう。
00:53:55彼は現在、EventCatalogというオープンソースプロジェクトも運営していて、ポッドキャストの
00:54:02ゲストとしても適任かもしれません。とにかく、彼の解説は驚くほど深くまで掘り下げていて、
00:54:07興味のある人にはぜひおすすめしたいですね。素晴らしい。ショーノートに追加しておきます。
00:54:14イベントやWebフックに関するあなたの知識は本当に豊富ですね。Hookdeckを
00:54:19構築する中で身についたものですか？それとも以前からWebフックに課題を感じていたのですか？
00:54:23ここで本格的にイベントについて深く掘り下げることになったのでしょうか？
00:54:27まさにその通りです。学びは現場の問題から直接得られました。それに加え、
00:54:34第一原理に基づいた考え方も重要でした。当時、私が直面していた問題について、
00:54:38私自身も十分な知識を持っていなかったことが、そもそも問題が起きた原因の一部でもありました。
00:54:42つまり、既存の解決策を問題に当てはめるのではなく、問題そのものと向き合い、
00:54:47そこから解決策を導き出すというプロセスが必要だったのです。今では、
00:54:51あらゆる業界の何十万ものWebフックを扱ってきました。
00:54:55そうした会話を通じて自然と知識を吸収していった感じです。本当に興味深い経験ですね。
00:54:59元々はプロダクトデザイナーから始まって、フルスタック開発者、バックエンドエンジニアを経て、
00:55:05今はインフラエンジニアとして、非常に深いところまで潜り込んでいます。
00:55:11顧客の懸念に耳を傾け、アーキテクチャを見直す中で得られた知見が大きいです。
00:55:15もちろん、チームメンバーも同様のシステムで豊富な経験を持っており、その知識が会社に
00:55:21大きく貢献してくれています。では、いつ頃この分野にビジネスの可能性を感じましたか？
00:55:26開発を始めてどこかで公開したとき、すぐに良い反応がありましたか？それとも人々に理解してもらうまでには、
00:55:30かなり時間がかかったのでしょうか？時間がかかったという言葉だけでは足りないほどですね。
00:55:33きっかけは、先ほど言及したMediumの記事でした。『Webフックは壊れている、でも解決策はある』という内容です。
00:55:38私は人々のためにプロダクトを作るというマインドセットで取り組んでいました。
00:55:42最初のバージョンはセルフサービス形式で、ユーザーが自分の最初の接続を作成できるようなものでした。
00:55:47記事を投稿しただけで、当時はビジネスにしようという野心すらありませんでした。
00:55:53これまでに失敗した20個のサイドプロジェクトの1つに過ぎなかったのです。今から振り返ると、
00:55:57当時の数字は本当にわずかでしたが、それでも記事経由で5人ほどが連絡をくれました。
00:56:01サイドプロジェクトをやっている人ならわかると思いますが、自分の作ったものを誰かに使ってもらうというのは
00:56:07本当に難しいことです。5人というのは、それまで私が経験した中で最高の数字でした。
00:56:12当時の私はブリティッシュコロンビア州でキャンピングカーに乗り、ロッククライミングをしていました。
00:56:16スタートアップなんて全く意識していませんでしたが、彼らと対話し、問題を一緒に解決することに熱中していました。
00:56:21その後、週に1人くらいのペースで連絡が来るようになり、通知を受け取るたびに、
00:56:26Slackで通知が来るたびに興奮していました。それが今では、追いきれないほどになっています。
00:56:32SlackをDDoS攻撃しているわけではありませんよ。今でもSlackの通知は使っていますが。
00:56:37なるほど。うまくいっているようですね。当初の仮説として、『可観測性のためだけに作られた』という点は
00:56:42不十分でした。しかし『メッセージバスを再発明している』と言い換えた瞬間、スコープが劇的に広がりました。
00:56:48最初のキューイングエンジンを作っている最中に、共同創業者であるCTOと出会いました。
00:56:55スコープが大きく広がることを確信した時、エンジェル投資家からプレシード資金を調達することにしました。
00:57:00開発にはかなりコストがかかることは明らかでしたし、実際その通りでした。一般的なサンフランシスコのルートではなく、
00:57:05モントリオールで構築したのですよね？それは少し違います。
00:57:08エンジェル投資家から40万ドルを調達しましたが、機関投資家からのVC資金ではありませんでした。
00:57:13その後、Hacker Newsに投稿したことで状況が変わりました。最高の結果とは言えませんが、予想以上でした。
00:57:18Hacker Newsの投稿後、300ドルのプランを買ってくれたユーザーがいたとき、
00:57:21共同創業者と『やったぞ、成功だ』と確信したのを覚えています。
00:57:25その夜はシャンパンで贅沢な夕食を楽しみました。その結果、投資家から積極的に連絡が来るようになりました。
00:57:31シリコンバレーのMatrix Partnersから調達し、今もカナダの会社としてモントリオールを拠点にしています。
00:57:38いや、当時は間違いなく違います。でも、今もまだそれを使っているとおっしゃいましたよね？だから聞いているんです。
00:57:44コロナ禍を経て、リモートチームが定着したことも大きかったです。ZapierやGitLabが先駆者ですね。
00:57:48カナダの創業者たちの間で、デラウェア州での法人登記を求められるという議論がありますが、
00:57:54結局のところ、断る選択肢もあります。
00:57:58彼らの仕事は資本を投下することであり、投資対象やアイデアを探しています。良いアイデアがあり、
00:58:02それを尊重してくれる投資家は必ずいます。私は今もモントリオールにいられることを幸せに思っています。
00:58:08同じカナダ人として、成功事例を聞けるのは嬉しいです。Hookdeckは最初のスタートアップですか？
00:58:15それとも他の経験が投資家との繋がりを作ったのでしょうか？私は14歳でPCの修理を請け負うなど、
00:58:19常に起業家精神を持っていました。失敗したサイドプロジェクトもたくさんあります。
00:58:23中でもEコマース企業の最初の社員としての経験は非常に形成的なものでした。4人から40人への成長過程を
00:58:28見届けられたことは大きな財産です。
00:58:32また、そのEコマース企業での最初の投資家が、Hookdeckの最初の投資家でもありました。
00:58:36全くゼロからのスタートではなかったのです。今ここにいることは数年前には想像できませんでした。
00:58:39Kiwi Morningsという健康朝食のスタートアップがあったそうですね？
00:58:44それは失敗したビジネスの一つです。妻と始めたもので、妻が職場で持参していた朝食を
00:58:51同僚が欲しがったのがきっかけでした。なぜ営業職の同僚が他人の朝食を欲しがるのか分かりませんが、
00:58:56そこからビジネスに繋げました。Slackボットで注文を受け、オフィスに朝食を配達するサービスです。
00:59:00しかし、朝4時から動き回る必要があり、食品ビジネスは利益率が低く、非常に大変でした。
00:59:05予想以上でした。面白いエピソードがあって、300ドルのプランを買ってくれた人がいたのを覚えています。
00:59:11コロナでオフィスランチ系ビジネスは全滅したので、幸運なタイミングでした。
00:59:18もう勝ったも同然だ。絶対成功するって確信したよ。
00:59:22その夜は食事に出かけて、全部使い果たしたよ。そんな感じだった。
00:59:25ポーリング（プル）ベースのキューイングシステムは、プッシュベースのシステムに比べて非常に劣っています。
00:59:31これまで良いプッシュベースのシステムが作られてこなかったのが原因です。
00:59:34ポーリングベースだと、キューごとに消費者が必要になり、マルチプレクシングの問題が発生します。
00:59:38プッシュベースなら、全てのキューが同じ消費者にプッシュでき、APIのようにスケーリングできます。
00:59:44しかし、多くのプッシュベースシステムは、スループット制御の粒度が粗すぎて実用的ではありません。
00:59:50GCP Pub/Subのように、APIが速度低下するまでレートを上げるだけのシステムでは、
00:59:55サーバーがクラッシュしてはゼロに戻る、という悪循環に陥ります。
01:00:00もし、スループットを細かく制御できるプッシュベースのメッセージキューを構築できれば、
01:00:04アーキテクチャは劇的に簡素化されます。これが私の譲れないこだわりです。
01:00:08全てを理解したとは言えませんが、理にかなっているのは分かります。
01:00:12GitLabなどの企業は、他の誰よりもずっと前から同じことを実践していましたから。
01:00:17アレックス、ありがとうございました。Better Stackポッドキャストをお聴きの皆さん、
01:00:21SpotifyやApple Musicなどで配信中です。
01:00:27それでは、さようなら。さようなら。さようなら。
01:00:32さようなら。
01:00:38さようなら。
01:00:42さようなら。
01:00:47さようなら。
01:00:54さようなら。
01:00:58さようなら。
01:01:03さようなら。
01:01:07さようなら。
01:01:11さようなら。
01:01:15さようなら。
01:01:19さようなら。
01:01:24さようなら。
01:01:27さようなら。
01:01:31さようなら。
01:01:36さようなら。
01:01:41さようなら。
01:01:47さようなら。
01:01:52さようなら。
01:01:57さようなら。
01:02:06さようなら。
01:02:11さようなら。
01:02:14さようなら。
01:02:19さようなら。
01:02:23さようなら。
01:02:27さようなら。
01:02:34さようなら。
01:02:38さようなら。
01:02:44さようなら。
01:02:48さようなら。
01:02:53さようなら。
01:02:58さようなら。
01:03:03さようなら。
01:03:07さようなら。
01:03:13さようなら。
01:03:19さようなら。
01:03:23さようなら。
01:03:27さようなら。
01:03:31さようなら。
01:03:36さようなら。
01:03:39さようなら。
01:03:44さようなら。
01:03:48さようなら。
01:03:54さようなら。
01:04:02さようなら。
01:04:09さようなら。
01:04:14さようなら。
01:04:19さようなら。
01:04:24さようなら。
01:04:30さようなら。
01:04:36さようなら。
01:04:41さようなら。
01:04:47さようなら。
01:04:51さようなら。
01:04:56さようなら。
01:05:01さようなら。
01:05:06さようなら。
01:05:11さようなら。
01:05:16さようなら。
01:05:20さようなら。
01:05:25さようなら。
01:05:29さようなら。
01:05:34さようなら。
01:05:42さようなら。
01:05:46さようなら。
01:05:52さようなら。
01:05:57さようなら。
01:06:01さようなら。
01:06:06さようなら。
01:06:12さようなら。
01:06:18さようなら。
01:06:22さようなら。
01:06:29さようなら。
01:06:35さようなら。
01:06:42さようなら。
01:06:49さようなら。
01:06:56さようなら。
01:07:02さようなら。
01:07:07さようなら。
01:07:12さようなら。
01:07:16さようなら。
01:07:21さようなら。
01:07:26さようなら。
01:07:31さようなら。
01:07:36さようなら。
01:07:41さようなら。
01:07:45さようなら。
01:07:49さようなら。
01:07:54さようなら。
01:07:58さようなら。
01:08:02さようなら。
01:08:07さようなら。
01:08:13さようなら。
01:08:17さようなら。
01:08:22さようなら。
01:08:29さようなら。
01:08:33さようなら。
01:08:37さようなら。
01:08:40さようなら。
01:08:45さようなら。
01:08:50さようなら。
01:08:55さようなら。
01:09:00さようなら。
01:09:06さようなら。
01:09:11さようなら。
01:09:15さようなら。
01:09:20さようなら。
01:09:24さようなら。
01:09:29さようなら。
01:09:34さようなら。
01:09:40さようなら。
01:09:46さようなら。
01:09:50さようなら。
01:09:57それでは私からお別れの挨拶を。私からもお別れを。そして私からも。