会話ログの先へ：コンテキストを設計する

AIエージェントに、作業の続きを頼みます。その単純な依頼の背後には、増え続けるメッセージ、ツール定義、検索結果、ファイル、判断の山があります。次にモデルに見せるべきなのは、そのうちどれでしょうか。NanthAIでは、この問いを軸に何か月も開発を進めてきました。

こちらにも掲載： [9][10].

現在、Piとその親会社Earendilも、MCPの探索とCodemodeを通じて、この問題に新たなエンジニアリングの取り組みを進めています。最近の記事は、私たちがNanthAIに組み込んできた方向への、歓迎すべき貢献です。[1][2]

先の2本は、詳細な技術事例研究でした。この記事ではその中心的な考えを振り返り、Piの最近の取り組みを手がかりに、次の層を考察します。出発点は単純です。エージェントがアクセスできる情報と機能は、毎回のプロンプトに持ち込む必要がある量を大幅に上回っていてよいはずです。

5月の記事で基礎を示しました。今回は、それらと併せてPiのアプローチを検討します。

今回は、ツールの実行前に何を入れるか、実行中に何をモデルへ渡すか、実行後に何を活用できる形で残すか、という考えをつなぎます。

会話が増えると、荷物も増えます。

単純なチャットアプリでは、新しいメッセージのたびに、それまでの会話を送ることがよくあります。ツールを追加すると、結果がその履歴に加わります。連携を追加すると、ツールカタログ全体が毎回のリクエストに付くこともあります。機能も履歴も、プロンプトが膨らむ要因になります。

こちらにも掲載： [10].

比較の基準となる方式は、蓄積した履歴を再送します。NanthAIは、会話、メモリ、再取得できる根拠からコンテキストを準備します。

会話ログには、人が会話を追えるようにするという明確な目的があります。モデルへのリクエストの目的は別で、今行動するために必要な情報をモデルに渡すことです。両者には重なる部分がありますが、同一である必要はありません。ユーザーには読みやすい履歴を残しながら、ランタイムは焦点を絞った作業用コンテキストを準備できます。

NanthAIは、人が読む会話と、その背後にある根拠やランタイムの状態を分離します。生のアーティファクトはツール結果を保持します。コンパクトなメモリは、出典への参照とともに有用な情報を運びます。コンテキストの組み立てでは、次のリクエストに適した材料を選びます。

こちらにも掲載： [10].

より大きなコンテキストウィンドウやプロンプトキャッシュも、このアーキテクチャと併用すると有用です。大きなウィンドウは容量を提供します。キャッシュは繰り返し送られる先頭部分（プレフィックス）のコストを減らせます。コンテキストの組み立ては、そもそも何にその容量を使うべきかを決めます。これは情報設計の選択であり、モデルの能力が高まっても重要です。

エージェントに入口を用意します。

こちらにも掲載： [9].

スキルは、探索できるワークフロー知識のパッケージです。短い説明により、モデルはいつ使うべきかを判断できます。指示全文は、作業の実行方法を説明します。ツールは、検索、読み取り、計算、作成、更新など、実行可能な操作です。1つのスキルが複数のツールを必要とすることも、複数のスキルが同じツールプロファイルを共有することもあります。

NanthAIでは、スキルを読み込むとワークフローの指示が入り、必要なツールプロファイルが有効になります。スキルは、タスクを、その実行に必要なガイダンスと機能の両方につなぎます。

調査レポートの依頼を考えてみてください。カタログは、適切なスキルを見つけるのに十分な情報をエージェントに渡します。そのスキルを読み込むと、調査のワークフローと必要な機能が入ります。後から別の機能が必要になれば、ほかのスキルで有効なツール群を拡張できます。モデルは、必要なものを探す手段を持って作業を始めます。

NanthAIはスキルでガイダンスとツールプロファイルを有効化します。Piはスキルに加え、個々のMCPツールを探索できます。

Piは、コンパクトなサーバーの説明、ツールの検索、詳細の確認を通じてMCPの探索を行います。エージェントは個々の宣言を見つけ、Codemode経由で使うことも、ツールを有効にして直接呼び出すこともできます。Piは、指示を必要に応じて読み込むスキルにも対応しています。[3][5]

そのため、この比較は、単にどちらがツールを遅延読み込みするかという話より興味深いものになります。NanthAIは、ワークフロー知識をツールのグループに明示的に結び付けます。PiのMCP探索は、個々のツールをより細かく選べるようにします。両者とも、機能の存在を知ることと、その詳細を読み込むことを分離しています。

こちらにも掲載： [9].

「ツールメモリ」は、その根拠に戻れるべきです。

こちらにも掲載： [10].

