Claude Code にヒトとゼブラフィッシュの色覚遺伝子を解析させてみた【実録】

以前からブログの中で、脊椎動物の視物質（オプシン）遺伝子や、塩基配列データベース・アクセッション番号の調べ方について書いてきました。今回はその延長で、配列の取得から比較解析までを、AIエージェント（Claude Code）にどこまで任せられるのかを実際に試してみました。

先に結論を書きます。

「作業」は任せられる。しかし「検証」は任せられない。

この記事は、その線引きをどこに引いたか、実際の手順・スクリプト・つまずいた点も含めてそのまま公開する実録です。バイオインフォマティクスの入門的な内容にもなっているので、AIエージェントの活用に関心がある方にも、色覚の進化に関心がある方にも読んでもらえる構成にしています。

1. 何を調べたいのか（問いの設定）
2. スペクトル調節部位（five-sites）とは
3. 環境
4. まずCLAUDE.mdでルールを縛る
5. 手順1：配列の取得（来歴を必ず残す）
1. 追記：正しいDrer_SWS2への差し替え（2026-09-07）
6. 手順2：取ってきたものが本当にオプシンかを機械的に確認する
7. 手順3：多重アラインメント
8. 手順4：スペクトル調節部位を抜き出す（本題）
1. スクリプト自体の動作確認
2. 本番実行
9. 手順5：系統樹
10. つまずいたところ（AIに任せて危なかった点）
11. わかったこと・次にやりたいこと
参考文献
免責

1. 何を調べたいのか（問いの設定）

エージェントに作業を投げる前に、まず自分の中で問いをはっきりさせておく必要があります。ここが曖昧なままだと、AIは「もっともらしい作業」を延々と続けてしまうからです。

今回立てた問いは、次の2つでした。

ヒトの赤オプシンと緑オプシンは、なぜあれほど似ているのに、見える色が違うのか。
そして、ゼブラフィッシュは同じ問題をどう解いているのか。

ヒトはL（赤）・M（緑）・S（青）の3種類の錐体オプシンを持ちます。LとMはX染色体上で隣り合っており、配列は驚くほどよく似ています。赤緑色覚異常がヒトに多いのは、この「似すぎている」構造と無関係ではありません。

一方、ゼブラフィッシュはまったく異なる構成をしています。

種類	ゼブラフィッシュの遺伝子	λmax（吸収極大）
UV（SWS1）	`opn1sw1`	約355 nm
青（SWS2）	`opn1sw2`	約416 nm
緑（RH2）	`opn1mw1` / `opn1mw2` / `opn1mw3` / `opn1mw4`	467 / 476 / 488 / 505 nm
赤（LWS）	`opn1lw1` / `opn1lw2`	558 / 548 nm
桿体（RH1）	`rho`	－

（λmaxはOgawa & Corbo, 2021による）

緑オプシンが4つ、赤オプシンが2つ、さらに紫外線を見る錐体まである。ヒトが3色型なのに対し、ゼブラフィッシュは紫外線を含む4色型です。同じ脊椎動物なのに、これほど設計が違うのは単純に面白いと感じます。

今回の目標を、次の3つに絞りました。

ヒトとゼブラフィッシュの視物質タンパク質配列を、来歴つきで取得する
多重アラインメントを作り、系統関係を見る
スペクトル調節部位（five-sites）の残基を、種を跨いで並べて比較する

3番目が今回の本題です。

2. スペクトル調節部位（five-sites）とは

M/LWS型オプシンでは、たった5か所のアミノ酸の違いが吸収波長（λmax）をほぼ加算的に動かすことが知られています。これが「five-sitesルール」です。

置換	λmaxのシフト（青方向）
S180A	約−7 nm
H197Y	約−28 nm
Y277F	約−8 nm
T285A	約−15 nm
A308S	約−27 nm

（Yokoyamaら, 2008の多重回帰による推定値。文献により数値には幅があります）

さらに、ヒトを含む類人猿では197番と308番が単型（H197・A308に固定）であるため、実質的に180・277・285の「three-sitesルール」に縮約されます。

つまり、ヒトの赤と緑の違いは、364アミノ酸のうちのたった3か所でおおむね説明がついてしまいます。これを自分の手元のデータで確認する、というのが今回のゴールです。

