目次／ツール／ AI活用

AIコーディング・実装支援

項目番号 135

AIコーディング支援とは、エディタやIDEに統合された形で、コードの補完・生成・修正・説明を行うツール群のことです。既存のコードを読ませて「ここは何をしているのか」を説明させたり、指示から実装を書かせたりできます。

ディレクター・PMにとって重要なのは、自分でコードを書けるようになることではありません。「エンジニアが何に困っているかが分かる」「小さな検証を自分で回せる」「仕様の実現可能性に当たりが付く」——この3つです。

言葉だけで仕様を詰めていると、認識のズレは最後まで残ります。ところが、動くものが数分で出てくると、議論が具体になります。

「この画面遷移でいいか」を文章で確認するより、動くプロトタイプを触ってもらうほうが早く、正確です。これは 028 UI設計（ワイヤーフレーム・プロトタイプ作成）や 049 要件定義の質に直結します。

もうひとつ、エンジニアとの会話が変わります。「これ何ピクセル？」「この実装、どのくらい大変？」といった質問の前に、自分で読んで当たりを付けられるようになると、確認の往復が減ります（045 フロントエンドエンジニアとのコミュニケーション）。

使う場所を限定する：ディレクターが使うのは、検証・プロトタイプ・調査の範囲です。本番のコードベースに直接手を入れるのは、レビューとテストのプロセスに乗る前提でのみ行います。
「動いた」と「正しい」は違う：AIが出したコードは、画面上は動いていても、セキュリティやパフォーマンスの観点で問題を抱えていることがあります。品質の責任はツールではなく、人とプロセスにあります（066 コーディングチェック、071 情報セキュリティ・個人情報の取り扱い）。
クライアントの資産を入れない：既存サイトのソースや、未公開の仕様書を安易に読み込ませないこと。何を入れてよいかは、案件ごとに先に決めます。
エンジニアの領分を侵さない：「AIで作れるんだから安くできますよね」は、もっともやってはいけない使い方です。検証が速くなるのと、実装の責任を持てるのは別の話です。

いきなり案件のコードに触るのではなく、自分の業務ツールを作るところから始めるのが安全です。スプレッドシートの集計を自動化する、議事録を整形する、ダッシュボードのHTMLを作る。壊れても誰も困りません。

そのうえで、エンジニアにレビューしてもらう機会を1回作ると、自分の書いたものの粗さが分かります。この経験が、実装側の見積もりを読む力になります。