第2章：実務判断に必要な技術理解

この章の使い方

誰向け

第1章のテンプレート活用を試し、次に「なぜ効くのか」「どこで失敗するのか」を理解したい人。
生成AIを業務へ組み込む担当として、prompt だけでなく、structured output、tool use、review 責任まで設計したい人。
モデル選定やPoCの前提として、token、context、uncertainty、sampling、limitations、cost-latency-quality の基本を実務言語で押さえたい人。

この章でできるようになること

生成AIを「賢い箱」ではなく、「限られた context 内で次の出力を確率的に選ぶ部品」として説明できる。
情報欠落、context 設計不備、schema 設計不備、tool 境界不備が、どの失敗につながるかを切り分けられる。
structured output と tool use を使うべき場面と、人間に判断を残すべき場面を分けて設計できる。
品質だけでなく、コスト、レイテンシ、運用負荷を同時に見て設計判断できる。

最短ルート

2.1 で「モデルは何をしているか」をつかむ。
2.2 で token と context の制約を理解する。
2.4 と 2.5 で structured output と tool use の設計原則を押さえる。
2.6 と 2.7 で、人間に残す判断と cost-latency-quality の折り合いを整理する。

深掘りルート

2.1 から 2.3 を通読し、uncertainty と sampling の意味を腹落ちさせる。
2.4 で schema 設計、2.5 でツール境界、2.6 で責任分界を具体例で確認する。
2.7 の運用指標を自チームのユースケースに当てはめる。
章末チェックリストを使い、現在の prompt や workflow を棚卸しする。

はじめに

生成AIを業務で使い始めると、多くの人が同じ壁に当たる。

なぜ同じ依頼でも答えが揺れるのか。
なぜ長い仕様書を読ませると重要条件が抜けるのか。
なぜ自然文ではうまく返すのに、JSON になると壊れるのか。
なぜ検索や社内DB接続を付けたのに、安心して自動化できないのか。

この壁を越えるには、数式よりも先に、実務判断に必要な技術理解が要る。本章の目的は、研究論文の詳細を暗記することではない。実務者が次の判断をできるようにすることだ。

これは prompt の問題か、context 設計の問題か。
これは model 単体で任せるべきか、tool use が必要か。
これは structured output で機械処理まで進めてよいか。
これは最後に human review を必須にすべきか。
この改善は quality 向上に見合う cost と latency か。

一次情報の確認日は 2026-07-21 である。OpenAI、Anthropic、Google、MCP などの API、tool、structured output、evaluation 関連機能は更新頻度が高い。本文では時点依存の実装差を固定値として断定しすぎず、2026-07-21 時点の一次情報に基づく設計原則として整理する。採用前に再確認すべき条件は、本文中で都度明示する。

2.1 生成AIを実務で理解する最小モデル

まず押さえるべき前提

生成AIは、入力文を読んで「意味」を完全理解しているわけではない。実務上の理解としては、次のように捉えると判断を誤りにくい。

入力は token に分解される。
モデルは与えられた context の範囲で token 同士の関係を処理する。
その時点で最も妥当と推定した次の出力候補に確率を割り振る。
sampling の設定に応じて、次の token を選ぶ。
これを繰り返して回答、JSON、要約、ツール呼び出し案を生成する。

この見方を持つだけで、期待値設定が変わる。モデルは「事実を知っているか」よりも、「今の context からそれらしい次の出力を作れるか」で振る舞う。したがって、情報が足りないのに正答だけを期待する設計は成立しにくい。

モデルは賢さよりも条件設定に強く依存する

実務での失敗は、model 性能の不足だけで起きるわけではない。むしろ多いのは、次のような条件設計の不備である。

入力に必要情報が含まれていない。
成功条件が曖昧で、何を優先すべきか不明。
出力形式が曖昧で、後続処理と接続できない。
参照すべき最新データがあるのに、model 単体に答えさせている。
禁止事項や guardrail が明示されていない。

