Grok 4.7 APIチュートリアル：AI回路設計レビューアを構築する

回路図は電子部品の接続関係を示す図です。レビューとは、部品とその定数が設計要件を満たしているかを確認することです。電源は十分な電流を供給できるか？プロセッサはセンサーの出力全域を読み取れるか？答えは回路図、部品のデータシート、そしていくつかの計算から得られます。

Grok 4.7がその一連のレビューを最後までやり切れるか試してみました。 Grok 4.7ガイドによれば、このモデルは長いタスクに対応し、自身の作業をより慎重に点検するよう訓練されています。回路は通常のPythonコードで検算できる数値を与えてくれるため、結果の判定に別のAIモデルは不要です。

この実験のために、USB給電の小さなセンサーボードEnviroNode Rev Aを作り、設計内に3つの不具合を意図的に仕込みました。Grokには不具合の数は伝えません。自ら見つけ、各発見を部品のドキュメントで裏付け、修正案を提示し、修正値をPythonのチェックにかける必要があります。

内容を追うのに電気工学の背景知識は不要です。回路のルールは登場時に都度説明します。次のことを学べます。

• Responses APIを通じてGrok 4.7に回路図画像を送る

• データシートをFiles APIで添付し、Grokに検索させる

• 計算をコード実行で検証し、上限値をウェブ検索で確認する

• 合否を判定するローカルのverify_design()関数をGrokに与える

• 長文かつドキュメント多用の会話をモデルのコンテキスト制限内に収める

• 一貫したレビュー形式で返し、推論レベルを比較する

最初の画像レビューから最後のPythonチェックまで、同じボードを見続けます。

TL;DR

Grok 4.7はデータシートを与えると仕込み不具合をすべて特定し、修正後の設計はPythonチェックを通過しました。これは今回の3つの不具合についての結果であり、一般的な回路レビューを代表するものではありません。

• ドキュメントなしでは推測を拒否：画像だけでは1件の欠陥を確定し、レギュレータとADC（アナログ・デジタル変換器）の上限は「要エビデンス」としました。
• データシートで疑念が証拠に：各発見がドキュメント値を引用し、正しい部品が誤って指摘されることはありませんでした。
• ファイル多用のターンは長期コンテキストを使い切り得る：PDF検索を繰り返した後、継続が500Kウィンドウを超過しました。修正したループは次のターン前に圧縮します。
• lowは検証を通過したが盲点を露呈：フィルタの定数は記述されたチェックを満たした一方、容量性負荷や過渡整定は未検証のままでした。

これは小さな1枚のボードであって、ベンチマークではありません。データシートが十数枚あるボードはより大きなコンテキストを生み、異なる結果をもたらすかもしれません。

Grok 4.7 APIとは？

Grok 4.7 APIは、モデルID grok-4.7で、Pythonアプリにテキストおよび画像入力、テキスト出力、そして50万トークンのコンテキストウィンドウを提供します。公式ガイドには、low、medium、high（デフォルト）、xhighの推論レベルが記載されており、推論は無効化できません。APIは関数呼び出し、構造化出力、ウェブ検索、X検索、コード実行もサポートします。

当社のGrok 4.7概要ではローンチとベンチマークを扱っています。SpaceXAIはChat Completionsをレガシーとして位置づけているため、ここでの例はすべてResponses APIを使用します。

Grok 4.7の料金は？

プロンプトトークンが20万未満の場合、Grok 4.7は入力トークン100万あたり$2、キャッシュ済み入力トークン100万あたり$0.50、出力トークン100万あたり$6です。プロンプトが20万トークンに達すると、そのリクエスト内の全トークンが$4、$1、$12で課金されます。

サーバー側ツールには別料金があります。料金ページではウェブ検索やコード実行1,000回ごとに$5と記載されています。添付ドキュメントの検索は1回につき1セント、保存ドキュメントにはGiBあたり日次料金も発生します。関連リクエストには安定したprompt_cache_keyを使用しつつ、キャッシュされない入力の予算も見込んでください。

