新しい家電を買って、付属のマニュアルどおりにボタンを押したのに、書かれているメニューがどこにも見当たらない。アプリのヘルプページを開いたら、画面のスクリーンショットが自分の見ている画面とまるで違う。そんな経験はないでしょうか。

腹立たしいのは、製品そのものが悪いわけではないことです。中身は改良されている。ただ、その改良を「説明する文章」だけが追いついていない。だから使う人は、正しいはずの手順書に裏切られます。

これは家電やアプリに限った話ではありません。社内の業務マニュアル、引き継ぎ資料、規程集。どれも「作られた瞬間が一番正確で、そこから毎日少しずつ嘘になっていく」という性質を持っています。書き換えるべきタイミングで書き換えられないのは、担当者が怠慢だからではありません。中身を変えた人と、説明を書く人が別だからです。中身を変えた人は「変えた」という事実を知っていますが、説明を書く担当ではない。説明を書く人は担当ではありますが、「何が変わったか」を知る手段がない。この情報のすれ違いが、ズレを生み続けます。

ソフトウェア開発の世界では、この問題が特に鋭い形で現れます。製品のコードと、その使い方を説明するドキュメントが、別々の保管場所（リポジトリ）に置かれていることが珍しくないからです。コードを直した人は自分の保管場所での作業を終えて満足しますが、隣の保管場所にあるドキュメントは手つかずのまま残ります。

GitHubのブログで公開された記事「Automating cross-repo documentation with GitHub Agentic Workflows」は、まさにこの「保管場所をまたいだズレ」に、AIエージェントで対処しようという試みを扱っています。

何をしようとしているのか——「変更」を「文書の修正案」に変える

まず、記事の要旨として公開されている説明を、そのまま押さえておきます。GitHubのAspireチームが、マージされた製品側の変更を、SME（Subject Matter Expert＝その分野に詳しい専門家）のレビューを経たドキュメントのプルリクエストに変える取り組みで、リリースとドキュメントの間に空いた溝を埋めるものだ、とされています。

専門用語をほどいておきます。

• リポジトリ：ソースコードや文書を保管し、変更履歴をすべて残しておく「共有の作業棚」のようなものです。製品用の棚とドキュメント用の棚が分かれている、というのが今回の前提です。
• マージ：提案された変更が、正式に製品本体へ取り込まれること。「稟議が通って、実際に反映された」状態だと思ってください。
• プルリクエスト（PR）：「ここをこう直したいのですが、どうでしょう」という変更提案書です。中身の差分が誰でも確認でき、承認されて初めて反映されます。いきなり書き換えるのではなく、必ず提案の形を経由するのがポイントです。
• エージェント型ワークフロー（Agentic Workflows）：あらかじめ決めた手順を機械的になぞるだけの自動化ではなく、AIが状況を読み取り、必要な調査や文章の作成まで担う自動化のことです。「決まった書式で通知を飛ばす」のが従来の自動化なら、「何が変わったのかを読み、それに合わせて説明文の修正案まで書いてくる」のがエージェント型、というイメージです。

つまり構図はこうです。従来は「製品が変わった → 誰かが気づく → 誰かが時間を作る → ドキュメントを直す」という、人間の善意と余力に依存した長い鎖でした。この鎖のうち、「気づく」と「下書きを書く」をAIに任せ、人間は「これで正しいか判断する」に集中する。取り組みの狙いは、この分業の組み替えにあると読み取れます。

ここで見逃せないのが、SMEレビューが工程に組み込まれている点です。AIが書いた文章がそのまま公開されるのではなく、その分野をよく知る人間の確認を通る設計になっている、と要旨には示されています。自動化の話題では「人手を減らせる」ばかりが注目されがちですが、この取り組みが取っているのは人間を外す方向ではなく、人間が判断すべき一点に人間を残す方向です。文章をゼロから書く負担は消え、内容の正しさを見極める責任は残る。減らしているのは作業であって、責任ではありません。

なお、ワークフローの具体的な起動条件、内部で実行される処理の詳細、利用しているモデルや設定、削減できた工数や品質の変化といった数値については、本記事の執筆時点で一次情報の本文を確認できていないため未確認です。ここでは公開されている要旨の範囲を超えた説明はしません。詳細は末尾の参考資料からご確認ください。

この発想が、開発現場の外にも効く理由

「うちはソフトウェアを作っていないから関係ない」と思われたかもしれません。しかし、この仕組みが解いている問題の骨格は、多くの職場に共通しています。

問題の本質は「変更が記録されているのに、誰にも届いていない」ことです。 製品の変更履歴という形で、何が変わったかは正確に残っている。にもかかわらず、その情報がドキュメント担当者の手元に届かず、結果として古い説明が残る。情報がないのではなく、情報が移動していないのです。

