機械や設備を長く使うなら、定期点検や部品交換が必要です。
AIや自動化を使う運用でも、似たことが起きると感じています。
ただし、点検する対象は機械ではありません。
読者
YuLab
AIへ継続して仕事を任せるようになるほど、AIが参照する情報そのものが、新しいメンテナンス対象になると考えるようになりました。
この記事の結論
AI運用では、定期点検と「変更が起きたときの点検」を組み合わせます。変更点・影響範囲・修正候補・再テスト要否はできるだけAIに確認させ、人間は変更要求と正式採用の判断を持つ形が扱いやすいです。
AI運用で「古くなる」のは情報
AIへ渡したルールが最初は正しくても、その後に運用が変わることがあります。
たとえば、
- 使うサービスが変わった
- Sheetの列やタブ構成が変わった
- 投稿フローが変わった
- 公開方法が変わった
- 新しい失敗パターンが見つかった
- 以前の判断基準が現状に合わなくなった
といった変化です。
AIが古い前提を参照すると、以前は正しかった行動が現在は間違いになることがあります。
AI運用では「情報が壊れる」というより、「前提が変わって古くなる」ことを意識する必要があります。
設備保全と同じく「定期点検＋変更時点検」で考える
自分はこの考え方を、設備の保全に近いものとして捉えています。
何も起きていなくても一定間隔で確認する「定期点検」と、変更が起きたときに影響を確認する「変更時点検」の2つです。
定期点検
週次・月次など既存のレビューの中で、最近の不具合、保留、連携エラー、重複作業、古くなったルールがないかを見ます。
点検のためだけに新しい管理作業を増やさず、すでにあるレビューへ統合します。
変更時点検
外部サービス、Sheet構成、公開フロー、ツール接続、定期実行などが変わったときは、その変更がどこへ影響するかを確認します。
変更が小さく見えても、AIが別の場所で同じ前提を使っている可能性があるためです。
実例｜記事を書いた後で流れを作る運用を変えた
最近、自分のWordPress運用でも具体的な変更がありました。
以前は、まず記事を作り、記事数が増えてから「この記事同士をどうつなげるか」を整理していました。
実際に公開記事が増えると、後からハブ記事や内部リンクを組み直す必要が出てきました。
そこで運用を見直し、本文を書く前にシリーズ全体・不足記事・必要情報・前後リンクを設計する工程を追加しました。
この変更は、その場の会話だけで終わらせず、現在の運用仕様へ正式に反映しています。
変更を「次回も効く形」にする
一度うまくいかなかった方法を直しても、会話の中だけで終わると次回また同じやり方へ戻る可能性があります。繰り返し使う改善は、正式ルールや仕様へ残します。
変更時にAIへ確認させたい4つのこと
変更時点検
- 何が変わったか
- どのProject・記事・制作物・ルールへ影響するか
- 仕様書や管理情報のどこを直す必要があるか
- 変更後に再テストが必要か
これらを毎回人間がすべて探すのではなく、AIが参照できる情報から先に洗い出します。
人間は、その提案を見て「この変更を正式採用するか」「高リスクなので止めるか」を判断します。
人間は「保守作業者」ではなく変更要求を出す側へ
理想は、人間が仕様書を毎回開いて差分を探すことではありません。
AI側が、
- 変更を検知する
- 影響先を探す
- 修正候補を出す
- 必要なら再テスト候補を出す
ところまで担当します。
人間は、なぜ期待どおり動かなかったのかを確認し、必要なら「ここを変える」という変更要求を出し、正式採否を決めます。
これはシリーズ最初の記事で扱った、人間が作業者からPMに近い役割へ移る考え方ともつながります。
すべての変更を仕様書へ入れない
変更管理を始めると、何でも記録したくなります。
しかし、小さな言い換えや一時的な試行まで全部ルール化すると、仕様書自体が重くなります。
管理のための管理にしない
正式ルールへ残すのは、次回以降の判断や実行が変わる意味のある変更です。問題がない既存フローに、確認項目や新しいツールをむやみに足しません。
自分の場合は、
- 同じ失敗を防げるか
- 別のProjectにも影響するか
- 次回も同じ判断基準を使うか
- ユーザーの手作業を減らせるか
を見て、正式変更にするか決めています。
再テストも「変更したら全部」ではなく影響で決める
仕様を更新するたびに全工程を再テストすると、それだけで大きな作業になります。
そこで、新形式、新しい連携、外部サービスの仕様変更、大きな運用変更、既存フローのエラー、データ互換性への影響など、リスクがある変更だけ再テスト対象にします。
すでに安定していて、今回の変更と無関係な部分まで毎回やり直さないようにします。
仕様書も「完成品」ではなく運用するもの
最初に完璧な仕様書を作り、それをずっと守ればよいわけではありません。
実際に使うことで、想定していなかった失敗や、もっと楽な方法が見つかります。
だから、
実行 → 問題発見 → 原因確認 → 変更判断 → 仕様更新 → 次回の実行
という循環で育てます。
AI時代のメンテナンス
- 定期点検と変更時点検を分ける
- 古くなった前提・ルール・接続条件を確認する
- 影響範囲と修正候補はAIに先に洗い出させる
- 人間は変更要求と正式採用を判断する
- 意味のある変更だけ仕様へ残す
- 再テストは変更の影響がある範囲に絞る
シリーズ全体で見ると「AIへ任せる運用」が一周する
このシリーズでは、人間の役割、要件の渡し方、完了条件、異常時の記録、Project間の引き継ぎ、仕様の保守までを順番に扱っています。
ここまでつながると、単にAIへ質問する使い方ではなく、AIへ継続的に仕事を任せるための運用として一つの循環になります。
各記事をまとめて見られるシリーズの入口記事も用意し、必要な工程へ移動できる形にします。
コメント