請求額はusage.cost_in_usd_ticksから読み取ります。コスト追跡ドキュメントによれば、キャッシングやツール料金も含まれます。値を10^10で割るとドルになります。

なぜ回路設計でGrok 4.7をテストするのか？

回路設計は、ドキュメント読解、計算、ツール利用、検証を1つのタスクで試せます。SpaceXAIはGrok 4.7のEEBenchスコアとして64.0%を公表しています。EEBenchの方法論は、大規模言語モデル（LLM）による判定ではなく、シミュレーションとBOMチェックを用いており、EnviroNodeも同じ方針です。

構築するもの：EnviroNode Rev Aの回路レビュー

EnviroNode Rev AはUSB給電のセンサーノードです。完全なプロジェクトはGitHubからダウンロードできます。

回路図には、Grokがレビューに必要とするすべての部品定数が記載されています。各要件にはPWR-002やBW-001のようなIDがあり、各発見をどのルールに紐づけるか明確にできます。

定数入りのEnviroNode Rev A回路図。画像：著者

Grokがボードをレビューする前に、検証器が用いるすべてのルールを公開します。この関数は、次の8つの要件から作られた5つの合否チェックを返します：

• PWR-001: USB入力は4.75 V〜5.25 Vの範囲に収まる
• PWR-002: レギュレータがピーク負荷をカバーする
• PWR-003: MCU以外の負荷は10 mAの予算を使う
• SIG-001: センサーのフルスケールは1.0 V
• ADC-001: ADC入力は2,250 mV以下を維持
• ADC-002: ADC入力は少なくとも1,500 mVに到達
• BW-001: 100 Hzまでの信号は損失1 dB未満
• BW-002: フィルタのカットオフは500 Hz以下

モデルも同じ要件セットを受け取ります。検証器の制限がGrokの修正提案後にのみ現れるといったことはありません。

3つの仕込み不具合は何か？

3つの不具合はいずれも数値で検証できます。不具合の数はプロンプトに記しません。

• レギュレータの容量不足（PWR-002）：TI TLV700は200 mA定格ですが、ESP32-C3のデータシートはWi‑Fi送信ピーク335 mAを記載し、Espressifの回路図チェックリストは少なくとも500 mAを求めています。

• ADCレンジ超過（ADC-001）：ゲイン3ではADCに3.0 Vが入り、データシートの実効レンジ上限2,500 mVの90%が要件です。

• フィルタが遅すぎる（BW-001）：10 kΩと1 μFでカットオフは15.9 Hz、一方で100 Hzまでの信号は損失1 dB以内が要件です。

ADCの欠陥は測定レンジに関するもので、ピン損傷ではありません。LED抵抗やCHIP_EN遅延のような正しい選択が、偽陽性を定量化可能にします。

レビュー・ループはどう機能するか？

レビューは明確な境界が必要です：Grokが変更案を提示し、合否はPythonが判断します。図は、そのループにドキュメントとツールがどこで入るかを示します。

提案と検証を分離するレビュー・ループ。画像：著者

最初のAPIコール前に成功条件を定義します。Grokがある要件と裏付け証拠に結び付けたときのみ欠陥をカウントします。修正は、verify_design()がall_pass = trueを返したときのみカウントします。

PythonでGrok 4.7 APIをセットアップする方法

xAIのプリペイドクレジット付きAPIキー、Python 3.10以上、そしてxAIのベースURLを指すOpenAI Python SDKが必要です。キーはxAIコンソールで作成し、以下のパッケージをインストールしてください。

python -m venv .venv
source .venv/bin/activate        # Windows: .venv\Scripts\activate
pip install openai python-dotenv pydantic httpx streamlit
pip install matplotlib schemdraw pytest  # Optional diagrams and verifier tests

