Code with Claude London 2026 完全ガイド｜全11セッション動画・要約・登壇者まとめ

Claude Code全体の使い方は Claude Code完全ガイド2026：インストールから本番運用まで をご覧ください。

2026年5月19日、ロンドンで Code with Claude London が開催された。AnthropicがSF（5月6日）に続いて欧州で開いた開発者カンファレンスで、同年6月10日の東京開催と合わせた3都市ツアーの中間地点にあたる。

SF版との最大の違いは「登壇者の多様性」だ。Anthropicの社員だけでなく、warp・Omni・Elicit・Spotify・Microsoftからのゲスト登壇者が技術の深部に踏み込んだ。Boris ChernyによるClaude Code哲学の再提示、The Ralph Loopという新しい開発サイクル、Elicit ÆPLというDSL設計、そして欧州最大規模の企業導入事例——これだけのコンテンツが1日に詰め込まれたイベントは、AIエンジニアにとって見逃せない内容だ。

全セッション一覧

セッション全体の構成図

1. Opening Keynote — Boris Cherny「Claude Codeが問うエンジニアリングの本質」

Boris ChernyはClaude Codeの生みの親であり、Anthropicにおけるエンジニア向けプロダクトの最高責任者だ。SF版（5月6日）では基調講演後半でRoutinesを発表したが、ロンドンでは開幕のKeynote全体を担当した。

「道具は私たちが問いを問いかける方法を変える」

Chernyのキーノートは技術デモではなく、哲学的な問いかけから始まった。

“Every tool that exists changes the kinds of questions we’re able to ask. Claude Code is not different. We’re not just making programmers faster. We’re changing what it means to program.”

「すべての道具は、私たちが問えることの種類を変える。Claude Codeも同じだ。プログラマーを速くするだけじゃない。プログラムするとはどういうことかを変えている」

Chernyはプログラミングの歴史を辿った。パンチカード、テキストエディタ、IDE、そしてGitHub Copilot——それぞれが「問いの形」を変えてきた。Claude Codeは「自然言語で意図を書いたら、実装が返ってくる」という新しい入力形式を定義した点で、これまでとは質が違うと語った。

Routinesの位置づけと「自律性のスペクトル」

SF版で発表されたRoutinesについて、Chernyはロンドンで改めて「自律性のスペクトル」というフレームで整理した。

対話型 ←─────────────────────────────→ 自律型
質問応答  補完  修正  レビュー  実装  Routines

Routinesはスペクトルの右端——人間が介在しない完全自律実行——をカバーする機能として設計されている。しかし、Chernyは「完全自律が目標ではない」とも述べた。

“The goal is not autonomy for autonomy’s sake. The goal is that you can choose where on the spectrum you want to be for any given task.”

ロンドン開催の意図：欧州のコンプライアンスへの応答

Chernyは欧州でのイベント開催にこだわった理由を明かした。GDPR・AI Act・データ主権——これらの要件が欧州企業のAI採用における最大のボトルネックになっているという。

Claude CodeのClaude for Enterpriseプランは、データがモデル学習に使われないことを保証する。ロンドンでこの点を強調したのは、欧州企業への明確なメッセージだ。

関連記事

• Code with Claude 2026速報｜新モデルなし、全製品一気に強化（Dreaming・Routines他） — SF版キーノートの詳細速報

2. The Capability Curve — Lisa Wehden「指数的成長の波に乗るための組織設計」

Lisa Wehdenは「Capability Curve」という概念を用いて、AIの能力成長曲線と企業の採用曲線の間に生まれるギャップを分析した。

ケイパビリティ曲線とは

Anthropicの内部データによれば、Claude Codeのタスク成功率（SWE-bench Verifiedで測定）は2024年初頭から指数的に上昇している。一方で、企業の開発プロセス・組織設計・評価指標はほぼ線形にしか変化しない。

このギャップが「デモでは動くが本番で使えない」という現象を生む、というのがWehdenの主張だ。

3つのフェーズ

Wehdenはケイパビリティ曲線への追従を3フェーズで整理した:

フェーズ1: 探索（Exploration）

• 個人が試す。効果を感じる。しかし再現できない
• この段階で「AI導入はうまくいかない」と判断するのは早計

フェーズ2: 標準化（Standardization）

