テスト観点は「出す」より「削る」ほうが難しい。 前回の記事で「テスト観点の書き方」を紹介しました。画面要素を列挙する、仕様書から名詞と動詞を抜き出す、AIに壁打ちする。これで「出す」はできるようになります。 でも、出した観点を全部テストできますか？ ! この記事を読んでほしい人 テスト観点の出し方は覚えた。次に「絞り方」を知りたい人 AIでテスト観点を出してみたけど、量が多すぎて困った人 「何をテストしないか」の判断に自信がない人 試しにClaudeに「ECサイトの決済機能のテスト観点を出して」と投げてみてください。100個くらい、平気で出てきます。正常系、異常系、境界値、セキュリ

「技術ブログを書け、PVを伸ばせ」と言われたあなたへ ども！1年間AIと一緒に活動してきた龍ちゃんです。 「技術ブログを書け、PVを伸ばせ」 会社からそう言われているエンジニア、いませんか？文章書くのは苦痛で、タイトルの付け方もメタディスクリプションの書き方もマーケの話も全然わからない。 先に、この記事で渡したいものだけ。個別のTipsでも「AIがすごい」って話でもなくて、 文章が苦手なエンジニアでも、ネタ切れせずにブログを続けられる仕組み です。検証から公開までの全工程を、ひとつのパイプラインとして見せます。タイトルもマーケも苦手なまま始められますよ。 これだけ「苦手」と言っておきながら、「この1年でAI活用が一番進んだ業務は？」と聞かれたら、答えはブログなんですよね。書き方も、昔は「やったことを順に書く実装ログ」だったのが、今は「読者のつまずきを起点に、検証結果を証拠として置く」形に変わりました。同じ人間が書いてるのに、です。AI活用の集大成として、今回まとめることにしました。 ちょうど1年前にも 「これが僕の執筆環境です」という記事 を1本書いてるんですけど、そこから工程ごとに道具を足し続けた結果が、今回話すパイプラインです。 大事にしている考え方は2つあります。 検証してから書く 。ネタを探してから書くのではなく、検証した結果が記事になる。だからネタに詰まらない 道具を使い捨てず仕組みに沈める 。便利な使い方をその場限りにせず、次も使えるように残す 順番に説明していきますね。 検証・調査からはじまる、Claude Codeで組んだパイプラインの全体像 まずざっくり全体を見てもらいます。 全工程にAIが居ます。調査もアウトライン作りも公開前のチェックも図もサムネも、どこを切ってもAIが何かやってます。ただ、 執筆だけ役割が反転します 。他の工程はAI主導で人間が確認するイメージなんですが、執筆だけは人間主導でAIが補助に回る。なぜそうなるのか、は後半で回収しますね。 なお、この記事に出てくる research-searcher みたいな名前は、それぞれ役割を持たせたAIに付けた呼び名です（僕は Claude Code の skill とサブエージェントで組んでます）。名前は覚えなくて大丈夫なので、「何をする担当か」だけ追ってもらえればOKです。あと、これ全部を自作しないと始まらない話でもないです。普段使ってるAIに同じ役割を振るだけでも回ります。 もう1つ前置きを。7工程のうち5つ（アウトライン / 執筆 / 公開前チェック / 図・サムネ / タイトル・SEO）は、それぞれ単独の記事で深掘りしてあります。なのでこの記事では、その5工程は「何をする工程で、なぜその形にしたか」と、さらっとしたコツだけを置いておきます。気になる方はぜひ個別記事も読んでみてください。 工程ごとに、上流から歩いてみる 工程は7つ。順に見ていくと、AIへの任せ方が工程ごとに違うのが見えてくると思います。 検証してから書く。だからネタ切れしない ブログの起点は「ネタ出し」じゃないんですよね。「検証・調査」なんです。 「よくネタが尽きないね？」って聞かれることがあるんですが、答えはシンプルで、自分の中に1つルールがあって。 検証した内容を基本的にブログ化する ってことを守ってます。 何か気になる技術があって、実際に手を動かして、「あ、こういう結果になった。これはブログにする価値があるな」と判断してから書く。逆に、ネタだけ考えて実装なしで「仮想のブログ」を書こうと思えば書けるんですけど、個人的にそれをやったら終わりだなと思ってて。技術ブログとして 動くものを提供できる 状態を維持することは、最低限守ることにしてます。 ここで効いてくるのが、 検証する場所と記事を書く場所が同じリポジトリにある 、という構成です。気になったら即AIに調べさせて 「放置案件」を作らない 。 調査の品質を /research で揃えて から書き始めると、書いてる途中で主張がブレなくなる。そうやって手を動かした結果は、 docs/research や docs/experiment にメモとして溜まっていきます。検証と執筆が地続きだから、検証した結果がそのまま記事の素材になるんですよね。 で、ネタの話なんですけど。溜まった検証メモを横断検索すると、「これ1記事になるな」という種が自然と立つんですよ。ここは Skill×サブエージェントで調査を速く回す構成 にした専用のエージェント（調査メモを横断検索する research-searcher や、過去のブログを照合する blog-searcher ）に探させてます。だから僕の中に「ネタを探すフェーズ」って実はないんですよ。むしろ逆で、 検証したことがネタになる んだから、検証していないことはそもそも記事にならない。ネタは探すものじゃなくて、検証から生まれるものなんです。そう捉えると、手を動かして検証を続けている限り、「ネタ切れ」という状態そのものが起きなくなるんですよね。「ネタを探す」は「自分の活動の振り返り」に近いかもしれません。 いきなり書かず、アウトラインで勝負を決める ネタが決まったら、次はアウトラインです。誰に・どの検索で届く記事か・どの角度で書くかを、本文を書く前に決めきる工程ですね。少しマーケティング的知識を入れておきます。 書く前に決めきる理由は単純で、「誰に届ける記事か」の設計は執筆より上流でしか機能しないからです。書き始めてから「あ、読者像ずれてたな」となると直すのが本当に大変なので。あと、ここで「うーん、わざわざ書くほどでもないな」となった記事を、1文字も書かずに畳めるのも大きいです。 この工程のコツを1つ。 アウトラインが「方法をN個並べる」形になったら、1記事に詰めるのをやめて分けたほうがいい です。見るのは、並べた方法どうしで読者に要求する思考が同じかどうか。「読者のペインが同じ」はまとめる理由になりません。実はこのシリーズがまさにそれで、最初は1本に詰めるつもりだったのが、工程ごとに読者へ要求する思考が違いすぎて5本に割れました。あと量の目安として、アウトラインは50〜60行で止めてます。超えたら本文を先食いしてるサインで、執筆が「アウトラインの清書」になるんですよね。 アウトラインを先に作ることで、前提知識などが見えてくることがあります。そういった「自分は知っている」けど、みたいな情報に気づくとまたそれも新規のブログネタになるという感じですね。あとは分量が増えたら分割みたいなこともとれるので、時間がなくてもサクッとアウトラインだけ作るのはおすすめです。AIと話して作ればそんなに時間もかからないですしねw そのアウトラインをAIにレビューさせる話（狙う角度を探す担当と、読者の代弁をする担当の2体）は、別記事に書きました。 2026-08-06 技術ブログの手戻りが消える、アウトラインのAIレビュー 執筆は、素材を渡して下書きを作り、最後は自分の目で通す 執筆は、ここまでで溜めた検証メモ・調査・過去記事を素材として渡して、文体を担当するAI（writing-stylist）に下書きを起こさせる工程です。音声入力でしゃべった内容を素材に混ぜることもあります。 ただ1個だけ、あえて仕組みに「落とさない」ところがあって。出てきた下書きを 自分の目で見て「これ、自分が書きそうか？」を判断して直す 。ここはAIに渡さず自分でやります。 正直、執筆の完全分離はできずにAIとけんかしている日々ですね。それでも執筆速度自体は上がっているので結構お勧めな手法です。 自分の文体をどこまで再現できて、どこから中身が捏造されるのか。その実物は別記事にあります。 2026-08-06 技術ブログで自分の文体をAIに再現させて時短を目指す 公開前は1体に全部見せず、観点で割る 下書きができたら、公開前に検査します。 ここで大事なのは、1体のAIにレビュー観点を盛り込みすぎないことです。それをやると観点が混ざって、「全体的によく整理されています」みたいな当たり障りない感想しか返ってこない。なので 観点ごとに別のAIに割って 、1体には1つだけ目的を持たせてます。いま割ってるのは、書いてはいけないことが混ざってないかのリスク検査、辛口の批評、論理の検算です。割ると、各担当が遠慮なく尖った指摘を返してくるんですよね。 ここで効いてるやり方が2つあって。 1つは、 表現の検査を別立てにする ことです。過剰な言い切り、前振りのない唐突な話題転換、「様々な」みたいなぼかし語といったやつですね。これは論理の破綻とは別の壊れ方なので、専用の担当に分けたほうが当たります。あわせて、約物（記号やカッコの揺れ）はAIに判断させず、スクリプトで機械的に正規化してます。揺れてるかどうかは読まなくても分かるので、ここにAIを使うのはもったいないんですよね。 もう1つは、 内部リンクをAIに探させる ことです。公開済みの記事を全部リポジトリに取り込んであるので、「この段落から張れる過去記事ある？」と聞けるんです。自分の記憶で思い出せる過去記事なんて直近の数本だけなので、ここはAIに探させた方が確実です。これは後で出てくる「1リポジトリに集約する」構成の副産物ですね。 検査の中身と、どこまで無人化してどこから人間が裁くのかは、別記事で書きました。 2026-08-06 技術ブログの公開前チェックをAIに任せる：機械が弾き、人が裁く 図とサムネはAIに作らせて、いい出来は貯めて育てる 記事が一通りできたら、図とサムネを付けます。 ここもAIに作らせてます。図は説明したい構造をそのまま渡してHTML＋Tailwindで組んでもらい、それをPNGに変換します。サムネは記事のタイトルと内容を渡して生成する感じですね。文章だけで説明していたところに図が1枚入ると、理解のしやすさが結構変わるんですよね。 最初から一発でいい感じに出てくるわけではないので、出来を見て「もうちょっと詰めて」と作り直すループを回します。そして、いい図ができたらそれを references に保存しておく。次に作図させるとき、それが“お手本”として効いてくるんですよね。この記事に載っている図も、全部この流れで作りました。 サムネイルに関しては、HTMLのコードをパターンとして保存しておくことで再利用ができるようになっています。HTML→PNGの撮影もPlaywrightを使用するとAIが勝手に判断してくれて撮影まで行ってくれるので超便利ですね。 なお、図を「作る」ことより残ってた判断は「どこに置くか」なんですが、そっちの話は1本に切り出しました。 2026-08-06 ブログの図は「どこに入れるか」をAIに決めさせる 作り方を具体的に知りたい人はこちら。 Mermaid図をAIで自動生成する — フロー図やシーケンス図を、Figmaで2時間かけてたのが5分に。最初に試すならここから 図解をAIに丸投げして育てる — 気に入った図をreferenceに貯めるだけで、AIの作図が勝手に上手くなっていく仕組みの話 タイトルとSEOは、マーケティングを知らないままAIで補える 正直、文章を作るよりも苦手だった領域です。タイトルの付け方、メタディスクリプション、競合調査。マーケッターの方に聞いても何から手を付けていいか全然分からなくて、最初にAIに任せ始めたのもここからでした。 やってることは2段階で、上位記事のタイトルの付け方を調べさせて相場を掴んでから、自分の記事のタイトルとメタの案を出させる。採るか直すかは自分で決めます。ここがAIに任せやすいのは、 正しさの基準が自分の外にあるから なんですよね。上位に並んでる記事の付け方が相場で、公開後のPVが答え合わせになる。SEOの知識が自分になくても、相場に照らせば案の良し悪しは判断できるわけです。 1つだけ書いておくと、 タイトルを詰めるついでに、各章の見出しも一緒に見直します 。見出しは執筆しながら立てるんですが、書き終わってから読むと、看板に内輪の用語（エラーの内部名とか実装用語）が乗ってることがあるんですよ。それが出たら文言をいじって済ませず、その章が書き手目線になってるサインとして中身の順番から疑います。看板は「困ってる人が打つ言葉」で書きたいので。 正直に言うと、この工程はまだ仕組み化の途上です。「仕組み完成してます！」と書きたいところですが、そうじゃないので正直に書いておきます。 2026-08-06 技術ブログのタイトルとSEOは、書いた後にAIで詰める 公開したら記録する。書いて終わりにしない 公開して終わり、にはしてないんですよ。 ここで効いてくるのが、また「1リポジトリに集約してある」という構成です。公開した記事も、そのPVデータも、同じリポジトリに置いてある。すると PV分析をこのリポジトリの中で回せる んですよね。このブログはどういう読者層に届いて、なぜ伸びたのか。それを分析して、次の記事のアウトライン（企画）に戻す。 ポイントは「作業ログを残す」というより、 後から参照できる資産として記事と分析結果が同じ場所にある ことです。記事の中身も、PV分析の結果も、ひとつながりで手元に残る。 実際これが効いたことがあって。リポジトリの中でPVを分析したら、生成AI系の記事が圧倒的に読まれていて（うちのブログの場合、PVの8割以上がそこ）、その中でも伸びてるのはツール名を題に置いた実用ノウハウ系で、しかも新記事を出さない月は数字が落ちる、というのが見えたんですよ。結論はシンプルで「 Claude Code 系に絞って、新規記事をとにかく出し続けろ 」。で、実際にそのテーマでシリーズを書き始めました。分析と記事と過去ログが同じリポジトリにあるから、「数字 → 次に何を書くか」の判断をそのまま回せるんですよね。 調査メモも記事の素材も過去ログもPVデータも同じ場所にあると、「次に何を書くか」を決めるのに別の場所を探しに行かなくて済むんですよね。正直やってみないと分からないんですが、続けてみると「あ、これか」ってなると思います。 記録と集約は、それぞれ単独記事にしてます。 git logを作業ログにする話 — コミットをAIに書かせるだけで、git logがそのまま作業履歴に。中断からの復帰や週次の振り返りがラクになる 全業務を1リポジトリに集約した話 — 開発も調査もブログも1つのリポジトリへ。やった仕事が消えず「資産」として積み上がる作業基盤の作り方 全工程に共通して効いてる考え方 工程を全部並べてみると、根っこに通ってるものが見えてきます。冒頭で2つ挙げましたが、こうして並べるともう1つ足したくなるので、3つにして書いておきます。 ① 検証が先、ネタは後 ネタを探すのではなく、検証する。検証したことがネタになるんだから、検証していないことは記事にもならない。記事は検証の副産物として立ち上がるもので、この順番にしておくと「ネタ切れ」という発想自体がなくなるんですよね。 ② 便利技は使い捨てず仕組みに沈める 「これ便利だな」で終わらせない。一番手軽なのは、良い結果が出たら reference に保存して次のAIへの参考資料にすること（さっきの図・サムネが育つのがこれ）。もう一歩進めると、繰り返す作業はスキルやエージェントの形にして残す。どちらも「その場限りにしない」という同じ原則で、保存はその入口です。次に使うとき1から作り直さなくていいので、この積み上げがじわじわ効いてきます。 ③ 1体に欲張らず、観点で割る 公開前チェックのところで出てきましたが、1体のAIに全部やらせると観点が混ざります。用途ごとに割った方が、各エージェントが遠慮なく動くんですよね。これはレビューに限らず、他の工程でも同じ考え方です。 AI全部入りでも、最後に残るのは「これ自分が書きそう？」の判断 自分らしさとAIっぽさのせめぎ合い。その摩擦の中で、自分の言葉が研がれていく。 ここまで見てきた通り、検証から公開まで全工程にAIが居ます。執筆にもAIは居ます。文体エージェント（writing-stylist）が下書きを作るし、音声入力で口述することもある。 でも、執筆だけ役割が逆なんですよね。 他の工程はAIが主導して人間が確認する形ですが、執筆は人間が主導してAIが補助に回る。なんでそうなるか。 理由は、AIの出力が「合ってるか」を測る基準が、工程ごとに違うからなんですよね。もちろん他の工程も、最後は人間が見ます。でも図やSEOや調査は、合ってるか外してるかの基準が外側にある。図がちゃんと描けてるか、検索意図に合うタイトルか、事実が正しいか。だから人間は「確認役」で済む。ところが文章の「自分らしさ」だけは、基準が自分の中にしかなくて、誰かに「合ってます」と言ってもらえない。だから執筆だけ、確認じゃなく「主導」に回るんです。 AIが出してきた文章を読むじゃないですか。読んでいると、「これはちょっと違う」「ここは自分ならこう言わないな」って思う部分が出てくるんですよ。そこを直す。その修正の過程で自分らしさが入ってくるんですよね。音声入力でしゃべった言葉も同じで、そのまま入れるんじゃなくて「これは自分が言いそうか？」を確かめながら使う形ですね。 残るのは「文章をうまく書く力」じゃないんですよね。「 これ、自分が書きそうか？ 」を判断する力なんです。 まぁ正直、この作業をなくしてしまえば今の3倍ぐらいの量のブログを出せますね。ただ、それはただの量産作業な気がしてしまいます。なんとなく愛着も湧かないですよね。文体と自己が乖離しちゃうというか。割と大事にしている考え方です。 これ、「技術ブログを書け」と言われてるエンジニアへのアンサーでもあって。2つ理由があります。 ひとつは、だから量産する意味がないということです。自分らしさをメッセージとして注入していく作業なので、機械的に数を増やすのとは違うんですよね。感覚としては「自分らしさとAIっぽさのバトル」みたいな感じですw ちゃんとそれなりに疲弊します。 もうひとつは、実装した内容は、実装した自分にしか正しく判断できないということです。検証して動かした結果について「これは本当にこうだったか？」を確かめられるのは、手を動かした本人だけです。だから最終チェックは絶対に人間が要る。 ここが面白いなと思ってて。「いきなり自分らしく書け」って言われても、何が自分らしいのかって分からないじゃないですか。でも「AIが出してきた文章を見て、違うと感じる所を直す」なら、誰でもできるんですよ。生成より添削の方が、自分を出しやすい。文章を書くのが苦痛な自分でもこのパイプラインが回ってる理由は、ここだと思ってます。 何から始めるか、そして正直な限界 まず何から始めるか 「で、何から始めればいい？」と思った方へ。 おすすめは、 苦手な1工程からAIに任せてみる ことです。順番はこんな感じ。 苦手な工程を1つ選ぶ （僕はタイトルとメタディスクリプションでした）。使うAIは普段のもので大丈夫です。ChatGPT でも Gemini でも、Claude Code でも 過去記事があれば、何本かAIに読ませて文体や思想を抽出してもらう （まだ1本も無ければ、ここは飛ばしてOK） AIが出した案を「これ自分が書きそう？」で直す 。気に入らない所を直すだけでOK（生成より添削の方がラク） これだけで1工程は回り始めます。いきなりパイプライン全部を組もうとしなくて大丈夫。苦手なところを1個ずつ潰していくと、じわじわ繋がってきます。 もっと手っ取り早く全体像を相談したいなら、この記事ごと自分のAIに読ませて「マネできそうな所ある？」と聞くのもアリです。状況に合いそうな工程を拾ってくれます。 正直な限界 誇張したくないので書いておきます。 まず、 ネタや「気になる！」は人間発信 です。そこにモチベがないと、そもそも書かない。仕組みは「書こうとした人の作業を楽にする」ものなので、動機まで代替はできないですw あと、 最初から完成形は組めない です。続けてみて初めて「ここ変えよう・ああしよう」が出てくる。この記事で紹介した形も、1年かけて少しずつ固まってきたものです。最初から全部揃えようとしなくていいです。 文章を書く苦痛がゼロになるわけでもないです。相変わらず書くのしんどいですよw マーケ周りの分析もまだ仕組み化の途上で、手動でやってる部分があります。 まとめ：個人で完結する領域だからこそ、AIを試せた この1年で一番腑に落ちたことがあって。同じAI活用でも、本職のコードを書く仕事とブログでは勝手が全然違うということです。 本職のエンジニアの仕事でエージェントを使うとなると、結構ハードルがあるんですよ。後のメンテナンスとか、決定事項を流動的に把握しておかないといけなくて、AIに自由にやらせるというより、ガチガチに縛って使うことになる。 でもブログは違うんですよね。僕個人で完結するコンテンツなので、僕がどう思うかだけで決まる。だから 自分が使いやすいように、好きなだけ環境を整えられる 。 そして、この「自分が使いやすい環境を整える」行為そのものが、AI活用を学ぶ一番の場になったんです。skill の作り方、agent の設計、観点の分け方、みんなここで学びました。本職のコードを書く現場では踏み込みづらかった領域に、ブログという個人完結の場だからこそ踏み込めた。それが一番の収穫だったと思ってます。 パイプラインは人によって違っていいんですよ。「自分はこの工程が苦手」「ここは手放したくない」は人それぞれです。残すべき人間の領分を自分なりに見極めていく、その過程がたぶん大事で。 文章を書くのは相変わらず好きじゃないんですけど、「AI活用が一番できてる業務は何か」と聞かれたらブログだって答えると思います。それがこの1年の一番の発見でした。 ほなまた〜 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Claude Codeと書く技術ブログ：ネタ切れしない仕組みの作り方 first appeared on SIOS Tech Lab .

