Skip to content

Latest commit

 

History

History
2023 lines (1463 loc) · 93.6 KB

File metadata and controls

2023 lines (1463 loc) · 93.6 KB

Claude Code 自然言語マクロプログラミングガイド

Claude Codeは、Anthropic社が開発したAIアシスタントClaudeを拡張したコーディング専用環境である(公式ドキュメント)。ファイル操作、Bash実行、Web検索などの強力なツール群を統合し、プログラミングから文書作成まで幅広いタスクを支援する。本ガイドはClaude Codeを単なるコーディングツールではなく、自然言語でプログラムできるエージェント実行環境として活用する手法とそのデザインパターンを提示する。

本ガイドで使用するマクロ構文は、CLAUDE.mdで定義された文法に基づいて動作する。ユーザーは自然言語でマクロを記述し、ClaudeがCLAUDE.mdの文法規則に従って実行する。実際の実行前に、CLAUDE.mdファイルをClaude Codeに読み込ませる必要がある。


Published: 2025-06-15
Last Updated: 2025-07-27
Author: Tadashi Wadayama (with assistance from Claude Code)
License: MIT License (2025)


🎯 目次

第1部:基本概念と理論的背景

第2部:10のデザインパターン

付録(高度な技術)- Appendix.md

免責事項

📚 主要コンテンツ

  • macro.md - メインガイド(10デザインパターン + 付録参照)
  • Appendix.md - 付録(高度なシステム統合とリスク管理)
  • examples/ - パターン別実例集
  • haiku_direct.md - 実例(俳句生成システム)
  • CLAUDE.md - マクロ定義ファイル
  • debugger.md - デバッグモード仕様書

第1部:基本概念と理論的背景

🤖 Core Concept: Claude Codeをインタープリタとしたエージェントプログラミング

本ガイドは、自然言語をマクロコードとし、LLMをインタープリタとして構造化されたタスクを実行する自然言語マクロプログラミングを提示する。本ガイドではClaude Codeを実行環境として使用する。

従来のプログラミングが特定の構文を持つプログラミング言語をコンピュータに解釈させるのに対し、自然言語マクロプログラミングでは:

  • 自然言語とマークダウン記法をプログラムとして記述
  • Claude Codeがそれを解釈・実行するインタープリタとして機能
  • Task tool、TODO tool、変数管理、条件分岐、並列実行等の高度な制御構造を自然言語で実現
  • エージェントシステムとして複雑なタスクを自動化・最適化

直感的な自然言語でエージェントの振る舞いを設計し、Claude Codeに実行させることが可能になる。

このドキュメントで示す自然言語マクロプログラミングとデザインパターンの大きな特徴は以下の3点に集約される。

  1. 可読性とアクセシビリティ: 自然言語で記述するため、非専門家でも理解・編集が可能。
  2. 構造化と再利用性: デザインパターンを用いて、複雑なタスクを体系的に構築できる。
  3. メタプログラミングへの高い適性: 「振る舞い」自体をデータとして扱い、操作できる。

自然言語マクロプログラミングは、メタプログラミングとしての側面も有する。自然言語マクロプログラミングでは、LISPに似た「コードとデータの等価性」を持つ。この特性は、特にメタプログラミング(プログラムを操作するプログラムを書くこと)を容易にする。マクロを動的に生成し、それを改めて自身に組み込み実行させる、といった高度なメタプログラミングが可能である。

🌍 フレームワークの汎用性と設計思想

この「自然言語マクロプログラミング」という概念と設計思想は、特定のLLMに縛られるものではない。一定の条件を満たす他の高性能なLLMにも十分に適用可能であると予想される。

このフレームワークの核心は、ツールや特定の製品ではなく、LLMを自然言語インタープリタとして構造化されたタスクを実行するというアプローチそのものにある。Claude Codeは、このアプローチを実現する優れた実行環境の一つとして位置づけられる。

適用可能な条件:

  • 複雑な自然言語指示の理解と実行能力
  • 変数管理と状態保持機能
  • 外部ツール・モジュールとの連携能力
  • マークダウン形式の構造化文書の解釈能力

🔗 既存プロンプト技術との相互補完関係

自然言語マクロプログラミングは、CoT(Chain of Thought)やReAct等の既存プロンプト技術と競合するものではなく、異なるレイヤーで動作する相互補完的な技術である。

技術レイヤーの違い

既存プロンプト技術(CoT、ReAct等):

  • 目的: 個別の推論プロセスの最適化
  • 範囲: 単一タスク内での思考過程改善
  • : 問題分析の精度向上、段階的推論の実現

自然言語マクロプログラミング:

  • 目的: システム全体の構築・制御・統合
  • 範囲: 複数タスクの協調、状態管理、フロー制御
  • : パイプライン設計、並列処理、エラーハンドリング

組み合わせの実践例

## CoT + Sequential Pipeline の組み合わせ
Step 1: CoTで複雑な問題を段階的に分析
Step 2: 分析結果を{{analysis_result}}に保存
Step 3: Sequential Pipelineで解決策を順次実行

## ReAct + Parallel Processing の組み合わせ
各並列タスクでReActによる情報収集を実行し、
結果をParallel Processingで統合処理

このように、既存技術の強みを活かしながら、システム全体の設計・制御に自然言語マクロプログラミングを活用することで、より高度で実用的なAIシステムの構築が可能になる。

🔍 高い説明可能性と責任あるAI開発への貢献

自然言語マクロプログラミングは、高い説明可能性(Explainability) を持つという、責任あるAI(Responsible AI)開発において極めて重要な特性を有している:

説明可能性の特徴:

  • 自然言語による記述: 処理ステップが人間に理解しやすい形で表現
  • 透明な実行過程: 各ステップの入力・出力・判断根拠が明確
  • 監査可能性: システムの動作を後から検証・追跡することが容易
  • デバッグ可能性: 問題発生時の原因特定と修正が直感的

責任あるAI開発への貢献:

  • 従来のブラックボックス的なAIシステムと比較して、意思決定過程の透明性が高い
  • AIシステムの動作に対する説明責任を果たしやすい
  • 人間による適切な監督と制御が可能
  • エラーや偏見の発見・修正が容易

⚠️ 確率的動作特性について

本ガイドで紹介する自然言語マクロプログラミング手法は、LLM(大規模言語モデル)の確率的動作特性に基づく:

  • 高確率動作: variables.jsonファイルを用いた変数管理({{variable_name}})、外部モジュール実行(filename.mdの実行)等は十分に優れたLLMの場合には非常に高い確率で期待通りに動作する。variables.json自動管理により変数値の永続化は保証されている
  • 完全確定性の非保証: 100%確定的な動作はLLMの性質上期待できない
  • 実用的信頼性: 実際の使用において十分な信頼性を持つレベルで動作する
  • 段階的機能低下: 理想的動作が困難な場合も、部分的な価値提供を継続する

特に失敗の可能性が高まるケース

このフレームワークを効果的に使用するには、LLMの確率的性質により予期しない動作を引き起こしやすい以下の状況を認識することが重要である:

複雑な制御構造: ループのネスト(二重、三重ループ)や、多段のif-then-else分岐が深くなると、LLMが現在のコンテキストや状態を見失い、意図しない振る舞いをする可能性が高まる。また、ループに含まれる内容が長く複雑になると、ループ実行を失敗する可能性が高くなる。

変数名の選択ミスと混同: variables.json自動管理により変数値の永続化は保証されているが、多数の類似変数名や動的生成変数において、適切な変数選択の判断ミスや変数名の混同が生じる可能性がある。明示的な変数命名規則と定期的な変数確認が推奨される。

自然言語固有の曖昧な指示: 「スコアが十分に高くなったら」や「結果が良ければ」といった定性的・曖昧な条件分岐は、LLMの解釈に揺らぎを生じさせ、実行のたびに挙動が変わる原因となる。可能な限り、「{{score}} > 90」のように定量的な指示を用いることが推奨される。

第2部:10のデザインパターン

📋 Claude Code自然言語マクロプログラミングの代表的な構文

- 条件分岐: 自然言語による条件指示(「...の場合は」「...に応じて」など)
- `{{variable_name}}`:変数参照
- 変数への保存:「...を{{variable_name}}に保存してください」
- ファイル保存:「{{variable_name}}をfilename.jsonに保存してください」
- ファイル読み込み:「filename.jsonを読み込んで{{variable_name}}に設定してください」
- 外部モジュール実行:「filename.mdの実行をしてください」
- ツール使用:自然言語で指示(例:「Webで調べて」「ファイルを読んで」、「TODOツールを使って」)

変数管理の特徴

自然言語による統一記法を採用し、JSONファイルベースの外部変数管理により確実な状態保持を実現している:

# 結果保存
データを分析し、結果を{{analysis_result}}に保存してください。
→ variables.jsonファイルに {"analysis_result": "分析結果"} として自動保存

# 結果参照  
{{analysis_result}}を基に報告書を作成してください。
→ variables.jsonから値を確実に取得して処理実行

