00:00
えっと、あなたがAIに、例えば4万行もあるエラーログを丸ごと投げ込んだとしますよね。
はいはい、よくやりますね。
で、本当のクラッシュの原因は、真ん中あたりのたった1行のエラーコードなのに、
AIが全く検討違いなファイルの修正案を、自信満々に出してくることってありませんか?
あー、ありますね。日常茶飯事というか。
そういう時って、なんか今日のAIは機嫌が悪いなーとか、性能の限界かなーって諦めがちじゃないですか。
そうなんですよ。でも実はこれ、AIの頭の良さの問題じゃないんですよね。
えー、全然違うんです。
今回の深堀り分析では、7つの最先端AIツールの公式資料から、巨大なデータとAIの付き合い方について徹底的に読み解いていきます。
よし、早速紐解いていきましょうか。
はい、よろしくお願いします。
結論から言うと、これってAIの性能ではなくて、長い出力がどこで切断されるかっていう物理的な問題なんですよね。
例えるなら、分厚い長編ミステリーの最初の数ページと最後の数ページだけを読まされて、
真ん中の一番重要な伏線を見落としたまま感想文を書かされるようなものでして。
まさにその通りです。
与えられた範囲のデータだけで何とか辻褄を合わせようとするから、AIは堂々とハルシネーションを起こすわけです。
なるほど。
システムの設計上、長すぎる出力は必ずどこかで切断されるんですが、
ここで非常に興味深いのは、その切断の単位がツールによって全く異なるという点なんですよ。
いやー、そこなんですよね。
例えばコーデックスだと、ツールごとに処理できる上限を1万2千トークンみたいな形で管理していますよね。
はい、トークン単位ですね。
でもハーミスエージェントになると全然違って、ターミナルへの出力は5万バイトまで、ファイルを読み込むときは2千行まで、さらに1行の長さは2千文字までってかなりバラバラに切っています。
そうなんです。これ、なんでそんな複雑なことをしているのかっていうエンジニアリングの視点が重要でして、
コードの生成と単なるエラーログの羅列ってシステムにかかる計算コストとかコンテキストの質が全く違うんですよ。
だから、一律の予算を持たせるんじゃなくて、情報の性質に合わせて制限を分けているんです。
なるほどな。でも単位が違うって、なんだか海外旅行で通貨を間違えるみたいですよね。
ああ、すごくいい例えですね。
上限を上げたつもりでも、単位が違ったら全く効いていないっていうのが一番怖いです。
例えば、私がヘルメスに圧縮されて1行にまとまったミニファイドのJavaScriptを読ませたとしたら、
ファイル全体で1行しかないのに、2000文字で切断されるルールがあるから、
残りの膨大なコードは読み込まれる前に一瞬で消えちゃうってことですよね。
その通りです。自分の使っているツールの単位を把握していないと、そういう恐ろしい事態に陥ります。
わあ、だとすると、その切り捨てられた残りのデータってどこに行くんですか?
AIはここから先は読めませんでしたって教えてくれるわけですよね。
03:02
それがですね、ツールの設計思想によって大きく二極化するんです。
例えば、クロードコードの場合、処理が失敗してエラーになったとき、
なんと約1万文字の制限内で先頭と末尾だけを残して真ん中を完全に消去するんですよ。
えっ、真ん中が消える?
はい。しかも元データのファイルパスすら残さないんです。
ちょっと待ってください。それっていくらなんでもUXとして最悪じゃないですか。
エラーの原因が真ん中にあったら、永遠に手がかりを失うってことですよね。
かなり厳しい設計ですよね。
でもこれは限られたAIの短期記憶をパンクさせないための極端な最適化なんです。
これをより広い視点で捉えると、他のツールとの違いがはっきりしてきます。
と言いますと?
例えば、マヌスやジェンスパークは真逆のアプローチで、長すぎる出力を会話の履歴に直接入れずに、
ファイルシステムや専用のAIドライブに保存するんです。
ああ、なるほど。中身は会話から落としても、復元可能なURLとかパスっていう手がかりは必ず残すんですね。
不可逆な圧縮を防ぐってことか。
ええ、そういう設計思想が見えます。
他にも、アントレクティは会話外のタスクログに置いたり、
オープンクローは古い履歴をプレイスホルダーに置き換えたりしますね。
ここからが本当に面白いところなんだけど、保存されたデータにも寿命があるじゃないですか。
はい、そこ重要です。
ヘルメスの一時ファイルが24時間で消えるのって、
まるで魔法が解けるシンデレラみたいですよね。
翌日には読めなくなっているなんて。
へえ、ジェンスパークの保存データも30日で自動削除されます。
ログが勝手に消える。つまり、ハードデスクじゃなくて、ラムみたいな感覚ですね。
うーん、高速な処理にはいいけど、ラップトップを閉じて翌日仕事に戻ったら、
昨日までの文脈がきれいさっぱり揮発しているのは怖いですね。
つまり、これってどういうことなんでしょうか。
聞いてくださっている皆さんが、明日からどうすればいいのか。
そうですね。皆さんにぜひ意識していただきたい教訓としては、
長い実行ログは絶対にそのままAIに丸投げしないことです。
一度リダイレクトでファイルに書き出して、
グレップコマンドなんかで絞ってから渡すと。
その通りです。
事前に切られる位置、置き場所、寿命を確認カードとして把握しておくことが不可欠ですね。
これが賢く使う第一歩です。
しかし、AIの記憶の寿命とか切り出しルールがツールごとにこれほど複雑化していくなら、
将来的にはどうなるんでしょうね。
と言いますと?
私たち人間がAIに直接指示を出すんじゃなくて、
AIの限られた記憶領域に何を、いつ、どの単位で食べさせるかっていう文脈管理だけを専門に行う、
全く新しい仕事を必要とするようになるんじゃないでしょうか。
プロンプトを書くスキルの次の形ですね。
十分にあり得る未来だと思います。
そんな気がしてなりません。
皆さんはどう思いますか。
ご自身の文脈管理、ぜひ見直してみてくださいね。
