一発で決めようとするな — Granola Product Engineer が語る LLM 機能の本番フィードバックループ

AI Engineer Code Summit (NYC) 2026/05/10

Mehedi Hassan / メヘディ・ハッサン · 08:30 「答えは『より良く one-shot すること』ではない — LLM とテニスのラリーをするようなフィードバックループをどう作るか、や。そうすれば最終プロダクトがブラックボックスじゃなく、マジックのように感じられる」

AI Engineer Code Summit (NYC、 2026/05 開催) のテクニカルトーク。約 9 分。登壇者は Granola の Product Engineer Mehedi Hassan

9 分の超短セッションだが、内容は Karpathy、 Schluntz、 Boris Cherny の vibe coding 三部作を、本番運用しているスタートアップの現場視点から補強する記事内容。 Mehedi は「jQuery がクールだった頃からコーディングしてる」ベテラン Web 開発者、 React と LLM の 2 つの大きな変化を実装現場で経験した立場から、「AI 機能を本番で動かすために何が要るか」を 9 分で語り抜く。

Granola は 2024 年に Chris Pedregal (元 Google PM) と Sam Stephenson が London で創業した AI 会議メモアプリ。「Dock に居座って、ユーザーがメモを書きながら、 AI が裏でシステム音声 + マイク音声を録音して、会議終了時にサマリーを生成する」という独特の UX。 2024 年 10 月に $20M、 2026 年 3 月に $125M ラウンド ($1.5B valuation) で「会議メモアプリから企業 AI アプリ」へ拡張中の急成長スタートアップ。 Mehedi はその Product Engineer として、 LLM 機能を毎日本番で運用している現場の人。

動画のメッセージは一言で要約できる: 「You can't just one shot it (一発じゃ決められへん)」。 LLM の世界では、 1 行のコードで API を呼んで魔法のような機能が完成すると思いがちやが、本番運用するとそれは幻想だと分かる。では何が必要か。 Mehedi の答え: 「LLM とテニスのラリーをするようなフィードバックループ」を構築すること。具体的には 2 つの実装事例 — (1) 社内独自トレーシングツール、 (2) Electron アプリの Web Shell 化 — を 9 分で示す。

MEMEX 編集視点で重要なのは、これが vibe coding 三部作の「現場の Product Engineer 翻訳」であること:

Karpathy の「verifiability is the new bottleneck」 → Mehedi の「内製トレーシングツールで agent loop 全段を見える化」として実装
Schluntz の「Claude PM になれ」 → Mehedi の「LLM とのテニスラリー型フィードバックループ」として実装
Boris Cherny の「Anthropic で書かれるコードの 80% を Claude Code が書く」 → Mehedi の「Cursor が PR をテストしてスクリーンショットをアップロードする」として実装

理論 (Karpathy)、組織内側 (Boris)、本番運用ベストプラクティス (Schluntz) に続いて、「実際にプロダクトを毎日出荷してる現場エンジニアの戦術」として、 Mehedi のセッションが業界の景色に最後のピースを足す位置にある。

着眼点

「Web Search ツールを 1 行追加」が本番で壊れる構造 (02:00 - 03:30)

Mehedi の最初の具体例。 Anthropic / OpenAI が公式 SDK で提供する「Web Search ツール」は、一見 1 行のコードで追加できる。「Just add the web search tool and you expect it to just work. That's what the labs want you to believe」 (02:30) — ラボはそう信じてほしいが、実態は違う。

本番で発生する 3 つの問題:

トークンコストの爆発: 複雑なクエリでコンテキストが膨れ上がる、「1 チャットで 10 ペンス」になることも。数百万ユーザー規模では成立しない
プロバイダ依存の脆さ: 「ある日突然モデルがアップデートされて、 Web Search の品質が劣化した。我々のコントロール外」 (03:00)。ラボ側のアップデートで UX が突然壊れる
競合の桁違い: 「Web Search はビリオンドルカンパニーが本業でやってる。 LLM パイプラインに 1 行追加するだけでは到底届かない」 (03:25)

