投稿者 投稿日: カテゴリー ChatGPT
Programmatic Tool Callingとは、AIがコードを書いてツール呼び出しを自動編成するAPI機能のことです。
2026年7月9日、OpenAIはGPT-5.6ファミリー(Sol・Terra・Luna)を一般提供に切り替え、同時にResponses APIへProgrammatic Tool Calling、マルチエージェント編成(ベータ)、persisted reasoning、明示的プロンプトキャッシュという4つの新機能を載せました。受注処理や在庫連携のようにツール呼び出しが数十回連鎖するEC自動化では、この4つの使いどころを押さえるかどうかでAPI費用と処理時間が大きく変わります。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル(うるチカラ運営)の現場知見にもとづいて、Responses APIの新機能をEC業務へ落とし込む手順を解説します。
GPT-5.6のAPI新機能は何を解決するのか
結論を先に書くと、Programmatic Tool Callingが解決するのは「ツール呼び出しのたびに中間結果を全部モデルへ戻す」従来型エージェントの無駄です。OpenAIの公式モデルガイドによると、GPT-5.6はツールを1回ずつ呼んで結果を見て次を考えるのではなく、複数ツールの呼び出しを編成する軽量なJavaScriptプログラムを自分で書き、ネットワークアクセスのない隔離されたV8ランタイム上で実行します。中間データはプログラム側でフィルタリングされ、モデルに戻るのは必要な状態だけです。
EC業務でこの差が効く場面は具体的です。たとえば「楽天・Amazon・Yahoo!の3モールから昨日の受注を取得し、送料区分ごとに集計して出荷指示を作る」処理を従来のFunction Callingで組むと、モール3回×受注ページネーション数回のツール応答がすべてプロンプトに積まれ、入力トークンが膨らみます。Programmatic Tool Callingなら、ループと集計はコード側で回り、モデルには集計後のサマリだけが返ります。MarkTechPostの解説でも、この「中間結果を返さない」設計がGPT-5.6のAPI面での最大の変更点とされています。
あわせて押さえたいのが残り3機能です。マルチエージェントはResponses APIのベータ機能で、GPT-5.6のインスタンスが複数のサブエージェントを並列に走らせて結果を統合します。persisted reasoningは、推論の中間状態(reasoning items)をターン間で持ち越す仕組みで、ステップ3の思考をステップ4に引き継げるため、長い業務フローの多ターン品質とキャッシュ効率が上がります。明示的プロンプトキャッシュは、どのプレフィックスをキャッシュするかを開発者が指定できる機能で、キャッシュ寿命は最低30分、書き込みは非キャッシュ入力単価の1.25倍、読み出しは90%割引という料金設計です。
なおGPT-5.6 Solはエージェント的なコーディングタスクでトークン効率が54%改善したとOpenAIは説明しています。モデルの性格づけとしては、Solが最上位、Terraが知能とコストのバランス、Lunaが大量処理向けの省コスト版という3層です。3モデルの選び分けと料金の考え方はGPT-5.6 Sol・Terra・LunaのEC向けコスト解説で詳しく扱っています。
EC自動化への実装手順(プロンプト3本)
実装は「ツール定義の整理→Programmatic Tool Calling有効化→キャッシュ設計」の順で進めるのが定石です。最初にやるべきは、自社のEC業務でツール呼び出しが3回以上連鎖している処理の棚卸しです。現場で繰り返し見るのは、受注CSVの取得・変換・検品・出荷指示のような直列フローと、複数モールの価格・在庫を突き合わせる並列フローの2種類で、前者はProgrammatic Tool Calling、後者はマルチエージェントベータの適性が高い、というのが編集部で実際に検証した際の感触です。
以下、ChatGPT(GPT-5.6)でそのまま使えるプロンプトを3本掲載します。宣言どおり3本です。
1本目は、自社業務のどこにProgrammatic Tool Callingを入れるべきかを診断させるプロンプトです。開発着手前の企画段階で使います。
プロンプト1:EC業務のツール連鎖診断
あなたはEC業務の自動化アーキテクトです。
以下の業務フローを分析し、Programmatic Tool Calling(モデルがコードでツール呼び出しを編成する方式)に置き換えるべき箇所を特定してください。
業務フロー:
{例: 楽天RMSから受注CSVをダウンロード→倉庫システムの在庫を照会→引当→送り状データ作成→出荷指示}
出力条件:
1. ツール呼び出しが連鎖している箇所と回数の推定
2. 中間データのうちモデルが読む必要のない部分(コード側でフィルタすべき部分)
3. 従来型Function Callingと比べた入力トークン削減の見込み(目安で可、根拠を1行)
4. 隔離ランタイムはネットワークアクセス不可のため、外部API呼び出しをツール定義側に寄せる設計案
2本目は、Responses API向けのツール定義とオーケストレーション方針を書き起こさせるプロンプトです。エンジニアと非エンジニアの橋渡しに使えます。
プロンプト2:Responses APIのツール定義ドラフト作成
あなたはOpenAI Responses APIの実装に詳しいエンジニアです。
以下のEC業務をProgrammatic Tool Callingで自動化するための、ツール定義(名前・引数・返り値)のドラフトをJSONスキーマ形式で作成してください。
業務: {例: 3モールの在庫数を取得し、乖離が5%以上のSKUだけをリスト化してSlackに通知}
条件:
1. ツールは最小限に分割する(1ツール1責務)
2. 各ツールの返り値には、コード側でフィルタしやすいようソート可能なキーを含める
3. モデルに返す最終状態のデータ構造も定義する
4. persisted reasoningを使う前提で、ターンをまたいで保持すべき文脈を1行で明記する
3本目は、明示的プロンプトキャッシュの設計用です。キャッシュ書き込みは1.25倍の課金がかかるため、置き場所を間違えると逆にコストが増えます。
プロンプト3:プロンプトキャッシュの配置設計
あなたはLLM APIのコスト最適化コンサルタントです。
以下のシステムプロンプトとツール定義を分析し、GPT-5.6の明示的プロンプトキャッシュでキャッシュすべきプレフィックスと、毎回変わる可変部分を分離してください。
対象: {システムプロンプト全文とツール定義を貼り付け}
条件:
1. キャッシュ対象は「30分以内に2回以上再利用される」部分に限定する
2. 書き込み1.25倍・読み出し90%割引の料金前提で、1日あたりの想定呼び出し回数から損益分岐の再利用回数を計算する
3. 商品マスタなど更新頻度が高いデータはキャッシュに入れない理由を添える
導入の最初の一歩としては、いきなり基幹の受注処理へ入れるのではなく、レビュー収集や競合価格モニタリングのような読み取り専用の業務で2週間ほど試験運用し、トークン消費のビフォーアフターを取るのが安全です。ChatGPTの社内活用全般の設計はChatGPT WorkとSlack・Drive連携によるEC業務自動化の記事も参考になります。
楽天・Amazon・Shopifyでの適用シナリオ
どのモールで効果が出やすいかを結論から言うと、API経由の定型処理が多いAmazonとShopifyが先行し、楽天市場はCSV運用との併用になります。順に見ていきます。
Amazonの場合、SP-APIで受注・在庫・レポートの取得がAPI化されているため、Programmatic Tool Callingとの相性が最も良い環境です。実装イメージとしては、注文レポートの取得、FBA在庫の照会、価格改定の3ツールを定義し、「在庫が30日分を切ったSKUだけ発注案を作る」「カート取得率が落ちたASINだけ価格シミュレーションを回す」といった条件分岐をコード側で処理させます。従来は数百SKUぶんの在庫データがそのままプロンプトへ流れ込んでいた処理が、コード内のフィルタで「対象SKUのみ」に絞られてからモデルに渡るため、SKU数が多い店舗ほど削減が効きます。
Shopifyの場合、Admin APIのGraphQLで注文・商品・顧客を横断取得できるため、「直近30日の新規顧客のうち2回目購入がない層を抽出し、セグメント別のフォローメール文面を作る」というCRM系の自動化が組みやすい構造です。メール文面の生成はモデルの仕事、セグメント抽出のループはコードの仕事、という分担がProgrammatic Tool Callingの設計思想そのものと一致します。
楽天市場は事情が異なります。RMSのAPI開放範囲は限られており、店舗運営の主要データはCSVダウンロードに依存する場面が残ります。このため実装は「CSVを置き場から読むツール」を定義してのバッチ処理が中心になります。それでも、商品別売上CSVとRPP広告実績CSVを突き合わせて「広告費率が粗利率を超えたSKUのリストだけ返す」ような集計はコード側で完結でき、判断コメントの生成だけをモデルに任せる構成なら十分に実用になります。楽天R-Mailの文面生成など楽天市場内で完結する施策と組み合わせるのが前提です。
3モール共通の注意として、各モールのAPI利用規約とレート制限は必ず事前に確認してください。特に価格改定や在庫更新のような書き込み系ツールは、試験運用の間は実行直前で人間の承認を挟むドライラン構成にしておくと事故を防げます。
失敗例と回避策
1つ目の失敗パターンは、隔離ランタイムの制約を見落とすことです。Programmatic Tool Callingが実行するコードはネットワークアクセスのないV8環境で動くため、コードから直接モールAPIを叩く設計は動きません。外部アクセスはすべてツール定義側に寄せ、コードは「どのツールをどの順で呼び、結果をどう絞るか」に専念させる構造が前提になります。ある家電ジャンルの店舗支援で観測したのは、既存のスクレイピングスクリプトをそのまま移植しようとして止まったケースでした。
2つ目は、マルチエージェントベータの使いすぎです。並列サブエージェントは応答は速くなりますが、エージェント数ぶんトークンを消費します。3モール比較程度なら1エージェント+Programmatic Tool Callingで足りることが多く、並列化は「調査対象が互いに独立で、かつ各調査が重い」場合に限定するのが費用対効果の面で妥当です。ベータ段階の機能である点も踏まえ、本番の受注系には入れず分析系から使うのが無難です。
3つ目は、キャッシュの当てすぎです。書き込みが1.25倍である以上、30分以内の再利用が見込めないプレフィックスをキャッシュすると単純に25%の割高になります。深夜バッチのように1日1回しか走らない処理はキャッシュ対象から外す判断が必要です。逆に、商品説明文の一括生成のようにシステムプロンプトと商品マスタの共通部分が数百回再利用される処理では、キャッシュ設計だけで入力コストが目に見えて下がります。まず呼び出しログから「同一プレフィックスの30分内再利用回数」を集計し、2回以上のものだけキャッシュ対象にする運用が堅実です。
4つ目は、コードにビジネスルールを埋め込みすぎることです。Programmatic Tool Callingが書くコードはあくまで実行時に生成される編成ロジックであり、送料の閾値や粗利率の下限のような業務ルールをモデル任せにすると、実行のたびに微妙に違う判断が混ざるリスクがあります。業務ルールはツール定義側の引数やバリデーションとして固定し、モデルには「どの順で呼ぶか」だけを委ねる線引きが、監査可能性の面でも望ましい構成です。
KPI設計と費用・工数目安
効果測定の軸は3つに絞ると運用しやすいです。第一に入力トークン数の削減率です。ツール応答をモデルに戻さなくなるぶん、ツール連鎖の長い処理ほど削減幅が出ます。削減率は処理の形状に依存するため、事前の見込みは立てず、試験運用2週間の実測で判断するのが確実です。第二にキャッシュヒット率で、明示的キャッシュ導入後は読み出し90%割引が効いた呼び出しの比率をダッシュボードで追います。第三に処理あたりの所要時間です。
費用面では、ChatGPTの個人向けプラン(Plus 20米ドル/月など)とは別に、API利用は従量課金です。GPT-5.6の各モデルの正確な単価は執筆時点の公式料金ページでの確認をおすすめします(モデル別単価は変動があるため要確認)。工数の目安としては、既存のFunction Calling実装がある場合の移行は小規模なフローで数人日、ゼロから受注系を組む場合は要件定義込みで1〜2か月を見ておくと現実的です。
KPIの取り方で1点補足すると、削減率は「処理1回あたりの合計トークン」ではなく「業務1件あたりのコスト」で見るべきです。Programmatic Tool Callingは1回の呼び出しでより多くの仕事を片付けるため、呼び出し単位の比較ではむしろ増えて見えることがあります。受注100件の処理にかかった総コスト、SKU1,000件の説明文生成にかかった総コストのように、業務量を分母にした単価で前後比較すると効果が正しく測れます。直近の支援案件で観測したのは、この分母設定を誤って「効果なし」と早合点しかけたケースで、分母を業務量に直した途端に評価が反転しました。
今後の展望と独自考察
GPT-5.6のAPI新機能は、単発の質問応答から「長時間動き続ける業務エージェント」へ課金と設計の重心を移す布石だと読んでいます。persisted reasoningとプロンプトキャッシュはどちらも「同じ文脈で何度も呼ばれる」ことを前提にした機能で、EC事業者にとっては、朝の受注処理・昼の在庫同期・夕方のレポートという定時バッチ群をひとつのエージェント文脈に統合する設計が現実味を帯びてきました。
競合との位置関係では、AnthropicがClaude Codeやスキル機構でエージェントの「手元実行」を強化し、Googleが動画・画像系の生成をAPIに載せてくる中、OpenAIはオーケストレーション層の効率化で差を付けにきた格好です。どのベンダーに寄せるかの判断は、モデル単体の賢さよりも「自社の業務フローがどの実行環境に載せやすいか」で決まる局面に入っています。5,000社支援の中で何度も再現したパターンとして、ツールの数が10を超えたあたりから編成コストが品質を左右し始めるため、ツール連鎖の多い事業者ほどProgrammatic Tool Callingの恩恵は大きいはずです。
よくある質問
Programmatic Tool Callingは無料で試せますか
いいえ、API従量課金の対象です。ただしResponses APIの標準機能として追加料金なしで使えるため、既存のGPT-5.6 API利用の範囲内で試験できます。まずは読み取り専用の小さな業務で実測するのが安全です。
従来のFunction Callingは使えなくなりますか
いいえ、従来方式も引き続き使えます。ツール呼び出しが1〜2回で終わる単純な処理は従来方式のままで問題ありません。連鎖が3回以上になる処理から順に移行するのが現実的です。
マルチエージェントは本番業務に使えますか
マルチエージェントとは、GPT-5.6が複数のサブエージェントを並列に走らせて結果を統合するベータ機能のことです。ベータ段階のため仕様変更の可能性があり、受注・決済のような基幹系ではなく、市場調査や競合分析のような分析系から使うことをおすすめします。
プロンプトキャッシュはどんなEC業務で効きますか
30分以内に同じシステムプロンプトで何度も呼び出す業務で効きます。具体的には、営業時間中に流れ続ける問い合わせ一次対応や、SKU単位でループする商品説明文の一括生成が該当します。1日1回のバッチには向きません。
GPT-5.6のどのモデルを選ぶべきですか
編成が複雑な自動化はSol、日常的な生成業務はTerra、大量の定型処理はLunaが目安です。迷ったらTerraで組み、品質が足りない工程だけSolに切り替える二段構えが費用対効果に優れます。
導入に社内エンジニアは必須ですか
はい、Responses APIの実装にはエンジニアが必要です。ただし本記事のプロンプト1〜2のように、要件定義とツール分割の設計はAIに下書きさせられるため、外部委託する場合も仕様書作成の工数を大幅に圧縮できます。
persisted reasoningを使うとコストは上がりますか
いいえ、むしろ多ターン処理の効率が上がる方向の機能です。persisted reasoningとは、推論の中間状態をターン間で再利用してキャッシュ効率と品質を高める仕組みのことです。過去の文脈をプロンプトへ再エンコードし直す必要が減るため、長い業務フローほど恩恵があります。
楽天市場の業務にも使えますか
はい、使えますが構成に工夫が要ります。楽天RMSはAPI開放範囲が限られるため、CSVダウンロードを起点にしたバッチ処理としてツールを定義するのが現実的です。売上CSVと広告実績CSVの突き合わせ集計のような読み取り系の分析から始めることをおすすめします。
参考文献
- OpenAI・Model guidance(公式ドキュメント)
- OpenAI・Changelog(公式API変更履歴)
- MarkTechPost・OpenAI Releases GPT-5.6: A Three-Tier Model Family With Programmatic Tool Calling
著者：齋藤竹紘（株式会社オルセル 編集長／5,000社以上のEC支援実績／書籍3冊）
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）
株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
