Claude Fable 5が復活。止まっていた開発が30分で動いた理由

あの止まったAIが、帰ってきた

先月、私は一本のブログ記事を書きました。「Anthropicの最新AI『Claude Fable 5』が、公開直後に利用停止になった」という事件を、たまたま新幹線での移動中に体験した話です。

そのとき私は、飲食店経営者のみなさんに向けて3つの教訓をお伝えしました。「AIは急に使えなくなることがある」「1つのAIに全部おんぶは危険」「人が最終確認する仕組みを残す」――この3つです。

（前編をまだ読まれていない方は、先にこちらをどうぞ。今回の話がぐっとわかりやすくなります）

📖 前編：「最新AIが公開直後に利用停止」から飲食店経営者が学ぶべきこと

さて、あれから約1か月。

2026年7月1日、私のスマートフォンとパソコンに、こんなお知らせが届きました。

「Fable 5が復活しました」

止まっていたはずのAIが、帰ってきたのです。

そして、この復活したAIを使って、私は自社で開発中のあるアプリの「数週間ずっと解けなかった問題」を、たった30分で解決することになります。

今日は、その一部始終を、できるだけありのままにお話しします。前編の続報であると同時に、「AIと一緒に仕事をするとは、結局どういうことなのか」という、経営者にとってわりと本質的な話にもつながっていく――そんな一本になればと思っています。

いつものように、途中で出てくる専門用語は枠で囲って、なるべくやさしく解説していきます。「うちの店にAIなんて」と思われている方こそ、最後まで読んでいただけるとうれしいです。

---

何が起きたのか──「お試し放題キャンペーン」として復活

まず、事実関係を整理しましょう。

Anthropic（アンソロピック、Claudeというサービスを作っている会社です）は、2026年7月1日、Fable 5を「プロモーションアクセス」という形で再び使えるようにしました。公式サポートページにも、はっきりと書かれています。

内容をかみ砕くと、こういうことです。

• 期間限定です。2026年7月1日から、7月7日の夜23:59:59（太平洋時間）まで。つまり約1週間だけ。
• 追加料金なしで使えます。ただし「使い放題」ではなく、いま契約しているプランの週の利用上限の、最大50%までFable 5に使ってよい、というルールです。
• その50%を使い切ったら、追加のクレジット（課金）で使い続けるか、別のAIに切り替えるか、を選ぶことになります。
• Fable 5は、ほかのモデル（Opus 4.8など）より利用量の消費が速いとされています。同じ作業でも「燃費」が違うイメージです。
• 対象は、Pro・Max・Team・そして法人向けEnterpriseのプレミアムシートを契約している人。無料プランは対象外です。
• 特別な申請や有効化の手続きは不要。契約者なら、勝手に使えるようになっています。

一言でいえば、「話題の高級モデルを、1週間だけ、決められた量まで無料でお試しできるキャンペーン」です。

飲食店にたとえるなら、こんな感じでしょうか。

たとえ話：期間限定の「特別コース」
ふだんはメニューに載っていない、シェフ自慢の特別コースがあるとします。「今週いっぱいだけ、いつものコース料金のなかで、その特別コースも半分までお楽しみいただけます。ただし食材が高いので、ご予算の減りは少し早めです」――そんなキャンペーンだと思ってください。せっかくなら、ただ食べて終わりではなく「これは家でも作れるか？」と学びながら味わいたいですよね。今回の私は、まさにその姿勢でFable 5と向き合いました。

前編で「急に止まった」と書いたAIが、今度は「期間限定で帰ってきた」。この落差そのものが、実は前編の教訓の裏返しになっています。AIは、止まることもあるし、いきなり復活することもある。私たちにできるのは、そのどちらに転んでも困らない準備をしておくこと。この話は、記事の後半でもう一度きちんと回収します。

---

本編：数週間の停滞と、30分の出来事

ここからが、今日の本題です。

舞台：自社で開発中のダイエットアプリ「楽ダイ」