ツールアーティファクトは実行記録です。何を依頼し、何が返ったかを、ファイルやエラーも含めて記録します。ツールメモリは、その記録の有用な根拠を小さく表現したものです。元の記録へのリンクを持ちます。コンテキストの組み立てでは、次の生成にどのメッセージ、メモリ、参照、正確な詳細を入れるかを選びます。

会話ログ、アーティファクト、メモリ、組み立てたコンテキストには、それぞれ異なる役割があります。出典への参照がそれらをつなぎます。

ツールがCSVを生成し、エージェントが結果を説明したとします。次のターンでは、モデルに必要なのは、分かったこととファイルへの参照だけかもしれません。後からユーザーが、ある数値の元になった正確な行を求めます。コンパクトなメモリが、元のアーティファクトに戻る道筋をシステムに示します。根拠を再取得できるからこそ、要約が役に立ちます。

この区別は、時間の扱いにも役立ちます。カレンダーの空き時間はすぐ古くなる一方、生成ファイルを特定する情報は、もっと長く有用かもしれません。そのため、ツールメモリには鮮度と来歴の情報が含まれます。組み立てを担う機構は、チャットにあるという理由だけで両方を同じ権威で扱わず、現在の根拠と古い観測を区別できます。

こちらにも掲載： [10].

根拠を残し、渡すものを選びます。

ツールが動き始めると、コンテキストの問題は形を変えます。回答には数件の事実しか必要ないのに、検索やAPI呼び出しから数百件のレコードが返ることがあります。ここで、PiのCodemodeが特に有用な比較対象になります。

MCPは、ツールをエージェントにつなぐ共通の方法を提供します。エージェントがモデルにどうツールを提示するかは、別の設計上の選択です。EarendilのMCPの記事とThe New Stackの報道は、その区別を具体的に示しています。すべてのスキーマが最初からプロンプトを占めなくても、連携は利用可能にできます。[1][2]

エージェントはJavaScriptを書き、ツールを呼び出し、応答を結合または絞り込み、選んだ出力を返します。中間値はスクリプト内に置けるため、計算を進めるために毎回の応答全文をモデルが受け取る必要はありません。[4]

Piは1つの操作内で中間応答を減らせます。NanthAIはリクエストをまたいで根拠を選び、再利用します。

こちらにも掲載： [10].

違いは、どの時点で介入するかです。Codemodeは、中間データが最初にモデルへ届く前に減らせます。私たちのメモリと組み立ては、後続のリクエストに何を持ち越すかを形作ります。NanthAIの専用ツールはすでに内部でデータを処理しています。汎用のツールループは、各ツールが生成するペイロードを返します。

これらは、同じ情報の流れの異なる段階にある、関連した手法です。Piの貢献は、その流れを検討するもう1つの有用な視点を与えてくれます。

並列呼び出しだけではCodemodeの価値を捉えきれないのも、このためです。並列実行では複数の結果を一度に取得できます。その後、プログラムで結果を組み合わせ、回答に必要な根拠だけを出力できます。呼び出しの構成だけでなく、モデルが受け取る内容も変わります。

1つのレポートに、3つのコンテキストの判断があります。

2つの売上エクスポートを比較し、どの取引先で最も変化があったか説明するよう、エージェントに頼むとします。完成したレポートには、取引先名、意味のある差分、裏付けとなる根拠が必要です。ワークフローでは、レポートに含まれるよりはるかに多くの行を扱うかもしれません。

実行前に、NanthAIは関連する分析スキルを読み込み、ツールを有効化できます。これは最初の記事で扱った機能選択の問題です。無関係なカレンダーやメッセージの指示を、分析に添える必要はありません。

レポートを例にした3つのコンテキストの判断です。各列は、挙げたアプローチごとの仕組みを示しています。

実行中は、Codemodeのスクリプトで、ツールを通じて両データセットを読み、取引先ごとにレコードを結合し、変化を計算して、最大の差分を返せます。これがPiの追加の仕組みを示しています。複数のデータ処理手順をコードで表し、モデルが受け取る出力を選ぶことです。[4]

その後、NanthAIのコンテキストアーキテクチャはアーティファクトを保持し、有用なツールメモリを後のリクエストに引き継げます。ユーザーがレポートの修正を求めると、選んだコンテキストと出典への参照が作業の継続を助けます。タスクに必要なら、正確な根拠を再取得できます。

最近のローカルランタイムの更新により、この役割分担はすでに製品の一部になっています。NanthAIは、Piを含む、Mac上の接続済みランタイムに作業を送れます。NanthAIが関連する会話、ブランチ、メモリ、アーティファクトのコンテキストを組み立てます。Piはその準備済みコンテキストと自身のランタイムの指示やツールを組み合わせ、エージェントループを実行し、設定済みのLLMプロバイダーを呼び出します。

NanthAIがコンテキストを準備し、Piが接続済みMacで実行して、設定済みのLLMプロバイダーを呼び出します。回答は同じ会話に戻ります。

