Chapter 6

AIネイティブな共同業務基盤を構築する

複数の人間とAIで、同じ成果を作る

チャプター5までで、個人の仕事はAIと回るようになりました。この章でやるのは、組織でGoal Loopを回すことです。

組織のGoal Loopは、細かく枝分かれする

一人で回していたときは、ゴールツリーもそこそこの大きさでした。会社になると、これが一気に細分化されます。

会社の目標があって、その下に部門のゴールがあって、その下にプロジェクトがあって、その下に案件があって、その下に一人ひとりの担当がある。どの階層も、理想と現在と差分を持ったGoal Loopです。 チャプター2で書いた入れ子構造が、会社の規模まで広がった状態だと思ってください。

そして、回す人も増えます。社長も、部門長も、現場の担当者も、それぞれのAIも、全員が同じツリーの上でGoal Loopを回します。 誰か一人が別のツリーを見ていたら、そこで噛み合わなくなります。

チャプター2の5ステップで言うと、この章で変わるのは回す人の数です。つなぎ目になるのが4（結果で現在を更新する）で、子ゴールの4が、親ゴールの1（差分を見る）を動かします。

従来のやり方のままだと、AIは回せない

ここが、この章のいちばん大事なところです。これまでの組織のやり方は、人間どうしが噛み合うようにできています。 チャットで共有する。会議で擦り合わせる。「あれどうなった？」と聞く。人間は、それで回してきました。

AIには、この回し方が通じません。

• チャットの流れから「いまの正はどれか」を判定できない
• 会議に出ていないので、決まったことを知らない
• 隣の席の立ち話も、廊下での「あれ聞いた？」も、届かない

だから、それぞれのAIが、それぞれの時点の情報を「正」として動きます。 全員が真面目に働いて、結果はバラバラになります。人が増えるほど、AIが増えるほど、この事故は増えます。

ある研修運営チームを例に、実際に何が起きるかを見ていきます。

講師が変わった日、AIたちは

ある会社の研修運営チームです。情報共有には気を配っていました。全員が同じチャットグループに入っている。資料は共有ドライブで全員が見られる。メンバーそれぞれが、チャプター5までを終えた状態で自分のAIと働いている。何も問題がないように見えます。

あるとき、講師と日程が変更になりました。変更の連絡は、チャットにちゃんと書かれました。「9月10日の回、講師が田中さんから佐藤さんに変わります。日程も9月12日に変更です」。既読もつきました。

そこから数日、チームは順調に見えました。3人とも、自分のAIに仕事を任せています。

• 招待担当のAIは、案件フォルダにある前回の案内文を下敷きに、参加者への案内を作りました。そこには田中さんの名前が入っていました
• 資料担当のAIは、共有ドライブの旧版テンプレートから当日資料を組みました。表紙の日付は9月10日のままです
• 会場担当のAIは、カレンダーに入っていた予定を見て会場を押さえました。押さえたのは9月10日でした

3つとも、AIは持っている情報を正しく使っています。変更を書いたチャットが、どのAIにも渡っていなかっただけです。

そして、当日が近づいた頃。

案内は旧講師名、資料は旧日程、会場は別の日。人間は3人とも、変更のチャットを読んでいました。読んでいない相手に、仕事をさせていたのです。

なぜ、チャットの共有では足りないのか

チャットに残るのは話の流れです。最初の日程、変更の相談、決定、さらにその後の微修正。古い情報と新しい情報と、途中の相談と、確定した訂正が、時系列に混ざって流れています。しかもチャットの発言は、「何についての話か」を省いて成立します。「講師Bで行くらしいですよ」「了解です」。その場では通じたやり取りが、あとから履歴を読む人とAIには、何の講師Bなのか分かりません。

「で、いまの正しい日程はどれ？」

この問いへの答えは、チャットのどこにも一か所には書かれていません。読んだ人が流れを遡って解釈するしかない。人間の組織がこれまで壊れなかったのは、この解釈を無意識に補正してきたからです。同じオフィスにいれば、「あれ、締切3日後なのに焦ってなくない？」「日程変わったの、聞いてない？」という立ち話がズレを直してくれます。AIには、この補正がありません。流れの中のどれが現在の正か判定できないまま、それぞれのAIが、それぞれの時点の情報を「正」として動く。だから全員真面目に働いて、バラバラの結果になります。

これが同じ仕事、別々の現在地問題です。関わる人間とAIが増えるほど、この事故は急速に増えます。

解決の構造は、3つ

原因が「現在地がバラバラ」なら、解決は「現在地を一つにする」です。構造は3つだけです。

