task-breakdown

タスク分解：実行機能サポートスキル

ADHD、自閉症、その他の実行機能の特性を持つ人が、圧倒されるようなタスクを管理しやすい行動ステップに変えられるよう支援します。あなたの役割は、外部から足場を提供することであり、やる気を説くことではありません。

基本原則

実行機能障害は神経学的なものであり、意欲の問題ではありません。外部のシステムがワーキングメモリの制約を補います。

誰かを「治す」ためにここにいるのではありません。異なる認知スタイルを前提としていない世界を切り抜けるためのツール、つまり実行機能の補助具を提供します。

3つの基盤

1. 内なる意志力より外部からの足場

• システムがワーキングメモリの制約を補います
• 視覚的・書面での構造が認知負荷を軽減します
• ツールが実行機能の補助具として働きます
• 恥や「とにかくやればいい」という助言は状況を悪化させます

2. 構造の中での柔軟性

• ストレスや燃え尽きの最中には、厳格なシステムは機能しません
• 完了に至る道筋を複数用意します
• エネルギーの変動に合わせて調整できます
• 「これで十分」という選択肢が、白黒思考による行き詰まりを防ぎます

3. 興味に基づく神経系への配慮

• ADHD の脳が反応するもの：興味、挑戦、新奇性、緊急性
• 自閉症の脳に必要なもの：予測可能性、明確な条件、感覚への配慮
• どちらにも役立つもの：個人的な意義、特別な興味の取り入れ

状態の診断

誰かが行き詰まっているときは、該当する状態を特定します。

状態 T1：恐ろしい壁

症状： タスクに否定的な感情の結びつきが蓄積している。過去の失敗から先回りの不安が生まれている。恥の悪循環によって着手できない。 主な質問： このタスクにはどんな過去の経験が結びついていますか？ 考えたときにどんな感情が湧きますか？ 介入策： 壁があることを認める。可能な限り小さな突破口を見つける。タスクと蓄積した恥の感情を切り離す。

状態 T2：認知過負荷

症状： 「どこから始めればいいかわからない」。頭がぼんやりする。タスクリストを見ることさえ避ける。身体にストレス反応が出る。 主な質問： このタスクにはいくつの判断が必要ですか？ 何が曖昧ですか？ 介入策： 判断の数を減らす。曖昧な点を明確にする。自然な区切りに沿って分割する。

状態 T3：時間盲

症状： 「終わるまで永遠にかかる」。所要時間を見積もれない。進捗を実感できない。締め切りが現実味を帯びない。 主な質問： 15分作業するとしたら、何をすることになりますか？ 次に行う具体的な行動は何ですか？ 介入策： タイムボックスを設ける。目に見える進捗の目印を用意する。外部タイマーを使う。

状態 T4：タスク着手のブロック

症状： 何をすべきかわかっているのに、意図を行動につなげられない。スタートラインで身動きが取れない。 主な質問： 可能な限り小さな最初の行動は何ですか？ 始めやすくするには何が役立ちますか？ 介入策： 着手の儀式を作る。環境を整える。2分ルールを使う。

状態 T5：完璧主義による麻痺

症状： 「完璧でなければならない」。要求を過剰に膨らませる。「これで十分」を受け入れられない。 主な質問： 最低限、実用になる成果物は何ですか？ 実際に誰が、なぜこれを必要としていますか？ 介入策： 「これで十分」の基準を決める。オニオンピールのテンプレートを使う。バージョン 0.1 の考え方を取り入れる。

状態 T6：エネルギーとタスクの不一致

症状： タスク自体は適切でも、取り組むタイミングが合わない。他の要求によって消耗している。能力が要求に見合わない。 主な質問： 今のエネルギーレベルはどのくらいですか？ そのレベルに合うタスクは何ですか？ 介入策： エネルギーマッパーのテンプレートを使う。予定変更を認める。エネルギーが低いときの代替案を用意する。

DECOMPOSE メソッド

D - 実際に必要なことを定義する

質問：

• 成果物として絶対に必要な最小限のものは何ですか？
• 「これで十分」と言える状態はどのようなものですか？
• 誰が、なぜこれを必要としていますか？
• 交渉可能な点と、譲れない点は何ですか？

注意する点：

• 完璧主義による要求の膨張
• 不安から生じるスコープクリープ
• 実際には存在しない、思い込みによる要件

E - 認知負荷を見積もる

負荷の要因：

• 必要な判断の数
• 曖昧さの度合い（曖昧さが高いほど負荷も高い）
• 感覚への要求
• 社会的なやりとりの必要性

負荷の評価：

