社内の記録：稼働状況と本人への確認事項を見る画面を追加した

hirostaの社内の開発基盤は、AIが作業・確認し、人が承認する仕組みです。公開用材料には、2026年10月13日に「部門の稼働と本人への確認事項を一つの画面で見る管理画面を追加した」と記録されています。

同じ材料の10月8日の記録には、着手と変更の取り込みを人がラベルで承認し、取り込みの承認は本番公開の承認を兼ねること、通知は人の対応が必要なときに絞ることが残っています。また、取り込み後の作業は人が行うものに絞り、見守りは気付きに分ける方針も記されています。

これらから読み取れるのは、作業の状況、人の判断、実際に手を動かす作業を分けて扱う方針です。管理画面の全項目や通知の到達状況、導入前後の確認時間までは、この材料から確認できません。以下の一覧項目や手順は、この記録を起点にした運用の提案であり、社内の画面仕様や実施済みの検証結果ではありません。

自社サイトでのAIと人の分担は、サイト運営の記録でも紹介しています。お客様への導入実績とは区別してください。

一覧では「今の工程」と「人の次の行動」を分ける

「実行中」「承認待ち」「完了」という状態名だけでは、担当者が何をするべきか分からない場合があります。次の情報を作業単位で揃える案です。すべてを一覧に詰め込まず、根拠や詳しい履歴は対象から開けるようにします。

一覧で見る項目 残す内容 人が確認する点
対象と担当 業務名・管理番号・担当者 同じ対象の別の依頼と混ざっていないか
今の工程 資料待ち・下書き中・内容確認待ちなど 最後に終わった工程はどこか
更新日時 元の作業記録が更新された日時 古い状態のまま表示されていないか
人が決めること 判断する内容・判断者・回答期限 誰が、いつまでに、何を決めるか
根拠と成果物 元資料・下書き・確認結果への参照 決定に必要な情報が揃っているか
実行結果 登録・送信・公開などの結果と確認者 承認後の処理が本当に終わったか

工程や実行結果は、正式な作業記録と結び付けます。AIが「完了しました」と要約した文章だけで、登録済み・送信済みとは判断しません。記録を取得できない場合は「不明」、更新されていない場合はその日時を表示し、正常な進行と区別します。

人の判断待ちと、原因調査が必要な停止も分けます。予定どおり承認を待っている仕事を、エラーとして再実行する必要はありません。処理が止まった原因の調べ方は、AIの作業が止まったときの確認手順で扱っています。

通知は、受け取った人が行動できる内容にする

通知には、対象、依頼する判断や作業、期限、確認先を添えます。「AIから報告があります」だけでは、読むだけでよいのか、承認が必要なのか分かりません。

報告は、次のように扱いを分ける案です。

  • 人の判断：案を採用するか、対象範囲を変えるか。選択肢、勧める案、その理由、保留した場合の扱いを添えます。
  • 人が行う作業：資料の用意や設定変更など。担当者、終わりの条件、実行前に必要か実行後でよいかを残します。
  • 気付き・観察：今後比較したいことなど。今すぐ人が行う作業と混ぜず、一覧から参照できる記録にします。

たとえば「返信下書きの返金案を採用するか、責任者が確認する」は判断です。「承認した文面を担当者が送信する」は作業です。「今後、問い合わせの傾向を比較する」は観察です。観察を必須作業として残すと、いつ完了するか決められません。

通知を絞る場合も、未対応の判断が消えない一覧は必要です。同じ対象・同じ判断内容の通知を重ねず、内容の変更や期限超過を知らせる条件を事前に決めます。担当者が不在なら誰へ引き継ぐかも、業務責任者が決めておきます。

想定シナリオ：問い合わせの返信下書きを責任者が確認する

以下は未実施の想定シナリオです。hirostaやお客様の導入・検証結果ではありません。AIが問い合わせの要点と返信下書きを作り、人が内容を確定して送る業務を想定します。

画面には、進捗と判断依頼を並べる

担当者の画面では、問い合わせごとに「下書き中」「内容確認待ち」「送信結果の確認待ち」を表示する案です。「内容確認待ち」を開くと、元の問い合わせ、返信下書き、参照した社内規程、人が決める点、回答期限を確認できるようにします。

返金条件の例外対応が必要なら、判断欄は「責任者が例外を認めるか確認」とします。AIに決裁を任せず、判断に必要な規程や条件がなければ資料不足として保留します。画面を見られる人は業務上必要な担当者に絞り、通知へ顧客情報や問い合わせ全文を写さない運用にします。

承認後も、送信結果を確かめてから完了にする

  1. 業務担当者が元の問い合わせと規程を照合し、下書きの誤りや不足を直します。
  2. 責任者が対象の下書きを確認し、採用・修正依頼・保留の判断と理由を残します。承認した版も特定できるようにします。
  3. 承認後に宛先・文面・条件を変えた場合は、変更が承認の範囲に入るかを確認します。範囲外なら再確認に戻します。
  4. 送信担当者が宛先と送信履歴を確認し、承認した文面を送ります。履歴が不明なら、重ねて送らず照合を先に行います。
  5. 正式な送信履歴と照合した結果、確認者、日時を残して完了にします。承認済みでも送信が未確認なら、完了にしません。

このように、「下書きができた」「人が承認した」「相手に送った」を別々に見ます。途中で手動対応した場合は、手動の結果と自動側の記録を照合する手順へ進みます。

業務の分担は問い合わせ対応の業務改善をご覧ください。問い合わせの仕分け・返信下書きの事例はAIと人の役割の参考ですが、ここで提案した管理画面を導入した事例ではありません。

費用と期間は、画面を作る前に記録先と判断の流れで考える

最初は既存の台帳に、工程・判断者・期限・成果物への参照を揃えるところから始められます。専用画面を先に作るより、どの記録を正とするか、誰が状態を更新するか、何をもって完了とするかを決めます。依頼時の条件は、AIへの業務依頼の書き方で整理できます。

費用は、項目と承認手順の整理、記録先との連携、閲覧権限、通知、実行結果の照合、運用の引き継ぎに分けて見積もります。AIの利用料だけでなく、人が根拠を確認する時間や、担当交代時の更新作業も含めます。

期間を左右するのは、正式な記録先を参照できるか、承認者を決められるか、例外時の処理が揃っているかです。まず対象業務を一つに絞り、開始前に確認する項目と、結果を振り返る日を決める案です。この記事では、標準日数・固定費用・削減効果を示していません。

全体の始め方はAI業務改善ガイド、支援範囲と料金はサービス・料金をご確認ください。相談では、顧客資料や生の作業記録を送る前に、状況を確認しづらい工程と、今使っている台帳の種類からお伝えください。

よくある質問

Q. 管理画面を新しく作る必要がありますか？

既存の台帳で対象・工程・判断待ち・根拠・結果を確認できれば、そこから始められます。複数の記録を探し回る、更新が追い付かないなど、困っている点を確認してから連携や画面の追加を判断します。

Q. 通知が来なければ、仕事は順調に進んでいますか？

通知がないことだけでは判断できません。一覧で最後の更新日時と元の作業記録を確認します。記録を取得できない場合は、進行中や完了と推測せず、不明として担当者へ確認します。

Q. 一度承認すれば、その後はAIに任せられますか？

何をどこまで承認したかによります。承認対象の版・実行範囲を残し、範囲外の変更は再確認に戻します。承認と実行結果の確認は別で、送信・登録・公開の結果が不明なら完了扱いにしません。