AIで仕事が速くならない会社に足りない「下の層」— 人の介入を減らし、品質を一定にする「ビジネス向けハーネス」とは

AIエージェントに、人の介入を極限まで減らしたうえで、一定の品質の成果を出させる。そのためにAIを制御する仕組みを、ここでは「ビジネス向けハーネス」と呼ぶ。

この記事は、2026年9月6日の発表「MulmoTerminalと1日500コミットする生活」の後半（ハーネス3層）をもとに、ビジネスの業務向けに書き直したものです。第4節以降の提案は仮説で、検証はこれから。登場する時間・回数はすべて一例であり、実測ではありません。

目次

1. 作成は30分になった。読む時間は減っていない
2. ボトルネックは「作成後」に移った
3. ソフトウェア開発では、何が起きているか
4. ビジネス向けハーネスとは何か
5. いまあるツールで、何が足りないか
6. 核心は「文章」ではなく「項目」を作らせること
7. 五つの場面 —— Web問い合わせ、出張、会食、企画、請求書
8. 人の判断を、仕組みにする
9. 導入はここから始める
10. まだ答えが出ていないこと
11. 作るべきはアプリではなく、その下の層

• 囲み: ソフトウェア開発の用語
• 付録: 用語集、関連資料

1. 作成は30分になった。読む時間は減っていない

ある営業担当者が、生成AIで提案書の下書きを作る。以前なら半日かかった作業が、30分で終わる。 ここまでは、どの会社でも起きている。

問題はその先にある。下書きは営業部長に回り、部長が全部読む。価格の節が薄いと差し戻される。 直して再提出し、部長がもう一度全部読む。法務に回り、法務が全部読む。前提条件の記載がないと指摘される。 直して再提出し、部長が三度目を読む。客先に届くのは4〜5営業日後。人が全部読んだ回数は5回。

AIが速くしたのは「作る」工程だけで、「確かめる」工程は一歩も速くなっていない。 しかも作れる量が増えたぶん、確かめる側の負担はむしろ増えた。

これはモデルの性能の問題ではない。指示の書き方の問題でもない。 AIが作ったものを、人の目に届く前に「止める」か「通す」かを決める仕組みが、ビジネスの現場にないことが原因である。

ソフトウェア開発の世界では、この仕組みがすでに動いている。本稿ではそれをハーネスと呼び、 ビジネスの業務に移植するとしたら何が要るかを考える。

2. ボトルネックは「作成後」に移った

冒頭の提案書の流れを、人の動きで追い直す。

• 読む —— 部長が3回、法務が1回、担当者本人が1回
• 直す —— 担当者が2回
• 運ぶ —— 担当者がメールで部長へ、法務へ、客先へ
• 探す —— 翌月、別の担当者が同じ理由で差し戻され、過去のやりとりをメールから探す

AIは「作る」しか担っていない。残りはすべて人の手で、人の速さで回っている。 AIをいくら速くしても、全体の速さは「人が読む速さ」で頭打ちになる。

ここで、本稿を通して使う2つの数を置いておく。

• 人の介入回数 —— 1本の成果物が相手に届くまでに、人が読んだ・直した・運んだ回数。冒頭の例では読む5回・直す2回・運ぶ3回で、10回
• 判断の配分 —— その成果物について下された判断のうち、機械・AI・人がそれぞれ下した割合。冒頭の例では人が100%

ハーネスの目的は、この2つを動かすことにある。介入回数を入口と出口の2回まで減らし、判断の配分を機械の側に寄せる。 品質は、送付後の差し戻し・訂正・事故の件数で測る。介入を減らしてこれが増えたなら、やり方が間違っている。

3. ソフトウェア開発では、何が起きているか

ソフトウェア開発の現場では、AIがプログラムを書くようになって同じ問題に先に直面し、先に答えを出した。 筆者の開発環境では、AIが作る変更を1日に数百件、検査を通して取り込んでいる。人がその全部を読むことは不可能で、実際に読んでいない。

それでも壊れた変更が取り込まれない理由は、工程の間に機械の検査を挟み、落ちたらAIに作り直させているからだ。流れはこうなる。

1. 人が「何をしてほしいか」を1件1枚で書く。雑でよい。AIが整える
2. AIが変更を作る
3. 機械が検査する。 書き方のルール、データの種類の整合、部品ごとの動作、最初から最後までの通し動作。落ちたらAIが直して再実行する。人は見ない
4. 別のAIが読んで指摘する。 AIが直す。了承まで自動で回る
5. 人に届くのは「検査を全部通った変更」と「AIが判断を仰ぎたい点」だけ
6. 人が取り込みを決める。数分で終わる
7. 同じ指摘が2回出たら、機械のルールに固める。以後その指摘は人にもAIにも届かない

人が触るのは1と6だけ。判断の大半は機械が下し、AIは「機械が通すまで作り直す」役に徹している。 依頼・変更・検査結果・指摘・判断・記録は、すべて一か所（GitHub）にある。

