kicad

KiCad プロジェクト解析スキル

関連スキル

スキル	目的
bom	BOM の抽出、情報補完、発注、エクスポートのワークフロー
digikey	DigiKey で部品を検索（試作向けの調達）
mouser	Mouser で部品を検索（二次試作向けの調達先）
lcsc	LCSC で部品を検索（量産向けの調達、JLCPCB）
element14	Newark/Farnell/element14 で検索（海外調達、信頼できるデータシート）
jlcpcb	PCB の製造および実装の発注
pcbway	PCB の製造および実装の代替手段
spice	検出したサブ回路の SPICE シミュレーションによる検証
emc	EMC の事前適合リスク分析 — 回路図と PCB アナライザーの出力を使用

引き継ぎの指針： このスキルを使って回路図／PCB を解析し、構造化データを抽出してください。BOM の情報補完、価格確認、発注は bom に引き継いでください。部品検索とデータシートの取得は digikey／mouser／lcsc／element14 に引き継いでください。製造の発注と DFM ルールの検証は jlcpcb／pcbway に引き継いでください。設計レビューでは、SPICE シミュレーターがインストールされている場合（which ngspice ltspice xyce で確認）、必ず spice を実行してシミュレーション検証を行ってください。回路図と PCB の両方を解析できる場合、設計レビューでは EMC の事前適合リスク分析として必ず emc を実行してください。これらは任意ではありません。省略すると、値の計算ミスや EMC リスクを検出できません。

解析の前に： ユーザーから KiCad プロジェクトの解析またはレビューを依頼されたら、プロジェクトに datasheets/ ディレクトリがあるか確認してください。ない場合、DigiKey API キー（DIGIKEY_CLIENT_ID）を利用できるなら、まずデータシートを同期するよう提案してください。「解析の前に、部品のデータシートをダウンロードできます。これにより、メーカー仕様に基づいたピンレベルの検証とデカップリングの確認が可能になります。同期しますか？」と尋ねてください。ユーザーが断った場合、または API キーが設定されていない場合は、データシートなしで解析を進めてください。解析はデータシートがなくても行えますが、データシートによる検証結果は得られません。

アナライザーの出力に DS-001 の指摘（重大度 high、検出器 audit_datasheet_coverage）がある場合、レビューで検証済みと主張することはできません。作業を止め、（a）認証情報／在庫を利用できるサービスの digikey／mouser／lcsc／element14 を使ってデータシートを同期する、（b）BOM の部品に MPN を設定する、または（c）すべてのピンレベル、電気的特性、レギュレーターに関する指摘は整合性の確認のみであるとレポートに明記する、のいずれかを行ってください。この場合、「verified」「confirmed」「per datasheet」という語はどこにも使わないでください。DS-002（データシートはないが MPN は設定済み）と DS-003（MPN の設定が一部のみ）も、対象としている部品については同じ意味を持つ、影響の小さいバリエーションです。

設計レビューの条件

ユーザーから設計レビュー、完全なレポート、製造準備完了の評価、またはそれに相当する依頼があった場合、1～2 個のアナライザーを実行して結果を要約するだけで終わらせないでください。このスキルでの設計レビューには、より厳格な条件があります。

1. アナライザーのコマンドセクションだけでなく、この SKILL.md のワークフロー全体を読みます。
2. レポートを作成する前に references/report-generation.md を読みます。
3. プロジェクト内にあるファイルに適用可能なアナライザーをすべて実行し、実行したものと実行しなかったものを明示します。
4. 何かを「検証済み」と主張する前に、元ファイルおよびデータシートとの照合検証を行います。
5. アナライザーの誤検出の可能性を確認してから、ブロッカーとして扱います。
6. 必須の手順を実施できなかった場合は、黙って省略せず、レビュー上の不足事項として明記します。

これを最低基準としてください。アナライザーの JSON だけでは、最終レビューになりません。

最低限のレビュー チェックリスト

完全な設計レビューを実施するには、以下の各項目をレポートで明示的に確認してください。

• datasheets/ が存在するか、同期されているか、または検証できていない旨が記載されている
• analyze_schematic.py
• analyze_pcb.py --full
• cross_analysis.py
• analyze_emc.py
• シミュレーターがインストールされている場合は、SPICE シミュレーション
• 回路図と PCB の両方の JSON が存在する場合は、analyze_thermal.py
• 製造用出力ファイルが存在する場合は、analyze_gerbers.py
• ネットワークアクセスが可能で、MPN のカバー範囲が十分な場合は、ライフサイクル監査
• 前回のレビュー／前回の実行との差分チェック
• 重要部品について、回路図／PCB の実データの抜き取り検証を完全な検証に引き上げる
• 阻害要因、検証の根拠、誤検知、スキップした分析に関するレポートの明示的なセクション

該当しない項目がある場合は、その理由を記載してください。スキップした場合は、その理由を記載してください。失敗した場合は、それによって信頼度がどのように制限されるかを説明してください。

よくあるレビューの失敗モード

この契約は、以下の失敗モードを防ぐことを目的としています。

• 回路図、PCB、EMC の出力だけを確認して完全なレビューと判断する
• アナライザーの指摘について、想定されるレイアウト上のアーティファクトかどうかを確認せずに報告する
• データシートの直接的な証拠または構造化された抽出の証拠なしに「検証済み」と主張する
• 熱、ライフサイクル、前回のレビューとの差分、Gerber のチェックを開示せずに省略する
• 判定、阻害要因の表、検証の根拠、スキップした分析に関する注記がないレポートを作成する
• このスキルの最初の部分だけを読み、ファイルの後半にある設計レビューワークフローを見落とす

PDF 回路図の分析

このスキルはPDF 回路図にも対応しています。対象には、リファレンスデザイン、開発ボードの回路図、評価ボードの資料、アプリケーションノート、データシートに記載された標準的な応用回路が含まれます。一般的な用途は次のとおりです。

• 回路を理解するために、メーカーのリファレンスデザインを分析する
• サブ回路（電源、USB インターフェース、センサーのフロントエンド）を抽出して、自分の KiCad 設計に取り込む
• PDF のリファレンスデザインと自分の回路図を比較する
• PDF 回路図から BOM 全体を抽出する
• PDF 内の部品値を最新のデータシートと照合して検証する

ワークフロー： PDF のページを目視で確認する → 部品と接続を特定する → 構造化データを抽出する → KiCad のシンボルとネットに変換する → データシートと照合して検証する。

部品の抽出、表記規則、ネットのマッピング、サブ回路の抽出、KiCad への変換、検証に関する詳細な手法については、references/pdf-schematic-extraction.md を読んでください。

抽出した回路をデータシートと照合して詳細に検証する場合（値の確認、パターンのチェック、エラーの検出）は、references/schematic-analysis.md の手法を使用してください。

分析スクリプト

このスキルには、KiCad ファイルから包括的な構造化 JSON を一度の処理で抽出する Python スクリプトが含まれています。まずこれらを実行し、その後で出力を検討してください。

独自の簡易抽出スクリプトを書くのではなく、アナライザーの JSON 出力を直接読んでください。JSON スキーマには、カスタムコードでは間違えやすい特定のフィールド名が定義されています（以下および references/output-schema.md に記載）。特定のセクションを抽出するには、python3 -c "import json; d=json.load(open('file.json')); print(json.dumps(d['key'], indent=2))" を実行します。

JSON の内容が想定外の場合（AttributeError が発生する、構造が想定と異なる、「値があるはず」のフィールドが None を返すなど）は、2 回目の抽出を試みる前に作業を止めて --schema を実行してください。すべてのトップレベルキーについて、正確なフィールド名と型が出力されます。

python3 <skill-path>/scripts/analyze_schematic.py --schema
python3 <skill-path>/scripts/analyze_pcb.py --schema
python3 <skill-path>/scripts/analyze_gerbers.py --schema

JSON フィールドの早見表 — アナライザーの出力を手作業で読む際によくある間違い：

確認したい内容	正しいパスとフィールド	よくある間違い
ネット上のピン	nets[<name>].pins[].component / .pin_number / .pin_name / .pin_type	ref、pin、type、number
名前のないネットの見やすい表示	nets[<name>].display_name — 設定すると、唯一の名前付き IC ピンから内容を読み取れる __unnamed_N ネットに Ref.PinName のヒントが表示されます（例：__unnamed_36 → U1.VBOOT）。存在しない場合は、アナライザーが判別できなかったことを意味します。	display_name を無視して、生の __unnamed_36 をレポートに貼り付ける
IC ピンマップ	ic_pin_analysis[] は IC エントリーのリストです。各エントリーには .reference と、.pin_number / .pin_name / .pin_type / .net / .connected_to[] を持つ .pins[] があります。対象：type が {ic, connector, crystal, oscillator} の場合のみ。	{ref: {...}} として扱う、または pins[].number を使用する
トランジスタのピンマップ	transistor_pin_analysis[] は、type=transistor（MOSFET、BJT、FET）用の別のリストで、エントリーごとの構造は ic_pin_analysis[] と同じです。ハーフブリッジ／ゲートドライバーのピン検証にはこちらを使用してください。	ic_pin_analysis[] 内で Q1 を探す — トランジスタはここにはありません
検出された回路	パターンマッチした回路（電源レギュレーター、RC フィルター、水晶発振器、ブリッジなど）はすべて findings[] に格納されます。finding_schema.get_findings(data, Det.POWER_REGULATORS) などで絞り込んでください。subcircuits[] から読み取らないでください：これは IC 周辺のグループ化（{center_ic, ic_value, neighbor_components, …}）であり、カテゴリ別の検出インデックスではありません。	subcircuits.power_regulators、subcircuits.rc_filters、または subcircuits[type] キーを探す — これらは v1.3 の出力には存在しません
ゾーンのネット	pcb.zones[].net は文字列ではなく、整数のネット ID です。f"{net!r}" を使用するか、先に変換してください。	f"{net:20s}" — ValueError: Unknown format code 's' for object of type 'int' でクラッシュします
ゾーンのレイヤー	pcb.zones[].layers（複数形）が正式なレイヤーリストです。複数レイヤーのゾーンでは zones[].layer（単数形）は予約済み／None です。必ず .layers を読み取ってください。	zones[].layer を読み取って None を取得する
フットプリントの位置	pcb.footprints[].x / .y はトップレベルにあります（.position ラッパーはありません）。	footprints[].position.x
フットプリント上のパッドごとのネット情報	pcb.footprints[].pad_nets{pad_number: {net, pin}} は、パッド番号をキーとする辞書です。connected_nets[] は、フットプリントに接続するネットの重複を除いたリストです。	footprints[].pads[] — このキーは出力に存在しません
トラックの概要	pcb.tracks は辞書（Tracks エンベロープ）で、{segment_count, arc_count, layer_distribution{}, width_distribution{}} が格納されています。内部の tracks.segments[] と tracks.arcs[] 配列が設定されるのは --full の場合のみです。セグメントのフィールド：{x1, y1, x2, y2, width, layer, net} — net は整数 ID です（トップレベルの nets / net_name_to_id を使って対応付けてください）。	--full を付けずに for t in tracks: ... を実行する — tracks はリストではなく概要の辞書です。seg.get("x") / seg.get("start") もキーが誤っており、.get() のデフォルト値によって気付かないまま 0.0 になるバグが発生します
電源ネットの配線	pcb.power_net_routing はネットごとのエントリー [{net, track_count, total_length_mm, ...}, ...] のリストであり、ネットをキーとする辞書ではありません。	power_net_routing["VCC"] → TypeError
検出結果	findings[] はフラットなリストです。各項目には rule_id、detector、severity、summary、report_context があります。finding_schema.get_findings(data, Det.*) または group_findings(data) で絞り込んでください。	signal_analysis.power_regulators[] のようなキー付き辞書を探す（v1.3 より前の形式で、削除済み）

