Azure OpenAIの設定で決める項目一覧｜閉じた環境で動かす

「置き場所は自社の契約の中に寄せると決まりました。ただ、そこから先の設定を誰が決めるのかで止まっています」「管理の画面を開いたら項目が多すぎて、どれを触ると何が変わるのかが分かりません」——Azure OpenAI で自社向けの基盤を立てた直後の会社から、ほとんど同じ形で届く言葉です。これは操作に詳しい人が社内にいないという問題ではありません。決めるべき項目の半分が業務側の判断であり、情報システム部門だけでは埋められないからです。基盤を立てた時点では何も決まっておらず、既定の値がそのまま効いた状態で動き始めるため、決める項目を先に並べておかないと、後から全部を貼り直す作業に変わります。この記事では、置き場所と契約の形を選び終えた後に何を決めるのかを、項目ごとに理由から整理します。

基盤を立てた時点では、まだ何も決まっていない

自社の契約の中に基盤を立てる作業そのものは、長くかかりません。情報システム部門が半日で終えてしまうこともあります。問題はその後で、立てた直後の状態は「まだ決めていない」ではなく「用意されていた既定の値を選んだ」という状態になっている点です。どこに記録が残るのか、誰が新しいモデルを載せられるのか、使いすぎた月に何が起きるのか。どれも既定の値で動き始めていて、説明できる人がいないまま数か月が過ぎます。

決める項目が情報システム部門の手に余るのは、判断の材料が別の部門にあるからです。やり取りを何日残すかは法務と人事、使える量の上限は予算の責任者、止める操作を誰が持つかは業務の責任者が材料を持っています。設定の画面を開いた人が全部を決めようとすると、必ずどこかに空欄が残ります。そして空欄は、誰かが決めるのを待ってはくれません。既定の値で埋まった状態のまま動き続けます。

この記事は、置き場所を自社の契約の中に寄せると決めた後、そして法人向けの契約の形を比べ終えた後から始めます。どちらも別の論点なのでここでは扱いません。また、画面のどこを押すかという手順も書きません。半年で変わるうえに、変わった後に社内へ残るのは手順ではなく「なぜその値にしたのか」だけだからです。以下では、決める項目とその理由を順に見ていきます。

設定で決めることは、6つに集まる

細かい項目は数十ありますが、人の判断が要るものは6つに集まります。環境をどの単位で切るか、身元と権限をどこで揃えるか、入力と出力がどこに残る設定か、使える量をどう割り当てるか、モデルの世代交代にどう追随するか、止める操作を誰が持つか。残りは、この6つが決まれば自動的に決まる項目か、既定のままで当面は困らない項目です。全部を同じ重さで議論すると、いちばん効く6つに時間を割けなくなります。

順番にも理由があります。環境の切り方を先に決めないと、権限の貼り方も、割り当て量の分け方も、後から全部やり直しになります。切り方は、費用を請求する単位と、権限を分ける単位と、記録をまとめる単位を同時に決めてしまうためです。逆に、止める操作を誰が持つかは最後でも間に合います。走り出してからでも決められる項目と、走り出す前にしか決められない項目を分けておくと、議論の順番で迷いません。

6つのうち2つは、発注や契約の前に決めておく必要があります。入力と出力がどこに残るかと、処理がどの地理的範囲で行われるかです。残る場所と処理の場所は、載せ方の型を選んだ時点で決まってしまい、後から型だけを差し替えるのは作り直しに近い作業になります。この2つについては、法務や情報セキュリティの担当と合意を取る時間を、日程の中に先に確保してください。

項目1：環境をどの単位で切るか

入れ物は3階建てになっています。いちばん外がAzureの契約の単位、その中に基盤の入れ物が置かれ、入れ物の中にモデルを載せる口を作ります。マイクロソフトが公開している上限の一覧（2026年8月20日付）では、1つの契約の単位あたり Azure OpenAI の入れ物は30まで、1つの入れ物あたりの標準の載せ口は32までと数が決められています。数そのもので困る会社は多くありませんが、切り方を細かくしすぎると早い段階で頭を打ちます。

