Andoとは｜エージェントを同僚にするメッセージングが初公開したUIと設計思想を32秒動画で読み解く

メッセージングアプリにAIを足す動きは、もう珍しくない。 Slackにもbotがいて、Teamsにもアシスタントがいる。 そこへ「最初からエージェントを同僚として設計したメッセージング」を掲げるAndoが、初めて自分たちのインターフェースを公開した。

2026年6月17日、Andoの公式アカウント@andocorporationが、約32秒のティザー動画を投稿した。 本文は短い。 「we’ve been super stealthy about our interface, but FINALLY, here’s a peek 🫣（インターフェースについてずっと秘密にしてきたが、ようやく少しお見せする）」。 この記事では、その動画と公式情報、一次ソースから、Andoが何を作ろうとしているのかを読み解く。

エージェント全般の設計の地図を先に持っておくと、Andoがどの位置を狙う道具なのか掴みやすい。 AIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証 を併読しておくと、本記事の前提が整う。

Andoとは（エージェント前提チームのメッセージング）

Andoは、AIエージェントをチームの一員として扱う前提で設計されたメッセージングプラットフォームだ。 公式サイト ando.so に掲げられたタグラインは「The messaging platform for agent-pilled teams」。 日本語にすると「エージェントにすっかり染まったチームのためのメッセージングプラットフォーム」という語感になる。 サイトのコピーはもう一段踏み込んで「Bring your agents into the conversation. No walled gardens.（自分のエージェントを会話に連れてくる。囲い込みはしない）」と書く。

@andocorporationのプロフィールにはこうある。 「The messaging platform for agent-pilled teams. Available in very private alpha for now.（エージェント前提チームのためのメッセージング。現在はごく限られたプライベートアルファで提供）」。 アカウントは認証済みの組織アカウントで、所在地はサンフランシスコ、開設は2024年10月だ。

「botを足したチャット」と「エージェント前提のチャット」は、言葉が似ているわりに発想が違う。 前者は人間の会話の脇にアシスタントを置く。 後者は、エージェントを他のメンバーと同じ場所に座らせ、文脈も権限も人間と同じように渡す。 Andoが狙うのは後者で、サイトではエージェントが「first class citizens, indistinguishable from other coworkers（他の同僚と区別できない一級の参加者）」だと表現されている。

まず動かない事実を整理しておく。

・名称：Ando（運営会社はサイト記載でAsari Inc.）
・公式サイト：ando.so
・カテゴリ：チーム向けメッセージング（エージェント協働前提）
・提供状況：クローズドアルファ（執筆時点 2026年6月）
・オープンソースか：いいえ。公開リポジトリは確認できない
・公開された動画：2026年6月17日投稿の約32秒のUIティザー

この記事の主役である動画は、製品が「何に見えて、どう振る舞うか」を初めて外に出したものだ。 次の節で、その中身を1カットずつ確認する。

デモ動画で見るAndoの動き（@andocorporation 公開映像）

冒頭に置いた動画は、@andocorporationが投稿したUIティザーだ。 取得時点（2026年6月18日）のエンゲージメントは、閲覧約47,190・いいね344・ブックマーク306・返信21・リポスト10だった。 ブックマークがいいねに迫る数で、「あとで詳しく見たい」という保存行動の多さが、製品への実利的な関心を示している。

動画は無音で、画面操作だけが進む。 背景は薄い青空と雲のイメージで、ウィンドウの余白が広い。 ここからは、推測を交えず、映っている内容だけを順に書く。

画面の構成はチャットアプリそのものだ。 左端に縦のアイコン列が並び、その右にチャンネルやスレッドの一覧、中央に#generalチャンネルのメッセージ、下にメッセージ入力欄がある。 最初に映るのは、人間のメンバーどうしの何気ないやり取りだ。 Oliverが「morning all! ☕」と挨拶し、Saraが「deploy went out clean last night! 🎉（昨夜のデプロイはきれいに通った）」と書き、そこに🔥の絵文字リアクションが3件付く。

