この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。OpenAI・Anthropicの現在のエージェント／ツール利用に関する公式ガイダンスを確認し、旧版の「CoTを全文表示し、Thought→Action→Observationの書式を必ず維持する」設計を、ツール実行・観測・再計画・停止条件を中心に見直しました。検証ステータス：📘 OpenAI・Anthropic公式情報確認済み／モデル横断ベンチマークは未実施
ReActやChain-of-Thought（CoT）は、LLMエージェントを説明するときによく出てくる言葉です。ただし、実務で大切なのは「Thoughtという文字列を出させること」ではなく、モデルが何を実行し、その結果をどう受け取り、次の行動をどう決めるかです。
現在のモデルはツール利用や長いタスクに対応する機能が増えており、古いテンプレートをそのまま固定すると、不要な長文、様式崩れ、ツールの過剰利用、同じ操作の反復が起きることがあります。エージェント側では、内部推論の全文をログにするより、外から検証できる状態を残す方が運用しやすくなります。
まず分ける：計画、実行、観測、再計画
| 段階 | アプリ側で持つもの | 確認ポイント |
|---|---|---|
| 計画 | 目的、成功条件、制約 | 何を終えれば完了か |
| 実行 | 選択したツール、引数 | 許可された操作か |
| 観測 | ツールの戻り値、エラー | 事実として使える結果か |
| 再計画 | 次の行動、停止判断 | 同じ失敗を繰り返していないか |
この4段階は、ReActの考え方と似ています。ただし、ユーザー向け出力に長い Thought を出す必要はありません。ログとして必要なのは、たとえば「どのツールを何の目的で呼び、何が返り、次に何をしたか」という監査可能な事実です。
ツール定義は「説明文」ではなく実行契約にする
ツールを使うエージェントでは、プロンプトだけでなくツールの名前、引数、型、説明が重要です。曖昧なツールが複数あると、モデルは選択を誤りやすくなります。
{
"name": "search_documents",
"description": "社内の承認済み文書を検索する。Web検索には使わない。",
"arguments": {
"query": "string",
"max_results": "integer"
}
}「何でも調べるツール」より、「何を対象にし、何には使わないか」が分かる定義の方が運用しやすくなります。
最初から全手順を固定しすぎない
旧版では、最初に全体計画を出力し、その計画どおりに Thought → Action → Observation を進める構造を強制していました。これは説明用には分かりやすい一方、実行途中で新しい情報が出たときに、古い計画へ固執する原因にもなります。
代わりに、次のように「次に必要な一手」を都度決められるようにします。
目的:
- 指定された質問に、確認可能な根拠付きで回答する
利用可能なツール:
- search_documents: 承認済み文書の検索
- calculator: 数値計算
ルール:
- 必要な場合だけツールを使う
- ツール結果にない事実を作らない
- 同じ失敗を2回繰り返したら別経路を検討する
- 成功条件を満たしたら停止する
- 最終回答には、使った根拠と未確認事項を短く示す停止条件を先に決める
エージェントでは「何をするか」だけでなく、「いつ止めるか」が重要です。停止条件がないと、検索を続けすぎたり、同じツールを呼び続けたりします。
- 必要な根拠がそろったら終了する
- 最大ツール呼び出し回数を超えたら終了する
- 同じエラーが続いたら人へ引き継ぐ
- 権限が必要な操作の前で承認を求める
- 結果が矛盾したら「未確定」として終了できるようにする
評価するのは「思考の美しさ」ではなく結果
エージェント評価では、長い推論ログがもっともらしいかより、外から確認できる指標を使います。
| 評価項目 | 例 |
|---|---|
| タスク完遂 | 成功条件を満たしたか |
| ツール選択 | 不要なツールを呼んでいないか |
| 引数精度 | 検索語や対象IDが正しいか |
| 根拠性 | 最終回答が観測結果に支えられているか |
| 効率 | 同じ操作の反復や無駄な呼び出しがないか |
| 安全性 | 権限外の操作を試していないか |
実務で残すログ
監査や障害解析では、内部推論全文ではなく次のようなイベントログが役立ちます。
{
"step": 3,
"tool": "search_documents",
"purpose": "契約更新条件の確認",
"result": "3 documents returned",
"status": "success",
"next": "compare clauses"
}これなら、後から「なぜそのツールを使ったのか」「何が返ったのか」「どこで止まったのか」を追えます。
まとめ
ReActやCoTは、エージェント設計を理解するための有用な考え方です。ただし、実装を Thought / Action / Observation の文字列出力に固定する必要はありません。
実務では、目的・成功条件・ツール契約・観測結果・再計画・停止条件を外部から確認できる形にし、ツール実行の正しさを評価する方が長期運用しやすくなります。
公式情報・一次情報
この記事の更新履歴
- 2026-09-13 追加：ツール契約、停止条件、監査可能なイベントログ、結果中心の評価指標を追加。
- 2026-09-13 変更：ReAct/CoTを固定書式として強制する構成から、計画・実行・観測・再計画を分離する構成へ変更。
- 2026-09-13 削除：内部メタ情報、本文H1、特定旧モデル前提、長いThoughtログの強制、MASAI固有と断定する未検証記述を削除。
