AIハーネスは「仕事術」の外部化

はじめに

AIハーネスの話をしていると、
つい「便利な共通装備」のように語りたくなる。

でも、少なくともユーザー側で作るハーネスは、
そんなに中立でも、そんなに汎用でもない。

むしろ実態に近いのは、
その人やそのチームの仕事の進め方を、外に出したもの
という見方だと思っている。

だから
「ハーネスを作りました。みんな使ってください」
という話は、かなりの部分で
「自分たちの仕事術を形式化しました。試してみますか」
に近い。

ここを見誤ると、
ハーネスに対して過剰な期待も、過剰な失望も起きやすい。

Skill は部品、ハーネスは運転系

この違いは、まずここから整理すると見えやすい。
Skill は、比較的共有しやすい。

調査する。
要約する。
テストを書く。
差分を見る。
仕様を整える。

このレベルなら、誰が作ってもある程度は似た形になる。
けれど、ハーネスは違う。

どの順で動くか。
どこで止まるか。
何を見に行くか。
どこまで自動で進めるか。
何を根拠として残すか。

ここまでつなぎ始めた瞬間、
それは単なる部品集ではなく、その人の仕事の回し方そのもの になる。

同じ Skill を持っていても、
つなぎ方が違えば、出てくる成果はかなり変わる。

だから差が出るのは、部品の有無より、
構成、順序、境界条件、停止条件 のほうだ。

汎用的な仕事術は、下のレイヤーに吸収される

ここも大事なポイントだ。
超一般的な仕事の型は、
いずれモデルやビルダーハーネス側に吸収されていく。
たとえば、

まず分解する。
仮説を出す。
必要なら調べる。
結果を比較する。
失敗したらやり直す。

このくらい汎用的な流れは、
モデルが賢くなるほど内側に取り込まれやすい。

つまり、誰にでも当てはまるレベルの仕事術だけなら、
外側にわざわざ重いハーネスを作らなくても、
モデルや製品側の進化だけでかなり回るようになる。

ここで残るのは何か。
それは、その現場に固有の判断基準 だ。

何を成功とみなすか。
何を危険とみなすか。
何が揃わないと先に進めないか。
誰の承認がないと動かせないか。
何を証拠として残さないと後で困るか。

この部分は、一般論だけでは埋まらない。
そして、こここそがユーザーハーネスの価値が出る場所になる。

ユーザーハーネスの本体は「手順」ではなく「制御契約」

ハーネスを単なる仕事術だと見ると、少しだけ弱い。

より正確には、
仕事術のうち、再現可能で、検証可能で、他者に渡せる部分を、制御可能な形に変えたもの
と捉えたほうがいい。

仕事術のままだと、「私はこう進めています」で終わる。
でもハーネスになると、次のような形まで落ちる。

この入力が来たら、まず何を見るか。
どの条件なら一旦止めるか。
どの例外は人間に返すか。
何を記録してから先へ進むか。
あとで見返したとき、なぜその判断をしたか追えるか。

ここまで来ると、
それは趣味のコツではなく、仕事を安定運用するための制御契約 になる。

だから本当に効くのは、上手いプロンプトを書くことより、
止め方、返し方、残し方を決めること だと思う。

モデルが吸収しやすいものと、最後まで外に残るもの

この話は、4回路＋証跡基盤で見ると整理しやすい。

モデルやビルダーハーネスに吸収されやすいのは、
分解、要約、草案、検索、反復のような汎用処理だ。

一方で、最後までユーザー側に残りやすいのは、次の5つになる。

状態回路
何を覚えながら進めるか。
未決事項、依存関係、担当、期限、根拠の強さ。

制御回路
どの順で進めるか。
どこで止めるか。
どこで承認を取るか。

接続回路
何を見に行くか。
誰に聞くか。
どのシステムとつなぐか。

評価回路
何を合格とするか。
どこが足りなければ不合格か。

証跡基盤
なぜそう判断したかを、あとで追えるように残すこと。

ここが弱いと、AIは便利でも怖いままになる。
ここが強いと、
モデルの出力に多少ぶれがあっても、運用全体の歩留まりは安定する。

職種ごとに見ると、価値の場所はかなり違う

この話はエンジニアリングだけのものではない。
むしろ、企画、経理、PdM、コーポレートのほうが、
ユーザーハーネスの意味が見えやすい場面も多い。