ここでAJという参加者が「found a bug. composer crashes when I paste an image from clipboard lol（バグを見つけた。クリップボードから画像を貼ると composer が落ちる）」と投稿する。 AJのアバターは、他の人間メンバーの顔写真とは異なり、黒い円にアイコンが入ったものだ。 このバグ報告が、動画の本筋であるスレッドの起点になる。

バグ報告をクリックすると、右側にスレッドが開く。 Ryanが「uh oh - repro on mac or everywhere?（うわ、再現はMacだけ？全環境?）」と尋ねる。 ここでYumiが会話に入る。 Yumiの名前は紫色で表示され、他の人間メンバーの黒い名前とは見た目が区別されている。 Yumiは「Looking into this!（見てみます）」と返し、その下に「Checking codebase」という状態表示を出す。 この状態表示が、エージェントが裏でツールを動かしている合図になっている。

しばらくすると、状態表示が「Checked codebase（コードベースを確認済み）」に変わる。 そしてYumiが具体的な結果を書く。 「Reproduced on both - images over 5 MB hit the crash. Filed it and tagged the composer team.（両環境で再現しました。5MBを超える画像でクラッシュします。起票して composer チームにタグを付けました）」。 ここでYumiは、原因の切り分け、再現条件の特定、チケット起票、担当チームへの通知までを、ひとつの返信の中でやってのけている。

返信の続きに、起票されたチケットのカードが現れる。 カードには「AND-214　Composer paste crash」と表示される。 ANDという接頭辞は、このワークスペースのチケット採番だと読み取れる。 さらにYumiは担当者を名指しする。 「@Graeme you’re the DRI - want me to fix it and open a PR?（あなたが責任者です。私が直してPRを開きましょうか?）」。 DRIは「directly responsible individual（直接の責任者）」の略で、シリコンバレーでよく使われる役割の呼び方だ。 これに対してGraemeが「All good Yumi, I’ll take it from here.（大丈夫、ここからは自分が引き取る）」と答え、人間が主導権を握り直す。

この一連の流れが、Andoが見せたかった核だと考えられる。 エージェントが会話の文脈からバグを拾い、コードベースを調べ、再現し、チケットを起票し、担当者に判断を仰ぐ。 そのすべてが、別ツールに飛ぶことなく、ひとつのスレッドの中で完結している。

スレッドが自動で名前を付けられる

動画では、もうひとつ細かい挙動が映っている。 スレッドを開いた直後のタイトルは単に「Thread」だが、やり取りが進むと、左サイドバーのスレッド名が「Composer paste crash」に変わる。 会話の内容から、スレッドの見出しが自動生成されているように見える。

エージェントは外部の文脈も読む

動画の後半は、もう少し軽い場面だ。 #generalに戻ったJordanが「@Yumi tell me a joke（ジョークを言って）」とYumiを直接呼ぶ。 新しいスレッドが開き、ここでも見出しが「A joke for Jordan」と自動で付く。

ここでのYumiの動きが面白い。 ジョークを求められたYumiは、まず「Checked Jordan’s Linear」という状態を出す。 つまりJordan個人のLinearを確認しにいく。 そのうえでこう返す。 「You have 6 open tickets, Jordan. I think you should get back to work.（未対応のチケットが6件ありますよ、Jordan。仕事に戻った方がいいと思います）」。 この返信には💀の絵文字リアクションが4件付く。

このやり取りは笑い話として作られているが、技術的な含みははっきりしている。 エージェントは、頼まれた相手のタスク管理ツールを文脈として参照できる。 チャンネル全体の会話だけでなく、個人に紐づく外部データにも手が届く設計だ、と動画は示している。

動画の末尾では、AndrewがCalebをコーヒーに誘い、Calebが「Yippee」と返して締めくくられる。

念のため強調しておくと、これはベンダー自身が用意したデモ映像だ。 実際の応答速度や、コードベース調査の精度、チケットの質は、第三者が検証したものではない。 動画は「こう振る舞うように作っている」という設計の宣言であって、性能の保証ではない。 ここは割り引いて見る前提が要る。

