AIに仕事を任せても学習の循環まで手放してはいけない ナデラとSkillOptに学ぶ能力の蓄積

AIに資料の下書きを作ってもらう。コードを書いてもらう。顧客への返信文を考えてもらう。

日々の業務でAIエージェントやLLMを活用する機会は当たり前になりました。しかし、その作業が一通り終わったとき、自分たちには何が残っているでしょうか。

手元に残ったのは、その場限りの完成した成果物だけなのか。それとも、次の仕事で再利用できる判断基準や、同じ失敗を未然に防ぐ仕組みまで組織に残っているのか。

この違いを明確に意識できるかどうかが、AI活用が単なるコスト消費で終わるか、自社の競争力として積み上がるかの分岐点になります。

Microsoftの会長兼CEOであるSatya Nadella氏は、2026年6月に公開した論考「A frontier without an ecosystem is not stable」の中で、人間とAIの間にある学習の循環こそが企業の将来を左右すると論じました。一方で、Microsoft Researchなどの研究チームが発表したSkillOptは、モデル自体の重みを固定したまま、実行履歴と検証に基づいてモデル外部の作業手順書（Skill）を最適化する実践的なアプローチを提示しています。

一方は経営者による産業構想であり、もう一方は具現化された技術研究です。両者を重ね合わせて読み解くと、私たちが実務で向き合うべき本質的な問いが浮かび上がってきます。

「AIに何を任せるか」だけでなく、「任せた仕事から得た学びを、誰の能力として蓄積するのか」。

AIの利用量と組織への能力蓄積を区別する

Nadella氏は先述の論考で、これからの企業が持つべき資本として「人的資本（Human Capital）」と「トークン資本（Token Capital）」という二つの概念を提示しています。

人的資本とは、組織に属する人間が持つ知識、文脈の理解、判断力、対人関係、創意工夫などを指します。これに対してトークン資本とは、企業がみずから構築し、保有・運用するAIの実行能力を意味します。ここでいう資本とは、単にAPIプロバイダへ支払った請求額や、購入したトークンの残高ではありません。

この区別は極めて重要です。

毎月のAI利用料や消費トークン数が増えたからといって、それだけで自社の能力が高まったとは言えません。処理したタスクの件数が増えたことと、次のタスクをより適切に進められる基盤が整ったことは、まったく別の問題だからです。

たとえば、毎回ゼロから前提条件をプロンプトで説明し、出力された誤りを人間がその場しのぎで手動修正し、文脈の補填を毎回同じように人が肩代わりしている運用を想像してみてください。成果物の量自体は増えていても、その経験から得られた知見はどこにも引き継がれません。

反対に、修正が発生した理由が分析され、判断条件やチェック手順が更新され、別の担当者やAIエージェントでも同じ品質を再現できるようになれば、その経験は一回限りの消費ではなく資産になります。

Nadella氏が重要視しているのは、単に最新で最高性能のモデルを買い換えることではなく、人間の判断とAIの実行能力が互いに積み上がる学習ループを構築することです。

問うべきなのは「どれだけAIを使ったか」ではなく、「使った結果として組織に何ができるようになったか」です。

SkillOptが変えるのはモデルではなく仕事の進め方である

学習ループを具体的にどう実装するかという問いに対して、明快な技術的示唆を与えてくれるのがMicrosoft ResearchによるSkillOptの取り組みです。

SkillOptの特徴は、基盤モデルのパラメータ（重み）には一切手を加えず、モデルに与える自然言語の「Skill文書」を訓練可能なパラメータとみなして最適化する点にあります。ここでいうSkillとは、情報の集め方、ツールの呼び出し順序、確認手順、判断基準などを記述した再利用可能な仕事の手順書です（当サイトの技術ガイド「AI AgentのSkillとは何か」でも解説している概念です）。

SkillOptの基本的な最適化プロセスは、以下の段階で構成されています。

さらに、不採用となった修正案の理由を以後の提案へのフィードバックとして蓄積する仕組みや、短期的な修正だけでは対応できない傾向に対処する更新メカニズムも備えています。

