【2026年最新】AI定着の2つの道｜モデルか、コンテキストか

結論: AIを業務に定着させる打ち手は「モデル自体を作り替える」か「AIに渡す作業環境を整える」かの2つに大別でき、多くの日本企業はまず後者から着手するのが現実的です。

この記事の要点:

• Microsoftの「Frontier Tuning」は、自社データと強化学習でモデル自身を業務に合わせて鍛え直す「モデル層」のアプローチ。一方、MCP（Model Context Protocol）や目標管理AI「Addness」のような仕組みは、業務の目標・タスク・ルールを構造化データとして外部に保持し、AIエージェントに供給する「コンテキスト層」のアプローチです
• コンテキスト層はCLAUDE.mdやMCPサーバーで今日から着手でき、特定のモデルに縛られないため乗り換えコストが低いという特徴があります
• モデル層は専用インフラと継続的な投資、大量の業務データが前提になるため、コンテキスト層で成果を出したうえで検討する”次の一手”と位置づけるのが現実的です

対象読者: 生成AIを導入したのに現場に根付かない、と感じている経営者・情報システム部門責任者

読了後にできること: 自社が今どちらの打ち手から着手すべきか、3ステップの優先順位で判断できるようになります

「AIツールをいくつも導入したのに、結局みんな使わなくなった」

100社以上の企業でAI研修・導入支援を続けていると、驚くほど頻繁に聞く相談です。ChatGPTやClaudeに単発で質問すれば賢い答えが返ってくるのに、実際の業務プロセスに組み込もうとした途端、「毎回同じ説明をゼロから書く」「前回の指摘を覚えていない」「社内ルールを知らないまま的外れな提案をする」といった壁にぶつかります。

この壁の正体は、実はモデルの”賢さ”の問題ではないことがほとんどです。どれだけ優秀な新人でも、会社の目標もルールも引き継ぎ資料もないまま「とりあえず働いて」と言われたら成果を出せないのと同じで、AIも「何を目指し、何を守り、これまで何が起きたか」という情報を渡されなければ、業務では機能しません。

この記事では、AIを業務に定着させるための2つの打ち手──①モデル自体を自社仕様に鍛え直す「モデル層」のアプローチ（MicrosoftのMAI・Frontier Tuning）と、②AIに渡す目標・文脈・記憶を整える「コンテキスト層」のアプローチ（MCP、Addnessのような目標管理AI）──の違いを、非エンジニアにも分かる言葉で整理します。そのうえで、日本企業がどちらから手をつけるべきか、明日から始められる3ステップまで具体的にお伝えします。

なぜ「AIに1回言うだけ」では業務が回らないのか

単発のプロンプトが業務では機能しない理由は、実はシンプルです。ChatGPTやClaudeのようなAIモデルは、原則として1回の会話（セッション）の中でしか情報を保持しません。これを「ステートレス（Stateless）」と呼びます。状態を持たない、つまり会話が終わればそれまでのやり取りは基本的に引き継がれない、という設計が前提になっているのです。

事例区分: 想定シナリオ
以下は100社以上の企業研修・AI導入支援の経験をもとに構成した、よくあるパターンです。特定の1社の実話ではありません。

ある企業の総務部門で、AIに「規程に沿って議事録をまとめて」と頼んだとします。1回目はうまくいっても、2回目以降は「うちの会社の規程」も「前回どう直したか」もAIは覚えていません。毎回、担当者が規程やフォーマットをコピペし直す羽目になり、「結局、自分でやった方が早い」という結論に落ち着く──これが、AI導入が”ツールを触っただけ”で終わってしまう典型的な流れです。

この問題を解決するアプローチは、大きく2つに分かれます。一つは、モデル自身にその会社のやり方を「覚え込ませる」方向。もう一つは、モデルは汎用のままにして、必要な情報を毎回きちんと”渡す”仕組みを整える方向です。

2つの道──モデル層とコンテキスト層

この2つのアプローチは、人材育成の比喩で考えると分かりやすくなります。

• モデル層のアプローチ = 「新人を1年かけて自社仕様に育て上げる」。時間もコストもかかりますが、育て上がれば会社の空気を読んで自律的に動けるようになります
• コンテキスト層のアプローチ = 「即戦力の外部人材に、しっかりした引き継ぎ資料と今日のゴールを渡す」。人材（モデル）自体は汎用のままでも、渡す情報の質を上げれば十分に成果が出ます

