AIは「たたき台」に強く、「事実」に弱い
技術記事を書くとき、生成AIを使う人は増えました。ただ、使い方を誤ると「もっともらしいが間違った記事」が量産されます。この記事では、AIの得意・不得意を踏まえて、下書きはAIに任せ、事実確認は自分でやるという分担で記事を仕上げる手順を整理します。特別なツールは要らず、考え方と手順の問題です。
まず前提として、現在の大規模言語モデル（LLM）には次のような傾向があります。
- 構成案やたたき台を作るのは得意: 見出しの並び、論点の洗い出し、文章の整形は速くて質も安定しています。
- 事実の正確さは保証されない: 事実かどうかを問わず、もっともらしい言葉で文章を組み立ててしまうことがあります。これは一般に「ハルシネーション（hallucination）」と呼ばれます。
- 最新情報や細かいバージョン差に弱い: 学習データのカットオフ以降の更新や、ライブラリの細かい挙動は外しがちです。
つまりAIは「文章を作る作業」を肩代わりしてくれますが、「その内容が本当か」までは担保しません。正確さの責任は、公開ボタンを押す人間にあります。 この役割分担を最初に意識することが、AIを使った執筆の出発点です。逆に言えば、この一点さえ押さえておけば、AIは強力な下書き要員になります。
AIが混入させる典型的な間違い
AIの下書きを検証するとき、何を疑うべきかが分かっていると効率的です。技術記事でよく混入する誤りには、いくつかの型があります。
- 存在しないAPI・メソッド・オプション: 「いかにもありそう」な命名のメソッドや引数を作り出すことがあります。例えば実在するライブラリに、実在しないオプションをそれっぽく付け足す、などです。
- バージョンによって変わる挙動の断定: 「このコマンドはこう動く」と書いていても、特定バージョンでしか成り立たない、あるいはすでに変わっている場合があります。
- 数値・日付・固有名詞の取り違え: リリース年、デフォルト値、ポート番号、設定ファイル名などは、もっともらしい別の値に入れ替わることがあります。
- 出典の捏造: 「公式ドキュメントによると」と書いてあっても、その記述が公式に存在しないことがあります。リンクが実在しない、あるいは無関係なページを指すこともあります。
- 動かないコード: 構文は通っても、importが足りない・引数の順序が違う・戻り値の扱いが誤っている、といった「読むと正しそうだが実行すると落ちる」コードです。
これらは「文章としては自然」なので、流し読みでは見逃します。とくに、自分が詳しくない領域ほど「それっぽさ」に引きずられやすく、危険です。だからこそ、後述する機械的な確認手順が必要になります。
下書きを作らせるときのプロンプトの工夫
検証コストを下げるには、下書きの段階で工夫しておくと効果的です。要点は「AIに事実を作らせず、構造を作らせる」ことです。
- 構成だけ先に頼む: いきなり完成原稿を求めず、「見出し案と各セクションの論点だけ」を出させます。論点の妥当性は人間が判断しやすく、ここで方向性を固められます。
- 自分が確かに知っている事実を渡す: 検証済みの仕様・数値・手順をプロンプトに含め、「これを使って文章にして」と頼みます。AIに知識を尋ねるのではなく、整形を頼む形にすると誤りが減ります。
- 断定させず、確信度を添えさせる: 「不確かな箇所は『要確認』と明記して」と指示すると、検証すべき場所がAI自身の出力に印として残ります。
- コードには前提を書かせる: 「言語・ライブラリ・バージョン・実行環境を冒頭に明記して」と頼むと、後で検証する際の照合先がはっきりします。
下書きはあくまで素材です。完成度を上げすぎると「直すのがもったいない」という心理が働き、検証が甘くなります。7割の完成度の下書きを、人間の確認で10割にするくらいの距離感がちょうど良いです。
一次情報で裏取りする具体的な手順
ここが記事の質を分ける核心です。AIの出力を、AIや検索結果の要約で確認するのではなく、一次情報で確認します。一次情報とは、公式ドキュメント、公式リポジトリ、仕様書、実際の実行結果などです。
検証は次の順序で進めると漏れが出にくくなります。
- 事実を箇条書きで抜き出す: 下書きから「検証すべき主張」をリスト化します。API名、数値、デフォルト値、手順、出典などです。文章のまま確認しようとすると見落とすので、主張単位に分解するのがコツです。
- APIやメソッドは公式リファレンスで存在を確認する: 「ありそう」では通しません。公式ドキュメントや型定義に実在するか、引数・戻り値が合っているかを確認します。
- コードは実際に動かす: これが最も確実です。小さな再現環境を作って実行し、エラーが出ないか、期待する出力かを確かめます。例えばPythonなら、最小の確認はこの程度で十分です。
# 下書きにあった処理が本当に動くかを最小コードで確認する
import json
data = json.loads('{"key": "value"}')
print(data["key"]) # -> value
- バージョン依存の記述は環境を明記する: 「私の環境では〜だった」と書ける範囲に限定し、断定を避けます。確認したバージョンを併記すると、読者にも親切です。
- 出典は必ず自分で開く: AIが挙げたリンクや「公式によると」は、リンク先を開いて該当記述があるか確認します。なければ削るか、正しい出典に差し替えます。
特にコードの実行確認は省略されがちですが、技術記事の信頼性に直結します。動かないコードを載せると、読者の時間を奪い、記事全体の信頼も失います。
例: 「ありそうなAPI」を疑う
たとえば下書きに「json.loads() には strict=False を渡せば末尾カンマを許容できる」と書いてあったとします。文としては自然で、いかにも実在しそうです。ここで止まらず、手元で実際に動かしてみるのが裏取りです。
実行してみると json.loads('{"a":1,}', strict=False) は末尾カンマを許容せずエラーになります（strict は文字列内の制御文字の扱いを変える引数で、末尾カンマとは無関係です）。このように「引数は実在するが、説明している効果が違う」というズレは、文章を読むだけでは絶対に気づけません。実行とリファレンス確認の二本立てで初めて捕まえられます。ここで挙げた値や挙動も、読者は自分の環境とバージョンで再確認してください——「鵜呑みにしない」がこの記事の主旨だからです。
軽い仕組みにして毎回まわす
検証は「気が向いたらやる」ものにすると続きません。記事ごとに使える短いチェックリストにしておくと、抜けが減ります。
- API・メソッド・オプションは公式リファレンスで実在を確認したか
- コードは実際に実行し、記載どおりの出力になったか
- 数値・日付・デフォルト値・バージョンの根拠を確認したか
- 「公式によると」の出典リンクを自分で開いて該当箇所を見たか
- 確証の取れない点に「要確認」を残していないか
このリストを記事の末尾にコメントとして貼り付け、公開前に全部チェックが付くまで出さない、という運用にするだけで質は安定します。仕組みにすれば、書き手の調子や締切に左右されにくくなります。
最後は人間が判断する
機械的な検証を終えても、最後に人間の判断が要る部分が残ります。AIには任せきれない、書き手の責任領域です。
- 構成の妥当性: 論点の順序、過不足、読者にとっての分かりやすさは、AIの提案を鵜呑みにせず自分で決めます。
- 重複や冗長の整理: AIは同じことを言い換えて繰り返す傾向があります。読み返して刈り込みます。
- トーンと正直さ: 煽らない、誇張しない、分からないことを「分かった風」に書かない。これは書き手の姿勢の問題です。
- 検証しきれなかった箇所の扱い: どうしても確証が取れない点は、断定せず「要確認」「環境による可能性がある」と正直に書きます。曖昧さを隠さないことが、長期的な信頼につながります。
- 公開の最終責任: 公開する以上、内容の責任は書き手にあります。AIが書いたから、では通りません。
AIを使うかどうかにかかわらず、技術記事の価値は「読者が安心して再現できること」にあります。AIは下書きの速度を上げてくれますが、その速度を信頼に変えるのは、人間による事実確認と判断です。
まとめ
AIで技術記事を書く流れを整理すると、次のようになります。
- 下書きはAIに: 構成案・論点・文章整形はAIが得意。完成度を上げすぎず素材として使う。
- 事実は疑う: 存在しないAPI、バージョン依存の断定、捏造された出典、動かないコードが典型的な落とし穴。
- 一次情報で裏取り: 主張を箇条書きに分解し、公式ドキュメントで確認し、コードは実際に動かす。
- 仕組みにする: チェックリスト化して毎回まわすと、検証の抜けが減る。
- 最後は人間が判断: 構成・正直さ・公開の責任は書き手が負う。確証のない点は隠さず正直に書く。
「AIに任せる部分」と「人間が責任を持つ部分」を分けて考えるだけで、記事の信頼性は大きく変わります。速く書くことと、正しく書くこと。その両立の鍵は、検証の手順を仕組みとして持っておくことです。