仕様が固まらない案件だからこそ、概要設計書をAIに書かせた

【目次】

AIが入っていない場所を探したら、上流工程が残った
なぜ「概要設計書」を選んだのか
「書き直させる」前提で、最初からAIに書かせた
つまずいたのは、スライドのデザインとUIのデザインの混在
ツール選定に、20分以上かけない
体感で2〜4倍。ただし数値化はこれから
生まれたバッファは、顧客の声を拾う時間へ
まとめ

こんにちは、ラクス技術広報です。

開発本部では、各部署でのAI活用の取り組みを技術広報がインタビューし、記事としてお届けしています。今回お話を伺ったのは、経費・請求・販売管理などのクラウドサービスを展開するラクスで、販売管理クラウドサービス「楽楽販売」の開発を担う 楽楽販売開発1課の前田啓佑さん です。

前田さんが取り組んでいたのは、コーディングでもテストでもありません。「概要設計書をAIに書かせる」 ——つまり、開発の上流工程そのものでした。

「AIでコーディングを行い、テストを行うのは当たり前になりつつある。じゃあ今、AIの導入が遅れている場所はどこか。そう考えていくと、上流工程が残るんです」

この記事はこのような方におすすめです。

コーディングやテストのAI活用は進んだが、その先の伸びしろが見えなくなっている方
仕様が固まりきらない案件で、設計ドキュメントの書き直しに疲弊している方
AIツールの選定・比較検討に時間をかけすぎていると感じている方

速くすること自体が目的ではありません。空いた時間を何に使うのか？ぜひ考えるきっかけになると幸いです。

AIが入っていない場所を探したら、上流工程が残った

前田さんが所属する楽楽販売の開発チームでも、コーディングやテストコード生成でのAI活用はすでに日常の一部になっています。課題として浮かび上がったのは、開発プロセス全体で見たときのボトルネックの位置 でした。

「上流工程が遅延すると、結局、開発タスクが下に降りてこないんですよ。下流だけをどれだけ速くしても、そこは詰まったままになる。ボトルネックは上流工程にあると感じました」

コーディングが2倍速くなっても、その前段の設計に時間がかかっていれば、リードタイム全体はほとんど変わりません。AIが入っていない場所こそ、一番効きやすい場所だった、ということです。

ここが今回の取り組みの出発点になりました。

なぜ「概要設計書」を選んだのか

上流工程といっても範囲は広い。その中で前田さんが最初の対象に選んだのが、概要設計書でした。楽楽販売の概要設計書には、少し特殊な事情があります。

「楽楽販売の概要設計書は、事業部向けの説明資料も兼ねているんです。なので、普段はGoogleスライドで作成しています」

読み手が開発者だけではないため、ドキュメントには内容の正しさに加えて「説明資料としての体裁」が求められます。テキストベースの設計書に比べて、作成にも修正にも手間がかかりやすい構造です。

そして、今回対象にした案件は、顧客の声から生まれた案件 でした。

顧客起点で始まった案件には、ひとつの特徴があります。解決すべき課題ははっきりしている一方で、それを どういう外部仕様で実現するかは、始まった時点では固まっていない ということです。

「具体的な外部仕様はハッキリとはしておらず、概要設計を何度も書き直すことになるのは明白でした」

書き直しは「起きるかもしれない」ではなく「明白だった」。この見通しが、次の判断につながります。

「書き直させる」前提で、最初からAIに書かせた

普通の順序であれば、まず人間が叩き台を作り、AIには補助的に手伝ってもらう、という発想になりそうなところです。前田さんは、その逆でした。

「最初からAIを使って書き、AIを使って書き直させる。そういう固い意思で概要設計を作り始めました」

使ったのは、Anthropicが2026年4月に公開した「Claude Design」です。テキストでの指示や対話を通じて、スライド資料やプロトタイプ、LPなどを作成できるツールで、執筆時点ではリサーチプレビューとして提供されています。前田さんはこれを使って、設計書のスライドそのものを生成しました。

前田さんの言葉で印象的だったのは、「思いの外、精度が高いものが作れることに驚いた」 という点です。当初から成功を確信していたわけではなく、書き直し前提だからこそ試せた、という順序でした。

さらに効果が大きかったのは、修正フェーズだったといいます。

「『こういう修正をお願い』と言うと、全部のページに目を通して、修正すべき箇所を洗い出して修正してくれるんです。漏れなくやってくれる」

これは、スライド形式の設計書につきまとう典型的な問題に効いています。ページ数が増えるほど、一箇所の仕様変更が他ページに波及していることを見落としやすくなる。

「人間がやると、矛盾した記載が残ったりします。この辺はAIの方が優秀でした」

「速く書ける」だけでなく、「書き直しても整合性が壊れない」 こと。書き直しが前提の案件においては、こちらの価値のほうが大きかったと言えそうです。

つまずいたのは、スライドのデザインとUIのデザインの混在

