0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@kyosuke_hayashi(kyosuke hayashi)

7/7いっぱいで、Fable 5が"使い放題の最強モデル"じゃなくなる。このプロンプートだけ打っておけ

0
Posted at

7/7いっぱいで、Fable 5が"使い放題の最強モデル"じゃなくなる。このプロンプートだけ打っておけ

⚡ 気づいたら手遅れだった、にしたくない

7/7を境に、Fable 5は「気軽に投げていいモデル」じゃなくなる。

Anthropicの公式発表はこうだ。7/1の復旧から7/7まで、週次利用枠の最大50%まで含まれる形で使える。7/8からは従量課金のusage credits経由になる（時刻は非公開だが、米国基準の日付なので日本時間だと7/8の午前中には切り替わっている可能性が高い）。「トークン単価を気にせず投げていい期間」は、今日（7/6）と明日（7/7）の2日間で終わる。

これ、静かに一番怖いパターンだと思ってる。「まだ大丈夫」と思ってるうちに枠を溶かして、気づいたら明日の夜、一番聞きたかった相談ができなくなってる。だから今日のうちに、Fable 5にしかできない仕事を全部終わらせて、日常運用は他モデル＋Skillsで再現できる形に落とし込む。そのために実際に自分が投げたプロンプトを、そのまま公開する。

🛠️ 開発用途（Web開発、GitHub運用、Cursor/Claude Code/MCP、技術ブログ、業務効率化、資格学習）に寄せて書いてるけど、変数部分（用途・目標・プロジェクト名）を書き換えれば誰でもそのまま流用できる。

🧠 使ったプロンプート（コピペしてそのまま投げていい）

以下のプロンプトをXで共有するためのNote記事を作成したい。

7/7以降、ProプランのサブスクリプションではFable5が利用できなくなります。
そのため、それまでにFable5でしか実現できていないワークフローや能力を、
他モデルでも可能な限り再現・代替できるよう準備したいと考えています。
以下の観点で、優先度を付けながら具体的に提案してください。

前提
・現在利用しているプロジェクトやチャット内容を考慮すること。
・私の主な用途は以下です。
  ・（例）JavaScriptを用いたWebRTC開発
  ・（例）GitHubを活用した開発
  ・（例）Cursor・Claude Code・MCPの活用
  ・（例）技術ブログ執筆
  ・（例）業務効率化・AI活用
  ・（例）学習支援（資格試験など）
・Fable5固有の強みが失われることを前提に、それを補う方法を考えてください。

提案してほしい内容

1. Skillsとして事前に作成しておくべきもの
今後も他モデルで使い回せるようなSkillsをできるだけ具体的に提案してください。
それぞれについて「作る価値」「活用シーン」「優先度」「具体的なSkill設計」まで
提案してください。

2. Fable5のうち今しかできないこと
Fable5だからこそ今のうちにやっておいた方が良いことを提案してください。

3. ネット上で話題になっている活用法
Web検索を行い、Reddit・X・GitHub・ブログ記事・AIコミュニティなどから
「Fable5終了前にやっておくべきこと」「Skillsの便利な使い方」
「他モデルへの移行テクニック」について最新の情報を調査し、
参考になるアイデアをまとめてください。

4. 私向けに最適化した提案
私の現在の利用状況を踏まえ、「これは絶対に今作っておくべき」というものを
優先順位付きで10〜20個提案してください。理由や期待できる効果も説明してください。

5. 移行ロードマップ
7/7までに実施すべき作業を、「今日やること」「明日やること」「最終確認」のように
時系列で整理し、短期間で最大限Fable5の恩恵を受けられる計画を作成してください。

単なる一般論ではなく、私の利用履歴・プロジェクト・技術スタックを踏まえて
具体的に提案してください。また、Web上の最新情報やコミュニティで評価されている
アイデアも積極的に取り入れてください。

これが効く理由、4つ

  • 「モデルの強みが失われる」という前提を最初に置くから、一般論じゃなく"代替手段"だけが返ってくる
  • ゴールを「Skillsとして残す」に固定してるから、その場限りの提案で終わらず資産化される
  • Web検索の指示を仕込んでるから、今この瞬間のコミュニティの議論も混ざってくる
  • 「今日／明日／最終確認」で時系列を切ってるから、ふわっとしたToDoじゃなく今夜動ける計画になる