この観察は、単に Granola の苦労話ではなく、「LLM API を統合するだけでは差別化できない」という構造的論点。ラボの SDK は 80% の仕事をしてくれるが、残り 20% が本番品質の壁という、業界が広く感じてる現実を簡潔に言語化してる。

「1 つのプロンプトが全員のニーズに対応できない」 — 出力スタイルの問題 (03:30 - 04:30)

2 つ目の問題は出力。 Granola の会議サマリー機能で、 Mehedi が引く具体例:

セールス担当 → デュアルフォーカス (相手企業 + 自社観点) の要約が欲しい
エンジニア → アクションアイテム、ブロッカー、 Linear チケット候補
HR → 全く別のフォーマット

「1 つのプロンプトでは普通、全員に対応できない。そして LLM は頑固 (stubborn)。中身を覗いて、望む動作をさせる方法を見つけなあかん」 (04:10)。「LLM behavior is largely seen as a black box, but we want to go very deep into the details」 (04:25) — ブラックボックスを覗き込む覚悟を Product Engineer に要求する。

この観察は Amanda Askell の Claude のキャラクター設計と裏返しの関係。 Amanda は「モデルの中に良いキャラクターを焼き込む」側、 Mehedi は「焼き込まれたキャラクターを使うプロダクト側から、微調整できる余地を探す」側。同じブラックボックスを、訓練者と統合者の両側から見る視点。

独自トレーシングツール — 「one-shot していい場面」 (04:30 - 06:00)

Mehedi の解決策その 1。「LLMs に感謝、こういうものは実は one-shot できる。これが one-shot がいい場面」 (04:45)。自社専用のトレーシングツールを内製した。

機能要件:

ツールコールの可視性 — 最初から最後まで完全に追跡
個別ツールコール、検索トレイル、推論トレイル、コスト
データ構造を「我々が望む通り」に設計
UI は エンジニアだけでなく、プロダクト・データ・CX (Customer Experience) 担当も使える形に

「以前ならこういうツールは SaaS プロバイダ任せで、自前で作る時間なんてなかった。でも今は実際に、自社のニーズに合わせたトレーシングツールを作る時間が取れる」 (05:30) — LLM 時代のソフトウェア構築コストの低下が、内製ツールの経済合理性を変えた、という構造的観察。「Raindrop のような SaaS を使う」という選択肢があるなかで、 Granola は内製を選んだ理由がここに集約される。

決定的な具体例: 「我々の創業者本人が、 agent loop を front から back まで完全にトレースして、何が壊れたか特定する」 (05:50)。 CEO が API トレースを見るためのツールという設計目標。これは Boris Cherny の Anthropic 内「テクニカルスタッフメンバー」文化と並べると見える — 「肩書きに関係なく、全員が技術の中身を見る」という組織哲学が、 LLM 時代の新しい標準になりつつある。

Electron アプリの Web Shell 化 — 並列テストの問題を物理的に解く (06:00 - 08:15)

Mehedi の解決策その 2。ここが技術的に最も興味深い部分。

問題: Granola は Electron 製のデスクトップアプリ。デスクトップアプリは「同時に 1 つのインスタンスしか走らせられない」という構造的制約がある。機能フラグで A/B/C/D の 4 つのバリアントを並列テストしたい時、 Web アプリなら別タブで同時起動できる。でも Electron アプリは 1 つ。

テスト摩擦の具体例: 「同僚に新機能をテストしてもらうには、 Electron アプリをローカルに走らせて、依存関係をインストールして、やってもらう必要がある。 Web アプリのような贅沢はない」 (06:30)。

解決策: Electron アプリのフロントエンドを Web Shell 化してオンラインデプロイ。 CI で PR ごとにプレビューリンクが生成される。「これで開発速度が劇的に上がった」 (07:15)。

技術的実装の詳細 (07:30 - 08:15):

Electron は Main process (システム API) と Renderer process (フロントエンド) の 2 プロセス構成
IPC API (Inter-Process Communication) を抽象化し、 Web 環境では Web 標準にフォールバックする層を作った
React の API (router、 session、 query layer) も Web 標準に置き換え可能な設計に
結果として Renderer process が Electron に依存しなくなり、そのまま Web アプリとして走る

