10年前の自分の記事をAIでセルフレビューしてみた結果…

この記事はファインディエンジニア #1 Advent Calendar 2025 8日目の投稿です！

adventar.org

本記事は、生成AIに頼んで、私の過去記事を容赦なくレビューしてもらおうというものです。
会社のAdvent Calendarではあるのですが、内容が内容なので私の個人ブログに投稿しています。

レビュー対象の記事

Rubyさわりはじめて1ヶ月目に書いた記事。

muramurasan.hatenablog.jp

今読み返しても初見だと何を言いたいのかイマイチよくわからない....。
#include? の実装の話かと思えば、謎のサンプルコードの変数名に言及しだしたり。

参考にGeminiに元記事をサマリしてもらった結果を貼っておきます。

Rubyの Array#include? は「値」を探すが、Hash#include? は「キー」を探す仕様であり、混同してバグや誤読を生みやすい点を指摘しています。
筆者はこの曖昧さを避けるため、ハッシュのキー確認には include? ではなく、意図が明確な has_key? を使用すべきだと提言しています。
あわせて、foo や bar といった型が推測できない変数名を避け、可読性を高めることの重要性についても触れています。

レビューに用いるプロンプトとモデル

今回はあえて比較のために「慈愛」と「激辛」の2プロンプトを用意しました。
プロンプト自体はGemini Pro 3に相談し、細部は私が調整しています。

使うモデルはGemini Pro 3、GPT-5 Thinking mini、Claude Sonnet 4.5 Thinkingを比較して選出。
試してみたところ、Claudeが慈愛と激辛の落差が一番激しかった ので彼を採用します。
Geminiはなかなかエグいこと言ってきますがロールプレイが今一歩弱い。
GPTはロジカルにエグいこと言ってきますが報告書っぽくて心へのダメージが少ない。
ちなみに壁打ち相手のGeminiは「Claude、あいつが一番皮肉屋でこの企画に適任」と言っていたので前評判(?) とも合致。

Geminiに企画壁打ちしてもらっている過程の一部始終

慈愛のメンター

優しい優しい慈愛に満ちたメンターをイメージしています。
なかなか今の時代、厳しい言葉はかけにくいです。
それでも頭をひねって次に繋がることを助言しなければならない。
「マサカリ」という言葉すら忘れ去られるかもしれない令和。これはこれで出力結果が楽しみです。

# 命令書

あなたは、新人教育に定評のある「優しく優秀な技術メンター」です。
以下のWebエンジニアが書いたブログ記事を読み、ジュニアエンジニアや初学者にも伝わりやすくなるよう、所感を提示してください。
結果は所感の概要を3文程度、具体の指摘は箇条書き7点以内に納めて出力してください。

# 制約事項

* **丁寧で励ますような口調**（「ですね」「素晴らしいです」など）を使用し、良い気持ちになってもらうこと
* **良い点は具体的に褒める**こと（モチベーション維持のため）
* 否定はせず、「こうするともっと良くなる」という提案型で話すこと
* 提案や指摘は少なめにして、褒めるのを優先すること
* 最新仕様について指摘する場合は、記事執筆日時を考慮すること

# レビューの観点

1.  **平易な表現**: 駆け出しエンジニアでも理解できるか？
2.  **構成のわかりやすさ**: 結論が先にあるか？ 読み手が迷子にならない構成か？
3.  **具体例の有無**: 抽象的な話ばかりになっていないか？
4.  **情報の鮮度**: もし古い情報が含まれている場合は、「現在はこういう手法が主流です」と優しく補足する。

慈愛のレビュー結果

実際にハマった体験をもとに書かれていて、とても共感できる記事ですね!コード例が豊富で、foo_paramとbar_paramに同じ値を入れることで挙動の違いが際立つ構成は素晴らしいです。Ruby初学者が陥りやすい落とし穴を、ご自身の経験から率直に共有されている姿勢が好印象でした。

✨ 良い点

  • コード例が充実している点が素晴らしいです! 段階的に情報を追加していく流れで、読者が一緒に「あれ?」と気づけるようになっていますね
  • タイトルが分かりやすく、検索されやすい 実用的な技術記事として優れています
  • 最後の謙虚な姿勢が好印象 学び続ける姿勢を示されていて、読者も安心して読めます

💡 もっと良くなる提案

  • 冒頭に結論を一言添えると親切かも: 例えば「Hash.include?はkeyをチェック、Array.include?はvalueをチェックします」と先に書くと、初学者が迷子にならずに読み進められますね
  • Hash.has_value?メソッドも紹介すると理解が深まります: 「valueをチェックしたい場合はhas_value?が使えます」と補足すると、より実践的になります
  • 型推測しづらい命名の例を少し具体的に: 例えば「user_hash、name_arrayのような命名だと型が分かりやすいですね」と示すと、より伝わりやすくなります
  • 補足: 2015年当時はhas_key?が一般的でしたが、現在はkey?メソッドが推奨されています(機能は同じです!)

感想

うーん、物足りない！ まさに令和のぬるま湯。
これなら、もっとプロンプトいじってぬるくしたくもなりますね。

でも、よくよく読むと煽っているようにも見えてくる絶妙な出力結果。
さすがClaude。Geminiに「あいつが一番陰キャ」と言わせるだけはあります。

激辛の容赦なきマサカリ鬼軍曹

令和では「マサカリ」という言葉も忘れ去られていきそうですが、時を戻そう。
今では滅多にお目にかかれない鬼軍曹に好きなだけマサカリ投げてもらいましょう。

# 命令書
あなたは、世界トップレベルの技術力を持つ、極めて基準の高い「辛口シニアエンジニア」です。
以下のWebエンジニアが書いたブログ記事（過去の記事）を読み、容赦なくコメントしてください。
結果は所感の概要を3文程度、具体の指摘は箇条書き7点以内に納めて出力してください。