切る理由は3つしかありません。費用を部門ごとに請求したい、権限を部門ごとに分けたい、記録を部門ごとに分けて監査に出したい。この3つのどれにも当てはまらないのに切ると、管理する対象が増えるだけです。部門ごとに切れば、設定の確認も、鍵の棚卸しも、監視に関する申請も、部門の数だけ繰り返すことになります。年に一度の確認作業が3部門で3倍になる、という形で効いてきます。

実務としての勧めは、最初は全社で1つにまとめ、請求を分ける必要が出た部門だけを後から切り出すという順です。逆向き、つまり最初に部門ごとに切ってから統合するほうは、載せ口の作り直しと権限の貼り直しが同時に起きるため、手間が数倍になります。最初の半年はどの部門がどれだけ使うかの見当も付かないのが普通なので、見当が付いてから切るほうが確実です。

切り方で決まるのは、割り当て量の取り合いの形

環境を切る話には、費用や権限とは別の副作用があります。使える量の取り合いです。同じ文書には、2026年5月7日より後、割り当ての管理が入れ物ごと・地域ごとではなく契約の単位で行われるようになったと記されています。ひとつの契約の単位の中にある入れ物と地域は、同じ枠を分け合う形になります。この変更は、部門を分けたつもりの会社に静かに効いてきます。

全世界に振り分ける型では、同じモデルの同じ版の載せ口が、契約の単位の中の全地域でひとつの枠を共有します。データゾーンの型では、その範囲ごとにひとつの枠です。つまり、入れ物を部門ごとに分けても、使える量まで分かれるとは限りません。片方の部門が夜間の一括処理を流した時間帯に、もう片方の部門の画面だけが遅くなる、という形で影響が出ます。原因が自部門の外にあるので、調べても分かりません。

ここから導かれる結論は単純です。環境を切る理由に「互いに影響しないようにするため」を入れない。影響を本当に切り分けたいなら、切るべきなのは入れ物ではなく契約の単位のほうか、あるいは容量を確保する型に載せ替えるかの判断になります。費用と権限のために切る、量のために切らない。この線を最初に引いておくと、後から社内へ説明するときに話が短く済みます。

項目2：身元と権限を、どこで揃えるか

使う側の身元は、社内の身元の台帳（Entra）に寄せます。理由は2つです。退職や異動のときに1か所を止めれば全部が止まること、そして誰が何を出したかの記録が人に結びつくこと。鍵の文字列を配る方式は、最初の試作では速いのですが、配った先が分からなくなった瞬間に止める手立てがなくなります。記録も残りますが、残るのは鍵の識別子であって人ではありません。

権限は3層に分けます。基盤の入れ物そのものを作れる人、モデルの載せ口を作れる人、載っているものを使うだけの人。いちばん絞るのは真ん中です。載せ口を作れる人は、費用の発生と、どのモデルが業務に入るかを同時に決められるからで、ここを開けたままにすると、誰も把握していないモデルが業務の中に入り込みます。使うだけの人の権限は広く配って構いませんが、真ん中だけは名前で数えられる人数に収めてください。

落とし穴は、試作の時期に配った鍵が本番でも生き続けることです。試作は情報システム部門以外の人が動かしていることも多く、その人の手元に文字列が残ります。鍵を発行したら、その場で用途と有効期限と失効の予定日を台帳に書く。発行の記録がないと、半年後に「これは誰の鍵か」を誰も答えられません。台帳は表計算で十分です。発行した人、用途、失効の予定日の3列だけは外さないでください。

項目3：入力と出力が、どこに残る設定になっているか

社内の説明でいちばん時間を取られるのがここです。マイクロソフトが公開している取り扱いの文書（2026年5月18日付・2026年6月5日更新）には、入力と出力、埋め込み、学習用のデータについて、他の顧客には提供されない、モデルの提供元にも提供されない、提供元がモデルやサービスを良くするために使うことはない、許可や指示なしに基盤となるモデルの学習に使われることはないと明記されています。同じ文書は、モデルは状態を持たず、入力も出力もモデルの中には保存されないとも述べています。

