ServiceNowにAIを載せる4段階｜台帳を壊さない順番

「依頼の受付にAIを入れたいと相談したら、情報システム部門から『台帳が壊れる』と言われて止まりました」「AIが起票した依頼が担当者の名前で残っていて、誰が承認したのかを後から説明できませんでした」——社内の依頼を捌く台帳を長く運用してきた会社ほど、AIの話が出た直後にこの2つで詰まります。この基盤にAIを載せるという相談は、新しい受付窓口を作る話ではありません。本当は、すでに定義された流れの上で、AIにどこまで書き込ませるかを決める話です。この記事では、書き込みの深さを4段階に分けたうえで、段階ごとに台帳へ増える行、AIの操作を誰の名前で残すか、段階を上げてよいかを何で判断するか、そして止め方と巻き戻し方までを順に整理します。

「AIを載せる」と言ったとき、実際に何が増えるのか

ServiceNow、つまり社内の依頼を捌く台帳の基盤が他の道具と違うのは、依頼・承認・変更・資産・障害が別々の場所に散らばっていないところです。1件の依頼が承認を通り、変更として実行され、資産の記録が書き換わり、後から障害が起きればその変更に結び付けて辿れる。ここまでが一本の線として設計されていることが前提になっています。提供元の解説にも、この上で動かす意味として、操作がレコードに結び付き、権限が効き、流れが追跡され、監査の履歴が損なわれない、という書き方が出てきます。つまり「AIを載せる」は、受付の手前に賢い案内役を置くことではありません。この線のどこかに、AIの書き込みを挿し込むことです。

挿し込んだ場所から先は、AIが作った行が線の上に混ざります。混ざること自体は問題ではありません。問題は、混ざったあとでどの行がAI由来なのかを分けられないまま、件数や日数を数えてしまうことです。導入の効果を測る数字も、監査で説明する材料も、同じ行から作られます。行が濁ると、両方が同時に濁ります。どこまで書かせるかを決めることは、そのまま行の設計を決めることだと考えてください。

この記事で扱わないことも先に書いておきます。届いた問い合わせをどの型に分けるか、一次受けをどう設計するか、どの工程を情報システム部門の手から外すかは、それぞれ別の主題として整理しています。ここでは、受け付けた後の話に絞ります。すでに定義されている流れの上で、AIに何を書かせ、何を書かせないか。決めるのはその一点です。

どの操作も行として残る——長く残る側と、画面で見せる側

行として残る、と書きましたが、残り方は一種類ではありません。公式の資料は2つを書き分けています。監査の対象になっている表の履歴が入る監査の表は「すべてのレコードについて履歴情報をシステムが保存する場所」と説明され、一方で画面の履歴に出る履歴セットの側は「監査対象の表のどのレコードに履歴情報があるかを特定する」ものとされています。実際の値の変化を持っているのは、その下にある履歴の行です。

違いがはっきり出るのは保持の長さです。同じ資料は、監査の表について「永久に保持されることを意図している」と書き、履歴セットについては「利用できる保持期間は最大21日」と書いています。さらに履歴セットと履歴のレコードは「システム内の全変更の完全な履歴ではなく、直近の一部だけを含む」と明記され、容量を抑える手段として「30日更新されていない履歴セットのレコードを掃除の仕組みで削除する」「4つの履歴の表を7日ごとに切り替えて回す」方法が挙げられています。画面で見える履歴は、記録の全部ではなく直近の一部だということです。

この差は、AIに書き込ませ始めた会社でそのまま実務の問題になります。半年後に「あのときAIは何を書いたのか」を辿る場面が必ず来るからです。画面の履歴だけを見て済ませると、直近しか見えません。長く残る側を読める人を、載せる前に決めておく必要があります。加えて、社内の表がすべて監査の対象になっているとは限りません。設定は会社ごとに変えられるので、AIが触る予定の表が対象に入っているかどうかは、既定のままかどうかも含めて確認しておきます。

