こんにちは。LINEリサーチプラットフォームで企画を担当している葛貫と、開発を担当している上土井です。
2026年8月6日に福岡で開催された社内イベント「AIDD Workshop in Fukuoka」に、企画・開発・ビジネスの混成チームで参加し、AIDD（AI-Driven Development）について一通り触れてきたので、当時の感想や得た知見などを紹介します。
私たちがWorkshopに持ち込んだのは「AIで各自のアウトプットは増えたのに、なぜプロダクト開発全体は速くならないのか」という課題であり、1Dayの実践はこの問いに対する実験でした。結論から言えば、ボトルネックは工程の外、チームの構造にありました。そしてAIは、そのチームの構造を変えるきっかけになりました。
なぜ速くならないのか──ボトルネックはサイロにあった
私たちのチームでは、AI活用自体は各ロールで進んでいました。ビジネスサイドは顧客の声の収集や要約に、企画は企画書やドキュメントの作成に、開発はコード生成に。各自のアウトプットは明らかに増えました。それでも、機能がユーザーに届くペースは体感でほとんど変わりませんでした。
理由は、企画・開発・ビジネスがそれぞれサイロ化していたことにあります。従来の流れは以下の通りです。
「ビジネスサイドの課題をもとに企画が企画書を作る」→「企画書レビューを通し、開発チームへ相談する」→「開発から別方針が提示されれば持ち帰り、合意後に 実装開始」
実装中に出た疑問はQ&Aとして積まれ、企画が回答し、仕様が変わればドキュメントと実装をやり直す。
このプロセスでは、企画がビジネスと開発の情報を集めてアイデアを具体化する「間を取り持つ役割」を担っていました。しかし、企画は開発のコードを読めるわけではなく、ビジネスサイドの一次情報がそのまま入ってくるわけでもありません。一方、開発からは「実際の利用者像やユーザーが何に悩んでいるのか」が見えない。ビジネスサイドからは「開発が何に悩み、どんな技術的制約を抱えているのか」が見えない。全員が自分の専門領域に閉じ、各領域が保有する情報に相互にアクセスすることはできない。この構造こそがボトルネックであり、ボトルネック理論が教える通り、そこを放置したまま各工程をAIで高速化しても、全体のスループットは変わらないのです。
したがって、私たちは1Day Workshopをこのサイロを崩す実験として設計しました。
題材：アンケート集計機能のMVP（Minimum Viable Product）
LINEリサーチは、アンケートの作成から配信・回収を一貫して行えるリサーチプラットフォームを社内外に提供しています。プラットフォームに搭載されている集計機能は部分的な提供で、プラットフォーム利用者であるリサーチの専門家は別途で外部の集計ソフトを利用しています。一方で、プラットフォームの提供範囲拡大に伴い、集計ソフトを扱えない利用者から集計機能を要望する声があり、今回のWorkshopの題材として取り扱いました。
「専門家ではないリサーチ担当者でも調査終了後に複数のクロス集計条件を設定し、報告書作成に使えるCSVを取得できる。」
今回はこのようなコンセプトを設定し、最も基本的な集計手法であるクロス集計だけにスコープを絞り、グラフやダッシュボード機能は見送りました。
もう1つ決めたのは、プロトタイプで終わらせないこと。実装して検証環境にデプロイして関係者が実際に検証できる状態まで持っていくことをゴールとしました。
前日までの準備：チームのAIを育て始める
「AIコーディングエージェントは渡されたコンテキストしか見ない。準備した分だけ当日の成果が伸びる」とWorkshop運営からは案内されており、事前準備には時間をかけました。
- 事前ヒアリングシートで、ゴールの1文、制約、当日触る範囲、そして当日の最終判断者を固定しました。
- 企画側は、企画仕様書そのものをAIで作成しました。画面イメージも従来のキャプチャ付きドキュメントではなく、HTMLモックとして用意。要求仕様はMarkdown化してAIが読める場所へ集約しました。
- 開発側は、以前から整備していたAI向けドキュメントのリポジトリ、企画の要求と上流設計を蓄積する仕様リポジトリ、チームで使っているPRレビュー用のAgent Skillを持ち込みました。
そして前日、東京の企画および事業戦略のビジネスメンバーが福岡へ出張し、各関係者が対面で最終すり合わせをしました。ここですでにサイロの壁は崩れ始めています。
「そもそもなぜ集計機能が必要とされているのか」というビジネスの背景から、技術的制約、将来の技術的負債への懸念まで、全員の視点を言語化してAIが読める形で共有しました。
振り返れば、企画・開発・ビジネスそれぞれの文脈を1か所に集めてAIに読み込ませるこの準備が、「私たちのプロダクトの専門家」としてAIを育てる第一歩になっていました。
なお、正直なところ、準備でいちばん時間がかかったのは企画・ビジネスサイドの環境構築です。GitHubアカウントの取得、AIコーディングツールのセットアップ、Skillの導入。エンジニアには当たり前のことが、企画・ビジネスサイドには大きなハードルでした。
当日：要求整理から検証環境デプロイまで
当日は10時開始。AIDDの標準プロセス（Inception → Construction）に沿って進めました。
- 午前：既存コードのリバースエンジニアリング、要件分析
- 昼 〜 14時すぎ：ユーザーストーリー、実行計画、アプリケーション設計、作業単位（Unit of Work）への分割
- 午後 ：集計コア、管理API、フロントエンド、統合検証の4ユニットを順に実装
- 夕方：ビルド・テスト、検証環境へのデプロイ、実データでの動作確認
サイロが崩れたと感じた場面が3つあります。
場面 1：AIの「ビジネス概要」が実態とズレた
リバースエンジニアリングでAIが生成したビジネス概要は、コードベースから読み取れる範囲に限られ、実際の事業内容とズレていました。ここでビジネスサイドが用意していた事業説明資料や企画書を投入し、全面的に見直させました。コードしか知らないAIは「開発視点のサイロ」に閉じます。どこまでの背景情報をAIに読ませるかを人が判断することが、生成物の質を直接決めました。
場面 2：AIからの質問数十件に、その場で意思決定した
要件分析の段階でAIは仕様の曖昧な点を選択肢付きの質問として数十件ほど出してきました。CSVの文字コードはどうするか。集計開始後に閲覧権限を失った利用者はいつまで結果を取得できるか。処理は同期か非同期か。
従来なら実装中にQ&Aとして積まれ、確認と持ち帰りで数日かかっていた種類の論点を、企画・開発・最終判断者の同席によって1件ずつその場で意思決定できました。
場面 3：質問の向きが双方向になった
開発から「この機能、ユーザーは実際どう使っているんですか」というビジネスサイドへの問いが生まれ、ビジネスサイドからは開発が抱える技術的課題が見えるようになりました。企画メンバーも各自AIを操作し、自然言語でGitHubのPull Requestを読み、コメントしました。それぞれの専門領域を越えた質問が飛び交うことで、AIに渡る文脈も自然と厚くなっていきました。
この日に実感した変化を一言で言うなら、速くなったというより、深くなったです。要求のすり合わせなど、最初の議論にはそれなりに時間をかけています。そのかわり、AIが出してくるアウトプットの質が明らかに上がりました。
従来なら2回、3回と作り直してやっと到達していた解像度のものが、1回目から出てくる。各職種の視点・議論の結果が最初から成果物に織り込まれた結果です。
コードが速く生成されても、解くべき課題がずれていれば作り直しが発生します。作り直しが減る分、スピードが結果としてついてきます。
| 観点 | 従来（As-Is） | Workshop（To-Be） |
|---|---|---|
| 要求・仕様の整理 | 企画書を作成し、レビューの往復を経て確定 | AIの質問に意思決定者がその場で回答 |
| 企画→開発のハンドオフ | 開発相談・持ち帰り・再レビュー | 同じ場で設計と実装へ接続 |
| 視点の共有 | 企画が仲介役、他領域の情報には相互にアクセスできない | AIを介して全員が同じ文脈を参照 |
| プロトタイプ | 試作の依頼自体に開発リソースが必要 | 1Dayで動くMVP |
| 実装時の動作検証 | 実装完了後に開始 | 実装と並行してコードレビューと自動テスト |
結果：できたこと・できなかったこと
1日の終わりに残ったものです。
- 動くクロス集計MVP：単一回答・複数回答・マトリクス設問のクロス集計、集計母数の切り替え、CSV / ZIP 出力
- バックエンド・フロントエンドの自動テストの完走と、既存集計機能の回帰テスト
- 検証環境へのデプロイと、実データを使った動作確認
- 企画・開発プロセス上の手戻りなし
一方で、できなかったことは以下です。
- 検証環境でのQAは未実施
- 権限のない利用者を拒否する系統の実地検証は、証跡が残っていない
- AIが生成した大量の設計ドキュメントは、当日中にレビューしきれなかった
Workshopでは「1Dayで本番リリース」は最初から目標にしておらず、通常の開発フローの入口として設計していました。成果物はその後のスプリントでQAチームの検証フェーズへ進んでおり、ブラッシュアップの上で近いうちのリリースを予定しています。この進め方自体も、次の案件への適用を検討しています。
ボトルネックはどうなったか──サイロは崩れた
「なぜ速くならないのか」の答えだったサイロは、AIをチームの中心に置いたことで崩れ始めました。今までボトルネックがあってできなかったことが、AIによってできるようになったのです。
従来の構造は、ビジネス → 企画 → 開発 → 検証という直列の流れで、間をつなぐのは人間の役割（主に企画による翻訳）でした。Workshop では、中心にAIがいて、企画・開発・ビジネスがそれぞれAIを介して同じ文脈を参照する構造に変わりました。
ビジネスはAIとの壁打ちの中で現行機能におけるユーザー課題を明文化できる。企画はコードレベルで仕様上の制約を理解した上で、ユーザー課題の解決案を模索できる。
それぞれの意思決定文脈をAIに取り込むことで、開発は「なぜこの機能が要るのか」という背景をユーザーストーリーの解像度で理解してから実装に入れるようになりました。
この形に今までできなかった理由は、専門性の限界です。ビジネスも企画も開発もすべてを理解して間を取り持てる人間、たとえるなら「超一流のCTO」がいれば、AIがなくてもこのプロセスは実現できたかもしれません。しかし、そんな人材は現実にはめったに存在しません。AIは、この「全領域を見渡す役割」をコモディティ化しました。どのチームでも、各職種が持つ知識や判断の背景をAIが参照できる形で共有すれば、再現できるのです。
この経験から私たちは、AIを「育てていくプロダクトの専門家」として捉えるようになりました。事前準備とInceptionを通じて、各メンバーの視点・質問・判断がAIに取り込まれ、私たちのプロダクトに最適化されたAIの下地ができました。これを続けるほどAIは賢くなります。逆に、ビジネス視点を欠いたまま企画と開発だけで回し続ければ、開発プロセスは速くなっても、本当の意味でAIを中心としたプロダクト開発にはなりません。
次のボトルネックは意思決定へ
AIによってサイロ化は解消されましたが、その結果、ボトルネックは意思決定へと移りました。AIによって実装や調整の工数が大きく縮んでも、意思決定そのものはなくなりません。むしろAIDDにより開発ペースが速くなることで判断すべき場面の数が増え、それがプロダクトマネージャーに集中します。実際、Workshop以外の案件でAI駆動の進め方を試した際も、開発の負荷は大きく減った一方で、意思決定の負担が企画担当やビジネスサイドなどの意思決定者に集中しました。
私たちは、この新しいボトルネックにもAIで対処できると考えています。AIによって「なぜこの機能が要るのか」「今どういう状況か」が全員に透明化されるなら、意思決定の重要度をランク分けし、たとえば「画面ごとのラベルの統一」のような、重要度の低い判断は各メンバーへ委譲できるはずです。委譲した判断の「背景や決定事項」の報告・共有は、人間の運用に頼ると漏れが出ますが、そこも含めてAIエージェントのルールとして強制すれば防げます。重要度の高い判断についても、意思決定者に対し背景を交えた相談ができれば、意思決定のサポートにもなります。この、意思決定を集中から分散へ移す運用が、私たちの次の実験です。
再現するための条件と、次の一歩
もし、私たちと同じような悩みを抱える他のチームがAIDD Workshopの内容を試したい場合、必要な条件は3つです。
- 具体的な題材と狭いスコープ。「集計機能のMVP、出力はCSVだけ」まで絞ったため1日で回りました
- 意思決定者の同席。仕様判断で止まらないことが、フィードバックループ短縮の鍵でした
- ビジネス・企画・開発すべての文脈をAIが読める場所に集約すること。当日の成果は準備の質でほぼ決まっていました。とくにビジネスサイドの文脈を欠かさないこと
課題も残っています。チームの文脈を取り込んだAIは、現状、特定メンバーのローカル環境に依存しており、チームの共有リソースとして育てる仕組みをこれからつくる必要があります。開発職以外のGitHub権限、端末性能、AI基盤の応答速度とコストも、企画・ビジネスを巻き込む上での現実的な障壁です。また、AIが生成する大量の成果物に対するレビューと品質保証の仕組みは、開発の高速化と同時に整備しなければ、新たな負担になり得ます。
Workshop後、このAIDDの進め方はチーム全体に共有され、企画側では今回の要件定義の進め方をチーム標準のフォーマットとしてSkill化する動きも始まりました。
最後になりますが、まだAIDDを試せていない方々や試したもののうまく適用できなかった方々は、この記事の内容を参考に、まずは小さな機能を1つ選び、企画・開発・ビジネス・意思決定者を揃えて、それぞれの文脈をAIに読ませるところから始めてみてください 。
そして、AIDDとして新たなプロセスで動き始めた結果、次のボトルネックがどこに現れるかを観察してみてください。私たちは、次に取り組むべき課題はそこにあると考えています。私たちの場合、それは意思決定でした。
私たちにとってのAI活用も、個人の生産性からチーム・組織の生産性へと重心が移りつつあります。
