AI に書かせた技術書を9回レビューした記録（指摘302件）— こわかったのは「確認したつもり」の4件でした

Last updated at 2026-09-26Posted at 2026-09-24

はじめに

Linux の障害対応をまとめた技術書を、AI に書かせました。本文13ファイル・7,739行、最終的に A4 で327ページの PDF になったものです。

書かせただけでは出せないので、レビューしました。レビューしたのも AI です。1回のレビューを4体に分担させ、それを9回。のべ36回ぶんの指摘を、人間（私）が1件ずつ見ました。

結果、指摘は 302件 でした。

この記事は、その302件がどう出てきたかの記録です。「AI はすごい」でも「AI はダメだ」でもなく、どこで間違えたかを件数で残すことが目的です。同じことをやる人が、どこに時間を使うべきかの目安になればと思います。

先に結論を書きます。

直すと、直した場所から新しい欠陥が出ました。 指摘件数は一度増えています（29件 → 44件）。
AI が書いた調査資料に、9か所の誤りがありました。 しかも本文のほうが正しく、資料が間違っていました。
一番こわかったのは、AI が「確認した」と言った4件です。 4件とも、確認の方法そのものが間違っていました。

1. 何をやったか


作ったもの	Linux の障害一次対応の技術書（RHEL / AlmaLinux / Rocky 8・9 が対象）
規模	本文13ファイル・7,739行。障害対応20テーマ、チェックリスト4本、コマンドチートシート1本
期間	2026-09-09 〜 2026-09-21
書いた	AI（執筆担当のエージェント）
調べた	AI（調査担当のエージェント）
レビューした	AI（レビュー担当のエージェント×4体で分担）
検収した	人間（私）

レビューは、指摘の重さを HIGH / MEDIUM / LOW の3段階で返させました。基準はあらかじめ決めてあります。

重さ	何を起こしうるものか
HIGH	データの消失、サービス停止、締め出し、セキュリティを弱めること、実質的に誤った切り分け、裏付けの無い危険な操作
MEDIUM	誤った診断、大きな混乱、バージョンの条件の欠落、運用の案内が不完全であること
LOW	運用上のリスクが小さい、見せ方や分かりやすさの問題

HIGH が1件でもあれば、原則として FAIL（差し戻し）です。

2. レビュー9回の件数

各回の「新しく出た指摘」の件数です。

回	日付	HIGH	MEDIUM	LOW	計	判定
1巡目 1回目	09-09	5	29	26	60	FAIL
1巡目 2回目	09-10	2	13	19	34	FAIL
1巡目 3回目	09-14	2	7	20	29	FAIL
2巡目 1回目	09-15	0	11	33	44	FAIL
2巡目 2回目	09-16	1	9	32	42	FAIL
3巡目 1回目	09-18	0	10	27	37	FAIL
3巡目 2回目	09-19	0	7	24	31	FAIL
4巡目 1回目	09-21	0	1	17	18	FAIL
4巡目 2回目	09-21	0	0	7	7	PASS
計		10	87	205	302

最後の回で、はじめて HIGH と MEDIUM が0になりました。残った LOW 7件は、どれも1〜2行の追記で済むものです。

記録上の注意: 1巡目1回目の件数は、重大度別の表では60件、次の回の「解決状況」の表では61件になっています。1件の差がどこから来たのかは記録から特定できませんでした。ここでは重大度別の表の値を使っています。件数を扱う記事でこう書くのは格好がつきませんが、合わない数字を合わせて書くほうが問題なので、そのまま残します。

3. 発見1 — 直すと、直した場所から新しい欠陥が出る

表の4行目を見てください。

3巡かけて直した直後のレビューで、指摘が29件から44件に増えています。

増えた理由は、記録にはっきり書いてあります。2巡目2回目の記録から引きます。

今回の指摘42件は、すべて「修正ラウンドで新しく入った欠陥」または「これまで見落とされていた欠陥」です。修正が次の欠陥を生む傾向は、サイクル2でも続いています。

