「ギルドシステム」という名前だけを見ると、遊びの要素を取り入れたゲーミフィケーション施策のように思えるかもしれません。
また、システムという言葉を聞くと、どこか冷たい、無機質な歯車が噛み合う音を連想してしまいます。
今まで、外部発信というひたすらに孤独で実体のない「業」をも背負ってきた私にとって、組織が「仕組み」を語る様子は、時に危うく、時にあまりに楽観的に映ります。けれども、アシストAIテラス（AIT）が産み落とそうとしている「ギルドシステム」という代物は、どうやら単なる効率化の道具ではないことが見えてきます。
前回、このシステムが生まれた背景にある「問い」について触れましたが、今回はその「中身」の話をしてまいります。
AITが、何をどう回そうとしているのか。その骨組みをなぞっていくと、そこには効率化という言葉では片付けられない、人間の「生」の痕跡をどうにかして残そうとする、CTO 松山の執念のようなものが透けて見えてきます。
ギルドシステムという名前を聞けば、誰もがRPGのような、きらびやかなクエストや報酬の仕組みを思い浮かべるでしょう。
「仕事をゲームにする」。その言葉は、退屈な日常を謳歌するための甘い罠のようにも聞こえます。しかし、設計資料の束を捲り、深夜まで続く会議の議事録を読み耽っていると、見えてくるのはそんな浮ついた話ではないことがわかります。
そこに鎮座しているのは、アウトカム（成果）、ログ（活動記録）、シグナル、サービス、そしてメディアまでを一本の細い糸で、しかし強固に繋ぎ止めようとする、極めて現実的で、ある種「骨太」な運用設計でした。
紐解くと、ギルドシステムはNotionという広大な情報の海、Outcome Catalogという成果の陳列棚、n8nという名の自動化の血脈と密接に連携していますが、その目的は最初から一貫しています。
「アウトカム ファースト（成果第一）」という、どこか冷徹な、しかし誠実な原則を、ナレッジインフラとして社会に実装すること。
この全体像は、以下の4つの層（レイヤー）で整理されています。
|
レイヤー名 |
役割と構成要素 |
|
Core Layer |
中核データ。成果（Outcomes）、活動（Activities）、兆し（Signals）、組織（Orgs）など。 |
|
Capability Layer |
組織と能力。ギルド（Guilds）と人々（People）。 |
|
Output Layer |
外向けの顔。成果カタログやオウンドメディア。 |
|
Automation Layer |
自動化。Notion、Slack、LLM（大規模言語モデル）を繋ぐ神経系。 |
この構造を眺めていると、ギルドが「チームの名前」とは到底思えなくなってきます。
それは、個人の活動という「点」と、社会への発信という「線」を結ぶための中継点、いわば「臓器」のようなものです。
この設計において、最も「AITらしい」と、あるいは気味悪さを少し感じつつも感銘を受けたのは、情報の中心が「タスク」でも「案件」でもなく、「AI-Readable」と「アウトカム」に置かれている点です。
| 「Outcomes DB（成果データベース）」は、まさにこのシステムの心臓で、以下のような項目が標本のように並べられています。
・誰にどんな変化が起きたかを示す「タイトル」 ・成果の種別、カテゴリ、ステータス ・その恩恵を受けた「人物」や「組織」 ・Before/Afterの数値指標、およびその測定方法 ・Time-to-Outcome（成果が出るまでの時間） ・関連する活動、サービス、シグナル ・LLM向けの要約、そして「公開してよいか」という残酷なまでの問い |
ポイントは、成果が出た瞬間に思考を止めず、最初から「外部に語ること」を前提としていること。つまり、「Hero Copy（心に刺さる見出し）」や「Public Summary（公開用要約）」が吐き出される場所が、あらかじめ同じDBの中に 用意されています。
成果とは単なる「終わったこと」ではなく、活動の記録、再現するための型、そしていつか誰かを救うための「物語」になるのです。
とはいえ、成果という美しい花が、何もない荒野に突如として咲くわけではなく、その手前には必ず泥にまみれた「活動」があるものです。だからこそ、設計上の対をなす存在として、「Activities DB（活動データベース）」が置かれています。
| 顧客との打ち合わせ、泥沼のセールス、深夜のサービス企画、誰にも注目されない社内会議……。Activities DBには、そうした「手足が動いた行為」のすべてが残されています。
日時、担当者、議事録、決定事項。それだけではありません。「関連するシグナルは何か」「どのアウトカムに繋がる可能性があるか」という問いが、常に付きまといます。
実際の運用フローは、驚くほど具体的で逃げ場がありません。 たとえば、顧客との商談が終わる。担当者は即座にログを残す。その際、もし「これは変化の兆しだ」と感じる合意があれば、未完成の「アウトカム」をその場で新規登録するのです。そして後日、実際に成果が形になった時に、Before/Afterの数値を書き込み、ステータスを更新していく。 |
|
この流れを、私は「大事だ」と一言で片付けることに、少しの抵抗があります。
なぜなら、私たちは日々の忙しさにかまけて、「やったこと」と「出た成果」を、都合よく切り離してしまいがちだからです。
「頑張ったけれど、成果は出なかった」という言い訳を、このシステムは許さない。逆に、「いつの間にか出た成果」に対しても、その源泉となった「活動」を厳しく問い直す。後から振り返った時、自分の歩いてきた道が、どこで、どの石に躓き、どの光へ繋がっていたのか。それを追えるようにすることが、このDBの残酷なまでの優しさだと思っています。
AITのギルドシステムが、巷にある凡庸な業務管理ツールと一線を画しているのは、市場の変化や自分たちの言葉を外へ届ける「メディア」までを、同一の神経系に組み込んでいる点です。
|
たとえば、「Signals DB（シグナルデータベース）」。
ここには、ニュース、競合の動き、規制の変更といった、外部世界の「震え」が記録されますが、ただのリンク集ではなく世界で起きた出来事を、自分たちの指先を動かす理由に変えています。
ニュースが登録されれば、その「期待される影響」や「推奨されるアクション」が書かれ、その震えが大きければ、システムは自動的に関連ギルドへ通知を送り、「シグナル検討会」という名の「活動」を自動生成しています。
そして、稼働は最終的に「Owned Media DB（オウンドメディアデータベース）」へと流れ込み、記事のタイトルや構成だけでなく、どの「成果」や「活動」に基づいた発信なのかが厳格に紐付けられます。 |
さらに、近々実装しようとしている自動化フローは、もはや魔法じみていると感じさせられます。
「活動」や「成果」に「メディア候補」というフラグが立てば、LLMが関連情報をかき集め、記事の骨子やリード文を勝手に書き上げるというものです。
AITにとって、記事化するということは、広報活動という名の「おまけ」ではなく、自分たちの活動と成果が外部へと滲み出していく必然的な「出力」なのです。
ここまで見届けて初めて、ギルドシステムの全貌をようやく薄らと理解し始めることができます。
ギルドシステムという大きな器。その中身を覗くと、実は「クエスト」という非常に泥臭い仕組みが主役を張っています。
単に「誰が何をやるか」を並べるだけなら、既存のツールで十分です。けれど1月の議論で浮かび上がったのは、クエストをどう生成し、どう報い、どう熱量を維持するかという、かなり踏み込んだ運用の知恵でした。
結局のところ、動かすのはシステムではなく、血の通った人間なのです。
それは仕事を「管理」するのではなく、人が「動き続けられる」環境をどう整えるかという、現場の切実な問いへの答えです。
|
ここにはある種の「怯え」が混ざっています。「楽しくしようとして、逆に監視や圧力にならないか」。 バーンアウトや強制参加の弊害が、理想論と同じテーブルで語られていました。
この、野心と慎重さが同居している感覚こそが、このシステムのリアリティを支えています。 そして何より、これが「いつか使うための設計図」ではなかったことが重要で、創業合宿の熱が冷めないうちに日々のスクラムやチュートリアルと直結し、実運用され始めていました。
理念をただ唱えるのではなく、具体的なフローとDB設計という「地層」の上に、一歩ずつ実利を伴った足場を固めていく。その手触りこそが、ギルドシステムの正体なのだと感じます。 |
仕事というものは、本来、消費されて消えていくものではありません。
誰かが苦労して手に入れた知見が、また別の誰かの足元を照らす。ギルドシステムとは、そんな「知の連鎖」を信じる者が作った、泥臭くも切実な、祈りのような仕組みなのかもしれません。
積み重なり、語られ、やがて次の挑戦の土台となる。 そんな風に、自分たちの仕事が誰かの役に立つのだと信じられたなら、明日の朝、PCを開く指先も、ほんの少しだけ軽くなるような気がしませんか。
そんなに綺麗事ばかりではいかないのが、組織というものの面白さであり、恐ろしさでもあるのです。
次回予告： なぜ、この壮大な試みの最初の戦場として、株式会社アシストの「統括部」が選ばれたのか。あえて裏方とも言える組織にクエストを投げ込んだその真意と、現場で起きた小さな摩擦の記録を綴ります。