Foundation ModelsでMac AIアプリを開発する方法？2026年デプロイガイド

Foundation Models Mac 開発では、最初に小さな評価セットを作り、その結果を基準に端末内モデル、Private Cloud Compute、Core AI、第三者モデルを選んでください。2026年8月25日時点では、macOS 27関連のAPIや権限、既知の問題がテスト期間中に変更される可能性があるため、最初から大規模なAIエージェントを作るのは避けるべきです。

今週の推奨アクションは、要約または構造化抽出を1つ選び、固定入力、期待出力、個人情報を含むかどうか、失敗時の処理を文書化することです。正式版の条件は、macOS 27のリリースノートと最新の開発者向け資料で再確認してください。

このガイドは、既存のMacアプリに要約、抽出、対話、ツール呼び出しを追加したいSwift開発者向けです。ローカル優先のAIエージェントを作る個人開発者や、複数のMac環境で評価と公開手順を整えたいチームにも適しています。

最終更新：2026年8月25日。情報はApple DeveloperのFoundation Models、Core AI、Private Cloud Compute関連資料とmacOS 27リリースノートを照合しています。

開発前：大きなエージェントより検証可能な1タスクを選ぶ

最初の対象には、要約、エンティティ抽出、分類、決まった形式の文章生成が向いています。出力の正解を人間が確認しやすく、モデルの変更による差分も見つけやすいからです。

一方で、複数のツールを自律的に選ぶエージェントから始めると、問題の原因がプロンプトなのか、モデルなのか、ツールの権限なのか分かりにくくなります。入力例と期待結果を先に保存し、成功、部分成功、拒否、タイムアウト、モデル利用不可を区別してください。

先に作る最小評価セット

[ ] 実際の入力に近いサンプルを用意する
[ ] 期待する出力形式を文章または構造体で定義する
[ ] 個人情報、社内情報、機密ファイルの扱いを決める
[ ] 不完全な入力と長い入力を含める
[ ] 誤答時に表示するメッセージを決める
[ ] モデルが利用できない場合の代替経路を決める
[ ] 人間が合否を判断する基準を記録する

この段階で、アプリの価値が「自然な会話」なのか「一定形式の結果」なのかも分けます。後者なら、自由文を返すより構造化出力を優先したほうが、保存や画面表示の不具合を減らせます。

環境準備：macOS 27の正式条件とテスト条件を分ける

macOS 27の開発環境では、OS、Xcode、Swift、対象デバイス、モデルの利用可否を別々に確認します。ベータ版で動いたことを、正式版でも同じ条件が続くとみなしてはいけません。

Swiftでの機械学習とAI開発に必要な準備は、AppleのSwift向け機械学習チュートリアルで確認できます。Foundation ModelsのAPIについては、生成とタスク実行の公式ガイドを基準にしてください。

次の情報をリポジトリに保存しておくと、環境差分を追跡できます。

開発に使ったmacOSとXcodeのバージョン
対象デバイスとモデル利用可否
アプリの署名、サンドボックス、必要な権限
使用したプロンプトと構造化出力の定義
モデルが利用できない場合の画面とログ
ベータ版で確認された制限と、正式版で再確認する項目

macOS 27のリリースノートに記載された既知の問題は、単なる補足ではありません。セッション開始、ストリーミング、ツール実行、権限エラーのどこに影響するかを、評価項目に直接反映させます。

最小実装：Foundation Modelsのセッションから構造化結果へ

最初のMac AI機能は、セッションを1回開始し、固定された入力に対して結果を返すだけにします。Foundation ModelsのLanguageModelプロトコルやセッションの最新仕様は、公式のLanguageModelリファレンスに合わせて実装してください。

概念を確認する最小コードは、次のような形です。実際の型名や利用条件は、使用するSDKの資料に合わせて更新します。

swift

import FoundationModels

let session = LanguageModelSession()

do {
    let response = try await session.respond(
        to: "次の文章を3項目で要約してください：\(inputText)"
    )
    print(response.content)
} catch {
    handleModelUnavailableOrFailure(error)
}

この例で重要なのは、コードの短さではなく失敗を前提にしている点です。モデルが利用できない、入力が長すぎる、生成が中断される、要求された形式を守らない、といった状態を通常の分岐として扱います。

構造化結果が必要なら、自由文を後から解析する設計を避けます。項目名、必須値、空値の扱い、再試行条件を定義し、評価セットで検証します。ストリーミング表示を使う場合も、途中結果を確定データとして保存しないようにしてください。

モデル選択：端末内モデル、Private Cloud Compute、Core AIを比較する

モデル名だけで採用先を決めると、プライバシー、接続性、文脈の長さ、応答の安定性を見落とします。同じ入力と合否基準で比較し、アプリの要件に合う経路を選びます。

端末内モデルを選ぶ条件