ただし「モデルの中に残らない」ことと「どこにも残らない」ことは別です。同じ文書は、機能によっては保管が発生すると書いています。会話の履歴を持ち越す機能、やり取りの組を保存する機能、追加学習のために上げたファイル、一括処理に渡した入力。これらは保管され、保管される場所は自社の契約の入れ物の中で、入れ物と同じ地理的範囲です。既定で暗号化され、自社で管理する鍵を選ぶこともでき、いつでも消せる、とされています。

だから確かめるのは設定の画面ではなく、その業務がどの機能を使っているのかです。1回きりの問い合わせで終わる業務なら保管は起きません。前の発言を踏まえて続ける形の業務は履歴を持ち越すので保管が起きます。試験のときに使った「やり取りの組を保存する」機能を切り忘れたまま本番に入るのが、いちばん多い取りこぼしです。業務の一覧に、この機能を使うかどうかの欄を1つ足してください。

「学習に使われない」と「どこにも残らない」は別の話

もうひとつ説明でつまずくのが、不正利用の監視です。同じ文書によれば、規約に反する使い方の兆候を見つける仕組みが働いており、兆候が出たときに入力と出力の一部が確認の対象として抜き出されます。確認は既定では自動で行われ、必要に応じて人が見ます。人が見られるのは、すでに印が付いたものか、悪用の疑いのある使い方の一部であるものに限られると書かれており、確認する社員は要求ごとの識別子を使った点の照会、専用の作業端末、その都度の承認という3つを経ることになっています。欧州経済領域に置いた場合は、確認する社員も同じ領域内にいる、という記載もあります。

この監視は申請で変えられます。承認された場合、保管と人による確認は行われません。ただし自動の確認は残り、重い違反や繰り返しの兆候が出れば利用の制限を受けることがある、と同じ文書に書かれています。承認されたかどうかは、入れ物の情報の中に記録に関する項目が現れるかどうかで確かめられます。この項目は記録を取っていないときにだけ現れると明記されているので、見当たらない場合は申請が通っていない、と読みます。社内の説明資料には、この確かめ方まで書いておくと、監査のたびに調べ直さずに済みます。

処理の場所も同じ枠で整理できます。地域を固定する型なら、指定した地理的範囲の中で処理されます。全世界に振り分ける型では、そのモデルが置かれているどの地理的範囲でも処理されうると明記されています。データゾーンの型は、その範囲の中です。どの型でも、保管されるものは指定した地理的範囲に残るとされている点が要点で、社内向けには「処理の場所」と「保管の場所」を分けた2行で書くと、話が通りやすくなります。

項目4：使える量の割り当てと、足りなくなったときの動き

使える量は、1分あたりに通せるトークンの量として割り当てられます。1分あたりの要求の回数は、そこから連動して決まります。公開されている一覧では、版によって1,000トークンあたり10回のものと1回のものがあり、同じ製品でも版が違えば通せる回数が変わります（2026年8月20日付）。上限を超えると、要求が多すぎるという応答が返ります。同じ文書には、トークンの使用量が枠の下に見えていてもこの応答が返ることがある、とも書かれています。

2026年には階層の仕組みが入りました。無料の階層と1から6の階層があり、使用量が増えると自動で上の階層に移ります。移る条件には、使用量の傾向に加えて、包括的な契約の有無と支払いの履歴も含まれると書かれています。自動で上げない設定に変えることもできます。ここで押さえておきたいのは、同じ文書が割り当て量を請求の管理に使うのは推奨する方法ではないとはっきり述べていることです。

つまり、使える量の割り当ては業務を守る安全装置であって、費用の上限ではありません。費用の上限は費用の管理の側で持ち、割り当ては業務が止まらない範囲で余裕を持って取る。この2つを混ぜると、月末に予算を守るつもりで量を絞り、結果として現場の業務が止まる、という事故が起きます。どちらの担当が何を握るのかを、設定に入る前に紙の上で分けてください。

割り当てが足りなくなった日に、何を選ぶか

上限に当たったときの選択肢は、実務上は限られています。同じ文書では、上限に当たった場合の対処として、割り当ての追加を申請する、容量を確保する型に移す、使用の状況を定期的に見る、という3つが挙げられています。注意したいのは申請の扱いで、申請は受け付けた順に処理され、いま持っている割り当てを実際に使っている顧客が優先される、条件に合わない申請は却下されることがある、と明記されている点です。使わない枠を先に押さえておく戦術は通りません。

