「ハーネス」という言葉が業務自動化の文脈で使われるようになってきた。ただ、実際に何をどう作るのかの各論は、あまり出回っていない。

私は現在、2つの現場でハーネスを運用している。事業本部の予実管理で約30本・1万行、新設拠点の運営で12本・6,000行。どちらもClaude Codeと対話しながら1本ずつ書いた。この記事は、最初の1本をどう選び、どう作り切るかの手順である。

ハーネスとは何か

まず言葉の整理から。

ハーネスは、業務システムと自分の間に置く薄いスクリプト群だ。語源のとおりロボット（自律して働くもの）ではなく、馬具にあたる。人と道具を繋いで力を引き出すものであって、人の代わりに走るものではない。

だから目標も「全部を自動化する」ではない。判断の手前まで運ぶことだ。集めて、突き合わせて、下書きを作って、dry-runで止める。そこから先は人かAIが判断する。

この線引きを最初に決めておかないと、作るものが際限なく膨らむ。

動作は4つに収まる

2つの現場で40本以上を書いてみて分かったのは、どの事例でも動作は4種類に収まることだった。

① 収集 — APIまたはブラウザから、決定的に取る。 勤怠の工数、稟議の明細、予定表、共有ドライブの表計算、チャットの会話。ここは再現可能であることが最優先で、賢さは要らない。

② 突合・投入 — 見てから流す。 工数を管理システムへ投入する、アサインと実績の配分を突き合わせる、入退社リストと組織定義の差分を出す、鍵タグの写真と管理簿を照合する。既定はdry-runで、書き込みは明示フラグを付けたときだけ起きる。

③ 生成 — 素材を作り、人が判断して書く。 週報、経営会議資料、稟議の起票、組織図。ハーネスが作るのは素材までで、文章は素材と執筆指示を読んだAIが書き、最後にまた機械がWordやPPTXに落とす。

④ 監視・通知 — 無人で回し、こぼれ球を拾う。 未回答の依頼を検出して個別に通知する、未完了タスクから「今日やるべきもの」だけを上限を決めて押し出す、週次でリーダーの活動状況を出す。定時実行の多重起動は排他ロックで防ぐ。

最初の1本は、ほぼ確実に①になる。

全体を貫く原則 — 収集と判断を必ず分ける

4つの動作を通して守っている柱がひとつある。収集は決定的に、判断はAIか人に。

会議資料の生成なら、こういう形になる。

ハーネスが素材を出す（機械的・再現可能）
  → AIが素材＋執筆指示を読んでドラフトを書く（判断）
    → ハーネスがWord / PPTXに落とす（機械的）

監視系も同型だ。「収集（決定的）→ プレフィルタ（決定的）→ 判定（AI）→ 重複抑止 → 通知」。走査そのものは決定的に済ませ、AIには絞り込んだ候補と文脈だけを渡す。

分ける理由は2つある。再現できること、そして壊れたときにどこが壊れたか分かることだ。収集と判断が混ざっていると、出力がおかしいときに「取れていないのか」「判断を誤ったのか」を切り分けられない。運用に乗せるハーネスでは、これが致命的になる。

Claude Codeのセッションを1日で閉じる

作り方の話に移る。私は「調査 → 実装 → 実運用 → 記録」を1セッションで閉じるようにしている。

1. 調査。 まず対象システムの構造をダンプする。私は各ハーネスに --discover のような調査専用モードを付けて、画面構造・HTML・APIレスポンスをすべて output/ に落としている。スクリーンショットも残す。ここで導線を確定させてから実装に入る。APIの命名規則や認証方式の癖も、この段階で確かめておく。

2. 実装。 コアを1本書き、派生は薄いラッパにする。既定はdry-run。書き込みは明示フラグを付けるまで起きない。

3. 実運用。 その日の実際の案件で使う。 これが重要で、テストデータでは分からないことが山ほど出る。件数と未マッチ項目を目で見てから流し、流した後はサーバ側の状態を引き直して、意図した結果になったかを確認する。

4. 記録。 踏んだ穴と判断を HANDOFF.md に書き戻す。次のセッションはこれを読ませてから始める。私の場合、コミットの3〜4割はドキュメントのみだ。

作るペースについてもひとつ。平常は1日1〜3コミットだが、課題が立った日に一気に作る。実際、ある月は特定の3日に9件・10件・19件と集中していた。毎日均等に進めようとするより、業務で困った日にその場で作り切るほうが、結果的に使われるものができる。

最初の1本を作る手順

以上を踏まえて、今日から始めるならこうなる。大きく作らないのが唯一のコツだ。

1. 繰り返しを1つ選ぶ。 毎週やっている転記・突合・貼り付けから1つだけ選ぶ。このとき、「送信」ではなく「読む」操作を選ぶ。最初の1本で書き込みを扱うと、事故ったときに心が折れる。

2. 接続ルートを決める。 公開APIがあるか。無ければSSOの内側か。どちらでも届かないなら、「ここは手作業のまま」とドキュメントに書く。3つ目も立派な設計判断で、自動化したつもりにしないことが後で効く。

3. Claude Codeで調査する。 構造をダンプし、スクリーンショット・HTML・APIレスポンスを残す。この段階の成果物は捨てずに置いておく。次に同じシステムを触るとき、これが一番効く資産になる。

4. dry-runで実装する。 読み取りから始める。書き込みは --commit を付けるまで起きないようにする。件数と未マッチ項目が目視できる出力にしておく。

5. HANDOFF.md を作る。 踏んだ穴と判断を書き戻す。1本目から作る。後から作ろうとすると、いちばん貴重な「最初に躓いた理由」が失われている。

6. 実案件で1日回す。 その日の仕事で使い、効いた／効かなかったを記録する。翌日、ラッパを1本足す。

なぜこれが従来の社内ツール開発と違うのか

最後に、この作り方が成立している理由について。

従来の感覚で「社内ツール開発」として見積もると、ここで挙げたものはどれも着手されない。要件定義をして、仕様を書いて、開発を発注して、という前提だと、1件30分の作業を自動化するために数十万円をかける判断にならないからだ。

AI駆動開発が変えたのは、この損益分岐点だ。1本を数時間で書けるなら、「これは来月も発生するか?」と自問して、発生するなら即スクリプト化する、というルールが成立する。私の場合、2か月で30本を超えたあたりで、定例業務のほうが例外になっていた。

もうひとつ、副次的だが大きい効果がある。業務をコードに落とす過程で、数値定義の曖昧さや構造的な誤りが表面化する。実際、集計をコードにしただけで、それまで手作業の集計に埋もれていた誤りが何度か見つかった。自動化そのものより、この検証効果のほうが金額的には効いているかもしれない。

ハーネスは、ロボットを作る仕事ではない。判断の手前まで運ぶ馬具を作る仕事だ。そう捉えると、最初の1本はかなり小さくてよいことが分かる。

どの業務から手を付けるべきか、社内でどう広げるかといった各論は、ご相談の場でお伝えできる。