私はクロードに1つのアプリを与え、4人の異なるシニア開発者のように振る舞うよう頼んだ。その結果はこうだ。

特にXなどのオンラインプラットフォームでは、チャットボットをより効果的にするという主張が数多く見られます。AI教育の専門家であるDavid Max氏の主張を初めて目にしたとき、私は懐疑的でしたが、まさにそれが試してみるきっかけとなりました。これらの主張は、Claudeを上級デバッガーからパフォーマンスエキスパートまであらゆるものに変身させるというものです。私が調査することにした際に何が起こったのか、以下に説明します。より効果的な主張に興味がある場合は、アイデアを開発し生産性を向上させるための7つの効果的なClaude 4の主張をご覧ください。

Claude の私の家計支出トラッカーをご覧ください

私は既にChatGPT Workを使って経費プレースホルダー付きの一般的な経費トラッカーを作成していたので、それを使ってから、クロードにアプリケーションを4回レビューしてもらいました。レビューのたびに、フルスタックエンジニア、デバッグエンジニア、フロントエンドエンジニア、パフォーマンスエンジニアという異なる主要なエンジニアリングの役割を彼に割り当てました。

その結果は、単にクロードに「アプリを改善してください」と頼むよりもはるかに多くのことを明らかにした。それぞれの登場人物は異なる問題点に焦点を当て、時には前の「開発者」が見落としていた問題を発見することさえあった。以下に、何が起こったのか、そして彼らがどのような主張をしたのかを紹介する。

1. 上級フルスタックエンジニアがアプリケーションを構築した。

すべては、誰でも使えるインタラクティブな家計支出トラッカーを作成してほしいというクロードからの依頼から始まった。クロードのアプリ開発機能の詳細については、「クロードとジェミニを使って3つのアプリを数分で作成しましたが、そのうちの1つには隠し機能があります」をお読みください。

課題：誰でも使える、家計支出を記録し理解するためのインタラクティブな家計支出トラッカーを作成すること。支出の追加・削除、カテゴリの割り当て、取引のフィルタリング、合計支出額の計算、カテゴリ別の視覚的な内訳表示などの機能を含めること。

スタートアップ企業向けに洗練されたMVP（最小実行可能製品）を開発する、経験豊富なフルスタックエンジニアになったつもりで考えてみてください。コードを書く前に、アーキテクチャ、データ構造、ユーザーフローの概要を簡単に説明してください。その後、アプリケーションをクラウドアーティファクトとして構築します。

レスポンシブで使いやすいデザインにしてください。ただし、最終コードのレビュー、デバッグ、改善に余分な時間を費やさないでください。それらの作業は他の開発者に任せます。

クロードは驚くほど洗練されたReactアプリを作成した。サンプル取引、支出合計、カテゴリランキング、検索・フィルタリング機能、日付による取引の並べ替え機能などが備わっていた。さらに、変更内容が保存されるため、アプリを再度開いた後も変更内容が保持される仕組みになっていた。

一見したところ、それは未完成の試作品というより、完成品に近いように見えた。上部には統計カードがあり、すっきりとした経費精算書、そして各項目でどれだけの金額が使われたかを示す色分けされた棒グラフが配置されていた。

2. 上級デバッグエンジニアがいくつかの問題を発見した。

その後、私はクロードに外見は気にせず、アプリケーションのローンチ準備を行うデバッグエンジニアとしての自身の仕事ぶりを検証するように頼んだ。

要求事項：今こそ、このアプリケーションが一般公開される前に引き継いだチーフデバッガーのように行動せよ。

アプリケーションとその既存コードを、本来の機能やビジュアルデザインを変更せずに注意深く検証してください。主要なユーザーフローをテストし、機能エラー、無効な入力処理、データ損失のリスク、計算ミス、永続性の問題、およびエッジケースを探してください。

コードを修正する前に、テスト内容、発見した問題、各問題の根本原因、各問題の深刻度、および推奨する修正方法を記載した簡単なデバッグレポートを提出してください。