3. 環境

Windows 11 Pro + WSL2（Ubuntu）※ Fedora Serverでも同じ手順で動きます
Python 3.12 / Biopython
MAFFT（多重アラインメント）
IQ-TREE（系統樹）
Claude Code

mkdir -p ~/opsin/{scripts,data,results} && cd ~/opsin
python3 -m venv .venv && source .venv/bin/activate
pip install biopython

# Ubuntu / WSL2
sudo apt install mafft iqtree
# Fedora
# sudo dnf install mafft iqtree

補足：今回の実行環境ではsudoにパスワードが必要でaptが使えなかったため、ユーザー権限でMiniforge（conda）を導入し、bioconda経由でMAFFT・IQ-TREEを取得しました。sudo権限がないサーバーやコンテナでも同じ手順で再現できます。

“`bash
curl -sL -o miniforge.sh https://github.com/conda-forge/miniforge/releases/latest/download/Miniforge3-Linux-x86_64.sh
bash miniforge.sh -b -p ./miniforge3
./miniforge3/bin/mamba install -y -p ./miniforge3 -c bioconda -c conda-forge mafft iqtree
“`

NCBIに問い合わせるため、規約上メールアドレスの設定が必要です。APIキーは任意ですが、あると秒間リクエスト数の上限が緩和されます。

export NCBI_EMAIL="your@example.com"
export NCBI_API_KEY="..."   # 任意

4. まずCLAUDE.mdでルールを縛る

ここが今回いちばん重要なポイントでした。

配列データを扱う作業で、AIに一番やらせてはいけないのは「それらしい値の捏造」です。

そこで作業ディレクトリのCLAUDE.mdに、最初に次のルールを書きました。

# 作業ルール（厳守）

## 絶対禁止
- 塩基配列・アミノ酸配列を、自分の記憶から書き出さないこと。
  配列は必ずNCBIから取得したファイルの中身のみを使う。
- アクセッション番号を推測で書かないこと。検索結果に出たものだけを使う。
- 解析結果（同一性、λmax、残基）を、実行していない状態で先回りして書かないこと。
- 数値を本文に書くときは、必ずそれを出力したコマンドを併記すること。

## 必須
- 取得した配列はdata/manifest.tsvに
  ラベル・種・遺伝子シンボル・accession.version・長さ・md5を必ず記録する。
- 検索が複数ヒットした場合は、勝手に1件目を採用せず候補件数を報告する。
- スクリプトはdata/を書き換えない。出力はresults/に置く。
- 各ステップの標準出力はresults/log/にteeで保存する。

「配列を記憶から書くな」というルールは、大げさに見えて実は必須です。言語モデルは配列らしい文字列をいくらでも生成できてしまうため、明示的に禁止しておかないと検証工程が丸ごと無意味になります。

5. 手順1：配列の取得（来歴を必ず残す）

scripts/fetch_opsins.py です。ヒト4種・ゼブラフィッシュ9種・外群としてウシのロドプシンを、NCBIのRefSeqから取得します。

#!/usr/bin/env python3
"""NCBIからRefSeqの視物質タンパク質配列を取得し、来歴(manifest)を必ず残す。
生成物: data/opsins.faa, data/manifest.tsv
"""
import hashlib, os, sys, time
from Bio import Entrez, SeqIO

Entrez.email   = os.environ.get("NCBI_EMAIL")    # 必須
Entrez.api_key = os.environ.get("NCBI_API_KEY")  # 任意

TARGETS = [
    ("Hsap_LWS",   "Homo sapiens", "OPN1LW"),
    ("Hsap_MWS",   "Homo sapiens", "OPN1MW"),
    ("Hsap_SWS1",  "Homo sapiens", "OPN1SW"),
    ("Hsap_RH1",   "Homo sapiens", "RHO"),
    ("Drer_LWS1",  "Danio rerio",  "opn1lw1"),
    ("Drer_LWS2",  "Danio rerio",  "opn1lw2"),
    ("Drer_RH2-1", "Danio rerio",  "opn1mw1"),
    ("Drer_RH2-2", "Danio rerio",  "opn1mw2"),
    ("Drer_RH2-3", "Danio rerio",  "opn1mw3"),
    ("Drer_RH2-4", "Danio rerio",  "opn1mw4"),
    ("Drer_SWS1",  "Danio rerio",  "opn1sw1"),
    ("Drer_SWS2",  "Danio rerio",  "opn1sw2"),
    ("Drer_RH1",   "Danio rerio",  "rho"),
    ("Btau_RH1",   "Bos taurus",   "RHO"),   # 外群 兼 残基番号の基準
]
# （検索・取得・manifest出力の詳細は割愛。全文はスクリプト参照）

