「Domain-Native AI Organization」 の作り方 — Chris Lovejoy (Notius Labs) が提示する 3 つの組織モデル (AI Engineer Europe 2026)

AI Engineer Europe 2026 (London) — Chris Lovejoy / Notius Labs 2026/05/16

クリストファー・ラブジョイ / Chris Lovejoy · 02:37 「Vertical AI で勝つのは fundamentally an organizational problem。 最良のモデルを取りに行くんやない、 domain expertise を組織にどう埋め込むかや」

AI Engineer Europe 2026 (London、 2026/05/16 公開、 約 24 分 45 秒)。 講師は Chris Lovejoy (元医師、 ケンブリッジ大学医学部出身、 NHS 数年勤務後 AI 業界へ。 Tandem (UK 最大手 clinical AI)、 Anterior (米国 prior authorization startup、 Squarepoint 系) の最初の technical employee を経て、 現在 Notius Labs)。 前年 AI Engineer World's Fair の同テーマ講演が 10 万 view を獲得した続編。 「 Domain-Native AI Organization Chris Lovejoy が提唱する、 domain expertise を組織構造の中核に据えた AI 製品開発組織のモデル。 Oracle (専門家が直接製品に手を入れる) / Evaluator (品質測定システムを設計) / Architect (自動改善システムを設計) の 3 つの形態に分類され、 製品の特性とスケールに応じて適切に選択 / 進化させる必要がある。 vertical AI で 95% のプロジェクトが本番到達できない (Gartner) 失敗を回避する組織論的処方箋 」 として、 Oracle / Evaluator / Architect の 3 モデルを実例で示す。

Chris Lovejoy の AI Engineer Europe 2026 講演は、 vertical AI 投資が活発化する中で 「95% のプロジェクトが本番に到達せず abandoned される (Gartner 2025)」 という不都合な現実への組織論的処方箋。 frontier model はもう十分強力、 RAG も普及、 でも 「現場の workflow を本当に automate する AI 製品」 は依然として作れない ── その gap は technology やなく組織 にある、 という主張。

Chris の経歴がそのまま thesis を支える ── 元医師 → Tandem (UK 最大 clinical AI、 採用ベース) → Anterior (prior authorization 自動化 startup、 first technical employee) → Notius Labs。 3 つの会社で 「domain expert を 組織内のどこに置くか」 の試行錯誤を積んで、 そこから抽出した方法論を体系化したのが本講演。

MEMEX 編集視点で重要なのは、 これが Pedro Rodrigues (Supabase) の skill 設計、 Mehedi Hassan (Granola) の feedback loop、 Brian Scanlan (Intercom) の 9 ヶ月 2x 等で個別に観測される 「domain expert が中心にいる組織」 という共通パターンを、 1 つの統一理論 として記述している点。

3 つの組織モデル ── Oracle / Evaluator / Architect

Chris のフレーム:

モデル 役割 適用条件
Oracle 専門家が直接製品に手を入れる ── prompt 編集、 doc 追加、 tool 設定 small scale、 客観 metric なし、 taste 重視
Evaluator 品質測定システムを設計 ── metric 定義、 review pipeline、 engineer 連携 objective metric あり、 manual iteration が間に合う scale
Architect 自動改善システムを設計 ── 評価 + 改良の loop を agent 化 manual iteration では追いつかない速度・variation

Case 1: Granola ── Oracle 永続パターン

Granola (AI ミーティングノート、 2026 年に $1B 評価額突破) の最初の従業員 Joe (元 writer / journalist) は 全 prompts を自分で書き、 ユーザー数千人と話し、 数百論文を読んで 「良いミーティングノートとは何か」 を抽出 した。 5 年経っても同じ役割を主体的に維持。

Chris の分析: 「客観的 perfect note は存在しない」 「人間 taste が支配する domain」 「note 生成は product の core output ── direct human review が scale に耐える」。 だから Oracle が永続して合理的。 これは Mehedi Hassan (Granola) の Cannot one-shot it での 「LLM とのテニスラリー型 feedback loop」 と同じ思想の組織側実装。

Case 2: Tandem ── Decentralized Oracle へ scale

Tandem (UK 最大手 clinical AI scribe ── 医師と患者の会話を聞いて医療ノート生成) は最初 Roy (元医師 + McKinsey) を Oracle として置いた。 review → prompt 修正 → 反復。 しかし scale: 多専門科、 多国、 多 use case で 1 人では不可能。

対応: Decentralized Oracle。 各 specialty / 各 country / 各 use case に小さな Oracle 専門医を配置。 platform 側を 「long-tail prompt customization」 対応に書き直し、 1000s の prompt variation を分業で運用。 「客観 perfect note 不在」 という Granola と同じ性質を持つが、 scale が大きいので分散化が必要。

Case 3: Anterior ── Oracle → Evaluator → Architect の進化

