はじめに
弊社では、社内業務システムや、世の中のお客様向けデジタルサービスで使われるDNSレコードのメンテナンス作業を、情報システム部門が事業部門から請け負っています。
DNSレコードのメンテナンス作業は、一つのミスでサービス停止を引き起こしてしまう可能性があり、とても気合が入りますよね。社内業務システムであればまだいいですが、デジタルサービスへ影響を与えてしまっては一大事です。
このDNSレコードのメンテナンス作業を、より安全、安心に、どんなスキルセットの作業者であっても品質のばらつきなく実施できるよう、生成AIを活用して改善した情報システム部門の取り組みをご紹介します。
改善前のメンテナンスフローと課題
フロー
- 事業部門のシステム管理者が情報システム部門にメンテナンス依頼(メール)
- 情報システム部門でメンテナンス内容を目視で確認（目視確認のポイントはマニュアル化）
- 情報システム部門でメンテナンス
課題
- 前例のない種類のレコードはマニュアルが不十分
- 作業者によってDNSに関する知識や経験にばらつきあり
- 様々な役割があるTXTレコードについて知識がない、など
- 目視確認のため、どうしても見落としがある
- 申請と同じホスト名で既存レコードがあった、など
改善後のメンテナンスフロー
大まかなフロー
- システム管理者は申請フォーム(Microsoft Forms)で申請
- 申請を生成AIが自動でチェック(Microsoft Power Automate、Dify)
- 情報システム部門に申請内容と生成AIがリスク評価した結果を通知 (Slack)
- 情報システム部門でメンテナンス
実装
まず、申請フォームは、社内で標準的に利用されているFormsを使いました。
次のステップでは、Formsとの連携のしやすさで、まずはPower Automateで申請内容 申請者の属性を抽出し、申請内容 申請者の属性をパラメーターにしてDifyのAPIを呼び出します。
Power Automateから直接、生成AIのAPIを呼び出すこともできますが、生成AIの組み込みがとても得意なDifyへパスすることにしました。
Difyの処理はこのようになリました。
生成AIは、単にDNSレコードの書式をチェックするだけでなく、現在のDNSゾーンファイルにレコードを追加したらどんなリスクがあるか、ないか、も評価します。HTTPリクエストブロックで現在のDNSゾーンファイルを取得し、LLMブロックのシステムプロンプトで生成AIにインプットしています。
DNSゾーンファイルをDifyから取得できるように、DNSゾーンファイル原本をAWS S3に安全にコピーして保管する仕組みは別途構築しました。説明は割愛します。
NSレコードなど複数行で1セットのレコードは、複数行まとめて生成AIに渡せるよう、申請内容を配列化するコード実行ブロックで処理しています。
LLMブロックに記述しているプロンプトは以下の通りです。
# タスク
ユーザーからの「新規DNSレコード登録依頼」について、現在のゾーンファイルと照らし合わせ、技術的なリスク評価を行います。
# 判定基準（優先度高）
以下の観点で厳格にチェックを行ってください。
1. **既存レコードとの競合・整合性（最重要）**:
申請されたホスト名が、既にゾーンファイル内に存在するか確認してください。存在する場合、DNSの仕様上、追加登録が許容されるか判定してください。
- **許容されない例**: CNAMEレコードと他のレコードの同居、DMARCやSPFのような「ポリシー定義」を行うTXTレコードの重複登録など、論理的に矛盾や動作不良を起こすケースは「高リスク」と判定してください。
- **許容される例**: 負荷分散のための複数のAレコード登録など。
2. **一般的なDNS技術基準（RFC準拠）**:
- レコードの構文、TTL、種別（Type）が正しく定義されているか。
- 不正な文字やフォーマットが含まれていないか。
3. **Value値の形式チェック**:
- **ドメイン指定の場合**（CNAME, MX, NS等）: Value値の末尾にルートドット「.」が付いているか必ず確認してください。.com や .net などの一般的なTLDであっても、ゾーンファイル上ではドットが必須です。省略されている場合は必ずリスク（構文エラー）と判定してください。
- **IPアドレス指定の場合**（A, AAAA等）: 末尾にドットは不要です。正しいIP形式か確認してください。
# 出力形式の制約
- テキスト形式で、**改行を一切含まずに一行**で出力してください。
- 文頭の挨拶やメタな説明は不要です。
- マークダウン（太字など）は使用禁止です。
最後に、Slackに投稿されたAIの評価はこのようになりました。
- Amazon SESなどで独自ドメインを使うと、DKIMレコードやDMARCレコードはこう登録するといいですよ、と提示してくれますよね。うっかりこれに従ってドメインで一意のDMARCレコードの登録が申請されると、以下のように警告してくれました。
- こちらはNSレコードの登録申請で、書式に不備があった例です。不備を指摘し、このまま登録されると何が起こるかが示され、改善案も示してくれました。
まとめ
最終的な確認は人の責任にはなりますが、この仕組みのおかげで、少ない時間で、これまでより幅広い観点での確認が行えるようになりました。
アナログかつ人間の知識や経験に頼った今までの業務フローを、生成AIとDifyのようなワークフローツールで再構築していく改善は、今後も進めていきたいと思います。