APIの例は最初のパッケージ群を使い、2つ目はリポジトリの図表とテストを支援します。Python 3.11.9、openai 3.19.2、pydantic 2.13.5、streamlit 1.64.0、httpx 0.28.1で検証しました。キーは環境変数XAI_API_KEYとして保存し、ソースコードに埋め込まずpython-dotenvで読み込みます。セットアップが初めての場合は当社の仮想環境ガイドを参照してください。

最初のGrok 4.7 APIコールを実行する

すでにResponses APIでキーが動作していればStep 1へ進んでください。そうでなければ、このリクエストでキー、ベースURL、モデルIDを一度に確認できます。

import os
import httpx
from dotenv import load_dotenv
from openai import OpenAI

load_dotenv()
client = OpenAI(api_key=os.environ["XAI_API_KEY"], base_url="https://api.x.ai/v1",
                timeout=httpx.Timeout(3600.0))

response = client.responses.create(
    model="grok-4.7",
    reasoning={"effort": "low"},
    input="In one sentence, what does a low-dropout regulator do?",
)
print(response.output_text)

1文の回答が返ればセットアップは成功です。後で重要になりますが、推論やツールを用いるリクエストは数分かかることがあるため、長いタイムアウトが必要です。

Step 1: 画像だけでGrok 4.7は回路をレビューできるか？

はい。ツールを使わないことを明確に伝えれば、Grok 4.7は画像だけから回路図をレビューできます。ベースラインでは、PNGをbase64データURLとして要件テキストと一緒に送信します。

image = {
    "type": "input_image",
    "image_url": f"data:image/png;base64,{SCHEMATIC_B64}",
    "detail": "high",
}
response = client.responses.create(
    model="grok-4.7",
    input=[{"role": "user", "content": [
        image,
        {"type": "input_text", "text": REVIEW_PROMPT},
    ]}],
)

プロンプトは「確定」「要追加エビデンス」「確認済みかつ許容」の3セクションを求めます。不具合の数や疑わしい部品には触れません。

画像のみのレビューで何が見つかったか？

ツールやデータシートが利用できない場合は明示してください。そうしないと、アクセスできない仕様を参照すると述べて回答を終えることがあります。

TL;DRで述べたとおり、Grokは100 Hzでの16.1 dB損失と15.9 Hzカットオフからフィルタの欠陥を確定しました。レギュレータとADCは推測せず「要追加エビデンス」に分類されました。

Step 2: Files APIでデータシートを追加する方法

添付ドキュメントは曖昧な懸念を数値に裏付けられた主張へと変えます。各ドキュメントを一度アップロードし、file_idで参照します。

with open(DATASHEET_PATH, "rb") as datasheet:
    uploaded = client.files.create(
        file=datasheet,
        purpose="assistants",
        expires_after={"anchor": "created_at", "seconds": 7 * 24 * 3600},
    )
content = [image, *[{"type": "input_file", "file_id": fid} for fid in file_ids],
           {"type": "input_text", "text": EVIDENCE_PROMPT}]

このチュートリアルではexpires_afterを7日に設定しているため、キャッシュしたIDの有効期限はその期間内だけです。expires_afterなしの場合、xAIは削除するまでアップロードファイルを保持します。

ここで取得したOpenAI SDKのレスポンスでは、添付検索はpdf_searchやpdf_browseという名前のcustom_tool_call項目として現れ、使用量はdocument_search_callsにカウントされました。これは観測された挙動であり、一般的なツールタイプ契約ではないため、ループはドキュメント化された使用量カウンターも確認します。

データシートでレビューはどう変わるか？

ドキュメントによりStep 1の2つの未解決点が明らかになり、電源、ADC、フィルタの発見が裏付けられました。レギュレータの発見では、TLV700の200 mA定格、ESP32-C3の送信ピーク335 mA、500 mAの電源推奨が引用されました。