もちろん、すべてがうまくいったわけではありません。前田さんが最も苦労したポイントは、スライドのデザインと、画面UIのデザインが、AIの中で混ざってしまう ということでした。

概要設計書では、新機能の画面イメージを説明する必要があります。つまり1枚のスライドの中に、

資料としてのレイアウト（見出し、余白、図解の配置）
説明対象であるプロダクトのUIデザイン

という、性質の異なる2種類のデザイン情報が同居することになります。AIから見ると、この2つは区別しづらい。

結果として、UIの説明図がスライドの装飾に引きずられたり、その逆が起きたりします。前田さんが出した結論は、分業させる ことでした。

「UIのデザイン案は、別で作らせた方が早くて綺麗なものができそうです」

ただし、前田さんはこれを「常に分けるべき」とは言いません。

「ただ、まだまだ修正が入るフェーズなら、叩き台としてこれで良い、と妥協するのも必要だと思います。効率を考えて使い分けるべきですね」

ここは、AI活用の実務でかなり効く判断だと感じました。「AIの出力品質をどこまで上げるか」ではなく「今このフェーズで、どこまで上げる必要があるか」から逆算する。 仕様が動く前提の段階で見た目を磨き込んでも、その労力の多くは次の書き直しで消えてしまいます。

ツール選定に、20分以上かけない

「なぜこの方法を選んだのか。他の選択肢と比較検討はしましたか？」

この質問への答えが、今回のインタビューで印象に残った部分でした。

「正直、こだわりはなかったです」

比較検討をしなかった、という話ではありません。前田さんが問題視していたのは、比較検討そのものにかかる時間 でした。

「今はどんどん新しいツールが出るし、料金プランの変更も1ヶ月単位で発生し続けています。悩んでいる時間が、開発速度を鈍化させる」

半年かけて選定した最適解が、選び終わった頃には最適ではなくなっている。変化の速度が意思決定の速度を上回っている領域では、慎重な比較検討がそのままコストになる、という指摘です。

「闇雲にやれば良いとは言いません。ただ、例えば20分調べて良さそうなツールを見繕って、その中から自分が良いと思うものを選んで、実際にトライアンドエラーを始める。その方が効率的じゃないかと思います。今のラクスに求められているスピードは、そういうことだと思っています」

ラクスの行動指針には「小さく試して大きく育てる」という項目がありますが、この判断はまさにそれを地でいくものだと感じました。机上で最適解を探すより、手を動かして得られる情報のほうが速くて確かだ という割り切りです。

なお、これは「検討を放棄してよい」という話ではないはずです。今回のケースでは、書き直し前提のドキュメント作成という 失敗コストの低い領域 から始めているという前提があります。試す場所の選び方とセットで受け取るのが実態に近そうです。

体感で2〜4倍。ただし数値化はこれから

では、実際どれくらい速くなったのか。

「まだ概要設計は完了していませんが、速度も品質も段違いであることは明らかです。体感ですが、2倍〜4倍は早く仕上がります。数値化できていなくて申し訳ないですが……」

ここは、記事としてもそのまま正直に書いておきたい部分です。現時点で計測された数値ではなく、進行中の案件における作業者本人の体感値 です。今後、案件が完了した段階で改めて振り返る余地が残っています。

一方で、前田さんが強調していたのは倍率そのものよりも、その手前にある事実でした。

「これまでAIが入っていなかった場所にAIが導入されるというのは、測れないくらいに改善効果が大きいと再確認しました」

すでにAIが入っているところをさらに磨いても、上がり幅はだんだん小さくなっていきます。一方で、ゼロだったところに入れたときの差は桁が違います。

伸びしろは、まだAIを使っていない場所にある。 これが今回の取り組みから得られた、最も再現性の高い学びだと感じました。

生まれたバッファは、顧客の声を拾う時間へ

最後に、他チームにも共有したいことを尋ねました。

「AIの進化で開発の現場が劇的に変化している昨今ですが、我々が求められている開発速度はこんなもんじゃない、と思っています。固定概念に囚われずに、もっと遥か高みを目指してほしいです」

そのために日々持ち続けたい問いとして、前田さんは2つを挙げてくれました。

手でやっている作業は、AIで代えられないか？
そもそも、やる意味がある作業か？

後者が併記されているのが重要なところだと思います。AIで速くすることと、そもそもやめることは、別の打ち手です。前者だけを追いかけると、不要な作業を高速に生産し続けることになりかねません。速くした先に何を置くかも、はっきりしていました。

「無駄を省くことで生まれたバッファーは、顧客の声を拾う時間などに有効活用して、より良い、求められるものを作り出していきたいです」

今回の取り組みの対象になった案件そのものが、顧客の声から生まれたものでした。顧客の声を聞く → 作る → その時間を捻出するために速くする → さらに顧客の声を聞く。 AI活用を、開発効率の話で終わらせず、顧客志向のサイクルを回す原資として位置づける。ここに、ラクスの開発組織がAIに向き合う理由が表れているように感じます。