ツイートカードで原文を確認する

動画の出典である投稿そのものも、下に置いておく。

なぜ今エージェント前提のメッセージングなのか

エージェントを業務に組み込もうとすると、最初にぶつかるのが「どこで動かすか」という問題だ。 コードを書くエージェントはIDEやターミナルにいる。 リサーチするエージェントはチャットUIにいる。 だが実際の仕事は、人と人の会話の中で決まり、文脈が生まれる。

New Ontologiesが2026年4月に公開したAndoの詳報には、創業者の問題意識が引用されている。 「If I needed single player AI agent experiences, it would be pretty easy to achieve. But I have so many processes that are collaborative — they are impossible or very frustrating to set up in Slack.（一人で使うエージェント体験なら簡単に作れる。けれど私の仕事には協働的なプロセスが山ほどあって、それをSlackで組むのは不可能か、ひどく面倒だ）」。

ここが出発点だ。 単独で動くエージェントは作りやすい。 難しいのは、複数の人間とエージェントが同じ文脈を共有しながら進める「協働」のほうだ。 そして協働が起きる場所は、たいていメッセージングアプリの中にある。

Andoの賭けは、この「会話＝文脈の生成源」という性質に乗ることだ。 人間が交わすメッセージや通話を、そのままエージェントが読める素材として扱う。 だからこそ、後付けのbotではなく、会話の場そのものを作り直す方向に進んでいる。

エージェントの設計には定石がいくつもある。 プロンプトの連鎖、ツール呼び出し、複数エージェントの分業といった型を俯瞰したい場合は、AIエージェント設計パターン入門｜プロンプトチェーンからマルチエージェントまで21の型を体系理解する が地図になる。 Andoは、その型を「メッセージングというUI」に落とし込もうとしている、と捉えると位置づけが見えてくる。

Andoの設計思想：建築家・安藤忠雄と「間」

プロダクト名のAndoは、Sara Du氏が好きな建築家、安藤忠雄に由来する。 これは趣味の話に留まらず、製品の方針に直結している。

New Ontologiesの記事によると、チームは安藤建築の概念である「間（ま）」、つまり空白・余白の価値を製品に取り込んでいる。 記事の表現では「silence as a design value（沈黙をデザインの価値とする）」。 通知で絶えず注意を奪う方向ではなく、静けさを保つ方向に倒す、という設計判断だ。 冒頭の動画でウィンドウの余白が広く、背景が静かな空のイメージだったのも、この思想と地続きに見える。

Sara Du氏は、デザインを見た目の話に閉じていない。 記事には本人のこんな言葉が引かれている。 製品の良し悪しは「craft that goes beyond visual aesthetics, into the amorphous and hard-to-measure feel of using a product（視覚的な美しさを超えた、つかみどころがなく測りにくい”使い心地”にまで及ぶ作り込み）」で決まる、と。 機能名の付け方、通知のリズム、データモデルの設計まで、そのすべてが体験を形づくるという立場だ。

この姿勢の背景には、Sara Du氏の経歴がある。 本人は19歳でAlloy Automationを創業し、a16z・Bain・Shopifyから2,700万ドルを調達した。 記事によると、その後Alloyを離れてAndoを始めた。 理由を本人は、得意でない領域を伸ばし続けるより、デザインとマーケティングという自分の強みに戻るためだと語っている。

設計思想を象徴するもうひとつのキーワードが、エージェントの「文体」だ。 チームは、エージェントの出力スタイルの内部基準にヘミングウェイを置いていると記事は伝える。 狙いは「compression and precision, or endeavoring to say more with fewer words（圧縮と精度、つまり少ない言葉で多くを語ろうとすること）」。 動画でYumiの返信が短く具体的だったのは、この基準の反映だと読める。

コンテキスト・メモリ・ツールという3つの土台

