LLM（大規模言語モデル）にエージェント的な作業を長時間任せる場面が増えてきています。今回扱うのは、ChatGPTのエージェント実行環境「ChatGPT Work」がGPT-6 Astraというモデルを使い、自宅からのランニングルートを27分かけて自動生成した事例です。RAG（検索拡張生成、外部データを参照しながら回答を作る仕組み）やツール呼び出しを組み合わせたエージェント実行の設計を検討している開発者に向けて、何が起きたのか技術的に整理します。
注目すべきなのは結果の精度ではなく、実行プロセスの不透明さです。ユーザーは「自宅から5kmと10kmのループコースをOSMデータで作って」と依頼しただけですが、モデルは複数の外部サービスを自律的に組み合わせて成果物を作りました。この裏側を分解すると、エージェント型LLM運用で押さえるべき論点が見えてきます。
何が起きたか：ツール連携の全体像
GPT-6 Astraは依頼を受けて、まずNominatim（OpenStreetMapプロジェクトが提供する住所とジオコーディング座標の相互変換API）で住所を座標に変換しました。
次にOverpass（OpenStreetMapの地図データを条件指定でクエリできるAPI）を使い、周辺の道路・小道データをダウンロードしています。
そのうえでループルートの計算はローカル環境（モデルが確保した実行サンドボックス内）で行われ、GPXファイル（GPS機器で読み込める経路データ形式）とGeoJSON（地理情報をJSON形式で表現する標準フォーマット）の両方を出力しました。
可視化にはvisualizeスキルという機能が使われ、D3.js（データ可視化のためのJavaScriptライブラリ、バージョン7.9.0がCDN経由で読み込まれています）でルート図をHTMLとして描画し、ChatGPTの画面内に直接埋め込んでいます。
段階的に見る技術的なポイント
この一連の流れは、単発のプロンプト応答とは性質が異なります。1回の指示に対してモデルが「ジオコーディング→データ取得→計算→可視化→ファイル出力」という多段階のタスク分解を自分で行い、外部APIとサンドボックス内コードの両方を組み合わせて完遂しています。
これはRAGの発展形と捉えると理解しやすくなります。RAGは通常「検索して埋め込む」までですが、ここでは検索結果（OSMの道路網データ）を使ってさらに計算処理を行い、成果物として構造化データとビジュアルを両方生成しています。ファインチューニング（モデル自体を追加学習で調整する手法）ではなく、既存モデルにツール呼び出しとサンドボックス実行環境を与えることで実現している点も重要です。モデルの重み自体は変えず、周辺のツール群とオーケストレーション（複数処理の調整・実行順序の管理）で機能を拡張する設計です。
一方で問題も明らかになりました。ユーザーが後から「どんなコードを実行したか教えて」と尋ねたところ、ChatGPTはPythonコードを再提示できませんでした。理由として挙げられているのがcompaction（会話履歴やコンテキストを要約・圧縮してトークン数を減らす処理）です。長時間のエージェント実行では、モデルが扱うコンテキストウィンドウ（一度に処理できるテキスト量の上限）を超えないよう、古いやり取りを要約して圧縮することがあります。この圧縮処理によって、実行済みコードの詳細な履歴が失われてしまったとみられます。
既存技術との比較で見える立ち位置
この構成は、LangChainやLlamaIndexのようなオーケストレーションフレームワークが提供する「エージェント＋ツール呼び出し」パターンと基本思想は共通しています。ただし大きな違いは、ツール定義・実行ログ・中間コードがすべてChatGPTのプラットフォーム内に隠蔽されている点です。
自前でLangChainなどを使ってエージェントパイプラインを組む場合、各ステップのログやツール呼び出しの引数はほぼすべて開発者側で確認できます。今回のケースでは可視化用HTMLファイル自体は取得できたものの、Overpassへのクエリ内容やルート計算のロジックは開発者が検証できないブラックボックスのまま処理が完了しています。
これはMCP（Model Context Protocol、LLMと外部ツール・データソースを接続する標準プロトコル）を使った自前構成との対比でも整理できます。MCPサーバーを自分で立てて同様のジオコーディング・地図データ取得・可視化パイプラインを組めば、各ツール呼び出しのリクエストとレスポンスをログとして残せます。監査性や再現性を重視する業務用途では、この違いが選定の分かれ目になります。
読者が今日確認できること
エージェント型LLMサービスを業務パイプラインに組み込む際は、以下の点を確認しておくと安心です。
- 使用しているサービスが長時間タスクでcompaction（履歴圧縮）を行うか、行う場合は圧縮前のログが保持・取得可能かを公式ドキュメントで確認する
- ツール呼び出し（API名・パラメータ・実行コード）がUI上または管理画面でエクスポート可能かをチェックする
- 外部リソース読み込みがある場合、CSP（Content Security Policy、読み込み許可先を制限するブラウザのセキュリティ機構）でどのCDNが許可されているかを確認する。今回のケースではcdnjs.cloudflare.com、esm.sh、cdn.jsdelivr.net、unpkg.com、フォント系CDNのみが許可され、それ以外は「fail silently」（エラー表示なく黙って失敗する）という仕様でした
- 再現性が必要な処理（監査ログ、コンプライアンス要件がある業務）は、ブラックボックス型のエージェントサービスではなく、MCPやLangChainなど自前でログを保持できる構成を検討する
特に「fail silently」という挙動は見落としやすい注意点です。許可外のCDNからリソースを読み込もうとした場合、エラーメッセージが出ないまま機能が動かなくなるため、可視化や外部連携を組み込む設計では事前に許可リストを把握しておく必要があります。
まとめ
今回のケースは、LLMエージェントが複数の外部API（Nominatim、Overpass）とローカル実行環境を組み合わせ、27分かけて自律的にタスクを完遂した好例です。同時に、compactionによる実行履歴の消失という、エージェント運用特有のリスクも浮き彫りになりました。
自分のプロジェクトでエージェント型LLMを検討する際は、まず対象サービスのモデルバージョンとエージェント機能の対応状況を公式リリースノートで確認してください。そのうえで、長時間タスクにおけるコンテキスト圧縮の仕様と、実行ログのエクスポート可否を必ず洗い出しておくことが、後々のトラブルシューティングを楽にする一歩になります。