いま当社では、「楽ダイ（らくダイ）」という名前の、ダイエットを支援するアプリを開発しています。スマホのブラウザから使えるタイプの、ヘルスケア（健康管理）向けのWebアプリです。

用語：Webアプリ（PWA）とは？
アプリストアからわざわざダウンロードしなくても、スマホやパソコンのブラウザからそのまま使えるアプリのことです。ホーム画面に置いておけば、ふつうのアプリと同じように起動できます。開発する側にとっては「iPhone用」「Android用」と別々に作らずに済むメリットがあります。

このアプリの開発で、私はある方針を貫いていました。それが、前編でお伝えした教訓そのもの――「複数のAIを使い分ける」です。

具体的には、Googleが提供する「Antigravity（アンチグラビティ）」という開発環境を使い、その中で2種類のAIを組み合わせて動かしていました。

• 一つは、じっくり考えるのが得意なモデル（Claude Sonnet 4.6の思考モード）。
• もう一つは、素早くこなすのが得意なモデル（Gemini 3.5 Flashの高性能モード）。

この2つを、作業の性質に応じて使い分ける「ハイブリッド体制」です。前編で「1つのAIに全部おんぶは危険」と書いた私自身が、ちゃんとそれを実践していた、というわけです。

どうしても解けなかった、たった1つの問題

この体制のおかげで、開発はおおむね順調に進んでいました。ところが――どうしても解決できない問題が、一つだけ残っていたのです。

楽ダイには、運動やウォーキングのときに音楽を流せるよう、「Apple Music（アップルの音楽サービス）と連携する」機能を入れようとしていました。そのためには、Appleが用意している開発者向けの管理サイト（Apple Developer Portal）で、連携用の「鍵」を作る必要があります。

用語：連携用の「鍵」とは？
自分のアプリが、正規の許可を得てAppleの音楽サービスとつながるための、いわば「通行証」のようなものです。これがないと、アプリは「あなた、誰ですか？」とはじかれてしまい、音楽を再生できません。安全のために、こうした鍵は開発者が自分で発行する仕組みになっています。

ところが、この鍵がどうしても作れない。管理画面で鍵を作ろうとすると、こんな英語のエラーが出て、先に進むためのチェックボックスが押せないのです。

There are no identifiers available that can be associated with the key
（＝この鍵に紐づけられる識別子がありません）

私は「たぶん、アプリの登録（App IDという設定）が足りないんだろう」と考えました。もっともらしい仮説です。そこで、その登録を試してみました。……直りません。もう一度、設定を見直して試しました。……やはり直りません。

計2回、同じ仮説にもとづいて手を動かし、2回とも失敗しました。原因がわからないまま、この音楽連携の機能だけが、数週間、まるごと止まっていました。

正直に言えば、少ししんどい時期でした。ほかの機能は動いているのに、一か所だけ、見えない壁にぶつかって前に進めない。経営をされている方なら、「あと一歩なのに、その一歩がどうしても踏み出せない」あの感覚、わかっていただけるのではないでしょうか。

厄介だったのは、このエラーメッセージが「なぜダメなのか」を教えてくれないことでした。「紐づけられる識別子がありません」とは言うものの、「では、どの識別子を、どこで用意すればいいのか」は書いてくれない。まるで、鍵屋さんに行って「その鍵はここでは作れません」とだけ言われ、では正しい店はどこですか、と聞いても黙って首を振られるような状態です。

こういうとき、人間は自分の経験や思い込みで「たぶんこうだろう」と当たりをつけます。私の場合、その当たりが「App IDの登録不足」でした。もっともらしく、実際、そういうケースも世の中には多いのです。だからこそ、その仮説を捨てるきっかけが、なかなかつかめませんでした。仮説が半分もっともらしいときほど、人は抜け出せなくなるものです。

7月1日、Fable 5が帰ってきた

そんなタイミングで、冒頭のお知らせが届いたのです。「Fable 5が復活しました」。

私は思いました。「よし、この止まった問題を、復活したFable 5にぶつけてみよう」と。