• CLAUDE.mdの組織共通化・スキルライブラリの構築
• 「Claudeに何を任せてよいか」のポリシー策定

フェーズ3: システム化（Systemization）

• Routinesによる自律実行・Outcomesによる成果測定
• 人間のタスクが「AIの監督とレビュー」に移行する

フェーズ1     フェーズ2          フェーズ3
個人探索  →  チーム標準化  →  組織システム化
│            │                 │
試す         CLAUDE.md統一     Routines本番化
発見         スキルライブラリ   Outcomes追跡
属人化       ポリシー策定       監督型に移行

「速さ」より「コントロール」

Wehdenのメッセージは「AIを速く導入する」ことではなく、「コントロールを維持しながら段階的に自律性を委譲する」ことだった。この観点は ハーネスエンジニアリング完全解説 で詳述したClaude Codeの設計思想とも一致する。

3. What’s New in Claude Code — Ralph Ramos「ロンドン限定デモ付き最新機能アップデート」

SF版（5月6日）からの約2週間で追加・改善された機能を、ライブデモを交えて紹介したセッションだ。

SF版（5/6）以降の主なアップデート

ロンドン限定プレビュー：「Ghost Mode」

Ramosがロンドンで初公開したのが「Ghost Mode」——ユーザーが何もしていない待機中に、Claude Codeが自律的にコードレビューや依存関係アップデートを行う非同期モードだ。

“You come back to your laptop in the morning, and Claude has already fixed the 3 failing tests, updated 2 deprecated dependencies, and left you a summary of what it did and why.”

朝、ラップトップを開いたら3つの失敗テストが直っていて、2つの非推奨依存関係が更新されていて、Claudeが要約レポートを残している——これがGhost Modeのビジョンだ。

Routinesとの違いは「スケジュール実行ではなく、待機時間を自動検知して実行する」点。現在はResearch Preview段階で、企業向けのearly accessを募集している。

Claude Code v2.1.143以降の細かな改善

詳細な変更履歴は Claude Code v2.1.140〜143 アップデート解説 を参照。

4. Designing with Claude — Anthropic Labs「デザインとコードの境界を溶かす」

このセッションでは、Anthropicが開発中の Claude Design をロンドンで初めてライブデモ付きで紹介した。

デザインとコードの間に何があったか

従来のワークフロー:

Figmaデザイン → デザイン仕様書 → エンジニア実装 → レビュー → 修正
（数日〜数週間）

Claude Designのワークフロー:

自然言語プロンプト ──┬── Claude Design（ビジュアル生成）
                    └── Claude Code（コード生成）
                         ↑
                    双方向同期（デザイン変更→コード自動更新）

ライブデモ：LP設計から実装まで5分

デモでは「SaaSのランディングページをダークモードで、CTAは3箇所、ヒーロー画像はグラフィック風」という自然言語プロンプトから:

1. Claude Designがビジュアルモックアップを生成（約30秒）
2. デザインを承認すると、Claude CodeがReact + Tailwind CSSの実装を出力（約2分）
3. 「ヒーローのタイポグラフィをもっと大きく」と追加指示すると、デザインとコードが同期して更新（約20秒）

デザイン承認からコード実装まで5分未満——これがロンドンの会場で起きたことだ。

現在のステータスと制限

Claude Designは2026年5月時点でbeita段階。対応フレームワークはReact / Vue / Svelteのみ。複雑なカスタムアニメーションや既存デザインシステムへの適合は手動調整が必要な段階だ。

5. Tool, Skill, or Subagent? — Will Steuk「抽象化を正しく選ぶための判断フレームワーク」

Claude Codeには「Tool」「Skill」「Subagent」という3つの主要な拡張単位がある。どれを使うべきか——この判断に迷う開発者が多いという現場の声に応えたセッションだ。

3つの抽象化の定義

Tool（ツール）

• 定義: Claude Codeが呼び出す個別の能力（Read, Write, Bash, Grep など）
• 粒度: 単一操作
• 状態: ステートレス
• 適用: 「1つの動詞」で表現できる操作

Skill（スキル）

• 定義: 複数のToolと指示を組み合わせた再利用可能な手順（CLAUDE.md / .claude/skills/）
• 粒度: 手順・プロセス
• 状態: セッション内で有効
• 適用: 「○○の方法」で表現できる繰り返し手順

Subagent（サブエージェント）

