>
>
公開日
ITGC（IT全般統制）は、会計や販売管理などの業務システムが正しく動き続ける環境を守るための統制で、J-SOX（金融商品取引法の内部統制報告制度）で評価の対象になります。監査法人から「ITGCの整備状況を出してください」と依頼されたとき、情シスが説明するのは、システムの開発・保守、運用・管理、アクセス管理、外部委託契約の管理の4つです。
本記事では、金融庁の実施基準に沿ってITGCの定義と4つの項目を整理します。そのうえで、SaaS中心の企業で情シスが用意する証跡、アクセス管理の年間スケジュール、IPO準備での進め方、よくある不備を解説します。
本記事のポイント
ITGCは、入力チェックや承認機能などの業務処理統制（ITAC）が働く土台を守る統制です。不備があると、業務処理統制の結果まで信頼されにくくなります
金融庁の実施基準は、ITGCの例として「開発・保守」「運用・管理」「アクセス管理などの安全性の確保」「外部委託契約の管理」の4つを挙げています
SaaS中心の企業では、インフラやプログラムの変更はベンダー側に移ります。自社に残るのは、利用者と権限、設定変更、データ連携、ベンダーの評価です
証跡が最も多くなるのはアクセス管理です。入社・異動・退職のたびに、申請・承認・処理の記録を残します
情報は2026年11月4日時点です。金融庁の公表資料をもとにした整理であり、自社の評価範囲や手続は、監査法人と協議して決めてください。
ITGC（IT全般統制）とは？ITACとの違い
ITGCは、個々の業務システムに組み込まれた統制が正しく働き続けるように、その土台を管理する仕組みです。金融庁の実施基準は、ITGCを「業務処理統制が有効に機能する環境を保証するための統制活動」と定義しています。
J-SOXでは、内部統制を6つの基本的要素で整理しています。統制環境、リスクの評価と対応、統制活動、情報と伝達、モニタリング、ITへの対応の6つです。このうち「ITへの対応」に含まれるITの統制は、全般統制（ITGC）と業務処理統制（ITAC）の2つに分かれます。
ITGCとITACの違い
ITACが個々のシステムの中で取引を正しく処理する統制であるのに対し、ITGCは複数のシステムをまとめて支える管理の統制です。
比較項目 | ITGC（IT全般統制） | ITAC（IT業務処理統制） |
|---|---|---|
守るもの | 業務処理統制が働く環境 | 取引の承認・記録・処理の正しさ |
構築する単位 | システムを支えるIT基盤ごと | 業務システムごと |
実施基準が挙げる例 | 開発・保守の管理、運用・管理、アクセス管理などの安全性の確保、外部委託契約の管理 | 入力情報のチェック、エラーの修正と再処理、マスタデータの維持管理、認証・操作範囲の限定 |
主な担い手 | 情シス、システムの管理者 | 業務部門と、業務システムの設定 |
アクセス管理は、両方の例に出てきます。ITACでいうアクセス管理は「誰が仕訳を承認できるか」のような、システム内の操作範囲の制限です。ITGCでいうアクセス管理は、その権限を誰に付与し、いつ削除し、定期的に見直したかという管理の手続です。情シスが主に説明を求められるのは、後者です。
ITGCに不備があると何が起きるか
ITGCの不備は、それだけで開示すべき重要な不備（内部統制報告書で開示が必要になる不備）と判断されるわけではありません。ただし、実施基準は、ITGCに不備があると業務処理統制の有効な運用を継続して維持できない可能性があるとしています。
実務への影響として大きいのは、監査の手間です。ITを使った統制は同じ処理を繰り返すため、ITGCが有効であれば、手作業の統制よりもサンプル数を減らせると実施基準に書かれています。逆にITGCに不備があれば、業務処理統制のテスト範囲を広げるなど、追加の手続が必要になります。
実施基準が挙げるITGCの4項目
実施基準は、ITGCの具体例として4つの項目を挙げています。監査人が各項目で確認する点も、実施基準に例示されています。
項目 | 監査人が確認する主な点（実施基準の例示） | 実務での呼び方の例 |
|---|---|---|
システムの開発、保守に係る管理 | 開発・変更の事前承認、導入前の十分なテストと承認、過程の記録と保存、データ移行時の誤りや不正の防止、利用者への教育 | 変更管理、開発管理 |
システムの運用・管理 | 重要なデータやソフトウェアの保存と復旧の備え、障害発生時の把握・分析・解決 | 運用管理（ジョブ・バックアップ・障害対応） |
内外からのアクセス管理などシステムの安全性の確保 | データやシステムの不正使用・改ざん・破壊を防ぐアクセス管理の方針 | アクセス管理（論理アクセス） |
外部委託に関する契約の管理 | ITに係る業務を外部に委託している場合の契約の管理 | 委託先管理、ベンダー管理 |
4項目はあくまで実施基準の「例」です。監査法人や企業によっては、開発と変更を分けて数えるなど、区分の仕方が異なります。社内の統制記述書をつくる前に、監査法人がどの区分で評価するかを確認しておくと、資料の作り直しを防げます。
2023年4月に改訂された実施基準（2024年4月1日以後に開始する事業年度から適用）では、ITの委託業務に係る統制の重要性が増していることと、クラウドやリモートアクセスの利用に伴いサイバーリスクを踏まえたセキュリティの確保が重要であることが明記されました。4項目のうち、アクセス管理と外部委託契約の管理は、SaaSを多く使う企業ほど改訂の趣旨と重なります。
評価対象システムと評価単位の決め方
ITGCの評価対象は、財務報告に関わる業務プロセスから逆算して決めます。社内の全システムが対象になるわけではありません。
重要な勘定科目に関係する業務プロセスとシステムを整理し、システムを支えるIT基盤を把握したうえで評価単位を識別する、という流れが実施基準に示されています。情シスの作業に置き換えると、次の4段階です。
重要な勘定科目と業務プロセスを確認する：売上、売掛金、棚卸資産など、評価対象の勘定科目と業務プロセスを経理・内部統制の担当者から受け取ります
業務プロセスで使うシステムを一覧にする：受注から売上計上までに通るシステムと、システム間のデータの流れを書き出します
IT基盤と管理部署を把握する：各システムの管理者権限を誰が持ち、誰が設定を変えているかを確認します
評価単位を決める：管理部署や運用方法が同じシステムをまとめて、評価の単位にします
実施基準の例では、販売・購買・物流の自社開発システムはシステム部が管理し、会計は経理部が市販のパッケージを導入・管理しているため、評価単位を「システム部」と「経理部」の2つに分けています。SaaSでも考え方は同じで、会計SaaSの管理者が経理部、販売管理SaaSの管理者が情シスなら、管理する部署ごとに整理します。
対象になりやすいSaaSと、確認が必要なSaaS
財務データを作る、または財務データが通るSaaSは、評価対象になりやすくなります。
区分 | SaaSの例 | 考え方 |
|---|---|---|
対象になりやすい | 会計、販売管理・請求、経費精算、給与計算、購買・在庫管理、固定資産管理 | 重要な勘定科目に直接つながるデータを作る |
関係を確認する | IdP（ID管理基盤）、データ連携ツール、ワークフロー、CRM | 対象SaaSへのログインを制御している、承認記録の保存先になっている、受注データが売上計上に流れているなど、つながり方によって対象になる |
対象外になりやすい | チャット、デザインツール、財務データを扱わないタスク管理 | 財務報告への影響が小さい。ただし承認や依頼の記録を残している場合は扱いを確認する |
評価範囲を決めるのは経営者であり、必要に応じて監査人と協議します。情シスが気をつけたいのは、経理部門や営業部門が独自に契約した精算・請求系のSaaSが、システム一覧から抜けることです。部門ごとのSaaS利用を把握する方法は、シャドーITの発見方法で整理しています。
SaaS中心の環境でITGCはどう変わるか
SaaSを使うと、インフラの運用やプログラムの変更はベンダーの責任範囲になります。一方で、誰が使えるか、設定をどう変えたか、データをどう連携し保全するか、ベンダーをどう評価するかは、利用企業に残ります。
市販のパッケージ・ソフトウェアをそのまま使うような比較的簡易なシステムの企業ほど、ITGCに重点を置く必要があると実施基準は述べています。プログラムを書かないから対象が減る、とは限りません。
ITGCの項目 | ベンダー側に移るもの | 自社に残るもの |
|---|---|---|
開発・保守 | プログラムの改修、テスト、本番環境への反映 | 承認経路、勘定科目などのマスタ、自動仕訳のルール、権限セットの変更。自社で書いた連携スクリプトの変更 |
運用・管理 | サーバの稼働監視、インフラのバックアップ、障害復旧 | データ連携の成功・失敗の監視と再処理、データの定期的なエクスポート、障害時の業務の代替手順 |
アクセス管理 | OS・データベース・ネットワーク層の管理 | 利用者IDの発行・削除、権限の付与、管理者ロール、MFA・SSOの設定、APIキーや連携用ID |
外部委託契約の管理 | （ベンダー自身の内部統制） | 契約・利用規約の管理、ベンダーの内部統制の評価 |
SaaSベンダーの評価は保証報告書の確認から始める
財務報告に関わる業務をSaaSに任せている場合、そのベンダーの内部統制も評価範囲に含まれます。評価の方法としては、受託会社から内部統制の評価結果を記載した報告書を入手して利用する方法と、委託業務の結果を自社でサンプル検証する方法の2つが、実施基準に例示されています。
ベンダーから入手する報告書として一般的なのは、財務報告に関わる受託業務の内部統制を独立した監査人が評価した保証報告書です。米国の基準ではSOC1報告書、日本では日本公認会計士協会の保証業務実務指針3402に基づく報告書と呼ばれます。入手したら、次の点を確認します。
報告書の種類：ある時点の設計を評価した「Type1」か、一定期間の運用まで評価した「Type2」か
対象期間：自社の会計期間をどこまでカバーしているか
対象範囲：自社が使っているサービスや拠点が含まれているか。ベンダーがさらに委託しているクラウド基盤などが除外されていないか
例外事項：監査人が指摘した逸脱がないか
利用者側に求められる統制：報告書には、利用企業が自ら実施することを前提にした統制（利用者のアカウント管理など）が書かれています。自社で実施しているかを確認します
情報セキュリティを対象にしたSOC2報告書やISO/IEC 27001の認証は、財務報告を目的にしたものではありません。SOC1報告書がないベンダーでSOC2報告書などで代えられるかは、監査人と協議して判断します。報告書がまったく入手できない場合は、委託業務の結果と基礎資料の照合など、自社での検証を組み合わせます。
ベンダーごとの契約や保証報告書の入手状況は、一覧で管理すると更新漏れを防げます。委託先を台帳で管理する項目は、委託先管理の進め方で解説しています。マネーフォワード Adminaでは、SaaSごとに管理担当者やSOC2・ISOなどの外部認証の取得状況を登録できるため、コンプライアンス対応の情報管理を台帳の土台として使えます。
情シスが用意する証跡一覧（4項目別）
証跡で最も量が多くなるのはアクセス管理です。また、証跡は「設定がこうなっている」という現在の状態だけでなく、「評価期間中、そのとおりに運用された」ことを示す記録が求められます。
以下は、SaaS中心の企業で一般に用意することが多い証跡の例です。実際に求められる資料は、監査法人の依頼資料リストで確認してください。
アクセス管理
統制の例 | 証跡の例 | 主な取得元 |
|---|---|---|
入社・異動時の権限付与は申請と承認に基づく | 申請・承認の記録、付与日、付与した権限 | ワークフロー、チケット管理ツール |
退職者のアカウントは速やかに削除・無効化する | 退職日と削除日の対応表、削除・無効化の操作記録 | 人事マスタ、各SaaSの監査ログ |
利用者と権限を定期的に見直す | 棚卸しの依頼・回答・是正の記録 | 棚卸しシート、メール・チケット |
管理者権限（特権ID）を限定する | 管理者ロールの保有者一覧、見直しの記録 | 各SaaSの管理画面 |
認証を強化する | MFA・SSO・パスワードポリシーの設定値、適用対象 | IdP、各SaaSの設定画面 |
共有IDや連携用IDを管理する | 共有ID・システム連携用ID・APIキーの一覧と責任者 | 管理表 |
退職者アカウントの確認では、IdPで止めても各SaaSに利用経路が残ることがあります。具体的な確認手順は、IdP停止後に残る退職者アカウントの確認手順にまとめています。MFAの適用漏れの点検方法は、多要素認証の適用漏れを防ぐ点検方法が参考になります。
開発・保守（変更管理）
統制の例 | 証跡の例 | 主な取得元 |
|---|---|---|
財務に影響する設定変更は事前に承認する | 変更申請、承認者、承認日、変更内容 | ワークフロー、チケット管理ツール |
変更前に検証する | テスト結果、検証環境での確認記録 | チケット、検証記録 |
連携やスクリプトの変更を管理する | 変更履歴、レビュー記録、反映日時 | Gitなどのバージョン管理、データ連携ツール |
ベンダーの機能変更の影響を確認する | リリース情報の確認記録と、影響の有無の判断 | 確認ログ |
運用・管理
統制の例 | 証跡の例 | 主な取得元 |
|---|---|---|
データ連携の失敗を検知し、再処理する | 連携エラーの一覧、対応内容、再処理の結果 | データ連携ツール、アラート履歴 |
必要なデータを保全する | エクスポートやバックアップの取得記録、保管場所 | 保管先のログ |
障害に対応する | 障害の記録、原因、対応、業務への影響 | 障害管理表、チケット |
外部委託契約の管理
統制の例 | 証跡の例 | 主な取得元 |
|---|---|---|
委託先と契約内容を把握する | 委託先一覧、契約書・利用規約・SLA | 契約管理、SaaS台帳 |
委託先の内部統制を評価する | 保証報告書と、その評価記録（対象期間・対象範囲・例外事項・利用者側の統制の確認結果） | ベンダー、評価シート |
報告書がない場合に代わりの検証を行う | 質問書の回答、委託結果と基礎資料の照合記録 | 評価シート |
アクセス管理の証跡では、母集団の正しさも見られます。母集団とは、監査人がサンプルを選ぶ元になる全件の一覧で、たとえば評価期間中の退職者一覧がこれにあたります。台帳に載っていないSaaSやIdPを通らないアカウントがあると、母集団そのものが不完全になります。母集団の作り方や資料の提出方法は、監査対応の進め方で詳しく扱っています。
アクセス管理の統制を回す年間スケジュール
アクセス管理は、入退社のたびの処理、月次の突合、定期の見直しの3つを重ねて回します。記録は1件ごとに残すことが前提です。
監査人は、記録の中からサンプルを選んで運用状況を確かめます。日常的に繰り返される取引の場合、90%の信頼度を得るには統制上の要点ごとに少なくとも25件のサンプルが必要になるという例が、実施基準に示されています。選ばれた1件の記録が欠けていれば、その分が例外として扱われます。
タイミング | やること | 残す記録 |
|---|---|---|
入社・異動・退職のたび | 申請に基づいて権限を付与・変更し、退職者のアカウントを削除・無効化する | 申請・承認・処理日、処理した担当者 |
毎月 | 人事マスタと各SaaSのアカウント一覧を突き合わせ、退職者や休職者のアカウントの残りを確認する | 突合の結果、見つかった差分と対応 |
四半期または半期 | 管理者権限の保有者を見直す | 保有者一覧、維持・縮小・削除の判断 |
年1回 | 一般ユーザーを含む全アカウントの権限を、業務部門の承認者に確認してもらう | 依頼・回答・是正の記録 |
期末前 | 評価期間の母集団を確定し、証跡を整理する | 母集団の抽出条件、件数、作成日 |
入退社の処理手順全体は入退社フローテンプレート、管理者権限の見直しはSaaS管理者ロールの棚卸し、年次の全件見直しはアクセス権限の棚卸しの進め方で、それぞれ手順を解説しています。
手作業を減らし、記録が自動で残る仕組みにする
入退社の件数が増えると、手作業での付与・削除と記録は漏れやすくなります。人事情報を起点にアカウントを処理し、その結果が記録として残る仕組みにすると、証跡を後から集める作業も減ります。
IdPのSCIM連携（アカウントの作成・更新・削除を自動で反映する仕組み）に対応したSaaSは、IdP側で自動化できます。設定の流れはSCIMプロビジョニングの設定手順を参照してください。
課題になりやすいのは、SAMLやSCIMに対応していないSaaSです。Adminaは従業員マスターと連携して、在籍情報と各SaaSのアカウントの差分を検出し、退職済みアカウントを検知してアラートを出し、ワンクリックで削除できます。入社日・退職日をきっかけにしたアカウント発行・削除の自動実行は、SAML/SCIM未対応のSaaSにも対応しています。連携SaaSの数は国内トップクラスで、各SaaSのロール・ステータス・2要素認証の設定状況をアカウント一覧として横断的に確認できるため、母集団の作成や管理者権限の洗い出しにも使えます。
IPO準備でのITGC整備タイムライン
上場企業は、上場した事業年度の末日を評価時点とする内部統制報告書から提出が始まります。申請期に初めて統制を動かすのでは運用の実績が足りないため、直前々期から記録を残し始めるのが一般的です。
押さえておきたい制度上の事実は3つです。
内部統制報告書は、上場後最初の事業年度から必要：金融庁の資料は、新規上場企業も上場後最初の事業年度終了後から内部統制報告書を提出すると説明しています
監査の免除は報告書の免除ではない：一定規模以上の企業を除き、新規上場後3年間は内部統制報告書に対する公認会計士監査の免除を選べます。ただし、経営者による評価と報告書の提出は免除されません
財務諸表監査は上場前から始まる：上場申請には直前2期分の財務諸表の監査が必要です。財務諸表監査の中でも、監査人は会社のIT環境と統制を確認します
期ごとに達成すべき水準を定めた公的な基準はありません。以下は一般的な進め方の目安で、実際のスケジュールは主幹事証券会社や監査法人と調整します。
時期 | 情シスの主な作業 |
|---|---|
直前々期（N-2期） | 財務報告に関わるSaaS・システムの一覧化と管理者の特定。アカウントの付与・削除の申請と承認の記録を始める。設定変更の記録ルールを決める |
直前期（N-1期） | 4項目の統制を文書化し、運用を始める。期中に一度、評価の予行演習を行い、不足している証跡を洗い出す。ベンダーの保証報告書を集める |
申請期（N期） | 運用を続け、期末日時点で評価する。母集団と証跡を整理し、不備があれば期末日までに是正する |
不備が見つかっても、期末日までに是正されていれば、内部統制は有効と評価できると実施基準は定めています。直前期に予行演習を入れておくと、是正のための時間を確保しやすくなります。
上場後は、毎期の評価が続きます。前年度の評価結果が有効で、整備状況に重要な変更がない項目は、前年度の運用状況の評価結果を継続して使える場合があります。ただし2023年の改訂で、この扱いはIT環境の変化を踏まえて慎重に判断し、特定の年数を機械的に当てはめないことが明確にされました。SaaSの追加や管理者の交代があった年は、変更として扱う前提で準備します。
よくある不備と指摘例
ITGCで指摘が出やすいのは、記録が残っていないことと、一覧が実態と合っていないことです。統制そのものはあっても、運用した事実を示せなければ不備として扱われることがあります。
不備の例 | 起きやすい原因 | 先に打てる手 |
|---|---|---|
退職者のアカウントが残っている、または削除日が退職日より大幅に遅い | 人事からの連絡が遅れる。IdPを通らないSaaSが削除の対象から漏れる | 人事マスタとの月次突合。IdP外のアカウントを含めた一覧化 |
申請・承認なしで権限が付与されている | チャットで依頼を受けて、管理者がそのまま付与している | 付与の窓口を申請フォームに一本化する |
棚卸しを実施したが、記録が残っていない | 結果だけを口頭やチャットで報告している | 依頼・回答・是正を同じシートで管理する |
管理者権限の保有者が多い、共有の管理者IDがある | 初期設定や担当交代のたびに管理者が追加される | 管理者ロールの定期見直しと、責任者の明確化 |
会計SaaSの設定変更に記録がない | 承認経路や勘定科目マスタを、担当者がその場で変更している | 財務に影響する設定項目を決め、変更申請の対象にする |
データ連携のエラーが放置されている | エラー通知の受け手が決まっていない | 通知先と対応期限、再処理の記録方法を決める |
ベンダーの保証報告書を入手していない、入手しても内容を確認していない | 契約時に確認する手順がない | 契約更新時に報告書の入手と評価を手順に組み込む |
システム一覧やアカウント一覧が実態と合わない | 部門が独自に契約したSaaSや、IdPを通らないアカウントがある | 申告だけに頼らず、複数の経路でSaaS利用を検出する |
不備がどの程度の重さになるかは、財務報告への影響や補完する統制の有無を踏まえて判断されます。ここに挙げたものは、すべてが開示すべき重要な不備になるという意味ではありません。
よくある質問（FAQ）
Q. ITGCとITACの違いは何ですか？
A. ITGC（IT全般統制）は、アカウント管理や変更管理など、複数のシステムをまとめて支える管理の統制です。ITAC（IT業務処理統制）は、入力チェックや承認機能など、個々の業務システムの中で取引を正しく処理する統制です。ITGCが有効であることが、ITACを信頼する前提になります。
Q. 自社でシステムを開発せず、SaaSだけを使っている場合もITGCは必要ですか？
A. 必要です。プログラムの変更やインフラの運用はベンダー側に移りますが、利用者IDと権限の管理、設定変更の管理、データ連携の監視、ベンダーの評価は利用企業に残ります。実施基準も、市販のパッケージをそのまま使うような比較的簡易なシステムの企業では、ITGCに重点を置く必要があるとしています。
Q. SOC2報告書があれば、SOC1報告書の代わりになりますか？
A. 目的が異なるため、そのまま代わりになるとは限りません。SOC1報告書は財務報告に関わる受託業務の内部統制を対象にしており、SOC2報告書は情報セキュリティや可用性などを対象にしています。SOC1報告書がないベンダーをどう評価するかは、監査人と協議して決めます。
Q. ITGCの評価は毎年必要ですか？
A. 原則として毎期実施します。前年度の評価結果が有効で、整備状況に重要な変更がない項目は、前年度の運用状況の評価結果を継続して使える場合があります。ただし、IT環境の変化を踏まえて慎重に判断し、特定の年数を機械的に当てはめないことが、2023年の改訂で明確にされています。
Q. 証跡はどのくらいの期間保存すればよいですか？
A. 保存期間は企業が判断しますが、実施基準は、有価証券報告書とその添付書類の縦覧期間（5年）を勘案して、同程度の期間保存することを例に挙げています。後から第三者が検証できるように、関連する証拠書類もあわせて保存します。
Q. IPO準備では、いつから証跡を残せばよいですか？
A. 直前々期から、アカウントの付与・削除の申請と承認、設定変更の記録を残し始めるのが一般的です。内部統制報告書は上場した事業年度から必要になるため、直前期に運用と評価の予行演習を一度通しておくと、申請期の評価に間に合わせやすくなります。
まとめ
ITGCは、業務システムの統制が正しく働き続けるための土台です。金融庁の実施基準は、開発・保守、運用・管理、アクセス管理などの安全性の確保、外部委託契約の管理の4つを例に挙げています。
SaaS中心の企業でも、ITGCの対象が消えるわけではありません。利用者と権限、設定変更、データ連携、ベンダーの評価は利用企業に残ります。なかでも証跡が多いのはアクセス管理で、入退社のたびの記録、月次の突合、定期の見直しを積み重ねることが、監査で説明できる状態につながります。
最後に、準備の状況を確認するチェックリストです。
□ 財務報告に関わるSaaS・システムの一覧があり、各システムの管理者が決まっている
□ 評価単位と、4項目それぞれの統制の内容を監査法人とすり合わせている
□ 入社・異動・退職のたびに、申請・承認・処理日の記録が残っている
□ 人事マスタと各SaaSのアカウントを毎月突き合わせている
□ 管理者権限の保有者を定期的に見直し、記録している
□ 年1回、全アカウントの権限を業務部門の承認者に確認してもらっている
□ 財務に影響する設定変更が、申請と承認の対象になっている
□ データ連携のエラーの通知先と、再処理の記録方法が決まっている
□ 財務報告に関わるSaaSベンダーの保証報告書を入手し、内容を評価している
□ 評価期間の母集団（退職者一覧など）を、抽出条件とあわせて作成できる
アクセス管理まわりの点検項目は、次の点検チェックリストでも1行ずつ確認できます。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
