NotionではFable 5を使おう：チームの知識を深く扱うAIワークフロー設計

Notion AI のモデル選択画面に、Claude Fable 5 が表示されるようになりました。

筆者の手元の Notion チャットでも Fable 5 を選べることを確認しています。Notion 公式の発信でも、Fable 5 は Business / Enterprise プラン向けに提供され、複雑な Custom Agents や Workers に使いたいモデルとして紹介されています。

結論から言うと、Notion では Fable 5 を使うべきです。

ただし、「全員の既定モデルにする」という意味ではありません。Fable 5 は Anthropic 側で入力と出力が30日保持される Mythos-class モデルです。Notion 側でも、そのために管理者が明示的に有効化する opt-in になっています。

だからこそ、使い方を決めてから使うべきです。

通常の短い相談や文章整理は Auto や他モデルで十分です。一方で、Notion に蓄積された議事録、仕様、顧客メモ、タスク、プロジェクトDBを横断しながら、深く考える仕事には Fable 5 が向いています。

まず確認した事実

今回確認できた事実は、次の通りです。

Notion 公式 LinkedIn は、Fable 5 が Notion で利用可能になり、Business / Enterprise プランで提供されると説明しています。
同じ投稿で、Fable 5 は Anthropic 側のデータ保持があるため opt-in であり、管理者が Settings → Notion AI から有効化すると説明されています。
Notion Help Center は、Enterprise ワークスペースでは既定で LLM provider の zero data retention を使う一方、データ保持を伴うAI機能では管理者向けの設定を用意し、既定では無効にすると説明しています。
Anthropic のドキュメントでは、Claude Fable 5 と Mythos 5 は30日データ保持の対象で、zero data retention では利用できない Covered Models とされています。
Notion Custom Agents は、Claude、GPT、Gemini、Grok など複数モデルを選択でき、モデル選択で速度、コスト、品質を調整できるとされています。
Notion credits では、読む情報量、ステップ数、実行頻度、モデル選択が消費量に影響します。高度なモデルほど、複雑な推論を扱うため credit 消費が大きくなる前提です。

ここで大事なのは、「Fable 5 が強い」だけで判断しないことです。

Notion は、チームの仕事の文脈が集まる場所です。だから Fable 5 のような深く考えるモデルを置く価値があります。一方で、そこには顧客情報、社内判断、未公開の事業計画も入りやすい。強いモデルほど、データ境界と用途を先に決める必要があります。

NotionでFable 5を使う意味

Fable 5 は、短い一問一答よりも、長く複雑な文脈を扱う仕事に向いたモデルです。Anthropic は、Fable 5 を「要求の高い reasoning と長期的な agentic work」のためのモデルとして説明しています。

この性格は、Notion と相性がよいです。

Notion には、チャット単体にはない文脈があります。

プロジェクトのタスクDB
会議メモ
顧客ヒアリング
仕様書
ナレッジベース
稟議や意思決定メモ
Slack や外部ツールから接続された情報
Custom Agents の手順と実行履歴

Fable 5 の価値は、この文脈をまとめて読み、論点を整理し、次の行動に落とすところにあります。

たとえば「この議事録を要約して」なら、Fable 5 である必要は薄いです。

しかし、「直近3回の商談メモ、プロジェクトDB、既存提案書、未解決Issueを見て、次の提案の論点、リスク、タスク分解、担当割りを作って」となると、話が変わります。

こういう仕事は、ただ文章を作るだけではありません。複数の情報をつなぎ、前提のズレを見つけ、実行可能な粒度まで分解する必要があります。Notion で Fable 5 を使う意味は、まさにここにあります。

使うべき仕事、使わなくてよい仕事

Fable 5 を Notion で使うなら、まず仕事を分けるべきです。