工程2の「絞る」を当日に決めようとすると、必ずもめます。どの業務を先に絞るかは、上限に当たる前に紙に書いておく。書く内容は3行で足ります。最後まで止めない業務、待たせてよい業務、当日なら止めてよい業務。この3行があるだけで、当日の判断が担当者1人でできるようになります。判断を会議に預ける形にすると、上限に当たっている時間がそのまま延びます。

項目5：モデルの世代交代に、どう追随するか

この項目を空欄のままにしている会社が最も多く、そして最も高く付きます。マイクロソフトが公開している世代交代の方針（2026年7月24日付）では、一般提供になったモデルの版には、公開の時点で18か月後の終了日が設定されると書かれています。後から告知が出るのではなく、使い始める時点ですでに期限が決まっている形です。終了日の延長を認める仕組みはない、ともはっきり書かれています。

途中には段階があります。公開から12か月の時点で、新しく使い始める顧客には提供されなくなります。すでに使っている顧客はそのまま使えます。この「すでに使っている」の判定は契約の単位で行われ、同じテナントの中に新しい契約の単位を作っても、その資格は引き継がれないと明記されています。そして18か月の時点で完全に終了し、それ以降の要求は取り出せないという応答が返ります。

告知の形も決まっています。一般提供のモデルの終了は少なくとも60日前、試験提供のモデルの終了は少なくとも30日前に通知され、通知は有効な載せ口を持つ契約の所有者あてに届きます。稼働状況の通知の画面でも確認できます。宛先が契約の所有者になっている点が落とし穴で、所有者が退職者や共有のアドレスのままだと、誰も読まないまま期限が来ます。所有者の連絡先を確かめる作業は10分で終わります。設定の見直しの最初にやってください。

版の更新の仕方は3通り。選ばないと既定のまま動く

終了日が来たときの動きは、載せ方の型で違います。同じ文書では、地域を固定する型・全世界に振り分ける型・データゾーンの型については、終了のときに自動で新しい版へ引き上げられると書かれています。引き上げは地域ごとに順に行われます。一方で、容量を確保する型は自動では引き上げられず、利用する側が手で移す必要があると重要な注意として明記されています。この違いを知らないまま容量を確保する型に載せていると、期限の日に止まります。

自動で引き上がる型でも、動き方は設定で選べます。同じ文書の質問欄には3つの値が示されています。新しい既定の版が出た時点で上げる、いまの版の期限が来たときだけ上げる、自動では上げない。最後の値を選ぶと、期限が来た時点でその載せ口は動かなくなります。選ばなければ既定の動きがそのまま効きます。どれが正しいかは業務によって変わるので、業務ごとに選ぶ形にします。

選ぶ値	動き方	向く業務	決める前に確かめること
新しい既定の版が出たら上げる	提供側が既定を切り替えた時点で追随する	人が読んで判断する業務・下書きを作る業務	出力の言い回しが変わっても後工程が壊れないか
期限が来たときだけ上げる	終了の日まで今の版のまま動く	決まった形で受け取って次の処理へ流す業務	期限の日付を業務の予定表に入れてあるか
自動では上げない	期限が来ると載せ口が動かなくなる	検証のために版を固定したい一時的な用途	期限の2か月前に移行の予定を入れてあるか

選び方の目安は、出力の形が後工程にどれだけ食い込んでいるかです。人が読んで判断する業務なら、新しい版に早く上がって構いません。決まった形で受け取って次の処理に流している業務は、期限が来るまで上げないほうが安全です。そして自動では上げない値を選んだ場合、期限の日に止まることが確定します。この値を選ぶなら、期限の2か月前に移行の予定を入れるところまでが1組だと考えてください。

項目6：止める・絞る操作を誰が持つか

最後の項目は、事故が起きたときの操作です。決めることは3つ。全部を止められる人、特定の業務だけを絞れる人、止めた後に社内へ知らせる人。この3つが同じ人である必要はありませんし、同じ人にすると、その人が休暇の週には誰も押せなくなります。役割ごとに2人以上を割り当てるのが原則です。

