クリティカル・インシデント法を組み込む研究アプローチ

作成日: 2026-05-02

位置づけ: 「変化の速い AI を、変化しにくい観察軸で捉える」という上位方針のもとで、クリティカル・インシデント法をどのように研究方法として組み込むかを整理するメモ。

関連: 実践タイプ・対象者・文脈管理の方針は 2026-05-02-cit-sampling-and-context.md、実際の記録フォーマットは 2026-05-02-critical-incident-record-template.md を参照する。

1. このメモの前提

現時点の研究方針では、次の上位方針が立っている。

変化の速い AI を研究として扱うために、AI が入り込んだ実践を観察し、その中で媒介物、ワークフロー、判断・評価の現れ方を手がかりに、変化に耐える観察軸を整理する。

この方針では、AI の最新機能や特定ツールそのものを追うのではなく、AI が制作・開発・研究・設計の実践に入り込んだときに繰り返し現れる構造を見る。

そのとき重要になるのが、判断、評価、違和感、修復が露出する具体的な出来事である。

AI がうまく動いているとき、人間の判断基準や暗黙知は見えにくい。むしろ、出力に対して「なんか違う」と感じたとき、期待とずれたとき、追加の情報を渡したとき、修正指示を出したとき、採用する／しないを決めたときに、普段は暗黙だった評価基準や判断が表に出る。

クリティカル・インシデント法は、このような出来事に焦点を当てる方法として、現在の研究方針と相性がよさそうである。

2. クリティカル・インシデント法の位置づけ

クリティカル・インシデント法は、特定の行動や出来事が結果に影響した場面を想起・記述し、その文脈や行動を分析する質的研究手法である。

この研究では、クリティカル・インシデント法を研究全体の主題にするのではない。あくまで、上位方針である「変化の速い AI を研究として扱うための観察軸を探る」ための、データ収集・分析の焦点化手段として使う。

つまり、位置づけは次のようになる。

上位方針:
  変化の速い AI を、変化しにくい観察軸で捉える

観察対象:
  AI が入り込んだ制作・開発・研究・設計の実践

焦点化の方法:
  判断・評価・違和感・修復が生じたクリティカル・インシデントを記録する

分析軸:
  ワークフロー上の位置
  媒介物
  外部化された目的・制約・評価基準・暗黙知
  人間の介入点

このように見ると、クリティカル・インシデント法は、「媒介物を見る」と「ワークフローを見る」をつなぐ方法になる。

3. なぜ相性がよいのか

3.1 判断や暗黙知は平常時には見えにくい

人間の判断や暗黙知は、普段は明示されないことが多い。特に、制作・開発・研究・設計の実践では、「なんとなくよい」「これは違う」「この文脈では使えない」「このブランドらしくない」といった判断が、経験や専門性の中に埋め込まれている。

AI に実行を任せると、この暗黙の判断が表に出やすくなる。なぜなら、AI の出力が期待とずれたとき、人間は「何が違うのか」「何を追加で伝えるべきか」「何を基準に直すべきか」を言語化したり、媒介物として整えたりする必要が生じるからである。

クリティカル・インシデント法は、このように判断が露出する具体的な出来事を拾うのに向いている。

3.2 AI の変化ではなく、実践内の出来事に焦点を置ける

AI ツールは変化が速い。特定の機能や UI を分析しても、すぐに変わってしまう可能性がある。

しかし、AI に何かを任せる場面で、目的が曖昧だった、制約が足りなかった、評価基準が共有されていなかった、修正の手がかりが必要になった、という出来事は、ツールが変わっても繰り返し現れやすい。

クリティカル・インシデント法を使うことで、変化するツールそのものではなく、AI が入った実践の中で起きる出来事に焦点を置ける。

3.3 媒介物とワークフローを同時に見られる

一つのインシデントには、ワークフロー上の位置と媒介物の両方が含まれる。

