DFB構造化メソッド

DFB が解決したい問題は、たった一つです。「AI 時代に必要な力」が静かに入れ替わったのに、私たちが古い力のまま生きてしまっている——この状態を、思考の道具として整えること ^[2] 。

2024 年まで、知的に働く人に求められた力は 3 つでした。「コミュニケーション力」「PC を使う力」「自分で考える推論力」。 2025 年からは、3 つ目の「自分で考える」が AI に考えさせる『枠』を作る力（= 構造化能力） に置き換わりました。これが 能力のスライド です。

ふと「プロンプトのテクニックを覚えても、これって何のスキルなんだろう？」と虚しくなる。SWOT・3C・ロジックツリーなどのフレームワークを ChatGPT などの LLM（大規模言語モデル）に投げると、3 秒で同じものが返ってくる。 こうした「あれ？」という感覚は、すべて能力のスライドが水面下で進んだ結果です。

マーケティングの世界でも同じ揺れが起きています。これまでの SEO（Google の検索アルゴリズムに合わせて文章を最適化する仕事）は影をひそめ、代わりに LLMO（Large Language Model Optimization・AI に拾わせる最適化） や GEO（Generative Engine Optimization・生成 AI 検索向け）、AEO（Answer Engine Optimization・回答エンジン向け）、AIO（AI Optimization） という新しい単語が浮上しました。 日経クロストレンドの 2026 トレンドマップでこの事実を実証した連載第 1 回が 2026 マーケトレンドマップ DFB 読み解き です。

この「枠を作る力」をパッケージ化したのが DFB です。SWOT・3C・4P・5Force・MECE・IF-THEN・JSON-LD / Schema.org 等の既存フレームを「覚える」のではなく、選ぶ・改造する・作る ための思考プロトコルにあたります ^[2] 。 フレーム集の知識量はもう競争優位になりません。代わりに、未知の課題を前にしたとき「このカオスにはどの枠を当てれば AI が一番うまく処理できるか」を瞬時に判断し、必要なら自分で新しい枠を組む。この一段上の判断力こそが DFB の到達点です。

昔は必要だった「自分で考える推論力」は、AI に取って代わられました。理由はシンプルに 3 つです。速い（人間が 30 分かける推論を AI は 3 秒で出す）/ 安い（人件費比で桁違いに安い）/ 疲れない（24 時間動ける・休日も祝日もない）。 この 3 条件がそろった相手と「考える速度・量・コスト」で勝負しても勝てません。コンサルやプランナーが 30 分かけて出すアウトプットの大半は、適切な前提を与えれば AI が数秒で返す時代に入っています。

勝てる領域として人間に残ったのが、AI に 「正しく考えさせる枠」を作る 仕事。これが本記事の核心命題「推論は AI に、構造化は人間に」です ^[2] 。 AI に何かを頼むとき「もっと具体的に指示してください」と返された経験は誰でも持っているはずです。あの「具体性の壁」こそが、人間が引き受けるべき構造化の領分にあたります。

ここで大事なのは、この話が「プロンプトを上手く書くコツ」のレベルではないこと。短期テクニックではなく、人間の知的労働の中身そのものが書き換わった という大きな変化です。 能力のスライドは、職業の置き換えではなく 職業の中身の置き換え として静かに進行しています。

わかりやすい実例が SEO の消失と LLMO 群の浮上 です。長年マーケターが使ってきた「SEO」という単語が、2026 年のトレンドマップから消えました。代わりに左上に LLMO・GEO・AEO・AIO という新しい島が浮上しています。 やっていること自体は変わっていません。「人間が」「コンテンツを」「最適化する」。変わったのは 最適化の対象が Google から LLM に置き換わったこと だけです。SEO が衰退したのではなく、LLMO 群というより大きな概念に格上げされた——これが能力のスライドの典型例です（詳細は クラスター連載第 1 回 で実証しています）。

「構造化スキル」とひとことで言っても、実はレベルがあります。シュ コウメイは 4 階層に分けて整理しています ^[5] :

