8月30日、Amanda Caswellが「I gave Claude one app and asked it to act like four different senior developers」と題した記事を公開した。Claudeに4つの異なるシニアエンジニアのペルソナを与えてアプリをレビューさせる実験を行い、各ペルソナが互いに見落とした問題を発見しただけでなく、通貨フォーマット処理を349msから5.2ms（約67倍）に高速化しながら「この最適化は実際には不要だった」と自ら認めるという逆説的な結果が得られた。
ペルソナプロンプティングとは何か
AIへの指示に「特定の専門家として振る舞え」という役割設定を加える手法は、ペルソナプロンプティング（あるいはロールプレイプロンプト）と呼ばれる。単に「改善して」と頼むよりも、「◯◯の専門家として◯◯の観点だけで見て」と制約を与えることで、モデルの注意が特定のドメインに集中し、汎用的な回答では埋もれがちな問題が浮上しやすくなるとされている。この実験はその効果を実際のアプリで検証したものだ。
Caswellは、あらかじめChatGPTで作成していた家計費トラッカーアプリをClaudeに渡し、4つのペルソナを順番に割り当ててレビューさせた。役割は次の通りだ：
- シニアフルスタックエンジニア
- シニアデバッグエンジニア
- シニアフロントエンドエンジニア
- シニアパフォーマンスエンジニア
各ペルソナは「担当範囲以外には手を出さないこと」と明示した上で呼び出している。この制約の明示が肝だ。
フルスタックエンジニアが最初に行ったこと
第1のペルソナであるシニアフルスタックエンジニアは、アプリ全体の構造を俯瞰してコードを整理した。具体的にはコンポーネント設計の見直しとコードの保守性向上が中心で、後続のペルソナがレビューしやすい状態に整える役割を担った。この段階では機能バグやアクセシビリティ問題には深く踏み込まず、後続の専門ペルソナに委ねる形となっている。
デバッグエンジニアが見つけた問題
第2のペルソナでは、機能面のバグを中心に調査させた。プロンプトでは「外観には触れるな、機能バグだけを探せ」と制約を明示している。
発見された問題：
- Enterキーで送信できない：入力欄が
<form>タグで囲まれておらず、ボタンクリックは動くがEnterキーが効かない - 日付なしで保存できる：日付欄を空にしたまま保存が通ってしまう
- 空の状態で「Housing」が最大カテゴリに表示される：集計ロジックのバグ
- 削除が一発で確定する：確認ダイアログなし（この問題はフロントエンドエンジニアが後で対応）
- ストレージ失敗がコンソールに隠れる：ユーザーには保存できたように見えて実は失敗している
一方で、自動テストの作成はしなかった。修正が正しく機能するかを検証するコードが残されなかった点は、Claudeの限界として言及されている。
一番面白かったのは「フロントエンドエンジニア」が別の問題を見つけた点
実験で最も示唆に富む結果が出たのは、第3のペルソナ（フロントエンドエンジニア）だ。
使ったプロンプトはこうだ：
Now act like a senior frontend engineer specializing in accessible, responsive consumer applications. Review the current expense tracker from the perspective of someone using it on a phone, with a keyboard or with assistive technology...
このペルソナが発見した問題は、デバッグエンジニアが完全にスルーしていたものだった。たとえば：
- フォーカスインジケーターが消えている：アプリはキーボード操作時に通常表示される入力欄の枠線を削除しており、代替表示も用意されていなかった
- ラベルと入力欄が未接続：視覚的には対応して見えるが、DOMレベルでは紐付いていない
- スクリーンリーダーにエラーが伝わらない：バリデーションエラーが音声通知されない設定になっていた
- 削除ボタンが一発削除：デバッグエンジニアは見逃したこの問題を、フロントエンドエンジニアは「2ステップ確認」に修正した
アクセシビリティの実装については一部に不整合もあった。Claudeは「最小タッチターゲットサイズは44×44ピクセル」と述べながら、実際の削除ボタンは36×36ピクセルにしか拡大しなかった。これはWCAG 2.2 AAの最低基準は満たすが、自ら言及した推奨値には届いていない。WCAG 2.2 AAはW3Cが定めるウェブアクセシビリティのガイドラインで、キーボード操作・スクリーンリーダー対応・タッチターゲットサイズなどを規定している。言葉と実装が一致しないこの齟齬は、AIレビューを鵜呑みにせず人間が検証する必要性を示している。
パフォーマンスエンジニアの「やりすぎない判断」
第4のペルソナには、1万件のトランザクションに耐えられるよう最適化を指示した。
Claudeが見つけた最大のボトルネックは、通貨フォーマットオブジェクトを毎回生成していた点だ。1万行の描画で349ミリ秒かかっていたこの処理は、オブジェクトを再利用することで5.2ミリ秒（約67倍の高速化）に改善された。さらにテーブルの仮想スクロール（画面内の行だけをレンダリングする手法）の導入や、検索・ストレージ更新のデバウンス処理も実装した。
だが、この実験で最も印象的だったのは最適化の内容ではなく、Claudeが「この最適化は実際には不要」と認めた点だ。
一般家庭が月30〜50件追加するとすれば、10年経っても元のアプリで問題なかった、とClaudeは結論づけた。通貨フォーマッターのキャッシュ以外の最適化は、「1万件対応」を明示的に要求されたから実装しただけだ、と明言している。この自制心こそが「シニアエンジニアらしい」とCaswellは評した。
実験から得られた教訓
Caswellが導いた結論は明快だ。「本番対応にして」という一発プロンプトより、役割を分けた複数回のレビューの方が見落としが少ない。
各ペルソナが異なる問題を見つけたという事実が、それを裏付けている。デバッグエンジニアは「動くか」を調べ、フロントエンドエンジニアは「人間が使えるか」を調べた。一つのプロンプトで両方を同時に深く掘り下げるのは難しい。ペルソナプロンプティングはその限界を分業によって補う手法として有効に機能している。
ただし、Claudeの利用上限（Usage Limit）には注意が必要だ。この実験では4回の長いやり取りが発生しており、Caswellは次回はプロンプトをまとめてリミットを節約することも検討している。
詳細はI gave Claude one app and asked it to act like four different senior developersを参照していただきたい。