これが最も素晴らしい部分: 「Cursor が PR を自動でテストして、スクリーンショットを PR にアップロードする」 (07:30)。 AI コーディングエージェントが Web プレビューを使って自分でテストできる、という構造。これは Karpathy の「verifiability」概念が、 Granola 内部で物理的に実装されている姿。 verifiability の bottleneck を、「AI が自分でテストする」ことで解消する具体例。

「テニスのラリー」という比喩 — フィードバックループの本質 (08:15 - 09:00)

Mehedi の結論部分。「答えは one-shot をより良くすることではない。 LLM とテニスのラリーをするようなフィードバックループをどう作るか、や。そうすれば最終プロダクトがブラックボックスじゃなく、マジックのように感じられる」 (08:25)。

テニスラリーの比喩が秀逸: 一発で決めようとせず、何度も打ち返し合いながら最終的に決まる、という構造。これは Schluntz の「Claude PM」概念や Karpathy の「人間が検証する」ワークフローと完全に同じ。

しかも、「magic vs black box」の対比が決定的: 内部を見える化することで、ユーザーには魔法のように感じる UX が実現できる。「ブラックボックスを覗き込まないで魔法を期待する」のはエンジニアリングの放棄、「ブラックボックスを覗き込んだ上で魔法を作る」のがフィードバックループ設計、という整理。 LLM プロダクトを構築するエンジニアへの倫理的・実装的指針として、 9 分で結晶化された。

Q&A: Tauri への移行検討 (09:18 - 09:47)

質疑応答で 1 つ。「Electron から Tauri への replatform を検討してる?」と聞かれて、 Mehedi の答え: 「何度か検討した。でも Electron は今のところよく機能してくれてる。 API が頻繁に変わってる。 Tauri も試したけど、性能面で劇的な改善は見えなかった。我々が最も気にする点」 (09:20 - 09:40)。

この実用主義的判断が面白い。「最新技術スタックに飛びつかない」という Granola のエンジニアリング文化。投資家を惹きつける $125M ラウンドの裏で、内部は地に足のついた判断をしてる、という構造が見える。

業界文脈

Granola は 2024 年創業、 London 拠点。 CEO Chris Pedregal は元 Google PM で、 Socratic (AI 家庭教師アプリ) の創業者。共同創業者 Sam Stephenson は Ideaflow 出身。 2 人とも「会議メモを AI で生成する」という単純な発想からスタートしたが、アプリの UX 設計 (Dock 常駐、ユーザーが手書きメモを書く一方で AI が裏で記録、という独特の組み合わせ) で投資家を惹きつけた。

資金調達履歴:

2024 年中頃: TechCrunch でローンチ報道
2024/10: $20M ラウンド — 「VC がこのプロダクトを使ってるから $20M 投資した」と TechCrunch がからかった見出し
2026/03: $125M ラウンド、 valuation $1.5B — エンタープライズ AI アプリへの拡張を宣言

AI Engineer Code Summit (NYC、 2026/05) は AI Engineer 系列の最新イベント。 AI Engineer Europe 2026 (Amsterdam、 2026/04) と並ぶ、業界実装者向けの主要カンファレンス。 Mehedi のセッションは 9 分の最短セッションの 1 つだが、「Product Engineer 視点」という、他のセッション (CTO/CEO レベル) と異なる現場目線が貴重。

Granola の選択肢 (内製トレーシング、 Electron Web Shell 化、 Tauri 検討) は、 LLM 時代のスタートアップ実装の典型的論点。 SaaS で済ます (=外注) vs 内製、既存スタック維持 vs 新スタック挑戦、 LLM API 直叩き vs ラッパー、という判断軸を、 Mehedi が現場目線で簡潔に示してる。「$1.5B valuation スタートアップ内部の Product Engineer がどう判断してるか」が分かる稀少な資料。

関連動画との位置づけ