ただ、ここでいきなりFableにヘルプをお願いしても、うまくいきません。なぜなら――AIは、これまでの経緯を何も知らないからです。

これは、AIと付き合ううえで、いちばん大事なポイントかもしれません。

用語：AIには「記憶」が続かない
人間なら「先週こういうことがあってね」と経緯を覚えていますが、AIは基本的に、会話やプロジェクトが変わると、それまでのやりとりをきれいに忘れてしまいます。とくに、別のAI（今回でいえば旧環境のAIから、復活したFable 5へ）に作業を引き継ぐ場合は、前任者の記憶はゼロからのスタートになります。

そこで私は、ひと工夫しました。

まず、これまで開発を担ってくれていた旧環境のAIに、「引き継ぎ書」を書かせたのです。

「引き継ぎ書」を書かせるという一手

引き継ぎ書とは、文字どおり、仕事を引き継ぐための書類です。私が旧環境のAIにお願いして作ってもらったのは、こんな内容を1つのドキュメントにまとめたものでした。

• このプロジェクトは、いまどこまで進んでいるのか（現在地）
• これまで、何を試して、何が失敗したのか（失敗の履歴）
• だから、やってはいけないこと（同じ轍を踏まないための注意書き）
• 各種の設定情報（どんな構成で作っているか）

つまり、「後任者がこれを読めば、いきなり戦力になれる」ように、経緯と地雷を全部書き出した紙です。新しく入ってきたスタッフに渡す、あの引き継ぎメモとまったく同じ発想です。

ここで少し、なぜ「旧環境のAIに書かせた」のかを補足させてください。自分で一から書いてもよかったのですが、それには理由があります。数週間、実際に手を動かしてきたのは、その旧環境のAIです。どの設定をどういじったか、どのエラーが何回出たか――その細部は、私の記憶よりも、作業を伴走してきたAIのほうが正確に覚えていました。ならば、いちばんの当事者に書かせるのが筋だろう、と考えたのです。これも、辞めていく担当者本人に引き継ぎ書を書いてもらうのと、まったく同じ理屈です。

私はこの引き継ぎ書を、復活したFable 5（今回はコード作業向けの「Claude Code」という形で使いました）に読み込ませ、そのうえで、こう頼みました。「この問題、一緒に解いてくれますか」と。

正直、半信半疑でした。旧環境のAIも決して非力ではありません。それでも解けなかった問題です。モデルが替わったくらいで、そう簡単に突破口が開くものだろうか――そんな気持ちが、心のどこかにありました。

30分の緊張感

ここからの展開が、私にとっては少し衝撃的でした。

Fable 5は、引き継ぎ書に書かれた「過去2回、App IDの登録を試して失敗した」という記録を、ちゃんと読み取っていました。そして、こう考えたようです。「2回試して直らなかったのなら、そもそもその仮説が間違っているのではないか」と。

つまり、私が数週間信じ込んでいた前提そのものを、疑ってくれたのです。

そこからFable 5は、Appleの公式ヘルプまで自力で調べにいき、真の原因を突き止めました。

必要だったのは、私がずっと思い込んでいた「App ID」ではなく、「Media ID」という、まったく別の種類の識別子だったのです。音楽（メディア）を扱うための、専用の登録が必要だった。私は種類そのものを取り違えていたわけです。道理で、いくらApp IDをいじっても直らないはずでした。

ここから先は、人間とAIの見事な連携プレーになりました。

• 人間（私）は、Fable 5が示してくれた正しい手順に従って、画面上で鍵の作成を進める。チェックボックスを押す、という「人にしかできない操作」を担当します。
• AI（Fable 5）は、そこから先――鍵をもとにした通行証（トークン）の生成、アプリへの組み込み、そして本番環境への公開まで、一気に完遂してくれました。

数週間止まっていた問題が、動き出してから約30分で、片づいてしまったのです。

おまけに、誰も気づいていなかったバグまで

話はこれで終わりません。

