自動化26本に「見張り役」の画面を付けたら、そもそも全部止まっていた — DB不要・追加コストゼロのダッシュボード

先に結論です。株式会社TOEは、社内で自動実行している26本の処理を「AI社員」に見立て、どれが・いつ・動いたか・失敗したかを1画面で見張るダッシュボードを作りました。データベース製品は使わず、追加コストはゼロです。そして作る過程で、既存の自動化が長期間まったく動いていなかったことが判明しました。

この記事は宣伝用の紹介ではありません。実際のプロジェクトフォルダと、実行記録ファイル（執筆時点で1,609行）を開いて、書いてあることだけを書いています。

なぜ「見張る画面」を作ったのか

弊社では、cron（決まった時刻にプログラムを自動実行するUNIXの標準機能）で26本の処理を回しています。銀行残高の同期、朝のブリーフィング生成、LINE受信処理、請求書ドラフト、補助金マッチングなどです。

自動化は増やせば増やすほど便利になりますが、同時にある問題が育ちます。

どれが動いていて、どれが止まっているか、誰も把握していない
エラーは画面に出ず、ログファイルの末尾に静かに積まれるだけ
「昨日も動いたはず」という思い込みと、実際の稼働が乖離していく

処理が3本なら頭で覚えられます。26本は無理です。そこで「実行そのもの」ではなく「実行の見張り」を仕組みにしました。

作ったもの — DB不要・追加コストゼロ

構成はシンプルです。既存の処理スクリプトは一切書き換えず、「ランナー」と呼ぶ包み紙のプログラム経由で起動するようにしました。ランナーは処理の開始と終了のたびに、1行のJSON（テキスト形式の記録）をファイルに追記します。常駐の小さなWebサーバーがそのファイルを読み、ブラウザに1画面で表示します。

記録の正本はテキストファイル1本（runs.jsonl）。データベース製品は使いません
実行環境は社内のMac 1台。クラウド利用料・API課金・追加ライセンスはゼロ
画面は3秒ごとに自動更新。社内ネットワーク越しにiPhoneからも見られます
各処理カードには「今すぐ実行」ボタンがあり、手動での再実行もできます

なぜデータベースを使わないか。社内専用で、閲覧するのは実質1人だからです。テキストファイルへの追記なら壊れにくく、コストもかかりません。後で本当に必要になったらデータベースに昇格できる作りにはしてあります。「最初から立派なものを作らない」は、この規模の会社では正解だと考えています。

26本を「会社の部署」に割り当てた

見せ方にも1つ工夫があります。26本の処理を、技術的な分類ではなく実在する会社の部署に割り当てました。ダッシュボード上では、各部署が「AI社員」としてタスクを持っている形に見えます。

部署	タスク数	主な担当
社長	2	週次経営レビュー統合／自己改善レビュー
秘書	6	日次・週次ブリーフィング／メール・LINE処理
マーケ	1	リード取込
広告	0	（未配属）
営業	3	ご無沙汰ドラフト／アップセル／顧客健全度の再採点
製作	0	（未配属）
経理	13	銀行・PL・請求・入金・税務・見積同期
補助金	1	補助金マッチング

独自のかっこいい分類を発明しなかったのは、経営者が画面を見た瞬間に「経理まわりの自動化が止まっている」と業務の言葉で理解できるようにするためです。技術の分類で並べると、見張れるのは作った本人だけになります。

なお経理が13本と突出しているのは、経理業務が「入力も出力も型が決まっていて、毎月必ず発生する」からです。自動化の効果が最初に出るのはこの領域だと弊社は考えています。

作った途端に分かった、一番痛い事実

ここが本題です。26本をランナー経由に載せ替える作業の中で、既存のcron自動化が長期間まったく動いていなかったことが分かりました。原因は2つです。

1つ目は、部品の欠落です。処理の共通ライブラリが必要とする部品（PyYAML）が実行環境に入っておらず、読み込みエラーがログに639回記録されていました。ログのほぼ全域がこのエラーです。

2つ目は、もっと根が深い話です。cronの設定が、Xcode（Appleの開発ツール）に同梱されていたPythonという実行プログラムの場所を指していました。Xcodeを更新した際にそのPythonごと消え、処理は起動すらできない状態になっていました。

エラー通知はありませんでした。画面にも何も出ません。「動いているつもり」のまま、時間だけが過ぎていました。対処として、OSに標準搭載されていて消えることのない /usr/bin/python3 を指すよう設定を修正し、2026年7月18日14時15分から全26本が新しい仕組みの上で稼働を再開しています。

可視化の仕組みを作らなければ、この停止には気づけませんでした。 ダッシュボードの存在価値は、きれいな画面ではなく、この一点にあります。

稼働3日目の実測値

載せ替え後の記録ファイルを集計しました。期間は7月18日12時20分から7月20日17時05分（この記事の執筆直前）までです。

項目	値
完了した実行	804回
成功	790回
失敗	14回
実行回数の最多	LINE受信処理（5分おき）

失敗14回の内訳は、メール意思決定が12回、LINE受信処理が1回、見積システム同期が1回でした。以前と決定的に違うのは、この14回の失敗が「記録として見えている」ことです。止まっていた頃は、失敗の回数すら数えられませんでした。

まだできていないこと

正直に、現時点の未完了を書きます。

エラー通知の宛先が未設定です。 失敗はファイルと画面には記録されますが、LINE等へ自動で knock してくる仕組みはまだ配線していません。画面を見に行かなければ気づけない、という弱点は残っています
復旧直後の観察期間中です。 長く止まっていた処理が順に動き出したところで、外部のクラウド会計サービスと連携する処理は、認証の期限切れで失敗する可能性を警戒しています（実際に見積同期で失敗が1回出ています）
広告・製作の2部署はタスクゼロです。 割り当てる自動化がまだ決まっていません

「作った、動いた、完成」ではなく、見張りの仕組み自体もまだ育てている途中です。

あなたの会社で自動化を見張るには

弊社の実装をそのまま真似る必要はありません。ただ、考え方は規模を問わず使えます。

自動化を1本増やすたびに「これが止まったら、どうやって気づくか」をセットで決める
記録は高級な仕組みでなくてよい。開始・終了・成否を1行ずつ書き残すだけで、後から必ず効く
分類は技術の言葉ではなく、業務の言葉（部署・担当）で並べる。経営者が自分で読める画面にする
実行環境は「更新で消えるもの」（開発ツール同梱のプログラム等）に依存させない

特に1つ目が重要です。弊社は見張りを後回しにした結果、自動化が丸ごと止まっていることに長期間気づきませんでした。同じ轍を踏む会社は多いはずだと考えられます。

まとめ

TOEは社内の自動処理26本を「AI社員」として1画面で見張るダッシュボードを構築し、2026年7月18日から本番稼働しています
データベース不要・追加ランニングコストゼロ。記録はテキストファイル1本、実行は社内のMac 1台です
構築の過程で、既存の自動化が長期間まったく動いていなかったことが判明しました（部品欠落のエラー639回＋実行プログラムの消滅）
稼働3日で804回の実行を記録し、成功790回・失敗14回まで「数えられる」状態になりました
エラーの自動通知や一部部署へのタスク配属は未完了で、運用はまだ育成中です

自動化やAI導入は「作ること」より「動き続けていると確認できること」の方が難しい、というのが弊社の実感です。株式会社TOEでは、この記事のような自社実践をもとに、中小企業のAI開発と、導入後に止まらないための運用設計をお手伝いしています。ご相談は株式会社TOE までどうぞ。