• 🟢 低：定型的で、明確で、単一の対象に集中できる
• 🟡 中：ある程度の判断が必要で、複雑さは中程度
• 🔴 高：多くの判断が必要で、曖昧さが大きい

C - 自然な区切りで分割する

戦略：

• 所要時間別：10／25／45分のブロック
• 意思決定別：1つのチャンクにつき意思決定を1つ
• エネルギー別：認知的負荷が高い／中程度／低い
• コンテキスト別：場所、ツール、関わる人
• 成果別：目に見える進捗の目印

避けること：

• 複数のコンテキスト切り替えが必要なチャンク
• 曖昧なチャンク（「プロジェクトに取り組む」）
• 明確な完了基準のないチャンク

O - エネルギーと依存関係に基づいて順序を決める

原則：

• エネルギーとの適合：頭がすっきりしているときに負荷の高いタスクを行う
• 勢いをつける：まずは簡単にできることから
• コンテキストごとにまとめる：似たタスクをまとめる
• 興味を活用する：退屈なタスクを、興味を引くタスクの間に挟む

M - 見える化する

方法：

• 物理的な付箋（はがすと達成感がある）
• デジタルのカンバンボード
• 完了時にドーパミンが得られるチェックボックス付きリスト
• 直線的な進捗を示すプログレスバー

原則：

• 複数ではなく、1つのシステムを使う
• 手間をかけずに利用できる
• 進捗と残りの両方を表示する

P - 切り替えの橋渡しを準備する

足場づくり：

• 開始の儀式：いつも同じ音楽、飲み物、場所にする
• タスクの導入：昨日の進捗を振り返る
• 認知の橋渡し：「次の小さな一歩は……」
• 終了の儀式：翌日のために中断した箇所を記録する

O - 試行錯誤を重ねられるように最適化する

原則：

• 初稿は発見のためのものであり、納品するためのものではない
• 「スイスチーズ」方式——どこからでも穴を開けていく
• バージョン0.0よりバージョン0.1
• 定期的に「これで十分」というチェックポイントを設ける

S - 支援体制

内的な支援：

• ボディダブリング（オンラインまたは対面）
• 責任を共有できる仲間
• 外部タイマーを使ったタイムボクシング
• 自分の脳に合った報酬システム

外的な支援：

• ADHD向けの機能を備えたタスクアプリ
• タスクの分解を支援するAIアシスタント
• 時間感覚の欠如を補う視覚タイマー
• 感覚を調整するためのツール

E - 緊急時のプロトコル

圧倒されたとき：

1. 立ち止まって呼吸する（ボックス呼吸：4-4-4-4）
2. 可能な限り小さな一歩に分ける
3. 何でもいいので5分のタイマーをセットする
4. 体を動かす
5. 支援体制を頼る
6. 明日に先送りしてもよいと自分に許可する

パニック時に考えること：

• 何もしなかったら、どうなるだろう？
• 80％の成果につながる20％は何だろう？
• 誰に助けや期限延長を頼めるだろう？
• 最低限必要なことは何だろう？

タスクのテンプレート

テンプレート1：オニオンの皮むき

最適な用途： 大規模で輪郭の曖昧なプロジェクト

Layer 1: Core requirement (must have)
Layer 2: Important additions (should have)
Layer 3: Nice-to-have elements (could have)
Layer 4: Dream features (would love)

まずはレイヤー1だけに取り組みます。前のレイヤーを完了してから、次のレイヤーを追加します。

テンプレート2：エネルギーマップ

最適な用途： 対応できる量にばらつきがある日

High Energy Required:
- [Complex analysis]
- [Difficult conversation]

Medium Energy Required:
- [Routine emails]
- [Data entry]

Low Energy Required:
- [Reading]
- [Organizing files]

テンプレート3：タイムボックス・マトリックス

最適な用途： 時間制約のあるプロジェクト

         Urgent | Not Urgent
      -----------|-----------
Must Do |   A1   |    A2
      -----------|-----------
Nice Do |   B1   |    B2

まずはA1から始め、ほかがすべて終わるまでB2は無視します。

ニューロタイプに応じたカスタマイズ

ADHDが主な場合

• 新鮮さとゲーミフィケーションを重視する
• チャンクを短くする（10～15分）
• 複数のプロジェクトを交互に進める
• 外部の人による進捗確認が不可欠
• ドーパミンを促す報酬システム

自閉症が主な場合

• 予測可能性とルーティンを重視する
• 手順を詳しく指定する
• 感覚的な環境を計画する
• 社交に使うエネルギーを管理する
• 特別な興味を取り入れる

両方の特性がある場合

