この記事の対象読者
- これから AI 活用をはじめようと思っている方
- 社内で上司から AI 活用のお達しを受けて、「なんとかせねば…」と頭を抱えている方
この記事に書いてないこと
- AI に関する細かな設定やセキュリティに関する技術的な内容は書きません。
(そのあたりは今後別記事として公開予定です。)
はじめに
GiftX では、GIFTFULやGIFTFUL for Businessという自社プロダクトの開発を行っています。
現在、これら2つのプロダクトを、開発者1名と副業メンバー1名のサポート体制で、新機能開発から運用・保守まで行っています。
今回は開発チームの中でどのように AI 活用しているかを紹介しようと思います。
プロダクト開発の工程内で特に活用しているシーンを知っていただき、似たような業務に導入できるか参考になれば嬉しいです。
主な活用ツール
現在一般的に公開されている AI ツールはたくさんありますが、主に利用しているのは以下のツールです。
- Claude Code (エージェント系)
- Gemini (カジュアルな調べ物系)
- GitHub Copilot (エディタ上のコード補完 / GitHub 上のコードレビュー)
- NotebookLM (情報源を絞った調べ物系)
これらを利用するのに特別、個人的なこだわりがあるわけではないです。
普段利用されている or 社内で規定されている似たような役割のツールを活用するでもいいと思っています。
利用シーン① - 設計の壁打ち相手としての AI 活用
どう使っているか?
作りたいものがある程度決まればいきなりコードを書き始められる…わけではありません。
既存の機能との関係性や今後の拡張の方向性など過去や少し先の未来を考慮した上で、実際にどのように作っていくかを設計する必要があります。
これまでは、あーでもないこーでもないと悶々と試行錯誤を行っていました。
あいまいな記憶を頼りに、ドキュメントや公開資料を引っ張ってきてまた考える。
基本的な流れは変わらないのですが、NotebookLM を使って情報ソースをアップロードしておくとアップロードしたリソースをベースに設計の相談が可能です。
特に気に入っているのは、AI が返してきたアウトプットの中に引用元のリンクがちゃんと記述されることです。
より深く調査したい場合は、引用元へ飛ぶことで詳細のキャッチアップが可能です。
また、設計の段階で検討したい方向性が複数あり、どちらで進める方がいいか悩むケースはよくあるのではないでしょうか。
例えば 2つの方向性で迷った時に Claude Code を利用して、実際に 2つの方向性で実装させてしまいます。
そのアウトプットや Claude が確認を求めてきたところ、イメージと違ったところを確認することで、事前にハマりどころの確認や決めておきたいポイントを設計の段階で行うことができます。
これまでは、想像で補完するしかなかったところに具体的なコードを見て判断するという手段が使えるようになりました。
DB設計やライブラリの選定や更新などの大きな味方です。
利用シーン② - プログラミングのパートナーとしての AI 活用
どう使っているか?
主にここでは Claude Code と GitHub Copilot を利用しています。
プログラミングを行う時、タスクは実装イメージの解像度の高低とコーディングの規模の大小という軸で分類できると思います。
実装イメージの解像度とはアウトプットになるプログラムのコードがどれくらいイメージできてるかという意味で使っています。
例えば、サンプルコードや構造的に似たような業務知識を含むコードがライブラリのドキュメントやプロジェクト内のソースコードに存在すれば「実装イメージの解像度が高い」とします。
四象限で分類すると
- 実装イメージの解像度-高 x コーディング規模-大
- 実装イメージの解像度-低 x コーディング規模-大
- 実装イメージの解像度-高 x コーディング規模-小
- 実装イメージの解像度-低 x コーディング規模-小
のような形になります。
ではそれぞれタスクの具体例と利用方法を説明していきます。
実装イメージの解像度-高 x コーディング規模-大
- 新機能開発-既存機能の延長や拡張系
- ライブラリの更新/乗り換え
といったタスクが当てはまると思います。
これらのタスクは、ライブラリ側では移行のガイドが用意されていたり、GIFTFUL の業務知識や処理を含んだコードがプロジェクト内にすでに存在するため、ほとんど Claude Code で実装を進めてしまうことが可能です。
一気に投げることも可能かもしれませんが、個人的にはある程度の境界を区切り生成されたアウトプットのレビューを行っていくのが変更の意図の理解もしやすいです。
境界に関しては、やりたいことのパターンの数にもよりますが、フロントエンド/バックエンドという大きな区切りのこともあれば、フロントエンド/バックエンドを分けた上で、それぞれ 3,4階層くらいに分けます。
例えばバックエンド側が複雑な実装になりそうであれば、モデル/ビュー/コントローラーといった層に分割するように進めます。
特に意識しているのは、それぞれの層で参考にしたいコードを @ で直接リファレンスしながら指示することです。
そうすれば、 Claude Code の調子が悪く、賢いモデルが利用できない場合でも安定したアウトプットが得られるようになります。
このタスクではファイルの変更も多くなるため、実装がひと通り落ち着いた後に GitHub 上で Copilot にコードレビューを投げることも多いです。
AI の利用に関わらずいろんなタイミングと観点でレビューを挟むこととテストコードを用意することで、ソフトウェア品質の低下を防いでいます。
実装イメージの解像度-低 x コーディング規模-大
- 新機能開発-新しい業務知識を含む系
- 大規模なリファクタリング
- 使わなくなった機能やコードの削除
- ライブラリの新規導入
といったタスクが当てはまると思います。
こちらのタスクを進めるためにはまず解像度が低い状態を高い状態へ上げていくことが必要です。
まずはお手本になるようなコードの一部分を自分で実装することになります。
この時は GitHub Copilot を搭載したエディタでゴリゴリコードを書くことが多いです。
ある程度コードを書きながら自分のイメージを崩さない範囲で提案を投げてくれるため、すべてを自分で記述するよりも早く試行錯誤が可能です。
このような流れで、お手本にできそうなコードを記述し、実装イメージの解像度が上がった後は、Claude Code にお任せします。
ここから先は↑のセクションと同じです。
実装イメージの解像度-高 x コーディング規模-小
- 不具合対応 x 原因がハッキリした
- 小さめのリファクタリング
といったタスクが当てはまると思います。
不具合対応であれば、最初は原因がわからず調査フェーズがありますが、その結果コーディング規模が小さく、実装イメージもハッキリしている場合、さくっとエディタ上の GitHub Copilot で実装をしてしまいます。
大きくなりそうだったら、途中から Claude Code へお任せです。
実装イメージの解像度-低 x コーディング規模-小
- 不具合対応 x 原因がハッキリしない/再現しない
といったタスクが当てはまります。
こちらも調査フェーズがあります。
報告からコードをざっと読み込んでみて原因がハッキリしない/不具合が再現しないケースでは、できるだけ Claude Code の賢いモデルを活用して調査を行います。
実際に不具合がある報告の導線をひと通り確認してもらいます。
GIFTFUL は Webサービスなので、不具合のあったページの URL を渡し、症状を説明して当たりの候補を出してもらいます。
原因らしきものが出力された場合も根拠の説明はしっかりお願いしましょう。
あくまで AI のアウトプットは確率ベースのものなので、それっぽい説明を鵜呑みにせずに根拠やサンプルコードを確認して不具合の修正を行います。
不具合対応の場合はコーディング規模が小さいものを想定してきましたが、不具合対応を調査した結果、コーディングの規模が大きいとなった場合は、設計の見直しなどから始める必要があるかと思います。
利用シーン③ - テスター&QAエンジニアとしての AI 活用
どう使っているか?
ここは開発内でも最近取り組みはじめた活用方法です。
ここでも主に Claude Code を活用します。
単体テストや結合テストの自動化はこれまでも行っており、ほとんどコードを書くのと同様の手順で作成が可能です。
これらのテストももちろん大切ですが、+αとしてユーザーが実際に操作するブラウザ上でどう動いているのか確認できると安心感はさらに増します。
このようなテストは E2E(エンドツーエンド) テストと呼ばれています。
そのようなテストができるならやったらいいじゃん!と誰しも考えると思います。
しかし、実際はなかなか導入しにくいのが現状です。
理由は、大きく2つあり
- E2Eテストのコードを作る負荷が高いこと
- テストが壊れやすいこと
です。
E2Eテストのコードを作る負荷が高いこと
この場合の負荷というのは、タスクの技術的な難易度が高いケースももちろんありますが、細かい作業をずっと続ける胆力( +時々職人的な微調整 )が必要になるケースという意味合いです。
ブラウザ操作を自動化するためには、Webサービスにアクセスした時に返却される様々なテキストデータを解釈し、Aというリンクを押し、B1を押すと出てくるB2を押し、最後にCというデータを送信する、というプログラムを記述する必要があります。
文字で書くと簡単ですが、そもそもページ内にたくさんあるリンクをどのように特定するのでしょう、またB1を押すとB2がすぐ出てくるとは限らず、一定時間待つ必要もあるかもしれません。
自身がブラウザの操作を記録しコードとして吐き出すような仕組みもありましたが、出力される E2Eテストのコードが具体的過ぎる、間違えた操作を記録してしまうなど中々使い勝手がよくなかったりしました。
このように E2E テストを動作させるためのプログラムを作成することはなかなか一筋縄ではいきませんでした。
テストが壊れやすいこと
自動テストに期待することは、自分が書き換えたプログラムに対して、テストが通ったり/落ちたりすることです。
E2E テストでは、作用するリソースがどうしても多く、何もしなくてもテストが落ちるというケースがどうしても発生します。
機能変更などで心当たりがある場合でも、E2Eテストのプログラムを修正するのは前のセクションで記述した通りなかなか面倒な作業ですし、何もしなくても落ちることが多ければオオカミ少年を見るような気持ちになります。
変更が一部であれば問題ありませんが、UI を大幅に変更するようなケースでは、ほとんどの E2Eテストを再びゼロから作成することになってしまいます。
このように運用・保守していく上であまりにも工数がかかってしまうということがありました。
AI エージェントにE2Eテスターを任せる(※利用時は注意事項あり)
以上のような課題がありましたが、GiftX では Claude Code と Playwright CLI というツールを組み合わせることで、これらの課題の解消ができそうなので取り組んでいます。
Playwright というツールはブラウザを操作し E2E テストを行うためのツールです。
このツール自体は AI が広まる以前から存在するものです。
Playwright が指定する文法に則ってプログラムを記載して実行すると、一連のブラウザ操作の流れを代行してくれるものです。
Playwright CLI はこれのコマンドライン版で、プログラムをファイルに書き出さなくても逐一実行&ブラウザで表示されているコンテンツを返却してくれるというものです。
また、いくつかプリセットで用意されているスキルを活用することで、Claude Code がブラウザの操作と結果の確認をスムーズに行えるようになります。
動作の流れはこうです。
- 人: Claude Code を起動
- 人: ブラウザ操作の指示出し「サイト https[:]//giftx.co.jp へ移動しお知らせページへ遷移してください」
- Claude: Playwright CLI を利用し指示を実行
- Claude: ブラウザを操作し指示が必要になれば人へ戻す
- 人: 次の指示 or E2Eテストの吐き出し
Claude Code を経由してから実行させることで、日本語で指示出しを行いながらブラウザを操作、ある一定の粒度でE2Eテストとして切り出しを行います。
例えば、サインインなどの処理は毎回実行するのではなくて、1つのタスクとして切り出しておいた方が、他のテストにつなげる時にも便利です。
テストコードとして書き出すのは、ブラウザ操作の処理手順として正確に記録するためです。
日本語などの自然言語で出した指示を渡しても毎回 Claude Code が同じように解釈してくれない可能性の方が高いですし、余計な指示による曖昧さがなくなります。
さらに便利なのは、記述した E2Eテストが失敗した時です。
必要であればテストを修正したり、再実行や読み込み待ちをよしなに調整してくれます。
流れはほとんど同じですが、Claude Code を起動した後に E2Eテストを呼び出すことで勝手に実行を進め、リトライや改善提案を行ってくれます。
- 人: Claude Code を起動
- 人: E2Eテストを起動するコマンド(npm run testなど)の実行を指示
- Claude: テストを実行
- Claude: 失敗すれば、内容によって試行錯誤をしてくれる。修正提案や勝手に改善してリトライ
- 人: 次の指示 or テスト終了
動画内ではテストコードのフィルタ名を「メディア掲載」 => 「メディア掲載hogehoge」 にわざと変更し最初に失敗するように調整しています。
このような流れでClaude Codeを活用できれば、E2Eを行う際のデメリットのおおよそが解消されるのではと感じています。
まとめ
ここまで、GiftX の開発チームでの AI 活用を 3つの利用シーンに分けて紹介してきました。
- 設計の壁打ち相手: NotebookLM で情報ソースを絞った相談を行ったり、Claude Code に複数の方向性を実際に実装させて判断材料にする
- プログラミングのパートナー: 実装イメージの解像度とコーディング規模の 2軸でタスクを捉え、Claude Code と GitHub Copilot を使い分ける
- テスター: Claude Code と Playwright CLI を組み合わせ、これまで導入しにくかった E2E テストの運用・保守のハードルを下げる
振り返ると、どのシーンでも共通しているのは「AI にすべてを丸投げするのではなく、人が判断したいポイントを残しながら役割分担している」という点です。
設計では最終的な方向性を、コーディングでは変更の意図やレビューを、テストではどこを切り出すかを、人が握り続けています。
AI のアウトプットは確率ベースのものなので、根拠の確認やレビュー、テストといった品質を担保する工程を省かないことが、結果的に開発を速く・安全に進めるコツだと感じています。
まずは身近な業務の一部分から、AI を相棒として迎え入れてみてはいかがでしょうか。
GiftXは、社内での AI 活用を促進するための支援サービスを用意しています。
「うちでもやってみたい」と思ったら、ぜひ気軽に声をかけてください。
※注意事項
- ブラウザを AI エージェントで操作する話がでてきますが、普段使いのPC上で実行することはオススメしておりません。許容するリスクによりますが、安全性を重視する場合は別端末や仮想環境の利用を推奨しています。
- 自社管理のサービスに対するアクセスのみの用途に利用してください。アクセス間隔を調整したり、基本的なクローリング/スクレイピングのお作法を守りましょう。
参考リンク
Claude の @ を使ったファイルやフォルダのリファレンスについて
https://code.claude.com/docs/ja/memory#import-additional-files
他にも Claude Code のメモリ活用のための知見が色々記載されているのでオススメです!
Playwright の公式サイト
https://playwright.dev/
Playwright CLI のリポジトリ
https://github.com/microsoft/playwright-cli
https://github.com/microsoft/playwright-cli/tree/main/skills/playwright-cli