• 画面の履歴が短くても、記録が無いとは限らない。長く残る側を見る手順を決めておく
• AIが触る予定の表が監査の対象に入っているかを、段階を上げる前に一覧で確認する
• 保持と掃除の設定は変更できる。自社が既定のままかどうかを、載せる前に確かめる
• 辿る作業を誰がやるかを役割名で決める。個人名で決めると異動で辿れなくなる

書き込みの深さを、4段階に分ける

段階の分け方の基準は、AIの賢さではありません。台帳に増える行の種類です。段階1では行が増えません。段階2で依頼の行が1本増えます。段階3で承認の行に材料が付きます。段階4で変更の行と資産の行が動きます。段階が上がるほど、外したときに戻す対象が増える。この対応関係だけを覚えておけば、どこで止めるべきかは自分で決められます。

段階	AIがすること	台帳に増える行	人が決めること
段階1 読んで分ける	種別の候補付け、重複の指摘、記入漏れの指摘、経緯の要約	増えない（提案として画面に出るだけ）	候補を採るかどうか
段階2 記入して起票する	欠けている欄の指摘、決まった型での起票	依頼の行が1本増える	起票を任せてよい種別の範囲
段階3 承認の材料を作る	影響範囲の下書き、過去の似た依頼の並べ、手順書の該当箇所	承認の行に注記と添付が増える	承認そのもの
段階4 実行まで渡す	手順があらかじめ文書になっている変更の実行	変更の行と資産の行が動く	渡してよい種別と、件数・時間帯の上限

一度に段階4まで渡す設計を持ち込むと、外すときに何を外せばよいのかが分からなくなります。段階1だけなら止めても行は残りません。段階4まで進んでいると、変更の行と資産の記録の両方を戻すことになります。1段ずつ上げる理由は慎重さではなく、戻す範囲を自分で把握できる状態を保つためです。

もうひとつ、段階を上げる単位は「全社」ではなく「種別」です。権限の付与の依頼は段階2まで、端末の貸し出しの依頼は段階3まで、手順が固まっている定期の入れ替えだけ段階4、という形になります。種別ごとに段階が違うのは正常な状態です。表にして貼っておくと、後から入った担当者が線を引き直さずに済みます。

段階1：読んで分ける。台帳には書き込ませない

段階1でAIにさせるのは4つです。届いた文面から種別の候補を出す。直近に同じ対象で立っている依頼との重複を指摘する。その種別で必須になっている欄のうち、埋まっていないものを挙げる。やり取りが長くなった依頼の経緯を要約する。どれも判断ではなく、読んで並べ替える作業です。

この段階の要点は、結果を台帳に書かせないことにあります。画面の脇に提案として出し、採るかどうかを人が決めます。理由は単純で、提案は消せますが、行は消せないからです。誤った種別が1件でも行として残れば、種別ごとの件数が動きます。その件数は月次の報告に載り、次の期の人員配分の材料になります。精度が読めていない段階で行を増やすと、精度の話が数か月遅れて別の形で戻ってきます。

段階1で測るのは正答率ではなく、提案した候補が、人にそのまま採用された割合です。採用されなかったときは、理由を人が1行で書きます。文面から読み取れなかったのか、社内の事情を知らないと決まらないのか、そもそも種別の定義が曖昧なのか。3つ目が多いなら、直すのはAIではなく種別の定義です。3週間ほど回して採用の割合が上下しなくなってから、段階2の話を始めます。

• 採用された割合が、週ごとに大きく振れていないか
• 採用されなかった理由が、3つの分類のどれに集まっているか
• 重複の指摘が、実際に重複していた件と一致しているか
• 要約に、元の文面には無い事実が足されていないか

段階2：記入を補い、起票まで任せる

