Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
AIエージェントがあれば技術書なんてすぐ書けるでしょ→無理でした
Search
watany
July 23, 2026
Technology
1.6k
7
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
AIエージェントがあれば技術書なんてすぐ書けるでしょ→無理でした
Qiita Tech Festa Dayで講演した内容です
watany
July 23, 2026
More Decks by watany
See All by watany
仕様駆動開発の消費期限
watany
20
9.8k
穢れた技術選定について
watany
22
8.8k
Alphaモジュール使っていいのかい!?いけないのかい!?どっちなんだいっ!?
watany
1
440
The Tyranny of Not Measuring
watany
5
530
新しいVibe Codingと”自走”について
watany
6
600
Equip GitHub Copilot CLI
watany
3
1.6k
SkillsをS3 Filesに置く時のあれこれ
watany
4
2.6k
App Runner最近使ってなかったのなんでだっけ
watany
1
180
CDK Deployのための ”反響定位”
watany
5
1.2k
Other Decks in Technology
See All in Technology
時うどん〜Socket.getifaddrsで学ぶネットワーク編 / Tokiudon: The Socket.getifaddrs Edition
coe401_
4
220
CLIライブラリ開発を支える技術
htnabe
0
150
エージェントはローカル、検証はMicroVM — Lambda MicroVMsでつくるServerless CI
fujioka6789
3
700
Making AI Agents Safe and Fast- Jev, Obsidian, and the Meta-Harness
x5gtrn
PRO
0
120
安心して変更できるWebフロントエンドの作り方
pirosikick
5
2.9k
俺の仕事は AIに奪われないし、たぶんその BIも要らない
hikaruri
0
540
GoのInterface内部構造から学ぶ!最高パフォーマンスを出すコード設計
yappli_developers
1
250
10Xに技術的負債をもたらした「2つの境界の歪み」その構造と解消への営み
10xinc
0
2.4k
30座EKS, 180次升級淬煉的EKS Upgrade Skill 的歷程
eric8230
0
210
Issue 駆動でスペシャリストの意図を届ける、AI 実装のアクセシビリティ向上
thkt
0
130
銀行勘定系システムにおける開発プロセス刷新×AIによる環境モダナイゼーション / Development Process Transformation and AI-Driven Environment Modernization
muit
1
2.6k
ほんとうの信頼性はヒーローが死んでからはじまる / True reliability begins after the hero dies
vtryo
0
100
Featured
See All Featured
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
254
22k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
1.6k
SEO Brein meetup: CTRL+C is not how to scale international SEO
lindahogenes
2
2.9k
Side Projects
sachag
456
43k
Deep Space Network (abreviated)
tonyrice
0
320
Raft: Consensus for Rubyists
vanstee
142
7.7k
Are puppies a ranking factor?
jonoalderson
2
3.9k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
21
1.6k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
11
1k
From Legacy to Launchpad: Building Startup-Ready Communities
dugsong
0
340
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
128
56k
How Software Deployment tools have changed in the past 20 years
geshan
1
34k
Transcript
None
About Me 渡邉 洋平(watany) • • • • 所属:NTTテクノクロス株式会社 AWS
Ambassadors(2024〜) JAWS-UG東京(AWSコミュニティ) 運営 寄稿:CodeZine ◦ 仕様駆動開発への期待と誤解 2026年5月2日(土)発売 https://www.sbcr.jp/product/4815636593/ 2
技術書(単著)を書きました - 買って読んで欲しい! - 対象読者: - ⽣成AI×システム開発を調べてもネットの場 当たり的な情報に振り回されて困っている - Agentの使い⽅をどこから学び始めるべきか
わからない - ⾃分は⼤丈夫でもチームメンバが後をついて こない時、渡す本がない 2026年5月2日(土)発売 https://www.sbcr.jp/product/4815636593/
AI活⽤×執筆のジレンマ ※個⼈の信念です。 - 「AIにシステム開発を委ねましょう!」と 書いたのに、AIに執筆を委ねない理由を 並べるのは道理に合わない - とはいえ、LLMに出⼒させた⽂章は、 AI臭くて使い物にならない 2026年5月2日(土)発売
https://www.sbcr.jp/product/4815636593/
AI Slop(⽣ゴミ) 圧倒的な量に対して内容の薄いコンテンツへの揶揄 海外版流⾏語⼤賞の1つが「スロップ(汚物)」に決定、「AIスロップ」のように使われる⾔葉 https://gigazine.net/news/20251217-merriam-webster-word-of-the-year/
AI Slop ⽂章の”臭い” ⽂章における代表的なAI Slop - 語彙:「構造」「⾜場」「刺さる」「効く」「置く」「emダッシュ(—)」 - 構⽂:Markdown強調、コロン付き箇条書き(- hogehoge:
fugafuga) - 構成 - 章‧節でのサブタイトルの多⽤ - クリフハンガー(続きが気になる中途半端な終わり) - バイアスの⽋如(書き⼿の極論‧傾向に対する、過度な調整) - LLMの予測可能性(=前の話から想定できる地点へ着地してしまう)
AI Slopの脱臭に関する是⾮ - そのAI臭を消す努⼒は、誰のためにやって いるのか - 「品質改善」「ロンダリング」 - なぜAI臭さを消したいのか? -
「責任を負う」「外注の痕跡を消す」 https://x.com/ktrmnm/status/2078763563733414102
”AI Slop”を脱臭するアプローチ Skilsの例 - blader/humanizer - Wikipedia:Signs of AI writingに基づき、AI出⼒で頻出のパ
ターン(33観点)を検出して⾃然な⽂章に修正するスキル - k16shikano/japanese-tech-writing - ⽇本語の技術⽂書を書かせたり推敲させるための⽇本語⽂章 規範スキル
”AI Slop”を脱臭するアプローチ - 執筆中は⾃前Skill‧Commandを試していた - 内容は後述 - Linterも試していた - textlint-rule-preset-ai-writing
textlint-rule-preset-ai-writingを試す https://zenn.dev/hibara428/articles/a4235e23f04110
結論として採⽤できなかった 決定論的フィードバックは、⽂章の質に寄与できない - Linterで「AI⽂章あるある」を刈り取ると、⼈間らしい⽂章ではな く、単に別のバイアスを持った⽂体になった - アンチパターンを機械的に添削した結果、かえって単調な⽂章に なってしまった - 漢字の閉じ開き、もの‧ことの撲滅
- LLMなりに⼈間らしさ(機械翻訳らしさ)を踏まえて出⼒しているの で、AI Slopの特徴を全て消すと、違和感が増す可能性 - 例:スラングを意識しすぎると却って話し⾟くなる
どうしたか
1. ⾃分の真似をさせる ⾃分の⽂体‧スタイルを”蒸留”する - 「⽂体や構成は@watanyの公開記事や登壇スラ イドを読んで理解し、参考に執筆Skillを作って」 - Qiitaを含めて約200くらいの公開資料 - Claude
Codeなどの「Web search tool」で 検索させる。どう真似るかはLLMに任せる https://qiita.com/watany
2. レビュー、修正 - レビュープロンプト例 - 「誤字脱字‧表記誤り‧⽂法誤りはありますか?」 - 「この<⽂章><表現>を簡潔にする代替案を考えてください」 - 「前後の章‧節と整合性が取れてない点を指摘してください」
- Tips - これらを1つの神Skillsに固めると抜け漏れが出るように感じる - 変に凝るより、定型reviewコマンド+観点無しレビューを3並列
どうしたか → どうなったか ユーザーハーネスの考え⽅にマッピングすると - feedforward(⽣成に必要な情報) - 1. ⾃分の真似をさせる -
feedback(評価に必要な情報) - 2. レビュー‧修正 どうなったか - 似てる⽂体にはなるけど、良い⽂章にならない Harness engineering for coding agent users https://martinfowler.com/articles/harness-engineering.html
「技術書の⽂章」の分解 技術書の⽂章には実⽤的に三層ある(と思う) 1. 語彙 - 頻度が⾼い‧使われ⾟い語彙 2. ⽂のリズム - ⼀⽂の⻑さ、句読点の位置、⾔葉の緩急
3. ⽂章の⾻格 - 何を書くか、書かないか、どの順序で語るか
分解した「技術書の⽂章」とどう向き合うか 1. 語彙 - LLMに⼀旦ありのままに書かせる - 禁⽌したい語彙はレビューで検出する 2. ⽂のリズム -
LLMに書かせた⽂章を、⾳読して違和感を検出する 3. ⽂章の⾻格 - 初⼿AI VS 初⼿Human
1. 語彙と向き合う - LLMに⼀旦ありのまま書かせる - GPT 5.6, Claude Fable 5のプロンプトガイドを読むと、
守らせる⼿順を減らすのがベストプラクティス - 禁⽌したい語彙はレビューで検出する - 機械的に削ると⽂章も機械的になるため指摘に留めるのも⼿ - 無駄な例「AIっぽい⽂章を⾒つけて」
2. ⽂のリズムと向き合う LLMに⼀旦ありのままに書かせ、⾳読して違和感を検出する - 黙読でもいいが、⼩声でも声に出した⽅がいい - 声に出さず何度も読むと違和感が摩耗してしまう - 「私はこの表現をするか?」「話の流れに違和感は無かった か?」「⾔葉選びは妥当か」など
- LLMに限らず、煮詰まったら効果的 - リズム改善系のSkillはあるが、LLMらしさを軽減するものの 違和感はぬぐえないため、今の所は使わない予定
3. ⽂章の⾻格と向き合う Human In The Loopの代表的なパターン - 初⼿AI - コンセプトを伝えてLLMに書かせる→「こんなのが俺の⽂章なわ
けないだろ!」→反発のままに書き直す→LLMに直させる→ 「こんなのが俺の⽂章なわけないだろ!」(以下略) - 初⼿Human - ⼀旦殴り書き‧メモレベルの材料を元にLLMで初稿を起こす。 順序を並べ替えたり、過不⾜を修正したり、を⼈とLLMでターン 制で繰り返す
部分的に効果があったアプローチ - 前提:本書にはエージェント(Cline)の操作 の様⼦を実況形式で画⾯キャプチャで紹介 するパートがある - PART3: Vibe Codingを試してみよう -
PART5: Agentic Coding ‒ 開発基盤構築 - PART6: Agentic Coding ‒ コーディング - PART7: Agentic Coding ‒ リリース 2026年5月2日(土)発売 https://www.sbcr.jp/product/4815636593/
部分的に効果があったアプローチ 画像から⽂章を作る⇒けっこう厳しい - ⼀操作ごとにキャプチャしていないので、 意図しないストーリーを創作してしまう - OCR的にキャプチャの⽂字を取り出して くれるのは普通に便利 画像のキャプションを作る⇒そこそこ -
意図しないストーリーを創作してしまう - 意外と説明を1⾏に収めるのは⼤変なので、 打率が低くても試す価値はあった https://www.sbcr.jp/product/4815636593/
AIエージェントでも技術書はすぐ書けない - 書籍の半分ほどはエージェント執筆を試みたが、肌感覚で1~3割程度の効率化 - 何なら⼿段の試⾏錯誤が⻑すぎて、脱稿が遅れてしまった - ⼤量に⽂を出⼒するのと、書籍としての品質にはギャップがある - 少なくとも0→1は「おもんない」⽂章になる -
とはいえ、LLMの出した表現を普通に採⽤する場合も - 素直に⼿を動かして書くか、LLM出⼒で早めに失敗⽂例を知る⽅がいい - プロンプトやSkillsに凝るよりOpus4.6 やFableなど⽂章⼒の⾼いモデル を使う⽅が良い - レビューは細かくプロンプトを刻んで適宜実⾏→issueなどに記録
せめてものTips - AIにゼロから書かせる時は⾃分の⽂章蒸留は効果がある - 「⽂体や構成は<任意>を読んで理解し、参考に執筆して」 - ⽂章を修正する語彙があるとLLMに指⽰しやすい - コロケーション:単語と単語、その他の品詞間の⾃然な組み合わせ -
呼応:「なぜなら〜からだ」など、対応する表現が正しい組み合わせか - Linterは育てるまでが⻑いので、最悪LLMレビューに置き換える選択肢も - ⽂章の違和感を拾うのは⾳読が⼀番実⽤的