止める理由は、外からの攻撃だけではありません。実際に多いのは自社の中の事故です。処理が繰り返しになって同じ要求を出し続ける、試験用の処理が本番の枠を食う、業務側の不具合で想定の何十倍もの入力が流れる。止める操作は、費用の事故と品質の事故の両方に効く最後の手段で、これがないと、気づいてから週明けの会議まで手が出せないことになります。

権限を配ったら、そのうえで止めた後に何が起きるかを、実際に一度試しておく。止めた瞬間に業務側の画面はどう見えるか、代わりに何が表示されるか、再開したときに取りこぼしが出ないか。この3つを確かめないまま権限だけ配ると、いざというときに誰も押しません。押せない権限は、無いのと同じです。試すのは、業務が動いていない時間帯の30分で足ります。

実務仕様：載せ口を作る前に、値を確定させる項目

ここまでの6項目を、埋める紙の形にまとめます。名前は自社の言葉に置き換えて構いませんが、「決める人」の列だけは必ず入れてください。項目そのものは誰でも書けますが、決める人の欄が空いていると、その項目は永遠に既定のままになります。

決める項目	決める人	決めないと何が起きるか
環境を切る単位（全社1つか部門ごとか）	情報システム部門と経理	後から切り直すときに、載せ口と権限を同時に貼り直すことになる
身元をどの台帳に寄せるか	情報システム部門	鍵の文字列が配られ、退職時に止める手立てがなくなる
載せ口を作れる人の一覧	情報システム部門の責任者	把握されていないモデルが業務に入り、費用も把握できなくなる
使う機能（履歴を持ち越すか、組を保存するか）	業務の責任者と法務	試験のときの設定のまま本番に入り、想定外の保管が起きる
載せ方の型（処理と保管がどの地理的範囲か）	法務と情報セキュリティ	契約後に型だけを差し替えられず、作り直しに近い作業になる
監視の変更を申請するかどうか	法務	申請が必要かどうかの議論が、監査の指摘を受けてから始まる
割り当て量の目安と、費用の上限	予算の責任者と情報システム部門	上限を守るつもりで量を絞り、現場の業務が止まる
版の更新の仕方（業務ごとに3つから）	業務の責任者	既定の動きで版が上がり、後工程が静かに壊れる
終了の通知を受け取る連絡先	情報システム部門	通知が退職者あてに届き、期限の日に業務が止まる
止める権限を持つ人（2人以上）	業務の責任者	事故に気づいてから、週明けの会議まで手が出せない

見直しの周期も決めておきます。半年に一度で十分ですが、周期より大事なのは引き金のほうです。モデルの終了の通知が来たとき、部門が増えたとき、監査で指摘が出たときの3つを、周期とは別の見直しの引き金にしておくと、この紙が生き続けます。周期だけで回すと、周期の間に起きた変化に追いつけず、次の見直しのときには紙と実態が食い違っています。

AIに任せてよい工程と、人が決める工程

この設定の作業にも、AIは効きます。効くのは調べ物と下書きです。公開されている仕様の一覧から自社に関係する行を抜き出す、上限の一覧を自社の業務量と突き合わせる、設定の理由を文章に起こす、社内向けの説明の下書きを作る。このあたりは人が数日かける作業が半日で形になりますし、見落としも減ります。特に、英語で公開されている仕様を日本語の社内文書に落とす作業は相性が良い領域です。

一方で、AIに決めさせてはいけない工程がはっきりあります。残す期間、量の上限、権限を持つ人、止める条件。どれも判断の材料が社外の文書ではなく、自社の契約と人の事情の中にあるからです。仕様を要約させると、もっともらしい推奨値が返ってきますが、その値の根拠は自社のどこにもありません。根拠のない値は、監査で聞かれたときに説明できません。

• 仕様を調べさせたら、必ず出どころの文書の名前と日付を一緒に書かせ、人が原典に当たる
• 残す期間・量の上限・権限を持つ人・止める条件の4つは、AIの出力を根拠にしない
• 版の更新の仕方をどれにするかは、後工程の壊れやすさを知っている業務側の人が決める
• 監視の変更を申請するかどうかの判断は、法務が原文を読んだうえで決める
• AIに作らせた社内向けの説明文は、決めた人の名前と決めた日付を人が書き足してから配る