たとえば「この会議メモを整理して」と依頼して失敗するのは、model が低性能だからとは限らない。「誰向けか」「何を残し何を削るか」「次アクションを抽出するか」「未決事項を別欄に出すか」が未定義なら、良い出力は安定しない。

次の出力を選ぶ仕組みが uncertainty を生む

model は、常に一意の正解を保持しているとは限らない。候補が複数ありうる場面では、確率分布の近い選択肢が並ぶ。その結果として、次のような現象が起きる。

文体は自然だが、事実根拠が弱い回答が出る。
ほぼ同じ依頼でも、強調点が少しずつ変わる。
途中までは正しいが、後半で補完しすぎる。
難しい条件が後段にあると、途中で忘れたような出力になる。

この揺れは、欠陥というより確率的生成の性質である。重要なのは、揺れる前提でシステムを組むことだ。

実務での誤解を先に外す

よくある誤解を整理する。

誤解	実務での理解
高性能 model なら情報不足を埋められる	情報不足は残る。推測はできても保証にはならない。
一度うまくいった prompt は再現される	context、設定、model 版、周辺ツールで再現性は揺れる。
自然文で自然に返るなら自動化してよい	機械処理につなぐなら schema、検証、失敗処理が別途必要。
tool use があれば hallucination はなくなる	ツール結果の解釈や統合でも誤りは起こる。
context を増やせば必ず精度が上がる	不要情報の混入で逆に判断が鈍ることがある。

人間が見るべき観点

model の内部実装を追いかけるより、次の観点を持つ方が業務では有効である。

何が入力されているか。
何が入力されていないか。
何を model に推測させているか。
どの出力を機械処理へ渡すか。
どの判断で人間が最終責任を持つか。

この5点が明確なら、model 名が変わっても設計は崩れにくい。

2.2 token と context の制約を設計に落とす

token は文字数の別名ではない

token は、model が入力と出力を扱うための単位であり、文字数や単語数とは一致しない。日本語では、表記ゆれ、記号、英数字、コード片、URL、表などの混在で token 消費が読みづらい。したがって「本文は短いから大丈夫」という感覚判断は危険である。特に token が膨らみやすいのは次の入力である。

長い議事録や設計書の全文貼り付け
コード、ログ、エラーメッセージの同時投入
Markdown 表、JSON、HTML の混在
過去会話の全履歴持ち回り
schema や tool 定義の大量追加

2026-07-21 時点の一次情報でも各社は token counting や context 管理のガイドを提供している。ただし利用可能な context window や長文時の挙動は model 系統、API、stable/preview 状態で変わるため、採用前に対象 API の現行仕様を再確認する。

context は model の作業机である

context は「model が見られる作業机」と考えるとよい。必要な資料だけが整っていれば判断しやすいが、無関係な資料、古いログ、冗長な会話が積まれると重要情報の優先度が下がる。課題は長さだけでなく、質と配置である。

情報欠落を最優先で疑う

実務で最も多い失敗原因は、性能不足より情報欠落である。例えば「この稟議文を要約して」だけでは、誰向けか、何を優先するか、どの形式で返すかが不明なので安定しない。最低限、次の情報は補う。

読者
目的
優先論点
禁止事項
出力形式
情報不足時の扱い

短いが有効な依頼は、次のように書ける。

以下の稟議文を、部長決裁前の事前確認メモとして要約してください。
出力順は、結論 / 期待効果 / 主なリスク / 未確定事項 / 追加確認点です。
本文にない情報は推測せず「本文記載なし」と書いてください。

長文対応は「全部入れる」より「必要部分を再構成する」

大量文書を扱うときは、全文投入より先に次を決める。

本当に必要な情報単位は何か。
どの情報を先頭に固定すべきか。
どの情報を検索や参照で後から取得すべきか。
どこで要約を挟むべきか。

