FDEが現場で最もよく使うAIツールは何ですか？

コーディング支援ではCursorやGitHub Copilot、ドキュメント整理ではClaude、ChatGPT、Geminiを用途別に使い分けるケースが多いです。最新の機能や料金は各ツールの公式情報で確認することを推奨します。

FDEはAIツールをクライアントのために使うのですか？

自分の作業を速くする目的もありますが、クライアントのリテラシー差を埋めるために使う視点が重要です。FDEはクライアントが自走できるよう、ツールの使い方ごとナレッジ移転することも役割の一つです。

Cursorはどんな場面でFDEに有効ですか？

クライアント現場でのプロトタイプ作成、既存コードベースへの機能追加、API連携の設計など、短期間で動くものを作る場面で特に効果が出ます。コンテキスト管理さえできれば、独力では数日かかる作業を数時間に短縮できます。

FDEが避けるべきAIツールの使い方はありますか？

クライアントの機密情報をプロンプトに含めたまま外部サービスに送信すること、AIが生成したコードや文章をレビューせずそのまま使うことは避けるべきです。ツールを使う責任はあくまで人間側にあります。

FDEが使うAIツール：現場で実際に使われる生成AI活用の実態

結論

FDEが現場で最も頻繁に使うAIツールは、コーディング支援の領域ではCursorやGitHub Copilot、会議・要件整理の領域ではClaude・ChatGPT・Geminiです。自分の手を速くするだけでなく、クライアントとの認識合わせや意思決定の速度を上げるためにも使います。道具の使い方ではなく、「いつ・なぜ使うか」を判断できることが、FDEのAI活用のポイントです。

FDEとは何かを基礎から確認したい方はFDEとは何か：企業に常駐するエンジニアの役割と仕事内容を参照してください。

FDEが使うコーディング支援AI

Cursorの現場での使い方

Cursorは、AIがコードベース全体をコンテキストとして参照しながら提案を出せる点が、従来のコード補完ツールと異なります。FDEが扱うのは、クライアントが持つ既存システムへの機能追加や、現場で急遽必要になった連携ツールの実装です。コードの全体像を把握しながら提案できるため、初めて触るコードベースでも短時間で作業を進められます。

具体的には次のような場面で使います。

クライアントの既存コードに新機能を追加するとき、@codebase機能でリポジトリ全体を参照しながらどこに何を書くか確認する
APIの設計について会議中にその場でサンプルコードを作り、議論の叩き台にする
エラーが出たとき、スタックトレースをそのまま貼り付けて原因と修正方法を聞く

注意点は、コンテキストウィンドウの管理です。大規模なリポジトリでは参照ファイルを絞り込まないと精度が落ちます。また、生成されたコードは必ず動作確認とレビューを挟みます。最新の機能や料金プランは公式情報で確認してください。

GitHub Copilotの使い方

GitHub Copilotは、テキストエディタに組み込まれたインライン補完として使います。Cursorほど会話的ではありませんが、コードを書きながら次の行を自動補完してくれるため、ルーティンな実装の速度が上がります。

FDEの現場では、テスト用のダミーデータを大量に生成したり、同じパターンのAPI呼び出しを繰り返し書くような場面で有効です。Copilotが提案するコードはあくまで参考であり、レビューなしにマージすることは避けるべきです。

議事録・要件整理でのLLM活用

会議後の構造化

FDEはクライアント現場での会議に毎日出席します。要件定義、進捗確認、課題共有と種類はさまざまですが、いずれも「何が決まり、何が宿題になったか」を短時間で整理する必要があります。

会議後に録音や手書きメモをLLMに渡し、次のような形式に構造化するのが典型的なフローです。

以下の会議メモから、
1. 今日決まったこと
2. 宿題（担当者と期日）
3. 次回の議題候補
を箇条書きで整理してください。

[会議メモ]
（ここにメモを貼る）

このプロンプトで出力したものをそのまま議事録に使うのではなく、ファクトチェックと言葉の確認を挟みます。LLMが補完した内容が実際の発言と異なる場合があるためです。

要件の曖昧さを検出する

FDEがLLMを使う場面で、見落とされがちなのが「要件の穴を発見するために使う」ユースケースです。クライアントから受け取った要件定義書や仕様書をLLMに貼り付け、「曖昧な箇所や前提が不足している箇所を指摘してほしい」と依頼します。

LLMは文章の矛盾や前提の欠如を指摘するのが得意です。人間が読んで気づかなかった「この条件が満たされないケース」「このエラーハンドリングが未定義」といった点を、会議の前に把握できます。

プロンプトエンジニアリングの詳細はFDEのプロンプトエンジニアリングで説明しています。

プロトタイプ生成とUI作成への活用

v0・Lovelace・Bolt等の活用場面

FDEはプロダクトマネージャーと協力してクライアントに機能のデモを見せることがあります。このとき、デザイナーがいなくてもUIのプロトタイプを作れるツールが役立ちます。

Vercelが提供するv0やBoltのようなプロンプトからUIを生成するツールは、「こんなダッシュボードが欲しい」という会話をそのまま入力して、数分で動くUIコンポーネントを得られます。生成したコードはReactベースのもので、そのまま既存プロジェクトに組み込める形で出力されます。

具体的な使い方は次の通りです。

