作って終わりにしないAI開発──理解から始まるClineとの開発のかたち

こんにちは、フロントエンドエンジニアの小林です。

開発の現場でAIツールを活用する動きが加速する中で、「実際どう使えばいいのか分からない」「便利だけど、ブラックボックス感があって不安」という声も少なくありません。 私自身、ある社内業務効率化ツールの開発に携わるなかで、AI支援型のコーディングツール「Cline」を導入し、“コードを理解すること”からAI活用を始めてみることにしました。

結果として得られたのは、実装スピードや正確性の向上だけでなく、AIと対話しながら構造を学び、自分の思考を深めていく新しい開発体験でした。

PIVOT社内では、AIの活用を積極的に推奨しています。

たとえば、

• セキュリティを遵守した上でのChatGPT全社導入
• Microsoft Teams上に「AI相談室」を設置し、誰もが気軽にAI活用を相談できる環境の整備

といったように、人とAIが協働する文化を組織全体で支援する取り組みが進んでいます。

本記事では、そうした文脈の中で私が体験した「作って終わりにしないAI開発」のリアルと、そこから得た気づきをご紹介します。

「Cline」は、自然言語からコードの提案・補完をしてくれるAIプログラミング支援ツールです。ChatGPTのように対話形式で使うことができ、プロンプトに対してコード例を生成してくれます。VSCode上でエディタと連携し、コードの自動生成・修正提案・バグ検出支援などができます。

ClineはAPIを介して大規模言語モデル（LLM）と接続ができ、今回の開発ではAnthropic社の「Claude 3.7 Sonnet」を使用しました。「Claude 3.7 Sonnet」はプログラミングに優れたLLMで、既存のコードベースの解析や、仕様に応じた実装提案において高い精度を発揮します。

今回のClineの利用は社内案件を対象としたものであり、クライアント案件には使用しておりません。また、Clineが接続しているAIモデルについても、開発元の公式ドキュメントにおいて次のように記載されています。

やり取りした内容がモデルの学習に使われることはないため、業務上のデータを含む利用であっても情報漏洩のリスクは極めて低い設計となっています。

社内の業務効率改善を目的にしたツールの一環で、特定の操作に対するモーダルの導入が求められました。要件は次のようなものでした。

• 「メディアを追加」ボタンを押す
  → ユーザーが画像や動画をアップロードできる
• 添付したメディアを選択する
  → モーダルが表示される

私自身、このプロジェクトのコードベースに触れるのは今回が初めてということもあり、まず最初にClineに既存のコード全体を読み込ませ、全体構造の解説を依頼してみました。

たとえば、次のような指示をClineに与えました。

「こちらのプロジェクトの全体概要をまとめてくれますか？」

この問いに対してClineは、驚くほど精緻なドキュメントを生成してくれました。

提示された情報は以下のように多岐にわたり、初学時に自分で読み解くには相当な時間を要する内容を一挙に整理してくれるものでした。

• プロジェクト構造：
  ディレクトリ階層、エントリーポイント、各フォルダの役割
• アプリケーションの全体設計：
  ページ遷移の流れ、データフロー、ルーティング構成
• 共有パッケージ：
  共通コンポーネントやユーティリティの使われ方、再利用性の考慮
• 技術スタック：
  使用ライブラリ、ビルド環境やテストフレームワーク
• 主要な機能の概要：
  どのファイルにどんな業務機能が実装されているか

初学者がチーム開発のソースを理解するまでに何日もかかるところを、わずか数分で概観できるようになる体験は、まさにAIならではの価値です。

プロジェクト全体の概要をClineにまとめてもらったことで、大まかな構造や技術的な骨組みはつかめました。
しかし実際に手を動かす段階では、「どのファイルがどの機能と直結しているのか？」というレベルでの理解が必要になります。

そこで次に行ったのが、個別のファイルごとにClineに詳細なコード解説を依頼するステップです。

