小さな事業のIT手帖

技術メモ担当者・業者向けの記事です。社長向けの入口は トップの困りごと です。

実録

AIに手順書を書かせて、別のAIに検証環境で再現させたら、間違いが5つ出た

公開 更新 読了11分

AIで回すメール

中身の図の縮小版。色が付いているのは: 会社の名前（ドメイン）、住所録（DNS・ネームサーバー）、郵便受け（メール）、社員の名簿と入館証（アカウント・パスワード）契約の名義とログイン情報ドメインDNSサイトメールアカウントファイルバックアップ電源・機器回線端末ソフトホームページとメール・パソコンの中身の図の、ここの話です会社の名前（ドメイン）／住所録（DNS・ネームサーバー）／郵便受け（メール）／社員の名簿と入館証（アカウント・パスワード）中身の図で位置を見る →

AIに手順書や社内向けの説明を書かせた。読むと筋は通っている。けれど、このまま社内に出してよいのか、確信が持てない。そういう人へ。

AIの文章には「もっともらしい誤り」が混ざります。厄介なのは、読んで確かめても見つからず、実際に動かして初めて見つかる種類がある、ということです。 このサイトの記事はAIに書かせています。今日、別のAIに検証環境を作らせて記事の手順を再現させたところ、記述の誤りが5つ出ました。読み終えると、同じ確かめ方を自分の会社で小さく回せます。

この記事で出来ること
AIに書かせた手順書を、配る前に「書いた当人ではない誰かに実際にやらせる」形で確かめられる
前提
専門知識は不要。検証環境を自分で作る場合だけ、Dockerが動くパソコンが1台要る
所要時間
読むのに10分。確認表を1本の手順書に当てるのに30分〜半日

先に結論：私ならこうします

  • AIに書かせた手順書は、書いた当人ではない誰か（別の担当か、別のAI）に実際にやらせてから配る。
  • 検証環境を作れない物は、公式の文書か、業者の検証結果に当たる。
  • 同じAIの同じ会話に「合ってる？」と聞いて済ませない。今回の5つは、書いたAI自身は1つも疑っていませんでした。
目次（7）
  1. 1. 何をしたか
  2. 2. 見つかった5つの誤り
  3. 3. 読者になりきる役が落とした6本
  4. 4. つまずいた所
  5. 5. 小さな会社で真似するなら
  6. 6. 確認表：自社で回すための5項目
  7. 誤りが見つかった記事

1. 何をしたか

このサイトは、AIのコーディング支援ツールと、その上で動かす複数のエージェントの分業で作っています。役割は4つに分けました。

役やること
書く役公式の文書を出典に、記事を書く
再現して撮る役検証環境を作り、記事の手順と場面を実際に動かし、出力を保存する。記事には触らない
読者になりきって判定する役「用語は初耳、焦っている、スマホ」の読者として読み、5つの問いで合否を付ける
事実を確かめる役記事の中の出力と保存した出力を機械的に突き合わせ、数字と引用を原文で確認する

決まりは1つ、書いた本人に検証させないことです。再現する役には記事を直す権限を与えず、「記事と違っていた点」を報告させました。

検証環境は、アカウントの登録が要らない物だけで組みました。Dockerの上に、DNSサーバ（親・旧・新）とキャッシュDNS、メールサーバ、Webサーバ、取引先の送信サーバ役。別に、LinuxのRAID 1と、Sambaのファイルサーバ。アドレスは文書用の 192.0.2.0/24、ドメインは example.jp で、外のDNSには問い合わせません。

2. 見つかった5つの誤り

① 「エラーが送信者に返る」→ 実際は、何も返らず保留されていた

AIが書いた文: ネームサーバーの切り替えでMX（メールの届け先）を写し忘れた場面で、「Webサーバがメールを受けなければ送り主にエラーが返り」。

検証環境で起きたこと: 送信サーバ（Postfix）のログはこうでした。

lab$ grep -E "status=" /var/log/mail.log | tail -3
（中略）
Sep 20 11:08:24 client postfix/smtp[364]: 194C540AE6: to=<info@example.jp>, relay=none, delay=0.01, delays=0/0/0/0, dsn=4.4.1, status=deferred (connect to example.jp[192.0.2.80]:25: Connection refused)
Sep 20 11:09:02 client postfix/smtp[364]: 194C540AE6: to=<info@example.jp>, relay=mail.example.jp[192.0.2.22]:25, delay=38, delays=38/0/0.01/0.03, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 2EE6C42D4D)

1行目が status=deferred（保留）。メールは送信側の待ち行列に残り、送り主には何も返っていません。MXを直した後の2行目で、同じ1通（194C540AE6）が新しいサーバへ status=sent になっています。後から届いたわけです。Postfixが保留を続ける日数の既定値は5日です（postconf の maximal_queue_lifetime）。送り主に即座に不達通知が返ったのは、MXもAレコードも無い場合だけでした。

