AIに作らせた資料をそのまま使うと危ない理由！現役SEが見ている確認ポイント

AIを使うと、議事録、設計書、手順書、テスト観点などの資料作成はかなり楽になります。

ただし、現場でそのまま使えるかというと別問題です。私自身、SEとして案件に関わる中で、AIが作った文章は「それっぽくまとまっているのに、実務で使うには危ない」と感じる場面が何度もあります。

特に危ないのは、文章がきれいに見えることで、確認すべき論点が埋もれてしまうことです。資料の見た目が整っていると、レビューする側も「だいたい合っていそう」と流してしまいやすくなります。

この記事では、AIに作らせた資料を現場で使う前に、私がどこを見ているかを実務目線で整理します。

AIの資料作成で一番危ないのは「間違い」より「抜け漏れ」

AIの回答を見ると、明らかに間違っている部分には気づきやすいです。用語が違う、前提が違う、画面名が違う。このような間違いは、読めば比較的見つけられます。

一方で、実務で本当に危ないのは「書かれていないこと」です。

たとえば、要件定義のメモからAIに仕様書のたたき台を作らせたとします。文章としては自然でも、次のような論点が抜けることがあります。

• 誰が最終承認するのか
• 例外時の処理をどうするのか
• 既存データとの整合性をどう保つのか
• 運用で誰が確認するのか
• 変更時に影響を受ける画面やバッチはどこか

これらは文章のうまさとは関係ありません。むしろ、AIが作った資料は読みやすい分、抜け漏れに気づきにくくなります。

要件定義でAIを使う場合の境界線については、以前の記事「要件定義でAIに任せてよいこと・任せてはいけないこと」でも整理しています。

現場で私が最初に見るのは「責任の所在」

AIが作った資料を確認するとき、私が最初に見るのは文章のきれいさではありません。まず「誰が判断する内容なのか」を見ます。

実務では、仕様が正しいかどうかだけではなく、その仕様を誰が決めたのかが重要です。開発側が勝手に決めてよい内容なのか、業務部門の確認が必要なのか、運用担当まで巻き込むべきなのか。この切り分けが曖昧な資料は、後で揉めやすくなります。

たとえば、ECサイトで「注文キャンセルは購入後30分以内なら可能」と書かれていたとします。一見すると仕様のように見えますが、実際には次の確認が必要です。

• キャンセル可能時間は業務判断として妥当か
• 決済サービス側で取り消し可能か
• 在庫引当後のキャンセルをどう扱うか
• 出荷準備に入った注文は対象外にするか
• ユーザーへの表示文言は誰が確認するか

AIはここまで自動で判断できません。過去の一般的な情報からそれらしい仕様を書くことはできますが、その案件で本当に通る仕様かどうかは別です。

AI生成資料でよくある失敗例

ここでは、実務で起きやすい失敗例を3つ挙げます。

失敗例1：きれいな議事録なのに決定事項が曖昧

AIで議事録を整えると、発言内容が読みやすくまとまります。しかし、会議で本当に必要なのは「何が決まったか」「誰が次に動くか」です。

文章として自然でも、次のような状態だと実務では使いにくいです。

• 検討する、確認する、調整する、という表現ばかり残っている
• 担当者名や期限がない
• 決定事項と未決事項が混ざっている
• 次回までに必要な確認が分かれていない

この状態で関係者に共有すると、全員が読んだのに誰も動かない、ということが起きます。

失敗例2：設計書が一般論でまとまっている

AIに設計書のたたき台を作らせると、一般的な構成はかなり整います。画面概要、入力項目、処理概要、エラー処理など、項目だけ見ると十分に見えます。

ただし、現場で必要なのは「このシステムではどうするか」です。

たとえば、エラー処理に「エラー時はメッセージを表示する」と書かれているだけでは不十分です。どのエラーをユーザーに見せるのか、ログには何を残すのか、リトライできるのか、運用担当が追跡できるのかまで考える必要があります。

設計書作成でAIを使う具体的な流れは「生成AIで設計書を作る方法」でも解説しています。

失敗例3：手順書が正常系だけで終わっている

手順書はAIと相性がよい分野です。操作手順を整理したり、箇条書きにしたり、読みやすく整える作業には向いています。

しかし、実務で使う手順書には正常系だけでは足りません。

• 途中でエラーになった場合
• 権限が足りない場合
• 対象データが存在しない場合
• 処理後に確認すべきログや画面
• 戻し作業が必要になった場合

ここが抜けていると、作業者は手順書どおりに進められなくなります。結果として、属人的に詳しい人へ確認が集中します。

AIでドキュメント作成を効率化する基本的な考え方は「AIでドキュメント作成を効率化する方法」でもまとめています。

AI生成資料を見るときの確認ポイント

私がAIで作った資料を見るときは、次の観点で確認しています。

この表の観点で見ると、AIが作った文章のどこに人の判断が必要なのかが見えやすくなります。

AIに任せてよいこと・人が見るべきこと

AIを使うこと自体は悪くありません。むしろ、たたき台作成や文章整理には積極的に使うべきです。

ただし、任せる範囲を間違えると、手戻りが増えます。

AIに任せてよいこと

• 議事メモの整理
• 設計書の構成案作成
• 手順書の文章整形
• レビュー観点のたたき台作成
• 抜け漏れチェック用の質問作成

人が必ず見るべきこと

• その案件固有の業務ルール
• 顧客や利用部門の判断が必要な項目
• 障害時や例外時の対応
• 既存システムとの整合性
• 責任範囲と承認者

AIは「整理する」のは得意ですが、「その現場で責任を持って判断する」ことはできません。この違いを分けて考えることが重要です。

レビュー時はAIに再チェックさせるのも有効

AIに作らせた資料を、人が確認した後でもう一度AIにチェックさせる使い方は有効です。

たとえば、次のように依頼します。

以下の設計書について、実務で抜け漏れになりやすい観点を指摘してください。特に例外処理、責任範囲、運用時の確認作業、既存機能への影響を重点的に見てください。

この使い方であれば、AIはレビュー補助として役立ちます。ただし、最終判断は人が行う前提です。

コードレビューでも同じで、AIの指摘をそのまま採用するのではなく、現場の設計方針や保守性に合っているかを見る必要があります。詳しくは「AIコードレビューの使い方と注意点」も参考になります。

まとめ：AI資料は「完成品」ではなく「レビュー対象」として扱う

AIを使えば、資料作成の初速は上がります。白紙から書き始めるよりも、たたき台があるだけでかなり楽になります。

しかし、AIが作った資料をそのまま完成品として扱うのは危険です。特に実務では、文章の自然さよりも、責任範囲、例外処理、運用、影響範囲が重要になります。

私が現場で意識しているのは、AIを「作業者」として使い、人が「判断者」として確認することです。

AIに任せる部分と人が見る部分を分けられるようになると、資料作成はかなり効率化できます。それだけでなく、レビューの質も上げやすくなります。

これからAIを実務で使うなら、まずは完成度の高い文章を作ることよりも、抜け漏れを見つけるための確認観点を持つことが大切です。