TECHNOLOGY COLUMN ・ AI AGENT ARCHITECTURE

AIは賢くなったのではない、読み込む量が増えただけだ — Claude Codeが1回の返答までに読んでいるものを図解する

ChatGPTでもClaude Codeでも、何かを尋ねれば数秒で答えが返ってきます。ただしその数秒の裏側では、入力した質問文だけがAIモデルに渡っているわけではありません。役割や話し方を定めた指示、プロジェクトごとの設定、過去のやり取りから蓄積した記憶、そのとき使える機能の一覧——これらを毎回あらためて組み立て直してから、初めてAIモデル本体に渡しています。この組み立てを担っているのはAIモデルそのものではなく、Claude Codeのような「エージェント」と呼ばれる周辺のプログラムです。

本記事では、いまこの文章を実際に生成しているClaude Codeというエージェントを題材に、1回の返答が返るまでに何が読み込まれているかを図解します。伝聞ではなく、当サイト編集部がこのツールを実際に操作しながら直接観測した挙動が元になっています。

8層 質問1つが返答になるまでにClaude Codeが積み上げる情報層の数(①システム指示〜⑧今回の質問)
2層 AIモデルを直接API呼び出しした場合に残る層。システム指示と質問文以外は存在しない
9割前後 直近の自社実測で「文脈を運び直す」処理が占めていた処理量の比率。生成そのものは1割程度
AT A GLANCE

先に判定

01 · THE DIAGRAM

図解 — プロンプト1本が返答になるまで

下の図は、この記事を書いているセッションを例に、質問を1つ受け取ってから答えを組み立てるまでに何が読み込まれるかを順番に並べたものです。右側には対比として、AIモデルのAPIを直接呼び出しただけの場合を並べています。

FIG. 01 — 情報層の比較(エージェント経由 vs 直接API呼び出し) プロンプト1本が返答になるまでに読み込まれる情報層(エージェント経由 vs 直接API呼び出し) Claude Codeのようなエージェント経由 AIモデルを直接(API)呼び出した場合 ① 土台の指示(システムプロンプト) 役割・話し方・安全上のルールなど。ほぼ毎回同じ内容 ② プロジェクトの指示(CLAUDE.md) ワークスペース共通→プロジェクト固有の順で重ねて読む ③ 記憶(メモリ) 索引は常に読み込み、個々のファイルは必要な時だけ ④ 実行時の事実 今日の日付・gitの状態など。保存せず毎回取得し直す ⑤ 使える「技」の一覧(スキル) 名前と一行説明だけ渡し、本体は使うと決めてから取得 ⑥ 使える「道具」の一覧(ツール) 一部は名前だけ渡し、使う直前に仕様を取得 ⑦ それまでの会話 長くなると自動要約。直近のやり取りはそのまま残る ⑧ 今回の質問 ユーザーが実際に入力した文章 LLM推論(ニューラルネットワーク本体) ①〜⑧をまとめて受け取り、ここで初めて応答を生成する 使うと判断したら取得 ① システム指示(最小限) 指示なし(system省略)でも呼び出せる場合が多い ②〜⑦に相当するものは 存在しない 記憶・スキル一覧・ツール一覧・会話履歴は 呼び出す側が別途用意しない限り渡らない ⑧ 今回の質問 同じ文章を送った場合 LLM推論 同じモデル本体。渡された情報ははるかに少ない
図: プロンプトが1つ入力されてからAIモデルが応答を生成するまでに読み込まれる情報の層。左=Claude Codeのようなエージェント経由、右=AIモデルのAPIを直接呼び出した場合の対比。2026年8月時点でのClaude Codeの実際の挙動をもとに当サイト編集部が作成。

色分け:紺=ほぼ固定の土台指示(アクセントカラー)/水色=実行のたびに取得し直す情報/橙=索引だけ常時渡し詳細は必要時に取得/グレー=その回のやり取り。

図の左下、LLM推論の箱から左側に伸びる点線は、返答を生成している途中でモデル自身が「この技(スキル)や道具(ツール)が必要だ」と判断した場合に起きる追加の取得を表しています。一直線の流れではなく、往復が起きる場面がある点は後述します。

02 · MODEL VS. AGENT

「AIモデル」と「AIエージェント」の境界線

図の右側に置いた「AIモデルを直接呼び出した場合」は誇張ではありません。AnthropicのAPI(Claude API)を直接呼び出す最小限の使い方では、渡すものは基本的に会話のやり取り(メッセージの配列)と、必要であれば短いシステム指示だけです。記憶も、使えるスキルの一覧も、プロジェクトの指示も、呼び出す側のプログラムが自分で用意して渡さない限り存在しません。