具体例を1つ。SSH の章で「設定ファイルをホームディレクトリに退避してから変更する」という手順を直したところ、こういう指摘が出ました。

コンソールから root で復旧するとき、~ が /root になり、ホームに退避したファイルに届かない。E5 の変更で入った退行

E5 は、前のサイクルで入れた修正方針に付けた社内の番号です。前のサイクルの修正が原因だと、レビュー側が名指ししていることになります。

退避先を ~/trouble-<日付>/ に統一する、という修正自体は正しいものでした。ただ、その章には「SSH で入れなくなったらコンソールから root で入る」という復旧経路があり、そこを通ると ~ の指す先が変わります。修正した AI は、自分が直した手順が他の経路から呼ばれることを見ていませんでした。

もっと分かりやすいのは1巡目です。2回目の指摘32件のうち、4件が「部分的にしか直っていない」と判定されました。そしてその4件は、3回目のレビューで出た HIGH 2件の原因そのものでした。記録には「新規 B3-H1 / B3-H2 の原因」と書かれています。

中途半端に直した場所が、次のラウンドで最も重い指摘になって返ってきた、ということです。

持ち帰り: AI に修正させたら、直した場所の周辺を読み直してください。 「指摘が減ったか」ではなく「直した場所から何が出たか」を見る必要があります。件数が減り始めたのは、4巡目（18件 → 7件）になってからでした。

4. 発見2 — 調査資料のほうが間違っていた

この作り方では、調査担当の AI が先に根拠をまとめ、執筆担当の AI がそれを読んで本文を書きます。つまり 調査資料が間違っていれば、本文も間違う はずです。

ところが、レビューの過程で逆のことが起きました。本文は正しいのに、調査資料が誤っている箇所が9件見つかりました。

記録では、こう整理されています。

レビューの過程で、商品側が正しく、調査資料側が誤っている／不足していることが分かった箇所です。

中身の例を3つ挙げます。

内容	どう間違っていたか
`systemctl show -p RestartSec,StartLimitIntervalSec,...`	`VERIFIED`（確認済み）のラベルが付いていたが、プロパティ名が誤っている可能性が高い
`logrotate` の実行	「対象を絞って実行を推奨」と書かれていたが、本文と逆の内容だった
古いカーネルをまとめて消す `dnf` の書き方（オプションの組み合わせ）	上流のソースと食い違っていた。そのまま実行すると意図と違う対象が消えうるため、ここには書きません

1行目が個人的に一番こたえました。この資料には、項目ごとに VERIFIED（確認済み）と INFERRED（推論）のラベルが付いています。 自分で調べて確認した、と AI が宣言した項目が、間違っていたわけです。

そして、この9件のうち2件は、最終ラウンドの HIGH 2件として出てきました。 つまり資料の誤りは、最後の最後まで本文に残りかけていたということです。

持ち帰り: AI が自分で付けた「確認済み」ラベルは、確認の証拠になりません。 ラベルを付けたのも同じ AI です。根拠として使うなら、ラベルではなく リンク先の一次情報 を見る必要があります。

5. 発見3 — 「確認したつもり」が4件

ここが本題です。

302件の指摘は、大半が「手順が足りない」「順序が逆」といった、読めば分かるものでした。こわかったのはそこではありません。AI が「確認しました」と報告してきて、その確認の方法自体が間違っていた ケースが4件ありました。

(1) grep がインデント行を拾えず、「除去済み」と報告した

危険なコマンドを本文から消したかを、grep で機械的に確認していました。結果は「除去済み」。ところが実際には残っていて、次のラウンドで見つかりました。

記録にはこうあります。

機械チェックは（中略）sudo dnf update コードブロックを「除去済み」と判断しました。インデントされた行を検出できなかったためで、実際には（次のラウンドで）除去されています。

