Claude Science入門——AI仮説をFirestoreで検証台帳にする

はじめに

2026年9月23日、Anthropicは「ClaudeがCRISPRに似た性質を持つ新しい酵素システムを発見した」と発表しました。公式記事では、Claudeが文献と公開データを読み、未知の候補を探し、人間が読める短い候補レポートを作り、その後に研究者が検証する流れが紹介されています。

Web系エンジニアにとって重要なのは、生命科学そのものではありません。ポイントは「AIが大量の候補を出せるようになるほど、候補を評価する仕組みが主役になる」という変化です。

たとえば、AIエージェントに次のような仕事を任せる場面を考えてみます。

本記事では、架空のカスタマーサポートSaaS「SupportLens」を題材に、Next.js App Router + Firestore + TypeScript + GitHub Actionsで「AI仮説の検証台帳」を作ります。この記事を読み終えると、AIの回答をその場で信じるのではなく、候補、根拠、レビュー結果、次のアクションを分けて扱えるようになります。

参考にした一次情報は次の通りです。

• Claude discovers a novel enzyme system with CRISPR-like repeats
• Claude Opus 5.5
• Claude Science
• Claude Code

Anthropicの発表から読み取れる設計パターン

Anthropicの発表では、Claudeがタンパク質ファミリーを調査し、既存研究を再現して方法を確認し、未説明の候補を探す流れが説明されています。その後、各候補について機能の仮説と根拠を短いレポートにし、さらにClaude自身が批判的に評価します。最終的に、研究者がレビューして実験対象を絞ります。

ここでWebアプリに応用しやすいのは、次の4段階です。

AIエージェントを強くするほど、「候補をたくさん出す」能力は上がります。一方で、候補が増えるほど、採用した理由、却下した理由、後から見直すべき根拠を残さないと、チームの判断がブラックボックスになります。

Anthropicの記事でも、単一キャンペーンから数百から数千の候補レポートが出るため、仮説そのものが研究対象になっていると説明されています。これはWeb開発でも同じです。AIに20〜30件のIssueを読ませるなら、返ってきた結論だけでは足りません。候補を台帳化し、人間のレビュー結果を学習材料として再利用できる形にする必要があります。

台帳で管理するデータ

SupportLensでは、問い合わせチケットをAIに読ませ、プロダクト改善の仮説を作ります。たとえば「請求画面の離脱が増えている」「CSV出力の説明が不足している」といった候補を、すぐ施策にせず、検証台帳に入れます。

Firestoreのコレクションは次のように分けます。

型はシンプルに始めます。重要なのは、AIの文章を大きな1フィールドに押し込まないことです。あとで並べ替え、集計、再レビューできるように、構造化して保存します。

export type HypothesisStatus = "candidate" | "accepted" | "rejected" | "needs_data";

export type Hypothesis = {
  campaignId: string;
  title: string;
  summary: string;
  evidenceTicketIds: string[];
  riskLevel: "low" | "medium" | "high";
  confidence: number;
  status: HypothesisStatus;
  aiRationale: string;
  reviewerNote?: string;
  createdAt: FirebaseFirestore.FieldValue;
  updatedAt: FirebaseFirestore.FieldValue;
};

confidence はAIの自己評価なので、正解率として扱わないようにします。画面では「AIの自信度」と明示し、人間のレビュー結果とは別の列に置くのが安全です。

ハンズオン1: 候補生成キャンペーンを登録する

まず、AIへ渡す対象範囲をキャンペーンとして保存します。SupportLensでは「直近7日間の請求カテゴリの問い合わせ」など、スコープを明確にします。

// src/app/actions/createHypothesisCampaign.ts
"use server";

import { FieldValue, getFirestore } from "firebase-admin/firestore";

type CreateCampaignInput = {
  projectId: string;
  ticketCategory: "billing" | "onboarding" | "export";
  fromDate: string;
  toDate: string;
  requestedBy: string;
};

export async function createHypothesisCampaign(input: CreateCampaignInput) {
  const db = getFirestore();

  const campaignRef = await db.collection("hypothesisCampaigns").add({
    projectId: input.projectId,
    ticketCategory: input.ticketCategory,
    fromDate: input.fromDate,
    toDate: input.toDate,
    requestedBy: input.requestedBy,
    status: "draft",
    createdAt: FieldValue.serverTimestamp(),
    updatedAt: FieldValue.serverTimestamp(),
  });

  return { campaignId: campaignRef.id };
}

AIに渡す前にキャンペーンを作る理由は、後から「どの条件で候補が出たのか」を追えるようにするためです。AIエージェント運用では、プロンプトだけでなく、入力データの範囲も監査対象になります。

ハンズオン2: AI出力をそのまま保存せず、候補ごとに分解する

次に、AIから返ってきた候補をFirestoreに保存します。ここでは特定のAnthropic APIやClaude Codeコマンドを仮定しません。Claude Scienceの記事から学べるのは、ツール名ではなく「候補レポートを作り、人間が読む単位に整える」という設計です。

AI出力は、サーバー側で次のような配列に正規化済みという前提にします。

