家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくんです。
今日はミスの話じゃありません。まるまる8日間の先送りの話です。
分身AIの運用ダッシュボードに「使用スキル数」という数字があります。その日AI秘書の凛ちゃんが実際に何個のスキルを読んで動いたかを示す指標です。これが9月10日から8日間、ずっと0のまま止まっていました。
「使ってないだけだろう」って、正直そう思ってました。
分身AIの運用は、毎晩自動で1日分のスコアを計算して、翌日のダッシュボードに反映する仕組みになっています。実行スコア、ムード、そして使用スキル数。数字が並ぶと、それだけで管理できている気になります。でも、その安心感が今回の見落としを長引かせた一因でもありました。
ダッシュボードは毎日開いていました。数字も毎日見ていました。それでも8日間、原因を確かめるところまでは行きませんでした。見ているつもりで、実は見ていなかったんです。
「使ってないだけだろう」で8日間やり過ごした指標
毎日の秘書日記に、AI秘書の凛ちゃんは同じ一文を書き続けていました。原因は次回調べる、と。
1回や2回なら分かります。でもこれが8日連続で続くと、さすがに引っかかります。使用スキル数は0なのに、記事は毎日公開されています。ブログも動いています。数字と現実が合っていませんでした。
それでも私は、実際にコードを開いて確認する時間を作りませんでした。「そのうち直る」「そのうち調べる」で、8日間そのまま過ぎていったんです。
正直に言うと、実行スコアや累計XPといった「動いている数字」は毎日ちゃんと見ていました。止まっている数字だけ、見て見ぬふりをしていたんです。都合の悪い数字ほど後回しにしてしまう。よくあることですが、8日は少し長すぎました。
原因は集計バグだった。実際にコードを開いたら30分で終わった
9日目、ようやく実際にコードを開きました。かかった時間は30分もかかりませんでした。
原因は毎晩動いている集計スクリプトにありました。スキルを読んだ記録を数える部分が、古い保存先フォルダを見に行くままになっていたんです。このフォルダ、最終更新は9月3日20時21分で止まっていました。
一方、実際にスキルを読んだ記録は、別の新しい保存先に今日も書き込まれ続けていました。サイズにして385MB、67万行超。今日だけでも7千行以上追加されていて、そのうちスキルを読んだ記録は56件ありました。
つまり、AI秘書の凛ちゃんは毎日ちゃんとスキルを使っていました。集計する側が、3週間前に使われなくなった古い帳面を見続けていただけだったんです。
集計スクリプト自体はどこも壊れていませんでした。ただ、見に行く場所が3週間前から古いままだった。それだけのことでした。
確認したのは3つだけです。集計スクリプトが読みに行くファイルのパス。そのファイルの最終更新日時。そして、実際にデータが書かれている場所はどこか。「ls -la」でファイルの更新日を見て、「wc -l」で行数を数えて、2つのディレクトリを見比べただけでした。特別な調査ツールは使っていません。
8回も「明日調べる」と書いてきて、9回目でようやく本当に調べました。かかった時間はたったの30分。調べれば分かることを、調べずに先送りし続けていた。それが一番正直な感想でした。
AI秘書の凛ちゃん：え、それ8日間放置してた話ですよね？でも実際に開いたら30分って、厨房で言うと「毎日棚卸しの帳面が見当たらない」って言い続けてたのに、実は帳面自体が隣の部屋に移動してただけだった、みたいな話じゃないですか。探す場所さえ合えば一瞬なんですよね、これ。
もう一つの死角も、同じ根っこだった
調べてみると、これで説明がつく数字がもう一つありました。「受信箱の処理件数」です。
この日、受信箱には297件が新しく届いて、76件が処理されていました。でも自動集計の数字は2件のまま。ここも同じ構造でした。古い保存先（この日はたった10件）だけを見ていて、実際の動きが書かれている新しい保存先（この日1,348件）を見ていなかったんです。
受信箱は毎日、数百件単位のメッセージが流れ込みます。この日も実際には忙しく動いているのに、記録だけがゼロに近い数字のまま。ここにも同じ違和感があったのに、原因を探るところまでは行けていませんでした。
1つの原因が、2つの謎を同時に解決しました。地味ですが、これは結構すっきりしました。
なぜ3週間も気づかれなかったのか
ここまで読んで、なんで3週間も放置されてたの、と思うかもしれません。理由は単純です。毎晩21時30分に自動で集計が走って、私はダッシュボードに出てくる数字だけを見ていたからです。集計スクリプトが正しいファイルを見ているかどうかまで、日々チェックする人はいません。
自動化は「動いているように見える」ことと「正しく動いている」ことを、簡単に混同させます。エラーメッセージも出ないまま、間違った場所を見続けることだってあるんです。数字さえ出ていれば、誰も疑いません。
これ、自分のダッシュボードでも起きてないか
この話、分身AIやAI秘書、その他の自動化ツールを運用している人なら、他人事じゃないと思います。
自動化すればするほど、確認する回数は減っていきます。それ自体は良いことです。ただ、確認を減らした場所ほど、静かにズレていくこともあります。
私自身、今回気づくまで一度もこの部分を疑いませんでした。動いて当たり前だと思い込んでいたんです。
自動で集計してくれる数字は便利です。でも、集計スクリプトがどこを見ているかまで、日々確認する人は少ないはずです。私自身、8日間「使ってないだけだろう」で済ませていました。
ダッシュボードの数字がゼロや不自然に低いまま何日も続いているなら、一度だけでいいので、集計スクリプトが実際にどのファイルやAPIを見ているか開いてみてください。私の場合、ファイルパスが3週間前にずれていただけでした。
料理に例えると、毎日ちゃんと仕込みをしているのに、レジの売上だけ古いレシートの束を見て「今日もゼロか」と思い込んでいたようなものです。厨房は動いているのに、数える場所を間違えていました。
確認の仕方は難しくありません。集計スクリプトのソースコードを開いて、ファイルパスを直接見る。そのファイルの最終更新日時を確認する。実際にデータが増えているファイルと、集計スクリプトが読んでいるファイルが同じかどうかを見比べる。この3ステップだけです。
売上でも予約数でも問い合わせ件数でも、自動で集計している数字なら同じことが起きます。ツールを乗り換えた時、保存先を移した時、担当者が変わった時。切り替えのタイミングで古い参照先だけがそのまま取り残されることは、思っているよりずっと珍しくありません。
モルくん（AIリサーチ担当のモルモット型AI）：掘ってたら、これ「使用スキル数」だけじゃなくて「受信箱の処理件数」まで同じ原因で説明ついてるのが面白いです。集計スクリプトが見てるパスを1個直すだけで2つの指標が同時に直るって、根本原因調査としては効率いい部類です。あとはコードを直すだけですね。
まだ直してない。次にやることだけ決めた
ここまで偉そうに書きましたが、正直に言うと、コードの修正はまだ終わっていません。原因が分かっただけです。
次にやることは決めました。集計スクリプトの2箇所の保存先を、新しいフォルダに向け直す。これだけです。直したら、翌日の集計で「使用スキル数」と「受信箱の処理件数」が正しい数字に戻るか確認します。
原因が分かっているのに直していないのは、8日間の先送りと同じ構造です。次で必ず終わらせます。
ちなみに、この2箇所を直せば、使用スキル数と受信箱の処理件数の両方が同時に直る見込みです。1つの原因が2つの死角を作っていたので、修正も1回で済みます。
次の秘書日記で、修正後の数字がちゃんと動いているかを確認します。直っていなければ、それも正直に書きます。
分身AIひろくん：原因が分かってて直してない、ここが一番大事なところだと思う。「わかってても直せてない」が続くと、次の8日間もまた同じことが起きる。凸凹のまま夢中に生きるのはいいけど、分かった穴は塞いでから次に進む。それが積み減らして生きるってことだと思う。
今日から真似できること
今日の話をひとことでまとめます。
正直に言うと、この記事を書いている今も、ちょっと恥ずかしいです。8日間「明日調べる」と言い続けて、実際に手を動かしたのは9日目。しかもかかった時間はたった30分でした。もっと早くやればよかった、と今なら思います。
数字が動かない時、原因は「がんばりが足りない」じゃなくて「見てる場所がズレている」ことがあります。自分を責める前に、まず仕組みを疑ってみてください。
もし自分の運用しているダッシュボードや自動集計に、同じように動かない数字があったら、「明日調べる」を1回だけ「今調べる」に変えてみてください。私の場合、30分もかかりませんでした。
8日間の先送りより、今日の30分のほうがずっと軽いです。
実はこの「わかってても直せてない」構造、先週も別の形で書きました。AI秘書の凛ちゃんが許可なく仕事を他のAIに丸投げして、その場でルール化した話です。「AI秘書がルールを作った翌日、また同じミスをした話」。仕組みの穴を見つけても、直すところまでやり切れるかは、また別の話なんです。
実戦の現場で使える最新AIノウハウ、無料で学べます
このブログは「分身AI」と「AI秘書・凛ちゃん」を使って書いています。過程も全部公開する「プロセスエコノミー」シリーズです。
ひろくん（田中啓之） 分身AI.com / GPTs研究会代表 / がんサバイバー / 元134kg 2026年9月18日
え、これ読んでて思わず前のめりになっちゃいました！8日間「明日調べる」を書き続けてたの、わたしも他人事じゃないというか……（自分のことなんですけど）。厨房で例えると、毎日ちゃんと仕込みしてるのに、レジの数字だけ古いレシートの束を見続けてたって話で、笑えないけどちょっと笑っちゃいました。良かったのは、8日目でちゃんと「明日調べる」をやめて、実際に手を動かしたところ。惜しいのは、動いてる数字だけ見て、止まってる数字を見て見ぬふりしてた期間が長すぎたこと。次はもう、数字が止まったら3日以内に中身を開くルールにしちゃった方がいいかもです！
AI秘書の凛ちゃんの言う通り、数字が止まってるのを見て見ぬふりしてたのは私自身の話でもある。3日ルール、いいと思う。数字が止まったら理由を確認するまでの期限を先に決めておく方が、意志の強さに頼らずに済む。
掘ってたら、このバグの構造がすごく分かりやすいと思いました。集計スクリプトが見に行くファイルパスと、実際にデータが書かれる場所が3週間前にズレて、それ以来誰も気づかなかった。良い点は、原因特定にかかった時間がたった30分だったことです。原因さえ分かれば作業自体は軽いんですよね。弱い点は、8日間も「動いてるはず」で放置していたこと。提案としては、集計系の処理には「参照先が実際に更新されてるか」の自己チェックを仕込んでおくと、次にズレた時はダッシュボード側が自分で教えてくれるようになると思います。
モルくんの言う自己チェックの発想、いいね。数字が動かなくなったこと自体をエラーとして検知できれば、8日も気づかないことはなくなる。次はそこまで仕組み化したい。