分割単位の例は、章、論点、顧客案件、チケット、FAQ 項目、API endpoint ごとである。先頭に置くべきなのは、タスク目的、成功条件、禁止事項、参照優先順位、出力 schema である。

context 設計の基本パターン

パターン1: 固定 instruction + 可変データ

固定部分: 役割、禁止事項、出力形式、評価基準
可変部分: 対象文書、顧客情報、チケット本文、当日データ

再現性を保ちやすく、改善対象も分離しやすい。

パターン2: 段階実行

1回で全部やらせず、事実抽出、論点整理、下書き生成、最終整形に分ける。どこで誤りが入ったかを観測しやすい。

パターン3: 取得してから考える

最新情報や社内データが必要な場合、先に検索や DB 取得を行い、その結果だけを渡す。更新頻度の高い業務ほど有効である。

context を増やすと悪化するケース

古い結論と新しい結論が混在している
同じ仕様の版違いが並ぶ
関係者の雑談ログが残っている
参照不要な長文を毎回付けている
過去の誤回答をそのまま履歴として残している

context 設計の実務SOP

最終成果物を一文で定義する。
必須入力を列挙する。
入力を「固定」「可変」「外部取得」に分類する。
推測禁止の項目を列挙する。
出力形式を自然文か schema かで決める。
human review の条件を書く。

実務上の要点

context 設計で効くのは、長く書くことではなく、必要情報を適切な順序で置くことである。長文対応でも、情報の再構成、検索の併用、段階実行の方が、単純な全文投入より安定しやすい。

2.3 uncertainty と sampling を業務品質に結びつける

uncertainty は「弱さ」ではなく出力特性である

model は、候補が複数あるときに確率分布を持つ。これが uncertainty の源である。業務上は次の2種類に分けて考えるとよい。

情報不足による uncertainty
表現候補の多さによる uncertainty

前者は、入力や tool use を改善しない限り解消しない。後者は、sampling 設定や出力形式の制約である程度制御できる。

情報不足による揺れ

例えば、障害報告の原因分析を依頼したとする。ログが一部欠けていれば、model はもっともらしい仮説を作れてしまう。しかし、その仮説は因果確認ではない。この種の揺れを減らす方法は明確である。

欠けている観測値を追加する。
分からない場合は「分からない」と出させる。
仮説と確定事項を分けて出力させる。
根拠欄を必須にする。

表現候補の多さによる揺れ

メール文面、要約、記事下書き、FAQ 草案では、正解が複数ある。このとき出力差が出るのは自然である。重要なのは、どこまでの自由度を許容するかを決めることだ。

自由度を上げてもよい場面

たたき台作成
キャッチコピー案の列挙
会議タイトル案の発散
研修コンテンツの例示

自由度を下げるべき場面

契約要約
規程の差分整理
JSON 出力
承認 workflow へ連携する判定値
セキュリティ手順書の更新提案

sampling は創造性設定ではなく出力分布の制御である

sampling というと「創造的にする設定」と説明されがちだが、実務では少し不正確である。本質は、候補分布からどの程度広く選ぶかを制御することだ。設定名称や利用可能パラメータは API ごとに異なる。2026-07-21 時点でも、temperature、top-p、seed 相当の制御可否や意味合いは提供面で差がある。したがって、社内標準ではパラメータ名を覚えるより、意図を言語化する方が重要である。

再現性を優先したい。
少数の候補に絞りたい。
発散させたうえで比較したい。
tool call と final answer で設定を変えたい。

実務での設定方針

方針1: 機械処理前提なら揺らさない

次の用途では、できるだけ分布を狭める設計が望ましい。

分類ラベル出力
JSON schema 出力
ツール引数生成
監査ログ要約の定型欄
FAQ の既知カテゴリ振り分け

ただし、設定だけで完全に deterministic になるとは限らない。model 更新や並列処理、ツール結果差分でも出力は揺れる。そのため、再現性は設定だけでなく、入力固定、schema 制約、回帰テストで担保する。