Mehedi のセッションは、 MEMEX で扱う「vibe coding 系列」の本番運用視点での補強。業界の景色を 4 階層で並べると:

概念層: Karpathy AI Ascent 2026 — Software 3.0、 verifiability の bottleneck、「ジャギーな知能」
組織内側層: Boris Cherny (Anthropic) — Claude Code の 80%、「印刷機の比喩」、 1 行も手で書かない
運用ベストプラクティス層: Schluntz (Anthropic) — Claude PM 概念、葉ノード戦略、 22,000 行 PR
本回 = 現場 Product Engineer 層: Mehedi Hassan (Granola) — 「one-shot するな、テニスラリーしろ」、内製トレーシング、 Electron Web Shell 化

4 つを並べると、業界が「LLM の能力に依存するだけでは本番品質に到達しない」という共通認識を、 4 つの異なる視点で別々に到達してる構図が見える。概念 (Karpathy)、ラボの組織哲学 (Boris)、推奨パターン (Schluntz)、そして顧客に出荷してる現場の戦術 (Mehedi) という 4 段階の階層化。

同じ AI Engineer 系列の関連記事:

Agent Observability — Raindrop — 同じトレーシング問題を SaaS 側から解いた人々。 Granola が内製を選んだ判断と対比できる
Vibe Engineering Effect Apps — Michael Arnaldi が Effect で同じ抽象化問題を扱う
Playground in Prod — Samuel Colvin / Pydantic — 本番でエージェントを最適化するもう 1 つの視点

実装上の含意

LLM プロダクトを本番運用してる技術者にとって、 Mehedi の 9 分から取り出せる戦術:

第一に、 「Web Search ツール 1 行追加」の罠を理解する。 LLM ラボの SDK が提供する組み込みツール (Web Search、 Code Interpreter、 File Search 等) は便利だが、 (a) トークンコストが予測しにくい、 (b) ラボ側アップデートで品質が変動する、 (c) ビリオンドル規模の競合 (Google Search、 Bing) と機能比較される、という構造的限界を持つ。自社プロダクトのコア機能をラボの組み込みツールに依存させる前に、これらのリスクを評価する。

第二に、 内製トレーシングツールの経済合理性を再評価する。 LLM 時代のソフトウェア構築コストが下がった結果、「以前は SaaS でやるしかなかったもの」が内製できるようになった。特に、自社プロダクト特有のデータ構造で、エンジニア以外 (PM、データ、 CX) も使うツールは内製が報われる。 LangSmith、 Helicone、 Arize、 Phoenix などの SaaS は素晴らしいが、「自社で 1-2 週で構築できる」という選択肢が常にある。

第三に、 「LLM のブラックボックスを覗き込む」ことを Product Engineer の必須能力とする。 Mehedi の発言「LLM behavior is largely seen as a black box, but we want to go very deep into the details」は、採用基準や評価指標にも適用できる。「LLM API を呼んで結果を表示する」だけのエンジニアではなく、「LLM のツールコールを追跡し、推論トレイルを読み、失敗を診断する」エンジニアを育てる組織設計。

第四に、 並列テスト可能性をプロダクト設計の制約として考慮する。 Granola が Electron Web Shell 化に踏み切ったのは、「機能フラグの A/B/C/D 並列テストができないと、 LLM 機能の改善速度が落ちる」という認識から。自社プロダクトのテクノロジー選択 (Electron / Tauri / native / web) を、「LLM 機能の高速反復が可能か」という軸で再評価する。

第五に、 AI コーディングエージェントを QA に組み込む。「Cursor が PR をテストしてスクリーンショットをアップロード」という Mehedi の実装は、 verifiability の bottleneck を別の角度から解消する。 Claude Code の Hooks や同等の機構を使って、 PR ごとの自動テスト → スクリーンショット添付、を自社で構築できる。

批評的な視点

9 分の濃縮セッションだが、留保もある。

第一に、 「Web Search を内製」の代替案が示されない。 Mehedi はラボの組み込み Web Search の限界を指摘するが、 Granola が実際に何を使ってるかは明かさない (SerpAPI、 Tavily、独自スクレイピング、等)。「ビリオンドル企業がやってる」という観察と「我々の選択肢」の間にギャップがある。これは 9 分という制約の問題でもあるが、実装者にとって最も知りたい部分が抜け落ちる。