自動実行のメカニズム: 上記の変数管理は、AIがCLAUDE.mdの仕様に従って自動的に実行する。具体的な動作は以下の通り:

  1. 変数保存時の自動処理:

    • {{variable_name}}に保存してくださいという指示を検出
    • AIがReadツールでvariables.jsonを読み込み(存在しない場合は{}として扱う)
    • JSONオブジェクトに新しい値を追加/更新
    • Writeツールで更新されたJSONをvariables.jsonに書き込み
    • 保存完了を報告
  2. 変数参照時の自動処理:

    • {{variable_name}}という記法を検出
    • AIがReadツールでvariables.jsonから該当する値を取得
    • 取得した値を後続の処理で使用

この一連の処理は、ユーザーが意識することなくAIによって完全に自動化されており、確実な変数管理を実現している。なお、より高度な変数管理が必要な場合は、A.15: SQLiteベース変数管理で説明されるデータベースベースの実装も利用可能である。

変数管理システムの特徴:

  • 確実性: LLMの推測による変数値の変動を排除
  • 透明性: variables.jsonで全変数の状態を常時確認可能
  • 継続性: セッション終了後も変数が保持される
  • デバッグ性: 変数の設定・参照履歴が追跡可能

制御構造

条件分岐は自然言語で柔軟に記述できる:

## データ処理
{{file_size}}が1MB以上の場合は詳細分析を、
それ以外の場合は基本分析を実行してください。

モジュール実行

外部モジュールファイルを呼び出すことで、モジュラー設計が可能である:

## データ処理パイプライン
data_collection.mdの実行をしてください。
data_analysis.mdの実行をしてください。
report_generation.mdの実行をしてください。

## 条件付きモジュール実行
{{data_type}}に応じて以下を実行:
- テキストデータの場合:text_analysis.mdの実行をしてください
- 数値データの場合:numerical_analysis.mdの実行をしてください

モジュール実行の利点

  • 再利用性: 共通処理を独立したモジュールとして管理
  • 保守性: 各モジュールを独立して開発・テスト可能
  • スケーラビリティ: 大規模システムの構築が現実的
  • 協働: チーム開発での責任分担が容易

📚 基本構文サンプル集

📝 変数管理について: 本ガイドの例文は、基本的な変数管理手法としてvariables.jsonファイルによる実装を前提として記述されている。より堅牢で高性能な変数管理については、A.15: SQLiteベース変数管理の実装例を参照されたい。

1. 順次実行:Python学習ガイド作成

## 基本情報収集
「Python入門」についてWebで調べ、初心者向けのポイント3つを{{basics}}に保存してください。

## 学習計画作成
{{basics}}を基に、1週間の学習スケジュールを{{schedule}}に保存してください。

## 最終ガイド作成
{{basics}}と{{schedule}}を組み合わせて「Python入門ガイド」を作成してください。

2. 並列実行:朝の準備分析

## 朝の準備ルーティン分析
**以下の3つのタスクをTask toolを利用して並列実行してください:**

### 身支度分析
朝の身支度(洗顔、歯磨き、着替えなど)の特徴と効率化のコツを分析し{{grooming}}に保存してください。

### 朝食準備分析  
朝食の準備(メニュー選択、調理、栄養バランスなど)の特徴とアイデアを分析し{{breakfast}}に保存してください。

### 出発準備分析
外出準備(持ち物確認、交通手段、時間管理など)の特徴と工夫を分析し{{departure}}に保存してください。

## 総合朝ルーティン提案
{{grooming}}、{{breakfast}}、{{departure}}を組み合わせて、効率的で充実した朝の過ごし方を提案してください。

3. 条件分岐:ファイル処理システム

## ファイル確認
README.mdファイルのサイズ(文字数)を確認し{{file_size}}に保存してください。

## 処理方式決定
{{file_size}}に応じて以下を実行:
- 100文字未満の場合:「簡潔なファイルです。全文を表示します」と出力し、全文を{{content}}に保存
- 100文字以上の場合:「詳細なファイルです。要約を作成します」と出力し、要約を{{content}}に保存

## 結果表示
{{content}}を使って適切な形式で結果を表示してください。

4. ファイル永続化:学習進捗管理

## 今日の学習記録
今日学習した内容を「Claude Code基本操作」として{{today_study}}に保存し、
{{today_study}}をstudy_log.jsonに保存してください。

## 進捗確認
study_log.jsonを読み込んで{{study_history}}に設定し、
学習継続日数と内容をまとめて表示してください。

5. 統合例:市場調査システム

## 調査準備
「AI市場動向」を調査テーマとして{{theme}}に保存してください。

## 並列情報収集
**以下の3つのタスクをTask toolを利用して並列実行してください:**

{{theme}}について以下を調査してください:

### 技術動向
最新のAI技術トレンドを{{tech_trends}}に保存してください。

### 市場規模
AI市場の規模と成長予測を{{market_size}}に保存してください。

### 企業動向
主要AI企業の戦略を{{company_strategies}}に保存してください。

## 条件付きレポート作成
{{tech_trends}}、{{market_size}}、{{company_strategies}}の完全性を確認し:
- 3つすべて収集できた場合:{{tech_trends}}、{{market_size}}、{{company_strategies}}を統合した包括的な市場分析レポートを作成
- 2つ以下の場合:利用可能な情報での基本レポートを作成し、不足部分を明記

## 結果保存
最終レポートをai_market_report.jsonに保存してください。

Pattern 1: Sequential Pipeline(順次パイプライン)

概要: データを段階的に処理する基本パターン。収集→処理→出力の線形フローで確実な結果を得る。

処理フロー: 入力 → 処理1 → 処理2 → 処理3 → 出力

適用判断:

  • ✅ 処理に明確な順序がある
  • ✅ 前段階の結果が次段階の入力になる
  • ✅ 各段階を独立してテスト・改善したい
  • ❌ 各処理が完全に独立している(→Parallel Processingを検討)

実用例:ブログ記事作成システム

## 完全初期化(クリーンスタート)

variables.jsonが存在すれば削除してください
TODOリストをすべてクリアしてください

「=== 順次パイプライン処理開始 ===」と表示してください。

## トピック調査
「リモートワークのメリット」についてWebで調べ、主要なポイント5つを{{research}}に保存してください。

## 構成作成
{{research}}を基に、読みやすいブログ記事の構成(見出し3-5個)を{{structure}}に保存してください。

## 記事執筆
{{structure}}に従って、1500文字程度のブログ記事を執筆し{{article}}に保存してください。

## 最終確認
{{article}}の文章を校正し、読みやすさと正確性を確認して最終版を作成してください。

🛡️ ロバストなSequential Pipeline(大規模タスク対応)

課題の認識: 各段階のタスクが大きく複雑な場合、以下の問題が発生する可能性がある:

  • 途中での処理失敗時の復旧困難
  • 長時間実行における進捗管理の欠如
  • セッション中断時の再開困難
  • 部分的完了状況の不透明性

解決アプローチ: TODOリストツールとの統合により、堅牢性と追跡可能性を向上させる

改良ポイント:

  • 段階的分解: 各メイン段階をサブタスクに細分化してTODO管理
  • 進捗可視化: 完了状況のリアルタイム確認
  • 状態永続化: セッション跨ぎでの継続実行対応
  • 失敗回復: 部分的失敗からの効率的復旧

実用例:大規模調査レポート作成システム

## Phase 1: 調査計画の策定
以下のサブタスクをTODOリストに追加してください:
1. 「調査テーマの詳細化と範囲設定」- 優先度: 高
2. 「主要情報源の特定とアクセス可能性確認」- 優先度: 高  
3. 「調査手法の決定と実行計画策定」- 優先度: 中
4. 「スケジュールとマイルストーンの設定」- 優先度: 中

各タスクを順次実行し、完了時にステータスを「completed」に更新してください。

## Phase 2: 文献調査の実行
前フェーズ完了後、以下をTODOリストに追加:
1. 「学術論文の検索と収集」- 優先度: 高
2. 「業界レポートの分析」- 優先度: 高
3. 「統計データの取得と整理」- 優先度: 中
...

## 進捗確認
各フェーズ完了時に全体の進捗状況を確認し、次フェーズへの移行判定を実行してください。

適用判断:

  • ✅ 総実行時間が30分以上の大規模タスク
  • ✅ 複数セッションに跨る可能性がある処理
  • ✅ 部分的失敗からの復旧が重要な業務
  • ✅ 進捗の可視化・追跡が必要なプロジェクト
  • ❌ 5分以内で完了する軽量タスク(→基本版を使用)

Pattern 2: Parallel Processing(並列処理)

概要: 独立したタスクを同時実行して効率化と多角的視点を実現する処理パターン。

処理フロー: 入力 → [タスクA, タスクB, タスクC] → 統合 → 出力

適用判断:

  • ✅ 各処理が互いに独立している
  • ✅ 同一データに対する異なる視点の分析が必要
  • ✅ 処理時間の短縮が重要
  • ❌ 処理に厳密な順序がある(→Sequential Pipelineを検討)

実用例:週末の過ごし方分析システム

## 完全初期化(クリーンスタート)

variables.jsonが存在すれば削除してください
TODOリストをすべてクリアしてください