AIモデル本体——Transformer型のニューラルネットワーク——がしていることは、渡された文章の続きとして最も確からしい文章を、学習済みのパラメータをもとに1トークンずつ予測することです(Vaswani et al., 2017)。このパラメータは、会話の最中はもちろん、通常は次のモデル更新まで変化しません。つまり「AIが賢くなった」と感じる体験の多くは、モデルそのものの進化ではなく、モデルの手前でどれだけの関連情報を集めて渡せるようになったか、という周辺システムの進化です。

「AIが賢くなった」と感じる体験の多くは、モデルそのものの進化ではなく、モデルの手前でどれだけの関連情報を集めて渡せるようになったか、という周辺システムの進化だ。

本記事の結論

Claude Codeは、この周辺システム(エージェント、あるいはハーネスと呼ばれます)を厚く持っている製品の一例です。プロジェクトの指示ファイルを自動で探して読み込み、過去のやり取りから学んだ内容をファイルとして記憶し、状況に応じて専用の手順(スキル)や外部機能(ツール)を呼び出します。同じAIモデルでも、素のAPI・シンプルなチャット画面・Claude Codeのようなエージェントでは、モデルに渡る前段の情報量がまったく異なります。

03 · THE SHARED DESIGN

記憶・スキル・道具に共通する設計

図の③⑤⑥——記憶・スキル・道具——には共通の設計思想があります。索引(名前と一行説明)は常に渡すが、詳細な中身は必要になるまで取得しない、という遅延読み込みです。

索引(名前と一行説明)は常に渡すが、詳細な中身は必要になるまで取得しない。

記憶・スキル・道具に共通する設計原則

たとえば「スキル」は、会話の冒頭でタイトルと1行説明だけがモデルに渡されています。実際にあるスキルを使うと判断した時点で初めて、そのスキルの完全な手順書を読み込みます。「ツール」の一部も同様に、名前だけを先に見せておき、実際に使う直前になって詳しい仕様を取得します。「記憶」も、全項目の一行要約をまとめた索引は常に渡っていますが、個々の記憶ファイルの中身は、話題に関連すると判断された時だけ読みに行きます。

この設計には理由があります。仮に記憶ファイルのすべて、スキルの完全な手順書すべて、ツールの詳しい仕様すべてを毎回渡すと、モデルに送る文章の量が膨れ上がります。文章の量が増えれば、関係のない情報が肝心な指示を埋もれさせるリスクが上がるだけでなく、処理コストと応答までの時間も増えます。索引だけを常駐させ、詳細をモデル自身の判断に任せて遅延取得する設計は、この二つのコストを避けるための工夫です。

04 · MID-RESPONSE LOOP

返答の途中でも起きる、追加の読み込み

ここまでの説明は「質問を受け取る→必要なものを一括で読み込む→答えを書く」という一直線の流れに見えるかもしれません。しかし実際にはもう一段階、動きがあります。モデルは文章を生成している途中でも、いったん止まって「この道具(ツール)を使いたい」と要求できます。この要求を受け取った周辺システムが実際にその道具を実行し、結果を新しい情報としてモデルに返し、モデルはその結果を踏まえて続きを生成します。この往復は1回の返答の中で複数回起きることも珍しくありません。

この往復は1回の返答の中で複数回起きることも珍しくない。

返答生成の途中で起きる追加の読み込み

本記事の執筆自体もこの往復の実例です。テーマの相談を受けた後、既存記事のHTML構造を確認し、サイトのカテゴリ一覧を調べ、コスト実測のデータファイルを読みに行く——これらはすべて、この記事を書いている途中でモデルが「必要だ」と判断して発生した追加の読み込みでした。

また、やり取りが長くなり会話の記録が一定の量を超えると、古い部分は自動的に要約され、直近のやり取りだけが元の形のまま残ります。これも会話の裏側で自動的に起きる、ユーザーからは見えにくい処理の一つです。

05 · WHY IT MATTERS

投資家にとって何が意味を持つか

この仕組みを知ることは、直接の売買助言にはなりません。ただし、AIサービスや関連企業を理解するうえでの前提として、押さえておく価値があります。

① 「賢さ」の差は、モデルだけで決まらない

