Fable5に、SaaSの健康診断をしてもらってから
私は、BCP——事業継続計画、つまり「災害や事故で事業が止まったとき、どう立て直すかについて、事前に対策を練っておく」を、経営者と一緒に考える機会が多く、中小企業向けに、そのBCPづくりを支援しています。
その私が、AIと対話しながら自分で作ったサービスがbcp-ai.comです。中小企業が簡単なBCPを自動で作れる、いま実際に動いているWebサービスです。プログラマーではない私が、AIに相談しながら少しずつ組み上げてきました。
先日、そのbcp-aiのコード一式を、Claude Fable 5に丸ごと渡してみました。「このサービスのコードを、レビューしてほしい」と。
自分のサービスを、AIに健康診断してもらう。そんな感覚でした。
結果を先に言うと——事業継続を脅かしかねない弱点が、2つ見つかりました。BCP、つまり「事業を止めないための計画」を売っている私のサービス自身に、事業を止めかねないリスクが眠っていたというわけです。
でも、この記事で本当に書きたいのは、潜在的な脆弱性が見つかった話ではありません。それをどう直したか——もっと言えば、非エンジニアの私が、複数のAIを「役割」で使い分けながら、本番のサービスを壊さずに直しきった、その進め方の話です。
AIに任せるとは、"どのAIに何をさせるか"を決めることだった。この数日で、私はそれを実感しました。
まず、相談するAIに診てもらった
コードを渡した相手は、Claude Fable 5です。
Fable5は、長くて、入り組んでいて、あいまいなものを読み解くのが得意だと言われています。私が渡したのは、まさにそういうものでした。何百ものファイルからなる、本番で動いているサービスの全体。巨大なかたまりです。「これを俯瞰して、気になるところを挙げてほしい」という仕事には、このFable5が向いていました。
返ってきた診断は、正直、意外なものから始まりました。
「バイブコーディング産のコードベースとしては、異例の水準です」——Fable5にそう言われたのです。
具体的には、他人のデータに勝手にアクセスできないための検査項目が用意されていたこと、パスワードの扱いや決済まわりの基本が正しく作られていたこと、これまでの判断の記録が残っていたこと等々。
褒められて、少しほっとしました。
けれど、話はそこで終わりませんでした。
そして、事業継続を脅かす穴が2つ
褒められた直後に、Fable 5はこう続けました。弱点が2つあります、と。
1つ目は、外部から指定されたURLアドレスを、私のサーバーがそのまま読みに行ってしまう穴（専門用語でSSRFと呼ばれる脆弱性です）で、2つ目は、ログインした利用者が、他の会社のデータに触れられてしまう可能性がある問題でした（IDORと呼ばれる脆弱性です）。
すぐに修正して本番へ反映しました。そのうえで、私がいちばん気になったのは——「これまでに、これらの穴が悪さをしたことがないか」でした。そこで、サービス開始から今日までの全期間、約8か月分のデータを一件ずつ照合し、あるお客様のデータが別のお客様の領域に紛れ込んでいないかを、すべての記録で確認しました。結果は、混入ゼロ。実際に悪用された形跡は、見当たりませんでした。
この2つの「穴」は、実はプロのエンジニアが作ったシステムでもしばしば見つかる種類の弱点です。バイブコーディングだから特別に危うい、という話ではありません。人が作ろうと、AIと作ろうと、Webサービスにはこうした穴が入り込む。だからこそ、作ったあとに「診てもらう」工程が要るのだと、私は今回痛感しました。
加えて、利用者がインタビューの13問目で先に進めなくなるバグも見つかりました。リロードすると先に進めるのですが、そのままでお試しいただいた方にはお詫び申し上げます。
見つかったときは、正直、ひやりとしました。でも同時に、こうも思ったのです——見つけられてよかった、と。動いているサービスは、動いているというだけで、つい「大丈夫」だと思ってしまう。診てもらわなければ、私はこの穴に気づかないままだったはずです。
Fable 5が出したのは、"処方箋"だった
Fable 5の診断は、穴の指摘だけでは終わりませんでした。むしろ量としては、「これから長く付き合うために、体質を整えておきましょう」という処方箋のほうが多かったのです。急所の手当てだけでなく、生活習慣の改善まで指導してくれる、健康診断そのものでした。
主なものを、3つ挙げます。
一つ目は、散らかった作業場の片づけ。開発の途中で作った多数の分析メモや動作確認用のファイルが、本番のコードと同じ場所に積み上がっていました。人間なら「まあ動くからいいか」で済ませてしまうところです。でもAIにとっては、この散らかりが誤作動のもとになる。整理すべきだ、と指摘されました。
二つ目は、巨大になりすぎたファイルの分割。サービスの中核をなすファイルが、約5,000行にまで膨らんでいました。Fable 5はここで鋭いことを言いました——バイブコーディングでは、ファイルが巨大なほどAIが編集を誤りやすい、と。AIに手伝ってもらう以上、AIが扱いやすい形にしておくことが、そのまま品質につながる。この指摘を受けて、後にこのファイルは30分の1程度まで整理されました。
三つ目は、テストの立て直し。このサービスには、もともとテスト（プログラムが正しく動くかを自動でチェックする仕組み）が数多く書かれていました。Fable 5も当初、その充実ぶりを評価してくれたほどです。ところが調べていくうちに、あることが分かりました。そのテストが、環境の不整合で、十分に動かなくなっていたのです。テストは「書いてある」だけでは意味がない。「動いて」はじめて、安全網として機能する。書いてあることに安心して、動いているかを確かめていなかった——その事実に、BCPを生業とする私が気づかされたわけです。
この不整合を直し、誰が何にアクセスしてよいかを点検するテストを、約300本、きちんと動く状態に整え直しました。
急所の2つの穴は、いわば緊急手術。
この処方箋の数々は、これから何年もこのサービスと付き合っていくための、体質改善です。
健康診断は、悪いところを見つけて終わりではない。その後の暮らし方まで含めて、はじめて意味がある。そう教えられた気がします。
直したのは、別のAIだった
ここからが、私がいちばん書きたかったことです。
穴が見つかり、処方箋も出そろった。では、誰がそれを実行するのか。
——診てくれたFable 5に、そのまま直させればいい。そう思うかもしれません。でも私は、直す作業は別のAIに任せました。Claude Codeです。中身はOpus 4.8という別のモデルが動いています。
なぜ、分けたのか。
Fable 5は、俯瞰して診断するのが得意な「相談相手」でした。一方、実際にファイルを開いて、正しい場所を正確に書き換え、テストを走らせ、変更を記録する——この「手を動かす」作業には、その作業に向いたAIがいる。同じClaudeでも、得意なことが違うのです。
だから私のやり方は、こうなりました。
相談するAI（Fable 5）に、どこを直すべきか診てもらう。手を動かすAI（Opus 4.8）に、実際の修正をさせる。そして、直したものを本番へ届ける。
急所の2つの穴も、散らかりの片づけも、巨大ファイルの分割も、テストの立て直しも、実際に手を動かしたのはOpus 4.8でした。相談で決まった方針を、黙々と、正確に実行していく。
この「届ける」役割を担っているのが、Manus（マナス）という開発・公開の環境です。なぜManusなのかというと、そもそもbcp-aiの開発とホスティングを、私がManusで始めたからです。
きれいな設計図があってこの三層になったわけではありません。実際に動かしながら、始めた場所を活かすかたちで、自然とこの分担に落ち着いていきました。
つまり、私の作業の流れはこうです。Fable 5に相談し、Opus 4.8に直させ、Manusで本番に届ける。 この数日、私はこの三層を何度も往復しながら、穴を1つずつ塞ぎ、体質を整えていきました。
AIに任せるとは、"どのAIに何をさせるか"を決めること
やってみて、腑に落ちたことがあります。
「AIに任せる」というと、1つの賢いAIに全部を丸投げする姿を思い浮かべがちです。でも、実際にやってみて分かったのは、そうではないということでした。
AIに任せるとは、"どのAIに何をさせるか"を決めることだった。
診断が得意なAIに診てもらい、修正が得意なAIに直させ、公開の仕組みに届けさせる。全体を見て、それぞれに向いた役割を割り振り、判断だけは自分がする。
——これは、私の本業とまったく同じ構造でした。
経営コンサルタントの仕事は、自分がすべてを手がけることではありません。この課題にはこの専門家、この場面にはこの制度、と適材適所で組み合わせ、経営者に伴走する。「誰に何を任せるか」を設計するのが仕事です。
エンジニアなら、あるいは全部を自分の手で書いてしまうのかもしれません。でも私はプログラマーではない。だからこそ、「自分でやる」の代わりに「誰に何をさせるか」で考えるしかなかった。そして、その考え方こそが、複数のAIを束ねて本番のサービスを直しきる——非エンジニアにとって現実的な、たぶん唯一の道だったのだと思います。
"動いている"と、"守れている"は、別のこと
最後に、経営者のみなさんへ。
今回いちばん怖かったのは、潜在的な脆弱性そのものよりも、それが「ちゃんと動いているサービス」の中に、静かに眠っていたという事実でした。
利用者は普通に使えていた。エラーも出ていなかった。私も「動いているから大丈夫」と思っていた。でも、動いていることと、守れていることは、まったく別のことだったのです。
これは、コードの話だけではありません。「うちのバックアップ、最後に復元を試したのはいつだろう」「非常時の連絡網、本当につながるか確かめたことがあるだろうか」——BCPの現場で私がいつも申し上げていることと、根っこは同じです。
さらに大きく広げて考えてみれば、組織。
例えば「今、うちの組織は非常に良く回っている状態だ。しかし、もし何かが発生した場合にこの状態でいられるだろうか？」
備えは、"ある"だけでは足りない。"効く"かどうかを、確かめないといけない。
まずは一度、既にあるものを、普通に動いているものを、見つめ直す、診てもらうことから始めてみませんか。
bcp-ai.com は、中小企業向けの簡易BCPを無料で作成できるサービスです。okawa-office.com では、中小企業の皆様のBCP策定を支援しています。
大川和久（おおかわかずひさ）
中小企業診断士・経営コンサルタント
北海道事業承継・引継ぎ支援センター 日高エリアコーディネーター
独立行政法人 中小企業基盤整備機構 北海道本部 アドバイザー
