tamarind

Tamarind Bio

Tamarind Bioは、構造予測、タンパク質および抗体の設計、ドッキング、結合親和性評価、MSA生成、分子動力学などの計算生物学ツールを、管理されたGPU上で実行するクラウドプラットフォームです。ユーザーは配列や構造を送信するだけで、自前のハードウェアを用意することなく、予測構造、設計案、生物物理学的スコアを取得できます。AlphaFold、Boltz-2、Chai-1、RFdiffusion、ProteinMPNN、BoltzGen、ESMFold2、DiffDock、Autodock Vinaなど、数百のツールを統一されたジョブAPIで提供しています。

公式ドキュメント： app.tamarind.bio/api-docs · プラットフォームのUIは app.tamarind.bio

正規の情報源 — 古いコピーに頼らず、こちらを取得してください

Tamarindは、最新の機械可読な情報源を公開しています。ツール名、スキーマ、エンドポイントは頻繁に変更されるため、ハードコードされたリストを信用するのではなく、実行時に取得してください。

• https://app.tamarind.bio/llms.txt — LLMインデックス：仕様、APIドキュメント、MCPガイドへのリンクです。
• https://app.tamarind.bio/openapi.yaml — 主要な8つのジョブエンドポイント（submit-job/-batch、jobs、result、upload、files、delete-job/-file；認証は ApiKeyAuth）を対象としたOpenAPI 3.0仕様です。正確な形式を確認するには、こちらを取得してください。検出／管理エンドポイント（/tools、/usage-statistics、パイプラインなど）は含まれていないため、MCP／RESTの検出ツールを使用してください。
• https://docs.tamarind.bio/llms.txt — ドキュメントのインデックスです。各ページには .md 形式があります（例：docs.tamarind.bio/tamarind/batch.md、/tamarind/api.md、/tamarind/pipelines.md）。
• ライブツール検出 — GET /tools（REST）、またはMCPの getAvailableTools と getJobSchema(jobType) が、利用可能なツールとそのパラメーターに関する信頼できる情報源です。

このスキルでは、これらの情報源に明記されていない、基本的な操作方法と注意すべき挙動を解説します（参考ファイルを参照）。形式に迷った場合は、openapi.yaml を取得してください。

このスキルを使う場面

次のような場合にTamarindを使用してください。

• タンパク質、複合体、またはタンパク質とリガンドの系の構造を予測する（AlphaFold、Boltz-2、Chai-1、ESMFold2、Chai／Boltzによる共折りたたみ）
• タンパク質または結合分子を設計する（RFdiffusion、BoltzGen、BindCraft、ProteinMPNN／LigandMPNNによる逆フォールディング）
• 抗体／ナノボディを設計または特性評価する（配列生成、ヒト化、開発適性、免疫原性）
• 低分子をタンパク質にドッキングする（DiffDock、Autodock Vina）、または結合親和性を予測する
• 下流のフォールディング処理に使うMSAを生成する
• 管理されたGPU上で分子動力学やその他の生物物理学的ワークフローを実行する
• 同じツールで多数の配列や設計案をバッチスクリーニングする
• ツールをパイプラインに連結する（例：設計 → フォールディング → スコア評価）。前のジョブの出力を次のジョブの入力として使用します。

このスキルは、ローカルインストールではなく、Tamarindの管理するクラウド上で処理を実行したい場合に適しています。ローカルでのケモインフォマティクスや、単発の配列入出力には、代わりにローカルライブラリ（RDKit、BioPython）を使用してください。

アクセスと認証

1. app.tamarind.bio にサインインし、アカウント／API設定からAPIキーを作成します。
2. RESTリクエストにはすべて、x-api-key ヘッダーを付けて認証します。
3. キーをハードコードしないでください。 TAMARIND_API_KEY 環境変数または .env ファイルから読み込みます（python-dotenv を使用）。キーをソース管理にコミットしないでください。

料金： すべてのユーザーに無料ジョブ10件が付与されます。さらに利用する場合は、サブスクリプションの購入について [email protected] にお問い合わせください。

