AIの出力は自然文でなく型で受ける

📝文章で受け取ると、後工程が毎回つまずく

「はい、以下が結果です」と前置きが付いたり、項目の並びが揺れたり。人が読むぶんには自然でも、機械で受けると崩れます。

最初は、AI に「この記事を分類して、要点を挙げて」と頼み、 返ってきた文章を次の処理でほどいて使っていました。 ところが、同じ頼み方でも、あるときは「承知しました。以下が結果です」と前置きが付き、あるときは箇条書きの記号が変わり、項目の順番も揺れる。

人が読むぶんには、どれも自然な日本語です。 でも、それを機械で決まった場所から取り出そうとすると、毎回どこかで崩れる。 AI が悪いというより、「自由に書いていい」と頼んだ私たちの受け口の問題でした。自由な文章は、機械にとっては形が定まらない入力です。

🔧答えの「型」を先に渡しておく

どの項目を、どんな種類の値で返すか。この設計図（スキーマ）を先に渡し、その形でしか答えられないようにしました。

切り替えたのは、答えの形を先に決めて渡すやり方です。「カテゴリはこの選択肢のどれか」「要点は文字列の並びで」「対応が必要かは真偽値で」―― というように、どの項目をどんな種類の値で返してほしいかを、設計図として先に AI に渡します。 いわゆる構造化された出力です。

こうすると、返ってくるのは前置きも飾りもない、決まった形のデータだけになります。後の工程は「この項目はここにある」と信じて取り出せる。 「承知しました」を毎回そぎ落とす小細工が要らなくなりました。 言葉で「余計な前置きは付けないで」とお願いするより、 形そのものを固定してしまうほうが、ずっと確実でした。

身近な例で言うと、このメディア自体がそうです。記事の見出しや説明、カテゴリ、タグを、 文章ではなく決まった項目の集まりとして持っています。一覧ページや、前後の記事への送りは、その項目を決まった場所から読むだけでいい。 表示を作る側が、本文をいちいち読み解いて情報を拾い出す必要がありません。 作った時点で形が決まっているから、後の工程がずっと素直に組めます。

✅形が合っているかを、機械で検証する

型を指定しても、たまに欠けや逸脱は起きます。だから受け取った直後に、設計図どおりかを機械でチェックします。

形を指定しても、ごくまれに項目が欠けたり、想定外の値が混じったりはします。 そこで、受け取った直後に「設計図どおりの形になっているか」を機械でチェックする関門を必ず通します。バリデーション、と呼ばれる工程です。

ここを通っていないデータは、後の工程に一切流さない。 AI の言い分ではなく、実際に形が合っているかどうかだけで合否を出します。動くはずのものが実は崩れていた、という事故を、 この関門が入口で止めてくれます。

🔁検証に落ちたら、AI自身に直させる

形が崩れていたら、その事実を添えてもう一度AIに投げ、直させる。人が毎回手直しに入らない形にしています。

では、検証に落ちたらどうするか。うちは、崩れているという事実を添えて、もう一度 AI に投げ直す形にしています。「ここが設計図と合っていないので、形を整えて出し直して」と伝えて、 自分で直させる。人が毎回手直しに入る運用にはしていません。

ただし、この直させる試みには回数の上限を必ず置きます。何度も落ち続けるなら、それは AI の出力の問題ではなく、 頼み方か設計図のほうがおかしい合図です。無限に投げ直させて費用と時間を溶かすより、 上限で止めて人が見に行く。この線引きが、任せきりの安全弁になっています。

🧭AIをパイプラインに組む人へ

「うまく書いてね」と願うより、答えの形を固定し、形を機械で検証し、落ちたら直させる。この3点で、任せられる範囲が広がります。

AI を処理の流れに組み込むほど、効いてくるのは「答えを自由に書かせない」という割り切りでした。表現の幅は、人に見せる最後の一歩に取っておけばいい。 途中の受け渡しは、形が定まっているほど壊れません。

明日から試せる順番は、こうです。 まず、どの項目をどんな値で返してほしいか、答えの形を書き出す。 次に、返ってきたデータがその形かを機械で確かめる関門を置く。 最後に、落ちたら上限つきで AI に直させる。 この 3 つを一本の線にするだけで、任せられる仕事の質が安定します。

あなたも、AI の答えを次の工程に流していますか。 もしそうなら――受け口を、文章から型に変えてみてください。