リダイレクト

矛盾する要求、ツールの障害、競合する制約を、入ってくる圧力に抵抗するのではなく融合し、その力を生産的な解決に向けてリダイレクトすることで対処する。

使用タイミング

• 矛盾する指示を受けた場合（ユーザーはXと言い、プロジェクトドキュメントはYと言い、ツール結果はZを示す）
• 計画したアプローチが実行不能になるツール障害の連鎖
• 要求された範囲を超えてタスクを拡大するスコープ圧力
• 競合する信号が多すぎてパラリシスを生むコンテキスト過負荷
• 吸収すべきユーザーのフラストレーションや修正

• center

  がバランスを不安定にする圧力を明らかにした場合

入力

• 必須: 対処すべき特定の圧力または矛盾（コンテキストから暗黙的に利用可能）
• 任意: 圧力タイプの分類（ステップ1の分類体系参照）
• 任意: この圧力を処理する以前の試みとその結果

手順

ステップ1: 接触前にセンタリングする

いかなる矛盾に関わる前にセンターを確立する（

center

参照）。次に入ってくる圧力を明確に特定する。

AI圧力タイプの分類体系：
┌─────────────────────────┬──────────────────────────────────────────┐
│ 圧力タイプ              │ 特徴                                     │
├─────────────────────────┼──────────────────────────────────────────┤
│ 矛盾する                │ 2つの有効なソースが両立しない指示を       │
│ 要件                    │ 与える。どちらも単純に間違いではない。     │
│                         │ 解決には選択ではなく統合が必要             │
├─────────────────────────┼──────────────────────────────────────────┤
│ ツール障害の             │ 計画したアプローチがツールレベルで         │
│ 連鎖                    │ 失敗する。リトライしても無駄。障害         │
│                         │ データ自体に有用な情報が含まれる           │
├─────────────────────────┼──────────────────────────────────────────┤
│ スコープ                │ タスクが静かに拡大する。各追加は           │
│ クリープ                │ 個別には妥当に見えるが、合計すると         │
│                         │ 要求された範囲を超える                     │
├─────────────────────────┼──────────────────────────────────────────┤
│ コンテキスト             │ ファイルが多すぎ、制約が多すぎ、           │
│ 過負荷                  │ 開いたスレッドが多すぎる。入力不足         │
│                         │ ではなく過剰な入力からのパラリシス         │
├─────────────────────────┼──────────────────────────────────────────┤
│ 曖昧さ                  │ リクエストが本当に不明確で、複数の         │
│                         │ 解釈が有効。行動は誤った問題を             │
│                         │ 解決するリスクがある                       │
├─────────────────────────┼──────────────────────────────────────────┤
│ ユーザー修正             │ ユーザーが現在のアプローチが間違い         │
│                         │ であることを示す。修正には情報と           │
│                         │ 感情的重みの両方が含まれる                 │
└─────────────────────────┴──────────────────────────────────────────┘

現在の圧力を分類する。複数の圧力が活性化している場合、主要なものを特定する — それを最初に対処する；二次的圧力はしばしば副作用として解決される。

期待結果： 現在のコンテキストにおける圧力タイプとその具体的な現れの明確な分類。分類は正確に感じられるべきで、分類体系に無理やり当てはめるべきではない。

失敗時： 圧力がどのカテゴリーにも当てはまらない場合、複合的かもしれない。分解する：どの部分が矛盾か？どの部分がスコープか？複合的なものへの対処は、全体を一つの問題として扱うのではなく、各コンポーネントに対処する必要がある。

ステップ2: 入身（イリミ） — 力に入る

問題に向かって動く。最小化、受け流し、即座の解決策の提案なしに、その全体の範囲を述べる。

1. 圧力を完全に表現する：正確に何が矛盾しているか？正確に何が失敗したか？正確に何が曖昧か？
2. 結果を名指しする：この圧力に対処しなければどうなるか？
3. 圧力が明らかにするものを特定する：ツールの障害は前提を明らかにし、矛盾は欠落したコンテキストを明らかにし、スコーププリープは不明確な境界を明らかにする

テスト: 問題の説明が安心させるように聞こえるなら、入っているのではなく受け流している。入身は困難との完全な接触を必要とする。

• 受け流し：「これら2つのファイル間にわずかな不整合がある。」
• 入る：「CLAUDE.mdは150のスキルを指定しているが、レジストリには148が含まれている。カウントが間違っているか、レジストリが不完全か、2つのスキルがカウントを更新せずに削除された。すべての下流参照が影響を受ける可能性がある。」

