はじめに
GMOコネクトの永田です。
AIエージェントに仕事をさせていると、一日の終わりに膨大な対話ログが残ります。その中身の多くは「そこはこう直して」「その根拠は？」といった訂正で、要するに私がAIの成果物に手を入れた記録です。これを眺めていて、ふと思いました。これ、ベテランが頭の中でやっている判断がそのまま文字になっているのでは、と。
暗黙知の形式知化は昔からあるテーマですが、いつも最後は「本人に時間を取ってもらってインタビューする」に帰着して立ち消えになります。対話ログなら本人に時間を取ってもらわずに済みそうに見えました。うまくいけば、ログを回すだけでノウハウが溜まる仕組みが作れます。
そう思って、3案件分のログで実際に測ってみました。動くシステムを作った話ではありません。対話ログという新しい原資から判断がどこまで自動で抜けて、どこで詰まるのかを数字にした第一報です。先に書いておくと、まだ半分も行っていません。
先にまとめ
抽出したノウハウは、作るのに使った実例では大きく効いたのに、別の実例では上積みがゼロでした。効いて見えたのは、テストする実例そのものからノウハウを作っていたからです😇
ただ、詰まった原因は人の言語化不足ではありませんでした。判断の決め手だった基準値は、元のログにそのまま書かれていたのです。拾い損ねていたのは抽出する側でした。だからここは、まだやりようがあると思っています。
| 問い | 結果 |
|---|---|
| ログから判断を機械抽出できるか | できる。3案件・1,157発話から191件が成立（16.5%）。ただし理由まで残っているのは、訂正のうち3割 |
| 抽出した内容でAIは同じ判断に到達するか | 到達する。0/8 → 5/8、上積み +62ポイント、悪化ゼロ |
| それは別の実例にも使えるか | 使えない。同じ型の別の実例6件で上積み +0ポイント。指摘の上限を5件から12件に広げても +17ポイント止まり |
| 何が別の実例で使えて、何が使えないのか | 抽象化した観点は使えない。具体的な基準値は使える。その値はログに逐語で書かれていたのに、抽出で落としていた |
| 「記録しなくてよいもの」は判別できるか | 入口で落ちていた。訂正を拾う時点で対象外になっており、14件すべてAI単独では未到達。測るべきは逆側の「人が訂正しなかったやりとり」 |
読み方の注意を先に書きます。これは1人分のログで、文書作成14件・インフラ作業2件の実験です。母数が小さく、対象も文書作成に偏っています。「この数字が一般に成り立つ」という主張はしません。言えるのは、ノウハウを作るのに使った実例と、使っていない別の実例を分けずに測ると、効いているように見えてしまう、という一点です。
昔から解けていないテーマだけあって、自動化はやはり簡単ではなさそうでした。それでも得るものがゼロだったわけではないので、このテーマには引き続き取り組んでいくつもりです。
1. AIとの対話ログが、従来の暗黙知抽出と違うところ
暗黙知を形式知にする取り組みは、いま大きく2つの型に分かれています。国も GENIAC-PRIZE で「製造業の暗黙知の形式知化」を掲げていますが、主戦場は製造現場の身体知で、ホワイトカラーの設計判断は手薄でした。
| 型 | 手法 | 弱点 |
|---|---|---|
| AIが本人にインタビューして引き出す | 段階的な質問で深掘りする | 本人が時間を割く必要がある |
| 作業映像やセンサーから抽出する | 身体動作を観測する | 対象が身体知に限られ、設計判断には使えない |
対話ログが違うのは、判断の結果が必ずテキストで残る点です。AIに直させた以上、何をどう変えたかは差分として確実に残ります。
ただし残るのは結果までで、なぜそう判断したのかは書いてあることもあれば書いていないこともあります。「そこはこう直して」で終わる発話のほうが多く、実測でも理由まで揃ったのは訂正シグナルの3割でした。減らせるのは本人に聞く量であって、ゼロにはできません。それでも聞く内容は「一から思い出してください」から「このとき、なぜこう直しましたか」の一点に変わります。
この差がどこで効くのかは、認知的タスク分析のレビュー論文（Brown, Power & Gore 2025）が自分たちの手法の限界として書いていることが分かりやすいです。
CTA is not immune from the typical criticisms of memory failure that have been directed at interview-based methodologies.
it is also plausible that participants will introduce biases when recounting their experiences or even cite fabricated knowledge to provide a stronger post hoc rationale for their decision-making.
後から思い出して語ってもらう以上、記憶違いと事後的な正当化が混ざる、という指摘です。著者ら自身は「CTAは何が起きたかを正確に復元するための手法ではない」と反論していますが、回顧に依存すること自体は前提として認めています。対話ログはその場で残った記録なので、少なくともここは踏みません。
逆に、従来と変わらないところもあります。それは次章の記録設計に直結するので、そちらで書きます。
2. 1レコードを「4つ組」にする
訂正だけを抜き出すと意味を成さない
最初にやったのは、ユーザー発話から訂正らしきものを抜き出すことでした。これは失敗します。抜き出した発話が、それ単体では何のことか分からないからです。
「こちらでも通っているので併記した方が良いのでは。
これだと片方が消極的な採用に見えるので」
この発話だけ見ても再利用できません。AIが何を書いていたかという引用とセットにして初めて、「一方だけを実証済みと書くと、もう一方が消極的な採用に見えてしまう」という判断原理が復元できます。
さらに、入力側だけでも足りませんでした。人の指示は「どう直したいか」であって「実際に何がどう変わったか」ではありません。指示が意図どおり反映されたのか、途中で解釈がずれたのか、追加の微調整が入ったのかは、成果物の差分を見ないと分かりません。判断の効果はそこに現れます。
結局、1レコードは4つの要素の組になりました。
| 要素 | 実体 | ログ上の所在 |
|---|---|---|
| 入力 | AIが何を出したか |
assistant メッセージ |
| 介入 | 人が何を指示したか |
user メッセージ |
| 出力 | 成果物が実際にどう変わったか |
Edit の old_string → new_string
|
| 理由 | 本人が語った根拠 |
user メッセージ（介入と同居することが多い） |
この4つはすべて同じログファイルの中にあり、parentUuid の鎖でたどれます。git履歴と突き合わせる必要はありませんでした。実案件の最大セッション1本での内訳は、assistant 1,845件、user 853件、Edit の tool_use 115件でした。
入力をどう特定するかでは少し手間取りました。最初は、人が > で引用したブロックを手がかりに元の文書の該当箇所を探そうとしたのですが、調べた8件のうち6件で文字列が一致しませんでした。引用するときに強調記号などの装飾が落ちるためです。結局、手がかりは Edit の old_string に置き直しました。介入の直前に成果物が実際どうなっていたかそのものなので、定義上ずれません。ログから何かを復元するときは、人が書いた引用ではなく機械が記録した差分を信じるのが正解でした。
1章の最後に書いた「従来と変わらないところ」がここです。理由を独立した要素として立てる必要があるのは、ログだから特別というわけではありません。設計判断の記録でよく引かれる Nygard の Architecture Decision Records の原文が、同じことを書いています。
One of the hardest things to track during the life of a project is the motivation behind certain decisions. A new person coming on to a project may be perplexed, baffled, delighted, or infuriated by some past decision. Without understanding the rationale or consequences, this person has only two choices: Blindly accept the decision. ... Blindly change it.
決定だけ残して理由を残さないと、読む側は盲目的に受け入れるか盲目的に変えるかの2択になる、という話です。ADRが Context（なぜ）と Decision（何を）を別の節に置いているのはこのためでした。あとから振り返ると、この記事の再演テストは、AIがこの2択のどちらに倒れるかを測ったことになります。理由も基準値も渡さないと、AIは黙って受け入れる側でした（4章、5章）。
スキーマ
項目は認知的タスク分析の確立手法から借りました。Critical Decision Method の Decision Requirements Table、アーキテクチャ決定記録の Y-statement、Google SRE のポストモーテムが出所です。
id: 2026-06-21-feasibility-wording
project: <案件>
# ここから4つが無いと成立しない
trigger: | # 入力：AIが出した内容の引用。要約で置き換えない
実現性を「△ 条件付き可能」と表記していた
judgment: | # 介入：人が指示した内容（観測された行動）
「実現性高い（実環境での検証要）」に修正させた
outcome_diff: | # 出力：成果物が実際にどう変わったか
before: 「△ 条件付き可能」
after : 「実現性高い（実環境での検証要）」
※ 同一表記が別表にも3箇所あり、そちらも併せて修正された
rationale: | # 理由：本人が語った根拠。介入・出力とは必ず別フィールドにする
「条件付き」は技術的に危ういと誤読させる。実際は技術検証は完了しており、
残るのは実物が無いと出来ない受入確認のみ
# 横展開を狙うなら必須（後述の実測で、無いと他の実例に効かない）
reference_value: | # 何と比べて妥当・過大と判断したか＝相場の中身
# 準必須
rejected_alternatives: | # 採らなかった選択肢
accepted_downside: | # 受け入れた欠点
expectancy_violation: | # 予期と実際のズレ
# 束ねるための分類キー
knowledge_type: 判断基準 # 判断基準 / 禁じ手 / 段取り / 観点 / 相場観
pattern: 過剰主張の抑制 # 再利用可能な型の名前
verifiable: false # true なら判断系ではないので自動チェックへ回す
通常のドキュメントには残らないのにログには残る、という点で価値が集中したのはこの3項目でした。
- 採らなかった選択肢 — 何を採ったかより、何を採らなかったかに判断基準が出ます
- 予期の裏切り — 認知科学の RPD モデルによれば、専門知は予期が外れた瞬間に最も強く可視化されます。想定どおりなら人は何も言いません
- AIの提案を退けた瞬間 — AIとの協働ログに固有の項目で、人間の専門性が最も濃く露出します
抽出の実測
過去に振り返りを行った3案件のログを対象にしました。抽出は機械処理だけで、人が読んで整えたレコードはありません。
| 案件 | ユーザー発話 | 訂正シグナル | 出力あり | 4つ組が成立 |
|---|---|---|---|---|
| A（インフラ構築の技術検証） | 137 | 67 | 101 | 29 |
| B（長期保守計画の策定） | 742 | 392 | 531 | 115 |
| C（ライブラリ置換の技術検証） | 278 | 153 | 230 | 47 |
| 合計 | 1,157 | 612 | 862 | 191 |
発話の16.5%が4つ組として成立しました。訂正のシグナルが立った612件を分母に取ると3割ほどで、残りは理由か出力のどちらかが欠けています。理由が書かれないまま直っているものの方が多いわけで、ここは自動抽出だけでは埋まりません。設計としては、欠けたレコードに「要確認」の印を立てて、週に一度まとめて本人に一行だけ聞くところまでを想定しています。
裏を返すと、書かれている3割は完全に機械で拾えます。ここまでは想定どおりでした。
3. 形式知化できたかを、人の納得ではなく再現で測る
抽出物ができたところで、次の問題にぶつかります。「これで十分に記録できている」を誰がどう判定するのか。
人が読んで納得できるかで判定してはいけない、というのが出発点でした。Nisbett & Wilson の古典的な研究が示したとおり、人が語った理由が実際の判断根拠と一致している保証はありません。自分で抽出して自分で「よく書けている」と判定したら、何も測っていないのと同じです。
そこで判定を行動の再現で行うことにしました。判断が起きた時点の入力だけをまっさらなセッションに渡し、同じ論点に到達するかを見ます。
| 条件 | 与えるもの |
|---|---|
| ノウハウなし | 判断時点の断片のみ。既存の全体ルールとメモリは有効なまま |
| ノウハウあり | 上に加えて、抽出したノウハウ（9項目のチェックリスト） |
ノウハウとして渡すチェックリストには、その実例の答えは含めません。含めたら再現ではなくカンニングです。
結果は3つに分かれ、扱いもそれぞれ変わります。
| 結果 | 意味 | 扱い |
|---|---|---|
| ノウハウなしで到達 | AIが既に持っている、または既存ルールで足りている | ノウハウ集から落とす |
| ノウハウなしでは未到達・ノウハウありで到達 | 形式知化が効いた | 採用。これが成果物の中身 |
| ノウハウありでも未到達 | 言語化が足りない | スキーマ設計に戻す |
1つめの分類があることが、この設計の肝です。ETH Zurich のチームが、開発者が実際にコミットしたコンテキストファイルを持つリポジトリで測ったところ、その提供はタスク成功率を改善せず、推論コストを平均20%以上増やすという結果が出ています。LLMに生成させたファイルに至っては成功率が約3%下がっていました。抽出したから足す、を続けると効かないうえに高くつきます。1つめに分類されたものを機械的に落とせれば、方針ではなく手続きでこれに対処できます。ただし今回、この分類は1件も出ませんでした。理由は6章に書きます。
統制条件も先に固定しました。ここを外すと数字が無意味になります。
| 項目 | 対処 |
|---|---|
| 答えの漏れ | 完成した成果物リポジトリを見せない。判断時点の断片のみ渡す |
| 文脈の漏れ | 再演セッションに元のログを触らせない |
| 判定の主観 | 到達の基準を事前に固定し、判定は別セッションで実施。抽出者が自分で採点しない |
判定者は2名（いずれも別セッション）です。判定者には2つの回答を並べて見せますが、どちらがノウハウなしでどちらがノウハウありかは伏せました。さらに2人目には、この2つを見せる順番を逆にしています。同じ順で見せ続けると、後に見たほうが良く見える偏りが乗るためです。あわせて、到達と判定するときは該当箇所の逐語引用を必須にしました。引用させておけば、その文字列が本当に回答の中にあるかを機械で照合できるので、判定者が到達したと言うだけの水増しを弾けます。
4. 実測：作成に使った実例では +62ポイント、別の実例では +0ポイント
4.1 作成に使った実例なら、確かに効いた
8つの実例で測った結果です。ここでいう実例は、実際に起きた1回の判断を指します。表の「判断の型」はそれを後から分類した名前で、同じ型の判断は別の場面でも起きます。この区別が次の 4.2 で効いてきます。
| 判断の型 | 既存ルール | ノウハウなし・判定者1 | ノウハウなし・判定者2 | ノウハウあり・判定者1 | ノウハウあり・判定者2 | 分類 |
|---|---|---|---|---|---|---|
| 過剰主張の抑制 | 部分 | partial | partial | reached | reached | 効いた |
| 非公式な回避の結果を成果と書かない | 部分 | partial | reached | reached | reached | 効いた |
| 正本を動かさない | 無 | missed | missed | reached | reached | 効いた |
| 重大度を混ぜない | 無 | missed | missed | reached | reached | 効いた |
| リスクと決定事項を判別する | 無 | missed | partial | reached | reached | 効いた |
| 指標が測らないものを明示する | 無 | missed | missed | reached | partial | 記録不足 |
| 問題の所在を切り分ける | 部分 | missed | missed | missed | partial | 記録不足 |
| 多義語を明示する | 有 | missed | missed | missed | partial | 記録不足 |
判定者間の一致は 11/16 で69%にとどまりました。単独のAI判定は信頼できないので、両者が一致したものだけを到達とする保守値を主に使います。
| 指標 | 保守（両者一致） | 寛容（いずれか） |
|---|---|---|
| ノウハウなしの到達率 | 0/8 = 0% | 1/8 = 12% |
| ノウハウありの到達率 | 5/8 = 62% | 6/8 = 75% |
| 上積み分 | +62 pt | +62 pt |
| ノウハウを渡して悪化 | 0/8 | 0/8 |
上積み分は判定基準を変えても +62ポイントで動きませんでした。8件すべてでノウハウありがノウハウなし以上で、悪化はゼロです。
ここで私はいったん喜びました。これが間違いでした。
4.2 別の実例では、上積みがゼロだった
ノウハウとして渡したチェックリストは、テストした8件そのものから一般化して書いたものです。つまり答えを見てから問題を作っている状態で、62%は上限値でしかありません。
そこで、チェックリスト作成に使っていない別の実例で測り直しました。型が同じでも中身は別物で、AIに渡す断片も、そこに書かれている内容も、直すべき箇所も違います。191件を正規化して重複を除くと36件になり、そこから既存のチェックリストと同じ型の別の実例を6件選びました。
| 判断の型 | ノウハウなし・判定者1 | ノウハウなし・判定者2 | ノウハウあり・判定者1 | ノウハウあり・判定者2 |
|---|---|---|---|---|
| 過剰主張の抑制 | missed | missed | partial | reached |
| 多義語を明示する | missed | missed | missed | missed |
| 多義語を明示する | partial | partial | partial | partial |
| 問題の所在を切り分ける | missed | missed | missed | missed |
| 異質なものを混ぜない | missed | missed | missed | missed |
| 分類の妥当性・相場観 | missed | partial | missed | partial |
| 指標 | 作成に使った実例8件 | 別の実例6件 |
|---|---|---|
| ノウハウなしの到達率 | 0/8 = 0% | 0/6 = 0% |
| ノウハウありの到達率 | 5/8 = 62% | 0/6 = 0% |
| 上積み分 | +62 pt | +0 pt |
判定者間の一致は 9/12 で75%でした。62%という数字は、別の実例には持ち越せませんでした。
ただし、この 0/6 は「チェックリストが読まれていない」という意味ではありませんでした。ある実例で渡した抜粋は6行の表で、AIは「項番5に違反」「項番6」とチェックリストの項番を挙げながら、表の行を1行ずつ指摘していました。同じ規則を、人がそのとき直した行とは別の行に当てていたわけです。
ここで疑いが出ます。指摘は最大5件までと制限していたので、6行の表に対して枠は5つしかありません。規則を行ごとに当てていくと、6行のうちどれを落とすかはAIが選ぶことになります。人が直した行がその落ちた1行だったのなら、規則は分かっていて枠が足りなかっただけ、という説明が成り立ちます。
そこで上限を12件に上げ、他は完全に同じ条件で再実行しました。指摘の数は平均5.0件から8.7件に増えたので、上限の変更自体は効いています。それでも到達したのは6件中1件だけ（上積み +17ポイント）で、3件は指摘の数が1.7倍に増えても未到達のままでした。枠の取り合いが原因ではありません。
残るのは、規則は読めているのにどの行に当てればいいのかが決まらない、という状態です。この観察が、そのまま次の答えになりました。
5. 効いたのは「観点」ではなく「基準値」だった
未到達に終わった実例を1件ずつ見ていくと、2件が同じ原因に収束しました。判断が相場観に依存していて、その照合先の値が記録されていないのです。
| 判断の型 | 人が持っていた相場観 | 記録に無かったもの |
|---|---|---|
| 問題の所在を切り分ける | 「3秒・90%」は一般的なWebサービスの性能目標として妥当な水準 | その基準値そのもの。「一般的な水準を疑うな」という指示だけでは、何が一般的かを判定できない |
| 多義語を明示する | 公的機関のPKIも一般的なPKIであり、認証局の構成が違うだけ | ドメインの相場。差分を「大」と評価するのが過大だと判定する基準 |
そこでスキーマに1項目だけ足しました。
reference_value: | # 何と比べて妥当・過大と判断したか（相場の中身）
Webシステムの応答時間目標は一般に1秒前後〜3秒・達成率90%程度が通常の水準。
この範囲内なら目標値自体は論点にしない
この値は、スキーマを直すときに新しく考えたものではありません。元のログに、私自身の発話として逐語で残っていました。それを書き写しただけです。抽出のときに落としていたわけです。
これを足して2件を再演した結果です。
| 判断の型 | 基準値なし | 基準値あり・判定者1 | 基準値あり・判定者2 |
|---|---|---|---|
| 問題の所在を切り分ける | missed | reached | reached |
| 多義語を明示する | missed | reached | reached |
2件とも記録不足から採用へ転じ、判定者2名が一致しました。
この非対称が実験の核心でした。
| 与えたもの | 別の実例で使えるか | 根拠 |
|---|---|---|
| 抽象化した観点（「一般的な水準を疑うな」「前提を裏取りせよ」） | 使えない | 別の実例6件で +0〜17pt |
| 具体的な基準値（相場観・照合先の値） | 使える | 2/2 が到達、判定者一致 |
文書作成以外でも同じ形が出ました。インフラ構築のログから2件だけ追加で測ったところ、未到達だった1件の理由が同型でした。チェックリストには「依存先の実装に依存する値は確認済みかを明示する」と書いてあり、AIはTLS設定の根拠不足には触れたのですが、ヘルスチェックのパスがアプリの実装と合っているかには届きませんでした。どの値が典型的に確認を要するのかという具体性が無かったためです。n=2 なので方向性の確認にとどまります。
6. 「記録しなくてよいもの」は、抽出の入口ですでに落ちていた
ノウハウなしで到達した判断はノウハウ集から落とせる、というのが3章の分類でした。ところが実測では、14件すべてがノウハウなしで未到達です（8件で 0/8、別の6件で 0/6）。落とす候補が1件も出てきません。
理由は単純で、抽出の入口がすでにフィルタになっているからです。4つ組は人が訂正した箇所からしか作られないので、AIが自力で正しく出せたものは最初から候補に入りません。再演で落とすまでもなく、入口で落ちています。0/14 はその裏返しで、訂正シグナルで拾ったものが本当にAIの穴だったことの検算になりました。
とはいえ、これで判別できたことにはなりません。測れていないのは逆側です。入口で落としている「人が訂正しなかったやりとり」に、記録すべきものが混ざっていないか。ここが次にやることです。
| 次に見る対象 | 何を意味するか | 記録できたときの効果 |
|---|---|---|
| 人が手を入れなかった出力 | AIの判断がそのまま通った。既に持っている判断の候補 | ノウハウ集から機械的に落とせる。渡す量が減り、読ませるコストと、足しすぎで精度が下がる問題の両方を避けられる |
| AIが「こうする案でどうか」と提案し、人が同意した発話 | 明示的に一致した判断。「OK」「進めて」のような短い返答として残っている | 毎回同意している提案は、確認を挟まず任せてよい候補になる。人が判断する回数が減り、AIが自分で決めてよい範囲が広がる |
| 同意された提案の中身そのもの | 人が是とした推奨内容の実物 | 次から提案の初期値として使える。人は選ぶだけになり、直す手間が減る |
ここは一度、見る対象を間違えました。ツールの実行許可のログを原資にしようとしたのですが、「このコマンドを実行してよいか」は「なぜその表現を直したか」とは粒度が違います。そもそも Claude Code の Auto Mode で動かしているため、許可・拒否のイベント自体が記録されていませんでした。
ただし、AIが既に持っているから落とす、という判断は、AIに渡す成果物としては正しくても、人に渡す成果物としては間違っているかもしれません。毎回同じ提案に人が同意しているなら、それは組織として合意が取れている判断です。AIには不要でも、新しく入った人には要ります。落とす前にAI向けと人向けを分ける、というのも次の宿題です。
7. この結果をどう読むか
近いことをやっている研究との関係
エージェントの行動ログから知見を抜き出して次に活かす、という研究は既にあります。
| 研究 | やっていること | 報告している結果 |
|---|---|---|
| ExpeL（AAAI 2024） | エージェントが自分で集めた軌跡から、成功と失敗の両方を自然言語の insight に蒸留し、次のタスクで参照させる | 3ドメインで一貫して改善。別ドメインへの転用も検証 |
| Agent Workflow Memory（ICML 2025） | 過去の軌跡から再利用できる手順のテンプレートを抽出し、必要なときだけ渡す | Mind2Web で成功率 +24.6%、WebArena で +51.1%（いずれも相対） |
私の +0 という結果は、これらの改善報告と一見ぶつかります。ただ、条件を並べてみると前提がかなり違いました。
- 抜いているものが違う。ExpeL と AWM が抽出するのはエージェント自身の行動です。この記事が抽出したのは、人がAIを止めた判断でした
- 正解判定がない。ベンチマークにはタスクの成否が自動で付きますが、「この表現が過剰主張かどうか」に自動判定はありません。判定者を2名立てる必要があったのはこのためです
- 渡し方が違う。ここがいちばん効きました
3番目について、ExpeL の転移実験が示唆的です。HotpotQA から FEVER へ insight を移すとき、対象ドメインの少数の例を使って insight を書き直す手順が入っています。
We use the same fewshot examples to finetune the insights as the ones that will be used during task execution.
そして、その例を使わない条件も並べて測っています。結果は、ベースラインの ReAct が63%、例なしの転移が65%、例ありの転移が70%。論文自身が、例をいくつか入れた側の改善のほうが明確に大きいと書いています。
私が渡していたのは、この「例なし」に相当するものでした。抽象化した観点だけを渡し、対象の中身には触れていません。同じ非対称が、正解判定のない実務データではもっと極端に出た、という読み方ができます。
実務側の日本語事例も探しましたが、セッションログの活用は利用傾向の可視化や振り返りが中心で、判断そのものの抽出まで踏み込んだものは見当たりませんでした。
ルールがあるのに再発する、を実データで見た
8件のうち1件だけ、判断の内容が全体ルールに明文で書かれていました。「読み手が一意に解釈できる用語に統一する。初出には定義を添える」という、多義語の明示に関する規定です。
この1件はノウハウなしで到達せず、ノウハウを渡しても到達しませんでした。常時読み込まれるルールファイルに書いてあるのに再発し、チェックリストで補強しても届きません。これは前述の ETH Zurich の結果が自分のデータで再現した形です。
対処はルールを増やすことではありません。置き場所を変えること、つまり機械的に検証できるなら自動チェックへ、判断系なら必要時だけ読み込まれる形へ移すことになります。実際、強調記号のリテラル化はこの実験の副産物として Lint を書き、書いた直後に検出できるようにしました。
どこまで言えるか
測ったのは1人分のログで、合計16件です。文書作成が14件（ノウハウを作るのに使った実例8件と、別の実例6件）、これにインフラ作業の2件を足した数です。文書作成に偏っていますし、他の人のログには触れていません。この数字が一般に成り立つとは言えません。
もう一つ、今回の16件はいずれも人が理由まで書いていた実例でした。4つ組の成立条件に理由が入っているためで、裏を返せば「理由を書かなかったらどうなるか」を一度も見ていません。ここは次に測りたいところです。
ただし条件の切り方には注意が要ります。意識して理由を書かせると、Nisbett & Wilson の指摘した「語られた理由と実際の判断根拠が食い違う」問題に近づき、その場で自然に出た理由をそのまま拾えるという利点を失います。しかも今回効いたのは理由そのものではなく基準値でした。測るなら理由の有無ではなく、基準値を添えるかどうかで条件を切るのが良さそうです。
やってみて思ったこと：これはOJTと同じ話かもしれない
一通り測ってから気づいたのですが、この記事で使った道具は、ほとんどが人間の暗黙知を引き出すために作られたものでした。
| 使ったもの | もともとの対象 |
|---|---|
| Critical Decision Method | 消防指揮官や看護師など、人間の専門家からの知識抽出 |
| 初級者ならどう違う行動をしたか、という項目 | 同上。OJTを前提にした設問 |
| 予期が外れた瞬間に専門知が可視化されるという整理 | 人間の意思決定研究 |
こう並べると、今回の結論も特に新しくありません。観点だけ渡しても動けず、基準値まで渡して初めて動くというのは、新人に「品質に気を配って」と言っても動けないのに「レビューでこの数字を超えていたら差し戻す」と言えば動く、という話とまったく同じです。抽象的な方針を配っただけで現場が動かないのは、AI以前からある光景でした。
違いは1つだけありそうです。AI相手なら再演テストが安く、何度でもやり直せることです。新人に同じ課題を条件を変えて8回やらせ、別の2人に採点させる、というのは現実には組めません。記録が足りているかを実測で判定できるのは、AI協働に固有の利点だと思います。
裏返すと、ここで作る基準値集をAI専用にする理由もありません。人に渡しても同じように効くはずで、効かなければ書き方が足りない、と判定できます。AIを新人だと思って書けば両方に使えるものになるはずで、次に試すときはこの見方で書いてみようと思っています。
まとめ
- AIとの対話ログから、判断を機械抽出できる。抽出そのものに人手は要らない。ただし理由まで残っているのは一部で、3案件・1,157発話のうち4つ組が成立したのは16.5%、訂正シグナルが立った612件に対しては3割だった
- 抽出したノウハウをAIに渡すと、作成に使った実例では到達率が 0/8 から 5/8 に上がる。上積み +62ポイント、悪化ゼロ
- ただしこの 62% は別の実例には持ち越せない。同じ型の別の実例6件では上積み +0ポイント。指摘の上限を12件に広げ、実際の指摘数が1.7倍になっても3件は未到達のままで、枠の競合が原因ではない
- 別の実例で効かなかった原因は抽象度。照合先の基準値を1項目足すと、未到達だった2件がともに到達した（判定者2名一致）。しかもその値は、元のログのユーザー発話に逐語で存在していた
- したがって成果物は「観点リスト」ではなく基準値つきの判断集にする。ただし基準値を足して確かめた再演は2件で、まだ方向性の確認にとどまる
- 効果を測るときは、ノウハウを作るのに使った実例と使っていない実例を必ず分ける。分けないと、答えを見てから作ったチェックリストで62%という数字が出てしまう
- 使った手法はどれも人間の暗黙知を引き出すためのもので、観点でなく基準値を渡すという結論はそのまま新人へのOJTにも当てはまりそう。AI固有の利点は、記録が足りているかを再演テストで安く実測できる点にある
暗黙知の形式知化は、うまい手を1つ見つければ解けるという種類のテーマではなさそうです。一度なぞってみて、そのことがようやく腑に落ちました。
いまはここで止まっています。次は基準値を必須項目にした状態で抽出をやり直し、理由が書かれていない実例も含めて測り直すところからです。同じ方向を試している方がいれば、ノウハウを作るのに使った実例と使っていない実例を分けて測るところだけは、先にやっておくことをおすすめします。
参考リンク
- Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?（ETH Zurich）: https://arxiv.org/abs/2602.11988
- Brown, Power & Gore「Cognitive Task Analysis: Eliciting Expert Cognition in Context」Organizational Research Methods 2025（回顧インタビューの限界を著者自身が整理している。本文の引用はこの公開版から）: https://eprints.bbk.ac.uk/id/eprint/53888/contents
- ExpeL: LLM Agents Are Experiential Learners（AAAI 2024。軌跡から insight を抽出し転移まで検証）: https://arxiv.org/abs/2308.10144
- Agent Workflow Memory（ICML 2025。軌跡から再利用可能な手順を抽出）: https://arxiv.org/abs/2409.07429
- Nygard「Documenting Architecture Decisions」2011（ADRの原典。理由を残さないと2択になる）: https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions
- Nisbett & Wilson「Telling More than We Can Know」1977: https://home.csulb.edu/~cwallis/382/readings/482/nisbett%20saying%20more.pdf
- Hoffman, Crandall, Klein, Jones & Endsley『Protocols for Cognitive Task Analysis』（CDM の出典）: https://www.ihmc.us/wp-content/uploads/2025/06/Protocols-for-Cognitive-Task-Analysis.pdf
- Zimmermann「Y-statements」: https://medium.com/olzzio/y-statements-10eb07b5a177
- Google SRE Book 第15章 Postmortem Culture: https://sre.google/sre-book/postmortem-culture/
- GENIAC-PRIZE 受賞一覧（NEDO）: https://geniac-prize.nedo.go.jp/archive/2025/
最後に、GMOコネクトではサービス開発支援や技術支援をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。