export TAMARIND_API_KEY="your_api_key"
# List available tools
curl https://app.tamarind.bio/api/tools \
  -H "x-api-key: $TAMARIND_API_KEY"

ベースURL： https://app.tamarind.bio/api/

公式Python SDKはありません。PyPIにある tamarind という名前のパッケージは、無関係なNeo4jツールです。uv pip install tamarind は実行しないでください。REST APIに対して通常の requests 呼び出しを記述するか（エンドポイントの形式は openapi.yaml に記載されています）、エージェントホストにはMCPサーバーを使用してください。

Tamarindを呼び出す2つの方法

MCP サーバー（AI エージェントに最適）

Tamarind は https://mcp.tamarind.bio/mcp で MCP サーバーをホストしています（X-API-Key ヘッダーによる API キー認証）。エージェントのホストが MCP に対応している場合は、MCP サーバーを優先してください。ツールはエージェント向けのスキーマで REST API を反映しています。

• listModalities() / listTags() — ラベルとツール数を含む、最新のフィルター用語（分子の種類／機能）。有効な modality／function の値を把握するために呼び出し、ハードコードは避けてください
• getAvailableTools(modality?, function?, search?, custom?) — ツールを検出します（category／tag は非推奨のエイリアスですが、引き続き利用できます）
• getJobSchema(jobType) — ツールの正確なパラメータースキーマと、開始用ペイロード exampleJob を返します（送信前に検証してください）
• validateJob(jobName, type, settings) — 送信前にドライランで検証します
• submitJob(jobName, type, settings) / submitBatch(batchName, type, settings[], jobNames[])
• getJobs(jobName?, batch?, limit?, includeSequences?) — ジョブとステータスを一覧表示／確認します（ジョブごとの大きな入力データはデフォルトで省略されます。保持するには includeSequences=true を渡してください）
• getJobLogs(jobName) — デバッグ用に出力ログを取得します
• listJobFiles(jobName) — 出力ファイルを一覧表示します（連鎖処理用に s3Path を返します）
• getResult(jobName, fileName?) — 結果をダウンロードします
• uploadFile(filename) — 署名付きアップロード URL を返します。または、ホストから S3 にアクセスできない場合（サンドボックス内のエージェント）は、uploadFileContent(filename, content, encoding?) で MCP 経由でファイルの内容を送信できます

スコープに関する注意：MCP のクエリツール（getJobs、getResult、listJobFiles など）の対象は、認証済みアカウントに限定されます。

REST API（汎用）

requests を使って通常の HTTP リクエストを送信します。エンドポイントの形式は openapi.yaml に記載されています。基本的な一連の処理は以下のとおりです。詳しいレシピは references/workflows.md を参照してください。

基本的なワークフロー

必ず discover → schema → validate → submit → poll → results の順に進めてください。ツール名や設定をハードコードしないでください。カタログは頻繁に更新されます。

import os, time, requests

BASE = "https://app.tamarind.bio/api"
HEADERS = {"x-api-key": os.environ["TAMARIND_API_KEY"]}

# 1. Discover tools. REST /tools returns the full list; filter client-side.
tools = requests.get(f"{BASE}/tools", headers=HEADERS).json()
alphafold = next(t for t in tools if t["name"] == "alphafold")

# 2. Get the exact schema for the chosen tool.
#    REST: each /tools entry already includes its inline `settings` schema
#          (parameter list) — find the entry whose name == your job type.
#    MCP:  getJobSchema(jobType) returns the same per-tool detail.

# 3. Submit a job. `settings` is tool-specific — match the schema exactly.
payload = {
    "jobName": "my-alphafold-run",          # ^[a-zA-Z0-9_-]+$, <=100 chars, unique
    "type": "alphafold",
    "settings": {
        "sequence": "MKTVRQERLKSIVRILERSKEPVSGAQLAEELSVSRQVIVQDIAYLRSLGYNIVATPRGYVLAGG",
        "numRecycles": 3,
    },
}
resp = requests.post(f"{BASE}/submit-job", headers=HEADERS, json=payload)
resp.raise_for_status()   # 200 ok; 400 bad request; 403 budget exceeded; 401 unauthorized