仕事	Fable 5 を使う理由	出すべき成果物
複数議事録からの提案設計	顧客文脈、課題、未決事項を横断して整理できる	提案骨子、リスク、次回確認事項
大きなプロジェクトの棚卸し	タスク、仕様、決定履歴をまとめて構造化できる	子タスク、依存関係、完了条件
ナレッジベース改善	重複、矛盾、不足を見つけやすい	統合案、更新優先度、ページ構成
Custom Agent の設計	手順、権限、トリガー、例外処理をまとめて考えられる	Agent instructions、アクセス範囲、検証手順
週次・月次レポート	多数のDBやメモから意味のある変化を抽出できる	経営向けサマリ、課題、次アクション
AI仕様駆動開発のIssue整理	背景、受け入れ条件、検証観点を一気通貫で作れる	実装指示、テスト観点、人間判断ポイント

逆に、次の仕事では Fable 5 を使わなくてよい場面が多いです。

短い文章の言い換え
1ページだけの要約
軽いアイデア出し
既に決まった手順の実行
機密度が高く、30日保持を許容できない情報の処理
credit 消費を抑えたい高頻度の自動実行

Fable 5 は「毎回使う高級モデル」ではなく、「複雑な仕事を構造化するための深いモデル」と考えるのがよいです。

30日保持を前提に、使ってよいデータを決める

Fable 5 を使う前に、最初に決めるべきなのはデータ境界です。

Notion の説明では、Notion と AI Subprocessors は既定で顧客データをモデル学習に使わない契約になっています。一方で、Fable 5 は Anthropic 側で30日間のデータ保持が必要です。

ここは混同しない方がよいです。

「学習に使われない」と「外部 provider に一定期間保持されない」は別の話です。

Fable 5 を有効化するなら、チーム内で少なくとも次の分類を作るべきです。

分類	Fable 5 利用	例
公開済み・社外公開前提	使ってよい	公開ブログ、公開資料、一般的なサービス説明
社内ナレッジ	条件付きで使う	業務手順、一般的な会議メモ、社内FAQ
顧客別情報	契約と内容を確認して使う	商談メモ、提案書、顧客課題、見積もり前提
高機密情報	原則使わない	未公開M&A、個人情報、認証情報、法務・医療・金融の機微情報

この分類を作らずに「便利だから Fable 5」を始めると、後から運用が苦しくなります。

Notion で Fable 5 を使う価値は高いです。ただし、Fable 5 を使えるページ、使えるDB、使えるAgentを先に決めることが前提です。

管理者はopt-inとcreditをセットで見る

Fable 5 は opt-in です。これは制限ではなく、チーム運用の入り口だと考えるべきです。

管理者は、単に Settings → Notion AI で有効化して終わりにしない方がよいです。

有効化前に、次を決めておくと安全です。

Fable 5 を使ってよい業務カテゴリ
Fable 5 を使ってよいページ、DB、Agent
使ってはいけないデータの例
Custom Agents の作成者と編集権限
Web access を使うかどうか
Notion credits の上限と監視担当
出力を人間が確認するタイミング

Notion の Custom Agents は、アクセス範囲を明示的に付与する設計です。特定のページやDBだけを参照させることも、広い範囲を見せることもできます。

Fable 5 を使う Agent では、広く見せるほど便利になりますが、同時に credit とデータリスクも増えます。

まずは、1つか2つの業務で小さく始めるのが現実的です。たとえば「週次のプロジェクト棚卸しAgent」「商談メモから提案論点を作るAgent」のように、対象DBと成果物が明確なものから始める。

そのうえで、Notion credits dashboard で実際の消費を見ながら、対象を広げるのがよいです。

まず作りたいFable 5用テンプレート

Notion で Fable 5 を使うなら、プロンプトを都度書くのではなく、テンプレート化しておくと再利用しやすくなります。

たとえば、プロジェクト棚卸しなら次のようにします。

目的:
このプロジェクトの現状を、次に動ける形に整理してください。

参照してよい情報:
- このプロジェクトDB
- 直近の議事録
- 関連する仕様ページ
- 未完了タスク

