Upgrade to Pro — share decks privately, control downloads, hide ads and more …

書き捨てではなく継続開発可能なコードをAIコーディングエージェントで書くために意識していること

 書き捨てではなく継続開発可能なコードをAIコーディングエージェントで書くために意識していること

Classmethod主催ウェビナー「AI駆動開発、実際どうなの?【実践編】~現場でぶつかる課題と乗り越え方~」以下のウェビナーの発表した資料です。
https://classmethod.jp/seminar/250805-aidd-webinar/

【概要】
・AIコーディングエージェントでAI駆動開発を進める際の課題と対応
・AIコーデイング時代にチームで生産性を上げるために気をつけていること

Avatar for ShuyaKinjo

ShuyaKinjo

August 04, 2025
Tweet

More Decks by ShuyaKinjo

Other Decks in Programming

Transcript

  1. これらのギャップが引き起こす課題 7 • 最後までタスクを完遂できない ◦ 途中までいい感じで進むが諦める ◦ すぐにレートリミットに引っかかる ◦ 時には完了したと虚偽報告をしてくる

    • 動きはするが継続的に開発するのが困難な実装 ◦ 既存コードとの⼀貫性がない ◦ 同じようなコードが複数箇所で実装される ◦ どこからも使われないゴミが残る ◦ 必要以上の機能が良かれと思って沢⼭実装される ◦ 型エラーやLintエラーをとにかく黙らせている
  2. 📚 何が問題か • AIがこれまで⼈間が書けなかったエッジケースまで網羅的にテスト を書いてくれるように ◦ ⼀⾒良さそうだが、書かれたコードはずっとメンテナンスしていく必要がある ◦ 必要以上のエッジケース網羅は、コードリーディングやその後の拡張‧アップデート時の負 債になる

    ◦ 中⾝を⾒ると形だけ取り繕った酷いものがあったりする 💡これに対してできること • AIが書いたテストコードをケースの説明⽂だけでなく内容まで精査する • ビジネスインパクトの低いケース、他で担保できているケースは意図的に削 る 📚 いらないテストケースまで実装してくる 21
  3. 📚 何が問題か • AIが気を利かせて⾊々と実装してくれる。開発者も直ぐに実装でき てしまうので、⼤きめの変更の実装判断を出しやすくなる。 ◦ 「いつか必要になるかも」で作られた機能は使われない ◦ 実装者は楽でもレビュワーの負荷が⾼まる ◦

    使われないコードが負債になる 💡これに対してできること • YAGNI(You Aren't Gonna Need It)の原則に⽴ち戻る • 本当にコードを書いて解決するべき問題か再検討する ◦ 仕様調整などで要望は満たしつつシンプルな実装にできるかも 📚 いらない機能まで実装してくる(してしまう) 22
  4. AIが書くコードをレビューしていると、よく以下のような問題を発⾒します • 型エラーやLintエラーを握りつぶしている • 既存コードの書きっぷりと⼀貫性がない • どこからも使われていないコードがゴミとして残っている • やたら多すぎるテストケース •

    想像を膨らませて要件にない機能まで実装 AIに適切にコンテキストを与えたりRulesやLintである程度低減はできるが、 最終的にはAIが書く悪いコードの癖を認識しておく必要がある 📚 再掲: 動きはするが継続的に開発するのが困難な実装 23
  5. • 精密なテストデータ⽣成 ◦ 最⼤⻑、最⼩⻑などの桁数データの⽣成 ▪ 微妙に桁数が⾜りないなど要件を満たせない ◦ 細かい数値データをInputとした、モックデータやOuput検証の実装 ▪ それ「らしい」が「らしい」だけの出鱈⽬データを⽣成

    • ライブラリの単純移⾏ ◦ jest -> vitest 移⾏でコード修正は⼀瞬だが、テストが落ちる原因を深く探索できずに失敗 📚 AIで効率化できそうで意外とできなかった分野 24
  6. 💡 開発者が各⾃で意識したい点 28 チーム全体の⽣産性向上のため、開発者各⾃が以下を意識する • AIが書くコードのハンドリング ◦ ここを怠るとAIが⽣成するコードのレビュー負荷を、チームメンバーにオフロードする ことになる ◦

    Vibe CodingとAgentic Codingで使い⽅をはっきり分ける ▪ どちらのモードで実装しているのかレビュワーに伝える • わかりやすいドキュメンテーション ◦ AIが⽣成する⽂章は基本的に冗⻑で読みづらい(情報量の割に⽂章だけが⻑い) ▪ AIで効率化はしつつも、最終的には他の誰か読むことを意識してまとめる
  7. 💡 開発者が各⾃で意識したい点 29 チーム全体の⽣産性向上のため、開発者各⾃が以下を意識する • AIが書くコードのハンドリング ◦ ここを怠るとAIが⽣成するコードのレビュー負荷を、チームメンバーにオフロードする ことになる ◦

    Vibe CodingとAgentic Codingで使い⽅をはっきり分ける ▪ どちらのモードで実装しているのかレビュワーに伝える • わかりやすいドキュメンテーション ◦ AIが⽣成する⽂章は基本的に冗⻑で読みづらい(情報量の割に⽂章だけが⻑い) ▪ AIで効率化はしつつも、最終的には他の誰か読むことを意識してまとめる コーディングとテクニカルライティングのスキルはこれからも変わらず重要
  8. 💡 レビューがボトルネックになる問題の対策 実装速度が上がるとレビュー負荷がボトルネックになるのは事実 • AIによるコードレビューを導⼊ ◦ GitHub Copilot、PR-Agent、BugBot(Cursor)など検証 ◦ 現時点ではClaude

    Code ActionsによるPRレビューが以下の点で優れている印象 ▪ レビュー指摘内容の精度、わかりやすさ ▪ 他のレビュワーのレビュー負荷軽減 ▪ 導⼊しやすさ ◦ 費⽤は1回あたり約20円ほど 30
  9. まとめ • 現時点でのAI駆動開発はツールを導⼊してタスクをAIに丸投げ では完結せず、エージェントを使いこなす⼯夫が必要 ◦ Planモードを必ず活⽤ ◦ 計画‧タスクを外部にアウトプット ◦ 頻繁に新しいチャットに切り替え

    ◦ @アノテーションをフル活⽤する ◦ AIが書く悪い癖を理解し適切にハンドリングする • チーム開発においては個⼈の⽣産性向上だけではなく、チーム 全体の⽣産性を意識する 33