# 4. Poll for completion.
#    NOTE the response shape: GET /jobs?jobName=<name> returns the job ROW
#    directly (no "jobs" wrapper); the list query (no jobName) returns
#    {"jobs": [...]}. Don't index ["jobs"][0] on the by-name response.
while True:
    job = requests.get(f"{BASE}/jobs", headers=HEADERS,
                       params={"jobName": "my-alphafold-run"}).json()
    if job["JobStatus"] in ("Complete", "Stopped", "Deleted"):
        break
    time.sleep(30)

# 5. Retrieve results. POST /result returns a presigned URL *string*;
#    GET that URL to download the actual results zip (two-step).
url = requests.post(f"{BASE}/result", headers=HEADERS,
                    json={"jobName": "my-alphafold-run"}).text.strip('"')
open("my-alphafold-run.zip", "wb").write(requests.get(url).content)

MCP ツールを使ったこの一連の処理のエージェント版と、より詳しい例については、references/workflows.md を参照してください。

ツールの検出

カタログには数百のツールがあります。必ず実行時に列挙し、ハードコードされたリストに依存しないでください。

REST GET /tools は全リストを返します（サーバー側ではフィルタリングされません）。各項目は {name, displayName, github, paper, description, settings} で、settings はそのツールのインラインパラメータースキーマです。クライアント側でフィルタリングしてください。

tools = requests.get(f"{BASE}/tools", headers=HEADERS).json()   # a list
boltz = [t for t in tools if "boltz" in t["name"].lower()]

注意：どちらのインターフェースもツール名ごとに1行を返します。REST /tools と MCP getAvailableTools はどちらも重複を排除します（MCP は最新のツールバージョンを保持するため）。したがって、名前が一致した場合は1行だけ返されます。

MCP getAvailableTools(search=..., modality=..., function=...) はサーバー側でフィルタリングし、各ツールに categories／tags を追加します（category／tag は modality／function の非推奨エイリアスですが、引き続き利用できます）。用語をハードコードしないでください。用語は変わるためです。最新の値は listModalities()／listTags() から取得してください（各関数は value、label、description、toolCount を返します）。または、getAvailableTools の各レスポンスに含まれる availableCategories／availableTags のファセット配列を参照してください。モダリティは分子の種類（protein、antibody、peptide、small-molecule、nucleic-acid など）、機能はツールが実行する処理（structure-prediction、binder-design、protein-ligand-docking など）を表します。

広く使われているツールの代表例を以下に示します（/tools で確認してください）：alphafold、boltz（Boltz-2）、chai（Chai-1）、esmfold／esmfold2、rfdiffusion、proteinmpnn、ligandmpnn、boltzgen、bindcraft、diffdock。カテゴリ／タグの全マップとツールメタデータの読み方については、references/tool_catalog.md を参照してください。

適切なツールの選び方

カタログにはタスクごとに多くのツールがあります。お気に入りのツールをハードコードせず、function（および modality）で絞り込んでから、候補ごとの description を読み、ユーザーの実際の目標に照らして選んでください（手元にある入力、必要な出力、速度や「MSA なし」などの制約）。description フィールドと tags フィールドは、ツールの用途を示す公開情報です。それらと validateJob を基に選択してください。タスクごとの簡単なガイドは次のとおりです。