これにより、フォーマット文字列のバグやフィールド名の間違いを防げます。出力のフォーマットには f-string または json.dumps() を使用し、文字列型でない値に %s を使用しないでください。一般的な抽出パターンを含む完全なスキーマについては、references/output-schema.md を参照してください。

以下のすべてのコマンドで、<skill-path> はこのスキルのベースディレクトリを指します（読み込み時にこのファイルの先頭に表示されます）。

回路図アナライザー

python3 <skill-path>/scripts/analyze_schematic.py <file.kicad_sch> --analysis-dir analysis/
python3 <skill-path>/scripts/analyze_schematic.py <file.kicad_sch> --analysis-dir analysis/ --compact
python3 <skill-path>/scripts/analyze_schematic.py <file.kicad_sch> --output analysis.json  # one-off, no cache

基板の複雑さに応じて、約 60～220 KB の構造化 JSON を出力します。

• コンポーネントと BOM：リファレンス、値、フットプリント、lib_id、タイプ分類、MPN、データシートを含む一覧と、数量をまとめた BOM
• ネット：ピンとネットの対応、配線数、未接続箇所を含む完全な接続マップ
• 検出されたサブ回路（パターンマッチングされた回路。すべて一致する Det.* 検出器を含む findings[] エントリとして出力されます。取得するには get_findings(data, Det.POWER_REGULATORS) などを使用します）：
  • 電源レギュレーター — LDO／スイッチング／反転トポロジー、データシートで検証された Vref ルックアップ（約 60 ファミリー）による Vout 推定と、ヒューリスティックによるフォールバックおよび固定出力サフィックスの解析、vref_source（lookup／heuristic／fixed_suffix）フィールドと vout_net_mismatch フィールド
  • 電圧分圧器、RC／LC フィルター（カットオフ周波数）、フィードバックネットワーク、水晶発振回路（負荷容量の解析、IC ピンに基づく検出）
  • オペアンプ回路（構成、ゲイン、積分器／補償器）、トランジスター回路（ネット名を考慮した負荷分類：モーター／ヒーター／ファン／ソレノイド／バルブ／ポンプ／リレー／スピーカー／ブザー／ランプ、FET レベルシフターのトポロジー）
  • ブリッジ回路（H ブリッジ、3 相、シート間検出）、保護デバイス（ESD／TVS）、電流検出、デカップリング解析
  • 分野固有：RF チェーン、RF マッチングネットワーク、BMS、イーサネット（BFS による PHY からコネクターまでの追跡）、HDMI／DVI インターフェイス、メモリーインターフェイス、キー・マトリクス（ネット名とトポロジーに基づく）、絶縁バリア、アドレス指定可能 LED チェーン（WS2812／SK6812／APA102）、バッテリー充電器（TP4056／MCP73831／BQ2404x）、モータードライバー（A4988／TMC2209／DRV8301）、ESD 保護範囲の監査、デバッグインターフェイス（MCU の追跡を伴う SWD／JTAG）、電源パス（ロードスイッチ／理想ダイオード／USB PD コントローラー）、ADC 信号調整（外付け ADC と電圧リファレンス、アンチエイリアスの相互参照）、リセット／スーパーバイザー回路（電圧スーパーバイザー／ウォッチドッグ／RC リセットネットワーク）、クロック分配（クロックジェネレーター／PLL／発振器出力の追跡）、ディスプレイ／タッチインターフェイス（SSD1306／ILI9341／ST7789／FT6236／GT911）、センサーフュージョン（割り込みの検証とバスクラスタリングを伴う IMU／環境センサー／磁力計）、レベルシフター（電源ドメインのマッピングを伴う IC ベースのものとディスクリート BSS138）、オーディオ回路（I2S／クラス D 検出を伴うアンプ／コーデック）、LED ドライバー IC（PWM／マトリクス／定電流）、RTC 回路（バッテリーバックアップ／水晶の組み合わせ）、LED 照明監査（電流制限の検証）、熱電対／RTD インターフェイス（MAX31855／MAX31865）、電源シーケンス検証（電源ツリー／イネーブルチェーン／PG デイジーチェーンの解析）
• IC ピン配置解析：ピンレベルの接続、IC 機能分類（3 段階：ライブラリのプレフィックス、部品番号のキーワード、説明によるフォールバック）
• 電源解析：PDN インピーダンス（MLCC の寄生要素を考慮した 1kHz～1GHz）、電力バジェット、電源シーケンス（EN／PG チェーン）、スリープ電流の監査（抵抗経路とレギュレーターの Iq、EN 検出を含む）、電圧ディレーティング、突入電流の推定
• 設計解析：ERC 警告、電源ドメイン、バス検出（COPI／CIPO／SDI／SDO を含む I2C／SPI／UART／CAN／RS-485）、差動ペア（USB／LVDS／イーサネット／HDMI／MIPI／PCIe／SATA／CAN／RS-485 のサフィックスペアマッチング）、ドメイン間信号（電圧の等価性）、BOM 最適化、テストカバレッジ、組み立ての複雑さ、USB 準拠
• 品質チェック：アノテーションの完全性、ラベルの検証、PWR_FLAG の監査、フットプリントフィルターの検証、調達監査、プロパティパターン監査、汎用トランジスターシンボルの検出（Q_NPN_/Q_PNP_/Q_NMOS_/Q_PMOS_ シンボルを検出し、データシートの有無を確認）
• 構造解析：MCU の代替ピン概要、グラウンドドメイン分類、バストポロジー、配線の幾何形状、空間クラスタリング、ピンカバレッジ、階層ラベルの検証

最新の .kicad_sch（KiCad 6 以降）と旧形式の .sch（KiCad 4／5）に対応しています。階層設計は再帰的に解析されます。 レガシー形式： KiCad 5 のレガシー .sch ファイルでは、アナライザーは .lib ファイル（キャッシュライブラリとプロジェクトライブラリ）を解析してピンデータを取得します。.lib ファイルが利用可能であれば、ピンとネットのマッピング、信号解析、サブ回路の検出がすべて機能します。カバレッジは通常 92～100% です。.lib ファイルが見つからないコンポーネント（リポジトリに含まれていない標準の KiCad システムライブラリ）には、ピンデータがありません。組み込みのフォールバックでは、40 種類以上の一般的なシンボル（R、C、L、D、LED、トランジスタ、MOSFET、水晶振動子、スイッチ、極性付きコンデンサ、最大 20 ピンのコネクタ、抵抗アレイ）に対応し、ミル単位のピンオフセットと、バージョン間でピン位置が異なる場合の自動ワイヤースナップ補正を提供します。

レガシー設計の補足データ

analyze_schematic.py が不完全なデータを返す場合（利用できない .lib ファイルが原因でピンが欠落しているコンポーネントがある場合）、追加のプロジェクトファイルを使って解析機能を完全に復元してください。最も有用な情報源は .net ネットリストファイルです。このファイルにはピンとネットの明示的なマッピングが記載されており、残りの不足を補えます。

詳細な解析手順、データ復元のワークフロー、補足情報源（ネットリスト、キャッシュライブラリ、PCB の相互参照、PDF エクスポート）の優先順位マトリックスについては、references/supplementary-data-sources.md を参照してください。

アナライザーの出力を実際のデータと照合してください。 アナライザーは、もっともらしく見えても誤った結果（誤った電圧推定、MPN の欠落、誤ったピンとネットのマッピング）を、エラーを出さずに生成することがあります。スクリプトエラーにはならず、レポートに誤ったデータがそのまま使われます。複数の基板を対象にしたテストでは、どのプロジェクトにも少なくとも 1 つ、誤解を招くアナライザー出力がありました。生の .kicad_sch ファイルと照合してください：