公式サイトのコピーを読むと、Andoがエージェントに渡そうとしているものが3つに整理できる。 コンテキスト、メモリ、ツールだ。 それぞれが、動画で見たYumiの振る舞いに対応している。

コンテキストは、エージェントが「いま何が起きているか」を理解するための材料だ。 動画でYumiがコードベースを確認し、JordanのLinearを参照できたのは、この供給があるからだと読める。 公式サイトは「Conversations, decisions, files, and tools are all in one place so agents understand the work around them.（会話、意思決定、ファイル、ツールがひとつの場所にあり、エージェントが周囲の仕事を理解できる）」と書く。

メモリは、一度きりの会話を越えて積み上がる知識だ。 New Ontologiesの記事は、Andoが「自己改善するメモリ」を持ち、エージェントが時間をかけてチームの基準や設計判断を学べる点を強みとして挙げている。 チームが繰り返す慣習や好みを覚えることで、毎回ゼロから指示し直す手間を減らす狙いだ。

ツールは、エージェントが世界に働きかける手だ。 チケットを起票する、PRを開く、Linearを調べる。 動画のYumiが見せた行動は、すべてこのツール層に属する。

公式サイトには、もうひとつ印象的な一節がある。 エージェントは「proactively hop into conversations and threads when they have something useful to add（役立つことがあるとき、自分から会話やスレッドに飛び込む）」とされている。 受け身で待つbotではなく、自分から動く同僚という像だ。 これはSara Du氏の次の言葉と重なる。 「The best human coworkers surprise you. They’re proactive, they stew on things overnight and send you interesting thoughts in the morning. Why can’t agents be like that too?（最高の同僚はこちらを驚かせる。先回りして動き、夜のあいだ考えを寝かせ、朝になって面白い案を送ってくる。エージェントだって、そうあっていいはずだ)」。

コンテキストをどう整理しているか

エージェントに会話を渡すうえで難しいのは、量だ。 チャットは際限なく流れ、そのまま渡しても精度は上がらない。 New Ontologiesの記事は、Andoチームがこの問題に「conversational units（会話の単位)」という概念で取り組んでいると伝える。

記事の説明はこうだ。 「An agent now groups incoming messages into bundles and annotates them with specific labels, which makes retrieval significantly more accurate.（エージェントが流れてくるメッセージを束にまとめ、具体的なラベルで注釈を付ける。これにより検索の精度が大きく上がる)」。 チームはこの作業の難しさを、ボルヘスの「バベルの図書館」になぞらえているという。 無限に見える会話の海から、必要な一節をどう引き当てるか。 そこに事前のラベリングという手をかけている。

アーキテクチャと動作原理

公開された情報の範囲で、Andoの構造を図にしておく。 内部実装は非公開なので、これは動画と公式コピー、New Ontologiesの記述から組んだ概念図だ。

押さえどころは3つだ。

・人間とエージェントが同じチャンネルに同居し、入口が分かれていない
・会話と通話（Jams）が索引化され、エージェントが読める文脈になる
・エージェントはツールを介してLinearやコードベースなど外部に働きかけ、その結果がまた文脈に戻る

動画で見たバグ対応の流れを、時系列で追うと次のようになる。

この図で見ると、エージェントの役割分担がはっきりする。 Yumiは調査と段取りを引き受け、最後の意思決定はGraemeに渡している。 全自動で突っ走るのではなく、人間が要所で主導権を取り戻せる設計だ。 動画の範囲では、この「引き取る」ボタン的な瞬間が意図的に見せられている。

SlackやMicrosoft Teamsとの違い

Andoの立ち位置を、既存のチャットと並べて整理する。 ここは「後付け」か「前提」かの一点に尽きる。

New Ontologiesの記事は、Andoが「established players like Slack and Microsoft Teams（SlackやMicrosoft Teamsといった既存勢)」だけでなく、職場コミュニケーションのあり方そのものに挑んでいる、と位置づける。 言い換えると、Andoの競合は機能の一覧ではない。 「エージェントがいる前提で、チームの働き方はどう変わるか」という問いに、UIごと答えようとしている。