期待結果： 問題の完全で臆することのない表明。表明は問題をより現実的に、より少なくではなく、感じさせるべき。

失敗時： 問題に入ることが不安や即座に解決したい衝動を生む場合、止まる。入身は入ることであり、反応ではない。目的は動く前に問題を明確に見ること。同じ文で問題を述べながら解決策を提案せずにいられない場合、明示的に分離する。

ステップ3: 転換（テンカン） — 回転してリダイレクト

力に入った後、解決に向けてリダイレクトするために方向転換する。各圧力タイプには特徴的なリダイレクトがある。

圧力タイプ別リダイレクトパターン：
┌─────────────────────────┬──────────────────────────────────────────┐
│ 圧力タイプ              │ リダイレクトパターン                       │
├─────────────────────────┼──────────────────────────────────────────┤
│ 矛盾する                │ 根底にある意図を統合する：両方のソースは   │
│ 要件                    │ 目的を持つ。共有する目標は何か？           │
│                         │ どちらのソース単独からでもなく、共有目標    │
│                         │ から構築する                               │
├─────────────────────────┼──────────────────────────────────────────┤
│ ツール障害の             │ 障害データを使用する：エラーは前提について │
│ 連鎖                    │ 何を明らかにしたか？障害は情報である。     │
│                         │ 障害が教えたことを取り入れて、ツールや     │
│                         │ アプローチを切り替える                     │
├─────────────────────────┼──────────────────────────────────────────┤
│ スコープ                │ 本質に分解する：元のリクエストは何だった   │
│ クリープ                │ か？それを満たす最小限は何か？黙って       │
│                         │ 吸収するのではなく、追加を明示的に         │
│                         │ 延期する                                   │
├─────────────────────────┼──────────────────────────────────────────┤
│ コンテキスト             │ トリアージと順序付け：どの情報が今必要     │
│ 過負荷                  │ vs. 後で vs. 決して不要か？即座の次の      │
│                         │ ステップへの関連性でランク付け             │
├─────────────────────────┼──────────────────────────────────────────┤
│ 曖昧さ                  │ 曖昧さをユーザーに提示する：「2つの解釈   │
│                         │ が見えます — AとB。どちらを意味しますか？」│
│                         │ 質問が可能な場合は推測しない               │
├─────────────────────────┼──────────────────────────────────────────┤
│ ユーザー修正             │ 修正を完全に吸収する：何が間違っていたか、 │
│                         │ なぜ間違っていたか、正しい方向はどのように │
│                         │ 見えるか？その後、防御的にならず過度な     │
│                         │ 謝罪もなく調整する                         │
└─────────────────────────┴──────────────────────────────────────────┘

適切なリダイレクトを適用する。リダイレクトは問題のエネルギーをそれと戦うのではなく利用する感覚であるべき。

期待結果： 圧力が障害から方向に変換される。矛盾は統合の機会になる。障害は診断データになる。過負荷は優先順位付けの練習になる。

失敗時： リダイレクトが不自然に感じられたり圧力を解決しない場合、ステップ1の分類が間違っている可能性がある。再検討する：これは本当に矛盾か、それとも一方のソースが単に古いだけか？これは本当にスコープクリープか、それとも拡大されたスコープが実際にユーザーが必要としているものか？誤った分類は誤ったリダイレクトにつながる。

ステップ4: 受身（ウケミ） — 優雅な回復

時にはリダイレクトが失敗する。圧力は本物であり変換できない。受身は安全に転ぶ技術 — 破局的にならずに限界を認める。

1. 限界を正直に認める：「利用可能な情報ではこの矛盾を解決できません」または「このアプローチはブロックされており、代替案が見えません」
2. 存在する進捗を保存する：達成されたこと、学んだこと、残っていることを要約する
3. 状況をユーザーに伝える：問題は何か、何が試されたか、前進するために何が必要か
4. 回復パスを特定する：何がこれをアンブロックするか？より多くの情報？異なるアプローチ？ユーザーの判断？

受身の回復チェックリスト：
┌─────────────────────────┬──────────────────────────────────────────┐
│ 保存                    │ 進捗と学びを要約する                       │
│ 認める                  │ 言い訳なしに限界を述べる                   │
│ 伝える                  │ ユーザーに何が必要かを伝える               │
│ 回復                    │ 具体的なアンブロック行動を特定する         │
└─────────────────────────┴──────────────────────────────────────────┘

期待結果： 信頼を維持する優雅な認知。ユーザーは何が起こったか、何が試されたか、何が必要かを知っている。情報は失われない。

