※この記事は、2026年7月時点でAIを使って業務設計書を作り、監査とテストを重ねている途中の実運用メモです。設計書の具体的なプロンプトや個別業務の中身ではなく、作った後の更新方法に絞って書いています。
最近、複数のAIで使える業務設計書を作っています。
最初に大枠を作り、分野ごとの役割を並べ、安全ルールや人間の確認点も入れました。
一式がそろった時点では、かなり形になったように見えました。
ところが、実際に監査してみると、抜けている役割が見つかりました。
追加した内容が、元の設計と噛み合っているか確認する必要も出てきました。
さらに、役割を追加しただけでは安心できないので、テストケースも必要になりました。
作って終わりではありませんでした。
むしろ、一度形にした後から、
「ここが足りない」 「この説明では判断がぶれる」 「この役割は人間の確認を強く残した方がいい」
という部分が見えてきました。
そこで今は、AIに作らせた設計書を完成品ではなく、実際の運用で増えた判断を戻していく台帳として持つ方がよさそうだと考えています。
設計書が一式そろっても、完成とは限らなかった
今回作っている設計書は、一つのプロンプトだけではありません。
複数の分野で使う役割。 共通の安全ルール。 必要な入力。 作業の流れ。 AIが止まる条件。 人間が最終判断する場所。 参考にした資料。 全体を探すための索引。
こうしたものを一式にしています。
最初は56個の役割を整理しました。
かなり多く見えますし、ここまでそろえば一度完成としてもよさそうでした。
ただ、外部資料との対応を監査すると、取り込めていない役割が見つかりました。
そこで5個を追加し、56個から61個へ増やしました。
問題は、数を増やせば終わりではないことです。
新しく追加した役割だけ書き方が違わないか。 共通ルールから外れていないか。 AIが最終判断まで踏み込む表現になっていないか。 必要な入力や出典確認が抜けていないか。 索引からきちんとたどり着けるか。
こうした確認が必要になります。
設計書は、ファイルがそろった時点では「形になった」にすぎません。
使える状態かどうかは、その後の監査とテストで決まるのだと思います。
AIに作らせた設計書ほど、実際に使った後の違和感を戻したい
AIに設計書を作らせると、最初からかなり整ったものが出てきます。
見出しもそろっています。 手順も並んでいます。 注意点も書かれています。
人間がゼロから作るより、早く形になります。
ただ、文章が整っていることと、実際の運用に合っていることは別です。
使ってみると、
「この役割は入力が曖昧だと動けない」 「ここはAIに任せるより、人間が選んだ方がいい」 「確認した証拠を残さないと、後から判断できない」 「別の分野でも同じ失敗をしている」
といった違和感が出てきます。
この違和感を、その場のチャットだけで直して終わると、次に別のAIや新しいチャットを使った時にまた同じ問題が起きます。
だから、うまくいかなかった理由や追加した確認点を、元の設計書へ戻す必要があります。
自分の中では、設計書をきれいな説明書として保つより、運用で見つかった判断を蓄積する方が重要になってきました。
設計書そのものが、AIへ仕事の前提を渡す場所になるからです。
更新するのは、本文だけではなかった
今回やってみて分かったのは、一か所を直すだけでは足りないことです。
役割を追加したなら、本文だけでなく索引にも追加する必要があります。
外部資料との対応を監査したなら、何を確認し、何が未確認なのかも残したいです。
テストしたなら、通ったことだけでなく、残っているリスクも分けておきたいです。
少なくとも、次の五つは一緒に見た方がよさそうでした。
- 実際の役割や手順
- 共通の安全ルール
- 全体から探すための索引
- 監査結果と未確認事項
- テストケースと結果
本文だけ最新で、索引が古い。
役割は追加されているのに、監査側では未対応のままになっている。
テスト結果はあるのに、設計書側へ注意点が戻っていない。
こうなると、人間もAIも、どれを現在の状態として読めばよいか分かりにくくなります。
これはObsidianの監査でも似た問題がありました。
情報が保存されていることと、今の入口から正しい情報へたどり着けることは別です。
設計書も同じで、内容を増やすだけではなく、入口、更新日、状態まで合わせて直す必要がありました。
今は「記録→監査→差分→テスト→反映」で回している
現時点では、設計書の更新を次の流れで考えています。
1. 運用中の違和感を記録する
AIの回答が少しずれた。 必要な入力が足りなかった。 人間の確認場所が弱かった。 別の役割と説明が重複していた。
まずは、こうした違和感をその場で消さずに残します。
この段階では、すぐ正解を決めなくてもいいと思っています。
2. 既存の設計と照らして監査する
その違和感が、一つの役割だけの問題なのか。 共通ルールの問題なのか。 索引や入口の問題なのか。 そもそも外部資料の読み落としなのか。
直す場所を分けます。
ここを飛ばして、見つけた場所だけ書き換えると、別のファイルと矛盾しやすくなります。
3. 小さい差分案を作る
いきなり設計書全体を書き直させるのではなく、どこへ何を追加・変更するかを小さく出します。
追加する役割。 変える一文。 強くする注意書き。 索引へ足す項目。
差分が小さければ、人間側でも確認しやすくなります。
4. テストケースで確認する
文章として正しく見えても、実際の作業でどう動くかは別です。
必要な入力がない時に止まれるか。 出典を確認できない時に断定しないか。 AIが最終判断まで進んでいないか。 別の役割と同じ仕事をしていないか。
想定する場面を作り、設計どおりに動くか確認します。
5. 採用した内容だけ設計書へ戻す
テスト結果を見て、人間が採用すると決めたものだけ反映します。
その時に、本文だけでなく、索引、更新日、監査記録も一緒に直します。
この流れなら、AIに更新作業を手伝ってもらいながらも、何を正式なルールにするかは人間側で握れます。
設計書の自動更新までは任せない方がよさそう
設計書を更新し続けるなら、AIに全部自動で直してもらえば早そうです。
実際、技術的にはかなりの部分を任せられると思います。
運用ログを読む。 問題らしい箇所を探す。 変更案を作る。 関連ファイルを更新する。 テストを走らせる。
ここまでつなぐことはできます。
ただ、今の自分は、設計書そのものをAIの判断だけで自動更新するところまでは進めたくありません。
AIは、もっともらしい改善案を出せます。
しかし、その改善が自分の目的に合っているか。 公開してよい範囲か。 有料で扱う内容に踏み込んでいないか。 人間が持つべき判断までAIへ渡していないか。
ここは、文章の整合性だけでは決められません。
だから、自動化するなら、
運用ログから候補を抜く。 関係するファイルを探す。 差分案を作る。 テスト結果をまとめる。
このあたりまで。
正式な設計書へ採用するかどうかは、人間が決める。
今のところは、この分け方がちょうどよさそうです。
前の記事では「作る時」、今回は「使った後」の話
以前、AIに設計書を作らせるなら、「汎用化していい部分」と「残す前提」を分けた方がよさそうだと書きました。
あの記事は、設計書を作る時の話です。
何を別の作業へ横展開してよいのか。 どのAIや環境の前提は残すのか。 どこを薄めると、欲しかった設計から外れるのか。
今回は、その続きになります。
残す前提を決めても、最初から完璧な設計書ができるわけではありません。
実際に使うと、抜けや重複が見つかります。
監査すると、元資料との対応不足が見つかります。
テストすると、文章では見えなかった危険が出てきます。
その結果を、次のチャットだけで使う一時的な修正にせず、設計書へ戻していく。
作る時の線引きと、使った後の更新。
この二つがそろって、ようやく設計書が自分の運用に近づいていくのだと思います。
まとめ
AIに設計書を作らせると、かなり早く形になります。
ただ、形になったことと、運用で使えることは別でした。
今回の設計書も、一式を作った後の監査で不足が見つかり、役割を追加し、さらにテストケースを作るところまで進みました。
その過程で感じたのは、設計書を完成品として保存するより、運用で増えた判断を戻す台帳として持つ方がよさそうだということです。
運用中の違和感を残す。 既存の設計と照らして監査する。 小さい差分案を作る。 テストする。 人間が採用を決める。 本文、索引、更新日へ反映する。
AIに全部を任せるのではなく、AIには候補抽出、監査、差分作成、テストを手伝ってもらう。
何を正式なルールにするかは、自分で握る。
設計書を作った後に、この戻し先があるだけでも、同じ説明や修正を何度も繰り返すことは減らせそうです。
設計書は、完成したら閉じる文書ではない。
AIと仕事を続けるために、少しずつ更新していく運用記録なのだと思います。
コメント