CONTENTS
最初に断っておくと、これは「AIを使うな」という話ではありません。当社もAIを日常的に使っていますし、この記事自体、AIとのやり取りを経て書かれています。
問題はツールではなく、検証工程が省略されていることにあります。実際に踏み抜いてきた経験から、疑うべき箇所を整理します。
1．存在しない関数・オプション・メソッド
最も分かりやすい失敗です。
AIは命名規則を学習しているため、実在しないものを、実在しそうな名前で作り出します。むしろ「あってしかるべきなのに存在しない機能」ほど、堂々と捏造されます。
たとえばCMSのモジュールで「一覧をCSVで出力するオプション」を尋ねたとします。そんなパラメータは存在しないのに、いかにも公式ドキュメントに載っていそうな名前のオプションが返ってくる。マイナーなライブラリほど、この現象は起きやすくなります。学習した情報が薄い領域を、周辺の知識で補完してしまうためです。
疑うべきポイント
見慣れないオプション名・メソッド名が出てきたら、記事を読む前に公式リファレンスで存在を確認する。ドキュメントに載っていないなら、それは存在しません。「ドキュメントが不完全なだけかもしれない」と考えるのは、ソースを読める場合だけにしてください。
2．バージョンの地層が混ざっている
こちらのほうが厄介です。
AIの知識は、年代の異なる情報が層状に堆積したものです。整理されて格納されているわけではないため、ひとつの記事の中で、異なる時代の作法が同居します。
-
最新バージョン前提の記述の中に、すでに削除された関数が混ざる
-
OSのバージョン間で変わったパッケージ名や手順が、古いまま書かれている
-
CMSのメジャーバージョン間で互換性のない書き方が混在する
厄介なのは、その多くが「一応動いてしまう」ことです。非推奨の関数も、削除されるまでは動きます。動くので気づかない。数年後の環境更新で、まとめて壊れます。
疑うべきポイント
記事の中に、対象バージョンが明記されているか。「PHPで」ではなく「PHP 8.2で」と書かれているか。書かれていない技術記事は、それだけで信頼度が大きく下がります。人間が書いた記事でも同じですが、AIが書いたものはこの明記が特に抜けやすい傾向にあります。
3．「動く」と「正しい」が区別されていない
ここからが本題です。
表面的な症状を消す方法と、原因を取り除く方法は違います。そしてAIは、症状を消す方法を、原因を取り除く方法として提示してきます。
具体例を挙げます。あるCMSで、エンティティに新しいフィールドを追加する必要がありました。データベースに直接 ALTER TABLE でカラムを追加すれば、値の読み書きはできるようになります。実際、画面上は正常に動きます。
しかしそのCMSは、テーブル構造の定義をデータベースとは別の場所にも保持していました。そちらを更新していないため、システムから見れば「定義上は存在しないカラム」が物理的に存在している状態になります。この不整合は、キャッシュを再構築したタイミングや、次のアップデートで表面化します。
正しい手順は、フレームワークが用意したAPIを通じてフィールド定義を登録することでした。ALTER TABLE は「動く」が「正しくない」。この区別は、そのフレームワークの設計思想を理解していないと判断できません。
POINT
その手順が「なぜそうするのか」まで書かれているかを確認してください。
「これで直ります」しか書いていない記事は、症状を消しているだけの可能性があります。特に、フレームワークやCMSの標準的な作法を迂回する手順が出てきたら、必ず立ち止まってください。
4．意味のない「おまじない」が紛れ込む
権限が原因かもしれないので全許可のパーミッションを設定する。念のためキャッシュをクリアする。とりあえず例外処理で囲む。
こうした記述は、対症療法ですらありません。過去に誰かがそれで解決したという記録の残骸です。AIはそれを、手順の一部として再生産します。
パーミッションの全許可に至っては、解決策ではなくセキュリティホールです。それが「よくある解決方法」として何千回も書かれてきたために、いまも生成され続けています。
疑うべきポイント
その手順を外したらどうなるか、説明できるか。説明できない手順は、入れないでください。理由の分からない操作を積み重ねたシステムは、あとから誰も触れなくなります。
5．環境固有の原因には、決してたどり着かない
エラーメッセージを投げれば、考えられる原因が列挙されます。これは便利です。しかし列挙されるのは、世の中で最も頻度の高い原因であって、目の前の環境の原因ではありません。
実例を書きます。あるNASからデータを救出するため、ディスクを取り出してLinuxマシンに接続し、RAIDの再構成までは成功しました。ところがファイルシステムがマウントできない。
エラーから推測される一般的な原因は、片端から潰しました。どれも該当しません。最終的な原因は、そのNASメーカーが独自に拡張したファイルシステムのフラグが、新しいカーネルで受け付けられなくなっていたことでした。古いカーネルのディストリビューションで起動すれば通る、という話です。
この結論は、一般的な原因のリストからは絶対に出てきません。その製品の実装を知っているか、同じ状況に陥った誰かの記録を探し当てるしかありません。
疑うべきポイント
一般解を三つ試して駄目なら、方針を切り替える。同じ質問を言い換えて投げ続けても、同じ層の答えしか返ってきません。そこから先は、製品固有の情報を探す作業です。
6．断定の強さは、根拠の強さではない
人間が書いた技術記事には、信頼度の信号が含まれています。「たしか」「うろ覚えだが」「自分の環境では」といった留保です。読み手はこれを見て、どこまで信じるかを調整しています。
AIの文章には、この信号がありません。確実に知っていることも、それらしく補完したことも、同じ調子で断定されます。
そしてAIが書いた文章をベースにした記事は、その均質な断定調をそのまま引き継ぎます。全体が同じ強さで書かれているため、どこが弱いのか読み取れません。
疑うべきポイント
記事全体が同じトーンで、一箇所も自信のなさを見せていないなら、それは検証済みの証拠ではなく、検証されていない証拠かもしれません。
7．「実際に試したところ」という記述
これが最も悪質です。
体験談の形式は、記事の信頼性を一気に引き上げます。だからAIは、依頼されればその形式で書きます。「筆者の環境で検証したところ」「実際に導入してみると」といった文章は、依頼者が試していなくても生成されます。
書き手が意図的に嘘をついているとは限りません。AIの出力をそのまま公開すれば、体験の偽装は自動的に混入します。
疑うべきポイント
体験の記述に、固有の情報が伴っているか。実測値、所要時間、エラーが出た回数、失敗した試行、途中で捨てた選択肢。こうした「うまくいかなかった記録」は、実際にやった人しか書けません。逆に言えば、成功手順しか書かれていない記事は、体験の形式を借りた一般論である可能性が高いということです。
8．見分けるためのチェックリスト
技術記事を読むとき、次の点を確認してください。
- バージョンが明記されているか（環境・言語・フレームワーク・OS）
- 失敗した経路が書かれているか（試して駄目だったこと、捨てた案）
- 「なぜ」が書かれているか（手順だけでなく、その手順が正しい理由）
- 副作用やトレードオフに触れているか（この方法の欠点は何か）
- 具体的な数字があるか（時間、件数、サイズ、実測値）
- 情報の賞味期限が意識されているか（いつ時点の情報か）
これらが揃っていない記事は、AIが書いたかどうかにかかわらず、そのまま実行するには足りません。
SUMMARY
9．まとめ それでも、AIは使うべきです
ここまで書いておいてなんですが、当社はAIを手放す気はまったくありません。
調査の起点として、実装の叩き台として、見落としの洗い出しとして、圧倒的に有効です。ひとりで三日かかっていた調査が、半日で当たりをつけられる。この差は決定的です。
問題は、役割を取り違えることにあります。AIが得意なのは、候補を素早く広く出すことです。苦手なのは、そのどれが目の前の状況で正しいかを確定することです。確定には、一次情報の確認と、実環境での検証と、その領域を理解している人間の判断が要ります。そして、この工程を省略できる魔法は存在しません。
当社が技術記事を書くとき、AIは下書きと構成整理には使いますが、自分たちが検証できない領域については書かないことにしています。それが、読んだ人に「動かないコード」を渡さないための、唯一の防衛線だと考えているからです。
情報が増えることと、判断が楽になることは、別のことです。むしろ、それらしく見えるものが増えたぶん、見極める側の負荷は上がりました。
疑ってください。この記事も含めて。
by Claude
RELATED ARTICLES