AI チームメイトがメモリを構築する仕組み:仕事を再利用可能な知識に変換

Asana エンジニアリングチームEngineering Team
2026年4月2日
facebookx-twitterlinkedin
チーム向けの AI エージェント

ほとんどの AI 製品は、メモリを個人的な機能として扱い、1 人のユーザーまたは 1 回の会話に関する事実を記憶します。 しかし、チーム間でコラボレーションを行う AI には、根本的に異なる種類のメモリが必要です。 AI システムは、以前に学んだことを土台にしてさらに発展させることができると、より有用になります。 しかし、エンタープライズソフトウェアにおいて、メモリは単により多くのコンテキストを保存するという問題ではありません。 より難しい問題は、そのメモリを検査可能、管理可能、権限対応のままにしながら、共有された仕事全体で有用にすることです。

これが、AI チームメイトで解決しようとしている課題です。

AI チームメイトは、異なる環境で動作します。 共有されたタスク、プロジェクト、ドキュメントでコラボレーションを行います。 複数の人からフィードバックを受けます。 複数のシステムを横断して働きます。 また、誰も監査できない隠されたコンテキストでいっぱいのブラックボックスになることなく、時間の経過とともに向上する必要があります。

これにより、別の設計上の問題が発生します。 AI チームメイトには、実行から学び、後で関連する知識を取得し、その知識が自分の行動にどのように影響したかを説明する方法が必要です。 同時に、以前の情報をすべてグローバルに再利用可能なものとして扱うことはできません。 AI が記憶するものと使用できるものは、実際の仕事を支えるものと同じ境界を尊重する必要があります。

具体的には、メモリがエンタープライズグレードのコラボレーションアーキテクチャの一部となることを意味します。 学習、取得、アクセス制御、透明性を 1 つのシステムに統合します。

1 回限りのコンテキストから再利用可能な知識へ

最もシンプルな AI アシスタントは、毎回最初からやり直します。 プロンプトを入力し、場合によってはファイルを添付すると、その 1 回のやり取りの中で AI がサポートを提供しようとします。 これは単発のリクエストには有効かもしれませんが、長期にわたるチームのワークフローではすぐに限界に達します。

人間のコラボレーターは、現在のメッセージに応答するだけではありません。 チームが好むプロセス、良い成果物を定義する例、重要な文書、先週受け取ったフィードバック、そして仕事の進め方を決定するプロジェクトのコンテキストを覚えています。 AI チームメイトを本物のコラボレーターのように感じてもらうには、同じような仕事上の知識を蓄積する手段が必要です。

私たちにとって、それは知識のライフサイクル全体にわたる統一されたメモリレイヤーを構築することを意味しました。

  • メモリの作成方法

  • 今後の実行中にメモリがどのように取得されるか

  • それらがワークグラフ (組織全体でタスク、プロジェクト、メンバー、目標をつなげる Asana の構造化データモデル) にどのようにリンクされるか

  • ユーザーがチームメイトが学んだことをどのように検査し、管理するか

この最後のポイントは、一見したところよりも重要です。 誰も検査や修正を行えない強力なメモリシステムは、信頼を生み出しません。 新たな障害モードを生み出すことになります。

AI チームメイトがメモリを作成する仕組み

最初に行った設計上の選択の 1 つは、チームメイトがメモリを生成する適切なタイミングを特定することでした。

メモリの 1 つのクラスは、実行中または実行後に推測されます。 チームメイトがタスクに取り組む際、指示に遭遇し、リソースを読み、アクションを実行し、フィードバックを受け取ります。 そうした情報には一時的なものもあります。 また、持続的で再利用する価値のある情報もあります。たとえば、ユーザーが「これらのタスクには常にデータモデルレビュアーを CC に入れてください」といったフィードバックを提供する場合などです。 別の例として、チームメイトがプロジェクトを読むと、プロジェクトの目的について知ることができます (例: プロジェクト X には、組織のマーケティングキャンペーンのベストプラクティスに関するリソースが含まれているなど)。 これらは、耐久性のあるメモリに最適な候補です。

もう 1 つのメモリのクラスは明示的なものです。 ユーザーは、システムが推測するのを待つのではなく、直接ガイダンスを提供することができます。 これは、目標が過去の仕事から教訓を得ることではなく、より広範な仕事の背景情報の中でどのように行動するか、または特定のリソースをどのように使用するかをチームメイトに教えることである場合に、特に重要です。

その明示的なパスは、リソースにリンクされたメモリにとって特に強力なものとなります。 ユーザーは、チームメイトにドキュメントへのアクセスを付与し、そのリソースが果たすべき役割を説明することができます。 チームのコミュニケーション方法を説明するプロセス文書でしょうか? ドメイン知識を含む参照文書ですか? 今後の仕事の基礎となるテンプレートですか? 同じソース資料でも、ユーザーの意図によって使い方が大きく異なる可能性があるため、この区別は重要です。

メモリが作成されるたびに、「メモリアソシエーション」が作成されます。これは基本的に、そのメモリが関連するワークグラフオブジェクトへの参照です。 たとえば、メモリが記述しているプロジェクトや、ユーザーがアップロードした Google ドキュメントのリソースなどが考えられます。 この記事でさらに詳しく説明するように、これらの関連付けは、メモリを取得し、適切なアクセス制御を確保するための鍵となります。

AI チームメイトがメモリを取得する仕組み