たとえば以下のような質問を、対象ファイルに対して順番に投げかけていきました。

「Modal.tsxは何をしているコンポーネントですか？親コンポーネントとの関係性も含めて解説してください」

「このuseImageUploader.tsのカスタムフックは、どのタイミングで呼び出されて、どんな副作用を管理していますか？」

こうした問いかけに対し、Clineはファイル内部のコードだけでなく、呼び出し関係・依存関係・状態の流れまで丁寧に言語化してくれました。単に関数の役割を述べるだけでなく、「どの変数がどこから渡され、どう処理されているか」といったつながりを意識した解説を返してくれます。

このプロセスを通じて、「プロジェクト全体のマクロな理解」から「ファイル単位のミクロな理解」へと段階的に認識が深まっていきました。しかも、AIとの対話を通じてコードを読むことで、自分自身の頭の中でも機能と構造が整理されていきます。単なるドキュメント読みとは異なる、AIとの対話を通じてコードへの理解が深まる感覚がありました。

このフェーズを経て、ようやくモーダルの実装に着手する準備が整いました。
ここでもClineを活用して実装を進めましたが、コードベースへの理解が深まった後だったからこそ、AIへの指示の質も変化しました。

抽象的に「モーダルを作って」と依頼するのではなく、

「このディレクトリにファイルを追加してください」

「こういうpropsを受け取るコンポーネントにしてください」

「呼び出し側では〇〇からimportして使います」

といったように、具体的な構成や依存関係を明示した指示が可能になります。結果として、AIも迷うことなくスムーズに実装案を返してくれるため、やり取りの精度と効率が格段に向上しました。

モーダルの実装をAIに支援してもらった後、私はそこで終わらせず、生成されたコードをAI自身に解説してもらうというステップを取りました。

たとえば以下のように問いかけます。

「この部分の状態管理はなぜこういう設計になっているのか？」

「このpropsの型定義にはどんな意図があるか？」

「この記述は他にどう書き換えられるか？」

AIはコード全体の構造や関連性を踏まえ、設計意図や最適化の観点まで含めて説明してくれます。これにより、単に使えるコードとして受け取るのではなく、なぜこのコードになっているのか？を自分の中で分解しながら吸収することができました。

このプロセスは、私にとってブラックボックスだったAI生成コードを自分の理解の輪の中に取り戻す作業でもありました。

理解が深まることで、自然と以下のような力が身についていきます。

• AIに指示出しする必要の無い細かな修正を自分で手を動かして行えるようになる
• よりミクロな粒度でAIに明確な指示が出せるようになる
• 「このコードはこう直した方が良い」と設計意見を持てるようになる

AIの提案を盲目的に受け取るのではなく、自分の言葉で問い直し、判断し、責任を持つ。この姿勢を通じて、AIは単なる自動化ツールではなく、自分のエンジニアリングスキルを伸ばすための対話的なトレーナーになっていくのだと感じました。

こうした学びを通じて、私はAIとの協働に対するスタンスが大きく変わりました。AIはただの「便利な道具」ではなく、正しい向き合い方をすれば、自分の成長を加速させてくれるパートナーです。

率直に言って、Clineの導入前と後では自分が書くコードの質とスピードが全く違うと感じています。

AIによるプログラミングでは、人間の理解がボトルネックになるという指摘もあります。しかし私はむしろ、人間がコードベースを理解するプロセスが、AIと協調して開発を進めるための推進力になり得ると考えています。

AIは非常に強力な補助輪になりますが、それを正しく使うための地図を持つのは、開発者自身です。今回のように、AIの力を引き出すには指示力が不可欠であり、それを得るための時間は決して無駄ではないと、この体験を通じて実感を得ることができました。

このような導入は、新規プロジェクト参画時やコードリファクタリング時にも大きな武器になります。

今後は他のメンバーともこうしたAI支援ツールの知見を共有し、チーム全体の開発体験を底上げしていければと考えています。