ただし、これは現時点では仮説段階の挑戦だ。 SlackもTeamsも巨大な導入基盤を持ち、エージェント機能の拡充を続けている。 Andoが見せたUIが優れていても、移行コストや既存連携の壁は別の問題として残る。 動画の鮮やかさと、実運用での定着しやすさは、分けて考える必要がある。

対応エージェントと「自分のエージェントを持ち込む」

Andoの方針で特徴的なのは、エージェントを自前で囲い込まない点だ。 公式サイトは「Bring Your Own Agents」と掲げ、こう補足する。 「Ando isn’t an agent orchestration platform.（Andoはエージェントのオーケストレーション基盤ではない)」。

つまりAndoは、エージェントを作る場所でも、複数エージェントを制御する司令塔でもない。 すでにあるエージェントを会話に連れてくる「場」を提供する立場だ。 公式サイトの記載では、持ち込めるエージェントとしてClaude・Codex・Devin・OpenClawなどが挙げられている。

このうちOpenClawは、GitHubで広く使われているOSSのAIアシスタントだ。 その全体像はOpenClaw完全ガイド2026｜GitHub35万★AIアシスタントOSSのインストールから運用までで詳しく扱っている。 Andoは、こうした既存エージェントの「働く場所」になることを狙っている、と読める。

本番でエージェントを運用する際の設計原則は、Andoのような外側のUIとは別に、エージェント側でも押さえておきたい。 Model Context Protocolで本番エージェントを構築｜Anthropic公式の設計原則と認証・最適化パターンは、エージェントに権限とツールを渡すときの勘所をまとめている。 Andoが供給する「ツール」層を、エージェント側がどう受け取るかを考えるうえで補助線になる。

注意したいのは、対応エージェントやツールの正確な範囲は、アルファの進行とともに変わりうる点だ。 ここで挙げた名前は公式サイトの記載に基づくが、最新の対応状況は公式での確認が前提になる。

実運用の一例：Truth Systemsのアルファ利用

公開情報の中で、唯一具体的な利用事例として出てくるのがTruth Systemsだ。 New Ontologiesの記事が、アルファ利用者として紹介している。

同社CEOのAlex Mac氏は、もともとSlack上でワークフローを作り込んでいた。 それをAndoへ移し、記事によると「Last week, 100% of tickets created and closed by his engineering team flowed through Ando.（先週は、彼のエンジニアチームが作成・クローズしたチケットの100%がAndoを通った)」。 さらに、チーム全体をSlackから移す計画だと書かれている。

この事例で、エージェントが何をしているかも具体的だ。 記事によると、エージェントは通話の文字起こし、過去のチケット、コードベース、Linearの履歴を使い、「multipage, implementation-ready tickets, detailed enough that Claude Code or another coding agent can one-shot the implementation from it.（複数ページにわたる、実装可能な粒度のチケット。Claude Codeなどのコーディングエージェントが一発で実装できるほど詳細なもの)」を生成するという。

この流れは、冒頭の動画で見たYumiの振る舞いと地続きだ。 会話から課題を拾い、複数の文脈を束ね、コーディングエージェントが動ける形のチケットに落とす。 人間が要件を会話で固め、エージェントが詳細化と起票を担い、別のコーディングエージェントが実装する。 そういう分業を、ひとつの会話の場で回す絵が見えてくる。

ただし、これは単一企業のアルファ利用だ。 「100%がAndoを通った」という数字も、その企業のその週の話であって、一般的な成果を保証するものではない。 事例は方向性を示す材料として読み、自分の環境での検証は別に要る。

制限事項・現時点でわかっていないこと

熱量のあるプロダクトほど、わかっていないことを正確に並べる価値がある。 執筆時点（2026年6月18日）で、確認できていない点を率直に挙げる。

