Windows、Mac、Linux のデバイスでは、スタートアップ時に自動起動するようにネイティブ アプリを設定できます。Run on OS Login（OS ログイン時に実行）機能は、Chrome 91 で導入されました。この機能がリリースされたことで、ユーザーが Windows、Mac、Linux のデバイスにログインしたときに、デスクトップ ウェブアプリを自動起動する設定が可能になっています。 インストール済みのアプリは、自身の自動実行を自動的に有効化することはできません。常にユーザーによる手動操作が必要です。 OS ログイン時にアプリを実行するよう設定するには、Chrome ブラウザを開き、chrome://apps に移動するか、ブックマーク バーの [ アプリ ] アイコン（下の例）をクリックします。
chrome://apps
リリースされたばかりの Pixel 6 と Pixel 6 Pro は最も安全な Pixel スマートフォンであり、5 年間にわたるセキュリティ アップデートが適用されるほか、最もレイヤー数の多いハードウェア セキュリティを備えています。これらの新しい Pixel スマートフォンでは、レイヤー化されたセキュリティ アプローチを採用しており、Google Tensor SoC（System on a Chip）ハードウェアから Pixel で先行利用できる Android オペレーティング システムの新機能に至るまでのイノベーションを活用して、チップからデータセンターまでを網羅する Google セキュリティが適用された最初の Pixel スマートフォンを実現しました。また、複数の専属のセキュリティ チームが開発を担当して、透明性と外部検証を通じて Pixel のセキュリティを証明しています。
コアにセキュリティを提供
Google は、Google Tensor を使用して、ハードウェア セキュリティの最重要部にユーザーデータの保護と透明性を提供しています。Google Tensor のメイン プロセッサは Arm ベースであり、TrustZone™ テクノロジーを活用しています。TrustZone は、一般的な処理を安全に行うセキュリティ アーキテクチャの重要な要素ですが、Google Tensor に含まれているセキュリティ強化は、TrustZone の一歩先を進んでいます。
Google Tensor セキュリティ コアは、ユーザー プライバシーの保護に特化したカスタム設計のセキュリティ サブシステムです。このサブシステムは、アプリケーション プロセッサとは論理的かつ物理的に異なり、専用 CPU、ROM、OTP（1 回しか書き込めない）メモリ、暗号化エンジン、内部 SRAM、保護された DRAM で構成されます。Pixel 6 と Pixel 6 Pro の場合、セキュリティ コアの主要なユースケースには、実行時にユーザーデータ キーを保護したり、セキュアブートを強化したり、Titan M2TM と連携したりすることが含まれます。
ハードウェアの安全性は、OS が安全であるときにのみ確保されます。Google では、オープンソースの信頼できる実行環境である Trusty を使用しています。Trusty OS は、TrustZone と Google Tensor セキュリティ コアの両方で使用される安全な OS です。
Pixel 6 と Pixel 6 Pro では、Google がすべてを設計して開発した別個のセキュリティ チップである新しい Titan M2TM によってセキュリティが強化されています。この次世代チップを採用したことにより、Google は社内設計した RISC-V プロセッサに移行し、速度とメモリ容量を向上し、高度な攻撃に対する耐性をさらに強化しています。Titan M2TM は、独立した認定済みの評価ラボによって、脆弱性評価の最も厳格な標準である AVA_VAN.5 に照らしてテストされています。Titan M2™ は Android StrongBox をサポートします。Android StrongBox は、PIN とパスワードの保護に使用されるキーを安全に生成して格納し、Google Tensor セキュリティ コアと連携して、SoC で使用中のユーザーデータ キーを保護します。
システムが改善された Pixel 6 と Pixel 6 Pro は、Android 12 と、Pixel で先行利用や限定利用ができるたくさんの機能が搭載された状態で出荷されます。
強化されたコントロール
Google は、Android のリリースのたびに、データをコントロールしてデバイスを管理するより適切な方法をユーザーに提供することを目指しています。Pixel で使用される Android 12 以降では、新しいセキュリティ ハブを使用して、すべてのセキュリティ設定を 1 か所で管理することができます。つまり、デバイスの現在の構成を一元的に表示することにより、スマートフォン、アプリ、Google アカウント、パスワードを保護できるようにしています。また、セキュリティ ハブは、セキュリティを改善するための推奨事項を提供するため、ニーズに最適な設定を判定できるようになります。
Google はプライバシーのためにプライバシー ダッシュボードをリリースし、過去 24 時間以内に位置情報、マイク、カメラにアクセスしたアプリをシンプルで明確なタイムライン形式で表示できるようにしています。予想よりも多くのデータにアクセスしているアプリに気付いた場合、ダッシュボードには、それらのアプリのパーミッションをすぐに変更できるコントロールへのパスが表示されます。
さらに透明性を向上するため、アプリがカメラやマイクにアクセスしていることが、Pixel のステータスバーにある新しいインジケーターでわかるようになっています。アクセスを無効にしたい場合、プライバシーの新しい切り替え機能により、1 回タップするだけで、スマートフォンのアプリによるカメラやマイクへのアクセスをいつでもオフにすることができます。
Pixel 6 と Pixel 6 Pro には、セキュリティが低い 2G ネットワークにアクセスするデバイスの機能を削除する切り替え機能も含まれています。一部の状況では 2G ネットワークへのアクセスが必要になりますが、さらなる攻撃ベクトルが発生する可能性があります。この切り替え機能は、2G 接続が不要なときに、そのリスクを軽減することに役立ちます。
組み込みのセキュリティ
Google はすべてのプロダクトをデフォルトで安全にするために、オンラインの安全を維持することに他の誰よりも取り組んでいます。また、Pixel 6 と Pixel 6 Pro では、デフォルトで組み込まれている保護機能を強化しています。
画面に埋め込まれた光学指紋認証センサーは、バイオメトリック情報の安全を確保し、デバイスの外に流出することを防ぎます。Google の継続的なセキュリティ開発ライフサイクルの一環として、Pixel 6 と Pixel 6 Pro の指紋認証によるロック解除は、外部のセキュリティ エキスパートによって、Android 12 互換性定義ドキュメント（Compatibility Definition Document、CDD）で定義されているクラス 3 強度要件を満たす安全な生体認証ロック解除メカニズムとして検証されています。
フィッシングは強大な攻撃ベクトルであり続け、さまざまなデバイスを使用しているすべての人に影響を及ぼしています。
Pixel 6 と Pixel 6 Pro では、新しいフィッシング対策保護機能が導入されています。組み込みの保護機能は、通話、テキスト メッセージ、メール、アプリを通じて送信されるリンクからの潜在的な脅威を自動的にスキャンし、潜在的な問題がある場合は、ユーザーに通知します。
また、ユーザーは、Google Play プロテクト内のオンデバイス検出機能に加えられた機能強化により、悪意のあるアプリからより強固に保護されています。Google Play プロテクトは 2017 年にリリースされて以来、デバイスがオフラインのときでも、悪意のあるアプリを検出できるようにしてきました。Pixel 6 と Pixel 6 では、Google Play プロテクトでのマルウェア検出を強化する新しい機械学習モデルを使用しています。この検出機能は Pixel で実行され、フェデレーション アナリティクスと呼ばれるプライバシー保護テクノロジーを使用して、一般的に実行される悪意のあるアプリを検出します。これにより、すでに 1,000 億個のアプリを毎日分析して脅威を検出している Google Play プロテクトが改善され、30 億人を超えるユーザーにさらに強固な保護を提供します。
Pixel の多くのプライバシー保護機能は、残りのオペレーティング システムやアプリから分離されたオープンソースのサンドボックスである Private Compute Core 内で実行されます。Google のオープンソースの Private Compute Services は、これらの機能のネットワーク通信を管理し、プライバシーを保護すると同時に、フェデレーション ラーニング、フェデレーション アナリティクス、個人情報の取得を通じて機能を改善します。Private Compute Core ですでに実行されているいくつかの機能には、自動字幕起こし、この曲なに？、スマート リプライの提案などが含まれます。
Google Binary Transparency（GBT）は、Google のオープンで検証可能なセキュリティ インフラストラクチャに追加された最新機能であり、デバイスのソフトウェア整合性に新しいレイヤーを追加します。証明書の透過性によって導かれる原則を基に構築された GBT は、Pixel で実行できるソフトウェアを、認定された OS ソフトウェアのみに限定します。GBT は、システム イメージのハッシュを署名し、追加専用のログに格納することで機能します。このログは公開され、公開されたハッシュとデバイスにあるハッシュが同じであることを検証するために使用できます。これにより、ユーザーと研究者は初めて、OS の整合性を独立して検証できるようになりました。
スマートフォン以外への拡張
多層防御は、ハードウェアとソフトウェアのレイヤーだけの問題ではありません。セキュリティは厳密なプロセスです。Pixel 6 と Pixel 6 Pro では、設計やアーキテクチャの詳細なレビュー、セキュリティ上重要なコードのメモリ安全な書き換え、静的分析、ソースコードの公式検証、重要なコンポーネントのファジング、デバイスに侵入テストする外部のセキュリティ ラボなどが含まれたレッドチームを活用しています。また、Pixel は Android 脆弱性報奨金プログラムに含まれています。昨年、このプログラムでは 175 万ドルが支払われ、Google とセキュリティ リサーチ コミュニティの間に有益なフィードバック ループを構築したほか、最も重要であるユーザーの安全を引き続き確保できるようにしています。
ハードウェアとソフトウェアが組み合わされた、このセキュリティ システムを締めくくるのは Titan Backup Architecture です。このアーキテクチャにより、クラウドでの Pixel の安全な土台が確保されます。Android のバックアップ サービスと Google Cloud の Titan テクノロジーの組み合わせは 2018 年に発表され、クライアント以外は Google を含め誰もが知らないランダムに生成されたキーのみによって、バックアップされたアプリケーション データを復号化できるようにします。このエンドツーエンドのサービスはサードパーティのセキュリティ ラボによって別個に監査され、パスコードを明確に知らない限り、ユーザーのバックアップされたアプリケーション データに誰もアクセスできないことが検証されました。
ハードウェアやソフトウェアからデータセンターに至るまでのこのエンドツーエンドのセキュリティに加え、Pixel 6 と Pixel 6 Pro デバイスでは、米国で発表されてから 5 年以上の Android セキュリティ アップデートが保証されています。これは、業界にとって重要な取り組みであり、他のスマートフォン メーカーもこの取り組みを推進することを望んでいます。
Google は安全なチップセット、ソフトウェア、プロセスを連携させることにより、Pixel 6 と Pixel 6 Pro を最も安全な Pixel スマートフォンにすることができました。
理由と解説 : 悪意のある人物がデベロッパー アカウントにアクセスできる場合、既知の貢献者になりすまして悪意のあるコードを送信する可能性があります。貢献者には、commit を送るプラットフォームだけでなく、メールなどの貢献に関連するアカウントに対して、多要素認証（MFA）を使うことを推奨しましょう。可能であれば、MFA の方式でお勧めなのはセキュリティ キーです。
理由と解説 : セルフマージ（一方的な変更とも呼ばれます）には、1）貢献者のアカウントを乗っ取った攻撃者がプロジェクトに悪意のあるコードを注入する可能性がある、2）善意の貢献者が意図しないセキュリティ リスクを含む commit をマージする可能性がある、という 2 つのリスクがあります。悪意のあるコードの送信や意図しない脆弱性を回避するために役立つのが、身元が明らかで信頼できる別の人の目です。可能であれば、GitHub のブランチ保護設定などを使い、自動要件として設定しましょう。Allstar などのツールも、この要件の適用に役立ちます。これは、SLSA レベル 4 に対応します。
理由と解説 : 「多層防御」というセキュリティの考え方は、複数の異なる防御レイヤーを設けてシステムやシークレット * などの機密データを守ることを指します。シークレット マネージャー ツール（GCP ユーザーの Secret Manager や、HashiCorp Vault、CyberArk Conjur、Keywhiz など）を使うと、ソースコードにシークレットをハードコードする必要はなくなり、集中管理や機能の監査を実現できます。また、シークレットの漏洩を防ぐ認可レイヤーを導入することにもなります。
* 機密データを CI システムに保存する場合は、それが CI/CD のためだけに使われることや、パスワードや ID マネージャーに格納するほうが適したデータではないことを確認してください。
理由と解説 : デフォルトでプロジェクト リポジトリに対して「必要最低限のアクセス」を付与することで、意図しないアクセスと不正利用の両方から CI/CD システムを守ることができます。テストを行うことは重要ですが、デフォルトですべての commit と pull リクエストに対してレビュー前にテストを実行すると、CI/CD システムのコンピューティング リソースの意図しない不正利用につながる可能性があります。
理由と解説 : 手動でビルド手順を実行すると、意図しない構成ミスが紛れ込む可能性があります。しかし、ビルド スクリプト（ビルドやビルドの手順を定義した build.yaml などのファイル）を使えば、手動でビルドする必要はなくなります。加えて、悪意のある人物がビルドを改ざんしたり、レビューされていない変更を紛れ込ませたりする機会を減らすことにもなります。これは、SLSA レベル 1～4 に対応します。
理由と解説 : 1 つの決定的な手法でパッケージが「良い」か「悪い」かを判断することはできません。セキュリティ プロファイルや許容できるリスクは、プロジェクトごとに異なります。プロジェクトにとって依存関係が「安全」であるかどうかを判断するうえで役立つのは、依存関係やどのような変更が推移的に取り込まれるかの情報を集めることです。Open Source Insights（deps.dev）などのツールは、最初のレイヤーと推移的依存関係をマッピングしてくれます。一方の Scorecards は、セキュリティ ポリシー、MFA、ブランチ保護の使用有無など、複数のリスク評価指標に基づいてパッケージのスコアを算出します。
使っている依存関係を把握できたら、定期的に Open Source Vulnerabilities などの脆弱性スキャンツールを実行します。そうすることで、常に最新のリリースやパッチについての情報を得ることができます。多くの脆弱性スキャンツールは、アップグレードの自動適用にも対応しています。
理由と解説 : ビルドの出所（ビルドの来歴）とアーティファクトを表示すると、ビルドが改ざんされていないことや、正しいものであることをユーザーに示すことができます。来歴にはさまざまな要素があります。こういった要素を実現する 1 つの方法は、来歴を表示するために必要なデータを生成と認証するビルドサービスを利用することです。これは、SLSA レベル 2～4 に対応します。
理由と解説 : 来歴の生成やビルドの署名は、自分のプロジェクトで行うべきことであるだけでなく（SLSA レベル 2～4）、他者のアーティファクトを使うときも、同じ証明を求めるべきです。ロゴなどのブランドに基づく認定形態は偽造可能で、タイポスクワッティングによって正当性を偽装できます。署名などの偽造できない証明を求めるようにしてください。たとえば Sigstore は、OSS プロジェクトでビルドに署名したり、他者のビルドを検証したりする際に役立ちます。
特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。2021 年 10 月 21 日の時点で Chrome 96 はベータ版です。
来年には、Chrome でバージョン 100 がリリースされます。つまり、Chrome のユーザー エージェント文字列で報告されるバージョン番号の桁が増えます。サイトオーナーが新しい文字列をテストしやすくするために、Chrome 96 では、Chrome のユーザー エージェント文字列として「100」が返されるようにするランタイム フラグが導入されています。chrome://flags/#force-major-version-to-100 と呼ばれるこの新しいフラグは、Chrome 96 以降で利用できます。
chrome://flags/#force-major-version-to-100
このバージョンの Chrome には、以下のオリジン トライアルが導入されています。オリジン トライアルとして新機能を試せるようにすることで、ウェブ標準コミュニティにユーザビリティ、実用性、有効性についてのフィードバックを提供することができます。以下の項目を含め、現在 Chrome でサポートされているオリジン トライアルに登録するには、Chrome オリジン トライアル ダッシュボードをご覧ください。Chrome のオリジン トライアルの詳細については、ウェブ デベロッパーのためのオリジン トライアル ガイドをご覧ください。Microsoft Edge は、Chrome とは別に独自のオリジン トライアルを行っています。詳細については、Microsoft Edge オリジン トライアル デベロッパー コンソールをご覧ください。
現在、他のウィンドウやタブをキャプチャするアプリケーションには、呼び出し元のアイテムやキャプチャするアイテムにフォーカスするかどうかをコントロールする方法がありません（ビデオ会議アプリのプレゼンテーション機能を思い浮かべてください）。Chrome 96 では、新しい focus() メソッドをサポートする FocusableMediaStreamTrack と呼ばれる MediaStreamTrack のサブクラスを使用して、このコントロールを可能にしました。次のコードをご覧ください。
focus()
FocusableMediaStreamTrack
MediaStreamTrack
stream = await navigator.mediaDevices.getDisplayMedia(); let [track] = stream.getVideoTracks();
このコードでは、以前は getVideoTracks() が MediaStreamTrack オブジェクトの配列を返していましたが、FocusableMediaStreamTrack オブジェクトを返すようになります（Chrome 97 では、返されるオブジェクトが BrowserCaptureMediaStreamTrack に変更される予定です。本記事の執筆時点で、Canary 版ではすでに新しいオブジェクトが返されるようになっています）。
getVideoTracks()
BrowserCaptureMediaStreamTrack
フォーカスするディスプレイ メディアを決定するには、このコードの次の行で "focus-captured-surface" を指定して track.focus() を呼び出し、新しくキャプチャするウィンドウやタブにフォーカスするか、"no-focus-change" を指定してこのメソッドを呼び出し、呼び出し元のウィンドウにフォーカスし続けます。Chrome 96 以降では、デモコードを試して、この機能の動作を確認できます。
"focus-captured-surface"
track.focus()
"no-focus-change"
Priority Hints では、デベロッパーが設定する "importance" 属性が導入され、計算されるリソースの優先度を変更することができます。サポートされる importance 属性の値は、"auto"、"low"、と "high" です。Priority Hints は、リソースの相対的な重要度をブラウザに示し、リソースが読み込まれる順序をより細かくコントロールできるようにします。ブラウザでは、リソースのタイプ、可視性、プリロードのステータスなど、多くの要素がリソースの優先度に影響を及ぼします。
"importance"
"auto"
"low"
"high"
プリフライト リクエストなしに、単純な Range ヘッダーを指定してリクエストを送信できるようになりました。CORS リクエストでは、プリフライト リクエストをトリガーせずに、Range ヘッダーを限定的な方法（1 つの有効な範囲のみ）で使用できます。
バックフォワード キャッシュにページが格納され、クロスサイト ナビゲーションをした後でも、以前にアクセスしたページへの即時ナビゲーションが可能になります。
Cross-Origin-Embedder-Policy には、クロスオリジン no-cors リクエストで認証情報（Cookie やクライアント証明書など）を省略できるようにする新しい credentialless オプションが追加されます。COEP:require-corp と同じように、クロスオリジン分離も有効化できます。
Cross-Origin-Embedder-Policy
no-cors
credentialless
COEP:require-corp
SharedArrayBuffer を使い続けたいサイトでは、クロスオリジン分離をオプトインする必要があります。COEP: require-corp を使用して、クロスオリジン分離のオプトインを大規模に導入することは難しく、すべてのサブリソースで明示的にオプトインしなければならなくなります。これが問題にならないサイトもありますが、ユーザーからコンテンツを収集するサイト（Google Earth、ソーシャル メディア全般、フォーラムなど）では、依存関係の問題が発生します。
COEP: require-corp
新しい autofill 疑似クラスを使用すると、自動入力されるフォーム要素のスタイルを設定できます。これは、:-webkit-autofill 疑似クラスの標準化として導入されており、WebKit ではすでにサポートされています。Firefox は、この標準バージョンをサポートします。
autofill
:-webkit-autofill
writing-mode、direction、background など、一部のプロパティは、body からビューポートに伝播されます。CSS コンテナクエリの無限ループを防ぐために、仕様と実装が変更され、HTML または BODY にレイアウトの封じ込めが適用される際にこれらのプロパティが伝播されなくなりました。
font-synthesis CSS プロパティは、フォント ファミリーにフェイスがない場合、ユーザー エージェントが斜体、太字、小型英大文字のフォント フェイスを合成できるようにするかどうかをコントロールします。
font-synthesis
MediaKeySession.closed プロパティは、enum を使用して、MediaKeySession オブジェクトが閉じられた理由を示すようになります。この closed プロパティは、セッションが閉じたときに解決される Promise を返します。以前は Promise が解決されるだけでしたが、文字列として解決されるようになり、閉じられた理由を示します。返される文字列は、"internal-error"、"closed-by-application"、"release-acknowledged"、"hardware-context-reset"、"resource-evicted" のいずれかです。
MediaKeySession.closed
MediaKeySession
"internal-error"
"closed-by-application"
"release-acknowledged"
"hardware-context-reset"
"resource-evicted"
Chrome では、DNS（ドメイン名サービス）から HTTPS レコードが利用できる場合は、常に HTTPS 経由でウェブサイトに接続します。
PerformanceEventTiming インターフェースに interactiveID と呼ばれる属性が含まれるようになりました。これは、ブラウザが生成する ID であり、複数の PerformanceEventTiming エントリが同じユーザー操作に対応する場合、これらのエントリをリンクできるようにします。現在、デベロッパーは Event Timing API を使用して、関心のあるイベントのパフォーマンス データを収集できます。ただし、同じユーザー操作に対応するイベントをリンクすることは困難です。たとえば、ユーザーがタップしたときなら、pointerdown、mousedown、pointerup、mouseup、click など、多くのイベントが生成されます。
PerformanceEventTiming
interactiveID
pointerdown
mousedown
pointerup
mouseup
click
Chrome は、 'prefers-contrast' と呼ばれる新しいメディアクエリをサポートします。そのため、ウェブ制作者は、オペレーティング システムで設定されたユーザーのコントラスト設定（具体的には、macOS のコントラストを強調したモードと Windows のハイ コントラスト モード）にウェブ コンテンツを合わせることができます。有効な選択肢は、'more'、'less'、'custom'、または 'no-preference' です。
'prefers-contrast'
'more'
'less'
'custom'
'no-preference'
ウェブアプリ マニフェストで任意の id フィールドがサポートされ、ウェブアプリをグローバルに特定できるようになりました。id フィールドがない場合、PWA は start_url にフォールバックします。現時点で、このフィールドはデスクトップのみでサポートされます。
id
start_url
ウェブ アプリケーションがインストール マニフェストを使用して、カスタム URL プロトコル / スキームのハンドラとして自身を登録できるようにします。多くの場合、オペレーティング システム アプリケーションは自身をプロトコル ハンドラとして登録して、見つけやすさと使用率を向上します。ウェブサイトは、すでに registerProtocolHandler() を介してスキームを処理するように登録できます。この新機能はもう一歩踏み込んで、カスタム スキーム リンクが呼び出されたときに、ウェブアプリを直接起動できるようにします。
registerProtocolHandler()
Chrome のコンテンツ セキュリティ ポリシーが強化され、WebAssembly との相互運用性が向上しています。wasm-unsafe-eval は、WebAssembly の実行をコントロールします（JavaScript の実行には影響しません）。また、script-src ポリシーに WebAssembly が含まれるようになりました。
wasm-unsafe-eval
script-src
WebAssembly モジュールで JavaScript オブジェクトや DOM オブジェクトへの参照を保持できるようになりました。具体的には、これらの参照は、引数として渡したり、ローカル変数やグローバル変数に格納したり、WebAssembly.Table オブジェクトに格納したりできます。
このバージョンの Chrome では、以下のサポートの終了と機能の削除が行われます。現在サポートが終了している機能と以前に削除された機能のリストは、ChromeStatus.com をご覧ください。
PaymentRequest API では、"basic-card" 支払い方法が非推奨となっています。その使用率は低いうえ、低下し続けています。この支払い方法の購入手続きまでの時間や購入完了率は、他の支払い方法を下回っています。デベロッパーは、代わりとして他の支払い方法に切り替えることができます。たとえば、Google Pay、Apple Pay、Samsung Pay などの支払い方法です。 削除までのタイムライン :
Google はテクノロジーが社会をより良くしていくと考えています。私たちは社会の大きな課題を解決するためのアイデアを持つスタートアップをテクノロジーの力で支援したいと考えています。そのため、Google では、Google for Startups Accelerator というスタートアップを支援するアクセラレータプログラムを日本でも継続的に行っております。
この度、Google for Startups Accelerator のプログラムにおいて、参加するスタートアップに対して技術的メンタリングを提供してくださるメンターを募集いたします。メンターの方にはスタートアップへのメンタリングを通じて、 テクノロジーを活用した社会、経済、環境といったさまざまな分野の問題解決への取り組みをともに解決し、ひいては、スタートアップの成長が日本経済のさらなる活性化につながることへの貢献を一緒に行っていければと考えています。
メンターとして参画してくださる方、ぜひこちらのフォームよりご応募ください。
canMakePayment()
false