モデル層とは何か──Microsoft「MAI」とFrontier Tuningの場合

Microsoftは2026年6月2〜3日開催の開発者会議「Build 2026」で、自社開発AIモデル群「MAI」ファミリーと、その調整手法「Frontier Tuning」を発表しました。Frontier Tuningは、企業が持つ独自のデータ・業務プロセス・用語・評価基準を使い、モデル自体を鍛え直す仕組みです。公式ブログでは「コンプライアンス境界の内側で、あなたの会社が実際に働いているやり方をAIに教える、強化学習の新しいアプローチ」と説明されています。

この学習はRLE（Reinforcement Learning Environment＝強化学習環境）と呼ばれる管理された環境の中で行われます。実際の業務の記録──ツールの呼び出し順序、下した判断、加えられた修正、得られた成果──からモデルが学習し、本番システムには影響を与えない形で調整が進む、と公式は説明しています。Microsoftはこの取り組み全体を「hill-climbing machine（山を登り続ける仕組み）」と表現しており、計算資源・データ・評価の精度を継続的に投入することで、組織ごとにモデルを改善し続けられるとしています。

同じBuild 2026では、推論に強い「MAI-Thinking-1」（公式表現: flagship reasoning model）や、効率重視のコーディング特化モデル「MAI-Code-1-Flash」（公式表現: inference-efficient agentic coding model）などMAIファミリー7モデルもあわせて発表されました。Microsoftは独自の推論用チップ「Maia 200」との協調設計により、効率を1.4倍高めているとも説明しています。Frontier Tuning自体は、2026年7月時点でForward Deployed Engineers経由のPrivate Preview（限定提供）の段階で、今後Microsoft Copilot StudioやMicrosoft Foundryでの提供が予定されています。

MAIモデル自体の全体像はMicrosoft MAI 3モデル完全解説で、コーディング特化モデルの詳細はMAI-Code-1-Flash完全ガイドで解説しています。

要するにモデル層は、「自社専用のRLE（学習環境）を用意し、自社データで強化学習を回してモデルそのものを作り替える」アプローチです。当然、専用のインフラ・データ整備・継続的な学習サイクルへの投資が前提になります。

コンテキスト層とは何か──MCPと目標管理AIの場合

MCP（Model Context Protocol）は、Anthropicが公開しているオープンな標準規格で、AIアプリケーションが外部のデータやツール、業務フローに接続するための「共通の差し込み口」です。Anthropic公式は「AIアプリケーション向けのUSB-Cポートのようなもの」と説明しており、Claude・ChatGPT・VS Code・Cursorなど幅広いAIツールが対応しています。MCPの基本的な仕組みや導入ステップはコンテキストエンジニアリングとは？プロンプトの次に来る企業AIの新常識で詳しく解説していますが、ポイントは「モデルを変えなくても、外部のデータソースやツールをAIに”つなぐ”ための共通規格」だという点です。

このMCPを実際の業務で使う例として、目標管理プラットフォーム「Addness（アドネス株式会社）」が挙げられます。Addnessは、組織やメンバーの目標・タスクの進捗をツリー構造で可視化する目標管理ツールで、2025年12月21日に正式リリースされました。同社は公式サイトで「話すだけでやるべきことが明確になり、気づいたら前に進んでいる」状態を実現するAI行動支援OSと位置づけています。同社はAIコーディングエージェント（Claude Code等）から目標・進捗データを読み書きできるCLIツールを公式GitHubで公開しており、目標・タスクを構造化データとして保持し、AIエージェント側から都度参照・更新できる仕組みを実際に提供しています（同社の発表によれば、この仕組みをMCP経由でも提供しているとのことです）。他社サービスのため、機能の詳細な優劣評価はここでは行わず、位置づけの参考例として紹介します。

要するにコンテキスト層は、「モデルは汎用のままにして、業務の目標・タスク・ルールを構造化データとして外部に保持し、必要なタイミングでMCP経由でAIに渡す」アプローチです。モデル自体を鍛える必要がないため、Claude・ChatGPT・Geminiなど複数のAIモデルから同じデータソースを使い回せる、という特徴があります。日本国内向けのMCPサーバーの選択肢は日本特化MCPサーバー8選で紹介しています。