ここで注目すべき核心は、「AIに反省文を書かせること」ではありません。

反省から生まれた修正案を、客観的な改善が検証できるまで本番のSkillとして絶対に採用しないことです。

人間にとってもAIにとっても、「もっともらしい理由」と「実効性のある改善」は別物です。「見落としを防ぐために確認項目を5つ追加しました」という変更案は、一見すると筋が通っているように見えます。しかし実際には、プロンプトのコンテキストを圧迫して重要な指示を埋もれさせたり、処理速度を大幅に低下させたりする副作用を生むことがあります。良さそうに見える変更を、そのまま良い変更として扱わない。そのために厳格な評価ゲートが存在します。

論文内の実験では、たとえばGPT-5.5の直接実行において、SpreadsheetBenchのスコアがSkillなしの41.8からSkillOpt適用後の80.7へと大幅に向上したことが報告されています。ただし、これはベンチマークの特定条件下における測定結果であり、あらゆる企業業務や長期的なビジネス成果に対する万能の特効薬を意味するものではありません。

また、関連研究のSkillOpt-Sleepでは、日々のエージェント実行ログから繰り返し発生する課題パターンを抽出し、オフラインでの再実行と検証を経てSkillや記憶の更新案を自律的に準備する枠組みも提案されています。しかしこれもプレビュー段階の実験であり、「ログを放り込んでおけば魔法のように賢くなる」といった類のものではありません。

実行履歴は保存しただけでは競争力にならない

ここからは、Nadella氏の構想とSkillOptの研究成果を踏まえ、実務の設計へどう落とし込むかという私自身の解釈を述べます。

多くの現場で「自社には長年蓄積された業務データがある」「現場のベテランに独自のノウハウがある」という言葉が語られます。それらが出発点として貴重であることは確かですが、データ量が多いことや現場にノウハウが眠っていることそれ自体が、直ちにAI時代の競争力になるわけではありません。

過去の業務ログや対応履歴には、優れた判断だけでなく、偶然その場をしのげただけの対応、過去の古い前提条件でしか通用しない暫定処置、担当者の個人的な思い込みや非効率な習慣も混ざり込んでいます。それらを無差別にAIへ学習させたりプロンプトへ詰め込んだりすれば、組織の強みだけでなく過去の悪癖まで忠実に再現してしまいます。

必要なのは、生ログをそのまま記憶させることではなく、どの経験から何を抽出し、どのような検証を経て再利用可能なルールへ蒸留するかという選別プロセスです。

たとえば、顧客から「特急で納期を前倒しできないか」という相談を受けるサポート業務を考えてみます。

過去の返信ログをそのまま保存しただけでは、AIは「以前も似たような相談に対応できると答えていた」という表面的な文面の真似しかできません。

一方、経験を組織の能力として蓄積するためには、以下のような階層的な整理が必要になります。

• 納期の前倒しを回答する前に、在庫状況や生産ラインのどの稼働状況を確認したのか
• どのような条件下では決して即答せず、現場責任者の事前承認を必須としたのか
• 回答後に現場でトラブルや納期の遅延が発生しなかったかどうかの結果の追跡
• 権限のない安請け合いや誤った確約をAIが提案しないかテストするための評価シナリオ

生ログはあくまで材料に過ぎません。検証された判断基準と具体的な手順へ変換されて初めて、繰り返し使える組織の能力になります。

また、得られた学びのすべてを自然言語のSkill文書にする必要もありません。過去記事「Agent Skillsの作り方 履歴から設計して評価する」でも触れたように、頻繁に変わる事実はナレッジベースへ、確実に決定論的な処理ができる部分はプログラムコードへ、絶対に越えてはならない安全境界は権限管理へ、二度と起こしてはならない重大な失敗は自動テストへと、学びの性質に応じた適切な置き場所へ配分することが肝要です。

何を良い仕事とするかの評価基準を手放さない

