クリティカル・インシデント記録フォーマット
作成日: 2026-05-02
位置づけ: AI 介在型の制作・開発・研究・設計実践において、判断・評価・違和感・修復が露出した出来事を記録するためのテンプレート。
使い方
このフォーマットは、AI を使った場面を何でも記録するためのものではない。
本研究では、クリティカル・インシデント法を厳密なインタビュー法としてそのまま適用するというより、AI 介在型実践において、判断・評価・違和感・修復が露出した出来事を収集・分析するために応用する。
そのため、記録する出来事は、単に「印象に残ったAI利用」ではなく、次の条件を満たすものを優先する。
- 具体的な出来事である
- 何らかの成果や結果に影響している
- その影響が、AI、人間の判断、媒介物、ワークフロー上の出来事と結びつけて説明できる
- 出来事の前後関係をある程度たどれる
記録対象にするのは、次のいずれかが起きた場面である。
- AI に何を任せるかを決めた
- AI に目的や制約を渡した
- 出力に違和感やズレがあった
- 出力を評価し、採用・修正・不採用を判断した
- 追加でプロンプト、資料、例、ルール、媒介物を渡した
- 出力を受けて、暗黙だった判断基準が明示された
- 修正後に出力や判断のしやすさが変わった
- うまくいった理由として、事前に外部化されていた情報や媒介物が確認できた
CIT として成立させるためのチェック
記録後に、次の問いに答えられるかを確認する。
- これは具体的な一つの出来事として記述されているか
- その出来事は、何らかの成果に正または負の影響を与えたか
- なぜその出来事を critical とみなすのかを説明できるか
- 出来事の直前、最中、直後に何が起きたかを追えるか
- その場面で、誰が何を判断・評価したかが分かるか
- どの媒介物や情報が使われ、不足し、更新されたかが分かるか
- 複数のインシデントと比較できる形で記録されているか
これらに答えられない場合、その記録は CIT というより、一般的な利用メモや感想に近い可能性がある。
記録テンプレート
## インシデント ID
例: CI-2026-05-02-001
## 記録日
YYYY-MM-DD
## 実践タイプ
該当するものを選ぶ、または近いものを書く。
- 文章・研究整理
- 資料・スライド生成
- UI・デザイン生成
- コード・実装支援
- その他:
## 実践の概要
何をしようとしていたのか。
例:
- 研究方針メモをスライド化しようとしていた
- デザインシステムに沿った UI 案を生成しようとしていた
- 既存コードに合わせてコンポーネントを修正しようとしていた
## 使った AI / ツール
例:
- ChatGPT
- Claude
- Gemini
- Genspark
- Canva AI
- Figma Make
- Claude Design
- Cursor
- Claude Code
- その他:
## 期待していた成果 / 結果
この作業で、何が達成されればよいと考えていたか。
例:
- 研究のニュアンスを保ったまま、発表用スライドに変換できる
- 既存デザインシステムに沿った UI 案が出る
- 既存コードの設計方針を崩さずに修正できる
- 自分の考えを失わずに、文章構成を整理できる
## 実際の結果
実際に何が起きたか。期待していた成果に対して、どうだったか。
例:
- 構成は整ったが、研究の探索的なニュアンスが失われた
- 見た目は整ったが、既存コンポーネントの使い方が違った
- コードは動きそうだが、既存設計と整合していなかった
- 期待よりも論点が明確になった
## インシデントの影響
この出来事が、作業や判断にどのような影響を与えたか。
例:
- 出力をそのまま採用できなかった
- 追加で評価基準を言語化する必要が生じた
- README / skill / プロンプトを修正する必要が見えた
- AI に任せる範囲を狭める判断につながった
- 次の依頼や媒介物設計が改善された
## なぜ critical と判断したか
この出来事が、単なる小さなミスや感想ではなく、研究上重要なインシデントだと考える理由。
例:
- 暗黙だった評価基準が表に出たため
- AI に任せる範囲の曖昧さが露出したため
- 媒介物の不足が出力に影響したため
- 修復によって出力や判断のしやすさが変わったため
- AI 介在型実践を見るための観察軸が得られたため
## 対象者 / 実践者の文脈
### 立場
例: 学生 / 研究者 / デザイナー / ジュニアデザイナー / エンジニア / PdM / 教授 / その他
### 専門性の程度
例: 初学者 / ジュニア / 経験者 / 専門家 / 判断保留
### 対象タスクとの関係
例:
- 自分の専門領域
- 補助的作業
- 初めての作業
- 他者の成果物を評価する作業
### 評価基準の有無
その人は、何を良い / 悪いと判断できる立場だったか。
例:
- 研究の論旨やニュアンスを判断できる
- デザインシステムとの整合を判断できる
- コードの保守性を判断できる
- 判断基準が曖昧だった
### AI 利用経験
例: 慣れている / 試行段階 / ほぼ初めて / 判断保留
### 組織的文脈
例:
- 個人作業
- チーム作業
- 組織のデザインシステムが関わる
- プロジェクト固有のコード規約がある
- 教授・ゼミ・研究室の評価文脈がある
## ワークフロー上の位置
該当するものを選ぶ、または近いものを書く。
- 依頼前
- 初回依頼
- 初回出力
- 出力確認
- 評価
- 修正指示
- 再生成
- 採用 / 不採用判断
- 媒介物の更新
- その他:
## インシデントの種類
該当するものを選ぶ。
- 肯定的インシデント
- 否定的インシデント
- 混合的インシデント
- その他:
補足として、該当する性質を書く。
- 違和感・ズレ
- 修復
- 判断・評価
- うまくいった場面
- 判断基準の露出
- 媒介物の不足 / 更新
## その時点で AI に渡していた情報
例:
- プロンプト
- 目的
- 背景
- 制約
- 画像
- ソースコード
- 参照資料
- README
- skill
- デザインシステム
- サンプル
- チェックリスト
- 口頭・チャット上の補足
## 使われた媒介物
AI と人間のあいだで、目的・制約・評価基準・暗黙知を運んでいたもの。
例:
- プロンプト
- UI の目的カテゴリ
- テンプレート
- README
- skill
- デザインシステム
- サンプル
- チェックリスト
- レビュー観点
- 既存コード
- 過去の成果物
## 出来事のタイムライン
### 直前
このインシデントが起きる直前に何をしていたか。
例:
- 初回プロンプトを入力した
- README を渡した
- 出力を確認し始めた
- 既存コードとの差分を見ていた
### 最中
インシデントの中心となる出来事。
例:
- AI の出力に違和感を持った
- ある判断基準が足りないと気づいた
- 修正指示を出した
- 出力を採用しないと判断した
### 直後
その後、何をしたか。
例:
- 評価観点を追加した
- 参照資料を足した
- 人間が直接修正した
- 次のプロンプトを変えた
- 媒介物を更新した
## 起きたこと
具体的に何が起きたか。
できるだけ事実ベースで書く。
## 人間が行った判断・評価
何を良い / 悪い / 違う / 使える / 使えないと判断したか。
例:
- 構成は合っているが、研究のニュアンスが落ちていると判断した
- UI は整っているが、コンポーネントの意味的な使い方が違うと判断した
- コードは動きそうだが、既存設計に合っていないと判断した
## 表に出てきた目的・制約・評価基準・暗黙知
この出来事によって、明示する必要があると分かったもの。
例:
- 研究では「結論」ではなく「探索中の問い」として語る必要がある
- ブランドらしさは色だけでなく、情報密度や余白にも関わっていた
- 既存コンポーネントは見た目ではなく用途で選ぶ必要がある
- コード修正では、動作だけでなく既存設計との整合が重要だった
## 修復・対応
何を追加・修正・削除・明示したか。
例:
- プロンプトに評価観点を追加した
- README に読み順を追加した
- サンプルを渡した
- 禁止事項を明示した
- AI の出力を採用せず、人間が直接修正した
## 修復後の結果
修復後に何が変わったか。
例:
- 出力の方向が揃った
- 判断しやすくなった
- まだズレが残った
- AI に任せる範囲を狭めた
- 媒介物を更新する必要が見えた
## 追加で確認したいプローブ質問
このインシデントを深掘りするために、後で自分または対象者に確認したい問い。
例:
- なぜその出力を「違う」と判断したのか
- その判断は、どの経験・知識・基準に基づいていたのか
- 事前に何が渡されていれば、このズレは起きにくかったか
- AI に任せる範囲はどこまでだと考えていたか
- どの媒介物が役に立ち、どれが足りなかったか
- その場面で、人間が確認すべきだった点は何か
## 見えてきた観察軸
このインシデントから、AI 介在型実践を見るうえでどんな観点が得られたか。
例:
- 評価基準は出力後に露出しやすい
- 媒介物は最初から十分に整っているわけではなく、修復の中で更新される
- 人間の判断は、生成前よりも生成後の評価・修正段階で強く現れる
- AI に任せる範囲を明示しないと、期待と出力がずれやすい
## 分析コード / カテゴリ（後で記入）
複数のインシデントを横断分析するときに付けるコード。
例:
- 目的の外部化
- 制約の不足
- 評価基準の露出
- 媒介物の更新
- 委譲範囲の曖昧さ
- 修復ループ
- ワークフロー上の評価接点
- 組織的知識の外部化
## 関連ファイル・ログ
必要に応じて、プロンプト、生成物、差分、メモ、スクリーンショットなどの場所を書く。
例:
- プロンプト履歴
- 生成物
- 修正前後の差分
- スクリーンショット
- README / skill / デザインシステムの該当箇所
- 会話ログ
## 記録の信頼性メモ
この記録が何に基づいているかを書く。
例:
- 実践直後に記録した
- 後から記憶で記録した
- プロンプト履歴を参照した
- 生成物の差分を確認した
- 対象者への聞き取りで補足した
## メモ
その他、後で分析するときに残しておきたいこと。
簡易版
時間がないときは、最低限これだけ記録する。
## インシデント ID
## 実践タイプ
## 実践者の文脈
立場 / 専門性 / 評価基準 / 組織的文脈:
## 何を AI に任せたか
## 期待していた成果 / 実際の結果
## なぜ critical と判断したか
## 何が起きたか
## どこで違和感・判断・修復が生じたか
## 使われた媒介物
## 表に出てきた判断基準・暗黙知
## 修復・対応
## 見えてきた観察軸
## 記録の根拠