インド政府、「スマホのソースコード提出義務化」を否定——本質は“83項目”の協議の進め方と運用にありです

今日の深掘りポイント

• インド政府は、スマホメーカーにソースコード提供を義務づけるとの報道を否定し、「83のセキュリティ基準」は業界との定期協議の一環だと説明しています。規制は“確定”ではなく“交渉のテーブル上”にあります。
• それでも、主要ソフトウェア更新の事前通知など、運用に直結する要件が検討対象に含まれる点は、エコシステム全体のリリース管理や脆弱性対応プロセスに影響しうる論点です。
• 「ソースコード提出」は否定された一方、第三者試験や監査、構成証跡の提出など、実効性の高い代替的な保証手段へと議論が収れんする可能性が高いです（編集部の仮説）。
• 日本企業にとっては、市場アクセス面の即時リスクは低下したものの、インド特有のセキュリティ保証・透明性要求に応じるための“準備度”が中期の勝負を分けます。
• 地政学的には、巨大市場を守りつつデジタル主権を主張する政策運営が続く見通しで、端末サプライチェーンやOSベンダーにも波及します。

はじめに

「ソースコードを出せ」という言葉は、デベロッパーだけでなく、リーガルや経営層の心拍数を確実に上げます。インドからその類のニュースが飛び込んだ直後、政府が速やかに「義務化を策定している事実はない」と火消しに回りました。ここで息をつけるのは事実ですが、肝心なのは「何がテーブルに乗り、どこへ着地しそうか」を見抜くことです。今回の否定は、規制の方向性が“ゼロ”になったことを意味しません。むしろ、協議の焦点と運用の設計にこそ、CISOやプロダクト責任者が手当すべき現実が潜んでいます。

以下では、報道で挙がった83項目の扱い、否定の言葉が示唆する政策運営のスタイル、そして日本企業の実務に跳ね返るインパクトを丁寧にほどいていきます。

深掘り詳細

事実整理（報道ベース）

• 報道によれば、インドはスマートフォンのセキュリティ強化のため「83の基準」を検討しており、その中に「ソースコードの共有」や「主要アップデートの事前通知」といった要求が含まれるとされました。一方、電子情報技術省（MeitY）は、これらは業界との定期的な協議の一環であり、強制的な要件の策定事実はないと否定しています。
• 背景として、スマートフォンが個人データの主要な保管・アクセス端末となるなか、サイバー犯罪や詐欺被害の増加に対応する必要性を政府が強調している流れがあります。過去にもビッグテックとの綱引きが断続的に発生してきた経緯があり、今回も「強いメッセージ」と「対話による収れん」が同じ紙面上に同居しています。
• 出所・詳細は以下の報道を参照ください（一次情報の公的文書は現時点で確認できる範囲で明示されていません）。The Register: India denies it’s drawing up rules to demand source code from smartphone makers（2026-01-12） です。

編集部のインサイト（仮説を含む）

• 否定の意味合い——“手段”は固定しない、しかし“目的”は揺らがないです
  ソースコード提出という最もセンシティブな案は、業界反発や知財保護の観点から現実解になりにくい一方、政府の目的（端末の安全性と利用者保護）は揺らがないはずです。ここから先は、実効性のある保証をどう設計するかが主戦場になります。
• 代替の保証レバー——試験・証跡・透明性の三層（編集部仮説）です
  1. 認定ラボによるセキュリティ評価・侵入テスト、2) ビルドプロセス・ブートチェーン・暗号鍵管理の証跡提示（例：ビルド署名の手順と分離、サプライヤー管理の統制）、3) アップデート方針と重大変更の透明性（ユーザー・当局双方への説明）など、“ソースコードを渡さずに”保証強度を高めるやり方は多様です。SBOMやビルド由来情報（provenance）の提示は、負担対効果の面で国際的にも採択が進む領域です（方向性の示唆であり、インドがこれらを採用することを断定するものではありません）。
• 事前通知の副作用——攻撃者の「先読み」を招かない設計が要点です
  主要アップデートの事前通知は、ユーザー保護や市場の透明性向上に資する一方、公開タイミングや内容の粒度を誤ると攻撃者に足がかりを与えるリスクがあります。匿名化されたアドバイザリ、限定公開、ロールアウトの段階的実施といったオペレーションで、利用者保護と攻撃面の最小化を両立する設計がカギになります。
