← すべての記事

プロンプトエンジニアリングのためのOODAループ：5つの失敗が教えてくれたこと

3分で読めます

John Boyd大佐のOODAループは、1960年代に戦闘機パイロットの意思決定のために開発されました。観察（Observe）、情勢判断（Orient）、意思決定（Decide）、行動（Act）のサイクルをより速く完了したパイロットが、機体の性能に関係なく決定的な優位性を得ました。私はプロンプトエンジニアリングにも同じ原則が当てはまることを発見しました。5つの高くついた失敗が、プロンプトを書くことが最も重要でないステップであることを教えてくれたのです。1

TL;DR

OODAループ（観察、情勢判断、意思決定、行動）は、プロンプトエンジニアリングにおける最も一般的な失敗パターン、つまり観察（完全なコンテキストの理解）の前に行動（プロンプトの記述）してしまうことを防ぐ体系的なフレームワークを提供します。44のスキル（それぞれが自動起動ロジックを備えた構造化されたプロンプト）を構築する中で、プロンプト自体が成果の約20%しか占めないことを学びました。残りの80%は、観察（モデルにどのようなコンテキストが必要か？）、情勢判断（そのタスクはどの種類のタスクか？）、そして意思決定（どのプロンプトパターンがそのタスクの種類に適合するか？）です。以下のインタラクティブビルダーでは、OODAサイクルの全体を体験できます。その結果、反復的な改善を必要とせず、最初の試行で成功するプロンプトが生まれます。

5回失敗したプロンプト

行動する前に観察することを学ぶ以前、私は開発者がコードを書くようにプロンプトを書いていました。つまり、いきなり解決策に飛びついていたのです。

失敗1：ブログ評価ツール。 ブログの品質評価プロンプトの最初の試み：「このブログ記事を評価して、1〜10のスコアをつけてください。」モデルは「7/10」という曖昧な段落を返し、実用的なフィードバックはありませんでした。4回反復してようやく、問題がプロンプトの言い回しではなく、「品質」の定義がなかったことだと気づきました。

OODAによる修正： 自分自身の評価プロセスを30分かけて観察しました。私が重視する6つの具体的な次元を特定しました：読者への価値（25%）、技術的正確性（20%）、教育的品質（20%）、文章品質（15%）、事実の正確性（15%）、SEO効果（5%）。この加重ルーブリックがblog-evaluatorスキルとなり、以降のすべての評価で一貫した実用的なスコアが生成されるようになりました。2

失敗2：コードレビュアー。 最初のレビュープロンプト：「このコードのバグとセキュリティの問題をレビューしてください。」モデルは15の指摘を返しましたが、そのうち12はスタイルに関する些細な指摘でした。シグナル対ノイズ比の低さがレビューを無意味にしていました。

OODAによる修正： タスクを3つの独立したサブタスク（正確性、セキュリティ、規約）として位置づけ、それぞれにツールアクセスの制限と具体的な評価基準を持つ3つの専用レビュアーサブエージェントを構築しました。正確性レビュアーはロジックエラーのみを指摘します。セキュリティレビュアーはOWASPの脆弱性のみを指摘します。規約レビュアーはパターンからの逸脱のみを指摘します。各プロンプトが1つの次元に狭くスコープされているため、ノイズはほぼゼロになりました。3

失敗3：翻訳プロンプト。 「このブログ記事を韓国語に翻訳してください。」モデルは翻訳しましたが、すべてのマークダウンフォーマットが失われ、脚注の参照が削除され、英語のまま残すべき技術用語が書き換えられていました。

OODAによる修正： 私のユースケースにおいて「翻訳」が実際に何を意味するかを観察しました。マークダウン構造の保持、脚注番号の保持、コードブロックの未翻訳維持、固有名詞の英語維持、慣用句の直訳ではなく意訳。制約リストは翻訳の指示よりも長くなりました。各制約が、「これを翻訳して」では発生していたであろう失敗モードを排除しました。4

プロンプティングに適用したOODAループ

フェーズ1：観察（Observe）

プロンプトの一言目を書く前に、問題空間を観察します：

実際のタスクは何か？ 表面的なリクエストではなく、根本的なニーズです。「この文書を要約して」は、実際には「この会議で下された3つの決定事項を抽出して、アクションアイテムをフォローアップできるようにして」という意味かもしれません。

モデルは何を知る必要があるか？ 正確な応答に必要なコンテキストを列挙します。コンテキストの不足はハルシネーションを引き起こします。過剰なコンテキストはトークンを浪費し、モデルの注意を散漫にします。

出力はどのような形か？ プロンプトを書く前に、望ましい出力のフォーマット、長さ、トーン、構造を定義します。曖昧な出力の期待は曖昧な出力を生みます。5