mkdir -p results/log
python3 scripts/fetch_opsins.py 2>&1 | tee results/log/01_fetch.log

実行結果（2026-09-07 実施、NCBI_EMAIL を設定して実行）

$ python3 scripts/fetch_opsins.py 2>&1 | tee results/log/01_fetch.log
Hsap_LWS	NP_064445	364aa	候補1件
Hsap_MWS	NP_000504	364aa	候補1件
Hsap_SWS1	NP_001372054	345aa	候補1件
Hsap_RH1	NP_000530	348aa	候補1件
Drer_LWS1	NP_001300644	357aa	候補1件
Drer_LWS2	NP_001002443	356aa	候補1件
Drer_RH2-1	NP_571328	349aa	候補1件
Drer_RH2-2	NP_878311	349aa	候補1件
Drer_RH2-3	NP_878312	349aa	候補1件
Drer_RH2-4	NP_571329	349aa	候補1件
Drer_SWS1	NP_571394	336aa	候補1件
Drer_SWS2	NP_571394	336aa	候補6件
Drer_RH1	NP_571159	354aa	候補1件
Btau_RH1	NP_001014890	348aa	候補1件

14件すべて取得はできましたが、Drer_SWS2（青オプシン opn1sw2）で重大な取り違えを検出しました。

Drer_SWS2 の検索結果は「候補6件」と表示されているにもかかわらず、スクリプトはロジックどおり1件目 NP_571394 を採用。
ところがこの NP_571394 は Drer_SWS1（UVオプシン opn1sw1）が採用したのと全く同一のアクセッションであり、配列のmd5ハッシュも完全一致（acd73e6315d7ca27fa64590bdec7e568）。
NCBIで NP_571394 を確認したところ、実体は "opsin-1, short-wave-sensitive 1 [Danio rerio]"（= opn1sw1、UVオプシン）そのものでした。
原因はNCBIの esearch における [Gene Name] フィールドが完全一致ではなく緩いテキストマッチである点。opn1sw2 で検索しても、opn1sw1 の説明文にヒットしてしまう挙動が確認されました。
これはまさに記事本文で警告している「候補件数を報告させ、2件以上なら手を止める」ルールが機能した実例です。実際、Drer_SWS2 を本番の比較対象に使うのは危険であり、five-sites抽出の対象からは除外、または正しいアクセッションを人手でNCBIから再確認する必要があります。

確認ポイント：「候補N件」が1でないターゲットは、必ず自分の目でNCBIのページを開いて選び直します。ここを「1件目でいいや」と流すと、その後の解析がすべて別物になります。今回の Drer_SWS2 はまさにこのケースで、実際に別物（opn1sw1）を掴んでいました。

追記：正しいDrer_SWS2への差し替え（2026-09-07）

CEOの承認を得て、NCBIを人手で確認し、正しいアクセッションに差し替えました。手順は次のとおりです。

# NCBI gene DBで opn1sw2 の遺伝子IDを検索（esearchの緩いマッチを避けるため gene DB を直接見る）
curl -s "https://eutils.ncbi.nlm.nih.gov/entrez/eutils/esearch.fcgi?db=gene&term=opn1sw2%5BGene+Name%5D+AND+Danio+rerio%5BOrganism%5D&retmode=json"
# → 2件ヒット（gene_id 30582, 30435）

2件の内訳をesummaryで確認すると、取り違えの本当の原因がわかりました。

gene_id	name	otheraliases
30582	`opn1sw1`	SWS1, opn1sw2（廃止済みエイリアス）, uvops, zfuv
30435	`opn1sw2`	SI:zK13A21.5, SWS2, bluops, zfblue

