話題の*1「モバイル・エコシステムに関する競争評価（中間報告）に対するパブリックコメント」を自分でも書いたので公開しておきます。
以下本文:
この報告書の位置づけに対する理解
（この項目は、提出用フォーマットの「2.記載された内容の他に、考慮すべき視点とそれに対する意見」として記載します。）
パブリックコメントは公開されて読まれる前提である、という考えに基づいて、このコメントは担当者の方以外にも読まれる体裁でまとめられている。
本コメントはmarkdown形式で書かれたものをメールで送信しているので、デジタルデータがあれば読みやすく復元できる。
この報告書は内閣官房デジタル市場競争本部事務局の名義で出されている。競争政策だが公正取引委員会はデジタル市場競争会議ワーキンググループの中で報告者として参加していたに過ぎない（ただGoogleの法務担当者から、ワーキンググループの議事録での参加は少なく見えるが実際には何度もミーティングしてきた旨、ジュリストNo.1564（2021年11月号）に書かれているとされている）。
本報告書に対しては、こんなかたちでAppleやGoogleを規制しても日本の企業がAppleやGoogleに勝てる市場を作れるわけではない、国粋主義者が非国産プラットフォームの足を引っ張る目的で作った非現実的な報告書である、といった批判が上がっているのが観測できる。前者については、本報告書の議題となる競争市場はプラットフォーム市場そのものだけでなく個別のアプリ市場（たとえば音楽ストリーミングアプリ市場）に対しても影響するものであり、本報告書の意図するかたちで対策を検討することは適切であることを確認しておきたい。
後者は国家による企業に対する正当な法規制ではないという主張であり、傾聴すべき意見ではある。これについて、米国でもモバイル独占市場にかかる規制法案が審議されるにあたって、議員の意見の割れ方に興味深い結果が出ている。現与党である民主党は全員規制側、共和党は半々に割れており、企業は国家に服従すべきと考える議員が民主党と同じ規制側に、企業の経済活動を最大限自由にすべきと考えるような議員が規制否定側に回っている状況であると理解できる。筆者は、競争法の観点から、合目的的な、最小限の、しかし積極的な介入は必要であると理解している。
デジタル庁には、かつてWindows PhoneというApp Storeのように独占的なモバイルプラットフォームを打ち出そうとして失敗し撤退した日本マイクロソフトの出身者が政府CIO補佐官の時代から何名も在籍しており、今回の報告書にも影響を及ぼしている可能性はある。一般にプラットフォーム企業の出身者は出身企業の従業員と密に連携して法に明確に反しない範囲で利益誘導を得ることがあり（たとえば招待講演を請けて現業を宣伝する場を設けてもらえる）、AppleやGoogleから営業秘密を引き出す意図をもって関連制度の枠組みに参加する危険性もあることは意識しておきたい。関連プラットフォーム業者には忌避の申立を可能にする等の対策が考えられる。
（以降は提出用フォーマットの「1. 記載された内容に対する意見」として記載します。）
I. 総論
第1.市場の構造と実態
＜中間報告の該当箇所：16ページ＞
モバイル OS を維持するためには年間数百億円かかると言われているが、一方で、OS の事業に関しては、根源的に先行者メリットがある。
コストばかりが強調されていて、収益について言及が無いことから、これはプラットフォーム側（AppleおよびGoogle）が主張したい数字だけをそのまま書いているのではないかという疑念が生じる。この引用部分は、間接的な先行者利益がこれらのプラットフォーム運用の動機に直結しているかのように読めるが、AppleのApp Store登録開発者は50万人おり、99ドル = 10000円という大雑把な換算でも1年で50億円の売上がある（アプリ内課金による収益のほうが大きいことは言うまでもない）。最終的な報告書では、開発者からのプラットフォーム利用料などが主要な収益源であることが読者にも理解できるようなまとめ方が望ましい。
＜中間報告の該当箇所：17ページ＞
ユーザーにとっては、ブランド・ロイヤリティだけでなく、使い慣れた UIやコンセプト、使い慣れたアプリなどをインストールする手間、既に端末内やクラウドに保存している多種大量のデータを移動する時間や労力などがあることから、スマートフォンの OS をスイッチすることについては、ハードルがある。
これに関連して、アプリ市場の消費者には、プラットフォームを切り替えるだけで同一のアプリケーションに再度対価を支払って購入させられているという状況があり、これが放置されていることが問題である。PCソフト市場においては、同一のソフトの市場において、同一ユーザーに対する複数のプラットフォーム分、数台のマシンへのインストールが可能になっているのが一般的であり、モバイルアプリマーケットが独占的であることは、対価の二重取りを肯定することになっている。
複数プラットフォームにおいて「同一の」アプリケーションが配布される場合に、対価の二重取りが生じないことを保証するような、同一ユーザーによる購入情報を確認できるようなアプリ市場間の相互運用の仕組みが、一定規模のアプリケーション市場において実装されるような施策が求められる。（同一性はアプリ名、アプリ内コンテンツの同一キャンペーン・イベント等、あるいは広告等で実質的に判断できる。）
第２. 目指すべき姿と対応に向けた基本的な考え方
＜中間報告の該当箇所：35ページ＞
「1. モバイル・エコシステム全体に関する認識」「2. モバイル・エコシステム全体のあるべき姿」ともに適切な内容でまとめられていると考える。
モバイル・エコシステムは、これらのサービスを利用する消費者の日常生活、そして、当該サービスを提供するビジネスユーザーの経済活動の基盤（インフラストラクチャー）としての機能を果たしているととらえることができる。
この他に、行政においてモバイルアプリケーションが開発・利用されているという観点が重要であると考える。そもそも論として可能な限りプラットフォーム依存性を排したWebでできる以上のことを行政で利用するアプリケーションにおいて利用すべきでないという問題もあるが、必要最小限の範囲でモバイルアプリケーションを利用せざるを得ない場合もあろう。そのプラットフォームは公正競争に則り独占に資することがあってはならないし、当該プラットフォームをサポートしないことで国民生活に多大な健康上の被害や金銭的利益の多寡といった影響が出るのであれば、それは国家がプラットフォームの機構に積極的に介入する必要がある。
この点で近年独占性が問題になったのはコロナウィルス濃厚接触を検出するExposure Notification APIとそのサービス実装で、日本でもCOCOAというアプリケーションがこれを組み込んでいる。COCOAは「公共事業案件を受注前のアピールだけは大々的に行い、受注後は何もしない」という方針に等しい開発企業のネグレクトによりユーザーフィードバックを放置して問題になったが、ここに競争原理が機能していれば、このような問題で国民の健康・生存権を幅広く損なうことはなかった。この独占構造に資することになったのがAppleとGoogleの1国1アプリという私的な制限だった。独占禁止政策はこのような観点でも他の官公庁から独立して影響力を及ぼす、具体的には国民および公正取引委員会などから問題の指摘を吸収し改善を促していく機関が存在すべきである、と考える。
＜中間報告の該当箇所：36ページ＞
アルゴリズムを利用しているためにビジネス上の決定の過程がブラックボックス化していること等により、情報の非対称が存在しており、
「企業秘密である非公開アルゴリズムに基づいており公開できない」といったエクスキューズのことを指していると思われるが、アルゴリズムに計算機にかかる判断処理がブラックボックス化されることは無い。 特許技術であればそれは公開されていなければならないし、営業秘密の保護は独占禁止法違反を正当化するものではなく、企業には官公庁において事実関係を確認するための監査を受け入れる義務がある、と立法で対策することが考えうる（もちろんこれは独占禁止法に基づく行政手続であって犯罪の捜査等に目的外利用できてはならない）。
＜中間報告の該当箇所：37ページ＞
複数のレイヤーで影響力を行使し得るプラットフォーム事業者による一定の行為に対し、現行の法的枠組みの制約にとらわれず
に、実効的に対応することができる方策を検討することとしている。
根拠法なしで実効的に対応する方策を検討するのは法律による行政の原理に反するので、少なくとも対応根拠に関しては明確に法に基づく対応が求められる。弊害の類型化と明示があれば、対応手段まで詳細に規定することは必須ではないと考えるが、基本的に政令等に基づいて対応する必要があろう。
＜中間報告の該当箇所：38ページ＞
今回競争評価の対象としているモバイル・エコシステムにおける競争上の諸課題については、その特性から、これまでの競争法によるアプローチとは異なるアプローチを考えていく必要があるのではないか。
本項に関連して、「独占的状態に対する措置」（独禁法第２条第７項、第８条の４）が注釈として言及されているが、本条はいわゆる伝家の宝刀であり、その適用を視野に入れるのは不当とまでは言えないものの、現状で野放図である市場の独占的状態に対して、最初から用いていく筋書きよりは、着実な競争促進策を推し進めるほうが適切であると考える。
＜中間報告の該当箇所：39ページ＞
セキュリティやプライバシー保護など例外的に何らかの理由を持つ場合もあり得ることから、プラットフォーム事業者がそれを示した場合、十分に精査したうえで正当な理由と認められる場合には、禁止から取り除くといった対応が可能ではないか。
「正当な理由のない禁止の禁止」は、法の原則として適切なものであり、プラットフォームが公共的存在である認定される以上は、これはユーザーおよびプラットフォーム内開発者に対するプラットフォームからの「禁止」についても妥当する原則といえる。
とはいえ、それがあまねく事前規制として存在すべきかどうかは別の問題である。行政にたとえるなら、地方自治体が独自の規制を定める際に、国政に対して事前に届け出をすることはないはずである。プラットフォームによる競争阻害行為についても、それが類型的に予測可能で事前承認を必要とする場合もあり得るが、それ以外は事前規制には馴染まないと考える。
セキュリティの関連では、プラットフォームに対する根源的に解決困難な攻撃が比較的短期間で可能になる状況がしばしば存在する。Intel系CPUに対するSpectre攻撃は、WebブラウザにおけるShared Array Buffer機能の利用を封印させるに至った。またセキュリティ対策がある時期に一気に普及することもある。HTTPSでないHTTPトラフィックの一般的な乗っ取りは、20世紀には理論上の存在でしかなかったが、現在では現実的な脅威となってきたため、ある時期にWebブラウザのベンダーやプラットフォーム側でHTTPの接続要求がHTTPSの接続要求に置き換えられるようになった。これらは安全策の強制が良い意味で世界を改善した例といえるが、いつから「対応必須」と言えたかは判断が難しく、「禁止の禁止」が強制されていたら実現は困難だったと考えられる。
この点では、プラットフォーム事業者がTerms of Serviceなどにおいて反競争的な禁止項目を追加したときに、そのプラットフォーム上のアプリ開発者やユーザーが幅広く反競争行為について申告できる対応窓口を行政側で提供し、それに基づいてプラットフォーム側に対応を要求する仕組みが構築されることが望ましいと考える。
一方で、類型的に反競争的なTerms of Serviceの追加などを事前に禁止類型として提示しておくことは、問題にならないと考える。プラットフォーム側に十分な対応リソースがあると考えるのが合理的である範囲においては、それを為さなければ独占禁止法違反となるという法的根拠がある限りにおいて、作為義務を認めることも妥当であると考える。なお、これに対して、たとえば「著作権法違反を防ぐため…」のような理由付けは独占禁止法違反の認定に内在する曖昧さとは無関係であり、本項に基づく作為義務の対象にはなりえないと考える。
＜中間報告の該当箇所：39ページ＞
デジタルプラットフォーム事業者が行っている行為については、データやアルゴリズムなどに関して、プラットフォーム事業者との間で情報の非対称性がある。このため、規制当局に対して、広範な情報提供や説明を求める権限を付与するなどの仕組みも考えられるか。
本項で注記された欧州委員会のほか、米国でもAmerican Innovation and Choice Online ActやOpen App Markets Actの制定といった動きがあり（これらは本報告書で後々に言及されている）、日本の行政においてもこれらの担当部署・機関と連携しての情報交換および国民に対する成果公開を期待したい。
第３. モバイル・エコシステムにおける各レイヤーに関する評価及び対応の方向性
総論としての事実認識、問題の提起については適切にまとめられていると考える。対応策に関しては、その妥当性および実効性について、II.各論で検討したい。
第４. モバイル・エコシステムにおける諸課題への対応における対象の考え方
＜中間報告の該当箇所：52ページ＞
モバイル・エコシステムにおける諸課題への対応策を検討するに当たっての対象の考え方について、どのように考えるか。
本報告書から想定される法規制の対象を競争市場とすることは妥当と考えるが、モバイルアプリケーションのプラットフォームに限らず、パーソナル・コンピューター市場も規制対象として考えるのが妥当であると考える。現状ではWindowsとMacのシェアが大きいが、Chromebookも普及しつつあり、Googleが対象となる日が来る可能性もあろう。ただし、本報告書で指摘されている通り、モバイルプラットフォームではデバイスの性質上プラットフォームベンダーがユーザーのアテンションを集中的に得られる等の側面があることが法の積極的な介入の理由のひとつであり、この問題が当てはまらない場面ではPCプラットフォーム市場は対象外とするのが適切であると考える。いずれにしても、独禁政策における市場策定や法の適用は公正に行われなければならない。
この他にゲームプラットフォームも独占的なアプリケーションの配布モデルとなっており、競争促進の観点では対象になりうるように思われるが、モバイルプラットフォームやPCプラットフォームとは異なり、行政の場面で利用するようなプラットフォームとはなっていないため、積極的な法システムが介入すべき市場としての側面が小さいことは否めない。
第５. モバイル・エコシステムにおける諸課題のとらえ方と対応の方向性
総論としての反競争状態に対する取り組みの方向性は、本節に付された諸外国動向資料を踏まえるに、正当なアプローチであると考える。
II. 各論: 第１. エコシステム内のルール設定・変更、解釈、運用
第１-１. 【OS・一部ブラウザ】
1. OS 等のアップデート・仕様変更への対応
＜中間報告の該当箇所：72ページ＞
オプション A は、問題の解決に有効か。また、どのようなメリットがあるか。
オプション A 以外に、問題の解決のために有効に機能すると見込まれる方策はあるか。
オプション A の実施に伴い、セキュリティ、プライバシー等どのようなコスト、リスクが生じるか。
その問題を軽減させる方策として、どのようなことが考えられるか
本項で論じられる本質的な問題は2点、(1)アップデートに（主に）Appleの規定する期限内に十分に対応できない (2)プラットフォームの新バージョン公開時に告知される新たな要求事項に対応する期間がAppleやGoogleにとって先行者利益をもたらす結果になっていること、と解釈できる。
このうち、後者を事前規制するのは困難で、独占的状態に対する規制すなわち事業分割を伴わなければ実効性が無いと考えられる。先行者利益は毎年とはいえ「たかだか数ヶ月」であり、これが長いか短いかは対象事業次第だが、独占的状態の規制を持ち出すにはさすがに問題が小さすぎると考えられる。プラットフォーム規制には、より直近に解決すべき問題が山積みである。
アップデートの内容および対応期間の問題について、特に日本語での「最新バージョンに関する適切な情報開示」「デベロッパからの問い合わせに関する手続・体制の整備」はほぼ実現できないと考えられる。プラットフォーム企業の日本法人はそもそも営業拠点でしかなく、プラットフォーム開発部隊のメンバーはおらず、短期間で新発表の技術等について伝達できる開発スキルを有する人材が十分にいない可能性が高く、簡単に増員できるものでもない。また、新バージョンの公開に伴って公表される資料は通常は膨大なもので、通常は一生日本語化されない。開発者が自己責任で機械翻訳にかけて読めれば十分である。
「運営状況の政府への報告」は、特に前者をプラットフォーム企業主導で行うことを要求しても、開発者が実際に直面する問題が適切に反映されない可能性がある。「政府によるモニタリング・レビューの実施」は、そのフォーマット次第ともいえるが、政府はアプリ開発者ではないので、プラットフォーム事業者から提供されるリソースをレビューできる技術力も時間リソースも無いであろう。それよりは、アプリ開発者および一般ユーザーが政府に対してプラットフォームの新たな制限等にかかる問題を報告できる窓口を設け、それに沿って政府側から新バージョン公表後は3ヶ月程度は毎月、各種変更追従対応にかかる要請（〜命令）を連絡する制度で対応するのが現実的かと思われる。
また、反競争的契約条項に関する報告窓口は常時設置して、新たな問題をタイムリーに審議し対応できる体制があることが望ましい。
2. OS のアップデート等に伴うアプリ開発の時間的優位性
＜中間報告の該当箇所：77ページ＞
事実関係や懸念事項について、さらなる情報（具体例の追加や補足等）はあるか。
Appleはこれまでに何度も反競争的な制限を開発者に課している。最初期に話題になったのは2010年にAdobe Flashを排斥するためにiPhone Developer Agreementに追加されたsection 3.3.1すなわちアプリケーションはObjective-C, C, C++をコンパイルしたものかWebKit上で動作するJavaScriptのみが許される(当時)とした条項である。
ゲーム開発フレームワークを開発しているUnity社は、それまで何の問題もなくC#でアプリケーションを開発し公開できていたものを、いったんC++コードに変換する仕組みに着手せざるを得なくなり、その後本条件が実質的にAdobeのみを狙い撃ちにするかたちで実施されているとわかるまで開発コストを割くことになった。（この仕組みはその後JITにかかるコーディング制限の緩和の目的でIL2CPPという名前で公開されている。）
本報告書で全く触れられていないと思われるのは、Google以外のAndroidデバイスベンダーが必要とするコードは、正式版のリリースまで全く公開されないことである。GoogleはAndroid 12が正式公開される前に3回のプレビュー版をリリースしたことが言及されているが、これはアプリケーション開発用のバイナリコードのみの公開であり、これは自社デバイスに向けてAOSPをカスタマイズしなければならないデバイスベンダーにとっては意味をなさない。ここで、アプリケーションではあまり問題にならない「2年間のサポートライフサイクル」の問題が、デバイスベンダーにとっては大きな問題になりうる。特に終期のないアプリケーションにとっての3ヶ月の先行利益とは異なり、最先端デバイスがリリースされてからの2年間のうち3ヶ月をキャッチアップに費やされる問題に対しては、何らかの制度的な救済が必要と思われる。
オプション A は、問題の解決に有効か。また、どのようなメリットがあるか。
オプション A 以外に、問題の解決のために有効に機能すると見込まれる方策はあるか。
いずれの分離政策も、日本単独で規定しても実効性が担保できない懸念があるものの、サンクションとしての制裁金を回収するレベルにまで至れば法的に完全に無意味というわけではないので、その方向で規定することに反対するものではない。とはいえ、規定の実効性が確保できる方が望ましく、EU・米国等関心のある各国で提携して、あるいはWTOのような組織レベルで、条約レベルで独占禁止政策を共同施行できる仕組みを模索されたい。
もっとも、コロナ禍も経て世界的にリモートワークが普及した2022年以降の世界で、データ分離は開発業務においてオフラインワークの強制に繋がることにもなりかねず、また分離業務が行われているという虚偽の申告に対しても検証可能性が低く（AppleやGoogleはEU圏では法令遵守より法規違反に伴う制裁金のほうが安いと判断すればその道を選んでいるという実績がある）、実効性が疑わしいように思える。
私見としては、独占的プラットフォームにかかるこれ以外の問題が解決されれば、この問題自体は「プラットフォーム開発者は先行者利益だけは引き続き得ることになるが、それも競争政策上否定すべきか?」という問題になり、これに対しては答えは割れるのではないかと思う。その意味では「他の問題が解決するまでの条件付き規制」という位置付けにする選択肢もあると考えられる。
5. ブラウザにおけるトラッキングのルール変更（Google）
＜中間報告の該当箇所：89ページ＞
本件にかかる最終的な意見は「2. OS のアップデート等に伴うアプリ開発の時間的優位性」におけるものと変わらない。
Google Privacy Sandboxについては、Google Play Servicesの機能のアプリケーションバンドル（aab/apk）からの分離によって「悪意のある改ざんが加えられていない」広告SDKの仕組みが期待でき、セキュリティと透明性に資するものと考える（Google Play Adsの仕組みが透明化されるという意味ではなく、Google Play Servicesの機能の一部がPrivacy SandboxによってGoogleの制御下でダウンロードされるようになれば、GPSを利用するアプリケーションにGPSのコードをバンドルする必要も、それに伴ってapkがGoogleのライセンスに拘束されることもなくなる、という意味において）。とはいえ、現時点ではAndroid 13以降でのみ利用可能な機能であり、まだ未来形の話であると理解している。
6. クローズド・ミドルウェア（Google）
＜中間報告の該当箇所：94ページ＞
一定規模以上の OS を提供する事業者が、当該 OS をオープンソースで提供している場合には、アプリの開発環境を提供するときは、その開発環境に、当該オープンソースの OS を利用して自らの OS を提供する事業者がアクセスできるようにすることを義務付ける規律を導入することが考えられるのではないか。
オプション A は、問題の解決に有効か。また、どのようなメリットがあるか。
オプション A 以外に、問題の解決のために有効に機能すると見込まれる方策はあるか。
これは公平性に欠け、プラットフォーム事業者に要求できることではない。「当該 OS をオープンソースで提供している場合には」という条件の設定が失当である。プラットフォームAPIが非独占的であることがプロプラエタリ部分のオープンソース化を要求できる正当な理由にはならない。クローズドミドルウェアによる囲い込みの解消策は、Windowsを公開しているMicrosoftにも、iOSやmacOSを公開しているAppleにも、等しく公正に要求すべきである。モバイル・プラットフォームであるか否かは、囲い込みの成否に影響する問題ではない。本項目の記述からは、そのような公正な発想が欠落している。実務上も「（理由は全くわからないが）プロプラエタリOSにすれば解決だ」と考えてプラットフォームコードの一部を非公開にして回避されるだけであり、透明性確保に完全に逆行することになる。
「サードパーティのOS開発者には許可制で見えるようにするのは一つの手」などと意見しているのは、おそらく日本マイクロソフトの関係者かアマゾン・ジャパンの関係者からの差し込みであろうと考えられる。日本の競争政策はGoogle/Apple以外の独占的プラットフォームが横槍を入れるために存在するものではない、ということを確認したい。
Google Play Services (GPS)の囲い込み問題を解決するための、より適切な方法は、GPSに相当するプラットフォームサービスプロバイダーAPIの策定とその適用をプラットフォーム提供者に義務付けることである。これならばGoogle等プラットフォーム事業者に「反競争状態を解消するための現実的かつ妥当なコスト」として認められると考えられる。Google Android以外のAOSP互換プラットフォームで当該サービスプロバイダーAPIの実装が存在しない状態がある場合に、それによってアプリケーションが利用できない不利益を受けるべきはプラットフォーム事業者であるべきである。
第１-２. 【アプリストア】
７. アプリストアの拘束（Apple）
＜中間報告の該当箇所：98ページ＞
報告書に示されているようなAppleの主張は、米国でOpen App Markets Actが審議されていたときに、日本も含め世界的に名前が広く知られている米国のセキュリティ研究者Bruce Schneierによって幅広く否定されており、日本語でもその詳細が「競争法案に反対するアップルの主張に反論するブルース・シュナイアーの意見書」という翻訳文書で読めるようになっている。
実際、Appleは開発者向けオンラインカンファレンスWWDC 2022において、iOS 16で開発者モードを導入し、開発者署名が付いたものはApp Storeで公開されていないアプリケーションであっても実行できるようにしている。Appleの開発者用ベータテスター向けアプリ配布サービスTestFlightを使用するとアプリケーションが配布できたため従前と変わらないという主張も見かけるが、開発者署名が付加されていれば配布チャンネルを問わないというのはsideloadingに近いと考えられる。何より、これはEUのDMAに対応するための機構と考えられている。開発者署名はAppleの有償サービスに開発者登録しないと付加できないため、これが実際にDMA適合的であるとは言えないとも考えられるが、まずは具体法をもつEUの判断が待たれる。日本でも同等の立法に着手し、反競争行為を積極的に規制していく必要があろうと考える。
なお、iOS16によって実現している開発者モードには、「8.サイドローディングの制限（Google）」で指摘される問題が同様に当てはまると考えられる。
この節にまとめられているAppleの主張にも理由がない。macOSからもiCloudに保存されている情報をはじめとする重要な個人情報にアクセスできることにも、ユーザーからの承認を得ない限りこれらの情報にアクセスできないことにも、iOSとmacOSで違いはない。
１２. OS 等の機能のブラウザに対するアクセス制限（Apple）
＜中間報告の該当箇所：166ページ＞
事実関係、懸念事項に関するさらなる情報について
・事実関係や懸念事項について、さらなる情報（具体例の追加や補足等）はあるか。
本節によればAppleは「JIT は、攻撃者が iPhone デバイスにアクセスするために悪用できる攻撃対象領域を提供するため、JIT コンパイラを使用する代替エンジンは、セキュリティ上の大きな脅威となる」と説明しているが、このAppleの主張は、GoogleがかつてWeb Assembly技術の前身ともいえるNaCL (Native Client)と呼ばれる技術において、コードの書き換えに繋がる命令を書き換えることで危険なコードの実行を抑止しつつJITを有効にする手段が有効であったことから、端的に事実に反している。
*1:と書くと他人事っぽいですが多少は自分も波風を立てたはず…