ここで重要なのは、各工程の道具の名前ではなく構造である。 機械が止める。AIが作り、指摘する。人は例外だけを見る。そして全部が一か所で回り、同じ指摘は二度と人に届かない。 道具の名前と中身は、末尾の囲みにまとめた。

4. ビジネス向けハーネスとは何か

定義

ビジネス向けハーネスとは、AIエージェントに人の介入を極限まで減らしたうえで、一定の品質の成果を出させるための、 AIを制御する仕組みである。

AIの挙動は確率的で、同じ依頼でも出てくるものが毎回違う。前提条件が抜ける日もあれば、数字の出典が落ちる日もある。 ハーネスは、この揺れを決定的な制約で囲み、機械が下す判断を増やすことで、成果の側を安定させる。 AIを賢くするのではなく、AIの周りを固める。

3つの層

制御は3つの層でできている。下ほど広く、下ほど強い。

右端の列は、エンジニア向けにソフトウェア開発での対応物を示す（用語は末尾の囲みを参照）。

「止める」権限を持てるのは、決定的な層、つまり機械だけである。 AIの判定は揺れるので、止める係にはできない。止める係にすると、同じ提案書が月曜は通って火曜は落ちる。 説明のつかない判定に、現場は従わない。

ではAIの役割は何か。作ることと、指摘することである。 AIが「了承」を出す工程はあるが、それは関門ではない。AI同士で指摘と修正を回し、人に届く論点を減らすための工程である。 AIが了承しなかった点は「気になる点」として人に添えられ、最後に決めるのは人になる。

10の工程

制御はどこに置くか。業務フローを10の工程に分けると、どの工程にも「ここで誰が判断を下すか」という制御点がある。

右端の列は、エンジニア向けにソフトウェア開発での対応物を示す。

そして、この10工程を**一か所に集約する場所（ハブ）**が要る。 依頼・成果物・検査結果・判断・履歴がバラバラの場所にあると、工程の間を人が運ぶことになる。

ハーネスの仕事は、判断を上から下へ落とし続けることにある。人が読んで見つけていた論点の整理をAIの指摘へ、ルールとして書けるものを機械の判定へ。 落とすほど、人の介入は減り、品質の揺れは減る。

止めるだけでなく、差し出す

ハーネスの仕事は、検査だけではない。②の「前提の供給」は、会社の標準を渡すことに留まらない。 その仕事に関係する記録を、人が忘れているものまで含めて、全部探して差し出す。

出張の前なら、先方の担当者と前回会ったのはいつで、何を話し、何を持っていったか。会食で先方の役員は何を好み、何を控えていたか。 先方の会社に、この1か月で何があったか。Web からの問い合わせが商談になったなら、最初の問い合わせ文、インサイドセールスの聞き取り、 商談の記録、過去の提案と見積、先方の決算情報。

人は忘れる。担当者が変われば、全部消える。機械は忘れない。 ハブに記録がある限り、AIはそれを読んで、次の一手を提案する側に回る。手土産の候補、企画の骨子、見積の初期値、出張報告の下書き。 人が「思い出す」「探す」「聞いて回る」に使っていた時間が消える。

止める（④）と差し出す（②③）は、同じハブの上の同じデータで動く。片方だけでは繋がらない。 検査のためにデータにした記録が、そのまま提案の材料になる。

5. いまあるツールで、何が足りないか

ビジネスの現場に、部品がないわけではない。むしろ豊富にある。

• 作成 —— ChatGPT、Claude、Gemini、Microsoft 365 Copilot、Google Workspace の Gemini、Notion AI
• 指示の保存 —— カスタム指示、GPTs、Claude の Projects、Copilot Studio のエージェント、社内プロンプト集
• AIによる確認 —— AI契約審査（LegalOn Cloud など）は、自社基準や条項の抜けと照らしてリスクを指摘する。Copilot や Grammarly の文書レビュー
• 人の承認 —— 稟議・申請システム（kintone、ジョブカンワークフロー、rakumo、Salesforce の承認プロセス など）
• 送付・締結 —— 電子契約（クラウドサイン、DocuSign など）。契約管理や契約レビューの機能を広げている製品もある
• 機械の検査 —— Excel や業務システムの入力規則、会計ソフトの貸借一致や消込、情報漏えい対策（DLP。Microsoft Purview などは、メールや共有ドライブ、チャットを横断して機密情報の送信を検出し、止める）

それぞれは、自分の守備範囲では機能している。足りないのは個々の機能ではなく、4つの繋がりである。

欠落1: 工程が繋がっておらず、一か所に集まっていない。 依頼はチャット、前提は共有ドライブ、作成は生成AI、承認は稟議システム、送付はメール、記録は各システムの中。 工程ごとに場所が違うので、工程の間を人が運ぶ。運ぶ人の速さが、全体の速さになる。