なお、時系列としてはAddnessが2025年12月に目標管理AIを正式リリースし、Microsoftが2026年6月のBuild 2026でFrontier Tuningを発表しています。X（旧Twitter）上では、この2つを「賢いエージェントモデルを作る」対「エージェントに正しい地図とコンテキストを渡す」という補完関係にある2つのアプローチとして整理し、Addnessが先行して同種の課題意識を示していた、という指摘も見られます。ただし両社は事業規模も対象領域も大きく異なるため、「どちらが先行したか」を単純に優劣として断定することは避け、あくまで課題意識の整理の一例として紹介します。

1枚で分かる違い

日本企業はどちらから始めるべきか──まずコンテキスト層

結論として、多くの日本企業にとって現実的な出発点はコンテキスト層です。理由は3つあります。

第一に、モデル層は自社インフラと巨額投資が前提になります。Frontier Tuningのような仕組みは専用の学習環境（RLE）を必要とし、現時点ではPrivate Previewの段階です。潤沢な開発リソースと業務データを持つ大企業でなければ、今すぐ選べる打ち手ではありません。

第二に、コンテキスト層はCLAUDE.mdやMCPで今日から始められます。特別なインフラ投資をしなくても、業務ルールや目標をドキュメント化し、必要なツールをMCPで接続するだけで、AIが参照できる情報の質を上げられます。

第三に、コンテキスト層はモデル非依存なので乗り換えコストが低いという利点があります。MCPは特定のAIベンダーに紐づく技術ではなく共通規格のため、将来的にどのAIモデルを主力にするかを変えても、整備したコンテキスト（ドキュメント・接続先データ）はそのまま使い続けられます。逆にモデル層に先に投資してしまうと、その投資は特定モデル・特定ベンダーに縛られやすく、方針転換の柔軟性が下がります。

事例区分: 想定シナリオ
以下は複数の企業のAI導入支援で共通して見られる、うまく進んだ場合の典型的な流れです。

うまく進む企業に共通するのは、最初から全社展開を狙わず、1つの部署・1つの定型業務からコンテキスト層を整備し始めている点です。「議事録の初稿作成」や「問い合わせ対応の一次回答」のように、範囲が狭く繰り返し発生する業務を選び、その業務のルールとゴールだけをまず言語化してAIに渡す。効果を確認してから、対象業務や接続するデータを少しずつ広げていく、という進め方が、結果的に一番早く現場に定着します。

明日から着手する3ステップ

ここからは、コンテキスト層の整備を今日から始めるための具体的な手順です。それぞれコピペで使えるプロンプトを添えています。

ステップ1：業務の”暗黙知”を棚卸しする

AIに任せたい業務について、担当者の頭の中にしかない「暗黙知」を先に言語化します。ここが曖昧なままだと、どれだけ立派なMCPをつないでも、AIが参照する情報の中身がスカスカのままになってしまいます。

以下の業務について、AIに任せる際に必要になる「暗黙知」を洗い出してください。

・業務名: [業務名を記入]
・現在の担当者: [氏名/部署を記入]

出力してほしい項目:
1. この業務でよく参照する社内ルール・規程・過去の判断基準
2. 過去に指摘・修正された典型的な失敗パターン
3. 業務のゴール(何をもって完了とするか)
4. 確認が必要な関係者・承認フロー

上記4項目をテキストでまとめてください。あとでCLAUDE.mdに転記します。

ステップ2：CLAUDE.md（コンテキストファイル）を作る

棚卸しした情報を、AIエージェントが毎回参照できる形にまとめます。CLAUDE.mdはClaude Code向けの呼び方ですが、考え方はどのAIツールでも共通で、「プロジェクトのルールをAIに常に読ませておくファイル」を用意する、という発想です。

次の情報をもとに、AIエージェントに読ませるプロジェクト設定ファイル(CLAUDE.md)の雛形を作成してください。

・会社名/部署: [ ]
・このAIに任せたい業務: [ ]
・守るべきルール・禁止事項: [ ]
・よく使う社内用語とその意味: [ ]
・成果物の提出形式: [ ]

Markdown形式で、見出しごとに整理して出力してください。

ステップ3：MCPで実データに接続する

ドキュメントの整備ができたら、次は実際の業務データにAIをつなげる段階です。いきなり全てのデータをつなごうとせず、まず何を・どの権限でつなぐべきかを整理します。