type NormalizedHypothesis = {
  title: string;
  summary: string;
  evidenceTicketIds: string[];
  riskLevel: "low" | "medium" | "high";
  confidence: number;
  aiRationale: string;
};

Firestoreへ保存するときは、キャンペーンIDを必ず付けます。あとでキャンペーン単位で採用率や却下理由を集計するためです。

import { FieldValue, getFirestore } from "firebase-admin/firestore";

export async function saveHypotheses(
  campaignId: string,
  hypotheses: NormalizedHypothesis[],
) {
  const db = getFirestore();
  const batch = db.batch();

  for (const hypothesis of hypotheses.slice(0, 30)) {
    const ref = db.collection("hypotheses").doc();

    batch.set(ref, {
      campaignId,
      title: hypothesis.title,
      summary: hypothesis.summary,
      evidenceTicketIds: hypothesis.evidenceTicketIds,
      riskLevel: hypothesis.riskLevel,
      confidence: Math.max(0, Math.min(1, hypothesis.confidence)),
      status: "candidate",
      aiRationale: hypothesis.aiRationale,
      createdAt: FieldValue.serverTimestamp(),
      updatedAt: FieldValue.serverTimestamp(),
    });
  }

  await batch.commit();

  await db.collection("hypothesisCampaigns").doc(campaignId).update({
    status: "reviewing",
    updatedAt: FieldValue.serverTimestamp(),
  });
}

slice(0, 30) のように上限を置くのは、最初の運用でレビュー不能な量を作らないためです。AIは候補を増やせますが、人間のレビュー帯域は急には増えません。まず30件程度に絞り、採用率を見てから増やす方が現実的です。

ハンズオン3: レビュー結果を次回に返す

Anthropicの記事で興味深いのは、候補の良し悪しから研究者の判断基準を学ばせている点です。Webアプリでも、採用・却下の理由を残せば、次回のプロンプト改善に使えます。

import { FieldValue, getFirestore } from "firebase-admin/firestore";

type ReviewInput = {
  hypothesisId: string;
  reviewerId: string;
  decision: "accepted" | "rejected" | "needs_data";
  note: string;
};

export async function reviewHypothesis(input: ReviewInput) {
  const db = getFirestore();
  const hypothesisRef = db.collection("hypotheses").doc(input.hypothesisId);
  const reviewRef = hypothesisRef.collection("reviews").doc();

  await db.runTransaction(async (transaction) => {
    transaction.set(reviewRef, {
      reviewerId: input.reviewerId,
      decision: input.decision,
      note: input.note,
      createdAt: FieldValue.serverTimestamp(),
    });

    transaction.update(hypothesisRef, {
      status: input.decision,
      reviewerNote: input.note,
      updatedAt: FieldValue.serverTimestamp(),
    });
  });
}

レビューUIでは、AIの仮説、根拠チケット、AIの自信度、人間の判断を横並びにします。

GitHub Actionsでは、毎朝レビュー結果を集計し、次回のAI実行時に参照するメモを作れます。ここでもAI呼び出しを直接書く必要はありません。まずは人間の判断ログを整えるだけで十分です。

name: summarize-hypothesis-reviews

on:
  schedule:
    - cron: "0 22 * * *"
  workflow_dispatch:

jobs:
  summarize:
    runs-on: ubuntu-latest
    steps:
      - name: Call internal review summary endpoint
        run: |
          curl -X POST "$SUMMARY_ENDPOINT" \
            -H "Authorization: Bearer $SUMMARY_TOKEN"
        env:
          SUMMARY_ENDPOINT: ${{ secrets.SUMMARY_ENDPOINT }}
          SUMMARY_TOKEN: ${{ secrets.SUMMARY_TOKEN }}

このワークフローはUTC 22時に動くため、日本時間では翌朝7時です。チームの始業前に、前日レビューされた仮説の傾向をまとめる運用に向いています。

運用で気をつけること

AI仮説の台帳運用では、精度より先にトレーサビリティを作るのが大切です。特に次の3点は最初から決めておきます。

また、生物学や医療など高リスク領域では、専門家レビューと安全要件が不可欠です。本記事のコード例は、問い合わせ分析や開発タスク整理のような一般的な業務アプリ向けの設計です。Anthropicの研究成果を、専門領域の検証手順として再現するものではありません。

まとめ

AnthropicのClaude Science発表から学べるのは、AIが「答えを1つ出す道具」から「大量の候補を作り、人間の判断を加速する道具」へ移っていることです。

Web開発チームがこの流れを取り入れるなら、まず作るべきは派手な自動実行ではなく、候補、根拠、レビュー結果を分けて保存する台帳です。Next.js + Firestoreなら、キャンペーン、仮説、レビューを小さなコレクションに分けるだけで、AIエージェントの出力をチームで扱える形にできます。

SupportLensのように30件単位で候補を出し、人が採用・却下し、その理由を次回に返す。この地味なループが、AI活用を「便利な一回きりの回答」から「改善され続ける業務プロセス」へ変えていきます。