• 単一タンパク質／複合体をフォールディングする（function=structure-prediction）：AlphaFold3 クラスの再実装である boltz／chai／openfold／protenix／intfold は、タンパク質のみの系を含むあらゆるケースで精度の高いデフォルト選択肢です。また、核酸＋低分子複合体にも対応するため、系にリガンド／RNA／DNA が含まれる場合はこれらを選んでください（さらに boltz は結合親和性も予測します）。alphafold（AF2）は、単量体と多量体に適した堅実な選択肢です（鎖は : で結合します）。esmfold は単一配列（MSA なし）を対象とし、高速です。速度を重視し、MSA がない場合に選んでください。esmfold2 はより新しく、デフォルトで MSA を条件として使用します（model 設定で、より高速な単一配列モードを選べます）。抗体（abodybuilder、immunebuilder）、環状ペプチド（highfold）、構造アンサンブル（afcluster、alphaflow）向けの特化型フォルダーもあります。絞り込んで、各説明を読んでください。
• バインダーを設計する（function=binder-design）：bindcraft（デノボのミニタンパク質バインダー）と boltzgen（タンパク質および低分子ターゲット向けのバインダー。ナノボディ／抗体／ペプチドを含む）は、デノボのバインダー設計に適した主要ツールです。rfdiffusion もバインダー設計に対応しており、モチーフの足場構築や既存バックボーンの多様化に適しています。抗体に特化した生成ツールは function=antibody-design にあります。
• 既知のバックボーンに対する配列を設計する（function=inverse-folding）：汎用の proteinmpnn、リガンドを考慮する ligandmpnn に加え、耐熱性／可溶性／抗体向けの MPNN 派生ツールがあります。逆フォールディングでは構造を入力して配列を出力するため、フォールディングし直して検証してください（チェーン実行を参照）。
• 低分子をドッキングする（function=protein-ligand-docking）：boltz／chai を優先してください。これらは固定された受容体にリガンドをドッキングするのではなく、リガンドを複合体に組み込んでフォールディングし、結合構造を予測します。既知のポケットに対する高速な大規模スクリーニングが必要な場合は、autodock-vina を選んでください。
• 結合親和性を予測する（function=binding-affinity）、または MSA を生成する（msa を検索する）：絞り込んで、説明を読んでください。

ユーザーが特定のツールを指定した場合は、そのツールを評価し、同じ tag グループ内の代替ツールも妥当性を確認してください。より高速なツールや、より適した関連ツールが見つかることもよくあります。判断に迷う場合は、確定する前に getJobSchema／validateJob で、候補ツールが実際に手元の入力を受け付けるか確認してください。

ジョブの設定、スキーマ、検証

各ツールには独自のsettingsスキーマがあります。送信する前に取得してください。

• REST /toolsエントリー：各settingsパラメーターはトリミング済みの辞書です。常に含まれるのはnameとrequiredのみです。type、default、description、optionsは該当する場合にのみ含まれます（typeがあるのは約60％です）。そのため、param["type"]ではなくparam.get("type")を使用してください。高度な制御用キー（exclude、conditionals）は、RESTレスポンスには含まれません。
• MCP getJobSchema(jobType)：exclude、conditionals、境界値を含む完全なスキーマです。これらの制御用キーについて判断する必要がある場合は、MCPを使用してください。（restrictOrgsはどちらのサーフェスでも除外されます。組織によって制限され、使用できないパラメーターは単に省略されます。references/api_reference.mdを参照してください。）

送信する前に、必ずMCPのvalidateJobを実行してください。これが信頼できる検証手段です。送信せずに/submit-jobと同じ検証を実行し、最初に見つかった未入力または無効なフィールドを示します。スキーマキーから、どのフィールドを除外すべきかを手作業で推測しないでください（RESTでは、そもそも確認できません）。validateJobに確認させてください。（レスポンスには、検証に使われたスキーマの出所を示す内部メモとして、"static-fallback"などのsourceフィールドが含まれる場合があります。対応の判断にはvalid: true/falseを使用してください。）

validateJobは、デフォルト値を補完した設定のnormalizedビューを返します。検証に使用したものと同じ、余分な要素のないsettingsを送信してください。normalizedは参考情報として扱ってください（設定していないデフォルト値や、一部のツールではプラットフォーム管理のフィールドが含まれる場合があります）。そのため、正規化されたデータではなく、独自の設定から送信内容を構築してください。

**配列：**アミノ酸配列文字列を指定します。マルチマーの各チェーンはコロン（:）で区切ります。例："MVLS...:EVQL..."。一部のツール（例：boltz、chai）では、sequence以外の項目も必要です。boltzではinputFormatも必須で、yamlFile／moleculesを指定できます。ツールに必須のフィールドを確認するには、必ずgetJobSchema／validateJobを使用してください。sequenceだけで十分だと決めつけないでください。