方針2: 発散用途は候補生成に分ける

アイデア出しをするとき、1回で最終文面まで決める必要はない。

まず案を3件出す。
次に評価軸で比較する。
最後に1件を選んで磨く。

このように工程分割すると、sampling の揺れを管理しやすい。

方針3: 不確実性を明示させる

技術調査や障害分析では、確信度の表現を output contract に入れると有効である。

各論点について次を出力してください。
- 確定している事実
- 妥当性の高い仮説
- 追加で必要な情報
- 今は判断しない方がよい点

これにより、もっともらしい断定を減らしやすい。

sampling で解決できない問題

次は設定調整では解決しない。

最新情報が必要なのに入力が古い。
必須根拠が context にない。
schema が曖昧で field 意味が重複している。
1ターンに処理を詰め込みすぎている。
業務ルールそのものが未定義。

問題の所在を誤ると、延々と prompt tuning を続けることになる。

2.4 structured output は「きれいな JSON」ではなく契約である

なぜ自然文だけでは運用が不安定なのか

人が読むだけなら自然文でも使える。しかし業務では、チケット分類、台帳登録、workflow 起票、レポート集計、承認ルート分岐など後続処理が続くことが多い。自然文しか返らないと、後続処理の実装が脆くなる。そこで必要になるのが structured output である。

structured output の本質

structured output は、model 回答を schema に沿って制約し、後続処理との契約を明確にする仕組みである。2026-07-21 時点の一次情報では、主要ベンダーは JSON Schema 等を使った schema 準拠出力、または function/tool 呼び出し用の構造化引数生成を提供している。ただし strict 制約の範囲、schema 制限、tool 併用可否、stable/preview 状態は API ごとに差があるため、採用前に再確認する。再確認項目は次の通りである。

strict schema を本番 API で使えるか
enum、nested object、array、nullable 等の制約範囲
refusal や safety block 時の返り値形式
built-in tools と併用できるか
validation failure 時の再試行戦略

schema 設計で先に決めること

良い schema は model のためではなく運用のために作る。先に決める項目は、field 名、field の意味、必須 / 任意、型、許容値、空欄時の扱い、未知値の扱い、後続処理の利用先である。

悪い schema

{
  "type": "object",
  "properties": {
    "result": { "type": "string" },
    "note": { "type": "string" }
  }
}

result に何を入れるか不明で、契約にならない。

改善例

{
  "type": "object",
  "properties": {
    "decision": {
      "type": "string",
      "enum": ["approve", "review_required", "reject"]
    },
    "reason_summary": { "type": "string" },
    "missing_information": {
      "type": "array",
      "items": { "type": "string" }
    }
  },
  "required": ["decision", "reason_summary", "missing_information"]
}

この形なら、承認分岐、人手レビュー、追加確認要求に接続しやすい。

schema を細かくしすぎる罠

schema は細かすぎても扱いにくい。field 意味の違いを model が誤りやすくなり、少しの仕様変更で互換性も崩れやすい。実務では「後続処理に必要な最小限」から始める方が保守しやすい。

validation は必須である

structured output を使っても、アプリ側 validation は不要にならない。最低限、次を検証する。

JSON として parse 可能か
schema 準拠か
業務ルール上の整合性があるか
根拠欄が空でないか
禁止値が含まれていないか

ここでは model validation と業務 validation を分ける。

model validation: 型、必須 field、enum
業務 validation: 日付範囲、金額上限、承認ルート整合、法的文言の review_required など

failure を前提にした設計

structured output は成功時だけでなく失敗時の戻し方が重要である。代表的な失敗は、schema 準拠失敗、必須値の空欄、誤った enum、refusal による欠落、tool result との不整合である。実装側では、自動再試行条件、human review 送付条件、再入力要求条件、監査ログ項目を先に決める。

向く場面と向かない場面

向く場面:

問い合わせの一次分類
会議メモから action item 抽出
契約レビューの論点抽出
社内申請の不足項目検出
QA 判定の pass/fail/review_required 分岐

