QiitaをAIで書く｜LGTMされる作法

AIで書いた記事が嫌われる理由を先に押さえる

「Qiita AI 書き方」で調べる人の多くは、AIで楽をしたいわけではなく「AIを使っても恥ずかしくない記事を出したい」と思っています。Qiitaは開発者の実用情報が集まる場で、読者は検証されていない情報と中身の薄い量産記事に敏感です。AI自体は禁止されていませんが、嫌われるのは「AIが書いた」ことではなく「人間が検証していない」ことです。ここを外さなければ、AIは強力な下書き相棒になります。

良い使い方：AIは「壁打ち」と「下書き」に使う

AIが得意なのは、あなたが頭の中に持っている経験を整理し、抜けを埋めることです。ゼロから事実を作らせるのではなく、自分の実体験を素材として渡すのがコツです。

構成（章立て）を先に決める

本文より先に骨格を作ると、内容がぶれません。Qiitaで読まれやすい技術記事の型はおおむね次の流れです。

• はじめに（誰向け・何が分かるか）
• 環境・前提（バージョンを明記）
• つまずいた課題
• 実装・解決
• 動作確認
• ハマりどころ
• まとめ・参考リンク

AIへの依頼例：「Reactの状態管理でuseEffectの無限ループにハマった体験談を書きたい。上の章立てに沿って見出し案を出して」。見出しだけ先にもらい、各節の中身は自分の言葉で書くと、コピペ感が消えます。

タイトルとタグを整える

Qiitaでストックされやすいタイトルは、内容が一目で分かるものです。「〜入門」「〜でハマった話と解決法」「〜の使い方まとめ」のように、対象と得られるものを具体的にします。

• 悪い例：Reactの話
• 良い例：useEffectの無限ループにハマった原因と、依存配列の正しい書き方

タグは記事内容と一致するものだけを5個以内に絞ります。関係ないタグを盛るのは逆効果です。

読みやすさを後から整える

書き終えた本文をAIに渡し、「冗長な言い回しを削って、コードブロックと箇条書きを使った方が良い箇所を指摘して」と頼むと、推敲が速くなります。ここでも判断するのは自分です。

悪い使い方：そのまま貼ると確実に信頼を失う

避けたいのは次のパターンです。どれもQiitaで反応が冷たくなる典型です。

• 未検証のコードをそのまま掲載：AIは動かないコードや古いAPIを自信満々に出します。必ず手元で実行し、バージョンを書く。
• 事実の捏造：存在しない関数名やオプションをAIが作ることがあります。一次情報（公式ドキュメント）で裏取りする。
• 同じテーマの薄い記事を量産：SEO目的の水増しはコミュニティに見抜かれます。
• 翻訳調・定型句の放置：「本記事では〜について解説します」を全節で繰り返すと、読み飛ばされます。

最低限のセルフチェックとして、公開前にこの3点を確認してください。

1. 載せたコードを実際に動かしたか
2. バージョン・環境を明記したか
3. AIが書いた段落を自分の言葉で確認・修正したか

執筆を補助するツールという選択肢

章立てやタイトル案、タグの整理を毎回プロンプトに打ち込むのが面倒なら、執筆画面に補助機能を足す方法もあります。筆者が個人で開発した非公式のChrome拡張「Qiita-AI+」は、qiita.comの編集画面にサイドバーを追加し、タイトル候補とLGTM予測・冒頭文3案・章立て・タグ最適化・読みやすさ評価を無料枠（毎日・回数上限あり）で使えます。設計はBYOK（自分のClaude/OpenAIのAPIキーを使う方式）で、本文やキーは運営サーバーに送らずローカル保存し、AI利用料は自分のAPI契約に直課金されます。無制限利用などのProは月¥980（ExtensionPay／Stripe決済）です。あくまで下書きと推敲を速くする道具で、コードの検証と最終判断は人間が行う前提は変わりません。

まとめ：AIは加速装置、責任は書き手

AIを使うこと自体は問題になりません。問題になるのは検証しないことです。構成と推敲はAIに任せ、事実とコードは自分で確かめる。この一線さえ守れば、AIはQiitaで読まれる記事づくりの良い味方になります。