フィルタについては、R5を変えずに両方の帯域要件を満たすコンデンサ値（およそ32〜81 nF）をGrokが算出しました。すべてのデコイは理由付きで「確認済みかつ許容」に分類されました。

Step 3: Grok 4.7のコード実行で計算を検証する方法

コード実行はxAIのサーバー側Pythonサンドボックスで、OpenAIクライアント使用時はtoolsに{"type": "code_interpreter"}を追加します。プロンプトには「数値を含む主張は、確定扱いする前に必ず計算する」というルールを加えます。

前掲のコード実行ガイドによれば、サンドボックスにはネットワークアクセスがなく、リクエスト間で状態を保持しません。いくつかのデータシート数値を扱う分には問題ありません。

Grokが検算すべき項目は？

電力予算、ADCレンジ、フィルタ帯域を1つのスクリプトで確認するよう依頼します。回路が得意でない場合は、以下の出力は読み飛ばして構いません。要点は後述します。

f=  100.0 Hz  |H|=0.157177  attenuation=16.0722 dB
fc required for <= 1 dB at 100 Hz: fc >= 196.5227 Hz
V_adc_fs = 3.0000 V
90% limit = 2.2500 V
required rating = max(headroom, mcu min) = 500.00 mA

196.5 Hzの最小カットオフはフィルタ修正の根拠であり、モデルの暗算に任せずコードで算出します。最も減衰が小さい許容コーナーでも100 Hzで15 dB超の損失となるため、結論は揺らぎません。

Step 4: Grok 4.7はAPI経由でウェブ検索できるか？

はい。ウェブ検索は、添付ドキュメントが最新かどうかを確認します。メーカーはモデルの学習カットオフ後にデータシートを改訂するためです。公式ドメインに限定して、一次情報のみをエビデンスとしてください。

tools = [
    {"type": "code_interpreter"},
    {"type": "web_search", "filters": {"allowed_domains": ["ti.com", "espressif.com"]}},
]

前掲のウェブ検索ガイドでは、allowed_domainsを最大5つまで許可でき、docs.espressif.comのようなサブドメインも含められます。添付のデータシートが最新でも、この手順は維持します。アップロード後に公開された改訂を拾えるためです。

引用は何を証明するか？

Grokは現行のTI製品ページ、ESP32-C3のドキュメント、ハードウェアチェックリスト、関連するエラッタを引用すべきです。これらの引用はソースの根拠であって、工学的結論の正しさを直接証明するものではありません。

ドメインフィルターでも無関係なページが返る可能性があります。各引用が、計算に用いた正確な部品と上限値を裏付けているか確認してください。

Grokはファイルを検索し、計算し、メーカーサイトを確認。画像：著者

Step 5: Grok 4.7の関数呼び出しで検証器を追加する方法

verify_design()はローカルマシンで動く通常のPython関数で、改訂の合否を判定する唯一の審判です。Grokは関数呼び出しで設計値を提案し、その値を固定の上限に照らしてチェックします。

VERIFY_DESIGN_TOOL = {
    "type": "function",
    "name": "verify_design",
    "description": "Deterministically check an EnviroNode revision against EN-REQ-001...",
    "parameters": {
        "type": "object",
        "properties": {
            "revision": {"type": "string"},
            "regulator_part": {"type": "string"},
            "gain_rf_ohm": {"type": "number"},
            "gain_rg_ohm": {"type": "number"},
            "filter_r_ohm": {"type": "number"},
            "filter_c_nf": {"type": "number"},
        },
        "required": ["revision", "regulator_part", "gain_rf_ohm",
                     "gain_rg_ohm", "filter_r_ohm", "filter_c_nf"],
    },
}

電源容量はmax((335 + 10) mA × 1.25, 500 mA)を満たす必要があります。ADCは1.0 V × (1 + Rf/Rg)が1,500〜2,250 mVの範囲に収まる必要があります。フィルタチェックは100 Hzでの損失を測り、カットオフを500 Hz以下に制限します。各チェックは値、上限、合否を返します。

