PTC推論と決定論的実行の分業
前提
1ステップ＝1推論。ステップ数に比例して、高く・遅く・ブレる
通常のツール呼び出しは、ツールを呼ぶたびに結果がコンテキストに戻り、次の1手を決めるためにまたモデルを回す。100件処理なら100往復。その間ずっと過去の全中間結果を抱えたままモデルを回し続ける。
従来：逐次ツール呼び出し推論 × N回
判断→実行→判断→実行→判断→実行→…
毎ステップ推論。中間結果が全部コンテキストに積み上がる。
PTC推論 × 判断箇所のみ
判断＝手順をコードとして一度だけ設計→実行（決定論）＋ 点で推論→集計（決定論）
繰り返し・分岐・集計はランタイムが実行。推論は判断が必要な箇所だけ、プログラムの中から呼ぶ（llm_call、構造化出力でスキーマ固定）。
分業の線引き
判断はAI、手順はプログラム
どこに線を引くかが設計。曖昧さを扱うのはLLM、数を扱うのはコード。
コード（決定論）が担う抜けない・重複しない・数を間違えない
- 繰り返し・件数管理
- 明示ルールの分岐
- 集計・計算・整形
- キー突合・重複チェック・リトライ
LLM（推論）が担う1件だけ・独立した文脈に閉じる
- 意味理解・要約・分類
- 曖昧な判断・例外の検知
- 文章からの構造化抽出
- 判断理由の説明
業務例
契約書100件をチェックし、ルール違反を抽出してレポートを作る
プログラムが100件を繰り返す。AIが1件ずつ読み解いて違反を判定する。プログラムが集計してレポートにする。100件を100件のまま処理する。
✕ システムだけ
契約書100件
↓
プログラムで処理
↓
読めずに停止
プログラムは手順は得意だが、文章の意味は理解できない。
✕ AIだけ
1件目 → AIが読む
↓
2件目 → AIが読む
↓
3件目 → … 前を忘れる／抜け漏れ
AIは1件読むのは得意だが、100件を確実に繰り返すのは苦手。
✓ Askhub PTC
システムプログラムが100件を繰り返す
AI1件読み解き、違反かどうか判定
システム↺ 次の1件へ → 集計 → レポート完了
誤りは1件に局所化され、累積しない。実行内容はコードとして残り、再実行で同じ結果になる。
3つの効果
推論を挟む回数を減らすほど、速く・正確に・大量に
01
推論コストが下がる
- —N回のモデル往復 → プログラム1回
- —毎ターンのシステムプロンプト＋全履歴の再送が消える
- —判断の重さでモデルを振り分け — 1件分類はFlash-Lite、難所だけOpus
02
確実性が上がる
- —100件は100件処理される。ループはコードなので抜けない・重複しない
- —四則演算・突合・整形はモデルを通さない
- —構造化出力で戻り値の形を保証。コードが残り、再実行で同じ結果
03
処理能力が増える
- —中間データは変数・ファイルに置かれ、コンテキストに載らない
- —返るのは集計済みの要約だけ。1,000件でも文脈は膨らまない
- —並列化・ページング・0件時の再クエリをコードで制御
3方式の対比
逐次呼び出し・RPA・PTC
RPAは文章の意味が読めない。AIは100件を数え続けられない。PTCは両方をやる。
逐次ツール呼び出し
RPA・ワークフロー
PTC
手順の担い手
毎回モデルが判断
人が事前に固定
モデルが実行時にコード化
推論回数
ステップ数に比例
0
判断箇所のみ
100件の再現性
揺れる・抜ける
完全
完全
文章の意味理解
可
不可
可（1件ずつ）
コンテキスト消費
中間結果が全部積む
—
最終要約のみ
変更コスト
プロンプト調整（挙動不安定）
フロー改修＝開発
会話でコード修正
実装例
台帳を集計し、編集可能なレポートを生成する
売上台帳・製造原価台帳をプログラムで集計し、AIがインサイトを書き、PowerPointとして出力。集計はコード、解釈はAI。図表はテキスト選択・後編集が可能な形式。
- 「100件の文書を横断検索して集計」を1往復で完結
- llm_call で構造化出力付きの推論をプログラム内から呼ぶ
- Claude／GPT／Gemini いずれのモデルでも動作
- 業務を理解したコンサルが直接コード化。Agent BuilderがPTCスクリプトを自動生成