第二に、 独自トレーシングツールのオープンソース化や共有がない。「セッションスタイルでオープン」してる Anthropic (Claude Code チームが多くを OSS) と対比すると、 Granola の内製ツールは社内資産として閉じてる。これは商業判断として理解できるが、業界全体の生産性を上げるエコシステム的視点からは惜しい。

第三に、 「テニスラリー」の比喩が抽象的。「ラリーを成立させる具体的なフィードバック loop の構造」 — どこで人間が介入し、どこで自動化するか、どんな指標で iteration を進めるか — の詳細が示されない。これも 9 分の制約だが、もう少し具体例が欲しい。「我々は ____ 指標を見て、 ____ を変更し、 ____ 回 iterate して機能を出荷した」という具体例があれば、もっと実用的だった。

第四に、 「Cursor が PR をテストしてスクリーンショット」の具体実装が示されない。これは最もエキサイティングなパートだが、「どう設定するか」「失敗時にどう扱うか」「コストはいくらか」が省略される。 Cursor の GitHub Integration を使ってるか、自前で動かしてるか、不明。

これらの留保はあるが、 9 分の制約で「LLM 機能を本番出荷する Product Engineer の戦術」を凝縮した内容として、業界の若手・中堅エンジニアにとって「上司に共有する 9 分」の価値が高い。

読者へのテイクアウェイ

LLM 機能を「1 行で済む」と過小評価しない。ラボの SDK が提供するツール (Web Search、 Code Interpreter 等) は 80% 動く、残り 20% を本番品質に持っていくのが Product Engineer の仕事
「LLM はブラックボックス」と諦めず、内部のツールコール・推論トレイルを覗き込む観測性を持つ。 SaaS (LangSmith、 Helicone、 Arize) を使うか、内製するかの判断軸を「エンジニア以外も使えるか」「自社特有のデータ構造か」で持つ
1 つのプロンプトで全員を満足させようとしない。ロール別 (セールス / エンジニア / HR 等) の出力スタイルを分岐させる設計を最初から考える
「LLM とテニスラリー」を内部の合言葉にする。一発で決めるのではなく、多数のバリアントを高速にテストして決める文化
並列テスト可能性をプロダクト技術選択の評価軸にする。 Electron / Tauri / native / web — どれを選ぶかで LLM 機能の反復速度が変わる
AI コーディングエージェント (Cursor、 Claude Code 等) を QA パイプラインに組み込む。 PR テスト + スクリーンショット添付の自動化が、 verifiability の bottleneck を実用的に解消する
「最新スタックに飛びつかない」という実用主義を保つ。 Granola は $1.5B valuation でも Electron を維持してる、「使えるものを使う」の重要性

動画の構成

(00:00) 自己紹介 — Mehedi、 Granola の Product Engineer、 jQuery 時代からのコーダー
(00:46) Granola の紹介 — Dock 常駐、システム音声 + マイク音声、リアルタイム文字起こし、ユーザーがメモを書ける
(01:20) ライブデモ — 前のセッションを録音して、サマリーを生成
(01:51) 「AI 機能を本番に入れたとき何が起きるか」 — Granola のチャット機能を例に
(02:30) Web Search の落とし穴 — ラボは「1 行で済む」と言う
(02:50) トークンコスト、プロバイダ依存、ビリオンドル競合
(03:30) 出力スタイル — ロール別 (セールス / エンジニア / HR) の差
(04:15) 「LLM は頑固、ブラックボックスを覗き込め」
(04:30) Granola の独自トレーシングツール — one-shot していい場面
(04:45) 機能要件 — ツールコール可視性、検索トレイル、推論トレイル、コスト
(05:11) UI は全社員 (エンジニア / PM / データ / CX) が使える設計
(05:30) SaaS から内製へ — 「以前はやる時間がなかったが今は作れる」
(05:50) 創業者本人が agent loop を front から back までトレースする
(06:00) Granola の Electron 問題 — 並列テストが困難
(06:30) 同僚にテストしてもらう摩擦 — 「Electron をローカル走らせて依存関係インストール」
(07:00) 解決策 — Electron アプリのフロントを Web Shell 化
(07:30) Cursor が PR を自動テストしてスクリーンショットを上げる
(07:45) 技術詳細 — Main process と Renderer process の構成
(08:00) IPC API を抽象化、 Web 標準にフォールバック
(08:15) Renderer process が Electron 非依存に
(08:25) 結論 — 「one-shot するな、テニスラリーしろ」
(09:00) 「フィードバックループでマジックを作る、ブラックボックスじゃなく」
(09:08) 質疑応答開始
(09:18) Q: Tauri 移行検討は? — A: 検討したが、 API 安定性と性能で Electron 継続
(09:47) 締め