ツールスキーマはGrokに送る値を知らせるだけです。合否ロジックの中心は通常のPythonです。

import math

part = PARTS.get(regulator_part.strip().upper())
required_ma = max((335 + 10) * 1.25, 500)
power_ok = (
    part is not None
    and float(part["rated_iout_ma"]) >= required_ma
    and float(part["vin_max_v"]) >= 5.25
    and float(part["vout_v"]) == 3.3
)

gain = 1 + gain_rf_ohm / gain_rg_ohm
adc_mv = gain * 1000

fc = 1 / (2 * math.pi * filter_r_ohm * filter_c_nf * 1e-9)
loss_db = 10 * math.log10(1 + (100 / fc) ** 2)

checks = {
    "PWR-002": power_ok,
    "ADC-001": adc_mv <= 2250,
    "ADC-002": adc_mv >= 1500,
    "BW-001": loss_db <= 1.0,
    "BW-002": fc <= 500,
}
return {"all_pass": all(checks.values()), "checks": checks}

完全版の関数は無効値も却下し、各結果に測定値を添えて返します。良品設計、欠陥設計、未知部品、ニアミスでテストしてください。

修正の採点はモデルではなくコードが行うべき理由

部品定格はモデルの管理外にしてください。モデル自身に電流定格を供給させるべきではありません。Grokは型番を送信し、アプリケーションのカタログで関数が定格を参照します。

コードで答えを検証できるなら、提案と正否判定を同じエージェントに担わせるべきではありません。タスクが変わる場合は、verify_design()をテストスイートやスキーマチェックに置き換えてください。検証器の実装には手間がかかりますが、合否はモデルの主観に依存しません。

Step 6: 回路を再設計して検証する方法

Grokに目標を1つ与えます：確定した違反を、最小限で妥当な変更だけで全て修正し、先に定義したチェックを通過するまで完了とみなさない。Step 3〜5のエビデンスとツールを提供し、リクエスト上限を設定します。

ここでTL;DRのコンテキスト警告が効いてきます。ターンを増やす前に対処してください。

ファイル多用のループに文脈圧縮が必要な理由

継続リクエストには以前のツール結果が含まれ、ドキュメント検索は大量のテキストを返し得ます。失敗したプロトタイプでは、次の継続が1,116,321トークンに達し、Grok 4.7の50万トークンウィンドウを超過しました。

コンテキスト圧縮は、すでに上限を超えたリクエストを救えません。修正したループは、各ドキュメント検索のターンが成功するたびに、次のリクエスト送信前に圧縮します。

details = (response.usage.model_extra or {}).get(
    "server_side_tool_usage_details", {}
)
observed_attachment_call = any(
    item.type == "custom_tool_call"
    and item.name in {"pdf_search", "pdf_browse"}
    for item in response.output
)
used_documents = (
    details.get("document_search_calls", 0) > 0
    or observed_attachment_call
)

if used_documents:
    compacted = client.responses.compact(
        model="grok-4.7", input=history + list(response.output) + follow_up)
    history = list(compacted.output)  # pass the compaction item back unchanged
    # Compaction drops tool output, so restate the verifier's verdict ourselves.
    history.append({"role": "user", "content":
                    "verify_design results, exactly as returned: " + json.dumps(results)})
else:
    history = history + list(response.output) + follow_up
response = client.responses.create(model="grok-4.7", input=history, tools=TOOLS,
                                   store=False, prompt_cache_key=cache_key)

最後のappendは必ず残してください。圧縮で冗長なツール出力が落ちるため、検証器の結果を言い直しておくと、次の応答で架空のチェックや混乱を避けやすくなります。各ドキュメント多用ターンの後に圧縮するのは保守的な運用です。大規模システムでは入力トークン閾値で制御してもよいでしょう。

Rev Bは検証を通過したか？