・一般公開の時期：クローズドアルファの段階で、一般提供の予定は未公表
・料金体系：価格やプラン構成は公式情報から確認できない
・動画の検証：UIティザーはベンダー提供のデモで、応答精度や速度の第三者検証はない
・対応範囲の確定情報：持ち込めるエージェントや連携先は変動しうる
・AJの正体：動画でバグを報告したAJはアイコン型のアバターだが、人間かエージェントかは動画からは断定できない
・「composer」が何を指すか：動画のバグ報告に出る composer が何のアプリ・機能かは明示されていない
・資金調達：公開された調達発表は確認できない（New Ontologiesは「quiet since inception」と表現）

動画の鮮やかさは、そのまま製品の完成度を意味しない。 デモは「こう動くように作っている」という宣言であり、毎回その通りに動く保証ではない。 特にエージェントがコードベースを調べてチケットを起票する部分は、実際のリポジトリやLinearの構造に依存する。 自分のチームで同じ精度が出るかは、アルファに参加して確かめるしかない。

もうひとつ、構造的な懸念も書いておく。 Andoはオープンソースではなく、運用はベンダーに依存する。 通話やチャットを索引化する設計は、文脈供給に効く一方で、機密情報をどこまで預けるかという判断を伴う。 クローズドアルファの段階では、データの取り扱いや権限設計の詳細を、導入前に確認する必要がある。

料金・提供状況・利用条件

提供状況を、わかっている範囲で明確に書く。

・提供形態：クローズドアルファ（very private alpha）
・入手方法：公式サイト ando.so の「Get access」からアクセスを申請
・オープンソース：いいえ。公開リポジトリは確認できない
・料金：未公表
・運営：サイト記載でAsari Inc.（2026年）
・採用：New Ontologiesの記事によると採用中

公式サイトの導線は「Get access」で統一されており、誰でもすぐ使える状態ではない。 GitHubのリンクを期待して探しても、Andoはオープンソースのプロジェクトではない。 この記事で参照しているのも、公式サイトのコピー、@andocorporationの投稿、New OntologiesとSara Du氏本人の文章という公開情報に限られる。

導入を検討する場合は、アルファ参加の可否、データの取り扱い、対応エージェントの範囲を、公式に問い合わせる前提で進めるのが妥当だ。

まとめ

Andoが公開したのは、32秒の短い動画だった。 だがその中身は、製品の主張を凝縮していた。

エージェントは、bot欄に隔離された道具ではなく、人間と同じチャンネルに座る同僚として描かれていた。 Yumiは会話からバグを拾い、コードベースを調べ、再現し、チケットを起票し、担当者に判断を仰いだ。 別のスレッドでは、頼まれた相手のLinearを覗いて軽口を返した。 そのすべてが、ツールを行き来せず、ひとつの会話の場で完結していた。

この設計を支えるのが、コンテキスト・メモリ・ツールという3つの供給だ。 会話と通話を索引化して文脈にし、チームの慣習を記憶し、Linearやコードベースに手を伸ばす。 建築家・安藤忠雄の「間」を借りた静かなUIは、その思想の表層にすぎない。

一方で、わかっていないことも多い。 クローズドアルファで、料金も一般公開時期も未公表。 動画はベンダーのデモで、第三者の検証はない。 オープンソースでもない。

それでも、「エージェントがいる前提でチャットを作り直す」という賭けは、後付けでアシスタントを足す路線とは明確に違う方向を向いている。 SlackやTeamsがエージェント機能を積み増す中で、Andoは入口の設計そのものを問い直そうとしている。 このティザーが製品としてどこまで届くかは、アルファの外に出てくるまで判断を保留するのが正しい。 ただ、エージェント前提のメッセージングという問いの立て方は、見ておく価値がある。

参照ソース

・@andocorporation 公式投稿（UIティザー動画 / 2026-06-17） — 本記事冒頭の動画の出典
・Ando 公式サイト（ando.so） — タグライン、3要素、対応エージェント、提供状況
・New Ontologies：Ando — Building Slack from Scratch — 創業者の経歴・設計思想・アルファ事例
・Sara Du 個人サイト：Ando について — 創業者本人によるプロダクト説明