Nadella氏は論考の中で、誰でも参照できる公開ベンチマークのスコアを競うことよりも、自社の事業にとって本当に重要な成果を測る「非公開の評価環境」を社内に構築することを強く主張しています。

これは単なるテスト運用の話ではありません。本質的には、「自分たちの仕事において、何が良い仕事であるか」の定義権を誰が握るのかという主導権の問題です。

先ほどの納期調整の例で、AIの回答精度を「文章の丁寧さ」や「返信までの所要時間」だけで採点していたとします。もしそのような評価基準を敷いてしまえば、実現不可能な納期を即座に丁寧な文面で約束してしまうような、極めて危険な出力が高得点を獲得してしまいます。

実務において本当に確かめるべき基準は、以下のような点にあるはずです。

1. 回答前に必要な前提条件（在庫、稼働率、出荷リードタイム）を確実に確認したか
2. 承認権限のない担当者やAIが、独断で確約を出してしまう事態を回避できたか
3. 顧客の次の行動に必要な情報が漏れなく伝わり、その後の確認往復や手戻りが減ったか
4. 最終的に約束どおりの納品が完了し、現場のオペレーションに無理な負荷をかけなかったか

評価の設計を誤ると、改善のための自動化ループは誤った方向へ猛烈な速度で突き進んでしまいます。

SkillOptの最適化プロセスも、信頼できる評価シグナルが存在することを前提に成り立っています。論文自身も認めているように、成功の定義が主観的であったり、多面的なトレードオフを含んでいたり、評価自体のコストが高い領域では、評価環境の設計そのものが最大の技術的難所になります。

実務においては、全体の平均点向上だけに目を奪われて重大なインシデントを見落とさないこと、改善案を探索するためのデータと最終合意判定を下すための評価データを厳密に分離すること、そして採点ロジック自体が現場のビジネス成果と乖離していないかを定期的に見直す姿勢が欠かせません。

さらに、組織の学習には二つの循環（ダブルループ）が求められます。

一つは、あらかじめ定義された手順に沿って業務をより効率的に進める循環です。そしてもう一つは、「そもそもこの業務や評価基準自体が、顧客や事業の目的に適っているのか」を根本から問い直す循環です。問い合わせ対応の改善をいくら突き詰めても、根本的な原因が製品マニュアルの不備やUIの分かりにくさにあるのなら、改修すべきはサポートのSkillではなく製品そのものです。

実行結果を検証し、方法だけでなく目的そのものを修正していく改善思想自体は、W. Edwards Deming Instituteが体系化したPDSAサイクルをはじめとして、ソフトウェア工学や品質管理の領域で古くから実践されてきました。現代の新しさは、その改善サイクルを人間の手作業の中だけに留めず、AIエージェントの実行履歴から手順の修正、評価、再配備に至るシステム構造として組み込めるようになった点にあります。

モデルを乗り換えても蓄積した熟練を失わない設計

Nadella氏は、自社が主導権を保てているかどうかを判断する試金石として、「汎用モデルを別のプロバイダのものへ差し替えたとき、学習システムに蓄積してきた自社ベテランの専門性を失わずに済むか」という鋭い問いを投げかけています。

この問いの真価は、導入の華やかな瞬間ではなく、運用が長期化し環境の変化に直面したときに現れます。

APIの利用料金や利用規約が変更されたとき、あるいは他社からより費用対効果の高いモデルが登場したとき、モデルを乗り換えるたびに判断基準や例外処理、評価シナリオを一から作り直さなければならないとしたら、その企業の知的資産は特定の外部プラットフォームに過剰に依存してしまっています。

SkillOptが最適化の対象として出力するのは、モデル内部のバイナリの重みではなく、人間にも可読な自然言語のSkill文書です。論文では、異なるモデル規模や異なる実行環境へSkillを移植した際の汎用性についても実験が行われています。もちろん、モデルが変わればプロンプトの解釈特性も微妙に変化するため、無条件に同じ性能が保証されるわけではなく、移植先での再評価は必須です。