Fable 5は、この作業の流れのなかで、コードの中に潜んでいた、もう一つの誰も気づいていなかったバグを見つけ出しました。音楽再生に必要なプログラム部品（SDK）を読み込むための住所（URL）が、そもそも存在しないドメインになっていたのです。これでは、たとえ鍵の問題が解決しても、いずれ音楽は鳴らなかったでしょう。この修正も、その場で済ませてくれました。

さらに同じ日のうちに、私はこんな作業まで終えることができました。

• 体重の推移を折れ線グラフで見られる、新しい機能の実装
• スマホの健康管理機能から取り込んだ体重データが、なぜか「目標体重」の数値を誤って上書きしてしまう、という不具合の修正
• これらを、本番環境に公開するところまで

数週間止まっていたプロジェクトが、たった1日で、いくつも前に進みました。

大事な但し書き（ここは誠実にお伝えします）

……と、ここまで読むと、「Fable 5、すごい！」で終わってしまいそうです。でも、そう単純に締めくくるのは、フェアではないと私は思っています。

前編の停止事件のとき、私は新幹線での移動中でした。揺れる車内、途切れがちなモバイル回線、周りに人がいる落ち着かない環境。対して今回は、社内の静かなデスクで、腰を据えて取り組んでいます。

作業をする「条件」が、そもそも違うのです。ですから今回の一件を、「Fable 5は前より優秀だ」という単純なモデルの性能比較の話として受け取ってほしくはありません。環境が違えば、うまくいくかどうかも変わって当然です。

それでも――この体験から得られた気づきそのものは、本物だと、私は確信しています。次章から、その気づきを掘り下げていきます。

---

なぜ、たった30分で解けたのか

数週間止まっていた問題が、30分で動いた。この差は、いったいどこから生まれたのでしょう。

私が考えるに、AIの本当の実力差は、多くの人が想像するところとは、少し違う場所に現れます。

多くの人は、AIの賢さを「新しいものを、どれだけ上手に作れるか」で測ろうとします。文章を書く、絵を描く、プログラムを組む――たしかに、それも大事な能力です。

でも今回、私が目の当たりにしたのは、それとは別の力でした。

「過去の失敗の記録を読み解き、思い込みを疑い、真の原因にたどり着く力」です。

考えてみてください。私は、数週間かけて「App IDが原因だ」と信じ込んでいました。2回失敗してもなお、その前提を捨てられなかった。人間は、一度「これが原因だ」と思い込むと、なかなかそこから抜け出せない生き物です。

Fable 5がやったのは、華々しい発明ではありません。引き継ぎ書に書かれた「2回失敗した」という地味な事実を、ちゃんと重く受け止め、「じゃあ前提が違うのでは」と冷静に疑ったこと。ただ、それだけです。

でも、この「疑う力」こそが、数週間の停滞を破りました。

これは、優秀な人材にも通じる話だと思います。本当に頼りになる人は、派手なアイデアを出す人よりも、「あれ、この前提、ほんとうに正しいんでしたっけ？」と、みんなが見落としている当たり前を疑える人だったりします。AIも、まさにその域に入ってきている、ということなのでしょう。

飲食店の現場に置き換えると、こういうことです。たとえば「最近、ランチの客数が落ちている」という問題があったとします。多くの人は、まず「メニューが飽きられたのかな」「値段が高いのかな」と、思いつきやすい原因から手をつけます。ときには、それで正解のこともある。でも、何を試しても客数が戻らないとき、本当に必要なのは、また別のメニューを考えることではありません。「そもそも、お客さまが減った本当の理由は、味でも値段でもなく、近くにできた大型駐車場の工事で人の流れが変わったからでは？」と、前提そのものを疑い直すことです。真因が違えば、いくら打ち手を重ねても空振りに終わります。私のApp IDの一件は、まさにこれと同じ構図でした。

そして――ここが今日いちばんお伝えしたいところなのですが――その「疑う力」を引き出したのは、AIの性能だけではありませんでした。私が渡した「引き継ぎ書」が、あってこそだったのです。

