社内運用の自動化

夜間の点検からAI会議、朝の報告、精算書の検算までを自動化しています。

8つのサイトを1日3回点検する作業、その結果を読んで変更点を選ぶ作業、8項目からなる経営報告を作成する作業を すべて自動化しました。 取引先26社の精算書を受け取り、発行台帳まで作成する業務も含まれており、 1人が丸1日かけていた業務が1時間になりました。

人が担う業務は 朝8時に届いた報告を読み、優先順位を決めること の一つだけです。6つの段階のうち残りは夜間に自動で完了します。

お客様に提供するものと同じ構成の自動化システムを 社内業務に導入し、毎日運用しています。 社内で先に検証する理由は、 自動化は失敗しても画面上は正常に見えるからです。 記録やリストはそのままなのに新しいデータだけが増えない状態は、画面だけでは分かりません。

VROFは「導入したか」ではなく 「今日届いたか」を基準に確認します。実行ごとに成否を1行ずつ記録し、停止すれば翌朝の報告の冒頭に表示されます。お客様に構築するシステムにも同じ構造を採用します。

この自動化は社内業務用に設計・運用しているため、お客様の事例とは分けてご紹介します。

点検から決定までが、毎日1サイクルで実行されます。

各システムは個別の作業ではなく、一つのサイクルとしてつながっています。 点検 → 判断 → 集約 → 報告までが1サイクルで、このサイクルが毎日同じ時刻に再び始まります。

各段階には 「リスク」を併記しました。その段階をこのように設計しなかった場合に生じる問題です。実際の事例と数値は、サイクルの下の3つの項目でご紹介します。

マークの見方 — 角形の白抜きマークはルール、塗りつぶしのマークは判断の担い手です

• ルール あらかじめ定めたルールに従って処理し、同じ入力には常に同じ結果を返します
• AI ルールでは処理しにくい定性的な判断を担います。早朝会議での判定と、朝の報告冒頭の一文です
• 人 届いた報告を読み、業務の優先順位を決めます

6つの段階のうち、AIが担うのは2つです。 点検・進捗確認・集約・報告の整理は、すべてルールが処理します。 同じ入力に同じ結果が出なければならない段階だからです。AIはルールでは処理しにくい定性的な判断、つまり早朝会議での判定と朝の報告冒頭の一文にだけ使います。 報告書の作成はAIに任せません。 8項目の数値、完了項目と定期項目の区分、優先表示は、すべてルールが確定します。

1サイクルのうち 人が関わるのは最後の一段階です。点検・判断・集約・送信は人を待ちません。 修正作業は自動化していません。点検は照会のみで、対象を変更しません。確認する側が対象を変えると、以降の数値を信頼できなくなるためです。そのため朝に届くのは修正済みの結果ではなく、 修正すべき項目を整理した報告です。

人が修正した内容は、次回の点検にそのまま反映されます。 あるサイトに検索エンジン向けのサイト所有者の表示を新たに追加したところ、特に知らせなくても、次の点検の「変わった項目」リストにその項目が挙がりました（2026-08-09）。

サイクル外で追加実行される作業

• 07:30 取引先の精算書の集約と検算
• 09:00 · 15:00 · 21:00 支援事業の公募情報の収集

サイクルの7回と上記3つの作業を合わせて、1日 10回実行されます。07時30分には、会議結果の集約と精算書の検算が同じ回で実行されます。

VROFは、AIの「処理完了」の報告を毎日確認し直します。

AIは毎日答えを出しますが、 その答えが実際に反映されたかどうかは教えてくれません。 エラーなく成果物が毎日積み上がるため、何か月も経ってから成果を問うことになります。

VROFは、提案が実際に処理されたかどうかを 自動で表示する仕組みを設け、前日の提案を見直す手順を毎日実行しています。提案だけでなく、 その表示が正しいかどうかも次の回で確認し直します。

「処理完了」を自動で表示する仕組みを設けるだけでは、その仕組みが正しいかどうかは確認されません。 処理済みと表示されたのに実際には反映されていない案件が混ざり、 完了していないのに完了したように見える状態になります。エラーも警告もないため、ログ上は最も正常に見えます。VROFのシステムでも9件中5件がずれていましたが、 前日の提案を見直す手順が、次の回でそれを見つけました。

• 会議前に前日の提案を確認

  前回の提案とその後の変化を会議資料の冒頭に入れ、前日の議論を知らないまま会議が始まらないようにします。

• 議事録の定型様式

  文章だけでは翌日に照合できないため、提案ごとに何を・誰が・なぜ・何で確認するかを所定の欄に記録します。

• 点数表ではなくログに基づく評価

  提案・発言・処理時刻をログに記録し、成果はログから算出します。点数表を設けると点数を上げる方向に業務がゆがみ、AIはその傾向がより強くなります。

• 前回の提案がある場合のみ判定

  前日の提案がなければ判定欄は空欄のままにします。必ず埋めるよう求めると、AIが根拠のない内容を作り出すためです。

「確認した値だけで完了を判定する」が原則で、 各提案が条件を満たしたかどうかがログにそのまま残ります。 満たせなかった提案も併せて記録し、後から結果を誇張しないようにしています。

