お問い合わせ
2026 / 09 / 04 ベストプラクティス

AIを業務に入れた後、月に一度立ち止まる時間の作り方

Lead

AIを業務に入れた後、月に一度30分の点検枠を置く設計を整理します。利用状況・ヒヤリハット・コスト・改善要望の4観点を、NIST AI RMF PlaybookのManage機能を手がかりに事務所サイズへ落とします。実施事務所の成果を実測した記事ではありません。

架空の設計例として、AIを業務に入れてから半年経った事務所を想定します。導入直後はみんなで使い方を共有していたのに、半年もすると「動いていれば問題ない」という扱いになり、誰が何にどう使っているかが見えなくなる。導入時に決めた運用ルールが半年後にどこまで守られているかを確認する場が、そもそも予定に入っていない、という状態です。

AIは一度入れたら終わりの道具ではなく、業務に組み込まれて動き続けるソフトウェアです。月に一度、運用の様子を眺める時間を置くと、劣化に気付く機会が定期的に生まれます。本稿では、士業の方の事務所で回せる月次点検の形を、4つの観点で整理します。本記事は、複数の事務所で効果を確認した事例報告ではなく、点検を設計するための候補を示すものです。

参考にしている枠組みは、米国NISTが公開しているAI Risk Management Framework (= AI RMF) のPlaybookのうち、Manage機能です。Manage 4.1 (= 展開後のモニタリング計画の実装。利用者からの入力の収集・評価、不服申立てと上書き、廃止、インシデント対応、復旧、変更管理を含む)、Manage 4.2 (= 継続的改善のための測定可能な活動をシステム更新に組み込む)、Manage 4.3 (= インシデントと誤りを関係者へ伝達し、追跡・対応・復旧の手順を文書化する) という項目が定義されています (確認日: 2026-09-04。URLは記事末「参考」をご覧ください)。

4つの観点で眺める

月次点検の設計例として、次の4つの観点で眺める形を置きます。

  • 利用状況 (= 誰が・どの業務で・どのくらい使っているか)
  • ヒヤリハット (= 誤出力・情報漏えい懸念・想定外の使われ方)
  • コスト (= API課金・サブスクリプション・付随する人件費)
  • 改善要望 (= 使っている職員から上がってくる「こうしたい」)

この4つは、Manage 4.1〜4.3が示すモニタリング・継続的改善・インシデントの追跡と文書化の発想を、士業事務所の実務サイズに落とし込んだ設計例です。観点の取り方は事務所の規模に合わせて調整します。

観点の数は4つを起点にします。5つ以上を毎月眺めるのは月次の運用には重く、3つに絞ると事故と改善が同じ区画に混ざります。規模が小さい事務所は3つに圧縮し、特定業務にAIを集中投入している事務所は業務カテゴリを別軸で足す、という調整が設計例として考えられます。

利用状況の眺め方

「誰が・どの業務で・どのくらいAIを使っているか」を、月次で次の切り口から眺めます。運用の偏りや、想定していなかった使い方を見つけるための切り口です。

  • アカウント別の利用件数 (= 特定の職員に集中していないか / 全く使われていないアカウントはないか)
  • 業務カテゴリ別の利用 (= 契約書レビュー、議事録要約、メール下書きなど、業務種別ごとの使用比率)
  • 時間帯・曜日の偏り (= 深夜帯や休日に集中している場合、業務時間外利用の妥当性を確認する余地が出てきます)
  • 想定外の用途 (= 当初想定していなかった業務での利用が生まれていないか)

利用しているサービスの管理画面で利用状況を取得できる場合はそれを使い、API利用ならログから集計します。完全な計測が難しくても、月次で各職員に5分程度の自己申告アンケートを回す形で、利用の偏りは把握できます。

ヒヤリハットの拾い方

AI利用におけるトラブルは、外部に露出した情報漏えいだけを指すわけではありません。月次点検で拾う対象を、次のように分けておくと拾い漏れが減ります。

分類例
顕在化した事案クライアント情報を含むプロンプトを誤って外部AIに送信した、AI生成の文書を確認せずに提出してしまった
ヒヤリハットプロンプトに個人情報を入れる直前で気付いた、AIの回答に明らかな誤りがあったが提出前に発見した
違和感出力品質が以前より下がっている気がする、特定の業務で使うと回答が安定しない

顕在化した事案だけを集めようとすると、報告する側の心理的なハードルが高くなります。ヒヤリハット・違和感まで含めて「気になったことはなかったか」を月次で聞く形にすると、重大事案の予兆を拾う機会が増えます。