向かない、または人間判断を残すべき場面:

条文解釈の最終判断
人事評価コメントの適法性判断
重大障害時の対外公表文の確定
与信判断
高リスク契約の承認可否

structured output は整形を強くするが、責任移譲を自動で解決しない。

2.5 tool use は知識追加ではなく実行境界の設計である

なぜ tool use が必要か

model 単体には限界がある。

学習時点以降の情報は自動で最新化されない。
社内データベースの中身も知らない。
実際のメール送信や台帳更新もできない。
計算や検索結果も保証できない。

これを補うのが tool use である。2026-07-21 時点の一次情報では、主要プラットフォームはいずれも、関数呼び出し、組み込み検索、ファイル検索、コード実行、外部サーバ連携などを提供している。ただし実行主体は大きく2つに分かれる。

自分のアプリが実行する client-side / custom tool
ベンダー側基盤で実行される server-side / built-in tool

この差は、責任分界、ログ、権限、再現性、ネットワーク境界に直結する。

tool use で設計すべき4つの境界

1. 権限境界

model に渡した tool は呼べる前提で扱われる。したがって最小権限が原則である。

悪い例: 顧客DBに何でも書ける更新 tool、本番削除を含む運用 tool
良い例: 参照専用検索、下書き保存までの起票、承認済み ID が必要な更新

2. 情報境界

tool が返す情報は必要最小限に絞る。

検索結果は top-k と抜粋に限定する
個人情報はマスキングする
機密列は返さない
参照元 ID を返す

3. 実行境界

ツールを「提案」で止めるか「実行」まで許すかを分ける。状態変更を伴う action には confirmation step を置く。MCP 仕様でも tool invocation には human in the loop を置くべき旨が示されている。

4. 監査境界

最低限残すべきものは、user request、instruction の版、tool 定義の版、tool call 引数、tool result の要約または参照 ID、最終回答、human approval の記録である。

tool use の代表パターン

パターン	典型用途	主な注意点
検索して要約する	社内ナレッジ検索、FAQ 回答案	検索結果 ID を残す。ヒットなしを正常系として扱う。
取得して構造化する	台帳参照、申請フォーム補完、優先度分類	tool result をそのまま信じず schema に整形する。
下書きを作り人間が送る	顧客返信、障害報告、稟議文初稿	送信 action と本文生成 action を分離する。
条件付きで自動実行する	低リスク分類、タグ付け	guardrail、監査ログ、rollback 手順を必須にする。

tool result も誤る

tool use を入れても誤りは消えない。取得元データが古い、model が複数結果を誤統合する、取得できなかった情報を埋める、といった失敗がある。したがって、tool use では「使えるようになること」と「信頼できること」を分ける必要がある。

tool use を入れる判断基準

次のいずれかに当てはまるなら、tool use を検討する価値が高い。

最新情報が必要
社内固有データが必要
計算や検索の再現性が必要
状態変更を伴う
引用元 ID を残したい
人手作業の転記を減らしたい

逆に、単なる言い換えや一般的な文章整形なら、tool use なしの方が保守しやすいことも多い。

2.6 limitations を理解し、人間に残す判断を決める

limitation は「使えない理由」ではなく「責任分界の材料」である

生成AIの limitation を理解する目的は、導入を止めることではない。どこまで任せ、どこから人間が責任を持つかを決めるためである。

主な limitation

1. 事実性の限界

model は、根拠が弱くても自然文として成立する回答を返せる。したがって、事実問題では次を分ける。

参照元が提示できるか
最新性が必要か
誤答コストはいくらか

2. 文脈保持の限界

長い会話や複雑な条件では、前半の制約が後半で弱まることがある。対策は次の通りである。

重要制約を先頭へ再掲する。
段階実行に分ける。
要約して持ち回る情報を選ぶ。
state を外部保存し、都度注入する。