確かめる範囲も先に決めます。人が必ず見るのは、出どころの日付、自社の契約に固有の値、そして決めた人の名前の3つ。それ以外は記録が残っていれば後から追えます。生成AIに関する仕様は半年で変わるので、要約だけが社内に残ると、半年後には古い紙が回覧されることになります。原典の日付が書いてあれば、古くなったこと自体には気づけます。

設定でやりがちな失敗

ここまでの内容を、失敗の形で裏返しておきます。どれも、設定そのものが難しかったのではなく、決める人と理由を書かなかったために起きています。

• 試作の設定のまま本番に入る：やり取りを保存する機能が入ったまま業務が始まり、想定していなかった保管が起きる
• 部門ごとに環境を切って、影響も切れたつもりになる：割り当ての枠は契約の単位で共有されるため、他部門の一括処理で自部門の画面が遅くなる
• 割り当て量を費用の上限として使う：月末に量を絞った結果、予算は守れたが現場の業務が止まる
• モデルの終了日を誰も追っていない：通知が退職者あてに届き、期限の日に業務が止まってから気づく
• 止める権限を1人にしか配らない：その人が不在の週に事故が起き、誰も押せないまま費用だけが積み上がる
• 決めた理由を書かずに値だけ残す：半年後の見直しで、その値を変えてよいのかどうかを誰も判断できない

この中で最も高く付くのが、終了日を追っていない状態です。ほかの失敗は気づいた時点で直せますが、期限による停止だけは、当日になってから直せることが何もありません。連絡先を確かめ、いま載せているモデルの版と終了日を一覧にする。この2つだけなら、半日で終わります。

よくある質問

自社の契約の中に立てれば、入力した内容が外部の学習に使われることはないと言い切れますか

公開されている取り扱いの文書には、入力と出力、埋め込み、学習用のデータが、他の顧客にもモデルの提供元にも提供されず、提供元がモデルやサービスを良くするために使うこともなく、許可や指示なしに基盤となるモデルの学習に使われることもない、と明記されています。社内へ説明するときは、この文書の名前と日付を添えてください。ただし、学習に使われないことと、どこにも保管されないことは別です。保管は使う機能によって起きるので、業務ごとに機能を確かめる必要があります。

環境は部門ごとに分けたほうがよいですか

費用を部門ごとに請求したい、権限を分けたい、記録を分けて監査に出したい。このどれかに当てはまるときだけ分けてください。当てはまらないのに分けると、確認と棚卸しの作業が部門の数だけ増えます。そして、分けても使える量の枠は共有される場合があるので、互いの影響を切る目的では分けないでください。

モデルが終了する日は、どうやって追えばよいですか

一般提供のモデルは、使い始める時点ですでに18か月後の終了日が決まっています。終了の通知は少なくとも60日前に、有効な載せ口を持つ契約の所有者あてに届きます。まず所有者の連絡先を確かめ、次にいま載せているモデルの版と終了日を一覧にして、業務の予定表に入れてください。終了日の延長を認める仕組みはない、と文書に明記されています。

使える量が足りているかどうかは、いつ判断すればよいですか

使い始めてからの3か月は、判断の材料が揃いません。3か月たったところで、時間帯ごとの使用量と、要求が多すぎるという応答が返った回数を見ます。応答が返っていなくても、特定の時間帯に集中していれば、業務が増えた瞬間に当たります。申請は受け付け順に処理されるため、当たってから動くのでは遅い、という前提で予定を組んでください。

まとめ

Azure OpenAI を閉じた環境で動かすときに決めるのは、環境を切る単位、身元と権限、入力と出力が残る場所、使える量の割り当て、世代交代への追随、止める権限という6項目です。環境は費用と権限のために切り、量のためには切らない。学習に使われないことと保管されないことを分けて説明する。割り当ては安全装置であって費用の上限ではない。一般提供のモデルには公開から18か月という終了日が最初から付いていて、版の更新の仕方を選ばなければ既定の動きがそのまま効く。止める権限は2人以上に配り、配る前に一度試しておく。まずは、いま載せているモデルの版と終了日、そして終了の通知が届く連絡先を確かめるところから始めてみてください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。