Microsoft MAI Code of Conduct、Satya Nadellaのスーパーインテリジェンス推進を検証可能な約束へ
Satya Nadellaは、業界内で競合するスーパーインテリジェンス計画の足並みを意図的に緩め、整合性を確保する方針を歓迎するとともに、Microsoft MAI Code of Conductを発表した。MicrosoftのCEOは今後の開発について、先進AIは人類に貢献しなければならず、人間が制御を維持しなければならないという2つの条件を示した。
この立場はMicrosoftを、ますます明確になりつつある2つの陣営の間に置く。一方は、システムがより大きな自律性を得る前に、より強力な検証を求める。もう一方は、先進AIを広く配布することこそが、権力の集中に対する最善の防御だと主張する。
Nadellaは両方の立場を維持しようとしている。Microsoftはフロンティアモデルの開発を続ける一方で、人間による制御を進歩の障害ではなく、その条件として位置付けたい考えだ。この均衡はもっともらしく聞こえるが、同社が執行可能なルール、評価、リリース境界を公表して初めて意味を持つ。
この発表は、AIリーダーたちが安全システムがモデル能力に追いついているかを議論していた時期に行われた。AnthropicのCEOであるDario Amodeiは、セーフガードが追いつけるだけ開発を減速させるべきだと訴えていた。一方Metaは、広く配布されるパーソナル・スーパーインテリジェンスが個人の力を守る方法だと擁護した。
Microsoftの回答は、停止でも無制限の競争でもない。同社が何を展開しないのかを定義すべき行動規範に従いつつ、開発を続けるという約束だ。中心的な問いは、その約束がモデル開発を変えるのか、それともMicrosoftによる説明の仕方だけを変えるのかである。
Satya Nadellaが実際に発表したこと
Microsoftはスーパーインテリジェンスに関する理念をガバナンス上のコミットメントへと転換したが、運用上の詳細はなお不完全である。
Nadella’s announcementで取り上げられた9月13日の声明で、CEOは整合性の実現には意図的なペース配分が必要であり、Microsoftはそれを歓迎すると述べた。整合性とは、とりわけ能力が高まるAIシステムについて、その振る舞いを人間の目標と制限に一致させることを意味する。
Nadellaは、スーパーインテリジェンスを追求するための閾値として人間による制御を位置付けた。人類に貢献せず、人間の指揮下にとどまらないシステムであれば、構築する価値はないと彼は主張した。また、AIの恩恵は国やコミュニティを横断して広がるべきだとの考えも維持した。
この組み合わせは重要だ。制御を求める声はより厳格な制限を支持し得る一方、広範な配布を求める声はより迅速な展開を支持し得る。Microsoftは、両方の目標が同一の戦略に含まれると主張している。
付随するMicrosoft MAI Code of Conductは、同社の社内モデル群を統制することを意図している。MAIとは、OpenAIやAnthropicなどのパートナーが供給するモデルではなく、Microsoft AIが開発するモデルを指す。
MicrosoftはすでにMAIを製品ロードマップの中心に据えている。Build 2026では、初の自社開発推論モデルであるMAI-Thinking-1を中心とした7モデルから成るMAIファミリーを発表した。このラインアップには画像生成、文字起こし、音声、コーディングも含まれる。
Microsoftによれば、MAI-Thinking-1は350億のアクティブパラメータを使用し、256,000トークンのコンテキストウィンドウをサポートする。アクティブパラメータとは特定の推論時に使用されるモデル構成要素であり、コンテキストウィンドウはモデルが考慮できる入力の量を定義する。
これらの仕様は、行動規範の発表が抽象的な取り組みではないことを示している。MicrosoftはすでにMAIモデルをFoundry、GitHub Copilot、PowerPoint、OneDrive、その他広く利用される製品に組み込んでいる。
ただし、現時点で公開されている発表だけでは、コンプライアンスを評価するために必要なすべてのルールは確立されていない。完全な公開テストプロトコル、執行プロセス、展開基準、モデル別のリスク分類は、まだ示されていない。
この違いは重要である。行動規範を発表すれば期待が生まれる。測定可能な義務を公表すれば説明責任が生まれる。
現時点で確認できる進展は、NadellaがMicrosoftのスーパーインテリジェンス計画を明示的な人間制御の原則に結び付けたことだ。未解決の問題は、その原則が実際のリリース判断をどのように統制するかである。
Microsoft MAI Code of Conductが今発表される理由
この規範が登場したのは、Microsoft独自のモデルが、パートナーのポリシーだけではカバーできないリスクを生むほど重要になっているためだ。
Microsoftの初期の生成AI拡大は、OpenAIに大きく依存していた。この関係により、同社はAzure、Microsoft 365、GitHub、コンシューマー製品向けのフロンティアモデルへ迅速にアクセスできた。
現在、その立場はより複雑になっている。Microsoftは引き続きOpenAIモデルを提供する一方、プラットフォームを通じてAnthropic、Mistral、Meta、DeepSeek、xAI、その他のモデルファミリーも配布している。同時に、MAIを自社製の代替手段として構築している。
この多様性は、商業的および技術的な目標に資する。汎用フロンティアモデルの能力が特定タスクの要件を上回る場合、特化型モデルはレイテンシー、トークン使用量、運用コストを削減できる。また、Microsoftにトレーニング、展開、製品統合に対するより大きな制御も与える。
Nadellaは、企業があらゆるタスクについて単一モデルに依存するのを避けるべきだと主張してきた。7月には、組織はデータ、メモリー、ツール、エージェントハーネスを個別のモデルから切り離すべきだと述べた。
エージェントハーネスとは、指示、メモリー、ツール、フィードバックを提供する周辺ソフトウェアである。このレイヤーを分離すれば、企業はワークフロー全体を再構築せずにモデルを置き換えられる。
このモデル非依存の主張は、OpenAIやその他のフロンティア研究所に圧力をかける。Microsoftは依然として彼らの投資家、クラウドパートナー、販売チャネル、顧客であり、さらに直接の競合相手にもなりつつある。
MAIの拡大はMicrosoftの責任も変える。同社はもはや、モデルレベルの安全性を主に外部プロバイダーが担うものとして扱えない。Microsoftがモデルをトレーニングし、リリース条件を定め、自社製品に展開するなら、同社はより大きなリスクを負うことになる。
Microsoftはすでに、AIサービスを利用する顧客向けにenterprise AI codeを維持している。この文書は、入力および出力の制御、合成コンテンツの開示、継続的なテスト、フィードバックチャネル、セキュリティ対策、適切な人間による監督を求めている。
また、有害な利用、欺瞞的な操作、特定の生体情報推論、適切な人間の関与なしに行われる重大な意思決定も制限している。自律システムには、監視、介入制御、障害警告、限界に関する文書化を含めなければならない。
こうした顧客向け義務は関連性を持つが、モデル開発規範と同一ではない。サービス契約は、顧客がシステムをどのように利用できるかを定める。モデル規範はさらに、Microsoftが何をトレーニングし、テストし、保留し、変更し、あるいはリリースを見送るのかを説明すべきである。
この違いこそ、Microsoft MAI Code of Conductが単なる利用規約以上の重みを持つ理由である。モデルが顧客に届く前のMicrosoftを統制すべきであり、展開後の顧客だけを統制するものではない。
このタイミングは、同社の5年間にわたるスーパーインテリジェンス計画も反映している。Microsoftは2026年3月にAIリーダーシップを再編し、Mustafa Suleymanがフロンティアモデルと企業向けに調整されたモデル系統により直接注力できるようにした。
企業がその目標に人材、コンピューティング、製品戦略を投入すると、非公式な安全性保証では不十分になる。文書化された規範は、研究者、経営陣、製品チーム、展開パートナーの間に共通の境界を設け得る。
また、Microsoftが進歩をベンチマーク性能だけで定義しているかどうかも明らかにし得る。真剣な規範なら、能力と並んで制御可能性、悪用への耐性、監視、現実世界への影響をリリース基準として扱うだろう。
Microsoftの真の対抗相手はリリース境界のない競争だ
主な対立はMicrosoftと特定の競合他社の間ではない。Microsoftの制御に関する約束と、ますます自律的なシステムを投入しようとする競争圧力との間にある。
主要なAI研究所はいずれも迅速に動く動機を持つ。より優れたモデルは、開発者、企業契約、人材、投資、価値の高い利用データを引き付ける。安全性を向上させるための遅延であっても、企業を後れに取らせる可能性がある。
競合他社が、スーパーインテリジェンスが現在の意思決定に影響を及ぼすほど近いものとして語ると、この圧力はさらに強まる。企業はプラットフォーム転換を逃すことを恐れ、支出を増やし、実験を加速し、野心的なタイムラインを発表する。
AnthropicのDario Amodeiは、セーフガードが追いつくには時間が必要だと主張し、この緊張を際立たせた。Associated Pressが報じたAI safety warningによれば、彼は能力を増すシステムに対する検証を強化するため、開発を十分に減速させることを支持した。
同報道によれば、Amodeiは先進AIが近く、インターネット上で活動可能な多数のエージェント群を協調させる可能性があると警告した。正確な時期は予測であり、独立して確立された事実ではない。
それでも、根底にある懸念は具体的である。AIエージェントは、多段階のタスクを実行し、ツールを呼び出し、コードを書いて実行し、他のシステムと通信し、限られた監督下で作業を継続できる。
有害な回答を生成するモデルは、ある種類のリスクを生む。その回答に基づいて行動するエージェントは、別のリスクを生む。後者のシステムは、エラー、欺瞞、悪用された指示を外部での行為へと転換し得る。
Nadellaが意図的なペース配分を支持したことは、能力とガバナンスが常に同時に進展するわけではないことを認めるものだ。同時に、無期限の停止を支持することも避けている。Microsoftは依然として先進システムを開発・配布したいと考えている。
Metaは異なる重点を示している。同社のpersonal superintelligence caseは、個人を広く力づけることで、過度な制御が政府や少数の企業に集中するのを防げると主張する。
Metaも、自らを改善したり、意味のある人間の監督を超える目標を追求したりするシステムの危険性を認識している。同社が提案する答えは、有害な行動が現れた際の検証、プライバシー、権限の分散、連携を重視する。
Microsoftの立場は、両方の主張の一部と重なる。Anthropicと同様に、整合性と制御を開発のペースを調整する理由として扱う。Metaと同様に、先進AIの恩恵は広く分配されるべきだと述べる。
難しいのは、これらの原則が衝突した場合に何が起きるかを決めることだ。広範な配布はアクセスを増やせるが、能力の高いシステムを悪用できる人の数も増やしかねない。制限的な展開は悪用を減らせるが、権力をプロバイダー内部に集中させかねない。
有用な規範は、誰がこの対立を解決するのかを明確にしなければならない。安全性チームがリリースを阻止できるのか、製品担当役員がその決定を覆せるのか、外部レビュー担当者が意味のある証拠を受け取るのかを説明すべきである。
また、人間による制御を運用面で定義する必要がある。運用者がシステムの行動を理解できず、障害を検知できず、取り返しのつかない結果が生じる前に介入できないなら、停止ボタンだけでは不十分だ。
企業顧客にとっての制御には、モデル選択、データ境界、監査ログ、役割ベースのアクセス、評価記録、ロールバック手順、自律行動への制限が含まれる。また、単一のプロバイダーの外部に組織的なコンテキストを保持することも含まれる。
そのアーキテクチャは、より広いナレッジ・ブレンディングの原則に通じる。つまり、出所やユーザーによる制御を失わせることなく関連情報源を結び付けるシステムほど、有用性が高まるという考え方だ。エンタープライズ向けエージェントでは、出所情報によって、あるアクションが信頼されるのか、レビュー対象となるのか、あるいは拒否されるのかが決まる可能性がある。
したがって、Microsoftのコードはレトリックではなく製品を通じて評価される。最も強力な証拠となるのは、モデルが定められた基準値を満たさなかったために、同社がリリースを延期、縮小、または中止したことが明確に示される事例だ。
コードの強さは、テストと執行力によって決まる
最大の不確実性は、Microsoftの原則が独立して検証可能な意思決定につながるかどうかだ。
Microsoftは長年にわたり、責任あるAIプログラムを構築してきた。同社が公開している責任あるAIプログラムは、透明性、説明責任、公平性、包摂性、信頼性、安全性、プライバシー、セキュリティを柱としている。
同社はまた、リスクを特定、測定、管理するプロセスについても説明している。こうした取り組みはモデルガバナンスの土台となるが、超知能に関する行動規範には、より高い基準が求められる。
第一に、Microsoftはコードの対象となるシステムを定義しなければならない。MAIファミリーには、推論、コーディング、音声、文字起こし、画像向けのモデルが含まれる。これらのシステムは故障モードが異なり、それぞれ異なる評価を必要とする。
音声モデルには、同意、なりすまし、詐欺、開示に関する懸念がある。コーディングモデルには、サイバーセキュリティ、依存関係、実行、ソフトウェア完全性に関する懸念がある。ツールに接続された推論モデルは、計画と自律的な行動に関するより広い問題を提起する。
単一の普遍的原則では、こうしたモデル固有の管理を置き換えられない。このコードには共通の基盤に加え、能力と導入コンテキストごとに個別の要件が必要だ。
第二に、評価は実際の製品利用に近いものでなければならない。個別のベンチマーク課題だけでテストされたコーディングモデルは、リポジトリの編集、コマンドの実行、認証情報へのアクセスを行うエージェント内では、異なる挙動を示す可能性がある。
Microsoftは、MAIモデルが製品固有の作業を中心に学習・最適化されていると述べている。そのため、製品レベルでの評価は特に重要になる。重要な評価単位は、多くの場合、ハーネス、ツール、メモリ、ポリシー、人による承認フローを含む完全なシステムだ。
第三に、結果には明確な報告が必要である。外部の関係者がテスト定義、比較条件、モデルバージョン、ツールへのアクセス、失敗カテゴリーを確認できなければ、スコアの価値は限定的だ。
Microsoftは、有用な根拠を示すために、機密性の高いモデル重みやセキュリティの詳細を公開する必要はない。評価手法、要約した結果、既知の制約、導入上の制限、重要な緩和策の説明を公開できる。
第四に、執行は社内チームにも及ばなければならない。Microsoftはサービスアクセスを停止できるため、顧客への制限は比較的把握しやすい。これに対し、製品の締め切りや収益目標が同じ会社の内部で作用するため、社内での執行はより難しい。
信頼できるガバナンス構造では、リスクレビューをリリース速度によって評価されるチームから分離する。文書化されたエスカレーション経路を設け、安全性と商業目標が衝突した際に誰が権限を持つのかを定める。
第五に、このコードはリリース後の変更にも対応すべきだ。モデルは新しいツール、より長いコンテキスト、更新されたシステム指示、より広い権限を与えられても、新たな公開名称を受けない場合がある。
こうした変更は、従来型のモデル更新よりもリスクを大きく変える可能性がある。したがってガバナンスは、学習の終わりに生成されたチェックポイントだけでなく、導入構成全体を対象にしなければならない。
独立研究者も、制御喪失リスクの測定は依然として難しいと強調している。2026年シンガポール・コンセンサスを通じて公表された世界的研究優先課題は、この分野が徐々に検証可能になっていると説明する一方で、予測に関する大きな不確実性も認めている。
この不確実性は両方向に作用する。破滅的な結果が差し迫っていることを証明するものではない。しかし、観測された失敗がないことを、システムの安全性を示す根拠として扱うことも正当化しない。
Microsoftは、文書化されたコードがアライメントを解決するかのような示唆を避けるべきだ。アライメントは、価値観の対立と不完全な測定を伴う、技術的、組織的、政治的な問題であり続ける。
批評家も反対方向の誇張は避けるべきだ。自主的なコードが自動的に無意味になるわけではない。具体的なテスト、明示された意思決定者、リリースゲート、文書化された結果を含むなら、エンジニアリング上の判断に影響を与えられる。
適切な基準は証拠である。このコードは、何が学習されるか、どのようにテストされるか、どの能力が制限されたままか、そしていつ導入が停止されるかを変えるのか。
開発者とエンタープライズ購入者が問うべきこと
顧客は、重要な業務をMAIモデルに任せる前に、Microsoftの人間による制御という誓約を調達上の質問へと置き換えるべきだ。
最初の質問は対象範囲に関するものだ。購入者は、Microsoft MAI Code of Conductが一般公開モデルだけに適用されるのか、それともMicrosoft製品内で使われる内部バージョンにも適用されるのかを知る必要がある。
Copilotに組み込まれたモデルは、ユーザーが直接選択しなくても影響を及ぼす可能性がある。Microsoftは、どのモデルがタスクを実行するのか、いつルーティングが行われるのか、管理者が特定のモデルファミリーを制限できるのかを開示すべきだ。
第二の質問は評価に関するものだ。組織は、モデルが一般的なベンチマークで高得点を達成したかどうかではなく、自らのユースケースにどの安全性・品質テストが適用されるのかを問うべきである。
カスタマーサービス支援ツールには、裏付けのない主張、エスカレーション、プライバシー、記録処理に関するテストが必要だ。コーディングエージェントには、安全でないコマンド、脆弱なコード、シークレットの露出、パッケージ完全性、無許可の変更に関するテストが必要となる。
医療または金融のワークフローでは、ミスが権利、機会、身体的な健康に影響し得るため、より厳格な人によるレビューが必要である。Microsoftの既存エンタープライズ向けコードも、重大な影響を及ぼす決定には適切な監督が必要だと位置付けている。
第三の質問は自律性に関するものだ。購入者は、エージェントが実行可能なアクション、承認を要するアクション、いかなる状況でも禁止されるアクションを文書化すべきである。
人間による制御は、失敗後だけでなく、重大な結果を伴うアクションの前に存在すべきだ。レビュー画面、権限境界、取引上限、可逆的なステージング環境は、安全に振る舞うという一般的な指示よりも大きな保護をもたらす。
第四の質問は監視に関するものだ。チームには、入力、取得されたコンテキスト、ツール呼び出し、モデル出力、ポリシー介入、承認、最終アクションを示すログが必要である。
ワークフローで複数のモデルを使う場合でも、これらの記録は理解可能な状態で維持されるべきだ。プラットフォームが各ステップを黙ってルーティングし、利用可能な意思決定の記録を残さなければ、企業はインシデントを調査できない。
第五の質問はモデル変更に関するものだ。MicrosoftがMAIモデルを更新する、またはルーティング層を変更する場合、エンタープライズ導入では、通知期間、回帰テスト、ロールバックの選択肢、バージョン管理を定義すべきである。
自動的な改善は魅力的だが、更新されたモデルは検証済みワークフローの挙動を変える可能性がある。規制対象のチームは、新バージョンを採用する前にテストを繰り返す必要があるかもしれない。
第六の質問はデータに関するものだ。Nadellaは、企業は自らの学習ループ、すなわち従業員とシステムが作業を行う際に生成される情報を管理し続けなければならないと主張している。
購入者は、プロンプト、出力、フィードバック、ツールのトレースがMicrosoftモデルの学習に使われるのかを明確にすべきである。また、それらの記録がどこに保存され、どのようにエクスポートまたは削除できるのかも確認すべきだ。
第七の質問はインシデント対応に関するものだ。コードには報告経路が必要だが、エンタープライズには対応時間、エスカレーション先、封じ込め手順、インシデント後の説明も必要である。
開発者にも実務上の責任がある。周辺システムが検証するまでは、モデル出力を信頼できないものとして扱うべきだ。この原則は、エージェントがコードを書く、データを変更する、あるいは外部と通信する場合に特に重要となる。
これらの質問はいずれも、超知能を待つ必要はない。すでに言語モデルをツールや組織データと組み合わせている現在のシステムにも当てはまる。
Nadellaの発表が重要なのは、顧客が引用できる基準を与えるからだ。MicrosoftがAIは人間の制御下に置かれなければならないと述べるなら、購入者はその制御がどこにあるのかを同社に示すよう求められる。
Microsoftの本気を示す3つのシグナル
次の試金石は実装であり、このコードがMicrosoftの行動を変えるかどうかは、観測可能な3つのシグナルによって明らかになる。
第一のシグナルは、モデル固有の要件と評価結果の公開である。Microsoftは、このコードを一般的な声明として放置するのではなく、個別のMAIモデルと結び付けるべきだ。
MAI-Thinking-1では、推論の信頼性、欺瞞のテスト、ツール利用の境界、サイバーセキュリティ評価、エージェント制御の結果などが含まれ得る。音声・画像モデルについては、なりすまし、出所、同意、有害コンテンツへの安全策を対象とすべきだ。
決定的な詳細は、すべてのスコアが好ましく見えるかどうかではない。高度なモデルはあらゆる環境で信頼性高く動作するわけではないため、制約を透明に示すことはフレームワークの信頼性を高める。
Microsoftが再現可能な手法、バージョン管理された結果、明確な導入制限を公開すれば、Nadellaの約束はより強固になる。原則だけを公開するなら、この発表は依然として監査が難しいままだ。
第二のシグナルは、リリースゲートが実際に結果をもたらすことの証拠だ。テストによって未解決のリスクが明らかになった後、Microsoftが延期、制限、またはプレビューに留めるMAI機能が現れるかを注視すべきである。
そのような判断は、意図的なペーシングが商業的圧力に打ち勝ち得ることを示す。また、後続リリースを評価する従業員やパートナーにとっての前例にもなる。
ただし、延期だけで優れたガバナンスが証明されるわけではない。企業は技術的、財務的、戦略的な理由で製品を延期する。Microsoftは、いつコードが判断に影響したのかを説明し、機密性の高いセキュリティ詳細を公開せずに関連する基準値を特定すべきだ。
コードによって変更されるリリースが一度もなければ、観察者はこのフレームワークが開発を統治しているのか、それとも既存の意図を文書化しているだけなのかを疑問視すべきである。
第三のシグナルは、MicrosoftがFoundry、Copilot、Microsoft 365にまたがる自律型エージェントをどのように扱うかだ。モデルがツールと行動権限を得た時点で、モデル安全性とエージェント安全性を別々に扱い続けることはできない。
より強力な管理者コントロール、細かな権限設定、承認要件、監視、ロールバック、一貫したモデル識別に注目したい。こうした機能は、人間による制御を製品の特性へと変える。
また、Microsoftが自社プラットフォームを通じて配布されるパートナーモデルにも同等の基準を適用するかを注視すべきだ。基盤となるモデルが別の研究所のものであっても、顧客が体験するのは完全なMicrosoftサービスである。
MAIに限定されたコードは、Microsoft社内の実務を改善するかもしれないが、より広いカタログ全体では保護の不整合を残すことになる。プラットフォームレベルの制御層は、その隔たりを縮小できる可能性がある。
したがってMicrosoft MAI Code of Conductは、同社の超知能戦略にとって有用な試金石となる。Microsoftは、フロンティアでの進歩、低コストな特化型モデル、広範な普及、有意義な人間による制御を同時に実現しようとしている。
これらの目標は、自動的に両立するものではない。その衝突は、リリース会議、製品の権限設定、評価レポート、インシデント対応に表れるだろう。
開発者とエンタープライズのリーダーは、Nadellaの原則を保存し、そうした判断と照らし合わせるべきだ。どのテストが導入を停止できるのか、誰がそれを執行する権限を持つのか、顧客はどのような証拠を受け取るのかを問うべきである。
Microsoftがこれらの問いに公に答えるなら、意図的なペーシングは運用上の規律となる。そうでなければ、このコードは加速するモデルプログラムに付随した価値観の声明にとどまる。