📈 実際に返ってきた提案（一部抜粋）

自分のケース（Web開発、GitHub運用、X運用、技術ブログ、資格学習）で投げてみたら、こう返ってきた。長いので構成と一部だけ切り出す。

🛠️ 1. 今のうちに"武装"しておくべきSkills

Skillsは「フォルダ＋SKILL.md」という構造。モデルが変わっても（Sonnet 5でもOpus 4.8でも）そのまま持ち運べる資産になる。Fable 5が持ってる「長期記憶・大規模文脈理解」という強み、それをSkillsという形で外部化しておくのが今回の本丸。

以下、自分の用途に直結するものを優先度順に紹介します（実際に返ってきた回答の要約です）。

🥇 優先度: 最高

① WebRTCデバッグ・実装Skill

  • 作る価値: WebRTC特有の落とし穴（ICE候補の扱い、SDPネゴシエーション、TURN/STUNの設定ミス、Safari/Chromeの実装差異など）は、汎用モデルだと毎回同じ説明をゼロからさせられがちです。これを一度体系化すれば、Fable 5でなくても再現性の高い支援が受けられます。
  • 活用シーン: 接続不安定の原因切り分け、SDP/ICEログの読み方、getUserMedia周りのブラウザ差異対応、新規実装時のアーキテクチャ相談。
  • 具体的なSkill設計:
    • SKILL.mdにWebRTCの接続確立フロー（Signaling→ICE→DTLS→SRTP）をチェックリスト化
    • よくあるエラーパターン集（ICE connection failed、m-line順序不一致など）と切り分け手順をreference/common-errors.mdに分離
    • 過去に自分が踏んだ罠をgotchas.mdとして追記していく運用にする（Fable 5に「今回のプロジェクトで学んだ罠を要約して」と頼んで種を作るのが効率的）

② 技術ブログ執筆Skill

  • 作る価値: 構成・トーン・読者層（日本のITエンジニア）を固定した執筆補助を毎回ゼロから説明せずに済む。
  • 活用シーン: WebRTC技術解説、個人開発の開発記、AI活用ノウハウ記事。
  • 具体的なSkill設計:
    • 導入・課題提示・実装・学びの4部構成テンプレ
    • コードブロックの言語表記ルール、見出し階層のスタイルガイド
    • 「結論から書く」「専門用語は初出時に一言補足」などの文体ルール

🥈 優先度: 高

③ README/ドキュメント生成Skill

  • 作る価値: 複数サービスにまたがるGitHub運用では、README/ドキュメントの陳腐化が起きやすい。生成ルールを固定化しておけば更新コストが下がる。
  • 活用シーン: 新機能追加時のREADME更新、DB/APIスキーマ変更時のドキュメント反映。
  • 具体的なSkill設計:
    • 自分のプロジェクト特有の構成（DBテーブル定義、CI/CDフロー）をテンプレの雛形として組み込み
    • Mermaid記法でのアーキテクチャ図生成ルールを含める

④ コードレビューSkill（GitHub Actions/Supabase/Next.js特化）

  • 作る価値: 自分のプロジェクト固有の設計原則（外部通信の分離方針、DBアクセス権限の最小化方針など）を、レビュー基準として固定できる。
  • 活用シーン: PRレビュー、Claude Code / エージェントが生成したコードの検証。
  • 具体的なSkill設計:
    • チェック項目：外部API通信を許可された経路だけで行っているか／DB接続の権限が過大でないか／型の扱いが安全か
    • 過去に事故った変更パターン（設定テーブルの想定外の複数行化など）を再発防止チェックとして明記

⑤ 設計レビュー・技術判断Skill

  • 作る価値: Fable 5の強みである「長期文脈での一貫した設計判断」を、判断基準の言語化によって部分的に代替。
  • 活用シーン: 新機能の技術選定、アーキテクチャの意思決定（構成A vs 構成Bのトレードオフ整理など）。
  • 具体的なSkill設計:
    • 過去の判断ログ（なぜその構成を選んだか、なぜ特定のアプローチを避けたか）をdecisions.mdとして蓄積
    • 新しい判断のたびにこのファイルを参照させ、一貫性を担保