「=== 並列処理システム開始 ===」と表示してください。

## 分析対象設定
「充実した週末」を分析対象として{{weekend}}に保存してください。

## 並列活動分析
**以下の3つのタスクをTask toolを利用して並列実行してください:**

{{weekend}}について以下の活動を分析してください:

### インドア活動分析
家で楽しめる活動(読書、映画、料理など)の特徴を分析し{{indoor}}に保存してください。

### アウトドア活動分析
外で楽しめる活動(散歩、スポーツ、旅行など)の特徴を分析し{{outdoor}}に保存してください。

### 社交活動分析
人との交流を楽しむ活動(友人との食事、イベント参加など)の特徴を分析し{{social}}に保存してください。

## 週末プラン提案レポート
{{indoor}}、{{outdoor}}、{{social}}を組み合わせて、バランスの取れた週末の過ごし方を提案してください。

🎌 実践例解説:俳句生成エージェントシステム

システム概要

俳句生成エージェントシステムは、Sequential PipelineParallel Processingを組み合わせた実用的な例である。創作プロセスをマクロ化することで、一貫した品質の俳句を効率的に生成する。

📁 実装ファイル

  • haiku_direct.md - 完全な実装コード
  • 学習目的: Sequential PipelineとParallel Processingの組み合わせ手法
  • 実行方法: ファイルを直接Claude Codeで実行

🏗️ システム構造分析

Phase 1: Sequential Pipeline(順次実行)

テーマ生成 → 俳句並列作成 → 俳句評価・選択 → 最終レポート

設計判断: 各段階が前段階の結果に依存するため、Sequential Pipelineを採用

Phase 2: Parallel Processing(並列実行)

俳句並列作成セクション内:
├── Task 1: 第1テーマ俳句 (並列)
├── Task 2: 第2テーマ俳句 (並列)  
├── Task 3: 第3テーマ俳句 (並列)
└── Task 4: 第4テーマ俳句 (並列)

設計判断: 各俳句の作成は独立しているため、Parallel Processingで効率化

🔄 データフロー設計

変数管理の活用

  1. テーマ共有: {{themes}} → 全ての並列タスクで共通利用
  2. 個別結果: {{haiku_1}}, {{haiku_2}}, {{haiku_3}}, {{haiku_4}} → 独立保存
  3. 評価統合: {{best_selection}} → 並列結果の統合評価
  4. 最終出力: 全変数を参照した包括的レポート

🔧 実用的な品質管理

  • 多様性確保: 4つの異なるテーマで多角的アプローチ
  • 客観評価: 明確な評価基準による選択プロセス
  • 包括記録: 全工程の結果を最終レポートで保存

🎯 実装の特徴

自然言語による直感的指示

# 技術的でない、自然な表現
「5-7-5の音律構造に従い、テーマの奇妙さと独特さを表現してください」
「最も奇妙で印象的な俳句を選択してください」

完全な自動化

  • 人間の介入なしで完結
  • 全プロセスが自動実行
  • 一貫した品質の保証

📈 応用可能性

このシステム構造は以下の分野への応用が考えられる:

  • 創作活動: 小説、詩、キャッチコピー生成
  • コンテンツ制作: 記事、プレゼン資料、企画書
  • 意思決定支援: 複数案の生成・評価・選択
  • 品質保証: 多角的検証による品質向上

🎓 学習効果

haiku_direct.mdを理解することで以下が期待される:

  1. 基本パターンの実践的組み合わせの習得
  2. 変数管理の効果的な設計手法の理解
  3. 実用的なシステム構築能力の獲得
  4. 自然言語マクロプログラミングの本質の体得

このファイルは、基本パターンから実用システムへの有用な架け橋となる学習教材である。


Pattern 3: Conditional Execution(条件分岐)

概要: 状況に応じて異なる処理パスを動的に選択。データ特性やユーザー状況による最適な処理を実現し、柔軟で実用的なシステムを構築。

処理フロー: 入力 → 条件判定 → [処理A | 処理B | 処理C] → 出力

適用判断:

  • ✅ データや状況によって処理を変える必要がある
  • ✅ エラーハンドリングや例外処理が重要
  • ✅ ユーザー権限や設定による機能制御が必要
  • ❌ 常に同じ処理で十分(→Sequential Pipelineを検討)
  • ❌ 複雑な問題分割が必要(→Problem Solving & Recursionを検討)

実用例:ファイル処理の自動振り分けシステム

## 完全初期化(クリーンスタート)

variables.jsonが存在すれば削除してください
TODOリストをすべてクリアしてください

「=== 条件分岐システム開始 ===」と表示してください。

## ファイル情報の取得
処理対象のファイルを指定し、以下の情報を取得:
- ファイル形式を{{file_type}}に保存
- ファイルサイズを{{file_size}}に保存
- ファイル内容の行数を{{line_count}}に保存

## ファイル形式による処理分岐
{{file_type}}に応じて処理を分岐:

CSV形式の場合:
→ データ分析処理を実行し、結果を{{analysis_result}}に保存

JSON形式の場合:
→ 構造解析処理を実行し、結果を{{structure_result}}に保存

テキスト形式の場合:
→ 自然言語処理を実行し、結果を{{nlp_result}}に保存

その他の形式の場合:
→ 基本情報のみ抽出し、{{basic_info}}に保存

## ファイルサイズによる処理方法選択
{{file_size}}に応じて処理方法を調整:

10MB以上の場合:
→ 「大容量ファイルのため分割処理を実行します」
→ チャンク分割処理を{{chunk_processing}}で実行

1MB未満の場合:
→ 「小容量ファイルのため一括処理を実行します」
→ 一括処理を{{batch_processing}}で実行

## 結果の統合と出力
処理結果を{{final_result}}に統合し、
処理方法と実行時間を{{processing_log}}に記録

🔤 曖昧性許容処理(Ambiguity Tolerance)

概要: 自然言語処理ならではの特性を活用し、不明確な要求でも推測ベースで価値を提供する設計原則。従来のプログラミングでは「エラー」として処理される曖昧性を、システムの柔軟性として活用するアプローチ。

4段階曖昧性対応戦略: 明確 → 部分推測 → 高度推測 → 解釈不能

  1. 推測ベース継続: エラー終了ではなく推測による処理継続
  2. 確信度明示: 推測レベルと不確実性をユーザーに透明化
  3. 段階的詳細化: より明確な要求への改善ガイダンス提供
  4. 価値提供継続: 最悪条件でも基本的フレームワークを提供

実用例:曖昧要求の段階的処理

## 曖昧要求の解釈
{{user_request}}の曖昧性レベルを判定し、以下を実行:

明確な要求の場合:
→ 確定的に処理を実行し{{definitive_result}}に保存

部分的曖昧性の場合:
→ 「文脈から推測して処理します」として実行し{{inferred_result}}に保存
→ 「部分的推測を含みます」を{{uncertainty_note}}に記録

高度な曖昧性の場合:
→ 「最も可能性の高い解釈として処理します」として実行し{{speculative_result}}に保存
→ 「高度な推測による解釈です」を{{speculation_note}}に記録

解釈不能の場合:
→ 一般的なフレームワークを提供し{{fallback_framework}}に保存
→ 「具体的な要求の再入力を推奨します」を{{clarification_request}}に記録

🆚 従来プログラミングとの差別化

従来のシステム設計

曖昧入力 → エラー → 処理停止 → ユーザー離脱

曖昧性許容システム

曖昧入力 → 推測処理 → 有用結果 + 不確実性明示 → 段階的改善

自然言語マクロプログラミングの独自価値

  • バイナリ判定からスペクトラムへ: 成功/失敗ではなく確信度の段階的評価
  • 完璧性から実用性へ: 完全理解より部分的でも有用な価値提供
  • エラーから機会へ: 曖昧性を柔軟性として活用する設計思想

この曖昧性許容処理により、人間-AI間の自然な対話における曖昧性への対応が改善され、より実用的なシステムの構築が可能となる。不確実な情報に基づく状況下においてエージェントが「完全停止」ではなく「推測継続」による処理を行うためのアプローチとなる。


📁 実践サンプル集

基本3パターンの詳細な実践例を以下で学習できる:

🔄 Sequential Pipeline(順次パイプライン)

⚡ Parallel Processing(並列処理)

🎌 Conditional Execution(条件分岐)


Pattern 4: Loop & Modular Programming(繰り返し・モジュール)

概要: TODOリストを活用して確実で可視性の高い反復処理を実現する新しいパターン。従来のカウンター制御方式を排除し、TODOタスクの管理により安定したループ動作を実現。実験において高い安定性を確認。

処理フロー: 初期化 → TODOタスク作成 → 順次実行 → [条件チェック → 残タスク削除] → 完了

適用判断:

  • ✅ 確実な反復処理が必要
  • ✅ 実行状態の可視性を重視する場合
  • ✅ 条件付きループ終了が必要
  • ✅ デバッグ可能なループ処理を実装したい
  • ✅ カウンター管理の複雑さを避けたい
  • ❌ 非常に単純な1回だけの処理(→基本的な処理で十分)
  • ❌ ループ処理が不安定で確実性が求められる場合(→A.14: Pythonオーケストレーション型ハイブリッドアプローチを検討)