検索パターンが行頭を前提にしていたため、字下げされた行に当たらなかった、というだけの話です。「0件でした」という報告は、「無い」ではなく「そのパターンでは見つからなかった」でしかありません。

(2) 文字数を grep で数えたら、約1.8倍になった

記事の分量を報告させたところ「13,452字 / 8,023字」と返ってきました。実際は 6,313字 / 3,929字 です。約1.8倍に膨らんでいました。

日本語の文字を数えるのに、文字クラスを指定した grep で1文字ずつ拾い上げて行数を数える、という方法を使っていたのが原因です。コードブロックや記号が二重に数えられていました。数え方を確かめずに、出てきた数字をそのまま報告していた わけです。

(3) 「注意書きが抜けている」と判定して、重複を作った

別の記事で「引用元にある I/O 負荷の注意書きが、記事側に入っていない」と判断し、段落を追加しました。

実際には、記事側にも同じ内容の段落が既にありました。 grep の結果の件数を読み違えたためです。結果として、同じことを言う段落が2つ並びました。あとで統合しています。

この件から、作業ルールを1つ追加しました。「引用元に注意書きがある場合は、件数の grep ではなく、コマンドの隣の本文を読んで確認する」 というものです。

(4) 終了コードで判定したら、常に成功になった

検証環境で、ホスト側のディスクがマウントされていないかを確認する必要がありました。使ったのはこのコマンドです。

findmnt -t vboxsf,9p,cifs,nfs,nfs4,virtiofs,fuse.vmhgfs-fuse

これを「終了コードが 0 なら安全」と判定しようとしました。findmnt は、該当が1件も無くても 0 を返します。 つまりこの判定は、何がマウントされていようといまいと、常に「安全」になります。

判定を 出力が空かどうか に直しました。

4件に共通していること

並べてみると、4件とも同じ形をしています。

	使った道具	何を見ていたか	何を見るべきだったか
(1)	grep	マッチ件数	実際の本文
(2)	grep	行数	数え方の妥当性
(3)	grep	マッチ件数	コマンドの隣の文章
(4)	findmnt	終了コード	出力の中身

確認の道具が「何も見つからなかった」と言ったとき、それは「無い」という意味ではありません。「そのやり方では見つからなかった」という意味です。AI はこの区別をせずに、前者として報告してきます。

これは AI に限った話ではなく、自動チェックを書く人間も同じことをやります。ただ AI の場合、確認の手順まで AI が考える ので、手順が間違っていても、報告は自信たっぷりに「確認しました」で返ってきます。

6. 同じ構造が、Linux コマンドの側にもあった

面白かったのは、本文の内容を実機で確かめたときです。「成功したように見えて、何もしていない」コマンドが、Linux 側にもありました。

検証環境（AlmaLinux 8.10 と 9.7）で確かめた結果です。

`mkdir -p -m 700` は、既にあるディレクトリの権限を直さない

~/.ssh の権限を直す文脈でよく出てくる書き方です。

状況	結果
既に `755` で存在するディレクトリに `mkdir -p -m 700`	`755` のまま。終了コードは 0 で、エラーも警告も出ない
新規に作る場合	`700` になる
`mkdir -p -m 700 x/y/z`（途中も新規）	`x` = `755`、`x/y` = `755`、`z` だけ `700`

-m は新しく作るディレクトリにしか効きません。.ssh が既にあると、権限は直らないのに成功として終わります。

権限を確実に直すなら chmod 700 を別に実行し、stat -c '%a' で確認する必要があります。

NFS 上のホームでは `restorecon` が効かない（しかも終了コード 0）

ホームディレクトリが NFS の上にある環境で、SELinux のラベルを直そうとした場合です。

確認したこと	結果
NFS マウント上のラベル	中のファイルまですべて `system_u:object_r:nfs_t:s0` のひとつのコンテキスト
`restorecon` で付け替えられるか	できない。終了コードは 0 だが、ラベルは変わらない
`use_nfs_home_dirs` の既定	off
off のまま公開鍵認証	失敗する

