顧客がチャット画面に「うちの会社の紹介ページを一つ作って」と言った瞬間、その一言が実際のタスクになるまでには、目に見えないいくつもの段階を経る。この過程を統括するのが、ONTLEのAI PMだ。ONTLEが顧客プロジェクトごとに一人ずつ付ける、担当者の役割を果たすAI(プロジェクトマネージャー)である。
この記事では、その「紹介ページ」のリクエスト一件が、最初の会話から完了までどう流れていくのか — そして曖昧な場面のたびに、AI PMが何を基準に判断するのか — を、実際のシーンを追いながら見ていく。
ONTLEの構造は、飲食店を思い浮かべると一目で分かる。
客がホールスタッフに口頭で注文すると(「辛いのを一つ、控えめで」)、ホールスタッフはその言葉を標準フォーマットの注文票に書き換えて厨房に通す(メニュー名・辛さのレベル・テーブル番号)。厨房は票を順番に掛けておいて調理し、料理ができたら客の前に配膳する。客が「これは辛すぎます」と言えば、修正依頼がふたたび厨房に入る。
ここで大事なのは、客と交わすすべての言葉が票になるわけではない、という点だ。「今日はいい天気ですね」といった雑談や、「辛いのと辛くないの、どっちがいいですか?」といった質問は、ホールで答えて終わる。ホールスタッフは「これは本物の注文だ」と思える言葉、つまり実行リクエストだけを選んで票を切る。
そして腕のいい厨房は、客を覚えている。「前より塩味を控えめに」という言葉や、常連の好みを思い出して調理に反映する。ONTLEでこの記憶装置に当たるのがナレッジONTLE — 顧客がこれまでONTLEに蓄えておいた資料を、実行担当があらためて取り出して参考にする仕組みだ。(実際に使われる場面は、後の第4段階で見よう。)
AI PMは、この飲食店の構造をほぼそのままソフトウェアに移したものだ。会話はホールで、実際の作業は厨房(タスクキュー)で処理される。では、「紹介ページを作って」という一言が、この厨房をどう通り抜けるのか、六つの段階で追ってみよう。
ある顧客がチャット画面に「うちの会社の紹介ページを一つ作って」と書いたとしよう。顧客はコマンドではなく、普段使っている言葉(自然言語)のまま会話すればいい。AI PMが真っ先にすることは、この言葉がただの言いかけなのか、実際に実行するリクエストなのかを見分けることだ。リクエストだと判断すれば、足りない情報がないかを問い返す。
たとえば「最近こういうサービスは多いんですか?」は、答えれば終わる質問なのでタスクには進まない。一方「紹介ページを作って、来週までに見せてください」には、何を(紹介ページを)と、どうしてほしいかという動詞(作ってほしい)がそろって入っている。このように「対象 + 実行動詞」がそろっていれば、リクエスト候補とみなす。
今回の例の「紹介ページを一つ作って」も、対象と動詞があるのでリクエスト候補だ。ただし、どんな会社なのか、何を盛り込むのかが空白になっている。だからAI PMは一人で決めつけず、「会社紹介ページをお作りします。どんな内容を盛り込みましょうか?」ともう一度尋ねる。すべての文をいきなりタスクに上げてしまうと「こんにちは」までリストに積み上がるし、逆に本物のリクエストを雑談として流してしまえば、何も起こらないからだ。
顧客が「会社紹介と連絡先、簡単な問い合わせフォームがあるといいです」と答える。すると、AI PMはこの会話をリクエスト票の下書きにまとめる。客の「辛いのを控えめで」を、ホールスタッフが票のフォーマットに書き写すのと同じだ。埋める欄は、たいてい四つある。
| 項目 | 説明 | 例 |
|---|---|---|
| 目的 | この作業がなぜ必要か | 新規顧客にサービスを紹介するため |
| 機能 | 何ができるべきか | 会社紹介、連絡先、問い合わせフォーム |
| 範囲 | どこまで含めて、何を外すか | 決済機能は除外、静的な紹介のみ |
| 形態 | 成果物の種類 | 「会社名.ontle.kr」のような専用アドレス(サブドメイン)で開くWebページ1つ |
ここでいう「サブドメイン」とは、大きなサイトのアドレスの前に名前を付けて、別個に開く専用アドレスのことだ。この下書きは、AI PMが勝手に確定しない。顧客にもう一度見せて確認を取る関所だ。足りない情報があれば、この場で「問い合わせフォームはメールで受け取る形でよろしいですか?」のように問い返す。「ホームページを作ってください」の一行だけ受けてすぐ着手すると、あとで「これじゃないんですが」が繰り返されるが、目的・機能・範囲・形態の四つの欄を先にそろえておけば、そのズレを手前で食い止められる。顧客が「はい、それで合っています」と言って初めて、次へ進む。
顧客がリクエスト票を確認した瞬間、リクエストに固有の番号が振られ、タスクキューに正式に載る。今回の例では「#123」が刻まれたとしよう。以後のすべてのやり取り(進捗の問い合わせ、修正依頼)は、この番号を基準に交わされる。
このとき、登録前のリクエスト票確認と、登録後の「レビュー中」は役割が違う。リクエスト票確認は、顧客が「この注文で合っている」とハンコを押す顧客との合意の段階だ。一方「レビュー中」は、このリクエストを実際に作る担当(次の段階で出てくる「ワーカー」)が、範囲と機能をあらためて精査し、技術的に無理がないかを吟味する実務レビューの段階だ。ここでさらに足りない情報が見つかれば、AI PMがもう一度顧客に尋ねる。
キューに載ったリクエストを実際に処理する実行プログラムを、ONTLEではワーカーと呼ぶ。厨房で票を見て料理人が調理を始める場面だ。ワーカーは、文章やコードを生み出す生成AIの力を借りて、リクエスト票に書かれた目的・機能・範囲・形態のとおりに成果物を作る。成果物は、リクエストの形態によって分かれる。
この段階で#123を手に取ったワーカーは、ナレッジONTLEを参考にする。ありふれた会社紹介ページを量産するのではなく、この顧客が以前に共有しておいたブランドガイドや製品リストをあらためて取り出し、その会社の色やロゴ・製品説明に合わせた「その会社らしい」紹介ページに仕上げる。
厨房がいつも順調とは限らない。もし参考にするブランド資料が足りず、ワーカーが途中で行き詰まった場合、リクエストは静かに消えたり、無理やり「完了」に回されたりはしない。「進行中」で止まったまま顧客の目に残り、何がさらに必要かをあらためて尋ねられる。
紹介ページの下書きができたからといって、自動で「完了」になるわけではない。ステータスが「確認待ち」に変わり、成果物が顧客に届けられる。料理が客の前に配膳される瞬間だ。顧客が自分で開いて判断する時間を与えるこの一欄があってこそ、意図とズレた成果物が勝手に完了処理される事故を防げる。
顧客が成果物を承認すれば、ステータスが「完了」に変わり、リクエストが締めくくられる。逆に「ロゴの色をもう少し濃くしてください」なら、修正依頼になってふたたびワーカーに戻り、第4〜5段階が繰り返される。
このとき、AI PMが見分ける基準が一つある。修正なのか、新規リクエストなのか。ものさしは、最初に合意したリクエスト票の「範囲」だ。「ロゴの色を濃く」は範囲内の手直しなので、#123をそのまま維持したまま作業し直す。しかし数日後に顧客が「決済機能も入れてください」と言えば、これは「決済機能は除外」で合意していた範囲を外れる。だから既存のリクエストに無理やり押し込まず、別のリクエストとして切り分けて新しい番号を与える。
これは、プロジェクト管理で最もよくある失敗原因として挙げられる「スコープクリープ(scope creep — 最初に合意した作業範囲が、要望が加わるにつれてじわじわ膨らんでいく現象)」を源から断つための核心原則だ。「紹介ページを一つ」が、あれこれ付け足されて正体不明に膨れ上がり、終わりの見えない作業になってしまうのを、ここで食い止める。
リクエスト一件がキューの中で通り抜けるステータスを整理すると、こうなる。
| ステータス | 意味 | このステータスで起こること |
|---|---|---|
| 新規 | リクエスト票が登録されたばかり | リクエスト番号の付与、ワーカー割り当て待ち |
| レビュー中 | ワーカーが範囲・機能を再確認 | 足りない情報があれば顧客に再質問 |
| 進行中 | ワーカーが実際に成果物を作っている | 文書・Web・アプリの形態で成果物を生成 |
| 確認待ち | 成果物ができて顧客の確認を待つ | 顧客に通知、成果物を届ける |
| 完了 | 顧客が承認した | リクエスト終了、成果物を確定 |
| 修正依頼 | 顧客が変更を望む | ふたたび進行中に戻って繰り返す |
顧客は、自分のリクエストが今どの欄にあるのかを、画面でリアルタイムに追える。
AI PMが質問だと判断して答えだけで終わった場合は、対象と実行動詞をそろえて言い直してください。「これできますか?」ではなく「じゃあこれで作ってください」のように。「何を + 作って/修正して」が付けば、リクエスト票の段階に進みます。
最初から全部埋めなくて構いません。分かる分だけ言っていただければ、AI PMが空欄を見て「これはどうしましょうか?」と問い返し、一緒に埋めていきます。ただし「形態」(Web・アプリ・文書)だけ先に決めておくと、リクエスト票がより早く確定します。
番号が振られた後は、チャット画面やリクエスト一覧で現在のステータスをいつでも見られます。タスクキューやコードを直接のぞく必要はなく、「今どの段階か」だけは常に表に出ています。
リクエスト票の「形態」欄に、必要な種類をあわせて書けば大丈夫です。ただし種類が増えるほど「レビュー中」の段階で確認することも増えるので、最初から形態を具体的に言っていただく方が早いです。
結局、よいAI PMとは「はい、承知しました」と早く答えるAIではなく、「これが本当にお望みのものですか?」と一度立ち止まらせるAIだ。「紹介ページを一つ作って」が#123になり、ブランド資料をまとった成果物になり、修正と新規リクエストに分かれていくまで — その道筋の節々に置かれたこの「もう一度の確認」こそが、流れていく言葉を、責任あるタスクへと変える信頼の核心である。
著者: チョン・ユナ