段階2は、台帳に行が増える最初の段階です。ここで先に決めるのは精度の目標ではなく、起票を任せてよい種別の一覧です。一覧に載っていない種別が来たら、段階1の動きに落ちて提案だけを出します。一覧は増やしてよいものですが、増やすときは日付と決めた人を残します。半年後に「いつからこの種別も任せていたのか」を聞かれる場面が必ず来ます。

次に決めるのは、埋めた出どころを分けて残すことです。起票された1本の行の中に、AIが埋めた欄と人が埋めた欄が混ざります。値そのものを見ても、どちらが埋めたかは分かりません。出どころを別の欄として持つか、注記として残すか、方法は自社の作りに合わせて構いませんが、分けられない状態で先に進むと、後で段階を下げる判断ができなくなります。下げる判断の材料は、AIが埋めた欄だけを抜き出して数えた誤りの件数だからです。

そして、欠けている欄を埋めさせないこと。これが段階2でいちばん多い失敗です。開始日が空なら「開始日が空です」と書かせます。それらしい日付を入れさせてはいけません。埋まった欄は、承認する人から見れば申請者が書いた値と区別が付きません。埋めた値は、その先で承認の材料として使われる。空欄は不便ですが、正しくない値より安全です。

• 開始日や期限が空の依頼を、それらしい日付で埋めさせる。埋めた値がそのまま承認の材料になる
• 承認者の欄を、過去の似た依頼から推測して入れさせる。承認の経路が誰にも気づかれずに変わる
• 起票のたびに新しい種別を作らせる。種別ごとの件数が前月と比べられなくなる
• 重複の確認を通さずに起票させる。同じ内容の行が2本立ち、閉じる手間が倍になる
• AIが起票した行を、人が起票した行と同じ欄だけで残す。後から分けて数えられない

段階3：承認の材料を作らせる。承認そのものは渡さない

承認の行は、後から「なぜ通したのか」を説明する対象になります。だからこの段階では、材料と判断をはっきり分けます。AIに作らせてよいのは材料のほうです。影響を受ける資産の一覧の下書き、過去の似た依頼とその結末、手順書の該当箇所、前回申請された内容との差分。どれも人が集めれば集まるもので、集めるのに時間がかかるものです。

材料には出どころを必ず添えさせます。どの行から取ったのか、どの文書の何章なのか。出どころを添えられないものは、材料として載せません。根拠の出せない材料は、材料ではなく感想です。承認する人が5分で読める分量に収めることも同時に決めます。分量の上限を決めないと、材料は増え続け、読まれない添付になります。読まれない添付が付いた承認の行は、後から見ると根拠が揃っているように見えるので、かえって危険です。

作らせてはいけないのは、可否の推奨です。推奨が付いた瞬間、承認する人は判断する側から追認する側に回ります。そして追認は、台帳の行の上では承認とまったく同じ形で残ります。承認と追認が同じ行として残るなら、後から区別する手段はない。材料は並べる、結論は書かない。この線を守ると、承認にかかる時間は短くなり、承認の重みは変わりません。

段階4：手順が文書になっているものだけ、実行まで渡す

段階4は、AIが台帳の上で実行の側に触る段階です。ここで手掛かりになるのが、変更の種別がもともと分かれていることです。提供元の解説では、既定の流れが種別ごとに用意されていて、手順があらかじめ文書になっている種別、担当者の確認と合議体の確認を通る通常の種別、緊急の種別に分かれています。通常の種別では変更諮問委員会に割り当てられて評価される流れが、緊急の種別では緊急用の合議体が状況に応じて関与する形が説明されています。

渡してよいのは1つ目だけです。理由は、手順が文書になっているということが、実行の中身が事前に決まっていて、判断の余地が無いことと同義だからです。判断の余地が無いところだけが、実行を渡してよい範囲になります。逆に言えば、文書が古い種別、例外が毎回付く種別、担当者の裁量が入っている種別は、見かけ上は定型でも段階4に上げてはいけません。上げる前に、手順書を読み直して例外の数を数えるほうが先です。