観察チェックリスト： - [ ] 実際のタスク（表面的なリクエストではなく）を特定した - [ ] 必要なコンテキストを列挙した - [ ] 出力フォーマットを定義した - [ ] 成功基準を明確にした - [ ] 失敗モードを予測した

フェーズ2：情勢判断（Orient）

モデルの能力空間の中でタスクを位置づけます：

タスクの種類分類。 そのタスクは抽出（提供されたテキストから情報を引き出す）、生成（新しいコンテンツを作成する）、変換（フォーマット間の変換）、分析（コンテンツの評価と推論）、分類（入力のカテゴリー分け）のどれですか？6

各タスクの種類には確立されたプロンプトパターンがあります。私の44のスキルはそのパターンを反映しています：blog-evaluatorスキルは分析パターン（加重ルーブリック、構造化スコアリング）を使用します。blog-writer-coreスキルは生成パターン（スタイルルール、制約リスト、構造の例）を使用します。citation-verifierスキルは抽出パターン（主張の抽出、ソースとの照合）を使用します。

複雑さの評価。 タスクは単一のプロンプトで完了できますか？それとも分解が必要ですか？目安として、3つ以上の異なる認知的操作が必要な場合は分解します。

私のdeliberationシステムは分解をさらに推し進めます。信頼度が低い場合（スコアが0.70未満）、システムは複数のエージェントを生成して問題を独立に探索し、その回答を品質順にランク付けします。単一プロンプトの複雑さの閾値はさまざまですが、リサーチ、分析、生成が混在するタスクは必ず分解します。

制約のマッピング。 どのような制約が適用されますか？トークン制限、出力フォーマットの要件、事実の正確性の必要性、トーンの要件、対象読者の考慮。各制約はプロンプト内の明示的な指示となります。

フェーズ3：意思決定（Decide）

観察と情勢判断に基づいて、プロンプトのアーキテクチャを決定します：

プロンプトパターンの選択：

タスクの種類 推奨パターン 実際の例
抽出 スキーマガイド付き抽出 Citation verifier：主張の抽出、脚注との照合
生成 制約リスト＋例 Blog writer：14の必須スタイルルール、トーンガイド
変換 入出力ペア＋保持リスト i18n translator：マークダウン、コード、脚注の保持
分析 加重ルーブリック＋構造化出力 Blog evaluator：6カテゴリー、加重スコアリング
分類 ラベル付き例＋決定木 Content depth checker：5つの独自性シグナル、0〜5のスコア

ロールの割り当て。 ロールは、特定の視点がタスクに有益な場合に機能します。私のsecurity-reviewerサブエージェントは「OWASP Top 10の脆弱性についてコードをレビューするシニアセキュリティエンジニア」というロールを与えられています。このロールにより、出力がセキュリティ上の懸念に焦点を当てます。ロールがタスクと矛盾する場合（事実分析タスクに「あなたはクリエイティブライターです」と指定するなど）、ロールは失敗します。7

フェーズ4：行動（Act）

フェーズ3の決定事項を使ってプロンプトを記述します。プロンプトは一貫した構造に従います：

[ROLE] (if applicable)
[CONTEXT] (the information the model needs)
[TASK] (the specific instruction)
[FORMAT] (the expected output structure)
[CONSTRAINTS] (restrictions and requirements)
[EXAMPLES] (if using few-shot)

この構造は機械的に埋めるテンプレートではありません。この構造はチェックリストです：観察、情勢判断、意思決定の各フェーズで、各セクションを書くための十分な明確さが得られたかを確認するためのものです。いずれかのセクションが不明確な場合は、適切な前のフェーズに戻ります。8

私のプロンプトライブラリ：構造化されたプロンプトとしての44のスキル

私のClaude Codeのスキルシステムは、本質的にはタスクの種類別に整理されたプロンプトライブラリです。各スキルはOODA構造に従っています：

---
description: FastAPI backend development patterns and conventions
allowed-tools: [Read, Grep, Glob, Edit, Write, Bash]
---
# FastAPI Development Expertise

## Project Structure
[CONTEXT: expected file layout, naming conventions]

## Route Patterns
[CONSTRAINTS: response format, error handling, dependency injection]

## Database Patterns
[CONSTRAINTS: SQLAlchemy 2.0+ async, Pydantic v2 models]

スキルの説明が観察（そのスキルはいつ起動すべきか？）を担います。allowed-toolsフィールドが情勢判断（そのタスクにはどの能力が必要か？）を担います。本文が意思決定と行動（モデルはどのパターンに従うべきか？）を担います。9