もし引き継ぎ書がなければ、Fable 5は「過去に2回失敗した」ことを知りようがありません。知らなければ、私と同じように、またApp IDから疑ってかかっていたかもしれない。振り出しに戻っていた可能性が高いのです。

つまり、成果を生んだのは「新しいAI」だけではなく、「引き継ぎ書 × 新しいAI」という掛け算でした。この掛け算こそ、今回いちばんの発見です。

---

最大の気づき──「引き継ぎ書」文化をつくる

ここで、前編の教訓を思い出してください。私は3つ目に、こう書きました。

「代替可能性の確保」――いつでも別の手段に切り替えられるようにしておく。

正直に告白すると、前編を書いた時点では、この「代替可能性」を、私はまだ少し抽象的にしか理解していませんでした。「複数のAIを持っておこう」くらいの、ふわっとしたイメージだったのです。

でも今回、その正体が、はっきりと形になりました。代替可能性を支える具体的な方法、それが「引き継ぎ書」だったのです。

理由を、あらためて整理します。

• AIは、記憶が続きません。会話やプロジェクトが変われば、経緯を忘れます。
• そしてAIのモデルは、前編で見たように、止まることがあります。逆に、今回のように突然復活することもあります。
• だとすれば、私たちが頼るべきなのは「特定のAIの記憶」ではありません。それは、いつ消えてもおかしくないからです。

では、何に頼ればいいのか。答えは、AIの外側に、経緯を書き残しておくことです。それが引き継ぎ書です。

引き継ぎ書さえ手元にあれば、使っていたAIが止まっても、別のAIに乗り換えても、その紙を渡すだけで――新しいAIは、数十分でまた走り出せるのです。今回、まさにそれが起きました。

これは、人間の職場と、まったく同じ構造です。

エースの店長が急に辞めても、しっかりした引き継ぎ書があれば、次の人がすぐに店を回せる。逆に、すべてがその店長の頭の中にしかなかったら、辞めた瞬間にお店は立ち行かなくなる。

AIも、同じです。すべてを「特定のAIの記憶」に預けてしまえば、そのAIが止まった瞬間にお手上げです。でも、経緯を引き継ぎ書として外に残しておけば、AIは「いつでも替えのきく存在」になる。皮肉なようですが、引き継ぎ書を残すことこそが、特定のAIに依存しないための、いちばん確実な方法なのです。

前編で書いた「代替可能性の確保」。その具体的な実践方法は、「引き継ぎ書を書かせ、AIの外に残す」ことだった。今回、私はようやく、その答えにたどり着きました。

そして、もう一つ気づいたことがあります。引き継ぎ書は「保険」であると同時に、「質を上げる道具」でもある、ということです。過去の失敗が明文化されていれば、次に来たAIは、同じ失敗を繰り返しません。それどころか、今回のように「その失敗の記録こそが、真因発見の手がかり」になります。つまり、失敗を記録に残せば残すほど、次の一手は賢くなる。失敗が資産に変わるのです。これは、AIに限らず、組織の成長そのものの原理でもあります。「うまくいかなかったこと」をきちんと残せる職場は、強い。逆に、失敗をなかったことにする職場は、同じ失敗を何度も繰り返します。

---

同じ朝、Fable 5は「曜日」を間違えた

ここまで読むと、やはり「Fable 5、すごい」の印象が強く残るかもしれません。でも、フェアであるために、同じ日の朝にあった、少し情けない――でも、だからこそ大事な――もう一つの出来事を書いておきます。

私は毎朝、AIにその日の予定やメールをまとめて報告させる「朝のブリーフィング」を習慣にしています。今朝、それを復活したFable 5に任せました。

報告そのものはスムーズでした。ところが、予定の一覧を見て、私は「あれ？」と首をかしげました。日付は合っているのに、曜日が全部、1日ずつずれていたのです。7月2日を「(水)」、7月3日を「(木)」と書いている。実際には、2日は木曜日、3日は金曜日です。