次に、修繕を実施し、元の機能が引き続き正常に動作することを確認してください。外観のデザイン変更、大規模な建築改修、または単なる表面的な変更は行わないでください。

デバッグ作業によって、多くの深刻な問題が明らかになった。

例えば、元の入力形式が適切ではありませんでした。「取引を保存」ボタンをクリックすると正常に動作しましたが、Enterキーを押しても動作しない場合がありました。クロードはこの問題を解決するため、該当箇所を送信ボタン付きの適切な形式に変換しました。

また、ユーザーが履歴を消去して、無効な日付情報を含む取引を保存できることも発見した。クロードは日付検証機能を追加し、無効な金額のチェックを強化し、トラッカーが空の場合にも「住宅」が最大のカテゴリとして表示される計算ミスを修正した。

ワンクリックでトランザクションを完全に削除できてしまう問題が依然として残っていた。ストレージエラーは開発者コンソールに表示されず、ユーザーは情報が保存されたと思い込んでしまう可能性があった。さらに、Claudeは修正が正しく機能していることを確認するための自動テストを実施していなかった。

3. 経験豊富なフロントエンドエンジニアは、全く異なるアプリケーションに気づいた。

第3ラウンドでは、クロードに、経費トラッカーをレスポンシブデザインとアクセシビリティを専門とするフロントエンドエンジニアとして扱うよう依頼しました。

求められていること：今すぐ、アクセシブルでレスポンシブな消費者向けアプリケーションを専門とする、経験豊富なフロントエンドエンジニアのように行動してください。

スマートフォン、キーボード、または補助機器を使って支出管理ツールを利用するユーザーの視点から、現在のツールを見直してください。機能性と全体的なデザインは維持しつつ、使いやすさとアクセシビリティを向上させましょう。

コードを変更する前に、携帯電話の動作と応答性、キーボード操作、フォームの使いやすさ、スクリーンリーダーのアクセシビリティ、色のコントラスト、読み込み状態とエラー状態、破壊的な操作、および分かりにくいコントロールについて、簡単なレビューを実施してください。

次に、改善策を実施します。すべての入力フィールドとインタラクティブコントロールに分かりやすい名前が付いていること、フォーカス状態が明確に表示されること、確認メッセージがスクリーンリーダーで読み上げられること、支出明細が色付きのバーだけに頼らずに情報を伝えることができることを確認してください。

これは、その実験に関する最も包括的なレビューだった。

クロード氏は、このアプリが選択された入力フィールドの周囲の自然な境界線を削除し、代替となる境界線を提供していないことを指摘した。そのため、キーボードを使って操作するユーザーは、アクティブなフィールドを見失いやすくなるという。

また、視覚的なラベルが対応する入力フィールドに適切にリンクされていないこと、検索フィールドがプレースホルダーテキストのみに依存していること、および検証エラーがスクリーンリーダーによって読み上げられるように設定されていないことも判明した。

クロードは、視覚的なフォーカスインジケーターを復活させ、ラベルをフォームコントロールにリンクさせ、スクリーンリーダーの説明を追加し、多くの薄いグレーのテキスト要素のコントラストを高めました。また、検索バーを小型画面でより柔軟に操作できるようにし、アイコンのみを含むボタンにはより分かりやすいラベルを追加しました。

最も重要なのは、この人物がデバッガーが見落としていた削除に関する問題を発見したことだ。クロードはワンクリックで削除できるボタンを、ユーザーがトランザクションを削除するか保持するかを選択する2段階の確認プロセスに変更した。

すべての主張が完璧だったわけではない。クロードはタッチターゲットの最小サイズを44×44ピクセルと説明したが、メインの削除ボタンを36×36ピクセルに拡大しただけだった。これはWCAG 2.2 AAのより小さな目標には達しているが、彼が言及した44ピクセルの推奨には達していない。

