Be Framework Blog

解像度を上げる：AIに必要なのは仕様書ではなくスキーマ

私たちはAIに曖昧な仕様書からコードを書かせてきた。本当にすべきは、AIに仕様書を書かせること——想像ではなく、観察によって。

AIエージェントに「タイトルを適切な長さでバリデーションして」と伝えると、毎回違う実装が返ってくる。あるエージェントは255を選び、別のエージェントは100を選び、3番目はバリデーション自体を省く。

"maxLength": 80, "minLength": 1 を渡せば、実装はただ一つ。毎回。どのエージェントでも。

自然言語の仕様書は非可逆圧縮だ。入力が曖昧であるほど、出力は発散する。

問題

仕様書はずっと散文で書かれてきた。「タイトルは適切な長さにすること。」全員がうなずく。半年後、「適切」はそれを読む開発者ごとに違うものを意味している。

人間だけが読み手だった時代——これはかろうじて機能した。人間はコンテキストを共有する。追加の質問をする。推測する。

AIエージェントは言葉を額面通りに受け取る。「適切な長さ」には額面がない。

プロセスとしての解像度向上

Be Frameworkは開発を解像度向上として捉える——曖昧な意図を、解釈の余地がなくなるまで研ぎ澄ます。

ユーザーストーリー  → 曖昧（人間の言葉）
ALPSプロファイル    → 構造化（状態遷移、セマンティクス）
Semantic-Ex         → 観察済み（データからの制約発見）
JSONスキーマ        → 明確（機械検証可能）
実装                → 収束

各ステップが一つのクラスの曖昧さを排除する。スキーマに至る頃には、意見は残っていない——事実だけだ。

Semantic-Ex

ALPSプロファイルとJSONスキーマの間に、Semantic-Exというステップがある。こう機能する：

  1. AIがドメインモデルから50件のリアルなフェイクレコードを生成
  2. AIが自分のデータを観察：最大長、null率、エッジケース
  3. AIが制約を提案：「50件中のタイトル最大長は73文字。80を提案します」
  4. 人間が承認：「80でいい」

ボトムアップの制約発見。トップダウンの布告ではない。

なぜAIが必要なのか

2つの性質が、AIをこの仕事に適したものにしている。

人間は良いフェイクデータを作れない。 最初の10件は丁寧に考える。残りはコピペだ。500件になると品質が崩壊する。AIは疲れない。仮定に偏らない。タイトルフィールドにURL、Unicode、空文字列——言われなくても自然にエッジケースを生成する。

人間は自己レビューができない。 データを書いた人は、自分が期待したものを見てしまう。コードレビューが存在するのはそのためだ——最初の目は判断力を失うから、2番目の目が必要になる。AIは生成と評価を別タスクとして行う。著者バイアスがない。自分が生成した50件のうち3件がタイトルフィールドにURLを含んでいることを、恥ずかしがらずに指摘できる。

私たちはこの限界を回避するために、何十年もかけて組織プロセス——コードレビュー、QA、ペアプログラミング——を構築してきた。AIにはその限界がない。

計画としてのスキーマ

AIコーディングエージェントを使ったことがあるなら分かるだろう。良い計画は良いコードを生む。曖昧な計画はカオスを生む。

スキーマは計画だ。型安全で、機械検証可能で、曖昧さがない。エージェントにJSONスキーマを渡して「バリデーターを書いて」と言えば——正しい実装は一つしかない。エージェントは逸脱できない。逸脱する先がない。

ALPSは状態遷移の曖昧さを排除する。スキーマはデータ制約の曖昧さを排除する。エージェントがコードに触れる頃には、創造的な判断はすでに下されている。エージェントの仕事は実行であり、判断ではない。

逆転

私たちはAIに曖昧な仕様書からコードを書かせてきた。本当にすべきは、AIに仕様書を書かせること——想像ではなく、観察によって。

データを生成する。パターンを観察する。制約を提案する。承認を得る。スキーマを生成する。それからコードを書く。

人間の役割は仕様書の著者から制約の承認者へとシフトする。書くことから判断することへ。データを想像することから、データを見ることへ。

これはエンジニアを置き換えることではない。エンジニアを本来いるべき場所に置くこと——判断を転写するのではなく、判断を下す場所に。