🔑 Opus 4.6の正しい使い方 - 5つのプロンプトシステム

**投稿者:** God of Prompt (@godofprompt)

**投稿日時:** 2026-02-09

**URL:** https://x.com/godofprompt/status/2020499426389741784

**エンゲージメント:** 大量のブックマーク（Article形式の長文投稿）

**カテゴリ:** 💻 技術Tips / 📖 学習リソース

**有益度:** ⭐⭐⭐ HIGH

---

概要

「みんなOpus 4.6のベンチマークを投稿してるけど、ワークフローを見せてよ」という挑発的な書き出しから始まる、実戦的なOpus 4.6活用ガイド。単発プロンプトではなく、5つのプロンプトが連携する「システム」を構築することで、真の生産性向上を実現する方法を解説。

---

まとめ

🎯 核心的な主張

**個別プロンプトは行き止まり**: 1つのプロンプト→1つの出力で終わる。翌日また最初から。蓄積がない。システムがない。

**システムが答え**: 5つのプロンプトが循環し、文脈が蓄積され、パターンが出現し、Claudeがあなたのニーズを先読みし始める。

📊 5つのプロンプトシステム

#### Step 1: THE AUDIT（監査）

• **目的**: 何を自動化すべきかを発見
• **特徴**: 時間消費だけでなく「精神的負荷」も評価
• **出力**: 自動化スコア付き4週間プラン

**Opus 4.6の強み**: 表面的な「仕事は何？」ではなく、「どのタスクが仕事中でなくても頭に残ってる？」と精神的コストを掘り下げる。

#### Step 2: THE ARCHITECT（設計者）

• **目的**: コードを書く前に完全な実装青写真を作成
• **特徴**: 複数のアプローチを提示、トレードオフを明示
• **出力**: 段階的実装プラン、依存関係チェック、ロールバックポイント

**Opus 4.6の強み**: 1Mトークンコンテキストウィンドウで、コードベース全体を保持しながら設計できる。

#### Step 3: THE ANALYST（分析者）

• **目的**: コード/自動化のエンジニアリングレビュー
• **特徴**: あなたのエンジニアリング標準を組み込んだレビュー
• **出力**: アーキテクチャ、コード品質、信頼性、パフォーマンスの4軸評価

**Opus 4.6の強み**: Adaptive thinkingが分析深度を動的調整。シンプルな関数は高速レビュー、複雑な状態管理は深い分析。

#### Step 4: THE REFINERY（精製所）

• **目的**: 収束ループによる再帰的改善
• **特徴**: 自己採点→診断→書き直し→再採点のループ
• **出力**: 品質基準（各項目8/10以上）に達するまで自動改善

**Opus 4.6の強み**: 自己採点が演技的でなく、本物の根本原因診断を行う。

#### Step 5: THE COMPOUNDER（複利化）

• **目的**: 週次レビューでシステムを賢くする
• **特徴**: 毎週のオートメーション振り返り、パターン認識
• **出力**: 累積時間節約、次週のターゲット、改善提案

**Opus 4.6の強み**: 1Mトークンコンテキストで数週間分のレビュー履歴を保持。コンテキスト圧縮で古いレビューを要約。

🔄 システムの循環

AUDIT → ARCHITECT → ANALYST → REFINERY → COMPOUNDER
  ↑                                           ↓
  └───────────────────────────────────────────┘

各プロンプトが次を改善し、最後が最初にフィードバック。これが「複利化」の正体。

💡 Opus 4.6の正直な評価

**genuinely better（本当に良くなった点）:**

• **Adaptive thinking**: タスク複雑度に応じて推論深度を動的調整（これは本物）
• **1Mトークンコンテキスト**: コードベース全体、数週間のレビュー履歴を保持可能
• **Sub-agent orchestration**: 複雑タスクを自動的に専門サブプロセスに委任

**about the same（変わらない点）:**

• 標準的なライティング、基本Q&A、シンプルなコンテンツ生成
• 「キャプション書いて」レベルでは差を感じない