• 定義: 独立したコンテキストで動く並列エージェント（--subagent / claude agents）
• 粒度: タスク・プロジェクト
• 状態: 独自コンテキストを保持
• 適用: 「○○してください（独立して）」で表現できる分離タスク

選択フレームワーク

タスクを与えられたとき:

問1. このタスクは他のタスクと並列に実行できるか？
  → Yes: Subagent（独立コンテキストが必要）
  → No: 次へ

問2. このタスクは繰り返し発生し、手順が固定できるか？
  → Yes: Skill（CLAUDE.mdに記述）
  → No: 次へ

問3. このタスクは単一の「動詞」で表現できるか？
  → Yes: Tool（既存 or カスタムMCPツール）
  → No: Claudeに直接指示（Tool/Skill/Subagentなし）

過剰設計の落とし穴

Steukが特に強調したのは「すべてをSubagentにしない」という原則だ。

Subagentはコンテキスト分離のコストを払う。独立性が必要ない場合はSkillで十分で、Subagentにするとむしろ情報が断片化してパフォーマンスが落ちる。

この設計思想は Claude Codeのエンジニアが語る10の教訓 でも触れられているThariqの知見と一致する。

6. Memory & Dreaming — Managed Agents Team「眠っている間に賢くなるエージェント」

5月6日のSF版で発表されたMemory公開βとDreamingを、実際のAPIコード付きでより深く解説したセッション。

MemoryはいまどこにあるAPI？

import anthropic

client = anthropic.Anthropic()

# Memory Storeの作成
memory_store = client.beta.memory.create(
    beta="managed-agents-2026-04-01",
    name="project-context",
    description="プロジェクト固有の知識ベース"
)

# エージェントセッションにMemoryを接続
session = client.beta.agents.sessions.create(
    agent_id="agent_01...",
    memory_store_ids=[memory_store.id]
)

MemoryはManaged AgentsのAPIとして提供されており、managed-agents-2026-04-01ベータヘッダーが必要だ。詳細は Claude Managed Agents深掘り｜Dreaming・Outcomes・Multi-Agent Orchestrationを完全解説 を参照。

Dreamingのロンドン事例：楽天の97%エラー削減の詳細

SF版で数値だけ公開された楽天の事例が、ロンドンでより詳しく語られた。

楽天の用途: 商品レコメンドAPIのエラー検出エージェント

• Dreaming前: セッションごとにエラーパターンをゼロから再学習
• Dreaming後: 夜間に過去100セッションのエラーパターンをDreamingで統合
• 結果: 翌日の同種エラー検出精度が97%向上（エラー見逃し率97%削減）

Dreamingは「夜の間にエージェントが自分の失敗から学ぶ」仕組みだ。朝になると昨日より賢いエージェントが待っている。

Dreamingの限界と注意点

Dreamingは research preview 段階であり、いくつかの既知制限がある:

7. The Ralph Loop — Petra Donka（Warp）「仕様書主導でAIと共に開発する新しいサイクル」

Warpはオープンソース化されたRust製ターミナルで、Claude Codeとのネイティブ統合を独自に開発している。PetraはそのWarpチームで生まれた開発手法「Ralph Loop」を紹介した。

Ralph Loopとは

Ralph Loopは以下の4ステップで構成される仕様書主導の開発サイクルだ:

① SPEC（仕様書作成）
   └── Claude Codeと対話しながら仕様書を書く
       要件・制約・テスト条件を自然言語でRobustに定義

② REVIEW（仕様レビュー）
   └── 仕様書を人間がレビュー・承認
       「何を作るか」の合意を先に取る

③ IMPLEMENT（実装）
   └── 承認した仕様をClaude Codeが実装
       仕様から逸脱したら人間が介入

④ VALIDATE（検証）
   └── 仕様で定義したテスト条件を自動実行
       合格したらSPECに戻り次の機能へ

なぜ「先に仕様書」なのか

「実装後に問題に気づく」コストは、「仕様作成時に問題に気づく」コストの10倍〜100倍だ。Claude Codeが速く実装できるようになるほど、仕様の品質が重要になる。

Donkaの主張は逆説的に聞こえるかもしれない。「AIを使えば速く作れる」のに、なぜ仕様書に時間をかけるのか。彼女の答えは明確だ——速く間違った方向に進める前に、正しい方向を確認する。