文章は書けるのに、図で手が止まる ども！龍ちゃんです。 文章は書けるんですよ。でも図が。 ブログって図があった方がいいですよね。技術ブログでも、何のブログでも。そこは疑ってなくて、あった方がいいのは分かってるんです。ただ、Figmaとかで作るのも図を検討するのもなかなか時間がかかります。 なので、書き終わってから記事を眺めて「なんかここ、文字ばっかりだな」と思ったら1枚差し込む。あるいは面倒で入れないまま出す。そんな感じでブログの装飾をつけていました。 AIを使うようになってから、この辺が大きく変わりました。図を 作る のはAIでできるようになったんですよ。HTML（ Tailwind ）で組ませてPNGにするところまで自動化してあるので、作るのは早い。最近はこれに加えて「どこに追加する？」の判断もAIに移譲して爆速で図解を作っている感じです。 今回は、ブログの図解関連の判断をちゃんとしたプロンプトに変えて、 図の要否と置き場所をAIに判断させている 話をします。実際に3本の記事に当てた出力も貼ります。 この記事で話すのは「どこに入れるか」だけ 埋めたいところは本当は2つあって、「どこに入れるか」と「どう作るか」なんですよね。ただ、作り方についてはもう別で書いてるので、今回は触れません。 Claude Code SkillでHTML図解を自動生成 — HTMLとTailwindで図を組んでPNGにする話。この記事の図もこの方式で作ってます 図解作成、AIに丸投げしたら「たまに自分より上手い」件 — 気に入った図をreferenceに貯めて、AIの作図を上手くしていく話 作る側はここまで来てるので、残ってるのが「どこに入れるか」だけなんですよね。 あと1つ、隣の話と切り分けておきたくて。「文字の塊が読みにくい」って話だと、たいてい改行や段落分割の話になりますよね。あれとは別の問題を扱ってます。 改行は文の長さの問題を解くもので、図は概念の並列関係の問題を解くもの です。「AとBがあって、Aはこうで、Bはこうで、しかもAとBは逆向き」みたいな構造は、改行をいくら入れても畳めない。そこは図の仕事だと思ってます。 で、この記事で渡すものは2つです。 判断のフローと、具体的なプロンプト 。 図にすると4段ありますが、この記事の取り分は①②です。③④は上のリンク先の話になります。 記事を丸ごと読ませて、息が詰まる所を探させる 使っているプロンプトはこれです。 この記事を全文読んで、図を1枚入れるべき箇所があるか見てほしい。 - 文字の塊が続いて息が詰まる所、概念が並列に並んで文章だと追いにくい所を探す - 見つかったら「どの見出しの直後か」「何を描く図か」を提案する - 図が無くても読める所には提案しない。最小限でいい - 入れる必要がなければ「不要」と返してくれていい。数を揃えなくていい ※ すでに入っている図（ の行）は考慮して、重複する提案はしないこと。 意図してるのは箇条書きの後半2行です。AIって基本的に何か出してくれるんですよね。親切なので。「図の場所を提案して」と頼めば、頼んだ数だけ出してきます。でも図って、増やせばいいものじゃないですよね。要らない図が3枚入った記事って、文字の壁が図の壁に変わっただけなので。 なので**「無くても読める所には提案しない」「数を揃えなくていい」を先に書いておく**。これで、こっちが図を捨てる作業をしなくて済むんじゃないかと思ったわけです。 ちなみにこの記事、シリーズの他の記事だとエージェントを紹介してるんですが、これはエージェントじゃなくて単発のプロンプトです。定義ファイルも作ってません。1回投げるだけで済むので、そのままにしてます。（内容的にスキル化もありですね！） あともう1つ。「記事を読ませて離脱しそうな所を探す」という動きは、 公開前チェックの記事 で書いた辛口係の4つ目の観点とほぼ同じなんですよね。あっちは読者がどこで離脱するかを特定して断罪してくるやつです。動きは同じで、返ってくるものが「断罪」か「図の置き場所」かの違いだけ。今回は後者の話だけします。 実際に3本の記事に当ててみた 自分の記事3本に、上のプロンプトをそのまま投げました。当てたのは全部、図がすでに入っている記事です。 対象 行数 既存の図 ブログ執筆パイプラインの記事（下書き） 287行 4枚 公開前チェックの記事 234行 5枚 文体の記事 153行 3枚 図が3枚から5枚入ってる記事たちなので、正直「もう十分です、不要」が返ってくると思ってました。 返ってきたのは、どれも1枚だった 3本とも「1枚」でした。「不要」は一度も返ってきませんでした。 たとえばパイプラインの記事だと、こう返ってきました。 位置 : オチの節の「理由は、AIの出力が”合ってるか”を測る基準が…」の段落の直後 何を描くか : 「正しさの基準がどこにあるか」で人間の役割が変わることを示す2列比較図。左＝他の工程（基準は外側にある→AI主導・人間は確認役）／右＝執筆（基準は自分の中にしかない→人間主導） 根拠 : この記事で最も長い純テキストの連続です。約20行がすべて散文で、コードブロック・箇条書き・表が一切入りません（他の節は必ず何かで切れています）。しかもここは記事の回収部＝一番読み飛ばされたくない場所です これ、当たってるんですよね。しかも「他の節は必ず何かで切れている」という比較までしてる。記事全体を読んだからこそ言えることで、部分だけ見せてたら出てこない指摘だと思います。 で、言われたとおりに作ったのがこれです。 左右の対比も、下に置く一行も、提案文にそのまま書いてあった通りです。僕がやったのは、指定された構造をHTMLで組んでPNGにしただけ。この図はいま、提案された位置（パイプラインの記事のオチの節）に入ってます。 作る手間はもともと軽いので、こうやって「どこに・何を」まで決まってしまうと、図を入れるのがほぼ作業になるんですよね。迷ってる時間がなくなるのが一番でかいです。 残りの2本も同じ形でした。「この節だけ図がなくて、内容が純粋な並列マッピングだから読者は頭の中に対応表を作らされる」「既存の図2枚の間隔が空いていて、その区間だけ休符がゼロ」。どれも位置と理由がセットで返ってきます。 頼んでいないのに、捨てた理由が返ってきた 面白かったのはここです。3本とも、 提案しなかった箇所とその理由 を勝手に付けてきました。 プロンプトに「見送った所も書いて」なんて一行も入れてません。それでもこう返ってきます。 提案しなかった箇所（検討して見送り） アウトラインの節: 45行と長めですが、実物のコードブロックと5項目の箇条書きで十分に割れています。図にすると箇条書きの再描画になるだけ 公開・記録の節: PV分析が次の企画へ戻るループは図向きの構造ですが、既存の全体図のaltが既に「PV分析が次の企画へ循環する」と明言済み＝重複 設計原則の節: 並列3項目ですが、太字ラベルで既に視覚的に分かれており、各項目2〜4行。図は装飾になります 「図にすると箇条書きの再描画になるだけ」とか、割と厳しいこと言ってきますよね。 別の記事では「この段落は体験の語りなので、構造化すると体温が落ちる」「引用ブロックの並置がすでに図の役割を果たしていて、図にすると実出力の生々しさが落ちる」というのも返ってきました。 体温が落ちる とか 生々しさが落ちる とか、こっちが普段使ってる感覚の言葉です。それを理由に「触らない方がいい」と言ってくる。 これが毎回ほしい場合は、プロンプトを改修すれば毎回出してくれるというのが良いポイントですね。 つまり、こっちが捨てる作業をしなくて済んだんですよね。候補を10個並べられて「どれにします？」と聞かれるのが一番しんどいわけで、そこを向こうがやってくれてる。 なぜ「出さない」の判断をAI側に置くのか 世の中のプロンプト例を見ると、だいたい「この記事から図を入れるべき箇所を3つ挙げて」という形なんですよね。数を指定するやつ。 あれをやると、記事に3箇所も要らなくても無理やり3箇所返ってきます。で、そこから2つ捨てるのは人間の仕事になる。捨てる方が判断としてはしんどいのに、しんどい方が手元に残るんですよね。というか、図が多すぎるのはそれはそれで問題ですからねｗ ここで自分に突っ込んでおくと、僕のプロンプトも「1枚」って数を言ってます。違うのは数の大小じゃなくて、 「無ければ不要と返していい」という逃げ道を一緒に置いてあるかどうか です。「3つ挙げて」は下限の指定で、「1枚あるか見て」は上限＋逃げ道になります。 なので、出す段階で絞らせてます。整理すると、判断が2階層に分かれてる形です。 出す／出さないの一次判断はAI 。「無くても読める所には提案しない」をプロンプトに埋めておく 提案された1枚を採るかどうかは人間 。ここは渡してません 前半をAIに持たせておくと、後半が軽くなる。実際に返ってきたのは「1枚＋捨てた理由」なので、僕がやったのは1枚について「うん、確かに」と言うだけでした。 あともう1つ収穫があって。 見送った理由の方が、判断基準の実体になってる んですよね。3本分の見送り理由を並べると、同じ型に収束してました。 すでに入ってる図が同じことを描いている（重複） コードブロックや箇条書き、引用が既に休符として効いている 短くて1段落で言い切れている 体験の語りなので、構造化すると体温が落ちる 1つ目の重複はプロンプトで「既存の図と重複する提案はしない」と指示してあるので、これは指示どおりなんですけどね。拾い物は下の3つで、とくに最後のは自分で言語化しようとしても出てこなかったやつでした。これが「どこを図の判断とするか」の答えなんですよね。 まとめ：数を揃えさせなかったら、判断が軽くなった 図を作るのはAIに任せられるようになりました。残ったのは「どこに入れるか」で、そこも記事を丸ごと読ませたら判断してくれました。ポイントは 数を揃えさせないこと で、「無くても読める所には提案しない」を先に書いておいたら、3本とも1枚と、捨てた理由が返ってきました。エージェントとして定義を固めてるわけじゃなくその場のプロンプトなので、毎回この形で返る保証はないです。少なくとも3本ではこうなった、というだけの話として置いておきます。 さっきの逃げ道の話、ここで正直に書いておきます。 このプロンプト、「1枚」って聞いてるんですよ。 3本とも1枚返ってきたのは、本当に各記事に1箇所だけ乾いた所があったからなのか、それとも「1枚」と聞いたから1枚に揃えてきただけなのか。**どっちの読みも成立します。**後者だとしたら、置いた逃げ道はほぼ働いてなかったことになる。僕が批判してた「3つ挙げて」型と実質同じですよね。数が3から1に減っただけで。 枚数の指定を外して試せば分かる話なんですが、まだやってません。なので今の時点では「効いてる気がする」までです。「不要」が一度も返ってこなかったのも、抑制が効いてない証拠かもしれない。ここは正直に置いておきます。 あとサムネイルは別問題です。あれは1枚作るのが決まってるので、置き場所の判断が要らない。今回の話には入りません。 図が要るのは分かってる。でもどこに入れるかは分からない。その状態のまま勘で置いてたのが、いまは1枚提案されて「うん」と言うだけになりました。判断が消えたわけじゃないんですが、軽くはなってます。 この記事は、ブログを書く工程を1つずつ書いてるシリーズの1本です。 書く前のレビュー 、 AIに自分の文体で書かせる話 、 公開前のチェック 、 タイトルとSEOの仕上げ 、それぞれ別の記事にしてます。検証から公開までの全体の流れは こちらの記事 でまとめてるので、気になる方はそちらから。 ほなまた〜 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post ブログの図は「どこに入れるか」をAIに決めさせる first appeared on SIOS Tech Lab .