Microsoft Edge origin trials expand Prompt API and Proofreader API testing は、Microsoft Edge上で動くオンデバイスAI系Web APIの検証範囲が広がったことを示す更新です。結論から言うと、開発者は Prompt API、Proofreader API、および Prompt API Sampling Parameters を本番に近いWebサイトで試しやすくなりました。ただし、いずれも実験的なOrigin Trialであり、正式機能として安定利用できる前提で設計すると危険です。
特に確認すべきなのは、対象ブラウザー、Origin Trialトークンの登録、オンデバイスモデルのダウンロード可否、端末要件、企業ポリシー、フォールバック設計です。Microsoft Edge 149のWeb Platform Release Notesは2026年6月4日公開の更新として、Origin Trials一覧にProofreader API、Prompt API、Prompt API sampling parametersを掲載しています。(Microsoft Learn)
Microsoft Edge origin trials expand Prompt API and Proofreader API testingで変わること
今回のポイントは、Microsoft EdgeのOrigin Trialsを通じて、Webサイトやブラウザー拡張機能からEdge内蔵のAIモデルを試せる範囲が整理・拡張されたことです。
Origin Trialは、実験的なWeb APIを期間限定で実際のWebサイト上で試す仕組みです。サイト運営者が対象ドメインを登録し、発行されたトークンをページやHTTPレスポンスに追加すると、そのサイトを訪問したMicrosoft Edgeユーザーの環境で対象APIが有効になります。ユーザー側で edge://flags を手動変更する必要がない点が、単なるローカル検証との大きな違いです。(Microsoft Learn)
今回確認すべきAPIは次の3つです。
| API | できること | 主な確認ポイント |
|---|---|---|
| Prompt API | Webサイトや拡張機能のJavaScriptから、Edge内蔵の小規模言語モデルにプロンプトを送る | APIの有効性、端末要件、モデルダウンロード、出力の不確実性 |
| Proofreader API | テキストの文法、スペル、句読点の誤りを修正する | 校正対象言語、リアルタイム処理の負荷、UI上の提案表示 |
| Prompt API Sampling Parameters | topK や temperature など、Prompt APIセッション単位の挙動調整を試す | 本体のPrompt APIとは別トライアルとして扱う必要がある |
Prompt APIのOrigin Trialページでは、テキスト、画像、音声入力を使ったAIモデルとのやり取りや、JSON Schemaなどで応答形式を制約する構造化出力が説明されています。試験期限は同ページ上で2026年6月16日とされています。(Microsoft Developer) 一方、Prompt API Sampling Parametersの試験期限は2026年10月6日で、topK や temperature のようなパラメーター調整をセッション単位で試すための別枠です。(Microsoft Developer)
Proofreader APIは、入力テキストに対して校正候補を返すJavaScript APIです。公式のOrigin Trialページでは、チャット、メール下書き、ノート、文書作成画面などでのリアルタイム校正が利用例として挙げられています。なお、同ページ上のTrial Expiration Dateは2026年5月19日と表示されていますが、Microsoft Edge 149の2026年6月4日更新のOrigin Trials一覧にはProofreader APIが掲載されています。導入前には、必ずOrigin Trialsポータル上の登録可否と期限を再確認してください。(Microsoft Developer)
Prompt APIは「自由度の高いAI機能」をWebに組み込むためのAPI
Prompt APIは、Webアプリや拡張機能のJavaScriptから、Microsoft Edgeに内蔵された小規模言語モデルへプロンプトを送るための実験的APIです。公式ドキュメントでは、テキスト生成、テキスト分析、ユーザー入力に基づくアプリケーションロジックの作成などが用途として示されています。(Microsoft Learn)
たとえば、次のような機能をクラウドAIサービスへ毎回送信せずに実装する検証ができます。
| 活用シーン | 実装例 | 注意点 |
|---|---|---|
| 問い合わせ分類 | ユーザー入力を「請求」「技術相談」「解約」などに分類 | 誤分類時に人間へ回す導線が必要 |
| CMS支援 | 記事本文からタグ候補や要約を生成 | 公開前レビューを必須にする |
| フォーム補助 | 自由入力欄の内容を整理して確認文を作成 | 個人情報の扱いを明確にする |
| 拡張機能 | 閲覧ページの一部を要約・分析 | 対象サイトの利用規約や社内規程に注意 |
Prompt APIの強みは、クラウドAI APIと違い、入力データと出力データが同じ端末上で処理される点です。公式ドキュメントでは、クラウド利用コストがかからないこと、初回モデルダウンロード後はネットワーク遅延を避けやすいこと、入力データが端末外へ送信されずAIモデルの学習にも収集されないことが利点として説明されています。(Microsoft Learn)
ただし、オンデバイスだからといって何でも安全に扱えるわけではありません。業務データ、個人情報、医療・金融・法務関連の入力を扱う場合は、社内のデータ分類、ログ保存、画面表示、ユーザー同意の設計を先に確認してください。
Proofreader APIは校正機能に特化した実験的API
Proofreader APIは、文法、スペル、句読点の誤りを修正する用途に最適化されたAPIです。Prompt APIのように自由な指示を投げるAPIではなく、校正という特定タスクに向いた高レベルAPIと考えると分かりやすいでしょう。公式ドキュメントでは、Microsoft Edge CanaryまたはDevチャネルのバージョン142以降でDeveloper Previewとして利用できるとされています。(Microsoft Learn)
実務では、次のような画面で効果を発揮します。
| 画面 | Proofreader APIが向く理由 | 実装時の注意 |
|---|---|---|
| チャット入力欄 | 送信前に誤字や文法を確認できる | 入力中に毎回実行せず、停止後に判定する |
| メール作成画面 | 送信前チェックに組み込みやすい | すべて自動置換せず、提案として表示する |
| 問い合わせフォーム | 顧客の入力品質を上げられる | 変更後の内容をユーザーに確認させる |
| CMS・エディター | 執筆中の文章チェックに使える | 日本語など対象言語の品質を実機で確認する |
Proofreader APIは「校正済みテキストを勝手に確定する」用途よりも、「候補を提示し、ユーザーが採用する」UIに向いています。特に問い合わせ、契約、申請フォームでは、AIが意味を変えてしまうとトラブルになります。修正候補の差分表示、元文への戻し操作、送信前確認を用意しましょう。
利用前に確認すべきブラウザーと端末要件
Prompt APIとProofreader APIは、単にMicrosoft Edgeが入っていれば必ず動くわけではありません。Edgeのチャネル、バージョン、OS、ストレージ、GPU、ネットワーク状態によって利用可否が変わります。
Prompt APIは、Microsoft Edge CanaryおよびDevチャネルのバージョン138.0.3309.2以降でDeveloper Previewとして利用可能とされています。Proofreader APIは、CanaryまたはDevチャネルのバージョン142以降が対象です。(Microsoft Learn)
主な端末要件は次の通りです。
| 確認項目 | 目安 | 実務上の注意 |
|---|---|---|
| OS | Windows 10/11、macOS 13.3以降 | 古いmacOSや管理外PCは対象外になりやすい |
| ストレージ | Edgeプロファイルがあるボリュームに20GB以上の空き容量 | 空き容量が10GB未満になるとモデルが削除される場合がある |
| GPU | 5.5GB以上のVRAM | 仮想デスクトップや低スペック端末では検証が必要 |
| ネットワーク | 従量課金ではない接続 | メータード接続ではモデルがダウンロードされない |
| モデル | 初回利用時にダウンロードが必要 | UI上で「準備中」「ダウンロード中」を表示する |
これらの要件は、Prompt APIとProofreader APIのDeveloper Previewに共通して重要です。特に企業PCでは、空き容量不足、プロキシ、コンポーネント更新の制限、GPU非搭載端末が原因で「APIは見えるがモデルが使えない」状態になりやすいため、対象端末を絞って検証しましょう。(Microsoft Learn)
Origin Trialの登録手順
Origin Trialを使うには、対象ドメインを登録し、発行されたトークンをWebサイトへ追加します。検証用のサブドメインを切ると、本番全体へ影響を出さずに試せます。
| 手順 | 作業内容 | 失敗しやすいポイント |
|---|---|---|
| 1 | Microsoft Edge Origin Trialsで対象のTrialを選ぶ | 期限切れや登録停止のTrialを選んでしまう |
| 2 | Terms of Useに同意し、必要に応じてGitHubでサインインする | 担当者個人アカウントで登録し、引き継ぎ不能になる |
| 3 | https://example.com や https://beta.example.com のようにOriginを入力する | パスやクエリは登録対象にならない |
| 4 | サブドメインを含めるか決める | 不要に広い範囲へ有効化してしまう |
| 5 | 発行されたトークンをコピーする | どのドメイン・API用のトークンか記録し忘れる |
| 6 | <meta> またはHTTPヘッダーで配信する | CDNやキャッシュで一部ページにしか反映されない |
| 7 | Edgeで動作確認し、フォールバックを確認する | 対象外ブラウザーでエラーになる |
トークンは、HTMLの<head>内にmetaタグとして追加するか、HTTPレスポンスヘッダーとして返します。Microsoft公式ドキュメントでは、どちらの方法も案内されています。(Microsoft Learn)
<meta http-equiv="origin-trial" content="EXAMPLE_TOKEN">Origin-Trial: EXAMPLE_TOKENlocalhostでの検証には注意が必要です。Origin Trialトークンの検出機構はSSL対応ドメイン向けであり、localhostでは対象機能のflagを edge://flags で有効にして試す必要があります。(Microsoft Learn)
実装時はfeature detectionとavailabilityチェックを必ず入れる
Origin TrialのAPIは、使える前提でコードを書くべきではありません。対象外ブラウザー、期限切れトークン、端末要件不足、管理ポリシーによるモデルダウンロード無効化、Microsoft側の早期終了などで利用できなくなる可能性があります。
Prompt APIでは、まず LanguageModel が存在するかを確認し、そのうえで LanguageModel.availability() を確認します。
async function canUsePromptApi() {
if (!("LanguageModel" in globalThis)) {
return { ok: false, reason: "Prompt API is not available in this browser." };
}
const availability = await LanguageModel.availability();
if (availability === "available") {
return { ok: true };
}
if (availability === "downloadable" || availability === "downloading") {
return { ok: false, reason: "The model needs to be downloaded before use." };
}
return { ok: false, reason: "The model is unavailable on this device." };
}Proofreader APIも同じ考え方です。
async function canUseProofreaderApi() {
if (!("Proofreader" in globalThis)) {
return { ok: false, reason: "Proofreader API is not available in this browser." };
}
const availability = await Proofreader.availability();
if (availability === "available") {
return { ok: true };
}
if (availability === "downloadable" || availability === "downloading") {
return { ok: false, reason: "The proofreading model needs to be downloaded." };
}
return { ok: false, reason: "The proofreading model is unavailable on this device." };
}公式ドキュメントでも、APIの存在確認、モデルの利用可否確認、モデルダウンロード状況の監視が案内されています。Prompt APIでは LanguageModel.availability()、Proofreader APIでは Proofreader.availability() を使う流れです。(Microsoft Learn)
管理者が確認すべきMicrosoft Edgeの設定とポリシー
企業環境では、開発者がコードを実装しても、管理ポリシーによってオンデバイスAIモデルが使えないことがあります。特にMicrosoft Edge for Businessを管理している組織では、次の点を確認してください。
| 確認項目 | 管理者が見る場所 | 判断基準 |
|---|---|---|
| Edgeのバージョンとチャネル | Edge更新ポリシー、端末管理ツール | 検証対象APIに必要なバージョンへ到達しているか |
| AIモデルのダウンロード | GenAILocalFoundationalModelSettings | Disallowedにしていないか |
| Component Updates | Edge更新・コンポーネント更新設定 | モデル配信が止まっていないか |
| feature flagsの操作許可 | FeatureFlagOverridesControl | localhost検証でflagsを使えるか |
| 適用済みポリシー | edge://policy | 端末に想定通り反映されているか |
| 端末性能 | edge://on-device-internals | Device performance classが要件を満たすか |
GenAILocalFoundationalModelSettings は、Microsoft Edgeが基盤となる生成AIローカルモデルをダウンロードし、ローカル推論に使うかを制御するポリシーです。Disallowedに設定するとモデルはダウンロードされず、既にダウンロード済みのモデルも削除されると説明されています。(Microsoft Learn)
また、FeatureFlagOverridesControl でflagsの上書きを禁止している環境では、開発者が edge://flags からローカル検証を進められない場合があります。ポリシーを厳格にしている組織では、検証用OUや検証端末を分ける運用が現実的です。(Microsoft Learn)
Microsoft Edgeのポリシーは、GPO、レジストリ、Microsoft Intuneなどで管理できます。適用結果は edge://policy で確認できるため、開発チームと端末管理チームで同じチェックリストを共有しておくと切り分けが早くなります。(Microsoft Learn)
移行・展開時に失敗しやすいポイント
APIを本番必須機能にしない
Prompt APIもProofreader APIも実験的APIです。Origin Trialは予定日まで続くとは限らず、早期終了する可能性もあります。MicrosoftのOrigin Trialドキュメントでは、セキュリティ上の問題や、開発者ニーズに合わず大きな再設計が必要になった場合などに、試験が早期終了する可能性が説明されています。(Microsoft Learn)
そのため、次のような設計にしてください。
| 悪い設計 | 良い設計 |
|---|---|
| APIが使えないとフォーム送信できない | APIが使えない場合は通常入力で送信できる |
| 校正結果を自動反映する | 候補を表示し、ユーザーが採用する |
| Prompt APIの出力をそのままDB更新に使う | JSON検証、確認画面、人間レビューを挟む |
| トークン期限を管理していない | 更新期限をカレンダー化し、検証環境で先に確認する |
トークン期限とTrial期限を混同しない
Origin Trialトークンは既定で6週間で期限切れになり、必要に応じて更新が必要です。一方で、Trial自体にも終了予定日があります。トークンを更新できても、Trial自体が終了すれば機能は使えなくなります。Microsoftのドキュメントでは、トークン更新手順と、Origin Trialが予定終了または早期終了する可能性が説明されています。(Microsoft Learn)
運用では、少なくとも次の3つを別々に管理しましょう。
| 管理対象 | 例 | 管理方法 |
|---|---|---|
| トークン期限 | 登録後6週間単位 | 担当者と更新日を台帳化 |
| Trial終了予定日 | Prompt APIは2026年6月16日など | APIごとに公式ページを確認 |
| Edgeバージョン | 149、150など | 更新リングと検証端末で管理 |
モデルダウンロード中のUIを用意する
オンデバイスモデルは初回利用時にダウンロードされます。ダウンロード中にボタンを押せない、何も表示しない、エラー扱いにする、といったUIは避けるべきです。
実装では、次の状態を分けて表示します。
| 状態 | ユーザーへの表示例 |
|---|---|
| APIなし | 「このブラウザーではAI支援機能を利用できません」 |
| モデル未ダウンロード | 「初回準備中です。完了までお待ちください」 |
| ダウンロード中 | 「AIモデルを準備しています」 |
| 利用可能 | 「AI支援を利用できます」 |
| 利用不可 | 「この端末ではAI支援機能を利用できません」 |
「AI機能が遅い」と見えるケースの多くは、初回モデルダウンロード、低スペック端末、従量課金接続、ストレージ不足が原因です。開発段階から状態表示とログを入れておくと、問い合わせ対応が楽になります。
日本語品質は必ず実データで検証する
Proofreader APIは校正機能に特化していますが、すべての言語や業界文書で同じ品質を期待するのは危険です。特に日本語では、誤字脱字だけでなく、敬語、表記ゆれ、専門用語、固有名詞、社内用語が問題になりやすくなります。
たとえば、次のような検証データを用意しましょう。
| 検証データ | 確認すること |
|---|---|
| 問い合わせ文 | 意味を変えずに読みやすくなるか |
| メール文 | 敬語が過剰・不自然にならないか |
| 技術文書 | コマンド、製品名、API名を誤修正しないか |
| 契約・申請文 | 法的意味を変える表現に変換しないか |
| SNS風短文 | カジュアルな表現を勝手に改めすぎないか |
Proofreader APIは「日本語文章校正ツールの完成版」としてではなく、「Webアプリへ組み込める校正候補生成の実験API」として扱うのが安全です。
開発者向けの実装チェックリスト
実装前に、次のチェックリストを使ってください。
| 項目 | 確認内容 |
|---|---|
| 対象API | Prompt API、Proofreader API、Sampling Parametersのどれを使うか決めたか |
| 登録範囲 | 本番ドメインではなく検証用サブドメインから始めるか |
| トークン設置 | metaタグかHTTPヘッダーのどちらで配信するか |
| feature detection | APIがない場合に落ちない実装か |
| availability確認 | available、downloadable、downloading、unavailable を分岐しているか |
| フォールバック | APIなしでも主要操作を続けられるか |
| UI | モデル準備中、利用不可、停止、再試行を表示できるか |
| セッション破棄 | 不要になったセッションを破棄する設計か |
| 入力制御 | 個人情報や機密情報を不用意に処理しないか |
| 監視 | エラー率、利用率、端末要件不足を把握できるか |
Prompt APIの出力をプログラムで扱う場合は、自由文ではなくJSON Schemaなどで応答形式を制約する設計が有効です。公式ドキュメントでも、responseConstraint にJSON Schemaや正規表現を指定し、出力形式をより決定的にする方法が説明されています。(Microsoft Learn)
どのAPIを選ぶべきか
どちらを使うべきか迷ったら、目的で分けるのが分かりやすいです。
| やりたいこと | 選ぶAPI |
|---|---|
| 文章の誤字、文法、句読点を直したい | Proofreader API |
| ユーザー入力を分類・要約・変換したい | Prompt API |
| JSON形式でラベルや判定結果を返したい | Prompt API |
| 校正候補を入力欄に表示したい | Proofreader API |
| 生成結果のランダム性を調整して試したい | Prompt API Sampling Parameters |
| 確実な業務処理を本番で安定運用したい | 現時点ではフォールバック前提で設計 |
重要なのは、Prompt APIを万能AIエンジンとして扱わないことです。入力補助、下書き、分類候補、校正候補など、ユーザーやシステムが確認できる補助機能から始めると、失敗時の影響を抑えられます。
管理者・開発者が次にやるべきこと
まず、対象APIを1つに絞り、検証用サブドメインでOrigin Trialを登録してください。次に、Edgeの対象バージョン、端末要件、GenAILocalFoundationalModelSettings、FeatureFlagOverridesControl、モデルダウンロード可否を確認します。
開発者は、APIが使えるケースよりも、使えないケースの実装を先に固めるべきです。Origin Trialは正式機能ではなく、期限切れや仕様変更が前提の検証枠です。Prompt APIやProofreader APIを試す価値は十分にありますが、公開サービスに組み込む場合は「AI支援が使えたら便利、使えなくても業務は止まらない」設計にしておくことが、最も現実的な展開方針です。
コメント