つまり opn1sw1 の遺伝子レコードには、歴史的な旧称として opn1sw2 という廃止済みエイリアスが登録されたまま残っていました。esearchの[Gene Name]は現行シンボルだけでなくこの旧エイリアスにもヒットするため、opn1sw2で検索すると本来無関係なopn1sw1のレコードが紛れ込みます。しかもこのopn1sw1エントリのRefSeqタンパク質（NP_571394）がリレバンス順で1位に来てしまい、スクリプトの「1件目採用」ロジックがそのまま誤爆した、というのが今回の全容です。

正しい遺伝子ID30435からelinkでRefSeqタンパク質を辿ると、キュレーション済み（PREDICTEDでない）のエントリはNP_571267（354aa、"opsin-1, short-wave-sensitive 2 [Danio rerio]"）の1件でした。他のゼブラフィッシュオプシン（336〜357aa）と長さの水準も揃っており、妥当と判断しました。

修正後のmanifest.tsv（該当行）:

label	species	symbol	accession_version	length	md5	n_candidates
Drer_SWS2	Danio rerio	opn1sw2	NP_571267	354	55b5f736e6810ebf3c555b8d93d7d329	2

（n_candidatesは「gene DBでopn1sw2をキーに検索した結果の件数」＝2に修正。うち1件は上記の廃止エイリアスによる誤ヒットです。）

この一件から得られる教訓は、「候補が複数出たら手を止める」ルールだけでは足りず、遺伝子シンボル検索は廃止済みエイリアスが原因で複数ヒットすることがあり、[Gene Name]のテキストマッチを疑ったら、taxonomy/gene DBのotheraliasesまで遡って確認する必要がある、という点です。今回はエージェントが検出した「異常（候補6件）」を人間が起点にNCBIを深掘りしたことで、単なる再検索ではなく原因の特定まで到達できました。

6. 手順2：取ってきたものが本当にオプシンかを機械的に確認する

エージェントが遺伝子を取り違えていないかを、人間の目ではなくコードで確認します。

scripts/verify_records.py は、長さ・開始残基・内部終止コドンの有無に加え、クラスA GPCRに広く保存されたモチーフ（(D/E)R(Y/W) と NPxxY）を持つかをチェックします。

python3 scripts/verify_records.py data/opsins.faa | tee results/log/02_verify.log

実行結果（2026-09-07 実施）

$ python3 scripts/verify_records.py data/opsins.faa | tee results/log/02_verify.log
Hsap_LWS	364aa	OK
Hsap_MWS	364aa	OK
Hsap_SWS1	345aa	OK
Hsap_RH1	348aa	OK
Drer_LWS1	357aa	OK
Drer_LWS2	356aa	OK
Drer_RH2-1	349aa	OK
Drer_RH2-2	349aa	OK
Drer_RH2-3	349aa	OK
Drer_RH2-4	349aa	OK
Drer_SWS1	336aa	OK
Drer_SWS2	336aa	OK
Drer_RH1	354aa	OK
Btau_RH1	348aa	OK

14件全てが長さ・開始残基・GPCR保存モチーフのチェックをクリアしました（Drer_SWS2 も含む）。ここが今回の重要な学びで、「オプシンとして妥当かどうか」の機械チェックは、「どのオプシンなのか」という取り違えを検出できません。Drer_SWS2（実体はopn1sw1）は正真正銘のオプシンなので、このチェックでは何の異常も出ません。手順1の「候補件数」チェックと、手順2の「配列として妥当か」チェックは、別の種類のミスを検出するための独立した仕組みであることが、実際に手を動かしてはっきりわかりました。

7. 手順3：多重アラインメント

mafft --localpair --maxiterate 1000 --reorder data/opsins.faa \
  > results/opsins_aln.faa 2> results/log/03_mafft.log

配列数が14と少ないので、精度重視のL-INS-i（--localpair --maxiterate 1000）を使いました。数百配列を扱う規模になったら --auto に切り替えます。

実行結果（2026-09-07 実施、MAFFT v7.526）

$ mafft --localpair --maxiterate 1000 --reorder data/opsins.faa > results/opsins_aln.faa
（省略）
Converged.
done
dvtditr (aa) Version 7.526
alg=A, model=BLOSUM62, 1.53, -0.00, -0.00, noshift, amax=0.0