欠落2: 機械が止める層が、文書に対して薄い。 入力規則は業務システムに入力するデータには効くが、Word や PowerPoint で書かれた提案書には効かない。 会計の検査は仕訳には効くが、見積書には効かない。DLP は個人情報など定型パターンを止めるが、 「前提条件の節が抜けている」「未確定の価格が確定形で書かれている」は見ない。 そして、AIが大量に作るのは文書のほうである。

欠落3: 差し戻しがルールに変わる経路がない。 差し戻しの理由は本人へのメールで終わる。数える仕組みがないので、「同じ指摘が2回出た」ことに誰も気づかない。 この経路がないと、人に届く件数は永遠に減らない。

欠落4: 横断の見える化がない。 自分の承認待ちは見えるが、文書の種類と部門をまたいで「いま何件がどこで何日止まっているか」は見えない。

4つは独立ではない。ハブ（欠落1）がないと見える化（欠落4）は作れず、機械の層（欠落2）がないとルール化（欠落3）の落とし先がない。 だから、部品を買い足しても繋がらない。 必要なのは、それらを一つの制御の流れに繋ぐ「下の層」である。 ただし、何でも繋げるわけではない。

繋げる条件 —— すべてをデータにし、API で動かす

ここで、ツールを選ぶ基準がひとつ決まる。

ハーネスは、工程の間を人ではなく機械とAIが運ぶ仕組みである。機械とAIが動かせるのは、 API（人の画面操作を介さず、外からそのツールを動かすための接続口）を持つツールだけだ。 人がクリックしないと動かないツールは、工程の中に人を置くことを強制する。 それは、そのツールがハーネスの外に置かれる、ということである。

したがって、基準は3つになる。

• すべてをデータにする。 依頼、成果物の項目、検査結果、判断と理由、送付の記録。さらに規定、予算と承認の記録、メールやチャットでの合意も。人が読む文章や画面ではなく、機械とAIが読み書きできるデータとして持つ
• すべてを API で動かす。 作成、検査、承認、送付、記録のどれも、機械とAIが API から呼べること
• API のないツールは、ハーネスに入れない。 便利な機能があっても、人が操作しないと動かない時点で、人の介入回数を減らせない

画面（GUI）の役割も、ここで決まる。画面は、人が最終確認をするための閲覧用である。 人が押すのは「通す」「戻す」「送ってよい」といった最小限のボタンだけでよい。 機能を画面に積み上げ、人が操作して仕事を進める設計の製品は、人が工程を運ぶ前提で作られている。 ハーネスの考え方とは向きが逆で、便利に見えるほど人の介入を固定する。

この基準で見ると、第4節の10工程に載せられるのは、データと API を持つものに限られる。 既存の承認システムや電子契約も、API で繋げるなら残し、繋げないなら置き換える。

6. 核心は「文章」ではなく「項目」を作らせること

機械が止める層を文書に対して作るには、ひとつ発想を変える必要がある。 AIに文章を書かせるのをやめ、項目を出させる。

項目を正にする

いまの使い方は、AIに「提案書を書いて」と頼み、文章が出て、人が読む。 提案するのは、AIに「提案書の中身を項目として出して」と頼むことだ。 課題・打ち手・範囲・価格・前提条件・各数字の出典、が項目として出る。 それを機械が検査し、通ったものだけを文章に仕立てる。

見積書 = 項目（品目・単価・数量・条件・有効期限） + 文章化
提案書 = 項目（課題・打ち手・範囲・価格・前提条件） + 文章化

項目を正とし、文章はその出力にする。 手に入るものは4つある。

• 検査が書ける —— 「価格が1つ以上ある」「決定事項には担当者と期限がある」が、項目に対するルールになる。文章を読み解く必要がない
• 変更が意味で見える —— 「前回版と何が変わったか」が、文章の差分ではなく「価格が変わった」「前提条件が1つ増えた」になる。決裁者が見るべきものはこれで足りる
• 矛盾が作れなくなる —— 提案書と見積書が同じ「価格」項目を参照していれば、ずれようがない
• 言い回しの違いで検査が落ちない —— AIは同じ依頼でも毎回文章が変わる。項目を比べれば、意味が変わったときだけ落ちる

順番を逆にしてはいけない。「文章を書かせる → AIに項目を抜き出させる → 検査」は、抜き出しが揺れるので検査対象が推定値になる。 「項目を作らせる → 検査 → 文章に仕立てる」の向きで、検査対象が正になる。 AIを「通す / 落とす」の判定には使わず、作成と指摘に使う。 作成は揺れてよい。落ちたら通るまで作り直させればいい。

機械でできる検査と、AIに残る検査

ここは正直に線を引く必要がある。機械が決定的に検査できるのは、項目同士の照合である。

左の列は「誰が見ても同じ答え」になるので、機械に任せられる。任せた瞬間、その観点は人の判断から消える。 右の列は揺れるので、AIが指摘はするが止めはしない。最後は人に残る。

文書の外にある事実と突き合わせる

