AIコーディングエージェントの普及で、コードを書く速度は飛躍的に上がりました。しかし、速くなったのは実装だけです。レビュー、ドキュメント、設計判断といった「人間の仕事」は、これまでと同じ速度でしか進みません。実装が速くなるほど、ボトルネックは人間の側へ移っていく。多くの開発現場が直面しつつある、構造的な課題です。

事業共創カンパニーRelicが開発する、新規事業のアイデア創出SaaS「IDEATION Cloud」の開発チームは、この壁に早くから向き合ってきました。人間がゼロからコードを書くことはほぼなく、PMも置かない3名のチームです。
今回は、開発責任者の保、多和田、高橋の3名に聞きました。何が詰まったのか。どう仕組みで解いたのか。そして、その先に見えた新しい課題とは何か。

＜インタビュイー紹介＞

写真左から順に多和田・保（開発責任者／Dev Leader）・高橋。
3名ともプロダクトディベロップメント事業部に所属するエンジニアです。

保と多和田は、11月7日（土）にあきた芸術劇場ミルハスにて開催されるAWSコミュニティイベント「JAWS FESTA 2026 in AKITA」に登壇採択されており、Webアプリケーションの高速開発手法や、地域方言に対応したAIチューニングの実践的な検証結果を発表します。
参考：https://relic.co.jp/news/press-release/900014/

1. 実装はAIに任せる。PMも置かない3人のチーム

――まず、IDEATION Cloudがどんなプロダクトで、どんなチームなのかを教えてください。
高橋：
IDEATION Cloudは、AIと世界中のスタートアップデータベースを活用し、成功確率の高い事業アイデアを生み出すためのSaaSです。開発メンバーは、開発責任者の保、多和田、そして私の3人です。
保：
前提として、人間がゼロからタイピングしてコードを書くことは基本的にしません。実装はClaude Codeなどのコーディングエージェントに委ねています。PMもあえて置かず、エンジニアが担当機能の実装責任を持つアジャイル開発を基本にしています。
多和田：
3人と聞くと少なく感じられるかもしれません。ただ、AIをパートナーとして徹底的に巻き込んでいるので、従来型のAIを使わない開発よりも速いペースで新機能が進んでいる実感があります。もっとも、最初から順調だったわけではありません。

2. 実装が速くなって詰まったのは、人間の側だった

――AIに実装を任せて、どんな課題が出てきましたか。
高橋：
コードを書く速度は圧倒的に上がりました。ところが、その周辺が詰まったんです。AIが書いたコードを取り込むPull Request（PR）の作成、人間によるレビュー、仕様書やドキュメントの更新。AIが速く走るほど、チェックして整理する人間の作業が追いつかなくなり、開発者体験が損なわれていきました。
多和田：
実装が速くなっても、PRの作成や動作確認、ドキュメント更新に何時間もかかっていては、プロダクト全体のリードタイムは縮みません。AIの速度に人間が溺れそうになっている、という感覚でした。
保：
だからこそ、実装の前後にあるプロセスをどう最適化するかが勝負になりました。人間の認知負荷と作業負荷を下げ、開発に集中できる環境をつくる。ここに挑戦する必要があったんです。

3. 解き方は「AIのためのレール敷き」

――どんな方針で解消していったのでしょうか。
多和田：
軸は、AIが適切に働くための「レール」を人間が敷くことです。AIは優秀ですが、私たちのチーム独自の文脈や、プロダクトの暗黙知は持っていません。自由に書かせれば、チームのルールから外れたコードが出てきます。そこで、人間が「この型とルールで動く」というレールを定義し、その仕組み自体も毎日改善するループを回しています。
保：
残る2つの方針は、ドキュメント運用コストの最小化と、定型業務のフォーマット化です。ドキュメントは細かく作るほど、最新に保つコストが膨らみ、陳腐化のリスクも増えます。そこで、何をドキュメントにするかという判断基準そのものを明文化しました。

――具体的な取り組みを教えてください。
高橋：
一つは、実装に入る前に、AIと仕様や設計を擦り合わせることです。状況に応じて仕様のすり合わせやUIだけを行う変更を出し、人間のレビューを挟むこともあります。いきなりコードを書かせず、まずAIが仕様書を作り、人間が確認して承認します。設計書、実装手順書も同じ流れで、すべて承認されてから初めてAIが実装に入ります。「何を、どう作るか」を先に合意しておくので、「思っていたものと違う」という手戻りが減りました。
多和田：
フロントエンドでは、Figma MCP（Model Context Protocol）も使っています。デザイナーがFigmaに描いたワイヤーフレームを、そのままAIに渡せる仕組みです。デザインの意図を示すアノテーション、Auto Layoutの構造、変数設定をAIが読み取り、コードに落とし込んでくれます。
保：
ただ、これはデザイナーの協力があって成り立ちます。「Figma MCPで読み込みやすいデータの作り方」を事前にすり合わせ、検証してから実装フローに組み込みました。

――ドキュメントの管理はどうしていますか。
多和田：
更新ルールは、あえて厳密にしていません。すべてを書こうとせず、必要ならコードを読むか、メンバーに直接確認する。割り切った方針です。
高橋：
置き場は、esaとGitHubリポジトリの2か所に分けています。esaに残すのは、「重要度が高い」「変わりにくい」「属人化しやすい」の3つを全て満たす知識だけです。開発環境の構築手順や、チームの共通ルールなどですね。
保：
コードの変更に連動して古くなる情報は、リポジトリ内に置きます。AIや人間と擦り合わせた仕様書や設計書、意思決定の経緯などです。整合性を保ちやすく、AIにとっても参照しやすく、変更しやすいからです。