3. 曖昧さ解消の限界

人間なら聞き返す場面でも、model は補完して進めてしまうことがある。そのため、曖昧入力に対しては次のルールが有効である。

必須項目が欠ける場合は質問へ戻る。
選択肢を提示して確認する。
推測で埋めた箇所を明示する。

4. 社会的・法的・組織的判断の限界

法務、労務、人事、広報、医療、金融、セキュリティでは、文面の自然さだけで採用可否を決めてはいけない。判断責任は、組織ルール、法令、契約、説明責任と結びついているからだ。

人間に残すべき判断

次は、人間が最終判断を持つ設計を基本とする。

対外公表の最終文面確定
契約上の義務解釈
個人情報や機密情報の開示可否
解雇、査定、懲戒など権利義務へ影響する判断
高額発注や与信判断
セキュリティ事故の重大度認定
例外処理の承認

human review を形式だけにしない

「最後に人が見る」と書くだけでは、実際には見ない運用になりやすい。実効性のある human review にするには、次を決める。

何を確認するか
どこを確認しなくてよいか
何分以内に判断するか
どの条件で差し戻すか
承認ログをどう残すか

例: 契約レビュー支援

AI に任せる範囲:

条項の抽出
差分の要約
既知論点のタグ付け
参照先テンプレートの提示

人間に残す範囲:

交渉方針の決定
リスク受容可否
例外条項の承認
顧客との最終合意文面

「分からない」を許す設計

運用成熟度が低いチームほど、model に毎回結論を出させたくなる。しかし高リスク業務では、「結論を出さない」こと自体が良い設計である。出力に次の選択肢を持たせるとよい。

approve
review_required
reject
insufficient_information

これだけで、誤自動化の多くを避けられる。

ガバナンスと教育も limitation 対策の一部

2026-07-21 時点の一次情報では、NIST の GenAI Profile、OWASP の LLM / agentic guidance、METI の AI事業者ガイドライン第1.2版、PPC の注意喚起などが、技術対策だけでなく、ガバナンス、文書化、教育、責任分界を重視している。つまり limitation 対策は prompt 改善だけでは完結しない。

利用ルール
権限設計
ログ方針
レビュー体制
教育・リスキリング

これらも同じくらい重要である。

2.7 cost-latency-quality を同時に見る

3つは常にトレードオフする

実務では quality だけを追えない。利用量が増えると、cost と latency がそのまま業務体験と運用費に跳ね返る。高性能 model で精度は高いが応答が遅い、長い context で安定するが費用が膨らむ、低コスト化で review 工数が増える、といった事態は珍しくない。

cost を見る観点

cost は API 単価だけではない。入力 token、出力 token、tool 実行、検索基盤、失敗時の再試行、human review 工数、障害調査コストまで含めて見る。安い model を使っても、人手修正が増えれば全体最適ではない。

latency を見る観点

latency も API 応答時間だけではない。

初回表示時間
tool 込み完了時間
review キュー滞留
再試行込みの最終完了時間

チャット補助、日次バッチ、承認前下書きでは許容値が異なる。

quality を見る観点

quality も一枚岩ではない。

事実性
指示追従
schema 準拠
日本語自然性
根拠提示
安全性
一貫性

用途別の重み付けが必要である。例えば FAQ 一次回答では根拠提示、禁止回答回避、latency が重く、提案書草案では文脈理解、構成力、読みやすさが重い。

代表的な設計パターン

入口は軽く、出口で重くする: 一次分類は軽量、詳細生成は高品質、最終承認は human review
先に絞ってから深く読む: 検索で候補を絞り、必要文書だけ長文投入する
非同期化する: 即時応答は受領だけ返し、重い生成は background で回す

まず測るべき運用指標

指標	例
quality	正答率、schema pass率、根拠付き率、review差戻し率
latency	p50/p95 完了時間、tool込み完了時間
cost	1件あたり総コスト、review込み総コスト
safety	guardrail違反率、個人情報検出率、危険 action 提案率
operability	再試行率、timeout率、手動介入率