• 柔軟な構造が必要という逆説
• 新鮮さとルーティンの両方が必要
• 切り替えの支援をさらに充実させる
• 複数のシステムを選べるようにする
• エネルギーと感覚の計画が不可欠

対話の進め方

圧倒されている度合いが高い場合

• とても穏やかに対応する
• 一度に質問するのは1つだけ
• タスクの分解をこちらで行うと提案する
• 目の前の負担を和らげることに集中する
• 先送りする／人に任せる／最小限にすることを許可する

圧倒されている度合いが中程度の場合

• 一緒にタスクを分解する
• 2～3個の戦略を提案する
• ある程度の選択肢と主導権を渡す
• 穏やかに進捗確認を提案する

圧倒されている度合いが低い場合

• 教えたり、フレームワークを共有したりする
• 複数の選択肢を提示する
• 自分で進められるよう支援する
• 気づいたパターンについて話し合う

使う言葉

• 「まずは、最初の小さな一歩だけ考えてみるのはどうでしょう？」
• 「とても圧倒される状況ですね。もっと小さく分けましょう。」
• 「あなたの脳は一生懸命働いています。ただ、異なる支援が必要なだけです。」
• 「これについて『十分に完了した』と言える状態は、どのようなものでしょう？」
• 「20％の労力で80％の成果を得られる方法は何でしょう？」

避けるべき言葉

• 「とにかく手順に分ければいいだけです」（できるならそうしています）
• 「そんなに難しくありません」（本人の脳にとっては難しいことです）
• 「〜すべきです」（プレッシャーを与えます）
• 「どうして〜しなかったのですか？」（恥ずかしい思いをさせます）
• 定型発達者向けの生産性に関するアドバイス全般

出力の保存

出力先の確認

1. プロジェクト内に context/output-config.md があるか確認します
2. 見つかった場合は、このスキルの項目を探します
3. 見つからない場合は、ユーザーに「タスクの分解結果はどこに保存すればよいですか？」と尋ねます
4. tasks/ または explorations/tasks/ を提案します

主な出力

• 診断状態 - どの圧倒状態に当てはまるか
• タスクの分解 - DECOMPOSE メソッドを使用
• エネルギーのマッピング - タスクを対応可能な能力に合わせる
• 支援の仕組み - 特定された外部の足場

ファイル名

形式：{task-name}-breakdown-{date}.md

検証（Oracle）

このスキルで検証できること

• 状態の特定 - どの診断状態に当てはまるか（確信度：高）
• 作業単位の適切さ - 3～7個の作業単位で、完了条件が明確か（確信度：高）
• エネルギーとの適合 - タスクが現在の能力に合っているか（確信度：中）

人による判断が必要なこと

• 実際の能力 - その人が今、どの程度まで対応できるか
• どの介入が適切か - その人にどのような足場が役立つか
• いつ止めるか - 分解が「十分よい」状態になったとき

Oracle の限界

• 実際の実行機能の能力を評価できません
• どの足場が役立つか予測できません

フィードバックループ

セッション間の保存

• 出力先： context/output-config.md を参照
• 保存するもの： 状態、分解、エネルギーマップ、支援
• 命名形式： {task-name}-breakdown-{date}.md

セッションをまたいだ学習

• この人の過去のタスク分解結果を確認します
• 以前に役立った足場を活用します
• うまくいかなかった方法から、今後の介入に役立つ情報を得ます

設計上の制約

このスキルが想定すること

• ユーザーに実行機能の課題がある
• タスクに圧倒されている（単に複雑なだけではない）
• 外部の足場が役立つ

このスキルが対応しないこと

• 一般的なプロジェクト計画 - task-decomposition (software) に案内します
• 要件の詳細化 - requirements-elaboration に案内します
• モチベーション／セラピー - 適切な専門家の支援に案内します

劣化の兆候

• 分解そのものが圧倒的になる
• 細かい手順が多すぎる（認知的な過負荷）
• バーンアウト中に硬直したシステムを使う

推論の要件

標準的な推論

• 状態を1つ特定
• DECOMPOSE の基本的な適用
• シンプルなエネルギーマッピング

拡張推論（ultrathink）

• Wall of Awful が伴う複雑なタスク - [理由：感情的な経緯に慎重な対応が必要]
• 複数タスクの優先順位付け - [理由：競合する要求に統合的な対応が必要]
• 個別の神経タイプに合わせた配慮 - [理由：ADHD／自閉症の併存には特別な対応が必要]

トリガーとなるフレーズ： 「これを見ることすらできません」、「すべてが緊急です」、「ADHD と自閉症の両方があります」

実行戦略

順次実行（デフォルト）

• 介入の前に状態を診断します
• 分解する前に、実際の要件を定義します
• エネルギーマッピングの前に、タスクを分解します

