0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

推論ベースRAGを業務で試したら、Claude CodeのOpus 4.8バグに悩まされた週の話

0
Last updated at Posted at 2026-06-16

はじめに

今週はAI周りで色々と重なった。Opus 4.8に切り替えてからClaude Codeが謎の挙動を起こし始めたのと、ちょうど推論ベースRAGの記事を読んで試したくなったのが同時期に来て、なかなかカオスな一週間だった。Go 1.26のリリースもあったし、GitHub Copilot CLIの改善も地味に効いている。順番に書いていく。


1. Claude Code + Opus 4.8の「court無限ループ」問題

これを最初に書かないと落ち着かない。Opus 4.8に切り替えてから、Claude Codeが court とか count みたいな謎の単語を吐いてツール呼び出しが止まる現象が何度か起きた。

# こういうログが出てループする
> court
> count
> court
> ...

一番つらいのは、公式の対処が「セッションを変えろ」であること。長い文脈を積み上げた会話の途中でこれが起きると、引き継ぎコマンドを打っても同じところで止まる。

実際に何度か試して効いた回避策はこれ:

  • 問題が起きたら /clear でコンテキストをリセット
  • --continue フラグで直前の会話から再開する
  • ループが起きた操作を細かく分割して再依頼する

完全解決ではないけど、セッションごと捨てるよりはマシだった。同じ問題で悩んでいる人が相当いるらしく、Zennでも対処法の記事が出ていた。根本修正を待ちつつ、とりあえずこれで乗り切っている。


2. PageIndex:ベクトル検索の「距離から構造へ」シフト

今週一番試したくなったのがこれ。従来のベクトル検索(近似最近傍探索)は「意味が近い文書を返す」のは得意だが、複数ドキュメントをまたいだ論理的な推論が必要なクエリには弱い。

PageIndexのアプローチはシンプルで、ドキュメントからツリー構造のインデックスを作り、LLMが生成したサマリを「検索キー」にする。AlphaGoのMCTS(モンテカルロ木探索)に近い探索で、AIエージェントがツリーを段階的に辿って答えへの筋を絞り込む。

社内の技術ドキュメント(Markdownファイル約200ページ)で試してみたところ、こういう差が出た:

# ベクトル検索での質問
query = "認証フローとエラーハンドリングの依存関係を教えて"
# → 認証フローの説明だけ返る(エラーハンドリングが別ドキュメントのため文脈が欠落)

# PageIndex使用
# Step1: 認証ドキュメントのサマリに「エラーハンドリングは別セクション参照」を発見
# Step2: ツリーを辿ってエラーハンドリングノードへ
# Step3: 両者を統合した回答を生成

ハマりポイントとして、インデックス構築コストがそれなりにかかる。200ページで初回構築に約15分かかった。一度作ってしまえばクエリ精度は体感で明らかに上がって、特に「AとBの関係を説明して」系の質問に強い。逐次更新の仕組みをどう設計するかが次の課題。


3. GitHub Copilot CLIの委譲最適化

GitHub Copilot CLIのオーケストレーション改善の話が地味に良かった。「委譲を減らして、直接処理を増やした」という内容で、業務で使っていてちょうど感じていた問題に刺さった。

単純なファイル検索でもサブエージェントへの確認が走るせいで遅かったのが、シンプルなタスクはオーケストレーター直接処理になったらしい。

# 改善前: 単純な検索でもサブエージェントを経由して3ステップかかる
# 改善後: オーケストレーター直接処理で1ステップ

# 試したコマンド
gh copilot suggest "find all TODO comments in src/"
# → 以前より明らかにレスポンスが速くなった

ローカルで確認したところ、確かに単純なコマンドサジェストが速くなっていた。カスタムエージェント機能も追加されていて、チームのワークフローをエージェントとして登録できるらしい。これは週末にもう少し掘ってみる予定。


4. Go 1.26:新GCとスタックアロケーション改善

Go 1.26がリリースされた。個人的に気になっているのが2点。

スタックアロケーションの改善: ヒープではなくスタックへのアロケーションを増やす最適化が入った。

// 小さい構造体がスタックに乗りやすくなった
type Event struct {
    ID   int64
    Type string
}

func handle(e Event) error {
    // Go 1.26ではeがスタックに確保される可能性が高まる
    return nil
}

マイクロサービスの短命なリクエスト処理でGCが詰まるケースがあったので、新しいGCは実際に計測してみたい。cgoのオーバーヘッド削減も入っているので、C/Go相互運用が多いプロジェクトにも恩恵がある。今週末にアップデートしてベンチマークを取ってみる。


まとめ

PageIndexの推論ベースRAGは、複雑なクエリに対する回答の質が体感で違った。ただインデックス更新コストの設計は考える必要がある。Claude CodeのOpus 4.8ループ問題は根本修正待ちだが、回避策はある程度見えてきた。Go 1.26はまだベンチマーク取れていないので、来週の結果も書けたら書く。

こういう「試してみたら想定外のことが起きた」週は、何だかんだで一番勉強になる。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?