TODOリストベースの価値:

  • 確実性: カウンター管理不要による高い安定性
  • 可視性: TODOリストによる実行状態の完全な透明性
  • 制御性: 動的なタスク削除による柔軟な終了制御
  • デバッグ性: 各タスクの実行状況が明確に把握可能

🧹 クリーンスタート機能

全てのループ処理において、確実な初期化のためクリーンスタートを実行します:

## 完全初期化
variables.jsonが存在すれば削除してください
TODOリストをすべてクリアしてください

重要性:

  • 純粋な実験環境: 前回の実行結果が残らない
  • 予測可能な動作: 毎回同じ初期状態から開始
  • デバッグの容易さ: 問題の原因を特定しやすい

🔢 基本例:固定回数ループ

TODOリストベースの最も基本的な固定回数ループの実装:

# 固定回数TODOリストベースループ

## 完全初期化
variables.jsonが存在すれば削除してください
TODOリストをすべてクリアしてください

## 変数初期化
{{counter}}を0に設定してください

## ループタスクの作成
以下のタスクを5回TODOリストに追加してください:
- カウンターを1増やして表示する

## 実行
TODOリストのタスクを上から順次実行してください

技術的特徴:

  • カウンター管理不要: TODOリスト自体が実行回数を管理
  • 確実な実行: 5つのタスクが確実に実行される
  • 状態の透明性: 各タスクの完了状況が可視化

🎯 応用例:条件付きループ

スコア到達まで処理を継続し、条件達成時に自動終了する条件付きループ:

# 条件付きTODOリストベースループ

## 完全初期化
variables.jsonが存在すれば削除してください
TODOリストをすべてクリアしてください

## 変数初期化
{{score}}を50に設定してください

## ループタスクの作成
以下のタスクのペアを5セット、TODOリストに追加してください:
- スコアに10を加算する
- {{score}}が80以上の場合、残りのタスクを削除して終了する

## 実行
TODOリストのタスクを上から順次実行してください

動作例:

  1. スコア: 50 → 60(継続)
  2. スコア: 60 → 70(継続)
  3. スコア: 70 → 80(条件達成)
  4. 残りタスクを削除して終了

🔄 ループパターンの種類

1. 固定回数ループ

以下のタスクをN回TODOリストに追加して実行してください:
- [実行したい処理]
  • 適用場面: 決まった回数の処理が必要
  • 特徴: シンプルで確実

2. 条件付きループ

以下のタスクのペアを最大N回TODOリストに追加して実行してください:
- [実行したい処理]
- {{変数}}が[条件]の場合、残りのタスクを削除して終了する
  • 適用場面: 目標達成まで処理を継続
  • 特徴: 動的終了制御、効率的実行

3. 複合条件ループ

以下のタスクのセットを最大N回TODOリストに追加して実行してください:
- [メイン処理]
- [サブ処理]
- {{条件A}} OR {{条件B}}の場合、残りのタスクを削除して終了する
  • 適用場面: 複数の終了条件がある複雑な処理
  • 特徴: 柔軟な制御、高度な条件判定

4. カウンターベースループ

{{counter}}を0に設定してください
{{counter}}に1を加算してください
{{counter}}が[上限]に達した場合、処理を終了してください
  • 適用場面: 進捗管理・リソース制限が重要な処理
  • 特徴: 明確な進捗表示、安全制限による無限ループ防止
  • 実践例: presentation_optimizer.md ({{iteration}}/{{max_iterations}}), prompt_improvement_learning.md ({{improvement_count}})

5. Few-shotパターンループ

具体例:
- 1番目の要素を{{item_1}}に保存してください
- 2番目の要素を{{item_2}}に保存してください

一般化:3番目以降は{{item_N}}形式(Nは番号3,4,5...)で{{total_count}}個まで続けてください
  • 適用場面: パターンが明確な繰り返し処理、動的変数名生成、配列的データ処理
  • 特徴: AIの推論能力活用、TODOリスト作成不要、自然言語的記述、直感的理解
  • 実践例: A.5俳句生成マルチエージェントシステムでのテーマ配布・エージェント起動

Few-shotパターンの実用例(俳句生成システムから):

## テーマ配布
具体例:
- 1番目のテーマを{{agent_1_theme}}に保存してください
- 2番目のテーマを{{agent_2_theme}}に保存してください

一般化:3番目以降は{{agent_N_theme}}形式(Nは番号3,4,5...)で{{agent_count}}個まで続けてください

## エージェント並列実行
具体例:
### Task 1: エージェント1実行
### Task 2: エージェント2実行

一般化:Task 3以降も同様のパターンで{{agent_count}}個まで並列実行してください

技術的優位性:

  • 学習効果: 具体例から一般パターンを推論するAIの能力を最大活用
  • 簡潔性: TODOリスト作成や明示的カウンター管理が不要
  • 柔軟性: 複雑なインデックス操作や条件分岐も自然に記述可能
  • 安定性: 実際のA.5実装で安定動作が確認済み

🔄 ループ手法の比較分析

特徴 TODOリストベース カウンターベース Few-shotパターン
実装の簡素性 ◎ カウンター管理不要 △ カウンター変数管理が必要 ◎ 管理構造完全不要
進捗の可視性 ◎ TODOリスト状態で完全可視 ◎ 数値による明確な進捗表示 △ パターン推論による間接的把握
安全性 ◎ 動的タスク削除で確実終了 ◎ 上限設定で無限ループ防止 ◎ 有限パターンで自然終了
リソース管理 △ 間接的な制御 ◎ 直接的な回数・コスト制限 ○ パターン範囲による制限
デバッグ容易性 ◎ 全状態がTODOリストで確認可能 ○ カウンター値で状態把握 ○ パターン実行で状態推定
学習効果 ○ TODOリスト理解が必要 ○ カウンター概念理解が必要 ◎ 自然言語的直感で即理解
適用場面 目標達成型、品質向上型 進捗管理型、リソース制限型 パターン型、動的変数名型

推奨使い分け

  • TODOリストベース: 条件達成まで継続する処理(品質向上、学習進捗)
  • カウンターベース: 明確な回数制限がある処理(評価回数、改善サイクル)
  • Few-shotパターン: 明確なパターンがある繰り返し処理(配列操作、動的変数生成、並列エージェント起動)

⚠️ ループ処理の安定性について

自然言語マクロによるループ処理は高い柔軟性を持つ一方、LLMの確率的動作により稀に予期しない動作が発生する可能性があります。確実性が最優先される重要なシステムでは、以下の代替手法を検討してください:

A.14: Pythonオーケストレーション型ハイブリッドアプローチ

  • Python側で確実なループ制御を実行
  • 自然言語マクロは各反復内の柔軟な判断処理に特化
  • 両技術の長所を組み合わせた最適解を提供

📁 実践サンプル

TODOリストベースLoop Processing の詳細な実践例:


Pattern 5: Problem Solving & Recursion(動的問題解決・再帰的分割)

概要: 複雑な問題をTODOツールを活用して再帰的に分割し、段階的に解決する高度なパターン。大きな問題を理解可能な単位まで分解し、確実な進歩を積み重ねて最終的な統合解決を実現。

処理フロー: 問題分析 → 分解判定 → [再帰分割 | 具体実行] → 統合解決

適用判断:

  • ✅ 複雑で多段階の問題解決が必要
  • ✅ 問題を段階的に分割できる構造
  • ✅ 確実な進捗管理と状態保持が重要
  • ✅ 中断・再開可能な長期タスク
  • ❌ 単純で分割不要な処理(→Sequential Pipelineを検討)

再帰的思考の価値:

  • 分解: 大きな問題を理解可能な単位に分割
  • 判定: 各タスクの分解可能性を適切に評価
  • 実行: 分解不可能なタスクの具体的完了
  • 統合: 分散した成果の体系的な結合

TODOリストによる安全な再帰計算

技術的可能性: TODOリストシステムの状態管理機能により、従来困難だった再帰計算を比較的安全に実現できる可能性がある。

主要な利点:

  • スタック管理: TODOリストが再帰呼び出しスタックの役割を果たし、深度制御が可能
  • 状態保持: variables.jsonによる中間状態の永続化で、中断・再開に対応
  • ループ代替: 複雑なネストしたループ処理を再帰的分割で置き換え、理解しやすい構造に変換

応用例: 階層的データ処理、木構造の探索、動的プログラミング的な問題分割など、従来のプログラミングで再帰的アプローチが有効な領域での活用が期待される。

🎯 段階的習得の3ステップ

ステップ1: TODOツール基本操作

## 完全初期化(クリーンスタート)

variables.jsonが存在すれば削除してください
TODOリストをすべてクリアしてください

「=== 問題解決システム開始 ===」と表示してください。

## TODOリスト基本操作体験

簡単なタスク「買い物リスト作成」でTODOツールの基本操作を習得:

現在のTODOリストを確認してください。

以下のタスクをTODOリストに追加してください:
1. 「食材確認」- 優先度: 高
2. 「買い物リスト作成」- 優先度: 高  
3. 「買い物実行」- 優先度: 中