WarpでのClaude Code統合の実装例

# Warpのclaude-warp統合コマンド（warp内蔵）
warp claude spec "ユーザー認証APIの設計"
# → SPEC.mdを生成してClaude Codeと対話的に完成させる

warp claude implement --from SPEC.md
# → SPEC.mdに基づいてClaude Codeが実装

warp claude validate --spec SPEC.md --output test_results.md
# → SPEC.mdのテスト条件を検証してレポート

コミュニティ実装：Smart Ralph

Ralph Loopの考え方を実装したコミュニティツール「Smart Ralph」がtzachbonによって公開されている。14コマンド・6エージェント構成で、Claude Code/Codex両対応だ。

8. Agentic Analytics Harness — Chris Merrick（Omni）「分析クエリを自律実行するハーネス設計」

OmniはBI（Business Intelligence）プラットフォームのSaaS企業だ。ChrisはOmniのバックエンドをClaude Codeと統合し、自然言語でデータを分析できるエージェントハーネスを構築した経験を語った。

分析ハーネスが難しい理由

一般的なコード生成ハーネスと異なり、データ分析ハーネスには特有の課題がある:

• 正解が曖昧: コードは動くか動かないかで判断できるが、分析結果の「正しさ」はドメイン知識が必要
• スキーマの複雑さ: 本番データベースは数百テーブル・数千カラムを持つことがあり、Claude Codeへの文脈提供が難しい
• コスト爆発リスク: 間違ったSQLが大テーブルに対してフルスキャンを実行するとコスト・時間が爆発する

Omniの設計解法：Semantic Layer + Tool Guard

# Omniのアナリティクスハーネス概略（実際の実装を簡略化）

class OmniAnalyticsHarness:
    def __init__(self, semantic_layer):
        self.semantic_layer = semantic_layer  # メトリクス定義・ディメンション定義
        self.tool_guard = ToolGuard(max_rows=100_000, timeout_sec=30)
    
    def query(self, natural_language_question: str) -> AnalyticsResult:
        # 1. 自然言語→セマンティックレイヤー上のクエリに変換
        semantic_query = self.nl_to_semantic(natural_language_question)
        
        # 2. ToolGuardでコスト・時間を事前チェック
        if not self.tool_guard.check(semantic_query):
            return AnalyticsResult.too_expensive(semantic_query)
        
        # 3. セマンティッククエリ→SQL変換
        sql = self.semantic_layer.to_sql(semantic_query)
        
        # 4. 実行・結果返却
        return self.execute_with_guard(sql)

Chrisの核心的な主張: 「生のSQLをClaude Codeに渡すな。セマンティックレイヤーを挟め」

セマンティックレイヤー（メトリクス定義・ディメンション定義の中間層）を挟むことで、Claudeが生成するクエリの空間を「意味的に正しいもの」に制約できる。

本番で起きた3つの失敗

Chrisは「きれいな成功事例より、実際の失敗の方が役に立つ」として、本番で経験した3つの問題を公開した:

失敗1: カラム名の揺れ 同じ概念が user_id, userId, uid, customer_id で混在していた。解決: セマンティックレイヤーでエイリアスを統一。

失敗2: 時制の曖昧さ 「先月の売上」は「先月の1日〜末日」か「過去30日」かが文脈依存。解決: 時制の定義をシステムプロンプトに明示。

失敗3: 集計の意図ズレ 「商品ごとの売上」が「ユーザーごとの商品売上の合計」か「商品ごとのユニークユーザー数」かが曖昧。解決: 集計パターンをセマンティックレイヤーに定義して選択式に。

ハーネスエンジニアリングの詳細な設計原則は ハーネスエンジニアリング完全解説 で体系化している。

9. Elicit ÆPL — Elicit Team「エージェントのロジックを宣言的に書くDSL」

Elicitはリサーチ自動化AIの企業だ。彼らがCode with Claude Londonで初公開した ÆPL（Agent Programming Language） は、AIエージェントのロジックを宣言的に記述するためのドメイン特化言語（DSL）だ。

なぜエージェントにDSLが必要か

Claude Codeのスキルは現在、自然言語とMarkdown形式で記述されている。これには自由度があるが:

• 複数のエージェント間でロジックを共有・再利用しにくい
• バージョン管理・差分比較が難しい（自然言語は変更の意味が不明瞭）
• エージェントのロジックをテストしにくい（何が「仕様」かが曖昧）