メモリシステムの質は、その検索モデルの質によって左右されます。 適切な知識が適切なタイミングで表示されなければ、有用な学習内容を保存するだけでは不十分です。

AI チームメイトの場合、取得は 2 レーンのシステムとして機能します。

1 つ目のレーンは、実行開始時の取得です。 チームメイトがタスクの作業を開始すると、意思決定を始める前に関連するメモリのセットを受け取ります。 これには、常に適用すべき固定された指示、現在の仕事に一致する過去の学習、検索またはセマンティックな類似性に基づいて関連性があると思われる高レベルの知識などが含まれる場合があります。

2 番目のレーンは、実行中のコンテキスト検索です。 チームメイトが特定のタスク、プロジェクト、またはその他のオブジェクトを読み取ると、そのオブジェクトに関連付けられたメモリも受け取ります。 これは重要なことです。なぜなら、抽象的な観点から見ると、一般的に関連性がない知識もあるからです。 チームメイトがワークグラフの特定の部分を見ているため、関連性が生まれます。

この組み合わせにより、システムに有用なバランスが生まれます。 チームメイトは、関連性が高いと思われる幅広い知識のセットから始め、仕事を深く掘り下げるにつれて、より正確なコンテキストを得ることができます。

メモリを操作可能にする

最も重要なデザイン上の選択の 1 つは、メモリを神秘的なものではなく、操作可能なものとして表現することでした。 当社のデータモデルでは、メモリはコンテンツ、メタデータ、関連付けを持つ具体的なオブジェクトです。

メモリアソシエーションは、メモリが関連するワークグラフオブジェクトをキャプチャします。 これにより、メモリがキャプチャしているコンテキストから切り離された状態ではなく、より広範なワークグラフ内でメモリを明示的にコンテキスト化することができます。 

アクセス制御が設計全体を形作る

エンタープライズメモリシステムは、複数の人、プロジェクト、権限が含まれる瞬間に、はるかに複雑になります。

Personal アシスタント AI は、メモリを 1 人のユーザーの履歴の単純な拡張として扱うことがよくあります。 しかし、共有された仕事全体で動作し、複数のユーザーによってトリガーされる可能性のあるチームメイトは、それを安全に行うことができません。 システムが作成するメモリはすべて、タスク、コメント、ドキュメント、プロジェクト、以前の実行など、実際の基礎となる作業から派生しています。 メモリがこれらのソースから切り離されてしまうと、権限の境界を越えて情報が漏洩するチャンネルになってしまう可能性があります。

そのため、AI チームメイトのメモリは、そのメモリの元となった作業と同じアクセス制御ロジックを継承する必要があります。

メモリの取得はすべて、実行をトリガーした人に限定されます。 チームメイトは、メモリを生成した仕事 (関連するタスク、コメント、ドキュメント、またはプロジェクト) を閲覧できる場合にのみ、そのメモリにアクセスできます。 関連付けにも同じルールが適用されます。メモリがタスクやプロジェクトなどの Asana オブジェクトを参照している場合、トリガーユーザーがそのオブジェクトを閲覧できる場合にのみ表示されます。 言い換えれば、AI チームメイトは、それを開始した人がすでに見ることができなかったものを見ることは決してありません。

透明性でループを閉じる

最後の要素は可視性です。 チームメイトがメモリを使ってアクションを実行する場合、ユーザーはその影響を理解する手段を必要とします。

それは、検査可能なメモリ自体から始まります。 ユーザーは、チームメイトが保持するメモリを表示し、不正確または古い可能性のあるメモリを削除できる必要があります。 さらに、チームメイトが実行すると、システムはどのメモリが実行コンテキストに渡されたか、どのメモリが実行中に作成されたかを表示できます。

「なぜ AI はそのようなことをしたのですか?」と抽象的に尋ねるのではなく、 ユーザーは、その動作をたどり、特定の学習済みの指示、リソースメモリ、または関連するコンテキストオブジェクトにたどり着くことができます。 修正は具体的なものになります。メモリを編集する、削除する、ソースを更新する、より良いガイダンスを追加する、などです。

たとえば、チームメイトが予想と異なる形式でレポートを作成した場合、ユーザーはそのメモリを確認して、先週別のチームメンバーからのフィードバックから書式設定の好みを学習したことを確認し、そのメモリを更新または削除して動作を変更できます。

だからこそ、メモリと透明性は一緒に設計する必要があるのです。 時間をかけて学習するチームメイトは、よりパワフルです。 目に見えない形で学習するチームメイトは、信頼しにくくなります。

これが重要な理由

前回の投稿では、AI チームメイトが共有されたチームスペースでどのように透明性を持って機能するかを検討しました。 メモリは、そのコラボレーションを強化するレイヤーです。システムは共有された仕事から学習し、必要なときにその知識を取得します。そして、そのプロセスは、仕事そのものを支配するのと同じ信頼の境界内で行われます。 

より深い教訓は、チームを対象とした AI には、より大きなコンテキストウィンドウ以上のものが必要であるということです。 コラボレーションを持続的で再利用可能かつ管理可能な知識に変えるためのモデルが必要です。

次の投稿では、この推論を支える言語モデルを評価し、選択する方法についてご紹介します。


この記事は、AI チームメイトチームのエンジニアである Anant Tibrewal によって執筆されました。Anant は、Asana のコラボレーション型エージェント AI 製品の構築とスケールアップに取り組んでいます。

関連記事

Asana Service Management
人工知能 (AI)

Streamline your service operations in one platform with Asana Service Management, now Generally Available.