数週間かかった難問を30分で解いたのと、同じAIです。それが、カレンダーを見れば誰でもわかる「曜日」を、堂々と間違えている。これが、AIの正直な姿でもあります。難しいことができるからといって、簡単なことを絶対に間違えない、とは限らない。ここからのやりとりが、今回いちばんの学びになりました。

「今後気をつけます」で終わらせなかった

私は、まず指摘しました。「曜日、間違えていませんか？」と。

Fable 5は、その場で現在の日付と曜日を機械的に確認し直し、すぐに誤りを認めて訂正しました。ここまでは、まあ、よくある話です。そして「今後は、曜日を機械的に確認してから記載します」と約束してくれました。

ただ、私はもう一歩、踏み込んで聞いてみたのです。「それ、以前のモデルではできていたことでは？ 記録の容量が足りないの？ それとも、新しいモデルに切り替えたせいのミス？」と。

正直、意地悪な質問だったかもしれません。でも、原因があいまいなまま「気をつけます」で流されると、また同じことが起きる。そう思ったからでした。

このときのFable 5の対応が、私には印象的でした。言い訳もせず、当てずっぽうの謝罪も並べず、まず「事実を確認しに」行ったのです。

具体的には、当社でAIに常時読ませている「ルールブック」――社内の決めごとをまとめた、いわば引き継ぎ書の親玉のような文書があるのですが、Fable 5はその中身を実際に読み直し、原因をこう切り分けてみせました。

用語：AIに読ませる「ルールブック」とは？
当社では、AIに仕事を任せるとき、「うちではこう進めてほしい」という決めごとを一つの文書にまとめ、毎回それを読ませてから作業を始めさせています。前半でお話しした「引き継ぎ書」を、会社全体のルールにまで育てたもの、とイメージしてください。どのAIが来ても、これを読めば同じ流儀で動ける、という土台です。

• 記録の容量の問題ではない。――なぜなら、同じ朝、ルールブックに書かれた他の決めごとは、ちゃんと読めて、実行できていたからです。読めていないわけではない、と切り分けました。
• 本当の原因は「ルールの穴」と「うっかりの重なり」だった。――ルールブックには「時刻は確認すること」とは書いてあったのに、「曜日を書くときは、頭の中で計算せず、必ず機械的に確認する」とまでは、書かれていなかった。Fable 5は、日付そのものは正しく把握していたのに、曜日だけを”暗算”して、間違えたのです。
• 新しいモデルのせいかどうかは、断定できない。――だからこそ、「モデルが何であっても、二度と再発しない形」に直すのが正解だ、と判断した、と説明してくれました。

原因を、人（AI）のせいにも、道具のせいにもしなかった。「ルールに穴があった」という、直せる場所に、原因を落とし込んだのです。

その場で、ルールブックを書き換えた

そして――ここが肝心なのですが――Fable 5は「今後気をつけます」という口約束で終わらせませんでした。

その場で、ルールブックそのものを書き換えたのです。「曜日は暗算禁止・必ず機械的に確認する」という一行を追記し、あわせて今回の誤りを「違反事例」として記録に残しました。

これで、次に朝のブリーフィングを任されるのが、どのAIであっても――たとえまた別のモデルに替わったとしても――このルールブックを読むかぎり、同じ間違いは起きなくなります。今朝のうっかりが、その場で「二度と繰り返さない仕組み」に変わったのです。

失敗した直後に、その失敗を仕組みへ焼き込む。前の章で書いた「失敗を資産に変える」を、Fable 5は、まさに目の前で実演してみせたのでした。

---

「気をつけます」と言う人と、マニュアルを1行直す人

この朝の一件は、AIの話であると同時に、そっくりそのまま、人の職場の話でもあります。みなさんの職場にも、きっと両方のタイプがいるはずです。

一つは、ミスを指摘されて「すみません、以後、気をつけます」と言うタイプ。悪気はありません。本人は本気で気をつけるつもりです。でも――気合いだけに頼った対策は、たいてい、しばらくすると元に戻ります。人は忘れる生き物だからです。だから、同じミスが、担当者を替えながら、何度も繰り返されます。

