AstroやVue、Svelteで作ったサイトでは、型検査を tsc だけで済ませられませんでした。.astro や .vue のファイルはTypeScriptのコンパイラが読めないため、astro check のような専用の道具を別に動かす必要があります。TypeScript 7（Goで書き直された版）に上げると、この専用の道具が動かなくなる、という問題も出ています。npmに公開されているAstro（7.4.7と、11月10日時点の最新の7.4.10）の astro check のソースは、TypeScriptのメジャー版が7以上だと「TypeScript 7.0には対応していない。TypeScript 6を入れること」というエラーで止まるよう書かれています。
TypeScript 7.1のベータには、この穴を埋める「content mapper（コンテンツマッパー）」という仕組みが入りました。ただし、使うにはコンパイル中に外部のコードを実行する許可が必要です。本記事では、TypeScriptの公式ブログの告知、TypeScriptのリポジトリ（microsoft/TypeScript）の原文、npmに公開されたパッケージの中身から、仕組みと、使い始める前に決めておくことを整理します。
TypeScript 7.1ベータの位置づけ
npmの typescript パッケージでは、2026年11月11日時点で次のタグが付いています。
latest（通常のnpm i typescriptで入る版）: 7.0.2（2026年7月8日公開）beta: 7.1.0-beta（2026年10月20日公開）next: 7.1.0-dev.20261110.1（毎日の開発版）
7.1はまだベータで、ベータより新しいRC（リリース候補）や正式版はnpmに出ていません。公式ブログの告知「Announcing TypeScript 7.1 Beta」（2026年10月20日）は、RCを「about a month from now（約1か月後）」、正式版をその少し後としています。7.1.0-betaのパッケージの exports には、./sync・./async・./ast などのAPIの入口が並んでいます。TypeScript 7.0への移行の全体像は、TypeScript 7.0の移行ガイドで扱いました。
contentMappersの書き方
content mapperは、TypeScriptが読めない形式のファイルを、型検査できる形に変換して渡す外部のプログラムです。公式ブログは、拡張子ごとに登録し、ファイルの仮の表現と元のファイルへの対応づけを返す「新しいプラグインの差し込み口」と説明しています。同じ告知によると、Astro・CSS Modules・Ember・MDX・Svelte・Vue向けに、試作または実装が進んでいます。tsconfig.json の最上位に contentMappers を書きます。7.1.0-betaに同梱されたスキーマでは、配列の各要素が package（パッケージ名、必須）、extensions（扱う拡張子、必須）、options（任意）の3つの項目を持ちます。
Astroのチームは、.astro 用の @astrojs/ts-content-mapper を公開しています（npmの最新は0.2.0、2026年9月22日公開）。READMEに書かれた設定は次のとおりです。
{
"compilerOptions": {},
"contentMappers": [
{
"package": "@astrojs/ts-content-mapper",
"extensions": [".astro"]
}
]
}実行は次のコマンドです。
tsc --noEmit --runExternalCodeスキーマの説明文には「Execution must be enabled separately with --runExternalCode.（実行はこのフラグで別に有効にする必要がある）」とあります。公式ブログも、content mapperは事実上どんなプログラムでも実行できるため、このフラグで明示させる、と説明しています。tsconfig.json に書いただけでは、マッパーは動きません。フラグなしで実行した場合のために、「Content mappers require the '--runExternalCode' command line flag to be enabled.」というエラーの文言が用意されており、7.1.0-betaの実行ファイルにもこの文言が含まれています。
なぜ「外部コードの実行」の許可が要るのか
TypeScriptのリポジトリには、信頼できない入力に対して tsc が何を保証するかをまとめた文書があります。そこでは、悪意のある .ts や tsconfig.json を tsc にかけても入力のコードが実行されることはない、これが tsc の中心となるセキュリティ上の性質だ、と書かれています。そのうえで、例外として次の一文があります。
content mapperを有効にすると、第三者のコードの実行が可能になる。どのcontent mapperが使われるかを確かめ、それを実行してよいと判断した場合にだけ
--runExternalCodeを渡すこと。
同じ文書には、tsc はcontent mapperを通じた場合を除いて、HTTPの通信もしないし子プロセスも起動しない、ともあります。言い換えると、フラグを付けた瞬間から、型検査のコマンドが「node_modules に入っているパッケージのプログラムを起動するコマンド」に変わります。@astrojs/ts-content-mapper の package.json にも、変換を受け持つ処理として node dist/server.js を起動する設定が書かれています。
エディタでは既定で有効になっている
コマンドラインでは明示の許可が必要な一方、TypeScript 7のVS Code拡張（リポジトリの packages/vscode-typescript）では扱いが異なります。
- 設定
js/ts.contentMappers.enabledの既定値は true（試験的な設定という印が付いている） - この設定の値が、言語サーバーへの
runExternalCodeとしてそのまま渡される - 拡張の
package.jsonでは、信頼していないワークスペース（untrusted workspaces）には対応しない、と宣言されている
公式ブログも、VS Codeなどのエディタでは content mapper が「just works（そのまま動く）」とし、ワークスペースの信頼と content mapper の許可の両方が要ること、js/ts.contentMappers.enabled で無効にできることを書いています。リポジトリのセキュリティ方針の文書には、node_modules から来るものも含め、content mapper は「プロジェクトのコード」の一部で、そのワークスペースを信頼すれば実行される、とあります。
2026年10月19日のコミット（#64837）では、言語サーバーがcontent mapperを読み込む場所を、ワークスペースのフォルダーの中にある node_modules だけに限る変更が入りました。ただし、ベータの元になったコミット（release-7.1ブランチの3e92363、10月19日20時38分 UTC）とGitHub上で比べると、この変更はその約2時間後にmainへ入っており、ベータには含まれていません。また、11月3日には、相対パスで指定したマッパーを、そのマッパーを宣言した設定ファイルの場所から解決する修正（#65105）が入っており、これはベータより後の開発版の変更です。11月9〜10日にも、content mapperで変換したファイルへのジャンプや、モジュール形式の扱いの修正（#65009・#65417・#65432）がmainに入りました。仕組みの細部はまだ動いています。
CIやチームで使い始める前に決めること
ここからは、上の原文をもとにした編集部の提案です。編集部では --runExternalCode を付けた実行は行っていません。
フラグを付けるのは、依存関係を固定したリポジトリだけにする。 型検査のたびに node_modules のプログラムが起動するので、package-lock.json を必ずコミットし、CIでは npm ci で入れます。マッパーのパッケージと、その依存（@astrojs/ts-content-mapper なら @astrojs/astro2tsx など）の更新は、通常の依存更新と同じようにレビューします。
外部からのプルリクエストを検査するジョブでは慎重に扱う。 協力会社や外部の人のプルリクエストが package.json を書き換えた場合、そのブランチで --runExternalCode を実行すると、書き換えた依存のコードが動きます。シークレットを渡さないジョブで実行する、package.json が変わったプルリクエストは人が確認してから動かす、などの分け方を決めておきます。
エディタの既定を、チームで把握しておく。 VS Code拡張の既定は有効です。ワークスペースを「信頼する」を押した時点で、そのリポジトリの node_modules のマッパーが動く前提で扱います。取引先から受け取ったリポジトリを開くときは、信頼の確認を安易に通さないようにします。
ベータの間は、本番のビルドの判定に使わない。 7.1は正式版ではなく、上で見たとおり、マッパーの解決の仕方も変わり続けています。当面は、今の型検査（TypeScript 6と astro check など）を残したまま、別のジョブで7.1ベータの結果を比べる、という並行の運用が無難です。型検査の道具を置き換えるときの比べ方は、Bunのbun checkとtscを並べて試した記事も参考になります。Astroの最近の修正は、Astro 7.4.5の環境変数の不具合の記事で扱いました。
確認した範囲
2026年11月9日に、npmの
typescript（7.1.0-betaの公開日・タグ・同梱のスキーマ・実行ファイル内の文言）と@astrojs/ts-content-mapper0.2.0のパッケージ（README・package.json）、microsoft/TypeScriptリポジトリ（f797316、2026年11月6日時点）のセキュリティ方針の文書・オプション定義・VS Code拡張の設定と、関連するコミットを確認しました（資料調査）。公開前の2026年11月11日に、TypeScriptの公式ブログの7.1ベータの告知、npmのタグ（ベータより新しい版がないこと）、7.1.0-betaのスキーマ、mainのセキュリティ方針の文書とVS Code拡張の設定、ベータの元になったコミットと#64837の関係を確かめ直しました。Astroのastro checkの挙動は、npmのastro 7.4.7と7.4.10のソースで確認したもので、実行はしていません。--runExternalCodeを付けた型検査は、ドラフトを書いた環境の権限設定で外部パッケージのコードの実行を見送ったため、行っていません。
Astroで作ったサイトの保守や、TypeScriptの版の上げ方は、HP制作・リニューアル相談からご相談ください。サイトの構成やCIの作りによって進め方が変わるため、個別にご案内します。
参考資料
- Announcing TypeScript 7.1 Beta（TypeScript公式ブログ）
- typescript（npm）
- @astrojs/ts-content-mapper（npm）
- withastro/astro — packages/language-tools/ts-content-mapper
- microsoft/typescript-go — Content mappers（#4712）
- microsoft/TypeScript — .github/skills/security-report-check/SKILL.md
- microsoft/TypeScript — packages/vscode-typescript/package.json
- microsoft/TypeScript — commit 28534d7（#64837）
- microsoft/TypeScript — commit ce8b744（#65105）
