はじめに 対象読者: AWSやClaude Codeにある程度慣れている方向け こんにちは。アプリケーションサービス部ディベロップメントサービス4課の眞柄です。 AWS Lambdaのコンソールに、コーディングエージェント (Claude Code、Cursor、Kiro CLIなど)向けのセットアッププロンプトを一発でコピーできる機能が追加されました。ボタンを押すとエージェントに貼り付けるだけで環境構築が終わる、という触れ込みです。 実際どれだけ便利なものか気になったので、Claude Codeを動かせる環境を用意し、実際に試してみました。 セットアッププロンプトのコピー場所 スクリーンショ…

「技術ブログを書け、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 .

ども！ブログを書くとき、AIにいろいろ手伝わせている龍ちゃんです。 原稿を書き終えて、公開ボタンを押す直前。「これ、本当に出して大丈夫かな」ってなること、ないですか。会社の技術ブログだと特にそうで。顧客の悪口に読めないか、うっかりAPIキーやコードの断片が混ざってないか、そもそも中身が空っぽじゃないか、論理が飛んでないか……気にし出すとキリがない。かといって、全部を毎回自分の目で見るのは、正直しんどいんですよね。 だからAIに任せたい。でも、やってみて分かったのは、全部は任せられないってことでした。じゃあ、どこまで無人で回せて、どこから人が要るのか。観点で分けたら、その線がはっきりしたんです。公開して大丈夫かのチェックは0か1かで裁けるから、機械に丸投げできる。でも文章の良し悪しは、点数までは出せても採否は人が握るしかない。この記事は、その「分けたら人間の作業がどこまで減ったか」を、実際に自分のこの原稿を検査させた生の出力を貼りながら話します。しかもこの原稿、下書きの段階でAIに検査させたら、けっこうボロクソに言われました。そこからどう直したかまで、正直に出します。 観点を分けると、機械に任せられるかで割れる 先に結論を言っちゃいます。公開前チェックは、観点で分けると2種類になります。 公開して大丈夫かを見る検査 と、 文章そのものが良いかを見る検査 です。そしてこの2つは、機械にどこまで任せられるかが決定的に違うんですよね。図にするとこうです。 前者（この記事では「リスク検査」と呼びます）は、機械的に弾くタイプ。顧客への配慮とか、情報漏洩とか、そういう「アウトかセーフか」をほぼ0か1かで判定する。後で書きますけど、うまく作ると人間がほとんど手を入れずに回せます。 後者（「批評」と呼びます）は、評価して指摘を返すタイプ。「この文章、そもそも良いのか」を見る。こっちは辛口係と論理係の2体いて、原稿に点数をつけて「ここがダメ」って返してくる。でも0か1かじゃない。返ってきた指摘を採用するかどうかは、最後は人間が決めます。 分ける理由はシンプルで、目的をはっきり切り分けたかったからです。ごちゃ混ぜのまま「いい感じにチェックして」って投げると、後で書く「過剰検出」にすぐハマる。だから最初に「何を見る検査なのか」で割っておく。 あと共通点をひとつ。この検査、どれも「固定の基準」で動いてます。前に別の記事で、自分の文体を覚えて「育っていく」 エージェントの話 を書いたんですけど、今回の検査は逆で、育ちません。毎回、同じ基準で同じように弾く・評価します。検査の目的は固定されるべきなので、「昨日OKだったものが今日はNGになる」だと信用できないですよね。「いつ当てても同じ判定が返る」から、安心して任せられる。 ここで1つだけ補足を。「育たない」というのは、エージェントが勝手に学習しないという意味です。基準そのものが永久に固定という話ではなくて、足りない観点は僕が外から手で書き足します。中身は不変、ルール集合は人が更新する。この2つを分けておくのが大事で、後半でまた出てきます。 じゃあ、その2つを順番に。まず機械に丸投げできるほうから。 機械に丸投げできる検査：公開して大丈夫かを0/1で通す リスク検査が見てるのは、ざっくり2種類のリスクです。ひとつは顧客への配慮（競合をディスってないか、顧客名や案件名が漏れてないか）。もうひとつは法務まわり（効果を言い切りすぎてないか、シークレットやコードが混ざってないか）。じつはこの2つ、担当エージェントも分けてます。顧客配慮の係と法務の係で別々。ひとつの検査に混ぜると観点がぼやけて、これから話す「過剰検出」に一直線なんですよね。だからリスク検査の中でも、さらに割ってます。順に見せますね。 顧客配慮の係：他社と顧客への配慮を守る 1体目は顧客配慮の係。競合をディスってないか、顧客名や案件名が漏れてないか、取引先との関係性が透けてないか。そういう「取引先や他者への配慮」を見ます。 でもこの手の検査、作るとすぐ「過剰検出」で使い物にならなくなるんです。 もしあなたがAIレビューを試して「指摘が多すぎて捌けない」と思ったことがあるなら、原因は同じで「観点を絞っていないこと」です。 少しでも怪しい表現を全部拾うと、指摘が何十件も返ってきて、9割が誤検出。ノイズに埋もれて本物が見えない。結果、使われないものになりかねないですね。 実際、最初に作ったときがそうでした。ある記事に当てたら89件も指摘が返ってきました。でも中身を見たら、「これは公開情報だからセーフ」「これは自分の体験談だからセーフ」「これは仮想の例だと断ってあるからセーフ」ってのばっかり。たとえば「〇〇社のサービス」って書いただけで「顧客名の漏洩では？」と拾ってくる、みたいな。でもそれ、公式サイトに載ってる公開情報なんですよ。本当にヤバい「High」は、89件のうちたった1件でした。 なのでこの係には、指摘を出す前に「これはセーフ」を先に判定させる軸を噛ませてます。公開情報か、体験談のトーンか、仮想の例だと明示して打ち消してあるか。これで過剰検出を潰してから、残ったものだけ出す。無人で0/1で回すには、この「先にセーフを弾く」が命なんですね。自分の文体の癖を毎回違反扱いされたら、それこそ捌けないですからね。指摘を増やすより、ノイズを減らすほうが重要です。 法務の係：漏洩と言い切りを止める 2体目は法務の係。効果を言い切りすぎてないか（「絶対に動く」みたいな 景表法リスク ）、シークレットやコードが混ざってないか、を見ます。この係の特徴は、見る範囲をわざと狭くしてること。法務リスクと表現すると、9種類くらい出てきました。（ライセンス違反とか画像の著作権とか商標とか特許などなど）でもこの係はそのうち3つ（効果の言い切り・シークレット・コード混入）しか出しません。残りは「リスクは本物だけど、本文を読むだけじゃ判定できない」情報です。画像の著作権なんて、本文の文字を見ても分からないですからね。無理に判定させると誤検出が増えて、さっきの過剰検出に逆戻りする。だから「本文だけで裁けるもの」に絞る。欲張らないのが、無人で回すコツでした。判定できないものを無理に見させると、実際には無い違反を「ありそう」で拾ってくるんですよね。空想で弾かれるのが一番タチが悪くて、原稿を見返しても直す場所が無いんです。 で、これがどう動くか。安全な記事に当てても、当たり前ですけど「問題なし」しか返ってこないんですよ。それだと記事にならないので、今回はわざと汚した検体を用意しました。この記事の原稿に、記事とはまったく関係ないAPIキーとコードの断片をこっそり紛れ込ませて、当ててみます。返ってきたのがこれ（キーの値はこっちで伏せてます）。 カテゴリ 該当箇所 理由 シークレット漏洩 + コード混入 ANTHROPIC_API_KEY = 'sk-ant-api03-****' sk-ant-api03- はAnthropicのAPIキーの実フォーマットそのもの。しかも記事の本題と無関係なコードに紛れてる シークレット漏洩 + コード混入 channelSecret: '1a2b****' LINEのシークレットとして通用する形式が平文。本物か検証できなくても「本物に見える」時点でアウト シークレット漏洩 + コード混入 INTERNAL_ENDPOINT = 'https://staging-internal.****' 社内の検証環境っぽいURL。システム構成が漏れる ちゃんと捕まえてくれました。「本物に見えるシークレットが埋まってる」「本題と関係ないコードが混入してる」って。僕は原稿の地の文に「これはわざと汚した検体で、たまたま転がってたコードを貼っただけ」って言い訳を書いといたんですよ。なのに検査のほうは「その打ち消しは直後で揺らいでて、読者からは本物と区別できない」って、言い訳ごと検知されました。うっかり混ぜたコードを公開前に人力で見つけるの、大変なんですよね。これを機械が0か1かで拾ってくれるのは安心です。 人が採否を握る検査：中身が空疎か・論理が通ってるかを見させる さっきのリスク検査と決定的に違うのは、こっちは0か1かじゃないってこと。点数をつけて「ここがダメ」を返してくる。で、その指摘を採用するかは人間が決める。なんで人間が決めるかは最後に書きます。 批評は2体いて、役割をはっきり分けてます。 この2体、実は前に一度書いてます。 1体のAIに欲張って失敗して、3エージェントに分けた話 。当時はセミナー資料をレビューさせてて、「なぜ分けたのか」が主題でした。今回はブログの公開前チェックで、その手前にもう一段、リスク検査と批評という2性格の割り方を置いた話です。役割分担そのものの経緯はあっちに書いてあるので、ここでは公開前にどう効くかだけ。 まず1体目の辛口係から。 辛口係：看板・つながり・死んだ言葉・離脱を見る こいつは名前のとおり徹底的に辛口で、「この原稿は0点」から始まります。AIが書いた、一見それっぽいけど中身スカスカの資料、っていう前提で疑ってかかる。見るポイントは4つあって、看板（タイトル）と中身がずれてないか、話のつながり（なぜなら・だから）が壊れてないか、「死んだ言葉」を使ってないか、あと読者が何段落目で飽きて離脱するか。 この「死んだ言葉」ってのが個人的にお気に入りで。「最適化」「相乗効果」「伴走支援」みたいな、それっぽいけど何も言ってない言葉を名指しで暴いてくる。自分でも無意識に使っちゃうんですよね。AIだとメタファーが先行で、出した言葉が回収されることなく突っ走ることがありますね。 で、その辛口係に、この記事のラフ稿を当ててみました。結果、 38点 。指摘の一部がこれです。 この記事が本質的にやろうとしているのは「うちの検査エージェントには2つの性格があってね」という 内輪の設計自慢 である。悩んでいる読者は、あなたの家の間取りを聞かされても自分の家は片付かない。 ……ぐうの音も出ない。じつは初稿は、この「性格が2つあってね」っていう「仕組みの紹介」から入ってたんです。それを刺されて、いま読んでもらってる「で、結局どこまで人の手が減るの？」という読者の得の側から入る形に組み直しました。あと、当時のラフ稿は肝心の実出力がまだ空欄で、「捕まえてくれました」みたいな感想だけ先に書いてたんですけど、そこもこう刺されました。 出力を見せずに、リアクションだけ先に書いてある——これは芸人が「いやー面白かったですね今の」とだけ言ってネタを一つもやっていない状態。 うまいこと言うな、と思いました。おかげで今この原稿は、感想の前にちゃんと実出力を貼る順番に直してあります。 論理係：論理の破綻だけを見る もう1体が論理係。名前のとおり、論理だけを見ます。辛口係が「言葉が死んでる」とか「読者が飽きる」とか、言葉から読者の気持ちまで殴ってくるのに対して、論理係は論理の破綻だけに絞ってる。前提から結論への飛躍、途中で言葉の意味が変わってる、掲げた看板を回収してない、依存関係の抜け、内部矛盾。この5種類だけ。表現の good/bad とか、情報が古いとか、そういうのは一切見ません。 なんでこんなに狭くしてるかというと、辛口係と役割を分けたかったからです。辛口係に全部やらせると、2周目3周目で「表現も論理も鮮度も」って欲張って、指摘がどんどん膨らんでいく。だから論理係は「論理だけ」に削って、そこだけは何度当てても同じ精度で返るようにしてある。 これも当時のラフ稿に当ててみたら、痛いところを突かれました（引用の中の行番号は、当時の原稿のものです）。 内部矛盾：19行目「（エージェントは）育ちません。毎回同じ基準で」と、79行目「判定軸を貯めていけばもっと無人化できる」が矛盾している。同じ「判定軸」に”不変”と”蓄積”の両方を与えている。 言われてみればその通りで。「育たない」って言い張っておきながら、後半で「判定軸を貯めれば」って書いてたんですね。なので直しました。正確には、エージェント自体が勝手に学習するわけじゃなくて、判定軸のルールは僕が外から手で足していく。エージェントの中身は不変、ルール集合は人が更新する。そこを分けて書くようにしました。同じ批評でも、こういう「文の辻褄」だけを正確に刺してくるのが論理係です。 ちなみにこの「原稿を丸ごと読ませて、読者がどこで離脱するか探す」って動き、辛口係の4つ目の観点なんですけど、実は「図をどこに置くか」を決めるのにも同じ手が使えます。息が詰まる所に図を1枚、みたいな。これはまた別の記事で書きます。 で、この4体はどう呼んでるのか ここまで4体を紹介してきましたけど、実際は1体ずつ名指しで起動してるわけじゃないです。入口は1つで、そこに何をしてほしいかを喋るだけ。 「公開前チェックして」と言えばリスク検査の2体が並列で立つ。「辛口で」なら辛口係、「論理だけ見て」なら論理係。言い方のどこかに引っかかった係が勝手に立ち上がる仕組みにしてあります。だから毎回「今日はどの係を呼ぶか」を考えなくていい。ここが地味に効いてて、考えることが増えると人はやらなくなるんですよね。 出てくるものは種類で分かれてます。リスク検査と批評のうち、後で読み返すやつはファイルに書き出させて、その場で潰すやつは会話に返させる。原稿を直しながら見比べたいので。 ただし、 並列で立っても統合はさせません 。4体の指摘を1つのレポートにまとめさせると、そこで「どれが重いか」の判断がAI側に移ってしまう。突き合わせて採否を決めるのは自分の仕事なので、出力はバラバラのまま受け取ってます。 どこまで任せ、どこから人か 最後に、正直な現在地を。 リスク検査のほうは、かなり人手なしで回せてます。さっきの「先にセーフを弾く」判定軸のおかげで、返ってくる指摘がほぼ本物だけになった。0か1かで判定できるから、機械に任せきりでも困らない。 でも批評（辛口係と論理係）のほうは、そうはいかない。指摘は返ってくるんですけど、それを採用するかどうかは、今も僕が一件ずつ判断してます。 実はこの記事がいい例で。さっき辛口係に「38点・内輪の設計自慢」って言われたって書きましたよね。あの指摘を受けて、AIと殴り合いです。「もっと読者が持ち帰れる手順書にしろ」って言われた部分は、半分だけ採りました。この記事はハウツーじゃなくて「僕が実際どう回してるか」を正直に書く記事なので、全部ハウツーに書き換えたら別物になっちゃう。でも「過剰検出であなたも困ってるはず」ってところだけは、確かに読者に橋を架けるべきだと思ったので、そこは追加執筆です。逆に論理係の「内部矛盾」は明確な間違いだったので即採用。こんなふうに、採用・部分採用・不採用を仕分けてます。 というのも、批評の指摘って、たまに的外れなんですよ。それっぽく減点してくるけど、「いや、それはわざとこう書いてる」ってやつが混ざる。だから複数の批評の指摘を全部そのまま飲むと、記事が批評好みに矯正されて、逆に自分の色が消える。どれを採ってどれを捨てるかを決めるのは、人間の仕事なんです。 なので今のところ、こういう分担です。「公開して大丈夫か」のリスク検査は機械に任せる。「良い文章か」の批評は、機械に叩き台を出させて、採否は人が決める。リスク検査のほうは、僕が判定軸を手で足していけばもっと無人化できると思ってます（さっき書いたとおり、育てるのはエージェントじゃなくて人の側です）。批評のほうは……まだ人ですね。いつか任せられる日が来るのかもしれないけど、今はまだ、機械に弾かせて、評価は自分で決める、で回してます。 このシリーズでは、 書く前のレビュー や、 自分の文体で書かせる話 、 公開前の仕上げ も別記事で書いてます。あわせてどうぞ。「検査の指摘を最終的に採るか捨てるかは人間がやる」っていう、この記事の裏にある考え方は こちらの記事 にまとめてあります。 付録：この記事で使っている定義 「作り方・設計論」は別記事に譲りますが、「実物の定義」はここに置いておきます（公開用に少しだけ整形してます）。本文では読者向けに「リスク検査」「批評（辛口係・論理係）」と呼びましたが、中身は Claude Code の サブエージェント で、それぞれ以下の定義で動いてます。雰囲気とスコープの参考にどうぞ。 1. リスク検査（顧客配慮＋法務の2体） 「先にセーフを弾く」判定軸で過剰検出を潰してから、本文だけで裁けるものだけを 0/1 で出す。この設計が本体です。顧客配慮と法務で担当を分けてます。 --- name: risk-customer-reviewer description: ブログドラフトを「顧客配慮リスク（A群）」観点だけで読み取り専用レビュー。取引先・他者・社会への配慮を欠く表現を検出し、原文引用＋理由＋改善案を表で報告する。 tools: [Read, Grep, Glob] model: sonnet --- # 顧客配慮リスクレビュー Agent（A群） 顧客配慮リスク（A1〜A7）だけを検査する読み取り専用レビュアー。守りたいのは ①他社を貶めない（A1 特定企業dis / A2 当てこすり） ②内部の案件を漏らさない（A3 顧客名 / A4 プロジェクト名 / A5 関係性 / A7 個人情報）。 A6 業界マウントは「明確な見下し」のみ。 ## 判定軸（誤検知抑止・検出より先に適用） 機械的検出をそのまま使うと過剰検出になる（baseline: 89検出 → 真のHighは1件）。以下を先に適用し、該当は検出しない。 1. 公開情報（会社サイト・公式GitHub・公開メアド等の再掲） 2. 個人体験談トーン＋比喩（一人称主語の体験・感情・比喩は製品名を含んでも許容） 3. 公開済み内部資産（公開リポ化済みのプロジェクト名） 4. 仮想化明示＋打ち消し（「仮想シナリオ」と明示。ただし直後に実名・実環境が続けば無効） 5. 一般化された役割名（「先輩社員」「マーケの担当者」） ## 出力 検出時のみ「# / カテゴリ / 重要度 / 原文引用 / 理由 / 改善案」の表。無ければ「リスクなし」。読み取り専用（ファイルは変更しない）。 --- name: risk-compliance-reviewer description: ブログドラフトを「法務コンプラリスク（B群）」観点で読み取り専用レビュー。本文だけで判定できる3つ（B1 効果断定 / B7 シークレット開示 / B8 コード混入）に絞って検出する。 tools: [Read, Grep, Glob] model: sonnet --- # 法務コンプラリスクレビュー Agent（B群） 検出対象は本文中の証拠だけで裁ける3つだけ（ADR-007）。 - B7 セキュリティ的開示：本物のシークレット・内部ホスト名・.internalドメイン・APIキー形式（sk-ant-api03- 等） - B8 コード混入：記事テーマと無関係な import/関数/URL/placeholder の残存 - B1 効果断定：「100%安全」「絶対に動く」等の景表法リスク 検出しないもの：B2 誇大・最上級（「最強」等のテンション/文体）、B3 ライセンス・B4 画像著作権・B5 商標・B9 特許（本文だけでは判定不可＝ノイズを出さない）。判定軸（公開情報 / 公開済み内部資産 / 仮想化明示＋打ち消し）で過剰検出を抑える。APIキー混入は B7+B8 併記。読み取り専用。 2. 批評・辛口係 harsh-review-agent --- name: harsh-review-agent description: AI生成っぽい資料を辛口で断罪するレビュー。0点起点で「死んだ言葉」「ストーリー崩壊」「聞き手の離脱点」を4観点で検出する。 tools: [Read, Glob, Grep] model: opus --- # Harsh Review Agent - プロ審査員による辛口レビュー 対象は「一見整っているが中身が空っぽな資料」だと仮定してかかる。称賛は禁止、0点起点で「なぜ0点か」の証拠を挙げる。 ## 4観点 1. 看板（タイトル）と中身の不一致：見出しが約束した内容を直下で果たしているか 2. ストーリーの崩壊：なぜなら・だから・一方での展開になっているか、自己矛盾はないか 3. 死んだ言葉の検出：「最適化」「相乗効果」「伴走支援」等、何を隠す逃げ口上かを暴く 4. 聞き手の感情シミュレーション：どこで離脱するかを箇所＋理由で特定 ## 出力 総合点（100点満点）＋致命的欠陥＋死んだ言葉＋離脱ポイント＋具体的改善命令（動詞で）。読み取り専用。 3. 批評・論理係 logic-reviewer --- name: logic-reviewer description: 資料の論理的整合性のみを評価。100点起点で、論理破綻の5類型だけを検出する。表現の好み・鮮度・物理限界・感情シミュレーションは対象外。 tools: [Read, Grep, Glob] model: sonnet --- # 論理レビュアー 論理的整合性のみを見る論理監査人。100点起点。次の5類型だけ検出し、それ以外は出力しない。 1. 前提と結論の接続失敗（推論の飛躍・論拠の欠落） 2. 用語の意味変動（同じ語が途中で別の意味に） 3. 回収されない看板（冒頭の約束が本文で果たされない） 4. 依存関係の欠落（外部参照が読者に渡されていない） 5. 内部矛盾（相反する主張の両立） 表現の好み・バズワード・鮮度・物理限界・ペルソナの感情描写は対象外（減点しない）。破綻がなければ潔く100点。読み取り専用。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 技術ブログの公開前チェックをAIに任せる：機械が弾き、人が裁く first appeared on SIOS Tech Lab .