1. コンポーネント数 — (symbol (lib_id ブロックを検索し、電源シンボルを差し引きます。アナライザーの数と完全に一致する必要があります。
2. ピンとネットの対応関係 — 各コンポーネントについて、アナライザーのピンとネットの対応関係を生の回路図と照合します。シンボルブロックを読み、配線やラベルをたどって接続を確認します。ICのピン割り当ては、メーカーのデータシートのピン配置表と照合します。これは最も重要な検証手順です。ピンの対応関係が誤っていると、基板は機能しなくなりますが、DRC/ERCでは検出できません。
3. 物理的な正しさ（整合性だけでなく） — 整合性チェック（回路図＝PCB＝アナライザーがすべて一致すること）は必要ですが、それだけでは十分ではありません。確認できるのは設計内部の一貫性だけであり、実際の部品と一致しているかどうかではありません。最も危険なのは、トランジスターのシンボルに記されたピン配置の想定（Q_NPN_BEC = 1番ピン=B、2番ピン=E、3番ピン=Cなど）が、実際の部品と一致しないケースです。整合性チェックはすべて通過しても、基板は誤ったものになります。これを見つけるには、以下を確認します。
   • SOT-23、SOT-223、TO-252などのパッケージのトランジスター（BJT/MOSFET）では、KiCad の lib_id のサフィックスにピン順序の想定が記されています。SOT-23 の BJT には少なくとも6種類のピン配置（BEC、BCE、EBC、ECB、CBE、CEB）があり、SOT-23 の MOSFET には GDS、GSD、SGD、DSG があります。MPNが指定されていない場合、この想定を検証する方法がないため、重大な曖昧さとして指摘します。
   • MPNが指定されている場合は、その特定のパッケージのデータシートにあるピン配置図と照合し、シンボルのピンとパッドの割り当てを検証します。
   • この原則はトランジスター以外にも当てはまります。同じパッケージで複数のピン順序が存在する部品（ピン割り当てが異なる電圧レギュレーター、メーカー独自のピン配置を持つコネクターなど）は、MPNレベルでの検証が必要です。
   • 検証できない場合は、妥当性を評価します。 未検証の選択肢がすべて同じリスクを持つわけではありません。強い慣例に沿うものもあれば（最も一般的なSOT-23 NPNのピン配置はBCE、SOT-23の2N2222はほぼ常にBCEです）、慣例に反するものや、実際に曖昧なものもあります（SOT-23のMOSFETには支配的な標準がありません）。MPNがなく検証できない場合は、ドメイン知識を活用します。デバイスの種類やパッケージに一般的なピン配置、メーカーの慣例、そのカテゴリの部品の大半の仕様などを考慮し、想定されたピン配置が正しい可能性が高いか、珍しいか、どちらとも言えないかを評価します。確信度を報告します。「最も一般的な慣例と一致する」と「どちらとも言えない」では意味が異なります。同じ考え方は、受動部品の値（4.7kΩはこのバスのプルアップ値として一般的か）、回路トポロジー（標準的な応用回路か）、部品選定（この用途で一般的に使われる部品か）にも当てはまります。
4. ネットの追跡 — 電源レールと重要な信号ネットを、配線やラベルをたどって端から端まで確認します。各ネットについて、アナライザーのピンリストが完全であることを検証します。
5. レギュレーターのVout — vref_source フィールドを確認します。"lookup" はデータシートで検証済み（約60のファミリー）を意味し、"heuristic" は推測値であり、手動での検証が必要です。vout_net_mismatch フィールドは、推定Voutが出力レール名の電圧と15%を超えて異なる場合にフラグを立てます。
6. 階層接続 — 複数シートの設計では、シート間の接続がネットデータに反映されていることを確認します。

検証チェックリストの全文は、references/schematic-analysis.md の手順2を参照してください。スクリプトが失敗する場合や、予期しない結果を返す場合は、完全な代替手順として references/manual-schematic-parsing.md を参照してください。

PCB レイアウトアナライザー

python3 <skill-path>/scripts/analyze_pcb.py <file.kicad_pcb> --analysis-dir analysis/
python3 <skill-path>/scripts/analyze_pcb.py <file.kicad_pcb> --analysis-dir analysis/ --proximity  # add crosstalk analysis
python3 <skill-path>/scripts/analyze_pcb.py <file.kicad_pcb> --output pcb.json --schematic analysis/schematic.json  # one-off; cross-ref + power-rail auto-detect

以下を含む構造化 JSON を出力します（基板の複雑さに応じて約 50～300 KB）。

• コア：フットプリント一覧（パッド、コートヤード、ネット割り当て、拡張属性、回路図との相互参照）、トラック／ビアの統計、ゾーンの概要、基板外形／寸法、配線の完了状況
• ゾーンと銅箔の有無：ゾーン外形と塗りつぶしポリゴンのバウンディングボックス、塗りつぶし率、各パッドにおける層間の銅箔の有無（反対側の層にゾーン銅箔があるコンポーネントと、ないコンポーネント）、同一層にある他ゾーンの検出
• ビア解析：種類の内訳（スルーホール／ブラインド／マイクロ）、アニュラリングの検査、ビア・イン・パッドの検出、BGA／QFN のファンアウトパターン、電流容量、スティッチングビアの特定、テンティング
• シグナルインテグリティ：ネットごとのトレース長、層遷移の追跡（グラウンドリターン経路）、トレースの近接性／クロストーク（--proximity を指定）
• 電源と熱：ネットごとの電流容量、電源ネットの配線概要、グラウンドドメインの特定（AGND／DGND）、ゾーンスティッチングビアの密度、サーマルパッドの検出とビア数のカウント
• 製造：配置解析（コートヤードの重なり、端面クリアランス）、デカップリングコンデンサーまでの距離、DFM スコア（JLCPCB の標準／上級ティア）、墓石化リスク（0201／0402 の熱的非対称性）、サーマルパッドのビアの適切性、シルクスクリーンのドキュメント監査

--full を追加すると、個々のトラック／ビアの座標、セグメントごとのトレースインピーダンス（スタックアップから算出したマイクロストリップの Z0）、パッド間の配線距離、リターン経路の連続性解析、ビアのスタブ長が含まれます。--full の出力は、spice スキルの寄生成分抽出（extract_parasitics.py）に渡され、PCB を考慮したシミュレーションに使用されます。KiCad 5 のレガシー形式にも対応しています。

ゾーンの塗りつぶしは最新の状態にしてください。 銅箔の有無の解析では、ユーザーが「編集 → すべてのゾーンを塗りつぶす」（ショートカット B）を実行したときに計算され、.kicad_pcb ファイルに保存される KiCad の塗りつぶし済みポリゴンデータを使用します。最後に塗りつぶしてから基板が変更されている場合、塗りつぶし済みポリゴンデータが古くなっている可能性があり、銅箔の有無の結果が不正確になります。銅箔の有無のデータを確認する際は、fill_ratio が妥当かどうかに注意してください。塗りつぶし面積が 0 のゾーンや is_filled: false のゾーンは、塗りつぶされていない可能性があります。

ゾーンの外形 ≠ 実際の銅箔。 ゾーンの outline_bbox はユーザーが描画した境界であり、filled_bbox はクリアランス、キープアウト、優先順位によるカットアウトを適用した後に、実際に銅箔が存在する範囲です。copper_presence セクションには、反対側の層にゾーン銅箔があるコンポーネントが示されます。銅箔の有無をゾーン外形から推測するのではなく、静電容量式タッチパッドの分離、アンテナのキープアウト、熱解析にはこの情報を使用してください。

銅箔の影響を受けやすいコンポーネントは、より詳細に確認してください。 静電容量式タッチパッドやアンテナでは、「反対側の層に銅箔がない」ことの確認は必要ですが、それだけでは不十分です。銅箔がない状態は偶然かもしれません。配線変更後にゾーンを再塗りつぶすだけで銅箔が追加され、タッチ感度が失われたり、アンテナの同調がずれたりする可能性があります。銅箔のない領域を DRC ルールとして保証するキープアウトゾーン（ルールエリア）が明示的に設定されているか確認してください。また、タッチパッド周辺の同一層にある GND とのクリアランスを測定し、コントローラーのアプリケーションノートに記載された最小値と比較してください。タッチパッドについては、すべてのパッドのトレース長を比較してください。大きな非対称性があると、チャネルごとのベースライン測定値にずれが生じます。銅箔の影響を受けやすいすべてのコンポーネントについて、物理的な詳細（パッドサイズ、位置、クリアランス、トレース幅／長さ）を報告してください。詳細なチェックリストは references/pcb-layout-analysis.md → Copper-Sensitive Components を参照してください。

実行するたびに検証してください： フットプリント数と基板外形寸法を、生の .kicad_pcb ファイルと照合してください。IC フットプリントのパッドとネットの割り当てを、回路図のピンとネットの対応関係と照合してください。これにより、パッド番号とシンボルのピン配置が一致しないライブラリフットプリントのエラーを検出できます。スクリプトが失敗した場合は、代替手法として references/manual-pcb-parsing.md を参照してください。

PCB のリッチ形式とアセンブリチェック

すべての PCB 解析セクションで、リッチ形式（detector、rule_id、category、severity、confidence、summary、recommendation、report_context）の検出結果が生成されるようになりました。さらに、7 つの新しいアセンブリ／DFM チェックが自動的に実行されます。

• FD-001：フィデューシャルマーカーの有無（SMD の各面に 3 個以上）
• TE-001：信号ネット全体のテストポイント網羅率
• OR-001：受動部品の向きの一貫性
• SK-001：露出パッドに重なるシルクスクリーンのテキスト
• VP-001：テント処理されていないビアインパッド（--full モード）
• BV-001：基板端からのビアのクリアランス（--full モード）
• KO-001：キープアウトゾーンの違反
• CP-001：コンポーネントの下にある同一レイヤー上の別ネットのゾーン。別ネットのゾーンが GND 以外のネットに属する場合、またはコンポーネントに GND パッドがない場合、重要度は warning です。別ネットのゾーンが GND に属し、コンポーネントに GND パッドがある場合、重要度は info です（バイパスコンデンサーがグラウンドの銅箔領域の上にある一般的なケースで、想定どおりのレイアウトであり、クリアランスの問題ではありません）。

ドメイン間解析

回路図と PCB の両方のアナライザーを実行した後、ドメイン間アナライザーを実行します。 --schematic と --pcb には現在の実行の JSON ファイルを指定し、 --analysis-dir analysis/ を渡して、結果を同じ実行フォルダーに保存し、 マニフェストで追跡されるようにします。

# Recommended: integrate into the current run
python3 <skill-path>/scripts/cross_analysis.py \
    --schematic analysis/<run_id>/schematic.json \
    --pcb analysis/<run_id>/pcb.json \
    --analysis-dir analysis/

# One-off (bypasses the cache)
python3 <skill-path>/scripts/cross_analysis.py \
    --schematic schematic.json --pcb pcb.json --output cross_analysis.json

チェック項目：CC-001 コネクターの電流容量、EG-001 ESD 保護の不足、DA-001 デカップリングの妥当性、XV-001..003 回路図／PCB の同期。PCB JSON は省略可能です。

機械的な相互検証（PCB と回路図のジオメトリ）：python3 <skill-path>/scripts/cross_verify.py --help。

接続グラフ（--full モード）

PCB アナライザーで --full を使用すると、出力に connectivity_graph セクションが含まれ、パッド、トラック、ビア、ゾーン塗りつぶしに対する Union-Find によるネットごとの銅箔接続解析が行われます。これにより、cross_analysis.py で決定論的なプレーン分割検出とリターンパスの検証が可能になります。connectivity_graph のトップレベルキーはネット名そのものです。たとえば cg['GND']、cg['Net-(D2-K)']、cg['+3V3'] のようになります。per_net ラッパーではありません。各ネットのエントリーには、アイランド数、コンポーネントからアイランドへのマッピング（{component:pad: island_id}）、ギャップの位置、未接続のパッドペアが示されます。

Gerber とドリルのアナライザー

# Recommended: integrate into the current run
python3 <skill-path>/scripts/analyze_gerbers.py <gerber_directory/> --analysis-dir analysis/

# One-off
python3 <skill-path>/scripts/analyze_gerbers.py <gerber_directory/> --output gerber.json

出力項目：レイヤーの識別（X2 属性）、コンポーネント／ネット／ピンのマッピング（KiCad 6+ の TO 属性）、アパーチャー機能の分類、トレース幅の分布、基板寸法、ドリルの分類（ビア／コンポーネント／取り付け穴）、レイヤーの完全性、位置合わせの検証、パッドタイプの概要（SMD/THT 比率）。ピンとネットの完全な接続情報を出力するには --full を追加します。約 10KB の JSON です。

Gerber アナライザーは、リッチ形式の検出結果を含む findings リストを生成します。検出項目は GR-001 レイヤーの欠落、GR-002 位置合わせの問題、GR-003 ドリルの問題、GR-004 ペーストアパーチャーの不一致、GR-005 基板外形線の途切れです。

スクリプトが失敗した場合、または予期しない結果を返した場合は、references/manual-gerber-parsing.md を参照してください。生の Gerber/Excellon ファイルを直接解析するための、フォールバック手法がすべて記載されています。

すべてのスクリプトは、デフォルトで JSON を標準出力に出力します。以下の「Analysis Cache Convention」で説明する実行フォルダー規約に出力を統合するには、--analysis-dir analysis/ を使用してください。これにより、1 回のセッションで実行した各アナライザーの出力が同じ analysis/<run_id>/ フォルダーにまとめられ、マニフェストで追跡されます。 結果をキャッシュしたくない単発の実行に限り、--output file.json を使用します。 1 行の JSON を出力するには --compact を追加します。

アナライザーの JSON は保存しておく価値があります。再生成にはコストがかかり（大きな回路図では時間がかかります）。--analysis-dir はすべての実行結果を保存し、下流ツール（diff_analysis、what_if）が想定する形式で出力します。Git にコミットする必要はありませんが、解析ステップの間に削除しないでください。

統一出力形式

すべてのアナライザーは、統一された出力エンベロープを生成します。

{
    "analyzer_type": "schematic|pcb|emc|cross_analysis|thermal|gerber|lifecycle|spice",
    "schema_version": "1.4.0",
    "summary": {
        "total_findings": 42,
        "by_severity": {"error": 3, "warning": 15, "info": 24}
    },
    "findings": [
        {"rule_id": "...", "detector": "...", "severity": "...", "confidence": "...", "evidence_source": "...", "summary": "...", ...}
    ],
    "trust_summary": {
        "total_findings": 42,
        "trust_level": "high|mixed|low",
        "by_confidence": {"deterministic": 20, "heuristic": 18, "datasheet_backed": 4},
        "by_evidence_source": {"datasheet": 4, "topology": 10, "heuristic_rule": 18, ...},
        "provenance_coverage_pct": 96.5
    }
}

findings リストは、すべての検出結果の唯一の信頼できる情報源です。finding_schema.get_findings() または finding_schema.group_findings() を使って、検出器、ルールのプレフィックス、またはカテゴリでフィルタリングしてください。検出器名は finding_schema.Det の定数として利用できます。重大度は error、warning、info のいずれかです。信頼度は deterministic、heuristic、datasheet-backed のいずれかです。

すべてのアナライザーは、人が読みやすい出力の --text、統合された実行フォルダーへの出力（推奨）の --analysis-dir、特定のファイルへそのまま書き込む出力（単発）の --output に対応しています。両方を指定した場合は、明示的に指定した --output のパスが優先されます。1 回の実行につき、いずれか一方を選んでください。

ステージと対象者によるフィルタリング

すべてのアナライザーは --stage フラグと --audience フラグに対応しています。

ステージ： schematic、layout、pre_fab、bring_up 対象者： designer（デフォルト）、reviewer、manager

# Show only layout-relevant findings for a reviewer
python3 <skill-path>/scripts/analyze_pcb.py board.kicad_pcb --stage layout --audience reviewer --text

# Manager summary of schematic review readiness
python3 <skill-path>/scripts/analyze_schematic.py design.kicad_sch --audience manager --text

# Pre-fab checklist for cross-domain analysis
python3 <skill-path>/scripts/cross_analysis.py -s sch.json -p pcb.json --stage pre_fab --text

JSON 出力には常にすべての検出結果が含まれます。--stage を指定すると、各検出結果に stages フィールドと in_active_stage フィールドが追加され、stage_filter の概要も追加されます。audience_summary では、常に designer／reviewer／manager 向けのビューが生成されます。--text 出力には、両方のフラグが反映されます。

生成ファイル

解析出力は analysis/ に保存されます。タイムスタンプ付きの実行フォルダーは analysis_cache.py で管理されます。マニフェスト（analysis/manifest.json）には、すべての実行が記録されます。

ファイルの種類	場所	再生成可能？	git にコミットする？
アナライザー JSON	analysis/<timestamp>/*.json	はい（時間がかかります）	.kicad-happy.json の track_in_git によって設定（デフォルト：いいえ）
マニフェスト	analysis/manifest.json	はい	常に（デフォルトで追跡）
デザインレビュー報告書	ユーザーが選択したパス	はい	任意

デザインレビューを作成するときは、過去の実行結果がないかマニフェストを確認してください。auto_diff が有効で過去の実行結果がある場合は、diff_analysis.py を使って現在の結果と前回の結果を自動的に比較し、その差分を「Previous Review Delta」セクションに含めます。

データシート、注文 CSV、バックアップについては、bom スキルのクリーンアップセクションも参照してください。

解析キャッシュの設定

.kicad-happy.json の analysis セクションで、共有の解析出力ディレクトリを制御します。

{
  "analysis": {
    "output_dir": "analysis",
    "retention": 5,
    "auto_diff": true,
    "track_in_git": false,
    "diff_threshold": "major"
  }
}

フィールド	デフォルト	説明
output_dir	"analysis"	プロジェクトルートからの相対パスで指定する解析ディレクトリのパス
retention	5	保持する、ピン留めされていない実行結果の最大数。0 = 無制限
auto_diff	true	デザインレビューに差分セクションを自動的に含める
track_in_git	false	false の場合、JSON は git の追跡対象から除外されますが、マニフェストは追跡されます
diff_threshold	"major"	新しいタイムスタンプ付きフォルダーを作成する重大度：minor、major、breaking

すべてのフィールドは任意です。フィールドがない場合は、デフォルト値が使用されます。

出力 JSON スキーマのクイックリファレンス

回路図アナライザーのトップレベルキー：

analyzer_type, schema_version, summary, findings, trust_summary,
file, kicad_version, file_version, title_block, statistics,
bom, components, nets, subcircuits, ic_pin_analysis, transistor_pin_analysis,
design_analysis, connectivity_issues, hierarchy_context, hierarchy_warning, net_classifications, rail_voltages

任意（空でない場合に存在）：pdn_impedance、sleep_current_audit、power_budget、power_sequencing、bom_optimization、test_coverage、assembly_complexity、usb_compliance、inrush_analysis、sheets（複数シートの場合のみ）、missing_info、bom_lock、project_settings 重要なネスト構造:

• statistics: {total_components, unique_parts, dnp_parts, total_nets, total_wires, total_no_connects, component_types, power_rails, missing_mpn, ...}
• bom[]: {reference, references[], value, footprint, mpn, manufacturer, datasheet, quantity, dnp, ...}
• components[]: {reference, value, footprint, lib_id, lib_name, type, category, mpn, datasheet, dnp, in_bom, parsed_value, ...}
• nets{net_name}: {pins[], wires, labels[], ...} — 各ピン: {component, pin_number, pin_name, pin_type, ...} (ref や pin ではありません)
• subcircuits[]: IC 近傍のグループ化 ({center_ic, ic_value, neighbor_components, ...}) であり、カテゴリ別の検出インデックスではありません — このファイル冒頭の JSON フィールド早見表を参照してください。
• 検出されたサブ回路は findings[] に格納されます — 電源レギュレータ、分圧器、RC/LC フィルタ、フィードバックネットワーク、オペアンプ/トランジスタ/ブリッジ/水晶回路、電流検出、デカップリング、保護、ブザー/スピーカー、Ethernet/HDMI/メモリインターフェース、RF チェーン/マッチング、BMS、キーマトリクス、絶縁バリア、アドレス指定可能 LED チェーン、および設計上の所見はすべて、対応する Det.* 検出器による findings として出力されます。取得には get_findings(data, Det.POWER_REGULATORS) などを使用してください。v1.3 より前の signal_analysis ラッパーとそのトップレベル検出リストは廃止されました。

PCB アナライザーのトップレベルキー:

analyzer_type, schema_version, summary, findings, trust_summary,
file, kicad_version, file_version, statistics, layers, setup,
nets, net_name_to_id, board_outline, component_groups, footprints,
tracks, vias, zones, keepout_zones, connectivity, net_lengths

オプション: power_net_routing、decoupling_placement、ground_domains、layer_transitions、silkscreen、board_metadata、dimensions、groups、net_classes、dfm_summary、placement_density、copper_presence_summary、board_thickness_mm、trace_proximity (--proximity 指定時)。以前はトップレベルにあったセクション (thermal_analysis、thermal_pad_vias、tombstoning_risk、placement_analysis、current_capacity、copper_presence、dfm) は現在 findings[] に含まれています。--full を指定すると、出力には connectivity_graph セクションも含まれます (上記の「Connectivity Graph」を参照)。

重要なネスト構造:

• net_lengths は リスト (辞書ではありません): [{net, net_number, total_length_mm, segment_count, via_count, layers{}}, ...] 長さの降順でソートされます
• power_net_routing は リスト です: [{net, track_count, total_length_mm, min_width_mm, max_width_mm, widths_used[]}, ...]
• footprints[]: {reference, value, footprint, layer, pads[], sch_path, sch_sheetname, sch_sheetfile, connected_nets[], ...}
• statistics: {footprint_count, copper_layers_used, smd_count, tht_count, zone_count, via_count, routing_complete, ...}

Gerber アナライザーのトップレベルキー:

analyzer_type, schema_version, summary, findings, trust_summary,
directory, generator, layer_count, statistics, completeness, alignment,
drill_classification, pad_summary, board_dimensions, gerbers, drills

ワークフロー: KiCad プロジェクトを解析する際は、プロジェクトディレクトリをスキャンして利用可能なすべてのファイルタイプを確認し、ユーザーが言及したものだけでなく、該当するすべてのアナライザーを実行してください。完全な解析には利用可能なすべてのデータを使用します。すべてのアナライザーで --analysis-dir analysis/ を使用すると、マニフェストで追跡される単一の実行フォルダーを共有できます。キャッシュ追跡なしの単発実行には、代わりに --output file.json を使用してください。

以下のワークフローを設計レビューのために開始する前に: references/report-generation.md を読んでください。そこに記載されているレポート構造、検証根拠のルール、スキップされた解析の開示、および誤検出トリアージの期待事項はレビューワークフローの一部であり、最後に追加される任意の仕上げではありません。

1. プロジェクトディレクトリをスキャンし、.kicad_sch、.kicad_pcb、.kicad_pro、ガーバーディレクトリ、.net／.xmlのネットリストファイルを探します。
2. データシートを同期します（下記の「データシートの取得」を参照）。これは検証の前提条件であり、省略できません。データシートがない場合、以降の検証はすべて内部整合性の確認に限られます。つまり、設計自体に一貫性があることは確認できますが、設計が正しいことは確認できません。アナライザーの出力を読む前に同期を実行してください。同期に失敗した場合、またはAPIキーが利用できない場合は、代替手段（DatasheetプロパティのURL、digikeyスキルを使った個別ダウンロード、ユーザーへの確認）を利用します。重要なICのデータシートを入手できない場合は、検証上の不足点としてレポートに明記してください。
3. 中核となるアナライザーを実行します。回路図がある場合はanalyze_schematic.pyを実行します。PCBがある場合はanalyze_pcb.py --fullを実行します。ガーバーファイルがある場合はanalyze_gerbers.pyを実行します。可能な場合は並行して実行してください。
4. ドメイン間分析を実行します。回路図とPCBの両方の分析結果がある場合は、cross_analysis.py --schematic sch.json --pcb pcb.jsonを実行します。これにより、ドメイン間の危険な不具合（コネクターの電流と配線幅、ESDの間隔、デカップリングの適切性、回路図とPCBの同期状態）を検出できます。
5. EMCの事前適合性評価を実行します。回路図とPCBの両方の分析結果がある場合は、python3 <emc-skill-path>/scripts/analyze_emc.py --schematic sch.json --pcb pcb.jsonを実行します（このスクリプトはemcスキル内にあり、このスキルの<skill-path>配下にはありません）。設計レビューではEMC評価は必須であり、省略できません。EMCスキルは、グラウンドプレーンの完全性、デカップリング、スイッチング高調波、PDNインピーダンス、差動ペアのスキュー、ESD経路などを対象に44項目のルールチェックを実行します。結果をレポートの「EMC」セクションに含めてください。
6. SPICEシミュレーションを実行します。まずwhich ngspice ltspice xyceを実行します。いずれかのシミュレーターがインストールされている場合は、レポートの作成前にSPICEの実行が必須です。spiceスキルに引き継ぎ、python3 <spice-skill-path>/scripts/simulate_subcircuits.py sch.jsonを実行します。これにより、フィルター周波数、分圧比、オペアンプのゲインなどを実際のシミュレーション結果と照合して検証できます。ほとんどの基板でSPICEの実行は1秒未満で、静的アナライザーでは見つけられない値の計算ミス（抵抗比の誤り、カットオフ周波数に対して不適切なコンデンサーなど）を検出できます。回路図とPCBの両方の分析結果がある場合は、python3 <spice-skill-path>/scripts/extract_parasitics.py pcb.json --output parasitics.jsonを実行し（--fullのPCB JSONが必要です）、高インピーダンス回路（100Kを超える帰還分圧器、LCフィルター、RFマッチングネットワーク）では--parasitics parasitics.jsonを渡してください。これは引数にパスを指定するもので、単独のフラグではありません。結果をレポートの「シミュレーション検証」セクションに含めてください。**出力スキーマ：**トップレベルのキーはsummary、simulation_results、workdir、total_elapsed_s、simulatorです。simulation_results[]の各エントリーには、subcircuit_type、components（参照名のリスト。例：["R5", "C3"]）、reference（参照名を連結したもの。例："R5/C3"）、status（pass／warn／fail／skip）、expected（指標値の辞書）、simulated（測定値の辞書）、delta（誤差率の辞書）が含まれます。
7. 熱解析を実行します。回路図とPCBの両方の分析結果がある場合は、analyze_thermal.py --schematic schematic.json --pcb pcb.jsonを実行します。パッケージのθJAと基板の熱特性に補正を加えて、接合部温度を推定します。結果をレポートの「熱ホットスポット」セクションに含めてください。
8. ライフサイクル監査を実行します（ネットワークに接続でき、MPNを利用できる場合）。analyze_schematic.py --lifecycleフラグを指定して実行します。販売代理店のAPIを使って部品の廃番状況を確認します。結果をレポートの「部品ライフサイクル」セクションに含めるか、「ライフサイクル監査は未実施 — [理由：APIキーなし／ネットワーク接続なし／MPNなし]」と記載してください。
9. .kicad_proプロジェクトファイルを直接読み取ります（JSON形式）。設計ルール、ネットクラス、DRC／ERCの設定を確認してください。
10. 過去の設計レビューを確認します。プロジェクトディレクトリをスキャンして、既存のレビュー用ファイル（*review*.md、*design-review*.md）を探します。見つかった場合は、最新のファイルを読み取ってください。auto_diffが有効で過去の実行結果がある場合は、diff_analysis.pyを実行して現在の結果と前回の結果を比較し、その差分を「前回レビューとの差分」セクションに含めてください。
11. レポートでデータを使用する前に、各出力を元ファイルおよびデータシートと照合して検証してください。
12. 統合レポートを作成し、回路図の分析、PCBレイアウトの分析、ドメイン間の所見、EMCリスク評価、シミュレーション検証、熱ホットスポット、相互参照の所見を網羅してください。レポートのテンプレートについてはreferences/report-generation.mdを参照してください。
13. レビューの不足点をすべて明示してください。熱解析、ライフサイクル監査、ガーバー解析、データシートの抽出、前回レビューとの差分のいずれかを実施していない場合は、黙って省略せず、レポートに短い「未実施／制限事項」セクションを追加してください。 組み合わせるデータソースが多いほど、分析の信頼性が高まります。回路図だけのレビューではレイアウトの問題を見落とし、PCBだけのレビューでは設計意図を見落とします。常に利用可能なすべての情報を使用してください。

分析の深さ

ユーザーが簡易レビューを求めていない限り、徹底的に分析してください。理由は、基板を動作不能にする不具合は、一見正しく見えるものだからです。抜き取り確認では5個のICが正しいと確認できても、6個目のピン3と4が入れ替わっているかもしれません。そして、それが基板を動作不能にする不具合です。徹底的に確認するための原則は次のとおりです。

• サンプルではなく、すべての部品を確認してください。「単純な」部品のピンとネットの誤り（ダイオードの逆接、分圧回路の抵抗値の間違い、ピン配置を誤ったコネクターなど）も、ICのピン入れ替えと同じように致命的です。設計全体を確認してください。
• KiCadのライブラリーシンボルではなく、データシートを正しい情報源として使用してください。 アナライザー、生の回路図、KiCadのライブラリーファイルが示すのは、設計が「どう記述されているか」です。「どうあるべきか」を示すのは、メーカーのPDFデータシートだけです。ピンの対応付けが誤ったライブラリーシンボルは、内部のすべての情報に整合性があるからこそ、最も危険な種類の不具合です。回路図、PCB、アナライザーはすべて一致していても、基板は動作しません。.kicad_symファイルに照らしてピン割り当てを確認するのは、潜在的な誤りの原因そのものを参照する循環的な確認です。検証を始める前にデータシートをダウンロードし（下記の「データシートの取得」を参照）、各ICの実際のPDFを開いてピン機能表を抽出し、検証結果を報告する際にはページ番号やセクション番号を引用してください。
• 検証可能性だけでなく、妥当性も評価してください。 検証できない場合（MPNがない、データシートがないなど）も、「未検証」で終わらせないでください。専門知識を使って、その設計上の選択が一般的な慣例に沿っているか、異例に見えるかを評価してください。10kΩのI2Cプルアップ抵抗は珍しくありませんが、100ΩのI2Cプルアップ抵抗は、照合用のデータシートがなくても詳しく確認する必要があります。BCEのピン配置を持つSOT-23のNPNトランジスターは最も一般的な慣例に合致しますが、CEBのものは異例なので、指摘する価値があります。目標は、「未検証だが、おそらく問題ない」ものと「未検証で、疑わしい」ものを区別することです。これはピン配置、受動部品の値、回路トポロジー、部品選定に当てはまります。
• アナライザーが検出する範囲を超えて考えてください。 アナライザーが検出できるのは、プログラムされているパターンだけです。自動解析データがないセクションについては、その設計に該当項目がないためなのか（問題ありません。簡潔にその旨を述べてください）、アナライザーでは検出できないためなのかを検討し、手作業で推論してください。すべてのセクションに説明の段落が必要なわけではありません。「該当なし：バッテリー駆動で、商用電源入力なし」で十分です。ただし、データが空だからといって、対象の設計にとって重要な分野を見落とさないようにしてください。

データシートの取得

Deep Reviewの工程に入る前に、入手可能かどうかを確認してください。抽出キャッシュ（datasheets/extracted/）が最短の方法です。ディスク上のPDF（datasheets/）は代替手段として直接読み込んでください。どちらもない部品がある場合は、データシートを使わずにレビューを進める前に、データシートの同期（digikey / lcsc / mouser / element14のスキル）を提案してください。抽出結果には品質フラグが付いています。品質の低い情報は隠されず、フラグ付きで返されるため、信頼するか、PDFを再読するかを判断してください。

データシートがあることで、整合性チェックと正確性チェックを区別できます。データシートがなければ、設計内で情報が一致していることは確認できますが、実際の部品と合致しているかは確認できません。ワークフローの早い段階でデータシートを入手してください。

自動同期（推奨）： ワークフローの早い段階で、データシート同期スクリプトを実行してください。これらのスクリプトは、MPNがあるすべての部品のデータシートをダウンロードし、マニフェストファイルmanifest.jsonとともに共有のdatasheets/ディレクトリーに保存します。まず推奨されるソースを実行し、一部の部品の取得に失敗した場合は、ほかのソースも試してください。これらのソースは同じディレクトリーを共有し、すでにダウンロード済みのファイルはスキップします。

python3 <digikey-skill-path>/scripts/sync_datasheets_digikey.py <file.kicad_sch>
python3 <lcsc-skill-path>/scripts/sync_datasheets_lcsc.py <file.kicad_sch>
python3 <element14-skill-path>/scripts/sync_datasheets_element14.py <file.kicad_sch>
python3 <mouser-skill-path>/scripts/sync_datasheets_mouser.py <file.kicad_sch>

DigiKeyが最適です（PDFへの直接URL）。element14は信頼性が高く（ボット対策がありません）、LCSCはLCSCでしか入手できない部品に対応しています。Mouserは最後の手段です（ダウンロードがブロックされることがよくあります）。 既存のデータシートを確認してください： ダウンロードする前に、次を確認します。

• <project>/datasheets/ にある manifest.json（以前の同期で作成されたもの）
• <project>/docs/ または <project>/documentation/
• ファイル名に MPN が含まれる、プロジェクトディレクトリ内の PDF ファイル
• KiCad のシンボルに埋め込まれた Datasheet プロパティの URL

自動同期を利用できない場合や、一部の部品が見つからない場合の代替方法：

1. 回路図シンボルの Datasheet プロパティの URL を使用します。多くの KiCad ライブラリには、PDF への直接リンクが含まれています。
2. digikey スキルを使用して MPN で検索し、個々のデータシートをダウンロードします。
3. ウェブ検索でメーカーのデータシートページを探します。
4. ユーザーに確認してください — 重要な部品のデータシートを自動で見つけられない場合は、見つからなかった部品をユーザーに伝え、データシートの提供を依頼します。データシートが入手できないという理由で、検証を黙って省略しないでください。例：「U3（XYZ1234）と U7（ABC5678）のデータシートが見つかりませんでした。提供していただけますか？ピン配置とアプリケーション回路を検証する必要があります。」

データシートの構造化抽出（大規模な設計やレビューを繰り返す場合）： データシートの仕様をキャッシュ済みの JSON に事前抽出しておくと、ピン検証をより迅速かつ一貫して行えます。PDF を毎回最初から読み直すと時間がかかるため、IC が 10 個以上ある設計では特に有効です。

python3 <skill-path>/scripts/datasheet_page_selector.py <pdf_path> --mpn <mpn> --category <category>

選択したページを読み、抽出 JSON を作成したら、datasheet_score モジュールと datasheet_extract_cache モジュールを使ってスコアを付け、キャッシュします。抽出結果は datasheets/extracted/<MPN>.json に保存され、レビュー間で再利用されます。抽出パイプライン全体（スキーマ、ページ選択、スコアリング基準、利用 API）は datasheets スキルが管理しています。skills/datasheets/SKILL.md とそのリファレンスガイドを参照してください。

各データシートから抽出する内容（引用用にページ、セクション、図、式の番号を記録してください）：

• ピン機能表（ピン番号 → 名前 → 機能）
• 絶対最大定格（電圧、電流、温度。突入電流を制約する VCC/GND ピンの最大連続電流を含む）
• 推奨アプリケーション回路と必須の外付け部品
• 必須の部品値（および、それらの値を導出する式）
• 熱特性

受動部品の場合： 抵抗器やコンデンサー個別のデータシートは通常不要ですが、部品値は、それを指定している IC のデータシートと照合してください。IC のデータシートに「入力コンデンサーには 10µF を使用」と書かれている場合、回路図に実際に 10µF があり、1µF ではないことを確認してください。

アンチパターン：データシートを使わない検証。 設計レビューで最もよくある失敗は、メーカーのデータシートではなく KiCad ライブラリのシンボルを基に部品の接続を検証することです。これは循環検証です。ライブラリのシンボルでピンの割り当てが間違っている場合、回路図、PCB、アナライザーの出力はすべて互いに（そして誤ったピン配置とも）一致してしまいます。エラーを明らかにできるのはデータシートだけです。これは、二次チェック用の上流 KiCad ライブラリが存在しないカスタム／コミュニティ製ライブラリのシンボル（例：sacmap:TPS61023）で特に危険です。.kicad_sym ファイルやアナライザーのピンデータを読み、回路図と一致することを確かめてピン配置を検証しようとしているなら、そこで止めてください。それは整合性の確認であって、正確性の確認ではありません。実際の PDF データシートを開き、ピン機能表を見つけて、それと照合してください。設計者が確認できるよう、報告書にはデータシートのページ、セクション、図の番号を引用してください。

回路図と PCB の相互照合

両方のファイルが存在する場合は、相互照合します。これにより、最もコストの高いバグを検出できます。ピンの入れ替わり、ネットの欠落、フットプリントの不一致は DRC/ERC を通過しても、基板が機能しない原因になります。

1. コンポーネント数：回路図の数（電源シンボルを除く）と PCB のフットプリント数を比較します。
2. ネットの整合性：回路図のネット名が PCB のネット宣言に含まれていることを確認します。ネットが欠落している場合、配線が不完全か、変更が同期されていない可能性があります。
3. ピンとネットの割り当て：回路図のピンとネットの対応を、PCB のパッドとネットの対応と比較します。不一致から、ピンの入れ替わりやライブラリエラーを特定できます。特にリスクが高い箇所：
   • カスタム／コミュニティ製ライブラリのシンボル（データシートのピン配置と一致しない場合があります）
   • 複数ユニットのシンボル（オペアンプ、ゲートアレイ）— ユニットとピンの割り当てエラー
   • QFN/BGA パッケージ — パッド番号の間違い
   • MPN のないトランジスタ — ピン配置が不明確（検証ステップ 3 を参照）
   • 極性のあるコンポーネント — アノード／カソードの向き
   • コネクタ — 1 番ピンの向き
4. フットプリントの一致：回路図の Footprint プロパティと実際の PCB フットプリントを比較します（例：SOT-23 と SOT-23-5）。
5. DNP の整合性：回路図で DNP とされたコンポーネントは、PCB 上で配線されていないことを確認します。
6. 値／MPN の整合性：回路図と PCB のプロパティで、値と MPN が一致していることを確認します。

PCB アナライザーの各フットプリントにある sch_path、sch_sheetname、sch_sheetfile フィールドを使うと、相互照合を自動化できます。

差分を考慮した設計比較

2 つの解析 JSON 出力を比較して、設計リビジョン間の変更（例：ベースブランチと PR、v1 と v2）を確認します。ユーザーが「設計を比較して」「何が変わった？」「回路図の差分を確認して」「main からの変更を表示して」「ベースとヘッドの差分を表示して」などと依頼した場合に使用します。詳細なリファレンス：references/diff-analysis.md。

# Compare two schematic analysis outputs (JSON to stdout)
python3 <skill-path>/scripts/diff_analysis.py base.json head.json

# Human-readable text output
python3 <skill-path>/scripts/diff_analysis.py base.json head.json --text

# Write to file, custom threshold (ignore <2% deltas)
python3 <skill-path>/scripts/diff_analysis.py base.json head.json --output diff.json --threshold 2.0

# Ignore small percentage changes (e.g., rounding noise)
python3 <skill-path>/scripts/diff_analysis.py base.json head.json --threshold 5.0 --text

アナライザーの種類（回路図、PCB、EMC、SPICE）を自動検出します。以下を報告します：

• コンポーネント：追加、削除、値／フットプリント／MPN の変更
• 信号解析：detection_schema.SCHEMAS の識別フィールドと値フィールドに基づく、検出タイプごとのパラメーターの変化
• BOM：明細項目の追加／削除、数量の変更
• 接続性／ERC：新規／解消された単一ピンネット、フローティングネット、複数ドライバーネット、ERC 警告
• EMC の検出結果：重大度とリスクスコアの差分を含む、新規／解消された検出結果、およびネットごとのスコアの変化
• SPICE の結果：ステータスの遷移（合格から不合格への後退、不合格から合格への修正）、モンテカルロ解析での懸念事項の変化
• 重大度分類：none（変更なし）、minor（統計情報のみ）、major（コンポーネント／信号／検出結果の変更）、breaking（SPICE の後退、新たな CRITICAL EMC 検出結果、新たな ERC 警告）

また、analysis_cache.should_create_new_run() からプログラム的に使用され、新しい出力をタイムスタンプ付きの新しい実行フォルダーに保存する必要があるかどうかを判断します。

熱ホットスポットの推定

回路図の電力データと PCB の熱設計要素（銅箔領域、サーマルビア、パッケージタイプ）を組み合わせて、電力を消費する部品の接合部温度を推定します。ユーザーが「熱を確認して」「熱解析」「過熱するか」「接合部温度」「消費電力」「熱設計」と言った場合に使用します。

# Recommended: integrate into the current run
python3 <skill-path>/scripts/analyze_thermal.py \
    -s analysis/<run_id>/schematic.json \
    -p analysis/<run_id>/pcb.json \
    --analysis-dir analysis/

# Human-readable text report
python3 <skill-path>/scripts/analyze_thermal.py -s schematic.json -p pcb.json --text

# Custom ambient temperature (default: 25°C), one-off output file
python3 <skill-path>/scripts/analyze_thermal.py -s schematic.json -p pcb.json --ambient 40 -o thermal.json

各電力部品（LDO、スイッチングレギュレーター、シャント抵抗）を点熱源としてモデル化します。Tj = T_ambient + P_diss × Rθ_JA_effective を計算します。Rθ_JA はパッケージ検索テーブル（SOT-223：60°C/W、QFN-5x5：25°C/W など）から取得し、PCB のサーマルビアと銅箔領域に応じて補正します。ルール：

ルール	条件	重大度
TS-001	Tj が絶対最大定格を超える	CRITICAL
TS-002	Tj が絶対最大定格の 15°C 以内	HIGH
TS-003	Tj > 85°C（近くの受動部品に影響する可能性あり）	MEDIUM
TS-004	サーマルビアがない状態で P > 0.5W	MEDIUM
TS-005	安全範囲内で、相当な電力を消費する	INFO
TP-001	高温部品から 10mm 以内に MLCC がある	LOW
TP-002	高温部品から 10mm 以内に電解コンデンサーがある	MEDIUM

熱に関する検出結果と評価には、詳細な形式のエンベロープ（detector、rule_id、summary、evidence_source、report_context）が含まれます。ルール ID：TS-001..005（安全性）、TP-001..002（近接性）、TH-DET（評価）。

インタラクティブな「What-If」パラメータスイープ

完全なアナライザーを再実行せずに、部品値の変更が回路の動作に与える影響をすぐに確認できます。ユーザーが「値を変更したらどうなる」「もし〜ならどうなる」「別の値を試して」「R5 を 4.7k に変更して」「パラメータスイープ」「X を得るにはどの値が必要」などと言った場合や、設計上のトレードオフを検討したい場合に使用します。リファレンス全文： references/what-if.md。

# Single value change
python3 <skill-path>/scripts/what_if.py analysis.json R5=4.7k --text

# Sweep: comma list or log range
python3 <skill-path>/scripts/what_if.py analysis.json R5=1k,2.2k,4.7k,10k --text
python3 <skill-path>/scripts/what_if.py analysis.json R5=1k..100k:10 --text

# Tolerance corner analysis (±5% worst-case)
python3 <skill-path>/scripts/what_if.py analysis.json R5=4.7k+-5% C3=100n+-10% --text

# Find the right value: inverse solver with E-series snapping
python3 <skill-path>/scripts/what_if.py analysis.json --fix voltage_dividers[0] --target 3.3 --text
python3 <skill-path>/scripts/what_if.py analysis.json --fix rc_filters[0] --target 1000 --text

# EMC impact preview
python3 <skill-path>/scripts/what_if.py analysis.json C3=1u --emc --text

# SPICE re-simulation on affected subcircuits
python3 <skill-path>/scripts/what_if.py analysis.json R5=4.7k --spice --text

# Export patched JSON for further analysis (EMC, thermal, diff)
python3 <skill-path>/scripts/what_if.py analysis.json R5=4.7k --output patched.json

アナライザーの JSON 内の部品値を変更し、派生フィールド（フィルターのカットオフ周波数、分圧比、オペアンプのゲイン、水晶発振器の負荷、電流検出範囲、レギュレーターの Vout）を再計算して、変化率とともに変更前後を比較表示します。単一値の変更、複数ポイントのスイープ（カンマ区切りまたは対数範囲）、公差コーナー解析、E 系列へのスナップを伴う逆算による修正案、EMC への影響プレビュー、PCB 寄生成分の考慮（自動検出または --pcb を使用）、および SPICE による再検証に対応しています。

検出結果の概要

実行時にすべてのアナライザーが検出した結果を要約します。個別の JSON ファイルを読まずに、上位 N 件の一覧、重大度で絞り込んだ表示、または機械可読形式での集約結果をユーザーが求める場合に使用します。現在の実行結果を analysis/manifest.json から読み込みます。

# Top findings from the current run (default: top 20)
python3 <skill-path>/scripts/summarize_findings.py analysis/

# Limit to top 10 high-severity findings
python3 <skill-path>/scripts/summarize_findings.py analysis/ --top 10 --severity high

# JSON output for programmatic consumption
python3 <skill-path>/scripts/summarize_findings.py analysis/ --json

# Summarise a specific run by ID
python3 <skill-path>/scripts/summarize_findings.py analysis/ --run <run_id>

フラグ：--top N（デフォルトは 20）、--severity（critical／high／warning／info に絞り込み）、--run（最新ではなく、明示的に実行 ID を指定）、--json（機械可読形式で出力）。

コンポーネントのライフサイクルと温度の監査

販売代理店の API に問い合わせて、コンポーネントのライフサイクル状況（アクティブ、NRND、EOL、廃止）と動作温度範囲への適合状況を確認します。ユーザーが「廃止された部品がないか確認して」「ライフサイクル監査」「生産終了になった部品はあるか」「温度監査」「産業用温度範囲で動作するか」と言った場合や、生産準備レビューの際に使用します。

# Basic lifecycle check
python3 <skill-path>/scripts/lifecycle_audit.py analysis.json

# With temperature range validation (preset or custom)
python3 <skill-path>/scripts/lifecycle_audit.py analysis.json --temp-range industrial
python3 <skill-path>/scripts/lifecycle_audit.py analysis.json --temp-range="-40,105"

# Query specific distributors only
python3 <skill-path>/scripts/lifecycle_audit.py analysis.json --only digikey,lcsc

# Search for replacement parts when EOL/NRND found
python3 <skill-path>/scripts/lifecycle_audit.py analysis.json --suggest-alternatives

# Save results
python3 <skill-path>/scripts/lifecycle_audit.py analysis.json --output lifecycle.json

アナライザーの JSON BOM セクションを読み込み、一意な MPN を抽出し、販売代理店（認証不要の LCSC、DigiKey、element14、Mouser）に問い合わせて、ライフサイクル状況と動作温度を確認します。温度プリセットは commercial（0/70°C）、industrial（-40/85°C）、extended（-40/105°C）、automotive（-40/125°C）、military（-55/125°C）です。また、API 呼び出しを行う前に、データシート抽出キャッシュから温度データも確認します。

ライフサイクル監査では、詳細な形式の指摘事項を生成します：LC-001（廃止／製造中止）、LC-002（最終購入）、LC-003（NRND）、LC-004（状況不明）、LC-005（単一供給元）、LC-006（長いリードタイム）、LT-001（温度違反）。--lifecycle が指定されていない場合（デフォルト）、analyze_schematic.py は監査がスキップされたことを示す情報レベルの指摘事項 LC-007 を出力します。これにより、レポートの指摘事項一覧に監査漏れが明示され、黙って省略されることを防ぎます。

ネットワークアクセスが必要です — コアアナライザーとは異なり、このスクリプトは販売代理店の API を呼び出します。販売代理店スキルと同じ環境変数（DIGIKEY_CLIENT_ID/SECRET、MOUSER_SEARCH_API_KEY、ELEMENT14_API_KEY）を使用します。LCSC には認証情報は不要です。

回路図アナライザーのルール ID

回路図ルールの指摘事項はすべて findings[] に表示されます。回路図アナライザーが生成するルール ID は次のとおりです。

ルール	検出器	条件	重要度
SS-001	audit_sourcing_gate	MPN の網羅率 < 50%	high
SS-002	audit_sourcing_gate	MPN の網羅率 50–80%	warning
SS-003	audit_sourcing_gate	MPN の網羅率 80–100%	info
NT-001	analyze_connectivity	単一ピンのネット：信号ピン	warning
NT-001	analyze_connectivity	単一ピンのネット：power_out または passive ピン	info
RS-001	audit_rail_sources	電源レールに宣言された電源元がない（power_out ピン、PWR_FLAG、またはブリッジされたジャンパーやレギュレーター出力がない）	warning
RS-002	audit_rail_sources	電源レールが、ユーザーによる開放状態のジャンパーの接続に依存している	high
RS-003	audit_rail_sources	ブリッジ状態がデフォルトのはんだジャンパーまたはフェライトを介して間接的に電源が供給されている — 機能上は問題ありませんが、PWR_FLAG の追加を検討してください	info
LB-001	detect_label_aliases	ネットに相異なるグローバル／階層ラベルが 2 個以上ある（電源ネットは除外）	info
PP-001	audit_power_pin_dc_paths	IC の power_in ピンが、コンデンサーを介した場合にのみ電源レールに到達する（2 ホップ BFS）	high
SP-001	detect_shorted_two_pin_components	2 ピンの受動部品またはダイオードの両ピンが同一ネットに接続されている（ジャンパー、ネットタイ、0R、DNP は除外）；同一ネット上に 5 個以上ある場合はネットレベルの指摘事項 1 件にまとめられる	warning

SS-001 は製造前の阻止要因です。発注前に解決すべき high の指摘事項です。NT-001 の重要度はピンの種類によって異なります。信号ピン（デジタル I/O、双方向）は warning、power_out ピンと passive ピンは info です。RS-001 は「電源元がまったくない」ケース専用（warning）です。「ブリッジされたジャンパー／フェライトを介して電源が供給される」という軽微なケースには、独自の rule_id RS-003（info）があり、レビュー担当者や CI ゲートが両者を個別にフィルタリングできます。PP-001 は、コンデンサーを介するエッジを除外しながら、ネットグラフ上で 2 ホップの BFS を実行し、電源レールから各 IC の power_in ピンへの直接的な DC パスを確認します。モジュール内部の LDO 電源レール（VDDPLL_*、VDDA_INT_*、VDDCORE_*、VCAP、VDDREG）では、デカップリングのみが正しいトポロジーであるため、PP-001 の重要度は info に引き下げられます。

詳細レビュー

アナライザーの実行後、詳細レビューパスを実施します。IC ごとに、実際の使用状況とデータシートの要件を比較します。アナライザーが事実を提示し、このパスで判断を行います。

設計内の各 IC について、次の手順を実行します。

1. データシートの情報を取得します。まず抽出キャッシュ（datasheets/extracted/<MPN>.json）を確認し、なければ PDF を直接読み取ります。どちらも存在しない場合は、「 は未検証 — データシートなし」という情報レベルの指摘を記録して、次に進みます。
2. アナライザーの JSON に記録された実際の使用状況と比較します。電源電圧と定格、ピンの機能と接続、必要な外付け部品（インダクター、コンデンサー、抵抗器）と回路図上の部品、熱環境などを確認します。確認項目はデータシートから導き出します。部品ごとに確認項目は異なります。
3. 上限値の計算が必要な場合は、analysis/helpers/ に使い捨てのヘルパースクリプトを作成し、アナライザーの JSON を読み込んで数値を出力します。スクリプトと結果を根拠として引用します。
4. analysis/deep_review.json に指摘を記録します（形式：skills/kicad/review/schemas/deep_review.schema.json）。各指摘には根拠ブロックが必要です。設計上のアンカー（コンポーネント／ネット／ピン）を 1 つ以上、情報源（データシートの引用および／または計算結果）を 1 つ以上含めてください。

続いて、相互に関連するペアを確認します。共有レール（シーケンス、合計負荷）、バスの接続相手（電圧レベル、プルアップの所有者）、熱的に近接する部品などが対象です。気になる点があれば、自由に掘り下げてください。

報告前に検証します。

python3 skills/kicad/review/scripts/deep_review_gate.py \
    analysis/deep_review.json --analysis-dir analysis/

ゲートが引用を検証し、finding_ids を付与し、失敗した項目を理由とともに quarantined[] に移動します。隔離された項目は修正するか、受け入れてください。レポートでは、これらは未検証の主張として表示されます。

再レビュー：以前のレビューで作成された analysis/deep_review.json がすでに存在する場合は、まず別の場所にコピーし、新しいレビューを差分の確認から始めます。「Previous Review Delta」セクションに、修正済み／未解決／新規を記載してください。

cp analysis/deep_review.json analysis/deep_review.prev.json
# ... run the pass, then the gate ...
python3 skills/kicad/scripts/diff_analysis.py \
    analysis/deep_review.prev.json analysis/deep_review.json --text

BOM が大きい場合は、サブシステムごとに分割するか、サブエージェントを使って IC グループごとに並行して進めてください。部品クラスごとの比較のヒューリスティック、ペアの確認パターン、ヘルパースクリプトの規約については、references/deep-review.md を参照してください。analysis/design_context.json がある場合は、レビューの優先順位付けに利用します。たとえば、自動車向け設計ではディレーティングへの注意を強化します。任意項目のため、これを理由にレビューを止めないでください。

参考ファイル

詳細な手法と形式のドキュメントは、参考ファイルに記載されています。必要に応じて参照してください。スクリプトが自動出力する内容を超える詳細な情報が得られます。

参考資料	行数	参照するタイミング
deep-review.md	—	詳細レビューのパス：部品クラスごとの比較ヒューリスティクス、ペアチェック、ヘルパースクリプトの規約、ファンアウト
schematic-analysis.md	1133	回路図の詳細レビュー：データシート検証、設計パターン、エラー分類、許容差の積み重ね、GPIO の監査、モーター制御、バッテリー寿命、サプライチェーン
pcb-layout-analysis.md	447	高度な PCB 分析：インピーダンス計算、差動ペア、リターンパス、銅箔バランス、基板端からのクリアランス、銅箔の影響を受けやすい部品（静電容量式タッチ、アンテナ）、カスタム分析スクリプト
output-schema.md	293	アナライザーの完全な JSON スキーマ（フィールド名、型、一般的な抽出パターン）
file-formats.md	379	ファイルの手動確認：S 式の構造、すべての KiCad ファイル形式のフィールドごとのドキュメント、バージョン検出
gerber-parsing.md	729	Gerber/Excellon 形式の詳細、X2 属性、分析手法
pdf-schematic-extraction.md	315	PDF 回路図の分析：抽出ワークフロー、表記規則、KiCad への変換
supplementary-data-sources.md	288	レガシーな KiCad 5 データの復元：ネットリストの解析、キャッシュライブラリ、PCB の相互参照
net-tracing.md	120	ネットの手動トレース：座標計算、Y 軸の反転、回転変換
manual-schematic-parsing.md	289	回路図スクリプトが失敗した場合の代替手順
manual-pcb-parsing.md	467	PCB スクリプトが失敗した場合の代替手順
manual-gerber-parsing.md	621	Gerber スクリプトが失敗した場合の代替手順
report-generation.md	614	レポートテンプレート（重要な指摘事項を冒頭に記載）、アナライザーの出力フィールドリファレンス（回路図／PCB／Gerber）、重大度の定義、記述の原則、分野固有の重点項目、既知のアナライザーの制限事項
standards-compliance.md	638	IPC/IEC 規格の表：導体間隔（IPC-2221A Table 6-1）、電流容量（IPC-2221A/IPC-2152）、環状リング、穴径、インピーダンス、ビア保護（IPC-4761）、沿面距離／空間距離（ECMA-287/IEC 60664-1）。すべての基板で検討してください。プロ向け／産業用設計、高電圧、商用電源入力、安全絶縁の場合は自動的に対象となります。
oshwa-certification.md	—	OSHWA オープンソースハードウェア認証への準備状況：編集可能な KiCad ソース、公開ドキュメント、ライセンス、バージョン登録、認証マークの使用。ユーザーが OSHWA 認証またはオープンソースハードウェアの公開について尋ねた場合に参照してください。これは電気的なチェックではなく、明示的な承認ゲートを設けたドキュメント／ライセンスの監査です。
design-intent.md	—	設計意図の確認、指摘事項を状況に応じて絞り込むためのターゲット市場／認証／電源の制約
diff-analysis.md	—	diff_analysis.py が 2 つのアナライザー実行結果を比較し、重大度順の変更レポートを出力する方法
what-if.md	—	what_if.py が部品値を変更し、派生フィールドを再計算し、フィードバック分圧器／水晶負荷コンデンサー／コンデンサーのディレーティングに対する修正案を提示する方法
config-reference.md	—	.kicad-happy.json スキーマ — 分析キャッシュ、抑制項目、設計意図、リスクスコアリングのプロジェクト設定
datasheet-verification.md	—	回路図の接続を、構造化されたデータシート抽出情報（ピン電圧、必要な外付け部品、デカップリングの妥当性）と自動照合する方法

スクリプトの内部処理、データ構造、信号分析のパターン、バッチテストスイートのドキュメントについては、scripts/README.md を参照してください。

ファイル形式のクイックリファレンス

拡張子	形式	用途
.kicad_pro	JSON	プロジェクト設定、ネットクラス、DRC/ERC の重大度、BOM フィールド
.kicad_sch	S-expr	回路図シート（シンボル、配線、ラベル、階層）
.kicad_pcb	S-expr	PCB レイアウト（フットプリント、配線、ビア、ゾーン、基板外形）
.kicad_sym	S-expr	シンボルライブラリ（ピンや図形を含む回路図シンボル）
.kicad_mod	S-expr	単一のフットプリント（.pretty/ ディレクトリ内）
.kicad_dru	Custom	カスタム設計ルール（DRC 制約）
fp-lib-table / sym-lib-table	S-expr	ライブラリパステーブル
.sch / .lib / .dcm	Legacy	KiCad 5 の回路図、シンボルライブラリ、説明
.net / .xml	S-expr/XML	ネットリストのエクスポート、BOM のエクスポート
.gbr / .g* / .drl	Gerber/Excellon	製造ファイル（銅箔、マスク、シルク、外形、ドリル）

バージョンの検出と、フィールドごとの詳細な形式ドキュメントについては、references/file-formats.md をお読みください。Flatpak 版の KiCad では kicad-cli（ネイティブの DRC/ERC レポート、ファイルのエクスポート）が PATH に含まれていません。flatpak run --command=kicad-cli org.kicad.KiCad <args> として実行してください。サンドボックスからホストの /tmp を読み取れないため、エクスポートファイルやネットリストはプロジェクトディレクトリ内（または $HOME 配下の別の場所）に書き込んでください。

分析戦略

回路図の詳細分析

データシートに基づく徹底的な回路図レビュー（サブ回路の特定、データシートの取得、メーカーの推奨事項に照らした部品値の検証、一般的な設計パターンとの比較、エラーの検出、改善案の提示）については、references/schematic-analysis.md をお読みください。ユーザーが回路図の詳細なレビュー、検証、分析を求めた場合は、必ずこのリファレンスを使用してください。

データシートの取得：分析でデータシートの情報が必要な場合は、優先ソースとして DigiKey API を使用してください（digikey スキルを参照）。Web スクレイピングなしで、DatasheetUrl フィールドから直接 PDF URL を取得できます。回路図の部品プロパティにある MPN で検索してください。DigiKey にない部品についてのみ、Web 検索に切り替えてください。

PCB の詳細分析

PCB アナライザースクリプトで提供される機能を超える高度なレイアウト分析（スタックアップのパラメーターに基づくインピーダンス計算、DRC ルールの作成、パワーエレクトロニクスの設計レビュー手法、差動ペアの検証、リターンパス分析、銅箔バランスの評価、基板端クリアランスルール、手動でスクリプトを書くパターン）については、references/pcb-layout-analysis.md をお読みください。

一般的な PCB 分析（ビアの種類、アニュラリング、配置、接続性、サーマルビア、電流容量、シグナルインテグリティ、DFM スコアリング、マンハッタン現象のリスク、サーマルパッドのビア）は、analyze_pcb.py が自動で処理します。より詳細な手動調査には、このリファレンスを使用してください。

設計意図

自動検出された設計意図の解釈や、製品クラスおよびターゲット市場（ホビー向け、民生用、産業用、医療用、自動車用、航空宇宙用）に応じたレビューの重大度の調整については、references/design-intent.md をお読みください。分析出力の design_intent オブジェクトを確認し、設計のコンテキストを把握してください。

Analyzer JSON の調査

レビュー中は、アナライザーの出力（ピンとネットの接続、電源レールの電圧、特定の検出結果の内容など）を調べるために、単発の python3 -c "import json; ..." プローブを実行することがよくあります。次の 2 つの方法を実践すると、ユーザーが内容を追いやすくなります。

各プローブの前に、何を確認するのかを伝えてください。 スクリプトの前に、簡潔な一文を添えます。後からではなく、スクリプト内のコメントでもありません。ユーザーがツールの呼び出しをすべて開かなくても、説明だけでレビューの流れを理解できるようにします。

• 悪い例：周囲に説明がないまま [Bash] python3 -c "import json; d = json.load(open('analysis/.../schematic.json')); print([...])" を実行する。
• 良い例：「U3 の EN ピンが +BATT に直接つながっているのか、分圧回路を介しているのかを確認します。」と伝えてからプローブを実行する。
• 良い例：「検出された TPS61023 のトポロジーがデータシートと一致する（昇降圧が想定される）かを確認します。」と伝えてからプローブを実行する。

特に、何かがおかしく見える理由を調べるプローブでは、説明が重要です。こうした場面では、ユーザーが状況を把握しにくくなります。

JSON の構造が不確かな場合に備えるパターン。 アナライザーの出力は、辞書のリスト、参照番号をキーとする辞書、省略可能なセクション、ネストされたパスなど、さまざまな構造を取ります。構造を誤って想定したスクリプトは、プローブの途中でクラッシュします。

• スライスする前に型を確認します。辞書に対する x[:3] は KeyError: slice(None, 3, None) を発生させます。辞書の場合は list(x.values())[:3] または list(x.items())[:3] を使います。
• min()／max() を使う前に、要素が空でないことを確認します。min([]) は ValueError: min() iterable argument is empty を発生させます。min(items, default=None) を使うか、if items: でチェックします。
• セクションが存在しない場合があるとき（アナライザーの検出内容によって省略可能なセクションは多数あります）は、["key"] ではなく .get("key", default) を使います。
• isinstance(x, list) と isinstance(x, dict) を使い分けます。components は辞書のリストで、nets はネット名をキーとする辞書です。反復処理の前にスキーマのリファレンスを確認してください。
• 検出結果のフィールドが文字列のリスト、または辞書のリストになり得る場合（レガシー形式のセクションでまれに発生します）は、どちらにも対応します。r = c if isinstance(c, str) else c.get("reference", "")
• パッド／コンポーネントのデータが欠けている場合：pad.get("abs_x") が None のことがあります。算術演算の前にチェックしてください。

少し手間をかけるだけで、作業がずっとスムーズになります。

アナライザー JSON ではなく、生の .kicad_sch／.kicad_pcb ファイルを調べる場合は、<skill-path>/scripts/sexp_parser.py を使います。parse(text) と parse_file(path) は、ドキュメントをネストされた Python リストとして返します。find_all(node, kw)、find_first(node, kw)、get_value(node, kw) を使って移動できます。

クイックレビュー用チェックリスト

回路図 — 以下を確認します：すべての IC の VCC/GND ペアにデカップリングコンデンサがあること、I2C のプルアップ抵抗、リセットピン回路、未接続ピンに No Connect マーカーが付いていること、シート間でネット名に一貫性があること、外部コネクターに ESD 保護があること、電源シーケンス（EN/PG）、十分なバルク容量。

PCB — 以下を確認します：電流に対する電源配線幅（IPC-2221）、ビアの電流容量、高電圧に対する沿面距離／空間距離、IC の電源ピンに近接したデカップリングコンデンサ、連続したグランドプレーン（信号の下に分割がないこと）、制御インピーダンス配線（USB/DDR）、閉じたポリゴンとしての基板外形、シルクスクリーンの視認性、露出パッド付き IC ごとのサーマルビア数（数を報告し、データシートの推奨範囲と比較してください。これは QFN/DFN のレイアウトで最もよくあるエラーの 1 つです）、銅箔に敏感な部品（タッチパッドやアンテナ）のキープアウトゾーンの適用（銅箔がないことの確認だけでは不十分です。偶然そうなっている可能性があるためです。DRC ルールとしてキープアウトゾーンが存在することを確認してください）、プロトコル固有の許容差に対する差動ペアの長さの差（差を計算して仕様を引用してください。長さだけでは、設計者は問題の有無を判断できません）、すべての IC／トランジスタ／コネクターについて、PCB レベルでパッドとネットを相互参照すること（DRC/ERC では検出できない、ライブラリフットプリントのピン番号エラーを見つけられます。これは最も危険な種類の PCB バグです）。IPC/IEC 規格値については references/standards-compliance.md を参照してください。導体間隔と電流容量はほとんどの基板で重要です。沿面距離／空間距離とビアの保護は、商用電源に接続する設計や安全絶縁を施した設計で適用されます。

よくあるバグ（基板を動作不能にする可能性が高い順）：IC ピンの入れ替わり（ライブラリシンボルとデータシートのピン配置の不一致。DRC/ERC では検出できません）、トランジスタのピン配置の曖昧さ（MPN のない SOT-23。シンボルが想定するピン順が実際の部品と一致しない可能性があります。確認できない場合は、一般的な慣例に照らして妥当性を評価してください）、フットプリントのパッド番号の誤り、同期されていない回路図→PCB に起因するネットの欠落、パッケージバリエーションの誤り（SOT-23 と SOT-23-5 の取り違え）、デジタル入力のフローティング、バルクコンデンサの欠落、極性の逆転、フィードバック分圧器の値の誤り、水晶振動子の負荷コンデンサの誤り、USB のインピーダンス不整合、QFN のサーマルパッドにビアがないこと、コネクターのピン配置エラー、一般的でない受動部品の値（技術的には有効でも、用途としては一般的でない値。例：標準外のプルアップ抵抗値や、珍しいデカップリングコンデンサの値）。

レポートの作成

設計レビューのレポートを作成する際は、標準のレポートテンプレート、重大度の定義、執筆の原則、分野固有の重点項目について references/report-generation.md を読んでください。レポート形式には、概要、部品の要約、電源ツリー、アナライザーによる検証（抜き取り確認）、信号／電源／設計の分析レビュー、品質と製造、優先順位付きの問題一覧、好ましい点、既知のアナライザーの不足事項が含まれます。指摘事項を報告する前に、必ずアナライザーの出力を回路図の生データと相互照合してください。

設計の比較

2 つの設計を比較する際は、部品の数と種類、ネットクラス／設計ルール、配線幅／ビアサイズ、基板寸法／レイヤー数、電源トポロジー、KiCad のバージョンの違いを比較します。

セキュリティアーキテクチャ

すべての解析スクリプトは、信頼できない入力（ユーザーが提供する KiCad ファイル、サードパーティ製 PDF データシート、販売代理店 API のレスポンス）を処理します。解析アーキテクチャにより、プロンプトインジェクションとコード実行のリスクを軽減します。

• 決定論的なパーサー：S 式ファイル（.kicad_sch、.kicad_pcb）は、専用の再帰下降パーサー（sexp_parser.py）で解析します。eval()、exec()、その他のコード実行プリミティブは使用しません。パーサーが生成するのは Python のリストと文字列のみです。
• 構造化 JSON 境界：すべてのアナライザー出力は、固定スキーマに基づく構造化 JSON です。外部コンテンツ（コンポーネントの値、ネット名、データシートのテキスト）はデータフィールドとして扱い、指示やコードとして扱うことはありません。
• PDF 処理：データシート PDF は pdftotext（外部バイナリ、リスト形式の引数を使用し、シェルインジェクションを防止）で処理し、ページの内容を LLM に渡して構造化された情報を抽出します。抽出データは、キャッシュする前に 5 つの観点からなる品質評価基準に照らして検証します。
• 入力からのシェルコマンド生成なし：アナライザーがファイルの内容からシェルコマンドを組み立てることはありません。サブプロセスの呼び出しには、リスト形式の引数のみを使用します。
• デフォルトで読み取り専用：解析スクリプトが入力ファイルを変更することはありません。BOM への書き戻しには、明示的な --write フラグが必要です。
• 販売代理店 API の範囲：ネットワークリクエストは、データシートのダウンロードとコンポーネントの検索に利用する、既知の販売代理店 API（DigiKey、Mouser、LCSC、element14）に限定されています。送信するのは MPN のみで、設計データがローカルマシンの外部に送信されることはありません。