Google提唱の「SKILL.state」について。プロンプトに型の概念を導入

本記事では、AIエージェントの性能を高めるための「SKILL.state」という手法について、ざっくり理解します。 株式会社ナレッジセンスは、生成AIやRAGを使ったプロダクトを、エンタープライズ企業向けに開発しているスタートアップです。 この記事は何 この記事は、「SKILL.state」の論文について、日本語で簡単にまとめたものです。 本題 ざっくりサマリー 「SKILL.state」は、長時間稼働するエージェントの精度を上げるための新しい手法です。Google とPurdue大学の研究者らによって2026年8月に提案されました。 AIエージェントを使っていると、「会話が長引くほどバカになる」という感覚はありませんか？ なぜこれが起きるかというと、AIに入力している文字数が長過ぎることが原因です。 どういうことかというと、Claudeのような通常のAIサービスでは、過去の履歴を全部読ま

[mkusaka]

Google提唱のSKILL.stateを解説。会話履歴を捨てState JSON差分で更新し、200ステップで0.94維持・トークン12万に削減。

[hathewy]

良さそう。具体的な実践方法気になる　具体的な状態のスキーマ定義

[misshiki]

Googleら提案のSKILL.state。会話履歴を捨て、型付きStateだけを毎ターン更新。200ステップでもスコア0.94を維持し、617万→12万トークンに削減。

[yojik]

比較的長時間のタスクでこの手のアプローチを試したら「逐次的な現状のまとめの更新」自体をサボり、最後に一気にやるみたいなズルをされて悲しくなったことがある。

[yarumato]

“LLMとの会話は長引くほど精度が劣化する。そこでSKILL.stateでは会話履歴をAIに入力しない代わり現在の実行状態（State）だけ渡す。この手法が向くのは定型業務。事前に作業を定義できないイレギュラー業務には非向き”

[jintrick]

じゃあさっそくagyにつかってね

[strawberryhunter]

コンテキスト長で性能が低下していくのは一般的な問題だけど、特にGeminiの問題なのでは？モデルもこれに合わせて学習しないと、初動をやり直すだけだと思う。

[nilab]

「AIエージェントを使っていると、「会話が長引くほどバカになる」という感覚はありませんか？ なぜこれが起きるかというと、AIに入力している文字数が長過ぎることが原因です」

[fuji_haruka]

会話のいいところはキャッシュが効くところなので、コスト的にはあるサイズ、ターン数までは既存の形式の方が安いはず。

[irh_nishi]

こんなのみんな前からやってるんじゃないの。エージェントじゃなくてもタスク引き継ぎ問題もあるんだし。

[hogetax]

会話履歴どうにかならんかなぁと思ってたのでちょうどよかった。試してみる

[ochikun]

そしてプログラミング言語に行き着くと、、、

[doko]

仕様駆動開発は「意味・決定事項の状態化」、SKILL.stateは「作業進行の状態化」であり、どちらも「会話履歴を正本にしない」という同じ思想の別レイヤーでの実装である。

[uehaj]

今のチャットセッションみたいに全思考履歴を残すのではなく、状態を表す一変数RealWorldを思考機械に繰り返しくぐらせる。累積的に明示記憶を増大させるようなプロンプトは書けると思うが選択的明示的にやる