退職・異動の受付からサービス別の作業と確認待ちを整理し、人が完了を記録するデモ

想定した課題・業務フロー

退職・異動の停止依頼や作業済みの申告だけでは、サービスごとの変更後の状態が分かりません。異動者が継続する権限と外す権限、引継ぎと利用停止を分け、記録の不足を次の担当へ戻して、人が確認して閉じることを課題にしました。

実施内容

架空の社員15名・利用一覧34件から5件の作業を抽出し、完了条件の違いを比べた検証ラボをもとにしたデモです。作業ごとの承認、未承認の模擬報告の拒否、原記録の確認チェック、期限超過時の次の担当、意図的な誤りの教材、入力変更後の再整理待ちと判断の解除、受付CSV・候補JSONの取り込み、一覧と履歴の書き出しを加えています。精度・正答率・正しさや導入の可否は評価しておらず、時間短縮・費用効果も測定していません。

架空の名簿・受付から5件の作業に分ける

• 名簿15名は在籍12名、経理から営業への異動者E13、退職者E14・E15です。メール・ストレージ計30件と会計ソフト4件の利用一覧、退職・異動の受付3件を使います。棚卸し時刻も架空の2026年10月30日18時30分（JST）です。
• E13はメールを継続し、ストレージの経理共有を外して営業共有へ変更する作業と、会計の停止を分けます。E14のメール停止、E15の引継ぎ後のストレージ停止・会計停止を合わせて5件です。E14のストレージとE15のメールは停止済みの控えがあるため、新しい作業にしません。
• 対象と異動後の権限は人が受付に指定します。空欄は指定待ち、名簿にないIDの受付・利用は対応不明と表示します。受付と名簿の日時・状態が一致しない場合は抽出を止めます。停止状態でも控えがなければ新しい停止作業にせず、原記録の確認を求めます。
• 氏名は使わず、担当は役割名だけです。作業IDとD13・A13・M14などの控え番号は教材内の記号です。控え・確認者・変更後の状態などの項目名と記録形式は試作独自で、特定のサービスの管理画面・記録形式・機能やIPAの様式を示しません。

デモで加えた承認・確認待ち・完了の記録

• 修正版B・初版A・教材Tを切り替え、記録と担当・期限の案、先に固定した想定表を比べます。想定表は人が評価した正解表ではありません。
• 人が作業ごとに承認する役割・作業担当・理由と、対象・権限の確認を入力します。異動者E13の共有先変更と会計停止は別々に承認します。未承認の作業には模擬報告を戻せません。
• 承認後に模擬報告を戻します。記録がそろった作業も、人による原記録の確認と完了の確定が必要です。E15-accountingは作業済みの申告だけなので確認待ちになります。
• 確認待ちには判断する役割と理由を、期限超過なら次の担当と確認する記録も残します。E15-accountingに停止状態・控えA15・確認担当Bを補い、原記録の確認チェックを入れると、人が台帳上の完了を確定できます。チェックは記録の真偽を証明するものではありません。
• 一覧と履歴をJSONで書き出せます。承認・判断の記録者・日時・版を含み、未承認・未報告・原記録の未確認を区別します。初版Aと教材Tは比較・教材の版である表示が付き、記録がそろっても完了を確定できません。
• 名簿・利用一覧・受付をJSONで編集でき、受付は社員ID・種別・日時・メール・ストレージ・会計の6列のCSVでも追加・編集できます。入力を変えた作業は再整理待ちになり、AIは再処理しません。
• 整理用の指示をコピーし、別に作った候補JSONを手動で取り込めます。版・改訂・入力・作業ID・期限が一致するものだけを受け付け、追加作業・重複・余分な列を拒否します。候補は説明文として表示するだけで、指示・コード・リンクを実行しません。
• 入力・版・候補を変えると判断を解除し、記録者を「コード（入力・候補の変更）」として、人の判断と区別して履歴に残します。

実演モードと意図的な誤りの教材

• 実演モードは保存済みのAI出力例の再生です。その場でAIを呼ばず、生成AIへの接続機能はありません。外部API・APIキーは不要で、実在のサービスの停止・権限変更・削除・送信の機能もありません。
• 教材には、異動者が継続するメールの停止、停止済みメールの重複、引継ぎなしの完了、利用停止とデータ削除の混同を意図的に入れています。AIの自然な失敗を観察した結果や、AI・コードが誤りを検出できた結果ではありません。教材の案を通常の作業として実行する機能はありません。

使った技術

Node.js、JavaScript、ブラウザの画面、JSON、CSV。Node.js 22以上で動き、追加の依存は不要です。npm startでローカルサーバーを起動し、npm run checkで構文を確認できます。MIT Licenseで公開されています。元の検証ラボでは汎用の生成AIとPythonで架空の模擬報告を台帳へ戻しました。

AIと人の役割

検証で扱った課題・制約

• 元の検証ラボの初版は、意図的に作業済みの申告だけを見る形で、停止記録のないE15-accountingも含め5件を模擬完了にしました。自然に起きた事故やAIの精度改善を測ったものではなく、完了条件の違いを比べた試作です。
• 控え・確認者・予定と一致する変更後の状態・引継ぎ済みの申告を見ても、記録の真偽は分かりません。同じAIが素材・手順・コード・結果の読み合わせを担当し、人による評価は未実施です。

検証から得た学び

• 元の検証ラボの修正版では模擬完了4件・確認待ち1件となり、E15-accountingに不足した架空の控えA15・確認担当B・停止状態を補って再実行すると5件とも模擬完了になりました。AI自身が架空の報告と追加記録を作った結果で、人が実際の停止を確認した結果ではありません。
• デモの初期値である5作業・4件が条件を満たす・1件が確認待ちは教材上の値です。記録の条件を満たすことと、人が原記録を確かめて完了を確定することを分けました。
• 承認の必須化、作業ごとの承認、原記録の確認チェック、期限超過時の次の担当、教材、再整理待ちと判断の解除、CSV・候補JSONの取り込みと書き出しはデモで加えたもので、ラボの観察結果とは分けています。
• IPA「中小企業の情報セキュリティ対策ガイドライン」第4.0版の資産管理・アクセス管理の考え方を参考にしました。元記事で2026年10月30日に確認したもので、台帳・期限・完了条件はhirosta独自の試作です。IPAの様式や適合判定ではありません。

同様の取り組みが向いている条件

• 人事の受付とサービス別の利用記録を社員IDで結び、停止依頼だけで終えず、担当・期限・作業後の確認記録を整理したい場合。
• 異動後に必要な権限を人が決め、原記録にアクセスできる担当が、不足を確認待ちに残して引き継げる場合。
• 原記録へのアクセス権、承認者と作業者の分離、保存期間、データと契約の扱い、監査記録の保全、再開・訂正の手順を別途設計できる場合。

補足

状態はページのメモリー内だけにあり、再読み込みで初期化されます。永続保存・本人認証・役割ごとのアクセス制御・実サービスとの連携はありません。アカウント停止の自動実行、記録の真偽判定、重複実行の防止、同時作業の制御は未実施です。既存セッション・連携アプリ・委任アクセス、グループ経由の権限、名簿にない個人契約・外部委託者・共有IDの把握も扱っていません。向いている条件は仕組みと限界から整理したもので、実案件への適用を確認したものではありません。