AIエージェントにMCP経由で接続させる社内データ・ツールの候補を洗い出したいです。
以下の観点で、業務[ ]に関連する候補を一覧化してください。

1. 読み取りだけで良いデータ(例: マニュアル、規程、過去の議事録)
2. 書き込み・更新が発生するデータ(例: タスク管理、顧客情報)
3. 機密度が高く、権限設計を先に決めるべきデータ

出力は表形式(データ名/種別/機密度/優先度)でお願いします。

【要注意】コンテキスト層整備でよくある失敗パターン

失敗1：一度作って更新しない（ドキュメント腐敗）

❌ よくある間違い: CLAUDE.mdやコンテキストファイルを最初に作ったきり、規程が変わっても放置してしまう。

⭕ 正しいアプローチ: 更新責任者と更新タイミング（規程変更時・四半期に1回など）をあらかじめ決めておく。

なぜ重要か: 古い情報を渡し続けると、AIは”もっともらしいが古いルール”に従って動いてしまいます。渡す情報が正しく更新されているかを、コードのレビューと同じ感覚で定期的にチェックしてください。次のようなプロンプトで簡易チェックできます。

以下のCLAUDE.md/コンテキストファイルの内容を読み、次の観点でチェックしてください。

1. 最終更新日から3ヶ月以上経っていそうな記述はないか
2. 現在の業務フローと矛盾していそうな記述はないか
3. 誰が更新責任者か明記されているか

[ここにCLAUDE.mdの内容を貼り付け]

指摘事項をリストで出力してください。

失敗2：一度に全部を構造化しようとする

❌ よくある間違い: 全部署・全業務のマニュアルを一気にドキュメント化しようとして、途中で息切れしてしまう。

⭕ 正しいアプローチ: 最もAIに任せたい1〜2業務から始めて、小さく検証してから範囲を広げる。

なぜ重要か: コンテキスト層の整備はゴールのない全社プロジェクトになりがちです。最初の1業務で「情報を渡すとAIの出力がどう変わるか」を体感できると、社内の納得感も投資判断もぐっとしやすくなります。

失敗3：権限設計を後回しにする

❌ よくある間違い: 「とりあえず便利そうだから」と、全データにアクセスできるMCPサーバーを最初につないでしまう。

⭕ 正しいアプローチ: 読み取り専用か書き込み可か、誰の権限でAIが動くのかを先に設計してから接続する。

なぜ重要か: コンテキスト層はAIに”手足”を与える仕組みでもあるため、権限設計を後回しにすると、意図しないデータ更新や情報漏えいのリスクにつながります。

事例区分: 想定シナリオ
以下は複数の企業のAI導入支援で共通して見られる、典型的な進み方です。

ある企業では、MCPを「便利そうだから」という理由で次々に追加した結果、半年後には「どのMCPが何のためにつながっているか、誰も正確に把握していない」状態に陥りました。棚卸しをしてみると、実際に業務で使われていたのは半分程度で、残りは接続したまま放置されていた、というのはよく聞くパターンです。MCPを増やすたびに「なぜこのMCPが必要か」を一覧化した台帳を持つことをおすすめします。

どこからモデル層（Frontier Tuning型）を検討すべきか

コンテキスト層を整備しても、それだけで全ての課題が解決するわけではありません。次のような状態になってきたら、モデル層の検討に進むタイミングです。

• コンテキスト層を数ヶ月運用しても、同じ種類の判断ミス・修正指示が繰り返される
• 対象業務の実行回数が非常に多く、毎回大量のコンテキスト（社内ルールや過去事例）を渡すコストが無視できなくなってきた
• 反復業務の判断ログ（誰が・どう判断し・どう修正したか）が、十分な量で蓄積されている
• 専用インフラへの投資や、特定ベンダーとの中長期的な連携を許容できる体制がある

逆に言えば、これらの条件が揃っていない段階でモデル層に投資しても、期待した効果は出にくいというのが実務的な見立てです。Frontier Tuning自体も2026年7月時点ではPrivate Preview段階であり、多くの企業にとっては「今すぐ選べる」選択肢というより「数年単位で視野に入れておく」打ち手と捉えるのが妥当です。自社がどちらの段階にいるかは、次のプロンプトで簡易的に整理できます。