• 地政学と産業政策のバランスです
  巨大市場の“門番”として、インドは安全基準の引き上げと産業育成を同時に進めたいはずです。外資の参加を得つつ、サプライチェーンの透明性や国内検査体制の強化に舵を切る——今回の否定は、その微妙な力学を反映した“揺り戻し”と捉えるのが妥当です。

将来の影響とインパクト

• 短期（～半年）：即座の遵守義務は見えません。とはいえ、規制当局とのダイアログは継続し、ドラフトの書きぶりや用語定義（「主要アップデート」「高リスク変更」など）に実務視点を注入できるフェーズです。日本企業も現地法人・業界団体を通じた発言機会の確保が効きます。
• 中期（半年～1年）：試験・証跡・透明性の“三点セット”が実装される可能性が高いです（編集部仮説）。この場合、端末ベンダー・OSベンダー・チップベンダー間の責任分界や、第三者評価のスコープ取り（カーネル／ドライバ／ブートローダ／サプライチェーンのどこまでか）が実務の争点になります。
• 長期（1年以上）：基準の国際整合性が問われます。各国で類似の要件が並立すると、複数管轄向けビルドや評価の重複がコスト増を招きます。インドが国際標準（暗号モジュール評価やソフトウェア保証の共通フレーム）と歩調を合わせられるかが、企業側の持続可能な対応ぶりを左右します。
• サプライチェーン全体への波及：プリインストールアプリ、サードパーティSDK、ベースバンドやセキュアエレメントなど“見えにくい層”の実装に光が当たりやすくなります。一次ベンダーだけでなく、SDK提供企業やローカルパートナーまで含む契約・評価の更新が必要になる見込みです。

セキュリティ担当者のアクション

• レギュラトリー・レディネスの確立です
  • 現地規制トラッキングと要件マッピングを専任化し、“想定ドラフト”に対する自社のギャップを平時から棚卸しします。
  • インド向け“レギュラトリーパック”（アーキテクチャ概要、セキュリティ設計、ビルド／署名手順の管理、脆弱性対応SLA、SBOM、第三者評価結果など）を標準化しておくと、どの案に振れても初動が早くなります（編集部の推奨プラクティス）。
• リリース運用の堅牢化です
  • 主要アップデートの「事前通知」が検討対象にある前提で、通知の粒度・時期・関係者範囲を定義し、情報漏えい時の影響最小化（段階的ロールアウト、機能フラグ、カナリア配信）を組み込んだ手順を整備します。
  • アドバイザリ文面の標準化と、当局・ユーザー・パートナー別のコミュニケーションテンプレートを用意します。
• 証跡と第三者評価の準備です
  • ブートチェーン、鍵管理、セキュアアップデートの設計と運用証跡（監査ログ、変更管理、ビルド環境の分離）を平文化し、再現可能性を高めます。
  • 外部ラボ評価や侵入テストの再実施周期、スコープ、再現性の要件を社内標準として定義し、ベンダー調達条件にも織り込みます。
• サプライヤーとSDKの健全性管理です
  • プリインアプリや収益化SDKの権限・データフローを棚卸しし、代替品の評価を含めたリスク軽減策を用意します。
  • チップ／ベースバンドなど下位レイヤーの更新SLAとサプライヤーの開示能力を契約で担保します。
• ガバナンスと対外コミュニケーションです
  • 法務・広報・プロダクトの三位一体で、規制当局との対話チャネルを持続。設計上のトレードオフ（ユーザー保護と攻撃者に与える情報の最小化）を定量・定性で説明できる資料化を進めます。
  • 日本本社とインド現地の意思決定レーンを短縮し、ドラフト公表からフィードバック提出までの“タイムボックス運用”を事前に決めておきます。

参考情報

• The Register: India denies it’s drawing up rules to demand source code from smartphone makers（2026-01-12）https://go.theregister.com/feed/www.theregister.com/2026/01/12/india_mobile_security/ です。

編集後記：
「出せるもの」と「出せないもの」の境界を曖昧にしたまま議論を進めると、双方にとって不幸な着地になります。今回の否定は、関係者が“落としどころ”を探る時間を稼いだとも読めます。技術で守れること、運用で補えること、そして規制で後押しすべきこと。その三つを整然と分け、言葉と証拠で積み上げていく——それが私たちの最良の準備になるはずです。