プラットフォーム内部フィールド — これらはプラットフォームが管理するため、自分で設定しないでください：submit_method、monomer_msa、msa。フィールドの扱いに関する完全なルールについては、references/api_reference.mdを参照してください。

送信前に、結果に影響する選択肢を提示し、黙ってデフォルトを適用しないでください。 リクエストに実行内容が完全に指定されている場合は、そのまま進めてください。一方、内容が自由である場合や、設定によって結果、実行時間、コストが大きく変わる場合（モデル／バリアント、サンプル数やシード数、MSAの有効／無効、GPUのティア、バッチサイズ）は、意味のある選択肢と、通常なら適用するデフォルトを提示し、送信前にユーザーに選んでもらってください。ジョブがキューに入った後で選択内容を報告するのではなく、必ず事前に確認してください。getJobSchemaとvalidateJobのnormalizedには、ユーザーに代わって設定する項目が正確に示されるため、確認してもらう価値のあるものを選んで手短に尋ねられます。これは特にバッチで重要です。共通の設定を1つ選ぶだけで、すべてのジョブにその選択が適用されるためです。

ファイル入力（PDB、CIF、SDF、…）

ファイルパラメーターを受け取るツールでは、次の3通りの方法で入力できます。

1. 最初にアップロードし、その後、ファイル名だけで参照します。 PUT /upload/{filename}、または MCP の uploadFile → 署名付き URL → curl -X PUT -T file "<url>"。ホストから S3 に接続できない場合（外部ネットワークへの接続がないサンドボックス化されたエージェントなど）は、代わりに MCP の uploadFileContent(filename, content, encoding?) を使って、MCP チャネル経由でファイルの内容を送信してください。デフォルトではテキストとして送信され、バイナリの場合は encoding="base64" を指定します。オブジェクトは S3 キー {email}/{filename} に保存されますが、settings で参照する際はファイル名の filename のみを指定してください（例："targetFile": "GLP1R_ECD.pdb"）。プラットフォームが自動的にアカウントのスコープを適用します。メールアドレスをプレフィックスとして付けないでください。{email}/{filename} を渡すと、参照時にプレフィックスが二重に付き、submit-job が "The following files have not been uploaded: <email>/<file>" というエラーで 400 を返します。MCP の getFiles(search=...) または REST の GET /files で、ストアに登録された正確な名前を確認してください（ファイル名のみの一覧です）。
2. 以前のジョブの出力を、そのパスで参照します。 JobName/path/to/file.ext（これがジョブを連結する方法です。下記を参照してください）。
3. インラインコンテンツ。 ファイルのテキスト内容をフィールド値として直接送信します。

注意点： ファイル型のパラメーターでは、通常の文字列値は、既存のオブジェクトへのパスではなく、インラインのファイル内容として扱われます。 すでにアップロードしたファイルを指定するには、ファイル名のみの filename（{email}/... の S3 キーではありません）を使用するか、以前のジョブの出力を指定する場合は JobName/... 形式のパスを使用してください。新しいコンテンツとして解決されることを期待して、ファイル名だけの文字列を渡してはいけません。

validateJob に関する注意事項。 応答に source フィールド（例："static-fallback"）が含まれる場合があります。これはツールのスキーマの解決方法を示すもので（組み込みツールでは常に static-fallback が返されます）、バリデーターに接続できたかどうかを示すものではありません。そのため、source ではなく valid に基づいて判断してください。ファイルパラメーターでは、上記のとおり、アップロード済みファイルをファイル名のみで参照してください。ファイル名だけならアカウントのスコープが適用されたオブジェクトとして解決されますが、メールアドレスをプレフィックスに付けた文字列はインラインコンテンツとして読み込まれ、ファイル型チェックで失敗することがあります（"... must contain ATOM records"）。また、ファイル内容をインラインで渡すと、検証前に validateJob が同期的にアップロードするため、時間がかかる場合があります。アップロード済みファイルを名前で参照する方法を優先してください（上記を参照）。ドライランに時間がかかる場合はスキップし、submit-job に検証させてください。