**worse（悪くなった点）:**

• 精度と構造化推論の最適化で、自由形式のクリエイティブ出力が機械的に感じる
• 純粋なクリエイティブライティングはSonnetと比較推奨
• 200Kトークン超えると料金が大幅に増加

🚀 実装の開始方法

**週次進行（全部一度にやらない）:**

• Week 1: AUDITプロンプト実行 → トップ4自動化ターゲット特定 → 最も簡単なものを自動化
• Week 2: ARCHITECTプロンプトで2番目のターゲットをプラン → 構築
• Week 3: ANALYSTプロンプトでWeek 1-2の成果物をレビュー → 修正
• Week 4: REFINERYで最も重要な出力を磨く → 品質ジャンプを確認
• Week 5: COMPOUNDERで全体レビュー → 次月プラン

**週1タスク自動化 → 3ヶ月で12ワークフロー稼働**

---

X Article 本文（要約・日本語訳）

みんなOpus 4.6のベンチマーク比較を投稿してる。

いいね。じゃあワークフローを見せてよ。

私はローンチからOpus 4.6を実際に動かしてる。ベンチマークじゃない。トリビアクイズのテストじゃない。**実際の仕事**を通して。

で、数日後に気づいたことがある：**個別プロンプトは行き止まり**だと。

1つのプロンプト → 1つの出力。微調整して少し良い出力を得て、次に進む。翌日また最初から。複利がない。システムがない。ただの「まあまあ良かったね」の連続。

**結果を出してる人はプロンプトを使ってない。システムを動かしてる。**

だから私は1つ作った。5つのプロンプトが循環するループ。各プロンプトが次に繋がる。文脈が蓄積され、パターンが出現し、Claudeがあなたが求める前にニーズを先読みし始める。

これが全システム。プロンプト1つずつ、何が機能して何が機能しないかの正直な内訳付き。

基盤：なぜシステムがプロンプトコレクションに勝つか

ほとんどの人はプロンプトをレシピのように集める。47個ブックマークして、2個使って、残りは忘れる。

**システムは違う。** Step 1の出力がStep 2の入力になり、Step 5の洞察がStep 1にフィードバックされる接続されたワークフロー。

これがループ：

1. **AUDIT**: 実際に時間とエネルギーを奪ってるものを発見

2. **ARCHITECT**: 何かを構築する前に解決策を計画

3. **BUILD + REVIEW**: 1回のパスで実行と品質チェック

4. **REFINE**: 品質バーに達するまで収束ループで出力を実行

5. **COMPOUND**: 改善を積み重ね、Step 1にフィードバックする週次レビュー

各ステップに1つのプロンプト。プロンプトは連携するように設計されているが、各プロンプトは独立しても有用。

全5つを初日から実行する必要はない。プロンプト1から始める。週1個追加。Week 5までに完全ループが稼働し、複利化が始まる。

Opus 4.6についての正直な見解も最後に書く。本当に良くなった点、同じ点、悪くなった点。誇大広告なし。

では構築しよう。

Step 1: THE AUDIT（何を自動化する価値があるかを発見）

ほとんどの人がここをスキップして「クールなプロンプトちょうだい」に行く。間違い。間違ったものを自動化したら、存在すべきでないものの高速版を作っただけ。

このプロンプトはOpus 4.6を生産性アナリストに変える。実際のワークフローをマッピングし、各タスクをエネルギー消費と自動化可能性でスコア化し、優先順位付けされた4週間プランを提供する。

**プロンプトとの重要な違い:** タスクを2次元でスコア化。消費時間 AND 精神的エネルギー消費。時々、1日中頭に残る15分タスクは、気にならない2時間タスクより先に自動化する価値がある。

（プロンプト全文は省略 - 原文参照）

Opus 4.6でこれを実行したとき、興味深いことが起きた。以前のモデルは「仕事は何？」みたいな表面レベルの質問をしてた。Opus 4.6は「あなたが言及したタスクの中で、作業してない時でも考えてしまうものはどれ？」と聞いてきた。これがエネルギー消費次元の働き。目に見えないコストをマッピングしてる。