重要な引用

「I've been coding since jQuery was cool. I've seen React change frontend engineering, and now experiencing LLMs change engineering and everything else」 (Mehedi、 00:30、自己紹介)
「Web search で『1 行のコードを追加して動く』はラボがそう信じてほしいだけ。実態は違う」 (Mehedi、 02:30)
「ある日突然モデルがアップデートされて、 Web Search の品質が劣化した。我々のコントロール外」 (Mehedi、 03:00)
「Web Search はビリオンドル企業が本業でやってる、 LLM パイプラインに 1 行追加するだけでは到底届かない」 (Mehedi、 03:25)
「1 つのプロンプトでは全員に対応できない。 LLM は頑固」 (Mehedi、 04:00、出力スタイル問題)
「LLM の振る舞いはブラックボックスと見なされがちだが、我々は中まで深く入る」 (Mehedi、 04:25)
「LLMs に感謝、こういうツールは実は one-shot できる。これが one-shot がいい場面」 (Mehedi、 04:45、独自トレーシング)
「UI はエンジニアだけでなく、プロダクト・データ・CX 担当も使える形に」 (Mehedi、 05:11)
「以前ならこういうツールは SaaS プロバイダ任せで、自前で作る時間なんてなかった。でも今は作れる」 (Mehedi、 05:30)
「我々の創業者本人が agent loop を front から back まで完全にトレースして、何が壊れたか特定する」 (Mehedi、 05:50)
「Cursor が PR を自動テストして、スクリーンショットを PR にアップロードする」 (Mehedi、 07:30、 verifiability の実装)
「Renderer process が Electron に依存しなくなり、そのまま Web アプリとして走る」 (Mehedi、 08:15)
「答えは one-shot をより良くすることではない。 LLM とテニスのラリーをするようなフィードバックループをどう作るか」 (Mehedi、 08:25、核心メッセージ)
「最終プロダクトがブラックボックスじゃなく、マジックのように感じられる」 (Mehedi、 08:55、結論)
「Tauri も試したけど性能面で劇的な改善は見えなかった。我々が最も気にする点」 (Mehedi、 09:35、 Q&A)

出典

You can't just one shot it — Mehedi Hassan, Granola (YouTube、 AI Engineer 公式チャンネル)

関連リソース:

メヘディ・ハッサン

Mehedi Hassan

Granola Product Engineer / 「one-shot するな、フィードバックループしろ」

用語集