文書を単体で検査しても、「正しい文書」にはならない。 請求書は、見積書・発注書・納品の記録と一致して初めて正しい。稟議書は、承認済みの予算に紐づいて初めて通せる。 企画書は、それを決めた会議と、それを賄う年度の予算に紐づいて初めて動かせる。 提案書の価格は、メールやチャットで相手と合意した価格と一致していなければならない。 経費は、誰が・誰と・何の目的で使ったかが、規定の範囲内で明示されていなければ通さない。

つまり検査の相手は、文書の中だけでなく、文書の外にある4種類の事実である。

• 経緯 —— メール、チャット、会議で、相手や社内と合意した価格・納期・範囲。企画なら、それを決めた会議の決定事項
• 規定 —— 経費規定、決裁基準、価格と値引きの方針、法務回付の条件、会議体ごとの決裁権限
• 関連書類 —— 見積書・発注書・納品記録・契約書・前回の議事録・過去の企画書
• 計画と予算 —— 年度予算とその残高、中期計画や事業計画の目標、承認済みの決裁記録

これが、第5節で「すべてをデータにする」と言った理由である。 規定が PDF の中にあり、合意がメールの中にあり、予算が表計算の中にあるうちは、照合は人の仕事になる。 データとして一か所にあれば、照合は機械の仕事になる。

根拠の連鎖 —— 書類は単独では存在しない

ここから第6節の終わりまでは、仕組みの中身に踏み込む。導入を判断するだけなら、第7節の場面と第9節の手順を先に読み、本節の表には実装のときに戻ってくればよい。

会社の書類は、前の書類を根拠にして作られる。典型的な連鎖はこうなる。

会議の決定 → 企画書 → 稟議書 → 発注書 → 納品・検収 → 請求書 → 支払い → 経費精算
      ↑          ↑          ↑                             ↑
 中期計画・事業計画  年度予算（枠と残高）  見積書・契約書      事前申請・予算

横の矢印が書類の順番、縦の矢印が、その書類を下から支える根拠である。 年度予算は主線の上にはない。年度の初めに承認された枠と残高として、企画書・稟議書・発注書を支える側にある。 矢印の一本一本が「参照」である。企画書は会議の決定事項番号と予算科目を持ち、稟議書は企画書番号と予算番号を持ち、 請求書は発注番号と検収番号を持つ。参照が番号で繋がっていれば、機械は各参照について同じ5つを確認できる。

1. 存在 —— 参照先の記録が実在するか
2. 状態 —— 参照先が「承認済み」「有効」か。却下された企画、失効した見積、締め切った年度の予算を参照していないか
3. 数値 —— 金額・数量・期間が参照先と一致するか。予算なら残高の範囲内か
4. 期間 —— 年度・会計期間が一致するか。今年度の企画が前年度の予算枠を指していないか
5. 権限 —— 起案者・承認者が、規定上その書類を起案・承認できる立場か。会議体が、その決定を下せる権限を持っていたか

根拠の連鎖を文書別に見ると、参照すべき根拠と確認する内容は次のようになる。

この表の右列は、番号・状態・数値・期間・権限・項目値の照合であり、機械が決定的に判定できる。 いま「根拠は？」「予算はあるの？」「それ、いつの会議で決まったの？」と人が口頭で確かめている部分が、ここに入る。

参照はどう作られるか

参照を人が手で書くなら、昔の稟議と同じで続かない。作るのはAIで、確かめるのは人、照合するのは機械、と分ける。

• AIが根拠を探して紐づける —— 企画書を作るとき、AIがハブの中から該当する会議の決定事項、予算科目、事業計画の目標を探し、番号で紐づける
• 人が一度だけ確認する —— 「この会議の、この決定が根拠で合っているか」を起案者が確認する。自由文からの読み取りは揺れるので、ここは人が見る
• 以後は機械が照合する —— 紐づいた番号同士の存在・状態・数値・期間・権限を、上の5項目で機械が確認する。稟議に進むとき、発注に進むとき、請求が来たとき、そのたびに自動で

経緯の扱いだけは、同じ理由で注意が要る。メールやチャットの自由文から「合意した価格」を読み取るのはAIの仕事で、揺れる。 だから、読み取った合意は項目として依頼票に紐づけ、人が一度確認する。以後の照合は項目同士で機械が行う。 向きはこの節の冒頭と同じで、自由文を毎回読ませるのではなく、一度項目にして正にする。

経費は、この照合が最も効く場所である。「誰が・誰と・何の目的で・いくら」が項目として揃い、 予算番号と承認記録に紐づき、規定の上限内であることまでを機械が確認する。 揃っていなければ、人の目に届く前に差し戻す。承認の通っていない予算で動く経費は、そこで止まる。 同じことが企画にも言える。根拠となる会議の決定と、当年度の予算枠に紐づかない企画は、稟議に進めない。

同じ話を、検査の種類別に並べ替えると次のようになる（列は、本節冒頭の表の左側に対応する）。いずれも、項目・印・番号として構造化されている場合に機械で判定できる例であり、自由文の意味を読ませるものはAIの確認に残る。