Opus 4.6のAdaptive thinkingがここで重要。「何時に仕事始める？」には速答。「コンテンツパイプライン vs クライアントオンボーディングの自動化優先順位をどうすべき？」には本物の熟考。シンプルな質問は高速回答。複雑なトレードオフ分析は本物の熟考を受ける。

**このプランを使って週1タスクを自動化すれば、1ヶ月で4ワークフローが稼働。3ヶ月で12。まだ「トップ10 AIツール」スレッドをブックマークしてる99%より先に進んでる。**

Step 2: THE ARCHITECT（構築前に計画）

ほとんどの人が時間を無駄にするのはここ。構築に直行、壁にぶつかり、後戻りし、再構築、また壁、の繰り返し。

このプロンプトはOpus 4.6をソリューション設計者に変える。コード1行、自動化1設定を書く前に、完全な実装青写真を作成。設計レビューでシニアエンジニアが聞くような質問をする。

Opus 4.6の1Mトークンコンテキストウィンドウで特に強力。コードベース全体、ドキュメント、プロジェクトコンテキストを入れて、ソリューションを設計しながら実際に全部をワーキングメモリに保持できる。

（プロンプト全文は省略 - 原文参照）

**Architectプロンプトはみんながスキップするもの。そして最も時間を節約するもの。**

先週、これを使って自動化コンテンツパイプラインを計画した。最初の本能は、Zapier、データベース、3つの異なるAPIを使った複雑なマルチツールワークフローを構築することだった。Architectプロンプトは3つのアプローチをマッピング。最もシンプルなもの、単一Google Sheetをデータベースとして使うClaude-nativeワークフローが、私の要件の90%を処理した。週末じゃなく午後で済んだ。

**それが計画の価値：複雑なものを構築せずに済む時、シンプルなもので機能する時。**

Step 3: THE ANALYST（1回のパスで構築とレビュー）

これがエンジニアリングプロンプト。コードレビュー、Vibe Codingプロジェクト、自動化デバッグ、技術的構築全般に使える。

**重要な設計選択:** Claudeに「コードレビューして」と頼む（曖昧、汎用フィードバックを生成）代わりに、あなたの実際のエンジニアリング標準を直接プロンプトに埋め込む。Claudeはあなたがどう品質を考えるか知ってるシニア開発者のようにレビューする。

Claude Codeコミュニティで出回ってたフレームワークから再構築した。オリジナルは堅実だったがほとんどのユーザーには過剰構築。このバージョンはよりタイトで、経験豊富な開発者とVibe Coder両方に機能する。

（プロンプト全文は省略 - 原文参照）

Opus 4.6はこのプロンプトを目に見えて良く処理する。Adaptive thinkingが分析深度をコードの複雑度にスケールさせる。シンプルなユーティリティ関数は高速レビュー。複雑な状態管理システムは、複数の関心事にわたる本物のトレードオフ推論を伴う深い分析を受ける。

**Tip:** 「エンジニアリング標準」セクションをあなたの実際の好みに合わせてカスタマイズする。それが汎用フィードバックと、コードベースを知ってる協力者のように感じるフィードバックの違い。

**直接コードを書かないVibe Coderには:** これはClaude CodeやCursorがあなたのために生成したコードをレビューするのに等しく機能する。生成されたものを貼り付け、このレビューを実行、複利化する前に問題をキャッチ。

Step 4: THE REFINERY（収束まで再帰的改善）

これがすべてを良くするパターン。コンセプト：1回生成して出荷する代わりに、生成し、特定基準で自身の出力をスコア化し、弱点を診断し、書き直し、収束するまで再スコア化するようClaudeに指示。

マーケティングフレームワークからクリーンで再利用可能なシステムに再構築した。重要な改善：バージョン間のデルタを追跡し、正確に何が変わって何故かを見れる。また収穫逓減に達したことを検出して停止し、無限書き直しの代わりに終わる。