PdM

PdMで重要なのは、案をたくさん出すことではない。

誰の痛みを優先するか。
どの証拠を十分とみなすか。
どの依存関係が残っていたら Go できないか。
どの関係者の合意が必要か。

つまり、価値があるのは
仕様書の自動生成ではなく、雑に前進しない仕組み のほうだ。

企画

企画で差が出るのは、面白い案を出すことだけではない。

この組織では何が地雷か。
誰の懸念を先に処理すべきか。
どの数字を先に見せると通りやすいか。
どこまでを今回の提案に入れるべきか。

ここで効くのは、発想法よりも組織通過率を上げる制御 だ。

経理

経理では、それっぽい答えが一番危ない。
必要なのは自然な文章ではなく、正しさ、締切、監査耐性、例外振り分けだ。

証憑が足りないなら止める。
税区分が曖昧なら返す。
重要性が高いなら承認に回す。
修正理由を残す。

経理ハーネスの価値は、
自動化率の高さではなく、危険な自動化を起こさないこと にある。

コーポレート

総務、人事、情シス、法務、購買のような社内依頼をさばく領域でも同じだ。

問い合わせを分類する。
不足情報を回収する。
正しい担当へ渡す。
越権を止める。
機微情報を漏らさない。

ここで重要なのは、
うまく答えること以上に、正しい境界を守りながら流すこと になる。

つまり、ユーザーハーネスの本当の戦場は、
名文を書く場所ではなく、責任境界を守りながら仕事を流す場所だ。

だから、導入したらすぐ使いこなせるものでもない

ここも誤解されやすい。
ユーザーハーネスは、
入れた瞬間に全員が同じ成果を出せる魔法の箱ではない。

むしろ近いのは、優れたビジネス書や優れた型だと思う。

読んだからすぐ使いこなせるわけではない。
考え方を学び、
どこで守り、どこで外すかを覚え、
例外を拾う感覚を育てていく必要がある。

だから、良いハーネスには
仕組みそのものだけでなく、人間側の習熟前提 が入っている。

どこで止めるべきか。
どこから人間が見るべきか。
どのログが重要か。
どの失敗は再発防止すべきか。

この読み方まで含めて、はじめてハーネスは機能する。

最初から全部を回そうとすると壊れやすい

実務でやるなら、最初から壮大な仕組みにしないほうがいい。
最初にやるべきなのは、1職種、1業務単位、1停止条件に絞ることだ。

たとえば、

PdMなら
「証拠が弱い案件は前に進めない」

経理なら
「証憑不足の案件は自動計上しない」

コーポレートなら
「機微情報を含む依頼は自動回答しない」

このくらい小さく始める。
そのうえで、まず集めるべきは成功事例ではなく、例外ログ だと思う。

どこで止まったか。
なぜ返したか。
どんな不足が多いか。
誰の承認待ちで詰まるか。

この例外の地図ができてから、自動実行範囲を広げる。
順番を逆にすると、派手に見えるが長続きしない。

結局、何が事業価値になるのか

ここまでを一言でまとめると、

ユーザーハーネスとは、その人の仕事術のうち、勘ではなく契約として外に出せる部分を、状態・制御・接続・評価・証跡に変換したもの
だと思っている。

だから価値が出るのは、汎用的な手順を増やしたときではない。

その現場だけが持っている判断基準。
その会社だけが持っている責任境界。
その職種だけが持っている失敗コスト。
その運用だけが求める証跡要件。

そうしたローカルな目的関数 を、
再現可能な形で外に出せたときに、
ユーザーハーネスは初めて事業価値を持つ。

モデルはこれからもっと賢くなる。
だからこそ、汎用処理はどんどん下のレイヤーに沈んでいく。

そのとき最後まで残るのは、現場固有の判断と責任の構造だ。

つまり勝負どころは、
「すごいプロンプトを作れるか」ではなく、
自分たちの仕事の目的関数を、運用可能な形に変換できるか
に移っていく。

このテーマは、まだ入口にすぎない。

次はここから、
PdM、企画、経理、コーポレートの4職種それぞれで、
どんな最小ハーネスから始めるべきかを、もう一段具体化していきたい。

#生成AI #AIエージェント #AI活用 #AIハーネス #ハーネス設計 #プロンプト設計 #業務設計 #プロダクトマネジメント #知識労働 #仕事術