AI導入で自社に何を残すか——Microsoft Frontier Companyから考える継続改善の設計

「AIを導入したい」という相談の多くは、「どのモデルを選び、どうつなぐか」から始まります。

ところが、最近のある大手の動きは、価値の重心がそこではない可能性を示しています。

モデルを入れた先に、自社に何が残るのか——そこから設計を始めると、見える景色が変わります。

Microsoftが立ち上げた「新しい事業組織」とは

Microsoftは2026年7月2日、「Microsoft Frontier Company」を発表しました。

同社はこれを、AIによる変革を顧客に届けるための “a new operating business”（新しい事業組織）と説明しています。

25億ドルの投資と、6,000名規模の業界・エンジニアリングの専門家を伴う取り組みだとされています。

なお、この6,000名について、全員が新規に採用される、あるいは物理的に常駐する、といったことは発表では明記されていません。

その特徴は、Microsoftの説明によれば、いわゆる Forward Deployed Engineering（FDE）を土台としつつ、深い業界知識、変革管理（チェンジマネジメント）、継続的な改善の経験、そしてエンタープライズ級のAIエンジニアリングを組み合わせる形へ拡張した点にあります。

専門家を顧客組織・顧客チームに組み込み、共同で設計・導入し、継続的に改善していく進め方だと説明されています。

Microsoftは、この取り組みで顧客のデータやIP、競争優位の扱いにも触れています。

同社の説明では、顧客の差別化要因をコモディティ化するような形でモデルの学習にそれらを使うことはしない、とされています。

ただし、これはあくまで発表上の方針であり、具体的なデータの利用条件は製品・契約・構成ごとに異なります。

実際に利用する際は、その都度確認が必要です。

継続改善の一例として、Microsoftは金融情報サービスのLSEG（ロンドン証券取引所グループ）との取り組みを挙げています。

同社の説明によれば、Microsoftのエンジニアと業界専門家がLSEGと組み、LSEG WorkspaceにAI検索機能を組み込み、金融の専門家が構造化・非構造化された情報を横断して問い合わせ、素早く答えを得られるようにした、とされています。

そしてその基盤は、顧客のフィードバックとリアルタイムのユーザーテストによって反復的に改善され、モデルの品質と適用範囲を継続的に高めている、と説明されています。

これはMicrosoftによる自社事例の説明であり、あらゆる導入の成功を一般的に保証するものではありませんが、「作って終わり」ではなく「使いながら改善し続ける」ことに価値を置いている点は読み取れます。

AI導入の価値は「モデルを入れること」だけでは決まらない

ここから読み取れるのは、AIを提供する側自身も、価値の所在を「モデルそのもの」だけには置いていない、ということです。

私たちの一貫した見方も同じ方向にあります。

AI導入の成否を分けるのは、モデルの性能そのものよりも、それを自社の業務のなかにどう組み込み、どう改善し続けるかという業務システム全体の設計です。

多くの企業にとって、基盤モデルは自社で作るものではなく外部から調達し、将来は別のモデルに切り替え得る構成要素です。

だからこそ、「最高性能のモデルを選ぶこと」よりも、「モデルが変わっても回り続ける業務の構成」と、「運用を続けるほど再利用できる価値になりうる仕組み」のほうが、長い目で見た資産になります。

言い換えると、基盤モデルは調達する構成要素であり、入れ替わり得ます。

残るのは、そのモデルを使った自社の業務のかたちと、そこから生まれる記録です。

次に、その「残るもの」をどう設計するかを見ていきます。

改善データ——自社に残る資産をどう設計するか

ここで本稿では、その「残るもの」を 改善データ と呼んで整理します。

これはMicrosoftの公式用語ではなく、あくまで本稿でのMIF独自の整理です。

改善データとは、次のものを一連の流れとして関連付け、評価と改善に使える形にしたものを指します——利用者の依頼（何を頼まれたか）、AIが参照した情報、AIの回答・提案・分類結果、実際に呼び出したツールの実行、人による承認・却下・修正、そして最終的な業務結果。

これらが「どの依頼が、どんな情報を経て、どう処理され、人がどこを直し、最終的にどうなったか」という筋でつながっていることが肝心です。

AIの内部的な思考の中身を保存する、という話ではありません。

あくまで、業務として観測できる入力・行動・結果・人の介入を、後から評価・改善に使えるように残す、ということです。

ここでいう「改善」は、モデルの再学習だけを指すものではありません。

集めた記録は、業務のルールの見直し、権限の調整、UIの改善、業務手順の変更、そして「どのモデルを使うか」の選択の見直しにも使えます。

むしろ再学習より、こうした運用側の調整のほうが効くことも少なくありません。

よくある誤解は、「自社開発すればデータが自社にたまる」という言い方です。

ためること自体が目的ではありません。

大事なのは、何を保存し、どのIDで相互に関連付け、誰がアクセスでき、何年間保持し、どの評価・改善に使うのかを、自社の都合で設計できることです。

加えて、その記録を自社が利用する権利があるか、必要な形でエクスポートできるか、ベンダーを変えても持ち出せる可搬性があるか——「自社に残る」とは、保存場所の話だけでなく、こうした利用権と可搬性まで含みます。

逆に言えば、既製品を使っていても、その記録を自社の基盤に残す設計にすれば改善データは作れますし、自社開発していても、この設計をしなければ記録は散らばったログのままで資産になりません。

「作るか買うか」ではなく、「改善に使える形で残す設計があるか」が分かれ目です。

一方で、記録は多く残すほどよい、というものでもありません。