クライアントへのヒアリング内容を箇条書きにまとめる
v0に「このデータを表示するダッシュボードを作って」と入力し、箇条書きを貼る
出力されたコードを自分のNext.jsプロジェクトに貼り付けて動作確認する
クライアントに見せてフィードバックを取る
フィードバックをもとにプロンプトを修正して再生成する

このサイクルを1日で2〜3周回せることが、FDEがプロトタイプを素早く出せる理由です。ただし、生成されたコードをそのままプロダクション環境に使うことは推奨しません。

データ分析・可視化での生成AI活用

Pythonコード生成とデータ探索

クライアントの現場では、CSVやExcelで管理されているデータを可視化してほしいという依頼が頻繁に発生します。FDEはこのとき、データの構造をLLMに説明してPandasとMatplotlibのコードを生成させる方法を使います。

次のCSVの列名と型です。
- date: 日付（YYYY-MM-DD形式）
- sales: 売上金額（整数）
- region: 地域名（文字列）

月次・地域別の売上推移を折れ線グラフで表示するPythonコードを書いてください。
seabornを使い、凡例は日本語で表示してください。

このプロンプトで生成されたコードはほとんどの場合そのまま動きます。動かないときはエラーメッセージをそのままLLMに渡して修正を依頼します。FDEが自分でPandasのドキュメントを調べるより、この往復の方が速いケースがほとんどです。

分析結果の説明文生成

可視化できたグラフをクライアントに説明するとき、数字の読み方をLLMに補助させることもあります。「このグラフから読み取れることを3点で説明して」という依頼をすると、説明文の骨格を得られます。ただし、数字の解釈に事業文脈が必要な部分はLLMの出力をそのまま使うと誤解を生むため、必ず人間が確認と修正を行います。

クライアントへのAIリテラシー移転ツールとして使う

FDEの役割は、自分が速く動くことだけではありません。クライアントが自走できる状態を作ることも重要な仕事です。AIツールの活用においても同様で、「FDEがいなくなってもクライアントが使い続けられるか」という視点を常に持ちます。

この視点から、FDEがよく行うのは次の3つです。

プロンプトをドキュメント化して渡す 効果があったプロンプトをそのまま渡しても、クライアント側が「なぜこう書くのか」を理解しないと応用できません。プロンプトに注釈を付けて、変えてよい部分と変えてはいけない部分を説明したドキュメントにして引き渡します。

ツールを選ぶ基準を説明する 「このタスクにはこのツール」という答えを渡すのではなく、「精度を求めるならClause、速度を求めるなら別のもの」というトレードオフの判断基準を共有します。ツールはアップデートされるため、今の答えより判断基準が長く使えます。

失敗事例を共有する クライアントが自分でAIツールを試してうまくいかなかった事例を一緒に振り返り、なぜうまくいかなかったかを分析します。「AIに全部投げてはいけないパターン」を経験から学んでもらう機会として使います。

FDEに必要なスキルセット全体についてはFDEに必要なスキルセットで詳しく解説しています。

FDEが避けるべきAIツールの使い方

AIツールを現場で使うとき、技術的な能力より判断の誤りで問題が起きます。FDEが現場で意識する「やってはいけないこと」を整理します。

機密情報を無制限に外部サービスに送る

クライアントの未公開情報、個人情報、契約内容をプロンプトに含めて外部のLLMサービスに送信することは、契約違反や情報漏洩につながります。どの情報がどのポリシーのもとで送信可能かを事前に確認します。企業向けのAIツールにはデータを学習に使わないオプションがある場合がありますが、最新のポリシーは各サービスの公式情報で確認が必要です。

生成物をレビューなしに使う

LLMが生成したコードは動いているように見えても、エッジケースで壊れる実装をすることがあります。LLMが生成した文章は正確に見えても、事実誤認を含む場合があります。生成物をそのまま使うことを習慣にすると、ある時点で大きなミスにつながります。FDEは「生成して確認する」というサイクルを崩さないことを徹底します。

コンテキストを与えずに汎用的な質問をする

「この機能を実装するには？」という質問より「既存のUserAuthクラスを継承し、JWTを使ったセッション管理を追加するには？」という質問の方が使える回答が返ります。コンテキストが薄いプロンプトは、LLMが持っている一般知識の平均を返すだけで、現場に固有の問題解決には使えません。

答えが出るまで依存し続ける

LLMが答えを出せないとき、プロンプトを変えて繰り返しても解決しない場合があります。AIが不得意な問題タイプ（特定の数値計算、最新情報の参照、実行環境への直接アクセス）を見極め、別の手段に切り替える判断も重要です。

AI時代のFDEのあり方についてはAI時代のFDEで詳しく解説しています。

まとめ

FDEのAIツール活用は、単に作業スピードを上げるためではありません。クライアントとの認識合わせを速くし、プロトタイプで議論の質を上げ、クライアント自身が使い続けられる土台を作る手段として使います。

道具は増え続けていますが、「何のために使うか」を明確にする判断がなければ、ツールの数だけ混乱が増えます。現場で役立つのは、最新のツールを知っていることより、今この場面でどのツールをどう使うかを即断できる力です。

各ツールの最新機能・料金・プランは変更されることがあるため、使用前に公式サイトで確認してください。