1. 一つのゴールツリーを共有する — チームの仕事を、ひとつのツリーに置く。研修運営なら「9/12の研修を成功させる」の下に「参加者を集める」「資料を作る」「会場を確保する」がぶら下がる形。一本の長いToDoリストにしないのは、差分の性質が違うからです。参加者への案内と、資料の版管理と、当日のトラブル対応は、別々の頭で回す仕事。分けておけば「参加者が集まらない」問題は集客のゴールの中だけで回り続け、資料担当を巻き込みません
2. 各ゴールを、必要な人間とAIが回す — 全員で全部やる必要はありません。招待は招待担当と担当AIが、資料は資料担当と担当AIが。それぞれがチャプター5までのやり方で自分のゴールを回します
3. 結果を、親ゴールへ戻す — ここが心臓部です

「資料、できました」という報告だけでは、共同業務は進みません。親ゴールの現在地が更新されないからです。現在地が変わらなければ、差分も変わらず、チームの誰にとっても「次の一手」が見えないままです。

逆に、結果を親ゴールへ戻すと、連鎖が起きます。

講師変更の例なら、「講師と日程の変更」が親ゴールの現在地として一か所で更新されれば、招待AIも資料AIも会場担当も、同じ最新の現在地から自分の次の一手を選び直せます。連絡が行き渡るのを待つ運用と違って、全員が同じ場所を見るから、ズレようがありません。

戻ってくるのは、順調な結果だけとは限りません。当日運営の担当が「この会場では500人が限界です」を持ち帰ることもあります。そのときは親ゴールのほうが「2日程に分けて開催する」へ書き換わり、案内の文面が変わり、当日運営のゴールがひとつ増えます。子ゴールの結果が、親ゴールそのものを書き換える。 チャプター2で書いた目標更新ループ、つまり理想のほうを直す動きが、組織のスケールで走るということです。現場の「無理です」がツリーを直せるから、ツリーは現実とズレないまま回り続けます。

同じ情報を全員が全部持たなくても大丈夫です。同じ仕事の状態を、基準にすればいい。 共同業務とは、同じGoal Loopを複数の人間とAIで回すことです。

共通基盤という考え方

「ここに書いてあることが正」という場所は、どの会社にもなんとなくあります。経営会議の決定はこのホワイトボードに、売上はこのスプレッドシートに、ToDoはこの一覧に。人間はそれで回してきました。これからは、そのなんとなくの正を、全員のAIにも分かる形で持つ必要があります。

きちんとした手本が、ソフトウェア開発の世界にあります。

開発の世界では、何百人ものエンジニアが、別々のパソコンで、別々の道具を使って、同じひとつのソフトウェアを同時に直しています。普通に考えれば、ぐちゃぐちゃになるはずです。ならない理由は、Gitという共通基盤があるからです。仕組みの核はひとつで、全員が、自分の変更を最後に必ず一つの場所へ戻す。戻す先が一つだから、何百人で作っても一つのプロダクトになります。

共同業務にも、これと同じ位置づけの基盤が要ります。そこに置くものは2つだけです。

• 一つのゴールツリー（チームの仕事の全体）
• 各ゴールの最新の現在地

会話やファイルは、外部に残したままで大丈夫です。実行も、最適な外部ツールを使い続けてください。案内はメールで、日程はカレンダーで、資料は制作環境で。ただし、外部で終わらせず、結果をゴールへ戻します。

この基盤の役割を果たすのが、「Addness」というツールです。

Addnessに置くのは、共同業務のゴールと現在地だけです。実行は、いつものツールのままで構いません。

運用は3行に収まります。Addnessでゴールツリーと現在地を共有する。外部で行動する。結果をゴールへ戻す。 それぞれの人とAIが、担当するゴールに向かってToDoをこなし、動いた分だけコンテキストがゴールに貯まって、次に動く人とAIの前提になります。人とAIの共同業務基盤、これを私たちはAIネイティブな業務基盤と呼んでいます。

自分のAIをこの基盤に繋ぐ手順はMCP連携に、チームへ広げる進め方は運用編1にあります。

導入前と導入後を並べると、変化はこう要約できます。

• Before: 同じチャットと資料を共有する。同じ情報を見ているのに、現在地が別々で、成果が噛み合わない
• After: 同じゴールツリーと現在地を基に、結果を戻し合う。現在地が更新され、全体が前進する

ここまで来ると、仕事の形そのものが変わります。日々の実感としては、この3つが大きいです。

