【備忘録】AI駆動開発Conference Autumn 2days で 学びと気づきが得られすぎたので、共有したい...
はじめに
2025年10月30日〜31日に開催された 「AI駆動開発 Conference Autumn 2025」 に参加してきました。
2日間にわたるイベントを通して、AIを活用した開発の最前線・現場での実践知について、沢山の学びと気づきを得られました。
本記事では、その中でも特に印象に残った内容を、備忘録としてまとめたものになります！
もし興味のある項目があれば、ご覧いただけると嬉しいです！
「ClaudeCode 実践方法」編
サブエージェントで同時並行で開発させる際は、タスクの進捗状況を共有するためのDB を作成する
それぞれのサブエージェントが、必要に応じて 「各自でタスク状況の更新」 を行うようにする。方法としては、DB の更新 や Git のリモードレポジトリをPushするなどです。
その上で、随時最新情報を取得することで、常に変更を取り込ませる。もしコンフリクトが起きた場合は、「変更履歴を元に人が修正している」とのことでした。
オンボーディング時は、AI を積極的に活用する
新しいメンバーが入った時は、http://Claude.md などのマークダウンファイルを渡した上で、 「Claude Code に疑問点を質問してキャッチアップ」 ができる。
従来の「ドキュメントのURL を送り、後は読んどいて」 という手法が変わってきている。
Claude Codeを 「同僚エンジニア」 として扱う
コツは 「期待してること」を素直に伝えること。またClaude が備えている機能の使い方が分からなかったら、 「どうやって使ったらいい？」とClaude Code に質問するのも大切。
ただ、Claude Codeを使って実装する時は、「人が主導する姿勢」 が大切。
Claude Code で 有効化しておくべき設定や環境
- 通知ON：長尺タスクやレビュー完了を見落とさない
- 文字起こしON：指示を音声で行えると、迅速な指示出しに繋がる
- 組み込みツール活用：Bash, Web Search など、便利なツールがビルドインで備わってる。使い方はClaude Code に聞けばいい。
- CLIツール：コマンドラインツールであれば、ほとんどが利用可能。
- MCP連携：Localの情報へアクセスすることができるようになる。必要に応じて自分でMCPを作成する。
必要に応じて 「推論の深さ」を調整する
「think ultrathink」 をプロンプトに付けることで、さらに深い推論をさせられる。
プランモードで計画を作成する時は、こちらの方が精度が上がるのでオススメです！
Claude に コードの質問をする時は、 「該当コード + なぜ質問するのか？」 の両方を含める
コードの内容を聞くときも、「なぜその質問をするのか？」の背景が必ず存在するはず。その背景を一緒に伝える。
バグレポート、 生じたインシデント 、該当チケットを見せて、「質問した理由はこれ」と背景も伝えられると、より良い回答が得られる。
プランモード実行時、作成された計画に対して 「さらに深掘りして質問」 する。
なぜその設計なのか？あるいは他の代替案と比較してどうか？この深掘りができると、計画の質が上がる。
実装するコードの質を高める方法
実装結果に対して「さらに改善して」 と何回か指示を送り、繰り返し改善してもらう。「ただ実装させて終わるのではなく」、それを「改善させるように繰り返し指示」して、継続的に改良するのが大切。
もしテストを作成していた場合は、そのテストが通るまで継続して修正させる指示も忘れない。
AIの環境整備ができていないなら、AI に整備させる。
各ディレクトリの構成やファイルに関して、AI に調査させてドキュメントを作成させる。もしまだ整備できていない方がいれば、試してみる価値がありそうです！
「TDD 開発手法 と コード品質管理」編
テスト書いて開発するだけ ≠ TDD(テスト駆動開発)
「テストを書いて開発する」だけでは、TDDとは言えない。TDDの本質は、実装して得られたフィードバックをテストに反映しつつ 「最適な設計を模索して考え続ける」こと。
また 「テストを先に書く」は「テストファースト」であり、TDDとは別物ではある。
設計の修正を常に仕様書にフィードバックする
「こっちの設計の方がいい」 と思ったら、随時設計書を修正する。目の前のコードや設計に固執しすぎない。
コード品質のメトリクス選びは拮抗するものを選ぶ
品質を高めるには、互いに拮抗する指標を組み合わせることが大切。似た指標ばかりだと、そのメトリクスに最適化された、偏ったコードになる。
例えば 「テスト/ソース比率とカバレッジ」 などで、カバレッジだけだったらテストコードだけが肥大化する可能性がある。
ここのバランスを取れると、AI が作成するコードの評価関数として使えるようになる。
AIに設計候補を大量に出させられれば、将来バイブコーディングでもいい設計が出来上がる、かもしれない
沢山の設計パターンを作らせた上で、↑ のメトリクスで評価できれば、 「一つは良い設計が出てくる」 可能性がある。
つまり 「数は正義」 ということ。前提が変われば、結果も変わる例だと感じました。現状でも取り入れられる所は多いと思います。
過去の事例を学習して今に活かす。
今のAI時代で起きている課題は、昔にソースコードが肥大化した時と似ている。対応方法も類似してる。
過去の設計ノウハウや失敗事例を学んでおくと、AI時代でも応用できる武器になる。
テストの役割
テストは“AIに根拠を与えるため”の仕組み 「ゼロリスク信仰」ではなく、改善可能な設計を目指す。
設計を安心して柔軟に変えられるのが、良い設計や仕組み。
「AIツール 活用方法」編
プロンプト設計力を大切にする
構造的プロンプト（主語・述語・制約）を意識する。日本語は、主語や述語が抜けがちなので、ここを補完することが 「良い出力」 に繋がる。何したいかが抜けてると、正しく出力できない。
また、英語指示の場合、上記の構造的情報が含まれやすいのと、日本語ではうまくいかないタスクも上手く行ったりする。
AI に修正依頼する時は 「ファイル指定」 を行う
どのファイルを直させるか？を指定すると、タスクのスコープを狭められて精度が上がる。またコンテキストも節約できる。
要件をAIに正しく渡してレビューさせる
AIレビューがうまくいかないのは、要件が不明確だから。デザインドックや仕様意図をセットで渡すと、AIが的確にレビューできるようになる。
要件をAIが読める形にするのが大切
タスクがタイムアウトしそうなら 「10 分単位」 にして回す
実装計画書を 「10 分単位」 で完了できるようにして、実装させる。この時に、成果物が独立しているものは並列処理させる。
ファイル出力時、トークン制限を超える場合は 「複数に分けて書き込んで」と指示する
これだけで、大量の内容をスムーズにファイルに書き込めるようになる。
Windsurf と Devin の最適な組み合わせ
上記のツールの長所を活かした使い方ができると、より効率的に開発できる。
- Windsurf：対話的。UI比較や簡単な実装テストが得意
- Devin：クラウド上で複数同時に実行。PMや自動化に強い
ここから 「Windsurf = 複雑なタスクを人と一緒に行う」・「Devin = 簡単なタスクを大量にこなす」などの使い分けが大切になる。
AI にMCPサーバーを繋いで、必要な情報を入れる。
Azure MCPサーバーでAIに学ばせる。WikiやBoards情報をAIに連携する。必要に応じて情報にアクセスできるように出来るとベスト。
「組織浸透」編
「業務理解」 がAI活用の9割
AI活用が成功する組織は、現場業務を深く理解している。
実際の現場に入り込んで仕事を行うなど、「観察・参与・ヒアリング」 を行い、なぜその業務を行うのか、なぜその行動をするのか？を掘り下げることが重要。
組織導入の壁は3つある
① 技術理解「AIは嘘をつく」などの誤解など
② 組織理解「ROIが見えない」などの経営判断やインセンティブなど
③ 心理的抵抗「やっても意味ない」などの人の心理的ハードルなど
「代理体験」 で安心感を与える
「AIを使いこなせている人」 を社内のロールモデルとして前面に出す。
「あの人ができたなら、自分もできるかも」 という代理体験が、学習性無気力を打破し、文化を作る。
組織でAIを活かすために
mass層（普通の社員）にも使える仕組みを作る。共通の「AIスキル評価制度」を設けて迷いを減らしたり、社内でハンズオン・勉強会でボトムアップに展開する。
AI をみんなで使える文化にする、これが大切。
「開発方法論」編
プロトタイプを最速で作り、まず見せてみる
「考える前に作って見せる」のが大切。Lovableのようなツールを使えば、数時間で顧客向けモックやキャンペーンアプリを形にできる。
これにより 「コンセプト作成」 にエネルギーを割けて、かつ意思決定自体も早くなる。
社内ツールは、自分達で独自に作る時代が来る
「試しに作ってみる」がそのまま形になる時代。Saas ではなく 「今の業務に最適化」 されたアプリケーションを簡単に作れる時代になる。
非エンジニアにも積極的に開発に参加できる世界
Lovableなどのノーコード/AI開発ツールで、エンジニアでなくても簡単なタスクをこなせるようになる。またプロトタイプをそのままプロダクションコードにも反映できるので、工数が圧倒的に減る。
エンジニアは重要なロジックや設計に集中できる。
開発時の段階を分ける
「超MVP → MVP → 本格実装」と、実装のフェーズを分ける。その上で、各フェーズごとに作り込み度合いを変えていく。
音声入力 × AI開発 で 高速開発を行う
会議中や顧客との対話をそのままAIに渡す。「これ作って」と言えば、そのままプロトタイプが返る時代。リアルタイムで発想を形にすることも出来る。
AI で 効率化を行う時は 「開発フロー全体」 を見直す
リリース速度は最も遅い工程で決まる。なので、開発効率だけを上げてもダメ。「PRD〜設計〜実装〜レビューまで」 を言語化し、全てにおいて全体で改善サイクルを回す。
コード生成がボトルネックにはならない。
コード生成は速くても、デバッグが24時間では意味がない。またレビューが溜まるだけで、全体から見ると開発スピードは上がらない。
目の前の開発効率だけでなく、全体を見る姿勢が大切。
人がコードを読む
AIが生成したコードは、必ず人が確認する習慣をつける。これで常に人は成長できる。この原則を忘れない。
AI駆動開発の未来
AI が、全てのコードを作ってくれる世界が来る。指示さえ出来れば、AIがコードを書き、テストし、改善してくれる。
人は、よりクリエイティブな領域に注力できるようになる。
AI 駆動開発の時の人の役割
AIが前提の時代に求められるのは、「ビジネス × 技術」を両方理解できている人。ビジネスの人もコードを書くし、エンジニアもビジネスの理解が必要になる。
また、ビジネスサイドの人とエンジニアの距離が近くなる。
人は何をやるべきなのか？
AI ができない領域を伸ばすべき。
例えば...
- 感動を生むUI/UX
- ビジネスモデルの構想
- 人の体験に基づく価値設計
など 「いいものを考え、心を動かす」 ことが 人間の仕事になる。
複雑なタスクに対するAIの限界
AIはコード生成は得意でも、「仕様策定」や「文脈理解」はまだ難しい…修正を指示しても、背景情報が抜け落ちることが多い。
上流工程で得られた情報をうまく組み込めるか？が大切。
バイブコーティングは、エンジニアのためのものではない。
非エンジニアの人が、 「自分しか使わないソフト」 は作れる。でもプロには“他人が使える品質”が求められる。ここの品質には達しない。
だからこそ、バイブコーティングを過信しすぎないことが大切。
AIと人の関係性
- AIと伴走：教習車のようにAIがサポート
- AIに委託：全部任せる代わりにレビューが大変になる。
目の前のタスクや状況に応じたバランスが大切で、委託することが全てではない。
Anthropicの思想
モデルは、安全性と信頼性を最優先に設計している。リリース前には、リスクを想定した上で、安全にモデルを利用できるか？に重きを置いている。
「環境整備と品質管理」編
AI に作成させるドキュメントは、統一フォーマットで管理する
Excel方眼紙はできる限り使わない。また「テストケースやチェックリスト」 は共通記法で統一する。ここを揃えることで、「誰がやっても同じ品質」 という状態を作れる。
ここまでいくと、水平展開が容易になる。
テストケースは ルールベースで作成する。
最後の品質管理は 人の責務。そのためテストケースはルールベースで観点を整理する。
その上で成果も定量的に測定する。
テスト駆動 × AI の活用方法
テストは 「品質担保」 だけでなく 「開発のゴール設定」 にもなる。UT観点をルール化し、AIが生成したコードにも自動チェックをかける。これにより、AI に指標も与えられる。
AIを上流工程で活かすには？
仕様やメモリを「再現可能な粒度」で記録していく。「なぜそうしたのか／なぜそうしなかったのか」を明文化する。会議ログ・制約条件など多様な文脈を取り込む。
多様なコンテキストがあればあるだけ良い。
AI が読みやすいドキュメントを作る
Markdown＋MermaidでAIが読める設計書を作成する。「AIがアクセスしやすい情報設計」 が重要。
Discussion