たとえば、AI に UI を生成させた場面で、出力がデザインシステムに合わなかったとする。このインシデントには、少なくとも次の要素が含まれる。

ワークフロー上の位置: 依頼後の初回出力、評価、修正指示
媒介物: プロンプト、デザインシステム、README、サンプル
判断・評価: どこが「合っていない」と判断されたのか
修復: 何を追加で渡したのか、どの指示を変えたのか

このように、インシデントを単位にすると、媒介物とワークフローを別々に見るのではなく、一つの出来事の中で接続して分析できる。

4. 収集するインシデントの種類

クリティカル・インシデントというと失敗やトラブルだけに見えやすいが、この研究では否定的な出来事だけでなく、肯定的な出来事も含めて扱う。

4.1 違和感・ズレのインシデント

AI の出力に対して、期待と違う、文脈に合わない、使えない、違和感があると判断した場面。

例:

スライドの構成は合っているが、研究のニュアンスが落ちている
UI の見た目は整っているが、情報の優先順位が違う
コードは動くが、プロジェクトの設計方針に合っていない
デザインシステムを参照させたつもりだが、適切なコンポーネントが使われていない

4.2 修復のインシデント

AI の出力を受けて、人間が追加情報、制約、例、判断基準、媒介物を渡し直した場面。

例:

プロンプトに「何を重視するか」を追加した
README や skill に読み順や禁止事項を追加した
デザインシステムの参照箇所を明示した
生成物の評価観点をチェックリスト化した
出力を見て、どの判断基準が足りなかったかを明文化した

4.3 判断・評価のインシデント

AI の出力に対して、人間が採用する、修正する、捨てる、方向を変えると判断した場面。

例:

AI の出力のうち、どの案を採用するかを選んだ
見た目はよいが、研究の文脈に合わないため使わなかった
UI として成立しているが、ユーザーに誤解されそうだと判断した
コードは正しそうだが、保守性や既存設計との整合性から修正した

4.4 うまくいったインシデント

AI が意図をよく汲み取り、作業が進んだ場面。

これは失敗事例と同じくらい重要である。うまくいった場面には、何が先に外部化されていたのか、どの媒介物が効いていたのか、どのワークフロー設計が有効だったのかが現れる。

例:

事前に構成方針を渡したことで、スライドの流れが大きく崩れなかった
既存コンポーネントの使い方を明示したことで、UI 生成の品質が安定した
修正観点を伝えたことで、再生成の方向が揃った

5. インシデント記録フォーマット案

インシデントを記録する場合、次のようなフォーマットが考えられる。

インシデント ID:
日付:
実践の種類:
  例: スライド作成 / UI 生成 / コード修正 / 文章整理 / デザインシステム参照

使った AI / ツール:
任せようとしたこと:

ワークフロー上の位置:
  例: 初回依頼 / 初回出力 / 評価 / 修正指示 / 再生成 / 採用判断 / 媒介物の更新

インシデントの種類:
  例: 違和感 / ズレ / 修復 / 判断 / うまくいった場面

その時点で渡していた情報:
  例: プロンプト / README / skill / デザインシステム / サンプル / 口頭の意図

使われた媒介物:
  例: UI / テンプレート / チェックリスト / 参照ドキュメント / プロンプト

起きたこと:
  具体的に何が起きたか

人間が行った判断・評価:
  何を良い / 悪い / 違う / 使える / 使えないと判断したか

表に出てきた目的・制約・評価基準・暗黙知:
  それまで明示されていなかったが、この出来事で表に出たもの

修復・対応:
  何を追加・修正・削除・明示したか

結果:
  出力や判断のしやすさがどう変わったか

見えてきた観察軸:
  このインシデントから、AI 介在型実践を見るうえでどんな観点が得られたか

6. 分析のしかた

集めたインシデントは、単なる事例集として並べるのではなく、複数の軸で横断的に見る。

6.1 ワークフロー上の位置で見る