いま法務や営業管理が目で追っている指摘のうち、この表に入るものがどれだけあるか。それがそのまま、機械に落とせる量になる。

作る仕組みも検査する

出来上がった1本を検査するだけでは足りない。 テンプレート・AIへの指示・業務手順を変えたとき、出てくる成果物の性質が保たれているかも検査する。

実際に起きる壊れ方は、どれも静かに起きる。 提案書テンプレートの体裁を直したら前提条件の節が消えた。AIへの指示を短くしたら見積書に有効期限が出なくなった。 基幹システムの項目名が変わり、売上見込みが0のまま出た。

対策は、固定した入力（過去の案件数件分）を用意しておき、仕組みを変えるたびに自動で生成し直して上の検査を通すこと。 落ちたら、その変更を止める。人が気づくのを待たず、変えた瞬間に赤くなる。 ソフトウェア開発ではこれを「テスト」と呼び、AIがテスト自体を書くので、用意するコストは以前より大きく下がっている。

最後の一歩

項目を文章に仕立てる工程もAIにやらせるなら、文章化のあとにもう一度検査が要る。 文章にする段階で、項目にない数字を足す、未確定を確定形に言い換える、ということが起きるからだ。

ここでも線を引く。項目にある数字・日付・固有名詞が文章にすべて現れているかは、機械で照合できる。 文章に項目にない主張が混ざっていないかは、文章の意味を読む必要があるので、AIの確認に残る。 この後半を機械に落としたいなら、文章化を定型文で機械的に行えばよい。検査自体が要らなくなるかわりに、文章は硬くなる。 どこまでAIに書かせるかは、この釣り合いで決める。

7. 五つの場面 —— Web問い合わせ、出張、会食、企画、請求書

ここまでの話を、実際の業務の流れに当てはめる。流れは一般的な実務の手順に沿っている。時間と回数は一例である。 以下の「人が触った回数」は、第2節の数え方を業務フロー単位に広げ、各場面に含まれる確認・承認・選択・実行の指示を数えたものである。

場面1: Web問い合わせから、提案書が客先に出るまで

今

先方の情報システム部門の課長が、自社サイトの問い合わせフォームに書く。「既存の販売管理システムとの連携が必須。来期予算の範囲で検討したい」。 フォームの内容は営業事務にメールで届き、インサイドセールスに転送される。インサイドセールスが電話で聞き取る。予算感、導入時期、決裁者、競合の有無。 メモは本人のノートに残る。「温度感高め」とチャットで営業に引き継ぐ。営業が訪問し、商談する。 営業は過去の提案書を共有ドライブから探し、生成AIで下書きを作る。問い合わせ文の「連携が必須」も、電話で聞いた「決裁者は情シス部長」も、営業は知らない。 あとは冒頭の流れになる。部長が3回読み、法務が1回読み、4〜5営業日後に送付。

ハーネスがあるとき

1. フォームの内容が、そのまま依頼票になる（①）。先方の会社名・担当者・問い合わせ文・流入経路が項目として入る
2. インサイドセールスの聞き取りは、通話後にAIが項目に起こす。予算感 / 導入時期 / 決裁者 / 既存システム / 競合。聞き取った本人が一度確認して、依頼票に紐づく（①⑥）
3. 商談の記録も同じく、AIが項目に起こし、営業が一度確認する。合意した範囲、先方が懸念した点、次回までの宿題（①⑥⑧）
4. AIが提案書の項目を出す。このとき、問い合わせ文・聞き取り・商談記録・先方の決算短信・過去の類似案件を自分で参照する。「既存システムとの連携」は範囲に、「来期予算」は前提条件に、「決裁者は情シス部長」は提案の宛先に、人が言わなくても入る（②③）
5. 機械が検査する。価格が見積書と一致、前提条件が揃っている、導入実績の数字に出典欄、「未確定」の印が付いた価格が確定形になっていない。落ちたらAIが直す（④）
6. 別のAIが読む。「連携の方式が先方の質問に答えていない」。AIが直す。残った1点を気になる点にする（⑤）
7. 部長の一覧に、項目と気になる点が載る。部長は項目だけを見て、送ってよいところまで承認する。法務回付の条件に当たらないことは機械が確認済み（⑥）
8. 文章化し、照合し、宛先と版を確認して送る（⑦）。依頼票に全部残る（⑧）

人が触ったのは、聞き取りの確認、商談記録の確認、部長の承認の3回。先方が最初に書いた「連携が必須」が、人の記憶を経由せずに提案書に届く。

場面2: 出張 —— 申請から、手土産、報告、精算まで

今

商談で「来週、先方本社に伺います」と決まる。帰社して出張申請を申請システムに入れる。日程、目的地、目的、概算額。上長が承認する。 新幹線と宿は本人が手配する。前日、「手土産どうしよう」。前回何を持っていったか覚えていない。先方に何人いるかも曖昧なまま、駅で買う。 帰ってから出張報告書を書き、旅費精算書に交通費・宿泊費・日当を書いて領収書を貼る。経理が旅費規程と照合し、運賃の妥当性を確認する。 宿泊費が規程の上限を超えていて差し戻し。本人が理由を書いて再提出。

