Nexar API の解説：その概要、仕組み、そして利用者にもたらす変化

まず、APIとは何か

APIは application programming interface（アプリケーション・プログラミング・インターフェース）の略です。人はWebサイトをクリックして読み進めながら利用しますが、プログラムはクリックできません。そのため、正確な質問を投げかけ、理解できる形式で正確な答えを受け取るためのサービス窓口が必要になります。その窓口がAPIです。Octopartは、ユーザーが電子部品を検索し、あらゆる角度からその情報を確認できるWebサイトです。この表示には、その部品を在庫している企業、価格、ライフサイクルステータス、技術属性などが含まれます。さらに、ある部品を検索して、それに類似する他の部品を確認することもできます。Nexar APIは、これと同じ情報を御社の業務ソフトウェアシステムに直接提供します。

Nexar APIを利用するメリット

• 独自ツールへの統合: Nexar APIの最新データを、カスタムの発注管理システムや製品ライフサイクル管理システムなどの社内システムに直接組み込めます。
• 供給データだけではない: 供給情報に加え、Nexar APIはお使いの Altium 365 ワークスペースから設計データも取得できるため、1つの統合で調達データと設計データをまとめて扱えます。
• チーム間での一貫性: 同じクエリを使う全員に、同じ値が返されます。つまり、同じ価格、同じ在庫水準、同じ単位が、同じ時点の情報として返ってきます。数値の比較可能性が、人をまたいでも、レポートをまたいでも、時系列でも維持されます。
• 大規模な自動化: Nexar APIを使えば、1回で最大100部品をプログラムから照会でき、1分あたり最大300クエリを実行できます（理論上、1分で30,000部品を分析可能です！）

Nexar API

Nexar APIは主に次の要素で構成されています: 

• 供給データ はOctopartの部品情報です。APIの供給側では9,500万点を超える部品にアクセスでき、在庫、価格、ライフサイクルステータス、リードタイム、データシート、技術属性、CADモデル、類似部品候補などを、電子部品ディストリビュータから取得し、毎日更新しています。 

• 設計データ はAltiumユーザー向けで、プロジェクトやコンポーネント詳細を含む設計ワークスペースの内容を対象とします。ここで公開されているNexar Data Modelが役立ちます: Nexar Voyager。このデータモデルでは、各オペレーションに対象を示すプレフィックスが付いています。 sup は供給、 des は設計、 adm はアカウント管理です。

例1: 欲しい回答の形を自分で記述する

Nexarは、API向けのクエリ言語であるGraphQLを採用しています。他のAPI基盤では、固定されたデータブロックを要求し、それを丸ごと受け取ったうえで、不要な部分を捨てるコードを書くのが一般的です。GraphQLでは、欲しい回答の形そのものを書き、その形のデータだけが返ってきます。以下は、MPN（manufacturer part number）で検索する際のドキュメント化された形式です:

query MpnSearch { 

  supSearchMpn { 

    results { part { id  name  mpn } } 

  } 

} 

声に出して読むならこうです。メーカー型番で検索を実行し、ヒット件数を教えてください。そして各結果について、部品の識別子、名称、MPNを返してください。それ以外は返しません。さらに多くを求めれば、さらに多くが返ってきます。Altiumのライブデモでは、Renesas RAファミリーのRA0E2マイクロコントローラを検索すると該当部品が返され、技術仕様を追加するとRoHS（特定有害物質使用制限）準拠としてフラグ付けされていることが確認できました。さらにデータシートを追加すると、ファイルへのリンク、ファイル名、作成日が返されました。これは、Octopartが利用可能なデータシートをスコアリングし、最適なものを返せるためです。どの情報も、要求されるまでは返ってきません。

例2: 複数の検索方法

Octopartと同様に、Nexar APIでは部品の検索方法に柔軟性があります。広めの検索をしたい場合は、部分的なMPNで検索したり、キーワードベースで検索したりできます。欲しいものが正確に分かっている場合は、完全一致のMPNで検索できます。

広めの検索でAPIで使用するオペレーションは「supSearch」です。このオペレーションはあいまい一致検索を実行します。

query search { 

  supSearch (q: "Current sensor") { 

    hits 

    results { 

      part { 

        id 

        name 

        shortDescription 

      } 

    } 

  } 

} 

上記の例では、「current sensor」の検索により、ヒット件数、部品ID、名称、そしてその部品の短い説明が返されます。 

