🌊

生産性4倍?実際の開発現場でAIエージェントを用いた開発を振り返る~2025年4月末~(Cline + Github Copilot編)

に公開

はじめに

お久しぶりです!レセプトの開発マネージャのMasakiです。前回の記事「小規模ツール開発におけるAI活用」では、小さなツール開発でのAI活用についてお話ししました。

最近は、ちょっとしたツールなら生成AIでサクッとアイデアを形にできるようになりました。でも、大きなプロジェクトやチーム開発となると、使う人によって業務で利用できるかどうかが分かれるというのが正直なところです。

そんな中、私はここ数ヶ月間、大規模な開発プロジェクトで生成AIをガッツリ使って、なんとか大規模プロジェクトの進捗を上げようと奮闘してきました。結果として、個人の生産性が約4倍になって(あくまで試算ですが)、マネージャー業務をしながらでも開発プロジェクトでそれなりに貢献できたかなと思っています。今はClaude Code + Devin + GitHub Copilot + Cursorといった感じで、複数のツールを使い分けています。

この記事シリーズでは、そんな試行錯誤の日々を何回かに分けてシェアしていこうと思います。2025年9月の今から振り返って、「これは今でも使えそう!」というTipsをピックアップしていきます。第1回目の今回は、Cline + GitHub Copilotを使い始めた頃のお話です。

この記事で伝えたいこと

  1. 実プロジェクトでAIを使うまでの道のり:「AIツール使ってみたいけど、実際社内でどうやって始めるの?」という疑問にお答えします
  2. 大規模プロジェクトで一人でAI活用する時のリアルな話:実際にやってみて「これは大変だった」という課題と、どうやって乗り越えたかの体験談
  3. ツールが変わっても使える考え方:Clineでもなんでも、結局大事なのはこういうことだよね、という普遍的なポイント

どんな人に読んでもらいたいか

  • AIツールが気になっている開発者の方:「実際の現場でどんな感じで使ってるの?」が知りたい方
  • 会社でAI活用を進めようとしている方:「うちでも導入したいけど、どう進めればいいんだろう?」と悩んでいる方
  • 他社の事例が気になる方:「他の会社はどんな風にAIを業務で活用している?」という好奇心旺盛な方

そもそも「生産性4倍」って本当?

「生産性4倍」って聞くと、盛っているように思われるかもしれないので、最初に補足します。

これは私が個人で片付けたストーリーポイントから計算した、ざっくりとした数字です。当時はまだスクラムを導入したてでチームの見積もりが甘かった時期でもあったので、参考程度に受け取ってもらえれば幸いです。詳しくは以下の記事を参考にしてください。

https://zenn.dev/rehabforjapan/articles/02cc6d46243aa6

チームで見積もった結果、ポイントが大きすぎて「これ誰がやるの..」みたいなPBI(プロダクトバックログアイテム)がいくつかありました。見積もりの時は複数人相当という前提だったんですが、そのうちの一つをAIの効果検証も兼ねて自分自身で巻き取ることにしました。

Cline + Github Copilot を業務活用してみた話

2025年4月当時の状況

当時のプロジェクト状況は以下の通り:

AIツールの状況

  • 2025年2月ごろから試行でDevinを使っていたのですが、既存プロダクト(レセプト)のコードベースはかなり大きく複雑でした。「API作って」など粒度が大きな課題を丸投げしても、なかなか「これは使える!」というレベルまでは到達しませんでした
  • チームの中で他のAIツールを試している人はいなくて、GitHub Copilotだけは導入されていました(ただし、当時はGitHub Copilot Agentが登場したばかりで社内で利用している人は少ない状態で、Agentを用いた開発は試行錯誤段階でした)

プロジェクトの状況
これから会社の行く末を左右する大規模プロジェクトを進めるぞという直前、スクラムを正式に導入して、大がかりなリファインメントをやった結果、見積もりを大幅に超える多くのPBIが作成されました。ただ、メンバー全員目の前のタスクをこなすことで必死であり、そもそも人手が不足していたため、進捗が遅れることが明白、という状況でした。

Clineとの出会い
そんな時に、Clineの情報がちらほら出始めました。特に以下の記事を読んで「これは試す価値がありそう」と感じ、AIエージェントに賭けることにしました。

https://zenn.dev/mizchi/articles/all-in-on-cline

まずは準備から

新しいAIツールを使い始める前に、準備をしました:

  1. どのツールが使えるか調査:「これは社内で利用OK」というツールを事前にピックアップ
  2. セキュリティ面のチェック:自身が利用したいツールに関して、既存のソースコードが学習データに使われないか、プライバシーポリシーの確認
  3. CTOに相談:「こんなツール使ってみたいんですけど、どうでしょう?」とCTOに相談。プライバシーポリシーと合わせて交渉

これらのおかげで「あとで問題になったらどうしよう」という心配をせずに、安心してAIツールを試すことができました。

実際にやってみた

自分で巻き取ることに決めた理由
大規模プロジェクトの見積もりを行ったのは自分自身。そのとき、100%開発にコミットできないと思っていた開発マネージャである自分自身の稼働は期待していませんでした。そこで、その自分がAIとともに1タスクでも完成させたら大きくプロジェクトに貢献できるのではないかと思い、チャレンジしました。