売上レポートの例に戻ると、NanthAIで比較を依頼すれば、接続済みのPiランタイムが、NanthAIの準備したコンテキストを使って分析できます。回答は同じ会話に戻ります。追加の質問では、NanthAIが次のターンに関連するコンテキストを準備し、ランタイムが実行を担当します。コンテキストの組み立てへの私たちの投資と、ローカルランタイムの機能が、1つのワークフローで結び付きます。

作業が続くとき、コンテキストも引き継ぎます。

こちらにも掲載： [10].

モデルを比較したり、タスクを再開したり、実行環境を変えたりするときに、この点が重要になります。NanthAIの共通の準備処理は、関連する会話ブランチ、要約、最近のメッセージ、メモリ、アーティファクトの根拠をまとめます。同じ正規の準備処理が、クラウドとローカルのターンの両方を支えます。

NanthAIは異なる実行経路に共通のコンテキストを準備します。各経路は、それぞれ独自のツール機能を維持します。

計画についての会話に、2つのブランチがあるとします。一方は控えめな予算を検討し、もう一方はより意欲的な提案を作っています。それぞれ異なるスプレッドシートを生成するかもしれません。次のリクエストでは、ユーザーが続けているブランチに関連するファイルと前提を使うべきです。会話全体のどこかにある最新ファイルが、自動的に正しいファイルになるわけではありません。

Piも、セッション、ブランチ、コンパクションを通じて継続性を維持します。EarendilのPi Durableの記事では、その取り組みをチェックポイント付きの実行と復旧へ広げています。[6] Piのコンテキストと実行の設計は、その独自の前提に沿って理解する価値があります。

NanthAIは、Pi自体も含め、クライアント、モデル、実行経路をまたぐ製品に共通のコンテキストを持ち込みます。実行エンジンが作業セッションを管理し、NanthAIが共有記録を維持できます。これが、5月に説明した分離の実用的な価値です。作業は、1つのモデルセッションを超えて続けられます。

こちらにも掲載： [10].

次の有用な一歩に向けて、コンテキストを組み立てます。

5月の記事では、機能を段階的に提示することと、有用な履歴を意図的に組み立てることという、つながった2つの原則を示しました。Piの最近の取り組みは、特にツールの探索とその出力に対する計算について、もう1つの有力な実装上の視点をもたらします。

共通する問題は、有用な作業をするために、エージェントがどれだけの情報を持ち運ばなければならないかです。アプローチごとに、何を選ぶか、いつ選ぶか、システムのどこがその判断を担うかが異なります。

重点の比較：段階的な機能提示、結果の選択、作業を通じた継続性。

CloudflareとAnthropicも、ツールを使うコード実行に関する取り組みを公開しています。[7][8] この問題に注目とエンジニアリングの投資が集まっていることを歓迎します。動作する設計を比較し、各チームの異なる選択から学ぶことには、確かな価値があります。

NanthAIにとって、これはスキル、ツールメモリ、組み立てたコンテキストへの継続的な投資です。私たちが重視するのは、その基礎が可能にする体験です。使いたいモデルを選び、適切な機能を使えるようにし、有用な作業を次の一歩にも活用できる状態に保ちます。

NanthAIで、よりよいコンテキストを作業に生かす

NanthAIは、こうしたアーキテクチャの選択をワークスペースとして形にしています。モデルを選び、スキルでワークフローを整え、ファイルを扱い、有用なコンテキストにアクセスしながら作業を続けられます。

1つのモデルで下書きし、別の視点を得て、会話を次にどこへ進めるか決めます。元の方向性を失わずに、別のブランチを探れます。Mac上の対応するPiやCodexの作業を、スマートフォンやブラウザで使うのと同じ会話に持ち込めます。

私たちは何か月も、この体験の基礎に投資してきました。Pi、Earendil、そのほかのチームが、同じ問題に力とアイデアを注いでいることを心強く感じます。よりよいコンテキストを巡る技術的な議論が豊かになっており、動作する製品とその背後の考えを通じて貢献できることをうれしく思います。

必要なAIを、お好みの価格で

NanthAIを見る

記事と情報源

1. The New Stack: One MCP server used 18,000 tokens before doing anything
2. Earendil: You Said No MCP! (2026年9月29日)
3. Pi documentation: MCP servers and tool exposure
4. Pi documentation: Codemode
5. Pi source: Skills and progressive disclosure
6. Earendil: Pi Durable (2026年10月1日)
7. Cloudflare: Code Mode: the better way to use MCP
8. Anthropic: Code execution with MCP
9. NanthAI: Skills as Tool Gates (2026年5月11日)
10. NanthAI: The Transcript Trap (2026年5月15日)

Piのロゴは公式Piプレスキットより。技術的な比較は、2026年10月に確認したソースとドキュメントに基づきます。

こちらにも掲載： LinkedIn.