出してほしいもの:
1. 現在のゴール
2. 完了済みのこと
3. 未完了タスク
4. ブロッカー
5. 判断が必要な論点
6. 次に切るべき子タスク
7. 人間が確認すべきリスク

制約:
- 機密度の高い個人情報は引用しない
- 推測は「推測」と明示する
- 不明点は断定せず、確認質問として出す
- 実行する前に、まず計画だけを出す

ポイントは、Fable 5 に「答え」だけを求めないことです。

Fable 5 に任せたいのは、見落としの発見、構造化、判断材料の整理です。実行そのものは、人間が確認してから Agent や別モデルに渡してもよい。

Notion は、こうしたテンプレートをページやAgent instructionsとして残しやすい場所です。だから、Fable 5 の出力を一回限りのチャットで終わらせず、チームの手順に変えられます。

チームで導入するなら、実行前の設計に置く

自社の Notion に議事録、仕様、タスク、顧客メモが集まっているなら、Fable 5 は「すぐに何かを実行するモデル」よりも、「実行前に仕事を整理するモデル」として使うのが現実的です。

たとえば、新規施策、システム改修、営業提案、社内ナレッジ整備の前に、Notion 上の資料をもとに次を整理してもらいます。

目的
非対象範囲
判断未決事項
依存関係
リスク
受け入れ条件
検証方法
実行担当者や外部Agentに渡す指示

この整理ができれば、人間は判断が必要な箇所だけを確認し、その後の実行を Notion Custom Agents、Claude、Cursor、Codex などに渡しやすくなります。

Notion 3.6 では、Claude や Cursor などの External Agents を Notion から扱う方向性も示されています。Notion は、AIの作業結果をチャットの外に出し、タスク、ページ、DB、議事録と接続する場所になりつつあります。

同じ Notion 3.6 では、Notion Agents がインタラクティブな HTML ブロックを作れるようになりました。ここでいう HTML 出力は、ページ全体を HTML ファイルとして書き出す話ではありません。Notion のドキュメント内で動く小さなUIを、Agent が作れるようになったということです。

これは Fable 5 の使い道とも相性がよいです。長い文脈を読ませて終わりではなく、たとえばROI計算ツール、理解度クイズ、プロジェクトのリスク確認表、簡易シミュレーターのような「その場で使える成果物」にできます。Notion の中に残るので、チームメンバーが後から使い、必要に応じてAgentに改善させられます。

読者が自社で試すなら、最初から大きな自動化を狙うより、「会議メモから次アクションと確認事項を作る」「プロジェクトDBから未解決リスクを出す」「仕様メモを実装Agent向けの指示に整える」といった小さな型から始めると扱いやすくなります。

そう考えると、Fable 5 は「Notion内で何かをちょっと相談するモデル」ではありません。

チームの情報を読み、仕事を分解し、次の実行に渡すための設計モデルです。

まとめ

Notion で Fable 5 が使えるようになったことは、かなり大きな変化です。

Fable 5 は、単体チャットでも強いモデルです。しかし、Notion の中で使うと、価値はさらに分かりやすくなります。Notion には、チームの文脈、意思決定、タスク、議事録、ナレッジが集まっているからです。

ただし、Fable 5 は30日データ保持を伴うモデルです。管理者が opt-in する設計になっているのは、そのためです。

だから、答えはこうです。

Notion では Fable 5 を使いましょう。

ただし、何でも Fable 5 に投げるのではなく、複雑な仕事、長い文脈、チームで再利用したい判断に使う。機密情報や高頻度の軽い処理には使わない。管理者は、使ってよいデータ、Agent、credit、レビュー境界を決めてから有効化する。

Fable 5 の強さを、単発の賢い回答で終わらせるのはもったいないです。

Notion のページ、DB、Agent、External Agents と組み合わせて、チームの仕事の流れに組み込む。そこまでやると、Fable 5 は「高性能モデル」ではなく、チームの知識を深く使うためのワークフローになります。