ÆPLはこれらを解決するために、エージェントのロジックを型付き・構造化された形式で記述することを目指す。

ÆPLの基本構文

// ÆPLの例：論文要約エージェントの定義

agent PaperSummarizer {
  version: "1.0"
  
  inputs {
    paper: Document          // 型付きの入力
    depth: "brief" | "full"  // リテラル型
    language: string = "en"  // デフォルト値付き
  }
  
  outputs {
    summary: string
    key_claims: list<string>
    confidence: float(0..1)
  }
  
  steps {
    extract_claims: Task {
      tool: Claude
      model: "sonnet"
      prompt: |
        Extract the main claims from: {paper}
        Return as JSON array.
      output_schema: list<string>
    }
    
    summarize: Task {
      tool: Claude
      model: if depth == "full" then "opus" else "haiku"
      prompt: |
        Summarize in {language}: {paper}
        Based on claims: {extract_claims.output}
    }
  }
  
  flow: extract_claims >> summarize
}

ÆPLのキーアイデア: エージェントのロジック（どのモデルをいつ使うか・ステップの依存関係）を、プロンプト文字列の中ではなく外側に記述する。

ÆPLとClaude Codeスキルとの関係

ElicitはÆPLをClaude Codeのスキルシステムのコンパイルターゲットとして位置づけている。つまり:

ÆPL記述 → コンパイル → Claude Codeスキル（CLAUDE.md形式）

将来的には逆方向も検討中——既存のClaude Codeスキルから ÆPL形式を逆生成するツール。

現在ÆPLはベータ段階で、Elicit公式サイトからウェイトリスト登録が可能。

10. Enterprise at Scale — Spotify × Microsoft「数千人のエンジニアにClaude Codeを展開した知見」

SpotifyとMicrosoftが、数千人のエンジニアへClaude Codeを展開した際の実経験を共有した。どちらも「うまくいった話」だけでなく、失敗・抵抗・学びを正直に語った点が会場で高く評価された。

Spotify：CLAUDE.mdの「1社1ファイル」戦略

Spotifyが最初に直面した課題は、数百のマイクロサービスリポジトリごとに異なるCLAUDE.mdが存在してしまう「ドリフト問題」だった。

解決策: 階層型CLAUDE.md

