AIの活用によってコーディングの速度が劇的に向上する一方で、「 レビューが追いつかない」「 品質保証(QA)の負荷が減らない」「 AI活用が属人化してしまう」といった新たな悩みが開発現場に生まれています。
そうした課題の解決策を提供するため、2026年1月15日にオンラインイベント「【AI時代の開発戦略】開発スピードと品質の両立に向けて ー 3社エンジニアの事例から学ぶ 」が開催されました。
本イベントには、カミナシ、キャディ、ENECHANGEという急成長テックベンチャー3社のエンジニアが登壇。開発の現場における実践知を発表しました。本稿では、その模様をレポートします。
みんなでAI上手ピーポーになろう! - AI-Assisted Dev Review の実践
株式会社カミナシのすずけん氏は、開発スピードと品質を両立させるために、チーム全体でAI活用のレベルを底上げするための考え方や施策を語りました。
AIと人間との適切な役割分担とは?
まず、人とAIの役割分担について、すずけん氏は「開発スピードの向上はAI、品質の向上は人間」と定義します。AIは人間と比べて圧倒的な知識量を持っています。そのため、世の中で一般的になっている技術の実装などは、AIに委託したほうがスピードは上がります。
一方で、品質を担保するのは人間の役割です。人間には「現在の状況への適用能力(応用するセンス) 」があります。環境やコンテキストはプロジェクトごとに異なるため、「 その場・その時において何が『品質が高い』状態なのか」という判断基準は、人間がデザインしなくてはなりません。
こうした協業を実現するために、人間の責務となるのが「AIを現状の開発スタイルにオンボーディングさせること」です。
変わることのない「不変な事実」
さらに、サービスやソフトウェア開発において誰もがパラダイムシフトを感じている今、不確実性の高い未来に向けて「現状に旗を立てる」ためには、変わることのない「不変な事実」を整理し、拠り所にすることが必要だと語りました。
その事実として、4つのことを提示しました。1つ目は「AI/LLMを取り巻く環境は、昨今類を見ないスピードで進化していること」 、2つ目は「AIの基盤となるLLMにも限界があること」 、3つ目は「LLMにとって入力(コンテキスト)が、出力(推論結果)の質の源泉になること」 、そして4つ目は「AI/LLMに最初の指示を出すのは人であること」です。
この4つを冷静に受け止めることが、未来に対して一歩を踏み出すための確かな足場になるのです。
知見を形式知に変える「AI-Assisted Dev Review」
続いて、カミナシの開発組織における具体的な実践手法である「AI-Assisted Dev Review」を紹介しました。これは、エンジニアが集まって「実務でどうAIを使ったか」を話し合う定例ミーティングです。AIの早すぎる進化に取り残されず、かといって過剰に追いかけすぎて消耗もしない、ちょうどいいバランスでスキルを磨くことを目的としています。
「AI-Assisted Dev Review」では、ナレッジマネジメントの手法を取り入れており、知識をチームのものにするための「型」を意識しています。誰かの経験(暗黙知)を言葉にしてシェアし、それをチームのルール(形式知)として取り入れ、実際にみんなで使ってみる。使ってみた結果をまた個人が振り返り、新たな気づきをシェアするというサイクルを回しています。こうして個人の学びを組織全体の知恵へと昇華させているのです。
文化作りはシンプルに、 ゆるく。 人への投資が複利で効く
こうした活動を長く続けるコツとして、すずけん氏は「とにかくシンプルに、ゆるく始めること」を強調しました。新しいことを始めようとすると、つい管理ルールを複雑にしがちですが、それでは現場が疲弊してしまいます。無理のない範囲で習慣化することを勧めました。
最後に、「 AI時代は、特定のツールや手法に依存した開発戦略は風化が早く、やってみて初めてわかることが多い。だからこそ、実務の中で開発戦略自体の保守性や柔軟性と、人・チームのAI活用リテラシーの向上に投資しつづけることが、複利のように後々の開発スピードと品質に効いてくる」と締めくくりました。
QAがGeminiで分身!受け入れ基準レビューを自動化して開発スピードに追いつくぞ!
キャディ株式会社のQAエンジニアであるnaco(なこ)氏は、開発スピードが加速する中で直面した「リリースのボトルネック」を解消するための挑戦について語りました。
「ACレビュー」の工数肥大化がボトルネックに
まず、naco氏は今回の発表でフォーカスする「AC(Acceptance Criteria:受け入れ基準)レビュー」の重要性を整理しました。これは、開発に着手する前に受け入れ基準を明文化し、チームで合意する活動を指します。このタイミングで基準を固めることで手戻りが減り、テストも作りやすくなるため、品質の根幹に関わる重要なプロセスです。
キャディの開発組織では、生産性を高めるためにAI活用やSREによる運用改善を進めており、作る速度も守る仕組みも強化されていました。しかし、QAがACレビューに関与する際に、一つの壁に突き当たったといいます。
それが「レビュー工数の肥大化」です。レビューそのものよりも、前段階の「必要な情報を集め、文脈を理解する」という下準備に膨大な時間が費やされていました。その結果、QAが本来注力すべき改善に時間を投資できなくなるという、本末転倒な状況に陥っていました。
この課題に対し、naco氏は「投資対効果の高さ」を重視した戦略をとりました。短期間で成果を出すため、QAチーム自身の裁量でコントロールしやすく、かつコスト削減のインパクトが最も大きい領域に絞って解決策を投じることにしたのです。
そこで選ばれたのが、AIを「QAの分身」としてACレビューを自動化するアプローチです。ポイントはAIにすべてを丸投げするのではなく、負荷の高い準備と下処理をAIに任せ、人間は判断に集中するという役割分担です。
自分の分身を生み出すための3つの成功要因
naco氏は、AIを自分の分身として機能させるための「3つの成功要因(KSF) 」を導き出しました。
1つ目は、「 QAの思考プロセスの構造化」です。QAが普段、頭の中で行っているレビュー観点を「型」として言語化しました。具体的には、レビュー観点をPlantUMLファイルに落とし込み、AIに参照させる手法をとりました。これにより、誰がチェックしても判断の一貫性が保たれ、属人化を減らすことに成功しました。
2つ目は、「 表記ゆれやタグ漏れに強い情報連携」です。ドキュメント上のタグ付け忘れや表記ゆれ(日本語・英語の混在など)があっても、AIがMCPサーバー経由で各種ツールから高い精度で情報を拾える仕組みを構築しました。これにより、レビューの下準備である情報収集の時間を大幅に削減しつつ、仕様変更の影響範囲の見落としを防いでいます。
3つ目は、「 人とAIの役割分担の明確化」です。AIはあくまで「1次レビュー(ドラフト作成) 」を担当し、人間が「最終チェック」を行うというワークフローを徹底しました。AIの指摘内容がログとして残るため、それを学習・フィードバックさせることで、改善サイクルが回る仕組みも整えました。
大切なのは「AIと共生するプロセス」のデザイン
これらの取り組みによって、QAの業務は劇的な変化を遂げました。これまで業務の大部分を占めていた「情報の収集と理解」という重い下準備をAIに寄せられたため、QAは「判断すること」に注力できるようになったのです。QAとしての視点や判断基準を型化し、AIと共生するプロセスをデザインする。その重要性が伝わるセッションとなりました。
仕様駆動開発を飛躍させる!巨匠に学ぶ、 AIとの対話術
ENECHANGE株式会社の利廣悠司氏は、Claude CodeなどのAIツールと協業しながら仕様書を中心に開発を進める「AI×仕様駆動開発」という手法について、その効率を最大化するための実践的なノウハウを共有しました。
運用における最大のボトルネックは「AIとのチャット」
まず、利廣氏は「AI×仕様駆動開発」の全体像を4つのステップで整理しました。1つ目は、基本設計書と詳細設計書の作成。2つ目は、それに基づいたタスクの分解。3つ目は、各タスクに対するテストファーストでの実装(テストケース作成、実装、リファクタリング) 。そして4つ目が、全タスク完了までの反復です。
このフローは開発の効率化に大きく寄与しますが、実際に運用する中での最大のボトルネックは「AIとのチャット」に集約されるといいます。やり取りに時間がかかりすぎたり、期待したレベルの回答が得られなかったりといった課題を突破するために、利廣氏は各界の巨匠たちの名言になぞらえて、4つのコツを提示しました。
成果を最大化するための4つのコツ
1つ目は、「 神は細部に宿る、具体的指示の徹底」です。指示が曖昧だと、AIは足りない情報を補おうとして勝手な推測を始めてしまいます。具体的な指示文を書くのは手間がかかりますが、AIが自分の意図を正確に反映してくれるようになれば、結果的に作業時間の大幅な短縮につながるのです。
2つ目は、文脈を極限まで削ぎ落とす「Less is More」という考え方です。丁寧に伝えようとするあまり、冗長なプロンプトを渡してしまうと、かえって逆効果になりかねません。情報が多すぎるとAIにとってはノイズが増え、処理すべきトークン量も増大します。「 解決に必要な最低限の情報のみを渡す」という引き算のコミュニケーションが有効です。
3つ目は、AIの創造性を引き出すための「And what else?(ほかには?) 」という問いかけです。AIは限られた文脈の中から一つの正解を提示しようとする性質がありますが、それでは解決策の可能性を狭めてしまう恐れがあります。そこで、最初から「複数の選択肢を挙げるように」と指示しておく手法を推奨しました。こうすることでAIは案を出すことに専念し、エンジニアは「どの選択肢が最適か」という判断に集中できるようになります。
4つ目は、背水の陣のように「逃げ場を塞ぐ徹底的なレビュー」です。AIによるレビューは、標準的な指示だけでは「甘さ」が出てしまい、影響範囲の漏れや根本的な問題を見逃してしまうことが少なくありません。これを解決するために有効なのが、AIに「厳格なレビュアー」という具体的な役割を与える方法です。安易な妥協を許さない批判的な視点を演じさせることで、細かな不備やリスクを鋭く指摘してくれるようになります。
対話の質を人間がコントロールする
利廣氏が提示したこれらの対話術は、単なるプロンプトのテクニックに留まらず、AIを「エンジニアリングのパートナー」として迎えるための規律ある向き合い方を示したものでした。
AIの特性を深く理解し、対話の質を人間がコントロールする。それこそが、「 AI×仕様駆動開発」において、開発スピードと品質を両立させるための鍵となります。
おわりに
AIの活用はもはや当たり前になりましたが、その価値を真に発揮するには、「 組織としての仕組み」や「AIとの対話の質」を改善し続けることが欠かせません。ぜひ3社の発表内容を参考にしつつ、開発スピードと品質の両立を目指していきましょう。