ハーネスがあるとき

1. 商談記録に「次回: 先方本社訪問、○月○日」が項目として入った時点で、AIが出張申請の項目を起こす。日程 / 目的地 / 目的 / 概算額 / 紐づく案件番号。本人は項目を確認して「申請してよい」を押す（①②③⑥）
2. 機械が照合する。宿泊費が規程の上限内、日当の区分が目的地と一致、案件の旅費枠に残高がある（④）。通ったものが上長の一覧に載り、上長は「行ってよい」を押す（⑥）
3. 新幹線と宿は、承認と同時に API で手配される（⑦）
4. 出張の前日、AIが差し出す。先方の出席者3名の氏名と役職。前回訪問は4月で、持参したのは焼き菓子。会食の記録に「先方役員は甘いものを控えている」とある。先方の直近のプレスリリース。前回の宿題で未回答のもの（②）
5. 手土産の候補を2つ提案する。人数分で個包装、常温で日持ちし、前回と重複せず、先方役員の好みに合い、先方の近所の店ではないもの。経費は接待交際費の規程内（③）。人は選ぶだけ（⑥）
6. 帰路、AIが出張報告と精算の項目を起こす。会議の記録から報告の骨子、交通系ICと法人カードの明細から交通費と宿泊費、規程から日当（②③）
7. 機械が照合する。日付が出張期間内、金額が明細と一致、宿泊費が上限内、日当の区分が正しい、同じ明細の二重申請がない（④）
8. 本人は項目を確認して「精算してよい」を押す（⑥）。経理に届くのは、深夜のタクシー利用のように規程上の理由が要る例外だけ

人が触ったのは、本人が3回（申請を確認する、手土産を選ぶ、精算を確認する）、上長が1回。経理はゼロか、例外のときだけ。

場面3: 会食の経費精算

今

先方の部長ら3名と会食する。領収書をもらう。翌週、経費精算システムに入力する。日付、店名、金額、参加者。 税務上、接待飲食費には年月日・参加者の氏名と関係・人数・金額・店名と所在地の記録が要る。1人あたり1万円を超えるかどうかで扱いも変わる。 参加者の会社名と役職を思い出しながら書く。上長が承認し、経理が確認する。「参加者の関係が書かれていない」で差し戻し。

ハーネスがあるとき

1. 会食の予定は、商談記録に紐づいている。案件番号、先方の出席者3名、自社2名（⑧）
2. 法人カードの明細が API で入る。AIが精算の項目を起こす。年月日 / 店名と所在地 / 金額 / 参加者の氏名・会社・関係 / 人数 / 目的（案件番号）/ 1人あたりの金額（②③）
3. 機械が照合する。参加者が商談記録の出席者と一致、1人あたりの金額で区分が正しい、規程の上限内、事前申請と一致、同じ領収書の二重申請がない、予算の残高内（④）
4. 通れば、本人は「申請する」を押すだけ（⑥）。経理に届くのは、規程を外れたものだけ

人が触ったのは、本人の1回。「誰が・誰と・何の目的で・いくら」は、人が思い出して書くのではなく、商談記録とカード明細から、AIが項目を起こし、機械が照合する。

場面4: 企画書から、稟議と年度予算まで

今

部内会議で「来期、販売代理店向けの研修プログラムをやろう」と決まる。担当者が企画書をゼロから書く。 予算はどの科目に枠があるか、経理に聞きに行く。中期経営計画のどの目標に効くのか、企画書の冒頭に書くが、根拠は記憶。 稟議書には件名・目的・金額・費用対効果・リスク対策を書き、課長、部長、役員の順に回覧する。 役員で差し戻し。「この科目の枠はもう使い切っている」「2年前に似た企画をやって中止になったはずだが、その検証は？」

ハーネスがあるとき

1. 会議の議事録に、決定事項「研修プログラムを企画化する。担当: A、期限: 3月15日」が項目として残っている（⑧）
2. AIが企画書の項目を起こす。このとき、決定事項の番号、年度予算の該当科目と残高、中期経営計画の目標番号、過去の類似企画とその結果を参照して差し出す。「2年前の代理店研修は中止。理由: 参加率が想定の半分」が、人が覚えていなくても企画書の「過去の経緯」に入る（②③）
3. 起案者が「この会議の決定・予算科目・中期計画の目標で合っている」ことを一度確認する（⑥）
4. 機械が照合する。決定事項が存在し、担当者が起案者と一致。予算科目が当年度で承認済みで、残高が企画の金額以上。中期計画の目標との対応が項目として付いている。過去企画の結果が参照されている（④）
5. 別のAIが読む。「効果試算の根拠が、参加率の前提を置いていない」。AIが直す。残った点を気になる点にする（⑤）
6. 部長の一覧に、項目と気になる点が載る。部長は根拠の紐づきと気になる点を見て、通す（⑥）
7. 稟議書は、AIが企画書の項目を引き継いで起こす。添付の見積書と金額が一致、金額が決裁基準で役員決裁に当たることを機械が判定し、役員の一覧に載せる（③④）
8. 役員は、会議の決定・企画・年度予算・見積が番号で紐づいていることと、気になる点だけを見て決裁する（⑥）