自社が「モデル層(自社データで強化学習しモデルを鍛え直す)」を検討すべき段階にあるか判定してください。

以下を教えてください:
1. 対象業務の月間実行回数(概算)
2. コンテキスト層(MCP・ドキュメント整備)を導入してからの期間
3. 同じ種類のミス・修正指示が、コンテキスト層整備後も繰り返されているか
4. 自社インフラ・専任担当者を用意できるか

この4点をもとに、「まだコンテキスト層を伸ばすべき」か「モデル層の検証に進んでよい」かを判定し、理由も添えてください。

よくある質問

Q. モデル層とコンテキスト層は、どちらか一方しか選べないのですか？

A. 排他的な選択ではなく、段階の違いとして捉えるのが実務的です。多くの企業はまずコンテキスト層で成果を出し、それでも解決しない課題が残ったときにモデル層を検討する、という順番になります。

Q. MCPを導入すれば、CLAUDE.mdのようなドキュメント整備は不要になりますか？

A. 逆です。MCPはAIとデータを”つなぐ配管”であり、何を・どんなルールで渡すかを決めるドキュメント設計が土台になります。MCPだけをつないでもドキュメントが整っていなければ、AIが参照する情報の質は上がりません。

Q. Addnessのような目標管理AIを導入すれば、コンテキスト層の整備は完成しますか？

A. 目標・タスクの構造化という一部分をカバーするツールの一つであり、社内規程・過去の判断基準・業務マニュアルなど他の情報源も含めた全体設計が別途必要です。特定のツール導入だけで完結する話ではありません。

Q. Frontier Tuningのようなモデル層のアプローチは、いつから検討すればいいですか？

A. コンテキスト層を数ヶ月運用しても同じ課題が解決しない、かつ対象業務の実行回数や判断ログが十分に蓄積されている場合に検討対象になります。現時点ではPrivate Preview段階であるため、多くの企業にとっては中長期の選択肢として位置づけるのが妥当です。

Q. コンテキスト層の整備だけで、本当に十分な効果が出ますか？

A. 反復性の高い定型業務であれば、コンテキスト層の整備だけで実務上十分な精度に達するケースが多くあります。モデル層が必要になるのは、丁寧にコンテキストを渡しても解決しない”暗黙の勘所”がなお残る場合です。

まとめ：今日から始める3つのアクション

1. 今日やること: 最もAIに任せたい業務を1つ選び、「業務の暗黙知棚卸しプロンプト」で言語化する
2. 今週中: 棚卸しした内容をもとにCLAUDE.md（コンテキストファイル）の雛形を作り、チームに共有する
3. 今月中: MCPで接続するデータ・ツールの優先順位を整理し、権限設計をしたうえで最初の1本を接続する

モデル層とコンテキスト層は、どちらが優れているという話ではありません。まずコンテキスト層で「AIに正しい情報を渡す」土台を作り、それでも足りない部分が見えてきたら、モデル層という次の選択肢を検討する──この順番で進めるのが、多くの日本企業にとって現実的な進み方です。

参考・出典

• Frontier Tuning: Teaching AI to work the way you do — Microsoft 365 Developer Blog（参照日: 2026-07-25）
• Building a hill-climbing machine: Launching seven new MAI models — Microsoft AI（参照日: 2026-07-25）
• What is the Model Context Protocol (MCP)? — Model Context Protocol公式ドキュメント（参照日: 2026-07-25）
• 事業内容 — アドネス株式会社 公式サイト（参照日: 2026-07-25）
• アドネス株式会社、AI行動支援OS「Addness」を正式リリース — PR TIMES（参照日: 2026-07-25）
• AddnessTech/Addness-cli — GitHub公式リポジトリ（参照日: 2026-07-25）

あわせて読みたい:

• コンテキストエンジニアリングとは？プロンプトの次に来る企業AIの新常識 — コンテキスト層の考え方を基礎から解説
• 日本特化MCPサーバー8選｜法令・税務・労務・助成金 — 実際にMCPをつなぐ具体例
• AI導入戦略ガイド — 企業のAI導入を段階的に進めるための全体像

著者: 佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。
100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』（SBクリエイティブ）。
SoftBank IT連載7回執筆（NewsPicks最大1,125ピックス）。

ご質問・ご相談はお問い合わせフォームからお気軽にどうぞ。