あるデモで露呈した2つのAIの失敗：Claude Codeがスキーマエラーではなくスペル修正を試み、OpenAIがカスタムフィールドのマッピングを誤る

Prismatic でのワークショップで、エンジニアが B2B インテグレーションをストリーム上でエンドツーエンドで構築しました。2つのAIツールが異なる方法で失敗し、実際のエージェントの動作は混沌として非決定的であることを示しました。

Claude Code: 誤った問題を解決

Claude Code は JSON Forms を使用して約30秒で設定ウィザードをスキャフォールディングしました。生成されたウィザードは問題なさそうに見えましたが、テスト中に JSON スキーマのバリデーションエラーが表面化しました — 「アイテムが1つ未満であってはならない」というような内容です。エンジニアが Claude に修正を依頼すると、エージェントは次の数分間、スキーマエラーに対処する代わりにファイル内のスペル警告を修正しました。エンジニアは最終的に「スペル修正以上のことをしてくれるといいんだけど」と言って諦め、前夜のドライランからコードを貼り付けました。

OpenAI: 奇妙なフィールドで最初の試行はガベージ

インテグレーションは実行時に OpenAI を呼び出し、顧客の Salesforce スキーマと宛先アプリの間のデフォルトのフィールドマッピングを生成します。通常の Salesforce コンタクト（email から email、company から company）では問題なく動作しました — 著者によれば「退屈」なレベルです。しかし、故意に奇妙なフィールド名を持つカスタムレコードタイプ（Group name、Internet address、Physical place、Internet email address）では、最初の呼び出しでガベージが返されました。2回目の試行で正しく動作しました。

主な教訓

• 退屈なスキーマは LLM の価値を過小評価する — エージェントの使用が過剰に見える。奇妙でカスタムなケースこそが真価を発揮するが、ほとんどのデモでは簡略化のためにこれらを避ける。
• ライブでの失敗は成功よりも有用。 エージェントを扱ったことがある人なら誰でも、それが混沌としていることを知っている。「スキーマエラーではなくスペルを修正した」という動作は、ドキュメントでは予測できないものだ。
• 異なる失敗の形: Claude Code は必要なものはすべて揃っていたが、間違った問題に取り組んだ。OpenAI は答えを「知っていた」が、最初の段階ではそれを表面化しなかった。失敗の形は、各ツールをどのように展開するかの手がかりになるかもしれない。

著者は Prismatic で働いているが、リンクは共有せず、自己宣伝ではなく学習の機会に焦点を当てている。