「supMultiMatch」オペレーションは、MPNまたはSKU（stock keeping unit）で識別される最大100部品までのリストを受け取り、それらをまとめて照合します。「supSearch」と異なり、「SupMultiMatch」を使用すると部分一致はすべて無視されます。以下の例では2つの部品を問い合わせています:

query MultiSearch { 

  supMultiMatch (queries: [ 

      {mpn: "SY55855VKG", limit: 1}, 

      {mpn: "BAV99-7-F"}, 

  ]) { hits  parts { id  name  mpn } } 

} 

各エントリはBOM（bill of materials）の1行として扱えるため、誰かがブラウザを開かなくても、BOM全体の価格を算出できます。

例3: 設計側とデータの書き戻し

設計側も同じ考え方で動作します。‘desWorkspaces’ のように des で始まるオペレーションは、お使いの Altium 365 ワークスペース内のデータにアクセスします。データはグラフ構造になっているため、どこから開始しても関係をたどって外側へ進めます。たとえば、ワークスペースからその中の設計へ、さらに設計からその中に含まれる内容へと進み、対象はネットやコンポーネント詳細から、MCAD（mechanical computer-aided design）や位置情報にまで及びます。どこまでたどるか、各地点からどれだけの情報を取得するかは自由に選べます。

読み出しは半分にすぎません。mutation は書き込みを行います。たとえばコメントの追加やプロジェクトのアップロードです。ファイルを必要とするオペレーションでは、まず files.nexar.com/File/Upload に対して、design.domain、user.access、openid のスコープを持つトークンを渡して、Nexar file serviceにファイルを投稿します。返されるのは識別子で、未使用であれば24時間有効です。その識別子をリクエスト本体で参照します。この識別子は内部形式が変更される可能性があるため、ブラックボックスとして扱ってください。

これによって業務がどう変わるか

この価値は、すでに3つの役割がどのように時間を使っているか、そしてその時間のどの部分をAPIが取り戻せるかを見ると最も分かりやすくなります。

調達マネージャーまたはバイヤー

EMS（electronics manufacturing services provider）やOEM（original equipment manufacturer）では、この担当者は製造対象のすべての部品が在庫されていることを確認し、納期を満たせるディストリビュータを見つけ、価格を把握し、発注を行います。扱う件数は、週に数件の注文から、1日に50～100件に及ぶこともあります。通常、この作業はスプレッドシートを見ながら部品ごとに行われます。1つのMPNを入力し、在庫を確認し、ディストリビュータのページにクリックして進み、これを繰り返します。まず認定ディストリビュータを確認し、在庫がない場合にのみ非認定ブローカーへ検索範囲を広げます。多くのバイヤーは、夜間に状況が変わっている可能性があるため、発注直前にもう一度確認します。

これらの各ステップには、上で説明したAPI上の対応手段があります。1回のAPIクエリで、100件の個別検索を置き換えられます。APIの認定先限定フィルタを使えば、「まず優先先を確認し、それから広げる」という判断を、手作業による再検索ではなく設定として表現できます。発注前の再確認は、スケジュール実行され、変化があった場合だけ通知するジョブに変えられます。APIが取り戻すのは判断そのものではなく、それを現在消耗させている入力作業やタブ切り替えです。事前交渉済みの契約価格は引き続きディストリビュータ側にあるため、APIは購入注文を置き換えるものではなく、候補の絞り込みや変更検知のためのものです。

設計エンジニア

OEMでは、この担当者がブロック図から部品選定、回路図作成、レイアウト、BOMリリースに至るまで、電気設計ライフサイクル全体を担います。この人にとっての制約は明確です。調達できない部品は設計上の問題です。そのためOctopartは、「この部品は本当に購入可能か、しかも複数の供給元から調達できるか」を確認する検証ステップとして使われると同時に、候補部品を探して比較するための探索ツールとしても使われます。ディストリビュータの広がり自体がシグナルになります。なぜなら、1社しか在庫していない部品や、複数のディストリビュータがあっても全体在庫が週ごとに減少している部品は、調達問題になる前の段階ですでにサプライチェーンリスクだからです。