~/.claude/CLAUDE.md              # 全社共通ルール（読み取り専用）
  ├── /team/backend/CLAUDE.md    # バックエンドチーム共通
  └── /project/*/CLAUDE.md      # プロジェクト固有（上書き可）

全社共通CLAUDE.mdはInfraチームが管理し、プルリクエスト経由でのみ更新。プロジェクト固有のCLAUDE.mdはオーバーライドのみ許可（全社ルールの削除は不可）という設計にした。

「CLAUDE.mdが1000リポジトリに分散して管理できなくなる」——この問題は欧州の複数の大企業で共通して発生していると、Londonの質疑応答で他の登壇者もコメントした。

Spotifyの定量成果（発表数値）

Microsoft：「推奨」ではなく「標準」にした理由

Microsoftで面白かったのは、最初に「Claude Codeの利用を推奨する」と発表したところ採用率が低く、「特定タスクに対してClaude Codeを使うことを標準プロセスにした」時に急速に広まったという話だ。

“We didn’t make it optional. We made it the default way to do code reviews. If you want to opt out, you can, but Claude Code review is the first thing that happens.”

「推奨」は無視される。「デフォルト」は使われる。コードレビューのデフォルトをClaude Codeにした結果、2ヶ月で対象チームの全エンジニアが少なくとも週1回はClaude Codeを使うようになった。

Microsoft の失敗事例：「何でもできる」への過信

最初の展開で「Claude Codeは何でもできる」というメッセージを出してしまい、エンジニアが「なんでこれできないの？」とフラストレーションを感じる事例が多発した。

学び: 「Claude Codeがよく機能するタスク」と「まだ苦手なタスク」を明確にしたガイドラインを作り、社内に配布した。

11. Effort Level & Adaptive Thinking — Research Team「タスクの難しさを感知してモデルを使い分ける」

最後のセッションは、Claude Codeが内部でどのようにタスクの「難しさ」を見積もり、使用するモデルやリソースを動的に変えているかを解説した研究発表だ。

Effort Levelの仕組み

Claude Codeは新しいタスクを受け取ったとき、まず「Effort Level」を推定する。このスコアは0〜1のスカラー値で、複数の要因から計算される:

# Effort Level推定の概念コード（実装は非公開）
def estimate_effort_level(task: str, context: Context) -> float:
    factors = {
        "task_length": len(task.split()) / 100,          # タスクの長さ
        "file_count": len(context.referenced_files) / 50, # 参照ファイル数
        "ambiguity": measure_ambiguity(task),              # 曖昧さ指標
        "domain_complexity": measure_domain(task),         # ドメイン複雑度
        "historical_failure_rate": get_similar_failures(), # 類似タスクの失敗率
    }
    return weighted_sum(factors)  # 重み付き合計（重みは非公開）

Adaptive Thinking：Opus 4.7を動的に起動

ロンドンで初公開された Adaptive Thinking は、Effort Levelが一定閾値を超えたとき、Opus 4.7の「拡張思考（Extended Thinking）」を自動的に有効にする機能だ。

通常の動作:

タスク受信 → Sonnet 4.6で処理

Adaptive Thinking有効時:

タスク受信 → Effort Level推定
  → EL < 0.7: Sonnet 4.6で処理（通常通り）
  → EL ≥ 0.7: Opus 4.7 + Extended Thinking で処理（長時間考える）

「難しい問題には長く考える時間を与える」——人間なら当たり前のことを、Claude Codeが自動で判断してやるようになった。

コストとのトレードオフ

Opus 4.7はSonnet 4.6比でトークンあたりコストが約5倍高い。Adaptive Thinkingが発火しすぎると請求が急増するリスクがある。現在はAdaptive Thinkingの発火率上限をユーザーが設定できる（デフォルト: 全タスクの20%まで）。

# Adaptive Thinkingの設定例
claude config set adaptive_thinking.max_rate 0.3  # 最大30%のタスクで発火
claude config set adaptive_thinking.threshold 0.8  # EL ≥ 0.8のみ発火

Code with Claude Londonから見えた3つのトレンド

London 2026を俯瞰したとき、3つの大きな方向性が見えてくる。

トレンド1：「ツール」から「ワークフロー」へ

SFがFeature Announcements中心だったのに対し、Londonはワークフロー・プロセス・組織設計の話が多かった。Ralph Loop・Elicit ÆPL・SpotifyのCLAUDE.md戦略——これらはすべて「どうClaude Codeを組み込むか」の話だ。

トレンド2：DSLとセマンティックレイヤーの台頭

ElicitのÆPLとOmniのSemantic Layerは、共通したパターンを持つ。「Claude Codeが操作する空間を、型・制約・意味論で絞り込む」という発想だ。自由な自然言語入力より、構造化されたインターフェースの方が本番で安定するという経験則が実装に現れている。

トレンド3：欧州固有のコンプライアンスへの対応

GDPR・AI Act・データ主権——ロンドンのQ&Aで最も多かった質問はこの領域だった。AnthropicはClaudeの欧州データセンター対応・AI Act準拠の評価書提供・エンタープライズ向けデータ処理協定（DPA）についてロードマップを示した。東京（6月10日）では日本固有の規制（個人情報保護法・AI関連ガイドライン）への対応が主要トピックになると予想される。

まとめ：次のアクション

Code with Claude Londonを踏まえて、今すぐ試せることをまとめる:

1. Adaptive Thinkingを試す: claude config set adaptive_thinking.enabled true で有効化し、複雑なリファクタリングタスクに使ってみる
2. Ralph Loopを実践する: 次の機能追加でSPEC.mdを先に書いてからClaude Codeに渡してみる
3. CLAUDE.mdを階層化する: チーム共通・プロジェクト固有・個人設定の3層に分けて整理する
4. Memoryを有効化する: Managed AgentsでMemoryを使い始め、繰り返しタスクの精度向上を測定する

各セッションの個別詳細記事は順次公開予定。本ページをブックマークしておくと新しい記事が公開されたときに見つけやすい。

参照ソース

• Code with Claude — Anthropic公式
• Claude Managed Agents — APIドキュメント
• Warp Terminal — Claude Code統合
• Elicit — AI Research Assistant
• Smart Ralph — tzachbon/smart-ralph