Anterior (米 prior authorization ── 医師の処方を保険会社が承認するか判定する自動化) で Chris は first technical employee。 進化を 3 段階で経験:

  1. Phase 1 (Oracle): Chris が prompt + code を書く、 clinical hat で output を review、 修正反復
  2. Phase 2 (Evaluator): scale で 1 人 Oracle 不可能、 metrics + failure mode 定義、 review dashboard 構築、 clinician を雇って review、 engineer に feed back
  3. Phase 3 (Architect): manual iteration では追いつかない customer variation → 自動改善 loop を architect として設計

Anterior が Oracle → Evaluator → Architect の 進化が 必要 やった理由:

  • AI quality が objective に measurable (承認 / 拒否 / 医学的エビデンス との 合致)
  • Clinical reasoning が必要 (= domain expertise mandatory)
  • Prior auth ルール解釈に巨大 variation (= manual では追いつかない)

誰を採用するか ── 必要スキルの分解

Chris の採用フレーム:

  • Oracle: relevant domain expertise (use case に直接従事した経験) + prompting / context engineering の感覚 + 細部への注意 + 顧客対話力
  • Evaluator: 上記 + data science の直観 (metric 定義、 集計、 分析) + 統計感覚 + leadership / PM 経験 + industry connection (review team を雇う場合)
  • Architect: 上記 + LLM-powered product 開発経験 + engineering スキル

失敗パターン: 「ただの domain expert」 を採用すると、 Oracle から Evaluator → Architect への進化に対応できず、 後で別の人を入れる必要が出る。 これは organizational discontinuity になる ── domain knowledge が頭の中にある人が抜けると、 ゼロからやり直し。

組織設計の 3 原則

Chris の推奨:

  1. Principal domain expert を 1 人定義 ── consensus by committee を避ける、 AI quality に対する明確な責任
  2. Ownership を与えよ ── consultant 扱いせず意思決定の場に入れる、 そうでないと差別化された製品が build できない
  3. Breadth で hire せよ ── domain expertise を base に、 adjacent skills も持つ人を選ぶ、 必要なら statistician 等と pairing

失敗例 (Chris が以前働いた会社): 「senior clinician が 2 人いて、 どちらが最終意思決定か曖昧、 ownership 与えず advisor 扱い」 → 12-18 ヶ月で両者退職、 domain knowledge が組織から抜ける重大損失。

編集所見 ── MEMEX に直接効く統一理論

この講演を MEMEX で取り上げる視点は 3 つ。

(1) Vertical AI の組織論的 unified framework。 これまで MEMEX で扱った Pedro (Supabase)、 Mehedi (Granola)、 Brian (Intercom)、 Mike Spitz (PFF) は全部、 Chris のフレームで Oracle (Pedro / Joe at Granola) / Evaluator (Brian の Team 2x) / Architect (Mike Spitz の autonomous flow) のどれかに分類できる。 これは MEMEX のネットワーク graph 上に 「組織モデル」 軸を追加する根拠。

(2) 「Domain expert を中央に置く」 が 2026 年の差別化要因。 frontier model が commoditize した今、 verticalize した製品の勝敗は 「自社の domain knowledge をどう agent に渡すか」 で決まる。 Chris の 3 モデルは、 その渡し方の選択肢を網羅。 これは Anthropic Glasswing や 日本 3 メガバンクの Claude 採用 の 「enterprise 向け production agent」 議論の組織側補完。

(3) AI ジャーナリズム自体への適用。 MEMEX 自身が 「AI domain の context graph」 として機能する以上、 これは 自己参照的に重要な議論。 編集者 (= domain expert) として MEMEX 運営者は Oracle 段階にあり、 今後 Evaluator (記事品質測定 system 構築) → Architect (自動 article 改善 loop) への進化が課題。 Chris のフレームはそのまま自社の roadmap になる。

動画の構成

  • (00:00) 自己紹介、 経歴 (Cambridge 医学 → NHS → Tandem → Anterior → Notius Labs)
  • (02:37) 「Vertical AI は organizational problem や」
  • (03:30) Gartner 95% プロジェクト abandoned の data
  • (05:00) 3 モデル提示 ── Oracle / Evaluator / Architect
  • (09:00) どのモデルを選ぶか ── 判断 flow chart
  • (10:30) Case 1: Granola の Joe = Oracle 永続パターン
  • (12:00) Case 2: Tandem = Decentralized Oracle へ scale
  • (13:30) Case 3: Anterior = Oracle → Evaluator → Architect 進化
  • (17:00) 必要スキルの分解 (Oracle / Evaluator / Architect 別)
  • (20:00) 組織設計の 3 原則 (Principal / Ownership / Breadth)
  • (22:30) 失敗例 ── senior clinician 2 人退職
  • (24:00) 締め、 Q&A

出典