14配列すべてがアラインメントされ、results/opsins_aln.faaが生成されました。MAFFT・IQ-TREEは、本作業環境にはaptでのsudo権限がなかったため、ユーザー権限でMiniforge（conda）を導入し、そこからbioconda経由でMAFFT 7.526・IQ-TREE 3.1.3を取得しました。sudoが使えない開発環境でも、パッケージマネージャーをユーザー領域に構築すれば同じ手順が再現できます。

8. 手順4：スペクトル調節部位を抜き出す（本題）

アラインメントの「列番号」と、論文が使う「残基番号」は一致しません。ここを取り違えると結論が丸ごと壊れます。そこで基準配列の残基番号 → アラインメント列の対応表を作ってから抜き出す設計にしました。

scripts/map_sites.py です。

#!/usr/bin/env python3
"""アラインメント上で、基準配列の残基番号に対応する列を各配列から抜き出す。
使い方: python3 map_sites.py aligned.faa REF_ID 180,197,277,285,308
"""
import sys
from Bio import AlignIO

def ref_pos_to_col(ref_seq):
    """基準配列の1-based残基番号 -> アラインメント列インデックス"""
    table, pos = {}, 0
    for col, ch in enumerate(str(ref_seq)):
        if ch != "-":
            pos += 1
            table[pos] = col
    return table
# （抜き出しロジックの詳細は割愛。全文はスクリプト参照）

スクリプト自体の動作確認

いきなり本番データに当てず、ギャップを跨いでも番号がずれないかを合成データで先に確認しました。

python3 scripts/map_sites.py test/toy.faa REF 9,10,38,50

実行結果（2026-09-07 実施）

$ python3 scripts/map_sites.py test/toy.faa REF 9,10,38,50
id      9(9)    10(10)  38(38)  50(50)
REF     T       G       T       T
A       -       -       T       T
B       T       G       A       T

REFの9・10番目に対応する位置でAはギャップ、38番目でBだけT→Aになっており、期待どおりの結果が得られました（このテスト配列はダミーで、オプシンとは無関係です）。ギャップを跨いでも残基番号がずれない実装であることを確認できました。

本番実行

# five-sites（ヒトM/LWSの残基番号を基準にする）
python3 scripts/map_sites.py results/opsins_aln.faa Hsap_LWS 180,197,277,285,308 \
  | tee results/five_sites.tsv

# レチナールが結合するシッフ塩基のリシン（ウシロドプシンK296基準）
python3 scripts/map_sites.py results/opsins_aln.faa Btau_RH1 113,296 \
  | tee results/schiff_base.tsv

実行結果（2026-09-07 実施、Drer_SWS2修正後のデータで実行）

$ python3 scripts/map_sites.py results/opsins_aln.faa Hsap_LWS 180,197,277,285,308 | tee results/five_sites.tsv
id	180(187)	197(204)	277(284)	285(292)	308(315)
Hsap_LWS	A	H	Y	T	A
Hsap_MWS	A	H	F	A	A
Drer_LWS1	A	H	Y	T	A
Drer_LWS2	A	H	F	T	A
Hsap_SWS1	G	E	F	A	S
Drer_SWS1	G	E	F	A	A
Hsap_RH1	A	E	F	A	A
Btau_RH1	A	E	F	A	A
Drer_RH1	A	E	F	A	A
Drer_RH2-1	A	E	F	A	A
Drer_RH2-2	A	E	F	A	A
Drer_RH2-3	A	E	F	A	A
Drer_RH2-4	A	E	F	A	A
Drer_SWS2	A	E	F	A	S

$ python3 scripts/map_sites.py results/opsins_aln.faa Btau_RH1 113,296 | tee results/schiff_base.tsv
id	113(136)	296(319)
Hsap_LWS	E	K
Hsap_MWS	E	K
Drer_LWS1	E	K
Drer_LWS2	E	K
Hsap_SWS1	E	K
Drer_SWS1	E	K
Hsap_RH1	E	K
Btau_RH1	E	K
Drer_RH1	E	K
Drer_RH2-1	E	K
Drer_RH2-2	E	K
Drer_RH2-3	E	K
Drer_RH2-4	E	K
Drer_SWS2	E	K

事前に立てた予想は次のとおりでした。答え合わせをします。