使ったツールとその役割

  • Cline(Claude 3.7 Sonnet):設計担当。私と設計の壁打ち。マークダウンファイルの設計書を出力するまでが役割
  • Github Copilot(GPT-4.1):実装担当。マークダウンファイルの設計書を受け取って、実装を完了させることが役割

どのように進めたか

  1. 設計を考える:ある程度自分で「こういう設計にしたい」を思い描いた後、Clineにクラス設計、クラス図も作ってもらって認識合わせ。他のAIに実装を渡す想定であることも伝えて、意図通りの設計が盛り込まれているかを確認
  2. コードを書く:Clineが作ってくれたマークダウンの設計書をGitHub Copilotに読み込ませて、実際のコードを書いてもらう
  3. 動かしてみる:最後に動作確認をして、「ここちょっと違うな」というところは手で直す。ただ、大きな齟齬はなく動作しました

イメージ図は以下の通りです。

結果がすごかった
複雑なビジネスロジックを実装するため1ヶ月はかかると見積時に言われていたPBIが、他の仕事(インシデント対応や打ち合わせなど)をやりながらでも、なんと5日でPRレビューまで到達しました。実装内容は、必要な要件を特定のビジネスロジックに切り出し、複数の入出力データパターンをテストすればOKという設計に落とし込めたため、AIエージェントを用いた開発がかなり有効だった事例だと思います。

今でも使えそうな学び

この経験から、これは今でも大事だと思うポイントを3つシェアします:

1. 設計と実装は分けて考える

なぜ大事なのか
AIエージェントへ指示を出す際に、設計と実装をきっちり分けるやり方は、今ではみんながやっていることですが、AIの性能がまだそれほど高くなかった当時でも効果的でした。Cline公式の推奨でもありますし、KiroやSpec Kitなどspec駆動開発を謳うツール、Claude Codeでも基本は同じです。しばらくこの流れは変わらないと考えています(3年先は不明ですが)。

2. 設計の時はAIとじっくり話し合う

気をつけたいこと
プロジェクトのルールなどはマークダウンファイルで整備していたのですが、やはりAIが「これ違う方向で設計してない?」みたいな行動をすることがありました。最終的にOKの判断は、人間によるチェックが必須です。

現時点ではどうか
現在、Serena MCPを利用することでClaude Code単体よりも調査・計画の精度が上がっている気がしますが、開発者自身もドメイン知識やシステム知識、ソフトウェア開発のスキルなどを身につけてAIをリードしてあげることが必要だと考えています。

3. AIモデルの得意・不得意を知って使い分ける

それぞれの特徴

  • GPT-4.1:指示追従性。ちゃんと伝えたことだけを実施してくれる
  • Claude 3.7 Sonnet:当時はコーディング性能が高いとされていた
  • コストの話:モデルによってAPI料金が異なる。そのため、設計に3.7 sonnetを利用しコストの比重をおいて、実装はGithub Copilot AgentのGPT-4.1(当時はビジネスプランなら使い放題)を活用するなど、やりくりしていました。

大事な考え方
「この作業にはこのモデルが向いてるな」って使い分けるのが、AIをうまく活用するコツだと思います。

感じた課題

良いことばかりではなく、実際やってみて「これは難しいな...」と思ったこともありました:

1. 大規模コードベースは一度にすべてを読ませることができない

現実的な壁
大規模なコードベースを全部AIに「はい、これ読んで!」って渡すのは、今の技術だとまだ無理です。コンテキストの長さに限界があります。

2. 仕様書がAI向きじゃない

何が困ったか
複雑なビジネスロジックを作るには、要件定義書や既存の設計書をちゃんと理解してもらう必要があるのですが、たいていの場合、これらの資料は「AIが読みやすい形」になっていません。特にスプレッドシートで描かれる要件定義書は難しく、PDFへ変換するなどしてなんとかAIが読める形式へ変換して、コンテキストとして渡すことにしました。

今どうしているか

  • AIが読みやすい仕様書を作る必要があると感じていますが、全体の開発プロセスの見直しも必要になります
  • 現状でも「今回はこの機能、元の仕様はこれ、追加仕様はこれ」という感じで、手動でコンテキストを整理して渡すという人力作業に頼っています

おわりに

以上、2025年4月頃にCline + GitHub Copilotを使ってみた体験談をお話ししました。

今回のポイントをまとめると

  • 事前準備(ツール選定、セキュリティチェック、社内調整)は大事
  • 設計と実装を分けて進めるやり方は効果的
  • AIモデルの得意・不得意を知って使い分けるのがコツ
  • 大規模コードベースやAI向きではない仕様書の問題はまだある

当時はまだAI活用は手探り状態という感じでしたが、基本的な考え方は今でも通用すると思います。特に「設計と実装を分ける」は、ツールが進歩した今でも変わらず大事なポイントです。

次回予告

次回はClaude Codeを使って、ストーリーポイント見積よりも2倍の速さでレセプトで最も複雑な機能を改修したという話です。お楽しみに!

Rehab Tech Blog

Discussion