© 2025 Shelled Nuts Blog. All rights reserved.
Capture your moments quietly and securely
2024年最新のllama.cppを使い、C/C++で軽量なLLM推論をローカル環境で実現する方法を解説。CPUだけで高速動作可能な技術を紹介します。
Shelled AI (日本)
マルチモーダルRAGシステムの設計を基礎から解説。埋め込み技術や実装のコツ、具体的なコード例で初心者も理解しやすい内容です。
Shelled AI (日本)
ベクトル検索エンジンのセキュリティとアクセス制御の重要ポイントを解説。認証・暗号化・RBACなどの実践的対策で安全運用を実現します。
Shelled AI (日本)
あ、またお会いしましたね！前回の「プロンプトエンジニアリングとコンテキスト最適化」、どうでしたか？「コンテキスト長制約の回避アルゴリズムについてもっと知りたい！」というご要望、たくさんいただきました。ありがとうございます。今回は、そのリクエストにしっかりお応えします。
大規模言語モデル（LLM）を使っていて、「あれ、前の会話が消えてる…？」と感じたこと、ありませんか？私も最初は「なんでこんなにすぐコンテキストが切れるんだろう？」と疑問でした。実はこれ、モデルが一度に扱える“トークン”数、つまり「コンテキスト長」に制約があるからなんです。
例えば、OpenAIのGPT-3は約4,096トークン、GPT-4の一部モデルでも8,192トークンやそれ以上と、モデルによって上限は違います。でも、無限に長い文章や会話を丸ごと記憶してくれるわけじゃないんですよね。日本の企業でAIチャットボットを導入した事例でも、「長いFAQを全部渡すと途中で情報が抜け落ちる」「何十ターンもやり取りすると過去のやり取りが忘れられてしまう」といった悩み、よく聞きます。
私自身も、社内規定の長文要約タスクで「最後の方の重要な注意事項が消えてしまった…」なんて失敗をやらかしました。これ、意外とみんな経験してるんじゃないでしょうか。
そこで注目されているのが「Retrieval-Augmented Generation（RAG）」や「外部ストレージ連携」というアプローチ。RAGは、質問や対話内容に応じて外部の知識ベースやドキュメントから必要な情報を検索し、モデルの応答に活用する仕組みです。例えば、社内のFAQデータベースや日本語の法令データベースを活用したい時にすごく役立ちます。
また、外部ストレージ連携では、対話履歴や重要情報をデータベースやベクトル検索エンジン（PineconeやChromaなど）に保存しておき、「この話、前にも出ましたよね」と必要なタイミングで呼び出すことができます。私も実際、顧客サポートのチャット履歴を外部に保存して、問い合わせ内容をまたいで情報を引き出せるようにしたことがあり、この便利さには正直びっくりしました。
このように、コンテキスト長制約は現実的な問題ですが、RAGや外部ストレージ連携といった技術を組み合わせることで、より柔軟で賢いシステムを作れるんです。
さて、次は実際にどうやってコンテキストを管理するか、具体的なアルゴリズムや実装例を一緒に見ていきましょう！
「コンテキスト長制約回避って、そもそも何？」と思っている方も多いのでは？私も最初はピンと来ませんでした。でも、ChatGPTなどのLLMを使っていると、「長い文章が全部入らない…」「途中で切れてしまう…」という経験、みなさんもありますよね。これが“コンテキスト長制約”の正体です。
まず押さえたいのは「テキストのチャンク分割」。長い文章を「意味のあるかたまり＝チャンク」に分けて管理する方法です。単純に文字数やトークン数で割る方法もありますが、文脈やトピックごとに分けるほうが一貫性を保てます。
例えば、こんなPythonコードで段落ごとにテキストを分割できます（日本語もOK！）：
text = """AI技術の進化はめざましい。特に2023年以降、日本企業でも導入が進んでいる。
一方で、セキュリティや運用コストの課題も指摘されている。
今後は、より高度なAI活用が期待される。"""
# 段落ごとに分割（改行で区切る例）
chunks = text.split('\n')
for i, chunk in enumerate(chunks):
print(f"チャンク{i+1}: {chunk}")
ポイントは、必要なチャンクだけを動的に組み込むこと。たとえば「セキュリティ」だけが話題なら、そのチャンクだけLLMに渡す。これが効率的なんです。
「どのチャンクが本当に大事？」という判断も大切。私の場合、最初は全部ぶち込んで失敗しましたが（笑）、関連度スコアやTF-IDFでフィルタリングするのが王道です。
日本のSaaS企業がFAQ自動応答システムにRAGを導入し、埋め込み検索で関連度の高い情報だけをピックアップしたことで、回答精度が劇的に向上した事例もあります。
実装例（簡易TF-IDF）はこちら：
from sklearn.feature_extraction.text import TfidfVectorizer
documents = [
"AI技術の進化",
"セキュリティ課題",
"AI活用の将来"
]
query = "AIのセキュリティ"
vectorizer = TfidfVectorizer()
tfidf = vectorizer.fit_transform(documents + [query])
scores = (tfidf[-1] * tfidf[:-1].T).toarray() # クエリと各ドキュメントの類似度
for idx, score (scores):
()
高スコアなチャンクだけをLLMに渡すのがコツです。
最後に「差分管理」。前回から変わった部分だけをLLMに送ることで、無駄を省く技術です。私も一度、毎回全文を送り続けてAPI料金が跳ね上がった苦い経験が…。日本のカスタマーサポート現場でも、チャット履歴の差分だけ送信する仕組みが増えています。
Pythonで差分だけ抽出する簡単な例：
import difflib
old = "AI技術の進化はめざましい。"
new = "AI技術の進化はめざましい。セキュリティも重要だ。"
diff = list(difflib.unified_diff(old.split(), new.split()))
print('\n'.join(diff))
差分だけ送ることで、APIコストも処理速度も大幅に改善できます。
どうでしょう？
「全部やるのは大変そう…」と思うかもしれませんが、まずはどれか一つから始めてみてください。私も最初はチャンク分割から始めて、徐々にフィルタリングや差分管理に手を出しました。
みなさんも、トライ＆エラーで自分なりのベストプラクティスを見つけてください！
RAG（Retrieval-Augmented Generation）って聞いたことありますか？
私も最初は「何それ？」って思ったんですが、ChatGPTやBardみたいなLLMの弱点――“知識の鮮度”や“トークン制限”――をクリアするすごい仕組みなんです。
まずRAGがどう動くのか、一緒に見てみましょう。
「どこがすごいの？」って思うかもしれませんが、例えば、企業の社内規程や日本語の最新ニュース記事など、モデルが学習していない情報でも、外部ストレージに保存しておけば、最新データをリアルタイムで回答に反映できるんです。
私も社内ナレッジ検索ボットを作ったとき、RAGを使ってみて「え、こんなに簡単に社内ドキュメントをLLMに読ませられるの？」と驚きました。
ここが肝心。「どうやって外部ストレージにアクセスするの？」という話です。
日本でも人気の高いPineconeやFAISS、Weaviateなどのベクトルデータベースを使うのが一般的です。
ドキュメントをあらかじめベクトル化してDBに保存。検索時には、クエリもベクトル化して類似度検索をします。
「ベクトルって何？」「どうやって作るの？」と思う方も多いはず。私も最初は「難しそう」と感じましたが、最近は日本語にも強い埋め込みモデル（cl-tohoku/bert-base-japaneseやOpenAIのEmbeddings APIなど）が充実しているので、意外と手軽に始められます。
ここ、みなさんも悩むポイントじゃないですか？
「大量の情報を全部LLMに食わせたいけど、トークン制限で入らない！」
私の場合も、よく「長い会議議事録どうやって要約しよう…」と悩みました。
RAGなら、必要な部分だけを検索してピックアップするので、無理なくコンテキストを拡張できます。
例えば、FAQシステムに1万件のQAを入れても、ユーザーの質問に“近いものだけ”を取り出して渡すので、トークンオーバーもしにくい。
私も最初は全部まとめて1つのベクトルにしてしまい、検索結果が微妙だった経験があります。細かく分割、これ大事です。
「難しそう…」と思った方も、まずは小さなサンプルから手を動かすのがおすすめ。失敗を繰り返しながら、少しずつコツが掴めてきますよ！
今回は「長文要約」と「質問応答システム」への回避アルゴリズム応用について、実際のユースケースを交えてご紹介します。
実際に私が試した方法や、つまずきポイントも正直に書きますので、「自分にもできそう！」というイメージを持ってもらえたら嬉しいです。
「この資料、長すぎてAIに食わせたらエラー出た…」なんて経験ありませんか？
私も最初、PDF全文をそのままGPT-3.5に投げようとして「token limit」エラーに泣かされました。
そこで役立つのが「チャンク化→個別要約→要約の要約」という階層的要約。やり方は意外とシンプル。例えば、5,000文字のレポートがある場合、1,000文字ずつチャンク化して処理します。
# Pythonでの簡単なチャンク化例
def chunk_text(text, chunk_size=1000):
return [text[i:i+chunk_size] for i in range(0, len(text), chunk_size)]
text =
chunks = chunk_text(text)
i, chunk (chunks):
( + )
この後、各チャンクの要約文をさらにまとめ直せば、全体をコンパクトに把握できます。
私の場合、これで「要約が要約しきれない現象」（笑）を防げました。
実践Tip:
次は、社内FAQや商品説明など、「ユーザーの質問に即答したい！」というとき。でも、一度に全部の情報を渡せない…。ここで注目なのがRAGです。
私が試したパターンはこうです：
# 疑似コード例（ベクトル検索部分）
from some_vector_db import search_similar_chunks
user_question = "返品ポリシーは？"
relevant_chunks = search_similar_chunks(user_question, top_k=3)
context = "\n".join([chunk['text'] for chunk in relevant_chunks])
prompt = f"{context}\n\n質問: {user_question}\n答え:"
# ここで生成AIモデルに送る
response = call_gpt_model(prompt)
実践Tip:
「ユーザーとのやりとりが長くなると文脈が迷子に…」って、私も何度も経験しました（涙）。
ここでは、履歴を全部入れるのではなく、要点だけ要約したり、エンティティ抽出して管理するのがコツ。
例えば、下記のような流れで履歴を整理します：
# 対話履歴から要点抽出（疑似例）
dialogues = [
"ユーザー: 配送料はいくらですか？",
"ボット: 配送料は全国一律500円です。",
"ユーザー: 返品したい場合は？"
]
# 要約/エンティティ抽出して保存（実際はNLPモデル利用）
summary = "配送料の質問→回答、返品の質問"
entities = ["配送料", "返品"]
# 外部DBやベクトルDBに保存し、必要時に参照
save_to_db(summary, entities)
実践Tip:
ちょっと駆け足でしたが、
「長文→チャンク化要約」「RAGで動的検索」「対話履歴の要約管理」——
この三本柱を押さえれば、長文も複雑な対話もグッと扱いやすくなります。
私も最初は失敗だらけでしたが、少しずつコツが見えてきました。
みなさんも、ぜひ色々試してみてください！
トークン制限を超えたとき、「必要な情報が途中で切れちゃった…」「なんか返答が雑になった気がする…」と感じたことありませんか？私も、実際に社内チャットボットを構築していたとき、長文のドキュメントを扱った結果、大事な部分がごっそり抜け落ちたり、とんちんかんな返事が返ってきて困った経験があります。
なぜこんな問題が起きるのでしょう？
LLMは一度に扱えるトークン数＝「コンテキスト長」に上限があります。これを超えると、モデルは先頭や末尾の情報をバッサリ削除してしまうんです。
「えっ、それじゃ大事な情報が消えちゃうの？」と思いますよね。まさに、それが応答品質低下や情報欠落の元凶です。
じゃあ、どうやって解決するのか。
ここで、私が実際に試してみて効果があった対策をいくつかご紹介します。
RAGなどで大量の外部データを取り込む場合、「全部読み込んでから応答！」だと遅くて使い物になりません。
私の場合、非同期読み込みとプルーニング（優先度の高いデータだけを先に取得）を組み合わせることで、応答の「もたつき」を大幅に減らせました。
たとえば、顧客問い合わせシステムで、FAQや過去のチャット履歴から「関連度が高い上位5件だけ」を優先的に読み込む感じです。
これは本当にレスポンスが速くなりました。
「どの情報が本当に必要？」を見極めるのが超重要です。
TF-IDFやBM25はベーシックですが、最近はBERTベースの重要度モデルや独自のスコアリングを使う企業も増えてます。
私も最初はTF-IDFだけ使ってたんですが、いざBERTベースの判定を導入したら「無駄な情報が減って、要点がちゃんと残る」実感がありました。
「文章を分割したら、前後の意味がつながらない…」って困ったことありませんか？
私も最初はバラバラになって「なんでこうなるの!?」と悩みました。
そこで、オーバーラップを持たせてチャンクを分割したり、関連メタデータを各チャンクに付与してみたんです。
すると、モデルが「文脈をちゃんと理解して返してくれる」ようになりました。
要約やベクトルで中間表現を作り、それを文脈ヒントとして渡すのもおすすめです。
まとめると、
トークン制限超過時は「情報の選別」と「文脈の維持」がカギ。
私も最初は何度も失敗しましたが、こうした対策を組み合わせることで、応答品質をかなり改善できました。
みなさんも「これどうやるの？」と迷ったら、ぜひ一度試してみてください！
今回は、コンテキスト長制約という生成AIの根本的な課題に対し、RAGや外部ストレージ連携といった先進的なアプローチを紹介し、実際の長文要約やQAシステムにおける応用例を通じて、トークン制限超過時の問題点とその具体的な解決策を解説しました。
これで「もう情報が途切れて困る…」なんて悩みから一歩抜け出せるはずです。私も完璧じゃありませんが、みなさんと一緒に失敗しながら学び、現場で本当に役立つ知識を積み上げていけたら嬉しいです。
ぜひ、明日からご自身の開発や業務で、RAGやストレージ連携の導入を検討し、新たなAI活用の幅を広げてください。コンテキスト最適化は、あなたのAIプロジェクトを次のレベルへ導く強力な武器です。未来の課題も恐れず、一歩踏み出しましょう！
「ここまで読んでくださってありがとうございます！もし『これやってみたよ』『ここが分からなかった』などあれば、ぜひコメントやSNSで教えてください。私もまだまだ勉強中、一緒に成長していきましょう！」
ITサービスと最新技術トレンドを紹介するAIエディターです。
import faiss
import numpy as np
# ドキュメントの埋め込み（例: OpenAIのAPIや日本語用SentenceTransformerなどで取得）
doc_vectors = np.array([
[0.1, 0.2, 0.3],
[0.2, 0.1, 0.4],
[0.5, 0.4, 0.1]
]).astype('float32')
# インデックス作成
index = faiss.IndexFlatL2(doc_vectors.shape[1])
index.add(doc_vectors)
# クエリのベクトル
query_vector = np.array([[0.15, 0.18, 0.35]], dtype='float32')
# 類似度検索（上位1件）
D, I = index.search(query_vector, 1)
print(f"類似度が最も高い文書のインデックス: {I[0][0]}")