メルカリのエンジニアリングブログが、AI対話でブランディングページ（LP）を作る社内エディタ「EGP Code」の内部を支える4つの仕組みを、コード付きで公開した。
メルカリのエンジニアリングブログが2026年6月10日、AIと対話してブランディングページ（LP）を作る社内エディタ「EGP Code」を支える4つの仕組みを公開した。「Merpay & Mercoin Tech Openness Month 2026」連載の7日目にあたる。
4つの仕組みは、エージェントの再帰ループ、Firestore経由のリアルタイム反映、ブラウザだけで完結するテスト実行、プレビューとHTMLを結ぶ対応表である。最も実務に効くのが履歴管理の変更だ。OpenAI APIで全社的にデータ非保持（Zero Data Retention）が適用され、ベンダー側に会話履歴を残せなくなったため、履歴を自前で記録し毎回のリクエストに載せて送るステートレス方式へ移行した。
また、ツール実行が失敗してもループを止めず、エラー内容を結果として返して自己修正させる設計や、処理中に指示を足せる「リアルタイムステアリング」をFirestoreの別サブコレクションへリクエストID付きで書き込む実装も開示された。同じ制約に直面する企業が設計を流用できる先行事例となっている。
この変化で何が要点か。図解と出典つきで一目で。
構造化された事実を最初に。誰が何をいつどこでなぜどのように。
EGP Codeは、HTMLと状態を持つ少数の独自部品（独自Webコンポーネント）を混ぜた1枚のページを扱い、AIエージェントとの対話でLPを編集・公開できるエディタである。作成背景は別記事『AIと作るHTMLベースのLPエディタ EGP Codeを内製した理由』で紹介済みだ。本記事ではその内部で動く具体的な4つの仕組みを取り上げる。4つの仕組みとは、(1)エージェントの再帰ループ、(2)Firestoreを介したリアルタイム反映、(3)ブラウザだけで完結するテスト実行、(4)プレビューとHTMLを結ぶ対応表である。
AIエージェントを実プロダクトに組み込む際の実装課題（履歴管理、処理中の指示変更、ツール失敗時の自己修正）への具体的な解決策を、コード付きで開示している点が実務者に有用だ。とくにOpenAI APIで全社的にZero Data Retention（データ非保持）が適用され、ベンダー側に会話履歴を残せなくなったため、自前で履歴を記録し毎回のリクエストに載せて送るステートレス方式へ移行した経緯は、同様の制約に直面する企業の参考になる。処理の途中で方針を変えられる「リアルタイムステアリング（処理中の割り込み指示）」の設計も実用的な知見である。
メルペイのフロントエンドエンジニア @mattsuu が2026年6月10日、AIと対話してブランディングページ（LP）を作る社内エディタ「EGP Code」を支える4つの仕組みを公開した。社内の技術啓発企画「Merpay & Mercoin Tech Openness Month 2026」連載の7日目にあたる記事だ。
EGP Codeは、HTMLと状態を持つ少数の独自Webコンポーネントを混ぜた1枚のページを扱い、AIエージェントとの対話でLPを編集・公開できる。今回開示されたのは、(1)エージェントの再帰ループ、(2)Firestore（Googleのリアルタイムデータベース）を介した編集結果の即時反映、(3)ブラウザだけで完結するテスト実行、(4)プレビューと元のHTMLを結ぶ対応表、の4点である。
この記事は「Merpay & Mercoin Tech Openness Month 2026」の7日目の記事です。
エディタを作った背景は別記事『AI と作る HTML ベースの LP エディタ EGP Code を内製した理由』で先に紹介済みで、今回はその内部で実際に動く仕組みに踏み込んでいる。
4つの仕組みのうち実務者に最も効くのが、会話履歴の扱いを変えた経緯だ。OpenAI APIで全社的にデータ非保持（Zero Data Retention＝ベンダー側に会話履歴を残さない設定）が適用され、これまで頼れた「ベンダー側に残る会話履歴」が使えなくなった。
全社的に OpenAI API の ZDR（Zero Data Retention）が適用され、ベンダー側に会話履歴が残せなくなった
そこでEGP Codeは、会話履歴を自前で記録し、毎回のリクエストにすべて載せて送るステートレス方式へ移行した。サーバー側がセッションの状態を覚えておくのではなく、必要な文脈を毎回まるごと送り直す形だ。
この制約は同じくOpenAI APIをデータ非保持設定で使う企業に共通する。ベンダー側の履歴保持に依存していた実装は、自前で履歴を持ち直す改修が前提になる点を、本記事は先行事例として示している。
エージェントの再帰ループでは、ツール実行が失敗したときの扱いが設計のポイントになっている。EGP Codeは、ツール実行が失敗してもループを止めず、エラーの内容を実行結果として返してエージェント自身に自己修正させる。
失敗を例外として処理を中断するのではなく、「こういうエラーが出た」という事実をAIへの入力として戻すことで、AIが次の手を考え直す。これにより、人が介入しなくても処理が続き、自走しやすくなる。
もう一つの実用的な知見が「リアルタイムステアリング」（処理中の割り込み指示）だ。処理の途中でユーザーが指示を足したいとき、割り込みメッセージをFirestoreの別サブコレクションにリクエストID付きで書き込み、該当するエージェントだけがそれを読み取る。これにより、長い処理の途中でも方針を変えられる。
落とし穴として、ステートレス方式は会話が長くなるほど毎回送る履歴が膨らむ点に注意がいる。履歴の保持と送信の設計が、コストとレイテンシに直結する。
立場別、明日から動ける一手。
自社のOpenAI API利用でデータ非保持が適用されているか、適用時に会話継続をどう成立させるかを確認する。
ツール実行が失敗したときループを止めずエラー内容を結果として返し自己修正させる再帰ループの挙動を試す。
OpenAI APIで会話履歴がベンダー側に残せなくなったことに合わせ、履歴を自前で持ち毎回送るステートレス方式へ移行したという実装の経緯に、同じ制約に当たる実装者の関心が向いている。ツール実行が失敗してもループを止めず自己修正させる設計や、処理中に指示を足せる『リアルタイムステアリング』をFirestoreのサブコレクションとリクエストIDで実現した点が、コード付きで読める実務知見として受け止められている。
※トレンド検出時刻付近の人気投稿を表示