緊急の種別は渡しません。緊急は、決まった手順の外に出るために用意されている種別だからです。止まっているものを早く戻すという目的のために、通常なら通す確認を飛ばします。そこにAIを入れると、飛ばしてよい確認の判断まで渡すことになります。速さのために作られた抜け道を、自動で通らせない。緊急のときこそ人の名前で残します。

1. 1日あたりに実行してよい件数の上限を決める。超えたら止まり、人に回る
2. 動かしてよい時間帯を決める。誰も見ていない時間に実行させない
3. 1件あたりで触れてよい資産の数に上限を置く。広く当たる作業は段階3までにする
4. 対象の範囲を種別ではなく具体の一覧で持つ。一覧に無いものは実行しない

AIの操作を、誰の名前で残すか

段階2以降に進むと、必ずこの問いが来ます。台帳に増えた行の担当者の欄に、誰の名前が入るのかという問いです。提供元の技術記事では、AIが動くときの資格の持たせ方が2つ示されています。1つは、そのとき操作している人の文脈と権限の制約をそのまま引き継ぐ形で、資料では既定として説明されています。もう1つは、専用の身元として動く形です。

台帳の上では、この選択がそのまま行の見え方になります。引き継ぐ形なら、履歴の行に出る名前は操作した人の名前です。その人が見てよい範囲しか触れないことが自動的に保証される代わりに、行の上でAIの操作と人の操作が混ざります。専用の身元なら、行の上では分かれます。代わりに、その身元が何を見てよいかを自分たちで設計し直すことになります。この選択は、後から何を説明できるかを決めている。速さや手間ではなく、そこで選びます。

実務の落とし所は、段階で分けることです。段階1と段階2は引き継ぐ形で構いません。読む範囲も書く範囲も、依頼した本人が触れる範囲を出ないからです。段階3と段階4は専用の身元に分けます。承認の材料を作った主体と、承認した人が同じ名前で残ると、材料の妥当性を後から検証できなくなるからです。身元を段階ごとに分けておくと、段階を下げるときにその身元を止めるだけで済みます。

なお、鍵そのものの渡し方、期限の付け方、盗まれたときの止め方は、この基盤に限らない話なので別に整理しています。ここで決めているのは、台帳の行に出る名前と、その名前で何を説明できるかです。決めた内容は運用の文書に1ページで残します。監査で最初に聞かれるのは、たいていこの1ページの有無です。

動かす資格に、強い役割を付けない

名前を決めたら、次はその名前に何を付けるかです。提供元の技術記事には、道具を実行する時点で、その資格に対して権限が検査される、という趣旨の記述があります。裏を返せば、資格に付けた役割が、そのままAIの届く範囲になるということです。管理者に近い役割を付けてしまうと、権限の仕組みそのものが素通りになります。動かないときに役割を足して直す、という手順を一度でも認めると、半年後には誰も範囲を説明できなくなります。

役割の粒度については、製品の側にも手掛かりがあります。AIの管理まわりで用意されている役割の一覧を見ると、全体を統括する役、AI資産の持ち主として最新の状態を保つ役、リスクと統制を見る役が管理者・担当者・業務利用者・読み取り専用に分かれ、割り当てられた対象だけを見られる役と、読むだけの役が別に定義されています。持ち分にあらかじめ名前が付いているのは、決める人を1人に決めろという設計です。この粒度を、自社のAIの資格にも持ち込みます。

実務では、段階ごとに資格を分けたうえで、段階を上げるときに役割を足します。足した日、足した人、足した理由を記録に残します。この3つが残っていれば、範囲が広がった経緯を後から説明できます。残っていなければ、広がった範囲を狭める作業は、止まる業務を一つずつ探す形になります。

• 管理者に近い役割を、AIの資格に付けていないか
• 段階ごとに資格が分かれていて、段階を下げるときに止める対象がはっきりしているか
• 役割を足した日と足した人が、記録として残っているか
• 資格が触れる表の一覧を、四半期に一度は読み直しているか
• 使わなくなった資格が、止められずに残っていないか

