昼休みにニュースを追っていたら、Claude Fable 5 が戻った話が流れてきました。
「高性能モデルが復活した」で終わらせたくなるのですが、業務で AI を使う側に効くのはそこではないです。僕が見るべきだと思ったのは、6月12日に止まり、7月1日に戻り、しかも7月7日までは一部プランで週次上限の最大50%までという条件つきだった点です。
つまり、AIモデルは機能表だけでなく「今日使えるか」「上限つきか」「代替先があるか」まで見ないと、現場の自動化に組み込めません。
この記事では、API を叩く前段に置く小さな台帳チェックを Python で作ります。モデルが急に止まったり、上限つきで戻ったりしたときに、どの業務が危ないかを先に見つけるためのものです。
何が起きたかを業務目線で見る
Guardian は、Fable 5 が2週間超の停止後に顧客向けアクセスを戻したと報じています。Business Insider は、Pro / Max / Team / 一部 Enterprise では7月7日まで週次上限の最大50%まで使え、その後は usage credit 方式になると説明しています。
このニュースから持ち帰るべき実務ポイントは、モデルの優劣ではありません。
「昨日まで使えなかったモデルが、今日から条件つきで戻る」ことがある。ここです。
たとえば競合調査の要約、商談メモの整形、問い合わせ返信の下書き。こういう業務は、モデル名をコードに直書きしていると上流の事情をそのまま受けます。人間から見ると「いつもの自動化が急に遅い」「上限に当たった」「品質が変わった」に見える。
ここ地味に効きます。障害対応のように大げさな仕組みを作らなくても、業務ごとに主モデル、代替モデル、上限条件を1枚の表にしておくだけで、慌て方がかなり変わります。
台帳に入れる列
最初から立派な管理画面はいりません。CSV で十分です。
モデル側の台帳には、最低限この列を持たせます。
| 列 | 例 | 見る理由 |
|---|---|---|
| model | Fable 5 | コードや手順書と照合する |
| status | restored | available / restored / disabled を分ける |
| limited_until | 2026-07-07 | 期間限定の上限を見落とさない |
| weekly_included_ratio | 50 | 通常枠の何%まで使えるかを見る |
| after_limit | usage credits | 上限後の扱いをメモする |
業務側の台帳には、主モデルと代替モデルを持たせます。
| 列 | 例 |
|---|---|
| workflow | 競合料金ページの差分要約 |
| primary_model | Fable 5 |
| fallback_model | Sonnet 5 |
| criticality | high |
この図で見ると、やることは「ニュースを読む」ではなく「業務ごとの分岐を決める」です。
PythonでWARNを出す
下のコードは、2つの CSV を読み、今日時点で危ない業務を WARN にします。外部ライブラリは使いません。
import csv
from io import StringIO
from datetime import date, datetime
models_csv = """model,provider,status,available_from,limited_until,weekly_included_ratio,after_limit,business_use
Fable 5,Anthropic,restored,2026-07-01,2026-07-07,50,usage credits,重い調査レポート
Sonnet 5,Anthropic,available,2026-06-30,,100,included,日次の下書き
既存モデルA,Other,available,,,100,included,定型文生成
"""
workflows_csv = """workflow,primary_model,fallback_model,criticality
競合料金ページの差分要約,Fable 5,Sonnet 5,high
商談メモの要約,Fable 5,Sonnet 5,medium
問い合わせ返信のたたき台,Sonnet 5,既存モデルA,high
"""
today = date(2026, 7, 2)
def rows(text):
return list(csv.DictReader(StringIO(text)))
models = {r["model"]: r for r in rows(models_csv)}
workflows = rows(workflows_csv)
def parse_date(value):
return datetime.strptime(value, "%Y-%m-%d").date() if value else None
def judge(workflow):
primary = models.get(workflow["primary_model"])
fallback = models.get(workflow["fallback_model"])
if primary is None:
return "NG", "主モデルが台帳にありません"
if primary["status"] not in {"available", "restored"}:
return "NG", "主モデルが利用不可です"
limited_until = parse_date(primary["limited_until"])
ratio = int(primary["weekly_included_ratio"] or 0)
if limited_until and today <= limited_until and ratio < 100:
if fallback and fallback["status"] in {"available", "restored"}:
return "WARN", f"{limited_until}まで週次上限{ratio}%枠。超過時は{workflow['fallback_model']}へ"
return "NG", "上限付きなのに代替モデルが使えません"
return "OK", "通常運用"
print("| 業務 | 判定 | メモ |")
print("| --- | --- | --- |")
for workflow in workflows:
status, note = judge(workflow)
print(f"| {workflow['workflow']} | {status} | {note} |")
手元で実行すると、こう出ました。
| 業務 | 判定 | メモ |
| --- | --- | --- |
| 競合料金ページの差分要約 | WARN | 2026-07-07まで週次上限50%枠。超過時はSonnet 5へ |
| 商談メモの要約 | WARN | 2026-07-07まで週次上限50%枠。超過時はSonnet 5へ |
| 問い合わせ返信のたたき台 | OK | 通常運用 |
今日これを動かしてみて、思ったより大事だったのは disabled だけを見ないことでした。復活しているのに WARN になるケースがある。Fable 5 のように「戻ったけど上限つき」という状態は、現場ではむしろ見落としやすいです。
2段目で見るべき落とし穴
このチェックは、モデルが使えるかどうかだけを見ています。実運用ではもう1段あります。
1つ目は、代替モデルに逃がしたときの品質差です。競合料金ページの差分要約なら、少し短くなる程度で済むかもしれません。契約文面のレビューや障害報告の要約なら、代替モデルに回す前に人の確認を挟んだ方がいい。だから criticality を入れておきます。
2つ目は、上限の消費が業務単位では見えないことです。週次上限50%と書いてあっても、営業部の全員が同じ枠を食うのか、ユーザーごとなのか、契約ごとなのかで対策が変わります。ここは各社の契約条件を見て、自社の台帳に「誰の枠か」を1列足すのが現実的です。
僕なら、最初はスプレッドシートで持ちます。情シスや開発だけが見る台帳にすると、営業企画側が「どの作業を落としていいか」を判断できないからです。WARN が出た業務だけ朝会で確認する。そのくらいの軽さで十分回ります。
現場でどう使うか
Fable 5 復活のニュースは、AI の性能競争として読むより、上流モデルの可用性が業務フローに入ってきた例として読む方が実務に効きます。強いモデルを使うほど、停止、上限、ルーティング変更の影響も大きくなります。
まずはモデル名をコードに直書きしている業務を3つだけ拾って、主モデルと代替モデルを書き出す。次に、上限つきのモデルを WARN にする。ここまでなら30分でできます。高機能な監視より先に、この小さい台帳を置く。モデルが戻った日に慌てないための、いちばん安い保険です。