AIに文章で負けて悔しかったので、自分の技術ブログをリライトしてみた話
きっかけはバズ記事だった
先日、はてな匿名ダイアリーで「AIに仕事奪われた」という投稿がバズっていた。
読み始めた。
文章がやたら流麗で、感情の起伏がリアルで、ストーリーとして完璧に構成されている。
「この人、文章うまいなあ」
そう思いながら読み進めた。
追記を見た。
geminiの生成文だった。
最初の反応は、悔しさじゃなかった。
むしろ、「すごいな」という感心だった。
正直、初見で見抜ける自信はない。それくらい自然だった。
悔しさの正体
でも、感心は長く続かなかった。
数時間後、ふと気づいた。
自分が書く文章よりも、AIが書いた文章の方が面白い。
その時、初めて悔しさが湧いてきた。
でも悔しさの奥には、別の感情があった。
「自分が書いたブログは、結構苦労して書いて、読みやすいはずなのに、あまり読まれていない」
先月投稿したブログ。
3日かけて書いたのに。
正確な情報を、丁寧に、論理的に書いているのに。
AIが書いた文章の方が面白い。この差は何なのだろう。
Youtubeで見つけた答え
この悔しさをどうにかしたくて、「面白い文章の書き方」を検索してみた。
バズ記事を分析するのではなく、理論から学ぼうと思った。
出てきたのがこの動画。
https://www.youtube.com/watch?v=DfvuynQgwXE
見終わった時、気づいた。
自分の技術ブログ、これ全部やってない。
むしろ意識的に避けていたことすらある。
動画で語られていたのは、主に3つのポイント。
1. 予測とのずれ
読者が「こう来るよね」と思った展開を、少しだけ外す。
驚きが発生して、続きが気になる。
自分のブログ： 「セキュリティチェック対応の工数が増大→生成AIで効率化しました」という王道ストーリー。予定調和すぎて、続きが読みたくならない。
2. 自己参照性
状況説明ではなく、今の自分の感情・主観・醜さそのものを晒す。
「この人、ほんとに本音で話してるっぽい」という信頼が立ち上がる。
自分のブログ： 「課題を抱えていました」「効率化を実現しました」という客観的な業務報告。限られた人員で対応に追われた時の焦りや葛藤は一切書いていない。
3. 変化の知覚
価値観・立場・セルフイメージが壊れる・更新される瞬間をそのまま見せる。
読者が物語の同席者になり、ドラマとして没入する。
自分のブログ： 最初から完成された解決策として提示。「公式回答リストを作成→AIで自動生成→工数52%削減」と結論だけ。途中で何度も失敗したはずなのに、その過程は全部カット。
実験：技術ブログをリライトしてみた
理論だけじゃ意味がない。
実際に、先日投稿した技術ブログをリライトしてみた。
元の記事：
生成AIによるセキュリティチェック対応効率化 ～工数大幅削減・属人性解消を両立する手法～
正直、書いた本人だけど。
読み返して思った。
「これ、真面目すぎて眠くなる」
技術的には正確だし、構成もしっかりしてる。でも、最後まで読む気力が湧かない。
なんでだろう。
リライト後の文章
以下が、3つの視点を意識してリライトした文章です。
午後8時のメンションから始まった話
午後8時すぎ、営業から「明日の午前までにこのセキュリティチェック返せます？」というメンションが飛んできました。これは単なる問い合わせではなく、商談の最終条件でした。もし回答が遅れたり内容に不備があったりすると、最悪そのまま案件が落ちる可能性があるタイプのやつです。
この瞬間に動くのは、Securityチームです。つまり「1問の回答ミス＝売上と信用に直結」という、かなり重い責任を背負った仕事です。
セキュリティチェック対応は、よく「チェックシート埋めるだけでしょ？」と軽く見られますが、実態はそうではありません。これは会社そのものの信用を約束する工程であり、ひとつの回答が、その会社の統制レベル・運用品質・リスク耐性をすべて代表します。雑に書いた1文が、対外的な「公式回答」になります。
だからこそ「ミスれないのに、時間はない」という最悪の組み合わせになりがちでした。
セキュリティチェック対応がなぜ地獄なのか
セキュリティチェック対応は、単に「はい」「いいえ」を返すだけでは終わりません。顧客はこう聞いてきます。
- データはどこで保存しているか
- アクセス権限の管理はどうなっているか
- ログはどこまで監視しているか
- インシデント対応プロセスは誰が責任者か
- 物理セキュリティ（入退室など）はどう担保しているか
これらは会社全体のいろいろな部署や役割にまたがっています。情報セキュリティ、ガバナンス、インフラ、開発運用、法務、コーポレートIT。つまり、1人で全部を完全に答えるのは本来は不可能です。
しかし実際には、社内では「この質問はAさん」「あの項目はBさん」「ここの説明はCさん」と、属人的な形で暗黙にアサインされていました。Aさんが不在だと、その項目は止まります。止まると営業が止まります。営業が止まるとお金が止まります。
セキュリティチェック対応は“属人で回す時限爆弾”になっていました。
そして現場の体感はこうでした。
- 1件のチェックシートに40問〜50問
- 1問あたり、慣れてない人で5分〜10分
- 丸腰のメンバーがやると、回答作成だけでもトータル3時間は軽く飛ぶ
- しかも3時間ぶっ通しでやっても正確性に自信が持てない
このときの本音はとてもシンプルでした。
「これ、もう回せない」でした。
当時の思い込み
当時の自分は、こう思っていました。
- セキュリティ回答は専門知識の塊だから、自動化なんて危なくて無理
- 経験の浅いメンバーに任せるのはリスクが高い
- 結局のところ、わかっている人間が1問ずつ丁寧に書くしかない
つまり、「人間が手でちゃんと書くこと＝品質」だと信じていました。
正直に言えば、「自分がいればなんとかなる」という感覚もありました。これは自信でもあったし、裏返すとプレッシャーでもありました。
でも今振り返ると、この考え方自体が最大のリスクでした。
思い込みが崩れた瞬間
最初にやったのは、AIをいきなり導入することではありませんでした。むしろ逆です。人間側のほうを先に整理しました。
やったことはシンプルです。
- 公式回答リストの整備
- 生成AIによるドラフト作成
- セキュリティチームによる最終レビュー
この順番です。順番が大事でした。
ステップ1：公式回答リストを作る
まず、社外に出してよい説明を「会社としての正式な言い方」に揃えました。これを項目ごとにリスト化しました。
各項目には次の情報をセットで持たせました。
- 回答案（標準でこう答えるべき文章）
- 根拠となる仕組みや運用プロセス
- 主幹部署（誰がこの領域の責任者なのか）
- 更新日・更新元（どの時点の事実か）
ポイントは「回答の文章」だけではなく「正しさの裏付け」と「誰の責任領域か」までがひも付いていることです。これにより、回答の正当性と説明責任を同時に取れる状態をつくりました。
これをやったことで、属人化していたノウハウが、チームの共有資産になりました。
ステップ2：生成AIにドラフトを書かせる
次に、この公式回答リストをもとに生成AIにドラフト回答を作らせました。
AIへの指示は「とりあえず作って」で終わりません。次のような制約をつけました。
-
リストに存在しない情報は勝手に書かないこと
-
回答不能な場合は「回答不能」と明記すること
-
各質問に対して、次の形式で1行ずつまとめること
- 質問項目
- 回答（はい-いいえ-対象外-回答不能）
- 詳細回答（顧客向けの説明文）
- 参照箇所（どの運用や規程が根拠か）
- 主幹部署（責任部門）
この形式で出させることにより、ラフな文章ではなく「説明できる回答案」として最初のアウトプットを得ることができました。
結果として、AIが出してくる草案はかなりの割合で「そのまま使えるベース」になりました。ヒット率は感覚的に8〜9割に迫る場面もありました。つまり、回答を“ゼロから書く”フェーズはほぼ消えました。人間の仕事は「直し」と「保証」に寄っていきます。
ステップ3：セキュリティチームがレビューする
最後に、AIが作った回答案を人間がレビューします。
- 文面にリスクのあるニュアンスが入っていないか
- 顧客の期待レベルと噛み合っているか
- 最新の運用とズレていないか
- 表現が過剰になっていないか（守れない約束になっていないか）
大事なのは、ここではじめてセキュリティ担当者の経験が効くようになったことです。
つまり「すべての回答を自分の手で書く人」ではなく、「回答の正確性と説明可能性を担保する人」に役割が変わりました。
具体的な効果
この流れを回した結果として、次の変化が起きました。
- 回答準備〜確認までの想定工数が、おおよそ半分程度（300分→145分）まで下がるイメージになった
- 経験が浅いメンバーでも、最初のドラフトを一気に組み立てられるようになった
- 回答内容の表現が標準化され、顧客ごとのブレが減った
- どの項目がどの部署の責任かが明確化されたことで、問い合わせのエスカレーションも早くなった
- 一部の回答プロセスは、将来的に別部署や委託先にも引き継げる設計になり、Securityチームが本来やるべき高度な判断（レビューやリスク評価など）に戻れるようになった
言い換えると、「属人で抱えるしかない地獄タスク」から「チームとして回る業務」に変わりました。
いちばん揺れたのは自分自身だった
正直に言うと、いちばん刺さったのはここです。
「自分がいないとこの回答無理だから」という感覚は、誇りでもあり、呪いでもありました。これは、自分の存在価値の根拠にもなっていました。
でもプロセスの標準化とAIのドラフト生成を入れた瞬間、「自分じゃなくてもここまではいける」が現実になりました。
このとき、喉の奥がスッと冷える感じがありました。
「これ、自分の居場所が減るんじゃないか？」という不安がふっと顔を出します。
ただ、そこで同時に気づいたこともあります。
- “自分だけが知っている知識”は、会社にとってはリスクである
- “誰でも同じ水準でスタートできる仕組み”は、会社にとっては資産である
- セキュリティエンジニアの価値は、回答を1文ずつ書くことではなく、回答の正しさと説明責任を担保することに移っていく
これは、職種の自己定義そのものが書き換わる感覚でした。
自分の役割が「職人」から「保証人と仕組みの設計者」に変わっていくイメージです。
この価値観の揺れは、正直に言って気持ちよく始まったものではありません。軽い敗北感もちゃんとありました。けれど、その揺れこそが、チームとしての正しさだとも感じました。
これは特殊な話ではない
これはうちだけの話ではないはずです。
- SaaSが企業の業務プロセスに入り込むほど、顧客からのセキュリティチェックは重くなる
- チェック内容は年々細かくなり、スピードも要求される
- 多くの会社では、回答できる人が1人か2人に偏っている
- その人がいなければ止まる、止まれば売上が止まる、という構造がすでにできている
この構造は、業界やプロダクトの種類にかかわらず、もうかなり多くのSaaS企業で現実化しているはずです。
つまりこれは、「うちが特殊だからこうなった」ではなく、「SaaSをやっていればどこでも順番にぶつかる壁」だと考えています。
まとめ
セキュリティチェック対応は、単なる事務作業ではなく、会社の信用と売上に直結する業務でした。
そして従来のやり方（詳しい人が全部書く）は、実は品質保証ではなく、ビジネス継続性のリスクでした。
- 公式回答リストでナレッジを形式化すること
- 生成AIでドラフトを出して初速を底上げすること
- セキュリティチームが最終責任を持ってレビューすること
この3つを組み合わせるだけで、工数は半分近くにまで落ち、属人リスクも減り、顧客への回答スピードも安定しました。
一方で、このプロセスは単に効率化の話ではありません。
「自分の価値はどこにあるのか」「チームとしてどこに価値を置き直すべきか」という、働き方そのものの問い直しでした。
セキュリティ業務は、守るための業務です。ただ、いまは「守る」の意味が変わっています。
1人のヒーローで守るのではなく、再現可能な仕組みで守ること。
それこそが、次のフェーズの“堅いセキュリティ”だと、今は信じています。
エピローグ
読み返してみて、思った。
こっちのほうが、圧倒的に面白い。
技術ブログでも、「感情」「迷い」「変化」を入れるだけで、こんなに読みたくなる文章になる。
正確さは大事です。でも、正確さだけでは読まれない。
人間にしか書けない「感情の実況」を埋め込むこと。
それが、AIに文章で負けないための、たった一つの方法かもしれない。
追記:
この記事自体も、3つの視点を意識してAIに大半を書いてもらいました。
気づきました？
Discussion