各タスクを順次実行し、完了時にステータスを「completed」に更新してください。

最終的にすべてのタスクが完了したことを確認してください。

ステップ2: 基本的な問題分割

## 完全初期化(クリーンスタート)

variables.jsonが存在すれば削除してください
TODOリストをすべてクリアしてください

「=== 問題分割システム開始 ===」と表示してください。

## 単純な問題分割システム

メインタスク「週末の掃除計画」を分割してTODOリストで管理:

メインタスクを以下のサブタスクに分割してTODOリストに追加:
1. 「リビング掃除」- 優先度: 高
2. 「キッチン掃除」- 優先度: 高
3. 「バスルーム掃除」- 優先度: 中
4. 「ゴミ出し」- 優先度: 低

各サブタスクについて:
- 具体的な作業内容を決定
- 作業完了後、ステータスをcompletedに更新
- 全完了後、掃除計画全体の成果をまとめて報告

ステップ3: 再帰的問題解決

## 完全初期化(クリーンスタート)

variables.jsonが存在すれば削除してください
TODOリストをすべてクリアしてください

「=== 再帰的問題解決システム開始 ===」と表示してください。

## 高度な再帰分割システム

メインタスク「料理レシピ作成」による再帰実装:

## フェーズ1: 初期問題分割
メインタスクを主要サブタスクに分解してTODOリストに追加

## フェーズ2: 再帰的分解判定
各pendingタスクについて:
- 分解可能性を判断
- 分解可能→詳細サブタスクを作成してTODO追加
- 分解不要→具体的作業を実行してcompleted

## フェーズ3: 継続的処理
pendingタスクが残る限り、フェーズ2を繰り返し実行

## フェーズ4: 最終統合
全タスク完了後、結果を統合して完全なレシピとして提示

📁 実践サンプル

Problem Solving & Recursion の詳細な実践例:


Pattern 6: Learning from Experience(経験学習・知識蓄積・記憶管理)

概要: エージェントが実行した処理の結果を永続化ファイルに保存し、蓄積された経験から学習して意思決定の質を向上させる高度なパターン。単純な経験記録から、類似性判定による知見検索、失敗パターン認識まで段階的に構築。

このパターンは、A.13: ゴール指向アーキテクチャと自律的プランニングにおける自律型エージェントの学習機能として重要な役割を果たします。自律的プランニングシステムでは、過去の計画立案・実行経験を蓄積し、将来のゴール設定や計画評価の精度向上に活用できます。

処理フロー: 経験記録 → 知見蓄積 → 経験検索 → 知見活用

適用判断:

  • ✅ 過去の経験を活用して判断精度を向上させたい
  • ✅ 継続的な学習・改善プロセスを実装したい
  • ✅ 類似状況での知見を効率的に利用したい
  • ✅ 失敗パターンの予測・回避システムを構築したい
  • ❌ 単発処理で記憶が不要(→基本パターンを検討)

経験学習の価値:

  • 記憶: 過去の成功・失敗事例の永続化
  • 学習: 経験からパターンを抽出し知見化
  • 検索: 類似状況での関連経験の効率的発見
  • 活用: 蓄積された知識に基づく改善された意思決定

🍳 基本例:料理経験の蓄積学習システム

まず、Learning from Experienceの最も基本的な概念として、経験の記録→蓄積→活用サイクルを実践します:

## 初期料理実験
今日の夕食として「チャーハン」を作ってみる。

使用材料: 米2合、卵2個、ネギ、醤油、塩
調理時間: 20分
評価: 味が薄い、べたつき気味(5/10点)

## 経験の記録
以下の料理経験をlearning_memory.jsonファイルに保存してください:

{
  "cooking_experiences": [
    {
      "date": "今日",
      "dish": "チャーハン",
      "ingredients": ["米2合", "卵2個", "ネギ", "醤油", "塩"],
      "cooking_time": 20,
      "score": 5,
      "problems": ["味が薄い", "べたつき気味"],
      "lessons": "調味料の量要調整、火力強化必要"
    }
  ]
}

## 改善実践
learning_memory.jsonを読み込んで{{past_experience}}に設定してください。

{{past_experience}}の教訓を活用して改善版チャーハンを作ります:

改善材料: 米2合、卵2個、ネギ、醤油(多め)、塩、鶏ガラスープ、ごま油
調理時間: 18分
評価: 味が濃厚、パラパラ食感(8/10点)

この改善結果も{{past_experience}}に追加してlearning_memory.jsonに保存してください。

## 学習完了とクリーンアップ
「料理学習サイクル完了!」と表示してください。

次回実行時のために、learning_memory.jsonファイルを削除してください。

🔄 継続学習:Loop Pattern + Learning from Experience

数当てゲーム学習システムでは、過去の推定履歴を活用して段階的に効率的な探索戦略を習得します:

## ゲーム初期設定
1から100までの数からランダムに秘密の数を選択し{{secret_number}}に設定してください。
(動作確認のため、秘密の数を表示してください)

game_history.jsonを読み込んで{{game_history}}に設定してください。
推定回数を0として{{attempt_count}}に設定してください。

## 学習推定ループ
{{attempt_count}}が10回に達するか正解するまで以下を繰り返してください:

{{attempt_count}}に1を加算してください。

「=== 推定回数 {{attempt_count}} ===」と表示してください。

## 過去履歴に基づく推定値決定
{{game_history}}を参照して次の推定値を決定してください。

初回の場合:
→ 1から100の間で推定値を選択してください

2回目以降の場合:
→ {{game_history}}の内容を確認し、あなたなりの方法で次の推定値を決定してください

推定値を{{current_guess}}に設定し、「推定値: {{current_guess}}」と表示してください。

## フィードバック判定
{{current_guess}}と{{secret_number}}の差を計算し、以下の段階的フィードバックを提供してください:

差が20以上の場合:
→ {{current_guess}} < {{secret_number}}: 「{{current_guess}}はだいぶ小さいです」
→ {{current_guess}} > {{secret_number}}: 「{{current_guess}}はだいぶ大きいです」

差が5-19の場合:
→ {{current_guess}} < {{secret_number}}: 「{{current_guess}}は少し小さいです」
→ {{current_guess}} > {{secret_number}}: 「{{current_guess}}は少し大きいです」

差が1-4の場合:
→ 「{{current_guess}}はとても近いです!」

差が0の場合:
→ 「正解!{{current_guess}}が秘密の数です!」と表示してループ終了

## 履歴更新
推定結果を{{game_history}}に追加し、game_history.jsonに保存してください:
- 推定回数
- 推定値
- フィードバック結果
- あなたが気づいたこと(任意)

## 最終学習成果
ゲーム完了後、{{game_history}}から学習プロセスを振り返ってください:
「数当て学習完了!{{attempt_count}}回で正解到達」
「あなたが発見した学習効果や戦略について自由に分析してください」

## 学習完了とクリーンアップ
次回実行時のために、game_history.jsonファイルを削除してください。

📁 実践サンプル

Learning from Experience の詳細な実践例:

関連する高度な技術


Pattern 7: Environment sensing, Knowledge-base and Environment model(環境センシング・知識ベース・環境モデル)

概要: エージェントが環境を理解し、状況に応じた最適な判断を行うための知識体系とモデル構築手法。基本パターンの実行能力に「環境理解」と「状況判断」の知的能力を追加し、より実用的で適応的なエージェントシステムを実現。

このパターンは、A.12: ベクトルデータベースとRAG活用と密接に関連しています。特に大規模な知識ベースの構築・検索において、ベクトル検索とRAGシステムの活用により、環境情報と知識の効率的な照合・活用が可能になります。

処理フロー: 環境センシング → 知識照合 → 状況推定 → 経験統合 → 行動判断

📚 エージェントの環境理解システム

基本概念: エージェントシステムは自身が動作する「環境」に関する知識を体系的に保持・活用する必要がある

環境知識の3層構造:

環境に関する知識 = LLMの持つ常識 + ナレッジベース + 環境モデル

情報統合による判断プロセス:

センシング情報 + ナレッジベース + 環境モデル + 経験学習 → 行動判断

🔍 環境センシング(Environment Sensing)

定義: エージェントが実世界・デジタル環境から情報を取得し、現在の状況を把握する基本機能

適用判断:

  • ✅ 時刻・日付等の時間的情報が必要
  • ✅ ファイル・データベースの現在状態を確認したい
  • ✅ 外部システム・Web情報を取得したい
  • ❌ 静的な情報のみで十分(→ナレッジベースで対応)

センシング手法の体系:

時間的情報の取得

## 現在時刻の取得
dateコマンドを実行して現在の日時を確認し、{{current_time}}に保存してください。

## 曜日別処理
{{current_time}}から曜日を判定し、以下を実行:
- 平日の場合:業務モードの処理を実行
- 週末の場合:メンテナンスモードの処理を実行

ファイル・データ状態の取得

## ファイル状態確認
project_status.jsonを読み込んで{{project_state}}に設定してください。

## データ整合性チェック
{{project_state}}の内容を分析し:
- 必須項目の完全性確認
- データ更新日時の検証
- 異常値・欠損値の検出

