CMSを削除してビルド時間を1/3に短縮した話
Article by: Eli Lennox（了読時間：11分） Sentryでは、ものが壊れないことに執念を燃やし、それこそが私たちの存在意義だと考えています。しかしかつて、自社のマーケティングサイトがその信念を揺るがしてしまう時期がありました。 sentry.io 上で皆さんが目にするもの（マーケティングサイト、ブログ、オープンソースのマイクロサイトなど）の多くは、従来のヘッドレスCMSを基盤とした古いGatsbyサイト群で動いていました。理論上は機能していましたが、実際には壊れやすいプラグインの寄せ集め、制限の多いスキーマ、そして肝心な出荷タイミングに限って失敗する外部API依存に振り回されていました。 そこで私たちは、まともなエンジニアリングチームなら当然そうするように、それをすっぱり捨てて、Astro、Markdown、AI駆動の自動化で置き換えました。 問題：「ヘッドレス」という頭痛の種 旧スタックは、不必要に複雑な代物になりつつありました。 ビルドのボトルネック：Gatsbyの統合データレイヤーは便利でしたが、コンテンツが増えるにつれてビルド時間は1回あたり約14分に膨らんでいました。1日平均95回のビルドを行っていたため、毎日約22時間分のビルド時間を消費していました。 CMSのコスト：約2,500ページのコンテンツを1つのCMSインスタンスで管理していました。ページスキーマとコンポーネントスキーマが並立しており、条件付きフィールドが使えなかったため、スキーマの上限に達しないよう条件付きフィールドのプラグインを別途購入する羽目になりました。月額サブスクリプションに加えて年間サブスクリプションのコストも重なり、それでもスケーラビリティは限られたままでした。 外部依存の脆さ：すべてのビルドがGatsbyプラグイン経由で外部のCMSとマーケティングオートメーションシステムのAPIに依存していました。リビルド開始前の最後の1か月で、CMSのGatsbyプラグインが1日に3〜5回失敗し（サポートチケットを提出しても解決策はなし）、マーケティングオートメーションAPIもレート制限で1日に複数回失敗していました（詳しくは後述）。 解決策：Astroと「ただのファイル」の力 フレームワークをAstroに移行しました。モダンなWeb向けに設計されており、デフォルトで高速、そして驚くほど柔軟性が高いことを選定理由としました。 Viteによる高速化：Viteへの移行により、ローカル開発と本番ビルドがようやく2026年らしい速度になりました。ビルド時間は約14分から4分未満に短縮され、1日あたり約15.8時間分のビルド時間を節約できています。 フレームワーク非依存：Astroは目的に最適なツールを使う自由を与えてくれます。コンポーネントにReactが適していればReactを使い、シンプルな静的コンテンツであればHTML/CSSで済みます。 Vercelに重い処理を任せる：画像処理をVercelにオフロードすることで、ビルドプロセスを遅らせることなくアセットを最適化できています。 しかし最大の変化はフレームワークではなく、コンテンツの管理方法でした。ヘッドレスCMSのUIをMarkdownとFrontmatterに置き換えたのです。 AIネイティブなコンテンツ管理（SaaSの肥大化なし） CMSプロバイダーの「AIアドオン」にお金を払う代わりに、Claude Skillsとの直接連携を自前で構築しました。 今ではサイトを更新する際、肥大化したダッシュボードにログインする必要はありません。スキルを使ったワークフローで作業します。 1. ユーザーをガイドしながら、MarkdownファイルとFrontmatterを正確に更新するプロセスを進めます。 2. ライブプレビューを生成します。 3. レビュー用のPull Requestの下書きを作成します。 CMS統合AIを使わず、なぜカスタム構築にしたのか。 依存ゼロ：コンテンツはリポジトリに置かれます。APIの障害がなければビルドの失敗もありません。 スキーマの制限なし：Frontmatterで構造を自分たちで定義します。新しいフィールドやスキーマタイプが必要になれば、追加するだけです。サブスクリプションの制限も、プランの縛りもありません。 「Sentryらしい」やり方：深い技術志向を持つデベロッパーファーストの企業として、コンテンツをコードとして管理することは自然な選択です。バージョン管理され、ピアレビューされ、レンダリングするコンポーネントのすぐそばに置かれます。 実施プロセス マーケティングサイトとブログ合わせて約2,500ページのサイトを移行するのは、大規模なプロジェクトです。チームは2.5人の開発者で、期間は2か月でした。 チームが小さく、サイトの規模が大きかったため、コーディングの多くをClaude Codeに頼りました。開発者たちは計画立案、スコープ定義、要件整理に時間の大半を費やし、コードのレビュー、変更の指示、アウトプットの調整を行いました。 スコープ定義 このプロジェクトでは、次の2つの理由からスコープ定義が比較的容易でした。 これらのWebサイトにはモノレポを使用しているため、ボットがビルド・移行対象の全体像を把握できていた。 […]
【React Native SDK】Expo アプリのデバッグが簡単に
Article by: Aleksandr Pantiukhov Expo アプリからのイベントは、React Native アプリ全体のイベント量の約 75% を占めています。この数値を受けて、Expo アプリのデバッグとパフォーマンスのワークフローを改善するために、Sentry React Native SDK への投資を行うことは自然な判断でした。 このアップデートにより、以下が可能になります。 OTA アップデートのチャンネルやバージョンでイシューをフィルタリングし、特定のアップデートに起因する問題かどうかを即座に絞り込む 緊急リリースに対するアラートを受け取り、ユーザーから報告される前に OTA パイプラインの障害を検知 EAS Build の健全性を Sentry 上で追跡できるため、ビルドログを辿ることなく問題の発生箇所を特定 ナビゲーションパフォーマンス全体を可視化し、プリフェッチのタイミングやアセット読み込みまで含めて確認 自動 OTA 更新コンテキストの付与 Expo Updates を使った OTA 配信では、適切なコンテキストがないと問題の原因が見えづらくなります。どの update channel だったのか、どの runtime version だったのか、埋め込みバンドルだったのか、それともダウンロードされた更新だったのか、といった情報です。 今回のアップデートでは、すべての Sentry イベントに ota_updates コンテキストが自動で付与されます。追加設定は不要です。update ID、channel、runtime version、起動時間、埋め込みアセットの使用有無などが取得できます。これらは Expo プロジェクトで標準で収集されます。 さらに、すべてのイベントには検索可能なタグ（expo.updates.channel、expo.updates.runtime_version、expo.updates.update_id）も付与されるため、特定のチャンネルやアップデートに絞ったフィルタリングを簡単に行えます。 […]
サイトからCookieをなくして2年：私たちはどこにたどり着いたのか
Article by: Matt Henderson 2024年1月、私は sentry.io からすべての広告 Cookie とユーザートラッキングを削除したことについて書きました。当時、その決定から8か月が経っていましたが、何が壊れ、何が予想外だったのかを、まだ検証している最中でした。その記事は大きな反響を呼びました。おそらく、これまで私たちが公開した記事の中でも最も多く読まれたものの一つです。理由は単純で、Web 上でプロダクトを作ったり運営したりしている誰もが、同じ Cookie 廃止の流れを見つめながら、「もし本当に誰かが思い切って全部やめたら、実際どうなるのか？」を気にしていたからだと思います。 それから、もう2年以上が経ちました。私たちは Cookie を戻していません（そもそも戻すつもりもありませんでした）。そして、その結果として、成長予算の使い方はかなり大きく変わりました。最初から壮大な戦略を立てていたわけではありません。ですが、Cookie をなくしたことで、「どこにお金を使うべきか」「その投資に何を期待するのか」を考え直さざるを得なくなったのです。現在、私たちの成長予算のおよそ70%は認知向上に使われています。実際には、たとえば次のような取り組みです。 私たちは Golden State Warriors、Golden State Valkyries、そして Chase Center と複数年契約を結びました。 Syntax.fm は、自社でコーポレートポッドキャストを立ち上げる代わりに、2023年に Sentry の一部となりました。 毎年、ビルボード広告や OOH（屋外広告）にもかなりの予算を使っています。 ポッドキャスト、Reddit、YouTube、サードパーティニュースレター、インフルエンサーは、私たちにとって非常に大きなチャネルです。 この2年間で Open Source Pledge を通じて、オープンソースメンテナーに75万ドルを寄付しました。（それ以前にも継続して支援しています。） コアとなるビジネスモデルや、その他すべての施策も含めると、こうした投資は確実に成果を上げています。新規のアクティブユーザー数は指数関数的に成長しています。 こうしたタイプの投資は、開発者向けに製品を販売している企業としてはかなり珍しいものです。ただ、私たちも最初から大きな施策を打っていたわけではなく、もっと小さなところから始めました。ここまでで、私が学んだことを紹介します。 ソフトウェアの見つけられ方が変わっている もしプロダクトを作っているなら、すでに感じているかもしれません。人々がツールを見つけ、評価する方法は、いま大きく変わりつつあります。 以前は、かなり予測しやすい導線がありました。誰かが Google で問題を検索し、いくつかの検索結果をクリックし、比較記事を読み、トライアルに登録する。コンテンツを書き、広告を出し、SEO を行い、その流れの中で見つけてもらえれば、プロダクトは成長できました。 ですが、その流れは以前ほど信頼できるものではなくなっています。Google からのリファラルトラフィックは減少し、ゼロクリック検索は増加しています。Semrush の 2025年のデータによると、現在では Google 検索のおよそ60%が、どの […]
本番環境で大規模データセットをページネーションする：OFFSETの限界とカーソルの利点
Article by: Lazar Nikolov 、Ben Coe MVP（Minimum Viable Product）と本番環境に耐えるアプリアプリを分ける要素は、仕上げ、最終調整、そしてパレートの法則で言うところの「最後の20%」の作業です。多くのバグやエッジケース、パフォーマンス問題は、リリース後にユーザーの殺到でアプリケーションに大きな負荷がかかったときに表面化します。この記事を読んでいるあなたは、おそらく80%地点にいて、残りを片付ける準備ができているはずです。 この記事では、大規模データセットをスケール環境でページネーションする際に、どこで問題が起こり得るのか、そしてデータベースのインデックスが結果をどう左右するのかを見ていきます。 本番の洗礼（ローンチ後の現実） テスト中はすべて順調でしたが、しばらくするとページの読み込みに時間がかかるようになりました。 このような状況に備えて、Sentry をローンチ前にセットアップしておくことをおすすめします。カスタムのインストゥルメンテーションを何もしなくても、データベースクエリが遅くなったときに Sentry が知らせてくれます。 スクリーンショットには、Sentry での Slow DB Query の問題が表示されています。Drizzle ORM と node-postgres を使用したおかげで、Sentry は自動的にすべてのデータベースクエリを計測してくれました。このテレメトリデータによって、Sentry は遅いデータベースクエリを検出して表示できます。 少しスクロールすると、リクエスト情報が表示されます。 ここから分かることは次のとおりです。 クエリは GET /admin/tickets リクエスト内で実行されています。 OFFSET を含むため、オフセットベースのページネーションです。 実行されたのは 321 ページです。 実行時間は3.85秒でした。 Seer はインデックス不足の可能性が高いと推測しています。 では、実際にインデックスが不足しているのか確認しましょう。 Seer の言った通りでした！大規模なデータセット、データベースインデックスの不足、そしてオフセットベースのページネーションの組み合わせがこの問題を増幅させています。 データベースにインデックスがなく、かつページネーションがオフセットベースのため、今回のように321ページのような高いページ番号に移動すると、データベースは 321 × page_size 行 […]
10x チームの夜明け
Article by: Milin Desai 以前の記事では、人間であれ AI 搭載ツールであれ、デバッグはコンテキストに依存しているという話を書きました。コンテキストがなければ、どれだけ高性能なシステムでも「どのコードが壊れているか」までは教えてくれても、「なぜ壊れたのか」までは教えてくれません。 いまや AI は、開発者が頼りにしているのと同じレベルのコンテキスト（スタックトレース、トレース、ログ、コミット、コード）にアクセスできるようになりました。その結果、ソフトウェアの構築と運用のあり方が変わりつつあります。私たちは、単なるモニタリングの時代から「推論」の時代へと移行しつつあるのです。 「10x デベロッパー（10倍の成果を出す開発者）」という概念は、今でも議論の的です。本当にそんな人はいるのか？ 採用に力を注ぐだけの人数が存在するのか、それともユニコーン探しに過ぎないのか？ そして AI は、私たちの多くをその理想像に近づけることができるのでしょうか。 しかし、これらは本質的なポイントではありません。私たちの前にあるチャンスは、単発の「超人的な個人貢献者」を解き放つことではなく、AI の力で「10x チーム」を実現することにあります。 情報の「ふるい分け」から、共有される推論へ 何十年もの間、デバッグは「起きてから対応する」もの（リアクティブ）でした。何かが壊れると、1人のエンジニアが（後ろで足をトントンしながら待っている人に急かされつつ）ログやトレース、ダッシュボードに飛び込み、干し草の山から一本の針を探すように原因を追いかけていました。モニタリングツールは「何が起きたか」を教えてくれますし、それは当時も今も有用ですが、「なぜ起きたのか」を判断するのは常に人間の役割でした。 時間とともに、モニタリングツールも進化してきました（正直に言うと（少し自慢すると）、その進化には私たちも大きく関わっています）。いま開発者が求めているのは、生のエラーデータだけではなく、「どこで・いつ問題が発生し、誰に影響し、その原因となったコードの行はどこか」といったコンテキストに富んだインサイトです。「何かがおかしい」から、「ここがまさにおかしい」とスポットライトを当てて指し示せるようになったことが、デバッグにおける最初の大きな転換でした。データに意味を与え、壊れたコードを素早く修正するためのツールを開発者に提供したのです。 AI はこの転換をさらに大きく前進させています。Sentry の Seer のようなエージェントは、「何が起きたのか」を構成するあらゆる情報を取り込み、それをコードベースや最近の変更と突き合わせて、根拠のある形で根本原因分析を行います。つまり、「何が起きたのか」を踏まえて推論し、その原因（＝なぜそうなったのか）を自然言語で説明できるのです。しかも、それをインタラクティブに行うこともできます。 こうして、デバッグのプロセスそのものが変わります。これまでは、1人か2人の担当者がベストな仮説を立て、それをチケットなどを通じて組織全体へ共有する、という流れでした。いまはそれが「チームスポーツ」になりつつあります。チーム全員が、同じコンテキスト、同じ推論過程、同じ解決への道筋を共有できるようになっているのです。 人手による「情報のふるい分け」から AI による推論支援へと移行することは、単に個々の開発者を速くするだけではありません。「なぜそうなったのか」という答えをチーム全員で共有できるようにすることで、チーム全体を速くします。「10x エンジニア」のことばかり心配する必要はありません。これは「10x チーム」をつくるための、最初の、そして一見するとごくささやかな一歩なのです。 コンテキストは力を増幅する どのエンジニアリングチームも、コンテキストの断片化やデータ不足がもたらす影響を経験しているはずです。ひとつの大規模チームの中ですら、メンバー間の認識のずれは非常に大きくなり得ます。使っているツールも違えば、追いかけているダッシュボードも違い、DM でのサイド会話の内容も異なる。その結果、本番環境で何が起きているのかについて、メンバーごとにまったく異なるメンタルモデルが形成されてしまいます。 ひとつのコンテキストを共有できれば、フィードバックループは短くなり、重複した作業は減り、時間の経過とともに学習効果が蓄積されていきます。本番環境の問題のデバッグは、孤立した作業からチームで取り組むリズムへと変わり、各イテレーションのたびに、人と機械から成るシステム全体が少しずつ賢くなっていきます。 いまやコンピュータも同じように機能しています。Seer は Sentry […]
【Sentry】デザインを一新しました！
Article by: Jesse Box お気づきかもしれませんが、Sentry の見た目が大きくアップデートされました。 これまで、プロダクトの見た目は「いかにもエンタープライズ向け」という無難なデザインだった一方で、ブランドはずっと大胆で型破りでした。そのちぐはぐさは、もう終わりです！今日からは、皆さんが Sentry に期待するあの「ノリ」とプロダクトのデザインがきちんと噛み合うようになりました。より鮮やかで、より手触り感があって、より一層「Sentry らしい」見た目になっています。 ようこそ、S.C.R.A.P.S. 時代へ。これは Sentry の新しいデザイン言語で、正式名称は 「Standardized Collection of Reusable Assets & Patterns for Sentry（Sentry のための再利用可能なアセット＆パターンの標準コレクション）」 です。Sentry ならではの、ちょっと風変わりでクセになる魅力を、そのままプロダクトの中に流し込むためのデザイン体系なのです。 はじまりはこんなところから Sentry のプロダクトは、この数年で機能面では大きく成長してきましたが、見た目のほうは小さな改善の積み重ねにとどまっていました。「壊れていないものは直すな（Don’t fix what isn’t broken）」という考え方も、いつまでも通用するわけではありません。デザインは静かに古びていき、いったん世の中の期待値が変わってしまうと、かつては新鮮だったものも途端に古くさく感じられてしまいます。 一方で、ブランドのほうはどんどん先へ進んでいました。イラストはいい意味でどんどん「ヘン」になり、トーンはますます大胆に。それに対してプロダクトは、ずっと控えめなまま。両者の距離は少しずつ開いていきました。アプリはブランドの「少しトーンを落とした反響」であることが多いとはいえ、私たちの場合、そのギャップはもはや見過ごせないほど大きくなっていたのです。プロダクトが、もはや「Sentry らしく」感じられなくなっていました。 直近のマーケティングキャンペーンは「Make it make sense.」でした。 Sentry が初期に成功できた理由は、ほんの少しだけ他と違うことをしていたからです。誰も気にしないような部分にまで手をかけ、誰とも同じような「しゃべり方」をしないと決めていました。その最初のタグラインである「Sh*t Happens. Be on top of it.（トラブルは起きるもの。主導権はこちらが握る。）」が、その姿勢を物語っています。正直で人間味があって、ソフトウェアのカオスを前にしてもユーモアを忘れないトーンです。 その声は今も私たちを形づくっていますが、状況は変わりました。いまや「磨き上げられていること」は前提条件で、どのアプリも見た目はちゃんとしている。だから Sentry のデザインを刷新しようと決めたとき、私たちが目指したのは、よりツヤツヤした UI ではなく、「もう一度、自分たちらしさを取り戻すこと」でした。 […]
【Sentry Logs】ダイナミックサンプリング問題をデバッグ
Article by: Simon Hellmayr この四半期、Sentry のチームの一部は不具合の修正に注力し、正確には 800 件を超える問題を解決しました。その中には、社内の Sentry プロジェクトでトランザクションのスパイク（急増）を引き起こしていた複雑な不具合も含まれていましたが、Sentry Logs を用いて調査し、根本原因を追跡して問題を解決しました。 問題：断続的なスパイクと 100% のサンプル率 最初の症状は明確でした。特定の時間帯の始まりに、社内のプロジェクトが大量のスパンであふれ、プロジェクトの「abuse layer（異常負荷防止層）」が Sentry プロジェクトから膨大なデータをランダムに破棄していました。ただし、すべての時間帯で発生するわけではなく、数日間連続で発生しないこともありました 調査の結果、ダイナミックサンプリング設定が「すべてをサンプリングする」ルールに上書きされていることがすぐに判明しました。つまり、{“type”: “sampleRate”, “value”: 1.0} という設定です。 この設定の目的は、どのプロジェクトやトランザクションをどの割合で保存するかを指定することです。そして、その値が 1.0 の場合、すべてをサンプリングすることを意味します。Sentry の目標サンプリング率は 2% であるため、突如として 50 倍のトラフィックを受け取る事態は冗談では済みません。 しかし、なぜこのようなことが起きていたのでしょうか？ 最初の仮説は、ルール生成ロジックがフォールバックケース（代替処理）に入ってしまっているというものでした。これを確認するためには、より多くの可視性が必要でした。まず最初のステップとして、問題の設定状況を把握するために、コードに詳細なログ出力を追加し、動作を記録するようにしました。 調査に Logs を活用する まずは設定の JSON をそのままログに出力しましたが、この設定は非常に大きくなることがあり、GCP Logs が受け付けるサイズを超える場合があると分かりました。一方で Sentry Logs は JSON を自動的に切り詰め、重要な情報を直接得られるようにしてくれました。 ログのペイロードを縮小し、意味の明確化も図って迅速に改善した結果、必要なデータを取得できるようになりました。次に問題が再発した際には、すぐにSentry […]
【Flask × React】実装するチェックアウトフローの監視とデバッグ
Article by: Will McMullen チェックアウトフローが壊れると、顧客は「最先端」のJSメタフレームワークが廃れるよりも早く離れていきます。幸い、Sentry を使えば、顧客のチェックアウトのようなクリティカルパスにオブザーバビリティを設定するのは簡単です。ここでは、私たちがどのようにインスツルメントし、監視し、大きな問題を最小限の労力で修正したのかを順を追って紹介します。 チェックアウトフローのインスツルメント まず、ユーザーがチェックアウトプロセスとどのようにやり取りしているかを正確に追跡したいと考えました。Sentry の Distributed Tracing を使って監視ダッシュボードを設定するのは簡単でした。フロントエンドとバックエンドのアプリケーション（今回の場合は app.py と App.tsx のトップレベルファイル）でトレーシングを有効化し、/api/ エンドポイントを tracePropagationTargets に追加して Distributed Tracing をセットアップするだけで完了です。 これで、Flask と React の両方にわたって、パフォーマンスメトリクス、エラー、トレーシングデータを取得できるようになりました。 ユーザージャーニーの監視 Sentry にデータが集まるようになると、eコマースストアフロントで最も重要な要素であるチェックアウトフローを監視するためのダッシュボードを立ち上げるのは非常に簡単でした。 ここに到達するために、私たちはいくつかの主要な属性で Span データ を拡張しました。これらは Sentry で Span Metrics として可視化・監視できます。誰かが Cart.jsx コンポーネントを使うたびに、Sentry SDK でのインスツルメンテーションによって「カートに追加されたアイテム数」をそのアクティブな Span に付与し、その数を追跡できるようにしました。 実際のところ、次のような形になります。 まず、Sentry.startSpan() でスパンを作成し、次に checkoutspan.setAttribute を使って items_at_checkout を属性として追加します。ここにデバッグやパターン分析のために顧客データなど他の有用な情報を付与することも簡単にできますが、ここではシンプルに留めることにしました。 […]
Sentry ハックウィークの舞台裏 壊すための口実
Article by: Hector Dearman, Nico Hinderling, Nelson Osacky Sentry ハックウィーク（社内開発週間）では、多くの「Sentaurs（Sentryのメンバー）」が、今後何年にもわたって価値をもたらす Sentry サービスの有用な拡張機能の構築にこの機会を活用しました。 しかし、私たちは違いました。 私たちは、混乱を引き起こし、クラッシュを誘発し、バグをあぶり出す機会として、初めて参加する Sentry ハックウィーク を利用しました。もっともらしさを最大化するために、プロジェクトの説明は「SaaS アプリケーション向けの LLM 主導型 Web ファジング」とし、愛称は「Gremlins（グレムリン）🧌」と名づけました。 Gremlins は、予測不能なユーザー操作を実行することでバグを発見するよう設計された、AI 駆動のファジングエージェントです。従来型のファジングが苦戦するのは、現代のアプリケーションがフロントエンド、バックエンド、データベース、補助的なサービスなど複数のコンポーネントにまたがっているためです。入力は単一のデータバッファではなく、ユーザー操作のシーケンスになっています。 Gremlins はこれを、Web エージェントを通じて意図的に混沌を作り出し、Sentry の SDK を活用してエラーを検出し、プロファイリング／トレーシングデータを収集し、セッションリプレイを取得して、何が明らかになったかを確認することで解決します。 グレムリンが見つけられるものは、実際のユーザーも同様に遭遇し得ます。 Gremlin ワークフロー 大まかには、Gremlins はシンプルな手順に従います。 ユーザーが対象サイトを設定し、必要に応じてエージェント設定を追加する エージェント（群）をサイトに放つ Gremlins があぶり出したエラーを Sentry が捕捉する 設定は軽量で、ユーザーは次の項目を指定できます。 対象サイト 任意のテスト指示（例：「設定ページを壊してみて」） 認証情報 Gremlins の数 など […]
エラーメッセージを（偶然）営業マシンに変えてしまった
Article by: Dan Mindru Dan Mindru はフロントエンド開発者／デザイナーであり、Morning Maker Show の共同ホストでもあります。現在、PageUI、Clobbr、CronTool など複数のアプリケーションを開発中です。 毎日のように多くの AI スタートアップが生まれているのは、実に驚くべきことだと感じています。 私たちソフトウェアエンジニアの多くは、自らのソフトウェアが実際に何をしているのかを知りたがります。計画を立て、レビューを行い、自動テストを実施して、想定どおりに動作しているかを検証します。さらに念のため、手動テストも一巡行います。ただし、AIは例外です。 何か月も何か月もテストを重ねた末、私は落ち着かない状況に置かれることになりました。私のプロダクトは概ね正常に動作していたものの、タスクの遂行に完全に失敗することがあったのです。 実際、約90％の確率では正しく動作しました。しかし、成功率を0％から80％に到達するまでに1か月、80％から90％、あでは 3か月、そして90％から100％にするには、少なくとも12か月はかかりそうに思えました。 現在のスピード感では、「AIの時間」における12か月は、通常の時間でいうところのほぼ1世紀に相当します。ですから、毎日のように新たなスタートアップが登場する理由がすぐに理解できたのです。 結局のところ、皆すぐにローンチするのです 🤷♂️ その後、私たちは12,000人のユーザーを獲得しました。ここから、それがどのように私に有利に働いたのかを説明していきます。あわせて、最大の問題が何だったのかについてもお話ししますが、おそらく想像もつかないはずです。 どのように始まったのか 私はウェブサイト制作を変革するスタートアップを立ち上げたいと考えました。PageAI は、シンプルな説明文から本番運用レベルの Web サイトを、計画・デザイン・コーディングまで行うことができるビルダーです。聞こえは非常に壮大ですが、エラーもそれに匹敵するほど壮大でした。 予想どおり、うまくいかないこと（実際に起きたこと）も数多くありました。どのように壊れるか、すべてを把握していたわけではありませんが、少なくとも AI の出力を完全には信用できないことは分かっていました。これはセキュリティだけでなく、デザインやコード品質の観点からも同様です。 そのため、失敗を受け入れた上で、適切に対処できるようにする必要がありました。 ここで直面したのが、古典的な「鶏が先か卵が先か」の問題です。多くの人に使ってもらわない限り、どのような失敗が起こるかは明らかになりません。一方で、自分たちだけでそれを洗い出そうとすれば、資金が尽き、時代遅れのプロダクトをリリースする危険があります（ちなみに PageAI は自己資金で運営していたため、QA のスケールにも厳しい制限がありました）。 そこで、他の多くのスタートアップと同様に、私たちもローンチすることにしました。 とはいえ、私もそこまで奇抜ではありません。ローンチ前に、AI のエラーを囲い込み、可能な限り緩和しようとしました。私たちが実際に行ったことは以下のとおりです。 自前のパーサーを実装し、生成されたコードを解析したうえで「再構築」し、怪しい／危険な出力をすべてスキップ 出力を保護するために、プロンプト、チェック、エージェントフローを強化 クラッシュを防ぐために、フロントエンドで追加の処理とサンドボックス化を実装 ローンチはあらゆる指標でうまくいき、最初の1週間で2,000人のユーザーを獲得しました。 ところが、その後は静まり返っていました。誰からもクレームがないのです。何かがおかしい… 少なくとも10人に1人は問題に直面すると思っていたのに。これが最初の問題でした。 ❌ 問題1：どれほど深刻かが見えていなかった エラーが発生していることは把握できていましたが、ユーザーがわざわざその問題を報告してくれることはほとんどありませんでした。試してみてエラーが出たら、黙って競合サービスに移ってしまう。良くない状況です。 ✅ […]