この教材の目次を開く
回答はこのページを開いている間だけ保持します。別ページへの移動や再読み込みで消えます。保存されるのは読み方の設定だけです。
「保存済みです。」と表示された回答は、同じブラウザーでこの教材を開き直すと復元できます。
1目標を、確かめられる小さな作業へ分ける
「調べてまとめて」と頼むとき、何がそろえば次へ進めるでしょうか。
比べる前に、何がいる？
見るポイント 見学先を比べるには、どの日の案内が必要でしょうか。二人が考えた作業の順番を追います。
コマは上から下へ、横に並んだコマは右から左へ読みます。
会話を文章で読む
場面：資料室の同じ机。左のハルが案内紙2枚を持ち、右手に鉛筆。右のミオとビットも同じ紙と白いメモを見る。
ハル「メモ一枚なら、すぐまとめられるかな。」 ミオ「何を比べるか、先に決めよう。」場面：右のコマ。ミオが開館日の行を指す。ハルは、行く日が未決定と気づく。紙には開館日・行き方・所要時間の3行がある。
ミオ「開館日は、いつ行くかで変わるね。」 ハル「あ、行く日がまだ決まってない。」場面：左のコマ。ハルが右手の鉛筆でメモを書く。「対象日を決める」の下に開館日・行き方・所要時間。案内紙2枚は机の左にある。
ハル「日を決めて、その日の案内を確かめるのが先だね。」場面：同じ机の横長のコマ。右のビットから左のミオへ読む。紙には「対象日を決める」、開館日・行き方・所要時間、下に「対象日→案内の確認→比較メモ」。未確認の答えは空欄のまま。
ビット「次の作業が、どの結果を待つかも見えるね。」 ミオ「まだ分からない所は、空けて残そう。」場面：ハルは鉛筆を机に置き、ミオは案内紙1枚を持つ。もう1枚と、3条件・段取りを残したメモも机上にある。比較や案内の確認はこれからです。
ハル「そろった条件を見てから、比べよう。」
資料室で二人は、見学先を比べるメモに何が必要かを紙へ書き出しました。対象日や案内を確かめてから比較するという、人の段取りを整理した場面です。この行動だけを、AIが内部で計画を選んだ証拠とはしません。本文では、LLMに任せる判断と作業のつながりを分けます。
LLMの判断と、小さな作業の役割
ここでは、目標に向けて道具や記録を使うAIエージェントを考えます。道具は照会や計算などを行う機能です。LLM（大規模言語モデル）は、言葉の並びを扱う大規模なモデルです。依頼を読み、次の作業や回答案を選ぶ中核になります。ただし、モデルが選んだ要求を道具へ渡す仕組みや、記録を保存する仕組みも別に必要です。作業の状態とは、今の目標、済んだこと、未確認のことなどの進み具合を指します。
タスクは達成したい仕事で、大きな仕事を小さな作業へ分けることをタスク分解といいます。分けた一つ一つがサブタスクです。「候補を比べたメモを作る」なら、比較する条件を決める、各候補の案内を調べる、同じ条件で比べる、という作業に分けられます。分けるだけで終わらず、各作業に何を渡し、何を得るか、何を確かめたら済みとするかを決めます。
根拠：Anthropic: Building effective agents（別タブで開く） ↗ / Google for Developers: Machine Learning Glossary（別タブで開く） ↗ / OpenAI Docs: Function calling（別タブで開く） ↗
何を先にそろえるかを計画する
計画は、目標に向けて行う作業と、その順序を具体化することです。ある作業が別の作業の結果を必要とする関係を、依存関係と呼びます。例えば対象日が決まらなければ、その日の利用条件を選べません。候補の条件がそろう前に比較の結論だけを確定することも避けます。独立に調べられる作業は同時に進める構成もありますが、分解すれば全て並列にできるわけではありません。
学習済みモデルを利用して応答や判断を求める処理が推論です。重みは、学習で調整するモデル内部の数値です。推論で計画を考えること、道具が実際に動くこと、重みを学習で調整することは別です。先に工程を決める構成も、途中の結果に応じて工程を選び直す構成もあります。名前の付いた計画が出ただけで、自律的に工程を変えられる仕組みだとは決めません。
根拠：Anthropic: Building effective agents（別タブで開く） ↗ / Google for Developers: Machine Learning Glossary（別タブで開く） ↗ / OpenAI Docs: Reasoning models（別タブで開く） ↗
計画の文と、実際に進んだ状態を区別する
AIの画面に「次は資料を検索します」と出ても、その表示だけでは、道具を呼ぶ要求が出たか、接続先が処理したか、結果に応じて次手を選ぶ構成かは分かりません。文章だけを作る利用でも、手順の文は書けます。任せる範囲は仕組みの説明を、実行した内容は道具や作業の記録を確認します。表示の自然さを、内部制御が確認できた証拠に置き換えません。
完了条件も、文章を書けたことと目的を満たしたことを分けます。例えば比較メモの下書きがあっても、必要な対象日の案内が未確認なら「下書きあり・条件は未確認」という状態です。未確認を残して次の作業を決めます。調べたこと、実行したこと、人がまだ確認することを混ぜずに記録すると、どこへ戻るべきかを追えます。
根拠：OpenAI Docs: Function calling（別タブで開く） ↗ / Anthropic: Building effective agents（別タブで開く） ↗ / Anthropic: Effective context engineering for AI agents（別タブで開く） ↗
図を拡大する ↗図の内容を文章で確認する
対象日と比較条件を先に決めます。候補AとBの案内は別に確かめられますが、比較は両方の必要な結果を待ちます。メモ案を書いた後も、未確認と根拠を照合します。書けたことを前段の作業完了へ読み替えません。
- 読者ができること
- 分解した作業に必要な入力と依存を追い、比較を確定する前に必要な材料をそろえられる。
- 図の項目
- 対象日・比べる条件を決める
- 図の項目
- 候補Aの案内を確かめる
- 図の項目
- 候補Bの案内を確かめる
- 図の項目
- 同じ条件で比較する
- 図の項目
- 比較メモの案
- 図の項目
- 未確認と根拠を照合
- 矢印：対象日・比べる条件を決める → 候補Aの案内を確かめる
- 対象日/比較条件が必要
- 矢印：対象日・比べる条件を決める → 候補Bの案内を確かめる
- 同じ対象日/比較条件が必要
- 矢印：候補Aの案内を確かめる → 同じ条件で比較する
- 候補Aの確認結果が必要
- 矢印：候補Bの案内を確かめる → 同じ条件で比較する
- 候補Bの確認結果が必要
- 矢印：同じ条件で比較する → 比較メモの案
- 比較結果を使って書く
- 矢印：比較メモの案 → 未確認と根拠を照合
- 案の文と確認状態を照合する
- 重要な条件1
- 候補AとBの案内を同時に確かめる構成もあるが、比較は両方の必要な確認結果がそろってから進める。
- 重要な条件2
- 矢印は入力依存で、速さ/性能/年代順ではない。
- 重要な条件3
- この図で与える構成例。手順文が表示された実サービスの内部構成を推定する図ではない。
模式図です。図の全項目・矢印・条件は下の文章版でも読めます。長い注記は拡大の見る位置で意味ごとに分け、左右へ動かして続けて読めます。
根拠：Anthropic: Building effective agents（別タブで開く） ↗
別の場面で確かめる
全て独自作成の問題です。公式問題や試験全体の難易度を再現したものではありません。
2道具への依頼案と、実行して返った結果を分ける
道具へ渡す番号が書けたら、もうその番号の情報を調べたことになるでしょうか。
渡す番号は、これでいい？
見るポイント 画面の番号案と控えの番号を見比べます。受取日を照会する前に、どの番号を渡せばよいか考えます。
コマは上から下へ、横に並んだコマは右から左へ読みます。
会話を文章で読む
場面：クリーニング店の待合。左のハルは右手に紙の「受付番号42」、左手にスマホの「受取日照会用の案／番号24」を持つ。ミオも両方を見る。
ハル「受取日を照会する案が出てる。」場面：紙の42と、スマホ案の24を並べた寄り。ミオの右指はスマホ側へ向く。ミオが42と24を先に読み、左下のハルが応じる。照会を実行した表示はない。
ミオ「控えは42。こっちの案は24だよ。」 ハル「同じ番号じゃなかった。」場面：下段右。ビットの右前足が上がり、ハルが応じる。ハルが持つ紙は42、スマホは番号24の案のまま。
ビット「まず、渡す番号を確かめよう。」 ハル「番号の案と、実際の照会結果は別なんだね。」場面：下段左。ミオの右指はスマホ案の番号付近。紙42と案24を二人で見比べ、送信や実行はしていない。
ミオ「渡す内容を確かめて、返った結果も見よう。」
クリーニング店の待合で、二人は控えの番号と、画面に出た照会用の番号案が違うと気づきました。番号案を見ただけで照会済みとはせず、渡す内容と実際に返る結果を分けて確かめようとした場面です。外の処理の有無は、この表示だけでは確定しません。
道具へ何を渡すかを決める
APIは、ソフトウェア同士が決まった形式で要求や結果をやり取りする窓口です。ここでいう関数は、空き状況を照会するなど、名前と渡す情報を決めた処理です。Function Callingは、モデルが使う関数と、そこへ渡す情報を要求として出す仕組みです。Tool Useは、こうした外部の道具を使うことを指します。Function CallingはTool Useを行う方法の一つとして捉えます。
関数へ渡す具体的な値を引数といいます。例えば「受取予定を照会する」という道具なら、受付番号が引数になります。道具の名前が合っていても、番号が別人のものなら目的の照会になりません。引数の項目、値の種類、依頼と合う対象や日付を確かめます。道具の要求を作ることは、正しい結果を得たことでも、実行したことでもありません。
根拠：OpenAI Docs: Function calling（別タブで開く） ↗ / Anthropic: Building effective agents（別タブで開く） ↗
受け取った仕組みが確認して、道具を動かす
モデルの要求を受けて道具を動かす側を、ここではホストと呼びます。ホストはアプリなどの実行する仕組みです。この例では、使える道具か、引数が依頼に合うか、操作が許可されているかを確認してから実行します。モデルに案を選ばせることと、ホストが実行を認めることを分けます。読み取りだけを許した依頼で、更新や送信の道具まで使えるとはしません。
実行した道具から返った情報が、次の判断の材料になります。返るものは成功の情報だけでなく、失敗や確認できなかった点の場合もあります。こうした結果を受け取り、今分かることを確かめるのが観察です。ホストが実行前に拒否したなら、その拒否を結果として渡し、処理したことにしません。モデルが「更新しました」と書いても、実行記録が実行前の拒否なら、その文を完了の記録に採用しません。
根拠：OpenAI Docs: Function calling（別タブで開く） ↗ / OpenAI Docs: Guardrails and human review（別タブで開く） ↗ / Anthropic: Building effective agents（別タブで開く） ↗
形式が合うことと、使ってよいことを別に確かめる
決めた項目と値の種類に合う要求でも、その番号が今回の対象か、操作してよいかは別に確認します。例えば「照会だけ、申込みは人の確認後」という条件は、関数名や引数を整えただけでは解除されません。許可が足りなければ人へ確認し、実行の前に止まる道を用意します。人が確認する位置を置いたまま、許された調査の次手をモデルに選ばせることはできます。
根拠：OpenAI Docs: Function calling（別タブで開く） ↗ / OpenAI Docs: Guardrails and human review（別タブで開く） ↗ / Anthropic: Building effective agents（別タブで開く） ↗
図を拡大する ↗図の内容を文章で確認する
モデルが関数名と引数の案を出し、ホストが対象・形式・許可を確かめます。認めた要求だけ道具で処理し、結果を返します。実行前に拒否した場合は道具を実行せず、拒否を観察結果として次へ渡します。要求と実行と結果を混ぜません。
- 読者ができること
- モデルが出す引数案と、ホストが実行を認める段階、道具の結果を別に指せる。
- 図の項目
- モデル：道具名・引数の案
- 図の項目
- ホスト：対象・形式・許可を確認
- 図の項目
- 道具：認められた照会を処理
- 図の項目
- 道具の結果：照会内容／失敗／未確認
- 図の項目
- 実行前に拒否：道具は実行しない
- 図の項目
- 返った結果から次を判断
- 矢印：モデル：道具名・引数の案 → ホスト：対象・形式・許可を確認
- 関数名と引数を要求
- 矢印：ホスト：対象・形式・許可を確認 → 道具：認められた照会を処理
- 条件/許可を満たしたときだけ実行
- 矢印：ホスト：対象・形式・許可を確認 → 実行前に拒否：道具は実行しない
- 条件/許可が足りないとき。実行先へ続けない
- 矢印：道具：認められた照会を処理 → 道具の結果：照会内容／失敗／未確認
- 処理の結果
- 矢印：道具の結果：照会内容／失敗／未確認 → 返った結果から次を判断
- 観察として渡す
- 矢印：実行前に拒否：道具は実行しない → 返った結果から次を判断
- 拒否も次の判断材料
- 重要な条件1
- この構成例はホストが実行前確認を行うと本文で与える。全製品へ自動適用しない。
- 重要な条件2
- 整った要求≠値の正しさ≠実行許可。
- 重要な条件3
- 読取り許可を更新/予約/送信許可へ広げない。
- 返った結果と成功の区別
- 道具から処理の結果が返っても、成功とは限りません。照会内容・失敗・未確認を分けて観察し、次を判断します。
模式図です。図の全項目・矢印・条件は下の文章版でも読めます。長い注記は拡大の見る位置で意味ごとに分け、左右へ動かして続けて読めます。
根拠：OpenAI Docs: Function calling（別タブで開く） ↗ / OpenAI Docs: Guardrails and human review（別タブで開く） ↗
別の場面で確かめる
全て独自作成の問題です。公式問題や試験全体の難易度を再現したものではありません。
3残した記録から、今回使う情報を選ぶ
メモを保存したことと、そのメモを今の判断に使ったことは同じでしょうか。
前のメモを、今日も使う？
見るポイント 前回は2人分、今日は4人分です。保存したメモのどこを使い、今回の条件をどこに残すか考えます。
コマは上から下へ、横に並んだコマは右から左へ読みます。
会話を文章で読む
場面：料理教室の作業台。保存メモのタブレットは「前回2人分」。ミオが示す別紙は「今日4人分」。今回用の白紙と鉛筆も台にある。
ハル「保存してあるメモ、そのまま使えるかな。」 ミオ「これは前回の2人分だよ。」場面：右のコマ。ハルの右指先はタブレットの「前回2人分」付近。表示を変えた反応や操作ボタンはなく、前回2人分のまま。
ハル「前回の条件が、残っているんだね。」場面：左のコマ。ハルが「今日は4人分」と読み、その後ビットが応じる。別紙は「今日4人分」。ミオは寄りの外にいる。
ハル「今日は4人分。人数が変わってる。」 ビット「残したメモから、今使う分を選ぼう。」場面：ミオは右手で「今回は4人分」と新しいメモを書き、左手で「今日4人分」の紙を押さえる。左の保存メモは前回2人分のまま。
ミオ「今回の条件を、こっちにそろえよう。」場面：鉛筆は机上へ。前回2人分の保存メモ、今日4人分の紙、今回は4人分のメモの3つを別々に残す。人が選び書いた場面で、AIの自動取得や重み学習の実証ではない。
ハル「保存した記録と、いま使う情報を分けるんだね。」
料理教室の準備台で、二人は前回2人分の保存メモと、今日4人分という用紙を見比べました。人が今使うメモを選び直した例です。AIがその記録を自動的に読んだことや、重みを学び直したことを示す場面ではありません。本文では、保存・選択・入力へ戻す役割を分けます。
作業中の記録と、後でも使う記録
エージェントの記憶（メモリ）は、過去の情報を保持し、必要なときに取り出すための仕組みとして考えます。短期メモリは、今の会話や作業の進み具合を継続して扱う記録です。残す履歴や要約を選び、次の応答へ渡す構成があります。「短期」という名前だけで、記録が必ず保存装置に残らないという意味にはしません。
長期メモリは、会話や作業をまたいで使えるよう保存し、後で取得する記録です。ファイルやデータベースなどに置く構成があります。データベースは、情報を整理して保存し、必要なものを取り出す仕組みです。保存した全記録が毎回自動的にモデルへ渡るわけではありません。どの記録を取得し、今回使うかを選びます。この例の保存や取得は、モデルの重みを追加学習する処理とは別です。
記録を再利用するときも、誰の・いつの情報か、現在も使える条件かを確かめます。前回の人数や希望を、今回の確定条件にすり替えません。記録を訂正・削除する条件、保存を認めた範囲も決めます。短期と長期の境界や保存方法は構成で異なり、人と同じ記憶能力や、全情報を正しく覚え続けることを名前だけで約束しません。
根拠：OpenAI Cookbook: Context Engineering - Short-Term Memory Management with Sessions（別タブで開く） ↗ / Anthropic: Effective context engineering for AI agents（別タブで開く） ↗ / OpenAI Docs: Running agents（別タブで開く） ↗ / OpenAI Docs: Function calling（別タブで開く） ↗
必要な情報と指示を、今回の入力へ組み立てる
コンテキストは、モデルがその応答で使う指示、会話、取得した記録、資料、道具の結果などの情報です。コンテキストウィンドウには扱える量の上限があります。必要な内容を選び、古い値や不要な履歴を整理するのがコンテキスト管理です。保存先にあるだけの情報と、今回の入力へ入った情報を分けます。要約で量を減らしても、例外や確認条件が消えていないか照合します。
コンテキストエンジニアリングは、指示だけでなく、資料・記録・道具の説明や結果を含め、何をどう渡すかを設計して見直すことです。システムプロンプトは、役割や基本的な制約などを、システムを設定する側が与える指示です。今回の質問や、資料に書かれた文章と区別します。ただし、指示文に制約を書いたことだけで、実行時の全ての動作がそのとおりになると認定しません。
根拠：Anthropic: Effective context engineering for AI agents（別タブで開く） ↗ / OpenAI Cookbook: Context Engineering - Short-Term Memory Management with Sessions（別タブで開く） ↗ / Google for Developers: Machine Learning Glossary（別タブで開く） ↗ / OpenAI Docs: Guardrails and human review（別タブで開く） ↗
形式を整えることと、値や動作を確かめること
構造化出力は、結果を決めた項目や値の種類に合わせて受け渡すことです。形式の設計をスキーマと呼びます。例えば「施設名・時刻・確認状況」を必須にする構成です。指定形式への適合を制約する機能にも、拒否や出力が途中で終わる場合などへの対処が必要です。形式に合った出力でも、時刻が原資料と一致するか、確認済みという値に根拠があるかは別に確かめます。形式の検査を通ったことは、値の真実や操作権限の証明ではありません。
ガードレールは、入力・出力・道具の利用などへ確認や制限を組み込み、問題のある処理を止めるための仕組みです。例えば、対象の合わない要求を止める、必要な確認前は送信しない、といった制御を組みます。人の確認は、その条件に達したときに承認や修正を受ける位置です。システム指示、形式の検査、ガードレール、人の確認は役割が違います。導入したという名前だけで全事故を防げるとはせず、実際の結果と条件を点検し、必要なら制御を見直します。
根拠：OpenAI Docs: Structured model outputs（別タブで開く） ↗ / OpenAI Docs: Function calling（別タブで開く） ↗ / OpenAI Docs: Guardrails and human review（別タブで開く） ↗ / Anthropic: Building effective agents（別タブで開く） ↗
図を拡大する ↗図の内容を文章で確認する
保存先から必要な記録を取得し、誰のいつの条件かを確かめ、現在の依頼や指示・道具の結果と合わせて今回のコンテキストへ入れます。学習済みLLMがそれを使って応答します。この例の保存や取得は重みの学び直しではありません。応答の形式と内容を分けて確認します。
- 読者ができること
- 保存先と今回のコンテキスト、重み学習を分け、保存した全情報が毎回自動入力されるとしない。
- 図の項目
- 保存した記録：ファイル・データベース
- 図の項目
- 関連記録を取得：誰の・いつの条件か確認
- 図の項目
- 今回のコンテキスト：現在の依頼＋選んだ記録＋指示/結果
- 図の項目
- 学習済みLLMで推論
- 図の項目
- 今回の応答：形式と内容は別々に確認
- 矢印：保存した記録：ファイル・データベース → 関連記録を取得：誰の・いつの条件か確認
- 必要な記録を選んで取得。全記録を自動投入しない
- 矢印：関連記録を取得：誰の・いつの条件か確認 → 今回のコンテキスト：現在の依頼＋選んだ記録＋指示/結果
- 現在の条件と照合した材料を入れる
- 矢印：今回のコンテキスト：現在の依頼＋選んだ記録＋指示/結果 → 学習済みLLMで推論
- 入力として渡す
- 矢印：学習済みLLMで推論 → 今回の応答：形式と内容は別々に確認
- 応答する
- 重要な条件1
- 短期は作業内の継続、長期は作業をまたぐ保存/取得という役割で比較。保存装置の有無だけでは決めない。
- 重要な条件2
- この例では保存/取得による重みの学習更新はない。
- 重要な条件3
- 形式の整った応答でも、値/権限/安全は別に確かめる。
- 線の読み方
- 太い横向きの4本が主な流れです。上の説明から下へ延びる細い4本は各矢印を説明する引出線で、別のデータ経路ではありません。
模式図です。図の全項目・矢印・条件は下の文章版でも読めます。長い注記は拡大の見る位置で意味ごとに分け、左右へ動かして続けて読めます。
根拠：Anthropic: Effective context engineering for AI agents（別タブで開く） ↗ / OpenAI Cookbook: Context Engineering - Short-Term Memory Management with Sessions（別タブで開く） ↗ / OpenAI Docs: Structured model outputs（別タブで開く） ↗
別の場面で確かめる
全て独自作成の問題です。公式問題や試験全体の難易度を再現したものではありません。
4返った結果から、次の手順と止まる位置を選ぶ
予定どおりに確かめられなかったとき、何を残し、どこへ戻るでしょうか。
ここが閉まっていたら、どう戻る？
見るポイント 東口は閉鎖、西口はまだ確認していません。道順を組み直す前に、何を確かめるか考えます。
コマは上から下へ、横に並んだコマは右から左へ読みます。
会話を文章で読む
場面：スポーツ公園の東入口で足を止める。「東入口 工事中」の柵と、画面左へ向く「案内所←」の道標。西は画面左で、案内所にはまだ着いていない。
ハル「東口へ向かう案だったけど、閉まってる。」 ミオ「掲示を見てみよう。」場面：ミオの右指が「東入口 工事中」を示す。園内マップの「西入口」は位置だけで、開いている表示はない。
ミオ「分かったのは、東口が閉まっていることだね。」場面：ハルのスマホは「確認メモ／東：閉鎖を確認／西：未確認」。西入口を通れると判断した場面ではない。
ハル「西口が開いているかは、まだ分からないね。」場面：ミオが右手で画面左の「案内所←」を示して先に話し、右のビットが応じる。
ミオ「案内所で確かめよう。」 ビット「分かったことと、まだの所を戻して考えよう。」場面：ハル、ミオ、ビットが画面左の案内所方向へ歩き始める。「案内所←」は左向きのまま。まだ案内所へ到着せず、西入口が通れるとも確認していない。
ハル「通れると分かってから、道順を組み直そう。」
運動公園で東入口の閉鎖を見た二人は、西入口は未確認だと整理し、案内所へ確かめに向かいました。人が見た状況から道順を考え直す場面で、AIが内部で再計画した証拠ではありません。本文では、返った観察結果を次の判断へ戻す構成をたどります。
返った情報を、次の判断へ戻す
観察は、道具の返した結果や周りの状況を受け取り、何が分かったかを確かめることです。成功という表示だけでなく、対象・日時・内容が目的に合うかを見ます。「確認できない」「一部だけ取得できた」という結果も、その状態を残します。未確認の数値を0へ変えたり、空の結果だけから対象が存在しないと決めたりしません。
結果を次の判断へ戻し、行動と確認を繰り返すつながりをフィードバックループといいます。例えば、対象日の案内が不足した結果を受け、調べる資料を追加してから比較へ戻ります。ここで結果を戻すのは、次の推論や作業を決めるためです。結果を受け取るたびに、モデルの重みが学習で更新されるという意味ではありません。
根拠：Anthropic: Building effective agents（別タブで開く） ↗ / OpenAI Docs: Function calling（別タブで開く） ↗ / Anthropic: Effective context engineering for AI agents（別タブで開く） ↗
分かったことに合わせて計画を直す
再計画は、結果や条件の変化を受けて、次の作業や順序を見直すことです。必要な資料が得られなければ別の取得先を確かめる、入力が違っていれば先の作業へ戻る、といった変更が考えられます。元の目標や人の確認条件を、失敗したからという理由で勝手に削りません。目標そのものを変える必要があるなら、依頼した人と確かめます。
実行前に拒否された、実行して失敗した、結果が不明、は分けて扱います。結果が不明なら、完了とも未実行とも決めず、分かっている範囲と未確認を記録します。例えば申込みの結果が不明という条件なら、失敗したと仮定して同じ申込みを増やす前に、現在の状態を確かめたり人へ戻したりします。予定の文を言い直すだけでは、観察や再計画を行ったことにはなりません。
根拠：Anthropic: Building effective agents（別タブで開く） ↗ / OpenAI Docs: Guardrails and human review（別タブで開く） ↗ / OpenAI Docs: Function calling（別タブで開く） ↗
繰り返す範囲と、人へ戻る条件を決める
調査を続ける回数、必要な確認が得られない場合、許可範囲を超える場合など、止まる条件をあらかじめ決められます。例えば「状態確認は2回まで。分からなければ担当者へ」という条件なら、2回で不明だった結果を残して止まります。完了したように報告したり、目標が大切だからと上限を自分で延ばしたりしません。人へ戻すことも作業を管理する一部であり、自律的な次手の選択と併存できます。
根拠：Anthropic: Building effective agents（別タブで開く） ↗ / OpenAI Docs: Guardrails and human review（別タブで開く） ↗
図を拡大する ↗図の内容を文章で確認する
作業の要求に対して返った結果を観察して目標へ照合します。実行前の拒否は実行済みとしません。必要な条件が確かめられたら、その範囲で完了を記録します。不足や不明があれば、許可と打切り条件を先に確かめ、範囲内なら再計画し、条件に達したら不明を残して人へ戻します。回数などの条件は事前に定める運用条件で、製品上限の図ではありません。
- 読者ができること
- 観察結果から完了/再計画/人への戻しを選び、上限や許可を反復で解除しない。
- 図の項目
- 次の作業を要求する
- 図の項目
- 返った結果を観察：実行前拒否・成功・失敗・不明を区別
- 図の項目
- 必要な目標条件を確認できたか
- 図の項目
- 確認できた範囲で完了を記録
- 図の項目
- 許可不足か／打切り条件に達したか
- 図の項目
- 不明と実施内容を残す：人へ確認・停止
- 図の項目
- 目標と許可を保って再計画
- 矢印：次の作業を要求する → 返った結果を観察：実行前拒否・成功・失敗・不明を区別
- ホスト/道具から返った結果。実行前拒否も含む
- 矢印：返った結果を観察：実行前拒否・成功・失敗・不明を区別 → 必要な目標条件を確認できたか
- 目的に照合
- 矢印：必要な目標条件を確認できたか → 確認できた範囲で完了を記録
- 必要条件を確かめた
- 矢印：必要な目標条件を確認できたか → 許可不足か／打切り条件に達したか
- 不足/不明がある
- 矢印：許可不足か／打切り条件に達したか → 不明と実施内容を残す：人へ確認・停止
- 許可が足りない/打切り条件に達した
- 矢印：許可不足か／打切り条件に達したか → 目標と許可を保って再計画
- 許可範囲と条件内で続けられる
- 矢印：目標と許可を保って再計画 → 次の作業を要求する
- 次に確かめる作業へ戻る。元の条件は解除しない
- 重要な条件1
- 状態確認の回数など、事前の打切り条件に達したら人へ戻す。上限を自動で解除しない。
- 重要な条件2
- 結果不明を未実行/成功/0へ書き換えない。
- 重要な条件3
- 実行前拒否は道具実行済みとしない。
- 重要な条件4
- この図は与えられた構成例。AIの予定の文章だけから内部ループを認定しない。
模式図です。図の全項目・矢印・条件は下の文章版でも読めます。長い注記は拡大の見る位置で意味ごとに分け、左右へ動かして続けて読めます。
根拠：Anthropic: Building effective agents（別タブで開く） ↗ / OpenAI Docs: Function calling（別タブで開く） ↗ / OpenAI Docs: Guardrails and human review（別タブで開く） ↗
別の場面で確かめる
全て独自作成の問題です。公式問題や試験全体の難易度を再現したものではありません。