プロンプトエンジニアリングでは、言語化能力の差が如実に出る
「Waterfall Boost」という名前のとおり、同社が構築するAI駆動開発環境は要件定義から保守運用までの従来のウォーターフォール工程を踏襲している。工程を組み替える選択肢もあったはずだが、所氏はこの選択について必然だったと振り返る。
背景にあるのは潮流の変化だ。生成AIが登場した当初はプロンプトでいかに分かりやすく、的確な指示を出すかがエンジニアの能力だと言われていた。それが仕様駆動開発やPlanモードなど、決まり事を先にドキュメントへまとめ、AIに認識させてから指示を出す方向へ潮流は移ってきた。
上位20%のエンジニアが優れているのは、抽象的なことを言語化する能力だと所氏は話す。なぜなら、これまで優れたエンジニアがやってきたことは「PCが理解しやすいシステムの書き方をプログラムにする」という作業であって、現在はその対象がPCからAIに変わっただけだからだ。
クライアントが漠然と語る内容を要件にまとめ、システムの形に作り直す。その翻訳こそ能力差が最も出る部分であり、だからこそプロンプトエンジニアリングでは出力品質が人によって異なった。
そこで所氏が目をつけたのが、以前から開発標準化の取り組みを進める中で作ってきたウォーターフォール開発に対応するドキュメントだった。工程の順番を踏めば形になるという手順が確立されている以上、そのドキュメントをプロンプト代わりに使えばよい、という発想だ。
従来のエンタープライズ開発において、不具合が発生する主要な原因の一つには要件定義段階の仕様書作成にあると所氏は考えている。
決めるべき要件が決まらないまま進む。詳細設計書を作らずに基本設計書から直接実装してしまう。その結果、必要な機能が欠落する。Waterfall Boostはこの抜け漏れを許さないエージェントを実装した。人間がプロセスを省略できない機能を置くことで、プロンプトを書けない人でもAI駆動開発ができるようにする設計だ。
また、ウォーターフォールには、ナレッジが蓄積しやすいという利点もあった。業界向けテンプレートとして仕様書を用意しておけば、そこを決めない限り次に進めないという縛りを設けられる。使うほどノウハウが溜まる構造を作りやすい。
あえてエージェントのナレッジを一元管理する
Waterfall Boostは3つのエージェントで構成されるが、3つの分割は始めから決まっていたわけではない。最初に生まれたのは、ドキュメントの品質をチェックするQA Agentだ。
先述した通り、ウォーターフォール型でトラブルのないシステムを作るなら、ドキュメントが非常に重要だ。そこでまず、人間が作ったドキュメントをAIがチェックし、問題点を指摘する仕組みを作った。当時はその先のコーディングやテストを人間が行っていた。
当時、実装工程を担うのは人間だったが、それでも効果はあった。AIのチェックでOKが出ない限り次の工程へ進めないという縛りによって、ドキュメントの質が安定したのだ。
「QA Agent」はウォーターフォールの各工程における成果物をチェックする
そして、次に開発したのがCoding Agentだ。QA Agentにより、質の高いドキュメントが揃ったため、それをそのままAIに流し込もうとしたが、通常のLLMでは想定どおりの成果物が上がってこなかった。
「外部のLLMにそのままドキュメントを流し込んでみると、想定外のものが出来上がってしまったり、セキュリティに穴があるものが出来上がってしまう可能性がありました」
そこで、UIの作り方、機能ごとのコードの書き方、使用するライブラリといったルールを定め、その範囲で動くエージェントを用意した。これがCoding Agentだ。このエージェントには採用するライブラリやオープンソースを規定しており、それ以外は使わせない仕掛けになっている。
「Coding Agent」がAIによる実装をコントロール
そして、QA Agent、Coding Agentを一つの流れで動かすにあたり、全体を管理する役割として、最後にProcedural Agentを開発した。従来、プロジェクトマネージャーが担っていたスケジュールや工程の管理を行うのがこのエージェントだ。
QA Agent、Coding Agent、Procedural Agentはいずれも、開発標準を集約したAgent Knowledge Baseを参照する。業界やクライアントごとの特徴を吸収しつつ会社として定めた範囲で動くようドキュメントに収めてあり、強力な中央集権型のナレッジ管理だ。
「Waterfall Boost」ではノウハウやルールを必ず遵守する
一般的なAIエージェントの展開方法と比べて特徴的なのは、個々のエンジニアによる調整を認めていない点だ。
「個人がAIをチューニングすることや、自分用にAIをカスタマイズするスキルファイルやルールファイルを置くことはできず、すべて一元管理しています。もしかしたら開発における楽しみが少し減ると感じる人もいるかもしれませんが、私は開発を標準化することこそ、品質を上げて、トラブルを減らし、最終的に楽しく仕事ができる環境につながると信じています」
所氏はあくまで「開発標準化」をベースにしたAI駆動開発の実現を目指している。それは、属人化の解消こそが、エンタープライズ開発におけるAI活用のカギである、という考えからだ。
この記事は参考になりましたか?
- この記事の著者
-
DeveloperZine編集部(デベロッパージン編集部)
DeveloperZineは、株式会社翔泳社が運営する、技術と組織の意思決定を支える情報メディアです。技術選定やチームづくりに向き合い、自分の判断を確かなものとしたいエンジニアやエンジニアリングリーダーに向けて、翔泳社主催エンジニアイベント「Developers Summit」とも連動しながら実践知...
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
-
関口 達朗(セキグチ タツロウ)
フリーカメラマン 1985年生まれ。東京工芸大学卒業後、2009年に小学館スクウェア写真事業部入社。2011年に朝日新聞出版写真部入社。2014から独立し、政治家やアーティストなどのポートレート、物イメージカットなどジャンルを問わず撮影。2児の父。旧姓結束。趣味アウトドア。
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
提供:株式会社トランスコスモス・デジタル・テクノロジー
【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社
この記事は参考になりましたか?
この記事をシェア