はい。Grokは不合格だった各サブシステム（電源、ADCゲイン、フィルタ帯域）で部品を1つずつ変更しました。図にRev AとRev Bの正確な値を示します。

3つの部品変更でRev Aを是正。画像：著者

修正後の値はverify_design()に渡されます。各要件ごとの結果が返ります。

修正設計はすべての検証チェックを通過。画像：著者

不合格の結果はfunction_call_outputとして戻るため、Grokはチェックが通るかリクエスト上限に達するまで設計を再修正できます。

Step 7: 構造化レビューを返す方法

構造化出力は、パースが必要な散文ではなく、スキーマに適合するオブジェクトを返します。同じ会話でPydanticモデルを指定してclient.responses.parse()を呼び、ツール呼び出しをオフにします。

class Finding(BaseModel):
    violated_requirement: str
    severity: Literal["blocker", "major", "minor"]
    evidence: list[str]
    recommended_change: str
    verifier_result: Literal["pass", "fail", "not_verified"]

parsed = client.responses.parse(
    model="grok-4.7", input=history + [REPORT_REQUEST],
    text_format=DesignReview, tools=TOOLS, tool_choice="none", store=False,
)

有効なスキーマは内容の正しさを保証しないため、検証器の結果を同梱し、verifier_resultはそれに基づかせます。JSONは課題管理や人の承認フローに渡せます。

構造化レビューの報告内容は？

構造化レポートは、元の各欠陥が解消されたことを示し、検証器が返した測定値を引用し、未検証の懸念はopen_risksに残すべきです。本設計では、ちょうど500 mAの下限にあるレギュレータや、Espressif推奨と異なるADCコンデンサが懸念に含まれます。

Grok 4.7の推論努力を上げると回路レビューは向上するか？

努力レベルを上げても検証器スコアは向上しませんでしたが、フィルタ修正の質は変化しました。各レベルは同じ回路図、プロンプト、ツール、リクエスト上限を受け取りました。

lowは抵抗を小さくし、1 μFのコンデンサを維持したため、容量性負荷と整定挙動が検証器の外に残りました。Microchipの容量性負荷ガイダンスは、直列抵抗が安定性を改善し得ると述べているため、この結果は修正が不安定であることを証明するものではありません。周波数応答、ステップ応答、またはベンチテストが必要です。highはコンデンサを変更し、xhighは追加の検証器コールの後にhighと同じ最終値を選択しました。

xhigh推論はいつ価値があるか？

この単一比較では、highがより良いバランスでした。未モデル化の負荷懸念を回避しつつ、xhighが行った余分な検証器コールを避けました。各レベル1回の実行では一般的な順位付けはできません。

Grok 4.7は回路を修正できたか？

冒頭の問いへの答えは「はい」です（検証器の5つのチェックの範囲内で）。表は先の発見を1つにまとめています。

• 画像と要件
  • 追加：目視検査
  • 結果：回路図だけで証明できる事実を確認
• データシート
  • 追加：メーカーの上限値
  • 結果：2つの未解決点を発見に変換
• コード実行
  • 追加：検証済み計算
  • 結果：電力とフィルタの問題を定量化
• ウェブ検索
  • 追加：最新の公式ソース
  • 結果：添付エビデンスが最新かを確認
• ローカル検証器
  • 追加：Pythonによる合否
  • 結果：全ルールを通過した改訂のみ受け入れ

Grokは符号化された要件を修正しました。修正後のボードが電気的に完全であり量産準備が整ったことを証明したわけではありません。

懸念にエビデンスがあるかはドキュメントが決めます。改訂が合格かどうかはPythonが決めます。流暢な文章は、そのどちらの代わりにもなりません。

Streamlitでレビューを見る

当社のStreamlitガイドはここで使うインターフェースを解説します。ストリーミングでツール呼び出しを逐次表示し、その後に検証器のチェックと最終レポートを示します。