外部情報の取得

## Web情報収集
「最新の技術動向」についてWebで調べ、重要なポイント3つを{{tech_trends}}に保存してください。

## 情報の信頼性評価
{{tech_trends}}について:
- 情報源の信頼性評価
- 情報の新しさ確認
- 複数ソースでの裏付け取得

実用例:週間タスク管理エージェント

エージェントプログラミングの核心概念「環境センシング→判断→行動」を実装する例:

## 環境センシング:現在の曜日取得
dateコマンドを実行して現在の曜日を確認し、{{current_day}}に保存してください。

## 曜日別タスク実行
{{current_day}}に応じて以下を実行し、結果を{{daily_result}}に保存してください:

月曜日の場合:
→ 週始めプランニング(1週間の目標設定)を実行

火曜日〜木曜日の場合:
→ 集中作業モード(重要タスクの進捗確認)を実行

金曜日の場合:
→ 週末準備モード(週の振り返りと次週準備)を実行

土曜日・日曜日の場合:
→ リフレッシュモード(休息とリチャージ活動)を実行

## エージェント動作報告
{{current_day}}と{{daily_result}}を組み合わせて、今日のエージェント動作報告書を作成してください。

センシングの要素:

  • 実世界情報: dateコマンドによる時刻・曜日の取得
  • デジタル情報: ファイル・データベースの状態確認
  • 外部情報: Web検索・API呼び出しによる最新情報取得
  • 状態変化: 前回実行時からの変化・差分の検出

📖 ナレッジベース(Knowledge Base)

定義: 環境に関する固有知識をテキストやJSON形式で構造化したもの

適用判断:

  • ✅ 業務固有のルール・手順が存在する
  • ✅ FAQ・マニュアル等の明文化された知識がある
  • ✅ 専門分野の知識体系が必要
  • ❌ 一般常識のみで対応可能(→LLMの基本知識で十分)

実装形式:

テキスト形式ナレッジベース

## 顧客サポート知識ベース(customer_kb.md)
### 返品ポリシー
- 購入から30日以内
- 未開封・未使用品のみ
- レシート必須

### よくある質問
Q: 配送にかかる日数は?
A: 通常3-5営業日、お急ぎ便は翌日配送

### エスカレーション基準
- 返金要求 → マネージャー承認必要
- 技術的問題 → 技術サポートチーム転送

JSON形式ナレッジベース

{
  "business_rules": {
    "discount_policy": {
      "vip_customer": 0.15,
      "regular_customer": 0.05,
      "minimum_order": 5000
    },
    "support_hours": {
      "weekday": "9:00-18:00",
      "weekend": "10:00-16:00"
    }
  },
  "contact_info": {
    "technical_support": "tech@company.com",
    "billing": "billing@company.com"
  }
}

RAGシステム連携とベクトル検索

A.12: ベクトルデータベースとRAG活用で詳述される技術を活用することで、大規模な知識ベースからの動的検索・活用が可能。Claude Code環境では、外部ベクトルDBやRAGサービスとの連携により、文書検索→要約→判断のパイプラインを構築可能。特に大量の技術文書、法規制、過去事例等を活用する業務エージェントに有効。

活用例:ナレッジベース参照システム

## 顧客問い合わせ対応
customer_kb.mdを読み込んで{{knowledge_base}}に設定してください。

## 問い合わせ内容分析
顧客からの問い合わせ「配送が遅れているようですが、どうなっていますか?」を{{inquiry}}に設定してください。

## 知識照合・回答生成
{{knowledge_base}}を参照して{{inquiry}}に最適な回答を生成し、{{response}}に保存してください。

## 対応履歴記録
{{inquiry}}と{{response}}をsupport_log.jsonに記録してください。

🌍 環境モデル(Environment Model)

定義: 環境を「状態を持つシステム」として捉え、その状態推定・予測を行うデジタルツイン

適用判断:

  • ✅ 環境の状態変化を追跡する必要がある
  • ✅ 複数要素の相互作用を理解したい
  • ✅ 将来状態の予測が重要
  • ❌ 静的な情報参照のみ(→ナレッジベースで十分)

状態表現の設計:

基本的な状態管理

{
  "system_state": {
    "timestamp": "2025-06-20T10:30:00Z",
    "inventory": {
      "product_a": 150,
      "product_b": 75,
      "product_c": 0
    },
    "active_orders": 12,
    "staff_status": {
      "available": 5,
      "busy": 3,
      "offline": 2
    }
  }
}

活用例:在庫管理エージェント

## 現在状況の取得
inventory_status.jsonを読み込んで{{current_state}}に設定してください。

## 新規注文の処理
新規注文「商品A × 20個」を{{new_order}}に設定してください。

## 状態更新の実行
{{current_state}}と{{new_order}}を基に:
- 在庫数量の更新
- 在庫不足の警告判定
- 自動発注の必要性判断

更新された状態を{{updated_state}}に保存し、inventory_status.jsonに保存してください。

## 予測・アラート機能
{{updated_state}}を分析し、今後24時間で在庫切れが予想される商品を{{alerts}}に抽出してください。

🔄 統合的判断システム

4つの情報源を統合した高度な判断システム: 環境センシング + ナレッジベース + 環境モデル + 経験学習

実用例:会議アシスタントエージェント

## 環境情報の収集
dateコマンドで現在時刻を確認し{{current_time}}に設定してください。
meeting_schedule.jsonを読み込んで{{schedule}}に設定してください。
participant_profiles.jsonを読み込んで{{participants}}に設定してください。

## 状況判断の実行
{{current_time}}、{{schedule}}、{{participants}}を統合して:

会議開始15分前の場合:
→ 参加者への事前リマインダー送信
→ 資料準備状況の確認
→ 会議室設備の動作確認

会議中の場合:
→ 議事録の自動記録開始
→ 参加者の発言時間管理
→ アクションアイテムの抽出

会議終了後の場合:
→ 議事録の整理・配布
→ アクションアイテムのフォローアップ設定
→ 次回会議のスケジュール提案

結果を{{meeting_action}}に保存してください。

## 経験学習の統合
past_meetings.jsonから類似会議の成功パターンを{{lessons}}に読み込み、
{{meeting_action}}の改善に活用してください。

更新された知見をpast_meetings.jsonに追記してください。

🎯 Knowledge base と Environment model の連携

相補的な活用:

  • ナレッジベース: 不変のルール・知識(「どうすべきか」)
  • 環境モデル: 動的な状態・予測(「現在どうなっているか」)
  • 統合判断: 両者を組み合わせた最適な行動決定

Pattern統合の活用:

  • Sequential Pipeline: 知識照合→状況判断→行動実行の順次処理
  • Conditional Execution: 状態に応じた条件分岐処理
  • Learning from Experience: 判断結果からの知識・モデル更新
  • Parallel Processing: 複数知識源の並列参照・統合

📁 実践サンプル

Environment sensing, Knowledge-base and Environment model の詳細な実践例:

関連する高度な技術


Pattern 8: Human-in-the-Loop(HITL)- 人間協調型エージェント設計

概要: エージェントの自動処理に人間の判断・創造性・監督を戦略的に組み込み、効率性を保ちながら安全で責任あるシステムを構築する高度なパターン。適切な介入ポイント設計により、完全自動化の限界を克服し、人間とAIの相補的協調を実現。

このパターンは、A.2: 4層の防御戦略のレイヤー1「設計段階での予防的対策」の中核技術として位置づけられます。Human-in-the-Loopの戦略的配置により、確率的システムの不確定性に対する防御機能を提供し、安全で責任あるシステム運用を実現します。

処理フロー: 自動処理 → 介入判定 → [人間介入 | 継続実行] → 結果統合 → 記録保持

適用判断:

  • ✅ 創造的判断や戦略的方向性が重要
  • ✅ 高リスクな決定や責任の明確化が必要
  • ✅ 安全性確保やミスコンダクト防止が重要
  • ✅ 品質基準や最終承認が必要
  • ❌ 定型的で低リスクな処理(→完全自動化を検討)
  • ❌ 高頻度で介入コストが効果を上回る場合

HITLの4つの価値:

  • 創造性導入: 人間の直感・発想をエージェント処理に組み込み
  • 方向性調整: 戦略的判断や優先順位の人間による修正
  • 安全性確保: 想定外のミスコンダクトや有害出力の防止
  • 責任明確化: 重要決定における人間の承認と責任の記録

これらの価値は、A.2: 4層の防御戦略における多層防御アプローチの基盤となり、単一の防御手法に依存しない堅牢なシステム設計を可能にします。

🎯 効率的介入設計の原則

介入ポイント最適化の考え方:

介入効果 = (判断品質向上 + リスク軽減) - (時間コスト + 複雑性コスト)

戦略的介入ポイント:

  1. 構想・計画段階: 全体方向性や戦略の確認
  2. 重要分岐点: 複数選択肢からの意思決定
  3. 品質確認段階: 成果物の妥当性や安全性検証
  4. 最終承認段階: 責任を伴う決定の確認