AIに任せる工程と、人が決める4つ

ここまでの段階を、工程の側から並べ直します。線引きの原則は2つです。1つ目は、読んで並べ替えるだけの工程は任せてよいということ。2つ目は、台帳の状態を変える工程と、変えてよいかを決める工程は人に残すということです。AIに判断させず、根拠を書かせ、人が確認する範囲を先に決める。この順番を崩さない限り、段階を上げても台帳は壊れません。

工程	AIに任せてよいところ	人が決めるところ
受け付ける	文面から種別の候補を出す。直近の同じ対象との重複を指摘する	候補を採るかどうかと、任せてよい種別の一覧
記入をそろえる	必須の欄で埋まっていないものを挙げる。決まった型で起票する	空欄のまま進めるか、差し戻すか
承認にかける	影響範囲の下書きと、過去の似た依頼を出どころ付きで並べる	承認そのもの。可否の判断はAIに書かせない
実行する	手順が文書になっている変更を、上限の中で実行する	渡してよい種別と、件数・時間帯・対象の上限
閉じる	閉じてよさそうな候補を、根拠とともに挙げる	閉じる判断そのもの
例外を扱う	過去に同じ形の例外があったかを探す	今回を例外として扱うかどうかと、その記録の残し方

人が決める側に残る4つを、もう一度言い換えます。承認は、通した理由を説明する責任が付いているから残します。閉じる判断は、閉じた瞬間に件数が変わり、その件数が評価に使われるから残します。例外の扱いは、例外の積み重ねが次の年の標準になるから残します。そして台帳の項目そのものの変更は、影響が依頼だけに留まらないから残します。4つとも、間違えたときに戻す作業がいちばん重いところです。

任せる側にも条件を付けます。出どころを書けない提案は出させない。確信の度合いではなく、参照した行と文書の名前を添えさせる。添えられないときは提案そのものを出させない。AIは分からないと言うのが苦手なので、言えるようにするのではなく、言えないときに黙る形にしておくほうが確実です。

段階を上げてよいかは、台帳から出る数字で決める

段階を上げる判断を、感触や試用期間の長さで決めないためには、台帳の側から数字を取り出す手順を先に決めておきます。この基盤の強みは、判断の材料がすべて同じ場所に揃っていることです。外部の集計を作る必要はありません。

見る数字は3つで足ります。AIが起票した行が承認前に人に書き換えられた割合。同じ対象で重複して立った行の件数。起票から承認までにかかった日数の中央値です。1つ目が下がらないまま2つ目が増えているなら、段階を上げるのではなく種別の定義を直す。3つ目だけが良くなっているときは、承認が形だけになっていないかを疑います。

下げる手順も同じ紙に書いておきます。どの数字がどこまで悪化したら、どの種別を1段下げるのか。下げる判断をする人を役割名で決めておくのか。下げたときに、その段階で作られた行をどう扱うのか。上げる手順だけがあって下げる手順が無い運用は、一度上げたら誰も下げられなくなります。

台帳の項目そのものを、AIの都合で変えない

段階2から3に進むころ、必ず出てくる相談があります。AIが分類しやすいように種別の選択肢を増やしたい。AIが書き込む専用の欄を足したい。埋まらないことが多い必須の欄を、任意に変えたい。どれも作業としては小さく、その場では合理的に見えます。

それでも止めるのは、項目が依頼だけのものではないからです。同じ項目は承認の条件から参照され、変更の自動処理の分岐に使われ、資産の記録との突き合わせに使われ、月次の集計の軸になっています。1つ増やすと、その全部が同時に動きます。台帳が壊れるというのは、この連鎖が読めないまま項目を触ることを指しています。選択肢を1つ足しただけで、前月と件数が比べられなくなる。必須を任意に変えただけで、承認の条件を素通りする経路ができる。起きるのは数か月後で、原因は誰も覚えていません。