Granola: 2024 年創業、 London 拠点の AI 会議メモアプリ。 CEO: Chris Pedregal (元 Google PM、 Socratic 創業者)、共同創業者: Sam Stephenson (元 Ideaflow)。 Dock に常駐し、システム音声 + マイク音声を録音して AI でサマリー生成、ユーザーが手書きメモを書くことで AI 出力をパーソナライズする独特の UX。 2024/10 に $20M、 2026/03 に $125M ($1.5B valuation) を調達、「会議メモから企業 AI アプリ」へ拡張中。
Mehedi Hassan: Granola の Product Engineer。 Queen Mary University of London 卒 (2018-2021)、「jQuery がクールだった頃からコーディングしてる」と自称する Web 開発出身者。 AI Engineer Code Summit 2026 (NYC) で「You can't just one shot it」を発表。
One-shotting (一発生成): LLM に 1 回のプロンプトで完全な出力を生成させようとする手法。簡単なタスクや軽量なツール (例: 内部トレーシングツールのコード) には有効だが、本番品質を目指す機能 (会議サマリー、 Web Search 統合、ユーザー対話) では不十分。 Mehedi の主張: 「one-shot するな、フィードバックループを作れ」。
Electron: GitHub 製のクロスプラットフォームデスクトップアプリフレームワーク。 Chromium + Node.js で Web 技術でデスクトップアプリを構築できる。 VS Code、 Slack、 Discord、 Granola など多くの主要アプリが採用。 Main process (Node.js、システム API アクセス) と Renderer process (Chromium、 UI) の 2 プロセス構成が特徴。
Tauri: Rust 製のクロスプラットフォームデスクトップアプリフレームワーク。 Electron の代替として注目される。 Rust + システム標準 Webview (Chromium 非バンドル) で軽量、セキュリティが強い、ビルドサイズが小さい。主流のオプションの 1 つだが、 API 成熟度や Web 技術との互換性で Electron に劣る場合もある。 Mehedi は「Tauri を試したが性能面で劇的な改善はなかった」と評価。
IPC API (Inter-Process Communication API): Electron の Main process と Renderer process 間で通信するための API。システム API へのアクセス、ファイル読み書き、 OS イベント処理などに使う。 Granola はこの IPC API を抽象化して、 Web 環境では Web 標準 (Fetch API、 LocalStorage、等) にフォールバックする層を作った。
Web Shell 化 (Electron → Web): Granola が採用した実装パターン。 Electron アプリの Renderer process (フロントエンド) を、 IPC API の抽象化により Web アプリとしても動作可能にした。 CI で PR ごとにプレビューリンクを生成、並列テスト、 Cursor による自動テストが可能になる。デスクトップアプリ開発の摩擦を Web アプリ並みに下げる手法。
Agent Loop (エージェントループ): LLM エージェントが、ツールコール → 結果受信 → 推論 → 次のツールコール、を繰り返す処理ループ。デバッグには「どのツールがいつ呼ばれ、何が返り、どう推論したか」を全段追跡できるトレーシングが不可欠。 Granola の創業者本人がこのループを front から back まで追跡してデバッグする、と Mehedi は明かす。
トレーシングツール (Tracing tool): LLM エージェントの実行を可視化するツール。ツールコール、推論ステップ、トークン使用量、コスト、検索クエリ、などを記録・表示。業界では LangSmith (LangChain)、 Helicone、 Arize Phoenix、 OpenTelemetry などの SaaS / OSS が一般的。 Granola は自社専用に内製を選択、「エンジニア以外 (PM、データ、 CX) も使える UI」が設計目標。
フィードバックループ (Feedback loop): LLM 機能の開発で、「実装 → 観察 → 修正」を高速に繰り返す構造。 Mehedi の比喩「LLM とテニスのラリー」。並列テスト可能性、内部観測性、 AI コーディングエージェントによる自動テストなど、複数の要素が組み合わさって成立する。「one-shot で完璧を期待しない」という設計思想の中核。
Cursor (PR テスト自動化): AI コーディングエージェント (Cursor 社製)。 Granola では、 Web Shell 化した PR プレビューに対して Cursor が自動でテストを実行し、スクリーンショットを PR にアップロードする運用。 Karpathy の「verifiability is the bottleneck」概念の具体的実装の 1 つ — AI が自分でテストすることで、人間の検証負担を減らす。
AI Engineer Code Summit (NYC、 2026/05): AI Engineer 系列の主要カンファレンス。 NYC 開催、 2026 年 5 月。 AI Engineer Europe 2026 (Amsterdam、 2026/04) と並ぶ、業界実装者向けの主要イベント。 Granola、 Trigger.dev、 Arize、 OpenCode (Tavoon) など、 LLM プロダクトを本番運用してるスタートアップの実装者が登壇。

comment is stripped from the HTML output. */}