LASSIC Media らしくメディア
TISAXとは｜自動車業界の情報セキュリティ評価
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- TISAX：自動車業界で共通の質問集をもとに情報セキュリティを評価し、結果を取引先間で共有する仕組みです。
- 評価レベル：扱う情報の重要度で三段階に分かれ、取引で求められるのは証拠確認をともなう水準が中心です。
- 委託開発の実務：設計データの保管と権限、持ち出しの制限、リモートアクセスの記録、再委託先の管理が要になります。
※ 本記事は2026年8月時点の公式情報（省庁・公的機関・ベンダー公式ドキュメント）に基づきます。
自動車メーカーやその一次取引先と仕事をしていると、「TISAXのラベルはお持ちですか」と問われる場面が出てきます。車両の設計データや試作情報を扱う以上、預ける側は相手の情報管理を確かめたい。その確認を業界で共通化し、何度も同じ監査を繰り返さずに済むようにしたのがTISAXです。
本記事では、自動車業界のサプライチェーンに関わる事業者、とくに設計支援やソフトウェア開発を受託する立場の担当者に向けて、TISAXの仕組み、評価レベルの違い、ISO/IEC 27001との関係、取得までの流れ、そして委託開発で問われる実務のポイントを整理します。制度の詳細は改定されることがあるため、実際の対応は運営団体の公式資料で確かめながら進めてください。
目次
TISAXとは——業界共通の評価を、取引先間で共有する仕組み
TISAX（Trusted Information Security Assessment Exchange）は、自動車業界の情報セキュリティ評価と、その結果の共有を担う枠組みです。運営はENX Associationが担い、評価に使う質問集は業界団体がまとめたもの（VDA ISA）が用いられます*1。企業が一度評価を受ければ、その結果を複数の取引先に対して共有できる点が、この仕組みの核心にあります。
従来、取引先ごとに監査票が送られてきて、同じような質問に何度も答える——という負担がありました。TISAXは「一度の評価を、必要な相手に見せる」形にすることで、この重複を減らします。評価結果はラベルとして表され、運営団体の仕組みを通じて共有先を指定する流れになります。
ここで押さえておきたいのが、TISAXは「認証」ではなく評価結果の共有制度だという点です。合否のマークを掲げて広く宣伝する使い方は想定されておらず、取引先に対して結果を開示するのが本来の姿になります。営業資料で誇示するものではない、と捉えておくとよいでしょう。
評価レベルとラベル——どこまで踏み込んで確かめるか
評価は、扱う情報の重要度に応じて深さが変わります。おおまかには三段階で、上に行くほど確認の手法が厳しくなります*1*2。
| レベル | 確認の手法 | 求められやすい場面 |
|---|---|---|
| レベル1 | 自己評価が中心。第三者の検証は入らない | 影響が限定的な情報を扱う場合 |
| レベル2 | 提出した証拠の確認と、担当者への面談を含む | 設計データなど通常の機密情報を扱う多くの取引 |
| レベル3 | 現地での確認を含み、より踏み込んで検証する | 試作車や特に重要な情報を扱う場合 |
あわせて、評価の対象範囲（どの拠点で、どの業務を、どんな情報を扱うか）も定めます。ラベルは、この範囲と結び付いた形で示されるため、範囲の外にある拠点や業務については何も語りません。取引先から求められた業務が範囲に含まれているか——ここは事前に確認しておきたいところです。
ラベルには有効期間があり、期限が来る前に再評価を受ける必要があります。取得して終わりではなく、運用を続けながら次に備える形です。証跡が日常業務のなかで自然に残る仕組みにしておくと、再評価の負担がぐっと軽くなります。
ISO/IEC 27001との違いと関係
すでにISMS（ISO/IEC 27001）の認証を持つ企業からは、「TISAXも必要なのか」という問いがよく出ます。両者は目的も使われ方も異なるため、片方があれば足りるとは言い切れません。
| 観点 | ISMS（ISO/IEC 27001） | TISAX |
|---|---|---|
| 性格 | マネジメントシステムの認証 | 業界共通の評価と、結果の共有 |
| 質問の内容 | 組織的な仕組みと継続的な改善が中心 | 自動車業界の事情（試作情報・設計データ）を織り込んだ観点を含む |
| 結果の使い方 | 認証として広く示せる | 共有先を指定して、取引先に開示する |
| 準備の重なり | 資産管理・権限・変更管理・記録は共通の土台 | 土台があれば、業界固有の観点を足す作業が主になる |
実務としては、ISMSの運用がある企業なら準備は進めやすいはずです。方針や手順、リスク評価の枠組みは流用できます。追加で問われやすいのは、試作情報の取り扱い、設計データの持ち出し制限、来訪者や作業スペースの管理といった、現場の運用に近い部分です。詳しくはISMS認証取得の進め方で土台の作り方を整理しています。
もう一つ、社内の受け止め方についても触れておきます。TISAXの準備は情報システム部門だけでは完結しません。設計部門が図面をどう受け渡しているか、購買部門が再委託をどう管理しているか、総務が来訪者や作業スペースをどう扱っているか——現場の運用に踏み込む項目が並びます。旗振りをどこが担うのかを決め、関係部門を早めに巻き込むほうが、あとの手戻りが少なくなります。
サプライチェーン全体で見ると、委託先の管理も評価の対象に入ります。自社が受託側であっても、さらに外部へ再委託しているなら、その管理の状況を説明できる必要があります。委託先・サプライチェーンのセキュリティ管理の考え方が、そのまま準備の指針になります。
取得までの流れと期間のめやす
初めて取り組む場合、次の順序で進めるのが素直です。
第一に、範囲の決定です。どの拠点で、どの業務が、どんな情報を扱うのか。ここを広く取ると準備も審査も重くなります。取引先が求めている業務に絞って始めるのが現実的でしょう。
第二に、自己評価です。業界共通の質問集に沿って現状を確かめます。この段階で、方針はあるが記録が残っていない、権限の棚卸しが定期的に行われていない、といった不足が見えてきます。
第三に、是正と整備です。不足を埋め、手順を運用に乗せます。ここで大事なのは、人手に頼る手順を増やしすぎないこと。棚卸しやログの確認を手作業に委ねると、続きません。
第四に、審査です。認定された審査機関による評価を受けます。レベルによって、証拠の確認、面談、現地での確認と、踏み込み方が変わります。
第五に、結果の共有です。ラベルを取引先へ共有し、以後は期限に向けて運用を続けます。準備開始から共有までは、範囲と現状によりますが、半年前後を見込む企業が多いところです。
IT・ソフト開発の委託先に問われること
車載ソフトや設計支援の開発を受託する立場では、次の点が具体的に問われます。開発の進め方そのものに関わるため、契約前に整えておきたい部分です。
- データの保管場所と権限：設計データや車両の情報をどこに置き、誰が参照できるのか。プロジェクト単位で分離できているか
- 持ち出しの制限：端末へのダウンロード、外部媒体、個人の環境への複製をどう防ぐか
- 試作情報の扱い：発表前の仕様や試作に関わる情報を、作業スペースや画面から漏らさない運用になっているか
- リモートアクセスの経路と記録：どの経路で入り、誰がいつ何を触ったのかを残せるか
- 再委託先の管理：さらに外部へ出す場合の条件と、その管理の実施記録
- インシデント時の連絡：検知から取引先への連絡までの流れが、あらかじめ合意されているか
実際の商談では、これらを一枚の資料にまとめておけるかどうかで進み方が変わります。保管場所と権限の一覧、持ち出し制御の仕組み、リモートアクセスの経路図、再委託の有無と管理方法、連絡フロー——この五点を先に示せると、取引先の確認作業が短くなります。逆に、その場で「確認します」を繰り返すと、案件の判断が先送りになりがちなのです。
これらは、車載ソフトのサイバーセキュリティ要件とも重なります。製品としての要件と、開発体制としての要件は別物ですが、同じプロジェクトで両方が問われる場面は少なくありません。組込み・ファームウェア開発の委託やソフトウェアサプライチェーン対策と合わせて、開発の型として整えておくと説明がしやすくなります。
車両側の機能に関わる開発では、スマートフォン連携のように利用者に近い部分も対象になります。CarPlay・Android Auto対応のような案件でも、扱う情報の種類によっては同じ観点で評価されると考えておくほうが堅実です。
受託・委託開発で押さえる実務ポイント
準備を進めるうえで、費用対効果の高い打ち手を挙げておきます。
第一に、プロジェクトごとの分離です。複数の取引先の設計データが同じ場所に混在していると、権限の説明が難しくなります。プロジェクト単位で保管場所とアクセス権を分け、参加者の異動に応じて棚卸しできる形にしておきます。
第二に、作業環境の集約です。データを開発者の端末へ落とさず、閉じた環境の中だけで作業する構成にすると、持ち出しの論点が大きく軽くなります。仮想デスクトップのような形が選ばれるのは、この理由からです。
第三に、記録が自然に残る仕組みです。アクセスの記録、変更の承認、権限の付与と剥奪。これらを台帳の手入力に頼らず、システムの記録として残せていれば、審査でも再評価でも説明に困りません。
第四に、契約と運用の整合です。契約書に「情報を適切に管理する」と書いてあっても、実際の運用がそれを満たしていなければ意味を持ちません。逆に、運用は堅いのに契約に書かれていない、というずれもよく見られます。両方を突き合わせて、抜けを埋めておきましょう。
まとめ：TISAX対応で押さえる3つの視点
TISAXは、自動車業界の情報セキュリティ評価を共通化し、その結果を取引先間で共有する仕組みです。押さえたい視点は三つです。第一に、性格は認証ではなく評価結果の共有であり、範囲と結び付いたラベルとして示されるため、取引先が求める業務が範囲に含まれているかを確かめる必要があること。第二に、評価レベルは扱う情報の重要度で決まり、証拠の確認や面談をともなう水準が取引の中心になるため、記録が残る運用が前提になること。第三に、IT・ソフト開発の委託では、設計データの保管と権限、持ち出しの制限、リモートアクセスの記録、再委託先の管理が具体的に問われることです。まずは対象範囲を絞り、プロジェクトごとの分離と作業環境の集約から着手するのが現実的でしょう。
よくある質問
TISAXは認証ですか。取得したことを公表できますか。
認証ではなく、評価結果を取引先間で共有する仕組みです。ラベルは運営団体の仕組みを通じて共有先を指定して開示する形が本来の使い方で、広く宣伝することは想定されていません。取引先から求められた際に、範囲と有効期間を添えて示すのが基本になります。
ISO/IEC 27001を取得していれば代替できますか。
そのままの代替にはなりません。土台となる仕組み（資産管理・権限・変更管理・記録）は共通するため準備は進めやすいのですが、試作情報の取り扱いや設計データの持ち出し制限といった業界固有の観点が追加で問われます。ISMSの運用がある企業は、差分を埋める作業として捉えるとよいでしょう。
どのレベルで受けるべきか、どう決めればよいですか。
扱う情報の重要度と、取引先が求める水準で決まります。設計データなど通常の機密情報を扱う取引では、証拠の確認と面談をともなう水準が求められることが多いところです。試作車や特に重要な情報に関わる場合は、現地確認を含む水準を求められます。取引先に確認してから範囲を決めるのが確実です。
準備期間はどれくらい必要ですか。
範囲と現状によって幅がありますが、初回は準備開始から結果の共有まで半年前後を見込む企業が多いところです。自己評価で不足が多く見つかった場合は、是正に時間がかかります。逆に、ISMSの運用がありログや権限の記録が残っている企業では、短く収まることもあります。
開発を受託する側では、まず何を整えればよいですか。
プロジェクトごとのデータ分離と、作業環境の集約からです。取引先ごとに保管場所と権限を分け、開発者の端末へデータを落とさない構成にできれば、持ち出しの論点が大きく軽くなります。あわせて、アクセスと変更の記録がシステムに残る形にしておくと、審査での説明が容易になります。
自動車業界向けの開発体制・情報管理のご相談はLASSICへ
元請（プライムベンダー）として、データ分離や閉じた作業環境の構築、アクセス記録・権限管理の整備まで、取引先の評価に耐える開発体制づくりをご提案します。まずはお気軽にご相談ください。
出典
- *1 参考：ENX Association「TISAX — Trusted Information Security Assessment Exchange」（https://enx.com/en-US/TISAX/）。制度の目的・運営主体・評価結果の共有という仕組みの参考として（2026年8月確認）
- *2 参考：ENX Association「TISAX Downloads（参加者向け資料）」（https://enx.com/en-US/tisax/downloads/）。評価レベルとラベル、対象範囲の考え方に関する公式資料の参考として（2026年8月確認）