しかし、持ち運ぶべき対象を単なるプロンプトや手順書のテキストだけに限定してはなりません。

• なぜその判断を下すのかという背景や論理的根拠
• 合否を厳格に判定するための評価テストケース
• 外部ツールや社内データベースとの接続条件・スキーマ定義
• 誤作動や権限逸脱を防ぐための認可ポリシーと安全境界
• どのような失敗を経てそのルールが追加されたのかという変更履歴

これらがリポジトリの中でコードやテストとして管理されていれば、基盤モデルが進化したり提供元を切り替えたりしても、蓄積してきた業務の熟練を自分たちの手元で再現できます。

真の「所有」とは、単にテキストファイルが手元のストレージにあることではありません。みずからその構造を理解し、修正し、テストで検証し、異なる環境でも自律的に運用し続けられることを指します。

なお、モデルの外部にデータを保存することと、外部への情報送信を遮断することは同義ではありません。SkillOpt-Sleepの公開資料でも、商用のクラウドバックエンドを利用する以上、履歴から抽出されたログがモデル提供者側へ送信されること、また秘密情報を完全に機械的除去できる保証はないことが明記されています。自社で学習の仕組みを構築するなら、どのような情報を外部に渡し、何を社内境界に留めるかという情報ガバナンスの設計が不可欠です。

一方で、Nadella氏が論じた「コモディティ化」への懸念を過剰に解釈して、「AIに入力した自社データはすべて無断で基盤モデルの事前学習に使われてしまう」と短絡するのも不正確です。たとえばMicrosoftは、FoundryにおいてAzure経由で提供されるモデルのデータプライバシー規約において、顧客の入力プロンプトや出力結果を顧客の明示的な許可なく基盤モデルの訓練には使用しないと明確に定めています。情報漏洩リスクへの現実的な対策と、企業としての競争力がどこに残るかという構造的な問題は、適切に切り分けて議論する必要があります。

人の役割と価値は自動的には高まらない

Nadella氏は、トークン資本（AIの能力）が蓄積されるほど、それと相互作用する人的資本の価値も相乗的に高まると説いています。しかし、これは企業が目指すべき理想的なビジョンとして受け止めるべきであり、現場で働くすべての人間の市場価値や待遇が何もしなくても自動的に向上するという保証ではありません。

Erik Brynjolfsson氏らによる顧客サポート業務を対象とした生成AI導入の実証研究（Generative AI at Work）でも、AI支援の効果は一律ではないことが示されています。業務経験の浅い層やスキルの低い層では生産性の大幅な向上が確認された一方で、もともと高い技能を持っていた熟練者の層では処理速度の向上がごくわずかに留まり、場合によっては品質スコアが微減する傾向すら観察されました。この研究が示しているのは業務アウトプットの変化であり、働く人々の報酬や裁量の増加が自動的に担保されるわけではないという冷徹な事実です。

ここで求められるのは、「最後は人間が重要です」という中身のない精神論で安心することではありません。

業務プロセスの中で、人間が果たすべき役割を具体的に再定義することです。

• 達成すべきビジネス上の目的や優先順位を決定する
• 現場の一次情報や顧客の生の声に触れ、新しい文脈を持ち帰る
• AIが出力した提案を現実の制約やトレードオフと照合する
• 既存のルールや手順書から漏れている例外的な状況を発見する
• 修正案や改善案を本番環境へ反映するかどうかの最終的な合意判断を下す
• 判断の根拠を理解し、次の改善サイクルへ還元する

過去記事「AIコードレビューと人間のミドルウェア化」でも論じたように、人間が単にAIの出力を右から左へ受け流すだけの「ミドルウェア」に堕してしまえば、人の判断力も学習機会も失われていきます。AIの出力を鵜呑みにせず、なぜその回答を採用したのか、どのような条件では使えないのかを自ら説明でき、自分自身の判断基準も更新されているか。個人としても組織としても、学びの主導権を手放してはなりません。

