結論から言う。AIが書いた報告書を、そのまま信じてはいけない

いま、中小企業の現場で静かに広がっている光景がある。

システム障害が起きた。復旧した。で、報告書は？——「ChatGPTに書かせました」。

これ自体は悪くない。報告書作成に2時間かかっていたのが15分になる。コスト削減としては正しい。問題は、その報告書の中身を誰も検証していないことだ。

LLM（大規模言語モデル）が生成するテキストには、「静かな捏造」と呼ぶべき特性がある。文法は完璧。構成も論理的。読んだ人間が「よくまとまっている」と感じる。だが中身が間違っている。存在しないエラーコードが記載されている。実際には発生していない事象が原因として書かれている。そして誰も気づかないまま、その報告書が意思決定の根拠になる。

これが「もっともらしく間違っている」問題の本質だ。

数字で見る「捏造」の実態

arXivに掲載された研究（LLM生成GPUカーネルの正確性に関する調査）では、LLMが生成したコードのうち、既存のテストを通過したものの中にも重大なバグが潜んでいたケースが複数報告されている。つまり「テストに通った＝正しい」という前提自体が崩れている。

これをインシデントレポートに置き換えると、こうなる。

• AIが書いた報告書を読んだ上長が「問題ない」と判断する
• 実際には根本原因の記載が間違っている
• 同じ障害が再発する
• 「前回の報告書ではこう書いてあったのに」と現場が混乱する

ある中小のSIerでは、LLMに障害報告書を書かせたところ、実際のログに存在しないプロセス名が原因として記載されていたという事例がある。担当者がたまたまベテランだったから気づいた。新人だったら？　そのまま顧客に提出されていた可能性が高い。

なぜAIは「もっともらしく」間違えるのか

理由はシンプルだ。LLMは「次に来る確率の高い単語」を並べているだけで、事実を検証する機能を持っていない。

障害報告書でいえば、「このタイプの障害では、一般的にこういう原因が多い」というパターンを学習データから引っ張ってくる。だが、目の前で起きた障害の実際のログやメトリクスを見ているわけではない。結果、一般論としては正しいが、今回の事象には当てはまらない記述が混ざる。

さらに厄介なのが、AIエージェント同士の評価バイアスだ。Contagion Networksという研究では、LLMが相互に評価し合う環境において、一つのエージェントのバイアスが他のエージェントに伝播することが示されている。複数のAIツールでクロスチェックすれば安心、という考えは甘い。同じ方向に間違える可能性がある。

AIエージェントはどこで壊れるのか——3つの失敗パターン

AgentArmorというフレームワークでは、AIエージェントの失敗を3つに分類している。中小企業の現場に翻訳するとこうなる。

1. 未定義の仕様エラー
「こういうケースではどう書くか」を指示していないと、AIが勝手に埋める。障害報告書で「影響範囲」の定義を明示していなければ、AIは学習データから「それっぽい」範囲を捏造する。

2. 能力エラー
正しい書き方ができるはずなのに、従わない。プロンプトで「ログに基づいて書け」と指示しても、ログの内容を無視して一般的な記述に逃げるケースがこれにあたる。

3. ハーネスエラー
そもそもAIが必要な情報にアクセスできない。ログファイルを参照させていない、監視ツールのデータを渡していない。入力が足りなければ、出力は想像で埋まる。

中小企業で最も多いのは3番目だ。AIに報告書を書かせるとき、障害の概要だけ口頭で伝えて「あとはよろしく」とやっていないか。それは捏造を依頼しているのと同じだ。

で、どうすればいいのか——月5万円の検証体制

「じゃあAIに報告書を書かせるのはやめよう」は間違った結論だ。人間が2時間かけて書いていた報告書を15分で出せるメリットは大きい。問題は検証の仕組みがないことであり、仕組みを作ればいい。

具体的なコスト感を出す。

構成例：月額5万円以下の検証体制

合計：月額1.5〜2.5万円＋既存人件費内のレビュー時間。

月5万円もかからない。だが、この仕組みがあるかないかで、顧客への誤報告、再発障害の見逃し、信用毀損といったリスクの大きさはまるで違う。

中小企業だからこそ、この問題は致命的になる

大企業なら、SREチームがいて、ポストモーテムのプロセスが確立されていて、報告書のレビュー体制もある。AIが多少間違えても、どこかで誰かが気づく。

中小企業は違う。報告書を書く人＝レビューする人＝提出する人、というケースが珍しくない。チェックの目が少ないからこそ、AIの「静かな捏造」がそのまま通ってしまう。

逆に言えば、検証の仕組みさえ入れれば、少人数でも高品質な報告書を量産できる。これは大企業が大人数でやっていることを、AIと仕組みで代替できるということだ。中小企業がAIを使う本当の意味はここにある。

やるべきことは3つ

1. AIに渡す入力を増やす
障害の概要だけでなく、実際のログ、監視ツールのスクリーンショット、タイムライン。入力の質が出力の質を決める。

2. 出力のファクトチェックを仕組み化する
チェックリストを作り、報告書の記載内容を実データと突合する。これを属人化させず、誰がやっても同じ結果になるようにする。

3. 「AIが書いた」ことを前提にレビューする
人間が書いた報告書のレビューと、AIが書いた報告書のレビューは、見るべきポイントが違う。AIは文法や構成は間違えない。間違えるのは事実だ。事実だけを集中的にチェックすればいい。

このままでいいのか、という問い

AIに報告書を書かせること自体は止まらない。むしろ加速する。問題は、「AIが書いたものは正しい」という無意識の信頼が、検証なしに定着してしまうことだ。

月2万円の検証体制を入れるか、入れないか。その差が、半年後に顧客からの信頼を失うか、「あの会社の報告書は正確だ」と評価されるかを分ける。

AIのコストが下がった先に起きるのは、「誰でもそれっぽい報告書が書ける世界」だ。そのとき、報告書の正確さを担保できる会社が選ばれる。これは中小企業にとって、大企業と差別化できる数少ないポイントになる。

まず、今日やること。自社でAIに書かせた直近の報告書を1つ取り出して、記載されている事実をログと突合してみてほしい。何か1つは間違いが見つかるはずだ。そこが出発点になる。

—