Hsap_LWS は180・277・285が S / Y / T（λmax約560 nmの側）
Hsap_MWS は同じ位置が A / F / A（λmax約530 nmの側）
197と308はヒトのLとMで差が出ない（＝three-sitesルールに縮約される）
Btau_RH1 の296番はすべての配列で K（保存されているはず）

結果は「一部的中、一部予想はずれ」でした。

277番（Y/F）と285番（T/A）は予想どおり、Hsap_LWSとHsap_MWSではっきり分かれました。
197・308も予想どおり両者で差が出ず、three-sitesルールへの縮約が確認できました。
180番は予想が外れました。 Hsap_LWSは事前予想ではSのはずが、実際にはHsap_MWSと同じAでした。
296番（シッフ塩基のリシン）は予想どおり全14配列でK固定でした。

180番の食い違いは、手順や番号の取り違えではなく、参照配列の選び方の問題でした。文献上のS180Aは「ヒト集団内の多型」（人によってSまたはAどちらもありうる）であり、S/Aどちらが「標準」というわけではありません。今回fetch_opsins.pyが取得したNCBIのRefSeq代表配列（NP_064445）はたまたまAバリアントだったため、Hsap_MWS（NP_000504）と180番で差が出ませんでした。実際、NP_064445のGenBankレコードには”Polymorphism in red photopigment underlies variation in colour matching”という文献が引用されており、この遺伝子座が多型であることが裏付けられます。

教訓: five-sitesルールのような「既知の対立に基づく予想」を検証するときは、比較対象の配列がどのアレル（多型のどちら側）を代表しているかを確認しないと、単一のRefSeq配列同士の比較だけでは再現できないことがあります。180番についてはこの記事の結論を「S180Aは典型的にはLとMの差の一因だが、今回参照した具体的なNCBI代表配列同士では180番に差が出なかった（両方Aバリアント）」と修正します。277・285番の差、および three-sites ルールへの縮約は、当初予想どおり明確に確認できました。

9. 手順5：系統樹

# 導入したIQ-TREEのバージョンにより実行コマンド名は iqtree2 / iqtree3 のいずれか
iqtree3 -s results/opsins_aln.faa -m MFP -B 1000 -T AUTO \
  --prefix results/opsin_tree 2>&1 | tee results/log/05_tree.log

ここで見たいのは、ゼブラフィッシュの4つの緑オプシン（RH2群）が、ヒトの緑オプシンと同じ枝にいるのかどうかです。名前が「緑」でも、由来は別系統。RH2とM/LWSは遺伝子ファミリーとして異なります。「緑を見る」という機能が、まったく別の道具立てで実現されているわけです。

実行結果（2026-09-07 実施、IQ-TREE 3.1.3）

$ iqtree3 -s results/opsins_aln.faa -m MFP -B 1000 -T AUTO --prefix results/opsin_tree
（省略）
Best-fit model according to BIC: LG+F+G4
BEST SCORE FOUND : -5201.960
Analysis results written to:
  Maximum-likelihood tree:       results/opsin_tree.treefile
  Consensus tree:                results/opsin_tree.contree

得られた系統樹（超高速ブートストラップ1000回、UFBoot支持率つき）は次のとおりです。

結果は事前予想と完全に一致しました。

Drer_RH2-1〜RH2-4（ゼブラフィッシュの4つの緑オプシン）は、UFBoot支持率98〜100%の強いサポートで一つのクレードにまとまり、RH1（桿体ロドプシン、ヒト・ウシ・ゼブラフィッシュ）に近い側の大きな枝に位置しました。
一方、ヒトのHsap_LWS・Hsap_MWSと、ゼブラフィッシュのDrer_LWS1・Drer_LWS2は、これらとは完全に別のクレード（枝の根本から離れた位置）にまとまっています。
つまり「ゼブラフィッシュの緑オプシン（RH2）」と「ヒト・ゼブラフィッシュの赤オプシン（LWS/M）」は、名前の色のイメージとは裏腹に、遺伝子系統としては遠縁であることが視覚的にも裏付けられました。RH2群はむしろRH1（桿体）に近い遺伝子ファミリーに属します。
Hsap_SWS1とDrer_SWS1（ともにUVまたは青紫オプシン）は、UFBoot 98%でひとつのクレードを形成し、Drer_SWS2（青オプシン、今回修正後の正しい配列）はこれらよりもRH1/RH2側に近い位置にありました。SWS1とSWS2は同じ「短波長感受性」でも別サブファミリーであることが確認できます。
Hsap_LWSとDrer_LWS1/Drer_LWS2は同じクレード内にまとまり（支持率99%）、M/LWS遺伝子ファミリーがヒト・魚類を通じて保存された単一起源であることが示されました。