• L1 知る — 既存フレーム（SWOT・3C・4P など）を暗記している段階。MBA の教科書を一冊読み終えた人のレベル。
• L2 使い分ける — 「これは SWOT より 5Force だな」と、状況に応じて道具を選べる段階。コンサル新人レベル。
• L3 改造する — カオスに合わせてフレーム自体を改造する。たとえば SWOT の SW に「3 年後の」「現在の」と時間軸を足して 4D-SWOT に組み替えるような動き。コンサル中堅以上が日常的にやっていることです。
• L4 新フレームを作る — 既存のどの枠にも当てはまらない問題に対して、新しいフレーム自体を設計する。DFB そのものを設計するような動きがここ。理論家・経営者のレベルです。

AI が代わりにやってくれるのは L1・L2 まで。L3・L4 を支える「目利き」（抽象度感覚・違和感察知・フレーム改造力）こそが、AI 時代に売れる人間スキルです ^[5] 。

目利きの 3 要素を分解するとこうなります。抽象度感覚（いまの問題を「個人 / 組織 / 業界」のどの粒度で扱うべきかを瞬時に判断する）/ 違和感察知（自分が作った構造に「なんか変だ」と気づける）/ フレーム改造力（既存フレームに「ここに時間軸を足す」「この軸を入れ替える」と手を入れられる）。 この 3 つは、知識の暗記量ではなく 経験の蓄積 で育ちます。だからこそ AI には置き換えられない。本記事のゴールは、読者を L3 の入口 まで連れていくことです。L4 は天才の領域で、無理に目指すものではありません。

DFB は突然出てきた発想ではなく、知的歴史 60 年の延長線上にあります ^[5] 。プログラミングの世界で連綿と積み上げられてきた「構造化」の思想が、AI 時代になって 現実世界そのもの に拡張されたのが DFB です。

この 60 年を貫く思想はシンプルです——「現実世界を、ちょうどよい抽象度でモデル化する」。DFB は、この思想を コードの世界から現実世界全体 へ拡張したものです。

順番に並べるとこうなります。1960 年代の構造化プログラミングが「処理の流れ」を整理し、1980 年代の OOP（オブジェクト指向プログラミング）が「データと振る舞い」を一体化し、1990 年代のデザインパターンが「再利用できる設計」を体系化し、2000 年代の DDD（ドメイン駆動設計）が「業務知識」をコードに反映する形で構造化してきました。これらの上に、DFB は「現実世界の塊そのものを、AI が扱える形に構造化する技法」として乗っています。

プログラマーには「現実世界の OOP 化」として、コンサルタント職には「SWOT を含む上位概念」として腑に落ちる位置取りです。具体的な対応は次の通り:

DFB の本体は、3 ステップの循環構造です ^[1] 。難しい理論ではなく「分けて・枠で見て・組み立てる」の繰り返しです。

• Decompose（分解） — カオスを要素に分ける作業。頭の中でモヤモヤしている塊を、言葉にできる小さな粒まで落とします。「うちの会社の課題」のような大きすぎる塊は、ここで「事実 / 感情 / 影響範囲 / 制約条件」のような扱いやすい粒に分けられます。
• Frame（枠で見る） — どの枠で見るかを選ぶ作業（フレーミング）。同じ要素を、SWOT で見るのか、3C で見るのか、IF-THEN リストで整理するのか、まったく新しい軸を作るのかを判断します。 L3 の目利き が一番効くのがこのフェーズです。
• Build（組み立てる） — 実際に組み立てる作業。選んだ枠に従って要素を再配置し、AI（LLM）が消化できる入力 として組み上げます。AI の出力を人間の経験で検閲し、違和感があれば次のサイクルへ戻ります。

PDCA（業務改善）・OODA（意思決定）と並ぶ思考サイクルですが、DFB は 「AI に渡す」ことに特化 している点が違います ^[1] 。 1 回で完璧に作るのではなく、組み立てた後の 違和感 をきっかけに Decompose に戻る、適応的なプロセス として設計されています。違和感の正体は、たいてい「分解の粒度が荒すぎた」「選んだフレームが現実に合っていない」「重要な要素を見落とした」のどれか。これは 1 サイクル目には見えません。だから DFB は単発の翻訳作業ではなく、回し続ける前提 のサイクルとして組まれています。

3 つのサイクル思考の住み分けを整理するとこうなる:

