AWS アカウントに一晩で 200 ドルの請求が発生しました。
システムがクラッシュしたからではありません。
エージェントが停止条件なしで 6 時間ループし、反復ごとに OpenAI API を呼び出していたのです。
すべての監視ダッシュボードは「正常」と表示していました。
朝、請求書が届くまで誰も気づきませんでした。
これが、AI システムが実際にどのように動作するかを理解せずに構築した場合に起こることです。
ほとんどの人は、間違った順序で AI エンジニアリングを学びます。
ライブラリをインストールする。チュートリアルに従う。API を呼び出す。何かを動かす。進歩した気分になる。
そして、意味がわからない形で何かが壊れます。
意味もなく数字を変えて、動くまで繰り返します。
それはエンジニアリングではありません。それはキーボードを持った願掛けです。
これを解決する 6 つのコンセプトをご紹介します。
すべてを説明するひとつの文章
どんなに複雑な AI システムも、結局はこれだけです：
メモリ (RAG) + 思考 (LLM + トークン) + アクション (エージェント) + 測定 (評価)
…これらを コンテキストエンジニアリング で組み立てたもの。
それがこの分野のすべてです。
以下の内容は、それぞれの部分が実際に何を意味するのかを具体的に説明したものです。
1. トークンとコンテキストウィンドウ
LLM は単語を読むのではありません。トークンと呼ばれるチャンクを読み取ります。
"engineering" → 1 トークン
"unbelievable" → 2 トークン スペースや句読点もカウントされます。
すべてのモデルにはコンテキストウィンドウがあります。これは、一度に保持できるトークンのハードリミットです。
→ Claude: 200,000 トークン
→ GPT-5: 400,000 トークン
会議室のホワイトボードのようなものだと考えてください。
モデルは、現在ボードに書かれている情報のみを使って作業します。
ボードがいっぱいになると、古いメモは消去されて新しい情報のためのスペースが作られます。
モデルが考える能力を失うわけではありません。
以前の情報へのアクセスを失うのです。
これが本番システムを壊す理由：
→ トークンにはコストがかかる — API 呼び出し毎に、入出力トークンに対して課金されます
→ 長い会話履歴はすぐにウィンドウを埋め尽くします
→ コンテキストがいっぱいになると、初期の指示が静かにドロップされます
→ 何をコンテキストに入れるかはエンジニアリング上の判断であり、デフォルトに任せるべきではありません
これを証明する障害例：
あるチームが、リクエスト毎に 12 ヶ月分の全チャット履歴をコンテキストとして提供するカスタマーサポートエージェントを構築しました。
5 件のインタラクションでのテストは完璧でした。
本番環境で、50 件のインタラクションを超えた後、エージェントは自身のシステムプロンプトを無視し始めました。
指示自体はまだ存在していました。
しかし、80,000 トークンの会話履歴の下に埋もれていたのです。
モデルは事実上、それらに注意を払わなくなっていました。
修正方法は、より良いモデルを使うことではありませんでした。
古い履歴を要約して、ウィンドウを焦点の絞れた状態に保つことでした。
気づきにくい真実：
ほとんどの「プロンプトエンジニアリングの失敗」は、実際にはトークンとコンテキストウィンドウの失敗が偽装されたものです。
エンジニアはプロンプトを責めますが、本当の問題は、重要な指示が 500 行のコンテキストの 3 行目にあり、モデルがそれを重み付けしなくなったことです。
2. 埋め込みとベクトル検索
埋め込みは、意味を数値に変換することで、「類似性」を数学的に計算できるようにします。
これが解決する問題：
あなたは 50,000 のドキュメントを持っています。ユーザーが質問をします。毎回 50,000 すべてを読むことなく、最も関連性の高い 3 つを見つける必要があります。
キーワード検索はここで失敗します。
ドキュメントに「自動車」と書かれていて、ユーザーが「車」について尋ねた場合、キーワード検索は見逃します。
答えがないからではありません。単語が一致しなかったからです。
埋め込みはこれを別の方法で解決します。
埋め込みモデルはテキストをベクトルに変換します。これは、数学的な空間における意味を表す数値のリストです。
意味的に類似したテキスト → 数値的に類似したベクトル。
「車」と「自動車」 → 近い位置
「車」と「光合成」 → 遠い位置
ベクトル検索の実際の仕組み：
- 各ドキュメントはベクトルに変換され、保存されます
- ユーザーの質問もベクトルに変換されます
- システムは、質問ベクトルに最も近い保存済みベクトルを見つけます
- それらが最も関連性の高いドキュメントです
これは近似的な魔法ではありません。幾何学です。
類似性は、計算可能な実際の数学的特性です。
これが本番環境で現れる場所：
→ あらゆるドキュメントシステムでの意味検索
→ 類似商品、記事、ユーザープロフィールの検索
→ RAG（次のコンセプト）における検索ステップ
→ AI エージェントにおけるメモリ
3. RAG（検索拡張生成）
モデルをあなたのデータでトレーニングする代わりに、クエリ時にその関連データを検索し、コンテキストとしてモデルに与えます。
RAG が解決する問題：
LLM は多くのことを知っています。しかし、あなたのデータは知りません。
会社の内部文書。製品データベース。カスタマーサポートの履歴。
それらのどれもトレーニングセットには含まれていません。
2 つの選択肢があります。あなたのデータでモデルをトレーニングするか（高価で、時間がかかり、すぐに古くなる）、またはモデルが必要とする正確なタイミングでデータを与えるかです。
RAG は、2 つ目の選択肢を体系的に行うものです。
3 ステップのパイプライン：
→ 検索：
質問がベクトルになる → ベクトルデータベースが最も類似した保存済みドキュメントを見つける → 上位 3～5 のチャンクが検索される
→ 拡張：
検索されたドキュメントがモデルのコンテキストに追加される → プロンプトは「このコンテキストを使って、この質問に答えてください」となる
→ 生成：
モデルは、幻覚ではなく、実際のデータに基づいた答えを生成する
RAG が機能しなくなるケース：
→ 検索が悪ければ、答えも悪い。モデルは受け取った情報でしか作業できない
→ チャンク分割が適切でないと、答えがそのコンテキストから切り離される
→ 検索で有用なものが見つからなければ、モデルは依然として幻覚を起こす可能性がある
実際の RAG 障害例：
あるチームが、500 ページの技術マニュアル用の社内ナレッジアシスタントを構築しました。
デモでは完璧に機能しました。本番環境では、回答は曖昧で、時には間違っていました。
問題はチャンクサイズでした。
彼らはマニュアルを、単純な文字数で 1,000 トークンのチャンクに分割していました。
表は途中で分割され、ステップバイステップの説明も途中で分割されていました。
検索はおおよその領域を見つけていましたが、実際の答えを見つけられていませんでした。
チャンクサイズを半分にし、オーバーラップを追加することで、問題の 80% が一晩で修正されました。
確固たる意見：
検索が悪ければ、RAG は過大評価されています。
LLM は悪い検索を修正できません。ただ、その周辺で幻覚を起こすだけです。
間違った回答が表示されているなら、プロンプトを微調整するのをやめましょう。
検索の精度を測定し始めてください。
そこに答えがあります。
4. エージェントループ
エージェントは、アクションを選択し、それを実行し、結果を観察し、次に何をするかを決定することを、タスクが完了するまで繰り返すことで動作します。
通常の LLM 呼び出しはステートレスです。質問し、答えが返ってきて、終わりです。
エージェントはステートフルです。行動し、観察し、決定し、繰り返します。
ループを平易な言葉で説明すると：
- 目標を受け取る
- 次のアクションを決定する
- それを実行する — 検索、コード実行、ファイル読み取り
- 結果を観察する
- 学習した内容に基づいて次のアクションを決定する
- 目標が完了するまで繰り返す
- 最終的な答えを返す
ツールこそがエージェントに力を与えるものです。
ツールがなければ、LLM はテキストで応答するだけです。
ツールがあれば、ウェブ検索、ファイルの読み取り、コードの作成、API の呼び出し、あなたが定義するあらゆるアクションをトリガーできます。
初心者が必ず間違える 3 つのこと：
→ 停止条件のないエージェントは永久に実行され続けます。いつ停止するかを定義する必要があります。ステップ数制限、時間制限、または目標条件です
→ ツールが多いほどパフォーマンスが良くなるわけではありません。ツールが多すぎると、モデルがどれを使うべきか混乱します
→ ツールエラーは明示的に処理する必要があります。サイレント障害により、エージェントは自信満々にゴミを出力します
一晩で 200 ドルかかった障害の詳細：
エージェントには最大ステップ数が設定されていませんでした。その目標は、あるトピックを調査し、要約を作成することでした。
ウェブ検索ツールの 1 つが空の結果を返しました。
エージェントは停止方法を知りませんでした。
検索、再試行、中間要約の生成を繰り返し、それぞれが次の検索を引き起こしました。
6 時間後：847 回の LLM 呼び出し。210 万トークン消費。一貫性があるように見えるが、完全に循環している要約。200 ドルの請求書。
修正は 3 行でした。最大ステップカウンター、空の結果に対する明示的なハンドラー、そして信頼度が低い場合のエスカレーションパスです。
同じエージェントは、現在平均 12 回未満の呼び出しで完了します。
あなたが聞くべき意見：
ほとんどのエージェントが失敗するのは、モデルが悪いからではなく、エンジニアがループを自己管理型であるかのように扱うからです。
そうではありません。
ガードレール、停止条件、エラーハンドラー — これらは最初から組み込むべきものであり、最初のインシデントの後に追加するものではありません。
5. 評価 (Eval)
評価とは、AI システムが実際に機能しているかどうか、そして変更によって良くなったか悪くなったかを知るための方法です。
これは、地味だからという理由でほとんどのチュートリアルが省略するコンセプトです。
そして、デモを作るエンジニアと本番システムを構築するエンジニアを分けるものでもあります。
評価なしでの問題点：
プロンプトを変更する。検索ロジックを更新する。新しいモデルに切り替える。
良くなりましたか？
わかりません。いくつか手動で確認することはできますが、それは感触であって証拠ではありません。
評価が実際にどのようなものか：
→ ゴールデンデータセット：既知の正しい出力を持つ 25～50 の実際の入力。主要なユースケースと、既知の難しいエッジケース 5 つをカバーします
→ 可能な場合のバイナリメトリクス：
— RAG システムは正しいドキュメントを取得しましたか？はい/いいえ
— エージェントはエラーなく完了しましたか？はい/いいえ
— 応答に必要な情報が含まれていましたか？はい/いいえ
→ 時間の経過とともに追跡される集計スコア：
— 検索精度：89% → 変更後 → 84%。回帰を発見。
— タスク完了率：76% → 新しいエージェントバージョン → 81%。改善を確認。
評価のサイクル：
デプロイ → 評価で測定 → 失敗を発見 → 失敗をゴールデンデータセットに追加 → 修正 → 再度評価を実行 → スコアを比較 → 数値が改善された場合のみリリース
正直な真実：
「有用性：3.7/5」では、何も具体的なことはわかりません。
「正しいドキュメントを取得した確率：84%」は、問題がどこにあるのか、修正によってどれだけ改善されたかを正確に示します。
評価のない AI システムは製品ではありません。
それは、自信を持って変更できないデモです。
6. コンテキストエンジニアリング
モデルのコンテキストウィンドウにどの情報を入れ、それをどのように構造化し、何を省略するかを正確に決定する学問です。
ここで、人々を不快にさせる意見を述べます。
コンテキストエンジニアリングは、プロンプトエンジニアリングよりも重要です。
適切にキュレーションされたコンテキスト内の平凡なプロンプトは、ノイズに埋もれた素晴らしいプロンプトよりも、毎回優れたパフォーマンスを発揮します。
ほとんどのチームは、最適化努力の 80% をプロンプトに費やし、コンテキストにはほとんど費やしません。
その結果はそれを反映しています。
単純なアプローチは失敗します：
すべてを含める。すべての履歴。すべての取得ドキュメント。すべてのツール説明。システムプロンプト。ユーザーメッセージ。そのすべて。
これは一貫した理由で失敗します。モデルは何が最も重要かについて混乱するのです。
「途中ロスト」と呼ばれる文書化された効果があります — 長いコンテキストの深くに埋もれた情報は、使用される可能性が低くなります。
コンテキストエンジニアリングが実際に含むもの：
→ 選択：この特定の決定には、どのドキュメント、事実、履歴が必要か？
→ 圧縮：会話の古い部分を要約してトークンを節約できるか？
→ 順序付け：重要な指示は最初と最後に配置すべきであり、途中ではない
→ 刈り込み：出力品質に影響を与えずに削除できるものは何か？
→ 構造：ヘッダー、区切り文字、ラベル付きセクションは、モデルが情報をどの程度確実に使用するかに影響を与える
実践的な例：
エージェントが 45 分間実行されています。80,000 トークンの会話履歴が蓄積されています。ウィンドウは 128,000 です。
履歴がウィンドウを埋めていっても、最初の目標と制約を失いたくありません。
コンテキストエンジニアリング：古いツール出力を圧縮し、以前の推論を要約し、セッション全体を通じてタスク定義を目立つように保ちます。
プロンプトエンジニアリングは、良い指示を書くことです。
コンテキストエンジニアリングは、それらの指示が実際に守られる環境を構築することです。
これら 6 つのコンセプトが 1 つのシステムを形成する方法
メモリ → RAG + 埋め込み (システムが知っていること)
思考 → LLM + トークン + コンテキストウィンドウ (知っていることを使って推論する方法)
アクション → エージェントループ + ツール (現実世界でできること)
測定 → 評価 (それが機能していることを確認する方法)
接着剤 → コンテキストエンジニアリング (上記すべての間で何を流すかを決定するもの)
単純なチャットボットは「思考」だけです。
カスタマーサポートエージェントは「メモリ + 思考 + アクション」です。
信頼性の高い本番システムは「測定」を追加します。
洗練さは、各部分がどれだけうまく接続されているかにあります。
単一のリクエストに対するフロー：
ユーザーの質問
→ コンテキストエンジニアリングが何を含めるかを決定
→ 埋め込みが関連するメモリ (RAG) を取得
→ トークンがウィンドウにどれだけ収まるかを決定
→ LLM が組み立てられたコンテキストに基づいて推論
→ エージェントループがさらに情報が必要かどうかを決定
→ 評価が出力が実際に正しかったかどうかを測定
どこから始めるか
6 つすべてを一度にマスターする必要はありません。
→ トークンとコンテキストウィンドウから始めましょう — これらはあなたが構築するすべてに影響します → 意味検索やメモリが必要になったら、埋め込みを追加します
→ モデルを自分自身のデータに基づかせる必要がある場合は、RAG を学びます
→ 自動化が必要な場合は、エージェントループを学びます
→ 何かを本番環境に出荷する前に、評価を追加します
→ 他のすべてが直感的になってきたら、コンテキストエンジニアリングを適用します
この順序は恣意的ではありません。
各コンセプトが次のコンセプトを学びやすくします。
正直な最終見解
本番環境で AI に苦労しているほとんどのチームは、間違ったモデルや間違ったライブラリに苦労しているわけではありません。
彼らは、これら 6 つのコンセプトのうちの 1 つをスキップしたために苦労しているのです。
誰も停止条件について考えなかったため、エージェントは永遠にループします。
誰も検索を測定しなかったため、RAG の回答は間違っています。
誰もコンテキストウィンドウがどのように埋まるかを理解していなかったため、プロンプトは長いセッションで機能しなくなります。
これらは洗練された問題ではありません。
技術的な語彙で飾られた、基本的な問題です。
ツールは 6 ヶ月ごとに変わります。
これらの 6 つのコンセプトは、ツールがどのように機能するかという本質です。
コンセプトを学べば、新しいツールに混乱することは決してありません。
さらに重要なことは、エージェントが一晩中ループするのを見ながら、何が間違っていたのかと疑問に思い、200 ドルを費やすことがなくなるということです。
もしこれが役に立ったなら：
→ これをリポストして、あなたの知っているすべての AI エンジニアと共有してください
→ @sairahul1 をフォローして、このようなシステムや解説をさらにご覧ください
→ これをブックマークしてください — 次に本番環境で何かが壊れたときに参照することになるでしょう
私は、あなたが寝ている間に機能する AI、製品、システムについて書いています。
