こんにちは、みのり（@minori_aimama）です。本業・育児の合間にAI×ブログ副業に挑戦中です。
今日は、期間限定で使えるようになったClaude Fable5で、AIブログ運営のOSを見直した話を書きます。
Xでは「上位モデルは、日々の作業より今後の資産になることに使った方がいい」という話を見かけました。
ただ、いざ自分のブログ運営に当てはめると、何をどう見直せばいいのかが分からない。
そこで今回は、まずファイル診断を試し、そこから本丸として、AIの記憶ファイル、読み込み構造、改善候補、4サイトの方向性を順に見直しました。
Fable5でAIブログ運営のOSを見直す。でも、具体的に何をする？
私はいま、Claude Codeを使って複数のブログ運営のフローを組んでいます。スキルや手順をAIに渡して、記事制作や日々の運用を回す形です。
その仕組み全体を、期間限定のFable5に見直してもらおう。方向性はそう決めました。せっかく強いモデルが触れるのに、いつもの記事書きに溶かすのはもったいない。
ただ、いざ手をつけようとすると、止まりました。
設計の見直しって、具体的に何を見るの？
資産になる使い方って、何を渡せばいいの？
総点検って、どの資料を、どの角度で見てもらうの？
方向性には納得しているのに、最初の一歩が分からない。最初から完璧な計画があったわけではありませんでした。
なので、まずは範囲が見えやすいところから試すことにしました。いきなり業務全体の棚卸しを任せるのは、さすがに大きすぎる。まずはファイル診断だけやらせてみて、Fable5がどこまで自走するのかを見てみよう。 そういう順番です。
試運転｜まずはファイル69本の一斉診断をやらせてみた
最初にやらせたのは、運用ファイル69本の一斉診断でした。
内容の重複、メタ情報、参照切れ、構造、文字コード、命名。このあたりの観点でまとめて見てもらいました。
面白かったのは、私が「このサブエージェントを使って」と細かく指示したわけではないこと。Fable5は自分で必要な資料を読み、必要に応じてサブエージェントも勝手に使っていました。
さらに驚いたのが、実装へ進もうとした段階の動き。サブエージェントの診断結果に自分で違和感を持って、実ファイルを確認し直していたんです。
結果はこうでした。
| 項目 | 数 |
|---|---|
| 一斉診断したファイル | 69本 |
| 重要度「高」とされた指摘 | 8件 |
| そのうち誤検出だったもの | 5件 |
重要度「高」の8件のうち、5件が誤検出。広く拾うだけなら、下位モデルやサブエージェントでもできます。でもFable5は、実装前に「この指摘、本当に直していいのか？」と立ち止まって、実ファイルに戻って精査していました。
指摘をたくさん出すことより、直す前に違和感へ気づけること。ここが最上位モデルの価値なんだなと思いました。
ただ、Fable5がすべて自力で気づいたわけでもありません。「ほぼ全文が重複している」という、ちょっと誇張気味の指摘が1件あって、そこは私の違和感で「いや、それは言いすぎでは」と訂正しました。
最上位モデルでも、AIの裏取りと人間の目の二段構えは要る。これは覚えておこうと思います。
そしてこの診断で、もうひとつ分かったことがありました。並列で走らせるエージェントは、広く拾える分だけ誤検出も多い。長く自走させたいなら、渡す前の整理が効く。 この学びが、次の下ごしらえに直結しました。
怖くなったので、本丸の前にOpusで下ごしらえした
一斉診断でよく分かったのは、Fable5は思った以上に自走できる、ということでした。
でも、自走できると分かったからこそ、逆に少し怖くなりました。Fable5が頼りなかったから下ごしらえしたのではなく、任せると広い範囲まで一人で進んでしまうと分かったから、渡し方が怖くなった。 自分でも意外な感覚でした。
一斉診断の次にやりたかったのは、業務全体の棚卸し。今回の本丸です。ファイル診断なら範囲は見えていますが、棚卸しはスキル、記憶ファイル、引き継ぎ、モデル方針、サイト運営方針まで絡みます。ここに「いい感じに総点検して」と投げるのは、さすがに怖い。
そこで、本丸に入る前にOpusで下ごしらえをしました。
Fable5にゼロからヒアリングさせるのではなく、先に業務マップを用意する。マップには、今やっている作業、使っているスキル、環境の制約、モデルの方針、お蔵入り候補などをまとめました。
そのうえで、普段使いのOpusに、Fable5用のプロンプトを作ってもらいました。ポイントは、「何かいい感じに改善して」ではなく、流れを固定したこと。
- 最初に業務マップを読む
- 実ファイルと突き合わせる
- 抜けやズレを補完する
- 改善候補を出す
- 優先順位をつける
- 作れるものは実装する
- 作れないものは仕様書・手順・プロンプトに落とす
- 最後にQAする
プロンプトには「ゼロからヒアリングせず、この業務マップの検証・補完から始めてください」と書いてもらいました。Fable5の賢さに丸投げするのではなく、見る資料と診断角度だけは、こちらで先に決めておく。 賢いモデルほど、入口を整えてから渡した方が働く、というのが実感です。
① AIの「記憶」を大掃除し、掃除手順をスキル化した
下ごしらえができたので、ここからが棚卸しの本体です。
まずやったのが、AIに引き継いでいる「記憶」ファイルの大掃除。決定事項の目次や参照先を見直して、古くなった情報や、もう存在しないファイルへの参照を整理してもらいました。
（ここでいう「記憶」は、ChatGPTのメモリ機能のようなものではなく、AIに引き継ぐ決定事項や運用ルールを書きためた、自作のメモファイルのことです。）
流れは4段階でした。
- 発掘
- 統合
- 重複除去
- 剪定
ただ、掃除して終わりにはしませんでした。この手順自体をスキルにして残したんです。
ここが今回の大事なところ。Fable5で一度きれいにするだけだと、また時間が経てば汚れます。記憶ファイルは、放っておけば必ず散らかる。
だから、次回以降は普段のモデルでも同じように掃除できるように、手順として残しました。Fable5に頼んだのは「記憶をきれいにすること」だけじゃなくて、「記憶を掃除し続けられる仕組みを作ること」。 一回きりの結果より、繰り返せる形を残す方が効くんだなと思いました。
②「毎回AIに読ませる」は限界。変わらない部分だけスクリプト化した
今回、一番厳しく指摘されたのがここです。
私はこれまで、必要な資料をAIに読ませて、その場で判断してもらう形で運用してきました。非エンジニアなので、正直、できればスクリプトにはあまり寄せたくない気持ちもありました。
- AIに読ませれば柔軟に処理できる
- スクリプトにするとメンテナンスが難しそう
- そもそも、どこまでコードにすればいいか分からない
でもFable5から見ると、毎回同じ資料を全部読ませる構造は、かなり重かったようです。
記事が増える。wikiが増える。スキルが増える。記憶ファイルも増える。そのたびに、AIが毎回ぜんぶ読んで判断する。
これはモデルを安くする以前の問題でした。ボトルネックはAI代じゃなくて、「毎回全部読む」構造そのものだった。 ここは自分でも薄々気づいていて、見ないふりをしていた部分でした🫠
そこで今回は、今後も変わらないだろう部分だけ、最小限スクリプト化してもらいました。全部を自動化するわけではありません。
| 残す・逃がす | 中身 | 担当 |
|---|---|---|
| AIに残す | 変わりやすい判断 | 毎回モデルに考えさせる |
| スクリプトに逃がす | 変わりにくい読み込み・集計 | 一度書いたら自動 |
非エンジニアでも扱える範囲に絞って、「ここは毎回AIに考えさせなくていい」という部分だけを切り出しました。抵抗はあったけど、やってみたら、線引きさえ間違えなければ怖くなかったです。
③ 改善候補16個を、実装9・見送り7まで決めた
Fable5には、業務マップと実ファイルを見たうえで、改善候補も出してもらいました。
候補は16個。でも、ただ候補を並べるだけではありませんでした。それぞれを優先度順に整理して、こんな風に分けてくれたんです。
- すぐ実装するもの
- 試運転してから判断するもの
- 今は見送ってよいもの
A案・B案があるものは、それぞれのメリット・デメリットも整理。さらに「これは今決める」「これは数回使ってから判断する」「これは次の運用フェーズで見直す」というように、判断するタイミングまで分けてくれました。
そのうえで、採用・見送り・保留を判断したのは私です。最終的に、改善候補16個のうち、実装9・見送り7まで決まりました。
よかったのは、見送り理由も一緒に残したこと。改善候補だけが増えていくと、次のセッションでまた同じ話を蒸し返します。でも「なぜ見送ったのか」「どの段階で再検討するのか」が残っていれば、「あ、これは検討済みだ」と判断できる。
Fable5は、私の代わりに全部を決めるAIではなくて、私が決めるべきことと、今は決めなくていいことを、分けてくれるAIでした。 ここがいちばん助かった気がします。
④ 4サイトの方向性を監査し、「実装止まり」に気づいた
最後に、運営ブログ全体の方向性も見てもらいました。
サブエージェントを並列で動かして、4サイト分のブランド定義、記事のポートフォリオ、今後の方向性を監査。ここで出てきた結論が、地味に刺さりました。
方向性は間違っていない。問題は、設計が完成しているのに、実装が途中で止まっていること。
つまり今の私に必要なのは、新しい設計を増やすことじゃなくて、すでに決めた設計を最後まで実装することだった、というわけです。
これは、引き継ぎやMEMORYで何度も顔を出していた「設計止まり」の罠とも、きれいにつながっていました。次にやるべきことは「方向転換」じゃなくて「実装完遂」。 これがはっきりしただけでも、見てもらった価値がありました。
共通してやったこと｜記述を単一化し、1か所直せばOKに寄せた
ここまでの作業で、ずっと共通して意識していたのが「記述の単一化」です。
普段から、同じルールをあちこちに書かないようには気をつけていました。共通ルールは設定ファイル（AGENTS.md）に寄せる。スキルには固有の手順だけを書く。引き継ぎには判断ログを残す。そのつもりで運用していました。
でも、実際に横断して見てもらうと、それでも重複は発生していました。しかも、こうなる理由の一つひとつが、間違っていないのが厄介なところ。
- 事故りやすいから、スキルにも書く
- 次回セッションで忘れないように、引き継ぎにも書く
- 前にハマったから、MEMORYにも残る
- 念のため、個別のプロンプトにも書く
ひとつひとつは正しい。でも積み重なると、同じようなルールが複数箇所に散らばります。しかも完全なコピペじゃなくて、少しずつ言い方や前提が違う。こうなると、1か所直しても全体が直ったことになりません。
だから今回は、どこを正本にするか、どこは参照に寄せるか、どこは判断ログとして残すか、どこは削っていいか、を見直しました。目指したのは、基本は1か所直せばOKの形です。
きれいなドキュメントを作りたいわけじゃなくて、あとから変更しても壊れにくい状態にしたい。 整理の目的はそこでした。気をつけていたのに散らかっていた、というのが、いちばん自分らしい発見だった気がします🫠
やってみて分かったこと｜Fable5は判断を奪わず、判断できる形にしてくれた
一連の作業を通して思ったのは、Fable5の強さは「全部を勝手に決めてくれること」ではなかった、ということです。
優先度をつけて、A案B案を並べて、メリデメを整理して、「今決めること」と「試運転してから決めること」を分ける。人間が判断しやすい形まで、材料を並べ直してくれる。強かったのは、そこでした。
Opusに作ってもらったプロンプトには、こんな一文を入れていました。
「あなた自身に最適化しないでください」
Fable5でしか動かない完璧な仕組みを作られても、Fable5がいなくなった瞬間に回らなくなります。だから、現行モデルでも改善を続けられる形に落とすことを、最初からお願いしていました。
同じ理由で、自動化も「完全自動は目指さず『事故らない半自動』にする」という方針にしました。全部を任せて事故るより、人が判断する隙間を残して事故らない方がいい。 非エンジニアの運用だと、ここのさじ加減がいちばん大事だと感じます。
まとめ｜Fable5はAIブログ運営OSの一度きりの設計者だった
今回Fable5にやらせたのは、ふわっとした「資産づくり」ではありませんでした。実際にやったのは、こういう地に足のついた作業です。
- 試運転としてファイル69本を一斉診断
- Fable5が自走できると分かったからこそ、Opusで「見る資料と診断角度」を設計
- 誤検出の精査（私の指摘で直した誇張も1件）
- AIの記憶ファイルの大掃除と、掃除手順のスキル化
- 「毎回全部読む」構造の見直しと、最小限スクリプト化
- 改善候補16個の整理、実装9・見送り7の判断
- 4サイトの方向性監査
- 記述の単一化
その上で、思想として残ったのがこれでした。
上位AIは、今だけ強い作業者として使うより、一度きりの設計者として使った方が残る。プロンプトにも「一度きりの設計者」という言葉を、そのまま入れていました。
Fable5に何かを全部決めてもらうのではなく、Fable5がいなくなったあとも、Opus / Sonnet / Haiku で改善を続けられる形に、土台を組み直してもらう。そして人間は、全部を細かく指示するのではなく、入口を整えて、出てきた提案を判断する。
Fable5は、判断を奪うAIではなくて、判断できる形まで整理してくれるAIでした。
次に上位モデルを使える機会が来たら、「何を作らせるか」だけじゃなくて、「どの資料を見てもらうか」「このモデルが使えなくなったあとも回るか」を先に考えようと思います。上位モデルと普段のモデルの使い分けは、まだ試行錯誤の途中です。