同じ構図は、たとえばこんな場面にあります。

• 料金表を改定したのに、営業資料とFAQページが旧価格のまま
• 承認フローを変えたのに、新人向けの手引きが旧フローを説明している
• システムを入れ替えたのに、問い合わせ窓口の想定問答が前のシステム前提

いずれも「変えた記録」はどこかに必ず存在します。稟議書、議事録、変更申請。足りないのは記録ではなく、記録を読んで「じゃあ、あの文書のこの部分を、こう直す必要がありますね」と翻訳する働きです。この翻訳作業は、これまで人間にしかできない上に、地味で、後回しにされ続けてきました。AIエージェントに任せる価値が最も高いのは、まさにこういう仕事です。

もう一点、設計として学べるのが**「提案の形で出す」**という作法です。AIが直接文書を書き換えてしまうと、誰も気づかないうちに内容が変わり、間違っていた場合に取り返しがつきません。プルリクエストという「提案書」の形をとることで、変更前と変更後が並べて表示され、承認されるまで本番には反映されず、履歴も残ります。AIを業務に組み込むとき、出力を本番に直結させず、必ず人間の承認を挟む一段を作る——この考え方は、ツールが何であれ応用が利きます。

期待しすぎないための注意点

魅力的な仕組みですが、そのまま真似れば必ずうまくいく、という話ではありません。導入を考えるなら、次の点は冷静に見ておくべきです。

第一に、AIは「もっともらしい嘘」を書きます。 変更内容を誤解したまま、自然で読みやすい説明文を生成することがあります。文章として整っているぶん、間違いに気づきにくいのが厄介です。だからこそ専門家レビューが不可欠であり、レビューを形式的な承認ボタンにしてしまうと、この仕組みは「間違いを効率よく量産する装置」に変わります。

第二に、レビュー担当者の負担は消えません。 提案が自動で作られるようになると、確認すべきものは増えます。文章を書く時間は減っても、読んで判断する時間は増える。ここを見積もらずに導入すると、レビュー待ちの提案が積み上がり、結局は放置されます。誰がどれくらいの頻度で確認するのか、承認されない提案をどう畳むのかまで決めておく必要があります。

第三に、対象の文書を選ぶべきです。 変更が機械的に反映できる説明（設定項目、手順、対応表など）は自動化と相性が良い一方、設計の意図や背景を語る文章、判断の分かれる注意喚起などは、変更履歴からは導けません。すべてを任せようとせず、「元の変更を見れば答えが決まる文書」に絞るのが現実的です。

第四に、権限と情報の扱いです。 複数のリポジトリをまたいで動く仕組みは、それだけ広い権限を持ちます。どこまで読めて、どこに書き込めるのかを絞り込まないと、想定外の場所に変更が及ぶ余地が生まれます。社内文書を扱う場合は、AIに渡る情報の範囲についても事前の確認が要ります。なお、今回取り上げた取り組みが実際にどのような権限設計を採っているかは未確認です。

第五に、これは組織の問題の一部しか解きません。 ドキュメントが古くなる原因には、そもそも書く文化がない、書いても読まれない、置き場所が散らばっていて誰も見つけられない、といった要因も混ざっています。自動化で埋められるのは「変更を反映する手間」の部分だけです。

まとめ：AIに任せるべきは、誰もやりたがらない翻訳作業

説明書だけが古いまま取り残される。この誰にとっても身近な不便さは、「変えた人」と「書く人」が分かれていることから生まれる、構造的な現象です。

GitHubのAspireチームの取り組みは、マージされた製品側の変更を、専門家レビューを経たドキュメントの修正提案へと変えることで、リリースと文書の間の溝を埋めようとするものだと公開されています。注目すべきは、人間を工程から追い出すのではなく、下書きをAIに、判断を人間にと役割を組み替えている点、そして必ず「提案」という取り消し可能な形を経由させている点です。

もしご自身の職場で似た仕組みを考えるなら、出発点は三つです。「変更の記録はどこに残っているか」「その記録から自動的に導ける文書はどれか」「その提案を誰が責任を持って承認するか」。この三つが埋まらないうちは、どんなに高性能なAIを入れても、古い説明書は古いままです。

本記事は公開されている要旨をもとに構成しており、ワークフローの実装詳細・効果測定の数値・技術構成については未確認です。実際の設計を検討される際は、必ず下記の一次情報をご確認ください。

参考資料

• Automating cross-repo documentation with GitHub Agentic Workflows（The GitHub Blog）: https://github.blog/ai-and-ml/github-copilot/automating-cross-repo-documentation-with-github-agentic-workflows/

新しい便利ツールが出るたびに試してみる。最初の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（本稿執筆時点で本文全体は未確認。公開概要にもとづき言及しています）