最近の議事録には次のような記録があります。ある数値が減ったことについて 成功か失敗かは読み取らなかったと書き、「原因の記録がない」に分類しました。増えた数値についても 「検索の成功」とは断定しなかったと書いています。流入経路をまだ区別できていないという理由でした。 VROFは「分からない」をそのまま記録するよう設計しました。 そうすることで、実際に改善したときにその報告を信頼できます。

2026年8月23日の会議は12回目で、 新規提案4件に対し、前回提案の判定が27件でした。新しい提案よりも前回提案の見直しに6倍以上の比重を置いており、その回が自ら記録した完了件数は 0件です。 AIが自ら「完了」を付けられないようにすると、完了欄には0が表示されます。これが正確な数値です。 「完了12件」と表示されたログよりも、 0と表示されたログのほうが信頼できます。

経営報告の数値はルールが確定します。

AIは指示どおりに文章を書きますが、その過程で 数字が変わることがあります。 たとえば「不足額 ○○ウォン」が特定の日付に必要な金額なのか、請求期間全体の合計なのかは、報告だけでは分かりません。

実際にVROFの報告でも、合計が特定日の必要額として読まれ、 4倍近く膨らんだことがあります。 解決策は「より良いモデル」ではありませんでした。 判断する段階と転記する段階を分けなければ、同じ問題が繰り返されるということです。VROFはこの区分を先に決めてから構築します。

• 元データに基づく分類

  完了項目、毎月自動で処理される定期項目、実際の業務ではないまとまりを、既存データの項目で区分します。報告に表示された項目は、元データの中でそのまま見つけられます。

• 一部の照会に失敗しても報告を送信

  確認できなかった項目は報告の冒頭に表示します。1か所のエラーで当日の報告全体が欠けることはありません。

AIに渡している指示文の原文です

• 数字と項目を新しく作ったり変えたりするな
• 一字も変えずにそのまま写せ。要約も、統合も、削除もするな
• 金額を新しく計算するな。資金調達の方法をでっち上げるな。振り込みを断定するな
• 元資料にないニュース・市場見通し・事業アイデアを付け足すな

指示文にはもう1行あります。 このシステムで最も重要な一文です。

「照会失敗」がある場合は、その項目が埋める節の数値を「なし」ではなく「見られず」として扱え。

「出ていくお金はない」と「出ていくお金を確認できなかった」は、まったく別のことです。 2つの状態を同じ形で表記すると、静かな朝が本当に安心してよい状況なのか判断できません。報告を作る段階で先に区別しておく必要があります。

AIが書く一文は「今日は何から処理すべきか」です。 優先順位の基準も併せて渡します。外部の期日が決まっている業務が最優先、遅れると加算税がかかる業務は午前中に、入金につながる業務はその次、外部の期限がない開発はその後です。 この判断はルールで決めるのが難しいものです。 その日に重なる業務によって答えが変わるためです。

点検システム自体の停止も確認します。

点検は、実行されたときにしか結果を知らせられません。 そのため、サーバー全体が停止した朝は すべての点検が沈黙します。 警告がないため、画面も報告も正常に見えます。実際に朝の6時間がまるごと抜けた日があり、その時間帯の作業はすべて欠落しましたが、異常を知らせた項目はありませんでした。

「通知が来ない状態」と「通知することがない状態」が同じに見えることは、自動点検を導入した企業が最も遅く気づく問題です。

• 時間帯別の実行記録の集計

  個別の点検とは別に時間帯ごとの実行件数を集計し、停止した時間帯を確認します。読み取れなかった場合は0ではなく「読み取れず」と表記します。

• 報告の確認範囲を明記

  該当項目の末尾に次の文言を記載します。

この節は、08:00の報告そのものの失敗は検知できない。報告がまったく届かなかった日がその合図である。

したがって御社では、「朝の報告が届かなかった」という事実そのものが最も重要な警告になります。 この点を把握しておけば、静かな朝を見誤ることはありません。

社内運用自動化の主な事例です。

サイクルの最初の段階と、サイクル外の07時30分の作業は、それぞれ事例としてご紹介します。社内システムのため、公開URLの代わりに モックデータで再構成した画面と、ツールが自ら記録した数値を掲載しています。

社内で検証した自動化の仕組みを、お客様の業務に適用します。

複数のシステムに散らばった数値を、毎朝1通の報告で受け取れます。倉庫の在庫、売掛金、前日の売上、夜間の自動化の実行状況など、 対象は違っても構造は同じです。

AIに業務を任せると提案は積み上がりますが、実行されたかどうかは別途確認が必要です。VROFが構築するのは、 前日の提案を見直す仕組みです。担当分野が5つでも10でも同じ構造で拡張でき、都合のよい数値だけを選んだ報告を防ぎます。

また、 AIが作った数字が経営判断に紛れ込みません。 数値・分類・選別をすべてルールが確定するためです。 「この数字はどこから出たのか」に答えられない報告は作りません。

社内運用自動化の適用範囲

このページのシステムは、VROFの社内業務の手順に合わせて設計した社内ツールです。販売している製品は 自社製品 ページでご紹介しています。このシステムは、 同じ方法をお客様の業務にも適用できるという根拠です。

分野別には、データ収集は Webデータ収集、収集したデータの基準統一と集計は データ分析、ルールでは処理しにくい判断は AI活用です。

運用中の自動化が動いているかを点検します。

運用中だと思っている自動化が、実際には止まっていることがあります。最後に新しいデータが入った日を基準に点検します。

1営業日以内に返信