🥉 優先度: 中

⑥ 基本情報技術者試験 学習支援Skill

  • 作る価値: 出題範囲・頻出分野・自分の弱点分野を固定しておけば、モデルが変わっても同じ精度で問題演習・解説が受けられる。
  • 活用シーン: 通勤時間などでのスキマ学習、過去問の解説依頼。
  • 具体的なSkill設計:
    • 出題分野（テクノロジ系/マネジメント系/ストラテジ系）ごとの理解度メモ
    • 間違えた問題のログをweak-points.mdに蓄積し、復習優先度を自動判定

⑦ 業務日報・作業ログ生成Skill

  • 作る価値: 個人開発の進捗を振り返りやすくし、技術ブログのネタ元にもなる。
  • 活用シーン: Claude Code / エージェントの実行結果をベースにした日次サマリー生成。
  • 具体的なSkill設計:
    • GitHubのコミットログ・PRから自動で「今日やったこと」を抽出するフォーマット
    • ブログネタ候補にフラグを立てる項目を追加

⚡ 2. Fable 5にしかできない仕事、今夜中に終わらせる

Skillsで代替しきれない、モデル自体の地力に依存する作業は今のうちに片付けておく。

  1. メインプロジェクトの全体アーキテクチャ分析＋改善提案：リポジトリ全体をFable 5に読み込ませ、既存の実装方針の改修案や、次に作りたい機能の設計骨子を作ってもらう。長期文脈と自己検証能力が効くタスクです。
  2. 上記①〜⑦のSkillのたたき台一括生成：Fable 5は「これまでの会話・プロジェクトの蓄積から要点を抽出する」作業に強みがあるため、各Skillの初稿をまとめて作らせるのに向いています。
  3. 中長期の運用プレイブックの精度検証：自分が立てた目標達成までの週次マイルストーンや判断基準を、長期プランニング能力の高いFable 5に一度レビューさせておく。
  4. 将来実装予定の機能の設計書作成：「あとで実装しよう」と後回しにしている機能について、今のうちに詳細設計書を作っておけば、実装フェーズでは安価なモデルに任せられる。
  5. decisions.md・gotchas.mdの初期構築：これまでの会話履歴を振り返らせて、「なぜその設計にしたか」を言語化・ファイル化する棚卸し作業。これは今しかできない「記憶の外部化」そのものです。

🌏 3. 海外・国内で今起きている議論

Web検索で拾った最新の議論、まとめるとコミュニティの結論はほぼ一致してる。

  • モデルの役割分担が定着しつつある：Sonnet 5が実装・調査の一次対応、Opus 4.8がレビュー・検証、Fable 5は「長期プランニングや高難度の移行作業」だけに絞って使う、という3層構成の運用が主流になりつつあります。日常タスクにFable 5を使うのは「トークンの無駄遣い」という指摘が目立ちます。
  • Skillsは「小さく始めて育てる」のが鉄則：Anthropicの公式ガイダンス、および実務者の記事の双方で、最初から完璧なSkillを作ろうとせず、数行のメモと1つの失敗パターンから始めて、使うたびに追記していくアプローチが推奨されています。
  • SKILL.mdのdescriptionは「トリガー文」として書く：「このSkillは〇〇をする」ではなく「〇〇するときにこのSkillを使う」という書き方にすることで、自動発火の精度が上がるとされています。
  • CLAUDE.md／SKILL.mdの二層構造：プロジェクト全体のルールはCLAUDE.mdに、特定タスクの手順はSkillsに分離する構成が、コンテキスト消費を抑えつつ精度を保つベストプラクティスとして紹介されています。
  • usage creditsの枯渇に備える：7/7以降の高コスト化に備え、キャッシュ利用（プロンプトキャッシュで最大90%割引）やBatch API活用でコストを抑える工夫が複数の記事で共有されていました。