どの段階でインシデントが起きたのかを見る。

依頼前
初回依頼
生成・実行
出力の確認
評価
修正指示
再生成
採用・不採用
媒介物の更新

この分析により、人間の判断や介入がどの段階で現れやすいかが見える。

6.2 媒介物で見る

どの媒介物が使われ、どの媒介物が不足していたのかを見る。

プロンプト
UI
目的カテゴリ
テンプレート
README
skill
デザインシステム
サンプル
チェックリスト
レビュー観点

この分析により、人間や組織の判断基準がどの形で外部化されるのかが見える。

6.3 表に出てきた判断・評価基準で見る

インシデントを通じて、どのような判断や評価基準が表に出たのかを見る。

目的に合っているか
文脈に合っているか
ブランドらしいか
情報の優先順位が妥当か
既存設計と整合しているか
ユーザーに誤解されないか
保守しやすいか
研究のニュアンスを損なっていないか

この分析により、AI に任せる場面で人間側に残る判断の種類が見える。

6.4 修復のしかたで見る

ズレや違和感が起きたあと、何を修正したのかを見る。

プロンプトを修正した
参照資料を追加した
優先順位を明示した
禁止事項を追加した
サンプルを渡した
評価観点を言語化した
AI ではなく人間が直接修正した

この分析により、AI 介在型実践における修復のパターンが見える。

7. この方法で見えてくるもの

この方法によって見えてくるのは、単なる AI の成功・失敗ではない。

見たいのは、次のようなことである。

AI に実行を任せるとき、人間は何を暗黙のままにしがちか
どのような場面で、その暗黙の判断が表に出るのか
どの媒介物が、判断や評価基準の外部化を支えているのか
ワークフローのどの段階で、人間の介入が重要になるのか
AI の出力を評価・修復する中で、人間の役割がどこに再配置されるのか
変化の速い AI を研究として扱うために、どの観察軸が有効そうか

この意味で、クリティカル・インシデント法は、上位方針を具体的な研究作業へ落とすための方法として有効である。

8. 注意点

クリティカル・インシデント法を使う場合、いくつか注意すべき点がある。

8.1 失敗事例に寄りすぎない

「インシデント」と言うと、失敗やトラブルを集める方向に寄りやすい。しかし、うまくいった場面も重要である。

うまくいった場面には、何が事前に外部化されていたのか、どの媒介物が効いていたのか、どのワークフローが判断を支えていたのかが現れる。

8.2 記憶に残る出来事への偏り

強い違和感や大きな失敗は記憶に残りやすい。一方で、小さな修正や日常的な判断は見落とされやすい。

そのため、できれば事後インタビューだけでなく、実践中のメモやログ、プロンプト履歴、生成物の差分などもあわせて記録する方がよい。

8.3 個別事例を一般化しすぎない

一つのインシデントから、AI 介在型実践全体について言い切ることは避ける必要がある。

重要なのは、個別事例を一般化することではなく、複数のインシデントを横断して、繰り返し現れる観察軸を見つけることである。

8.4 方法が目的化しないようにする

クリティカル・インシデント法は、この研究の主題ではない。主題は、変化の速い AI を研究として扱うために、AI が入り込んだ実践のどの要素を見ればよいのかを整理することである。

したがって、方法名を前に出しすぎるよりも、「判断・評価・違和感・修復が露出する出来事を記録する」と説明した方が、研究の意図に合うかもしれない。

9. 現時点の方法方針

現時点では、次のように置ける。

本研究では、AI 介在型の制作・開発・研究・設計実践において、判断・評価・違和感・修復が生じたクリティカル・インシデントを記録し、それらをワークフロー上の位置、媒介物、外部化された判断基準の観点から分析することで、変化の速い AI 実践を捉える観察軸を整理する。

この方針では、クリティカル・インシデント法は、媒介物とワークフローをつなぎ、人間の判断や暗黙知が露出する場面を捉えるための方法として機能する。