端末内モデルは、機密情報を端末外へ送らずに処理したい機能や、接続なしでも動かしたい機能に向いています。ただし、複雑な推論や長い文脈を必要とする処理では、入力の分割や処理内容の縮小が必要になる場合があります。

文脈の管理方法は、端末内Foundation Modelsの文脈ウィンドウに関する技術ノートで確認してください。文書を無制限に渡すのではなく、検索、要約、分割処理を組み合わせます。

Private Cloud Computeへ切り替える条件

より強い推論や大きな文脈が必要で、端末内処理だけでは品質が足りない場合は、Private Cloud Computeを候補にします。Private Cloud Computeの接続方法を確認し、利用資格やデータ送信の説明をアプリ内で明確にしてください。

端末内モデルより常に速い、または常に高品質だと決めつけてはいけません。応答時間、失敗率、機密データの扱い、接続断時の挙動を同じ評価セットで比べます。

Core AIと第三者モデルを使う条件

専門分野の能力、既存のクラウド基盤、複数OSへの展開が重要なら、Core AIや第三者モデルを検討します。Core AIの位置づけは、公式のCore AI案内で確認できます。

第三者モデルを接続する場合は、モデル呼び出しをアプリ本体から分離します。入力の匿名化、認証情報の保管、通信失敗、利用量の制限、応答形式の変換を共通層に集約すると、後から端末内モデルやPrivate Cloud Computeへ切り替えやすくなります。

ツール呼び出し：便利さより権限と取り消しを先に設計する

Mac AIアプリがカレンダー、ファイル、検索、社内APIなどを操作するなら、ツールごとに入力、権限、実行結果、取り消し方法を定義します。Foundation Modelsのツール呼び出しガイドに沿って、モデルに直接強い権限を渡さない構成にしてください。

ファイル削除、送信、購入、設定変更のような操作は、モデルの判断だけで実行しません。対象、変更内容、実行ボタンをユーザーに示し、確認後にアプリ側の決められた関数を呼び出します。

呼び出し回数には上限を設けます。無限ループ、同じ引数の再実行、権限エラー後の連続試行を止め、時間切れなら読み取り専用の結果に降格します。macOS 27の既知の問題がツール呼び出しやセッションに関係する場合は、人工的な確認を挟む回避策も評価対象にします。

評価と環境：互換Macがない場合は隔離した遠隔環境で確認する

Foundation Modelsの評価では、正しさだけでなく、モデル利用不可、接続断、言語差、入力の長さ、システム更新後のプロンプト変化を確認します。評価結果は「成功したか」だけでなく、どのモデル、どのプロンプト、どのOSで実行したかと一緒に保存してください。

ツール呼び出しの評価では、次のケースを最低限用意します。

正常な引数で安全な読み取り処理を行う
必須引数が欠けている
権限がない
ツールが時間内に応答しない
同じ処理を繰り返そうとする
ユーザー確認が必要な操作を要求する
ツールの結果が空、または不正な形式になる

互換性のあるMacを手元に用意できない場合は、隔離された遠隔Mac環境でOSや構成を分けて検証します。ここで必要なのは、単に画面へ接続することではありません。起動時の状態を固定し、秘密情報を持ち込まず、ログと評価結果を回収できることです。

複数のmacOS環境で作業する場合は、先に遠隔Macを使った複数環境の検証方法を確認してください。AIエージェントの権限設計は、Mac AIエージェントの評価項目と組み合わせると、機能評価と安全性評価を分けて管理できます。

公開後：モデル更新をアプリ更新と同じように扱う

端末内モデルの挙動は、OSや提供されるモデルの更新によって変わる可能性があります。公開後も、モデル識別情報、プロンプトの版、ツール呼び出し結果、ユーザーが復旧できたかどうかを記録します。

ログには入力本文をそのまま残さず、必要な場合は匿名化した識別子と結果分類を保存します。機密情報を扱うアプリでは、ログの保存先と保管期間も仕様に含めてください。

macOSまたはモデルが更新されたら、最小評価セットを再実行します。合格基準を満たさなくなった場合は、プロンプト修正、入力分割、端末内モデルからPrivate Cloud Computeへの切り替え、または非AI処理への降格を選びます。モデル応答の評価に関する公式資料も、評価方法を整える際の基準になります。

現在の開発方法が、互換Macを1台だけ共有し、手作業でOSを入れ替え、同じ環境で順番に確認する形なら、待ち時間、状態の混在、再現性の不足が問題になります。高負荷の長期運用や物理ポート操作が必要なら自社保有のMacが適していますが、リリース前の並行評価や短期の互換性確認には、HashvpsのレンタルMacで隔離した環境を用意するほうが、環境を壊さずに検証を進めやすくなります。

まずは最小評価セットを固定し、必要な期間だけ遠隔Macを追加してください。Foundation Models Mac 開発を本番へ進める前に、端末内モデル、Private Cloud Compute、第三者モデルの結果を同じ基準で比較できれば、API変更やモデル利用不可にも回復しやすい構成になります。