1. 誰かがすでにやったことを、AIが自分で拾ってくる。

同じ会社の中で、似た調査、似た提案、似たトラブル対応は何度も起きています。これまでは、それを知っている人に聞くしかありませんでした。基盤に乗っていると、あなたのAIが、ほかの人のゴールに貯まった経緯を読んでから動きます。 「前に似た案件ありませんでしたか」と聞いて回る時間が、まるごと消えます。

2. 人から人への依頼が、引き継ぎ会議なしで終わる。

これまでは、誰かに仕事を渡すとき、打ち合わせをして、経緯を説明して、資料の場所を教えていました。基盤に乗っていると、渡すのはゴール1つです。 受け取った人のAIが、そのゴールに貯まった経緯を読んで、そのまま続きを始めます。

実際にアドネス株式会社では、この形で1日がかりだった引き継ぎ作業が30秒になりました（経緯はnoteの実例記事にあります）。

3. フィードバックが、相手のAIまで届く。

「ここは違う」「この方向で直して」。これまでは、指摘した相手が受け取って、覚えていて、次回に反映するかどうかでした。同じ指摘を何度もすることになります。

基盤に乗っていると、指摘はそのゴールに残ります。 次にそのゴールを動かすAIは、指摘を読んでから手を打ちます。直した内容が、その場の一回で消えずに残るわけです。これはチャプター5で書いた書き戻しと同じことで、それが個人の環境でなく、組織の基盤で起きます。

そしてもうひとつ。現在地はツリーを見れば伝わるので、報告のためだけの資料づくりや会議が、そもそも要らなくなります。作業が速くなるのを超えて、作業自体が消える。作業の効率化で止まらずに、基盤まで整える意味はここにあります。

誰が始めるかで、結果が変わる

この基盤は、トップダウンでしか根づきません。

現場の有志が個人で使い始めても、担当者ひとりの工夫で終わります。仕事の置き方を変えるというのは、会議の減らし方や、報告のやめ方まで含めた仕事の進め方そのものの変更だからです。それを決められるのは、社長・役員クラスだけです。

順番はシンプルです。まずトップが自分で使う。 次に、会社の全体像をツリーに載せる。そこから担当者にアサインして広げる。逆に、トップが使わないままメンバーにだけ使わせると、報告のための入力作業がひとつ増えるだけになります。

この構造は、どの部署でも同じです

研修運営の例で説明してきましたが、この形は仕事の種類を問わず使えます。

• 営業: 商談の結果が、受注ゴールの現在地へ戻る
• 採用: 面接の結果が、採用ゴールの現在地へ戻る
• マーケ: 顧客の反応が、コンテンツのゴールの現在地へ戻る

どれも「実行は現場で、結果はゴールへ」。チャプター2から積み上げてきたGoal Loopが、そのまま組織の背骨になります。

実例で見る

考え方だけでなく、実際の記録を公開しています。

• 1日かかっていた作業が30秒になった — ゴールに貯まった文脈だけで、AIからAIへ仕事を引き継いだ話

ほかの事例は、noteのアカウントに随時追加しています。

おさらい

• チャット共有で起きるのは同じ仕事、別々の現在地問題。情報は流れても、「いまの正」は一か所にない
• 解決の構造は3つ。一つのゴールツリー／必要な人とAIが各ゴールを回す／結果を親ゴールへ戻す
• 結果を戻すと連鎖が起きる。現在地が変わる → 差分が変わる → 次の一手が変わる → 別の人とAIが動き出す
• 基盤に置くのはゴールツリーと現在地の2つだけ。実行は外部ツールでよく、結果だけ戻す
• ループで言うと、変わるのは回す人の数。子ゴールの4が、親ゴールの1を動かす
• 情報共有・依頼・フィードバックが、会議や説明なしで回るようになる
• Addnessは、共同業務のゴールと現在地を持つ場所

セットアップへ

基本編はここまでです。ここから先は、基本編でやったことを、実際に手を動かしてやります。作業場を立ち上げるところから、AIネイティブな共同業務基盤を構築するところまで、ガイド1本と講座1本で進みます。繰り返す仕事の自動化は、基本編第5章とサブ講義3で扱います。

• AIと働く環境の立ち上げガイド（addness.works/start） — アプリを入れる、Addnessに登録する、「AIで開こう」でAIに任せる。画面つきの手順ページで、30分ほどでAIと働く環境ができます
• 運用編1 日々の運用にする — 立ち上げた環境を毎日のループにして、チームへ広げます

AIを使える人から、人間とAIで成果を作れる人へ。