Microsoftから提供されるデモテナント（Contoso）でAzureのAIエージェントを試していると、サブスクリプション作成が「無料試用版」「従量課金」に誘導され、個人の支払い情報を求められることがあります。本記事では、なぜそうなるのか、会社負担で使うための現実的な手順を整理します。
結論：Azureポータルは「デモテナントだから会社課金」という判定をしない
最初に押さえておきたいのは、AzureポータルはContosoのようなデモテナントを特別扱いしないという点です。Microsoft Entra ID（旧Azure Active Directory）上の「テナント」と、課金の単位である「サブスクリプション」は別物で、ポータルの「新しいサブスクリプション」作成は基本的に“作成できる課金スコープ（請求先）を持っているか”で分岐します。
そのため、あなたのアカウントがContosoテナントにサインインしていても、
- そのテナントに紐づく組織向けの課金アカウントがない
- または課金アカウントはあるが、あなたに「サブスクリプション作成」権限がない
といった状態だと、ポータルは一般公開されているオファー（無料試用版／従量課金／学生向けなど）へ誘導し、個人の支払い情報を求める流れになりやすいです。これは「あなたが間違っている」のではなく、ポータルの設計上の自然な挙動です。
まず確認したいポイント：ディレクトリ、サブスクリプション、権限
「作れない」問題は、原因が複数あります。手戻りを減らすために、最初に次の3点を確認してください。
| 確認ポイント | よくある状態 | 何が起きるか | 次の一手 |
|---|---|---|---|
| 今いるディレクトリ（テナント）がContosoか | 別テナントに切り替わっている | 期待したサブスクやリソースが見えない | ポータル右上のディレクトリ切替でContosoに戻す |
| Contosoに既存サブスクリプションがあるか | サブスクが0件 | リソース作成ができず、作成画面が公開オファーへ | チームの共通サブスク／スポンサーシップ有無を確認 |
| サブスクリプション作成／割り当て権限があるか | 閲覧はできるが作れない | サブスク作成メニューが出ても最後で詰まる | 課金管理者に「作成」または「割り当て」を依頼 |
特にデモテナントは、検証用途でアカウントが複数テナントを行き来しがちです。ポータルの「ディレクトリ + サブスクリプション」フィルターで、Contosoのディレクトリにいること、そして対象のサブスクリプションが選択されていることを先に整えると、判断が早くなります。
なぜ個人課金のページに飛ぶのか：仕組みを短く理解する
Azureのサブスクリプションは、基本的に「請求の親（課金アカウント／契約）」の配下に作られます。組織（会社）で使う場合は、会社が契約している課金アカウント（例：EA、Microsoft Customer Agreement、CSPなど）の中でサブスクリプションを払い出し、必要なメンバーに権限を割り当てます。
ところがContosoのようなデモテナントは、ディレクトリとしては用意されていても、課金の親がまだ紐づいていない、あるいは紐づいていてもあなたが作成できないことがあります。この状態でポータルから「新しいサブスクリプション」を押すと、ポータルは「では新規に契約（=公開オファー）を作ってください」という導線を出します。結果として、個人の支払い情報が必要になります。
つまり、疑問の核心はここです。
- 「デモテナントだからMicrosoft負担で自動的に課金される」わけではない
- 「会社負担で使いたい」なら、会社側の課金枠の中でサブスクを発行してもらう必要がある
「誰がサブスクリプションを作れるのか」を先に整理する
サブスクリプション作成は、ほとんどの組織で“自由作成”にしていません。理由はシンプルで、サブスク＝請求の単位なので、無秩序に増えるとコスト管理が破綻するからです。現場の感覚としては、次のどれかになります。
- 課金管理者が作成し、開発者にRBACを割り当てる（多くの企業でこの形）
- 特定ロール（Subscription Creator等）を持つ人だけが作成できる
- CSP/パートナー経由で、パートナーが作成して払い出す
契約形態によって呼び方は違いますが、重要なのは「あなたが今、作成権限を持っていないなら、ポータルが公開オファーへ誘導するのは自然」という点です。
| 契約・購入のパターン | サブスク作成の主担当 | 現場での動き方 |
|---|---|---|
| 企業契約（例：EA / MCA 等） | 課金管理者（契約管理者） | 管理者に作成依頼 → 付与されたサブスクで開発 |
| CSP（クラウドソリューションプロバイダー） | パートナー／販売代理店 | 担当営業・パートナーに依頼して発行してもらう |
| 個人購入（従量課金・無料試用版） | 本人 | 会社業務では原則避け、組織枠に切り替える |
最優先の選択肢：チーム／部門が既に持っているサブスクリプションを使う
新規作成に進む前に、現場で一番早いのは既存の組織向けサブスクリプションに参加させてもらうことです。多くのチームは、次のような形で既にサブスクリプションを持っています。
- 部署のコストセンターに紐づいた共通サブスクリプション
- 検証・研究向けのスポンサーシップ（クレジット枠）
- プロジェクト単位で発行されたサブスクリプション
「自分で作る」よりも「既存に入る」ほうが、ガバナンス（命名規則、タグ、予算、権限設計）が整っていることが多く、あとから監査・経費精算で困りにくいです。
依頼するときに伝えるとスムーズな情報
サブスクリプション管理者やチームのリードに依頼する際は、次の情報をまとめて渡すと手戻りが減ります。
| 項目 | 例 | 目的 |
|---|---|---|
| 利用するテナント | Contoso（デモテナント） | 誤って別テナントに割り当てないため |
| 用途 | AIエージェント開発（検証） | Dev/Test制約の可否判断に使う |
| 必要な権限レベル | 最初はContributor、必要に応じてOwner | 最小権限で開始する |
| 想定期間と予算感 | 2週間、上限○○円相当 | 予算（Budget）設定や承認の材料にする |
依頼文の例（そのまま貼れるテンプレ）
口頭で伝えるより、次のように“必要情報が揃った依頼”にすると、管理者側の対応が早くなります。
件名例：Contosoデモテナント向け Azureサブスクリプション（組織課金）払い出し依頼
本文例：
Contoso（デモテナント）でAIエージェント開発の検証を行いたく、組織課金のAzureサブスクリプションを利用したいです。既存の共通サブスクがあれば参加、なければ新規払い出しをご検討ください。
・利用テナント：Contoso
・用途：AIエージェント検証（dev/test）
・期間：○/○〜○/○（予定）
・上限予算：月○○相当（Budget設定可能）
・希望権限：Contributor（必要に応じて一部Owner）
以上、よろしくお願いします。
Microsoft社員・社内環境での王道：Internal Subscription（社内サブスクリプション）を申請する
質問の前提が「Microsoftから付与されたデモテナント（Contoso）」である場合、社員向けに会社へ直接課金される内部用サブスクリプションを利用できるケースがあります。一般的には、社内のEmployee向けポータル（EPPなど）から、内部サブスクリプションの利用条件や申請手続きを確認します。
重要なのは、ここでのゴールが「ポータルで公開オファーを契約する」ではなく、
- 社内の課金枠（コストセンター）に紐づいたサブスクリプションを払い出す
- そのサブスクリプションをContosoテナント（ディレクトリ）に関連付けて使う
という流れに切り替えることです。名前が「Microsoft internal subscription」であっても、部署によって申請窓口・承認フロー・配賦単位が違うことがあります。社内ガイドに沿って、自分が所属する組織のルールで申請してください。
内部サブスクリプション申請で起きがちな落とし穴
- テナントを間違える：申請時に「どのディレクトリ（テナント）で使うか」を選ぶ場面がある場合、Contosoを選び忘れると、サブスクは別テナントにぶら下がります。
- 権限の想定が強すぎる：いきなりOwnerが付かず、まずはContributor付与で始まる運用もあります。必要な操作（RBAC付与、ポリシー設定）がある場合は、どの権限が必要かを先に整理するとスムーズです。
- 利用目的が曖昧：「AI開発」だけだと審査で止まることがあります。どのサービス（例：Azure AI関連、ストレージ、コンテナ等）を使うのか、期間と上限、データ取り扱いを簡潔に書くと通りやすいです。
開発・検証用途ならDev/Testオファーも現実的
社内で用意されている選択肢として、開発・テスト用途のDev/Test系サブスクリプションが提供されている場合があります。これは「本番利用はしない（または制限される）」代わりに、料金体系や利用ルールが通常の従量課金と異なることがある枠です。
Dev/Testの有無や条件は組織によって異なるため、社内のSharePointやガイドラインで「Azure Dev/Test subscription guidance」などのキーワードで探すと見つかることがあります。
| 選択肢 | 向いているケース | メリット | 注意点 |
|---|---|---|---|
| 既存の共通サブスクリプション | チームで継続的に検証・開発する | ガバナンスが整っている／立ち上げが速い | リソース競合や権限範囲の調整が必要 |
| スポンサーシップ（クレジット枠） | 短期の検証やPoC | 上限が明確で、予算管理しやすい | 期限・対象サービスに制約がある場合 |
| Dev/Testサブスクリプション | 非本番の開発・テストが中心 | 開発用途に最適化されることがある | 本番相当の運用は不可／制限がある場合 |
| 公開オファー（個人の従量課金・無料試用版） | どうしても緊急で個人検証したい | 今すぐ開始できる | 会社業務では原則避ける（精算・監査・権限管理で破綻しやすい） |
「個人のクレカで一旦作って後で移す」はおすすめしない
現場では「とりあえず個人で従量課金を作って、あとで会社の課金に移せばいいのでは？」という発想が出がちです。しかし、この方法は次の理由でおすすめできません。
- 移行できる保証がない：契約形態や権限、組織のポリシー次第で、後から課金スコープを変えられない／手続きが重いことがあります。
- 監査・コンプラの地雷になりやすい：個人契約の支払い情報に業務リソースがぶら下がると、退職・異動・カード変更で運用が崩れます。
- 権限設計が弱くなる：個人起点だと「誰がOwnerか」「誰が請求を管理するか」が曖昧になり、コスト事故が起きやすいです。
AIエージェント開発は、検証フェーズでも意外とコストが増えます（学習／推論、ログ、ストレージ、ネットワークなど）。だからこそ、最初から組織負担の枠で、予算と責任が明確なサブスクリプションを使うのが安全です。
実務で迷わない推奨フロー
「今すぐ作りたい」気持ちがあるほど、順序を間違えると後で詰みます。現実的で安全な流れは次の通りです。
- チーム／部門に既存サブスクリプション（共通／スポンサーシップ）がないか確認する
最短で環境が用意でき、後からの説明も簡単です。 - 既存がなければ、社内ポータル（EPP等）からInternal SubscriptionまたはDev/Test枠を申請する
「Contosoテナントで利用したい」ことを明記し、用途・期間・上限を添えます。 - 発行されたら、最小権限で開始し、予算とタグを最初に整備する
最初からBudget（予算）とアラートを入れると、検証の自由度を保ちつつ事故を防げます。
開始前に入れておきたい最低限のガバナンス
サブスクリプションが手に入った瞬間にリソースを作り始めると、あとから整理が大変です。AIエージェント開発のように実験が増えやすい場合は、最低限ここだけ先に決めましょう。
| 項目 | おすすめ | 理由 |
|---|---|---|
| リソースグループの分け方 | プロジェクト単位 + 環境（dev/test） | 削除・棚卸しが簡単になる |
| タグ | costCenter / project / owner / environment | 請求配賦と責任所在が明確になる |
| 予算（Budget） | 月次上限 + 50%/80%/100%アラート | 気付いたら高額、を防ぐ |
| 権限（RBAC） | 原則Contributor、必要時に一部のみOwner | 誤操作・権限濫用のリスクを抑える |
ContosoデモテナントでAIエージェントを作るときの具体的な注意点
AIエージェント開発は、リソースが増えやすく、コストとセキュリティの両面で「後から効く」落とし穴があります。デモテナントであっても、次の観点は現場で効きます。
コスト：ログとストレージが静かに増える
モデル推論そのものだけでなく、アプリ側のログ（Application Insights等）、会話履歴、ベクトル検索用のインデックス、検証データの保管でストレージが積み上がることがあります。検証の段階でこそ、
- リソースの命名に「期限」や「用途」を入れる
- 一定期間で自動削除する運用（棚卸し日を決める）
- 予算アラートを必ず有効化する
を徹底すると、チーム全体が楽になります。
セキュリティ：キーや接続文字列をコードに埋めない
デモテナントだからといって、ソースコードにキーを直書きする運用は避けるべきです。後から本番環境へ流用するときに負債になります。最低限、
- シークレットはKey Vault等に集約する
- 権限はManaged Identity（可能なら）で渡す
- 共有するサンプルはキーをマスクする
といった「移植可能な作法」に寄せると、社内共有もしやすくなります。
運用：サブスクリプションを分けると片付けが速い
可能であれば、AIエージェント検証用のサブスクリプションを別にし、他の開発と混ぜないのが理想です。サブスクリプション単位で予算・権限・ポリシーを分けられるため、実験が増えても「消す」「閉じる」「引き継ぐ」がしやすくなります。
よくある質問
Azureポータル以外（CLIやAPI）でサブスクリプションを作れますか？
サブスクリプション作成は、裏側では課金スコープに対する権限が必要です。CLIやAPIが入口になったとしても、必要な権限がない限り作れない点は変わりません。まずは「組織の課金枠」と「作成権限」を用意するのが近道です。
Contosoテナントにサブスクリプションを紐づけるには何が必要ですか？
必要なのは、Contoso（ディレクトリ）上で利用できる形でサブスクリプションが発行されることです。多くの組織では、課金管理者がサブスクリプションを作成し、指定ユーザーにOwner/Contributorを割り当てます。申請時にテナント指定ができる場合は、Contosoを指定します。
「公開オファーに飛ばされる」のを止める設定はありますか？
テナント側の設定で一律に“公開オファー画面を出さない”というより、そもそも公開オファーに行かなくて済む状態（=組織課金のサブスクがあり、あなたに権限がある）を作るのが現実的です。つまり、解決策は設定変更ではなく、課金と権限の整備です。
まとめ：Contosoでのサブスクリプション作成は「課金枠の用意」と「権限」がすべて
Contosoデモテナントでサブスクリプション作成が個人課金の導線に流れるのは、Azureポータルがデモテナントを特別扱いしないためです。会社負担で安全に進めるなら、
- 既存の組織向けサブスクリプション（共通／スポンサーシップ）を確認する
- 必要なら社内ポータル（EPP等）からInternal SubscriptionやDev/Test枠を申請する
- 発行後すぐに予算・タグ・最小権限を整備して、AI検証を加速する
この順番が、最短かつ事故が少ない進め方です。
コメント