（プロンプト全文は省略 - 原文参照）

**異なる作業のためのスコアリング基準のカスタマイズ方法:**

• **ライティング/コンテンツ:** フック強度、明瞭さと流れ、具体性、感情的共鳴、実行可能性
• **コード:** 正確性、可読性、エッジケース処理、パフォーマンス特性、テストカバレッジ
• **リサーチ/分析:** ソース品質、推論深度、実用的適用性、論理構造、知的誠実性
• **メール/アウトリーチ:** トーン校正、簡潔性、要求の明瞭さ、パーソナライゼーション、プロフェッショナルな温かみ

Opus 4.6のAdaptive thinkingがこのループを実際に機能させる。以前のモデルでは「自己スコアリング」が演技的だった。「具体性7/10」と言って、同じレベルの具体性で書き直す。Opus 4.6は自分の出力の根本原因を診断するためにより深い推論に本当に関与する。

記事下書きでこれをテストした時、v1は具体性6/10をスコア化。モデルは問題を「名前付き企業とデータポイントの代わりに汎用カテゴリ参照を使用」と診断。v2は汎用例を特定の名前付きソースと具体的数字に置き換えた。v3は9/10に達した。自己診断は正確で、演技ではなかった。

Step 5: THE COMPOUNDER（システムを賢くする週次レビュー）

これはほとんどの人が構築を考えないプロンプト。そしてこれが5つの孤立プロンプトを実際のシステムに変える。

毎週金曜日（またはあなたのレビュー日）、このプロンプトを実行。その週に自動化したものをレビューし、機能したもの、しなかったもの、次週の自動化ターゲットを計画。時間をかけて、あなたの特定ワークフローに何が機能するかのパターンライブラリを構築。

（プロンプト全文は省略 - 原文参照）

このプロンプトはOpus 4.6のコンテキスト管理機能を活用。1Mトークンコンテキストウィンドウで、単一会話で数週間のレビュー履歴を保持できる。コンテキスト圧縮機能は、新しいもののためのスペースを保持しながら重要なパターンを失わずに古いレビューを自動要約する。

**複利効果は本物。** Week 1、おそらく2時間節約する1つの自動化を持ってる。Week 4、6-8時間節約する4つ。Week 12、ワークフローを動かす12のマイクロシステムとClaudeはあなたが考えなかった自動化を提案するのに十分あなたのパターンを知ってる。

システムがどう接続するか

5つのプロンプトはランダムじゃない。サイクルを形成：

AUDIT → 何を自動化するか特定

ARCHITECT → 構築方法を計画

ANALYST → 構築したものをレビュー

REFINERY → 出力品質を磨く

COMPOUNDER → 週をレビューし、次のAUDITに洞察をフィード

各プロンプトが他を良くする。ArchitectはAnalystのレビュー標準があなたの思考に埋め込まれてるからよりクリーンなプランを作る。RefineryはAuditが正しいタスクを特定したから良い出力を生産。Compounderは将来のAuditを改善するパターンを検出。

**それがプロンプトコレクションとシステムの違い。プロンプトは孤立イベント。システムは複利化。**

Opus 4.6についての正直な見解

実際の仕事を数週間通して実行した後、ここに着地した：

**本当に良くなったもの:**

Adaptive thinkingは本物。モデルはタスク複雑度に基づいて推論深度を動的調整。シンプルな質問、高速回答。複雑なマルチステップ問題、実際に熟考。

これはマーケティング言語じゃない。シンプル vs 複雑コードでAnalystプロンプトがどう処理するかの違いを感じられる。

1Mトークンコンテキストウィンドウは大規模プロジェクトで可能なことを変える。コードベース全体をAnalystプロンプトに入れる、またはCompounderで数週間のレビュー履歴を維持する、これは以前単に実現可能じゃなかった。コンテキスト圧縮も助ける。重要な決定を失わずにスペースを保持するため古い会話ターンを自動要約。