しかし、クロードの役割が変わると、その視点も明らかに変化した。デバッガーはアプリケーションが正しく動作しているかどうかを確認する一方、フロントエンドエンジニアは実際のユーザーが快適に使用できるかどうかを検証した。この実験は、たった一つの要件がクロードの成果にどれほど大きな影響を与えるかを示している。

4. パフォーマンスエンジニアは、そのアプリケーションはそれほど多くの支援を必要としていないことを認めた。

最後に、私はクロードに、少なくとも10,000万件の取引を処理できる経費追跡システムを設定するよう依頼した。

募集内容：シニアパフォーマンスエンジニアとして、数千件の取引を処理できる経費トラッカーを準備してください。

現在の実装を分析し、不要なレンダリング、冗長な計算、非効率的なソートやフィルタリング、ストレージのボトルネック、メモリの増加、データサイズの増加に伴って遅くなる可能性のあるインタラクションなどを特定する。

パフォーマンスに問題があると決めつけないでください。少なくとも10,000件のトランザクションでアプリケーションをテストする現実的な方法を作成し、重要な操作のベースラインを確立してください。

そして、分析によって正当化された改善点のみを実装してください。アプリの外観、アクセシビリティの向上、および現在の動作は維持してください。速度の改善を主張する場合は、実際に測定するか、期待される改善として明確に定義してください。

クロードは特に深刻なボトルネックを発見した。アプリケーションは金額を表示するたびに新しい通貨フォーマットオブジェクトを作成していたのだ。10,000万行のデータで、クロードはこの処理に349ミリ秒かかっていた。単一のフォーマッタを再利用することで、処理時間は5.2ミリ秒に短縮され、クロードはこれを67倍の改善と算出した。

クロード氏はまた、「テーブル仮想化」機能を追加しました。これは、ブラウザが一度に何千行ものトランザクションを表示するのではなく、現在画面に表示されているトランザクションのみを表示することを意味します。検索とストレージの更新は、キー入力や素早い変更のたびに発生するコストのかかる繰り返し処理を避けるため、ほんの一瞬だけ遅延されます。

クロードはさらに、ストレステスト用に1,000件、10,000件、または50,000件のサンプル取引を生成できるボタンも追加した。

しかし、報告書の中で最も説得力のある部分は、クロードがこれらの改良点のほとんどが、アプリケーションの本来の目的には必要ではなかったと認めた点だった。

一般的な家庭では、月に30～50件の取引が発生する可能性がある。10年経っても、クロードは、元のアプリケーションでも大きな問題なくデータ処理ができたはずだと結論付けた。通貨フォーマッタのキャッシュを除けば、ほとんどの改善は、私が数千件の取引への対応を具体的に要求したからこそ役立ったのだ。

この抑制（あるいは自制）は、単に変更できるからという理由だけで変更を行うよりも、「成熟した」「プロフェッショナルな」態度のように思えた。

私の最終結論

これらの主張は非常に効果的だと感じました。それぞれがクロードの長所と短所を明確に示していたからです。それぞれの役割が独自の視点から評価を提供しており、大変参考になりました。今後、他のアプリやウェブサイトのレビューを行う際にも、ぜひ活用していきたいと思います。

デバッグエンジニアは不具合を発見したが、フロントエンドエンジニアはアクセシビリティとユーザビリティの問題を発見した。一方、パフォーマンスエンジニアはデータ量の増加がもたらす影響を考慮し、最適化が不要な場合を認識した。

この経験を通して、「本番環境に対応できるようにしてください」といった包括的な要求を一つだけ出すことが必ずしも最善策ではない理由も明らかになった。要求が包括的に見えても、一度のレビューでは重要な問題を見落としてしまう可能性があるのだ。作業を段階的に細分化することで、クロードは対処すべき優先事項を減らし、結果の評価を容易にすることができた。

クラウドの使用制限には注意してください。次回は、最大使用制限に達しないように、プロンプトをまとめて使用してみようと思います。

---

---