体重計に毎朝乗るだけの人と、手帳に食事内容と体重を書き続けようとする人。どちらが1年後も記録を続けているか、答えは明らかだろう。前者は装置に乗るだけで自動的に記録が残る。後者は「今日は疲れているから明日書こう」が、いつか「もう書かなくていいか」に変わる。意志の強さの差ではない。設計の差である。
AIプロジェクトにおける現場データの入力も、まったく同じ構造で失敗する。キックオフの熱気の中で「これからは日々の判断根拠をきちんと記録しましょう」と申し合わせる。最初の1週間は守られる。1ヶ月後、記録は形骸化している。
01 「記録してください」が機能しない理由
現場の担当者に悪意はない。彼らは日々の生産目標、納期、突発的なトラブル対応に追われている。その合間に「AIエンジンのための記録」という、直接的な見返りが見えにくい作業を差し込む余地は、構造的にほとんど残っていない。
さらに厄介なのは、記録の重要性が「後になってから」わかることだ。今日のこの判断が、半年後のAIエンジン開発において決定的なデータになる——そんなことは、現場で判断を下している瞬間には誰にもわからない。重要性が見えない作業は、優先順位の最下位に置かれる。これは怠慢ではなく、人間の情報処理として自然な帰結である。
02 なぜこれがAIプロジェクトの致命傷になるのか
どれほど優れたAIエンジンを設計しても、入力されるデータが揃わなければ、そのエンジンは動かない。多くのAIプロジェクトが「技術は完成したが、使えるデータがない」という壁にぶつかって停止する。原因の多くは、モデルの性能ではなく、この最初の一歩——データの入力設計——にある。
そして皮肉なことに、この問題は「もっと現場に協力を呼びかけよう」という精神論的な対策では解決しない。むしろ協力要請そのものが摩擦になり、現場の疲弊とAIプロジェクトへの不信を招くことすらある。
03 記録する主体を、人から仕組みへ移す
処方箋は単純だ。「人が正確に記録し続けること」を前提にしない設計に切り替える。具体的には二つの方向がある。
一つは、記録という行為そのものを、既存の業務フローに埋め込むことだ。新たに「記録する」という作業を追加するのではなく、すでに現場が日常的に行っている作業——判断シートへの入力、報告書の提出——の中に、後でAIが処理できる構造化された項目をあらかじめ組み込んでおく。現場から見れば、いつもの仕事をしているだけで、必要なデータが自動的に蓄積されていく。
もう一つは、自由記述を許さないことだ。「気づいたことを自由に書いてください」という形式は、書く人の負担が大きく、AIが処理できる形にもならない。COG（何が急所か）、COE（誰が・どこで判断しているか）、根拠——という決まった型への入力を制度として義務づける。自由度を奪うことは、一見不親切に見えるが、実際には「何を書けばいいかわからない」という最大の負担を取り除く設計である。
LONGNOWがSAISに組み込んでいる「防御COE」という発想は、この二つを制度化したものだ。記録する主体を人間の善意から仕組みへ移し、構造化されたフォーマットへの入力を、特別な努力を要さない形で組織に埋め込む。
04 「強制」は、不親切ではない
「構造的に強制する」と聞くと、現場に負担を強いる冷たい仕組みに聞こえるかもしれない。しかし実際は逆だ。何をどう書けばよいか分からないまま自由記述を求められることの方が、現場にとってはるかに大きな負担である。
型を決め、その型の中でしか入力できないようにすることは、現場の迷いをなくす親切設計である。体重計に乗るだけで記録が残るように、いつもの仕事をするだけでデータが残る。それが実現できて初めて、「記録してください」というお願いは不要になる。
体重計は、意志の強さを試す道具ではない。乗るだけで記録が残るように作られている。データも同じだ。人の意志に期待するのではなく、乗るだけで残る仕組みを作れるかどうかが、すべてを決める。
貴社のAIプロジェクトで、現場に求めているのは「手帳に書き続ける努力」だろうか、それとも「乗るだけで記録が残る装置」だろうか。前者である限り、どれほど優れたAIエンジンを用意しても、その原料であるデータは半年後には枯渇している。
記録を、お願いするな。記録が、残る仕組みを作れ。
