そもそもWorkspace StudioとGASは設計思想が異なる GASは、Google Workspaceを自動化・拡張し、Googleサービスと連携するためのクラウドベースのJavaScriptプラットフォーム（ローコード開発基盤）です。実行時間等の制約はありますが、外部へのデータ通信等、ユーザーは自由度の高い実装が可能になります。

こんにちは。イノベーションセンターの加藤です。先日私たちのLLMベースJSON生成についての論文がニューラルネットワーク分野の国際会議IJCNN2026 1 に採択され、ポスター発表を行いました。本稿ではその発表内容を紹介します。 プレプリントはこちら： https://arxiv.org/abs/2605.13076 IJCNNについて LLMベースJSON生成 既存手法の問題点 提案手法 今後の方向性 IJCNNについて IJCNN（International Joint Conference on Neural Networks）は、ニューラルネットワークをはじめとするAI分野を対象とした主要な国際会議のひとつです。ニューラルネットワークの理論から応用まで幅広いテーマを扱っており、近年は深層学習や大規模言語モデル（LLM: Large Language Model）に関する研究も多く発表されています。 今年のIJCNN2026は、進化計算を扱うIEEE CEC（Congress on Evolutionary Computation）およびファジィシステムを扱うFUZZ-IEEE（International Conference on Fuzzy Systems）と合同で、IEEE WCCI（World Congress on Computational Intelligence） 2 として6月21日から26日にオランダのマーストリヒトで開催されました。 この合同会議は2年に一度開催される計算知能分野の大規模な国際会議であり、分野を横断した活発な議論や交流が行われました。 LLMベースJSON生成 LLMはチャットボットのように人間向けの文章を生成するだけでなく、その出力を外部のプログラムに繋ぎ込むことで、より高度なシステムを構築できます。近年注目されているLLMエージェントは、下図のように複数のLLMやツールを連携させて複雑なタスクを遂行しますが、こうした連携ではLLM同士やLLMとツールの間でやり取りされるデータが機械的に解釈可能である必要があります。 このような用途では、決まったスキーマに従うJSONをLLMに生成させることが定番の方法となっています。JSONはキーと値の対応が明確で、多くのプログラミング言語で標準的に扱えるため、LLMの出力を後段のプログラムに渡す際のインターフェースとして広く使われています。実際、OpenAI 3 やGemini 4 など主要なLLMプロバイダはStructured Outputという名称で指定したスキーマに沿ったJSONを生成するAPIを提供しています。 一方でLLMは元々自然言語でのやり取りを前提にデザインされているので、プロンプトで「JSONのみを出力してください」と指示するだけでは、余計な説明文が混ざったり括弧の対応が崩れたりして、文法的に正しくない出力となることがあります。そこで、プロンプトのような確実性のない手段に頼るのではなく、生成の段階で選択できるトークンの候補を適切に制限することで、出力を必ず目的のフォーマットに従わせる文法制約付き生成（Structured Generation, Grammar Constrained Generation）が用いられています。 一般的な文法制約付き生成では対象とする文法のパーサーを利用します。 各生成ステップにおいて、パーサーはそれまでの途中出力を部分的にパースして次に来ることが許される終端記号を教えてくれます。終端記号とは、文法においてそれ以上分解されない最小の要素のことで、JSONでいえば { や } といった記号や、 true や false のようなキーワードが該当します。パーサーの仕様によっては文字列や数などの記述も終端記号として扱われます。対して、オブジェクト {"key": "value"} や配列 [0,1,2] のように複数の要素から構成される概念を表した記号を非終端記号と呼びます。このようにして提示された終端記号の候補をもとにして有効なLLMトークンを判定します。 より詳細な解説は こちらの記事 をご覧ください。 既存手法の問題点 文法制約付き生成のアルゴリズムはさまざまなものが提案されていますが、既存の手法はどれも停止性が保証されていないという問題があります。 LLMは無限生成を避けるため、あるいは推論コストや応答時間を抑えるために生成するトークン数の上限（ max_new_tokens 5 ）を指定することがほとんどですが、この最大トークン数の指定を文法制約付き生成と併用すると、JSONを閉じきる前に上限トークン数に達してしまったとき途中で切れたJSONが出力されてしまいます。 これは既存手法があくまで文法的に正しい続きのトークンを選択しているにすぎず、最大トークン数に達する前に出力が完成するかどうかは考慮されていないことが原因です。 私たちの論文ではこの問題に対して、文法的な正しさだけでなく将来必要になるトークン数を意識した制約を導入し、最大トークン数に達する前に必ず出力が止まる制約手法を提案しました。 提案手法 上記の問題を解決するために私たちの提案手法が必要とするのは、次に有効な終端記号だけではなく、そこから出力が完成するまでに続き得る終端記号の列です。将来的に必要となるトークン数を見積もるには、この先どのような単語がどれだけ続くのかを把握する必要があるためです。 このような「続きとして有効な記号列」の候補数や探索のための計算量は文法やそれに対応するパーサーの複雑さに依存して変化します。 私たちは有効記号列の計算を効率化するために、JSONの定義をLL(1)文法と呼ばれる形式で記述し、それに対応したパーサーを採用しました。LL(1)パーサーは1つ先の終端記号を参照するだけで内部状態を決定でき、続きうる記号列も一意に決定できます。そうして得られた「あり得る続きの候補」と、あらかじめ前計算しておいた「各記号を実現するのに必要なLLMのトークン数」をもとに、将来必要になるトークン数の最小値を求めることで、最大トークン数に達する前に必ずJSONが完成するように生成を制御します。 実験ではJSON Mode Eval 6 というJSON生成のベンチマークを使い、厳しい最大トークン数制約下では提案手法が常に文法的に正しいJSONを出力することを確認しました。それに加えて内容の正確性という観点では、Beam SearchやMonte Carlo Tree Searchのようなより良い出力を探索する生成手法と組み合わせた場合に、既存手法では効果がなかったのに対し提案手法では精度が向上することを確認しました。 今後の方向性 前述のとおり、提案手法では文法的な正しさは保証できましたが、内容の正確性についてはBeam SearchやMonte Carlo Tree Searchといったサーチ手法を併用する必要がありました。しかし、これらのサーチ手法は計算量の高さが課題です。 ポスター発表ではその課題を改善するための方向性についてのヒントをいくつか得られたので、より頑健な文法制約手法を模索しようと思います。 https://attend.ieee.org/wcci-2026/ijcnn-2026-topics/ ↩ https://attend.ieee.org/wcci-2026/ ↩ https://platform.openai.com/docs/guides/structured-outputs ↩ https://ai.google.dev/gemini-api/docs/structured-output ↩ https://huggingface.co/docs/transformers/ja/main_classes/text_generation#transformers.GenerationConfig.max_new_tokens ↩ https://huggingface.co/datasets/NousResearch/json-mode-eval ↩

社会インフラ業務で需要が増加しているGIS（地理情報システム）について解説します。代表的なツール（ArcGIS、QGISなど）の種類やトレンド、都市計画などの用途、活用に必要なプログラミング言語などの基礎知識をご紹介します。