DFB の最初の一歩は、サイクルを回す前に「依頼そのもの」を構造化する ことです ^[1] 。これは書き手の暴走を止めるための「儀式」のような工程。 やることはシンプルで、ユーザーの依頼文から 主体・動詞・対象・暗黙制約・成果物数 を抜き出し、動詞の数 = 成果物の数 を厳守します。

抜き出す 5 要素は次の通り:

• 主体 — 誰が誰に頼んでいるか
• 動詞（複数）— 何を要求しているか。動詞のみを抜き出す
• 対象 — 動詞の目的語は何か
• 暗黙制約 — 言われていないが守るべきもの。修辞疑問は答えない、背景情報は処理対象外、など
• 成果物数 — 動詞の数だけ

たとえば「この要件を構造化して、別 AI に渡すプロンプトを作成して」という依頼なら、動詞は「構造化する」と「プロンプトを作成する」の 2 つ。成果物も 2 つで止めます。フィージビリティ判定や工数見積もりが依頼に含まれていなければ、それは 絶対に作らない。

これを飛ばすと 失敗パターン G（Over-Delivery / 親切心過剰） が発動し、依頼にない成果物を勝手に足してしまいます。実はこのルール、提唱者本人が「自分が DFB を使えていなかった」自己言及的な失敗から発見されたものです ^[1] 。

発見の経緯はこうです。DFB を実装した直後の検証セッションで、提唱者は「構造化して、プロンプトを作って」という 2 動詞の依頼に対し、フィージビリティ判定・スキル資産マッピング・8 週間工数・リスク Top3・優位性 4 点まで自動的に添えてしまいました。「DFB を使う側」が DFB の最初の一歩を踏んでいなかったのです。このメタ的な自己発見こそが Step -1 を生み出しました。

サイクルを始める前に、必ず「立ち止まって判断する（Stop-Judge）」工程があります。自分に向けて 4 つを声に出して宣言します ^[1] :

• I（Intent layer）— ユーザーは メタ（道具評価）か オブジェクト（道具で実行）か ★最重要
• S（Scope）— L1〜L4 のどこで止めるか
• T（Time）— 何分以内で完結するか
• D（Deliverable）— 何を作って終わりとするか

最重要ルールは 「I を最初に判定しないまま DFB を始めるな」。これを誤ると S/T/D が全部見当外れになります。能力評価系のキーワード（「デモして」「見せて」「試して」「サンプル」「評価したい」）が含まれていれば I = メタ。 それ以外は I = オブジェクト です。

I を取り違える典型例を 5 つ並べます:

メタを「オブジェクト」と取り違えると、デモ依頼に対してフィージビリティ判定・工数・リスクまで添える パターン F（メタ/オブジェクト取り違え） が発動。逆にオブジェクトを「メタ」と取り違えると、実装すべきものを「概念解説」で済ませてしまいます。 S/T/D の判定は I が確定したあとに自然に決まるので、I を最初に声に出して宣言する 習慣が最強の予防策です。

実装は次のフレームに対応します ^{[3] [4]} :

1. Decompose — 6 要素分解（Role 誰として動くか / Task 何をするか・1 文で / Input 渡す素材 / Constraints 守るルール / Output 出力形式 / Examples 見本）。 ここで意識すべきは「全部埋めようとしない」こと。素材がなければ Input は空欄で OK。例がなければ Examples なしで OK。埋めること自体が目的化すると 失敗パターン B（6 要素埋め病） に陥ります。
2. Frame — 5 つの枠から選ぶ。複雑な役割 × 複数指示 × 制約あり なら XML タグ。表で表せるデータ変換なら Markdown 表。条件分岐があれば IF-THEN。構造化データ出力（AI 検索や Schema.org 連携）なら JSON-LD。段階的処理なら 番号付き手順。 単発質問にまで XML タグを巻くのは 失敗パターン D（構造化疲労） 。フレーム選択は「効果に対するコスト」で判断します。
3. Build — XML タグ 7 種で組み立てる。<role> / <task> / <input> / <constraints> / <output_format> / <example> がコアの 6 個、<phase> が段階制御用の拡張タグ。 Decompose の 6 要素と XML タグ 6 個が 1 対 1 で対応 するように設計されているので、Decompose が終われば Build は機械的に埋まります ^[4] 。