また企業経営の観点からは、貴重な暗黙知や業務経験を提供してくれた現場の従業員に対して、節約された時間、より高次の判断を担う裁量、新しいスキルの獲得機会、そして適切な評価や処遇として還元できる制度設計が強く問われます。現場から知見を吸い上げるだけで、現場の人々から学習の機会やインセンティブを奪ってしまうような運用では、人とAIが共に成長するというエコシステムの思想は持続しません。

一部の巨大モデルに学習を独占させない構造

Nadella氏の論考が示唆に富んでいるのは、自社一社の利益だけで議論を終えていない点です。ごく少数の巨大フロンティアモデル提供者にすべての経済的価値と学習の機会が集中し、一般企業や周辺産業が単なる下請けの消費者に空洞化してしまうのではなく、各企業、各産業、各地域に固有の価値が残り続ける健全なエコシステムが必要だと訴えています。

ただし、この主張は世界最大規模のAIインフラとプラットフォームを提供する企業のトップによるステートメントであるという文脈を忘れてはなりません。特定のメガクラウドや製品を導入すれば、それだけで自社に価値が残るわけではありません。

むしろユーザー企業である私たちは、どのようなAIプロバイダに対しても以下の自問を投げかけ続ける必要があります。

• 自社の蓄積した知見やデータを、オープンな形式でいつでも取り出せるか
• 自社業務にとっての「品質」や「成功」の評価基準を、外部任せにせず自分たちで定義できているか
• コストや規約の変更に応じて、必要であれば別のモデルやインフラへ乗り換えられる主導権があるか
• 現場の知見を吸い上げてAI化するだけでなく、現場の人材にも還元される循環が作れているか

独自性を保つということは、オープンな技術や外部の優れたモデルを拒絶してすべてを自前主義で囲い込むことではありません。共通の強力な基盤モデルやオープンソースの資産を大いに活用しながら、その上で動く自社の判断基準、業務手順、評価データセットをみずからの手元に着実に積み上げていく。その二層構造を維持することこそが肝要です。

Nadella氏の経営論とSkillOptの技術研究から私たちが受け取るべきメッセージは明快です。

「現実の業務から深く学ぶ人間」「その学びを再利用可能な仕組みへ変換する評価駆動のプロセス」、そして「学びの成果をみずからの側に保持し続ける主導権」を確立すること。

AIモデルの計算力や推論能力は、利用料を支払えばいつでも外部から調達できます。しかし、その性能を使って自社が何を学び、どこに固有の能力として残すのかという学習の循環まで、外部のプラットフォームに委ねてはならないのです。

明日から実践できる三つのステップ

組織の中で経験を能力へ変える学習ループを回し始めるために、まずは以下の3つのステップから着手することをお勧めします。

1. AIの利用量ではなく、改善したい業務課題と評価基準を決める

漫然とAIの利用率やプロンプトの回数を追うのをやめ、繰り返し発生している特定の業務プロセスを一つ選定します。そのうえで、何が「良い成果」であり、何が「絶対に許容できない失敗」なのかを明確に定義し、現在の達成度を測定します。

1. 直近の失敗や訂正を一つだけ選び、検証可能な改善へ変換する

AIが誤った回答をしたログや、人間が手作業で訂正した事例を一件取り出します。なぜ失敗したのかを分析し、単にその場を取り繕うのではなく、手順書（Skill）、ナレッジベース、コード、権限境界、あるいはテストケースの適切な場所へ反映します。その変更によって本当に改善したかを、別のテストケースで検証してから正式に採用します。

1. その学びが別の環境や別の担当者にも引き継げるかを検証する

整備した手順や評価ケースが、他のメンバーや別のAIモデルでも同じように機能するかを試します。特定の個人の勘や特定のモデルの癖に依存せず、根拠とテストケースがセットで引き継げる状態になっているかを確認します。

目の前の仕事を一件片付けるだけで終わらせず、その経験を使って「次の一件のやり方」を確実に進化させる。その地道な学習の循環を回し続けることこそが、AI時代において真に自分たちに残る能力を形作っていきます。