新しい便利ツールが出るたびに試してみる。最初の30分は感動する。けれど1週間後には元のやり方に戻っている——。心当たりのある方は、決して少なくないはずです。

これはプログラマーだけの話ではありません。文章を書く人も、資料をつくる人も、経理や人事の仕事をしている人も、ここ数年で「AIに頼めば一瞬で終わるはず」と言われ続けてきました。それなのに、体感として仕事が半分の時間で終わるようになったかというと、多くの人が首をかしげるのではないでしょうか。

GitHub（ソフトウェア開発者が世界中でコードを共有・共同編集しているサービス）の公式ブログに、この違和感を正面から扱った記事が公開されています。タイトルは「The harness is all you need (mostly)」——直訳すると「必要なのは（だいたい）ハーネスだけだ」。公開元の概要によれば、次から次へと登場するAIツールを追いかけ回すのではなく、プロトタイプ（試作）・計画・実装・レビューという一連の流れを回すための実践的な作業手順を扱った記事だとされています。

なお、筆者は本稿執筆時点でこの記事の本文全体を直接確認できていません。したがって以下で紹介する「ハーネス」という考え方の中身は、記事の公開概要から読み取れる範囲と、一般に知られているAI活用の実務知見にもとづく解説です。記事内の具体的な数値・事例・推奨設定については未確認であることを、あらかじめお断りしておきます。

「ハーネス」とは何か——道具ではなく、道具の使いどころ

ハーネス（harness）はもともと、馬に取り付ける「引き具」を指す言葉です。馬車を引かせるとき、馬そのものがどれだけ速く走れても、引き具が正しく取り付けられていなければ荷車は前に進みません。力を出せるかどうかは、馬の性能より「つなぎ方」で決まるわけです。

ソフトウェア開発の文脈では、この言葉は「AIを仕事の流れの中にどう組み込むか、その枠組みそのもの」を指して使われます。もう少しかみ砕くと、次のようなものの総称です。

• AIに何をどこまで任せるかの役割分担のルール
• AIに渡す前提情報（コンテキスト）の準備の仕方
• AIが出した成果物を誰が・どの基準で確認するか
• うまくいかなかったときにどこまで戻ってやり直すか

「コンテキスト」という言葉は、平たく言えば「話の前提」です。人間の同僚に仕事を頼むときも、前提を何も伝えずに「いい感じにやっておいて」と言えば、返ってくる成果物はまず期待とずれます。AIはこの点で人間より優秀ではありません。むしろ、遠慮なく自信満々にずれた成果物を出してくる分だけ厄介です。

つまり「最新のAIモデルに乗り換えれば解決する」という発想が空振りしやすいのは、ボトルネックが馬（＝AIの賢さ）ではなく引き具（＝仕事の渡し方と受け取り方）の側にあるからだ、というのがハーネスという考え方の核心です。

4つの工程：プロトタイプ・計画・実装・レビュー

公開概要で挙げられている工程は4つです。それぞれを、専門用語を使わずに整理してみます。

1. プロトタイプ（試作）

いきなり完成品をつくらず、まず「動く粗いもの」を短時間でつくる段階です。料理でいえば味見、企画でいえば手書きのラフスケッチにあたります。

AIはこの段階が非常に得意です。完成度は低くても、形があると議論が具体的になるからです。逆に言えば、この段階の成果物を「もうできた」と勘違いして次に進むと、後で大きくやり直すことになります。

2. 計画

「何をつくるか」「どういう順番でつくるか」を言葉にする段階です。ここは実は、AIに丸投げしてはいけない部分と、任せてよい部分がはっきり分かれます。

何を優先するか、どこまでの品質でよしとするか——こうした判断は、その仕事の事情を知っている人間にしか下せません。一方で、決めた方針を漏れのない手順書に整形したり、抜けている観点を洗い出したりする作業は、AIに任せると速くなります。

3. 実装

実際に手を動かしてつくる段階です。プログラミングでいえばコードを書く工程で、AIが最も注目されてきた領域でもあります。

