カスタムデータソース

Updated: 5月 21, 2026

Validation logic is only as reliable as the data it validates against. Custom data sources connect your authoritative external systems into Altium platform processes – so that checks run against current, live data, not a snapshot that goes stale.

Behavior Extensibility において、カスタムデータソースは独立したインフラストラクチャコンポーネントではなく、Python のチェックやスクリプトが外部データにアクセスするためのパターンです。Python で記述されたチェックは、アクセス可能な任意の API を呼び出し、到達可能な任意のデータベースに問い合わせ、その結果を検証ロジックの一部として利用できます。外部システムは引き続き正式な情報源です。Altium はそれを問い合わせるのであって、コピーを保持するわけではありません。

これにより、ロードマップにおける Customizability の主張、すなわち「チェックは社内の部品データベース、承認済みベンダー一覧、ERP システムにアクセスし、結果を返せる」が具体的なものになります。カスタムデータソースとは、それを実現する呼び出しのことです。

ライブデータアクセスが重要な理由

チェックロジックに埋め込まれた静的リストに対してコンポーネント承認を検証するチェックは、作成時点では正しくても、数週間後には誤りになる可能性があります。承認済み部品リストは変化します。制限材料リストも変化します。ライフサイクルステータスも変わります。ライブシステムを呼び出すチェックであれば、実行のたびに最新の答えを取得できます。

これは、ルールをコード化することと、知識をコード化することの違いです。静的リストは、ある時点での知識の状態をコード化したものです。ライブデータソースの呼び出しは、正式なシステムの現在の状態が適合性を決定する、というルールをコード化したものです。後者のアプローチの方が陳腐化しにくいのです。

一般的な外部データソース

Approved Vendor / Manufacturer Lists (AVL/AML) – 調達チームまたはコンポーネントエンジニアリングチームが、承認済みメーカーおよびベンダーの正式なリストを管理している場合があります。このリストをライブで照会するチェックにより、Altium で承認済みとしてフラグ付けされたコンポーネントが、チェック実行時点で正式なシステム上でも実際に承認済みであることを保証できます。これは、誰かが最後にローカルファイルを更新した時点の情報ではありません。
Component qualification databases – コンポーネント認定プロセスが成熟している組織では、認定ステータス、試験データ、適用制限、承認済み使用用途に関する内部データベースを維持しています。このデータを Altium のチェックに接続することで、認定ステータスを設計段階で可視化し、強制できるようになり、リリースレビュー時に初めて発覚する事態を防げます。
ERP and inventory systems – リードタイム、在庫レベル、または調達状況をライブ ERP データに照らして検証するチェックにより、エンジニアは設計中に調達を意識した判断を行えるようになり、設計完了後に供給問題へ気付く事態を避けられます。
Compliance and restricted materials databases – ITAR、EAR、RoHS、REACH、および社内 IP 管理リストはコンプライアンスチームによって維持され、時間とともに変化します。ライブのコンプライアンスデータを照会するチェックは、ポリシーが変更されるたびにチェック自体を更新しなくても、現在のポリシー状態を適用できます。
Internal parametric and specifications data – 組織内で維持されているエンジニアリング標準、推奨コンポーネント仕様、社内データシート、試験結果は、Altium のチェックやパネルに表示でき、エンジニアが意思決定の時点で社内知識にアクセスできるようになります。

実装上の考慮事項

Accessibility – サーバーサイドプラットフォーム上で実行されるチェックは、サーバーのネットワークコンテキストから外部システムへ到達できる必要があります。Altium Designer 上でクライアントサイド実行されるチェックは、エンジニアのマシンから到達できる必要があります。外部呼び出しに依存するチェックを構築する前に、ネットワーク接続性を確認してください。
Latency – デスクトップ側のチェックは、エンジニアの作業中に実行されます。外部 API が遅く、応答に数秒かかるチェックは摩擦を生み、エンジニアはそれを回避しようとします。外部呼び出しは高速かつ対象を絞ったものにし、データが頻繁に変化しない場合はキャッシュ可能にしてください。
Failure handling – 外部システムが利用できない場合でも安全に失敗するよう、チェックを設計してください。AVL に到達できないチェックは fail closed とすべきです。つまり、コンポーネントが承認済みであると判断するのではなく、チェックを完了できなかったことを報告すべきです。データソースに到達できなかったためにチェックが黙って通過してしまうのは、信頼性上の欠陥であり、コンプライアンス上の問題を引き起こします。
Authentication – チェックロジックからの外部 API 呼び出しには認証情報が必要です。認証情報は、チェックのスクリプトにハードコードするのではなく、Workspace のシークレットまたは環境設定として保存してください。チェックコードは、認証情報を扱う本番コードと同様に扱うべきです。