【Agent Hackathon】DNS変更作業をAIエージェントで証跡化する ChangeProof Agent を作った
DNS変更のリスク評価から承認文、実行手順、ロールバック手順、Evidence Bundleの保存まで、AIが一括して生成するMVP。際立つのは「AIにDNSを変更させない」という設計方針で、人間が作業する前後の判断材料と証跡を揃えることに役割を絞っている。小規模ITチームで証跡が曖昧になりやすい変更作業に、説明可能なプロセスを与えようとした試みだ。
「何をさせないか」から設計が始まる
承認フローをAIで自動化する取り組みは増えている。リスク判定、申請文生成、承認ルーティング——いずれも自動化の対象として語られる。ただし多くの場合、議論は「どこまで自動化するか」に向かい、「AIに何をさせないか」は後回しになりやすい。
ChangeProof Agentの設計はその順序を逆にしている。AIは「判断材料の整備者」として位置づけられ、変更の実行は人間に委ねられる。承認文はドラフトであり、実行手順は参照資料だ。AIのアウトプットが「材料」である以上、それを使って判断し実行するのは人間のアクションに結びついたままになる。
このラインの引き方が、責任の所在を決める。
証跡の構造化が「後から説明できる」を作る
元記事が指摘する課題は明確だ。DNS変更やサーバー切替は、経験者の頭の中で完結することが多い。変更前の状態、承認の根拠、失敗時の戻し方——これらが残らないまま作業が進み、事故・監査・引き継ぎの場面で初めて証跡の欠如が問題になる。
Change Intake → Risk Assessment → Approval Brief → Execution Plan → Rollback Plan → Evidence Report というパイプラインは、作業の順序を強制するのではなく、「この変更について何を確認したか」の記録を自動的に整える仕組みとして機能する。AIが生成するのは承認そのものではなく、承認を支える構造だ。
この構造があることで、「誰が、何を根拠に、どの範囲の変更を承認したのか」がたどれる状態が初めて作られる。
同じ設計パターンが波及しうる場所
「人間が実行する前の判断材料をAIが整備する」という発想は、DNS変更に限らない。
インフラのパラメータ変更、セキュリティポリシーの更新、顧客データの移行——いずれも、手順書は存在しても証跡が追えない状態になりやすい業務だ。特に、変更の影響範囲が広いほど、後から「何を根拠にその変更を承認したか」を再構成するのが難しくなる。
変更管理の重いプロセスが乗らない業務ほど、このアプローチは有効に機能する可能性がある。AIが「承認を代替する」のではなく「承認に必要な構造を渡す」設計は、人間の最終判断責任を維持したまま自動化の恩恵を受ける現実的な経路として広がりうる。
ChangeProof Agentはそのモデルケースの一つとして読める。変更管理ツールというより、「AIの役割をどこに引くか」という設計パターンの例示として。
関連記事
- サイバーセキュリティ特化型AIモデルは、汎用モデルよりも防御効果を実質的に高めるのか？
- Check out real-life AI prototypes from the Futures Lab.
- 9 demos of Gemini Omni and Gemini 3.5 in action
参考文献
コメント