目的を限定し、その目的に必要なものだけを残す（データ最小化）、アクセス権を絞る、保持期間を決めて過ぎたら削除する、個人情報や機密は必要に応じてマスキングする——こうした観点をセットで設計しないと、改善データはそのまま漏えいや管理コストのリスクにもなります。

残す設計と、残さない・消す設計は、いつも対で考えます。

3つの実装パターンで考える

AIの導入は「既製品か、自社開発か」の二択で語られがちですが、実際にはその間に幅があります。

本稿では、3つの実装パターンとして整理します。

これは成熟度の順（下から上へ上がっていくもの）ではありません。

企業全体でどれか一つに決めるものでもなく、業務ごとに使い分け・併用してよいものです。

1. 既製品をそのまま使う：提供されるツールやアシスタントをそのまま業務に充てる。導入が速く、初期の開発負担を抑えやすい。
2. 既存プラットフォームに独自機能や接続を追加する：既製の基盤を土台に、自社データへの接続、独自のツール連携、権限や記録の追加などを載せる。
3. UI・データ・認可・実行系まで自社向けに設計・開発する：画面、保存するデータ、権限の制御、外部システムへの実行までを自社の業務に合わせて作り込む。これはすべてを自前で書くという意味ではなく、自社または開発パートナーが、自社固有の部分を設計する構成を指します。

同じ会社のなかでも、問い合わせの一次対応は①、社内ナレッジ検索は②、基幹システムを操作する定型処理は③、というように、業務ごとに違うパターンを選ぶのが自然です。

作り込みで得られるもの・背負うもの

③のように自社向けに作り込むほど、自社で制御・最適化できる範囲が広がります。

改善データを自社の狙いに合わせて設計できること、業務に固有の権限制御を細かく作れること、既存システムへ深く組み込めること、自社の物差しで評価できること、状況に応じてモデルを切り替えられること、コストや速度を業務に合わせて最適化できること、そして運用のなかで自社にノウハウが蓄積されていくこと——これらは作り込みの側に寄るほど手に入りやすくなります。

なお、モデルの切り替えも、作り込めば自動的に可能になるわけではありません。

切り替えやすいように抽象化しておき、切替の良否を測る評価基盤をあらかじめ設計しておく必要があります。

ただし、同じだけ背負うものも増えます。

作り込んだ範囲は、開発の責任も、稼働の監視も、セキュリティの確保も、障害が起きたときの対応も、品質の評価も、自社側に移ってきます。

ベンダーに任せていた部分を自前で持つということは、その分の運用と責任を引き受けるということです。

ここを見ずに「作り込めば自由になる」とだけ考えると、運用の負担で行き詰まります。

得られるものと背負うものは、いつも対になっています。

どのパターンを選ぶか——業務ごとに判断する

だからこそ、選択は会社単位ではなく業務単位で行うのが現実的です。

判断の観点としては、次のようなものがあります。

以下は自社の状況に置き換えて使うための叩き台であり、正解の設定ではありません。実際の値や重み付けは、自社の業務・体制・リスク許容度に合わせて決めてください。

判断の観点	見るポイント	目安（あくまで一例）
業務の独自性	自社固有の判断・ノウハウが競争力の源か	独自性が高いほど②③を検討
統制の強制	必要な承認・上限・停止・監査を既製品の標準機能で強制できるか	標準機能で強制できないなら②③
連携の深さ	既存システムとどこまで繋ぐ必要があるか	深いほど②③
データ	何を残し、どう評価・改善に使うか設計したいか	要件次第。①でも記録を自社基盤へ残せる場合がある
処理規模・頻度	件数・速度・コストが効いてくるか	大きいほど最適化の余地。①で足りる場合もある
セキュリティ・コンプライアンス	データの保存場所、アクセス制御、監査証跡、保持・削除の要件を満たせるか	必須要件を満たせない選択肢は外す
社内運用体制	開発・監視・障害対応・評価を担える体制があるか	体制が薄いなら①②から始める

表を一枚に見せていますが、これらは「一つの製品の設定」で決まるものではありません。

権限や実行の制御は接続先システム側で、保持年数や利用範囲は社内の運用ルールで、評価は自社の物差しで——というように、決めどころは制度・システム・運用に分かれます。

まずは主要な業務を数個挙げ、この観点で①②③のどれから始めるかを置いてみると、議論が具体になります。

まとめ：モデルと同時に「何を残すか」を決める

Microsoftの新しい事業組織が示しているのは、大手が「モデルを届けて終わり」ではなく、顧客の現場で使いながら継続的に改善する仕組みに投資している、という事実です。

裏を返せば、AI導入の価値は、どのモデルを選ぶかだけでは決まりません。

自社で検討するなら、モデルの選定と少なくとも同時に、「この業務で何を残すか」を決めることをおすすめします。

どの依頼・情報・回答・実行・人の修正・結果を、どのIDでつなぎ、誰がどれだけの期間持ち、どの改善に使うのか。

そして、その記録を自社が利用でき、必要なら持ち出せるか。

それを先に描いておけば、既製品から始めても、作り込みに進んでも、記録と改善の運用を続けていくかぎり、それは再利用できる資産になっていきます。

モデルは変わっていきますが、その設計は残ります。

情報確認について

本記事は2026年7月確認時点で、Microsoftの公式ブログ「Microsoft Frontier Company: AI engineering that amplifies and protects your intelligence」（2026年7月2日）および Microsoft Frontier Company の公式事業ページを主要な参照元として作成しています。

事業組織の規模・体制、データやIPの取り扱い方針、事例の内容は、今後変更される可能性があり、具体的なデータ利用条件は製品・契約・構成ごとに異なります。

導入・利用の際は、各製品の公式情報と契約条件でご確認ください。