コーディングエージェントにスプレッドシート操作を教える - Witan Labs の Nuno Campos氏

コーディングエージェントがスプレッドシートを自在に操る方法：Witan Labs が挑んだ「REPL」と「検証エンジン」の実践

スプレッドシートの操作は、AI エージェントにとって従来のツール呼び出しでは解決できない難問でした。しかし Witan Labs のヌーノ・カンプス氏は、JavaScript の REPL（対話型実行環境）の導入と、高忠実度な計算・レンダリングエンジンによるフィードバックループの実装により、精度を 50% から 92% へと劇的に向上させることに成功しました。

本記事では、複雑なドメインにおける AI エージェントの実用化に向けた、彼らの具体的なアプローチと技術的転換点を解説します。

スプレッドシートが AI に難しい理由：見えない構造と推論の壁

スプレッドシートは人間にとっては直感的で視覚的な情報ですが、AI にとっては「構造化されたデータ」として認識するのが極めて困難です。Excel ファイルを開いた瞬間に収益表やチャートの構造を把握できるのは人間だけであり、LLM はその視覚情報を直接見ることができません。

例えば「収益は？」と問われた際、AI は以下の点を特定する必要があります。

• 純収益か総収益か、特定の項目の収益か
• どの四半期・年なのか
• 見つかった数字が実際の入力値なのか、それとも数式の結果なのか

このように、文脈を特定し、数式の依存関係を解読する必要があるため、単純なツール呼び出しでは限界がありました。当初は複数のエージェント（編集、計画、実行など）を分割して試みましたが、これでは文脈の連携が難しく、行き止まりに陥るケースが多発しました。

解決策：15 のツールを統合した「JavaScript REPL」への移行

Witan Labs がたどり着いた最大の転換点は、約 15 個あった個別のツール（ファイル操作、数式検索など）を、Node.js の REPL（対話型実行環境）という単一のインターフェースに統合することでした。

なぜ JavaScript か？

スクリプト言語である JavaScript を採用した理由には明確な意図があります。

• LLM が得意とする言語: トレーニングデータが豊富で、エージェントがコードを生成しやすい。
• サンドボックス化の容易さ: 安全に実行環境を提供できる。
• 状態の保持: コードモードとの決定的な違いは「永続的な状態」です。REPL を一度呼び出すと、変数の定義や中間結果が保持され、エージェントはその上で推論を積み重ねていくことができます。

これにより、以前は 10〜15 回に及んでいた逐次的なツール呼び出しが、単一のスクリプト実行で完結するようになりました。また、実際のファイル処理は C# で書かれたバックエンドで行い、エージェント側には JavaScript のメソッドを TypeScript の型定義として提示するだけで済むため、拡張性も高まりました。

「エージェントは REPL を使うことで、より短いスクリプト（平均 50 行程度）で複雑な処理を行い、各ステップの間に推論を挟み込むことが可能になりました。その結果、回答速度が向上し、タイムアウトするタスクはゼロに近づきました。」

信頼性を担保する「高忠実度フィードバックループ」

コード生成と同様に、スプレッドシート操作でも「実行して確認する」サイクルが不可欠です。Witan Labs は以下の 2 つのエンジンを実装し、AI に厳密な検証環境を提供しました。

1. 数式計算エンジン: エージェントが書いた数式を正確に計算し、結果を検証します。
2. レンダリングエンジン: スプレッドシートの見た目（レイアウト、書式）を画像としてレンダリングし、視覚的な整合性を確認させます。

この「真実の源」となる検証ループが機能するためには、エンジンの忠実度が極めて重要です。もし計算エンジンが Excel の数式の 50% しか対応していなければ、AI は「正しく動く」と信じて間違った数式を書き込み、エラーを引き起こすことになります。

「不完全なエンジンでは、エージェントは機能すると信じて数式を作成しますが、実際には実装されていないため誤った結果を得ます。検証ループの成否は、それを支えるエンジンの質に完全に依存します。」

評価手法の転換：LLM 採点から「決定論的比較」へ

このプロジェクトで最も手間がかかったのは評価プロセスです。当初は LLM をジャッジとして採用していましたが、「スコアの変化がエージェントの改善によるものか、評価者（LLM）の出力揺らぎによるものか」を判別できないという課題がありました。

そこで Witan Labs は「ゴールデンデータを用いた決定論的比較」へ移行しました。

• 事前に用意した入力値と期待される出力を持つスプレッドシート（ブラックボックス）を用意する。
• エージェントが生成したスプレッドシートに同じ入力値を適用し、期待通りの出力が得られるかを検証する。

この手法により、LLM の主観的な採点に依存しない、信頼性の高い評価が可能になりました。また、失敗の原因が「モデルの推論ミス」なのか「ツールのバグ」や「プロンプトの不備」なのかを特定するため、トレースとログの精査も徹底しました。

結論：複雑なドメインにおける AI エージェント設計の教訓

ヌーノ・カンプス氏は、このプロジェクトから得られた教訓として以下の点を挙げています。

1. 本物の言語を与える: 逐次的なツール呼び出しは「自作のスクリプト言語」に過ぎません。コードモードや REPL のように、エージェントが実際に得意とする言語を与え、状態を保持できる環境を提供すべきです。
2. フィードバックループの構築: ドメイン固有の計算エンジンやレンダリングエンジンを構築するコストは高いですが、信頼性を担保するために投資する価値は十分にあります。
3. インターフェースの重要性: 現在の最適解（REPL）が永遠に続くわけではありません。モデルの能力変化に合わせて、最適なインターフェースを常に再検討する必要があります。
4. ドメイン知識と評価: モデルに「何を教えるか」よりも、「何に注意を向けるか」を促すプロンプト設計や、決定論的な評価手法の実装が成果を分けます。

スプレッドシートという複雑なドメインで AI エージェントを実用レベルまで引き上げた Witan Labs のアプローチは、財務分析やデータ処理など、他の複雑なタスクにおける AI 自動化の指針となるでしょう。