AIエージェントで技術書が書けなかった理由 — 語彙は真似できても骨格は真似できない
AIエージェントで技術書が書けなかった理由 — 語彙は真似できても骨格は真似できない
コーディングをAIに委任する方法を扱った本を、著者はなぜAIに委任して書けなかったのか。失敗したのはモデルの能力なのか、それとも検証者なき作業の本質的限界なのか。
導入
7月25日にQiitaに投稿された一本の記事が、日本のエンジニアコミュニティで静かに話題を集めた。タイトルは挑発的だ — 「AIエージェントがあれば技術書なんてすぐ書けるでしょ、と思ったが無理だった」。著者のwatany氏は2026年5月にエージェンティックコーディングを扱った技術書を出版したエンジニアで、いわばAIに開発を委任する方法論を本として書いた人物である。その著者が、執筆そのものはAIに委任できなかったという逆説を、詳細な失敗記録とともに公開した。
タイミングが絶妙である。2026年上半期は、エージェンティックコーディングが「可能性」から「デフォルト」へと移行した時期だ。コードベース全体をエージェントに任せる事例がニュースでなくなり、コミュニティの関心は自然と「次は何を委任できるか」に移った。技術書一冊はその次の候補として完璧に見えた — 成果物はテキストであり、著者はドメイン知識をコンテキストとして注入でき、分量はコードベースより小さい。それなのに失敗した。なぜか。
この記事が興味深いのは結論(「AIではまだ本が書けない」)ではなく、失敗の解剖図である。著者はどこまでできてどこからできないのかを階層に分けて記録し、その境界線はAI長文生成の現在地を正確に示している。折しも同じ週のHacker Newsでは「コーディングは解決されたはずなのに、なぜソフトウェアは悪化し続けるのか」というエッセイが887ポイントを集め、同種の問いをコード側から投げかけていた。生成量と品質の乖離 — 2026年夏のAI実務言説に共通するテーマだ。
何を試み、何が失敗したのか
著者の試みは体系的だった。単に「本を書いて」と投げたのではなく、エージェンティックコーディングの実践者らしくパイプラインを構築した。
第一に、AI臭除去の自動化。AI生成文特有のパターン — 繰り返される語彙、予測可能な構造、乱発されるダッシュ、常套句 — を捕まえるため、humanizer 系のツールや textlint-rule-ai-writing のようなリンターをパイプラインに組み込んだ。結果は失敗だった。著者の表現を借りれば、すべてのAIパターンを除去した後に残ったのは自然な文章ではなく別の種類の偏りだった。特徴を削ぎ落とした文章は人間らしくなるのではなく、単調になった。
この最初の失敗は噛みしめる価値がある。「AI臭除去」は今やひとつのツール生態系を成している — 特定の常套句を検出するリンタールール、語彙分布を人間の文章に近づける後処理器、ダッシュや並列構文の頻度を下げるリライター。しかしこれらはすべて表層統計を操作しているに過ぎない。AI文章がAIらしく読める根本原因が表層パターンではなく論旨展開の画一性にあるなら、表層をいくら洗浄しても「別の種類の偏り」が残るという著者の観察は必然である。検出器と洗浄器の軍拡競争は、文章の自然さではなく不自然さの種類を変えるだけだ。
第二に、フィードフォワードとフィードバックの二重ハーネス。自身が公開した200本以上の記事をスタイル参照として注入し文体を模倣させ(フィードフォワード)、AIレビュアーが誤り・明瞭性・一貫性を検査するループ(フィードバック)を回した。こちらは部分的成功である。文体模倣は成功した。しかし著者の診断では「文体は真似できたが品質はついてこなかった」。
この落差を著者は三つの層に整理する。技術文章には語彙の層、リズムの層、構造(骨格)の層があるというのだ。語彙はAIがうまく処理した。リズムは半分 — 音読すると引っかかる不自然さが残り、これは自動化ツールではなく人間の音読でしか捕まらなかった。そして構造、すなわち一冊の本を貫く論理の骨格は「模倣がほぼ不可能」だった。
ここから実務的に有用なディテールが出てくる。効果があったのは (1) 音読 — 自動ツールが見逃す問題を音が暴く、(2) 事前に人間が組んだ目次構造の上でAIと交代で書く協働反復 — 骨格の統制権を人間が握る、(3) プロンプトエンジニアリングより上位モデルの選択 — 著者は小技よりモデルの乗り換えが効いたと明記している、(4) フィードバックの言語学的細分化 — 「もっと自然に」のような曖昧な指示ではなく、コロケーションや呼応のような具体的な言語学用語で指摘したときにAIの修正品質が上がった、というものだ。
なぜコードはできて本はできないのか
この失敗記録を構造的に読むと、核心の変数はモデルの能力ではなく検証者(verifier)の存在である。
エージェンティックコーディングが機能する理由は、コードという成果物に機械的検証者が付いているからだ。コンパイラが文法を、型チェッカーが整合性を、テストが動作を検証する。AIが生成したコードが間違っていれば、間違っているというシグナルが即座に、機械的に、客観的に返ってくる。エージェントループとは本質的に、この検証シグナルを燃料に回る機械である。
散文にはこれがない。textlint は文法と表記規則を捕まえるだけで、「この章の論証が前章の前提と呼応しているか」を検証できない。著者が三層のうち語彙層でだけ完全な成功を見たのは偶然ではない — 語彙はリンターで検証可能な唯一の層だ。リズムには人間の音読という半自動の検証者が必要で、構造には検証者がそもそも存在しない。検証者の不在はすなわちエージェントループの不在であり、ループがないところでAIはワンショット生成の品質上限に閉じ込められる。
もうひとつの軸は文脈の時間的射程である。関数ひとつの整合性は数百トークンの局所文脈で判断できる。しかし本の骨格は10万トークン先の伏線と呼応しなければならない。コンテキストウィンドウがいくら長くても、「入れられる」と「一貫して活用する」は別物だ。著者が観察した「構造模倣の不可能性」は、長距離一貫性(long-range coherence)という、ベンチマークがあまり測らない能力の空白を実戦で確認したものである。
翻訳産業の前例も参考になる。機械翻訳が実用水準に達した後、翻訳市場は「機械の下訳 + 人間のポストエディット(MTPE)」に再編されたが、このとき品質が維持された領域と崩壊した領域の境界が、まさに検証者の有無だった。用語集とスタイルガイドで検証可能な技術マニュアル翻訳はMTPEに順調に移行したが、文学翻訳は下訳すら使いにくいという評価が維持されている。watany氏の実験は、技術書執筆がこのスペクトラム上で思いのほか文学側に近いことを示したことになる — コード例と用語はマニュアル的だが、一冊を貫く論証は文学的構造物なのだ。
同じ週にHNで話題になった「コーディングは解決されたのにソフトウェアは悪化する」というエッセイと重ねて読むと絵が完成する。あの記事の論旨 — 要旨を写せば、個々のコード片の生産は速くなったが、システム全体の整合性はむしろ悪化しているというもの — は、watany氏の三層モデルと正確に同型である。コードでも関数単位(語彙層)はAIが制覇したが、アーキテクチャ(構造層)の検証者は依然として人間のレビューだけだ。本が先にぶつかった壁に、ソフトウェアもぶつかりつつある。
日本コミュニティ特有の文脈も押さえておく価値がある。日本の技術書市場は技術書典のような同人即売会と商業出版の間のグレーゾーンが厚く、個人エンジニアが一冊丸ごと本を書く文化が際立って発達している。「AIで技術書が書けるか」がこのコミュニティで切実な問いである理由であり、この密度の失敗記録がQiitaに上がってくる背景でもある。
実務者への示唆
この記録から引き出せる実務原則は三つある。
第一に、委任の単位は「検証者がいる範囲」で切る。 文書作業でAIに丸ごと任せてよいのは検証可能な層 — 用語統一、表記規則、要約、翻訳の下訳 — だ。目次設計と章間の論理配線は人間が握り、AIはその骨格の上の肉付けに役割を限定する。watany氏の「事前目次 + 交代執筆」がまさにこのパターンである。
第二に、品質フィードバックは具体的な語彙で与える。 「もっと自然に」はプロンプトではなくノイズだ。コロケーション、呼応、文長の分散のように操作可能な指標で指摘したときにだけ修正ループは収束する。これはコードレビューで「きれいにして」ではなく具体的な命名と分離基準を要求するのと同じ原理だ。
第二の補足 — 検証ループの非対称性も設計に織り込む。 コードではテストが失敗すればエージェントが自ら直すループが回るが、散文では人間の音読・通読がループのボトルネックになる。人間検証がボトルネックだということは、バッチサイズを小さくすべきだということだ。章単位でまとめて検討すると、構造の問題を発見したときの廃棄コストが大きい。節単位で生成と検討を交互に回すwatany式の運用が損失を最小化する — アジャイルがウォーターフォールに勝ったのと同じ理由である。
第三に、ツールよりモデル、モデルより構造。 著者はプロンプトの小技より上位モデルの選択が効いたと書いたが、同時に最上位モデルでも構造層は突破できなかった。リソース配分の優先順位は明確だ — 構造を人間が統制するワークフロー設計が先で、モデルのアップグレードが次、文章推敲ツールは最後である。
出版経済の観点から見れば、この失敗談はむしろ安堵すべき知らせかもしれない。生成コストがゼロに収束する中、技術書市場にもAI量産書籍が流入しており、Amazonの電子書籍セルフパブリッシングには表層だけもっともらしい本が氾濫しているという指摘が繰り返されてきた。構造層が自動化の最後の砦として残っているということは、良い本の希少性 — そしてそれを書ける著者の希少性 — が当面維持されるという意味だ。読者にとって「この本は人間が骨格を組んだか」が新しい品質シグナルになる時代が来ている。
展望すれば、この壁が永遠である保証はない。長文成果物に対する検証者 — 論証グラフの抽出、章間一貫性の検査のような — が作られた瞬間、書籍執筆もエージェントループの射程に入る。実際、数学の証明分野ではLeanのような形式検証器がその役割を果たし、AI証明自動化が急進展した。散文のLeanが登場するのかが次の観戦ポイントである。
結論
リード質問に戻れば、失敗したのはモデルではなく、検証者なき作業にエージェントパターンを移植しようとした設計だった。語彙・リズム・構造という三層のうちAIが制覇したのは検証者が存在する層だけであり、この境界線はコードでも散文でも同じように作動する。「AIで本が書けるか」という問いは、だから「あなたの作業にはどんな検証者がいるか」という問いに置き換えられる。
そしてこの置き換えは執筆の外にも拡張される。設計文書、アーキテクチャ決定記録、障害報告書 — エンジニアが書くあらゆる長文には同じ三層があり、同じ検証者の空白がある。AIに草稿を任せてぎこちない文だけ直す今日の慣行は、語彙層だけ検収して構造層を放置しているのかもしれない。
著者の最後の洞察が残る — 何を書くべきかの最適化より、何を書くべきでないかについての人間の直観の方が価値があった、ということ。生成がタダになった時代に希少になるのは生産能力ではなく、削除の判断力である。あなたの次の文書作業で、AIに任せる層と自分で握る層の境界はどこにあるだろうか。
出典: