デジタルエンジニアリング部 Eビジネスエンジニアリング課の田原です。
最近携わったプロジェクトで、AIコーディングツールであるClaude Codeを活用しました。本記事では、実際のプロジェクトにおいてClaude Codeをどのように使ったのかを解説するとともに、便利だった点や改善の余地がある点を紹介します。
具体的には、以下の3つの場面での活用事例を取り上げます。
- モック画面の作成
- Amazon DynamoDBのテーブル設計
- Amazon Athenaのクエリ設計
AIツールの導入を検討している方や、実際のプロジェクトでの活用イメージを知りたい方の参考になれば幸いです。
モック画面の作成
やったこと
プロジェクトの初期段階で、画面のモックをHTML/CSSで作成する必要がありました。デザインの参考画像をClaude Codeに渡し、モック画面の生成を依頼しました。
便利だった点
参考画像を渡すだけで、短時間でHTMLベースのモック画面を生成してくれました。ゼロからHTMLやCSSを書く手間が大幅に省け、プロジェクト序盤のスピード感を高めることができました。
以下は、実際にClaude Codeへ渡した参考画像です。
※本記事で使用している画像は、実際の案件で使用したものではなく、説明用に別途作成したものです。
Claude Codeへは、以下のように参考画像のファイルパスを指定し、モックの生成を依頼しました。
改善の余地があった点
参考画像を渡すだけでモック画面を生成してくれる点は便利でしたが、最初に生成されたモックは参考画像と比べるとレイアウトや配色にズレがありました。特に、細かなUIパーツやアイコンの再現度は低く、調整が必要な状態でした。
以下は、最初に生成されたモック画面です。
対処法：段階的に指示を出す
最初の出力をベースに、修正したい箇所を一つずつ具体的に指示していくことで、徐々に参考画像に近いモックに仕上げることができました。
例えば、以下のように段階的に指示を出しました。
- 「サイドメニューの背景色を白にして、コンテンツの背景は灰色にして」
- 「サイドメニューの各文字は黒文字にして」
- 「統計カードの角丸を6pxにして」
- 「人気商品のテーブルは交互に白と灰色の背景にして」
このように、一度に完璧な出力を求めるのではなく、対話を重ねて段階的にブラッシュアップしていくことがClaude Codeを効果的に使うコツだと感じました。
以下は、段階的な指示を繰り返した後の修正済みモック画面です。
細部にはまだ修正の余地があるものの、サイドメニューの構成やカードのレイアウト、グラフやテーブルの配置など、おおむね参考画像と同じ構造のモックに仕上げることができました。
Amazon DynamoDBのテーブル設計
背景
プロジェクトでAmazon DynamoDBを使用することになりました。しかし、私自身はDynamoDBの設計経験がほとんどなく、パーティションキーやソートキーの設計、GSI（グローバルセカンダリインデックス）の活用方法など、知見がない状態でした。
AIとの壁打ちで設計を検討
Claude Codeに要件を伝え、テーブル設計について何度も対話しながら検討しました。
例えば、「ユーザーの操作ログを保存するテーブルを設計したい。ユーザーIDごとに時系列で取得したい」といった要件を伝えると、以下のようにパーティションキーやソートキー、GSIの設計方針を提案してくれました。
さらに、コスト面やパフォーマンス面の観点でも壁打ちを行いました。GSIを追加すべきかどうか、クエリの仕方によってコストがどう変わるか、ホットパーティションを避けるにはどうキーを分散させるべきかといった観点で、実運用を見据えた論点を整理して回答してくれました。
便利だった点
AIとの対話を通じて、自分だけでは気づけなかった設計上の考慮点を洗い出すことができました。具体的には、以下のような点が役立ちました。
- 設計の選択肢を素早く提示してくれる：「このアクセスパターンならキー設計はこう、別のパターンならこう」といった形で、複数の設計案を比較検討できた
- DynamoDB特有の考え方を学べた：RDBのように正規化するのではなく、「アクセスパターンからテーブル設計を逆算する」というDynamoDB特有の設計思想を、対話の中で自然に理解できた
- コスト試算の観点を得られた：読み込み・書き込み回数の見積もりや、ホットパーティションを避けるための考え方など、実践的な知見を得ることができた
改善の余地があった点
一方で、以下のような点には注意が必要でした。
- 要件の解釈が曖昧になることがある：「ログを保存したい」のような抽象的な指示だと、実際の業務要件とは異なるテーブル構成を提案されることがあった。具体的なアクセスパターンやデータ量を明示することで、精度が大きく向上した
- プロジェクト固有の制約を考慮しきれない：既存システムとの連携や運用上の制約など、プロジェクト固有の事情はこちらから補足する必要があった
学んだこと
DynamoDBのようなNoSQLデータベースは、RDBとは設計思想が大きく異なります。知見がない状態からでも、Claude Codeとの壁打ちを通じて設計の方向性を固めていくことができました。
ただし、AIの提案をそのまま採用するのではなく、プロジェクトの要件に合っているかを判断することが重要です。AIはあくまで「考える起点」を与えてくれるツールであり、最終的な設計判断はエンジニア自身が行う必要があります。
Amazon Athenaのクエリ設計
背景
DynamoDBと同様に、Amazon Athenaについても知見がない状態でプロジェクトに参加しました。Amazon Athenaは、Amazon S3上のデータに対してSQLでクエリを実行できるサービスです。
AIとの壁打ちで設計を検討
こちらもClaude Codeと対話しながら、クエリ設計やパフォーマンスの最適化について検討しました。主に議論したポイントは以下の通りです。
- コスト面：Athenaのスキャン量課金を抑えるため、パーティショニングや列指向フォーマット（Parquetなど）によるコスト削減策
- 処理速度：クエリのパフォーマンスを向上させるためのパーティション設計やファイルサイズの最適化
- データ構成：S3上のデータのディレクトリ構成とテーブル定義の設計
学んだこと
Amazon Athenaはスキャン量ベースの従量課金であるため、データの格納方法がコストに直結します。AIとの対話を通じて、以下のような実践的な知見を得ることができました。
- Parquet形式への変換によるスキャン量の削減
- 日付やカテゴリでのパーティショニングによるクエリ対象データの絞り込み
- 適切なファイルサイズ（目安として128MB以上）への分割によるクエリ速度の改善
Amazon DynamoDBの設計と同様に、知見がない領域でもAIとの壁打ちによって効率的に設計を進めることができました。
まとめ
本記事では、実際のプロジェクトにおけるClaude Codeの活用事例を3つ紹介しました。
AIツールは万能ではありませんが、対話を重ねることで学習と設計を同時に進められるという点で、特に知見のない技術領域への取り組みにおいて大きな力を発揮しました。
一方で、AIの出力をそのまま採用するのではなく、自分自身で内容を理解し判断する姿勢は欠かせません。AIはあくまでサポートツールであり、最終的な設計判断や品質の担保はエンジニア自身の責任です。
今後もAIツールを効果的に活用しながら、プロジェクトの生産性向上に取り組んでいきたいと思います。