効率性を保つバランス設計:

  • 階層的介入: 重要度に応じた介入密度の調整
  • 条件的介入: 特定条件下のみの介入設計
  • 並列処理: 人間判断中の並行作業継続
  • 事前設定: 判断基準の事前合意による迅速化

🤝 Claude Code実装の4パターン

1. 承認待機パターン

## 重要決定の承認待機
以下の提案について承認をお願いします:
- 提案内容: {{proposal_content}}
- 想定効果: {{expected_effect}}
- リスク評価: {{risk_assessment}}

「承認」または「修正要求」を回答してください。
承認いただけるまで次のステップに進みません。

あなたの判断を{{human_decision}}に設定してください。

2. 選択肢提示パターン

## 戦略選択
{{current_situation}}の状況で、以下の選択肢があります:

A. {{option_a}} - メリット: {{merit_a}}, リスク: {{risk_a}}
B. {{option_b}} - メリット: {{merit_b}}, リスク: {{risk_b}}  
C. {{option_c}} - メリット: {{merit_c}}, リスク: {{risk_c}}

どの選択肢を選びますか?(A/B/C)
選択理由もお聞かせください。

あなたの選択を{{human_choice}}に設定してください。

3. フィードバック統合パターン

## 成果物の品質確認
{{generated_content}}を作成しました。

以下の観点でフィードバックをお願いします:
- 内容の正確性: 問題ありませんか?
- 安全性: 不適切な表現はありませんか?
- 改善提案: 追加・修正すべき点はありますか?

フィードバックを{{human_feedback}}に設定してください。

4. 記録保持パターン

## 人間介入記録の永続化
以下の介入記録をhitl_log.jsonに保存してください:

{
  "timestamp": "{{current_time}}",
  "intervention_type": "{{intervention_type}}",
  "human_decision": "{{human_decision}}",
  "context": "{{decision_context}}",
  "rationale": "{{human_rationale}}",
  "system_state": "{{system_state}}"
}

🛡️ 基本例:安全な記事作成システム

HITLの基本概念を実践する、承認待機を組み込んだ記事作成システム:

## 記事テーマ設定
記事のテーマ「AI技術の最新動向」について、以下の構成を提案します:

1. AI技術の現状分析
2. 注目すべき技術トレンド  
3. 産業への影響予測
4. 今後の展望

この構成で進めてよろしいですか?
修正・追加したい点があれば指示してください。

あなたの承認を{{structure_approval}}に設定してください。

## 内容生成
{{structure_approval}}に基づいて各セクションの内容を生成し{{draft_content}}に設定してください。

## 安全性確認
{{draft_content}}について以下を確認してください:
- 事実関係の正確性
- 偏見や不適切な表現の有無
- 誤解を招く可能性のある記述

問題がある場合は修正指示をお願いします。
問題なければ「承認」と回答してください。

あなたの品質確認結果を{{quality_check}}に設定してください。

## 最終出力
{{quality_check}}が「承認」の場合のみ、最終記事をarticle_output.mdに保存してください。

## 介入記録
この一連の介入プロセスをhitl_log.jsonに記録してください:
- 構成承認: {{structure_approval}}
- 品質確認: {{quality_check}}
- 修正回数: {{revision_count}}

📁 実践サンプル

Human-in-the-Loop の詳細な実践例:

関連する高度な技術


Pattern 9: Error Handling(エラーハンドリング)

概要

Error Handlingパターンは、システム実行中に発生する様々な種類の問題への対応手法を提供する。堅牢なエージェントシステムには欠かせない重要なパターンである。

2つのアプローチ:

  1. Try-Catch-Finally(従来形例外処理): 予期せぬ実行時エラーへの対応
  2. Graceful Degradation(段階的品質調整): 予見可能な制約や限界への適応

この2つのアプローチを組み合わせることで、様々な状況に対応できる堅牢なシステムを構築できる。

このパターンは、A.2: 4層の防御戦略のレイヤー2「実行時のエラーハンドリング」の中核技術として位置づけられます。また、Graceful Degradationアプローチは、レイヤー1「設計段階での予防的対策」における品質調整機能も提供します。

9-1: Try-Catch-Finally(従来形例外処理)

プログラミング言語のtry-catch-finallyと同様の構造を自然言語で実現する。API呼び出し失敗、ネットワークエラー、ツールのバグなど、予期せぬ実行時エラーに対する明示的な回復処理を定義する。

基本構文パターン

## メインタスクの実行
以下の処理を試してください(Try):

primary_task.md を実行する。

もし失敗した場合は(Catch):
backup_task.md を実行する。

最後に(Finally):
実行結果(成功または失敗)を execution_log.txt に記録する。

実践パターン

1. API呼び出しの冗長化

## データ取得処理
以下の処理を試してください:

メインAPIからデータを取得し{{api_data}}に保存する。

失敗した場合:
バックアップAPIから同じデータを取得し{{api_data}}に保存する。

最終的に:
取得状況を{{api_status}}に記録し、api_log.jsonに保存する。

2. ファイル操作の安全性確保

## ファイル書き込み処理
以下の処理を試してください:

{{report_data}}をfinal_report.mdに書き込む。

失敗した場合:
{{report_data}}をbackup_report.mdに書き込み、
「メインファイルの書き込みに失敗しました」というメッセージを表示する。

最終的に:
書き込み結果を処理ログに記録する。

3. 外部ツール実行の信頼性向上

## 複数ツールでの検証
以下の処理を試してください:

Tool Aを使用してタスクを実行する。

失敗した場合:
Tool Bを使用して同じタスクを実行する。

それでも失敗した場合:
手動処理用の指示書を作成し、管理者に通知する。

最終的に:
実行結果と使用したツールを実行履歴に記録する。

これらの冗長化手法は、A.2: 4層の防御戦略のレイヤー2で詳述される「実行時エラーハンドリング」戦略の具体的実装です。複数の代替手段を事前に準備することで、単一障害点を排除し、システム全体の可用性を向上させます。

9-2: Graceful Degradation(段階的品質調整)

理想的な動作が困難な場合に、品質を段階的に調整しながらも価値のある結果を提供し続ける手法である。完全な失敗ではなく、制限された環境下でも最大限の機能を維持する。

基本概念

システムが理想的に動作できない場合でも、以下の優先順位で段階的に品質を調整:

  1. 理想動作: 完全な機能とクオリティ
  2. 実用動作: 主要機能を維持、一部制限
  3. 最低限動作: 核心価値のみ提供

実践パターン

1. リソース制約への対応

## レポート生成処理
十分な時間とリソースがある場合:
- 完全な市場分析
- 詳細なグラフ作成
- 包括的な推奨事項

時間が限られている場合:
- 主要指標のみの分析
- 簡易グラフ作成
- 重要な推奨事項のみ

緊急時:
- 最重要データのサマリーのみ
- テキストベースの簡潔な報告

2. データ品質への適応

## 分析精度の調整
データが完全にそろっている場合:
高精度な統計分析を実行し{{detailed_analysis}}に保存する。

一部データが欠損している場合:
利用可能なデータで概算分析を実行し{{approximate_analysis}}に保存する。

データが大幅に不足している場合:
傾向分析のみを実行し{{trend_analysis}}に保存し、
「データ不足により詳細分析は実行できませんでした」と記録する。

3. ツール利用可能性への対応

## 情報収集の段階的実行
Web検索ツールが利用可能な場合:
最新情報を含む包括的な調査を実行する。

Web検索が利用できない場合:
既存の知識ベースから関連情報を抽出する。

いずれも困難な場合:
一般的な知識に基づく基礎的な情報を提供し、
「最新情報の確認を推奨」との注意書きを追加する。

Error Handling統合例

Try-Catch-FinallyとGraceful Degradationを組み合わせた堅牢なシステム例:

## 市場分析レポート生成システム
以下の処理を試してください(Try):

最新の市場データAPIから情報を取得し、詳細分析を実行する。

API取得に失敗した場合(Catch):
既存データを使用した分析に切り替える(Graceful Degradation)。

既存データも不十分な場合:
業界一般動向に基づく概略分析を実行する(Further Degradation)。

最終的に(Finally):
- 実行された分析レベルを記録
- データソースと信頼性レベルを明記
- 次回実行時の改善提案を記録

要点

Try-Catch-Finally:

  1. 明示的エラー対応: 失敗時の具体的な回復手順を事前定義
  2. 冗長性の確保: 複数の実行パスによる信頼性向上
  3. 状況記録: 成功・失敗の情報を後の改善に活用
  4. 予期せぬ障害への備え: システムの完全停止を回避
  5. 変数管理の堅牢性: SQLiteベース変数管理での堅牢なデータ管理(詳細はA.15参照)

Graceful Degradation:

  1. 段階的品質調整: 完璧でなくても価値ある結果を提供
  2. 制約条件への適応: リソースやデータの制限下での最適化
  3. ユーザー期待の管理: 制限事項の明確な説明
  4. 継続的サービス: 部分的な機能提供によるシステム価値の維持

📁 実践サンプル

Error Handlingパターンの詳細な実践例:

エラーハンドリング体験方法

通常実行: そのまま実行するとWeb検索成功による理想レベル体験

