特定分野に特化したAIツールを自分で作りたい個人開発者にとって、Anthropic が2026年6月30日に公開した「Claude Science」は教材の宝庫だ。科学者向けに60以上のツールとデータベースを事前構成した専用ワークベンチという形を採ったこの製品は、製薬の中身を知らなくても「汎用モデルを特定ドメインの即戦力に仕立てる設計」がまるごと観察できる。筆者は競艇予想AIやEVE Onlineの統合ダッシュボードなど、ドメイン特化の自作アプリを複数運用してきた。その実務目線で、Claude Science から個人開発者が汎用的に真似できる設計の型を取り出す。
目次
Claude Science が公開したもの（公開情報の範囲で）
Anthropic の公式発表によると、Claude Science は科学研究の断片化したツール群を1つの環境に統合するAIワークベンチだ。公開情報の範囲で要点を並べる。
- 60以上のキュレーション済みスキルとコネクタを事前構成（ゲノミクス・単一細胞解析・プロテオミクス・構造生物学・ケモインフォマティクス）。
- 生成した図表には再現パッケージが付く。図を作ったコードと計算環境、平易な言葉での作成手順の説明、メッセージ履歴の全体が同梱される。
- レビュワーエージェントが引用と計算を点検し、誤りを検出して修正する。分析の途中で自己修正しながら進む点も明記されている。
- Claude Pro / Max / Team / Enterprise 向けにベータ提供（macOS・Linux、2026年6月30日開始）。既存の Claude モデル上で動く。
- あわせて、商業的に採算が合いにくい病気を対象とする創薬プログラムも開始したと発表された。
製品の細部までは筆者も検証していない。ここで注目したいのは、この構成に埋め込まれた設計の型だ。製薬の知識はいらない。報道では、Claude Science は OpenAI が2026年4月に出した研究支援AIへの回答という位置づけでも語られている。大手が同じ方向へ動いている事実は、ドメイン特化ワークベンチという製品カテゴリが立ち上がりつつある傍証になる。
ドメイン特化ワークベンチを4つの部品に分解する
汎用チャットに毎回前提を貼り直す手間を、なぜ人は消耗と感じるのか。前提の再入力・ツールの手呼び出し・出力の検算という定型作業が、分野の仕事のたびに丸ごと繰り返されるからだ。Claude Science はこの繰り返しを製品側へ吸収している。構成要素はこう分解できる。
汎用LLM
＋ ①ドメイン知識の注入（用語・制約・評価基準をシステム側に固定）
＋ ②ツール接続（その分野で頻出の検索・計算・データ取得を事前配線）
＋ ③検証ループ（出力を別エージェントが点検・自己修正）
＋ ④出典と監査可能性（何を根拠にどう作ったかを残す）
＝ 「開いたら仕事が始まる」ドメイン特化ワークベンチClaude Science の各機能は、この4部品にきれいに対応する。60コネクタは②、レビュワーエージェントは③、図表の再現パッケージは④だ。汎用チャットとの差は「毎回ゼロから指示する」か「専門家の道具箱が最初から揃っている」かに集約される。この差がその分野の人にとっての価値になり、課金の理由になる。
| 設計部品 | 汎用チャットでの状態 | ドメイン特化ワークベンチでの状態 |
|---|---|---|
| ①ドメイン知識 | 毎回プロンプトに貼る | システム側に固定済み |
| ②ツール接続 | 手で呼ぶ・都度設定 | 事前配線で即利用 |
| ③検証 | 人間が目視で検算 | 別エージェントが自動点検 |
| ④出典・監査 | 後追いで手作業 | 出力に履歴が同梱 |
個人開発者が同型を作るなら
60ツールは要らない。3〜5個の道具、固定した前提、2〜3本のワークフローがあれば「ミニ・ワークベンチ」は成立する。着手の順番はこうだ。
- 得意分野を1つ選ぶ：会計、法務文書、特定言語のコードレビュー、ゲームのバランス調整など、繰り返しやっている作業ほど向く。
- 「毎回貼る前提」をシステム側へ固定：用語定義・制約・評価基準をプロンプトの土台に埋める（①ドメイン知識）。
- 頻出ツールを事前接続：MCP でその分野のデータ取得や計算をつないでおく（②ツール接続）。
- 検算役を別に置く：出力を鵜呑みにせず、数値や引用を点検する second pass を組む（③検証ループ）。
- 根拠を出力に残す：どのデータ・どの手順で作ったかを結果に添える（④出典・監査）。
③と④を後回しにする個人開発者は多い。動くものが先に欲しいからだ。Claude Science がわざわざレビュワーエージェントと再現パッケージを製品の中核に据えている点は、そこを軽視すると信頼されないという設計判断の表れとして読める。
例えば：筆者の競艇予想AIに当てはめる
筆者が運用する競艇予想AIを、この4部品で組み直すとこうなる。
- ①ドメイン知識：モーター2連率・進入コース別勝率・展示タイムの読み方といった競艇固有の評価基準をシステムプロンプトに固定する。汎用チャットに毎レース説明する手間が消える。
- ②ツール接続：出走表を取得する道具、過去成績を集計する道具、オッズを読む道具を事前配線する。
- ③検証ループ：予想を出したあとに「その根拠データは実在するか」「確率の合計が破綻していないか」を別プロセスで点検する。ここを入れる前は、それらしい数字を自信満々に並べる出力を何度も見た。
- ④出典・監査：予想の各項目に参照したデータ行を添える。外れたときの振り返りが速くなる。
EVE Online の統合ダッシュボードでも構図は同じだ。ゲーム内経済の用語と価格計算のルールを①に固定し、市場APIを②で配線する。ドメインが変わっても、部品の配置は変わらない。
この「まず1分野・3道具・1ワークフローから始めて、使いながら足す」進め方の全体像はバイブコーディングの進め方で整理している。
実際に動いている側の数字を並べる
上は組み直すとしたらの話で、いま動いているものとは別になる。2026年7月31日時点の中身を数えた。
| 部品 | 実体 | 規模 |
|---|---|---|
| ①ドメインデータ | data/boatrace.db（公式のB/Kファイルを取り込んだSQLite） |
374MB |
| ②道具 | core/（特徴量抽出・DB・キャリブレーション）＋ Streamlit 3画面 |
全体で91ファイル・15,716行 |
| ③検証ループ分かれ目 | backtest / ev_backtest / bankroll_sim / calibrate / ablation / retrain_rolling | 検証専用で948行 |
| ④出典 | 取り込み元が公式のB（番組表）・K（結果）ファイル | ingest/ にパーサ2本 |
③に948行を割いている。予想を出す本体とは別に、当たったかどうかを測るコードを書き足していった結果こうなった。
検証ループが「効いていない特徴量」を炙り出した
③の中に ablation.py がある。特徴量を抜いてスコアの変化を見るスクリプトで、出力が ablation_results.csv に残っている。
| 変種 | 特徴量 | ndcg@1 | top1的中率 |
|---|---|---|---|
| Baseline（全32特徴量） | 32 | 0.7563 | 0.6527 |
| 風×コース系6つを除外上がった | 26 | 0.7588 | 0.6563 |
| target encoding 2種を除外 | 30 | 0.7251 | 0.6084 |
| R3で足した分を全部戻す | 24 | 0.7275 | 0.6109 |
2行目が効いている。風とコースを掛け合わせた6つの特徴量を外したほうが、スコアが上がった。足したときは効くと思って足したもので、抜いて測って初めて害だったと分かった。
target encoding の2つは逆で、外すと ndcg@1 が 0.7563 から 0.7251 へ落ちる。こちらは効いている。
どちらも、予想画面を眺めていて気づくものではない。抜いて測るコードを書いたから出た。③検証ループがおもちゃと道具を分けるというのは、こういう具体を指している。
未検証: Claude Science の中身は公開情報の範囲でしか見ていない。上の数字は筆者のアプリの実測で、Claude Science の性能とは無関係になる。
③検証ループと④出典が、おもちゃと道具を分ける
個人開発のドメインAIが「それらしいだけ」で止まる原因の多くは、③と④の欠落にある。汎用LLMは、根拠のない数字や実在しない引用を自信たっぷりに出す。その分野の実務で1回でも間違った出力を信じて損をすると、二度と開かれなくなる。
Claude Science が引用と計算を点検する専用エージェントを持ち、図表に生成コードとメッセージ履歴を丸ごと添える設計にしたのは、この不信を製品側で先に潰すためと読める。個人開発でも縮小版は組める。
# ①本予想 → ②検算 → ③根拠添付、の3段で回す最小構成
def domain_answer(query, context):
draft = llm(system=DOMAIN_RULES, user=query, tools=DATA_TOOLS)
# ③検証ループ: 数値の整合と引用の実在を別プロセスで点検
review = llm(system=REVIEWER_RULES, user=f"検算せよ:\n{draft}")
if review.has_error:
draft = llm(system=DOMAIN_RULES, user=review.fix_hint)
# ④出典: 参照した実データ行を出力に同梱
return attach_sources(draft, used_rows=context.cited_rows)行数は増える。任せられる度合いも上がる。筆者の競艇予想AIでは、この検算段を入れる前と後で、明らかな破綻出力（確率の合計が1を超える等）を見る頻度が体感で大きく減った。数値は取っていないので、そこは要検証と断っておく。
実装で外さないための注意
- 提供範囲を正確に扱う：Claude Science はベータで、Pro / Max / Team / Enterprise 向け、macOS・Linux。手元で試せる範囲は最新情報で確認する（本記事はパターン分析で、製品の細部検証はしていない・未検証）。
- 狭く深く作る：汎用チャットに勝てる余地は「その分野だけ深い」点にある。広く浅い機能を足すほど、汎用モデルとの差が消える。
- 検証を製品の一部にする：出力の正しさを人間の目視だけに頼らない。小さくても自動の検算を組み込むと、その分野の実務で任せられる水準に近づく。
FAQ
Q. 60ツールを揃えないと意味がない？
いいえ。まず3〜5個で成立する。Claude Science の数は最終形であって、出発点ではない。
Q. MCP を使わないと作れない？
必須ではない。前提の固定とワークフローのテンプレ化だけでも汎用チャットとの差は出る。ツール接続は差を広げる次の一手だ。
Q. システムプロンプトを凝るのと何が違う？
プロンプトを凝るのは①ドメイン知識の部分にあたる。ワークベンチはそこに②ツール接続・③検証ループ・④出典を足した構成を指す。①だけでも価値は出るが、実務で任せられる水準に届かせるのは②〜④の積み上げだ。
Q. どの分野から始めると失敗しにくい？
正解の判定が自分でできる分野が向く。競艇なら結果が出れば当否がわかり、会計なら帳簿と突き合わせられる。検証の基準が自分の中にある領域ほど、③検証ループを設計しやすい。
まとめ
Claude Science が示すのは、AIプロダクトの主戦場が「汎用の賢さ」から「特定分野での即戦力」へ移りつつあるという読みだ。巨大な汎用モデルは個人には作れない。得意分野に特化したワークベンチなら、4つの部品を意識するだけで今日から組める。①ドメイン知識を固定し、②道具を配線し、③検算役を置き、④根拠を残す。この順で1分野ずつ積み上げていけば、汎用チャットには真似できない深さが自分の道具箱に貯まっていく。まず自分が一番よく分かっている領域を1つ選ぶところから始めたい。