📈 4. 自分向けに返ってきた優先順位、ガチで14個

自分の利用状況（Web開発、X運用、技術ブログ、資格学習）を踏まえると、「今のうちに絶対やっておくべきこと」はこの順番でまとまった。

# やること 理由・期待効果
1 Fable 5でメインプロジェクト全体のアーキテクチャレビューを実施 既存の実装方針の改修や新機能の設計を今のうちに前倒し
2 本業領域のデバッグ・実装Skillの作成 本業の生産性がモデル依存にならないようにする、最も汎用性の高い投資
3 decisions.md（設計判断ログ）の棚卸し 「なぜその設計にしたか」等の暗黙知を今のうちに文書化
4 技術ブログ執筆Skillの作成 ブログ執筆の再現性を確保し、Fable 5以外でも一定品質を担保
5 中長期プレイブックのFable 5による最終レビュー 目標達成までのマイルストーンの精度を、長期プランニングに強いうちに検証
6 README/ドキュメント生成Skillの作成 継続開発でのドキュメント陳腐化を防ぐ
7 コードレビューSkillの作成 エージェントの生成物を安価なモデルでも一定精度でチェック可能に
8 将来実装予定の機能の詳細設計書をFable 5で作成 実装フェーズは安価なモデルに委任できる状態にしておく
9 資格学習支援Skillの作成 学習を日常タスク化し、モデル切り替えの影響を受けにくくする
10 gotchas.md（躓きポイント集）の作成 過去の会話履歴から抽出、今しかできない知識の外部化
11 設計レビューSkillの作成 技術選定の一貫性を、モデルが変わっても保つための判断基準の言語化
12 プロンプトキャッシュ・Batch API活用方針の検討 7/8以降のusage credits化に備えたコスト最適化
13 業務日報生成Skillの作成 開発ログの蓄積を自動化し、ブログネタの供給源にする
14 既存の運用マニュアル・instructionのSkill化 個別ファイルとして持っていた手順書をSkill形式に再構成し、他モデルからも呼び出せるようにする

🧠 5. 残り時間の行動計画（7/6〜7/7）

Fable 5がProプラン内で実質無料枠を使えるのは7/7まで。残り時間、正直もうそんなにない。

📅 今日（7/6・日）：棚卸しとSkillのたたき台生成

  • Fable 5にメインリポジトリ全体を読み込ませ、アーキテクチャレビュー＋改修案を出させる
  • 過去の会話履歴（設計判断、本業領域の躓きポイント、X投稿の勝ちパターン）を棚卸しし、decisions.md / gotchas.md の初稿を作成
  • 優先度「最高」の2つのSkill（本業デバッグ／技術ブログ執筆）のSKILL.md初稿をFable 5に生成させる
  • 将来実装予定の機能の詳細設計書のドラフトを作成

📅 明日（7/7・月）：最終追い込みとカットオフ当日対応

  • 残りのSkill（README生成／コードレビュー／設計レビュー／資格学習／業務日報）を仕上げる
  • 中長期の運用プレイブックをFable 5に最終レビューさせ、マイルストーンの精度を検証
  • 各SkillをSonnet 5 / Opus 4.8で試運転し、「Fable 5と比べて何が落ちるか」をその場でメモ→Skillに追記（この日のうちにやらないと比較が難しくなる）
  • 週次利用枠の残量をダッシュボードで確認し、枠内に収まるよう作業の優先順位を調整

✅ 最終確認（7/7中）

  • 作成した全Skillが.claude/skills/または該当ディレクトリに配置され、Claude Codeから発火することを確認
  • decisions.md・gotchas.mdがリポジトリにコミットされていること
  • 7/8以降の運用ルール（Sonnet 5=実装、Opus 4.8=レビュー、Fable 5=usage credits消費してでも使うべき高難度作業のみ）を自分の中で明文化しておく

Fable 5がなくなるわけじゃない。「気軽に投げられなくなる」だけだ。だからこそ、今日と明日でSkillsという形に知見を外部化しておけば、モデルが何であっても同じ質のアウトプットを再現できる。残り時間、悔いのない使い方をしてほしい。⚡

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?