Slide 1
Slide 1 text
2025/08/05
リテールアプリ共創部 マッハチーム ⾦城秀哉
書き捨てではなく継続開発可能なコードを
AIコーディングエージェントで書くために意識し
ていること
Slide 2
Slide 2 text
⾃⼰紹介
● 2014年 某SIerにて基幹システム開発従事
● 2017年 某飲⾷系広告事業会社 社内SE
● 2021年 クラスメソッド⼊社
○ 主に⼩売業界のお客様のWeb、LINE、モバイル
アプリ開発に従事
● 部署
○ リテールアプリ共創部
● 名前
○ ⾦城秀哉
● 役割
○ サーバーサイドエンジニア
Slide 3
Slide 3 text
AIコーディングエージェントの登場で変わった⾔われること 3
● コードの断⽚⽣成だけではなく、複雑なタスクをAIに依頼可能になった
● ⾃然⾔語だけで⾼速にコーディング
● ⼈間のタスクは「何を作るか」を決め、「受け⼊れ」をするだけ
⼀⼈の開発者の⽣産性が数倍~数⼗倍以上に！
Slide 4
Slide 4 text
そんなに上⼿くいっていますか？🤔
実際のところ 4
Slide 5
Slide 5 text
もちろんそういうタスクも沢⼭あります 5
例えば以下のようなタスクは、雑な依頼でもサクサク作業を進めてくれます
● 既存機能の横展開(CRUDレベル)
● 作業⽤のETL処理を作る
● ⾃分⼀⼈が使うツールをサクッと作る
● プロンプトだけで簡単なゲームを作ってみる
…etc
Slide 6
Slide 6 text
実際の開発現場とのギャップ 6
実務において、AI主体のコーディングスタイルが難しい要因
● 複雑な業務要件
● 多数のシステム間連携
● ⼤規模なコードベース
● 蓄積された技術的負債
…etc
Slide 7
Slide 7 text
これらのギャップが引き起こす課題 7
● 最後までタスクを完遂できない
○ 途中までいい感じで進むが諦める
○ すぐにレートリミットに引っかかる
○ 時には完了したと虚偽報告をしてくる
● 動きはするが継続的に開発するのが困難な実装
○ 既存コードとの⼀貫性がない
○ 同じようなコードが複数箇所で実装される
○ どこからも使われないゴミが残る
○ 必要以上の機能が良かれと思って沢⼭実装される
○ 型エラーやLintエラーをとにかく黙らせている
Slide 8
Slide 8 text
もういい⾃分でやる🤯
気づくと⾃分がドライバー席に座っていることも 8
Slide 9
Slide 9 text
実案件で発⽣した課題をベースに以下をお話しします
1. AIエージェントにコードを書かせつつ継続開発可能な品質を担保する⽅法
2. AIコーディング時代にチームの⽣産性を上げるために気をつけていること
今⽇お話しすること 9
Slide 10
Slide 10 text
今⽇お話ししないこと 10
以下についてはブログを参照してください
● Cursorの機能詳細、アップデート
Slide 11
Slide 11 text
AIエージェントにコードを書かせつつ
継続開発可能な品質を担保するために意識している点
Slide 12
Slide 12 text
複雑なタスクをAIに丸投げすると、よく以下のような問題が発⽣します
● 途中まで順調に進むが、途中で⽅向性を⾒失い壊し始める
● 試⾏錯誤すると直ぐにレートリミットに引っかかる
● タスクを完了していなくても完了したと報告をしてくる
📚 複雑なタスクを最後まで完遂できない 12
Slide 13
Slide 13 text
タスクが完遂できない原因 13
1. そもそも最初から作業者(AI)と指⽰者の認識がずれている
2. タスク遂⾏に必要な情報が与えられていない
3. １セッションが⻑く指⽰に余計なコンテキストが含まれている
Slide 14
Slide 14 text
Planモードを必ず活⽤する
● Cursor‧Claude Code‧Clineなど各ツールには、AIにいきなりコード
を書かせる前に実装計画を⽴てるモードがある(CursorだとAsk)
● 実装すべき仕様、必要なコードベースのコンテキストなどを与えた後、
「実装を進めるにあたり不明点はありますか？」を必ず聞き、作業者
(AI)と指⽰者の間で認識齟齬が無くなるまで繰り返す
● 技術的な判断や、不明確な制約事項をAIエージェントが勝⼿に決めて⼿
戻りが発⽣することを防ぐ
💡 予め計画して、認識を合わせてから実装を開始 14
Slide 15
Slide 15 text
Planで練った計画やタスクをMarkdown形式で外部にアウトプットする
Claude CodeやCursorも内部でTODOリストを管理している
外部であえて持つ理由は以下
● 別のセッション開始時にコンテキストをマニュアルで引き継げる
● 実装計画をAIと指⽰者で共同編集できる
○ AIが出した設計やTODOを直接書き換えて細かい指⽰を出し永続化する
○ コーディング中に後から対応したいタスクを積んでおく
💡 計画‧タスクをチャットセッションの外部にアウトプット 15
Slide 16
Slide 16 text
変更を⼩さい単位に分割し、新しいチャットで⼩さく作る
● ⻑いセッションでは定期的に履歴の要約が⾛るので最初に与えた重要
な指⽰が薄まる
● 以下のような不要なコンテキストを除外できる
○ 機能A実装→機能B実装→失敗/削除→機能B再実装→失敗/削除→機能C実装
● ⼩さい変更を都度レビュー→最終的なAIコーディングレビューが楽に
○ AIが書きがちな品質の悪いコードを⾒落としにくくなる
● 前のセッションで何をしたかは、前の会話の要約と、外部に保存した
Markdownファイルを与えて共有する
💡 頻繁に新しいチャットに切り替える 16
Slide 17
Slide 17 text
@や#などのコマンドを⾯倒くさがらずに使⽤しコンテキストを与える
● 特定のファイル/ディレクトリ、ターミナルやWebサーチ、予めイン
デックスしておいたドキュメントなど、アノテーションを利⽤してAIに
与えられるコンテキストは多岐に渡る
● 複雑な業務要件を、⼤規模なコードベースに対して実装するには、⾯
倒でもアノテーションで細かい指⽰を出す必要がある
● 今後はAIにコンテキストを与えやすいプロジェクト構成を採⽤する
○ 例)技術関⼼カットのディレクトリ構成からドメインカットのモジュラーモノリスへ
💡 @アノテーションをフル活⽤する 17
Slide 18
Slide 18 text
AIが書くコードをレビューしていると、よく以下のような問題を発⾒します
● 型エラーやLintエラーを握りつぶしている
● 既存コードの書きっぷりと⼀貫性がない
● どこからも使われていないコードがゴミとして残っている
● やたら多すぎるテストケース
● 想像を膨らませて要件にない機能まで実装
📚 動きはするが継続的に開発するのが困難な実装 18
Slide 19
Slide 19 text
具体的にTypeScriptで例に挙げると以下のような実装です
💡これに対してできること
● 蔓延する前にLintルールで厳しく縛る
● AIに与えるRulesで型安全性についての指⽰
● 曖昧な状態を作らない型定義
📚 型エラーやLintエラーを握りつぶしている 19
Slide 20
Slide 20 text
💡これに対してできること
● ＠アノテーションを駆使して⾜りていないコンテキストをマニュアルで
指⽰する
● 機能開発を⼩さく区切り頻繁に新しいセッションに切り替える
○ うまくいかないセッションはすっぱり諦める
○ 変更を⼩さくしてレビュー負荷を下げる
● セッション中に指⽰した学びをRulesファイルにアウトプットさせて育
てる
📚 既存コードとの⼀貫性がない、使われていないゴミが残る 20
Slide 21
Slide 21 text
📚 何が問題か
● AIがこれまで⼈間が書けなかったエッジケースまで網羅的にテスト
を書いてくれるように
○ ⼀⾒良さそうだが、書かれたコードはずっとメンテナンスしていく必要がある
○ 必要以上のエッジケース網羅は、コードリーディングやその後の拡張‧アップデート時の負
債になる
○ 中⾝を⾒ると形だけ取り繕った酷いものがあったりする
💡これに対してできること
● AIが書いたテストコードをケースの説明⽂だけでなく内容まで精査する
● ビジネスインパクトの低いケース、他で担保できているケースは意図的に削
る
📚 いらないテストケースまで実装してくる 21
Slide 22
Slide 22 text
📚 何が問題か
● AIが気を利かせて⾊々と実装してくれる。開発者も直ぐに実装でき
てしまうので、⼤きめの変更の実装判断を出しやすくなる。
○ 「いつか必要になるかも」で作られた機能は使われない
○ 実装者は楽でもレビュワーの負荷が⾼まる
○ 使われないコードが負債になる
💡これに対してできること
● YAGNI（You Aren't Gonna Need It）の原則に⽴ち戻る
● 本当にコードを書いて解決するべき問題か再検討する
○ 仕様調整などで要望は満たしつつシンプルな実装にできるかも
📚 いらない機能まで実装してくる(してしまう) 22
Slide 23
Slide 23 text
AIが書くコードをレビューしていると、よく以下のような問題を発⾒します
● 型エラーやLintエラーを握りつぶしている
● 既存コードの書きっぷりと⼀貫性がない
● どこからも使われていないコードがゴミとして残っている
● やたら多すぎるテストケース
● 想像を膨らませて要件にない機能まで実装
AIに適切にコンテキストを与えたりRulesやLintである程度低減はできるが、
最終的にはAIが書く悪いコードの癖を認識しておく必要がある
📚 再掲: 動きはするが継続的に開発するのが困難な実装 23
Slide 24
Slide 24 text
● 精密なテストデータ⽣成
○ 最⼤⻑、最⼩⻑などの桁数データの⽣成
■ 微妙に桁数が⾜りないなど要件を満たせない
○ 細かい数値データをInputとした、モックデータやOuput検証の実装
■ それ「らしい」が「らしい」だけの出鱈⽬データを⽣成
● ライブラリの単純移⾏
○ jest -> vitest 移⾏でコード修正は⼀瞬だが、テストが落ちる原因を深く探索できずに失敗
📚 AIで効率化できそうで意外とできなかった分野 24
Slide 25
Slide 25 text
AIエージェント時代に
チーム開発で⽣産性を上げるために意識している点
Slide 26
Slide 26 text
再掲: AIコーディングエージェントの登場で変わったと⾔われること 26
● コードの断⽚⽣成だけではなく、複雑なタスクをAIに依頼可能になった
● ⾃然⾔語だけで⾼速にコーディング
● ⼈間のタスクは「何を作るか」を決め、「受け⼊れ」をするだけ
⼀⼈の開発者の⽣産性が数倍~数⼗倍以上に！
● PullRequest本数が以前より5倍出せるように
● ドキュメント作成コストが1/5に
Slide 27
Slide 27 text
再掲: AIコーディングエージェントの登場で変わったと⾔われること 27
● コードの断⽚⽣成だけではなく、複雑なタスクをAIに依頼可能になった
● ⾃然⾔語だけで⾼速にコーディング
● ⼈間のタスクは「何を作るか」を決め、「受け⼊れ」をするだけ
⼀⼈の開発者の⽣産性が数倍~数⼗倍以上に！
● PullRequest本数が以前より5倍出せるように
● ドキュメント作成コストが1/5に
→プロジェクトにおいてはチーム全体で⽣産性を考える必要がある
Slide 28
Slide 28 text
💡 開発者が各⾃で意識したい点 28
チーム全体の⽣産性向上のため、開発者各⾃が以下を意識する
● AIが書くコードのハンドリング
○ ここを怠るとAIが⽣成するコードのレビュー負荷を、チームメンバーにオフロードする
ことになる
○ Vibe CodingとAgentic Codingで使い⽅をはっきり分ける
■ どちらのモードで実装しているのかレビュワーに伝える
● わかりやすいドキュメンテーション
○ AIが⽣成する⽂章は基本的に冗⻑で読みづらい(情報量の割に⽂章だけが⻑い)
■ AIで効率化はしつつも、最終的には他の誰か読むことを意識してまとめる
Slide 29
Slide 29 text
💡 開発者が各⾃で意識したい点 29
チーム全体の⽣産性向上のため、開発者各⾃が以下を意識する
● AIが書くコードのハンドリング
○ ここを怠るとAIが⽣成するコードのレビュー負荷を、チームメンバーにオフロードする
ことになる
○ Vibe CodingとAgentic Codingで使い⽅をはっきり分ける
■ どちらのモードで実装しているのかレビュワーに伝える
● わかりやすいドキュメンテーション
○ AIが⽣成する⽂章は基本的に冗⻑で読みづらい(情報量の割に⽂章だけが⻑い)
■ AIで効率化はしつつも、最終的には他の誰か読むことを意識してまとめる
コーディングとテクニカルライティングのスキルはこれからも変わらず重要
Slide 30
Slide 30 text
💡 レビューがボトルネックになる問題の対策
実装速度が上がるとレビュー負荷がボトルネックになるのは事実
● AIによるコードレビューを導⼊
○ GitHub Copilot、PR-Agent、BugBot(Cursor)など検証
○ 現時点ではClaude Code ActionsによるPRレビューが以下の点で優れている印象
■ レビュー指摘内容の精度、わかりやすさ
■ 他のレビュワーのレビュー負荷軽減
■ 導⼊しやすさ
○ 費⽤は1回あたり約20円ほど
30
Slide 31
Slide 31 text
💡 メンバー間でRulesを個⼈管理できるように 31
● チーム全体で⽣産性を向上させるため、品質の粒を揃えるために各種
RulesはGit管理してチームで共有するのが良いと考えていた
● ⾊々なAIツールを試し、使い⽅を模索する現段階では、チームでRulesを
完全同期する⽅が⾜枷になる可能性がある
○ プロジェクト全体に関する情報や制約はGit管理する
○ エージェントの振る舞いや個⼈的に与えたいRulesについてはGit管理外
Slide 32
Slide 32 text
まとめ
Slide 33
Slide 33 text
まとめ
● 現時点でのAI駆動開発はツールを導⼊してタスクをAIに丸投げ
では完結せず、エージェントを使いこなす⼯夫が必要
○ Planモードを必ず活⽤
○ 計画‧タスクを外部にアウトプット
○ 頻繁に新しいチャットに切り替え
○ @アノテーションをフル活⽤する
○ AIが書く悪い癖を理解し適切にハンドリングする
● チーム開発においては個⼈の⽣産性向上だけではなく、チーム
全体の⽣産性を意識する
33
Slide 34
Slide 34 text
AI駆動開発したいエンジニアを⼤募集しています！
Slide 35
Slide 35 text
リテールアプリ共創部 マッハチーム 35
プロダクト開発の 「立ち上げ専門チーム」 です。
高速に、プロダクト開発 と、
顧客との信頼関係構築 を行うことを目指しています。
Slide 36
Slide 36 text
こんな希望が叶うかも 36
‧ モダンな技術でフルスタック開発に挑戦したい
2~3名のエンジニアで、フロントエンド、サーバーサイド、インフラの全てを担当できます
‧ プリセールスから⼊りプロダクトの⽅向性を提案したい
エンジニアがプリセールスも顧客折衝もガンガン進めていきます
‧ 0から1をAI駆動の圧倒的なスピードで⽴ち上げたい
・2~6人月程度の案件サイズがボリュームゾーンです
・様々な業界・お客様のご支援を高速に回して、マッハで経験を獲得できます
Slide 37
Slide 37 text
カジュアル⾯談お待ちしています！ 37
Slide 38
Slide 38 text
No content