もう一つは、ミスを指摘されたその場で、「では、マニュアルにこう一行足しておきます」とチェックリストを直すタイプです。自分の気合いではなく、仕組みのほうを直す。すると、次に同じ場面が来たとき、たとえ担当が新人に替わっていても、マニュアルがミスを防いでくれます。

対応の仕方	「気をつけます」で終わる	その場で仕組みを直す
直すもの	本人の気合い・注意力	ルール・マニュアル
効き目の持続	忘れると元に戻る	担当が替わっても残る
担当が替わったら	また同じミスが起きる	新しい人も守れる
失敗の扱い	なかったことになりがち	「違反事例」として資産化

今朝のFable 5がやったのは、まぎれもなく右側でした。そして私は、これこそがAIの賢さの本質ではなく、賢さより大事な「習慣」なのだと、あらためて思ったのです。

難しい問題を30分で解く力より、簡単なミスを二度と起こさない仕組みに落とす習慣。経営の現場で本当に効いてくるのは、たぶん後者です。そしてこの習慣は、AIにも、人にも、まったく同じように必要なものでした。

---

飲食店経営に翻訳すると、どうなるか

さて、ここまではAI開発の話でした。でも、この記事を読んでくださっているのは、飲食店や中小企業の経営者の方が多いはずです。「うちには関係ない」と思われる前に、少しだけお付き合いください。実は、まったく同じ話なのです。

みなさんのお店には、きっと「マニュアル」や「引き継ぎ書」がありますよね。（もしなければ、これを機にぜひ）。

• 新人が入ってきても、マニュアルがあれば、一定の水準で仕事を覚えられる。
• ベテランが辞めても、引き継ぎ書があれば、次の人が業務を引き継げる。
• 「あの人がいないと、この作業は誰もわからない」――この属人化こそ、経営でいちばん怖いことのひとつです。

AIの活用も、これとまったく同じ構造だ、というのが今日の結論です。

「あのAIじゃないと、うちの業務は回らない」という状態は、「あのベテランがいないと店が回らない」のと、危うさがそっくりです。私はこれを、勝手に「属AI化（ぞくエーアイか）」と呼んでいます。特定のAIに、経緯も判断も、全部おんぶしてしまっている状態のことです。

前編の教訓「1つのAIに全部おんぶは危険」を、もう一歩進めた表現とも言えます。

対比で見ると、はっきりします。

状況	引き継ぎ書が「ない」場合	引き継ぎ書が「ある」場合
ベテラン店員が辞めた	業務が止まる。ノウハウが消える	次の人が読んで、すぐ引き継げる
使っていたAIが止まった	何をどこまでやったか誰もわからない	別のAIに渡せば、数十分で再開できる
新しいAI（新人）が来た	イチから全部教え直し	引き継ぎ書を渡すだけで戦力になる
判断のよりどころ	「あの人／あのAIの記憶」頼み	「文書として残った経緯」が土台

左の列は、いつか必ず行き詰まります。右の列は、人が替わっても、AIが替わっても、事業が回り続けます。

飲食店経営で当たり前にやってきた「仕組みで回す」という発想。それを、AI活用にも、そのまま持ち込めばいいのです。難しい技術の話ではありません。「経緯を、人（AI）の頭の外に、文書で残す」――ただそれだけです。

もう少し具体的に、みなさんのお店に引き寄せてみましょう。

たとえば、SNSの投稿をAIに手伝ってもらっているお店は、いま本当に増えました。集客のためのキャンペーン文を考えてもらったり、季節メニューの告知文を作ってもらったり。とても便利です。でも、もしそのやりとりが、スタッフ一人のスマホの中の、あるAIとの会話だけで完結していたらどうでしょう。そのスタッフが辞めたら、「どんな方針で、何を試して、何が反応がよかったのか」は、丸ごと消えてしまいます。次の人は、また手探りで一からやり直しです。