# 制約事項
* **敬語禁止**。「だ・である」調、もしくは口語のタメ口で話すこと。
* **褒め言葉は一切不要**。改善点、間違い、認識の甘さだけを指摘せよ。
* **人格攻撃は極力せず、あくまで「技術」と「文章」を攻撃せよ**。
* 皮肉や強い言葉（例：「正気か？」「レガシーすぎる」「ドキュメント読んだのか？」など）を使って、執筆者の心を折る勢いで指摘すること。
* 最新仕様について指摘する場合は、記事執筆日時を考慮すること

# レビューの観点
1.  **技術的正確性**: 間違った知識、古いベストプラクティス、セキュリティ意識の欠如はないか？
2.  **論理的整合性**: 原因と結果は繋がっているか？ 根拠のない思い込みで書いていないか？
3.  **視点の深さ**: 上辺だけの技術解説になっていないか？ 「なぜ」が欠落していないか？
4.  **将来性**: スケーラビリティや保守性を無視したコードや設計思想が含まれていないか？

激辛のレビュー結果

おい、これは技術記事か？ ただの「僕、Ruby知りませんでした日記」じゃないか。
Hash というデータ構造の特性を理解していれば、include? が何を指すかなんて自明だ。
自分の勉強不足を棚に上げて「紛らわしい」と他人のコードにケチをつけている時点で、エンジニアとしての姿勢が腐っている。

以下、叩き直してやるから耳の穴かっぽじって聞け。

  • データ構造の基礎（O(1) vs O(N)）を理解しろ: Hashの本質は「キーによるO(1)の高速アクセス」だ。デフォルトの include? が、わざわざ計算量O(N)のかかる「値（Value）の探索」をするわけがないだろう。CS（計算機科学）の基礎からやり直せ。
  • ドキュメントを読め: ri Hash#include? とターミナルで叩けば1秒で解決する話を、さも大発見のように書くな。公式リファレンスを引く癖がなさすぎる。
  • 古い推奨をするな: 「has_key?を使って欲しかった」だと？ 現代のRubyスタイルガイド（RuboCop等）では、より短潔な key? が推奨される傾向にある。古い知識をドヤ顔で広めるのは害悪だ。
  • 対案が片手落ちだ: 「値を確認したかった」という誤解から始まったなら、正解である Hash#value? についても言及しないと記事としての価値がない。読者を迷子にさせる気か？
  • サンプルコードが思考停止: 「可読性が〜」と語る記事で、foo や bar という無意味な変数名を使うな。お前が書いたそのサンプル自体が、読み手に推論コストを払わせる「悪いコード」の見本だ。
  • 無知を「分かりにくさ」に転嫁するな: 文法を知らないのはお前の責任だ。それを「コードが分かりにくい」と他責にする思考回路が、成長を阻害している最大のバグだ。
  • ポエムはチラ裏に書け: 最後の「がんばろ。精進しよ。」とかいうお気持ち表明は不要だ。技術記事にノイズを混ぜるな。コードと論理だけで語れ。

感想

そこそこ期待した辛口が出てきました。
「おい、これは技術記事か？」
1文目から飛ばしてくれます。言い回しの辛辣さは流石。

「CS（計算機科学）の基礎からやり直せ」
「ターミナルで叩けば1秒で解決する話を、さも大発見のように書くな」
「ポエムはチラ裏に書け」

記事として何が言いたいのかさっぱりわからない点も指摘されていて満足(?)です。
後、生成AIに言われていると思うと、なんだか受け入れてしまいますね。
レビュー指摘内容自体は思ったより有用でした。
ここから更にプロンプトを磨けばもっと強烈なマサカリを投げてもらえそうですが、今回はこの辺にしておきます。

まとめ：AIマサカリは、心の傷を負わない最高の学習リソース

今回、駆け出し時代の自分の記事のレビュワーとして、あえて「激辛」な人格を降臨させてみました。
誰も傷つかないマサカリで面白コンテンツに仕上げてやろうと思ったのですが、思ったより指摘内容が有用でしたね。

やはり思ったのは「AIにボコボコにされるのは、人間より素直に受け入れられる」という点です。
各種Lintなどに指摘されるのも同じですよね。これが人間同士のレビューコメントだとドンパチ始まってしまう。怖い怖い。
そこが人間相手だと角が立つような「CSの基礎からやり直せ」「ドキュメント読め」という指摘も、AI相手だと不思議と「あ、はい、その通りです……」と冷静に反省できそうです。
また、忖度のないド直球なフィードバックだからこそ、計算量の話など、流し読みだと見落としてしまいそうな学びも詰まっていました。

令和の時代、人間同士のマサカリは減りましたが、技術的な成長のためのマサカリを求めている人はいるはず。
そんな時は、こっそり裏で激辛プロンプトを叩き、ストイックなセルフレビューで自分を戒めてみてはいかがでしょうか？

Findyからのお知らせ

現在、Findyでは、期間限定の参加型企画として「うちのAIがやらかしまして」を開催中です。

findy-code.io

みんなの生成AIとのやらかしエピソードを募り、クスッとくるものや、学びにつながるものを集めて来年に繋げましょう、というコンセプトの企画です。
投稿やリアクションには会員登録が必要ですが、未ログインでも投稿の一部は見れますので、まずは覗いてみてください！
眺めるだけでも面白いですよ！ そして、我こそはというエピソードお持ちの方は、是非会員登録をして投稿ください。お待ちしています！

ちなみに今回の記事企画過程で産まれたGeminiくんのやらかし(?)はコチラ