ジョブをパイプラインにつなぐ

完了したジョブの出力を、ダウンロードや再アップロードをせずに次のジョブの入力にできます。**次のツールが実際に必要とする入力タイプに合わせてください。**シーケンス設計ツール（ProteinMPNN）は シーケンス を出力するため、それぞれを sequence として渡してフォールディングします。ファイル パラメーターを取るツールには、パスを渡します。

設計からフォールディングへの最も簡潔な連鎖方法は、MCP の submitBatch(fromJob=...) です。完了した設計ジョブが生成したシーケンスを読み取り、それぞれを 1 つのジョブとしてフォールディングします。

# ProteinMPNN designs sequences -> fold every one with AlphaFold, one call:
submitBatch(batchName="verify-designs", type="alphafold", fromJob="my-proteinmpnn-job")

ファイル入力（例：.pdb／.cif を取るツール）の場合、ファイルパラメーターで JobName/path/to/file.ext というパス形式を指定すると、前のジョブの出力を参照できます。注意点は 2 つあり、どちらも検証で確認されています。（1）パラメーターで必須のファイルタイプに合わせてください。たとえば AlphaFold の templateFiles は .cif のみを受け付け、リスト形式であり、templateMode: "custom" の場合にのみ使用できます。（2）templateFiles は構造テンプレート用であり、「設計したシーケンスをフォールディングする」ためのものではありません。シーケンスをフォールディングするには、sequence を渡してください。ファイルパラメーターに連鎖させる前に、必ず getJobSchema／validateJob を使って、そのタイプと条件を確認してください。

ジョブの正確な出力パスを確認するには、MCP の listJobFiles(job1) を使います。各ファイルの s3Path が返され、次の submitJob でそのまま使用できます。（REST の GET /files では、アカウントにアップロードしたファイルが名前の一覧としてフラットに表示されるだけで、ジョブの出力は列挙されません。）Tamarind は保存済みのパイプラインにも対応しています。UI で作成し、/run-pipeline（{pipelineName, initialInputs, inputs}）で実行するか、/submit-pipeline で stages[] をインライン定義できます（各ステージでは task と toolSettings を指定し、"pdbFile": "pipe" を使ってあるステージの出力を次のステージにつなぎます）。references/workflows.md を参照してください。

バッチ送信

同じツールのジョブをまとめて送信できます。Python 形式では、settings[] と jobNames[] の配列を並行して指定します（配列の長さは同じで、最大 100 件です）。

requests.post(f"{BASE}/submit-batch", headers=HEADERS, json={
    "batchName": "egfr-binder-screen",
    "type": "alphafold",
    "jobNames": ["seq1", "seq2", "seq3"],
    "settings": [{"sequence": "..."}, {"sequence": "..."}, {"sequence": "..."}],
    # optional: "maxRuntimeSeconds": 3600, "weightedHoursBudget": 100,
    # (some accounts also accept an optional "gpuType" — confirm with support)
})

**バッチでは、サブジョブの JobStatus ではなく、親ジョブの batchStatus をポーリングしてください。**バッチを作成すると、親ジョブ（Type: "batch"）とサブジョブが作成されます。サブジョブは計算が終わるとすぐに Complete に変わりますが、その後、バッチでは最終的なダウンロード可能な出力を集約するのに数分かかります。親ジョブを名前で取得し、batchStatus を確認してください。

import time
while True:
    # ?jobName= returns the parent ROW directly (no "jobs" wrapper)
    parent = requests.get(f"{BASE}/jobs", headers=HEADERS,
                          params={"jobName": "egfr-binder-screen"}).json()
    bs = parent.get("batchStatus")
    if bs == "Complete":
        break
    if bs in ("Stopped", "AggregationFailed"):
        raise RuntimeError(parent.get("AggregationError", bs))
    time.sleep(15)   # Running / Aggregating -> keep waiting