Sub-agent orchestrationは静かなアップグレード。Opus 4.6に複雑タスクを与えると、作業の一部が専門サブプロセスに委任されることで利益を得るとき認識する。これをプロンプトする必要ない。ただやる。

**ほぼ同じもの:**

標準ライティングタスク、基本Q&A、シンプルコンテンツ生成。ワークフローがほぼ「キャプション書いて」なら、意味のあるジャンプに気づかない。改善は複雑、マルチステップ、推論ヘビーなタスクで現れる。

**悪くなったもの:**

精度と構造化推論の最適化が自由形式クリエイティブ出力をより機械的に感じさせるとユーザー報告。

純粋なクリエイティブライティングが欲しいなら、コミットする前にSonnetとテストする。また、料金は200Kトークン超えで大幅にスケール。1Mコンテキストウィンドウは強力だが無料じゃない。

**パターンは全モデルリリースで保持:** 約20%のワークフローが本当に改善。他80%は同じまま。利益を得る人は全ベンチマークスレッドを読んでる人じゃない。5つの実際のプロンプトを実行して30分で決定する人。

なぜこれが機能するか（そしてほとんどのプロンプトコレクションが機能しない理由）

「ChatGPT用500プロンプト」リストの問題：幅を最適化。メール用1つ。コード用1つ。レシピ用1つ。間に接続なし。複利化なし。

**このシステムは深度を最適化。** 5つのプロンプト、タイト接続、長く使うほど良くなる。

AI生産性についての不快な真実：**ツールはシステムほど重要じゃない。** 人々は魔法のアップグレードを探して最新モデルリリースを追う。本当のアップグレードは、どのモデルを動かしてても複利化するワークフローを構築すること。

Opus 4.6はこのシステムのために使った最高モデル。でもシステムはGPT-5.2でも機能する。次四半期何が出荷されても機能する。**なぜならアーキテクチャがモデル非依存だから。知性はワークフローで複利化、モデルだけじゃない。**

ここから始める

今日全5プロンプトを実装しようとしない。それがシステムが死ぬ方法。

**実際のシーケンス:**

• Week 1: Auditプロンプト実行。トップ4自動化ターゲット特定。最も簡単なものを自動化。
• Week 2: 2番目ターゲットでArchitectプロンプト実行。構築。
• Week 3: Week 1-2で構築したものをAnalystプロンプトでレビュー。壊れてるものを修正。
• Week 4: 最も重要な出力でRefineryを実行。品質ジャンプを見る。
• Week 5: Compounderを実行。全てをレビュー。次月を計画。

**週1つのものを自動化すれば、3ヶ月で12ワークフローが稼働。** これを読んでるほとんどの人はブックマークして決して始めない。今夜Prompt 1を実行する人は3月までにワークロードと完全に異なる関係を持つ。

プロンプトをコピー。基準をあなたの実際の仕事にカスタマイズ。より良いものを保持、そうでないものを無視。

**それが全システム。**

P.S. もっとAI tipsとワークフローを見たいなら、無料ニュースレター購読はこちら。

---

活用ポイント

🎯 誰に刺さるか

• **AI疲れを感じてる人**: プロンプトコレクション地獄から脱出したい
• **結果が出てない人**: 個別プロンプトで満足してて蓄積がない
• **エンジニア/PM**: システム思考、複利化の考え方が刺さる

🔧 実装のキー

1. **週次進行が重要**: 一度に全部やらない

2. **カスタマイズ必須**: 各プロンプトの基準を自分の仕事に合わせる

3. **ループを意識**: 各プロンプトが次を改善する設計を理解

🚀 Vibe Coder Bootcampへの応用

• **Week 1-5のカリキュラム**: このシステムそのまま教えられる
• **成果の可視化**: 「12週で12ワークフロー」は明確なゴール
• **プロンプト資産**: 5つのプロンプトはそのまま教材になる

---

関連リンク

• [God of Prompt ニュースレター](https://godofprompt.beehiiv.com)