MXが空でAレコードだけが返る dig の出力と、Postfixのログ「connect to example.jp[192.0.2.80]:25: Connection refused」「status=deferred」、mailqに1通残っている様子
MXが無いと、送信サーバはWebサーバの25番へ行く。拒否されるとメールは送信側に保留で残り、送り主にはすぐには何も返らない（検証環境で再現・撮影 2026-09-20）

なぜ読んでも気づけなかったか: 「届かなければエラーが返る」は日常の感覚に合っていて、文として不自然な所がありません。RFC 5321 が再送を数日続けるよう求めていることを知っていても、この1文と結び付けて疑うのは難しい。しかも意味が逆になります。「エラーが来ないから届いているはず」と取引先が思い込む数日間が、いちばん危ない。

直した文: 「Webサーバが25番を閉じていれば、相手のメールサーバは配送を保留にして、数日間、再送を続けます。その間、送り主には何も返りません。裏を返せば、この間にMXを直せば、保留されていたメールは後から届きます」

② 「無い」という答えも覚えられている、が抜けていた

AIが書いた文: TTL（DNSの答えを覚えておく秒数）の説明はありました。ただ、「MXを足した直後に、まだ見えない」場面の説明がありませんでした。誤りというより、欠落です。

検証環境で起きたこと: 新しいネームサーバーにMXを足した3秒後、キャッシュDNSの答えはこうでした。

lab$ date "+%H:%M:%S"; dig +noall +answer +authority example.jp MX
11:08:32
example.jp.		6	IN	SOA	ns1.new-dns.example. hostmaster.lab.example. 2026092101 3600 600 86400 60

lab$ date "+%H:%M:%S"; dig +noall +answer +authority example.jp MX
11:08:45
example.jp.		120	IN	MX	10 mail.example.jp.

1回目はMXではなくSOAの行が返っています。「MXは無い」という答えを、あと6秒覚えている、という意味です（RFC 2308 のネガティブキャッシュ）。13秒後にMXが見えました。検証環境は60秒に設定しましたが、実際のDNSではもっと長いことがあります。

新ネームサーバーにはMXがあるのに、キャッシュDNSはSOAだけを返している dig の出力。13秒後にMXが返り、溜まっていたメールが status=sent になったログ
MXを足した直後は、キャッシュDNSが「無い」という答えを覚えている。切れるとMXが見える（検証環境で再現・撮影 2026-09-20）

なぜ気づけなかったか: 書かれていない事は、読んでも見つかりません。手順どおりに動かして「足したのに見えない」に自分でぶつかって、初めて欠落だと分かります。現場では、ここで慌てて設定を何度も書き換える事故になります。

直した文: 「慌てて設定を書き換えないでください。『無い』という答えも、一定時間キャッシュされます。新しいネームサーバーに直接聞いて入っていれば、あとは待つだけです」

③ アカウントを止めても、開いていた接続は生きていた

AIが書いた文: 退職者の処理で「②サインインを止める」。停止は戻せるので先に止める、で終わっていました。

検証環境で起きたこと: Sambaで、利用者の接続を1本開いたままにして、その間にアカウントを無効にしました。

lab$ smbclient //localhost/share -A /lab/auth/tanaka -c 'ls'
session setup failed: NT_STATUS_ACCOUNT_DISABLED

新しい接続は拒否されます。ところが、無効にする前から開いていた接続では、無効にした後も、フォルダの一覧とファイルの取り出しが通りました。

アカウントを無効化すると新しい接続は NT_STATUS_ACCOUNT_DISABLED で拒否されるが、無効化の前から開いていた接続では ls と get が通っている
アカウントを無効化した直後。新しい接続は拒否されるが、開いたままの接続は生きていた（Sambaスタンドアロンの検証環境・撮影 2026-09-20）

なぜ気づけなかったか: 「止めた」の後に何が残るかは、止めてみないと見えません。読む側も「止めれば止まる」と思って読みます。

直した文: 「止めた後、開いたままの接続を切るところまでが②です」。ただし、これは単体のSambaでの結果です。Windows Server や Active Directory、各社のNASでは確かめていないので、記事にも「検証環境のSambaでは」と断って書きました。

④ 「3行とも入れよう」と書いたサイト自身に、DMARCが無かった

AIが書いた文: 別の記事で「SPF・DKIM・DMARCの3行を入れる」。

検証で起きたこと: 再現する役が、このサイトのドメインを外から引きました。

lab$ dig +noall +comments _dmarc.it-techo.com TXT | grep status
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 759

NXDOMAIN、つまり、その行が存在しない。勧めている当のサイトが、2行目までしか入れていませんでした。その日のうちにDMARCの行を足し、記事には足した後の出力を載せています。

なぜ気づけなかったか: 記事の文は正しいからです。誤っていたのは文章ではなく足元で、文章をいくら読んでも出てきません。「自分の環境に同じコマンドを打つ」を検証の項目に入れていたから見つかりました。

