すぐに曖昧になる二つの動機があると思う。a) 特定のコンテキストがうまく機能するのを見つけて、その一部を保存したり、説明を繰り返さなくて済むようにしたい b) セッションを続けて、最初からコンテキストを再構築しなくて済むようにしたい。Aはプロンプトライブラリや特定のエージェントファイルの一部として保存するのが合理的だと思う。Bは長期間続けると問題が起きやすいけど、比喩的なオレンジから最後の一滴を絞り出すのには役立つかも。私がやってしまったアンチパターンは、異なるタスクや役割のために異なる復元コンテキストを切り替えること。そうなると、必要ならもっと耐久性のあるドキュメントに変換するか、「全体のコンテキストを復元する」以上に特定のキュレーションをするべきだと思う。

もっと擬人化すると、「でも最初からやり直したくない、このインスタンスはもう重要なことを全部知ってるから」って感じになるよね。もしすべてのやり取りが独立したクエリ/レスポンスとして扱われるなら、要らない部分を省いて自分の要約と組み合わせることで集中しやすくなるんだ。

マネジメントは数字が好きだよね。X > Yで客観的に比較できる唯一のものだから。きれいなグラフや推計、予測が作れるし、数字が特に正確じゃなくても関係ない。データ収集のステップが正当化できればそれでOK。数字を大きくすることが良いことなら、なおさらボーナスポイントだね（例えば、重大な問題の数を追跡するのとは対照的に）。

何をインセンティブにしようとしているかによるね。パフォーマンスを測るのではなく、単にトークン消費を増やしてバブルとハイプを育てようとしている可能性もある。さらに、プレッシャーを感じた従業員がAIの新しいユニークな使い方を見つけるかもしれない。インフレが目標なら、たくさんのお金を配って、使われさえすれば目標達成って感じだね。

グッドハートの法則が実際に働いてるね。

これに賛成する意見も聞いたことがあるんだけど、経営陣はこれが副作用になることを知ってたけど、AIとできることを探るためにできるだけ人を巻き込むことが大事だと思ってるんだよね。結局、役に立つことを学べるかもしれないって期待して、意図的にお金を無駄にしてるってことだね。

今の仕事も全く同じことやってるよ。マネージャーがトークンの使用状況や関連メトリクスを示すツールを見せてくれた。

これがマット・ガーマン、究極のMBAだね。ボーナスは四半期ごとのトークンに結びついてるし、2026年にはエンジニアをコードの行数で測るのと同じことになる…だからAWSは何年も優秀なエンジニアを失ってるんだよね。残ってるのは、マクドネル合併後のボーイングみたいになってきてる…ドキュメントページの限られたスペースの4分の1を削除して、誰も求めてないAIの短いドキュメントを入れて、無効にできない。

最近、いろんなデータをいじってみたんだけど、全部をコンテキストに放り込んで、クロードにデータを分析させることもできるんだ。でも、トークンをたくさん消費しちゃう。データをディスクに保存して、クロードにデータを処理・分析するスクリプトを書かせる方が賢いよ。ずっと速いし、結果も良くなるし、トークンも節約できる。でも、アマゾンは最初のアプローチを好むんだろうね。