本文2節で立てた「RH2とM/LWSは遺伝子ファミリーとして異なる」という予想は、系統樹上ではっきりと裏付けられた形です。

10. つまずいたところ（AIに任せて危なかった点）

実際に手を動かしてみると、うまくいかない箇所には偏りがありました。

① 番号体系の取り違え オプシンの論文には「ウシロドプシン番号」と「ヒトM/LWS番号」が混在します。エージェントは、指示しないとこの2つを平気で混ぜてしまいます。どの配列を基準に何番を見るのかを、コマンドの引数として明示する設計にしたのは、この対策です。

② 「1件目採用」の危うさ 遺伝子シンボル検索は、アイソフォーム・予測配列・別種のホモログを拾ってしまいます。ここを自動で1件目に決めさせると、後の全工程が静かにずれます。候補件数を必ず出力させ、2件以上なら手を止める、というルールにしました。

③ 実行していない結果を書き始める 「じゃあ結果をまとめますね」と、まだ動かしていない解析の結論めいた文章を書き始めることがあります。CLAUDE.mdの「数値には必ずコマンドを併記」というルールは、これを止めるためのものです。

④ 中間ファイルの上書き data/ を読み取り専用の置き場と決め、出力は results/ に限定しました。取得のやり直しは通信を伴うため、ここを守るだけでも作業が安定します。

逆に、任せてよかったのは以下です。

Biopython のEntrezまわりの定型コード
ギャップを考慮した番号マッピングのような、間違えやすい細かい実装
合成データでのテストケースづくり
ログとマニフェストを残す仕組みの整備

つまり、「手が速い」ところは任せられ、「合っているかを決める」ところは任せられない。今回いちばんはっきりしたのはこの点でした。

11. わかったこと・次にやりたいこと

ヒトの赤と緑は、わずか数か所のアミノ酸で分かれています。似すぎているからこそ組換えが起きやすく、赤緑色覚異常につながる。裏を返せば、ヒトの3色型色覚はかなり際どい構成の上に成り立っているとも言えます。

一方のゼブラフィッシュは、紫外線を含む4種類の錐体に加え、緑と赤を複数の遺伝子で分担しています。網膜の場所や発生段階によって使い分けているという報告もあります。ヒトが「3つで足りるように調整した」のに対し、ゼブラフィッシュは「たくさん持って割り当てた」といえそうです。

次は、以下を試したいと考えています。

CDS（塩基配列）レベルでdN/dSを計算し、選択圧を見る
ヒトL/M遺伝子の周辺配列を取得し、組換えが起きやすい構造を確認する
各オプシンの構造予測を並べ、five-sitesがレチナール結合ポケットのどこに位置するかを見る

参考文献

Yokoyama S, Radlwimmer FB. *The “five-sites” rule and the evolution of red and green color vision in mammals.* Mol Biol Evol. 1998. https://pubmed.ncbi.nlm.nih.gov/9580985/
Yokoyama S, Yang H, Starmer WT. *Molecular basis of spectral tuning in the red- and green-sensitive (M/LWS) pigments in vertebrates.* Genetics. 2008. https://pubmed.ncbi.nlm.nih.gov/18660543/
Ogawa Y, Corbo JC. *Partitioning of gene expression among zebrafish photoreceptor subtypes.* Sci Rep. 2021. https://www.nature.com/articles/s41598-021-96837-z
Yokoyama S. *Evolution of dim-light and color vision pigments.* Annu Rev Genomics Hum Genet. 2008.

免責

本記事は個人の学習・研究の記録です。医学的な診断や助言を目的としたものではありません。配列データベースの内容は更新されるため、再現の際はmanifest.tsvに記録したaccession.versionをご確認ください。

Post Views: 21