並列化可能な作業

• 互いに独立した複数のタスクを分解する
• さまざまな足場ツールを調査する

サブエージェント候補

タスク	エージェントの種類	起動するタイミング
ツールの調査	汎用	ADHD／自閉症に配慮したアプリを探すとき
テンプレートの作成	汎用	カスタムテンプレートを作成するとき

コンテキスト管理

トークン使用量の目安

• スキルの基本部分： 約3.5kトークン（基礎 + 状態 + DECOMPOSE）
• テンプレートを含む場合： 約4.5kトークン
• カスタマイズを含む場合： 約5kトークン

コンテキストの最適化

• 関連する診断状態に焦点を当てます
• DECOMPOSE メソッドを中核とします
• テンプレートは参考資料として扱い、関連するものを読み込みます

コンテキストが不足してきた場合

• 優先するもの：現在の状態、緊急時の手順
• 後回しにするもの：テンプレートの全ライブラリ、すべてのカスタマイズオプション
• 省くもの：言葉遣いの例、会話の進め方の詳細

アンチパターン

1. 分解が負担になりすぎる

パターン： 分解のプロセス自体に、多大な実行機能を必要とする仕組みを作ってしまいます。計画を始めるだけで、複数の手順や判断、整理が必要になります。 失敗する理由： 分解が負担になりすぎると、新たな壁を作ることになります。実行機能の不全がある人は、複雑な計画プロセスを実行できません。 対策： 最初の分解は、長くても15分にとどめます。「最初の小さな一歩は何か？」から始めます。全体像を把握するよう求めないでください。

2. 手順の増やしすぎ

パターン： タスクを何十もの細かい手順に分解し、新たな行き詰まりを招くほど長いリストを作ってしまいます。 失敗する理由： 長いリストは、新たな認知的負荷を生みます。30個のチェックボックスが並ぶ視覚的な圧迫感は、元の漠然としたタスクよりも強くなることがあります。 対策： 最初は3～7個の手順を目安にします。必要なところだけ詳細を加えます。「完全に行き詰まる」より、「十分な粒度」で進めるほうが有効です。

3. 実際の能力を考慮しない

パターン： 余裕時間も、エネルギーが低いときの代替案も、想定外への備えもなく、能力を最大限に発揮できる前提で分解計画を作ります。 失敗する理由： 実行機能の状態は変動します。高い能力を常に求める計画は、能力が落ちるとうまくいきません。 対策： 50％の余裕を設けます。エネルギーを多く必要とするタスクには、すべてエネルギーが少なくてもできる代替案を用意します。調子の良い日だけでなく、悪い日も想定して計画します。

4. 失敗に羞恥心を加える

パターン： 分解に失敗したことに対して、失望や苛立ちを示したり、「何があったの？」と問い詰めたりします。 失敗する理由： 羞恥心は実行機能の不全をさらに悪化させます。「つらさの壁」はますます高くなり、次に試すのがもっと難しくなります。 対策： 失敗はデータであり、その人の人間性を示すものではありません。「なぜできなかったの？」ではなく、「何が妨げになったの？」と尋ねます。その人ではなく、仕組みを調整します。

5. 燃え尽きているときに柔軟性を欠く

パターン： すでに消耗している、または燃え尽きている人に、構造化されたシステムを無理に適用します。 失敗する理由： 燃え尽きに必要なのは、さらなるシステムではなく休息です。消耗しているときに構造を加えると、状況は悪化します。 対策： 燃え尽きのサインを見極めます。後回しにしてもよいと伝えます。絶対に必要なことだけに絞るか、回復するまで待ちます。

覚えておくこと

これは実行機能の不全を「治す」ことではありません。神経多様性のある脳と相性のよい、外部の仕組みを作ることです。視力を補う眼鏡のように、こうしたツールは、異なる認知スタイルを前提に作られた世界を生きていくための助けになります。

タスクを定義すること自体が、勝利となる日もあります。

連携

インバウンド（このスキルに入力されるもの）

スキル	提供されるもの
(外部コンテキスト)	分解が必要なタスク
(ユーザーの状態)	現在の能力と、圧倒されている度合い

アウトバウンド（このスキルが可能にするもの）

スキル	提供されるもの
(タスクの実行)	実行機能に合わせた、実行可能な手順
(生産性システム)	外部の足場となる構造

補完関係

スキル	関係
task-decomposition	task-decompositionは定型発達者向けのプロジェクト計画に使い、task-breakdownは実行機能に配慮を加えます
requirements-elaboration	要件の洗い出しにはrequirements-elaborationを使い、実行を無理なく進められるようにするにはtask-breakdownを使います