エラー体験: Catch処理とGraceful Degradationを実際に体験したい場合

  1. Claude Code UIで /permissions を実行し現在権限確認
  2. 対話的UIでWebSearchツールを「Deny」に設定(権限変更はUI操作のみ可能)
  3. マクロ実行(Web検索失敗→Catch処理→実用レベル品質調整)
  4. 対話的UIでWebSearchツールを「Allow」に復元

注意: Claude Codeの権限変更は、セキュリティ上の理由により対話的UI操作でのみ可能である。コマンドライン形式(/permissions remove WebSearch等)は動作しない。この手順により、Try-Catch-Finally完全フローとGraceful Degradationの段階的品質調整を実際に体験できる。

関連する高度な技術


Pattern 10: Debug & Tracing(デバッグ・トレーシング)

概要: マクロ実行過程の状態追跡と問題診断機能。LLMが自然言語でデバッグ情報を実況し、変数値や判断根拠を明示することで、意図しない動作の原因特定と理解促進を実現する。

このパターンは、A.2: 4層の防御戦略のレイヤー3「監査と継続的改善」、およびA.5: 監査ログシステムと密接に関連しています。これらの技術を組み合わせることで、開発時のデバッグから本番運用時の監査まで、一貫した可視性を確保できます。

処理フロー: 実行 → 状態記録 → 分析・判断 → 診断情報出力

適用判断:

  • ✅ 複雑なマクロのデバッグが必要
  • ✅ 学習目的でプロセス理解を深めたい
  • ✅ 透明性と説明可能性が求められる
  • ✅ 非技術者が処理過程を理解する必要がある
  • ❌ 単純な処理でオーバーヘッドが不要(→Sequential Pipelineを検討)
  • ❌ 本番環境でのパフォーマンス重視時(→通常モード実行を推奨)

📋 デバッグ実行時の準備手順

デバッグ機能を使用する際は、以下の手順で準備してください:

手順1: デバッグ機能の読み込み

「debugger.mdを読み込んでください」  
→ デバッグ専用構文と出力機能を有効化

手順2: デバッグ実行

「デバッグモードで[処理内容]を実行してください」
→ 詳細な実行過程を可視化

統合実行例

「debugger.mdを読み込んでから、デバッグモードで商品推奨システムを実行してください」

重要: debugger.mdファイルには上記構文の完全版仕様が含まれており、実際のデバッグ時により詳細な参考資料として活用できる。このファイルには実験で検証された正確な構文定義、豊富な実行例、トラブルシューティングガイドが掲載されている。

実用例:学習スコア評価システムのデバッグ

## デバッグモードによる条件分岐の追跡

デバッグモードで以下を実行してください:
1. 学習スコアを85点として{{score}}に保存
2. {{score}}が80点以上の場合は『優秀』、60点以上80点未満は『良好』、それ未満は『要改善』として{{evaluation}}に保存
3. {{evaluation}}に基づいて具体的な次のステップを{{next_action}}に保存
4. 結果を整理して表示

# 期待されるデバッグ出力例:
[DEBUG] ステップ1: 学習スコアを{{score}}に保存
[DEBUG] 変数状態: {{score}} = 85
[DEBUG] ステップ2: 条件分岐による評価判定
[DEBUG] 条件1チェック: {{score}} >= 80 → 85 >= 80 = true
[DEBUG] 分岐決定: 条件1が真のため「優秀」ブランチを選択
[DEBUG] 変数状態: {{evaluation}} = "優秀"
[DEBUG] ステップ3: {{evaluation}}に基づく次のステップ決定
[DEBUG] 判断根拠: 優秀評価 → さらなる高度な学習機会を提供
[DEBUG] 変数状態: {{next_action}} = "高度な応用課題への挑戦を推奨"

🔧 基本的なデバッグモード

簡易デバッグ: 変数値の確認のみ

「簡易デバッグモードで{{weather}}を基に服装提案を作成してください」
→ 変数値と基本的な処理ステップのみ表示

標準デバッグ: 判断根拠を含む詳細情報

「デバッグモードで{{budget}}と{{required_qty}}から商品推奨を実行してください」
→ 計算過程、条件判定、判断理由を詳細に説明

🛡️ 高度なトレーシング機能

変数特化追跡:

「変数{{score}}をデバッグ追跡しながら評価システムを実行してください」
→ 特定変数の状態変化を重点的に監視

エラー診断モード:

「エラー発生時に詳細説明付きで予算チェックシステムを実行してください」
→ 異常系での詳細な診断情報を提供

🎯 段階的習得の3ステップ

ステップ1: 基本変数のデバッグ

## 変数操作の可視化

デバッグモードで以下を実行してください:
「今日の天気情報を{{weather}}に保存し、{{weather}}を基に服装提案を{{outfit}}に保存してください」

期待される効果:
- 変数への値設定プロセスの理解
- 変数間の依存関係の可視化
- 基本的なデバッグ出力の読み方

ステップ2: 条件分岐のデバッグ

## 判断プロセスの追跡

デバッグモードで以下を実行してください:
「{{temperature}}が20度未満で{{weather}}が雨の場合は『外出注意』、そうでない場合は『通常外出』として{{advice}}に保存してください」

期待される効果:
- 複合条件の評価過程の理解
- 論理演算(AND, OR)の可視化
- 分岐選択の理由説明

ステップ3: 複雑ワークフローのデバッグ

## 多段階処理の全体追跡

デバッグモードで以下を実行してください:
「予算150000円、必要台数3台の条件で、商品データから価格フィルタリング→在庫チェック→推奨決定→見積作成の全工程を実行してください」

期待される効果:
- 長期プロセスでの状態管理
- 数値計算とビジネスロジックの連携
- エンドツーエンドの処理追跡

🔧 デバッグ構文リファレンス

基本デバッグ指示

「デバッグモードで[処理内容]を実行してください」
→ 標準レベルのデバッグ情報を出力

レベル別デバッグ

# 簡易デバッグ(基本情報のみ)
「簡易デバッグモードで{{weather}}を基に服装提案を作成してください」

# 標準デバッグ(詳細情報)
「デバッグモードで{{budget}}から商品推奨システムを実行してください」

# 詳細デバッグ(最大詳細)
「詳細デバッグモードで複雑な在庫管理ワークフローを実行してください」

特定要素デバッグ

# 変数追跡
「変数{{score}}をデバッグ追跡しながら評価システムを実行してください」

# 条件分岐
「条件分岐をデバッグしながら推奨システムを実行してください」

# エラー診断
「エラー発生時に詳細説明付きで予算チェックシステムを実行してください」

デバッグ出力フォーマット

[DEBUG] ステップ[番号]: [実行内容の説明]
[DEBUG] 変数状態: {{variable_name}} = [現在値]
[DEBUG] 判断根拠: [条件評価の理由]
[DEBUG] 次のアクション: [次に実行する処理]

本番環境での監査ログ記録についてはA.5: 監査ログシステムを、より包括的な防御戦略についてはA.2: 4層の防御戦略を参照してください。

📁 実践サンプル

Debug & Tracing の詳細な実践例:

関連する高度な技術


📜 免責事項

本ガイド『Claude Code 自然言語マクロプログラミングガイド』をご利用いただく前に、以下の内容をよくお読みいただき、ご理解の上でご自身の責任においてご活用いただきたい。本ガイドの利用を開始した時点で、以下の内容に同意したものとみなす。

  1. 保証の否認 本ガイドで提供される情報、サンプルコード、および手法は、その正確性、完全性、有用性、特定目的への適合性を一切保証するものではない。これらは「現状有姿(as-is)」で提供される。

  2. 動作の不確実性 本ガイドで紹介する手法は、大規模言語モデル(LLM)の確率的な性質に強く依存している。そのため、本ガイドに記載された通りに実行しても、常に期待通りの結果や動作が得られるとは限らない。実行のたびに結果が変動する可能性がある。

  3. 責任の制限 本ガイドの利用によって生じたいかなる損害(データの損失、業務の中断、利益の逸失、その他あらゆる直接的・間接的損害を含む)についても、著者および関係者は一切の責任を負わない。

  4. 自己責任の原則 本ガイドの手法の利用は、すべて利用者ご自身の責任において行ってください。特に、ファイル操作やコマンド実行(Bashなど)といった、ご自身のシステム環境に影響を与える可能性のある機能の利用には、細心の注意が必要です。重要なデータが含まれる環境や本番環境での実行は絶対に避け、必ず安全なテスト環境で十分に検証してください。

  5. セキュリティについて 本ガイドで提示される手法を安全に利用するためのセキュリティ対策(信頼できないコードを実行しない、権限を適切に管理するなど)は、利用者ご自身の責任で行う必要があります。

  6. 外部サービスについて 本ガイドはAnthropic社のClaudeの機能に言及していますが、著者および本ガイドは同社とは独立しており、公式なものではありません。Claudeの利用規約や仕様は変更される可能性があり、それに伴い本ガイドの内容が古くなったり、利用できなくなったりする場合があります。

  7. 内容の変更 本ガイドの内容は、予告なく変更または削除されることがある。