ただし重要なのは、この工程の速さだけを上げても全体は速くならない、という点です。前工程の計画が曖昧なら、速く書けば速く間違えるだけになります。「AIで実装が10倍速くなった」という話が、チーム全体の成果に結びつかない例が多いのはこのためです。

4. レビュー（確認）

つくったものを別の目で確かめる段階です。プログラミングの世界では「プルリクエスト」という仕組みで、変更内容を他のメンバーが読んでから本番に反映する慣習が定着しています。

AIが大量の成果物を出せるようになると、この確認工程に負荷が集中します。10倍の量が出てきても、確認できる人間の数と時間は10倍にはなりません。ハーネスを設計するときに最も丁寧に考えるべきなのは、実はここだと言えます。

一般の仕事にも効く「ハーネス思考」

この4工程は、ソフトウェア開発以外の仕事にもほぼそのまま当てはまります。

たとえば提案資料をつくるとき。「AIに提案書を書かせる」と考えると、たいてい当たり障りのない文章が出てきて使えません。ですが工程を分けて、

1. まず論点だけを箇条書きで10案出させる（試作）
2. その中から自分が本当に主張したいものを3つ選び、構成を決める（計画）
3. 決めた構成に沿って各パートを書かせる（実装）
4. 「顧客の立場から見て弱い箇所はどこか」と別途問い直す（レビュー）

と進めれば、成果物の質は目に見えて変わります。変わったのはAIの性能ではなく、渡し方と受け取り方——つまりハーネスの側です。

ここで大事なのは、自分の仕事の型を一度決めたら、しばらくそれを変えないことです。ツールを乗り換えるたびに型もリセットしていると、いつまで経っても「最初の30分の感動」を繰り返すだけになります。

注意点：ハーネスを過信しないために

一方で、「型さえ整えれば万事解決」と受け取るのも危険です。実務で押さえておきたい注意点を挙げます。

確認工程を省略しないこと。 AIの出力は、もっともらしいけれど事実と異なる内容を含むことがあります。特に、数値・固有名詞・法令や規約に関する記述は、必ず一次情報にあたって裏を取る必要があります。本稿でも、参照元記事の本文を直接確認できていない部分は「未確認」と明記しているのは、そのためです。

型を作ること自体が目的化しないこと。 手順書やルールを整備しすぎると、今度はその維持に時間が取られます。実際に効果が出ている工程だけを残し、使われていないルールは定期的に捨てる勇気が要ります。

機密情報の取り扱いを先に決めること。 顧客情報や社外秘の資料をどこまで外部サービスに渡してよいかは、組織ごとにルールが異なります。ハーネスを設計するなら、この線引きは最初に固めておくべき項目です。なお、個別のAIサービスがデータをどう扱うかは提供事業者ごとに条件が異なり、本稿では未確認です。利用前に各サービスの公式な利用規約とデータ取り扱い方針をご確認ください。

「速さ」ではなく「やり直しの少なさ」で測ること。 AI活用の効果測定を「何分で書けたか」で行うと、後工程での手戻りが見えなくなります。最終的に世に出るまでに何回やり直したか、という指標のほうが実態に近くなります。

まとめ

• 仕事が速くならない原因は、AIの性能より「渡し方・受け取り方の枠組み（ハーネス）」にあることが多い
• 試作 → 計画 → 実装 → 確認 の4工程に分け、それぞれで人間とAIの役割を決める
• 判断は人間、整形と洗い出しはAI、という線引きが実務では機能しやすい
• AIの出力が増えるほど確認工程が詰まる。ここを最初に設計する
• 型は決めたらしばらく変えない。ツールを変えるたびにリセットしないこと

新しいツールが出るたびに試すこと自体は悪いことではありません。ただ、そのたびに仕事の型ごと作り直していては、いつまでも助走のままです。まずは自分の仕事の中で最も時間を食っている工程をひとつ選び、そこだけAIとの分担を決めてみる。ハーネスづくりは、そのくらい小さく始めるのが現実的です。

参考資料

• The harness is all you need (mostly) — The GitHub Blog（本稿執筆時点で本文全体は未確認。公開概要にもとづき言及しています）