SKILL.md: 複雑な設計のための認知システム工学
ライセンス: Apache-2.0
metadata:
name: 認知システム工学 (CSE)
source: "The Role of Cognitive Systems Engineering in the Systems Engineering Design Process"
authors: Militello, Dominguez, Lintern, Klein
version: 1.0
activation_triggers:
- エージェントシステムまたはオーケストレーションアーキテクチャの設計
- システムが失敗した理由やユーザーを失敗させている理由の分析
- AIまたは人間が実行する複雑なタスクの分解
- ドメイン専門家からの要件の引き出し
- 認知作業におけるエラーや予期しない動作への遭遇
- 正しい問題を解決しているかどうかの疑問
- 専門家の判断、意思決定支援、自動化のための設計
- ソリューションが述べられた問題と実際の問題のどちらを解決しているかの評価
このスキルを使用すべき時
以下の場合にこのスキルをロードしてください：
- システムが人間の認知を支援するために設計されている場合 — 意思決定支援、エージェントオーケストレーション、情報システム、専門知識の自動化
- 要件が曖昧で、議論があり、または絶えず変化している場合 — これは、認知的要件が目に見えていないというサインであり、関係者が混乱しているわけではありません
- エラーや障害が発生している場合 — それらをパッチする欠陥としてではなく、設計の前提に関する診断情報として扱います
- 述べられた問題が間違っているように感じられる場合 — ソリューションスペースに実際の答えが含まれていないように思える場合
- 専門知識を捉え、複製し、またはサポートする必要がある場合 — そして専門家が「自分がどのようにそれをしているのかうまく説明できない」場合
- 分散したチームまたはシステムが複雑な認知作業を調整する必要がある場合 — 複数のエージェント、人間、ツール、または組織が認知負荷を共有している場合
- 分析作業の価値が疑問視されている場合 — エンジニアリングの成果物に対して認知的な貢献が目に見えない場合
核となるメンタルモデル
1. 認知的要件は目に見えない
デザイナーがワーカーに必要だと想定するものと、ワーカーが実際に必要とするものは体系的に異なり、そのギャップは計り知れません。熟練した実践者は、暗黙知、知覚的な手がかり、パターン認識、制約認識に基づいて行動し、それらを簡単に言葉にできず、観察だけでは明らかになりません。これらの要件を積極的に掘り起こさない設計プロセスは、架空のワーカー向けに構築されることになります。
含意: 要件の引き出しには、インタビューやサーベイではなく、専門的な方法（認知タスク分析、Critical Decision Method、発話思考プロトコル）を使用する必要があります。この作業の成果物は、機能リストではなく、実際の作業の認知モデルです。
2. エラーは診断情報であり、欠陥ではない
認知システムにおけるエラーは機能不全ではありません。それは、システムの作業モデルが実際の作業の構造からどこで乖離しているかを正確に示すものです。期待される動作と観察される動作の不一致は、デザイナーが利用できる最も情報密度の高いシグナルです。
含意: エージェント、ユーザー、または結合システムが予期しない出力を生成した場合、最初の質問は「このエラーは、私たちの設計前提について何を明らかにしているのか？」であり、「このエラーをどのように排除するか？」ではありません。
3. 設計はパイプラインではなく対話である
順次的な設計モデル（要件→仕様→構築→テスト）は教育学的には便利ですが、運用上は誤りです。複雑な問題に取り組むと、新しい情報が明らかになります。最初に立てた問題文は、最終的に使うべき問題文ではありません。初期の段階で要件を固定しようとすると、複雑な問題が必要とする発見が抑制されます。
含意: イテレーションは計画の失敗ではありません。プロジェクトの途中で問題の枠組みを再検討することは、スコープクリープではなく、プロセスが正しく機能していることの証拠です。明示的な再評価ゲートを組み込みましょう。
4. 問題の枠組み設定が最大の効果を持つ介入である
認知分析が生み出す最も価値のあるものは、多くの場合、問題の言い換えです。つまり、述べられた問題に対するより良い解決策ではなく、述べられた問題が間違っているという証拠です。原子力発電所の事例: 80人以上のスタッフが35人に削減され、新しいテクノロジーはゼロ。単に作業の実際の認知構造を理解しただけです。
含意: どのような解決策を最適化する前に、問題文を検証することに投資しましょう。間違った問題を高品質で解決するコストは、他のほとんどの設計エラーを上回ります。
5. ツールとユーザーのペアではなく、共同認知システム
認知の複雑さは分散システム、つまり、集合的に認知作業を実行する人間、テクノロジー、プロセス、組織構造に存在します。単一のエージェントやツールを単独で設計することはできません。システム全体にわたる調整メカニズム、情報フロー、共有された状況認識こそが、認知の成功または失敗を決定します。
含意: ノードだけでなく、ハンドオフを設計しましょう。コンポーネント間の共有メンタルモデルの要件を指定しましょう。自動化が機能するかどうかだけでなく、自動化が結合システム全体の認知負荷の分散をどのように変えるかを分析しましょう。
意思決定フレームワーク
問題診断
IF システムがエラーや予期しない動作を生成している
THEN ロード: failure-modes-in-complex-cognitive-systems.md
→ 修正を提案する前に障害モードを分類する
→ 質問：これは、自動化の驚き、間違った問題、サイロ化、過剰仕様、またはボトルネックですか？
IF 関係者が要件について意見が合わない、または要件が絶えず変化している
THEN ロード: cognitive-requirements-are-invisible.md
→ 変化は情報です：認知的要件がまだ明示されていません
→ さらなる要件収集の前に、構造化された引き出しを展開する
IF 提案された解決策が間違ったものを解決しているように感じられる
THEN ロード: problem-reframing-as-highest-leverage-intervention.md
→ ソリューション作業を停止し、まず問題の枠組み設定に投資する
→ 現在のソリューションカテゴリを不要にする言い換えを探す
設計プロセス
IF エージェントシステムまたはオーケストレーションアーキテクチャを設計している
THEN ロード: joint-cognitive-systems-distributed-cognition.md AND cse-concept-map-for-agent-architecture.md
→ コンポーネントを設計する前に、完全な結合システムをマッピングする
→ 最初に調整メカニズムと情報フローを設計する
IF 十分な理解なしに要件を確定するよう圧力を受けている
THEN ロード: design-as-dialog-not-pipeline.md
→ 「要件を固定すること」と「現在の最良のモデルを持つこと」を区別する
→ 順次的な固定化の代わりに、明示的な再評価ゲートを提案する
IF 専門家の判断のため、または専門家の判断を中心に設計している
THEN ロード: expertise-recognition-and-tacit-knowledge.md
→ Recognition-Primed Decisionモデルを適用して、専門知識が実際にどのように機能するかを理解する
→ 要件作業における専門家の説明ギャップに備える
評価と価値
IF 認知分析作業の価値が疑問視されている
THEN ロード: value-case-and-invisible-contributions.md
→ パラドックス：優れたCSEの仕事はそれ自体を目に見えなくする（障害の減少、運用の円滑化）
→ インシデント数だけでなく、先行指標を使用する
IF 提案された解決策がテクノロジーやスタッフの追加を伴う
THEN ロード: problem-reframing-as-highest-leverage-intervention.md
→ チェック：作業の正確な認知モデルを使用してこの解決策を検証しましたか？
→ 原子力発電所のベンチマーク：問題の枠組みの再設定により、提案されたリソースの必要性を排除できますか？
参照ファイル
| ファイル | ロードすべき時 |
|---|---|
references/cognitive-requirements-are-invisible.md | 要件が曖昧または議論の余地がある場合、専門家ユーザー向けに設計する場合、要件の引き出しプロセスを開始する場合、ユーザーリサーチ手法が疑問視されている場合 |
references/design-as-dialog-not-pipeline.md | 早期に要件を確定するよう圧力がある場合、反復プロセスが非効率と見なされている場合、プロジェクトが途中で問題文の再検討が必要な場合 |
references/problem-reframing-as-highest-leverage-intervention.md | ソリューションスペースに正しい答えが含まれていないように思える場合、提案された解決策が高価またはミスアライメントに見える場合、実行を一時停止して枠組みを再設定する正当性を説明する必要がある場合 |
references/joint-cognitive-systems-distributed-cognition.md | マルチエージェントまたは人間-機械システムを設計する場合、調整の失敗を分析する場合、自動化が認知負荷分散をどのように変えるかを評価する場合 |
references/expertise-recognition-and-tacit-knowledge.md | 専門家の知識を捉える場合、意思決定支援を設計する場合、専門家の判断を複製または支援するシステムを構築する場合、専門家がどのように作業を行うかを説明できない場合 |
references/failure-modes-in-complex-cognitive-systems.md | システムエラーや予期しない動作を診断する場合、提案された設計のプレモーテムを行う場合、観察された障害に応答する前に分類する場合 |
references/cse-concept-map-for-agent-architecture.md | エージェントシステムの機能をマッピングする場合、コンポーネント間で認知機能を整理する場合、フレームワーク間の用語の混乱を解決する場合 |
references/value-case-and-invisible-contributions.md | 認知分析への投資を正当化する場合、CSEの仕事の価値が疑問視されている場合、主に障害を防止するシステムの成果を測定する場合 |
アンチパターン
これらはCSEが特に警告する障害モードです。早期に認識してください。
1. 想像上のワーカー向けに設計する
専門家が実際にどのように働くかではなく、デザイナーが専門家はこう働くだろうと考える方法に基づいてシステムを構築すること。想像上のワーカーは合理的で、完全な情報を持ち、手順に従い、教科書が言う通りに意思決定を行います。実際のワーカーはこれらを一切行いません。
2. エラーを診断情報ではなく欠陥として扱う
エラーが何を明らかにするかを尋ねずにエラーを修正すること。理解されずに修正されたエラーは、根底にある設計の前提を修正する機会を逃したことであり、問題が別の形で再浮上することを保証します。
3. 認知作業が行われる前に要件を固定する
順次的なプロセスモデルは、早期に要件を固定する圧力を生み出します。認知的に複雑なドメインでは、これは間違ったシステムが効率的に構築されることを保証します。初期の要件固定は規律ではなく、早期の終結です。
4. サイロ化：結合システムの視点なしにコンポーネントを最適化する
周囲の人間やエージェントのワークフローを壊す優れたツールを構築すること。システムパフォーマンスを低下させる局所的な最適化。典型的な例：人間をタスクから解放するが、自動化が失敗したときに状況認識を失うような自動化。
5. 障害分析における後知恵バイアス
インシデントの後、その特定の障害のためにのみ設計すること。事後的な再構築の魅惑的な明瞭さは、障害が実際よりも予測可能に見えるようにし、次の障害ではなく最後の障害に設計のエネルギーを集中させます。
6. 適応能力を排除する過剰仕様
現実がモデルから逸脱したときに実践者が即興で対応できないほど、システムを厳格に設計すること。実際の複雑な作業には適応が必要です。過剰仕様は、柔軟性が最も重要である状況でシステムを脆弱にします。
7. 設計による専門家ボトルネック
単一の専門家（人間またはAI）がすべての重要な決定に必要なゲートウェイとなるシステムを構築すること。その専門家が優秀であっても、これは壊滅的な脆弱性を生み出します。CSEは、専門知識を集中させるのではなく、分散させることを求めています。
識別子
誰かがCSEを本当に内面化したか、それとも要約を読んだだけかを判断する方法：
彼らは「エラーは興味深い」と言う — 「エラーは問題だ」とは言いません。CSEを吸収した人は、障害レポートをクローズすべきチケットとしてではなく、研究の機会として扱います。
彼らは「解決策は何か？」の前に「これは正しい問題か？」と尋ねる — そして、それが目に見える進捗を遅らせても、その質問に真剣な時間を費やすことを厭いません。彼らは原子力発電所の事例を見て、その答えにどれほどの価値があるかを知っています。
彼らは認知分析なしに要件が固定されることに抵抗する — 妨害としてではなく、作業の認知構造を理解する前に要件を固定することが、間違ったものを構築するための特定の、名前の付いた、予測可能な方法であることを理解しているからです。
彼らは結合システムで考える — 障害を分析したり解決策を設計したりするときに、彼らは本能的に「これは完全な認知システムのどこに位置するのか？」と尋ね、「このコンポーネントは何をすべきか？」とは尋ねません。
彼らは暗黙知にコストがかかることを知っている — 彼らは専門家が自分たちが必要とすることを教えてくれるとは期待しません。彼らは専門知識が内省にはほとんどアクセスできないことを内面化しており、それに応じて引き出し方法を計画しています。
彼らは設計の反復的な性質をノイズではなくシグナルとして扱う — プロジェクトの途中で問題文が変わったとき、彼らはそれを管理すべき計画の失敗としてではなく、プロセスが何か現実的なものを明らかにしていると読みます。
彼らは5つの障害モードを挙げることができる — 自動化の驚き、間違った問題文、サイロ化、過剰仕様、専門家ボトルネック — そしてそれらをチェックリストとしてではなく、新しい状況に診断的に適用します。
彼らが言わないこと: 「より良い要件が必要なだけです。」「プロセスを文書化すれば、システムはそれに従うでしょう。」「ユーザーはトレーニングが必要なだけです。」「オペレーターがどのように使用するかとは独立してAIツールを評価できます。」
特定の状況が発生した場合に、オンデマンドで参照ファイルをロードしてください。このファイルでスキルがアクティブになります。より深い分析には参照ファイルが必要です。