# When Complete, the parent carries a presigned `resultUrl` and a `statuses`
# subjob tally ({Complete, Running, In Queue, Stopped}).
open("batch.zip", "wb").write(requests.get(parent["resultUrl"]).content)

GET /jobs?batch=<name> に includeSubjobs=true を追加すると、サブジョブごとの行を一覧表示できます。

ジョブのステータスのライフサイクル

単一ジョブでは JobStatus が報告され、バッチの親ジョブでは batchStatus が報告されます（バッチでは前述のとおり、こちらをポーリングしてください）。

ステータス	意味
In Queue	受け付け済み。処理能力に空きができるまで待機中です
Running	ワーカーで実行中です
Complete	正常に完了しました。結果を利用できます
Stopped	停止しました（失敗、タイムアウト、手動停止、または予算超過）
Deleted	ジョブが別の手段で削除されました
Aggregating	（バッチの親ジョブのみ）サブジョブが完了し、最終出力を作成中です
AggregationFailed	（バッチの親ジョブのみ）集約処理に失敗しました

完了したジョブには Score（pLDDT／pTM／ipTM などのツール固有の指標）と WeightedHours が含まれます。Complete／Stopped／Deleted（バッチでは AggregationFailed も）を終端状態として扱い、15～30 秒間隔でポーリングしてください。**Complete／Stopped だけでなく、いずれかの終端状態になったらポーリングループを終了してください。**ポーリング中にジョブが Deleted になると、そうしなければループが無限に続く可能性があります。Stopped になったジョブについては、getJobLogs(jobName) を取得して理由を確認してください。WeightedHours はジョブごとに請求される使用量の単位です。weightedHoursBudget でバッチの上限を設定してください。送信時に 403 が返る場合は予算に達しています（references/api_reference.md と /usage-statistics エンドポイントを参照）。

エラー処理

コード	意味	対応
400	不正なリクエスト／無効な設定	スキーマに照らして再確認し、まず validateJob を実行してください
401	認証されていません	x-api-key を確認してください
403	予算超過（組織／チーム）	適用範囲を狭めるか、予算を引き上げてください
429	レート制限	待機時間を延ばしてから再試行してください
500	サーバーエラー	再試行し、解消しない場合はサポートに連絡してください

リファレンスファイル

openapi.yaml の仕様がエンドポイントの形式に関する信頼できる情報源です。以下のファイルでは、仕様に記載されていない動作や注意点を補足しています。

• references/examples.md — 一般的なツール（alphafold/boltz/diffdock/autodock-vina/proteinmpnn/batch）ごとの検証済みsettings ペイロード、コピーして使えるセルフチェック、「失敗する内容と正確なエラー」の一覧、出力形式に関する注記を掲載しています。動作するペイロードを確認するには、まずこちらをご覧ください。
• references/api_reference.md — エンドポイントのクイックリファレンスと、一見わかりにくい形式に関する説明：/jobs は名前で検索すると単独の行を返す（{jobs:[...]} ではありません）、/result は2段階のダウンロード、バッチの親ジョブは batchStatus をポーリングする、/files はファイル名のフラットな一覧、settings フィールドの処理ルール。
• references/tool_catalog.md — カテゴリとタグの対応表、ツールとパラメーターのメタデータの読み方、一般的なツールファミリー。
• references/workflows.md — エンドツーエンドの手順：配列のフォールディング、送信前の検証、ファイルのアップロードと参照、設計からフォールディングへの連携、集計ポーリングを使ったバッチスクリーニング、使用状況の統計、ページネーション、長時間ジョブ向けの非ブロッキングな「すぐに送信し、後で確認」するパターン。

関連スキル

• rowan：Rowan は、Python API を備えたクラウドネイティブの分子モデリングおよびメディシナルケミストリーのワークフロープラットフォームです。
• adaptyv：タンパク質実験の設計、送信、結果取得に Adaptyv Bio Foundry API と Python SDK を使用する方法です。
• diffdock：DiffDock と DiffDock-L による分子ドッキング。