blog-writer-coreスキルには14の必須スタイルルールがエンコードされています。これらは失敗を通じて発見された制約です：

  1. 能動態のみ使用（「エンジニアが導入した」であり「導入された」ではない）
  2. 「これ」を主語にしない（常に指示対象を明示する）
  3. すべての主張に脚注で出典を記載する
  4. コードブロックに言語識別子をタグ付けする
  5. emダッシュを使わない（カンマまたはセミコロンを使用する）

各ルールは、それに違反した記事を公開した経験から生まれています。ルール#1は、blog-quality-gateフックが7つの受動態の文を検出したことから生まれました。ルール#3は、McKinseyの統計について出典のない主張を公開したことから生まれました。OODAの観察フェーズが失敗を特定し、プロンプト内の制約が再発を防ぎます。10

反復ループ

OODAループは本質的に反復的です。行動（プロンプトの送信）の後、結果を観察します：

  1. 観察： 出力を確認します。何が正しいか？何が間違っているか？何が欠けているか？
  2. 情勢判断： ギャップを分析します。問題はコンテキスト（情報の不足）か、フォーマット（構造の誤り）か、能力（単一プロンプトには複雑すぎるタスク）か？
  3. 意思決定： 修正方法を決めます。コンテキストの追加か、フォーマット指示の調整か、タスクの分解か。
  4. 行動： 修正したプロンプトで再実行します。

各反復サイクルでは、正確に1つの変数のみを変更すべきです。複数のプロンプト要素を同時に変更すると、どの変更がどの効果を生んだかを特定できなくなります。11

私のブログ評価ワークフローは、完全な反復ループに従っています：

1. Lint (deterministic) → fix structural issues
2. Evaluate (LLM) → score on 6 dimensions
3. Critique (LLM) → identify specific improvements
4. Fix (LLM) → apply surgical improvements
5. Re-evaluate → verify score improved

各ステップは、そのタスクの種類に最適化された異なるプロンプトを使用します。リントステップは抽出（違反の発見）を使用します。評価ステップは分析（ルーブリックに対するスコアリング）を使用します。批評ステップは生成（改善提案の作成）を使用します。修正ステップは変換（構造を保持した変更の適用）を使用します。このチェーンは、単一の包括的な「この記事を改善して」というプロンプトよりも優れた結果を生み出します。12

重要なポイント

AIの機能を構築するエンジニアの方へ： - プロンプトを書く前に完全なOODAサイクルを適用してください。5分間の観察と情勢判断が、30分間の反復的なプロンプト改善を節約します - プロンプトパターンを選択する前に、タスクの種類（抽出、生成、変換、分析、分類）を分類してください。各種類には、汎用的なプロンプティングを上回る確立されたパターンがあります - タスクの種類別に整理されたプロンプトライブラリを構築してください。私の44のスキルは、プロジェクト横断で再利用する検証済みのプロンプトパターンです

AIを日常的に使用するプロダクトチームの方へ： - AIの出力に不満がある場合、失敗が観察（誤ったタスクの特定）、情勢判断（誤ったアプローチ）、意思決定（誤ったプロンプトパターン）、行動（誤ったプロンプトの文言）のどのフェーズにあるかを診断してください。修正方法はフェーズごとに異なります - 制約は巧みなプロンプトの言い回しよりも多くの失敗を防ぎます。私のブログライターの14の必須ルールは、いかなる量の「上手に書いてください」よりも一貫した品質を生み出します

参考文献

  1. Boyd, John R., “Destruction and Creation,” unpublished paper, 1976. ↩

  2. Author’s evaluator skill. 6-category weighted rubric developed through iterative prompt failure. Located at ~/.claude/skills/. ↩

  3. Author’s reviewer subagent architecture. Three specialized reviewers (correctness, security, conventions) with restricted tool access and narrow evaluation criteria. ↩

  4. Author’s i18n translation system. Constraint-driven translation preserving markdown structure, footnotes, code blocks, and proper nouns across 6 languages. ↩

  5. Anthropic, “Prompt Engineering Guide,” 2025. ↩

  6. Wei, Jason et al., “Chain-of-Thought Prompting Elicits Reasoning in Large Language Models,” NeurIPS 2022. ↩

  7. Shanahan, Murray et al., “Role Play with Large Language Models,” Nature, 623, 493-498, 2023. ↩

  8. Anthropic, “Prompt Engineering Guide,” 2025. Prompt structure best practices. ↩

  9. Author’s Claude Code skills system. 44 skills functioning as structured prompt library with OODA-aligned structure. ↩

  10. Author’s writer-core skill. 14 mandatory style rules, each derived from a published quality failure. ↩

  11. Zamfirescu-Pereira, J.D. et al., “Why Johnny Can’t Prompt: How Non-AI Experts Try (and Fail) to Design LLM Prompts,” CHI 2023. ↩

  12. Author’s quality pipeline. 5-step evaluate-fix-reevaluate loop using task-specific prompts at each stage. ↩