個人情報保護委員会は2023年6月2日、「生成AIサービスの利用に関する注意喚起等」を公表し、個人情報取扱事業者・行政機関等・一般の利用者のそれぞれに、個人情報を含むプロンプトを入力する際の留意点を示しています (確認日: 2026-09-04。URLは記事末「参考」をご覧ください)。士業の方の事務所では、依頼者情報・相続案件・係争中の事案など、機微な情報がプロンプトに混ざりうるため、ヒヤリハットの収集対象に「入力してよいか迷った場面」を含めます。

コストで見落とされやすい論点

月次点検でコストを眺めるとき、「いくら使ったか」だけを見ると見落としが出ます。次の観点を並べておきます。

  • 絶対額 (= 予算に対する実績)
  • 単価 (= 1案件・1業務あたりのコスト、前月との比較)
  • 隠れコスト (= AIを使うために発生している人件費。プロンプト調整、出力チェック、再生成)
  • 重複契約 (= 複数のAIツールで似た機能を重複して契約していないか)

特に隠れコストは見落とされがちです。サブスクリプション料金が小さく見えても、出力チェックに職員の方の時間が取られていれば、トータルは料金より大きくなります。月次で「AIを使って減った時間 − AIを使うために増えた時間」を粗くでも記録しておくと、ROIを話し合う土台になります。

API課金型のサービスは月途中で予算を超過しうるため、月次点検とは別に「予算の70% / 90% でアラートを出す」といった日次の仕組みを併用する設計例が考えられます。

改善要望の仕分け

職員の方から上がってくる「こうしたい」「これは使いにくい」という改善要望は、AIを業務に組み込んだ後の質を上げていくうえで大切なインプットになります。一方で、すべての要望に対応しようとすると工数が回らないため、月次点検で仕分けます。

  • すぐ対応 (= プロンプトテンプレートの修正、設定変更で済むもの)
  • 次月検討 (= ワークフロー変更が必要なもの、複数職員の合意が必要なもの)
  • 保留・見送り (= 効果が不明確、コストが見合わない、現状の運用で十分なもの)
  • エスカレーション (= 自所の判断の範囲を超えて、外部の知見が必要なもの)

「保留・見送り」を明示的に記録に残しておくと、要望を出した方への戻し方が変わります。「検討した結果、現時点では見送る」というフィードバックを返さないと、要望そのものが上がらなくなります。

セキュリティとコンプライアンスの月次点検

月次点検にセキュリティとコンプライアンスの観点を1区画入れます。確認項目の一例は次の通りです。

  • アクセス権限 (= 退職者・異動者のアカウントが残っていないか、不要な権限が付与されていないか)
  • データ保存範囲 (= AIサービス側でプロンプト・出力が学習・保管に使われていないか、契約条件の再確認)
  • ログ保管 (= 監査が必要になった場合に追跡できるログが残っているか)
  • 第三者提供・委託の整理 (= AIサービスへの入力が個人データの第三者提供や委託に当たるかの整理。個人情報保護委員会の注意喚起が求める確認事項を含む)
  • 業務委託契約の整合 (= クライアントとの業務委託契約でAI利用が許容されているか、必要なら同意を取得しているか)

士業の方の事務所では、守秘義務・利益相反といった業法上の論点がAI利用と交差します。弁護士法・税理士法など業によって参照する法令が変わるため、所内のコンプライアンス担当の方や顧問の方の判断を仰ぐ項目として置きます。

個人情報保護法・各士業法・ガイドライン類は改正・改訂されます。月次点検に「直近1か月で関連法令・ガイドラインの更新がなかったか」を確認する項目を入れます。

月30分の枠を予定に入れる

月次点検で大事なのは、完璧な集計表ではなく、4つの観点を毎月眺める習慣そのものです。利用状況・ヒヤリハット・コスト・改善要望、この4つを30分でいいので眺める枠を、月の予定に入れます。それだけで、運用の品質が落ちていることに気付く機会が毎月生まれます。

NIST AI RMF PlaybookのManage機能が示す展開後モニタリング・継続的改善・インシデントの追跡と文書化の発想は、士業事務所の規模に縮約しても取り入れられます。完璧な月次点検を目指して立ち止まるより、まず30分の枠を確保して3か月続ける、という入り方が設計例です。続けるうちに「この観点を足したい」「これはいらない」が見えてきて、所として合う形に収まります。点検の記録は、半年後・1年後に「何が論点だったか」「どの打ち手を見送ったか」を振り返れる粒度で残します。点検の効果を自所で確認するなら、拾えたヒヤリハットの件数と顕在化した事案の件数を月ごとに記録し、点検開始の前後で比べます。

参考