• AIの分類が当たらないので、種別の選択肢を増やす。前月との比較ができなくなる
• AIが書き込む専用の欄を足す。集計の軸が二重になり、どちらが正しいか分からなくなる
• 埋まりにくい必須の欄を任意に変える。承認の条件を通らない経路ができる
• 検証用の環境で項目を足し、本番に反映する手順を通さない。差が静かに残る
• AIの都合で足した欄を、後から誰も使わなくなっても消さない。次の担当者が意味を推測する

どうしても項目を変える必要があるなら、変更の種別として通します。AIの改善という名目で、変更の手続きを飛ばさないことです。台帳の項目を変える作業は、台帳の上で最も影響が広い変更です。その作業だけが手続きの外で行われている状態は、AIを載せる載せない以前に、運用として先に直すところになります。

閉じる判断を渡すと、数字だけがよくなる

閉じるという操作は、依頼の行が終わったことにする操作です。ここを任せると、未対応の件数は確実に減ります。報告に出る数字は良くなります。それでも渡さないのは、閉じたかどうかと、片付いたかどうかが別の話だからです。

実際に起きるのは、再依頼が別の行として立つことです。台帳の上では2件の依頼として数えられ、1件あたりの対応時間は短く見えます。同じ人が同じ件で3回立てても、3件の依頼が短時間で片付いた記録になります。数字が良くなる仕組みが埋め込まれているので、誰も嘘をついていないのに、実態と記録が離れていきます。離れたことに気づくのは、現場から「何度も言っているのに直らない」という声が出たときです。

任せてよいのは、閉じてよさそうな候補を根拠とともに挙げるところまでです。最後のやり取りから何日経っているか、依頼者からの返信があるか、同じ対象で新しい依頼が立っていないか。この3つを添えて候補を出させ、人がまとめて確認します。閉じる操作は人の名前で残す。件数を減らすためではなく、後から説明できる状態を保つためです。

止め方と巻き戻し方を、載せる前に決める

止め方から決めます。AIの動きだけを止めて、人の仕事は止めない。段階ごとに資格を分けておくと、これがそのまま実現します。段階4の資格を止めれば実行だけが止まり、段階3以下は動き続けます。止める手順は、載せる前に一度試しておきます。本当に必要になったときに手順を書き始めると、止めるまでの時間がそのまま影響の大きさになります。

巻き戻し方は、消すのではなく足す形にします。誤って作られた行を消すと、長く残る側の記録と画面の履歴が食い違います。食い違った記録は、後から読む人には解けません。取り消しの行を足し、なぜ取り消したかを書きます。行を消して整えた台帳は、整って見えるだけで説明できなくなる。段階4まで進んでいて資産の記録が動いていたら、資産の側も同じやり方で戻します。

戻した後にやることも決めておきます。何件が対象だったのか、どの種別に集まっていたのか、どの段階で止めれば防げたのか。この3つを1枚にして残します。戻した記録が残っていない会社は、同じ理由で二度戻すことになる。四半期に一度、段階4に置いている種別の一覧と手順書を読み直す予定を入れておくと、手順書が古くなったことが原因の実行事故は、かなりの割合で防げます。

• 止める手順は、載せる前に一度試す。試していない手順は本番で動かないと考える
• 行は消さず、取り消しの行を足す。取り消した理由を同じ行に書く
• 資産の記録まで動いていたら、資産の側も同じ手順で戻す
• 戻した件数と種別を1枚にまとめ、次に段階を上げる判断の材料にする

よくある質問

一次受けのやり取りを自動化するのと、この4段階はどう違いますか

答える相手が違います。一次受けは人に向かって答える仕組みで、何を答えてよいか、答えられないときにどう人へ回すかを設計します。この4段階は、台帳に向かって書く深さの話です。一次受けを入れずに段階2から始めることもできますし、一次受けだけを入れて段階1にも進まない選択もあります。順番に依存関係はありません。

段階1から段階2に上げるまで、どのくらいかかりますか

期間ではなく、採用の割合が安定したかどうかで決めます。目安として3週間ほど回すと振れ幅が見えてきますが、種別の定義が曖昧なまま始めた場合は、定義を直す時間のほうが長くかかります。採用されなかった理由が種別の定義に集まっているなら、先に定義を直したほうが、結果として早く上げられます。

AIが埋めた欄を人が全部見直すなら、任せる意味がないのでは

見直す対象が変わっています。空欄の依頼を見るときは、何が足りないかを自分で探すところから始まります。指摘が付いていれば、指摘が正しいかどうかを見るだけになります。探す作業と、確かめる作業では、かかる時間が違います。また、この見直しは段階1と段階2の話で、段階が上がるほど人が見る対象は候補と例外に絞られていきます。

専用の身元にすると、見える範囲の設計をやり直すことになりませんか

段階3から段階4に限れば、やり直す範囲は限定できます。その身元が触る表と、実行してよい種別の一覧が決まっているからです。全社の権限設計をやり直す話ではありません。むしろ、引き継ぐ形のまま段階4まで進めるほうが、実行の記録が個人の名前で残り、異動のたびに説明が付かなくなります。

台帳の外にあるやり取りは、どう扱えばよいですか

材料として読ませることはできますが、行の根拠にするなら台帳に写します。外にある記録は、消えたり編集されたりします。承認の材料として添えるときは、要約ではなく引用と日時を写し、写した人の名前を残します。外の記録をそのまま参照する形にすると、半年後に承認の根拠が辿れなくなる場面が出てきます。

小さな組織でも、4段階に分ける意味はありますか

あります。人数が少ないほど、段階を飛ばしても当面は困りません。困るのは、担当が入れ替わった後です。段階を分けておくと、引き継ぐ相手に「今どこまで任せているか」を一言で伝えられます。分けていないと、どの行が自動で作られたのかを、引き継いだ人が一件ずつ調べることになります。

まとめ

社内の依頼を捌く台帳にAIを載せるとき、つまりServiceNowの上でAIを動かすとき、決めるのは賢さの度合いではありません。この基盤では依頼・承認・変更・資産・障害が同じ台帳の上で一本につながり、どの操作も「誰がいつ何を変えたか」の行として残ります。だからAIを載せると、AIの操作も同じ形で残ります。決めることは2つに絞られます。すでに定義された流れの上で、どこまで書き込ませるか。そして、その行に誰の名前を残すかです。

書き込みの深さは4段階に分けます。読んで分けるところまでは行を増やしません。記入を補って起票させると、依頼の行が1本増えます。承認の材料を作らせると、承認の行に注記が付きます。手順があらかじめ文書になっている変更だけ、実行まで渡します。段階を上げる単位は全社ではなく種別で、上げる判断は台帳から取り出した3つの数字で決めます。AIが起票した行が承認前に書き換えられた割合、重複して立った行の件数、起票から承認までの日数です。上げる手順と同じ紙に、下げる手順も書いておきます。画面に出る履歴は直近の一部しか含まないと公式の資料に明記されているので、辿るときに読む先と、読める人も先に決めておきます。

任せるのは分類、重複の検出、記入漏れの指摘、候補の提示までです。承認、閉じる判断、例外の扱い、台帳の項目そのものの変更は人が決めます。材料には必ず出どころを添えさせ、出せないものは出させません。可否の推奨は書かせません。推奨を追認した記録は、台帳の上では承認とまったく同じ形で残るからです。資格には管理者に近い役割を付けず、段階ごとに分け、足した日と足した人を記録に残します。止め方と巻き戻し方を、載せる前に一度試しておく。行は消さず、取り消しの行を足す。この順番を守れば、AIを載せても台帳は説明できる状態のまま残ります。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。