人が触ったのは、起案者が1回（根拠の確認）、部長が1回、役員が1回。「枠は残っているか」「前にやって失敗していないか」は、回覧の途中で人が気づくのではなく、起案の時点で機械が確認している。

場面5: 請求書が届いてから、支払いまで

今

取引先から請求書が PDF でメールに届く。経理が、発注書・納品書と突き合わせる。 宛名が自社か、発行者が想定の取引先か、内容と金額が発注と一致するか、税率、適格請求書の登録番号、振込先、支払期限。 発注書が見つからない。検収が終わっているか担当者に聞く。金額が見積と違う。担当者に聞く。返事が来るまで支払いが止まる。

ハーネスがあるとき

1. 請求書の PDF を、AIが項目に起こす。発行者 / 登録番号 / 品目 / 金額 / 税率 / 振込先 / 支払期限（③）
2. 機械が照合する。発注番号が存在し承認済み。検収記録が完了している。品目と金額が発注書と一致。登録番号が公表されている番号と一致し有効。振込先が取引先の記録と一致している（振込先の変更は、別の承認が要る）。支払期限が契約書の条件と一致。予算の残高内（④）
3. 通ったものが経理の一覧に載る。経理は「支払ってよい」を押す（⑥）。支払いは API で実行され、仕訳が起きる（⑦⑧）
4. 落ちたものは、理由付きで担当者に戻る。「検収が未完了」なら担当者の一覧に「検収を登録してください」が載り、登録した瞬間に照合が再実行される（④⑨）

人が触ったのは、経理の1回。例外のときに担当者が1回。「担当者に聞く」というやりとりが、一覧上の状態の変化に置き換わる。

五つの場面に共通すること

• 人が触るのは、入口と出口と、機械にもAIにも判断できなかった例外だけ
• 「思い出す」「探す」「聞いて回る」が、ハブの中の参照に置き換わる。人が忘れていることを、機械が差し出す
• 止める検査と、差し出す提案は、同じデータで動く。会食の出席者は、手土産の提案にも、経費の照合にも使われる
• 差し戻しの理由は、メールではなく、一覧の上の状態として数えられる

8. 人の判断を、仕組みにする

AIの確認に残る判断がある以上、人の評価は消えない。消えないなら、評価の仕方を仕組みにする。要素は3つ。

1. 可視化 —— いま人の判断を待っているのは何件か。どこで止まっているか。誰の手元か。文書の種類と部門をまたいで一画面に出す
2. 評価の口 —— その場で通す / 戻す / 理由を選ぶ。会議やメールに持ち出さない。理由を選択式にするのは、数えるため
3. 評価がルールに変わる経路 —— 同じ理由が2回出たら、ルール化の候補。構造・整合・禁止のどれかに書けるなら機械の検査に落とし、書けないならAIへの指示書に足す

3つ目がないと、AIの確認と同じで「知らせるだけ」で終わる。 これを人が気づくのではなく、仕組みが数える。 新しいルールは、警告として入れ、既存の違反をゼロにしてから、エラーに上げる。

溜まった人の判定は、2つの問題も解く。 たとえばAIにリスクの点数を付けさせる場合、「80点未満は人に確認を回す」の80に根拠がなくても、通した / 戻したの分布から、どこから人に見せるかの線が引ける。 AIのモデルを更新したときは、過去の人の判定を正解として全件を再判定し、答えが変わった件を検出できる。

評価の蓄積は使い勝手の改善ではなく、人に届く件数を減らし続ける機構そのものである。

9. 導入はここから始める

全部を一度に作る必要はない。最初の3か月は、次の順でよい。

1. 測る —— 手元の提案書・議事録・契約書を10本取り、依頼から送付までの人の介入回数と、判断の配分（機械・AI・人）を数える。過去の指摘のうち、第6節の表で機械判定できるものの割合も数える
2. 構造・整合と、予算・承認との照合を機械検査にする —— 項目の有無、数字の一致、承認済み予算への紐づけ。出典の妥当性や文章の良し悪しには手を出さない
3. 送付直前の照合を入れる —— 宛先と版が承認されたものと一致するか。取り消せない点の直前に、決定的な検査を1つ置く
4. 差し出す対象を1つ選ぶ —— 出張前の過去訪問・会食・宿題、または提案書を作る前の問い合わせ・聞き取り・過去提案。検査に使うデータを、作成の前にAIへ渡す
5. 差し戻し理由を選択式にして集計する —— 同じ理由が2回出たものを、検査ルールの候補として並べる
6. 既存の承認システム・電子契約は、API で繋げるものは繋ぎ、繋げないものは置き換える —— 工程の間を人が運んでいる箇所を、機械が運ぶように変える

