残したいのは、
あの人の判断のほうです。

そこは正直に申し上げます。このページに削減時間や精度の数字を載せていないのは、測った記録を取っていないからです。書けるようになったら書きます。かわりに稟議で使えるのは、いまその工程に何人が何分かけているかという、御社の手元にしかない数字です。最初の相談でそこを一緒に測ります。対象を一工程に絞れば、判断できる大きさになります。

入れ替えません。変更を知らせる仕組みを持たない世代の基幹でも、こちらから定期的に見に行く形で読み取れます。同世代の基幹への読み取り接続は検証済みです。しかも読み取るだけで、AIから基幹へ書き戻すことはしません。基幹側に新しいリスクを足さないので、情報システムのご担当者にも説明しやすいはずです。

秘密保持契約を結んでから進めます。どのデータをどこまで扱うかは、要件定義の段階で文書にして合意します。範囲を後から広げないこと自体を仕様に書きます。書き込みを行わない設計なので、扱うのは読み取った範囲だけです。保管場所と処理の実行環境は、御社のご要件に合わせて構成をご提示します。

特殊であることが前提です。出来合いのものを当てる仕事ではありません。AIが新しく入った人と同じところは一点だけで、御社固有の決まりごとも、現場の勘どころも、まったく知らないという点です。だから設計の中心は「何を渡すか」になります。特殊さは障害ではなく、渡す中身そのものです。それが全部ひとりの頭の中にあることのほうが、気がかりだと思っています。

同じことが起きないようにするための仕組みですから、その仕組みが誰か一人に寄ってしまっては本末転倒です。判断は決まりごとと例外として書き下し、画面には必ず根拠を出します。この根拠の表示が、そのまま引き継ぎの資料になります。動き出したあとも、保守運用の契約で動き続けることに責任を持ちます。

最終確認は人が行う形にしています。AIから基幹への書き込みは載せていません。出てくるのは判断の案と、その根拠です。決めるのは人のままです。あわせて、細かい調整の作り込みは途中で外しました。揺らぎを持ち込む要因になるからで、決まりごとと貯まっていくデータで精度を上げる形に寄せています。当たり外れのあるものにしないこと自体を、設計の条件にしています。

やれるなら、そのほうがいいと思います。社内に残る資産としても内製が勝ちます。止まりやすいのは、たいてい三か所です。どのタスクが流れを止めているかの見極め、古い基幹への接続、そして機能を削る判断。要件は放っておくと膨らみます。削る判断だけは、社内の力関係の外にいる人間のほうが出しやすいことがあります。設計と判断だけをこちらが持つ形でも、お受けしています。