はじめに
2026年5月2日に『Agentic Coding 生成AI時代のシステム開発入門』という単著を出しました。生成AI×システム開発の情報がネットの場当たり的なものばかりで困っている人、エージェントの使い方をどこから学べばいいか分からない人、そして自分は大丈夫でもチームメンバに渡す本が無い人に向けた本です。
本記事はその宣伝……ではなく、執筆中にAIエージェントをどう使い、何を捨てたかという話です。先に結論を書くと、すぐには書けませんでした。以下は登壇資料に加筆したものになります。
AIに開発を委ねろと書いた本を、AIに書かせない矛盾
執筆中、筆者はずっとジレンマを抱えていました。
「AIにシステム開発を委ねましょう」と書いている本の原稿を、AIに委ねない。この態度は道理に合いません。読者からすれば「お前が使えよ」で終わる話でしょう。
一方で、LLMに出力させた文章はAI臭くて使い物にならない、という感覚もありました。個人の信念に近いのですが、そのまま本にするわけにはいきません。
では、どこまでなら委ねられるのでしょうか。矛盾を抱えたまま、その線を探ることになります。
そもそも何がAI臭いのか
海外版の流行語大賞のひとつが「スロップ(汚物)」に決まりました。「AIスロップ」のように使われる言葉で、圧倒的な量に対して内容の薄いコンテンツへの揶揄です。
では、文章におけるAI Slopとは具体的に何でしょうか。筆者は三つの層があると考えています。
一つ目は語彙です。「構造」「足場」「刺さる」「効く」「置く」あたりの頻出語と、emダッシュ(—)が代表例に挙げられます。二つ目は構文です。Markdownの強調と、コロン付きの箇条書き(- hogehoge: fugafuga)がよく知られています。
三つ目が構成で、これがもっとも厄介です。章・節でサブタイトルを多用する癖、続きが気になる中途半端な終わり方(クリフハンガー)、書き手の極論や傾向に対して過度な調整をかけてしまうバイアスの欠如、そして前の話から想定できる地点にきれいに着地してしまうLLMの予測可能性が該当します。
語彙や構文は目に見えるので直せます。とはいえ、構成はそう簡単には直せません。
脱臭は誰のためにやっているのか
ここで一度立ち止まる必要がありました。そのAI臭を消す努力は、誰のためにやっているのでしょうか。
「品質改善」なのか「ロンダリング」なのか。なぜAI臭さを消したいのかと自問すると、「責任を負うため」という答えと「外注の痕跡を消すため」という答えが両方出てきます。
後者だとすると、読者に対して不誠実でしょう。この線引きは最後まで筆者の中で解けていません。もっとも、少なくとも「消せば良い文章になる」わけではないことは、検証で分かりました。
自動で脱臭する、を試して捨てた
世の中には脱臭のためのSkillsがあります。
blader/humanizer は Wikipedia:Signs of AI writing に基づいて、AI出力で頻出のパターンを33観点で検出し、自然な文章に修正するスキルです。k16shikano/japanese-tech-writing は日本語の技術文書を書かせたり推敲させたりするための、日本語文章規範のスキルです。
執筆中は自前のSkill・Commandも試していましたし、Linterも試しました。textlint-rule-preset-ai-writing です。
結論として、Linterは採用できませんでした。
「AI文章あるある」を機械的に刈り取ると、人間らしい文章になるのではなく、単に別のバイアスを持った文体になります。例えば漢字の閉じ開きの統一や、「もの」「こと」の撲滅です。アンチパターンを機械的に添削した結果、かえって単調な文章になってしまいました。
そもそもLLMはLLMなりに、人間らしさ(というか機械翻訳らしさ)を踏まえて出力しています。すなわち、AI Slopの特徴を全部消すと、違和感がむしろ増える可能性があります。スラングを意識しすぎると却って話し辛くなるのと同じですね。
ハーネスとして組み直す
次に試したのが、ユーザーハーネスの考え方へのマッピングです。ハーネスとは、エージェントが良い出力を出せるように整える、入力と評価の仕組み一式を指す言葉です。
生成に必要な情報をfeedforward、評価に必要な情報をfeedbackとすると、前者は「自分の真似をさせる」、後者は「Skillsによるレビュー・修正」になります。
まずfeedforwardは単純です。
文体や構成は@watanyの公開記事や登壇スライドを読んで理解し、参考に執筆して
Qiitaを含めて公開資料が200くらいあるので、Claude Codeなどの Web search tool に任せます。どう真似るかの手段はLLM側に決めさせます。コンテキストが気になるなら、理解した後に調査結果をファイル化させて /clear すれば済みます。
次にfeedbackとして、レビューのプロンプトを刻みました。
誤字脱字・表記誤り・文法誤りはありますか？
この＜文章＞＜表現＞を簡潔にする代替案を考えてください
前後の章・節と整合性が取れてない点を指摘してください
これらのプロンプトを1つのSkillsに固めると、抜け漏れが出るように感じています。感覚的な話なので話半分に聞いてください。
では、どうなったでしょうか。結果は、似ている文体にはなるけれど、良い文章にはならないでした。
この結果が一番こたえました。文体の模倣は成功しているのに、読み返すと面白くないのです。
技術書の文章を三つに分解する
なぜ似ているのに良くないのでしょうか。技術書の文章には実用的に三層あるからだ、と筆者は考えるようにしました(あくまで私見です)。
一つ目は語彙です。頻度が高い語彙、あるいは使われ辛い語彙がここに入ります。二つ目は文のリズムで、一文の長さ、句読点の位置、言葉の緩急を指します。三つ目が文章の骨格で、何を書くか、何を書かないか、どの順序で語るかです。
ハーネスで模倣できていたのは主に語彙で、リズムは部分的、骨格に至ってはほぼ模倣できていませんでした。
語彙との向き合い方
LLMには一旦ありのままに書かせます。GPT 5.6 や Claude Fable 5 のプロンプトガイドを読むと、守らせる手順を減らすのがベストプラクティスとされているので、最初から縛らない方がいいでしょう。
禁止したい語彙はレビューで検出します。もっとも、機械的に削ると文章も機械的になるため、指摘に留めるのも手です。なお「AIっぽい文章を見つけて」という指示は無駄でした。抽象的すぎて何も出てきません。
リズムとの向き合い方
リズムもまず、ありのままに書かせます。そのうえで音読します。
黙読でも構わないのですが、小声でも声に出した方が効果的です。声に出さず何度も読むと、違和感が摩耗してしまうからです。「私はこの表現をするか？」「話の流れに違和感は無かったか？」「言葉選びは妥当か」と自問しながら読みます。
音読はLLMに限らず、煮詰まったときに効きます。リズム改善系のSkillもあるにはあるのですが、LLMらしさは軽減されるものの違和感が拭えないため、今のところ使わない予定です。
骨格との向き合い方
骨格へのアプローチは、だいたい2パターンありました。
一つは、コンセプトを伝えてLLMに書かせる → 「こんなのが俺の文章なわけないだろ！」 → 反発のままに書き直す → LLMに直させる → 「こんなのが俺の文章なわけないだろ！」(以下略)、という反発駆動の方法です。この方法は疲れます。
もう一つが、一旦殴り書き・メモレベルで並べた材料を元にLLMで初稿を起こし、順序を並べ替えたり過不足を修正したりを人とLLMでターン制で繰り返す方法です。骨格を自分で握ったまま進むぶん、こちらの方が消耗は少なく済みました。
画面キャプチャから文章を作れるか
本書にはエージェント(Cline)の操作の様子を、実況形式で画面キャプチャ付きで紹介するパートがあります。PART3のVibe Coding(自然言語の指示だけで作りきる開発スタイル)と、PART5からPART7のAgentic Coding(エージェントを開発工程に組み込む進め方)のあたりです。
ここでキャプチャから文章を生成させてみたのですが、けっこう厳しい結果になりました。一操作ごとにキャプチャしているわけではないので、間が飛んでいる部分について意図しないストーリーを創作してしまいます。もっとも、OCR的にキャプチャの文字を取り出してくれるのは普通に便利でした。
画像のキャプションを作らせるのはそこそこの結果です。こちらも意図しないストーリーを創作するのは同じですが、説明を1行に収めるのは意外と大変なので、打率が低くても試す価値はありました。
まとめ
とりあえず大量の文を出力するのと、書籍としての品質の間にはギャップがあります。ここを埋める銀の弾丸は見つかりませんでした。
一方で、LLMの出した表現の方がいい場合もあります。その時は素直に採用します。悔しいですが。
また、文章を修正するための語彙を持っておくと、LLMに指示しやすくなります。例えば、単語と単語、その他の品詞間の自然な組み合わせを指す「コロケーション」や、「なぜなら〜からだ」のように対応する表現が正しく組み合わさっているかを見る「呼応」です。指摘の解像度が上がります。
そして最大の教訓は、テクニックに凝るくらいなら手を動かして書くか、LLM出力で早めに失敗例を知る方がいい、ということでした。プロンプトやSkillsに凝るより、Opus 4.6 や Fable など文章力の高いモデルを使う方が効きます。レビューは細かくプロンプトを刻んで適宜実行し、結果はissueなどに記録しておきましょう。
AIエージェントでも技術書はすぐ書けない。これが筆者の結論です。
ふりかえり
ちなみにこの記事は私の文体を蒸留したSkillsでOpus5に書かせて、私の本の文体を蒸留したSkillsを使いFableで直したものです。AIっぽいですよね？ エージェントに執筆を任せられないって、要はこれです。