最適化で先に効く施策

目的	先に試す施策
cost	不要履歴の削除、system prompt 整理、長文の前処理、前置き再利用、工程分解
quality	成功条件の明確化、context 欠落の補完、schema の簡素化、tool での根拠取得、review_required の逃げ道
latency	同期/非同期分離、tool 数削減、前段要約、短い回答と詳細回答の分離

実務上の結論

cost、latency、quality は別々に最適化しない。業務で本当に見るべきなのは、総コスト、最終完了時間、review 負荷まで含めた全体性能である。

2.8 実務で使う設計テンプレート

テンプレート1: 情報欠落を防ぐ依頼契約

目的 / 対象 / 前提 / 成功条件 / 禁止事項 / 不足時の対応 / 出力形式

テンプレート2: structured output 契約

schema に厳密に従って出力してください。
不明な値は推測せず missing_information に列挙してください。
後続の承認フローで機械処理されるため、自由文の補足は不要です。

テンプレート3: tool use 付き判断

必要な場合のみ最新規程検索、申請者情報取得、過去承認事例検索を行ってください。
判断は approve / review_required / reject / insufficient_information のいずれかに限定します。
外部状態を変更する提案はしてもよいですが、実行前に必ず人間の承認が必要です。

テンプレート4: human review 指示

判断候補
根拠
未確認点
リスク
人間が最終確認すべき項目

この章を現場へ持ち帰るときの要点

prompt 改善だけでなく context 設計を見直す
自然文から structured output への切り替えを検討する
最新情報が必要なら tool use を足す
残る判断は human review へ戻す
最後に cost-latency-quality の全体最適で判断する

章末まとめ

生成AIは、与えられた context の中で次の出力を確率的に選ぶ部品として理解すると、実務判断を誤りにくい。
失敗原因の多くは、model 性能より情報欠落、曖昧な成功条件、過剰な context、曖昧な出力契約にある。
token と context は単なる上限値ではなく、何を入れ、何を削り、どの順で置くかという設計問題である。
uncertainty と sampling は避ける対象ではなく、用途別に制御し、再現性が必要な場面では schema、validation、regression で支える。
structured output は JSON をきれいに出す機能ではなく、後続処理との契約である。
tool use は知識追加ではなく、権限、情報、実行、監査の境界を設計する行為である。
limitation を理解した上で、人間に残す判断を明示し、cost-latency-quality を同時に最適化することが重要である。

実務チェックリスト

次に読む章・参照付録

第3章評価設計とモデル・ツール選定: 本章の技術理解を、モデル比較、PoC、継続評価へ接続する。
第6章知識連携とツール連携: tool use、外部知識接続、自動化境界を具体化する。
付録A AIエージェント実務テンプレート集: context 設計や structured output 指示の叩き台として使う。
付録B 参考文献: 本章で参照した一次情報の source ID を確認する。
付録E 用語集と更新確認ノート: 時点依存の仕様を再確認する際の観点を整理する。

Source Notes

token、context、tool execution 境界、長文運用、tool result の扱いは、ANT-CONTEXT、ANT-TOOLS、OAI-TOOLS、GGL-TOOLS、MCP-SPEC、MCP-TOOLS を参照。
structured output と function/tool calling の設計観点は、OAI-STRUCTURED、OAI-TOOLS、GGL-STRUCTURED、GGL-FUNCTION、GGL-TOOLS を参照。
uncertainty、validation、human in the loop、責任分界、ガバナンスの整理は、NIST-AIRMF、NIST-GENAI、OWASP-LLM-2025、METI-AI-1-2、PPC-GENAI を参照。
2026-07-21 時点依存の主張は、各 API の stable/preview 状態、context window、tool availability、schema 制約が変わりうることを前提に記述した。model 更新、API 版変更、業務リスク上昇時は一次情報を再確認すること。