「鍵は置いたのに入れない」の原因がこれだった場合、ls -Z で見てもラベルは付いているように見えます。そして restorecon は成功として終わります。

確認できた範囲について。 これは AlmaLinux 8.10 と 9.7 の検証用 VM 2台で確かめた結果です。RHEL と Rocky Linux の実機では確認していません。NFS の確認は 9.7 のみで行いました。ご自身の環境で確かめてから使ってください。

7. もうひとつ、レンダリングで23行

これは技術的には小さい話ですが、AI に日本語を書かせるなら知っておく価値があります。

原稿を PDF にしたとき、太字が描画されていない箇所が23行 見つかりました。

日本語の **太字** は、前後に 「 」 （ ） 。 、 が来ると、Markdown の記法として成立せず、** が文字のまま残ったり、太字にならなかったりします。原稿を目で読んでも気づけません。 記法としては正しく見えるからです。

以降は、marked で実際にレンダリングして、出力側に ** が残っていないかを検査する 方法に変えました。正規表現で原稿を検査する方法では取りこぼします。

8. では、どう検収するか

302件を見て、最後に手元に残ったチェック項目です。AI に技術文書を書かせる人向けです。

件数の報告を、判定に使わない。 「0件でした」は「そのやり方では見つからなかった」です。本文を読んで確かめてください。
終了コードではなく、出力と状態を見る。 何もしなくても 0 を返すコマンドは珍しくありません。
AI が自分で付けた「確認済み」ラベルを信じない。 ラベルを付けたのも同じ AI です。
直させた箇所の周辺を、もう一度読む。 修正は退行を連れてきます。件数が減っていても関係ありません。
レンダリング後の見た目を確認する。 原稿では正しく見えます。
「未確認」を未確認のまま残す欄を作る。 埋めさせると、AI は埋めます。

6 は説明が要ります。この本には、最後まで確認しきれなかった項目を 「Human Review」として本文に明示して残す 欄を作りました。約214項目あります。多いと感じるかもしれませんが、空欄を許さない作りにすると、AI は推測で埋めます。 埋まっていない欄が見えている状態のほうが、安全でした。

9. この記録の限界

最後に、この記事の数字をどう扱うべきかを書いておきます。

1つの商品・1人・約2週間の記録です。 統計ではありません。他のテーマや他のモデルで同じ比率になる保証はありません。
レビューしたのも AI です。 302件は「AI が AI を見て出した件数」です。人間が読めば、別の指摘が出ると思います。
302件は重大度別の表の合計です。 指摘の粒度は一定ではありません。1行の追記も、章の作り直しも、同じ「1件」として数えています。
実機で確かめたのは AlmaLinux 8.10 / 9.7 の2台だけです。 RHEL と Rocky Linux では確認していません。

それでも、(1)〜(4) の「確認したつもり」の4件は、テーマにもモデルにも依存しない形をしていると思います。確認の道具が黙っていることを、確認できたことと取り違える。 ここだけは、同じことをやる人にも起きると思います。

この記事の題材にした本について

この記録は、「Linux 障害一次対応スターターパック — RHEL / AlmaLinux / Rocky 8・9 対応」という PDF を作る過程で取ったものです（第2版・A4・327ページ）。障害の連絡を受けてから最初の10分に「どの順で何を見るか」を、症状から引けるようにしたものです。

切り分けフロー20テーマ（SSH / ディスク / CPU・メモリ / systemd / ネットワーク / 権限 / ログ）
現場チェックリスト4本
読み取り専用のコマンドチートシート

本文には、上に書いた「Human Review」の欄がそのまま入っています。確認しきれていない項目が見える形で残っているということなので、そこも含めて判断してください。実機で確認したのは AlmaLinux 8.10 / 9.7 の検証環境での項目のみです。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up