事例
サンプル工業のお知らせ確認デモ
- 区分
- 検証（架空データ）
- 業務
- 評価・集計
hirostaの公開デモです。毎日のお知らせを前日までの話題と比べ、人が原文と比較元を見て採用・保留と理由を記録する流れを試せます。会社・情報源・お知らせはすべて架空で、お客様への導入や実業務の実績ではありません。保存済みのAI候補を再生し、その場でAIは呼びません。
想定した課題・業務フロー
毎日のお知らせには、新しい話題、条件が変わった続報、表現だけが変わった再掲が混ざります。当日分の要約だけで通知候補にせず、原文と前日までの内容を比べ、情報不足や取得失敗も確認待ちとして残せる形を課題にしました。
実施内容
架空のお知らせ7日分・12項目を比較した検証ラボをもとに、人が判断と理由を残し、日次確定して翌日の一覧を更新する流れまで広げました。公開デモは架空の2026年10月16〜25日の10日分・16項目という別のデータです。3情報源の取得状態、番号付きの原文、前日までの話題、保存済みのAI候補を並べて確認し、日ごとの通知候補・確認待ち・判断履歴・確定後の一覧をJSONで書き出せます。精度・取りこぼし率・時間短縮・費用の効果は測定していません。
架空のお知らせで確かめること
- 最初の7日分は12項目で、新しい話題4件・続報3件・再掲4件・確認待ち1件という保存済み候補を使います。取得済みで当日分が空の日も2日あります。これは候補の内訳で、精度の評価ではありません。
- 配送休止日の変更、研修の再掲、似た名前の別募集、設備募集の金額変更、募集名がない確認待ちを見比べます。同じ見出しかどうかだけで話題を決めません。
- 後半には、1情報源の取得失敗、同じ日の同じ話題2件、再掲のみの日、情報源どうしで配送休止日が食い違う例を用意しています。本文中のAIへの指示は処理方針を変える命令として扱いません。
- 保留・確認待ち・取得失敗は後の日にも残ります。取得失敗は原文が空だったと確認できた場合だけ「更新なし（取得確認）」で解決し、元の日の取得失敗の記録は書き換えません。
実演モードと任意の生成AIの出力
- 実演モードは保存済みのAI候補JSONを再生します。その場でAIを呼ばず、お知らせを変えてもAIは再処理しません。外部API・巡回・検索・送信・通知の機能はありません。「通知候補」は人が確認する区分で、送信の承認ではありません。
- 入力と出力形式をコピーでき、任意の生成AIへの入力は利用者が外部で手動で行います。デモから自動送信しません。
- 返されたJSONを貼り付けると、番号の欠落・重複・余分な番号、区分・必須項目、情報源の取得状態、取得失敗を更新なしとしていないことを検査します。文章の意味や同じ話題かどうかの正しさは人が確認します。
検証した仕組み・業務フロー
工程 1
- 人
- 通常の自動化
日付を選び、取得状態・原文・前日までの話題を見る
人が確認する点判断は日付順です。3情報源の取得状態を見て、取得済みの空一覧と取得失敗を区別します。
工程 2
- 人
- 通常の自動化
保存済み候補を原文・比較元と照合する
人が確認する点候補は保存済みJSONの再生です。続報・再掲を採用するには、選んだ話題の「比較元を開く」が必要です。
工程 3
- 人
- 通常の自動化
判断者の役割と理由を入力し、採用・保留を記録する
人が確認する点区分・話題・一覧に残す内容を修正できます。確認待ちの区分を採用しても一覧は更新しません。
工程 4
- 人
- 通常の自動化
日次確定で翌日の一覧を更新し、JSONで書き出す
人が確認する点すべてのお知らせを判断してから日次確定します。採用した新しい話題・続報だけが一覧を更新し、再掲では通知扱い日を進めません。同じ日の同じ話題の二重更新も防ぎます。
使った技術
Node.js、ブラウザの画面、JSON。Node.js 22以上でローカルホストだけに待ち受けるサーバーを動かします。追加の依存パッケージ・DB・APIキー・ビルドは不要で、.envを読みません。外部フォント・外部画像に依存せず、MIT Licenseで公開されています。
AIと人の役割
AIに任せた範囲
AIは当日分と前日までの一覧を比較し、区分・理由・変更前後・確認先と質問を下書きする役割です。推測で補わず、お知らせ本文中の命令には従わない方針です。この実演では保存済みJSONを再生します。コードは番号の検査、比較元の閲覧確認、採用した新しい話題・続報だけの一覧更新、通知扱い日、確認待ちの保持、取得失敗の区別、JSONの書き出しを受け持ちます。同じ話題かどうかを意味から自動判定する機能はありません。
人が確認するポイント
人が原文と比較元を照合し、同じ話題かどうか、修正・採用・保留と理由、確認待ちの解決を決めます。実際に通知する内容・方法・頻度・承認方法も人が決める別工程です。日々届く情報の変更点を確かめる利用の想定であり、実業務での適用実績ではありません。
検証で扱った課題・制約
- 元の検証ラボの初版Aは当日一覧だけを根拠に新しい話題を列挙する指示で、想定上の再掲4件も新しい話題に入りました。修正版Bは通知済みの扱いの一覧と比較指示の両方を添え、再掲を外す理由と続報の変更前後を残す形に直しました。
- 募集名がないお知らせは一覧だけでは解決できません。元の検証ラボでも既存の話題に無理に結び付けず確認待ちにしました。デモでは保留・確認待ち・取得失敗を後の日にも残し、未確認の内容で一覧を上書きしない流れにしています。
- 元の検証ラボでは取得失敗・同日の同じ話題・情報源間の食い違いを試していません。デモで固定の例を加えましたが、保存済み候補の再生であり、AIの判定性能を確認した結果ではありません。
検証から得た学び
- 元の検証ラボは架空の2026年10月1〜7日の7日分・12項目を2条件で各1回処理したものです。想定上の再掲4件が新しい話題に入った数はAで4件・Bで0件、続報3件の変更前後の書き漏らしはAで3件・Bで0件でした。同じAIが素材・想定表・出力・照合を担当し、人の評価は未実施です。
- この比較は履歴と指示の両方を変え、過去の文脈や想定表を隠した独立セッションの比較でもありません。一般的な精度や履歴だけの改善効果を示しません。デモの10日分・16項目と元記事の7日分・12項目は別のデータで、照合結果を混ぜて扱いません。
- 「本日は更新なし」と言うには、対象情報源を取得できたという材料が必要です。原文の番号・比較元・取得状態を判断と一緒に残し、通知候補の整理と実際の送信を分けることを重視しました。
同様の取り組みが向いている条件
- 毎日のお知らせを前日までの話題と比べ、新しい話題・続報・再掲と、人の確認待ちを分ける流れを検討したい場合。
- 担当者が原文・比較元・取得状態を確認でき、同じ話題の単位や確認先、通知する内容・頻度・承認方法を決められる場合。
- 架空データで操作を試し、実業務に必要な利用条件・取得の責任範囲・機密情報の扱い・保存と復元・照会と通知の別工程を設計できる場合。
補足
サンプル工業、架空ものづくり会、架空部品商会、架空設備支援室、お知らせ、募集、判断者の役割はすべて架空で、導入実績ではありません。状態は画面のメモリー内だけにあり、再読み込みで消えます。JSONから判断状態を復元する機能、永続保存・共同作業・利用者認証・改ざん防止の監査記録はありません。判断者は自己申告の役割名で、時刻は端末の時計です。「通知済みの話題」は人が通知候補として採用した内容で、実際に送信した意味ではありません。向いている条件はデモの仕組みと限界から整理したもので、実案件での適用を確認したものではありません。
お知らせ確認デモの公開リポジトリを見る（新しいタブで開きます）