これをAPIで実行すると、その確認作業は部品ごとの反射的な習慣ではなく、ゲートになります。BOMの全行をリリース時に検証でき、ディストリビュータが1社しかないもの、在庫が薄いもの、ライフサイクル上の警告があるものを、設計承認後の数か月後ではなく、サインオフ前に表面化できます。これが対処する不安は具体的でコストも高いものです。つまり、設計採用後に部品がEOL（end of life）となり、再設計を強いられることです。データシートも同時に独自ツールへ取り込めますが、エンジニアが最終的にデータシートそのもので仕様を確認すべきである点は変わりません。

コンポーネントエンジニア

中規模から大規模のOEM、特に航空宇宙、防衛、自動車、医療分野に見られる役割で、この担当者は通常、新規設計は行いません。すでに生産中の部品を管理し、承認済み部品ライブラリを最新に保ち、陳腐化を危機になる前に捉え、部品が生産中止になった際には代替品を認定します。リスクのある部品はウォッチリストに載せて定期的に確認します。というのも、生産中止になった部品が再び市場に戻ることもあるためです。

自己検証型のウォッチリストは、この記事の中で最もわかりやすい成果です。誰かがリストを見直すことを覚えておく必要があるのではなく、スケジュールされたクエリがそのリストを巡回し、例外を報告します。1つのアプリケーション内で調達と設計のスコープをまとめて保持できるため、同じ実行の中で、設計側ではライブラリを読み取り、調達側では最新の市場データと比較できます。これにより、定期的な手作業の監査が常時実行されるレポートへと変わります。Octopart は依然として候補を広げる入口であって、そこで完結するものではありません。候補となる代替部品や市場での入手性はここから得られますが、形状・適合性・機能、コンプライアンス、ライフサイクルの検証は、引き続き PLM（製品ライフサイクル管理）ツールや専門のデータプロバイダーで行われます。

3者に共通すること

これらのペルソナはいずれも、新しいWebサイトを訪れたいと言っているわけではありません。彼らが求めているのは、すでに業務で使っているシステムの中に、必要なその瞬間に、誰かが取りに行かなくても答えが届くことです。それこそが API の役割であり、Nexar 自身が掲げる目的――情報を民主化し、人々をつなぎ、より効率的に働き、より賢いビジネス判断を行えるようにすること――にも非常に近いものです。

セットアップ方法

1. メールアドレスとパスワード、または Google、Facebook、Altium 365 の認証情報を使って、 portal.nexar.com で登録します。すでに Altium 365 で SSO（シングルサインオン）を利用している組織は、その方法でサインインできます。
2. 組織を作成するか、既存の組織に参加します。 この手順は必須です。既存の組織に参加するには、メンバーに招待してもらってください。
3. 登録が完了するとすぐに、あらかじめ構築された「Evaluation」アプリケーションが用意され、利用できます。必要に応じて Apps に移動し、追加のアプリケーションを作成することも可能です。
4. API ダッシュボード内にはサンドボックス環境があり、すぐに試すことができます。データを自分のツールやアプリケーションに統合する準備ができたら、Authorization タブに移動して認証情報を取得できます。
5. アプリの Authorization タブから client ID と client secret を取得します。これらは静的な認証情報です。secret はパスワードと同様に扱ってください。
6. それらを access token と交換します。 Nexar は OAuth 2.0（Open Authorization, version 2.0）を使用しており、トークンの有効期間は24時間です。supply クエリでは client credentials grant を使用し、design および adm クエリでは OpenID、design.domain、user.access の各スコープを用いた authorization code grant を使用します。

上記の例はすべて、アプリケーションコードを1行も書く前に、Nitro（旧 Banana Cake Pop）や Postman などの GraphQL エディターで実行できます。エンドポイントは、API 用が api.nexar.com/graphql、トークン用が identity.nexar.com/connect/token、アップロード用が files.nexar.com/File/Upload です。 

次に進むには

API の動作を確認しましょう。Altium の Platform API 責任者である Rob Barton が、OnTrack ポッドキャストで Altium の API の進化を解説し、Octopart の供給データに対してライブクエリを実行しています： YouTube の「Altium API Deep Dive: Opening PCB Data to Developers」。

エピソードを聴く。 Zach Peterson がホストを務める「OnTrack: The PCB Design Podcast」。

データモデルを確認する。 Nexar Voyager では、GraphQL スキーマを視覚的に表現して確認できます。

ドキュメントを読む。完全なドキュメントと用語集は support.nexar.com で提供されています。実用的なコード例は NexarDeveloper GitHub で公開されています。