⑤ 「名前も住所も出ない」→ 国と都道府県は出ていた

AIが書いた文: ドメインの登録情報の代理公開について、「自分の名前も住所も出ません」。

検証で起きたこと: このサイトのドメインをRDAP（WHOISの後継）で引くと、登録者の氏名は DATA REDACTED、番地・市区町村・郵便番号も伏せられていました。ただし、国と都道府県の欄には値が入っていました。ICANNの方針で、伏せない項目です。

it-techo.com のRDAPの出力。登録事業者は Cloudflare, Inc.、登録者の氏名は DATA REDACTED、注記は REDACTED FOR PRIVACY
当サイトのドメインを公開RDAPで引いた結果。登録者の氏名は伏せられている（撮影 2026-09-20）

なぜ気づけなかったか: 「概ね正しい」からです。ほとんど正しい文は、疑う気が起きません。けれど、自宅の住所で登録する人にとって、都道府県が出るかどうかは小さな話ではありません。

直した文: 「登録者の欄に自分の名前も番地も出ません。ただし国と都道府県までは表示されます」

3. 読者になりきる役が落とした6本

誤りとは別の話ですが、同じ日の結果なので書いておきます。読者になりきって判定する役は、14本のうち6本を「上から読むだけでは、今やることが分からない」で不合格にしました。型は1つで、コマンドを打てる前提で始まり、打てない人・管理画面に入れない人の道が記事の後ろにある。書く役は技術的に正しい順に書き、焦っている人が読む順には書いていませんでした。事実の誤りではないので、事実を確かめる役には見つけられない種類の欠点です。

4. つまずいた所

検証環境づくりも、すんなりは行きませんでした。

  • MacのDockerでは、RAIDが組めなかった。 Docker Desktop が使うLinuxのカーネルに、ソフトウェアRAID（md）の機能が入っていませんでした。コンテナの中でQEMUを動かし、Alpine Linux の本物のカーネルを起動して、その中で mdadm を使う形に変えています。1回の通しは2〜3分です。
  • クラウド同期のフォルダの下では、bind mount が固まった。 作業フォルダがクラウド同期の配下にあり、設定ファイルをコンテナに見せる方法（bind mount）が止まりました。設定はすべてイメージに焼き、切り替えるファイルだけを Docker のボリュームにコピーする形にしています。

検証環境にも限界があります。故障は論理的に起こした物で、物理的な故障ではない。Sambaは単体で、Active Directory ではない。再現できなかった事は「再現していない」と、検証環境の説明書きに残しました。

5. 小さな会社で真似するなら

私ならこうします。

  • AIに書かせた手順書は、配る前に、別の担当か別のAIに「実際にやらせる」。 読ませるのではなく、やらせる。詰まった所、書いてある結果と違った所を報告してもらう。今回の5つのうち①②③は、やって初めて出ました。
  • 検証環境を作れない物は、公式の文書か、業者の検証結果に当たる。 基幹のサーバや契約中のクラウドで試すわけにはいきません。「この手順は検証済みですか。どの版で、いつ」と業者に聞くのは、失礼ではありません。
  • 自分の環境に同じ確認のコマンドを打つ。 ④と⑤は、検証環境ではなく、自分のドメインを外から引いて出ました。見るだけのコマンドなら、何も壊れません。
  • AIの判定を最終判断にしない。 読者になりきる役の「合格」は、人間の読者の合格ではありません。社内に出すかどうかを決めるのは、出した後に問い合わせを受ける人です。
  • 再現できなかった事は「未確認」と書いて残す。 確かめた範囲を書いておけば、次に確かめる人がそこから始められます。

やめたほうがいいのは、次の2つです。

  • AIの出力を、そのまま社内手順にする。文が整っていることと、合っていることは別です。
  • 書いた当人（同じAIの同じ会話）に「合ってる？」と聞いて済ませる。自分の文脈の中で読み直すだけで、動かしてはいません。今回、書く役は5つのどれも自分からは疑いませんでした。

6. 確認表：自社で回すための5項目

AIに書かせた手順書1本ごとに、配る前に埋めます。

#確かめること結果確かめた人・日付
1書いた当人ではない人かAIが、手順を最初から最後まで実際にやったか
2手順に書いてある結果（画面・出力）と、実際の結果が一致したか。違った所はどこか
3試せなかった手順について、公式の文書か業者の検証結果を確認したか（URL・版・日付）
4自社の環境で、見るだけの確認（設定の一覧、dig など）を実際に打ったか
5確かめられなかった事を「未確認」として手順書に書き残したか

誤りが見つかった記事

どれも、上の内容を反映して直してあります。

出典（取得日 2026-09-20）

この記事は特定の製品の使用レビューではありません。公式仕様と公的情報をもとに整理しています。 ・仕様の取得日

次にやること