Decompose の 6 要素と XML タグは 1 対 1 で対応するように設計されている のがこのメソッドの特徴で、構造化が綺麗に揃います ^[4] 。これは偶然ではなく、Decompose を「そのまま Build に渡せる単位」で行うことで、サイクル中の翻訳コストをゼロにするための設計判断です。実務的には、Decompose の段階で何を分けるかが、Build の品質の 8 割を決めます。

なお、Schema.org の JSON-LD は LLMO / GEO / AEO / AIO の対策とも親和性が高く、本記事自体も Article + HowTo + FAQPage の JSON-LD を埋め込んでいます（AI 検索エンジンに「何の記事か」を構造化して伝えるため）。

基本 DFB の上に、シーン別の 5 派生が乗っています ^[1] 。それぞれ「いつ呼び出すか」「典型シーン」がはっきり決まっています:

• DFB-Q（Question 型・質問先行）— 入力に不明点が多すぎて、即構造化すると間違える時。 先に AI（または自分）に質問を生成させ、回答を得てから Decompose に入る。例: 先方から「サイト作って」とだけ来た要件依頼。
• DFB-S（Stop 型・強制停止）— 境界を明示的に守りたい時の基本形。 Stop-Judge の I/S/T/D を最初に宣言し、それを越えそうになったら強制停止。例: 受講者が「ちょっと聞いただけ」のときに講師が深掘りしすぎないように。
• DFB-I（Iterate 型・反復明示）— 1 サイクルでは精度が出ないとき、明示的に複数サイクル回す。 Decompose A（粗）→ Frame → Build → 違和感察知 → Decompose B（細）→ Frame → Build。例: 複雑な業務カオスを段階的に解きほぐす。
• DFB-M（Meta 型・自己言及）— DFB そのものを DFB で構造化する。教える側のスキル。 Decompose（DFB の構成要素）→ Frame（教えやすい枠）→ Build（カリキュラム）。例: 講座設計・スキル伝承・DFB 自体の改善。
• DFB-R（Reverse 型・逆構造化）— 既に構造化されたものを解体し、別の抽象度で再構造化する。 De-build → De-frame → De-decompose → Decompose（別軸）→ Frame → Build。例: 既存の SWOT を「時間軸を入れた 4D-SWOT」に拡張する。

5 つは排他ではなく、現場では複数を入れ子で使うことが多いです。たとえば DFB-Q で要件を引き出し → DFB-S で境界を引き → DFB-I で反復する、といった重ね方になります。バリエーションを「使い分ける」こと自体が L3 の目利き の一部です。

「やってはいけない」を明示することで、 目利き が育ちます ^{[1] [5]} 。9 つのパターンは、依頼受領フェーズ・実行フェーズ・出力フェーズの 3 段階に分布します:

【依頼受領フェーズ】(4 種)

• G: 依頼の未構造化（Over-Delivery） ★最重要 — 動詞にない成果物を親切心で足す。発見の経緯はメタ的に痛烈で、「DFB の提唱者が DFB を使えていなかった」ことから生まれた。動詞数 = 成果物数 を声に出す習慣で防ぐ。
• F: メタ/オブジェクト取り違え／F-chain（連続発動）— ユーザーがメタ評価で話しているのに、オブジェクト実行で応答する。1 回踏むと次のターンで再発しやすい（F-chain）。Step 0 で I を最初に判定するだけで予防できる。
• H: タイムライン盲目 — 直前ターンの失敗や、これまでの議論の流れを取り込み忘れる。「いま自分は何回目のやり取りで、直前で何を踏んだか」を Step -2 として宣言することで予防する。
• E: メタ盲目 — 「これは構造化すべきか？」を問わずに、反射的に DFB を始める。雑談ですら構造化して空気を壊す愚行はここに分類される。

【実行フェーズ】(3 種)

• B: 6要素埋め病 — Decompose の 6 要素を全部埋めようとして本質が薄まる。「今何時？」のプロンプトに役割・制約・出力形式まで足す典型例がこれ。
• C: フレーム原理主義 — 既存フレームに合わない情報を切り捨てる。SWOT に収まらない時系列要因を「対象外」にしてしまう動き。DFB-R（逆構造化）で防ぐ。
• D: 構造化疲労 — 一過性のタスクまで構造化して ROI 割れする。「明日の天気は？」を XML タグで構造化する愚行。入力直後に 5 秒「これを構造化する価値があるか」を問うだけで防げる。