AI関連企業を比較するとき、「どの基盤モデルを使っているか」だけに注目しがちですが、本記事で見た通り、同じモデルでも周辺の記憶・検索・道具連携をどれだけ厚く作り込めるかで、実際の使い勝手は大きく変わります。AIスタックのどの層(基盤モデルの開発・周辺エージェントの構築・業務への組み込み)で企業が競っているのかを見分ける視点は、この仕組みを知っているかどうかで変わってきます。

② 「文脈を運ぶこと」自体に、実際のコストがかかる

当サイトはClaude Codeを使って記事を制作しており、その利用実績を自前で継続的に計測しています。直近の実測では、1回のやり取りにかかる処理量のうち、実際に文章を新しく生成している部分は1割程度にとどまり、残りの9割前後は、既に渡した文脈(システム指示・記憶・会話の続きなど)を毎回のやり取りで運び直す処理が占めていました。これは複数回の計測で一貫して見られた傾向です。「回答の生成」自体よりも「その回答にたどり着くための文脈をどれだけ効率よく運べるか」の方が、実際のコスト構造では大きな比重を占めているということです。

「回答の生成」自体よりも「その回答にたどり着くための文脈をどれだけ効率よく運べるか」の方が、実際のコスト構造では大きな比重を占めている。

当サイトの運用コスト実測より

③ だから「文脈を安く運ぶ」技術に投資が向かう

モデルに渡す文脈のうち、システムの指示や記憶の索引のように毎回ほぼ同じ内容になる部分は、まとめて使い回す(キャッシュする)ことでコストを下げられます。AI関連のサービスやインフラで「プロンプトキャッシュ」「長期記憶」「検索連携(RAG)」といった機能が相次いで整備されてきた背景には、こうした文脈を運ぶコストを下げる必要があるという、地味だが実務的な理由があります。

本記事で紹介した比率は、あくまで当サイトがClaude Codeを使って記事を制作する中で得た実測値(比率のみ)であり、他のAIサービス・利用形態すべてに当てはまる数値ではありません。特定の銘柄やサービスの購入・利用を推奨するものではなく、一般的な情報提供を目的としています。

SOURCES

一次情報・参考文献

⚠ 留意点

FAQ

Q. memoryやCLAUDE.mdの内容は、AIの「学習」に使われるのですか?
いいえ。本記事で説明した各層は、いずれもそのセッションの入力として毎回渡される文章であり、AIモデル自体のパラメータ(学習によって決まる重み)は一切変化しません。次の会話ではまた同じ手順で一から組み立て直されます。事前学習・追加学習とプロンプトの組み立ては別の工程です。

Q. ChatGPTなど他のAIサービスでも、同じ仕組みが動いているのですか?
「静的な指示に加えて、取得した文脈・使える道具・会話履歴を積み重ねてからモデルに渡す」という設計思想自体は、エージェント型のAI製品に広く共通しています。ただし何を記憶と呼ぶか、何を自動で読み込むかという具体的な実装は製品ごとに異なります。本記事で図解したのはClaude Codeという1つの製品の実例であり、細部をすべてのAIサービスに一般化できるわけではありません。

Q. 読み込む情報は多ければ多いほど、回答の質は上がるのですか?
一概には言えません。関係のない情報まで大量に読み込ませると、肝心な指示がノイズに埋もれたり、処理コストや応答時間が増えたりします。本記事で図解した「一覧は常に渡すが、詳細は必要になった時だけ取得する」という設計は、関連性の低い情報を最初から全部持たせないための工夫です。

Q. この仕組みを知ることは、投資判断にどう関係するのですか?
直接の売買助言にはなりません。ただし、AIサービスの実用性がモデル単体の性能だけでなく、周辺の文脈収集・記憶・道具連携という「エージェント側の設計」にも左右されるという理解は、AI関連企業の事業内容を読み解く土台になります。またこの文脈の組み立てには実際の処理コストがかかっており、それがサービスの料金設計にも反映されます。

KEEP READING

あわせて読みたい

本記事は、当サイト編集部がClaude Codeというエージェントを実際に操作して観測した挙動、および公開されている技術文献を基に整理した一般的な情報提供を目的としており、特定の金融商品やAIサービスの購入・利用を推奨・勧誘するものではありません。AI製品の具体的な挙動は更新により変化する可能性があります。最終的な判断はご自身の責任で行ってください。

出典:Vaswani et al. "Attention Is All You Need"(2017)、Claude Code公式リポジトリ、Claude/Claude Code公式ドキュメント、当サイト編集部による直接観測・実測(2026年8月6日時点)。