失敗時： 限界を認めることがコミュニケーションではなく失敗のように感じる場合、エゴのシグナルに注目する。受身はスキルであり弱さではない。正直な「行き詰まっています」に続く明確な助けの要求は、新しい問題を生む無理な解決策よりも有用。

ステップ5: 乱取り（ランドリ） — 複数の同時圧力

複数の圧力が同時に到来する場合（ユーザー修正 + ツール障害 + スコープの質問）、乱取りの原則を適用する。

1. 凍結しない: 一つの圧力を選んで対処する。どんな動きもパラリシスよりまし
2. 圧力を互いに利用する: ツール障害がスコープの質問を解決できる（「その機能はこの方法では実装できないので、スコープは自然に縮小する」）
3. 圧力下ではシンプルな技法: 圧倒された場合、最もシンプルなリダイレクトにデフォルトする — 各圧力を認識し、緊急度で優先順位付け、順次対処
4. 意識を維持: 一つの圧力に対処しながら、他を周辺視野に保つ。最も緊急なものを最初に対処するが、残りを見失わない

期待結果： 複数の圧力にもかかわらず前進する動き。すべての圧力の完全な同時解決ではなく、進捗を維持する順次的な処理。

失敗時： 複数の圧力がパラリシスを生む場合、すべてを明示的にリストし、緊急度で番号を付ける。1番に対処する。始めるだけでパラリシスが解消される。すべての圧力が等しく緊急に見える場合、最もシンプルな解決のものを最初に選ぶ — 迅速な勝利が勢いを生む。

ステップ6: 残心（ザンシン） — 解決後の継続的意識

圧力をリダイレクトした後、二次的影響に対する意識を維持する。

1. リダイレクトが新しい圧力を生んだか？（例：一方の解釈を選んで矛盾を解決することで、以前の作業が無効になるかもしれない）
2. リダイレクトは根本的ニーズを満たしたか、それとも表面的な症状だけか？
3. 解決は安定しているか、それとも同じ圧力が再発するか？
4. 将来の参考のためにリダイレクトパターンを記録する — この圧力タイプが再発した場合、対応を速くできる

期待結果： 各リダイレクト後の二次的影響の簡潔なスキャン。ほとんどのリダイレクトはクリーンだが、連鎖的な問題を生むものこそ、残心が重要なもの。

失敗時： 二次的影響を見逃し後から表面化した場合、それは残心の実践を深めるシグナル。重要なリダイレクトの後に「これは何を壊したか？」の簡潔な確認を追加する。

バリデーション

• 圧力が曖昧なままではなく、特定のタイプに分類された
• 入身：問題が最小化されずに全体の範囲で述べられた
• 転換：リダイレクトが問題のエネルギーをそれと戦うのではなく利用した
• リダイレクトが失敗した場合、受身が適用された（正直な認知、進捗の保存）
• 複数の同時圧力が凍結ではなく順次的に処理された
• 残心：リダイレクトの二次的影響がチェックされた

よくある落とし穴

• 入るのではなく受け流す: 問題を最小化する（「わずかな不整合です」）ことは、全力が関わらないため効果的なリダイレクトを妨げる。まず入り、次にリダイレクトする
• 合わないリダイレクトを強制する: すべての圧力がその場でリダイレクトできるわけではない。ユーザーの入力、追加情報、または単に待つことが必要なものもある。強制的なリダイレクトは新しい問題を生む
• 受身におけるエゴ: 限界を認める必要を情報交換ではなく個人的失敗として扱う。ユーザーは早く知ることで利益を得る、無理な解決策ではなく
• 二次的圧力を先に対処する: 複数の圧力が存在する場合、簡単なものを先に処理したくなる。これは生産的に感じるが、主要な圧力を増大させたまま残す。最も重要な圧力を対処する、最も快適なものではなく
• センタリングの省略: まずセンターを確立せずにリダイレクトしようとすると、リダイレクションが反応に変わる。センターは任意の準備ではない — 効果的なリダイレクトの基礎

関連スキル

• aikido

  — このスキルがAI推論にマッピングする人間の武術；身体的融合とリダイレクションの原則が認知的圧力処理に情報を与える

• center

  — 効果的なリダイレクトの前提条件；リダイレクションが機能する安定した基盤を確立

• awareness

  — 緊急リダイレクトが必要になる前に圧力を早期検出

• heal

  — 圧力がサブシステムのドリフトを引き起こした場合のより深い回復

• meditate

  — 困難な圧力を処理した後の残留ノイズをクリア