【出力フェーズ】(1 種)

• I: アカデミック疲労 — 構造化された内部ロジックをそのまま出力してしまい、末尾の平易な翻訳（ユーザー説明レイヤー）が欠落する。読み手が疲れる。Step 7 で「ユーザー向けの平易なまとめ」を必ず添える。

※ かつての「A: 抽象度の暴走」は、再診断の結果 誤診断と判明 して削除されました。「L1 指示なのに L4 まで降りた」と当初は理論化していましたが、本質は 抽象度の問題ではなくメタ/オブジェクトの取り違え だったので、パターン F に再定義しました。この「自己訂正の経緯」自体が「失敗を講座素材化する」という発想の源泉になっています ^[5] 。失敗パターン集は他人を裁くためのものではなく、自分の応答を客観視するための道具 として設計されています。

DFB の効果は、誰でも身近な題材「プロンプト最適化」で検証できます ^[3] 。日常的に AI に投げているラフな依頼を、DFB の 3 ステップで再構築すると、出力品質が桁違いに変わります:

• 議事録作成: 「次の会議の議事録を作って」（15 字）→ <role>（議事録作成のプロライター）/ <task>（A4 1 枚以内に変換）/ <input>（文字起こし）/ <constraints>（敬語・固有名詞そのまま）/ <output_format>（会議概要・議題と議論・決定事項・ToDo の 5 セクション仕様）まで構造化（約 500 字）。変化のポイント: AI が「議事録っぽい何か」を返すのではなく、仕様に従った決まった形式で返すようになる。
• 新規事業アイデア出し: 「新規事業のアイデア出して」（14 字）→ Role（新規事業立ち上げ 20 件以上のコンサル）+ 前提条件（自社の強み・初期予算・市場領域・既存事業）+ 制約（既存シナジー・1 年以内に MVP・レッドオーシャン除外）+ 出力（5 案 × 7 軸テーブル + おすすめ TOP1 の理由）（約 450 字）。変化のポイント: 比較可能な評価軸を最初に明示することで、案を並べる時点で判断材料が揃う。
• メール返信案: 「このメールに返信考えて」（15 字）→ Role（ビジネスメール作成補助）+ context（相手・関係性・自分の立場・盛り込み事項）+ output（堅め / 中間 / 柔らかめの 3 トーン案 + 適切案の判断理由）+ constraints（書き出し統一・署名・字数）（約 500 字）。変化のポイント: 1 案ではなく 3 トーン案を出させることで、選ぶ自由と判断材料がついてくる。

共通する設計判断は 3 つです。(1) Role を具体化（経験年数や顧客層まで書く）/ (2) Constraints は禁止形で書く（「〜してください」より「〜しないでください」のほうが効きやすい）/ (3) Output_format をスキーマレベルで指定（あとでプログラム的に処理できる形式に揃える、たとえば JSON-LD や Schema.org 準拠で出力させる）。 この 3 つは Before/After のすべてのサンプルで共通して効いていて、トピックが何であってもプロンプト品質を底上げする最小公倍数のような働きをします。

さらに大きなスケールでの実演として、日経クロストレンドの 2026 マーケトレンドマップ（35 キーワードの散布図）を DFB で読み解いた クラスター連載第 1 回 もあります。SEO 消失と LLMO 群（LLMO / GEO / AEO / AIO）の浮上を「能力のスライド」の実例として実証した記事です。

理論を知っていても、実装で崩れる典型を 7 つ集めました ^[4] 。 失敗パターン 9 種 が「思考の歪み」を扱うのに対し、こちらは「実装の手癖」を扱います。実装時に踏みやすい順に並べました:

1. 単純質問への過剰構造化（→ 失敗パターン D）— 「明日の天気は？」のような単発質問にまで XML タグを巻く。フレーム選択のコストが効果を上回っている時点でアンチパターン。
2. <task> に複数動詞を詰める（→ 失敗パターン B）— 「読んで・要約して・宿題も教えて」のように動詞を散らかすと、AI が優先順位を誤って一部を抜かす。<task> は 1 文・1 動詞に圧縮するのが鉄則。
3. <role> を「AI です」とだけ書く — 役割定義になっていない。経験年数・顧客層・専門領域まで書いて、AI に語彙と視点を固定する。
4. <constraints> に「良い感じに」と書く — 主観的な形容詞は制約ではない。文字数・敬語レベル・禁止事項のように検証可能な形で書く。
5. <example> をフレーム外に書く — 例示を地の文に置くと AI が「見本」と認識しない。必ず <example> タグで囲って渡す。
6. タグの閉じ忘れ — 構文として壊れ、AI が出力をどこまでが入力かを誤解する。コピペ運用では特に起きやすい。
7. 入れ子記述 — <role><task>…</task></role> のように役割の中にタスクを入れない。DFB は並列フラットを推奨する。役割・タスク・入力・制約・出力・例 は同じレイヤーに並ぶ独立要素として扱う。

この 7 つに共通するのは、「フレームを使うこと自体が目的化している」状態です。フレームは出力品質を上げる 手段 であって、整った見た目を作る 目的 ではありません。実装時に「これは効果ある？」と自問する 30 秒の習慣 だけで、ほとんどのアンチパターンは予防できます。

DFB は 1 回学んで終わりではなく、毎日の思考の 型 として体得するものです ^[2] 。記事を読み終えて「分かった」気になるレベルと、実務で反射的に使えるレベルの間には、武道でいう「型稽古」に相当する距離があります。

体得の道筋は、守破離の 3 段階 で進みます:

• 守 — 6 要素分解 / Stop-Judge / XML タグ 7 種を、教科書通りに毎回踏む段階。違和感があっても省略しない。
• 破 — 状況に応じて要素を間引いたり、フレームを改造したりする段階。 L3 の入口 がここ。
• 離 — DFB そのものを使わずに、構造化の本質だけで動ける段階。L4 の領域。

日々の鍛錬は 2 原則 に集約されます:

1. 常に構造化目線で考える — どんな会話・業務でも、「いまの塊は、どの要素で構成されているか？」を問い続ける。
2. 構造化された言葉でアウトプットする — 思考が構造化されていても、出力が散文に戻ると相手に伝わりません。表・箇条書き・段落構造を出力時に意識します。

実用的なトレーニング法として 30 秒トレーニング（目の前のテキスト 1 つを 30 秒だけ Decompose してみる）と、30 日習慣化ロードマップ（Day 1〜30 で段階的に DFB を生活に組み込む工程表）があります。型として体に染み込むまで、毎日少しずつ動かすのが最短経路です。

シュ コウメイは、AI 時代の構造化メソッド「DFB」を 2025 年に提唱した実務家です。 クライアント業務で AI（ChatGPT・Claude などの LLM）を駆動しながら、「AI に正しく仕事をさせる技術」を体系化した独自メソッドとして DFB（Decompose / Frame / Build）を開発しました。

DFB は机上の理論ではなく、現場の実装試行から逆算 して組まれています。プロンプト 1 通の最適化から、社内 AI システム設計、クライアント業務の自動化、ピラー記事構成、講座カリキュラム設計まで、扱う粒度はバラバラ。でも「底に流れる構造化の手順は同じだ」という観察から、DFB という汎用プロトコルが結晶化しました。

自社で運用する LLM Wiki（AI 駆動型ナレッジ管理システム）は、DFB の実証実験そのもの。プロンプトレベルから組織知レベルまで、あらゆる階層で「AI フレンドリーな構造化」（JSON-LD / Schema.org / LLMO / GEO / AEO / AIO を含む）を毎日実践しています ^[2] 。本記事自身も、DFB を使って書かれた DFB の解説、というメタ的な構造を持っています。

DFB を実演した連載第 1 回が 2026 マーケトレンドマップ DFB 読み解き 、入門編が DFB とは — シュ コウメイが提唱する AI 時代の構造化メソッド 、関連論考が AI 時代に『シニア有利』の本質は構造化能力にある です。

提唱者本人の関連発信は次のとおり:Substack「構造化脳」（構造化の最新論考をメール配信）/ストアカ講座（DFB を学べる対面講座）。 DFB は閉じた理論ではなく、現場で使われながら改訂され続けるオープンな実装プロトコルとして運用されている。本記事末尾の「よくある質問」や「関連項目」もその一部にあたる。