こんにちは。LINEアプリ開発SBU AIディベロッパーエクスペリエンスユニットの Nagase Takuya です。
私のチームは、AndroidとiOSの開発者が混在する体制で、LINEアプリの機能開発を担っています。日々の開発と並行して、設計工程にAIを組み込んだワークフローの運用と改善に取り組んできました。今回は、AIに速く設計書を書かせる工夫ではなく、その前後にある「理解」と「共有」のワークフローをどう設計したかをご紹介します。
1. 成果物が増えて、人への負担が重くなった
AIエージェントは、既存のコードを調べるのも設計書を書くのも速いです。背景と課題を渡せば、両OSのコードを読み解いて、仕様書も基本設計も詳細設計も短時間で形にしてくれます。AIの進化と環境の整備が進むにつれて、日々の開発業務が速くなっていくのを体感していました。
前提として、私のチームの開発フローを説明します。AndroidとiOSの開発では、以前から双方で設計をレビューし、実装のズレが起きないようにしていました。しかし、細かい解釈の違いや設計時の考慮不足から、挙動のズレが後になって分かることもありました。
AIが導入される以前から、OSの差分に影響されない範囲の基本設計は、1人がまとめて進めていました。担当者が両OSの設計と実装を確認して、チームに共有して議論をし、合意が得られるまで修正を続けるというフローです。ただ、担当外のOSのコードまでは深く理解できないため、チーム内での共有時に初めて出てくる論点も多くありました。
図 1：1人が基本設計までをまとめて進め、そこからはチームでの議論と修正を、合意できるまで繰り返します。解釈のズレは合意の場で見つけます。
AIが普及したことで1人が調べられる範囲が変わりました。担当外のOSのコードを実際に確認する負担が下がり、両OSの状況をある程度深くまで把握しながら基本設計を進められます。ただ、AIが出した差分が正しいか判断するには、各OSの担当者による確認が欠かせません。そのため、合意の場は引き続き設けています。
このような開発フローの変化の中で、AIが賢くなるにつれて、人への負担が大きくなっていました。 特に重くなっていたのは、次の3つの工程です。
- AIの成果物を理解してレビューする
- 論点を理解してチームメンバーに共有する
- 次の作業担当者に引き継ぐ
AIが普及し始めた当初は、各自のやり方でAIを使って設計や実装の速度を上げてきました。ただ、AIと設計を議論する負担と、人に見せる資料を作る負担が大きくなってきました。要件定義 → 設計書 → チーム共有 → 議論 → 修正 → 資料作成 → 議論、という往復が繰り返される状況です。その度に、AIが生成した大量のドキュメントを理解し直して資料を作る必要がありました。
2. 3つの仕組みを改善した
そこで私たちは、設計書を書く速度をさらに上げるためではなく、AIと議論する人と、成果物を読む人のために仕組みを改善しました。
図 2：速いのは、AIが調べて書く部分です。仕組み1〜3は、増えた成果物を人間が受け取るために改善した仕組みです。以降の章で順に説明します。
この3つの改善が記事の中身です。その前に、私たちの開発手法の土台となったフレームワークを解説します。
3. AI-DLCを土台にして新しいワークフローを設計した
このような課題がある中で、チームで取り入れたのが AI-DLC でした。AI駆動開発ライフサイクル（AI-DLC）は、AWSが提唱している開発ライフサイクルの考え方です。私たちが特に参考にしたのは次の2点です。
- 初めからAIと並走しながら、要件定義・仕様検討・実装まで進める
- その間に、機械にとっても人間にとっても理解しやすい形式で情報を残しておく
AI-DLC では、要件定義から実装までをステージという単位に区切って進めます。ステージごとに成果物を作り、人間が承認してから次へ進む形です。私たちは入力・状況把握（リバースエンジニアリング）・仕様・基本設計・詳細設計・タスク分割・QA・振り返りの8つで運用しています。
以前は、この「資料の作成と議論の往復」をWikiの資料とチームの運用でカバーしていました。AI-DLCを導入してからは、資料の作成と記録の管理をAIに任せるようにしていきました。
また、この開発ライフサイクルは社内でも先行して実装 されていて、そこからも発想を借りています。社内では、AIを開発プロセス全体の協力者として使う考え方を AIDD と呼んで、組織として取り組みを進めています。ただし、そのままは使わず、私たちの開発スタイルに合うように運用しながら改善を進めていきました。
4. 仕組み1：AIとの質問形式の改善
ここからが改善した3つの仕組みについての話です。1つ目の「質問形式の改善」がいちばん手を入れた部分でした。4段階で変わっています。
- 解説と質問を1ページのHTMLにまとめる
- 論点に優先度をつける
- 「その他」を書けるようにする
- やり取りを記録として残す
4.1 第1段階：解説と質問を1ページのHTMLにまとめる
AI-DLCを利用すると、未確定なことや論点を、AIがチャットでの一問一答、もしくは1つのMarkdownにまとめた形で質問してきます。チャット形式では、「論点1はAとBどちらにしますか」と聞いて答えを待ち、反映して次へ進みます。ただ、論点の多い案件では往復が10回を超え、読む側が全体像を保持しにくいという問題がありました。Markdownでも同様で、背景の解説がほとんどなく認知負荷が高いという声が多く上がりました。また、全体像が分からないと一つひとつの質問にも答えにくく、ひとつずつ見れば妥当な選択を積み重ねても、全体として噛み合わない設計になることがありました。
そこでチャットでの往復やMarkdownでの質問形式をやめ、そのステージの成果物全体を説明する1ページのHTMLを 作って、そこに論点を並べる形にしました。ステージごとに overview.html という名前で置いています。
論点だけを並べても判断はできません。判断をするには文脈を理解する必要があります。そこで overview.html には、論点の前に背景と前提を置きました。いまの実装がどうなっているか、両OSで挙動がどう違うか、今回は何を変えない前提で進めるか。そのうえで、そのステージで何が決まり、何がまだ決まっていないかを並べます。この1ページを読むだけで、前提を理解したうえで判断できるようにしています。
各論点には、背景、何が問題か、選択肢ごとのメリットとデメリット、そしてAIの推奨が並びます。読む側は全部の論点を見てから、一度に回答します。
図 3：レイアウトを示すためのサンプルです。背景と前提から読み始めて、決まったことを確認し、最後に論点へ進みます。選択肢にはAIの推奨が付き、どれでもないときは自由記述欄に書きます。
4.2 第2段階：論点に優先度をつける
まとめて出せるようになると、今度は論点の数が増えて、回答の負担が大きくなりました。判断できる箇所を全部出すと10個以上になり、1ページで読み切るには多すぎます。
そこ で基準を作り、AIが前提を置いて進めていいものと、人間の判断が必要なものを分けました。 今決めなくても全体の設計を進められるものは、仮の前提としてAIに判断を任せます。人間に渡すのは「前提やスコープを左右する」「トレードオフがある」「設計全体に影響がある」ものだけです。あわせて重要度のラベル（major / medium / minor）を付け、minor は原則として論点にしません。
AIが自分で判断した項目には、「既存の実装にならい、〜と仮定」といった注記を成果物に残すようにしています。もしその前提に誤りがあれば、読んだ人が指摘をする想定です。判断を求めるものと、前提を明示して間違いがあったときだけ修正を依頼するものを区別しています。
4.3 第3段階：「その他」を書けるようにする
論点についての選択肢を考えるのはAIです。そのため、並んだ選択肢に適切なものが存在しないことがありました。そのとき選択肢の中から選ぼうとすると、良い設計に届きません。
そこで、各論点に自由記述欄と質問欄を追加しました。さらに、読む側がAIの提示にない論点そのものを足せるようにしました。実際、AIが立てた選択肢にない設計が採用されたことが何度もあります。
AIに選択肢を出させる仕組みは、放っておくと「AIが用意した枠の中で人間が選ぶ」形に固まってしまいます。選択肢の枠の外に出る導線を用意することで、枠の外にある案も最初から検討できるようにしました。
4.4 第4段階：やり取りを記録として残す
今は論点があるステージご とに、discussion-points.md という記録を置いています。中身は以下です。
| 記録する項目 | 中身 |
|---|---|
| 論点 | 何を判断する必要があるか。重要度のラベル付き |
| 背景 / 問題 | なぜその判断が必要になったか |
| 選択肢 | 各案のメリットとデメリット。採用しなかった案も消さずに残す |
| AIの推奨 | どれを推すか、その理由 |
| 人間の決定 | どの案を選んだか、その理由 |
| 反映先 | 決定を成果物のどこに書いたか（ファイルと節） |
却下した案とAIの推奨を消しません。結論だけを残すと「なぜそれを選んだか」が復元できないからです。ある案件では、この形で29件の論点が記録として残りました。
効いてくるのは、設計の再検討や振り返りのタイミングです。仕様や設計に不備が見つかったとき、どの判断が原因かを辿れます。これにより、いつでもそのポイントまで戻って、別の案を検討することができます。履歴がないと、再検討のたびに、過去にした検討をもう一度やり直すことになってしまいます。
5. 仕組み2：チーム内で論点について合意する
2つ目の仕組みは、新しく作ったものではありません。仕組み1の質問と資料の形式が、人間同士の合意にもそのまま使えました。 実際の手順はこうです。
図 4：1〜3は1人で、4〜5はチームで進めます。ここで大事なのは、3の時点で未決の論点を残しておくことです。
変わったのは、合意のタイミングで何をするかです。以前は事前に資料を作り、チームのメンバーに説明していました。そこで新しい論点が出てくると、設計を検討し直し、資料を修正して、また共有する必要がありました。
今は資料の中で、担当者が1人でAIと議論して決めたことと、まだ決まっていないことがはっきり分かれています。 どこに絞って話せばいいかが分かるので、その場は未決の論点に時間を使えるようになりました。また、新しい議論が出てもHTML内で回答や論点を作成し、AIにその情報を渡すだけで資料の改善と設計を進められます。
6. 仕組み3：進捗と決定事項を人間とAIが読める形で残す
3つ目の仕組みは、チームの中で envelope と呼んでいる機能です。狙いは、設計の中身と進捗の記録を、切り離して保存できるようにすることでした。ワークフローの手順や成果物の形は案件ごとに変わりますが、「今どのステージか、誰が何を決めたか、どの論点が未回答か、何を省略したか」という事実の形は変わりません。この2つが混ざっていると、片方を直すたびにもう片方を同様に修正する必要があります。
進捗の記録側はひとつのJSONにまとめています。入るのは、成果物の周りにある事実だけです。設計書の本文は入れず、場所を相対パス で指します。中身を持たないので、このワークフローから切り離しても進捗の記録だけで成立します。中身ではなく、設計書の本文へのパスと扱いだけが書かれた封筒。これが envelope という名前の由来です。
図 5：形が変わらない事実だけを封筒に入れ、形が変わる成果物は場所で指します。だから中身から切り離しても、記録だけで成立します。
進捗を記録するたびに、進捗ビューのHTML（progress.html）が自動で再生成されます。これが人が確認するメイン画面です。上に8ステージが横並びで配置され、完了・回答待ち・省略が色で分かります。その下には、いま進めているステージの overview.html がそのまま埋め込まれる仕組みです。どのステージにいるかと、そこで何を判断すればいいかを、同じ画面で確認できるようにしています。
図 6：レイアウトを示すためのサンプルです。完了し たステージ、回答待ちのステージ、省略したステージが色で分かれ、ヘッダーの「いま誰の番か」の行にも文章で出ます。引き継ぐときはこのページのリンクを渡します。
7. 新しいワークフローを取り入れて、セッションの引き継ぎがスムーズになった
ここまでの仕組みが揃って、作業の途中で担当者が代わっても、スムーズに引き継げるようになりました。要件定義とOS共通の基本設計を1人が書き、詳細設計や実装などは各OSの担当者が引き継ぐというフローは、AIの導入前後で変わっていません。
このフローをさらにスムーズに進めるために、私のチームでは次の4つを運用しています。
案件のすべてを1つのディレクトリに置く。 各ステージの成果物・状態ファイル・envelope・進捗ビューをそのディレクトリにまとめ、すべてGit管理下に置きます。目的は「セッションの履歴に依存する情報を作らない」ことです。セッションの中でしか決まっていないことがあると、その履歴を持っている人しか続けられません。
ステージごとにタグを打つ。 承認が下りた時点で、成果物・envelope・進捗ビューを同じコミットに入れてタグを打ちます。これで「どこまで人間の承認が終わっているか」がコミット単位で確定します。
引き継ぎ時は進捗ビューを使って共有する。 進捗ビューなどAIの成果物を、そのまま活用できます。受け取る側は、ディレクトリ内の情報だけで、どのステージが完了しているか、今どの状態か、未回答の論点が何件あるか 、誰がいつ何を承認したかを確認できます。すべての情報をGit管理下に残しているので、資料を作り直したり、引き継いだ人が新しくプロンプトを打ち込んだりする必要がありません。
判断の記録を成果物のほうにも残す。 実装に入れば、設計と現実の食い違いが必ず出てくるものです。設計書に「なぜそうしたか」が書いてあれば、引き継いだ人はその情報をもとに自分で判断できます。仕組み1の論点収集が引き継ぎ後のこのタイミングでも効いてきます。
8. まとめ
これらの仕組みを改善したことで、設計が止まらずに進むようになりました。
両OSの調査が一気に進み、そのまま議論すべき論点まで整理されて出てきます。HTMLでの出力と論点の出し方を作り込んだことでAIとのやり取りもスムーズになり、ワークフローの流れを崩さずに設計から合意まで進められます。 両OSの実装やタスクを途中で引き継ぐときも、新しくプロンプトを打ち込み直す必要がありません。生成されたHTMLで現在の状況を理解し、そのまま回答フォームとしてやり取りを再開できるので、引き継ぎのコストを大きく下げられます。
作ったのは設計書を速く書く仕組みではありませんでした。 出発点は「AIが速いのは、出すところまでだった」という観察です。設計書の理解や合意、引き継ぎも自動的には速くならず、むしろ成果物が増える分だけ重くなります。
改善した3つの仕組みを並べてみると、どれも同じ形をしていました。AIが速く大量に出せるようになった結果、それを受け取る側の人間の負担が重くなった。だから、受け取 り方そのものを設計し直しました。
調べる・論点を立てる・合意する・共有する。この間にあった手作業が、徐々になくなっていきました。 個々の工程が劇的に速くなったというより、工程がつながって人間が止まらずに作業できるようになった、という感覚に近いです。
8.1 これからやること
次に広げたいのは企画の担当者と一緒に進めることです。細かい仕様や要件定義を進めるためには企画の担当者との合意形成が欠かせません。論点を選択肢の形で渡すやり方は職種を選ばないはずで、企画のメンバーと一緒に要件定義から進める運用を計画しています。設計の入口にいる人と合意の形式を共有できれば、いちばん手前のつなぎ目もスムーズになるはずです。
AIの性能も、周辺のツールも、進化し続けています。半年前に必要だった工夫が要らなくなることも珍しくありません。だから私たちは今も改善サイクルを回しながら運用しています。仕組みを固定するのではなく、変わり続ける前提で仕組み自体も組むということです。
この記事に書いたのは、その途中経過です。