ここで、「うちの店のSNSは、こういう客層に向けて、こういうトーンで、こういう投稿が反応がよかった。逆にこれは滑った」という引き継ぎ書が一枚あれば、話はまったく変わります。スタッフが替わっても、使うAIが替わっても、その一枚を渡すだけで、すぐに同じ水準の投稿が続けられる。しかも過去の「滑った記録」があるぶん、無駄打ちが減っていきます。

これは、レジの締め方や仕込みの手順をマニュアル化するのと、何ら変わりません。「頭の中にしかない大事なこと」を、紙（データ）に落として、みんなで共有できる状態にしておく。AI活用でつまずく会社と、うまく回る会社の差は、多くの場合、能力ではなく、この「残す習慣があるかどうか」だと、私は現場で感じています。

---

まとめ──今日から始められる、3つの実践

長くなりました。最後に、今回の体験から得た気づきを、みなさんがすぐ試せる形で3つにまとめます。

実践1：AIに「引き継ぎ書」を書かせる習慣を持つ

AIに何か作業を任せたら、区切りのいいところで「ここまでの経緯と、うまくいかなかったこと、注意点を、引き継ぎ書としてまとめて」とお願いしてみてください。それを、AIの外（メモ帳でも、共有ドキュメントでも構いません）に保存しておく。

これだけで、次に別のAIを使うことになっても、その紙を渡すだけでスムーズに再開できます。人間の職場でやっている引き継ぎを、AIにもやらせる。ただそれだけです。

実践2：複数AI体制を、維持する

前編でお伝えした教訓の、変わらぬ王道です。1つのAIに全部おんぶしない。「じっくり考える用」「素早くこなす用」など、性格の違うAIを使い分ける。今回、私が数週間の停滞のあいだも開発を止めずに済んだのは、この複数体制があったからでした。1つが止まっても、事業は止まらない。この備えは、これからも手放しません。

実践3：期間限定の新モデルは、「検証案件」を決めて試す

Fable 5のプロモーションは、2026年7月7日の夜までの、期間限定です。もし対象プランを契約されている方がいれば、ぜひこの機会に触ってみてください。

ただし、おすすめは「なんとなく触ってみる」ではありません。「これができたら本物だ」という、自分にとっての検証案件を1つ決めてから試すことです。私の場合は、それが「数週間止まっていた音楽連携」でした。明確なお題があったからこそ、性能差がくっきりと見えたのです。ただ試すだけでは、「へえ、すごいね」で終わってしまいます。

---

おわりに

前編で「止まった」と書いたAIが、今回は「復活し、数週間の停滞を30分で破った」。この1か月で、私は正反対の体験を続けてしたことになります。

同じAIが、曜日を間違えもすれば、数週間の難問を30分で解きもする。その凸凹こそが、AIの正直な姿です。大事なのは、その凸を過信することでも、凹に失望することでもなく、どちらが来ても仕組みで受け止められるようにしておくこと――今回、私はそう学びました。

でも、両方を通して見えてきた結論は、実はひとつでした。

AIは、止まることもあれば、復活することもある。だから、特定のAIに頼りきるのではなく、経緯を「引き継ぎ書」として残し、いつでも替えがきく仕組みをつくっておく。

これは、飲食店がマニュアルと引き継ぎ書で「人が替わっても回る店」をつくってきたのと、まったく同じ知恵です。新しいのは道具（AI）だけで、大事にすべき考え方は、昔から変わっていません。AIは便利な道具ですが、賢く頼り、でも頼りすぎない。前編の締めくくりを、今回も繰り返しておきたいと思います。

---

当社デリシャスノーツでは、こうした「AIを賢く使いこなす仕組みづくり」と、Webを活用した集客のご支援を、飲食店・中小企業のみなさまと二人三脚で行っています。「AIに興味はあるけれど、何から手をつければいいかわからない」「うちの業務にどう活かせるのか、一度相談してみたい」――そんな方は、どうぞお気軽にお問い合わせください。今日ご紹介したような実践を、みなさんの現場に合わせた形で、一緒に組み立てていきます。

最後までお読みいただき、ありがとうございました。