4. 個人の知見を「skills」に。レビューはAIが先に走る

――個人のノウハウも仕組み化していると聞きました。
保：
メンバーそれぞれが持つ「こう見たい」「こう進めたい」という観点を、頭の中に留めず、プロンプトの集合体である「skills」にしています。これでチーム全員が同じ観点を再現できます。たとえば高橋が作った「/code-cleaner」は、副作用と純粋性の観点でコードをレビューし、承認した箇所だけをリファクタリングします。
多和田：
高橋が作った「/release-announce」も地味に助かっています。PRの差分からビジネスメンバーに向けたSlack告知文を自動で作ってくれるので、他メンバーの実装を追ってお知らせを書く負担が軽くなります。こういう細かい部分の仕組み化も大事にしています。
高橋：
PRの文章も、何をどの観点で書くかをskillsに組み込んでいます。考える手間が減り、一定の品質のPRが揃うので、レビューする側の負担も下がりました。

――コードレビューも自動化されているのですね。
高橋：
実装が速すぎて、人間のレビューが追いつかなかったんです。そこでGitHub Actionsを使い、PRの作成や更新と同時にAIレビューが走る仕組みにしました。CodeRabbit、Claude Code、Copilotの3つを同時に動かしています。

――AIに任せて、品質は大丈夫なのでしょうか。
保：
そこは私たちも重く見ています。AIは「動くコード」を素早く出しますが、見えにくい欠陥を抱えやすいことも指摘されています。だからこそ、レビューを多層にしています。人間がPRを開く前に、AIが一次レビューと修正案の作成まで済ませます。人間はその内容を確認し、取り込むかどうかを判断します。
そのうえで、最終的にマージするかどうかの判断と、品質の責任は人間が持ちます。使うツールも、Relicの全社ルールに沿って申請し、許可を受けたものです。AIを動かす環境も、定められた範囲に限っています。
多和田：
その分、人間がレビューにかける時間は、本当に判断が要る部分に集中できるようになりました。

5. 次の壁は「判断の疲れ」と「学びの減少」。原点回帰し、人間同士の対話を増やす必要性も

――これらの改善で、どんな成果がありましたか。
高橋：
実装からPR作成、Slackでのレビュー依頼までの流れが整い、開発全体のリードタイムは大きく縮まりました。何より、タイピングや定型文づくりから解放され、機能設計や複雑な課題の解決といった本質的な仕事に集中できるようになったと感じます。

――AIを活用したからこそ見えた、新たな課題はありますか。
保：
2つあります。1つ目は、技術的な判断の負荷の増大です。「動く」ことは、AIのおかげで確かめやすくなりました。難しいのは、拡張性、安全性、運用のしやすさといった、画面を見ただけでは分からない部分の判断です。AIが大量のコードを猛スピードで提案してくれるので、「この設計で本当にいいのか」という判断を絶えず求められます。判断の頻度が上がり、頭の体力をかなり消耗します。
多和田：
2つ目は、学びの機会の減少です。AIレビューが優秀で自動的に修正案が出るため、これまでPRのコメント欄で「ここはどう書くのがよいか」と議論しながら共有していた知識やノウハウの交換が、自然と減りました。

――その壁に、どう向き合いますか。
高橋：
3人で同じ画面を見ながら判断する時間を、意図的に増やせないかと話しています。
保：
1人でAIと向き合い続けると判断は重くなります。専門家同士で議論すれば、判断の精度も上がりますし、減ってしまった学びの機会にもなり、一石二鳥だと考えています。
多和田：
AIのおかげで生まれた「余白」を、人間同士のリアルタイムな対話や、新しい取り組みへの挑戦に投資していきたいです。もっと創造的で、楽しい開発の場にしていきたいですね。

おわりに：両輪で、大志ある挑戦を支え続ける

実装をAIに委ね、人間は「レール敷き」と「設計判断」に集中する。IDEATION Cloud開発チームの取り組みは、単なる効率化にとどまらず、エンジニアの役割そのものが変わりつつあることを示していました。
印象的だったのは、その泥臭さです。テンプレートを整え、判断基準を明文化し、デザイナーとデータの作り方をすり合わせる。華やかなAI活用の裏には、地道な積み重ねがありました。そして、新たに見つけた壁にも、仕組みとチームの対話で向き合おうとしています。
事業共創カンパニーRelicは、新規事業開発を「支援する」だけでなく、パートナーとして共に創る立場にあります。ビジネス、テクノロジー、クリエイティブを併せ持つBTC組織として、挑戦の現場で得た知見を、今後の事業共創にも活かしていきたいと考えています。
ビジネスとテクノロジーの両輪で、大志ある挑戦に向き合いたい。そんなエンジニアの方は、ぜひ一度お話ししましょう。

関連記事
非エンジニアがAIで作るシステムを、どう統制するか。Relic CTOの大庭が、自社のヒヤリハットと対策を語りました。

生成AIで激変した“野良システム”問題　ヒヤリハットが起きたRelicはどう対策したか非エンジニアでもAIを活用することで業務効率化に役立つシステムを構築できるようになる今、組織で管理されていない「野良システatmarkit.itmedia.co.jp

事業共創カンパニーRelicでは、共に挑戦するエンジニアを募集中

「事業を創る人を、創る」ことを掲げるRelicでは、積極採用中です。少しでも興味が湧いた方、ぜひ気軽にお話ししましょう！