想定される反論にも、先に答えておく。

「既存のSaaSで十分ではないか」 —— 個々の機能はすでにある。足りないのは、文書の種類をまたいで、依頼から改善まで同じ制御の流れで回すこと。 第5節の4つの欠落は、どれも製品の機能ではなく、製品の間の繋がりである。そして API を持たない製品は、その繋がりを作る側に立てない。API で繋ぐだけでも足りない。出張前に前回の会食の記録を差し出せるのは、記録がその粒度でデータになっているときだけである。

「法務や監査が、AIによる自動化を許すのか」 —— この設計では、AIに止める権限を与えない。止めるのは決定的な機械の検査で、 何を通し何を落としたかが依頼票にすべて残る。人の最終判断も残る。法務に回す条件そのものも、機械が確認するルールとして明文化される。 むしろ、人がメールで回していた判断よりも、記録が残り、再現できる。監査には向いている。

「品質が落ちないか」 —— 送付後の差し戻し・訂正・事故の件数で測る。介入を減らしてこれが増えたら、落とし方を一段戻す。 測る仕組みを先に置くのは、そのためである。

10. まだ答えが出ていないこと

評価のコストを誰が払うか —— 全成果物を人が評価するなら、ボトルネックが動いただけで減っていない。 見える化の仕事は「見やすくする」ことではなく「人に届く件数を減らし続ける」ことで、そこが効かないと成立しない。

形を固定できない領域 —— 相手ごとに構成が変わる提案書のようなものに、どこまで項目を強制できるか。強制しすぎると質が落ちる。

評価者によって判定が割れる —— 人の判定を正解として溜める前提だが、そもそも人によって違う。誰の判定を正とするのかが決まらない。

既存システムとの接続 —— 承認システム・電子契約・CRM をハブに繋ぐのは、技術よりも運用の問題が大きい。移行の順番が決まっていない。

11. 作るべきはアプリではなく、その下の層

ソフトウェア開発では、GitHub や CI のような共通基盤があり、その上に各プロジェクトのルールやテストを載せる。 ビジネス側にはこの共通基盤に当たる層がまだ薄く、いまは各社が業務ごとにプロンプトを書き、承認経路を組み、送付の手順を決めている。 毎回ゼロからやっている。

基盤を先に持てば、上に載せる業務は格段に速くなる。そしてこの基盤は溜まる。載る業務が増えるほど、 検査ルールが増え、人の判定が溜まり、機械で落とせる量が増えて、人に届く件数が減る。 載る業務が増えるほど基盤が強くなる。 ここが普通のツールと違う。

依頼・検査・承認・送付・記録の仕組みは、どの事業でも必要で、どこも差別化しない。 だからこそ、事業ごとに作るのではなく、共通の層として持つ価値がある。

筆者注: この「共通の層」は、9/5 の SS Connect で話した Compound Startup 構想（事業側はコアだけを持ち、コア以外を共通インフラに寄せる）の具体的な中身のひとつにあたる。

囲み: ソフトウェア開発の用語

第3節の流れに出てくる道具を、ビジネスの言葉に置き換えて短く説明する。

付録A 用語集

付録B 関連資料

• ハーネスとは「モデル以外のすべて」——公式定義と実装6例を読む —— ハーネスとは何か（ソフトウェア側の定義と実装例）
• 発表「MulmoTerminalと1日500コミットする生活」の資料 —— 3層ピラミッド / 落とせるだけ下へ / 開発フロー
• 文書を項目として検査する、ソフトウェア側の先行例（技術者向け）: Schematron（ISO/IEC 19757）、remark-lint、textlint

第7節の業務の流れは、次の資料を参考にした。

• 稟議の流れと必須項目: https://biz.moneyforward.com/contract/basic/18534/、https://www.docusign.com/ja-jp/blog/ringi-and-kessai
• 接待飲食費の保存要件: 国税庁 https://www.nta.go.jp/publication/pamph/hojin/tebiki2019/pdf/03-15.pdf、https://www.habitto.com/blogs/settai-kousaihi-kanri-hoho-kaisetsu/
• 出張申請と旅費精算: https://kigyolog.com/article.php?id=962、https://biz.moneyforward.com/payroll/basic/56872/
• Web問い合わせから商談まで: https://www.issoh.co.jp/column/details/15250/、https://www.salesforce.com/jp/blog/?p=15046
• 請求書の受領と照合: https://biz.moneyforward.com/invoice/basic/7080/、https://www.freee.co.jp/kb/kb-invoice/flow-invoice/
• 年度予算と中期経営計画: https://www.issoh.co.jp/column/details/17935/、https://www.pwc.com/jp/ja/knowledge/guide/ipo-guideline/profit-management.html
• 取引先への手土産: https://precious.jp/articles/-/5398、https://allabout.co.jp/gm/gc/1363/